From 420ea7233fc990119aa362f39421d65bba15186f Mon Sep 17 00:00:00 2001 From: TsunamiNoAi Date: Tue, 4 Aug 2026 12:47:21 -0400 Subject: [PATCH 1/2] SCF 2026.2: rename-resilient sheet/column resolution MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upstream renamed the "Authoritative Sources" tab to "Focal Documents" and shortened the compensating-controls "SCF Control #" header to "SCF #", breaking the weekly autopilot twice (issues #1, #2). The validation gate is fail-fast, so only the tab rename ever reached the filed report. Resolution is now alias-capable rather than single-pattern: - SHEET_PATTERNS maps each logical kind to an ordered tuple of accepted names (current first, historical after), so one parser reads every supported release. Sheet.col() takes the same treatment via `alts`. - Tab names match with norm_key, the normalization column headers already got, so invisible whitespace drift no longer summons a human. - overrides.json gains a `resolution` section carrying sheets[]/columns[] fallbacks, so a rename found in production is a JSON edit rather than a release. Operator aliases are tried only after the built-in patterns miss and raise a resolution-alias WARN, so they get folded into the parser later; a built-in pattern always wins over an alias. Three latent bugs that would have surfaced immediately after the rename fix: - The version-named catalog was never pruned on a bump. find_catalog takes the first sorted scf-*.json, so a leftover scf-2026-1-1.json would have shadowed scf-2026-2.json and published the previous release's data. - The summon-a-human step filed a new issue every cron run instead of commenting on the open one (hence two identical issues), and a failing hermetic gate filed nothing at all. - _structural_failure labelled every ColumnResolveError as sheet-resolve (every such message contains the word "sheet"), str() on these KeyError subclasses emitted the quoted repr, and the report's workbook sha256 was hardcoded empty. validate_overrides_file was dead code; it now runs as part of `validate`. The MON-03.3 evidence-request typo persists at 2026.2, so its override is no longer version-scoped — autopilot stays hands-off until upstream fixes it. Dataset: 1,534 controls across 34 families (new QTS, Quantum Security), 252 crosswalk frameworks, 5,956 AOs, 316 ERLs, 1,371 compensating controls, 42 threats (new MT-28). All 252 source rows now reconcile exact, where 2026.1.1 needed fuzzy matching and produced 5 warnings. Parsing the 2026.1.1 workbook still reproduces the committed 2026.1.1 dataset byte-for-byte: the aliases are additive, not a cutover. --- .github/workflows/update-scf.yml | 59 +- .scf-version | 2 +- CHANGELOG.md | 67 + CLAUDE.md | 26 +- README.md | 4 +- data/{scf-2026-1-1.json => scf-2026-2.json} | 18081 +- data/scf-assessment-objectives.json | 1810 +- data/scf-compensating-controls.json | 1100 +- data/scf-crosswalks.json | 239943 ++++++++------- data/scf-evidence-requests.json | 144 +- data/scf-threats.json | 10 +- docs/api/assessment-objectives.json | 1810 +- docs/api/assessment-objectives/AAT-01.5.json | 76 + docs/api/assessment-objectives/AAT-12.5.json | 16 + docs/api/assessment-objectives/AAT-12.6.json | 16 + docs/api/assessment-objectives/AAT-29.24.json | 46 + docs/api/assessment-objectives/AAT-33.json | 46 + docs/api/assessment-objectives/AST-05.2.json | 36 + docs/api/assessment-objectives/CFG-09.1.json | 16 + docs/api/assessment-objectives/CFG-09.2.json | 46 + docs/api/assessment-objectives/CFG-09.3.json | 16 + docs/api/assessment-objectives/CFG-09.json | 16 + docs/api/assessment-objectives/CPL-03.8.json | 26 + docs/api/assessment-objectives/GOV-01.4.json | 26 + docs/api/assessment-objectives/GOV-10.1.json | 26 + docs/api/assessment-objectives/GOV-19.3.json | 46 + docs/api/assessment-objectives/GOV-21.json | 76 + docs/api/assessment-objectives/IAC-01.4.json | 36 + docs/api/assessment-objectives/IAC-15.10.json | 16 + docs/api/assessment-objectives/MON-03.json | 2 +- docs/api/assessment-objectives/NET-06.8.json | 36 + docs/api/assessment-objectives/NET-06.9.json | 16 + docs/api/assessment-objectives/PRI-01.12.json | 26 + docs/api/assessment-objectives/QTS-01.1.json | 56 + docs/api/assessment-objectives/QTS-01.2.json | 26 + docs/api/assessment-objectives/QTS-01.3.json | 16 + docs/api/assessment-objectives/QTS-01.4.json | 56 + docs/api/assessment-objectives/QTS-01.json | 36 + docs/api/assessment-objectives/QTS-02.1.json | 56 + docs/api/assessment-objectives/QTS-02.2.json | 16 + docs/api/assessment-objectives/QTS-02.3.json | 16 + docs/api/assessment-objectives/QTS-02.json | 46 + docs/api/assessment-objectives/QTS-03.1.json | 26 + docs/api/assessment-objectives/QTS-03.2.json | 36 + docs/api/assessment-objectives/QTS-03.3.json | 36 + docs/api/assessment-objectives/QTS-03.4.json | 16 + docs/api/assessment-objectives/QTS-03.json | 46 + docs/api/assessment-objectives/QTS-04.1.json | 76 + docs/api/assessment-objectives/QTS-04.2.json | 56 + docs/api/assessment-objectives/QTS-04.3.json | 46 + docs/api/assessment-objectives/QTS-04.json | 26 + docs/api/assessment-objectives/QTS-05.1.json | 46 + docs/api/assessment-objectives/QTS-05.2.json | 16 + docs/api/assessment-objectives/QTS-05.json | 46 + docs/api/assessment-objectives/QTS-06.1.json | 56 + docs/api/assessment-objectives/QTS-06.10.json | 16 + docs/api/assessment-objectives/QTS-06.2.json | 56 + docs/api/assessment-objectives/QTS-06.3.json | 26 + docs/api/assessment-objectives/QTS-06.4.json | 16 + docs/api/assessment-objectives/QTS-06.5.json | 16 + docs/api/assessment-objectives/QTS-06.6.json | 46 + docs/api/assessment-objectives/QTS-06.7.json | 16 + docs/api/assessment-objectives/QTS-06.8.json | 46 + docs/api/assessment-objectives/QTS-06.9.json | 46 + docs/api/assessment-objectives/QTS-06.json | 16 + docs/api/assessment-objectives/QTS-07.json | 56 + docs/api/assessment-objectives/QTS-08.json | 46 + docs/api/assessment-objectives/RSK-01.json | 2 +- docs/api/assessment-objectives/RSK-03.2.json | 16 + docs/api/assessment-objectives/RSK-09.json | 2 +- docs/api/assessment-objectives/SAT-04.1.json | 26 + docs/api/assessment-objectives/SEA-01.4.json | 26 + docs/api/assessment-objectives/SEA-01.5.json | 16 + docs/api/assessment-objectives/SEA-08.2.json | 36 + docs/api/assessment-objectives/TDA-06.7.json | 26 + docs/api/assessment-objectives/TDA-13.1.json | 16 + docs/api/assessment-objectives/TDA-13.2.json | 26 + docs/api/assessment-objectives/TDA-19.1.json | 26 + docs/api/assessment-objectives/THR-01.1.json | 16 + docs/api/assessment-objectives/THR-01.2.json | 16 + docs/api/assessment-objectives/TPM-05.json | 2 +- docs/api/assessment-objectives/VPM-02.1.json | 36 + docs/api/compensating-controls.json | 1100 +- docs/api/compensating-controls/AAT-01.5.json | 16 + docs/api/compensating-controls/AAT-12.5.json | 16 + docs/api/compensating-controls/AAT-12.6.json | 16 + docs/api/compensating-controls/AAT-29.24.json | 16 + docs/api/compensating-controls/AAT-33.json | 16 + docs/api/compensating-controls/AST-05.2.json | 16 + docs/api/compensating-controls/CFG-09.1.json | 16 + docs/api/compensating-controls/CFG-09.2.json | 16 + docs/api/compensating-controls/CFG-09.3.json | 16 + docs/api/compensating-controls/CFG-09.json | 16 + docs/api/compensating-controls/CPL-03.8.json | 16 + docs/api/compensating-controls/GOV-01.4.json | 16 + docs/api/compensating-controls/GOV-10.1.json | 16 + docs/api/compensating-controls/GOV-19.3.json | 16 + docs/api/compensating-controls/GOV-21.json | 16 + docs/api/compensating-controls/IAC-01.4.json | 16 + docs/api/compensating-controls/IAC-15.10.json | 16 + docs/api/compensating-controls/NET-06.8.json | 16 + docs/api/compensating-controls/NET-06.9.json | 16 + docs/api/compensating-controls/PRI-01.12.json | 16 + docs/api/compensating-controls/QTS-01.1.json | 16 + docs/api/compensating-controls/QTS-01.2.json | 16 + docs/api/compensating-controls/QTS-01.3.json | 16 + docs/api/compensating-controls/QTS-01.4.json | 16 + docs/api/compensating-controls/QTS-01.json | 16 + docs/api/compensating-controls/QTS-02.1.json | 16 + docs/api/compensating-controls/QTS-02.2.json | 16 + docs/api/compensating-controls/QTS-02.3.json | 16 + docs/api/compensating-controls/QTS-02.json | 16 + docs/api/compensating-controls/QTS-03.1.json | 16 + docs/api/compensating-controls/QTS-03.2.json | 16 + docs/api/compensating-controls/QTS-03.3.json | 16 + docs/api/compensating-controls/QTS-03.4.json | 16 + docs/api/compensating-controls/QTS-03.json | 16 + docs/api/compensating-controls/QTS-04.1.json | 16 + docs/api/compensating-controls/QTS-04.2.json | 16 + docs/api/compensating-controls/QTS-04.3.json | 16 + docs/api/compensating-controls/QTS-04.json | 16 + docs/api/compensating-controls/QTS-05.1.json | 16 + docs/api/compensating-controls/QTS-05.2.json | 16 + docs/api/compensating-controls/QTS-05.json | 16 + docs/api/compensating-controls/QTS-06.1.json | 16 + docs/api/compensating-controls/QTS-06.10.json | 16 + docs/api/compensating-controls/QTS-06.2.json | 16 + docs/api/compensating-controls/QTS-06.3.json | 16 + docs/api/compensating-controls/QTS-06.4.json | 16 + docs/api/compensating-controls/QTS-06.5.json | 16 + docs/api/compensating-controls/QTS-06.6.json | 16 + docs/api/compensating-controls/QTS-06.7.json | 16 + docs/api/compensating-controls/QTS-06.8.json | 16 + docs/api/compensating-controls/QTS-06.9.json | 16 + docs/api/compensating-controls/QTS-06.json | 16 + docs/api/compensating-controls/QTS-07.json | 16 + docs/api/compensating-controls/QTS-08.json | 16 + docs/api/compensating-controls/RSK-03.2.json | 16 + docs/api/compensating-controls/SAT-04.1.json | 16 + docs/api/compensating-controls/SEA-01.4.json | 16 + docs/api/compensating-controls/SEA-01.5.json | 16 + docs/api/compensating-controls/SEA-08.2.json | 16 + docs/api/compensating-controls/TDA-06.7.json | 16 + docs/api/compensating-controls/TDA-13.1.json | 16 + docs/api/compensating-controls/TDA-13.2.json | 16 + docs/api/compensating-controls/TDA-19.1.json | 16 + docs/api/compensating-controls/THR-01.1.json | 16 + docs/api/compensating-controls/THR-01.2.json | 16 + docs/api/compensating-controls/VPM-02.1.json | 16 + docs/api/controls.json | 50184 +-- docs/api/controls/AAT-01.1.json | 3 +- docs/api/controls/AAT-01.2.json | 3 +- docs/api/controls/AAT-01.3.json | 5 +- docs/api/controls/AAT-01.4.json | 3 +- docs/api/controls/AAT-01.5.json | 104 + docs/api/controls/AAT-01.json | 7 +- docs/api/controls/AAT-02.1.json | 3 +- docs/api/controls/AAT-02.2.json | 4 +- docs/api/controls/AAT-02.3.json | 6 +- docs/api/controls/AAT-02.4.json | 3 +- docs/api/controls/AAT-02.json | 3 +- docs/api/controls/AAT-03.1.json | 5 +- docs/api/controls/AAT-03.2.json | 3 +- docs/api/controls/AAT-03.json | 6 +- docs/api/controls/AAT-04.1.json | 3 +- docs/api/controls/AAT-04.2.json | 3 +- docs/api/controls/AAT-04.3.json | 3 +- docs/api/controls/AAT-04.4.json | 3 +- docs/api/controls/AAT-04.json | 3 +- docs/api/controls/AAT-05.json | 3 +- docs/api/controls/AAT-06.json | 3 +- docs/api/controls/AAT-07.1.json | 3 +- docs/api/controls/AAT-07.2.json | 3 +- docs/api/controls/AAT-07.3.json | 3 +- docs/api/controls/AAT-07.json | 3 +- docs/api/controls/AAT-08.json | 3 +- docs/api/controls/AAT-09.1.json | 12 +- docs/api/controls/AAT-09.json | 3 +- docs/api/controls/AAT-10.1.json | 5 +- docs/api/controls/AAT-10.10.json | 5 +- docs/api/controls/AAT-10.11.json | 5 +- docs/api/controls/AAT-10.12.json | 5 +- docs/api/controls/AAT-10.13.json | 5 +- docs/api/controls/AAT-10.14.json | 5 +- docs/api/controls/AAT-10.15.json | 5 +- docs/api/controls/AAT-10.16.json | 5 +- docs/api/controls/AAT-10.17.json | 7 +- docs/api/controls/AAT-10.18.json | 5 +- docs/api/controls/AAT-10.19.json | 3 +- docs/api/controls/AAT-10.2.json | 5 +- docs/api/controls/AAT-10.3.json | 5 +- docs/api/controls/AAT-10.4.json | 5 +- docs/api/controls/AAT-10.5.json | 5 +- docs/api/controls/AAT-10.6.json | 5 +- docs/api/controls/AAT-10.7.json | 5 +- docs/api/controls/AAT-10.8.json | 5 +- docs/api/controls/AAT-10.9.json | 5 +- docs/api/controls/AAT-10.json | 5 +- docs/api/controls/AAT-11.1.json | 3 +- docs/api/controls/AAT-11.2.json | 3 +- docs/api/controls/AAT-11.3.json | 3 +- docs/api/controls/AAT-11.4.json | 5 +- docs/api/controls/AAT-11.json | 3 +- docs/api/controls/AAT-12.1.json | 7 +- docs/api/controls/AAT-12.2.json | 3 +- docs/api/controls/AAT-12.3.json | 3 +- docs/api/controls/AAT-12.4.json | 3 +- docs/api/controls/AAT-12.5.json | 105 + docs/api/controls/AAT-12.6.json | 105 + docs/api/controls/AAT-12.json | 3 +- docs/api/controls/AAT-13.1.json | 3 +- docs/api/controls/AAT-13.json | 3 +- docs/api/controls/AAT-14.1.json | 3 +- docs/api/controls/AAT-14.2.json | 3 +- docs/api/controls/AAT-14.json | 3 +- docs/api/controls/AAT-15.1.json | 3 +- docs/api/controls/AAT-15.2.json | 3 +- docs/api/controls/AAT-15.json | 3 +- docs/api/controls/AAT-16.1.json | 3 +- docs/api/controls/AAT-16.10.json | 5 +- docs/api/controls/AAT-16.11.json | 8 +- docs/api/controls/AAT-16.12.json | 5 +- docs/api/controls/AAT-16.13.json | 5 +- docs/api/controls/AAT-16.14.json | 3 +- docs/api/controls/AAT-16.2.json | 4 +- docs/api/controls/AAT-16.3.json | 3 +- docs/api/controls/AAT-16.4.json | 3 +- docs/api/controls/AAT-16.5.json | 3 +- docs/api/controls/AAT-16.6.json | 3 +- docs/api/controls/AAT-16.7.json | 3 +- docs/api/controls/AAT-16.8.json | 3 +- docs/api/controls/AAT-16.9.json | 3 +- docs/api/controls/AAT-16.json | 3 +- docs/api/controls/AAT-17.1.json | 3 +- docs/api/controls/AAT-17.2.json | 3 +- docs/api/controls/AAT-17.3.json | 3 +- docs/api/controls/AAT-17.4.json | 3 +- docs/api/controls/AAT-17.5.json | 4 +- docs/api/controls/AAT-17.json | 6 +- docs/api/controls/AAT-18.1.json | 5 +- docs/api/controls/AAT-18.json | 3 +- docs/api/controls/AAT-19.1.json | 5 +- docs/api/controls/AAT-19.2.json | 5 +- docs/api/controls/AAT-19.3.json | 5 +- docs/api/controls/AAT-19.4.json | 5 +- docs/api/controls/AAT-19.5.json | 5 +- docs/api/controls/AAT-19.6.json | 5 +- docs/api/controls/AAT-19.7.json | 5 +- docs/api/controls/AAT-19.8.json | 3 +- docs/api/controls/AAT-19.json | 5 +- docs/api/controls/AAT-20.1.json | 3 +- docs/api/controls/AAT-20.2.json | 3 +- docs/api/controls/AAT-20.3.json | 5 +- docs/api/controls/AAT-20.json | 7 +- docs/api/controls/AAT-21.json | 3 +- docs/api/controls/AAT-22.1.json | 3 +- docs/api/controls/AAT-22.2.json | 3 +- docs/api/controls/AAT-22.3.json | 3 +- docs/api/controls/AAT-22.4.json | 3 +- docs/api/controls/AAT-22.5.json | 3 +- docs/api/controls/AAT-22.6.json | 3 +- docs/api/controls/AAT-22.7.json | 3 +- docs/api/controls/AAT-22.8.json | 3 +- docs/api/controls/AAT-22.json | 3 +- docs/api/controls/AAT-23.json | 3 +- docs/api/controls/AAT-24.json | 3 +- docs/api/controls/AAT-25.1.json | 3 +- docs/api/controls/AAT-25.json | 3 +- docs/api/controls/AAT-26.1.json | 3 +- docs/api/controls/AAT-26.2.json | 3 +- docs/api/controls/AAT-26.3.json | 3 +- docs/api/controls/AAT-26.4.json | 3 +- docs/api/controls/AAT-26.json | 3 +- docs/api/controls/AAT-27.1.json | 5 +- docs/api/controls/AAT-27.json | 3 +- docs/api/controls/AAT-28.1.json | 5 +- docs/api/controls/AAT-28.2.json | 5 +- docs/api/controls/AAT-28.3.json | 5 +- docs/api/controls/AAT-28.json | 5 +- docs/api/controls/AAT-29.1.json | 5 +- docs/api/controls/AAT-29.10.json | 5 +- docs/api/controls/AAT-29.11.json | 5 +- docs/api/controls/AAT-29.12.json | 6 +- docs/api/controls/AAT-29.13.json | 5 +- docs/api/controls/AAT-29.14.json | 5 +- docs/api/controls/AAT-29.15.json | 5 +- docs/api/controls/AAT-29.16.json | 5 +- docs/api/controls/AAT-29.17.json | 5 +- docs/api/controls/AAT-29.18.json | 5 +- docs/api/controls/AAT-29.19.json | 5 +- docs/api/controls/AAT-29.2.json | 11 +- docs/api/controls/AAT-29.20.json | 5 +- docs/api/controls/AAT-29.21.json | 5 +- docs/api/controls/AAT-29.22.json | 5 +- docs/api/controls/AAT-29.23.json | 5 +- docs/api/controls/AAT-29.24.json | 74 + docs/api/controls/AAT-29.3.json | 5 +- docs/api/controls/AAT-29.4.json | 5 +- docs/api/controls/AAT-29.5.json | 5 +- docs/api/controls/AAT-29.6.json | 5 +- docs/api/controls/AAT-29.7.json | 9 +- docs/api/controls/AAT-29.8.json | 9 +- docs/api/controls/AAT-29.9.json | 5 +- docs/api/controls/AAT-29.json | 5 +- docs/api/controls/AAT-30.1.json | 5 +- docs/api/controls/AAT-30.2.json | 11 +- docs/api/controls/AAT-30.json | 5 +- docs/api/controls/AAT-31.json | 5 +- docs/api/controls/AAT-32.1.json | 3 +- docs/api/controls/AAT-32.json | 5 +- docs/api/controls/AAT-33.json | 103 + docs/api/controls/AST-01.1.json | 48 +- docs/api/controls/AST-01.2.json | 25 +- docs/api/controls/AST-01.3.json | 5 +- docs/api/controls/AST-01.4.json | 22 +- docs/api/controls/AST-01.5.json | 10 +- docs/api/controls/AST-01.json | 112 +- docs/api/controls/AST-02.1.json | 20 +- docs/api/controls/AST-02.10.json | 7 +- docs/api/controls/AST-02.11.json | 3 +- docs/api/controls/AST-02.2.json | 23 +- docs/api/controls/AST-02.3.json | 3 +- docs/api/controls/AST-02.4.json | 21 +- docs/api/controls/AST-02.5.json | 23 +- docs/api/controls/AST-02.6.json | 5 +- docs/api/controls/AST-02.7.json | 13 +- docs/api/controls/AST-02.8.json | 24 +- docs/api/controls/AST-02.9.json | 76 +- docs/api/controls/AST-02.json | 83 +- docs/api/controls/AST-03.1.json | 19 +- docs/api/controls/AST-03.2.json | 22 +- docs/api/controls/AST-03.json | 39 +- docs/api/controls/AST-04.1.json | 41 +- docs/api/controls/AST-04.2.json | 13 +- docs/api/controls/AST-04.3.json | 6 +- docs/api/controls/AST-04.json | 62 +- docs/api/controls/AST-05.1.json | 7 +- docs/api/controls/AST-05.2.json | 114 + docs/api/controls/AST-05.json | 26 +- docs/api/controls/AST-06.1.json | 9 +- docs/api/controls/AST-06.json | 12 +- docs/api/controls/AST-07.json | 14 +- docs/api/controls/AST-08.json | 11 +- docs/api/controls/AST-09.json | 63 +- docs/api/controls/AST-10.json | 10 +- docs/api/controls/AST-11.json | 14 +- docs/api/controls/AST-12.json | 15 +- docs/api/controls/AST-13.json | 16 +- docs/api/controls/AST-14.1.json | 18 +- docs/api/controls/AST-14.2.json | 9 +- docs/api/controls/AST-14.json | 14 +- docs/api/controls/AST-15.1.json | 13 +- docs/api/controls/AST-15.json | 11 +- docs/api/controls/AST-16.json | 134 +- docs/api/controls/AST-17.json | 9 +- docs/api/controls/AST-18.json | 12 +- docs/api/controls/AST-19.json | 19 +- docs/api/controls/AST-20.json | 10 +- docs/api/controls/AST-21.json | 7 +- docs/api/controls/AST-22.json | 11 +- docs/api/controls/AST-23.json | 33 +- docs/api/controls/AST-24.json | 10 +- docs/api/controls/AST-25.json | 7 +- docs/api/controls/AST-26.json | 7 +- docs/api/controls/AST-27.json | 15 +- docs/api/controls/AST-28.1.json | 19 +- docs/api/controls/AST-28.json | 19 +- docs/api/controls/AST-29.1.json | 5 +- docs/api/controls/AST-29.json | 10 +- docs/api/controls/AST-30.json | 16 +- docs/api/controls/AST-31.1.json | 5 +- docs/api/controls/AST-31.2.json | 5 +- docs/api/controls/AST-31.3.json | 5 +- docs/api/controls/AST-31.json | 8 +- docs/api/controls/AST-32.json | 3 +- docs/api/controls/BCD-01.1.json | 16 +- docs/api/controls/BCD-01.2.json | 14 +- docs/api/controls/BCD-01.3.json | 5 +- docs/api/controls/BCD-01.4.json | 39 +- docs/api/controls/BCD-01.5.json | 10 +- docs/api/controls/BCD-01.6.json | 6 +- docs/api/controls/BCD-01.7.json | 52 +- docs/api/controls/BCD-01.json | 178 +- docs/api/controls/BCD-02.1.json | 15 +- docs/api/controls/BCD-02.2.json | 27 +- docs/api/controls/BCD-02.3.json | 22 +- docs/api/controls/BCD-02.4.json | 15 +- docs/api/controls/BCD-02.json | 56 +- docs/api/controls/BCD-03.1.json | 17 +- docs/api/controls/BCD-03.2.json | 6 +- docs/api/controls/BCD-03.json | 10 +- docs/api/controls/BCD-04.1.json | 17 +- docs/api/controls/BCD-04.2.json | 13 +- docs/api/controls/BCD-04.json | 65 +- docs/api/controls/BCD-05.json | 30 +- docs/api/controls/BCD-06.1.json | 10 +- docs/api/controls/BCD-06.2.json | 5 +- docs/api/controls/BCD-06.json | 13 +- docs/api/controls/BCD-07.json | 7 +- docs/api/controls/BCD-08.1.json | 12 +- docs/api/controls/BCD-08.2.json | 11 +- docs/api/controls/BCD-08.json | 27 +- docs/api/controls/BCD-09.1.json | 12 +- docs/api/controls/BCD-09.2.json | 15 +- docs/api/controls/BCD-09.3.json | 11 +- docs/api/controls/BCD-09.4.json | 3 +- docs/api/controls/BCD-09.5.json | 8 +- docs/api/controls/BCD-09.json | 24 +- docs/api/controls/BCD-10.1.json | 11 +- docs/api/controls/BCD-10.2.json | 7 +- docs/api/controls/BCD-10.3.json | 7 +- docs/api/controls/BCD-10.4.json | 8 +- docs/api/controls/BCD-10.json | 12 +- docs/api/controls/BCD-11.1.json | 39 +- docs/api/controls/BCD-11.10.json | 11 +- docs/api/controls/BCD-11.2.json | 29 +- docs/api/controls/BCD-11.3.json | 11 +- docs/api/controls/BCD-11.4.json | 20 +- docs/api/controls/BCD-11.5.json | 17 +- docs/api/controls/BCD-11.6.json | 7 +- docs/api/controls/BCD-11.7.json | 19 +- docs/api/controls/BCD-11.8.json | 11 +- docs/api/controls/BCD-11.9.json | 17 +- docs/api/controls/BCD-11.json | 70 +- docs/api/controls/BCD-12.1.json | 11 +- docs/api/controls/BCD-12.2.json | 10 +- docs/api/controls/BCD-12.3.json | 5 +- docs/api/controls/BCD-12.4.json | 5 +- docs/api/controls/BCD-12.json | 37 +- docs/api/controls/BCD-13.1.json | 5 +- docs/api/controls/BCD-13.json | 8 +- docs/api/controls/BCD-14.json | 11 +- docs/api/controls/BCD-15.json | 7 +- docs/api/controls/BCD-16.json | 3 +- docs/api/controls/CAP-01.json | 55 +- docs/api/controls/CAP-02.json | 27 +- docs/api/controls/CAP-03.json | 31 +- docs/api/controls/CAP-04.json | 21 +- docs/api/controls/CAP-05.json | 18 +- docs/api/controls/CAP-06.json | 5 +- docs/api/controls/CFG-01.1.json | 7 +- docs/api/controls/CFG-01.json | 88 +- docs/api/controls/CFG-02.1.json | 34 +- docs/api/controls/CFG-02.2.json | 49 +- docs/api/controls/CFG-02.3.json | 17 +- docs/api/controls/CFG-02.4.json | 13 +- docs/api/controls/CFG-02.5.json | 63 +- docs/api/controls/CFG-02.6.json | 8 +- docs/api/controls/CFG-02.7.json | 19 +- docs/api/controls/CFG-02.8.json | 19 +- docs/api/controls/CFG-02.9.json | 26 +- docs/api/controls/CFG-02.json | 346 +- docs/api/controls/CFG-03.1.json | 16 +- docs/api/controls/CFG-03.2.json | 17 +- docs/api/controls/CFG-03.3.json | 33 +- docs/api/controls/CFG-03.4.json | 13 +- docs/api/controls/CFG-03.json | 62 +- docs/api/controls/CFG-04.1.json | 14 +- docs/api/controls/CFG-04.2.json | 17 +- docs/api/controls/CFG-04.json | 16 +- docs/api/controls/CFG-05.1.json | 20 +- docs/api/controls/CFG-05.2.json | 16 +- docs/api/controls/CFG-05.json | 23 +- docs/api/controls/CFG-06.1.json | 19 +- docs/api/controls/CFG-06.json | 20 +- docs/api/controls/CFG-07.json | 5 +- docs/api/controls/CFG-08.1.json | 14 +- docs/api/controls/CFG-08.json | 20 +- docs/api/controls/CFG-09.1.json | 76 + docs/api/controls/CFG-09.2.json | 78 + docs/api/controls/CFG-09.3.json | 79 + docs/api/controls/CFG-09.json | 76 + docs/api/controls/CHG-01.json | 98 +- docs/api/controls/CHG-02.1.json | 41 +- docs/api/controls/CHG-02.2.json | 61 +- docs/api/controls/CHG-02.3.json | 33 +- docs/api/controls/CHG-02.4.json | 8 +- docs/api/controls/CHG-02.5.json | 5 +- docs/api/controls/CHG-02.json | 76 +- docs/api/controls/CHG-03.json | 36 +- docs/api/controls/CHG-04.1.json | 11 +- docs/api/controls/CHG-04.2.json | 7 +- docs/api/controls/CHG-04.3.json | 18 +- docs/api/controls/CHG-04.4.json | 13 +- docs/api/controls/CHG-04.5.json | 17 +- docs/api/controls/CHG-04.json | 17 +- docs/api/controls/CHG-05.json | 11 +- docs/api/controls/CHG-06.1.json | 8 +- docs/api/controls/CHG-06.json | 29 +- docs/api/controls/CHG-07.1.json | 14 +- docs/api/controls/CHG-07.json | 25 +- docs/api/controls/CHG-08.json | 11 +- docs/api/controls/CLD-01.1.json | 9 +- docs/api/controls/CLD-01.2.json | 18 +- docs/api/controls/CLD-01.json | 98 +- docs/api/controls/CLD-02.json | 35 +- docs/api/controls/CLD-03.json | 18 +- docs/api/controls/CLD-04.1.json | 4 +- docs/api/controls/CLD-04.json | 18 +- docs/api/controls/CLD-05.json | 9 +- docs/api/controls/CLD-06.1.json | 19 +- docs/api/controls/CLD-06.2.json | 8 +- docs/api/controls/CLD-06.3.json | 5 +- docs/api/controls/CLD-06.4.json | 3 +- docs/api/controls/CLD-06.json | 18 +- docs/api/controls/CLD-07.json | 8 +- docs/api/controls/CLD-08.json | 9 +- docs/api/controls/CLD-09.json | 52 +- docs/api/controls/CLD-10.json | 19 +- docs/api/controls/CLD-11.json | 19 +- docs/api/controls/CLD-12.json | 7 +- docs/api/controls/CLD-13.1.json | 5 +- docs/api/controls/CLD-13.2.json | 9 +- docs/api/controls/CLD-13.json | 6 +- docs/api/controls/CLD-14.json | 6 +- docs/api/controls/CLD-15.json | 5 +- docs/api/controls/CPL-01.1.json | 60 +- docs/api/controls/CPL-01.2.json | 31 +- docs/api/controls/CPL-01.3.json | 42 +- docs/api/controls/CPL-01.4.json | 73 +- docs/api/controls/CPL-01.5.json | 28 +- docs/api/controls/CPL-01.6.json | 15 +- docs/api/controls/CPL-01.7.json | 14 +- docs/api/controls/CPL-01.8.json | 11 +- docs/api/controls/CPL-01.json | 364 +- docs/api/controls/CPL-02.1.json | 73 +- docs/api/controls/CPL-02.2.json | 45 +- docs/api/controls/CPL-02.3.json | 21 +- docs/api/controls/CPL-02.json | 214 +- docs/api/controls/CPL-03.1.json | 58 +- docs/api/controls/CPL-03.2.json | 90 +- docs/api/controls/CPL-03.3.json | 12 +- docs/api/controls/CPL-03.4.json | 5 +- docs/api/controls/CPL-03.5.json | 5 +- docs/api/controls/CPL-03.6.json | 5 +- docs/api/controls/CPL-03.7.json | 5 +- docs/api/controls/CPL-03.8.json | 114 + docs/api/controls/CPL-03.json | 231 +- docs/api/controls/CPL-04.json | 12 +- docs/api/controls/CPL-05.1.json | 12 +- docs/api/controls/CPL-05.2.json | 30 +- docs/api/controls/CPL-05.json | 17 +- docs/api/controls/CPL-06.json | 24 +- docs/api/controls/CPL-07.1.json | 5 +- docs/api/controls/CPL-07.json | 25 +- docs/api/controls/CPL-08.1.json | 15 +- docs/api/controls/CPL-08.json | 22 +- docs/api/controls/CPL-09.json | 5 +- docs/api/controls/CPL-10.json | 5 +- docs/api/controls/CPL-11.1.json | 5 +- docs/api/controls/CPL-11.2.json | 5 +- docs/api/controls/CPL-11.3.json | 5 +- docs/api/controls/CPL-11.json | 5 +- docs/api/controls/CPL-12.json | 5 +- docs/api/controls/CPL-13.1.json | 10 +- docs/api/controls/CPL-13.2.json | 6 +- docs/api/controls/CPL-13.json | 9 +- docs/api/controls/CRY-01.1.json | 13 +- docs/api/controls/CRY-01.2.json | 5 +- docs/api/controls/CRY-01.3.json | 7 +- docs/api/controls/CRY-01.4.json | 5 +- docs/api/controls/CRY-01.5.json | 26 +- docs/api/controls/CRY-01.json | 138 +- docs/api/controls/CRY-02.json | 11 +- docs/api/controls/CRY-03.json | 79 +- docs/api/controls/CRY-04.json | 40 +- docs/api/controls/CRY-05.1.json | 22 +- docs/api/controls/CRY-05.2.json | 3 +- docs/api/controls/CRY-05.3.json | 7 +- docs/api/controls/CRY-05.json | 45 +- docs/api/controls/CRY-06.json | 3 +- docs/api/controls/CRY-07.json | 17 +- docs/api/controls/CRY-08.1.json | 9 +- docs/api/controls/CRY-08.json | 26 +- docs/api/controls/CRY-09.1.json | 7 +- docs/api/controls/CRY-09.2.json | 7 +- docs/api/controls/CRY-09.3.json | 26 +- docs/api/controls/CRY-09.4.json | 20 +- docs/api/controls/CRY-09.5.json | 7 +- docs/api/controls/CRY-09.6.json | 5 +- docs/api/controls/CRY-09.7.json | 5 +- docs/api/controls/CRY-09.json | 48 +- docs/api/controls/CRY-10.json | 9 +- docs/api/controls/CRY-11.json | 5 +- docs/api/controls/CRY-12.json | 3 +- docs/api/controls/CRY-13.json | 6 +- docs/api/controls/DCH-01.1.json | 30 +- docs/api/controls/DCH-01.2.json | 99 +- docs/api/controls/DCH-01.3.json | 15 +- docs/api/controls/DCH-01.4.json | 48 +- docs/api/controls/DCH-01.json | 232 +- docs/api/controls/DCH-02.1.json | 13 +- docs/api/controls/DCH-02.json | 94 +- docs/api/controls/DCH-03.1.json | 291 +- docs/api/controls/DCH-03.2.json | 14 +- docs/api/controls/DCH-03.3.json | 5 +- docs/api/controls/DCH-03.json | 21 +- docs/api/controls/DCH-04.1.json | 13 +- docs/api/controls/DCH-04.json | 20 +- docs/api/controls/DCH-05.1.json | 5 +- docs/api/controls/DCH-05.10.json | 5 +- docs/api/controls/DCH-05.11.json | 5 +- docs/api/controls/DCH-05.2.json | 5 +- docs/api/controls/DCH-05.3.json | 5 +- docs/api/controls/DCH-05.4.json | 5 +- docs/api/controls/DCH-05.5.json | 5 +- docs/api/controls/DCH-05.6.json | 5 +- docs/api/controls/DCH-05.7.json | 5 +- docs/api/controls/DCH-05.8.json | 5 +- docs/api/controls/DCH-05.9.json | 7 +- docs/api/controls/DCH-05.json | 7 +- docs/api/controls/DCH-06.1.json | 12 +- docs/api/controls/DCH-06.2.json | 18 +- docs/api/controls/DCH-06.3.json | 14 +- docs/api/controls/DCH-06.4.json | 15 +- docs/api/controls/DCH-06.5.json | 7 +- docs/api/controls/DCH-06.json | 19 +- docs/api/controls/DCH-07.1.json | 26 +- docs/api/controls/DCH-07.2.json | 13 +- docs/api/controls/DCH-07.json | 32 +- docs/api/controls/DCH-08.json | 43 +- docs/api/controls/DCH-09.1.json | 19 +- docs/api/controls/DCH-09.2.json | 10 +- docs/api/controls/DCH-09.3.json | 25 +- docs/api/controls/DCH-09.4.json | 7 +- docs/api/controls/DCH-09.5.json | 17 +- docs/api/controls/DCH-09.json | 40 +- docs/api/controls/DCH-10.1.json | 18 +- docs/api/controls/DCH-10.2.json | 5 +- docs/api/controls/DCH-10.json | 18 +- docs/api/controls/DCH-11.json | 12 +- docs/api/controls/DCH-12.json | 25 +- docs/api/controls/DCH-13.1.json | 16 +- docs/api/controls/DCH-13.2.json | 23 +- docs/api/controls/DCH-13.3.json | 14 +- docs/api/controls/DCH-13.4.json | 17 +- docs/api/controls/DCH-13.json | 22 +- docs/api/controls/DCH-14.1.json | 5 +- docs/api/controls/DCH-14.2.json | 25 +- docs/api/controls/DCH-14.3.json | 12 +- docs/api/controls/DCH-14.json | 53 +- docs/api/controls/DCH-15.json | 6 +- docs/api/controls/DCH-16.json | 19 +- docs/api/controls/DCH-17.json | 33 +- docs/api/controls/DCH-18.1.json | 30 +- docs/api/controls/DCH-18.2.json | 19 +- docs/api/controls/DCH-18.3.json | 5 +- docs/api/controls/DCH-18.json | 72 +- docs/api/controls/DCH-19.json | 37 +- docs/api/controls/DCH-20.json | 7 +- docs/api/controls/DCH-21.json | 30 +- docs/api/controls/DCH-22.1.json | 137 +- docs/api/controls/DCH-22.2.json | 11 +- docs/api/controls/DCH-22.3.json | 10 +- docs/api/controls/DCH-22.json | 19 +- docs/api/controls/DCH-23.1.json | 5 +- docs/api/controls/DCH-23.2.json | 5 +- docs/api/controls/DCH-23.3.json | 5 +- docs/api/controls/DCH-23.4.json | 5 +- docs/api/controls/DCH-23.5.json | 5 +- docs/api/controls/DCH-23.6.json | 5 +- docs/api/controls/DCH-23.7.json | 9 +- docs/api/controls/DCH-23.8.json | 5 +- docs/api/controls/DCH-23.9.json | 9 +- docs/api/controls/DCH-23.json | 51 +- docs/api/controls/DCH-24.1.json | 65 +- docs/api/controls/DCH-24.json | 79 +- docs/api/controls/DCH-25.1.json | 5 +- docs/api/controls/DCH-25.json | 110 +- docs/api/controls/DCH-26.json | 20 +- docs/api/controls/DCH-27.json | 3 +- docs/api/controls/EMB-01.json | 35 +- docs/api/controls/EMB-02.json | 21 +- docs/api/controls/EMB-03.json | 8 +- docs/api/controls/EMB-04.json | 8 +- docs/api/controls/EMB-05.json | 15 +- docs/api/controls/EMB-06.json | 14 +- docs/api/controls/EMB-07.json | 12 +- docs/api/controls/EMB-08.json | 7 +- docs/api/controls/EMB-09.json | 11 +- docs/api/controls/EMB-10.json | 14 +- docs/api/controls/EMB-11.json | 5 +- docs/api/controls/EMB-12.json | 8 +- docs/api/controls/EMB-13.json | 27 +- docs/api/controls/EMB-14.json | 9 +- docs/api/controls/EMB-15.json | 5 +- docs/api/controls/EMB-16.json | 5 +- docs/api/controls/EMB-17.json | 5 +- docs/api/controls/EMB-18.json | 8 +- docs/api/controls/EMB-19.json | 8 +- docs/api/controls/END-01.1.json | 3 +- docs/api/controls/END-01.json | 86 +- docs/api/controls/END-02.json | 42 +- docs/api/controls/END-03.1.json | 11 +- docs/api/controls/END-03.2.json | 3 +- docs/api/controls/END-03.json | 11 +- docs/api/controls/END-04.1.json | 16 +- docs/api/controls/END-04.2.json | 3 +- docs/api/controls/END-04.3.json | 13 +- docs/api/controls/END-04.4.json | 11 +- docs/api/controls/END-04.5.json | 5 +- docs/api/controls/END-04.6.json | 8 +- docs/api/controls/END-04.7.json | 16 +- docs/api/controls/END-04.json | 54 +- docs/api/controls/END-05.json | 12 +- docs/api/controls/END-06.1.json | 17 +- docs/api/controls/END-06.2.json | 14 +- docs/api/controls/END-06.3.json | 9 +- docs/api/controls/END-06.4.json | 9 +- docs/api/controls/END-06.5.json | 10 +- docs/api/controls/END-06.6.json | 14 +- docs/api/controls/END-06.7.json | 5 +- docs/api/controls/END-06.8.json | 19 +- docs/api/controls/END-06.json | 25 +- docs/api/controls/END-07.json | 24 +- docs/api/controls/END-08.1.json | 16 +- docs/api/controls/END-08.2.json | 3 +- docs/api/controls/END-08.json | 23 +- docs/api/controls/END-09.json | 7 +- docs/api/controls/END-10.json | 14 +- docs/api/controls/END-11.json | 11 +- docs/api/controls/END-12.json | 13 +- docs/api/controls/END-13.1.json | 11 +- docs/api/controls/END-13.2.json | 10 +- docs/api/controls/END-13.3.json | 12 +- docs/api/controls/END-13.4.json | 3 +- docs/api/controls/END-13.json | 3 +- docs/api/controls/END-14.1.json | 7 +- docs/api/controls/END-14.2.json | 3 +- docs/api/controls/END-14.3.json | 3 +- docs/api/controls/END-14.4.json | 5 +- docs/api/controls/END-14.5.json | 3 +- docs/api/controls/END-14.6.json | 3 +- docs/api/controls/END-14.json | 11 +- docs/api/controls/END-15.json | 9 +- docs/api/controls/END-16.1.json | 5 +- docs/api/controls/END-16.json | 5 +- docs/api/controls/GOV-01.1.json | 121 +- docs/api/controls/GOV-01.2.json | 63 +- docs/api/controls/GOV-01.3.json | 41 +- docs/api/controls/GOV-01.4.json | 130 + docs/api/controls/GOV-01.json | 247 +- docs/api/controls/GOV-02.1.json | 21 +- docs/api/controls/GOV-02.json | 374 +- docs/api/controls/GOV-03.json | 104 +- docs/api/controls/GOV-04.1.json | 84 +- docs/api/controls/GOV-04.2.json | 33 +- docs/api/controls/GOV-04.json | 129 +- docs/api/controls/GOV-05.1.json | 12 +- docs/api/controls/GOV-05.2.json | 16 +- docs/api/controls/GOV-05.json | 56 +- docs/api/controls/GOV-06.json | 34 +- docs/api/controls/GOV-07.json | 16 +- docs/api/controls/GOV-08.json | 27 +- docs/api/controls/GOV-09.json | 28 +- docs/api/controls/GOV-10.1.json | 100 + docs/api/controls/GOV-10.json | 28 +- docs/api/controls/GOV-11.json | 9 +- docs/api/controls/GOV-12.json | 38 +- docs/api/controls/GOV-13.json | 39 +- docs/api/controls/GOV-14.json | 33 +- docs/api/controls/GOV-15.1.json | 98 +- docs/api/controls/GOV-15.2.json | 83 +- docs/api/controls/GOV-15.3.json | 62 +- docs/api/controls/GOV-15.4.json | 36 +- docs/api/controls/GOV-15.5.json | 45 +- docs/api/controls/GOV-15.json | 155 +- docs/api/controls/GOV-16.1.json | 12 +- docs/api/controls/GOV-16.2.json | 9 +- docs/api/controls/GOV-16.json | 15 +- docs/api/controls/GOV-17.json | 63 +- docs/api/controls/GOV-18.json | 12 +- docs/api/controls/GOV-19.1.json | 7 +- docs/api/controls/GOV-19.2.json | 7 +- docs/api/controls/GOV-19.3.json | 121 + docs/api/controls/GOV-19.json | 8 +- docs/api/controls/GOV-20.1.json | 7 +- docs/api/controls/GOV-20.json | 7 +- docs/api/controls/GOV-21.json | 100 + docs/api/controls/HRS-01.1.json | 14 +- docs/api/controls/HRS-01.json | 92 +- docs/api/controls/HRS-02.1.json | 18 +- docs/api/controls/HRS-02.2.json | 3 +- docs/api/controls/HRS-02.json | 59 +- docs/api/controls/HRS-03.1.json | 26 +- docs/api/controls/HRS-03.2.json | 47 +- docs/api/controls/HRS-03.json | 162 +- docs/api/controls/HRS-04.1.json | 37 +- docs/api/controls/HRS-04.2.json | 43 +- docs/api/controls/HRS-04.3.json | 14 +- docs/api/controls/HRS-04.4.json | 7 +- docs/api/controls/HRS-04.json | 47 +- docs/api/controls/HRS-05.1.json | 55 +- docs/api/controls/HRS-05.2.json | 20 +- docs/api/controls/HRS-05.3.json | 58 +- docs/api/controls/HRS-05.4.json | 18 +- docs/api/controls/HRS-05.5.json | 45 +- docs/api/controls/HRS-05.6.json | 5 +- docs/api/controls/HRS-05.7.json | 36 +- docs/api/controls/HRS-05.json | 71 +- docs/api/controls/HRS-06.1.json | 51 +- docs/api/controls/HRS-06.2.json | 10 +- docs/api/controls/HRS-06.json | 33 +- docs/api/controls/HRS-07.1.json | 14 +- docs/api/controls/HRS-07.2.json | 3 +- docs/api/controls/HRS-07.3.json | 10 +- docs/api/controls/HRS-07.json | 25 +- docs/api/controls/HRS-08.json | 24 +- docs/api/controls/HRS-09.1.json | 11 +- docs/api/controls/HRS-09.2.json | 18 +- docs/api/controls/HRS-09.3.json | 15 +- docs/api/controls/HRS-09.4.json | 15 +- docs/api/controls/HRS-09.json | 25 +- docs/api/controls/HRS-10.json | 16 +- docs/api/controls/HRS-11.json | 40 +- docs/api/controls/HRS-12.1.json | 10 +- docs/api/controls/HRS-12.json | 13 +- docs/api/controls/HRS-13.1.json | 6 +- docs/api/controls/HRS-13.2.json | 7 +- docs/api/controls/HRS-13.3.json | 10 +- docs/api/controls/HRS-13.4.json | 9 +- docs/api/controls/HRS-13.json | 9 +- docs/api/controls/HRS-14.1.json | 5 +- docs/api/controls/HRS-14.json | 7 +- docs/api/controls/HRS-15.json | 3 +- docs/api/controls/IAC-01.1.json | 10 +- docs/api/controls/IAC-01.2.json | 67 +- docs/api/controls/IAC-01.3.json | 3 +- docs/api/controls/IAC-01.4.json | 107 + docs/api/controls/IAC-01.json | 147 +- docs/api/controls/IAC-02.1.json | 16 +- docs/api/controls/IAC-02.2.json | 11 +- docs/api/controls/IAC-02.3.json | 7 +- docs/api/controls/IAC-02.4.json | 7 +- docs/api/controls/IAC-02.json | 53 +- docs/api/controls/IAC-03.1.json | 5 +- docs/api/controls/IAC-03.2.json | 11 +- docs/api/controls/IAC-03.3.json | 7 +- docs/api/controls/IAC-03.4.json | 5 +- docs/api/controls/IAC-03.5.json | 5 +- docs/api/controls/IAC-03.json | 45 +- docs/api/controls/IAC-04.1.json | 13 +- docs/api/controls/IAC-04.2.json | 5 +- docs/api/controls/IAC-04.json | 30 +- docs/api/controls/IAC-05.1.json | 7 +- docs/api/controls/IAC-05.2.json | 6 +- docs/api/controls/IAC-05.json | 32 +- docs/api/controls/IAC-06.1.json | 21 +- docs/api/controls/IAC-06.2.json | 20 +- docs/api/controls/IAC-06.3.json | 26 +- docs/api/controls/IAC-06.4.json | 15 +- docs/api/controls/IAC-06.5.json | 3 +- docs/api/controls/IAC-06.json | 68 +- docs/api/controls/IAC-07.1.json | 35 +- docs/api/controls/IAC-07.2.json | 24 +- docs/api/controls/IAC-07.json | 62 +- docs/api/controls/IAC-08.json | 118 +- docs/api/controls/IAC-09.1.json | 16 +- docs/api/controls/IAC-09.2.json | 18 +- docs/api/controls/IAC-09.3.json | 7 +- docs/api/controls/IAC-09.4.json | 8 +- docs/api/controls/IAC-09.5.json | 15 +- docs/api/controls/IAC-09.6.json | 28 +- docs/api/controls/IAC-09.json | 19 +- docs/api/controls/IAC-10.1.json | 62 +- docs/api/controls/IAC-10.10.json | 9 +- docs/api/controls/IAC-10.11.json | 28 +- docs/api/controls/IAC-10.12.json | 3 +- docs/api/controls/IAC-10.13.json | 3 +- docs/api/controls/IAC-10.14.json | 3 +- docs/api/controls/IAC-10.2.json | 12 +- docs/api/controls/IAC-10.3.json | 6 +- docs/api/controls/IAC-10.4.json | 26 +- docs/api/controls/IAC-10.5.json | 30 +- docs/api/controls/IAC-10.6.json | 18 +- docs/api/controls/IAC-10.7.json | 3 +- docs/api/controls/IAC-10.8.json | 24 +- docs/api/controls/IAC-10.9.json | 5 +- docs/api/controls/IAC-10.json | 50 +- docs/api/controls/IAC-11.json | 10 +- docs/api/controls/IAC-12.1.json | 7 +- docs/api/controls/IAC-12.json | 10 +- docs/api/controls/IAC-13.1.json | 7 +- docs/api/controls/IAC-13.2.json | 5 +- docs/api/controls/IAC-13.3.json | 3 +- docs/api/controls/IAC-13.json | 5 +- docs/api/controls/IAC-14.json | 7 +- docs/api/controls/IAC-15.1.json | 64 +- docs/api/controls/IAC-15.10.json | 97 + docs/api/controls/IAC-15.2.json | 20 +- docs/api/controls/IAC-15.3.json | 20 +- docs/api/controls/IAC-15.4.json | 17 +- docs/api/controls/IAC-15.5.json | 21 +- docs/api/controls/IAC-15.6.json | 11 +- docs/api/controls/IAC-15.7.json | 27 +- docs/api/controls/IAC-15.8.json | 7 +- docs/api/controls/IAC-15.9.json | 14 +- docs/api/controls/IAC-15.json | 103 +- docs/api/controls/IAC-16.1.json | 16 +- docs/api/controls/IAC-16.2.json | 6 +- docs/api/controls/IAC-16.3.json | 5 +- docs/api/controls/IAC-16.4.json | 14 +- docs/api/controls/IAC-16.5.json | 6 +- docs/api/controls/IAC-16.json | 68 +- docs/api/controls/IAC-17.json | 53 +- docs/api/controls/IAC-18.json | 13 +- docs/api/controls/IAC-19.json | 12 +- docs/api/controls/IAC-20.1.json | 33 +- docs/api/controls/IAC-20.2.json | 17 +- docs/api/controls/IAC-20.3.json | 11 +- docs/api/controls/IAC-20.4.json | 13 +- docs/api/controls/IAC-20.5.json | 13 +- docs/api/controls/IAC-20.6.json | 5 +- docs/api/controls/IAC-20.7.json | 3 +- docs/api/controls/IAC-20.json | 34 +- docs/api/controls/IAC-21.1.json | 3 +- docs/api/controls/IAC-21.2.json | 12 +- docs/api/controls/IAC-21.3.json | 13 +- docs/api/controls/IAC-21.4.json | 8 +- docs/api/controls/IAC-21.5.json | 10 +- docs/api/controls/IAC-21.6.json | 9 +- docs/api/controls/IAC-21.7.json | 5 +- docs/api/controls/IAC-21.json | 92 +- docs/api/controls/IAC-22.json | 27 +- docs/api/controls/IAC-23.json | 22 +- docs/api/controls/IAC-24.1.json | 8 +- docs/api/controls/IAC-24.json | 23 +- docs/api/controls/IAC-25.1.json | 7 +- docs/api/controls/IAC-25.json | 20 +- docs/api/controls/IAC-26.json | 7 +- docs/api/controls/IAC-27.json | 5 +- docs/api/controls/IAC-28.1.json | 33 +- docs/api/controls/IAC-28.2.json | 11 +- docs/api/controls/IAC-28.3.json | 9 +- docs/api/controls/IAC-28.4.json | 5 +- docs/api/controls/IAC-28.5.json | 5 +- docs/api/controls/IAC-28.json | 33 +- docs/api/controls/IAC-29.1.json | 7 +- docs/api/controls/IAC-29.2.json | 7 +- docs/api/controls/IAC-29.json | 20 +- docs/api/controls/IAC-30.json | 6 +- docs/api/controls/IAO-01.1.json | 45 +- docs/api/controls/IAO-01.json | 108 +- docs/api/controls/IAO-02.1.json | 25 +- docs/api/controls/IAO-02.2.json | 74 +- docs/api/controls/IAO-02.3.json | 14 +- docs/api/controls/IAO-02.4.json | 27 +- docs/api/controls/IAO-02.json | 106 +- docs/api/controls/IAO-03.1.json | 7 +- docs/api/controls/IAO-03.2.json | 61 +- docs/api/controls/IAO-03.json | 134 +- docs/api/controls/IAO-04.json | 41 +- docs/api/controls/IAO-05.1.json | 4 +- docs/api/controls/IAO-05.json | 51 +- docs/api/controls/IAO-06.json | 44 +- docs/api/controls/IAO-07.json | 52 +- docs/api/controls/IRO-01.json | 129 +- docs/api/controls/IRO-02.1.json | 10 +- docs/api/controls/IRO-02.2.json | 9 +- docs/api/controls/IRO-02.3.json | 5 +- docs/api/controls/IRO-02.4.json | 32 +- docs/api/controls/IRO-02.5.json | 13 +- docs/api/controls/IRO-02.6.json | 7 +- docs/api/controls/IRO-02.json | 182 +- docs/api/controls/IRO-03.json | 31 +- docs/api/controls/IRO-04.1.json | 115 +- docs/api/controls/IRO-04.2.json | 10 +- docs/api/controls/IRO-04.3.json | 15 +- docs/api/controls/IRO-04.json | 113 +- docs/api/controls/IRO-05.1.json | 8 +- docs/api/controls/IRO-05.2.json | 3 +- docs/api/controls/IRO-05.json | 28 +- docs/api/controls/IRO-06.1.json | 22 +- docs/api/controls/IRO-06.json | 62 +- docs/api/controls/IRO-07.json | 77 +- docs/api/controls/IRO-08.1.json | 4 +- docs/api/controls/IRO-08.json | 18 +- docs/api/controls/IRO-09.1.json | 21 +- docs/api/controls/IRO-09.2.json | 3 +- docs/api/controls/IRO-09.3.json | 6 +- docs/api/controls/IRO-09.4.json | 6 +- docs/api/controls/IRO-09.json | 41 +- docs/api/controls/IRO-10.1.json | 5 +- docs/api/controls/IRO-10.2.json | 107 +- docs/api/controls/IRO-10.3.json | 8 +- docs/api/controls/IRO-10.4.json | 10 +- docs/api/controls/IRO-10.5.json | 40 +- docs/api/controls/IRO-10.json | 305 +- docs/api/controls/IRO-11.1.json | 5 +- docs/api/controls/IRO-11.2.json | 13 +- docs/api/controls/IRO-11.json | 10 +- docs/api/controls/IRO-12.1.json | 9 +- docs/api/controls/IRO-12.2.json | 9 +- docs/api/controls/IRO-12.3.json | 14 +- docs/api/controls/IRO-12.4.json | 13 +- docs/api/controls/IRO-12.json | 23 +- docs/api/controls/IRO-13.json | 38 +- docs/api/controls/IRO-14.json | 26 +- docs/api/controls/IRO-15.json | 26 +- docs/api/controls/IRO-16.json | 10 +- docs/api/controls/MDM-01.json | 85 +- docs/api/controls/MDM-02.json | 28 +- docs/api/controls/MDM-03.json | 22 +- docs/api/controls/MDM-04.json | 15 +- docs/api/controls/MDM-05.json | 28 +- docs/api/controls/MDM-06.json | 29 +- docs/api/controls/MDM-07.json | 20 +- docs/api/controls/MDM-08.json | 5 +- docs/api/controls/MDM-09.json | 5 +- docs/api/controls/MDM-10.json | 7 +- docs/api/controls/MDM-11.json | 11 +- docs/api/controls/MNT-01.json | 48 +- docs/api/controls/MNT-02.1.json | 3 +- docs/api/controls/MNT-02.json | 26 +- docs/api/controls/MNT-03.1.json | 10 +- docs/api/controls/MNT-03.2.json | 7 +- docs/api/controls/MNT-03.3.json | 5 +- docs/api/controls/MNT-03.json | 11 +- docs/api/controls/MNT-04.1.json | 10 +- docs/api/controls/MNT-04.2.json | 7 +- docs/api/controls/MNT-04.3.json | 12 +- docs/api/controls/MNT-04.4.json | 5 +- docs/api/controls/MNT-04.json | 13 +- docs/api/controls/MNT-05.1.json | 13 +- docs/api/controls/MNT-05.2.json | 8 +- docs/api/controls/MNT-05.3.json | 13 +- docs/api/controls/MNT-05.4.json | 10 +- docs/api/controls/MNT-05.5.json | 11 +- docs/api/controls/MNT-05.6.json | 5 +- docs/api/controls/MNT-05.7.json | 3 +- docs/api/controls/MNT-05.json | 22 +- docs/api/controls/MNT-06.1.json | 18 +- docs/api/controls/MNT-06.2.json | 10 +- docs/api/controls/MNT-06.json | 16 +- docs/api/controls/MNT-07.json | 5 +- docs/api/controls/MNT-08.json | 7 +- docs/api/controls/MNT-09.json | 10 +- docs/api/controls/MNT-10.json | 8 +- docs/api/controls/MNT-11.json | 3 +- docs/api/controls/MON-01.1.json | 26 +- docs/api/controls/MON-01.10.json | 5 +- docs/api/controls/MON-01.11.json | 9 +- docs/api/controls/MON-01.12.json | 19 +- docs/api/controls/MON-01.13.json | 7 +- docs/api/controls/MON-01.14.json | 15 +- docs/api/controls/MON-01.15.json | 28 +- docs/api/controls/MON-01.16.json | 87 +- docs/api/controls/MON-01.17.json | 5 +- docs/api/controls/MON-01.2.json | 39 +- docs/api/controls/MON-01.3.json | 23 +- docs/api/controls/MON-01.4.json | 67 +- docs/api/controls/MON-01.5.json | 15 +- docs/api/controls/MON-01.6.json | 3 +- docs/api/controls/MON-01.7.json | 25 +- docs/api/controls/MON-01.8.json | 68 +- docs/api/controls/MON-01.9.json | 11 +- docs/api/controls/MON-01.json | 139 +- docs/api/controls/MON-02.1.json | 51 +- docs/api/controls/MON-02.2.json | 44 +- docs/api/controls/MON-02.3.json | 30 +- docs/api/controls/MON-02.4.json | 9 +- docs/api/controls/MON-02.5.json | 10 +- docs/api/controls/MON-02.6.json | 20 +- docs/api/controls/MON-02.7.json | 18 +- docs/api/controls/MON-02.8.json | 10 +- docs/api/controls/MON-02.9.json | 3 +- docs/api/controls/MON-02.json | 72 +- docs/api/controls/MON-03.1.json | 17 +- docs/api/controls/MON-03.2.json | 22 +- docs/api/controls/MON-03.3.json | 23 +- docs/api/controls/MON-03.4.json | 7 +- docs/api/controls/MON-03.5.json | 5 +- docs/api/controls/MON-03.6.json | 19 +- docs/api/controls/MON-03.7.json | 10 +- docs/api/controls/MON-03.json | 54 +- docs/api/controls/MON-04.json | 17 +- docs/api/controls/MON-05.1.json | 18 +- docs/api/controls/MON-05.2.json | 5 +- docs/api/controls/MON-05.json | 22 +- docs/api/controls/MON-06.1.json | 5 +- docs/api/controls/MON-06.2.json | 3 +- docs/api/controls/MON-06.json | 22 +- docs/api/controls/MON-07.1.json | 10 +- docs/api/controls/MON-07.json | 12 +- docs/api/controls/MON-08.1.json | 17 +- docs/api/controls/MON-08.2.json | 17 +- docs/api/controls/MON-08.3.json | 13 +- docs/api/controls/MON-08.4.json | 11 +- docs/api/controls/MON-08.json | 39 +- docs/api/controls/MON-09.1.json | 3 +- docs/api/controls/MON-09.json | 26 +- docs/api/controls/MON-10.json | 50 +- docs/api/controls/MON-11.1.json | 7 +- docs/api/controls/MON-11.2.json | 9 +- docs/api/controls/MON-11.3.json | 47 +- docs/api/controls/MON-11.json | 15 +- docs/api/controls/MON-12.json | 7 +- docs/api/controls/MON-13.json | 6 +- docs/api/controls/MON-14.1.json | 5 +- docs/api/controls/MON-14.json | 5 +- docs/api/controls/MON-15.json | 8 +- docs/api/controls/MON-16.1.json | 11 +- docs/api/controls/MON-16.2.json | 6 +- docs/api/controls/MON-16.3.json | 12 +- docs/api/controls/MON-16.4.json | 9 +- docs/api/controls/MON-16.json | 63 +- docs/api/controls/MON-17.1.json | 5 +- docs/api/controls/MON-17.json | 5 +- docs/api/controls/MON-18.json | 7 +- docs/api/controls/MON-19.json | 6 +- docs/api/controls/NET-01.1.json | 11 +- docs/api/controls/NET-01.json | 111 +- docs/api/controls/NET-02.1.json | 41 +- docs/api/controls/NET-02.2.json | 12 +- docs/api/controls/NET-02.3.json | 25 +- docs/api/controls/NET-02.json | 37 +- docs/api/controls/NET-03.1.json | 16 +- docs/api/controls/NET-03.2.json | 11 +- docs/api/controls/NET-03.3.json | 12 +- docs/api/controls/NET-03.4.json | 5 +- docs/api/controls/NET-03.5.json | 11 +- docs/api/controls/NET-03.6.json | 14 +- docs/api/controls/NET-03.7.json | 22 +- docs/api/controls/NET-03.8.json | 22 +- docs/api/controls/NET-03.json | 58 +- docs/api/controls/NET-04.1.json | 32 +- docs/api/controls/NET-04.10.json | 11 +- docs/api/controls/NET-04.11.json | 7 +- docs/api/controls/NET-04.12.json | 5 +- docs/api/controls/NET-04.13.json | 5 +- docs/api/controls/NET-04.14.json | 7 +- docs/api/controls/NET-04.2.json | 15 +- docs/api/controls/NET-04.3.json | 10 +- docs/api/controls/NET-04.4.json | 10 +- docs/api/controls/NET-04.5.json | 11 +- docs/api/controls/NET-04.6.json | 17 +- docs/api/controls/NET-04.7.json | 19 +- docs/api/controls/NET-04.8.json | 16 +- docs/api/controls/NET-04.9.json | 11 +- docs/api/controls/NET-04.json | 41 +- docs/api/controls/NET-05.1.json | 18 +- docs/api/controls/NET-05.2.json | 20 +- docs/api/controls/NET-05.json | 26 +- docs/api/controls/NET-06.1.json | 25 +- docs/api/controls/NET-06.2.json | 22 +- docs/api/controls/NET-06.3.json | 30 +- docs/api/controls/NET-06.4.json | 24 +- docs/api/controls/NET-06.5.json | 18 +- docs/api/controls/NET-06.6.json | 7 +- docs/api/controls/NET-06.7.json | 7 +- docs/api/controls/NET-06.8.json | 100 + docs/api/controls/NET-06.9.json | 116 + docs/api/controls/NET-06.json | 70 +- docs/api/controls/NET-07.json | 15 +- docs/api/controls/NET-08.1.json | 13 +- docs/api/controls/NET-08.2.json | 26 +- docs/api/controls/NET-08.3.json | 5 +- docs/api/controls/NET-08.4.json | 5 +- docs/api/controls/NET-08.json | 46 +- docs/api/controls/NET-09.1.json | 10 +- docs/api/controls/NET-09.2.json | 3 +- docs/api/controls/NET-09.json | 15 +- docs/api/controls/NET-10.1.json | 15 +- docs/api/controls/NET-10.2.json | 12 +- docs/api/controls/NET-10.3.json | 23 +- docs/api/controls/NET-10.4.json | 7 +- docs/api/controls/NET-10.json | 24 +- docs/api/controls/NET-11.json | 10 +- docs/api/controls/NET-12.1.json | 5 +- docs/api/controls/NET-12.2.json | 11 +- docs/api/controls/NET-12.json | 19 +- docs/api/controls/NET-13.json | 30 +- docs/api/controls/NET-14.1.json | 24 +- docs/api/controls/NET-14.2.json | 17 +- docs/api/controls/NET-14.3.json | 13 +- docs/api/controls/NET-14.4.json | 11 +- docs/api/controls/NET-14.5.json | 27 +- docs/api/controls/NET-14.6.json | 8 +- docs/api/controls/NET-14.7.json | 5 +- docs/api/controls/NET-14.8.json | 7 +- docs/api/controls/NET-14.json | 40 +- docs/api/controls/NET-15.1.json | 14 +- docs/api/controls/NET-15.2.json | 15 +- docs/api/controls/NET-15.3.json | 12 +- docs/api/controls/NET-15.4.json | 10 +- docs/api/controls/NET-15.5.json | 13 +- docs/api/controls/NET-15.json | 26 +- docs/api/controls/NET-16.json | 7 +- docs/api/controls/NET-17.json | 28 +- docs/api/controls/NET-18.1.json | 23 +- docs/api/controls/NET-18.2.json | 10 +- docs/api/controls/NET-18.3.json | 5 +- docs/api/controls/NET-18.4.json | 5 +- docs/api/controls/NET-18.5.json | 5 +- docs/api/controls/NET-18.6.json | 5 +- docs/api/controls/NET-18.7.json | 5 +- docs/api/controls/NET-18.8.json | 5 +- docs/api/controls/NET-18.9.json | 5 +- docs/api/controls/NET-18.json | 60 +- docs/api/controls/NET-19.json | 7 +- docs/api/controls/NET-20.1.json | 5 +- docs/api/controls/NET-20.2.json | 5 +- docs/api/controls/NET-20.3.json | 5 +- docs/api/controls/NET-20.4.json | 16 +- docs/api/controls/NET-20.5.json | 5 +- docs/api/controls/NET-20.6.json | 5 +- docs/api/controls/NET-20.7.json | 7 +- docs/api/controls/NET-20.8.json | 3 +- docs/api/controls/NET-20.9.json | 3 +- docs/api/controls/NET-20.json | 5 +- docs/api/controls/OPS-01.1.json | 128 +- docs/api/controls/OPS-01.json | 52 +- docs/api/controls/OPS-02.json | 16 +- docs/api/controls/OPS-03.json | 45 +- docs/api/controls/OPS-04.json | 20 +- docs/api/controls/OPS-05.json | 12 +- docs/api/controls/OPS-06.json | 9 +- docs/api/controls/OPS-07.json | 12 +- docs/api/controls/PES-01.1.json | 17 +- docs/api/controls/PES-01.2.json | 7 +- docs/api/controls/PES-01.json | 116 +- docs/api/controls/PES-02.1.json | 45 +- docs/api/controls/PES-02.2.json | 5 +- docs/api/controls/PES-02.json | 53 +- docs/api/controls/PES-03.1.json | 35 +- docs/api/controls/PES-03.2.json | 17 +- docs/api/controls/PES-03.3.json | 22 +- docs/api/controls/PES-03.4.json | 32 +- docs/api/controls/PES-03.json | 66 +- docs/api/controls/PES-04.1.json | 43 +- docs/api/controls/PES-04.2.json | 5 +- docs/api/controls/PES-04.3.json | 3 +- docs/api/controls/PES-04.json | 50 +- docs/api/controls/PES-05.1.json | 32 +- docs/api/controls/PES-05.2.json | 22 +- docs/api/controls/PES-05.json | 27 +- docs/api/controls/PES-06.1.json | 17 +- docs/api/controls/PES-06.2.json | 14 +- docs/api/controls/PES-06.3.json | 17 +- docs/api/controls/PES-06.4.json | 5 +- docs/api/controls/PES-06.5.json | 5 +- docs/api/controls/PES-06.6.json | 10 +- docs/api/controls/PES-06.json | 47 +- docs/api/controls/PES-07.1.json | 11 +- docs/api/controls/PES-07.2.json | 6 +- docs/api/controls/PES-07.3.json | 13 +- docs/api/controls/PES-07.4.json | 12 +- docs/api/controls/PES-07.5.json | 16 +- docs/api/controls/PES-07.6.json | 10 +- docs/api/controls/PES-07.7.json | 6 +- docs/api/controls/PES-07.json | 27 +- docs/api/controls/PES-08.1.json | 13 +- docs/api/controls/PES-08.2.json | 15 +- docs/api/controls/PES-08.3.json | 6 +- docs/api/controls/PES-08.json | 26 +- docs/api/controls/PES-09.1.json | 12 +- docs/api/controls/PES-09.json | 12 +- docs/api/controls/PES-10.json | 26 +- docs/api/controls/PES-11.json | 9 +- docs/api/controls/PES-12.1.json | 19 +- docs/api/controls/PES-12.2.json | 13 +- docs/api/controls/PES-12.json | 28 +- docs/api/controls/PES-13.json | 9 +- docs/api/controls/PES-14.json | 7 +- docs/api/controls/PES-15.json | 3 +- docs/api/controls/PES-16.json | 7 +- docs/api/controls/PES-17.json | 5 +- docs/api/controls/PES-18.json | 15 +- docs/api/controls/PES-19.json | 5 +- docs/api/controls/PRI-01.1.json | 87 +- docs/api/controls/PRI-01.10.json | 5 +- docs/api/controls/PRI-01.11.json | 603 +- docs/api/controls/PRI-01.12.json | 98 + docs/api/controls/PRI-01.2.json | 9 +- docs/api/controls/PRI-01.3.json | 23 +- docs/api/controls/PRI-01.4.json | 204 +- docs/api/controls/PRI-01.5.json | 344 +- docs/api/controls/PRI-01.6.json | 392 +- docs/api/controls/PRI-01.7.json | 48 +- docs/api/controls/PRI-01.8.json | 5 +- docs/api/controls/PRI-01.9.json | 10 +- docs/api/controls/PRI-01.json | 247 +- docs/api/controls/PRI-02.1.json | 162 +- docs/api/controls/PRI-02.10.json | 5 +- docs/api/controls/PRI-02.11.json | 5 +- docs/api/controls/PRI-02.12.json | 7 +- docs/api/controls/PRI-02.13.json | 13 +- docs/api/controls/PRI-02.14.json | 5 +- docs/api/controls/PRI-02.2.json | 44 +- docs/api/controls/PRI-02.3.json | 8 +- docs/api/controls/PRI-02.4.json | 8 +- docs/api/controls/PRI-02.5.json | 8 +- docs/api/controls/PRI-02.6.json | 8 +- docs/api/controls/PRI-02.7.json | 5 +- docs/api/controls/PRI-02.8.json | 8 +- docs/api/controls/PRI-02.9.json | 5 +- docs/api/controls/PRI-02.json | 666 +- docs/api/controls/PRI-03.1.json | 27 +- docs/api/controls/PRI-03.10.json | 19 +- docs/api/controls/PRI-03.11.json | 16 +- docs/api/controls/PRI-03.12.json | 8 +- docs/api/controls/PRI-03.13.json | 41 +- docs/api/controls/PRI-03.2.json | 59 +- docs/api/controls/PRI-03.3.json | 60 +- docs/api/controls/PRI-03.4.json | 84 +- docs/api/controls/PRI-03.5.json | 28 +- docs/api/controls/PRI-03.6.json | 49 +- docs/api/controls/PRI-03.7.json | 17 +- docs/api/controls/PRI-03.8.json | 8 +- docs/api/controls/PRI-03.9.json | 32 +- docs/api/controls/PRI-03.json | 311 +- docs/api/controls/PRI-04.1.json | 246 +- docs/api/controls/PRI-04.2.json | 39 +- docs/api/controls/PRI-04.3.json | 11 +- docs/api/controls/PRI-04.4.json | 16 +- docs/api/controls/PRI-04.5.json | 5 +- docs/api/controls/PRI-04.6.json | 5 +- docs/api/controls/PRI-04.7.json | 6 +- docs/api/controls/PRI-04.json | 204 +- docs/api/controls/PRI-05.1.json | 169 +- docs/api/controls/PRI-05.2.json | 104 +- docs/api/controls/PRI-05.3.json | 40 +- docs/api/controls/PRI-05.4.json | 815 +- docs/api/controls/PRI-05.5.json | 18 +- docs/api/controls/PRI-05.6.json | 11 +- docs/api/controls/PRI-05.7.json | 66 +- docs/api/controls/PRI-05.8.json | 5 +- docs/api/controls/PRI-05.json | 261 +- docs/api/controls/PRI-06.1.json | 205 +- docs/api/controls/PRI-06.2.json | 170 +- docs/api/controls/PRI-06.3.json | 64 +- docs/api/controls/PRI-06.4.json | 417 +- docs/api/controls/PRI-06.5.json | 100 +- docs/api/controls/PRI-06.6.json | 58 +- docs/api/controls/PRI-06.7.json | 52 +- docs/api/controls/PRI-06.8.json | 43 +- docs/api/controls/PRI-06.json | 522 +- docs/api/controls/PRI-07.1.json | 274 +- docs/api/controls/PRI-07.2.json | 95 +- docs/api/controls/PRI-07.3.json | 64 +- docs/api/controls/PRI-07.4.json | 95 +- docs/api/controls/PRI-07.5.json | 83 +- docs/api/controls/PRI-07.json | 215 +- docs/api/controls/PRI-08.json | 14 +- docs/api/controls/PRI-09.json | 14 +- docs/api/controls/PRI-10.1.json | 8 +- docs/api/controls/PRI-10.2.json | 11 +- docs/api/controls/PRI-10.json | 34 +- docs/api/controls/PRI-11.json | 13 +- docs/api/controls/PRI-12.1.json | 8 +- docs/api/controls/PRI-12.json | 17 +- docs/api/controls/PRI-13.json | 8 +- docs/api/controls/PRI-14.1.json | 120 +- docs/api/controls/PRI-14.2.json | 26 +- docs/api/controls/PRI-14.json | 222 +- docs/api/controls/PRI-15.json | 155 +- docs/api/controls/PRI-16.json | 37 +- docs/api/controls/PRI-17.1.json | 8 +- docs/api/controls/PRI-17.2.json | 8 +- docs/api/controls/PRI-17.3.json | 22 +- docs/api/controls/PRI-17.4.json | 5 +- docs/api/controls/PRI-17.5.json | 5 +- docs/api/controls/PRI-17.json | 88 +- docs/api/controls/PRI-18.json | 24 +- docs/api/controls/PRI-19.1.json | 11 +- docs/api/controls/PRI-19.2.json | 20 +- docs/api/controls/PRI-19.3.json | 27 +- docs/api/controls/PRI-19.json | 96 +- docs/api/controls/PRI-20.json | 5 +- docs/api/controls/PRI-21.1.json | 5 +- docs/api/controls/PRI-21.2.json | 12 +- docs/api/controls/PRI-21.json | 7 +- docs/api/controls/PRM-01.1.json | 64 +- docs/api/controls/PRM-01.2.json | 17 +- docs/api/controls/PRM-01.json | 73 +- docs/api/controls/PRM-02.1.json | 40 +- docs/api/controls/PRM-02.json | 51 +- docs/api/controls/PRM-03.json | 37 +- docs/api/controls/PRM-04.json | 126 +- docs/api/controls/PRM-05.json | 114 +- docs/api/controls/PRM-06.json | 52 +- docs/api/controls/PRM-07.json | 82 +- docs/api/controls/PRM-08.json | 9 +- docs/api/controls/QTS-01.1.json | 97 + docs/api/controls/QTS-01.2.json | 96 + docs/api/controls/QTS-01.3.json | 96 + docs/api/controls/QTS-01.4.json | 97 + docs/api/controls/QTS-01.json | 98 + docs/api/controls/QTS-02.1.json | 96 + docs/api/controls/QTS-02.2.json | 97 + docs/api/controls/QTS-02.3.json | 98 + docs/api/controls/QTS-02.json | 100 + docs/api/controls/QTS-03.1.json | 97 + docs/api/controls/QTS-03.2.json | 94 + docs/api/controls/QTS-03.3.json | 97 + docs/api/controls/QTS-03.4.json | 95 + docs/api/controls/QTS-03.json | 105 + docs/api/controls/QTS-04.1.json | 96 + docs/api/controls/QTS-04.2.json | 100 + docs/api/controls/QTS-04.3.json | 96 + docs/api/controls/QTS-04.json | 100 + docs/api/controls/QTS-05.1.json | 100 + docs/api/controls/QTS-05.2.json | 96 + docs/api/controls/QTS-05.json | 98 + docs/api/controls/QTS-06.1.json | 95 + docs/api/controls/QTS-06.10.json | 94 + docs/api/controls/QTS-06.2.json | 95 + docs/api/controls/QTS-06.3.json | 106 + docs/api/controls/QTS-06.4.json | 95 + docs/api/controls/QTS-06.5.json | 101 + docs/api/controls/QTS-06.6.json | 95 + docs/api/controls/QTS-06.7.json | 95 + docs/api/controls/QTS-06.8.json | 95 + docs/api/controls/QTS-06.9.json | 98 + docs/api/controls/QTS-06.json | 102 + docs/api/controls/QTS-07.json | 96 + docs/api/controls/QTS-08.json | 94 + docs/api/controls/RSK-01.1.json | 43 +- docs/api/controls/RSK-01.2.json | 5 +- docs/api/controls/RSK-01.3.json | 27 +- docs/api/controls/RSK-01.4.json | 17 +- docs/api/controls/RSK-01.5.json | 26 +- docs/api/controls/RSK-01.json | 165 +- docs/api/controls/RSK-02.1.json | 23 +- docs/api/controls/RSK-02.json | 26 +- docs/api/controls/RSK-03.1.json | 24 +- docs/api/controls/RSK-03.2.json | 104 + docs/api/controls/RSK-03.json | 60 +- docs/api/controls/RSK-04.1.json | 56 +- docs/api/controls/RSK-04.2.json | 31 +- docs/api/controls/RSK-04.3.json | 11 +- docs/api/controls/RSK-04.4.json | 9 +- docs/api/controls/RSK-04.json | 108 +- docs/api/controls/RSK-05.json | 31 +- docs/api/controls/RSK-06.1.json | 44 +- docs/api/controls/RSK-06.2.json | 64 +- docs/api/controls/RSK-06.3.json | 44 +- docs/api/controls/RSK-06.4.json | 34 +- docs/api/controls/RSK-06.json | 64 +- docs/api/controls/RSK-07.json | 26 +- docs/api/controls/RSK-08.json | 46 +- docs/api/controls/RSK-09.1.json | 30 +- docs/api/controls/RSK-09.2.json | 3 +- docs/api/controls/RSK-09.json | 38 +- docs/api/controls/RSK-10.json | 154 +- docs/api/controls/RSK-11.json | 22 +- docs/api/controls/RSK-12.json | 5 +- docs/api/controls/RSK-13.1.json | 5 +- docs/api/controls/RSK-13.2.json | 3 +- docs/api/controls/RSK-13.json | 16 +- docs/api/controls/SAT-01.1.json | 52 +- docs/api/controls/SAT-01.json | 105 +- docs/api/controls/SAT-02.1.json | 13 +- docs/api/controls/SAT-02.2.json | 28 +- docs/api/controls/SAT-02.json | 104 +- docs/api/controls/SAT-03.1.json | 15 +- docs/api/controls/SAT-03.2.json | 36 +- docs/api/controls/SAT-03.3.json | 44 +- docs/api/controls/SAT-03.4.json | 9 +- docs/api/controls/SAT-03.5.json | 29 +- docs/api/controls/SAT-03.6.json | 55 +- docs/api/controls/SAT-03.7.json | 16 +- docs/api/controls/SAT-03.8.json | 10 +- docs/api/controls/SAT-03.9.json | 3 +- docs/api/controls/SAT-03.json | 127 +- docs/api/controls/SAT-04.1.json | 78 + docs/api/controls/SAT-04.json | 10 +- docs/api/controls/SAT-05.json | 12 +- docs/api/controls/SEA-01.1.json | 28 +- docs/api/controls/SEA-01.2.json | 18 +- docs/api/controls/SEA-01.3.json | 15 +- docs/api/controls/SEA-01.4.json | 132 + docs/api/controls/SEA-01.5.json | 106 + docs/api/controls/SEA-01.json | 244 +- docs/api/controls/SEA-02.1.json | 41 +- docs/api/controls/SEA-02.2.json | 11 +- docs/api/controls/SEA-02.3.json | 5 +- docs/api/controls/SEA-02.json | 236 +- docs/api/controls/SEA-03.1.json | 17 +- docs/api/controls/SEA-03.2.json | 9 +- docs/api/controls/SEA-03.json | 215 +- docs/api/controls/SEA-04.1.json | 9 +- docs/api/controls/SEA-04.2.json | 7 +- docs/api/controls/SEA-04.3.json | 7 +- docs/api/controls/SEA-04.4.json | 5 +- docs/api/controls/SEA-04.json | 9 +- docs/api/controls/SEA-05.json | 20 +- docs/api/controls/SEA-06.json | 7 +- docs/api/controls/SEA-07.1.json | 30 +- docs/api/controls/SEA-07.2.json | 12 +- docs/api/controls/SEA-07.3.json | 9 +- docs/api/controls/SEA-07.json | 8 +- docs/api/controls/SEA-08.1.json | 16 +- docs/api/controls/SEA-08.2.json | 83 + docs/api/controls/SEA-08.json | 18 +- docs/api/controls/SEA-09.1.json | 5 +- docs/api/controls/SEA-09.json | 9 +- docs/api/controls/SEA-10.json | 15 +- docs/api/controls/SEA-11.json | 20 +- docs/api/controls/SEA-12.json | 12 +- docs/api/controls/SEA-13.1.json | 50 +- docs/api/controls/SEA-13.json | 16 +- docs/api/controls/SEA-14.1.json | 11 +- docs/api/controls/SEA-14.2.json | 12 +- docs/api/controls/SEA-14.json | 16 +- docs/api/controls/SEA-15.json | 75 +- docs/api/controls/SEA-16.json | 7 +- docs/api/controls/SEA-17.json | 9 +- docs/api/controls/SEA-18.1.json | 13 +- docs/api/controls/SEA-18.2.json | 13 +- docs/api/controls/SEA-18.json | 15 +- docs/api/controls/SEA-19.json | 14 +- docs/api/controls/SEA-20.json | 15 +- docs/api/controls/SEA-21.json | 5 +- docs/api/controls/SEA-22.json | 9 +- docs/api/controls/TDA-01.1.json | 164 +- docs/api/controls/TDA-01.2.json | 11 +- docs/api/controls/TDA-01.3.json | 12 +- docs/api/controls/TDA-01.4.json | 10 +- docs/api/controls/TDA-01.json | 142 +- docs/api/controls/TDA-02.1.json | 15 +- docs/api/controls/TDA-02.10.json | 16 +- docs/api/controls/TDA-02.11.json | 29 +- docs/api/controls/TDA-02.12.json | 49 +- docs/api/controls/TDA-02.13.json | 8 +- docs/api/controls/TDA-02.14.json | 5 +- docs/api/controls/TDA-02.2.json | 5 +- docs/api/controls/TDA-02.3.json | 30 +- docs/api/controls/TDA-02.4.json | 25 +- docs/api/controls/TDA-02.5.json | 7 +- docs/api/controls/TDA-02.6.json | 10 +- docs/api/controls/TDA-02.7.json | 13 +- docs/api/controls/TDA-02.8.json | 14 +- docs/api/controls/TDA-02.9.json | 32 +- docs/api/controls/TDA-02.json | 46 +- docs/api/controls/TDA-03.1.json | 12 +- docs/api/controls/TDA-03.json | 14 +- docs/api/controls/TDA-04.1.json | 22 +- docs/api/controls/TDA-04.2.json | 22 +- docs/api/controls/TDA-04.json | 31 +- docs/api/controls/TDA-05.1.json | 5 +- docs/api/controls/TDA-05.2.json | 5 +- docs/api/controls/TDA-05.json | 54 +- docs/api/controls/TDA-06.1.json | 24 +- docs/api/controls/TDA-06.2.json | 22 +- docs/api/controls/TDA-06.3.json | 32 +- docs/api/controls/TDA-06.4.json | 8 +- docs/api/controls/TDA-06.5.json | 24 +- docs/api/controls/TDA-06.6.json | 8 +- docs/api/controls/TDA-06.7.json | 101 + docs/api/controls/TDA-06.json | 118 +- docs/api/controls/TDA-07.json | 28 +- docs/api/controls/TDA-08.1.json | 5 +- docs/api/controls/TDA-08.json | 41 +- docs/api/controls/TDA-09.1.json | 19 +- docs/api/controls/TDA-09.2.json | 22 +- docs/api/controls/TDA-09.3.json | 26 +- docs/api/controls/TDA-09.4.json | 20 +- docs/api/controls/TDA-09.5.json | 22 +- docs/api/controls/TDA-09.6.json | 15 +- docs/api/controls/TDA-09.7.json | 5 +- docs/api/controls/TDA-09.json | 82 +- docs/api/controls/TDA-10.1.json | 10 +- docs/api/controls/TDA-10.json | 13 +- docs/api/controls/TDA-11.1.json | 16 +- docs/api/controls/TDA-11.2.json | 4 +- docs/api/controls/TDA-11.json | 25 +- docs/api/controls/TDA-12.json | 5 +- docs/api/controls/TDA-13.1.json | 96 + docs/api/controls/TDA-13.2.json | 96 + docs/api/controls/TDA-13.json | 8 +- docs/api/controls/TDA-14.1.json | 15 +- docs/api/controls/TDA-14.2.json | 8 +- docs/api/controls/TDA-14.json | 14 +- docs/api/controls/TDA-15.json | 31 +- docs/api/controls/TDA-16.json | 10 +- docs/api/controls/TDA-17.1.json | 10 +- docs/api/controls/TDA-17.json | 41 +- docs/api/controls/TDA-18.json | 26 +- docs/api/controls/TDA-19.1.json | 90 + docs/api/controls/TDA-19.json | 20 +- docs/api/controls/TDA-20.1.json | 5 +- docs/api/controls/TDA-20.2.json | 8 +- docs/api/controls/TDA-20.3.json | 10 +- docs/api/controls/TDA-20.4.json | 5 +- docs/api/controls/TDA-20.json | 24 +- docs/api/controls/TDA-21.json | 9 +- docs/api/controls/TDA-22.1.json | 8 +- docs/api/controls/TDA-22.json | 34 +- docs/api/controls/THR-01.1.json | 107 + docs/api/controls/THR-01.2.json | 107 + docs/api/controls/THR-01.json | 68 +- docs/api/controls/THR-02.json | 19 +- docs/api/controls/THR-03.1.json | 28 +- docs/api/controls/THR-03.json | 61 +- docs/api/controls/THR-04.json | 7 +- docs/api/controls/THR-05.json | 7 +- docs/api/controls/THR-06.1.json | 9 +- docs/api/controls/THR-06.json | 28 +- docs/api/controls/THR-07.json | 22 +- docs/api/controls/THR-08.json | 11 +- docs/api/controls/THR-09.json | 27 +- docs/api/controls/THR-10.json | 34 +- docs/api/controls/THR-11.json | 8 +- docs/api/controls/TPM-01.1.json | 22 +- docs/api/controls/TPM-01.json | 152 +- docs/api/controls/TPM-02.json | 56 +- docs/api/controls/TPM-03.1.json | 32 +- docs/api/controls/TPM-03.2.json | 44 +- docs/api/controls/TPM-03.3.json | 16 +- docs/api/controls/TPM-03.4.json | 9 +- docs/api/controls/TPM-03.json | 81 +- docs/api/controls/TPM-04.1.json | 66 +- docs/api/controls/TPM-04.2.json | 6 +- docs/api/controls/TPM-04.3.json | 13 +- docs/api/controls/TPM-04.4.json | 88 +- docs/api/controls/TPM-04.json | 94 +- docs/api/controls/TPM-05.1.json | 42 +- docs/api/controls/TPM-05.2.json | 59 +- docs/api/controls/TPM-05.3.json | 5 +- docs/api/controls/TPM-05.4.json | 59 +- docs/api/controls/TPM-05.5.json | 30 +- docs/api/controls/TPM-05.6.json | 22 +- docs/api/controls/TPM-05.7.json | 21 +- docs/api/controls/TPM-05.8.json | 18 +- docs/api/controls/TPM-05.json | 279 +- docs/api/controls/TPM-06.json | 24 +- docs/api/controls/TPM-07.json | 20 +- docs/api/controls/TPM-08.json | 65 +- docs/api/controls/TPM-09.json | 29 +- docs/api/controls/TPM-10.json | 28 +- docs/api/controls/TPM-11.json | 14 +- docs/api/controls/TPM-12.1.json | 6 +- docs/api/controls/TPM-12.2.json | 6 +- docs/api/controls/TPM-12.json | 8 +- docs/api/controls/VPM-01.1.json | 34 +- docs/api/controls/VPM-01.json | 98 +- docs/api/controls/VPM-02.1.json | 111 + docs/api/controls/VPM-02.json | 71 +- docs/api/controls/VPM-03.1.json | 9 +- docs/api/controls/VPM-03.json | 36 +- docs/api/controls/VPM-04.1.json | 20 +- docs/api/controls/VPM-04.2.json | 16 +- docs/api/controls/VPM-04.3.json | 14 +- docs/api/controls/VPM-04.json | 56 +- docs/api/controls/VPM-05.1.json | 27 +- docs/api/controls/VPM-05.2.json | 11 +- docs/api/controls/VPM-05.3.json | 19 +- docs/api/controls/VPM-05.4.json | 22 +- docs/api/controls/VPM-05.5.json | 7 +- docs/api/controls/VPM-05.6.json | 11 +- docs/api/controls/VPM-05.7.json | 7 +- docs/api/controls/VPM-05.8.json | 9 +- docs/api/controls/VPM-05.json | 73 +- docs/api/controls/VPM-06.1.json | 12 +- docs/api/controls/VPM-06.2.json | 13 +- docs/api/controls/VPM-06.3.json | 10 +- docs/api/controls/VPM-06.4.json | 13 +- docs/api/controls/VPM-06.5.json | 13 +- docs/api/controls/VPM-06.6.json | 10 +- docs/api/controls/VPM-06.7.json | 11 +- docs/api/controls/VPM-06.8.json | 14 +- docs/api/controls/VPM-06.9.json | 3 +- docs/api/controls/VPM-06.json | 63 +- docs/api/controls/VPM-07.1.json | 15 +- docs/api/controls/VPM-07.json | 61 +- docs/api/controls/VPM-08.json | 5 +- docs/api/controls/VPM-09.json | 9 +- docs/api/controls/VPM-10.json | 17 +- docs/api/controls/WEB-01.1.json | 5 +- docs/api/controls/WEB-01.json | 24 +- docs/api/controls/WEB-02.json | 22 +- docs/api/controls/WEB-03.json | 18 +- docs/api/controls/WEB-04.json | 21 +- docs/api/controls/WEB-05.json | 5 +- docs/api/controls/WEB-06.json | 26 +- docs/api/controls/WEB-07.json | 21 +- docs/api/controls/WEB-08.json | 24 +- docs/api/controls/WEB-09.json | 7 +- docs/api/controls/WEB-10.json | 13 +- docs/api/controls/WEB-11.json | 7 +- docs/api/controls/WEB-12.json | 10 +- docs/api/controls/WEB-13.json | 11 +- docs/api/controls/WEB-14.json | 10 +- docs/api/crosswalks.json | 816 +- .../amaericas-can-osfi-self-assessment.json | 990 - .../api/crosswalks/americas-arg-ppd-2018.json | 736 +- .../api/crosswalks/americas-bhs-dpa-2003.json | 1606 +- .../crosswalks/americas-bmu-mba-coc-2020.json | 582 +- .../crosswalks/americas-bra-lgpd-2018.json | 876 +- .../americas-can-itsp-10-171-2025.json | 712 +- .../americas-can-osfi-b13-2022.json | 2 +- .../americas-can-osfi-self-assessment-2.json | 700 + .../americas-can-osfi-self-assessment.json | 12 + .../crosswalks/americas-can-pipeda-2000.json | 416 +- .../americas-chl-act-19628-1999.json | 166 +- .../americas-col-law-1581-2012.json | 374 +- .../crosswalks/americas-mex-fdpa-2010.json | 432 +- .../crosswalks/apac-aus-cop-sitc-2020.json | 224 +- .../crosswalks/apac-aus-essential-8-2024.json | 2 +- ...june.json => apac-aus-ism-2026-march.json} | 1508 +- .../crosswalks/apac-aus-privacy-act-1998.json | 144 - .../apac-aus-privacy-principles-2026.json | 946 +- .../crosswalks/apac-aus-ps-cps-230-2023.json | 620 +- .../crosswalks/apac-aus-ps-cps-234-2019.json | 356 +- docs/api/crosswalks/apac-chn-csnip-2012.json | 78 +- .../apac-chn-cybersecurity-law-2017.json | 2 +- .../apac-chn-data-security-law-2021.json | 236 +- docs/api/crosswalks/apac-chn-pipl-2021.json | 1022 +- docs/api/crosswalks/apac-hkg-pdo-2022.json | 1092 +- docs/api/crosswalks/apac-ind-dpdpa-2023.json | 2 +- .../apac-ind-privacy-rules-2011.json | 196 +- docs/api/crosswalks/apac-ind-sebi-2024.json | 2 +- docs/api/crosswalks/apac-jpn-appi-2020.json | 508 + docs/api/crosswalks/apac-jpn-ismap.json | 6 +- docs/api/crosswalks/apac-jpn-ppi-2020.json | 1204 - docs/api/crosswalks/apac-kor-pipa-2011.json | 804 +- .../crosswalks/apac-mys-bnm-rmit-2025.json | 1326 + docs/api/crosswalks/apac-mys-pdpa-2010.json | 954 +- .../apac-nzl-hisf-microsmall-2023.json | 1062 +- .../crosswalks/apac-nzl-hisf-mlhsp-2023.json | 1064 +- .../apac-nzl-hisf-suppliers-2023.json | 2 +- docs/api/crosswalks/apac-nzl-ism-3-9.json | 2640 +- .../crosswalks/apac-nzl-privacy-act-2020.json | 1316 +- docs/api/crosswalks/apac-phl-dpa-2012.json | 404 +- .../apac-sgp-cyber-hygiene-practice-2019.json | 98 +- .../api/crosswalks/apac-sgp-mas-trm-2021.json | 2358 +- docs/api/crosswalks/apac-sgp-pdpa-2012.json | 624 +- docs/api/crosswalks/apac-twn-pdpa-2025.json | 346 +- docs/api/crosswalks/emea-aut-dpa-2018.json | 452 + docs/api/crosswalks/emea-aut-fappd-2000.json | 376 - docs/api/crosswalks/emea-bel-act-30-2018.json | 490 + docs/api/crosswalks/emea-bel-act-8-1992.json | 282 - docs/api/crosswalks/emea-che-fadp-2025.json | 510 +- docs/api/crosswalks/emea-deu-bsrit-2017.json | 388 +- docs/api/crosswalks/emea-deu-c5-2020.json | 2262 +- docs/api/crosswalks/emea-deu-fdpa-2017.json | 1282 +- .../crosswalks/emea-esp-boe-a-2022-7191.json | 830 - .../emea-esp-ccn-stic-825-2023.json | 608 - .../emea-esp-ccn-stic-825-2026.json | 1546 + .../crosswalks/emea-esp-decree-1720-2007.json | 152 - .../crosswalks/emea-esp-decree-311-2022.json | 1006 +- docs/api/crosswalks/emea-eu-ai-act-2024.json | 2 +- .../emea-eu-cyber-resilience-act-2022.json | 274 - .../emea-eu-cyber-resilience-act-2024.json | 534 + ...-eu-cyber-resilience-act-annex-i-2024.json | 186 + ...-eu-cyber-resilience-act-annexes-2022.json | 548 - docs/api/crosswalks/emea-eu-dora-2023.json | 2 +- .../crosswalks/emea-eu-eba-ict-srm-2025.json | 1584 +- docs/api/crosswalks/emea-eu-gdpr-2016.json | 2 +- docs/api/crosswalks/emea-eu-nis2-2022.json | 2 +- .../crosswalks/emea-eu-nis2-annex-2024.json | 2 +- docs/api/crosswalks/emea-eu-psd2-2015.json | 130 + docs/api/crosswalks/emea-gbr-caf-4-0.json | 2 +- .../crosswalks/emea-gbr-cap-1850-2020.json | 242 +- ...gbr-cyber-essentials-requirements-3-3.json | 226 +- .../emea-gbr-def-stan-05-138-2024.json | 2 +- .../emea-gbr-def-stan-05-138-l0-2024.json | 2 +- .../emea-gbr-def-stan-05-138-l1-2024.json | 2 +- .../emea-gbr-def-stan-05-138-l2-2024.json | 2 +- .../emea-gbr-def-stan-05-138-l3-2024.json | 2 +- docs/api/crosswalks/emea-gbr-dpa-1998.json | 72 - docs/api/crosswalks/emea-gbr-dpa-2018.json | 1460 + docs/api/crosswalks/emea-grc-pirppd-1997.json | 398 +- .../crosswalks/emea-hun-act-cxii-2011.json | 570 + docs/api/crosswalks/emea-hun-isdfi-2011.json | 194 - docs/api/crosswalks/emea-irl-dpa-2003.json | 124 - docs/api/crosswalks/emea-irl-dpa-2018.json | 232 + docs/api/crosswalks/emea-isr-cmo-1-0.json | 3110 - docs/api/crosswalks/emea-isr-cmo-2-0.json | 396 + .../crosswalks/emea-isr-ppl-5741-1981.json | 148 - .../crosswalks/emea-isr-ppl-5741-2025.json | 120 + docs/api/crosswalks/emea-ita-pdpc-2003.json | 228 - docs/api/crosswalks/emea-ita-pdpc-2018.json | 222 + docs/api/crosswalks/emea-ken-pda-2019.json | 1554 +- docs/api/crosswalks/emea-nga-dpr-2019.json | 480 +- docs/api/crosswalks/emea-nor-pda-2018.json | 178 +- docs/api/crosswalks/emea-pol-act-10-2018.json | 30 + docs/api/crosswalks/emea-pol-act-29-1997.json | 190 - docs/api/crosswalks/emea-qat-pdppl-2020.json | 562 +- docs/api/crosswalks/emea-rus-152-fz-2025.json | 146 + .../emea-rus-federal-law-27-2006.json | 184 - docs/api/crosswalks/emea-sau-cgiot-2024.json | 2 +- docs/api/crosswalks/emea-sau-cscc-1-2019.json | 664 +- docs/api/crosswalks/emea-sau-ecc-1-2018.json | 1400 +- docs/api/crosswalks/emea-sau-otcc-1-2022.json | 1612 +- .../crosswalks/emea-sau-sacs-002-2022.json | 1314 +- .../crosswalks/emea-sau-sama-csf-1-2017.json | 2216 +- docs/api/crosswalks/emea-srb-act-9-2018.json | 1962 +- docs/api/crosswalks/emea-tur-lppd-2016.json | 480 +- docs/api/crosswalks/emea-us-psd2-2015.json | 166 - docs/api/crosswalks/emea-zaf-popia-2013.json | 1362 +- .../crosswalks/general-aicpa-pmf-2020.json | 2 +- .../crosswalks/general-aicpa-tsc-2017.json | 2 +- .../general-apec-privacy-framework-2015.json | 2 +- .../api/crosswalks/general-bsi-200-1-1-0.json | 2 +- .../crosswalks/general-cis-csc-8-1-ig1.json | 2 +- .../crosswalks/general-cis-csc-8-1-ig2.json | 86 +- .../crosswalks/general-cis-csc-8-1-ig3.json | 102 +- docs/api/crosswalks/general-cis-csc-8-1.json | 336 +- docs/api/crosswalks/general-cr-cmm-2026.json | 2 +- .../api/crosswalks/general-csa-cmm-4-1-0.json | 2 +- docs/api/crosswalks/general-csa-iot-2.json | 2 +- docs/api/crosswalks/general-govramp-core.json | 2 +- docs/api/crosswalks/general-govramp-high.json | 2 +- .../crosswalks/general-govramp-low-plus.json | 2 +- docs/api/crosswalks/general-govramp-low.json | 2 +- docs/api/crosswalks/general-govramp-mod.json | 2 +- docs/api/crosswalks/general-govramp.json | 2 +- .../general-iec-62443-2-1-2024.json | 2 +- .../general-iec-62443-3-3-2013.json | 2 +- .../general-iec-62443-4-1-2018.json | 2 +- .../general-iec-62443-4-2-2019.json | 2 +- .../general-iec-tr-60601-4-5-2021.json | 2 +- .../crosswalks/general-iso-21434-2021.json | 2 +- .../crosswalks/general-iso-22301-2019.json | 2 +- .../crosswalks/general-iso-27001-2022.json | 2 +- .../crosswalks/general-iso-27002-2022.json | 10 +- .../crosswalks/general-iso-27017-2015.json | 2 +- .../crosswalks/general-iso-27018-2025.json | 2 +- .../crosswalks/general-iso-27701-2025.json | 2 +- .../crosswalks/general-iso-29100-2024.json | 26 +- .../crosswalks/general-iso-31000-2018.json | 2 +- .../crosswalks/general-iso-31010-2009.json | 2 +- .../crosswalks/general-iso-42001-2023.json | 2 +- ...-1.json => general-mitre-att_ck-16-1.json} | 4 +- .../crosswalks/general-mpa-csbp-5-3-1.json | 2 +- ...ance-data-security-model-law-668-2017.json | 2 +- .../crosswalks/general-nist-100-1-ai-rmf.json | 2 +- .../general-nist-600-1-gen-ai-profile.json | 2 +- .../general-nist-800-160-vol-2-r1.json | 2 +- .../general-nist-800-161-r1-cscrm.json | 2 +- .../general-nist-800-161-r1-flowdown.json | 2 +- .../general-nist-800-161-r1-level-1.json | 2 +- .../general-nist-800-161-r1-level-2.json | 2 +- .../general-nist-800-161-r1-level-3.json | 2 +- .../crosswalks/general-nist-800-161-r1.json | 2 +- .../crosswalks/general-nist-800-171-r2.json | 2 +- .../crosswalks/general-nist-800-171-r3.json | 662 +- .../crosswalks/general-nist-800-171a-r3.json | 3252 +- .../api/crosswalks/general-nist-800-171a.json | 2 +- .../crosswalks/general-nist-800-172-r3.json | 1018 + docs/api/crosswalks/general-nist-800-172.json | 400 - .../crosswalks/general-nist-800-172a-r3.json | 1896 + docs/api/crosswalks/general-nist-800-207.json | 2 +- docs/api/crosswalks/general-nist-800-218.json | 2 +- .../crosswalks/general-nist-800-37-r2.json | 2 +- docs/api/crosswalks/general-nist-800-39.json | 2 +- .../crosswalks/general-nist-800-53-r4.json | 2 +- .../general-nist-800-53-r5-2-high.json | 2 +- .../general-nist-800-53-r5-2-low.json | 2 +- .../general-nist-800-53-r5-2-mod.json | 2 +- .../general-nist-800-53-r5-2-privacy.json | 2 +- .../crosswalks/general-nist-800-53-r5-2.json | 2 +- .../crosswalks/general-nist-800-66-r2.json | 2 +- .../general-nist-800-82-r3-high.json | 2 +- .../general-nist-800-82-r3-low.json | 2 +- .../general-nist-800-82-r3-mod.json | 2 +- .../crosswalks/general-nist-800-82-r3.json | 2 +- docs/api/crosswalks/general-nist-csf-2-0.json | 2 +- docs/api/crosswalks/general-nist-cswp-39.json | 128 + .../general-nist-privacy-framework-1-0.json | 12 +- .../general-oecd-privacy-principles-2010.json | 2 +- .../crosswalks/general-owasp-top-10-2025.json | 2 +- .../general-pci-dss-4-0-1-saq-a-ep.json | 2 +- .../general-pci-dss-4-0-1-saq-a.json | 2 +- .../general-pci-dss-4-0-1-saq-b-ip.json | 2 +- .../general-pci-dss-4-0-1-saq-b.json | 2 +- .../general-pci-dss-4-0-1-saq-c-vt.json | 2 +- .../general-pci-dss-4-0-1-saq-c.json | 2 +- .../general-pci-dss-4-0-1-saq-d-merchant.json | 2 +- ...-pci-dss-4-0-1-saq-d-service-provider.json | 2 +- .../general-pci-dss-4-0-1-saq-p2pe.json | 2 +- .../api/crosswalks/general-pci-dss-4-0-1.json | 2 +- .../api/crosswalks/general-scf-dpmp-2025.json | 1126 +- .../general-shared-assessments-sig-2025.json | 2 +- docs/api/crosswalks/general-sparta.json | 2 +- .../crosswalks/general-swift-cscf-2025.json | 2 +- docs/api/crosswalks/general-tisax-6-0-3.json | 2 +- .../crosswalks/general-ul-2900-1-2017.json | 2 +- .../crosswalks/general-ul-2900-2-2-2016.json | 2 +- docs/api/crosswalks/general-un-155-2021.json | 2 +- .../crosswalks/general-un-ece-wp-29-2020.json | 2 +- .../crosswalks/usa-federal-cms-marse-2-0.json | 12 +- .../usa-federal-dhs-cisa-cpg-2-0.json | 2 +- .../usa-federal-dhs-cisa-ssdaf-2024.json | 2 +- .../usa-federal-dhs-cisa-tic-3-0.json | 2 +- ...deral-doc-data-privacy-framework-2023.json | 2 +- .../crosswalks/usa-federal-doe-c2m2-2-1.json | 2 +- .../usa-federal-dow-cert-rmm-1-2.json | 2 +- .../usa-federal-dow-cmmc-2-level-1-aos.json | 2 +- .../usa-federal-dow-cmmc-2-level-1.json | 2 +- .../usa-federal-dow-cmmc-2-level-2.json | 2 +- .../usa-federal-dow-cmmc-2-level-3.json | 2 +- .../usa-federal-dow-dfars-252-204-7012.json | 2 +- ...sa-federal-dow-safeguarding-nnpi-2010.json | 2 +- .../usa-federal-dow-zt-roadmap-1-1.json | 8 +- ...al-dow-zta-reference-architecture-2-0.json | 2 +- docs/api/crosswalks/usa-federal-eo-14028.json | 2 +- .../crosswalks/usa-federal-far-52-204-21.json | 2 +- .../crosswalks/usa-federal-far-52-204-25.json | 2 +- .../crosswalks/usa-federal-far-52-204-27.json | 2 +- .../crosswalks/usa-federal-fbi-cjis-6-0.json | 2 +- .../usa-federal-fda-21-cfr-part-11-2025.json | 2 +- .../usa-federal-gsa-fedramp-5-high.json | 2 +- .../usa-federal-gsa-fedramp-5-li-saas.json | 2 +- .../usa-federal-gsa-fedramp-5-low.json | 2 +- .../usa-federal-gsa-fedramp-5-mod.json | 2 +- .../usa-federal-hhs-45-cfr-155-260-2016.json | 2 +- .../crosswalks/usa-federal-irs-1075-2021.json | 14 +- ...federal-law-33-cfr-part-101-subpart-f.json | 920 + .../usa-federal-law-coppa-2024.json | 2 +- .../usa-federal-law-facta-fcra-2023.json | 2 +- .../usa-federal-law-ferpa-2010.json | 2 +- .../crosswalks/usa-federal-law-ftc-act.json | 2 +- .../usa-federal-law-glba-cfr-314-2023.json | 2 +- ...-federal-law-hipaa-security-rule-2013.json | 626 +- ...federal-law-hipaa-simplification-2013.json | 2640 +- .../crosswalks/usa-federal-law-sox-2002.json | 2 +- .../crosswalks/usa-federal-nerc-cip-2024.json | 2 +- .../crosswalks/usa-federal-nispom-2020.json | 2 +- .../usa-federal-omb-fipps-1973.json | 2 +- ...a-federal-sec-cybersecurity-rule-2023.json | 2 +- .../usa-federal-sro-fca-crm-2023.json | 2 +- .../api/crosswalks/usa-federal-sro-finra.json | 2 +- ...sa-security-directive-1580-82-2022-01.json | 2 +- .../crosswalks/usa-state-ak-pipa-2009.json | 2 +- .../usa-state-ca-ccpa-cpra-2026.json | 2 +- .../crosswalks/usa-state-ca-sb1386-2002.json | 2 +- .../crosswalks/usa-state-ca-sb327-2018.json | 2 +- .../usa-state-co-privacy-act-2021.json | 2 +- .../crosswalks/usa-state-il-bipa-2008.json | 2 +- .../api/crosswalks/usa-state-il-ipa-2009.json | 2 +- .../crosswalks/usa-state-il-pipa-2006.json | 2 +- .../usa-state-ma-201-cmr-17-2008.json | 2 +- .../usa-state-nv-privacy-law-2023.json | 576 + .../usa-state-nv-regulation-5-2024.json | 2 +- .../crosswalks/usa-state-nv-sb220-2019.json | 2 +- ...sa-state-ny-dfs-23-nycrr500-2023-amd2.json | 2 +- .../usa-state-ny-shield-act-2019.json | 2 +- .../api/crosswalks/usa-state-or-cpa-2023.json | 2 +- .../usa-state-or-ors-646a-2025.json | 2 +- .../crosswalks/usa-state-tn-tipa-2025.json | 2 +- .../crosswalks/usa-state-tx-bc521-2009.json | 2 +- .../crosswalks/usa-state-tx-cdpa-2025.json | 2 +- ...ecurity-control-standards-catalog-2-2.json | 2 +- .../crosswalks/usa-state-tx-sb2610-2025.json | 2 +- .../crosswalks/usa-state-tx-sb820-2019.json | 2 +- .../usa-state-tx-txramp-2-0-level-1.json | 2 +- .../usa-state-tx-txramp-2-0-level-2.json | 2 +- .../crosswalks/usa-state-va-cdpa-2023.json | 2 +- .../crosswalks/usa-state-vt-act-171-2018.json | 2 +- docs/api/docs.md | 41 +- docs/api/evidence-requests.json | 144 +- docs/api/evidence-requests/E-CPL-01.json | 3 +- docs/api/evidence-requests/E-QTS-01.json | 10 + docs/api/evidence-requests/E-QTS-02.json | 10 + docs/api/evidence-requests/E-QTS-03.json | 10 + docs/api/evidence-requests/E-QTS-04.json | 13 + docs/api/evidence-requests/E-QTS-05.json | 10 + docs/api/evidence-requests/E-QTS-06.json | 10 + docs/api/evidence-requests/E-QTS-07.json | 10 + docs/api/evidence-requests/E-QTS-08.json | 11 + docs/api/evidence-requests/E-QTS-09.json | 10 + docs/api/evidence-requests/E-QTS-10.json | 11 + docs/api/evidence-requests/E-QTS-11.json | 10 + docs/api/evidence-requests/E-QTS-12.json | 10 + docs/api/evidence-requests/E-QTS-13.json | 12 + docs/api/evidence-requests/E-SAT-05.json | 1 + docs/api/evidence-requests/E-THR-03.json | 1 + docs/api/families.json | 39 +- docs/api/families/AAT.json | 1160 +- docs/api/families/AST.json | 1468 +- docs/api/families/BCD.json | 1169 +- docs/api/families/CAP.json | 157 +- docs/api/families/CFG.json | 1323 +- docs/api/families/CHG.json | 539 +- docs/api/families/CLD.json | 407 +- docs/api/families/CPL.json | 1736 +- docs/api/families/CRY.json | 604 +- docs/api/families/DCH.json | 2362 +- docs/api/families/EMB.json | 225 +- docs/api/families/END.json | 620 +- docs/api/families/GOV.json | 2632 +- docs/api/families/HRS.json | 1264 +- docs/api/families/IAC.json | 2568 +- docs/api/families/IAO.json | 793 +- docs/api/families/IRO.json | 1633 +- docs/api/families/MDM.json | 255 +- docs/api/families/MNT.json | 319 +- docs/api/families/MON.json | 1538 +- docs/api/families/NET.json | 1999 +- docs/api/families/OPS.json | 294 +- docs/api/families/PES.json | 1043 +- docs/api/families/PRI.json | 9351 +- docs/api/families/PRM.json | 663 +- docs/api/families/QTS.json | 3317 + docs/api/families/RSK.json | 1358 +- docs/api/families/SAT.json | 746 +- docs/api/families/SEA.json | 1658 +- docs/api/families/TDA.json | 2111 +- docs/api/families/THR.json | 545 +- docs/api/families/TPM.json | 1412 +- docs/api/families/VPM.json | 922 +- docs/api/families/WEB.json | 224 +- docs/api/summary.json | 875 +- docs/api/threats.json | 10 +- docs/api/threats/MT-12.json | 2 +- docs/api/threats/MT-28.json | 6 + docs/index.html | 18 +- docs/llms-full.txt | 534 +- docs/llms.txt | 2 +- overrides/overrides.json | 12 +- src/scf_api/cli.py | 56 +- src/scf_api/overrides.py | 45 + src/scf_api/parse.py | 22 +- src/scf_api/schemas/overrides.schema.json | 40 + src/scf_api/workbook.py | 204 +- tests/conftest.py | 28 +- tests/test_cli.py | 25 + tests/test_integration_real.py | 67 +- tests/test_parse.py | 38 + tests/test_workbook.py | 93 +- validation/validation-report.json | 801 +- 2024 files changed, 285743 insertions(+), 211126 deletions(-) rename data/{scf-2026-1-1.json => scf-2026-2.json} (94%) create mode 100644 docs/api/assessment-objectives/AAT-01.5.json create mode 100644 docs/api/assessment-objectives/AAT-12.5.json create mode 100644 docs/api/assessment-objectives/AAT-12.6.json create mode 100644 docs/api/assessment-objectives/AAT-29.24.json create mode 100644 docs/api/assessment-objectives/AAT-33.json create mode 100644 docs/api/assessment-objectives/AST-05.2.json create mode 100644 docs/api/assessment-objectives/CFG-09.1.json create mode 100644 docs/api/assessment-objectives/CFG-09.2.json create mode 100644 docs/api/assessment-objectives/CFG-09.3.json create mode 100644 docs/api/assessment-objectives/CFG-09.json create mode 100644 docs/api/assessment-objectives/CPL-03.8.json create mode 100644 docs/api/assessment-objectives/GOV-01.4.json create mode 100644 docs/api/assessment-objectives/GOV-10.1.json create mode 100644 docs/api/assessment-objectives/GOV-19.3.json create mode 100644 docs/api/assessment-objectives/GOV-21.json create mode 100644 docs/api/assessment-objectives/IAC-01.4.json create mode 100644 docs/api/assessment-objectives/IAC-15.10.json create mode 100644 docs/api/assessment-objectives/NET-06.8.json create mode 100644 docs/api/assessment-objectives/NET-06.9.json create mode 100644 docs/api/assessment-objectives/PRI-01.12.json create mode 100644 docs/api/assessment-objectives/QTS-01.1.json create mode 100644 docs/api/assessment-objectives/QTS-01.2.json create mode 100644 docs/api/assessment-objectives/QTS-01.3.json create mode 100644 docs/api/assessment-objectives/QTS-01.4.json create mode 100644 docs/api/assessment-objectives/QTS-01.json create mode 100644 docs/api/assessment-objectives/QTS-02.1.json create mode 100644 docs/api/assessment-objectives/QTS-02.2.json create mode 100644 docs/api/assessment-objectives/QTS-02.3.json create mode 100644 docs/api/assessment-objectives/QTS-02.json create mode 100644 docs/api/assessment-objectives/QTS-03.1.json create mode 100644 docs/api/assessment-objectives/QTS-03.2.json create mode 100644 docs/api/assessment-objectives/QTS-03.3.json create mode 100644 docs/api/assessment-objectives/QTS-03.4.json create mode 100644 docs/api/assessment-objectives/QTS-03.json create mode 100644 docs/api/assessment-objectives/QTS-04.1.json create mode 100644 docs/api/assessment-objectives/QTS-04.2.json create mode 100644 docs/api/assessment-objectives/QTS-04.3.json create mode 100644 docs/api/assessment-objectives/QTS-04.json create mode 100644 docs/api/assessment-objectives/QTS-05.1.json create mode 100644 docs/api/assessment-objectives/QTS-05.2.json create mode 100644 docs/api/assessment-objectives/QTS-05.json create mode 100644 docs/api/assessment-objectives/QTS-06.1.json create mode 100644 docs/api/assessment-objectives/QTS-06.10.json create mode 100644 docs/api/assessment-objectives/QTS-06.2.json create mode 100644 docs/api/assessment-objectives/QTS-06.3.json create mode 100644 docs/api/assessment-objectives/QTS-06.4.json create mode 100644 docs/api/assessment-objectives/QTS-06.5.json create mode 100644 docs/api/assessment-objectives/QTS-06.6.json create mode 100644 docs/api/assessment-objectives/QTS-06.7.json create mode 100644 docs/api/assessment-objectives/QTS-06.8.json create mode 100644 docs/api/assessment-objectives/QTS-06.9.json create mode 100644 docs/api/assessment-objectives/QTS-06.json create mode 100644 docs/api/assessment-objectives/QTS-07.json create mode 100644 docs/api/assessment-objectives/QTS-08.json create mode 100644 docs/api/assessment-objectives/RSK-03.2.json create mode 100644 docs/api/assessment-objectives/SAT-04.1.json create mode 100644 docs/api/assessment-objectives/SEA-01.4.json create mode 100644 docs/api/assessment-objectives/SEA-01.5.json create mode 100644 docs/api/assessment-objectives/SEA-08.2.json create mode 100644 docs/api/assessment-objectives/TDA-06.7.json create mode 100644 docs/api/assessment-objectives/TDA-13.1.json create mode 100644 docs/api/assessment-objectives/TDA-13.2.json create mode 100644 docs/api/assessment-objectives/TDA-19.1.json create mode 100644 docs/api/assessment-objectives/THR-01.1.json create mode 100644 docs/api/assessment-objectives/THR-01.2.json create mode 100644 docs/api/assessment-objectives/VPM-02.1.json create mode 100644 docs/api/compensating-controls/AAT-01.5.json create mode 100644 docs/api/compensating-controls/AAT-12.5.json create mode 100644 docs/api/compensating-controls/AAT-12.6.json create mode 100644 docs/api/compensating-controls/AAT-29.24.json create mode 100644 docs/api/compensating-controls/AAT-33.json create mode 100644 docs/api/compensating-controls/AST-05.2.json create mode 100644 docs/api/compensating-controls/CFG-09.1.json create mode 100644 docs/api/compensating-controls/CFG-09.2.json create mode 100644 docs/api/compensating-controls/CFG-09.3.json create mode 100644 docs/api/compensating-controls/CFG-09.json create mode 100644 docs/api/compensating-controls/CPL-03.8.json create mode 100644 docs/api/compensating-controls/GOV-01.4.json create mode 100644 docs/api/compensating-controls/GOV-10.1.json create mode 100644 docs/api/compensating-controls/GOV-19.3.json create mode 100644 docs/api/compensating-controls/GOV-21.json create mode 100644 docs/api/compensating-controls/IAC-01.4.json create mode 100644 docs/api/compensating-controls/IAC-15.10.json create mode 100644 docs/api/compensating-controls/NET-06.8.json create mode 100644 docs/api/compensating-controls/NET-06.9.json create mode 100644 docs/api/compensating-controls/PRI-01.12.json create mode 100644 docs/api/compensating-controls/QTS-01.1.json create mode 100644 docs/api/compensating-controls/QTS-01.2.json create mode 100644 docs/api/compensating-controls/QTS-01.3.json create mode 100644 docs/api/compensating-controls/QTS-01.4.json create mode 100644 docs/api/compensating-controls/QTS-01.json create mode 100644 docs/api/compensating-controls/QTS-02.1.json create mode 100644 docs/api/compensating-controls/QTS-02.2.json create mode 100644 docs/api/compensating-controls/QTS-02.3.json create mode 100644 docs/api/compensating-controls/QTS-02.json create mode 100644 docs/api/compensating-controls/QTS-03.1.json create mode 100644 docs/api/compensating-controls/QTS-03.2.json create mode 100644 docs/api/compensating-controls/QTS-03.3.json create mode 100644 docs/api/compensating-controls/QTS-03.4.json create mode 100644 docs/api/compensating-controls/QTS-03.json create mode 100644 docs/api/compensating-controls/QTS-04.1.json create mode 100644 docs/api/compensating-controls/QTS-04.2.json create mode 100644 docs/api/compensating-controls/QTS-04.3.json create mode 100644 docs/api/compensating-controls/QTS-04.json create mode 100644 docs/api/compensating-controls/QTS-05.1.json create mode 100644 docs/api/compensating-controls/QTS-05.2.json create mode 100644 docs/api/compensating-controls/QTS-05.json create mode 100644 docs/api/compensating-controls/QTS-06.1.json create mode 100644 docs/api/compensating-controls/QTS-06.10.json create mode 100644 docs/api/compensating-controls/QTS-06.2.json create mode 100644 docs/api/compensating-controls/QTS-06.3.json create mode 100644 docs/api/compensating-controls/QTS-06.4.json create mode 100644 docs/api/compensating-controls/QTS-06.5.json create mode 100644 docs/api/compensating-controls/QTS-06.6.json create mode 100644 docs/api/compensating-controls/QTS-06.7.json create mode 100644 docs/api/compensating-controls/QTS-06.8.json create mode 100644 docs/api/compensating-controls/QTS-06.9.json create mode 100644 docs/api/compensating-controls/QTS-06.json create mode 100644 docs/api/compensating-controls/QTS-07.json create mode 100644 docs/api/compensating-controls/QTS-08.json create mode 100644 docs/api/compensating-controls/RSK-03.2.json create mode 100644 docs/api/compensating-controls/SAT-04.1.json create mode 100644 docs/api/compensating-controls/SEA-01.4.json create mode 100644 docs/api/compensating-controls/SEA-01.5.json create mode 100644 docs/api/compensating-controls/SEA-08.2.json create mode 100644 docs/api/compensating-controls/TDA-06.7.json create mode 100644 docs/api/compensating-controls/TDA-13.1.json create mode 100644 docs/api/compensating-controls/TDA-13.2.json create mode 100644 docs/api/compensating-controls/TDA-19.1.json create mode 100644 docs/api/compensating-controls/THR-01.1.json create mode 100644 docs/api/compensating-controls/THR-01.2.json create mode 100644 docs/api/compensating-controls/VPM-02.1.json create mode 100644 docs/api/controls/AAT-01.5.json create mode 100644 docs/api/controls/AAT-12.5.json create mode 100644 docs/api/controls/AAT-12.6.json create mode 100644 docs/api/controls/AAT-29.24.json create mode 100644 docs/api/controls/AAT-33.json create mode 100644 docs/api/controls/AST-05.2.json create mode 100644 docs/api/controls/CFG-09.1.json create mode 100644 docs/api/controls/CFG-09.2.json create mode 100644 docs/api/controls/CFG-09.3.json create mode 100644 docs/api/controls/CFG-09.json create mode 100644 docs/api/controls/CPL-03.8.json create mode 100644 docs/api/controls/GOV-01.4.json create mode 100644 docs/api/controls/GOV-10.1.json create mode 100644 docs/api/controls/GOV-19.3.json create mode 100644 docs/api/controls/GOV-21.json create mode 100644 docs/api/controls/IAC-01.4.json create mode 100644 docs/api/controls/IAC-15.10.json create mode 100644 docs/api/controls/NET-06.8.json create mode 100644 docs/api/controls/NET-06.9.json create mode 100644 docs/api/controls/PRI-01.12.json create mode 100644 docs/api/controls/QTS-01.1.json create mode 100644 docs/api/controls/QTS-01.2.json create mode 100644 docs/api/controls/QTS-01.3.json create mode 100644 docs/api/controls/QTS-01.4.json create mode 100644 docs/api/controls/QTS-01.json create mode 100644 docs/api/controls/QTS-02.1.json create mode 100644 docs/api/controls/QTS-02.2.json create mode 100644 docs/api/controls/QTS-02.3.json create mode 100644 docs/api/controls/QTS-02.json create mode 100644 docs/api/controls/QTS-03.1.json create mode 100644 docs/api/controls/QTS-03.2.json create mode 100644 docs/api/controls/QTS-03.3.json create mode 100644 docs/api/controls/QTS-03.4.json create mode 100644 docs/api/controls/QTS-03.json create mode 100644 docs/api/controls/QTS-04.1.json create mode 100644 docs/api/controls/QTS-04.2.json create mode 100644 docs/api/controls/QTS-04.3.json create mode 100644 docs/api/controls/QTS-04.json create mode 100644 docs/api/controls/QTS-05.1.json create mode 100644 docs/api/controls/QTS-05.2.json create mode 100644 docs/api/controls/QTS-05.json create mode 100644 docs/api/controls/QTS-06.1.json create mode 100644 docs/api/controls/QTS-06.10.json create mode 100644 docs/api/controls/QTS-06.2.json create mode 100644 docs/api/controls/QTS-06.3.json create mode 100644 docs/api/controls/QTS-06.4.json create mode 100644 docs/api/controls/QTS-06.5.json create mode 100644 docs/api/controls/QTS-06.6.json create mode 100644 docs/api/controls/QTS-06.7.json create mode 100644 docs/api/controls/QTS-06.8.json create mode 100644 docs/api/controls/QTS-06.9.json create mode 100644 docs/api/controls/QTS-06.json create mode 100644 docs/api/controls/QTS-07.json create mode 100644 docs/api/controls/QTS-08.json create mode 100644 docs/api/controls/RSK-03.2.json create mode 100644 docs/api/controls/SAT-04.1.json create mode 100644 docs/api/controls/SEA-01.4.json create mode 100644 docs/api/controls/SEA-01.5.json create mode 100644 docs/api/controls/SEA-08.2.json create mode 100644 docs/api/controls/TDA-06.7.json create mode 100644 docs/api/controls/TDA-13.1.json create mode 100644 docs/api/controls/TDA-13.2.json create mode 100644 docs/api/controls/TDA-19.1.json create mode 100644 docs/api/controls/THR-01.1.json create mode 100644 docs/api/controls/THR-01.2.json create mode 100644 docs/api/controls/VPM-02.1.json delete mode 100644 docs/api/crosswalks/amaericas-can-osfi-self-assessment.json create mode 100644 docs/api/crosswalks/americas-can-osfi-self-assessment-2.json create mode 100644 docs/api/crosswalks/americas-can-osfi-self-assessment.json rename docs/api/crosswalks/{apac-aus-ism-2024-june.json => apac-aus-ism-2026-march.json} (78%) delete mode 100644 docs/api/crosswalks/apac-aus-privacy-act-1998.json create mode 100644 docs/api/crosswalks/apac-jpn-appi-2020.json delete mode 100644 docs/api/crosswalks/apac-jpn-ppi-2020.json create mode 100644 docs/api/crosswalks/apac-mys-bnm-rmit-2025.json create mode 100644 docs/api/crosswalks/emea-aut-dpa-2018.json delete mode 100644 docs/api/crosswalks/emea-aut-fappd-2000.json create mode 100644 docs/api/crosswalks/emea-bel-act-30-2018.json delete mode 100644 docs/api/crosswalks/emea-bel-act-8-1992.json delete mode 100644 docs/api/crosswalks/emea-esp-boe-a-2022-7191.json delete mode 100644 docs/api/crosswalks/emea-esp-ccn-stic-825-2023.json create mode 100644 docs/api/crosswalks/emea-esp-ccn-stic-825-2026.json delete mode 100644 docs/api/crosswalks/emea-esp-decree-1720-2007.json delete mode 100644 docs/api/crosswalks/emea-eu-cyber-resilience-act-2022.json create mode 100644 docs/api/crosswalks/emea-eu-cyber-resilience-act-2024.json create mode 100644 docs/api/crosswalks/emea-eu-cyber-resilience-act-annex-i-2024.json delete mode 100644 docs/api/crosswalks/emea-eu-cyber-resilience-act-annexes-2022.json create mode 100644 docs/api/crosswalks/emea-eu-psd2-2015.json delete mode 100644 docs/api/crosswalks/emea-gbr-dpa-1998.json create mode 100644 docs/api/crosswalks/emea-gbr-dpa-2018.json create mode 100644 docs/api/crosswalks/emea-hun-act-cxii-2011.json delete mode 100644 docs/api/crosswalks/emea-hun-isdfi-2011.json delete mode 100644 docs/api/crosswalks/emea-irl-dpa-2003.json create mode 100644 docs/api/crosswalks/emea-irl-dpa-2018.json delete mode 100644 docs/api/crosswalks/emea-isr-cmo-1-0.json create mode 100644 docs/api/crosswalks/emea-isr-cmo-2-0.json delete mode 100644 docs/api/crosswalks/emea-isr-ppl-5741-1981.json create mode 100644 docs/api/crosswalks/emea-isr-ppl-5741-2025.json delete mode 100644 docs/api/crosswalks/emea-ita-pdpc-2003.json create mode 100644 docs/api/crosswalks/emea-ita-pdpc-2018.json create mode 100644 docs/api/crosswalks/emea-pol-act-10-2018.json delete mode 100644 docs/api/crosswalks/emea-pol-act-29-1997.json create mode 100644 docs/api/crosswalks/emea-rus-152-fz-2025.json delete mode 100644 docs/api/crosswalks/emea-rus-federal-law-27-2006.json delete mode 100644 docs/api/crosswalks/emea-us-psd2-2015.json rename docs/api/crosswalks/{general-mitre-att&ck-16-1.json => general-mitre-att_ck-16-1.json} (99%) create mode 100644 docs/api/crosswalks/general-nist-800-172-r3.json delete mode 100644 docs/api/crosswalks/general-nist-800-172.json create mode 100644 docs/api/crosswalks/general-nist-800-172a-r3.json create mode 100644 docs/api/crosswalks/general-nist-cswp-39.json create mode 100644 docs/api/crosswalks/usa-federal-law-33-cfr-part-101-subpart-f.json create mode 100644 docs/api/crosswalks/usa-state-nv-privacy-law-2023.json create mode 100644 docs/api/evidence-requests/E-QTS-01.json create mode 100644 docs/api/evidence-requests/E-QTS-02.json create mode 100644 docs/api/evidence-requests/E-QTS-03.json create mode 100644 docs/api/evidence-requests/E-QTS-04.json create mode 100644 docs/api/evidence-requests/E-QTS-05.json create mode 100644 docs/api/evidence-requests/E-QTS-06.json create mode 100644 docs/api/evidence-requests/E-QTS-07.json create mode 100644 docs/api/evidence-requests/E-QTS-08.json create mode 100644 docs/api/evidence-requests/E-QTS-09.json create mode 100644 docs/api/evidence-requests/E-QTS-10.json create mode 100644 docs/api/evidence-requests/E-QTS-11.json create mode 100644 docs/api/evidence-requests/E-QTS-12.json create mode 100644 docs/api/evidence-requests/E-QTS-13.json create mode 100644 docs/api/families/QTS.json create mode 100644 docs/api/threats/MT-28.json diff --git a/.github/workflows/update-scf.yml b/.github/workflows/update-scf.yml index fff1babb..3cceb84f 100644 --- a/.github/workflows/update-scf.yml +++ b/.github/workflows/update-scf.yml @@ -125,18 +125,67 @@ jobs: echo echo "Full report: workflow-run artifact \`validation-report-${{ steps.resolve.outputs.version }}\`." echo - echo "Your job: add an override entry (with a reason) to overrides/overrides.json," - echo "or report the workbook bug upstream — then re-dispatch this workflow." + echo "Your job: add an override entry (with a reason) to overrides/overrides.json." + echo "A renamed tab or column header goes in the \`resolution\` section of that" + echo "same file (sheets[] / columns[]) — no code change needed. Then re-dispatch" + echo "this workflow. If the workbook itself is wrong, report it upstream." + echo + echo "Run: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" } > /tmp/issue-body.md - gh issue create \ - --title "SCF ${{ steps.resolve.outputs.version }}: validation gate failed" \ - --body-file /tmp/issue-body.md + # Re-notify on an existing open issue rather than filing a duplicate: + # this job is a weekly cron, so the same blockage recurs every Monday. + TITLE="SCF ${{ steps.resolve.outputs.version }}: validation gate failed" + EXISTING="$(gh issue list --state open --search "$TITLE in:title" \ + --json number,title \ + --jq "[.[] | select(.title == \"$TITLE\")] | .[0].number // empty")" + if [ -n "$EXISTING" ]; then + gh issue comment "$EXISTING" --body-file /tmp/issue-body.md + echo "Commented on existing issue #$EXISTING" + else + gh issue create --title "$TITLE" --body-file /tmp/issue-body.md + fi exit 1 - name: Full hermetic gate + id: hermetic if: steps.resolve.outputs.skip == 'false' && steps.pipeline.outputs.gate_rc == '0' run: nix flake check -L + # The validation gate passed but the hermetic check did not, so nothing + # is pushed. Without this the run just goes red with no issue filed. + - name: Summon a human (hermetic gate failed) + if: failure() && steps.hermetic.outcome == 'failure' + run: | + TITLE="SCF ${{ steps.resolve.outputs.version }}: hermetic gate failed" + { + echo "\`nix flake check\` failed for SCF ${{ steps.resolve.outputs.version }}" + echo "*after* the validation gate passed, so nothing was pushed." + echo + echo "The dataset parsed and validated cleanly — this is a repo-side" + echo "inconsistency (schemas, docs freshness, or version consistency)." + echo "Reproduce locally:" + echo + echo '```' + echo "nix develop --command python3 -m scf_api.cli parse \\" + echo " --workbook <2026.x workbook> \\" + echo " --scf-version ${{ steps.resolve.outputs.version }} --out data \\" + echo " --overrides overrides/overrides.json \\" + echo " --report validation/validation-report.json" + echo "nix develop --command python3 -m scf_api.cli build --data data --out docs" + echo "nix flake check -L" + echo '```' + echo + echo "Run: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" + } > /tmp/hermetic-body.md + EXISTING="$(gh issue list --state open --search "$TITLE in:title" \ + --json number,title \ + --jq "[.[] | select(.title == \"$TITLE\")] | .[0].number // empty")" + if [ -n "$EXISTING" ]; then + gh issue comment "$EXISTING" --body-file /tmp/hermetic-body.md + else + gh issue create --title "$TITLE" --body-file /tmp/hermetic-body.md + fi + - name: Commit and push (or no-op) if: steps.resolve.outputs.skip == 'false' && steps.pipeline.outputs.gate_rc == '0' run: | diff --git a/.scf-version b/.scf-version index 76d000a5..c729d392 100644 --- a/.scf-version +++ b/.scf-version @@ -1 +1 @@ -2026.1.1 +2026.2 diff --git a/CHANGELOG.md b/CHANGELOG.md index 58100577..1ef3158a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,72 @@ # Changelog +## SCF 2026.2 + +Upstream restructured the workbook: the **Authoritative Sources** tab was +renamed **Focal Documents**, and the compensating-controls **SCF Control #** +header was shortened to **SCF #**. Both broke the weekly autopilot (issues #1, +#2). Sheet and column resolution now accept an ordered list of historical +names, so one parser reads every supported release, and tab names are matched +with the same normalization column headers already got. + +New this release: the **QTS** (Quantum Security) control family, threat **MT-28** +(mapped to nearly every control, which is why almost all controls show a +`threats` change), and 25 crosswalk frameworks — most of the churn is upstream +adding explicit year suffixes to framework names. + +The MON-03.3 evidence-request typo is still present upstream, so its override +is no longer version-scoped (`mon-03.3-erl-typo`); the gate resolves it +automatically and will warn once upstream fixes it. + +Equivalence against the archived hackIDLE/scf-api dataset stays frozen at +2026.1.1 — that archive has no 2026.2 to compare against. Parsing the 2026.1.1 +workbook with this release still reproduces the committed 2026.1.1 dataset +byte-for-byte. + +## SCF 2026.1.1 → 2026.2 + +### Controls + +66 added, 0 removed, 1468 changed (1534 total) + +**Added:** AAT-01.5, AAT-12.5, AAT-12.6, AAT-29.24, AAT-33, AST-05.2, CFG-09, CFG-09.1, CFG-09.2, CFG-09.3, CPL-03.8, GOV-01.4, GOV-10.1, GOV-19.3, GOV-21, IAC-01.4, IAC-15.10, NET-06.8, NET-06.9, PRI-01.12, QTS-01, QTS-01.1, QTS-01.2, QTS-01.3, QTS-01.4, QTS-02, QTS-02.1, QTS-02.2, QTS-02.3, QTS-03, QTS-03.1, QTS-03.2, QTS-03.3, QTS-03.4, QTS-04, QTS-04.1, QTS-04.2, QTS-04.3, QTS-05, QTS-05.1, QTS-05.2, QTS-06, QTS-06.1, QTS-06.10, QTS-06.2, QTS-06.3, QTS-06.4, QTS-06.5, QTS-06.6, QTS-06.7 … +**Changed:** AAT-01 (threats); AAT-01.1 (threats); AAT-01.2 (threats); AAT-01.3 (maturity, threats); AAT-01.4 (threats); AAT-02 (threats); AAT-02.1 (threats); AAT-02.2 (errata, threats); AAT-02.3 (errata, maturity, threats); AAT-02.4 (threats); AAT-03 (threats); AAT-03.1 (maturity, threats); AAT-03.2 (threats); AAT-04 (threats); AAT-04.1 (threats); AAT-04.2 (threats); AAT-04.3 (threats); AAT-04.4 (threats); AAT-05 (threats); AAT-06 (threats); AAT-07 (threats); AAT-07.1 (threats); AAT-07.2 (threats); AAT-07.3 (threats); AAT-08 (threats); AAT-09 (threats); AAT-09.1 (description, maturity, scf_question, threats); AAT-10 (maturity, threats); AAT-10.1 (maturity, threats); AAT-10.10 (maturity, threats); AAT-10.11 (maturity, threats); AAT-10.12 (maturity, threats); AAT-10.13 (maturity, threats); AAT-10.14 (maturity, threats); AAT-10.15 (maturity, threats); AAT-10.16 (maturity, threats); AAT-10.17 (maturity, scf_question, threats); AAT-10.18 (maturity, threats); AAT-10.19 (threats); AAT-10.2 (maturity, threats); AAT-10.3 (maturity, threats); AAT-10.4 (maturity, threats); AAT-10.5 (maturity, threats); AAT-10.6 (maturity, threats); AAT-10.7 (maturity, threats); AAT-10.8 (maturity, threats); AAT-10.9 (maturity, threats); AAT-11 (threats); AAT-11.1 (threats); AAT-11.2 (threats) … + +### Assessment objectives + +180 added, 0 removed, 4 changed (5956 total) + +**Added:** AAT-01.5_A01, AAT-01.5_A02, AAT-01.5_A03, AAT-01.5_A04, AAT-01.5_A05, AAT-01.5_A06, AAT-01.5_A07, AAT-12.5_A01, AAT-12.6_A01, AAT-29.24_A01, AAT-29.24_A02, AAT-29.24_A03, AAT-29.24_A04, AAT-33_A01, AAT-33_A02, AAT-33_A03, AAT-33_A04, AST-05.2_A01, AST-05.2_A02, AST-05.2_A03, CFG-09.1_A01, CFG-09.2_A01, CFG-09.2_A02, CFG-09.2_A03, CFG-09.2_A04, CFG-09.3_A01, CFG-09_A01, CPL-03.8_A01, CPL-03.8_A02, GOV-01.4_A01, GOV-01.4_A02, GOV-10.1_A01, GOV-10.1_A02, GOV-19.3_A01, GOV-19.3_A02, GOV-19.3_A03, GOV-19.3_A04, GOV-21_A01, GOV-21_A02, GOV-21_A03, GOV-21_A04, GOV-21_A05, GOV-21_A06, GOV-21_A07, IAC-01.4_A01, IAC-01.4_A02, IAC-01.4_A03, IAC-15.10_A01, NET-06.8_A01, NET-06.8_A02 … +**Changed:** MON-03_A13 (scf_defined_parameters); RSK-01_A12 (scf_defined_parameters); RSK-09_A31 (scf_defined_parameters); TPM-05_A05 (scf_defined_parameters) + +### Evidence requests + +13 added, 0 removed, 3 changed (316 total) + +**Added:** E-QTS-01, E-QTS-02, E-QTS-03, E-QTS-04, E-QTS-05, E-QTS-06, E-QTS-07, E-QTS-08, E-QTS-09, E-QTS-10, E-QTS-11, E-QTS-12, E-QTS-13 +**Changed:** E-CPL-01 (scf_controls); E-SAT-05 (scf_controls); E-THR-03 (scf_controls) + +### Threats + +1 added, 0 removed, 1 changed (42 total) + +**Added:** MT-28 +**Changed:** MT-12 (description) + +### Compensating controls + +66 added, 0 removed, 0 changed (1371 total) + +**Added:** AAT-01.5, AAT-12.5, AAT-12.6, AAT-29.24, AAT-33, AST-05.2, CFG-09, CFG-09.1, CFG-09.2, CFG-09.3, CPL-03.8, GOV-01.4, GOV-10.1, GOV-19.3, GOV-21, IAC-01.4, IAC-15.10, NET-06.8, NET-06.9, PRI-01.12, QTS-01, QTS-01.1, QTS-01.2, QTS-01.3, QTS-01.4, QTS-02, QTS-02.1, QTS-02.2, QTS-02.3, QTS-03, QTS-03.1, QTS-03.2, QTS-03.3, QTS-03.4, QTS-04, QTS-04.1, QTS-04.2, QTS-04.3, QTS-05, QTS-05.1, QTS-05.2, QTS-06, QTS-06.1, QTS-06.10, QTS-06.2, QTS-06.3, QTS-06.4, QTS-06.5, QTS-06.6, QTS-06.7 … + +### Crosswalk frameworks + +25 added, 22 removed, 65 with mapping changes (252 total) + +**Added:** americas-can-osfi-self-assessment, americas-can-osfi-self-assessment-2, apac-aus-ism-2026-march, apac-jpn-appi-2020, apac-mys-bnm-rmit-2025, emea-aut-dpa-2018, emea-bel-act-30-2018, emea-esp-ccn-stic-825-2026, emea-eu-cyber-resilience-act-2024, emea-eu-cyber-resilience-act-annex-i-2024, emea-eu-psd2-2015, emea-gbr-dpa-2018, emea-hun-act-cxii-2011, emea-irl-dpa-2018, emea-isr-cmo-2-0, emea-isr-ppl-5741-2025, emea-ita-pdpc-2018, emea-pol-act-10-2018, emea-rus-152-fz-2025, general-mitre-att_ck-16-1, general-nist-800-172-r3, general-nist-800-172a-r3, general-nist-cswp-39, usa-federal-law-33-cfr-part-101-subpart-f, usa-state-nv-privacy-law-2023 +**Removed:** amaericas-can-osfi-self-assessment, apac-aus-ism-2024-june, apac-aus-privacy-act-1998, apac-jpn-ppi-2020, emea-aut-fappd-2000, emea-bel-act-8-1992, emea-esp-boe-a-2022-7191, emea-esp-ccn-stic-825-2023, emea-esp-decree-1720-2007, emea-eu-cyber-resilience-act-2022, emea-eu-cyber-resilience-act-annexes-2022, emea-gbr-dpa-1998, emea-hun-isdfi-2011, emea-irl-dpa-2003, emea-isr-cmo-1-0, emea-isr-ppl-5741-1981, emea-ita-pdpc-2003, emea-pol-act-29-1997, emea-rus-federal-law-27-2006, emea-us-psd2-2015, general-mitre-att&ck-16-1, general-nist-800-172 +**Mapping changes:** americas-arg-ppd-2018, americas-bhs-dpa-2003, americas-bmu-mba-coc-2020, americas-bra-lgpd-2018, americas-can-itsp-10-171-2025, americas-can-pipeda-2000, americas-chl-act-19628-1999, americas-col-law-1581-2012, americas-mex-fdpa-2010, apac-aus-cop-sitc-2020, apac-aus-privacy-principles-2026, apac-aus-ps-cps-230-2023, apac-aus-ps-cps-234-2019, apac-chn-csnip-2012, apac-chn-data-security-law-2021, apac-chn-pipl-2021, apac-hkg-pdo-2022, apac-ind-privacy-rules-2011, apac-jpn-ismap, apac-kor-pipa-2011, apac-mys-pdpa-2010, apac-nzl-hisf-microsmall-2023, apac-nzl-hisf-mlhsp-2023, apac-nzl-ism-3-9, apac-nzl-privacy-act-2020, apac-phl-dpa-2012, apac-sgp-cyber-hygiene-practice-2019, apac-sgp-mas-trm-2021, apac-sgp-pdpa-2012, apac-twn-pdpa-2025 … + ## SCF 2026.1.1 — initial canonical release First release of sc2in/scf: 1,468 controls across 33 families, 249 diff --git a/CLAUDE.md b/CLAUDE.md index 7c5b3426..4ccc4027 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -40,13 +40,33 @@ ground truth, output contracts, and acceptance proofs. Work milestone by milesto - praxis: `/home/tsunami/code/sc2/praxis` — `scripts/generate-facts.py` (hardcodes `scf-2026-1-1.json`), `modules/flake/checks.nix` `praxis-facts-fresh`. Acceptance: facts.json regenerated from this repo's `data/` is **byte-identical**. + **The catalog filename carries the SCF version**, so it is now `scf-2026-2.json` — + de-hardcode praxis (glob `scf-*.json` or read `.scf-version`) before bumping its pin. - policypress: `/home/tsunami/code/sc2/policypress` — `src/control_report.zig` reads `data/scf.json` (bare array of `{domain, control_id, control}`). - grc: `/home/tsunami/code/sc2/grc` — `import/import-scf.mjs` consumes `scf-api/docs/api/*.json` (submodule); count asserts are its acceptance test. -- Known 2026.1.1 deviations (documented in PLAN.md): MON-03.3 evidence_requests workbook - typo (override: drop), TDA-11.2 `["[object Object]"]` upstream parser bug (we emit real - values; allowlisted in the tree proof). +- Known deviations (documented in PLAN.md): MON-03.3 evidence_requests workbook typo + (override: drop — still present at 2026.2, so the entry is deliberately NOT + version-scoped), TDA-11.2 `["[object Object]"]` upstream parser bug (we emit real + values; allowlisted in the tree proof). The hackIDLE oracle equivalence proof is frozen + at 2026.1.1 — the archive has no later release to compare against. + +## Upstream renames tabs and headers between releases + +SCF 2026.2 renamed the `Authoritative Sources` tab to `Focal Documents` and shortened the +compensating-controls `SCF Control #` header to `SCF #`, breaking autopilot. So: + +- `SHEET_PATTERNS` (workbook.py) maps each logical kind to an **ordered tuple** of accepted + patterns, current name first; `Sheet.col(..., alts=(...))` does the same for headers. + Add the new name, keep the old — one parser must read every supported release, and + `tests/test_integration_real.py` pins ground-truth counts per version. +- Tab names match via `norm_key`, same as column headers, so invisible whitespace drift + does not summon a human. +- A rename found in production is fixable **without a code change**: the `resolution` + section of `overrides/overrides.json` carries `sheets[]`/`columns[]` fallbacks. Those are + tried only after the built-in patterns miss and raise a `resolution-alias` WARN, so the + alias gets folded back into `SHEET_PATTERNS` later. ## House style diff --git a/README.md b/README.md index f949ca16..05ff59ff 100644 --- a/README.md +++ b/README.md @@ -4,8 +4,8 @@ SC2's canonical, validated [Secure Controls Framework](https://securecontrolsfra dataset: official SCF Excel workbook → validated `data/*.json` → static JSON API under `docs/` (GitHub Pages). -- **1,468 controls** across 33 families (SCF 2026.1.1), 249 framework crosswalks, - 5,776 assessment objectives, 303 evidence requests, risk/threat catalogs, +- **1,534 controls** across 34 families (SCF 2026.2), 252 framework crosswalks, + 5,956 assessment objectives, 316 evidence requests, risk/threat catalogs, compensating controls, privacy principles. - **Validated**: every id-bearing cell is checked for cross-sheet referential integrity before a release ships. The SCF master workbook is maintained by hand; diff --git a/data/scf-2026-1-1.json b/data/scf-2026-2.json similarity index 94% rename from data/scf-2026-1-1.json rename to data/scf-2026-2.json index 9b4f8d6e..0d273f98 100644 --- a/data/scf-2026-1-1.json +++ b/data/scf-2026-2.json @@ -1,11 +1,11 @@ { "framework": { - "id": "scf-2026-1-1", + "id": "scf-2026-2", "name": "SCF", - "version": "2026.1.1" + "version": "2026.2" }, "families": { - "GOV": "Cybersecurity & Data Protection Governance", + "GOV": "Security, Compliance & Resilience Governance", "AAT": "Artificial Intelligence & Autonomous Technologies", "AST": "Asset Management", "BCD": "Business Continuity & Disaster Recovery", @@ -29,6 +29,7 @@ "PES": "Physical & Environmental Security", "PRI": "Data Privacy", "PRM": "Project & Resource Management", + "QTS": "Quantum Security", "RSK": "Risk Management", "SEA": "Secure Engineering & Architecture", "OPS": "Security Operations", @@ -61,9 +62,9 @@ }, "maturity": { "0": "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.", - "1": "Cybersecurity & Data Protection Governance (GOV) capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement and manage the organization's internal control system.\n▪ Legal representation is consulted on an as-needed basis.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -144,9 +145,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-01.1", @@ -169,9 +170,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to trends.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align security, compliance and resilience capabilities with business requirements through a steering committee or advisory board, comprised of key cybersecurity, data protection and business executives, which meets formally and on a regular basis.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align security, compliance and resilience capabilities with business requirements through a steering committee or advisory board, comprised of key cybersecurity, data protection and business executives, which meets formally and on a regular basis.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -247,16 +248,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-01.2", "title": "Status Reporting To Governing Body", "family": "GOV", "description": "Mechanisms exist to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", - "scf_question": "Does the organization provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP)?", + "scf_question": "Does the organization provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to its Security, Compliance & Resilience Program (SCRP)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -278,9 +279,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to trends.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -337,16 +338,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-01.3", "title": "Commitment To Continual Improvements", "family": "GOV", "description": "Mechanisms exist to commit appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", - "scf_question": "Does the organization commit appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies?", + "scf_question": "Does the organization commit appropriate resources needed for continual improvement of its Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -361,7 +362,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to observed trends.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ Appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ Appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -403,9 +404,102 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "GOV-01.4", + "title": "Secure Practices Alignment Justification", + "family": "GOV", + "description": "Mechanisms exist to align the organization’s Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices.", + "scf_question": "Does the organization align its Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align the organization’s Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" ], - "errata": "- wordsmithed" + "possible_solutions": { + "micro_small": "∙ Informal alignment with NIST CSF 2.0, SCF CORE Fundamentals, CIS Controls or another framework that meets the organization's needs.", + "small": "∙ Formal alignment with NIST CSF 2.0, SCF CORE Fundamentals, CIS Controls or another framework that meets the organization's needs.\n∙ Gap analysis documentation\n∙ Written justification for framework choices.", + "medium": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ Documented gap analysis and justification\n∙ GRC platform alignment reports (e.g., SCFConnect)", + "large": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ Regulatory mapping evidence packages\n∙ GRC platform with framework comparison reporting", + "enterprise": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ External auditor validation\n∙ Board-level reporting on framework compliance\n∙ GRC platform with automated framework mapping" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" }, { "control_id": "GOV-02", @@ -431,7 +525,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ People affected by documentation changes are provided notification of the policy and standard changes.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ The organization's cybersecurity policies and standards are made available to internal personnel.\n▪ Documented procedures exist for requesting a deviation from approved standards.\n▪ The responsibility for enforcing cybersecurity and data protection control implementation is assigned to business / process owners and asset custodians.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -504,9 +598,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-02.1", @@ -530,7 +624,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to prohibit exceptions to standards, except when the exception has been formally assessed for risk impact, approved and recorded.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to prohibit exceptions to standards, except when the exception has been formally assessed for risk impact, approved and recorded.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -606,7 +700,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -629,9 +724,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel perform an annual documentation review process that includes the scope of applicable statutory, regulatory and/or contractual obligations.\n▪ Recommendations for documentation edits are submitted for review and are handled in accordance with documentation change control processes.\n▪ Updated documentation versions are published, based on no less than an annual review cycle.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to review the Security, Compliance & Resilience Program (SCRP), including policies, standards and procedures, at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to review the Security, Compliance & Resilience Program (SCRP), including policies, standards and procedures, at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness. ", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -686,9 +781,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-04", @@ -718,9 +813,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is assigned the role and responsibilities to centrally manage, coordinate, develop, implement and maintain a cybersecurity and data protection program (e.g., cybersecurity director or Chief Information Security Officer (CISO)).\n▪ The individual assigned the role and responsibilities to centrally manage, coordinate, develop, implement and maintain a cybersecurity and data protection program develops plans to implement the organization's security, compliance and resiliency-related objectives.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ A qualified individual is assigned the role and responsibilities to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP) (e.g., cybersecurity director or Chief Information Security Officer (CISO)).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ A qualified individual is assigned the role and responsibilities to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP) (e.g., cybersecurity director or Chief Information Security Officer (CISO)).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -791,9 +886,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-04.1", @@ -815,9 +910,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to enforce an accountability structure so that appropriate teams and individuals are empowered, responsible and trained for mapping, measuring and managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to enforce an accountability structure so that appropriate teams and individuals are empowered, responsible and trained for mapping, measuring and managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -902,9 +997,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-04.2", @@ -928,7 +1023,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish an authoritative chain of command with clear lines of communication to remove ambiguity from individuals and teams related to managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish an authoritative chain of command with clear lines of communication to remove ambiguity from individuals and teams related to managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1008,9 +1103,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-05", @@ -1032,11 +1127,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Basic metrics are developed to provide operational oversight of a limited scope of cybersecurity and data protection controls.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -1082,9 +1177,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-05.1", @@ -1104,11 +1199,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -1151,9 +1246,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-05.2", @@ -1177,9 +1272,9 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to observed trends.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -1225,9 +1320,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-06", @@ -1249,9 +1344,9 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity personnel identify and maintain contact information for local and national law enforcement (e.g., FBI field office) in case of cybersecurity incidents that require law enforcement involvement.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -1300,7 +1395,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -1323,11 +1419,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Cybersecurity and data privacy personnel identify and maintain contact information for local, regional and national cybersecurity / data privacy groups and associations.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.\n", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -1392,16 +1488,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-08", "title": "Defining Business Context & Mission", "family": "GOV", "description": "Mechanisms exist to define the context of its business model and document the organization's mission.", - "scf_question": "Does the organization define the context of its business model and document the mission of the organization?", + "scf_question": "Does the organization define the context of its business model and document its mission?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1416,9 +1512,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ The context of the entity's business model and its mission are documented.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ The context of the entity's business model and its mission are documented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1489,7 +1585,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -1497,7 +1594,7 @@ "title": "Define Control Objectives", "family": "GOV", "description": "Mechanisms exist to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", - "scf_question": "Does the organization establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system?", + "scf_question": "Does the organization establish control objectives as the basis for the selection, implementation and management of its internal security, compliance and resilience control system?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1514,7 +1611,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1584,16 +1681,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-10", "title": "Data Governance", "family": "GOV", - "description": "Mechanisms exist to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization facilitate data governance to oversee its policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive and/or regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization facilitate data governance to oversee its policies, standards and procedures so that sensitive and/or regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -1608,7 +1705,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Administrative processes require all employees and contractors to apply cybersecurity and data protection principles in their daily work (e.g., policies & standards).\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1681,9 +1778,108 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "GOV-10.1", + "title": "Data Catalog", + "family": "GOV", + "description": "Mechanisms exist to identify and catalog the organization's data holdings in a structured format to document each significant data asset.", + "scf_question": "Does the organization identify and catalog its data holdings in a structured format to document each significant data asset?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and catalog the organization's data holdings in a structured format to document each significant data asset.", + "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Spreadsheet-based data inventory\n∙ Manual data catalog template", + "small": "∙ Spreadsheet data catalog with sensitivity classifications\n∙ Data classification register for significant data assets", + "medium": "∙ Data catalog platform (e.g., Collibra, Alation)\n∙ Structured data inventory with metadata\n∙ Microsoft Purview basic tier (https://microsoft.com)", + "large": "∙ Enterprise data catalog (e.g., Collibra (https://collibra.com), Alation (https://alation.com))\n∙ Data lineage tracking\n∙ Microsoft Purview (https://microsoft.com)", + "enterprise": "∙ Enterprise data catalog with automated discovery\n∙ Microsoft Purview or equivalent (https://microsoft.com)\n∙ Automated data lineage and classification at scale" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" + }, { "control_id": "GOV-11", "title": "Purpose Validation", @@ -1702,9 +1898,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to monitor mission/business-critical Technology Assets, Applications and/or Services (TAAS) to ensure those resources are being used consistent with their intended purpose.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to monitor mission/business-critical Technology Assets, Applications and/or Services (TAAS) to ensure those resources are being used consistent with their intended purpose.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1769,15 +1965,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "GOV-12", "title": "Forced Technology Transfer (FTT)", "family": "GOV", - "description": "Mechanisms exist to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", - "scf_question": "Does the organization avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices?", + "description": "Mechanisms exist to avoid and/or constrain the forced exfiltration of sensitive and/or regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", + "scf_question": "Does the organization avoid and/or constrain the forced exfiltration of sensitive and/or regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -1790,9 +1987,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1856,7 +2053,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -1877,9 +2075,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to constrain the host government's ability to leverage the organization's Technology Assets, Applications and/or Services (TAAS) for economic or political espionage and/or cyberwarfare activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to constrain the host government's ability to leverage the organization's Technology Assets, Applications and/or Services (TAAS) for economic or political espionage and/or cyberwarfare activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1943,7 +2141,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -1964,9 +2163,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to incorporate security, compliance and resilience principles into Business As Usual (BAU) practices through executive leadership involvement.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to incorporate security, compliance and resilience principles into Business As Usual (BAU) practices through executive leadership involvement.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2029,16 +2228,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-15", "title": "Operationalizing Security, Compliance & Resilience Capabilities", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -2053,9 +2252,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2147,16 +2346,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed" + "errata": "- wordsmithed" }, { "control_id": "GOV-15.1", "title": "Select Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2169,9 +2369,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2247,7 +2447,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed" }, @@ -2255,8 +2456,8 @@ "control_id": "GOV-15.2", "title": "Implement Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2269,9 +2470,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2362,7 +2563,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed" }, @@ -2370,8 +2572,8 @@ "control_id": "GOV-15.3", "title": "Assess Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", - "scf_question": "Does the organization compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended?", + "description": "Mechanisms exist to compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", + "scf_question": "Does the organization compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2384,9 +2586,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2476,7 +2678,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed" }, @@ -2498,9 +2701,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to obtain authorization for the production use of each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to obtain authorization for the production use of each Technology Asset, Application and/or Service (TAAS) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2590,7 +2793,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -2611,9 +2815,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to monitor Technology Assets, Applications, Services and/or Data (TAASD) under their control on an ongoing basis for applicable threats and risks, as well as to ensure security, compliance and resilience controls are operating as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to monitor Technology Assets, Applications, Services and/or Data (TAASD) under their control on an ongoing basis for applicable threats and risks, as well as to ensure security, compliance and resilience controls are operating as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2703,9 +2907,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-16", @@ -2727,9 +2931,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define materiality threshold criteria capable of designating an incident as material.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define materiality threshold criteria capable of designating an incident as material.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2766,7 +2970,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -2789,9 +2994,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a risk as a material risk.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a risk as a material risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2825,7 +3030,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -2848,9 +3054,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a threat as a material threat.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a threat as a material threat.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2884,7 +3090,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -2892,7 +3099,7 @@ "title": "Security, Compliance & Resilience Status Reporting", "family": "GOV", "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.", - "scf_question": "Does the organization submit status reporting of the organization's security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required?", + "scf_question": "Does the organization submit status reporting of its security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -2907,9 +3114,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2952,9 +3159,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-18", @@ -2976,7 +3183,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Unstructured review of the cybersecurity and/or data privacy program is performed on an annual basis.\n▪ Administrative processes require all employees and contractors to apply cybersecurity and data protection principles in their daily work (e.g., policies & standards).", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to govern a Quality Management System (QMS) to ensure security, compliance and resilience processes conform with applicable statutory, regulatory and/or contractual obligations.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to govern a Quality Management System (QMS) to ensure security, compliance and resilience processes conform with applicable statutory, regulatory and/or contractual obligations.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3049,9 +3256,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-19", @@ -3073,7 +3280,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define the basis for confidence that implemented practices conform to applicable security, compliance and resilience controls, where the control implementation performs as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define the basis for confidence that implemented practices conform to applicable security, compliance and resilience controls, where the control implementation performs as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3128,9 +3335,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "GOV-19.1", @@ -3152,7 +3359,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assurance Levels (AL) for assessment activities to standardize the following assurance attributes:\n(1) Depth that addresses the rigor and level of detail of the assessment; and\n(2) Coverage that addresses the scope and breadth of the assessment.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assurance Levels (AL) for assessment activities to standardize the following assurance attributes:\n(1) Depth that addresses the rigor and level of detail of the assessment; and\n(2) Coverage that addresses the scope and breadth of the assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3206,7 +3413,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -3229,7 +3437,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assessment Objectives (AO) to assess the implementation of requirements, when available.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assessment Objectives (AO) to assess the implementation of requirements, when available.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3283,16 +3491,17 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "GOV-20", - "title": "Mergers, Acquisitions & Divestitures (MA&D)", + "control_id": "GOV-19.3", + "title": "Security, Compliance & Resilince Outsourcing Limitations", "family": "GOV", - "description": "Mechanisms exist to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", - "scf_question": "Does the organization define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities?", - "relative_weight": 6, + "description": "Mechanisms exist to ensure organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations.", + "scf_question": "Does the organization ensure third-parties involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", @@ -3300,13 +3509,13 @@ "scrm_focus": { "strategic": true, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", - "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to ensure organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3314,13 +3523,121 @@ "Community Derived" ], "possible_solutions": { - "medium": "∙ Documented M&A/divestiture security procedures", - "large": "∙ Formal M&A security due diligence checklist\n∙ Documented integration/separation procedures", - "enterprise": "∙ Enterprise M&A security playbook\n∙ Dedicated M&A security team\n∙ Legal and compliance integration\n∙ Technical due diligence framework" + "micro_small": "∙ Vendor due diligence checklist\n∙ Third-party security questionnaire (e.g., CAIQ, SIG)", + "small": "∙ Vendor security questionnaire (CAIQ or SIG)\n∙ Third-party risk assessment prior to outsourcing", + "medium": "∙ Third-party risk management program\n∙ Vendor security assessments with contractual security obligations\n∙ Contract security requirements for outsourced functions", + "large": "∙ Third-party risk management (TPRM) program\n∙ Vendor SOC 2 and ISO 27001 certification requirements\n∙ Contractual security and compliance obligations", + "enterprise": "∙ Enterprise TPRM program with automated vendor risk assessment\n∙ Third-party risk ratings (e.g., BitSight, SecurityScorecard)\n∙ Contractual oversight and audit rights for outsourced functions" }, "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", "R-AC-4", - "R-EX-1" + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-14", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" + }, + { + "control_id": "GOV-20", + "title": "Mergers, Acquisitions & Divestitures (MA&D)", + "family": "GOV", + "description": "Mechanisms exist to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "scf_question": "Does the organization define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities?", + "relative_weight": 6, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "medium": "∙ Documented M&A/divestiture security procedures", + "large": "∙ Formal M&A security due diligence checklist\n∙ Documented integration/separation procedures", + "enterprise": "∙ Enterprise M&A security playbook\n∙ Dedicated M&A security team\n∙ Legal and compliance integration\n∙ Technical due diligence framework" + }, + "risks": [ + "R-AC-4", + "R-EX-1" ], "threats": [ "NT-2", @@ -3360,7 +3677,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -3383,7 +3701,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provision a Virtual Data Room (VDR), or similar technology, to securely share documentation among stakeholders to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provision a Virtual Data Room (VDR), or similar technology, to securely share documentation among stakeholders to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3440,9 +3758,104 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "GOV-21", + "title": "High Value Assets (HVAs)", + "family": "GOV", + "description": "Mechanisms exist to identify and catalog the organization's High Value Assets (HVAs) (e.g., crown jewels), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA;\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a HVA based on business process criticality or dependency relationships;\n(3) Location of HVA Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements.", + "scf_question": "Does the organization identify and catalog its High Value Assets (HVAs) (e.g., crown jewels), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA;\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a HVA based on business process criticality or dependency relationships;\n(3) Location of HVA Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and catalog the organization's High Value Assets (HVAs), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA (e.g., \"crown jewel\" IP);\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a \"crown jewel,\" based on business process criticality or dependency relationships;\n(3) Location of \"crown jewel\" Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Manual identification of most critical business assets\n∙ HVA asset register (spreadsheet)", + "small": "∙ HVA asset register with basic protection requirements\n∙ Critical asset identification by business process dependency", + "medium": "∙ HVA identification process\n∙ Critical asset register with minimum protection requirements\n∙ Risk-based prioritization of HVA assets", + "large": "∙ Formal HVA identification program\n∙ Critical asset protection requirements matrix\n∙ Regular HVA review cycle", + "enterprise": "∙ Enterprise HVA program with board-level visibility\n∙ Integrated critical asset protection within GRC platform\n∙ Threat modeling centered on HVA assets" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-GV-1" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" + }, { "control_id": "AAT-01", "title": "Artificial Intelligence (AI) & Autonomous Technologies Governance", @@ -3552,7 +3965,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -3641,7 +4055,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -3744,7 +4159,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -3765,7 +4181,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to sustain the value of deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3844,7 +4260,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -3945,9 +4362,112 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "AAT-01.5", + "title": "Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization", + "family": "AAT", + "description": "Mechanisms exist to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements.", + "scf_question": "Does the organization assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ AI system inventory with basic use-case categorization\n∙ NIST AI RMF categorization guidance.\n∙ Designated responsible party for AI tools in use", + "small": "∙ AI system inventory with risk-based categorization\n∙ NIST AI RMF categorization guidance\n∙ EU AI Act risk tier mapping.", + "medium": "∙ Formal AI system categorization process\n∙ EU AI Act risk tier mapping\n∙ NIST AI RMF implementation\n∙ AI risk register with categorization metadata", + "large": "∙ Formal AI governance program with defined categorization criteria\n∙ EU AI Act compliance mapping\n∙ NIST AI RMF full implementation\n∙ AI Risk Management Committee-approved categorization", + "enterprise": "∙ Enterprise AI categorization program with automated registry\n∙ EU AI Act and ISO/IEC 42001 alignment\n∙ Board-level AI risk reporting by category" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" + }, { "control_id": "AAT-02", "title": "Situational Awareness of AI & Autonomous Technologies", @@ -4046,7 +4566,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -4145,7 +4666,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -4244,9 +4766,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "AAT-02.3", @@ -4266,7 +4788,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT include reasonable security, compliance and resilience protections that are commensurate with assessed risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4345,9 +4867,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "AAT-02.4", @@ -4447,7 +4969,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -4546,7 +5069,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -4567,7 +5091,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to define and document the organization's mission and defined goals for AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4645,7 +5169,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -4747,7 +5272,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -4835,7 +5361,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -4933,7 +5460,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5031,7 +5559,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5129,7 +5658,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5214,7 +5744,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5315,7 +5846,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5414,7 +5946,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5516,7 +6049,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5618,7 +6152,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5720,7 +6255,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5819,7 +6355,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -5919,7 +6456,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6020,15 +6558,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "AAT-09.1", "title": "AI & Autonomous Technologies High Risk Designations", "family": "AAT", - "description": "Mechanisms exist to designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", - "scf_question": "Does the organization designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making?", + "description": "Mechanisms exist to designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one (1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", + "scf_question": "Does the organization designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one (1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making?", "relative_weight": 7, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -6041,7 +6580,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to designate AAT \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6121,7 +6660,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6145,7 +6685,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices to enable AAT-related security, resilience and compliance-related conformity testing throughout the lifecycle of the AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6225,7 +6765,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6246,7 +6787,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate AAT for trustworthy behavior and operation including security, anonymization and disaggregation of captured and stored data for approved purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6325,7 +6866,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6346,7 +6888,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to document test sets, metrics and details about the tools used during Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6424,7 +6966,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6445,7 +6988,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to demonstrate the AAT to be deployed are:\n(1) Valid;\n(2) Reliable; and\n(3) Operate as intended, based on approved designs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6523,7 +7066,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6544,7 +7088,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to demonstrate the AAT to be deployed are safe, residual risk does not exceed the organization's risk tolerance and can fail safely, particularly if made to operate beyond its knowledge limits.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6622,7 +7166,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6643,7 +7188,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the security and resilience of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6721,7 +7266,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6742,7 +7288,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine risks associated with transparency and accountability of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6806,7 +7352,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6827,7 +7374,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine the data privacy risk of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6891,7 +7438,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6912,7 +7460,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine fairness and bias of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6976,7 +7524,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -6997,7 +7546,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate the AAT model.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7075,7 +7624,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7096,7 +7646,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the results of Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) to determine the viability of the proposed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7157,7 +7707,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7178,7 +7729,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the effectiveness of the processes utilized to perform Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7256,7 +7807,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7277,7 +7829,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate AAT-related performance or the assurance criteria demonstrated for conditions similar to deployment settings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7355,7 +7907,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7376,7 +7929,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to proactively and continuously monitor deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7455,7 +8008,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7476,7 +8030,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to integrate continual improvements for deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7537,7 +8091,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7558,7 +8113,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to report the status and results of Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) to relevant stakeholders, including governing bodies, as required.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7636,7 +8191,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7657,7 +8213,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate claims of AAT model capabilities using empirically validated methods.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7735,7 +8291,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7743,7 +8300,7 @@ "title": "AI TEVV Benchmarking Content Provenance", "family": "AAT", "description": "Mechanisms exist to benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry-recognized standards.", - "scf_question": "Does the organization benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry -recognized standards?", + "scf_question": "Does the organization benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry-recognized standards?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7756,7 +8313,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to benchmark the verifiable lineage and origin of content used by AAT according to industry-recognized standards.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7834,7 +8391,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -7855,7 +8413,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to mitigate concerns of model collapse by:\n(1) Assessing the proportion of synthetic to non-synthetic training data; and\n(2) Verifying training data is not overly homogenous or AAT system-produced.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7933,7 +8491,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8033,7 +8592,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8134,7 +8694,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8233,7 +8794,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8332,7 +8894,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8431,7 +8994,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8454,7 +9018,7 @@ "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to communicate AAT-related incidents and/or errors to relevant stakeholders, including affected communities.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to communicate AAT-related incidents and/or errors to relevant stakeholders, including affected communities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8530,7 +9094,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8619,7 +9184,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8717,7 +9283,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8813,7 +9380,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -8912,7 +9480,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -9011,42 +9580,41 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "AAT-13", - "title": "AI & Autonomous Technologies Stakeholder Diversity", + "control_id": "AAT-12.5", + "title": "Training Data Source & Integrity", "family": "AAT", - "description": "Mechanisms exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise.", - "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise?", - "relative_weight": 8, + "description": "Mechanisms exist to validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT).", + "scf_question": "Does the organization validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT)?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], - "pptdf": "People", - "nist_csf_function": "Identify", + "pptdf": "Process", + "nist_csf_function": "Protect", "scrm_focus": { "strategic": false, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", - "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE AI Model Deployment" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "medium": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "large": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "enterprise": "∙ Artificial Intelligence (AI) / autonomous technologies governance program" + "micro_small": "∙ Documented training data provenance\n∙ Basic data quality checks before model training\n∙ Vendor attestations for third-party training data", + "small": "∙ Training data source documentation\n∙ Vendor-supplied training data integrity attestations\n∙ Data quality validation before training", + "medium": "∙ Training data validation pipeline\n∙ Data provenance documentation\n∙ Data integrity checks (hash verification, data quality metrics)", + "large": "∙ Formal training data governance program\n∙ Automated data quality and integrity validation\n∙ Training data lineage tracking", + "enterprise": "∙ Enterprise AI data governance framework\n∙ Automated training data validation pipelines\n∙ Third-party training data audits\n∙ Data integrity monitoring throughout the AI lifecycle" }, "risks": [ "R-AC-1", @@ -9110,7 +9678,208 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ], + "errata": "- new control - SM-2088" + }, + { + "control_id": "AAT-12.6", + "title": "Prohibit Training", + "family": "AAT", + "description": "Mechanisms exist to prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "scf_question": "Does the organization prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Acceptable Use Policy (AUP) prohibiting unauthorized AI training\n∙ Contractual review of AI vendor terms of service", + "small": "∙ AI usage policy prohibiting unauthorized training\n∙ Employee acknowledgment of AI data use restrictions", + "medium": "∙ AI usage policy prohibiting unauthorized training on organizational data\n∙ Vendor contract reviews for training restrictions\n∙ Data Handling Agreements (DHA) with AI vendors", + "large": "∙ Formal AI data usage policy\n∙ Technical controls preventing data uploads to unauthorized AI systems\n∙ Data Loss Prevention (DLP) for AI training data", + "enterprise": "∙ Enterprise AI data governance policy\n∙ DLP controls restricting data to authorized AI platforms\n∙ Automated enforcement of training data restrictions\n∙ Regular audits of AI vendor training data handling" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2103" + }, + { + "control_id": "AAT-13", + "title": "AI & Autonomous Technologies Stakeholder Diversity", + "family": "AAT", + "description": "Mechanisms exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise.", + "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "People", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE AI Model Deployment" + ], + "possible_solutions": { + "micro_small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "medium": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "large": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "enterprise": "∙ Artificial Intelligence (AI) / autonomous technologies governance program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { @@ -9209,7 +9978,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -9308,7 +10078,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -9407,7 +10178,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -9506,7 +10278,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -9606,7 +10379,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -9706,7 +10480,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -9806,7 +10581,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -9907,7 +10683,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10006,7 +10783,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10105,9 +10883,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "AAT-16.3", @@ -10205,7 +10983,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10304,7 +11083,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10403,7 +11183,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10504,7 +11285,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10604,7 +11386,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10703,7 +11486,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10803,7 +11587,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10824,7 +11609,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to perform an investigation when there is a serious incident involving operational AAT that documents a:\n(1) Root Cause Analysis (RCA);\n(2) Risk assessment of the incident; and \n(3) Description of corrective actions taken, including measures implemented to prevent a recurrence of the incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10903,7 +11688,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -10924,7 +11710,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to analyze anomalous AAT behavior and provide escalation paths for human oversight, including:\n(1) Real-time review; and\n(2) Intervention.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11004,7 +11790,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11025,7 +11812,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to require human review and clear escalation paths for approval for high-risk or ambiguous AAT actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11105,7 +11892,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11126,7 +11914,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and contain emergent or collusive behaviors among multiple AAT, including:\n(1) Automated or human-triggered containment; and \n(2) Formal investigation to determine the root cause of agentic cascades or collusion.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11206,7 +11994,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11305,7 +12094,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11407,7 +12197,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11508,7 +12299,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11608,7 +12400,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11708,7 +12501,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11806,7 +12600,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -11905,9 +12700,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "AAT-18", @@ -12007,7 +12802,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12028,7 +12824,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prioritize, respond to and remediate AAT-related risks based on assessments and other analytical output.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12108,7 +12904,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12129,7 +12926,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure deployed AAT conform to applicable statutory and regulatory requirements, based on:\n(1) Defined use cases;\n(2) Geographic markets; and\n(3) Use of Intellectual Property (IP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12209,7 +13006,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12230,7 +13028,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that utilize manipulative or deceptive techniques (including biased data) to impair an individual's ability to make a reasonably informed decision.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12309,7 +13107,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12330,7 +13129,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that exploit a human subject to materially affect a targeted behavior due to their:\n(1) Age;\n(2) Disability; or \n(3) Specific social or economic situation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12409,7 +13208,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12430,7 +13230,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that: \n(1) Evaluate human subjects over a certain period of time based on their social behavior or known, inferred or predicted personal or personality characteristics; and\n(2) Assign a \"social score\" branding or equivalent classification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12509,7 +13309,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12530,7 +13331,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that lead to the detrimental or unfavorable treatment of certain data subjects, or groups of data subjects, in social contexts that is:\n(1) Are unrelated to the contexts in which the data was originally generated or collected; and/or\n(2) Is unjustified or disproportionate to their social behavior or its gravity.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12609,7 +13410,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12630,7 +13432,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that:\n(1) Assess the risk of an individual committing a criminal offence; and\n(2) Predicts risk based solely on the profiling of personality traits and characteristics.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12709,7 +13511,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12730,7 +13533,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that create, or expand, facial recognition databases through scraping facial images from:\n(1) The Internet; or \n(2) Closed-Circuit Television (CCTV) footage.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12809,7 +13612,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -12830,7 +13634,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that infer human emotions of an individual based on observed characteristics.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12909,7 +13713,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13009,7 +13814,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13017,7 +13823,7 @@ "title": "AI & Autonomous Technologies Development Practices", "family": "AAT", "description": "Measures exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals.", - "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness, and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals?", + "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13034,7 +13840,7 @@ "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ Measures exist to ensure AAT are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals.", "4": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -13109,7 +13915,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13209,7 +14016,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13309,7 +14117,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13330,7 +14139,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to document the extent to which human domain knowledge is employed to improve AAT performance including:\n(1) Reinforcement Learning from Human Feedback (RLHF);\n(2) Fine-tuning;\n(3) Retrieval- augmented generation;\n(4) Content moderation; and\n(5) Business rules.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13408,7 +14217,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13506,7 +14316,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13607,7 +14418,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13708,7 +14520,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13809,7 +14622,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -13908,7 +14722,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14007,7 +14822,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14106,7 +14922,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14205,7 +15022,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14304,7 +15122,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14403,7 +15222,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14502,7 +15322,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14602,7 +15423,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14702,7 +15524,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14801,7 +15624,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14900,7 +15724,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -14999,7 +15824,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15098,7 +15924,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15197,7 +16024,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15296,7 +16124,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15395,7 +16224,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15416,7 +16246,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to assign personnel to review AAT-generated content for alignment with culturally accepted norms.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15494,7 +16324,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15515,7 +16346,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI models are designed with resilience capabilities that are sufficient to withstand reasonable threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15594,7 +16425,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15615,7 +16447,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent \"model pollution\" due to accidental and/or malicious inputs by an AI agent that can negatively alter the AI model.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15694,7 +16526,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15715,7 +16548,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and prevent the propagation of false data (e.g., hallucinations) within the AI model or between AI agents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15794,7 +16627,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15815,7 +16649,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to monitor and prevent resource overload or Denial of Service (DoS) conditions through:\n(1) Enforcement of quotas;\n(2) Workload controls; and \n(3) Auto-suspension of runaway AI agent processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15894,7 +16728,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -15915,7 +16750,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agents are designed, developed and deployed to securely operate under human oversight.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15995,7 +16830,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -16016,7 +16852,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to protect, isolate and harden infrastructure resources used by AI agents, including:\n(1) Resource allocation;\n(2) Privilege management;\n(3) Network segmentation; and \n(4) Workload isolation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16096,7 +16932,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -16117,7 +16954,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement limitations for AI agents according to:\n(1) Least privileges, where the AI agent operates with the minimal permissions necessary to perform designated tasks; and\n(2) Least functionality, where the AI agent is restricted to communicate with the minimal Technology Assets, Applications and/or Services (TAAS) and networks necessary to perform designated tasks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16197,7 +17034,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -16218,7 +17056,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to authenticate, authorize, validate and monitor all tool and Application Programming Interface (API) invocations by AI agents, including;\n(1) Schema validation;\n(2) Rate limiting;\n(3) Access controls; and\n(4) Output validation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16298,7 +17136,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -16319,7 +17158,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate, secure and restrict AI agent orchestration protocols to prevent:\n(1) Unauthorized tool chaining;\n(2) Context manipulation; and/or\n(3) Protocol-based escalation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16399,7 +17238,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -16420,7 +17260,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate, sanitize and monitor all data inputs and retrieval pipelines for AI agents to:\n(1) Ensure data provenance; and \n(2) Prevent unauthorized access risks (e.g., injection, manipulation or exfiltration).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16500,7 +17340,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -16521,7 +17362,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent privilege escalation or unauthorized delegation by AI agents by:\n(1) Monitoring and enforcing dynamic roles; and\n(2) Establishing cross-agent delegation boundaries and privileged actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16601,15 +17442,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "AAT-29.7", "title": "AI Agent Data Access Restrictions", "family": "AAT", - "description": "Mechanisms exist to restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", - "scf_question": "Does the organization restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data?", + "description": "Mechanisms exist to restrict agent access to sensitive and/or regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", + "scf_question": "Does the organization restrict agent access to sensitive and/or regulated data so that AI agents cannot ingest, generate or act on unauthorized data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16622,7 +17464,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16702,15 +17544,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "AAT-29.8", "title": "Data Extraction", "family": "AAT", - "description": "Mechanisms exist to prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point.", - "scf_question": "Does the organization prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point?", + "description": "Mechanisms exist to prevent AI agents from extracting sensitive and/or regulated data from volatile memory that can be exploited at a later point.", + "scf_question": "Does the organization prevent AI agents from extracting sensitive and/or regulated data from volatile memory that can be exploited at a later point?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16723,7 +17566,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16803,7 +17646,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -16824,7 +17668,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure user identification and authentication methods are capable of preventing AI agents from \n(1) Spoofing;\n(2) Mimicry; and/or\n(3) Impersonation attacks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16904,7 +17748,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -16925,7 +17770,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent AI agent logic from being subverted or manipulated.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17005,7 +17850,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17026,7 +17872,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to utilize a \"sandbox\" capability to restrict AI agents from unrestricted access to both local and remote resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17106,7 +17952,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17127,7 +17974,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and mitigate prompt injection / input attacks that seek to manipulate AI agent instructions, bypass security, compliance and/or resilience controls or result in unauthorized actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17207,9 +18054,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "AAT-29.13", @@ -17229,7 +18076,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to allow authorized users or operators to immediately halt or disable AI agent activity in case of unexpected behavior or harm.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17309,7 +18156,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17330,7 +18178,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to regularly conduct adversarial testing that simulates attacks against AI agents to identify and mitigate vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17410,7 +18258,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17431,7 +18280,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to control, restrict and log AI agent self-modification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17511,7 +18360,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17532,7 +18382,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict purging of any persistent memory or long-term data used by AI agents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17612,7 +18462,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17633,7 +18484,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict agentic delegation, chaining and multi-agent communication to prevent unauthorized task escalation or emergent risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17713,7 +18564,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17734,7 +18586,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to continuously monitor for behavioral drift or deviation from established AI agent baselines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17814,7 +18666,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17835,7 +18688,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure that all AI agent-initiated actions are properly mapped to authenticated user or system identities, with enforced authorization checks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17915,7 +18768,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -17936,7 +18790,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to provide comprehensive audit trails of AI agent actions including:\n(1) Rationales; and \n(2) User/trigger mappings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18016,7 +18870,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -18037,7 +18892,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to:\n(1) Provide human-understandable explanations for significant AI agent actions or decisions; and \n(2) Enable users to contest outcomes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18117,7 +18972,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -18138,7 +18994,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect unfair, unethical or biased AI agent actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18218,7 +19074,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -18239,7 +19096,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate AI agent-generated outputs through the use of:\n(1) Content scanning; and\n(2) Output vetting through human approvals, where appropriate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18319,15 +19176,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "AAT-30", - "title": "Agentic Output Traceability & Repudiation", + "control_id": "AAT-29.24", + "title": "Resource Limiting", "family": "AAT", - "description": "Mechanisms exist to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", - "scf_question": "Does the organization ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability?", + "description": "Automated mechanisms exist to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget).", + "scf_question": "Does the organization use automated mechanisms to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18340,62 +19198,26 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget).", + "4": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, - "profiles": [ - "Community Derived", - "CORE AI-Enabled Operations", - "CORE AI Model Deployment" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Document relevant policy and procedures", - "small": "∙ Written policy and procedures\n∙ Designated responsible owner\n∙ Annual review", - "medium": "∙ Formal program with documented processes\n∙ Regular review and testing", - "large": "∙ Enterprise program with dedicated resources\n∙ Automated tooling\n∙ Metrics tracking", - "enterprise": "∙ Enterprise platform with dedicated team\n∙ Automated monitoring\n∙ Continuous improvement program" + "micro_small": "∙ Cloud provider resource quotas and budget alerts\n∙ API rate limiting for AI tool usage\n∙ Basic AI tool usage monitoring", + "small": "∙ Cloud provider resource quotas and API rate limiting\n∙ Cost alerting for AI workload spend", + "medium": "∙ Resource quotas and limits in AI deployment platforms\n∙ Cloud cost management tools (e.g., AWS Cost Explorer, Azure Cost Management)\n∙ API rate limiting and throttling", + "large": "∙ Enterprise resource governance for AI workloads\n∙ Cloud FinOps practices\n∙ Automated resource limit enforcement\n∙ AI workload monitoring and alerting", + "enterprise": "∙ Enterprise AI resource governance platform\n∙ Automated resource limit enforcement with alerting\n∙ AI workload orchestration (e.g., Kubernetes resource limits)\n∙ FinOps program for AI infrastructure costs" }, "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-BC-5", "R-EX-1", "R-EX-2", "R-EX-3", "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-GV-8", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" + "R-GV-1" ], "threats": [ "NT-2", @@ -18420,15 +19242,17 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2090 & 2091" }, { - "control_id": "AAT-30.1", - "title": "AI Agent Logging", + "control_id": "AAT-30", + "title": "Agentic Output Traceability & Repudiation", "family": "AAT", - "description": "Mechanisms exist to generate event logs for Artificial Intelligence (AI) and Autonomous Technologies (AAT) actions to ensure transparency and auditability.", - "scf_question": "Does the organization generate event logs for Artificial Intelligence (AI) and Autonomous Technologies (AAT) actions to ensure transparency and auditability?", + "description": "Mechanisms exist to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", + "scf_question": "Does the organization ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18441,9 +19265,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to generate event logs for AAT actions to ensure transparency and auditability.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -18521,7 +19345,110 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "AAT-30.1", + "title": "AI Agent Logging", + "family": "AAT", + "description": "Mechanisms exist to generate event logs for Artificial Intelligence (AI) and Autonomous Technologies (AAT) actions to ensure transparency and auditability.", + "scf_question": "Does the organization generate event logs for Artificial Intelligence (AI) and Autonomous Technologies (AAT) actions to ensure transparency and auditability?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to generate event logs for AAT actions to ensure transparency and auditability.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived", + "CORE AI-Enabled Operations", + "CORE AI Model Deployment" + ], + "possible_solutions": { + "micro_small": "∙ Document relevant policy and procedures", + "small": "∙ Written policy and procedures\n∙ Designated responsible owner\n∙ Annual review", + "medium": "∙ Formal program with documented processes\n∙ Regular review and testing", + "large": "∙ Enterprise program with dedicated resources\n∙ Automated tooling\n∙ Metrics tracking", + "enterprise": "∙ Enterprise platform with dedicated team\n∙ Automated monitoring\n∙ Continuous improvement program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { @@ -18542,7 +19469,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to control AI agent sessions by:\n(1) Embedding session IDs into the requests to the AI model;\n(2) Implementing capabilities to correlate sessions; and\n(3) Terminating sessions after a defined time period.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18622,7 +19549,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -18643,7 +19571,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent cognitive overload or decision fatigue for humans-in-the-loop (HITL) through risk-based prioritization.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18723,7 +19651,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -18744,7 +19673,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement Robotic Process Automation (RPA) to improve efficiency, accuracy and speed for high-volume, repetitive and rules-based business processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18822,7 +19751,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -18921,9 +19851,111 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "AAT-33", + "title": "Release Owner Gate (ROG) For AI-Augmented Content", + "family": "AAT", + "description": "Mechanisms exist to implement a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization.", + "scf_question": "Does the organization implement a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to govern a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Manual review and approval process before publishing AI-generated content\n∙ Designated content reviewer for AI-assisted materials", + "small": "∙ Documented AI content review workflow\n∙ SME review checklist for AI-augmented content\n∙ Management sign-off before external release", + "medium": "∙ Formal content release workflow with ROG checkpoint\n∙ SME review requirements for AI-augmented content\n∙ CMS approval workflow for externally published content", + "large": "∙ Enterprise ROG program with defined approval authorities\n∙ Automated flagging of AI-augmented content for review\n∙ Cross-functional review panel for sensitive AI content", + "enterprise": "∙ Enterprise AI content governance program\n∙ Automated AI content detection and flagging\n∙ Multi-stage ROG approval workflows in enterprise CMS\n∙ Board-level visibility into high-risk AI content releases" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" + }, { "control_id": "AST-01", "title": "Asset Governance", @@ -18944,11 +19976,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to facilitate an IT Asset Management (ITAM) program to implement and manage asset management controls.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -19019,7 +20051,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19044,7 +20077,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ Data / process owners maintain limited network diagrams to document the flow of sensitive/regulated data that is specific to their initiative.\n▪ Inventory of physical technology assets are assigned to individual users or teams and covers common devices (e.g., laptops, workstations and servers).\n▪ No structured process exists to review or share the results of the inventories.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to i identify and assess the security of Technology Assets, Applications and/or Services (TAAS) that support more than one critical business function.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to i identify and assess the security of Technology Assets, Applications and/or Services (TAAS) that support more than one critical business function. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -19107,9 +20140,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "AST-01.2", @@ -19131,7 +20164,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Inventories may be manual (e.g., spreadsheets) or automated.\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to identify and involve pertinent stakeholders of critical TAASD to support the ongoing secure management of those assets.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -19176,7 +20209,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19197,7 +20231,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement a scalable, standardized naming convention for TAASD that avoids asset naming conflicts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -19251,7 +20285,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19274,7 +20309,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ Inventory of physical technology assets are assigned to individual users or teams and covers common devices (e.g., laptops, workstations and servers).\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ No structured process exists to review or share the results of the inventories.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain a current list of approved technologies (hardware and software).", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain a current list of approved technologies (hardware and software). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -19345,7 +20380,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19399,9 +20435,9 @@ "MT-5", "MT-8", "MT-9", - "MT-10" - ], - "errata": "- new control (SCF)" + "MT-10", + "MT-28" + ] }, { "control_id": "AST-02", @@ -19426,11 +20462,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Inventories may be manual (e.g., spreadsheets) or automated.\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ No structured process exists to review or share the results of the inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to perform inventories of TAASD that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -19504,7 +20540,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19525,9 +20562,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to update asset inventories as part of component installations, removals and asset upgrades.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to update asset inventories as part of component installations, removals and asset upgrades. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -19566,7 +20603,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19587,7 +20625,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to automatically detect and alert upon the detection of unauthorized hardware, software and firmware components.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -19626,7 +20664,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19698,7 +20737,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19723,9 +20763,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to document and govern instances of approved deviations from established baseline configurations.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to document and govern instances of approved deviations from established baseline configurations. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -19783,7 +20823,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19804,7 +20845,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to automatically employ Network Access Control (NAC), or a similar technology, which is capable of detecting unauthorized devices and disable network access to those unauthorized devices.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -19819,7 +20860,7 @@ "small": "∙ VLAN segmentation to isolate unknown devices\n∙ MAC address filtering (basic NAC)\n∙ Wireless access point policies", "medium": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Open-source NAC (e.g., PacketFence)", "large": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ 802.1X certificate-based authentication", - "enterprise": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Zero Trust Network Access (ZTNA) integration\n∙ 802.1X with EAP-TLS and certificate infrastructure" + "enterprise": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Zero Trust Network Architecture (ZTNA) integration\n∙ 802.1X with EAP-TLS and certificate infrastructure" }, "risks": [ "R-AC-1", @@ -19871,7 +20912,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19896,7 +20938,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to enable Dynamic Host Configuration Protocol (DHCP) server logging to improve asset inventories and assist in detecting unknown systems.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to enable Dynamic Host Configuration Protocol (DHCP) server logging to improve asset inventories and assist in detecting unknown systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -19953,7 +20995,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -19976,7 +21019,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors are primarily administrative and preventative in nature.", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to protect Intellectual Property (IP) rights with software licensing restrictions.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to protect Intellectual Property (IP) rights with software licensing restrictions.\n", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -20024,15 +21067,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "AST-02.8", "title": "Data Action Mapping", "family": "AST", - "description": "Mechanisms exist to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed.", - "scf_question": "Does the organization create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed?", + "description": "Mechanisms exist to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive and/or regulated data is stored, transmitted or processed.", + "scf_question": "Does the organization create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive and/or regulated data is stored, transmitted or processed?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -20047,7 +21091,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT and/or cybersecurity personnel work with process owners to generate and maintain Data Flow Diagrams (DFDs) and network diagrams to document the flow of data to create and maintain a map of systems where sensitive/regulated data is stored, transmitted or processed.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -20109,7 +21153,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -20130,7 +21175,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and manage a Configuration Management Database (CMDB), or similar technology, to monitor and govern technology asset-specific information.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -20198,7 +21243,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -20219,11 +21265,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to track the geographic location of system components.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -20252,7 +21298,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -20307,7 +21354,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -20331,11 +21379,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure asset ownership responsibilities are assigned, tracked and managed at a team, individual, or responsible organization level to establish a common understanding of requirements for asset protection.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -20407,7 +21455,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -20430,7 +21479,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to include capturing the name, position and/or role of individuals responsible/accountable for administering assets as part of the technology asset inventory process.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -20498,7 +21547,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -20598,15 +21648,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "AST-04", "title": "Network Diagrams & Data Flow Diagrams (DFDs)", "family": "AST", - "description": "Mechanisms exist to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive/regulated data flows.", - "scf_question": "Does the organization maintain network architecture diagrams that: \n (1) Contain sufficient detail to assess the security of the network's architecture;\n (2) Reflect the current architecture of the network environment; and\n (3) Document all sensitive/regulated data flows?", + "description": "Mechanisms exist to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive and/or regulated data flows.", + "scf_question": "Does the organization maintain network architecture diagrams that: \n (1) Contain sufficient detail to assess the security of the network's architecture;\n (2) Reflect the current architecture of the network environment; and\n (3) Document all sensitive and/or regulated data flows?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -20623,7 +21674,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT and/or cybersecurity personnel work with process owners to generate and maintain Data Flow Diagrams (DFDs) and network diagrams to document the flow of data to create and maintain a map of systems where sensitive/regulated data is stored, transmitted or processed.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive/regulated data flows.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -20696,7 +21747,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -20722,7 +21774,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to determine security, compliance and resilience control applicability by identifying, assigning and documenting the appropriate asset scope categorization for all Technology Assets, Applications and/or Services (TAAS) and personnel (internal and third-parties).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20781,9 +21833,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "AST-04.2", @@ -20806,7 +21858,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure control applicability is appropriately-determined for Technology Assets, Applications and/or Services (TAAS) and third parties by graphically representing applicable boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20840,7 +21892,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -20897,15 +21950,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "AST-05", "title": "Security of Assets & Media", "family": "AST", - "description": "Mechanisms exist to maintain strict control over the internal or external distribution of any kind of sensitive/regulated media.", - "scf_question": "Does the organization maintain strict control over the internal or external distribution of any kind of sensitive/regulated media?", + "description": "Mechanisms exist to maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity.", + "scf_question": "Does the organization maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -20918,9 +21972,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT personnel collect technology assets and media for destruction when it is no longer needed for business or legal reasons.", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain strict control over the internal or external distribution of any kind of sensitive/regulated media.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -21006,15 +22060,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed" }, { "control_id": "AST-05.1", "title": "Management Approval For External Media Transfer", "family": "AST", - "description": "Mechanisms exist to obtain management approval for any sensitive/regulated media that is transferred outside of the organization's facilities.", - "scf_question": "Does the organization obtain management approval for any sensitive/regulated media that is transferred outside of its facilities?", + "description": "Mechanisms exist to obtain management approval for any sensitive and/or regulated media that is transferred outside of the organization's facilities.", + "scf_question": "Does the organization obtain management approval for any sensitive and/or regulated media that is transferred outside of its facilities?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -21102,16 +22158,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "AST-06", - "title": "Unattended End-User Equipment", + "control_id": "AST-05.2", + "title": "Technology Assets, Applications, Services and/or Data (TAASD) Storage", "family": "AST", - "description": "Mechanisms exist to implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access.", - "scf_question": "Does the organization implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access?", - "relative_weight": 9, + "description": "Mechanisms exist to ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "scf_question": "Does the organization ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections?", + "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", @@ -21119,25 +22176,23 @@ "scrm_focus": { "strategic": false, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", - "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access.", + "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE)", - "small": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE)", - "medium": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)", - "large": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)", - "enterprise": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)" + "micro_small": "∙ Locked cabinet or secure room for equipment\n∙ Basic physical access controls (key or PIN)", + "small": "∙ Locked server room with physical access controls\n∙ Physical access log\n∙ Environmental controls (temperature, humidity)", + "medium": "∙ Dedicated server room with physical access controls and monitoring\n∙ Physical access logging\n∙ Co-location or private cage in certified data center", + "large": "∙ Secure data center facilities (access control, CCTV, environmental monitoring)\n∙ Co-location or private cage in certified data center\n∙ Physical security assessments", + "enterprise": "∙ Co-location or private cage in certified data center\n∙ Multi-layer physical access controls (mantraps, biometrics)\n∙ 24/7 physical security monitoring\n∙ Redundant physical infrastructure" }, "risks": [ "R-AC-1", @@ -21151,6 +22206,7 @@ "R-BC-2", "R-BC-3", "R-BC-4", + "R-BC-5", "R-EX-1", "R-EX-2", "R-EX-3", @@ -21208,16 +22264,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - AU ISM ISM-1975" }, { - "control_id": "AST-06.1", - "title": "Asset Storage In Automobiles", + "control_id": "AST-06", + "title": "Unattended End-User Equipment", "family": "AST", - "description": "Mechanisms exist to educate users on the need to physically secure laptops and other mobile devices out of sight when traveling, preferably in the trunk of a vehicle.", - "scf_question": "Does the organization educate users on the need to physically secure laptops and other mobile devices out of sight when traveling, preferably in the trunk of a vehicle?", - "relative_weight": 7, + "description": "Mechanisms exist to implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access.", + "scf_question": "Does the organization implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access?", + "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", @@ -21229,39 +22287,59 @@ }, "maturity": { "0": "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.", - "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Generic guidelines are published for users to secure laptops and other mobile devices while traveling.", + "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to educate users on the need to physically secure laptops and other mobile devices out of sight when traveling, preferably in the trunk of a vehicle.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [], + "profiles": [ + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], "possible_solutions": { - "micro_small": "∙ Physical security awareness training", - "small": "∙ Physical security awareness training", - "medium": "∙ Physical security awareness training", - "large": "∙ Physical security awareness training", - "enterprise": "∙ Physical security awareness training" + "micro_small": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE)", + "small": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE)", + "medium": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)", + "large": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)", + "enterprise": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)" }, "risks": [ "R-AC-1", "R-AC-2", + "R-AC-3", "R-AC-4", "R-AM-1", + "R-AM-2", "R-AM-3", "R-BC-1", "R-BC-2", "R-BC-3", - "R-BC-5", + "R-BC-4", "R-EX-1", "R-EX-2", + "R-EX-3", "R-EX-4", + "R-EX-5", + "R-EX-6", "R-EX-7", "R-GV-1", "R-GV-2", + "R-GV-3", "R-GV-4", "R-GV-5", - "R-IR-4" + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" ], "threats": [ "NT-2", @@ -21294,15 +22372,103 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "AST-06.1", + "title": "Asset Storage In Automobiles", + "family": "AST", + "description": "Mechanisms exist to educate users on the need to physically secure laptops and other mobile devices out of sight when traveling, preferably in the trunk of a vehicle.", + "scf_question": "Does the organization educate users on the need to physically secure laptops and other mobile devices out of sight when traveling, preferably in the trunk of a vehicle?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Generic guidelines are published for users to secure laptops and other mobile devices while traveling.", + "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to educate users on the need to physically secure laptops and other mobile devices out of sight when traveling, preferably in the trunk of a vehicle.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Physical security awareness training", + "small": "∙ Physical security awareness training", + "medium": "∙ Physical security awareness training", + "large": "∙ Physical security awareness training", + "enterprise": "∙ Physical security awareness training" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-4", + "R-AM-1", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-4", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-IR-4" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { "control_id": "AST-07", "title": "Kiosks & Point of Interaction (PoI) Devices", "family": "AST", - "description": "Mechanisms exist to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution.", - "scf_question": "Does the organization appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution?", + "description": "Mechanisms exist to appropriately protect devices that capture sensitive and/or regulated data via direct physical interaction from tampering and substitution.", + "scf_question": "Does the organization appropriately protect devices that capture sensitive and/or regulated data via direct physical interaction from tampering and substitution?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -21317,7 +22483,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -21398,7 +22564,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -21502,7 +22669,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -21607,7 +22775,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -21698,7 +22867,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -21721,7 +22891,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to authorize, control and track technology assets entering and exiting organizational facilities.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to authorize, control and track technology assets entering and exiting organizational facilities. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -21789,7 +22959,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -21901,7 +23072,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -21922,7 +23094,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to reduce the risk associated with third-party assets that are attached to the network from harming organizational assets or exfiltrating organizational data.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -21995,7 +23167,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22016,11 +23189,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to monitor and enforce usage parameters that limit the potential damage caused from the unauthorized or unintentional alteration of system parameters.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to monitor and enforce usage parameters that limit the potential damage caused from the unauthorized or unintentional alteration of system parameters. \n", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -22077,7 +23250,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22098,7 +23272,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to prevent the usage of Bluetooth and wireless devices (e.g., Near Field Communications (NFC)) in sensitive areas or unless used in a Radio Frequency (RF)-screened building.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22169,7 +23343,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22261,7 +23436,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22288,7 +23464,7 @@ "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Periodic physical inspections are performed to validate the integrity of unattended technology assets (e.g., kiosks, ATMs, point of sale devices, etc.).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to assess the integrity of critical Technology Assets, Applications and/or Services (TAAS) to detect evidence of tampering, where:\n(1)\tLogical assessments evaluate the integrity of critical components (e.g., configuration settings); and\n(2)\tPhysical assessments evaluate assets for evidence of unauthorized access and/or modifications.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -22343,7 +23519,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22366,9 +23543,9 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Periodic physical inspections are performed to validate the integrity of unattended technology assets (e.g., kiosks, ATMs, point of sale devices, etc.).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to physically and logically inspect critical technology assets to detect evidence of tampering.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to physically and logically inspect critical technology assets to detect evidence of tampering. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -22439,7 +23616,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22460,7 +23638,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ The use of personal devices (e.g., Bring Your Own Device (BYOD), as part of acceptable and unacceptable behaviors are primarily administrative and preventative in nature.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and govern a Bring Your Own Device (BYOD) program to reduce risk associated with personally-owned devices in the workplace.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -22532,7 +23710,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22555,7 +23734,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to govern Supply Chain Risk Management (SCRM) sanctions that require the removal and prohibition of certain Technology Assets, Applications and/or Services (TAAS) that are designated as supply chain threats by a statutory or regulatory body.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22629,7 +23808,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22652,7 +23832,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to provision and protect the confidentiality, integrity and authenticity of product supplier keys and data that can be used as a “roots of trust” basis for integrity verification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22717,7 +23897,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22738,7 +23919,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for telecommunication equipment to prevent potential damage or unauthorized modification and to prevent potential eavesdropping.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22802,7 +23983,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22823,7 +24005,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement secure Video Teleconference (VTC) capabilities on endpoint devices and in designated conference rooms, to prevent potential eavesdropping.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22887,7 +24069,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -22908,7 +24091,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement secure Internet Protocol Telephony (IPT) that logically or physically separates Voice Over Internet Protocol (VoIP) traffic from data networks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22972,15 +24155,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "AST-22", "title": "Microphones & Web Cameras", "family": "AST", - "description": "Mechanisms exist to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed.", - "scf_question": "Does the organization configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed?", + "description": "Mechanisms exist to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive and/or regulated information is discussed.", + "scf_question": "Does the organization configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive and/or regulated information is discussed?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -22993,7 +24177,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23057,7 +24241,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23080,7 +24265,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely configure Multi-Function Devices (MFD) according to industry-recognized secure practices for the type of device.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23144,7 +24329,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23165,7 +24351,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to issue personnel travelling overseas with temporary, loaner or \"travel-only\" end user technology (e.g., laptops and mobile devices) when travelling to authoritarian countries with a higher-than average risk for Intellectual Property (IP) theft or espionage against individuals and private companies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23239,7 +24425,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23260,7 +24447,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to re-image end user technology (e.g., laptops and mobile devices) when returning from overseas travel to an authoritarian country with a higher-than average risk for Intellectual Property (IP) theft or espionage against individuals and private companies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23338,7 +24525,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23359,7 +24547,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to develop, implement and govern system administration processes, with corresponding Standardized Operating Procedures (SOP), for operating and maintaining Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23435,7 +24623,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23456,7 +24645,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to conduct remote system administrative functions via a \"jump box\" or \"jump server\" that is located in a separate network zone to user workstations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23546,7 +24735,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23567,7 +24757,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to develop, implement and govern database management processes, with corresponding Standardized Operating Procedures (SOP), for operating and maintaining databases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23643,7 +24833,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23664,7 +24855,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Database administrators implement and maintain Database Management Systems (DBMSs), where applicable.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and maintain Database Management Systems (DBMSs), where applicable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23738,7 +24929,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23759,7 +24951,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Enhanced security requirements for Bluetooth and wireless devices in sensitive/regulated areas are primarily administrative and preventative in nature.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely govern Radio Frequency Identification (RFID) deployments to ensure RFID is used safely and securely to protect the confidentiality and integrity of data and prevent the compromise of secure spaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23823,7 +25015,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23844,7 +25037,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely configure contactless access control systems incorporating contactless RFID or smart cards to protect the confidentiality and integrity of data and prevent the compromise of secure spaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23908,7 +25101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -23929,7 +25123,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT personnel collect technology assets and media for destruction when it is no longer needed for business or legal reasons.\n▪ Asset decommissioning consists of mainly wiping hard drives.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications and/or Services (TAAS) are properly decommissioned so that data is properly transitioned to new systems or archived in accordance with applicable organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24015,7 +25209,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24038,7 +25233,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24128,7 +25323,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24151,7 +25347,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize Artificial Intelligence (AI) and Autonomous Technologies (AAT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24229,7 +25425,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24250,7 +25447,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize a system and/or service as \"High Risk\" if it poses a significant risk of harm to an individual's:\n(1) Health;\n(2) Safety; and/or \n(3) Fundamental human rights.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24299,7 +25496,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24320,7 +25518,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to dynamically associate asset-specific attributes to enable Attribute-Based Access Control (ABAC).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24375,7 +25573,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24461,7 +25660,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24569,7 +25769,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24594,7 +25795,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan development with internal and external elements responsible for related plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan development with internal and external elements responsible for related plans. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -24650,7 +25851,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24673,7 +25875,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate internal contingency plans with the contingency plans of external service providers to ensure that contingency requirements can be satisfied.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -24748,7 +25950,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24771,7 +25974,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to redeploy personnel to other roles during a disruptive event or in the execution of a continuity plan.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24841,7 +26044,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -24865,7 +26069,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to facilitate recovery operations in accordance with Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -24942,7 +26146,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25020,7 +26225,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25103,7 +26309,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25111,7 +26318,7 @@ "title": "Business Continuity & Disaster Recovery (BC/DR) Plans", "family": "BCD", "description": "Mechanisms exist for process owners to establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions.", - "scf_question": "Does the organization process owners to establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions?", + "scf_question": "Does the organization ensure process owners establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -25181,9 +26388,9 @@ "MT-10", "MT-11", "MT-24", - "MT-27" - ], - "errata": "- new control (C2M2)" + "MT-27", + "MT-28" + ] }, { "control_id": "BCD-02", @@ -25264,7 +26471,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25362,7 +26570,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25456,7 +26665,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25477,9 +26687,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.\n▪ Business stakeholders and process owners define Recovery Time Objectives (RTOs) for business-critical TAASD.\n▪ Business stakeholders and process owners define Recovery Point Objectives (RPOs) for business-critical TAASD.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to resume essential missions and business functions within an organization-defined time period of contingency plan activation.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to resume essential missions and business functions within an organization-defined time period of contingency plan activation. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -25550,15 +26760,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "BCD-02.4", "title": "Data Storage Location Reviews", "family": "BCD", - "description": "Mechanisms exist to perform periodic security reviews of storage locations that contain sensitive/regulated data.", - "scf_question": "Does the organization perform periodic security reviews of storage locations that contain sensitive/regulated data?", + "description": "Mechanisms exist to perform periodic security reviews of storage locations that contain sensitive and/or regulated data.", + "scf_question": "Does the organization perform periodic security reviews of storage locations that contain sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -25573,7 +26784,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to perform periodic security reviews of storage locations that contain sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25648,7 +26859,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25671,9 +26883,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to adequately train contingency personnel and applicable stakeholders in their contingency roles and responsibilities.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to adequately train contingency personnel and applicable stakeholders in their contingency roles and responsibilities. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -25743,7 +26955,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25766,7 +26979,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to incorporate simulated events into contingency training to facilitate effective response by personnel in crisis situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25816,7 +27029,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25884,7 +27098,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -25910,7 +27125,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to conduct tests and/or exercises to evaluate the contingency plan's effectiveness and the organization's readiness to execute the plan.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to conduct tests and/or exercises to evaluate the contingency plan's effectiveness and the organization's readiness to execute the plan. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -25980,7 +27195,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26001,9 +27217,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan testing with internal and external elements responsible for related plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan testing with internal and external elements responsible for related plans. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -26055,7 +27271,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26078,7 +27295,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A dedicated alternate site(s) is/are equipped to be compatible with the production network's processing, storage, connectivity and other infrastructure needs.\n▪ Alternate sites are given priority of service to meet applicable RTOs and/or RPOs.\n▪ RTOs are used to identify business-critical TAASD, which are given priority of service in alternate processing and storage sites.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to test contingency plans at alternate storage & processing sites to both familiarize contingency personnel with the facility and evaluate the capabilities of the alternate processing site to support contingency operations.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to test contingency plans at alternate storage & processing sites to both familiarize contingency personnel with the facility and evaluate the capabilities of the alternate processing site to support contingency operations. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -26149,7 +27366,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26244,7 +27462,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26267,7 +27486,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Production TAASD support business-critical application and services failover.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to develop BC/DR plans to recover business-critical TAASD.\n▪ Data/process owners conduct a Business Impact Analysis (BIA) at least annually, or after any major technology or process change, to identify TAASD that are critical to the business, as well as single points of failure.\n▪ Business stakeholders and process owners designate alternative decision-makers if primary decision-makers are unavailable.\n▪ Within the BC/DR plans, alternate communications channels are defined if primary means of communication are unavailable.\n▪ RTOs are used to identify business-critical TAASD, which are given priority of service in alternate processing and storage sites.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to update contingency plans due to changes affecting:\n(1) People (e.g., personnel changes);\n(2) Processes (e.g., new, altered or decommissioned business practices, including third-party services)\n(3) Technologies (e.g., new, altered or decommissioned technologies);\n(4) Data (e.g., changes to data flows and/or data repositories);\n(5) Facilities (e.g., new, altered or decommissioned physical infrastructure); and/or\n(6) Feedback from contingency plan testing activities.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -26322,7 +27541,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26330,7 +27550,7 @@ "title": "Contingency Planning Components", "family": "BCD", "description": "Mechanisms exist to identify components that potentially impact the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure.", - "scf_question": "Does the organization identify components that potentially impacts the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure?", + "scf_question": "Does the organization identify components that potentially impact its ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -26345,7 +27565,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify components that potentially impacts the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26397,7 +27617,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26420,7 +27641,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to keep stakeholders informed of changes to contingency plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to keep stakeholders informed of changes to contingency plans.\n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -26468,7 +27689,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26489,9 +27711,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -26547,7 +27769,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26568,9 +27791,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate storage site that includes both the assets and necessary agreements to permit the storage and recovery of system backup information.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate storage site that includes both the assets and necessary agreements to permit the storage and recovery of system backup information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -26632,7 +27855,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26653,7 +27877,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to separate the alternate storage site from the primary storage site to reduce susceptibility to similar threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26695,16 +27919,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed" + "MT-27", + "MT-28" + ] }, { "control_id": "BCD-08.2", "title": "Primary Storage Site Accessibility", "family": "BCD", "description": "Mechanisms exist to identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster.", - "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster?", + "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -26717,7 +27941,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26779,9 +28003,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "BCD-09", @@ -26801,7 +28025,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate processing site that provides security measures equivalent to that of the primary site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26865,7 +28089,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -26886,7 +28111,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to separate the alternate processing site from the primary processing site to reduce susceptibility to similar threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26928,16 +28153,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed" + "MT-27", + "MT-28" + ] }, { "control_id": "BCD-09.2", "title": "Alternate Processing Site Accessibility", "family": "BCD", "description": "Mechanisms exist to identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster.", - "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate processing site and possible mitigation actions, in the event of an area-wide disruption or disaster?", + "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -26950,7 +28175,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -27010,9 +28235,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "BCD-09.3", @@ -27034,9 +28259,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to address priority-of-service provisions in alternate processing and storage sites that support availability requirements, including Recovery Time Objectives (RTOs).", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to address priority-of-service provisions in alternate processing and storage sites that support availability requirements, including Recovery Time Objectives (RTOs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -27090,7 +28315,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27167,7 +28393,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27175,7 +28402,7 @@ "title": "Inability to Return to Primary Site", "family": "BCD", "description": "Mechanisms exist to plan and prepare for both natural and manmade circumstances that preclude returning to the primary site.", - "scf_question": "Does the organization plan and prepare for both natural and manmade circumstances that preclude returning to the primary processing site?", + "scf_question": "Does the organization plan and prepare for both natural and manmade circumstances that preclude returning to the primary site?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -27188,7 +28415,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to plan and prepare for both natural and manmade circumstances that preclude returning to the primary site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -27246,9 +28473,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "BCD-10", @@ -27268,7 +28495,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to reduce the likelihood of a single point of failure with primary telecommunications services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -27324,7 +28551,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27347,9 +28575,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to formalize primary and alternate telecommunications service agreements contain priority-of-service provisions that support availability requirements, including Recovery Time Objectives (RTOs).", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to formalize primary and alternate telecommunications service agreements contain priority-of-service provisions that support availability requirements, including Recovery Time Objectives (RTOs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -27386,7 +28614,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27407,9 +28636,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -27463,7 +28692,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27484,7 +28714,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to contractually-require external service providers to have contingency plans that meet organizational contingency requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -27542,7 +28772,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27615,7 +28846,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27706,7 +28938,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27731,7 +28964,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ A random sampling of backups is tested at least annually to verify integrity and recoverability of backed up data.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel perform a random sampling of backups is tested at least semi-annually to verify integrity and recoverability of backed up data.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to routinely test backups that verify the reliability of the backup process, as well as the integrity and availability of the data.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to routinely test backups that verify the reliability of the backup process, as well as the integrity and availability of the data. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -27776,7 +29009,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27862,7 +29096,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -27929,7 +29164,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28004,7 +29240,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28027,9 +29264,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel perform a random sampling of backups is tested at least semi-annually to verify integrity and recoverability of backed up data.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize sampling of available backups to test recovery capabilities as part of business continuity plan testing.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize sampling of available backups to test recovery capabilities as part of business continuity plan testing. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -28080,7 +29317,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28103,7 +29341,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to transfer backup data to the alternate storage site at a rate that is capable of meeting both Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -28165,7 +29403,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28186,7 +29425,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to maintain a failover capability, which is not collocated with the primary Technology Asset, Application and/or Service (TAAS), which can be activated with little-to-no loss of information or disruption to operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -28246,7 +29485,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28267,7 +29507,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to enforce dual authorization for the deletion or destruction of sensitive backup media and data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -28322,7 +29562,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28343,7 +29584,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restrict access to backups to privileged users with assigned roles for data backup and recovery operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -28395,7 +29636,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28468,7 +29710,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28491,7 +29734,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to ensure the secure recovery and reconstitution of Technology Assets, Applications and/or Services (TAAS) to a known state after a disruption, compromise or failure.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -28567,7 +29810,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28660,7 +29904,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28753,7 +29998,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28774,7 +30020,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize electronic discovery (eDiscovery) that covers current and archived communication transactions.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -28820,7 +30066,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -28843,7 +30090,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ Backups are performed ad-hoc and focus on business-critical Technology Assets, Applications, Services and/or Data (TAASD).\n▪ IT and/or cybersecurity personnel use a backup methodology (e.g., grandfather, father & son rotation) to create backups to support business needs (e.g., Recovery Time Objectives).", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restore TAASD within organization-defined restoration time-periods from configuration-controlled and integrity-protected information; representing a known, operational state for the asset.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restore TAASD within organization-defined restoration time-periods from configuration-controlled and integrity-protected information; representing a known, operational state for the asset. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -28903,7 +30150,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29002,7 +30250,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29026,7 +30275,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to verify the integrity of backups and other restoration assets prior to using them for restoration.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -29078,7 +30327,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29099,7 +30349,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize an isolated, non-production environment to perform data backup and recovery operations through offline, cloud or off-site capabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -29151,7 +30401,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29172,7 +30423,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to purchase and maintain a sufficient reserve of spare hardware to ensure essential missions and business functions can be maintained in the event of a supply chain disruption.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -29254,7 +30505,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29363,7 +30615,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29390,7 +30643,7 @@ "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to facilitate the implementation of capacity management controls to ensure optimal system performance to meet expected and anticipated future capacity requirements.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -29446,7 +30699,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29473,7 +30727,7 @@ "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to control resource utilization of Technology Assets, Applications and/or Services (TAAS) that are susceptible to Denial of Service (DoS) attacks to limit and prioritize the use of resources.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -29519,7 +30773,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29542,11 +30797,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", - "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support will exist during contingency operations.", + "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support will exist during contingency operations. ", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -29594,7 +30849,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29617,11 +30873,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to automatically centrally-monitor and alert on the operating state and health status of critical Technology Assets, Applications and/or Services (TAAS).", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -29683,7 +30939,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29706,11 +30963,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to automatically scale the resources available for Technology Assets, Applications and/or Services (TAAS), as demand conditions change.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -29767,7 +31024,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29792,7 +31050,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to support operations that are geographically dispersed via regional delivery of technological Technology Assets, Applications and/or Services (TAAS).", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -29847,7 +31105,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -29965,7 +31224,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30064,7 +31324,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30161,7 +31422,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30258,7 +31520,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30281,7 +31544,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to include a cybersecurity and/or data protection representative in the configuration change control review process.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -30353,9 +31616,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed" + "MT-27", + "MT-28" + ] }, { "control_id": "CHG-02.4", @@ -30375,7 +31638,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions upon the detection of unauthorized baseline configurations change(s).", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -30430,7 +31693,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30453,7 +31717,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern assets involved in providing cryptographic protections according to the organization's configuration management processes.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern assets involved in providing cryptographic protections according to the organization's configuration management processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -30485,7 +31749,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30571,7 +31836,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30595,7 +31861,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -30636,7 +31902,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30657,7 +31924,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to perform after-the-fact reviews of configuration change logs to discover any unauthorized changes.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -30715,7 +31982,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30736,7 +32004,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to prevent the installation of software and firmware components without verification that the component has been digitally signed using an organization-approved certificate authority.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -30772,7 +32040,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30793,7 +32062,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to enforce a two-person rule for implementing changes to critical Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -30848,7 +32117,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30927,7 +32197,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -30950,7 +32221,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to restrict software library privileges to those individuals with a pertinent business need for access.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to restrict software library privileges to those individuals with a pertinent business need for access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -31005,7 +32276,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31030,7 +32302,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited information is provided to stakeholders about proposed changes.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to ensure stakeholders are made aware of and understand the impact of proposed changes.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to ensure stakeholders are made aware of and understand the impact of proposed changes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -31087,7 +32359,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31095,7 +32368,7 @@ "title": "Control Functionality Verification", "family": "CHG", "description": "Mechanisms exist to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed.", - "scf_question": "Does the organization verify the functionality of cybersecurity and/or data protection controls following implemented changes to ensure applicable controls operate as designed?", + "scf_question": "Does the organization verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -31108,9 +32381,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -31175,16 +32448,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CHG-06.1", "title": "Report Verification Results", "family": "CHG", "description": "Mechanisms exist to report the results of security, compliance and resilience capability verification to appropriate organizational management.", - "scf_question": "Does the organization report the results of cybersecurity and data protection function verification to appropriate organizational management?", + "scf_question": "Does the organization report the results of security, compliance and resilience capability verification to appropriate organizational management?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -31197,7 +32470,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to report the results of security, compliance and resilience capability verification to appropriate organizational management.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -31241,9 +32514,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CHG-07", @@ -31263,7 +32536,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern change management procedures for \"emergency\" changes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -31272,7 +32545,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Documented emergency change procedure\n∙ Post-implementation documentation requirement", + "small": "∙ Emergency change request process\n∙ Designated emergency change approver\n∙ Post-implementation review", + "medium": "∙ Formal emergency change management process\n∙ ITSM tool emergency change workflow (e.g., ServiceNow, Jira)\n∙ Emergency Change Advisory Board (CAB) approval", + "large": "∙ Enterprise emergency change management process in ITSM platform\n∙ Emergency CAB with on-call members\n∙ Integration with incident response", + "enterprise": "∙ Enterprise ITSM emergency change workflow\n∙ 24/7 emergency CAB availability\n∙ Automated emergency change tracking and audit trail\n∙ Integration with incident response processes" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -31324,7 +32603,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31354,7 +32634,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Emergency change log (spreadsheet)\n∙ Post-hoc documentation template for emergency changes", + "small": "∙ Emergency change documentation register\n∙ Mandatory post-implementation review requirement", + "medium": "∙ ITSM-based post-implementation emergency change documentation\n∙ Mandatory post-implementation review within defined timeframe", + "large": "∙ ITSM platform mandatory documentation workflow\n∙ Post-implementation review with management sign-off\n∙ Integration with audit trail", + "enterprise": "∙ Automated ITSM documentation requirements for emergency changes\n∙ Mandatory post-implementation review with sign-off\n∙ Integration with GRC and audit reporting" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -31406,7 +32692,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31414,7 +32701,7 @@ "title": "Dual Approval For High-Impact Environments", "family": "CHG", "description": "Mechanisms exist to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization require dual approval for any changes that might result in a serious, but adverse impact to:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -31427,7 +32714,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -31459,9 +32746,9 @@ "MT-8", "MT-9", "MT-10", - "MT-11" - ], - "errata": "- new control (IEC 62443-4-2)" + "MT-11", + "MT-28" + ] }, { "control_id": "CLD-01", @@ -31483,9 +32770,9 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify cybersecurity and data protection requirements for CSP environments, including dedicated and multi-client environments.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -31582,7 +32869,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31603,7 +32891,7 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud services are designed and configured so Technology Assets, Applications and/or Services (TAAS) are secured in accordance with applicable organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -31677,7 +32965,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31767,7 +33056,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31790,9 +33080,9 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -31863,7 +33153,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31884,7 +33175,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ The cloud infrastructure incorporates a managed security zone to house cybersecurity and data protection tools.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to host security-specific technologies in a dedicated subnet.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -31924,7 +33215,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -31945,7 +33237,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure support for secure interoperability between components with Application Programming Interfaces (APIs).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -31993,7 +33285,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32079,7 +33372,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32102,7 +33396,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the integrity of virtual machine images at all times.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the integrity of virtual machine images at all times. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -32144,7 +33438,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32165,7 +33460,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure multi-tenant owned or managed assets (physical and virtual) are designed and governed such that provider and customer (tenant) user access is appropriately segmented from other tenant users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -32253,7 +33548,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32324,9 +33620,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CLD-06.2", @@ -32346,7 +33642,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure Multi-Tenant Service Providers (MTSP) facilitate security event logging capabilities for its customers that are consistent with applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -32391,7 +33687,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32412,7 +33709,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure Multi-Tenant Service Providers (MTSP) facilitate prompt forensic investigations in the event of a suspected or confirmed security incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -32457,7 +33754,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32523,7 +33821,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32546,7 +33845,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud providers use secure protocols for the import, export and management of data in cloud-based Technology Assets, Applications and/or Services (TAAS).", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud providers use secure protocols for the import, export and management of data in cloud-based Technology Assets, Applications and/or Services (TAAS). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -32579,7 +33878,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32640,7 +33940,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32667,9 +33968,9 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Geolocation requirements for sensitive/regulated data types identify restrictions on transfer of data to third-countries or international organizations.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to govern geolocation requirements for sensitive/regulated data types, including the transfer of data to third-countries or international organizations.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to control the location of cloud processing/storage based on business requirements that includes statutory, regulatory and contractual obligations.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to control the location of cloud processing/storage based on business requirements that includes statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cloud Security (CLD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cloud Security (CLD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -32717,15 +34018,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "CLD-10", "title": "Sensitive Data In Public Cloud Providers", "family": "CLD", - "description": "Mechanisms exist to limit and manage the storage of sensitive/regulated data in public cloud providers.", - "scf_question": "Does the organization limit and manage the storage of sensitive/regulated data in public cloud providers?", + "description": "Mechanisms exist to limit and manage the storage of sensitive and/or regulated data in public cloud providers.", + "scf_question": "Does the organization limit and manage the storage of sensitive and/or regulated data in public cloud providers?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -32742,7 +34044,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to limit and manage the storage of sensitive/regulated data in public cloud providers.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to limit and manage the storage of sensitive/regulated data in public cloud providers. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -32788,7 +34090,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32809,7 +34112,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to utilize a Cloud Access Security Broker (CASB), or similar technology, to provide boundary protection and monitoring functions that both provide access to the cloud and protect the organization from misuse of cloud resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -32845,7 +34148,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32866,7 +34170,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to prevent \"side channel attacks\" when using a Content Delivery Network (CDN) by restricting access to the origin server's IP address to the CDN and an authorized management network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -32906,7 +34210,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -32927,7 +34232,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to specify applicable security, compliance and resilience that must be implemented on external Technology Assets, Applications and/or Services (TAAS), consistent with the contractual obligations established with the External Service Providers (ESP) owning, operating and/or maintaining external TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -32997,9 +34302,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CLD-13.1", @@ -33019,7 +34324,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to authorize specified individuals to access External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -33089,15 +34394,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "CLD-13.2", "title": "Sensitive / Regulated Data On Hosted Assets, Applications & Services", "family": "CLD", - "description": "Mechanisms exist to define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", - "scf_question": "Does the organization define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations?", + "description": "Mechanisms exist to define formal processes to store, process and/or transmit sensitive and/or regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", + "scf_question": "Does the organization define formal processes to store, process and/or transmit sensitive and/or regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -33110,7 +34416,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -33180,7 +34486,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -33201,7 +34508,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to prohibit access to, or usage of, hosted Technology Assets, Applications and/or Services (TAAS) until applicable security, compliance and/or resilience control implementation is verified.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -33271,16 +34578,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CLD-15", "title": "Software Defined Storage (SDS)", "family": "CLD", "description": "Automated mechanisms exist to utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization use automated mechanisms to utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 3, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -33361,7 +34668,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -33385,7 +34693,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -33488,7 +34796,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -33511,7 +34820,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to document and review instances of non-compliance with statutory, regulatory and/or contractual obligations to develop appropriate risk mitigation actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -33604,7 +34913,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -33629,7 +34939,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to perform compliance scoping of control applicability for statutory, regulatory and/or contractual compliance obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to document and validate the scope of security, compliance and resilience controls that are determined to meet statutory, regulatory and/or contractual compliance obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -33680,9 +34990,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CPL-01.3", @@ -33702,7 +35012,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -33776,9 +35086,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CPL-01.4", @@ -33798,7 +35108,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -33897,9 +35207,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CPL-01.5", @@ -33919,7 +35229,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ A formal report is generated for each security assessment/audit with sufficient details to understand the organization's ability to demonstrate conformity with its requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to generate a declaration of conformity for each conformity assessment, where the document:\n(1) Is concise;\n(2) Unambiguously reflects the current status;\n(3) Is physically or electronically signed; and\n(4) Where possible, is machine readable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -33991,7 +35301,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -34012,7 +35323,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure individuals performing audits and/or assessments have reasonable:\n(1) Professional qualifications to perform the audit and/or assessment; and\n(2) Subject matter expertise to perform review, interview and test activities for in-scope People, Processes, Technologies, Data and/or Facilities (PPTDF).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -34072,7 +35383,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ] }, { @@ -34093,10 +35405,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to designate an individual the authority to make statements of conformity on behalf of the organization.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define." + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to designate an individual the authority to make statements of conformity on behalf of the organization. ", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { @@ -34117,16 +35430,16 @@ "MT-8", "MT-9", "MT-11", - "MT-14" - ], - "errata": "- new control (SOX)" + "MT-14", + "MT-28" + ] }, { "control_id": "CPL-01.8", "title": "Conformity Attestations", "family": "CPL", "description": "Mechanisms exist for the certifying official to attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria.", - "scf_question": "Does the organization's certifying official attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria", + "scf_question": "Does the organization have a certifying official attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -34139,10 +35452,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists for the certifying official to attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define." + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { @@ -34163,16 +35477,16 @@ "MT-8", "MT-9", "MT-11", - "MT-14" - ], - "errata": "- new control (SOX)" + "MT-14", + "MT-28" + ] }, { "control_id": "CPL-02", "title": "Security, Compliance & Resilience Controls Oversight", "family": "CPL", "description": "Mechanisms exist to provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership.", - "scf_question": "Does the organization provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership?", + "scf_question": "Does the organization provide a security, compliance and resilience controls oversight function that reports to its executive leadership?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -34193,7 +35507,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.\n▪ A formal report is generated for each security assessment/audit with sufficient details to understand the organization's ability to demonstrate conformity with its requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -34285,9 +35599,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CPL-02.1", @@ -34310,7 +35624,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to implement an internal audit function that is capable of providing senior organization management with insights into the appropriateness of the organization's technology and information governance processes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -34401,7 +35715,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -34409,7 +35724,7 @@ "title": "Periodic Audits", "family": "CPL", "description": "Mechanisms exist to conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures.", - "scf_question": "Does the organization conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures?", + "scf_question": "Does the organization conduct periodic audits of security, compliance and resilience controls to evaluate conformity with its documented policies, standards and procedures?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -34422,17 +35737,23 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.\n▪ Specialized assessments are conducted for specific statutory, regulatory and/or contractual compliance obligations, as well as business-critical TAASD.\n▪ IT and/or cybersecurity use an impartial member of its team or a third-party assessor to perform an independent assessment of cybersecurity and data protection controls.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Annual self-assessment against applicable compliance requirements\n∙ External compliance review if contractually required", + "small": "∙ Annual internal review of key security controls\n∙ External audit for compliance requirements", + "medium": "∙ Internal audit program\n∙ Annual external compliance audits\n∙ GRC platform for audit tracking.", + "large": "∙ Enterprise internal audit function\n∙ Annual external audits.\n∙ GRC platform with audit management", + "enterprise": "∙ Enterprise internal audit program with dedicated resources\n∙ Multiple external compliance audits\n∙ Continuous control monitoring and automated audit reporting" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -34506,9 +35827,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CPL-02.3", @@ -34528,7 +35849,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to take corrective action to remediate instances of non-conformity with applicable statutory, regulatory, and/or contractual compliance obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -34538,7 +35859,13 @@ "CORE AI Model Deployment", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Corrective action log (spreadsheet)\n∙ Documented remediation plans for audit findings", + "small": "∙ Corrective action register with remediation tracking\n∙ Management review of open findings", + "medium": "∙ Formal corrective action plan process\n∙ GRC platform for finding tracking and remediation\n∙ Management review of open findings", + "large": "∙ Enterprise corrective action management program\n∙ GRC platform with workflow-driven remediation tracking\n∙ Executive reporting on open findings", + "enterprise": "∙ Enterprise GRC platform for corrective action management\n∙ Automated finding tracking and escalation workflows\n∙ Board-level reporting on material findings" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -34612,15 +35939,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "CPL-03", - "title": "Security, Compliance & Resilience Assessments", + "title": "Control Conformity Monitoring", "family": "CPL", - "description": "Mechanisms exist to regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", - "scf_question": "Does the organization regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements?", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "scf_question": "Does the organization validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to its security, compliance and/or resilience policies, standards and other applicable requirements?", "relative_weight": 10, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -34638,7 +35966,7 @@ "0": "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.", "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments. \n▪ For specific statutory, regulatory and/or contractual obligations, stakeholders may contract with a third-party auditor/assessor to perform an independent assessment of cybersecurity and data protection controls.", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -34649,8 +35977,8 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", - "small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", + "micro_small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, SimpleRisk, etc.)", + "small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, SimpleRisk, etc.)", "medium": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", "large": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", "enterprise": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)" @@ -34726,9 +36054,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed" + "errata": "- renamed control\n- wordsmithed control" }, { "control_id": "CPL-03.1", @@ -34836,16 +36165,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CPL-03.2", "title": "Functional Review Of Security, Compliance & Resilience Controls", "family": "CPL", "description": "Mechanisms exist to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards.", - "scf_question": "Does the organization regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards?", + "scf_question": "Does the organization regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to its security, compliance and/or resilience policies and standards?", "relative_weight": 8, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -34860,9 +36189,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -34953,9 +36282,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "CPL-03.3", @@ -34975,7 +36304,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to grant assessors minimum necessary access to conduct conformity assessments, including:\n(1) Logical access to design, development, production, inspection and testing artifacts; and \n(2) Physical access to facilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35062,7 +36391,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -35083,7 +36413,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define acceptable methods to conduct a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35172,7 +36502,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -35193,7 +36524,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define the level of assessment rigor necessary to conduct a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35282,7 +36613,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -35303,7 +36635,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define an Evidence Request List (ERL) prior to the start of a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35392,7 +36724,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -35413,7 +36746,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define evidence sampling criteria for cybersecurity and/or data protection assessments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35502,9 +36835,122 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "CPL-03.8", + "title": "Continuous Control Monitoring (CCM)", + "family": "CPL", + "description": "Automated mechanisms exist to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "scf_question": "Does the organization use automated mechanisms to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Periodic manual control reviews", + "small": "∙ GRC solution with control tracking\n∙ Regular control status reviews", + "medium": "∙ GRC platform with control monitoring\n∙ Regular automated control status reporting", + "large": "∙ GRC platform with continuous control monitoring\n∙ Integration with SIEM and vulnerability management\n∙ Automated control evidence collection", + "enterprise": "∙ Enterprise continuous control monitoring platform\n∙ Automated evidence collection and control testing\n∙ Real-time control dashboards\n∙ Integration with GRC, SIEM, and asset management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-1", + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" + }, { "control_id": "CPL-04", "title": "Audit Activities", @@ -35523,7 +36969,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to thoughtfully plan audits by including input from operational risk and compliance partners to minimize the impact of audit-related activities on business operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35588,7 +37034,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -35609,7 +37056,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with the organization's legal counsel for guidance on how to respond to legal orders (e.g., court orders, investigations, etc.).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to determine whether a government agency has an applicable and valid legal basis to request data from the organization and what further steps need to be taken, if necessary.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35696,7 +37143,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -35717,7 +37165,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to notify customers about investigation request notifications, unless the applicable legal basis for a government agency's action prohibits notification (e.g., potential criminal prosecution).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35801,7 +37249,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -35822,7 +37271,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to support official investigations by provisioning government investigators with \"least privileges\" and \"least functionality\" to ensure that government investigators only have access to the TAASD needed to perform the investigation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35908,7 +37357,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -35929,7 +37379,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to constrain the host government from having unrestricted and non-monitored access to the organization's TAASD that could potentially violate other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35995,7 +37445,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36003,7 +37454,7 @@ "title": "Grievances", "family": "CPL", "description": "Mechanisms exist to govern the intake and analysis of grievances related to the organization's cybersecurity and/or data protection practices.", - "scf_question": "Does the organization govern the intake, analysis, assignment and remediation of grievances related to its cybersecurity and/or data protection practices?", + "scf_question": "Does the organization govern the intake and analysis of grievances related to its cybersecurity and/or data protection practices?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -36016,7 +37467,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36088,7 +37539,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36109,7 +37561,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to respond to legitimate grievances related to the organization's cybersecurity and/or data protection practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36181,7 +37633,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36202,7 +37655,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to appoint localized representation with a physical presence in localities, as required by applicable laws and/or regulations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36300,7 +37753,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36321,7 +37775,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to contract localized representation to perform specified functions in regard to representing statutory and/or regulatory compliance matters.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36419,7 +37873,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36440,7 +37895,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define instances of control reciprocity within assessment boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36473,7 +37928,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36494,7 +37950,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define instances of control inheritance within assessment boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36527,7 +37983,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36548,7 +38005,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern technologies and/or data that have potential:\n(1) \"Dual-use” capabilities for civil and military;\n(2) Use by terrorists; and/or \n(3) Weapons of Mass Destruction (WMD) applications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36624,7 +38081,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36645,7 +38103,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify if the organization handles United States Munitions List (USML) or Commerce Control List (CCL):\n(1) Items;\n(2) Technical data; and/or\n(3) Provides defense services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36721,7 +38179,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36742,7 +38201,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict logical and physical access to United States (US) export-controlled data to US: \n(1) Citizens; and/or\n(2) Green Card holders.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36818,7 +38277,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36839,7 +38299,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to generate detailed logs of export-controlled data including:\n(1) Logical and physical access; and\n(2) Export activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36915,7 +38375,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -36938,7 +38399,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce a Statement of Applicability (SOA), or similar document, for compliance-related scoping activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36964,7 +38425,8 @@ "MT-8", "MT-9", "MT-14", - "MT-15" + "MT-15", + "MT-28" ] }, { @@ -36985,7 +38447,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce work products (e.g., process artifacts) that demonstrate the ability to comply with applicable requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -37010,9 +38472,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" - ], - "errata": "- new control (CERT-RMM 1.2)" + "MT-14", + "MT-28" + ] }, { "control_id": "CPL-13.1", @@ -37032,7 +38494,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce evidence of due diligence activities performed, capable of withstanding external audit or regulatory scrutiny.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -37061,9 +38523,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" - ], - "errata": "- new control" + "MT-14", + "MT-28" + ] }, { "control_id": "CPL-13.2", @@ -37083,7 +38545,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce evidence of due care activities performed, capable of withstanding external audit or regulatory scrutiny.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -37112,9 +38574,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" - ], - "errata": "- new control" + "MT-14", + "MT-28" + ] }, { "control_id": "CFG-01", @@ -37141,7 +38603,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to facilitate the implementation of configuration management controls.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -37220,7 +38682,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37309,7 +38772,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37343,9 +38807,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -37418,7 +38882,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37441,11 +38906,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to review and update baseline configurations:\n(1) At least annually;\n(2) When required due to so; or\n(3) As part of system component installations and upgrades.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -37515,7 +38980,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37540,7 +39006,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically govern and report on baseline configurations of Technology Assets, Applications and/or Services (TAAS) through Continuous Diagnostics and Mitigation (CDM), or similar technologies.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -37582,7 +39048,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37605,7 +39072,7 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Historical versions of configurations are maintained for troubleshooting and forensics purposes.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -37671,7 +39138,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37696,7 +39164,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to manage baseline configurations for development and test environments separately from operational baseline configurations to minimize the risk of unintentional changes.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -37761,7 +39229,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37794,11 +39263,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) utilized in high-risk areas with more restrictive baseline configurations.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -37869,7 +39338,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37892,7 +39362,7 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -37952,7 +39422,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -37975,11 +39446,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Any deviations from approved baseline configurations are reviewed, approved and documented on a case-by-case basis by IT and/or cybersecurity personnel.\n▪ Deviations to baseline configurations are required to have a risk assessment and the business process owner's acceptance of the risk(s) associated with the deviation.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to document, assess risk and approve or deny deviations to standardized configurations.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -38049,7 +39520,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38072,9 +39544,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to verify the functionality of security controls when anomalies or misconfigurations are discovered.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 3 Advanced Threats", @@ -38140,7 +39612,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38164,11 +39637,11 @@ }, "maturity": { "0": "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.", - "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment.\n▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices.", + "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment.\n▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.\n▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to allow baseline controls to be specialized or customized by applying a defined set of tailoring actions that are specific to:\n(1) Mission / business functions;\n(2) Operational environment;\n(3) Specific threats or vulnerabilities; or\n(4) Other conditions or situations that could affect mission / business success.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -38236,7 +39709,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38270,9 +39744,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to provide only essential capabilities by specifically prohibiting or restricting the use of ports, protocols, and/or services.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to provide only essential capabilities by specifically prohibiting or restricting the use of ports, protocols, and/or services. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -38343,7 +39817,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38368,7 +39843,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to periodically review system configurations to identify and disable unnecessary and/or non-secure functions, ports, protocols and services.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -38436,7 +39911,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38462,9 +39938,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the execution of unauthorized software programs.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the execution of unauthorized software programs. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -38533,7 +40009,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38560,7 +40037,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to explicitly allow (allowlist / whitelist) and/or block (denylist / blacklist) applications that are authorized to execute on systems.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -38630,7 +40107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38638,7 +40116,7 @@ "title": "Split Tunneling", "family": "CFG", "description": "Mechanisms exist to prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards.", - "scf_question": "Does the organization prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?\n\nPrevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?", + "scf_question": "Does the organization prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -38655,7 +40133,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -38704,7 +40182,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38729,7 +40208,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to enforce software usage restrictions to comply with applicable contract agreements and copyright laws.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -38800,7 +40279,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38823,9 +40303,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to establish parameters for the secure use of open source software.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to establish parameters for the secure use of open source software. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -38895,7 +40375,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -38920,7 +40401,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to allow only approved Internet browsers and email clients to run on systems.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -38988,7 +40469,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -39017,7 +40499,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to restrict the ability of non-privileged users to install unauthorized software.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -39088,7 +40570,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -39111,9 +40594,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Secure baseline configurations generate logs that contain sufficient information to establish necessary details of activity and allow for forensics analysis.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to generate an alert when the unauthorized installation of software is detected.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to generate an alert when the unauthorized installation of software is detected. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -39162,7 +40645,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -39183,11 +40667,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the installation of software, unless the action is performed by a privileged user or service.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -39255,7 +40739,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -39276,11 +40761,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically monitor, enforce and report on configurations for endpoint devices.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -39349,7 +40834,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -39370,7 +40856,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically identify unauthorized deviations from an approved baseline and implement automated resiliency actions to remediate the unauthorized change.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -39441,7 +40927,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -39462,7 +40949,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to implement Zero-Touch Provisioning (ZTP), or similar technology, to automatically and securely configure devices upon being added to a network.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -39510,15 +40997,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "CFG-08", "title": "Sensitive / Regulated Data Access Enforcement", "family": "CFG", - "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data.", - "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data?", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive and/or regulated data.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive and/or regulated data?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -39533,7 +41021,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -39621,15 +41109,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "CFG-08.1", "title": "Sensitive / Regulated Data Actions", "family": "CFG", - "description": "Automated mechanisms exist to generate event logs whenever sensitive/regulated data is collected, created, updated, deleted and/or archived.", - "scf_question": "Does the organization use automated mechanisms to generate event logs whenever sensitive/regulated data is collected, created, updated, deleted and/or archived?", + "description": "Automated mechanisms exist to generate event logs whenever sensitive and/or regulated data is collected, created, updated, deleted and/or archived.", + "scf_question": "Does the organization use automated mechanisms to generate event logs whenever sensitive and/or regulated data is collected, created, updated, deleted and/or archived?", "relative_weight": 7, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -39725,9 +41214,290 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "CFG-09", + "title": "Production Software Repository", + "family": "CFG", + "description": "Mechanisms exist to maintain an authoritative repository for production software.", + "scf_question": "Does the organization maintain an authoritative repository for production software?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to maintain an authoritative repository for production software.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Version control system with protected production branch (e.g., GitHub, GitLab).\n∙ Designated production branch with access controls", + "small": "∙ Version control with protected production branches.\n∙ Access restrictions on production branch", + "medium": "∙ Artifact repository manager (e.g., JFrog Artifactory, Nexus)\n∙ Version-controlled production software with access restrictions", + "large": "∙ Enterprise artifact repository (e.g., JFrog Artifactory, Nexus)\n∙ Access controls on production repository\n∙ Immutable artifact storage", + "enterprise": "∙ Enterprise artifact repository (e.g., JFrog Artifactory)\n∙ Software Bill of Materials (SBOM) generation\n∙ Immutable artifact storage with digital signing\n∙ Integration with CI/CD pipeline" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2023" + }, + { + "control_id": "CFG-09.1", + "title": "Third-Party Libraries", + "family": "CFG", + "description": "Mechanisms exist to restrict the use and import of third-party libraries and/or software components to trustworthy sources.", + "scf_question": "Does the organization restrict the use and import of third-party libraries and/or software components to trustworthy sources?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to restrict the use and import of third-party libraries and/or software components to trustworthy sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Manual review of third-party libraries before use\n∙ OWASP Dependency-Check\n∙ Approved library list", + "small": "∙ OWASP Dependency-Check for vulnerability scanning\n∙ Approved third-party library register", + "medium": "∙ Software Composition Analysis (SCA) tool\n∙ Approved vendor/library register\n∙ Dependency vulnerability scanning in CI/CD", + "large": "∙ Enterprise SCA tool (e.g., Snyk, Mend, Black Duck)\n∙ Approved library registry\n∙ Automated dependency scanning in CI/CD pipeline", + "enterprise": "∙ Enterprise SCA platform (e.g., Snyk, Black Duck\n∙ Automated library approval workflows\n∙ SBOM generation for all dependencies\n∙ Real-time vulnerability alerting for in-use libraries" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2029" + }, + { + "control_id": "CFG-09.2", + "title": "Software Repository Protections", + "family": "CFG", + "description": "Mechanisms exist to protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys.", + "scf_question": "Does the organization protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Checksum verification of downloaded packages\n∙ Use of reputable package registries only", + "small": "∙ Package signature verification\n∙ Private package mirror or proxy", + "medium": "∙ Artifact repository with malware scanning\n∙ Package signature and hash verification\n∙ Private package registry to proxy public registries", + "large": "∙ Enterprise artifact repository with integrated security scanning\n∙ Signed artifact enforcement\n∙ Private package proxy with allowlist", + "enterprise": "∙ Enterprise artifact repository with automated malware scanning and secret detection\n∙ Code signing enforcement\n∙ Supply chain security tools.\n∙ Private package proxy with security scanning" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2026 & ISM-2027" + }, + { + "control_id": "CFG-09.3", + "title": "Software Development Repository", + "family": "CFG", + "description": "Mechanisms exist to maintain an authoritative repository for software development activities that is separate from production software.", + "scf_question": "Does the organization maintain an authoritative repository for software development activities that is separate from production software?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to maintain an authoritative repository for software development activities that is separate from production software.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Separate development branch in version control\n∙ GitHub or GitLab for development repository.", + "small": "∙ Separate development environment and repository\n∙ Branch-based development workflow separate from production", + "medium": "∙ Separate development, staging and production repositories\n∙ Access controls separating development from production code", + "large": "∙ Enterprise repository management with environment separation\n∙ Strict access controls between dev and production repositories\n∙ Code review requirements before production promotion", + "enterprise": "∙ Enterprise DevSecOps platform with environment-separated repositories\n∙ Automated promotion gates between environments\n∙ Immutable production code repository\n∙ Integration with ITSM change management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2024" + }, { "control_id": "MON-01", "title": "Continuous Monitoring", @@ -39829,7 +41599,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -39854,7 +41625,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement Intrusion Detection / Prevention Systems (IDS / IPS) technologies on critical systems, key network segments and network choke points.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -39924,7 +41695,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -39948,9 +41720,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support near real-time analysis and incident escalation.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support near real-time analysis and incident escalation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -40017,7 +41789,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40112,7 +41885,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40138,9 +41912,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to generate, monitor, correlate and respond to alerts from physical, cybersecurity, data protection and supply chain activities to achieve integrated situational awareness.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to generate, monitor, correlate and respond to alerts from physical, cybersecurity, data protection and supply chain activities to achieve integrated situational awareness. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -40210,7 +41984,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40314,9 +42089,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "MON-01.6", @@ -40400,7 +42175,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40425,7 +42201,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a File Integrity Monitor (FIM), or similar change-detection technology, on critical Technology Assets, Applications and/or Services (TAAS) to generate alerts for unauthorized modifications.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a File Integrity Monitor (FIM), or similar change-detection technology, on critical Technology Assets, Applications and/or Services (TAAS) to generate alerts for unauthorized modifications. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -40493,7 +42269,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40590,7 +42367,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40613,7 +42391,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.\n▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to log all Internet-bound requests, in order to identify prohibited activities and assist incident handlers with identifying potentially compromised systems.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to log all Internet-bound requests, in order to identify prohibited activities and assist incident handlers with identifying potentially compromised systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -40679,7 +42457,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40700,7 +42479,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor deactivated accounts for attempted usage.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -40770,7 +42549,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40778,7 +42558,7 @@ "title": "Automated Response to Suspicious Events", "family": "MON", "description": "Automated mechanisms exist to implement pre-determined corrective actions in response to detected events that have security incident implications.", - "scf_question": "Does the organization automatically implement pre-determined corrective actions in response to detected events that have security incident implications?", + "scf_question": "Does the organization use automated mechanisms to implement pre-determined corrective actions in response to detected events that have security incident implications?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -40791,11 +42571,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically implement pre-determined corrective actions in response to detected events that have security incident implications.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -40855,7 +42635,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40878,7 +42659,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically alert incident response personnel to inappropriate or anomalous activities that have potential security incident implications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -40947,7 +42728,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -40968,11 +42750,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to \"tune\" event monitoring technologies through analyzing communications traffic/event patterns and developing profiles representing common traffic patterns and/or events.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -41037,7 +42819,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41060,11 +42843,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for individuals who have been identified as posing an increased level of risk.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for individuals who have been identified as posing an increased level of risk. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -41129,7 +42912,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41152,11 +42936,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for privileged users.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -41226,7 +43010,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41234,7 +43019,7 @@ "title": "Analyze and Prioritize Monitoring Requirements", "family": "MON", "description": "Mechanisms exist to assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes.", - "scf_question": "Does the organization assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes?", + "scf_question": "Does the organization assess its needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -41249,7 +43034,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -41327,9 +43112,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed\n- NIST 800-171A" + "MT-27", + "MT-28" + ] }, { "control_id": "MON-01.17", @@ -41349,7 +43134,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to enable authorized personnel the ability to remotely view and hear content related to an established user session in real time, in accordance with organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -41415,7 +43200,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41423,7 +43209,7 @@ "title": "Centralized Collection of Security Event Logs", "family": "MON", "description": "Mechanisms exist to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs.", - "scf_question": "Does the organization utilize a Security Incident Event Manager (SIEM) or similar automated tool, to support the centralized collection of security-related event logs?", + "scf_question": "Does the organization utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -41439,7 +43225,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -41524,7 +43310,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41548,7 +43335,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of vulnerability scanning activities and associated administrator accounts are reviewed to ensure that those activities are limited to the timeframes of legitimate scans.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate both technical and non-technical information from across the enterprise by a Security Incident Event Manager (SIEM) or similar automated tool, to enhance organization-wide situational awareness.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -41633,7 +43420,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41658,11 +43446,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically centrally collect, review and analyze audit records from multiple sources.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -41742,7 +43530,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41763,11 +43552,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically integrate the analysis of audit records with analysis of vulnerability scanners, network performance, system monitoring and other sources to further enhance the ability to identify inappropriate or unusual activity.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -41847,7 +43636,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41868,11 +43658,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual or malevolent activity.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual or malevolent activity. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -41950,7 +43740,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -41971,9 +43762,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to specify the permitted actions for both users and Technology Assets, Applications and/or Services (TAAS) associated with the review, analysis and reporting of audit information.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to specify the permitted actions for both users and Technology Assets, Applications and/or Services (TAAS) associated with the review, analysis and reporting of audit information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -42036,7 +43827,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42057,9 +43849,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to adjust the level of audit review, analysis and reporting based on evolving threat information from law enforcement, industry associations or other credible sources of threat intelligence.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to adjust the level of audit review, analysis and reporting based on evolving threat information from law enforcement, industry associations or other credible sources of threat intelligence. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -42126,7 +43918,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42147,11 +43940,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically compile audit records into an organization-wide audit trail that is time-correlated.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -42235,7 +44028,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42256,9 +44050,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide privileged users or roles the capability to change the auditing to be performed on specified system components, based on specific event criteria within specified time thresholds.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide privileged users or roles the capability to change the auditing to be performed on specified system components, based on specific event criteria within specified time thresholds. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -42325,7 +44119,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42432,7 +44227,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42458,7 +44254,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.\n▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum:\n(1) Establish what type of event occurred;\n(2) When (date and time) the event occurred;\n(3) Where the event occurred;\n(4) The source of the event;\n(5) The outcome (success or failure) of the event; and \n(6) The identity of any user/subject associated with the event.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum:\n(1) Establish what type of event occurred;\n(2) When (date and time) the event occurred;\n(3) Where the event occurred;\n(4) The source of the event;\n(5) The outcome (success or failure) of the event; and \n(6) The identity of any user/subject associated with the event. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -42532,15 +44328,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "MON-03.1", "title": "Sensitive Event Log Information", "family": "MON", - "description": "Mechanisms exist to protect sensitive/regulated data contained in log files.", - "scf_question": "Does the organization protect sensitive/regulated data contained in log files?", + "description": "Mechanisms exist to protect sensitive and/or regulated data contained in log files.", + "scf_question": "Does the organization protect sensitive and/or regulated data contained in log files?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -42555,7 +44352,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect sensitive/regulated data contained in log files.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect sensitive/regulated data contained in log files. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -42601,9 +44398,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed" + "MT-27", + "MT-28" + ] }, { "control_id": "MON-03.2", @@ -42698,7 +44495,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42792,7 +44590,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42849,7 +44648,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42870,7 +44670,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to limit Personal Data (PD) contained in audit records to the elements identified in the Data Privacy Risk Assessment (DPRA).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -42916,7 +44716,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -42937,9 +44738,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to centrally manage and update the criteria to be captured in event logs generated by organization-defined system components.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to centrally manage and update the criteria to be captured in event logs generated by organization-defined system components. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -42992,9 +44793,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "MON-03.7", @@ -43014,7 +44815,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to ensure databases produce audit records that contain sufficient information to monitor database activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -43079,7 +44880,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43102,7 +44904,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to allocate and proactively manage sufficient event log storage capacity to reduce the likelihood of such capacity being exceeded.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to allocate and proactively manage sufficient event log storage capacity to reduce the likelihood of such capacity being exceeded. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -43157,7 +44959,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43180,7 +44983,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to alert appropriate personnel in the event of a log processing failure and take actions to remedy the disruption.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -43241,7 +45044,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43262,9 +45066,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide 24x7x365 near real-time alerting capability when an event log processing failure occurs.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide 24x7x365 near real-time alerting capability when an event log processing failure occurs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -43319,7 +45123,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43340,7 +45145,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically alert appropriate personnel when the allocated volume reaches an organization-defined percentage of maximum event log storage capacity.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -43397,7 +45202,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43418,9 +45224,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide an event log report generation capability to aid in detecting and assessing anomalous activities.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide an event log report generation capability to aid in detecting and assessing anomalous activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -43492,7 +45298,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43513,7 +45320,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide and implement the capability for auditing the parameters of user query events for data sets containing Personal Data (PD).", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -43555,7 +45362,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43633,7 +45441,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43656,7 +45465,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use an authoritative time source to generate time stamps for event logs.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use an authoritative time source to generate time stamps for event logs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -43708,7 +45517,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43731,7 +45541,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to synchronize internal system clocks with an authoritative time source.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to synchronize internal system clocks with an authoritative time source. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -43783,7 +45593,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43804,7 +45615,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel retain security event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and/or contractual retention requirements.\n▪ IT and/or cybersecurity personnel restrict access to the management of event logs for privileged users to protect event logs and audit tools from unauthorized access, modification and deletion.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect event logs and audit tools from unauthorized access, modification and deletion.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -43877,7 +45688,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43950,7 +45762,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -43971,7 +45784,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict access to the management of event logs for privileged users to protect event logs and audit tools from unauthorized access, modification and deletion.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to restrict access to the management of event logs to privileged users with a specific business need.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -44030,7 +45843,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44051,9 +45865,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational cryptographic capability exists to protect the integrity of event logs and audit tools.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational cryptographic capability exists to protect the integrity of event logs and audit tools. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -44109,7 +45923,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44200,7 +46015,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44221,9 +46037,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a non-repudiation capability to protect against an individual falsely denying having performed a particular action.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a non-repudiation capability to protect against an individual falsely denying having performed a particular action. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -44264,7 +46080,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44317,7 +46134,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44342,7 +46160,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -44402,7 +46220,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44423,9 +46242,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of non-public information.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of non-public information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -44495,7 +46314,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44516,11 +46336,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically analyze network traffic to detect covert data exfiltration.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -44557,7 +46377,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44578,11 +46399,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically detect unauthorized network services and alert incident response personnel.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically detect unauthorized network services and alert incident response personnel. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -44637,7 +46458,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44661,11 +46483,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically identify and alert on Indicators of Compromise (IoC).", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically identify and alert on Indicators of Compromise (IoC). ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -44749,7 +46571,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44841,7 +46664,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44912,7 +46736,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -44933,7 +46758,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to coordinate sanitized event logs among external organizations to identify anomalous events when event logs are shared across organizational boundaries, without giving away sensitive or critical business data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -44990,7 +46815,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45011,7 +46837,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to share event logs with third-party organizations based on specific cross-organizational sharing agreements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45068,7 +46894,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45135,7 +46962,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45251,7 +47079,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45365,7 +47194,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45479,7 +47309,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45503,7 +47334,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for unauthorized activities, accounts, connections, devices and software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45593,7 +47424,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45705,7 +47537,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45726,7 +47559,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to ensure event log reviews include analysis and triage practices that integrate with the organization's established incident response processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45814,7 +47647,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -45835,7 +47669,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to make event log review processes more efficient and effective by developing and maintaining an incident response escalation matrix.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45923,15 +47757,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "MON-18", "title": "File Activity Monitoring (FAM)", "family": "MON", - "description": "Automated mechanisms exist to monitor sensitive/regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories.", - "scf_question": "Does the organization use automated tools to monitor sensitive/regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories?", + "description": "Automated mechanisms exist to monitor sensitive and/or regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories.", + "scf_question": "Does the organization use automated mechanisms to monitor sensitive and/or regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -46030,7 +47865,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46051,7 +47887,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to produce event logs on hardware-enforced, write-once media (e.g., Write Once Read Many (WORM) technologies).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46079,9 +47915,9 @@ "NT-7", "MT-2", "MT-8", - "MT-9" - ], - "errata": "- new control (IEC 62443-4-2)" + "MT-9", + "MT-28" + ] }, { "control_id": "CRY-01", @@ -46169,7 +48005,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46192,9 +48029,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of information as an alternative to physical safeguards.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of information as an alternative to physical safeguards. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -46263,7 +48100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46284,7 +48122,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to address the exporting of cryptographic technologies in compliance with relevant statutory and regulatory requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46318,7 +48156,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46339,7 +48178,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to ensure the confidentiality and integrity of information during preparation for transmission and during reception.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46378,7 +48217,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46399,7 +48239,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to conceal or randomize communication patterns.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46435,7 +48275,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46446,7 +48287,9 @@ "scf_question": "Does the organization identify, document and review deployed cryptographic cipher suites and protocols to proactively respond to industry trends regarding the continued viability of utilized cryptographic cipher suites and protocols?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", - "evidence_requests": [], + "evidence_requests": [ + "E-QTS-04" + ], "pptdf": "Process", "nist_csf_function": "Protect", "scrm_focus": { @@ -46456,7 +48299,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to identify, document and review deployed cryptographic cipher suites and protocols to proactively respond to industry trends regarding the continued viability of utilized cryptographic cipher suites and protocols.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46492,7 +48335,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46565,9 +48409,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed" + "MT-27", + "MT-28" + ] }, { "control_id": "CRY-03", @@ -46591,7 +48435,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Sensitive/regulated data is encrypted in transit according to standardized processes.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ Sensitive/regulated data is encrypted at rest using cryptographic protections that are commensurate with the sensitivity of the data.\n▪ Sensitive/regulated data is encrypted during transmission using cryptographic protections that are commensurate with the sensitivity of the data.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality of data being transmitted.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality of data being transmitted. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -46647,7 +48491,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46672,7 +48517,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ Sensitive/regulated data is encrypted at rest using cryptographic protections that are commensurate with the sensitivity of the data.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity of data being transmitted.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity of data being transmitted. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -46726,7 +48571,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46751,7 +48597,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of data at rest.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of data at rest. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -46807,15 +48653,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "CRY-05.1", "title": "Storage Media", "family": "CRY", - "description": "Cryptographic mechanisms exist to protect the confidentiality and integrity of sensitive/regulated data residing on storage media.", - "scf_question": "Are cryptographic mechanisms utilized to protect the confidentiality and integrity of sensitive/regulated data residing on storage media?", + "description": "Cryptographic mechanisms exist to protect the confidentiality and integrity of sensitive and/or regulated data residing on storage media.", + "scf_question": "Are cryptographic mechanisms utilized to protect the confidentiality and integrity of sensitive and/or regulated data residing on storage media?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -46828,7 +48675,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of sensitive/regulated data residing on storage media.", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -46883,7 +48730,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46971,7 +48819,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -46992,7 +48841,7 @@ }, "maturity": { "0": "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.", - "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.).", + "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.). ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure that database servers utilize encryption to protect the confidentiality of the data within the databases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -47059,7 +48908,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47131,7 +48981,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47207,7 +49058,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47228,9 +49080,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ The IT department implements Public Key Infrastructure (PKI) key management controls to protect the confidentiality, integrity and availability of keys.\n▪ The IT department implements and maintains an internal PKI infrastructure or obtains PKI services from a reputable PKI service provider.\n▪ The PKI infrastructure enables the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes.\n▪ The PKI infrastructure ensures the availability of information in the event of the loss of cryptographic keys by individual users.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -47289,7 +49141,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47310,7 +49163,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of data in the event of the loss of cryptographic keys.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -47376,7 +49229,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47400,7 +49254,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -47488,7 +49342,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47511,9 +49366,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of symmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of symmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -47576,7 +49431,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47599,9 +49455,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of asymmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes that protect the user’s private key.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of asymmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes that protect the user’s private key. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -47664,7 +49520,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47685,9 +49542,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of information in the event of the loss of cryptographic keys by individual users.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of information in the event of the loss of cryptographic keys by individual users. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -47769,7 +49626,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47790,9 +49648,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -47874,7 +49732,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47895,9 +49754,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure cryptographic keys are bound to individual identities.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure cryptographic keys are bound to individual identities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -47959,7 +49818,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -47980,7 +49840,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure customers are provided with appropriate key management guidance whenever cryptographic keys are shared.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -48015,7 +49875,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -48036,7 +49897,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to maintain control of cryptographic keys for encrypted material stored or transmitted through an external system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -48106,7 +49967,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -48127,9 +49989,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to associate Technology Assets, Applications and/or Services (TAAS) security attributes with information exchanged between TAAS.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to associate Technology Assets, Applications and/or Services (TAAS) security attributes with information exchanged between TAAS. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -48182,7 +50044,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -48203,7 +50066,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to automatically enable the use of organization-defined Certificate Authorities (CAs) to facilitate the establishment of protected sessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -48272,7 +50135,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -48364,7 +50228,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -48432,7 +50297,8 @@ "MT-16", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -48457,7 +50323,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ A basic data classification process exists to identify categories of sensitive/regulated data for compliance-related protection requirements.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of data protection controls.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of data protection controls. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -48556,7 +50422,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -48582,7 +50449,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data stewardship is assigned, documented and communicated.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data stewardship is assigned, documented and communicated. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -48654,15 +50521,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-01.2", "title": "Sensitive / Regulated Data Protection", "family": "DCH", - "description": "Mechanisms exist to protect sensitive/regulated data wherever it is processed and/or stored.", - "scf_question": "Does the organization protect sensitive/regulated data wherever it is processed and/or stored?", + "description": "Mechanisms exist to protect sensitive and/or regulated data wherever it is processed and/or stored.", + "scf_question": "Does the organization protect sensitive and/or regulated data wherever it is processed and/or stored?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -48679,7 +50547,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data wherever it is processed and/or stored.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -48720,15 +50588,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-01.3", "title": "Sensitive / Regulated Media Records", "family": "DCH", - "description": "Mechanisms exist to ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", - "scf_question": "Does the organization ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident?", + "description": "Mechanisms exist to ensure media records for sensitive and/or regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", + "scf_question": "Does the organization ensure media records for sensitive and/or regulated data contain sufficient information to determine the potential impact in the event of a data loss incident?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -48743,7 +50612,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -48832,15 +50701,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-01.4", "title": "Defining Access Authorizations for Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data.", - "scf_question": "Does the organization explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data?", + "description": "Mechanisms exist to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive and/or regulated data.", + "scf_question": "Does the organization explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive and/or regulated data?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -48856,7 +50726,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -48931,7 +50801,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -48955,9 +50826,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to categorize data in accordance with organizational policies and standards.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -49032,7 +50903,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49053,7 +50925,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to categorize data in accordance with organizational policies and standards.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that Technology Assets, Applications and/or Services (TAAS) are classified according to the highest level of data sensitivity that is stored, transmitted and/or processed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -49122,7 +50994,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49145,9 +51018,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to control and restrict access to digital and non-digital media to authorized individuals.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to control and restrict access to digital and non-digital media to authorized individuals. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -49235,15 +51108,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-03.1", "title": "Disclosure of Information", "family": "DCH", - "description": "Mechanisms exist to restrict the disclosure of sensitive/regulated data to authorized parties with a need to know.", - "scf_question": "Does the organization restrict the disclosure of sensitive/regulated data to authorized parties with a need to know?", + "description": "Mechanisms exist to restrict the disclosure of sensitive and/or regulated data to authorized parties with a need to know.", + "scf_question": "Does the organization restrict the disclosure of sensitive and/or regulated data to authorized parties with a need to know?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -49256,7 +51130,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the disclosure of sensitive/regulated data to authorized parties with a need to know.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -49338,15 +51212,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-03.2", "title": "Masking Displayed Data", "family": "DCH", - "description": "Mechanisms exist to apply data masking to sensitive/regulated information that is displayed or printed.", - "scf_question": "Does the organization apply data masking to sensitive/regulated information that is displayed or printed?", + "description": "Mechanisms exist to apply data masking to sensitive and/or regulated information that is displayed or printed.", + "scf_question": "Does the organization apply data masking to sensitive and/or regulated information that is displayed or printed?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -49359,9 +51234,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply data masking to sensitive/regulated information that is displayed or printed.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply data masking to sensitive/regulated information that is displayed or printed. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -49405,7 +51280,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49426,7 +51302,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically validate cybersecurity and data protection attributes prior to releasing information to external Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -49456,7 +51332,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49477,9 +51354,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to mark media in accordance with data protection requirements so that personnel are alerted to distribution limitations, handling caveats and applicable security requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to mark media in accordance with data protection requirements so that personnel are alerted to distribution limitations, handling caveats and applicable security requirements. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -49528,7 +51405,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49549,9 +51427,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically mark physical media and digital files to indicate the distribution limitations, handling requirements and applicable security markings (if any) of the information to aid Data Loss Prevention (DLP) technologies.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically mark physical media and digital files to indicate the distribution limitations, handling requirements and applicable security markings (if any) of the information to aid Data Loss Prevention (DLP) technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -49611,7 +51489,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49632,7 +51511,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to bind cybersecurity and data protection attributes to information as it is stored, transmitted and processed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -49679,7 +51558,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49700,7 +51580,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to dynamically associate cybersecurity and data protection attributes with individuals and objects as information is created, combined, or transformed, in accordance with organization-defined cybersecurity and data protection policies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -49747,7 +51627,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49768,7 +51649,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide authorized individuals (or processes acting on behalf of individuals) the capability to define or change the value of associated cybersecurity and data protection attributes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -49815,7 +51696,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49836,7 +51718,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain the association and integrity of cybersecurity and data protection attributes to individuals and objects.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -49883,7 +51765,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49904,7 +51787,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide the capability to associate cybersecurity and data protection attributes with individuals and objects by authorized individuals (or processes acting on behalf of individuals).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -49951,7 +51834,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -49972,7 +51856,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to display cybersecurity and data protection attributes in human-readable form on each object that the system transmits to output devices to identify special dissemination, handling or distribution instructions using human-readable, standard naming conventions.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50019,7 +51903,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50040,7 +51925,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to require personnel to associate and maintain the association of cybersecurity and data protection attributes with individuals and objects in accordance with cybersecurity and data protection policies.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50087,7 +51972,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50108,7 +51994,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide a consistent, organizationally agreed upon interpretation of cybersecurity and data protection attributes employed in access enforcement and flow enforcement decisions between distributed system components.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50155,7 +52041,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50176,7 +52063,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to associate cybersecurity and data protection attributes to information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50223,7 +52110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50244,7 +52132,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to reclassify data as required, due to changing business/technical requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50291,7 +52179,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50312,7 +52201,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide authorized individuals the capability to define or change the type and value of cybersecurity and data protection attributes available for association with subjects and objects.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -50359,7 +52248,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50384,7 +52274,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to audit changes to cybersecurity and data protection attributes and responds to events in accordance with incident response procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -50432,7 +52322,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50440,7 +52331,7 @@ "title": "Media Storage", "family": "DCH", "description": "Mechanisms exist to: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures.", - "scf_question": "Does the organization: \n (1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n (2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures?", + "scf_question": "Does the organization: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -50460,7 +52351,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -50534,7 +52425,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50555,7 +52447,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to physically secure all media that contains sensitive information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50631,7 +52523,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50654,9 +52547,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain inventory logs of all sensitive media and conduct sensitive media inventories at least annually.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain inventory logs of all sensitive media and conduct sensitive media inventories at least annually. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -50733,15 +52626,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-06.3", "title": "Periodic Scans for Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", - "scf_question": "Does the organization periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations?", + "description": "Mechanisms exist to periodically scan unstructured data sources for sensitive and/or regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", + "scf_question": "Does the organization periodically scan unstructured data sources for sensitive and/or regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations?", "relative_weight": 7, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -50756,9 +52650,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -50818,15 +52712,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-06.4", "title": "Making Sensitive Data Unreadable In Storage", "family": "DCH", - "description": "Mechanisms exist to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored.", - "scf_question": "Does the organization ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored?", + "description": "Mechanisms exist to ensure sensitive and/or regulated data is rendered human unreadable anywhere sensitive and/or regulated data is stored.", + "scf_question": "Does the organization ensure sensitive and/or regulated data is rendered human unreadable anywhere sensitive and/or regulated data is stored?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -50839,9 +52734,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -50899,7 +52794,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -50920,9 +52816,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the storage of sensitive transaction authentication data after authorization.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the storage of sensitive transaction authentication data after authorization. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -50977,7 +52873,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51000,7 +52897,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ Data classification and handling criteria govern user behavior for media handling.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect and control digital and non-digital media during transport outside of controlled areas using appropriate security measures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -51086,7 +52983,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51109,7 +53007,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ Data classification and handling criteria govern user behavior for media handling.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify custodians throughout the transport of digital or non-digital media.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify custodians throughout the transport of digital or non-digital media. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -51193,7 +53091,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51214,7 +53113,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -51274,7 +53173,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51297,9 +53197,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of media when it is no longer required, using formal procedures.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of media when it is no longer required, using formal procedures. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -51375,7 +53275,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51399,7 +53300,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to sanitize system media with the strength and integrity commensurate with the classification or sensitivity of the information prior to disposal, release out of organizational control or release for reuse.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -51476,7 +53377,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51500,9 +53402,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to supervise, track, document and verify system media sanitization and disposal actions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to supervise, track, document and verify system media sanitization and disposal actions. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -51573,7 +53475,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51594,9 +53497,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to test sanitization equipment and procedures to verify that the intended result is achieved.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to test sanitization equipment and procedures to verify that the intended result is achieved. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -51667,7 +53570,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51688,7 +53592,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the sanitization of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -51766,7 +53670,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51787,7 +53692,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply nondestructive sanitization techniques to portable storage devices prior to first use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -51846,15 +53751,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-09.5", "title": "Dual Authorization for Sensitive Data Destruction", "family": "DCH", - "description": "Mechanisms exist to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data.", - "scf_question": "Does the organization enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data?", + "description": "Mechanisms exist to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive and/or regulated data.", + "scf_question": "Does the organization enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive and/or regulated data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -51867,7 +53773,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -51948,7 +53854,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -51969,9 +53876,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of types of digital media on systems or system components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of types of digital media on systems or system components. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -52030,15 +53937,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-10.1", "title": "Limitations on Use", "family": "DCH", - "description": "Mechanisms exist to restrict the use and distribution of sensitive/regulated data.", - "scf_question": "Does the organization restrict the use and distribution of sensitive/regulated data?", + "description": "Mechanisms exist to restrict the use and distribution of sensitive and/or regulated data.", + "scf_question": "Does the organization restrict the use and distribution of sensitive and/or regulated data?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -52053,9 +53961,9 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ Limited media handling guidance exists for users.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use and distribution of sensitive/regulated data.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use and distribution of sensitive/regulated data. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -52108,7 +54016,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -52129,7 +54038,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the use of portable storage devices in organizational systems when such devices have no identifiable owner.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52189,7 +54098,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -52210,11 +54120,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to reclassify data, including associated Technology Assets, Applications and/or Services (TAAS), commensurate with the security category and/or classification level of the information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -52275,7 +54185,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -52296,7 +54207,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict removable media in accordance with data handling and acceptable usage parameters.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -52365,7 +54276,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -52386,11 +54298,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern how external parties, including Technology Assets, Applications and/or Services (TAAS), are used to securely store, process and transmit data.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern how external parties, including Technology Assets, Applications and/or Services (TAAS), are used to securely store, process and transmit data. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -52474,7 +54386,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -52495,7 +54408,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit external parties, including Technology Assets, Applications and/or Services (TAAS), from storing, processing and transmitting data unless authorized individuals first: \n(1) Verifying the implementation of required security, compliance and/or resilience controls; or\n(2) Retaining a processing agreement with the entity hosting the external TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52563,9 +54476,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "DCH-13.2", @@ -52585,9 +54498,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict or prohibit the use of portable storage devices by users on external systems.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict or prohibit the use of portable storage devices by users on external systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -52670,15 +54583,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-13.3", "title": "Protecting Sensitive / Regulated Data on External Technology Assets, Applications and/or Services (TAAS)", "family": "DCH", - "description": "Mechanisms exist to ensure that the requirements for the protection of sensitive/regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization ensure that the requirements for the protection of sensitive/regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to ensure that the requirements for the protection of sensitive and/or regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization ensure that the requirements for the protection of sensitive and/or regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations?", "relative_weight": 10, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -52776,7 +54690,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -52797,7 +54712,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of non-organizationally owned Technology Assets, Applications and/or Services (TAAS) to process, store or transmit organizational information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -52881,7 +54796,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -52905,11 +54821,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a process to assist users in making information sharing decisions to ensure data is appropriately protected.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -52974,7 +54890,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -52995,7 +54912,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications and/or Services (TAAS) implement data search and retrieval functions that properly enforce data protection / sharing restrictions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53068,7 +54985,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -53089,7 +55007,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to verify that individuals or Technology Assets, Applications and/or Services (TAAS) transferring data between interconnecting TAAS have the requisite authorizations (e.g., write permissions or privileges) prior to transferring said data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53157,15 +55075,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-14.3", "title": "Data Access Mapping", "family": "DCH", - "description": "Mechanisms exist to leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive/regulated data is shared.", - "scf_question": "Does the organization leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive/regulated data is shared?", + "description": "Mechanisms exist to leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive and/or regulated data is shared.", + "scf_question": "Does the organization leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive and/or regulated data is shared?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -53247,7 +55166,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -53339,7 +55259,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -53362,7 +55283,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect data storage objects against unauthorized data mining and data harvesting techniques.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect data storage objects against unauthorized data mining and data harvesting techniques. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -53419,7 +55340,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -53444,7 +55366,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to secure ad-hoc exchanges of large digital files with internal or external parties.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -53512,7 +55434,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -53537,7 +55460,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ A manual data retention process exists.\n▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -53623,15 +55546,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-18.1", "title": "Minimize Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", - "scf_question": "Does the organization minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes?", + "description": "Mechanisms exist to minimize sensitive and/or regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", + "scf_question": "Does the organization minimize sensitive and/or regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -53648,7 +55572,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -53711,15 +55635,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-18.2", "title": "Limit Sensitive / Regulated Data In Testing, Training & Research", "family": "DCH", - "description": "Mechanisms exist to minimize the use of sensitive/regulated data for research, testing, or training, in accordance with authorized, legitimate business practices.", - "scf_question": "Does the organization minimize the use of Personal Data (PD) for research, testing, or training, in accordance with the Data Protection Impact Assessment (DPIA)?", + "description": "Mechanisms exist to minimize the use of sensitive and/or regulated data for research, testing, or training, in accordance with authorized, legitimate business practices.", + "scf_question": "Does the organization minimize the use of sensitive and/or regulated data for research, testing, or training, in accordance with authorized, legitimate business practices?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -53800,7 +55725,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -53825,7 +55751,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform periodic checks of temporary files for the existence of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -53886,7 +55812,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -53909,11 +55836,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to inventory, document and maintain data flows for data that is resident (permanently or temporarily) within a service's geographically distributed applications (physical and virtual), infrastructure, systems components and/or shared with other third-parties.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -53996,7 +55923,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54017,9 +55945,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect archived data in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect archived data in accordance with applicable statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -54076,7 +56004,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54097,7 +56026,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of, destroy or erase information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54183,7 +56112,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54191,7 +56121,7 @@ "title": "Data Quality Operations", "family": "DCH", "description": "Mechanisms exist to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", - "scf_question": "Does the organization check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", + "scf_question": "Does the organization check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -54204,11 +56134,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -54262,7 +56192,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54283,7 +56214,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize technical controls to correct Personal Data (PD) that is inaccurate or outdated, incorrectly determined regarding impact, or incorrectly de-identified.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54353,15 +56284,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-22.2", "title": "Data Tags", "family": "DCH", - "description": "Mechanisms exist to utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle.", - "scf_question": "Does the organization utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle?", + "description": "Mechanisms exist to utilize data tags to automate tracking of sensitive and/or regulated data across the information lifecycle.", + "scf_question": "Does the organization utilize data tags to automate tracking of sensitive and/or regulated data across the information lifecycle?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -54374,11 +56306,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -54433,7 +56365,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54454,9 +56387,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to collect Personal Data (PD) directly from the individual.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to collect Personal Data (PD) directly from the individual. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -54502,7 +56435,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54523,7 +56457,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to anonymize data by removing Personal Data (PD) from datasets.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54574,7 +56508,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54595,7 +56530,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to de-identify the dataset upon collection by not collecting Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54644,7 +56579,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54665,7 +56601,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to refrain from archiving Personal Data (PD) elements if those elements in a dataset will not be needed after the dataset is archived.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54714,7 +56650,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54735,7 +56672,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to remove Personal Data (PD) elements from a dataset prior to its release if those elements in the dataset do not need to be part of the data release.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54786,7 +56723,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54807,7 +56745,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to remove, mask, encrypt, hash or replace direct identifiers in a dataset.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54857,7 +56795,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54878,7 +56817,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to manipulate numerical data, contingency tables and statistical findings so that no person or organization is identifiable in the results of the analysis.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54917,7 +56856,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -54938,7 +56878,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prevent disclosure of Personal Data (PD) by adding non-deterministic noise to the results of mathematical operations before the results are reported.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54977,15 +56917,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-23.7", "title": "Automated De-Identification of Sensitive Data", "family": "DCH", - "description": "Mechanisms exist to perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms.", - "scf_question": "Does the organization perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms?", + "description": "Mechanisms exist to perform de-identification of sensitive and/or regulated data, using validated algorithms and software to implement the algorithms.", + "scf_question": "Does the organization perform de-identification of sensitive and/or regulated data, using validated algorithms and software to implement the algorithms?", "relative_weight": 1, "conformity_cadence": "Annual", "evidence_requests": [], @@ -54998,7 +56939,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -55036,7 +56977,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -55057,7 +56999,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform a motivated intruder test on the de-identified dataset to determine if the identified data remains or if the de-identified data can be re-identified.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -55096,15 +57038,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "DCH-23.9", "title": "Code Names", "family": "DCH", - "description": "Mechanisms exist to use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data.", - "scf_question": "Does the organization use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data?", + "description": "Mechanisms exist to use aliases to name assets, which are mission-critical and/or contain highly-sensitive and/or regulated data, are unique and not readily associated with a product, project or type of data.", + "scf_question": "Does the organization use aliases to name assets, which are mission-critical and/or contain highly-sensitive and/or regulated data, are unique and not readily associated with a product, project or type of data?", "relative_weight": 1, "conformity_cadence": "Annual", "evidence_requests": [], @@ -55117,7 +57060,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -55156,7 +57099,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -55179,11 +57123,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify and document the location of information and the specific system components on which the information resides.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -55246,7 +57190,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -55254,7 +57199,7 @@ "title": "Automated Tools to Support Information Location", "family": "DCH", "description": "Automated mechanisms exist to identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection.", - "scf_question": "Does the organization identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection?", + "scf_question": "Does the organization use automated mechanisms to identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection?", "relative_weight": 6, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -55271,7 +57216,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -55328,9 +57273,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "DCH-25", @@ -55350,11 +57295,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict and govern the transfer of sensitive and/or regulated data to third-countries or international organizations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -55417,7 +57362,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -55438,7 +57384,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to establish organization-defined \"normal business activities\" to identify anomalous transaction activities that can reduce the opportunity for sending (outbound) and/or receiving (inbound) fraudulent actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -55484,7 +57430,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -55505,7 +57452,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to constrain the impact of \"digital sovereignty laws,\" that require localized data within the host country, where data and processes may be subjected to arbitrary enforcement actions that potentially violate other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -55572,7 +57519,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -55680,7 +57628,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -55705,7 +57654,7 @@ "0": "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.", "1": "Embedded Technology (EMB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with EMB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Embedded technology management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Embedded technologies (e.g., Operational Technology (OT) and Internet of Things (IoT) are managed in the same manner as any other technology asset.", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.", - "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to facilitate the implementation of embedded technology controls.", + "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to facilitate the implementation of embedded technology controls. ", "4": "Embedded Technology (EMB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -55799,7 +57748,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -55907,9 +57857,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "EMB-03", @@ -56016,9 +57966,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "EMB-04", @@ -56038,7 +57988,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Special baselines for embedded technologies configurations are created for higher-risk environments.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to protect embedded devices against unauthorized use of the physical factory diagnostic and test interface(s).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56123,7 +58073,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56144,7 +58095,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to generate log entries on embedded devices when configuration changes or attempts to access interfaces are detected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56229,7 +58180,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56250,7 +58202,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to protect embedded devices by preventing the unauthorized installation and execution of software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56337,7 +58289,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56358,7 +58311,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to securely update software and upgrade functionality on embedded devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56445,7 +58398,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56466,7 +58420,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to configure embedded technology to be resilient to data network and power outages.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56551,7 +58505,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56572,7 +58527,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to automatically monitor the power levels of embedded technologies for decreased or excessive power usage, including battery drainage, to investigate for device tampering.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56634,7 +58589,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56655,7 +58611,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to perform evaluations of deployed embedded technologies as needed, or at least on an annual basis, to ensure that necessary updates to mitigate the risks associated with legacy embedded technologies are identified and implemented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56710,7 +58666,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56731,7 +58688,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to enforce the security of Message Queuing Telemetry Transport (MQTT) traffic.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56778,7 +58735,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56799,7 +58757,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to require embedded technologies to initiate all communications and drop new, incoming communications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56846,7 +58804,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56867,7 +58826,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to restrict embedded technologies to communicate only with authorized peers and service endpoints.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56914,7 +58873,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -56935,7 +58895,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to determine if embedded technologies are certified for secure use in the proposed operating environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56993,7 +58953,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57014,7 +58975,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to evaluate the safety aspects of embedded technologies via a fault tree analysis, or similar method, to determine possible consequences of misuse, misconfiguration and/or failure.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57093,7 +59054,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57114,7 +59076,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to enforce certificate-based authentication for embedded technologies (e.g., IoT, OT, etc.) and their supporting services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57161,7 +59123,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57182,7 +59145,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to implement embedded technologies that utilize pre-provisioned cloud trust anchors to support secure bootstrap and Zero Touch Provisioning (ZTP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57229,7 +59192,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57250,7 +59214,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to ensure embedded technologies utilize a securely configured Real-Time Operating System (RTOS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57297,7 +59261,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57318,7 +59283,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to continuously validate autonomous systems that trigger an automatic state change when safe operation is no longer assured.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57380,7 +59345,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57503,7 +59469,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57617,7 +59584,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57642,7 +59610,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to protect the confidentiality, integrity, availability and safety of endpoint devices.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -57726,7 +59694,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57751,7 +59720,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically prohibit software installations without explicitly assigned privileged status.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically prohibit software installations without explicitly assigned privileged status. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -57823,7 +59792,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -57846,7 +59816,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to generate an alert when new software is detected.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to generate an alert when new software is detected. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -57915,7 +59885,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58010,7 +59981,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58034,7 +60006,7 @@ }, "maturity": { "0": "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.", - "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-malware technologies are decentralized but are deployed on all technology assets that can run anti-malware software.", + "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-malware technologies are decentralized but are deployed on all technology assets that can run anti-malware software. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).\n▪ Anti-malware detection tools are configured to automatically update.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize antimalware technologies to detect and eradicate malicious code.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -58110,7 +60082,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58118,7 +60091,7 @@ "title": "Automatic Antimalware Signature Updates", "family": "END", "description": "Automated mechanisms exist to update antimalware technologies, including signature definitions.", - "scf_question": "Does the organization automatically update antimalware technologies, including signature definitions?", + "scf_question": "Does the organization use automated mechanisms to update antimalware technologies, including signature definitions?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -58135,7 +60108,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware detection tools are configured to automatically update.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically update antimalware technologies, including signature definitions.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically update antimalware technologies, including signature definitions. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -58207,7 +60180,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58276,7 +60250,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58390,7 +60365,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58485,7 +60461,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58508,7 +60485,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to test antimalware technologies by introducing a known benign, non-spreading test case into the system and subsequently verifying that both detection of the test case and associated incident reporting occurs.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to test antimalware technologies by introducing a known benign, non-spreading test case into the system and subsequently verifying that both detection of the test case and associated incident reporting occurs. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -58575,7 +60552,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58598,7 +60576,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to perform periodic evaluations evolving malware threats to assess systems that are generally not considered to be commonly affected by malicious software.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to perform periodic evaluations evolving malware threats to assess systems that are generally not considered to be commonly affected by malicious software. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -58665,7 +60643,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58688,7 +60667,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure that anti-malware technologies are continuously running in real-time and cannot be disabled or altered by non-privileged users, unless specifically authorized by management on a case-by-case basis for a limited time period.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure that anti-malware technologies are continuously running in real-time and cannot be disabled or altered by non-privileged users, unless specifically authorized by management on a case-by-case basis for a limited time period. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -58760,7 +60739,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58850,7 +60830,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58877,7 +60858,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize File Integrity Monitor (FIM), or similar technologies, to detect and report on unauthorized changes to selected files and configuration settings.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -58947,7 +60928,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -58972,7 +60954,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to validate configurations through integrity checking of software and firmware.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -59037,7 +61019,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59058,7 +61041,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to detect and respond to unauthorized configuration changes as cybersecurity incidents.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -59129,7 +61112,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59150,11 +61134,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically alert incident response personnel upon discovering discrepancies during integrity verification.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically alert incident response personnel upon discovering discrepancies during integrity verification. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -59218,7 +61202,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59239,11 +61224,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions when integrity violations are discovered.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions when integrity violations are discovered. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -59307,7 +61292,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59328,11 +61314,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically verify the integrity of the boot process of systems.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -59396,7 +61382,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59421,7 +61408,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically protect the integrity of boot firmware in systems.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -59487,7 +61474,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59508,7 +61496,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to prohibit the use of binary or machine-executable code from sources with limited or no warranty and without access to source code.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -59577,7 +61565,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59667,7 +61656,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59761,7 +61751,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -59858,15 +61849,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "END-08.1", - "title": "Central Management", + "title": "Phishing & Spam Protection Centralized Management", "family": "END", - "description": "Mechanisms exist to centrally-manage anti-phishing and spam protection technologies.", - "scf_question": "Does the organization centrally-manage anti-phishing and spam protection technologies?", + "description": "Mechanisms exist to centrally manage anti-phishing and spam protection technologies.", + "scf_question": "Does the organization centrally manage anti-phishing and spam protection technologies?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -59881,7 +61873,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-spam/phishing technologies are centralized and built into existing email capabilities.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-spam/phishing technologies are centralized and built into existing email capabilities.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to centrally-manage anti-phishing and spam protection technologies.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to centrally manage anti-phishing and spam protection technologies.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -59966,8 +61958,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- renamed control\n- wordsmithed" }, { "control_id": "END-08.2", @@ -60056,7 +62050,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60146,7 +62141,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60171,7 +62167,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to address mobile code / operating system-independent applications.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to address mobile code / operating system-independent applications. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -60242,7 +62238,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60265,7 +62262,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to configure thin nodes to have minimal functionality and information storage.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to configure thin nodes to have minimal functionality and information storage. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -60332,7 +62329,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60422,7 +62420,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60514,7 +62513,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60606,7 +62606,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60682,7 +62683,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60703,7 +62705,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize sensors that are configured to minimize the collection of information about individuals.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60758,7 +62760,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60848,7 +62851,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60942,7 +62946,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -60963,11 +62968,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to disable or remove collaborative computing devices from critical systems and secure work areas.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -61035,7 +63040,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61126,7 +63132,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61197,7 +63204,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61218,7 +63226,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure the meeting host can positively control an individual's participation in virtual meetings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61267,7 +63275,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61324,7 +63333,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61394,7 +63404,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61485,7 +63496,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61576,7 +63588,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61599,7 +63612,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to implement underlying software separation mechanisms to facilitate security function isolation.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to implement underlying software separation mechanisms to facilitate security function isolation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -61665,7 +63678,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61787,7 +63801,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61879,7 +63894,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -61977,15 +63993,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "HRS-02.1", "title": "Users With Elevated Privileges", "family": "HRS", - "description": "Mechanisms exist to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question.", - "scf_question": "Does the organization ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question?", + "description": "Mechanisms exist to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive and/or regulated data is cleared and regularly trained to handle the information in question.", + "scf_question": "Does the organization ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive and/or regulated data is cleared and regularly trained to handle the information in question?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -62004,7 +64021,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates risk for individuals requiring elevated privileges or access to sensitive/regulated data.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -62077,7 +64094,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62166,7 +64184,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62199,7 +64218,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Formal roles and responsibilities for cybersecurity and/or data protection are not consistent and/or standardized.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define cybersecurity roles & responsibilities for all personnel.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define cybersecurity roles & responsibilities for all personnel. ", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -62268,7 +64287,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62294,7 +64314,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to communicate with users about their roles and responsibilities to maintain a safe and secure working environment.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -62380,7 +64400,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62406,7 +64427,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Formal roles and responsibilities for cybersecurity and/or data protection are not consistent and/or standardized.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that all security-related positions are staffed by qualified individuals who have the necessary skill set.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that all security-related positions are staffed by qualified individuals who have the necessary skill set. ", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -62490,7 +64511,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62602,7 +64624,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62626,7 +64649,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that individuals accessing a system that stores, transmits or processes information requiring special protection satisfy organization-defined personnel screening criteria.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -62699,7 +64722,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62722,7 +64746,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department governs personnel management operations and notifies IT and/or cybersecurity personnel of role changes for logical access provisioning and deprovisioning actions.\n▪ Personnel managers ensure personnel are responsible for educating new hires on the organization's cybersecurity and data protection policies.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to formally educate authorized users on proper data handling practices for all the relevant types of data to which they have access.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -62806,7 +64830,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62827,7 +64852,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to verify that individuals accessing a system processing, storing, or transmitting sensitive information meet applicable statutory, regulatory and/or contractual requirements for citizenship.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62895,7 +64920,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -62916,7 +64942,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to identify foreign nationals, including by their specific citizenship.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62984,7 +65010,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -63096,9 +65123,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "HRS-05.1", @@ -63208,7 +65235,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -63234,7 +65262,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define rules of behavior that contain explicit restrictions on the use of social media and networking sites, posting information on commercial websites and sharing account information.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define rules of behavior that contain explicit restrictions on the use of social media and networking sites, posting information on commercial websites and sharing account information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63302,7 +65330,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -63310,7 +65339,7 @@ "title": "Technology Use Restrictions", "family": "HRS", "description": "Mechanisms exist to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously.", - "scf_question": "Does the organization establish usage restrictions and implementation guidance for communications technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously?", + "scf_question": "Does the organization establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -63327,7 +65356,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63412,7 +65441,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -63437,7 +65467,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern usage policies for critical technologies.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern usage policies for critical technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63521,7 +65551,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -63544,7 +65575,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to manage business risks associated with permitting mobile device access to organizational resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63630,7 +65661,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -63651,7 +65683,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to prohibit the use of oversized clothing (e.g., baggy pants, oversized hooded sweatshirts, etc.) to prevent the unauthorized exfiltration of data and technology assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63688,7 +65720,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -63696,7 +65729,7 @@ "title": "Policy Familiarization & Acknowledgement", "family": "HRS", "description": "Mechanisms exist to ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement.", - "scf_question": "Does the organization ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement?", + "scf_question": "Does the organization ensure personnel receive recurring familiarization with its security, compliance and resilience policies and provide acknowledgement?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -63713,7 +65746,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63796,9 +65829,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "HRS-06", @@ -63820,9 +65853,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to require internal and third-party users to sign appropriate access agreements prior to being granted access.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to require internal and third-party users to sign appropriate access agreements prior to being granted access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63890,7 +65923,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -63983,15 +66017,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "HRS-06.2", "title": "Post-Employment Requirements Awareness", "family": "HRS", - "description": "Mechanisms exist to notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive/regulated data.", - "scf_question": "Does the organization notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive/regulated data?", + "description": "Mechanisms exist to notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive and/or regulated data.", + "scf_question": "Does the organization notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive and/or regulated data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -64087,7 +66122,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -64113,7 +66149,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Requests for investigations are handled through a formal, management-approved process.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to sanction personnel failing to comply with established security policies, standards and procedures.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to sanction personnel failing to comply with established security policies, standards and procedures. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -64198,7 +66234,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -64219,9 +66256,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Requests for investigations are handled through a formal, management-approved process.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to conduct employee misconduct investigations when there is reasonable assurance that a policy has been violated.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to conduct employee misconduct investigations when there is reasonable assurance that a policy has been violated. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -64307,7 +66344,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -64413,15 +66451,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "HRS-07.3", "title": "Preventative Access Restriction", "family": "HRS", - "description": "Mechanisms exist to proactively restrict logical and physical access when an individual with access to sensitive/regulated data is under investigation for personnel sanctions that may lead to employment termination.", - "scf_question": "Does the organization proactively restrict logical and physical access when an individual with access to sensitive/regulated data is under investigation for personnel sanctions that may lead to employment termination?", + "description": "Mechanisms exist to proactively restrict logical and physical access when an individual with access to sensitive and/or regulated data is under investigation for personnel sanctions that may lead to employment termination.", + "scf_question": "Does the organization proactively restrict logical and physical access when an individual with access to sensitive and/or regulated data is under investigation for personnel sanctions that may lead to employment termination?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -64517,7 +66556,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -64627,7 +66667,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -64738,7 +66779,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -64761,7 +66803,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to retrieve organization-owned assets upon termination of an individual's employment.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -64846,7 +66888,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -64869,7 +66912,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to expedite the process of removing \"high risk\" individual’s access to TAASD upon termination, as determined by management.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -64956,15 +66999,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "HRS-09.3", "title": "Post-Employment Requirements Notification", "family": "HRS", - "description": "Mechanisms exist to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data.", - "scf_question": "Does the organization govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data?", + "description": "Mechanisms exist to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive and/or regulated data.", + "scf_question": "Does the organization govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -64979,7 +67023,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -65061,7 +67105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -65082,11 +67127,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to automatically notify Identity and Access Management (IAM) personnel or roles upon termination of an individual employment or contract.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -65151,7 +67196,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -65176,7 +67222,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern third-party personnel by reviewing and monitoring third-party security, compliance and/or resilience roles and responsibilities.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -65267,9 +67313,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "HRS-11", @@ -65378,7 +67424,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -65401,7 +67448,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates risk for individuals requiring elevated privileges or access to sensitive/regulated data.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to avoid incompatible development-specific roles through limiting and reviewing developer privileges to change hardware, software and firmware components within a production/operational environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -65474,7 +67521,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -65581,7 +67629,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -65589,7 +67638,7 @@ "title": "Identify Critical Skills & Gaps", "family": "HRS", "description": "Mechanisms exist to evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist.", - "scf_question": "Does the organization evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist?", + "scf_question": "Does the organization evaluate the critical security, compliance and resilience skills needed to support its mission and identify gaps that exist?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -65673,9 +67722,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "HRS-13.1", @@ -65764,7 +67813,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -65854,9 +67904,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "HRS-13.3", @@ -65943,9 +67993,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "HRS-13.4", @@ -65965,7 +68015,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates the business-critical cybersecurity and data protection skills needed to support the organization's mission and identify gaps that exist.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to perform succession planning for vital security, compliance and resilience roles.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -66033,16 +68083,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "HRS-14", "title": "Identifying Authorized Work Locations", "family": "HRS", "description": "Mechanisms exist to identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home).", - "scf_question": "Does the organization identity and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home)?", + "scf_question": "Does the organization identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -66055,7 +68105,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -66123,7 +68173,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -66144,7 +68195,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to communicate authorized work locations to organizational personnel.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -66210,7 +68261,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -66302,7 +68354,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -66426,7 +68479,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -66447,7 +68501,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to retain a record of personnel accountability to ensure there is a record of all access granted to an individual (system and application-wise), who provided the authorization, when the authorization was granted and when the access was last reviewed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -66533,7 +68587,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -66556,7 +68611,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).\n▪ LAC and RBAC enforcements limit the ability of non-administrators from making unauthorized configuration changes to TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to strictly govern the use of Authenticate, Authorize and Audit (AAA) solutions, both on-premises and those hosted by an External Service Provider (ESP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -66635,7 +68690,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -66759,134 +68815,21 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "IAC-02", - "title": "Identification & Authentication for Organizational Users", + "control_id": "IAC-01.4", + "title": "Identity Providers (IdP) & Authorization Servers", "family": "IAC", - "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", - "scf_question": "Does the organization uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users?", - "relative_weight": 9, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-IAM-05", - "E-IAM-06", - "E-IAM-13" - ], - "pptdf": "Technology", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": true, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], - "possible_solutions": { - "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" - }, - "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", - "R-AM-3", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-GV-8", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", - "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", - "MT-1", - "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "IAC-02.1", - "title": "Group Authentication", - "family": "IAC", - "description": "Mechanisms exist to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized.", - "scf_question": "Does the organization require individuals to be authenticated with an individual authenticator when a group authenticator is utilized?", + "description": "Mechanisms exist to employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms.", + "scf_question": "Does the organization employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], - "pptdf": "Technology", - "nist_csf_function": "Protect", + "pptdf": "Process", + "nist_csf_function": "Identify", "scrm_focus": { "strategic": false, "operational": true, @@ -66894,21 +68837,19 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Secure Baseline Configurations (SBC)", - "small": "∙ Secure Baseline Configurations (SBC)", - "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" + "micro_small": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "small": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "medium": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "large": "∙ Microsoft Entra ID with conditional access\n∙ Okta Workforce Identity\n∙ SailPoint for identity governance", + "enterprise": "∙ Enterprise IdP with federation (SAML/OIDC/OAuth 2.0)\n∙ Microsoft Entra ID with Privileged Identity Management\n∙ Okta or Ping Identity enterprise tier\n∙ SailPoint or Saviynt for identity governance" }, "risks": [ "R-AC-1", @@ -66953,6 +68894,10 @@ "NT-7", "MT-1", "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", "MT-7", "MT-8", "MT-9", @@ -66964,34 +68909,36 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3" }, { - "control_id": "IAC-02.2", - "title": "Replay-Resistant Authentication", + "control_id": "IAC-02", + "title": "Identification & Authentication for Organizational Users", "family": "IAC", - "description": "Automated mechanisms exist to employ replay-resistant authentication.", - "scf_question": "Does the organization use automated mechanisms to employ replay-resistant authentication?", + "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", + "scf_question": "Does the organization uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users?", "relative_weight": 9, - "conformity_cadence": "Quarterly", + "conformity_cadence": "Annual", "evidence_requests": [ - "E-AST-01", "E-IAM-05", - "E-IAM-06" + "E-IAM-06", + "E-IAM-13" ], "pptdf": "Technology", "nist_csf_function": "Protect", "scrm_focus": { - "strategic": false, + "strategic": true, "operational": true, "tactical": true }, "maturity": { "0": "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.", - "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", + "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically employ replay-resistant authentication.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -67002,99 +68949,11 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Secure Baseline Configurations (SBC)", - "small": "∙ Secure Baseline Configurations (SBC)", - "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" - }, - "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", - "R-AM-3", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-GV-8", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "IAC-02.3", - "title": "Acceptance of PIV Credentials", - "family": "IAC", - "description": "Mechanisms exist to accept and electronically verify organizational Personal Identity Verification (PIV) credentials.", - "scf_question": "Does the organization accept and electronically verify organizational Personal Identity Verification (PIV) credentials?", - "relative_weight": 2, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Technology", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify organizational Personal Identity Verification (PIV) credentials.", - "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "micro_small": "∙ Secure Baseline Configurations (SBC)", - "small": "∙ Secure Baseline Configurations (SBC)", - "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" + "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" }, "risks": [ "R-AC-1", @@ -67166,16 +69025,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "IAC-02.4", - "title": "Out-of-Band Authentication (OOBA)", + "control_id": "IAC-02.1", + "title": "Group Authentication", "family": "IAC", - "description": "Mechanisms exist to implement Out-of-Band Authentication (OOBA) under specific conditions.", - "scf_question": "Does the organization implement Out-of-Band Authentication (OOBA) under specific conditions?", - "relative_weight": 5, + "description": "Mechanisms exist to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized.", + "scf_question": "Does the organization require individuals to be authenticated with an individual authenticator when a group authenticator is utilized?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Technology", @@ -67187,13 +69047,15 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Out-of-Band Authentication (OOBA) under specific conditions.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [], + "profiles": [ + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], "possible_solutions": { "micro_small": "∙ Secure Baseline Configurations (SBC)", "small": "∙ Secure Baseline Configurations (SBC)", @@ -67241,25 +69103,9 @@ "R-SC-6" ], "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", "MT-1", "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", "MT-7", "MT-8", "MT-9", @@ -67271,18 +69117,20 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "IAC-03", - "title": "Identification & Authentication for Non-Organizational Users", + "control_id": "IAC-02.2", + "title": "Replay-Resistant Authentication", "family": "IAC", - "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization.", - "scf_question": "Does the organization uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization?", + "description": "Automated mechanisms exist to employ replay-resistant authentication.", + "scf_question": "Does the organization use automated mechanisms to employ replay-resistant authentication?", "relative_weight": 9, - "conformity_cadence": "Annual", + "conformity_cadence": "Quarterly", "evidence_requests": [ + "E-AST-01", "E-IAM-05", "E-IAM-06" ], @@ -67295,10 +69143,10 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization.", - "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically employ replay-resistant authentication.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ @@ -67308,11 +69156,11 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" + "micro_small": "∙ Secure Baseline Configurations (SBC)", + "small": "∙ Secure Baseline Configurations (SBC)", + "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" }, "risks": [ "R-AC-1", @@ -67354,25 +69202,9 @@ "R-SC-6" ], "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", "MT-1", "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", "MT-7", "MT-8", "MT-9", @@ -67381,18 +69213,18 @@ "MT-12", "MT-13", "MT-14", - "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "IAC-03.1", - "title": "Acceptance of PIV Credentials from Other Organizations", + "control_id": "IAC-02.3", + "title": "Acceptance of PIV Credentials", "family": "IAC", - "description": "Mechanisms exist to accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties.", - "scf_question": "Does the organization accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties?", + "description": "Mechanisms exist to accept and electronically verify organizational Personal Identity Verification (PIV) credentials.", + "scf_question": "Does the organization accept and electronically verify organizational Personal Identity Verification (PIV) credentials?", "relative_weight": 2, "conformity_cadence": "Annual", "evidence_requests": [], @@ -67405,10 +69237,10 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify organizational Personal Identity Verification (PIV) credentials. ", + "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], @@ -67489,17 +69321,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "IAC-03.2", - "title": "Acceptance of Third-Party Credentials", + "control_id": "IAC-02.4", + "title": "Out-of-Band Authentication (OOBA)", "family": "IAC", - "description": "Automated mechanisms exist to accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials.", - "scf_question": "Does the organization use automated mechanisms to accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials?", - "relative_weight": 2, - "conformity_cadence": "Quarterly", + "description": "Mechanisms exist to implement Out-of-Band Authentication (OOBA) under specific conditions.", + "scf_question": "Does the organization implement Out-of-Band Authentication (OOBA) under specific conditions?", + "relative_weight": 5, + "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Technology", "nist_csf_function": "Protect", @@ -67510,10 +69343,10 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Out-of-Band Authentication (OOBA) under specific conditions. ", + "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], @@ -67591,20 +69424,25 @@ "MT-12", "MT-13", "MT-14", + "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "IAC-03.3", - "title": "Use of FICAM-Issued Profiles", + "control_id": "IAC-03", + "title": "Identification & Authentication for Non-Organizational Users", "family": "IAC", - "description": "Mechanisms exist to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles.", - "scf_question": "Does the organization conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles?", - "relative_weight": 2, + "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization.", + "scf_question": "Does the organization uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization?", + "relative_weight": 9, "conformity_cadence": "Annual", - "evidence_requests": [], + "evidence_requests": [ + "E-IAM-05", + "E-IAM-06" + ], "pptdf": "Technology", "nist_csf_function": "Protect", "scrm_focus": { @@ -67614,19 +69452,24 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization.", + "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [], + "profiles": [ + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], "possible_solutions": { - "micro_small": "∙ Secure Baseline Configurations (SBC)", - "small": "∙ Secure Baseline Configurations (SBC)", - "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" + "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" }, "risks": [ "R-AC-1", @@ -67668,9 +69511,25 @@ "R-SC-6" ], "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", "MT-1", "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", "MT-7", "MT-8", "MT-9", @@ -67682,15 +69541,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "IAC-03.4", - "title": "Disassociability", + "control_id": "IAC-03.1", + "title": "Acceptance of PIV Credentials from Other Organizations", "family": "IAC", - "description": "Mechanisms exist to disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties.", - "scf_question": "Does the organization disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties?", + "description": "Mechanisms exist to accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties.", + "scf_question": "Does the organization accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties?", "relative_weight": 2, "conformity_cadence": "Annual", "evidence_requests": [], @@ -67703,9 +69563,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -67717,130 +69577,6 @@ "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" }, - "risks": [ - "R-AM-1", - "R-AM-3", - "R-BC-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-GV-1" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "IAC-03.5", - "title": "Acceptance of External Authenticators", - "family": "IAC", - "description": "Mechanisms exist to restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators.", - "scf_question": "Does the organization restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators?", - "relative_weight": 4, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-IAM-05", - "E-IAM-06" - ], - "pptdf": "Technology", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats" - ], - "possible_solutions": { - "micro_small": "∙ Secure Baseline Configurations (SBC)", - "small": "∙ Secure Baseline Configurations (SBC)", - "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", - "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" - }, - "risks": [ - "R-AM-3", - "R-GV-1" - ], - "threats": [ - "MT-8", - "MT-9", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "IAC-04", - "title": "Identification & Authentication for Devices", - "family": "IAC", - "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant.", - "scf_question": "Does the organization uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant?", - "relative_weight": 9, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-IAM-05", - "E-IAM-06" - ], - "pptdf": "Technology", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": true, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant.", - "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], - "possible_solutions": { - "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" - }, "risks": [ "R-AC-1", "R-AC-2", @@ -67911,7 +69647,435 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "IAC-03.2", + "title": "Acceptance of Third-Party Credentials", + "family": "IAC", + "description": "Automated mechanisms exist to accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials.", + "scf_question": "Does the organization use automated mechanisms to accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials?", + "relative_weight": 2, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials. ", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Secure Baseline Configurations (SBC)", + "small": "∙ Secure Baseline Configurations (SBC)", + "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "IAC-03.3", + "title": "Use of FICAM-Issued Profiles", + "family": "IAC", + "description": "Mechanisms exist to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles.", + "scf_question": "Does the organization conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles?", + "relative_weight": 2, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles. ", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Secure Baseline Configurations (SBC)", + "small": "∙ Secure Baseline Configurations (SBC)", + "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "IAC-03.4", + "title": "Disassociability", + "family": "IAC", + "description": "Mechanisms exist to disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties.", + "scf_question": "Does the organization disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties?", + "relative_weight": 2, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Secure Baseline Configurations (SBC)", + "small": "∙ Secure Baseline Configurations (SBC)", + "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" + }, + "risks": [ + "R-AM-1", + "R-AM-3", + "R-BC-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "IAC-03.5", + "title": "Acceptance of External Authenticators", + "family": "IAC", + "description": "Mechanisms exist to restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators.", + "scf_question": "Does the organization restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators?", + "relative_weight": 4, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-IAM-05", + "E-IAM-06" + ], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats" + ], + "possible_solutions": { + "micro_small": "∙ Secure Baseline Configurations (SBC)", + "small": "∙ Secure Baseline Configurations (SBC)", + "medium": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "large": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program", + "enterprise": "∙ Secure Baseline Configurations (SBC)\n∙ Identity & Access Management (IAM) program" + }, + "risks": [ + "R-AM-3", + "R-GV-1" + ], + "threats": [ + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "IAC-04", + "title": "Identification & Authentication for Devices", + "family": "IAC", + "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant.", + "scf_question": "Does the organization uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-IAM-05", + "E-IAM-06" + ], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant.", + "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", + "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { @@ -67932,11 +70096,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure device identification and authentication is accurate by centrally-managing the joining of systems to the domain as part of the initial asset configuration management process.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -68000,7 +70164,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -68021,7 +70186,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce cryptographic communications keys to prevent one key from being used to access multiple devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -68082,7 +70247,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -68106,7 +70272,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify and authenticate third-party Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -68195,7 +70361,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -68216,11 +70383,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure external service providers provide current and accurate information for any third-party user with access to the organization's data or assets.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -68300,7 +70467,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -68403,15 +70571,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IAC-06", "title": "Multi-Factor Authentication (MFA)", "family": "IAC", - "description": "Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:\n(1) Remote network access; \n(2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n(3) Non-console access to critical TAAS that store, transmit and/or process sensitive/regulated data.", - "scf_question": "Does the organization use automated mechanisms to enforce Multi-Factor Authentication (MFA) for:\n (1) Remote network access; \n (2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n (3) Non-console access to critical TAAS that store, transmit and/or process sensitive/regulated data?", + "description": "Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:\n(1) Remote network access; \n(2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n(3) Non-console access to critical TAAS that store, transmit and/or process sensitive and/or regulated data.", + "scf_question": "Does the organization use automated mechanisms to enforce Multi-Factor Authentication (MFA) for:\n (1) Remote network access; \n (2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n (3) Non-console access to critical TAAS that store, transmit and/or process sensitive and/or regulated data?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -68514,7 +70683,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -68537,7 +70707,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -68623,7 +70793,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -68646,7 +70817,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -68732,7 +70903,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -68753,9 +70925,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -68841,7 +71013,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -68849,7 +71022,7 @@ "title": "Out-of-Band Multi-Factor Authentication", "family": "IAC", "description": "Mechanisms exist to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed.", - "scf_question": "Does the organization implements Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is securely provided by a device separate from the system gaining access?", + "scf_question": "Does the organization implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -68862,9 +71035,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -68946,7 +71119,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69051,7 +71225,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69078,7 +71253,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize a formal user registration and de-registration process that governs the assignment of access rights.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize a formal user registration and de-registration process that governs the assignment of access rights. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -69167,7 +71342,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69193,7 +71369,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -69263,7 +71439,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69375,7 +71552,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69403,7 +71581,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Role-Based Access Control (RBAC) for TAASD to restrict access to individuals assigned specific roles with legitimate business needs.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -69474,7 +71652,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69568,7 +71747,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69591,7 +71771,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure proper user identification management for non-consumer users and administrators.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure proper user identification management for non-consumer users and administrators. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -69661,7 +71841,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69682,9 +71863,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify contractors and other third-party users through unique username characteristics.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify contractors and other third-party users through unique username characteristics. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -69754,7 +71935,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69775,9 +71957,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to dynamically manage usernames and system identifiers.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to dynamically manage usernames and system identifiers. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -69845,7 +72027,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69868,7 +72051,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to coordinate username identifiers with external organizations for cross-organization management of identifiers.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to coordinate username identifiers with external organizations for cross-organization management of identifiers. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -69934,7 +72117,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -69955,7 +72139,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely manage privileged accounts to identify the account as a privileged user or service.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -70027,7 +72211,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70085,7 +72270,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70110,7 +72296,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to:\n(1) Securely manage authenticators for users and devices; and\n(2) Ensure the strength of authentication is appropriate to the classification of the data being accessed.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -70181,7 +72367,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70274,7 +72461,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70295,7 +72483,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically validate certificates by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information for PKI-based authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -70378,7 +72566,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70486,7 +72675,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70509,9 +72699,9 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Password managers are not governed.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -70578,7 +72768,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70601,7 +72792,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Password managers are not governed.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -70670,7 +72861,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70693,7 +72885,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -70763,7 +72955,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70851,7 +73044,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70947,7 +73141,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -70968,7 +73163,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement security safeguards to manage the risk of compromise due to individuals having accounts on multiple Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71036,7 +73231,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71124,7 +73320,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71145,7 +73342,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ Password managers are provided, but decentralized and not actively governed.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect and store passwords via a password manager tool.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71218,7 +73415,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71323,7 +73521,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71429,7 +73628,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71518,7 +73718,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71541,7 +73742,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to obscure the feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to obscure the feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -71611,7 +73812,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71632,7 +73834,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure cryptographic modules adhere to applicable statutory, regulatory and contractual requirements for security strength.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71702,7 +73904,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71723,9 +73926,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Hardware Security Modules (HSM) to protect authenticators on which the component relies.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Hardware Security Modules (HSM) to protect authenticators on which the component relies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -71788,7 +73991,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71809,7 +74013,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to allow individuals to utilize alternative methods of authentication under specific circumstances or situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71881,7 +74085,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71889,7 +74094,7 @@ "title": "Single Sign-On (SSO) Transparent Authentication", "family": "IAC", "description": "Mechanisms exist to provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to the organization's Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization provide a Single Sign-On (SSO) capability to its Technology Assets, Applications and/or Services (TAAS)?", + "scf_question": "Does the organization provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to its Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -71902,7 +74107,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to the organization's Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71970,7 +74175,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -71991,7 +74197,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to federate credentials to allow cross-organization authentication of individuals and devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -72059,7 +74265,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -72149,7 +74356,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -72172,7 +74380,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72242,15 +74450,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IAC-15", "title": "Account Management", "family": "IAC", - "description": "Mechanisms exist to proactively govern account management of individual, group, system, service, application, guest and temporary accounts.", - "scf_question": "Does the organization proactively govern account management of individual, group, system, service, application, guest and temporary accounts?", + "description": "Mechanisms exist to:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts.", + "scf_question": "Does the organization:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -72266,9 +74475,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to proactively govern account management of individual, group, system, service, application, guest and temporary accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72281,11 +74490,11 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" + "micro_small": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "small": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "medium": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "large": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "enterprise": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM" }, "risks": [ "R-AC-1", @@ -72341,15 +74550,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed" }, { "control_id": "IAC-15.1", "title": "Automated System Account Management (Directory Services)", "family": "IAC", "description": "Automated mechanisms exist to support the management of system accounts (e.g., directory services).", - "scf_question": "Does the organization use automated mechanisms to support the management of system accounts?", + "scf_question": "Does the organization use automated mechanisms to support the management of system accounts (e.g., directory services)?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -72362,9 +74573,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically support the management of system accounts (e.g., directory services).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically support the management of system accounts (e.g., directory services). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72433,7 +74644,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -72454,9 +74666,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable or remove temporary and emergency accounts after an organization-defined time period for each type of account.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable or remove temporary and emergency accounts after an organization-defined time period for each type of account. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72523,7 +74735,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -72544,9 +74757,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable inactive accounts after an organization-defined time period.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable inactive accounts after an organization-defined time period. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72615,7 +74828,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -72638,9 +74852,9 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically audit account creation, modification, enabling, disabling and removal actions and notify organization-defined personnel or roles.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically audit account creation, modification, enabling, disabling and removal actions and notify organization-defined personnel or roles. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -72703,7 +74917,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -72730,7 +74945,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to authorize the use of shared/group accounts only under certain organization-defined conditions.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -72798,7 +75013,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -72819,7 +75035,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disable accounts immediately upon notification for users posing a significant risk to the organization.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -72891,7 +75107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -72899,7 +75116,7 @@ "title": "System Account Reviews", "family": "IAC", "description": "Mechanisms exist to review all system accounts and disable any account that cannot be associated with a business process and owner.", - "scf_question": "Does the organization review all system accounts and disables any account that cannot be associated with a business process and owner?", + "scf_question": "Does the organization review all system accounts and disable any account that cannot be associated with a business process and owner?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -72914,11 +75131,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.\n▪ IAM inventories all privileged accounts and validates that each person with elevated privileges is authorized by the appropriate level of organizational management.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to review all system accounts and disable any account that cannot be associated with a business process and owner.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to review all system accounts and disable any account that cannot be associated with a business process and owner. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -72987,7 +75204,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -73008,11 +75226,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically enforce usage conditions for users and/or roles.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -73093,7 +75311,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -73114,7 +75333,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to establish and control \"emergency access only\" accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73200,9 +75419,101 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "IAC-15.10", + "title": "Account Separation Between Infrastructure Environments", + "family": "IAC", + "description": "Mechanisms exist to separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "scf_question": "Does the organization separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Separate user accounts for production vs development environments\n∙ Role-based access restricting cross-environment access", + "small": "∙ Separate accounts per environment (dev, staging, prod)\n∙ Access restrictions preventing cross-environment access", + "medium": "∙ Separate cloud accounts or tenants per environment\n∙ AWS Organizations or Azure Management Groups for account separation\n∙ Privileged Access Management (PAM)", + "large": "∙ AWS Organizations, Azure Landing Zones, or GCP Organization policies for environment separation\n∙ PAM solution for privileged environment access\n∙ Zero Trust access between environments", + "enterprise": "∙ Enterprise cloud account separation via AWS Organizations or Azure Entra Tenants\n∙ Enterprise PAM (e.g., CyberArk, BeyondTrust)\n∙ Zero Trust architecture for cross-environment access\n∙ Automated account lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - (33 CFR Part 101 Subpart F)" + }, { "control_id": "IAC-16", "title": "Privileged Account Management (PAM)", @@ -73227,7 +75538,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).\n▪ LAC and RBAC enforcements limit the ability of non-administrators from making unauthorized configuration changes to TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict and control privileged access rights for users and Technology Assets, Applications and/or Services (TAAS).", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -73315,7 +75626,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -73338,11 +75650,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -73411,7 +75723,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -73501,7 +75814,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -73522,7 +75836,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure privilege change requests require additional levels of authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73589,7 +75903,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -73614,7 +75929,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to assign dedicated privileged user accounts to be used solely for duties requiring privileged access.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -73677,7 +75992,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -73698,7 +76014,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enable a manual override of the current account privileges to enable the timely response to unusual conditions without terminating the current session and establishing a new session as a higher-privileged user.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73728,9 +76044,9 @@ "MT-2", "MT-8", "MT-9", - "MT-14" - ], - "errata": "- new control (IEC 62443-4-2)" + "MT-14", + "MT-28" + ] }, { "control_id": "IAC-17", @@ -73829,7 +76145,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -73852,7 +76169,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -73921,7 +76238,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -74011,7 +76329,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -74019,7 +76338,7 @@ "title": "Access Enforcement", "family": "IAC", "description": "Mechanisms exist to enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"", - "scf_question": "Does the organization enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege?\"", + "scf_question": "Does the organization enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -74032,7 +76351,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74106,15 +76425,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IAC-20.1", "title": "Access To Sensitive / Regulated Data", "family": "IAC", - "description": "Mechanisms exist to limit access to sensitive/regulated data to only those individuals whose job requires such access.", - "scf_question": "Does the organization limit access to sensitive/regulated data to only those individuals whose job requires such access?", + "description": "Mechanisms exist to limit access to sensitive and/or regulated data to only those individuals whose job requires such access.", + "scf_question": "Does the organization limit access to sensitive and/or regulated data to only those individuals whose job requires such access?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -74127,11 +76447,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit access to sensitive/regulated data to only those individuals whose job requires such access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit access to sensitive/regulated data to only those individuals whose job requires such access. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -74215,15 +76535,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IAC-20.2", "title": "Database Access", "family": "IAC", - "description": "Mechanisms exist to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", - "scf_question": "Does the organization restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access?", + "description": "Mechanisms exist to restrict access to databases containing sensitive and/or regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", + "scf_question": "Does the organization restrict access to databases containing sensitive and/or regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -74236,11 +76557,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -74322,7 +76643,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -74343,7 +76665,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict and tightly control utility programs that are capable of overriding system and application controls.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -74413,7 +76735,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -74434,7 +76757,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict executing administrative tasks or tasks requiring elevated access to a dedicated machine.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -74520,7 +76843,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -74541,7 +76865,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically enforce dual authorization for privileged commands.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74626,7 +76950,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -74647,7 +76972,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM revokes user access rights in a timely manner, up on termination of employment or contract.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke logical and physical access authorizations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74720,7 +77045,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -74814,7 +77140,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -74839,9 +77166,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -74914,7 +77241,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75005,7 +77333,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75026,9 +77355,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prohibit privileged users from using privileged accounts, while performing non-security functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prohibit privileged users from using privileged accounts, while performing non-security functions. \n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75098,7 +77427,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75193,7 +77523,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75216,7 +77547,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM revokes user access rights following changes in personnel roles and duties, if no longer necessary or permitted.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to audit the execution of privileged functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to audit the execution of privileged functions. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75286,7 +77617,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75309,7 +77641,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75379,15 +77711,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IAC-21.6", "title": "Network Access to Privileged Commands", "family": "IAC", - "description": "Mechanisms exist to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs.", - "scf_question": "Does the organization authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs?", + "description": "Mechanisms exist to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive and/or regulated data is stored, transmitted and/or processed only for compelling operational needs.", + "scf_question": "Does the organization authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive and/or regulated data is stored, transmitted and/or processed only for compelling operational needs?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -75400,7 +77733,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -75468,7 +77801,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75491,7 +77825,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically prevent applications from executing at higher privilege levels than the user's privileges.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically prevent applications from executing at higher privilege levels than the user's privileges. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75556,7 +77890,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75649,7 +77984,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75672,7 +78008,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit the number of concurrent sessions for each system account.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit the number of concurrent sessions for each system account. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75740,7 +78076,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75833,7 +78170,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75856,7 +78194,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement pattern-hiding displays to conceal information previously visible on the display during the session lock.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement pattern-hiding displays to conceal information previously visible on the display during the session lock. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75926,7 +78264,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -75949,7 +78288,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76018,7 +78357,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76039,9 +78379,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a logout capability and display an explicit logout message to users indicating the reliable termination of the session.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a logout capability and display an explicit logout message to users indicating the reliable termination of the session. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76107,7 +78447,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76128,7 +78469,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify and document the supporting rationale for specific user actions that can be performed on a system without identification or authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76196,7 +78537,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76217,7 +78559,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement a reference monitor that is tamperproof, always-invoked, small enough to be subject to analysis / testing and the completeness of which can be assured.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76285,7 +78627,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76311,7 +78654,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to verify the identity of a user before issuing authenticators or modifying access permissions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76385,7 +78728,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76408,7 +78752,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure management approvals are required for new accounts or changes in permissions to existing accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76497,7 +78841,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76518,8 +78863,8 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM collects, validates and verifies identity evidence of a user.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require evidence of individual identification to be presented to the registration authority.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." @@ -76603,7 +78948,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76624,7 +78970,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that the presented identity evidence be validated and verified through organizational-defined methods of validation and verification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76709,7 +79055,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76730,7 +79077,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that the validation and verification of identity evidence be conducted in person before a designated registration authority.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76815,7 +79162,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76836,7 +79184,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that a notice of proofing be delivered through an out-of-band channel to verify the user's address (physical or digital).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76921,7 +79269,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76942,7 +79291,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Attribute-Based Access Control (ABAC) for policy-driven, dynamic authorizations that supports the secure sharing of information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76989,7 +79338,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -76997,7 +79347,7 @@ "title": "Real-Time Access Decisions", "family": "IAC", "description": "Automated mechanisms exist to utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources.", - "scf_question": "Does the organization utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources?", + "scf_question": "Does the organization use automated mechanisms to utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources?", "relative_weight": 3, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -77010,7 +79360,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77055,15 +79405,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IAC-29.2", "title": "Access Profile Rules", "family": "IAC", - "description": "Mechanisms exist to develop access profile rules for sensitive/regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes.", - "scf_question": "Does the organization develop access profile rules for sensitive/regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes?", + "description": "Mechanisms exist to develop access profile rules for sensitive and/or regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes.", + "scf_question": "Does the organization develop access profile rules for sensitive and/or regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -77123,7 +79474,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77144,7 +79496,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Mutual Authentication (MA) where both sides of a communications channel verify the identity of the other party through certificate exchange.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77170,9 +79522,9 @@ "MT-2", "MT-8", "MT-9", - "MT-14" - ], - "errata": "- new control (IEC 62443-2-1)" + "MT-14", + "MT-28" + ] }, { "control_id": "IRO-01", @@ -77293,7 +79645,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77316,7 +79669,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.\n▪ IT and/or cybersecurity personnel operate facilitate basic forensic investigations in the event of a suspected or confirmed security incident.\n▪ The IRP contains eDiscovery processes to support Federal Rules of Civil Procedure (FRCP) requirements for eDiscovery practices.\n▪ IT personnel support incident response operations by provisioning and deprovisioning incident responders with temporary emergency accounts.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to cover:\n(1) Preparation;\n(2) Automated event detection or manual incident report intake;\n(3) Analysis;\n(4) Containment;\n(5) Eradication; and\n(6) Recovery.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -77407,7 +79760,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77428,9 +79782,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically support the incident handling process.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically support the incident handling process. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77511,7 +79865,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77532,9 +79887,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to implement and govern an insider threat program.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to implement and govern an insider threat program. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77614,7 +79969,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77637,7 +79993,7 @@ "0": "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.", "1": "Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically dynamically reconfigure system components as part of the incident response capability.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically dynamically reconfigure system components as part of the incident response capability. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77677,7 +80033,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77700,7 +80057,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77786,7 +80143,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77809,9 +80167,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate with approved third-parties to achieve a cross-organization perspective on incident awareness and more effective incident responses.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate with approved third-parties to achieve a cross-organization perspective on incident awareness and more effective incident responses. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77895,7 +80253,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77959,7 +80318,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -77982,7 +80342,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to define specific Indicators of Compromise (IOC) to identify the signs of potential cybersecurity events.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -78047,7 +80407,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78070,7 +80431,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain and make available a current and viable Incident Response Plan (IRP) to all stakeholders.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -78161,7 +80522,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78182,9 +80544,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address data breaches, or other incidents involving the unauthorized disclosure of sensitive or regulated data, according to applicable laws, regulations and contractual obligations.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address data breaches, or other incidents involving the unauthorized disclosure of sensitive or regulated data, according to applicable laws, regulations and contractual obligations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78250,7 +80612,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78273,7 +80636,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ On at least an annual basis, IT and/or cybersecurity personnel update incident response strategies to keep current with business needs, technology changes and regulatory requirements.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to regularly review and modify incident response practices to incorporate lessons learned, business process changes and industry developments, as necessary.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -78346,7 +80709,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78354,7 +80718,7 @@ "title": "Continuous Incident Response Improvements", "family": "IRO", "description": "Mechanisms exist to use qualitative and quantitative data from incident response testing to: \n(1) Determine the effectiveness of incident response processes;\n(2) Continuously improve incident response processes; and\n(3) Provide incident response measures and metrics that are accurate, consistent and in a reproducible format.", - "scf_question": "Does the organization use qualitative and quantitative data from incident response testing to: \n (1) Determine the effectiveness of incident response processes;\n (2) Continuously improve incident response processes; and\n (3) Provide incident response measures and metrics that are accurate, consistent, and in a reproducible format?", + "scf_question": "Does the organization use qualitative and quantitative data from incident response testing to: \n(1) Determine the effectiveness of incident response processes;\n(2) Continuously improve incident response processes; and\n(3) Provide incident response measures and metrics that are accurate, consistent and in a reproducible format?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -78438,7 +80802,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78462,7 +80827,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders are proficient on their specific IRP role(s) and responsibilities through recurring training events (e.g., annual rock drill).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to train personnel in their incident response roles and responsibilities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -78534,7 +80899,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78555,7 +80921,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate simulated events into incident response training to facilitate effective response by personnel in crisis situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -78627,7 +80993,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78715,7 +81082,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78738,7 +81106,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders are proficient on their specific IRP role(s) and responsibilities through recurring training events (e.g., annual rock drill).\n▪ On at least an annual basis, IT and/or cybersecurity personnel conduct tabletop exercises to validate disaster recovery and contingency plans, in conjunction with stakeholders and any required vendors.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to formally test incident response capabilities through realistic exercises to determine the operational effectiveness of those capabilities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -78810,7 +81178,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78833,9 +81202,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ On at least an annual basis, IT and/or cybersecurity personnel conduct tabletop exercises to validate disaster recovery and contingency plans, in conjunction with stakeholders and any required vendors.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate incident response testing with organizational elements responsible for related plans.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate incident response testing with organizational elements responsible for related plans. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78921,7 +81290,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -78945,7 +81315,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to establish an integrated team of cybersecurity, IT and business function representatives that are capable of addressing cybersecurity and data protection incident response operations.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -79034,7 +81404,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -79058,7 +81429,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to perform digital forensics and maintain the integrity of the chain of custody, in accordance with applicable laws, regulations and industry-recognized secure practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79149,7 +81520,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -79207,9 +81579,9 @@ "MT-6", "MT-8", "MT-9", - "MT-11" - ], - "errata": "- new control (SCF)" + "MT-11", + "MT-28" + ] }, { "control_id": "IRO-09", @@ -79231,7 +81603,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to document, monitor and report the status of cybersecurity and data protection incidents to internal stakeholders all the way through the resolution of the incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79321,7 +81693,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -79342,11 +81715,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically assist in the tracking, collection and analysis of information from actual and potential cybersecurity and data protection incidents.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -79426,7 +81799,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -79532,7 +81906,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -79553,7 +81928,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain a repository of cybersecurity events and incidents that documents:\n(1) Details of the incident (e.g., category, severity, affected parties, etc.);\n(2) Remediation actions taken through incident closure; and\n(3) A summary from the Root Cause Analysis (RCA), if applicable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79587,9 +81962,9 @@ "MT-5", "MT-6", "MT-8", - "MT-9" - ], - "errata": "- new control (C2M2)" + "MT-9", + "MT-28" + ] }, { "control_id": "IRO-09.4", @@ -79609,7 +81984,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to analyze historical incidents in aggregate to identify:\n(1) Patterns;\n(2) Trends; and \n(3) Other common root causes in order to address the vulnerability and risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79641,9 +82016,9 @@ "MT-5", "MT-6", "MT-8", - "MT-9" - ], - "errata": "- new control (C2M2)" + "MT-9", + "MT-28" + ] }, { "control_id": "IRO-10", @@ -79667,7 +82042,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to timely-report incidents to applicable:\n(1) Internal stakeholders; \n(2) Affected clients & third-parties; and\n(3) Regulatory authorities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -79747,7 +82122,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -79768,7 +82144,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically assist in the reporting of cybersecurity and data protection incidents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79841,15 +82217,16 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IRO-10.2", "title": "Cyber Incident Reporting for Sensitive / Regulated Data", "family": "IRO", - "description": "Mechanisms exist to report sensitive/regulated data incidents in a timely manner.", - "scf_question": "Does the organization report sensitive/regulated data incidents in a timely manner?", + "description": "Mechanisms exist to report sensitive and/or regulated data incidents in a timely manner.", + "scf_question": "Does the organization report sensitive and/or regulated data incidents in a timely manner?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -79943,7 +82320,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -79964,7 +82342,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to report system vulnerabilities associated with reported cybersecurity and data protection incidents to organization-defined personnel or roles.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80047,7 +82425,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -80070,7 +82449,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide cybersecurity and data protection incident information to the provider of the Technology Assets, Applications and/or Services (TAAS) and other organizations involved in the supply chain for TAAS related to the incident.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80159,7 +82538,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -80167,7 +82547,7 @@ "title": "Serious Incident Reporting", "family": "IRO", "description": "Mechanisms exist to report any serious incident involving the organization's Technology Assets, Applications, Services and/or Data (TAASD) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines.", - "scf_question": "Does the organization report any serious incident involving the organization's Technology Assets, Applications and/or Services (TAAS) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines?", + "scf_question": "Does the organization report any serious incident involving its Technology Assets, Applications, Services and/or Data (TAASD) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -80180,7 +82560,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to report any serious incident involving the organization's TAASD to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80265,7 +82645,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -80286,9 +82667,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide incident response advice and assistance to users of Technology Assets, Applications and/or Services (TAAS) for the handling and reporting of actual and potential cybersecurity and data protection incidents.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide incident response advice and assistance to users of Technology Assets, Applications and/or Services (TAAS) for the handling and reporting of actual and potential cybersecurity and data protection incidents. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80372,7 +82753,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -80395,7 +82777,7 @@ "0": "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.", "1": "Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically increase the availability of incident response-related information and support.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically increase the availability of incident response-related information and support. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80461,7 +82843,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -80482,7 +82865,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to establish a direct, cooperative relationship between the organization's incident response capability and external service providers.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80566,15 +82949,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IRO-12", "title": "Sensitive / Regulated Data Spill Response", "family": "IRO", - "description": "Mechanisms exist to respond to sensitive/regulated data spills.", - "scf_question": "Does the organization respond to sensitive/regulated data spills?", + "description": "Mechanisms exist to respond to sensitive and/or regulated data spills.", + "scf_question": "Does the organization respond to sensitive and/or regulated data spills?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -80589,7 +82973,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to respond to sensitive/regulated data spills.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80676,15 +83060,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IRO-12.1", "title": "Sensitive / Regulated Data Spill Responsible Personnel", "family": "IRO", - "description": "Mechanisms exist to formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills.", - "scf_question": "Does the organization formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills?", + "description": "Mechanisms exist to formally assign personnel or roles with responsibility for responding to sensitive and/or regulated data spills.", + "scf_question": "Does the organization formally assign personnel or roles with responsibility for responding to sensitive and/or regulated data spills?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -80697,7 +83082,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80781,15 +83166,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IRO-12.2", "title": "Sensitive / Regulated Data Spill Training", "family": "IRO", - "description": "Mechanisms exist to ensure incident response training material provides coverage for sensitive/regulated data spillage response.", - "scf_question": "Does the organization ensure incident response training material provides coverage for sensitive/regulated data spillage response?", + "description": "Mechanisms exist to ensure incident response training material provides coverage for sensitive and/or regulated data spillage response.", + "scf_question": "Does the organization ensure incident response training material provides coverage for sensitive and/or regulated data spillage response?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -80802,7 +83188,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to ensure incident response training material provides coverage for sensitive/regulated data spillage response.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80870,15 +83256,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IRO-12.3", "title": "Post-Sensitive / Regulated Data Spill Operations", "family": "IRO", - "description": "Mechanisms exist to ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", - "scf_question": "Does the organization ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions?", + "description": "Mechanisms exist to ensure that organizational personnel impacted by sensitive and/or regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", + "scf_question": "Does the organization ensure that organizational personnel impacted by sensitive and/or regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -80891,7 +83278,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80975,15 +83362,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IRO-12.4", "title": "Sensitive / Regulated Data Exposure to Unauthorized Personnel", "family": "IRO", - "description": "Mechanisms exist to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations.", - "scf_question": "Does the organization address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations?", + "description": "Mechanisms exist to address security safeguards for personnel exposed to sensitive and/or regulated data that is not within their assigned access authorizations.", + "scf_question": "Does the organization address security safeguards for personnel exposed to sensitive and/or regulated data that is not within their assigned access authorizations?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -80996,9 +83384,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81081,7 +83469,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -81104,9 +83493,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders provide After Action Review (AAR) feedback on what worked, what did not work and ways to improve future responses to similar incidents.\n▪ A formal Root Cause Analysis (RCA) is performed that documents the findings in a report for both technical and business leadership management.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81194,7 +83583,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -81215,9 +83605,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain incident response contacts with applicable regulatory and law enforcement agencies.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain incident response contacts with applicable regulatory and law enforcement agencies. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81286,7 +83676,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -81307,7 +83698,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to utilize a detonation chamber capability to detect and/or block potentially-malicious files and email attachments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -81395,7 +83786,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -81492,7 +83884,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -81517,7 +83910,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel coordinate IAP activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience assessment and authorization controls.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience assessment and authorization controls. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81613,9 +84006,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "IAO-01.1", @@ -81724,7 +84117,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -81839,9 +84233,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "IAO-02.1", @@ -81863,7 +84257,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81946,16 +84340,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "IAO-02.2", "title": "Specialized Assessments", "family": "IAO", - "description": "Mechanisms exist to conduct specialized assessments for: \n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities; \n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management; \n(8) Malicious code; \n(9) Insider threats;\n(10) Performance/load testing; and/or\n(11) Artificial Intelligence and Autonomous Technologies (AAT).", - "scf_question": "Does the organization conduct specialized assessments for: \n (1) Statutory, regulatory and contractual compliance obligations;\n (2) Monitoring capabilities; \n (3) Mobile devices;\n (4) Databases;\n (5) Application security;\n (6) Embedded technologies (e.g., IoT, OT, etc.);\n (7) Vulnerability management; \n (8) Malicious code; \n (9) Insider threats;\n (10) Performance/load testing; and/or\n (11) Artificial Intelligence and Autonomous Technologies (AAT) testing?", + "description": "Mechanisms exist to conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.", + "scf_question": "Does the organization conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -81970,7 +84364,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct specialized assessments for: \n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities; \n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management; \n(8) Malicious code; \n(9) Insider threats;\n(10) Performance/load testing; and/or\n(11) Artificial Intelligence and Autonomous Technologies (AAT).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82054,8 +84448,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control" }, { "control_id": "IAO-02.3", @@ -82075,9 +84471,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to accept and respond to the results of external assessments that are performed by impartial, external organizations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to accept and respond to the results of external assessments that are performed by impartial, external organizations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82160,9 +84556,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed" + "MT-27", + "MT-28" + ] }, { "control_id": "IAO-02.4", @@ -82186,7 +84582,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82274,7 +84670,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -82297,7 +84694,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ 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).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate authoritative documentation (e.g., System Security Plan (SSP)) that:\n(1) Identifies key architectural and implementation information on in-scope Technology Assets, Applications and/or Services (TAAS);\n(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\n(3) Provides a historical record of applied security controls, including changes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -82370,9 +84767,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "IAO-03.1", @@ -82392,9 +84789,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to plan and coordinate Information Assurance Program (IAP) activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to plan and coordinate Information Assurance Program (IAP) activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82478,15 +84875,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "IAO-03.2", "title": "Adequate Security for Sensitive / Regulated Data In Support of Contracts", "family": "IAO", - "description": "Mechanisms exist to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", - "scf_question": "Does the organization protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract?", + "description": "Mechanisms exist to protect sensitive and/or regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", + "scf_question": "Does the organization protect sensitive and/or regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -82501,9 +84899,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82587,7 +84985,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -82595,7 +84994,7 @@ "title": "Threat Analysis & Flaw Remediation During Development", "family": "IAO", "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.", - "scf_question": "Does the organization require system developers and integrators to create and execute a Security Testing and Evaluation (ST&E) plan to identify and remediate flaws during development?", + "scf_question": "Does the organization 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?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -82608,7 +85007,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -82693,7 +85092,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -82716,7 +85116,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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:\n(1) Deficiency tracking number;\n(2) Applicable security, compliance and/or resilience control;\n(3) Description of the deficiency(ies);\n(4) Risk associated with the deficiency(ies);\n(5) Source deficiency identification/detection;\n(6) Temporary compensating controls, if applicable;\n(7) Point of Contact (POC) (e.g., asset/process owner);\n(8) Resources required to conduct remediation actions;\n(9) Planned remedial actions to the deficiency(ies);\n(10) Proposed remediation timeline; and\n(11) Disposition statement (e.g., closeout summary).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -82788,9 +85188,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "IAO-05.1", @@ -82855,9 +85255,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "IAO-06", @@ -82877,7 +85277,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -82966,9 +85366,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "IAO-07", @@ -83076,7 +85476,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83198,7 +85599,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83206,7 +85608,7 @@ "title": "Controlled Maintenance", "family": "MNT", "description": "Mechanisms exist to conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).", - "scf_question": "Does the organization conduct controlled maintenance activities throughout the lifecycle of theTechnology Asset, Application and/or Service (TAAS)?", + "scf_question": "Does the organization conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -83221,7 +85623,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset custodians track maintenance activities and component failure rates.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -83312,7 +85714,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83417,7 +85820,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83440,7 +85844,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to obtain maintenance support and/or spare parts for Technology Assets, Applications and/or Services (TAAS) within a defined Recovery Time Objective (RTO).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -83529,7 +85933,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83552,11 +85957,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset custodians track maintenance activities and component failure rates.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to perform preventive maintenance on critical Technology Assets, Applications and/or Services (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -83640,7 +86045,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83661,11 +86067,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to perform predictive maintenance on critical Technology Assets, Applications and/or Services (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -83735,7 +86141,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83756,7 +86163,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to automatically transfer predictive maintenance data to a computerized maintenance management system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83829,7 +86236,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83850,9 +86258,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to control and monitor the use of system maintenance tools.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to control and monitor the use of system maintenance tools. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83936,7 +86344,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -83957,9 +86366,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.\n▪ IT and/or cybersecurity personnel inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84042,7 +86451,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84065,9 +86475,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.\n▪ IT and/or cybersecurity personnel inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to check media containing diagnostic and test programs for malicious code before the media are used.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to check media containing diagnostic and test programs for malicious code before the media are used. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84147,7 +86557,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84168,7 +86579,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners prevent or control the removal of equipment undergoing maintenance that contains organizational information.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to prevent or control the removal of equipment undergoing maintenance that contains organizational information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84247,7 +86658,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84272,7 +86684,7 @@ "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to automatically restrict the use of maintenance tools to authorized maintenance personnel and/or roles.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -84348,7 +86760,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84369,11 +86782,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Instances of non-console administrative access use cryptographic mechanisms to protect the confidentiality and integrity of the data being transmitted.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to authorize, monitor and control remote, non-local maintenance and diagnostic activities.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -84457,7 +86870,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84478,9 +86892,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to audit remote, non-local maintenance and diagnostic sessions, as well as review the maintenance action performed during remote maintenance sessions.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to audit remote, non-local maintenance and diagnostic sessions, as well as review the maintenance action performed during remote maintenance sessions. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84550,7 +86964,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84571,7 +86986,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners require maintenance personnel to notify entity-defined personnel when non-local maintenance is planned (e.g., date/time).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require maintenance personnel to notify affected stakeholders when remote, non-local maintenance is planned (e.g., date/time).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84642,7 +87057,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84663,9 +87079,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity and confidentiality of remote, non-local maintenance and diagnostic communications.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity and confidentiality of remote, non-local maintenance and diagnostic communications. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84720,7 +87136,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84741,7 +87158,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel provide remote disconnect verification to ensure non-local maintenance and diagnostic sessions are properly terminated.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to provide remote disconnect verification to ensure remote, non-local maintenance and diagnostic sessions are properly terminated.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -84809,7 +87226,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84830,7 +87248,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require maintenance personnel to obtain pre-approval and scheduling for remote, non-local maintenance sessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84899,7 +87317,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -84920,7 +87339,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require Technology Assets, Applications and/or Services (TAAS) performing remote, non-local maintenance and/or diagnostic services implement a security capability comparable to the capability implemented on the system being serviced.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84987,7 +87406,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85073,7 +87493,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85094,7 +87515,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT personnel, in conjunction with asset custodians, maintain a current list of authorized maintenance organizations or personnel.\n▪ Asset / process owners require maintenance personnel to obtain pre-approval and scheduling for non-local maintenance sessions.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to maintain a current list of authorized maintenance organizations or personnel.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -85183,7 +87604,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85294,7 +87716,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85315,7 +87738,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners require maintenance personnel to obtain pre-approval and scheduling for non-local maintenance sessions.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to ensure that non-escorted personnel performing non-IT maintenance activities in the physical proximity of systems have required access authorizations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85388,7 +87811,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85409,7 +87833,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to maintain proper physical security and configuration control over technology assets awaiting service or repair.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85495,7 +87919,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85516,7 +87941,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to securely conduct field maintenance on geographically deployed assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85598,7 +88023,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85619,7 +88045,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to ensure off-site maintenance activities are conducted securely and the asset(s) undergoing maintenance actions are secured during physical transfer and storage while off-site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85705,7 +88131,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85726,7 +88153,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to validate:\n(1) Maintenance activities were appropriately performed according to the work order; and \n(2) Applicable security, compliance and resilience controls are operational.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85809,9 +88236,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "MNT-11", @@ -85896,7 +88323,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -85917,7 +88345,7 @@ }, "maturity": { "0": "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.", - "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage.", + "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to implement and govern Mobile Device Management (MDM) controls.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86012,7 +88440,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86033,9 +88462,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict the connection of personally-owned, mobile devices to organizational TAASD.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce access control requirements for the connection of mobile devices to organizational Technology Assets, Applications and/or Services (TAAS).", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce access control requirements for the connection of mobile devices to organizational Technology Assets, Applications and/or Services (TAAS). ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86120,7 +88549,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86141,7 +88571,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of information on mobile devices through full-device or container encryption.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86194,7 +88624,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86215,7 +88646,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel protect mobile devices from tampering through inspecting devices returning from locations that the organization deems to be of significant risk, prior to the device being connected to the organization's network.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to protect mobile devices from tampering through inspecting devices returning from locations that the organization deems to be of significant risk, prior to the device being connected to the organization's network.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86286,7 +88717,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86307,11 +88739,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ MDM software can remotely purge selected information from mobile devices.", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to remotely purge selected information from mobile devices.", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to remotely purge selected information from mobile devices. ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -86376,7 +88808,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86397,9 +88830,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict the connection of personally-owned, mobile devices to organizational TAASD.\n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connection of personally-owned, mobile devices to organizational Technology Assets, Applications and/or Services (TAAS).", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connection of personally-owned, mobile devices to organizational Technology Assets, Applications and/or Services (TAAS). ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86486,7 +88919,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86507,7 +88941,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).\n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to prohibit the installation of non-approved applications or approved applications not obtained through the organization-approved application store.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86596,7 +89030,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86617,7 +89052,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to limit data retention on mobile devices to the smallest usable dataset and timeframe.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86658,7 +89093,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86679,7 +89115,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the functionality of mobile devices based on geographic location.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86723,7 +89159,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86744,9 +89181,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce a separate device workspace on applicable mobile devices to separate work-related and personal-related applications and data.", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce a separate device workspace on applicable mobile devices to separate work-related and personal-related applications and data. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86812,7 +89249,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -86835,7 +89273,7 @@ }, "maturity": { "0": "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.", - "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. \n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).\n▪ MDM software is used to prevent the unauthorized disclosure of sensitive/regulated data (e.g., cryptographic containerization).", + "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. \n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).\n▪ MDM software is used to prevent the unauthorized disclosure of sensitive/regulated data (e.g., cryptographic containerization). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connectivity of unauthorized mobile devices from communicating with organizational Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86902,7 +89340,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87024,7 +89463,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87047,7 +89487,7 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to treat all users and devices as potential threats and prevent access to data and resources until the users can be properly authenticated and their access authorized.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87113,7 +89553,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87138,9 +89579,9 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity architects maintain a segmented development network to ensure a secure development environment.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security functions as a layered structure that minimizes interactions between layers of the design and avoids any dependence by lower layers on the functionality or correctness of higher layers.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security functions as a layered structure that minimizes interactions between layers of the design and avoids any dependence by lower layers on the functionality or correctness of higher layers. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87218,7 +89659,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87239,9 +89681,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Boundary protection technologies minimize the effect of Denial of Service (DoS) attacks against business-critical services.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically protect against or limit the effects of denial of service attacks.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically protect against or limit the effects of denial of service attacks. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87280,7 +89722,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87301,9 +89744,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel implement and manage a secure guest network.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and manage a secure guest network.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and manage a secure guest network. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87387,7 +89830,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87493,7 +89937,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87517,7 +89962,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network activity monitoring and control communications at the external network boundary and at key internal boundaries within the network.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor and control communications at the external network boundary and at key internal boundaries within the network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87609,7 +90054,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87632,7 +90078,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to limit the number of concurrent external network connections to its Technology Assets, Applications and/or Services (TAAS).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to limit the number of concurrent external network connections to its Technology Assets, Applications and/or Services (TAAS). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87717,7 +90163,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87808,7 +90255,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87829,9 +90277,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent the public disclosure of internal network information.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent the public disclosure of internal network information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87869,7 +90317,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -87890,7 +90339,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to apply network-based processing rules to data elements of Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87938,15 +90387,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "NET-03.5", "title": "Prevent Unauthorized Exfiltration", "family": "NET", - "description": "Automated mechanisms exist to prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces.", - "scf_question": "Does the organization use automated mechanisms to prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces?", + "description": "Automated mechanisms exist to prevent the unauthorized exfiltration of sensitive and/or regulated data across managed interfaces.", + "scf_question": "Does the organization use automated mechanisms to prevent the unauthorized exfiltration of sensitive and/or regulated data across managed interfaces?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -87959,9 +90409,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88009,7 +90459,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88030,9 +90481,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically dynamically isolate (e.g., sandbox) untrusted components during runtime, where the component is isolated in a fault-contained environment but it can still collaborate with the application.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically dynamically isolate (e.g., sandbox) untrusted components during runtime, where the component is isolated in a fault-contained environment but it can still collaborate with the application. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88077,7 +90528,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88098,9 +90550,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ boundary protections to isolate Technology Assets, Applications and/or Services (TAAS) that support critical missions and/or business functions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ boundary protections to isolate Technology Assets, Applications and/or Services (TAAS) that support critical missions and/or business functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88169,7 +90621,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88262,7 +90715,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88289,11 +90743,11 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and govern Access Control Lists (ACLs) to provide data flow enforcement that explicitly restrict network traffic to only what is authorized.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -88365,7 +90819,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88391,11 +90846,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure firewall and router configurations to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure firewall and router configurations to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -88465,7 +90920,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88488,7 +90944,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to associate security attributes with information, source and destination objects to enforce defined information flow control configurations as a basis for flow control decisions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to associate security attributes with information, source and destination objects to enforce defined information flow control configurations as a basis for flow control decisions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88533,7 +90989,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88554,9 +91011,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent encrypted data from bypassing content-checking mechanisms.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent encrypted data from bypassing content-checking mechanisms. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88601,7 +91058,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88622,9 +91080,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce limitations on embedding data within other data types.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce limitations on embedding data within other data types. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88669,7 +91127,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88692,7 +91151,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce information flow controls based on metadata.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce information flow controls based on metadata. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88737,7 +91196,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88760,9 +91220,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88842,7 +91302,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88850,7 +91311,7 @@ "title": "Policy Decision Point (PDP)", "family": "NET", "description": "Automated mechanisms exist to evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions.", - "scf_question": "Does the organization evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions?", + "scf_question": "Does the organization use automated mechanisms to evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -88863,7 +91324,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88913,7 +91374,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -88934,7 +91396,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically utilize data type identifiers to validate data essential for information flow decisions when transferring information between different security domains.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88980,7 +91442,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89001,7 +91464,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms, when transferring information between different security domains.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89045,7 +91508,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89066,7 +91530,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically implement security policy filters requiring fully enumerated formats that restrict data structure and content, when transferring information between different security domains.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -89118,7 +91582,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89139,11 +91604,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically examine information for the presence of unsanctioned information and prohibits the transfer of such information, when transferring information between different security domains.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -89192,7 +91657,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89213,7 +91679,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically uniquely identify and authenticate source and destination points for information transfer.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89250,7 +91716,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89271,7 +91738,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically apply cybersecurity and/or data protection filters on metadata.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89308,7 +91775,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89316,7 +91784,7 @@ "title": "Application Proxy", "family": "NET", "description": "Mechanisms exist to terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network.", - "scf_question": "Does the organization maintain visibility and control over application traffic, regardless of the user’s location or the security posture of the surrounding network?", + "scf_question": "Does the organization terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -89329,7 +91797,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89380,7 +91848,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89481,9 +91950,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "NET-05.1", @@ -89508,7 +91977,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the direct connection of a sensitive system to an external network without the use of an organization-defined boundary protection device.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the direct connection of a sensitive system to an external network without the use of an organization-defined boundary protection device. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89583,7 +92052,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89682,15 +92152,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "NET-06", - "title": "Network Segmentation (macrosegementation)", + "title": "Network Segmentation (macrosegmentation)", "family": "NET", - "description": "Mechanisms exist to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.", - "scf_question": "Does the organization ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources?", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "scf_question": "Does the organization implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -89703,9 +92174,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network segmentation exists to implement separate network addresses (e.g., different subnets) to connect TAASD in different security domains (e.g., sensitive/regulated data environments).\n▪ IT and/or cybersecurity architects maintain a segmented development network to ensure a secure development environment.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.\nMechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89792,8 +92263,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- renamed control (typo)\n- wordsmithed control" }, { "control_id": "NET-06.1", @@ -89815,7 +92288,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Processing and storage of service location, including a managed security zone to house cybersecurity and data protection tools.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security management subnets to isolate security tools and support components from other internal system components by implementing separate subnetworks with managed interfaces to other components of the system.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security management subnets to isolate security tools and support components from other internal system components by implementing separate subnetworks with managed interfaces to other components of the system. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89898,7 +92371,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -89919,9 +92393,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89990,15 +92464,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "NET-06.3", "title": "Sensitive / Regulated Data Enclave (Secure Zone)", "family": "NET", - "description": "Mechanisms exist to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones).", - "scf_question": "Does the organization implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones)?", + "description": "Mechanisms exist to implement segmentation controls to restrict inbound and outbound connectivity for sensitive and/or regulated data enclaves (secure zones).", + "scf_question": "Does the organization implement segmentation controls to restrict inbound and outbound connectivity for sensitive and/or regulated data enclaves (secure zones)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -90011,9 +92486,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -90023,7 +92498,7 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "medium": "∙ Dedicated network segment for sensitive/regulated data systems", + "medium": "∙ Dedicated network segment for sensitive and/or regulated data systems", "large": "∙ Secure enclave/zone for sensitive data\n∙ Enhanced controls within the zone", "enterprise": "∙ Enterprise secure data enclave with enhanced controls\n∙ Data loss prevention at enclave boundary\n∙ Microsegmentation" }, @@ -90076,15 +92551,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "NET-06.4", "title": "Segregation From Enterprise Services", "family": "NET", - "description": "Mechanisms exist to isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", - "scf_question": "Does the organization isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments?", + "description": "Mechanisms exist to isolate sensitive and/or regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", + "scf_question": "Does the organization isolate sensitive and/or regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments?", "relative_weight": 4, "conformity_cadence": "Annual", "evidence_requests": [], @@ -90097,7 +92573,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90160,15 +92636,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "NET-06.5", "title": "Direct Internet Access Restrictions", "family": "NET", - "description": "Mechanisms exist to prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones).", - "scf_question": "Does the organization prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones)?", + "description": "Mechanisms exist to prohibit, or strictly-control, Internet access from sensitive and/or regulated data enclaves (secure zones).", + "scf_question": "Does the organization prohibit, or strictly-control, Internet access from sensitive and/or regulated data enclaves (secure zones)?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -90181,7 +92658,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90244,7 +92721,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -90265,7 +92743,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90333,7 +92811,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -90341,7 +92820,7 @@ "title": "Software Defined Networking (SDN)", "family": "NET", "description": "Automated mechanisms exist to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", - "scf_question": "Does the organization enable dynamic, policy-driven network segmentation, access controls and traffic management?", + "scf_question": "Does the organization use automated mechanisms to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -90358,7 +92837,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -90436,93 +92915,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "NET-07", - "title": "Network Connection Termination", + "control_id": "NET-06.8", + "title": "Network Device Plane Segmentation", "family": "NET", - "description": "Mechanisms exist to terminate network connections at the end of a session or after an organization-defined time period of inactivity.", - "scf_question": "Does the organization terminate network connections at the end of a session or after an organization-defined time period of inactivity?", - "relative_weight": 8, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Technology", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": false, - "operational": false, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", - "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network connection terminations at the end of a session or after an entity-defined time period of inactivity.\n▪ SBC terminate remote sessions at the end of the session or after an entity-defined time period of inactivity.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate network connections at the end of a session or after an organization-defined time period of inactivity.", - "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." - }, - "profiles": [ - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], - "possible_solutions": { - "micro_small": "∙ Configure session timeouts on systems and applications", - "small": "∙ Session timeout policy\n∙ Configure timeouts on all key systems", - "medium": "∙ Formal network session termination policy\n∙ Automated session timeout enforcement", - "large": "∙ Enterprise session management controls\n∙ Automated disconnect for idle sessions\n∙ Network access control enforcement", - "enterprise": "∙ Enterprise session management platform\n∙ Automated session termination via NAC/IAM\n∙ Zero-trust continuous session validation" - }, - "risks": [ - "R-AM-2", - "R-AM-3", - "R-BC-1", - "R-BC-2", - "R-BC-4", - "R-BC-5", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-IR-1", - "R-IR-2", - "R-IR-4", - "R-SA-1" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "NET-08", - "title": "Network Intrusion Detection / Prevention Systems (NIDS / NIPS)", - "family": "NET", - "description": "Mechanisms exist to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network.", - "scf_question": "Does the organization employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network?", - "relative_weight": 9, + "description": "Automated mechanisms exist to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations.", + "scf_question": "Does the organization use automated mechanisms to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Technology", @@ -90534,25 +92937,25 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network.", - "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Automated mechanisms exist to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "Community Derived" ], "possible_solutions": { - "micro_small": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)", - "small": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)", - "medium": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)", - "large": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)", - "enterprise": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)" + "micro_small": "∙ Management VLAN for network device administration\n∙ Out-of-band management interface for network devices", + "small": "∙ Management VLAN for network device administration\n∙ Restrict management access to jump server", + "medium": "∙ Dedicated out-of-band management network\n∙ Separate control plane and data plane configuration\n∙ Management VLAN with strict ACLs", + "large": "∙ Dedicated out-of-band management network (OOB)\n∙ Software-defined networking (SDN) with plane separation\n∙ Management plane protection with strict ACLs", + "enterprise": "∙ Dedicated OOB management network infrastructure\n∙ SDN platform with automated plane segmentation\n∙ Management plane micro-segmentation\n∙ Automated configuration enforcement" }, "risks": [ + "R-AC-1", + "R-AC-2", "R-AC-3", "R-AC-4", "R-AM-1", @@ -90562,39 +92965,38 @@ "R-BC-2", "R-BC-3", "R-BC-4", + "R-BC-5", "R-EX-1", "R-EX-2", "R-EX-3", "R-EX-4", "R-EX-5", + "R-EX-6", "R-EX-7", "R-GV-1", "R-GV-2", + "R-GV-3", "R-GV-4", "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", "R-IR-4", - "R-SA-1" + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" ], "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", "MT-1", "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", "MT-7", "MT-8", "MT-9", @@ -90606,17 +93008,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" }, { - "control_id": "NET-08.1", - "title": "DMZ Networks", + "control_id": "NET-06.9", + "title": "Separate Subnets To Isolate Functions", "family": "NET", - "description": "Mechanisms exist to monitor De-Militarized Zone (DMZ) network segments to separate untrusted networks from trusted networks.", - "scf_question": "Does the organization monitor De-Militarized Zone (DMZ) network segments to separate untrusted networks from trusted networks?", - "relative_weight": 8, - "conformity_cadence": "Annual", + "description": "Mechanisms exist to implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 7, + "conformity_cadence": "", "evidence_requests": [], "pptdf": "Technology", "nist_csf_function": "Protect", @@ -90627,23 +93031,19 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). \n▪ Internet-facing technologies are governed no differently from internal network assets.", - "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor De-Militarized Zone (DMZ) network segments to separate untrusted networks from trusted networks.", - "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ System Security Plan (SSP)", - "small": "∙ System Security Plan (SSP)", - "medium": "∙ Architectural review board\n∙ System Security Plan (SSP)", - "large": "∙ Architectural review board\n∙ System Security Plan (SSP)", - "enterprise": "∙ Architectural review board\n∙ System Security Plan (SSP)" + "micro_small": "∙ Subnetting for basic functional isolation\n∙ VLAN segmentation", + "small": "∙ VLAN-based subnet isolation\n∙ Separate subnets for servers, workstations and IoT/OT", + "medium": "∙ Subnet-based micro-segmentation\n∙ Firewall rules between functional subnets\n∙ Network ACLs for inter-subnet traffic", + "large": "∙ Network micro-segmentation\n∙ Host-based firewall enforcement between subnets\n∙ Zero Trust Network Architecture (ZTNA) between segments", + "enterprise": "∙ Enterprise micro-segmentation platform (e.g., Illumio, Guardicore)\n∙ Software-Defined Networking (SDN) for subnet isolation\n∙ ZTNA platform for workload-to-workload access control\n∙ Automated subnet policy enforcement" }, "risks": [ "R-AC-1", @@ -90700,7 +93100,275 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "NET-07", + "title": "Network Connection Termination", + "family": "NET", + "description": "Mechanisms exist to terminate network connections at the end of a session or after an organization-defined time period of inactivity.", + "scf_question": "Does the organization terminate network connections at the end of a session or after an organization-defined time period of inactivity?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": false, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network connection terminations at the end of a session or after an entity-defined time period of inactivity.\n▪ SBC terminate remote sessions at the end of the session or after an entity-defined time period of inactivity.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate network connections at the end of a session or after an organization-defined time period of inactivity. ", + "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [ + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Configure session timeouts on systems and applications", + "small": "∙ Session timeout policy\n∙ Configure timeouts on all key systems", + "medium": "∙ Formal network session termination policy\n∙ Automated session timeout enforcement", + "large": "∙ Enterprise session management controls\n∙ Automated disconnect for idle sessions\n∙ Network access control enforcement", + "enterprise": "∙ Enterprise session management platform\n∙ Automated session termination via NAC/IAM\n∙ Zero-trust continuous session validation" + }, + "risks": [ + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-IR-1", + "R-IR-2", + "R-IR-4", + "R-SA-1" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "NET-08", + "title": "Network Intrusion Detection / Prevention Systems (NIDS / NIPS)", + "family": "NET", + "description": "Mechanisms exist to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network.", + "scf_question": "Does the organization employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network. ", + "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)", + "small": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)", + "medium": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)", + "large": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)", + "enterprise": "∙ Network Intrusion Detection System (NIDS)\n∙ Network Intrusion Prevention Systems (NIPS)" + }, + "risks": [ + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-IR-4", + "R-SA-1" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "NET-08.1", + "title": "DMZ Networks", + "family": "NET", + "description": "Mechanisms exist to monitor De-Militarized Zone (DMZ) network segments to separate untrusted networks from trusted networks.", + "scf_question": "Does the organization monitor De-Militarized Zone (DMZ) network segments to separate untrusted networks from trusted networks?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). \n▪ Internet-facing technologies are governed no differently from internal network assets.", + "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor De-Militarized Zone (DMZ) network segments to separate untrusted networks from trusted networks.", + "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ System Security Plan (SSP)", + "small": "∙ System Security Plan (SSP)", + "medium": "∙ Architectural review board\n∙ System Security Plan (SSP)", + "large": "∙ Architectural review board\n∙ System Security Plan (SSP)", + "enterprise": "∙ Architectural review board\n∙ System Security Plan (SSP)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { @@ -90721,7 +93389,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel receive feeds from Wireless Intrusion Detection / Protection Systems (WIDS / WIPS) to identify rogue wireless devices and to detect attack attempts via wireless networks.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize Wireless Intrusion Detection / Protection Systems (WIDS / WIPS) on wireless network segments.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -90792,9 +93460,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "NET-08.3", @@ -90814,7 +93482,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enforce host containment protections that revoke or quarantine a host’s access to the network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90884,7 +93552,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -90975,7 +93644,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -90996,9 +93666,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the authenticity and integrity of communications sessions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the authenticity and integrity of communications sessions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91056,7 +93726,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91077,9 +93748,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically invalidate session identifiers upon user logout or other session termination.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically invalidate session identifiers upon user logout or other session termination. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91133,7 +93804,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91188,7 +93860,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91209,7 +93882,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel ensure Domain Name Service (DNS) resolution is designed, implemented and managed to protect the security of name / address resolution.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure Domain Name Service (DNS) resolution is designed, implemented and managed to protect the security of name / address resolution.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -91287,7 +93960,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91308,9 +93982,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel ensure systems that collectively provide Domain Name Service (DNS) resolution service for are fault-tolerant and implement internal/external role separation.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure systems that collectively provide Domain Name Service (DNS) resolution service are fault-tolerant and implement internal/external role separation.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure systems that collectively provide Domain Name Service (DNS) resolution service are fault-tolerant and implement internal/external role separation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91383,7 +94057,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91404,9 +94079,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to perform data origin authentication and data integrity verification on the Domain Name Service (DNS) resolution responses received from authoritative sources when requested by client systems.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to perform data origin authentication and data integrity verification on the Domain Name Service (DNS) resolution responses received from authoritative sources when requested by client systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91483,7 +94158,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91504,7 +94180,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to validate the legitimacy of email communications through configuring a Domain Naming Service (DNS) Sender Policy Framework (SPF) record to specify the IP addresses and/or hostnames that are authorized to send email from the specified domain.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -91581,7 +94257,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91680,7 +94357,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91703,7 +94381,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize out-of-band channels for the electronic transmission of information and/or the physical shipment of system components or devices to authorized individuals.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize out-of-band channels for the electronic transmission of information and/or the physical shipment of system components or devices to authorized individuals. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91762,15 +94440,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "NET-12", "title": "Safeguarding Data Over Open Networks", "family": "NET", - "description": "Cryptographic mechanisms exist to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks.", - "scf_question": "Are cryptographic mechanisms utilized to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks?", + "description": "Cryptographic mechanisms exist to implement strong cryptography and security protocols to safeguard sensitive and/or regulated data during transmission over open, public networks.", + "scf_question": "Are cryptographic mechanisms utilized to implement strong cryptography and security protocols to safeguard sensitive and/or regulated data during transmission over open, public networks?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -91785,7 +94464,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). \n▪ Wireless access is protected via secure authentication and encryption.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network communications containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91862,7 +94541,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -91958,15 +94638,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "NET-12.2", "title": "End-User Messaging Technologies", "family": "NET", - "description": "Mechanisms exist to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies.", - "scf_question": "Does the organization prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies?", + "description": "Mechanisms exist to prohibit the transmission of unprotected sensitive and/or regulated data by end-user messaging technologies.", + "scf_question": "Does the organization prohibit the transmission of unprotected sensitive and/or regulated data by end-user messaging technologies?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -91979,9 +94660,9 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92065,7 +94746,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92086,7 +94768,7 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the confidentiality, integrity and availability of electronic messaging communications.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92171,7 +94853,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92195,7 +94878,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define, control and review organization-approved, secure remote access methods.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92276,7 +94959,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92299,9 +94983,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically monitor and control remote access sessions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically monitor and control remote access sessions. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -92356,7 +95040,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92377,9 +95062,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of remote access sessions (e.g., VPN).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of remote access sessions (e.g., VPN). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92438,7 +95123,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92538,7 +95224,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92561,7 +95248,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network communications containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to restrict the execution of privileged commands and access to security-relevant information via remote access only for compelling operational needs.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to restrict the execution of privileged commands and access to security-relevant information via remote access only for compelling operational needs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92619,7 +95306,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92643,9 +95331,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define secure telecommuting practices and govern remote access to TAASD for remote workers.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define secure telecommuting practices and govern remote access to TAASD for remote workers. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92737,7 +95425,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92760,7 +95449,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to proactively control and monitor third-party accounts used to access, support, or maintain system components via remote access.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92849,7 +95538,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92857,7 +95547,7 @@ "title": "Endpoint Security Validation", "family": "NET", "description": "Automated mechanisms exist to validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS)?", + "scf_question": "Does the organization use automated mechanisms to validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 6, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -92941,7 +95631,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -92966,7 +95657,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel provide the capability to expeditiously disconnect or disable a user's remote access session.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to provide the capability to expeditiously disconnect or disable a user's remote access session.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -93044,7 +95735,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93151,7 +95843,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93227,7 +95920,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93250,7 +95944,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to disable unnecessary wireless networking capabilities that are internally embedded within system components prior to issuance to end users.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to disable unnecessary wireless networking capabilities that are internally embedded within system components prior to issuance to end users. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93303,7 +95997,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93326,7 +96021,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to identify and explicitly authorize users who are allowed to independently configure wireless networking capabilities.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to identify and explicitly authorize users who are allowed to independently configure wireless networking capabilities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93388,7 +96083,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93411,7 +96107,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to confine wireless communications to organization-controlled boundaries.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to confine wireless communications to organization-controlled boundaries. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93483,7 +96179,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93508,9 +96205,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to test for the presence of Wireless Access Points (WAPs) and identify all authorized and unauthorized WAPs within the facility(ies).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to test for the presence of Wireless Access Points (WAPs) and identify all authorized and unauthorized WAPs within the facility(ies). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -93582,7 +96279,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93590,7 +96288,7 @@ "title": "Intranets", "family": "NET", "description": "Mechanisms exist to establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS.", - "scf_question": "Does the organization establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n (1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n (2) Process, store, and/or transmit organization-controlled information using the external systems?", + "scf_question": "Does the organization establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -93603,7 +96301,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -93688,7 +96386,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93713,7 +96412,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Data Loss Prevention (DLP), or similar technologies, prevent unauthorized devices from connecting to endpoint devices to control the distribution of sensitive/regulated data.\n▪ DLP prevents unauthorized devices from connecting to endpoint devices to control the distribution of sensitive/regulated data.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically implement Data Loss Prevention (DLP) to protect sensitive information as it is stored, transmitted and processed.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -93751,7 +96450,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93778,7 +96478,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce Internet-bound network traffic routing through a proxy device for URL content filtering to limit a user's ability to connect to prohibited content.\n▪ Content filtering blocks users from performing ad hoc file transfers through unapproved file transfer services (e.g., Box, Dropbox, Google Drive, etc.).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to force Internet-bound network traffic through a proxy device (e.g., Policy Enforcement Point (PEP)) for URL content filtering and DNS filtering to limit a user's ability to connect to dangerous or prohibited Internet sites.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -93854,7 +96554,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93877,9 +96578,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce Internet-bound network traffic routing through a proxy device for URL content filtering to limit a user's ability to connect to prohibited content.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to route internal communications traffic to external networks through organization-approved proxy servers at managed interfaces.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to route internal communications traffic to external networks through organization-approved proxy servers at managed interfaces. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93952,7 +96653,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -93973,7 +96675,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure the proxy to make encrypted communications traffic visible to monitoring tools and mechanisms.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94049,7 +96751,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94070,7 +96773,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically route networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94126,7 +96829,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94147,7 +96851,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically ensure network traffic complies with Internet Engineering Task Force (IETF) protocol specifications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94214,7 +96918,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94235,7 +96940,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure that domain name lookups, whether for internal or external domains, are validated according to Domain Name System Security Extensions (DNSSEC).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94301,7 +97006,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94322,7 +97028,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement Internet address denylisting protections that blocks traffic received from or destined to a denylisted Internet address.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94388,7 +97094,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94409,7 +97116,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement bandwidth control technologies to limit the amount of bandwidth used by categories of domains that are bandwidth-intensive.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94474,7 +97181,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94495,7 +97203,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to force systems and processes to authenticate Internet-bound traffic with a proxy to enable user, group and/or location-aware security controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94560,7 +97268,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94581,7 +97290,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent communication with Technology Assets, Applications and/or Services (TAAS) that use a set of known bad certificates.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94647,7 +97356,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94655,7 +97365,7 @@ "title": "Content Disarm and Reconstruction (CDR)", "family": "NET", "description": "Automated Content Disarm and Reconstruction (CDR) mechanisms exist to detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements.", - "scf_question": "Automated Content Disarm and Reconstruction (CDR) Does the organization detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements?", + "scf_question": "Does the organization use automated Content Disarm and Reconstruction (CDR) mechanisms exist to detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -94668,7 +97378,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational Content Disarm and Reconstruction (CDR) capability detects the presence of unapproved active content and facilitates its removal, resulting in content with only known safe elements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94734,7 +97444,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94755,7 +97466,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement an email filtering security service to detect malicious attachments in emails and prevent users from accessing them.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94821,7 +97532,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94842,7 +97554,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor the organization's email domain’s reputation and protect the email domain’s reputation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94908,7 +97620,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -94929,7 +97642,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement sender denylisting protections that prevent the reception of email from denylisted senders, domains and/or email servers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94995,7 +97708,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95016,7 +97730,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize an authenticated received chain that allows for an intermediary to sign its own authentication of the original email, allowing downstream entities to accept the intermediary’s authentication even if the email was changed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95080,7 +97794,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95101,9 +97816,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement domain signature verification protections that authenticate incoming email according to the Domain-based Message Authentication Reporting and Conformance (DMARC).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement domain signature verification protections that authenticate incoming email according to the Domain-based Message Authentication Reporting and Conformance (DMARC).\n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95167,7 +97882,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95188,7 +97904,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable users to digitally sign their emails, allowing external parties to authenticate the email’s sender and its contents according to the Domain-based Message Authentication Reporting and Conformance (DMARC) email authentication protocol.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95252,7 +97968,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95273,7 +97990,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable the encryption of outgoing emails using organization-approved cryptographic means.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95339,7 +98056,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95360,7 +98078,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize adaptive email protections that involve employing risk-based analysis in the application and enforcement of email protections.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95426,7 +98144,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95513,7 +98232,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95600,7 +98320,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95626,7 +98347,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ The Human Resources (HR) department maintains a current list of personnel with authorized access to organizational facilities and facilitates the implementation of physical access management controls.\n▪ Physical security controls and technologies ensure that only authorized personnel are allowed access to secure areas.\n▪ A facilities maintenance team, or similar function, manages the operation of automated physical and environmental protection controls.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to facilitate the operation of physical and environmental protection controls.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to facilitate the operation of physical and environmental protection controls. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95723,7 +98444,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95731,7 +98453,7 @@ "title": "Physical Security Plan (PSP)", "family": "PES", "description": "Mechanisms exist to document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats.", - "scf_question": "Does the organization document a Site Security Plan (SitePlan) for each server and communications room to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats?", + "scf_question": "Does the organization document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats?", "relative_weight": 4, "conformity_cadence": "Annual", "evidence_requests": [ @@ -95746,7 +98468,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95815,7 +98537,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -95907,7 +98630,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96006,7 +98730,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96031,11 +98756,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ The Human Resources (HR) department maintains a current list of personnel with authorized access to organizational facilities and facilitates the implementation of physical access management controls.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to authorize physical access to facilities based on the position or role of the individual.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -96104,7 +98829,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96125,7 +98851,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to enforce a \"two-person rule\" for physical access by requiring two authorized individuals with separate access cards, keys or PINs, to access highly-sensitive areas (e.g., safe, high-security cage, etc.).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96191,7 +98917,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96218,7 +98945,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls and technologies ensure that only authorized personnel are allowed access to secure areas.\n▪ A facilities maintenance team, or similar function, manages the operation of automated physical and environmental protection controls.\n▪ Physical security controls and technologies are configured to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96308,7 +99035,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96417,7 +99145,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96440,7 +99169,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect system components from unauthorized physical access (e.g., lockable physical casings).", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect system components from unauthorized physical access (e.g., lockable physical casings). ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96500,7 +99229,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96508,7 +99238,7 @@ "title": "Physical Access Logs", "family": "PES", "description": "Physical access control mechanisms generate a log entry for each access attempt through controlled ingress and egress points.", - "scf_question": "Does the organization generate a log entry for each access attempt through controlled ingress and egress points?", + "scf_question": "Physical access control mechanisms generate a log entry for each access attempt through controlled ingress and egress points?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -96523,7 +99253,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Where applicable, physical security controls and technologies are configured to generate a log entry for each access attempt through controlled ingress and egress points.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to generate a log entry for each access attempt through controlled ingress and egress points.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96606,15 +99336,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PES-03.4", "title": "Access To Critical Systems", "family": "PES", - "description": "Physical access control mechanisms exist to enforce physical access to critical systems or sensitive/regulated data, in addition to the physical access controls for the facility.", - "scf_question": "Does the organization enforce physical access to critical systems or sensitive/regulated data, in addition to the physical access controls for the facility?", + "description": "Physical access control mechanisms exist to enforce physical access to critical systems or sensitive and/or regulated data, in addition to the physical access controls for the facility.", + "scf_question": "Does the organization enforce physical access to critical systems or sensitive and/or regulated data, in addition to the physical access controls for the facility?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -96713,7 +99444,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96736,7 +99468,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls and technologies are primarily designed and implemented for offices, rooms and facilities that focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to identify systems, equipment and respective operating environments that require limited physical access so that appropriate physical access controls are designed and implemented for offices, rooms and facilities.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to identify systems, equipment and respective operating environments that require limited physical access so that appropriate physical access controls are designed and implemented for offices, rooms and facilities. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96821,7 +99553,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96842,9 +99575,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to allow only authorized personnel access to secure areas.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to allow only authorized personnel access to secure areas. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96928,7 +99661,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -96949,7 +99683,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to inspect personnel and their personal effects (e.g., personal property ordinarily worn or carried by the individual, including vehicles) to prevent the unauthorized exfiltration of data and technology assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -97031,7 +99765,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -97134,7 +99869,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -97246,7 +99982,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -97269,9 +100006,9 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Where applicable, physical security controls and technologies are configured to monitor for, detect and respond to physical security incidents.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to monitor physical intrusion alarms and surveillance equipment.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to monitor physical intrusion alarms and surveillance equipment. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -97339,15 +100076,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PES-05.2", "title": "Monitoring Physical Access To Critical Systems", "family": "PES", - "description": "Facility security mechanisms exist to monitor physical access to critical systems or sensitive/regulated data, in addition to the physical access monitoring of the facility.", - "scf_question": "Does the organization monitor physical access to critical systems or sensitive/regulated data, in addition to the physical access monitoring of the facility?", + "description": "Facility security mechanisms exist to monitor physical access to critical systems or sensitive and/or regulated data, in addition to the physical access monitoring of the facility.", + "scf_question": "Does the organization monitor physical access to critical systems or sensitive and/or regulated data, in addition to the physical access monitoring of the facility?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -97431,7 +100169,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -97456,9 +100195,9 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.\n▪ Users are trained and encouraged to stop and question anyone attempting to install or remove IT assets from facilities.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible).", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible). ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -97544,15 +100283,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PES-06.1", "title": "Distinguish Visitors from On-Site Personnel", "family": "PES", - "description": "Physical access control mechanisms exist to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", - "scf_question": "Does the organization easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible?", + "description": "Physical access control mechanisms exist to easily distinguish between onsite personnel and visitors, especially in areas where sensitive and/or regulated data is accessible.", + "scf_question": "Does the organization easily distinguish between onsite personnel and visitors, especially in areas where sensitive and/or regulated data is accessible?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -97567,7 +100307,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -97651,7 +100391,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -97659,7 +100400,7 @@ "title": "Identification Requirement", "family": "PES", "description": "Physical access control mechanisms exist to requires at least one(1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility.", - "scf_question": "Does the organization require at least one (1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility?", + "scf_question": "Does the organization requires at least one(1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -97746,7 +100487,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -97767,9 +100509,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Users are trained and encouraged to stop and question anyone attempting to install or remove IT assets from facilities.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict unescorted access to facilities to personnel with required security clearances, formal access authorizations and validate the need for access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict unescorted access to facilities to personnel with required security clearances, formal access authorizations and validate the need for access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -97851,7 +100593,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -97874,7 +100617,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to automatically facilitate the maintenance and review of visitor access records.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -97916,7 +100659,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -97937,7 +100681,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to minimize the collection of Personal Data (PD) contained in visitor access records.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -98017,7 +100761,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98113,7 +100858,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98138,7 +100884,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power equipment and power cabling for the system from damage and destruction.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power equipment and power cabling for the system from damage and destruction. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98207,7 +100953,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98230,7 +100977,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize automatic voltage controls for critical system components.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize automatic voltage controls for critical system components. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98293,7 +101040,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98381,7 +101129,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98469,7 +101218,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98492,7 +101242,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98557,7 +101307,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98580,9 +101331,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect systems from damage resulting from water leakage by providing master shutoff valves that are accessible, working properly and known to key personnel.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect systems from damage resulting from water leakage by providing master shutoff valves that are accessible, working properly and known to key personnel. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98651,7 +101402,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98672,9 +101424,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to detect the presence of water in the vicinity of critical systems and alert facility maintenance and IT personnel.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to detect the presence of water in the vicinity of critical systems and alert facility maintenance and IT personnel. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98738,7 +101490,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98813,7 +101566,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98838,7 +101592,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire suppression and detection devices/systems for the system that are supported by an independent energy source.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire suppression and detection devices/systems for the system that are supported by an independent energy source. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98907,7 +101661,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -98930,7 +101685,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire detection devices/systems that activate automatically and notify organizational personnel and emergency responders in the event of a fire.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire detection devices/systems that activate automatically and notify organizational personnel and emergency responders in the event of a fire. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98996,7 +101751,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99017,9 +101773,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize fire suppression devices/systems that provide automatic notification of any activation to organizational personnel and emergency responders.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize fire suppression devices/systems that provide automatic notification of any activation to organizational personnel and emergency responders. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99083,7 +101839,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99170,7 +101927,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99263,7 +102021,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99286,7 +102045,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to trigger an alarm or notification of temperature and humidity changes that be potentially harmful to personnel or equipment.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to trigger an alarm or notification of temperature and humidity changes that be potentially harmful to personnel or equipment. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99351,7 +102110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99374,7 +102134,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99454,7 +102214,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99563,7 +102324,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99586,7 +102348,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to locate system components within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to locate system components within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99673,7 +102435,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99694,9 +102457,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power and telecommunications cabling carrying data or supporting information services from interception, interference or damage.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power and telecommunications cabling carrying data or supporting information services from interception, interference or damage. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99782,7 +102545,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99805,7 +102569,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict access to printers and other system output devices to prevent unauthorized individuals from obtaining the output.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict access to printers and other system output devices to prevent unauthorized individuals from obtaining the output. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99869,7 +102633,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99890,9 +102655,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect the system from information leakage due to electromagnetic signals emanations.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect the system from information leakage due to electromagnetic signals emanations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99944,7 +102709,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -99965,11 +102731,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to employ asset location technologies that track and monitor the location and movement of organization-defined assets within organization-defined controlled areas.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -100027,7 +102793,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100084,7 +102851,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100105,7 +102873,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to mark system hardware components indicating the impact or classification level of the information permitted to be processed, stored or transmitted by the hardware component.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100165,7 +102933,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100186,7 +102955,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to automatically monitor physical proximity to robotic or autonomous platforms to reduce applied force or stop the operation when sensors indicate a potentially dangerous scenario.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -100237,15 +103006,16 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PES-18", "title": "On-Site Client Segregation", "family": "PES", - "description": "Mechanisms exist to ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces.", - "scf_question": "Does the organization ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces?", + "description": "Mechanisms exist to ensure client-specific sensitive and/or regulated data is isolated from other data when client-specific sensitive and/or regulated data is processed or stored within multi-client workspaces.", + "scf_question": "Does the organization ensure client-specific sensitive and/or regulated data is isolated from other data when client-specific sensitive and/or regulated data is processed or stored within multi-client workspaces?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -100258,7 +103028,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -100334,7 +103104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100359,7 +103130,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to maintain an accurate inventory of all physical access devices (e.g., RFID cards, access fobs, door keys, etc.).", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -100431,7 +103202,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100455,7 +103227,7 @@ }, "maturity": { "0": "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.", - "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.\n▪ Data/process owners are expected to take the initiative to work with Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ No formal data privacy principles are identified for the organization.\n▪ Data/process owners perform their own Data Protection Impact Assessment (DPIA).", + "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.\n▪ Data/process owners are expected to take the initiative to work with Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ No formal data privacy principles are identified for the organization.\n▪ Data/process owners perform their own Data Protection Impact Assessment (DPIA). ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is formally assigned as the Chief Privacy Officer (CPO), or similar role, to lead the organization's data privacy program. This individual may be assigned to multiple data privacy-related roles.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to facilitate the implementation and operation of data protection controls throughout the data lifecycle to ensure all forms of Personal Data (PD) are processed lawfully, fairly and transparently.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100532,7 +103304,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100540,7 +103313,7 @@ "title": "Chief Privacy Officer (CPO)", "family": "PRI", "description": "Mechanisms exist to appoints a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program.", - "scf_question": "Does the organization have a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program?", + "scf_question": "Does the organization appoints a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [ @@ -100555,7 +103328,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is formally assigned as the Chief Privacy Officer (CPO), or similar role, to lead the organization's data privacy program. This individual may be assigned to multiple data privacy-related roles.\n▪ The CPO, or similar role, identifies appropriate data privacy controls that Technology Assets, Applications and/or Services (TAAS) and third-parties must adhere to, in addition to applicable statutory, regulatory and/or contractual obligations.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ A Chief Privacy Officer (CPO) or similar role, has the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100603,7 +103376,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100671,7 +103445,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100679,7 +103454,7 @@ "title": "Dissemination of Data Privacy Program Information", "family": "PRI", "description": "Mechanisms exist to: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes.", - "scf_question": "Does the organization: \n (1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n (2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n (3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n (4) Inform data subjects when changes are made to the privacy notice and the nature of such changes?", + "scf_question": "Does the organization: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -100692,11 +103467,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -100749,7 +103524,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100772,7 +103548,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Data/process owners work with IT and/or cybersecurity personnel and Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ A Data Protection Officer (DPO) is appointed:\n(1) Based on professional qualifications; and\n(2) To be involved in all issues related to how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100830,7 +103606,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100853,7 +103630,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to implement and manage Binding Corporate Rules (BCR) (e.g., data sharing agreement) to legally-bind all parties engaged in a joint economic activity that contractually states enforceable rights on data subjects with regard to the processing of their personal data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -100904,7 +103681,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100925,7 +103703,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure Personal Data (PD) is protected by logical and physical security safeguards that are sufficient and appropriately scoped to protect the confidentiality and integrity of the PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -100974,7 +103752,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -100995,7 +103774,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to limit the disclosure of Personal Data (PD) to authorized parties for the sole purpose for which the PD was obtained.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101043,7 +103822,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101064,7 +103844,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to appoint an individual to determine the following criteria about Personal Data (PD):\n(1) The purpose why PD is necessary; \n(2) Authorized methods to collect, receive, process, store, transmit, share, update and/or dispose PD; and\n(3) Authorized parties PD may be shared with.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101114,7 +103894,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101122,7 +103903,7 @@ "title": "Personal Data (PD) Process Manager", "family": "PRI", "description": "Mechanisms exist to assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent.", - "scf_question": "Does the organization assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD)is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent?", + "scf_question": "Does the organization assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -101135,7 +103916,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ Accountability is assigned to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101186,7 +103967,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101207,7 +103989,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to strictly govern financial incentives offered to data subjects for Personal Data (PD) to ensure compliance with applicable legal and regulatory requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101243,7 +104025,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101302,9 +104085,102 @@ "MT-12", "MT-13", "MT-14", - "MT-15" + "MT-15", + "MT-28" ] }, + { + "control_id": "PRI-01.12", + "title": "Privacy-Aware Design", + "family": "PRI", + "description": "Mechanisms exist to formally incorporate the organization's data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "scf_question": "Does the organization formally incorporate its data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to formally incorporate the organization's data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Privacy by design principles (basic data minimization practices)\n∙ NIST Privacy Framework reference", + "small": "∙ Privacy by design checklist for new systems\n∙ NIST Privacy Framework or GDPR Art. 25 alignment", + "medium": "∙ Privacy by design and by default program\n∙ DPIA for new systems\n∙ Privacy engineering practices in SDLC", + "large": "∙ Enterprise privacy engineering program\n∙ Privacy by design requirements in system development lifecycle\n∙ DPIA for new data processing", + "enterprise": "∙ Enterprise privacy engineering framework\n∙ Automated privacy design reviews in SDLC\n∙ DPIA for all new data processing\n∙ Privacy technology stack (e.g., OneTrust)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-4", + "R-AM-2", + "R-AM-3", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-28" + ], + "errata": "- new control - NIST Privacy Framework" + }, { "control_id": "PRI-02", "title": "Data Privacy Notice", @@ -101325,11 +104201,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ The CPO, or similar role, develops and ensures data privacy notices are published that include relevant purpose, notice and data privacy program information.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -101379,7 +104255,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101400,7 +104277,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data privacy notices identify the purpose(s) for which Personal Data (PD) is collected, received, processed, stored, transmitted and/or shared.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101453,7 +104330,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101461,7 +104339,7 @@ "title": "Automated Data Management Processes", "family": "PRI", "description": "Automated mechanisms exist to adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s).", - "scf_question": "Does the organization use automated mechanisms to adjust data that is able tobe collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s)?", + "scf_question": "Does the organization use automated mechanisms to adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s)?", "relative_weight": 1, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -101474,7 +104352,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101526,7 +104404,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101547,7 +104426,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish Computer Matching Agreements (CMA) on the organization's public website(s).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101598,7 +104477,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101619,7 +104499,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to draft, publish and keep System of Records Notices (SORN) updated in accordance with regulatory guidance.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101670,7 +104550,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101691,7 +104572,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to review all routine uses of data published in the System of Records Notices (SORN) to ensure continued accuracy and to ensure that routine uses continue to be compatible with the purpose for which the information was collected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101742,7 +104623,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101763,7 +104645,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to review all Privacy Act exemptions claimed for the System of Records Notices (SORN) to ensure they remain appropriate and accurate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101814,7 +104696,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101835,7 +104718,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide real-time and/or layered notice when Personal Data (PD) is collected that provides data subjects with a summary of key points or more detailed information that is specific to the organization's data privacy notice.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101886,7 +104769,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101907,7 +104791,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to periodically assess disclosed purposes for which Personal Data (PD) is collected, received, processed, stored, transmitted and/or shared to ensure compatibility with reasonable consumer expectations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101958,7 +104842,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -101979,7 +104864,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reasonably accommodate data privacy notice formatting for consumers requiring alternative formatting due to accessibility needs through:\n(1) Screen resolution / screen sizes;\n(2) Multilingual support; and/or\n(3) Disability-specific concessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102030,7 +104915,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102051,7 +104937,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure symmetry in choice, where options presented to consumers for more protective options are not longer, more difficult, nor more time-consuming than less protective options.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102102,7 +104988,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102123,7 +105010,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to avoid choice architecture that impairs, interferes with or subverts a consumer’s ability to make well-informed choices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102174,7 +105061,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102195,9 +105083,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to perform testing of choice architecture to ensure it does not undermine a consumer’s ability to submit choice selections.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to perform testing of choice architecture to ensure it does not undermine a consumer’s ability to submit choice selections. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102246,7 +105134,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102267,9 +105156,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include within the data privacy notice a notification to data subjects of:\n(1) Their right to limit the use and disclosure of their sensitive Personal Data (sPD); and\n(2) The methods available to exercise that right.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include within the data privacy notice a notification to data subjects of:\n(1) Their right to limit the use and disclosure of their sensitive Personal Data (sPD); and\n(2) The methods available to exercise that right. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102318,7 +105207,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102339,7 +105229,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with a data privacy notice through alternative means for interactions that do not utilize an interface on a website or application.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102390,15 +105280,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRI-03", - "title": "Choice & Consent", + "title": "Data Subject Consent", "family": "PRI", - "description": "Mechanisms exist to enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations?", "relative_weight": 7, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -102411,9 +105302,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to Mechanisms exist to enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102465,8 +105356,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control\n- renamed control" }, { "control_id": "PRI-03.1", @@ -102486,7 +105379,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to modify permission to collect, receive, process, store, transmit, share, update and/or dispose selected attributes of their Personal Data (PD).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102539,7 +105432,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102560,7 +105454,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to present data subjects with a new or updated consent request to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD) in conjunction with the data action, when:\n(1) The original circumstances under which an individual gave consent have changed; or\n(2) A significant amount of time has passed since an individual gave consent.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102613,7 +105507,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102634,7 +105529,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Asset / process owners collect, store, processes, transmit share or use PD only for the purposes identified in the data privacy notice.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to prevent the sale, processing and/or sharing of Personal Data (PD) when:\n(1) Instructed by the data subject; or\n(2) The data subject is a minor, where selling and/or sharing PD is legally prohibited.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102687,7 +105582,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102708,7 +105604,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to revoke consent to collect, receive, process, store, transmit, share and/or update their Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102761,7 +105657,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102782,7 +105679,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to prevent discrimination against a data subject for exercising their legal rights pertaining to modifying or revoking consent, including prohibiting:\n(1) Refusing products and/or services;\n(2) Charging different rates for goods and/or services; and\n(3) Providing different levels of quality.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102832,7 +105729,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102853,7 +105751,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to authorize another person or entity (e.g., authorized agent, proxy, etc.), acting on the data subject's behalf, to make Personal Data (PD) processing decisions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102883,9 +105781,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "PRI-03.7", @@ -102905,7 +105803,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to compel data subjects to select the level of consent deemed appropriate by the data subject for the relevant business purpose (e.g., opt-in, opt-out, accept all cookies, etc.).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102956,7 +105854,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -102977,7 +105876,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically provide data subjects with functionality to exercise pre-selected opt-out preferences (e.g., opt-out signal).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103028,7 +105927,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -103049,7 +105949,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to govern the continued use of Personal Data (PD) as it is collected, received, processed, stored, transmitted, shared and/or updated until:\n(1) Disposal of PD occurs when there is no longer a legitimate business purpose;\n(2) Disposal of PD occurs when the data retention timeline for the use case is met; and/or\n(3) Continued use of PD is prohibited upon withdrawal of data subject consent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103087,7 +105987,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -103095,7 +105996,7 @@ "title": "Cease Processing, Storing and/or Sharing Personal Data (PD)", "family": "PRI", "description": "Mechanisms exist to ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation.", - "scf_question": "Does the organization ensure it ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation?", + "scf_question": "Does the organization ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -103108,7 +106009,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Asset / process owners collect, store, processes, transmit share or use PD only for the purposes identified in the data privacy notice.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103146,7 +106047,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -103167,7 +106069,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of processing changes affecting their Personal Data (PD), including:\n(1) Erasure of PD;\n(2) Remediation of incorrect PD; and/or\n(3) Processing restrictions affecting their PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103203,7 +106105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -103224,7 +106127,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to obtain consent from data subjects to opt-in for the following Personal Data (PD) actions:\n(1) Collecting;\n(2) Receiving; \n(3) Processing;\n(4) Storing;\n(5) Transmitting:\n(6) Sharing; and/or\n(7) Updating.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103260,7 +106163,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -103281,7 +106185,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to obtain parental or guardian consent for Personal Data (PD) processing actions through reasonable consumer expectations, when the data subject is a minor.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103317,15 +106221,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRI-04", - "title": "Restrict Collection To Identified Purpose", + "title": "Restrict Collection, Processing & Sharing To Identified Purpose", "family": "PRI", - "description": "Mechanisms exist to minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", - "scf_question": "Does the organization minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent?", + "description": "Mechanisms exist to minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", + "scf_question": "Does the organization minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -103340,9 +106245,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -103394,414 +106299,422 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] - }, - { - "control_id": "PRI-04.1", - "title": "Authority To Collect, Process, Store & Share Personal Data (PD)", - "family": "PRI", - "description": "Mechanisms exist to determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process.", - "scf_question": "Does the organization determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process?", - "relative_weight": 7, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-PRI-02" - ], - "pptdf": "Process", - "nist_csf_function": "Identify", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": false - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process.", - "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], - "possible_solutions": { - "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" - }, - "risks": [ - "R-AM-3", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-GV-1", - "R-GV-2", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-IR-4", - "R-SA-2", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "PRI-04.2", - "title": "Primary Sources", - "family": "PRI", - "description": "Mechanisms exist to ensure information is directly collected from the data subject, whenever possible.", - "scf_question": "Does the organization ensure information is directly collected from the data subject, whenever possible?", - "relative_weight": 7, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Process", - "nist_csf_function": "Identify", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": false - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure information is directly collected from the data subject, whenever possible.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" - }, - "risks": [ - "R-AM-3", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-GV-1", - "R-GV-4", - "R-GV-6", - "R-GV-7", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "PRI-04.3", - "title": "Identifiable Image Collection", - "family": "PRI", - "description": "Mechanisms exist to restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs.", - "scf_question": "Does the organization restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs?", - "relative_weight": 7, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Process", - "nist_csf_function": "Identify", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" - }, - "risks": [ - "R-AM-3", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-GV-1", - "R-GV-2", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "PRI-04.4", - "title": "Acquired Personal Data (PD)", - "family": "PRI", - "description": "Mechanisms exist to promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject.", - "scf_question": "Does the organization promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject?", - "relative_weight": 6, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Process", - "nist_csf_function": "Identify", - "scrm_focus": { - "strategic": false, - "operational": false, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" - }, - "risks": [ - "R-AM-3", - "R-GV-1", - "R-GV-5" - ], - "threats": [ - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "PRI-04.5", - "title": "Validate Collected Personal Data (PD)", - "family": "PRI", - "description": "Mechanisms exist to ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process.", - "scf_question": "Does the organization ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process?", - "relative_weight": 1, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Data", - "nist_csf_function": "Identify", - "scrm_focus": { - "strategic": false, - "operational": false, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" - }, - "risks": [ - "R-AM-3", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-GV-1", - "R-GV-2", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-IR-4", - "R-SA-2", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "PRI-04.6", - "title": "Re-Validate Collected Personal Data (PD)", - "family": "PRI", - "description": "Mechanisms exist to ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate.", - "scf_question": "Does the organization ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate?", - "relative_weight": 1, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Data", - "nist_csf_function": "Identify", - "scrm_focus": { - "strategic": false, - "operational": false, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" - }, - "risks": [ - "R-AM-3", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-GV-1", - "R-GV-2", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-IR-4", - "R-SA-2", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control\n- renamed control" + }, + { + "control_id": "PRI-04.1", + "title": "Authority To Collect, Process, Store & Share Personal Data (PD)", + "family": "PRI", + "description": "Mechanisms exist to determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process.", + "scf_question": "Does the organization determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-PRI-02" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process.", + "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" + }, + "risks": [ + "R-AM-3", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-4", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "PRI-04.2", + "title": "Primary Sources", + "family": "PRI", + "description": "Mechanisms exist to ensure information is directly collected from the data subject, whenever possible.", + "scf_question": "Does the organization ensure information is directly collected from the data subject, whenever possible?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure information is directly collected from the data subject, whenever possible.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" + }, + "risks": [ + "R-AM-3", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-4", + "R-GV-6", + "R-GV-7", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "PRI-04.3", + "title": "Identifiable Image Collection", + "family": "PRI", + "description": "Mechanisms exist to restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs.", + "scf_question": "Does the organization restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" + }, + "risks": [ + "R-AM-3", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "PRI-04.4", + "title": "Acquired Personal Data (PD)", + "family": "PRI", + "description": "Mechanisms exist to promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject.", + "scf_question": "Does the organization promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject?", + "relative_weight": 6, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": false, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" + }, + "risks": [ + "R-AM-3", + "R-GV-1", + "R-GV-5" + ], + "threats": [ + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "PRI-04.5", + "title": "Validate Collected Personal Data (PD)", + "family": "PRI", + "description": "Mechanisms exist to ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process.", + "scf_question": "Does the organization ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process?", + "relative_weight": 1, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Data", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": false, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" + }, + "risks": [ + "R-AM-3", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-4", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "PRI-04.6", + "title": "Re-Validate Collected Personal Data (PD)", + "family": "PRI", + "description": "Mechanisms exist to ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate.", + "scf_question": "Does the organization ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate?", + "relative_weight": 1, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Data", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": false, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" + }, + "risks": [ + "R-AM-3", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-4", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { @@ -103858,7 +106771,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -103866,7 +106780,7 @@ "title": "Personal Data (PD) Retention & Disposal", "family": "PRI", "description": "Mechanisms exist to: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records).", - "scf_question": "Does the organization: \n (1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n (2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n (3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records)?", + "scf_question": "Does the organization: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -103882,11 +106796,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -103969,7 +106883,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -103992,7 +106907,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to address the use of Personal Data (PD) for internal testing, training and research that:\n(1) Takes measures to limit or minimize the amount of PD used for internal testing, training and research purposes; and\n(2) Authorizes the use of PD when such information is required for internal testing, training and research.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104059,7 +106974,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104080,7 +106996,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n(1) Keeping PD up-to-date; and \n(2) Remediating identified inaccuracies, as necessary.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104126,15 +107042,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRI-05.3", - "title": "Data Masking", + "title": "Data Anonymization", "family": "PRI", - "description": "Mechanisms exist to mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification.", - "scf_question": "Does the organization mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification?", + "description": "Mechanisms exist to mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification.", + "scf_question": "Does the organization mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -104147,9 +107064,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104193,8 +107110,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- renamed control" }, { "control_id": "PRI-05.4", @@ -104214,7 +107133,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) to:\n(1) The purpose(s) originally collected, consistent with the data privacy notice(s);\n(2) What is authorized by the data subject, or authorized agent; and\n(3) What is consistent with applicable laws, regulations and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104271,7 +107190,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104279,7 +107199,7 @@ "title": "Inventory of Personal Data (PD)", "family": "PRI", "description": "Mechanisms exist to establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD).", - "scf_question": "Does the organization establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS)that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD)?", + "scf_question": "Does the organization establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -104294,7 +107214,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104360,7 +107280,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104381,7 +107302,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically determine if Personal Data (PD) is maintained in electronic form.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104432,7 +107353,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104455,7 +107377,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to define and implement data handling and protection requirements for specific categories of sensitive Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104502,7 +107424,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104523,7 +107446,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to retain Personal Data (PD) in a format permitting data subject identification for no longer than is necessary for legitimate business purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104559,7 +107482,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104582,7 +107506,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide authenticated data subjects the ability to:\n(1) Access their Personal Data (PD) that is being processed, stored and shared, except where the burden, risk or expense of providing access would be disproportionate to the benefit offered to the data subject through granting access;\n(2) Obtain answers on the specifics of how their PD is collected, received, processed, stored, transmitted, shared, updated and/or disposed; \n(3) Obtain the source(s) of their PD; \n(4) Obtain the categories of their PD being collected, received, processed, stored and shared; \n(5) Request correction to their PD due to inaccuracies;\n(6) Request erasure of their PD; and\n(7) Restrict the further collecting, receiving, processing, storing, transmitting, updated and/or sharing of their PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104643,7 +107567,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104664,7 +107589,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process for:\n(1) Data subjects to have inaccurate Personal Data (PD) maintained by the organization corrected or amended; and\n(2) Disseminating corrections or amendments of PD to other authorized users of the PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104736,7 +107661,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104757,7 +107683,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify affected data subjects if their Personal Data (PD) has been corrected, amended or deleted.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104816,7 +107742,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -104837,7 +107764,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process for data subjects to appeal an adverse decision.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104899,15 +107826,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRI-06.4", - "title": "User Feedback Management", + "title": "Data Subject Feedback Management", "family": "PRI", - "description": "Mechanisms exist to maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", - "scf_question": "Does the organization maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes?", + "description": "Mechanisms exist to maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", + "scf_question": "Does the organization maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes?", "relative_weight": 5, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -104920,9 +107848,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104979,8 +107907,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control\n- renamed control" }, { "control_id": "PRI-06.5", @@ -105000,7 +107930,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to erase a data subject's Personal Data (PD), in accordance with applicable laws, regulations and contractual obligations pertaining to the retention of their PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -105059,7 +107989,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -105080,7 +108011,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to format exports of Personal Data (PD) in a structured, machine-readable format that allows data subjects to transfer their PD to another controller without hindrance.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105123,7 +108054,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -105131,7 +108063,7 @@ "title": "Personal Data (PD) Exports", "family": "PRI", "description": "Mechanisms exist to export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request.", - "scf_question": "Does the organization process an export of a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request?", + "scf_question": "Does the organization export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -105144,7 +108076,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105185,7 +108117,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -105206,7 +108139,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to utilize reasonable consumer expectations to verify a data subject's identity, prior to taking action to disclose, share, correct, amend and/or delete Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105247,7 +108180,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -105271,9 +108205,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to disclose Personal Data (PD) to third-parties only for the purposes identified in the data privacy notice and with the implicit or explicit consent of the data subject.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to disclose Personal Data (PD) to third-parties only for the purposes identified in the data privacy notice and with the implicit or explicit consent of the data subject. ", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105330,7 +108264,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -105354,9 +108289,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include data privacy requirements in contracts and other acquisition-related documents that establish data privacy roles and responsibilities for contractors and service providers.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include data privacy requirements in contracts and other acquisition-related documents that establish data privacy roles and responsibilities for contractors and service providers. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105420,7 +108355,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -105444,9 +108380,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to clearly define and communicate the organization's role in processing Personal Data (PD) in the data processing ecosystem.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to clearly define and communicate the organization's role in processing Personal Data (PD) in the data processing ecosystem. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105505,7 +108441,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -105526,7 +108463,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to inform applicable third-parties of any modification, deletion or other change that affects shared Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105584,15 +108521,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRI-07.4", - "title": "Reject Unauthenticated or Untrustworthy Disclosure Requests", + "title": "Disclosure Request Rejections", "family": "PRI", - "description": "Mechanisms exist to reject unauthenticated, or untrustworthy, disclosure requests.", - "scf_question": "Does the organization reject unauthenticated, or untrustworthy, disclosure requests?", + "description": "Mechanisms exist to reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful.", + "scf_question": "Does the organization reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -105605,9 +108543,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject unauthenticated, or untrustworthy, disclosure requests.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105650,15 +108588,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control\n- renamed control" }, { "control_id": "PRI-07.5", "title": "Justification To Reject Disclosure Requests", "family": "PRI", - "description": "Mechanisms exist to reject data subject access requests that are categorized as:\n(1) Harassing; \n(2) Repetitive; or\n(3) Fraudulent.", - "scf_question": "Does the organization reject data subject access requests that are categorized as:\n (1) Harassing; \n (2) Repetitive; or\n (3) Fraudulent?", + "description": "Mechanisms exist to document justifiable reasons for rejecting a data subject's access request for disclosure when the request is:\n(1) Harassing;\n(2) Repetitive;\n(3) Fraudulent;\n(4) Unjustified; and/or\n(5) Unlawful.", + "scf_question": "Does the organization document justifiable reasons for rejecting a data subject's access request for disclosure when the request is:\n(1) Harassing;\n(2) Repetitive;\n(3) Fraudulent;\n(4) Unjustified; and/or\n(5) Unlawful?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -105671,7 +108611,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject data subject access requests that are categorized as:\n(1) Harassing; \n(2) Repetitive; or\n(3) Fraudulent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105716,8 +108656,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control" }, { "control_id": "PRI-08", @@ -105737,9 +108679,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to conduct testing, training and monitoring activities for Personal Data (PD) controls.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to conduct testing, training and monitoring activities for Personal Data (PD) controls.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105804,16 +108746,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "PRI-09", "title": "Personal Data (PD) Lineage", "family": "PRI", "description": "Mechanisms exist to maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD.", - "scf_question": "Does the organization document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD?", + "scf_question": "Does the organization maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -105826,7 +108768,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -105869,15 +108811,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRI-10", "title": "Data Quality Management", "family": "PRI", - "description": "Mechanisms exist to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle.", - "scf_question": "Does the organization manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle?", + "description": "Mechanisms exist to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive and/or regulated data across the information lifecycle.", + "scf_question": "Does the organization manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive and/or regulated data across the information lifecycle?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -105890,7 +108833,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105952,7 +108895,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -105973,7 +108917,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically support the evaluation of data quality across the information lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106018,7 +108962,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106039,7 +108984,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to evaluate its analytical processes for potential bias.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106083,15 +109028,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRI-11", "title": "Data Tagging", "family": "PRI", - "description": "Mechanisms exist to issue data modeling guidelines to support tagging of sensitive/regulated data.", - "scf_question": "Does the organization issue data modeling guidelines to support tagging of sensitive/regulated data?", + "description": "Mechanisms exist to issue data modeling guidelines to support tagging of sensitive and/or regulated data.", + "scf_question": "Does the organization issue data modeling guidelines to support tagging of sensitive and/or regulated data?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -106104,7 +109050,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to issue data modeling guidelines to support tagging of sensitive/regulated data.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -106148,7 +109094,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106215,7 +109162,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106236,7 +109184,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to enable data subjects to update their Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106274,7 +109222,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106295,7 +109244,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to establish a written charter for a Data Management Board (DMB) and assigned organization-defined roles to the DMB.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106357,7 +109306,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106378,7 +109328,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to document Personal Data (PD) processing activities that covers collection, receiving, processing, storage, transmission, sharing, updating and/or disposal actions with sufficient detail to demonstrate conformity with applicable statutory, regulatory and contractual requirements.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -106463,7 +109413,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106486,7 +109437,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with an accounting of disclosures of their Personal Data (PD) controlled by:\n(1) The organization; and/or\n(2) Relevant third-parties that their PD was shared with.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -106548,7 +109499,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106569,7 +109521,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of applicable legal requests to disclose Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106613,7 +109565,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106636,7 +109589,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to register as a data controller and/or data processor, including registering databases containing Personal Data (PD) with the appropriate Data Authority, when necessary.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -106682,7 +109635,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106703,7 +109657,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to constrain the supply of physical and/or digital activity logs to the host government that can directly lead to contravention of the Universal Declaration of Human Rights (UDHR), as well as other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106748,7 +109702,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106769,7 +109724,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Communications with data subjects is designed to be readily accessible and written in a manner that is concise, unambiguous and understandable by a reasonable person.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to craft disclosures and communications to data subjects in a manner that is concise, unambiguous and understandable by a reasonable person.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106813,7 +109768,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106834,7 +109790,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a conspicuous link to the organization's data privacy notice on all consumer-facing websites and mobile applications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106891,7 +109847,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106912,7 +109869,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with a Notice of Financial Incentive that explains the material terms of a financial incentive, price or service difference so the data subject can make an informed decision about whether to participate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106969,7 +109926,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -106990,7 +109948,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain records of data subject requests and responses in accordance with an established documentation retention schedule that adheres to applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107047,7 +110005,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107068,7 +110027,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to collect metrics associated with data subject requests and responses.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107125,7 +110084,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107146,7 +110106,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publicly disclose applicable data subject communications metrics, as required by statutory and/or regulatory obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107205,7 +110165,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107226,7 +110187,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to receive and process data controller communications pertaining to:\n(1) Receiving and responding to data subject requests;\n(2) Updating/correcting Personal Data (PD); \n(3) Accounting for disclosures of PD; and\n(4) Accounting for PD that is stored, processed and/or transmitted on behalf of the data controller.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107298,7 +110259,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107319,7 +110281,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data subject actions utilizing Automated Decision-Making Technology (ADMT) where computation replaces, or substantially replaces, human decisionmaking, conforms with all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107379,7 +110341,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107400,7 +110363,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of their rights through a pre-use notice when their Personal Data (PD) will be processed by an Automated Decision-Making Technology (ADMT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107460,7 +110423,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107481,7 +110445,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide concise, unambiguous and understandable instructions on how data subjects can opt-out of Automated Decision-Making Technology (ADMT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107541,7 +110505,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107562,7 +110527,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with sufficient details of the logic and parameters used by Automated Decision-Making Technology (ADMT) to process the Personal Data (PD) to generate an output with respect to the data subject.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107622,7 +110587,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107643,7 +110609,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data brokers that collect Personal Data (PD) from a source other than directly from the data subject adhere to all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107702,7 +110668,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107723,9 +110690,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a notification to data subjects within the data privacy notice of:\n(1) Their right to direct an organization that sells or shares their Personal Data (PD) to stop selling or sharing their PD; and\n(2) The methods available to exercise that right.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a notification to data subjects within the data privacy notice of:\n(1) Their right to direct an organization that sells or shares their Personal Data (PD) to stop selling or sharing their PD; and\n(2) The methods available to exercise that right. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -107782,7 +110749,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -107803,7 +110771,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish conspicuous links for data subjects to exercise their rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107862,15 +110830,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRI-21.2", - "title": "Alternative Out-Out Link", + "title": "Alternative Opt-Out Link", "family": "PRI", - "description": "Mechanisms exist to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", - "scf_question": "Does the organization publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD?", + "description": "Mechanisms exist to publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD.", + "scf_question": "Does the organization publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -107885,7 +110854,7 @@ "0": "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.", "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.\nMechanisms exist to publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -107942,8 +110911,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control\n- renamed control" }, { "control_id": "PRM-01", @@ -108046,9 +111017,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "PRM-01.1", @@ -108070,7 +111041,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to establish a:\n(1) Strategic security, compliance and resilience-specific business plan; and \n(2) Set of objectives to achieve that plan.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -108134,9 +111105,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "PRM-01.2", @@ -108219,7 +111190,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -108244,7 +111216,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.\n▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to address all capital planning and investment requests, including the resources needed to implement the Security, Compliance & Resilience Program (SCRP) and document all exceptions to this requirement.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to address all capital planning and investment requests, including the resources needed to implement the Security, Compliance & Resilience Program (SCRP) and document all exceptions to this requirement. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108306,16 +111278,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "PRM-02.1", "title": "Prioritization To Address Evolving Risks & Threats", "family": "PRM", "description": "Mechanisms exist to integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize the organization's exposure to evolving risks and threats.", - "scf_question": "Does the organization integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize the organization's exposure to evolving risks and threats?", + "scf_question": "Does the organization integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize its exposure to evolving risks and threats?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -108387,7 +111359,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -108477,15 +111450,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "PRM-04", "title": "Security, Compliance & Resilience In Project Management", "family": "PRM", - "description": "Mechanisms exist 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.", - "scf_question": "Does the organization 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?", + "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.", + "scf_question": "Does the organization 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?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -108594,16 +111568,17 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed" + "errata": "- wordsmithed control" }, { "control_id": "PRM-05", "title": "Security, Compliance & Resilience Requirements Definition", "family": "PRM", - "description": "Mechanisms exist to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC).", - "scf_question": "Does the organization identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC)?", + "description": "Mechanisms exist to proactively govern Technology Assets, Applications and/or Services (TAAS) by:\n(1) Defining technical security, compliance and resilience requirements; and\n(2) Performing a criticality analysis at predefined decision points in the Secure Development Life Cycle (SDLC).", + "scf_question": "Does the organization proactively govern Technology Assets, Applications and/or Services (TAAS) by:\n(1) Defining technical security, compliance and resilience requirements; and\n(2) Performing a criticality analysis at predefined decision points in the Secure Development Life Cycle (SDLC)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -108621,7 +111596,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC). ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108695,9 +111670,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed" + "errata": "- wordsmithed control" }, { "control_id": "PRM-06", @@ -108781,9 +111757,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "PRM-07", @@ -108805,9 +111781,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108902,7 +111878,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -108925,7 +111902,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to manage the organizational knowledge of the security, compliance and resilience staff.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to manage the organizational knowledge of the security, compliance and resilience staff.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108999,50 +111976,3571 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "QTS-01", + "title": "Quantum Risk Governance", + "family": "QTS", + "description": "Mechanisms exist to establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "scf_question": "Does the organization establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-01", + "E-QTS-02" ], - "errata": "- wordsmithed" + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Awareness of NIST PQC standards (https://csrc.nist.gov/pqc)\n∙ Note: Formal quantum risk governance may not be cost-effective at this size; monitor NIST guidance", + "small": "∙ Designate a named lead responsible for tracking PQC developments\n∙ NIST Post-Quantum Cryptography standards awareness (https://csrc.nist.gov/pqc)", + "medium": "∙ Designated quantum migration lead within CISO function\n∙ NIST PQC standards alignment\n∙ Include quantum risk in enterprise risk register", + "large": "∙ Executive-sponsored quantum risk governance structure\n∙ Named migration lead with defined authority\n∙ NIST PQC and NSA CNSA 2.0 alignment\n∙ Quantum risk as standing agenda item in executive meetings", + "enterprise": "∙ Board-level quantum risk governance structure\n∙ NIST PQC standards and NSA CNSA 2.0 alignment\n∙ Dedicated PQC migration program team\n∙ Quantum risk integrated into enterprise risk management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" }, { - "control_id": "RSK-01", - "title": "Risk Management Program", - "family": "RSK", - "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls.", - "scf_question": "Does the organization facilitate the implementation of strategic, operational and tactical risk management controls?", - "relative_weight": 10, + "control_id": "QTS-01.1", + "title": "Quantum Security Policy", + "family": "QTS", + "description": "Mechanisms exist to establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "scf_question": "Does the organization establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ - "E-RSK-01" + "E-GOV-08" ], "pptdf": "Process", - "nist_csf_function": "Govern", + "nist_csf_function": "Protect", "scrm_focus": { "strategic": true, "operational": true, - "tactical": true + "tactical": false }, "maturity": { "0": "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.", - "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", - "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to facilitate the implementation of strategic, operational and tactical risk management controls.", - "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "SCRMS", - "CORE AI Model Deployment", - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Reference NIST PQC standards in cryptography policy\n∙ Note: Standalone quantum security policy may not be required at this size", + "small": "∙ Addendum to existing cryptography policy covering quantum risks\n∙ NIST PQC reference (https://csrc.nist.gov/pqc)", + "medium": "∙ Formal quantum security policy\n∙ Annual review cycle aligned to NIST PQC updates\n∙ Integration with cryptography standard", + "large": "∙ Standalone quantum security policy with executive approval\n∙ Annual review and update cycle\n∙ Alignment to NIST PQC, NSA CNSA 2.0 and CISA PQC guidance", + "enterprise": "∙ Enterprise quantum security policy with board endorsement\n∙ Alignment to NIST, NSA, CISA, and applicable regulatory guidance\n∙ Integration with security policy framework" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-01.2", + "title": "Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization", + "family": "QTS", + "description": "Mechanisms exist to classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "scf_question": "Does the organization classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-03" ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)", - "small": "∙ Risk Management Program (RMP)", - "medium": "∙ Risk Management Program (RMP)", - "large": "∙ Risk Management Program (RMP)", - "enterprise": "∙ Risk Management Program (RMP)" + "small": "∙ Identify data with long-term confidentiality requirements (e.g., legal, financial, health records)\n∙ Flag for priority PQC protection", + "medium": "∙ Data classification extended to include confidentiality shelf-life dimension\n∙ Prioritize PQC migration for long-lived sensitive data", + "large": "∙ Formal data shelf-life classification taxonomy\n∙ Integration with data catalog and PQC migration prioritization\n∙ Policy-driven PQC protection for long-lived data", + "enterprise": "∙ Automated data shelf-life classification\n∙ Integration with enterprise data catalog and PQC migration roadmap\n∙ Continuous monitoring of long-lived data for PQC readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-01.3", + "title": "Long-Lived Data Identification", + "family": "QTS", + "description": "Mechanisms exist to identify data with long-lived confidentiality protection requirements.", + "scf_question": "Does the organization identify data with long-lived confidentiality protection requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-03" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to identify data with long-lived confidentiality protection requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Review data retention schedules to identify long-lived sensitive records", + "medium": "∙ Data discovery tools to identify long-lived sensitive data\n∙ Data retention policy integration\n∙ Tag long-lived data in data catalog", + "large": "∙ Automated long-lived data identification via data discovery tools\n∙ Integration with DLP and data catalog\n∙ PQC priority mapping for identified data", + "enterprise": "∙ Enterprise data discovery and classification platform\n∙ Automated long-lived data tagging and PQC risk mapping\n∙ Continuous monitoring of data with long confidentiality requirements" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-01.4", + "title": "Harvest Now, Decrypt Later (HNDL) Mitigation", + "family": "QTS", + "description": "Mechanisms exist to mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control.", + "scf_question": "Does the organization mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-09" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Ensure TLS 1.3 is enforced for sensitive data in transit\n∙ Note: Full HNDL mitigation via ZTNA is typically not feasible at this size", + "small": "∙ Enforce TLS 1.3 for all sensitive communications\n∙ Minimize external exposure of long-lived sensitive data", + "medium": "∙ TLS 1.3 enforcement across all external-facing services\n∙ Data access minimization practices\n∙ Zero Trust Network Architecture (ZTNA) planning", + "large": "∙ Zero Trust Network Architecture (ZTNA) implementation\n∙ TLS 1.3 enforcement with forward secrecy\n∙ Identity-based access controls for sensitive data\n∙ Data microsegmentation", + "enterprise": "∙ Enterprise ZTNA platform (e.g., Zscaler, Netskope, Palo Alto Prisma Access)\n∙ Continuous authentication enforcement\n∙ Data microsegmentation with identity-aware access\n∙ HNDL risk monitoring and response program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-02", + "title": "Cryptographic Agility Risk Assessment (CARA)", + "family": "QTS", + "description": "Mechanisms exist to perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact.", + "scf_question": "Does the organization perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-06" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Inventory of cryptographic algorithms in use\n∙ Identification of quantum-vulnerable algorithms (RSA, ECDSA, DH)", + "medium": "∙ Structured CARA aligned to NIST guidance\n∙ Asset-level mapping of cryptographic algorithm use\n∙ Prioritization by business impact", + "large": "∙ Formal CARA process aligned to NIST IR 8547 or equivalent methodology\n∙ Integration with risk register and PQC migration planning", + "enterprise": "∙ Enterprise CARA program with automated cryptographic discovery\n∙ NIST IR 8547 methodology implementation\n∙ Integration with GRC platform and PQC migration roadmap" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-02.1", + "title": "Cryptographic Exception Register", + "family": "QTS", + "description": "Mechanisms exist to govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date.", + "scf_question": "Does the organization govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-07" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Simple exception register for known quantum-vulnerable algorithm uses", + "medium": "∙ Cryptographic exception register with owner, compensating controls, and remediation dates\n∙ Integration with risk register", + "large": "∙ Formal cryptographic exception register\n∙ GRC platform integration\n∙ Regular review and escalation process for aged exceptions", + "enterprise": "∙ Enterprise cryptographic exception register within GRC platform\n∙ Automated exception tracking and escalation\n∙ Integration with PQC migration roadmap and compliance reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-02.2", + "title": "Compensating Controls for Quantum-Vulnerable Systems", + "family": "QTS", + "description": "Mechanisms exist to implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "scf_question": "Does the organization implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Network isolation of legacy systems using quantum-vulnerable algorithms\n∙ Shorten certificate validity periods", + "small": "∙ Network segmentation of quantum-vulnerable systems\n∙ Reduce key lifetimes for quantum-vulnerable certificates", + "medium": "∙ Network segmentation and additional authentication for quantum-vulnerable systems\n∙ Shortened key validity periods\n∙ Out-of-band key transport where applicable", + "large": "∙ Network micro-segmentation of quantum-vulnerable systems\n∙ Shortened key lifetimes and certificate validity periods\n∙ Pre-shared key (PSK) layers on quantum-vulnerable links\n∙ Data minimization on quantum-vulnerable paths", + "enterprise": "∙ Automated micro-segmentation of quantum-vulnerable systems\n∙ Enterprise PSK and data minimization controls\n∙ Continuous monitoring of quantum-vulnerable system exposure\n∙ Integration with PQC migration prioritization" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-02.3", + "title": "Crypto Agility Maturity Assessment", + "family": "QTS", + "description": "Mechanisms exist to measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "scf_question": "Does the organization measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Self-assessment against basic cryptographic agility criteria\n∙ NIST PQC readiness checklist", + "medium": "∙ Crypto agility maturity assessment against defined criteria\n∙ NIST or CISA PQC maturity model\n∙ Integration with annual security assessments", + "large": "∙ Formal crypto agility maturity assessment using NIST or CISA PQC maturity framework\n∙ Annual assessment with improvement roadmap", + "enterprise": "∙ Enterprise crypto agility maturity program\n∙ Third-party validated maturity assessments\n∙ Continuous maturity monitoring via GRC platform\n∙ Board-level reporting on crypto agility progress" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-03", + "title": "Post-Quantum Cryptography Agility Plan (PSCAP)", + "family": "QTS", + "description": "Mechanisms exist to develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms.", + "scf_question": "Does the organization develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Basic PQC transition roadmap aligned to NIST PQC standards\n∙ NIST PQCAP guidance (https://csrc.nist.gov/pqc)", + "medium": "∙ Documented PQCAP aligned to NIST standards\n∙ Risk-prioritized migration roadmap\n∙ Integration with enterprise risk management", + "large": "∙ Formal PQCAP with executive sponsorship\n∙ Risk-prioritized migration with milestones\n∙ NIST PQC and NSA CNSA 2.0 alignment\n∙ Annual plan refresh", + "enterprise": "∙ Enterprise PQCAP with board visibility\n∙ Dedicated PQC program office\n∙ NIST, NSA CNSA 2.0, and CISA PQC guidance alignment\n∙ Integration with enterprise architecture and GRC" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-03.1", + "title": "Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support", + "family": "QTS", + "description": "Mechanisms exist to allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period.", + "scf_question": "Does the organization allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-11", + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor TLS library vendor support for PQC/hybrid modes\n∙ Plan transition for highest-risk systems first", + "medium": "∙ PQC algorithm support assessment for key systems\n∙ Hybrid cryptography pilot for critical services\n∙ Vendor roadmap review for PQC support", + "large": "∙ Hybrid cryptography deployment for critical services\n∙ TLS 1.3 with hybrid PQC key exchange pilot\n∙ Legacy system migration planning and resource allocation", + "enterprise": "∙ Enterprise hybrid cryptography deployment program\n∙ FIPS 140-3 validated PQC module adoption\n∙ Hybrid mode support across all external-facing services\n∙ Automated legacy system discovery and migration tracking" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-03.2", + "title": "Post-Quantum Cryptography (PQC) Migration Progress Oversight", + "family": "QTS", + "description": "Mechanisms exist to establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership.", + "scf_question": "Does the organization establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Note: Typically not required at this size; document any PQC migration progress informally", + "medium": "∙ PQC migration progress metrics\n∙ Inclusion in security program status reports", + "large": "∙ Executive dashboard for PQC migration progress\n∙ Milestone-based reporting aligned to PQCAP\n∙ Regular reporting to security leadership", + "enterprise": "∙ Board-level PQC migration progress reporting\n∙ Automated migration tracking in GRC platform\n∙ KPIs aligned to PQCAP milestones\n∙ Regulatory compliance reporting on PQC readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-03.3", + "title": "Post-Quantum Cryptography (PQC) Supply Chain Visibility", + "family": "QTS", + "description": "Mechanisms exist to require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "scf_question": "Does the organization require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04", + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Request PQC support roadmaps from key technology vendors\n∙ Include PQC readiness in vendor RFPs", + "medium": "∙ Vendor PQC readiness assessments as part of TPRM\n∙ Contractual requirements for PQC roadmap disclosure\n∙ Vendor questionnaires on quantum readiness", + "large": "∙ Formal vendor PQC disclosure requirements\n∙ PQC readiness as part of third-party risk assessments\n∙ Vendor roadmap tracking for critical suppliers", + "enterprise": "∙ Enterprise vendor PQC supply chain program\n∙ Automated vendor PQC tracking in TPRM platform\n∙ Contractual PQC disclosure requirements for all critical vendors\n∙ Regular supply chain quantum risk reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-03.4", + "title": "Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements", + "family": "QTS", + "description": "Mechanisms exist to require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "scf_question": "Does the organization require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-CPL-01" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "medium": "∙ Include PQC flow-down requirements in new vendor contracts\n∙ Reference NIST PQC standards in contract language", + "large": "∙ Formal PQC flow-down contract requirements\n∙ Supplier compliance verification\n∙ Integration with third-party risk management", + "enterprise": "∙ Enterprise PQC flow-down program\n∙ Automated contract requirement tracking\n∙ Subcontractor PQC compliance monitoring\n∙ Integration with supply chain risk management platform" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-04", + "title": "Post-Quantum Cryptography (PQC) Discovery & Visibility", + "family": "QTS", + "description": "Mechanisms exist to gain situational awareness into the organization’s current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques.", + "scf_question": "Does the organization gain situational awareness into its current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to gain situational awareness into the organization’s current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Manual cryptographic algorithm inventory\n∙ Free scanning tools for common quantum-vulnerable implementations", + "medium": "∙ Automated cryptographic discovery tools\n∙ Cryptographic inventory as part of vulnerability management\n∙ NIST guidance on cryptographic discovery (https://csrc.nist.gov/pqc)", + "large": "∙ Automated cryptographic discovery and inventory platform\n∙ Integration with asset management and vulnerability scanning\n∙ Regular cryptographic posture reporting", + "enterprise": "∙ Enterprise cryptographic discovery platform\n∙ Continuous cryptographic inventory maintenance\n∙ Integration with GRC, asset management, and SIEM\n∙ Automated quantum exposure reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-04.1", + "title": "Post-Quantum Cryptography (PQC) Asset Inventory", + "family": "QTS", + "description": "Mechanisms exist to maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "scf_question": "Does the organization maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Spreadsheet-based cryptographic asset inventory\n∙ Document algorithms, key lengths, and associated systems", + "medium": "∙ Structured cryptographic asset inventory\n∙ FIPS validation status tracking\n∙ Integration with overall asset inventory", + "large": "∙ Formal cryptographic asset inventory with automated updates\n∙ FIPS 140-3 validation tracking\n∙ Integration with vulnerability management and asset management", + "enterprise": "∙ Enterprise cryptographic asset inventory platform\n∙ Automated discovery and inventory maintenance\n∙ FIPS 140-3 validation status integration\n∙ Continuous inventory accuracy monitoring" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-04.2", + "title": "Cryptographic Bill of Materials (CBOM)", + "family": "QTS", + "description": "Mechanisms exist to develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing the organization's cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols.", + "scf_question": "Does the organization develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing its cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-05" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing the organization's cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "medium": "∙ Software Composition Analysis (SCA) tools to identify cryptographic library usage\n∙ Manual CBOM for critical applications", + "large": "∙ SCA platform with cryptographic library identification\n∙ CBOM generation for critical systems\n∙ Integration with SBOM processes", + "enterprise": "∙ Enterprise CBOM generation platform\n∙ Integration with SCA and SBOM tooling\n∙ Automated cryptographic dependency tracking\n∙ CBOM as input to PQC migration prioritization" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-04.3", + "title": "Post-Quantum Cryptography Exposure", + "family": "QTS", + "description": "Mechanisms exist to maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "scf_question": "Does the organization maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-10" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Identify systems using quantum-vulnerable public key algorithms (RSA, ECDSA, DH)\n∙ Prioritize based on data sensitivity", + "medium": "∙ Inventory of systems with PQC exposure\n∙ Risk-based prioritization of exposed systems\n∙ Integration with vulnerability management", + "large": "∙ Formal PQC exposure inventory\n∙ Automated scanning for quantum-vulnerable algorithm use\n∙ Risk-prioritized remediation planning", + "enterprise": "∙ Continuous PQC exposure monitoring\n∙ Enterprise scanning for quantum-vulnerable implementations\n∙ Automated risk prioritization and remediation tracking\n∙ Board-level PQC exposure reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-05", + "title": "Quantum Security Awareness", + "family": "QTS", + "description": "Mechanisms exist to deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles.", + "scf_question": "Does the organization deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-SAT-05" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Include quantum threat awareness in annual security training\n∙ NIST PQC awareness resources (https://csrc.nist.gov/pqc)", + "medium": "∙ Differentiated quantum security awareness content by role\n∙ General workforce awareness module\n∙ Technical team PQC training", + "large": "∙ Role-specific quantum security awareness program (workforce, technical, leadership)\n∙ Integration with annual security awareness platform", + "enterprise": "∙ Enterprise quantum security awareness program\n∙ Differentiated content for workforce, technical, and leadership roles\n∙ Annual training refresh aligned to NIST and regulatory updates\n∙ Integration with Learning Management System (LMS)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-05.1", + "title": "Quantum Threat Intelligence Monitoring", + "family": "QTS", + "description": "Mechanisms exist to maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists.", + "scf_question": "Does the organization maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-10", + "E-THR-03" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subscribe to NIST and CISA PQC update notifications (https://csrc.nist.gov/pqc)", + "small": "∙ NIST and CISA PQC update subscriptions\n∙ Relevant industry group newsletters or alerts", + "medium": "∙ Dedicated quantum threat intelligence monitoring\n∙ NIST, CISA, and NSA PQC guidance tracking\n∙ Industry-specific quantum security working groups", + "large": "∙ Quantum threat intelligence function within threat intelligence program\n∙ Monitoring of cryptanalytic advances and quantum computing milestones\n∙ NIST algorithm update tracking", + "enterprise": "∙ Dedicated quantum threat intelligence capability\n∙ Monitoring of academic, regulatory, and vendor quantum developments\n∙ Integration with enterprise threat intelligence platform\n∙ Regular quantum threat briefings to leadership" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-05.2", + "title": "Collaboration & Information Sharing", + "family": "QTS", + "description": "Mechanisms exist to ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk.", + "scf_question": "Does the organization ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor outputs from sector-specific quantum security working groups\n∙ CISA and NIST information-sharing resources", + "medium": "∙ Participation in sector-appropriate quantum security working groups\n∙ ISAC membership where relevant\n∙ CISA PQC working group engagement", + "large": "∙ Active participation in quantum security forums and ISACs\n∙ NIST PQC working group engagement\n∙ Cross-sector information sharing on quantum threats", + "enterprise": "∙ Enterprise participation in quantum security forums\n∙ ISAC and government information sharing partnerships\n∙ Active contribution to quantum security standards development\n∙ Public-private partnership engagement on quantum readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06", + "title": "Crypto-Agility Architecture", + "family": "QTS", + "description": "Mechanisms exist to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "scf_question": "Does the organization validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Use cloud-native cryptographic services with configurable algorithm support\n∙ Avoid hardcoded cryptographic algorithm dependencies", + "medium": "∙ Design systems for cryptographic algorithm replaceability\n∙ Crypto-agility requirements in architecture reviews\n∙ Abstraction of cryptographic operations from application logic", + "large": "∙ Crypto-agility architecture validation in design reviews\n∙ Cryptographic abstraction layer requirements\n∙ Support for PQC key and signature sizes in protocols and libraries", + "enterprise": "∙ Enterprise crypto-agility architecture program\n∙ Formal agility validation across protocols, libraries and hardware\n∙ Cryptographic abstraction APIs enforced organization-wide\n∙ Automated architecture compliance checking" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.1", + "title": "Entropy Source & Random Bit Generation", + "family": "QTS", + "description": "Mechanisms exist to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation.", + "scf_question": "Does the organization use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use OS and cloud provider cryptographically secure random number generators\n∙ Avoid custom entropy implementations", + "small": "∙ Cryptographically secure PRNG from OS or validated cryptographic libraries\n∙ NIST SP 800-90B guidance (https://csrc.nist.gov)", + "medium": "∙ FIPS 140-3 validated entropy sources\n∙ Hardware Security Module (HSM) with validated RNG\n∙ NIST SP 800-90B compliance", + "large": "∙ FIPS 140-3 validated HSMs for key generation\n∙ Validated entropy sources aligned to NIST SP 800-90B\n∙ Enterprise key management platform", + "enterprise": "∙ Enterprise HSM infrastructure with FIPS 140-3 validated entropy\n∙ Quantum random number generators (QRNG) for enhanced entropy\n∙ Centralized key management platform\n∙ Continuous entropy source validation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.2", + "title": "Stateful Hash-Based Signatures for Firmware & Code Signing", + "family": "QTS", + "description": "Mechanisms exist to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases.", + "scf_question": "Does the organization enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use vendor-managed firmware signing", + "small": "∙ Use vendor-managed firmware signing", + "medium": "∙ Review code signing infrastructure for quantum vulnerability\n∙ Plan migration to hash-based signatures for critical firmware\n∙ NIST SP 800-208 guidance (https://csrc.nist.gov)", + "large": "∙ Hash-based signature scheme deployment for firmware signing\n∙ NIST SP 800-208 compliance for firmware and code signing\n∙ State-management controls to prevent key reuse", + "enterprise": "∙ Enterprise hash-based signature infrastructure for firmware and code signing\n∙ NIST SP 800-208 compliant implementation\n∙ Automated state management to prevent one-time key reuse\n∙ HSM-backed hash-based key management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.3", + "title": "Approved Post-Quantum Cryptography (PQC) Algorithm Use", + "family": "QTS", + "description": "Mechanisms exist to define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).", + "scf_question": "Does the organization define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Monitor NIST PQC algorithm approvals (https://csrc.nist.gov/pqc)\n∙ Adopt approved PQC algorithms as available in consumed services", + "small": "∙ Reference NIST PQC approved algorithms in cryptography policy\n∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)", + "medium": "∙ Define approved PQC algorithm list\n∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) adoption\n∙ FIPS 140-3 validated module requirements", + "large": "∙ Formal approved PQC algorithm standard\n∙ NIST FIPS 203/204/205 compliant implementations\n∙ Required validation levels in cryptography policy\n∙ Algorithm approval workflow for exceptions", + "enterprise": "∙ Enterprise approved PQC algorithm governance\n∙ NIST FIPS 203/204/205 and CNSA 2.0 alignment\n∙ Automated algorithm compliance enforcement\n∙ Integration with cryptographic exception register" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.4", + "title": "Post-Quantum Cryptography (PQC) Validation Requirements", + "family": "QTS", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use cloud provider services with FIPS 140-3 validated cryptographic modules\n∙ Prefer managed services over self-hosted cryptography", + "small": "∙ Use FIPS 140-3 validated cryptographic libraries and services\n∙ NIST CMVP validation list (https://csrc.nist.gov/projects/cryptographic-module-validation-program)", + "medium": "∙ FIPS 140-3 validated module requirements for cryptographic operations\n∙ Track NIST CMVP PQC validation certificates\n∙ Policy mandate for validated modules where applicable", + "large": "∙ Enterprise policy requiring FIPS 140-3 validated modules\n∙ Validation tracking in cryptographic asset inventory\n∙ HSM with FIPS 140-3 validation for key management", + "enterprise": "∙ Enterprise FIPS 140-3 validation requirement enforcement\n∙ Automated validation status tracking in cryptographic inventory\n∙ HSM infrastructure with FIPS 140-3 Level 3 validation\n∙ Continuous compliance monitoring for cryptographic module validation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.5", + "title": "Deprecated Cryptographic Algorithms", + "family": "QTS", + "description": "Mechanisms exist to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.", + "scf_question": "Does the organization identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Disable RC4, DES, 3DES and MD5 in systems and services\n∙ Enforce TLS 1.2 minimum (disable TLS 1.0/1.1)\n∙ Reference NIST SP 800-131A for deprecated algorithm guidance", + "small": "∙ Deprecated algorithm disablement per NIST SP 800-131A\n∙ TLS 1.2 minimum enforcement\n∙ Retire RSA-1024 and similar weak key sizes", + "medium": "∙ Deprecated algorithm disablement across all systems\n∙ NIST SP 800-131A and SP 800-57 compliance\n∙ Vulnerability scanning for deprecated algorithm detection", + "large": "∙ Formal deprecated algorithm disablement program\n∙ Automated scanning for deprecated cryptographic use\n∙ NIST SP 800-131A compliance tracking", + "enterprise": "∙ Enterprise deprecated algorithm removal program\n∙ Automated detection and alerting for deprecated algorithm use\n∙ NIST SP 800-131A and CNSA 2.0 compliance enforcement\n∙ Continuous monitoring for deprecated algorithm introduction" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.6", + "title": "Post-Quantum Cryptography (PQC) Key Management", + "family": "QTS", + "description": "Mechanisms exist to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources.", + "scf_question": "Does the organization manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Shorten TLS certificate validity periods (e.g., 90-day certificates)\n∙ Let's Encrypt for automated short-lived certificate management (https://letsencrypt.org)", + "small": "∙ 90-day certificate validity enforcement\n∙ Automated certificate lifecycle management\n∙ Let's Encrypt or ACME protocol (https://letsencrypt.org)", + "medium": "∙ Shortened certificate validity periods per PQC guidance\n∙ Certificate lifecycle management platform\n∙ PKI preparation for PQC roots of trust", + "large": "∙ Enterprise certificate lifecycle management with shortened validity periods\n∙ PKI infrastructure preparation for PQC transition\n∙ HSM-backed key generation with quantum-safe entropy", + "enterprise": "∙ Enterprise PKI with PQC-ready architecture\n∙ Automated certificate lifecycle management (e.g., Venafi, Keyfactor)\n∙ HSM infrastructure with quantum-safe entropy sources\n∙ Dual-root hybrid trust model support" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.7", + "title": "Quantum-Safe Public Key Infrastructure (PKI) Transition", + "family": "QTS", + "description": "Mechanisms exist to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.", + "scf_question": "Does the organization transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Rely on cloud provider and CA/Browser Forum quantum-safe transitions", + "small": "∙ Monitor CA/Browser Forum and browser vendor PQC adoption timelines\n∙ Plan reliance on public CA quantum-safe transition", + "medium": "∙ Assess internal PKI for PQC transition readiness\n∙ Evaluate hybrid certificate support in PKI platforms\n∙ Certificate authority PQC roadmap review", + "large": "∙ Internal PKI PQC transition plan\n∙ Hybrid certificate deployment for critical services\n∙ Trust anchor migration planning to quantum-safe algorithms", + "enterprise": "∙ Enterprise quantum-safe PKI transition program\n∙ Hybrid certificate infrastructure deployment\n∙ Trust anchor migration to NIST FIPS 203/204/205 algorithms\n∙ Integration with enterprise certificate lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.8", + "title": "Algorithm Negotiation Integrity", + "family": "QTS", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Enforce TLS 1.3 (includes transcript integrity protection)\n∙ Disable TLS 1.0/1.1 and weak cipher suites", + "small": "∙ TLS 1.3 enforcement\n∙ Disable deprecated cipher suites\n∙ Monitor for TLS downgrade attempts via web application firewall", + "medium": "∙ TLS 1.3 with strong cipher suite enforcement\n∙ Monitoring for algorithm downgrade attempts\n∙ Disallow classical-only cipher suite negotiation where PQC is deployed", + "large": "∙ TLS 1.3 enforcement with integrity-protected handshake\n∙ Algorithm downgrade monitoring and alerting\n∙ Cipher suite allowlisting across enterprise TLS infrastructure", + "enterprise": "∙ Enterprise TLS cipher suite governance with automated enforcement\n∙ Algorithm negotiation integrity monitoring at scale\n∙ Automated detection of downgrade attempts\n∙ Integration with network security monitoring and SIEM" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.9", + "title": "Hybrid / Composite Cryptography", + "family": "QTS", + "description": "Mechanisms exist to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.", + "scf_question": "Does the organization leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor TLS library and browser vendor hybrid PQC support\n∙ Plan adoption of hybrid modes when widely available", + "medium": "∙ Pilot hybrid cryptography for highest-risk external-facing services\n∙ IETF hybrid draft standards monitoring\n∙ Vendor hybrid mode support assessment", + "large": "∙ Hybrid cryptography deployment for critical services\n∙ ECDH + ML-KEM hybrid KEM support\n∙ Hybrid certificate testing and deployment", + "enterprise": "∙ Enterprise hybrid cryptography deployment program\n∙ Hybrid KEM (ECDH + ML-KEM) and hybrid signatures (ECDSA + ML-DSA)\n∙ PKI infrastructure supporting dual-key/dual-certificate models\n∙ Plan for classical algorithm sunset post-PQC confidence" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-06.10", + "title": "Cryptographic Application Programming Interface (API) Abstraction", + "family": "QTS", + "description": "Mechanisms exist to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "scf_question": "Does the organization use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Use established cryptographic libraries with abstraction (e.g., OpenSSL, BouncyCastle)\n∙ Avoid direct algorithm calls; use library-level interfaces", + "medium": "∙ Cryptographic abstraction requirements in development standards\n∙ Use of crypto-agility compatible libraries\n∙ Abstract cryptographic operations from application code", + "large": "∙ Enterprise cryptographic API abstraction standard\n∙ Use of PKCS#11 or equivalent for hardware abstraction\n∙ Crypto abstraction layer in enterprise development frameworks", + "enterprise": "∙ Enterprise cryptographic API abstraction framework\n∙ Universal cryptographic interface standard across all applications\n∙ PKCS#11 and provider-based abstraction architecture\n∙ Automated compliance checking for cryptographic abstraction" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-07", + "title": "Cryptographic Incident Response (Emergency Algorithm Transition)", + "family": "QTS", + "description": "Mechanisms exist to establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios.", + "scf_question": "Does the organization establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-12" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Maintain vendor and CA contacts for certificate revocation emergencies\n∙ Basic plan for replacing compromised certificates", + "medium": "∙ Emergency certificate replacement procedures\n∙ Pre-identified algorithm alternates in security runbook\n∙ Integration with incident response plan", + "large": "∙ Formal cryptographic incident response plan\n∙ Pre-identified algorithm alternates with tested rollback procedures\n∙ Customer/counterparty communication templates\n∙ Integration with enterprise incident response", + "enterprise": "∙ Enterprise cryptographic incident response program\n∙ Tested emergency algorithm transition procedures\n∙ 24/7 incident response capability for cryptographic emergencies\n∙ Regular cryptographic incident response exercises" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "QTS-08", + "title": "PQC Implementation Validation & Interoperability Testing", + "family": "QTS", + "description": "Mechanisms exist to validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions.", + "scf_question": "Does the organization validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Verify PQC implementations using NIST test vectors (https://csrc.nist.gov/pqc)\n∙ Use FIPS 140-3 validated modules where available", + "medium": "∙ PQC implementation testing using NIST test vectors\n∙ Interoperability testing with key counterparties\n∙ FIPS 140-3 validated module requirement", + "large": "∙ Formal PQC implementation validation program\n∙ Interoperability testing with counterparties and successors\n∙ Performance testing for PQC use cases\n∙ Test result documentation", + "enterprise": "∙ Enterprise PQC implementation validation framework\n∙ Automated test vector validation\n∙ Continuous interoperability testing with ecosystem partners\n∙ Third-party validation for critical implementations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain" + }, + { + "control_id": "RSK-01", + "title": "Risk Management Program", + "family": "RSK", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "scf_question": "Does the organization facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) its Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices?", + "relative_weight": 10, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-RSK-01" + ], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to facilitate the implementation of strategic, operational and tactical risk management controls.", + "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "SCRMS", + "CORE AI Model Deployment", + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Risk Management Program (RMP)", + "small": "∙ Risk Management Program (RMP)", + "medium": "∙ Risk Management Program (RMP)", + "large": "∙ Risk Management Program (RMP)", + "enterprise": "∙ Risk Management Program (RMP)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-1", + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control" + }, + { + "control_id": "RSK-01.1", + "title": "Risk Framing", + "family": "RSK", + "description": "Mechanisms exist to identify:\n(1) Assumptions affecting risk assessments, risk response and risk monitoring;\n(2) Constraints affecting risk assessments, risk response and risk monitoring;\n(3) The organizational risk tolerance; and\n(4) Priorities, benefits and trade-offs considered by the organization for managing risk.", + "scf_question": "Does the organization identify:\n (1) Assumptions affecting risk assessments, risk response and risk monitoring;\n (2) Constraints affecting risk assessments, risk response and risk monitoring;\n (3) The organizational risk tolerance; and\n (4) Priorities, benefits and trade-offs considered by the organization for managing risk?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-RSK-01", + "E-RSK-06", + "E-RSK-07", + "E-RSK-08" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify:\n(1) Assumptions affecting risk assessments, risk response and risk monitoring;\n(2) Constraints affecting risk assessments, risk response and risk monitoring;\n(3) The organizational risk tolerance; and\n(4) Priorities, benefits and trade-offs considered by the organization for managing risk.", + "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "SCRMS", + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Risk Management Program (RMP)", + "small": "∙ Risk Management Program (RMP)", + "medium": "∙ Risk Management Program (RMP)", + "large": "∙ Risk Management Program (RMP)", + "enterprise": "∙ Risk Management Program (RMP)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-17", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "RSK-01.2", + "title": "Risk Management Resourcing", + "family": "RSK", + "description": "Mechanisms exist to reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks.", + "scf_question": "Does the organization reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Risk Management Program (RMP)", + "small": "∙ Risk Management Program (RMP)", + "medium": "∙ Risk Management Program (RMP)", + "large": "∙ Risk Management Program (RMP)", + "enterprise": "∙ Risk Management Program (RMP)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-17", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "RSK-01.3", + "title": "Risk Tolerance", + "family": "RSK", + "description": "Mechanisms exist to define organizational risk tolerance, the specified range of acceptable results.", + "scf_question": "Does the organization define organizational risk tolerance, the specified range of acceptable results?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-RSK-06" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk tolerance, the specified range of acceptable results.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "SCRMS", + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance", + "small": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance", + "medium": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance", + "large": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance", + "enterprise": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance" }, "risks": [ "R-AC-1", @@ -109085,7 +115583,6 @@ "R-SC-6" ], "threats": [ - "NT-1", "NT-2", "NT-3", "NT-4", @@ -109105,7 +115602,6 @@ "MT-4", "MT-5", "MT-6", - "MT-7", "MT-8", "MT-9", "MT-11", @@ -109113,46 +115609,37 @@ "MT-13", "MT-14", "MT-15", - "MT-16", "MT-17", - "MT-18", - "MT-19", - "MT-20", - "MT-21", - "MT-22", - "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "RSK-01.1", - "title": "Risk Framing", + "control_id": "RSK-01.4", + "title": "Risk Threshold", "family": "RSK", - "description": "Mechanisms exist to identify:\n(1) Assumptions affecting risk assessments, risk response and risk monitoring;\n(2) Constraints affecting risk assessments, risk response and risk monitoring;\n(3) The organizational risk tolerance; and\n(4) Priorities, benefits and trade-offs considered by the organization for managing risk.", - "scf_question": "Does the organization identify:\n (1) Assumptions affecting risk assessments, risk response and risk monitoring;\n (2) Constraints affecting risk assessments, risk response and risk monitoring;\n (3) The organizational risk tolerance; and\n (4) Priorities, benefits and trade-offs considered by the organization for managing risk?", + "description": "Mechanisms exist to define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted.", + "scf_question": "Does the organization define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ - "E-RSK-01", - "E-RSK-06", - "E-RSK-07", - "E-RSK-08" + "E-RSK-07" ], "pptdf": "Process", "nist_csf_function": "Identify", "scrm_focus": { "strategic": true, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify:\n(1) Assumptions affecting risk assessments, risk response and risk monitoring;\n(2) Constraints affecting risk assessments, risk response and risk monitoring;\n(3) The organizational risk tolerance; and\n(4) Priorities, benefits and trade-offs considered by the organization for managing risk.", - "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ @@ -109163,101 +115650,11 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)", - "small": "∙ Risk Management Program (RMP)", - "medium": "∙ Risk Management Program (RMP)", - "large": "∙ Risk Management Program (RMP)", - "enterprise": "∙ Risk Management Program (RMP)" - }, - "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-BC-5", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-GV-8", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SA-2", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-17", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "RSK-01.2", - "title": "Risk Management Resourcing", - "family": "RSK", - "description": "Mechanisms exist to reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks.", - "scf_question": "Does the organization reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks?", - "relative_weight": 8, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Process", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": true, - "operational": true, - "tactical": false - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)", - "small": "∙ Risk Management Program (RMP)", - "medium": "∙ Risk Management Program (RMP)", - "large": "∙ Risk Management Program (RMP)", - "enterprise": "∙ Risk Management Program (RMP)" + "micro_small": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold", + "small": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold", + "medium": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold", + "large": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold", + "enterprise": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold" }, "risks": [ "R-AC-1", @@ -109329,19 +115726,20 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "RSK-01.3", - "title": "Risk Tolerance", + "control_id": "RSK-01.5", + "title": "Risk Appetite", "family": "RSK", - "description": "Mechanisms exist to define organizational risk tolerance, the specified range of acceptable results.", - "scf_question": "Does the organization define organizational risk tolerance, the specified range of acceptable results?", + "description": "Mechanisms exist to define organizational risk appetite, the degree of uncertainty the organization is willing to accept in anticipation of a reward.", + "scf_question": "Does the organization define organizational risk appetite, the degree of uncertainty the organization is willing to accept in anticipation of a reward?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ - "E-RSK-06" + "E-RSK-08" ], "pptdf": "Process", "nist_csf_function": "Identify", @@ -109352,9 +115750,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk tolerance, the specified range of acceptable results.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk appetite, the degree of uncertainty the organization is willing to accept in anticipation of a reward.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -109442,19 +115840,23 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "RSK-01.4", - "title": "Risk Threshold", + "control_id": "RSK-02", + "title": "Risk-Based Security Categorization", "family": "RSK", - "description": "Mechanisms exist to define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted.", - "scf_question": "Does the organization define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted?", + "description": "Mechanisms exist to categorize Technology Assets, Applications, Services and/or Data (TAASD) in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", + "scf_question": "Does the organization categorize Technology Assets, Applications, Services and/or Data (TAASD) in accordance with applicable laws, regulations and contractual obligations that:\n (1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n (2) Ensure the security categorization decision is reviewed and approved by the asset owner?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ - "E-RSK-07" + "E-RSK-01", + "E-RSK-04", + "E-BCM-08", + "E-TPM-02" ], "pptdf": "Process", "nist_csf_function": "Identify", @@ -109465,25 +115867,24 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to categorize TAASD in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", + "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "SCRMS", "CORE ESP Level 1 Foundational", "CORE ESP Level 2 Critical Infrastructure", "CORE ESP Level 3 Advanced Threats", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold", - "small": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold", - "medium": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold", - "large": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold", - "enterprise": "∙ Risk Management Program (RMP)\n∙ Defined risk threshold" + "micro_small": "∙ Risk Management Program (RMP)", + "small": "∙ Risk Management Program (RMP)", + "medium": "∙ Risk Management Program (RMP)", + "large": "∙ Risk Management Program (RMP)", + "enterprise": "∙ Risk Management Program (RMP)" }, "risks": [ "R-AC-1", @@ -109526,25 +115927,10 @@ "R-SC-6" ], "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", "MT-1", "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", + "MT-7", "MT-8", "MT-9", "MT-11", @@ -109555,48 +115941,49 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "RSK-01.5", - "title": "Risk Appetite", + "control_id": "RSK-02.1", + "title": "Impact-Level Prioritization", "family": "RSK", - "description": "Mechanisms exist to define organizational risk appetite, the degree of uncertainty the organization is willing to accept in anticipation of a reward.", - "scf_question": "Does the organization define organizational risk appetite, the degree of uncertainty the organization is willing to accept in anticipation of a reward?", + "description": "Mechanisms exist to prioritize the impact level for Technology Assets, Applications and/or Services (TAAS) to prevent potential disruptions.", + "scf_question": "Does the organization prioritize the impact level for Technology Assets, Applications and/or Services (TAAS) to prevent potential disruptions?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ - "E-RSK-08" + "E-BCM-08", + "E-RSK-04", + "E-TPM-02" ], "pptdf": "Process", "nist_csf_function": "Identify", "scrm_focus": { "strategic": true, "operational": true, - "tactical": true + "tactical": false }, "maturity": { "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk appetite, the degree of uncertainty the organization is willing to accept in anticipation of a reward.", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to prioritize the impact level for Technology Assets, Applications and/or Services (TAAS) to prevent potential disruptions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "SCRMS", "CORE ESP Level 1 Foundational", "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "CORE ESP Level 3 Advanced Threats" ], "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance", - "small": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance", - "medium": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance", - "large": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance", - "enterprise": "∙ Risk Management Program (RMP)\n∙ Defined risk tolerance" + "micro_small": "∙ Risk Management Program (RMP)", + "small": "∙ Risk Management Program (RMP)", + "medium": "∙ Risk Management Program (RMP)", + "large": "∙ Risk Management Program (RMP)", + "enterprise": "∙ Risk Management Program (RMP)" }, "risks": [ "R-AC-1", @@ -109639,25 +116026,10 @@ "R-SC-6" ], "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", "MT-1", "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", + "MT-7", "MT-8", "MT-9", "MT-11", @@ -109668,42 +116040,43 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "RSK-02", - "title": "Risk-Based Security Categorization", + "control_id": "RSK-03", + "title": "Risk Identification", "family": "RSK", - "description": "Mechanisms exist to categorize Technology Assets, Applications, Services and/or Data (TAASD) in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", - "scf_question": "Does the organization categorize Technology Assets, Applications, Services and/or Data (TAASD) in accordance with applicable laws, regulations and contractual obligations that:\n (1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n (2) Ensure the security categorization decision is reviewed and approved by the asset owner?", + "description": "Mechanisms exist to identify and document risks, both internal and external.", + "scf_question": "Does the organization identify and document risks, both internal and external?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ - "E-RSK-01", - "E-RSK-04", - "E-BCM-08", - "E-TPM-02" + "E-RSK-04" ], "pptdf": "Process", "nist_csf_function": "Identify", "scrm_focus": { - "strategic": true, + "strategic": false, "operational": true, - "tactical": true + "tactical": false }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to categorize TAASD in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and document risks, both internal and external. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ + "SCRMS", + "CORE AI Model Deployment", "CORE ESP Level 1 Foundational", "CORE ESP Level 2 Critical Infrastructure", "CORE ESP Level 3 Advanced Threats", + "CORE Fundamentals", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { @@ -109768,79 +116141,60 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "RSK-02.1", - "title": "Impact-Level Prioritization", + "control_id": "RSK-03.1", + "title": "Risk Catalog", "family": "RSK", - "description": "Mechanisms exist to prioritize the impact level for Technology Assets, Applications and/or Services (TAAS) to prevent potential disruptions.", - "scf_question": "Does the organization prioritize the impact level for Technology Assets, Applications and/or Services (TAAS) to prevent potential disruptions?", - "relative_weight": 9, + "description": "Mechanisms exist to develop and keep current a catalog of applicable risks associated with the organization's business operations and technologies in use.", + "scf_question": "Does the organization develop and keep current a catalog of applicable risks associated with its business operations and technologies in use?", + "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ - "E-BCM-08", - "E-RSK-04", - "E-TPM-02" + "E-RSK-09" ], "pptdf": "Process", - "nist_csf_function": "Identify", + "nist_csf_function": "Protect", "scrm_focus": { "strategic": true, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", - "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to prioritize the impact level for Technology Assets, Applications and/or Services (TAAS) to prevent potential disruptions.", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to develop and keep current a catalog of applicable risks associated with the organization's business operations and technologies in use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ + "SCRMS", "CORE ESP Level 1 Foundational", "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats" + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)", - "small": "∙ Risk Management Program (RMP)", - "medium": "∙ Risk Management Program (RMP)", - "large": "∙ Risk Management Program (RMP)", - "enterprise": "∙ Risk Management Program (RMP)" + "micro_small": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog", + "small": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog", + "medium": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog", + "large": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog", + "enterprise": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog" }, "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", "R-BC-1", "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-BC-5", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", "R-EX-5", - "R-EX-6", - "R-EX-7", "R-GV-1", "R-GV-2", - "R-GV-3", "R-GV-4", "R-GV-5", "R-GV-6", "R-GV-7", - "R-GV-8", - "R-IR-1", - "R-IR-2", - "R-IR-3", "R-IR-4", "R-SA-1", "R-SA-2", @@ -109866,50 +116220,41 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "RSK-03", - "title": "Risk Identification", + "control_id": "RSK-03.2", + "title": "Risk Owner", "family": "RSK", - "description": "Mechanisms exist to identify and document risks, both internal and external.", - "scf_question": "Does the organization identify and document risks, both internal and external?", + "description": "Mechanisms exist to identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks.", + "scf_question": "Does the organization identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks?", "relative_weight": 9, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-RSK-04" - ], + "conformity_cadence": "Quarterly", + "evidence_requests": [], "pptdf": "Process", "nist_csf_function": "Identify", "scrm_focus": { - "strategic": false, + "strategic": true, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and document risks, both internal and external.", - "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "SCRMS", - "CORE AI Model Deployment", - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Fundamentals", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)", - "small": "∙ Risk Management Program (RMP)", - "medium": "∙ Risk Management Program (RMP)", - "large": "∙ Risk Management Program (RMP)", - "enterprise": "∙ Risk Management Program (RMP)" + "micro_small": "∙ Risk register with assigned owner column\n∙ Designated security lead responsible for risk follow-up", + "small": "∙ Risk register with mandatory owner assignment\n∙ Regular risk owner check-ins on remediation progress", + "medium": "∙ Formal risk ownership assignment in risk register\n∙ GRC platform with risk owner workflow\n∙ Management accountability for open risk items", + "large": "∙ GRC platform with risk ownership and accountability workflow\n∙ Executive reporting on risk owner compliance\n∙ Risk owner training and awareness", + "enterprise": "∙ Enterprise GRC platform with risk ownership management\n∙ Automated risk owner escalation and reminders\n∙ Board-level reporting on material risk accountability\n∙ Risk ownership integrated into performance management" }, "risks": [ "R-AC-1", @@ -109966,86 +116311,10 @@ "MT-17", "MT-24", "MT-25", - "MT-27" - ] - }, - { - "control_id": "RSK-03.1", - "title": "Risk Catalog", - "family": "RSK", - "description": "Mechanisms exist to develop and keep current a catalog of applicable risks associated with the organization's business operations and technologies in use.", - "scf_question": "Does the organization develop and keep current a catalog of applicable risks associated with its business operations and technologies in use?", - "relative_weight": 5, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-RSK-09" - ], - "pptdf": "Process", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": true, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", - "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to develop and keep current a catalog of applicable risks associated with the organization's business operations and technologies in use.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "SCRMS", - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "MT-27", + "MT-28" ], - "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog", - "small": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog", - "medium": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog", - "large": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog", - "enterprise": "∙ Risk Management Program (RMP)\n∙ Documented risk catalog" - }, - "risks": [ - "R-BC-1", - "R-BC-2", - "R-EX-5", - "R-GV-1", - "R-GV-2", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-IR-4", - "R-SA-1", - "R-SA-2", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-17", - "MT-24", - "MT-25", - "MT-27" - ] + "errata": "- new control - RMiT" }, { "control_id": "RSK-04", @@ -110144,7 +116413,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -110167,11 +116437,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to maintain a risk register that facilitates monitoring and reporting of risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -110243,7 +116513,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -110264,7 +116535,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to implement a risk assessment methodology to ensure coverage for organizational components relevant for secure, compliant and resilient operations.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -110337,7 +116608,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -110360,7 +116632,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define instances that require a risk assessment to be performed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -110428,7 +116700,8 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ] }, { @@ -110517,7 +116790,8 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ] }, { @@ -110542,7 +116816,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -110615,7 +116889,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -110640,7 +116915,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to remediate risks to an acceptable level.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to remediate risks to an acceptable level. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -110732,7 +117007,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -110755,7 +117031,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure proper risk response actions were performed to remediate findings from security, compliance and/or resilience-related:\n(1) Assessments;\n(2) Audits; and/or\n(3) Incidents.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -110848,9 +117124,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "RSK-06.2", @@ -110873,7 +117149,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and implement compensating countermeasures to reduce risk and exposure to threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -110966,15 +117242,16 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "RSK-06.3", "title": "Risk Treatment Options", "family": "RSK", - "description": "Mechanisms exist to select appropriate risk treatment options, based on applicable risk assessment findings.", - "scf_question": "Does the organization select appropriate risk treatment options, based on applicable risk assessment findings?", + "description": "Mechanisms exist to select appropriate risk treatment options, based on applicable risk assessment findings, including:\n(1) Mitigating the risk to an acceptable level;\n(2) Avoiding the risk (e.g., terminating the project);\n(3) Transferring the risk to a third party (e.g., insurance, service provider, etc.); or\n(4) Accepting the risk.", + "scf_question": "Does the organization select appropriate risk treatment options, based on applicable risk assessment findings, including:\n(1) Mitigating the risk to an acceptable level;\n(2) Avoiding the risk (e.g., terminating the project);\n(3) Transferring the risk to a third party (e.g., insurance, service provider, etc.); or\n(4) Accepting the risk?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -110989,7 +117266,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to select appropriate risk treatment options, based on applicable risk assessment findings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -111074,8 +117351,10 @@ "MT-15", "MT-17", "MT-24", - "MT-25" - ] + "MT-25", + "MT-28" + ], + "errata": "- wordsmithed control" }, { "control_id": "RSK-06.4", @@ -111097,7 +117376,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to formalize a Risk Treatment Plan (RTP) that applicable stakeholders will utilize to remediate identified risks according to a defined timeline.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -111184,9 +117463,9 @@ "MT-15", "MT-17", "MT-24", - "MT-25" - ], - "errata": "- renamed" + "MT-25", + "MT-28" + ] }, { "control_id": "RSK-07", @@ -111208,7 +117487,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -111296,7 +117575,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -111319,7 +117599,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to conduct a Business Impact Analysis (BIA) to identify and assess security, compliance and resilience risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -111407,9 +117687,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "RSK-09", @@ -111532,7 +117812,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -111555,7 +117836,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to periodically assess supply chain risks associated with Technology Assets, Applications and/or Services (TAAS).", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -111654,7 +117935,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -111762,7 +118044,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -111785,7 +118068,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to conduct a Data Protection Impact Assessment (DPIA) on Technology Assets, Applications and/or Services (TAAS) that store, process and/or transmit Personal Data (PD) to identify and remediate reasonably-expected risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -111839,7 +118122,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -111860,7 +118144,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure risk monitoring as an integral part of the continuous monitoring strategy that includes monitoring the effectiveness of security, compliance and resilience controls, compliance and change management.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -111946,9 +118230,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "RSK-12", @@ -111970,7 +118254,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure teams are committed to a culture that considers and communicates technology-related risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -112037,7 +118321,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -112061,9 +118346,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to obtain executive leadership approval for risk management decisions involving material risk.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to obtain executive leadership approval for risk management decisions involving material risk. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -112090,7 +118375,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ] }, { @@ -112113,7 +118399,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to document alternative courses of action to ensure executive leadership is reasonably informed of options to manage material risks, including potential:\n(1) Benefits;\n(2) Drawbacks (including technical limitations);\n(3) Costs; and\n(4) Timelines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -112142,7 +118428,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ] }, { @@ -112196,7 +118483,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ] }, { @@ -112223,7 +118511,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).\n▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of TAAS.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -112305,9 +118593,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SEA-01.1", @@ -112330,7 +118618,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to centrally-manage the organization-wide management and implementation of security, compliance and resilience controls and related processes.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -112420,9 +118708,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SEA-01.2", @@ -112446,7 +118734,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to achieve resilience requirements in normal and adverse situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -112501,45 +118789,124 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "SEA-01.3", + "title": "Resilience Capabilities", + "family": "SEA", + "description": "Mechanisms exist to ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention.", + "scf_question": "Does the organization ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived", + "SCRMS" + ], + "possible_solutions": { + "micro_small": "∙ Document security requirements for any new systems built or purchased", + "small": "∙ Security requirements checklist for systems engineering", + "medium": "∙ Formal security requirements engineering process\n∙ Security integrated into system design", + "large": "∙ Enterprise systems security engineering program\n∙ Security architecture reviews", + "enterprise": "∙ Enterprise systems security engineering program (NIST SP 800-160)\n∙ Architecture review board\n∙ Threat modeling integration" + }, + "risks": [ + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-4", + "R-GV-5", + "R-IR-4" + ], + "threats": [ + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { - "control_id": "SEA-01.3", - "title": "Resilience Capabilities", + "control_id": "SEA-01.4", + "title": "Secure Architecture Principles", "family": "SEA", - "description": "Mechanisms exist to ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention.", - "scf_question": "Does the organization ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention?", - "relative_weight": 5, + "description": "Mechanisms exist to ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture.", + "scf_question": "Does the organization ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], - "pptdf": "Technology", + "pptdf": "Process", "nist_csf_function": "Protect", "scrm_focus": { - "strategic": false, + "strategic": true, "operational": true, "tactical": false }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "Community Derived", - "SCRMS" + "Community Derived" ], "possible_solutions": { - "micro_small": "∙ Document security requirements for any new systems built or purchased", - "small": "∙ Security requirements checklist for systems engineering", - "medium": "∙ Formal security requirements engineering process\n∙ Security integrated into system design", - "large": "∙ Enterprise systems security engineering program\n∙ Security architecture reviews", - "enterprise": "∙ Enterprise systems security engineering program (NIST SP 800-160)\n∙ Architecture review board\n∙ Threat modeling integration" + "micro_small": "∙ Reference NIST CSF for architecture guidance\n∙ Apply basic secure design principles (least privilege, defense-in-depth)", + "small": "∙ NIST CSF and OWASP design principles\n∙ Documented secure design checklist", + "medium": "∙ TOGAF or SABSA-aligned secure architecture principles\n∙ Documented architecture principles standard\n∙ Security architecture review in project lifecycle", + "large": "∙ Enterprise secure architecture principles aligned to TOGAF or SABSA\n∙ Security Architecture Review Board (SARB)\n∙ Architecture principles enforced in project governance", + "enterprise": "∙ Enterprise architecture framework with embedded security principles (TOGAF or SABSA)\n∙ Dedicated security architecture function\n∙ Automated architecture compliance checking\n∙ Board-approved enterprise architecture standards" }, "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", "R-BC-1", "R-BC-2", "R-BC-3", @@ -112550,22 +118917,36 @@ "R-EX-3", "R-EX-4", "R-EX-5", + "R-EX-6", + "R-EX-7", "R-GV-1", + "R-GV-2", + "R-GV-3", "R-GV-4", "R-GV-5", - "R-IR-4" + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" ], "threats": [ + "NT-7", "MT-1", "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", "MT-7", "MT-8", "MT-9", - "MT-10", "MT-11", "MT-12", "MT-13", @@ -112573,9 +118954,103 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed" + "errata": "- new control - SCF community" + }, + { + "control_id": "SEA-01.5", + "title": "Security-Aware Design", + "family": "SEA", + "description": "Mechanisms exist to formally incorporate the organization's secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "scf_question": "Does the organization formally incorporate its secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to formally incorporate the organization's secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Security design checklist for new systems or applications\n∙ OWASP Top 10 design guidance", + "small": "∙ OWASP secure design principles\n∙ Security requirements in development projects", + "medium": "∙ Security-by-design requirements integrated into SDLC\n∙ Threat modeling for new systems\n∙ OWASP Threat Dragon or similar", + "large": "∙ Enterprise secure-by-design program\n∙ Threat modeling requirements in SDLC\n∙ Security architecture approval for new projects\n∙ Privacy and security design reviews", + "enterprise": "∙ Enterprise security-aware design program\n∙ Automated threat modeling integration in SDLC\n∙ Security and privacy design reviews for all new systems\n∙ Board-approved security-by-design policy" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" }, { "control_id": "SEA-02", @@ -112598,9 +119073,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -112671,9 +119146,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SEA-02.1", @@ -112693,9 +119168,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -112732,7 +119207,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -112753,7 +119229,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to identify non-essential functions or services that are capable of being outsourced to external service providers and align with the organization's enterprise architecture and security standards.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -112820,7 +119296,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -112841,7 +119318,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to conduct ongoing “technical debt” reviews of hardware and software technologies to remediate outdated and/or unsupported technologies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -112919,7 +119396,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -112943,9 +119421,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).\n▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113016,7 +119494,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113037,9 +119516,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to partition systems so that partitions reside in separate physical domains or environments.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to partition systems so that partitions reside in separate physical domains or environments. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113086,7 +119565,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113107,9 +119587,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to separate user functionality from system management functionality.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to separate user functionality from system management functionality. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113156,7 +119636,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113177,9 +119658,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement a separate execution domain for each executing process.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement a separate execution domain for each executing process. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113225,7 +119706,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113246,9 +119728,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate security functions from non-security functions.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate security functions from non-security functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113314,7 +119796,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113335,9 +119818,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement underlying hardware separation mechanisms to facilitate process separation.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement underlying hardware separation mechanisms to facilitate process separation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113381,7 +119864,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113402,9 +119886,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to maintain a separate execution domain for each thread in multi-threaded processing.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to maintain a separate execution domain for each thread in multi-threaded processing. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113448,7 +119932,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113469,7 +119954,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate, or logically separate, any application, service and/or process running with system privileges.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -113532,7 +120017,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113553,9 +120039,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent unauthorized and unintended information transfer via shared system resources.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent unauthorized and unintended information transfer via shared system resources. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113626,7 +120112,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113647,9 +120134,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically prevent the execution of unauthorized software programs.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically prevent the execution of unauthorized software programs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113698,7 +120185,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113721,7 +120209,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to determine the Mean Time to Failure (MTTF) for system components in specific environments of operation.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -113774,7 +120262,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113797,9 +120286,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113861,7 +120350,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113882,11 +120372,11 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -113950,7 +120440,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -113971,11 +120462,11 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement fail-safe procedures when failure conditions occur.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement fail-safe procedures when failure conditions occur. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -114006,7 +120497,168 @@ "R-IR-4" ], "threats": [ - "NT-1", + "NT-1", + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "SEA-08", + "title": "Non-Persistence", + "family": "SEA", + "description": "Mechanisms exist to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency.", + "scf_question": "Does the organization implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": false, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency. ", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Secure Baseline Configurations (SBC)", + "small": "∙ Secure Baseline Configurations (SBC)", + "medium": "∙ Secure Baseline Configurations (SBC)", + "large": "∙ Secure Baseline Configurations (SBC)", + "enterprise": "∙ Secure Baseline Configurations (SBC)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-IR-1", + "R-IR-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "SEA-08.1", + "title": "Refresh from Trusted Sources", + "family": "SEA", + "description": "Mechanisms exist to ensure that software and data needed for system component and service refreshes are obtained from trusted sources.", + "scf_question": "Does the organization ensure that software and data needed for system component and service refreshes are obtained from trusted sources?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure that software and data needed for system component and service refreshes are obtained from trusted sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "medium": "∙ Review systems for covert channels as part of security assessment", + "large": "∙ Covert channel analysis as part of security architecture review", + "enterprise": "∙ Enterprise covert channel analysis program\n∙ Formal covert channel testing for high-assurance systems" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-IR-1", + "R-IR-4" + ], + "threats": [ "NT-2", "NT-3", "NT-4", @@ -114037,88 +120689,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] - }, - { - "control_id": "SEA-08", - "title": "Non-Persistence", - "family": "SEA", - "description": "Mechanisms exist to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency.", - "scf_question": "Does the organization implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency?", - "relative_weight": 9, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Technology", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": false, - "operational": false, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], - "possible_solutions": { - "micro_small": "∙ Secure Baseline Configurations (SBC)", - "small": "∙ Secure Baseline Configurations (SBC)", - "medium": "∙ Secure Baseline Configurations (SBC)", - "large": "∙ Secure Baseline Configurations (SBC)", - "enterprise": "∙ Secure Baseline Configurations (SBC)" - }, - "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", - "R-AM-3", - "R-BC-1", - "R-BC-2", - "R-BC-4", - "R-BC-5", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-4", - "R-GV-5", - "R-IR-1", - "R-IR-4" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "SEA-08.1", - "title": "Refresh from Trusted Sources", + "control_id": "SEA-08.2", + "title": "Non-Persistent Information", "family": "SEA", - "description": "Mechanisms exist to ensure that software and data needed for system component and service refreshes are obtained from trusted sources.", - "scf_question": "Does the organization ensure that software and data needed for system component and service refreshes are obtained from trusted sources?", - "relative_weight": 5, + "description": "Mechanisms exist to:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed.", + "scf_question": "Does the organization:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", @@ -114130,20 +120711,19 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", - "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure that software and data needed for system component and service refreshes are obtained from trusted sources.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "medium": "∙ Review systems for covert channels as part of security assessment", - "large": "∙ Covert channel analysis as part of security architecture review", - "enterprise": "∙ Enterprise covert channel analysis program\n∙ Formal covert channel testing for high-assurance systems" + "micro_small": "∙ Session timeout configurations\n∙ Ephemeral file deletion after use", + "small": "∙ Session termination and ephemeral data deletion\n∙ Temporary file cleanup policies", + "medium": "∙ Automated ephemeral data lifecycle management\n∙ Session management with defined timeout and cleanup\n∙ Secure deletion of temporary data stores", + "large": "∙ Automated non-persistent information management\n∙ Defined data refresh cycles for non-persistent stores\n∙ Secure deletion enforcement", + "enterprise": "∙ Enterprise non-persistent information governance\n∙ Automated data lifecycle enforcement for ephemeral data\n∙ Integration with data classification and DLP\n∙ Continuous monitoring for data persistence policy compliance" }, "risks": [ "R-AC-1", @@ -114166,25 +120746,9 @@ "R-IR-4" ], "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", "MT-1", "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", "MT-7", "MT-8", "MT-9", @@ -114196,8 +120760,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3" }, { "control_id": "SEA-09", @@ -114217,9 +120783,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114266,7 +120832,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114287,7 +120854,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to limit the dissemination of Personal Data (PD) to organization-defined elements identified in the Data Protection Impact Assessment (DPIA) and consistent with authorized purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -114344,7 +120911,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114365,9 +120933,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security safeguards to protect system memory from unauthorized code execution.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security safeguards to protect system memory from unauthorized code execution. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114414,7 +120982,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114435,9 +121004,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeypots that are specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting and analyzing such attacks.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeypots that are specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting and analyzing such attacks. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114480,7 +121049,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114501,9 +121071,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeyclients that proactively seek to identify malicious websites and/or web-based malicious code.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeyclients that proactively seek to identify malicious websites and/or web-based malicious code. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114543,7 +121113,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114564,9 +121135,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a diverse set of technologies for system components to reduce the impact of technical vulnerabilities from the same Original Equipment Manufacturer (OEM).", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a diverse set of technologies for system components to reduce the impact of technical vulnerabilities from the same Original Equipment Manufacturer (OEM). ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114612,7 +121183,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114633,7 +121205,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize virtualization techniques to support the employment of a diversity of operating systems and applications.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -114679,7 +121251,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114700,9 +121273,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize concealment and misdirection techniques for TAAS to confuse and mislead adversaries.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize concealment and misdirection techniques for TAAS to confuse and mislead adversaries. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114734,7 +121307,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114755,7 +121329,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically introduce randomness into organizational operations and assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -114803,7 +121377,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114824,7 +121399,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically change the location of processing and/or storage at random time intervals.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -114872,7 +121447,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114893,9 +121469,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to distribute processing and storage across multiple physical locations.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to distribute processing and storage across multiple physical locations. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114957,7 +121533,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -114978,7 +121555,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize non-modifiable executable programs that load and execute the operating environment and applications from hardware-enforced, read-only media.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115010,7 +121587,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115031,7 +121609,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a trusted communications path between the user and the security functions of the system.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115082,7 +121660,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115105,7 +121684,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize system use notification / logon banners that display an approved system use notification message or banner before granting access to Technology Assets, Applications and/or Services (TAAS).", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115157,9 +121736,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SEA-18.1", @@ -115181,7 +121760,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to configure Microsoft Windows-based systems to display an approved logon banner before granting access to the system.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115233,9 +121812,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SEA-18.2", @@ -115257,7 +121836,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a truncated system use notification / logon banner on systems not capable of displaying a logon banner from a centralized directory services technology (e.g., Active Directory, Entra ID, etc.).", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115309,16 +121888,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SEA-19", "title": "Previous Logon Notification", "family": "SEA", - "description": "Mechanisms exist to configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", - "scf_question": "Does the organization configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon?", + "description": "Mechanisms exist to configure systems that process, store or transmit sensitive and/or regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", + "scf_question": "Does the organization configure systems that process, store or transmit sensitive and/or regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -115331,7 +121910,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115365,7 +121944,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115386,9 +121966,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize time-synchronization technology to synchronize all critical system clocks.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize time-synchronization technology to synchronize all critical system clocks. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -115440,7 +122020,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115461,7 +122042,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize an application container (virtualization approach) to isolate to a known set of dependencies, access methods and interfaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -115492,7 +122073,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115500,7 +122082,7 @@ "title": "Privileged Environments", "family": "SEA", "description": "Mechanisms exist to prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS).", + "scf_question": "Does the organization prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -115513,7 +122095,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -115588,7 +122170,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115700,7 +122283,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115723,7 +122307,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to identify and document Standardized Operating Procedures (SOP), or similar documentation, to enable the proper execution of day-to-day / assigned tasks.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115794,7 +122378,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115817,7 +122402,7 @@ "0": "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.", "1": "Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cybersecurity operations are primarily viewed as additional duties for IT staff.\n▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage.", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", - "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to develop a security Concept of Operations (CONOPS), or a similarly-defined plan for achieving cybersecurity objectives, that documents management, operational and technical measures implemented to apply defense-in-depth techniques that is communicated to all appropriate stakeholders.", + "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to develop a security Concept of Operations (CONOPS), or a similarly-defined plan for achieving cybersecurity objectives, that documents management, operational and technical measures implemented to apply defense-in-depth techniques that is communicated to all appropriate stakeholders. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -115881,7 +122466,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115904,7 +122490,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to define supporting business processes and implement appropriate governance and service management to ensure appropriate planning, delivery and support of the organization's technology capabilities supporting business functions, workforce, and/or customers based on industry-recognized standards to achieve the specific goals of the process area.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115975,7 +122561,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -115998,7 +122585,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to establish and maintain a Security Operations Center (SOC) that facilitates a 24x7 response capability.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -116072,7 +122659,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -116093,7 +122681,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to provide guidelines and recommendations for the secure use of Technology Assets, Applications and/or Services (TAAS) to assist in the configuration, installation and use of the product and/or service.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -116165,7 +122753,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -116237,7 +122826,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -116260,7 +122850,7 @@ "0": "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.", "1": "Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cybersecurity operations are primarily viewed as additional duties for IT staff.\n▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage.", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ An implemented and operational capability exists to detect the presence of unauthorized Technology Assets, Applications and/or Services (TAAS) in use.", + "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to detect the presence of unauthorized Technology Assets, Applications and/or Services (TAAS) in use.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -116356,7 +122946,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -116383,7 +122974,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security workforce development and awareness controls.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security workforce development and awareness controls. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -116481,9 +123072,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed" + "MT-27", + "MT-28" + ] }, { "control_id": "SAT-01.1", @@ -116599,7 +123190,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -116624,7 +123216,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -116714,9 +123306,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SAT-02.1", @@ -116825,7 +123417,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -116904,7 +123497,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -116912,7 +123506,7 @@ "title": "Role-Based Security, Compliance & Resilience Training", "family": "SAT", "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", - "scf_question": "Does the organization provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafterystem changes; and \n (3) Annually thereafter?", + "scf_question": "Does the organization provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -117002,13 +123596,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SAT-03.1", - "title": "Practical Exercises", + "title": "Practical Security Training Exercises", "family": "SAT", "description": "Mechanisms exist to include practical exercises in security, compliance and resilience training that reinforce training objectives.", "scf_question": "Does the organization include practical exercises in security, compliance and resilience training that reinforce training objectives?", @@ -117028,7 +123622,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to include practical exercises in security, compliance and resilience training that reinforce training objectives.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to include practical exercises in security, compliance and resilience training that reinforce training objectives.\nMechanisms exist to include practical exercises in security, compliance and resilience training that reinforce training objectives.", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -117082,9 +123676,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed" + "errata": "- renamed control" }, { "control_id": "SAT-03.2", @@ -117164,15 +123759,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "update mappings to NIST 800-53" }, { "control_id": "SAT-03.3", "title": "Sensitive / Regulated Data Storage, Handling & Processing", "family": "SAT", - "description": "Mechanisms exist to ensure that every user accessing a system processing, storing or transmitting sensitive/regulated data is formally trained in data handling requirements.", - "scf_question": "Does the organization ensure that every user accessing a system processing, storing or transmitting sensitive/regulated data is formally trained in data handling requirements?", + "description": "Mechanisms exist to ensure that every user accessing a system processing, storing or transmitting sensitive and/or regulated data is formally trained in data handling requirements.", + "scf_question": "Does the organization ensure that every user accessing a system processing, storing or transmitting sensitive and/or regulated data is formally trained in data handling requirements?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -117273,7 +123870,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -117299,7 +123897,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to incorporate vendor-specific security, compliance and resilience training in support of new technology initiatives.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to incorporate vendor-specific security, compliance and resilience training in support of new technology initiatives. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -117365,16 +123963,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SAT-03.5", "title": "Privileged Users", "family": "SAT", "description": "Mechanisms exist to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", - "scf_question": "Does the organization provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", + "scf_question": "Does the organization provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -117389,9 +123987,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.\n▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data).", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -117479,7 +124077,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -117502,7 +124101,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.\n▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data).\n▪ Business process owners are required to incorporate vendor-specific security training in support of new technology initiatives.\n▪ Security awareness training covers recommended practices for securing laptops and mobile devices while traveling.\n▪ Security awareness training covers reporting of unauthorized alterations and evidence of tampering of equipment", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide role-based security, compliance and resilience awareness training that is current and relevant to the cyber threats that users might encounter in day-to-day business operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -117575,9 +124174,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed" + "errata": "update mappings to NIST 800-53" }, { "control_id": "SAT-03.7", @@ -117600,7 +124200,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience personnel receive Continuing Professional Education (CPE) training to maintain currency and proficiency with industry-recognized secure practices that are pertinent to their assigned roles and responsibilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -117649,9 +124249,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "SAT-03.8", @@ -117671,7 +124271,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to ensure application development and operations (DevOps) personnel receive Continuing Professional Education (CPE) training on Secure Software Development Practices (SSDP) to appropriately address evolving threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -117716,7 +124316,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -117805,7 +124406,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -117900,9 +124502,78 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "SAT-04.1", + "title": "Training Feedback", + "family": "SAT", + "description": "Mechanisms exist to:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders.", + "scf_question": "Does the organization:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders.", + "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Track training completion rates\n∙ Simple feedback survey after training", + "small": "∙ Training completion tracking\n∙ Post-training feedback forms\n∙ Report findings to management", + "medium": "∙ Learning Management System (LMS) with completion and assessment tracking\n∙ Training effectiveness metrics\n∙ Regular reporting to management on training outcomes", + "large": "∙ LMS with detailed completion and assessment analytics\n∙ Training effectiveness measurement\n∙ Reporting to security leadership and HR", + "enterprise": "∙ Enterprise LMS with advanced analytics\n∙ Training effectiveness measurement and outcome reporting\n∙ Behavioral change metrics linked to awareness program\n∙ Board-level workforce security readiness reporting" + }, + "risks": [ + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" ], - "errata": "- renamed\n- wordsmithed" + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3" }, { "control_id": "SAT-05", @@ -117929,7 +124600,13 @@ "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Informal security knowledge sharing (e.g., team meetings, email updates)\n∙ Subscribe to CISA and NIST security alerts", + "small": "∙ Regular security briefings or newsletter\n∙ CISA and NIST alert subscriptions for the security team", + "medium": "∙ Internal security knowledge sharing program\n∙ Cross-functional security briefings\n∙ Lessons learned from incidents and assessments", + "large": "∙ Formal knowledge sharing program (security communities of practice)\n∙ Internal security portal or wiki\n∙ Cross-functional security training and briefings", + "enterprise": "∙ Enterprise security knowledge management platform\n∙ Communities of practice for security specializations\n∙ Cross-organizational knowledge sharing and lessons learned\n∙ Integration with LMS and professional development programs" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -118000,9 +124677,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-01", @@ -118027,7 +124704,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -118129,7 +124806,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118241,7 +124919,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118264,11 +124943,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize integrity validation mechanisms for security updates.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -118322,7 +125001,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118330,7 +125010,7 @@ "title": "Malware Testing Prior to Release", "family": "TDA", "description": "Mechanisms exist to utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update.", - "scf_question": "Does the organization utilize at least one (1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update?", + "scf_question": "Does the organization utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -118343,11 +125023,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -118398,7 +125078,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118507,9 +125188,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-02", @@ -118531,7 +125212,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to design, develop and produce Technology Assets, Applications and/or Services (TAAS) in such a way that risk-based technical and functional specifications ensure Minimum Viable Product (MVP) criteria establish an appropriate level of security and resiliency based on applicable risks and threats.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -118622,7 +125303,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118646,9 +125328,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to identify early in the Secure Development Life Cycle (SDLC), the functions, ports, protocols and services intended for use.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to identify early in the Secure Development Life Cycle (SDLC), the functions, ports, protocols and services intended for use. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -118716,7 +125398,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118737,7 +125420,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit the use of commercially-provided Information Assurance (IA) and IA-enabled IT products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile or the cryptographic module is FIPS-validated or NSA-approved.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -118773,7 +125456,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118796,7 +125480,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -118869,7 +125553,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118890,7 +125575,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure vendors / manufacturers:\n(1) Deliver the Technology Asset, Application and/or Service (TAAS) with a pre-established, secure configuration implemented; and\n(2) Use the pre-established, secure configuration as the default for any subsequent TAAS reinstallation or upgrade.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -118962,7 +125647,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -118986,9 +125672,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require process owners to identify, document and justify the business need for the ports, protocols and other services necessary to operate their technology solutions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require process owners to identify, document and justify the business need for the ports, protocols and other services necessary to operate their technology solutions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -119048,7 +125734,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119069,9 +125756,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to mitigate the risk associated with the use of insecure ports, protocols and services necessary to operate technology solutions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to mitigate the risk associated with the use of insecure ports, protocols and services necessary to operate technology solutions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -119133,7 +125820,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119154,7 +125842,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to include appropriate security, compliance and resilience representatives in the product feature and/or functionality change control review process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119241,9 +125929,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-02.8", @@ -119263,7 +125951,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to minimize the attack surface of Technology Assets, Applications and/or Services (TAAS) by reasonably mitigating known exploitable vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119350,7 +126038,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119371,7 +126060,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to deliver security updates to Technology Assets, Applications and/or Services (TAAS), where applicable, through:\n(1) Automatic updates; and\n(2) Notification of available updates to affected users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119457,7 +126146,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119478,7 +126168,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for an appropriate level of security and resiliency based on applicable risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119565,7 +126255,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119586,7 +126277,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to disclose information about vulnerabilities to relevant stakeholders, including:\n(1) A description of the vulnerability(ies);\n(2) Affected product(s) and/or service(s);\n(3) Potential impact of the vulnerability(ies);\n(4) Severity of the vulnerability(ies); and\n(5) Guidance to remediate the vulnerability(ies).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119672,7 +126363,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119693,7 +126385,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to categorize applicable security and resiliency requirements for products and/or services with digital elements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119776,7 +126468,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119797,7 +126490,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to notify applicable stakeholders about potentially exploitable vulnerabilities in organization-developed Technology Assets, Applications and/or Services (TAAS), as required by statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119880,7 +126573,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119901,7 +126595,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers to use an industry-defined secure logging format to generate event logs for specified event types at organization-defined level of detail.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119964,7 +126658,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -119985,9 +126680,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, custom-develops business-critical TAAS, when Commercial Off The Shelf (COTS) solutions are unavailable.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize only Commercial Off-the-Shelf (COTS) security products.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize only Commercial Off-the-Shelf (COTS) security products. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -120024,7 +126719,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -120045,7 +126741,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to obtain security, compliance and resilience technologies from different suppliers to minimize supply chain risk.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -120107,9 +126803,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-04", @@ -120133,7 +126829,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to obtain, protect and distribute administrator documentation for Technology Assets, Applications and/or Services (TAAS) that describe:\n(1) Secure configuration, installation and operation of the TAAS;\n(2) Effective use and maintenance of security features/functions; and\n(3) Known vulnerabilities regarding configuration and use of administrative (e.g., privileged) functions.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -120181,7 +126877,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -120207,9 +126904,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -120264,9 +126961,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-04.2", @@ -120288,7 +126985,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate, or obtain, a Software Bill of Materials (SBOM) for Technology Assets, Applications and/or Services (TAAS) that lists software packages in use, including versions and applicable licenses.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -120338,7 +127035,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -120346,7 +127044,7 @@ "title": "Developer Architecture & Design", "family": "TDA", "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", - "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection?", + "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of its security architecture which is established within and is an integrated part of its enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -120361,7 +127059,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -120460,9 +127158,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-05.1", @@ -120482,7 +127180,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to secure physical diagnostic and test interfaces to prevent misuse.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -120536,7 +127234,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -120557,7 +127256,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to enable endpoint devices to log events and generate alerts for attempts to access diagnostic and test interfaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -120611,7 +127310,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -120635,11 +127335,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to develop applications based on Secure Software Development Practices (SSDP).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -120709,7 +127409,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -120734,7 +127435,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developer of the Technology Asset, Application and/or Service (TAAS) to perform a criticality analysis at organization-defined decision points in the Secure Development Life Cycle (SDLC).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -120786,9 +127487,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-06.2", @@ -120812,7 +127513,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform threat modelling and other secure design techniques, to ensure that threats to software and solutions are identified and accounted for.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -120864,7 +127565,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -120888,7 +127590,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a Software Assurance Maturity Model (SAMM) to govern a secure development lifecycle for the development of Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -120937,7 +127639,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -120958,7 +127661,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically improve the accuracy, consistency and comprehensiveness of secure practices throughout the asset's lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -120999,22 +127702,90 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "TDA-06.5", + "title": "Software Design Review", + "family": "TDA", + "description": "Mechanisms exist to have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated.", + "scf_question": "Does the organization have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated?", + "relative_weight": 10, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-TDA-05" + ], + "pptdf": "Process", + "nist_csf_function": "Detect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "SCRMS", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "large": "∙ Formal system integration testing with security focus", + "enterprise": "∙ Enterprise integration testing program with security validation\n∙ Automated integration security testing" + }, + "risks": [ + "R-AM-3", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-4", + "R-GV-6", + "R-GV-7", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { - "control_id": "TDA-06.5", - "title": "Software Design Review", + "control_id": "TDA-06.6", + "title": "Software Design Root Cause Analysis", "family": "TDA", - "description": "Mechanisms exist to have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated.", - "scf_question": "Does the organization have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated?", - "relative_weight": 10, + "description": "Mechanisms exist to assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness.", + "scf_question": "Does the organization assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness?", + "relative_weight": 5, "conformity_cadence": "Annual", - "evidence_requests": [ - "E-TDA-05" - ], + "evidence_requests": [], "pptdf": "Process", - "nist_csf_function": "Detect", + "nist_csf_function": "Protect", "scrm_focus": { "strategic": false, "operational": true, @@ -121022,19 +127793,15 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "SCRMS", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "large": "∙ Formal system integration testing with security focus", - "enterprise": "∙ Enterprise integration testing program with security validation\n∙ Automated integration security testing" + "enterprise": "∙ Enterprise acceptance testing program with formal security criteria" }, "risks": [ "R-AM-3", @@ -121067,49 +127834,75 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { - "control_id": "TDA-06.6", - "title": "Software Design Root Cause Analysis", + "control_id": "TDA-06.7", + "title": "Programming Language Selection", "family": "TDA", - "description": "Mechanisms exist to assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness.", - "scf_question": "Does the organization assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness?", - "relative_weight": 5, + "description": "Mechanisms exist to:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions.", + "scf_question": "Does the organization:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", - "nist_csf_function": "Protect", + "nist_csf_function": "Identify", "scrm_focus": { "strategic": false, "operational": true, - "tactical": true + "tactical": false }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { - "enterprise": "∙ Enterprise acceptance testing program with formal security criteria" + "micro_small": "∙ Document approved programming languages for internal development\n∙ Prefer memory-safe languages for security-sensitive code (e.g., Rust, Go, Python)", + "small": "∙ Approved programming language list\n∙ Memory-safe language preference for new development\n∙ Documented justification for language choices", + "medium": "∙ Formal programming language governance standard\n∙ Memory-safe language requirements for security-critical code\n∙ Language selection approval process", + "large": "∙ Enterprise programming language governance program\n∙ Enforcement of approved languages in CI/CD\n∙ Security-focused language selection criteria (e.g., CISA memory safety guidance)", + "enterprise": "∙ Enterprise programming language governance with automated enforcement\n∙ CISA Memory Safe Roadmap alignment\n∙ Automated language compliance checking in CI/CD pipeline\n∙ Developer training on approved languages" }, "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", "R-EX-1", "R-EX-2", "R-EX-3", "R-EX-4", "R-EX-5", + "R-EX-6", + "R-EX-7", "R-GV-1", + "R-GV-2", + "R-GV-3", "R-GV-4", + "R-GV-5", "R-GV-6", "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", "R-SC-1", "R-SC-2", "R-SC-3", @@ -121121,6 +127914,7 @@ "NT-7", "MT-1", "MT-2", + "MT-7", "MT-8", "MT-9", "MT-11", @@ -121130,8 +127924,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2040" }, { "control_id": "TDA-07", @@ -121151,11 +127947,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a segmented development network to ensure a secure development environment.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a segmented development network to ensure a secure development environment. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -121223,7 +128019,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -121244,7 +128041,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -121340,7 +128137,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -121361,7 +128159,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure secure migration practices purge Technology Assets, Applications and/or Services (TAAS) of test/development/staging data and accounts before it is migrated into a production environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -121424,7 +128222,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -121448,7 +128247,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers/integrators consult with security, compliance and/or resilience personnel to: \n(1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability;\n(2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the control testing and evaluation process; and\n(3) Document the results.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -121525,9 +128324,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- renamed\n- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-09.1", @@ -121549,9 +128348,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a plan for the continuous monitoring of security, compliance and/or resilience control effectiveness.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a plan for the continuous monitoring of security, compliance and/or resilience control effectiveness. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -121633,9 +128432,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-09.2", @@ -121657,9 +128456,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Developers of TAAS are required to employ static code analysis tools to identify and remediate common flaws, documenting the results of the analysis before the application is cleared for production usage.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ static code analysis tools to identify and remediate common flaws and document the results of the analysis.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ static code analysis tools to identify and remediate common flaws and document the results of the analysis. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -121715,7 +128514,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -121738,9 +128538,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Developers of TAAS are to employ dynamic code analysis tools to identify and remediate common flaws, documenting the results of the analysis before the application is cleared for production usage.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ dynamic code analysis tools to identify and remediate common flaws and document the results of the analysis.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ dynamic code analysis tools to identify and remediate common flaws and document the results of the analysis. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -121795,7 +128595,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -121818,7 +128619,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, implements a process to check the validity of information inputs.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize testing methods to ensure Technology Assets, Applications and/or Services (TAAS) continue to operate as intended when subject to invalid or unexpected inputs on its interfaces.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -121875,7 +128676,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -121898,7 +128700,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform application-level penetration testing of custom-made Technology Assets, Applications and/or Services (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -121957,7 +128759,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -121980,7 +128783,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement secure configuration settings by default to reduce the likelihood of Technology Assets, Applications and/or Services (TAAS) being deployed with weak security settings that would put the TAAS at a greater risk of compromise.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -122043,7 +128846,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -122064,7 +128868,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ a manual code review process to identify and remediate unique flaws that require knowledge of the application’s requirements and design.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -122118,7 +128922,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -122139,7 +128944,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to approve, document and control the use of live data in development and test environments.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -122192,7 +128997,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -122213,11 +129019,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure the integrity of test data through existing security, compliance and resilience controls.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -122263,9 +129069,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TDA-11", @@ -122285,7 +129091,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain awareness of component authenticity by developing and implementing Product Tampering and Counterfeiting (PTC) practices that include the means to detect and prevent counterfeit components.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -122357,16 +129163,230 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "TDA-11.1", + "title": "Anti-Counterfeit Training", + "family": "TDA", + "description": "Mechanisms exist to train personnel to detect counterfeit system components, including hardware, software and firmware.", + "scf_question": "Does the organization train personnel to detect counterfeit system components, including hardware, software and firmware?", + "relative_weight": 6, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "People", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to train personnel to detect counterfeit system components, including hardware, software and firmware. ", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats" + ], + "possible_solutions": { + "medium": "∙ Regression testing for security after code changes", + "large": "∙ Enterprise security regression testing program", + "enterprise": "∙ Enterprise automated security regression testing in CI/CD pipeline" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "TDA-11.2", + "title": "Component Disposal", + "family": "TDA", + "description": "[deprecated - incorporated into AST-09]\nMechanisms exist to dispose of system components using organization-defined techniques and methods to prevent such components from entering the gray market.", + "scf_question": "[deprecated - incorporated into AST-09]\nDoes the organization dispose of system components using organization-defined techniques and methods to prevent such components from entering the gray market?", + "relative_weight": 0, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "N/A", + "nist_csf_function": "N/A", + "scrm_focus": { + "strategic": false, + "operational": false, + "tactical": false + }, + "maturity": { + "0": "N/A", + "1": "N/A", + "2": "N/A", + "3": "N/A", + "4": "N/A", + "5": "N/A" + }, + "profiles": [], + "possible_solutions": { + "large": "∙ Fuzz testing for critical applications", + "enterprise": "∙ Enterprise fuzz testing program (e.g., AFL, libFuzzer, Google OSS-Fuzz)\n∙ Automated fuzzing in CI/CD" + }, + "risks": [], + "threats": [] + }, + { + "control_id": "TDA-12", + "title": "Customized Development of Critical Components", + "family": "TDA", + "description": "Mechanisms exist to custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable.", + "scf_question": "Does the organization custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Perform basic security testing before deploying new software", + "small": "∙ Security testing checklist before software deployment", + "medium": "∙ Formal security testing program for software releases", + "large": "∙ Enterprise DAST/SAST program integrated with deployment process", + "enterprise": "∙ Enterprise DevSecOps security testing automation (SAST, DAST, SCA, IAST)\n∙ Full CI/CD integration" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { - "control_id": "TDA-11.1", - "title": "Anti-Counterfeit Training", + "control_id": "TDA-13", + "title": "Developer Screening", "family": "TDA", - "description": "Mechanisms exist to train personnel to detect counterfeit system components, including hardware, software and firmware.", - "scf_question": "Does the organization train personnel to detect counterfeit system components, including hardware, software and firmware?", - "relative_weight": 6, + "description": "Mechanisms exist to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", + "scf_question": "Does the organization ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations?", + "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "People", @@ -122378,21 +129398,19 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to train personnel to detect counterfeit system components, including hardware, software and firmware.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats" - ], + "profiles": [], "possible_solutions": { - "medium": "∙ Regression testing for security after code changes", - "large": "∙ Enterprise security regression testing program", - "enterprise": "∙ Enterprise automated security regression testing in CI/CD pipeline" + "micro_small": "∙ Document and communicate security vulnerabilities in released software", + "small": "∙ Document and communicate security vulnerabilities in released software", + "medium": "∙ Formal coordinated vulnerability disclosure (CVD) policy and process", + "large": "∙ Enterprise vulnerability disclosure program (VDP)\n∙ CNA enrollment if applicable", + "enterprise": "∙ Enterprise vulnerability disclosure program (VDP)\n∙ Bug bounty integration (e.g., HackerOne, Bugcrowd)\n∙ CVE/CNA participation" }, "risks": [ "R-AC-1", @@ -122426,7 +129444,6 @@ "R-IR-3", "R-IR-4", "R-SA-1", - "R-SA-2", "R-SC-1", "R-SC-2", "R-SC-3", @@ -122448,48 +129465,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "TDA-11.2", - "title": "Component Disposal", + "control_id": "TDA-13.1", + "title": "Developer Knowledge & Skills Register", "family": "TDA", - "description": "[deprecated - incorporated into AST-09]\nMechanisms exist to dispose of system components using organization-defined techniques and methods to prevent such components from entering the gray market.", - "scf_question": "[deprecated - incorporated into AST-09]\nDoes the organization dispose of system components using organization-defined techniques and methods to prevent such components from entering the gray market?", - "relative_weight": 0, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "N/A", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": false, - "operational": false, - "tactical": false - }, - "maturity": { - "0": "N/A", - "1": "N/A", - "2": "N/A", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ [deprecated - incorporated into AST-09]\nAn implemented and operational capability exists to dispose of system components using organization-defined techniques and methods to prevent such components from entering the gray market.", - "4": "N/A", - "5": "N/A" - }, - "profiles": [], - "possible_solutions": { - "large": "∙ Fuzz testing for critical applications", - "enterprise": "∙ Enterprise fuzz testing program (e.g., AFL, libFuzzer, Google OSS-Fuzz)\n∙ Automated fuzzing in CI/CD" - }, - "risks": [], - "threats": [] - }, - { - "control_id": "TDA-12", - "title": "Customized Development of Critical Components", - "family": "TDA", - "description": "Mechanisms exist to custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable.", - "scf_question": "Does the organization custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable?", - "relative_weight": 8, + "description": "Mechanisms exist to maintain a cybersecurity knowledge and skills register for developers.", + "scf_question": "Does the organization maintain a cybersecurity knowledge and skills register for developers?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", @@ -122501,19 +129487,19 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a cybersecurity knowledge and skills register for developers.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { - "micro_small": "∙ Perform basic security testing before deploying new software", - "small": "∙ Security testing checklist before software deployment", - "medium": "∙ Formal security testing program for software releases", - "large": "∙ Enterprise DAST/SAST program integrated with deployment process", - "enterprise": "∙ Enterprise DevSecOps security testing automation (SAST, DAST, SCA, IAST)\n∙ Full CI/CD integration" + "micro_small": "∙ Note: Formal developer skills register typically not required at this size\n∙ Track relevant security certifications for development staff", + "small": "∙ Simple skills inventory for development team security knowledge\n∙ Track SSDP training completion", + "medium": "∙ Developer cybersecurity skills register\n∙ Skills gap analysis against SSDP requirements\n∙ Integration with HR and training records", + "large": "∙ Formal developer security knowledge and skills register\n∙ Annual skills assessment and gap analysis\n∙ Integration with training and professional development program", + "enterprise": "∙ Enterprise developer security skills management program\n∙ Automated skills tracking in HR platform\n∙ Skills gap analysis tied to learning pathways\n∙ Integration with workforce planning" }, "risks": [ "R-AC-1", @@ -122522,7 +129508,6 @@ "R-AC-4", "R-AM-1", "R-AM-2", - "R-AM-3", "R-BC-1", "R-BC-2", "R-BC-3", @@ -122542,6 +129527,7 @@ "R-GV-5", "R-GV-6", "R-GV-7", + "R-GV-8", "R-IR-1", "R-IR-2", "R-IR-3", @@ -122568,16 +129554,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2039" }, { - "control_id": "TDA-13", - "title": "Developer Screening", + "control_id": "TDA-13.2", + "title": "Developer Training", "family": "TDA", - "description": "Mechanisms exist to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", - "scf_question": "Does the organization ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations?", - "relative_weight": 9, + "description": "Mechanisms exist to ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP).", + "scf_question": "Does the organization ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP)?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "People", @@ -122589,19 +129577,19 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { - "micro_small": "∙ Document and communicate security vulnerabilities in released software", - "small": "∙ Document and communicate security vulnerabilities in released software", - "medium": "∙ Formal coordinated vulnerability disclosure (CVD) policy and process", - "large": "∙ Enterprise vulnerability disclosure program (VDP)\n∙ CNA enrollment if applicable", - "enterprise": "∙ Enterprise vulnerability disclosure program (VDP)\n∙ Bug bounty integration (e.g., HackerOne, Bugcrowd)\n∙ CVE/CNA participation" + "micro_small": "∙ Free OWASP and SANS resources for developer security training.\n∙ Online SSDP training (e.g., Secure Code Warrior free tier)", + "small": "∙ OWASP resources and Secure Code Warrior free tier (https://securecodewarrior.com)\n∙ Annual developer security training requirement", + "medium": "∙ Secure coding training platform (e.g., Secure Code Warrior, Snyk Learn)\n∙ Role-based training for developers on SSDP\n∙ Annual required training completion", + "large": "∙ Enterprise secure coding training platform (e.g., Secure Code Warrior)\n∙ Mandatory annual training tied to developer roles\n∙ Training effectiveness measurement", + "enterprise": "∙ Enterprise developer security training program\n∙ Role-based SSDP training with LMS integration\n∙ Secure Code Warrior or equivalent at scale\n∙ Skills-gap based personalized learning paths" }, "risks": [ "R-AC-1", @@ -122656,8 +129644,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2038" }, { "control_id": "TDA-14", @@ -122682,7 +129672,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to perform configuration management during system design, development, implementation and operation.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -122759,7 +129749,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -122785,11 +129776,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of software and firmware components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of software and firmware components. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -122852,7 +129843,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -122878,7 +129870,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -122945,18 +129937,196 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ] + }, + { + "control_id": "TDA-15", + "title": "Developer Threat Analysis & Flaw Remediation", + "family": "TDA", + "description": "Mechanisms exist to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", + "scf_question": "Does the organization require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Security Testing and Evaluation (ST&E)", + "small": "∙ Security Testing and Evaluation (ST&E)", + "medium": "∙ Security Testing and Evaluation (ST&E)", + "large": "∙ Security Testing and Evaluation (ST&E)", + "enterprise": "∙ Security Testing and Evaluation (ST&E)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ] + }, + { + "control_id": "TDA-16", + "title": "Developer-Provided Training", + "family": "TDA", + "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS).", + "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS)?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS).", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "large": "∙ Formal privacy engineering practices in development lifecycle", + "enterprise": "∙ Enterprise privacy engineering program\n∙ Privacy-by-design in SDLC\n∙ Privacy design patterns" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ] }, { - "control_id": "TDA-15", - "title": "Developer Threat Analysis & Flaw Remediation", + "control_id": "TDA-17", + "title": "Unsupported Technology Assets, Applications and/or Services (TAAS)", "family": "TDA", - "description": "Mechanisms exist to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", - "scf_question": "Does the organization require system developers and integrators to create a Security Testing and Evaluation (ST&E) plan and implement the plan under the witness of an independent party?", - "relative_weight": 9, + "description": "Mechanisms exist to prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs.", + "scf_question": "Does the organization prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs?", + "relative_weight": 10, "conformity_cadence": "Annual", - "evidence_requests": [], + "evidence_requests": [ + "E-AST-09" + ], "pptdf": "Process", "nist_csf_function": "Protect", "scrm_focus": { @@ -122966,19 +130136,24 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", - "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, provides in-house support or contract external providers for support with unsupported system components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [], + "profiles": [ + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], "possible_solutions": { - "micro_small": "∙ Security Testing and Evaluation (ST&E)", - "small": "∙ Security Testing and Evaluation (ST&E)", - "medium": "∙ Security Testing and Evaluation (ST&E)", - "large": "∙ Security Testing and Evaluation (ST&E)", - "enterprise": "∙ Security Testing and Evaluation (ST&E)" + "micro_small": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)", + "small": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)", + "medium": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)", + "large": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)", + "enterprise": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)" }, "risks": [ "R-AC-1", @@ -123031,18 +130206,27 @@ "MT-13", "MT-14", "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "TDA-16", - "title": "Developer-Provided Training", + "control_id": "TDA-17.1", + "title": "Alternate Sources for Continued Support", "family": "TDA", - "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS).", - "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS)?", - "relative_weight": 9, + "description": "Mechanisms exist to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS).", + "scf_question": "Does the organization provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS)?", + "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", @@ -123054,111 +130238,23 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS).", - "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "large": "∙ Formal privacy engineering practices in development lifecycle", - "enterprise": "∙ Enterprise privacy engineering program\n∙ Privacy-by-design in SDLC\n∙ Privacy design patterns" - }, - "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", - "R-AM-3", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-BC-5", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ] - }, - { - "control_id": "TDA-17", - "title": "Unsupported Technology Assets, Applications and/or Services (TAAS)", - "family": "TDA", - "description": "Mechanisms exist to prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs.", - "scf_question": "Does the organization prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs?", - "relative_weight": 10, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-AST-09" - ], - "pptdf": "Process", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", - "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, provides in-house support or contract external providers for support with unsupported system components.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS). ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ "CORE ESP Level 1 Foundational", "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "CORE ESP Level 3 Advanced Threats" ], "possible_solutions": { - "micro_small": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)", - "small": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)", - "medium": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)", - "large": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)", - "enterprise": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management\n∙ Computer Lifecycle Program (CLP)\n∙ IT Asset Management (ITAM) program\n∙ Risk Management Program (RMP)" + "micro_small": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management", + "small": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management", + "medium": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management", + "large": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management", + "enterprise": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management" }, "risks": [ "R-AC-1", @@ -123221,58 +130317,51 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "TDA-17.1", - "title": "Alternate Sources for Continued Support", + "control_id": "TDA-18", + "title": "Input Data Validation", "family": "TDA", - "description": "Mechanisms exist to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS)?", - "relative_weight": 8, + "description": "Mechanisms exist to check the validity of information inputs.", + "scf_question": "Does the organization check the validity of information inputs?", + "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], - "pptdf": "Process", + "pptdf": "Technology", "nist_csf_function": "Protect", "scrm_focus": { - "strategic": false, + "strategic": true, "operational": true, "tactical": true }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to check the validity of information inputs. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats" + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management", - "small": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management", - "medium": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management", - "large": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management", - "enterprise": "∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program\n∙ Product / project management" + "enterprise": "∙ Enterprise formal methods or model-based design for highest-assurance systems" }, "risks": [ - "R-AC-1", - "R-AC-2", "R-AC-3", "R-AC-4", - "R-AM-1", "R-AM-2", "R-AM-3", "R-BC-1", "R-BC-2", - "R-BC-3", "R-BC-4", - "R-BC-5", "R-EX-1", "R-EX-2", "R-EX-3", @@ -123282,14 +130371,10 @@ "R-EX-7", "R-GV-1", "R-GV-2", - "R-GV-3", "R-GV-4", "R-GV-5", "R-GV-6", "R-GV-7", - "R-IR-1", - "R-IR-2", - "R-IR-3", "R-IR-4", "R-SA-1", "R-SC-1", @@ -123311,51 +130396,39 @@ "MT-13", "MT-14", "MT-15", - "MT-16", - "MT-17", - "MT-18", - "MT-19", - "MT-20", - "MT-21", - "MT-22", - "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "TDA-18", - "title": "Input Data Validation", + "control_id": "TDA-19", + "title": "Error Handling", "family": "TDA", - "description": "Mechanisms exist to check the validity of information inputs.", - "scf_question": "Does the organization check the validity of information inputs?", + "description": "Mechanisms exist to handle error conditions by: \n(1) Identifying potentially security-relevant error conditions;\n(2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n(3) Revealing error messages only to authorized personnel.", + "scf_question": "Does the organization handle error conditions by: \n (1) Identifying potentially security-relevant error conditions;\n (2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n (3) Revealing error messages only to authorized personnel?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Technology", "nist_csf_function": "Protect", "scrm_focus": { - "strategic": true, + "strategic": false, "operational": true, "tactical": true }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to check the validity of information inputs.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to handle error conditions by: \n(1) Identifying potentially security-relevant error conditions;\n(2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n(3) Revealing error messages only to authorized personnel.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "enterprise": "∙ Enterprise formal methods or model-based design for highest-assurance systems" + "enterprise": "∙ Enterprise reverse engineering controls for high-assurance systems\n∙ Code obfuscation" }, "risks": [ "R-AC-3", @@ -123401,19 +130474,20 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { - "control_id": "TDA-19", - "title": "Error Handling", + "control_id": "TDA-19.1", + "title": "Designated Roles To View Error Messages", "family": "TDA", - "description": "Mechanisms exist to handle error conditions by: \n(1) Identifying potentially security-relevant error conditions;\n(2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n(3) Revealing error messages only to authorized personnel.", - "scf_question": "Does the organization handle error conditions by: \n (1) Identifying potentially security-relevant error conditions;\n (2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n (3) Revealing error messages only to authorized personnel?", - "relative_weight": 9, + "description": "Mechanisms exist to:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s).", + "scf_question": "Does the organization:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s)?", + "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], - "pptdf": "Technology", + "pptdf": "Process", "nist_csf_function": "Protect", "scrm_focus": { "strategic": false, @@ -123422,15 +130496,19 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to handle error conditions by: \n(1) Identifying potentially security-relevant error conditions;\n(2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n(3) Revealing error messages only to authorized personnel.", - "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { - "enterprise": "∙ Enterprise reverse engineering controls for high-assurance systems\n∙ Code obfuscation" + "micro_small": "∙ Configure error messages to suppress technical details from end users\n∙ Role-based access to application error logs", + "small": "∙ Application configuration to display generic errors to end users\n∙ Technical error details restricted to authorized administrators", + "medium": "∙ Error message configuration standards\n∙ Role-based access to error logs and detailed messages\n∙ Centralized log management with access controls", + "large": "∙ Enterprise error message governance standard\n∙ Role-based log access controls\n∙ Automated testing for information disclosure via error messages", + "enterprise": "∙ Enterprise error handling standard with automated enforcement\n∙ Centralized SIEM with role-based log access\n∙ Automated security testing for error message information disclosure\n∙ Integration with code review and CI/CD security gates" }, "risks": [ "R-AC-3", @@ -123476,8 +130554,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3" }, { "control_id": "TDA-20", @@ -123497,9 +130577,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, uses a Source Code Manager (SCM) solution to govern modifying, copying, deleting, moving and renaming items in the software library.\n▪ SCM supports integrity checking on the source code repository.\n▪ SCM uses Role-Based Access Controls (RBAC) to limit the logical access and permissions for users in the software library.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit privileges to change software resident within software libraries.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit privileges to change software resident within software libraries. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -123564,7 +130644,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -123585,7 +130666,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to publish integrity verification information for software releases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -123639,7 +130720,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -123660,7 +130742,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to archive software releases and all of their components (e.g., code, package files, third-party libraries, documentation) to maintain integrity verification information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -123714,7 +130796,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -123737,9 +130820,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to escrow source code and supporting documentation to ensure software availability in the event the software provider goes out of business or is unable to provide support.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to escrow source code and supporting documentation to ensure software availability in the event the software provider goes out of business or is unable to provide support. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -123777,7 +130860,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -123798,7 +130882,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to govern the approval of binaries and code for production use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -123859,7 +130943,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -123880,7 +130965,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure developed Technology Assets, Applications and/or Services (TAAS) conform to applicable statutory and regulatory requirements, based on the product's and/or service's:\n(1) Use case(s); and\n(2) Geographic markets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -123946,7 +131031,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -123967,7 +131053,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate appropriate technical documentation artifacts for Technology Assets, Applications and/or Services (TAAS) in sufficient detail to demonstrate conformity with applicable statutory, regulatory and contractual compliance requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -124033,7 +131119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124054,7 +131141,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to include a detailed cybersecurity risk assessment in the technical documentation for Technology Assets, Applications and/or Services (TAAS) to demonstrate applicable risks in approved use cases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -124117,7 +131204,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124241,7 +131329,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124265,7 +131354,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A procurement function maintains a list of all active External Service Providers (ESPs), including pertinent contract information that will assist in a risk assessment.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to maintain a current, accurate and complete list of External Service Providers (ESPs) that can potentially impact the Confidentiality, Integrity, Availability and/or Safety (CIAS) of the organization's TAASD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -124335,7 +131424,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124358,7 +131448,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to identify, prioritize and assess suppliers and partners of critical Technology Assets, Applications and/or Services (TAAS) using a supply chain risk assessment process relative to their importance in supporting the delivery of high-value services.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -124456,7 +131546,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124464,7 +131555,7 @@ "title": "Supply Chain Risk Management (SCRM)", "family": "TPM", "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", - "scf_question": "Does the organization:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary?", + "scf_question": "Does the organization:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize its exposure to those risks and threats, as necessary?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -124479,11 +131570,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -124579,7 +131670,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124600,7 +131692,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize tailored acquisition strategies, contract tools and procurement methods for the purchase of unique Technology Assets, Applications and/or Services (TAAS).", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -124669,7 +131761,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124695,9 +131788,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize security safeguards to limit harm from potential adversaries who identify and target the organization's supply chain.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize security safeguards to limit harm from potential adversaries who identify and target the organization's supply chain. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -124793,7 +131886,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124801,7 +131895,7 @@ "title": "Processes To Address Weaknesses or Deficiencies", "family": "TPM", "description": "Mechanisms exist to address identified weaknesses or deficiencies in the security of the supply chain", - "scf_question": "Does the organization address identified weaknesses or deficiencies in the security of the supply chain", + "scf_question": "Does the organization address identified weaknesses or deficiencies in the security of the supply chain?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -124821,7 +131915,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No centralized inventory of External Service Providers (ESP) is maintained.\n▪ ESP are not formally managed according to criticality.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address identified weaknesses or deficiencies in the security of the supply chain", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address identified weaknesses or deficiencies in the security of the supply chain ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -124917,7 +132011,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -124938,11 +132033,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to develop and implement a spare parts strategy to ensure that an adequate supply of critical components is available to meet operational needs.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to develop and implement a spare parts strategy to ensure that an adequate supply of critical components is available to meet operational needs. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -125019,7 +132114,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -125042,7 +132138,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel proactively control and monitor third-party accounts used to access, support, or maintain system components via remote access.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to mitigate the risks associated with third-party access to the organization's TAASD.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -125140,7 +132236,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -125165,7 +132262,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to conduct a risk assessment prior to the acquisition or outsourcing of technology-related Technology Assets, Applications and/or Services (TAAS).", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -125264,7 +132361,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -125358,7 +132456,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -125381,7 +132480,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure that the interests of external service providers are consistent with and reflect organizational interests.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -125461,7 +132560,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -125486,7 +132586,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to restrict the location of information processing/storage based on business requirements.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to restrict the location of information processing/storage based on business requirements. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -125582,7 +132682,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -125590,7 +132691,7 @@ "title": "Third-Party Contract Requirements", "family": "TPM", "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting its needs to protect its Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -125609,7 +132710,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.\n▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its TAASD.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -125708,9 +132809,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-05.1", @@ -125730,7 +132831,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to compel External Service Providers (ESPs) to provide notification of actual or potential compromises in the supply chain that can potentially affect or have adversely affected Technology Assets, Applications and/or Services (TAAS) that the organization utilizes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -125827,7 +132928,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -125850,7 +132952,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.\n▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure applicable security, compliance and resilience requirements are included in contracts that flow-down to applicable sub-contractors and suppliers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -125926,9 +133028,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-05.3", @@ -125950,7 +133052,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure External Service Providers (ESPs) use unique authentication factors for each of its customers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -126016,7 +133118,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -126039,9 +133142,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel govern third-party cybersecurity and data protection roles and responsibilities through a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar shared responsibilities tracking tool.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to document and maintain a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to delineate assignment for security, compliance and resilience controls between internal stakeholders and External Service Providers (ESPs).", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to document and maintain a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to delineate assignment for security, compliance and resilience controls between internal stakeholders and External Service Providers (ESPs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -126117,9 +133220,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-05.5", @@ -126141,7 +133244,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to perform recurring validation of the Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to ensure security, compliance and resilience control assignments accurately reflect current:\n(1) Contractual obligations for the External Service Provider (ESP);\n(2) Business practices;\n(3) Applicable stakeholders; and\n(4) Deployed Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -126203,9 +133306,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-05.6", @@ -126227,9 +133330,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to obtain a First-Party Declaration(1PD) from applicable External Service Providers (ESPs) that provides assurance of compliance with specified statutory, regulatory and contractual obligations for security, compliance and resilience controls, including any flow-down requirements to subcontractors.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to obtain a First-Party Declaration(1PD) from applicable External Service Providers (ESPs) that provides assurance of compliance with specified statutory, regulatory and contractual obligations for security, compliance and resilience controls, including any flow-down requirements to subcontractors. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -126302,9 +133405,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-05.7", @@ -126326,7 +133429,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Contracts with ESP contain break clauses to enable penalty-free, early termination of a contract for cause, based on ESP cybersecurity and/or data protection practices deficiency(ies).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to include \"break clauses\" within contracts for failure to meet contract criteria for security, compliance and/or resilience controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -126399,9 +133502,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-05.8", @@ -126495,9 +133598,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-06", @@ -126519,7 +133622,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to control personnel security requirements including security roles and responsibilities for third-party providers.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -126616,7 +133719,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -126637,9 +133741,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of organizational information.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of organizational information. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -126698,7 +133802,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -126721,9 +133826,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -126803,9 +133908,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-09", @@ -126827,9 +133932,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -126924,7 +134029,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -126947,7 +134053,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to control changes to services by suppliers, taking into account the criticality of business TAASD that are in scope by the third-party.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -127045,7 +134151,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -127070,7 +134177,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure response/recovery planning and testing are conducted with critical suppliers/providers.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure response/recovery planning and testing are conducted with critical suppliers/providers. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -127165,7 +134272,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -127173,7 +134281,7 @@ "title": "Foreign Ownership, Control or Influence (FOCI)", "family": "TPM", "description": "Mechanisms exist to minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices.", - "scf_question": "Does the organization minimize risk associate with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices?", + "scf_question": "Does the organization minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -127186,7 +134294,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -127227,9 +134335,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- new control (SCF)" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-12.1", @@ -127249,7 +134357,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to periodically review External Service Providers (ESP) for changes that affect Foreign Ownership, Control or Influence (FOCI).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -127288,9 +134396,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- new control (SCF)" + "MT-27", + "MT-28" + ] }, { "control_id": "TPM-12.2", @@ -127310,7 +134418,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to contractually impose safeguards (e.g., additional controls, access modification, contract termination, etc.) from Foreign Ownership, Control or Influence (FOCI) concerns to ensure that:\n(1) Unauthorized access to sensitive and/or regulated data is prevented; and \n(2) Performance of contracts is not adversely affected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -127355,9 +134463,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- new control (SCF)" + "MT-27", + "MT-28" + ] }, { "control_id": "THR-01", @@ -127478,9 +134586,198 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "THR-01.1", + "title": "Dynamic Threat Awareness", + "family": "THR", + "description": "Mechanisms exist to determine and maintain ongoing awareness of the current cyber threat environment.", + "scf_question": "Does the organization determine and maintain ongoing awareness of the current cyber threat environment?", + "relative_weight": 3, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to determine and maintain ongoing awareness of the current cyber threat environment.", + "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subscribe to CISA alerts\n∙ MS-ISAC free membership", + "small": "∙ CISA and MS-ISAC alerts\n∙ Industry-specific threat intelligence feeds\n∙ Basic threat awareness program", + "medium": "∙ Threat intelligence feeds (CISA, industry ISACs)\n∙ Regular threat landscape reviews\n∙ Integration with security awareness program", + "large": "∙ Threat intelligence program with dedicated analyst\n∙ ISAC membership and information sharing\n∙ Regular executive threat briefings", + "enterprise": "∙ Enterprise threat intelligence program\n∙ Automated threat intelligence feeds and analysis\n∙ ISAC and government information sharing partnerships\n∙ Threat intelligence integrated with SIEM and SOC operations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3" + }, + { + "control_id": "THR-01.2", + "title": "Predictive Cyber Analytics", + "family": "THR", + "description": "Mechanisms exist to employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 3, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use free threat indicators from CISA and MS-ISAC", + "small": "∙ Use free threat indicators from CISA and MS-ISAC\n∙ Basic anomaly detection via endpoint protection tools", + "medium": "∙ SIEM with anomaly detection capabilities\n∙ User and Entity Behavior Analytics (UEBA) basic functionality", + "large": "∙ SIEM/UEBA platform with predictive analytics\n∙ Machine learning-based anomaly detection\n∙ Threat hunting based on behavioral analytics", + "enterprise": "∙ Enterprise SIEM/SOAR with advanced predictive analytics\n∙ AI/ML-based threat detection (e.g., Darktrace, Vectra AI, Microsoft Sentinel ML)\n∙ Dedicated threat analytics team\n∙ Predictive analytics integrated with SOC operations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3" + }, { "control_id": "THR-02", "title": "Indicators of Exposure (IOE)", @@ -127503,9 +134800,9 @@ "0": "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.", "1": "Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Threat management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop Indicators of Exposure (IOE) to understand the potential attack vectors that attackers could use to attack the organization.", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop Indicators of Exposure (IOE) to understand the potential attack vectors that attackers could use to attack the organization. ", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -127564,7 +134861,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -127657,7 +134955,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -127746,7 +135045,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -127771,7 +135071,7 @@ "0": "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.", "1": "Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Threat management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to implement an insider threat program that includes a cross-discipline insider threat incident handling team.", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to implement an insider threat program that includes a cross-discipline insider threat incident handling team. ", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -127844,7 +135144,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -127869,7 +135170,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to utilize security awareness training on recognizing and reporting potential indicators of insider threat.", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -127944,7 +135245,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -127967,7 +135269,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to establish a Vulnerability Disclosure Program (VDP) to assist with the secure development and maintenance of Technology Assets, Applications and/or Services (TAAS) that receives unsolicited input from the public about vulnerabilities in organizational TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -128014,7 +135316,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128035,7 +135338,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to enable public submissions of discovered or potential security vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -128080,7 +135383,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128103,7 +135407,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to perform cyber threat hunting that uses Indicators of Compromise (IoC) to detect, track and disrupt threats that evade existing security controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -128178,7 +135482,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128199,7 +135504,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to embed false data or steganographic data in files to enable the organization to determine if data has been exfiltrated and provide a means to identify the individual(s) involved.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -128242,7 +135547,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128265,7 +135571,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop and keep current a catalog of applicable internal and external threats to the organization, both natural and manmade.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -128319,7 +135625,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128396,7 +135703,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128423,7 +135731,7 @@ "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to automatically establish behavioral baselines that capture information about user and entity behavior to enable dynamic threat discovery.", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -128491,7 +135799,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128615,7 +135924,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128638,7 +135948,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to define and manage the scope for its attack surface management activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -128728,7 +136038,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128754,11 +136065,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that vulnerabilities are properly identified, tracked and remediated.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -128846,9 +136157,119 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, + { + "control_id": "VPM-02.1", + "title": "Known Exploited Vulnerabilities (KEV) Mitigations", + "family": "VPM", + "description": "Mechanisms exist to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions.", + "scf_question": "Does the organization prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions?", + "relative_weight": 7, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ IT and/or cybersecurity personnel apply software patches through an informal process.", + "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.\n▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Subscribe to CISA KEV catalog alerts (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)\n∙ Prioritize patching KEV-listed vulnerabilities within CISA timeframes", + "small": "∙ CISA KEV catalog subscription and monitoring\n∙ Priority patching for KEV-listed vulnerabilities within CISA-defined windows", + "medium": "∙ KEV-integrated vulnerability management program\n∙ CISA KEV catalog integration with vulnerability scanner\n∙ Accelerated remediation SLAs for KEV items", + "large": "∙ Enterprise vulnerability management with KEV prioritization\n∙ Automated KEV alerting and remediation tracking\n∙ Defined KEV remediation SLAs", + "enterprise": "∙ Enterprise KEV management program\n∙ Automated CISA KEV catalog integration\n∙ Real-time KEV exposure tracking and alerting\n∙ Risk-based KEV remediation with board-level visibility for material exposures" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community" + }, { "control_id": "VPM-03", "title": "Vulnerability Ranking", @@ -128872,9 +136293,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -128946,7 +136367,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -128967,7 +136389,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify, assess, prioritize and document the potential impact(s) and likelihood(s) of applicable internal and external threats exploiting known vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -129015,7 +136437,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129039,11 +136462,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -129128,7 +136551,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129149,7 +136573,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to install the latest stable version of any software and/or security-related updates on all applicable systems.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -129219,7 +136643,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129240,11 +136665,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and correct flaws related to the collection, usage, processing or dissemination of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -129298,7 +136723,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129328,7 +136754,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Documented deferred patch register (spreadsheet)\n∙ Management sign-off for deferred patches with interim mitigations documented", + "small": "∙ Formal deferred patch register\n∙ Risk-based justification and management approval\n∙ Compensating control documentation", + "medium": "∙ Deferred patching exception process within vulnerability management program\n∙ Compensating control requirements for deferred patches\n∙ GRC platform for exception tracking", + "large": "∙ Enterprise deferred patch management process\n∙ Formal exception approval with compensating controls\n∙ GRC platform for tracking and reporting\n∙ Regular review of aged deferred patches", + "enterprise": "∙ Enterprise patch exception management program\n∙ Automated deferred patch tracking and escalation\n∙ Compensating control validation for all exceptions\n∙ Board-level reporting on material deferred patches" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -129383,7 +136815,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129391,7 +136824,7 @@ "title": "Software & Firmware Patching", "family": "VPM", "description": "Mechanisms exist to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", - "scf_question": "Does the organization conduct software patching for all deployed systems, applications and firmware?", + "scf_question": "Does the organization conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -129407,11 +136840,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -129498,7 +136931,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129519,9 +136953,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to centrally-manage the flaw remediation process.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to centrally-manage the flaw remediation process. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -129606,7 +137040,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129627,9 +137062,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically determine the state of system components with regard to flaw remediation.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically determine the state of system components with regard to flaw remediation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -129675,7 +137110,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129696,11 +137132,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to track the effectiveness of remediation operations through metrics reporting.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -129750,7 +137186,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129839,7 +137276,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129862,9 +137300,9 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -129907,7 +137345,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -129932,7 +137371,7 @@ "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform due diligence on software and/or firmware update stability by conducting pre-production testing in a non-production environment.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -129996,7 +137435,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130017,11 +137457,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform out-of-cycle software and/or firmware updates to address time-sensitive remediations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -130085,7 +137525,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130174,7 +137615,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130202,7 +137644,7 @@ "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel configure technologies to update vulnerability scanning tools.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -130268,7 +137710,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130356,7 +137799,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130379,7 +137823,7 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify the breadth and depth of coverage for vulnerability scanning that define the system components scanned and types of vulnerabilities that are checked for.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify the breadth and depth of coverage for vulnerability scanning that define the system components scanned and types of vulnerabilities that are checked for. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -130442,7 +137886,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130463,9 +137908,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement privileged access authorization for selected vulnerability scanning activities.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement privileged access authorization for selected vulnerability scanning activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -130528,7 +137973,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130549,9 +137995,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically compare the results of vulnerability scans over time to determine trends in system vulnerabilities.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically compare the results of vulnerability scans over time to determine trends in system vulnerabilities. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -130613,7 +138059,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130636,9 +138083,9 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to review historical event logs to determine if identified vulnerabilities have been previously exploited.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to review historical event logs to determine if identified vulnerabilities have been previously exploited. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -130699,7 +138146,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130802,7 +138250,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130905,7 +138354,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -130926,7 +138376,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to define what information is allowed to be discoverable by adversaries and take corrective actions to remediate non-compliant Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -130964,7 +138414,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131020,7 +138471,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131044,7 +138496,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, conduct annual penetration testing on network segments hosting High Value Assets (HVAs).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct penetration testing on Technology Assets, Applications and/or Services (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -131128,7 +138580,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131151,7 +138604,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, use red team exercises to simulate attempts by adversaries to compromise TAASD in accordance with entity-defined rules of engagement.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize an independent assessor or penetration team to perform penetration testing.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -131229,7 +138682,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131250,7 +138704,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a technical surveillance countermeasures survey.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -131302,7 +138756,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131323,11 +138778,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to monitor logs associated with scanning activities and associated administrator accounts to ensure that those activities are limited to the timeframes of legitimate scans.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to monitor logs associated with scanning activities and associated administrator accounts to ensure that those activities are limited to the timeframes of legitimate scans. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -131370,7 +138825,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131393,7 +138849,7 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, use red team exercises to simulate attempts by adversaries to compromise TAASD in accordance with entity-defined rules of engagement.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize \"red team\" exercises to simulate attempts by adversaries to compromise Technology Assets, Applications and/or Services (TAAS) in accordance with organization-defined rules of engagement.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize \"red team\" exercises to simulate attempts by adversaries to compromise Technology Assets, Applications and/or Services (TAAS) in accordance with organization-defined rules of engagement. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -131481,7 +138937,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131583,7 +139040,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131604,7 +139062,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to prevent unauthorized code from being present in a secure page as it is rendered in a client’s browser.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -131666,7 +139124,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131687,7 +139146,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to utilize a Demilitarized Zone (DMZ) to restrict inbound traffic to authorized Technology Assets, Applications and/or Services (TAAS) on certain services, protocols and ports.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -131752,7 +139211,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131773,9 +139233,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy Web Application Firewalls (WAFs) to provide defense-in-depth protection for application-specific threats.", + "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy Web Application Firewalls (WAFs) to provide defense-in-depth protection for application-specific threats. ", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -131819,7 +139279,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131840,7 +139301,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy reasonably-expected security, compliance and resilience controls to protect the confidentiality and availability of client data that is stored, transmitted or processed by the Internet-based service.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -131897,9 +139358,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "errata": "- wordsmithed" + "MT-27", + "MT-28" + ] }, { "control_id": "WEB-05", @@ -131919,7 +139380,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to provide individuals with clear and precise information about cookies, in accordance with applicable legal requirements for cookie management.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -131967,7 +139428,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -131988,11 +139450,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to implement Strong Customer Authentication (SCA) for consumers to reasonably prove their identity.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. " }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -132047,7 +139509,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -132068,7 +139531,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure the Open Web Application Security Project (OWASP) Application Security Verification Standard is incorporated into the organization's Secure Systems Development Lifecycle (SSDLC) process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -132123,15 +139586,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "WEB-08", "title": "Web Application Framework", "family": "WEB", - "description": "Mechanisms exist to ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs.", - "scf_question": "Does the organization ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs?", + "description": "Mechanisms exist to use a robust Web Application Framework to support the development of secure web applications, including web services, web resources and web Application Programming Interfaces (APIs).", + "scf_question": "Does the organization use a robust Web Application Framework to support the development of secure web applications, including web services, web resources and web Application Programming Interfaces (APIs)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -132144,7 +139608,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -132152,7 +139616,6 @@ }, "profiles": [], "possible_solutions": { - "micro_small": "∙ Use a security-tested web framework", "small": "∙ Approved secure web framework policy\n∙ Use maintained frameworks only", "medium": "∙ Formal web application framework security requirements\n∙ Approved framework list", "large": "∙ Enterprise web framework governance program\n∙ Security-approved frameworks\n∙ Framework lifecycle management", @@ -132199,8 +139662,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ] + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control" }, { "control_id": "WEB-09", @@ -132220,7 +139685,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure all input handled by a web application is validated and/or sanitized.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -132275,7 +139740,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -132296,7 +139762,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure all web application content is delivered using cryptographic mechanisms (e.g., TLS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -132353,7 +139819,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -132374,7 +139841,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure output encoding is performed on all content produced by a web application to reduce the likelihood of cross-site scripting and other injection attacks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -132429,7 +139896,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { @@ -132450,7 +139918,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure web applications implement Content-Security-Policy, HSTS and X-Frame-Options response headers to protect both the web application and its users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -132505,15 +139973,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "WEB-13", "title": "Website Change Detection", "family": "WEB", - "description": "Mechanisms exist to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data.", - "scf_question": "Does the organization detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data?", + "description": "Mechanisms exist to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive and/or regulated data.", + "scf_question": "Does the organization detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -132526,9 +139995,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data.", + "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -132588,15 +140057,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] }, { "control_id": "WEB-14", "title": "Publicly Accessible Content Reviews", "family": "WEB", - "description": "Mechanisms exist to routinely review the content on publicly accessible systems for sensitive/regulated data and remove such information, if discovered.", - "scf_question": "Does the organization routinely review the content on publicly accessible systems for sensitive/regulated data and remove such information, if discovered?", + "description": "Mechanisms exist to routinely review the content on publicly accessible systems for sensitive and/or regulated data and remove such information, if discovered.", + "scf_question": "Does the organization routinely review the content on publicly accessible systems for sensitive and/or regulated data and remove such information, if discovered?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -132659,7 +140129,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ] } ] diff --git a/data/scf-assessment-objectives.json b/data/scf-assessment-objectives.json index d37c4fff..98c1105b 100644 --- a/data/scf-assessment-objectives.json +++ b/data/scf-assessment-objectives.json @@ -1,5 +1,5 @@ { - "total": 5776, + "total": 5956, "assessment_objectives": [ { "scf_control_id": "AAT-01", @@ -151,6 +151,76 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A01", + "objective": "mechanisms exist to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A02", + "objective": "the assigned class determines applicable approval requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A03", + "objective": "the assigned class determines applicable security, compliance and/or resilience controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A04", + "objective": "the assigned class determines applicable testing rigor.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A05", + "objective": "the assigned class determines applicable monitoring requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A06", + "objective": "the assigned class determines applicable supporting documentation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A07", + "objective": "the assigned class determines applicable oversight requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AAT-02", "ao_id": "AAT-02_A01", @@ -1311,6 +1381,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AAT-12.5", + "ao_id": "AAT-12.5_A01", + "objective": "the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT) is validated.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-12.6", + "ao_id": "AAT-12.6_A01", + "objective": "Artificial Intelligence and Autonomous Technologies (AAT) is prohibited from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AAT-13", "ao_id": "AAT-13_A01", @@ -3371,6 +3461,46 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A01", + "objective": "automated mechanisms enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A02", + "objective": "enforced resource limits address energy consumption.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A03", + "objective": "enforced resource limits address processing capacity.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A04", + "objective": "enforced resource limits address financial consumption (e.g., allocated budget).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AAT-30", "ao_id": "AAT-30_A01", @@ -3471,6 +3601,46 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A01", + "objective": "a Release Owner Gate (ROG), or similar function, prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A02", + "objective": "the review and approval process validates material facts.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A03", + "objective": "the review and approval process validates citations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A04", + "objective": "the review and approval process validates other relevant content that could discredit the organization.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AST-01", "ao_id": "AST-01_A01", @@ -4461,6 +4631,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A01", + "objective": "reasonable physical security protections for storage are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A02", + "objective": "processes exist to define criteria for Technology Assets, Applications, Services and/or Data (TAASD) storage", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A03", + "objective": "Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AST-06", "ao_id": "AST-06_A01", @@ -9131,6 +9331,76 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "CFG-09", + "ao_id": "CFG-09_A01", + "objective": "an authoritative repository for production software is established.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.1", + "ao_id": "CFG-09.1_A01", + "objective": "the use and import of third-party libraries and/or software components to trustworthy sources is restricted.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A01", + "objective": "software repositories are protected from importing untrusted and/or malicious software artifacts.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A02", + "objective": "software artifacts are scanned for malicious content.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A03", + "objective": "a digital signature or secure hash provided over a secure channel is verified.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A04", + "objective": "software artifacts are scanned to identify plain text or encoded secrets and keys.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.3", + "ao_id": "CFG-09.3_A01", + "objective": "an authoritative repository for software development activities is maintained that is separate from production software.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "CHG-01", "ao_id": "CHG-01_A01", @@ -11461,6 +11731,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "CPL-03.8", + "ao_id": "CPL-03.8_A01", + "objective": "Continuous Control Monitoring (CCM) scoping is defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CPL-03.8", + "ao_id": "CPL-03.8_A02", + "objective": "automated mechanisms exist to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization's Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "CPL-04", "ao_id": "CPL-04_A01", @@ -18971,6 +19261,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "GOV-01.4", + "ao_id": "GOV-01.4_A01", + "objective": "the organization's Security, Compliance & Resilience Program (SCRP) is aligned with one or more industry-recognized frameworks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-01.4", + "ao_id": "GOV-01.4_A02", + "objective": "the framework alignment provides defensible justification for secure practices.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "GOV-02", "ao_id": "GOV-02_A01", @@ -19521,6 +19831,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "GOV-10.1", + "ao_id": "GOV-10.1_A01", + "objective": "a data catalog exists.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-10.1", + "ao_id": "GOV-10.1_A02", + "objective": "data is cataloged in a structured format to document each significant data asset.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "GOV-11", "ao_id": "GOV-11_A01", @@ -19911,6 +20241,46 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A01", + "objective": "organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A02", + "objective": "the internal oversight capabilities demonstrate governance of internal controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A03", + "objective": "the internal oversight capabilities demonstrate risk management, including analysis and mitigation activities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A04", + "objective": "the internal oversight capabilities demonstrate compliance with applicable laws, regulations and contractual obligations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "GOV-20", "ao_id": "GOV-20_A01", @@ -19931,6 +20301,76 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A01", + "objective": "A High Value Assets (HVAs) catalog is created.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A02", + "objective": "criteria are defined for high-value Intellectual Property (IP) to be categorized as a \"crown jewel.\"", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A03", + "objective": "criteria are defined for Technology Assets, Applications and Services (TAAS) to be categorized as a \"crown jewel,\" based on business process criticality or dependency relationships.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A04", + "objective": "the physical and/or logical location of HVAs are documented.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A05", + "objective": "assigned owners are defined for HVAs", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A06", + "objective": "minimum protection mechanisms for HVAs are defined.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A07", + "objective": "assurance requirements for HVAs are defined.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "HRS-01", "ao_id": "HRS-01_A01", @@ -22301,6 +22741,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A01", + "objective": "identity providers and authorization servers are employed to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A02", + "objective": "authentication and authorization decisions are made in accordance with organization-defined identification and authentication policy.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A03", + "objective": "authentication and authorization decisions use organization-defined mechanisms.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "IAC-02", "ao_id": "IAC-02_A01", @@ -25651,6 +26121,16 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "IAC-15.10", + "ao_id": "IAC-15.10_A01", + "objective": "non-privileged accounts are separated between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "IAC-16", "ao_id": "IAC-16_A01", @@ -34118,7 +34598,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.03.01.a", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "SDP values:\nat a minimum and where applicable:\n(1) Authentication events:\n (a) Logons (Success/Failure)\n (b) Logoffs (Success)\n(2) Security Relevant File and Objects events:\n (a) Create (Success/Failure)\n (b) Access (Success/Failure)\n (c) Delete (Success/Failure)\n (d) Modify (Success/Failure)\n (e) Permission Modification (Success/Failure)\n (f) Ownership Modification (Success/Failure)\n(3) Export/Writes/downloads to devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(4) Import/Uploads from devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(5) User and Group Management events:\n (a) User add, delete, modify, disable, lock (Success/Failure)\n (b) Group/Role add, delete, modify (Success/Failure)\n6) Use of Privileged/Special Rights events:\n (a) Security or audit policy changes (Success/Failure)\n (b) Configuration changes (Success/Failure)\n(7) Admin or root-level access (Success/Failure)\n(8) Privilege/Role escalation (Success/Failure)\n(9) Audit and security relevant log data accesses (Success/Failure)\n(10) System reboot, restart, and shutdown (Success/Failure)\n(11) Print to a device (Success/Failure)\n(12) Print to a file (e.g., pdf format) (Success/Failure)\n(13) Application (e.g., Adobe, Firefox, MS Office Suite) initialization (Success/Failure)\n\nFor additional guidance, see: OMB21-31 ML 1", + "scf_defined_parameters": "SDP values:\nat a minimum and where applicable:\n(1) Authentication events:\n (a) Logons (Success/Failure)\n (b) Logoffs (Success)\n(2) Security Relevant File and Objects events:\n (a) Create (Success/Failure)\n (b) Access (Success/Failure)\n (c) Delete (Success/Failure)\n (d) Modify (Success/Failure)\n (e) Permission Modification (Success/Failure)\n (f) Ownership Modification (Success/Failure)\n(3) Export/Writes/downloads to devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(4) Import/Uploads from devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(5) User and Group Management events:\n (a) User add, delete, modify, disable, lock (Success/Failure)\n (b) Group/Role add, delete, modify (Success/Failure)\n6) Use of Privileged/Special Rights events:\n (a) Security or audit policy changes (Success/Failure)\n (b) Configuration changes (Success/Failure)\n(7) Admin or root-level access (Success/Failure)\n(8) Privilege/Role escalation (Success/Failure)\n(9) Audit and security relevant log data accesses (Success/Failure)\n(10) System reboot, restart, and shutdown (Success/Failure)\n(11) Print to a device (Success/Failure)\n(12) Print to a file (e.g., pdf format) (Success/Failure)\n(13) Application (e.g., Adobe, Firefox, MS Office Suite) initialization (Success/Failure)\n\nFor additional guidance, see: OMB21-31 ML 1", "org_defined_parameters": "" }, { @@ -38221,6 +38701,46 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A01", + "objective": "automated mechanisms separate network appliance functions (e.g., management, control and data planes).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A02", + "objective": "separation prevents ordinary traffic from accessing functions that manage network appliances.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A03", + "objective": "separation prevents ordinary traffic from accessing functions that affect network operations.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "NET-06.9", + "ao_id": "NET-06.9_A01", + "objective": "subnetworks are physically or logically separate to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "NET-07", "ao_id": "NET-07_A01", @@ -42561,6 +43081,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "PRI-01.12", + "ao_id": "PRI-01.12_A01", + "objective": "the organization's data privacy principles are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "PRI-01.12", + "ao_id": "PRI-01.12_A02", + "objective": "the organization's data privacy principles are formally incorporated into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "PRI-02", "ao_id": "PRI-02_A01", @@ -46961,6 +47501,1056 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A01", + "objective": "an executive-sponsored quantum risk governance structure is established that institutionalizes quantum risk in the same manner as other enterprise risks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A02", + "objective": "a named migration lead with defined authority is assigned.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A03", + "objective": "quantum risk is treated as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A01", + "objective": "a formal, documented quantum security policy is established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A02", + "objective": "the quantum security policy conveys executive management's intent.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A03", + "objective": "the quantum security policy provides organizational direction and expected behaviors.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A04", + "objective": "the quantum security policy is reviewed at least annually.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A05", + "objective": "the quantum security policy is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.2", + "ao_id": "QTS-01.2_A01", + "objective": "a classification scheme exists to determine confidentiality shelf-life.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.2", + "ao_id": "QTS-01.2_A02", + "objective": "the shelf-life classification is used as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.3", + "ao_id": "QTS-01.3_A01", + "objective": "Technology Assets, Applications, Services and Data (TAASD) are classified according to confidentiality shelf-life.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A01", + "objective": "Harvest Now, Decrypt Later (HNDL) risk is mitigated through Zero Trust Network Access (ZTNA).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A02", + "objective": "ZTNA enforces continuous authentication.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A03", + "objective": "ZTNA enforces data microsegmentation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A04", + "objective": "ZTNA enforces least privilege.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A05", + "objective": "ZTNA enforces identity-based access control.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A01", + "objective": "a Cryptographic Agility Risk Assessment (CARA) methodology is defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A02", + "objective": "a CARA is performed to map Technology Assets, Applications, Services and Data (TAASD).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A03", + "objective": "the CARA identifies TAASD most vulnerable to quantum-enabled cryptanalytic threats.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A04", + "objective": "the CARA prioritizes TAASD based on potential business impact.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A01", + "objective": "each Post-Quantum Cryptography (PQC) deviation is governed through a formal cryptographic exception register.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A02", + "objective": "the exception register contains the asset and/or process owner(s).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A03", + "objective": "the exception register contains compensating control(s).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A04", + "objective": "the exception register contains the planned remediation date.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A05", + "objective": "the exception register contains the re-evaluation date.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.2", + "ao_id": "QTS-02.2_A01", + "objective": "short-term compensating measures are implemented for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.3", + "ao_id": "QTS-02.3_A01", + "objective": "progress is measured in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A01", + "objective": "a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) is developed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A02", + "objective": "the PQCAP enables cryptographic agility.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A03", + "objective": "the PQCAP aligns with evolving security standards.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A04", + "objective": "the PQCAP defines the approach for selecting and implementing PQC algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.1", + "ao_id": "QTS-03.1_A01", + "objective": "sufficient resources are allocated to transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.1", + "ao_id": "QTS-03.1_A02", + "objective": "hybrid cryptography is supported during a defined transition period, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A01", + "objective": "reportable metrics for Post-Quantum Cryptography (PQC) migration are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A02", + "objective": "the metrics measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A03", + "objective": "the metrics report progress periodically to executive leadership.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A01", + "objective": "vendors are required to disclose Post-Quantum Cryptography (PQC) support roadmaps.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A02", + "objective": "the roadmaps include identification of PQC-related limitations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A03", + "objective": "the roadmaps include supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.4", + "ao_id": "QTS-03.4_A01", + "objective": "vendors are contractually obligated to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04", + "ao_id": "QTS-04_A01", + "objective": "means to gain situational awareness into the organization's current cryptographic landscape through a formal discovery process are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04", + "ao_id": "QTS-04_A02", + "objective": "the discovery process uses available tools to generate situational awareness.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A01", + "objective": "a current inventory of cryptographic assets is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A02", + "objective": "the inventory includes algorithms (asymmetric and symmetric).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A03", + "objective": "the inventory includes key lengths.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A04", + "objective": "the inventory includes libraries.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A05", + "objective": "the inventory includes protocols.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A06", + "objective": "the inventory includes associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A07", + "objective": "the inventory includes Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A01", + "objective": "a Cryptographic Bill of Materials (CBOM) is maintained to analyze the organization's cryptographic architecture.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A02", + "objective": "the CBOM includes hardware.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A03", + "objective": "the CBOM includes firmware.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A04", + "objective": "the CBOM includes software modules.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A05", + "objective": "the CBOM includes communication protocols.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A01", + "objective": "a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A02", + "objective": "the inventory includes public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A03", + "objective": "the inventory includes long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A04", + "objective": "the inventory includes TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A01", + "objective": "differentiated quantum security training content is developed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A02", + "objective": "differentiated quantum security awareness training to the general workforce.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A03", + "objective": "differentiated quantum security awareness training to technical roles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A04", + "objective": "differentiated quantum security awareness training to leadership roles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A01", + "objective": "a quantum threat intelligence function is established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A02", + "objective": "the function monitors cryptanalytic threat developments.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A03", + "objective": "the function monitors quantum computing capability advances.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A04", + "objective": "the function monitors NIST and/or regulatory updates to approved algorithm lists.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.2", + "ao_id": "QTS-05.2_A01", + "objective": "stakeholders participation in sector-appropriate quantum security forums.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06", + "ao_id": "QTS-06_A01", + "objective": "design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) is validated to support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A01", + "objective": "validated entropy sources and random bit generators comply with NIST SP 800-90B.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A02", + "objective": "the entropy sources support Post-Quantum Cryptography (PQC) key generation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A03", + "objective": "the entropy sources support nonce generation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A04", + "objective": "the entropy sources support probabilistic algorithm inputs.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A05", + "objective": "the entropy sources support key validation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A01", + "objective": "stateful hash-based signature schemes conform with NIST SP 800-208.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A02", + "objective": "state-management controls necessary to prevent one-time key reuse are required.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A03", + "objective": "stateful hash-based signatures are enforced for firmware signing.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A04", + "objective": "stateful hash-based signatures are enforced for secure boot signing.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A05", + "objective": "stateful hash-based signatures are enforced for other long-lifetime code-signing use cases.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.3", + "ao_id": "QTS-06.3_A01", + "objective": "Post-Quantum Cryptography (PQC) algorithms are approved.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.3", + "ao_id": "QTS-06.3_A02", + "objective": "required validation levels for approved algorithms (e.g., FIPS 140-3 validated) are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.4", + "ao_id": "QTS-06.4_A01", + "objective": "Technology Assets, Applications and/or Services (TAAS) are configured to use FIPS 140-3 validated cryptographic modules, where applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.5", + "ao_id": "QTS-06.5_A01", + "objective": "quantum-vulnerable and otherwise deprecated cryptographic algorithms are prohibited from being used.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A01", + "objective": "cryptographic keys and certificates are managed in a manner that supports Post-Quantum Cryptography (PQC) transition.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A02", + "objective": "validity periods for quantum-vulnerable certificates are shortened to reduce exposure.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A03", + "objective": "Public Key Infrastructure (PKI) is prepared for PQC roots of trust or dual-root hybrid trust models.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A04", + "objective": "key generation uses quantum-safe entropy sources.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.7", + "ao_id": "QTS-06.7_A01", + "objective": "Public Key Infrastructure (PKI) trust anchors are transitioned to quantum-safe algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A01", + "objective": "Technology Assets, Applications and/or Services (TAAS) are configured to prevent attackers from forcing quantum-vulnerable algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A02", + "objective": "integrity-protected algorithm negotiation is used (e.g., TLS 1.3 handshake transcript).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A03", + "objective": "negotiation of classical-only cipher suites is disallowed once Post-Quantum Cryptography (PQC) is deployed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A04", + "objective": "downgrade attempts are monitored.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A01", + "objective": "hybrid/composite algorithms are leveraged as a transition path to Post-Quantum Cryptography (PQC) solutions, where applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A02", + "objective": "solutions support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A03", + "objective": "certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A04", + "objective": "plans exist for eventual removal of classical algorithms once PQC confidence is sufficient.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.10", + "ao_id": "QTS-06.10_A01", + "objective": "universal interface is used to bridge established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A01", + "objective": "capability exists to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A02", + "objective": "pre-identified algorithm alternates are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A03", + "objective": "tested rollback and roll-forward procedures are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A04", + "objective": "customer and/or counterparty communication templates are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A05", + "objective": "incident response rehearsals against defined scenarios are conducted.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A01", + "objective": "Post-Quantum Cryptography (PQC) implementations are validated for functional and cryptographic requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A02", + "objective": "each PQC implementation is interoperable with counterparties and successors.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A03", + "objective": "each PQC implementation meets performance criteria for its use case.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A04", + "objective": "test results and exceptions are documented.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "RSK-01", "ao_id": "RSK-01_A01", @@ -47078,7 +48668,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.17.03.b", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", + "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", "org_defined_parameters": "" }, { @@ -47441,6 +49031,16 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "RSK-03.2", + "ao_id": "RSK-03.2_A01", + "objective": "a risk owner is identified for each item in the risk register to ensure clear accountability for unremediated risks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "RSK-04", "ao_id": "RSK-04_A01", @@ -48208,7 +49808,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.17.03.b", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", + "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", "org_defined_parameters": "" }, { @@ -49361,6 +50961,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "SAT-04.1", + "ao_id": "SAT-04.1_A01", + "objective": "individual training results are monitored.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SAT-04.1", + "ao_id": "SAT-04.1_A02", + "objective": "training results are reported to applicable stakeholders.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "SAT-05", "ao_id": "SAT-05_A01", @@ -49641,6 +51261,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "SEA-01.4", + "ao_id": "SEA-01.4_A01", + "objective": "security architecture principles are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-01.4", + "ao_id": "SEA-01.4_A02", + "objective": "security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-01.5", + "ao_id": "SEA-01.5_A01", + "objective": "secure architecture principles are incorporated into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "SEA-02", "ao_id": "SEA-02_A01", @@ -50431,6 +52081,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A01", + "objective": "a frequency is defined for information to be regenerated or refreshed.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A02", + "objective": "information is generated or refreshed per an organization-defined frequency.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A03", + "objective": "mechanisms exist to delete information when no longer needed.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "SEA-09", "ao_id": "SEA-09_A01", @@ -52711,6 +54391,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "TDA-06.7", + "ao_id": "TDA-06.7_A01", + "objective": "organization-approved programming language(s) for software development are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-06.7", + "ao_id": "TDA-06.7_A02", + "objective": "the justification for program language alignment selection decisions are documented.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "TDA-07", "ao_id": "TDA-07_A01", @@ -53461,6 +55161,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "TDA-13.1", + "ao_id": "TDA-13.1_A01", + "objective": "a cybersecurity knowledge and skills register for developers is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-13.2", + "ao_id": "TDA-13.2_A01", + "objective": "requisite skillsets for developers for Secure Software Development Practices (SSDP) are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-13.2", + "ao_id": "TDA-13.2_A02", + "objective": "developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP) are trained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "TDA-14", "ao_id": "TDA-14_A01", @@ -54081,6 +55811,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "TDA-19.1", + "ao_id": "TDA-19.1_A01", + "objective": "personnel and/or role(s) authorized to receive security-relevant error messages are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-19.1", + "ao_id": "TDA-19.1_A02", + "objective": "access to error messages are restricted to authorized personnel and/or role(s).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "TDA-20", "ao_id": "TDA-20_A01", @@ -54331,6 +56081,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "THR-01.1", + "ao_id": "THR-01.1_A01", + "objective": "ongoing awareness of the current cyber threat environment is maintained as part of the Threat Intelligence Program (TIP).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "THR-01.2", + "ao_id": "THR-01.2_A01", + "objective": "advanced automation and analytics capabilities are implemented to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "THR-02", "ao_id": "THR-02_A01", @@ -55668,7 +57438,7 @@ "pptdf": "Data", "origin": "171A_R3_A.03.16.03.a", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "SDP values: \n(1) For cloud service providers:\n (i) FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or\n (ii) meets security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline.\n(2) All other external service providers must meet NIST SP 800-171 R2.", + "scf_defined_parameters": "SDP values: \n(1) For cloud service providers:\n (i) FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or\n (ii) meets security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline.\n(2) All other external service providers must meet NIST SP 800-171 R2.", "org_defined_parameters": "" }, { @@ -56341,6 +58111,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A01", + "objective": "remediation and mitigation of Known Exploited Vulnerabilities (KEV) is prioritized.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A02", + "objective": "KEV remediation efforts reduce or remove public exposure to exploitation, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A03", + "objective": "KEV remediation efforts expedite patch deployment actions, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "VPM-03", "ao_id": "VPM-03_A01", diff --git a/data/scf-compensating-controls.json b/data/scf-compensating-controls.json index 0a0887d2..81ed9521 100644 --- a/data/scf-compensating-controls.json +++ b/data/scf-compensating-controls.json @@ -1,5 +1,5 @@ { - "total": 1305, + "total": 1371, "compensating_controls": [ { "control_id": "GOV-01.1", @@ -49,6 +49,22 @@ "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Commitment To Continual Improvements (GOV-01.3) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "GOV-01.4", + "risk_if_not_implemented": "Without Secure Practices Alignment Justification, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides third-party oversight and contractual controls that compensates for the absence of Secure Practices Alignment Justification (GOV-01.4) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-09", + "name": "Define Control Objectives", + "description": "Mechanisms exist to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", + "justification": "Define Control Objectives (GOV-09) provides overlapping security capability that compensates for the absence of Secure Practices Alignment Justification (GOV-01.4) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "GOV-02.1", "risk_if_not_implemented": "Without Exception Management, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -241,6 +257,22 @@ "justification": "Data Privacy Program (PRI-01) provides policy-level governance that compensates for the absence of Data Governance (GOV-10) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "GOV-10.1", + "risk_if_not_implemented": "Without Data Catalog, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "DCH-24", + "name": "Information Location", + "description": "Mechanisms exist to identify and document the location of information and the specific system components on which the information resides.", + "justification": "Information Location (DCH-24) provides overlapping security capability that compensates for the absence of Data Catalog (GOV-10.1) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Data Catalog (GOV-10.1) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "GOV-11", "risk_if_not_implemented": "Without Purpose Validation, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -497,6 +529,22 @@ "justification": "Audit Activities (CPL-04) provides detective monitoring capability that compensates for the absence of Assessment Objectives (AO) (GOV-19.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "GOV-19.3", + "risk_if_not_implemented": "Without Security, Compliance & Resilince Outsourcing Limitations, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "TPM-04", + "name": "Third-Party Services", + "description": "Mechanisms exist to mitigate the risks associated with third-party access to the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Services (TPM-04) provides third-party oversight and contractual controls that compensates for the absence of Security, Compliance & Resilince Outsourcing Limitations (GOV-19.3) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CPL-10", + "name": "Control Inheritance", + "description": "Mechanisms exist to define instances of control inheritance within assessment boundaries.", + "justification": "Control Inheritance (CPL-10) provides overlapping security capability that compensates for the absence of Security, Compliance & Resilince Outsourcing Limitations (GOV-19.3) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "GOV-20", "risk_if_not_implemented": "Without Mergers, Acquisitions & Divestitures (MA&D), residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -529,6 +577,22 @@ "justification": "Risk Assessment (RSK-04) provides periodic assessment and assurance that compensates for the absence of Virtual Data Room (VDR) (GOV-20.1) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "GOV-21", + "risk_if_not_implemented": "Without HVA / crown jewels protections, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Crown Jewels (GOV-21) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-05", + "name": "Risk Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "justification": "Risk Ranking (RSK-05) provides risk identification and prioritization that compensates for the absence of Crown Jewels (GOV-21) by enabling informed decisions about where to focus resources to manage residual exposure. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AAT-01.1", "risk_if_not_implemented": "Without AI & Autonomous Technologies-Related Legal Requirements Definition, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -577,6 +641,22 @@ "justification": "Third-Party Contract Requirements (TPM-05) provides third-party oversight that compensates for the absence of AI Model & Agent Inventory & Lifecycle Management (AAT-01.4) by extending security obligations contractually and monitoring third-party risk in lieu of direct control. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AAT-01.5", + "risk_if_not_implemented": "Without Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "AAT-01", + "name": "Artificial Intelligence (AI) & Autonomous Technologies Governance", + "description": "Mechanisms exist to ensure policies, processes, procedures and practices related to the mapping, measuring and managing of Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related risks are in place, transparent and implemented effectively.", + "justification": "Artificial Intelligence (AI) & Autonomous Technologies Governance (AAT-01) provides detective monitoring capability that compensates for the absence of Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization (AAT-01.5) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-04", + "name": "Risk Assessment", + "description": "Mechanisms exist to conduct recurring assessments of risk that includes the likelihood and magnitude of harm, from unauthorized access, use, disclosure, disruption, modification or destruction of the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Risk Assessment (RSK-04) provides periodic assessment and verification that compensates for the absence of Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization (AAT-01.5) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AAT-02", "risk_if_not_implemented": "Without Situational Awareness of AI & Autonomous Technologies, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -1249,6 +1329,38 @@ "justification": "Third-Party Management (TPM-01) provides third-party oversight that compensates for the absence of Digital Content Modification Logging (AAT-12.4) by extending security obligations contractually and monitoring third-party risk in lieu of direct control. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AAT-12.5", + "risk_if_not_implemented": "Without Training Data Source & Integrity, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "DCH-22", + "name": "Data Quality Operations", + "description": "Mechanisms exist to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", + "justification": "Data Quality Operations (DCH-22) provides overlapping security capability that compensates for the absence of Training Data Source & Integrity (AAT-12.5) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "AAT-10", + "name": "Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV)", + "description": "Mechanisms exist to implement Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices to enable Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related security, resilience and compliance-related conformity testing throughout the lifecycle of the AAT.", + "justification": "Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) (AAT-10) provides periodic assessment and verification that compensates for the absence of Training Data Source & Integrity (AAT-12.5) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "AAT-12.6", + "risk_if_not_implemented": "Without Prohibit Training, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides third-party oversight and contractual controls that compensates for the absence of Prohibit Training (AAT-12.6) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-14", + "name": "Information Sharing", + "description": "Mechanisms exist to utilize a process to assist users in making information sharing decisions to ensure data is appropriately protected.", + "justification": "Information Sharing (DCH-14) provides threat intelligence and situational awareness that compensates for the absence of Prohibit Training (AAT-12.6) by providing early warning of threats and informing proactive security posture adjustments. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AAT-13", "risk_if_not_implemented": "Without AI & Autonomous Technologies Stakeholder Diversity, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -2609,6 +2721,22 @@ "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Agent Output Integrity & Verification (AAT-29.23) by restricting system and data access to authorized users through alternative identity and access mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AAT-29.24", + "risk_if_not_implemented": "Without Resource Limiting, AI and autonomous technology risks may go ungoverned, leading to unintended outcomes, misuse, or data exposure.", + "compensating_control_1": { + "control_id": "CAP-01", + "name": "Capacity & Performance Management", + "description": "Mechanisms exist to facilitate the implementation of capacity management controls to ensure optimal system performance to meet expected and anticipated future capacity requirements.", + "justification": "Capacity & Performance Management (CAP-01) provides overlapping security capability that compensates for the absence of Resource Limiting (AAT-29.24) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Resource Limiting (AAT-29.24) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AAT-30", "risk_if_not_implemented": "Without Agentic Output Traceability & Repudiation, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -2705,6 +2833,22 @@ "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Business Process Task Enumeration (AAT-32.1) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AAT-33", + "risk_if_not_implemented": "Without Release Owner Gate (ROG) For AI-Augmented Content, AI and autonomous technology risks may go ungoverned, leading to unintended outcomes, misuse, or data exposure.", + "compensating_control_1": { + "control_id": "CHG-08", + "name": "Dual Approval For High-Impact Environments", + "description": "Mechanisms exist to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Dual Approval For High-Impact Environments (CHG-08) provides overlapping security capability that compensates for the absence of Release Owner Gate (ROG) For AI-Augmented Content (AAT-33) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-04", + "name": "Assigned Security, Compliance & Resilience Responsibilities", + "description": "Mechanisms exist to assign one or more qualified individuals with the mission and resources to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP).", + "justification": "Assigned Security, Compliance & Resilience Responsibilities (GOV-04) provides resilience and recovery capability that compensates for the absence of Release Owner Gate (ROG) For AI-Augmented Content (AAT-33) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AST-01.1", "risk_if_not_implemented": "Without Asset-Service Dependencies, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -3089,6 +3233,22 @@ "justification": "Media Storage (DCH-06) provides overlapping security capability that compensates for the absence of Management Approval For External Media Transfer (AST-05.1) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AST-05.2", + "risk_if_not_implemented": "Without Technology Assets, Applications, Services and/or Data (TAASD) Storage, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "PES-03", + "name": "Physical Access Control", + "description": "Physical access control mechanisms exist to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", + "justification": "Physical Access Control (PES-03) provides access control enforcement that compensates for the absence of Technology Assets, Applications, Services and/or Data (TAASD) Storage (AST-05.2) by restricting system and data access through alternative identity and access management mechanisms. Given the facility and physical environment focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "PES-06", + "name": "Visitor Control", + "description": "Physical access control mechanisms exist to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible).", + "justification": "Visitor Control (PES-06) provides physical access control that compensates for the absence of Technology Assets, Applications, Services and/or Data (TAASD) Storage (AST-05.2) by preventing unauthorized physical interaction with systems and infrastructure. Given the facility and physical environment focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AST-06", "risk_if_not_implemented": "Without Unattended End-User Equipment, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -5521,6 +5681,22 @@ "justification": "Security, Compliance & Resilience Assessments (CPL-03) provides periodic assessment and assurance that compensates for the absence of Evidence Sampling (CPL-03.7) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "CPL-03.8", + "risk_if_not_implemented": "Without Continuous Control Monitoring (CCM), security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "CPL-03", + "name": "Control Conformity Monitoring", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "justification": "Control Conformity Monitoring (CPL-03) provides detective monitoring capability that compensates for the absence of Continuous Control Monitoring (CCM) (CPL-03.8) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Continuous Control Monitoring (CCM) (CPL-03.8) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "CPL-04", "risk_if_not_implemented": "Without Audit Activities, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -6209,6 +6385,70 @@ "justification": "Access Enforcement (IAC-20) provides access control enforcement that compensates for the absence of Sensitive / Regulated Data Actions (CFG-08.1) by restricting system and data access to authorized users through alternative identity and access mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "CFG-09", + "risk_if_not_implemented": "Without Production Software Repository, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "CHG-02", + "name": "Configuration Change Control", + "description": "Mechanisms exist to govern the technical configuration change control processes.", + "justification": "Configuration Change Control (CHG-02) provides configuration and supply-chain hardening that compensates for the absence of Production Software Repository (CFG-09) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-05", + "name": "Software & Firmware Patching", + "description": "Mechanisms exist to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", + "justification": "Software & Firmware Patching (VPM-05) provides vulnerability management that compensates for the absence of Production Software Repository (CFG-09) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "CFG-09.1", + "risk_if_not_implemented": "Without Third-Party Libraries, third-party risks may go unmanaged, creating supply-chain exposure that compromises organizational systems or data.", + "compensating_control_1": { + "control_id": "TPM-03", + "name": "Supply Chain Risk Management (SCRM)", + "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", + "justification": "Supply Chain Risk Management (SCRM) (TPM-03) provides risk identification and prioritization that compensates for the absence of Third-Party Libraries (CFG-09.1) by enabling informed decisions about where to focus resources to manage residual exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Third-Party Libraries (CFG-09.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "CFG-09.2", + "risk_if_not_implemented": "Without Software Repository Protections, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Software Repository Protections (CFG-09.2) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "END-04", + "name": "Malicious Code Protection (Anti-Malware)", + "description": "Mechanisms exist to utilize antimalware technologies to detect and eradicate malicious code.", + "justification": "Malicious Code Protection (Anti-Malware) (END-04) provides overlapping security capability that compensates for the absence of Software Repository Protections (CFG-09.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "CFG-09.3", + "risk_if_not_implemented": "Without Software Development Repository, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "TDA-08", + "name": "Separation of Development, Testing and Operational Environments", + "description": "Mechanisms exist to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).", + "justification": "Separation of Development, Testing and Operational Environments (TDA-08) provides periodic assessment and verification that compensates for the absence of Software Development Repository (CFG-09.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CHG-04", + "name": "Access Restriction For Change", + "description": "Mechanisms exist to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.", + "justification": "Access Restriction For Change (CHG-04) provides access control enforcement that compensates for the absence of Software Development Repository (CFG-09.3) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "MON-01.1", "risk_if_not_implemented": "Without Intrusion Detection & Prevention Systems (IDS & IPS), security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -10321,6 +10561,22 @@ "justification": "Session Audit (MON-12) provides detective monitoring capability that compensates for the absence of Authenticate, Authorize and Audit (AAA) (IAC-01.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "IAC-01.4", + "risk_if_not_implemented": "Without Identity Providers (IdP) & Authorization Servers, unauthorized users may gain access to systems or data, increasing risk of data breaches and privilege escalation.", + "compensating_control_1": { + "control_id": "IAC-02", + "name": "Identification & Authentication for Organizational Users", + "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", + "justification": "Identification & Authentication for Organizational Users (IAC-02) provides access control enforcement that compensates for the absence of Identity Providers (IdP) & Authorization Servers (IAC-01.4) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-08", + "name": "Role-Based Access Control (RBAC)", + "description": "Mechanisms exist to enforce Role-Based Access Control (RBAC) for Technology Assets, Applications, Services and/or Data (TAASD) to restrict access to individuals assigned specific roles with legitimate business needs.", + "justification": "Role-Based Access Control (RBAC) (IAC-08) provides access control enforcement that compensates for the absence of Identity Providers (IdP) & Authorization Servers (IAC-01.4) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "IAC-02", "risk_if_not_implemented": "Without Identification & Authentication for Organizational Users, unauthorized users may gain access to systems or data, increasing risk of data breaches and insider threats.", @@ -11201,6 +11457,22 @@ "justification": "User Provisioning & De-Provisioning (IAC-07) provides access control enforcement that compensates for the absence of Emergency Accounts (IAC-15.9) by restricting system and data access to authorized users through alternative identity and access mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "IAC-15.10", + "risk_if_not_implemented": "Without Account Separation Between Infrastructure Environments, unauthorized users may gain access to systems or data, increasing risk of data breaches and privilege escalation.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Account Separation Between Infrastructure Environments (IAC-15.10) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-16", + "name": "Privileged Account Management (PAM)", + "description": "Mechanisms exist to restrict and control privileged access rights for users and Technology Assets, Applications and/or Services (TAAS).", + "justification": "Privileged Account Management (PAM) (IAC-16) provides access control enforcement that compensates for the absence of Account Separation Between Infrastructure Environments (IAC-15.10) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "IAC-16.2", "risk_if_not_implemented": "Without Privileged Account Separation, unauthorized users may gain access to systems or data, increasing risk of data breaches and insider threats.", @@ -13713,6 +13985,38 @@ "justification": "Boundary Protection (NET-03) provides network-level access restriction that compensates for the absence of Software Defined Networking (SDN) (NET-06.7) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "NET-06.8", + "risk_if_not_implemented": "Without Network Device Plane Segmentation, network defenses may be weakened, enabling lateral movement and exploitation of unprotected communication pathways.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Network Device Plane Segmentation (NET-06.8) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Network Device Plane Segmentation (NET-06.8) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "NET-06.9", + "risk_if_not_implemented": "Without Separate Subnets To Isolate Functions, network defenses may be weakened, enabling lateral movement and exploitation of unprotected communication pathways.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Separate Subnets To Isolate Functions (NET-06.9) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-04", + "name": "Data Flow Enforcement – Access Control Lists (ACLs)", + "description": "Mechanisms exist to implement and govern Access Control Lists (ACLs) to provide data flow enforcement that explicitly restrict network traffic to only what is authorized.", + "justification": "Data Flow Enforcement – Access Control Lists (ACLs) (NET-04) provides access control enforcement that compensates for the absence of Separate Subnets To Isolate Functions (NET-06.9) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "NET-07", "risk_if_not_implemented": "Without Network Connection Termination, network defenses are weakened, enabling lateral movement and exploitation of unprotected pathways.", @@ -15473,6 +15777,22 @@ "justification": "Data Privacy Program (PRI-01) provides policy-level governance that compensates for the absence of Reasonable Data Privacy Practices (PRI-01.11) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "PRI-01.12", + "risk_if_not_implemented": "Without Privacy-Aware Design, personal data may be processed without adequate privacy safeguards, increasing regulatory and reputational risk.", + "compensating_control_1": { + "control_id": "PRI-01", + "name": "Data Privacy Program", + "description": "Mechanisms exist to facilitate the implementation and operation of data protection controls throughout the data lifecycle to ensure all forms of Personal Data (PD) are processed lawfully, fairly and transparently.", + "justification": "Data Privacy Program (PRI-01) provides policy-level governance that compensates for the absence of Privacy-Aware Design (PRI-01.12) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Privacy-Aware Design (PRI-01.12) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "PRI-02", "risk_if_not_implemented": "Without Data Privacy Notice, personal data may be processed without appropriate safeguards, increasing regulatory and reputational risk.", @@ -17026,37 +17346,581 @@ } }, { - "control_id": "RSK-01.1", - "risk_if_not_implemented": "Without Risk Framing, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", + "control_id": "QTS-01", + "risk_if_not_implemented": "Without Quantum Risk Governance, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", "compensating_control_1": { + "control_id": "RSK-01", + "name": "Risk Management Program", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Quantum Risk Governance (QTS-01) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { "control_id": "GOV-01", "name": "Security, Compliance & Resilience Program (SCRP)", "description": "Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.", - "justification": "Security, Compliance & Resilience Program (SCRP) (GOV-01) provides resilience and recovery capability that compensates for the absence of Risk Framing (RSK-01.1) by ensuring the organization can restore operations and data when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." - }, - "compensating_control_2": { - "control_id": "CPL-01", - "name": "Statutory, Regulatory & Contractual Compliance", - "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", - "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides overlapping security capability that compensates for the absence of Risk Framing (RSK-01.1) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + "justification": "Security, Compliance & Resilience Program (SCRP) (GOV-01) provides resilience and recovery capability that compensates for the absence of Quantum Risk Governance (QTS-01) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, { - "control_id": "RSK-01.2", - "risk_if_not_implemented": "Without Risk Management Resourcing, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", + "control_id": "QTS-01.1", + "risk_if_not_implemented": "Without Quantum Security Policy, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", "compensating_control_1": { - "control_id": "CPL-01", - "name": "Statutory, Regulatory & Contractual Compliance", - "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", - "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides overlapping security capability that compensates for the absence of Risk Management Resourcing (RSK-01.2) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + "control_id": "GOV-01", + "name": "Security, Compliance & Resilience Program (SCRP)", + "description": "Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.", + "justification": "Publishing Security, Compliance & Resilience Documentation (GOV-02) provides resilience and recovery capability that compensates for the absence of Quantum Security Policy (QTS-01.1) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." }, "compensating_control_2": { - "control_id": "RSK-01", - "name": "Risk Management Program", - "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls.", - "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Risk Management Resourcing (RSK-01.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." - } - }, + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Quantum Security Policy (QTS-01.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-01.2", + "risk_if_not_implemented": "Without Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization (QTS-01.2) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-05", + "name": "Risk Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "justification": "Risk Ranking (RSK-05) provides risk identification and prioritization that compensates for the absence of Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization (QTS-01.2) by enabling informed decisions about where to focus resources to manage residual exposure. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-01.3", + "risk_if_not_implemented": "Without Long-Lived Data Identification, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Long-Lived Data Identification (QTS-01.3) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-18", + "name": "Media & Data Retention", + "description": "Mechanisms exist to retain media and data in accordance with applicable statutory, regulatory and contractual obligations.", + "justification": "Media & Data Retention (DCH-18) provides overlapping security capability that compensates for the absence of Long-Lived Data Identification (QTS-01.3) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-01.4", + "risk_if_not_implemented": "Without Harvest Now, Decrypt Later (HNDL) Mitigation, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CRY-03", + "name": "Transmission Confidentiality", + "description": "Cryptographic mechanisms exist to protect the confidentiality of data being transmitted.", + "justification": "Transmission Confidentiality (CRY-03) provides overlapping security capability that compensates for the absence of Harvest Now, Decrypt Later (HNDL) Mitigation (QTS-01.4) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-03", + "name": "Boundary Protection", + "description": "Mechanisms exist to monitor and control communications at the external network boundary and at key internal boundaries within the network.", + "justification": "Boundary Protection (NET-03) provides network-level access restriction that compensates for the absence of Harvest Now, Decrypt Later (HNDL) Mitigation (QTS-01.4) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-02", + "risk_if_not_implemented": "Without Cryptographic Agility Risk Assessment (CARA), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "RSK-04", + "name": "Risk Assessment", + "description": "Mechanisms exist to conduct recurring assessments of risk that includes the likelihood and magnitude of harm, from unauthorized access, use, disclosure, disruption, modification or destruction of the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Risk Assessment (RSK-04) provides periodic assessment and verification that compensates for the absence of Cryptographic Agility Risk Assessment (CARA) (QTS-02) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Cryptographic Agility Risk Assessment (CARA) (QTS-02) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-02.1", + "risk_if_not_implemented": "Without Cryptographic Exception Register, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CPL-12", + "name": "Statement of Applicability (SOA)", + "description": "Mechanisms exist to produce a Statement of Applicability (SOA), or similar document, for compliance-related scoping activities.", + "justification": "Statement of Applicability (SOA) (CPL-12) provides overlapping security capability that compensates for the absence of Cryptographic Exception Register (QTS-02.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-06", + "name": "Risk Remediation", + "description": "Mechanisms exist to remediate risks to an acceptable level.", + "justification": "Risk Remediation (RSK-06) provides vulnerability management that compensates for the absence of Cryptographic Exception Register (QTS-02.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-02.2", + "risk_if_not_implemented": "Without Compensating Controls for Quantum-Vulnerable Systems, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Compensating Controls for Quantum-Vulnerable Systems (QTS-02.2) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Compensating Controls for Quantum-Vulnerable Systems (QTS-02.2) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-02.3", + "risk_if_not_implemented": "Without Crypto Agility Maturity Assessment, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CPL-03", + "name": "Control Conformity Monitoring", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "justification": "Control Conformity Monitoring (CPL-03) provides detective monitoring capability that compensates for the absence of Crypto Agility Maturity Assessment (QTS-02.3) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-02", + "name": "Assessments", + "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.", + "justification": "Assessments (IAO-02) provides periodic assessment and verification that compensates for the absence of Crypto Agility Maturity Assessment (QTS-02.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03", + "risk_if_not_implemented": "Without Post-Quantum Cryptography Agility Plan (PSCAP), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "RSK-01", + "name": "Risk Management Program", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Post-Quantum Cryptography Agility Plan (PSCAP) (QTS-03) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography Agility Plan (PSCAP) (QTS-03) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03.1", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support (QTS-03.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CHG-01", + "name": "Change Management Program", + "description": "Mechanisms exist to facilitate the implementation of a change management program.", + "justification": "Change Management Program (CHG-01) provides policy-level governance that compensates for the absence of Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support (QTS-03.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03.2", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Migration Progress Oversight, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "GOV-05", + "name": "Measures of Performance", + "description": "Mechanisms exist to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "justification": "Measures of Performance (GOV-05) provides overlapping security capability that compensates for the absence of Post-Quantum Cryptography (PQC) Migration Progress Oversight (QTS-03.2) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-11", + "name": "Risk Monitoring", + "description": "Mechanisms exist to ensure risk monitoring as an integral part of the continuous monitoring strategy that includes monitoring the effectiveness of security, compliance and resilience controls, compliance and change management.", + "justification": "Risk Monitoring (RSK-11) provides detective monitoring capability that compensates for the absence of Post-Quantum Cryptography (PQC) Migration Progress Oversight (QTS-03.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03.3", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Supply Chain Visibility, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TPM-08", + "name": "Review of Third-Party Services", + "description": "Mechanisms exist to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls.", + "justification": "Review of Third-Party Services (TPM-08) provides periodic assessment and verification that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Visibility (QTS-03.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TPM-05", + "name": "Third-Party Contract Requirements", + "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Contract Requirements (TPM-05) provides third-party oversight and contractual controls that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Visibility (QTS-03.3) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03.4", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TPM-03", + "name": "Supply Chain Risk Management (SCRM)", + "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", + "justification": "Supply Chain Risk Management (SCRM) (TPM-03) provides risk identification and prioritization that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements (QTS-03.4) by enabling informed decisions about where to focus resources to manage residual exposure. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TPM-05", + "name": "Third-Party Contract Requirements", + "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Contract Requirements (TPM-05) provides third-party oversight and contractual controls that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements (QTS-03.4) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-04", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Discovery & Visibility, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Post-Quantum Cryptography (PQC) Discovery & Visibility (QTS-04) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Post-Quantum Cryptography (PQC) Discovery & Visibility (QTS-04) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-04.1", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Asset Inventory, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Post-Quantum Cryptography (PQC) Asset Inventory (QTS-04.1) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Asset Inventory (QTS-04.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-04.2", + "risk_if_not_implemented": "Without Cryptographic Bill of Materials (CBOM), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Cryptographic Bill of Materials (CBOM) (QTS-04.2) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-01", + "name": "Configuration Management Program", + "description": "Mechanisms exist to facilitate the implementation of configuration management controls.", + "justification": "Configuration Management Program (CFG-01) provides policy-level governance that compensates for the absence of Cryptographic Bill of Materials (CBOM) (QTS-04.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-04.3", + "risk_if_not_implemented": "Without Post-Quantum Cryptography Exposure, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "VPM-03", + "name": "Vulnerability Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information.", + "justification": "Vulnerability Ranking (VPM-03) provides vulnerability management that compensates for the absence of Post-Quantum Cryptography Exposure (QTS-04.3) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-02", + "name": "Risk-Based Security Categorization", + "description": "Mechanisms exist to categorize Technology Assets, Applications, Services and/or Data (TAASD) in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", + "justification": "Risk-Based Security Categorization (RSK-02) provides risk identification and prioritization that compensates for the absence of Post-Quantum Cryptography Exposure (QTS-04.3) by enabling informed decisions about where to focus resources to manage residual exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-05", + "risk_if_not_implemented": "Without Quantum Security Awareness, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "SAT-02", + "name": "Security, Compliance & Resilience Awareness Training", + "description": "Mechanisms exist to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function.", + "justification": "Security, Compliance & Resilience Awareness Training (SAT-02) provides personnel training and awareness that compensates for the absence of Quantum Security Awareness (QTS-05) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Quantum Security Awareness (QTS-05) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-05.1", + "risk_if_not_implemented": "Without Quantum Threat Intelligence Monitoring, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Quantum Threat Intelligence Monitoring (QTS-05.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "THR-03", + "name": "Threat Intelligence Feeds", + "description": "Mechanisms exist to maintain situational awareness of vulnerabilities and evolving threats by leveraging the knowledge of attacker tactics, techniques and procedures to facilitate the implementation of preventative and compensating controls.", + "justification": "Threat Intelligence Feeds (THR-03) provides threat intelligence and situational awareness that compensates for the absence of Quantum Threat Intelligence Monitoring (QTS-05.1) by providing early warning of threats and informing proactive security posture adjustments. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-05.2", + "risk_if_not_implemented": "Without Collaboration & Information Sharing, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "GOV-07", + "name": "Contacts With Groups & Associations", + "description": "Mechanisms exist to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.", + "justification": "Contacts With Groups & Associations (GOV-07) provides overlapping security capability that compensates for the absence of Collaboration & Information Sharing (QTS-05.2) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Collaboration & Information Sharing (QTS-05.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06", + "risk_if_not_implemented": "Without Crypto-Agility Architecture, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Crypto-Agility Architecture (QTS-06) by embedding security requirements into design processes as an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Crypto-Agility Architecture (QTS-06) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.1", + "risk_if_not_implemented": "Without Entropy Source & Random Bit Generation, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Entropy Source & Random Bit Generation (QTS-06.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Entropy Source & Random Bit Generation (QTS-06.1) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.2", + "risk_if_not_implemented": "Without Stateful Hash-Based Signatures for Firmware & Code Signing, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Stateful Hash-Based Signatures for Firmware & Code Signing (QTS-06.2) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-06", + "name": "Configuration Enforcement", + "description": "Automated mechanisms exist to monitor, enforce and report on configurations for endpoint devices.", + "justification": "Configuration Enforcement (CFG-06) provides configuration and supply-chain hardening that compensates for the absence of Stateful Hash-Based Signatures for Firmware & Code Signing (QTS-06.2) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.3", + "risk_if_not_implemented": "Without Approved Post-Quantum Cryptography (PQC) Algorithm Use, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Approved Post-Quantum Cryptography (PQC) Algorithm Use (QTS-06.3) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Approved Post-Quantum Cryptography (PQC) Algorithm Use (QTS-06.3) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.4", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Validation Requirements, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Validation Requirements (QTS-06.4) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-06", + "name": "Technical Verification", + "description": "Mechanisms exist to perform Information Assurance Program (IAP) activities to evaluate the design, implementation and effectiveness of technical security, compliance and resilience controls.", + "justification": "Technical Verification (IAO-06) provides periodic assessment and verification that compensates for the absence of Post-Quantum Cryptography (PQC) Validation Requirements (QTS-06.4) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.5", + "risk_if_not_implemented": "Without Deprecated Cryptographic Algorithms, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Deprecated Cryptographic Algorithms (QTS-06.5) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Deprecated Cryptographic Algorithms (QTS-06.5) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.6", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Key Management, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Key Management (QTS-06.6) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-12", + "name": "Certificate Monitoring", + "description": "Automated mechanisms exist to discover when new certificates are issued for organization-controlled domains.", + "justification": "Certificate Monitoring (CRY-12) provides detective monitoring capability that compensates for the absence of Post-Quantum Cryptography (PQC) Key Management (QTS-06.6) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.7", + "risk_if_not_implemented": "Without Quantum-Safe Public Key Infrastructure (PKI) Transition, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Quantum-Safe Public Key Infrastructure (PKI) Transition (QTS-06.7) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Quantum-Safe Public Key Infrastructure (PKI) Transition (QTS-06.7) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.8", + "risk_if_not_implemented": "Without Algorithm Negotiation Integrity, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "NET-09", + "name": "Session Integrity", + "description": "Mechanisms exist to protect the authenticity and integrity of communications sessions.", + "justification": "Session Integrity (NET-09) provides overlapping security capability that compensates for the absence of Algorithm Negotiation Integrity (QTS-06.8) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-03", + "name": "Transmission Confidentiality", + "description": "Cryptographic mechanisms exist to protect the confidentiality of data being transmitted.", + "justification": "Transmission Confidentiality (CRY-03) provides overlapping security capability that compensates for the absence of Algorithm Negotiation Integrity (QTS-06.8) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.9", + "risk_if_not_implemented": "Without Hybrid / Composite Cryptography, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Hybrid / Composite Cryptography (QTS-06.9) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Hybrid / Composite Cryptography (QTS-06.9) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.10", + "risk_if_not_implemented": "Without Cryptographic Application Programming Interface (API) Abstraction, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Cryptographic Application Programming Interface (API) Abstraction (QTS-06.10) by embedding security requirements into design processes as an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Cryptographic Application Programming Interface (API) Abstraction (QTS-06.10) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-07", + "risk_if_not_implemented": "Without Cryptographic Incident Response (Emergency Algorithm Transition), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "IRO-04", + "name": "Incident Response Plan (IRP)", + "description": "Mechanisms exist to maintain and make available a current and viable Incident Response Plan (IRP) to all stakeholders.", + "justification": "Incident Response Plan (IRP) (IRO-04) provides incident response capability that compensates for the absence of Cryptographic Incident Response (Emergency Algorithm Transition) (QTS-07) by enabling timely detection, containment, and recovery from security events. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "BCD-07", + "name": "Alternative Security Measures", + "description": "Mechanisms exist to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised.", + "justification": "Alternative Security Measures (BCD-07) provides overlapping security capability that compensates for the absence of Cryptographic Incident Response (Emergency Algorithm Transition) (QTS-07) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-08", + "risk_if_not_implemented": "Without PQC Implementation Validation & Interoperability Testing, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TDA-09", + "name": "Security, Compliance & Resilience Testing Throughout Development", + "description": "Mechanisms exist to require system developers/integrators consult with security, compliance and/or resilience personnel to: \n(1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability;\n(2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the control testing and evaluation process; and\n(3) Document the results.", + "justification": "Security, Compliance & Resilience Testing Throughout Development (TDA-09) provides periodic assessment and verification that compensates for the absence of PQC Implementation Validation & Interoperability Testing (QTS-08) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-06", + "name": "Technical Verification", + "description": "Mechanisms exist to perform Information Assurance Program (IAP) activities to evaluate the design, implementation and effectiveness of technical security, compliance and resilience controls.", + "justification": "Technical Verification (IAO-06) provides periodic assessment and verification that compensates for the absence of PQC Implementation Validation & Interoperability Testing (QTS-08) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "RSK-01.1", + "risk_if_not_implemented": "Without Risk Framing, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", + "compensating_control_1": { + "control_id": "GOV-01", + "name": "Security, Compliance & Resilience Program (SCRP)", + "description": "Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.", + "justification": "Security, Compliance & Resilience Program (SCRP) (GOV-01) provides resilience and recovery capability that compensates for the absence of Risk Framing (RSK-01.1) by ensuring the organization can restore operations and data when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides overlapping security capability that compensates for the absence of Risk Framing (RSK-01.1) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "RSK-01.2", + "risk_if_not_implemented": "Without Risk Management Resourcing, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", + "compensating_control_1": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides overlapping security capability that compensates for the absence of Risk Management Resourcing (RSK-01.2) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-01", + "name": "Risk Management Program", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls.", + "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Risk Management Resourcing (RSK-01.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "RSK-01.3", "risk_if_not_implemented": "Without Risk Tolerance, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", @@ -17169,6 +18033,22 @@ "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Risk Catalog (RSK-03.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "RSK-03.2", + "risk_if_not_implemented": "Without Risk Owner, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "GOV-04", + "name": "Assigned Security, Compliance & Resilience Responsibilities", + "description": "Mechanisms exist to assign one or more qualified individuals with the mission and resources to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP).", + "justification": "Assigned Security, Compliance & Resilience Responsibilities (GOV-04) provides resilience and recovery capability that compensates for the absence of Risk Owner (RSK-03.2) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-06", + "name": "Risk Remediation", + "description": "Mechanisms exist to remediate risks to an acceptable level.", + "justification": "Risk Remediation (RSK-06) provides vulnerability management that compensates for the absence of Risk Owner (RSK-03.2) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "RSK-04.2", "risk_if_not_implemented": "Without Risk Assessment Methodology, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -17505,6 +18385,38 @@ "justification": "Secure Engineering Principles (SEA-01) provides overlapping security capability that compensates for the absence of Resilience Capabilities (SEA-01.3) by addressing related risk objectives through an alternative control mechanism aligned with Technology applicability. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "SEA-01.4", + "risk_if_not_implemented": "Without Secure Architecture Principles, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Secure Architecture Principles (SEA-01.4) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-05", + "name": "Developer Architecture & Design", + "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", + "justification": "Developer Architecture & Design (TDA-05) provides secure engineering and architectural guidance that compensates for the absence of Secure Architecture Principles (SEA-01.4) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "SEA-01.5", + "risk_if_not_implemented": "Without Security-Aware Design, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Security-Aware Design (SEA-01.5) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "PRM-04", + "name": "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.", + "justification": "Security, Compliance & Resilience In Project Management (PRM-04) provides resilience and recovery capability that compensates for the absence of Security-Aware Design (SEA-01.5) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "SEA-02", "risk_if_not_implemented": "Without Alignment With Enterprise Architecture, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -17809,6 +18721,22 @@ "justification": "Least Functionality (CFG-03) provides configuration hardening that compensates for the absence of Refresh from Trusted Sources (SEA-08.1) by eliminating unnecessary services and enforcing secure settings to reduce inherent exposure. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "SEA-08.2", + "risk_if_not_implemented": "Without Non-Persistent Information, sensitive information may be inadvertently exposed through error messages, insecure code, or persistent ephemeral data.", + "compensating_control_1": { + "control_id": "DCH-09", + "name": "System Media Sanitization", + "description": "Mechanisms exist to sanitize system media with the strength and integrity commensurate with the classification or sensitivity of the information prior to disposal, release out of organizational control or release for reuse.", + "justification": "System Media Sanitization (DCH-09) provides overlapping security capability that compensates for the absence of Non-Persistent Information (SEA-08.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-25", + "name": "Session Termination", + "description": "Automated mechanisms exist to log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity.", + "justification": "Session Termination (IAC-25) provides overlapping security capability that compensates for the absence of Non-Persistent Information (SEA-08.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "SEA-09", "risk_if_not_implemented": "Without Information Output Filtering, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -18513,6 +19441,22 @@ "justification": "Security, Compliance & Resilience Awareness Training (SAT-02) provides personnel training and awareness that compensates for the absence of Security, Compliance & Resilience Training Records (SAT-04) by reducing human-factor risk by equipping personnel to recognize and respond to relevant threats. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "SAT-04.1", + "risk_if_not_implemented": "Without Training Feedback, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "SAT-04", + "name": "Security, Compliance & Resilience Training Records", + "description": "Mechanisms exist to document, retain and monitor individual training activities, including:\n(1) Initial security, compliance and resilience awareness training;\n(2) Recurring awareness training; and\n(3) Technology Assets, Applications and/or Services (TAAS)-specific training.", + "justification": "Security, Compliance & Resilience Training Records (SAT-04) provides personnel training and awareness that compensates for the absence of Training Feedback (SAT-04.1) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-05", + "name": "Measures of Performance", + "description": "Mechanisms exist to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "justification": "Measures of Performance (GOV-05) provides overlapping security capability that compensates for the absence of Training Feedback (SAT-04.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "SAT-05", "risk_if_not_implemented": "Without Security, Compliance & Resilience Knowledge Sharing, the organization may be unable to recover from disruptions, resulting in data loss and extended downtime.", @@ -19009,6 +19953,22 @@ "justification": "Secure Engineering Principles (SEA-01) provides overlapping security capability that compensates for the absence of Software Design Root Cause Analysis (TDA-06.6) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "TDA-06.7", + "risk_if_not_implemented": "Without Programming Language Selection, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Programming Language Selection (TDA-06.7) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-04", + "name": "Software Usage Restrictions", + "description": "Mechanisms exist to enforce software usage restrictions to comply with applicable contract agreements and copyright laws.", + "justification": "Software Usage Restrictions (CFG-04) provides overlapping security capability that compensates for the absence of Programming Language Selection (TDA-06.7) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "TDA-07", "risk_if_not_implemented": "Without Secure Development Environments, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -19281,6 +20241,38 @@ "justification": "Third-Party Personnel Security (TPM-06) provides third-party oversight that compensates for the absence of Developer Screening (TDA-13) by extending security obligations contractually and monitoring third-party risk in lieu of direct control. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "TDA-13.1", + "risk_if_not_implemented": "Without Developer Knowledge & Skills Register, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "HRS-13", + "name": "Identify Critical Skills & Gaps", + "description": "Mechanisms exist to evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist.", + "justification": "Identify Critical Skills & Gaps (HRS-13) provides overlapping security capability that compensates for the absence of Developer Knowledge & Skills Register (TDA-13.1) by addressing related risk objectives through an alternative control mechanism. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Developer Knowledge & Skills Register (TDA-13.1) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "TDA-13.2", + "risk_if_not_implemented": "Without Developer Training, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Developer Training (TDA-13.2) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Developer Training (TDA-13.2) by addressing related risk objectives through an alternative control mechanism. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "TDA-14", "risk_if_not_implemented": "Without Developer Configuration Management, systems may operate with insecure settings or unauthorized changes, expanding the attack surface.", @@ -19409,6 +20401,22 @@ "justification": "Secure Baseline Configurations (CFG-02) provides configuration hardening that compensates for the absence of Error Handling (TDA-19) by eliminating unnecessary services and enforcing secure settings to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "TDA-19.1", + "risk_if_not_implemented": "Without Designated Roles To View Error Messages, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Designated Roles To View Error Messages (TDA-19.1) by restricting system and data access through alternative identity and access management mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SEA-09", + "name": "Information Output Filtering", + "description": "Mechanisms exist to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content.", + "justification": "Information Output Filtering (SEA-09) provides overlapping security capability that compensates for the absence of Designated Roles To View Error Messages (TDA-19.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "TDA-20", "risk_if_not_implemented": "Without Access to Program Source Code, unauthorized users may gain access to systems or data, increasing risk of data breaches and insider threats.", @@ -19969,6 +20977,38 @@ "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Threat Intelligence Program (THR-01) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "THR-01.1", + "risk_if_not_implemented": "Without Dynamic Threat Awareness, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Dynamic Threat Awareness (THR-01.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Dynamic Threat Awareness (THR-01.1) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "THR-01.2", + "risk_if_not_implemented": "Without Predictive Cyber Analytics, the organization's threat model may become stale, leaving security controls misaligned with the actual threat landscape.", + "compensating_control_1": { + "control_id": "THR-07", + "name": "Threat Hunting", + "description": "Mechanisms exist to perform cyber threat hunting that uses Indicators of Compromise (IoC) to detect, track and disrupt threats that evade existing security controls.", + "justification": "Threat Hunting (THR-07) provides overlapping security capability that compensates for the absence of Predictive Cyber Analytics (THR-01.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-16", + "name": "Anomalous Behavior", + "description": "Mechanisms exist to utilize User & Entity Behavior Analytics (UEBA) and/or User Activity Monitoring (UAM) solutions to detect and respond to anomalous behavior that could indicate account compromise or other malicious activities.", + "justification": "Anomalous Behavior (MON-16) provides detective monitoring capability that compensates for the absence of Predictive Cyber Analytics (THR-01.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "THR-02", "risk_if_not_implemented": "Without Indicators of Exposure (IOE), residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -20193,6 +21233,22 @@ "justification": "Vulnerability Remediation Process (VPM-02) provides vulnerability management that compensates for the absence of Attack Surface Scope (VPM-01.1) by reducing the exploitable attack surface by addressing known weaknesses before they are leveraged. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "VPM-02.1", + "risk_if_not_implemented": "Without Known Exploited Vulnerabilities (KEV) Mitigations, unpatched vulnerabilities may remain exploitable, directly increasing the probability of successful attacks against the organization.", + "compensating_control_1": { + "control_id": "VPM-02", + "name": "Vulnerability Remediation Process", + "description": "Mechanisms exist to ensure that vulnerabilities are properly identified, tracked and remediated.", + "justification": "Vulnerability Remediation Process (VPM-02) provides vulnerability management that compensates for the absence of Known Exploited Vulnerabilities (KEV) Mitigations (VPM-02.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-03", + "name": "Boundary Protection", + "description": "Mechanisms exist to monitor and control communications at the external network boundary and at key internal boundaries within the network.", + "justification": "Boundary Protection (NET-03) provides network-level access restriction that compensates for the absence of Known Exploited Vulnerabilities (KEV) Mitigations (VPM-02.1) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "VPM-03", "risk_if_not_implemented": "Without Vulnerability Ranking, unpatched vulnerabilities accumulate, providing attackers with known and exploitable entry points.", diff --git a/data/scf-crosswalks.json b/data/scf-crosswalks.json index 8d0bcb1f..2286ece8 100644 --- a/data/scf-crosswalks.json +++ b/data/scf-crosswalks.json @@ -1,241 +1,243 @@ { "metadata": { - "source": "Secure Controls Framework (SCF) v2026.1.1", + "source": "Secure Controls Framework (SCF) v2026.2", "source_url": "https://securecontrolsframework.com", "license": "CC BY-ND (Attribution, No Derivatives)", - "total_frameworks": 249, + "total_frameworks": 252, "framework_display_names": { - "general-aicpa-pmf-2020": "AICPA Privacy Management Framework (PMF) (2020)", - "general-aicpa-tsc-2017": "Trust Services Criteria (TSC) (2017)", - "general-apec-privacy-framework-2015": "APEC Privacy Framework (2015)", - "general-bsi-200-1-1-0": "Standard 200-1 (v1.0)", - "general-cis-csc-8-1": "Critical Security Controls (CSC) (v8.1)", - "general-cis-csc-8-1-ig1": "Critical Security Controls (CSC) (v8.1) - IG1", - "general-cis-csc-8-1-ig2": "Critical Security Controls (CSC) (v8.1) - IG2", - "general-cis-csc-8-1-ig3": "Critical Security Controls (CSC) (v8.1) - IG3", + "general-aicpa-pmf-2020": "American Institute of Certified Public Accountants (AICPA) Privacy Management Framework (PMF) (2020)", + "general-aicpa-tsc-2017": "American Institute of Certified Public Accountants (AICPA) Trust Services Criteria (2017)", + "general-apec-privacy-framework-2015": "Asia - Pacific Economic Cooperation (APEC) Privacy Framework (2015)", + "general-bsi-200-1-1-0": "Bundesamt für Sicherheit in der Informationstechnik (BSI) - Standard 200 - 1 (v1.0)", + "general-cis-csc-8-1": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1", + "general-cis-csc-8-1-ig1": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG1", + "general-cis-csc-8-1-ig2": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG2", + "general-cis-csc-8-1-ig3": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG3", "general-cobit-2019": "Control Objectives for Information and Related Technologies (COBIT) (2019)", "general-coso-2013": "Committee of Sponsoring Organizations (COSO) (2013)", - "general-csa-cmm-4-1-0": "Cloud Controls Matrix (CCM) (v4.1.0)", - "general-csa-iot-2": "IoT Security Controls Framework (v2)", - "general-cr-cmm-2026": "Cyber Resilience Capability Maturity Model (CR-CMM) (2026)", - "general-govramp": "GovRAMP", - "general-govramp-core": "GovRAMP Core", - "general-govramp-low": "GovRAMP Low", - "general-govramp-low-plus": "GovRAMP Low+", - "general-govramp-mod": "GovRAMP Moderate", - "general-govramp-high": "GovRAMP High", - "general-iec-tr-60601-4-5-2021": "IEC TR 60601-4-5 (2021)", - "general-iec-62443-2-1-2024": "IEC 62443-2-1 (2024)", - "general-iec-62443-3-3-2013": "IEC 62443-3-3 (2013)", - "general-iec-62443-4-1-2018": "IEC 62443-4-1 (2018)", - "general-iec-62443-4-2-2019": "IEC 62443-4-2 (2019)", + "general-csa-cmm-4-1-0": "Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) v4.1.0", + "general-csa-iot-2": "Cloud Security Alliance (CSA) Internet of Things Security Controls Framework v2", + "general-cr-cmm-2026": "Cyber Resilience Capability Maturity Model (CR - CMM) (2026)", + "general-govramp": "Government Risk and Authorization Management Program (GovRAMP)", + "general-govramp-core": "Government Risk and Authorization Management Program (GovRAMP) - Core Controls", + "general-govramp-low": "Government Risk and Authorization Management Program (GovRAMP) - Low", + "general-govramp-low-plus": "Government Risk and Authorization Management Program (GovRAMP) - Low+", + "general-govramp-mod": "Government Risk and Authorization Management Program (GovRAMP) - Moderate", + "general-govramp-high": "Government Risk and Authorization Management Program (GovRAMP) - High", + "general-iec-tr-60601-4-5-2021": "International Electrotechnical Commission (IEC) Technical Report 60601 - 4 - 5:2021 - Medical electrical equipment - Part 4 - 5: Guidance and interpretation - Safety - related technical security specifications", + "general-iec-62443-2-1-2024": "International Electrotechnical Commission (IEC) 62443 - 2 - 1:2024 - Security for industrial automation and control systems - Part 2 - 1: Security program requirements for IACS asset owners", + "general-iec-62443-3-3-2013": "International Electrotechnical Commission (IEC) 62443 - 3 - 3:2013 - Industrial communication networks - Network and system security - Part 3 - 3: System security requirements and security levels", + "general-iec-62443-4-1-2018": "International Electrotechnical Commission (IEC) 62443 - 4 - 1:2018 - Security for industrial automation and control systems - Part 4 - 1: Secure product development lifecycle requirements", + "general-iec-62443-4-2-2019": "International Electrotechnical Commission 62443 - 4 - 2 Ed. 1.0 b:2019 - Security for industrial automation and control systems - Part 4 - 2: Technical security requirements for IACS components", "general-imo-maritime-cyber-risk-management-2025": "International Maritime Organization (IMO) Guidelines on Maritime Cyber Risk Management (2025)", - "general-iso-21434-2021": "ISO 21434 (2021)", - "general-iso-22301-2019": "ISO 22301 (2019)", - "general-iso-27001-2022": "ISO 27001 (2022)", - "general-iso-27002-2022": "ISO 27002 (2022)", - "general-iso-27017-2015": "ISO 27017 (2015)", - "general-iso-27018-2025": "ISO 27018 (2025)", - "general-iso-27701-2025": "ISO 27701 (2025)", - "general-iso-29100-2024": "ISO 29100 (2024)", - "general-iso-31000-2018": "ISO 31000 (2018)", - "general-iso-31010-2009": "ISO 31010 (2009)", - "general-iso-42001-2023": "ISO 42001 (2023)", - "general-mitre-att&ck-16-1": "MITRE ATT&CK (v16.1)", - "general-mpa-csbp-5-3-1": "Content Security Best Practices Common Guidelines (v5.3.1)", - "general-naic-insurance-data-security-model-law-668-2017": "Insurance Data Security Model Law 668 (2017)", - "general-nist-100-1-ai-rmf": "NIST AI 100-1 (AI RMF 1.0)", - "general-nist-600-1-gen-ai-profile": "NIST AI 600-1", - "general-nist-privacy-framework-1-0": "NIST Privacy Framework (v1.0)", - "general-nist-800-37-r2": "NIST SP 800-37 R2", - "general-nist-800-39": "NIST SP 800-39", - "general-nist-800-53-r4": "NIST SP 800-53 R4", - "general-nist-800-53-r5-2": "NIST SP 800-53 R5", - "general-nist-800-53-r5-2-privacy": "NIST SP 800-53 R5 - Privacy Baseline", - "general-nist-800-53-r5-2-low": "NIST SP 800-53 R5 - Low Baseline", - "general-nist-800-53-r5-2-mod": "NIST SP 800-53 R5 - Moderate Baseline", - "general-nist-800-53-r5-2-high": "NIST SP 800-53 R5 - High Baseline", - "general-nist-800-66-r2": "NIST SP 800-66 R2", - "general-nist-800-82-r3": "NIST SP 800-82 R3", - "general-nist-800-82-r3-low": "NIST SP 800-82 R3 - Low OT Overlay", - "general-nist-800-82-r3-mod": "NIST SP 800-82 R3 - Moderate OT Overlay", - "general-nist-800-82-r3-high": "NIST SP 800-82 R3 - High OT Overlay", - "general-nist-800-160-vol-2-r1": "NIST SP 800-160 (Vol 2, Rev 1)", - "general-nist-800-161-r1": "NIST SP 800-161 R1 UDP1", - "general-nist-800-161-r1-cscrm": "NIST SP 800-161 R1 UDP1 - C-SCRM Baseline", - "general-nist-800-161-r1-flowdown": "NIST SP 800-161 R1 UDP1 - Flow Down Baseline", - "general-nist-800-161-r1-level-1": "NIST SP 800-161 R1 UDP1 - Level 1 Baseline", - "general-nist-800-161-r1-level-2": "NIST SP 800-161 R1 UDP1 - Level 2 Baseline", - "general-nist-800-161-r1-level-3": "NIST SP 800-161 R1 UDP1 - Level 3 Baseline", - "general-nist-800-171-r2": "NIST SP 800-171 R2", - "general-nist-800-171-r3": "NIST SP 800-171 R3", - "general-nist-800-171a": "NIST SP 800-171A", - "general-nist-800-171a-r3": "NIST SP 800-171A R3", - "general-nist-800-172": "NIST SP 800-172", - "general-nist-800-207": "NIST SP 800-207", - "general-nist-800-218": "NIST SP 800-218", - "general-nist-csf-2-0": "NIST Cybersecurity Framework (v2.0)", - "general-oecd-privacy-principles-2010": "OECD Privacy Principles (2010)", - "general-owasp-top-10-2025": "OWASP Top 10 (2025)", - "general-pci-dss-4-0-1": "Payment Card Industry Data Security Standard (PCI DSS) (v4.01)", - "general-pci-dss-4-0-1-saq-a": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ A (v4.0.1)", - "general-pci-dss-4-0-1-saq-a-ep": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ A-EP (v4.0.1)", - "general-pci-dss-4-0-1-saq-b": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ B (v4.0.1)", - "general-pci-dss-4-0-1-saq-b-ip": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ B-IP (v4.0.1)", - "general-pci-dss-4-0-1-saq-c": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ C (v4.0.1)", - "general-pci-dss-4-0-1-saq-c-vt": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ C-VT (v4.0.1)", - "general-pci-dss-4-0-1-saq-d-merchant": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Merchant (v4.0.1)", - "general-pci-dss-4-0-1-saq-d-service-provider": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Service Provider (v4.0.1)", - "general-pci-dss-4-0-1-saq-p2pe": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ P2PE (v4.0.1)", - "general-scf-dpmp-2025": "Data Privacy Management Principle (DPMP) (2025)", - "general-shared-assessments-sig-2025": "SIG (2025)", - "general-sparta": "SPARTA Countermeasures", - "general-swift-cscf-2025": "SWIFT Customer Security Controls Framework (2025)", - "general-tisax-6-0-3": "TISAX ISA (6.0.3)", - "general-ul-2900-1-2017": "UL 2900-1 (2017)", - "general-ul-2900-2-2-2016": "UL 2900-2-2 (2016)", - "general-un-155-2021": "UN Regulation No. 155 (2021)", - "general-un-ece-wp-29-2020": "UNECE WP.29 (2020)", - "usa-federal-dow-cert-rmm-1-2": "CERT-RMM (v1.2)", - "usa-federal-law-coppa-2024": "Children's Online Privacy Protection Act (COPPA) (2024)", - "usa-federal-dhs-cisa-ssdaf-2024": "CISA Secure Software Development Attestation Form (SSDAF) (2024)", - "usa-federal-dhs-cisa-tic-3-0": "CISA Trusted Internet Connections 3.0 Security Capabilities Catalog (TIC 3.0)", - "usa-federal-dhs-cisa-cpg-2-0": "CISA Cross-Sector Cybersecurity Performance Goals (CPG) (2.0)", - "usa-federal-fbi-cjis-6-0": "Criminal Justice Information Services (CJIS) Security Policy (v6.0)", - "usa-federal-doe-c2m2-2-1": "Cybersecurity Capability Maturity Model (C2M2) (v2.1)", - "usa-federal-dow-cmmc-2-level-1": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1", - "usa-federal-dow-cmmc-2-level-1-aos": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1 Assessment Objectives", - "usa-federal-dow-cmmc-2-level-2": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 2", - "usa-federal-dow-cmmc-2-level-3": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 3", - "usa-federal-doc-data-privacy-framework-2023": "Data Privacy Framework (2023)", - "usa-federal-dow-zt-roadmap-1-1": "Department of War (DoW) - Zero Trust Execution Roadmap (v1.1)", - "usa-federal-dow-zta-reference-architecture-2-0": "Department of War (DoW) - Zero Trust Reference Architecture (v2)", - "usa-federal-dow-dfars-252-204-7012": "DFARS 252.204-7012", - "usa-federal-eo-14028": "Executive Order 14028 - Improving the Nation's Cybersecurity", - "usa-federal-law-facta-fcra-2023": "Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023)", - "usa-federal-far-52-204-21": "FAR 52.204-21", - "usa-federal-far-52-204-25": "FAR 52.204-25 (NDAA Section 889)", - "usa-federal-far-52-204-27": "FAR 52.204-27", - "usa-federal-sro-fca-crm-2023": "Farm Credit Administration (FCA) Cyber Risk Management (2023)", - "usa-federal-fda-21-cfr-part-11-2025": "Food & Drug Administration (FDA) 21 CFR Part 11 (2025)", - "usa-federal-gsa-fedramp-5-low": "FedRAMP R5 - Low Baseline", - "usa-federal-gsa-fedramp-5-mod": "FedRAMP R5 - Moderate Baseline", - "usa-federal-gsa-fedramp-5-high": "FedRAMP R5 - High Baseline", - "usa-federal-gsa-fedramp-5-li-saas": "FedRAMP R5 - Li-SAAS Baseline", - "usa-federal-law-ferpa-2010": "Family Educational Rights and Privacy Act (FERPA) (2010)", - "usa-federal-sro-finra": "FINRA Cybersecurity Rules", - "usa-federal-omb-fipps-1973": "US Fair Information Practice Principles (FIPPs) (1973)", - "usa-federal-law-ftc-act": "Federal Trade Commission (FTC) Act", - "usa-federal-law-glba-cfr-314-2023": "Gramm Leach Bliley Act (GLBA) (2023)", - "usa-federal-hhs-45-cfr-155-260-2016": "HHS § 155.260 (2016)", - "usa-federal-law-hipaa-simplification-2013": "HIPAA Administrative Simplification (2013)", - "usa-federal-law-hipaa-security-rule-2013": "HIPAA Security Rule (2013)", - "usa-federal-irs-1075-2021": "IRS 1075 (2021)", - "usa-federal-cms-marse-2-0": "MARS-E Document Suite (2.0)", - "usa-federal-nerc-cip-2024": "NERC Critical Infrastructure Protection (CIP) (2024)", - "usa-federal-nispom-2020": "National Industrial Security Program Operating Manual (NISPOM) (2020)", - "usa-federal-dow-safeguarding-nnpi-2010": "Safeguarding of NNPI (2010)", - "usa-federal-sec-cybersecurity-rule-2023": "SEC Cybersecurity Rule (2023)", - "usa-federal-law-sox-2002": "SOX (2002)", - "usa-federal-tsa-security-directive-1580-82-2022-01": "TSA Security Directive 1580/82-2022-01", - "usa-state-ak-pipa-2009": "Alaska Personal Information Protection Act (PIPA) (2009)", - "usa-state-ca-sb327-2018": "California SB327 (2018)", - "usa-state-ca-ccpa-cpra-2026": "California Consumer Privacy Act (CCPA) (2026)", - "usa-state-ca-sb1386-2002": "California SB1386 (2002)", - "usa-state-co-privacy-act-2021": "Colorado Privacy Act (2021)", - "usa-state-il-bipa-2008": "Illinois Biometric Information Privacy Act (BIPA) (2008)", - "usa-state-il-ipa-2009": "Illinois Identity Protection Act (IPA) (2009)", - "usa-state-il-pipa-2006": "Illinois Personal Information Protection Act (PIPA) (2006)", - "usa-state-ma-201-cmr-17-2008": "Massachusetts 201 CMR 17.00 (2008)", - "usa-state-nv-regulation-5-2024": "Nevada Operation of Gaming Establishment (NOGE) Regulation 5.260 (2024)", - "usa-state-nv-sb220-2019": "Nevada SB220 (2019)", - "usa-state-ny-dfs-23-nycrr500-2023-amd2": "New York Department of Financial Services 23NYCRR Part 500 (2023 Amendment 2)", - "usa-state-ny-shield-act-2019": "New York SHIELD Act (SB S5575B) (2019)", - "usa-state-or-ors-646a-2025": "Oregon Consumer Information Protection Act (ORS 646A) (2025)", - "usa-state-or-cpa-2023": "Oregon Consumer Privacy Act (SB 619) (2023)", - "usa-state-tn-tipa-2025": "Tennessee Information Protection Act (TIPA) (2025)", - "usa-state-tx-bc521-2009": "Texas Identity Theft Enforcement and Protection Act (BC521) (2009)", - "usa-state-tx-cdpa-2025": "Texas Consumer Data Protection Act (2025)", - "usa-state-tx-dir-security-control-standards-catalog-2-2": "Texas DIR Security Control Standards Catalog (v2.2)", - "usa-state-tx-sb820-2019": "Texas SB820 (2019)", - "usa-state-tx-sb2610-2025": "Texas Safe Harbor Law (SB2610) (2025)", - "usa-state-tx-txramp-2-0-level-1": "TX-RAMP 2.0 - Level 1", - "usa-state-tx-txramp-2-0-level-2": "TX-RAMP 2.0 - Level 2", - "usa-state-va-cdpa-2023": "Virginia Consumer Data Protection Act (2023)", - "usa-state-vt-act-171-2018": "Vermont Data Broker Registration Act (Act 171 of 2018)", - "emea-eu-ai-act-2024": "EU Artificial Intelligence Act (AI Act) (2024)", - "emea-eu-cyber-resilience-act-2022": "EU Cyber Resilience Act (CRA) (2022)", - "emea-eu-cyber-resilience-act-annexes-2022": "EU Cyber Resilience Act Annexes (CRA Annexes) (2022)", - "emea-eu-eba-ict-srm-2025": "EU EBA Guidelines on ICT and Security Risk Management (2025)", - "emea-eu-dora-2023": "EU Digital Operational Resilience Act (DORA) (2023)", - "emea-eu-gdpr-2016": "EU General Data Protection Regulation (GDPR) (2016)", - "emea-eu-nis2-2022": "EU NIS2 Directive (2022)", - "emea-eu-nis2-annex-2024": "EU NIS2 Annex (2024)", - "emea-us-psd2-2015": "EU Second Payment Services Directive (PSD2) (2015)", - "emea-aut-fappd-2000": "Austria - Federal Act concerning the Protection of Personal Data (2000)", - "emea-bel-act-8-1992": "Belgium - Act of 8 December 1992", + "general-iso-21434-2021": "ISO/SAE 21434:2021 - Road vehicles — Cybersecurity engineering", + "general-iso-22301-2019": "ISO/IEC 22301:2019 - Security and resilience - Business continuity management systems - Requirements", + "general-iso-27001-2022": "ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements", + "general-iso-27002-2022": "ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls", + "general-iso-27017-2015": "ISO/IEC 27017:2015 - Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services", + "general-iso-27018-2025": "ISO/IEC 27018:2025 - Information security, cybersecurity and privacy protection - Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors", + "general-iso-27701-2025": "ISO/IEC 27701:2025 - Information security, cybersecurity and privacy protection - Privacy information management systems - Requirements and guidance", + "general-iso-29100-2024": "ISO/IEC 29100:2024 - Information technology - Security techniques - Privacy framework", + "general-iso-31000-2018": "ISO/IEC 31000:2018 - Risk management - Guidelines", + "general-iso-31010-2009": "ISO/IEC 31010:2019 - Risk management - Risk assessment techniques", + "general-iso-42001-2023": "ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system", + "general-mitre-att_ck-16-1": "MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) - NIST 800 - 53 mappings", + "general-mpa-csbp-5-3-1": "Motion Picture Association (MPA) Content Security Best Practices Common Guidelines v5.3.1", + "general-naic-insurance-data-security-model-law-668-2017": "National Association of Insurance Commissioners (NAIC) Insurance Data Security Model Law (MDL - 668) (2017)", + "general-nist-100-1-ai-rmf": "NIST AI 100 - 1 - Artificial Intelligence Risk Management Framework (AI RMF 1.0)", + "general-nist-600-1-gen-ai-profile": "NIST AI 600 - 1 - Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", + "general-nist-privacy-framework-1-0": "NIST Privacy Framework v1.0", + "general-nist-800-37-r2": "NIST SP 800 - 37 R2 - Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy", + "general-nist-800-39": "NIST SP 800 - 39 - Managing Information Security Risk: Organization, Mission, and Information System View", + "general-nist-800-53-r4": "NIST SP 800 - 53 R4 - Security and Privacy Controls for Federal Information Systems and Organizations", + "general-nist-800-53-r5-2": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations", + "general-nist-800-53-r5-2-privacy": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Privacy Baseline", + "general-nist-800-53-r5-2-low": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Low Baseline", + "general-nist-800-53-r5-2-mod": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Moderate Baseline", + "general-nist-800-53-r5-2-high": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - High Baseline", + "general-nist-800-66-r2": "NIST SP 800 - 66 R2 - Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide", + "general-nist-800-82-r3": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay", + "general-nist-800-82-r3-low": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay", + "general-nist-800-82-r3-mod": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Moderate OT Overlay", + "general-nist-800-82-r3-high": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - High OT Overlay", + "general-nist-800-160-vol-2-r1": "NIST SP 800 - 160 Volume 2, Revision 1 - Developing Cyber - Resilient Systems: A Systems Security Engineering Approach", + "general-nist-800-161-r1": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations", + "general-nist-800-161-r1-cscrm": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - C - SCRM Baseline", + "general-nist-800-161-r1-flowdown": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Flow Down Baseline", + "general-nist-800-161-r1-level-1": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 1 Baseline", + "general-nist-800-161-r1-level-2": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 2 Baseline", + "general-nist-800-161-r1-level-3": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 3 Baseline", + "general-nist-800-171-r2": "NIST SP 800 - 171 R2 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", + "general-nist-800-171-r3": "NIST SP 800 - 171 R3 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", + "general-nist-800-171a": "NIST SP 800 - 171A - Assessing Security Requirements for Controlled Unclassified Information", + "general-nist-800-171a-r3": "NIST SP 800 - 171A R3 - Assessing Security Requirements for Controlled Unclassified Information", + "general-nist-800-172-r3": "NIST SP 800 - 172 R3 - Enhanced Security Requirements for Protecting Controlled Unclassified Information", + "general-nist-800-172a-r3": "NIST SP 800 - 172A R3 - Assessing Enhanced Security Requirements for Controlled Unclassified Information", + "general-nist-800-207": "NIST SP 800 - 207 - Zero Trust Architecture", + "general-nist-800-218": "NIST SP 800 - 218 - Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities", + "general-nist-csf-2-0": "NIST Cybersecurity Framework v2.0", + "general-nist-cswp-39": "NIST CSWP 39 - Considerations for Achieving Crypto Agility", + "general-oecd-privacy-principles-2010": "Organisation for Economic Co - operation and Development (EOCD) Privacy Principles", + "general-owasp-top-10-2025": "Open Worldwide Application Security Project (OWASP) Top 10 (2025)", + "general-pci-dss-4-0-1": "Payment Card Industry Data Security Standard (PCI DSS) v4.01", + "general-pci-dss-4-0-1-saq-a": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A", + "general-pci-dss-4-0-1-saq-a-ep": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A - EP", + "general-pci-dss-4-0-1-saq-b": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B", + "general-pci-dss-4-0-1-saq-b-ip": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B - IP", + "general-pci-dss-4-0-1-saq-c": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C", + "general-pci-dss-4-0-1-saq-c-vt": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C - VT", + "general-pci-dss-4-0-1-saq-d-merchant": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Merchant", + "general-pci-dss-4-0-1-saq-d-service-provider": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Service Provider", + "general-pci-dss-4-0-1-saq-p2pe": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) P2PE", + "general-scf-dpmp-2025": "Secure Controls Framework (SCF) Data Privacy Management Principles (2025)", + "general-shared-assessments-sig-2025": "Shared Assessments Standard Information Gathering (SIG) Questionnaire 2025", + "general-sparta": "Space Attack Research & Tactic Analysis (SPARTA) Countermeasures", + "general-swift-cscf-2025": "Society for Worldwide Interbank Financial Telecommunication Customer Security Controls Framework 2025", + "general-tisax-6-0-3": "Trusted Information Security Assessment Exchange (TISAX) 6.0.3", + "general-ul-2900-1-2017": "UL 2900 - 1 - Software Cybersecurity for Network - Connectable Products, Part 1: General Requirements (2017)", + "general-ul-2900-2-2-2016": "UL 2900 - 2 - 2 Ed. 1 - 2016 - Outline of Investigation for Software Cybersecurity for Network - Connectable Products, Part 2 - 2: Particular Requirements for Industrial Control Systems", + "general-un-155-2021": "United Nations - Regulation No. 155 - Cyber security and cyber security management system (2021)", + "general-un-ece-wp-29-2020": "United Nations - United Nations Economic Commission for Europe (UNECE) Working Party 29 (2020)", + "usa-federal-dow-cert-rmm-1-2": "US - Department of War (DoW) - Computer Emergency Response Team (CERT) Resilience Management Model (RMM) Version 1.2", + "usa-federal-law-coppa-2024": "US - Children's Online Privacy Protection Act (COPPA) (2024)", + "usa-federal-dhs-cisa-ssdaf-2024": "US - Cybersecurity & Infrastructure Security Agency (CISA) Secure Software Development Attestation Form (SSDAF) (2024)", + "usa-federal-dhs-cisa-tic-3-0": "US - Cybersecurity & Infrastructure Security Agency (CISA) Trusted Internet Connections 3.0 Security Capabilities Catalog", + "usa-federal-dhs-cisa-cpg-2-0": "US - Cybersecurity & Infrastructure Security Agency (CISA) Cross - Sector Cybersecurity Performance Goals 2.0", + "usa-federal-fbi-cjis-6-0": "US - Department of Justice - Criminal Justice Information Services (CJIS) Security Policy v6.0", + "usa-federal-doe-c2m2-2-1": "US - Department of Energy (DOE) - Cybersecurity Capability Maturity Model version 2.1", + "usa-federal-dow-cmmc-2-level-1": "US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1", + "usa-federal-dow-cmmc-2-level-1-aos": "US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1 Assessment Objectives", + "usa-federal-dow-cmmc-2-level-2": "US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 2", + "usa-federal-dow-cmmc-2-level-3": "US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 3", + "usa-federal-doc-data-privacy-framework-2023": "US - Data Privacy Framework (2023)", + "usa-federal-dow-zt-roadmap-1-1": "US - Department of War (DoW) - Zero Trust Execution Roadmap v1.1", + "usa-federal-dow-zta-reference-architecture-2-0": "US - Department of War (DoW) - Zero Trust Reference Architecture v2", + "usa-federal-dow-dfars-252-204-7012": "US - Defense Federal Acquisition Regulation Supplement (DFARS) 252.204 - 7012", + "usa-federal-eo-14028": "US - Executive Order (EO) 14028 - Improving the Nation's Cybersecurity", + "usa-federal-law-facta-fcra-2023": "US - Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023)", + "usa-federal-far-52-204-21": "US - Federal Acquisition Regulation (FAR) 52.204 - 21 - Basic Safeguarding of Covered Contractor Information Systems", + "usa-federal-far-52-204-25": "US - Federal Acquisition Regulation (FAR) 52.204 - 25 (NDAA Section 889) - Prohibition on Contracting With Entities Using Certain Telecommunications and Video Surveillance Services or Equipment", + "usa-federal-far-52-204-27": "US - Federal Acquisition Regulation (FAR) 52.204 - 27 - Prohibition on a ByteDance Covered Application", + "usa-federal-sro-fca-crm-2023": "US - Farm Credit Administration (FCA) Cyber Risk Management (2023)", + "usa-federal-fda-21-cfr-part-11-2025": "US - Food & Drug Administration (FDA) 21 CFR Part 11 (2025)", + "usa-federal-gsa-fedramp-5-low": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Low Baseline", + "usa-federal-gsa-fedramp-5-mod": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Moderate Baseline", + "usa-federal-gsa-fedramp-5-high": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - High Baseline", + "usa-federal-gsa-fedramp-5-li-saas": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Li - SAAS Baseline", + "usa-federal-law-33-cfr-part-101-subpart-f": "US - 33 CFR Part 101 Subpart F (up to date as of 4 - 17 - 2026)", + "usa-federal-law-ferpa-2010": "US - Family Educational Rights and Privacy Act (FERPA) (2010)", + "usa-federal-sro-finra": "US - Financial Industry Regulatory Authority (FINRA) Cybersecurity Rules", + "usa-federal-omb-fipps-1973": "US - Fair Information Practice Principles (FIPPs) (1973)", + "usa-federal-law-ftc-act": "US - Federal Trade Commission (FTC) Act", + "usa-federal-law-glba-cfr-314-2023": "US - Gramm Leach Bliley Act (GLBA) - CFR 314 (Dec 2023)", + "usa-federal-hhs-45-cfr-155-260-2016": "US - Health and Human Services (HHS) § 155.260 - Privacy and Security of Personally Identifiable Information (2016)", + "usa-federal-law-hipaa-simplification-2013": "US - Health Insurance Portability and Accountability Act (HIPAA) Administrative Simplification (2013)", + "usa-federal-law-hipaa-security-rule-2013": "US - Health Insurance Portability and Accountability Act (HIPAA) Security Rule (2013)", + "usa-federal-irs-1075-2021": "US - Internal Revenue Service (IRS) 1075 (2021)", + "usa-federal-cms-marse-2-0": "US - Centers for Medicare & Medicaid Services MARS - E Document Suite, Version 2.0", + "usa-federal-nerc-cip-2024": "US - North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) (2024)", + "usa-federal-nispom-2020": "US - National Industrial Security Program Operating Manual (NISPOM) (2020)", + "usa-federal-dow-safeguarding-nnpi-2010": "US - Safeguarding of Naval Nuclear Propulsion Information (NNPI) (2010)", + "usa-federal-sec-cybersecurity-rule-2023": "US - Securities and Exchange Commission (SEC) Cybersecurity Rule (2023)", + "usa-federal-law-sox-2002": "US - Sarbanes Oxley Act (SOX) (2002)", + "usa-federal-tsa-security-directive-1580-82-2022-01": "US - Transportation Security Administration (TSA) Security Directive 1580/82 - 2022 - 01 - Rail Cybersecurity Mitigation Actions and Testing", + "usa-state-ak-pipa-2009": "US - Alaska Personal Information Protection Act (PIPA) (2009)", + "usa-state-ca-sb327-2018": "US - California SB327 (2018)", + "usa-state-ca-ccpa-cpra-2026": "US - California Consumer Privacy Act (CCPA) (January 2026) - amended California Privacy Rights Act (CPRA)", + "usa-state-ca-sb1386-2002": "US - California SB1386 (2002)", + "usa-state-co-privacy-act-2021": "US - Colorado Privacy Act (2021)", + "usa-state-il-bipa-2008": "US - Illinois Biometric Information Privacy Act (BIPA) (2008)", + "usa-state-il-ipa-2009": "US - Illinois Identity Protection Act (IPA) (2009)", + "usa-state-il-pipa-2006": "US - Illinois Personal Information Protection Act (PIPA) (2006)", + "usa-state-ma-201-cmr-17-2008": "US - Massachusetts 201 CMR 17.00 (2008)", + "usa-state-nv-privacy-law-2023": "US - Nevada Privacy Law (2023) - CHAPTER 603A - SECURITY AND PRIVACY OF PERSONAL INFORMATION", + "usa-state-nv-regulation-5-2024": "US - Nevada Operation of Gaming Establishments - Regulation 5.260 (Cybersecurity)", + "usa-state-nv-sb220-2019": "US - Nevada SB220 (2019)", + "usa-state-ny-dfs-23-nycrr500-2023-amd2": "US - New York Department of Financial Services (NY DFS) 23NYCRR Part 500 (2023 Amendment 2)", + "usa-state-ny-shield-act-2019": "US - New York SHIELD Act (SB S5575B) (2019)", + "usa-state-or-ors-646a-2025": "US - Oregon Consumer Information Protection Act (ORS 646A) (2025)", + "usa-state-or-cpa-2023": "US - Oregon Consumer Privacy Act (SB 619) (2023)", + "usa-state-tn-tipa-2025": "US - Tennessee Information Protection Act (TIPA) (2025)", + "usa-state-tx-bc521-2009": "US - Texas Identity Theft Enforcement and Protection Act (BC521) (2009)", + "usa-state-tx-cdpa-2025": "US - Texas Consumer Data Protection Act (2025)", + "usa-state-tx-dir-security-control-standards-catalog-2-2": "US - Texas DIR Security Control Standards Catalog v2.2", + "usa-state-tx-sb820-2019": "US - Texas SB820 (2019)", + "usa-state-tx-sb2610-2025": "US - Texas Safe Harbor Law (SB2610) (2025)", + "usa-state-tx-txramp-2-0-level-1": "US - Texas Risk & Authorization Management Program 2.0 - Level 1", + "usa-state-tx-txramp-2-0-level-2": "US - Texas Risk & Authorization Management Program 2.0 - Level 2", + "usa-state-va-cdpa-2023": "US - Virginia Consumer Data Protection Act (2023)", + "usa-state-vt-act-171-2018": "US - Vermont Data Broker Registration Act (Act 171 of 2018)", + "emea-eu-ai-act-2024": "EU - European Union Artificial Intelligence Act (Regulation (EU) 2024/1689)", + "emea-eu-cyber-resilience-act-2024": "EU - European Union Cyber Resilience Act (2024)", + "emea-eu-cyber-resilience-act-annex-i-2024": "EU - European Union Cyber Resilience Act - Annex I (2024)", + "emea-eu-eba-ict-srm-2025": "EU - European Banking Authority Guidelines on ICT and Security Risk Management (2025)", + "emea-eu-dora-2023": "EU - Digital Operational Resilience Act (2023)", + "emea-eu-gdpr-2016": "EU - European Union General Data Protection Regulation (2016)", + "emea-eu-nis2-2022": "EU - European Union Agency for Cybersecurity NIS2 Directive (EU) 2022/2555)", + "emea-eu-nis2-annex-2024": "EU - European Union Agency for Cybersecurity NIS2 Annex (2024)", + "emea-eu-psd2-2015": "EU - Second Payment Services Directive (PSD2) (2015)", + "emea-aut-dpa-2018": "Austria - Data Protection Act (2018)", + "emea-bel-act-30-2018": "Belgium - Act of 30 July 2018", "emea-deu-fdpa-2017": "Germany - Federal Data Protection Act (2017)", "emea-deu-bsrit-2017": "Germany - Banking Supervisory Requirements for IT (2017)", "emea-deu-c5-2020": "Germany - Cloud Computing Compliance Controls Catalogue (C5) (2020)", - "emea-grc-pirppd-1997": "Greece - Protection of Individuals with Regard to the Processing of Personal Data (1997)", - "emea-hun-isdfi-2011": "Hungary - Informational Self-Determination and Freedom of Information (2011)", - "emea-irl-dpa-2003": "Ireland - Data Protection Act (DPA) (2003)", - "emea-isr-cmo-1-0": "Israel - Cybersecurity Methodology for an Organization v1.0", - "emea-isr-ppl-5741-1981": "Israel - Protection of Privacy Law, 5741 (1981)", - "emea-ita-pdpc-2003": "Italy - Personal Data Protection Code (2003)", + "emea-grc-pirppd-1997": "Greece - Protection of Individuals with Regard to the Processing of Personal Data (2472/1997)", + "emea-hun-act-cxii-2011": "Hungary - Act CXII of 2011", + "emea-irl-dpa-2018": "Ireland - Data Protection Act (DPA) (2018)", + "emea-isr-cmo-2-0": "Ireland - Cybersecurity Methodology for an Organization (CMO) v2.0", + "emea-isr-ppl-5741-2025": "Israel - Protection of Privacy Law, 5741 (2025)", + "emea-ita-pdpc-2018": "Italy - Personal Data Protection Code (2018)", "emea-ken-pda-2019": "Kenya - Data Protection Act (DPA) (2019)", "emea-nga-dpr-2019": "Nigeria - Data Protection Regulation (DPR) (2019)", "emea-nor-pda-2018": "Norway - Personal Data Act (PDA) (2018)", - "emea-pol-act-29-1997": "Poland - Act of 29 August 1997 on the Protection of Personal Data", + "emea-pol-act-10-2018": "Poland - Act of 10 May 2018 on the Protection of Personal Data", "emea-qat-pdppl-2020": "Qatar - Personal Data Privacy Protection Law (PDPPL) (2020)", - "emea-rus-federal-law-27-2006": "Russia - Federal Law of 27 (2006)", + "emea-rus-152-fz-2025": "Russia - Federal Law No. 152 - FZ (2025)", "emea-sau-cscc-1-2019": "Saudi Arabia - Critical Systems Cybersecurity Controls (CSCC – 1: 2019)", - "emea-sau-cgiot-2024": "Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT-1:2024)", + "emea-sau-cgiot-2024": "Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT - 1:2024)", "emea-sau-ecc-1-2018": "Saudi Arabia - Essential Cybersecurity Controls (ECC – 1 : 2018)", - "emea-sau-otcc-1-2022": "Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC -1: 2022)", + "emea-sau-otcc-1-2022": "Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC - 1: 2022)", "emea-sau-pdpl-2023": "Saudi Arabia - Personal Data Protection Law (PDPL) (2023)", - "emea-sau-sacs-002-2022": "Saudi Arabia - SACS-002 Third Party Cybersecurity Standard (2022)", - "emea-sau-sama-csf-1-2017": "Saudi Arabia - SAMA CSF Version 1.0 (2017)", - "emea-srb-act-9-2018": "Serbia - Act of 9 November 2018 on Personal Data Protection", + "emea-sau-sacs-002-2022": "Saudi Arabia - SACS - 002 Third Party Cybersecurity Standard (2022)", + "emea-sau-sama-csf-1-2017": "Saudi Arabia - Saudi Arabian Monetary Authority (SAMA) Cyber Security Framework Version 1.0 (2017)", + "emea-srb-act-9-2018": "Serbia - Act of 9 November 2018 on Personal Data Protection (Official Gazette No. 87/18)", "emea-zaf-popia-2013": "South Africa - Protection of Personal Information Act (POPIA) (2013)", - "emea-esp-boe-a-2022-7191": "Spain - BOE-A-2022-7191", - "emea-esp-decree-1720-2007": "Spain - Royal Decree 1720/2007", "emea-esp-decree-311-2022": "Spain - Royal Decree 311/2022", - "emea-esp-ccn-stic-825-2023": "Spain - ICT Security Guide CCN-STIC 825 (2023)", - "emea-che-fadp-2025": "Switzerland - FADP", + "emea-esp-ccn-stic-825-2026": "Spain - ICT Security Guide CCN - STIC 825 (2026)", + "emea-che-fadp-2025": "Switzerland - Federal Act on Data Protection (FADP) (2025)", "emea-tur-lppd-2016": "Turkey - Law on the Protection of Personal Data (LPPD) (2016)", "emea-uae-niaf-2023": "UAE - National Information Assurance Framework (NIAF) (2023)", - "emea-gbr-caf-4-0": "UK - Cyber Assessment Framework (CAF) (v4.0)", + "emea-gbr-caf-4-0": "UK - Cyber Assessment Framework (CAF) v4.0", "emea-gbr-cap-1850-2020": "UK - Cyber Assessment Framework for Aviation Guidance (CAP1850) (2020)", - "emea-gbr-cyber-essentials-requirements-3-3": "UK - Cyber Essentials (v3.3)", - "emea-gbr-def-stan-05-138-2024": "UK - Defstan 05-138 (2024)", - "emea-gbr-def-stan-05-138-l0-2024": "UK - Defstan 05-138 (2024) - L0", - "emea-gbr-def-stan-05-138-l1-2024": "UK - Defstan 05-138 (2024) - L1", - "emea-gbr-def-stan-05-138-l2-2024": "UK - Defstan 05-138 (2024) - L2", - "emea-gbr-def-stan-05-138-l3-2024": "UK - Defstan 05-138 (2024) - L3", - "emea-gbr-dpa-1998": "UK - Data Protection Act (DPA) (1998)", - "apac-aus-essential-8-2024": "Australia - Essential Eight (2024)", - "apac-aus-privacy-act-1998": "Australia - Privacy Act of 1998", + "emea-gbr-cyber-essentials-requirements-3-3": "UK - Cyber Essentials: Requirements for IT Infrastructure v3.3", + "emea-gbr-def-stan-05-138-2024": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024)", + "emea-gbr-def-stan-05-138-l0-2024": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L0", + "emea-gbr-def-stan-05-138-l1-2024": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L1", + "emea-gbr-def-stan-05-138-l2-2024": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L2", + "emea-gbr-def-stan-05-138-l3-2024": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L3", + "emea-gbr-dpa-2018": "UK - Data Protection Act (DPA) (2018)", + "apac-aus-essential-8-2024": "Australia - Essential Eight maturity model and ISM mapping (2024)", "apac-aus-privacy-principles-2026": "Australia - Privacy Principles (2026)", - "apac-aus-ism-2024-june": "Australia - Information Security Manual (ISM) (June 2024)", + "apac-aus-ism-2026-march": "Australia - Information Security Manual (ISM) (March 2026)", "apac-aus-cop-sitc-2020": "Australia - Code of Practice - Securing the Internet of Things for Consumers (2020)", - "apac-aus-ps-cps-230-2023": "Australia - Prudential Standard CPS 230 (2023)", - "apac-aus-ps-cps-234-2019": "Australia - Prudential Standard CPS 234 (2019)", - "apac-chn-cybersecurity-law-2017": "China - Cybersecurity Law (2017)", - "apac-chn-data-security-law-2021": "China - Data Security Law (2021)", + "apac-aus-ps-cps-230-2023": "Australia - Prudential Standard CPS 230 - Operational Risk Management (2023)", + "apac-aus-ps-cps-234-2019": "Australia - Prudential Standard CPS 234 Information Security (2019)", + "apac-chn-cybersecurity-law-2017": "China - Cybersecurity Law of the People's Republic of China (2017)", + "apac-chn-data-security-law-2021": "China - Data Security Law of the People's Republic of China (2021)", "apac-chn-csnip-2012": "China - Decision on Strengthening Network Information Protection (2012)", - "apac-chn-pipl-2021": "China - Personal Information Protection Law (2021)", + "apac-chn-pipl-2021": "China - Personal Information Protection Law of the People's Republic of China (2021)", "apac-hkg-pdo-2022": "Hong Kong - Personal Data Ordinance (2022)", - "apac-ind-dpdpa-2023": "India - DPDPA (2023)", - "apac-ind-privacy-rules-2011": "India - Privacy Rules (2011)", - "apac-ind-sebi-2024": "India - SEBI CSCRF (2024)", - "apac-jpn-ppi-2020": "Japan - Act on the Protection of Personal Information (2020)", + "apac-ind-dpdpa-2023": "India Digital Personal Data Protection Act (2023)", + "apac-ind-privacy-rules-2011": "India - Information Technology Rules (Privacy Rules) (2011)", + "apac-ind-sebi-2024": "India - SEBI Cybersecurity and Cyber Resilience Framework (2024)", + "apac-jpn-appi-2020": "Japan - Act on the Protection of Personal Information (2020)", "apac-jpn-ismap": "Japan - Information System Security Management and Assessment Program (ISMAP)", "apac-mys-pdpa-2010": "Malaysia - Personal Data Protection Act (PDPA) (2010)", + "apac-mys-bnm-rmit-2025": "Malaysia - Risk Management in Technology (RMiT) (2025)", "apac-nzl-hisf-mlhsp-2023": "New Zealand - HISF MLHSP (2023)", "apac-nzl-hisf-microsmall-2023": "New Zealand - HISF MicroSmall (2023)", - "apac-nzl-hisf-suppliers-2023": "New Zealand - HISF Guidance for Suppliers (2023)", - "apac-nzl-ism-3-9": "New Zealand - Information Security Manual (ISM) (v3.9)", + "apac-nzl-hisf-suppliers-2023": "New Zealand - HISO 10029:2024 NZ Health Information Security Framework Guidance for Suppliers", + "apac-nzl-ism-3-9": "New Zealand - Information Security Manual (ISM) v3.9", "apac-nzl-privacy-act-2020": "New Zealand - Privacy Act (2020)", "apac-phl-dpa-2012": "Philippines - Data Privacy Act (DPA) (2012)", "apac-sgp-pdpa-2012": "Singapore - Personal Data Protection Ac (PDPA) (2012)", @@ -244,14 +246,15 @@ "apac-kor-pipa-2011": "South Korea - Personal Information Protection Act (PIPA) (2011)", "apac-twn-pdpa-2025": "Taiwan - Personal Data Protection Act (PDPA) (2025)", "americas-arg-ppd-2018": "Argentina - Protection of Personal Data (2018)", - "americas-bhs-dpa-2003": "Bahamas - DPA (2003)", - "americas-bmu-mba-coc-2020": "Bermuda - Bermuda Monetary Authority Code of Conduct (2020)", + "americas-bhs-dpa-2003": "Bahamas - Data Protection Act (DPA) (2003)", + "americas-bmu-mba-coc-2020": "Bermuda - Bermuda Monetary Authority (BMA) Insurance Sector Operational Cyber Risk Management Code of Conduct (2020)", "americas-bra-lgpd-2018": "Brazil - General Data Protection Law (LGPD) (2018)", - "amaericas-can-osfi-self-assessment": "Canada - OSFI Cyber Security Self-Assessment Guidance", - "americas-can-osfi-b13-2022": "Canada - OSFI B-13 (2022)", - "americas-can-itsp-10-171-2025": "Canada - ITSP.10.171 (2025)", + "americas-can-osfi-self-assessment": "Canada - Office of the Superintendent of Financial Institutions Canada (OSFI) - Cyber Security Self - Assessment Guidance", + "americas-can-osfi-b13-2022": "Canada - OSFI B - 13 (2022)", + "americas-can-osfi-self-assessment-2": "Canada - OSFI Cyber Security Self - Assessment Guidance", + "americas-can-itsp-10-171-2025": "Canada - Protecting controlled information in non - Government of Canada systems and organizations (ITSP.10.171) (2025)", "americas-can-pipeda-2000": "Canada - Personal Information Protection and Electronic Documents Act (PIPEDA) (2000)", - "americas-chl-act-19628-1999": "Chile - Act 19628 (1999)", + "americas-chl-act-19628-1999": "Chile - Act 19628 - Protection of Personal Data (1999)", "americas-col-law-1581-2012": "Colombia - Law 1581 (2012)", "americas-mex-fdpa-2010": "Mexico - Federal Law on Protection of Personal Data held by Private Parties (2010)" } @@ -3174,15 +3177,15 @@ }, "general-cis-csc-8-1": { "AST-01": [ - "1.0", - "2.0", + "1", + "2", "2.1", "2.2" ], "AST-02": [ - "1.0", + "1", "1.1", - "2.0", + "2", "2.1", "2.2", "2.4", @@ -3226,7 +3229,7 @@ "4.11" ], "BCD-01": [ - "11.0", + "11", "11.1" ], "BCD-11": [ @@ -3255,8 +3258,8 @@ "18.4" ], "CFG-01": [ - "2.0", - "4.0", + "2", + "4", "4.1", "4.2" ], @@ -3269,6 +3272,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -3284,7 +3288,7 @@ "2.3" ], "CFG-03": [ - "4.0", + "4", "4.6", "4.8" ], @@ -3298,7 +3302,7 @@ "2.7" ], "CFG-04.2": [ - "9.0", + "9", "9.1", "9.4" ], @@ -3314,9 +3318,9 @@ "2.4" ], "MON-01": [ - "8.0", + "8", "8.2", - "13.0", + "13", "13.6" ], "MON-01.4": [ @@ -3377,13 +3381,13 @@ ], "MON-04": [ "8.3", - "8.1" + "8.10" ], "MON-07.1": [ "8.4" ], "MON-10": [ - "8.1" + "8.10" ], "MON-16.3": [ "2.3" @@ -3391,11 +3395,11 @@ "CRY-01": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "CRY-03": [ - "3.1" + "3.10" ], "CRY-05": [ "3.6", @@ -3410,10 +3414,10 @@ "12.3" ], "DCH-01": [ - "3.0", + "3", "3.1", "3.3", - "11.0", + "11", "11.3" ], "DCH-01.1": [ @@ -3477,20 +3481,20 @@ "3.5" ], "END-01": [ - "10.0" + "10" ], "END-02": [ - "10.0", + "10", "10.3", "10.4", "10.5", - "11.0" + "11" ], "END-03.1": [ "2.3" ], "END-04": [ - "10.0", + "10", "10.1", "10.4" ], @@ -3520,7 +3524,7 @@ "13.7" ], "END-08": [ - "9.0", + "9", "9.6", "9.7" ], @@ -3528,16 +3532,16 @@ "9.4" ], "HRS-05.2": [ - "9.0" + "9" ], "HRS-05.4": [ "9.4" ], "IAC-01": [ "4.7", - "5.0", + "5", "5.6", - "6.0", + "6", "6.6" ], "IAC-01.2": [ @@ -3573,7 +3577,7 @@ ], "IAC-08": [ "3.3", - "6.0", + "6", "6.8" ], "IAC-09": [ @@ -3595,9 +3599,9 @@ "6.7" ], "IAC-15.1": [ - "5.0", + "5", "5.6", - "6.0" + "6" ], "IAC-15.3": [ "5.3" @@ -3621,18 +3625,18 @@ "5.4" ], "IAC-22": [ - "4.1" + "4.10" ], "IAC-24": [ "4.3" ], "IRO-01": [ - "17.0", + "17", "17.5" ], "IRO-02": [ "2.3", - "17.0", + "17", "17.1", "17.3", "17.4", @@ -3678,7 +3682,7 @@ "17.8" ], "IRO-15": [ - "9.0", + "9", "9.6", "9.7" ], @@ -3707,7 +3711,7 @@ "4.12" ], "NET-01": [ - "12.0", + "12", "12.1", "12.2", "12.3", @@ -3765,13 +3769,13 @@ "3.13" ], "NET-18": [ - "9.0", + "9", "9.2", "9.3", - "13.1" + "13.10" ], "NET-18.1": [ - "13.1" + "13.10" ], "NET-20.4": [ "9.5" @@ -3818,21 +3822,21 @@ "SEA-01": [ "12.2", "12.6", - "16.0", - "16.1" + "16", + "16.10" ], "SEA-01.1": [ - "16.1" + "16.10" ], "SEA-02": [ "12.2", - "16.1" + "16.10" ], "SEA-03.1": [ "3.12" ], "SAT-01": [ - "14.0", + "14", "14.1" ], "SAT-02": [ @@ -3841,7 +3845,7 @@ "14.8" ], "SAT-02.2": [ - "9.0", + "9", "14.2" ], "SAT-03": [ @@ -3869,7 +3873,7 @@ ], "TDA-01": [ "15.7", - "16.0" + "16" ], "TDA-01.1": [ "15.7" @@ -3895,12 +3899,14 @@ "16.4" ], "TDA-05": [ - "16.1" + "16.1", + "16.10" ], "TDA-06": [ - "16.0", + "16", "16.1", "16.5", + "16.10", "16.11" ], "TDA-06.2": [ @@ -3967,7 +3973,7 @@ "2.2" ], "TPM-01": [ - "15.0", + "15", "15.2" ], "TPM-01.1": [ @@ -3993,13 +3999,13 @@ "15.4" ], "TPM-05.4": [ - "15.0" + "15" ], "TPM-05.5": [ - "15.0" + "15" ], "TPM-08": [ - "15.0", + "15", "15.6" ], "TPM-10": [ @@ -4009,16 +4015,16 @@ "16.2" ], "VPM-01": [ - "7.0", + "7", "7.1", - "18.0" + "18" ], "VPM-02": [ "7.2", "7.7" ], "VPM-04": [ - "7.0", + "7", "7.7", "12.1", "18.3" @@ -4052,23 +4058,25 @@ "7.5" ], "VPM-07": [ - "18.0", + "18", "18.1", "18.2", "18.5" ], "WEB-03": [ "4.4", - "13.1" + "13.10" ], "WEB-07": [ - "16.0", + "16", "16.1", - "16.7" + "16.7", + "16.10" ], "WEB-08": [ - "16.0", - "16.1" + "16", + "16.1", + "16.10" ] }, "general-cis-csc-8-1-ig1": { @@ -4503,6 +4511,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -4592,13 +4601,13 @@ ], "MON-04": [ "8.3", - "8.1" + "8.10" ], "MON-07.1": [ "8.4" ], "MON-10": [ - "8.1" + "8.10" ], "MON-16.3": [ "2.3" @@ -4606,11 +4615,11 @@ "CRY-01": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "CRY-03": [ - "3.1" + "3.10" ], "CRY-05": [ "3.6", @@ -4811,7 +4820,7 @@ "5.4" ], "IAC-22": [ - "4.1" + "4.10" ], "IAC-24": [ "4.3" @@ -4970,14 +4979,14 @@ "SEA-01": [ "12.2", "12.6", - "16.1" + "16.10" ], "SEA-01.1": [ - "16.1" + "16.10" ], "SEA-02": [ "12.2", - "16.1" + "16.10" ], "SEA-03.1": [ "3.12" @@ -5037,11 +5046,13 @@ "16.4" ], "TDA-05": [ - "16.1" + "16.1", + "16.10" ], "TDA-06": [ "16.1", "16.5", + "16.10", "16.11" ], "TDA-06.2": [ @@ -5168,10 +5179,12 @@ ], "WEB-07": [ "16.1", - "16.7" + "16.7", + "16.10" ], "WEB-08": [ - "16.1" + "16.1", + "16.10" ] }, "general-cis-csc-8-1-ig3": { @@ -5264,6 +5277,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -5368,13 +5382,13 @@ ], "MON-04": [ "8.3", - "8.1" + "8.10" ], "MON-07.1": [ "8.4" ], "MON-10": [ - "8.1" + "8.10" ], "MON-16.3": [ "2.3" @@ -5382,11 +5396,11 @@ "CRY-01": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "CRY-03": [ - "3.1" + "3.10" ], "CRY-05": [ "3.6", @@ -5595,7 +5609,7 @@ "5.4" ], "IAC-22": [ - "4.1" + "4.10" ], "IAC-24": [ "4.3" @@ -5737,10 +5751,10 @@ "NET-18": [ "9.2", "9.3", - "13.1" + "13.10" ], "NET-18.1": [ - "13.1" + "13.10" ], "NET-20.4": [ "9.5" @@ -5787,14 +5801,14 @@ "SEA-01": [ "12.2", "12.6", - "16.1" + "16.10" ], "SEA-01.1": [ - "16.1" + "16.10" ], "SEA-02": [ "12.2", - "16.1" + "16.10" ], "SEA-03.1": [ "3.12" @@ -5860,11 +5874,13 @@ "16.4" ], "TDA-05": [ - "16.1" + "16.1", + "16.10" ], "TDA-06": [ "16.1", "16.5", + "16.10", "16.11" ], "TDA-06.2": [ @@ -6011,14 +6027,16 @@ ], "WEB-03": [ "4.4", - "13.1" + "13.10" ], "WEB-07": [ "16.1", - "16.7" + "16.7", + "16.10" ], "WEB-08": [ - "16.1" + "16.1", + "16.10" ] }, "general-cobit-2019": { @@ -18602,10 +18620,10 @@ "7.2" ], "PES-12": [ - "7.12", "7.3", "7.5", - "7.8" + "7.8", + "7.12" ], "PES-12.1": [ "7.12" @@ -18830,7 +18848,7 @@ ], "TPM-03.2": [ "5.19", - "5.2" + "5.20" ], "TPM-03.3": [ "5.19", @@ -21216,19 +21234,19 @@ "6.7" ], "IRO-10": [ - "6.1" + "6.10" ], "PRI-01": [ - "6.1" + "6.10" ], "PRI-01.1": [ - "6.1" + "6.10" ], "PRI-01.3": [ "6.8" ], "PRI-01.4": [ - "6.1" + "6.10" ], "PRI-01.6": [ "6.11" @@ -21239,7 +21257,7 @@ "PRI-01.11": [ "6.5", "6.8", - "6.1" + "6.10" ], "PRI-02": [ "6.3" @@ -21278,25 +21296,25 @@ ], "PRI-06": [ "6.9", - "6.1" + "6.10" ], "PRI-06.1": [ "6.9" ], "PRI-06.4": [ - "6.1" + "6.10" ], "PRI-07": [ - "6.1" + "6.10" ], "PRI-07.1": [ - "6.1" + "6.10" ], "SAT-03": [ - "6.1" + "6.10" ], "SAT-03.3": [ - "6.1" + "6.10" ] }, "general-iso-31000-2018": { @@ -22515,7 +22533,7 @@ "10.2(e)" ] }, - "general-mitre-att&ck-16-1": { + "general-mitre-att_ck-16-1": { "AST-02": [ "T1011.001", "T1020.001", @@ -30479,6 +30497,9 @@ "CM.AW-P2", "CM.AW-P3" ], + "PRI-01.12": [ + "CT.DM-P10" + ], "PRI-02": [ "CM.PO-P1", "CM.AW-P1" @@ -50836,6 +50857,7 @@ ], "GOV-15": [ "03.15.01.a", + "03.16.01", "03.17.01.a" ], "GOV-15.1": [ @@ -50867,6 +50889,9 @@ "AST-01.1": [ "03.01.03" ], + "AST-01.4": [ + "03.04.08.c" + ], "AST-02": [ "03.04.08.a", "03.04.08.c", @@ -50890,8 +50915,7 @@ "AST-02.9": [ "03.04.08.a", "03.04.10.a", - "03.04.10.b", - "03.04.10.c" + "03.04.10.b" ], "AST-03": [ "03.09.02.a.03" @@ -50965,17 +50989,21 @@ ], "CHG-01": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.d" ], "CHG-02": [ "03.04.02.b", "03.04.03.a", "03.04.03.b", - "03.04.03.c" + "03.04.03.c", + "03.07.05.a" ], "CHG-02.1": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.b", + "03.07.05.a" ], "CHG-02.2": [ "03.04.03.b", @@ -51009,7 +51037,8 @@ "03.12.01" ], "CPL-01.1": [ - "03.12.02.a.01" + "03.12.02.a.01", + "03.12.02.a.02" ], "CPL-01.2": [ "03.04.11.a", @@ -51027,14 +51056,17 @@ "03.12.03" ], "CPL-03.2": [ + "03.04.02.b", "03.04.08.c", "03.12.03" ], "CFG-01": [ - "03.04.01.a" + "03.04.01.a", + "03.04.03.a" ], "CFG-02": [ "03.01.01.h", + "03.01.03", "03.01.08.a", "03.01.08.b", "03.01.09", @@ -51044,32 +51076,38 @@ "03.01.11", "03.01.12.a", "03.01.16.a", + "03.01.16.c", "03.01.18.a", + "03.03.08.a", "03.04.01.a", "03.04.02.a", + "03.04.02.b", "03.04.06.a", "03.04.06.b", "03.04.06.d", + "03.05.04", + "03.05.07.c", "03.05.07.d", "03.05.07.e", "03.05.07.f", "03.05.12.d", + "03.07.05.b", "03.08.07.a", "03.13.12.b" ], "CFG-02.1": [ "03.04.01.b", - "03.04.02.b" + "03.04.06.c" ], "CFG-02.2": [ "03.04.02.b", - "03.04.03.d" + "03.04.03.d", + "03.13.13.b" ], "CFG-02.5": [ "03.04.01.a", "03.04.02.a", "03.04.06.a", - "03.04.06.b", "03.04.06.d", "03.04.12.a" ], @@ -51127,7 +51165,8 @@ "MON-01": [ "03.03.01.a", "03.12.03", - "03.14.06.a" + "03.14.06.a", + "03.14.06.a.02" ], "MON-01.1": [ "03.13.01.a" @@ -51144,7 +51183,6 @@ "03.14.06.c" ], "MON-01.8": [ - "03.03.01.b", "03.03.05.a" ], "MON-01.12": [ @@ -51163,13 +51201,15 @@ "03.03.05.c" ], "MON-02.2": [ - "03.03.01.b", "03.03.05.a", "03.03.05.c" ], "MON-02.3": [ "03.03.05.c" ], + "MON-02.6": [ + "03.03.01.b" + ], "MON-02.7": [ "03.03.01.a" ], @@ -51190,6 +51230,9 @@ "MON-03.3": [ "03.01.07.b" ], + "MON-03.6": [ + "03.03.01.b" + ], "MON-05": [ "03.03.04.b" ], @@ -51207,7 +51250,8 @@ "MON-08": [ "03.03.03.b", "03.03.06.b", - "03.03.08.a" + "03.03.08.a", + "03.03.08.b" ], "MON-08.1": [ "03.03.08.a" @@ -51250,10 +51294,12 @@ "03.13.11" ], "CRY-03": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "CRY-05": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "CRY-05.1": [ "03.13.08" @@ -51342,7 +51388,8 @@ ], "DCH-07": [ "03.08.05.a", - "03.08.05.b" + "03.08.05.b", + "03.08.05.c" ], "DCH-07.1": [ "03.08.05.a", @@ -51416,6 +51463,7 @@ ], "DCH-18": [ "03.01.20.c.02", + "03.10.07.b", "03.14.08" ], "DCH-19": [ @@ -51425,7 +51473,11 @@ "DCH-21": [ "03.08.03" ], + "DCH-24": [ + "03.04.11.a" + ], "END-01": [ + "03.01.03", "03.14.02.a" ], "END-04": [ @@ -51472,16 +51524,19 @@ "03.01.01.d.02", "03.01.02", "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.15.03.b" ], "HRS-02.1": [ "03.01.02" ], "HRS-03": [ "03.01.22.a", + "03.02.02.a.01", "03.06.04.a", "03.06.05.d", "03.07.06.a", + "03.07.06.d", "03.08.02", "03.15.03.b", "03.16.03.b" @@ -51495,7 +51550,8 @@ ], "HRS-04": [ "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.09.02.b.01" ], "HRS-04.1": [ "03.01.22.a", @@ -51513,7 +51569,8 @@ "HRS-05": [ "03.01.01.h", "03.01.22.a", - "03.15.03.a" + "03.15.03.a", + "03.15.03.b" ], "HRS-05.1": [ "03.01.12.a", @@ -51539,14 +51596,12 @@ "03.15.03.a" ], "HRS-05.7": [ - "03.15.03.b", "03.15.03.c", "03.15.03.d" ], "HRS-06": [ "03.01.18.a", "03.12.05.a", - "03.15.03.b", "03.15.03.c" ], "HRS-06.1": [ @@ -51564,12 +51619,14 @@ "HRS-08": [ "03.01.01.g.02", "03.09.02.a", - "03.09.02.b.01" + "03.09.02.b.01", + "03.09.02.b.02" ], "HRS-09": [ "03.01.01.f.03", "03.01.01.g.02", "03.09.02.a", + "03.09.02.a.02", "03.09.02.a.03", "03.09.02.b.01" ], @@ -51603,6 +51660,8 @@ "03.05.12.e" ], "IAC-01.2": [ + "03.01.01.d.01", + "03.01.16.b", "03.05.01.a", "03.05.02", "03.05.05.d", @@ -51612,7 +51671,6 @@ "03.05.07.d", "03.05.07.e", "03.05.12.d", - "03.05.12.f", "03.07.05.a" ], "IAC-02": [ @@ -51650,7 +51708,11 @@ "IAC-06.3": [ "03.05.03" ], + "IAC-06.4": [ + "03.05.03" + ], "IAC-07": [ + "03.01.01.b", "03.01.01.g.01", "03.01.01.g.02", "03.01.01.g.03", @@ -51715,10 +51777,8 @@ "03.05.07.e", "03.05.07.f", "03.05.12.b", - "03.05.12.c", "03.05.12.d", - "03.05.12.e", - "03.05.12.f" + "03.05.12.e" ], "IAC-10.3": [ "03.05.12.a" @@ -51761,6 +51821,7 @@ "03.01.01.d.02", "03.01.01.e", "03.01.01.f.01", + "03.01.01.f.02", "03.01.01.f.03", "03.01.01.f.04", "03.01.01.f.05", @@ -51770,9 +51831,11 @@ "03.01.02", "03.01.05.b", "03.01.05.c", - "03.01.05.d" + "03.01.05.d", + "03.05.07.e" ], "IAC-15.1": [ + "03.01.01.d.01", "03.05.05.b", "03.05.05.c", "03.05.05.d", @@ -51795,6 +51858,7 @@ "03.01.01.f.05" ], "IAC-15.7": [ + "03.01.01.b", "03.01.01.e", "03.01.05.c" ], @@ -51830,6 +51894,7 @@ "03.01.03", "03.01.04.b", "03.01.05.a", + "03.01.05.b", "03.06.05.d", "03.10.01.a" ], @@ -51837,6 +51902,7 @@ "03.01.01.c.03", "03.01.01.d.01", "03.01.01.d.02", + "03.01.02", "03.01.04.b", "03.01.05.a", "03.01.05.b", @@ -51876,8 +51942,7 @@ "03.07.05.c" ], "IAC-28": [ - "03.05.12.a", - "03.05.12.c" + "03.05.12.a" ], "IAC-28.1": [ "03.01.01.b", @@ -51892,7 +51957,8 @@ "03.06.02.a", "03.06.02.b", "03.06.02.c", - "03.06.02.d" + "03.06.02.d", + "03.06.05.b" ], "IRO-04": [ "03.06.01", @@ -51903,10 +51969,10 @@ "03.06.05.a.04", "03.06.05.a.05", "03.06.05.a.06", - "03.06.05.b" + "03.06.05.b", + "03.06.05.d" ], "IRO-04.2": [ - "03.06.04.b", "03.06.05.c" ], "IRO-04.3": [ @@ -51919,13 +51985,18 @@ "IRO-06": [ "03.06.03" ], + "IRO-07": [ + "03.06.02.b", + "03.06.02.d" + ], "IRO-09": [ "03.06.02.a", "03.06.02.b" ], "IRO-10": [ "03.06.02.b", - "03.06.02.c" + "03.06.02.c", + "03.06.02.d" ], "IRO-10.2": [ "03.06.02.b", @@ -51935,6 +52006,7 @@ "03.06.02.d" ], "IRO-12": [ + "03.01.22.b", "03.06.01" ], "IRO-13": [ @@ -51953,6 +52025,8 @@ "03.12.01" ], "IAO-03": [ + "03.01.16.a", + "03.04.11.a", "03.04.11.b", "03.15.02.a", "03.15.02.a.01", @@ -52026,12 +52100,10 @@ "03.07.06.d" ], "MNT-06.1": [ - "03.07.06.a", "03.07.06.c", "03.07.06.d" ], "MNT-06.2": [ - "03.07.06.a", "03.07.06.c" ], "MNT-09": [ @@ -52066,7 +52138,6 @@ "NET-01": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.18.a", "03.13.01.a" ], @@ -52079,6 +52150,7 @@ ], "NET-03": [ "03.01.12.a", + "03.01.18.a", "03.13.01.a", "03.13.01.b", "03.13.01.c" @@ -52103,7 +52175,6 @@ ], "NET-05.2": [ "03.01.03", - "03.12.05.a", "03.12.05.b", "03.12.05.c" ], @@ -52114,6 +52185,7 @@ "03.13.01.b" ], "NET-07": [ + "03.07.05.c", "03.13.09" ], "NET-08": [ @@ -52129,8 +52201,7 @@ "NET-14": [ "03.01.12.a", "03.01.12.b", - "03.01.12.c", - "03.01.12.d" + "03.01.12.c" ], "NET-14.1": [ "03.01.12.b" @@ -52139,7 +52210,6 @@ "03.01.12.a" ], "NET-14.3": [ - "03.01.12.b", "03.01.12.c" ], "NET-14.4": [ @@ -52147,7 +52217,6 @@ ], "NET-14.5": [ "03.01.12.a", - "03.01.12.c", "03.10.06.a", "03.10.06.b" ], @@ -52174,24 +52243,29 @@ "03.08.01", "03.08.02", "03.10.01.a", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "PES-02": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.a", "03.10.01.b", "03.10.01.c", "03.10.01.d", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "PES-02.1": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.b", "03.10.01.d" ], "PES-03": [ + "03.04.05", "03.10.02.a", "03.10.07.a", "03.10.07.a.01", @@ -52201,10 +52275,12 @@ "PES-03.1": [ "03.10.02.a", "03.10.07.a", + "03.10.07.a.01", "03.10.07.a.02" ], "PES-03.3": [ "03.10.02.a", + "03.10.07.a.02", "03.10.07.b" ], "PES-03.4": [ @@ -52230,19 +52306,18 @@ "03.10.02.b" ], "PES-05.1": [ - "03.10.02.a", - "03.10.02.b" + "03.10.02.a" ], "PES-05.2": [ "03.10.02.a", "03.10.02.b" ], "PES-06": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "PES-06.1": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "PES-06.2": [ @@ -52279,7 +52354,8 @@ ], "RSK-01": [ "03.11.01.a", - "03.17.01.a" + "03.17.01.a", + "03.17.03.b" ], "RSK-01.1": [ "03.11.01.a" @@ -52295,6 +52371,7 @@ "03.11.01.a" ], "RSK-03.1": [ + "03.11.01.a", "03.15.02.a.03" ], "RSK-04": [ @@ -52336,7 +52413,6 @@ "SEA-01": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.16.c", "03.01.18.a", "03.13.01.c", @@ -52376,17 +52452,22 @@ "03.15.01.a" ], "OPS-03": [ - "03.15.01.b" + "03.15.01.a" ], "SAT-01": [ "03.02.01.a" ], + "SAT-01.1": [ + "03.02.01.b", + "03.02.02.a.02", + "03.02.02.b", + "03.06.04.b" + ], "SAT-02": [ "03.01.22.a", "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.06.04.a.03" ], "SAT-02.2": [ @@ -52399,11 +52480,10 @@ "03.02.02.a", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a", "03.06.04.a.01", "03.06.04.a.02", - "03.06.04.b" + "03.06.04.a.03" ], "SAT-03.3": [ "03.01.22.a", @@ -52418,15 +52498,10 @@ "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a.02" ], - "SAT-03.7": [ - "03.06.04.b" - ], "TDA-01": [ "03.12.01", "03.12.03", @@ -52475,10 +52550,12 @@ "03.01.20.c.01", "03.07.06.a", "03.16.01", - "03.16.03.a" + "03.16.03.a", + "03.17.02" ], "TPM-01.1": [ - "03.07.06.a" + "03.07.06.a", + "03.07.06.b" ], "TPM-02": [ "03.11.01.a", @@ -52543,6 +52620,7 @@ ], "TPM-05.4": [ "03.07.06.a", + "03.07.06.b", "03.16.03.b" ], "TPM-05.5": [ @@ -52580,13 +52658,12 @@ ], "THR-01": [ "03.11.02.a", + "03.14.01.a", "03.14.03.a" ], "THR-03": [ "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", - "03.02.02.b", "03.11.02.a", "03.14.03.a" ], @@ -52596,6 +52673,9 @@ "THR-05": [ "03.02.01.a.03" ], + "THR-06": [ + "03.14.01.a" + ], "THR-09": [ "03.15.02.a.03" ], @@ -52620,8 +52700,7 @@ ], "VPM-04": [ "03.11.02.b", - "03.14.01.a", - "03.14.01.b" + "03.14.01.a" ], "VPM-05": [ "03.11.02.b", @@ -52630,7 +52709,8 @@ "03.14.01.b" ], "VPM-06": [ - "03.11.02.a" + "03.11.02.a", + "03.14.01.a" ], "VPM-06.1": [ "03.11.02.c" @@ -53312,6 +53392,15 @@ ] }, "general-nist-800-171a-r3": { + "GOV-01": [ + "A.03.15.01.a[01]" + ], + "GOV-01.1": [ + "A.03.12.03[01]" + ], + "GOV-01.2": [ + "A.03.12.03[01]" + ], "GOV-02": [ "A.03.15.01.a[01]", "A.03.15.01.a[02]", @@ -53321,25 +53410,70 @@ "GOV-03": [ "A.03.15.01.ODP[01]", "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.b[02]", + "A.03.15.03.d[01]" + ], + "GOV-05": [ + "A.03.12.03[01]" ], "GOV-15": [ - "A.03.16.01" + "A.03.15.01.a[03]", + "A.03.16.01", + "A.03.17.01.a[01]" + ], + "GOV-15.1": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "GOV-15.2": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "GOV-15.3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "GOV-15.4": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "GOV-15.5": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "AST-01": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.18.a[01]", + "A.03.04.11.a[02]", + "A.03.07.04.a[01]" + ], + "AST-01.1": [ + "A.03.01.03[02]" ], "AST-01.4": [ "A.03.04.08.c" ], "AST-02": [ + "A.03.04.08.a", + "A.03.04.08.c", "A.03.04.10.ODP[01]", "A.03.04.10.a", "A.03.04.10.b[01]", - "A.03.04.10.b[02]" + "A.03.04.10.b[02]", + "A.03.04.11.a[02]" ], "AST-02.1": [ + "A.03.04.10.a", + "A.03.04.10.b[02]", "A.03.04.10.c[01]", "A.03.04.10.c[02]", "A.03.04.10.c[03]" ], + "AST-02.4": [ + "A.03.04.02.a[02]", + "A.03.04.06.a" + ], "AST-02.8": [ "A.03.04.11.a[01]", "A.03.04.11.a[02]", @@ -53347,37 +53481,123 @@ "A.03.04.11.b[01]", "A.03.04.11.b[02]" ], + "AST-02.9": [ + "A.03.04.08.a", + "A.03.04.10.a", + "A.03.04.10.b[02]" + ], + "AST-03": [ + "A.03.09.02.a.03" + ], + "AST-03.1": [ + "A.03.09.02.a.03" + ], + "AST-04": [ + "A.03.01.03[02]", + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "AST-04.1": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "AST-04.2": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "AST-04.3": [ + "A.03.01.03[02]" + ], + "AST-05": [ + "A.03.07.04.a[02]" + ], + "AST-09": [ + "A.03.07.04.c", + "A.03.08.03" + ], "AST-10": [ "A.03.09.02.a.03" ], + "AST-12": [ + "A.03.01.18.a[01]" + ], + "AST-13": [ + "A.03.01.18.a[01]" + ], + "AST-14": [ + "A.03.01.18.a[01]" + ], + "AST-16": [ + "A.03.01.18.a[01]" + ], + "AST-17": [ + "A.03.11.01.a", + "A.03.16.01" + ], "AST-24": [ - "A.03.04.12.a" + "A.03.04.12.a", + "A.03.04.12.b" ], "AST-25": [ "A.03.04.12.b" ], + "AST-27": [ + "A.03.01.12.a[01]", + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" + ], + "AST-31": [ + "A.03.01.03[02]" + ], + "BCD-11": [ + "A.03.08.09.a" + ], "BCD-11.4": [ "A.03.08.09.a", "A.03.08.09.b" ], "CHG-01": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.d[01]", "A.03.04.03.d[02]" ], "CHG-02": [ + "A.03.04.02.b[01]", "A.03.04.03.a", - "A.03.04.03.c[01]" + "A.03.04.03.b[02]", + "A.03.04.03.c[01]", + "A.03.07.05.a[01]" ], "CHG-02.1": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.b[02]", - "A.03.04.05[05]" + "A.03.04.05[05]", + "A.03.07.05.a[01]" ], "CHG-02.2": [ - "A.03.04.03.c[02]" + "A.03.04.03.b[02]", + "A.03.04.03.c[02]", + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "CHG-02.3": [ + "A.03.04.04.a" ], "CHG-03": [ "A.03.04.03.b[01]", - "A.03.04.04.a" + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "CHG-04": [ + "A.03.04.02.b[01]", + "A.03.04.05[06]" ], "CHG-04.4": [ "A.03.04.05[06]" @@ -53389,25 +53609,52 @@ "CHG-06": [ "A.03.04.04.b" ], + "CPL-01": [ + "A.03.04.11.a[01]", + "A.03.12.01" + ], + "CPL-01.1": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" + ], + "CPL-01.2": [ + "A.03.04.11.a[01]" + ], "CPL-02": [ + "A.03.12.01", "A.03.12.03[01]", "A.03.12.03[03]", "A.03.12.03[04]" ], "CPL-02.1": [ - "A.03.12.01.ODP[01]" + "A.03.12.01.ODP[01]", + "A.03.12.01" ], "CPL-03": [ - "A.03.12.01" + "A.03.12.01", + "A.03.12.03[01]" ], "CPL-03.2": [ + "A.03.04.02.b[01]", + "A.03.04.08.c", "A.03.12.03[02]" ], "CFG-01": [ + "A.03.04.01.a[02]", "A.03.04.03.a" ], "CFG-02": [ + "A.03.01.01.h", "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.08.a", + "A.03.01.08.b", + "A.03.01.09", + "A.03.01.10.a", + "A.03.01.10.b", + "A.03.01.10.c", + "A.03.01.11", + "A.03.01.12.a[03]", "A.03.01.16.a[03]", "A.03.01.16.c", "A.03.01.18.a[02]", @@ -53421,18 +53668,23 @@ "A.03.04.06.ODP[03]", "A.03.04.06.ODP[04]", "A.03.04.06.ODP[05]", + "A.03.04.06.a", "A.03.04.06.b[01]", "A.03.04.06.b[02]", "A.03.04.06.b[03]", "A.03.04.06.b[04]", "A.03.04.06.b[05]", + "A.03.04.06.d", "A.03.05.04[01]", "A.03.05.04[02]", "A.03.05.07.c", "A.03.05.07.d", "A.03.05.07.e", "A.03.05.07.f", - "A.03.07.05.b[02]" + "A.03.05.12.d", + "A.03.07.05.b[01]", + "A.03.08.07.a", + "A.03.13.12.b" ], "CFG-02.1": [ "A.03.04.01.ODP[01]", @@ -53443,72 +53695,145 @@ "A.03.04.06.c" ], "CFG-02.2": [ + "A.03.04.02.b[01]", "A.03.04.03.d[01]", - "A.03.04.03.d[02]" + "A.03.04.03.d[02]", + "A.03.13.13.b[02]" ], "CFG-02.5": [ + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.d", "A.03.04.12.ODP[01]", - "A.03.04.12.ODP[02]" + "A.03.04.12.ODP[02]", + "A.03.04.12.a" ], "CFG-02.7": [ - "A.03.04.02.b[01]", + "A.03.04.01.a[01]", "A.03.04.02.b[02]" ], "CFG-02.9": [ - "A.03.03.02.b" + "A.03.03.02.b", + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.06.a", + "A.03.04.08.a", + "A.03.04.12.a", + "A.03.13.11" ], "CFG-03": [ "A.03.04.02.ODP[01]", - "A.03.04.06.d" + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.b[01]", + "A.03.04.06.b[02]", + "A.03.04.06.b[03]", + "A.03.04.06.b[04]", + "A.03.04.06.b[05]", + "A.03.04.06.d", + "A.03.04.08.a" ], "CFG-03.1": [ - "A.03.04.06.ODP[06]" + "A.03.04.06.ODP[06]", + "A.03.04.06.c", + "A.03.04.08.c" + ], + "CFG-03.2": [ + "A.03.04.08.b" ], "CFG-03.3": [ "A.03.04.08.ODP[01]", "A.03.04.08.a", "A.03.04.08.b", + "A.03.13.13.a[01]", + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", "A.03.13.13.b[03]" ], + "CFG-04": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", + "A.03.13.13.b[03]" + ], + "CFG-04.1": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], + "CFG-05": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], + "CFG-06": [ + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.03.a" + ], "CFG-08": [ - "A.03.01.02[01]" + "A.03.01.02[01]", + "A.03.01.02[02]" ], "MON-01": [ + "A.03.03.01.a", + "A.03.12.03[01]", "A.03.14.06.a.01[01]", "A.03.14.06.a.01[02]", "A.03.14.06.a.02" ], + "MON-01.1": [ + "A.03.13.01.a[01]" + ], "MON-01.3": [ "A.03.13.01.a[01]", "A.03.13.01.a[03]", - "A.03.14.06.c[01]", - "A.03.14.06.c[02]" + "A.03.14.06.b", + "A.03.14.06.c[01]" ], "MON-01.4": [ - "A.03.03.02.a.01", - "A.03.03.03.a" + "A.03.03.01.a", + "A.03.03.03.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" ], "MON-01.8": [ "A.03.03.01.ODP[02]", - "A.03.03.01.b[01]", "A.03.03.05.ODP[01]", "A.03.03.05.a" ], "MON-01.12": [ "A.03.03.05.b" ], + "MON-01.15": [ + "A.03.01.07.b" + ], "MON-02": [ "A.03.03.05.ODP[01]", "A.03.03.05.a", "A.03.03.05.c[01]" ], "MON-02.1": [ + "A.03.03.05.a", + "A.03.03.05.c[02]" + ], + "MON-02.2": [ + "A.03.03.05.a", + "A.03.03.05.c[01]" + ], + "MON-02.3": [ "A.03.03.05.c[02]" ], + "MON-02.6": [ + "A.03.03.01.b[01]" + ], + "MON-02.7": [ + "A.03.03.01.a" + ], "MON-03": [ "A.03.03.01.ODP[01]", "A.03.03.01.a", - "A.03.03.01.b[02]", + "A.03.03.02.a.01", "A.03.03.02.a.02", "A.03.03.02.a.03", "A.03.03.02.a.04", @@ -53516,9 +53841,16 @@ "A.03.03.02.a.06", "A.03.03.02.b" ], + "MON-03.2": [ + "A.03.03.01.a" + ], "MON-03.3": [ "A.03.01.07.b" ], + "MON-03.6": [ + "A.03.03.01.b[01]", + "A.03.03.01.b[02]" + ], "MON-05": [ "A.03.03.04.ODP[01]", "A.03.03.04.ODP[02]", @@ -53533,6 +53865,7 @@ "A.03.03.06.a[04]" ], "MON-07": [ + "A.03.03.02.a.02", "A.03.03.07.ODP[01]", "A.03.03.07.a", "A.03.03.07.b[01]" @@ -53547,13 +53880,34 @@ "A.03.03.08.a[01]", "A.03.03.08.b" ], + "MON-08.1": [ + "A.03.03.08.a[01]" + ], "MON-08.2": [ + "A.03.03.08.a[01]", "A.03.03.08.b" ], + "MON-08.3": [ + "A.03.03.08.a[01]" + ], "MON-10": [ "A.03.03.03.b" ], + "MON-11": [ + "A.03.01.22.b[01]" + ], + "MON-11.3": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", + "A.03.14.06.b" + ], "MON-16": [ + "A.03.01.01.e", + "A.03.03.05.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", "A.03.14.06.b" ], "CRY-01": [ @@ -53562,6 +53916,12 @@ "A.03.13.11.ODP[01]", "A.03.13.11" ], + "CRY-01.1": [ + "A.03.13.08[02]" + ], + "CRY-01.5": [ + "A.03.13.11" + ], "CRY-03": [ "A.03.13.08[01]", "A.03.13.11.ODP[01]", @@ -53572,19 +53932,86 @@ "A.03.13.11.ODP[01]", "A.03.13.11" ], + "CRY-05.1": [ + "A.03.13.08[02]" + ], + "CRY-07": [ + "A.03.01.16.a[02]" + ], + "CRY-08": [ + "A.03.13.10[01]" + ], "CRY-09": [ "A.03.13.10.ODP[01]", "A.03.13.10[01]", "A.03.13.10[02]" ], + "CRY-09.3": [ + "A.03.13.10[02]" + ], + "CRY-09.4": [ + "A.03.13.10[02]" + ], + "DCH-01": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.08.01[01]", + "A.03.08.01[02]" + ], + "DCH-01.1": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.05.a[01]" + ], + "DCH-01.2": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.d", + "A.03.06.05.d", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.08.05.a[02]", + "A.03.17.01.c" + ], + "DCH-01.3": [ + "A.03.08.05.c" + ], "DCH-01.4": [ + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", "A.03.15.02.c", "A.03.17.01.c" ], + "DCH-02": [ + "A.03.04.11.a[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.04[01]" + ], "DCH-03": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", "A.03.08.02" ], "DCH-03.1": [ + "A.03.01.22.a", "A.03.15.02.c", "A.03.17.01.c" ], @@ -53597,13 +54024,37 @@ "A.03.08.01[01]", "A.03.08.01[02]" ], + "DCH-06.1": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], + "DCH-06.2": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "DCH-06.4": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], "DCH-07": [ "A.03.08.05.a[01]", "A.03.08.05.a[02]", "A.03.08.05.b", "A.03.08.05.c" ], + "DCH-07.1": [ + "A.03.08.05.a[02]", + "A.03.08.05.b" + ], + "DCH-07.2": [ + "A.03.08.05.a[02]" + ], + "DCH-08": [ + "A.03.08.03" + ], "DCH-09": [ + "A.03.07.04.c", "A.03.08.03" ], "DCH-10": [ @@ -53613,51 +54064,108 @@ "DCH-10.2": [ "A.03.08.07.b" ], + "DCH-12": [ + "A.03.08.07.a" + ], "DCH-13": [ "A.03.01.20.ODP[01]", "A.03.01.20.a", "A.03.01.20.b", "A.03.01.20.c.01", - "A.03.01.20.c.02" + "A.03.01.20.c.02", + "A.03.01.20.d" + ], + "DCH-13.1": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.01.20.d" ], "DCH-13.2": [ + "A.03.01.20.a", + "A.03.01.20.d" + ], + "DCH-13.3": [ + "A.03.01.20.b", + "A.03.01.20.c.01" + ], + "DCH-13.4": [ + "A.03.01.20.a", + "A.03.01.20.c.01", "A.03.01.20.d" ], + "DCH-14": [ + "A.03.01.20.b" + ], + "DCH-14.2": [ + "A.03.01.20.b", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], + "DCH-14.3": [ + "A.03.01.03[02]", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], "DCH-15": [ "A.03.01.22.a", - "A.03.01.22.b[01]", - "A.03.01.22.b[02]" + "A.03.01.22.b[01]" + ], + "DCH-17": [ + "A.03.01.20.a" ], "DCH-18": [ + "A.03.01.20.c.02", + "A.03.10.07.b", "A.03.14.08[01]", "A.03.14.08[02]", "A.03.14.08[03]", "A.03.14.08[04]" ], + "DCH-19": [ + "A.03.04.11.a[01]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "DCH-21": [ + "A.03.08.03" + ], "DCH-24": [ "A.03.04.11.a[01]" ], "END-01": [ - "A.03.01.03[01]" + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.14.02.a[01]" ], "END-04": [ "A.03.14.02.ODP[01]", "A.03.14.02.a[01]", "A.03.14.02.a[02]", + "A.03.14.02.c.01[01]", "A.03.14.02.c.02" ], "END-04.1": [ "A.03.14.02.b" ], + "END-04.3": [ + "A.03.14.02.a[01]" + ], "END-04.7": [ + "A.03.14.02.a[01]", "A.03.14.02.c.01[01]", "A.03.14.02.c.01[02]" ], + "END-07": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" + ], "END-10": [ "A.03.13.13.a[01]", "A.03.13.13.a[02]", "A.03.13.13.b[01]", - "A.03.13.13.b[02]", "A.03.13.13.b[03]" ], "END-14": [ @@ -53671,10 +54179,43 @@ "A.03.01.01.ODP[01]", "A.03.01.01.ODP[02]", "A.03.01.01.ODP[03]", - "A.03.01.01.ODP[04]" + "A.03.01.01.ODP[04]", + "A.03.01.01.g.02", + "A.03.15.03.a", + "A.03.15.03.d[01]" + ], + "HRS-02": [ + "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.09.01.a", + "A.03.09.01.b", + "A.03.15.03.b" + ], + "HRS-02.1": [ + "A.03.01.02[01]", + "A.03.01.02[02]" ], "HRS-03": [ - "A.03.06.05.d" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.05.d", + "A.03.07.06.a", + "A.03.07.06.d[02]", + "A.03.08.02", + "A.03.15.03.b", + "A.03.16.03.b" + ], + "HRS-03.1": [ + "A.03.01.22.a", + "A.03.15.03.b" + ], + "HRS-03.2": [ + "A.03.07.06.d[01]" ], "HRS-04": [ "A.03.09.01.ODP[01]", @@ -53683,12 +54224,28 @@ "A.03.09.02.b.01[01]" ], "HRS-04.1": [ - "A.03.09.01.ODP[01]" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.09.01.ODP[01]", + "A.03.09.01.a", + "A.03.09.01.b" + ], + "HRS-04.2": [ + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.04.a.01", + "A.03.15.03.b" ], "HRS-05": [ + "A.03.01.01.h", + "A.03.01.22.a", + "A.03.15.03.a", "A.03.15.03.b" ], "HRS-05.1": [ + "A.03.01.18.a[01]", + "A.03.01.22.a", "A.03.15.03.ODP[01]", "A.03.15.03.a", "A.03.15.03.d[01]", @@ -53698,39 +54255,103 @@ "A.03.15.03.a" ], "HRS-05.3": [ + "A.03.01.01.h", + "A.03.01.18.a[01]", + "A.03.15.03.a" + ], + "HRS-05.4": [ "A.03.15.03.a" ], "HRS-05.5": [ + "A.03.01.18.a[01]", "A.03.15.03.a" ], "HRS-05.7": [ + "A.03.15.03.c", + "A.03.15.03.d[02]" + ], + "HRS-06": [ + "A.03.01.18.a[01]", + "A.03.12.05.a[01]", + "A.03.15.03.c" + ], + "HRS-06.1": [ + "A.03.12.05.a[01]", "A.03.15.03.c" ], + "HRS-07": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], + "HRS-07.1": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], "HRS-08": [ + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", + "A.03.09.02.a.01", "A.03.09.02.b.01[01]", "A.03.09.02.b.01[02]", "A.03.09.02.b.02" ], "HRS-09": [ + "A.03.01.01.f.03", + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", "A.03.09.02.a.01", "A.03.09.02.a.02[01]", "A.03.09.02.a.02[02]", - "A.03.09.02.a.03" + "A.03.09.02.a.03", + "A.03.09.02.b.01[01]" ], "HRS-09.1": [ "A.03.09.02.a.03" ], + "HRS-09.2": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]", + "A.03.09.02.b.01[01]" + ], + "HRS-09.4": [ + "A.03.01.01.g.02", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], + "HRS-10": [ + "A.03.16.03.b" + ], "HRS-11": [ "A.03.01.04.a" ], + "HRS-12": [ + "A.03.01.04.a" + ], + "IAC-01": [ + "A.03.01.01.a[01]", + "A.03.01.01.a[02]", + "A.03.01.18.b", + "A.03.05.01.a[01]", + "A.03.05.05.a", + "A.03.05.12.e" + ], "IAC-01.2": [ "A.03.01.01.d.01", - "A.03.01.01.d.02", "A.03.01.16.b", "A.03.05.01.a[01]", - "A.03.05.01.a[02]" + "A.03.05.01.a[02]", + "A.03.05.02[01]", + "A.03.05.02[02]", + "A.03.05.05.d", + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.12.d", + "A.03.07.05.a[01]" ], "IAC-02": [ "A.03.05.01.a[03]", @@ -53741,16 +54362,37 @@ "A.03.05.04[02]", "A.03.07.05.b[02]" ], + "IAC-03": [ + "A.03.05.01.a[03]" + ], "IAC-04": [ + "A.03.01.18.b", "A.03.05.02.ODP[01]", "A.03.05.02[01]", "A.03.05.02[02]" ], + "IAC-05": [ + "A.03.05.01.a[03]", + "A.03.05.02[01]", + "A.03.05.02[02]" + ], + "IAC-05.2": [ + "A.03.07.05.a[01]" + ], "IAC-06": [ "A.03.05.03[01]", "A.03.05.03[02]", "A.03.07.05.b[01]" ], + "IAC-06.1": [ + "A.03.05.03[01]" + ], + "IAC-06.2": [ + "A.03.05.03[02]" + ], + "IAC-06.3": [ + "A.03.05.03[01]" + ], "IAC-06.4": [ "A.03.05.03[01]", "A.03.05.03[02]" @@ -53761,29 +54403,70 @@ "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.05.05.a" + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], + "IAC-07.1": [ + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" + ], + "IAC-07.2": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" ], "IAC-08": [ + "A.03.01.01.c.01", "A.03.01.01.c.02", "A.03.01.01.c.03", + "A.03.01.02[01]", + "A.03.01.02[02]", "A.03.01.05.ODP[01]", "A.03.01.05.ODP[02]", "A.03.01.05.b[01]", "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.12.a[02]", + "A.03.03.08.b", "A.03.04.05[04]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.07.06.a" ], "IAC-09": [ "A.03.05.05.ODP[01]", "A.03.05.05.b[01]", "A.03.05.05.b[02]", - "A.03.05.05.c" + "A.03.05.05.c", + "A.03.05.05.d" + ], + "IAC-09.1": [ + "A.03.05.05.b[01]", + "A.03.05.05.b[02]" ], "IAC-09.2": [ "A.03.05.05.ODP[02]", "A.03.05.05.d" ], + "IAC-09.5": [ + "A.03.01.07.b", + "A.03.05.05.d" + ], "IAC-10": [ + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", "A.03.05.12.ODP[01]", "A.03.05.12.ODP[02]", "A.03.05.12.a", @@ -53801,7 +54484,14 @@ ], "IAC-10.1": [ "A.03.05.07.ODP[02]", - "A.03.05.07.f" + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.b", + "A.03.05.12.d", + "A.03.05.12.e" + ], + "IAC-10.3": [ + "A.03.05.12.a" ], "IAC-10.4": [ "A.03.05.07.ODP[01]", @@ -53816,12 +54506,22 @@ "A.03.05.12.f[01]", "A.03.05.12.f[02]" ], + "IAC-10.6": [ + "A.03.05.07.d" + ], + "IAC-10.8": [ + "A.03.05.07.e", + "A.03.05.12.d" + ], "IAC-10.11": [ "A.03.05.07.ODP[01]", "A.03.05.07.a[01]", "A.03.05.07.a[02]", "A.03.05.07.a[03]", - "A.03.05.07.b" + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.f" ], "IAC-11": [ "A.03.05.11" @@ -53834,7 +54534,13 @@ "A.03.01.01.ODP[01]", "A.03.01.01.a[01]", "A.03.01.01.a[02]", + "A.03.01.01.b[01]", + "A.03.01.01.b[02]", + "A.03.01.01.b[03]", "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", "A.03.01.01.e", "A.03.01.01.f.01", "A.03.01.01.f.02", @@ -53844,41 +54550,117 @@ "A.03.01.01.g.01", "A.03.01.01.g.02", "A.03.01.01.g.03", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.05.c", + "A.03.01.05.d", "A.03.05.07.e" ], + "IAC-15.1": [ + "A.03.01.01.d.01", + "A.03.05.05.b[01]", + "A.03.05.05.b[02]", + "A.03.05.05.c", + "A.03.05.05.d", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.d", + "A.03.05.12.e", + "A.03.05.12.f[01]", + "A.03.05.12.f[02]" + ], "IAC-15.3": [ "A.03.01.01.f.02" ], + "IAC-15.5": [ + "A.03.01.01.c.01" + ], + "IAC-15.6": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], "IAC-15.7": [ - "A.03.01.01.a[01]", - "A.03.01.01.a[02]", - "A.03.01.01.b[01]", - "A.03.01.01.b[02]", - "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.01.01.c.01" + "A.03.01.01.e", + "A.03.01.05.c" + ], + "IAC-16": [ + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.01.07.b" ], "IAC-17": [ + "A.03.01.01.g.03", "A.03.01.05.ODP[03]", "A.03.01.05.c", - "A.03.01.05.d" + "A.03.01.05.d", + "A.03.10.01.c", + "A.03.10.01.d" + ], + "IAC-20": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" ], "IAC-20.1": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", "A.03.01.05.b[01]", "A.03.01.05.b[02]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]" ], "IAC-21": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", "A.03.01.02[02]", - "A.03.01.05.a" + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.03.08.a[02]", + "A.03.03.08.b", + "A.03.04.05[04]" ], "IAC-21.2": [ "A.03.01.06.b" ], "IAC-21.3": [ "A.03.01.06.ODP[01]", - "A.03.01.06.a" + "A.03.01.06.a", + "A.03.01.07.a" + ], + "IAC-21.4": [ + "A.03.01.07.b" ], "IAC-21.5": [ "A.03.01.07.a" @@ -53908,18 +54690,32 @@ "A.03.01.11", "A.03.07.05.c[01]" ], + "IAC-28": [ + "A.03.05.12.a" + ], + "IAC-28.1": [ + "A.03.01.01.b[02]", + "A.03.05.05.a" + ], "IRO-01": [ "A.03.06.01[01]" ], "IRO-02": [ + "A.03.03.04.b", "A.03.06.01[02]", "A.03.06.01[03]", "A.03.06.01[04]", "A.03.06.01[05]", "A.03.06.01[06]", - "A.03.06.02.b" + "A.03.06.02.a[01]", + "A.03.06.02.a[02]", + "A.03.06.02.b", + "A.03.06.02.c", + "A.03.06.02.d", + "A.03.06.05.b[01]" ], "IRO-04": [ + "A.03.06.01[01]", "A.03.06.02.ODP[01]", "A.03.06.02.ODP[02]", "A.03.06.05.a.01", @@ -53935,16 +54731,12 @@ "IRO-04.2": [ "A.03.06.05.c" ], + "IRO-04.3": [ + "A.03.06.04.b[03]" + ], "IRO-05": [ - "A.03.06.04.ODP[01]", - "A.03.06.04.ODP[02]", - "A.03.06.04.ODP[03]", - "A.03.06.04.ODP[04]", "A.03.06.04.a.01", - "A.03.06.04.b[01]", - "A.03.06.04.b[02]", - "A.03.06.04.b[03]", - "A.03.06.04.b[04]" + "A.03.06.04.a.03" ], "IRO-06": [ "A.03.06.03.ODP[01]", @@ -53956,7 +54748,8 @@ ], "IRO-09": [ "A.03.06.02.a[01]", - "A.03.06.02.a[02]" + "A.03.06.02.a[02]", + "A.03.06.02.b" ], "IRO-10": [ "A.03.06.02.ODP[01]", @@ -53965,21 +54758,34 @@ "A.03.06.02.d" ], "IRO-10.2": [ - "A.03.06.02.ODP[02]" + "A.03.06.02.ODP[02]", + "A.03.06.02.b" ], "IRO-11": [ "A.03.06.02.d" ], "IRO-12": [ - "A.03.01.22.b[02]" + "A.03.01.22.b[02]", + "A.03.06.01[01]" ], "IRO-13": [ - "A.03.06.04.ODP[04]" + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" ], "IRO-14": [ "A.03.06.02.ODP[02]" ], + "IAO-01": [ + "A.03.12.01" + ], + "IAO-01.1": [ + "A.03.12.01" + ], + "IAO-02": [ + "A.03.12.01" + ], "IAO-03": [ + "A.03.01.16.a[01]", "A.03.04.11.a[02]", "A.03.04.11.a[03]", "A.03.04.11.b[01]", @@ -53994,24 +54800,43 @@ "A.03.15.02.a.07", "A.03.15.02.a.08", "A.03.15.02.b[01]", - "A.03.15.02.b[02]", - "A.03.15.02.c" + "A.03.15.02.b[02]" ], "IAO-05": [ + "A.03.04.11.b[01]", + "A.03.04.11.b[02]", "A.03.12.02.a.01", "A.03.12.02.a.02", "A.03.12.02.b.01", "A.03.12.02.b.02", - "A.03.12.02.b.03" + "A.03.12.02.b.03", + "A.03.14.01.a[01]" + ], + "MNT-01": [ + "A.03.04.03.c[01]", + "A.03.07.04.a[01]", + "A.03.07.04.a[02]", + "A.03.07.06.a" ], "MNT-02": [ - "A.03.04.03.c[01]" + "A.03.04.03.c[01]", + "A.03.07.04.a[02]", + "A.03.07.05.a[01]" + ], + "MNT-03": [ + "A.03.07.04.a[02]" + ], + "MNT-03.1": [ + "A.03.07.04.a[02]" ], "MNT-04": [ "A.03.07.04.a[01]", "A.03.07.04.a[02]", "A.03.07.04.a[03]" ], + "MNT-04.1": [ + "A.03.07.04.b" + ], "MNT-04.2": [ "A.03.07.04.b" ], @@ -54019,37 +54844,75 @@ "A.03.07.04.c" ], "MNT-05": [ + "A.03.01.12.d[1]", "A.03.07.05.a[01]", + "A.03.07.05.a[02]", + "A.03.07.05.b[01]", + "A.03.07.05.c[01]" + ], + "MNT-05.1": [ "A.03.07.05.a[02]" ], "MNT-05.3": [ - "A.03.07.05.b[02]" + "A.03.07.05.b[01]" ], "MNT-05.4": [ "A.03.07.05.c[01]" ], + "MNT-05.5": [ + "A.03.07.05.a[01]" + ], "MNT-06": [ "A.03.07.06.a", "A.03.07.06.b", "A.03.07.06.c", - "A.03.07.06.d[01]", - "A.03.07.06.d[02]" + "A.03.07.06.d[01]" ], "MNT-06.1": [ - "A.03.07.06.c" + "A.03.07.06.c", + "A.03.07.06.d[01]", + "A.03.07.06.d[02]" ], "MNT-06.2": [ "A.03.07.06.c" ], + "MNT-09": [ + "A.03.07.04.a[02]" + ], "MDM-01": [ - "A.03.01.18.a[01]" + "A.03.01.18.a[01]", + "A.03.01.20.d" ], "MDM-02": [ + "A.03.01.18.a[02]", "A.03.01.18.b" ], "MDM-03": [ "A.03.01.18.c" ], + "MDM-04": [ + "A.03.04.12.b" + ], + "MDM-06": [ + "A.03.01.18.a[01]", + "A.03.01.18.b" + ], + "MDM-07": [ + "A.03.01.18.a[01]", + "A.03.01.18.b", + "A.03.01.20.d" + ], + "MDM-11": [ + "A.03.01.18.b" + ], + "NET-01": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[03]", + "A.03.13.01.a[02]" + ], + "NET-02": [ + "A.03.13.01.b" + ], "NET-02.2": [ "A.03.01.16.a[01]", "A.03.01.16.a[02]", @@ -54060,17 +54923,25 @@ "A.03.01.18.a[03]", "A.03.13.01.a[02]", "A.03.13.01.a[04]", + "A.03.13.01.b", "A.03.13.01.c" ], + "NET-03.8": [ + "A.03.13.01.b" + ], "NET-04": [ - "A.03.01.03[02]" + "A.03.01.03[02]", + "A.03.13.01.a[02]", + "A.03.13.01.c" ], "NET-04.1": [ + "A.03.13.01.a[02]", "A.03.13.06[01]", "A.03.13.06[02]" ], "NET-05": [ "A.03.01.03[02]", + "A.03.01.20.c.02", "A.03.12.05.ODP[01]", "A.03.12.05.ODP[02]", "A.03.12.05.a[01]", @@ -54081,33 +54952,54 @@ "A.03.12.05.c[01]", "A.03.12.05.c[02]" ], + "NET-05.2": [ + "A.03.01.03[02]" + ], "NET-06": [ "A.03.13.01.b" ], + "NET-06.3": [ + "A.03.13.01.b" + ], "NET-07": [ "A.03.07.05.c[02]", "A.03.13.09.ODP[01]", "A.03.13.09" ], + "NET-08": [ + "A.03.13.01.a[02]", + "A.03.14.06.c[01]" + ], + "NET-08.1": [ + "A.03.13.01.b" + ], "NET-09": [ "A.03.13.15" ], "NET-14": [ "A.03.01.12.a[01]", "A.03.01.12.a[02]", - "A.03.01.12.a[03]", "A.03.01.12.a[04]", "A.03.01.12.b", "A.03.01.12.c[01]", - "A.03.01.12.c[02]", - "A.03.01.12.d[1]", - "A.03.01.12.d[2]" + "A.03.01.12.c[02]" + ], + "NET-14.1": [ + "A.03.01.12.b" + ], + "NET-14.2": [ + "A.03.01.12.a[04]" + ], + "NET-14.3": [ + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" ], "NET-14.4": [ "A.03.01.12.d[1]", "A.03.01.12.d[2]" ], "NET-14.5": [ + "A.03.01.12.a[01]", "A.03.10.06.ODP[01]", "A.03.10.06.a", "A.03.10.06.b" @@ -54115,35 +55007,94 @@ "NET-15": [ "A.03.01.16.a[01]", "A.03.01.16.a[02]", - "A.03.01.16.a[04]" + "A.03.01.16.a[04]", + "A.03.01.16.b" ], "NET-15.1": [ + "A.03.01.16.a[04]", + "A.03.01.16.b", "A.03.01.16.d[01]", "A.03.01.16.d[02]" ], + "NET-15.2": [ + "A.03.01.16.c" + ], + "NET-15.3": [ + "A.03.01.16.a[03]", + "A.03.01.16.c" + ], + "NET-18": [ + "A.03.14.06.c[02]" + ], + "PES-01": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", + "A.03.10.07.a.01" + ], "PES-02": [ "A.03.04.05[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", "A.03.10.01.a[01]", "A.03.10.01.a[02]", "A.03.10.01.a[03]", + "A.03.10.01.b", "A.03.10.01.c", "A.03.10.01.d", "A.03.10.07.a.01" ], "PES-02.1": [ "A.03.04.05[01]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", - "A.03.10.01.b" + "A.03.10.01.b", + "A.03.10.01.d" ], "PES-03": [ "A.03.04.05[03]", + "A.03.10.02.a[01]", + "A.03.10.07.a.01", "A.03.10.07.a.02", "A.03.10.07.d" ], + "PES-03.1": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], "PES-03.3": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.02", "A.03.10.07.b" ], + "PES-03.4": [ + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], + "PES-04": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" + ], + "PES-04.1": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" + ], "PES-05": [ "A.03.10.02.ODP[01]", "A.03.10.02.ODP[02]", @@ -54152,11 +55103,25 @@ "A.03.10.02.b[01]", "A.03.10.02.b[02]" ], + "PES-05.1": [ + "A.03.10.02.a[01]" + ], + "PES-05.2": [ + "A.03.10.02.a[01]", + "A.03.10.02.b[01]", + "A.03.10.02.b[02]" + ], "PES-06": [ + "A.03.10.01.a[02]", "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], "PES-06.1": [ + "A.03.10.01.a[02]", + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], + "PES-06.2": [ "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], @@ -54164,23 +55129,49 @@ "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], + "PES-06.6": [ + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], + "PES-07": [ + "A.03.10.08" + ], "PES-11": [ "A.03.10.06.ODP[01]", "A.03.10.06.a", "A.03.10.06.b" ], + "PES-12": [ + "A.03.10.07.e", + "A.03.10.08" + ], "PES-12.1": [ "A.03.10.08" ], "PES-12.2": [ "A.03.10.07.e" ], + "PRM-01": [ + "A.03.16.01" + ], + "PRM-05": [ + "A.03.16.01" + ], "RSK-01": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", "A.03.17.03.b" ], "RSK-01.1": [ "A.03.11.01.a" ], + "RSK-02": [ + "A.03.11.01.a" + ], + "RSK-02.1": [ + "A.03.11.01.a", + "A.03.14.03.a" + ], "RSK-03": [ "A.03.11.01.a" ], @@ -54188,14 +55179,28 @@ "A.03.11.01.a" ], "RSK-04": [ - "A.03.11.01.a", - "A.03.11.01.b" + "A.03.11.01.a" + ], + "RSK-04.1": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" + ], + "RSK-05": [ + "A.03.11.01.a" + ], + "RSK-06": [ + "A.03.11.02.b", + "A.03.12.02.a.02" ], "RSK-06.1": [ + "A.03.11.02.b", "A.03.11.04[01]", "A.03.11.04[02]", "A.03.11.04[03]" ], + "RSK-06.2": [ + "A.03.11.02.b" + ], "RSK-07": [ "A.03.11.01.ODP[01]", "A.03.11.01.b" @@ -54215,19 +55220,42 @@ "A.03.17.01.a[10]", "A.03.17.01.b[01]", "A.03.17.01.b[02]", - "A.03.17.01.c", "A.03.17.03.ODP[01]", "A.03.17.03.a[01]", "A.03.17.03.a[02]", "A.03.17.03.b" ], + "RSK-09.1": [ + "A.03.11.01.a", + "A.03.11.01.b", + "A.03.17.03.a[01]" + ], "SEA-01": [ - "A.03.16.01.ODP[01]" + "A.03.01.12.a[04]", + "A.03.01.16.a[02]", + "A.03.01.16.c", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01.ODP[01]", + "A.03.16.01" + ], + "SEA-02": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01" ], "SEA-05": [ "A.03.13.04[01]", "A.03.13.04[02]" ], + "SEA-07": [ + "A.03.16.02.b" + ], + "SEA-07.1": [ + "A.03.16.02.a", + "A.03.16.02.b" + ], "SEA-18": [ "A.03.01.09" ], @@ -54237,27 +55265,52 @@ "SEA-18.2": [ "A.03.01.09" ], + "OPS-01": [ + "A.03.15.01.a[03]" + ], "OPS-01.1": [ "A.03.15.01.a[03]", - "A.03.15.01.a[04]", - "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.a[04]" + ], + "OPS-03": [ + "A.03.15.01.a[04]" ], "SAT-01": [ "A.03.02.01.ODP[01]", "A.03.02.01.ODP[02]", - "A.03.02.01.a.01[01]", - "A.03.02.01.a.01[02]" + "A.03.02.01.a.01[01]" + ], + "SAT-01.1": [ + "A.03.02.01.b[01]", + "A.03.02.01.b[02]", + "A.03.02.02.b[01]", + "A.03.02.02.b[02]", + "A.03.06.04.ODP[03]", + "A.03.06.04.ODP[04]", + "A.03.06.04.b[01]", + "A.03.06.04.b[02]", + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" ], "SAT-02": [ + "A.03.01.22.a", "A.03.02.01.ODP[03]", "A.03.02.01.ODP[04]", + "A.03.02.01.a.01[01]", "A.03.02.01.a.03[03]", "A.03.02.01.a.03[04]", + "A.03.06.04.a.03" + ], + "SAT-02.2": [ + "A.03.02.01.a.03[03]", "A.03.02.01.a.03[05]", "A.03.02.01.a.03[06]" ], "SAT-03": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.01.a.01[02]", + "A.03.02.01.a.02", "A.03.02.02.ODP[01]", "A.03.02.02.ODP[02]", "A.03.02.02.ODP[03]", @@ -54266,27 +55319,70 @@ "A.03.02.02.a.01[02]", "A.03.02.02.a.01[03]", "A.03.02.02.a.02", - "A.03.02.02.b[01]", - "A.03.02.02.b[02]", + "A.03.06.04.ODP[01]", + "A.03.06.04.ODP[02]", "A.03.06.04.a.01", "A.03.06.04.a.02", "A.03.06.04.a.03" ], + "SAT-03.3": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], + "SAT-03.5": [ + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], "SAT-03.6": [ + "A.03.02.01.a.01[01]", "A.03.02.01.a.02", - "A.03.02.01.b[01]", - "A.03.02.01.b[02]" + "A.03.02.01.b[02]", + "A.03.02.02.a.01[01]", + "A.03.02.02.a.02", + "A.03.06.04.a.02" ], "TDA-01": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", "A.03.16.01.ODP[01]", + "A.03.16.01", "A.03.17.02[04]", "A.03.17.02[05]", "A.03.17.02[06]" ], + "TDA-01.1": [ + "A.03.12.03[01]" + ], + "TDA-02": [ + "A.03.16.01" + ], "TDA-02.3": [ "A.03.16.01.ODP[01]", "A.03.16.01" ], + "TDA-02.4": [ + "A.03.16.01" + ], + "TDA-03": [ + "A.03.16.01" + ], + "TDA-05": [ + "A.03.16.01" + ], + "TDA-06": [ + "A.03.16.01" + ], + "TDA-09": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], + "TDA-09.1": [ + "A.03.12.03[01]" + ], "TDA-17": [ "A.03.16.02.a" ], @@ -54294,42 +55390,146 @@ "A.03.16.02.b" ], "TPM-01": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.07.06.a", + "A.03.16.01", + "A.03.16.03.a", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.02[06]", "A.03.17.03.ODP[01]" ], + "TPM-01.1": [ + "A.03.07.06.b" + ], + "TPM-02": [ + "A.03.11.01.a", + "A.03.17.03.a[01]" + ], + "TPM-03": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "TPM-03.1": [ + "A.03.17.01.a[01]", "A.03.17.02[01]", "A.03.17.02[02]", - "A.03.17.02[03]" + "A.03.17.02[03]", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], + "TPM-03.2": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], + "TPM-03.3": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], + "TPM-04": [ + "A.03.16.03.a", + "A.03.16.03.c", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], "TPM-04.1": [ - "A.03.17.03.a[01]" + "A.03.11.01.a", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], + "TPM-04.4": [ + "A.03.16.03.a" ], "TPM-05": [ + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.07.06.a", "A.03.16.03.ODP[01]", - "A.03.16.03.a" + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" + ], + "TPM-05.1": [ + "A.03.17.02[05]" ], "TPM-05.2": [ - "A.03.16.03.ODP[01]" + "A.03.16.03.ODP[01]", + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" ], "TPM-05.4": [ + "A.03.07.06.b", "A.03.16.03.b" ], "TPM-05.5": [ - "A.03.16.03.c" + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[02]", + "A.03.17.03.b" ], "TPM-05.6": [ + "A.03.01.20.c.01", "A.03.16.03.c" ], + "TPM-05.7": [ + "A.03.17.01.a[01]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.b" + ], "TPM-05.8": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.16.03.a", "A.03.16.03.c" ], "TPM-08": [ - "A.03.16.03.c" + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]" + ], + "TPM-09": [ + "A.03.17.02[06]" + ], + "TPM-10": [ + "A.03.16.01", + "A.03.17.02[06]" + ], + "THR-01": [ + "A.03.11.02.a[01]", + "A.03.14.01.a[01]", + "A.03.14.03.a" ], "THR-03": [ + "A.03.02.01.a.02", + "A.03.02.01.b[02]", + "A.03.11.02.a[01]", "A.03.14.03.a" ], "THR-03.1": [ + "A.03.14.03.a", "A.03.14.03.b[01]", "A.03.14.03.b[02]" ], @@ -54337,24 +55537,39 @@ "A.03.02.01.a.03[01]", "A.03.02.01.a.03[02]" ], + "THR-06": [ + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], + "THR-10": [ + "A.03.14.03.a" + ], "VPM-01": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" ], "VPM-01.1": [ - "A.03.11.02.a[01]" + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" ], "VPM-02": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.b", + "A.03.12.02.a.02" + ], + "VPM-03": [ + "A.03.11.02.a[01]" ], "VPM-04": [ - "A.03.11.02.b" + "A.03.11.02.b", + "A.03.14.01.a[03]" ], "VPM-05": [ "A.03.11.02.b", + "A.03.12.02.a.02", "A.03.14.01.ODP[01]", "A.03.14.01.ODP[02]", - "A.03.14.01.a[01]", - "A.03.14.01.a[02]", "A.03.14.01.a[03]", "A.03.14.01.b[01]", "A.03.14.01.b[02]" @@ -54367,247 +55582,1324 @@ "A.03.11.02.a[02]", "A.03.11.02.a[03]", "A.03.11.02.a[04]", - "A.03.11.02.c[01]", - "A.03.11.02.c[02]" + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" ], "VPM-06.1": [ "A.03.11.02.ODP[04]", "A.03.11.02.c[01]", "A.03.11.02.c[02]" + ], + "WEB-01": [ + "A.03.01.22.a" + ], + "WEB-14": [ + "A.03.01.22.b[02]" ] }, - "general-nist-800-172": { - "AST-02": [ - "3.1.2e" + "general-nist-800-172-r3": { + "GOV-02": [ + "03.01.17E", + "03.05.07E", + "03.17.03E" ], - "AST-02.5": [ - "3.5.3e" + "AST-02.2": [ + "03.04.02E" ], "AST-02.8": [ - "3.1.3e" + "03.01.14E" ], "AST-02.9": [ - "3.4.1e", - "3.4.3e" + "03.04.03E", + "03.04.08E" + ], + "AST-03.2": [ + "03.17.04E" ], "AST-04": [ - "3.1.3e" + "03.01.14E" ], "AST-04.1": [ - "3.14.3e" + "03.06.03E" ], - "AST-18": [ - "3.14.1e" + "AST-08": [ + "03.17.02E", + "03.17.05E" ], - "BCD-02.4": [ - "3.14.5e" + "AST-15": [ + "03.17.05E" ], - "CHG-01": [ - "3.13.2e" + "AST-15.1": [ + "03.17.02E" ], - "CPL-01.2": [ - "3.11.5e", - "3.14.3e" + "BCD-01": [ + "03.04.04E", + "03.08.04E" ], - "CPL-03": [ - "3.11.5e" + "BCD-01.4": [ + "03.08.04E" + ], + "BCD-02": [ + "03.11.10E" + ], + "BCD-11.1": [ + "03.08.03E" + ], + "BCD-11.8": [ + "03.08.02E" + ], + "BCD-12": [ + "03.08.04E" + ], + "CAP-01": [ + "03.13.12E" + ], + "CAP-02": [ + "03.13.12E" + ], + "CAP-03": [ + "03.13.12E" + ], + "CHG-02.2": [ + "03.04.07E" + ], + "CHG-04.3": [ + "03.04.05E" + ], + "CHG-06": [ + "03.04.07E" + ], + "CPL-02": [ + "03.12.03E" + ], + "CFG-02": [ + "03.01.04E", + "03.01.14E", + "03.01.16E", + "03.05.01E", + "03.05.05E", + "03.12.04E", + "03.13.06E", + "03.13.11E", + "03.13.13E", + "03.14.11E" ], "CFG-02.2": [ - "3.4.2e" + "03.04.02E", + "03.04.04E" ], - "CFG-02.7": [ - "3.5.2e" + "CFG-02.3": [ + "03.04.06E" ], "CFG-02.8": [ - "3.4.2e" + "03.04.02E" ], - "CFG-06": [ - "3.4.2e" + "CFG-03.3": [ + "03.13.06E" + ], + "CFG-05.1": [ + "03.04.02E" ], "CFG-06.1": [ - "3.4.2e", - "3.14.7e" + "03.14.11E" ], - "MON-01": [ - "3.14.2e" + "MON-01.4": [ + "03.14.17E" ], - "MON-01.1": [ - "3.14.6e" + "MON-01.5": [ + "03.14.19E" + ], + "MON-01.7": [ + "03.14.01E" + ], + "MON-01.8": [ + "03.01.08E", + "03.11.09E", + "03.14.01E" + ], + "MON-01.12": [ + "03.14.17E", + "03.14.18E" + ], + "MON-02.3": [ + "03.03.04E" + ], + "MON-05": [ + "03.03.02E" + ], + "MON-05.1": [ + "03.03.02E" + ], + "MON-08.1": [ + "03.03.01E" + ], + "MON-08.4": [ + "03.03.03E" ], "MON-11.3": [ - "3.11.2e" + "03.01.08E", + "03.11.02E", + "03.11.09E", + "03.14.17E", + "03.14.18E" ], "MON-16": [ - "3.14.2e" + "03.01.08E", + "03.06.03E" ], - "CRY-13": [ - "3.14.1e" + "CRY-01": [ + "03.14.09E" + ], + "DCH-01": [ + "03.01.17E" ], "DCH-01.2": [ - "3.14.5e" + "03.01.17E" ], - "DCH-06.2": [ - "3.1.2e" + "DCH-01.4": [ + "03.01.17E" ], - "HRS-02": [ - "3.9.1e" + "DCH-02": [ + "03.01.17E" ], - "HRS-02.1": [ - "3.9.2e" + "DCH-09": [ + "03.08.01E" ], - "HRS-03": [ - "3.9.1e" + "DCH-09.5": [ + "03.08.01E", + "03.08.02E" ], - "HRS-04": [ - "3.9.1e" + "DCH-13.4": [ + "03.01.02E" ], - "HRS-04.1": [ - "3.9.1e" + "DCH-18": [ + "03.04.06E", + "03.10.01E" ], - "HRS-07": [ - "3.9.2e" + "END-03.1": [ + "03.04.02E" ], - "HRS-07.1": [ - "3.9.2e" + "END-06": [ + "03.14.01E" ], - "HRS-07.3": [ - "3.9.2e" + "END-06.1": [ + "03.14.08E" ], - "IAC-01.2": [ - "3.5.2e" + "END-06.2": [ + "03.14.11E" ], - "IAC-02.2": [ - "3.5.1e" + "END-06.6": [ + "03.14.10E" + ], + "END-06.8": [ + "03.14.11E" + ], + "END-10": [ + "03.13.06E" + ], + "END-11": [ + "03.13.11E" + ], + "END-12": [ + "03.13.13E" + ], + "HRS-01": [ + "03.09.03E", + "03.09.04E" + ], + "HRS-03": [ + "03.01.08E", + "03.01.11E", + "03.14.17E", + "03.14.18E", + "03.17.03E" + ], + "HRS-04.3": [ + "03.09.04E" + ], + "HRS-06": [ + "03.09.03E" + ], + "HRS-12.1": [ + "03.01.01E" + ], + "IAC-01": [ + "03.05.07E" + ], + "IAC-01.4": [ + "03.05.07E" ], "IAC-04": [ - "3.5.1e" + "03.05.01E", + "03.05.03E" + ], + "IAC-04.1": [ + "03.05.03E" ], "IAC-08": [ - "3.1.2e" + "03.01.11E" + ], + "IAC-10.1": [ + "03.05.02E" + ], + "IAC-10.4": [ + "03.05.02E" + ], + "IAC-10.5": [ + "03.05.02E" + ], + "IAC-10.6": [ + "03.05.04E" + ], + "IAC-10.10": [ + "03.05.05E" ], "IAC-10.11": [ - "3.5.2e" + "03.05.02E" + ], + "IAC-15.1": [ + "03.01.07E", + "03.01.11E" + ], + "IAC-15.4": [ + "03.01.07E" ], "IAC-20.5": [ - "3.1.1e" + "03.01.01E" + ], + "IAC-23": [ + "03.01.04E" + ], + "IAC-28": [ + "03.05.06E" + ], + "IAC-29": [ + "03.01.09E" + ], + "IRO-01": [ + "03.11.09E" + ], + "IRO-02": [ + "03.17.03E" + ], + "IRO-03": [ + "03.01.08E", + "03.02.01E", + "03.11.02E", + "03.11.09E", + "03.14.17E" ], "IRO-07": [ - "3.6.2e" + "03.06.02E" + ], + "IRO-09.1": [ + "03.06.04E" + ], + "IRO-15": [ + "03.13.14E" + ], + "IAO-02.1": [ + "03.12.02E" ], "IAO-03": [ - "3.11.4e" + "03.01.04E", + "03.01.06E", + "03.13.11E", + "03.13.14E", + "03.13.16E", + "03.14.08E", + "03.14.10E", + "03.14.14E", + "03.14.15E", + "03.14.16E", + "03.15.01E", + "03.15.02E", + "03.15.03E", + "03.16.01E", + "03.17.02E" ], - "NET-02": [ - "3.13.4e" + "MNT-04": [ + "03.07.01E" ], - "NET-02.3": [ - "3.1.3e" + "NET-02.1": [ + "03.13.12E" + ], + "NET-03": [ + "03.01.12E", + "03.13.04E" ], "NET-03.7": [ - "3.13.4e" + "03.13.04E" ], - "NET-04": [ - "3.1.3e" + "NET-03.8": [ + "03.13.10E", + "03.13.15E" + ], + "NET-04.2": [ + "03.01.10E" + ], + "NET-04.5": [ + "03.01.13E" + ], + "NET-04.7": [ + "03.01.10E", + "03.01.13E", + "03.01.14E" + ], + "NET-04.8": [ + "03.01.13E", + "03.01.14E", + "03.01.15E" + ], + "NET-04.9": [ + "03.01.16E" + ], + "NET-04.10": [ + "03.01.17E" + ], + "NET-05": [ + "03.12.04E" + ], + "NET-05.2": [ + "03.12.04E" ], "NET-06": [ - "3.14.3e" + "03.01.12E" ], - "NET-06.4": [ - "3.14.3e" + "NET-06.1": [ + "03.13.09E", + "03.13.15E" ], - "PES-03": [ - "3.1.2e" + "NET-06.9": [ + "03.13.09E", + "03.13.15E" ], - "PES-04.1": [ - "3.13.4e" + "NET-14": [ + "03.01.06E" ], - "PES-12": [ - "3.13.4e" + "NET-14.1": [ + "03.01.05E" ], - "PES-18": [ - "3.13.4e" + "NET-17": [ + "03.01.17E" ], - "RSK-03.1": [ - "3.11.5e" + "PES-05": [ + "03.10.01E", + "03.10.02E" ], - "RSK-04": [ - "3.11.1e", - "3.11.5e" + "PES-05.1": [ + "03.10.01E" ], - "RSK-04.2": [ - "3.11.1e" + "PES-05.2": [ + "03.10.01E" ], - "RSK-06": [ - "3.11.7e" + "PES-06": [ + "03.10.01E" ], - "RSK-06.1": [ - "3.11.6e" + "PES-10": [ + "03.10.02E" ], - "RSK-09": [ - "3.11.6e", - "3.11.7e" + "PRM-04": [ + "03.11.10E" ], - "RSK-09.1": [ - "3.11.6e" + "PRM-05": [ + "03.11.10E", + "03.13.01E", + "03.13.02E", + "03.13.03E" + ], + "PRM-06": [ + "03.13.01E" + ], + "RSK-11": [ + "03.12.03E" + ], + "SEA-01.4": [ + "03.15.01E" + ], + "SEA-01.5": [ + "03.15.01E" + ], + "SEA-02": [ + "03.15.01E" + ], + "SEA-03": [ + "03.15.02E" + ], + "SEA-03.1": [ + "03.13.16E" + ], + "SEA-08": [ + "03.14.15E" ], "SEA-08.1": [ - "3.14.4e" + "03.14.04E" + ], + "SEA-08.2": [ + "03.14.05E" + ], + "SEA-10": [ + "03.14.14E" + ], + "SEA-11": [ + "03.13.08E" ], "SEA-13": [ - "3.13.1e" + "03.13.01E" + ], + "SEA-13.1": [ + "03.13.07E" ], "SEA-14": [ - "3.13.3e" + "03.13.03E" ], - "SEA-15": [ - "3.13.5e" + "SEA-14.1": [ + "03.13.02E" + ], + "SEA-14.2": [ + "03.13.05E" + ], + "OPS-01.1": [ + "03.02.01E", + "03.08.03E", + "03.09.03E", + "03.11.02E", + "03.12.01E", + "03.13.05E", + "03.13.07E", + "03.14.08E", + "03.14.15E", + "03.15.01E", + "03.17.02E" ], "OPS-04": [ - "3.6.1e" + "03.06.01E" ], - "OPS-06": [ - "3.11.3e" + "SAT-01.1": [ + "03.02.01E" ], - "SAT-02.2": [ - "3.2.1e" + "SAT-02.1": [ + "03.02.02E" ], "SAT-03": [ - "3.2.1e" + "03.02.01E", + "03.02.04E" ], - "SAT-03.1": [ - "3.2.2e" + "SAT-03.2": [ + "03.02.01E" + ], + "SAT-03.6": [ + "03.02.01E" + ], + "SAT-04.1": [ + "03.02.03E" + ], + "TDA-01": [ + "03.16.01E" + ], + "TDA-01.1": [ + "03.16.01E" + ], + "TDA-03.1": [ + "03.15.03E" + ], + "TDA-06.1": [ + "03.11.10E" + ], + "TDA-11": [ + "03.17.02E", + "03.17.03E", + "03.17.05E" + ], + "TDA-11.1": [ + "03.02.04E" + ], + "TDA-18": [ + "03.14.12E" + ], + "TDA-19": [ + "03.14.13E" + ], + "TPM-02": [ + "03.11.10E" + ], + "TPM-05": [ + "03.17.01E" + ], + "TPM-05.1": [ + "03.17.01E" + ], + "THR-01": [ + "03.11.01E" + ], + "THR-01.1": [ + "03.11.08E" + ], + "THR-01.2": [ + "03.11.03E" + ], + "THR-03": [ + "03.11.12E" + ], + "THR-07": [ + "03.11.02E" + ], + "THR-08": [ + "03.14.16E" + ], + "VPM-01.1": [ + "03.12.01E" + ], + "VPM-02": [ + "03.11.11E" + ], + "VPM-06.8": [ + "03.11.11E" + ], + "VPM-07": [ + "03.12.01E" + ] + }, + "general-nist-800-172a-r3": { + "GOV-02": [ + "A.03.01.17E.ODP[02]", + "A.03.05.07E.ODP[01]", + "DS-A.03.17.03E.a[01]", + "DS-A.03.17.03E.a[02]", + "DS-A.03.17.03E.a[03]", + "DS-A.03.17.03E.a[04]" + ], + "GOV-04.1": [ + "A.03.02.03E.ODP[01]" + ], + "AST-02.2": [ + "DS-A.03.04.02E.a", + "A.03.04.02E.ODP[01]" + ], + "AST-02.8": [ + "A.03.01.14E.ODP[02]" + ], + "AST-02.9": [ + "DS-A.03.04.03E[01]", + "A.03.04.03E.ODP[01]", + "DS-A.03.04.03E[02]", + "A.03.04.03E.ODP[02]", + "DS-A.03.04.03E[03]", + "A.03.04.03E.ODP[03]", + "DS-A.03.04.04E[01]", + "DS-A.03.04.04E[02]", + "DS-A.03.04.04E[03]", + "DS-A.03.04.08E" + ], + "AST-03.2": [ + "DS-A.03.17.04E[01]", + "A.03.17.04E.ODP[01]", + "DS-A.03.17.04E[02]", + "DS-A.03.17.04E[03]" + ], + "AST-04": [ + "A.03.01.14E.ODP[02]" + ], + "AST-04.1": [ + "A.03.06.03E.ODP[01]" + ], + "AST-08": [ + "A.03.17.02E.ODP[04]", + "A.03.17.05E.ODP[02]" + ], + "AST-15": [ + "A.03.17.05E.ODP[02]" + ], + "AST-15.1": [ + "DS-A.03.17.02E" + ], + "BCD-01": [ + "DS-A.03.04.03E[04]", + "A.03.04.03E.ODP[04]", + "DS-A.03.04.04E[04]", + "DS-A.03.08.04E[01]" + ], + "BCD-01.4": [ + "A.03.08.04E.ODP[01]", + "A.03.08.04E.ODP[02]" + ], + "BCD-02": [ + "DS-A.03.11.10E" + ], + "BCD-11.1": [ + "DS-A.03.08.03E[01]", + "DS-A.03.08.03E[02]" + ], + "BCD-11.8": [ + "DS-A.03.08.02E" + ], + "BCD-12": [ + "DS-A.03.08.04E[02]" + ], + "CAP-01": [ + "DS-A.03.13.12E.b" + ], + "CAP-02": [ + "DS-A.03.13.12E.b" + ], + "CAP-03": [ + "DS-A.03.13.12E.b" + ], + "CHG-02.2": [ + "DS-A.03.04.07E[01]", + "DS-A.03.04.07E[03]" + ], + "CHG-04.3": [ + "DS-A.03.04.05E[01]", + "A.03.04.05E.ODP[01]", + "DS-A.03.04.05E[02]", + "A.03.04.05E.ODP[02]" + ], + "CHG-06": [ + "DS-A.03.04.07E[02]" + ], + "CPL-02": [ + "DS-A.03.12.03E[02]", + "DS-A.03.12.03E[03]", + "DS-A.03.12.03E[04]" + ], + "CFG-02": [ + "A.03.01.04E.ODP[01]", + "A.03.01.14E.ODP[03]", + "A.03.01.14E.ODP[04]", + "DS-A.03.01.16E", + "A.03.05.01E.ODP[01]", + "DS-A.03.05.05E", + "DS-A.03.12.04E.c", + "A.03.13.06E.ODP[01]", + "DS-A.03.13.11E[02]", + "A.03.13.13E.ODP[01]", + "A.03.14.11E.ODP[01]" + ], + "CFG-02.2": [ + "A.03.04.02E.ODP[03]", + "DS-A.03.04.03E[01]", + "A.03.04.04E.ODP[01]" + ], + "CFG-02.3": [ + "DS-A.03.04.06E", + "A.03.04.06E.ODP[01]" + ], + "CFG-02.8": [ + "DS-A.03.04.02E.b", + "A.03.04.02E.ODP[02]" + ], + "CFG-03.3": [ + "A.03.13.06E.ODP[01]" + ], + "CFG-05.1": [ + "DS-A.03.04.02E.b" + ], + "CFG-06.1": [ + "DS-A.03.14.11E" + ], + "MON-01.4": [ + "DS-A.03.14.17E" + ], + "MON-01.5": [ + "DS-A.03.14.19E[01]", + "DS-A.03.14.19E[02]", + "DS-A.03.14.19E[03]" + ], + "MON-01.7": [ + "DS-A.03.14.01E.a[03]", + "A.03.14.01E.ODP[03]" + ], + "MON-01.8": [ + "DS-A.03.01.08E.b", + "DS-A.03.11.09E[03]", + "DS-A.03.14.01E.b[01]", + "A.03.14.01E.ODP[04]", + "DS-A.03.14.01E.b[02]", + "A.03.14.01E.ODP[05]", + "DS-A.03.14.01E.b[03]", + "A.03.14.01E.ODP[06]" + ], + "MON-01.12": [ + "DS-A.03.14.17E", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[02]" + ], + "MON-02.3": [ + "DS-A.03.03.04E", + "A.03.03.04E.ODP[01]", + "A.03.03.04E.ODP[02]" + ], + "MON-05": [ + "DS-A.03.03.02E", + "A.03.03.02E.ODP[03]", + "A.03.03.02E.ODP[02]" + ], + "MON-05.1": [ + "A.03.03.02E.ODP[01]" + ], + "MON-08.1": [ + "DS-A.03.03.01E" + ], + "MON-08.4": [ + "DS-A.03.03.03E", + "A.03.03.03E.ODP[01]", + "A.03.03.03E.ODP[02]" + ], + "MON-11.3": [ + "DS-A.03.01.08E.a", + "DS-A.03.11.02E.a.01[01]", + "DS-A.03.11.09E[01]", + "DS-A.03.11.09E[02]", + "DS-A.03.14.17E", + "A.03.14.18E.ODP[03]" + ], + "MON-16": [ + "DS-A.03.01.08E.a", + "DS-A.03.06.03E" + ], + "CRY-01": [ + "DS-A.03.14.09E[01]", + "DS-A.03.14.09E[02]", + "DS-A.03.14.09E[03]" + ], + "DCH-01": [ + "A.03.01.17E.ODP[02]" + ], + "DCH-01.2": [ + "A.03.01.17E.ODP[02]" + ], + "DCH-01.4": [ + "DS-A.03.01.17E.b", + "A.03.01.17E.ODP[02]" + ], + "DCH-02": [ + "A.03.01.17E.ODP[01]" + ], + "DCH-09": [ + "A.03.08.01E.ODP[01]" + ], + "DCH-09.5": [ + "DS-A.03.08.01E", + "A.03.08.02E.ODP[01]" + ], + "DCH-13.4": [ + "DS-A.03.01.02E", + "A.03.01.02E.ODP[01]" + ], + "DCH-18": [ + "DS-A.03.04.06E", + "A.03.10.01E.ODP[01]" + ], + "END-06": [ + "DS-A.03.14.01E.a[01]", + "A.03.14.01E.ODP[01]", + "DS-A.03.14.01E.a[02]", + "A.03.14.01E.ODP[02]" + ], + "END-06.1": [ + "DS-A.03.14.08E[01]", + "A.03.14.08E.ODP[02]", + "A.03.14.08E.ODP[04]", + "DS-A.03.14.08E[02]", + "A.03.14.08E.ODP[06]", + "DS-A.03.14.08E[03]", + "A.03.14.08E.ODP[10]" + ], + "END-06.2": [ + "DS-A.03.14.11E" + ], + "END-06.6": [ + "DS-A.03.14.10E", + "A.03.14.10E.ODP[01]" + ], + "END-06.8": [ + "DS-A.03.14.11E" + ], + "END-10": [ + "DS-A.03.13.06E" + ], + "END-11": [ + "DS-A.03.13.11E[01]" + ], + "END-12": [ + "DS-A.03.13.13E", + "A.03.13.13E.ODP[02]", + "A.03.13.13E.ODP[03]" + ], + "HRS-01": [ + "DS-A.03.09.03E.a", + "A.03.09.04E.ODP[01]" + ], + "HRS-03": [ + "A.03.01.08E.ODP[02]", + "A.03.01.11E.ODP[01]", + "A.03.14.17E.ODP[01]", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[01]", + "A.03.17.03E.ODP[03]" + ], + "HRS-04.3": [ + "DS-A.03.09.04E" + ], + "HRS-06": [ + "DS-A.03.09.03E.c.01" + ], + "HRS-12.1": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" + ], + "IAC-01": [ + "A.03.05.07E.ODP[01]" + ], + "IAC-01.4": [ + "DS-A.03.05.07E[01]", + "A.03.05.07E.ODP[02]", + "DS-A.03.05.07E[02]", + "DS-A.03.05.07E[03]" + ], + "IAC-04": [ + "DS-A.03.05.01E", + "DS-A.03.05.03E" + ], + "IAC-04.1": [ + "A.03.05.03E.ODP[01]" + ], + "IAC-08": [ + "DS-A.03.01.11E.a", + "DS-A.03.01.11E.b" + ], + "IAC-10.1": [ + "A.03.05.02E.ODP[02]" + ], + "IAC-10.4": [ + "A.03.05.02E.ODP[01]" + ], + "IAC-10.5": [ + "DS-A.03.05.02E.b" + ], + "IAC-10.6": [ + "DS-A.03.05.04E" + ], + "IAC-10.10": [ + "A.03.05.05E.ODP[01]" + ], + "IAC-10.11": [ + "DS-A.03.05.02E.a" + ], + "IAC-15.1": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]", + "DS-A.03.01.11E.a" + ], + "IAC-15.4": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]" + ], + "IAC-20.5": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" + ], + "IAC-23": [ + "DS-A.03.01.04E", + "A.03.01.04E.ODP[01]", + "A.03.01.04E.ODP[02]" + ], + "IAC-28": [ + "DS-A.03.05.06E.a", + "DS-A.03.05.06E.b", + "DS-A.03.05.06E.c[01]", + "DS-A.03.05.06E.c[02]", + "DS-A.03.05.06E.c[03]" + ], + "IAC-29": [ + "DS-A.03.01.09E.a[01]", + "DS-A.03.01.09E.a[02]", + "DS-A.03.01.09E.b", + "A.03.01.09E.ODP[01]" + ], + "IRO-01": [ + "A.03.11.09E.ODP[02]" + ], + "IRO-02": [ + "A.03.17.03E.ODP[02]" + ], + "IRO-03": [ + "A.03.01.08E.ODP[01]", + "A.03.02.01E.ODP[01]", + "DS-A.03.11.02E.a.01[01]", + "A.03.11.09E.ODP[01]", + "A.03.14.17E.ODP[02]" + ], + "IRO-07": [ + "DS-A.03.06.02E[01]", + "A.03.06.02E.ODP[01]", + "DS-A.03.06.02E[02]", + "DS-A.03.06.02E[03]" + ], + "IRO-09.1": [ + "DS-A.03.06.04E[01]", + "A.03.06.04E.ODP[01]", + "DS-A.03.06.04E[02]", + "A.03.06.04E.ODP[02]", + "DS-A.03.06.04E[03]", + "A.03.06.04E.ODP[03]" + ], + "IRO-15": [ + "DS-A.03.13.14E" + ], + "IAO-02.1": [ + "DS-A.03.12.02E" + ], + "IAO-03": [ + "A.03.01.04E.ODP[02]", + "DS-A.03.01.06E", + "A.03.13.11E.ODP[01]", + "A.03.13.14E.ODP[01]", + "A.03.13.16E.ODP[03]", + "A.03.14.08E.ODP[01]", + "A.03.14.08E.ODP[03]", + "A.03.14.08E.ODP[05]", + "A.03.14.08E.ODP[07]", + "A.03.14.08E.ODP[11]", + "A.03.14.10E.ODP[02]", + "A.03.14.14E.ODP[01]", + "A.03.14.15E.ODP[01]", + "A.03.14.16E.ODP[01]", + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.03", + "DS-A.03.15.01E.b", + "DS-A.03.15.01E.c", + "DS-A.03.15.02E.b", + "A.03.15.02E.ODP[01]", + "A.03.15.03E.ODP[01]", + "A.03.15.03E.ODP[02]", + "A.03.16.01E.ODP[02]", + "A.03.17.02E.ODP[01]" + ], + "MNT-04": [ + "DS-A.03.07.01E" + ], + "NET-02.1": [ + "DS-A.03.13.12E.a", + "A.03.13.12E.ODP[01]", + "A.03.13.12E.ODP[02]", + "DS-A.03.13.12E.b", + "A.03.13.12E.ODP[03]" + ], + "NET-03": [ + "A.03.01.12E.ODP[01]", + "DS-A.03.13.04E" + ], + "NET-03.7": [ + "A.03.13.04E.ODP[01]" + ], + "NET-03.8": [ + "DS-A.03.13.10E", + "DS-A.03.13.15E" + ], + "NET-04.2": [ + "DS-A.03.01.10E", + "A.03.01.10E.ODP[01]", + "A.03.01.10E.ODP[02]", + "A.03.01.10E.ODP[03]", + "A.03.01.10E.ODP[04]" + ], + "NET-04.5": [ + "A.03.01.13E.ODP[01]" + ], + "NET-04.7": [ + "A.03.01.10E.ODP[05]", + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "A.03.01.14E.ODP[01]", + "DS-A.03.01.14E.b" + ], + "NET-04.8": [ + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "DS-A.03.01.15E", + "A.03.01.15E.ODP[01]" + ], + "NET-04.9": [ + "A.03.01.16E.ODP[01]" + ], + "NET-04.10": [ + "DS-A.03.01.17E.a" + ], + "NET-05": [ + "DS-A.03.12.04E.a", + "A.03.12.04E.ODP[01]", + "DS-A.03.12.04E.b[01]", + "DS-A.03.12.04E.b[02]", + "DS-A.03.12.04E.b[03]", + "A.03.12.04E.ODP[02]", + "DS-A.03.12.04E.d" + ], + "NET-05.2": [ + "DS-A.03.12.04E.c" + ], + "NET-06": [ + "DS-A.03.01.12E", + "A.03.01.12E.ODP[01]" + ], + "NET-06.1": [ + "DS-A.03.13.09E", + "DS-A.03.13.15E" + ], + "NET-06.9": [ + "A.03.13.09E.ODP[01]", + "DS-A.03.13.15E", + "A.03.13.15E.ODP[01]", + "A.03.13.15E.ODP[02]" + ], + "NET-14": [ + "DS-A.03.01.06E" + ], + "NET-14.1": [ + "DS-A.03.01.05E[01]", + "DS-A.03.01.05E[02]" + ], + "NET-17": [ + "DS-A.03.01.17E.a" + ], + "PES-05": [ + "DS-A.03.10.01E[02]", + "DS-A.03.10.02E.b" + ], + "PES-05.1": [ + "DS-A.03.10.01E[02]" + ], + "PES-05.2": [ + "DS-A.03.10.01E[01]" + ], + "PES-06": [ + "A.03.10.01E.ODP[01]" + ], + "PES-10": [ + "DS-A.03.10.02E.a[01]", + "A.03.10.02E.ODP[01]", + "DS-A.03.10.02E.a[02]", + "DS-A.03.10.02E.a[03]", + "A.03.10.02E.ODP[02]", + "DS-A.03.10.02E.a[04]" + ], + "PRM-04": [ + "A.03.11.10E.ODP[02]" + ], + "PRM-05": [ + "DS-A.03.11.10E", + "A.03.13.01E.ODP[01]", + "A.03.13.02E.ODP[01]", + "A.03.13.03E.ODP[01]" + ], + "PRM-06": [ + "A.03.13.01E.ODP[01]" + ], + "RSK-11": [ + "DS-A.03.12.03E[01]" + ], + "SEA-01.4": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "SEA-01.5": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "SEA-02": [ + "DS-A.03.15.01E.a.02" + ], + "SEA-03": [ + "DS-A.03.15.02E.a", + "A.03.15.02E.ODP[02]", + "DS-A.03.15.02E.c" + ], + "SEA-03.1": [ + "DS-A.03.13.16E", + "A.03.13.16E.ODP[01]", + "A.03.13.16E.ODP[02]" + ], + "SEA-08": [ + "DS-A.03.14.15E.a", + "DS-A.03.14.15E.b", + "DS-A.03.14.15E.c", + "A.03.14.15E.ODP[02]" + ], + "SEA-08.1": [ + "DS-A.03.14.04E", + "A.03.14.04E.ODP[01]" + ], + "SEA-08.2": [ + "DS-A.03.14.05E.a", + "A.03.14.05E.ODP[01]", + "DS-A.03.14.05E.b" + ], + "SEA-10": [ + "DS-A.03.14.14E" + ], + "SEA-11": [ + "DS-A.03.13.08E[01]", + "DS-A.03.13.08E[02]", + "DS-A.03.13.08E[03]" + ], + "SEA-13": [ + "DS-A.03.13.01E" + ], + "SEA-13.1": [ + "DS-A.03.13.07E" + ], + "SEA-14": [ + "DS-A.03.13.03E" + ], + "SEA-14.1": [ + "DS-A.03.13.02E" + ], + "SEA-14.2": [ + "DS-A.03.13.05E", + "A.03.13.05E.ODP[01]" + ], + "OPS-01.1": [ + "A.03.02.01E.ODP[02]", + "A.03.08.03E.ODP[01]", + "A.03.08.03E.ODP[02]", + "DS-A.03.09.03E.b[01]", + "A.03.09.03E.ODP[01]", + "DS-A.03.09.03E.b[02]", + "DS-A.03.09.03E.c.02", + "A.03.09.03E.ODP[02]", + "A.03.11.02E.ODP[01]", + "A.03.12.01E.ODP[01]", + "A.03.12.04E.ODP[03]", + "A.03.13.05E.ODP[02]", + "A.03.13.05E.ODP[03]", + "A.03.13.07E.ODP[01]", + "A.03.14.05E.ODP[02]", + "A.03.14.05E.ODP[03]", + "A.03.14.05E.ODP[04]", + "A.03.14.08E.ODP[08]", + "A.03.14.08E.ODP[09]", + "A.03.14.08E.ODP[12]", + "A.03.14.15E.ODP[03]", + "A.03.15.01E.ODP[01]", + "A.03.17.02E.ODP[02]", + "A.03.17.02E.ODP[03]" + ], + "OPS-04": [ + "DS-A.03.06.01E[01]", + "DS-A.03.06.01E[02]" + ], + "SAT-01.1": [ + "DS-A.03.02.01E.b[01]", + "DS-A.03.02.01E.b[02]", + "A.03.02.01E.ODP[03]" + ], + "SAT-02.1": [ + "DS-A.03.02.02E" + ], + "SAT-03": [ + "DS-A.03.02.01E.a.02", + "A.03.02.04E.ODP[01]" ], "SAT-03.2": [ - "3.2.1e" + "DS-A.03.02.01E.a.02" ], "SAT-03.6": [ - "3.2.1e", - "3.2.2e" + "DS-A.03.02.01E.a.01", + "DS-A.03.02.01E.a.03" ], - "TDA-01.2": [ - "3.14.1e", - "3.14.7e" + "SAT-04.1": [ + "DS-A.03.02.03E" ], - "TDA-14.1": [ - "3.14.7e" + "TDA-01": [ + "DS-A.03.16.01E" ], - "TDA-14.2": [ - "3.14.7e" + "TDA-01.1": [ + "DS-A.03.16.01E", + "A.03.16.01E.ODP[01]" + ], + "TDA-03.1": [ + "DS-A.03.15.03E" + ], + "TDA-06.1": [ + "A.03.11.10E.ODP[01]" + ], + "TDA-11": [ + "A.03.17.02E.ODP[04]", + "DS-A.03.17.03E.b", + "A.03.17.03E.ODP[01]", + "DS-A.03.17.05E[01]", + "A.03.17.05E.ODP[01]", + "DS-A.03.17.05E[02]" + ], + "TDA-11.1": [ + "DS-A.03.02.04E" + ], + "TDA-18": [ + "DS-A.03.14.12E", + "A.03.14.12E.ODP[01]" + ], + "TDA-19": [ + "DS-A.03.14.13E.a", + "DS-A.03.14.13E.b" + ], + "TDA-19.1": [ + "A.03.14.13E.ODP[01]" + ], + "TPM-02": [ + "A.03.11.10E.ODP[01]" + ], + "TPM-05": [ + "A.03.17.01E.ODP[02]" + ], + "TPM-05.1": [ + "DS-A.03.17.01E", + "A.03.17.01E.ODP[01]" + ], + "THR-01": [ + "DS-A.03.11.01E" + ], + "THR-01.1": [ + "DS-A.03.11.08E", + "A.03.11.08E.ODP[01]" + ], + "THR-01.2": [ + "DS-A.03.11.03E[01]", + "A.03.11.03E.ODP[01]", + "A.03.11.03E.ODP[02]", + "DS-A.03.11.03E[02]", + "A.03.11.03E.ODP[03]" ], "THR-03": [ - "3.11.1e", - "3.14.6e" + "DS-A.03.11.12E" ], "THR-07": [ - "3.11.1e", - "3.11.2e", - "3.14.6e" + "DS-A.03.11.02E.a.01[02]", + "DS-A.03.11.02E.a.02[01]", + "DS-A.03.11.02E.a.02[02]", + "DS-A.03.11.02E.b" ], - "THR-09": [ - "3.11.5e" + "THR-08": [ + "DS-A.03.14.16E" + ], + "VPM-01.1": [ + "A.03.12.01E.ODP[02]" + ], + "VPM-02": [ + "A.03.11.11E.ODP[01]", + "DS-A.03.11.11E[02]" + ], + "VPM-06.8": [ + "DS-A.03.11.11E[01]" ], "VPM-07": [ - "3.12.1e" + "DS-A.03.12.01E" ] }, "general-nist-800-207": { @@ -56320,6 +58612,62 @@ "ID.RA-01" ] }, + "general-nist-cswp-39": { + "CLD-02": [ + "6.4" + ], + "CPL-01": [ + "3.1.1", + "3.1.2", + "5.1" + ], + "CRY-01.5": [ + "3.1" + ], + "CRY-09": [ + "3.3" + ], + "EMB-18": [ + "4.4" + ], + "PRM-01": [ + "6.1" + ], + "PRM-01.2": [ + "6.5" + ], + "PRM-02": [ + "6.1" + ], + "PRM-02.1": [ + "6.1" + ], + "QTS-02": [ + "5" + ], + "QTS-02.3": [ + "6.5" + ], + "QTS-03": [ + "3", + "5", + "5.3", + "6" + ], + "QTS-04": [ + "5" + ], + "QTS-06": [ + "4", + "5.4", + "6.2", + "6.3", + "6.4" + ], + "QTS-06.5": [ + "5.2" + ] + }, "general-oecd-privacy-principles-2010": { "PRI-01": [ "8" @@ -65344,700 +67692,7 @@ "12.8.4" ] }, - "general-scf-dpmp-2025": { - "GOV-01": [ - "1.0" - ], - "GOV-01.2": [ - "11.5", - "11.8" - ], - "GOV-02": [ - "11.2" - ], - "GOV-03": [ - "11.3" - ], - "GOV-05": [ - "11.5" - ], - "GOV-08": [ - "11.1" - ], - "GOV-10": [ - "5.9" - ], - "GOV-15": [ - "7.0", - "7.1" - ], - "GOV-15.1": [ - "7.0", - "7.1" - ], - "GOV-15.2": [ - "7.0", - "7.1" - ], - "GOV-15.3": [ - "7.0", - "7.1" - ], - "GOV-15.4": [ - "7.0", - "7.1" - ], - "GOV-15.5": [ - "7.0", - "7.1" - ], - "AST-02": [ - "5.2" - ], - "AST-02.8": [ - "5.2" - ], - "AST-03": [ - "5.3" - ], - "AST-03.1": [ - "5.3" - ], - "AST-04": [ - "5.2" - ], - "BCD-02": [ - "11.7" - ], - "CHG-02": [ - "7.1" - ], - "CHG-03": [ - "7.1" - ], - "CLD-01": [ - "7.1" - ], - "CLD-02": [ - "7.1" - ], - "CPL-01": [ - "2.4", - "11.6" - ], - "CPL-01.1": [ - "11.6" - ], - "CPL-01.2": [ - "11.6" - ], - "CPL-01.3": [ - "11.6" - ], - "CPL-01.4": [ - "11.6" - ], - "CPL-02": [ - "11.4" - ], - "CPL-03": [ - "11.3" - ], - "CFG-01": [ - "7.12" - ], - "CFG-02": [ - "7.12" - ], - "CFG-08.1": [ - "5.2" - ], - "MON-01": [ - "7.0" - ], - "MON-02": [ - "7.0", - "7.13" - ], - "MON-02.1": [ - "7.13" - ], - "MON-10": [ - "11.6" - ], - "CRY-01": [ - "7.2" - ], - "CRY-03": [ - "7.2" - ], - "CRY-05": [ - "7.2" - ], - "DCH-01": [ - "5.0" - ], - "DCH-01.3": [ - "5.2" - ], - "DCH-02": [ - "1.2" - ], - "DCH-09.3": [ - "5.5" - ], - "DCH-18": [ - "5.4" - ], - "DCH-18.1": [ - "3.3", - "5.4" - ], - "DCH-18.2": [ - "3.2" - ], - "DCH-21": [ - "5.5" - ], - "DCH-22.1": [ - "5.15", - "6.1", - "6.2" - ], - "DCH-23": [ - "5.1" - ], - "DCH-24": [ - "5.6" - ], - "DCH-25": [ - "5.6" - ], - "EMB-01": [ - "7.4" - ], - "END-13.1": [ - "7.4" - ], - "END-13.2": [ - "7.4" - ], - "END-13.3": [ - "7.4" - ], - "HRS-01": [ - "7.9" - ], - "HRS-04": [ - "7.1" - ], - "HRS-05.1": [ - "7.7" - ], - "HRS-05.2": [ - "7.7" - ], - "HRS-07": [ - "7.8" - ], - "IAC-01": [ - "7.0" - ], - "IAC-01.2": [ - "7.1" - ], - "IAC-06": [ - "7.1" - ], - "IAC-08": [ - "7.1" - ], - "IAC-16": [ - "7.1" - ], - "IAC-21": [ - "7.1" - ], - "IAC-28.1": [ - "7.1" - ], - "IRO-01": [ - "8.0" - ], - "IRO-02": [ - "8.0", - "8.1" - ], - "IRO-04": [ - "8.0" - ], - "IRO-04.1": [ - "8.0" - ], - "IRO-06": [ - "8.0" - ], - "IRO-07": [ - "8.1" - ], - "IRO-10": [ - "8.2" - ], - "IRO-11": [ - "8.0" - ], - "IRO-11.2": [ - "8.2" - ], - "IAO-01": [ - "7.11" - ], - "IAO-03": [ - "5.13" - ], - "IAO-05": [ - "9.3" - ], - "IAO-07": [ - "7.11" - ], - "PES-01": [ - "7.3" - ], - "PES-02": [ - "7.3" - ], - "PES-02.1": [ - "7.3" - ], - "PES-03": [ - "7.3" - ], - "PES-04": [ - "7.3" - ], - "PES-05": [ - "7.3" - ], - "PES-06": [ - "7.3" - ], - "PRI-01": [ - "1.0", - "1.1" - ], - "PRI-01.1": [ - "1.1" - ], - "PRI-01.2": [ - "4.0" - ], - "PRI-01.3": [ - "1.0", - "11.2" - ], - "PRI-01.4": [ - "1.1" - ], - "PRI-01.6": [ - "7.0", - "7.1" - ], - "PRI-01.11": [ - "1.0" - ], - "PRI-02": [ - "4.0" - ], - "PRI-02.1": [ - "4.1" - ], - "PRI-02.2": [ - "5.0" - ], - "PRI-02.3": [ - "11.6" - ], - "PRI-02.4": [ - "11.6" - ], - "PRI-02.5": [ - "11.6" - ], - "PRI-02.6": [ - "11.6" - ], - "PRI-03": [ - "2.0", - "2.1", - "2.2" - ], - "PRI-03.1": [ - "2.5" - ], - "PRI-03.2": [ - "2.3", - "5.14" - ], - "PRI-03.3": [ - "2.5" - ], - "PRI-03.4": [ - "2.3" - ], - "PRI-03.5": [ - "2.4" - ], - "PRI-03.6": [ - "2.6" - ], - "PRI-03.7": [ - "6.0" - ], - "PRI-03.8": [ - "2.7" - ], - "PRI-04": [ - "3.0" - ], - "PRI-04.1": [ - "3.1" - ], - "PRI-05": [ - "5.0" - ], - "PRI-05.1": [ - "3.3" - ], - "PRI-05.2": [ - "5.9" - ], - "PRI-05.3": [ - "5.1" - ], - "PRI-05.4": [ - "3.3" - ], - "PRI-05.5": [ - "1.5" - ], - "PRI-05.6": [ - "1.5" - ], - "PRI-05.7": [ - "1.2", - "1.7" - ], - "PRI-06": [ - "6.0" - ], - "PRI-06.1": [ - "6.3" - ], - "PRI-06.2": [ - "6.4" - ], - "PRI-06.3": [ - "6.5" - ], - "PRI-06.4": [ - "6.1" - ], - "PRI-06.5": [ - "6.6" - ], - "PRI-06.6": [ - "5.7" - ], - "PRI-06.7": [ - "5.7" - ], - "PRI-06.8": [ - "6.1" - ], - "PRI-07": [ - "10.2" - ], - "PRI-07.1": [ - "10.3" - ], - "PRI-07.2": [ - "11.1" - ], - "PRI-07.3": [ - "6.4" - ], - "PRI-07.4": [ - "6.0", - "6.1" - ], - "PRI-08": [ - "10.4" - ], - "PRI-09": [ - "5.1", - "5.13" - ], - "PRI-10": [ - "5.11" - ], - "PRI-10.1": [ - "5.11" - ], - "PRI-10.2": [ - "5.16" - ], - "PRI-11": [ - "5.0", - "5.2" - ], - "PRI-12": [ - "6.2" - ], - "PRI-13": [ - "11.4" - ], - "PRI-14": [ - "5.8", - "11.5" - ], - "PRI-14.1": [ - "5.8" - ], - "PRI-14.2": [ - "4.0", - "4.1" - ], - "PRI-15": [ - "1.3" - ], - "PRI-17": [ - "1.8" - ], - "PRI-17.1": [ - "1.9" - ], - "PRI-17.2": [ - "1.1" - ], - "PRM-01": [ - "1.4" - ], - "PRM-02": [ - "11.0" - ], - "PRM-04": [ - "5.12" - ], - "PRM-05": [ - "5.12" - ], - "PRM-06": [ - "5.12" - ], - "PRM-07": [ - "5.12" - ], - "PRM-08": [ - "5.12" - ], - "RSK-01": [ - "9.0" - ], - "RSK-04": [ - "9.1" - ], - "RSK-04.1": [ - "9.3" - ], - "RSK-04.3": [ - "9.1" - ], - "RSK-04.4": [ - "9.1" - ], - "RSK-06.1": [ - "9.4" - ], - "RSK-06.2": [ - "9.0" - ], - "RSK-08": [ - "9.2" - ], - "RSK-09": [ - "9.2" - ], - "RSK-09.1": [ - "9.2" - ], - "RSK-10": [ - "9.5" - ], - "RSK-11": [ - "7.11", - "9.0", - "9.3" - ], - "SEA-01": [ - "5.12", - "7.1" - ], - "SEA-01.1": [ - "7.0" - ], - "SEA-02": [ - "7.1" - ], - "SEA-15": [ - "5.6" - ], - "SAT-01": [ - "1.6", - "7.6" - ], - "SAT-02": [ - "1.6" - ], - "SAT-02.1": [ - "1.6" - ], - "SAT-03": [ - "1.6" - ], - "SAT-03.1": [ - "1.6" - ], - "SAT-03.2": [ - "1.6" - ], - "SAT-03.3": [ - "1.6" - ], - "SAT-03.6": [ - "1.6" - ], - "SAT-04": [ - "1.6" - ], - "TDA-01": [ - "7.0" - ], - "TDA-01.1": [ - "7.1" - ], - "TDA-02.3": [ - "7.1" - ], - "TDA-02.4": [ - "7.1" - ], - "TDA-02.6": [ - "7.1" - ], - "TDA-02.7": [ - "7.1" - ], - "TDA-02.8": [ - "7.1" - ], - "TDA-02.9": [ - "7.1" - ], - "TDA-02.10": [ - "7.1" - ], - "TDA-02.11": [ - "7.1" - ], - "TDA-06": [ - "5.12", - "7.1" - ], - "TDA-06.1": [ - "11.7" - ], - "TDA-06.5": [ - "7.1" - ], - "TDA-09": [ - "7.0", - "7.11", - "7.12" - ], - "TDA-17": [ - "7.5" - ], - "TDA-22": [ - "7.1" - ], - "TPM-01": [ - "10.0", - "11.0" - ], - "TPM-02": [ - "11.7" - ], - "TPM-03": [ - "10.1" - ], - "TPM-04": [ - "10.0", - "10.1", - "10.4" - ], - "TPM-04.4": [ - "5.6" - ], - "TPM-05": [ - "10.3" - ], - "TPM-05.2": [ - "10.3" - ], - "TPM-05.4": [ - "10.4" - ], - "TPM-05.5": [ - "10.4" - ], - "TPM-08": [ - "10.0", - "10.4" - ], - "TPM-09": [ - "10.0", - "10.4" - ], - "TPM-10": [ - "10.0", - "10.4" - ], - "THR-06": [ - "5.15" - ], - "VPM-01": [ - "5.15" - ], - "VPM-01.1": [ - "5.15" - ], - "VPM-02": [ - "5.15" - ], - "VPM-03": [ - "5.15" - ], - "VPM-04": [ - "5.15" - ], - "VPM-04.2": [ - "5.15" - ], - "VPM-05": [ - "5.15" - ] - }, + "general-scf-dpmp-2025": {}, "general-shared-assessments-sig-2025": { "GOV-04.1": [ "R.6" @@ -74186,6 +75841,7 @@ "6.6.3" ], "CLD-04.1": [ + "3.4", "3.4.1" ], "CLD-09": [ @@ -82025,6 +83681,417 @@ "SA-11(05)" ] }, + "usa-federal-law-33-cfr-part-101-subpart-f": { + "GOV-01": [ + "101.620(b)(1)" + ], + "GOV-01.2": [ + "101.625(d)(14)", + "101.645(a)" + ], + "GOV-02": [ + "101.625(d)(5)" + ], + "GOV-02.1": [ + "101.625(d)(14)" + ], + "GOV-03": [ + "101.625(d)(5)" + ], + "GOV-04": [ + "101.620(b)(2)", + "101.620(b)(3)", + "101.625(c)" + ], + "GOV-04.1": [ + "101.620(b)(2)" + ], + "GOV-15": [ + "101.625(d)(2)", + "101.625(d)(5)", + "101.650(c)" + ], + "GOV-15.1": [ + "101.625(d)(2)" + ], + "GOV-15.2": [ + "101.625(d)(2)" + ], + "GOV-15.3": [ + "101.625(d)(2)" + ], + "GOV-17": [ + "101.625(d)(12)", + "101.625(d)(13)", + "101.630(d)", + "101.630(e)(2)", + "101.630(e)(2)(ii)", + "101.630(e)(3)", + "101.630(e)(4)", + "101.630(f)(3)", + "101.630(f)(5)" + ], + "AST-01": [ + "101.650(i)(2)" + ], + "AST-01.4": [ + "101.650(b)(1)" + ], + "AST-01.5": [ + "101.650(i)(2)" + ], + "AST-02": [ + "101.650(b)(3)" + ], + "AST-02.2": [ + "101.650(i)(2)" + ], + "AST-04": [ + "101.650(b)(4)" + ], + "BCD-11": [ + "101.650(g)(4)" + ], + "CAP-01": [ + "101.650(f)(1)" + ], + "CPL-01": [ + "101.620(a)", + "101.620(b)(4)", + "101.620(b)(5)", + "101.650(b)", + "101.650(e)", + "101.650(e)(3)", + "101.650(f)", + "101.650(g)", + "101.650(h)", + "101.650(i)" + ], + "CPL-01.2": [ + "101.605(a)", + "101.605(b)", + "101.625(d)", + "101.630(d)(2)" + ], + "CPL-01.3": [ + "101.625(d)(6)", + "101.660" + ], + "CPL-01.4": [ + "101.650(g)(3)" + ], + "CPL-01.6": [ + "101.630(f)(4)", + "101.630(f)(4)(i)" + ], + "CPL-02": [ + "101.625(d)(7)" + ], + "CPL-02.2": [ + "101.625(d)(3)" + ], + "CPL-02.3": [ + "101.625(d)(7)" + ], + "CPL-03": [ + "101.630(f)(1)", + "101.630(f)(2)" + ], + "CPL-03.1": [ + "101.630(f)(4)(ii)", + "101.630(f)(4)(iii)" + ], + "CPL-05.2": [ + "101.625(d)(6)" + ], + "CPL-13": [ + "101.640" + ], + "CFG-02": [ + "101.650(b)(2)", + "101.650(c)(2)" + ], + "CFG-02.5": [ + "101.650(b)(2)" + ], + "MON-01": [ + "101.650(c)(1)", + "101.650(f)(3)" + ], + "MON-01.3": [ + "101.650(f)(3)", + "101.650(h)(2)" + ], + "MON-01.4": [ + "101.650(c)(1)", + "101.650(h)(2)" + ], + "MON-01.8": [ + "101.650(c)(1)" + ], + "MON-08": [ + "101.650(c)(1)" + ], + "MON-08.2": [ + "101.650(c)(1)" + ], + "MON-10": [ + "101.650(c)(1)" + ], + "CRY-01": [ + "101.650(c)(2)" + ], + "CRY-03": [ + "101.650(c)(2)" + ], + "CRY-05": [ + "101.650(c)(2)" + ], + "DCH-01": [ + "101.630(b)" + ], + "DCH-01.4": [ + "101.630(b)" + ], + "DCH-18": [ + "101.625(d)(11)", + "101.640" + ], + "EMB-03": [ + "101.650(e)(3)(v)" + ], + "HRS-01.1": [ + "101.650(a)(7)" + ], + "HRS-02": [ + "101.625(a)" + ], + "HRS-03": [ + "101.620(b)(2)", + "101.625(a)" + ], + "HRS-03.1": [ + "101.625(d)(8)" + ], + "HRS-03.2": [ + "101.625(e)", + "101.625(e)(1)", + "101.625(e)(2)", + "101.625(e)(3)", + "101.625(e)(4)", + "101.625(e)(5)", + "101.625(e)(6)", + "101.625(e)(7)", + "101.625(e)(8)", + "101.625(e)(9)", + "101.625(e)(10)", + "101.625(e)(11)", + "101.625(e)(12)" + ], + "HRS-04.2": [ + "101.625(d)(8)" + ], + "HRS-11": [ + "101.650(a)(6)" + ], + "IAC-01": [ + "101.650(a)" + ], + "IAC-06": [ + "101.650(a)(4)" + ], + "IAC-07": [ + "101.650(a)(7)" + ], + "IAC-10.1": [ + "101.650(a)(3)" + ], + "IAC-10.8": [ + "101.650(a)(2)" + ], + "IAC-15.10": [ + "101.650(a)(6)" + ], + "IAC-16.2": [ + "101.650(a)(6)" + ], + "IAC-21": [ + "101.650(a)(5)" + ], + "IAC-22": [ + "101.650(a)(1)" + ], + "IRO-02": [ + "101.625(d)(4)" + ], + "IRO-04": [ + "101.620(b)(6)", + "101.650(g)(2)" + ], + "IRO-06": [ + "101.635(a)(1)", + "101.635(b)(1)", + "101.635(b)(2)", + "101.635(b)(3)", + "101.635(c)(1)", + "101.635(c)(2)", + "101.635(c)(2)(i)", + "101.635(c)(2)(ii)", + "101.635(c)(2)(iii)", + "101.635(c)(2)(iv)", + "101.635(c)(3)", + "101.635(c)(4)", + "101.635(c)(5)" + ], + "IRO-06.1": [ + "101.635(a)(1)" + ], + "IRO-10": [ + "101.625(d)(10)" + ], + "IRO-10.2": [ + "101.620(b)(7)", + "101.625(d)(10)", + "101.650(g)(1)" + ], + "IRO-10.5": [ + "101.625(d)(10)" + ], + "IRO-13": [ + "101.635(c)(6)" + ], + "IRO-14": [ + "101.620(b)(3)" + ], + "IAO-02": [ + "101.650(e)(1)", + "101.650(e)(1)(i)", + "101.650(e)(1)(ii)" + ], + "IAO-02.4": [ + "101.650(e)(1)(iii)" + ], + "IAO-03": [ + "101.625(d)(5)", + "101.630(a)", + "101.630(c)", + "101.630(c)(1)", + "101.630(c)(2)", + "101.630(c)(3)", + "101.630(c)(4)", + "101.630(c)(5)", + "101.630(c)(6)", + "101.630(c)(7)", + "101.630(c)(8)", + "101.630(c)(9)", + "101.630(c)(10)", + "101.630(c)(11)", + "101.630(c)(12)", + "101.630(c)(13)", + "101.630(c)(14)", + "101.650(c)", + "101.650(e)(1)(v)" + ], + "IAO-05": [ + "101.650(e)(1)(iv)" + ], + "MNT-06.1": [ + "101.650(d)(3)" + ], + "MNT-06.2": [ + "101.650(d)(3)" + ], + "NET-06": [ + "101.650(h)(1)" + ], + "NET-06.5": [ + "101.650(e)(3)(iv)", + "101.650(e)(3)(v)" + ], + "PES-02": [ + "101.650(i)(1)" + ], + "PES-02.1": [ + "101.650(i)(1)" + ], + "PES-03": [ + "101.650(i)(1)" + ], + "PES-06.3": [ + "101.650(d)(3)" + ], + "RSK-04": [ + "101.625(d)(1)" + ], + "SEA-02.1": [ + "101.615" + ], + "SEA-03": [ + "101.650(e)(3)(iv)" + ], + "SAT-01": [ + "101.625(d)(8)", + "101.650(d)" + ], + "SAT-01.1": [ + "101.625(d)(8)" + ], + "SAT-02": [ + "101.625(d)(9)", + "101.650(d)(1)", + "101.650(d)(1)(i)", + "101.650(d)(1)(ii)", + "101.650(d)(1)(iii)", + "101.650(d)(1)(iv)" + ], + "SAT-03": [ + "101.625(d)(9)", + "101.650(d)(1)(v)", + "101.650(d)(2)", + "101.650(d)(2)(i)", + "101.650(d)(2)(ii)", + "101.650(d)(4)" + ], + "SAT-03.6": [ + "101.625(d)(8)" + ], + "SAT-04": [ + "101.650(d)(4)" + ], + "TPM-05": [ + "101.650(f)(2)" + ], + "THR-03": [ + "101.650(e)(3)(ii)" + ], + "THR-03.1": [ + "101.625(d)(8)", + "101.625(d)(14)", + "101.650(e)(3)(iii)" + ], + "VPM-01.1": [ + "101.625(d)(15)" + ], + "VPM-02": [ + "101.625(d)(15)" + ], + "VPM-03": [ + "101.625(d)(15)" + ], + "VPM-05": [ + "101.625(d)(15)", + "101.650(e)(3)(i)" + ], + "VPM-05.4": [ + "101.650(e)(3)(ii)" + ], + "VPM-06": [ + "101.650(e)(3)(vi)" + ], + "VPM-07": [ + "101.650(e)(2)" + ] + }, "usa-federal-law-ferpa-2010": { "CPL-01": [ "1232h(c)(1)(C)(i)" @@ -82698,1586 +84765,1586 @@ }, "usa-federal-law-hipaa-simplification-2013": { "GOV-01": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)", - "164.530(c)(1)", - "164.530(i)(1)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)", + "§ 164.530(c)(1)", + "§ 164.530(i)(1)" ], "GOV-02": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)", - "164.530(j)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)", + "§ 164.530(j)(1)(i)" ], "GOV-02.1": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "GOV-03": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)", - "164.530(i)(2)(i)", - "164.530(i)(2)(ii)", - "164.530(i)(2)(iii)", - "164.530(i)(3)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)", + "§ 164.530(i)(2)(i)", + "§ 164.530(i)(2)(ii)", + "§ 164.530(i)(2)(iii)", + "§ 164.530(i)(3)" ], "GOV-04": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "GOV-08": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "GOV-09": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "GOV-15": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "GOV-15.1": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.2": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "GOV-15.3": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.4": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.5": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "AST-01": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "AST-01.1": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "AST-02": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-02.1": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-02.9": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-03": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-03.1": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-09": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "AST-11": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "BCD-01": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "BCD-02": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "BCD-02.2": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "BCD-04": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "BCD-05": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "BCD-09.2": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "BCD-11": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "BCD-12": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "CHG-01": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "CPL-01": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)", - "164.504(g)(1)", - "164.530(i)(1)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)", + "§ 164.504(g)(1)", + "§ 164.530(i)(1)" ], "CPL-02": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "CPL-03": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "CPL-03.2": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "CFG-01": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "CFG-02": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "CFG-08": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "CFG-08.1": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "MON-01.4": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-01.7": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01.8": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "MON-01.15": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01.16": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-03": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-03.2": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-16": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "CRY-01": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "CRY-03": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "CRY-04": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "DCH-01": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "DCH-01.2": [ - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "DCH-03": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-03.1": [ - "164.510(b)(1)(i)", - "164.510(b)(1)(ii)", - "164.510(b)(2)", - "164.510(b)(4)", - "164.510(b)(5)", - "164.512", - "164.512(a)(1)", - "164.512(c)(1)", - "164.512(c)(1)(i)", - "164.512(c)(1)(ii)", - "164.512(c)(1)(iii)(A)", - "164.512(c)(1)(iii)(B)", - "164.512(c)(2)", - "164.512(c)(2)(i)", - "164.512(c)(2)(ii)", - "164.512(d)(1)", - "164.512(d)(1)(i)", - "164.512(d)(1)(ii)", - "164.512(d)(1)(iii)", - "164.512(d)(1)(iv)", - "164.512(e)(1)", - "164.512(e)(1)(i)", - "164.512(e)(1)(ii)", - "164.512(e)(1)(ii)(A)", - "164.512(e)(1)(ii)(B)", - "164.512(e)(1)(iii)", - "164.512(e)(1)(iii)(A)", - "164.512(e)(1)(iii)(B)", - "164.512(e)(1)(iii)(C)", - "164.512(e)(1)(iii)(C)(1)", - "164.512(e)(1)(iii)(C)(2)", - "164.512(e)(1)(iv)", - "164.512(e)(1)(iv)(A)", - "164.512(e)(1)(iv)(B)", - "164.512(e)(1)(v)", - "164.512(e)(1)(v)(A)", - "164.512(e)(1)(v)(B)", - "164.512(e)(1)(vi)", - "164.512(f)", - "164.512(f)(1)", - "164.512(f)(1)(i)", - "164.512(f)(1)(ii)(A)", - "164.512(f)(1)(ii)(B)", - "164.512(f)(1)(ii)(C)", - "164.512(f)(1)(ii)(C)(1)", - "164.512(f)(1)(ii)(C)(2)", - "164.512(f)(1)(ii)(C)(3)", - "164.512(f)(2)", - "164.512(f)(2)(i)(A)", - "164.512(f)(2)(i)(B)", - "164.512(f)(2)(i)(C)", - "164.512(f)(2)(i)(D)", - "164.512(f)(2)(i)(E)", - "164.512(f)(2)(i)(F)", - "164.512(f)(2)(i)(G)", - "164.512(f)(2)(i)(H)", - "164.512(f)(2)(ii)", - "164.512(f)(3)", - "164.512(f)(3)(i)", - "164.512(f)(3)(ii)", - "164.512(f)(3)(ii)(A)", - "164.512(f)(3)(ii)(B)", - "164.512(f)(3)(ii)(C)", - "164.512(f)(4)", - "164.512(f)(5)", - "164.512(f)(6)(i)", - "164.512(f)(6)(i)(A)", - "164.512(f)(6)(i)(B)", - "164.512(f)(6)(i)(C)", - "164.512(f)(6)(ii)", - "164.512(g)(1)", - "164.512(g)(2)", - "164.512(h)", - "164.512(i)(1)", - "164.512(j)(1)", - "164.514(d)(3)(i)", - "164.514(d)(3)(ii)(A)", - "164.514(d)(3)(ii)(B)", - "164.514(d)(3)(iii)", - "164.514(d)(3)(iii)(A)", - "164.514(d)(3)(iii)(B)", - "164.514(d)(3)(iii)(C)", - "164.514(d)(3)(iii)(D)", - "164.514(d)(4)", - "164.514(d)(4)(i)", - "164.514(d)(4)(ii)", - "164.514(d)(4)(iii)(A)", - "164.514(d)(4)(iii)(B)", - "164.514(d)(5)", - "164.514(e)(1)", - "164.514(e)(2)", - "164.514(e)(2)(i)", - "164.514(e)(2)(ii)", - "164.514(e)(2)(iii)", - "164.514(e)(2)(iv)", - "164.514(e)(2)(v)", - "164.514(e)(2)(vi)", - "164.514(e)(2)(vii)", - "164.514(e)(2)(viii)", - "164.514(e)(2)(ix)", - "164.514(e)(2)(x)", - "164.514(e)(2)(xi)", - "164.514(e)(2)(xii)", - "164.514(e)(2)(xiii)", - "164.514(e)(2)(xiv)", - "164.514(e)(2)(xv)", - "164.514(e)(2)(xvi)", - "164.514(e)(3)(i)", - "164.514(e)(3)(ii)", - "164.514(e)(4)(i)", - "164.514(e)(4)(ii)", - "164.514(e)(4)(ii)(A)", - "164.514(e)(4)(ii)(B)", - "164.514(e)(4)(ii)(C)", - "164.514(e)(4)(ii)(C)(1)", - "164.514(e)(4)(ii)(C)(2)", - "164.514(e)(4)(ii)(C)(3)", - "164.514(e)(4)(ii)(C)(4)", - "164.514(e)(4)(ii)(C)(5)", - "164.532(a)", - "164.532(b)", - "164.532(c)", - "164.532(c)(1)", - "164.532(d)" + "§ 164.510(b)(1)(i)", + "§ 164.510(b)(1)(ii)", + "§ 164.510(b)(2)", + "§ 164.510(b)(4)", + "§ 164.510(b)(5)", + "§ 164.512", + "§ 164.512(a)(1)", + "§ 164.512(c)(1)", + "§ 164.512(c)(1)(i)", + "§ 164.512(c)(1)(ii)", + "§ 164.512(c)(1)(iii)(A)", + "§ 164.512(c)(1)(iii)(B)", + "§ 164.512(c)(2)", + "§ 164.512(c)(2)(i)", + "§ 164.512(c)(2)(ii)", + "§ 164.512(d)(1)", + "§ 164.512(d)(1)(i)", + "§ 164.512(d)(1)(ii)", + "§ 164.512(d)(1)(iii)", + "§ 164.512(d)(1)(iv)", + "§ 164.512(e)(1)", + "§ 164.512(e)(1)(i)", + "§ 164.512(e)(1)(ii)", + "§ 164.512(e)(1)(ii)(A)", + "§ 164.512(e)(1)(ii)(B)", + "§ 164.512(e)(1)(iii)", + "§ 164.512(e)(1)(iii)(A)", + "§ 164.512(e)(1)(iii)(B)", + "§ 164.512(e)(1)(iii)(C)", + "§ 164.512(e)(1)(iii)(C)(1)", + "§ 164.512(e)(1)(iii)(C)(2)", + "§ 164.512(e)(1)(iv)", + "§ 164.512(e)(1)(iv)(A)", + "§ 164.512(e)(1)(iv)(B)", + "§ 164.512(e)(1)(v)", + "§ 164.512(e)(1)(v)(A)", + "§ 164.512(e)(1)(v)(B)", + "§ 164.512(e)(1)(vi)", + "§ 164.512(f)", + "§ 164.512(f)(1)", + "§ 164.512(f)(1)(i)", + "§ 164.512(f)(1)(ii)(A)", + "§ 164.512(f)(1)(ii)(B)", + "§ 164.512(f)(1)(ii)(C)", + "§ 164.512(f)(1)(ii)(C)(1)", + "§ 164.512(f)(1)(ii)(C)(2)", + "§ 164.512(f)(1)(ii)(C)(3)", + "§ 164.512(f)(2)", + "§ 164.512(f)(2)(i)(A)", + "§ 164.512(f)(2)(i)(B)", + "§ 164.512(f)(2)(i)(C)", + "§ 164.512(f)(2)(i)(D)", + "§ 164.512(f)(2)(i)(E)", + "§ 164.512(f)(2)(i)(F)", + "§ 164.512(f)(2)(i)(G)", + "§ 164.512(f)(2)(i)(H)", + "§ 164.512(f)(2)(ii)", + "§ 164.512(f)(3)", + "§ 164.512(f)(3)(i)", + "§ 164.512(f)(3)(ii)", + "§ 164.512(f)(3)(ii)(A)", + "§ 164.512(f)(3)(ii)(B)", + "§ 164.512(f)(3)(ii)(C)", + "§ 164.512(f)(4)", + "§ 164.512(f)(5)", + "§ 164.512(f)(6)(i)", + "§ 164.512(f)(6)(i)(A)", + "§ 164.512(f)(6)(i)(B)", + "§ 164.512(f)(6)(i)(C)", + "§ 164.512(f)(6)(ii)", + "§ 164.512(g)(1)", + "§ 164.512(g)(2)", + "§ 164.512(h)", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.514(d)(3)(ii)(A)", + "§ 164.514(d)(3)(ii)(B)", + "§ 164.514(d)(3)(iii)", + "§ 164.514(d)(3)(iii)(A)", + "§ 164.514(d)(3)(iii)(B)", + "§ 164.514(d)(3)(iii)(C)", + "§ 164.514(d)(3)(iii)(D)", + "§ 164.514(d)(4)", + "§ 164.514(d)(4)(i)", + "§ 164.514(d)(4)(ii)", + "§ 164.514(d)(4)(iii)(A)", + "§ 164.514(d)(4)(iii)(B)", + "§ 164.514(d)(5)", + "§ 164.514(e)(1)", + "§ 164.514(e)(2)", + "§ 164.514(e)(2)(i)", + "§ 164.514(e)(2)(ii)", + "§ 164.514(e)(2)(iii)", + "§ 164.514(e)(2)(iv)", + "§ 164.514(e)(2)(v)", + "§ 164.514(e)(2)(vi)", + "§ 164.514(e)(2)(vii)", + "§ 164.514(e)(2)(viii)", + "§ 164.514(e)(2)(ix)", + "§ 164.514(e)(2)(x)", + "§ 164.514(e)(2)(xi)", + "§ 164.514(e)(2)(xii)", + "§ 164.514(e)(2)(xiii)", + "§ 164.514(e)(2)(xiv)", + "§ 164.514(e)(2)(xv)", + "§ 164.514(e)(2)(xvi)", + "§ 164.514(e)(3)(i)", + "§ 164.514(e)(3)(ii)", + "§ 164.514(e)(4)(i)", + "§ 164.514(e)(4)(ii)", + "§ 164.514(e)(4)(ii)(A)", + "§ 164.514(e)(4)(ii)(B)", + "§ 164.514(e)(4)(ii)(C)", + "§ 164.514(e)(4)(ii)(C)(1)", + "§ 164.514(e)(4)(ii)(C)(2)", + "§ 164.514(e)(4)(ii)(C)(3)", + "§ 164.514(e)(4)(ii)(C)(4)", + "§ 164.514(e)(4)(ii)(C)(5)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)", + "§ 164.532(c)(1)", + "§ 164.532(d)" ], "DCH-07": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-07.1": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-09": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "DCH-13.2": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-18": [ - "164.316(b)(2)(i)", - "164.530(j)(2)" + "§ 164.316(b)(2)(i)", + "§ 164.530(j)(2)" ], "DCH-18.1": [ - "164.502(b)(1)" + "§ 164.502(b)(1)" ], "DCH-22.1": [ - "164.526(a)(1)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)" ], "END-01": [ - "164.310(b)" + "§ 164.310(b)" ], "END-02": [ - "164.310(c)" + "§ 164.310(c)" ], "HRS-01": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)", - "164.530(e)(2)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)", + "§ 164.530(e)(2)" ], "HRS-02": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "HRS-03": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "HRS-04": [ - "164.312(d)" + "§ 164.312(d)" ], "HRS-05": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.1": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.3": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.7": [ - "164.530(b)(1)" + "§ 164.530(b)(1)" ], "HRS-06.1": [ - "164.502(a)" + "§ 164.502(a)" ], "HRS-07": [ - "164.308(a)(1)(ii)(C)", - "164.530(e)(1)" + "§ 164.308(a)(1)(ii)(C)", + "§ 164.530(e)(1)" ], "HRS-08": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "HRS-09": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-01": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)", + "§ 164.530(c)(2)(ii)" ], "IAC-02": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "IAC-07": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-07.1": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "IAC-07.2": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-08": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)", - "164.514(d)(2)(i)(A)", - "164.514(d)(2)(i)(B)", - "164.514(d)(2)(ii)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)", + "§ 164.514(d)(2)(i)(A)", + "§ 164.514(d)(2)(i)(B)", + "§ 164.514(d)(2)(ii)", + "§ 164.530(c)(2)(ii)" ], "IAC-09": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "IAC-15": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-15.2": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-15.9": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-17": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "IAC-21": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "IAC-25": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "IAC-28": [ - "164.312(d)" + "§ 164.312(d)" ], "IAC-28.1": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "IAC-28.2": [ - "164.312(d)" + "§ 164.312(d)" ], "IAC-28.3": [ - "164.312(d)" + "§ 164.312(d)" ], "IRO-01": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "IRO-02": [ - "164.308(a)(6)(ii)", - "164.412", - "164.412(a)", - "164.412(b)", - "164.530(f)" + "§ 164.308(a)(6)(ii)", + "§ 164.412", + "§ 164.412(a)", + "§ 164.412(b)", + "§ 164.530(f)" ], "IRO-04.1": [ - "164.404(a)(1)", - "164.404(a)(2)", - "164.404(c)(1)(A)", - "164.404(c)(1)(B)", - "164.404(c)(1)(C)", - "164.404(c)(1)(D)", - "164.404(c)(1)(E)", - "164.404(c)(2)", - "164.404(d)(1)(i)", - "164.404(d)(1)(ii)", - "164.404(d)(2)", - "164.404(d)(2)(i)", - "164.404(d)(2)(ii)(A)", - "164.404(d)(2)(ii)(B)", - "164.404(d)(3)", - "164.406(a)", - "164.406(b)", - "164.406(c)", - "164.410(c)(1)" + "§ 164.404(a)(1)", + "§ 164.404(a)(2)", + "§ 164.404(c)(1)(A)", + "§ 164.404(c)(1)(B)", + "§ 164.404(c)(1)(C)", + "§ 164.404(c)(1)(D)", + "§ 164.404(c)(1)(E)", + "§ 164.404(c)(2)", + "§ 164.404(d)(1)(i)", + "§ 164.404(d)(1)(ii)", + "§ 164.404(d)(2)", + "§ 164.404(d)(2)(i)", + "§ 164.404(d)(2)(ii)(A)", + "§ 164.404(d)(2)(ii)(B)", + "§ 164.404(d)(3)", + "§ 164.406(a)", + "§ 164.406(b)", + "§ 164.406(c)", + "§ 164.410(c)(1)" ], "IRO-09": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "IRO-10": [ - "164.404(b)", - "164.408(a)", - "164.408(b)", - "164.408(c)" + "§ 164.404(b)", + "§ 164.408(a)", + "§ 164.408(b)", + "§ 164.408(c)" ], "IRO-10.2": [ - "164.410(a)(1)" + "§ 164.410(a)(1)" ], "IAO-01.1": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "IAO-02": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "IAO-03.2": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "MNT-01": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "MNT-02": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "MNT-04.3": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "NET-01": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "PES-01": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "PES-02": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "PES-02.1": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "PES-03": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "PES-03.4": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "PES-04": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "PES-04.1": [ - "164.310(c)" + "§ 164.310(c)" ], "PES-06": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "PRI-01": [ - "164.502(a)", - "164.530(a)(1)(i)", - "164.530(i)(1)", - "164.530(i)(4)(i)(A)", - "164.530(i)(4)(i)(B)", - "164.530(i)(5)", - "164.530(i)(5)(i)", - "164.530(i)(5)(ii)" + "§ 164.502(a)", + "§ 164.530(a)(1)(i)", + "§ 164.530(i)(1)", + "§ 164.530(i)(4)(i)(A)", + "§ 164.530(i)(4)(i)(B)", + "§ 164.530(i)(5)", + "§ 164.530(i)(5)(i)", + "§ 164.530(i)(5)(ii)" ], "PRI-01.1": [ - "164.530(a)(1)(i)" + "§ 164.530(a)(1)(i)" ], "PRI-01.4": [ - "164.530(a)(1)(ii)" + "§ 164.530(a)(1)(ii)" ], "PRI-02": [ - "164.520(a)(1)", - "164.520(a)(2)(i)", - "164.520(a)(2)(i)(A)", - "164.520(a)(2)(i)(B)", - "164.520(a)(2)(ii)", - "164.520(a)(2)(ii)(A)", - "164.520(a)(2)(ii)(B)", - "164.520(a)(2)(iii)", - "164.520(b)(1)", - "164.520(b)(1)(i)", - "164.520(b)(1)(ii)", - "164.520(b)(1)(ii)(A)", - "164.520(b)(1)(ii)(B)", - "164.520(b)(1)(ii)(C)", - "164.520(b)(1)(ii)(D)", - "164.520(b)(1)(ii)(E)", - "164.520(b)(1)(iv)", - "164.520(b)(1)(iv)(A)", - "164.520(b)(1)(iv)(B)", - "164.520(b)(1)(iv)(C)", - "164.520(b)(1)(iv)(D)", - "164.520(b)(1)(iv)(E)", - "164.520(b)(1)(iv)(F)", - "164.520(b)(1)(v)", - "164.520(b)(1)(v)(A)", - "164.520(b)(1)(v)(B)", - "164.520(b)(1)(v)(C)", - "164.520(b)(1)(vi)", - "164.520(b)(1)(vii)", - "164.520(b)(1)(viii)", - "164.520(b)(2)(i)", - "164.520(b)(2)(ii)", - "164.520(b)(3)", - "164.520(c)", - "164.520(c)(1)(i)", - "164.520(c)(1)(i)(A)", - "164.520(c)(1)(i)(B)", - "164.520(c)(1)(ii)", - "164.520(c)(1)(iii)", - "164.520(c)(1)(iv)", - "164.520(c)(1)(v)", - "164.520(c)(1)(v)(A)", - "164.520(c)(1)(v)(B)", - "164.530(i)(4)(i)(C)" + "§ 164.520(a)(1)", + "§ 164.520(a)(2)(i)", + "§ 164.520(a)(2)(i)(A)", + "§ 164.520(a)(2)(i)(B)", + "§ 164.520(a)(2)(ii)", + "§ 164.520(a)(2)(ii)(A)", + "§ 164.520(a)(2)(ii)(B)", + "§ 164.520(a)(2)(iii)", + "§ 164.520(b)(1)", + "§ 164.520(b)(1)(i)", + "§ 164.520(b)(1)(ii)", + "§ 164.520(b)(1)(ii)(A)", + "§ 164.520(b)(1)(ii)(B)", + "§ 164.520(b)(1)(ii)(C)", + "§ 164.520(b)(1)(ii)(D)", + "§ 164.520(b)(1)(ii)(E)", + "§ 164.520(b)(1)(iv)", + "§ 164.520(b)(1)(iv)(A)", + "§ 164.520(b)(1)(iv)(B)", + "§ 164.520(b)(1)(iv)(C)", + "§ 164.520(b)(1)(iv)(D)", + "§ 164.520(b)(1)(iv)(E)", + "§ 164.520(b)(1)(iv)(F)", + "§ 164.520(b)(1)(v)", + "§ 164.520(b)(1)(v)(A)", + "§ 164.520(b)(1)(v)(B)", + "§ 164.520(b)(1)(v)(C)", + "§ 164.520(b)(1)(vi)", + "§ 164.520(b)(1)(vii)", + "§ 164.520(b)(1)(viii)", + "§ 164.520(b)(2)(i)", + "§ 164.520(b)(2)(ii)", + "§ 164.520(b)(3)", + "§ 164.520(c)", + "§ 164.520(c)(1)(i)", + "§ 164.520(c)(1)(i)(A)", + "§ 164.520(c)(1)(i)(B)", + "§ 164.520(c)(1)(ii)", + "§ 164.520(c)(1)(iii)", + "§ 164.520(c)(1)(iv)", + "§ 164.520(c)(1)(v)", + "§ 164.520(c)(1)(v)(A)", + "§ 164.520(c)(1)(v)(B)", + "§ 164.530(i)(4)(i)(C)" ], "PRI-02.1": [ - "164.502(a)(3)", - "164.508(c)(1)(i)", - "164.508(c)(1)(ii)", - "164.508(c)(1)(iii)", - "164.508(c)(1)(iv)", - "164.508(c)(2)(i)(A)", - "164.508(c)(2)(i)(B)" + "§ 164.502(a)(3)", + "§ 164.508(c)(1)(i)", + "§ 164.508(c)(1)(ii)", + "§ 164.508(c)(1)(iii)", + "§ 164.508(c)(1)(iv)", + "§ 164.508(c)(2)(i)(A)", + "§ 164.508(c)(2)(i)(B)" ], "PRI-03": [ - "164.506(b)(1)", - "164.508(a)(2)", - "164.508(c)(1)(v)", - "164.508(c)(3)", - "164.510(b)(2)(i)", - "164.510(b)(2)(ii)", - "164.510(b)(2)(iii)", - "164.510(b)(3)", - "164.514(f)(2)(ii)", - "164.514(f)(2)(iv)", - "164.514(f)(2)(v)" + "§ 164.506(b)(1)", + "§ 164.508(a)(2)", + "§ 164.508(c)(1)(v)", + "§ 164.508(c)(3)", + "§ 164.510(b)(2)(i)", + "§ 164.510(b)(2)(ii)", + "§ 164.510(b)(2)(iii)", + "§ 164.510(b)(3)", + "§ 164.514(f)(2)(ii)", + "§ 164.514(f)(2)(iv)", + "§ 164.514(f)(2)(v)" ], "PRI-03.3": [ - "164.502(a)(5)(ii)(A)" + "§ 164.502(a)(5)(ii)(A)" ], "PRI-03.5": [ - "164.508(c)(2)(ii)(A)", - "164.508(c)(2)(ii)(B)", - "164.514(f)(2)(iii)" + "§ 164.508(c)(2)(ii)(A)", + "§ 164.508(c)(2)(ii)(B)", + "§ 164.514(f)(2)(iii)" ], "PRI-03.6": [ - "164.502(g)(1)", - "164.502(g)(2)", - "164.502(g)(3)(i)", - "164.502(g)(3)(i)(A)" + "§ 164.502(g)(1)", + "§ 164.502(g)(2)", + "§ 164.502(g)(3)(i)", + "§ 164.502(g)(3)(i)(A)" ], "PRI-04.1": [ - "164.502(a)(1)(i)", - "164.502(a)(1)(ii)", - "164.502(a)(1)(iii)", - "164.502(a)(5)(i)", - "164.502(i)" + "§ 164.502(a)(1)(i)", + "§ 164.502(a)(1)(ii)", + "§ 164.502(a)(1)(iii)", + "§ 164.502(a)(5)(i)", + "§ 164.502(i)" ], "PRI-05.1": [ - "164.508(a)(2)(i)(B)" + "§ 164.508(a)(2)(i)(B)" ], "PRI-05.4": [ - "164.502(c)", - "164.502(d)(1)", - "164.504(g)(2)", - "164.506(a)", - "164.506(c)(1)", - "164.506(c)(5)", - "164.508(a)(1)", - "164.508(a)(2)(i)(C)", - "164.510(a)(1)(i)(A)", - "164.510(a)(1)(i)(B)", - "164.510(a)(1)(i)(C)", - "164.510(a)(1)(i)(D)", - "164.510(a)(1)(ii)(A)", - "164.510(a)(1)(ii)(B)", - "164.510(b)(4)", - "164.512", - "164.512(i)(1)", - "164.512(j)(1)", - "164.512(j)(1)(i)(A)", - "164.512(j)(1)(i)(B)", - "164.512(j)(1)(ii)", - "164.512(j)(1)(ii)(A)", - "164.512(j)(1)(ii)(B)", - "164.512(j)(2)(i)", - "164.512(j)(2)(ii)", - "164.512(j)(3)", - "164.512(j)(4)", - "164.512(k)(1)(i)", - "164.512(k)(1)(i)(A)", - "164.512(k)(1)(i)(B)", - "164.512(k)(1)(ii)", - "164.512(k)(1)(iii)", - "164.512(k)(1)(iv)", - "164.512(k)(2)", - "164.512(k)(3)", - "164.512(k)(4)", - "164.512(k)(4)(i)", - "164.512(k)(4)(ii)", - "164.512(k)(4)(iii)", - "164.512(k)(5)(i)", - "164.512(k)(5)(i)(A)", - "164.512(k)(5)(i)(B)", - "164.512(k)(5)(i)(C)", - "164.512(k)(5)(i)(D)", - "164.512(k)(5)(i)(E)", - "164.512(k)(5)(i)(F)", - "164.512(k)(5)(ii)", - "164.512(k)(5)(iii)", - "164.512(k)(6)(i)", - "164.512(k)(6)(ii)", - "164.512(k)(6)(ii)(1)", - "164.514(f)(2)(i)", - "164.514(g)", - "164.530(i)(4)(ii)", - "164.530(i)(4)(ii)(B)", - "164.532(a)", - "164.532(b)", - "164.532(c)" + "§ 164.502(c)", + "§ 164.502(d)(1)", + "§ 164.504(g)(2)", + "§ 164.506(a)", + "§ 164.506(c)(1)", + "§ 164.506(c)(5)", + "§ 164.508(a)(1)", + "§ 164.508(a)(2)(i)(C)", + "§ 164.510(a)(1)(i)(A)", + "§ 164.510(a)(1)(i)(B)", + "§ 164.510(a)(1)(i)(C)", + "§ 164.510(a)(1)(i)(D)", + "§ 164.510(a)(1)(ii)(A)", + "§ 164.510(a)(1)(ii)(B)", + "§ 164.510(b)(4)", + "§ 164.512", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.512(j)(1)(i)(A)", + "§ 164.512(j)(1)(i)(B)", + "§ 164.512(j)(1)(ii)", + "§ 164.512(j)(1)(ii)(A)", + "§ 164.512(j)(1)(ii)(B)", + "§ 164.512(j)(2)(i)", + "§ 164.512(j)(2)(ii)", + "§ 164.512(j)(3)", + "§ 164.512(j)(4)", + "§ 164.512(k)(1)(i)", + "§ 164.512(k)(1)(i)(A)", + "§ 164.512(k)(1)(i)(B)", + "§ 164.512(k)(1)(ii)", + "§ 164.512(k)(1)(iii)", + "§ 164.512(k)(1)(iv)", + "§ 164.512(k)(2)", + "§ 164.512(k)(3)", + "§ 164.512(k)(4)", + "§ 164.512(k)(4)(i)", + "§ 164.512(k)(4)(ii)", + "§ 164.512(k)(4)(iii)", + "§ 164.512(k)(5)(i)", + "§ 164.512(k)(5)(i)(A)", + "§ 164.512(k)(5)(i)(B)", + "§ 164.512(k)(5)(i)(C)", + "§ 164.512(k)(5)(i)(D)", + "§ 164.512(k)(5)(i)(E)", + "§ 164.512(k)(5)(i)(F)", + "§ 164.512(k)(5)(ii)", + "§ 164.512(k)(5)(iii)", + "§ 164.512(k)(6)(i)", + "§ 164.512(k)(6)(ii)", + "§ 164.512(k)(6)(ii)(1)", + "§ 164.514(f)(2)(i)", + "§ 164.514(g)", + "§ 164.530(i)(4)(ii)", + "§ 164.530(i)(4)(ii)(B)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)" ], "PRI-06": [ - "164.502(a)(2)(i)", - "164.502(a)(2)(ii)", - "164.514(h)(1)(i)", - "164.514(h)(1)(ii)", - "164.524(a)(1)", - "164.524(a)(1)(i)", - "164.524(a)(1)(ii)", - "164.524(a)(1)(iii)", - "164.524(a)(1)(iii)(A)", - "164.524(a)(1)(iii)(B)", - "164.524(a)(2)", - "164.524(a)(2)(i)", - "164.524(a)(2)(ii)", - "164.524(a)(2)(iii)", - "164.524(a)(2)(iv)", - "164.524(a)(2)(v)", - "164.524(a)(3)", - "164.524(a)(3)(i)", - "164.524(a)(3)(ii)", - "164.524(a)(3)(iii)", - "164.524(a)(4)", - "164.524(b)(1)", - "164.524(b)(2)(i)", - "164.524(b)(2)(i)(A)", - "164.524(b)(2)(i)(B)", - "164.524(b)(2)(ii)", - "164.524(b)(2)(ii)(A)", - "164.524(b)(2)(ii)(B)", - "164.524(c)", - "164.524(c)(1)", - "164.524(c)(3)(i)", - "164.524(c)(3)(ii)", - "164.524(c)(4)", - "164.524(c)(4)(i)", - "164.524(c)(4)(ii)", - "164.524(c)(4)(iii)", - "164.524(c)(4)(iv)", - "164.524(d)", - "164.524(d)(1)", - "164.524(d)(2)" + "§ 164.502(a)(2)(i)", + "§ 164.502(a)(2)(ii)", + "§ 164.514(h)(1)(i)", + "§ 164.514(h)(1)(ii)", + "§ 164.524(a)(1)", + "§ 164.524(a)(1)(i)", + "§ 164.524(a)(1)(ii)", + "§ 164.524(a)(1)(iii)", + "§ 164.524(a)(1)(iii)(A)", + "§ 164.524(a)(1)(iii)(B)", + "§ 164.524(a)(2)", + "§ 164.524(a)(2)(i)", + "§ 164.524(a)(2)(ii)", + "§ 164.524(a)(2)(iii)", + "§ 164.524(a)(2)(iv)", + "§ 164.524(a)(2)(v)", + "§ 164.524(a)(3)", + "§ 164.524(a)(3)(i)", + "§ 164.524(a)(3)(ii)", + "§ 164.524(a)(3)(iii)", + "§ 164.524(a)(4)", + "§ 164.524(b)(1)", + "§ 164.524(b)(2)(i)", + "§ 164.524(b)(2)(i)(A)", + "§ 164.524(b)(2)(i)(B)", + "§ 164.524(b)(2)(ii)", + "§ 164.524(b)(2)(ii)(A)", + "§ 164.524(b)(2)(ii)(B)", + "§ 164.524(c)", + "§ 164.524(c)(1)", + "§ 164.524(c)(3)(i)", + "§ 164.524(c)(3)(ii)", + "§ 164.524(c)(4)", + "§ 164.524(c)(4)(i)", + "§ 164.524(c)(4)(ii)", + "§ 164.524(c)(4)(iii)", + "§ 164.524(c)(4)(iv)", + "§ 164.524(d)", + "§ 164.524(d)(1)", + "§ 164.524(d)(2)" ], "PRI-06.1": [ - "164.526(a)(1)", - "164.526(a)(2)", - "164.526(a)(2)(i)", - "164.526(a)(2)(ii)", - "164.526(a)(2)(iii)", - "164.526(a)(2)(iv)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(a)(2)", + "§ 164.526(a)(2)(i)", + "§ 164.526(a)(2)(ii)", + "§ 164.526(a)(2)(iii)", + "§ 164.526(a)(2)(iv)", + "§ 164.526(b)(1)" ], "PRI-06.2": [ - "164.526(c)", - "164.526(c)(1)", - "164.526(c)(2)", - "164.526(c)(3)", - "164.526(c)(3)(i)", - "164.526(c)(3)(ii)" + "§ 164.526(c)", + "§ 164.526(c)(1)", + "§ 164.526(c)(2)", + "§ 164.526(c)(3)", + "§ 164.526(c)(3)(i)", + "§ 164.526(c)(3)(ii)" ], "PRI-06.3": [ - "164.524(d)(4)" + "§ 164.524(d)(4)" ], "PRI-06.4": [ - "164.526(b)(2)(i)", - "164.526(b)(2)(i)(A)", - "164.526(b)(2)(i)(B)", - "164.526(b)(2)(ii)", - "164.526(b)(2)(ii)(A)", - "164.526(b)(2)(ii)(B)", - "164.526(d)", - "164.526(d)(1)", - "164.526(d)(1)(i)", - "164.526(d)(1)(ii)", - "164.526(d)(1)(iii)", - "164.526(d)(1)(iv)", - "164.526(d)(2)", - "164.526(d)(3)", - "164.526(d)(4)", - "164.526(d)(5)(i)", - "164.526(d)(5)(ii)", - "164.526(d)(5)(iii)", - "164.526(e)", - "164.526(f)", - "164.530(d)(1)", - "164.530(d)(2)" + "§ 164.526(b)(2)(i)", + "§ 164.526(b)(2)(i)(A)", + "§ 164.526(b)(2)(i)(B)", + "§ 164.526(b)(2)(ii)", + "§ 164.526(b)(2)(ii)(A)", + "§ 164.526(b)(2)(ii)(B)", + "§ 164.526(d)", + "§ 164.526(d)(1)", + "§ 164.526(d)(1)(i)", + "§ 164.526(d)(1)(ii)", + "§ 164.526(d)(1)(iii)", + "§ 164.526(d)(1)(iv)", + "§ 164.526(d)(2)", + "§ 164.526(d)(3)", + "§ 164.526(d)(4)", + "§ 164.526(d)(5)(i)", + "§ 164.526(d)(5)(ii)", + "§ 164.526(d)(5)(iii)", + "§ 164.526(e)", + "§ 164.526(f)", + "§ 164.530(d)(1)", + "§ 164.530(d)(2)" ], "PRI-06.6": [ - "164.524(c)(2)(i)", - "164.524(c)(2)(ii)" + "§ 164.524(c)(2)(i)", + "§ 164.524(c)(2)(ii)" ], "PRI-07": [ - "164.506(c)(1)", - "164.506(c)(2)", - "164.506(c)(3)", - "164.506(c)(4)", - "164.508(a)(1)", - "164.508(a)(4)(i)" + "§ 164.506(c)(1)", + "§ 164.506(c)(2)", + "§ 164.506(c)(3)", + "§ 164.506(c)(4)", + "§ 164.508(a)(1)", + "§ 164.508(a)(4)(i)" ], "PRI-07.1": [ - "164.504(e)(2)(i)", - "164.504(e)(2)(ii)(A)", - "164.504(e)(2)(ii)(B)", - "164.504(e)(2)(ii)(C)", - "164.504(e)(4)(i)", - "164.504(e)(4)(i)(A)", - "164.504(e)(4)(i)(B)", - "164.504(e)(4)(i)(B)(ii)", - "164.504(e)(4)(i)(B)(ii)(A)" + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(ii)(A)", + "§ 164.504(e)(2)(ii)(B)", + "§ 164.504(e)(2)(ii)(C)", + "§ 164.504(e)(4)(i)", + "§ 164.504(e)(4)(i)(A)", + "§ 164.504(e)(4)(i)(B)", + "§ 164.504(e)(4)(i)(B)(ii)", + "§ 164.504(e)(4)(i)(B)(ii)(A)" ], "PRI-07.4": [ - "164.524(d)(2)(i)", - "164.524(d)(2)(ii)", - "164.524(d)(2)(iii)", - "164.524(d)(3)" + "§ 164.524(d)(2)(i)", + "§ 164.524(d)(2)(ii)", + "§ 164.524(d)(2)(iii)", + "§ 164.524(d)(3)" ], "PRI-10": [ - "164.512(i)(1)(i)(B)", - "164.512(i)(1)(i)(B)(1)", - "164.512(i)(1)(i)(B)(2)", - "164.512(i)(1)(i)(B)(3)" + "§ 164.512(i)(1)(i)(B)", + "§ 164.512(i)(1)(i)(B)(1)", + "§ 164.512(i)(1)(i)(B)(2)", + "§ 164.512(i)(1)(i)(B)(3)" ], "PRI-12": [ - "164.526(a)(1)", - "164.526(b)(1)", - "164.526(e)", - "164.526(f)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)", + "§ 164.526(e)", + "§ 164.526(f)" ], "PRI-14.1": [ - "164.528(a)(1)", - "164.528(a)(1)(i)", - "164.528(a)(1)(ii)", - "164.528(a)(1)(iii)", - "164.528(a)(1)(iv)", - "164.528(a)(1)(v)", - "164.528(a)(1)(vi)", - "164.528(a)(1)(vii)", - "164.528(a)(1)(viii)", - "164.528(a)(1)(ix)", - "164.528(b)", - "164.528(b)(1)", - "164.528(b)(2)", - "164.528(b)(2)(i)", - "164.528(b)(2)(ii)", - "164.528(b)(2)(iii)", - "164.528(b)(2)(iv)", - "164.528(b)(3)", - "164.528(b)(3)(i)", - "164.528(b)(3)(ii)", - "164.528(b)(3)(iii)", - "164.528(b)(4)(i)", - "164.528(b)(4)(i)(A)", - "164.528(b)(4)(i)(B)", - "164.528(b)(4)(i)(C)", - "164.528(b)(4)(i)(D)", - "164.528(b)(4)(i)(E)", - "164.528(b)(4)(i)(F)", - "164.528(b)(4)(ii)", - "164.528(c)(1)", - "164.528(c)(1)(i)", - "164.528(c)(1)(ii)", - "164.528(c)(1)(ii)(A)", - "164.528(c)(1)(ii)(B)", - "164.528(c)(2)", - "164.528(d)", - "164.528(d)(1)", - "164.528(d)(2)", - "164.528(d)(3)" + "§ 164.528(a)(1)", + "§ 164.528(a)(1)(i)", + "§ 164.528(a)(1)(ii)", + "§ 164.528(a)(1)(iii)", + "§ 164.528(a)(1)(iv)", + "§ 164.528(a)(1)(v)", + "§ 164.528(a)(1)(vi)", + "§ 164.528(a)(1)(vii)", + "§ 164.528(a)(1)(viii)", + "§ 164.528(a)(1)(ix)", + "§ 164.528(b)", + "§ 164.528(b)(1)", + "§ 164.528(b)(2)", + "§ 164.528(b)(2)(i)", + "§ 164.528(b)(2)(ii)", + "§ 164.528(b)(2)(iii)", + "§ 164.528(b)(2)(iv)", + "§ 164.528(b)(3)", + "§ 164.528(b)(3)(i)", + "§ 164.528(b)(3)(ii)", + "§ 164.528(b)(3)(iii)", + "§ 164.528(b)(4)(i)", + "§ 164.528(b)(4)(i)(A)", + "§ 164.528(b)(4)(i)(B)", + "§ 164.528(b)(4)(i)(C)", + "§ 164.528(b)(4)(i)(D)", + "§ 164.528(b)(4)(i)(E)", + "§ 164.528(b)(4)(i)(F)", + "§ 164.528(b)(4)(ii)", + "§ 164.528(c)(1)", + "§ 164.528(c)(1)(i)", + "§ 164.528(c)(1)(ii)", + "§ 164.528(c)(1)(ii)(A)", + "§ 164.528(c)(1)(ii)(B)", + "§ 164.528(c)(2)", + "§ 164.528(d)", + "§ 164.528(d)(1)", + "§ 164.528(d)(2)", + "§ 164.528(d)(3)" ], "PRM-03": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "PRM-05": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "PRM-06": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "RSK-01": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "RSK-01.1": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-02": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-03": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-03.1": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-04": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "RSK-06.2": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "SEA-01": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "SEA-02": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "SEA-02.1": [ - "164.103", - "164.304", - "164.402", - "164.501", - "164.504(a)" + "§ 164.103", + "§ 164.304", + "§ 164.402", + "§ 164.501", + "§ 164.504(a)" ], "SEA-03": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "OPS-01.1": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "OPS-03": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "SAT-01": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "SAT-02": [ - "164.308(a)(5)(i)", - "164.530(b)(2)(i)", - "164.530(b)(2)(i)(A)", - "164.530(b)(2)(i)(B)", - "164.530(b)(2)(i)(C)", - "164.530(b)(2)(ii)" + "§ 164.308(a)(5)(i)", + "§ 164.530(b)(2)(i)", + "§ 164.530(b)(2)(i)(A)", + "§ 164.530(b)(2)(i)(B)", + "§ 164.530(b)(2)(i)(C)", + "§ 164.530(b)(2)(ii)" ], "SAT-03": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)", - "164.530(b)(1)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)", + "§ 164.530(b)(1)" ], "SAT-03.2": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "SAT-03.6": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "TPM-01": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "TPM-02": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "TPM-04": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "TPM-05": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)", - "164.502(a)(4)(i)", - "164.502(a)(4)(ii)", - "164.502(e)(1)(i)", - "164.502(e)(2)", - "164.504(e)(2)(i)", - "164.504(e)(2)(i)(A)", - "164.504(e)(2)(i)(B)", - "164.504(e)(2)(ii)(J)", - "164.504(e)(4)(i)(B)(ii)(B)(1)", - "164.504(e)(4)(i)(B)(ii)(B)(2)", - "164.504(f)(1)(i)", - "164.504(f)(2)(i)", - "164.504(f)(2)(ii)", - "164.504(f)(2)(ii)(A)", - "164.504(f)(2)(ii)(B)", - "164.504(f)(2)(ii)(C)", - "164.504(f)(2)(ii)(D)", - "164.504(f)(2)(ii)(E)", - "164.504(f)(2)(ii)(F)", - "164.504(f)(2)(ii)(G)", - "164.504(f)(2)(ii)(H)", - "164.504(f)(2)(ii)(I)", - "164.504(f)(2)(ii)(J)", - "164.504(f)(2)(iii)(A)", - "164.504(f)(2)(iii)(B)", - "164.504(f)(2)(iii)(C)", - "164.504(f)(3)(i)", - "164.504(f)(3)(ii)", - "164.504(f)(3)(iii)", - "164.504(f)(3)(iv)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)", + "§ 164.502(a)(4)(i)", + "§ 164.502(a)(4)(ii)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(2)", + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(i)(A)", + "§ 164.504(e)(2)(i)(B)", + "§ 164.504(e)(2)(ii)(J)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(1)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(2)", + "§ 164.504(f)(1)(i)", + "§ 164.504(f)(2)(i)", + "§ 164.504(f)(2)(ii)", + "§ 164.504(f)(2)(ii)(A)", + "§ 164.504(f)(2)(ii)(B)", + "§ 164.504(f)(2)(ii)(C)", + "§ 164.504(f)(2)(ii)(D)", + "§ 164.504(f)(2)(ii)(E)", + "§ 164.504(f)(2)(ii)(F)", + "§ 164.504(f)(2)(ii)(G)", + "§ 164.504(f)(2)(ii)(H)", + "§ 164.504(f)(2)(ii)(I)", + "§ 164.504(f)(2)(ii)(J)", + "§ 164.504(f)(2)(iii)(A)", + "§ 164.504(f)(2)(iii)(B)", + "§ 164.504(f)(2)(iii)(C)", + "§ 164.504(f)(3)(i)", + "§ 164.504(f)(3)(ii)", + "§ 164.504(f)(3)(iii)", + "§ 164.504(f)(3)(iv)" ], "TPM-05.1": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)", - "164.410(a)(1)", - "164.410(a)(2)", - "164.410(b)", - "164.410(c)(2)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)", + "§ 164.410(a)(1)", + "§ 164.410(a)(2)", + "§ 164.410(b)", + "§ 164.410(c)(2)" ], "TPM-05.2": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)", - "164.502(e)(1)(ii)", - "164.504(e)(2)(ii)(D)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)", + "§ 164.502(e)(1)(ii)", + "§ 164.504(e)(2)(ii)(D)" ], "TPM-05.4": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "TPM-05.6": [ - "164.308(b)(2)", - "164.502(e)(1)(i)", - "164.502(e)(1)(ii)" + "§ 164.308(b)(2)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(1)(ii)" ], "TPM-05.7": [ - "164.504(e)(2)(iii)" + "§ 164.504(e)(2)(iii)" ], "THR-09": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "THR-10": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ] }, "usa-federal-law-hipaa-security-rule-2013": { "GOV-01": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)" ], "GOV-02": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)" ], "GOV-02.1": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "GOV-03": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)" ], "GOV-04": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "GOV-08": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "GOV-09": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "GOV-15": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "GOV-15.1": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.2": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "GOV-15.3": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.4": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.5": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "AST-01": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "AST-01.1": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "AST-02": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-02.1": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-02.9": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-03": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-03.1": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-09": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "AST-11": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "BCD-01": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "BCD-02": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "BCD-02.2": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "BCD-04": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "BCD-05": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "BCD-09.2": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "BCD-11": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "BCD-12": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "CHG-01": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "CPL-01": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)" ], "CPL-02": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "CPL-03": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "CPL-03.2": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "CFG-01": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "CFG-02": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "CFG-08": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "CFG-08.1": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "MON-01.4": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-01.7": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01.8": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "MON-01.15": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01.16": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-03": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-03.2": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-16": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "CRY-01": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "CRY-03": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "CRY-04": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "DCH-01": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)" ], "DCH-01.2": [ - "164.312(c)(1)" + "§ 164.312(c)(1)" ], "DCH-03": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-07": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-07.1": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-09": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "DCH-13.2": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-18": [ - "164.316(b)(2)(i)" + "§ 164.316(b)(2)(i)" ], "END-01": [ - "164.310(b)" + "§ 164.310(b)" ], "END-02": [ - "164.310(c)" + "§ 164.310(c)" ], "HRS-01": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)" ], "HRS-02": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)" ], "HRS-03": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)" ], "HRS-04": [ - "164.312(d)" + "§ 164.312(d)" ], "HRS-05": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.1": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.3": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-07": [ - "164.308(a)(1)(ii)(C)" + "§ 164.308(a)(1)(ii)(C)" ], "HRS-08": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "HRS-09": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-01": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)" ], "IAC-02": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "IAC-07": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-07.1": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "IAC-07.2": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-08": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)" ], "IAC-09": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "IAC-15": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-15.2": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-15.9": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-17": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "IAC-21": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "IAC-25": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "IAC-28": [ - "164.312(d)" + "§ 164.312(d)" ], "IAC-28.1": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "IAC-28.2": [ - "164.312(d)" + "§ 164.312(d)" ], "IAC-28.3": [ - "164.312(d)" + "§ 164.312(d)" ], "IRO-01": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "IRO-02": [ - "164.308(a)(6)(ii)" + "§ 164.308(a)(6)(ii)" ], "IRO-09": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "IAO-01.1": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "IAO-02": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "IAO-03.2": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "MNT-01": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "MNT-02": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "MNT-04.3": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "NET-01": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "PES-01": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "PES-02": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "PES-02.1": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "PES-03": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "PES-03.4": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "PES-04": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "PES-04.1": [ - "164.310(c)" + "§ 164.310(c)" ], "PES-06": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "PRM-03": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "PRM-05": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "PRM-06": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "RSK-01": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "RSK-01.1": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-02": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-03": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-03.1": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-04": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "RSK-06.2": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "SEA-01": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "SEA-02": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "SEA-03": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "OPS-01.1": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "OPS-03": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "SAT-01": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "SAT-02": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "SAT-03": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)" ], "SAT-03.2": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "SAT-03.6": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "TPM-01": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "TPM-02": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "TPM-04": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "TPM-05": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)" ], "TPM-05.1": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)" ], "TPM-05.2": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)" ], "TPM-05.4": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "TPM-05.6": [ - "164.308(b)(2)" + "§ 164.308(b)(2)" ], "THR-09": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "THR-10": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ] }, "usa-federal-irs-1075-2021": { @@ -85659,8 +87726,12 @@ "PE-8" ], "PES-04": [ + "2.B.3", "2.B.3.3" ], + "PES-04.1": [ + "2.B.3" + ], "PES-05": [ "PE-6" ], @@ -86360,6 +88431,9 @@ "CP-10-IS.1.d", "CP-10-IS.1.e" ], + "BCD-12.1": [ + "CP-10(2)" + ], "CAP-01": [ "SC-5" ], @@ -91668,6 +93742,197 @@ "17.04(7)" ] }, + "usa-state-nv-privacy-law-2023": { + "GOV-02": [ + "603A.525.2", + "603A.525.2(a)" + ], + "GOV-15": [ + "603A.210.2", + "603A.215.1" + ], + "GOV-15.1": [ + "603A.210.2", + "603A.215.1" + ], + "GOV-15.2": [ + "603A.210.2", + "603A.215.1" + ], + "CPL-01": [ + "603A.500.2(c)", + "603A.525.2(b)" + ], + "CRY-03": [ + "603A.215.2(a)" + ], + "DCH-01": [ + "603A.200.1" + ], + "DCH-01.1": [ + "603A.215.2(b)" + ], + "DCH-01.2": [ + "603A.215.2(b)" + ], + "DCH-03.1": [ + "603A.495.3(b)", + "603A.500.2" + ], + "DCH-08": [ + "603A.200.1" + ], + "DCH-18": [ + "603A.200.1" + ], + "DCH-21": [ + "603A.200.1" + ], + "IRO-10": [ + "603A.220.1", + "603A.220.2", + "603A.220.3", + "603A.220.4", + "603A.220.4(a)", + "603A.220.4(b)", + "603A.220.4(c)", + "603A.220.4(c)(1)", + "603A.220.4(c)(2)", + "603A.220.4(c)(3)", + "603A.220.6" + ], + "PRI-01.6": [ + "603A.210.1" + ], + "PRI-01.11": [ + "603A.210.1", + "603A.510.3(b)", + "603A.525.1", + "603A.525.1(a)", + "603A.525.1(b)", + "603A.525.2(c)" + ], + "PRI-02": [ + "603A.340.1", + "603A.340.1(b)", + "603A.340.1(c)", + "603A.340.1(d)", + "603A.340.1(e)", + "603A.345.1", + "603A.346.1", + "603A.495.1", + "603A.495.1(a)", + "603A.495.1(b)", + "603A.495.1(c)", + "603A.495.1(d)", + "603A.495.1(e)", + "603A.495.1(f)", + "603A.495.1(g)", + "603A.495.1(h)", + "603A.495.1(i)", + "603A.495.1(j)", + "603A.495.1(k)", + "603A.495.2" + ], + "PRI-03": [ + "603A.500.2(a)", + "603A.500.2(b)", + "603A.500.3", + "603A.500.3(a)", + "603A.500.3(b)", + "603A.500.3(c)", + "603A.500.3(d)", + "603A.535.5", + "603A.535.6", + "603A.535.6(a)", + "603A.535.6(b)", + "603A.535.6(c)", + "603A.535.6(d)", + "603A.535.7" + ], + "PRI-03.4": [ + "603A.500.3(d)", + "603A.505.1(c)", + "603A.535.4" + ], + "PRI-03.5": [ + "603A.535.2" + ], + "PRI-04": [ + "603A.495.3(a)", + "603A.495.3(c)", + "603A.500.1(a)", + "603A.500.1(b)", + "603A.535.1", + "603A.535.1(a)", + "603A.535.1(b)" + ], + "PRI-05.7": [ + "603A.340.1(a)" + ], + "PRI-06": [ + "603A.345.2", + "603A.346.2", + "603A.505.1(a)", + "603A.505.1(b)", + "603A.505.2", + "603A.505.2(a)", + "603A.510.3(a)(1)", + "603A.510.3(a)(2)" + ], + "PRI-06.3": [ + "603A.520.1", + "603A.520.1(a)", + "603A.520.1(b)", + "603A.520.2", + "603A.520.2(a)", + "603A.520.2(b)", + "603A.520.2(c)" + ], + "PRI-06.4": [ + "603A.345.3", + "603A.345.4", + "603A.346.3", + "603A.346.4", + "603A.510.1", + "603A.510.2", + "603A.510.2(a)", + "603A.510.2(b)" + ], + "PRI-06.5": [ + "603A.505.1(d)", + "603A.515.1", + "603A.515.1(a)", + "603A.515.1(b)", + "603A.515.2", + "603A.515.3" + ], + "PRI-06.8": [ + "603A.505.2(b)" + ], + "PRI-07.1": [ + "603A.210.3", + "603A.495.3(d)", + "603A.530.1", + "603A.530.2", + "603A.530.3", + "603A.530.3(a)", + "603A.530.3(b)" + ], + "PRI-14": [ + "603A.535.3", + "603A.535.3(a)", + "603A.535.3(b)", + "603A.535.3(c)", + "603A.535.3(d)", + "603A.535.3(e)", + "603A.535.3(f)", + "603A.535.3(g)", + "603A.535.3(h)", + "603A.535.3(i)", + "603A.535.8" + ] + }, "usa-state-nv-regulation-5-2024": { "GOV-01": [ "5.260.1" @@ -96546,996 +98811,932 @@ "Article 53.1(a)" ] }, - "emea-eu-cyber-resilience-act-2022": { + "emea-eu-cyber-resilience-act-2024": { + "GOV-17": [ + "Article 13(23)", + "Article 19(8)", + "Article 20(6)" + ], + "AAT-09.1": [ + "Article 12(1)" + ], + "CPL-01": [ + "Article 6", + "Article 6(a)", + "Article 6(b)", + "Article 12(1)(a)", + "Article 12(1)(b)", + "Article 19(7)", + "Article 23(1)", + "Article 23(1)(a)", + "Article 23(1)(b)", + "Article 24(2)" + ], "CPL-01.3": [ - "Article 10.13" + "Article 13(1)", + "Article 32(5)" ], "CPL-01.4": [ - "Article 10.2", - "Article 10.7", - "Article 13.2(a)", - "Article 24.1", - "Article 24.1(a)", - "Article 24.1(b)", - "Article 24.1(c)" + "Article 12(3)", + "Article 13(12)", + "Article 19(2)(a)", + "Article 32(1)", + "Article 32(1)(a)", + "Article 32(1)(b)", + "Article 32(1)(c)", + "Article 32(1)(d)", + "Article 32(3)", + "Article 32(3)(a)", + "Article 32(3)(b)", + "Article 32(6)" ], - "CPL-02.3": [ - "Article 10.12", - "Article 13.6", - "Article 14.4" + "CPL-01.5": [ + "Article 12(1)(c)", + "Article 20(5)" ], - "CPL-03.3": [ - "Article 13.8", - "Article 14.5" + "CPL-01.7": [ + "Article 18(1)" ], - "CPL-08": [ - "Article 12.1" + "CPL-05.2": [ + "Article 53" ], - "CPL-08.1": [ - "Article 12.3", - "Article 12.3(a)", - "Article 12.3(b)", - "Article 12.3(c)" + "CPL-07": [ + "Article 13(17)" ], "DCH-18": [ - "Article 10.8", - "Article 13.7" + "Article 13(13)", + "Article 19(6)", + "Article 23(2)" ], - "IRO-10.5": [ - "Article 11.2", - "Article 11.4" + "IRO-02.4": [ + "Article 14(5)", + "Article 14(5)(a)", + "Article 14(5)(b)" ], - "SEA-02.1": [ - "Article 3" + "IRO-10": [ + "Article 14(8)", + "Article 15(1)", + "Article 15(2)" ], - "TDA-01.1": [ - "Article 5", - "Article 5.1", - "Article 5.2", - "Article 10.1", - "Article 10.5", - "Article 10.6", - "Article 10.9", - "Article 10.10", - "Article 10.11", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.3", - "Article 13.4", - "Article 13.5", - "Article 13.6", - "Article 14.1", - "Article 14.2", - "Article 14.2(a)", - "Article 14.2(b)", - "Article 14.3", - "Article 14.4" + "IRO-10.2": [ + "Article 14(1)", + "Article 14(3)", + "Article 14(4)(a)", + "Article 14(4)(b)", + "Article 14(4)(c)", + "Article 14(4)(i)", + "Article 14(4)(i)(ii)", + "Article 14(4)(i)(iii)" ], - "TDA-02.9": [ - "Article 10.6" + "IAO-01": [ + "Article 13(2)" ], - "TDA-02.11": [ - "Article 11.7" + "IAO-01.1": [ + "Article 13(2)" ], - "TDA-02.13": [ - "Article 11.1" + "IAO-02": [ + "Article 13(2)", + "Article 32(1)" ], - "TDA-04.2": [ - "Article 11.7" + "IAO-02.1": [ + "Article 13(2)" ], - "TDA-21": [ - "Article 10.12" + "IAO-02.2": [ + "Article 13(2)", + "Article 13(3)", + "Article 32(1)" ], - "TDA-22": [ - "Article 10.7", - "Article 13.2(b)", - "Article 23.1", - "Article 23.2", - "Article 23.3", - "Article 23.4" + "IAO-02.4": [ + "Article 13(2)" ], - "TDA-22.1": [ - "Article 10.3" + "IAO-03": [ + "Article 13(2)", + "Article 13(3)", + "Article 13(7)", + "Article 19(2)(b)", + "Article 31(1)", + "Article 31(2)", + "Article 31(3)" ], - "TPM-03": [ - "Article 10.4" - ] - }, - "emea-eu-cyber-resilience-act-annexes-2022": { - "CPL-01.4": [ - "Annex 6 Module A.1" + "IAO-03.2": [ + "Article 24(1)" ], - "CPL-01.5": [ - "Annex 4", - "Annex 4.1", - "Annex 4.2", - "Annex 4.3", - "Annex 4.4", - "Annex 4.5", - "Annex 4.6", - "Annex 4.7", - "Annex 4.8", - "Annex 6 Module A.4", - "Annex 6 Module A.4.2", - "Annex 6 Module C.3.2" + "IAO-04": [ + "Article 13(6)", + "Article 13(21)" ], - "CPL-03.1": [ - "Annex 6 Module H.3.1", - "Annex 6 Module H.3.5" + "IAO-05": [ + "Article 13(2)" ], - "CPL-03.3": [ - "Annex 6 Module H.4.2" + "IAO-06": [ + "Article 13(2)" ], - "CPL-08": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" + "IAO-07": [ + "Article 13(2)" ], - "CPL-08.1": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" + "PRM-04": [ + "Article 13(14)" ], - "DCH-01.2": [ - "Annex 1.1(3)(e)" + "PRM-07": [ + "Article 13(14)" ], - "DCH-01.4": [ - "Annex 1.1(3)(e)" + "TDA-01.1": [ + "Article 13(1)", + "Article 13(5)", + "Article 13(8)", + "Article 13(10)", + "Article 13(11)", + "Article 13(13)", + "Article 13(14)", + "Article 13(15)", + "Article 13(16)", + "Article 13(17)", + "Article 13(18)", + "Article 13(19)", + "Article 13(20)", + "Article 13(21)", + "Article 13(22)", + "Article 13(23)", + "Article 19(1)", + "Article 19(2)", + "Article 19(2)(c)", + "Article 19(2)(d)", + "Article 19(3)", + "Article 19(4)", + "Article 19(5)", + "Article 19(6)", + "Article 20(1)", + "Article 20(2)", + "Article 20(2)(a)", + "Article 20(2)(b)", + "Article 20(3)", + "Article 20(4)", + "Article 24(1)", + "Article 30(1)", + "Article 30(2)", + "Article 30(3)", + "Article 30(4)" ], - "DCH-18": [ - "Annex 6 Module B.9", - "Annex 6 Module C.3.2" + "TDA-02": [ + "Article 24(1)" ], - "IAC-21": [ - "Annex 1.1(3)(e)" + "TDA-02.9": [ + "Article 13(8)", + "Article 13(9)", + "Article 13(11)" ], - "PRI-05.4": [ - "Annex 1.1(3)(e)" + "TDA-02.11": [ + "Article 14(1)", + "Article 14(2)(a)", + "Article 14(2)(b)", + "Article 14(2)(c)", + "Article 14(2)(i)", + "Article 14(2)(i)(ii)", + "Article 14(2)(i)(iii)", + "Article 20(3)", + "Article 20(4)" + ], + "TDA-04": [ + "Article 13(4)", + "Article 13(7)", + "Article 31(1)" + ], + "TDA-04.1": [ + "Article 13(7)", + "Article 31(1)" + ], + "TDA-06": [ + "Article 24(1)" + ], + "VPM-02": [ + "Article 13(6)" + ] + }, + "emea-eu-cyber-resilience-act-annex-i-2024": { + "CPL-01": [ + "Annex I, Part II" + ], + "IAO-01": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], + "IAO-02.2": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], + "IAO-04": [ + "Annex I, Part II(2)", + "Annex I, Part II(3)" + ], + "PRI-01.11": [ + "Annex I, Part I(2)(g)" ], "TDA-01.1": [ - "Annex 1.1(3)(j)", - "Annex 1.2(2)", - "Annex 2.1", - "Annex 2.2", - "Annex 2.3", - "Annex 2.4", - "Annex 2.5", - "Annex 2.6", - "Annex 2.7", - "Annex 2.8", - "Annex 2.9", - "Annex 2.9(a)", - "Annex 2.9(b)", - "Annex 2.9(c)", - "Annex 2.9(d)", - "Annex 6 Module A.3", - "Annex 6 Module A.4.1", - "Annex 6 Module C.2.1", - "Annex 6 Module C.3.1", - "Annex 6 Module H.2", - "Annex 6 Module H.3.2", - "Annex 6 Module H.3.4", - "Annex 6 Module H.5.1", - "Annex 6 Module H.5.2", - "Annex 6 Module H.6" + "Annex I, Part I(1)", + "Annex I, Part I(2)(g)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)", + "Annex I, Part I(2)(m)", + "Annex I, Part II(1)", + "Annex I, Part II(2)" + ], + "TDA-01.3": [ + "Annex I, Part I(2)(a)" ], "TDA-02": [ - "Annex 1.1(1)", - "Annex 1.1(3)(b)", - "Annex 1.1(3)(c)", - "Annex 1.1(3)(d)", - "Annex 1.1(3)(f)", - "Annex 1.1(3)(g)", - "Annex 1.1(3)(i)", - "Annex 6 Module A.3" + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" ], "TDA-02.4": [ - "Annex 1.1(3)(a)" + "Annex I, Part I(2)(b)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" ], "TDA-02.8": [ - "Annex 1.1(2)", - "Annex 1.1(3)(h)" + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(d)" ], "TDA-02.9": [ - "Annex 1.1(3)(k)", - "Annex 1.2(2)", - "Annex 1.2(7)", - "Annex 1.2(8)" - ], - "TDA-02.10": [ - "Annex 1.2(3)" + "Annex I, Part I(2)(c)", + "Annex I, Part I(2)(l)", + "Annex I, Part II(2)", + "Annex I, Part II(3)", + "Annex I, Part II(4)", + "Annex I, Part II(5)", + "Annex I, Part II(6)", + "Annex I, Part II(7)", + "Annex I, Part II(8)" ], "TDA-02.11": [ - "Annex 1.2(4)", - "Annex 1.2(6)" + "Annex I, Part II(5)", + "Annex I, Part II(6)" ], "TDA-02.12": [ - "Annex 3 Class 1.1", - "Annex 3 Class 1.2", - "Annex 3 Class 1.3", - "Annex 3 Class 1.4", - "Annex 3 Class 1.5", - "Annex 3 Class 1.6", - "Annex 3 Class 1.7", - "Annex 3 Class 1.8", - "Annex 3 Class 1.9", - "Annex 3 Class 1.10", - "Annex 3 Class 1.11", - "Annex 3 Class 1.12", - "Annex 3 Class 1.13", - "Annex 3 Class 1.14", - "Annex 3 Class 1.15", - "Annex 3 Class 1.16", - "Annex 3 Class 1.17", - "Annex 3 Class 1.18", - "Annex 3 Class 1.19", - "Annex 3 Class 1.20", - "Annex 3 Class 1.21", - "Annex 3 Class 1.22", - "Annex 3 Class 1.23", - "Annex 3 Class 2.1", - "Annex 3 Class 2.2", - "Annex 3 Class 2.3", - "Annex 3 Class 2.4", - "Annex 3 Class 2.5", - "Annex 3 Class 2.6", - "Annex 3 Class 2.7", - "Annex 3 Class 2.8", - "Annex 3 Class 2.9", - "Annex 3 Class 2.10", - "Annex 3 Class 2.11", - "Annex 3 Class 2.12", - "Annex 3 Class 2.13", - "Annex 3 Class 2.14", - "Annex 3 Class 2.15" + "Annex I, Part I(1)" ], "TDA-04.2": [ - "Annex 1.2(1)", - "Annex 1.2(6)" + "Annex I, Part II(1)" ], - "TDA-22": [ - "Annex 5", - "Annex 5.1", - "Annex 5.1(a)", - "Annex 5.1(b)", - "Annex 5.1(c)", - "Annex 5.1(d)", - "Annex 5.2", - "Annex 5.2(a)", - "Annex 5.2(b)", - "Annex 5.2(c)", - "Annex 5.3", - "Annex 5.4", - "Annex 5.5", - "Annex 5.6", - "Annex 5.7", - "Annex 6 Module A.2" - ], - "THR-06": [ - "Annex 1.2(5)" + "TDA-06": [ + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)" ], - "THR-06.1": [ - "Annex 2.2" + "VPM-02": [ + "Annex I, Part II(2)" ] }, "emea-eu-eba-ict-srm-2025": { + "GOV-01": [ + "3.4.1.30" + ], "GOV-01.1": [ - "3.2.1(2)", - "3.2.1(3)", - "3.2.1(4)" + "3.2.1.2", + "3.2.1.3", + "3.2.1.4" ], "GOV-01.2": [ - "3.3.1(13)(e)", - "3.3.5(24)" + "3.3.1.13(e)", + "3.3.5.24" + ], + "GOV-01.3": [ + "3.4.6.48" ], "GOV-02": [ - "3.4.1(28)", - "3.4.1(29)", - "3.4.5(38)" + "3.4.1.28", + "3.4.5.38", + "3.5.50" ], "GOV-03": [ - "3.3.1(14)" + "3.3.1.14" ], "GOV-04": [ - "3.3.1(11)", - "3.3.1(12)", - "3.7.5(91)" + "3.3.1.11" ], "GOV-04.1": [ - "3.3.1(11)", - "3.7.5(91)" + "3.3.1.11", + "3.3.1.12" ], - "GOV-04.2": [ - "3.7.5(91)" + "GOV-05": [ + "3.5.51" ], "GOV-06": [ - "3.7.5(91)" + "3.7.5.91" ], "GOV-08": [ - "3.2.1(4)" - ], - "GOV-09": [ - "3.2.1(5)(c)" + "3.2.1.4", + "3.2.2.5" ], "GOV-15": [ - "3.3.4(22)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "GOV-15.1": [ - "3.3.4(22)", - "3.3.4(23)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "GOV-15.2": [ - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" - ], - "GOV-15.3": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "AST-01": [ - "3.5(53)", - "3.5(54)" + "3.5.53", + "3.5.54" ], "AST-01.1": [ - "3.3.3(17)", - "3.3.3(18)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "AST-01.2": [ - "3.3.2(16)", - "3.5(54)" + "3.5.54" ], "AST-02": [ - "3.5(53)", - "3.5(54)" + "3.3.2.16", + "3.5.53", + "3.5.54" + ], + "AST-02.9": [ + "3.5.54" ], "AST-04.1": [ - "3.3.3(17)", - "3.3.3(18)" + "3.3.3.17", + "3.3.3.18" ], "BCD-01": [ - "3.7(77)", - "3.7.1(78)", - "3.7.1(79)", - "3.7.2(80)", - "3.7.2(81)", - "3.7.2(82)", - "3.7.3(83)", - "3.7.3(84)(a)", - "3.7.3(84)(b)", - "3.7.3(84)(c)", - "3.7.3(85)", - "3.7.3(86)" + "3.7.77", + "3.7.1.78", + "3.7.1.79", + "3.7.2.80", + "3.7.3.83", + "3.7.3.85", + "3.7.3.86", + "3.7.5.91" + ], + "BCD-01.4": [ + "3.7.2.81" + ], + "BCD-01.7": [ + "3.7.2.82", + "3.7.3.83", + "3.7.3.84", + "3.7.3.84(a)", + "3.7.3.84(b)", + "3.7.3.84(c)" ], "BCD-02": [ - "3.7.1(78)", - "3.7.3(83)" + "3.3.2.16", + "3.7.1.78" ], "BCD-04": [ - "3.7.4(87)", - "3.7.4(89)", - "3.7.4(89)(a)", - "3.7.4(89)(b)", - "3.7.4(89)(c)", - "3.7.4(90)" + "3.7.4.87", + "3.7.4.89", + "3.7.4.89(a)", + "3.7.4.89(b)", + "3.7.4.89(c)", + "3.7.4.90" ], "BCD-05": [ - "3.7.4(88)", - "3.7.4(90)" + "3.7.3.84(c)", + "3.7.4.88", + "3.7.4.90" ], "BCD-06": [ - "3.7.4(88)", - "3.7.4(90)" - ], - "BCD-10": [ - "3.7.5(91)" + "3.7.4.88", + "3.7.4.90" ], "BCD-10.3": [ - "3.7.3(86)" + "3.7.3.86" ], "BCD-10.4": [ - "3.7.5(91)" + "3.7.5.91" ], "BCD-11": [ - "3.5(57)" + "3.5.57" ], "BCD-11.2": [ - "3.5(58)" - ], - "BCD-12": [ - "3.7.3(83)" + "3.5.58" ], "CAP-01": [ - "3.5(56)" + "3.5.56" ], "CHG-01": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "CHG-02": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "CHG-02.1": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "CHG-02.2": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "CHG-02.3": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "CHG-03": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.76" ], "CPL-01": [ - "3.1(1)", - "3.8(92)", - "3.8(93)", - "3.8(94)", - "3.8(95)", - "3.8(96)", - "3.8(97)", - "3.8(98)" + "3.1.1", + "3.8.92", + "3.8.93", + "3.8.94", + "3.8.95", + "3.8.96", + "3.8.97", + "3.8.98" + ], + "CPL-01.1": [ + "3.3.6.27" ], "CPL-02": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.1.11", + "3.3.3.19", + "3.3.6.25", + "3.4.6.41", + "3.4.6.46", + "3.4.6.48" ], "CPL-02.1": [ - "3.3.1(11)", - "3.3.6(25)" + "3.3.1.11", + "3.3.6.25" ], "CPL-03": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41", + "3.4.6.44" ], "CPL-03.1": [ - "3.3.6(25)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)(a)", - "3.4.6(43)(b)" + "3.3.6.25", + "3.4.6.41" ], "CPL-03.2": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41" ], "CFG-02": [ - "3.4.4(36)(b)" + "3.4.4.36(b)" + ], + "CFG-02.1": [ + "3.4.6.46" ], "MON-01": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" + "3.4.5.39", + "3.5.52" ], "MON-01.2": [ - "3.4.5(39)", - "3.4.5(40)" + "3.4.5.38", + "3.4.5.39" ], "MON-01.7": [ - "3.4.4(36)(e)" - ], - "MON-01.8": [ - "3.4.5(39)", - "3.4.5(40)" - ], - "MON-01.16": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" + "3.4.4.36(e)" ], "MON-02": [ - "3.5(52)" + "3.4.5.38", + "3.4.5.39", + "3.5.52" ], - "MON-02.2": [ - "3.5(52)" + "MON-02.1": [ + "3.4.5.38(a)", + "3.4.5.38(b)", + "3.4.5.38(c)", + "3.4.5.39", + "3.4.5.40" ], - "MON-03": [ - "3.5(52)" + "MON-02.2": [ + "3.5.52" ], "MON-11.3": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" ], "MON-16": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" + ], + "MON-16.4": [ + "3.4.2.31(c)", + "3.4.2.31(d)" ], "CRY-01": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "CRY-03": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "CRY-05": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "DCH-02": [ - "3.3.3(17)", - "3.3.3(18)", - "3.3.3(19)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "END-01": [ - "3.4.4(36)(d)" + "3.4.4.36(d)" ], "END-06": [ - "3.4.4(36)(e)" + "3.4.4.36(e)" ], "HRS-01": [ - "3.3.2(15)" - ], - "HRS-02": [ - "3.3.2(15)" + "3.2.1.3" ], "HRS-03": [ - "3.3.1(12)", - "3.3.2(15)" + "3.2.1.2", + "3.3.1.12", + "3.4.1.29" + ], + "HRS-13": [ + "3.2.1.3" + ], + "HRS-13.1": [ + "3.2.1.3" + ], + "HRS-13.3": [ + "3.2.1.3" + ], + "IAC-01": [ + "3.4.2.31(g)" + ], + "IAC-01.2": [ + "3.4.2.31(g)" + ], + "IAC-07": [ + "3.4.2.31(e)" ], "IAC-08": [ - "3.4.2.(32)" + "3.4.2.32" + ], + "IAC-15": [ + "3.4.2.31(c)" + ], + "IAC-15.5": [ + "3.4.2.31(b)" + ], + "IAC-16": [ + "3.4.2.31(d)" + ], + "IAC-17": [ + "3.4.2.31(e)", + "3.4.2.31(f)" + ], + "IAC-21": [ + "3.4.2.31(a)" ], "IRO-01": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60" ], "IRO-02": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60", + "3.5.1.60(a)", + "3.5.1.60(b)", + "3.5.1.60(c)", + "3.5.1.60(d)", + "3.5.1.60(d)(i)", + "3.5.1.60(d)(ii)", + "3.5.1.60(e)", + "3.5.1.60(f)", + "3.5.1.60(f)(i)", + "3.5.1.60(f)(ii)" ], "IRO-04": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" - ], - "IRO-07": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)" - ], - "IRO-09": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(ii)" + "3.5.1.59", + "3.5.1.60" ], "IRO-10": [ - "3.7.5(91)" + "3.7.5.91" ], "IRO-10.2": [ - "3.7.5(91)" + "3.7.5.91" ], "IRO-14": [ - "3.7.5(91)" + "3.7.5.91" ], "IRO-16": [ - "3.7.5(91)" + "3.7.5.91" ], "IAO-01": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)" + "3.4.6.42", + "3.4.6.43", + "3.4.6.43(a)", + "3.4.6.43(b)", + "3.4.6.45", + "3.6.2.69", + "3.6.2.70" + ], + "IAO-01.1": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-02": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" + ], + "IAO-02.1": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-02.2": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.4.6.47", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" + ], + "IAO-02.4": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "IAO-03": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "IAO-03.2": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "IAO-04": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-05": [ - "3.3.1(13)(d)" + "3.3.1.13(d)", + "3.3.6.27", + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-06": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-07": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "NET-06": [ - "3.4.4(36)(c)" + "3.4.4.36(c)" ], "PES-01": [ - "3.4.3(33)" + "3.4.3.33" + ], + "PES-02": [ + "3.4.3.34" ], "PES-02.1": [ - "3.4.3(34)" + "3.4.3.34" ], "PES-07": [ - "3.4.3(35)" + "3.4.3.35" ], "PES-07.1": [ - "3.4.3(35)" + "3.4.3.35" ], "PES-07.5": [ - "3.4.3(35)" + "3.4.3.35" ], "PES-08": [ - "3.4.3(35)" + "3.4.3.35" ], "PES-09": [ - "3.4.3(35)" + "3.4.3.35" ], "PRM-01": [ - "3.2.1(6)", - "3.6.1(61)", - "3.6.1(62)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66", + "3.6.2.74" ], "PRM-01.1": [ - "3.2.1(4)", - "3.2.1(5)(a)", - "3.2.1(5)(b)", - "3.2.1(5)(c)" + "3.2.1.4", + "3.2.2.5", + "3.2.2.5(a)", + "3.2.2.5(b)", + "3.2.2.5(c)", + "3.2.2.6" ], "PRM-02": [ - "3.6.1(61)", - "3.6.1(62)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66" + ], + "PRM-02.1": [ + "3.6.1.62", + "3.6.1.66" ], "PRM-03": [ - "3.2.1(3)" + "3.2.1.3" ], "PRM-04": [ - "3.3.1(10)", - "3.3.1(13)(f)", - "3.6.1(62)", - "3.6.1(61)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.3.1.10", + "3.3.1.13(f)", + "3.6.1.61", + "3.6.1.62", + "3.6.1.63", + "3.6.1.63(a)", + "3.6.1.63(b)", + "3.6.1.63(c)", + "3.6.1.63(d)", + "3.6.1.63(e)", + "3.6.1.63(f)", + "3.6.1.64", + "3.6.1.65", + "3.6.1.66", + "3.6.2.74" ], "PRM-05": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.6.1.64", + "3.6.2.68" ], "PRM-06": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.3.2.15", + "3.6.1.64", + "3.6.2.68" ], "PRM-07": [ - "3.3.1(13)(f)", - "3.5(55)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)" + "3.3.1.13(f)", + "3.5.55" ], "RSK-01": [ - "3.2.3(7)", - "3.3.1(10)", - "3.3.1(13)(a)", - "3.3.1(13)(b)", - "3.3.1(13)(c)", - "3.3.1(13)(d)", - "3.3.1(13)(e)", - "3.3.1(13)(f)", - "3.3.1(14)" + "3.2.3.7", + "3.3.1.10", + "3.3.1.13", + "3.3.1.13(d)", + "3.3.1.13(e)", + "3.3.1.13(f)", + "3.3.1.14", + "3.3.4.23" ], "RSK-01.1": [ - "3.3.1(10)", - "3.6.1(66)", - "3.7.2(82)" + "3.3.1.10" ], "RSK-01.3": [ - "3.3.1(10)" + "3.3.1.10" ], "RSK-01.4": [ - "3.3.1(10)" + "3.3.1.10" ], "RSK-01.5": [ - "3.3.1(10)", - "3.3.1(13)(a)" + "3.3.1.10", + "3.3.1.13(a)" ], "RSK-03": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "RSK-04": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.3.3(20)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "RSK-04.1": [ - "3.3.1(10)", - "3.3.1(13)(d)" + "3.3.1.10", + "3.3.1.13(d)" ], "RSK-05": [ - "3.3.1(10)" + "3.3.1.10" ], "RSK-06": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "RSK-06.1": [ - "3.3.1(13)(c)" + "3.3.1.13(c)" ], "RSK-06.2": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "RSK-07": [ - "3.3.1(13)(f)" + "3.3.1.13(f)" ], "RSK-08": [ - "3.7.1(78)" + "3.3.3.20", + "3.7.1.78" ], "SEA-01": [ - "3.7.1(79)" + "3.7.1.79" ], "SEA-02": [ - "3.7.1(79)" + "3.7.1.79" ], "SEA-03": [ - "3.7.1(79)" + "3.7.1.79" ], "SEA-07.1": [ - "3.5(55)" + "3.5.55" ], "OPS-01.1": [ - "3.4.2.(31)", - "3.4.2(31)(a)", - "3.4.2(31)(b)", - "3.4.2(31)(c)", - "3.4.2(31)(d)", - "3.4.2(31)(e)", - "3.4.2(31)(f)", - "3.4.2(31)(g)", - "3.4.5(38)", - "3.5(50)" + "3.4.2.31", + "3.4.4.36", + "3.5.50" ], "OPS-02": [ - "3.2.1(6)" + "3.2.2.6" ], "SAT-01": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "SAT-02": [ - "3.4.7(49)" + "3.4.7.49" ], "SAT-03": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "TDA-01": [ - "3.6.2(67)", - "3.6.2(74)" - ], - "TDA-01.1": [ - "3.6.2(68)" - ], - "TDA-02": [ - "3.6.2(68)" - ], - "TDA-02.3": [ - "3.6.2(69)", - "3.6.2(74)" - ], - "TDA-02.4": [ - "3.6.2(69)" - ], - "TDA-02.7": [ - "3.6.2(69)" + "3.6.2.67", + "3.6.2.74" ], "TDA-04": [ - "3.6.2(73)" - ], - "TDA-04.1": [ - "3.6.2(69)" - ], - "TDA-05": [ - "3.6.2(69)" - ], - "TDA-06": [ - "3.6.2(69)" - ], - "TDA-06.2": [ - "3.6.2(69)" - ], - "TDA-06.5": [ - "3.6.2(69)" + "3.6.2.73" ], "TDA-07": [ - "3.6.2(69)", - "3.6.2(72)" + "3.6.2.72" ], "TDA-08": [ - "3.6.2(69)", - "3.6.2(72)" - ], - "TDA-09": [ - "3.6.2(69)", - "3.6.2(70)", - "3.6.2(71)" - ], - "TDA-15": [ - "3.6.2(68)", - "3.6.2(69)", - "3.6.2(70)" + "3.6.2.72" ], "TDA-20": [ - "3.6.2(73)" + "3.6.2.73" ], "TPM-01": [ - "3.2.3(7)", - "3.6.2(74)" - ], - "TPM-03": [ - "3.6.2(74)" + "3.2.3.7" ], - "TPM-03.1": [ - "3.6.2(74)" + "TPM-02": [ + "3.3.2.16" ], - "TPM-04.1": [ - "3.6.2(74)" + "TPM-03": [ + "3.7.3.86" ], "TPM-05": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8", + "3.2.3.8(a)", + "3.2.3.8(b)" ], "TPM-05.2": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8" ], "TPM-05.4": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)", - "3.3.2(16)", - "3.5(55)" + "3.2.3.8", + "3.5.55" ], "TPM-05.5": [ - "3.5(55)" + "3.5.55" ], "TPM-05.6": [ - "3.2.3(9)" + "3.2.3.9" ], "TPM-08": [ - "3.2.3(9)" + "3.2.3.9" ], "TPM-11": [ - "3.2.3(8)(b)" + "3.2.3.8(b)" ], "THR-03": [ - "3.3.3(21)" + "3.3.3.21" ], "VPM-01": [ - "3.3.3(21)", - "3.4.4(36)(a)" + "3.3.3.21", + "3.4.4.36(a)" ] }, "emea-eu-dora-2023": { @@ -99762,614 +101963,769 @@ "6.10.4" ] }, - "emea-us-psd2-2015": { + "emea-eu-psd2-2015": { "GOV-01": [ - "3" - ], - "GOV-02": [ - "3" + "95(1)", + "97(3)" + ], + "GOV-01.4": [ + "98(1)", + "98(1)(a)", + "98(1)(b)", + "98(1)(c)", + "98(1)(d)", + "98(2)", + "98(3)", + "98(4)", + "98(5)" ], - "GOV-03": [ - "3" - ], - "GOV-05": [ - "3" - ], - "AST-09": [ - "24" + "GOV-17": [ + "96(6)" ], "CPL-01": [ - "3", - "29" - ], - "CPL-02": [ - "3" - ], - "CPL-03": [ - "3", - "29" - ], - "CPL-03.1": [ - "3" - ], - "CPL-03.2": [ - "3" - ], - "CPL-04": [ - "3" + "97(3)" ], - "MON-09": [ - "26" - ], - "CRY-01": [ - "20", - "30" - ], - "CRY-03": [ - "20", - "30" - ], - "CRY-04": [ - "20", - "30" - ], - "DCH-08": [ - "24" - ], - "DCH-09.3": [ - "24" - ], - "DCH-21": [ - "24" - ], - "IAC-01": [ - "4" - ], - "IAC-03": [ - "4" - ], - "IAC-04": [ - "25" - ], - "IAC-05": [ - "4" - ], - "IAC-06": [ - "4" - ], - "IAC-10": [ - "4" + "HRS-06.1": [ + "24(1)" ], - "IAC-10.1": [ - "4" + "IRO-01": [ + "95(1)" ], - "IAC-10.4": [ - "19" + "IRO-10": [ + "96(1)" ], - "IAC-10.5": [ - "19", - "22" + "IRO-10.5": [ + "96(1)" ], - "NET-11": [ - "22" + "PRI-01.11": [ + "94(1)", + "94(2)" ], - "PRI-05": [ - "24" + "RSK-04": [ + "95(2)" ], "WEB-06": [ - "4" + "97(1)", + "97(1)(a)", + "97(1)(b)", + "97(1)(c)", + "97(2)" ] }, - "emea-aut-fappd-2000": { - "GOV-01": [ - "Sec 14", - "Sec 15" - ], - "GOV-02": [ - "Sec 14", - "Sec 15" - ], - "GOV-03": [ - "Sec 14", - "Sec 15" + "emea-aut-dpa-2018": { + "CPL-01.3": [ + "§ 37(3)" ], - "GOV-04": [ - "Sec 14", - "Sec 15" + "CPL-05.2": [ + "§ 51", + "§ 52", + "§ 53" ], - "AST-01": [ - "Sec 14", - "Sec 15" + "END-13.2": [ + "§ 12(2)" ], - "AST-02": [ - "Sec 14", - "Sec 15" + "HRS-05.7": [ + "§ 6(3)" ], - "AST-03": [ - "Sec 14", - "Sec 15" + "HRS-06.1": [ + "§ 5(1)" ], - "AST-04": [ - "Sec 14", - "Sec 15" + "IRO-10": [ + "§ 55(1)", + "§ 55(2)", + "§ 56(1)", + "§ 56(2)" ], - "BCD-01": [ - "Sec 14", - "Sec 15" + "PRI-01.4": [ + "§ 5(1)", + "§ 57(1)", + "§ 57(2)", + "§ 57(3)", + "§ 57(4)" ], - "CAP-01": [ - "Sec 14", - "Sec 15" + "PRI-01.5": [ + "§ 58(1)", + "§ 58(2)", + "§ 58(3)", + "§ 59(1)", + "§ 59(2)", + "§ 59(3)", + "§ 59(5)", + "§ 59(6)", + "§ 59(7)" ], - "CHG-01": [ - "Sec 14", - "Sec 15" + "PRI-01.6": [ + "§ 6(1)", + "§ 13(1)", + "§ 54(1)" ], - "CLD-01": [ - "Sec 14", - "Sec 15" + "PRI-01.11": [ + "§ 1(1)", + "§ 1(2)", + "§ 1(3)", + "§ 1(4)", + "§ 6(2)", + "§ 8(1)", + "§ 8(2)", + "§ 8(3)", + "§ 37(1)", + "§ 37(5)", + "§ 37(8)", + "§ 45(3)" ], - "CPL-01": [ - "Sec 14", - "Sec 15" + "PRI-02": [ + "§ 43(1)", + "§ 43(2)", + "§ 43(3)", + "§ 43(4)" ], - "CFG-01": [ - "Sec 14", - "Sec 15" + "PRI-03": [ + "§ 8(1)", + "§ 12(1)", + "§ 12(2)", + "§ 12(3)", + "§ 12(4)" ], - "MON-01": [ - "Sec 14", - "Sec 15" + "PRI-05": [ + "§ 13(3)", + "§ 37(2)" ], - "MON-01.16": [ - "Sec 14", - "Sec 15" + "PRI-05.1": [ + "§ 7(2)" ], - "CRY-01": [ - "Sec 14", - "Sec 15" + "PRI-05.2": [ + "§ 37(6)", + "§ 37(7)" ], - "DCH-01": [ - "Sec 14", - "Sec 15" + "PRI-05.4": [ + "§ 7(1)", + "§ 7(6)", + "§ 38", + "§ 39", + "§ 40(1)", + "§ 40(2)", + "§ 40(3)" ], - "DCH-22.1": [ - "Sec 27" + "PRI-05.7": [ + "§ 37(4)" ], - "DCH-24": [ - "Sec 10" + "PRI-06": [ + "§ 42(1)", + "§ 42(2)", + "§ 44(1)", + "§ 44(5)" ], - "DCH-24.1": [ - "Sec 10" + "PRI-06.1": [ + "§ 45(1)" ], - "DCH-25": [ - "Sec 10" + "PRI-06.2": [ + "§ 45(5)" ], - "EMB-01": [ - "Sec 14", - "Sec 15" + "PRI-06.4": [ + "§ 42(3)", + "§ 42(4)", + "§ 42(5)", + "§ 42(6)", + "§ 45(8)", + "§ 45(9)", + "§ 44(3)", + "§ 44(4)", + "§ 45(4)" ], - "END-01": [ - "Sec 14", - "Sec 15" + "PRI-06.5": [ + "§ 45(2)" ], - "HRS-01": [ - "Sec 14", - "Sec 15" + "PRI-07.1": [ + "§ 48(1)", + "§ 48(2)", + "§ 48(3)", + "§ 48(4)", + "§ 48(5)", + "§ 48(6)" ], - "IAC-01": [ - "Sec 14", - "Sec 15" + "PRI-07.2": [ + "§ 47" ], - "IRO-01": [ - "Sec 14", - "Sec 15" + "PRI-07.5": [ + "§ 44(4)" ], - "IRO-14": [ - "Sec 10" + "PRI-14": [ + "§ 13(2)", + "§ 49(1)", + "§ 49(2)", + "§ 49(3)", + "§ 50(1)", + "§ 50(2)", + "§ 50(3)", + "§ 50(5)" + ], + "PRI-19": [ + "§ 41(1)", + "§ 41(2)", + "§ 41(3)" ], - "IAO-01": [ - "Sec 14", - "Sec 15" + "SAT-03.3": [ + "§ 6(3)" + ] + }, + "emea-bel-act-30-2018": { + "CPL-01.3": [ + "Title 2, Chapter II, Art. 29(5)" ], - "MNT-01": [ - "Sec 14", - "Sec 15" + "DCH-23": [ + "Title 4, Chapter III, Section 3, Art. 198", + "Title 4, Chapter III, Section 3, Art. 199", + "Title 4, Chapter III, Section 3, Art. 200", + "Title 4, Chapter III, Section 3, Art. 201" ], - "MDM-01": [ - "Sec 14", - "Sec 15" + "IRO-10": [ + "Title 2, Chapter IV, Section 4, Art. 61(1)", + "Title 2, Chapter IV, Section 4, Art. 61(2)", + "Title 2, Chapter IV, Section 4, Art. 61(3)", + "Title 2, Chapter IV, Section 4, Art. 61(4)", + "Title 2, Chapter IV, Section 4, Art. 61(5)", + "Title 2, Chapter IV, Section 4, Art. 61(6)", + "Title 2, Chapter IV, Section 4, Art. 62(1)", + "Title 2, Chapter IV, Section 4, Art. 62(2)", + "Title 2, Chapter IV, Section 4, Art. 62(3)", + "Title 2, Chapter IV, Section 4, Art. 62(4)", + "Title 2, Chapter IV, Section 4, Art. 62(5)" ], - "NET-01": [ - "Sec 14", - "Sec 15" + "PRI-01.4": [ + "Title 2, Chapter IV, Section 5, Art. 63", + "Title 2, Chapter IV, Section 5, Art. 64", + "Title 2, Chapter IV, Section 5, Art. 65", + "Title 4, Chapter II, Art. 190", + "Title 4, Chapter II, Art. 191", + "Title 4, Chapter II, Art. 192" ], - "PES-01": [ - "Sec 14", - "Sec 15" + "PRI-01.5": [ + "Title 2, Chapter V, Art. 66(1)", + "Title 2, Chapter V, Art. 66(2)", + "Title 2, Chapter V, Art. 67", + "Title 2, Chapter V, Art. 68(1)", + "Title 2, Chapter V, Art. 68(2)", + "Title 2, Chapter V, Art. 68(3)", + "Title 2, Chapter V, Art. 69(1)", + "Title 2, Chapter V, Art. 69(2)", + "Title 2, Chapter V, Art. 69(3)", + "Title 2, Chapter V, Art. 70(1)", + "Title 2, Chapter V, Art. 70(2)", + "Title 2, Chapter V, Art. 70(3)" ], - "PRI-01": [ - "Sec 14", - "Sec 15" + "PRI-01.6": [ + "Title 2, Chapter II, Art. 34(2)", + "Title 2, Chapter III, Art. 45(4)", + "Title 2, Chapter IV, Section 1, Art. 50", + "Title 2, Chapter IV, Section 1, Art. 51(1)", + "Title 2, Chapter IV, Section 1, Art. 51(2)", + "Title 2, Chapter IV, Section 4, Art. 60(1)", + "Title 2, Chapter IV, Section 4, Art. 60(2)" ], - "PRI-02.1": [ - "Sec 6" + "PRI-01.11": [ + "Title 1, Section III, Art. 14(2)", + "Title 2, Chapter II, Art. 28", + "Title 2, Chapter II, Art. 32(1)", + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter II, Art. 34(1)", + "Title 2, Chapter III, Art. 39(3)", + "Title 2, Chapter III, Art. 45(3)", + "Title 4, Chapter III, Section 2, Art. 194", + "Title 4, Chapter III, Section 2, Art. 195", + "Title 4, Chapter III, Section 2, Art. 196", + "Title 4, Chapter III, Section 2, Art. 197", + "Title 4, Chapter III, Section 3, Art. 202(1)", + "Title 4, Chapter III, Section 3, Art. 202(2)" ], - "PRI-03": [ - "Sec 8" + "PRI-02": [ + "Title 2, Chapter III, Art. 37(1)", + "Title 2, Chapter III, Art. 37(2)", + "Title 4, Chapter III, Section 1, Art. 193" ], - "PRI-03.2": [ - "Sec 8" + "PRI-03.3": [ + "Title 1, Chapter II, Art. 7" ], "PRI-04": [ - "Sec 6" + "Title 2, Chapter II, Art. 29(1)", + "Title 2, Chapter II, Art. 29(2)" ], "PRI-04.1": [ - "Sec 6" + "Title 1, Section III, Art. 14(4)", + "Title 2, Chapter II, Art. 33(1)", + "Title 2, Chapter II, Art. 33(2)" ], "PRI-05": [ - "Sec 7" + "Title 2, Chapter II, Art. 30" ], - "PRI-05.1": [ - "Sec 12" + "PRI-05.2": [ + "Title 2, Chapter II, Art. 32(2)" ], "PRI-05.4": [ - "Sec 12" + "Title 1, Chapter II, Art. 8(3)", + "Title 1, Chapter II, Art. 9", + "Title 1, Chapter II, Art. 10(1)", + "Title 2, Chapter III, Art. 45(2)" + ], + "PRI-05.7": [ + "Title 1, Chapter II, Art. 8(2)", + "Title 1, Chapter II, Art. 10(2)", + "Title 2, Chapter II, Art. 31" ], "PRI-06": [ - "Sec 26" + "Title 2, Chapter III, Art. 36(2)", + "Title 2, Chapter III, Art. 38(1)", + "Title 2, Chapter III, Art. 38(2)", + "Title 2, Chapter III, Art. 39(1)" ], - "PRI-06.1": [ - "Sec 27" + "PRI-06.2": [ + "Title 2, Chapter III, Art. 39(5)", + "Title 2, Chapter III, Art. 39(6)" ], - "PRI-06.3": [ - "Sec 28" + "PRI-06.4": [ + "Title 2, Chapter III, Art. 36(3)", + "Title 2, Chapter III, Art. 38(3)", + "Title 2, Chapter III, Art. 39(4)", + "Title 2, Chapter III, Art. 40" ], - "PRI-07": [ - "Sec 10" + "PRI-06.5": [ + "Title 2, Chapter III, Art. 39(2)" ], "PRI-07.1": [ - "Sec 10" - ], - "PRI-15": [ - "Sec 16", - "Sec 17" - ], - "PRM-01": [ - "Sec 14", - "Sec 15" - ], - "RSK-01": [ - "Sec 14", - "Sec 15" + "Title 2, Chapter IV, Section 3, Art. 53(1)", + "Title 2, Chapter IV, Section 3, Art. 53(2)", + "Title 2, Chapter IV, Section 3, Art. 53(3)", + "Title 2, Chapter IV, Section 3, Art. 53(4)", + "Title 2, Chapter IV, Section 3, Art. 53(5)", + "Title 2, Chapter IV, Section 3, Art. 54" ], - "SEA-01": [ - "Sec 14", - "Sec 15" - ], - "SEA-02": [ - "Sec 14", - "Sec 15" - ], - "SEA-03": [ - "Sec 14", - "Sec 15" - ], - "SEA-15": [ - "Sec 10" - ], - "OPS-01": [ - "Sec 14", - "Sec 15" - ], - "SAT-01": [ - "Sec 14", - "Sec 15" - ], - "TDA-01": [ - "Sec 14", - "Sec 15" + "PRI-07.2": [ + "Title 2, Chapter IV, Section 2, Art. 52" ], - "TPM-01": [ - "Sec 14", - "Sec 15" + "PRI-07.4": [ + "Title 2, Chapter III, Art. 36(4)" ], - "TPM-04.4": [ - "Sec 10" + "PRI-07.5": [ + "Title 2, Chapter III, Art. 36(5)" ], - "THR-01": [ - "Sec 14", - "Sec 15" + "PRI-14": [ + "Title 1, Section III, Art. 14(3)", + "Title 2, Chapter III, Art. 45(5)", + "Title 2, Chapter IV, Section 4, Art. 55(1)", + "Title 2, Chapter IV, Section 4, Art. 55(2)", + "Title 2, Chapter IV, Section 4, Art. 55(3)", + "Title 2, Chapter IV, Section 4, Art. 56(1)", + "Title 2, Chapter IV, Section 4, Art. 56(2)", + "Title 2, Chapter IV, Section 4, Art. 56(3)", + "Title 2, Chapter IV, Section 4, Art. 57", + "Title 2, Chapter IV, Section 4, Art. 58" ], - "VPM-01": [ - "Sec 14", - "Sec 15" + "PRI-17": [ + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter III, Art. 36(1)" ], - "WEB-01": [ - "Sec 14", - "Sec 15" + "PRI-18": [ + "Title 2, Chapter III, Art. 38(4)" ], - "WEB-02": [ - "Sec 14", - "Sec 15" + "PRI-19": [ + "Title 2, Chapter II, Art. 35" ] }, - "emea-bel-act-8-1992": { - "GOV-01": [ - "16" - ], - "GOV-02": [ - "16" - ], - "GOV-03": [ - "16" - ], - "GOV-04": [ - "16" - ], - "AST-01": [ - "16" - ], - "AST-02": [ - "16" - ], - "AST-03": [ - "16" - ], - "AST-04": [ - "16" - ], - "BCD-01": [ - "16" - ], - "CAP-01": [ - "16" - ], - "CHG-01": [ - "16" - ], - "CLD-01": [ - "16" + "emea-deu-fdpa-2017": { + "GOV-17": [ + "3.5.79(3)" ], "CPL-01": [ - "16" - ], - "CFG-01": [ - "16" - ], - "MON-01": [ - "16" - ], - "MON-01.16": [ - "16" + "3.4.76(5)", + "3.4.77" ], "CRY-01": [ - "16" - ], - "DCH-01": [ - "16" - ], - "DCH-22.1": [ - "10", - "12" - ], - "DCH-24": [ - "Chapter 4 - 16" - ], - "DCH-24.1": [ - "Chapter 4 - 16" + "3.2.48(2)7" ], - "EMB-01": [ - "16" + "DCH-23": [ + "3.4.64(2)" ], - "END-01": [ - "16" + "HRS-05": [ + "3.2.48(2)8" ], - "HRS-01": [ - "16" + "IAC-08": [ + "2.1.2.27(1)", + "3.2.48(2)4" ], - "IAC-01": [ - "16" + "IRO-04.1": [ + "3.4.65(1)", + "3.4.65(2)" ], - "IRO-01": [ - "16" + "IRO-10": [ + "3.4.66(1)", + "3.4.66(2)" ], - "IAO-01": [ - "16" + "IRO-10.2": [ + "3.4.65(1)", + "3.4.65(2)", + "3.4.65(3)", + "3.4.65(3)1", + "3.4.65(3)2", + "3.4.65(3)3", + "3.4.65(3)4", + "3.4.65(4)", + "3.4.65(5)", + "3.4.65(6)" ], - "MNT-01": [ - "16" + "PRI-01": [ + "2.1.2.26(5)" ], - "MDM-01": [ - "16" + "PRI-01.4": [ + "2.1.1.22(2)4", + "2.3.38(1)", + "2.3.38(2)" ], - "NET-01": [ - "16" + "PRI-01.5": [ + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)8", + "3.4.62(5)9", + "3.4.62(6)", + "3.4.62(7)", + "3.4.63", + "3.5.78(1)", + "3.5.78(1)1", + "3.5.78(1)2", + "3.5.78(2)", + "3.5.78(3)", + "3.5.78(4)", + "3.5.79(1)", + "3.5.79(1)1" ], - "PES-01": [ - "16" + "PRI-01.6": [ + "2.1.1.22(2)5", + "2.1.1.22(2)6", + "2.1.1.22(2)7", + "2.1.2.28(1)", + "3.2.53", + "3.4.62(5)2", + "3.4.64(1)", + "3.4.64(2)1", + "3.4.64(2)2", + "3.4.64(3)", + "3.4.64(3)1", + "3.4.64(3)2", + "3.4.64(3)3", + "3.4.64(3)4", + "3.4.64(3)5", + "3.4.64(3)6", + "3.4.64(3)7", + "3.4.64(3)8", + "3.4.64(3)9", + "3.4.64(3)10", + "3.4.64(3)11", + "3.4.64(3)12", + "3.4.64(3)13", + "3.4.64(3)14", + "3.4.71(2)" ], - "PRI-01": [ - "4" + "PRI-01.11": [ + "2.2.32(1)1", + "2.2.32(1)2", + "2.2.32(1)3", + "2.2.32(1)4", + "2.2.32(1)5", + "2.2.32(2)", + "2.2.32(3)", + "2.2.33(1)1(a)", + "2.2.33(1)1(b)", + "2.2.33(1)2", + "2.2.33(2)", + "2.2.35(3)", + "2.2.36", + "3.1.47.1", + "3.2.48(2)", + "3.2.48(2)1", + "3.2.48(2)5", + "3.3.57(4)", + "3.3.58(3)", + "3.3.58(3)1", + "3.3.58(3)2", + "3.3.58(3)3", + "3.3.58(4)", + "3.3.59(3)", + "3.4.71(1)", + "3.4.74(1)", + "3.4.74(2)", + "3.5.80(1)", + "3.5.80(1)1", + "3.5.80(1)2", + "3.5.80(1)3", + "3.5.80(1)4", + "3.5.80(1)5", + "3.5.80(2)", + "3.5.80(3)", + "3.7.83(2)", + "3.7.83(3)", + "3.7.83(4)", + "3.7.83(5)" ], "PRI-02": [ - "9" + "3.2.51(4)", + "3.3.55", + "3.3.55.1", + "3.3.55.2", + "3.3.55.3", + "3.3.55.4", + "3.3.55.5", + "3.3.56(1)", + "3.3.56(1)1", + "3.3.56(1)2", + "3.3.56(1)3", + "3.3.56(1)4", + "3.3.56(1)5", + "3.3.56(2)1", + "3.3.56(2)2", + "3.3.56(2)3", + "3.3.56(3)" ], "PRI-02.1": [ - "45754" + "3.3.56(1)2" ], "PRI-03": [ - "45754" + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.27(4)", + "3.2.51(1)", + "3.2.51(2)", + "3.2.51(5)" ], - "PRI-04": [ - "45754" - ], - "PRI-04.1": [ - "45754" - ], - "PRI-05": [ - "4-7", - "21" - ], - "PRI-05.1": [ - "4-7", - "21" - ], - "PRI-05.4": [ - "4-7", - "21" - ], - "PRI-06": [ - "10", - "12" - ], - "PRI-06.1": [ - "10", - "12" - ], - "PRI-15": [ - "17" - ], - "PRM-01": [ - "16" - ], - "RSK-01": [ - "16" - ], - "RSK-08": [ - "21" - ], - "SEA-01": [ - "16" - ], - "SEA-02": [ - "16" + "PRI-03.4": [ + "3.2.51(3)" ], - "SEA-03": [ - "16" + "PRI-03.5": [ + "3.3.59(3)" ], - "SEA-15": [ - "Chapter 4 - 16" + "PRI-03.11": [ + "3.4.75(3)" ], - "OPS-01": [ - "16" + "PRI-04": [ + "3.1.47.2", + "3.1.47.3", + "3.1.47.6" ], - "SAT-01": [ - "16" + "PRI-04.1": [ + "2.1.2.26(1)", + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.26(4)", + "3.2.49", + "3.2.50" ], - "TDA-01": [ - "16" + "PRI-04.7": [ + "3.3.56(2)" ], - "TPM-01": [ - "16" + "PRI-05": [ + "3.1.47.5", + "3.2.48(2)2", + "3.3.58(2)", + "3.4.62(5)4", + "3.4.75(2)", + "3.4.75(4)" ], - "TPM-04.4": [ - "Chapter 4 - 16" + "PRI-05.1": [ + "2.1.2.27(3)" ], - "THR-01": [ - "16" + "PRI-05.2": [ + "3.1.47.4", + "3.4.74(1)" ], - "VPM-01": [ - "16" + "PRI-05.3": [ + "3.2.48(2)6", + "3.2.50" ], - "WEB-01": [ - "16" + "PRI-05.4": [ + "2.1.1.22(1)", + "2.1.1.22(1)1", + "2.1.1.22(1)1(a)", + "2.1.1.22(1)1(b)", + "2.1.1.22(1)1(c)", + "2.1.1.22(1)1(d)", + "2.1.1.22(1)2(a)", + "2.1.1.22(1)2(b)", + "2.1.1.22(2)", + "2.1.1.22(2)1", + "2.1.1.22(2)2", + "2.1.1.22(2)3", + "2.1.1.22(2)8", + "2.1.1.22(2)9", + "2.1.1.22(2)10", + "2.1.1.24(1)", + "2.1.1.24(1)1", + "2.1.1.24(1)2", + "2.1.1.24(2)", + "2.2.33(1)2(a)", + "2.2.33(1)3(b)", + "3.2.52" ], - "WEB-02": [ - "16" - ] - }, - "emea-deu-fdpa-2017": { - "GOV-01": [ - "Sec 9", - "Sec 9a", - "Annex" + "PRI-05.7": [ + "2.1.2.26(3)", + "2.1.2.26(4)", + "2.1.2.26(7)", + "3.2.48(1)", + "3.2.51(5)", + "3.4.70(2)", + "3.4.72", + "3.4.72.1", + "3.4.72.2", + "3.4.72.3", + "3.4.72.4", + "3.4.72.5", + "3.4.73" ], - "CPL-01": [ - "Sec 9", - "Sec 9a", - "Annex" + "PRI-06": [ + "3.3.57(1)", + "3.3.57(1)2", + "3.3.57(1)3", + "3.3.57(1)4", + "3.3.57(1)5", + "3.3.57(1)6", + "3.3.57(1)7", + "3.3.57(1)8", + "3.3.58(1)", + "3.3.58(2)" ], - "CPL-02": [ - "Sec 9", - "Sec 9a", - "Annex" + "PRI-06.1": [ + "3.3.57(1)6", + "3.3.58(1)", + "3.4.75(1)" ], - "DCH-01": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" + "PRI-06.2": [ + "3.3.58(1)", + "3.3.58(5)", + "3.4.75(3)" ], - "DCH-22.1": [ - "Sec 20" + "PRI-06.4": [ + "2.2.34(2)", + "2.2.35(2)", + "3.3.57(6)", + "3.3.59(2)" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-06.5": [ + "2.2.35(1)", + "3.3.58(2)" ], - "PRI-01.1": [ - "Sec 4d", - "Sec 4f", - "Sec 4g" + "PRI-06.8": [ + "3.3.57(3)", + "3.3.59(4)" ], - "PRI-02": [ - "Sec 4", - "Sec 19" + "PRI-07": [ + "3.5.79(1)2", + "3.5.81(1)", + "3.5.81(1)1", + "3.5.81(1)2", + "3.5.81(1)3", + "3.5.81(2)", + "3.5.81(3)", + "3.5.81(4)" ], - "PRI-03": [ - "Sec 4a", - "Sec 11" + "PRI-07.2": [ + "3.4.62(1)", + "3.4.62(2)", + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)9", + "3.4.63" ], - "PRI-04": [ - "Sec 4" + "PRI-07.3": [ + "3.3.58(5)" ], - "PRI-04.1": [ - "Sec 4" + "PRI-07.5": [ + "2.2.34(2)", + "3.3.59(4)" ], - "PRI-05": [ - "Sec 3a", - "Sec 5", - "Sec 13", - "Sec 14", - "Sec 20" + "PRI-14": [ + "3.4.70(1)", + "3.4.70(1)1", + "3.4.70(1)2", + "3.4.70(1)3", + "3.4.70(1)4", + "3.4.70(1)5", + "3.4.70(1)6", + "3.4.70(1)7", + "3.4.70(1)8", + "3.4.70(1)9", + "3.4.70(2)1", + "3.4.70(2)2", + "3.4.70(2)3", + "3.4.70(4)", + "3.4.76(1)", + "3.4.76(1)1", + "3.4.76(1)2", + "3.4.76(1)3", + "3.4.76(1)4", + "3.4.76(1)5", + "3.4.76(1)6", + "3.4.76(2)", + "3.4.76(3)", + "3.4.76(4)", + "3.5.79(2)" ], - "PRI-06": [ - "Sec 19" + "PRI-14.1": [ + "3.3.57(1)4", + "3.5.79(2)" ], - "PRI-06.1": [ - "Sec 20" + "PRI-17": [ + "2.2.33(2)", + "2.2.34(2)", + "3.3.57(6)", + "3.3.57(8)", + "3.3.58(6)", + "3.3.59(1)", + "3.3.59(2)", + "3.4.74(2)" ], - "PRI-15": [ - "Sec 4d", - "Sec 4e" + "PRI-17.3": [ + "3.3.57(8)" ], - "SEA-01": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" + "PRI-19": [ + "2.2.37(1)1", + "2.2.37(1)2", + "2.2.37(2)", + "3.2.54(1)", + "3.2.54(2)", + "3.2.54(3)" ], - "SEA-02": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" + "RSK-10": [ + "3.4.67(1)", + "3.4.67(2)", + "3.4.67(3)", + "3.4.67(4)", + "3.4.67(4)1", + "3.4.67(4)2", + "3.4.67(4)3", + "3.4.67(4)4", + "3.4.67(5)" ], - "SEA-03": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" + "SAT-02": [ + "3.2.48(2)3" ] }, "emea-deu-bsrit-2017": { "GOV-01": [ - "4.1" + "3.1", + "4.1", + "4.8" ], "GOV-01.1": [ "1.1", @@ -100384,25 +102740,30 @@ "2.2", "2.3", "2.4", - "2.5" + "2.5", + "4.3" ], "GOV-01.2": [ - "3.9", "3.11", "4.10", "7.5" ], + "GOV-01.3": [ + "2.2", + "4.4" + ], + "GOV-01.4": [ + "2.1" + ], "GOV-02": [ "4.2", - "4.3", "4.8" ], "GOV-03": [ "4.2", - "4.8" + "4.4" ], "GOV-04": [ - "4.4", "4.5", "4.6" ], @@ -100411,44 +102772,41 @@ "4.6", "4.10" ], - "GOV-04.2": [ - "4.5", - "4.6", - "4.10" + "GOV-05": [ + "2.5", + "4.9" ], "GOV-15": [ + "3.4", + "3.6", "5.1" ], "GOV-15.1": [ + "3.4", + "3.6", "5.1" ], "GOV-15.2": [ + "3.4", "5.2" ], - "AST-01": [ - "12.2" - ], "AST-01.1": [ - "12.2" + "3.3" ], "AST-02": [ - "8.2", - "12.2" - ], - "AST-04.1": [ - "12.4" + "3.3", + "8.2" ], "BCD-01": [ + "1.2(e)", "10.1", "10.2", "10.3", "10.5" ], - "BCD-02": [ - "12.2" - ], "BCD-04": [ - "10.4" + "10.4", + "10.5" ], "BCD-08": [ "10.5" @@ -100475,43 +102833,26 @@ "8.5" ], "CPL-01": [ - "12.5" - ], - "CPL-02": [ - "5.6" + "2.1" ], "CPL-03": [ + "3.7", "5.6" ], "CPL-03.2": [ "5.6" ], - "CFG-01": [ - "6.8" - ], "CFG-02": [ "6.8" ], "CFG-02.8": [ "8.6" ], - "MON-01": [ - "5.5", - "6.3", - "6.7" - ], "MON-01.8": [ - "5.5" - ], - "MON-01.14": [ - "6.7" - ], - "MON-01.15": [ "6.7" ], "MON-01.16": [ "5.5", - "6.3", "6.7" ], "MON-03": [ @@ -100525,8 +102866,7 @@ ], "DCH-02": [ "7.13", - "7.14", - "12.4" + "7.14" ], "IAC-01": [ "6.1", @@ -100547,27 +102887,15 @@ "6.5", "6.6" ], - "IAC-08": [ - "6.2" - ], - "IAC-15": [ - "6.2" - ], - "IAC-15.7": [ - "6.2" - ], - "IAC-17": [ - "6.2" - ], - "IAC-21": [ - "6.2" - ], "IRO-01": [ "4.7" ], "IRO-02": [ "4.7" ], + "IRO-02.4": [ + "4.7" + ], "IRO-03": [ "5.4" ], @@ -100580,6 +102908,18 @@ "IAO-02.2": [ "7.11" ], + "IAO-03": [ + "3.6" + ], + "IAO-05": [ + "3.8" + ], + "IAO-06": [ + "7.11" + ], + "IAO-07": [ + "7.11" + ], "PRM-01": [ "2.3", "7.4", @@ -100607,6 +102947,12 @@ "7.2", "7.3" ], + "PRM-05": [ + "7.6" + ], + "PRM-06": [ + "7.6" + ], "PRM-07": [ "7.1", "7.2", @@ -100615,38 +102961,40 @@ "RSK-01": [ "3.1", "3.2", - "3.3", - "3.4", - "3.5", - "3.6", - "3.7", - "3.8", - "3.9", - "3.10", - "3.11", - "12.3" + "3.5" ], "RSK-03.1": [ "3.3" ], + "RSK-03.2": [ + "3.4" + ], "RSK-04": [ - "3.10" + "3.9" + ], + "RSK-06": [ + "11.1" + ], + "RSK-06.3": [ + "3.9" + ], + "RSK-13": [ + "3.4" ], "SEA-01": [ - "12.1" + "1.2(d)" ], - "SEA-02": [ - "12.1" + "SEA-01.4": [ + "1.2(d)" ], - "SEA-03": [ - "12.1" + "SEA-02": [ + "1.2(d)" ], "SEA-07.1": [ "8.3" ], "OPS-03": [ "8.1", - "8.2", "11.1", "11.2", "11.3", @@ -100659,22 +103007,21 @@ "SAT-01": [ "4.9" ], + "SAT-01.1": [ + "4.9" + ], "TDA-01": [ + "1.2(f)", "7.7", "7.8", "7.9", - "7.10", - "7.11", - "7.12", - "7.13", - "7.14" + "7.10" ], "TDA-01.1": [ "7.7", "7.8", "7.9", "7.10", - "7.11", "7.12", "7.13", "7.14" @@ -100682,6 +103029,9 @@ "TDA-02": [ "7.7" ], + "TDA-02.9": [ + "7.12" + ], "TDA-06": [ "7.6", "7.7", @@ -100694,10 +103044,7 @@ "7.8", "7.9", "7.10", - "7.11", - "7.12", - "7.13", - "7.14" + "7.12" ], "TDA-20": [ "7.9" @@ -100718,383 +103065,473 @@ "TPM-05": [ "9.4" ], + "TPM-05.2": [ + "9.4" + ], + "TPM-08": [ + "9.3" + ], "THR-01": [ "3.10", "5.3" ], "THR-03": [ + "3.10", "5.3" ], "THR-09": [ "3.3", + "3.10", "5.3" ], "THR-10": [ "3.10", "5.3" - ], - "VPM-01": [ - "5.6" - ], - "VPM-06": [ - "5.6" - ], - "VPM-07": [ - "5.6" - ], - "VPM-10": [ - "5.6" ] }, "emea-deu-c5-2020": { "GOV-01": [ + "OIS-01", + "OIS-01-BP1", + "OIS-01-DOAR" + ], + "GOV-01.1": [ "OIS-01" ], - "GOV-02": [ + "GOV-01.2": [ + "SPN-01" + ], + "GOV-01.3": [ + "OIS-01-BP3", + "SA-02-BP2" + ], + "GOV-01.4": [ "OIS-01", + "RB-22-DOAR" + ], + "GOV-02": [ "OIS-02", - "SP-01" + "OIS-06", + "SA-01", + "SA-01-BP1", + "SA-01-BP2", + "SA-01-BP3", + "SA-01-BP4", + "SA-01-BP5", + "SA-01-BP6", + "MDM-01" + ], + "GOV-02.1": [ + "SA-03" ], "GOV-03": [ - "OIS-01", - "SP-02" + "SA-02", + "SA-02-BP1", + "SA-02-BP2", + "SA-02-BP3" ], - "GOV-04": [ - "OIS-03" + "GOV-04.1": [ + "SA-01-BP4" ], "GOV-05": [ - "COM-04" + "OIS-01-BP2" ], "GOV-06": [ "OIS-05" ], "GOV-09": [ "OIS-01", - "OIS-02" + "OIS-02", + "DLL-01-BP1" + ], + "GOV-14": [ + "SA-01-BP4" + ], + "GOV-15": [ + "UP-01-BP2" + ], + "GOV-15.1": [ + "DLL-01-BP1" ], "AST-01": [ "AM-03" ], + "AST-01.2": [ + "AM-02" + ], "AST-02": [ "AM-01", - "AM-02" + "RB-12" ], "AST-02.1": [ + "AM-01" + ], + "AST-02.9": [ "AM-01", - "AM-02" + "AM-01-DOAR", + "RB-12" ], - "AST-02.2": [ + "AST-03": [ "AM-02" ], - "AST-02.4": [ - "SP-03" - ], "AST-04": [ - "COS-07" - ], - "AST-06.1": [ - "AM-02" + "KOS-06" ], "AST-09": [ - "AM-04", - "PI-03" + "AM-04" ], "AST-10": [ - "AM-04", - "AM-05" + "AM-04" ], "BCD-01": [ + "UP-01-BP4", + "RB-06", "BCM-01", "BCM-02", - "BCM-03" + "BCM-02-BP1", + "BCM-02-BP2", + "BCM-02-BP3", + "BCM-02-BP4", + "BCM-02-BP5", + "BCM-02-BP6", + "BCM-02-BP7", + "BCM-02-BP8", + "BCM-02-BP9", + "BCM-02-BP10", + "BCM-03", + "BCM-03-BP1", + "BCM-03-BP2", + "BCM-03-BP3", + "BCM-03-BP4", + "BCM-03-BP5", + "BCM-03-BP6", + "BCM-03-BP7", + "BCM-03-BP8" ], "BCD-01.4": [ - "OPS-06", - "OPS-08", - "OPS-09" + "BCM-02-BP6", + "BCM-02-BP8", + "BCM-02-BP9" ], "BCD-02": [ - "BCM-02" + "RB-12", + "BCM-02-BP4" ], - "BCD-04": [ - "PS-02", - "PS-06", - "BCM-04" + "BCD-02.3": [ + "BCM-02-BP7" ], - "BCD-05": [ - "BCM-04" + "BCD-02.4": [ + "BCM-05" + ], + "BCD-04": [ + "PS-03-BP6", + "BCM-04", + "BCM-04-DOAR", + "BCM-05-DOAR" ], "BCD-06": [ "BCM-04" ], - "BCD-08": [ - "PSS-12" - ], - "BCD-08.1": [ - "OPS-09" - ], - "BCD-09": [ - "PSS-12" - ], - "BCD-09.1": [ - "OPS-09" - ], "BCD-11": [ - "OPS-06" + "RB-06", + "RB-07" ], "BCD-11.1": [ - "OPS-06", - "OPS-07", - "OPS-08" + "RB-07" ], "BCD-11.2": [ - "OPS-06", - "PSS-12" + "RB-09" ], - "BCD-11.3": [ - "OPS-09" + "BCD-11.4": [ + "RB-06-DOAR" ], - "BCD-11.7": [ - "PS-02" + "BCD-11.5": [ + "RB-08" ], "CAP-01": [ - "OPS-01", - "OPS-02", - "OPS-03" + "RB-01" ], "CAP-03": [ - "OPS-01", - "OPS-02", - "OPS-03" + "RB-01", + "RB-01-DOAR" + ], + "CAP-04": [ + "RB-02" + ], + "CAP-05": [ + "RB-02" ], "CHG-01": [ - "DEV-03", - "DEV-08" + "BEI-03", + "BEI-03-BP1", + "BEI-03-BP2", + "BEI-05", + "BEI-06", + "BEI-08" ], "CHG-02": [ - "DEV-08" + "BEI-08", + "BEI-09-DOAR" ], "CHG-02.1": [ - "IDM-02" + "BEI-12" ], "CHG-02.2": [ - "DEV-06", - "DEV-08", - "DEV-09" - ], - "CHG-02.3": [ - "DEV-05", - "DEV-09" + "BEI-03-BP3", + "BEI-03-BP4", + "BEI-07", + "BEI-09" ], "CHG-03": [ - "DEV-05", - "BCM-02" + "BEI-04", + "BEI-06" ], - "CHG-04": [ - "DEV-09" + "CHG-05": [ + "BEI-03-BP2" ], - "CHG-04.4": [ - "DEV-09", - "PSS-08" + "CHG-07": [ + "BEI-10" ], - "CHG-04.5": [ - "DEV-07", - "DEV-08" + "CHG-07.1": [ + "BEI-10" ], "CLD-01": [ - "COS-01", - "COS-02" + "UP-01", + "UP-01-BP1", + "UP-01-BP2", + "RB-05" ], - "CLD-02": [ - "COS-01", - "COS-02" - ], - "CLD-03": [ - "COS-01", - "COS-02", - "COS-05" + "CLD-01.2": [ + "PI-02", + "PI-05" ], "CLD-04": [ - "PI-01" - ], - "CLD-05": [ - "PSS-11" + "PI-01", + "PI-04" ], "CLD-06": [ - "OPS-24" + "RB-23" ], - "CLD-07": [ - "PI-01", - "PI-02" + "CLD-06.1": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03" ], - "CLD-08": [ - "PSS-11" + "CLD-06.2": [ + "RB-10" ], - "CLD-09": [ + "CLD-07": [ + "PI-01", "PI-02", - "PSS-12" + "PI-03" ], - "CLD-11": [ - "COS-04" + "CLD-09": [ + "UP-02", + "RB-03" ], "CPL-01": [ - "SP-01", + "SA-01-BP6", "PI-02", + "DLL-01-BP2", "COM-01" ], - "CPL-02": [ - "SP-03" + "CPL-01.1": [ + "SPN-02" ], - "CPL-03": [ - "COM-03" + "CPL-01.3": [ + "UP-04", + "SPN-03-DOAR", + "COM-02-DOAR", + "COM-03-DOAR" ], - "CPL-03.1": [ - "COM-03" + "CPL-02": [ + "RB-05-DOAR", + "SPN-02", + "COM-02" ], - "CPL-03.2": [ - "COM-01" + "CPL-02.1": [ + "SPN-03" ], - "CPL-04": [ + "CPL-02.2": [ + "RB-05-DOAR", + "SPN-02", + "SPN-02-DOAR", "COM-02", + "COM-02-BP1", + "COM-02-BP2", + "COM-02-BP3", "COM-03" ], - "CPL-05": [ - "INQ-01" - ], - "CPL-05.1": [ - "INQ-02" - ], - "CPL-05.2": [ - "INQ-03", - "INQ-04" - ], - "CFG-01": [ - "AM-03" + "CPL-03": [ + "OIS-01-BP2", + "OIS-01-BP3" ], "CFG-02": [ - "AM-02", - "AM-03", - "OPS-23" - ], - "CFG-03.3": [ - "AM-02" + "RB-05", + "RB-22", + "RB-22-DOAR", + "IDM-11", + "IDM-11-BP1", + "IDM-11-BP2", + "IDM-11-BP3", + "IDM-11-BP4", + "IDM-11-BP5", + "IDM-11-DOAR", + "IDM-11-DOAR-BP1", + "IDM-11-DOAR-BP2", + "IDM-11-DOAR-BP3", + "IDM-11-DOAR-BP4", + "IDM-11-DOAR-BP5", + "IDM-11-DOAR-BP6", + "IDM-11-DOAR-BP7" ], "MON-01": [ - "OPS-10" - ], - "MON-01.2": [ - "OPS-13" - ], - "MON-01.4": [ - "OPS-13" - ], - "MON-01.16": [ - "OPS-10" + "RB-10" ], "MON-02": [ - "OPS-14" - ], - "MON-02.1": [ - "OPS-13" + "RB-10", + "RB-13", + "RB-16-DOAR", + "SIM-05" ], "MON-02.2": [ - "OPS-13" + "RB-10", + "SIM-05" ], - "MON-02.6": [ - "OIS-05" + "MON-02.7": [ + "RB-14" ], - "MON-03": [ - "OPS-15" + "MON-02.8": [ + "RB-15" ], - "MON-03.3": [ - "OPS-16" + "MON-03": [ + "RB-10" ], - "MON-05": [ - "OPS-17" + "MON-03.2": [ + "RB-14", + "RB-16" ], "MON-05.1": [ - "OPS-17" + "RB-16-DOAR" ], - "MON-08": [ - "OPS-16" + "MON-06": [ + "RB-16" ], - "MON-08.2": [ - "OPS-16" + "MON-08": [ + "RB-16" ], "MON-10": [ - "OPS-14" + "RB-13" ], "CRY-01": [ - "CRY-01" + "KRY-01", + "KRY-01-BP1", + "KRY-01-BP2", + "KRY-01-BP3", + "KRY-01-BP4", + "KRY-02" ], "CRY-03": [ - "CRY-02" - ], - "CRY-04": [ - "OPS-09" + "KRY-02", + "KRY-02-DOAR" ], "CRY-05": [ - "CRY-03" - ], - "CRY-05.1": [ - "CRY-03" + "KRY-02", + "KRY-03" ], "CRY-09": [ - "CRY-04" + "KRY-03", + "KRY-04", + "KRY-04-BP1", + "KRY-04-BP3", + "KRY-04-BP4", + "KRY-04-BP5", + "KRY-04-BP6", + "KRY-04-BP7", + "KRY-04-BP8" ], "DCH-01": [ - "COS-08" + "AM-07", + "RB-23" ], "DCH-01.1": [ "AM-06" ], + "DCH-01.2": [ + "AM-07", + "RB-11" + ], "DCH-02": [ "AM-02", + "AM-05", "AM-06", - "COS-08", - "PI-01" + "PI-01", + "SIM-02" ], "DCH-04": [ "AM-06" ], - "DCH-08": [ - "PI-03" + "DCH-07": [ + "AM-08" ], - "DCH-21": [ - "PI-03" + "DCH-09": [ + "PI-05" + ], + "DCH-11": [ + "SIM-02" + ], + "DCH-14.2": [ + "AM-08" + ], + "DCH-18": [ + "RB-06" + ], + "DCH-19": [ + "UP-02", + "RB-03" ], "END-04": [ - "OPS-04", - "OPS-05" + "RB-05" + ], + "HRS-01": [ + "HR-02", + "KOS-08-DOAR" + ], + "HRS-02": [ + "HR-01-DOAR" ], "HRS-03": [ - "PSS-08" + "UP-01-BP5", + "OIS-03-BP1", + "OIS-03-BP2", + "OIS-03-BP3", + "SA-01-BP3" ], "HRS-04": [ - "HR-01" + "HR-01", + "HR-01-BP1", + "HR-01-BP2", + "HR-01-BP3", + "HR-01-BP4" ], "HRS-04.1": [ "HR-01", - "PSS-08" + "HR-01-DOAR" ], "HRS-05": [ "HR-02", - "HR-03", - "AM-05" - ], - "HRS-05.1": [ - "HR-03" + "HR-05", + "AM-04" ], - "HRS-05.5": [ - "AM-05" + "HRS-05.7": [ + "HR-02" ], "HRS-06": [ "HR-02" ], "HRS-06.1": [ - "HR-06", - "IDM-08", - "PSS-07" + "IDM-07-DOAR", + "KOS-08" ], "HRS-07": [ "HR-04" @@ -101108,9700 +103545,10027 @@ ], "HRS-11": [ "OIS-04", - "IDM-01" - ], - "HRS-12": [ - "PSS-08" + "OIS-04-BP1", + "OIS-04-BP2", + "OIS-04-BP3", + "OIS-04-DOAR", + "IDM-01-BP2", + "IDM-01-BP3", + "BEI-12" ], "IAC-01": [ "IDM-01", - "PSS-05", - "PSS-09" - ], - "IAC-02": [ - "IDM-01", - "PSS-05", - "PSS-09" - ], - "IAC-03": [ - "PSS-05", - "PSS-09" + "IDM-03" ], - "IAC-03.2": [ - "PSS-05", - "PSS-09" + "IAC-01.2": [ + "IDM-02", + "IDM-03-BP2", + "IDM-08-BP2" ], - "IAC-04": [ - "PSS-05", - "PSS-09" + "IAC-06": [ + "RB-15-DOAR", + "IDM-08-BP3" ], - "IAC-05": [ - "PSS-05", - "PSS-09" + "IAC-06.3": [ + "RB-15-DOAR" ], "IAC-07": [ - "IDM-01", - "IDM-02", - "PSS-09" - ], - "IAC-07.1": [ - "PS-04", - "PSS-08" + "IDM-01-BP1", + "IDM-01-BP5", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-04", + "IDM-05" ], "IAC-08": [ - "PSS-08", - "PSS-11" + "RB-15", + "IDM-01", + "IDM-01-BP3", + "BEI-12" ], - "IAC-09": [ - "IDM-01" + "IAC-10.5": [ + "IDM-07", + "IDM-08" ], - "IAC-09.5": [ + "IAC-15": [ "IDM-02" ], - "IAC-10": [ - "IDM-08" - ], - "IAC-10.1": [ - "IDM-09", - "PSS-07" + "IAC-15.1": [ + "IDM-03-BP2", + "IDM-08-BP2" ], - "IAC-10.2": [ + "IAC-15.9": [ "IDM-09" ], - "IAC-10.4": [ - "PSS-07" - ], - "IAC-10.5": [ - "IDM-08", - "PSS-07" - ], - "IAC-15.2": [ - "IDM-04", - "PSS-09" - ], - "IAC-15.3": [ - "IDM-03" - ], "IAC-16": [ "IDM-06" ], "IAC-17": [ - "IDM-05" + "IDM-01-BP4", + "IDM-05", + "IDM-05-DOAR", + "IDM-09-DOAR" ], "IAC-20.3": [ - "IDM-06" + "IDM-12" ], "IAC-21": [ - "IDM-07" - ], - "IAC-23": [ - "PSS-06" + "IDM-03-BP1", + "IDM-03-BP2", + "IDM-03-BP4", + "IDM-10", + "IDM-12", + "IDM-13" ], - "IAC-24": [ - "PSS-06" - ], - "IAC-25": [ - "PSS-06" + "IAC-28": [ + "IDM-08-BP1" ], "IAC-28.1": [ - "IDM-01", - "IDM-02" + "IDM-01-BP1", + "IDM-01-BP6", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-06", + "IDM-09", + "BEI-09" ], "IRO-01": [ - "SIM-01" - ], - "IRO-02": [ - "SIM-02" + "UP-01-BP4", + "SIM-01", + "SIM-07" ], - "IRO-02.5": [ - "OPS-21" + "IRO-02.4": [ + "SIM-03", + "SIM-07" ], - "IRO-04.1": [ - "SIM-02" + "IRO-04": [ + "SIM-03" ], "IRO-08": [ - "SIM-03" + "SIM-01-DOAR" + ], + "IRO-09": [ + "SIM-07" ], "IRO-10": [ - "SIM-03", + "RB-20", "SIM-04" ], - "IRO-10.3": [ - "PSS-02" - ], - "IRO-12.3": [ - "OPS-21" - ], "IRO-13": [ - "SIM-05" + "SIM-04" + ], + "IAO-03": [ + "UP-01-BP2", + "UP-01-BP3", + "UP-01-BP5" ], "IAO-03.2": [ - "HR-06", - "PI-02" + "BEI-02", + "BEI-02-BP1", + "BEI-02-BP2", + "BEI-02-BP3", + "BEI-02-BP4" ], - "NET-01": [ - "PSS-10" + "MNT-01": [ + "PS-05" ], - "NET-02": [ - "PSS-10" + "MDM-01": [ + "MDM-01", + "MDM-01-BP2", + "MDM-01-BP3", + "MDM-01-BP5", + "MDM-01-DOAR" ], - "NET-03": [ - "COS-04", - "PSS-10" + "MDM-03": [ + "MDM-01-BP1" ], - "NET-03.1": [ - "COS-04" + "MDM-04": [ + "MDM-01-BP4" ], - "NET-03.2": [ - "COS-03" + "MDM-06": [ + "MDM-01-BP6" ], - "NET-04": [ - "COS-03" + "NET-02": [ + "KOS-01", + "KOS-03-DOAR" ], - "NET-04.6": [ - "COS-03" + "NET-02.1": [ + "KOS-01" ], - "NET-05": [ - "COS-03" + "NET-02.3": [ + "KOS-03" + ], + "NET-03": [ + "KOS-01", + "KOS-02", + "KOS-03" + ], + "NET-03.8": [ + "KOS-02" ], "NET-06": [ - "COS-06" + "RB-23-DOAR", + "KOS-05" ], - "NET-06.1": [ - "COS-04" + "NET-06.2": [ + "KOS-05-DOAR" ], - "NET-09": [ - "PSS-06" + "NET-06.4": [ + "KOS-05" ], - "NET-09.1": [ - "PSS-06" + "NET-06.8": [ + "KOS-04" ], - "PES-01": [ - "PS-01" + "NET-08": [ + "KOS-01", + "KOS-01-DOAR" ], - "PES-03": [ - "PS-03", - "PS-04" + "NET-12": [ + "PI-04" ], - "PES-03.1": [ + "PES-01": [ + "PS-01", + "PS-02", "PS-03" ], - "PES-03.4": [ - "PS-04" + "PES-01.1": [ + "PS-02", + "PS-03" ], - "PES-04": [ - "PS-04" + "PES-01.2": [ + "PS-01-DOAR", + "PS-03-BP1" ], - "PES-06": [ - "PS-04" + "PES-03": [ + "PS-02-DOAR" ], "PES-07": [ - "PS-01", - "PS-06" + "PS-04" ], "PES-07.3": [ - "PS-01", - "PS-06" + "PS-04" ], - "PES-07.5": [ - "PS-01" + "PES-07.7": [ + "PS-04" ], "PES-08": [ - "PS-01", - "PS-05" + "PS-03-BP1", + "PS-03-BP2", + "PS-03-BP4", + "PS-03-BP6" ], "PES-08.1": [ - "PS-05" + "PS-03-BP5" ], "PES-08.2": [ - "PS-05" - ], - "PES-08.3": [ - "PS-05" + "PS-03-BP5" ], "PES-09": [ - "PS-06", - "PS-07" - ], - "PES-09.1": [ - "PS-06", - "PS-07" + "PS-03-BP3", + "PS-03-DOAR" ], - "PES-11": [ - "PS-02" + "PES-12.1": [ + "PS-04" ], - "PRI-05": [ - "OPS-11", - "OPS-12", - "PI-03" + "PRM-01.1": [ + "SA-02-DOAR" ], - "PRI-07.1": [ - "HR-06", - "PI-02" + "PRM-02.1": [ + "SA-02-BP3" ], "RSK-01": [ - "OIS-06" + "OIS-06", + "OIS-07" + ], + "RSK-01.3": [ + "OIS-07-DOAR" + ], + "RSK-01.5": [ + "OIS-07-DOAR" ], "RSK-03": [ - "SP-03" + "OIS-03-DOAR", + "OIS-07" + ], + "RSK-03.1": [ + "OIS-03-DOAR" ], "RSK-04": [ "OIS-07", - "SP-03" + "BEI-06" ], "RSK-04.1": [ - "SP-03" - ], - "RSK-08": [ - "BCM-02" + "OIS-03-DOAR" ], - "RSK-09": [ + "RSK-04.2": [ "OIS-07" ], - "RSK-10": [ - "BCM-02" - ], - "SEA-01": [ - "COS-01" - ], - "SEA-02": [ - "COS-01" - ], - "SEA-03": [ - "COS-01" - ], - "SEA-05": [ - "OPS-24", - "COS-06" + "RSK-06.2": [ + "OIS-04-DOAR", + "SA-03-DOAR" ], - "SEA-13.1": [ - "PSS-11" + "RSK-08": [ + "BCM-02-BP5", + "BCM-04" ], - "OPS-01": [ - "SP-01" + "RSK-09": [ + "OIS-07", + "PS-04-DOAR" ], - "OPS-01.1": [ - "SP-01", - "IDM-02" + "SEA-01": [ + "UP-01-BP2", + "DLL-01-BP1" ], - "OPS-05": [ - "PSS-01" + "SEA-01.4": [ + "UP-01-BP2", + "SA-01-BP5" ], "SAT-01": [ - "HR-03", - "DEV-04" + "HR-03" ], "SAT-02": [ - "HR-03", - "DEV-04" + "HR-03" ], "SAT-03": [ - "DEV-04" + "HR-03", + "HR-03-BP1", + "HR-03-BP4", + "HR-03-DOAR" ], - "SAT-03.4": [ - "DEV-04" + "SAT-03.3": [ + "HR-03-BP2" + ], + "SAT-03.6": [ + "HR-03-BP3" ], "TDA-01": [ - "DEV-01" + "BEI-01" ], - "TDA-02": [ - "DEV-02" + "TDA-02.11": [ + "RB-21-DOAR" ], "TDA-04": [ - "DEV-02" - ], - "TDA-04.1": [ - "DEV-02" - ], - "TDA-05": [ - "DEV-02" + "UP-01", + "KOS-07" ], "TDA-06": [ - "DEV-02", - "DEV-07", - "DEV-08" + "UP-01-BP2", + "BEI-01-BP1", + "BEI-01-BP4", + "BEI-01-DOAR", + "BEI-02" ], - "TDA-07": [ - "DEV-02", - "DEV-10" + "TDA-06.7": [ + "BEI-01-BP3" ], "TDA-08": [ - "DEV-10" - ], - "TDA-09": [ - "DEV-02" - ], - "TDA-09.2": [ - "PSS-02" - ], - "TDA-09.3": [ - "PSS-02" - ], - "TDA-09.4": [ - "PSS-02" - ], - "TDA-09.5": [ - "PSS-02" - ], - "TDA-13": [ - "DEV-02" - ], - "TDA-14": [ - "DEV-02" - ], - "TDA-15": [ - "DEV-02" - ], - "TDA-19": [ - "PSS-04" + "BEI-01-BP2", + "BEI-11" ], "TDA-20": [ - "DEV-07" + "IDM-13" ], "TPM-01": [ - "SSO-01", - "SSO-03" - ], - "TPM-02": [ - "SSO-02", - "SSO-03" + "UP-01", + "DLL-01", + "DLL-02" ], "TPM-03": [ - "SSO-02", - "SSO-03" - ], - "TPM-03.1": [ - "SSO-05" + "PS-04-DOAR" ], "TPM-03.2": [ - "SSO-02" - ], - "TPM-03.3": [ - "SSO-02" + "UP-01-BP1" ], "TPM-04": [ - "SSO-05" + "PS-04-DOAR" ], - "TPM-04.1": [ - "SSO-02", - "SSO-04" + "TPM-05": [ + "UP-01-BP1", + "UP-01-BP6", + "UP-03", + "OIS-03", + "DLL-01", + "DLL-01-BP1", + "DLL-01-BP2", + "DLL-01-BP3", + "DLL-01-BP4", + "BCM-05" ], - "TPM-04.4": [ - "PI-02", - "PSS-12" + "TPM-05.1": [ + "RB-20" ], - "TPM-05": [ - "HR-06", - "PI-02", - "SSO-02", - "SSO-05" + "TPM-05.2": [ + "UP-01-BP6", + "DLL-01-BP2", + "DLL-01-BP4", + "DLL-01-DOAR" ], - "TPM-07": [ - "SSO-04" + "TPM-05.4": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03", + "SIM-06" ], - "TPM-08": [ - "SSO-04", - "SSO-05" + "TPM-05.5": [ + "UP-01-BP1" ], - "TPM-09": [ - "SSO-04" + "TPM-05.8": [ + "UP-04" + ], + "TPM-08": [ + "DLL-02", + "DLL-02-BP1", + "DLL-02-BP2", + "DLL-02-BP3" ], "TPM-10": [ - "SSO-04", - "SSO-05" + "OIS-03" ], - "VPM-01": [ - "OPS-18", - "PSS-02" + "THR-01": [ + "OIS-05-DOAR" ], - "VPM-01.1": [ - "PSS-02" + "THR-03": [ + "OIS-05" ], - "VPM-02": [ - "OPS-18", - "PSS-02" + "THR-03.1": [ + "OIS-05-DOAR" + ], + "VPM-01": [ + "RB-17", + "RB-17-BP2" ], "VPM-03": [ - "OPS-18", - "OPS-22", - "PSS-02" + "RB-17-BP1", + "RB-19" + ], + "VPM-03.1": [ + "RB-17-BP1", + "RB-19" ], "VPM-04": [ - "OPS-18", - "PSS-02" + "RB-17-BP2", + "RB-19", + "RB-21" ], "VPM-05": [ - "PSS-03" + "RB-17-BP2" ], "VPM-05.1": [ - "PSS-03" - ], - "VPM-05.3": [ - "OPS-19" + "RB-17-BP2" ], "VPM-06": [ - "OPS-22", - "PSS-02", - "PSS-03" - ], - "VPM-06.1": [ - "PSS-03" - ], - "VPM-06.4": [ - "OPS-20" - ], - "VPM-06.5": [ - "OPS-20" - ], - "VPM-06.6": [ - "PSS-02" - ], - "VPM-06.7": [ - "PSS-02" + "RB-17-BP1", + "RB-21" ], "VPM-07": [ - "OPS-19", - "PSS-02" - ], - "VPM-07.1": [ - "OPS-19", - "PSS-02" - ], - "WEB-06": [ - "PSS-05" + "RB-18", + "RB-18-DOAR" ] }, "emea-grc-pirppd-1997": { - "GOV-01": [ - "10" + "GOV-17": [ + "B.7.7", + "B.8.2" ], "CPL-01": [ - "10" + "B.5.3" ], - "CPL-02": [ - "10" + "HRS-01": [ + "B.10.2" ], - "DCH-01": [ - "9" + "PRI-01.5": [ + "B.9.1.b", + "B.9.2" ], - "DCH-22.1": [ - "13" + "PRI-01.6": [ + "B.9.2.f", + "B.10.1", + "B.10.2", + "B.10.3" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-01.7": [ + "C.11.3" + ], + "PRI-01.11": [ + "B.4.1.a", + "B.4.1.b", + "B.7.2.b", + "B.7.2.c", + "B.7.2.d", + "B.7.2.e", + "B.7.2.f", + "B.7.2.g", + "B.9.2.f", + "C.11.4", + "C.11.5", + "C.12.3" + ], + "PRI-02": [ + "C.11.1", + "C.11.1.a", + "C.11.1.b", + "C.11.1.c", + "C.11.1.d", + "C.11.2", + "C.11.3" ], "PRI-03": [ - "5" + "B.5.1", + "B.7.2.a" + ], + "PRI-03.3": [ + "B.7.1", + "B.9.1", + "B.9.1.a" ], "PRI-04": [ - "4" + "B.4.1.a", + "B.4.1.b" ], "PRI-04.1": [ - "4" + "B.4.1.a", + "B.4.1.b", + "B.5.2", + "B.5.2.a", + "B.5.2.b", + "B.5.2.c", + "B.5.2.d", + "B.5.2.e", + "B.8.3" ], "PRI-05": [ - "4", - "7" + "B.4.1.d", + "B.4.2" + ], + "PRI-05.1": [ + "B.7.2.f" + ], + "PRI-05.4": [ + "B.7.1", + "B.7.2", + "B.8.3" ], "PRI-06": [ - "11", - "12" + "C.12.1", + "C.12.2", + "C.12.2.a", + "C.12.2.b", + "C.12.2.c", + "C.12.2.d", + "C.12.2.e", + "C.12.2.f" ], "PRI-06.1": [ - "13" + "B.4.1.c", + "C.12.2.e" ], - "PRI-06.3": [ - "13" + "PRI-06.5": [ + "C.12.2.e" ], - "PRI-15": [ - "6" + "PRI-07": [ + "B.9.1", + "B.9.2.a", + "B.9.2.b", + "B.9.2.b.i", + "B.9.2.b.ii", + "B.9.2.b.iii", + "B.9.2.c", + "B.9.2.d", + "B.9.2.e" ], - "SEA-01": [ - "9" + "PRI-07.1": [ + "B.10.4" ], - "SEA-02": [ - "9" + "PRI-07.2": [ + "B.8.1" ], - "SEA-03": [ - "9" + "PRI-07.3": [ + "C.12.2.f" + ], + "PRI-10": [ + "B.4.1.c" + ], + "PRI-15": [ + "B.6.1", + "B.6.2", + "B.6.2.a", + "B.6.2.b", + "B.6.2.c", + "B.6.2.d", + "B.6.2.e", + "B.6.2.f", + "B.6.2.g", + "B.6.2.h", + "B.6.3", + "B.6.4" + ], + "PRI-17": [ + "C.11.3" + ], + "PRI-19.3": [ + "C.12.2.d" ] }, - "emea-hun-isdfi-2011": { - "GOV-01": [ - "7" + "emea-hun-act-cxii-2011": { + "GOV-17": [ + "II.13.16(3)" ], "CPL-01": [ - "7" + "II.5.5(2)(b)", + "II.5.6(1)(a)", + "II.5.6(5)(a)" ], - "CPL-02": [ - "7" + "DCH-02": [ + "II.4.4(3)" ], - "CPL-03": [ - "7" + "DCH-23": [ + "II.11.12(2)" ], - "DCH-01": [ - "7", - "8" + "HRS-03": [ + "II.18.24(2)" ], - "DCH-22.1": [ - "14", - "15", - "17" + "PRI-01": [ + "II.6.7(1)" ], - "DCH-24": [ - "7" + "PRI-01.4": [ + "II.18.24(1)(a)", + "II.18.24(1)(b)", + "II.18.24(1)(c)", + "II.18.24(2)", + "II.18.24(2)(a)", + "II.18.24(2)(b)", + "II.18.24(2)(c)", + "II.18.24(2)(d)", + "II.18.24(2)(e)", + "II.18.24(2)(f)" ], - "DCH-24.1": [ - "7" + "PRI-01.5": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-01.6": [ + "II.6.7(2)", + "II.6.7(3)", + "II.6.7(4)", + "II.6.7(5)(a)", + "II.6.7(5)(b)", + "II.6.7(5)(c)", + "II.6.7(5)(d)", + "II.6.7(5)(e)", + "II.6.7(5)(f)", + "II.6.7(6)" ], - "PRI-01.1": [ - "24" + "PRI-01.11": [ + "II.5.6(1)(a)", + "II.5.6(5)(b)", + "II.6.7(1)", + "II.8.9(1)(c)", + "II.8.9(1)(d)", + "II.10.11(1)(a)", + "II.13.16(1)", + "II.13.17(3)", + "II.13.17(4)", + "II.13.17(5)", + "II.14.20(4)(e)", + "II.14.20(4)(f)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)", + "II.15.21(3)", + "II.15.21(7)", + "II.18.24(3)" + ], + "PRI-02": [ + "II.5.6(4)", + "II.7.8(1)(a)", + "II.14.20(1)", + "II.14.20(2)", + "II.14.20(4)(a)", + "II.14.20(4)(b)", + "II.14.20(4)(d)" + ], + "PRI-02.1": [ + "II.8.9(1)(a)", + "II.14.20(2)", + "II.14.20(4)(c)" + ], + "PRI-02.13": [ + "II.14.20(4)(f)" ], "PRI-03": [ - "6" + "II.5.5(1)(a)", + "II.5.5(2)(a)", + "II.5.6(3)", + "II.5.6(4)", + "II.7.8(1)(a)", + "II.8.9(4)", + "II.11.12(3)(a)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)" + ], + "PRI-03.3": [ + "II.5.6(3)" + ], + "PRI-03.4": [ + "II.15.21(1)(a)", + "II.15.21(1)(b)" + ], + "PRI-03.6": [ + "II.5.6(2)" + ], + "PRI-03.7": [ + "II.14.20(1)" + ], + "PRI-03.11": [ + "II.13.18(1)" ], "PRI-04": [ - "4", - "5" + "II.4.4(1)", + "II.4.4(2)", + "II.11.12(1)", + "II.12.13(2)" ], "PRI-04.1": [ - "4", - "5" + "II.4.4(1)", + "II.4.4(2)", + "II.4.4(3)", + "II.4.4(5)", + "II.5.5(1)(b)", + "II.5.5(2)(b)", + "II.5.5(2)(c)", + "II.5.5(3)", + "II.5.5(4)", + "II.5.6(1)(b)", + "II.5.6(5)(a)", + "II.10.11(1)(b)", + "II.11.12(1)" ], "PRI-05": [ - "5" + "II.8.9(1)(b)", + "II.13.15(3)", + "II.13.17(2)(a)", + "II.13.17(2)(b)", + "II.13.17(2)(c)", + "II.13.17(2)(d)", + "II.13.17(2)(e)", + "II.14.20(4)(d)", + "II.15.21(7)" ], - "PRI-05.1": [ - "9" + "PRI-05.2": [ + "II.4.4(4)", + "II.13.17(1)" ], "PRI-05.4": [ - "9" + "II.11.12(3)(a)", + "II.11.12(3)(b)", + "II.12.13(2)" ], "PRI-06": [ - "14", - "15" + "II.13.14(a)", + "II.13.14(b)", + "II.13.14(c)", + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)" ], "PRI-06.1": [ - "14", - "15", - "17" + "II.13.17(1)" ], - "PRI-06.2": [ - "14", - "15", - "17", - "18" + "PRI-06.4": [ + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)", + "II.13.16(2)", + "II.13.18(2)", + "II.15.21(2)", + "II.15.21(3)" ], - "PRI-06.3": [ - "14", - "15", - "17", - "18" + "PRI-07": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" ], - "PRI-06.4": [ - "14", - "15", - "17" + "PRI-07.1": [ + "II.7.8(1)(b)", + "II.8.9(1)", + "II.8.9(1)(c)", + "II.8.9(1)(e)", + "II.8.9(2)", + "II.8.9(3)", + "II.8.9(5)", + "II.9.10(1)", + "II.9.10(2)", + "II.9.10(3)", + "II.9.10(4)", + "II.10.11(1)(a)" ], - "PRI-15": [ - "65", - "66" + "PRI-07.3": [ + "II.13.18(1)" ], - "SEA-01": [ - "7", - "8" + "PRI-07.4": [ + "II.13.16(1)" ], - "SEA-02": [ - "7", - "8" + "PRI-14": [ + "II.13.15(2)" ], - "SEA-03": [ - "7", - "8" + "PRI-14.1": [ + "II.13.15(2)" ], - "SEA-15": [ - "7" + "PRI-17": [ + "II.13.16(2)", + "II.13.18(2)" ], - "TPM-04.4": [ - "7" + "PRI-19": [ + "II.10.11(2)" ] }, - "emea-irl-dpa-2003": { - "GOV-01": [ - "2" - ], + "emea-irl-dpa-2018": { "CPL-01": [ - "2" - ], - "CPL-02": [ - "2" - ], - "CPL-03": [ - "2" - ], - "DCH-01": [ - "2" - ], - "DCH-22.1": [ - "2" + "s.83" ], - "DCH-24": [ - "2" + "IRO-10": [ + "s.85", + "s.86" ], - "DCH-24.1": [ - "2" + "IRO-10.2": [ + "s.87" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-01.4": [ + "s.88" ], - "PRI-01.1": [ - "2" + "PRI-01.5": [ + "s.96", + "s.97", + "s.98", + "s.99", + "s.100" ], - "PRI-02.1": [ - "2" + "PRI-01.6": [ + "s.72", + "s.75", + "s.76", + "s.77", + "s.78" ], - "PRI-03": [ - "2" + "PRI-01.11": [ + "s.71", + "s.94" ], - "PRI-04": [ - "2" + "PRI-02": [ + "s.90" ], - "PRI-04.1": [ - "2" + "PRI-05.2": [ + "s.74" ], - "PRI-05": [ - "2" + "PRI-05.4": [ + "s.45", + "s.46", + "s.47", + "s.48", + "s.49", + "s.50", + "s.51", + "s.52", + "s.53", + "s.54", + "s.55", + "s.73" ], "PRI-06": [ - "2" - ], - "PRI-06.1": [ - "2" - ], - "PRI-06.2": [ - "2" - ], - "PRI-06.3": [ - "2" + "s.56", + "s.57", + "s.58", + "s.59", + "s.60", + "s.61", + "s.91", + "s.92" ], - "PRI-15": [ - "17" + "PRI-06.4": [ + "s.93" ], - "SEA-01": [ - "2" + "PRI-07.1": [ + "s.80" ], - "SEA-02": [ - "2" + "PRI-07.2": [ + "s.79" ], - "SEA-03": [ - "2" + "PRI-14": [ + "s.81", + "s.82" ], - "SEA-15": [ - "2" + "PRI-19": [ + "s.89" ], - "TPM-04.4": [ - "2" + "RSK-10": [ + "s.84" ] }, - "emea-isr-cmo-1-0": { + "emea-isr-cmo-2-0": { "GOV-01": [ - "3.2", - "4.25" + "2.A", + "4.2, Stage 0" ], - "GOV-02": [ - "1.1", - "4.1", - "4.25", - "5.2", - "5.3", - "9.1", - "10.1", - "11.2", - "12.1", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "20.1", - "21.1", - "22.1", - "24.1", - "25.1" + "GOV-01.1": [ + "2.A" + ], + "GOV-01.3": [ + "4.1, Stage 5", + "Appendix A, 1.1" ], "GOV-03": [ - "1.1", - "5.2", - "9.1", - "10.1", - "11.2", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "21.1", - "22.1", - "24.1", - "25.1" + "Appendix A, 1.1" ], - "AST-02.4": [ - "6.8" + "GOV-04": [ + "4.2, Stage 1.1" ], - "AST-02.5": [ - "23.6" + "GOV-04.1": [ + "4.2, Stage 1.1" ], - "AST-02.7": [ - "3.1" + "GOV-04.2": [ + "4.2, Stage 1.1" ], - "AST-09": [ - "15.4", - "17.21" + "GOV-05": [ + "4.2, Stage 5", + "Appendix D" ], - "AST-10": [ - "11.12" + "AST-02": [ + "4.1, Stage 1" ], - "AST-12": [ - "12.6" + "AST-04": [ + "4.1, Stage 1" ], - "AST-13": [ - "12.6" + "BCD-11": [ + "Appendix A, 14.1" ], - "BCD-01": [ - "11.7", - "25.1" + "CAP-02": [ + "Appendix A, 7.1" ], - "BCD-01.1": [ - "25.2" + "CLD-02": [ + "Appendix A, 6.1" ], - "BCD-02.1": [ - "21.15", - "21.16" + "CLD-06.1": [ + "Appendix A, 5.1" ], - "BCD-02.2": [ - "18.15", - "25.23" + "CLD-10": [ + "Appendix A, 6.1" ], - "BCD-02.3": [ - "21.15", - "21.16" + "CPL-02": [ + "4.1, Stage 5" ], - "BCD-03": [ - "25.3" + "CPL-02.1": [ + "4.1, Stage 5" ], - "BCD-03.1": [ - "25.4", - "25.5" + "CPL-03": [ + "4.2, Stage 5" ], - "BCD-03.2": [ - "25.8" + "CFG-02": [ + "Appendix A, 3.1", + "Appendix A, 4.1", + "Appendix A, 4.2" ], - "BCD-04": [ - "25.4", - "25.6", - "25.7", - "25.9", - "25.23" + "MON-03": [ + "Appendix A, 12.2" ], - "BCD-04.1": [ - "25.6", - "25.7" + "CRY-01": [ + "Appendix A, 3.1" ], - "BCD-08": [ - "11.7", - "25.7", - "25.10" + "DCH-01.2": [ + "Appendix A, 5.2" ], - "BCD-08.1": [ - "25.11" + "DCH-02": [ + "Appendix A, 5.2" ], - "BCD-08.2": [ - "25.13" + "DCH-14": [ + "Appendix A, 5.2" ], - "BCD-09": [ - "11.7", - "25.7", - "25.10" + "END-04": [ + "Appendix A, 2.1" ], - "BCD-09.1": [ - "25.11" + "END-04.1": [ + "Appendix A, 2.2" ], - "BCD-09.2": [ - "25.13" + "END-04.7": [ + "Appendix A, 2.1" ], - "BCD-09.3": [ - "25.12", - "21.14" + "HRS-05.1": [ + "Appendix A, 9.1" ], - "BCD-10": [ - "21.14", - "25.16" + "HRS-08": [ + "Appendix A, 9.2" ], - "BCD-10.1": [ - "21.14", - "25.17" + "HRS-09": [ + "Appendix A, 9.2" ], - "BCD-11": [ - "25.9" + "IAC-01": [ + "Appendix A, 8.2" ], - "BCD-11.1": [ - "25.9", - "25.19" + "IAC-07": [ + "Appendix A, 9.2" ], - "BCD-11.2": [ - "25.20" + "IAC-07.1": [ + "Appendix A, 9.2" ], - "BCD-11.3": [ - "25.12", - "25.22" + "IAC-07.2": [ + "Appendix A, 9.2" ], - "BCD-11.4": [ - "25.18" + "IAC-15": [ + "Appendix A, 8.1" ], - "BCD-12": [ - "25.9", - "25.12", - "25.22" + "IRO-02": [ + "Appendix A, 12.1" ], - "BCD-12.1": [ - "25.9", - "25.21" + "IRO-02.4": [ + "Appendix B" ], - "BCD-12.2": [ - "12.26", - "25.12" + "IRO-09": [ + "Appendix A, 13.1" ], - "BCD-13": [ - "25.12", - "25.18" + "IAO-01.1": [ + "4.2, Stage 1.3" ], - "CAP-01": [ - "25.2" + "IAO-05": [ + "4.2, Stage 4" ], - "CAP-03": [ - "25.2" + "NET-03": [ + "Appendix A, 7.3" ], - "CHG-01": [ - "10.6", - "14.6", - "14.7" + "NET-03.1": [ + "Appendix A, 7.4" ], - "CHG-02": [ - "10.6", - "14.7" + "NET-04.1": [ + "Appendix A, 7.4" ], - "CHG-02.1": [ - "14.7" + "NET-06.9": [ + "Appendix A, 7.5" ], - "CHG-02.2": [ - "10.6", - "12.21", - "12.30", - "14.6", - "14.8", - "14.9", - "14.10" + "NET-10": [ + "Appendix A, 7.2" ], - "CHG-02.3": [ - "14.8" + "PES-07.4": [ + "Appendix A, 11.1" ], - "CHG-03": [ - "10.6", - "14.8" + "PES-08": [ + "Appendix A, 11.2" ], - "CHG-04.4": [ - "10.4" + "PRI-01": [ + "Appendix F" ], - "CHG-06": [ - "10.6", - "12.30", - "14.10" + "PRM-01": [ + "4.1, Stage 4" ], - "CLD-01": [ - "11.2" + "PRM-01.1": [ + "2.A", + "4.1, Stage 4", + "4.2, Stage 1.2" ], - "CLD-03": [ - "9.2" + "PRM-01.2": [ + "4.1, Stages 2-3" ], - "CLD-06": [ - "10.1", - "11.3" + "PRM-02.1": [ + "2.D", + "4.1, Stage 4" ], - "CLD-10": [ - "11.6" + "PRM-03": [ + "4.1, Stage 4" ], - "CLD-11": [ - "9.10", - "11.8", - "16.4" + "RSK-01": [ + "3" ], - "CPL-01": [ - "1.3" + "RSK-01.1": [ + "4.2, Stage 2.1" ], - "CPL-02": [ - "1.3", - "3.1" + "RSK-03": [ + "4.2, Stage 2.1" ], - "CPL-03": [ - "3.1" + "RSK-04": [ + "4.2, Stage 2.2", + "4.2, Stage 2.3" ], - "CPL-03.2": [ - "3.1", - "3.3", - "12.30" + "RSK-04.1": [ + "4.2, Stage 2.2" ], - "CFG-01": [ - "3.3", - "9.22", - "9.23", - "14.1" + "RSK-06": [ + "4.2, Stage 2.3" ], - "CFG-02": [ - "3.3", - "4.9", - "4.12", - "4.15", - "6.1", - "9.21", - "12.13", - "12.24", - "12.29", - "13.5", - "13.6", - "14.2", - "15.6" + "RSK-06.3": [ + "4.2, Stage 3.1" ], - "CFG-02.1": [ - "3.3", - "14.3" + "RSK-06.4": [ + "4.2, Stage 4" ], - "CFG-02.2": [ - "3.3", - "6.2", - "6.4", - "9.22", - "9.23", - "14.3", - "14.4" + "SEA-01.1": [ + "Appendix C" ], - "CFG-02.3": [ - "14.5" + "SEA-03": [ + "2.E" ], - "CFG-02.4": [ - "10.1", - "10.2" + "OPS-02": [ + "4.2, Stage 1.2" ], - "CFG-02.5": [ - "4.12", - "9.21", - "10.7" + "TPM-01": [ + "Appendix A, 10.1" ], - "CFG-02.6": [ - "9.22" + "THR-01": [ + "2.B" ], - "CFG-02.9": [ - "10.7" + "THR-10": [ + "Appendix B" + ] + }, + "emea-isr-ppl-5741-2025": { + "GOV-04": [ + "s.17B" ], - "CFG-03": [ - "4.8", - "4.9", - "12.9", - "12.13" + "HRS-03": [ + "s.17B2" ], - "CFG-03.3": [ - "6.7" + "HRS-03.2": [ + "s.17B3" ], - "CFG-03.4": [ - "4.15", - "9.13" + "HRS-06.1": [ + "s.16" ], - "CFG-05": [ - "6.3" + "PRI-01.4": [ + "s.17B1", + "s.17B2" ], - "CFG-05.2": [ - "6.3" + "PRI-01.6": [ + "s.17" ], - "MON-01": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" + "PRI-01.11": [ + "s.1", + "s.2", + "s.2A", + "s.3", + "s.16" ], - "MON-01.1": [ - "7.4", - "11.11", - "12.18", - "23.6" + "PRI-02": [ + "s.11" ], - "MON-01.2": [ - "11.11", - "12.31" + "PRI-03": [ + "s.1" ], - "MON-01.3": [ - "9.9", - "9.10", - "10.9" + "PRI-06": [ + "s.13", + "s.14" ], - "MON-01.4": [ - "21.2", - "21.4" + "PRI-06.1": [ + "s.14" ], - "MON-01.5": [ - "7.6" + "PRI-07.1": [ + "s.13A" ], - "MON-01.7": [ - "6.4", - "12.19" + "PRI-15": [ + "s.8", + "s.8A", + "s.9", + "s.10" + ] + }, + "emea-ita-pdpc-2018": { + "CPL-01": [ + "Article 1(1)" ], - "MON-01.8": [ - "12.31", - "21.3", - "21.11" + "HRS-03": [ + "Article 2-o(1)", + "Article 2-o(2)" ], - "MON-01.9": [ - "9.14", - "21.20" + "PRI-01.4": [ + "Article 2-q(1)" ], - "MON-01.16": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" + "PRI-01.6": [ + "Article 115(1)", + "Article 115(2)" ], - "MON-02": [ - "4.6", - "12.17", - "21.3", - "21.4", - "21.6", - "21.12" + "PRI-01.11": [ + "Article 75(1)", + "Article 102(1)", + "Article 102(2)(a)", + "Article 102(2)(b)", + "Article 102(2)(c)", + "Article 106(1)", + "Article 106(2)(a)", + "Article 106(2)(b)", + "Article 106(2)(c)", + "Article 106(2)(d)", + "Article 106(2)(g)", + "Article 106(2)(h)", + "Article 106(2)(i)", + "Article 126(1)", + "Article 126(2)", + "Article 126(3)", + "Article 126(4)" ], - "MON-02.1": [ - "4.6", - "12.17", - "21.6", - "21.12", - "21.13", - "21.19" + "PRI-02": [ + "Article 2-d(2)", + "Article 77(1)(a)", + "Article 77(1)(b)", + "Article 78(1)", + "Article 78(2)", + "Article 78(3)", + "Article 132-c(1)" ], - "MON-03": [ - "4.6", - "12.17", - "21.2", - "21.5", - "21.7", - "21.10" + "PRI-03.3": [ + "Article 2-d(1)" ], - "MON-03.1": [ - "21.4" + "PRI-03.6": [ + "Article 82(2)(a)" ], - "MON-03.2": [ - "12.17" + "PRI-03.9": [ + "Article 99(1)" ], - "MON-03.3": [ - "21.10", - "21.21" + "PRI-05": [ + "Article 99(3)" ], - "MON-03.4": [ - "21.5", - "21.21" + "PRI-05.1": [ + "Article 99(3)", + "Article 105(1)", + "Article 105(2)", + "Article 105(3)", + "Article 105(4)" ], - "MON-04": [ - "21.8" + "PRI-05.4": [ + "Article 2-f(1)", + "Article 2-g(1)", + "Article 101(1)", + "Article 101(2)", + "Article 101(3)", + "Article 122(1)" ], - "MON-05": [ - "21.9" + "PRI-14": [ + "Article 110(2)" + ] + }, + "emea-ken-pda-2019": { + "GOV-17": [ + "IV.31(5)" ], - "MON-05.1": [ - "21.9" + "CPL-01": [ + "IV.37(1)", + "IV.37(1)(a)", + "IV.37(1)(b)", + "IV.37(2)", + "IV.37(3)" ], - "MON-06": [ - "21.3", - "21.11", - "21.19", - "21.20" + "CPL-01.3": [ + "IV.32(1)" ], - "MON-08": [ - "21.4", - "21.14", - "21.16" + "DCH-23": [ + "IV.39(2)" ], - "MON-08.1": [ - "21.14", - "21.15", - "21.17" + "DCH-25": [ + "IV.25(h)" ], - "MON-08.2": [ - "21.14" + "IRO-10": [ + "IV.43(1)(b)", + "IV.43(2)", + "IV.43(3)", + "IV.43(4)", + "IV.43(5)", + "IV.43(5)(a)", + "IV.43(5)(b)", + "IV.43(5)(c)", + "IV.43(5)(d)", + "IV.43(5)(e)", + "IV.43(6)", + "IV.43(7)", + "IV.43(8)", + "IV.43(8)(a)", + "IV.43(8)(b)", + "IV.43(8)(c)" ], - "MON-09": [ - "21.14" + "IRO-10.2": [ + "IV.43(1)(a)" ], - "MON-10": [ - "21.4", - "21.15", - "21.17" + "PRI-01": [ + "IV.25" ], - "MON-12": [ - "21.10", - "21.18" + "PRI-01.4": [ + "III.24(1)", + "III.24(1)(a)", + "III.24(1)(b)", + "III.24(1)(c)", + "III.24(2)", + "III.24(3)", + "III.24(4)", + "III.24(5)", + "III.24(6)", + "III.24(7)", + "III.24(7)(a)", + "III.24(7)(b)", + "III.24(7)(c)", + "III.24(7)(d)", + "III.24(7)(e)" ], - "MON-13": [ - "21.15" + "PRI-01.5": [ + "IV.25(h)", + "VI.49(1)", + "VI.49(2)", + "VI.49(3)", + "VI.50" ], - "MON-15": [ - "21.10" + "PRI-01.6": [ + "IV.41(1)", + "IV.41(1)(a)", + "IV.41(1)(b)", + "IV.41(2)", + "IV.41(3)", + "IV.41(3)(a)", + "IV.41(3)(b)", + "IV.41(3)(c)", + "IV.41(3)(d)", + "IV.41(3)(e)", + "IV.41(4)", + "IV.41(4)(a)", + "IV.41(4)(b)", + "IV.41(4)(c)", + "IV.41(4)(d)", + "IV.41(4)(e)", + "IV.41(4)(f)", + "IV.42(1)", + "IV.42(1)(a)", + "IV.42(1)(b)", + "IV.42(1)(c)", + "IV.42(1)(d)", + "IV.42(2)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], - "MON-16": [ - "4.7", - "21.10", - "21.20" + "PRI-01.11": [ + "IV.25(b)", + "IV.25(d)", + "IV.26", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(e)", + "IV.28(2)(f)", + "IV.28(2)(f)(i)", + "IV.28(2)(f)(ii)", + "IV.28(2)(f)(iii)", + "IV.28(3)", + "IV.33(2)", + "IV.33(3)", + "IV.33(3)(a)", + "IV.33(3)(b)", + "IV.33(3)(c)", + "IV.33(3)(d)", + "IV.33(3)(e)", + "IV.34(1)(c)", + "IV.34(1)(d)", + "IV.34(2)(a)", + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.35(2)(c)" ], - "MON-16.1": [ - "21.10" + "PRI-02": [ + "IV.25(e)", + "IV.26(a)", + "IV.29", + "IV.29(a)", + "IV.29(b)", + "IV.29(c)", + "IV.29(d)", + "IV.29(e)", + "IV.29(f)", + "IV.29(g)", + "IV.29(h)" ], - "MON-16.2": [ - "21.10" + "PRI-02.2": [ + "IV.35(1)" ], - "MON-16.3": [ - "21.10" + "PRI-03": [ + "IV.26(c)", + "IV.28(2)(c)", + "IV.32(4)" ], - "CRY-01": [ - "8.1", - "8.8", - "15.7", - "21.16" + "PRI-03.3": [ + "IV.36" ], - "CRY-01.1": [ - "15.7" + "PRI-03.4": [ + "IV.26(c)", + "IV.32(2)", + "IV.32(3)" ], - "CRY-02": [ - "4.37", - "12.10" + "PRI-03.5": [ + "IV.32(4)" ], - "CRY-03": [ - "4.22", - "8.4", - "8.5", - "8.6", - "9.8", - "9.20", - "12.10", - "13.6" + "PRI-03.6": [ + "IV.27(a)", + "IV.27(b)", + "IV.27(c)", + "IV.28(2)(d)" ], - "CRY-04": [ - "4.22", - "9.8", - "9.20", - "12.10", - "13.6" + "PRI-03.7": [ + "IV.28(1)" ], - "CRY-05": [ - "8.7", - "15.7" + "PRI-03.13": [ + "IV.27(a)", + "IV.28(2)(d)", + "IV.33(2)", + "IV.33(4)" ], - "CRY-05.1": [ - "15.7" + "PRI-04": [ + "IV.25(c)", + "IV.27(a)" ], - "CRY-07": [ - "4.22" + "PRI-04.1": [ + "IV.25(a)", + "IV.28(3)" ], - "CRY-08": [ - "8.2", - "8.9" + "PRI-04.2": [ + "IV.28(1)" ], - "CRY-09": [ - "8.2", - "8.9", - "8.10" + "PRI-05": [ + "IV.25(g)", + "IV.34(1)(b)", + "IV.34(3)", + "IV.39(1)", + "IV.39(1)(a)", + "IV.39(1)(b)", + "IV.39(1)(c)", + "IV.39(1)(d)", + "IV.39(2)" ], - "CRY-09.3": [ - "8.3", - "8.11" + "PRI-05.1": [ + "IV.30(1)(b)(viii)" ], - "CRY-09.4": [ - "8.9", - "8.11" + "PRI-05.2": [ + "IV.25(f)" ], - "DCH-01": [ - "5.1", - "5.2", - "5.3", - "5.5", - "11.6", - "15.1", - "15.6", - "15.7" + "PRI-05.4": [ + "IV.25(a)", + "IV.25(b)", + "IV.28(3)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(1)(b)(i)", + "IV.30(1)(b)(ii)", + "IV.30(1)(b)(iii)", + "IV.30(1)(b)(iv)", + "IV.30(1)(b)(v)", + "IV.30(1)(b)(vi)", + "IV.30(1)(b)(vii)", + "IV.30(2)", + "IV.33(1)", + "IV.33(1)(a)", + "IV.33(1)(b)", + "IV.36", + "V.45", + "V.45(a)", + "V.45(a)(i)", + "V.45(a)(ii)", + "V.45(b)", + "V.45(c)", + "V.45(c)(i)", + "V.45(c)(ii)", + "V.45(c)(iii)", + "V.46(1)", + "V.46(1)(a)", + "V.46(1)(b)", + "V.46(2)(a)", + "V.46(2)(b)" ], - "DCH-01.1": [ - "11.6" + "PRI-06": [ + "IV.26(b)", + "IV.27", + "IV.34(1)", + "IV.35(3)(b)(i)", + "IV.35(3)(b)(ii)", + "IV.38(1)", + "IV.38(2)", + "IV.38(3)", + "IV.40(1)", + "IV.40(1)(a)", + "IV.40(1)(b)" ], - "DCH-02": [ - "5.3", - "15.2" + "PRI-06.1": [ + "IV.25(f)", + "IV.26(d)", + "IV.34(1)(a)", + "IV.40(1)(a)" ], - "DCH-03.1": [ - "10.5" + "PRI-06.4": [ + "IV.35(4)(a)", + "IV.35(4)(b)", + "IV.35(4)(c)", + "IV.35(4)(c)(i)", + "IV.35(4)(c)(ii)", + "IV.38(4)" ], - "DCH-04": [ - "15.2" + "PRI-06.5": [ + "IV.26(e)", + "IV.40(1)(b)", + "IV.40(3)" ], - "DCH-06": [ - "15.3" + "PRI-06.6": [ + "IV.38(1)", + "IV.38(2)", + "IV.38(3)" ], - "DCH-07": [ - "15.7" + "PRI-06.7": [ + "IV.38(1)", + "IV.38(2)" ], - "DCH-07.1": [ - "15.7" + "PRI-07": [ + "IV.25(h)" ], - "DCH-08": [ - "15.4" + "PRI-07.1": [ + "IV.25(h)", + "IV.40(2)(a)", + "IV.40(2)(b)", + "IV.40(3)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], - "DCH-09": [ - "15.4" + "PRI-07.3": [ + "IV.40(2)", + "IV.40(3)" ], - "DCH-09.1": [ - "15.8" + "PRI-17": [ + "IV.34(2)(b)", + "IV.35(3)(a)" ], - "DCH-09.2": [ - "15.8" + "PRI-19": [ + "IV.35(1)" ], - "DCH-09.3": [ - "15.4" + "PRI-19.1": [ + "IV.35(3)(a)" ], - "DCH-12": [ - "12.24" + "PRI-19.2": [ + "IV.35(1)" ], - "DCH-13": [ - "11.6" + "RSK-10": [ + "IV.31(1)", + "IV.31(2)", + "IV.31(2)(a)", + "IV.31(2)(b)", + "IV.31(2)(c)", + "IV.31(2)(d)", + "IV.31(3)" + ] + }, + "emea-nga-dpr-2019": { + "GOV-17": [ + "4.1(6)", + "4.1(7)" ], - "DCH-13.3": [ - "11.6" + "CPL-01": [ + "2.1(2)", + "2.1(3)", + "3.1(16)", + "4.1(1)" ], - "DCH-14": [ - "5.4", - "10.5" + "CPL-01.3": [ + "3.1(4)" ], - "DCH-17": [ - "5.1", - "5.4", - "10.5" + "CPL-01.4": [ + "4.1(5)", + "4.1(5)a", + "4.1(5)b", + "4.1(5)c", + "4.1(5)d", + "4.1(5)e", + "4.1(5)f", + "4.1(5)g", + "4.1(5)h", + "4.1(5)i", + "4.1(5)j" ], - "DCH-19": [ - "11.6" + "DCH-25": [ + "2.11" ], - "DCH-21": [ - "11.12", - "15.4" + "PRI-01": [ + "4.1(3)" ], - "DCH-25": [ - "10.5" + "PRI-01.4": [ + "4.1(2)" ], - "EMB-01": [ - "12.1", - "12.2", - "12.3" + "PRI-01.5": [ + "2.11", + "2.11(a)", + "2.11(b)", + "2.11(c)", + "2.11(d)", + "2.11(e)", + "2.12" ], - "END-01": [ - "7.1", - "7.3", - "15.5" + "PRI-01.6": [ + "2.1(1)(d)", + "2.6" ], - "END-02": [ - "7.1", - "7.3", - "15.5" + "PRI-01.11": [ + "2.4(a)", + "2.4(b)", + "2.6", + "2.8", + "2.9", + "2.12(b)", + "2.12(c)", + "2.12(d)", + "2.12(e)", + "2.12(f)", + "3.1(3)", + "3.1(3)(a)" ], - "END-03": [ - "6.3" + "PRI-02": [ + "2.3(1)", + "2.5", + "2.5(a)", + "2.5(b)", + "2.5(c)", + "2.5(d)", + "2.5(e)", + "2.5(f)", + "2.5(g)", + "2.5(h)", + "2.5(i)", + "3.1(1)", + "3.1(7)", + "3.1(7)(a)", + "3.1(7)(b)", + "3.1(7)(c)", + "3.1(7)(d)", + "3.1(7)(e)", + "3.1(7)(f)", + "3.1(7)(g)", + "3.1(7)(h)", + "3.1(7)(i)", + "3.1(7)(j)", + "3.1(7)(k)", + "3.1(7)(l)", + "3.1(7)(m)", + "3.1(7)(n)", + "3.1(8)" ], - "END-03.1": [ - "6.3" + "PRI-02.1": [ + "2.3(1)" ], - "END-04": [ - "7.1", - "7.3", - "12.20", - "15.5" + "PRI-03": [ + "2.3(2)", + "2.3(2)(a)", + "2.3(2)(b)", + "2.3(2)(c)", + "2.3(2)(d)", + "2.3(2)(e)", + "2.8(b)", + "2.12(a)", + "3.1(14)(a)", + "3.1(14)(b)", + "3.1(14)(c)" ], - "END-04.1": [ - "7.9" + "PRI-03.4": [ + "2.8(a)", + "3.1(9)(b)" ], - "END-04.3": [ - "7.7", - "12.20" + "PRI-04.1": [ + "2.3(1)" ], - "END-04.4": [ - "7.8" + "PRI-05": [ + "3.1(9)(a)" ], - "END-04.6": [ - "12.20" + "PRI-05.4": [ + "2.1(1)(a)", + "2.1(1)(a)(i)", + "2.1(1)(a)(ii)", + "2.1(1)(b)", + "2.1(1)(c)", + "2.2(a)", + "2.2(c)", + "2.2(d)", + "2.2(e)", + "3.1(12)" ], - "END-04.7": [ - "7.5", - "12.25" + "PRI-06": [ + "2.8(a)", + "3.1(9)", + "3.1(9)(a)", + "3.1(9)(b)", + "3.1(9)(c)", + "3.1(9)(d)", + "3.1(9)(e)", + "3.1(11)", + "3.1(11)(a)", + "3.1(11)(b)", + "3.1(11)(c)", + "3.1(11)(d)", + "3.1(15)" ], - "END-06": [ - "6.4", - "12.19" + "PRI-06.4": [ + "3.1(2)", + "3.1(3)(b)", + "3.1(5)", + "3.1(13)" ], - "END-06.2": [ - "7.2" + "PRI-06.5": [ + "3.1(9)(e)" ], - "END-07": [ - "7.4", - "7.5", - "12.18", - "12.24", - "23.6" + "PRI-06.6": [ + "3.1(14)", + "3.1(15)" ], - "END-09": [ - "4.37" + "PRI-06.7": [ + "3.1(14)" ], - "END-14": [ - "5.6" + "PRI-06.8": [ + "3.1(5)" ], - "HRS-01": [ - "19.1" + "PRI-07": [ + "2.12(a)" ], - "HRS-02": [ - "19.1" + "PRI-07.1": [ + "2.7" ], - "HRS-03": [ - "4.13", - "18.10" + "PRI-07.3": [ + "3.1(10)" ], - "HRS-04": [ - "19.2" + "PRI-07.5": [ + "3.1(4)" ], - "HRS-04.1": [ - "19.2" + "PRI-14": [ + "3.1(8)" ], - "HRS-05": [ - "5.1", - "19.3", - "19.4" + "PRI-14.1": [ + "3.1(8)" ], - "HRS-05.1": [ - "5.1", - "15.6", - "19.3", - "19.6" + "PRI-14.2": [ + "3.1(8)" ], - "HRS-05.2": [ - "4.13", - "19.6", - "19.7" + "PRI-15": [ + "4.1(4)" ], - "HRS-05.3": [ - "5.4", - "9.5", - "15.6", - "19.6" + "PRI-17": [ + "3.1(2)", + "3.1(6)" + ] + }, + "emea-nor-pda-2018": { + "PRI-01.4": [ + "18", + "18(a)", + "18(b)", + "18(c)", + "18(d)" ], - "HRS-05.4": [ - "15.6", - "19.6" + "PRI-04.1": [ + "8" ], - "HRS-05.5": [ - "13.2", - "13.3", - "13.7", - "13.10", - "15.6", - "19.6" + "PRI-05.4": [ + "9", + "12" ], - "HRS-06": [ - "19.6" + "PRI-07.5": [ + "16" + ] + }, + "emea-pol-act-10-2018": { + "PRI-01.4": [ + "Art. 8", + "Art. 11a" ], - "HRS-06.1": [ - "19.4" + "PRI-02": [ + "Art. 11" + ] + }, + "emea-qat-pdppl-2020": { + "GOV-04.1": [ + "3.11.2" ], - "HRS-07": [ - "19.8" + "AST-01.2": [ + "3.11.2" ], - "HRS-08": [ - "19.9" + "CPL-01": [ + "3.8" ], - "HRS-09": [ - "19.9", - "19.10" + "CPL-01.4": [ + "3.11.7" ], - "HRS-09.1": [ - "19.10" + "CPL-02": [ + "3.11.7" ], - "HRS-09.2": [ - "19.10" + "IRO-01": [ + "3.11.5" ], - "HRS-09.3": [ - "19.10" + "IRO-10.2": [ + "3.14" ], - "HRS-10": [ - "19.5" + "PRI-01": [ + "3.11", + "3.11.5" ], - "HRS-11": [ - "4.11", - "10.4" + "PRI-01.5": [ + "3.15" ], - "IAC-01": [ - "4.1", - "4.8", - "4.34", - "4.37", - "12.15", - "12.28", - "12.29" + "PRI-01.6": [ + "3.13" ], - "IAC-02": [ - "4.2", - "4.31", - "4.34" + "PRI-01.11": [ + "2.4", + "2.6.3", + "3.8.1", + "3.8.2", + "3.8.3", + "3.8.4", + "3.10", + "3.11.1", + "3.11.6", + "3.13", + "4.17.3", + "4.17.4", + "4.17.5" ], - "IAC-02.1": [ - "4.34" + "PRI-02": [ + "3.9", + "3.9.1", + "3.9.2", + "3.9.3", + "3.9.4", + "4.17.1" ], - "IAC-02.2": [ - "4.31" + "PRI-03": [ + "2.4", + "2.5.2" ], - "IAC-03": [ - "4.2", - "4.21" + "PRI-03.3": [ + "3.12" ], - "IAC-04": [ - "4.33" + "PRI-03.4": [ + "2.5.1" ], - "IAC-05": [ - "4.2" + "PRI-03.13": [ + "4.17.2" ], - "IAC-06": [ - "4.21", - "4.32" + "PRI-04": [ + "3.12" ], - "IAC-06.1": [ - "4.29" + "PRI-04.1": [ + "2.4", + "3.11.1" ], - "IAC-06.3": [ - "4.30" + "PRI-05.4": [ + "3.10", + "4.16", + "4.17", + "4.17.4" ], - "IAC-08": [ - "4.2", - "4.8", - "4.9", - "4.10", - "4.11", - "4.20", - "12.28", - "12.29" + "PRI-06": [ + "2.5.1", + "2.5.2", + "2.5.3", + "2.5.4", + "2.6", + "2.6.1", + "2.6.2", + "3.11.6" ], - "IAC-09": [ - "12.15" + "PRI-06.1": [ + "2.5.4" ], - "IAC-09.1": [ - "12.15" + "PRI-06.4": [ + "3.11.4" ], - "IAC-10": [ - "4.35", - "12.15", - "12.16" + "PRI-06.5": [ + "2.5.3" ], - "IAC-10.1": [ - "4.35", - "12.15", - "12.16" + "PRI-06.8": [ + "4.17.3" ], - "IAC-10.2": [ - "12.15", - "12.16" + "PRI-07": [ + "3.12" ], - "IAC-10.5": [ - "4.37" + "PRI-17": [ + "2.6.2", + "3.11.4" ], - "IAC-11": [ - "4.36" + "RSK-10": [ + "3.11.1" ], - "IAC-12": [ - "4.37" + "SAT-03": [ + "3.11.3" ], - "IAC-15": [ - "4.3", - "4.4", - "4.6" + "SAT-03.3": [ + "3.11.3" ], - "IAC-15.2": [ - "4.4" + "TPM-05": [ + "3.11.8" ], - "IAC-15.3": [ - "4.5" + "TPM-05.6": [ + "3.11.8" ], - "IAC-16": [ - "4.2" + "TPM-05.8": [ + "3.11.8" ], - "IAC-17": [ - "4.3" + "TPM-08": [ + "3.11.8" + ] + }, + "emea-rus-152-fz-2025": { + "DCH-23": [ + "Art. 13.1" ], - "IAC-21": [ - "4.10", - "12.29" + "PRI-01.4": [ + "Art. 22.1" ], - "IAC-22": [ - "4.14" + "PRI-01.5": [ + "Art. 12" ], - "IAC-23": [ - "4.15" + "PRI-01.6": [ + "Art. 7", + "Art. 18.1", + "Art. 19" ], - "IAC-24": [ - "4.16" + "PRI-01.11": [ + "Art. 5", + "Art. 6", + "Art. 11", + "Art. 18.1" ], - "IRO-01": [ - "24.1" + "PRI-02": [ + "Art. 18" ], - "IRO-02": [ - "7.2", - "24.2" + "PRI-03": [ + "Art. 6", + "Art. 9", + "Art. 10.1" ], - "IRO-02.1": [ - "24.4" + "PRI-05.3": [ + "Art. 13.1" ], - "IRO-04": [ - "7.2", - "24.2", - "24.3", - "24.8", - "24.9" + "PRI-05.4": [ + "Art. 10", + "Art. 11", + "Art. 13" ], - "IRO-05": [ - "24.10", - "24.11" + "PRI-05.7": [ + "Art. 10" ], - "IRO-06": [ - "24.10", - "24.11", - "24.12" + "PRI-06": [ + "Art. 14", + "Art. 15", + "Art. 20" ], - "IRO-07": [ - "24.7", - "24.9" + "PRI-06.3": [ + "Art. 17" ], - "IRO-09": [ - "24.5" + "PRI-06.4": [ + "Art. 21" ], - "IRO-09.1": [ - "24.5" + "PRI-15": [ + "Art. 22" ], - "IRO-10": [ - "24.6", - "24.8" + "PRI-19": [ + "Art. 16" ], - "IRO-10.4": [ - "17.11" + "PRI-19.2": [ + "Art. 16" ], - "IAO-01": [ - "10.6", - "16.5", - "17.1", - "17.16", - "17.18" + "PRI-19.3": [ + "Art. 16" + ] + }, + "emea-sau-cscc-1-2019": { + "GOV-01": [ + "1-1-1" ], - "IAO-02": [ - "10.6", - "16.5", - "17.2", - "17.16", - "17.18" + "GOV-08": [ + "1-1-1" ], - "IAO-02.1": [ - "17.2", - "17.16" + "GOV-14": [ + "1-1-1" ], - "IAO-02.2": [ - "17.2", - "17.16" + "GOV-15": [ + "1-1-1", + "2-1-1" ], - "IAO-02.3": [ - "17.2", - "17.16" + "GOV-15.1": [ + "1-1-1" ], - "IAO-03.2": [ - "16.5" + "GOV-15.2": [ + "1-1-1" ], - "IAO-06": [ - "10.6", - "16.5" + "GOV-15.3": [ + "1-1-1" ], - "IAO-07": [ - "10.6", - "16.5" + "GOV-15.4": [ + "1-1-1" ], - "MNT-05": [ - "4.18", - "12.7" + "GOV-15.5": [ + "1-1-1" ], - "MNT-05.1": [ - "12.7" + "AST-01": [ + "1-3-1" ], - "MNT-05.2": [ - "12.7" + "AST-01.1": [ + "3-1-1-2" ], - "MNT-05.3": [ - "4.20", - "12.7" + "AST-01.2": [ + "2-1-1-2" ], - "MNT-05.4": [ - "4.18", - "4.20", - "12.7" + "AST-02": [ + "2-1-1-1" ], - "MNT-05.5": [ - "12.7" + "AST-03": [ + "2-1-1-2" ], - "MNT-06": [ - "12.7" + "AST-05.1": [ + "2-6-1-5" ], - "MNT-06.1": [ - "12.7" + "AST-27": [ + "2-3-1-4" ], - "MDM-01": [ - "4.25", - "4.28", - "13.1", - "13.3", - "13.5", - "13.8", - "13.9", - "13.10" + "AST-28": [ + "2-2-1-8" ], - "MDM-02": [ - "4.27", - "13.2", - "13.3", - "13.5", - "13.7", - "13.9" + "BCD-01": [ + "2-8-1", + "3-1-1", + "3-1-1-1" ], - "MDM-03": [ - "4.26", - "8.7", - "13.4" + "BCD-02": [ + "2-1-1-1", + "2-8-1-1", + "3-1-1-2" ], - "MDM-04": [ - "13.9" + "BCD-03.1": [ + "3-1-1-4" ], - "MDM-05": [ - "13.8" + "BCD-04": [ + "3-1-1-3", + "3-1-1-4" ], - "MDM-06": [ - "13.3", - "13.5" + "BCD-11": [ + "2-8-1-1", + "2-8-1-2", + "2-8-1-3" ], - "MDM-07": [ - "13.3", - "13.5" + "BCD-11.1": [ + "2-8-2" ], - "NET-01": [ - "9.1" + "BCD-11.4": [ + "2-8-1-3" ], - "NET-02": [ - "9.17" + "BCD-11.9": [ + "2-8-1-3" ], - "NET-02.1": [ - "9.3" + "BCD-11.10": [ + "2-8-1-3" ], - "NET-02.2": [ - "9.18" + "BCD-12": [ + "2-8-2" ], - "NET-03": [ - "9.3", - "9.18", - "9.23", - "10.9", - "11.8", - "16.4" + "CHG-01": [ + "1-3-1" ], - "NET-03.1": [ - "9.10", - "9.11", - "16.4" + "CHG-04.5": [ + "1-3-2-2" ], - "NET-03.2": [ - "9.5" + "CLD-01": [ + "4-2-1" ], - "NET-03.3": [ - "9.19" + "CLD-04": [ + "1-3-2-3" ], - "NET-04": [ - "9.12", - "9.16", - "10.9", - "12.11" + "CLD-09": [ + "4-2-1-1" ], - "NET-04.1": [ - "9.12", - "12.9" + "CPL-02": [ + "1-4-1" ], - "NET-04.3": [ - "9.16" + "CPL-02.1": [ + "1-4-2" ], - "NET-04.4": [ - "9.16" + "CPL-03.1": [ + "1-4-2" ], - "NET-04.6": [ - "9.24" + "CFG-01": [ + "2-3-1-6" ], - "NET-05": [ - "16.4" + "CFG-02": [ + "1-3-2-3", + "2-2-1-5", + "2-2-1-6", + "2-3-1-6", + "2-3-1-7", + "2-4-1-3", + "2-12-1" ], - "NET-05.1": [ - "9.11", - "12.8", - "16.4" + "CFG-02.1": [ + "2-3-1-6", + "2-4-1-2" ], - "NET-06": [ - "9.2", - "9.18", - "9.19", - "10.8", - "12.4", - "12.5", - "12.11" + "CFG-02.2": [ + "2-3-1-6" ], - "NET-06.1": [ - "9.2", - "12.4", - "12.5" + "CFG-02.5": [ + "2-6-1-3" ], - "NET-07": [ - "4.16", - "9.4" + "CFG-03.3": [ + "2-3-1-1" ], - "NET-08": [ - "7.4", - "7.6", - "12.18", - "23.6" + "MON-01": [ + "2-11-1" ], - "NET-08.2": [ - "4.24", - "12.18", - "23.6" + "MON-01.2": [ + "2-11-1-3", + "2-11-1-4" ], - "NET-09": [ - "17.25" + "MON-01.4": [ + "2-11-1-1" ], - "NET-10": [ - "9.6" + "MON-01.8": [ + "2-11-1-2" ], - "NET-10.1": [ - "9.7" + "MON-02": [ + "2-11-1-3", + "2-11-1-4" ], - "NET-10.2": [ - "9.7" + "MON-02.1": [ + "2-11-1-3", + "2-11-1-4" ], - "NET-12": [ - "8.4", - "8.6", - "9.20", - "13.6" + "MON-02.2": [ + "2-11-1-3" ], - "NET-14": [ - "4.17" + "MON-03": [ + "2-11-1-5" ], - "NET-14.1": [ - "4.18" + "MON-03.2": [ + "2-11-1-3" ], - "NET-14.2": [ - "9.8" + "MON-03.7": [ + "2-2-1-8" ], - "NET-14.3": [ - "4.19" + "MON-08": [ + "2-3-1-8", + "2-11-1-5", + "2-11-2" ], - "NET-14.4": [ - "4.17", - "4.20" + "MON-08.1": [ + "2-11-1-5", + "2-11-2" ], - "NET-15": [ - "4.24", - "12.12", - "12.14" + "MON-10": [ + "2-11-2" ], - "NET-15.1": [ - "12.14" + "CRY-01": [ + "2-7-1", + "2-7-1-3" ], - "NET-15.2": [ - "4.24" + "CRY-01.5": [ + "2-7-1-3" ], - "NET-15.3": [ - "12.13" + "CRY-03": [ + "2-3-1-5", + "2-7-1-1" ], - "NET-15.4": [ - "4.23" + "CRY-04": [ + "2-3-1-5", + "2-7-1-1" ], - "NET-18": [ - "9.14" + "CRY-05": [ + "2-7-1-2" ], - "NET-18.1": [ - "9.14" + "DCH-01": [ + "2-6-1", + "2-6-1-3" ], - "PES-01": [ - "9.15", - "12.27", - "18.1", - "18.2", - "18.10" + "DCH-01.2": [ + "2-6-1-1", + "2-6-1-3" ], - "PES-02": [ - "12.27", - "18.3" + "DCH-01.4": [ + "2-6-1-1", + "2-6-1-3" ], - "PES-02.1": [ - "12.27", - "18.4" + "DCH-02": [ + "2-6-1-1", + "2-6-1-2" ], - "PES-03": [ - "9.15", - "12.27", - "18.4" + "DCH-02.1": [ + "2-6-1-1" ], - "PES-03.1": [ - "12.27", - "18.6", - "18.8" + "DCH-03.1": [ + "2-6-1-3" ], - "PES-03.2": [ - "18.6", - "18.11" + "DCH-14.2": [ + "2-6-1-5" ], - "PES-03.3": [ - "18.5" + "DCH-17": [ + "2-6-1-5" ], - "PES-04": [ - "9.15", - "18.6" + "DCH-18": [ + "2-6-1-4", + "2-11-2" ], - "PES-04.1": [ - "18.6" + "DCH-25": [ + "2-6-1-5" ], - "PES-05": [ - "18.8", - "18.10", - "18.11" + "DCH-26": [ + "4-2-1-1" ], - "PES-05.1": [ - "18.9", - "18.11" + "END-01": [ + "2-3-1-2" ], - "PES-06": [ - "18.3", - "18.12" + "END-02": [ + "2-3-1-2" ], - "PES-07.3": [ - "18.14", - "18.15" + "HRS-01": [ + "1-5-1" ], - "PES-07.4": [ - "18.16" + "HRS-02": [ + "1-5-1-2" ], - "PES-07.5": [ - "18.19" + "HRS-04": [ + "1-5-1-1" ], - "PES-08": [ - "18.17" + "HRS-04.3": [ + "1-5-1-2" ], - "PES-08.1": [ - "18.17" + "IAC-01": [ + "2-2-1" ], - "PES-08.2": [ - "18.17" + "IAC-05": [ + "2-2-1-7" ], - "PES-09": [ - "18.18" + "IAC-06": [ + "2-2-1-3", + "2-2-1-4" ], - "PES-09.1": [ - "18.18" + "IAC-06.1": [ + "2-2-1-4" ], - "PES-10": [ - "18.20" + "IAC-06.2": [ + "2-2-1-3" ], - "PES-11": [ - "18.21" + "IAC-06.3": [ + "2-2-1-4" ], - "PES-12": [ - "18.7", - "18.13", - "18.22" + "IAC-10.1": [ + "2-2-1-5" ], - "PES-12.1": [ - "9.15", - "18.13" + "IAC-10.5": [ + "2-2-1-6" ], - "PES-12.2": [ - "18.7" + "IAC-10.8": [ + "2-3-1-7" ], - "PRI-05": [ - "15.4" + "IAC-10.11": [ + "2-2-1-6" ], - "PRI-07": [ - "10.5" + "IAC-15": [ + "2-2-1-7" ], - "PRI-07.1": [ - "11.1" + "IAC-16": [ + "2-2-1-7" ], - "PRM-01": [ - "17.5" + "IAC-17": [ + "2-2-2" ], - "PRM-02": [ - "17.5", - "17.8", - "17.9" + "IAC-20.2": [ + "2-2-1-8" ], - "PRM-03": [ - "17.5" + "IAC-20.4": [ + "2-3-1-4" ], - "PRM-04": [ - "17.5", - "17.8", - "17.9" + "IAO-01": [ + "1-3-1", + "1-3-2", + "2-13-4" ], - "PRM-05": [ - "17.5", - "17.6" + "IAO-01.1": [ + "1-3-1-1", + "2-13-4" ], - "PRM-06": [ - "17.5", - "17.6" + "IAO-02": [ + "1-3-1-1", + "1-3-1-2", + "2-13-4" ], - "PRM-07": [ - "17.4", - "17.5", - "17.8" + "IAO-02.2": [ + "1-3-1-1", + "2-13-4" ], - "RSK-01": [ - "1.2", - "2.1", - "2.2" + "IAO-02.4": [ + "2-13-4" ], - "RSK-01.1": [ - "2.2" + "IAO-03": [ + "2-13-4" ], - "RSK-02": [ - "2.2" + "IAO-04": [ + "1-3-2-1" ], - "RSK-03": [ - "1.2", - "2.2" + "IAO-05": [ + "2-13-4" ], - "RSK-04": [ - "1.2", - "2.2" + "IAO-06": [ + "1-3-1-2", + "2-13-4" ], - "RSK-04.1": [ - "2.2", - "6.8" + "IAO-07": [ + "2-13-4" ], - "RSK-05": [ - "2.2" + "MDM-01": [ + "2-5-1" ], - "RSK-07": [ - "2.2" + "MDM-02": [ + "2-5-1-1" ], - "RSK-08": [ - "6.8", - "16.6" + "MDM-03": [ + "2-5-1-2" ], - "RSK-09": [ - "16.3", - "17.3", - "17.11" + "MDM-11": [ + "2-5-1-1" ], - "RSK-09.1": [ - "16.6", - "17.3", - "17.11" + "NET-01": [ + "2-3-1-5", + "2-4-1" ], - "RSK-10": [ - "16.6", - "17.3" + "NET-02": [ + "2-4-1-5" ], - "SEA-01": [ - "2.1", - "15.6", - "17.7" + "NET-02.1": [ + "2-4-1-8" ], - "SEA-02": [ - "2.1", - "15.6", - "17.7" + "NET-02.3": [ + "2-6-1-5" ], - "SEA-03": [ - "2.1", - "15.6", - "17.7" + "NET-03": [ + "2-4-1-5" ], - "SEA-05": [ - "10.5", - "10.8" + "NET-04": [ + "2-4-1-4", + "2-4-1-6", + "2-4-1-7", + "2-4-1-9" ], - "SEA-07.2": [ - "9.17" + "NET-04.1": [ + "2-4-1-4", + "2-4-1-6", + "2-4-1-7", + "2-4-1-9" ], - "SEA-11": [ - "23.5" + "NET-04.6": [ + "2-4-1-2" ], - "SEA-12": [ - "23.5" + "NET-06": [ + "2-3-1-4", + "2-4-1-1" ], - "OPS-01.1": [ - "12.2", - "12.3", - "18.2", - "22.2" + "NET-06.3": [ + "2-3-1-4", + "2-4-1-6", + "2-4-1-7" ], - "SAT-01": [ - "20.1" + "NET-06.5": [ + "2-4-1-3", + "2-4-1-6" ], - "SAT-02": [ - "20.2" + "NET-14": [ + "2-2-1-1", + "2-2-1-2" ], - "SAT-02.2": [ - "20.4" + "NET-14.1": [ + "2-2-1-2" ], - "SAT-03": [ - "20.2", - "25.3" + "NET-14.5": [ + "2-2-1-1", + "2-2-1-2" ], - "SAT-03.3": [ - "20.3" + "NET-15": [ + "2-3-1-5", + "2-4-1-4" ], - "TDA-01": [ - "17.1", - "17.9" + "NET-15.2": [ + "2-4-1-4" ], - "TDA-01.1": [ - "17.9" + "NET-18.1": [ + "2-4-1-3" ], - "TDA-02.1": [ - "12.9", - "12.29" + "PRI-05.3": [ + "2-6-1-1" ], - "TDA-04": [ - "17.6", - "17.10" + "PRM-01": [ + "1-3-1", + "2-13-1" ], - "TDA-04.1": [ - "17.6", - "17.10" + "PRM-01.1": [ + "1-1-1" ], - "TDA-05": [ - "17.6" + "PRM-04": [ + "2-13-2" ], - "TDA-06": [ - "11.9", - "17.6", - "17.9", - "17.20", - "17.25" + "PRM-05": [ + "2-13-1", + "2-13-2" ], - "TDA-07": [ - "10.1" + "PRM-07": [ + "2-13-1" ], - "TDA-08": [ - "10.1" + "RSK-01": [ + "1-2-1" ], - "TDA-09": [ - "11.9", - "17.3", - "17.4", - "17.12", - "17.15" + "RSK-04": [ + "1-2-1-1" ], - "TDA-09.1": [ - "17.3", - "17.4", - "17.12" + "RSK-04.1": [ + "1-2-1-2" ], - "TDA-09.2": [ - "17.3", - "17.14" + "RSK-04.2": [ + "1-2-1" ], - "TDA-09.3": [ - "17.3", - "17.19" + "SEA-02": [ + "2-12-2" ], - "TDA-09.4": [ - "17.3", - "17.24" + "OPS-02": [ + "1-1-1" ], - "TDA-09.5": [ - "11.9", - "17.3", - "17.15", - "17.17" + "TDA-01": [ + "1-3-2", + "2-13-1" ], - "TDA-10": [ - "10.3" + "TDA-01.1": [ + "2-13-1", + "2-13-2" ], - "TDA-11": [ - "17.21" + "TDA-02": [ + "2-13-1", + "2-13-2", + "2-13-3", + "2-13-3-1", + "2-13-3-2", + "2-13-3-3", + "2-13-3-4" ], - "TDA-11.1": [ - "17.21" + "TDA-06": [ + "1-3-2-3", + "2-13-1", + "2-13-2" ], - "TDA-14.1": [ - "17.20" + "TDA-07": [ + "1-3-2-4" ], - "TDA-15": [ - "17.13" + "TDA-08": [ + "1-3-2-4" ], - "TDA-17": [ - "12.23" + "TDA-08.1": [ + "1-3-2-4" ], - "TDA-18": [ - "17.22" + "TDA-09": [ + "1-3-2-1" ], - "TDA-19": [ - "17.23" + "TDA-09.2": [ + "1-3-2-1" + ], + "TDA-09.3": [ + "1-3-2-1" + ], + "TDA-20": [ + "1-3-2-2" + ], + "TDA-20.3": [ + "1-3-2-2" ], "TPM-01": [ - "11.3", - "11.10", - "16.1", - "17.3" + "4-1-1" ], "TPM-02": [ - "16.1", - "16.6" + "4-1-1-1" ], "TPM-03": [ - "11.3", - "16.1", - "16.3", - "16.5", - "17.3", - "17.11" + "4-1-1-1", + "4-1-1-2" ], "TPM-03.1": [ - "16.1" + "4-1-1-1", + "4-1-1-2" ], "TPM-03.2": [ - "11.3", - "16.2" + "4-1-1-1", + "4-1-1-2" ], "TPM-04": [ - "11.3", - "16.1", - "22.4" + "4-1-1-1", + "4-1-1-2" ], "TPM-04.1": [ - "16.3", - "16.5", - "17.3" - ], - "TPM-04.2": [ - "16.3" - ], - "TPM-04.3": [ - "16.3" - ], - "TPM-04.4": [ - "16.3" + "4-1-1-1", + "4-1-1-2" ], "TPM-05": [ - "11.1", - "11.3", - "11.10", - "16.2", - "19.5", - "22.4", - "25.17" - ], - "TPM-06": [ - "11.1", - "11.3", - "18.10", - "19.5" - ], - "TPM-07": [ - "11.5", - "11.11" - ], - "TPM-08": [ - "11.4", - "11.5" - ], - "TPM-11": [ - "25.17" - ], - "THR-01": [ - "23.1", - "23.4" - ], - "THR-02": [ - "23.3" - ], - "THR-03": [ - "23.2" + "4-1-1-1", + "4-1-1-2" ], "VPM-01": [ - "22.1", - "22.2" + "2-3-1-3", + "2-9-1", + "2-9-2" + ], + "VPM-01.1": [ + "2-10-1-1" ], "VPM-02": [ - "22.8", - "22.11", - "22.13" + "2-9-1-2" ], "VPM-03": [ - "22.8" + "2-9-1-2" ], "VPM-04": [ - "22.6", - "22.11" - ], - "VPM-04.1": [ - "12.22" + "2-9-1-3" ], "VPM-05": [ - "12.21" - ], - "VPM-05.1": [ - "12.21", - "22.11", - "22.12" - ], - "VPM-05.2": [ - "22.11", - "22.12" - ], - "VPM-05.3": [ - "12.22" + "2-3-1-3" ], "VPM-06": [ - "3.4", - "9.25", - "12.30", - "22.3", - "22.6" - ], - "VPM-06.1": [ - "22.7" + "2-9-1-1", + "2-9-2" ], "VPM-06.2": [ - "22.6" - ], - "VPM-06.3": [ - "22.9" - ], - "VPM-06.4": [ - "22.10" - ], - "VPM-06.5": [ - "22.10" + "2-9-2" ], "VPM-06.6": [ - "22.3" + "2-9-1-1" ], "VPM-06.7": [ - "22.3" + "2-9-1-1" ], "VPM-07": [ - "3.4", - "12.30", - "17.17", - "22.4", - "22.5" + "2-10-1", + "2-10-1-1", + "2-10-1-2", + "2-10-2" ], "VPM-07.1": [ - "17.16", - "17.17", - "22.4", - "22.5" - ] - }, - "emea-isr-ppl-5741-1981": { - "GOV-01": [ - "16", - "17" + "2-10-1-2" ], - "CPL-01": [ - "16", - "17" + "WEB-01": [ + "2-12-1", + "2-12-1-1", + "2-12-1-2" ], - "CPL-02": [ - "16", - "17" + "WEB-04": [ + "2-12-1-1" ], - "CPL-03": [ - "16", - "17" + "WEB-06": [ + "2-12-1-1" ], - "DCH-01": [ - "16", - "17" + "WEB-07": [ + "2-12-1-2", + "2-12-2" ], - "DCH-22.1": [ - "14" + "WEB-08": [ + "2-12-1-1" ], - "DCH-24": [ - "16", - "17" + "WEB-10": [ + "2-12-1-1" + ] + }, + "emea-sau-cgiot-2024": { + "GOV-01": [ + "1-1-2" ], - "DCH-24.1": [ - "16", - "17" + "GOV-01.1": [ + "1-1-4" ], - "PRI-01": [ - "Inferred", - "Expectation" + "GOV-02": [ + "1-2-1" ], - "PRI-01.1": [ - "16", - "17" + "GOV-03": [ + "1-1-4", + "1-2-3", + "1-4-6", + "1-8-3" ], - "PRI-02.1": [ - "8" + "GOV-05": [ + "1-1-4" ], - "PRI-05": [ - "8" + "GOV-05.1": [ + "1-1-3" ], - "PRI-05.1": [ - "8" + "GOV-15": [ + "1-6-1" ], - "PRI-05.4": [ - "8" + "GOV-15.1": [ + "1-6-1" ], - "PRI-06": [ - "13" + "GOV-15.2": [ + "1-6-1" ], - "PRI-06.1": [ - "14" + "GOV-15.3": [ + "1-6-1" ], - "PRI-15": [ - "8", - "9" + "GOV-15.4": [ + "1-6-1" ], - "SEA-01": [ - "16", - "17" + "GOV-15.5": [ + "1-6-1" ], - "SEA-02": [ - "16", - "17" + "AST-01.1": [ + "4-1-4" ], - "SEA-03": [ - "16", - "17" + "AST-02": [ + "2-1-1" ], - "SEA-15": [ - "16", - "17" + "AST-02.1": [ + "2-1-2" ], - "TPM-04.4": [ - "16", - "17" - ] - }, - "emea-ita-pdpc-2003": { - "GOV-01": [ - "31", - "33", - "34", - "35" + "AST-02.9": [ + "2-1-2" ], - "CPL-01": [ - "26", - "31", - "33", - "34", - "35" + "AST-08": [ + "2-6-2", + "2-13-2" ], - "CPL-02": [ - "31", - "33", - "34", - "35" + "AST-09": [ + "2-5-1", + "2-15-3" ], - "CPL-03": [ - "31" + "AST-15": [ + "2-6-2" ], - "DCH-01": [ - "31", - "33", - "34", - "35", - "42" + "AST-18": [ + "2-15-1" ], - "DCH-22.1": [ - "7" + "BCD-01": [ + "2-8-1", + "2-12-2", + "3-1-1" ], - "DCH-24": [ - "31" + "BCD-11": [ + "2-8-1", + "2-8-2" ], - "DCH-24.1": [ - "31" + "BCD-11.1": [ + "2-8-2" ], - "PRI-01": [ - "Inferred", - "Expectation" + "BCD-11.5": [ + "2-8-3" ], - "PRI-01.1": [ - "30" + "BCD-12": [ + "2-12-2" ], - "PRI-02": [ - "11", - "13", - "37" + "CHG-01": [ + "1-5-3" ], - "PRI-02.1": [ - "13" + "CHG-02.2": [ + "1-5-3" ], - "PRI-03": [ - "23", - "24" + "CHG-05": [ + "1-5-3" ], - "PRI-04": [ - "11" + "CLD-01": [ + "4-2-1" ], - "PRI-04.1": [ - "11" + "CLD-02": [ + "4-2-1", + "4-2-2" ], - "PRI-05": [ - "11" + "CPL-01": [ + "1-2-3", + "1-6-1", + "2-6-1", + "2-7-1" ], - "PRI-05.1": [ - "13", - "20" + "CPL-01.1": [ + "1-7-3" ], - "PRI-05.4": [ - "13", - "20" + "CPL-02": [ + "1-7-3" ], - "PRI-06": [ - "7" + "CPL-02.2": [ + "1-7-1" ], - "PRI-06.1": [ - "7" + "CPL-03.1": [ + "1-7-2" ], - "PRI-06.2": [ - "10" + "CPL-03.2": [ + "1-7-1" ], - "PRI-06.4": [ - "9" + "CFG-02": [ + "1-2-2", + "2-5-1", + "2-6-3", + "2-14-2", + "2-15-2" ], - "PRI-15": [ - "26", - "37" + "CFG-02.1": [ + "2-14-4" ], - "SEA-01": [ - "31", - "33", - "34", - "35", - "42" + "CFG-03.3": [ + "2-14-2" ], - "SEA-02": [ - "31", - "33", - "34", - "35", - "42" + "MON-01": [ + "2-11-1" ], - "SEA-03": [ - "31", - "33", - "34", - "35", - "42" + "MON-01.2": [ + "2-11-1" ], - "SEA-15": [ - "31" + "MON-01.8": [ + "2-11-1" ], - "TPM-04.4": [ - "31" - ] - }, - "emea-ken-pda-2019": { - "CLD-09": [ - "25(h)" + "MON-10": [ + "2-11-1" ], - "CPL-01": [ - "4(a)", - "4(b)(i)", - "4(b)(ii)", - "51(1)", - "51(2)(a)", - "51(2)(b)", - "51(2)(c)", - "52(1)(a)", - "52(1)(b)", - "52(1)(c)", - "52(2)", - "52(3)", - "54", - "55(1)(a)", - "55(1)(b)", - "55(2)" + "CRY-03": [ + "2-4-1", + "2-4-2", + "2-4-3", + "2-7-2" ], - "DCH-14.2": [ - "25(h)" + "CRY-04": [ + "2-4-1", + "2-4-2", + "2-4-3" ], - "DCH-19": [ - "25(h)" + "CRY-05": [ + "2-7-2" ], - "DCH-23": [ - "39(2)" + "DCH-02": [ + "2-6-1" ], - "DCH-25": [ - "25(h)", - "48(a)", - "48(b)", - "48(c)(i)", - "48(c)(ii)", - "48(c)(iii)", - "48(c)(iv)", - "48(c)(v)", - "48(c)(vi)", - "49(1)", - "49(2)", - "49(3)", - "50" + "EMB-01": [ + "1-1-1", + "1-1-2", + "2-4-6", + "2-5-1" ], - "DCH-26": [ - "50" + "EMB-02": [ + "2-5-1" ], - "IRO-04.1": [ - "43(1)(b)", - "43(2)", - "43(3)", - "43(4)", - "43(5)", - "43(5)(a)", - "43(5)(b)", - "43(5)(c)", - "43(5)(d)", - "43(5)(e)", - "43(6)", - "43(7)", - "43(8)(a)", - "43(8)(b)", - "43(8)(c)" + "EMB-04": [ + "2-14-1" ], - "PRI-01": [ - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)" + "EMB-05": [ + "2-11-2" ], - "PRI-01.4": [ - "24(1)", - "24(1)(a)", - "24(1)(b)", - "24(1)(c)", - "24(2)", - "24(3)", - "24(4)", - "24(5)", - "24(6)", - "24(7)(a)", - "24(7)(b)", - "24(7)(c)", - "24(7)(d)", - "24(7)(e)" + "EMB-06": [ + "2-6-2" ], - "PRI-01.6": [ - "29(f)", - "41(1)", - "41(1)(a)", - "41(1)(b)", - "41(2)", - "41(3)(a)", - "41(3)(b)", - "41(3)(c)", - "41(3)(d)", - "41(3)(e)", - "41(4)(a)", - "41(4)(b)", - "41(4)(c)", - "41(4)(d)", - "41(4)(e)", - "41(4)(f)", - "42(1)(a)", - "42(1)(b)", - "42(1)(c)", - "42(1)(d)", - "42(2)(a)", - "42(2)(b)", - "42(3)", - "42(4)" + "EMB-07": [ + "2-4-6" ], - "PRI-02": [ - "25(e)", - "26(a)", - "29(a)", - "29(b)", - "29(c)", - "29(d)", - "29(e)", - "29(f)", - "29(g)", - "29(h)" + "EMB-08": [ + "3-1-1", + "3-1-2" ], - "PRI-02.1": [ - "29(c)" + "EMB-09": [ + "2-11-2" ], - "PRI-02.2": [ - "35(1)", - "35(2)", - "35(2)(a)", - "35(2)(b)", - "35(2)(c)", - "35(3)", - "35(3)(a)", - "35(3)(b)(i)", - "35(3)(b)(ii)", - "35(4)(a)", - "35(4)(b)", - "35(4)(c)(i)", - "35(4)(c)(ii)" + "END-13.3": [ + "2-6-3" ], - "PRI-03": [ - "32(1)", - "32(4)" + "HRS-01": [ + "1-3-2", + "1-8-1" ], - "PRI-03.2": [ - "32(2)", - "32(3)" + "HRS-01.1": [ + "1-8-1", + "1-8-2" ], - "PRI-03.4": [ - "26(c)", - "32(2)", - "32(3)" + "HRS-02": [ + "1-8-1" ], - "PRI-03.5": [ - "32(4)" + "HRS-03": [ + "1-3-1", + "1-3-2", + "1-8-1" ], - "PRI-03.6": [ - "27(a)", - "27(b)", - "27(c)" + "HRS-11": [ + "2-2-1" ], - "PRI-03.7": [ - "26(a)", - "26(c)" + "IAC-08": [ + "2-2-1" ], - "PRI-04": [ - "25(c)", - "25(d)", - "27(a)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)" + "IAC-10": [ + "2-2-2" ], - "PRI-04.1": [ - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)" + "IAC-10.1": [ + "2-2-2" ], - "PRI-04.2": [ - "28(1)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)" + "IAC-10.8": [ + "2-2-2" ], - "PRI-05": [ - "25(g)", - "34(3)", - "39(1)", - "39(1)(a)", - "39(1)(b)", - "39(1)(c)", - "39(1)(d)", - "39(2)" + "IAC-15.7": [ + "1-8-2" ], - "PRI-05.1": [ - "25(a)", - "25(b)", - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "34(1)(a)", - "34(1)(b)", - "34(1)(c)", - "34(1)(d)", - "34(2)(a)", - "34(2)(b)", - "34(3)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)", - "53(1)", - "53(2)", - "53(3)(a)", - "53(3)(b)", - "53(4)" + "IAC-16": [ + "2-2-1" ], - "PRI-05.2": [ - "25(f)" + "IAC-17": [ + "1-8-2", + "2-2-3" ], - "PRI-05.4": [ - "44", - "45(a)", - "45(a)(i)", - "45(a)(ii)", - "45(b)", - "45(c)(i)", - "45(c)(ii)", - "45(c)(iii)", - "46(1)(a)", - "46(1)(b)", - "46(2)(a)", - "46(2)(b)", - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" + "IAC-21": [ + "2-2-1" ], - "PRI-05.7": [ - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" + "IAC-22": [ + "2-2-2" ], - "PRI-06": [ - "26(a)", - "26(b)", - "26(c)", - "26(d)", - "26(e)" + "IRO-02": [ + "2-12-2" ], - "PRI-06.1": [ - "25(f)", - "26(d)", - "40(1)(a)", - "40(2)(a)" + "IRO-04": [ + "2-12-1", + "2-12-2" ], - "PRI-06.4": [ - "40(1)(b)" + "IRO-10": [ + "2-12-2" ], - "PRI-06.5": [ - "26(e)", - "40(1)(b)", - "40(2)(b)", - "40(3)" + "IRO-13": [ + "2-12-2", + "2-12-3" ], - "PRI-06.6": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IAO-01": [ + "1-5-2", + "2-15-2", + "4-1-5", + "4-2-3" ], - "PRI-06.7": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IAO-02": [ + "2-15-2", + "4-1-5", + "4-2-3", + "4-2-4" ], - "PRI-07": [ - "25(h)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "NET-01": [ + "2-3-1", + "2-3-2", + "2-4-1", + "2-4-5" ], - "PRI-07.1": [ - "25(h)", - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "NET-03": [ + "2-4-5" ], - "PRI-07.2": [ - "42(2)(a)", - "42(2)(b)", - "42(3)" + "NET-06": [ + "2-4-4" ], - "PRI-07.3": [ - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)" + "NET-13": [ + "2-3-1", + "2-3-2" ], - "PRI-15": [ - "18(1)", - "18(2)", - "18(2)(a)", - "18(2)(b)", - "18(2)(c)", - "18(2)(d)", - "19(1)", - "19(2)", - "19(2)(a)", - "19(2)(b)", - "19(2)(c)", - "19(2)(d)", - "19(2)(e)", - "19(2)(f)", - "19(2)(g)", - "19(3)", - "19(4)", - "19(5)", - "19(6)", - "19(7)", - "20" + "PES-05": [ + "2-13-1" ], - "RSK-10": [ - "31(1)", - "31(2)(a)", - "31(2)(b)", - "31(2)(c)", - "31(2)(d)", - "31(3)", - "31(4)", - "31(5)", - "31(6)" + "PES-05.1": [ + "2-13-1" ], - "SEA-02.1": [ - "2" - ] - }, - "emea-nga-dpr-2019": { - "GOV-02": [ - "4.1(1)" + "PES-16": [ + "2-6-1" ], - "CPL-01": [ - "2.1(2)", - "2.1(3)", - "3.1(16)", - "4.1(1)", - "4.1(6)", - "4.1(7)" + "PRM-07": [ + "1-5-2" ], - "CPL-02": [ - "4.1(5)(a)", - "4.1(5)(b)", - "4.1(5)(c)", - "4.1(5)(d)", - "4.1(5)(e)", - "4.1(5)(f)", - "4.1(5)(g)", - "4.1(5)(h)", - "4.1(5)(i)", - "4.1(5)(j)", - "4.1(6)", - "4.1(7)" + "RSK-01": [ + "1-4-1" ], - "DCH-25": [ - "2.11", - "2.11(a)", - "2.11(b)", - "2.11(c)", - "2.11(d)", - "2.11(e)", - "2.12", - "2.12(a)", - "2.12(b)", - "2.12(c)", - "2.12(d)", - "2.12(e)", - "2.12(f)" + "RSK-01.5": [ + "1-4-5" ], - "PRI-01": [ - "4.1(3)" + "RSK-03": [ + "1-1-2", + "1-4-1", + "1-4-5" ], - "PRI-01.4": [ - "4.1(2)", - "4.1(3)" + "RSK-03.1": [ + "1-4-2", + "1-4-4" ], - "PRI-01.6": [ - "2.1(1)(d)", - "2.6" + "RSK-04": [ + "1-4-1", + "1-4-4" ], - "PRI-02": [ - "2.5", - "2.5(a)", - "2.5(b)", - "2.5(c)", - "2.5(d)", - "2.5(e)", - "2.5(f)", - "2.5(g)", - "2.5(h)", - "2.5(i)", - "3.1(1)", - "3.1(7)(a)", - "3.1(7)(b)", - "3.1(7)(c)", - "3.1(7)(d)", - "3.1(7)(e)", - "3.1(7)(f)", - "3.1(7)(g)", - "3.1(7)(h)", - "3.1(7)(i)", - "3.1(7)(j)", - "3.1(7)(k)", - "3.1(7)(l)", - "3.1(7)(m)", - "3.1(7)(n)", - "3.1(9)", - "3.1(9)(a)", - "3.1(9)(b)", - "3.1(9)(c)", - "3.1(9)(d)", - "3.1(9)(e)" + "RSK-04.1": [ + "1-4-3" ], - "PRI-02.1": [ - "2.3(1)" + "RSK-06": [ + "1-1-2", + "1-4-1", + "1-4-5" ], - "PRI-03": [ - "2.2(a)", - "2.3(2)", - "2.3(2)(a)", - "2.3(2)(b)", - "2.3(2)(c)", - "2.3(2)(d)", - "2.3(2)(e)" + "SEA-01": [ + "1-5-1", + "2-5-1" ], - "PRI-03.4": [ - "2.8", - "2.8(a)", - "2.8(b)" + "SEA-07.1": [ + "2-15-3" ], - "PRI-04.1": [ - "2.1(1)(a)", - "2.1(1)(a)(i)", - "2.1(1)(a)(ii)", - "2.2(a)", - "2.2(b)", - "2.2(c)", - "2.2(d)", - "2.2(e)", - "2.4(a)" + "OPS-01.1": [ + "1-2-1" ], - "PRI-05": [ - "2.1(1)(c)" + "SAT-01": [ + "1-9-1" ], - "PRI-05.1": [ - "2.1(1)(b)", - "3.1(12)" + "SAT-02": [ + "1-9-1", + "1-9-2" ], - "PRI-05.4": [ - "3.1(12)" + "SAT-03": [ + "1-9-1" ], - "PRI-06": [ - "3.1(1)", - "3.1(3)", - "3.1(3)(a)", - "3.1(3)(b)" + "SAT-03.6": [ + "1-9-2" ], - "PRI-06.2": [ - "3.1(13)" + "TDA-02.5": [ + "2-15-1" ], - "PRI-06.4": [ - "2.8", - "2.8(a)", - "2.8(b)", - "3.1(2)", - "3.1(4)", - "3.1(5)", - "3.1(11)(a)", - "3.1(11)(b)", - "3.1(11)(c)", - "3.1(11)(d)", - "3.1(13)" + "TDA-04.2": [ + "4-1-3" ], - "PRI-06.5": [ - "3.1(13)" + "TDA-06": [ + "2-14-3" ], - "PRI-06.6": [ - "3.1(6)", - "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)", - "3.1(15)" + "TDA-06.2": [ + "2-12-1" ], - "PRI-06.7": [ - "3.1(6)", - "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)" + "TDA-06.5": [ + "2-14-3" ], - "PRI-07": [ - "2.4(b)" + "TPM-05": [ + "4-1-1", + "4-2-5" ], - "PRI-07.1": [ - "2.4(b)", - "2.7" + "TPM-05.6": [ + "4-1-2" ], - "PRI-07.3": [ - "3.1(10)" + "TPM-08": [ + "4-1-6" ], - "SEA-02.1": [ - "1.3" - ] - }, - "emea-nor-pda-2018": { - "GOV-01": [ - "13", - "14" + "TPM-09": [ + "4-1-6" ], - "CPL-01": [ - "13", - "14" + "THR-01": [ + "2-12-4" ], - "CPL-02": [ - "13", - "14" + "THR-03": [ + "2-12-4" ], - "CPL-03": [ - "13", - "14" + "THR-03.1": [ + "2-12-4" ], - "DCH-01": [ - "13", - "14", - "29" + "THR-09": [ + "1-4-4" ], - "DCH-22.1": [ - "27" + "THR-10": [ + "1-4-4" ], - "DCH-24": [ - "13", - "14" + "VPM-01": [ + "2-9-1" ], - "DCH-24.1": [ - "13", - "14" + "VPM-02": [ + "2-9-1" ], - "PRI-01": [ - "Inferred", - "Expectation" + "VPM-05": [ + "2-4-6", + "2-9-2" ], - "PRI-02": [ - "31" + "VPM-06": [ + "2-9-1" ], - "PRI-02.1": [ - "32" + "VPM-07": [ + "2-10-1" ], - "PRI-05": [ - "8", - "11", - "15", - "27", - "28" + "VPM-10": [ + "2-10-2" + ] + }, + "emea-sau-ecc-1-2018": { + "GOV-01": [ + "1-2-1", + "2-1-1" ], - "PRI-05.1": [ - "11", - "27" + "GOV-01.1": [ + "1-1-1", + "1-2-3", + "1-4-1" ], - "PRI-05.2": [ - "11" + "GOV-01.2": [ + "1-8-3" ], - "PRI-05.4": [ - "9" + "GOV-01.3": [ + "1-1-3", + "1-3-4", + "2-3-4" ], - "PRI-06": [ - "18" + "GOV-02": [ + "1-3-1", + "1-3-3", + "2-1-1", + "2-1-2", + "2-1-3", + "2-1-4", + "2-2-1", + "2-2-2" ], - "PRI-06.1": [ - "27" + "GOV-03": [ + "1-1-3", + "1-3-4", + "1-4-2", + "2-1-6", + "2-4-4", + "2-5-4", + "2-6-4", + "2-7-4", + "2-8-4", + "2-9-4", + "2-10-4", + "2-11-4", + "2-12-4", + "2-13-4", + "2-14-4", + "2-15-4", + "3-1-4", + "4-1-4", + "4-2-4", + "5-1-4" ], - "PRI-15": [ - "33" + "GOV-04": [ + "1-2-2", + "1-4-1" ], - "SEA-01": [ - "13", - "14", - "29" + "GOV-04.1": [ + "1-4-1" ], - "SEA-02": [ - "13", - "14", - "29" + "GOV-04.2": [ + "1-4-1" ], - "SEA-03": [ - "13", - "14", - "29" + "GOV-08": [ + "1-1-1" ], - "SEA-15": [ - "13", - "14" + "GOV-14": [ + "1-9-2" ], - "TPM-04.4": [ - "13", - "14" - ] - }, - "emea-pol-act-29-1997": { - "GOV-01": [ - "1", - "36" + "GOV-15": [ + "1-3-2", + "1-9-2", + "1-10-2", + "2-1-2", + "2-1-4", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-2", + "2-14-2", + "2-15-2", + "3-1-2", + "4-2-2", + "5-1-2" + ], + "AST-04.1": [ + "2-1-5" + ], + "AST-09": [ + "2-14-3-4" + ], + "AST-16": [ + "2-6-1" + ], + "BCD-01": [ + "2-9-2", + "3-1-1", + "3-1-2", + "3-1-3-1", + "3-1-3-2", + "3-1-3-3" + ], + "BCD-01.1": [ + "3-1-3-2" + ], + "BCD-01.2": [ + "3-1-3-2" + ], + "BCD-01.4": [ + "2-9-1" + ], + "BCD-11": [ + "2-4-3-3", + "2-9-3-1", + "2-9-3-2" + ], + "BCD-11.1": [ + "2-9-3-3" + ], + "CLD-01": [ + "4-2-1", + "4-2-2", + "4-2-3-1", + "4-2-3-2", + "4-2-3-3" + ], + "CLD-01.1": [ + "4-2-3-1" + ], + "CLD-01.2": [ + "4-2-3-1" + ], + "CLD-02": [ + "4-2-3-2" + ], + "CLD-09": [ + "4-1-3-2", + "4-2-3-3" ], "CPL-01": [ - "1", - "36" + "1-7-1", + "1-7-2" ], "CPL-02": [ - "1", - "36" + "1-8-1", + "1-8-3" + ], + "CPL-02.1": [ + "1-8-3" ], "CPL-03": [ - "1", - "36" + "1-3-2", + "1-8-1", + "1-8-2", + "2-2-4" + ], + "CPL-03.1": [ + "1-8-2" + ], + "CPL-08": [ + "4-1-3-2" + ], + "CFG-02": [ + "1-3-3", + "2-4-1" + ], + "CFG-02.1": [ + "5-1-3-7" + ], + "CFG-02.2": [ + "5-1-3-7" + ], + "CFG-02.5": [ + "5-1-3-5", + "5-1-3-6", + "5-1-3-7" + ], + "CFG-09.3": [ + "1-6-3-2" + ], + "MON-01": [ + "2-12-1", + "2-12-2", + "5-1-3-3" + ], + "MON-01.2": [ + "2-12-3-3", + "2-12-3-4", + "5-1-3-3" + ], + "MON-01.4": [ + "2-12-3-1", + "2-12-3-2" + ], + "MON-08": [ + "2-14-3-3" + ], + "MON-10": [ + "2-12-3-5", + "2-14-3-3" + ], + "CRY-01": [ + "2-8-1", + "2-8-2", + "2-8-3-1" + ], + "CRY-03": [ + "2-8-3-3" + ], + "CRY-05": [ + "2-8-3-3" + ], + "CRY-09": [ + "2-8-3-2" ], "DCH-01": [ - "1", - "36", - "47" + "2-7-1" ], - "DCH-22.1": [ - "32" + "DCH-01.1": [ + "2-7-1", + "2-7-3-1" ], - "DCH-24": [ - "1", - "36" + "DCH-01.2": [ + "2-7-1" ], - "DCH-24.1": [ - "1", - "36" + "DCH-01.4": [ + "2-7-2" ], - "PRI-01": [ - "Inferred", - "Expectation" + "DCH-02": [ + "2-1-5", + "2-7-3-2", + "2-7-3-3", + "4-2-3-1" ], - "PRI-01.1": [ - "46" + "DCH-04": [ + "2-1-5" ], - "PRI-02": [ - "23" + "DCH-10": [ + "5-1-3-5" ], - "PRI-02.1": [ - "23" + "DCH-13.2": [ + "2-3-3-2", + "5-1-3-5" ], - "PRI-03": [ - "23" + "DCH-26": [ + "4-1-3-2", + "4-2-3-3" ], - "PRI-04": [ - "23" + "EMB-01": [ + "5-1-1", + "5-1-2", + "5-1-3-1", + "5-1-3-2", + "5-1-4" ], - "PRI-04.1": [ - "23" + "EMB-05": [ + "5-1-3-3" ], - "PRI-05": [ - "23", - "26" + "EMB-09": [ + "5-1-3-3" ], - "PRI-05.1": [ - "26" + "END-04": [ + "2-3-3-1", + "5-1-3-10" ], - "PRI-05.4": [ - "27" + "END-06.8": [ + "2-4-3-4" ], - "PRI-06": [ - "32" + "END-08": [ + "2-4-3-1" ], - "PRI-06.1": [ - "32" + "HRS-01": [ + "1-4-2", + "1-9-1", + "1-9-2", + "1-9-3", + "1-9-4", + "1-9-6" ], - "PRI-06.2": [ - "32" + "HRS-03": [ + "1-4-1", + "1-4-2", + "1-9-1" ], - "PRI-15": [ - "40" + "HRS-03.1": [ + "1-9-4-1" ], - "SEA-01": [ - "1", - "36", - "47" + "HRS-04": [ + "1-9-3-2" ], - "SEA-02": [ - "1", - "36", - "47" + "HRS-04.1": [ + "1-9-3-2" ], - "SEA-03": [ - "1", - "36", - "47" + "HRS-04.2": [ + "1-9-4-1", + "1-9-4-2" ], - "SEA-15": [ - "1", - "36" + "HRS-05": [ + "1-9-1", + "1-9-3-1" ], - "TPM-03": [ - "31" + "HRS-05.1": [ + "1-9-3-1", + "2-1-3", + "2-1-4", + "2-15-3-4" ], - "TPM-04.4": [ - "1", - "36" + "HRS-05.2": [ + "1-9-4-2" ], - "TPM-05": [ - "31" - ] - }, - "emea-qat-pdppl-2020": { - "GOV-02": [ - "8.4" + "HRS-05.3": [ + "1-9-4-2", + "2-15-3-4" ], - "GOV-15": [ - "8.3" + "HRS-05.4": [ + "1-9-4-2" ], - "GOV-15.1": [ - "8.3", - "11.1" + "HRS-05.5": [ + "1-9-4-2" ], - "GOV-15.2": [ - "8.3", - "11.3", - "11.5", - "11.6" + "HRS-05.7": [ + "1-9-4-1", + "1-9-4-2" ], - "GOV-15.3": [ - "8.3", - "11.1", - "11.2" + "HRS-06": [ + "1-9-3-1" ], - "GOV-15.4": [ - "8.3", - "11.1" + "HRS-06.1": [ + "1-9-3-1", + "4-1-2-1" ], - "GOV-15.5": [ - "8.3", - "11.7", - "11.8" + "IAC-01": [ + "2-2-1", + "2-2-3" ], - "CLD-09": [ - "15" + "IAC-01.2": [ + "2-2-3-1" ], - "CPL-01": [ - "2" + "IAC-06": [ + "2-2-3-2", + "2-4-3-2", + "2-15-3-5" ], - "CPL-03": [ - "11.7", - "11.8" + "IAC-07": [ + "1-9-5" ], - "CPL-03.2": [ - "11.7", - "11.8" + "IAC-08": [ + "2-2-3-3", + "2-6-3-2" ], - "DCH-19": [ - "15" + "IAC-16": [ + "2-2-3-4" ], - "DCH-25": [ - "15" + "IAC-17": [ + "2-2-3-5" ], - "IRO-04.1": [ - "14" + "IRO-01": [ + "2-13-1", + "2-13-2", + "2-13-3-1" + ], + "IRO-02.4": [ + "2-13-3-2" + ], + "IRO-04": [ + "2-13-3-1" ], "IRO-10": [ - "14" + "2-13-3-3", + "2-13-3-4" ], "IRO-10.2": [ - "14" + "2-13-3-3", + "2-13-3-4" ], "IAO-01": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" + "1-6-2" + ], + "IAO-01.1": [ + "2-11-3-1" ], "IAO-02": [ - "11.1", - "11.2" + "1-6-2-1", + "1-6-2-2" ], - "IAO-03": [ - "11.1" + "IAO-02.2": [ + "1-6-2-1", + "1-6-2-2" ], - "PRI-01": [ - "2", - "3", - "8.1" + "IAO-04": [ + "1-5-3" ], - "PRI-01.1": [ - "8.1" + "IAO-06": [ + "1-6-3-5" ], - "PRI-01.4": [ - "8.2", - "10" + "MDM-01": [ + "2-6-1", + "2-6-2" ], - "PRI-01.5": [ - "15" + "MDM-03": [ + "2-6-3-1" ], - "PRI-01.6": [ - "8.3", - "13" + "MDM-05": [ + "2-6-3-3" ], - "PRI-02": [ - "6.1", - "8.1", - "9.1", - "9.3", - "9.4", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "MDM-06": [ + "5-1-3-6" ], - "PRI-02.1": [ - "6.1", - "8.1", - "10" + "MDM-07": [ + "5-1-3-6" ], - "PRI-03": [ - "4", - "5.2", - "10" + "NET-01": [ + "2-5-1", + "2-5-2" ], - "PRI-03.4": [ - "5.1" + "NET-02": [ + "2-5-3-8" ], - "PRI-03.6": [ - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "NET-03.7": [ + "5-1-3-4" ], - "PRI-04": [ - "9.1", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "NET-04": [ + "2-5-3-5" ], - "PRI-04.1": [ - "9.2", - "18.1", - "18.2", - "18.3", - "18.4" + "NET-06": [ + "2-5-3-1", + "2-5-3-2", + "5-1-3-1", + "5-1-3-2" ], - "PRI-05.1": [ - "8.2", - "9.4" + "NET-06.3": [ + "5-1-3-1", + "5-1-3-2" ], - "PRI-05.4": [ - "8.2", - "9.4", - "10", - "16", - "22" + "NET-08": [ + "2-5-3-6" ], - "PRI-06": [ - "6", - "21.1", - "21.2" + "NET-10": [ + "2-5-3-7" ], - "PRI-06.1": [ - "5.4", - "6.2" + "NET-10.3": [ + "2-4-3-5" ], - "PRI-06.2": [ - "6.2" + "NET-15": [ + "2-5-3-4" ], - "PRI-06.4": [ - "5.3", - "5.4", - "6.3" + "NET-15.1": [ + "2-5-3-4" ], - "PRI-06.5": [ - "5.3" + "NET-18": [ + "2-5-3-3" ], - "PRI-06.6": [ - "6.3" + "PES-01": [ + "2-3-1", + "2-3-2", + "2-14-1", + "2-14-2", + "2-14-3-1", + "2-14-3-2", + "2-14-3-3", + "2-14-3-5", + "2-14-4" ], - "PRI-06.7": [ - "6.3" + "PES-03.3": [ + "2-14-3-3" ], - "PRI-07.1": [ - "12" + "PES-04": [ + "2-14-3-5" ], - "PRI-14": [ - "6.2" + "PES-04.1": [ + "2-14-3-5" ], - "PRI-14.1": [ - "6.2" + "PES-05": [ + "2-14-3-2" ], - "PRI-14.2": [ - "6.2" + "PES-05.1": [ + "2-14-3-2" + ], + "PRM-01": [ + "1-1-3", + "1-2-3" + ], + "PRM-01.1": [ + "1-1-1", + "1-1-2", + "1-1-3" + ], + "PRM-02": [ + "1-1-3" + ], + "PRM-02.1": [ + "1-6-4" + ], + "PRM-04": [ + "1-5-2", + "1-6-1" ], "PRM-05": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" + "1-6-1", + "2-9-1" ], "PRM-06": [ - "11.4", - "11.5", - "11.6" + "2-9-1" ], "PRM-07": [ - "11.4", - "11.5", - "11.6" + "1-5-3-1", + "1-5-3-2", + "1-5-3-3", + "1-5-3-4" ], - "RSK-10": [ - "8.2" + "RSK-01": [ + "1-5-1", + "1-5-2", + "1-5-4" ], - "SEA-02.1": [ - "1" + "RSK-04": [ + "1-5-3" + ], + "RSK-04.2": [ + "1-5-1", + "1-5-2" + ], + "SEA-01": [ + "1-6-3-1", + "1-6-3-4", + "2-15-3-3" + ], + "SEA-02": [ + "1-6-3-4" + ], + "SEA-03": [ + "2-15-3-2" + ], + "SEA-20": [ + "2-3-3-4" + ], + "OPS-01.1": [ + "1-3-4" ], "SAT-01": [ - "11.3" + "1-10-1", + "1-10-2" + ], + "SAT-02": [ + "1-10-1", + "2-6-3-4" + ], + "SAT-02.2": [ + "1-10-3-1" ], "SAT-03": [ - "11.3" + "1-10-4-1", + "1-10-4-2", + "1-10-4-3", + "1-10-5" + ], + "SAT-03.2": [ + "1-10-3-1" ], "SAT-03.3": [ - "11.3" + "1-10-3-2" ], - "TDA-01": [ - "11.4", - "11.5", - "11.6" + "SAT-03.6": [ + "1-10-3-3", + "1-10-3-4" ], "TDA-01.1": [ - "11.4", - "11.5", - "11.6" - ], - "TPM-05": [ - "12" + "1-6-3-4" ], - "TPM-05.2": [ - "12" - ] - }, - "emea-rus-federal-law-27-2006": { - "GOV-01": [ - "7", - "19" + "TDA-02.3": [ + "1-6-3-2" ], - "CPL-01": [ - "7", - "19" + "TDA-06": [ + "1-6-3-1" ], - "CPL-02": [ - "7", - "19" + "TDA-08": [ + "2-5-3-2" ], - "CPL-03": [ - "7" + "TDA-09": [ + "1-6-3-3" ], - "DCH-01": [ - "7", - "12", - "19" + "TDA-09.2": [ + "1-6-3-3" ], - "DCH-22.1": [ - "17" + "TDA-09.3": [ + "1-6-3-3" ], - "DCH-24": [ - "7" + "TDA-09.4": [ + "1-6-3-3" ], - "DCH-24.1": [ - "7" + "TDA-09.5": [ + "1-6-3-3" ], - "PRI-01": [ - "Inferred", - "Expectation" + "TPM-01": [ + "4-1-1", + "4-1-3-2" ], - "PRI-01.1": [ - "23" + "TPM-03": [ + "4-1-3-1" ], - "PRI-02": [ - "22" + "TPM-04.1": [ + "4-1-3-1" ], - "PRI-02.1": [ - "5" + "TPM-05": [ + "4-1-2-1", + "4-1-2-2", + "4-1-2-3" ], - "PRI-03": [ - "6", - "9" + "TPM-05.2": [ + "4-1-2-3" ], - "PRI-04": [ - "5" + "TPM-05.4": [ + "4-1-2-2" ], - "PRI-04.1": [ - "5" + "TPM-11": [ + "4-1-2-2" ], - "PRI-05": [ - "5" + "THR-01": [ + "2-13-1", + "2-13-2", + "2-13-3-5" ], - "PRI-05.4": [ - "6", - "10" + "THR-03": [ + "2-13-3-5" ], - "PRI-05.6": [ - "16" + "VPM-01": [ + "2-10-1", + "2-10-2", + "5-1-3-8" ], - "PRI-06": [ - "14" + "VPM-01.1": [ + "5-1-3-8" ], - "PRI-06.1": [ - "17" + "VPM-02": [ + "5-1-3-8" ], - "PRI-06.2": [ - "18" + "VPM-03": [ + "2-10-3-2", + "2-10-3-3" ], - "PRI-06.3": [ - "17" + "VPM-05": [ + "2-3-3-3", + "2-10-3-4", + "5-1-3-9" ], - "PRI-15": [ - "23" + "VPM-05.4": [ + "2-10-3-5" ], - "SEA-01": [ - "7", - "12", - "19" + "VPM-06": [ + "2-10-3-1" ], - "SEA-02": [ - "7", - "12", - "19" + "VPM-07": [ + "2-11-1", + "2-11-2", + "2-11-3-1", + "2-11-3-2" ], - "SEA-03": [ - "7", - "12", - "19" + "WEB-01": [ + "2-15-1", + "2-15-2", + "2-15-3", + "2-15-3-2", + "2-15-3-4", + "2-15-3-5", + "2-15-4" ], - "SEA-15": [ - "7" + "WEB-03": [ + "2-15-3-1" ], - "TPM-04.4": [ - "7" + "WEB-10": [ + "2-15-3-3" ] }, - "emea-sau-cscc-1-2019": { - "GOV-09": [ - "1-1" + "emea-sau-otcc-1-2022": { + "GOV-01.4": [ + "1-1-2" + ], + "GOV-02": [ + "1-1-1", + "1-1-2" + ], + "GOV-03": [ + "1-1-3" + ], + "GOV-05": [ + "1-4-2", + "1-7-2" + ], + "AAT-30.2": [ + "2-2-1-4" ], "AST-01": [ - "2-1", - "2-5" + "2-1-1", + "2-1-2" + ], + "AST-01.2": [ + "2-1-1-4" ], "AST-02": [ "2-1-1-1" ], - "AST-03": [ + "AST-02.9": [ "2-1-1-2" ], - "AST-05.1": [ - "2-6-1-5" + "AST-04": [ + "2-4-1-16" ], - "AST-16": [ - "2-5" + "BCD-01": [ + "2-8-1", + "2-8-2", + "3-1-1" ], - "AST-27": [ - "2-3-1-4" + "BCD-01.1": [ + "2-12-1-1" ], - "AST-28": [ - "2-2-1-8" + "BCD-01.4": [ + "3-1-1-1" ], - "BCD-01": [ - "2-8", - "3-1", - "3-1-1-1", - "3-1-1-2" + "BCD-01.7": [ + "3-1-1-3", + "3-1-1-4" ], "BCD-02": [ - "2-8-1-1", - "3-1-1-2" - ], - "BCD-03.1": [ - "3-1-1-4" + "2-1-1-5" ], - "BCD-04.2": [ - "3-1-1-1" + "BCD-02.2": [ + "3-1-1-5" ], - "BCD-08": [ - "3-1-1-1" + "BCD-02.3": [ + "3-1-1-5" ], - "BCD-09": [ - "3-1-1-1" + "BCD-04": [ + "3-1-1-6" ], "BCD-11": [ - "2-8-1-2", + "2-8-1-1", "2-8-1-3" ], - "BCD-11.1": [ - "2-8-2" + "BCD-11.2": [ + "2-8-1-2" ], "BCD-11.4": [ - "2-8-1-3" + "2-8-1-4" ], - "BCD-11.5": [ - "3-1-1-3" + "BCD-11.6": [ + "2-8-1-1" ], - "BCD-12": [ - "2-8-2" + "BCD-11.7": [ + "3-1-1-2" ], - "CHG-02.2": [ - "1-3-1-2" + "CAP-01": [ + "3-1-1", + "3-1-2" ], - "CHG-03": [ - "1-3-1-2" + "CHG-01": [ + "1-5-1", + "1-5-2", + "1-5-3" ], - "CHG-04.5": [ - "1-3-2-2" + "CHG-02": [ + "1-5-3-1", + "1-5-3-4" ], - "CLD-01": [ - "4-2" + "CHG-02.2": [ + "1-5-3-2" ], - "CLD-04": [ - "1-3-2-3" + "CHG-02.3": [ + "1-5-4" ], - "CLD-09": [ - "4-2-1-1" + "CHG-03": [ + "1-5-4" ], - "CPL-01": [ - "1-4" + "CHG-04": [ + "1-5-3-4" ], - "CPL-02": [ - "1-4" + "CHG-04.1": [ + "1-5-3-5" ], - "CPL-02.1": [ - "1-4-2", - "2-13-4" + "CHG-06": [ + "1-5-4" + ], + "CHG-08": [ + "2-2-1-6" ], "CPL-03": [ - "1-4-1", - "2-13-4" + "1-4-2", + "1-5-4", + "1-6-1", + "1-7-2", + "2-1-2", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-7-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-1-9", + "2-13-2", + "3-1-2", + "4-1-2" ], "CPL-03.1": [ - "1-4-2" - ], - "CPL-03.2": [ - "1-4-1" - ], - "CFG-01": [ - "2-3-1-6" + "1-6-2" ], "CFG-02": [ - "1-3-2-3", - "2-3-1-7" + "2-2-1-8", + "2-4-1-4" ], - "CFG-02.1": [ - "2-3-1-6" + "CFG-02.2": [ + "2-3-1-11" ], "CFG-02.5": [ - "1-3-2-3", - "2-3-1-7" + "2-2-1-5" + ], + "CFG-02.8": [ + "2-3-1-11" + ], + "CFG-03": [ + "2-4-1-14" + ], + "CFG-03.1": [ + "2-3-1-2" ], "CFG-03.3": [ - "2-3-1-1" + "2-3-1-6" ], "MON-01": [ - "2-11" + "2-11-1", + "2-11-1-10", + "2-11-2" ], "MON-01.2": [ - "2-11-1-3", - "2-11-1-4" + "2-11-1-3" ], "MON-01.4": [ "2-11-1-1" ], "MON-01.8": [ - "2-11-1-2" + "2-11-1-4" ], "MON-01.16": [ - "2-11" + "2-11-1-9" ], "MON-02": [ - "2-11-1-3", - "2-11-1-4" - ], - "MON-02.1": [ - "2-11-1-3", - "2-11-1-4" - ], - "MON-02.2": [ - "2-11-1-3" + "2-11-1-5", + "2-11-1-6", + "2-11-1-7", + "2-11-1-8" ], - "MON-02.5": [ - "2-3-1-8" + "MON-02.6": [ + "2-11-1-9" ], "MON-03": [ - "2-11-1-5" - ], - "MON-03.2": [ - "2-11-1-3" + "2-11-1-2" ], "MON-08": [ - "2-3-1-8", - "2-11-1-5", - "2-11-2" - ], - "MON-08.1": [ - "2-11-1-5", - "2-11-2" + "2-3-1-10" ], - "MON-10": [ - "2-11-2" + "MON-16": [ + "2-3-1-12" ], "CRY-01": [ - "2-7", - "2-7-1-3" - ], - "CRY-01.5": [ - "2-7-1-3" + "2-6-1", + "2-7-1", + "2-7-2" ], "CRY-03": [ - "2-3-1-5", - "2-7-1-1" + "2-6-1-1" ], "CRY-05": [ - "2-7-1-2" + "2-6-1-1" ], "DCH-01": [ - "2-6", - "2-6-1-3" - ], - "DCH-02": [ - "2-6-1-2" - ], - "DCH-02.1": [ - "2-6-1-1" + "2-6-1", + "2-6-2" ], - "DCH-03.1": [ - "2-6-1-3" + "DCH-01.2": [ + "2-1-1-3" ], - "DCH-14.2": [ - "2-6-1-5" + "DCH-12": [ + "2-3-1-9" ], "DCH-17": [ - "2-6-1-5" - ], - "DCH-18": [ - "2-6-1-4", - "2-11-2" + "2-6-1-4" ], - "DCH-25": [ - "2-6-1-5" + "EMB-01": [ + "1-4-1" ], - "END-01": [ - "2-3-1-2", - "2-5" + "END-04": [ + "2-3-1-1", + "2-3-1-8" ], - "END-02": [ - "2-3-1-2" + "END-06.8": [ + "2-3-1-1", + "2-3-1-12" ], "HRS-01": [ - "1-5", - "2-5" + "1-7-1", + "1-7-2" ], "HRS-02": [ - "1-5-1-2" + "1-2-1-2" + ], + "HRS-03": [ + "1-2-1", + "1-2-1-2" ], "HRS-04": [ - "1-5-1-1" + "1-7-1" ], - "HRS-04.3": [ - "1-5-1-2" + "HRS-05.5": [ + "2-5-1-1", + "2-5-1-2" ], - "HRS-05": [ - "2-5" + "HRS-10": [ + "1-7-1" ], - "HRS-05.1": [ - "2-5" + "IAC-01": [ + "2-2-1", + "2-2-2" ], - "HRS-05.3": [ - "2-5" + "IAC-02": [ + "2-2-1-2" ], - "IAC-01": [ - "2-2", - "2-2-1-5" + "IAC-07": [ + "2-2-1-10", + "2-2-1-11" ], - "IAC-02.1": [ - "2-2-1-7" + "IAC-07.1": [ + "2-2-1-11" ], - "IAC-06": [ - "2-2-1-3", - "2-2-1-4" + "IAC-07.2": [ + "2-2-1-11" ], - "IAC-06.1": [ - "2-2-1-4" + "IAC-10.1": [ + "2-2-1-8" ], - "IAC-06.2": [ + "IAC-10.8": [ "2-2-1-3" ], - "IAC-06.3": [ - "2-2-1-4" + "IAC-10.11": [ + "2-2-1-9" ], - "IAC-10": [ - "2-2-1-6" + "IAC-17": [ + "2-2-1-10" ], - "IAC-10.1": [ - "2-2-1-5" + "IAC-20.4": [ + "2-3-1-7" ], - "IAC-10.5": [ - "2-2-1-6" + "IAC-21": [ + "2-3-1-4" ], - "IAC-10.11": [ - "2-2-1-6" + "IRO-01": [ + "2-12-1", + "2-12-2" ], - "IAC-15": [ - "2-2-1-7" + "IRO-02": [ + "2-12-1-3", + "2-12-1-4" ], - "IAC-18": [ - "2-2-2" + "IRO-04": [ + "2-12-1-1", + "2-12-1-3", + "2-12-1-5" ], - "IAC-20.2": [ - "2-2-1-8" + "IRO-05": [ + "2-12-1-6" ], - "IAC-20.4": [ - "2-3-1-4" + "IRO-06": [ + "2-12-1-7" + ], + "IRO-07": [ + "2-12-1-4" + ], + "IRO-13": [ + "2-12-1-2" + ], + "IAO-01": [ + "1-5-3-3" + ], + "IAO-02": [ + "1-4-1-2" + ], + "IAO-02.2": [ + "1-4-1-2", + "1-5-3-3", + "2-10-1-4" + ], + "IAO-05": [ + "1-3-1-7" + ], + "IAO-06": [ + "1-4-1-2", + "1-5-3-3" + ], + "IAO-07": [ + "1-4-1-2", + "1-5-3-3" ], "MDM-01": [ - "2-5" + "2-5-1", + "2-5-1-4", + "2-5-2" ], "MDM-02": [ - "2-5-1-1" + "2-5-1-3" ], "MDM-03": [ - "2-5-1-2" + "2-5-1-5" + ], + "MDM-05": [ + "2-6-1-3" ], "MDM-06": [ - "2-5-1-1" + "2-5-1-3" ], - "MDM-11": [ - "2-5-1-1" + "MDM-07": [ + "2-5-1-1", + "2-5-1-3" ], "NET-01": [ - "2-3-1-5", - "2-4", - "2-4-1-5" - ], - "NET-02": [ - "2-4-1-5" + "2-4-1", + "2-4-2" ], - "NET-02.1": [ - "2-4-1-8" + "NET-03": [ + "2-3-1-13", + "2-4-1-12" ], "NET-04": [ - "2-4-1-4", - "2-4-1-6", - "2-4-1-7", - "2-4-1-9" - ], - "NET-04.1": [ - "2-4-1-4", "2-4-1-6", - "2-4-1-7", - "2-4-1-9" - ], - "NET-04.6": [ - "2-3-1-6", - "2-4-1-2" + "2-4-1-8", + "2-4-1-9", + "2-4-1-10" ], "NET-06": [ - "2-3-1-4", - "2-4-1-1" + "2-4-1-1", + "2-4-1-2", + "2-4-1-5" ], "NET-06.3": [ - "2-4-1-6", - "2-4-1-7" + "2-4-1-2", + "2-4-1-3" ], "NET-06.5": [ - "2-4-1-3", - "2-4-1-6" + "2-4-1-7" + ], + "NET-06.9": [ + "2-4-1-1", + "2-4-1-5", + "2-4-1-6", + "2-4-1-9", + "2-4-1-10", + "2-4-1-12", + "2-4-1-13" + ], + "NET-08": [ + "2-3-1-12", + "2-3-1-13" ], "NET-14": [ - "2-2-1-1", - "2-2-1-2" + "2-2-1-7", + "2-4-1-10" ], - "NET-14.5": [ - "2-2-1-1", - "2-2-1-2" + "NET-14.1": [ + "2-2-1-7" + ], + "NET-14.2": [ + "2-2-1-7" + ], + "NET-14.3": [ + "2-4-1-7" ], "NET-15": [ - "2-3-1-5", "2-4-1-4" ], - "NET-15.2": [ - "2-4-1-4" + "NET-17": [ + "2-6-1-2" ], "NET-18.1": [ - "2-4-1-3" + "2-4-1-11" ], "PES-01": [ - "2-3" + "2-3-1", + "2-3-2", + "2-13-1", + "2-13-2" ], - "PRM-01": [ - "1-1" + "PES-02": [ + "2-13-1-1" ], - "PRM-01.1": [ - "1-1", - "1-1-1" + "PES-03": [ + "2-13-1-3" + ], + "PES-03.4": [ + "2-13-1-5" + ], + "PES-04": [ + "2-13-1-4" + ], + "PES-05": [ + "2-13-1-2" + ], + "PES-05.1": [ + "2-13-1-2" + ], + "PES-05.2": [ + "2-13-1-7" + ], + "PES-06": [ + "2-13-1-6" + ], + "PRM-01": [ + "1-4-2" ], "PRM-02": [ - "1-1" + "1-4-2" + ], + "PRM-02.1": [ + "1-4-2" ], "PRM-03": [ - "1-1" + "1-4-2" ], "PRM-04": [ - "1-3", - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "1-4-1-1", + "1-4-1-3" ], "PRM-05": [ - "1-3-1-2", - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "1-4-1-1" ], "PRM-07": [ - "2-13-4" + "1-4-1-1" ], "RSK-01": [ - "1-2" + "1-3-1" ], "RSK-04": [ - "1-2-1-1" + "1-3-1-2", + "1-3-1-4", + "1-3-1-5" ], "RSK-04.1": [ - "1-2-1-2" + "1-3-1-3" ], - "TDA-01": [ - "2-13", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "RSK-04.2": [ + "1-3-1-1" ], - "TDA-01.1": [ - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "RSK-06.2": [ + "1-3-1-6", + "1-3-1-7" ], - "TDA-02": [ - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "RSK-06.3": [ + "1-3-1-6" ], - "TDA-06": [ - "1-3-2-3", - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "RSK-06.4": [ + "1-3-1-6" ], - "TDA-07": [ - "1-3-2-4" + "SEA-01": [ + "1-4-1-3" ], - "TDA-08": [ - "1-3-2-4" + "SEA-01.2": [ + "3-1-1-1" ], - "TDA-08.1": [ - "1-3-2-4" + "SEA-07.1": [ + "2-2-1-1" ], - "TDA-09": [ - "1-3-1-1", - "1-3-2-1" + "SAT-01": [ + "1-8-1" ], - "TDA-09.2": [ - "1-3-2-1" + "SAT-02": [ + "1-8-2" ], - "TDA-09.3": [ - "1-3-2-1" + "SAT-03": [ + "1-8-2-1", + "2-13-1-8" ], - "TDA-15": [ - "1-3-2-1" + "SAT-03.6": [ + "1-8-2-2", + "2-13-1-8" ], - "TDA-20.3": [ - "1-3-2-2" + "SAT-03.7": [ + "1-8-2-1" ], - "TPM-01": [ - "4-1" + "TDA-07": [ + "1-4-1-4" ], - "TPM-02": [ - "4-1-1-1" + "TPM-01": [ + "4-1-1", + "4-1-2" ], - "TPM-03": [ - "4-1-1-1", + "TPM-04.1": [ "4-1-1-2" ], - "TPM-03.1": [ + "TPM-05": [ "4-1-1-1", - "4-1-1-2" + "4-1-1-3" ], - "TPM-03.2": [ - "4-1-1-1", - "4-1-1-2" + "TPM-05.4": [ + "1-2-1-1" ], - "TPM-04": [ - "4-1-1-1", - "4-1-1-2" + "TPM-08": [ + "4-1-1-4" ], - "TPM-04.1": [ - "4-1-1-1", - "4-1-1-2" + "THR-01": [ + "2-12-1-8" ], - "TPM-05": [ - "4-1-1", - "4-1-1-1", - "4-1-1-2" + "THR-03": [ + "2-12-1-8" ], "VPM-01": [ - "2-3-1-3", - "2-9", - "2-9-2" + "2-9-1", + "2-9-2", + "2-10-1", + "2-10-2" ], "VPM-01.1": [ + "2-9-1-1", "2-10-1-1" ], "VPM-02": [ "2-9-1-2" ], - "VPM-03": [ - "2-9-1-2" - ], - "VPM-04": [ - "2-9-1-3" - ], "VPM-05": [ - "2-3-1-3" + "2-3-1-3", + "2-4-1-15" ], - "VPM-06": [ - "2-9-1-1", - "2-9-2" + "VPM-05.8": [ + "2-4-1-15" ], - "VPM-06.2": [ - "2-9-2-1" + "VPM-06": [ + "2-9-1-3" ], "VPM-07": [ - "2-10", - "2-10-1-1", "2-10-1-2", - "2-10-2" + "2-10-1-3" ], - "VPM-07.1": [ - "2-10-1-2" + "WEB-02": [ + "2-4-1-13" + ] + }, + "emea-sau-pdpl-2023": { + "CPL-01": [ + "Article 2.1", + "Article 30.3" ], - "WEB-01": [ - "2-12", - "2-12-1-1", - "2-12-1-2" + "CPL-01.2": [ + "Article 2.2" ], - "WEB-04": [ - "2-12", - "2-12-1-1", - "2-12-1-2" + "CPL-01.3": [ + "Article 30.4.a" ], - "WEB-06": [ - "2-12-1-1" + "DCH-03.1": [ + "Article 15.3", + "Article 15.4", + "Article 15.5", + "Article 15.6", + "Article 16.1", + "Article 16.2", + "Article 16.3", + "Article 16.4", + "Article 16.5", + "Article 16.6", + "Article 16.7", + "Article 16.8", + "Article 16.9" ], - "WEB-07": [ - "2-12-1-2" + "DCH-18.1": [ + "Article 11.3" ], - "WEB-08": [ - "2-12-1-1" + "DCH-22.1": [ + "Article 17.1" ], - "WEB-10": [ - "2-12-1-1" + "DCH-22.3": [ + "Article 10" ], - "WEB-12": [ - "2-12-1-1" - ] - }, - "emea-sau-cgiot-2024": { - "GOV-01": [ - "1-1-2" + "DCH-25": [ + "Article 29.1" ], - "GOV-01.1": [ - "1-1-4" + "HRS-03": [ + "Article 30.2" ], - "GOV-02": [ - "1-2-1" + "IRO-04.1": [ + "Article 20.1", + "Article 20.2" ], - "GOV-03": [ - "1-1-4", - "1-2-3", - "1-4-6", - "1-8-3" + "PRI-01": [ + "Article 11.2" ], - "GOV-05": [ - "1-1-4" + "PRI-01.4": [ + "Article 30.2" ], - "GOV-05.1": [ - "1-1-3" + "PRI-01.5": [ + "Article 29.2.b" ], - "GOV-15": [ - "1-6-1" + "PRI-01.6": [ + "Article 19" ], - "GOV-15.1": [ - "1-6-1" + "PRI-01.7": [ + "Article 23.1", + "Article 23.2", + "Article 29.2.c" ], - "GOV-15.2": [ - "1-6-1" + "PRI-02": [ + "Article 4.1", + "Article 12", + "Article 13.2", + "Article 13.4", + "Article 13.5", + "Article 13.6" ], - "GOV-15.3": [ - "1-6-1" + "PRI-02.1": [ + "Article 11.1", + "Article 13.2", + "Article 13.3" ], - "GOV-15.4": [ - "1-6-1" + "PRI-03": [ + "Article 5.1", + "Article 10.1", + "Article 15.1", + "Article 24.1", + "Article 25.1", + "Article 25.2", + "Article 25.3", + "Article 26" ], - "GOV-15.5": [ - "1-6-1" + "PRI-03.4": [ + "Article 5.2" ], - "AST-01.1": [ - "4-1-4" + "PRI-03.5": [ + "Article 7" ], - "AST-02": [ - "2-1-1" + "PRI-04.1": [ + "Article 13.1" ], - "AST-02.1": [ - "2-1-2" + "PRI-04.2": [ + "Article 10" ], - "AST-02.9": [ - "2-1-2" + "PRI-04.4": [ + "Article 10", + "Article 14", + "Article 15.2" ], - "AST-08": [ - "2-6-2", - "2-13-2" + "PRI-04.5": [ + "Article 14" ], - "AST-09": [ - "2-5-1", - "2-15-3" + "PRI-04.7": [ + "Article 11.2" ], - "AST-15": [ - "2-6-2" + "PRI-05": [ + "Article 11.4", + "Article 18.1", + "Article 18.2.a", + "Article 18.2.b" ], - "AST-18": [ - "2-15-1" + "PRI-05.2": [ + "Article 14" ], - "BCD-01": [ - "2-8-1", - "2-12-2", - "3-1-1" + "PRI-05.4": [ + "Article 11.3" ], - "BCD-11": [ - "2-8-1", - "2-8-2" + "PRI-06": [ + "Article 4.2", + "Article 4.3", + "Article 4.4", + "Article 4.5", + "Article 21" ], - "BCD-11.1": [ - "2-8-2" + "PRI-07": [ + "Article 8" ], - "BCD-11.5": [ - "2-8-3" + "PRI-12": [ + "Article 17.1" ], - "BCD-12": [ - "2-12-2" + "PRI-14": [ + "Article 31", + "Article 31.1", + "Article 31.2", + "Article 31.3", + "Article 31.4", + "Article 31.5", + "Article 31.6" ], - "CHG-01": [ - "1-5-3" + "PRI-14.2": [ + "Article 24.2" ], - "CHG-02.2": [ - "1-5-3" + "RSK-10": [ + "Article 22" ], - "CHG-05": [ - "1-5-3" + "TPM-05": [ + "Article 8" ], - "CLD-01": [ - "4-2-1" + "TPM-08": [ + "Article 8" + ] + }, + "emea-sau-sacs-002-2022": { + "GOV-01.3": [ + "VII.B.TPC-69" ], - "CLD-02": [ - "4-2-1", - "4-2-2" + "GOV-02": [ + "VII.B.TPC-24", + "VII.B.TPC-25" ], - "CPL-01": [ - "1-2-3", - "1-6-1", - "2-6-1", - "2-7-1" + "AST-09": [ + "VII.A.TPC-19", + "VII.B.TPC-66" ], - "CPL-01.1": [ - "1-7-3" + "BCD-01": [ + "VII.B.TPC-64" ], - "CPL-02": [ - "1-7-3" + "BCD-01.7": [ + "VII.B.TPC-67", + "VII.B.TPC-68", + "VII.B.TPC-68(a)", + "VII.B.TPC-68(b)", + "VII.B.TPC-68(c)", + "VII.B.TPC-68(d)", + "VII.B.TPC-68(e)", + "VII.B.TPC-68(f)", + "VII.B.TPC-68(g)", + "VII.B.TPC-68(h)", + "VII.B.TPC-68(i)", + "VII.B.TPC-69" ], - "CPL-02.2": [ - "1-7-1" + "BCD-04": [ + "VII.B.TPC-70" ], - "CPL-03.1": [ - "1-7-2" + "BCD-11": [ + "VII.B.TPC-64" ], - "CPL-03.2": [ - "1-7-1" + "BCD-11.2": [ + "VII.B.TPC-65" ], - "CFG-02": [ - "1-2-2", - "2-5-1", - "2-6-3", - "2-14-2", - "2-15-2" + "BCD-11.4": [ + "VII.B.TPC-50", + "VII.B.TPC-65" ], - "CFG-02.1": [ - "2-14-4" + "CAP-02": [ + "VII.B.TPC-92" ], - "CFG-03.3": [ - "2-14-2" + "CFG-02": [ + "VII.A.TPC-2", + "VII.A.TPC-2-BP1", + "VII.A.TPC-2-BP2", + "VII.A.TPC-2-BP3", + "VII.A.TPC-2-BP4", + "VII.A.TPC-2-BP5", + "VII.A.TPC-10", + "VII.B.TPC-56", + "VII.B.TPC-62", + "VII.B.TPC-63", + "VII.B.TPC-63-BP1", + "VII.B.TPC-63-BP2", + "VII.B.TPC-63-BP3", + "VII.B.TPC-63-BP4" ], - "MON-01": [ - "2-11-1" + "MON-01.15": [ + "VII.B.TPC-83" ], - "MON-01.2": [ - "2-11-1" + "MON-02.1": [ + "VII.B.TPC-81" ], - "MON-01.8": [ - "2-11-1" + "MON-03": [ + "VII.B.TPC-87" ], "MON-10": [ - "2-11-1" + "VII.B.TPC-75" ], - "CRY-03": [ - "2-4-1", - "2-4-2", - "2-4-3", - "2-7-2" + "MON-11.3": [ + "VII.B.TPC-80" ], - "CRY-04": [ - "2-4-1", - "2-4-2", - "2-4-3" + "MON-16": [ + "VII.B.TPC-80" ], - "CRY-05": [ - "2-7-2" + "CRY-01": [ + "VII.B.TPC-54" ], - "DCH-02": [ - "2-6-1" + "CRY-03": [ + "VII.B.TPC-52", + "VII.B.TPC-53" ], - "EMB-01": [ - "1-1-1", - "1-1-2", - "2-4-6", - "2-5-1" + "CRY-07": [ + "VII.B.TPC-42" ], - "EMB-02": [ - "2-5-1" + "CRY-09": [ + "VII.B.TPC-55" ], - "EMB-04": [ - "2-14-1" + "DCH-01.2": [ + "VII.B.TPC-39", + "VII.B.TPC-58" ], - "EMB-05": [ - "2-11-2" + "DCH-01.4": [ + "VII.B.TPC-39" ], - "EMB-06": [ - "2-6-2" + "DCH-02": [ + "VII.B.TPC-24" ], - "EMB-07": [ - "2-4-6" + "DCH-09": [ + "VII.A.TPC-19", + "VII.B.TPC-66" ], - "EMB-08": [ - "3-1-1", - "3-1-2" + "DCH-13": [ + "VII.B.TPC-36" ], - "EMB-09": [ - "2-11-2" + "DCH-18": [ + "VII.A.TPC-19" ], - "END-13.3": [ - "2-6-3" + "END-04": [ + "VII.A.TPC-12" + ], + "END-05": [ + "VII.A.TPC-22" + ], + "END-08": [ + "VII.A.TPC-16" ], "HRS-01": [ - "1-3-2", - "1-8-1" + "VII.B.TPC-26" ], "HRS-01.1": [ - "1-8-1", - "1-8-2" - ], - "HRS-02": [ - "1-8-1" + "VII.A.TPC-18", + "VII.B.TPC-71" ], "HRS-03": [ - "1-3-1", - "1-3-2", - "1-8-1" + "VII.B.TPC-26" ], - "HRS-11": [ - "2-2-1" + "HRS-03.2": [ + "VII.B.TPC-26" + ], + "HRS-05": [ + "VII.A.TPC-1" + ], + "HRS-05.1": [ + "VII.A.TPC-1" + ], + "HRS-05.3": [ + "VII.A.TPC-8" + ], + "HRS-05.5": [ + "VII.B.TPC-84" + ], + "HRS-06.1": [ + "VII.A.TPC-9" + ], + "HRS-09.4": [ + "VII.A.TPC-6" + ], + "IAC-02": [ + "VII.B.TPC-32" + ], + "IAC-03": [ + "VII.B.TPC-32" + ], + "IAC-06": [ + "VII.A.TPC-4", + "VII.A.TPC-5", + "VII.B.TPC-37", + "VII.B.TPC-44", + "VII.B.TPC-45" + ], + "IAC-07": [ + "VII.A.TPC-6" ], "IAC-08": [ - "2-2-1" + "VII.B.TPC-34" ], "IAC-10": [ - "2-2-2" + "VII.B.TPC-62" ], "IAC-10.1": [ - "2-2-2" - ], - "IAC-10.8": [ - "2-2-2" + "VII.A.TPC-2" ], - "IAC-15.7": [ - "1-8-2" + "IAC-10.5": [ + "VII.A.TPC-3" ], - "IAC-16": [ - "2-2-1" + "IAC-15": [ + "VII.B.TPC-32" ], "IAC-17": [ - "1-8-2", - "2-2-3" + "VII.B.TPC-33" ], "IAC-21": [ - "2-2-1" + "VII.B.TPC-34" ], - "IAC-22": [ - "2-2-2" + "IRO-01": [ + "VII.A.TPC-23" ], "IRO-02": [ - "2-12-2" + "VII.B.TPC-89" + ], + "IRO-03": [ + "VII.B.TPC-80" ], "IRO-04": [ - "2-12-1", - "2-12-2" + "VII.A.TPC-23-BP2", + "VII.B.TPC-88" + ], + "IRO-09": [ + "VII.B.TPC-90" ], "IRO-10": [ - "2-12-2" + "VII.A.TPC-23-BP1" ], "IRO-13": [ - "2-12-2", - "2-12-3" - ], - "IAO-01": [ - "1-5-2", - "2-15-2", - "4-1-5", - "4-2-3" - ], - "IAO-02": [ - "2-15-2", - "4-1-5", - "4-2-3", - "4-2-4" - ], - "NET-01": [ - "2-3-1", - "2-3-2", - "2-4-1", - "2-4-5" + "VII.B.TPC-89" ], - "NET-03": [ - "2-4-5" + "IAO-02.2": [ + "VII.B.TPC-72" ], - "NET-06": [ - "2-4-4" + "IAO-04": [ + "VII.B.TPC-72" ], - "NET-13": [ - "2-3-1", - "2-3-2" + "IAO-06": [ + "VII.B.TPC-72", + "VII.B.TPC-73" ], - "PES-05": [ - "2-13-1" + "IAO-07": [ + "VII.B.TPC-72", + "VII.B.TPC-73" ], - "PES-05.1": [ - "2-13-1" + "MDM-05": [ + "VII.B.TPC-59" ], - "PES-16": [ - "2-6-1" + "MDM-06": [ + "VII.B.TPC-84" ], - "PRM-07": [ - "1-5-2" + "NET-03": [ + "VII.B.TPC-76" ], - "RSK-01": [ - "1-4-1" + "NET-05.1": [ + "VII.B.TPC-36" ], - "RSK-01.5": [ - "1-4-5" + "NET-06": [ + "VII.B.TPC-40" ], - "RSK-03": [ - "1-1-2", - "1-4-1", - "1-4-5" + "NET-06.3": [ + "VII.B.TPC-38" ], - "RSK-03.1": [ - "1-4-2", - "1-4-4" + "NET-08": [ + "VII.B.TPC-77" ], - "RSK-04": [ - "1-4-1", - "1-4-4" + "NET-10.3": [ + "VII.A.TPC-13", + "VII.A.TPC-14", + "VII.A.TPC-15" ], - "RSK-04.1": [ - "1-4-3" + "NET-14.4": [ + "VII.B.TPC-35" ], - "RSK-06": [ - "1-1-2", - "1-4-1", - "1-4-5" + "NET-15.1": [ + "VII.B.TPC-42" ], - "SEA-01": [ - "1-5-1", - "2-5-1" + "NET-18": [ + "VII.B.TPC-57", + "VII.B.TPC-57-BP1", + "VII.B.TPC-57-BP2", + "VII.B.TPC-57-BP3" ], - "SEA-07.1": [ - "2-15-3" + "PES-02": [ + "VII.B.TPC-86" ], - "OPS-01.1": [ - "1-2-1" + "PES-02.1": [ + "VII.B.TPC-86" ], - "SAT-01": [ - "1-9-1" + "PES-03": [ + "VII.B.TPC-82" ], - "SAT-02": [ - "1-9-1", - "1-9-2" + "PES-03.2": [ + "VII.B.TPC-46" ], - "SAT-03": [ - "1-9-1" + "PES-03.4": [ + "VII.B.TPC-46" ], - "SAT-03.6": [ - "1-9-2" + "PES-04.1": [ + "VII.B.TPC-49" ], - "TDA-02.5": [ - "2-15-1" + "PES-06": [ + "VII.B.TPC-47", + "VII.B.TPC-47-BP2", + "VII.B.TPC-47-BP3" ], - "TDA-04.2": [ - "4-1-3" + "PES-06.2": [ + "VII.B.TPC-47-BP1" ], - "TDA-06": [ - "2-14-3" + "PES-06.3": [ + "VII.B.TPC-48" ], - "TDA-06.2": [ - "2-12-1" + "PES-18": [ + "VII.B.TPC-38", + "VII.B.TPC-49" ], - "TDA-06.5": [ - "2-14-3" + "RSK-04": [ + "VII.B.TPC-31" ], - "TPM-05": [ - "4-1-1", - "4-2-5" + "SAT-02": [ + "VII.A.TPC-7", + "VII.A.TPC-7.1", + "VII.A.TPC-7.2", + "VII.A.TPC-7.4", + "VII.A.TPC-7.5", + "VII.A.TPC-8", + "VII.A.TPC-9" ], - "TPM-05.6": [ - "4-1-2" + "SAT-02.2": [ + "VII.A.TPC-7.3" ], - "TPM-08": [ - "4-1-6" + "TDA-06": [ + "VII.B.TPC-74" ], - "TPM-09": [ - "4-1-6" + "TDA-17": [ + "VII.B.TPC-51" ], - "THR-01": [ - "2-12-4" + "TDA-18": [ + "VII.B.TPC-60" ], - "THR-03": [ - "2-12-4" + "TDA-19": [ + "VII.B.TPC-61" ], - "THR-03.1": [ - "2-12-4" + "TDA-19.1": [ + "VII.B.TPC-61" ], - "THR-09": [ - "1-4-4" + "TPM-04": [ + "VII.B.TPC-36" ], - "THR-10": [ - "1-4-4" + "TPM-05": [ + "VII.A.TPC-17", + "VII.A.TPC-23-BP2" ], - "VPM-01": [ - "2-9-1" + "TPM-05.8": [ + "VII.A.TPC-20", + "VII.A.TPC-21" ], "VPM-02": [ - "2-9-1" + "VII.B.TPC-91", + "VII.B.TPC-91-BP1", + "VII.B.TPC-91-BP2", + "VII.B.TPC-91-BP3" ], "VPM-05": [ - "2-4-6", - "2-9-2" + "VII.A.TPC-11" ], "VPM-06": [ - "2-9-1" + "VII.B.TPC-85" + ], + "VPM-06.1": [ + "VII.B.TPC-78" ], "VPM-07": [ - "2-10-1" + "VII.B.TPC-27", + "VII.B.TPC-28", + "VII.B.TPC-29" ], - "VPM-10": [ - "2-10-2" + "WEB-02": [ + "VII.B.TPC-41" + ], + "WEB-03": [ + "VII.B.TPC-79" ] }, - "emea-sau-ecc-1-2018": { + "emea-sau-sama-csf-1-2017": { "GOV-01": [ - "1-2-1", - "1-3-2" + "3.1.1" + ], + "GOV-01.1": [ + "3.1.1.1", + "3.1.1.2", + "3.1.1.3", + "3.1.1.3.a", + "3.1.1.3.b", + "3.1.1.3.c", + "3.1.1.4", + "3.1.1.4.a", + "3.1.1.4.b", + "3.1.1.4.c", + "3.1.1.4.d", + "3.1.1.5", + "3.1.1.6", + "3.1.1.7", + "3.1.1.8", + "3.1.1.9", + "3.1.1.9.a", + "3.1.1.9.b", + "3.1.1.9.c" + ], + "GOV-01.4": [ + "3.2.3", + "3.2.3.1", + "3.2.3.1.a", + "3.2.3.1.b", + "3.2.3.1.c" ], "GOV-02": [ - "1-3-1", - "1-3-3" + "3.1.3", + "3.1.3.1", + "3.1.3.3", + "3.1.3.3.a", + "3.1.3.3.b", + "3.1.3.3.c", + "3.1.3.3.d", + "3.1.3.4", + "3.1.3.4.a", + "3.1.3.4.b", + "3.1.3.4.c", + "3.1.3.4.d", + "3.1.3.4.e", + "3.1.3.4.f", + "3.1.3.4.f.1", + "3.1.3.4.f.2", + "3.1.3.4.f.3", + "3.1.3.4.f.4", + "3.1.3.4.f.5", + "3.1.3.4.f.6", + "3.1.3.4.f.7", + "3.1.3.4.f.8", + "3.3.5.1", + "3.3.5.4", + "3.3.5.4.a", + "3.3.5.4.b", + "3.3.5.4.b.1", + "3.3.5.4.b.2", + "3.3.5.4.b.3", + "3.3.5.4.b.4", + "3.3.5.4.b.5", + "3.3.5.4.b.6", + "3.3.5.4.b.7", + "3.3.5.4.c", + "3.3.5.4.d", + "3.3.5.4.e", + "3.3.5.4.f", + "3.3.5.4.f.1", + "3.3.5.4.f.1.a", + "3.3.5.4.f.1.b", + "3.3.5.4.f.2", + "3.3.5.4.f.3", + "3.3.5.4.f.4", + "3.3.5.4.f.4.a", + "3.3.5.4.f.4.b", + "3.3.5.4.f.4.c", + "3.3.8", + "3.3.8.1", + "3.3.8.4", + "3.3.8.5", + "3.3.8.6", + "3.3.8.6.a", + "3.3.8.6.b", + "3.3.8.6.c", + "3.3.8.6.d", + "3.3.8.6.e", + "3.3.8.6.f", + "3.3.8.6.g", + "3.3.8.6.h", + "3.3.8.6.h.1", + "3.3.8.6.h.2", + "3.3.8.6.h.3", + "3.3.8.6.h.4", + "3.3.8.6.h.5", + "3.3.8.6.i", + "3.3.8.6.j", + "3.3.10", + "3.3.10.1" ], "GOV-03": [ - "1-1-3", - "1-3-4", - "1-6-4", - "1-9-6", - "1-10-5", - "2-2-4", - "2-3-4", - "2-4-4", - "2-5-4", - "2-6-4", - "2-7-4", - "2-8-4", - "2-9-4", - "2-10-4", - "2-11-4", - "2-12-4", - "2-13-4", - "2-14-4", - "2-15-4", - "3-1-4", - "4-1-4", - "4-2-4", - "5-1-4" + "3.1.3.2" ], "GOV-04": [ - "1-2-2", - "1-4-1", - "1-4-2", - "1-5-2" + "3.1.4", + "3.1.4.4", + "3.1.4.4.a", + "3.1.4.4.a.1", + "3.1.4.4.a.2", + "3.1.4.4.a.3", + "3.1.4.4.a.4", + "3.1.4.4.b", + "3.1.4.4.c", + "3.1.4.4.d", + "3.1.4.4.e", + "3.1.4.4.e.1", + "3.1.4.4.e.2", + "3.1.4.4.e.3", + "3.1.4.4.e.4", + "3.1.4.4.e.5", + "3.1.4.4.f", + "3.1.4.4.g", + "3.1.4.4.g.1", + "3.1.4.4.g.2", + "3.1.4.4.g.3", + "3.1.4.4.h", + "3.1.4.4.i", + "3.1.4.4.i.1", + "3.1.4.4.i.2", + "3.1.4.4.i.3", + "3.1.4.4.i.4" ], - "GOV-08": [ - "1-1-1" + "GOV-04.1": [ + "3.1.4.1", + "3.1.4.1.a", + "3.1.4.1.b", + "3.1.4.1.c", + "3.1.4.1.c.1", + "3.1.4.1.c.2", + "3.1.4.1.c.3", + "3.1.4.2", + "3.1.4.2.a", + "3.1.4.2.b", + "3.1.4.2.c", + "3.1.4.2.c.1", + "3.1.4.2.c.2", + "3.1.4.2.c.3", + "3.1.4.2.c.4", + "3.1.4.2.c.5", + "3.1.4.2.c.6", + "3.1.4.3", + "3.1.4.3.a", + "3.1.4.3.b", + "3.1.4.3.c", + "3.1.4.5", + "3.1.4.5.a" + ], + "GOV-19.3": [ + "3.4.2.3", + "3.4.2.3.a", + "3.4.2.3.b", + "3.4.2.3.c" ], "AST-01": [ - "2-1-1", - "2-1-2", - "2-6-1", - "2-6-2", - "2-6-4" + "3.3.3", + "3.3.3.1", + "3.3.3.3" + ], + "AST-02.9": [ + "3.3.3.3", + "3.3.3.3.a", + "3.3.3.3.b", + "3.3.3.3.c", + "3.3.3.3.d", + "3.3.3.3.e" ], "AST-09": [ - "2-14-3-4" + "3.3.2.3.e", + "3.3.11", + "3.3.11.1", + "3.3.11.4", + "3.3.11.5" + ], + "AST-10": [ + "3.3.1.3.e.2" ], "AST-16": [ - "2-6-1", - "2-6-2" + "3.3.10.4", + "3.3.10.4.a", + "3.3.10.4.b", + "3.3.10.4.c", + "3.3.10.4.d", + "3.3.10.4.e" ], - "BCD-01": [ - "2-4-4", - "2-9-1", - "2-9-2", - "2-9-3", - "2-9-3-1", - "2-9-4", - "3-1-1", - "3-1-2", - "3-1-3", - "3-1-3-1", - "3-1-3-2", - "3-1-3-3", - "3-1-4" + "CHG-01": [ + "3.3.7", + "3.3.7.1", + "3.3.7.4" ], - "BCD-01.1": [ - "3-1-3-2" + "CHG-02": [ + "3.3.7.4.c", + "3.3.7.4.d", + "3.3.7.4.e", + "3.3.7.4.i" ], - "BCD-01.2": [ - "3-1-3-2" + "CHG-02.2": [ + "3.3.7.4.b" ], - "BCD-01.4": [ - "2-9-3-2" + "CHG-03": [ + "3.3.7.4.a" ], - "BCD-02": [ - "2-9-3-2" + "CHG-06": [ + "3.3.7.4.f" ], - "BCD-02.1": [ - "2-9-3-2" + "CHG-07": [ + "3.3.7.4.h" ], - "BCD-02.2": [ - "2-9-3-2" + "CLD-01": [ + "3.4.3", + "3.4.3.1", + "3.4.3.3", + "3.4.3.4", + "3.4.3.4.a", + "3.4.3.4.a.1", + "3.4.3.4.a.2", + "3.4.3.4.a.3", + "3.4.3.4.b", + "3.4.3.4.b.1", + "3.4.3.4.c", + "3.4.3.4.c.1", + "3.4.3.4.d", + "3.4.3.4.d.1", + "3.4.3.4.e", + "3.4.3.4.e.1", + "3.4.3.4.f", + "3.4.3.4.f.1", + "3.4.3.4.g", + "3.4.3.4.g.1", + "3.4.3.4.g.2", + "3.4.3.4.g.3" ], - "BCD-02.3": [ - "2-9-3-2" + "CLD-01.2": [ + "3.4.3.4.h", + "3.4.3.4.h.1", + "3.4.3.4.h.2", + "3.4.3.4.h.3" ], - "BCD-06": [ - "3-1-4" + "CPL-01": [ + "3.2.2", + "3.2.2.1", + "3.2.2.1.a", + "3.2.2.1.b", + "3.2.2.1.c" ], - "BCD-11": [ - "2-9-3" + "CPL-02": [ + "3.2.5" ], - "BCD-11.1": [ - "2-9-3-3" + "CPL-02.1": [ + "3.2.5.1" ], - "BCD-12": [ - "2-4-3-3" + "CPL-02.2": [ + "3.2.5.2" ], - "BCD-12.1": [ - "2-4-3-3" + "CPL-03": [ + "3.2.4", + "3.2.4.1", + "3.2.4.2", + "3.2.4.3", + "3.2.4.4", + "3.2.4.5", + "3.2.4.5.a", + "3.2.4.5.b", + "3.2.4.5.c", + "3.3.1.2", + "3.3.2.2", + "3.3.3.2", + "3.3.4.2", + "3.3.5.2", + "3.3.5.3", + "3.3.6.2", + "3.3.6.3", + "3.3.7.2", + "3.3.7.3", + "3.3.8.2", + "3.3.8.3", + "3.3.9.2", + "3.3.9.3", + "3.3.10.2", + "3.3.10.3", + "3.3.11.2", + "3.3.11.3", + "3.3.14.2", + "3.3.14.4.i", + "3.3.14.4.l", + "3.3.15", + "3.3.15.2", + "3.3.16", + "3.3.16.2", + "3.3.17.2", + "3.4.1.2", + "3.4.1.3", + "3.4.2", + "3.4.2.2", + "3.4.3.2" ], - "CHG-01": [ - "1-6-2" + "CFG-02": [ + "3.3.6", + "3.3.6.1", + "3.3.13.4.c.2" ], - "CHG-02": [ - "1-6-3-5" + "MON-01": [ + "3.3.14", + "3.3.14.1", + "3.3.14.3", + "3.3.14.4", + "3.3.14.4.a", + "3.3.14.4.b", + "3.3.14.4.c", + "3.3.14.4.d", + "3.3.14.4.e", + "3.3.14.4.f", + "3.3.14.4.g" ], - "CHG-02.2": [ - "1-6-2-1", - "1-6-3-5" + "MON-01.2": [ + "3.3.14.4.j", + "3.3.14.4.k" ], - "CHG-02.3": [ - "1-6-2-2" + "MON-03": [ + "3.3.14.3.a" ], - "CLD-01": [ - "4-2-1", - "4-2-2", - "4-2-3", - "4-2-3-2", - "4-2-4" + "MON-08": [ + "3.3.14.4.h" ], - "CLD-02": [ - "4-2-3-2" + "CRY-01": [ + "3.3.9", + "3.3.9.1", + "3.3.9.4", + "3.3.9.4.a", + "3.3.9.4.b", + "3.3.9.4.c" ], - "CLD-09": [ - "4-1-3-2", - "4-2-3-3" + "HRS-01": [ + "3.3.1", + "3.3.1.1", + "3.3.1.3" ], - "CPL-01": [ - "1-7-1", - "1-7-2" + "HRS-01.1": [ + "3.3.1.3.e.1", + "3.3.1.3.e.2" ], - "CPL-02": [ - "1-3-2" + "HRS-03": [ + "3.1.4.6", + "3.1.4.6.a", + "3.3.1.3.a" ], - "CPL-02.1": [ - "1-8-1", - "1-8-3" + "HRS-04": [ + "3.3.1.3.d" ], - "CPL-03": [ - "1-3-2", - "1-8-1" + "HRS-04.1": [ + "3.3.1.3.d" ], - "CPL-03.1": [ - "1-8-2" + "HRS-04.2": [ + "3.3.1.3.b" ], - "CPL-03.2": [ - "1-8-1" + "HRS-05.7": [ + "3.3.1.3.b" ], - "CFG-01": [ - "1-6-2-2", - "2-4-4", - "2-5-4" + "HRS-06.1": [ + "3.3.1.3.a" ], - "CFG-02": [ - "1-3-3", - "2-4-1", - "2-4-2", - "5-1-3-7" + "HRS-06.2": [ + "3.3.1.3.e" ], - "CFG-02.1": [ - "1-6-2-2" + "HRS-07": [ + "3.3.1.3.c" ], - "CFG-02.5": [ - "5-1-3-7" + "IAC-01": [ + "3.3.5.1" ], - "CFG-03": [ - "2-5-3-5" + "IAC-21": [ + "3.3.5" ], - "CFG-04.2": [ - "2-4-1", - "2-5-3-3" + "IRO-01": [ + "3.3.15.1" ], - "MON-01": [ - "2-3-4", - "2-12-1", - "2-12-2", - "2-12-3", - "2-12-4", - "5-1-3-3" + "IRO-02": [ + "3.3.15.3", + "3.3.15.4", + "3.3.15.4.a", + "3.3.15.4.b", + "3.3.15.4.c", + "3.3.15.4.d", + "3.3.15.4.e", + "3.3.15.4.f", + "3.3.15.4.g", + "3.3.15.4.h", + "3.3.15.4.i", + "3.3.15.4.j" ], - "MON-01.1": [ - "2-5-3-6" + "IRO-10.5": [ + "3.3.15.7", + "3.3.15.7.a", + "3.3.15.7.b", + "3.3.15.7.c", + "3.3.15.7.d", + "3.3.15.7.e", + "3.3.15.7.f", + "3.3.15.7.g", + "3.3.15.7.h", + "3.3.15.7.i", + "3.3.15.7.j", + "3.3.15.7.k" ], - "MON-01.2": [ - "2-12-3-3", - "5-1-3-3" + "IAO-02.2": [ + "3.3.7.4.b.1", + "3.3.7.4.b.2", + "3.3.7.4.b.3", + "3.3.7.4.b.4" ], - "MON-01.4": [ - "2-12-3-1" + "IAO-05": [ + "3.2.1.4-2.2" ], - "MON-01.8": [ - "2-12-3-4" + "MDM-01": [ + "3.3.10" ], - "MON-01.12": [ - "2-12-3-1" + "PES-01": [ + "3.3.2", + "3.3.2.1", + "3.3.2.3" ], - "MON-01.14": [ - "2-12-3-2" + "PES-03": [ + "3.3.2.3.a" ], - "MON-01.15": [ - "2-12-3-2" + "PES-04": [ + "3.3.2.3.c" ], - "MON-01.16": [ - "2-3-4", - "2-12-1", - "2-12-2", - "2-12-3", - "2-12-4", - "5-1-3-3" + "PES-05.1": [ + "3.3.2.3.b" ], - "MON-02.2": [ - "2-12-3-4" + "PES-07": [ + "3.3.2.3.d" ], - "MON-03.3": [ - "2-12-3-2" + "PES-10": [ + "3.3.2.3.e" ], - "MON-03.6": [ - "2-12-4" + "PES-12": [ + "3.3.2.3.e" ], - "MON-04": [ - "2-12-3-5" + "PRM-01": [ + "3.1.5.1" ], - "MON-07": [ - "2-3-3-4" + "PRM-01.1": [ + "3.1.2", + "3.1.2.1", + "3.1.2.2", + "3.1.2.2.a", + "3.1.2.2.b", + "3.1.2.2.c", + "3.1.2.3", + "3.1.2.3.a", + "3.1.2.3.b", + "3.1.2.3.c" ], - "MON-07.1": [ - "2-3-3-4" + "PRM-03": [ + "3.1.1.10" ], - "MON-08": [ - "2-12-3-5", - "2-14-3-3" + "PRM-04": [ + "3.1.5", + "3.1.5.1", + "3.1.5.2", + "3.1.5.2.a", + "3.1.5.2.b", + "3.1.5.2.c", + "3.1.5.2.d", + "3.1.5.2.e", + "3.1.5.2.f" ], - "MON-10": [ - "2-12-3-5", - "2-14-3-3" + "PRM-07": [ + "3.1.5" ], - "CRY-01": [ - "2-8-1", - "2-8-2", - "2-8-3", - "2-8-3-1", - "2-8-4" + "RSK-01": [ + "3.2.1", + "3.2.1.1-1", + "3.2.1.2-1", + "3.2.1.3-1", + "3.2.1.4-1", + "3.2.1.5", + "3.2.1.5.a", + "3.2.1.5.b", + "3.2.1.5.c", + "3.2.1.6", + "3.2.1.6.a", + "3.2.1.6.b", + "3.2.1.6.c", + "3.2.1.6.d", + "3.2.1.7", + "3.2.1.8", + "3.2.1.8.a", + "3.2.1.8.b", + "3.2.1.8.c", + "3.2.1.8.d" ], - "CRY-02": [ - "2-8-3-1" + "RSK-01.3": [ + "3.2.1.11" ], - "CRY-03": [ - "2-8-3-3" + "RSK-01.5": [ + "3.2.1.11" ], - "CRY-05": [ - "2-8-3-3" + "RSK-03": [ + "3.2.1.4-1.a", + "3.2.1.1-2", + "3.2.1.1-2.1", + "3.2.1.1-2.3" ], - "CRY-07": [ - "2-5-3-4" + "RSK-03.1": [ + "3.2.1.1-2.2" ], - "CRY-09": [ - "2-8-3-2" + "RSK-04": [ + "3.2.1.4-1.b", + "3.2.1.2-2", + "3.2.1.2-2.1", + "3.2.1.2-2.2" ], - "DCH-01": [ - "2-1-6", - "2-3-3", - "2-3-3-2", - "2-3-4", - "2-7-1", - "2-7-2", - "2-7-3", - "2-7-4", - "2-7-3-3" + "RSK-04.1": [ + "3.2.1.4-1.c", + "3.2.1.1-2.2" ], - "DCH-01.1": [ - "2-7-3-1" + "RSK-04.4": [ + "3.2.1.9" ], - "DCH-02": [ - "2-1-5", - "2-7-3-2", - "4-2-3-1" + "RSK-06": [ + "3.2.1.3-2", + "3.2.1.3-2.1" ], - "DCH-06": [ - "2-3-3-2" + "RSK-06.1": [ + "3.2.1.4-1.d" ], - "DCH-10": [ - "2-3-3-2" + "RSK-06.2": [ + "3.2.1.3-2.6", + "3.2.1.3-2.6.a", + "3.2.1.3-2.6.b", + "3.2.1.3-2.6.b.1", + "3.2.1.3-2.6.b.2", + "3.2.1.3-2.6.b.3", + "3.2.1.3-2.6.c", + "3.2.1.3-2.6.d" ], - "DCH-12": [ - "2-3-3-2" + "RSK-06.3": [ + "3.2.1.10", + "3.2.1.3-2.3", + "3.2.1.3-2.3.a", + "3.2.1.3-2.3.b", + "3.2.1.3-2.3.b.1", + "3.2.1.3-2.3.b.2", + "3.2.1.3-2.4", + "3.2.1.3-2.5", + "3.2.1.3-2.5.a", + "3.2.1.3-2.5.b", + "3.2.1.3-2.5.c" ], - "DCH-13": [ - "4-2-3-1" + "RSK-06.4": [ + "3.2.1.3-2.2", + "3.2.1.3-2.7", + "3.2.1.4-2", + "3.2.1.4-2.1", + "3.2.1.4-2.1.a", + "3.2.1.4-2.1.b", + "3.2.1.4-2.2" ], - "DCH-13.2": [ - "5-1-3-5" + "RSK-11": [ + "3.2.1.4-1.d" ], - "DCH-24": [ - "4-2-3-1" + "RSK-13": [ + "3.2.1.10" ], - "EMB-01": [ - "5-1-1", - "5-1-2", - "5-1-3", - "5-1-4" + "SEA-01.4": [ + "3.3.4", + "3.3.4.1", + "3.3.4.3", + "3.3.4.3.a", + "3.3.4.3.b", + "3.3.4.3.c", + "3.3.4.3.d", + "3.3.4.3.e" ], - "END-01": [ - "2-3-4", - "2-4-4" + "SAT-01": [ + "3.1.6", + "3.1.6.1", + "3.1.6.2", + "3.1.6.2.a", + "3.1.6.2.b", + "3.1.6.2.c", + "3.1.6.3", + "3.1.6.4", + "3.1.6.5", + "3.1.6.5.a", + "3.1.6.5.b", + "3.1.6.5.c" ], - "END-04": [ - "2-3-3-1", - "2-4-3-4", - "5-1-3-10" + "SAT-01.1": [ + "3.1.6.6", + "3.1.6.6.a", + "3.1.6.6.b" ], - "END-04.4": [ - "2-4-3-4" + "SAT-02": [ + "3.1.6.7", + "3.1.7", + "3.3.1.3.b" ], - "END-08": [ - "2-4-3-1" + "SAT-03": [ + "3.1.7.1", + "3.1.7.1.a", + "3.1.7.1.b", + "3.1.7.1.c", + "3.1.7.1.d", + "3.1.7.2" ], - "HRS-01": [ - "1-9-1", - "1-9-6", - "2-6-4" + "TDA-06": [ + "3.3.6.4", + "3.3.6.5", + "3.3.6.5.a", + "3.3.6.5.b", + "3.3.6.5.c", + "3.3.6.5.d", + "3.3.6.5.e", + "3.3.6.5.f", + "3.3.6.5.g" ], - "HRS-02": [ - "1-9-2" + "TDA-08": [ + "3.3.7.4.g" ], - "HRS-03.2": [ - "1-9-2" + "TPM-01": [ + "3.4.1", + "3.4.1.1", + "3.4.1.4", + "3.4.1.4.a", + "3.4.1.6", + "3.4.1.6.a", + "3.4.2.1" ], - "HRS-04": [ - "1-9-3", - "1-9-3-2" + "TPM-05": [ + "3.4.1.4.b", + "3.4.1.4.c", + "3.4.1.5", + "3.4.1.5.a", + "3.4.1.5.b", + "3.4.1.5.c", + "3.4.1.5.d", + "3.4.1.5.e", + "3.4.1.5.f", + "3.4.1.5.g" ], - "HRS-04.1": [ - "1-9-3-2" + "TPM-08": [ + "3.3.11.6" ], - "HRS-04.2": [ - "1-9-4", - "1-9-4-1" + "THR-01": [ + "3.3.16.1", + "3.3.16.3", + "3.3.16.3.a", + "3.3.16.3.c", + "3.3.16.3.d", + "3.3.16.3.e" ], - "HRS-05": [ - "1-9-3-1", - "1-9-3-2", - "1-9-4-2" + "THR-03": [ + "3.3.16.3.b" ], - "HRS-05.1": [ - "1-9-3-1", - "1-9-4-2", - "2-1-3", - "2-1-4", - "2-15-3-4" + "THR-03.1": [ + "3.3.16.3.f" ], - "HRS-05.2": [ - "1-9-4-2" + "VPM-01": [ + "3.3.17", + "3.3.17.1", + "3.3.17.3", + "3.3.17.3.a", + "3.3.17.3.b", + "3.3.17.3.c", + "3.3.17.3.d", + "3.3.17.3.e", + "3.3.17.3.f" + ] + }, + "emea-srb-act-9-2018": { + "CPL-01": [ + "IV.1.49" ], - "HRS-05.3": [ - "1-9-4-2", - "2-1-3", - "2-6-4", - "2-15-3-4" + "CPL-08": [ + "IV.1.44" ], - "HRS-05.4": [ - "1-9-4-2", - "2-1-3" + "DCH-23": [ + "IV.2.50(1)" ], - "HRS-05.5": [ - "1-9-4-2" + "IRO-10": [ + "IV.2.52", + "IV.2.52(1)", + "IV.2.52(2)", + "IV.2.52(3)", + "IV.2.52(4)", + "IV.2.53" ], - "HRS-06": [ - "1-9-3" + "PRI-01.4": [ + "IV.4.56", + "IV.4.56(1)", + "IV.4.56(2)", + "IV.4.56(3)", + "IV.4.57", + "IV.4.58", + "IV.4.58(1)", + "IV.4.58(2)", + "IV.4.58(3)", + "IV.4.58(4)" ], - "HRS-06.1": [ - "1-9-3-1" + "PRI-01.5": [ + "V.63", + "V.63(1)", + "V.63(2)", + "V.63(3)", + "V.63(4)", + "V.64", + "V.64(1)", + "V.64(2)", + "V.64(3)", + "V.65-1", + "V.65-1(1)", + "V.65-1(2)", + "V.65-1(3)", + "V.65-1(4)", + "V.65-1(5)", + "V.65-2", + "V.65-2(1)", + "V.65-2(2)", + "V.66", + "V.66(1)", + "V.66(2)", + "V.67-1", + "V.67-1(1)", + "V.67-1(2)", + "V.67-1(3)", + "V.67-2", + "V.67-2(1)", + "V.67-2(2)", + "V.67-2(3)", + "V.67-2(4)", + "V.67-2(5)", + "V.67-2(6)", + "V.67-2(7)", + "V.67-2(8)", + "V.67-2(9)", + "V.67-2(10)", + "V.67-2(11)", + "V.67-2(12)", + "V.67-2(13)", + "V.67-2(14)", + "V.68", + "V.69-1", + "V.69-1(1)", + "V.69-1(2)", + "V.69-1(3)", + "V.69-1(4)", + "V.69-1(5)", + "V.69-1(6)", + "V.69-1(7)", + "V.69-2", + "V.69-2(1)", + "V.69-2(2)", + "V.69-2(3)", + "V.69-2(4)", + "V.70", + "V.70(1)", + "V.70(2)", + "V.70(3)", + "V.70(4)", + "V.70(5)", + "V.71", + "V.71(1)", + "V.71(2)", + "V.71(3)", + "V.71(4)", + "V.71(5)", + "V.72", + "V.72(1)", + "V.72(2)", + "V.72(3)", + "V.72(4)" ], - "HRS-10": [ - "1-9-1" + "PRI-01.6": [ + "II.6(5)", + "II.8", + "IV.1.41", + "IV.1.42", + "IV.1.42(1)", + "IV.1.42(2)", + "IV.2.50", + "IV.2.50(2)", + "IV.2.50(3)", + "IV.2.50(4)", + "IV.2.51", + "IV.2.51(1)", + "IV.2.51(2)", + "IV.2.51(3)", + "IV.2.51(4)", + "IV.2.51(5)", + "IV.2.51(6)", + "IV.2.51(7)", + "IV.2.51(8)", + "IV.2.51(9)", + "IV.2.51(10)" ], - "IAC-01": [ - "2-2-1", - "2-2-2", - "2-2-4" + "PRI-01.11": [ + "II.5", + "II.5(1)", + "II.5(2)", + "II.5(3)", + "II.5(4)", + "II.5(5)", + "II.5(6)", + "II.6", + "II.12", + "III.1.21(1)", + "III.1.22(1)", + "III.2.24-4", + "III.2.24-4(1)", + "III.2.24-4(2)", + "III.2.24-4(3)", + "III.2.24-4(4)", + "III.2.25-1", + "III.2.25-1(1)", + "III.2.25-1(2)", + "III.2.25-1(3)", + "III.2.25-1(4)", + "III.2.25-1(5)", + "III.2.25-2", + "III.2.25-2(1)", + "III.2.25-2(2)", + "III.2.25-2(3)", + "III.2.25-2(4)", + "III.2.25-3", + "III.2.25-3(1)", + "III.2.25-3(2)", + "III.2.25-3(3)", + "III.2.25-3(4)", + "III.2.25-3(5)", + "III.2.28", + "III.2.28(1)", + "III.2.28(2)", + "III.2.28(3)", + "III.2.28(4)", + "III.2.28(5)", + "III.3.31(1)", + "III.3.31(2)", + "III.3.31(3)", + "III.3.31(4)", + "III.3.32(1)", + "III.3.32(2)", + "III.3.34(1)", + "III.3.34(2)", + "III.3.34(3)", + "III.3.34(4)", + "III.3.34(5)", + "III.4.38(1)", + "III.4.38(2)", + "III.4.38(3)" ], - "IAC-02": [ - "2-2-3" + "PRI-02": [ + "III.1.21", + "III.2.23-1", + "III.2.23-1(1)", + "III.2.23-1(2)", + "III.2.23-1(3)", + "III.2.23-1(4)", + "III.2.23-1(5)", + "III.2.23-1(6)", + "III.2.23-2", + "III.2.23-2(1)", + "III.2.23-2(2)", + "III.2.23-2(3)", + "III.2.23-2(4)", + "III.2.23-2(5)", + "III.2.23-2(6)", + "III.2.24-1", + "III.2.24-1(1)", + "III.2.24-1(2)", + "III.2.24-1(3)", + "III.2.24-1(4)", + "III.2.24-1(5)", + "III.2.24-1(6)", + "III.2.24-2", + "III.2.24-2(1)", + "III.2.24-2(2)", + "III.2.24-2(3)", + "III.2.24-2(4)", + "III.2.24-2(5)", + "III.2.24-2(6)", + "III.2.24-2(7)", + "III.2.24-3", + "III.2.24-3(1)", + "III.2.24-3(2)", + "III.2.24-3(3)" ], - "IAC-03": [ - "2-2-3" + "PRI-03": [ + "II.15", + "III.3.31" ], - "IAC-05": [ - "2-2-3" + "PRI-03.3": [ + "II.16" ], - "IAC-06": [ - "2-2-3-2", - "2-4-3-2", - "2-15-3-5" + "PRI-03.4": [ + "III.3.30-1(2)", + "III.4.37" ], - "IAC-08": [ - "2-2-3-3" + "PRI-04.1": [ + "II.14" ], - "IAC-09.1": [ - "2-2-3-1" + "PRI-05": [ + "II.8", + "III.3.30-1(1)" ], - "IAC-10": [ - "2-2-3-1" + "PRI-05.2": [ + "II.11" ], - "IAC-10.1": [ - "2-2-3-1" + "PRI-05.4": [ + "II.6(1)", + "II.6(2)", + "II.6(3)", + "II.6(4)", + "II.6(5)", + "II.7", + "II.7(1)", + "II.7(2)", + "II.12", + "II.12(1)", + "II.12(2)", + "II.12(3)", + "II.12(4)", + "II.12(5)", + "II.12(6)", + "II.13", + "II.17", + "II.17(1)", + "II.17(2)", + "II.17(3)", + "II.17(4)", + "II.17(5)", + "II.17(6)", + "II.17(7)", + "II.17(8)", + "II.17(9)", + "II.17(10)", + "II.18", + "II.18(1)", + "II.18(2)", + "II.18(3)", + "II.19", + "II.20", + "IV.1.46", + "IV.1.47-1", + "IV.1.47-1(1)", + "IV.1.47-1(2)", + "IV.1.47-1(3)", + "IV.1.47-1(4)", + "IV.1.47-1(5)", + "IV.1.47-1(6)", + "IV.1.47-1(7)" ], - "IAC-16": [ - "2-2-3-4" + "PRI-06": [ + "III.2.26", + "III.2.26(1)", + "III.2.26(2)", + "III.2.26(3)", + "III.2.26(4)", + "III.2.26(5)", + "III.2.26(6)", + "III.2.26(7)", + "III.2.26(8)", + "III.2.27", + "III.2.27(1)", + "III.2.27(2)", + "III.2.27(3)", + "III.2.27(4)", + "III.2.27(5)", + "III.2.27(6)", + "III.2.27(7)" ], - "IAC-17": [ - "1-9-5", - "2-2-3-5" + "PRI-06.1": [ + "III.3.29" ], - "IRO-01": [ - "2-13-1", - "2-13-2", - "2-13-3", - "2-13-3-2", - "2-13-4" + "PRI-06.4": [ + "III.1.22", + "III.3.34" ], - "IRO-02": [ - "2-13-3-2" + "PRI-06.5": [ + "III.3.30-1", + "III.3.32" ], - "IRO-04": [ - "2-13-3-1", - "2-13-3-2" + "PRI-06.6": [ + "III.3.36" + ], + "PRI-07.1": [ + "IV.1.45-1", + "IV.1.45-1(1)", + "IV.1.45-1(2)", + "IV.1.45-1(3)", + "IV.1.45-1(4)", + "IV.1.45-1(5)", + "IV.1.45-1(6)", + "IV.1.45-1(7)", + "IV.1.45-1(8)", + "IV.1.45-2", + "IV.1.45-2(1)", + "IV.1.45-2(2)", + "IV.1.45-2(3)", + "IV.1.45-2(4)", + "IV.1.45-2(5)", + "IV.1.45-2(6)" + ], + "PRI-07.2": [ + "IV.1.43" + ], + "PRI-07.3": [ + "II.11" + ], + "PRI-07.5": [ + "III.1.21(2)", + "III.1.22(2)" + ], + "PRI-14": [ + "II.15", + "IV.1.47-2", + "IV.1.47-2(1)", + "IV.1.47-2(2)", + "IV.1.47-2(3)", + "IV.1.47-2(4)", + "IV.1.47-2(5)", + "IV.1.47-2(6)", + "IV.1.47-2(7)", + "IV.1.47-2(8)", + "IV.1.47-2(9)", + "IV.1.47-3", + "IV.1.47-3(1)", + "IV.1.47-3(2)", + "IV.1.47-3(3)", + "IV.1.47-3(4)", + "IV.1.47-4", + "IV.1.47-4(1)", + "IV.1.47-4(2)", + "IV.1.47-4(3)", + "IV.1.47-4(4)" ], + "PRI-14.2": [ + "III.3.33" + ], + "PRI-17": [ + "III.3.34" + ], + "PRI-19": [ + "III.4.39" + ], + "PRI-19.2": [ + "III.4.38" + ], + "RSK-10": [ + "IV.3.54-1", + "IV.3.54-1(1)", + "IV.3.54-1(2)", + "IV.3.54-1(3)", + "IV.3.54-2", + "IV.3.54-2(1)", + "IV.3.54-2(2)", + "IV.3.54-2(3)", + "IV.3.54-2(4)", + "IV.3.55-1", + "IV.3.55-1(1)", + "IV.3.55-1(2)", + "IV.3.55-2", + "IV.3.55-2(1)", + "IV.3.55-2(2)", + "IV.3.55-2(3)", + "IV.3.55-2(4)", + "IV.3.55-2(5)", + "IV.3.55-2(6)" + ] + }, + "emea-zaf-popia-2013": { "IRO-10": [ - "2-13-3-3", - "2-13-3-4" + "3.A.7.22(1)", + "3.A.7.22(1)(a)", + "3.A.7.22(1)(b)", + "3.A.7.22(2)", + "3.A.7.22(3)", + "3.A.7.22(4)", + "3.A.7.22(4)(a)", + "3.A.7.22(4)(b)", + "3.A.7.22(4)(c)", + "3.A.7.22(4)(d)", + "3.A.7.22(4)(e)", + "3.A.7.22(5)", + "3.A.7.22(5)(a)", + "3.A.7.22(5)(b)", + "3.A.7.22(5)(c)", + "3.A.7.22(5)(d)", + "3.A.7.22(6)" ], - "IRO-10.2": [ - "2-13-3-3", - "2-13-3-4" + "PRI-01.5": [ + "9.72(1)", + "9.72(1)(a)", + "9.72(1)(a)(i)", + "9.72(1)(a)(ii)", + "9.72(1)(b)", + "9.72(1)(c)", + "9.72(1)(d)", + "9.72(1)(e)", + "9.72(1)(e)(i)", + "9.72(1)(e)(ii)", + "9.72(2)", + "9.72(2)(a)", + "9.72(2)(b)" ], - "MDM-01": [ - "2-6-3", - "2-6-3-1", - "2-6-3-2", - "2-6-3-3", - "2-6-3-4", - "2-6-4", - "5-1-3-6" + "PRI-01.6": [ + "3.A.7.19(1)", + "3.A.7.19(1)(a)", + "3.A.7.19(1)(b)", + "3.A.7.19(2)", + "3.A.7.19(2)(a)", + "3.A.7.19(2)(b)", + "3.A.7.19(2)(c)", + "3.A.7.19(2)(d)", + "3.A.7.19(3)" ], - "MDM-02": [ - "2-6-3-2", - "5-1-3-6" + "PRI-01.11": [ + "2.5(1)", + "2.5(1)(a)", + "2.5(1)(a)(i)", + "2.5(1)(a)(ii)", + "2.5(1)(b)", + "2.5(1)(c)", + "2.5(1)(d)", + "2.5(1)(e)", + "2.5(1)(e)(i)", + "2.5(1)(e)(ii)", + "2.5(1)(f)", + "2.5(1)(g)", + "2.5(1)(h)", + "2.5(1)(i)", + "3.A.2.9(1)", + "3.A.2.9(1)(a)", + "3.A.2.9(1)(b)", + "3.A.2.10", + "3.A.2.11(2)(a)", + "3.A.2.12(2)", + "3.A.2.12(2)(a)", + "3.A.2.12(2)(b)", + "3.A.2.12(2)(c)", + "3.A.2.12(2)(d)", + "3.A.2.12(2)(d)(i)", + "3.A.2.12(2)(d)(ii)", + "3.A.2.12(2)(d)(iii)", + "3.A.2.12(2)(d)(iv)", + "3.A.2.12(2)(d)(v)", + "3.A.2.12(2)(e)", + "3.A.2.12(2)(f)", + "3.A.6.17", + "3.A.6.18(1)", + "3.A.6.18(1)(a)", + "3.A.6.18(1)(b)", + "3.A.6.18(1)(c)", + "3.A.6.18(1)(d)", + "3.A.6.18(1)(e)", + "3.A.6.18(1)(f)", + "3.A.6.18(1)(g)", + "3.A.6.18(1)(h)", + "3.A.6.18(1)(h)(i)", + "3.A.6.18(1)(h)(ii)", + "3.A.6.18(1)(h)(iii)", + "3.A.6.18(1)(h)(iv)", + "3.A.6.18(1)(h)(v)", + "3.A.6.18(2)", + "3.A.6.18(2)(a)", + "3.A.6.18(2)(b)", + "3.A.6.18(3)", + "3.A.6.18(4)", + "3.A.6.18(4)(a)", + "3.A.6.18(4)(b)", + "3.A.6.18(4)(c)", + "3.A.6.18(4)(c)(i)", + "3.A.6.18(4)(c)(ii)", + "3.A.6.18(4)(c)(iii)", + "3.A.6.18(4)(c)(iv)", + "3.A.6.18(4)(d)", + "3.A.6.18(4)(e)", + "3.A.6.18(4)(f)", + "3.A.6.18(4)(f)(i)", + "3.A.6.18(4)(f)(ii)", + "3.A.7.20(1)", + "3.A.7.20(1)(a)", + "3.A.7.20(1)(b)" ], - "MDM-03": [ - "2-6-3-1" + "PRI-02": [ + "3.A.3.13(1)", + "3.A.3.13(2)" ], - "MDM-05": [ - "2-6-3-3" + "PRI-03": [ + "6.57(1)", + "6.57(1)(a)", + "6.57(1)(a)(i)", + "6.57(1)(a)(ii)", + "6.57(1)(b)", + "6.57(1)(c)", + "6.57(1)(d)", + "6.57(2)", + "6.57(3)", + "6.57(4)" ], - "MDM-06": [ - "5-1-3-6" + "PRI-03.3": [ + "3.C.34", + "3.C.35(1)", + "3.C.35(1)(a)", + "3.C.35(1)(b)", + "3.C.35(1)(c)", + "3.C.35(1)(d)", + "3.C.35(1)(d)(i)", + "3.C.35(1)(d)(ii)", + "3.C.35(1)(d)(iii)", + "3.C.35(1)(e)", + "3.C.35(2)", + "3.C.35(3)", + "3.C.35(3)(a)", + "3.C.35(3)(a)(i)", + "3.C.35(3)(a)(ii)", + "3.C.35(3)(b)", + "3.C.35(3)(b)(i)", + "3.C.35(3)(b)(ii)", + "3.C.35(3)(b)(iii)", + "3.C.35(3)(c)", + "3.C.35(3)(d)" ], - "MDM-07": [ - "5-1-3-6" + "PRI-03.4": [ + "3.A.2.11(2)(b)", + "3.A.2.11(3)", + "3.A.2.11(3)(a)", + "3.A.2.11(3)(b)", + "3.A.2.11(4)" ], - "NET-01": [ - "2-4-4", - "2-5-1", - "2-5-2", - "2-5-4" + "PRI-03.7": [ + "3.A.2.12(1)" ], - "NET-02": [ - "2-5-3-1" + "PRI-04.1": [ + "3.A.2.11(1)", + "3.A.2.11(1)(a)", + "3.A.2.11(1)(b)", + "3.A.2.11(1)(c)", + "3.A.2.11(1)(d)", + "3.A.2.11(1)(e)", + "3.A.2.11(1)(f)" ], - "NET-03.7": [ - "5-1-3-4" + "PRI-05": [ + "3.A.3.14(1)", + "3.A.3.14(1)(a)", + "3.A.3.14(1)(b)", + "3.A.3.14(1)(c)", + "3.A.3.14(1)(d)", + "3.A.3.14(2)", + "3.A.3.14(3)", + "3.A.3.14(3)(a)", + "3.A.3.14(3)(b)", + "3.A.3.14(4)", + "3.A.3.14(5)", + "3.A.3.14(6)", + "3.A.3.14(6)(a)", + "3.A.3.14(6)(b)", + "3.A.3.14(6)(c)", + "3.A.3.14(6)(d)", + "3.A.3.14(7)" ], - "NET-04": [ - "2-5-3-5" + "PRI-05.2": [ + "3.A.5.16(1)", + "3.A.5.16(2)" ], - "NET-05.1": [ - "5-1-3-2" + "PRI-05.4": [ + "3.A.4.15(1)", + "3.A.4.15(2)", + "3.A.4.15(2)(a)", + "3.A.4.15(2)(b)", + "3.A.4.15(2)(c)", + "3.A.4.15(2)(d)", + "3.A.4.15(2)(e)", + "3.A.4.15(3)", + "3.A.4.15(3)(a)", + "3.A.4.15(3)(b)", + "3.A.4.15(3)(c)", + "3.A.4.15(3)(c)(i)", + "3.A.4.15(3)(c)(ii)", + "3.A.4.15(3)(c)(iii)", + "3.A.4.15(3)(c)(iv)", + "3.A.4.15(3)(d)", + "3.A.4.15(3)(d)(i)", + "3.A.4.15(3)(d)(ii)", + "3.A.4.15(3)(e)", + "3.A.4.15(3)(f)", + "3.B.26(1)", + "3.B.26(1)(a)", + "3.B.26(1)(b)", + "3.B.26(1)(b)(i)", + "3.B.26(1)(b)(ii)", + "3.B.27(1)", + "3.B.27(1)(a)", + "3.B.27(1)(b)", + "3.B.27(1)(c)", + "3.B.27(1)(d)", + "3.B.27(1)(d)(i)", + "3.B.27(1)(d)(ii)", + "3.B.27(1)(e)", + "3.B.27(1)(f)", + "3.B.27(2)", + "3.B.27(3)" ], - "NET-05.2": [ - "5-1-3-1" + "PRI-06": [ + "3.A.8.23(1)", + "3.A.8.23(1)(a)", + "3.A.8.23(1)(b)", + "3.A.8.23(1)(b)(i)", + "3.A.8.23(1)(b)(ii)", + "3.A.8.23(1)(b)(iii)", + "3.A.8.23(1)(b)(iv)", + "3.A.8.23(2)", + "3.A.8.23(3)", + "3.A.8.23(3)(a)", + "3.A.8.23(3)(b)" ], - "NET-06": [ - "5-1-3-1", - "5-1-3-2" + "PRI-06.1": [ + "3.A.8.24(1)", + "3.A.8.24(1)(a)", + "3.A.8.24(1)(b)" ], - "NET-08": [ - "2-5-3-6" + "PRI-06.2": [ + "3.A.8.24(3)", + "3.A.8.24(4)" ], - "NET-10": [ - "2-4-3-5", - "2-5-3-7" + "PRI-06.4": [ + "3.A.8.23(4)(a)", + "3.A.8.23(4)(b)", + "3.A.8.23(5)", + "3.A.8.24(2)", + "3.A.8.24(2)(a)", + "3.A.8.24(2)(b)", + "3.A.8.24(2)(c)", + "3.A.8.24(2)(d)" ], - "NET-18": [ - "2-5-3-3", - "2-5-3-8" + "PRI-07.1": [ + "3.A.7.21(1)", + "3.A.7.21(2)" ], - "NET-18.1": [ - "2-5-3-8" + "PRI-17": [ + "3.A.3.14(8)" ], - "PES-01": [ - "2-3-1", - "2-3-2", - "2-3-4", - "2-14-1", - "2-14-2", - "2-14-3", - "2-14-4" + "PRI-18": [ + "3.A.3.14(8)" ], - "PES-02": [ - "2-14-3-1" + "PRI-19": [ + "8.71(1)", + "8.71(2)", + "8.71(2)(a)", + "8.71(2)(a)(i)", + "8.71(2)(a)(ii)", + "8.71(2)(b)", + "8.71(3)" ], - "PES-03": [ - "2-14-3-1" + "PRI-19.1": [ + "8.71(3)(b)" ], - "PES-03.1": [ - "2-14-3-1" + "PRI-19.2": [ + "8.71(3)(a)" + ] + }, + "emea-esp-decree-311-2022": { + "GOV-01": [ + "Article 8(1)", + "Article 8(2)", + "Article 8(5)", + "Article 9(1)", + "Article 9(1)(a)", + "Article 9(1)(b)", + "Article 9(2)", + "Article 10(1)", + "Article 10(2)", + "Article 10(3)", + "Article 12(6)(a)" ], - "PES-03.3": [ - "2-14-3-3" + "GOV-01.1": [ + "Article 12(1)(d)" ], - "PES-03.4": [ - "2-3-3-2" + "GOV-01.2": [ + "Article 31(6)" ], - "PES-04": [ - "2-14-3-5" + "GOV-01.3": [ + "Article 12(6)(ñ)", + "Article 27" ], - "PES-04.1": [ - "2-14-3-5" + "GOV-01.4": [ + "Article 12(1)(b)" ], - "PES-05": [ - "2-14-3-2" + "GOV-02": [ + "Article 11(3)", + "Article 12(1)", + "Article 12(6)" ], - "PES-05.1": [ - "2-14-3-2" + "GOV-04": [ + "Article 13(3)" ], - "PRI-06.6": [ - "4-2-3-1" + "GOV-04.1": [ + "Article 11(2)", + "Article 13(3)" ], - "PRM-01": [ - "1-1-3", - "1-2-3" + "GOV-08": [ + "Article 12(1)(a)" ], - "PRM-01.1": [ - "1-1-1", - "1-1-2" + "GOV-15": [ + "Article 13(2)(d)", + "Article 15(1)" ], - "PRM-02": [ - "1-1-3" + "GOV-15.1": [ + "Article 28(2)" ], - "PRM-03": [ - "1-6-4" + "GOV-19.3": [ + "Article 14(1)", + "Article 16(2)" ], - "PRM-04": [ - "1-6-1", - "1-6-4" + "AST-01.2": [ + "Article 11(1)", + "Article 11(2)" ], - "PRM-05": [ - "1-6-1" + "AST-04.1": [ + "Article 40(1)", + "Article 40(2)" ], - "RSK-01": [ - "1-5-1", - "1-5-2", - "1-5-4" + "BCD-01": [ + "Article 12(6)(n)", + "Article 22(2)" ], - "RSK-04": [ - "1-5-3" + "BCD-11": [ + "Article 26" ], - "RSK-07": [ - "1-5-3-2", - "1-5-4" + "CPL-01": [ + "Article 37" ], - "RSK-08": [ - "1-5-3-4" + "CPL-01.3": [ + "Article 38(1)" ], - "RSK-09": [ - "1-5-3-3" + "CPL-01.4": [ + "Article 31(1)", + "Article 31(2)", + "Article 31(3)", + "Article 31(4)", + "Article 31(5)", + "Article 31(7)" ], - "RSK-09.1": [ - "1-5-3-3" + "CPL-01.5": [ + "Article 38(2)" ], - "RSK-10": [ - "1-5-3-4" + "CPL-02": [ + "Article 16(1)" ], - "SEA-01": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" + "CPL-03": [ + "Article 15(1)" ], - "SEA-02": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" + "CFG-02": [ + "Article 12(7)", + "Article 20(a)", + "Article 20(c)", + "Article 20(d)", + "Single Transitional Provision(3)" ], - "SEA-03": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" + "CFG-02.2": [ + "Article 21(2)" ], - "SEA-05": [ - "4-2-3-1" + "CFG-03": [ + "Article 20(c)" ], - "SEA-08.1": [ - "1-6-3-2" + "MON-01": [ + "Article 8(3)", + "Article 12(6)(l)", + "Article 24(1)", + "Article 24(2)" ], - "SAT-01": [ - "1-10-1", - "1-10-5" + "MON-03": [ + "Article 20(b)" ], - "SAT-02": [ - "1-10-2", - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4" + "CRY-01": [ + "Article 12(6)(j)" ], - "SAT-02.2": [ - "1-10-3" + "DCH-01": [ + "Article 22(3)" ], - "SAT-03": [ - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4", - "1-10-4", - "1-10-4-1", - "1-10-4-2", - "1-10-4-3" + "DCH-01.2": [ + "Article 22(3)" ], - "SAT-03.3": [ - "1-10-4-2" + "DCH-02": [ + "Article 40(1)" ], - "SAT-03.5": [ - "1-10-4-1" + "DCH-13": [ + "Article 22(1)" ], - "TDA-01": [ - "1-6-3", - "2-5-4" + "DCH-13.2": [ + "Article 22(1)" ], - "TDA-02.1": [ - "2-5-3-5", - "2-15-3-3" + "END-02": [ + "Article 23" ], - "TDA-05": [ - "1-6-3-4" + "HRS-01": [ + "Article 12(6)(c)" ], - "TDA-06": [ - "1-6-3-1" + "HRS-02": [ + "Article 16(3)" ], - "TDA-08": [ - "2-5-3-2" + "HRS-03": [ + "Article 12(1)(c)", + "Article 13(2)" ], - "TDA-09": [ - "1-5-3-2", - "1-5-3-4", - "1-6-3-3" + "HRS-03.2": [ + "Article 16(2)" ], - "TDA-09.2": [ - "1-6-3-3" + "HRS-05": [ + "Article 12(6)(d)", + "Article 13(1)" ], - "TDA-09.3": [ - "1-6-3-3" + "HRS-05.1": [ + "Article 15(2)" ], - "TDA-09.4": [ - "1-6-3-3" + "HRS-05.7": [ + "Article 13(2)" ], - "TDA-09.5": [ - "1-6-3-3" + "IAC-01": [ + "Article 12(6)(e)", + "Article 24(3)" ], - "TDA-15": [ - "1-5-3-2", - "1-5-3-4" + "IAC-08": [ + "Article 17" ], - "TPM-01": [ - "1-5-3-3", - "4-1-1", - "4-1-2", - "4-1-3", - "4-1-4" + "IAC-21": [ + "Article 12(6)(h)", + "Article 20" ], - "TPM-04.1": [ - "1-5-3-4", - "4-1-3-1" + "IRO-01": [ + "Article 8(4)", + "Article 12(6)(m)", + "Article 25(1)" ], - "TPM-05": [ - "4-1-2", - "4-1-2-1", - "4-1-2-2", - "4-1-2-3" + "IRO-02": [ + "Article 25(2)", + "Article 34(1)(a)" ], - "TPM-09": [ - "4-1-2-3" + "IRO-10.5": [ + "Article 33(7)" ], - "TPM-11": [ - "4-1-2-2" + "IAO-01": [ + "Article 13(2)(c)", + "Article 21(1)" ], - "THR-01": [ - "2-10-4", - "2-13-1", - "2-13-2", - "2-13-3", - "2-13-4" + "IAO-03": [ + "Article 12(1)(e)", + "Article 15(2)" ], - "THR-03": [ - "2-10-3-5", - "2-13-3-5" + "IAO-07": [ + "Article 21(1)" ], - "VPM-01": [ - "2-3-4", - "2-10-1", - "2-10-2", - "2-10-3", - "2-10-4", - "2-11-1", - "2-11-2", - "2-11-3", - "2-11-4", - "5-1-3-8" + "MDM-01": [ + "Article 22(1)" ], - "VPM-01.1": [ - "2-11-3-1", - "5-1-3-8" + "NET-01": [ + "Article 12(6)(k)", + "Article 18" ], - "VPM-02": [ - "2-10-3-3", - "5-1-3-8" + "NET-05": [ + "Article 23" ], - "VPM-03": [ - "2-10-3-2" + "PES-01": [ + "Article 12(6)(f)" ], - "VPM-04": [ - "2-10-3-3" + "PRI-01.6": [ + "Article 5(a)", + "Article 5(b)", + "Article 5(c)", + "Article 5(d)", + "Article 5(e)", + "Article 5(f)", + "Article 5(g)" ], - "VPM-05": [ - "2-3-3-3", - "2-10-3-4", - "5-1-3-9" + "PRM-04": [ + "Article 16(1)" ], - "VPM-05.4": [ - "2-10-3-5" + "PRM-05": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], - "VPM-06": [ - "2-10-3-1" + "PRM-06": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], - "VPM-06.2": [ - "2-11-3-1" + "RSK-01": [ + "Article 7(2)", + "Article 12(6)(b)" ], - "VPM-07": [ - "2-11-3-1" + "RSK-01.1": [ + "Article 14(2)" ], - "WEB-01": [ - "2-15-1", - "2-15-2", - "2-15-3", - "2-15-4" + "RSK-04": [ + "Article 14(2)" ], - "WEB-03": [ - "2-15-3-1" + "RSK-06": [ + "Article 3(3)" + ], + "RSK-06.2": [ + "Article 28(3)" + ], + "RSK-06.4": [ + "Article 14(3)" + ], + "RSK-10": [ + "Article 3(2)", + "Article 12(1)(f)" + ], + "RSK-11": [ + "Article 14(1)" + ], + "SEA-02.2": [ + "Article 14(1)" + ], + "SAT-03": [ + "Article 6(2)", + "Article 15(1)", + "Article 16(3)" + ], + "TDA-01": [ + "Article 12(6)(g)", + "Article 19(1)" + ], + "TPM-05.4": [ + "Article 11(2)", + "Article 13(3)", + "Article 13(5)" + ], + "TPM-06": [ + "Article 13(5)" + ], + "VPM-01": [ + "Article 12(6)(i)" ] }, - "emea-sau-otcc-1-2022": { + "emea-esp-ccn-stic-825-2026": { "GOV-01": [ - "1-1" + "org.1", + "org.2", + "org.3" + ], + "GOV-01.2": [ + "op.mon.2" ], "GOV-02": [ - "1-1", - "1-1-1" + "org.1", + "org.2", + "org.3" ], "GOV-03": [ - "1-1-3" + "org.1", + "org.2", + "org.3" ], "GOV-04": [ - "1-2", - "1-2-1-2" - ], - "GOV-15": [ - "2-3", - "2-3-2" - ], - "GOV-15.1": [ - "2-3", - "2-3-2" - ], - "GOV-15.2": [ - "2-3", - "2-3-2" + "org.4" ], - "GOV-15.3": [ - "2-3", - "2-3-2" - ], - "GOV-15.4": [ - "2-3", - "2-3-2" + "GOV-05": [ + "op.mon.2" ], - "GOV-15.5": [ - "2-3", - "2-3-2" + "GOV-10": [ + "mp.info.2" ], "AST-01": [ - "2-1" + "op.cont.3" + ], + "AST-01.1": [ + "op.pl.2", + "op.exp.1", + "op.cont.3" ], "AST-01.2": [ - "2-1-1-4" + "op.pl.2", + "op.exp.1" ], "AST-02": [ - "2-1", - "2-1-1", - "2-1-1-3" - ], - "AST-02.1": [ - "2-1-1-1" - ], - "AST-02.2": [ - "2-3-1-11" + "op.pl.2", + "op.exp.1" ], "AST-02.8": [ - "2-4-1-16" + "op.pl.2", + "op.exp.1" ], "AST-02.9": [ - "2-1-1", - "2-1-1-2", - "2-1-1-3" + "op.exp.2", + "op.exp.3" + ], + "AST-03": [ + "op.pl.2", + "op.exp.1" + ], + "AST-03.1": [ + "op.pl.2", + "op.exp.1" + ], + "AST-03.2": [ + "op.ext.3" ], "AST-04": [ - "2-4-1-16" + "op.pl.2", + "op.exp.1", + "op.mon.1", + "mp.com.1" ], - "AST-04.2": [ - "2-4-1-16" + "AST-04.1": [ + "mp.info.2" ], - "AST-05": [ - "2-6-1-4" + "AST-06": [ + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" ], - "AST-09": [ - "2-6-1-3" + "AST-07": [ + "mp.eq.3", + "mp.eq.4" ], - "AST-30": [ - "2-6-1-3" + "AST-11": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "AST-12": [ + "mp.eq.3", + "mp.eq.4", + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "BCD-01": [ - "3-1", - "3-1-1", - "3-1-1-1", - "3-1-1-2", - "3-1-1-3", - "3-1-1-4", - "3-1-1-5", - "3-1-1-6", - "3-1-2" + "op.cont.1", + "op.cont.2", + "op.cont.3" ], - "BCD-02": [ - "2-1-1-5" + "BCD-01.1": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ], - "BCD-03.1": [ - "3-1-1-6" + "BCD-01.2": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ], "BCD-04": [ - "3-1-1-6" + "op.cont.1", + "op.cont.2", + "op.cont.3" + ], + "BCD-08": [ + "op.cont.4" + ], + "BCD-09": [ + "op.cont.4" ], "BCD-11": [ - "2-8", - "2-8-1", - "2-8-1-1", - "2-8-1-2", - "2-8-1-3", - "2-8-1-4", - "2-8-2" + "mp.info.6" + ], + "BCD-11.1": [ + "mp.info.6" ], "BCD-11.2": [ - "2-8-1-4" + "mp.info.6" ], "BCD-11.4": [ - "2-8-1-4" - ], - "BCD-11.6": [ - "2-8-1-4" + "mp.info.6" ], "BCD-11.7": [ - "3-1-1-2" + "op.cont.4" + ], + "CAP-01": [ + "op.pl.4", + "mp.s.4" + ], + "CAP-03": [ + "op.pl.4", + "mp.s.4" ], "CHG-01": [ - "1-5", - "1-5-1", - "1-5-2" + "op.exp.5" ], "CHG-02": [ - "1-5", - "1-5-1", - "1-5-2", - "1-5-3", - "1-5-3-1" - ], - "CHG-02.1": [ - "1-5-3-4" + "op.exp.5" ], "CHG-02.2": [ - "1-5-3-2" - ], - "CHG-02.3": [ - "1-5-2" - ], - "CHG-02.4": [ - "1-5-4" - ], - "CHG-03": [ - "1-5-2", - "1-5-4" + "op.exp.5" ], - "CHG-04": [ - "1-5-3-4" + "CLD-01": [ + "op.nub.1" ], - "CHG-04.1": [ - "1-5-4" + "CLD-04": [ + "mp.info.4", + "mp.s.2" ], - "CHG-04.3": [ - "2-2-1-6" + "CPL-01": [ + "op.mon.2" ], "CPL-01.1": [ - "1-6", - "1-6-1" + "op.mon.2" ], - "CPL-02": [ - "1-6", - "1-6-1" + "CPL-01.2": [ + "op.mon.2" ], "CPL-03": [ - "1-6", - "1-6-1", - "1-6-2" + "op.mon.2" ], - "CPL-03.1": [ - "1-6-1", - "1-6-2" + "CFG-01": [ + "op.exp.2", + "op.exp.3" + ], + "CFG-01.1": [ + "op.exp.2", + "op.exp.3" ], "CFG-02": [ - "2-2-1-5", - "2-3-1-1", - "2-3-1-7" + "op.acc.6", + "op.exp.2", + "op.exp.3", + "mp.sw.1", + "mp.info.4", + "mp.s.2" ], "CFG-02.1": [ - "2-3-1-2" - ], - "CFG-02.5": [ - "2-2-1-5", - "2-3-1-7" - ], - "CFG-02.8": [ - "2-3-1-11" + "op.exp.2", + "op.exp.3" ], - "CFG-02.9": [ - "2-3-1-7" + "CFG-02.4": [ + "mp.sw.1" ], "CFG-03": [ - "2-2-1-5", - "2-3-1-4" - ], - "CFG-03.2": [ - "2-3-1-11" - ], - "CFG-03.3": [ - "2-3-1-6" - ], - "CFG-05.1": [ - "2-3-1-11" + "op.exp.2", + "op.exp.3" ], "MON-01": [ - "2-11", - "2-11-1", - "2-11-2" - ], - "MON-01.7": [ - "1-5-4" + "op.exp.8" ], - "MON-01.16": [ - "2-11", - "2-11-1", - "2-11-2" + "MON-01.4": [ + "op.exp.8" ], "MON-02": [ - "2-11-1-3", - "2-11-1-9" + "op.exp.8" ], "MON-02.1": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" + "op.exp.8" ], "MON-02.2": [ - "2-11-1-9", - "2-11-2" + "op.exp.8" ], - "MON-02.3": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" + "MON-03": [ + "op.exp.8" ], - "MON-02.7": [ - "2-11-1-1", - "2-11-1-2", - "2-11-1-3" + "MON-03.3": [ + "op.exp.8" ], - "MON-05": [ - "2-11-1-2" + "MON-06": [ + "op.exp.8" ], "MON-08": [ - "2-3-1-10" + "op.exp.8" ], - "MON-16": [ - "2-3-1-12" + "MON-11": [ + "op.mon.3" ], - "MON-16.3": [ - "2-3-1-11", - "2-3-1-12" + "MON-11.3": [ + "op.mon.3" ], "CRY-01": [ - "2-2-1-4", - "2-7", - "2-7-1", - "2-7-2" + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" ], "CRY-03": [ - "2-2-1-4" + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.1", + "mp.s.2" ], "CRY-04": [ - "2-2-1-4" - ], - "CRY-05.1": [ - "2-3-1-8", - "2-3-1-9" + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" ], - "DCH-01": [ - "2-6", - "2-6-1", - "2-6-1-1", - "2-6-2" + "CRY-05": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], - "DCH-01.2": [ - "2-6-1-1" + "CRY-09": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], - "DCH-02": [ - "2-6-1-1" + "CRY-09.3": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], - "DCH-02.1": [ - "2-6-1-4" + "CRY-09.4": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], - "DCH-03.1": [ - "2-6-1-4" + "DCH-01": [ + "op.pl.2", + "op.exp.1", + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.info.2" ], - "DCH-07": [ - "2-6-1-4" + "DCH-02": [ + "op.pl.2", + "op.exp.1", + "mp.info.2" ], - "DCH-07.1": [ - "2-6-1-4" + "DCH-03": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "DCH-08": [ - "2-6-1-3" + "DCH-04": [ + "mp.si.1" ], - "DCH-09": [ - "2-6-1-3" + "DCH-06": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "DCH-13.2": [ - "2-3-1-8", - "2-3-1-9" + "DCH-07": [ + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.s.1" ], - "EMB-01": [ - "1-1-2", - "1-6", - "2-1-2", - "2-3-2" + "DCH-07.1": [ + "mp.s.1" ], - "EMB-05": [ - "1-5-4" + "DCH-07.2": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "EMB-06": [ - "1-5-2", - "1-5-3", - "1-5-4", - "2-3-1-5", - "2-3-1-6" + "DCH-08": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "EMB-07": [ - "1-5-4", - "2-2-1-4" + "DCH-10": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "EMB-10": [ - "1-6", - "1-6-1", - "1-6-2", - "2-1-2", - "2-3-2", - "2-7-2", - "2-9-2" + "DCH-10.1": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "EMB-13": [ - "2-2-1-4", - "2-2-1-7", - "2-4-1", - "2-4-1-1", - "2-4-1-2", - "2-4-1-3", - "2-4-1-4", - "2-4-1-5", - "2-4-1-6", - "2-4-1-7", - "2-4-1-8", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13", - "2-4-1-14", - "2-4-1-15", - "2-4-1-16" + "DCH-12": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "EMB-14": [ - "1-5-3-3", - "2-4-1-15" + "DCH-14": [ + "mp.s.1" ], - "EMB-19": [ - "3-1-1-5" + "DCH-17": [ + "mp.s.1" ], "END-01": [ - "2-5", - "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", - "2-5-1-4", - "2-5-1-5", - "2-5-2" + "op.acc.6", + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" ], - "END-04": [ - "2-3-1-8" + "END-02": [ + "op.acc.6", + "mp.eq.3", + "mp.eq.4" ], - "END-04.7": [ - "2-3-1-8" + "END-04": [ + "op.exp.6" ], - "END-06": [ - "1-5-4" + "END-04.1": [ + "op.exp.6" ], - "HRS-01": [ - "1-7", - "1-7-2", - "1-8" + "END-09": [ + "op.acc.6" ], "HRS-03": [ - "1-2", - "1-2-1", - "1-2-1-1" + "org.4" ], "HRS-04": [ - "1-7-1" + "op.pl.1", + "mp.per.1" ], "HRS-04.1": [ - "1-7-1" + "org.4", + "op.pl.1", + "mp.per.1" ], - "HRS-04.2": [ - "1-8" + "HRS-05": [ + "mp.s.1" ], - "IAC-01": [ - "2-2", - "2-2-1" + "HRS-05.1": [ + "mp.s.1" ], - "IAC-07.1": [ - "2-2-1-10" + "HRS-06": [ + "mp.s.1" ], - "IAC-07.2": [ - "2-2-1-10", - "2-2-1-11" + "HRS-06.1": [ + "mp.s.1" ], - "IAC-10": [ - "2-2-1-8" + "HRS-11": [ + "op.acc.3", + "op.acc.4", + "op.acc.5" ], - "IAC-10.1": [ - "2-2-1-8" + "HRS-12": [ + "op.acc.3" ], - "IAC-10.8": [ - "2-2-1-3" + "IAC-01": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], - "IAC-10.11": [ - "2-2-1-9" + "IAC-02": [ + "op.acc.2" ], - "IAC-15": [ - "2-2-1-10" + "IAC-03": [ + "op.acc.1" ], - "IAC-15.7": [ - "2-2-1-2" + "IAC-04": [ + "op.acc.1" ], - "IAC-17": [ - "2-2-1-10" + "IAC-05": [ + "op.acc.1" ], - "IAC-20.4": [ - "2-3-1-7" + "IAC-07": [ + "op.acc.1", + "op.acc.4", + "op.acc.5" ], - "IAC-21": [ - "2-3-1-4" + "IAC-07.1": [ + "op.acc.4", + "op.acc.5" ], - "IAC-24": [ - "2-2-1-4" + "IAC-07.2": [ + "op.acc.4", + "op.acc.5" ], - "IAC-25": [ - "2-2-1-4" + "IAC-08": [ + "op.acc.2" + ], + "IAC-09": [ + "op.acc.1" + ], + "IAC-09.1": [ + "op.acc.1" + ], + "IAC-09.4": [ + "op.acc.1" + ], + "IAC-10": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-10.11": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-15": [ + "op.acc.1", + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-15.1": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-15.2": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-15.3": [ + "op.acc.1" + ], + "IAC-15.5": [ + "op.acc.1" + ], + "IAC-16": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-16.1": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-17": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-19": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-20": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-20.1": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-20.2": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-20.3": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-21": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-21.3": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-22": [ + "mp.eq.3", + "mp.eq.4" ], "IRO-01": [ - "2-12", - "2-12-1", - "2-12-2" + "op.exp.7" ], "IRO-02": [ - "2-12-2-1", - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5", - "2-12-2-6", - "2-12-2-7", - "2-12-2-8" - ], - "IRO-03": [ - "2-3-1-12" + "op.exp.7", + "op.exp.9" ], "IRO-04": [ - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5" + "op.exp.7", + "op.exp.9" ], "IRO-05": [ - "2-12-2-6" + "op.cont.1", + "op.cont.2" ], "IRO-06": [ - "2-12-2-7" + "op.cont.3" ], "IRO-06.1": [ - "2-12-2-8" + "op.cont.1", + "op.cont.2" + ], + "IRO-07": [ + "op.exp.9" + ], + "IRO-08": [ + "op.exp.9" + ], + "IRO-11.2": [ + "op.cont.1", + "op.cont.2" + ], + "IRO-13": [ + "op.exp.7" ], "IAO-01": [ - "1-4-1-2" + "op.ext.3" ], - "IAO-05": [ - "1-3-1-6" + "IAO-02": [ + "op.ext.3", + "mp.sw.2" ], - "MNT-01": [ - "2-13-1-7" + "IAO-02.2": [ + "op.ext.3", + "mp.sw.2" ], - "MNT-05": [ - "2-2-1-7" + "IAO-04": [ + "mp.sw.1" ], - "MNT-06": [ - "2-13-1-7" + "MNT-01": [ + "op.exp.4" ], - "MNT-06.1": [ - "2-13-1-7" + "MNT-02": [ + "op.exp.4" + ], + "MNT-03": [ + "op.exp.4" ], "MDM-01": [ - "2-5", - "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", - "2-5-1-4", - "2-5-1-5", - "2-5-2" + "mp.eq.3", + "mp.eq.4" ], - "MDM-07": [ - "2-5-1-4" + "MDM-02": [ + "mp.eq.3", + "mp.eq.4" + ], + "MDM-05": [ + "mp.eq.3", + "mp.eq.4" ], "NET-01": [ - "2-3", - "2-3-1", - "2-3-1-1", - "2-4", - "2-4-1", - "2-4-2", - "2-5-2" + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3", + "mp.s.1" ], "NET-02": [ - "2-3-1-1" - ], - "NET-02.3": [ - "2-4-1-2" + "op.mon.1", + "mp.com.1" ], "NET-03": [ - "2-3-1-1", - "2-4-1-2", - "2-4-1-6" - ], - "NET-03.8": [ - "2-4-1-2" + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3" ], "NET-04": [ - "2-4-1-6", - "2-4-1-7", - "2-4-1-8", - "2-4-1-10", - "2-4-1-14", - "2-4-1-16" + "op.mon.1", + "mp.com.1", + "mp.s.1" ], "NET-04.1": [ - "2-4-1-6", - "2-4-1-8", - "2-4-1-14" - ], - "NET-05.1": [ - "2-3-1-13" - ], - "NET-05.2": [ - "2-3-1-13" + "op.mon.1", + "mp.com.1", + "mp.s.1" ], "NET-06": [ - "2-4-1-1", - "2-4-1-2", - "2-4-1-3", - "2-4-1-5", - "2-4-1-10" + "op.ext.4", + "op.mon.1", + "mp.com.1", + "mp.com.4" ], - "NET-06.3": [ - "2-4-1-1" + "NET-06.1": [ + "op.ext.4", + "mp.com.4" ], - "NET-06.4": [ - "2-2-1-1", - "2-4-1-3", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13" + "NET-08": [ + "mp.com.2", + "mp.com.3" ], - "NET-06.5": [ - "2-3-1-13", - "2-4-1-7" + "NET-08.1": [ + "op.mon.1", + "mp.com.1" ], - "NET-14": [ - "2-2-1-7" + "NET-13": [ + "mp.s.1" ], "NET-15": [ - "2-4-1-4", - "2-4-1-5" + "mp.com.2", + "mp.com.3" ], - "NET-17": [ - "2-6-1-2" + "NET-18": [ + "mp.s.1", + "mp.s.3" ], "PES-01": [ - "2-13", - "2-13-1", - "2-13-1-8", - "2-13-1-9", - "2-13-2" + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.s.1" ], "PES-02": [ - "2-13-1-1" + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" + ], + "PES-02.1": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "PES-03": [ - "2-13-1-3" + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" ], "PES-03.1": [ - "2-13-1-3" - ], - "PES-03.2": [ - "2-13-1-4" + "mp.if.1", + "mp.if.2", + "mp.if.7" ], - "PES-03.4": [ - "2-13-1-5" + "PES-03.3": [ + "mp.if.2", + "mp.if.7" ], "PES-04": [ - "2-13-1-4" + "op.acc.2", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.eq.1", + "mp.eq.2" ], "PES-04.1": [ - "2-13-1-5" - ], - "PES-05.1": [ - "2-13-1-2" + "op.acc.2", + "mp.if.2", + "mp.if.7" ], "PES-06": [ - "2-13-1-6" + "mp.if.2", + "mp.if.7" ], - "PES-06.3": [ - "2-13-1-7" + "PES-07": [ + "mp.if.4" ], - "PRM-02": [ - "1-4", - "1-4-1", - "1-4-1-1" + "PES-07.1": [ + "mp.if.4" + ], + "PES-07.2": [ + "mp.if.4" + ], + "PES-07.3": [ + "mp.if.4" + ], + "PES-07.4": [ + "mp.if.4" + ], + "PES-10": [ + "mp.if.2", + "mp.if.7" + ], + "PES-12": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" + ], + "PRI-01": [ + "org.1", + "org.2", + "mp.info.1" + ], + "PRI-01.3": [ + "org.1", + "org.2" + ], + "PRI-01.6": [ + "mp.info.1" + ], + "PRI-02": [ + "mp.info.1" + ], + "PRI-02.1": [ + "mp.info.1" + ], + "PRI-05.5": [ + "op.pl.2", + "op.exp.1" + ], + "PRM-01": [ + "op.pl.3" ], "PRM-04": [ - "1-4-1-2" + "op.pl.3" ], "PRM-05": [ - "1-4-1", - "1-4-1-1", - "1-4-2" + "op.pl.2", + "op.pl.3", + "op.exp.1", + "mp.info.4", + "mp.s.2" + ], + "PRM-07": [ + "op.pl.3", + "op.exp.5", + "mp.sw.1" ], "RSK-01": [ - "1-3", - "1-3-1", - "1-3-1-1" + "mp.if.3", + "mp.if.5", + "mp.if.6" ], "RSK-01.1": [ - "1-3-1-4", - "1-3-1-5" - ], - "RSK-02": [ - "1-3-1-4", - "1-3-1-5" + "op.pl.3" ], - "RSK-02.1": [ - "1-3-1-4", - "1-3-1-5" + "RSK-03": [ + "op.pl.3" ], "RSK-04": [ - "1-3-1-2" + "op.pl.3", + "mp.if.3", + "mp.if.5", + "mp.if.6" ], - "RSK-04.1": [ - "1-3-1-3", - "1-3-1-6" + "RSK-06": [ + "op.pl.3" ], - "RSK-06.2": [ - "1-3-1-6", - "1-3-1-7" + "RSK-06.1": [ + "op.pl.3" + ], + "RSK-08": [ + "op.cont.3" + ], + "RSK-09": [ + "op.ext.3" ], "SEA-01": [ - "1-1-2" + "mp.info.4", + "mp.s.2" ], "SEA-02": [ - "1-1-2" + "op.pl.3", + "mp.info.4", + "mp.s.2" ], - "SEA-03": [ - "1-1-2" + "SEA-17": [ + "op.acc.6" + ], + "OPS-01": [ + "org.3" + ], + "OPS-01.1": [ + "org.3" + ], + "OPS-03": [ + "org.3" ], "SAT-01": [ - "1-8" + "mp.per.3", + "mp.per.4" ], "SAT-02": [ - "1-8" + "mp.per.3", + "mp.per.4" ], "SAT-03": [ - "1-8-1", - "1-8-2", - "1-8-3" + "mp.per.3", + "mp.per.4" ], - "SAT-03.2": [ - "1-8-1", - "1-8-2", - "1-8-3", - "2-3-1-12" - ], - "SAT-03.5": [ - "1-8-1", - "1-8-2", - "1-8-3" + "TDA-01": [ + "mp.sw.1" ], - "SAT-03.6": [ - "1-8-1", - "1-8-2", - "1-8-3" + "TDA-02": [ + "mp.sw.1", + "mp.sw.2" ], - "TDA-01": [ - "1-1-2" + "TDA-02.3": [ + "mp.sw.1", + "mp.sw.2" ], - "TDA-01.1": [ - "1-1-2", - "4-1-1-1" + "TDA-06": [ + "mp.sw.1", + "mp.info.4", + "mp.s.2" ], - "TDA-04": [ - "1-1-2" + "TDA-06.1": [ + "mp.sw.2" ], "TDA-07": [ - "1-4-1-4" + "mp.sw.1" ], "TDA-08": [ - "1-4-1-4" + "mp.sw.1" ], "TDA-09": [ - "1-4-1-2" + "mp.sw.1", + "mp.sw.2" ], - "TDA-09.6": [ - "1-4-1-3" + "TDA-14": [ + "op.exp.5" ], "TPM-01": [ - "4-1", - "4-1-1", - "4-1-1-1", - "4-1-1-2", - "4-1-1-3", - "4-1-1-4", - "4-1-2" + "op.ext.1" + ], + "TPM-01.1": [ + "op.ext.1" ], "TPM-02": [ - "4-1-1-2" + "op.ext.1" + ], + "TPM-03": [ + "op.ext.1", + "op.ext.2", + "op.ext.3" + ], + "TPM-03.1": [ + "op.ext.2", + "op.ext.3" + ], + "TPM-03.2": [ + "op.ext.1" + ], + "TPM-03.3": [ + "op.ext.1", + "op.ext.2" ], "TPM-04": [ - "4-1-1-3" + "op.ext.1" ], "TPM-04.1": [ - "4-1-1-2", - "4-1-1-4" + "op.ext.1" ], - "TPM-05": [ - "4-1-1-1", - "4-1-1-3" + "TPM-04.3": [ + "op.ext.1" ], - "TPM-05.4": [ - "1-2-1-1" + "TPM-04.4": [ + "op.ext.3" ], - "TPM-08": [ - "4-1-1-4" + "TPM-05": [ + "op.ext.1", + "op.ext.3", + "mp.com.2", + "mp.com.3" ], - "THR-02": [ - "2-12-2-8" + "TPM-05.1": [ + "op.ext.3" ], - "THR-03": [ - "1-8-3", - "2-12-2-8" + "TPM-05.4": [ + "org.4" ], - "VPM-01": [ - "2-9", - "2-9-1", - "2-9-2" + "TPM-06": [ + "org.4", + "op.ext.1" ], - "VPM-01.1": [ - "2-9-1-1" + "TPM-08": [ + "op.ext.1", + "op.ext.2", + "mp.com.2", + "mp.com.3" ], - "VPM-02": [ - "2-9-1-2" + "TPM-09": [ + "op.ext.1" ], - "VPM-03": [ - "2-9-1-2", - "2-9-1-3" + "TPM-10": [ + "op.ext.2" ], - "VPM-04": [ - "2-9-1-2", - "2-9-1-3" + "TPM-11": [ + "op.ext.1" ], - "VPM-05": [ - "2-3-1-3", - "2-4-1-15" + "THR-01": [ + "op.mon.3" ], - "VPM-05.4": [ - "2-3-1-3" + "THR-02": [ + "op.mon.3" ], - "VPM-07": [ - "2-10", - "2-10-1", - "2-10-1-1", - "2-10-1-2", - "2-10-1-3", - "2-10-1-4", - "2-10-2" + "THR-03": [ + "op.mon.3" ], - "VPM-10": [ - "2-13-1-9" + "THR-03.1": [ + "op.mon.3" ], "WEB-02": [ - "2-4-1-10", - "2-4-1-13" + "op.ext.4", + "mp.com.4" ] }, - "emea-sau-pdpl-2023": { + "emea-che-fadp-2025": { "CPL-01": [ - "Article 2.1", - "Article 30.3" + "2.2.14.1.b", + "2.2.14.1.c", + "2.2.14.1.d" ], "CPL-01.2": [ - "Article 2.2" + "2.2.14.1.a" ], - "CPL-01.3": [ - "Article 30.4.a" + "CPL-05.2": [ + "2.2.15.2" ], - "DCH-03.1": [ - "Article 15.3", - "Article 15.4", - "Article 15.5", - "Article 15.6", - "Article 16.1", - "Article 16.2", - "Article 16.3", - "Article 16.4", - "Article 16.5", - "Article 16.6", - "Article 16.7", - "Article 16.8", - "Article 16.9" + "CPL-08": [ + "2.2.14.1", + "2.2.14.2", + "2.2.14.3" ], "DCH-18.1": [ - "Article 11.3" - ], - "DCH-22.1": [ - "Article 17.1" - ], - "DCH-22.3": [ - "Article 10" + "2.1.7.3" ], - "DCH-25": [ - "Article 29.1" - ], - "HRS-03": [ - "Article 30.2" + "END-13.3": [ + "2.1.7.3" ], - "IRO-04.1": [ - "Article 20.1", - "Article 20.2" + "HRS-05": [ + "5.30.1", + "5.30.2", + "5.30.2.a", + "5.30.2.b", + "5.30.2.c", + "5.30.3" ], - "PRI-01": [ - "Article 11.2" + "IRO-10": [ + "3.24.1", + "3.24.2", + "3.24.3", + "3.24.4", + "3.24.5", + "3.24.5.a", + "3.24.5.b", + "3.24.5.c", + "3.24.5bis", + "3.24.6" ], "PRI-01.4": [ - "Article 30.2" + "2.1.10.1", + "2.1.10.2", + "2.1.10.2.b" ], "PRI-01.5": [ - "Article 29.2.b" + "2.3.16.1", + "2.3.16.2", + "2.3.16.2.a", + "2.3.16.2.b", + "2.3.16.2.c", + "2.3.16.2.d", + "2.3.16.2.e", + "2.3.16.3" ], "PRI-01.6": [ - "Article 19" + "2.1.7.2", + "2.1.8.1", + "2.1.8.2" ], - "PRI-01.7": [ - "Article 23.1", - "Article 23.2", - "Article 29.2.c" + "PRI-01.11": [ + "2.1.6.1", + "2.1.6.2", + "2.1.7.1", + "4.25.6" ], "PRI-02": [ - "Article 4.1", - "Article 12", - "Article 13.2", - "Article 13.4", - "Article 13.5", - "Article 13.6" - ], - "PRI-02.1": [ - "Article 11.1", - "Article 13.2", - "Article 13.3" + "2.2.15.3", + "3.19.1", + "3.19.2", + "3.19.2.a", + "3.19.2.b", + "3.19.2.c", + "3.19.3", + "3.19.4", + "3.19.5", + "3.21.1" ], "PRI-03": [ - "Article 5.1", - "Article 10.1", - "Article 15.1", - "Article 24.1", - "Article 25.1", - "Article 25.2", - "Article 25.3", - "Article 26" - ], - "PRI-03.4": [ - "Article 5.2" - ], - "PRI-03.5": [ - "Article 7" - ], - "PRI-04.1": [ - "Article 13.1" - ], - "PRI-04.2": [ - "Article 10" + "2.1.6.6", + "2.1.6.7", + "2.1.6.7.a", + "2.1.6.7.b", + "2.1.6.7.c" ], - "PRI-04.4": [ - "Article 10", - "Article 14", - "Article 15.2" - ], - "PRI-04.5": [ - "Article 14" - ], - "PRI-04.7": [ - "Article 11.2" + "PRI-04": [ + "2.1.6.3" ], "PRI-05": [ - "Article 11.4", - "Article 18.1", - "Article 18.2.a", - "Article 18.2.b" + "2.1.6.4" ], "PRI-05.2": [ - "Article 14" - ], - "PRI-05.4": [ - "Article 11.3" + "2.1.6.5" ], "PRI-06": [ - "Article 4.2", - "Article 4.3", - "Article 4.4", - "Article 4.5", - "Article 21" + "3.21.2", + "4.25.1", + "4.25.2", + "4.25.2.a", + "4.25.2.b", + "4.25.2.c", + "4.25.2.d", + "4.25.2.e", + "4.25.2.f", + "4.25.2.g", + "4.25.3", + "4.25.4", + "4.25.5", + "4.28.1", + "4.28.1.a", + "4.28.1.b", + "4.28.2" ], - "PRI-07": [ - "Article 8" - ], - "PRI-12": [ - "Article 17.1" + "PRI-06.4": [ + "4.25.7", + "4.28.3" ], "PRI-14": [ - "Article 31", - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6" + "2.1.12.1", + "2.1.12.2", + "2.1.12.2.a", + "2.1.12.2.b", + "2.1.12.2.c", + "2.1.12.2.d", + "2.1.12.2.e", + "2.1.12.2.f", + "2.1.12.2.g", + "2.1.12.3", + "2.2.15.1" + ], + "PRI-19": [ + "3.21.3.a" ], - "PRI-14.2": [ - "Article 24.2" + "PRI-19.2": [ + "3.21.3.b" ], - "RSK-10": [ - "Article 22" + "PRI-19.3": [ + "3.21.3.a" ], - "TPM-05": [ - "Article 8" + "RSK-10": [ + "3.22.1", + "3.22.2", + "3.22.2.a", + "3.22.2.b", + "3.22.3", + "3.22.4", + "3.22.5", + "3.22.5.a", + "3.22.5.b", + "3.22.5.c" ], - "TPM-08": [ - "Article 8" + "SAT-03": [ + "2.1.10.2.a" ] }, - "emea-sau-sacs-002-2022": { - "GOV-01": [ - "TPC-25" + "emea-tur-lppd-2016": { + "PRI-01.5": [ + "9(1)", + "9(2)", + "9(3)", + "9(3)(a)", + "9(3)(b)", + "9(3)(c)", + "9(3)(ç)", + "9(3)(d)", + "9(3)(e)", + "9(4)", + "9(4)(a)", + "9(4)(b)", + "9(4)(c)", + "9(4)(ç)", + "9(5)", + "9(6)", + "9(6)(a)", + "9(6)(b)", + "9(6)(c)", + "9(6)(ç)", + "9(6)(d)", + "9(6)(e)", + "9(6)(f)", + "9(7)", + "9(8)", + "9(9)", + "9(10)", + "9(11)" ], - "GOV-02": [ - "TPC-25" + "PRI-01.6": [ + "12(1)", + "12(1)(a)", + "12(1)(b)", + "12(1)(c)", + "12(2)", + "12(3)", + "12(4)", + "12(5)" ], - "AST-09": [ - "TPC-19", - "TPC-66" + "PRI-02": [ + "10(1)", + "10(1)(a)", + "10(1)(b)", + "10(1)(c)", + "10(1)(ç)", + "10(1)(d)", + "11(1)", + "11(1)(a)", + "11(1)(b)", + "11(1)(c)", + "11(1)(ç)", + "11(1)(d)", + "11(1)(e)", + "11(1)(f)", + "11(1)(g)", + "11(1)(ğ)" ], - "AST-12": [ - "TPC-84" + "PRI-05.4": [ + "4(1)", + "4(2)", + "4(2)(a)", + "4(2)(b)", + "4(2)(c)", + "4(2)(ç)", + "4(2)(d)", + "5(1)", + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(2)(c)", + "5(2)(ç)", + "5(2)(d)", + "5(2)(e)", + "5(2)(f)", + "6(1)", + "6(2)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "6(3)(ç)", + "6(3)(d)", + "6(3)(e)", + "6(3)(f)", + "6(3)(g)", + "6(4)", + "7(1)", + "7(2)", + "7(3)" ], - "AST-13": [ - "TPC-84" + "PRI-06": [ + "13(1)", + "13(2)", + "13(3)" ], - "AST-19": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17" + "PRI-07": [ + "8(1)", + "8(2)", + "8(2)(a)", + "8(2)(b)", + "8(3)" ], - "AST-27": [ - "TPC-41" + "PRI-15": [ + "16(1)", + "16(2)", + "16(3)", + "16(3)(a)", + "16(3)(b)", + "16(3)(c)", + "16(3)(ç)", + "16(3)(d)", + "16(3)(e)", + "16(3)(f)", + "16(4)", + "16(5)" + ] + }, + "emea-uae-niaf-2023": { + "AST-02": [ + "3.1.1" ], "BCD-01": [ - "TPC-67", - "TPC-68", - "TPC-69" + "3.4", + "3.4.1", + "3.4.2", + "3.4.3" + ], + "BCD-01.5": [ + "3.4.2" ], "BCD-02": [ - "TPC-24" + "3.4" + ], + "BCD-02.1": [ + "3.4.3" ], "BCD-04": [ - "TPC-70" + "3.4.1" ], - "BCD-11": [ - "TPC-64" + "CFG-02": [ + "3.2.1" ], - "BCD-11.2": [ - "TPC-38" + "HRS-01": [ + "3.2.3" ], - "BCD-11.4": [ - "TPC-65" + "HRS-01.1": [ + "3.2.3" ], - "BCD-11.9": [ - "TPC-50" + "IRO-01": [ + "3.3", + "3.3.2" ], - "BCD-12.2": [ - "TPC-43" + "IRO-02": [ + "3.3.1", + "3.3.2" ], - "CHG-02": [ - "TPC-73" + "IRO-09": [ + "3.3.1" ], - "CHG-02.1": [ - "TPC-73" + "IRO-10": [ + "3.3.3" ], - "CHG-02.2": [ - "TPC-73" + "IRO-10.2": [ + "3.3.3" ], - "CLD-01": [ - "TPC-43" + "IAO-05": [ + "3.2" ], - "CLD-01.1": [ - "TPC-43" + "PES-01": [ + "3.2.2" ], - "CLD-09": [ - "TPC-30" + "PES-03": [ + "3.2.2" ], - "CPL-01": [ - "TPC-20", - "TPC-21", - "TPC-43" + "RSK-08": [ + "3.1.2" ], - "CPL-03.1": [ - "TPC-20", - "TPC-21" + "SEA-01": [ + "3.2.1" ], - "CFG-01": [ - "TPC-2" + "VPM-06": [ + "3.1.3" + ] + }, + "emea-gbr-caf-4-0": { + "GOV-01.1": [ + "A1.a", + "A1.c" ], - "CFG-02": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" + "GOV-02": [ + "A1", + "B1", + "B1.b" ], - "CFG-02.5": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" + "GOV-03": [ + "B1.a" ], - "MON-01": [ - "TPC-40", - "TPC-80" + "GOV-04": [ + "A1.b", + "A1.c" ], - "MON-01.3": [ - "TPC-40" + "GOV-04.1": [ + "A1.b" ], - "MON-01.4": [ - "TPC-80", - "TPC-87" + "GOV-04.2": [ + "A1.b" ], - "MON-01.8": [ - "TPC-40" + "GOV-15": [ + "B4.a" ], - "MON-01.15": [ - "TPC-83" + "GOV-15.1": [ + "B4.a" ], - "MON-01.16": [ - "TPC-40", - "TPC-80" + "GOV-15.2": [ + "B4.a" ], - "MON-02": [ - "TPC-81" + "GOV-19": [ + "A2.c" ], - "MON-02.1": [ - "TPC-81" + "AST-01": [ + "A3" ], - "MON-02.2": [ - "TPC-81" + "AST-01.1": [ + "A3", + "A3.a (point 2)" ], - "MON-10": [ - "TPC-75" + "AST-01.2": [ + "A3.a (point 4)" ], - "MON-16": [ - "TPC-80" + "AST-02": [ + "A3.a (point 1)" ], - "CRY-01": [ - "TPC-52", - "TPC-54" + "AST-03": [ + "A3.a (point 4)" ], - "CRY-03": [ - "TPC-52", - "TPC-53" + "AST-04": [ + "B3.a" ], - "CRY-07": [ - "TPC-42" + "BCD-01": [ + "B5.a" ], - "CRY-09": [ - "TPC-55" + "BCD-02": [ + "A3.a (point 3)" ], - "DCH-01": [ - "TPC-24", - "TPC-39", - "TPC-58" + "BCD-11": [ + "B5.c" ], - "DCH-01.1": [ - "TPC-39", - "TPC-58" + "CPL-01.4": [ + "A2.c" ], - "DCH-01.2": [ - "TPC-24", - "TPC-39", - "TPC-58" + "CFG-01": [ + "B4", + "B4.c" ], - "DCH-02": [ - "TPC-24" + "CFG-02": [ + "B4", + "B4.b" ], - "DCH-02.1": [ - "TPC-24" + "MON-01": [ + "C1" ], - "DCH-03": [ - "TPC-39" + "MON-01.4": [ + "C1.a", + "C1.c" ], - "DCH-03.1": [ - "TPC-39" + "MON-01.8": [ + "C1.a" ], - "DCH-09": [ - "TPC-19", - "TPC-66" + "MON-03": [ + "C1.a" ], - "DCH-19": [ - "TPC-30" + "MON-08": [ + "C1.b" ], - "DCH-25": [ - "TPC-30" + "MON-10": [ + "C1.b" ], - "END-01": [ - "TPC-12", - "TPC-22" + "MON-16": [ + "C1.f" ], - "END-02": [ - "TPC-22" + "MON-17": [ + "C1.d" ], - "END-04": [ - "TPC-12" + "CRY-03": [ + "B3.b" ], - "END-08": [ - "TPC-16" + "CRY-05": [ + "B3.c" ], - "HRS-01": [ - "TPC-6", - "TPC-71" + "DCH-01": [ + "B3" ], - "HRS-02": [ - "TPC-26" + "DCH-02": [ + "B3.a" ], - "HRS-03": [ - "TPC-26" + "DCH-06.2": [ + "B3.a" ], - "HRS-03.2": [ - "TPC-26" + "DCH-09": [ + "B3.e" ], - "HRS-04.1": [ - "TPC-26" + "DCH-14.3": [ + "B3.a" ], - "HRS-04.2": [ - "TPC-26", - "TPC-71" + "DCH-19": [ + "B3.a" ], - "HRS-05": [ - "TPC-26" + "END-01": [ + "B3.d" ], - "HRS-05.1": [ - "TPC-1", - "TPC-8", - "TPC-9" + "HRS-03.2": [ + "C1.e" ], - "HRS-05.3": [ - "TPC-8", - "TPC-9" + "IAC-01": [ + "B2", + "B2.d" ], - "HRS-05.7": [ - "TPC-26", - "TPC-71" + "IAC-02": [ + "B2.a" ], - "HRS-06": [ - "TPC-9", - "TPC-71" + "IAC-03": [ + "B2.a" ], - "HRS-06.1": [ - "TPC-9", - "TPC-71" + "IAC-04": [ + "B2.b" ], - "HRS-08": [ - "TPC-18" + "IAC-16": [ + "B2.c" ], - "HRS-09": [ - "TPC-6", - "TPC-18" + "IRO-01": [ + "D1" ], - "HRS-09.1": [ - "TPC-18" + "IRO-02": [ + "D1.b" ], - "HRS-09.2": [ - "TPC-6", - "TPC-18" + "IRO-03": [ + "C1.f" ], - "HRS-09.3": [ - "TPC-18" + "IRO-04": [ + "D1.a" ], - "HRS-09.4": [ - "TPC-6" + "IRO-06": [ + "D1.c" ], - "IAC-01": [ - "TPC-10" + "IRO-13": [ + "D2", + "D2.a", + "D2.b" ], - "IAC-02": [ - "TPC-32" + "MDM-01": [ + "B3.d" ], - "IAC-06": [ - "TPC-4", - "TPC-5", - "TPC-37", - "TPC-44", - "TPC-45" + "RSK-01": [ + "A2", + "A2.a" ], - "IAC-06.1": [ - "TPC-5", - "TPC-37" + "RSK-09": [ + "A4", + "A4.a" ], - "IAC-06.2": [ - "TPC-5", - "TPC-45" + "SEA-01": [ + "B4.a", + "B5.b" ], - "IAC-06.3": [ - "TPC-37" + "SEA-01.3": [ + "B5", + "B5.b" ], - "IAC-08": [ - "TPC-39" + "SEA-07.1": [ + "A3.a (point 5)" ], - "IAC-10": [ - "TPC-3" + "SAT-01": [ + "B6.a" ], - "IAC-10.1": [ - "TPC-2" + "SAT-02": [ + "B6" ], - "IAC-10.5": [ - "TPC-3" + "SAT-03": [ + "B6.b" ], - "IAC-10.6": [ - "TPC-62" + "TDA-06": [ + "A4.b" ], - "IAC-10.11": [ - "TPC-3" + "TPM-01": [ + "A4" ], - "IAC-16": [ - "TPC-34" + "THR-01": [ + "A2.b" ], - "IAC-16.1": [ - "TPC-34" + "THR-07": [ + "C2", + "C2.a (point 1)", + "C2.a (point 2)", + "C2.a (point 3)", + "C2.a (point 4)", + "C2.a (point 5)", + "C2.a (point 6)", + "C2.a (point 7)", + "C2.a (point 8)" ], - "IAC-17": [ - "TPC-33", - "TPC-34" + "THR-09": [ + "A2.b", + "C1.f" ], - "IAC-24": [ - "TPC-2" + "VPM-01": [ + "B4.d" + ] + }, + "emea-gbr-cap-1850-2020": { + "GOV-01": [ + "A1", + "B1" ], - "IAC-24.1": [ - "TPC-2" + "GOV-02": [ + "A1" ], - "IRO-01": [ - "TPC-23", - "TPC-88", - "TPC-89" + "GOV-15": [ + "B4" ], - "IRO-02": [ - "TPC-23", - "TPC-88", - "TPC-89" + "GOV-15.1": [ + "B4" ], - "IRO-04": [ - "TPC-23", - "TPC-88" + "GOV-15.2": [ + "B4" ], - "IRO-05": [ - "TPC-88" + "AST-01.1": [ + "A4" ], - "IRO-07": [ - "TPC-89" + "BCD-02": [ + "A4" ], - "IRO-08": [ - "TPC-89" + "MON-01": [ + "C1" ], - "IRO-09": [ - "TPC-89", - "TPC-90" + "CRY-01": [ + "B3" ], - "IRO-10": [ - "TPC-23", - "TPC-89" + "CRY-03": [ + "B3" ], - "IRO-10.2": [ - "TPC-23", - "TPC-89" + "CRY-05": [ + "B3" ], - "IRO-13": [ - "TPC-89" + "END-04": [ + "C2" ], - "IAO-01": [ - "TPC-51" + "IAC-01": [ + "B2" ], - "IAO-03.2": [ - "TPC-25" + "IAC-01.2": [ + "B2" ], - "IAO-07": [ - "TPC-51" + "IAC-15.1": [ + "B2" ], - "MNT-01": [ - "TPC-78" + "IRO-01": [ + "D1" ], - "MNT-02": [ - "TPC-78" + "IRO-02": [ + "D1" ], - "MNT-05": [ - "TPC-35" + "IRO-04.3": [ + "D2" ], - "MDM-02": [ - "TPC-84" + "IRO-13": [ + "D2" ], - "MDM-05": [ - "TPC-59" + "IAO-01": [ + "A2" ], - "MDM-06": [ - "TPC-84" + "IAO-01.1": [ + "A2" ], - "MDM-11": [ - "TPC-84" + "IAO-02": [ + "A2" ], - "NET-01": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-78" + "IAO-03": [ + "A2", + "A3", + "B1", + "B4" ], - "NET-02.1": [ - "TPC-92" + "IAO-03.2": [ + "A2", + "B1" ], - "NET-03": [ - "TPC-76" + "IAO-06": [ + "A2" ], - "NET-03.6": [ - "TPC-38" + "IAO-07": [ + "A2" ], - "NET-03.8": [ - "TPC-38", - "TPC-40" + "RSK-01": [ + "A2" ], - "NET-04.1": [ - "TPC-36" + "RSK-03": [ + "A2" ], - "NET-05.1": [ - "TPC-36" + "RSK-04": [ + "A2" ], - "NET-06": [ - "TPC-38", - "TPC-40" + "SEA-01.2": [ + "B5" ], - "NET-06.3": [ - "TPC-38", - "TPC-40" + "SEA-01.3": [ + "B5" ], - "NET-06.5": [ - "TPC-41" + "SAT-02": [ + "B6" ], - "NET-08": [ - "TPC-77" + "SAT-03": [ + "B6" ], - "NET-08.1": [ - "TPC-41" + "TPM-02": [ + "A4" ], - "NET-08.2": [ - "TPC-77" + "TPM-03": [ + "A4" ], - "NET-10.3": [ - "TPC-13", - "TPC-14", - "TPC-15" + "TPM-04.1": [ + "A4" + ] + }, + "emea-gbr-cyber-essentials-requirements-3-3": { + "AST-01": [ + "2" ], - "NET-14": [ - "TPC-35" + "AST-01.4": [ + "5-BP2-2" ], - "NET-14.4": [ - "TPC-35" + "AST-02.7": [ + "3-BP1" ], - "NET-14.6": [ - "TPC-35" + "CFG-02": [ + "2-BP3", + "2-BP4" ], - "NET-18": [ - "TPC-57" + "CFG-03": [ + "2-BP3" ], - "PES-01": [ - "TPC-46" + "CFG-03.3": [ + "5-BP2", + "5-BP2-1", + "5-BP2-2" ], - "PES-02": [ - "TPC-86" + "END-04": [ + "5", + "5-BP1" ], - "PES-02.1": [ - "TPC-86" + "END-04.1": [ + "5-BP1-1" ], - "PES-03": [ - "TPC-47", - "TPC-82", - "TPC-86" + "END-04.7": [ + "5-BP1-2", + "5-BP1-3" ], - "PES-03.1": [ - "TPC-82" + "END-05": [ + "1" ], - "PES-03.2": [ - "TPC-46" + "IAC-01": [ + "4" ], - "PES-03.4": [ - "TPC-46", - "TPC-49" + "IAC-01.2": [ + "2-BP5", + "4", + "4-BP2" ], - "PES-04": [ - "TPC-46" + "IAC-06": [ + "4-BP4" ], - "PES-04.1": [ - "TPC-49" + "IAC-07": [ + "4-BP6" ], - "PES-06": [ - "TPC-47" + "IAC-10.8": [ + "2-BP2" ], - "PES-06.1": [ - "TPC-47" + "IAC-15": [ + "2-BP1", + "4-BP1", + "4-BP3" ], - "PES-06.2": [ - "TPC-47" + "IAC-15.1": [ + "2-BP6" ], - "PES-06.3": [ - "TPC-48" + "IAC-15.3": [ + "4-BP3" ], - "PES-06.6": [ - "TPC-47" + "IAC-16": [ + "4-BP6" ], - "PES-18": [ - "TPC-38" + "IAC-16.4": [ + "4-BP5" ], - "PRI-07.1": [ - "TPC-25" + "IAC-17": [ + "2-BP1" ], - "PRM-04": [ - "TPC-74" + "IAC-21": [ + "2-BP1" ], - "PRM-05": [ - "TPC-43" + "NET-03": [ + "1" ], - "PRM-07": [ - "TPC-74" + "NET-18": [ + "5-BP1-4" ], - "RSK-01": [ - "TPC-31" + "TDA-17": [ + "3-BP2" ], - "RSK-03": [ - "TPC-31" + "VPM-05": [ + "3", + "3-BP4", + "3-BP4-1", + "3-BP4-2", + "3-BP4-3" ], - "RSK-04": [ - "TPC-31" + "VPM-05.4": [ + "3-BP3" + ] + }, + "emea-gbr-def-stan-05-138-2024": { + "GOV-01.1": [ + "1101", + "1103", + "1202" ], - "RSK-04.1": [ - "TPC-31" + "GOV-02": [ + "1100", + "1101", + "2100", + "2101" ], - "RSK-05": [ - "TPC-31" + "GOV-03": [ + "2100", + "2101" ], - "RSK-06": [ - "TPC-31" + "GOV-04": [ + "1102", + "1103" ], - "RSK-06.1": [ - "TPC-31" + "GOV-04.1": [ + "1101", + "1103" ], - "RSK-06.2": [ - "TPC-31" + "GOV-04.2": [ + "1103" ], - "RSK-07": [ - "TPC-31" + "AST-01": [ + "1300", + "1301", + "2202" ], - "SEA-01": [ - "TPC-43" + "AST-01.4": [ + "2410" ], - "SEA-02": [ - "TPC-43" + "AST-02": [ + "1301", + "2202", + "2310" ], - "SEA-03": [ - "TPC-43" + "AST-02.2": [ + "3204" ], - "SAT-01": [ - "TPC-7" + "AST-02.4": [ + "2202" ], - "SAT-02": [ - "TPC-7" + "AST-02.9": [ + "1301", + "2423" ], - "SAT-03": [ - "TPC-7" + "AST-04": [ + "1203", + "2301" ], - "TDA-06": [ - "TPC-60", - "TPC-62" + "AST-09": [ + "2323" ], - "TDA-07": [ - "TPC-73" + "AST-16": [ + "2322" ], - "TDA-08": [ - "TPC-73" + "AST-21": [ + "2412" ], - "TDA-09": [ - "TPC-72" + "BCD-01": [ + "2501", + "2502", + "4100" ], - "TDA-09.2": [ - "TPC-72" + "BCD-04": [ + "2503" ], - "TDA-09.3": [ - "TPC-72" + "BCD-11": [ + "2504", + "2505" ], - "TDA-09.4": [ - "TPC-72" + "BCD-11.1": [ + "2504", + "2505" ], - "TDA-09.5": [ - "TPC-72" + "BCD-11.2": [ + "2505" ], - "TDA-18": [ - "TPC-60" + "BCD-11.4": [ + "2506" ], - "TDA-19": [ - "TPC-61" + "BCD-11.5": [ + "2505" ], - "TPM-05": [ - "TPC-25" + "BCD-11.6": [ + "2506" ], - "TPM-05.2": [ - "TPC-25" + "BCD-12": [ + "4202" ], - "VPM-01": [ - "TPC-11" + "BCD-12.2": [ + "4202" ], - "VPM-01.1": [ - "TPC-27", - "TPC-28", - "TPC-29" + "CHG-01": [ + "2404" ], - "VPM-02": [ - "TPC-11", - "TPC-91" + "CHG-04": [ + "2422" ], - "VPM-05": [ - "TPC-11", - "TPC-78" + "CPL-01": [ + "0001", + "0002", + "2314" ], - "VPM-05.1": [ - "TPC-91" + "CPL-02": [ + "1206" ], - "VPM-05.3": [ - "TPC-91" + "CPL-02.2": [ + "1206" ], - "VPM-05.4": [ - "TPC-78" + "CPL-03.2": [ + "1206" ], - "VPM-06": [ - "TPC-85" + "CFG-02": [ + "2204", + "2310", + "2400", + "2401", + "2418" ], - "VPM-07": [ - "TPC-27", - "TPC-28", - "TPC-29" + "CFG-02.1": [ + "2418" ], - "WEB-02": [ - "TPC-41" + "CFG-02.2": [ + "2415" ], - "WEB-03": [ - "TPC-79" - ] - }, - "emea-sau-sama-csf-1-2017": { - "GOV-01": [ - "3.1.1" + "CFG-02.5": [ + "2312" ], - "GOV-01.1": [ - "3.1.1" + "CFG-02.9": [ + "2418" ], - "GOV-02": [ - "3.1.3" + "CFG-03": [ + "2204", + "2430", + "2507" ], - "GOV-04": [ - "3.1.4" + "CFG-03.1": [ + "2430", + "2507" ], - "AST-01": [ - "3.3.3" + "CFG-03.3": [ + "2409" ], - "AST-07": [ - "3.3.12" + "CFG-03.4": [ + "2305" ], - "AST-09": [ - "3.3.11" + "MON-01": [ + "2203", + "2427", + "3100", + "3101", + "3102", + "3106" ], - "AST-16": [ - "3.3.10" + "MON-01.2": [ + "3102" ], - "CHG-01": [ - "3.3.7" + "MON-01.4": [ + "3101" ], - "CLD-01": [ - "3.3.4", - "3.3.8", - "3.4.3" + "MON-01.8": [ + "3101", + "3102" ], - "CLD-02": [ - "3.3.4", - "3.3.8", - "3.4.3" + "MON-01.15": [ + "2203" ], - "CPL-01": [ - "3.2.2", - "3.2.3", - "3.3.13" + "MON-03": [ + "3104" ], - "CPL-02": [ - "3.2.4" + "MON-03.2": [ + "3107" ], - "CPL-02.1": [ - "3.2.5" + "MON-03.3": [ + "2216" ], - "CPL-03": [ - "3.2.4", - "3.2.5" + "MON-06": [ + "3108" ], - "MON-01": [ - "3.3.14" + "MON-07.1": [ + "2421" ], - "MON-01.2": [ - "3.3.14" + "MON-08": [ + "3103" ], - "MON-01.16": [ - "3.3.14" + "MON-10": [ + "3103", + "3107" ], - "MON-02": [ - "3.3.14" + "MON-16": [ + "3200", + "3202", + "3203" ], - "MON-02.1": [ - "3.3.14" + "MON-16.3": [ + "4106" ], - "CRY-01": [ - "3.3.9" + "MON-17": [ + "3109" ], - "DCH-08": [ - "3.3.11" + "MON-17.1": [ + "3101", + "3102" ], - "DCH-21": [ - "3.3.11" + "CRY-01": [ + "2304", + "2317", + "2318" ], - "HRS-01": [ - "3.3.1" + "CRY-03": [ + "2302", + "2306" ], - "HRS-03": [ - "3.1.4" + "CRY-05": [ + "2310", + "2317" ], - "IAC-01": [ - "3.3.5" + "CRY-09": [ + "2319" ], - "IRO-01": [ - "3.3.15" + "DCH-01": [ + "2300", + "2308" ], - "NET-01": [ - "3.3.4", - "3.3.8" + "DCH-01.2": [ + "2308" ], - "PES-01": [ - "3.3.2" + "DCH-01.4": [ + "2301" ], - "PRI-05": [ - "3.3.11" + "DCH-02": [ + "2301" ], - "PRM-01.1": [ - "3.1.2" + "DCH-03": [ + "2301" ], - "PRM-04": [ - "3.1.5" + "DCH-06": [ + "2308" ], - "RSK-01": [ - "3.2.1" + "DCH-07": [ + "2302", + "2506" ], - "RSK-03": [ - "3.2.1.1" + "DCH-07.2": [ + "2302" ], - "RSK-04": [ - "3.2.1.2" + "DCH-09": [ + "2313", + "2323" ], - "RSK-04.1": [ - "3.2.1.4" + "DCH-09.1": [ + "2323" ], - "RSK-05": [ - "3.2.1.2" + "DCH-10": [ + "2310" ], - "RSK-06.1": [ - "3.2.1.3" + "DCH-12": [ + "2310" ], - "SEA-01": [ - "3.3.4", - "3.3.8", - "3.3.13" + "DCH-15": [ + "2321" ], - "SEA-02": [ - "3.3.4", - "3.3.8", - "3.3.13" + "END-01": [ + "2317", + "2411" ], - "SEA-03": [ - "3.3.4", - "3.3.8", - "3.3.13" + "END-02": [ + "2411" ], - "SAT-01": [ - "3.1.6" + "END-04": [ + "2411", + "2426" ], - "SAT-03": [ - "3.1.6", - "3.1.7" + "END-04.1": [ + "2426" ], - "SAT-03.3": [ - "3.1.7" + "END-04.7": [ + "2426" ], - "TDA-01": [ - "3.3.6" + "END-06": [ + "2425" ], - "TPM-01": [ - "3.4.1", - "3.4.2" + "END-06.1": [ + "2425" ], - "TPM-03": [ - "3.4.2" + "END-08": [ + "2509" ], - "TPM-04.1": [ - "3.4.1", - "3.4.2" + "END-10": [ + "2413" ], - "THR-01": [ - "3.3.16" + "HRS-01": [ + "1300", + "2702" ], - "VPM-01": [ - "3.3.17" - ] - }, - "emea-srb-act-9-2018": { - "GOV-15": [ - "50", - "51" + "HRS-01.1": [ + "2702" ], - "GOV-15.1": [ - "50", - "51" + "HRS-03": [ + "1102", + "2321", + "3101", + "3102" ], - "GOV-15.2": [ - "50", - "51" + "HRS-03.1": [ + "2600", + "2603" ], - "GOV-15.3": [ - "50", - "51" + "HRS-04": [ + "2700", + "2701" ], - "GOV-15.5": [ - "50", - "51" + "HRS-05": [ + "2604" ], - "CPL-01": [ - "5.1", - "13", - "49", - "59" + "HRS-05.1": [ + "2604" ], - "DCH-01": [ - "65" + "HRS-05.2": [ + "2604" ], - "DCH-13.1": [ - "5.1" + "HRS-05.3": [ + "2604" ], - "DCH-14.2": [ - "64", - "64.1", - "64.2", - "64.3", - "64.4" + "HRS-05.5": [ + "2322" ], - "DCH-18": [ - "5.5" + "HRS-11": [ + "2207" ], - "DCH-18.2": [ - "5.1" + "HRS-14": [ + "2311" ], - "DCH-23": [ - "50.1" + "HRS-14.1": [ + "2311" ], - "DCH-25": [ - "23", - "63", - "63.1", - "63.2", - "63.3", - "63.4", - "65", - "68", - "69", - "69.x", - "70", - "70.1", - "70.2", - "70.3", - "70.4", - "70.5", - "71", - "71.1", - "71.2", - "71.3", - "71.4", - "71.5" + "HRS-15": [ + "2703" ], - "IRO-04.1": [ - "53", - "53.1", - "53.2", - "53.3" + "IAC-01": [ + "2200", + "2208", + "2210" ], - "IRO-10.2": [ - "52", - "52.1", - "52.2", - "52.3", - "52.4" + "IAC-01.1": [ + "1503" ], - "IAO-03.2": [ - "5", - "11" + "IAC-01.2": [ + "2200", + "2209", + "2210", + "2304" ], - "PRI-01": [ - "5.1", - "59", - "59.1", - "59.2", - "59.3", - "59.4", - "59.5", - "59.6", - "59.7", - "59.8", - "59.9", - "59.10", - "59.11" + "IAC-01.3": [ + "2217" ], - "PRI-01.4": [ - "44", - "44.1", - "44.2", - "56", - "56.1", - "56.2", - "56.3", - "57", - "58", - "58.1", - "58.2", - "58.3", - "58.4" + "IAC-02": [ + "2218" ], - "PRI-01.5": [ - "65", - "65.x", - "66", - "67", - "67.x" + "IAC-02.2": [ + "2215" ], - "PRI-01.6": [ - "5.6", - "41", - "42", - "42.1", - "42.2", - "50", - "50.1", - "50.2", - "50.3", - "50.4", - "51", - "51.1", - "51.2", - "51.3", - "51.4", - "51.5", - "51.6", - "51.7", - "51.8", - "51.9", - "51.10" + "IAC-06": [ + "2201", + "2305", + "2512" ], - "PRI-01.7": [ - "33" + "IAC-07": [ + "2702" ], - "PRI-02": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" + "IAC-08": [ + "2200", + "2206", + "2422" ], - "PRI-02.1": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" + "IAC-10.4": [ + "2213" ], - "PRI-02.2": [ - "38", - "38.1", - "38.2", - "38.3", - "39" + "IAC-10.8": [ + "2211" ], - "PRI-03": [ - "12.1", - "15", - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "IAC-10.11": [ + "2212" ], - "PRI-03.1": [ - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "IAC-11": [ + "2419", + "2420" ], - "PRI-03.3": [ - "37" + "IAC-15": [ + "2424" ], - "PRI-03.4": [ - "15", - "37" + "IAC-15.1": [ + "2209", + "2218" ], - "PRI-04": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "16" + "IAC-16": [ + "2424" ], - "PRI-04.1": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "7", - "7.1", - "7.2", - "14", - "20" + "IAC-16.1": [ + "2424" ], - "PRI-04.4": [ - "20" + "IAC-21": [ + "2205", + "2206" ], - "PRI-05": [ - "5.5", - "8" + "IAC-21.5": [ + "2216" ], - "PRI-05.1": [ - "5.1", - "5.3", - "7", - "7.1", - "7.2", - "20" + "IAC-22": [ + "2214" ], - "PRI-05.2": [ - "5.4" + "IAC-24": [ + "2408" ], - "PRI-05.4": [ - "5.1", - "5.3", - "17", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5", - "17.6", - "17.7", - "17.8", - "17.9", - "17.10", - "18.1", - "18.2", - "18.3", - "19" + "IRO-01": [ + "3105", + "4104" ], - "PRI-05.7": [ - "9", - "9.1", - "9.2", - "9.3", - "9.4", - "9.5", - "10", - "13" + "IRO-02": [ + "3105", + "4104" ], - "PRI-06": [ - "21", - "23", - "24", - "25", - "26", - "28.1", - "28.2", - "28.3", - "28.4", - "28.5" + "IRO-03": [ + "3201" ], - "PRI-06.1": [ - "5.4", - "11", - "29" + "IRO-04": [ + "4101", + "4102" ], - "PRI-06.2": [ - "34", - "34.1", - "34.2", - "34.3", - "34.4", - "34.5" + "IRO-06": [ + "4103", + "4105" ], - "PRI-06.4": [ - "21", - "21.1", - "21.2", - "22", - "22.1", - "22.2", - "23", - "23.x", - "24", - "24.x", - "25", - "25.x", - "26", - "26.1", - "26.2", - "26.3", - "26.4", - "26.5", - "26.6", - "26.7", - "26.8", - "27.1", - "27.2", - "27.3", - "27.4", - "27.5", - "27.6", - "27.7" + "IRO-08": [ + "3104" ], - "PRI-06.5": [ - "30", - "30.x", - "32", - "32.1", - "32.2" + "IRO-13": [ + "4200" ], - "PRI-06.6": [ - "21", - "22", - "36", - "36.1", - "36.2" + "IRO-15": [ + "2411" ], - "PRI-06.7": [ - "21", - "22" + "IAO-01": [ + "1205" ], - "PRI-07": [ - "5" + "IAO-02": [ + "1205" ], - "PRI-07.1": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "45", - "45.x", - "46" + "IAO-03": [ + "2301" ], - "PRI-07.2": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "43" + "IAO-06": [ + "1205" ], - "PRI-07.3": [ - "30", - "30.x", - "32", - "32.1", - "32.2", - "33" + "MNT-02": [ + "2511" ], - "PRI-07.4": [ - "21.2", - "22.2" + "MNT-03": [ + "2511" ], - "PRI-07.5": [ - "21.2", - "22.2" + "MNT-04.2": [ + "2510" ], - "PRI-10": [ - "5.4", - "11" + "MNT-05": [ + "2512" ], - "PRI-14": [ - "47", - "47.x", - "48", - "52", - "52.1", - "52.2", - "52.3", - "52.4" + "MNT-06.1": [ + "2513" ], - "PRI-14.1": [ - "33" + "MDM-01": [ + "2309", + "2322" ], - "PRI-14.2": [ - "33", - "35" + "MDM-03": [ + "2309" ], - "RSK-10": [ - "54", - "54.x" + "NET-03": [ + "2427" ], - "TPM-05": [ - "5", - "11" + "NET-03.4": [ + "2316" ], - "TPM-05.2": [ - "5", - "11" - ] - }, - "emea-zaf-popia-2013": { - "GOV-01": [ - "19", - "21" + "NET-04": [ + "2316", + "2428" ], - "AST-01": [ - "19.1", - "19.2" + "NET-04.1": [ + "2507" ], - "BCD-01": [ - "19.1", - "19.2" + "NET-06": [ + "2508" ], - "CAP-01": [ - "19.1", - "19.2" + "NET-07": [ + "2303", + "2411" ], - "CHG-01": [ - "19.1", - "19.2" + "NET-08": [ + "2411" ], - "CLD-01": [ - "19.1", - "19.2" + "NET-09": [ + "2414" ], - "CPL-01": [ - "2", - "3", - "9", - "19", - "21" + "NET-10": [ + "2315" ], - "CPL-02": [ - "8", - "19", - "21" + "NET-10.3": [ + "2315" ], - "CPL-03": [ - "8", - "19", - "21" + "NET-12": [ + "2305" ], - "CPL-03.1": [ - "60" + "NET-14": [ + "2305" ], - "MON-01": [ - "19.1", - "19.2" + "NET-14.2": [ + "2305", + "2306" ], - "MON-01.16": [ - "19.1", - "19.2" + "NET-14.3": [ + "2307" ], - "CRY-01": [ - "14.1", - "19.1", - "19.2" + "NET-14.4": [ + "2417" ], - "CRY-03": [ - "14.1" + "NET-14.5": [ + "2305" ], - "CRY-04": [ - "14.1" + "NET-15.1": [ + "2304" ], - "CRY-05": [ - "14.1" + "NET-17": [ + "2320" ], - "DCH-01": [ - "14.1", - "19", - "21" + "NET-18": [ + "2411" ], - "DCH-09.3": [ - "16.1" + "NET-20.4": [ + "2315" ], - "DCH-14": [ - "72" + "NET-20.7": [ + "2509" ], - "DCH-18": [ - "9" + "PES-01": [ + "1500" ], - "DCH-18.1": [ - "19" + "PES-02": [ + "1500" ], - "DCH-18.2": [ - "19" + "PES-02.1": [ + "1502", + "2422" ], - "DCH-22.1": [ - "24" + "PES-03": [ + "1500" ], - "DCH-24": [ - "19", - "21" + "PES-03.3": [ + "1500" ], - "DCH-24.1": [ - "19", - "21" + "PES-03.4": [ + "1502" ], - "DCH-25": [ - "72" + "PES-05": [ + "1500" ], - "EMB-01": [ - "19" + "PES-05.1": [ + "1500" ], - "EMB-02": [ - "19" + "PES-06.1": [ + "1503" ], - "EMB-03": [ - "19" + "PES-06.2": [ + "1503" ], - "END-01": [ - "19" + "PES-06.6": [ + "1503" ], - "END-13.1": [ - "8", - "9", - "13.1" + "PES-07.3": [ + "2704" ], - "END-13.2": [ - "18" + "PES-08.2": [ + "2704" ], - "END-13.3": [ - "10" + "PES-09": [ + "2704" ], - "HRS-01": [ - "19", - "20" + "PES-11": [ + "2312" ], - "HRS-04": [ - "19", - "20" + "PES-19": [ + "1501" ], - "IAC-01": [ - "19", - "20" + "PRI-02": [ + "2406", + "2407" ], - "IAC-09.6": [ - "6.1.b" + "RSK-01": [ + "1200", + "1201", + "1204" ], - "IRO-01": [ - "19.1", - "19.3", - "22" + "RSK-03": [ + "1200" ], - "IRO-04.1": [ - "22" + "RSK-04": [ + "1200", + "1202", + "1204" ], - "IRO-10": [ - "22" + "RSK-04.1": [ + "4201" ], - "IRO-11.2": [ - "21.2" + "RSK-06": [ + "1200" ], - "IAO-01": [ - "19", - "60" + "RSK-08": [ + "4201" ], - "MNT-01": [ - "19" + "RSK-09": [ + "1400" ], - "NET-01": [ - "19" + "RSK-09.1": [ + "1400" ], - "PES-01": [ - "19" + "RSK-12": [ + "2601" ], - "PRI-01": [ - "19", - "20", - "60" + "SEA-01": [ + "2400" ], - "PRI-01.1": [ - "55", - "56" + "SEA-01.2": [ + "2500", + "2501" ], - "PRI-01.4": [ - "17", - "55", - "56" + "SEA-05": [ + "2416" ], - "PRI-02": [ - "18" + "SEA-18": [ + "2406", + "2407" ], - "PRI-02.1": [ - "13", - "18" + "SEA-20": [ + "2421" ], - "PRI-02.2": [ - "5", - "71" + "OPS-01.1": [ + "1100", + "2100", + "2101" ], - "PRI-03": [ - "11" + "SAT-02": [ + "2600", + "2602", + "2603" ], - "PRI-03.1": [ - "11" + "SAT-02.1": [ + "2605" ], - "PRI-03.2": [ - "15" + "SAT-02.2": [ + "2602" ], - "PRI-04": [ - "5", - "11", - "69" + "SAT-03": [ + "2321", + "2602" ], - "PRI-04.1": [ - "2", - "3", - "4" + "SAT-03.1": [ + "2605" ], - "PRI-05": [ - "4", - "14", - "16" + "SAT-03.2": [ + "2602" ], - "PRI-05.1": [ - "10" + "SAT-03.3": [ + "2602" ], - "PRI-05.2": [ - "14", - "16" + "SAT-03.6": [ + "2601", + "2602", + "2603", + "3106" ], - "PRI-05.4": [ - "15", - "26" + "TPM-01": [ + "1400" ], - "PRI-06": [ - "23" + "TPM-03": [ + "1400" ], - "PRI-06.1": [ - "24" + "TPM-05": [ + "1401", + "2323" ], - "PRI-06.2": [ - "24" + "TPM-05.2": [ + "1401" ], - "PRI-06.3": [ - "63", - "74" + "THR-01": [ + "1204" ], - "PRI-07": [ - "18", - "28", - "30", - "31" + "THR-03": [ + "1204", + "3110" ], - "PRI-07.1": [ - "11", - "20", - "21" + "THR-03.1": [ + "1204", + "3110" ], - "PRI-08": [ - "19" + "VPM-01": [ + "2402", + "2405" ], - "PRI-09": [ - "17" + "VPM-02": [ + "2402" ], - "PRI-10": [ - "4" + "VPM-05": [ + "2402", + "2405" ], - "PRI-12": [ - "16" + "VPM-05.6": [ + "2405" ], - "PRI-14.1": [ - "17" + "VPM-05.7": [ + "2405" ], - "PRM-01": [ - "19" + "VPM-06": [ + "2402" ], - "RSK-01": [ - "19" + "VPM-07": [ + "2403" ], - "RSK-03": [ - "19" + "WEB-14": [ + "2321" + ] + }, + "emea-gbr-def-stan-05-138-l0-2024": { + "CPL-01": [ + "0001", + "2314" ], - "RSK-04": [ - "19" + "SEA-01.2": [ + "2500" + ] + }, + "emea-gbr-def-stan-05-138-l1-2024": { + "GOV-01.1": [ + "1202" ], - "RSK-04.1": [ - "19" + "GOV-02": [ + "1100", + "2100" ], - "RSK-05": [ - "19" + "GOV-03": [ + "2100" ], - "RSK-06": [ - "19" + "GOV-04": [ + "1102" ], - "RSK-06.1": [ - "19" + "AST-01": [ + "1300" ], - "RSK-06.2": [ - "19" + "AST-01.4": [ + "2410" ], - "RSK-07": [ - "19" + "AST-02": [ + "2310" ], - "RSK-08": [ - "19" + "AST-02.2": [ + "3204" ], - "RSK-10": [ - "19" + "AST-02.9": [ + "2423" ], - "RSK-11": [ - "4" + "AST-04": [ + "1203" ], - "SEA-01": [ - "19", - "21" + "AST-09": [ + "2323" ], - "SEA-01.1": [ - "8" + "AST-16": [ + "2322" ], - "SEA-02": [ - "19", - "21" + "AST-21": [ + "2412" ], - "SEA-03": [ - "19", - "21" + "BCD-01": [ + "2501", + "2502", + "4100" ], - "SEA-15": [ - "19", - "21" + "BCD-11": [ + "2504" ], - "OPS-01": [ - "19" + "BCD-11.1": [ + "2504" ], - "SAT-01": [ - "4.1.e" + "CHG-01": [ + "2404" ], - "TPM-01": [ - "20", - "21" + "CHG-04": [ + "2422" ], - "TPM-03": [ - "20" + "CPL-01": [ + "0001", + "2314" ], - "TPM-04": [ - "19" - ], - "TPM-04.1": [ - "19" - ], - "TPM-04.3": [ - "20", - "21" - ], - "TPM-04.4": [ - "19", - "21" + "CFG-02": [ + "2204", + "2310", + "2400", + "2401", + "2418" ], - "TPM-05": [ - "20" + "CFG-02.1": [ + "2418" ], - "VPM-01": [ - "19" + "CFG-02.5": [ + "2312" ], - "VPM-04.2": [ - "4" + "CFG-02.9": [ + "2418" ], - "WEB-04": [ - "19" - ] - }, - "emea-esp-boe-a-2022-7191": { - "GOV-01": [ - "Article 5", - "Article 6.1", - "Article 6.2", - "Article 13.1", - "Article 35.1" + "CFG-03": [ + "2204", + "2507" ], - "GOV-01.1": [ - "Article 5", - "Article 27" + "CFG-03.1": [ + "2507" ], - "GOV-02": [ - "Article 12.1", - "Article 12.1(a)", - "Article 12.1(b)", - "Article 12.1(c)", - "Article 12.1(d)", - "Article 12.1(e)", - "Article 12.1(f)", - "Article 12.2", - "Article 12.6", - "Article 12.6(a)", - "Article 12.6(b)", - "Article 12.6(c)", - "Article 12.6(d)", - "Article 12.6(e)", - "Article 12.6(f)", - "Article 12.6(g)", - "Article 12.6(h)", - "Article 12.6(i)", - "Article 12.6(j)", - "Article 12.6(k)", - "Article 12.6(l)", - "Article 12.6(m)", - "Article 12.6(n)", - "Article 12.6(ñ)", - "Article 12.7" + "CFG-03.3": [ + "2409" ], - "GOV-03": [ - "Article 27" + "CFG-03.4": [ + "2305" ], - "GOV-06": [ - "Article 32.1", - "Article 32.2", - "Article 32.3" + "MON-01": [ + "2427", + "3100", + "3101" ], - "GOV-15": [ - "Article 5", - "Article 5(a)", - "Article 5(b)", - "Article 5(c)", - "Article 5(d)", - "Article 5(e)", - "Article 5(f)", - "Article 5(g)", - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5", - "Article 28.1", - "Article 37" + "MON-01.4": [ + "3101" ], - "GOV-15.1": [ - "Article 3.3", - "Article 28.1(a)", - "Article 28.1(b)", - "Article 28.1(c)", - "Article 28.2", - "Article 28.3", - "Article 37" + "MON-01.8": [ + "3101" ], - "GOV-15.2": [ - "Article 3.3", - "Article 37" + "MON-03.2": [ + "3107" ], - "AST-01": [ - "Article 18" + "MON-06": [ + "3108" ], - "BCD-01": [ - "Article 26" + "MON-07.1": [ + "2421" ], - "BCD-11": [ - "Article 26" + "MON-10": [ + "3107" ], - "CHG-01": [ - "Article 21.1" + "MON-16": [ + "3200", + "3203" ], - "CHG-02": [ - "Article 21.1" + "MON-16.3": [ + "4106" ], - "CPL-01": [ - "Article 3.1", - "Article 39" + "MON-17": [ + "3109" ], - "CPL-01.2": [ - "Article 38.2" + "MON-17.1": [ + "3101" ], - "CPL-02": [ - "Article 10.1", - "Article 10.2", - "Article 10.3" + "CRY-01": [ + "2304", + "2317", + "2318" ], - "CPL-02.1": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 41.1", - "Article 41.2" + "CRY-03": [ + "2306" ], - "CPL-03": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7" + "CRY-05": [ + "2310", + "2317" ], - "CPL-03.1": [ - "Article 38.1" + "CRY-09": [ + "2319" ], - "CPL-03.2": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 38.1" + "DCH-01": [ + "2300" ], - "CFG-01": [ - "Article 30.1", - "Article 30.2" + "DCH-09": [ + "2323" ], - "CFG-02": [ - "Article 20(d)" + "DCH-09.1": [ + "2323" ], - "CFG-02.2": [ - "Article 21.2" + "DCH-10": [ + "2310" ], - "CFG-03": [ - "Article 20(a)", - "Article 20(b)", - "Article 20(c)", - "Article 20(d)" + "DCH-12": [ + "2310" ], - "CFG-03.1": [ - "Article 21.2" + "DCH-15": [ + "2321" ], - "MON-01": [ - "Article 10.1", - "Article 21.2", - "Article 24.1" + "END-01": [ + "2317", + "2411" ], - "MON-03": [ - "Article 24.1" + "END-02": [ + "2411" ], - "MON-16": [ - "Article 10.1" + "END-04": [ + "2411", + "2426" ], - "DCH-01": [ - "Article 22.1", - "Article 22.3" + "END-04.1": [ + "2426" ], - "DCH-01.2": [ - "Article 22.1", - "Article 22.3" + "END-04.7": [ + "2426" ], - "DCH-02": [ - "Article 40.1", - "Article 40.2", - "Article 41.2" + "END-08": [ + "2509" ], - "DCH-18.1": [ - "Article 24.2" + "END-10": [ + "2413" ], "HRS-01": [ - "Article 15.1" + "1300", + "2702" ], - "HRS-02": [ - "Article 13.2" + "HRS-01.1": [ + "2702" ], "HRS-03": [ - "Article 11.1", - "Article 11.2", - "Article 11.3", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.2(d)", - "Article 13.3", - "Article 13.4", - "Article 13.5" + "1102", + "2321", + "3101" ], "HRS-03.1": [ - "Article 13.1", - "Article 15.1" - ], - "HRS-03.2": [ - "Article 15.1", - "Article 16.1", - "Article 16.2", - "Article 16.3" + "2600", + "2603" ], - "HRS-04.2": [ - "Article 13.2", - "Article 15.1" + "HRS-04": [ + "2700", + "2701" ], "HRS-05": [ - "Article 11.2", - "Article 11.3" + "2604" ], "HRS-05.1": [ - "Article 11.2", - "Article 11.3" + "2604" + ], + "HRS-05.2": [ + "2604" + ], + "HRS-05.3": [ + "2604" + ], + "HRS-05.5": [ + "2322" ], "HRS-11": [ - "Article 13.3" + "2207" ], - "IAC-01": [ - "Article 18" + "HRS-14": [ + "2311" ], - "IAC-02": [ - "Article 24.3" + "HRS-14.1": [ + "2311" ], - "IAC-03": [ - "Article 24.3" + "HRS-15": [ + "2703" ], - "IAC-08": [ - "Article 17" + "IAC-01": [ + "2200", + "2210" ], - "IAC-21": [ - "Article 17", - "Article 20" + "IAC-01.1": [ + "1503" ], - "IRO-01": [ - "Article 25.1" + "IAC-01.2": [ + "2200", + "2210", + "2304" ], - "IRO-02": [ - "Article 25.1", - "Article 25.2", - "Article 33.4" + "IAC-01.3": [ + "2217" ], - "IRO-02.4": [ - "Article 33.4" + "IAC-02": [ + "2218" ], - "IRO-04": [ - "Article 25.1", - "Article 25.2" + "IAC-02.2": [ + "2215" ], - "IRO-07": [ - "Article 33.3" + "IAC-06": [ + "2305", + "2512" ], - "IRO-09": [ - "Article 25.2" + "IAC-07": [ + "2702" ], - "IRO-10": [ - "Article 25.2", - "Article 33.2", - "Article 33.4", - "Article 33.7" + "IAC-08": [ + "2200", + "2206", + "2422" ], - "NET-01": [ - "Article 23" + "IAC-10.4": [ + "2213" ], - "PES-01": [ - "Article 18" + "IAC-10.8": [ + "2211" ], - "PRM-07": [ - "Article 8 (end)", - "Article 36" + "IAC-11": [ + "2419", + "2420" ], - "RSK-01": [ - "Article 7.1", - "Article 7.2" + "IAC-15.1": [ + "2218" ], - "RSK-03": [ - "Article 3.2" + "IAC-21": [ + "2205", + "2206" ], - "RSK-04": [ - "Article 3.2", - "Article 14.1", - "Article 14.2" + "IAC-22": [ + "2214" ], - "RSK-06": [ - "Article 14.2", - "Article 14.3" + "IAC-24": [ + "2408" ], - "RSK-06.1": [ - "Article 14.2", - "Article 14.3" + "IRO-01": [ + "4104" ], - "SEA-01": [ - "Article 29" + "IRO-02": [ + "4104" ], - "SEA-02": [ - "Article 29" + "IRO-03": [ + "3201" ], - "SEA-02.1": [ - "Article 4" + "IRO-13": [ + "4200" ], - "SEA-03": [ - "Article 9.1", - "Article 9.1(a)", - "Article 9.1(b)", - "Article 9.2" + "IRO-15": [ + "2411" ], - "SEA-07.1": [ - "Article 36" + "MNT-02": [ + "2511" ], - "OPS-01": [ - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5" + "MNT-03": [ + "2511" ], - "OPS-01.1": [ - "Article 13.2(d)", - "Article 13.4", - "Article 22.2" + "MNT-04.2": [ + "2510" ], - "SAT-01": [ - "Article 6.2" + "MNT-05": [ + "2512" ], - "TDA-01": [ - "Article 19.1", - "Article 19.2", - "Article 19.2(a)", - "Article 19.2(b)", - "Article 19.2(c)", - "Article 19.3" + "MNT-06.1": [ + "2513" ], - "TPM-04": [ - "Article 13.5" + "MDM-01": [ + "2322" ], - "TPM-05.4": [ - "Article 13.2", - "Article 13.5" - ] - }, - "emea-esp-decree-1720-2007": { - "DCH-22.1": [ - "23", - "24", - "31", - "32" + "NET-03": [ + "2427" ], - "PRI-01": [ - "Inferred", - "Expectation" + "NET-03.4": [ + "2316" ], - "PRI-02": [ - "8" + "NET-04": [ + "2316", + "2428" ], - "PRI-03": [ - "8", - "12" + "NET-04.1": [ + "2507" ], - "PRI-04": [ - "8" + "NET-06": [ + "2508" ], - "PRI-04.1": [ - "8" + "NET-07": [ + "2303", + "2411" ], - "PRI-05": [ - "8", - "22" + "NET-08": [ + "2411" ], - "PRI-05.1": [ - "8" + "NET-09": [ + "2414" ], - "PRI-05.2": [ - "8" + "NET-10": [ + "2315" ], - "PRI-06": [ - "23", - "24", - "27", - "28", - "29" + "NET-10.3": [ + "2315" ], - "PRI-06.1": [ - "23", - "24", - "31", - "32" + "NET-12": [ + "2305" ], - "PRI-06.2": [ - "23", - "24", - "31", - "32" + "NET-14": [ + "2305" ], - "PRI-06.3": [ - "23", - "24" + "NET-14.2": [ + "2305", + "2306" ], - "PRI-06.4": [ - "26" + "NET-14.3": [ + "2307" ], - "PRI-15": [ - "60" + "NET-14.4": [ + "2417" ], - "TPM-03": [ - "20", - "21" + "NET-14.5": [ + "2305" ], - "TPM-05": [ - "20", - "21" - ] - }, - "emea-esp-decree-311-2022": { - "GOV-01": [ - "13.1", - "35.1", - "5", - "6.1", - "6.2" + "NET-15.1": [ + "2304" ], - "GOV-01.1": [ - "27", - "5" + "NET-18": [ + "2411" ], - "GOV-02": [ - "12.1", - "12.1(a)", - "12.1(b)", - "12.1(c)", - "12.1(d)", - "12.1(e)", - "12.1(f)", - "12.2", - "12.6", - "12.6(a)", - "12.6(b)", - "12.6(c)", - "12.6(d)", - "12.6(e)", - "12.6(f)", - "12.6(g)", - "12.6(h)", - "12.6(i)", - "12.6(j)", - "12.6(k)", - "12.6(l)", - "12.6(m)", - "12.6(n)", - "12.6(ñ)", - "12.7" + "NET-20.4": [ + "2315" ], - "GOV-03": [ - "27" + "NET-20.7": [ + "2509" ], - "GOV-06": [ - "32.1", - "32.2", - "32.3" + "PES-01": [ + "1500" ], - "GOV-15": [ - "28.1", - "37", - "5", - "5(a)", - "5(b)", - "5(c)", - "5(d)", - "5(e)", - "5(f)", - "5(g)", - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" + "PES-02": [ + "1500" ], - "GOV-15.1": [ - "28.1(a)", - "28.1(b)", - "28.1(c)", - "28.2", - "28.3", - "3.3", - "37" + "PES-02.1": [ + "1502", + "2422" ], - "GOV-15.2": [ - "3.3", - "37" + "PES-03": [ + "1500" ], - "AST-01": [ - "18" + "PES-03.3": [ + "1500" ], - "BCD-01": [ - "26" + "PES-03.4": [ + "1502" ], - "BCD-11": [ - "26" + "PES-05": [ + "1500" ], - "CHG-01": [ - "21.1" + "PES-05.1": [ + "1500" ], - "CHG-02": [ - "21.1" + "PES-06.1": [ + "1503" ], - "CPL-01": [ - "3.1", - "39" + "PES-06.2": [ + "1503" ], - "CPL-01.2": [ - "38.2" + "PES-06.6": [ + "1503" ], - "CPL-02": [ - "10.1", - "10.2", - "10.3" + "PES-07.3": [ + "2704" ], - "CPL-02.1": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "41.1", - "41.2" + "PES-08.2": [ + "2704" ], - "CPL-03": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7" + "PES-09": [ + "2704" ], - "CPL-03.1": [ - "38.1" + "PES-11": [ + "2312" ], - "CPL-03.2": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "38.1" + "PES-19": [ + "1501" ], - "CFG-01": [ - "30.1", - "30.2" + "PRI-02": [ + "2407" ], - "CFG-02": [ - "20(d)" + "RSK-01": [ + "1200" ], - "CFG-02.2": [ - "21.2" + "RSK-03": [ + "1200" ], - "CFG-03": [ - "20(a)", - "20(b)", - "20(c)", - "20(d)" + "RSK-04": [ + "1200", + "1202" ], - "CFG-03.1": [ - "21.2" + "RSK-06": [ + "1200" ], - "MON-01": [ - "10.1", - "21.2", - "24.1" + "RSK-09": [ + "1400" ], - "MON-01.16": [ - "10.1", - "21.2", - "24.1" + "RSK-09.1": [ + "1400" ], - "MON-03": [ - "24.1" + "SEA-01": [ + "2400" ], - "MON-16": [ - "10.1" + "SEA-01.2": [ + "2500", + "2501" ], - "DCH-01": [ - "22.1", - "22.3" + "SEA-18": [ + "2407" ], - "DCH-01.2": [ - "22.1", - "22.3" + "SEA-20": [ + "2421" ], - "DCH-02": [ - "40.1", - "40.2", - "41.2" + "OPS-01.1": [ + "1100", + "2100" ], - "DCH-18.1": [ - "24.2" + "SAT-02": [ + "2600", + "2603" ], - "HRS-01": [ - "15.1" + "SAT-03": [ + "2321" ], - "HRS-02": [ - "13.2" + "SAT-03.6": [ + "2603" ], - "HRS-03": [ - "11.1", - "11.2", - "11.3", - "13.1", - "13.2", - "13.2(a)", - "13.2(b)", - "13.2(c)", - "13.2(d)", - "13.3", - "13.4", - "13.5" + "TPM-01": [ + "1400" ], - "HRS-03.1": [ - "13.1", - "15.1" + "TPM-03": [ + "1400" ], - "HRS-03.2": [ - "15.1", - "16.1", - "16.2", - "16.3" + "TPM-05": [ + "1401", + "2323" ], - "HRS-04.2": [ - "13.2", - "15.1" + "TPM-05.2": [ + "1401" ], - "HRS-05": [ - "11.2", - "11.3" + "VPM-01": [ + "2402", + "2405" ], - "HRS-05.1": [ - "11.2", - "11.3" + "VPM-02": [ + "2402" ], - "HRS-11": [ - "13.3" + "VPM-05": [ + "2402", + "2405" ], - "IAC-01": [ - "18" + "VPM-05.6": [ + "2405" ], - "IAC-02": [ - "24.3" + "VPM-05.7": [ + "2405" ], - "IAC-03": [ - "24.3" + "VPM-06": [ + "2402" ], - "IAC-08": [ - "17" + "VPM-07": [ + "2403" ], - "IAC-21": [ - "17", - "20" + "WEB-14": [ + "2321" + ] + }, + "emea-gbr-def-stan-05-138-l2-2024": { + "GOV-01.1": [ + "1101", + "1103", + "1202" ], - "IRO-01": [ - "25.1" + "GOV-02": [ + "1100", + "1101", + "2100", + "2101" ], - "IRO-02": [ - "25.1", - "25.2", - "33.4" + "GOV-03": [ + "2100", + "2101" ], - "IRO-02.4": [ - "33.4" + "GOV-04": [ + "1102", + "1103" ], - "IRO-04": [ - "25.1", - "25.2" + "GOV-04.1": [ + "1101", + "1103" ], - "IRO-07": [ - "33.3" + "GOV-04.2": [ + "1103" ], - "IRO-09": [ - "25.2" + "AST-01": [ + "1300", + "1301", + "2202" ], - "IRO-10": [ - "25.2", - "33.2", - "33.4", - "33.7" + "AST-01.4": [ + "2410" ], - "NET-01": [ - "23" + "AST-02": [ + "1301", + "2202", + "2310" ], - "PES-01": [ - "18" + "AST-02.2": [ + "3204" ], - "PRM-07": [ - "36", - "8 (end)" + "AST-02.4": [ + "2202" ], - "RSK-01": [ - "7.1", - "7.2" + "AST-02.9": [ + "1301", + "2423" ], - "RSK-03": [ - "3.2" + "AST-04": [ + "1203", + "2301" ], - "RSK-04": [ - "14.1", - "14.2", - "3.2" + "AST-09": [ + "2323" ], - "RSK-06": [ - "14.2", - "14.3" + "AST-16": [ + "2322" ], - "RSK-06.1": [ - "14.2", - "14.3" + "AST-21": [ + "2412" ], - "SEA-01": [ - "29" + "BCD-01": [ + "2501", + "4100" ], - "SEA-02": [ - "29" + "BCD-04": [ + "2503" ], - "SEA-02.1": [ - "4" + "BCD-11": [ + "2505" ], - "SEA-03": [ - "29" + "BCD-11.1": [ + "2505" ], - "SEA-07.1": [ - "36" + "BCD-11.2": [ + "2505" ], - "OPS-01": [ - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" + "BCD-11.4": [ + "2506" ], - "OPS-01.1": [ - "13.2(d)", - "13.4", - "22.2" + "BCD-11.5": [ + "2505" ], - "SAT-01": [ - "6.2" + "BCD-11.6": [ + "2506" ], - "TDA-01": [ - "19.1", - "19.2", - "19.2(a)", - "19.2(b)", - "19.2(c)", - "19.3" + "CHG-01": [ + "2404" ], - "TPM-04": [ - "13.5" + "CHG-04": [ + "2422" ], - "TPM-05.4": [ - "13.2", - "13.5" - ] - }, - "emea-esp-ccn-stic-825-2023": { - "GOV-01": [ - "6.1 [ORG.1]" + "CPL-01": [ + "0001", + "0002", + "2314" ], - "GOV-02": [ - "6.1 [ORG.1]", - "6.2 [ORG.2]" + "CPL-02": [ + "1206" ], - "GOV-05": [ - "7.6.2 [OP.MON.2]" + "CPL-02.2": [ + "1206" ], - "AST-02": [ - "7.3.1 [OP.EXP.1]" + "CPL-03.2": [ + "1206" ], - "AST-06": [ - "8.3.2 [MP.EQ.2]" + "CFG-02": [ + "2204", + "2310", + "2400", + "2401", + "2418" ], - "AST-09": [ - "8.5.5 [MP.SI.5]" + "CFG-02.1": [ + "2418" ], - "BCD-01": [ - "7.5.1 [OP.CONT.1]", - "7.5.2 [OP.CONT.2]" + "CFG-02.5": [ + "2312" ], - "BCD-04": [ - "7.5.3 [OP.CONT.3]" + "CFG-02.9": [ + "2418" ], - "BCD-08": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.4.4 [MP.COM.4]", - "8.8.4 [MP.S.4]" + "CFG-03": [ + "2204", + "2430", + "2507" ], - "BCD-09": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.8.4 [MP.S.4]" + "CFG-03.1": [ + "2430", + "2507" ], - "BCD-11": [ - "8.7.7 [MP.INFO.7]" + "CFG-03.3": [ + "2409" ], - "CAP-01": [ - "7.1.4 [OP.PL.4]" + "CFG-03.4": [ + "2305" ], - "CHG-01": [ - "7.3.5 [OP.EXP.5]" + "MON-01": [ + "2203", + "2427", + "3100", + "3101", + "3106" ], - "CPL-01": [ - "7.1.5 [OP.PL.5]" + "MON-01.4": [ + "3101" ], - "CPL-02": [ - "9" + "MON-01.8": [ + "3101" ], - "CPL-03.1": [ - "9" + "MON-01.15": [ + "2203" ], - "CFG-01": [ - "7.3.3 [OP.EXP.3]" + "MON-03": [ + "3104" ], - "CFG-02": [ - "7.3.2 [OP.EXP.2]" + "MON-03.2": [ + "3107" ], - "MON-01": [ - "7.3.8 [OP.EXP.8]" + "MON-03.3": [ + "2216" ], - "MON-01.1": [ - "7.6.1 [OP.MON.1]" + "MON-06": [ + "3108" ], - "MON-01.4": [ - "7.3.8 [OP.EXP.8]" + "MON-07.1": [ + "2421" ], - "MON-01.16": [ - "7.3.8 [OP.EXP.8]" + "MON-08": [ + "3103" ], - "MON-02.2": [ - "7.3.8 [OP.EXP.8]" + "MON-10": [ + "3103", + "3107" ], - "MON-03": [ - "7.3.8 [OP.EXP.8]" + "MON-16": [ + "3200", + "3202", + "3203" ], - "MON-07": [ - "8.7.5 [MP.INFO.5]" + "MON-16.3": [ + "4106" ], - "MON-08": [ - "7.3.10 [OP.EXP.10]" + "MON-17": [ + "3109" + ], + "MON-17.1": [ + "3101" ], "CRY-01": [ - "8.4.2 [MP.COM.2]", - "8.4.3 [MP.COM.3]", - "8.5.2 [MP.SI.2]", - "8.7.3 [MP.INFO.3]", - "8.7.4 [MP.INFO.4]" + "2304", + "2317", + "2318" + ], + "CRY-03": [ + "2302", + "2306" + ], + "CRY-05": [ + "2310", + "2317" ], "CRY-09": [ - "7.3.11 [OP.EXP.11]" + "2319" ], "DCH-01": [ - "8.5.3 [MP.SI.3]" + "2308" ], - "DCH-01.1": [ - "8.5.3 [MP.SI.3]" + "DCH-01.2": [ + "2308" + ], + "DCH-01.4": [ + "2301" ], "DCH-02": [ - "8.7.2 [MP.INFO.2]" + "2301" ], - "DCH-04": [ - "8.5.1 [MP.SI.1]" + "DCH-03": [ + "2301" ], - "DCH-07": [ - "8.5.4 [MP.SI.4]" + "DCH-06": [ + "2308" ], - "DCH-07.1": [ - "8.5.3 [MP.SI.3]" + "DCH-07": [ + "2302", + "2506" ], - "DCH-08": [ - "8.5.5 [MP.SI.5]" + "DCH-07.2": [ + "2302" ], "DCH-09": [ - "8.7.6 [MP.INFO.6]" - ], - "DCH-18": [ - "9" + "2313", + "2323" ], - "END-01": [ - "8.3.1 [MP.EQ.1]" + "DCH-09.1": [ + "2323" ], - "END-04": [ - "7.3.6 [OP.EXP.6]" + "DCH-10": [ + "2310" ], - "END-07": [ - "7.6.1 [OP.MON.1]" + "DCH-12": [ + "2310" ], - "HRS-03": [ - "6.4 [ORG.4]", - "8.2.1 [MP.PER.1]", - "8.2.2 [MP.PER.2]" + "DCH-15": [ + "2321" ], - "HRS-05": [ - "8.2.2 [MP.PER.2]" + "END-01": [ + "2317", + "2411" ], - "HRS-11": [ - "7.2.3 [OP.ACC.3]" + "END-02": [ + "2411" ], - "HRS-13.2": [ - "8.2.5 [MP.PER.5]" + "END-04": [ + "2411", + "2426" ], - "HRS-13.3": [ - "8.2.5 [MP.PER.5]" + "END-04.1": [ + "2426" ], - "HRS-13.4": [ - "8.2.5 [MP.PER.5]" + "END-04.7": [ + "2426" ], - "IAC-01": [ - "7.2.2 [OP.ACC.2]", - "7.2.4 [OP.ACC.4]" + "END-08": [ + "2509" ], - "IAC-07": [ - "7.2.1 [OP.ACC.1]" + "END-10": [ + "2413" ], - "IAC-08": [ - "7.2.4 [OP.ACC.4]" + "HRS-01": [ + "1300", + "2702" ], - "IAC-10": [ - "7.2.5 [OP.ACC.5]" + "HRS-01.1": [ + "2702" ], - "IAC-10.1": [ - "7.2.5 [OP.ACC.5]" + "HRS-03": [ + "1102", + "2321", + "3101" ], - "IAC-10.5": [ - "7.2.5 [OP.ACC.5]" + "HRS-03.1": [ + "2600", + "2603" ], - "IAC-10.11": [ - "7.2.5 [OP.ACC.5]" + "HRS-04": [ + "2700", + "2701" ], - "IRO-01": [ - "7.3.7 [OP.EXP.7]" + "HRS-05": [ + "2604" ], - "IRO-02": [ - "7.3.7 [OP.EXP.7]", - "7.3.9 [OP.EXP.9]" + "HRS-05.1": [ + "2604" ], - "MNT-01": [ - "7.3.4 [OP.EXP.4]" + "HRS-05.2": [ + "2604" ], - "MDM-01": [ - "8.3.3 [MP.EQ.3]" + "HRS-05.3": [ + "2604" ], - "NET-01": [ - "8.4.1 [MP.COM.1]", - "8.4.2 [MP.COM.2]" + "HRS-05.5": [ + "2322" ], - "NET-02.1": [ - "8.8.3 [MP.S.3]" + "HRS-11": [ + "2207" ], - "NET-06": [ - "8.4.4 [MP.COM.4]" + "HRS-14": [ + "2311" ], - "NET-08": [ - "7.6.1 [OP.MON.1]" + "HRS-14.1": [ + "2311" ], - "NET-08.2": [ - "7.6.1 [OP.MON.1]" + "HRS-15": [ + "2703" ], - "NET-13": [ - "8.8.1 [MP.S.1]" - ], - "NET-14": [ - "7.2.7 [OP.ACC.7]" - ], - "NET-14.5": [ - "7.2.7 [OP.ACC.7]", - "9" - ], - "PES-01.1": [ - "8.1.1 [MP.IF.1]" - ], - "PES-02": [ - "8.1.1 [MP.IF.1]" - ], - "PES-02.1": [ - "8.1.1 [MP.IF.1]" - ], - "PES-03": [ - "8.1.1 [MP.IF.1]" - ], - "PES-06": [ - "8.1.2 [MP.IF.2]", - "8.1.7 [MP.IF.7]" - ], - "PES-06.2": [ - "8.1.2 [MP.IF.2]" - ], - "PES-07": [ - "8.1.3 [MP.IF.3]", - "8.1.4 [MP.IF.4]" - ], - "PES-07.1": [ - "8.1.4 [MP.IF.4]" - ], - "PES-07.6": [ - "8.1.6 [MP.IF.6]" - ], - "PES-08": [ - "8.1.5 [MP.IF.5]" - ], - "PES-12": [ - "8.1.3 [MP.IF.3]" - ], - "PRI-01": [ - "8.7.1 [MP.INFO.1]" - ], - "PRM-01": [ - "9" - ], - "PRM-05": [ - "7.1.3 [OP.PL.3]" - ], - "RSK-04": [ - "7.1.1 [OP.PL.1]" - ], - "SEA-01": [ - "7.1.2 [OP.PL.2]" - ], - "SEA-02": [ - "7.1.2 [OP.PL.2]" - ], - "SEA-03": [ - "7.1.2 [OP.PL.2]" - ], - "SEA-17": [ - "7.2.6 [OP.ACC.6]" - ], - "OPS-01.1": [ - "6.3 [ORG.3]" - ], - "SAT-01": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" - ], - "SAT-02": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" - ], - "SAT-03": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" - ], - "TDA-01": [ - "7.1.3 [OP.PL.3]", - "8.6.1 [MP.SW.1]" - ], - "TDA-02.3": [ - "8.6.1 [MP.SW.1]" - ], - "TDA-06.3": [ - "8.6.1 [MP.SW.1]" - ], - "TDA-06.5": [ - "8.6.2 [MP.SW.2]" - ], - "TDA-09": [ - "8.6.2 [MP.SW.2]" - ], - "TDA-17.1": [ - "7.4.3 [OP.EXT.3]" - ], - "TPM-01": [ - "7.4.1 [OP.EXT.1]" - ], - "TPM-03": [ - "7.4.1 [OP.EXT.1]", - "7.4.3 [OP.EXT.3]" - ], - "TPM-05": [ - "7.4.1 [OP.EXT.1]" - ], - "TPM-10": [ - "7.4.2 [OP.EXT.2]" - ], - "WEB-01": [ - "8.8.2 [MP.S.2]" - ] - }, - "emea-che-fadp-2025": { - "GOV-01": [ - "7" - ], - "CPL-01": [ - "7" - ], - "CPL-02": [ - "7" - ], - "DCH-01": [ - "6", - "7" - ], - "DCH-22.1": [ - "5" - ], - "IRO-04.1": [ - "12" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-04": [ - "4" - ], - "PRI-04.1": [ - "4" - ], - "PRI-05": [ - "4" - ], - "PRI-06": [ - "8" - ], - "PRI-06.1": [ - "5" - ], - "PRI-15": [ - "11" - ], - "SEA-01": [ - "6", - "7" - ], - "SEA-02": [ - "6", - "7" - ], - "SEA-03": [ - "6", - "7" - ] - }, - "emea-tur-lppd-2016": { - "GOV-01": [ - "12" - ], - "CPL-01": [ - "12" - ], - "CPL-02": [ - "12" - ], - "DCH-01": [ - "8", - "12" - ], - "PRI-01": [ - "Inferred", - "Expectation" + "IAC-01": [ + "2200", + "2208", + "2210" ], - "PRI-02": [ - "10" + "IAC-01.1": [ + "1503" ], - "PRI-02.1": [ - "10" + "IAC-01.2": [ + "2200", + "2210", + "2304" ], - "PRI-03": [ - "10" + "IAC-01.3": [ + "2217" ], - "PRI-04": [ - "10" + "IAC-02": [ + "2218" ], - "PRI-04.1": [ - "10" + "IAC-02.2": [ + "2215" ], - "PRI-05": [ - "5", - "7" + "IAC-06": [ + "2201", + "2305", + "2512" ], - "PRI-05.4": [ - "6" + "IAC-07": [ + "2702" ], - "PRI-06": [ - "11" + "IAC-08": [ + "2200", + "2206", + "2422" ], - "PRI-15": [ - "16" + "IAC-10.4": [ + "2213" ], - "SEA-01": [ - "8", - "12" + "IAC-10.8": [ + "2211" ], - "SEA-02": [ - "8", - "12" + "IAC-10.11": [ + "2212" ], - "SEA-03": [ - "8", - "12" - ] - }, - "emea-uae-niaf-2023": { - "AST-02": [ - "3.1.1" + "IAC-11": [ + "2419", + "2420" ], - "BCD-01": [ - "3.4", - "3.4.1", - "3.4.2", - "3.4.3" + "IAC-15": [ + "2424" ], - "BCD-01.5": [ - "3.4.2" + "IAC-15.1": [ + "2218" ], - "BCD-02": [ - "3.4" + "IAC-16": [ + "2424" ], - "BCD-02.1": [ - "3.4.3" + "IAC-16.1": [ + "2424" ], - "BCD-04": [ - "3.4.1" + "IAC-21": [ + "2205", + "2206" ], - "CFG-02": [ - "3.2.1" + "IAC-21.5": [ + "2216" ], - "HRS-01": [ - "3.2.3" + "IAC-22": [ + "2214" ], - "HRS-01.1": [ - "3.2.3" + "IAC-24": [ + "2408" ], "IRO-01": [ - "3.3", - "3.3.2" + "3105", + "4104" ], "IRO-02": [ - "3.3.1", - "3.3.2" - ], - "IRO-09": [ - "3.3.1" - ], - "IRO-10": [ - "3.3.3" - ], - "IRO-10.2": [ - "3.3.3" - ], - "IAO-05": [ - "3.2" - ], - "PES-01": [ - "3.2.2" - ], - "PES-03": [ - "3.2.2" - ], - "RSK-08": [ - "3.1.2" - ], - "SEA-01": [ - "3.2.1" - ], - "VPM-06": [ - "3.1.3" - ] - }, - "emea-gbr-caf-4-0": { - "GOV-01.1": [ - "A1.a", - "A1.c" - ], - "GOV-02": [ - "A1", - "B1", - "B1.b" - ], - "GOV-03": [ - "B1.a" - ], - "GOV-04": [ - "A1.b", - "A1.c" - ], - "GOV-04.1": [ - "A1.b" - ], - "GOV-04.2": [ - "A1.b" - ], - "GOV-15": [ - "B4.a" - ], - "GOV-15.1": [ - "B4.a" - ], - "GOV-15.2": [ - "B4.a" - ], - "GOV-19": [ - "A2.c" - ], - "AST-01": [ - "A3" - ], - "AST-01.1": [ - "A3", - "A3.a (point 2)" - ], - "AST-01.2": [ - "A3.a (point 4)" - ], - "AST-02": [ - "A3.a (point 1)" - ], - "AST-03": [ - "A3.a (point 4)" - ], - "AST-04": [ - "B3.a" - ], - "BCD-01": [ - "B5.a" - ], - "BCD-02": [ - "A3.a (point 3)" - ], - "BCD-11": [ - "B5.c" - ], - "CPL-01.4": [ - "A2.c" - ], - "CFG-01": [ - "B4", - "B4.c" - ], - "CFG-02": [ - "B4", - "B4.b" - ], - "MON-01": [ - "C1" - ], - "MON-01.4": [ - "C1.a", - "C1.c" - ], - "MON-01.8": [ - "C1.a" - ], - "MON-03": [ - "C1.a" - ], - "MON-08": [ - "C1.b" - ], - "MON-10": [ - "C1.b" - ], - "MON-16": [ - "C1.f" - ], - "MON-17": [ - "C1.d" - ], - "CRY-03": [ - "B3.b" - ], - "CRY-05": [ - "B3.c" - ], - "DCH-01": [ - "B3" - ], - "DCH-02": [ - "B3.a" - ], - "DCH-06.2": [ - "B3.a" - ], - "DCH-09": [ - "B3.e" + "3105", + "4104" ], - "DCH-14.3": [ - "B3.a" + "IRO-03": [ + "3201" ], - "DCH-19": [ - "B3.a" + "IRO-04": [ + "4101", + "4102" ], - "END-01": [ - "B3.d" + "IRO-06": [ + "4103", + "4105" ], - "HRS-03.2": [ - "C1.e" + "IRO-08": [ + "3104" ], - "IAC-01": [ - "B2", - "B2.d" + "IRO-13": [ + "4200" ], - "IAC-02": [ - "B2.a" + "IRO-15": [ + "2411" ], - "IAC-03": [ - "B2.a" + "IAO-01": [ + "1205" ], - "IAC-04": [ - "B2.b" + "IAO-02": [ + "1205" ], - "IAC-16": [ - "B2.c" + "IAO-03": [ + "2301" ], - "IRO-01": [ - "D1" + "IAO-06": [ + "1205" ], - "IRO-02": [ - "D1.b" + "MNT-02": [ + "2511" ], - "IRO-03": [ - "C1.f" + "MNT-03": [ + "2511" ], - "IRO-04": [ - "D1.a" + "MNT-04.2": [ + "2510" ], - "IRO-06": [ - "D1.c" + "MNT-05": [ + "2512" ], - "IRO-13": [ - "D2", - "D2.a", - "D2.b" + "MNT-06.1": [ + "2513" ], "MDM-01": [ - "B3.d" - ], - "RSK-01": [ - "A2", - "A2.a" + "2309", + "2322" ], - "RSK-09": [ - "A4", - "A4.a" + "MDM-03": [ + "2309" ], - "SEA-01": [ - "B4.a", - "B5.b" + "NET-03": [ + "2427" ], - "SEA-01.3": [ - "B5", - "B5.b" + "NET-03.4": [ + "2316" ], - "SEA-07.1": [ - "A3.a (point 5)" + "NET-04": [ + "2316", + "2428" ], - "SAT-01": [ - "B6.a" + "NET-04.1": [ + "2507" ], - "SAT-02": [ - "B6" + "NET-06": [ + "2508" ], - "SAT-03": [ - "B6.b" + "NET-07": [ + "2303", + "2411" ], - "TDA-06": [ - "A4.b" + "NET-08": [ + "2411" ], - "TPM-01": [ - "A4" + "NET-09": [ + "2414" ], - "THR-01": [ - "A2.b" + "NET-10": [ + "2315" ], - "THR-07": [ - "C2", - "C2.a (point 1)", - "C2.a (point 2)", - "C2.a (point 3)", - "C2.a (point 4)", - "C2.a (point 5)", - "C2.a (point 6)", - "C2.a (point 7)", - "C2.a (point 8)" + "NET-10.3": [ + "2315" ], - "THR-09": [ - "A2.b", - "C1.f" + "NET-12": [ + "2305" ], - "VPM-01": [ - "B4.d" - ] - }, - "emea-gbr-cap-1850-2020": { - "GOV-01": [ - "A1" + "NET-14": [ + "2305" ], - "GOV-02": [ - "A1", - "A5" + "NET-14.2": [ + "2305", + "2306" ], - "GOV-15": [ - "A5" + "NET-14.3": [ + "2307" ], - "GOV-15.1": [ - "A5", - "A6" + "NET-14.4": [ + "2417" ], - "GOV-15.2": [ - "A5", - "A6", - "B4" + "NET-14.5": [ + "2305" ], - "GOV-15.3": [ - "A5", - "A6", - "B4" + "NET-15.1": [ + "2304" ], - "GOV-15.4": [ - "A5" + "NET-17": [ + "2320" ], - "GOV-15.5": [ - "A5" + "NET-18": [ + "2411" ], - "AST-01": [ - "A3" + "NET-20.4": [ + "2315" ], - "AST-01.1": [ - "A4" + "NET-20.7": [ + "2509" ], - "BCD-01": [ - "D1" + "PES-01": [ + "1500" ], - "BCD-02": [ - "A4" + "PES-02": [ + "1500" ], - "BCD-05": [ - "D2" + "PES-02.1": [ + "1502", + "2422" ], - "CFG-01": [ - "B4" + "PES-03": [ + "1500" ], - "CFG-02": [ - "B4" + "PES-03.3": [ + "1500" ], - "CFG-02.5": [ - "B4" + "PES-03.4": [ + "1502" ], - "MON-01": [ - "C1" + "PES-05": [ + "1500" ], - "MON-01.8": [ - "C1", - "C2" + "PES-05.1": [ + "1500" ], - "MON-01.16": [ - "C1" + "PES-06.1": [ + "1503" ], - "MON-02": [ - "C1", - "C2" + "PES-06.2": [ + "1503" ], - "MON-02.2": [ - "C1", - "C2" + "PES-06.6": [ + "1503" ], - "MON-02.3": [ - "C1", - "C2" + "PES-07.3": [ + "2704" ], - "MON-16": [ - "C1", - "C2" + "PES-08.2": [ + "2704" ], - "DCH-01": [ - "B3" + "PES-09": [ + "2704" ], - "DCH-01.2": [ - "B3" + "PES-11": [ + "2312" ], - "DCH-02": [ - "B3" + "PES-19": [ + "1501" ], - "IRO-13": [ - "D2" + "PRI-02": [ + "2406", + "2407" ], "RSK-01": [ - "A2" + "1200", + "1201" ], "RSK-03": [ - "A2" + "1200" ], "RSK-04": [ - "A2" - ], - "RSK-09": [ - "A4" - ], - "RSK-09.1": [ - "A4" - ], - "SEA-01": [ - "B4", - "B5" - ], - "SEA-02": [ - "B4", - "B5" + "1200", + "1202" ], - "SEA-03": [ - "B4", - "B5" + "RSK-04.1": [ + "4201" ], - "SAT-01": [ - "B6" + "RSK-06": [ + "1200" ], - "SAT-02": [ - "B6" + "RSK-08": [ + "4201" ], - "TDA-06.1": [ - "A4" + "RSK-09": [ + "1400" ], - "TPM-01": [ - "A4" + "RSK-09.1": [ + "1400" ], - "TPM-02": [ - "A4" + "RSK-12": [ + "2601" ], - "TPM-04": [ - "A4" + "SEA-01": [ + "2400" ], - "TPM-04.1": [ - "A4" + "SEA-01.2": [ + "2500", + "2501" ], - "TPM-05.4": [ - "A4" - ] - }, - "emea-gbr-cyber-essentials-requirements-3-3": { - "AST-02.7": [ - "3" + "SEA-05": [ + "2416" ], - "CFG-01": [ - "2" + "SEA-18": [ + "2406", + "2407" ], - "CFG-02": [ - "2" + "SEA-20": [ + "2421" ], - "CFG-03.3": [ - "4" + "OPS-01.1": [ + "1100", + "2100", + "2101" ], - "CFG-04": [ - "3" + "SAT-02": [ + "2600", + "2602", + "2603" ], - "CFG-05": [ - "3" + "SAT-02.1": [ + "2605" ], - "END-01": [ - "4" + "SAT-02.2": [ + "2602" ], - "END-02": [ - "4" + "SAT-03": [ + "2321", + "2602" ], - "END-03": [ - "3" + "SAT-03.1": [ + "2605" ], - "END-04": [ - "4" + "SAT-03.2": [ + "2602" ], - "END-04.1": [ - "4" + "SAT-03.3": [ + "2602" ], - "END-05": [ - "1" + "SAT-03.6": [ + "2601", + "2602", + "2603", + "3106" ], - "IAC-01": [ - "2" + "TPM-01": [ + "1400" ], - "IAC-02": [ - "2" + "TPM-03": [ + "1400" ], - "IAC-06": [ - "2" + "TPM-05": [ + "1401", + "2323" ], - "IAC-07": [ - "3" + "TPM-05.2": [ + "1401" ], - "IAC-08": [ - "3" + "THR-03": [ + "3110" ], - "IAC-09.5": [ - "3" + "THR-03.1": [ + "3110" ], - "IAC-10": [ - "2" + "VPM-01": [ + "2402", + "2405" ], - "IRO-15": [ - "4" + "VPM-02": [ + "2402" ], - "NET-01": [ - "1" + "VPM-05": [ + "2402", + "2405" ], - "NET-03": [ - "1" + "VPM-05.6": [ + "2405" ], - "NET-03.6": [ - "4" + "VPM-05.7": [ + "2405" ], - "VPM-01": [ - "5" + "VPM-06": [ + "2402" ], - "VPM-02": [ - "5" + "VPM-07": [ + "2403" ], - "VPM-05": [ - "5" + "WEB-14": [ + "2321" ] }, - "emea-gbr-def-stan-05-138-2024": { + "emea-gbr-def-stan-05-138-l3-2024": { "GOV-01.1": [ "1101", "1103", @@ -110866,18 +113630,15 @@ ], "BCD-01": [ "2501", - "2502", "4100" ], "BCD-04": [ "2503" ], "BCD-11": [ - "2504", "2505" ], "BCD-11.1": [ - "2504", "2505" ], "BCD-11.2": [ @@ -110956,18 +113717,13 @@ "2203", "2427", "3100", - "3101", "3102", "3106" ], "MON-01.2": [ "3102" ], - "MON-01.4": [ - "3101" - ], "MON-01.8": [ - "3101", "3102" ], "MON-01.15": [ @@ -111007,7 +113763,6 @@ "3109" ], "MON-17.1": [ - "3101", "3102" ], "CRY-01": [ @@ -111027,7 +113782,6 @@ "2319" ], "DCH-01": [ - "2300", "2308" ], "DCH-01.2": [ @@ -111107,7 +113861,6 @@ "HRS-03": [ "1102", "2321", - "3101", "3102" ], "HRS-03.1": [ @@ -111535,21005 +114288,22346 @@ "2321" ] }, - "emea-gbr-def-stan-05-138-l0-2024": { - "CPL-01": [ - "0001", - "2314" - ], - "SEA-01.2": [ - "2500" - ] - }, - "emea-gbr-def-stan-05-138-l1-2024": { - "GOV-01.1": [ - "1202" + "emea-gbr-dpa-2018": { + "IRO-10": [ + "Section 67(1)", + "Section 67(1)(a)", + "Section 67(1)(b)", + "Section 67(2)", + "Section 67(3)", + "Section 67(4)", + "Section 67(4)(a)", + "Section 67(4)(b)", + "Section 67(4)(c)", + "Section 67(4)(d)", + "Section 67(5)", + "Section 67(6)", + "Section 67(6)(a)", + "Section 67(6)(b)", + "Section 67(6)(c)", + "Section 67(7)", + "Section 67(9)", + "Section 68(1)", + "Section 68(2)", + "Section 68(2)(a)", + "Section 68(2)(b)", + "Section 68(2)(c)", + "Section 68(2)(d)", + "Section 68(3)", + "Section 68(3)(a)", + "Section 68(3)(b)", + "Section 68(3)(c)", + "Section 68(4)", + "Section 68(5)", + "Section 68(6)", + "Section 68(6)(a)", + "Section 68(6)(b)", + "Section 68(7)", + "Section 68(7)(a)", + "Section 68(7)(b)", + "Section 68(7)(c)", + "Section 68(7)(e)", + "Section 68(8)", + "Section 68(9)" ], - "GOV-02": [ - "1100", - "2100" + "PRI-01.4": [ + "Section 69(1)", + "Section 69(2)", + "Section 69(2)(a)", + "Section 69(2)(b)", + "Section 69(3)", + "Section 70(1)", + "Section 70(2)", + "Section 70(2)(a)", + "Section 70(2)(b)", + "Section 70(3)", + "Section 70(3)(a)", + "Section 70(3)(b)", + "Section 70(3)(c)", + "Section 70(4)", + "Section 70(4)(a)", + "Section 70(4)(b)", + "Section 70(5)", + "Section 71(1)", + "Section 71(1)(a)", + "Section 71(1)(b)", + "Section 71(1)(c)", + "Section 71(1)(d)", + "Section 71(1)(e)", + "Section 71(1)(f)", + "Section 71(2)", + "Section 71(2)(a)", + "Section 71(2)(b)", + "Section 71(2)(c)", + "Section 71(2)(d)", + "Section 71(3)" ], - "GOV-03": [ - "2100" + "PRI-01.5": [ + "Section 78", + "Section 78(1)", + "Section 78(1)(a)", + "Section 78(1)(b)", + "Section 78(1)(b)(i)", + "Section 78(1)(b)(ii)", + "Section 78(1A)", + "Section 78(1A)(a)", + "Section 78(1A)(b)", + "Section 78(2)", + "Section 78(3)", + "Section 78(3)(a)", + "Section 78(3)(b)", + "Section 78(3)(c)", + "Section 78(4)", + "Section 78(5)", + "Section 78(5)(a)", + "Section 78(5)(b)", + "Section 78(6)", + "Section 78(7)", + "Section 78(7)(a)", + "Section 78(7)(b)" ], - "GOV-04": [ - "1102" + "PRI-01.6": [ + "Section 55(3)", + "Section 55(3)(a)", + "Section 55(3)(b)", + "Section 55(3)(c)", + "Section 55(3)(d)", + "Section 56(1)", + "Section 56(2)", + "Section 56(3)", + "Section 57(1)", + "Section 57(1)(a)", + "Section 57(1)(b)", + "Section 57(2)", + "Section 57(3)", + "Section 57(4)", + "Section 57(4)(a)", + "Section 57(4)(b)", + "Section 57(4)(c)", + "Section 57(4)(d)", + "Section 57(5)", + "Section 66(1)", + "Section 66(2)", + "Section 66(2)(a)", + "Section 66(2)(b)", + "Section 66(2)(c)", + "Section 66(2)(d)", + "Section 66(3)" ], - "AST-01": [ - "1300" + "PRI-01.11": [ + "Section 45(4)", + "Section 45(4)(a)", + "Section 45(4)(b)", + "Section 45(4)(c)", + "Section 45(4)(e)", + "Section 47(2)" ], - "AST-01.4": [ - "2410" + "PRI-02": [ + "Section 44(1)", + "Section 44(1)(a)", + "Section 44(1)(b)", + "Section 44(1)(c)", + "Section 44(1)(d)", + "Section 44(1)(d)(i)", + "Section 44(1)(d)(ii)", + "Section 44(1)(d)(iii)", + "Section 44(1)(e)", + "Section 44(2)", + "Section 44(2)(b)", + "Section 44(2)(c)", + "Section 44(2)(d)", + "Section 44(3)", + "Section 69(4)" ], - "AST-02": [ - "2310" + "PRI-03.4": [ + "Section 47(4)" ], - "AST-02.2": [ - "3204" + "PRI-04.1": [ + "Section 44(2)(a)" ], - "AST-02.9": [ - "2423" + "PRI-05.2": [ + "Section 46(1)", + "Section 47(3)" ], - "AST-04": [ - "1203" + "PRI-05.4": [ + "Section 44(4)", + "Section 44(4)(a)", + "Section 44(4)(b)", + "Section 44(4)(c)", + "Section 44(4)(e)", + "Section 47(4)" ], - "AST-09": [ - "2323" + "PRI-06": [ + "Section 45(1)", + "Section 45(1)(a)", + "Section 45(1)(b)", + "Section 45(2)", + "Section 45(2)(a)", + "Section 45(2)(b)", + "Section 45(2)(c)", + "Section 45(2)(d)", + "Section 45(2)(e)", + "Section 45(2)(e)(i)", + "Section 45(2)(e)(ii)", + "Section 45(2)(f)", + "Section 45(2)(g)", + "Section 45(2A)" ], - "AST-16": [ - "2322" + "PRI-06.1": [ + "Section 46(1)", + "Section 46(2)", + "Section 46(3)", + "Section 46(4)" ], - "AST-21": [ - "2412" + "PRI-06.2": [ + "Section 48(1)", + "Section 48(1)(a)", + "Section 48(1)(b)", + "Section 48(1)(b)(i)", + "Section 48(1)(b)(ii)", + "Section 48(1)(b)(iii)", + "Section 48(1)(b)(iv)", + "Section 48(2)", + "Section 48(2)(a)", + "Section 48(2)(b)", + "Section 48(3)", + "Section 48(3)(a)", + "Section 48(3)(b)", + "Section 48(3)(c)", + "Section 48(3)(e)", + "Section 48(4)", + "Section 48(4)(a)", + "Section 48(4)(b)", + "Section 48(4)(c)", + "Section 48(4)(d)", + "Section 48(5)", + "Section 48(6)", + "Section 48(6)(a)", + "Section 48(6)(b)", + "Section 48(7)", + "Section 48(9)", + "Section 48(9)(a)", + "Section 48(9)(b)", + "Section 48(10)" ], - "BCD-01": [ - "2501", - "2502", - "4100" + "PRI-06.4": [ + "Section 45(3)", + "Section 45(3)(a)", + "Section 45(3)(b)", + "Section 45(5)", + "Section 45(5)(a)", + "Section 45(5)(b)", + "Section 45(5)(c)", + "Section 45(5)(d)", + "Section 45(5)(e)", + "Section 52(6)", + "Section 53(6)", + "Section 53(6)(a)", + "Section 53(6)(b)", + "Section 53(7)", + "Section 53(7)(a)", + "Section 53(7)(b)" ], - "BCD-11": [ - "2504" + "PRI-06.5": [ + "Section 47(1)", + "Section 47(1)(a)", + "Section 47(1)(b)" ], - "BCD-11.1": [ - "2504" + "PRI-06.7": [ + "Section 52(1)", + "Section 52(2)", + "Section 52(3)", + "Section 52(5)" ], - "CHG-01": [ - "2404" + "PRI-06.8": [ + "Section 52(4)", + "Section 52(4)(a)", + "Section 52(4)(b)" ], - "CHG-04": [ - "2422" + "PRI-07.1": [ + "Section 59(1)", + "Section 59(2)", + "Section 59(2)(a)", + "Section 59(2)(b)", + "Section 59(3)", + "Section 59(4)", + "Section 59(5)", + "Section 59(5)(a)", + "Section 59(5)(b)", + "Section 59(5)(c)", + "Section 59(5)(d)", + "Section 59(6)", + "Section 59(6)(a)", + "Section 59(6)(b)", + "Section 59(6)(c)", + "Section 59(6)(d)", + "Section 59(6)(d)(i)", + "Section 59(6)(d)(ii)", + "Section 59(6)(e)", + "Section 59(6)(f)", + "Section 59(7)", + "Section 59(7A)", + "Section 59(8)", + "Section 60", + "Section 60(a)", + "Section 60(b)", + "Section 63" ], - "CPL-01": [ - "0001", - "2314" + "PRI-07.2": [ + "Section 58(1)", + "Section 58(2)", + "Section 58(3)" ], - "CFG-02": [ - "2204", - "2310", - "2400", - "2401", - "2418" + "PRI-07.4": [ + "Section 53(1)", + "Section 53(1)(a)", + "Section 53(1)(b)", + "Section 53(2)", + "Section 53(3)", + "Section 53(4)", + "Section 53(4A)", + "Section 53(4A)(a)", + "Section 53(4A)(b)", + "Section 53(5)" ], - "CFG-02.1": [ - "2418" + "PRI-14": [ + "Section 61(1)", + "Section 61(2)", + "Section 61(2)(a)", + "Section 61(2)(b)", + "Section 61(2)(c)", + "Section 61(2)(d)", + "Section 61(2)(e)", + "Section 61(2)(f)", + "Section 61(2)(f)(i)", + "Section 61(2)(f)(ii)", + "Section 61(2)(g)", + "Section 61(2)(h)", + "Section 61(2)(h)(i)", + "Section 61(2)(j)", + "Section 61(2)(k)", + "Section 61(3)", + "Section 61(4)", + "Section 61(4)(a)", + "Section 61(4)(b)", + "Section 61(4)(c)", + "Section 61(4)(d)", + "Section 61(4)(e)", + "Section 61(4)(f)", + "Section 61(5)", + "Section 62(1)", + "Section 62(1)(a)", + "Section 62(1)(b)", + "Section 62(1)(c)", + "Section 62(1)(d)", + "Section 62(1)(e)", + "Section 62(1)(f)", + "Section 62(2)", + "Section 62(2)(a)", + "Section 62(2)(b)", + "Section 62(3)", + "Section 62(3)(a)", + "Section 62(3)(b)", + "Section 62(3)(b)(i)", + "Section 62(3)(b)(ii)", + "Section 62(4)", + "Section 62(4)(a)", + "Section 62(4)(b)", + "Section 62(4)(c)", + "Section 62(4)(d)", + "Section 62(5)" ], - "CFG-02.5": [ - "2312" + "PRI-17": [ + "Section 44(5)", + "Section 44(5)(a)", + "Section 44(5)(b)", + "Section 44(5)(c)", + "Section 44(5)(d)", + "Section 44(5)(e)", + "Section 44(6)" ], - "CFG-02.9": [ - "2418" + "PRI-17.3": [ + "Section 44(7)(a)", + "Section 44(7)(b)", + "Section 45(7)(a)", + "Section 45(7)(b)" + ], + "PRI-19": [ + "Section 50(1)", + "Section 50(1)(a)", + "Section 50(1)(b)", + "Section 50(1)(b)(i)", + "Section 50(1)(b)(ii)", + "Section 50(2)", + "Section 50C(1)", + "Section 50C(1)(a)", + "Section 50C(1)(b)", + "Section 50C(2)", + "Section 50C(2)(a)", + "Section 50C(2)(b)", + "Section 50C(2)(c)", + "Section 50C(2)(d)", + "Section 50C(3)", + "Section 50C(3)(a)", + "Section 50C(3)(b)", + "Section 50C(3)(c)", + "Section 50C(4)", + "Section 50C(4)(a)", + "Section 50C(4)(b)", + "Section 50C(4)(c)", + "Section 50C(4)(d)", + "Section 50C(4)(e)", + "Section 50C(5)" ], - "CFG-03": [ - "2204", - "2507" + "RSK-10": [ + "Section 64(1)", + "Section 64(2)", + "Section 64(3)", + "Section 64(3)(a)", + "Section 64(3)(b)", + "Section 64(3)(c)", + "Section 64(3)(d)", + "Section 64(4)" + ] + }, + "apac-aus-essential-8-2024": { + "AST-02": [ + "ML1-P1", + "ML1-P2", + "ML2-P1", + "ML2-P2", + "ML3-P1", + "ML3-P2" ], - "CFG-03.1": [ - "2507" + "AST-27": [ + "ML2-P4", + "ML3-P4" ], - "CFG-03.3": [ - "2409" + "BCD-01.4": [ + "ML1-P8", + "ML2-P8", + "ML3-P8" ], - "CFG-03.4": [ - "2305" + "BCD-11": [ + "ML1-P8", + "ML2-P8", + "ML3-P8" ], - "MON-01": [ - "2427", - "3100", - "3101" + "BCD-11.2": [ + "ML1-P8", + "ML2-P8", + "ML3-P8" ], - "MON-01.4": [ - "3101" + "BCD-11.5": [ + "ML1-P8", + "ML2-P8", + "ML3-P8" ], - "MON-01.8": [ - "3101" + "BCD-11.9": [ + "ML1-P8", + "ML2-P8", + "ML3-P8" ], - "MON-03.2": [ - "3107" + "BCD-11.10": [ + "ML1-P8", + "ML2-P8", + "ML3-P8" ], - "MON-06": [ - "3108" + "CFG-02": [ + "ML1-P6", + "ML1-P7", + "ML2-P5", + "ML2-P6", + "ML2-P7", + "ML3-P4", + "ML3-P5", + "ML3-P6", + "ML3-P7" ], - "MON-07.1": [ - "2421" + "CFG-02.1": [ + "ML2-P5", + "ML3-P5", + "ML3-P6" ], - "MON-10": [ - "3107" + "CFG-03.2": [ + "ML2-P5", + "ML3-P5" ], - "MON-16": [ - "3200", - "3203" + "CFG-03.3": [ + "ML1-P5", + "ML2-P5", + "ML3-P5" ], - "MON-16.3": [ - "4106" + "MON-02.2": [ + "ML2-P3", + "ML2-P4", + "ML2-P5", + "ML2-P7", + "ML3-P3", + "ML3-P4", + "ML3-P5", + "ML3-P7" ], - "MON-17": [ - "3109" - ], - "MON-17.1": [ - "3101" - ], - "CRY-01": [ - "2304", - "2317", - "2318" - ], - "CRY-03": [ - "2306" - ], - "CRY-05": [ - "2310", - "2317" - ], - "CRY-09": [ - "2319" - ], - "DCH-01": [ - "2300" - ], - "DCH-09": [ - "2323" - ], - "DCH-09.1": [ - "2323" - ], - "DCH-10": [ - "2310" - ], - "DCH-12": [ - "2310" - ], - "DCH-15": [ - "2321" - ], - "END-01": [ - "2317", - "2411" - ], - "END-02": [ - "2411" - ], - "END-04": [ - "2411", - "2426" - ], - "END-04.1": [ - "2426" + "MON-03": [ + "ML2-P3", + "ML2-P5", + "ML3-P3", + "ML3-P5" ], - "END-04.7": [ - "2426" + "MON-03.3": [ + "ML2-P4", + "ML3-P4", + "ML3-P7" ], - "END-08": [ - "2509" + "MON-08": [ + "ML2-P3", + "ML2-P4", + "ML2-P5", + "ML2-P7", + "ML3-P3", + "ML3-P4", + "ML3-P5", + "ML3-P7" ], - "END-10": [ - "2413" + "MON-17": [ + "ML2-P3", + "ML2-P4", + "ML2-P5", + "ML2-P7", + "ML3-P3", + "ML3-P4", + "ML3-P5", + "ML3-P7" ], - "HRS-01": [ - "1300", - "2702" + "IAC-06": [ + "ML1-P3", + "ML2-P3", + "ML3-P3" ], - "HRS-01.1": [ - "2702" + "IAC-06.2": [ + "ML2-P3", + "ML3-P3" ], - "HRS-03": [ - "1102", - "2321", - "3101" + "IAC-06.3": [ + "ML2-P3", + "ML3-P3" ], - "HRS-03.1": [ - "2600", - "2603" + "IAC-08": [ + "ML1-P4", + "ML2-P4", + "ML3-P4" ], - "HRS-04": [ - "2700", - "2701" + "IAC-15.3": [ + "ML2-P4", + "ML3-P4" ], - "HRS-05": [ - "2604" + "IAC-15.9": [ + "ML2-P4", + "ML3-P4" ], - "HRS-05.1": [ - "2604" + "IAC-16": [ + "ML1-P4", + "ML2-P4", + "ML3-P4" ], - "HRS-05.2": [ - "2604" + "IAC-16.4": [ + "ML1-P4", + "ML2-P4", + "ML3-P4" ], - "HRS-05.3": [ - "2604" + "IAC-20.4": [ + "ML3-P4" ], - "HRS-05.5": [ - "2322" + "IAC-21": [ + "ML1-P4", + "ML2-P4", + "ML3-P4" ], - "HRS-11": [ - "2207" + "IAC-21.2": [ + "ML1-P4", + "ML2-P4", + "ML3-P4" ], - "HRS-14": [ - "2311" + "IAC-21.3": [ + "ML1-P4", + "ML2-P4", + "ML3-P4" ], - "HRS-14.1": [ - "2311" + "IRO-02": [ + "ML2-P3", + "ML2-P4", + "ML2-P5", + "ML2-P7", + "ML3-P3", + "ML3-P4", + "ML3-P5", + "ML3-P7" ], - "HRS-15": [ - "2703" + "IRO-10": [ + "ML2-P3", + "ML2-P4", + "ML2-P5", + "ML2-P7", + "ML3-P3", + "ML3-P4", + "ML3-P5", + "ML3-P7" ], - "IAC-01": [ - "2200", - "2210" + "SEA-07.1": [ + "ML3-P2" ], - "IAC-01.1": [ - "1503" + "SEA-22": [ + "ML2-P4", + "ML3-P4" ], - "IAC-01.2": [ - "2200", - "2210", - "2304" + "TDA-17": [ + "ML1-P1", + "ML1-P2", + "ML2-P1", + "ML2-P2", + "ML3-P1", + "ML3-P2" ], - "IAC-01.3": [ - "2217" + "VPM-05": [ + "ML1-P1", + "ML1-P2", + "ML2-P1", + "ML2-P2", + "ML3-P1", + "ML3-P2" ], - "IAC-02": [ - "2218" + "VPM-06": [ + "ML1-P1", + "ML1-P2", + "ML2-P1", + "ML2-P2", + "ML3-P1", + "ML3-P2" ], - "IAC-02.2": [ - "2215" + "VPM-06.1": [ + "ML1-P1", + "ML1-P2", + "ML2-P1", + "ML2-P2", + "ML3-P1", + "ML3-P2" + ] + }, + "apac-aus-privacy-principles-2026": { + "GOV-02": [ + "1.1.3" ], - "IAC-06": [ - "2305", - "2512" + "CPL-01": [ + "1.1.2.a" ], - "IAC-07": [ - "2702" + "CPL-07": [ + "1.1.2.b" ], - "IAC-08": [ - "2200", - "2206", - "2422" + "DCH-03.1": [ + "3.9.2", + "3.9.2.a", + "3.9.2.b", + "3.9.2.c", + "3.9.2.d", + "3.9.2.e", + "3.9.2.f", + "3.9.3", + "3.9.3.a", + "3.9.3.b", + "3.9.3.c" ], - "IAC-10.4": [ - "2213" + "PRI-01.5": [ + "3.8.1", + "3.8.1.a", + "3.8.1.b", + "3.8.2", + "3.8.2.a", + "3.8.2.a.i", + "3.8.2.a.ii", + "3.8.2.b", + "3.8.2.b.i", + "3.8.2.b.ii", + "3.8.2.c", + "3.8.2.d", + "3.8.2.e", + "3.8.2.f", + "3.8.2.f.i", + "3.8.2.f.ii" ], - "IAC-10.8": [ - "2211" + "PRI-01.6": [ + "4.11.1", + "4.11.1.a", + "4.11.1.b" ], - "IAC-11": [ - "2419", - "2420" + "PRI-01.7": [ + "3.6.1" ], - "IAC-15.1": [ - "2218" + "PRI-01.11": [ + "1.1.2", + "2.3.1", + "2.3.2", + "2.3.5", + "2.3.7", + "2.4.1", + "2.4.1.a", + "2.4.1.b", + "2.4.2", + "2.4.3", + "2.4.3.a", + "2.4.3.b", + "2.4.4", + "3.9.1", + "3.9.1.a", + "3.9.1.b", + "5.12.7", + "5.12.8", + "5.12.8.a", + "5.12.8.b" ], - "IAC-21": [ - "2205", - "2206" + "PRI-02": [ + "1.1.3", + "1.1.4", + "1.1.4.a", + "1.1.4.b", + "1.1.4.c", + "1.1.4.d", + "1.1.4.e", + "1.1.4.f", + "1.1.4.g", + "1.1.5", + "1.1.5.a", + "1.1.5.b", + "1.1.6", + "2.5.1", + "2.5.1.a", + "2.5.1.b", + "2.5.2", + "2.5.2.a", + "2.5.2.b", + "2.5.2.b.i", + "2.5.2.b.ii", + "2.5.2.c", + "2.5.2.d", + "2.5.2.e", + "2.5.2.f", + "2.5.2.g", + "2.5.2.h", + "2.5.2.i", + "2.5.2.j" ], - "IAC-22": [ - "2214" + "PRI-02.13": [ + "1.2.1" ], - "IAC-24": [ - "2408" + "PRI-04.1": [ + "2.3.1", + "2.3.2" ], - "IRO-01": [ - "4104" + "PRI-04.2": [ + "2.3.6", + "2.3.6.a", + "2.3.6.a.ii", + "2.3.6.b" ], - "IRO-02": [ - "4104" + "PRI-05": [ + "4.11.2", + "4.11.2.a", + "4.11.2.b", + "4.11.2.c", + "4.11.2.d" ], - "IRO-03": [ - "3201" + "PRI-05.2": [ + "4.10.1", + "4.10.2" ], - "IRO-13": [ - "4200" + "PRI-05.4": [ + "2.3.3", + "2.3.3.a", + "2.3.3.a.i", + "2.3.3.a.ii", + "2.3.3.b", + "2.3.4", + "2.3.4.a", + "2.3.4.b", + "2.3.4.c", + "2.3.4.d", + "2.3.4.d.i", + "2.3.4.d.ii", + "2.3.4.e", + "2.3.4.e.i", + "2.3.4.e.ii", + "3.6.1", + "3.6.1.a", + "3.6.1.b", + "3.6.2", + "3.6.2.a", + "3.6.2.a.i", + "3.6.2.a.ii", + "3.6.2.b", + "3.6.2.c", + "3.6.2.d", + "3.6.2.e", + "3.6.3", + "3.6.4", + "3.6.4.a", + "3.6.4.b", + "3.7.1", + "3.7.2", + "3.7.2.a", + "3.7.2.b", + "3.7.2.c", + "3.7.2.d", + "3.7.3", + "3.7.3.a", + "3.7.3.a.i", + "3.7.3.a.ii", + "3.7.3.b", + "3.7.3.b.i", + "3.7.3.b.ii", + "3.7.3.c", + "3.7.3.d", + "3.7.3.d.i", + "3.7.3.d.ii", + "3.7.3.e", + "3.7.4", + "3.7.5", + "3.7.5.a", + "3.7.5.b", + "3.7.5.c" ], - "IRO-15": [ - "2411" + "PRI-06": [ + "3.7.6", + "3.7.6.a", + "3.7.6.b", + "3.7.6.c", + "3.7.6.d", + "3.7.6.e", + "3.7.7", + "3.7.7.a", + "3.7.7.b", + "5.12.1" ], - "MNT-02": [ - "2511" + "PRI-06.1": [ + "5.13.1", + "5.13.1.a", + "5.13.1.b", + "5.13.1.b.i" ], - "MNT-03": [ - "2511" + "PRI-06.2": [ + "5.13.2", + "5.13.2.a", + "5.13.2.b", + "5.13.3", + "5.13.3.a", + "5.13.3.b", + "5.13.3.c" ], - "MNT-04.2": [ - "2510" + "PRI-06.4": [ + "5.12.3", + "5.12.3.a", + "5.12.3.b", + "5.12.3.c", + "5.12.3.d", + "5.12.3.e", + "5.12.3.f", + "5.12.3.g", + "5.12.3.h", + "5.12.3.h.ii", + "5.12.3.i", + "5.12.3.j", + "5.12.4", + "5.12.4.a", + "5.12.4.a.i", + "5.12.4.a.ii", + "5.12.4.b", + "5.12.5", + "5.12.5.a", + "5.12.5.b", + "5.12.6", + "5.13.4", + "5.13.4.a", + "5.13.5", + "5.13.5.a", + "5.13.5.a.i", + "5.13.5.a.ii", + "5.13.5.b" ], - "MNT-05": [ - "2512" + "PRI-06.8": [ + "1.2.2.a", + "1.2.2.b" ], - "MNT-06.1": [ - "2513" + "PRI-07.4": [ + "5.12.3.h.i" ], - "MDM-01": [ - "2322" + "PRI-12.1": [ + "5.13.1.b.ii" ], - "NET-03": [ - "2427" + "PRI-14.2": [ + "3.6.5" ], - "NET-03.4": [ - "2316" + "PRI-17": [ + "5.12.9", + "5.12.9.a", + "5.12.9.b", + "5.12.9.c", + "5.12.10" + ] + }, + "apac-aus-ism-2026-march": { + "GOV-01": [ + "ISM-0047" ], - "NET-04": [ - "2316", - "2428" + "GOV-01.1": [ + "ISM-0725", + "ISM-1998", + "ISM-1999", + "ISM-2002", + "ISM-2003", + "ISM-2005", + "ISM-2006" ], - "NET-04.1": [ - "2507" + "GOV-01.2": [ + "ISM-0718", + "ISM-1918", + "ISM-2000" ], - "NET-06": [ - "2508" + "GOV-02": [ + "ISM-0047", + "ISM-1478", + "ISM-1551", + "ISM-1602", + "ISM-1784", + "ISM-1785", + "ISM-2074" ], - "NET-07": [ - "2303", - "2411" + "GOV-03": [ + "ISM-0888", + "ISM-1617" ], - "NET-08": [ - "2411" + "GOV-04": [ + "ISM-0714", + "ISM-0717", + "ISM-0720", + "ISM-0724", + "ISM-0725", + "ISM-0726", + "ISM-0731", + "ISM-0732", + "ISM-0733", + "ISM-0734", + "ISM-0735", + "ISM-1997" ], - "NET-09": [ - "2414" + "GOV-05": [ + "ISM-0724" ], - "NET-10": [ - "2315" + "GOV-14": [ + "ISM-2001" ], - "NET-10.3": [ - "2315" + "GOV-15": [ + "ISM-1633", + "ISM-1634", + "ISM-1635", + "ISM-1636" ], - "NET-12": [ - "2305" + "GOV-15.1": [ + "ISM-1634" ], - "NET-14": [ - "2305" + "GOV-15.2": [ + "ISM-1635" ], - "NET-14.2": [ - "2305", - "2306" + "GOV-15.3": [ + "ISM-1636" ], - "NET-14.3": [ - "2307" + "GOV-15.4": [ + "ISM-0027" ], - "NET-14.4": [ - "2417" + "GOV-15.5": [ + "ISM-1526" ], - "NET-14.5": [ - "2305" + "GOV-17": [ + "ISM-1587" ], - "NET-15.1": [ - "2304" + "GOV-21": [ + "ISM-2005" ], - "NET-18": [ - "2411" + "AAT-01": [ + "ISM-2072", + "ISM-2074" ], - "NET-20.4": [ - "2315" + "AAT-03": [ + "ISM-2084" ], - "NET-20.7": [ - "2509" + "AAT-12.1": [ + "ISM-2086", + "ISM-2087" ], - "PES-01": [ - "1500" + "AAT-12.5": [ + "ISM-2088" ], - "PES-02": [ - "1500" + "AAT-12.6": [ + "ISM-2103" ], - "PES-02.1": [ - "1502", - "2422" + "AAT-16.11": [ + "ISM-2089" ], - "PES-03": [ - "1500" + "AAT-17": [ + "ISM-2094" ], - "PES-03.3": [ - "1500" + "AAT-29.2": [ + "ISM-2092" ], - "PES-03.4": [ - "1502" + "AAT-29.24": [ + "ISM-2090", + "ISM-2091" ], - "PES-05": [ - "1500" + "AST-01": [ + "ISM-0285", + "ISM-0286", + "ISM-0289", + "ISM-0290", + "ISM-0591", + "ISM-1457", + "ISM-1480" ], - "PES-05.1": [ - "1500" + "AST-02": [ + "ISM-0336", + "ISM-1643", + "ISM-1807", + "ISM-1966" ], - "PES-06.1": [ - "1503" + "AST-02.2": [ + "ISM-1807" ], - "PES-06.2": [ - "1503" + "AST-02.5": [ + "ISM-0520", + "ISM-1182" ], - "PES-06.6": [ - "1503" + "AST-02.9": [ + "ISM-1493" ], - "PES-07.3": [ - "2704" + "AST-03": [ + "ISM-1071" ], - "PES-08.2": [ - "2704" + "AST-03.2": [ + "ISM-1790", + "ISM-1791", + "ISM-1792", + "ISM-1816" ], - "PES-09": [ - "2704" + "AST-04": [ + "ISM-0516", + "ISM-0518", + "ISM-1645", + "ISM-1646" ], - "PES-11": [ - "2312" + "AST-05": [ + "ISM-0161", + "ISM-0293", + "ISM-1178", + "ISM-1973" ], - "PES-19": [ - "1501" + "AST-05.2": [ + "ISM-1974", + "ISM-1975" ], - "PRI-02": [ - "2407" + "AST-06": [ + "ISM-0161" ], - "RSK-01": [ - "1200" + "AST-09": [ + "ISM-0311", + "ISM-0312", + "ISM-0315", + "ISM-0318", + "ISM-0321", + "ISM-0330", + "ISM-0350", + "ISM-0363", + "ISM-0370", + "ISM-0372", + "ISM-0378", + "ISM-0839", + "ISM-1076", + "ISM-1217", + "ISM-1218", + "ISM-1219", + "ISM-1220", + "ISM-1221", + "ISM-1222", + "ISM-1223", + "ISM-1534", + "ISM-1550", + "ISM-1641", + "ISM-1722", + "ISM-1723", + "ISM-1724", + "ISM-1725", + "ISM-1726", + "ISM-1727", + "ISM-1728", + "ISM-1729", + "ISM-1741", + "ISM-1742" ], - "RSK-03": [ - "1200" + "AST-14.1": [ + "ISM-0233", + "ISM-1199", + "ISM-1200" ], - "RSK-04": [ - "1200", - "1202" + "AST-16": [ + "ISM-1297" ], - "RSK-06": [ - "1200" + "AST-19": [ + "ISM-0558" ], - "RSK-09": [ - "1400" + "AST-20": [ + "ISM-0548", + "ISM-0551", + "ISM-0553", + "ISM-0554", + "ISM-0555", + "ISM-1014", + "ISM-1562" ], - "RSK-09.1": [ - "1400" + "AST-21": [ + "ISM-0549", + "ISM-0551", + "ISM-0555", + "ISM-0556", + "ISM-0558", + "ISM-1014" ], - "SEA-01": [ - "2400" + "AST-22": [ + "ISM-0559", + "ISM-1450" ], - "SEA-01.2": [ - "2500", - "2501" + "AST-23": [ + "ISM-0245", + "ISM-0589", + "ISM-0590", + "ISM-1036", + "ISM-1854", + "ISM-1855" ], - "SEA-18": [ - "2407" + "AST-24": [ + "ISM-1088", + "ISM-1298", + "ISM-1299", + "ISM-1300", + "ISM-1554", + "ISM-1555", + "ISM-1556" ], - "SEA-20": [ - "2421" + "AST-25": [ + "ISM-1300", + "ISM-1556" ], - "OPS-01.1": [ - "1100", - "2100" + "AST-26": [ + "ISM-0042", + "ISM-1380", + "ISM-1385" ], - "SAT-02": [ - "2600", - "2603" + "AST-27": [ + "ISM-1385", + "ISM-1387" ], - "SAT-03": [ - "2321" + "AST-28": [ + "ISM-0393", + "ISM-1243", + "ISM-1255", + "ISM-1256", + "ISM-1268", + "ISM-1269", + "ISM-1270", + "ISM-1271", + "ISM-1272", + "ISM-1273", + "ISM-1274", + "ISM-1275", + "ISM-1276", + "ISM-1277", + "ISM-1278" ], - "SAT-03.6": [ - "2603" + "AST-28.1": [ + "ISM-1245", + "ISM-1246", + "ISM-1247", + "ISM-1249", + "ISM-1250", + "ISM-1260", + "ISM-1263" ], - "TPM-01": [ - "1400" + "AST-30": [ + "ISM-2053" ], - "TPM-03": [ - "1400" + "BCD-01": [ + "ISM-0734" ], - "TPM-05": [ - "1401", - "2323" + "BCD-01.4": [ + "ISM-1810" ], - "TPM-05.2": [ - "1401" + "BCD-02": [ + "ISM-2005" ], - "VPM-01": [ - "2402", - "2405" + "BCD-11": [ + "ISM-1511", + "ISM-1547", + "ISM-1548", + "ISM-1810", + "ISM-1811" ], - "VPM-02": [ - "2402" + "BCD-11.1": [ + "ISM-1515" ], - "VPM-05": [ - "2402", - "2405" + "BCD-11.2": [ + "ISM-1811" ], - "VPM-05.6": [ - "2405" + "BCD-11.9": [ + "ISM-1812", + "ISM-1813", + "ISM-1814" ], - "VPM-05.7": [ - "2405" + "BCD-11.10": [ + "ISM-1814" ], - "VPM-06": [ - "2402" + "BCD-15": [ + "ISM-1789" ], - "VPM-07": [ - "2403" + "CAP-01": [ + "ISM-1579", + "ISM-1580", + "ISM-1581" ], - "WEB-14": [ - "2321" - ] - }, - "emea-gbr-def-stan-05-138-l2-2024": { - "GOV-01.1": [ - "1101", - "1103", - "1202" + "CAP-02": [ + "ISM-1579", + "ISM-1580", + "ISM-1581" ], - "GOV-02": [ - "1100", - "1101", - "2100", - "2101" + "CAP-03": [ + "ISM-1579", + "ISM-1580", + "ISM-1581" ], - "GOV-03": [ - "2100", - "2101" + "CAP-05": [ + "ISM-1579" ], - "GOV-04": [ - "1102", - "1103" + "CHG-01": [ + "ISM-1211" ], - "GOV-04.1": [ - "1101", - "1103" + "CHG-02": [ + "ISM-1211" ], - "GOV-04.2": [ - "1103" + "CHG-04": [ + "ISM-1823" ], - "AST-01": [ - "1300", - "1301", - "2202" + "CHG-04.2": [ + "ISM-1796" ], - "AST-01.4": [ - "2410" + "CHG-04.5": [ + "ISM-0405" ], - "AST-02": [ - "1301", - "2202", - "2310" + "CLD-01": [ + "ISM-1437", + "ISM-1529", + "ISM-1579", + "ISM-1580", + "ISM-1581" ], - "AST-02.2": [ - "3204" + "CLD-03": [ + "ISM-1385", + "ISM-1750" ], - "AST-02.4": [ - "2202" + "CLD-06": [ + "ISM-1529" ], - "AST-02.9": [ - "1301", - "2423" + "CLD-09": [ + "ISM-1572" ], - "AST-04": [ - "1203", - "2301" + "CLD-12": [ + "ISM-1438", + "ISM-1439" ], - "AST-09": [ - "2323" + "CPL-01": [ + "ISM-0078", + "ISM-0854" ], - "AST-16": [ - "2322" + "CPL-03.1": [ + "ISM-0100" ], - "AST-21": [ - "2412" + "CFG-01": [ + "ISM-0912" ], - "BCD-01": [ - "2501", - "4100" + "CFG-02": [ + "ISM-0341", + "ISM-0343", + "ISM-0345", + "ISM-0380", + "ISM-0383", + "ISM-0567", + "ISM-1316", + "ISM-1318", + "ISM-1319", + "ISM-1321", + "ISM-1406", + "ISM-1407", + "ISM-1408", + "ISM-1409", + "ISM-1418", + "ISM-1491", + "ISM-1492", + "ISM-1562", + "ISM-1584", + "ISM-1604", + "ISM-1608", + "ISM-1621", + "ISM-1622", + "ISM-1623", + "ISM-1624", + "ISM-1654", + "ISM-1655", + "ISM-1710", + "ISM-1745", + "ISM-1823", + "ISM-1824", + "ISM-1825", + "ISM-1828", + "ISM-1829", + "ISM-1830", + "ISM-1836", + "ISM-1838", + "ISM-1839", + "ISM-1840", + "ISM-1841", + "ISM-1844", + "ISM-1846", + "ISM-1858", + "ISM-1859", + "ISM-1860", + "ISM-1861", + "ISM-1870", + "ISM-1871", + "ISM-1886", + "ISM-1887", + "ISM-1888", + "ISM-1890", + "ISM-1891", + "ISM-1896", + "ISM-1897", + "ISM-1913", + "ISM-1914", + "ISM-1915", + "ISM-1916", + "ISM-1928", + "ISM-1929", + "ISM-1930", + "ISM-1931", + "ISM-1932", + "ISM-1933", + "ISM-1934", + "ISM-1935", + "ISM-1936", + "ISM-1938", + "ISM-1943", + "ISM-1944", + "ISM-1945", + "ISM-1946", + "ISM-1947", + "ISM-1948", + "ISM-1949", + "ISM-1950", + "ISM-1951", + "ISM-1952", + "ISM-1953", + "ISM-1954", + "ISM-1955", + "ISM-1956", + "ISM-1957", + "ISM-1958", + "ISM-1962", + "ISM-1980", + "ISM-1984", + "ISM-2010", + "ISM-2012", + "ISM-2047", + "ISM-2049", + "ISM-2079", + "ISM-2080", + "ISM-2081", + "ISM-2096", + "ISM-2097", + "ISM-2098" ], - "BCD-04": [ - "2503" + "CFG-02.1": [ + "ISM-1407", + "ISM-1588" ], - "BCD-11": [ - "2505" + "CFG-02.3": [ + "ISM-1510" ], - "BCD-11.1": [ - "2505" + "CFG-02.5": [ + "ISM-0534", + "ISM-1656", + "ISM-1657", + "ISM-1658", + "ISM-1659", + "ISM-1667", + "ISM-1668", + "ISM-1669", + "ISM-1670", + "ISM-1671", + "ISM-1672", + "ISM-1673", + "ISM-1674", + "ISM-1675", + "ISM-1676", + "ISM-1748", + "ISM-1749", + "ISM-1800", + "ISM-1867", + "ISM-1868" ], - "BCD-11.2": [ - "2505" + "CFG-03": [ + "ISM-0385", + "ISM-1006", + "ISM-1311", + "ISM-1312", + "ISM-1392", + "ISM-1479", + "ISM-1487", + "ISM-1488", + "ISM-1489", + "ISM-1621" ], - "BCD-11.4": [ - "2506" + "CFG-03.3": [ + "ISM-0843", + "ISM-0846", + "ISM-1235", + "ISM-1544" ], - "BCD-11.5": [ - "2505" + "CFG-03.4": [ + "ISM-0705" ], - "BCD-11.6": [ - "2506" + "CFG-04.2": [ + "ISM-0824", + "ISM-1235", + "ISM-1412", + "ISM-1470", + "ISM-1485", + "ISM-1486", + "ISM-1542", + "ISM-1585", + "ISM-1601", + "ISM-1654", + "ISM-1655" ], - "CHG-01": [ - "2404" + "CFG-05": [ + "ISM-0382", + "ISM-1592", + "ISM-1655" ], - "CHG-04": [ - "2422" + "CFG-05.2": [ + "ISM-0382", + "ISM-1592" ], - "CPL-01": [ - "0001", - "0002", - "2314" + "CFG-06": [ + "ISM-0843", + "ISM-0846", + "ISM-0955", + "ISM-1392", + "ISM-1471", + "ISM-1490", + "ISM-1544", + "ISM-1582" ], - "CPL-02": [ - "1206" + "CFG-06.1": [ + "ISM-0843", + "ISM-0846", + "ISM-0955", + "ISM-1392", + "ISM-1471", + "ISM-1490", + "ISM-1544", + "ISM-1582" ], - "CPL-02.2": [ - "1206" + "CFG-09": [ + "ISM-2023" ], - "CPL-03.2": [ - "1206" + "CFG-09.1": [ + "ISM-2029" ], - "CFG-02": [ - "2204", - "2310", - "2400", - "2401", - "2418" + "CFG-09.2": [ + "ISM-2026", + "ISM-2027", + "ISM-2030" ], - "CFG-02.1": [ - "2418" + "CFG-09.3": [ + "ISM-2024" ], - "CFG-02.5": [ - "2312" + "MON-01": [ + "ISM-0109", + "ISM-0120", + "ISM-0580", + "ISM-0660", + "ISM-1163", + "ISM-1294", + "ISM-1586" ], - "CFG-02.9": [ - "2418" + "MON-01.3": [ + "ISM-1906", + "ISM-1907", + "ISM-2015" ], - "CFG-03": [ - "2204", - "2430", - "2507" + "MON-01.4": [ + "ISM-1959" ], - "CFG-03.1": [ - "2430", - "2507" + "MON-01.8": [ + "ISM-0109" ], - "CFG-03.3": [ - "2409" + "MON-01.9": [ + "ISM-0261" ], - "CFG-03.4": [ - "2305" + "MON-01.16": [ + "ISM-0109", + "ISM-0120", + "ISM-0580", + "ISM-0660", + "ISM-1163", + "ISM-1294", + "ISM-1586" ], - "MON-01": [ - "2203", - "2427", - "3100", - "3101", - "3106" + "MON-02": [ + "ISM-0109", + "ISM-1228", + "ISM-1405", + "ISM-1536", + "ISM-1537", + "ISM-1566", + "ISM-1650", + "ISM-1911", + "ISM-1960", + "ISM-1963", + "ISM-1976", + "ISM-1977", + "ISM-1978", + "ISM-1979", + "ISM-1983", + "ISM-1986", + "ISM-1987" ], - "MON-01.4": [ - "3101" + "MON-02.1": [ + "ISM-1228", + "ISM-1961", + "ISM-1964" ], - "MON-01.8": [ - "3101" + "MON-02.2": [ + "ISM-1228" ], - "MON-01.15": [ - "2203" + "MON-02.7": [ + "ISM-0988" ], "MON-03": [ - "3104" + "ISM-0582", + "ISM-0585", + "ISM-1536", + "ISM-1537", + "ISM-1895", + "ISM-2051" + ], + "MON-03.1": [ + "ISM-2052" ], "MON-03.2": [ - "3107" + "ISM-0407" ], "MON-03.3": [ - "2216" + "ISM-1537", + "ISM-1889" ], - "MON-06": [ - "3108" + "MON-03.7": [ + "ISM-1537" ], - "MON-07.1": [ - "2421" + "MON-06": [ + "ISM-1660" ], "MON-08": [ - "3103" + "ISM-1815" + ], + "MON-08.2": [ + "ISM-1985" ], "MON-10": [ - "3103", - "3107" + "ISM-1213", + "ISM-1988", + "ISM-1989" ], - "MON-16": [ - "3200", - "3202", - "3203" + "MON-11.3": [ + "ISM-0120", + "ISM-1091" ], - "MON-16.3": [ - "4106" + "MON-16": [ + "ISM-1660" ], - "MON-17": [ - "3109" + "MON-16.1": [ + "ISM-1625" ], - "MON-17.1": [ - "3101" + "MON-16.4": [ + "ISM-1650" ], "CRY-01": [ - "2304", - "2317", - "2318" - ], + "ISM-0142", + "ISM-0457", + "ISM-0460", + "ISM-0471", + "ISM-0472", + "ISM-0474", + "ISM-0475", + "ISM-0476", + "ISM-0477", + "ISM-0479", + "ISM-0481", + "ISM-0499", + "ISM-0501", + "ISM-0994", + "ISM-0999", + "ISM-1080", + "ISM-1091", + "ISM-1146", + "ISM-1233", + "ISM-1446", + "ISM-1629", + "ISM-1759", + "ISM-1761", + "ISM-1762", + "ISM-1763", + "ISM-1764", + "ISM-1765", + "ISM-1766", + "ISM-1767", + "ISM-1768", + "ISM-1769", + "ISM-1770", + "ISM-1771", + "ISM-1772" + ], + "CRY-01.3": [ + "ISM-0548", + "ISM-0554" + ], "CRY-03": [ - "2302", - "2306" + "ISM-0231", + "ISM-0232", + "ISM-0465", + "ISM-0467", + "ISM-0469", + "ISM-0484", + "ISM-0547", + "ISM-1139", + "ISM-1369", + "ISM-1370", + "ISM-1372", + "ISM-1373", + "ISM-1374", + "ISM-1375", + "ISM-1448", + "ISM-1453", + "ISM-1506", + "ISM-1553", + "ISM-1589", + "ISM-1781" + ], + "CRY-04": [ + "ISM-0677" ], "CRY-05": [ - "2310", - "2317" + "ISM-0459", + "ISM-1080" + ], + "CRY-05.3": [ + "ISM-1080", + "ISM-1277" + ], + "CRY-07": [ + "ISM-1314", + "ISM-1332" + ], + "CRY-08": [ + "ISM-0485", + "ISM-1449", + "ISM-2050" ], "CRY-09": [ - "2319" + "ISM-0455", + "ISM-0507" + ], + "CRY-09.3": [ + "ISM-0455", + "ISM-0462" ], "DCH-01": [ - "2308" + "ISM-0337", + "ISM-0831", + "ISM-1059", + "ISM-1549", + "ISM-1599" ], "DCH-01.2": [ - "2308" - ], - "DCH-01.4": [ - "2301" + "ISM-1802" ], "DCH-02": [ - "2301" + "ISM-0270", + "ISM-0271", + "ISM-0272", + "ISM-0294", + "ISM-0296", + "ISM-0323", + "ISM-0393" ], - "DCH-03": [ - "2301" + "DCH-02.1": [ + "ISM-0323", + "ISM-0325" ], - "DCH-06": [ - "2308" + "DCH-04": [ + "ISM-0201", + "ISM-0270", + "ISM-0272", + "ISM-0294", + "ISM-0296", + "ISM-0332", + "ISM-0356", + "ISM-0358", + "ISM-0360" ], - "DCH-07": [ - "2302", - "2506" + "DCH-04.1": [ + "ISM-0271" ], - "DCH-07.2": [ - "2302" + "DCH-05.9": [ + "ISM-0325" + ], + "DCH-06.2": [ + "ISM-0336" + ], + "DCH-08": [ + "ISM-0311", + "ISM-0312", + "ISM-0315", + "ISM-0363", + "ISM-0368", + "ISM-0374", + "ISM-0375", + "ISM-0378", + "ISM-0839", + "ISM-0840", + "ISM-1160", + "ISM-1217", + "ISM-1218", + "ISM-1361", + "ISM-1517", + "ISM-1550", + "ISM-1722", + "ISM-1723", + "ISM-1724", + "ISM-1725", + "ISM-1726", + "ISM-1727" ], "DCH-09": [ - "2313", - "2323" + "ISM-0311", + "ISM-0313", + "ISM-0317", + "ISM-0348", + "ISM-0351", + "ISM-0352", + "ISM-0354", + "ISM-0356", + "ISM-0357", + "ISM-0358", + "ISM-0359", + "ISM-0360", + "ISM-0361", + "ISM-0362", + "ISM-0835", + "ISM-0836", + "ISM-0947", + "ISM-1065", + "ISM-1067", + "ISM-1287", + "ISM-1300", + "ISM-1600", + "ISM-1735" ], "DCH-09.1": [ - "2323" + "ISM-0316", + "ISM-0363", + "ISM-0370", + "ISM-0371", + "ISM-0372", + "ISM-0373" + ], + "DCH-09.4": [ + "ISM-1600", + "ISM-1642" ], "DCH-10": [ - "2310" + "ISM-0341", + "ISM-0343" + ], + "DCH-10.1": [ + "ISM-0343" + ], + "DCH-11": [ + "ISM-0325", + "ISM-0330" ], "DCH-12": [ - "2310" + "ISM-1359", + "ISM-1713" ], - "DCH-15": [ - "2321" + "DCH-14": [ + "ISM-0657", + "ISM-0661", + "ISM-0663", + "ISM-0664", + "ISM-0665", + "ISM-0669", + "ISM-0675", + "ISM-1187", + "ISM-1535" ], - "END-01": [ - "2317", - "2411" + "DCH-17": [ + "ISM-0347", + "ISM-0947", + "ISM-1778", + "ISM-1779" ], - "END-02": [ - "2411" + "DCH-18": [ + "ISM-1510" ], - "END-04": [ - "2411", - "2426" + "DCH-18.1": [ + "ISM-2021" ], - "END-04.1": [ - "2426" + "DCH-21": [ + "ISM-0311" ], - "END-04.7": [ - "2426" + "END-04": [ + "ISM-1284", + "ISM-1286", + "ISM-1288", + "ISM-1289", + "ISM-1290", + "ISM-1293", + "ISM-1417", + "ISM-1608", + "ISM-1969" ], - "END-08": [ - "2509" + "END-04.4": [ + "ISM-1284", + "ISM-1286", + "ISM-1288", + "ISM-1289", + "ISM-1293", + "ISM-1417", + "ISM-1608", + "ISM-1782" ], - "END-10": [ - "2413" + "END-05": [ + "ISM-1416" ], - "HRS-01": [ - "1300", - "2702" + "END-07": [ + "ISM-1034", + "ISM-1341", + "ISM-1418" ], - "HRS-01.1": [ - "2702" + "END-14": [ + "ISM-0231" + ], + "END-16": [ + "ISM-1006" ], "HRS-03": [ - "1102", - "2321", - "3101" + "ISM-0717", + "ISM-0720", + "ISM-0724", + "ISM-0725", + "ISM-0726", + "ISM-0731", + "ISM-0732", + "ISM-0733", + "ISM-0734", + "ISM-0735", + "ISM-2035", + "ISM-2036" ], "HRS-03.1": [ - "2600", - "2603" + "ISM-0824" ], "HRS-04": [ - "2700", - "2701" + "ISM-0434" + ], + "HRS-04.1": [ + "ISM-0446", + "ISM-0447" + ], + "HRS-04.2": [ + "ISM-0435" + ], + "HRS-04.3": [ + "ISM-0409", + "ISM-0411", + "ISM-0420", + "ISM-0446", + "ISM-0447", + "ISM-1773" + ], + "HRS-04.4": [ + "ISM-0420" ], "HRS-05": [ - "2604" + "ISM-0258", + "ISM-0824", + "ISM-1146", + "ISM-1865" ], "HRS-05.1": [ - "2604" + "ISM-0820", + "ISM-0821", + "ISM-1864", + "ISM-2095" ], "HRS-05.2": [ - "2604" + "ISM-0229", + "ISM-0230", + "ISM-0233", + "ISM-0235", + "ISM-0236", + "ISM-0240", + "ISM-0264", + "ISM-0267", + "ISM-0588", + "ISM-0824", + "ISM-0931", + "ISM-1078", + "ISM-1196", + "ISM-1198", + "ISM-1199", + "ISM-1200", + "ISM-1562", + "ISM-1644" ], "HRS-05.3": [ - "2604" + "ISM-1866", + "ISM-2075", + "ISM-2095", + "ISM-2099", + "ISM-2100", + "ISM-2101" ], - "HRS-05.5": [ - "2322" - ], - "HRS-11": [ - "2207" + "HRS-05.4": [ + "ISM-2095" ], - "HRS-14": [ - "2311" + "HRS-05.5": [ + "ISM-0229", + "ISM-0230", + "ISM-0240", + "ISM-0701", + "ISM-0705", + "ISM-0866", + "ISM-0870", + "ISM-0871", + "ISM-0874", + "ISM-1082", + "ISM-1083", + "ISM-1084", + "ISM-1145", + "ISM-1196", + "ISM-1198", + "ISM-1199", + "ISM-1200", + "ISM-1366", + "ISM-1866" ], - "HRS-14.1": [ - "2311" + "HRS-08": [ + "ISM-0430" ], - "HRS-15": [ - "2703" + "HRS-09": [ + "ISM-0430" ], "IAC-01": [ - "2200", - "2208", - "2210" + "ISM-1146", + "ISM-1546", + "ISM-2076", + "ISM-2077" ], "IAC-01.1": [ - "1503" + "ISM-0407" ], "IAC-01.2": [ - "2200", - "2210", - "2304" - ], - "IAC-01.3": [ - "2217" + "ISM-2013", + "ISM-2014" ], "IAC-02": [ - "2218" + "ISM-0414", + "ISM-0415", + "ISM-1546" + ], + "IAC-02.1": [ + "ISM-0415", + "ISM-1619" ], "IAC-02.2": [ - "2215" + "ISM-1055", + "ISM-1603" + ], + "IAC-03": [ + "ISM-1583" + ], + "IAC-04": [ + "ISM-1603" ], "IAC-06": [ - "2201", - "2305", - "2512" + "ISM-0974", + "ISM-1173", + "ISM-1401", + "ISM-1504", + "ISM-1505", + "ISM-1559", + "ISM-1560", + "ISM-1561", + "ISM-1679", + "ISM-1680", + "ISM-1681", + "ISM-1682", + "ISM-1683", + "ISM-1685", + "ISM-1872", + "ISM-1873", + "ISM-1874", + "ISM-1892", + "ISM-1893", + "ISM-1894", + "ISM-2011" ], "IAC-07": [ - "2702" + "ISM-0430" + ], + "IAC-07.1": [ + "ISM-0430" + ], + "IAC-07.2": [ + "ISM-0430" ], "IAC-08": [ - "2200", - "2206", - "2422" + "ISM-1746", + "ISM-1852", + "ISM-2092", + "ISM-2093" ], - "IAC-10.4": [ - "2213" + "IAC-10": [ + "ISM-1227", + "ISM-1593", + "ISM-1594", + "ISM-1595" ], - "IAC-10.8": [ - "2211" + "IAC-10.1": [ + "ISM-0417", + "ISM-0421", + "ISM-0422", + "ISM-1557", + "ISM-1558", + "ISM-1596", + "ISM-1795", + "ISM-1980", + "ISM-2079", + "ISM-2080", + "ISM-2081" ], - "IAC-10.11": [ - "2212" + "IAC-10.4": [ + "ISM-2078" ], - "IAC-11": [ - "2419", - "2420" + "IAC-10.5": [ + "ISM-0418", + "ISM-1402", + "ISM-1590", + "ISM-1597", + "ISM-1686", + "ISM-1749" + ], + "IAC-10.8": [ + "ISM-1304", + "ISM-1806", + "ISM-2044" ], "IAC-15": [ - "2424" + "ISM-0441", + "ISM-0443", + "ISM-1832", + "ISM-1834", + "ISM-1845", + "ISM-1940", + "ISM-1941", + "ISM-1942" ], "IAC-15.1": [ - "2218" + "ISM-1649" + ], + "IAC-15.3": [ + "ISM-1404", + "ISM-1648" + ], + "IAC-15.6": [ + "ISM-1591" + ], + "IAC-15.9": [ + "ISM-1610", + "ISM-1611", + "ISM-1612", + "ISM-1613", + "ISM-1614", + "ISM-1615" ], "IAC-16": [ - "2424" + "ISM-0445", + "ISM-0446", + "ISM-0447", + "ISM-1175", + "ISM-1380", + "ISM-1507", + "ISM-1508", + "ISM-1509", + "ISM-1620", + "ISM-1648", + "ISM-1649", + "ISM-1650", + "ISM-1687", + "ISM-1688", + "ISM-1689", + "ISM-1835", + "ISM-1939" ], - "IAC-16.1": [ - "2424" + "IAC-16.4": [ + "ISM-0445", + "ISM-1827", + "ISM-1842" + ], + "IAC-17": [ + "ISM-0405", + "ISM-1647", + "ISM-1648" + ], + "IAC-18": [ + "ISM-0421", + "ISM-0422" + ], + "IAC-20.4": [ + "ISM-1898" ], "IAC-21": [ - "2205", - "2206" + "ISM-0441", + "ISM-0611", + "ISM-1380", + "ISM-1392", + "ISM-1705", + "ISM-1706", + "ISM-1707", + "ISM-1708", + "ISM-1833" + ], + "IAC-21.2": [ + "ISM-1175", + "ISM-1883" ], "IAC-21.5": [ - "2216" + "ISM-1592", + "ISM-2048" ], "IAC-22": [ - "2214" + "ISM-1403" ], "IAC-24": [ - "2408" + "ISM-0428" + ], + "IAC-25": [ + "ISM-0853" + ], + "IAC-28.1": [ + "ISM-0405" ], "IRO-01": [ - "3105", - "4104" + "ISM-0137", + "ISM-0576", + "ISM-1609", + "ISM-1618" ], "IRO-02": [ - "3105", - "4104" + "ISM-0123", + "ISM-0141", + "ISM-0917", + "ISM-1618", + "ISM-1803", + "ISM-1819" ], - "IRO-03": [ - "3201" + "IRO-02.2": [ + "ISM-1625", + "ISM-1626" ], "IRO-04": [ - "4101", - "4102" + "ISM-0043", + "ISM-0576", + "ISM-0917", + "ISM-1784" + ], + "IRO-04.1": [ + "ISM-0133" ], "IRO-06": [ - "4103", - "4105" + "ISM-2006" + ], + "IRO-07": [ + "ISM-0733", + "ISM-1618" ], "IRO-08": [ - "3104" + "ISM-0137", + "ISM-0138", + "ISM-1609", + "ISM-1731", + "ISM-1732" ], - "IRO-13": [ - "4200" + "IRO-09": [ + "ISM-0125", + "ISM-0137", + "ISM-0733", + "ISM-1609", + "ISM-1803" ], - "IRO-15": [ - "2411" + "IRO-10": [ + "ISM-0123", + "ISM-0137", + "ISM-0733", + "ISM-1088", + "ISM-1609", + "ISM-1880", + "ISM-1881" ], - "IAO-01": [ - "1205" + "IRO-10.2": [ + "ISM-0733" ], - "IAO-02": [ - "1205" + "IRO-10.4": [ + "ISM-1569" ], - "IAO-03": [ - "2301" + "IRO-12": [ + "ISM-0133" ], - "IAO-06": [ - "1205" + "IRO-12.3": [ + "ISM-0133" ], - "MNT-02": [ - "2511" + "IRO-12.4": [ + "ISM-0133" ], - "MNT-03": [ - "2511" + "IRO-13": [ + "ISM-1213" ], - "MNT-04.2": [ - "2510" + "IRO-14": [ + "ISM-0140" ], - "MNT-05": [ - "2512" + "IRO-15": [ + "ISM-0651", + "ISM-0652", + "ISM-1389", + "ISM-1970" ], - "MNT-06.1": [ - "2513" + "IAO-01": [ + "ISM-0027", + "ISM-0280", + "ISM-1525" ], - "MDM-01": [ - "2309", - "2322" + "IAO-02": [ + "ISM-0100", + "ISM-1967", + "ISM-1971", + "ISM-1972" ], - "MDM-03": [ - "2309" + "IAO-02.2": [ + "ISM-0100", + "ISM-1137", + "ISM-1570", + "ISM-2019" ], - "NET-03": [ - "2427" + "IAO-02.3": [ + "ISM-0100" ], - "NET-03.4": [ - "2316" + "IAO-02.4": [ + "ISM-1563" ], - "NET-04": [ - "2316", - "2428" + "IAO-03": [ + "ISM-0041", + "ISM-0432", + "ISM-0912", + "ISM-1912", + "ISM-2005" ], - "NET-04.1": [ - "2507" + "IAO-03.2": [ + "ISM-0072", + "ISM-1451", + "ISM-1571", + "ISM-1572", + "ISM-1573", + "ISM-1574", + "ISM-1575" ], - "NET-06": [ - "2508" + "IAO-05": [ + "ISM-1564" ], - "NET-07": [ - "2303", - "2411" + "IAO-07": [ + "ISM-0027", + "ISM-0293", + "ISM-1525", + "ISM-1968" ], - "NET-08": [ - "2411" + "MNT-01": [ + "ISM-0305" ], - "NET-09": [ - "2414" + "MNT-02": [ + "ISM-1079" ], - "NET-10": [ - "2315" + "MNT-06": [ + "ISM-0305", + "ISM-0307" ], - "NET-10.3": [ - "2315" + "MNT-06.1": [ + "ISM-0306" ], - "NET-12": [ - "2305" + "MNT-08": [ + "ISM-0305" ], - "NET-14": [ - "2305" + "MNT-09": [ + "ISM-0310" ], - "NET-14.2": [ - "2305", - "2306" + "MNT-10": [ + "ISM-1598" ], - "NET-14.3": [ - "2307" + "MDM-01": [ + "ISM-0682", + "ISM-0687", + "ISM-0863", + "ISM-0864", + "ISM-0874", + "ISM-1085", + "ISM-1195", + "ISM-1297", + "ISM-1366", + "ISM-1533" ], - "NET-14.4": [ - "2417" + "MDM-03": [ + "ISM-0869" ], - "NET-14.5": [ - "2305" + "MDM-05": [ + "ISM-0702" ], - "NET-15.1": [ - "2304" + "MDM-06": [ + "ISM-0694", + "ISM-1297", + "ISM-1400", + "ISM-1482" ], - "NET-17": [ - "2320" + "NET-01": [ + "ISM-0521", + "ISM-0629", + "ISM-1186", + "ISM-1428", + "ISM-1429", + "ISM-1430", + "ISM-1711", + "ISM-1712", + "ISM-1774", + "ISM-1783" ], - "NET-18": [ - "2411" + "NET-01.1": [ + "ISM-0665" ], - "NET-20.4": [ - "2315" + "NET-02.1": [ + "ISM-1019", + "ISM-1431", + "ISM-1436", + "ISM-1805" ], - "NET-20.7": [ - "2509" + "NET-02.2": [ + "ISM-0536" ], - "PES-01": [ - "1500" + "NET-02.3": [ + "ISM-0597", + "ISM-0610", + "ISM-0626", + "ISM-0635", + "ISM-0670", + "ISM-1287", + "ISM-1521", + "ISM-1522", + "ISM-1523" ], - "PES-02": [ - "1500" + "NET-03": [ + "ISM-0611", + "ISM-0612", + "ISM-0613", + "ISM-0616", + "ISM-0619", + "ISM-0622", + "ISM-0628", + "ISM-0629", + "ISM-0631", + "ISM-0634", + "ISM-0637", + "ISM-0639", + "ISM-1037", + "ISM-1192", + "ISM-1284", + "ISM-1286", + "ISM-1287", + "ISM-1288", + "ISM-1289", + "ISM-1293", + "ISM-1389", + "ISM-1427", + "ISM-1520", + "ISM-1521", + "ISM-1522", + "ISM-1528" ], - "PES-02.1": [ - "1502", - "2422" + "NET-03.1": [ + "ISM-1314" ], - "PES-03": [ - "1500" + "NET-03.2": [ + "ISM-0546", + "ISM-1562" ], - "PES-03.3": [ - "1500" + "NET-04": [ + "ISM-0643", + "ISM-0645", + "ISM-1157", + "ISM-1158", + "ISM-1386" ], - "PES-03.4": [ - "1502" + "NET-04.1": [ + "ISM-2068" ], - "PES-05": [ - "1500" + "NET-06": [ + "ISM-1181", + "ISM-1269", + "ISM-1270", + "ISM-1271", + "ISM-1577", + "ISM-1750" ], - "PES-05.1": [ - "1500" + "NET-06.1": [ + "ISM-1385", + "ISM-1750" ], - "PES-06.1": [ - "1503" + "NET-06.2": [ + "ISM-0529", + "ISM-0530", + "ISM-0535", + "ISM-1364", + "ISM-1532" ], - "PES-06.2": [ - "1503" + "NET-06.4": [ + "ISM-1385" ], - "PES-06.6": [ - "1503" + "NET-06.5": [ + "ISM-1863" ], - "PES-07.3": [ - "2704" + "NET-06.6": [ + "ISM-1269", + "ISM-1270", + "ISM-1271" ], - "PES-08.2": [ - "2704" + "NET-08": [ + "ISM-1028", + "ISM-1030", + "ISM-1627", + "ISM-1628" ], - "PES-09": [ - "2704" + "NET-08.1": [ + "ISM-0637" ], - "PES-11": [ - "2312" + "NET-08.4": [ + "ISM-1778", + "ISM-1779" ], - "PES-19": [ - "1501" + "NET-10": [ + "ISM-0574", + "ISM-0861", + "ISM-1026", + "ISM-1027", + "ISM-1151", + "ISM-1183", + "ISM-1540", + "ISM-1782", + "ISM-1799", + "ISM-2017" ], - "PRI-02": [ - "2406", - "2407" + "NET-10.3": [ + "ISM-0574", + "ISM-1151", + "ISM-1183", + "ISM-1799" ], - "RSK-01": [ - "1200", - "1201" + "NET-10.4": [ + "ISM-1432" ], - "RSK-03": [ - "1200" + "NET-13": [ + "ISM-0264", + "ISM-0267", + "ISM-0269", + "ISM-0270", + "ISM-0271", + "ISM-0272", + "ISM-0490", + "ISM-0494", + "ISM-0496", + "ISM-0498", + "ISM-0565", + "ISM-0569", + "ISM-0570", + "ISM-0571", + "ISM-0572", + "ISM-0574", + "ISM-0861", + "ISM-0998", + "ISM-0999", + "ISM-1000", + "ISM-1023", + "ISM-1024", + "ISM-1026", + "ISM-1027", + "ISM-1089", + "ISM-1151", + "ISM-1183", + "ISM-1540", + "ISM-1589" ], - "RSK-04": [ - "1200", - "1202" + "NET-14": [ + "ISM-0487", + "ISM-0488", + "ISM-0489" ], - "RSK-04.1": [ - "4201" + "NET-14.8": [ + "ISM-1591" ], - "RSK-06": [ - "1200" + "NET-15": [ + "ISM-0225", + "ISM-0536", + "ISM-1314", + "ISM-1315", + "ISM-1316", + "ISM-1317", + "ISM-1318", + "ISM-1319", + "ISM-1320", + "ISM-1321", + "ISM-1322", + "ISM-1323", + "ISM-1324", + "ISM-1327", + "ISM-1330", + "ISM-1334", + "ISM-1335", + "ISM-1454", + "ISM-1543" ], - "RSK-08": [ - "4201" + "NET-15.4": [ + "ISM-1013", + "ISM-1338" ], - "RSK-09": [ - "1400" + "NET-15.5": [ + "ISM-0829" ], - "RSK-09.1": [ - "1400" + "NET-18": [ + "ISM-0267", + "ISM-0649", + "ISM-0659", + "ISM-0958", + "ISM-0961", + "ISM-0963", + "ISM-1171", + "ISM-1234", + "ISM-1236", + "ISM-1237", + "ISM-1275", + "ISM-1287", + "ISM-1293", + "ISM-1502", + "ISM-1524", + "ISM-1965" ], - "RSK-12": [ - "2601" + "NET-18.1": [ + "ISM-0260", + "ISM-0570", + "ISM-1237" ], - "SEA-01": [ - "2400" + "NET-18.2": [ + "ISM-0263" ], - "SEA-01.2": [ - "2500", - "2501" + "NET-20.4": [ + "ISM-1540" ], - "SEA-05": [ - "2416" + "NET-20.7": [ + "ISM-0567" ], - "SEA-18": [ - "2406", - "2407" + "PES-01": [ + "ISM-0810" ], - "SEA-20": [ - "2421" + "PES-03": [ + "ISM-1296" ], - "OPS-01.1": [ - "1100", - "2100", - "2101" + "PES-03.4": [ + "ISM-0813", + "ISM-1053", + "ISM-1074", + "ISM-1530" ], - "SAT-02": [ - "2600", - "2602", - "2603" + "PES-04.1": [ + "ISM-0164" ], - "SAT-02.1": [ - "2605" + "PES-06": [ + "ISM-0164" ], - "SAT-02.2": [ - "2602" + "PES-06.3": [ + "ISM-0164" ], - "SAT-03": [ - "2321", - "2602" + "PES-07.3": [ + "ISM-1123" ], - "SAT-03.1": [ - "2605" + "PES-12": [ + "ISM-1644" ], - "SAT-03.2": [ - "2602" + "PES-12.1": [ + "ISM-0181", + "ISM-0187", + "ISM-0194", + "ISM-0195", + "ISM-0198", + "ISM-0201", + "ISM-0206", + "ISM-0208", + "ISM-0211", + "ISM-0213", + "ISM-0216", + "ISM-0217", + "ISM-0218", + "ISM-0926", + "ISM-1095", + "ISM-1096", + "ISM-1098", + "ISM-1100", + "ISM-1101", + "ISM-1102", + "ISM-1103", + "ISM-1105", + "ISM-1107", + "ISM-1109", + "ISM-1111", + "ISM-1112", + "ISM-1114", + "ISM-1115", + "ISM-1116", + "ISM-1119", + "ISM-1122", + "ISM-1130", + "ISM-1133", + "ISM-1164", + "ISM-1216", + "ISM-1639", + "ISM-1640", + "ISM-1718", + "ISM-1719", + "ISM-1720", + "ISM-1721", + "ISM-1820", + "ISM-1821", + "ISM-1822" ], - "SAT-03.3": [ - "2602" + "PES-12.2": [ + "ISM-1036" ], - "SAT-03.6": [ - "2601", - "2602", - "2603", - "3106" + "PES-13": [ + "ISM-0246", + "ISM-0249", + "ISM-0250" ], - "TPM-01": [ - "1400" + "PES-16": [ + "ISM-1107", + "ISM-1216", + "ISM-1217", + "ISM-1599", + "ISM-1718", + "ISM-1719", + "ISM-1720", + "ISM-1721", + "ISM-1728", + "ISM-1729" ], - "TPM-03": [ - "1400" + "PRM-01": [ + "ISM-0720", + "ISM-0732" ], - "TPM-05": [ - "1401", - "2323" + "PRM-01.1": [ + "ISM-0039", + "ISM-0720" ], - "TPM-05.2": [ - "1401" + "PRM-02": [ + "ISM-0732", + "ISM-2004" ], - "THR-03": [ - "3110" + "PRM-02.1": [ + "ISM-2020" ], - "THR-03.1": [ - "3110" + "PRM-03": [ + "ISM-0732", + "ISM-2020" ], - "VPM-01": [ - "2402", - "2405" + "PRM-04": [ + "ISM-1739" ], - "VPM-02": [ - "2402" + "PRM-05": [ + "ISM-0720", + "ISM-1739" ], - "VPM-05": [ - "2402", - "2405" + "PRM-07": [ + "ISM-1526", + "ISM-1739" ], - "VPM-05.6": [ - "2405" + "QTS-03": [ + "ISM-1917", + "ISM-2073" ], - "VPM-05.7": [ - "2405" + "QTS-04.2": [ + "ISM-2082", + "ISM-2083" ], - "VPM-06": [ - "2402" + "QTS-06.3": [ + "ISM-1990", + "ISM-1991", + "ISM-1992", + "ISM-1993", + "ISM-1994", + "ISM-1995" ], - "VPM-07": [ - "2403" + "QTS-06.9": [ + "ISM-1996" ], - "WEB-14": [ - "2321" - ] - }, - "emea-gbr-def-stan-05-138-l3-2024": { - "GOV-01.1": [ - "1101", - "1103", - "1202" + "RSK-01": [ + "ISM-0726" ], - "GOV-02": [ - "1100", - "1101", - "2100", - "2101" + "RSK-03": [ + "ISM-1526" ], - "GOV-03": [ - "2100", - "2101" + "RSK-04": [ + "ISM-1203" ], - "GOV-04": [ - "1102", - "1103" + "RSK-06.2": [ + "ISM-0009", + "ISM-1809" ], - "GOV-04.1": [ - "1101", - "1103" + "RSK-09": [ + "ISM-0731", + "ISM-1567", + "ISM-1785" ], - "GOV-04.2": [ - "1103" + "RSK-09.1": [ + "ISM-1452", + "ISM-1567" ], - "AST-01": [ - "1300", - "1301", - "2202" + "SEA-01": [ + "ISM-1739", + "ISM-1743", + "ISM-1926", + "ISM-1927" ], - "AST-01.4": [ - "2410" + "SEA-02": [ + "ISM-1739", + "ISM-1743" ], - "AST-02": [ - "1301", - "2202", - "2310" + "SEA-03": [ + "ISM-1739", + "ISM-1743" ], - "AST-02.2": [ - "3204" + "SEA-13.1": [ + "ISM-1460", + "ISM-1461", + "ISM-1604", + "ISM-1605", + "ISM-1606", + "ISM-1607" ], - "AST-02.4": [ - "2202" + "SEA-18": [ + "ISM-0408" ], - "AST-02.9": [ - "1301", - "2423" + "SEA-18.1": [ + "ISM-0408" ], - "AST-04": [ - "1203", - "2301" + "SEA-18.2": [ + "ISM-0408" ], - "AST-09": [ - "2323" + "SEA-20": [ + "ISM-0988" ], - "AST-16": [ - "2322" + "SEA-22": [ + "ISM-1687" ], - "AST-21": [ - "2412" + "SAT-01": [ + "ISM-0252", + "ISM-0720", + "ISM-0735", + "ISM-2022" ], - "BCD-01": [ - "2501", - "4100" + "SAT-02": [ + "ISM-0252", + "ISM-0824", + "ISM-1146", + "ISM-1740" ], - "BCD-04": [ - "2503" + "SAT-02.2": [ + "ISM-0817", + "ISM-2071" ], - "BCD-11": [ - "2505" + "SAT-03": [ + "ISM-1146", + "ISM-1565", + "ISM-1740" ], - "BCD-11.1": [ - "2505" + "SAT-03.2": [ + "ISM-0817", + "ISM-0824", + "ISM-1740" ], - "BCD-11.2": [ - "2505" + "SAT-03.3": [ + "ISM-0831", + "ISM-1059" ], - "BCD-11.4": [ - "2506" + "SAT-03.5": [ + "ISM-1565" ], - "BCD-11.5": [ - "2505" + "SAT-03.8": [ + "ISM-1780" ], - "BCD-11.6": [ - "2506" + "TDA-01": [ + "ISM-0938", + "ISM-1780" ], - "BCD-12": [ - "4202" + "TDA-01.1": [ + "ISM-1796", + "ISM-1797", + "ISM-1798" ], - "BCD-12.2": [ - "4202" + "TDA-02.4": [ + "ISM-1798" ], - "CHG-01": [ - "2404" + "TDA-04": [ + "ISM-1798" ], - "CHG-04": [ - "2422" + "TDA-04.1": [ + "ISM-1798" ], - "CPL-01": [ - "0001", - "0002", - "2314" + "TDA-04.2": [ + "ISM-1730", + "ISM-2054", + "ISM-2056" ], - "CPL-02": [ - "1206" + "TDA-05": [ + "ISM-2033", + "ISM-2043" ], - "CPL-02.2": [ - "1206" + "TDA-06": [ + "ISM-0401", + "ISM-1239", + "ISM-1419", + "ISM-1552", + "ISM-1849", + "ISM-1922", + "ISM-2032", + "ISM-2035", + "ISM-2041", + "ISM-2045", + "ISM-2063", + "ISM-2064", + "ISM-2065", + "ISM-2066", + "ISM-2067" ], - "CPL-03.2": [ - "1206" + "TDA-06.2": [ + "ISM-1238", + "ISM-2039" ], - "CFG-02": [ - "2204", - "2310", - "2400", - "2401", - "2418" + "TDA-06.3": [ + "ISM-2025", + "ISM-2034", + "ISM-2102" ], - "CFG-02.1": [ - "2418" + "TDA-06.4": [ + "ISM-2031" ], - "CFG-02.2": [ - "2415" + "TDA-06.6": [ + "ISM-1909" ], - "CFG-02.5": [ - "2312" + "TDA-06.7": [ + "ISM-2040", + "ISM-2041" ], - "CFG-02.9": [ - "2418" + "TDA-07": [ + "ISM-0400", + "ISM-1419" ], - "CFG-03": [ - "2204", - "2430", - "2507" + "TDA-08": [ + "ISM-0400", + "ISM-1273", + "ISM-1274" ], - "CFG-03.1": [ - "2430", - "2507" + "TDA-09": [ + "ISM-0402", + "ISM-1754", + "ISM-1850", + "ISM-1851", + "ISM-2057", + "ISM-2060", + "ISM-2061", + "ISM-2062" ], - "CFG-03.3": [ - "2409" + "TDA-09.2": [ + "ISM-0402", + "ISM-2028" ], - "CFG-03.4": [ - "2305" + "TDA-09.3": [ + "ISM-0402", + "ISM-2028" ], - "MON-01": [ - "2203", - "2427", - "3100", - "3102", - "3106" + "TDA-09.4": [ + "ISM-0402", + "ISM-2057" ], - "MON-01.2": [ - "3102" + "TDA-09.5": [ + "ISM-0402" ], - "MON-01.8": [ - "3102" + "TDA-09.6": [ + "ISM-0383", + "ISM-2042", + "ISM-2044" ], - "MON-01.15": [ - "2203" + "TDA-10": [ + "ISM-1420" ], - "MON-03": [ - "3104" + "TDA-10.1": [ + "ISM-0402" ], - "MON-03.2": [ - "3107" + "TDA-11": [ + "ISM-1790", + "ISM-1791", + "ISM-1792" ], - "MON-03.3": [ - "2216" + "TDA-13.1": [ + "ISM-2038" ], - "MON-06": [ - "3108" + "TDA-13.2": [ + "ISM-2037" ], - "MON-07.1": [ - "2421" + "TDA-17": [ + "ISM-0304", + "ISM-1501", + "ISM-1704", + "ISM-1753", + "ISM-1848", + "ISM-1981", + "ISM-1982" ], - "MON-08": [ - "3103" + "TDA-18": [ + "ISM-2059" ], - "MON-10": [ - "3103", - "3107" + "TDA-20": [ + "ISM-1422" ], - "MON-16": [ - "3200", - "3202", - "3203" + "TPM-01": [ + "ISM-1073", + "ISM-1785" ], - "MON-16.3": [ - "4106" + "TPM-01.1": [ + "ISM-1631", + "ISM-1637", + "ISM-1638", + "ISM-1736", + "ISM-1737", + "ISM-1786" ], - "MON-17": [ - "3109" + "TPM-02": [ + "ISM-1452" ], - "MON-17.1": [ - "3102" + "TPM-03": [ + "ISM-0731", + "ISM-1452", + "ISM-1632", + "ISM-1789" ], - "CRY-01": [ - "2304", - "2317", - "2318" + "TPM-03.1": [ + "ISM-1567", + "ISM-1568", + "ISM-1632", + "ISM-1743", + "ISM-1788", + "ISM-1789" ], - "CRY-03": [ - "2302", - "2306" + "TPM-03.2": [ + "ISM-1567" ], - "CRY-05": [ - "2310", - "2317" + "TPM-04": [ + "ISM-1569" ], - "CRY-09": [ - "2319" + "TPM-04.1": [ + "ISM-1568", + "ISM-1573", + "ISM-1787", + "ISM-1882" ], - "DCH-01": [ - "2308" + "TPM-04.4": [ + "ISM-1572" ], - "DCH-01.2": [ - "2308" + "TPM-05": [ + "ISM-0072", + "ISM-1395", + "ISM-1451", + "ISM-1569", + "ISM-1571", + "ISM-1572", + "ISM-1573", + "ISM-1574", + "ISM-1575", + "ISM-1738" ], - "DCH-01.4": [ - "2301" + "TPM-05.1": [ + "ISM-1576" ], - "DCH-02": [ - "2301" + "TPM-05.5": [ + "ISM-1793" ], - "DCH-03": [ - "2301" + "TPM-05.7": [ + "ISM-1804" ], - "DCH-06": [ - "2308" + "TPM-06": [ + "ISM-1569" ], - "DCH-07": [ - "2302", - "2506" + "TPM-08": [ + "ISM-1793" ], - "DCH-07.2": [ - "2302" + "TPM-10": [ + "ISM-1794" ], - "DCH-09": [ - "2313", - "2323" + "THR-04": [ + "ISM-1625", + "ISM-1626" ], - "DCH-09.1": [ - "2323" + "THR-05": [ + "ISM-1625", + "ISM-1626" ], - "DCH-10": [ - "2310" + "THR-06": [ + "ISM-1616", + "ISM-1717", + "ISM-1755", + "ISM-1756" ], - "DCH-12": [ - "2310" + "THR-07": [ + "ISM-1921" ], - "DCH-15": [ - "2321" + "THR-10": [ + "ISM-1203" ], - "END-01": [ - "2317", - "2411" + "VPM-01": [ + "ISM-1143", + "ISM-1163", + "ISM-1460", + "ISM-1493" ], - "END-02": [ - "2411" + "VPM-02": [ + "ISM-1902", + "ISM-1903", + "ISM-1904" ], - "END-04": [ - "2411", - "2426" + "VPM-03": [ + "ISM-1163" ], - "END-04.1": [ - "2426" + "VPM-04": [ + "ISM-1801" ], - "END-04.7": [ - "2426" + "VPM-04.1": [ + "ISM-1467", + "ISM-1483" ], - "END-06": [ - "2425" + "VPM-05": [ + "ISM-1143", + "ISM-1493", + "ISM-1690", + "ISM-1691", + "ISM-1692", + "ISM-1693", + "ISM-1694", + "ISM-1695", + "ISM-1696", + "ISM-1697", + "ISM-1751", + "ISM-1876", + "ISM-1877", + "ISM-1878", + "ISM-1879", + "ISM-1901" ], - "END-06.1": [ - "2425" + "VPM-05.1": [ + "ISM-0298", + "ISM-0300" ], - "END-08": [ - "2509" + "VPM-05.4": [ + "ISM-1467" ], - "END-10": [ - "2413" + "VPM-06": [ + "ISM-1163", + "ISM-1698", + "ISM-1699", + "ISM-1700", + "ISM-1701", + "ISM-1702", + "ISM-1703", + "ISM-1752", + "ISM-1875", + "ISM-1900" ], - "HRS-01": [ - "1300", - "2702" + "VPM-06.1": [ + "ISM-1808" ], - "HRS-01.1": [ - "2702" + "VPM-07": [ + "ISM-1163" ], - "HRS-03": [ - "1102", - "2321", - "3102" + "WEB-03": [ + "ISM-1862" ], - "HRS-03.1": [ - "2600", - "2603" + "WEB-07": [ + "ISM-0971", + "ISM-1239" ], - "HRS-04": [ - "2700", - "2701" + "WEB-08": [ + "ISM-1239" ], - "HRS-05": [ - "2604" + "WEB-09": [ + "ISM-1240" ], - "HRS-05.1": [ - "2604" + "WEB-10": [ + "ISM-1552" ], - "HRS-05.2": [ - "2604" + "WEB-11": [ + "ISM-1241" ], - "HRS-05.3": [ - "2604" + "WEB-12": [ + "ISM-1424" + ] + }, + "apac-aus-cop-sitc-2020": { + "CPL-01": [ + "5" ], - "HRS-05.5": [ - "2322" + "CFG-02": [ + "6" ], - "HRS-11": [ - "2207" + "CFG-03": [ + "6" ], - "HRS-14": [ - "2311" + "MON-01.4": [ + "7" ], - "HRS-14.1": [ - "2311" + "MON-02.1": [ + "10" ], - "HRS-15": [ - "2703" + "MON-03": [ + "7" ], - "IAC-01": [ - "2200", - "2208", - "2210" + "CRY-03": [ + "7" ], - "IAC-01.1": [ - "1503" + "EMB-04": [ + "13" ], - "IAC-01.2": [ - "2200", - "2209", - "2210", - "2304" + "EMB-05": [ + "8" ], - "IAC-01.3": [ - "2217" + "EMB-06": [ + "13" ], - "IAC-02": [ - "2218" + "EMB-07": [ + "3" ], - "IAC-02.2": [ - "2215" + "EMB-08": [ + "9" ], - "IAC-06": [ - "2201", - "2305", - "2512" + "EMB-09": [ + "10" ], - "IAC-07": [ - "2702" + "EMB-12": [ + "13" ], - "IAC-08": [ - "2200", - "2206", - "2422" + "EMB-13": [ + "13" ], - "IAC-10.4": [ - "2213" + "END-06.6": [ + "8" ], - "IAC-10.8": [ - "2211" + "IAC-06": [ + "1" ], - "IAC-10.11": [ - "2212" + "IAC-10.1": [ + "1" ], - "IAC-11": [ - "2419", - "2420" + "IAC-10.6": [ + "4" ], "IAC-15": [ - "2424" - ], - "IAC-15.1": [ - "2209", - "2218" - ], - "IAC-16": [ - "2424" - ], - "IAC-16.1": [ - "2424" + "1" ], "IAC-21": [ - "2205", - "2206" + "6" ], - "IAC-21.5": [ - "2216" + "NET-14.2": [ + "7" ], - "IAC-22": [ - "2214" + "PRI-01.6": [ + "5" ], - "IAC-24": [ - "2408" + "PRI-01.11": [ + "5" ], - "IRO-01": [ - "3105", - "4104" + "PRI-07.1": [ + "5" ], - "IRO-02": [ - "3105", - "4104" + "TDA-01.1": [ + "11" ], - "IRO-03": [ - "3201" + "TDA-02": [ + "4" ], - "IRO-04": [ - "4101", - "4102" + "TDA-04": [ + "11", + "12" ], - "IRO-06": [ - "4103", - "4105" + "TDA-06": [ + "4", + "6" ], - "IRO-08": [ - "3104" + "TDA-09.6": [ + "4" ], - "IRO-13": [ - "4200" + "TDA-17": [ + "3" ], - "IRO-15": [ - "2411" + "THR-06": [ + "2" ], - "IAO-01": [ - "1205" + "THR-06.1": [ + "2" ], - "IAO-02": [ - "1205" + "VPM-05": [ + "3" ], - "IAO-03": [ - "2301" + "VPM-05.8": [ + "3" + ] + }, + "apac-aus-ps-cps-230-2023": { + "GOV-01": [ + "12(a)", + "16(c)" ], - "IAO-06": [ - "1205" + "GOV-01.1": [ + "16(a)", + "17", + "18", + "24", + "27(a)" ], - "MNT-02": [ - "2511" + "GOV-01.2": [ + "58" ], - "MNT-03": [ - "2511" + "GOV-02": [ + "12(a)", + "47" ], - "MNT-04.2": [ - "2510" + "GOV-04": [ + "23" ], - "MNT-05": [ - "2512" + "GOV-09": [ + "29" ], - "MNT-06.1": [ - "2513" + "GOV-15": [ + "16(c)" ], - "MDM-01": [ - "2309", - "2322" + "GOV-17": [ + "59", + "59(a)", + "59(b)" ], - "MDM-03": [ - "2309" + "AST-01.1": [ + "34(a)" ], - "NET-03": [ - "2427" + "AST-04": [ + "34(a)" ], - "NET-03.4": [ - "2316" + "AST-04.1": [ + "36", + "36(a)", + "36(b)", + "36(c)", + "36(d)", + "37" ], - "NET-04": [ - "2316", - "2428" + "BCD-01": [ + "14", + "15", + "34(b)", + "41" ], - "NET-04.1": [ - "2507" + "BCD-01.4": [ + "38", + "38(a)", + "38(b)" ], - "NET-06": [ - "2508" + "BCD-01.5": [ + "34(d)" ], - "NET-07": [ - "2303", - "2411" + "BCD-01.7": [ + "16(e)", + "34(c)", + "40", + "40(a)", + "40(b)", + "40(c)", + "40(d)", + "40(e)" ], - "NET-08": [ - "2411" + "BCD-02": [ + "15", + "34(a)", + "35" ], - "NET-09": [ - "2414" + "BCD-02.1": [ + "34(e)" ], - "NET-10": [ - "2315" + "BCD-02.2": [ + "34(e)", + "38(c)" ], - "NET-10.3": [ - "2315" + "BCD-02.3": [ + "34(e)", + "38(c)" ], - "NET-12": [ - "2305" + "BCD-04": [ + "27(c)", + "43", + "44" ], - "NET-14": [ - "2305" + "BCD-05": [ + "32", + "45" ], - "NET-14.2": [ - "2305", - "2306" + "BCD-06": [ + "45" ], - "NET-14.3": [ - "2307" + "BCD-06.1": [ + "45" ], - "NET-14.4": [ - "2417" + "CPL-01": [ + "12" ], - "NET-14.5": [ - "2305" + "CPL-01.4": [ + "28" ], - "NET-15.1": [ - "2304" + "CPL-02": [ + "58", + "58(a)", + "58(b)", + "58(c)" ], - "NET-17": [ - "2320" + "CPL-02.1": [ + "46" ], - "NET-18": [ - "2411" + "CPL-03": [ + "30" ], - "NET-20.4": [ - "2315" + "MON-01": [ + "16(d)" ], - "NET-20.7": [ - "2509" + "DCH-02": [ + "36" ], - "PES-01": [ - "1500" + "IRO-01": [ + "16(d)" ], - "PES-02": [ - "1500" + "IRO-06": [ + "27(c)" ], - "PES-02.1": [ - "1502", - "2422" + "IRO-10": [ + "42" ], - "PES-03": [ - "1500" + "IRO-10.2": [ + "33" ], - "PES-03.3": [ - "1500" + "IRO-13": [ + "32" ], - "PES-03.4": [ - "1502" + "PRM-01": [ + "25", + "27(b)" ], - "PES-05": [ - "1500" + "PRM-01.1": [ + "27(b)" ], - "PES-05.1": [ - "1500" + "PRM-01.2": [ + "27(b)" ], - "PES-06.1": [ - "1503" + "PRM-02": [ + "27(b)" ], - "PES-06.2": [ - "1503" + "PRM-02.1": [ + "25", + "27(b)" ], - "PES-06.6": [ - "1503" + "PRM-03": [ + "27(b)" ], - "PES-07.3": [ - "2704" + "PRM-04": [ + "25", + "27(b)" ], - "PES-08.2": [ - "2704" + "PRM-05": [ + "25" ], - "PES-09": [ - "2704" + "PRM-07": [ + "25" ], - "PES-11": [ - "2312" + "RSK-01": [ + "16", + "16(d)" ], - "PES-19": [ - "1501" + "RSK-01.1": [ + "16(b)", + "27" ], - "PRI-02": [ - "2406", - "2407" + "RSK-01.3": [ + "16(b)" ], - "RSK-01": [ - "1200", - "1201", - "1204" + "RSK-01.5": [ + "16(b)" ], "RSK-03": [ - "1200" + "13", + "16(d)" ], "RSK-04": [ - "1200", - "1202", - "1204" + "13", + "16(d)", + "28" ], "RSK-04.1": [ - "4201" + "13", + "32" ], "RSK-06": [ - "1200" + "13", + "31" ], - "RSK-08": [ - "4201" + "RSK-06.1": [ + "16(d)" ], - "RSK-09": [ - "1400" + "RSK-06.4": [ + "31" ], - "RSK-09.1": [ - "1400" + "RSK-08": [ + "26" ], - "RSK-12": [ - "2601" - ], - "SEA-01": [ - "2400" - ], - "SEA-01.2": [ - "2500", - "2501" - ], - "SEA-05": [ - "2416" + "RSK-10": [ + "26" ], - "SEA-18": [ - "2406", - "2407" + "SEA-02.2": [ + "15" ], - "SEA-20": [ - "2421" + "SEA-07.1": [ + "25" ], - "OPS-01.1": [ - "1100", - "2100", - "2101" + "OPS-03": [ + "12(b)" ], - "SAT-02": [ - "2600", - "2602", - "2603" + "TDA-06.2": [ + "27(c)" ], - "SAT-02.1": [ - "2605" + "TPM-01": [ + "12(c)", + "16(f)", + "47", + "48", + "48(a)", + "48(b)", + "48(c)" ], - "SAT-02.2": [ - "2602" + "TPM-01.1": [ + "49", + "51" ], - "SAT-03": [ - "2321", - "2602" + "TPM-02": [ + "15", + "49", + "50", + "50(a)", + "50(b)", + "50(c)", + "50(d)", + "51" ], - "SAT-03.1": [ - "2605" + "TPM-03": [ + "15" ], - "SAT-03.2": [ - "2602" + "TPM-04.1": [ + "15", + "53", + "53(a)", + "53(b)" ], - "SAT-03.3": [ - "2602" + "TPM-05": [ + "15", + "16(f)", + "54", + "54(a)", + "54(b)", + "54(c)", + "54(d)", + "54(e)", + "54(f)", + "55", + "55(a)", + "55(b)", + "55(c)", + "56", + "56(a)", + "56(b)", + "56(c)", + "56(d)" ], - "SAT-03.6": [ - "2601", - "2602", - "2603", - "3106" + "TPM-05.7": [ + "54(g)" ], - "TPM-01": [ - "1400" + "THR-03": [ + "16(d)" ], - "TPM-03": [ - "1400" + "THR-10": [ + "16(d)" + ] + }, + "apac-aus-ps-cps-234-2019": { + "GOV-01": [ + "15", + "17" ], - "TPM-05": [ - "1401", - "2323" + "GOV-01.1": [ + "13" ], - "TPM-05.2": [ - "1401" + "GOV-02": [ + "18" ], - "THR-01": [ - "1204" + "GOV-04": [ + "14" ], - "THR-03": [ - "1204", - "3110" + "GOV-04.1": [ + "14" ], - "THR-03.1": [ - "1204", - "3110" + "GOV-04.2": [ + "14" ], - "VPM-01": [ - "2402", - "2405" + "GOV-15": [ + "21" ], - "VPM-02": [ - "2402" + "GOV-15.1": [ + "21", + "21(a)", + "21(b)", + "21(c)", + "21(d)" ], - "VPM-05": [ - "2402", - "2405" + "CPL-02": [ + "29", + "31" ], - "VPM-05.6": [ - "2405" + "CPL-02.1": [ + "32", + "34", + "34(a)", + "34(b)" ], - "VPM-05.7": [ - "2405" + "CPL-03.1": [ + "30" ], - "VPM-06": [ - "2402" + "CPL-03.2": [ + "33" ], - "VPM-07": [ - "2403" + "DCH-02": [ + "20" ], - "WEB-14": [ - "2321" - ] - }, - "emea-gbr-dpa-1998": { - "DCH-08": [ - "Chapter29-Schedule1-Part1-Principle 5" + "HRS-03": [ + "19" ], - "DCH-18": [ - "Chapter29-Schedule1-Part1-Principle 3 & 5" + "IRO-01": [ + "23" ], - "DCH-22": [ - "Chapter29-Schedule1-Part1-Principle 1" + "IRO-02": [ + "23" ], - "IRO-04.1": [ - "Chapter29-Schedule1-Part1-Principles 7" + "IRO-04": [ + "24", + "25", + "25(a)", + "25(b)" ], - "PRI-01": [ - "Inferred", - "Expectation" + "IRO-06": [ + "26", + "27", + "27(a)", + "27(b)", + "27(c)", + "27(d)", + "27(e)" ], - "PRI-01.2": [ - "Chapter29-Schedule1-Part1-Principles 8" + "IRO-10": [ + "35", + "36" ], - "PRI-02": [ - "Chapter29-Schedule1-Part1-Principles 8" + "IAO-02": [ + "22", + "28" ], - "PRI-05": [ - "Chapter29-Schedule1-Part1-Principle 5" + "TPM-04.1": [ + "16" ], - "PRI-05.1": [ - "Chapter29-Schedule1-Part1-Principle 3" + "THR-01": [ + "17" ], - "PRI-05.4": [ - "Chapter29-Schedule1-Part1-Principle 3" + "VPM-01": [ + "17" ] }, - "apac-aus-essential-8-2024": { - "AST-02": [ - "ML1-P1", - "ML1-P2", - "ML2-P1", - "ML2-P2", - "ML3-P1", - "ML3-P2" + "apac-chn-cybersecurity-law-2017": { + "GOV-12": [ + "Article 28" ], - "AST-27": [ - "ML2-P4", - "ML3-P4" + "GOV-13": [ + "Article 28" ], - "BCD-01.4": [ - "ML1-P8", - "ML2-P8", - "ML3-P8" + "GOV-17": [ + "Article 38", + "Article 54(1)" + ], + "BCD-01": [ + "Article 33", + "Article 34(4)" + ], + "BCD-04": [ + "Article 34(4)" ], "BCD-11": [ - "ML1-P8", - "ML2-P8", - "ML3-P8" + "Article 34(3)" ], - "BCD-11.2": [ - "ML1-P8", - "ML2-P8", - "ML3-P8" + "CPL-01": [ + "Article 9", + "Article 10", + "Article 21", + "Article 23", + "Article 26", + "Article 27", + "Article 34", + "Article 34(5)", + "Article 41", + "Article 47" ], - "BCD-11.5": [ - "ML1-P8", - "ML2-P8", - "ML3-P8" + "CPL-03.1": [ + "Article 38" ], - "BCD-11.9": [ - "ML1-P8", - "ML2-P8", - "ML3-P8" + "CPL-05": [ + "Article 72" ], - "BCD-11.10": [ - "ML1-P8", - "ML2-P8", - "ML3-P8" + "CPL-05.2": [ + "Article 28", + "Article 55", + "Article 56" ], - "CFG-02": [ - "ML1-P6", - "ML1-P7", - "ML2-P5", - "ML2-P6", - "ML2-P7", - "ML3-P4", - "ML3-P5", - "ML3-P6", - "ML3-P7" + "CPL-06": [ + "Article 28", + "Article 29" ], - "CFG-02.1": [ - "ML2-P5", - "ML3-P5", - "ML3-P6" + "DCH-01": [ + "Article 40" ], - "CFG-03.2": [ - "ML2-P5", - "ML3-P5" + "DCH-26": [ + "Article 37" ], - "CFG-03.3": [ - "ML1-P5", - "ML2-P5", - "ML3-P5" + "HRS-01": [ + "Article 34(1)" ], - "MON-02.2": [ - "ML2-P3", - "ML2-P4", - "ML2-P5", - "ML2-P7", - "ML3-P3", - "ML3-P4", - "ML3-P5", - "ML3-P7" + "IAC-01": [ + "Article 40" ], - "MON-03": [ - "ML2-P3", - "ML2-P5", - "ML3-P3", - "ML3-P5" + "IRO-04": [ + "Article 25" ], - "MON-03.3": [ - "ML2-P4", - "ML3-P4", - "ML3-P7" + "IAO-02": [ + "Article 35" ], - "MON-08": [ - "ML2-P3", - "ML2-P4", - "ML2-P5", - "ML2-P7", - "ML3-P3", - "ML3-P4", - "ML3-P5", - "ML3-P7" + "PRI-01.6": [ + "Article 42" ], - "MON-17": [ - "ML2-P3", - "ML2-P4", - "ML2-P5", - "ML2-P7", - "ML3-P3", - "ML3-P4", - "ML3-P5", - "ML3-P7" + "PRI-03": [ + "Article 22" ], - "IAC-06": [ - "ML1-P3", - "ML2-P3", - "ML3-P3" + "PRI-05.4": [ + "Article 41", + "Article 44" ], - "IAC-06.2": [ - "ML2-P3", - "ML3-P3" + "PRI-06.1": [ + "Article 43" ], - "IAC-06.3": [ - "ML2-P3", - "ML3-P3" + "PRI-06.4": [ + "Article 43" ], - "IAC-08": [ - "ML1-P4", - "ML2-P4", - "ML3-P4" + "PRI-06.5": [ + "Article 43" ], - "IAC-15.3": [ - "ML2-P4", - "ML3-P4" + "PRI-16": [ + "Article 24" ], - "IAC-15.9": [ - "ML2-P4", - "ML3-P4" + "SAT-01": [ + "Article 34(2)" ], - "IAC-16": [ - "ML1-P4", - "ML2-P4", - "ML3-P4" + "TDA-01.1": [ + "Article 22", + "Article 46", + "Article 48" ], - "IAC-16.4": [ - "ML1-P4", - "ML2-P4", - "ML3-P4" + "TPM-05": [ + "Article 36" + ] + }, + "apac-chn-data-security-law-2021": { + "GOV-04": [ + "Article 27" ], - "IAC-20.4": [ - "ML3-P4" + "GOV-12": [ + "Article 28" ], - "IAC-21": [ - "ML1-P4", - "ML2-P4", - "ML3-P4" + "GOV-13": [ + "Article 27" ], - "IAC-21.2": [ - "ML1-P4", - "ML2-P4", - "ML3-P4" + "CPL-01": [ + "Article 27", + "Article 32" ], - "IAC-21.3": [ - "ML1-P4", - "ML2-P4", - "ML3-P4" + "CPL-06": [ + "Article 27", + "Article 31" + ], + "MON-01": [ + "Article 29" ], "IRO-02": [ - "ML2-P3", - "ML2-P4", - "ML2-P5", - "ML2-P7", - "ML3-P3", - "ML3-P4", - "ML3-P5", - "ML3-P7" + "Article 29" ], - "IRO-10": [ - "ML2-P3", - "ML2-P4", - "ML2-P5", - "ML2-P7", - "ML3-P3", - "ML3-P4", - "ML3-P5", - "ML3-P7" + "PRI-01.11": [ + "Article 33" ], - "SEA-07.1": [ - "ML3-P2" + "PRI-16": [ + "Article 27", + "Article 33" ], - "SEA-22": [ - "ML2-P4", - "ML3-P4" + "RSK-04": [ + "Article 30" + ] + }, + "apac-chn-csnip-2012": { + "HRS-06.1": [ + "III" ], - "TDA-17": [ - "ML1-P1", - "ML1-P2", - "ML2-P1", - "ML2-P2", - "ML3-P1", - "ML3-P2" + "PRI-01.6": [ + "IV" ], - "VPM-05": [ - "ML1-P1", - "ML1-P2", - "ML2-P1", - "ML2-P2", - "ML3-P1", - "ML3-P2" + "PRI-01.11": [ + "I", + "II", + "VI" ], - "VPM-06": [ - "ML1-P1", - "ML1-P2", - "ML2-P1", - "ML2-P2", - "ML3-P1", - "ML3-P2" + "PRI-05.4": [ + "V" ], - "VPM-06.1": [ - "ML1-P1", - "ML1-P2", - "ML2-P1", - "ML2-P2", - "ML3-P1", - "ML3-P2" + "PRI-06": [ + "VIII" + ], + "PRI-06.5": [ + "VIII" + ], + "PRI-16": [ + "VI" ] }, - "apac-aus-privacy-act-1998": { - "GOV-01": [ - "APP Part 1", - "APP Part 11" + "apac-chn-pipl-2021": { + "GOV-13": [ + "Article 38" ], - "CPL-01": [ - "APP Part 11" + "CPL-06": [ + "Article 38" ], - "CPL-02": [ - "APP Part 11" + "CPL-08": [ + "Article 53" ], - "DCH-01": [ - "APP Part 8", - "APP Part 11" + "DCH-03.1": [ + "Article 25" ], - "DCH-22.1": [ - "APP Part 13" + "DCH-26": [ + "Article 40" + ], + "HRS-06.1": [ + "Article 59" + ], + "IRO-02": [ + "Article 57" + ], + "IRO-10": [ + "Article 57" ], "PRI-01": [ - "Inferred", - "Expectation" + "Article 51" + ], + "PRI-01.4": [ + "Article 52", + "Article 54" + ], + "PRI-01.5": [ + "Article 38" + ], + "PRI-01.6": [ + "Article 9" + ], + "PRI-01.11": [ + "Article 5", + "Article 7", + "Article 10", + "Article 26", + "Article 27" ], "PRI-02": [ - "APP Part 5" + "Article 17", + "Article 18", + "Article 30", + "Article 39" ], "PRI-02.1": [ - "APP Part 3" + "Article 6" ], "PRI-03": [ - "APP Part 3" + "Article 14" ], - "PRI-04": [ - "APP Part 3" + "PRI-03.1": [ + "Article 29" ], - "PRI-04.1": [ - "APP Part 3" + "PRI-03.4": [ + "Article 15" ], - "PRI-05": [ - "APP Part 3", - "APP Part 6" + "PRI-03.5": [ + "Article 16" ], - "PRI-05.1": [ - "APP Part 3" + "PRI-03.6": [ + "Article 49" ], - "PRI-05.2": [ - "APP Part 10" + "PRI-03.13": [ + "Article 31" ], - "PRI-05.3": [ - "APP Part 2" + "PRI-05": [ + "Article 19", + "Article 47" + ], + "PRI-05.2": [ + "Article 8" ], "PRI-05.4": [ - "APP Part 3" + "Article 13", + "Article 28" ], "PRI-06": [ - "APP Part 12" + "Article 44", + "Article 48" ], "PRI-06.1": [ - "APP Part 13" - ], - "PRI-06.2": [ - "APP Part 13" + "Article 46" ], "PRI-06.4": [ - "APP Part 13" - ], - "SEA-01": [ - "APP Part 8", - "APP Part 11" + "Article 50" ], - "SEA-02": [ - "APP Part 8", - "APP Part 11" + "PRI-06.6": [ + "Article 45" ], - "SEA-03": [ - "APP Part 8", - "APP Part 11" - ] - }, - "apac-aus-privacy-principles-2026": { - "GOV-02": [ - "APP 1" + "PRI-07.1": [ + "Article 21" ], - "CLD-09": [ - "APP 8" + "PRI-07.2": [ + "Article 20" ], - "DCH-01": [ - "APP 11" + "PRI-07.4": [ + "Article 50" ], - "DCH-19": [ - "APP 8" + "PRI-07.5": [ + "Article 50" ], - "DCH-22.1": [ - "APP 13" + "PRI-14.1": [ + "Article 22", + "Article 23" ], - "IAC-09.6": [ - "APP 2" + "PRI-16": [ + "Article 38" ], - "PRI-01": [ - "APP 1" + "PRI-19": [ + "Article 24" ], - "PRI-01.3": [ - "APP 1" + "PRI-19.3": [ + "Article 24" ], - "PRI-02": [ - "APP 1", - "APP 5" + "RSK-10": [ + "Article 55", + "Article 56" + ] + }, + "apac-hkg-pdo-2022": { + "CPL-01": [ + "4" ], - "PRI-02.1": [ - "APP 1" + "PRI-01.6": [ + "Schedule 1 - 4(1)", + "Schedule 1 - 4(1)(a)", + "Schedule 1 - 4(1)(b)", + "Schedule 1 - 4(1)(c)", + "Schedule 1 - 4(1)(d)", + "Schedule 1 - 4(1)(e)" ], - "PRI-03": [ - "APP 3" + "PRI-01.11": [ + "28(1)", + "28(2)", + "28(3)", + "28(4)", + "28(4)(II)", + "28(5)", + "28(6)", + "28(6)(a)", + "28(6)(b)", + "29", + "29(a)", + "29(b)", + "Schedule 1 - 1(1)(a)", + "Schedule 1 - 1(1)(b)", + "Schedule 1 - 1(1)(c)", + "Schedule 1 - 1(2)(a)", + "Schedule 1 - 1(2)(b)" ], - "PRI-03.2": [ - "APP 5" + "PRI-02": [ + "35C(2)", + "35C(2)(a)", + "35C(2)(a)(i)", + "35C(2)(a)(ii)", + "35C(2)(b)", + "35C(2)(b)(i)", + "35C(2)(b)(ii)", + "35C(2)(c)", + "35C(3)", + "35C(4)", + "35C(5)", + "35J(2)", + "35J(2)(a)", + "35J(2)(a)(i)", + "35J(2)(a)(ii)", + "35J(2)(b)", + "35J(2)(b)(i)", + "35J(2)(b)(ii)", + "35J(2)(b)(iii)", + "35J(2)(b)(iv)", + "35J(2)(c)", + "35J(3)", + "35J(4)", + "35J(5)", + "35J(5)(a)", + "35J(5)(b)", + "Schedule 1 - 1(3)(a)", + "Schedule 1 - 1(3)(b)(ii)(B)", + "Schedule 1 - 5", + "Schedule 1 - 5(a)", + "Schedule 1 - 5(b)", + "Schedule 1 - 5(c)" ], - "PRI-03.3": [ - "APP 7" + "PRI-03": [ + "35E(1)", + "35E(1)(a)", + "35E(1)(b)", + "35E(1)(b)(i)", + "35E(1)(b)(ii)", + "35E(1)(b)(iii)", + "35E(1)(c)", + "35E(2)", + "35E(2)(a)", + "35E(2)(b)", + "35E(3)", + "35E(4)", + "Schedule 1 - 1(3)(a)(i)", + "Schedule 1 - 1(3)(a)(ii)", + "Schedule 1 - 1(3)(b)", + "Schedule 1 - 1(3)(b)(i)", + "Schedule 1 - 1(3)(b)(i)(A)", + "Schedule 1 - 1(3)(b)(i)(B)", + "Schedule 1 - 1(3)(b)(ii)", + "Schedule 1 - 1(3)(b)(ii)(A)" ], - "PRI-04": [ - "APP 3" + "PRI-03.4": [ + "35G(1)", + "35L(1)", + "35L(1)(a)", + "35L(1)(b)", + "35L(2)", + "35L(3)", + "35L(4)" ], - "PRI-04.1": [ - "APP 3", - "APP 7" + "PRI-03.9": [ + "Schedule 1 - 2(1)(b)(i)", + "Schedule 1 - 2(1)(b)(ii)" ], "PRI-05": [ - "APP 4", - "APP 6" - ], - "PRI-05.1": [ - "APP 6" + "26(1)", + "26(1)(a)", + "26(1)(b)", + "26(2)", + "26(2)(a)", + "26(2)(b)", + "Schedule 1 - 2(2)", + "Schedule 1 - 2(3)" ], "PRI-05.2": [ - "APP 10" + "Schedule 1 - 2(1)(a)", + "Schedule 1 - 2(1)(b)", + "Schedule 1 - 2(1)(c)(i)", + "Schedule 1 - 2(1)(c)(ii)", + "Schedule 1 - 2(1)(c)(ii)(A)", + "Schedule 1 - 2(1)(c)(ii)(B)" ], "PRI-05.4": [ - "APP 6", - "APP 7", - "APP 9" - ], - "PRI-05.7": [ - "APP 9" + "35K(1)", + "35K(1)(a)", + "35K(1)(b)", + "35K(1)(c)", + "35K(2)", + "35K(2)(a)", + "35K(2)(b)", + "35K(2)(c)", + "35K(3)", + "Schedule 1 - 3(1)", + "Schedule 1 - 3(2)", + "Schedule 1 - 3(2)(a)", + "Schedule 1 - 3(2)(a)(i)", + "Schedule 1 - 3(2)(a)(ii)", + "Schedule 1 - 3(2)(a)(iii)", + "Schedule 1 - 3(2)(b)", + "Schedule 1 - 3(2)(c)", + "Schedule 1 - 3(3)" ], "PRI-06": [ - "APP 12" + "18(1)", + "18(1)(a)", + "18(1)(b)", + "18(2)", + "18(3)", + "18(4)", + "18(4)(a)", + "18(4)(b)", + "35G(3)", + "Schedule 1 - 6", + "Schedule 1 - 6(a)", + "Schedule 1 - 6(b)", + "Schedule 1 - 6(b)(i)", + "Schedule 1 - 6(b)(ii)", + "Schedule 1 - 6(b)(iii)", + "Schedule 1 - 6(b)(iv)", + "Schedule 1 - 6(c)", + "Schedule 1 - 6(d)", + "Schedule 1 - 6(e)", + "Schedule 1 - 6(f)", + "Schedule 1 - 6(g)" ], "PRI-06.1": [ - "APP 13" + "22(1)(a)", + "22(1)(b)", + "22(1A)", + "22(2)", + "22(2)(a)", + "22(2)(b)", + "22(3)", + "22(4)", + "23(1)", + "23(1)(a)", + "23(1)(c)(i)", + "23(1)(c)(ii)", + "23(2)", + "23(2)(a)", + "23(2)(a)(i)", + "23(2)(a)(ii)", + "23(2)(b)", + "23(3)", + "23(3)(a)", + "23(3)(b)" ], "PRI-06.2": [ - "APP 13" + "19(3)(b)", + "19(3)(c)", + "19(3)(c)(i)", + "19(3)(c)(i)(A)", + "19(3)(c)(i)(B)", + "19(3)(c)(ii)", + "19(3)(c)(iii)", + "19(3)(c)(iii)(A)", + "19(3)(c)(iii)(B)", + "19(3)(c)(I)", + "19(3)(c)(II)", + "19(3)(c)(iv)", + "19(3)(c)(v)", + "23(1)(b)" ], "PRI-06.4": [ - "APP 12", - "APP 13" - ], - "PRI-07": [ - "APP 7", - "APP 8" + "18(5)", + "18(5)(a)", + "18(5)(b)", + "19(1)", + "19(1)(a)", + "19(1)(a)(i)", + "19(1)(a)(ii)", + "19(1)(b)", + "19(3)", + "19(3)(a)", + "19(3)(a)(i)", + "19(3)(a)(i)(A)", + "19(3)(a)(i)(B)", + "19(3)(a)(ii)", + "19(4)", + "19(4)(a)", + "19(4)(b)", + "19(4)(b)(i)", + "19(4)(b)(ii)", + "19(4)(b)(ii)(A)", + "19(4)(b)(I)", + "19(4)(b)(II)", + "19(4)(b)(III)", + "19(4)(b)(III)(B)", + "21(1)", + "21(1)(a)", + "21(1)(b)", + "21(1)(c)", + "25(1)", + "25(1)(b)" ], "PRI-07.1": [ - "APP 7" + "Schedule 1 - 4(2)" + ], + "PRI-07.4": [ + "24(1)", + "24(1)(a)", + "24(1)(b)", + "24(1)(b)(i)", + "24(1)(b)(ii)", + "24(2)", + "24(3)", + "24(3)(a)", + "24(3)(b)", + "24(3)(c)", + "24(3)(d)", + "24(3)(e)", + "24(4)" + ], + "PRI-07.5": [ + "20(1)", + "20(1)(a)", + "20(1)(a)(i)", + "20(1)(a)(ii)", + "20(1)(a)(ii)(A)", + "20(1)(a)(ii)(B)", + "20(1)(b)", + "20(1)(c)", + "20(2)(a)", + "20(2)(b)", + "20(3)", + "20(3)(a)", + "20(3)(b)", + "20(3)(c)", + "20(3)(c)(i)", + "20(3)(c)(ii)", + "20(3)(c)(iii)", + "20(3)(d)", + "20(3)(e)", + "20(3)(f)", + "25(1)(a)" + ], + "PRI-14": [ + "27(1)", + "27(1)(a)", + "27(1)(b)", + "27(1)(c)", + "27(1)(c)(i)", + "27(1)(c)(ii)", + "27(2)", + "27(2)(a)", + "27(2)(b)", + "27(2)(c)", + "27(2)(d)", + "27(3)", + "27(3)(a)", + "27(3)(b)", + "27(3)(c)", + "27(3)(d)", + "27(4)", + "27(4)(a)", + "27(4)(b)" ] }, - "apac-aus-ism-2024-june": { - "GOV-01": [ - "ISM-0888" - ], + "apac-ind-dpdpa-2023": { "GOV-01.1": [ - "ISM-0725" + "8(6)", + "18(2)", + "23(1)", + "26(a)", + "26(b)", + "26(c)", + "27(1)(a)", + "27(1)(b)", + "27(1)(c)", + "27(1)(d)", + "27(1)(e)", + "27(2)", + "27(3)", + "28(1)", + "28(2)", + "28(3)", + "28(4)", + "28(5)", + "28(6)" ], "GOV-01.2": [ - "ISM-0718" - ], - "GOV-02": [ - "ISM-0047", - "ISM-0888", - "ISM-1478", - "ISM-1551", - "ISM-1602", - "ISM-1784", - "ISM-1785" - ], - "GOV-03": [ - "ISM-1617" + "10(2)(c)(ii)" ], "GOV-04": [ - "ISM-0714", - "ISM-0717", - "ISM-0720", - "ISM-0724", - "ISM-0725", - "ISM-0726", - "ISM-0731", - "ISM-0732", - "ISM-0733", - "ISM-0734", - "ISM-0735" + "19(3)" ], - "GOV-05": [ - "ISM-0724" + "CPL-01": [ + "7(c)", + "7(d)", + "7(e)", + "8(1)", + "8(4)" ], - "GOV-15": [ - "ISM-1633", - "ISM-1634", - "ISM-1635", - "ISM-1636" + "CPL-02.1": [ + "10(2)(b)" ], - "GOV-15.1": [ - "ISM-1634" + "CPL-02.2": [ + "10(2)(c)(ii)" ], - "GOV-15.2": [ - "ISM-1635" + "CPL-03.1": [ + "10(2)(b)" ], - "GOV-15.3": [ - "ISM-1636" + "CPL-07": [ + "13(1)" ], - "GOV-15.4": [ - "ISM-0027" + "CPL-07.1": [ + "13(2)" ], - "GOV-15.5": [ - "ISM-1526" + "DCH-09.3": [ + "8(7)(a)" ], - "GOV-17": [ - "ISM-1587" + "DCH-18": [ + "8(7)(a)", + "8(8)" ], - "AST-01": [ - "ISM-0285", - "ISM-0286", - "ISM-0289", - "ISM-0290", - "ISM-0591", - "ISM-1457", - "ISM-1480" + "HRS-01": [ + "21(1)(a)", + "21(1)(b)", + "21(1)(c)", + "21(1)(d)", + "21(1)(e)", + "21(2)", + "22(1)", + "22(2)", + "22(3)" ], - "AST-02": [ - "ISM-0336", - "ISM-1643", - "ISM-1807" + "HRS-03": [ + "6(9)", + "10(2)(a)(iv)" ], - "AST-02.2": [ - "ISM-1807" + "IRO-04.1": [ + "8(6)" ], - "AST-02.5": [ - "ISM-0520", - "ISM-1182" + "IRO-09": [ + "8(6)" ], - "AST-02.9": [ - "ISM-1493" + "IRO-10": [ + "8(6)" ], - "AST-03": [ - "ISM-1071" + "PRI-01.4": [ + "10(2)(a)", + "10(2)(a)(iv)" ], - "AST-03.2": [ - "ISM-1790", - "ISM-1791", - "ISM-1792" + "PRI-01.6": [ + "8(4)", + "8(5)" ], - "AST-04": [ - "ISM-0516", - "ISM-0518", - "ISM-1645", - "ISM-1646" + "PRI-01.8": [ + "5(3)", + "8(9)", + "8(10)", + "8(11)", + "10(2)", + "10(2)(a)(i)", + "10(2)(a)(ii)", + "10(2)(a)(iii)" ], - "AST-05": [ - "ISM-0161", - "ISM-0293", - "ISM-1178" + "PRI-01.9": [ + "6(8)" ], - "AST-06": [ - "ISM-0161" + "PRI-02": [ + "5(1)(i)", + "5(1)(ii)", + "5(1)(iii)", + "5(2)(a)(i)", + "5(2)(a)(ii)", + "5(2)(a)(iii)", + "6(3)", + "6(10)" ], - "AST-09": [ - "ISM-0311", - "ISM-0312", - "ISM-0315", - "ISM-0318", - "ISM-0321", - "ISM-0330", - "ISM-0350", - "ISM-0363", - "ISM-0370", - "ISM-0372", - "ISM-0378", - "ISM-0839", - "ISM-1076", - "ISM-1217", - "ISM-1218", - "ISM-1219", - "ISM-1220", - "ISM-1221", - "ISM-1222", - "ISM-1223", - "ISM-1225", - "ISM-1534", - "ISM-1550", - "ISM-1641", - "ISM-1722", - "ISM-1723", - "ISM-1724", - "ISM-1725", - "ISM-1726", - "ISM-1727", - "ISM-1728", - "ISM-1729", - "ISM-1741", - "ISM-1742" + "PRI-02.1": [ + "4(2)", + "5(1)(i)", + "5(2)(a)(i)", + "7(a)", + "8(8)(a)" ], - "AST-14.1": [ - "ISM-0233", - "ISM-1199", - "ISM-1200" + "PRI-03": [ + "4(1)(a)", + "6(1)", + "6(3)", + "6(7)", + "6(10)", + "7(a)", + "7(b)(i)", + "8(8)(b)" ], - "AST-16": [ - "ISM-1297" + "PRI-03.4": [ + "5(2)(b)", + "6(4)", + "6(7)", + "8(7)(a)", + "8(8)(b)" ], - "AST-19": [ - "ISM-0558" + "PRI-03.6": [ + "6(7)", + "9(1)", + "14(1)" ], - "AST-20": [ - "ISM-0548", - "ISM-0551", - "ISM-0553", - "ISM-0554", - "ISM-0555", - "ISM-1014", - "ISM-1562" + "PRI-03.9": [ + "5(2)(b)", + "9(2)", + "9(3)" ], - "AST-21": [ - "ISM-0549", - "ISM-0551", - "ISM-0555", - "ISM-0556", - "ISM-0558", - "ISM-1014" + "PRI-03.10": [ + "6(6)" ], - "AST-22": [ - "ISM-0559", - "ISM-1450" + "PRI-04.1": [ + "4(1)(b)" ], - "AST-23": [ - "ISM-0245", - "ISM-0589", - "ISM-0590", - "ISM-1036" + "PRI-05.2": [ + "8(3)", + "8(3)(a)", + "8(3)(b)" ], - "AST-24": [ - "ISM-1088", - "ISM-1298", - "ISM-1299", - "ISM-1300", - "ISM-1554", - "ISM-1555", - "ISM-1556" + "PRI-05.4": [ + "7(f)", + "7(g)", + "7(h)", + "7(i)", + "8(1)" ], - "AST-25": [ - "ISM-1300", - "ISM-1556" + "PRI-06": [ + "11(1)(c)", + "11(2)" ], - "AST-26": [ - "ISM-0042", - "ISM-1380", - "ISM-1385" + "PRI-06.1": [ + "12(1)", + "12(2)(a)", + "12(2)(b)" ], - "AST-27": [ - "ISM-1385", - "ISM-1387" + "PRI-06.5": [ + "8(7)(a)", + "12(1)", + "12(3)" ], - "AST-28": [ - "ISM-0393", - "ISM-1243", - "ISM-1255", - "ISM-1256", - "ISM-1268", - "ISM-1269", - "ISM-1270", - "ISM-1271", - "ISM-1272", - "ISM-1273", - "ISM-1274", - "ISM-1275", - "ISM-1276", - "ISM-1277", - "ISM-1278" + "PRI-06.7": [ + "11(1)(a)" ], - "AST-28.1": [ - "ISM-1245", - "ISM-1246", - "ISM-1247", - "ISM-1249", - "ISM-1250", - "ISM-1260", - "ISM-1263" + "PRI-07": [ + "8(2)" ], - "BCD-01": [ - "ISM-0734" + "PRI-07.1": [ + "8(2)", + "8(7)(b)" ], - "BCD-01.4": [ - "ISM-1810" + "PRI-12.1": [ + "12(2)(c)" ], - "BCD-11": [ - "ISM-0859", - "ISM-0991", - "ISM-1511", - "ISM-1547", - "ISM-1548", - "ISM-1810", - "ISM-1811" + "PRI-14.1": [ + "11(1)(b)" ], - "BCD-11.1": [ - "ISM-1515" + "RSK-10": [ + "10(2)(c)(i)" ], - "BCD-11.2": [ - "ISM-1811" + "TPM-05": [ + "8(7)(b)" ], - "BCD-15": [ - "ISM-1789" + "TPM-05.2": [ + "8(7)(b)" + ] + }, + "apac-ind-privacy-rules-2011": { + "CPL-07": [ + "5(9)" ], - "CAP-01": [ - "ISM-1579", - "ISM-1580", - "ISM-1581" + "DCH-03.1": [ + "6(1)", + "6(2)", + "6(3)" ], - "CAP-02": [ - "ISM-1579", - "ISM-1580", - "ISM-1581" + "PRI-01": [ + "8(1)" ], - "CAP-03": [ - "ISM-1579", - "ISM-1580", - "ISM-1581" + "PRI-01.5": [ + "7" ], - "CAP-05": [ - "ISM-1579" + "PRI-01.6": [ + "5(8)", + "8(2)" ], - "CHG-01": [ - "ISM-1211" + "PRI-01.11": [ + "4(v)", + "8(1)", + "8(4)" ], - "CHG-02": [ - "ISM-1211" + "PRI-02": [ + "4", + "4(i)", + "4(ii)", + "4(iii)", + "4(iv)", + "4(v)", + "5(3)", + "5(3)(a)", + "5(3)(b)", + "5(3)(c)", + "5(3)(d)", + "5(3)(d)(i)", + "5(3)(d)(ii)" ], - "CHG-04.2": [ - "ISM-1796" + "PRI-03": [ + "5(1)", + "5(7)" ], - "CHG-04.5": [ - "ISM-0405" + "PRI-04": [ + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(5)" ], - "CLD-01": [ - "ISM-1437", - "ISM-1529", - "ISM-1579", - "ISM-1580", - "ISM-1581" + "PRI-05": [ + "5(4)" ], - "CLD-03": [ - "ISM-1385", - "ISM-1750" + "PRI-05.2": [ + "5(6)" ], - "CLD-06": [ - "ISM-1529" + "PRI-06.4": [ + "5(9)" ], - "CLD-09": [ - "ISM-1572" + "PRI-07.1": [ + "6(4)" + ] + }, + "apac-ind-sebi-2024": { + "GOV-01": [ + "GV.OC.S1", + "GV.OC.S2", + "PR.IP.S17" ], - "CLD-12": [ - "ISM-1438", - "ISM-1439" + "GOV-01.1": [ + "GV.OV.S2", + "GV.RR.S1", + "GV.RR.S3", + "GV.RR.S4" ], - "CPL-01": [ - "ISM-0078", - "ISM-0854" + "GOV-01.2": [ + "GV.OV.S1" ], - "CPL-03.1": [ - "ISM-0100" + "GOV-02": [ + "GV.PO.S1" ], - "CFG-02": [ - "ISM-0341", - "ISM-0343", - "ISM-0345", - "ISM-0380", - "ISM-0383", - "ISM-0567", - "ISM-1316", - "ISM-1318", - "ISM-1319", - "ISM-1321", - "ISM-1406", - "ISM-1407", - "ISM-1408", - "ISM-1409", - "ISM-1418", - "ISM-1491", - "ISM-1492", - "ISM-1562", - "ISM-1584", - "ISM-1604", - "ISM-1608", - "ISM-1621", - "ISM-1622", - "ISM-1623", - "ISM-1624", - "ISM-1654", - "ISM-1655", - "ISM-1710", - "ISM-1745" + "GOV-02.1": [ + "GV.PO.S3" ], - "CFG-02.1": [ - "ISM-1407", - "ISM-1588" + "GOV-03": [ + "GV.PO.S2", + "GV.PO.S3", + "GV.PO.S4" ], - "CFG-02.3": [ - "ISM-1510" + "GOV-04": [ + "GV.RR.S1", + "GV.RR.S2", + "GV.RR.S3" ], - "CFG-02.5": [ - "ISM-0534", - "ISM-1656", - "ISM-1657", - "ISM-1658", - "ISM-1659", - "ISM-1667", - "ISM-1668", - "ISM-1669", - "ISM-1670", - "ISM-1671", - "ISM-1672", - "ISM-1673", - "ISM-1674", - "ISM-1675", - "ISM-1676", - "ISM-1677", - "ISM-1748", - "ISM-1749", - "ISM-1800" + "GOV-04.1": [ + "GV.RR.S1", + "GV.RR.S2" ], - "CFG-03": [ - "ISM-0385", - "ISM-1006", - "ISM-1311", - "ISM-1312", - "ISM-1392", - "ISM-1479", - "ISM-1487", - "ISM-1488", - "ISM-1489", - "ISM-1621" + "GOV-04.2": [ + "GV.OC.S1", + "GV.PO.S5" ], - "CFG-03.3": [ - "ISM-0843", - "ISM-0846", - "ISM-1235", - "ISM-1544" + "GOV-05": [ + "GV.OV.S3", + "GV.OV.S4", + "PR.IP.S10" ], - "CFG-03.4": [ - "ISM-0705" + "GOV-09": [ + "GV.OC.S1", + "GV.RM.S1" ], - "CFG-04.2": [ - "ISM-0824", - "ISM-1235", - "ISM-1412", - "ISM-1470", - "ISM-1485", - "ISM-1486", - "ISM-1542", - "ISM-1585", - "ISM-1601", - "ISM-1654", - "ISM-1655" + "GOV-14": [ + "GV.RR.S1" ], - "CFG-05": [ - "ISM-0382", - "ISM-1592", - "ISM-1655" + "GOV-15": [ + "GV.RM.S2" ], - "CFG-05.2": [ - "ISM-0382", - "ISM-1592" + "AST-01": [ + "GV.PO.S5" ], - "CFG-06": [ - "ISM-0843", - "ISM-0846", - "ISM-0955", - "ISM-1392", - "ISM-1471", - "ISM-1490", - "ISM-1544", - "ISM-1582" + "AST-01.2": [ + "GV.PO.S5" ], - "CFG-06.1": [ - "ISM-0843", - "ISM-0846", - "ISM-0955", - "ISM-1392", - "ISM-1471", - "ISM-1490", - "ISM-1544", - "ISM-1582" + "AST-02": [ + "ID.AM.S1", + "ID.AM.S5", + "ID.AM.S6" ], - "MON-01": [ - "ISM-0109", - "ISM-0120", - "ISM-0580", - "ISM-0660", - "ISM-1163", - "ISM-1294", - "ISM-1586" + "AST-02.8": [ + "ID.AM.S2" ], - "MON-01.8": [ - "ISM-0109" + "AST-03": [ + "GV.PO.S5" ], - "MON-01.9": [ - "ISM-0261" + "AST-04": [ + "ID.AM.S2" ], - "MON-01.16": [ - "ISM-0109", - "ISM-0120", - "ISM-0580", - "ISM-0660", - "ISM-1163", - "ISM-1294", - "ISM-1586" + "AST-09": [ + "PR.AA.S14" ], - "MON-02": [ - "ISM-0109", - "ISM-1228", - "ISM-1405", - "ISM-1536", - "ISM-1537", - "ISM-1566", - "ISM-1650" + "BCD-01": [ + "PR.IP.S11", + "RC.RP.S1", + "RC.RP.S4", + "RS.MA.S3" ], - "MON-02.1": [ - "ISM-1228" + "BCD-01.2": [ + "GV.SC.S6" ], - "MON-02.2": [ - "ISM-1228" + "BCD-01.4": [ + "RC.RP.S2" ], - "MON-02.7": [ - "ISM-0988" + "BCD-01.5": [ + "RC.RP.S1" ], - "MON-03": [ - "ISM-0582", - "ISM-0585", - "ISM-1536", - "ISM-1537" + "BCD-02": [ + "ID.AM.S4" ], - "MON-03.2": [ - "ISM-0407" + "BCD-04": [ + "GV.RM.S3", + "PR.IP.S11", + "RC.IM.S2", + "RC.RP.S3" ], - "MON-03.3": [ - "ISM-1537" + "BCD-05": [ + "RC.IM.S1", + "RC.IM.S2", + "RS.AN.S4", + "RS.AN.S4a", + "RS.AN.S4b", + "RS.IM.S1" ], - "MON-03.7": [ - "ISM-1537" + "BCD-11": [ + "PR.IP.S7", + "PR.IP.S8", + "RC.RP.S4" ], - "MON-06": [ - "ISM-1660" + "BCD-11.1": [ + "PR.IP.S8" ], - "MON-08": [ - "ISM-0859", - "ISM-0991" + "BCD-12": [ + "PR.IP.S7" ], - "MON-10": [ - "ISM-0859", - "ISM-0991", - "ISM-1213" + "CAP-01": [ + "PR.DS.S3" ], - "MON-11.3": [ - "ISM-0120", - "ISM-1091" + "CAP-04": [ + "DE.CM.S4" ], - "MON-16": [ - "ISM-1660" + "CHG-01": [ + "PR.IP.S3" ], - "MON-16.1": [ - "ISM-1625" + "CHG-02": [ + "PR.IP.S3" ], - "MON-16.4": [ - "ISM-1650" + "CHG-02.2": [ + "PR.MA.S1" ], - "CRY-01": [ - "ISM-0142", - "ISM-0457", - "ISM-0460", - "ISM-0471", - "ISM-0472", - "ISM-0474", - "ISM-0475", - "ISM-0476", - "ISM-0477", - "ISM-0479", - "ISM-0481", - "ISM-0499", - "ISM-0501", - "ISM-0994", - "ISM-0999", - "ISM-1080", - "ISM-1091", - "ISM-1146", - "ISM-1446", - "ISM-1629", - "ISM-1759", - "ISM-1761", - "ISM-1762", - "ISM-1763", - "ISM-1764", - "ISM-1765", - "ISM-1766", - "ISM-1767", - "ISM-1768", - "ISM-1769", - "ISM-1770", - "ISM-1771", - "ISM-1772" + "CLD-01": [ + "PR.IP.S13" ], - "CRY-01.3": [ - "ISM-0548", - "ISM-0554" + "CLD-02": [ + "PR.IP.S13" ], - "CRY-03": [ - "ISM-0231", - "ISM-0232", - "ISM-0241", - "ISM-0465", - "ISM-0467", - "ISM-0469", - "ISM-0484", - "ISM-0547", - "ISM-1139", - "ISM-1369", - "ISM-1370", - "ISM-1372", - "ISM-1373", - "ISM-1374", - "ISM-1375", - "ISM-1448", - "ISM-1453", - "ISM-1506", - "ISM-1553", - "ISM-1589", - "ISM-1781" + "CLD-04": [ + "PR.AA.S17" ], - "CRY-04": [ - "ISM-0677" + "CLD-09": [ + "PR.DS.S2" ], - "CRY-05": [ - "ISM-0459", - "ISM-1080" + "CPL-01": [ + "GV.OC.S2", + "PR.IP.S13", + "RS.MA.S5" ], - "CRY-05.3": [ - "ISM-1080", - "ISM-1277" + "CPL-01.3": [ + "PR.IP.S17" ], - "CRY-07": [ - "ISM-1314", - "ISM-1332" + "CPL-02": [ + "EV.ST.S4" ], - "CRY-08": [ - "ISM-0485", - "ISM-1449" + "CPL-02.2": [ + "DE.CM.S5" ], - "CRY-09": [ - "ISM-0455", - "ISM-0507" + "CPL-03": [ + "EV.ST.S5" ], - "CRY-09.3": [ - "ISM-0455", - "ISM-0462" + "CPL-03.1": [ + "PR.IP.S14" ], - "DCH-01": [ - "ISM-0337", - "ISM-0831", - "ISM-1059", - "ISM-1549", - "ISM-1599" + "CPL-03.2": [ + "DE.CM.S5" ], - "DCH-01.2": [ - "ISM-1802" + "CFG-01": [ + "PR.IP.S3" ], - "DCH-02": [ - "ISM-0270", - "ISM-0271", - "ISM-0272", - "ISM-0294", - "ISM-0296", - "ISM-0323", - "ISM-0393" + "CFG-02": [ + "PR.IP.S1" ], - "DCH-02.1": [ - "ISM-0323", - "ISM-0325" + "CFG-02.1": [ + "PR.IP.S1" ], - "DCH-04": [ - "ISM-0201", - "ISM-0270", - "ISM-0272", - "ISM-0294", - "ISM-0296", - "ISM-0332", - "ISM-0356", - "ISM-0358", - "ISM-0360" + "CFG-03": [ + "PR.IP.S1" ], - "DCH-04.1": [ - "ISM-0271" + "CFG-03.1": [ + "DE.CM.S5" ], - "DCH-05.9": [ - "ISM-0325" + "CFG-06": [ + "PR.DS.S6" ], - "DCH-06.2": [ - "ISM-0336" + "CFG-06.1": [ + "PR.DS.S6" ], - "DCH-08": [ - "ISM-0311", - "ISM-0312", - "ISM-0315", - "ISM-0363", - "ISM-0368", - "ISM-0374", - "ISM-0375", - "ISM-0378", - "ISM-0839", - "ISM-0840", - "ISM-1160", - "ISM-1217", - "ISM-1218", - "ISM-1361", - "ISM-1517", - "ISM-1550", - "ISM-1722", - "ISM-1723", - "ISM-1724", - "ISM-1725", - "ISM-1726", - "ISM-1727" + "MON-01": [ + "DE.CM.S2", + "PR.AA.S8" ], - "DCH-09": [ - "ISM-0311", - "ISM-0313", - "ISM-0317", - "ISM-0348", - "ISM-0351", - "ISM-0352", - "ISM-0354", - "ISM-0356", - "ISM-0357", - "ISM-0358", - "ISM-0359", - "ISM-0360", - "ISM-0361", - "ISM-0362", - "ISM-0835", - "ISM-0836", - "ISM-0947", - "ISM-1065", - "ISM-1067", - "ISM-1287", - "ISM-1300", - "ISM-1600", - "ISM-1735" + "MON-01.8": [ + "DE.CM.S3" ], - "DCH-09.1": [ - "ISM-0316", - "ISM-0363", - "ISM-0370", - "ISM-0371", - "ISM-0372", - "ISM-0373" + "MON-03": [ + "PR.AA.S9" ], - "DCH-09.4": [ - "ISM-1600", - "ISM-1642" + "MON-08": [ + "PR.AA.S9" ], - "DCH-10": [ - "ISM-0341", - "ISM-0343" + "MON-10": [ + "PR.AA.S9" ], - "DCH-10.1": [ - "ISM-0343" + "MON-17": [ + "DE.CM.S3" ], - "DCH-11": [ - "ISM-0325", - "ISM-0330" + "CRY-01": [ + "PR.DS.S1" ], - "DCH-12": [ - "ISM-1359", - "ISM-1713" + "CRY-03": [ + "PR.DS.S1" ], - "DCH-14": [ - "ISM-0657", - "ISM-0661", - "ISM-0663", - "ISM-0664", - "ISM-0665", - "ISM-0669", - "ISM-0675", - "ISM-1187", - "ISM-1535" + "CRY-05": [ + "PR.DS.S1" ], - "DCH-17": [ - "ISM-0347", - "ISM-0947", - "ISM-1778", - "ISM-1779" + "DCH-01": [ + "PR.AA.S14", + "PR.DS.S4" + ], + "DCH-02": [ + "PR.DS.S2" + ], + "DCH-06": [ + "PR.AA.S14" + ], + "DCH-06.2": [ + "ID.AM.S5" ], "DCH-18": [ - "ISM-0859", - "ISM-0991", - "ISM-1510" + "PR.AA.S13" ], "DCH-21": [ - "ISM-0311" + "PR.AA.S13" + ], + "DCH-26": [ + "PR.DS.S2" ], "END-04": [ - "ISM-1284", - "ISM-1286", - "ISM-1288", - "ISM-1289", - "ISM-1290", - "ISM-1293", - "ISM-1417", - "ISM-1608" + "PR.IP.S4" ], - "END-04.4": [ - "ISM-1284", - "ISM-1286", - "ISM-1288", - "ISM-1289", - "ISM-1293", - "ISM-1417", - "ISM-1608", - "ISM-1782" + "END-04.7": [ + "PR.IP.S4" ], - "END-05": [ - "ISM-1416" + "END-06": [ + "PR.DS.S6" ], - "END-07": [ - "ISM-1034", - "ISM-1341", - "ISM-1418" + "END-06.1": [ + "PR.DS.S6" ], - "END-14": [ - "ISM-0231" + "HRS-01": [ + "GV.RR.S6", + "RS.CO.S1" ], - "END-16": [ - "ISM-1006" + "HRS-02": [ + "DE.DP.S1", + "GV.RR.S2", + "PR.AT.S4", + "RS.CO.S1" ], "HRS-03": [ - "ISM-0717", - "ISM-0720", - "ISM-0724", - "ISM-0725", - "ISM-0726", - "ISM-0731", - "ISM-0732", - "ISM-0733", - "ISM-0734", - "ISM-0735" + "DE.DP.S1", + "GV.RR.S2", + "PR.AT.S4", + "PR.AT.S5", + "RS.CO.S1" ], "HRS-03.1": [ - "ISM-0824" + "GV.RR.S6", + "PR.AT.S4", + "PR.AT.S5" ], - "HRS-04": [ - "ISM-0434" + "HRS-06": [ + "GV.RR.S5" ], - "HRS-04.1": [ - "ISM-0446", - "ISM-0447" + "HRS-06.1": [ + "GV.RR.S5" ], - "HRS-04.2": [ - "ISM-0435" + "HRS-11": [ + "PR.AA.S3" ], - "HRS-04.3": [ - "ISM-0409", - "ISM-0411", - "ISM-0420", - "ISM-0446", - "ISM-0447", - "ISM-1773" + "IAC-01": [ + "PR.AA.S1", + "PR.AA.S6", + "PR.AA.S15" ], - "HRS-04.4": [ - "ISM-0420" + "IAC-06": [ + "PR.AA.S7" ], - "HRS-05": [ - "ISM-0258", - "ISM-0824", - "ISM-1146" + "IAC-08": [ + "PR.AA.S3" ], - "HRS-05.1": [ - "ISM-0820", - "ISM-0821" + "IAC-10": [ + "PR.AA.S6" ], - "HRS-05.2": [ - "ISM-0229", - "ISM-0230", - "ISM-0233", - "ISM-0235", - "ISM-0236", - "ISM-0240", - "ISM-0241", - "ISM-0264", - "ISM-0267", - "ISM-0588", - "ISM-0824", - "ISM-0931", - "ISM-1075", - "ISM-1078", - "ISM-1092", - "ISM-1196", - "ISM-1198", - "ISM-1199", - "ISM-1200", - "ISM-1562", - "ISM-1644" + "IAC-15": [ + "PR.AA.S1" ], - "HRS-05.5": [ - "ISM-0229", - "ISM-0230", - "ISM-0240", - "ISM-0701", - "ISM-0705", - "ISM-0866", - "ISM-0870", - "ISM-0871", - "ISM-0874", - "ISM-1082", - "ISM-1083", - "ISM-1084", - "ISM-1145", - "ISM-1196", - "ISM-1198", - "ISM-1199", - "ISM-1200", - "ISM-1366" + "IAC-16": [ + "PR.AA.S11" ], - "HRS-08": [ - "ISM-0430" + "IAC-17": [ + "PR.AA.S5" ], - "HRS-09": [ - "ISM-0430" + "IAC-20": [ + "PR.AA.S15" ], - "IAC-01": [ - "ISM-1146", - "ISM-1546" + "IAC-21": [ + "PR.AA.S3" ], - "IAC-01.1": [ - "ISM-0407" + "IAC-21.4": [ + "PR.AA.S11" ], - "IAC-02": [ - "ISM-0414", - "ISM-0415", - "ISM-1546" + "IRO-01": [ + "RS.MA.S1" ], - "IAC-02.1": [ - "ISM-0415", - "ISM-1619" + "IRO-02": [ + "RS.MA.S2" ], - "IAC-02.2": [ - "ISM-1055", - "ISM-1603" + "IRO-02.4": [ + "RS.AN.S2" ], - "IAC-03": [ - "ISM-1583" + "IRO-02.5": [ + "GV.SC.S6", + "RS.CO.S3", + "RS.MA.S5" ], - "IAC-04": [ - "ISM-1603" + "IRO-04": [ + "DE.DP.S2", + "GV.RM.S3", + "RS.MA.S1", + "RS.MA.S3" ], - "IAC-06": [ - "ISM-0974", - "ISM-1173", - "ISM-1401", - "ISM-1504", - "ISM-1505", - "ISM-1559", - "ISM-1560", - "ISM-1561", - "ISM-1679", - "ISM-1680", - "ISM-1681", - "ISM-1682", - "ISM-1683", - "ISM-1685" + "IRO-04.2": [ + "EV.ST.S3", + "RS.IM.S2" ], - "IAC-07": [ - "ISM-0430" + "IRO-05": [ + "RS.IM.S2" ], - "IAC-07.1": [ - "ISM-0430" + "IRO-06": [ + "DE.DP.S2", + "GV.RM.S3" ], - "IAC-07.2": [ - "ISM-0430" + "IRO-08": [ + "RS.AN.S3" ], - "IAC-08": [ - "ISM-1746" + "IRO-09": [ + "RS.CO.S3" ], - "IAC-10": [ - "ISM-1227", - "ISM-1593", - "ISM-1594", - "ISM-1595" + "IRO-10": [ + "DE.DP.S3", + "RC.CO.S2", + "RC.CO.S3", + "RS.CO.S2", + "RS.CO.S3" ], - "IAC-10.1": [ - "ISM-0417", - "ISM-0421", - "ISM-0422", - "ISM-1557", - "ISM-1558", - "ISM-1596", - "ISM-1795" + "IRO-10.2": [ + "DE.DP.S3", + "RS.CO.S2" ], - "IAC-10.5": [ - "ISM-0418", - "ISM-1402", - "ISM-1590", - "ISM-1597", - "ISM-1686", - "ISM-1749" + "IRO-10.4": [ + "RS.CO.S3" ], - "IAC-10.8": [ - "ISM-1304", - "ISM-1806" + "IRO-13": [ + "EV.ST.S3", + "RC.IM.S1", + "RS.AN.S3", + "RS.AN.S4", + "RS.AN.S4a", + "RS.AN.S4b", + "RS.AN.S5", + "RS.IM.S1" ], - "IAC-15": [ - "ISM-0441", - "ISM-0443" + "IRO-16": [ + "RC.CO.S1" ], - "IAC-15.1": [ - "ISM-1649" + "IAO-01": [ + "ID.AM.S4", + "PR.AA.S16" ], - "IAC-15.3": [ - "ISM-1404", - "ISM-1648" + "IAO-02": [ + "PR.AA.S16" ], - "IAC-15.6": [ - "ISM-1591" + "MNT-02": [ + "PR.MA.S1" ], - "IAC-15.9": [ - "ISM-1610", - "ISM-1611", - "ISM-1612", - "ISM-1613", - "ISM-1614", - "ISM-1615" + "MNT-05": [ + "PR.MA.S2" ], - "IAC-16": [ - "ISM-0445", - "ISM-0446", - "ISM-0447", - "ISM-1175", - "ISM-1380", - "ISM-1507", - "ISM-1508", - "ISM-1509", - "ISM-1620", - "ISM-1648", - "ISM-1649", - "ISM-1650", - "ISM-1687", - "ISM-1688", - "ISM-1689" + "MNT-05.5": [ + "PR.MA.S2" ], - "IAC-16.4": [ - "ISM-0445" + "NET-01": [ + "PR.AA.S2" ], - "IAC-17": [ - "ISM-0405", - "ISM-1647", - "ISM-1648", - "ISM-1716" + "NET-01.1": [ + "PR.AA.S4" ], - "IAC-18": [ - "ISM-0421", - "ISM-0422" + "NET-03.5": [ + "PR.DS.S4" ], - "IAC-21": [ - "ISM-0441", - "ISM-0611", - "ISM-1380", - "ISM-1392", - "ISM-1705", - "ISM-1706", - "ISM-1707", - "ISM-1708" + "NET-04.11": [ + "ID.AM.S3" ], - "IAC-21.2": [ - "ISM-1175" + "NET-06": [ + "PR.AA.S2" ], - "IAC-21.5": [ - "ISM-1592" + "NET-14": [ + "PR.AA.S12" ], - "IAC-22": [ - "ISM-1403" + "NET-17": [ + "PR.DS.S4" ], - "IAC-24": [ - "ISM-0428" + "PES-01": [ + "PR.AA.S10", + "PR.IP.S9" ], - "IAC-25": [ - "ISM-0853" + "PES-01.1": [ + "PR.IP.S9" ], - "IAC-28.1": [ - "ISM-0405" + "PES-03": [ + "PR.AA.S10" ], - "IRO-01": [ - "ISM-0137", - "ISM-0576", - "ISM-1609", - "ISM-1618" + "PES-03.4": [ + "PR.AA.S10" ], - "IRO-02": [ - "ISM-0123", - "ISM-0141", - "ISM-0917", - "ISM-1618", - "ISM-1803" + "PES-05": [ + "PR.AA.S10" ], - "IRO-02.2": [ - "ISM-1625", - "ISM-1626" + "PRM-01": [ + "GV.RR.S4" ], - "IRO-04": [ - "ISM-0043", - "ISM-0576", - "ISM-0917", - "ISM-1784" + "PRM-01.1": [ + "GV.RR.S4" ], - "IRO-04.1": [ - "ISM-0133" + "PRM-03": [ + "GV.RR.S4" ], - "IRO-07": [ - "ISM-0733", - "ISM-1618" + "PRM-07": [ + "PR.IP.S2" ], - "IRO-08": [ - "ISM-0137", - "ISM-0138", - "ISM-1609", - "ISM-1731", - "ISM-1732" + "RSK-01": [ + "GV.RM.S1" ], - "IRO-09": [ - "ISM-0125", - "ISM-0137", - "ISM-0733", - "ISM-1609", - "ISM-1803" + "RSK-01.3": [ + "GV.RM.S4" ], - "IRO-10": [ - "ISM-0123", - "ISM-0137", - "ISM-0733", - "ISM-1088", - "ISM-1609" + "RSK-01.5": [ + "GV.RM.S4" ], - "IRO-10.2": [ - "ISM-0733" + "RSK-04": [ + "ID.RA.S1", + "ID.RA.S2" ], - "IRO-10.4": [ - "ISM-1569" + "RSK-04.1": [ + "GV.RM.S4" ], - "IRO-12": [ - "ISM-0133" + "RSK-06": [ + "ID.RA.S5" ], - "IRO-12.3": [ - "ISM-0133" - ], - "IRO-12.4": [ - "ISM-0133" - ], - "IRO-13": [ - "ISM-1213" + "RSK-06.2": [ + "EV.ST.S1", + "EV.ST.S4" ], - "IRO-14": [ - "ISM-0140" + "RSK-09.1": [ + "GV.SC.S7" ], - "IRO-15": [ - "ISM-0651", - "ISM-0652", - "ISM-1389" + "SEA-01": [ + "PR.IP.S17" ], - "IAO-01": [ - "ISM-0027", - "ISM-0280", - "ISM-1525" + "SEA-13": [ + "EV.ST.S2" ], - "IAO-02": [ - "ISM-0100" + "OPS-01.1": [ + "PR.AA.S14", + "PR.IP.S7", + "RC.RP.S4" ], - "IAO-02.2": [ - "ISM-0100", - "ISM-1137", - "ISM-1570" + "OPS-04": [ + "DE.CM.S1" ], - "IAO-02.3": [ - "ISM-0100" + "OPS-07": [ + "ID.AM.S3" ], - "IAO-02.4": [ - "ISM-1563" + "SAT-01": [ + "GV.RR.S6", + "PR.AT.S1" ], - "IAO-03": [ - "ISM-0041", - "ISM-0432" + "SAT-03": [ + "PR.AT.S2" ], - "IAO-03.2": [ - "ISM-0072", - "ISM-1451", - "ISM-1571", - "ISM-1572", - "ISM-1573", - "ISM-1574", - "ISM-1575" + "SAT-03.5": [ + "PR.AT.S2" ], - "IAO-05": [ - "ISM-1564" + "TDA-04.2": [ + "GV.SC.S5", + "PR.IP.S5" ], - "IAO-07": [ - "ISM-0027", - "ISM-0293", - "ISM-1525" + "TDA-08": [ + "PR.DS.S5" ], - "MNT-01": [ - "ISM-0305", - "ISM-1226" + "TDA-09": [ + "PR.IP.S6" ], - "MNT-02": [ - "ISM-1079" + "TPM-01": [ + "GV.OC.S3", + "GV.SC.S1", + "PR.IP.S15" ], - "MNT-06": [ - "ISM-0305", - "ISM-0307" + "TPM-01.1": [ + "GV.OC.S3", + "GV.SC.S1", + "GV.SC.S2" ], - "MNT-06.1": [ - "ISM-0306" + "TPM-02": [ + "GV.OC.S3", + "GV.SC.S1", + "GV.SC.S2" ], - "MNT-08": [ - "ISM-0305" + "TPM-03": [ + "GV.OC.S3", + "GV.SC.S1" ], - "MNT-09": [ - "ISM-0310" + "TPM-05": [ + "GV.OC.S3", + "GV.SC.S3", + "GV.SC.S8", + "PR.AT.S3" ], - "MNT-10": [ - "ISM-1598" + "TPM-05.2": [ + "GV.SC.S3", + "GV.SC.S8" ], - "MDM-01": [ - "ISM-0682", - "ISM-0687", - "ISM-0863", - "ISM-0864", - "ISM-0874", - "ISM-1085", - "ISM-1195", - "ISM-1297", - "ISM-1366", - "ISM-1533" + "TPM-05.4": [ + "GV.OC.S3", + "GV.SC.S3", + "PR.AT.S3" ], - "MDM-03": [ - "ISM-0869" + "TPM-05.6": [ + "PR.IP.S5" ], - "MDM-05": [ - "ISM-0702" + "TPM-05.7": [ + "GV.SC.S3" ], - "MDM-06": [ - "ISM-0694", - "ISM-1297", - "ISM-1400", - "ISM-1482" + "TPM-05.8": [ + "PR.IP.S15", + "PR.IP.S16" ], - "NET-01": [ - "ISM-0521", - "ISM-0629", - "ISM-1186", - "ISM-1428", - "ISM-1429", - "ISM-1430", - "ISM-1711", - "ISM-1712", - "ISM-1774", - "ISM-1783" + "TPM-06": [ + "PR.AT.S3" ], - "NET-01.1": [ - "ISM-0665" + "TPM-08": [ + "GV.SC.S4" ], - "NET-02.1": [ - "ISM-1019", - "ISM-1431", - "ISM-1436", - "ISM-1805" + "TPM-09": [ + "GV.SC.S4" ], - "NET-02.2": [ - "ISM-0536" + "TPM-10": [ + "GV.SC.S4" ], - "NET-02.3": [ - "ISM-0597", - "ISM-0610", - "ISM-0626", - "ISM-0635", - "ISM-0670", - "ISM-1287", - "ISM-1521", - "ISM-1522", - "ISM-1523" + "THR-01": [ + "EV.ST.S1" ], - "NET-03": [ - "ISM-0611", - "ISM-0612", - "ISM-0613", - "ISM-0616", - "ISM-0619", - "ISM-0622", - "ISM-0628", - "ISM-0629", - "ISM-0631", - "ISM-0634", - "ISM-0637", - "ISM-0639", - "ISM-1037", - "ISM-1192", - "ISM-1284", - "ISM-1286", - "ISM-1287", - "ISM-1288", - "ISM-1289", - "ISM-1293", - "ISM-1389", - "ISM-1427", - "ISM-1520", - "ISM-1521", - "ISM-1522", - "ISM-1528" + "THR-03": [ + "EV.ST.S1", + "EV.ST.S4", + "ID.RA.S3", + "RS.AN.S1" ], - "NET-03.1": [ - "ISM-1314" + "THR-03.1": [ + "RS.AN.S1" ], - "NET-03.2": [ - "ISM-0546", - "ISM-1562" + "THR-07": [ + "DE.DP.S5" ], - "NET-04": [ - "ISM-0643", - "ISM-0645", - "ISM-1157", - "ISM-1158", - "ISM-1386" + "THR-10": [ + "ID.RA.S4" ], - "NET-06": [ - "ISM-1181", - "ISM-1269", - "ISM-1270", - "ISM-1271", - "ISM-1577", - "ISM-1750" + "VPM-01": [ + "PR.IP.S12" ], - "NET-06.1": [ - "ISM-1385", - "ISM-1750" + "VPM-02": [ + "PR.MA.S3" ], - "NET-06.2": [ - "ISM-0529", - "ISM-0530", - "ISM-0535", - "ISM-1364", - "ISM-1532" + "VPM-03": [ + "PR.MA.S3" ], - "NET-06.4": [ - "ISM-1385" + "VPM-05": [ + "PR.MA.S3" ], - "NET-06.6": [ - "ISM-1269", - "ISM-1270", - "ISM-1271" + "VPM-06": [ + "ID.RA.S1" ], - "NET-08": [ - "ISM-1028", - "ISM-1030", - "ISM-1627", - "ISM-1628" + "VPM-10": [ + "DE.DP.S4" + ] + }, + "apac-jpn-appi-2020": { + "GOV-17": [ + "IV.5.53(2)" ], - "NET-08.1": [ - "ISM-0637" + "CPL-01": [ + "IV.1.16-2", + "IV.1.26(1)", + "IV.1.26(1)(i)", + "IV.1.26(1)(ii)", + "IV.1.26(2)" ], - "NET-08.4": [ - "ISM-1778", - "ISM-1779" + "CPL-07": [ + "IV.5.52(1)", + "IV.5.52(2)", + "IV.5.52(3)" ], - "NET-10": [ - "ISM-0574", - "ISM-0861", - "ISM-1026", - "ISM-1027", - "ISM-1151", - "ISM-1183", - "ISM-1540", - "ISM-1782", - "ISM-1799" + "DCH-22.1": [ + "IV.1.29(3)" ], - "NET-10.3": [ - "ISM-0574", - "ISM-1151", - "ISM-1183", - "ISM-1799" + "HRS-01": [ + "IV.1.21", + "IV.1.22" ], - "NET-10.4": [ - "ISM-1432" + "IAC-09.6": [ + "IV.2.35-2(1)" ], - "NET-13": [ - "ISM-0264", - "ISM-0267", - "ISM-0269", - "ISM-0270", - "ISM-0271", - "ISM-0272", - "ISM-0490", - "ISM-0494", - "ISM-0496", - "ISM-0498", - "ISM-0565", - "ISM-0569", - "ISM-0570", - "ISM-0571", - "ISM-0572", - "ISM-0574", - "ISM-0861", - "ISM-0998", - "ISM-0999", - "ISM-1000", - "ISM-1023", - "ISM-1024", - "ISM-1026", - "ISM-1027", - "ISM-1089", - "ISM-1151", - "ISM-1183", - "ISM-1540", - "ISM-1589" + "IRO-10": [ + "IV.1.22-2(2)" ], - "NET-14": [ - "ISM-0487", - "ISM-0488", - "ISM-0489" + "IRO-10.2": [ + "IV.1.22-2(1)" ], - "NET-14.8": [ - "ISM-1591" + "PRI-01": [ + "IV.5.53(1)" ], - "NET-15": [ - "ISM-0225", - "ISM-0248", - "ISM-0536", - "ISM-1314", - "ISM-1315", - "ISM-1316", - "ISM-1317", - "ISM-1318", - "ISM-1319", - "ISM-1320", - "ISM-1321", - "ISM-1322", - "ISM-1323", - "ISM-1324", - "ISM-1327", - "ISM-1330", - "ISM-1334", - "ISM-1335", - "ISM-1454", - "ISM-1543" + "PRI-01.3": [ + "IV.5.53(3)" ], - "NET-15.4": [ - "ISM-1013", - "ISM-1338" + "PRI-01.5": [ + "IV.1.24(1)", + "IV.1.24(2)", + "IV.1.24(3)" ], - "NET-15.5": [ - "ISM-0829" + "PRI-01.6": [ + "IV.1.20" ], - "NET-18": [ - "ISM-0267", - "ISM-0649", - "ISM-0659", - "ISM-0958", - "ISM-0961", - "ISM-0963", - "ISM-1171", - "ISM-1234", - "ISM-1236", - "ISM-1237", - "ISM-1275", - "ISM-1287", - "ISM-1293", - "ISM-1502", - "ISM-1524" + "PRI-01.11": [ + "IV.1.17(1)", + "IV.1.26-2(1)", + "IV.2.35-2(7)", + "IV.2.35-2(8)", + "IV.2.35-3(1)", + "IV.3.36(1)", + "IV.3.36(2)", + "IV.3.36(3)", + "IV.3.36(4)", + "IV.3.36(5)", + "IV.3.36(6)", + "IV.3.37", + "IV.3.38", + "IV.3.39", + "IV.5.54" ], - "NET-18.1": [ - "ISM-0260", - "ISM-0570", - "ISM-1237" + "PRI-02": [ + "IV.1.18(1)", + "IV.1.18(2)", + "IV.1.18(3)", + "IV.1.23(2)", + "IV.1.23(2)(i)", + "IV.1.23(2)(ii)", + "IV.1.23(2)(iii)", + "IV.1.23(2)(iv)", + "IV.1.23(2)(v)", + "IV.1.23(2)(vi)", + "IV.1.23(2)(vii)", + "IV.1.23(2)(viii)", + "IV.1.27(1)", + "IV.1.27(1)(i)", + "IV.1.27(1)(ii)", + "IV.1.27(1)(iii)", + "IV.1.27(1)(iv)" ], - "NET-18.2": [ - "ISM-0263" + "PRI-02.1": [ + "IV.1.15(1)" ], - "NET-20.4": [ - "ISM-1540" + "PRI-03": [ + "IV.1.26-2(1)(i)", + "IV.1.26-2(1)(ii)" ], - "NET-20.7": [ - "ISM-0567" + "PRI-03.1": [ + "IV.1.30(5)" ], - "PES-01": [ - "ISM-0810" + "PRI-03.2": [ + "IV.1.16(2)" ], - "PES-03": [ - "ISM-1296" + "PRI-03.3": [ + "IV.1.23(1)" ], - "PES-03.4": [ - "ISM-0813", - "ISM-1053", - "ISM-1074", - "ISM-1530" + "PRI-03.4": [ + "IV.1.30(1)" ], - "PES-04.1": [ - "ISM-0164" + "PRI-03.9": [ + "IV.1.30(2)", + "IV.1.30(4)", + "IV.1.30(6)", + "IV.1.30(7)", + "IV.1.31" ], - "PES-06": [ - "ISM-0164" + "PRI-03.11": [ + "IV.1.23(3)", + "IV.1.23(6)", + "IV.1.30(3)" ], - "PES-06.3": [ - "ISM-0164" + "PRI-04": [ + "IV.1.15(2)" ], - "PES-07.3": [ - "ISM-1123" + "PRI-05": [ + "IV.2.35-2(5)" ], - "PES-12": [ - "ISM-1644" + "PRI-05.2": [ + "IV.1.19" ], - "PES-12.1": [ - "ISM-0181", - "ISM-0187", - "ISM-0194", - "ISM-0195", - "ISM-0198", - "ISM-0201", - "ISM-0206", - "ISM-0208", - "ISM-0211", - "ISM-0213", - "ISM-0216", - "ISM-0217", - "ISM-0218", - "ISM-0926", - "ISM-1095", - "ISM-1096", - "ISM-1098", - "ISM-1100", - "ISM-1101", - "ISM-1102", - "ISM-1103", - "ISM-1105", - "ISM-1107", - "ISM-1109", - "ISM-1111", - "ISM-1112", - "ISM-1114", - "ISM-1115", - "ISM-1116", - "ISM-1119", - "ISM-1122", - "ISM-1130", - "ISM-1133", - "ISM-1164", - "ISM-1216", - "ISM-1639", - "ISM-1640", - "ISM-1718", - "ISM-1719", - "ISM-1720", - "ISM-1721" + "PRI-05.3": [ + "IV.2.35-2(1)" ], - "PES-12.2": [ - "ISM-1036" + "PRI-05.4": [ + "IV.1.16(1)", + "IV.1.17(2)", + "IV.1.17(2)(i)", + "IV.1.17(2)(ii)", + "IV.1.17(2)(iii)", + "IV.1.17(2)(iv)", + "IV.1.17(2)(v)", + "IV.1.17(2)(vi)", + "IV.1.23(1)(i)", + "IV.1.23(1)(ii)", + "IV.1.23(1)(iii)", + "IV.1.23(1)(iv)" ], - "PES-13": [ - "ISM-0246", - "ISM-0249", - "ISM-0250" + "PRI-06": [ + "IV.1.28(1)" ], - "PES-16": [ - "ISM-1107", - "ISM-1216", - "ISM-1217", - "ISM-1599", - "ISM-1718", - "ISM-1719", - "ISM-1720", - "ISM-1721", - "ISM-1728", - "ISM-1729" + "PRI-06.1": [ + "IV.1.29(1)", + "IV.1.29(2)" ], - "PRM-01": [ - "ISM-0720", - "ISM-0732" + "PRI-06.4": [ + "IV.1.27(2)", + "IV.1.27(2)(i)", + "IV.1.27(2)(ii)", + "IV.1.27(3)", + "IV.1.28(2)", + "IV.1.28(3)", + "IV.1.35(1)", + "IV.1.35(2)" ], - "PRM-01.1": [ - "ISM-0039", - "ISM-0720" + "PRI-07.5": [ + "IV.1.28(2)(i)", + "IV.1.28(2)(ii)", + "IV.1.28(2)(iii)" ], - "PRM-02": [ - "ISM-0732" + "PRI-14.1": [ + "IV.1.25(1)", + "IV.1.25(2)", + "IV.1.26(3)", + "IV.1.26(4)" ], - "PRM-03": [ - "ISM-0732" + "PRI-18": [ + "IV.1.32(1)", + "IV.1.32(2)", + "IV.1.32(3)", + "IV.1.32(4)" ], - "PRM-04": [ - "ISM-1739" + "TPM-09": [ + "IV.5.53(4)" + ] + }, + "apac-jpn-ismap": { + "GOV-01": [ + "4.4.1.1", + "4.4.1.2", + "4.4.2.1", + "4.5.4.1", + "4.5.4.2", + "4.8.1.1", + "4.8.2.2", + "5.1", + "5.1.1", + "6.1" ], - "PRM-05": [ - "ISM-0720", - "ISM-1739" + "GOV-01.1": [ + "4.4.1.1", + "4.4.1.3", + "4.4.5.3", + "4.5.3.1", + "4.6.3.1", + "4.6.3.2", + "4.6.3.3" ], - "PRM-07": [ - "ISM-1526", - "ISM-1739" + "GOV-01.2": [ + "4.6.1.1" ], - "RSK-01": [ - "ISM-0726" + "GOV-01.3": [ + "4.6.1.1", + "4.6.1.2", + "4.6.3.3" ], - "RSK-03": [ - "ISM-1526" + "GOV-02": [ + "4.4.5.1", + "4.4.5.3", + "4.5.2.1", + "4.8.2.1", + "5", + "5.1.1", + "5.1.1.1", + "5.1.1.8", + "5.1.1.21", + "6", + "6.2.1" ], - "RSK-06.2": [ - "ISM-1809" + "GOV-02.1": [ + "5.1.1.7" ], - "RSK-09": [ - "ISM-0731", - "ISM-1567", - "ISM-1785" + "GOV-03": [ + "4.5.3.1", + "4.7.1.5", + "4.8.2.1", + "5.1.1", + "5.1.2", + "5.1.2.2", + "5.1.2.3", + "5.1.2.4" ], - "RSK-09.1": [ - "ISM-1452", - "ISM-1567" + "GOV-04": [ + "4.4.1.2", + "5.1.1.6", + "5.1.2.1" ], - "SEA-01": [ - "ISM-1739", - "ISM-1743" + "GOV-05": [ + "4.6.2.1" ], - "SEA-02": [ - "ISM-1739", - "ISM-1743" + "GOV-06": [ + "6.1.3", + "6.1.3.1", + "6.1.3.3.PB" ], - "SEA-03": [ - "ISM-1739", - "ISM-1743" + "GOV-07": [ + "6.1.4", + "6.1.4.1", + "6.1.4.2", + "6.1.4.3", + "6.1.4.4", + "6.1.4.5", + "6.1.4.6" ], - "SEA-13.1": [ - "ISM-1460", - "ISM-1461", - "ISM-1604", - "ISM-1605", - "ISM-1606", - "ISM-1607" + "GOV-09": [ + "4.4.4.1", + "5.1.1.5" ], - "SEA-18": [ - "ISM-0408" + "GOV-14": [ + "4.5.2.1", + "7.2.1.8" ], - "SEA-18.1": [ - "ISM-0408" + "GOV-15": [ + "4.4.4.1", + "4.5.2.1" ], - "SEA-18.2": [ - "ISM-0408" + "GOV-15.1": [ + "4.4.4.1" ], - "SEA-20": [ - "ISM-0988" + "GOV-17": [ + "4.5.3.1" ], - "SEA-22": [ - "ISM-1687" + "AAT-12": [ + "18.1.2", + "18.1.2.13.PB" ], - "SAT-01": [ - "ISM-0252", - "ISM-0720", - "ISM-0735" + "AST-01": [ + "8", + "8.1", + "8.1.1.1", + "8.1.1.6.PB" ], - "SAT-02": [ - "ISM-0252", - "ISM-0824", - "ISM-1146", - "ISM-1740" + "AST-02": [ + "8.1.1", + "8.1.1.2", + "8.1.1.3", + "8.1.1.4", + "8.1.2.3" ], - "SAT-02.2": [ - "ISM-0817" + "AST-02.7": [ + "14.2.7.1", + "18.1.2", + "18.1.2.1", + "18.1.2.2", + "18.1.2.3", + "18.1.2.4", + "18.1.2.5", + "18.1.2.6", + "18.1.2.7", + "18.1.2.8", + "18.1.2.9", + "18.1.2.10", + "18.1.2.11", + "18.1.2.12" ], - "SAT-03": [ - "ISM-1146", - "ISM-1565", - "ISM-1740" + "AST-03": [ + "8.1.1.5", + "8.1.2", + "8.1.2.1", + "8.1.2.2" ], - "SAT-03.2": [ - "ISM-0817", - "ISM-0824", - "ISM-1740" + "AST-04": [ + "4.4.4" ], - "SAT-03.3": [ - "ISM-0831", - "ISM-1059" + "AST-04.1": [ + "4.4.4", + "4.4.4.1", + "8.1.2.4" ], - "SAT-03.5": [ - "ISM-1565" + "AST-05": [ + "8.3", + "8.3.1" ], - "SAT-03.8": [ - "ISM-1780" + "AST-05.1": [ + "8.3.1.2", + "13.2.2.1" ], - "TDA-01": [ - "ISM-0938", - "ISM-1780" + "AST-06": [ + "6.2.1.18", + "6.2.1.19", + "8.2.3.5", + "11.2.8", + "11.2.8.1", + "11.2.8.2", + "11.2.8.3", + "11.2.8.4" ], - "TDA-01.1": [ - "ISM-1796", - "ISM-1797", - "ISM-1798" + "AST-09": [ + "8.1.2.6", + "8.3.1.1", + "8.3.2", + "8.3.2.1", + "8.3.2.2", + "8.3.2.3", + "11.2.7", + "11.2.7.1", + "11.2.7.2" ], - "TDA-02.4": [ - "ISM-1798" + "AST-10": [ + "8.1.4" ], - "TDA-04": [ - "ISM-1798" + "BCD-01": [ + "5.1.1.13", + "17", + "17.1", + "17.1.1", + "17.1.1.1", + "17.1.1.2", + "17.1.1.3", + "17.1.1.4", + "17.1.3", + "17.1.3.1", + "17.1.3.4" ], - "TDA-04.1": [ - "ISM-1798" + "BCD-01.7": [ + "12.2.1.10", + "12.2.1.11", + "17.1.2", + "17.1.2.1", + "17.1.2.2", + "17.1.2.3", + "17.1.2.4", + "17.1.2.5", + "17.1.2.6" ], - "TDA-04.2": [ - "ISM-1730" + "BCD-04": [ + "17.1.3.2", + "17.1.3.3" ], - "TDA-06": [ - "ISM-0401", - "ISM-1239", - "ISM-1419", - "ISM-1552" + "BCD-09": [ + "17.2", + "17.2.1", + "17.2.1.1", + "17.2.1.2", + "17.2.1.3" ], - "TDA-06.2": [ - "ISM-1238" + "BCD-11": [ + "12.3", + "12.3.1", + "12.3.1.1", + "12.3.1.2", + "12.3.1.3", + "12.3.1.4", + "12.3.1.5", + "12.3.1.11", + "12.3.1.12", + "12.3.1.13", + "12.3.1.14", + "12.3.1.16.P", + "12.3.1.17.P", + "12.3.1.18.P", + "12.3.1.21.P", + "12.3.1.24.P" ], - "TDA-07": [ - "ISM-0400", - "ISM-1419" + "BCD-11.2": [ + "8.3.1.7", + "12.3.1.6", + "12.3.1.7", + "12.3.1.23.P" ], - "TDA-08": [ - "ISM-0400", - "ISM-1273", - "ISM-1274" + "BCD-11.5": [ + "12.3.1.8", + "12.3.1.9", + "12.3.1.10", + "12.3.1.20.P", + "12.3.1.22.P" ], - "TDA-09": [ - "ISM-0402", - "ISM-1754" + "CAP-01": [ + "12.1.3", + "12.1.3.1", + "12.1.3.2", + "12.1.3.3", + "12.1.3.4", + "12.1.3.5", + "12.1.3.6", + "12.1.3.7", + "12.1.3.8" ], - "TDA-09.2": [ - "ISM-0402" + "CHG-01": [ + "4.5.4.4", + "12.1.2", + "12.1.2.1", + "12.1.2.11.PB" ], - "TDA-09.3": [ - "ISM-0402" + "CHG-02": [ + "12.1.2.2", + "12.1.2.3", + "12.1.2.4", + "12.1.2.5", + "12.1.2.6", + "12.1.2.7", + "12.1.2.8", + "12.1.2.9", + "12.1.2.13", + "12.1.2.14", + "12.5.1.4", + "12.5.1.6", + "12.5.1.7", + "12.5.1.8", + "12.5.1.10", + "12.5.1.11", + "12.5.1.12", + "12.5.1.13", + "12.5.1.14", + "12.5.1.15", + "12.5.1.16", + "12.5.1.17", + "12.5.1.18", + "14.2.2", + "14.2.2.1", + "14.2.2.2", + "14.2.2.3", + "14.2.2.4", + "14.2.2.5", + "14.2.2.6", + "14.2.2.7", + "14.2.2.8", + "14.2.2.9", + "14.2.2.10", + "14.2.2.11", + "14.2.2.12", + "14.2.2.13", + "14.2.2.14", + "14.2.2.15", + "14.2.2.16", + "14.2.2.17", + "14.2.4.7", + "14.2.4.8", + "14.2.4.9", + "14.2.4.10" ], - "TDA-09.4": [ - "ISM-0402" + "CHG-02.1": [ + "14.2.4", + "14.2.4.1", + "14.2.4.2", + "14.2.4.3", + "14.2.4.4", + "14.2.4.5", + "14.2.4.6" ], - "TDA-09.5": [ - "ISM-0402" + "CHG-02.2": [ + "12.1.2.10", + "12.5.1.5", + "12.5.1.9", + "14.2.3", + "14.2.3.1", + "14.2.3.2", + "14.2.3.3" ], - "TDA-09.6": [ - "ISM-0383" + "CLD-01": [ + "5.1.1.22.P", + "5.1.1.23.P", + "5.1.1.24.P", + "5.1.1.25.P", + "5.1.1.26.P", + "5.1.1.27.P", + "5.1.1.28.P", + "5.1.1.29.P", + "5.1.1.30.P" ], - "TDA-10": [ - "ISM-1420" + "CLD-01.2": [ + "8.1.5.P", + "8.1.5.1.P", + "8.1.5.2.P", + "8.1.5.3.P", + "8.1.5.4.P" ], - "TDA-10.1": [ - "ISM-0402" + "CLD-02": [ + "8.1.2.7.PB", + "9.2.3.11.PB" ], - "TDA-11": [ - "ISM-1790", - "ISM-1791", - "ISM-1792" + "CLD-06": [ + "9.5.1.P", + "9.5.1.1.P", + "9.5.1.2.P", + "9.5.1.3.P", + "9.5.1.4.P" ], - "TDA-17": [ - "ISM-0304", - "ISM-1501", - "ISM-1704", - "ISM-1753" + "CLD-06.1": [ + "6.3.1.1.PB" ], - "TDA-20": [ - "ISM-1422" + "CPL-01": [ + "4.4.2.1", + "5.1.1.3", + "18", + "18.1", + "18.1.1", + "18.1.1.1", + "18.1.1.2", + "18.1.1.3", + "18.1.1.4.P", + "18.1.1.5.P", + "18.1.1.6.P", + "18.1.1.7.P", + "18.1.5.7.PB" ], - "TPM-01": [ - "ISM-1073", - "ISM-1785" + "CPL-01.1": [ + "4.6.1.1", + "4.7.1.1", + "4.7.1.2" ], - "TPM-01.1": [ - "ISM-1631", - "ISM-1637", - "ISM-1638", - "ISM-1736", - "ISM-1737", - "ISM-1786" + "CPL-01.2": [ + "4.4.4", + "4.4.4.1" ], - "TPM-02": [ - "ISM-1452" + "CPL-01.3": [ + "4.5.4.3", + "18.2.1.11.P", + "18.2.1.12.P" ], - "TPM-03": [ - "ISM-0731", - "ISM-1452", - "ISM-1632", - "ISM-1789" + "CPL-01.4": [ + "4.5.4.3", + "4.6.2.2" ], - "TPM-03.1": [ - "ISM-1567", - "ISM-1568", - "ISM-1632", - "ISM-1743", - "ISM-1788", - "ISM-1789" + "CPL-02": [ + "4.6.1.1", + "4.6.2.2", + "4.6.2.6", + "12.7", + "12.7.1.8", + "12.7.1.9" ], - "TPM-03.2": [ - "ISM-1567" + "CPL-02.1": [ + "4.6.2.2", + "4.6.2.4" ], - "TPM-04": [ - "ISM-1569" + "CPL-03": [ + "4.6.2.3", + "4.6.2.5", + "12.7.1", + "12.7.1.1", + "12.7.1.2", + "12.7.1.3", + "12.7.1.4", + "12.7.1.5", + "12.7.1.6", + "12.7.1.7", + "18.2", + "18.2.2", + "18.2.2.1", + "18.2.2.2", + "18.2.2.3", + "18.2.2.4", + "18.2.2.5", + "18.2.2.6", + "18.2.2.7", + "18.2.2.8" ], - "TPM-04.1": [ - "ISM-1568", - "ISM-1573", - "ISM-1787" - ], - "TPM-04.4": [ - "ISM-1572" - ], - "TPM-05": [ - "ISM-0072", - "ISM-1395", - "ISM-1451", - "ISM-1569", - "ISM-1571", - "ISM-1572", - "ISM-1573", - "ISM-1574", - "ISM-1575", - "ISM-1738" + "CPL-03.1": [ + "4.6.2.5", + "18.2.1", + "18.2.1.3", + "18.2.1.4", + "18.2.1.5", + "18.2.1.6", + "18.2.1.7", + "18.2.1.8", + "18.2.1.9.P", + "18.2.1.10.P", + "18.2.1.13.P" ], - "TPM-05.1": [ - "ISM-1576" + "CPL-03.2": [ + "18.2.3", + "18.2.3.1", + "18.2.3.2", + "18.2.3.3", + "18.2.3.4", + "18.2.3.5" ], - "TPM-05.5": [ - "ISM-1793" + "CPL-07": [ + "18.1.2.13.PB" ], - "TPM-05.7": [ - "ISM-1804" + "CPL-13.1": [ + "4.6.2.7" ], - "TPM-06": [ - "ISM-1569" + "CPL-13.2": [ + "4.6.2.7" ], - "TPM-08": [ - "ISM-1793" + "CFG-02": [ + "8.3.1.9" ], - "TPM-10": [ - "ISM-1794" + "CFG-02.9": [ + "9.5.2.P", + "9.5.2.1.PB" ], - "THR-04": [ - "ISM-1625", - "ISM-1626" + "CFG-05.2": [ + "12.5", + "12.5.1", + "12.5.1.1", + "12.5.1.2", + "12.5.1.3", + "12.6.2", + "12.6.2.1", + "12.6.2.2", + "12.6.2.3", + "12.6.2.4" ], - "THR-05": [ - "ISM-1625", - "ISM-1626" + "MON-01": [ + "12.4", + "12.4.1", + "12.4.1.15.PB" ], - "THR-06": [ - "ISM-1616", - "ISM-1717", - "ISM-1755", - "ISM-1756" + "MON-01.8": [ + "12.4.3.3", + "12.4.5.P", + "12.4.5.1.P", + "12.4.5.2.P", + "12.4.5.3.P", + "12.4.5.4.P", + "12.4.5.5.P" ], - "VPM-01": [ - "ISM-1143", - "ISM-1163", - "ISM-1460", - "ISM-1493" + "MON-02.6": [ + "6.1.3.5", + "6.1.4.7" ], - "VPM-03": [ - "ISM-1163" + "MON-03": [ + "12.4.1.1", + "12.4.1.2", + "12.4.1.3", + "12.4.1.4", + "12.4.1.5", + "12.4.1.6", + "12.4.1.7", + "12.4.1.8", + "12.4.1.9", + "12.4.1.10", + "12.4.1.11", + "12.4.1.12", + "12.4.1.13", + "12.4.1.14", + "12.4.1.17", + "12.4.1.18" ], - "VPM-04": [ - "ISM-1801" + "MON-03.3": [ + "12.4.3", + "12.4.3.1" ], - "VPM-04.1": [ - "ISM-1467", - "ISM-1483" + "MON-08": [ + "12.4.2", + "12.4.2.1", + "12.4.2.2", + "12.4.2.3", + "12.4.3.2" ], - "VPM-05": [ - "ISM-1143", - "ISM-1493", - "ISM-1690", - "ISM-1691", - "ISM-1692", - "ISM-1693", - "ISM-1694", - "ISM-1695", - "ISM-1696", - "ISM-1697", - "ISM-1751" + "CRY-01": [ + "5.1.1.17", + "10", + "10.1", + "10.1.1", + "10.1.1.1", + "10.1.1.2", + "10.1.1.3", + "10.1.1.4", + "10.1.1.5", + "10.1.1.6", + "10.1.1.7", + "10.1.1.8", + "10.1.1.9.PB", + "10.1.1.10.P", + "13.2.1.6", + "14.1.3", + "14.1.3.1", + "14.1.3.2", + "14.1.3.3", + "14.1.3.4", + "14.1.3.5", + "14.1.3.6" ], - "VPM-05.1": [ - "ISM-0298", - "ISM-0300" + "CRY-01.2": [ + "18.1.5", + "18.1.5.1", + "18.1.5.2", + "18.1.5.3", + "18.1.5.4", + "18.1.5.5", + "18.1.5.6" ], - "VPM-05.4": [ - "ISM-1467" + "CRY-04": [ + "14.2.5.8" ], - "VPM-06": [ - "ISM-1163", - "ISM-1698", - "ISM-1699", - "ISM-1700", - "ISM-1701", - "ISM-1702", - "ISM-1703", - "ISM-1752" + "CRY-05": [ + "8.3.1.5" ], - "VPM-06.1": [ - "ISM-1808" + "CRY-09": [ + "10.1.2", + "10.1.2.1", + "10.1.2.2", + "10.1.2.3", + "10.1.2.4", + "10.1.2.5", + "10.1.2.6", + "10.1.2.7", + "10.1.2.8", + "10.1.2.9", + "10.1.2.10", + "10.1.2.11", + "10.1.2.12", + "10.1.2.13", + "10.1.2.14", + "10.1.2.15", + "10.1.2.16", + "10.1.2.17", + "10.1.2.18", + "10.1.2.19", + "10.1.2.20.PB" ], - "VPM-07": [ - "ISM-1163" + "DCH-01": [ + "5.1.1.10", + "5.1.1.14", + "8.2", + "8.2.3", + "8.2.3.1", + "13.2", + "13.2.1", + "13.2.1.10", + "13.2.1.12", + "13.2.1.13", + "13.2.1.14" ], - "WEB-07": [ - "ISM-0971", - "ISM-1239" + "DCH-01.3": [ + "8.2.3.3", + "8.2.3.4", + "8.3.1.3" ], - "WEB-08": [ - "ISM-1239" + "DCH-01.4": [ + "8.2.3.2" ], - "WEB-09": [ - "ISM-1240" + "DCH-02": [ + "8.2.1", + "8.2.1.1", + "8.2.1.2", + "8.2.1.3", + "8.2.1.4", + "8.2.1.5", + "8.2.1.6", + "8.2.1.7", + "8.2.1.8", + "8.2.1.9", + "8.2.1.10" ], - "WEB-10": [ - "ISM-1552" + "DCH-04": [ + "8.2.2", + "8.2.2.1", + "8.2.2.2", + "8.2.2.3", + "8.2.2.4", + "8.2.2.5", + "8.2.2.6", + "8.2.2.7.PB", + "8.2.3.6" ], - "WEB-11": [ - "ISM-1241" + "DCH-06": [ + "8.3.1.4" ], - "WEB-12": [ - "ISM-1424" - ] - }, - "apac-aus-cop-sitc-2020": { - "AST-18": [ - "Principle 4", - "Principle 7" + "DCH-06.1": [ + "8.3.1.4" ], - "EMB-02": [ - "Principle 11", - "Principle 13" + "DCH-07": [ + "8.3.3", + "8.3.3.1", + "8.3.3.2", + "8.3.3.3", + "8.3.3.4", + "8.3.3.5", + "13.2.2.5" ], - "EMB-04": [ - "Principle 6", - "Principle 13" + "DCH-07.1": [ + "8.3.1.10" ], - "EMB-05": [ - "Principle 8", - "Principle 10" + "DCH-08": [ + "8.3.2.4", + "8.3.2.5", + "8.3.2.6" ], - "EMB-06": [ - "Principle 6" + "DCH-09": [ + "11.2.7.3" ], - "EMB-07": [ - "Principle 3", - "Principle 12" + "DCH-09.1": [ + "8.3.2.7" ], - "EMB-08": [ - "Principle 9" + "DCH-14": [ + "13.2.1.5", + "13.2.1.9" ], - "END-06.5": [ - "Principle 8" + "DCH-18": [ + "4.4.7.4", + "4.6.3.4", + "12.3.1.15", + "12.3.1.19.P", + "13.2.1.7", + "18.1.3", + "18.1.3.1", + "18.1.3.2", + "18.1.3.3", + "18.1.3.4", + "18.1.3.5", + "18.1.3.6", + "18.1.3.7", + "18.1.3.8", + "18.1.3.9", + "18.1.3.10", + "18.1.3.11", + "18.1.3.12", + "18.1.3.13.PB" ], - "END-06.6": [ - "Principle 8" + "END-01": [ + "5.1.1.15", + "12.2.1.2" ], - "IAC-10.1": [ - "Principle 1" + "END-02": [ + "6.2.1", + "6.2.1.1", + "6.2.1.2", + "6.2.1.3", + "6.2.1.4", + "6.2.1.5", + "6.2.1.6", + "6.2.1.7", + "6.2.1.8", + "6.2.1.9", + "6.2.1.10", + "6.2.1.11", + "6.2.1.12", + "6.2.1.13", + "6.2.1.14", + "6.2.1.15", + "6.2.1.16", + "6.2.1.17", + "6.2.1.21", + "6.2.1.22" ], - "IAC-10.8": [ - "Principle 1" + "END-04": [ + "12.2", + "12.2.1", + "12.2.1.1", + "12.2.1.3", + "12.2.1.4", + "12.2.1.5", + "12.2.1.6", + "12.2.1.7", + "12.2.1.8", + "12.2.1.9", + "12.2.1.15" ], - "SEA-01": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" + "HRS-01": [ + "4.5.2.2", + "5.1.1.12", + "7", + "7.1", + "7.1.1.13" ], - "SEA-02": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" + "HRS-01.1": [ + "8.1.4.1", + "8.1.4.2", + "8.1.4.3", + "8.1.4.4", + "9.2.6.2", + "9.2.6.4", + "9.2.6.5", + "9.2.6.6" ], - "SEA-03": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" + "HRS-02": [ + "4.5.2.2" ], - "THR-06": [ - "Principle 2" - ] - }, - "apac-aus-ps-cps-230-2023": { - "GOV-01.1": [ - "20", - "21", - "22(a)", - "22(b)", - "22(c)", - "23", - "24", - "25" + "HRS-03": [ + "4.5.2.2", + "6.1.1", + "6.1.1.1", + "6.1.1.2", + "6.1.1.3", + "6.1.1.4", + "6.1.1.5", + "6.1.1.6", + "6.1.1.7", + "6.1.1.13.PB" ], - "GOV-01.2": [ - "30", - "58(a)", - "58(b)", - "58(c)" + "HRS-03.1": [ + "4.5.2.6", + "4.5.2.7", + "4.5.2.8", + "7.1.2.7", + "7.2", + "7.2.1.4", + "8.1.3.1" ], - "GOV-04": [ - "21", - "24" + "HRS-03.2": [ + "4.5.2.2", + "4.5.2.3", + "7.1.1.6", + "14.2.1.7", + "14.2.1.8", + "14.2.1.11" ], - "GOV-04.1": [ - "21" + "HRS-04": [ + "7.1.1", + "7.1.1.1", + "7.1.1.2", + "7.1.1.3", + "7.1.1.5", + "7.1.1.9", + "7.1.1.10" ], - "GOV-04.2": [ - "21" + "HRS-04.1": [ + "7.1.1.7", + "7.1.1.8" ], - "GOV-06": [ - "33", - "42", - "51", - "59(a)", - "59(b)" + "HRS-04.2": [ + "4.5.2.6", + "7.2", + "7.2.1.1", + "8.1.3.1" ], - "GOV-14": [ - "24" + "HRS-05": [ + "7.1.2", + "7.1.2.1", + "7.1.2.2", + "7.1.2.3", + "7.1.2.4", + "7.1.2.5", + "7.1.2.6", + "7.1.2.8", + "7.1.2.9", + "7.2.1", + "7.2.1.5", + "9.2.4.2" ], - "GOV-15": [ - "29" + "HRS-05.1": [ + "7.2.1.2", + "8.1.3", + "8.1.3.2" ], - "GOV-15.1": [ - "29" + "HRS-05.3": [ + "13.2.1.1", + "13.2.1.2", + "13.2.1.3", + "13.2.1.4", + "13.2.1.8", + "13.2.1.11" ], - "GOV-15.5": [ - "30" + "HRS-05.7": [ + "4.5.2.6", + "4.5.2.8", + "7.2", + "7.2.1.3", + "8.1.3.1" ], - "BCD-01": [ - "12(b)", - "14", - "34(a)", - "34(b)", - "34(c)", - "34(d)", - "34(e)", - "40(a)", - "40(b)", - "40(c)", - "40(d)", - "40(e)", - "41" + "HRS-06.1": [ + "13.2.4", + "13.2.4.1", + "13.2.4.2", + "13.2.4.3", + "13.2.4.4", + "13.2.4.5", + "13.2.4.6", + "13.2.4.7", + "13.2.4.8", + "13.2.4.9", + "13.2.4.10", + "13.2.4.11", + "13.2.4.12", + "13.2.4.13", + "13.2.4.14", + "13.2.4.15", + "13.2.4.16" ], - "BCD-01.4": [ - "38(a)", - "38(b)", - "38(c)", - "39" + "HRS-06.2": [ + "7.1.2.10" ], - "BCD-02": [ - "34(a)", - "35", - "36(a)", - "36(b)", - "36(c)", - "36(d)", - "37" + "HRS-07": [ + "7.2.3", + "7.2.3.1", + "7.2.3.2", + "7.2.3.3", + "7.2.3.4" ], - "BCD-02.1": [ - "34(e)" + "HRS-09": [ + "7.3", + "7.3.1", + "7.3.1.1", + "7.3.1.2", + "7.3.1.3" ], - "BCD-02.2": [ - "34(e)" + "HRS-10": [ + "7.1.1.10" ], - "BCD-02.3": [ - "34(e)" + "HRS-11": [ + "4.5.2.2", + "6.1.2", + "6.1.2.1", + "6.1.2.2", + "6.1.2.3", + "6.1.2.4" ], - "BCD-04": [ - "43", - "44", - "45", - "46" + "HRS-15": [ + "7.2.1.7" ], - "CPL-01": [ - "28" + "IAC-01": [ + "5.1.1.9", + "9", + "9.1", + "9.1.1", + "9.1.1.1", + "9.1.1.2", + "9.1.1.3", + "9.1.1.4", + "9.1.1.5", + "9.1.1.6", + "9.1.1.7", + "9.1.1.8", + "9.1.1.9", + "9.1.1.10", + "9.1.1.11", + "9.1.1.12", + "9.1.1.13", + "9.1.1.14", + "9.1.1.15", + "9.4.1.8.PB" ], - "CPL-01.1": [ - "30", - "31" + "IAC-01.2": [ + "9.4.2", + "9.4.2.1", + "9.4.2.2.B", + "9.4.2.3", + "9.4.2.4", + "9.4.2.5", + "9.4.2.6", + "9.4.2.7", + "9.4.2.8", + "9.4.2.9", + "9.4.2.10", + "9.4.2.11", + "9.4.2.12", + "9.4.2.13", + "9.4.2.14", + "9.4.2.15", + "9.4.2.16" ], - "CPL-02": [ - "29", - "30", - "58(b)", - "58(c)" + "IAC-07": [ + "9.2.2", + "9.2.2.2", + "9.2.2.3", + "9.2.2.4", + "9.2.2.6", + "9.2.2.8.PB", + "9.2.6", + "9.2.6.3" ], - "CPL-02.1": [ - "46", - "60" + "IAC-08": [ + "8.1.2.5", + "9.4", + "9.4.1", + "9.4.1.1", + "9.4.1.2", + "9.4.1.3", + "9.4.1.4", + "9.4.1.5", + "9.4.1.6", + "9.4.1.7" ], - "IRO-01": [ - "32" + "IAC-10": [ + "9.2.4", + "9.2.4.1", + "9.2.4.3", + "9.2.4.4", + "9.2.4.5", + "9.2.4.6", + "9.2.4.7", + "9.2.4.8" ], - "IRO-02": [ - "32" + "IAC-10.1": [ + "9.3.1.4", + "9.4.3", + "9.4.3.1", + "9.4.3.2", + "9.4.3.3", + "9.4.3.4", + "9.4.3.5", + "9.4.3.6", + "9.4.3.7", + "9.4.3.8", + "9.4.3.9" ], - "IRO-10": [ - "33", - "42" + "IAC-10.5": [ + "9.3", + "9.3.1", + "9.3.1.1", + "9.3.1.2", + "9.3.1.3", + "9.3.1.5", + "9.3.1.6", + "9.3.1.7" ], - "PRM-01": [ - "25" + "IAC-15": [ + "9.2", + "9.2.1", + "9.2.1.1", + "9.2.1.2", + "9.2.1.3", + "9.2.1.4", + "9.2.1.5", + "9.2.1.6.PB", + "9.2.4.9.PB" ], - "PRM-02": [ - "25" + "IAC-15.1": [ + "9.2.2.5" ], - "PRM-03": [ - "25" + "IAC-16": [ + "9.2.3", + "9.2.3.1", + "9.2.3.2", + "9.2.3.3", + "9.2.3.4", + "9.2.3.5", + "9.2.3.6", + "9.2.3.7", + "9.2.3.8", + "9.2.3.9", + "9.2.3.10" ], - "RSK-01": [ - "12(a)", - "12(c)", - "13", - "16(a)", - "16(b)", - "16(c)", - "16(d)", - "16(e)", - "16(f)", - "17", - "18", - "19(a)", - "19(b)", - "19(c)", - "19(d)", - "19(e)" + "IAC-17": [ + "9.2.2.7", + "9.2.5", + "9.2.5.1", + "9.2.5.2", + "9.2.5.3", + "9.2.5.4", + "9.2.5.5", + "9.2.5.6" ], - "RSK-01.3": [ - "26" + "IAC-20.3": [ + "9.4.4", + "9.4.4.1", + "9.4.4.2", + "9.4.4.3", + "9.4.4.4", + "9.4.4.5", + "9.4.4.6", + "9.4.4.7", + "9.4.4.8", + "9.4.4.9", + "9.4.4.10.P", + "9.4.4.11.P" ], - "RSK-01.4": [ - "26" + "IAC-20.6": [ + "9.2.6.1" ], - "RSK-01.5": [ - "26" + "IAC-21": [ + "9.1.2", + "9.1.2.1", + "9.1.2.2", + "9.1.2.3", + "9.1.2.4", + "9.1.2.5", + "9.1.2.6", + "9.1.2.7", + "9.1.2.8" ], - "RSK-04": [ - "27(a)", - "27(b)", - "27(c)", - "28" + "IAC-28": [ + "7.1.1.4" ], - "RSK-06": [ - "31" + "IAC-28.1": [ + "9.2.2.1" ], - "TPM-01": [ - "15", - "47", - "48(a)", - "48(b)", - "48(c)", - "57" + "IRO-01": [ + "16", + "16.1", + "16.1.1.2", + "16.1.1.4", + "16.1.1.5", + "16.1.1.6.P", + "16.1.1.7.P", + "16.1.1.8.P", + "16.1.1.9.P", + "16.1.1.10.P", + "16.1.1.11.P", + "16.1.1.12.P" ], - "TPM-01.1": [ - "49" + "IRO-02": [ + "16.1.1", + "16.1.1.1", + "16.1.1.3", + "16.1.2", + "16.1.2.1", + "16.1.2.2", + "16.1.2.3", + "16.1.2.4", + "16.1.2.5", + "16.1.2.6", + "16.1.2.7", + "16.1.2.8", + "16.1.2.9", + "16.1.2.10", + "16.1.2.11.P", + "16.1.2.12.P", + "16.1.2.13.P", + "16.1.3", + "16.1.3.1", + "16.1.3.2", + "16.1.5.9" ], - "TPM-02": [ - "50(a)", - "50(b)", - "50(c)", - "50(d)", - "52" + "IRO-02.4": [ + "16.1.4", + "16.1.4.1", + "16.1.4.2" ], - "TPM-03.2": [ - "56(a)", - "56(b)", - "56(c)", - "56(d)" + "IRO-04": [ + "16.1.5", + "16.1.5.1", + "16.1.5.2", + "16.1.5.3", + "16.1.5.4", + "16.1.5.5", + "16.1.5.6", + "16.1.5.7", + "16.1.5.8" ], - "TPM-04.1": [ - "15", - "53(a)", - "53(b)" + "IRO-04.3": [ + "16.1.1.14" ], - "TPM-05": [ - "15", - "54(a)", - "54(b)", - "54(c)", - "54(d)", - "54(e)", - "54(f)", - "54(g)", - "55(a)", - "55(b)", - "55(c)" + "IRO-08": [ + "16.1.7", + "16.1.7.1", + "16.1.7.2", + "16.1.7.3", + "16.1.7.4", + "16.1.7.5", + "16.1.7.6", + "16.1.7.7", + "16.1.7.8", + "16.1.7.9", + "16.1.7.10", + "16.1.7.11", + "16.1.7.12", + "16.1.7.13.PB" ], - "TPM-05.7": [ - "50(g)" + "IRO-09.2": [ + "16.1.5.10" ], - "TPM-08": [ - "58(a)", - "58(b)", - "58(c)" - ] - }, - "apac-aus-ps-cps-234-2019": { - "GOV-01": [ - "13", - "18", - "19" + "IRO-10": [ + "6.1.3.2" ], - "GOV-01.1": [ - "13", - "19" + "IRO-10.4": [ + "16.1.1.15.P" ], - "GOV-02": [ - "18", - "19" + "IRO-13": [ + "16.1.6", + "16.1.6.1", + "16.1.6.2" ], - "GOV-03": [ - "19" + "IRO-15": [ + "12.2.1.14" ], - "GOV-04": [ - "14", - "19" + "IAO-02": [ + "14.1.1.12", + "14.1.1.17", + "14.1.1.18", + "14.2.7.4", + "14.2.9", + "14.2.9.1", + "14.2.9.2", + "14.2.9.3", + "14.2.9.4" ], - "GOV-06": [ - "35", - "35(a)", - "35(b)", - "36" + "IAO-03": [ + "4.4.4", + "4.4.5.2" ], - "AST-01": [ - "21", - "21(c)" + "IAO-03.2": [ + "13.2.2", + "13.2.2.2", + "13.2.2.3", + "13.2.2.4", + "13.2.2.6", + "13.2.2.7", + "13.2.2.8", + "13.2.2.9", + "13.2.2.10", + "13.2.2.11" ], - "AST-01.1": [ - "21(a)" + "IAO-05": [ + "4.4.6.1", + "4.7.1.4", + "4.7.1.7" ], - "BCD-02": [ - "21(b)" + "MNT-01": [ + "11.2.4", + "11.2.4.1", + "11.2.4.3", + "11.2.4.5" ], - "CHG-03": [ - "21(d)" + "MNT-02": [ + "11.2.4.4" ], - "CPL-01": [ - "31", - "35", - "35(a)", - "35(b)", - "36" + "MNT-04.3": [ + "11.2.5", + "11.2.5.1", + "11.2.5.2", + "11.2.5.3", + "11.2.5.4" ], - "CPL-01.1": [ - "29", - "35", - "35(a)", - "35(b)", - "36" + "MNT-05": [ + "11.2.4.8", + "11.2.4.9", + "11.2.4.10" ], - "CPL-02": [ - "27", - "27(a)", - "27(b)", - "27(c)", - "27(d)", - "27(e)", - "29" + "MNT-05.1": [ + "11.2.4.7" ], - "CPL-02.1": [ - "31", - "32", - "33", - "34", - "34(a)", - "34(b)" + "MNT-05.4": [ + "11.2.4.11" ], - "CPL-03": [ - "30" + "MNT-05.5": [ + "11.2.4.7" ], - "CPL-03.1": [ - "30" + "MNT-06": [ + "11.2.4.2" ], - "DCH-01": [ - "20", - "21(a)" + "MNT-09": [ + "11.2.6", + "11.2.6.1", + "11.2.6.2", + "11.2.6.3", + "11.2.6.4", + "11.2.6.5", + "11.2.6.6" ], - "DCH-02": [ - "20", - "21(a)" + "MNT-10": [ + "11.2.4.6" ], - "HRS-03": [ - "14" + "MDM-06": [ + "6.2.1.23" ], - "IRO-01": [ - "23", - "24" + "NET-01": [ + "5.1.1.18", + "13", + "13.1", + "13.1.1", + "13.1.1.1", + "13.1.1.2", + "13.1.1.3", + "13.1.1.5", + "13.1.1.6", + "13.1.1.7", + "13.1.1.8", + "13.1.1.9", + "13.1.2" ], - "IRO-02": [ - "23", - "24" + "NET-01.1": [ + "9.1.1.16" ], - "IRO-04": [ - "23", - "24", - "25(a)", - "25(b)" + "NET-03.3": [ + "14.1.1.23" ], - "IRO-06": [ - "26" + "NET-05.2": [ + "13.1.1.10" ], - "IRO-07": [ - "23", - "24", - "25(a)", - "25(b)" + "NET-06": [ + "13.1.3", + "13.1.3.1", + "13.1.3.2", + "13.1.3.3", + "13.1.3.4", + "13.1.3.5", + "13.1.3.6", + "13.1.3.7", + "13.1.3.8", + "13.1.3.9", + "13.1.3.10.P", + "13.1.3.11.P", + "13.1.3.12.P", + "13.1.4.P" ], - "IRO-09": [ - "23", - "24" + "NET-06.1": [ + "13.1.4.P" ], - "IRO-13": [ - "25(a)" + "NET-06.2": [ + "13.1.4.P" ], - "PRM-01": [ - "13", - "15" + "NET-06.3": [ + "13.1.4.P" ], - "PRM-01.1": [ - "13", - "15" + "NET-12": [ + "13.1.1.4", + "14.1.2", + "14.1.2.1", + "14.1.2.2", + "14.1.2.3", + "14.1.2.4", + "14.1.2.5", + "14.1.2.6", + "14.1.2.7", + "14.1.2.8", + "14.1.2.9", + "14.1.2.10", + "14.1.2.11", + "14.1.2.12", + "14.1.2.13", + "14.1.2.14", + "14.1.2.15" ], - "PRM-01.2": [ - "15" + "NET-13": [ + "13.2.2.12", + "13.2.2.13", + "13.2.3", + "13.2.3.1", + "13.2.3.2", + "13.2.3.3", + "13.2.3.4", + "13.2.3.5", + "13.2.3.6", + "13.2.3.7.P" ], - "PRM-02": [ - "13", - "15" + "NET-14.5": [ + "6.2", + "6.2.2", + "6.2.2.1", + "6.2.2.2", + "6.2.2.3", + "6.2.2.4", + "6.2.2.5", + "6.2.2.6", + "6.2.2.7", + "6.2.2.8", + "6.2.2.9", + "6.2.2.10", + "6.2.2.11", + "6.2.2.12", + "6.2.2.13", + "6.2.2.14", + "6.2.2.15", + "6.2.2.16", + "6.2.2.17", + "6.2.2.18", + "6.2.2.19", + "6.2.2.20", + "6.2.2.21" ], - "PRM-03": [ - "15" + "PES-01": [ + "5.1.1.11", + "11", + "11.1", + "11.1.4", + "11.1.4.1", + "11.2.1.3" ], - "PRM-07": [ - "21(c)" + "PES-02": [ + "11.1.2.3", + "11.1.2.12" ], - "RSK-08": [ - "21(d)" + "PES-03": [ + "11.1.1", + "11.1.1.1", + "11.1.1.2", + "11.1.1.3", + "11.1.1.4", + "11.1.1.5", + "11.1.1.6", + "11.1.1.7", + "11.1.2", + "11.1.2.1", + "11.1.2.2", + "11.1.2.5", + "11.1.2.10" ], - "RSK-10": [ - "21(d)" + "PES-03.3": [ + "11.1.2.7" ], - "SEA-01": [ - "15", - "18" + "PES-04": [ + "11.1.2.6", + "11.1.3", + "11.1.3.1", + "11.1.3.2", + "11.1.3.3", + "11.1.3.4", + "11.2.9", + "11.2.9.1", + "11.2.9.2", + "11.2.9.3", + "11.2.9.4", + "11.2.9.5", + "11.2.9.6" ], - "SEA-01.1": [ - "18" + "PES-04.1": [ + "11.1.2.11", + "11.1.5", + "11.1.5.1", + "11.1.5.2", + "11.1.5.3", + "11.1.5.4", + "11.1.5.5", + "11.1.5.6" ], - "SEA-02": [ - "15", - "18" + "PES-05": [ + "11.1.2.13" ], - "SEA-03": [ - "15", - "18" + "PES-06": [ + "11.1.2.4" ], - "TDA-06.1": [ - "21(b)" + "PES-06.1": [ + "11.1.2.8" ], - "TPM-01": [ - "16", - "20", - "22", - "28" + "PES-06.3": [ + "11.1.2.9" ], - "TPM-02": [ - "21(b)" + "PES-07": [ + "11.2.2", + "11.2.2.1", + "11.2.2.2", + "11.2.2.3", + "11.2.2.4", + "11.2.2.5" ], - "TPM-03": [ - "22", - "28" + "PES-07.2": [ + "11.2.2.7" ], - "TPM-03.2": [ - "22" + "PES-07.4": [ + "11.2.2.6" ], - "TPM-04": [ - "16", - "22", - "28" + "PES-10": [ + "11.1.6", + "11.1.6.1", + "11.1.6.2", + "11.1.6.3", + "11.1.6.4", + "11.1.6.5", + "11.1.6.6", + "11.1.6.7" ], - "TPM-04.1": [ - "22", - "28" + "PES-12": [ + "11.2", + "11.2.1", + "11.2.1.1", + "11.2.1.2", + "11.2.1.4", + "11.2.1.5", + "11.2.1.6", + "11.2.1.7", + "11.2.1.8", + "11.2.1.9", + "11.2.1.10", + "11.2.7.4.PB" ], - "TPM-05": [ - "16", - "20", - "28" + "PES-12.1": [ + "11.2.3", + "11.2.3.1", + "11.2.3.2", + "11.2.3.3" ], - "TPM-08": [ - "28" + "PRI-01": [ + "5.1.1", + "5.1.1.19", + "18.1.4" ], - "THR-01": [ - "17" + "PRI-01.3": [ + "5.1.1" ], - "VPM-01": [ - "17" + "PRI-01.11": [ + "7.1.1.12", + "18.1.4", + "18.1.4.1", + "18.1.4.2", + "18.1.4.3", + "18.1.4.4", + "18.1.4.5", + "18.1.4.6" ], - "VPM-02": [ - "21" + "PRM-01": [ + "4.5.1.1" ], - "VPM-04": [ - "21" + "PRM-01.1": [ + "5.1.1.2" ], - "VPM-05": [ - "21" - ] - }, - "apac-chn-cybersecurity-law-2017": { - "GOV-12": [ - "Article 28" + "PRM-01.2": [ + "4.4.5.2" ], - "GOV-13": [ - "Article 28" + "PRM-02": [ + "4.5.1.1", + "4.5.5.3" ], - "GOV-17": [ - "Article 38", - "Article 54(1)" + "PRM-02.1": [ + "4.5.5.3" ], - "BCD-01": [ - "Article 33", - "Article 34(4)" + "PRM-03": [ + "4.5.1.2", + "4.5.5.3" ], - "BCD-04": [ - "Article 34(4)" + "PRM-04": [ + "4.5.1.1", + "6.1.5", + "6.1.5.1" ], - "BCD-11": [ - "Article 34(3)" + "PRM-05": [ + "4.4.3.1", + "4.4.5.2", + "4.5.1.1", + "6.1.5.2", + "14.1.1.2" ], - "CPL-01": [ - "Article 9", - "Article 10", - "Article 21", - "Article 23", - "Article 26", - "Article 27", - "Article 34", - "Article 34(5)", - "Article 41", - "Article 47" + "PRM-06": [ + "4.4.3.1", + "4.4.5.2", + "4.5.1.1", + "6.1.5.5", + "13.1.2", + "14.1.1.2" ], - "CPL-03.1": [ - "Article 38" + "PRM-07": [ + "6.1.5.4", + "14.1" ], - "CPL-05": [ - "Article 72" + "RSK-01": [ + "4.4.6.1", + "4.5.5.2", + "4.8.1.1" ], - "CPL-05.2": [ - "Article 28", - "Article 55", - "Article 56" + "RSK-01.1": [ + "4.4.6.1", + "4.4.7.2", + "4.4.7.3" ], - "CPL-06": [ - "Article 28", - "Article 29" + "RSK-01.3": [ + "4.4.7.1" ], - "DCH-01": [ - "Article 40" + "RSK-01.4": [ + "4.4.7.1" ], - "DCH-26": [ - "Article 37" + "RSK-01.5": [ + "4.4.7.1" ], - "HRS-01": [ - "Article 34(1)" + "RSK-03": [ + "4.4.6.1", + "4.4.7.2" ], - "IAC-01": [ - "Article 40" + "RSK-03.1": [ + "4.4.7.2" ], - "IRO-04": [ - "Article 25" + "RSK-04": [ + "4.4.6.1", + "4.4.7.1", + "4.4.7.2", + "4.4.7.3", + "4.4.7.4", + "4.6.1.1", + "6.1.5.3" ], - "IAO-02": [ - "Article 35" + "RSK-04.1": [ + "4.4.7.2" ], - "PRI-01.6": [ - "Article 42" + "RSK-04.2": [ + "4.4.6.1", + "4.4.7.1", + "4.4.7.4" ], - "PRI-03": [ - "Article 22" + "RSK-04.3": [ + "4.4.7.3", + "4.5.5.1" ], - "PRI-05.4": [ - "Article 41", - "Article 44" + "RSK-06": [ + "4.6.1.1", + "4.7.1.1" ], - "PRI-06.1": [ - "Article 43" + "RSK-06.1": [ + "4.4.7.4", + "4.4.8.1", + "4.4.8.2", + "4.4.8.5", + "4.7.1.3", + "4.7.1.6" ], - "PRI-06.4": [ - "Article 43" + "RSK-06.2": [ + "4.4.8.1", + "4.4.8.2" ], - "PRI-06.5": [ - "Article 43" + "RSK-06.3": [ + "4.4.7.1", + "4.4.8.1", + "4.4.8.2" ], - "PRI-16": [ - "Article 24" + "RSK-06.4": [ + "4.4.6.1", + "4.4.7.1", + "4.4.8.1", + "4.4.8.2", + "4.4.8.3", + "4.4.8.4", + "4.4.8.5", + "4.5.5.2", + "4.7.1.1", + "4.7.1.4", + "4.9" ], - "SAT-01": [ - "Article 34(2)" + "RSK-08": [ + "4.4.7.3" ], - "TDA-01.1": [ - "Article 22", - "Article 46", - "Article 48" + "SEA-01": [ + "14.2.5", + "14.2.5.1", + "14.2.5.2", + "14.2.5.3", + "14.2.5.4", + "14.2.5.5", + "14.2.5.6", + "14.2.5.7" ], - "TPM-05": [ - "Article 36" - ] - }, - "apac-chn-data-security-law-2021": { - "GOV-04": [ - "45", - "46" + "SEA-02.2": [ + "4.5.4.5" ], - "GOV-12": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "SEA-05": [ + "9.5.P" ], - "GOV-13": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "SEA-20": [ + "12.4.4", + "12.4.4.1", + "12.4.4.2", + "12.4.4.3", + "12.4.4.4.PB" ], - "CHG-04.4": [ - "27" + "OPS-01": [ + "12", + "12.1", + "12.1.3.9.PB" ], - "CPL-01": [ - "46" + "OPS-01.1": [ + "8.3.1.11", + "12.1.1", + "12.1.1.1", + "12.1.1.2", + "12.1.1.3", + "12.1.1.4", + "12.1.1.5", + "12.1.1.6", + "12.1.1.7", + "12.1.1.8", + "12.1.1.9", + "12.1.1.10", + "12.1.1.11", + "12.1.1.12", + "12.1.1.13", + "12.1.5.P", + "12.1.5.1.PB" ], - "CPL-06": [ - "24", - "27", - "31", - "33", - "44" + "OPS-03": [ + "13.1.1.11.P", + "13.1.4.1.P", + "13.1.4.2.P", + "14.1.1.19.P", + "14.1.1.20.P" ], - "DCH-26": [ - "36" + "SAT-01": [ + "7.2.2.1", + "7.2.2.2", + "7.2.2.3", + "7.2.2.4", + "7.2.2.5", + "7.2.2.6", + "7.2.2.17", + "7.2.2.18" ], - "HRS-03": [ - "27" + "SAT-01.1": [ + "4.5.2.4", + "4.5.2.5" ], - "HRS-04.1": [ - "27" + "SAT-02": [ + "6.2.1.20", + "7.2.2", + "7.2.2.7", + "7.2.2.8", + "7.2.2.9", + "7.2.2.10", + "7.2.2.11", + "7.2.2.12", + "7.2.2.13", + "7.2.2.15", + "7.2.2.25" ], - "HRS-12": [ - "27" + "SAT-03": [ + "4.5.2.4", + "4.5.3.1", + "7.2.1.6", + "7.2.2.14", + "7.2.2.19.PB" ], - "IAC-07.1": [ - "27" + "SAT-03.3": [ + "7.2.2.16", + "7.2.2.19.PB" ], - "IAC-08": [ - "27" + "SAT-03.7": [ + "4.5.2.4" ], - "PES-02.1": [ - "27" + "SAT-04": [ + "4.5.2.4", + "4.5.2.5" ], - "PRI-16": [ - "7", - "8", - "9", - "11", + "TDA-01": [ "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "14.2", + "14.2.1", + "14.2.1.13.PB", + "14.2.7" ], - "SAT-03": [ - "27" - ] - }, - "apac-chn-csnip-2012": { - "GOV-01": [ - "4" + "TDA-01.1": [ + "14.1.1", + "14.2.7.11" ], - "CPL-01": [ - "4" + "TDA-02": [ + "14.1.1.2", + "14.1.1.3", + "14.1.1.4", + "14.1.1.5", + "14.1.1.6", + "14.1.1.7", + "14.1.1.8", + "14.1.1.9", + "14.1.1.10", + "14.1.1.11", + "14.1.1.16", + "14.2.1.3" ], - "CPL-02": [ - "4" + "TDA-04": [ + "14.1.1.15", + "14.2.7.10" ], - "DCH-01": [ - "4" + "TDA-06": [ + "14.1.1.1", + "14.2.1.2", + "14.2.1.9", + "14.2.1.10" ], - "DCH-22.1": [ - "8" + "TDA-06.2": [ + "14.2.7.3" ], - "PRI-01": [ - "Inferred", - "Expectation" + "TDA-07": [ + "14.2.1.1", + "14.2.6", + "14.2.6.1", + "14.2.6.2", + "14.2.6.3", + "14.2.6.4", + "14.2.6.5", + "14.2.6.6", + "14.2.6.7", + "14.2.6.8", + "14.2.6.9", + "14.2.6.10", + "14.2.6.11", + "14.2.6.12" ], - "PRI-06.1": [ - "8" + "TDA-08": [ + "12.1.4", + "12.1.4.1", + "12.1.4.2", + "12.1.4.3", + "12.1.4.4", + "12.1.4.5", + "12.1.4.6", + "12.1.4.7", + "12.1.4.8", + "12.1.4.9" ], - "SEA-01": [ - "4" + "TDA-08.1": [ + "14.2.6.11" ], - "SEA-02": [ - "4" + "TDA-09": [ + "14.2.1.4", + "14.2.7.5", + "14.2.7.6", + "14.2.7.7", + "14.2.8", + "14.2.8.1", + "14.2.8.2", + "14.2.8.3" ], - "SEA-03": [ - "4" - ] - }, - "apac-chn-pipl-2021": { - "GOV-01": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" + "TDA-10": [ + "14.3", + "14.3.1", + "14.3.1.1", + "14.3.1.2", + "14.3.1.3", + "14.3.1.4", + "14.3.1.5", + "14.3.1.6" ], - "GOV-04": [ - "52" + "TDA-18": [ + "14.2.5.9" ], - "GOV-10": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" + "TDA-20": [ + "9.4.5", + "9.4.5.1", + "9.4.5.2", + "9.4.5.3", + "9.4.5.4", + "9.4.5.5", + "9.4.5.6", + "9.4.5.7", + "9.4.5.8", + "9.4.5.9", + "14.2.1.5" ], - "GOV-12": [ - "38", - "38(4)", - "40" + "TDA-20.1": [ + "14.2.1.6" ], - "GOV-13": [ - "11", - "12", - "38(4)", - "40", - "47(5)", - "60", - "63(3)", - "63(4)", - "64" + "TDA-20.3": [ + "14.2.7.8" ], - "AST-20": [ - "26" + "TPM-01": [ + "4.5.3.1", + "5.1.1.20", + "5.1.1.31.P", + "15", + "15.1", + "15.1.1", + "15.1.1.1", + "15.1.1.2", + "15.1.1.3", + "15.1.1.4", + "15.1.1.5", + "15.1.1.6", + "15.1.1.7", + "15.1.1.8", + "15.1.1.9", + "15.1.1.10", + "15.1.1.11", + "15.1.1.12", + "15.1.1.13", + "15.1.1.14.B" ], - "CLD-09": [ - "38", - "39", - "40" + "TPM-04.1": [ + "14.1.1.14", + "15.1.1.16.B" ], - "CPL-01": [ - "32", - "37", - "38(4)", - "42" + "TPM-05": [ + "6.3.P", + "7.1.1.11", + "8.2.3.7", + "13.1.2", + "13.1.2.2", + "14.1.1.13", + "14.2.1.12", + "14.2.7.1", + "14.2.7.2", + "14.2.7.9", + "15.1.2", + "15.1.2.1", + "15.1.2.2", + "15.1.2.3", + "15.1.2.4", + "15.1.2.5", + "15.1.2.6", + "15.1.2.7", + "15.1.2.8", + "15.1.2.9", + "15.1.2.10", + "15.1.2.11", + "15.1.2.12", + "15.1.2.13", + "15.1.2.14", + "15.1.2.15", + "15.1.2.16", + "15.1.2.17", + "15.1.2.18.PB", + "15.1.3", + "15.1.3.1", + "15.1.3.2", + "15.1.3.3", + "15.1.3.4", + "15.1.3.5", + "15.1.3.6", + "15.1.3.7", + "15.1.3.8", + "15.1.3.9", + "15.1.3.10.P", + "15.1.3.11.P", + "15.2" ], - "CPL-01.1": [ - "54" + "TPM-05.4": [ + "6.1.1.8", + "6.1.1.9", + "6.1.1.10", + "6.1.1.11", + "6.1.1.12", + "6.1.5.6", + "6.3.1.P" ], - "CPL-02": [ - "54" + "TPM-08": [ + "13.1.2.1", + "15.2.1", + "15.2.1.1", + "15.2.1.2", + "15.2.1.3", + "15.2.1.4", + "15.2.1.5", + "15.2.1.6", + "15.2.1.7", + "15.2.1.8", + "15.2.1.9", + "15.2.1.10", + "15.2.1.11", + "15.2.1.12", + "15.2.1.13" ], - "CPL-02.1": [ - "54" + "TPM-10": [ + "15.2.1.14", + "15.2.1.15", + "15.2.2", + "15.2.2.1", + "15.2.2.2", + "15.2.2.3" ], - "CPL-03": [ - "38(1)", - "38(2)", - "40" + "THR-01": [ + "5.1.1.4" ], - "CPL-03.1": [ - "38(1)", - "38(2)", - "40" + "THR-03": [ + "4.9", + "4.9.2.2", + "6.1.4.3", + "12.2.1.12", + "12.2.1.13" ], - "CPL-03.2": [ - "54" + "THR-03.1": [ + "4.9", + "4.9.1.1", + "4.9.2.1", + "4.9.2.2" ], - "CPL-05": [ - "41" + "VPM-01": [ + "5.1.1.16", + "12.6", + "12.6.1", + "12.6.1.1", + "12.6.1.2", + "12.6.1.3", + "12.6.1.4", + "12.6.1.5", + "12.6.1.6", + "12.6.1.7", + "12.6.1.8", + "12.6.1.9", + "12.6.1.11", + "12.6.1.12", + "12.6.1.13", + "12.6.1.15", + "12.6.1.16", + "12.6.1.17", + "12.6.1.18.PB" ], - "CPL-05.1": [ - "18" + "VPM-02": [ + "12.6.1.14" ], - "CPL-05.2": [ - "61(4)", - "63", - "63(1)", - "63(2)", - "63(3)", - "63(4)", - "64" + "VPM-05": [ + "12.6.1.10" + ] + }, + "apac-mys-pdpa-2010": { + "PRI-01.5": [ + "129(1)", + "129(2)", + "129(2)(a)", + "129(2)(b)", + "129(3)", + "129(3)(a)", + "129(3)(b)", + "129(3)(c)", + "129(3)(c)(i)", + "129(3)(c)(ii)", + "129(3)(d)", + "129(3)(e)", + "129(3)(e)(i)", + "129(3)(e)(ii)", + "129(3)(e)(iii)", + "129(3)(f)", + "129(3)(g)", + "129(3)(h)", + "129(4)", + "129(4)(a)", + "129(4)(b)" ], - "CPL-06": [ - "11", - "12", - "26", - "38(4)", - "40", - "47(5)", - "60", - "61(4)", - "63(3)", - "63(4)", - "64" + "PRI-01.6": [ + "9(1)", + "9(1)(a)", + "9(1)(b)", + "9(1)(c)", + "9(1)(d)", + "9(1)(e)", + "9(2)", + "9(2)(a)", + "9(2)(b)" ], - "MON-10": [ - "19" + "PRI-01.11": [ + "5(1)", + "5(1)(a)", + "5(1)(b)", + "5(1)(c)", + "5(1)(d)", + "5(1)(e)", + "5(1)(f)", + "5(1)(g)", + "130(1)", + "130(1)(a)", + "130(1)(b)", + "130(2)", + "130(2)(a)", + "130(2)(a)(i)", + "130(2)(a)(ii)", + "130(2)(b)", + "130(2)(c)", + "130(2)(d)", + "130(3)", + "130(4)", + "130(5)", + "130(5)(a)", + "130(5)(b)", + "130(6)" ], - "DCH-18": [ - "19" + "PRI-02": [ + "7(1)", + "7(1)(a)", + "7(1)(b)", + "7(1)(c)", + "7(1)(d)", + "7(1)(e)", + "7(1)(f)", + "7(1)(g)", + "7(1)(h)", + "7(2)", + "7(2)(a)", + "7(2)(b)", + "7(2)(c)", + "7(2)(c)(i)", + "7(2)(c)(ii)" ], - "DCH-18.2": [ - "6" + "PRI-03": [ + "7(3)" ], - "DCH-19": [ - "38", - "39", - "40" + "PRI-03.4": [ + "38(1)", + "43(1)" ], - "DCH-22": [ - "8" + "PRI-03.10": [ + "38(2)", + "42(1)", + "42(1)(a)" ], - "DCH-22.1": [ - "46", - "49" + "PRI-05": [ + "10(1)", + "10(2)" ], - "DCH-26": [ - "36", - "38", - "40" + "PRI-05.2": [ + "11" ], - "EMB-02": [ - "26" + "PRI-05.4": [ + "6(1)(a)", + "6(2)", + "6(2)(a)", + "6(2)(b)", + "6(2)(c)", + "6(2)(d)", + "6(2)(e)", + "6(2)(f)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "8", + "8(a)", + "8(a)(i)", + "8(a)(ii)", + "8(b)", + "39", + "39(a)", + "39(b)", + "39(b)(i)", + "39(b)(ii)", + "39(c)", + "39(d)", + "39(e)", + "40(1)", + "40(1)(a)", + "40(1)(b)", + "40(1)(b)(i)", + "40(1)(b)(ii)", + "40(1)(b)(ii)(A)", + "40(1)(b)(ii)(B)", + "40(1)(b)(iii)", + "40(1)(b)(iv)", + "40(1)(b)(iv)(A)", + "40(1)(b)(iv)(B)", + "40(1)(b)(v)", + "40(1)(b)(vi)", + "40(1)(b)(vii)", + "40(1)(b)(viii)", + "40(1)(b)(ix)", + "40(1)(b)(x)", + "40(1)(c)", + "42(1)(b)", + "42(1)(b)(A)", + "42(1)(b)(B)", + "42(2)", + "42(2)(a)", + "42(2)(b)", + "42(2)(b)(i)", + "42(2)(b)(ii)", + "42(2)(b)(iii)", + "42(2)(b)(iv)", + "42(2)(c)", + "42(3)", + "42(3)(a)", + "42(3)(b)", + "42(4)", + "42(5)" ], - "END-14": [ - "26" + "PRI-06": [ + "12", + "30(1)", + "30(2)(a)", + "30(2)(b)", + "34(1)(a)", + "34(1)(b)", + "34(2)" ], - "IRO-02": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "PRI-06.1": [ + "35(1)", + "35(1)(a)", + "35(1)(b)", + "35(1)(c)", + "35(1)(c)(i)", + "35(1)(c)(ii)", + "35(2)", + "35(2)(a)", + "35(2)(b)", + "35(3)", + "35(4)", + "35(4)(a)", + "35(4)(b)", + "35(5)", + "35(5)(a)", + "35(5)(b)" ], - "IRO-04": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "PRI-06.2": [ + "37(1)", + "37(1)(a)", + "37(1)(b)" ], - "IRO-04.1": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "PRI-06.4": [ + "30(3)", + "30(4)", + "30(5)", + "31(1)", + "31(2)", + "31(2)(a)", + "31(2)(b)", + "31(3)", + "32(1)", + "32(1)(a)", + "32(1)(b)", + "32(1)(c)", + "32(2)", + "32(2)(a)", + "32(2)(b)", + "32(2)(c)", + "32(2)(d)", + "32(3)", + "33", + "33(a)", + "33(b)" ], - "IRO-10.2": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "PRI-06.8": [ + "32(1)(a)(i)", + "32(1)(a)(ii)", + "32(1)(a)(ii)(A)", + "32(1)(a)(ii)(B)" ], - "PES-05.1": [ - "26" + "PRI-07.4": [ + "36(1)", + "36(1)(a)", + "36(1)(a)(i)", + "36(1)(a)(ii)", + "36(1)(a)(ii)(A)", + "36(1)(a)(ii)(B)", + "36(1)(b)", + "36(1)(c)", + "36(1)(d)", + "36(1)(e)", + "36(2)" ], - "PRI-01": [ - "7", - "16", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)", - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)", - "59" + "PRI-07.5": [ + "32(1)(d)", + "32(1)(d)(i)", + "32(1)(d)(ii)", + "32(1)(e)", + "32(1)(f)", + "32(1)(g)", + "32(1)(h)" ], - "PRI-01.1": [ - "9", - "52" + "PRI-14": [ + "44(1)" ], - "PRI-01.3": [ - "9", - "48" + "PRI-17.3": [ + "37(2)", + "37(2)(a)", + "37(2)(a)(i)", + "37(2)(a)(ii)", + "37(2)(b)", + "37(3)" + ] + }, + "apac-mys-bnm-rmit-2025": { + "GOV-01": [ + "10.1", + "11.1", + "11.2", + "11.5" ], - "PRI-01.4": [ - "9", - "52", - "53" + "GOV-01.1": [ + "8.2", + "8.3", + "8.4", + "8.5", + "8.7", + "11.17", + "12.3" ], - "PRI-01.6": [ - "9", - "25", - "28", - "59" + "GOV-01.2": [ + "8.4", + "8.6", + "9.3", + "9.5" ], - "PRI-01.7": [ - "20", - "21", - "22", - "25", - "41" + "GOV-01.3": [ + "8.2", + "8.4" ], - "PRI-02": [ - "7", - "17", - "17(1)", - "17(2)", - "17(3)", - "17(4)", - "27", - "39", - "48" + "GOV-02": [ + "8.6", + "9.5", + "10.16", + "10.20", + "11.12" ], - "PRI-02.1": [ - "6", - "48" + "GOV-03": [ + "9.5" ], - "PRI-02.2": [ - "24" + "GOV-04": [ + "8.6", + "9.4" ], - "PRI-03": [ - "13(1)", - "14", - "23", - "27", - "29", - "30", - "44" - ], - "PRI-03.2": [ - "14", - "22", - "23", - "27" - ], - "PRI-03.3": [ - "10" + "GOV-04.1": [ + "8.6", + "10.35", + "11.8" ], - "PRI-03.4": [ - "15" + "GOV-04.2": [ + "11.8" ], - "PRI-03.5": [ - "16" + "GOV-05": [ + "8.6" ], - "PRI-04": [ - "26", - "31" + "GOV-05.2": [ + "8.1" ], - "PRI-04.1": [ - "5", - "10", - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "26", - "29", - "30", - "47" + "GOV-14": [ + "9.5" ], - "PRI-04.2": [ - "10" + "GOV-15": [ + "9.5" ], - "PRI-04.3": [ - "26" + "GOV-16": [ + "10.2" ], - "PRI-05": [ - "10", - "19", - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)" + "GOV-16.1": [ + "10.2" ], - "PRI-05.1": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "28", - "47" + "GOV-17": [ + "16.1", + "17.2", + "17.5" ], - "PRI-05.2": [ - "8" + "AST-01": [ + "10.17" ], - "PRI-05.4": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "28", - "29", - "30", - "31", - "32" + "AST-01.1": [ + "9.2", + "11.3" ], - "PRI-05.7": [ - "51(2)" + "AST-02": [ + "11.3" ], - "PRI-06": [ - "45", - "46", - "49" + "AST-02.9": [ + "11.3" ], - "PRI-06.1": [ - "46", - "49" + "AST-04": [ + "10.41" ], - "PRI-06.2": [ - "22", - "46", - "49" + "AST-30": [ + "10.13" ], - "PRI-06.4": [ - "45", - "46", - "50" + "BCD-01": [ + "8.2", + "8.6", + "10.24", + "10.44" ], - "PRI-06.5": [ - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)", - "49" + "BCD-01.4": [ + "10.32" ], - "PRI-06.7": [ - "45" + "BCD-01.5": [ + "10.24", + "10.32" ], - "PRI-07": [ - "20", - "21", - "22", - "27", - "38(3)", - "41", - "42", - "49" + "BCD-01.6": [ + "11.15" ], - "PRI-07.1": [ - "20", - "21", - "27", - "38(3)", - "42" + "BCD-02": [ + "9.2", + "10.26", + "11.3" ], - "PRI-07.2": [ - "20", - "21", - "27", - "38(3)" + "BCD-02.2": [ + "10.25", + "10.26" ], - "PRI-07.3": [ - "46" + "BCD-10.4": [ + "11.15" ], - "PRI-07.4": [ - "45", - "46", - "49" + "BCD-11": [ + "10.44" ], - "PRI-07.5": [ - "45", - "46", - "49" + "BCD-11.1": [ + "10.44" ], - "PRI-10": [ - "8" + "BCD-11.2": [ + "10.44" ], - "PRI-16": [ - "11", - "12", - "18", - "26", - "38(4)", - "40", - "47(5)" + "BCD-11.4": [ + "10.45" ], - "RSK-10": [ - "55", - "55(1)", - "55(2)", - "55(3)", - "55(4)", - "55(5)", - "56", - "56(1)", - "56(2)", - "56(3)" + "BCD-11.7": [ + "10.25", + "10.26" ], - "OPS-01": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "BCD-12": [ + "10.45" ], - "OPS-01.1": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "BCD-14": [ + "10.45" ], - "OPS-03": [ - "51" + "CAP-01": [ + "10.29" ], - "TPM-01": [ - "20", - "21", - "38(3)", - "42", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "CAP-02": [ + "10.29" ], - "TPM-03.2": [ - "20" + "CAP-03": [ + "10.29" ], - "TPM-04": [ - "20", - "21", - "38(3)" + "CAP-04": [ + "10.30", + "10.39" ], - "TPM-04.4": [ - "21", - "38", - "38(3)", - "40" + "CAP-05": [ + "10.29" ], - "TPM-05": [ - "20", - "21", - "38(3)", - "42" + "CHG-01": [ + "10.11" ], - "TPM-06": [ - "52" - ] - }, - "apac-hkg-pdo-2022": { - "GOV-01": [ - "Principle 4" + "CHG-02": [ + "10.11", + "10.18", + "10.27" ], - "CPL-01": [ - "Principle 4" + "CHG-02.2": [ + "10.18" ], - "CPL-02": [ - "Principle 4" + "CHG-02.3": [ + "10.11" ], - "DCH-01": [ - "Principle 4", - "Sec 33" + "CHG-03": [ + "10.11" ], - "DCH-22.1": [ - "Sec 22" + "CHG-04.5": [ + "10.12" ], - "PRI-01": [ - "Inferred", - "Expectation" + "CHG-05": [ + "10.18" ], - "PRI-02.1": [ - "Principle 1" + "CLD-01": [ + "10.26", + "10.50" ], - "PRI-05": [ - "Principle 2", - "Sec 26", - "Principle 3", - "Sec 4" + "CLD-02": [ + "10.50" ], - "PRI-06": [ - "Principle 6", - "Sec 17A", - "Sec 18" + "CLD-06": [ + "10.50" ], - "PRI-06.1": [ - "Sec 22" + "CLD-06.1": [ + "10.50" ], - "PRI-15": [ - "Sec 15" + "CLD-09": [ + "10.50" ], - "SEA-01": [ - "Principle 4", - "Sec 33" + "CLD-10": [ + "10.50" ], - "SEA-02": [ - "Principle 4", - "Sec 33" + "CPL-01.3": [ + "16.6" ], - "SEA-03": [ - "Principle 4", - "Sec 33" - ] - }, - "apac-ind-dpdpa-2023": { - "GOV-01.1": [ - "8(6)", - "18(2)", - "23(1)", - "26(a)", - "26(b)", - "26(c)", - "27(1)(a)", - "27(1)(b)", - "27(1)(c)", - "27(1)(d)", - "27(1)(e)", - "27(2)", - "27(3)", - "28(1)", - "28(2)", - "28(3)", - "28(4)", - "28(5)", - "28(6)" + "CPL-01.4": [ + "8.1", + "8.2", + "18.1" ], - "GOV-01.2": [ - "10(2)(c)(ii)" + "CPL-01.5": [ + "8.2", + "18.2" ], - "GOV-04": [ - "19(3)" + "CPL-01.6": [ + "16.5" ], - "CPL-01": [ - "7(c)", - "7(d)", - "7(e)", - "8(1)", - "8(4)" + "CPL-02": [ + "13.2" ], "CPL-02.1": [ - "10(2)(b)" + "13.3" ], - "CPL-02.2": [ - "10(2)(c)(ii)" + "CPL-03": [ + "11.9", + "13.1" ], "CPL-03.1": [ - "10(2)(b)" + "13.4", + "14.1", + "14.2" ], "CPL-07": [ - "13(1)" - ], - "CPL-07.1": [ - "13(2)" + "10.35", + "12.8" ], - "DCH-09.3": [ - "8(7)(a)" + "CPL-13.1": [ + "10.2", + "10.21" ], - "DCH-18": [ - "8(7)(a)", - "8(8)" + "CFG-03": [ + "10.54" ], - "HRS-01": [ - "21(1)(a)", - "21(1)(b)", - "21(1)(c)", - "21(1)(d)", - "21(1)(e)", - "21(2)", - "22(1)", - "22(2)", - "22(3)" + "CFG-04.1": [ + "10.15" ], - "HRS-03": [ - "6(9)", - "10(2)(a)(iv)" + "MON-01": [ + "10.57", + "11.9", + "12.3" ], - "IRO-04.1": [ - "8(6)" + "MON-10": [ + "10.42" ], - "IRO-09": [ - "8(6)" + "MON-16": [ + "10.31", + "10.57", + "11.9" ], - "IRO-10": [ - "8(6)" + "CRY-01": [ + "10.20", + "10.22" ], - "PRI-01.4": [ - "10(2)(a)", - "10(2)(a)(iv)" + "CRY-01.5": [ + "10.20", + "10.22" ], - "PRI-01.6": [ - "8(4)", - "8(5)" + "CRY-09": [ + "10.20", + "10.21", + "10.23" ], - "PRI-01.8": [ - "5(3)", - "8(9)", - "8(10)", - "8(11)", - "10(2)", - "10(2)(a)(i)", - "10(2)(a)(ii)", - "10(2)(a)(iii)" + "DCH-01.2": [ + "10.44" ], - "PRI-01.9": [ - "6(8)" + "DCH-06": [ + "10.44" ], - "PRI-02": [ - "5(1)(i)", - "5(1)(ii)", - "5(1)(iii)", - "5(2)(a)(i)", - "5(2)(a)(ii)", - "5(2)(a)(iii)", - "6(3)", - "6(10)" + "DCH-06.1": [ + "10.44" ], - "PRI-02.1": [ - "4(2)", - "5(1)(i)", - "5(2)(a)(i)", - "7(a)", - "8(8)(a)" + "HRS-03.2": [ + "9.4" ], - "PRI-03": [ - "4(1)(a)", - "6(1)", - "6(3)", - "6(7)", - "6(10)", - "7(a)", - "7(b)(i)", - "8(8)(b)" + "IAC-01": [ + "10.53", + "10.54", + "10.56", + "10.57" ], - "PRI-03.4": [ - "5(2)(b)", - "6(4)", - "6(7)", - "8(7)(a)", - "8(8)(b)" + "IAC-01.2": [ + "10.54" ], - "PRI-03.6": [ - "6(7)", - "9(1)", - "14(1)" + "IAC-06": [ + "10.55" ], - "PRI-03.9": [ - "5(2)(b)", - "9(2)", - "9(3)" + "IAC-08": [ + "10.56" ], - "PRI-03.10": [ - "6(6)" + "IAC-15": [ + "10.56" ], - "PRI-04.1": [ - "4(1)(b)" + "IAC-21": [ + "10.54" ], - "PRI-05.2": [ - "8(3)", - "8(3)(a)", - "8(3)(b)" + "IAC-29": [ + "10.54" ], - "PRI-05.4": [ - "7(f)", - "7(g)", - "7(h)", - "7(i)", - "8(1)" + "IRO-01": [ + "9.2", + "11.2", + "11.12" ], - "PRI-06": [ - "11(1)(c)", - "11(2)" + "IRO-02": [ + "10.31", + "10.35", + "11.3", + "11.11" ], - "PRI-06.1": [ - "12(1)", - "12(2)(a)", - "12(2)(b)" + "IRO-04": [ + "10.20", + "11.3", + "11.13" ], - "PRI-06.5": [ - "8(7)(a)", - "12(1)", - "12(3)" + "IRO-06": [ + "11.16" ], - "PRI-06.7": [ - "11(1)(a)" + "IRO-06.1": [ + "11.3" ], - "PRI-07": [ - "8(2)" + "IRO-07": [ + "11.13", + "11.14" ], - "PRI-07.1": [ - "8(2)", - "8(7)(b)" + "IRO-10": [ + "10.35", + "11.19" ], - "PRI-12.1": [ - "12(2)(c)" + "IRO-10.2": [ + "11.18" ], - "PRI-14.1": [ - "11(1)(b)" + "IAO-01": [ + "10.2", + "10.6", + "10.8", + "10.15", + "16.2" ], - "RSK-10": [ - "10(2)(c)(i)" + "IAO-01.1": [ + "10.8", + "10.9" ], - "TPM-05": [ - "8(7)(b)" + "IAO-02": [ + "10.2", + "10.6", + "10.8", + "10.9", + "16.4" ], - "TPM-05.2": [ - "8(7)(b)" - ] - }, - "apac-ind-privacy-rules-2011": { - "GOV-01": [ - "8" + "IAO-02.1": [ + "10.8" ], - "CPL-01": [ - "8" + "IAO-02.2": [ + "10.6", + "10.8", + "10.9", + "10.15" ], - "CPL-02": [ - "8" + "IAO-02.4": [ + "10.8" ], - "DCH-01": [ - "7", - "8" + "IAO-04": [ + "10.6", + "10.8", + "10.10" ], - "PRI-01": [ - "Inferred", - "Expectation" + "IAO-05": [ + "10.8" ], - "PRI-03": [ - "5" + "IAO-06": [ + "10.6", + "10.8" ], - "PRI-04": [ - "5" + "IAO-07": [ + "10.6", + "10.8", + "10.15" ], - "PRI-04.1": [ - "5" + "MNT-01": [ + "10.26" ], - "PRI-05": [ - "5" + "MNT-02": [ + "10.26" ], - "SEA-01": [ - "7", - "8" + "MDM-01": [ + "12.3" ], - "SEA-02": [ - "7", - "8" + "NET-01": [ + "10.37", + "12.3", + "12.5" ], - "SEA-03": [ - "7", - "8" - ] - }, - "apac-ind-sebi-2024": { - "GOV-01": [ - "GV.OC.S1", - "GV.OC.S2", - "PR.IP.S17" + "NET-02": [ + "12.3" ], - "GOV-01.1": [ - "GV.OV.S2", - "GV.RR.S1", - "GV.RR.S3", - "GV.RR.S4" + "NET-06": [ + "10.28" ], - "GOV-01.2": [ - "GV.OV.S1" + "PRI-02": [ + "16.2" ], - "GOV-02": [ - "GV.PO.S1" + "PRM-01": [ + "8.1", + "8.2", + "8.4" ], - "GOV-02.1": [ - "GV.PO.S3" + "PRM-01.1": [ + "8.1", + "8.2", + "8.4" ], - "GOV-03": [ - "GV.PO.S2", - "GV.PO.S3", - "GV.PO.S4" + "PRM-01.2": [ + "8.1" ], - "GOV-04": [ - "GV.RR.S1", - "GV.RR.S2", - "GV.RR.S3" + "PRM-02.1": [ + "8.1", + "8.2", + "8.4" ], - "GOV-04.1": [ - "GV.RR.S1", - "GV.RR.S2" + "PRM-04": [ + "9.3", + "10.2", + "10.3", + "10.5" ], - "GOV-04.2": [ - "GV.OC.S1", - "GV.PO.S5" + "PRM-05": [ + "9.3", + "10.2" ], - "GOV-05": [ - "GV.OV.S3", - "GV.OV.S4", - "PR.IP.S10" + "PRM-06": [ + "10.2" ], - "GOV-09": [ - "GV.OC.S1", - "GV.RM.S1" + "PRM-07": [ + "10.5" ], - "GOV-14": [ - "GV.RR.S1" + "RSK-01": [ + "8.2", + "9.1", + "9.2", + "9.3", + "11.3" ], - "GOV-15": [ - "GV.RM.S2" + "RSK-01.3": [ + "8.1", + "11.2" ], - "AST-01": [ - "GV.PO.S5" + "RSK-01.5": [ + "8.1" ], - "AST-01.2": [ - "GV.PO.S5" + "RSK-02": [ + "9.2" ], - "AST-02": [ - "ID.AM.S1", - "ID.AM.S5", - "ID.AM.S6" + "RSK-02.1": [ + "9.2" ], - "AST-02.8": [ - "ID.AM.S2" + "RSK-03": [ + "9.2" ], - "AST-03": [ - "GV.PO.S5" + "RSK-03.1": [ + "9.2" ], - "AST-04": [ - "ID.AM.S2" + "RSK-03.2": [ + "8.1" ], - "AST-09": [ - "PR.AA.S14" + "RSK-04": [ + "8.1", + "9.2" ], - "BCD-01": [ - "PR.IP.S11", - "RC.RP.S1", - "RC.RP.S4", - "RS.MA.S3" + "RSK-04.1": [ + "9.2" ], - "BCD-01.2": [ - "GV.SC.S6" + "RSK-04.2": [ + "9.2" ], - "BCD-01.4": [ - "RC.RP.S2" + "RSK-06": [ + "9.2" ], - "BCD-01.5": [ - "RC.RP.S1" + "RSK-06.1": [ + "9.2" ], - "BCD-02": [ - "ID.AM.S4" + "RSK-06.2": [ + "9.2" ], - "BCD-04": [ - "GV.RM.S3", - "PR.IP.S11", - "RC.IM.S2", - "RC.RP.S3" + "RSK-06.3": [ + "11.17" ], - "BCD-05": [ - "RC.IM.S1", - "RC.IM.S2", - "RS.AN.S4", - "RS.AN.S4a", - "RS.AN.S4b", - "RS.IM.S1" + "RSK-06.4": [ + "9.2" ], - "BCD-11": [ - "PR.IP.S7", - "PR.IP.S8", - "RC.RP.S4" + "RSK-08": [ + "10.44" ], - "BCD-11.1": [ - "PR.IP.S8" + "RSK-09": [ + "10.15" ], - "BCD-12": [ - "PR.IP.S7" + "RSK-09.1": [ + "10.15" ], - "CAP-01": [ - "PR.DS.S3" + "SEA-01": [ + "10.4", + "10.5", + "10.22", + "10.26", + "10.36", + "10.37", + "10.38", + "10.40", + "10.43", + "10.52" ], - "CAP-04": [ - "DE.CM.S4" + "SEA-01.2": [ + "10.24", + "10.31", + "10.32", + "10.40", + "11.2" ], - "CHG-01": [ - "PR.IP.S3" + "SEA-01.3": [ + "10.31", + "10.32", + "10.40", + "11.2" ], - "CHG-02": [ - "PR.IP.S3" + "SEA-01.4": [ + "10.4", + "10.5", + "10.36", + "10.37", + "10.38", + "10.40" ], - "CHG-02.2": [ - "PR.MA.S1" + "SEA-02": [ + "10.4", + "10.36", + "10.40" ], - "CLD-01": [ - "PR.IP.S13" + "OPS-01.1": [ + "10.27" ], - "CLD-02": [ - "PR.IP.S13" + "OPS-03": [ + "10.31" ], - "CLD-04": [ - "PR.AA.S17" + "OPS-04": [ + "11.9" ], - "CLD-09": [ - "PR.DS.S2" + "OPS-07": [ + "10.16" ], - "CPL-01": [ - "GV.OC.S2", - "PR.IP.S13", - "RS.MA.S5" + "SAT-02": [ + "15.1" ], - "CPL-01.3": [ - "PR.IP.S17" + "SAT-03": [ + "15.2", + "15.3" ], - "CPL-02": [ - "EV.ST.S4" + "SAT-03.7": [ + "15.2" ], - "CPL-02.2": [ - "DE.CM.S5" + "TDA-01": [ + "10.2", + "10.12", + "12.1", + "12.5" ], - "CPL-03": [ - "EV.ST.S5" + "TDA-01.1": [ + "10.2", + "10.12", + "12.1", + "12.5" ], - "CPL-03.1": [ - "PR.IP.S14" + "TDA-02": [ + "10.12", + "12.1", + "12.5" ], - "CPL-03.2": [ - "DE.CM.S5" + "TDA-02.3": [ + "10.12", + "10.14" ], - "CFG-01": [ - "PR.IP.S3" + "TDA-02.4": [ + "10.12" ], - "CFG-02": [ - "PR.IP.S1" + "TDA-02.7": [ + "10.12" ], - "CFG-02.1": [ - "PR.IP.S1" + "TDA-02.12": [ + "12.1" ], - "CFG-03": [ - "PR.IP.S1" + "TDA-04.2": [ + "10.15" ], - "CFG-03.1": [ - "DE.CM.S5" + "TDA-06.2": [ + "9.2" ], - "CFG-06": [ - "PR.DS.S6" + "TDA-07": [ + "10.7" ], - "CFG-06.1": [ - "PR.DS.S6" + "TDA-08": [ + "10.7", + "10.26", + "10.28" ], - "MON-01": [ - "DE.CM.S2", - "PR.AA.S8" + "TDA-09": [ + "10.10" ], - "MON-01.8": [ - "DE.CM.S3" + "TDA-09.3": [ + "10.14" ], - "MON-03": [ - "PR.AA.S9" + "TDA-17": [ + "10.17" ], - "MON-08": [ - "PR.AA.S9" + "TDA-20": [ + "10.12" ], - "MON-10": [ - "PR.AA.S9" + "TDA-20.2": [ + "10.12" ], - "MON-17": [ - "DE.CM.S3" + "TDA-20.3": [ + "10.12" ], - "CRY-01": [ - "PR.DS.S1" + "TDA-21": [ + "10.12" ], - "CRY-03": [ - "PR.DS.S1" + "TPM-01": [ + "10.12", + "10.24", + "10.25", + "10.46" ], - "CRY-05": [ - "PR.DS.S1" + "TPM-02": [ + "9.2", + "10.46" ], - "DCH-01": [ - "PR.AA.S14", - "PR.DS.S4" + "TPM-03": [ + "10.15" ], - "DCH-02": [ - "PR.DS.S2" + "TPM-03.1": [ + "10.50" ], - "DCH-06": [ - "PR.AA.S14" + "TPM-04": [ + "10.12", + "10.50" ], - "DCH-06.2": [ - "ID.AM.S5" + "TPM-04.1": [ + "10.46", + "10.47", + "10.50" ], - "DCH-18": [ - "PR.AA.S13" + "TPM-04.4": [ + "10.50" ], - "DCH-21": [ - "PR.AA.S13" + "TPM-05": [ + "10.12", + "10.24", + "10.25", + "10.46", + "10.48", + "10.50" ], - "DCH-26": [ - "PR.DS.S2" + "TPM-05.1": [ + "10.49" ], - "END-04": [ - "PR.IP.S4" + "TPM-05.2": [ + "10.48" ], - "END-04.7": [ - "PR.IP.S4" + "TPM-05.4": [ + "10.46", + "10.48" ], - "END-06": [ - "PR.DS.S6" + "TPM-05.5": [ + "10.46" ], - "END-06.1": [ - "PR.DS.S6" + "TPM-05.7": [ + "10.50" ], - "HRS-01": [ - "GV.RR.S6", - "RS.CO.S1" + "TPM-07": [ + "10.49" ], - "HRS-02": [ - "DE.DP.S1", - "GV.RR.S2", - "PR.AT.S4", - "RS.CO.S1" + "TPM-08": [ + "10.49" ], - "HRS-03": [ - "DE.DP.S1", - "GV.RR.S2", - "PR.AT.S4", - "PR.AT.S5", - "RS.CO.S1" + "THR-01": [ + "11.10" ], - "HRS-03.1": [ - "GV.RR.S6", - "PR.AT.S4", - "PR.AT.S5" + "THR-03": [ + "11.3", + "11.10", + "12.3", + "12.4" ], - "HRS-06": [ - "GV.RR.S5" + "THR-03.1": [ + "11.10" ], - "HRS-06.1": [ - "GV.RR.S5" + "THR-06": [ + "11.7" ], - "HRS-11": [ - "PR.AA.S3" + "THR-09": [ + "9.2", + "11.3" ], - "IAC-01": [ - "PR.AA.S1", - "PR.AA.S6", - "PR.AA.S15" + "THR-10": [ + "11.3", + "12.4" ], - "IAC-06": [ - "PR.AA.S7" + "VPM-01": [ + "10.17", + "10.18", + "10.19", + "10.31" ], - "IAC-08": [ - "PR.AA.S3" + "VPM-01.1": [ + "10.18" ], - "IAC-10": [ - "PR.AA.S6" + "VPM-02": [ + "10.18" ], - "IAC-15": [ - "PR.AA.S1" + "VPM-03": [ + "10.18" ], - "IAC-16": [ - "PR.AA.S11" + "VPM-04": [ + "10.18" ], - "IAC-17": [ - "PR.AA.S5" + "VPM-05": [ + "10.17", + "10.18" ], - "IAC-20": [ - "PR.AA.S15" + "VPM-05.1": [ + "10.19" ], - "IAC-21": [ - "PR.AA.S3" + "VPM-05.6": [ + "10.18" ], - "IAC-21.4": [ - "PR.AA.S11" + "VPM-06": [ + "11.9" ], - "IRO-01": [ - "RS.MA.S1" + "VPM-07": [ + "11.9" ], - "IRO-02": [ - "RS.MA.S2" + "VPM-10": [ + "11.6" + ] + }, + "apac-nzl-hisf-mlhsp-2023": {}, + "apac-nzl-hisf-microsmall-2023": { + "GOV-01.1": [ + "HHSP12", + "HML12", + "HML21" ], - "IRO-02.4": [ - "RS.AN.S2" + "GOV-01.2": [ + "HHSP46", + "HHSP75", + "HML12", + "HML46", + "HML75" ], - "IRO-02.5": [ - "GV.SC.S6", - "RS.CO.S3", - "RS.MA.S5" + "GOV-02": [ + "HML01", + "HHSP01" ], - "IRO-04": [ - "DE.DP.S2", - "GV.RM.S3", - "RS.MA.S1", - "RS.MA.S3" + "GOV-03": [ + "HHSP67", + "HML66" ], - "IRO-04.2": [ - "EV.ST.S3", - "RS.IM.S2" + "GOV-04": [ + "HHSP21", + "HHSP27", + "HML21", + "HML27" ], - "IRO-05": [ - "RS.IM.S2" + "GOV-04.1": [ + "HHSP21", + "HHSP27", + "HML21", + "HML27" ], - "IRO-06": [ - "DE.DP.S2", - "GV.RM.S3" + "GOV-04.2": [ + "HHSP21" ], - "IRO-08": [ - "RS.AN.S3" + "GOV-05": [ + "HHSP46", + "HML46" ], - "IRO-09": [ - "RS.CO.S3" + "GOV-15": [ + "HHSP11", + "HHSP16", + "HHSP28", + "HML11", + "HML16", + "HML28" ], - "IRO-10": [ - "DE.DP.S3", - "RC.CO.S2", - "RC.CO.S3", - "RS.CO.S2", - "RS.CO.S3" + "AST-01": [ + "HHSP05", + "HHSP54", + "HML05", + "HML54" ], - "IRO-10.2": [ - "DE.DP.S3", - "RS.CO.S2" + "AST-09": [ + "HHSP06", + "HHSP45", + "HML06", + "HML45" ], - "IRO-10.4": [ - "RS.CO.S3" + "BCD-01": [ + "HHSP08", + "HHSP24", + "HHSP56", + "HHSP61", + "HML08", + "HML24", + "HML61" ], - "IRO-13": [ - "EV.ST.S3", - "RC.IM.S1", - "RS.AN.S3", - "RS.AN.S4", - "RS.AN.S4a", - "RS.AN.S4b", - "RS.AN.S5", - "RS.IM.S1" + "BCD-01.4": [ + "HHSP24", + "HML24" ], - "IRO-16": [ - "RC.CO.S1" + "BCD-02.1": [ + "HHSP35", + "HML35" ], - "IAO-01": [ - "ID.AM.S4", - "PR.AA.S16" + "BCD-02.2": [ + "HHSP35", + "HML35" ], - "IAO-02": [ - "PR.AA.S16" + "BCD-05": [ + "HHSP64", + "HML63" ], - "MNT-02": [ - "PR.MA.S1" + "BCD-11": [ + "HHSP17", + "HHSP56", + "HHSP69", + "HML17", + "HML56", + "HML68" ], - "MNT-05": [ - "PR.MA.S2" + "BCD-11.1": [ + "HHSP57", + "HHSP69", + "HML57", + "HML68" ], - "MNT-05.5": [ - "PR.MA.S2" + "BCD-11.10": [ + "HHSP56", + "HML56" ], - "NET-01": [ - "PR.AA.S2" + "BCD-12": [ + "HHSP17", + "HML17" ], - "NET-01.1": [ - "PR.AA.S4" + "CAP-01": [ + "HHSP61", + "HML61" ], - "NET-03.5": [ - "PR.DS.S4" + "CHG-01": [ + "HHSP18", + "HML18" ], - "NET-04.11": [ - "ID.AM.S3" + "CHG-02": [ + "HHSP18", + "HML18" ], - "NET-06": [ - "PR.AA.S2" + "CHG-03": [ + "HHSP33", + "HML33" ], - "NET-14": [ - "PR.AA.S12" + "CLD-02": [ + "HHSP51", + "HML51" ], - "NET-17": [ - "PR.DS.S4" + "CLD-04": [ + "HHSP52", + "HML52" ], - "PES-01": [ - "PR.AA.S10", - "PR.IP.S9" + "CLD-06": [ + "HHSP53", + "HML53" ], - "PES-01.1": [ - "PR.IP.S9" + "CPL-01": [ + "HHSP29", + "HML29" ], - "PES-03": [ - "PR.AA.S10" + "CPL-02": [ + "HHSP67", + "HML66" ], - "PES-03.4": [ - "PR.AA.S10" + "CPL-02.1": [ + "HHSP67", + "HML66" ], - "PES-05": [ - "PR.AA.S10" + "CFG-02": [ + "HHSP54", + "HHSP60", + "HHSP65", + "HML16", + "HML54", + "HML60", + "HML64" ], - "PRM-01": [ - "GV.RR.S4" + "MON-01": [ + "HHSP70", + "HML70" ], - "PRM-01.1": [ - "GV.RR.S4" + "MON-01.4": [ + "HHSP69", + "HML68" ], - "PRM-03": [ - "GV.RR.S4" + "MON-01.12": [ + "HHSP69", + "HML68" ], - "PRM-07": [ - "PR.IP.S2" + "MON-03": [ + "HHSP70", + "HML70" ], - "RSK-01": [ - "GV.RM.S1" + "MON-03.2": [ + "HHSP70", + "HML70" ], - "RSK-01.3": [ - "GV.RM.S4" + "MON-07.1": [ + "HHSP71", + "HML71" ], - "RSK-01.5": [ - "GV.RM.S4" + "MON-11": [ + "HHSP63", + "HML69" ], - "RSK-04": [ - "ID.RA.S1", - "ID.RA.S2" + "CRY-01": [ + "HHSP37", + "HML37" ], - "RSK-04.1": [ - "GV.RM.S4" + "DCH-01": [ + "HHSP14", + "HHSP34", + "HHSP74", + "HML14", + "HML74" ], - "RSK-06": [ - "ID.RA.S5" + "DCH-01.2": [ + "HHSP14", + "HHSP74", + "HML14", + "HML74" ], - "RSK-06.2": [ - "EV.ST.S1", - "EV.ST.S4" + "DCH-02": [ + "HML34" ], - "RSK-09.1": [ - "GV.SC.S7" + "DCH-12": [ + "HHSP14", + "HML14" ], - "SEA-01": [ - "PR.IP.S17" + "END-01": [ + "HHSP34" ], - "SEA-13": [ - "EV.ST.S2" + "END-04": [ + "HHSP62", + "HML62" ], - "OPS-01.1": [ - "PR.AA.S14", - "PR.IP.S7", - "RC.RP.S4" + "HRS-01": [ + "HML02" ], - "OPS-04": [ - "DE.CM.S1" + "HRS-03": [ + "HHSP02", + "HHSP23", + "HML02", + "HML23" ], - "OPS-07": [ - "ID.AM.S3" + "HRS-04": [ + "HHSP20", + "HML20" ], - "SAT-01": [ - "GV.RR.S6", - "PR.AT.S1" + "HRS-07": [ + "HHSP03", + "HHSP72", + "HHSP73", + "HML03", + "HML72", + "HML73" ], - "SAT-03": [ - "PR.AT.S2" + "HRS-07.1": [ + "HHSP03", + "HHSP73", + "HML03", + "HML73" ], - "SAT-03.5": [ - "PR.AT.S2" + "IAC-01.2": [ + "HHSP39", + "HML39" ], - "TDA-04.2": [ - "GV.SC.S5", - "PR.IP.S5" + "IAC-05": [ + "HHSP49", + "HML49" ], - "TDA-08": [ - "PR.DS.S5" + "IAC-07": [ + "HHSP04", + "HML04" ], - "TDA-09": [ - "PR.IP.S6" + "IAC-07.1": [ + "HHSP04", + "HML04" ], - "TPM-01": [ - "GV.OC.S3", - "GV.SC.S1", - "PR.IP.S15" + "IAC-07.2": [ + "HHSP04", + "HML04" ], - "TPM-01.1": [ - "GV.OC.S3", - "GV.SC.S1", - "GV.SC.S2" + "IAC-08": [ + "HHSP40", + "HHSP42", + "HML40", + "HML42" ], - "TPM-02": [ - "GV.OC.S3", - "GV.SC.S1", - "GV.SC.S2" + "IAC-15": [ + "HHSP38", + "HML38" ], - "TPM-03": [ - "GV.OC.S3", - "GV.SC.S1" + "IAC-16": [ + "HHSP41", + "HML41" ], - "TPM-05": [ - "GV.OC.S3", - "GV.SC.S3", - "GV.SC.S8", - "PR.AT.S3" + "IAC-20": [ + "HHSP10", + "HHSP40", + "HML10", + "HML40" ], - "TPM-05.2": [ - "GV.SC.S3", - "GV.SC.S8" + "IRO-02": [ + "HHSP07", + "HML07" ], - "TPM-05.4": [ - "GV.OC.S3", - "GV.SC.S3", - "PR.AT.S3" + "IRO-04": [ + "HHSP07", + "HML07" ], - "TPM-05.6": [ - "PR.IP.S5" + "IRO-08": [ + "HHSP74", + "HML74" ], - "TPM-05.7": [ - "GV.SC.S3" + "IRO-10": [ + "HHSP75", + "HML75" ], - "TPM-05.8": [ - "PR.IP.S15", - "PR.IP.S16" + "IAO-01": [ + "HHSP68", + "HML67" ], - "TPM-06": [ - "PR.AT.S3" + "IAO-02": [ + "HHSP68", + "HML67" ], - "TPM-08": [ - "GV.SC.S4" + "MNT-01": [ + "HHSP15", + "HML15" ], - "TPM-09": [ - "GV.SC.S4" + "NET-01": [ + "HHSP49", + "HHSP54", + "HML49", + "HML54" ], - "TPM-10": [ - "GV.SC.S4" + "NET-03.7": [ + "HHSP43", + "HHSP55", + "HML43", + "HML55" ], - "THR-01": [ - "EV.ST.S1" + "NET-06": [ + "HHSP55", + "HML55" ], - "THR-03": [ - "EV.ST.S1", - "EV.ST.S4", - "ID.RA.S3", - "RS.AN.S1" + "NET-17": [ + "HHSP63", + "HML69" ], - "THR-03.1": [ - "RS.AN.S1" + "PES-01": [ + "HHSP47", + "HML47" ], - "THR-07": [ - "DE.DP.S5" + "PES-01.1": [ + "HHSP13", + "HML13" ], - "THR-10": [ - "ID.RA.S4" + "PES-02": [ + "HHSP04", + "HML04" + ], + "PES-03": [ + "HHSP48", + "HML48" + ], + "PES-03.4": [ + "HHSP10", + "HML10" + ], + "PES-04": [ + "HHSP48", + "HML48" + ], + "PES-05": [ + "HHSP66", + "HML65" + ], + "PRM-04": [ + "HHSP11", + "HHSP28", + "HHSP31", + "HML11", + "HML28", + "HML31" + ], + "PRM-05": [ + "HHSP11", + "HHSP28", + "HHSP31", + "HML31" + ], + "RSK-01": [ + "HHSP30", + "HML30" + ], + "RSK-04": [ + "HHSP32", + "HML32" + ], + "RSK-04.1": [ + "HHSP65", + "HML64" + ], + "RSK-06.2": [ + "HHSP26", + "HHSP43", + "HHSP65", + "HML26", + "HML43", + "HML64" + ], + "SEA-01": [ + "HHSP16", + "HML16" + ], + "SAT-01": [ + "HHSP22", + "HML22" + ], + "TDA-01": [ + "HHSP50", + "HML50" + ], + "TDA-01.1": [ + "HHSP50", + "HML50" + ], + "TDA-02": [ + "HHSP31", + "HML31" + ], + "TDA-06": [ + "HHSP50", + "HML50" + ], + "TDA-08": [ + "HHSP58", + "HML58" + ], + "TDA-17": [ + "HHSP43", + "HML43" + ], + "TDA-20": [ + "HHSP42", + "HML42" + ], + "TPM-01": [ + "HHSP25", + "HML25" + ], + "TPM-04.1": [ + "HHSP25", + "HML25" + ], + "TPM-05": [ + "HHSP09", + "HHSP36", + "HHSP72", + "HML09", + "HML36", + "HML72" + ], + "TPM-07": [ + "HHSP73", + "HML73" + ], + "TPM-08": [ + "HHSP25", + "HHSP73", + "HML25", + "HML73" ], "VPM-01": [ - "PR.IP.S12" + "HHSP19", + "HHSP26", + "HML19", + "HML26" ], "VPM-02": [ - "PR.MA.S3" + "HHSP19", + "HHSP59", + "HML19", + "HML59" ], - "VPM-03": [ - "PR.MA.S3" + "VPM-04.1": [ + "HHSP44", + "HML44" ], "VPM-05": [ - "PR.MA.S3" + "HHSP19", + "HML19" ], "VPM-06": [ - "ID.RA.S1" - ], - "VPM-10": [ - "DE.DP.S4" + "HHSP26", + "HHSP59", + "HML26", + "HML59" ] }, - "apac-jpn-ppi-2020": { - "GOV-01": [ - "20" + "apac-nzl-hisf-suppliers-2023": { + "GOV-01.1": [ + "HSUP10", + "HSUP19" ], - "CLD-09": [ - "24(1)" + "GOV-01.2": [ + "HSUP10", + "HSUP38", + "HSUP65" ], - "CPL-01": [ - "20", - "21", - "22", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" + "GOV-02": [ + "HSUP01" ], - "CPL-01.1": [ - "40(1)", - "40(2)", - "40(3)" + "GOV-03": [ + "HSUP58" ], - "CPL-02": [ - "21" + "GOV-04": [ + "HSUP19", + "HSUP23" ], - "CPL-03": [ - "40(1)", - "40(2)", - "40(3)" + "GOV-04.1": [ + "HSUP19", + "HSUP23" ], - "DCH-01": [ - "20" + "GOV-05": [ + "HSUP38" ], - "DCH-01.1": [ - "21" + "GOV-15": [ + "HSUP14", + "HSUP24" ], - "DCH-19": [ - "24(1)" + "AST-01": [ + "HSUP05", + "HSUP46" ], - "DCH-22.1": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" + "AST-01.2": [ + "HSUP27" ], - "DCH-22.3": [ - "17(1)" + "AST-09": [ + "HSUP06" ], - "DCH-23": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" + "BCD-01": [ + "HSUP08", + "HSUP22", + "HSUP53" ], - "DCH-24": [ - "20" + "BCD-01.4": [ + "HSUP22" ], - "DCH-25": [ - "24(1)" + "BCD-02.1": [ + "HSUP31" ], - "HRS-01": [ - "21" + "BCD-02.2": [ + "HSUP31" ], - "HRS-03": [ - "21" + "BCD-05": [ + "HSUP56" ], - "HRS-05.1": [ - "21" + "BCD-11": [ + "HSUP15", + "HSUP48", + "HSUP60" ], - "HRS-06": [ - "21" + "BCD-11.1": [ + "HSUP49", + "HSUP60" ], - "HRS-06.1": [ - "21" + "BCD-11.10": [ + "HSUP48" ], - "IAC-09.6": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" + "BCD-12": [ + "HSUP15" ], - "IRO-04.1": [ - "22-2(1)", - "22-2(2)" + "CAP-01": [ + "HSUP53" ], - "IAO-03.2": [ - "22" + "CHG-01": [ + "HSUP16" ], - "PRI-01": [ - "24(3)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" + "CHG-02": [ + "HSUP16" ], - "PRI-01.1": [ - "21" + "CHG-03": [ + "HSUP29" ], - "PRI-01.6": [ - "20", - "21" + "CLD-02": [ + "HSUP43" ], - "PRI-02": [ - "15(1)", - "15(2)" + "CLD-04": [ + "HSUP44" ], - "PRI-02.1": [ - "15(1)", - "15(2)" + "CLD-06": [ + "HSUP45" ], - "PRI-03": [ - "16(1)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)", - "24(1)", - "24(2)" + "CPL-01": [ + "HSUP25" ], - "PRI-03.2": [ - "16(2)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" + "CPL-02": [ + "HSUP58" ], - "PRI-03.6": [ - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" + "CPL-02.1": [ + "HSUP58" ], - "PRI-04": [ - "17(1)" + "CFG-02": [ + "HSUP14", + "HSUP46", + "HSUP52" ], - "PRI-04.1": [ - "17(1)", - "17(2)", - "17(2)(i)", - "17(2)(ii)", - "17(2)(iii)", - "17(2)(iv)", - "17(2)(v)", - "17(2)(vi)" + "MON-01": [ + "HSUP61" ], - "PRI-04.4": [ - "18(1)", - "18(2)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)" + "MON-01.4": [ + "HSUP60" ], - "PRI-05": [ - "19" + "MON-01.12": [ + "HSUP60" ], - "PRI-05.1": [ - "16-2" + "MON-03": [ + "HSUP61" ], - "PRI-05.2": [ - "19" + "MON-03.2": [ + "HSUP61" ], - "PRI-05.4": [ - "16-2" + "MON-07.1": [ + "HSUP62" ], - "PRI-06": [ - "27(1)", - "27(1)(i)", - "27(1)(ii)", - "27(1)(iii)", - "27(1)(iv)", - "27(2)(i)", - "27(2)(ii)", - "27(3)", - "28(1)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)" + "MON-11": [ + "HSUP55" ], - "PRI-06.1": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" + "CRY-01": [ + "HSUP32" ], - "PRI-06.2": [ - "18(3)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)", - "29(1)", - "29(2)", - "29(3)" + "DCH-01": [ + "HSUP12", + "HSUP30", + "HSUP66" ], - "PRI-06.3": [ - "31" + "DCH-01.2": [ + "HSUP12", + "HSUP66" ], - "PRI-06.4": [ - "27(3)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)", - "31", - "32(1)", - "32(2)", - "32(3)", - "32(4)" + "DCH-02": [ + "HSUP30" ], - "PRI-06.5": [ - "30(1)", - "30(2)", - "30(3)", - "30(4)", - "30(5)", - "30(6)", - "30(7)", - "33(1)", - "33(2)", - "34", - "34(1)", - "34(2)", - "34(3)", - "35(1)", - "35(2)" + "DCH-12": [ + "HSUP12" ], - "PRI-07": [ - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" + "END-01": [ + "HSUP30" ], - "PRI-07.1": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" + "END-04": [ + "HSUP54" ], - "PRI-07.2": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" + "HRS-01": [ + "HSUP02" ], - "PRI-07.3": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" + "HRS-03": [ + "HSUP02", + "HSUP21" ], - "PRI-14.1": [ - "25(1)", - "25(2)" + "HRS-04": [ + "HSUP18" ], - "SEA-01": [ - "20" + "HRS-05.1": [ + "HSUP01" ], - "SEA-02": [ - "20" + "HRS-07": [ + "HSUP03", + "HSUP63", + "HSUP64" ], - "SEA-03": [ - "20" + "HRS-07.1": [ + "HSUP03", + "HSUP64" ], - "SEA-15": [ - "20" + "IAC-01.2": [ + "HSUP34" ], - "TPM-01": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "24(3)" + "IAC-05": [ + "HSUP41" ], - "TPM-04": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" + "IAC-07": [ + "HSUP04", + "HSUP35" ], - "TPM-04.4": [ - "20" + "IAC-07.1": [ + "HSUP04" ], - "TPM-05": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" + "IAC-07.2": [ + "HSUP04" ], - "TPM-08": [ - "24(3)" + "IAC-08": [ + "HSUP04", + "HSUP37" ], - "TPM-10": [ - "24(3)" - ] - }, - "apac-jpn-ismap": { - "GOV-01": [ - "4.4.1.1", - "4.4.1.2", - "4.4.2.1", - "4.5.4.1", - "4.5.4.2", - "4.8.1.1", - "4.8.2.2", - "5.1", - "5.1.1", - "6.1" + "IAC-15": [ + "HSUP33", + "HSUP35" ], - "GOV-01.1": [ - "4.4.1.1", - "4.4.1.3", - "4.4.5.3", - "4.5.3.1", - "4.6.3.1", - "4.6.3.2", - "4.6.3.3" + "IAC-16": [ + "HSUP36" ], - "GOV-01.2": [ - "4.6.1.1" + "IAC-20": [ + "HSUP09" ], - "GOV-01.3": [ - "4.6.1.1", - "4.6.1.2", - "4.6.3.3" + "IRO-02": [ + "HSUP07" ], - "GOV-02": [ - "4.4.5.1", - "4.4.5.3", - "4.5.2.1", - "4.8.2.1", - "5", - "5.1.1", - "5.1.1.1", - "5.1.1.8", - "5.1.1.21", - "6", - "6.2.1" + "IRO-04": [ + "HSUP07" ], - "GOV-02.1": [ - "5.1.1.7" + "IRO-08": [ + "HSUP66" ], - "GOV-03": [ - "4.5.3.1", - "4.7.1.5", - "4.8.2.1", - "5.1.1", - "5.1.2", - "5.1.2.2", - "5.1.2.3", - "5.1.2.4" + "IRO-10": [ + "HSUP65" ], - "GOV-04": [ - "4.4.1.2", - "5.1.1.6", - "5.1.2.1" + "IAO-01": [ + "HSUP59" ], - "GOV-05": [ - "4.6.2.1" + "IAO-02": [ + "HSUP59" ], - "GOV-06": [ - "6.1.3", - "6.1.3.1", - "6.1.3.3.PB" + "MNT-01": [ + "HSUP13" ], - "GOV-07": [ - "6.1.4", - "6.1.4.1", - "6.1.4.2", - "6.1.4.3", - "6.1.4.4", - "6.1.4.5", - "6.1.4.6" + "NET-01": [ + "HSUP41", + "HSUP46" ], - "GOV-09": [ - "4.4.4.1", - "5.1.1.5" + "NET-03.7": [ + "HSUP47" ], - "GOV-14": [ - "4.5.2.1", - "7.2.1.8" + "NET-06": [ + "HSUP47" ], - "GOV-15": [ - "4.4.4.1", - "4.5.2.1" + "NET-17": [ + "HSUP55" ], - "GOV-15.1": [ - "4.4.4.1" + "PES-01": [ + "HSUP11", + "HSUP39" ], - "GOV-17": [ - "4.5.3.1" + "PES-01.1": [ + "HSUP11" ], - "AAT-12": [ - "18.1.2", - "18.1.2.13.PB" + "PES-02": [ + "HSUP04" ], - "AST-01": [ - "8", - "8.1", - "8.1.1.1", - "8.1.1.6.PB" + "PES-02.1": [ + "HSUP04" ], - "AST-02": [ - "8.1.1", - "8.1.1.2", - "8.1.1.3", - "8.1.1.4", - "8.1.2.3" + "PES-03": [ + "HSUP40" ], - "AST-02.7": [ - "14.2.7.1", - "18.1.2", - "18.1.2.1", - "18.1.2.2", - "18.1.2.3", - "18.1.2.4", - "18.1.2.5", - "18.1.2.6", - "18.1.2.7", - "18.1.2.8", - "18.1.2.9", - "18.1.2.10", - "18.1.2.11", - "18.1.2.12" + "PES-03.4": [ + "HSUP09" ], - "AST-03": [ - "8.1.1.5", - "8.1.2", - "8.1.2.1", - "8.1.2.2" + "PES-04": [ + "HSUP40" ], - "AST-04": [ - "4.4.4" + "PES-05": [ + "HSUP57" ], - "AST-04.1": [ - "4.4.4", - "4.4.4.1", - "8.1.2.4" + "PRM-04": [ + "HSUP24" ], - "AST-05": [ - "8.3", - "8.3.1" + "PRM-05": [ + "HSUP27" ], - "AST-05.1": [ - "8.3.1.2", - "13.2.2.1" + "PRM-06": [ + "HSUP27" ], - "AST-06": [ - "6.2.1.18", - "6.2.1.19", - "8.2.3.5", - "11.2.8", - "11.2.8.1", - "11.2.8.2", - "11.2.8.3", - "11.2.8.4" + "RSK-01": [ + "HSUP26" ], - "AST-09": [ - "8.1.2.6", - "8.3.1.1", - "8.3.2", - "8.3.2.1", - "8.3.2.2", - "8.3.2.3", - "11.2.7", - "11.2.7.1", - "11.2.7.2" + "RSK-04": [ + "HSUP28" ], - "AST-10": [ - "8.1.4" + "SEA-01": [ + "HSUP14" ], - "BCD-01": [ - "5.1.1.13", - "17", - "17.1", - "17.1.1", - "17.1.1.1", - "17.1.1.2", - "17.1.1.3", - "17.1.1.4", - "17.1.3", - "17.1.3.1", - "17.1.3.4" + "OPS-01.1": [ + "HSUP01" ], - "BCD-01.7": [ - "12.2.1.10", - "12.2.1.11", - "17.1.2", - "17.1.2.1", - "17.1.2.2", - "17.1.2.3", - "17.1.2.4", - "17.1.2.5", - "17.1.2.6" + "SAT-01": [ + "HSUP20" ], - "BCD-04": [ - "17.1.3.2", - "17.1.3.3" + "TDA-01": [ + "HSUP42" ], - "BCD-09": [ - "17.2", - "17.2.1", - "17.2.1.1", - "17.2.1.2", - "17.2.1.3" + "TDA-01.1": [ + "HSUP42" ], - "BCD-11": [ - "12.3", - "12.3.1", - "12.3.1.1", - "12.3.1.2", - "12.3.1.3", - "12.3.1.4", - "12.3.1.5", - "12.3.1.11", - "12.3.1.12", - "12.3.1.13", - "12.3.1.14", - "12.3.1.16.P", - "12.3.1.17.P", - "12.3.1.18.P", - "12.3.1.21.P", - "12.3.1.24.P" + "TDA-06": [ + "HSUP42" ], - "BCD-11.2": [ - "8.3.1.7", - "12.3.1.6", - "12.3.1.7", - "12.3.1.23.P" + "TDA-08": [ + "HSUP50" ], - "BCD-11.5": [ - "12.3.1.8", - "12.3.1.9", - "12.3.1.10", - "12.3.1.20.P", - "12.3.1.22.P" + "TDA-20": [ + "HSUP37" ], - "CAP-01": [ - "12.1.3", - "12.1.3.1", - "12.1.3.2", - "12.1.3.3", - "12.1.3.4", - "12.1.3.5", - "12.1.3.6", - "12.1.3.7", - "12.1.3.8" + "TPM-01": [ + "HSUP67" ], - "CHG-01": [ - "4.5.4.4", - "12.1.2", - "12.1.2.1", - "12.1.2.11.PB" + "TPM-04.1": [ + "HSUP67" ], - "CHG-02": [ - "12.1.2.2", - "12.1.2.3", - "12.1.2.4", - "12.1.2.5", - "12.1.2.6", - "12.1.2.7", - "12.1.2.8", - "12.1.2.9", - "12.1.2.13", - "12.1.2.14", - "12.5.1.4", - "12.5.1.6", - "12.5.1.7", - "12.5.1.8", - "12.5.1.10", - "12.5.1.11", - "12.5.1.12", - "12.5.1.13", - "12.5.1.14", - "12.5.1.15", - "12.5.1.16", - "12.5.1.17", - "12.5.1.18", - "14.2.2", - "14.2.2.1", - "14.2.2.2", - "14.2.2.3", - "14.2.2.4", - "14.2.2.5", - "14.2.2.6", - "14.2.2.7", - "14.2.2.8", - "14.2.2.9", - "14.2.2.10", - "14.2.2.11", - "14.2.2.12", - "14.2.2.13", - "14.2.2.14", - "14.2.2.15", - "14.2.2.16", - "14.2.2.17", - "14.2.4.7", - "14.2.4.8", - "14.2.4.9", - "14.2.4.10" + "TPM-05": [ + "HSUP63", + "HSUP68" ], - "CHG-02.1": [ - "14.2.4", - "14.2.4.1", - "14.2.4.2", - "14.2.4.3", - "14.2.4.4", - "14.2.4.5", - "14.2.4.6" + "TPM-07": [ + "HSUP64" ], - "CHG-02.2": [ - "12.1.2.10", - "12.5.1.5", - "12.5.1.9", - "14.2.3", - "14.2.3.1", - "14.2.3.2", - "14.2.3.3" + "TPM-08": [ + "HSUP64", + "HSUP67" ], - "CLD-01": [ - "5.1.1.22.P", - "5.1.1.23.P", - "5.1.1.24.P", - "5.1.1.25.P", - "5.1.1.26.P", - "5.1.1.27.P", - "5.1.1.28.P", - "5.1.1.29.P", - "5.1.1.30.P" + "VPM-01": [ + "HSUP17" ], - "CLD-01.2": [ - "8.1.5.P", - "8.1.5.1.P", - "8.1.5.2.P", - "8.1.5.3.P", - "8.1.5.4.P" + "VPM-02": [ + "HSUP17", + "HSUP51" ], - "CLD-02": [ - "8.1.2.7.PB", - "9.2.3.11.PB" + "VPM-05": [ + "HSUP17" ], - "CLD-06": [ - "9.5.1.P", - "9.5.1.1.P", - "9.5.1.2.P", - "9.5.1.3.P", - "9.5.1.4.P" + "VPM-06": [ + "HSUP51" + ] + }, + "apac-nzl-ism-3-9": { + "GOV-01": [ + "5.1.14.C.01", + "5.1.16.C.01", + "16.1.24.C.01" ], - "CLD-06.1": [ - "6.3.1.1.PB" + "GOV-01.1": [ + "3.2.9.C.01" ], - "CPL-01": [ - "4.4.2.1", - "5.1.1.3", - "18", - "18.1", - "18.1.1", - "18.1.1.1", - "18.1.1.2", - "18.1.1.3", - "18.1.1.4.P", - "18.1.1.5.P", - "18.1.1.6.P", - "18.1.1.7.P", - "18.1.5.7.PB" + "GOV-01.4": [ + "5.1.16.C.02" ], - "CPL-01.1": [ - "4.6.1.1", - "4.7.1.1", - "4.7.1.2" + "GOV-02": [ + "5.1.7.C.01", + "5.1.14.C.01", + "5.1.16.C.01", + "5.1.16.C.02", + "5.1.17.C.01", + "5.1.18.C.01", + "5.1.19.C.01", + "5.1.20.C.01", + "5.1.20.C.02", + "5.2.3.C.01", + "5.2.3.C.02", + "11.1.15.C.01", + "11.1.15.C.02", + "11.3.5.C.01", + "11.4.9.C.01", + "11.5.13.C.01", + "11.8.3.C.01", + "16.1.24.C.01", + "20.2.15.C.04", + "21.1.6.C.01", + "22.1.10.C.01", + "22.1.22.C.01" ], - "CPL-01.2": [ - "4.4.4", - "4.4.4.1" + "GOV-03": [ + "5.1.14.C.01", + "5.1.21.C.01", + "5.1.21.C.02" ], - "CPL-01.3": [ - "4.5.4.3", - "18.2.1.11.P", - "18.2.1.12.P" + "GOV-04": [ + "3.1.8.C.01", + "3.1.8.C.02", + "3.1.8.C.03", + "3.1.9.C.01", + "3.2.8.C.01", + "3.2.8.C.02", + "3.2.8.C.03", + "3.2.8.C.04", + "3.2.8.C.05", + "3.2.9.C.01", + "3.2.10.C.01", + "3.2.10.C.02", + "3.2.10.C.03", + "3.2.10.C.04", + "3.2.11.C.01", + "3.2.11.C.02", + "3.2.11.C.03", + "3.2.12.C.01", + "3.2.12.C.02", + "3.2.12.C.03", + "3.2.13.C.01", + "3.2.13.C.02", + "3.2.14.C.01", + "3.2.15.C.01", + "3.2.16.C.01", + "3.2.17.C.01", + "3.2.18.C.01", + "3.2.19.C.01" ], - "CPL-01.4": [ - "4.5.4.3", - "4.6.2.2" + "GOV-10": [ + "20.2.16.C.03" ], - "CPL-02": [ - "4.6.1.1", - "4.6.2.2", - "4.6.2.6", - "12.7", - "12.7.1.8", - "12.7.1.9" + "GOV-15": [ + "3.2.10.C.04", + "3.4.11.C.01" ], - "CPL-02.1": [ - "4.6.2.2", - "4.6.2.4" + "GOV-15.1": [ + "3.2.10.C.04" ], - "CPL-03": [ - "4.6.2.3", - "4.6.2.5", - "12.7.1", - "12.7.1.1", - "12.7.1.2", - "12.7.1.3", - "12.7.1.4", - "12.7.1.5", - "12.7.1.6", - "12.7.1.7", - "18.2", - "18.2.2", - "18.2.2.1", - "18.2.2.2", - "18.2.2.3", - "18.2.2.4", - "18.2.2.5", - "18.2.2.6", - "18.2.2.7", - "18.2.2.8" + "GOV-15.2": [ + "3.4.11.C.01" ], - "CPL-03.1": [ - "4.6.2.5", - "18.2.1", - "18.2.1.3", - "18.2.1.4", - "18.2.1.5", - "18.2.1.6", - "18.2.1.7", - "18.2.1.8", - "18.2.1.9.P", - "18.2.1.10.P", - "18.2.1.13.P" + "GOV-15.4": [ + "23.2.16.C.03", + "23.2.16.C.04" ], - "CPL-03.2": [ - "18.2.3", - "18.2.3.1", - "18.2.3.2", - "18.2.3.3", - "18.2.3.4", - "18.2.3.5" + "GOV-15.5": [ + "23.2.18.C.01" ], - "CPL-07": [ - "18.1.2.13.PB" + "AST-01": [ + "8.4.9.C.01", + "20.2.15.C.04", + "20.2.15.C.07" ], - "CPL-13.1": [ - "4.6.2.7" + "AST-02": [ + "8.4.8.C.01", + "8.4.9.C.01" ], - "CPL-13.2": [ - "4.6.2.7" + "AST-02.9": [ + "20.2.15.C.07" ], - "CFG-02": [ - "8.3.1.9" + "AST-04": [ + "18.1.9.C.02", + "18.1.11.C.01", + "18.1.12.C.01", + "18.1.12.C.02" ], - "CFG-02.9": [ - "9.5.2.P", - "9.5.2.1.PB" + "AST-05": [ + "17.9.36.C.01" ], - "CFG-05.2": [ - "12.5", - "12.5.1", - "12.5.1.1", - "12.5.1.2", - "12.5.1.3", - "12.6.2", - "12.6.2.1", - "12.6.2.2", - "12.6.2.3", - "12.6.2.4" + "AST-08": [ + "8.5.3.C.01", + "8.5.3.C.02", + "8.5.3.C.03", + "8.5.3.C.04", + "8.5.4.C.01", + "8.5.4.C.02", + "8.5.4.C.03", + "8.5.5.C.01" ], - "MON-01": [ - "12.4", - "12.4.1", - "12.4.1.15.PB" + "AST-09": [ + "11.2.13.C.01", + "11.7.35.C.01", + "11.8.10.C.03", + "11.8.10.C.05", + "11.8.12.C.01", + "11.8.12.C.02", + "12.6.4.C.01", + "12.6.4.C.02", + "12.6.5.C.01", + "12.6.5.C.02", + "12.6.5.C.03", + "12.6.5.C.04", + "12.6.5.C.05", + "12.6.8.C.01", + "12.6.9.C.01", + "12.6.10.C.01", + "13.4.10.C.01", + "13.4.19.C.02", + "13.5.24.C.01", + "13.5.24.C.02", + "13.5.24.C.03", + "13.5.24.C.04", + "13.5.25.C.01", + "13.5.26.C.01", + "13.5.26.C.02", + "13.5.26.C.03", + "13.5.29.C.01", + "13.5.29.C.02", + "13.5.30.C.01", + "13.6.6.C.01", + "13.6.6.C.02", + "13.6.7.C.01", + "13.6.8.C.01", + "13.6.9.C.01", + "13.6.10.C.01", + "13.6.10.C.02", + "13.6.10.C.03", + "13.6.11.C.01", + "13.6.12.C.01", + "17.6.6.C.01" ], - "MON-01.8": [ - "12.4.3.3", - "12.4.5.P", - "12.4.5.1.P", - "12.4.5.2.P", - "12.4.5.3.P", - "12.4.5.4.P", - "12.4.5.5.P" + "AST-14.1": [ + "11.1.19.C.03" ], - "MON-02.6": [ - "6.1.3.5", - "6.1.4.7" + "AST-14.2": [ + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03" ], - "MON-03": [ - "12.4.1.1", - "12.4.1.2", - "12.4.1.3", - "12.4.1.4", - "12.4.1.5", - "12.4.1.6", - "12.4.1.7", - "12.4.1.8", - "12.4.1.9", - "12.4.1.10", - "12.4.1.11", - "12.4.1.12", - "12.4.1.13", - "12.4.1.14", - "12.4.1.17", - "12.4.1.18" + "AST-16": [ + "8.1.12.C.01", + "21.1.12.C.01", + "22.4.7.C.02", + "22.4.8.C.01", + "22.4.8.C.02", + "22.4.10.C.01", + "22.4.10.C.02", + "22.4.10.C.03", + "22.4.10.C.04", + "22.4.10.C.05", + "22.4.10.C.06", + "22.4.10.C.07", + "22.4.10.C.08", + "22.4.10.C.09", + "22.4.10.C.10", + "22.4.10.C.11", + "22.4.10.C.12", + "22.4.10.C.13", + "22.4.10.C.14", + "22.4.10.C.15", + "22.4.10.C.16", + "22.4.11.C.01", + "22.4.11.C.02", + "22.4.11.C.03", + "22.4.11.C.04", + "22.4.11.C.05", + "22.4.11.C.06", + "22.4.11.C.07", + "22.4.11.C.08", + "22.4.11.C.09", + "22.4.11.C.10", + "22.4.11.C.11", + "22.4.11.C.12", + "22.4.11.C.13", + "22.4.11.C.14", + "22.4.11.C.15", + "22.4.11.C.16", + "22.4.11.C.17", + "22.4.11.C.18", + "22.4.11.C.19", + "22.4.11.C.20", + "22.4.12.C.01", + "22.4.13.C.01", + "22.4.13.C.02", + "22.4.13.C.03", + "22.4.13.C.04", + "22.4.13.C.05", + "22.4.13.C.06", + "22.4.13.C.07", + "22.4.13.C.08", + "22.4.13.C.09", + "22.4.13.C.10", + "22.4.13.C.11", + "22.4.14.C.01", + "22.4.14.C.02", + "22.4.14.C.03", + "22.4.14.C.04" ], - "MON-03.3": [ - "12.4.3", - "12.4.3.1" + "AST-19": [ + "11.3.5.C.01", + "11.3.6.C.01", + "11.3.6.C.02", + "11.3.7.C.01", + "11.3.8.C.01", + "11.3.9.C.01", + "11.3.9.C.02", + "11.3.10.C.01", + "11.3.11.C.01", + "11.3.12.C.01", + "11.3.12.C.02", + "11.3.12.C.03", + "11.3.13.C.01", + "11.3.13.C.02", + "11.3.13.C.03", + "11.8.3.C.01", + "11.8.4.C.01", + "11.8.5.C.01" ], - "MON-08": [ - "12.4.2", - "12.4.2.1", - "12.4.2.2", - "12.4.2.3", - "12.4.3.2" + "AST-20": [ + "18.3.14.C.01", + "18.3.14.C.02" ], - "CRY-01": [ - "5.1.1.17", - "10", - "10.1", - "10.1.1", - "10.1.1.1", - "10.1.1.2", - "10.1.1.3", - "10.1.1.4", - "10.1.1.5", - "10.1.1.6", - "10.1.1.7", - "10.1.1.8", - "10.1.1.9.PB", - "10.1.1.10.P", - "13.2.1.6", - "14.1.3", - "14.1.3.1", - "14.1.3.2", - "14.1.3.3", - "14.1.3.4", - "14.1.3.5", - "14.1.3.6" + "AST-21": [ + "18.3.8.C.01", + "18.3.9.C.01", + "18.3.9.C.02", + "18.3.10.C.01", + "18.3.11.C.01", + "18.3.11.C.02", + "18.3.12.C.01", + "18.3.12.C.02", + "18.3.13.C.01", + "18.3.13.C.02", + "18.3.13.C.03", + "18.3.14.C.01", + "18.3.14.C.02", + "18.3.15.C.01", + "18.3.15.C.02", + "18.3.16.C.01", + "18.3.16.C.02", + "18.3.16.C.03", + "18.3.17.C.01" ], - "CRY-01.2": [ - "18.1.5", - "18.1.5.1", - "18.1.5.2", - "18.1.5.3", - "18.1.5.4", - "18.1.5.5", - "18.1.5.6" + "AST-23": [ + "11.2.11.C.01", + "11.2.11.C.02", + "11.2.12.C.01", + "11.2.13.C.01", + "11.8.3.C.01", + "11.8.7.C.01", + "11.8.8.C.01", + "11.8.13.C.01" ], - "CRY-04": [ - "14.2.5.8" + "AST-26": [ + "3.4.10.C.01", + "3.4.10.C.02", + "5.1.11.C.01", + "5.1.13.C.01", + "5.5.3.C.01", + "5.5.4.C.01", + "5.5.5.C.01", + "5.5.6.C.01", + "18.6.10.C.01" ], - "CRY-05": [ - "8.3.1.5" + "AST-28": [ + "3.4.10.C.01", + "3.4.10.C.02", + "5.1.11.C.01", + "5.1.13.C.01", + "5.5.3.C.01", + "5.5.4.C.01", + "5.5.5.C.01", + "5.5.6.C.01" ], - "CRY-09": [ - "10.1.2", - "10.1.2.1", - "10.1.2.2", - "10.1.2.3", - "10.1.2.4", - "10.1.2.5", - "10.1.2.6", - "10.1.2.7", - "10.1.2.8", - "10.1.2.9", - "10.1.2.10", - "10.1.2.11", - "10.1.2.12", - "10.1.2.13", - "10.1.2.14", - "10.1.2.15", - "10.1.2.16", - "10.1.2.17", - "10.1.2.18", - "10.1.2.19", - "10.1.2.20.PB" + "AST-29": [ + "11.6.59.C.01", + "11.6.59.C.02", + "11.6.60.C.01", + "11.6.60.C.02", + "11.6.60.C.03", + "11.6.60.C.04", + "11.6.61.C.01", + "11.6.61.C.02", + "11.6.62.C.01", + "11.6.62.C.02", + "11.6.62.C.03", + "11.6.63.C.01", + "11.6.63.C.02", + "11.6.64.C.01", + "11.6.65.C.01", + "11.6.65.C.02", + "11.6.65.C.03", + "11.6.66.C.01", + "11.6.67.C.01", + "11.6.67.C.02", + "11.6.68.C.01", + "11.6.69.C.01", + "11.6.70.C.01", + "11.6.71.C.01" ], - "DCH-01": [ - "5.1.1.10", - "5.1.1.14", - "8.2", - "8.2.3", - "8.2.3.1", - "13.2", - "13.2.1", - "13.2.1.10", - "13.2.1.12", - "13.2.1.13", - "13.2.1.14" + "AST-29.1": [ + "11.7.29.C.01", + "11.7.29.C.02", + "11.7.30.C.01", + "11.7.30.C.02", + "11.7.30.C.03", + "11.7.31.C.01", + "11.7.31.C.02", + "11.7.32.C.01", + "11.7.32.C.02", + "11.7.32.C.03", + "11.7.32.C.04", + "11.7.33.C.01", + "11.7.33.C.02", + "11.7.33.C.03", + "11.7.34.C.01" ], - "DCH-01.3": [ - "8.2.3.3", - "8.2.3.4", - "8.3.1.3" + "AST-30": [ + "2.3.30.C.01", + "13.1.9.C.01", + "13.1.10.C.01", + "13.1.10.C.02", + "13.1.10.C.03", + "13.1.10.C.04", + "13.1.11.C.01", + "13.1.12.C.01", + "13.1.12.C.02", + "13.1.12.C.03", + "13.1.13.C.01", + "13.1.13.C.02", + "13.1.13.C.03", + "13.1.13.C.04", + "13.1.14.C.01", + "20.2.15.C.03", + "20.2.15.C.06" ], - "DCH-01.4": [ - "8.2.3.2" + "BCD-01": [ + "6.4.5.C.01", + "6.4.7.C.01", + "6.4.8.C.01", + "20.1.26.C.01", + "23.4.12.C.01", + "23.4.12.C.02" ], - "DCH-02": [ - "8.2.1", - "8.2.1.1", - "8.2.1.2", - "8.2.1.3", - "8.2.1.4", - "8.2.1.5", - "8.2.1.6", - "8.2.1.7", - "8.2.1.8", - "8.2.1.9", - "8.2.1.10" + "BCD-11": [ + "6.4.6.C.01" ], - "DCH-04": [ - "8.2.2", - "8.2.2.1", - "8.2.2.2", - "8.2.2.3", - "8.2.2.4", - "8.2.2.5", - "8.2.2.6", - "8.2.2.7.PB", - "8.2.3.6" + "BCD-12.3": [ + "11.3.13.C.01", + "11.3.13.C.02", + "11.3.13.C.03" ], - "DCH-06": [ - "8.3.1.4" + "CHG-01": [ + "6.3.6.C.01" ], - "DCH-06.1": [ - "8.3.1.4" + "CHG-02": [ + "6.3.6.C.02", + "6.3.7.C.01", + "6.3.7.C.02", + "6.3.7.C.03" ], - "DCH-07": [ - "8.3.3", - "8.3.3.1", - "8.3.3.2", - "8.3.3.3", - "8.3.3.4", - "8.3.3.5", - "13.2.2.5" + "CHG-02.1": [ + "20.2.15.C.02", + "20.2.15.C.05" ], - "DCH-07.1": [ - "8.3.1.10" + "CHG-02.2": [ + "6.3.8.C.01" ], - "DCH-08": [ - "8.3.2.4", - "8.3.2.5", - "8.3.2.6" + "CLD-01": [ + "2.3.28.C.01", + "20.1.20.C.01", + "20.1.20.C.02", + "20.1.20.C.03", + "20.1.20.C.04", + "22.1.20.C.01", + "22.1.20.C.02", + "22.1.20.C.03", + "22.1.21.C.01", + "23.1.54.C.01", + "23.1.54.C.02", + "23.2.19.C.01" ], - "DCH-09": [ - "11.2.7.3" + "CLD-01.1": [ + "23.4.9.C.01", + "23.4.9.C.02", + "23.4.9.C.03", + "23.4.10.C.01", + "23.5.11.C.01", + "23.5.12.C.01", + "23.5.12.C.02" ], - "DCH-09.1": [ - "8.3.2.7" + "CLD-01.2": [ + "20.1.26.C.02", + "20.1.26.C.03", + "23.4.13.C.01", + "23.4.13.C.02", + "23.4.13.C.03" ], - "DCH-14": [ - "13.2.1.5", - "13.2.1.9" + "CLD-02": [ + "2.3.28.C.01", + "20.1.24.C.02", + "20.1.24.C.03", + "20.1.24.C.04", + "20.2.12.C.01", + "20.2.12.C.02", + "23.1.54.C.01", + "23.1.54.C.02", + "23.1.56.C.01", + "23.2.20.C.01" ], - "DCH-18": [ - "4.4.7.4", - "4.6.3.4", - "12.3.1.15", - "12.3.1.19.P", - "13.2.1.7", - "18.1.3", - "18.1.3.1", - "18.1.3.2", - "18.1.3.3", - "18.1.3.4", - "18.1.3.5", - "18.1.3.6", - "18.1.3.7", - "18.1.3.8", - "18.1.3.9", - "18.1.3.10", - "18.1.3.11", - "18.1.3.12", - "18.1.3.13.PB" + "CLD-06": [ + "23.1.55.C.01", + "23.1.55.C.02", + "23.1.55.C.03", + "23.2.20.C.01" ], - "END-01": [ - "5.1.1.15", - "12.2.1.2" + "CLD-06.1": [ + "20.1.21.C.03", + "23.1.55.C.01", + "23.1.55.C.02", + "23.1.55.C.03" ], - "END-02": [ - "6.2.1", - "6.2.1.1", - "6.2.1.2", - "6.2.1.3", - "6.2.1.4", - "6.2.1.5", - "6.2.1.6", - "6.2.1.7", - "6.2.1.8", - "6.2.1.9", - "6.2.1.10", - "6.2.1.11", - "6.2.1.12", - "6.2.1.13", - "6.2.1.14", - "6.2.1.15", - "6.2.1.16", - "6.2.1.17", - "6.2.1.21", - "6.2.1.22" + "CLD-06.2": [ + "23.5.11.C.01", + "23.5.12.C.01", + "23.5.12.C.02" ], - "END-04": [ - "12.2", - "12.2.1", - "12.2.1.1", - "12.2.1.3", - "12.2.1.4", - "12.2.1.5", - "12.2.1.6", - "12.2.1.7", - "12.2.1.8", - "12.2.1.9", - "12.2.1.15" + "CLD-06.4": [ + "23.5.12.C.01", + "23.5.12.C.02" ], - "HRS-01": [ - "4.5.2.2", - "5.1.1.12", - "7", - "7.1", - "7.1.1.13" + "CLD-09": [ + "20.1.22.C.01", + "20.1.22.C.02", + "20.1.22.C.03", + "20.1.22.C.04", + "20.1.22.C.05", + "20.1.22.C.06", + "22.1.22.C.01", + "22.1.22.C.02", + "23.4.11.C.01", + "23.4.11.C.02" ], - "HRS-01.1": [ - "8.1.4.1", - "8.1.4.2", - "8.1.4.3", - "8.1.4.4", - "9.2.6.2", - "9.2.6.4", - "9.2.6.5", - "9.2.6.6" + "CPL-01": [ + "1.1.64.C.01", + "1.1.65.C.01", + "1.1.66.C.01", + "1.1.66.C.02", + "1.1.67.C.01", + "1.2.15.C.01", + "1.2.15.C.02", + "17.9.37.C.01" ], - "HRS-02": [ - "4.5.2.2" + "CPL-01.1": [ + "1.1.68.C.01", + "1.1.69.C.01", + "1.1.69.C.02" ], - "HRS-03": [ - "4.5.2.2", - "6.1.1", - "6.1.1.1", - "6.1.1.2", - "6.1.1.3", - "6.1.1.4", - "6.1.1.5", - "6.1.1.6", - "6.1.1.7", - "6.1.1.13.PB" + "CPL-02": [ + "6.1.7.C.01", + "23.2.18.C.01" ], - "HRS-03.1": [ - "4.5.2.6", - "4.5.2.7", - "4.5.2.8", - "7.1.2.7", - "7.2", - "7.2.1.4", - "8.1.3.1" + "CPL-02.2": [ + "17.9.33.C.01", + "17.9.33.C.02", + "17.9.33.C.03" ], - "HRS-03.2": [ - "4.5.2.2", - "4.5.2.3", - "7.1.1.6", - "14.2.1.7", - "14.2.1.8", - "14.2.1.11" + "CPL-03": [ + "4.3.16.C.01", + "6.1.7.C.01", + "6.1.9.C.01", + "23.2.18.C.01" ], - "HRS-04": [ - "7.1.1", - "7.1.1.1", - "7.1.1.2", - "7.1.1.3", - "7.1.1.5", - "7.1.1.9", - "7.1.1.10" + "CPL-03.1": [ + "6.1.8.C.01" ], - "HRS-04.1": [ - "7.1.1.7", - "7.1.1.8" + "CPL-03.2": [ + "6.1.7.C.01", + "6.1.9.C.01", + "23.2.18.C.01" ], - "HRS-04.2": [ - "4.5.2.6", - "7.2", - "7.2.1.1", - "8.1.3.1" + "CFG-01": [ + "4.3.19.C.01", + "12.2.5.C.01", + "12.2.5.C.02", + "12.2.6.C.01", + "12.2.6.C.02", + "17.9.38.C.03", + "18.1.10.C.01", + "18.1.10.C.02", + "18.1.10.C.03", + "18.1.10.C.04", + "20.2.14.C.02" ], - "HRS-05": [ - "7.1.2", - "7.1.2.1", - "7.1.2.2", - "7.1.2.3", - "7.1.2.4", - "7.1.2.5", - "7.1.2.6", - "7.1.2.8", - "7.1.2.9", - "7.2.1", - "7.2.1.5", - "9.2.4.2" + "CFG-01.1": [ + "4.3.19.C.01" ], - "HRS-05.1": [ - "7.2.1.2", - "8.1.3", - "8.1.3.2" + "CFG-02": [ + "11.1.16.C.01", + "11.1.16.C.02", + "11.1.17.C.01", + "11.1.17.C.03", + "11.8.6.C.01", + "11.8.6.C.02", + "14.1.8.C.01", + "14.1.9.C.01", + "14.1.9.C.02", + "14.1.10.C.01", + "14.1.10.C.02", + "14.3.7.C.01", + "15.2.41.C.01", + "15.2.41.C.02", + "15.2.42.C.01", + "15.2.43.C.01", + "15.2.44.C.01", + "15.2.46.C.01", + "15.2.46.C.03", + "15.2.47.C.01", + "15.2.47.C.02", + "15.2.48.C.01", + "15.2.48.C.02", + "15.2.48.C.03", + "15.2.49.C.01", + "15.2.49.C.02", + "15.2.49.C.03", + "15.2.50.C.01", + "15.2.50.C.02", + "15.2.50.C.03", + "15.2.50.C.04", + "16.1.31.C.03", + "16.1.31.C.04", + "16.1.31.C.05", + "16.7.42.C.01", + "20.2.14.C.05", + "20.2.14.C.07", + "22.1.16.C.01", + "22.1.16.C.02", + "22.1.17.C.01", + "22.1.17.C.02", + "22.1.17.C.03", + "22.1.19.C.01", + "22.1.19.C.02", + "23.2.21.C.01" ], - "HRS-05.3": [ - "13.2.1.1", - "13.2.1.2", - "13.2.1.3", - "13.2.1.4", - "13.2.1.8", - "13.2.1.11" + "CFG-02.1": [ + "15.2.45.C.01" ], - "HRS-05.7": [ - "4.5.2.6", - "4.5.2.8", - "7.2", - "7.2.1.3", - "8.1.3.1" + "CFG-02.4": [ + "18.1.10.C.01", + "18.1.10.C.02", + "18.1.10.C.03", + "18.1.10.C.04" ], - "HRS-06.1": [ - "13.2.4", - "13.2.4.1", - "13.2.4.2", - "13.2.4.3", - "13.2.4.4", - "13.2.4.5", - "13.2.4.6", - "13.2.4.7", - "13.2.4.8", - "13.2.4.9", - "13.2.4.10", - "13.2.4.11", - "13.2.4.12", - "13.2.4.13", - "13.2.4.14", - "13.2.4.15", - "13.2.4.16" + "CFG-02.5": [ + "15.2.38.C.01", + "18.1.10.C.01", + "18.1.10.C.02", + "18.1.10.C.03", + "18.1.10.C.04", + "23.2.21.C.01" ], - "HRS-06.2": [ - "7.1.2.10" + "CFG-02.6": [ + "18.1.10.C.01", + "18.1.10.C.02", + "18.1.10.C.03", + "18.1.10.C.04" ], - "HRS-07": [ - "7.2.3", - "7.2.3.1", - "7.2.3.2", - "7.2.3.3", - "7.2.3.4" + "CFG-03": [ + "18.1.15.C.01", + "18.1.15.C.02", + "18.1.15.C.03", + "18.1.15.C.04" ], - "HRS-09": [ - "7.3", - "7.3.1", - "7.3.1.1", - "7.3.1.2", - "7.3.1.3" + "CFG-03.3": [ + "14.2.4.C.01", + "14.2.5.C.01", + "14.2.5.C.02", + "14.2.5.C.03", + "14.2.5.C.04", + "14.2.6.C.01", + "14.2.7.C.01", + "14.2.7.C.02", + "14.2.7.C.03", + "14.2.7.C.04", + "14.2.7.C.05", + "14.2.7.C.06", + "14.2.7.C.07", + "21.3.12.C.02" ], - "HRS-10": [ - "7.1.1.10" + "CFG-03.4": [ + "18.7.14.C.01", + "18.7.14.C.02" ], - "HRS-11": [ - "4.5.2.2", - "6.1.2", - "6.1.2.1", - "6.1.2.2", - "6.1.2.3", - "6.1.2.4" + "MON-01": [ + "16.6.6.C.01", + "16.6.6.C.02", + "16.6.8.C.01", + "16.6.10.C.01", + "16.6.10.C.02" ], - "HRS-15": [ - "7.2.1.7" + "MON-01.1": [ + "16.6.10.C.01", + "16.6.10.C.02", + "18.4.7.C.01", + "18.4.7.C.02", + "18.4.7.C.03", + "18.4.8.C.01", + "18.4.8.C.02", + "18.4.8.C.03", + "18.4.9.C.01", + "18.4.9.C.02", + "18.4.10.C.01", + "18.4.11.C.01", + "18.4.11.C.02", + "18.4.11.C.03", + "18.4.12.C.01", + "18.4.14.C.01" ], - "IAC-01": [ - "5.1.1.9", - "9", - "9.1", - "9.1.1", - "9.1.1.1", - "9.1.1.2", - "9.1.1.3", - "9.1.1.4", - "9.1.1.5", - "9.1.1.6", - "9.1.1.7", - "9.1.1.8", - "9.1.1.9", - "9.1.1.10", - "9.1.1.11", - "9.1.1.12", - "9.1.1.13", - "9.1.1.14", - "9.1.1.15", - "9.4.1.8.PB" + "MON-01.2": [ + "16.6.15.C.01", + "16.6.15.C.02" ], - "IAC-01.2": [ - "9.4.2", - "9.4.2.1", - "9.4.2.2.B", - "9.4.2.3", - "9.4.2.4", - "9.4.2.5", - "9.4.2.6", - "9.4.2.7", - "9.4.2.8", - "9.4.2.9", - "9.4.2.10", - "9.4.2.11", - "9.4.2.12", - "9.4.2.13", - "9.4.2.14", - "9.4.2.15", - "9.4.2.16" + "MON-01.3": [ + "15.2.40.C.02", + "16.6.10.C.01", + "16.6.10.C.02", + "18.4.8.C.01", + "18.4.8.C.02", + "18.4.8.C.03" ], - "IAC-07": [ - "9.2.2", - "9.2.2.2", - "9.2.2.3", - "9.2.2.4", - "9.2.2.6", - "9.2.2.8.PB", - "9.2.6", - "9.2.6.3" + "MON-01.5": [ + "16.6.10.C.01", + "16.6.10.C.02", + "18.4.8.C.01", + "18.4.8.C.02", + "18.4.8.C.03" ], - "IAC-08": [ - "8.1.2.5", - "9.4", - "9.4.1", - "9.4.1.1", - "9.4.1.2", - "9.4.1.3", - "9.4.1.4", - "9.4.1.5", - "9.4.1.6", - "9.4.1.7" + "MON-01.7": [ + "16.6.10.C.01", + "16.6.10.C.02" ], - "IAC-10": [ - "9.2.4", - "9.2.4.1", - "9.2.4.3", - "9.2.4.4", - "9.2.4.5", - "9.2.4.6", - "9.2.4.7", - "9.2.4.8" + "MON-01.9": [ + "14.3.6.C.02", + "16.6.10.C.01", + "16.6.10.C.02" ], - "IAC-10.1": [ - "9.3.1.4", - "9.4.3", - "9.4.3.1", - "9.4.3.2", - "9.4.3.3", - "9.4.3.4", - "9.4.3.5", - "9.4.3.6", - "9.4.3.7", - "9.4.3.8", - "9.4.3.9" + "MON-01.16": [ + "16.6.6.C.01", + "16.6.6.C.02", + "16.6.8.C.01", + "16.6.10.C.01", + "16.6.10.C.02" ], - "IAC-10.5": [ - "9.3", - "9.3.1", - "9.3.1.1", - "9.3.1.2", - "9.3.1.3", - "9.3.1.5", - "9.3.1.6", - "9.3.1.7" + "MON-02": [ + "16.6.11.C.01", + "16.6.11.C.02", + "16.6.11.C.03", + "16.6.12.C.01", + "16.6.12.C.02", + "16.6.12.C.03" ], - "IAC-15": [ - "9.2", - "9.2.1", - "9.2.1.1", - "9.2.1.2", - "9.2.1.3", - "9.2.1.4", - "9.2.1.5", - "9.2.1.6.PB", - "9.2.4.9.PB" + "MON-02.1": [ + "16.6.14.C.01", + "18.4.12.C.01" ], - "IAC-15.1": [ - "9.2.2.5" + "MON-02.2": [ + "16.6.11.C.01", + "16.6.11.C.02", + "16.6.11.C.03", + "16.6.12.C.01", + "16.6.12.C.02", + "16.6.12.C.03" ], - "IAC-16": [ - "9.2.3", - "9.2.3.2", - "9.2.3.3", - "9.2.3.4", - "9.2.3.5", - "9.2.3.6", - "9.2.3.7", - "9.2.3.8", - "9.2.3.9", - "9.2.3.10" + "MON-02.7": [ + "16.6.11.C.02" ], - "IAC-17": [ - "9.2.2.7", - "9.2.5", - "9.2.5.1", - "9.2.5.2", - "9.2.5.3", - "9.2.5.4", - "9.2.5.5", - "9.2.5.6" + "MON-03": [ + "16.6.7.C.01", + "16.6.9.C.01", + "16.6.10.C.01", + "16.6.10.C.02" ], - "IAC-20.3": [ - "9.4.4", - "9.4.4.1", - "9.4.4.2", - "9.4.4.3", - "9.4.4.4", - "9.4.4.5", - "9.4.4.6", - "9.4.4.7", - "9.4.4.8", - "9.4.4.9", - "9.4.4.10.P", - "9.4.4.11.P" + "MON-03.2": [ + "16.6.8.C.01", + "16.6.9.C.01", + "16.6.10.C.01", + "16.6.10.C.02" ], - "IAC-20.6": [ - "9.2.6.1" + "MON-03.3": [ + "16.4.41.C.01", + "16.4.41.C.02" ], - "IAC-21": [ - "9.1.2", - "9.1.2.1", - "9.1.2.2", - "9.1.2.3", - "9.1.2.4", - "9.1.2.5", - "9.1.2.6", - "9.1.2.7", - "9.1.2.8" + "MON-03.7": [ + "16.6.7.C.01", + "16.6.9.C.01", + "16.6.10.C.01", + "16.6.10.C.02" ], - "IAC-28": [ - "7.1.1.4" + "MON-04": [ + "16.6.13.C.01", + "16.6.13.C.02", + "16.6.13.C.03", + "16.6.13.C.04" ], - "IAC-28.1": [ - "9.2.2.1" + "MON-08": [ + "16.6.13.C.01", + "16.6.13.C.02", + "16.6.13.C.03", + "16.6.13.C.04" ], - "IRO-01": [ - "16", - "16.1", - "16.1.1.2", - "16.1.1.4", - "16.1.1.5", - "16.1.1.6.P", - "16.1.1.7.P", - "16.1.1.8.P", - "16.1.1.9.P", - "16.1.1.10.P", - "16.1.1.11.P", - "16.1.1.12.P" + "MON-08.1": [ + "16.6.13.C.01", + "16.6.13.C.02", + "16.6.13.C.03", + "16.6.13.C.04" ], - "IRO-02": [ - "16.1.1", - "16.1.1.1", - "16.1.1.3", - "16.1.2", - "16.1.2.1", - "16.1.2.2", - "16.1.2.3", - "16.1.2.4", - "16.1.2.5", - "16.1.2.6", - "16.1.2.7", - "16.1.2.8", - "16.1.2.9", - "16.1.2.10", - "16.1.2.11.P", - "16.1.2.12.P", - "16.1.2.13.P", - "16.1.3", - "16.1.3.1", - "16.1.3.2", - "16.1.5.9" + "MON-08.2": [ + "16.4.41.C.03" ], - "IRO-02.4": [ - "16.1.4", - "16.1.4.1", - "16.1.4.2" + "MON-10": [ + "16.6.13.C.05" ], - "IRO-04": [ - "16.1.5", - "16.1.5.1", - "16.1.5.2", - "16.1.5.3", - "16.1.5.4", - "16.1.5.5", - "16.1.5.6", - "16.1.5.7", - "16.1.5.8" + "CRY-01": [ + "8.4.13.C.01", + "17.1.52.C.01", + "17.1.52.C.02", + "17.1.53.C.01", + "17.1.53.C.02", + "17.1.53.C.03", + "17.1.53.C.04", + "17.1.54.C.01", + "17.1.55.C.01", + "17.1.55.C.02", + "17.1.55.C.03", + "17.1.55.C.04", + "17.1.56.C.01", + "17.1.56.C.02", + "17.1.57.C.01", + "17.2.17.C.01", + "17.2.18.C.01", + "17.2.19.C.01", + "17.2.20.C.01", + "17.2.20.C.02", + "17.2.21.C.01", + "17.2.22.C.01", + "17.2.22.C.02", + "17.2.23.C.01", + "17.2.24.C.01", + "17.2.24.C.02", + "17.2.24.C.03", + "17.2.25.C.01", + "17.2.26.C.01", + "17.2.26.C.02", + "17.2.26.C.03", + "17.2.27.C.01", + "17.2.27.C.02", + "17.2.27.C.03", + "17.2.28.C.01", + "17.3.6.C.01", + "17.4.16.C.01", + "17.4.16.C.02", + "17.5.6.C.01", + "17.6.7.C.01", + "17.7.6.C.01", + "17.8.10.C.01", + "17.8.10.C.02", + "17.8.11.C.01", + "17.8.12.C.01", + "17.8.13.C.01", + "17.8.14.C.01", + "17.8.15.C.01", + "17.8.16.C.01", + "17.8.17.C.01", + "17.9.30.C.01", + "17.9.30.C.02", + "17.9.30.C.03", + "17.9.31.C.01", + "17.9.32.C.01", + "17.9.32.C.02", + "17.9.38.C.01", + "17.9.38.C.02" ], - "IRO-04.3": [ - "16.1.1.14" + "CRY-01.5": [ + "17.9.34.C.01" ], - "IRO-08": [ - "16.1.7", - "16.1.7.1", - "16.1.7.2", - "16.1.7.3", - "16.1.7.4", - "16.1.7.5", - "16.1.7.6", - "16.1.7.7", - "16.1.7.8", - "16.1.7.9", - "16.1.7.10", - "16.1.7.11", - "16.1.7.12", - "16.1.7.13.PB" + "CRY-05": [ + "8.4.13.C.01" ], - "IRO-09.2": [ - "16.1.5.10" + "CRY-05.1": [ + "8.4.13.C.01" ], - "IRO-10": [ - "6.1.3.2" + "CRY-07": [ + "18.2.9.C.01", + "18.2.9.C.02", + "18.2.10.C.01", + "18.2.10.C.02", + "18.2.11.C.01", + "18.2.11.C.02", + "18.2.11.C.03", + "18.2.11.C.04", + "18.2.11.C.05", + "18.2.12.C.01", + "18.2.12.C.02", + "18.2.13.C.01", + "18.2.14.C.01", + "18.2.15.C.01", + "18.2.16.C.01", + "18.2.17.C.01", + "18.2.18.C.01", + "18.2.19.C.01", + "18.2.20.C.01", + "18.2.20.C.02", + "18.2.20.C.03", + "18.2.21.C.01", + "18.2.22.C.01", + "18.2.23.C.01", + "18.2.23.C.02", + "18.2.24.C.01", + "18.2.25.C.01" ], - "IRO-10.4": [ - "16.1.1.15.P" + "CRY-08": [ + "17.1.51.C.01", + "23.3.21.C.01", + "23.3.22.C.01" ], - "IRO-13": [ - "16.1.6", - "16.1.6.1", - "16.1.6.2" + "CRY-08.1": [ + "17.1.51.C.01" ], - "IRO-15": [ - "12.2.1.14" + "CRY-09": [ + "17.1.51.C.01", + "17.1.58.C.01", + "17.1.58.C.02", + "17.1.58.C.03", + "23.3.21.C.01", + "23.3.22.C.01", + "23.4.9.C.02", + "23.4.9.C.03" ], - "IAO-02": [ - "14.1.1.12", - "14.1.1.17", - "14.1.1.18", - "14.2.7.4", - "14.2.9", - "14.2.9.1", - "14.2.9.2", - "14.2.9.3", - "14.2.9.4" + "CRY-09.3": [ + "7.2.24.C.01" ], - "IAO-03": [ - "4.4.4", - "4.4.5.2" + "CRY-09.7": [ + "23.4.9.C.02", + "23.4.9.C.03" ], - "IAO-03.2": [ - "13.2.2", - "13.2.2.2", - "13.2.2.3", - "13.2.2.4", - "13.2.2.6", - "13.2.2.7", - "13.2.2.8", - "13.2.2.9", - "13.2.2.10", - "13.2.2.11" + "CRY-11": [ + "23.3.21.C.01", + "23.3.22.C.01" ], - "IAO-05": [ - "4.4.6.1", - "4.7.1.4", - "4.7.1.7" + "DCH-01": [ + "4.4.10.C.01", + "9.2.12.C.01", + "9.2.13.C.01", + "9.2.13.C.02", + "9.2.14.C.01", + "9.2.15.C.01", + "9.2.15.C.02", + "9.2.17.C.01", + "9.2.17.C.02", + "9.2.18.C.01", + "9.2.19.C.01", + "9.2.19.C.02", + "9.2.19.C.03", + "9.2.19.C.04", + "9.2.20.C.01", + "13.2.6.C.01", + "13.2.7.C.01" ], - "MNT-01": [ - "11.2.4", - "11.2.4.1", - "11.2.4.3", - "11.2.4.5" + "DCH-01.2": [ + "16.2.7.C.01", + "16.2.7.C.02", + "18.6.8.C.01" ], - "MNT-02": [ - "11.2.4.4" + "DCH-02": [ + "12.3.4.C.01", + "12.3.5.C.01", + "12.3.5.C.02", + "12.3.6.C.01", + "12.3.7.C.01", + "18.6.8.C.01" ], - "MNT-04.3": [ - "11.2.5", - "11.2.5.1", - "11.2.5.2", - "11.2.5.3", - "11.2.5.4" + "DCH-02.1": [ + "4.4.9.C.01", + "13.2.8.C.01", + "13.2.9.C.01", + "18.6.9.C.01" ], - "MNT-05": [ - "11.2.4.8", - "11.2.4.9", - "11.2.4.10" + "DCH-04": [ + "4.4.10.C.01", + "12.3.4.C.01", + "12.3.5.C.01", + "12.3.5.C.02", + "12.3.6.C.01", + "12.3.7.C.01", + "13.2.12.C.01", + "13.2.12.C.02", + "13.2.12.C.03", + "13.2.12.C.04", + "13.2.13.C.01", + "13.2.14.C.01", + "13.2.14.C.02" ], - "MNT-05.1": [ - "11.2.4.7" + "DCH-04.1": [ + "15.2.39.C.02", + "15.2.39.C.03" ], - "MNT-05.4": [ - "11.2.4.11" + "DCH-06": [ + "8.4.10.C.01", + "8.4.11.C.01", + "8.4.12.C.01", + "8.4.13.C.01", + "13.3.5.C.01" ], - "MNT-05.5": [ - "11.2.4.7" + "DCH-06.4": [ + "8.4.13.C.01" ], - "MNT-06": [ - "11.2.4.2" + "DCH-07.2": [ + "8.4.13.C.01" ], - "MNT-09": [ - "11.2.6", - "11.2.6.1", - "11.2.6.2", - "11.2.6.3", - "11.2.6.4", - "11.2.6.5", - "11.2.6.6" + "DCH-08": [ + "11.7.35.C.01", + "12.6.6.C.01", + "12.6.6.C.02", + "12.6.7.C.01", + "12.6.7.C.02", + "13.5.23.C.01", + "13.5.24.C.01", + "13.5.24.C.02", + "13.5.24.C.03", + "13.5.24.C.04", + "13.5.25.C.01", + "13.5.26.C.01", + "13.5.26.C.02", + "13.5.26.C.03", + "13.5.29.C.01", + "13.5.29.C.02", + "13.5.30.C.01" ], - "MNT-10": [ - "11.2.4.6" + "DCH-09": [ + "12.6.5.C.05", + "13.4.9.C.01", + "13.4.11.C.01", + "13.4.12.C.01", + "13.4.13.C.01", + "13.4.13.C.02", + "13.4.13.C.03", + "13.4.13.C.04", + "13.4.13.C.05", + "13.4.14.C.01", + "13.4.15.C.01", + "13.4.16.C.01", + "13.4.17.C.01", + "13.4.18.C.01", + "13.4.19.C.01", + "13.4.19.C.02", + "13.4.20.C.01", + "13.4.20.C.02", + "13.4.20.C.03", + "13.4.21.C.01", + "13.4.22.C.01" ], - "MDM-06": [ - "6.2.1.23" + "DCH-09.1": [ + "13.5.22.C.01", + "13.5.27.C.01", + "13.5.27.C.02", + "13.5.27.C.03", + "13.5.28.C.01", + "13.5.28.C.02" ], - "NET-01": [ - "5.1.1.18", - "13", - "13.1", - "13.1.1", - "13.1.1.1", - "13.1.1.2", - "13.1.1.3", - "13.1.1.5", - "13.1.1.6", - "13.1.1.7", - "13.1.1.8", - "13.1.1.9", - "13.1.2" + "DCH-09.2": [ + "13.4.23.C.01" ], - "NET-01.1": [ - "9.1.1.16" + "DCH-10": [ + "13.3.4.C.01" ], - "NET-03.3": [ - "14.1.1.23" + "DCH-10.1": [ + "13.3.4.C.01" ], - "NET-05.2": [ - "13.1.1.10" + "DCH-11": [ + "13.2.10.C.01", + "13.2.11.C.01" ], - "NET-06": [ - "13.1.3", - "13.1.3.1", - "13.1.3.2", - "13.1.3.3", - "13.1.3.4", - "13.1.3.5", - "13.1.3.6", - "13.1.3.7", - "13.1.3.8", - "13.1.3.9", - "13.1.3.10.P", - "13.1.3.11.P", - "13.1.3.12.P", - "13.1.4.P" + "DCH-12": [ + "13.3.6.C.01", + "13.3.6.C.02", + "13.3.6.C.03", + "13.3.10.C.01" ], - "NET-06.1": [ - "13.1.4.P" + "DCH-13.2": [ + "11.8.11.C.01", + "11.8.11.C-02", + "13.3.7.C.01", + "13.3.7.C.02", + "13.3.8.C.01", + "13.3.8.C.02", + "13.3.9.C.01", + "13.3.9.C.02", + "13.3.10.C.01" ], - "NET-06.2": [ - "13.1.4.P" + "DCH-14.3": [ + "16.2.5.C.01", + "16.2.6.C.01" ], - "NET-06.3": [ - "13.1.4.P" + "END-04": [ + "14.1.9.C.02", + "21.3.10.C.01" ], - "NET-12": [ - "13.1.1.4", - "14.1.2", - "14.1.2.1", - "14.1.2.2", - "14.1.2.3", - "14.1.2.4", - "14.1.2.5", - "14.1.2.6", - "14.1.2.7", - "14.1.2.8", - "14.1.2.9", - "14.1.2.10", - "14.1.2.11", - "14.1.2.12", - "14.1.2.13", - "14.1.2.14", - "14.1.2.15" + "END-06": [ + "14.1.12.C.01", + "14.1.12.C.02", + "14.1.12.C.03" ], - "NET-13": [ - "13.2.2.12", - "13.2.2.13", - "13.2.3", - "13.2.3.1", - "13.2.3.2", - "13.2.3.3", - "13.2.3.4", - "13.2.3.5", - "13.2.3.6", - "13.2.3.7.P" + "END-07": [ + "18.4.13.C.01" ], - "NET-14.5": [ - "6.2", - "6.2.2", - "6.2.2.1", - "6.2.2.2", - "6.2.2.3", - "6.2.2.4", - "6.2.2.5", - "6.2.2.6", - "6.2.2.7", - "6.2.2.8", - "6.2.2.9", - "6.2.2.10", - "6.2.2.11", - "6.2.2.12", - "6.2.2.13", - "6.2.2.14", - "6.2.2.15", - "6.2.2.16", - "6.2.2.17", - "6.2.2.18", - "6.2.2.19", - "6.2.2.20", - "6.2.2.21" + "END-08": [ + "15.2.37.C.01" ], - "PES-01": [ - "5.1.1.11", - "11", - "11.1", - "11.1.4", - "11.1.4.1", - "11.2.1.3" + "HRS-01": [ + "9.2.10.C.01", + "9.2.11.C.01", + "9.2.11.C.02", + "14.3.5.C.01", + "15.1.7.C.01" ], - "PES-02": [ - "11.1.2.3", - "11.1.2.12" + "HRS-02": [ + "9.2.10.C.01", + "9.2.11.C.01", + "9.2.11.C.02" ], - "PES-03": [ - "11.1.1", - "11.1.1.1", - "11.1.1.2", - "11.1.1.3", - "11.1.1.4", - "11.1.1.5", - "11.1.1.6", - "11.1.1.7", - "11.1.2", - "11.1.2.1", - "11.1.2.2", - "11.1.2.5", - "11.1.2.10" + "HRS-03": [ + "3.3.4.C.01", + "3.3.4.C.02", + "3.3.4.C.03", + "3.3.4.C.04", + "3.3.4.C.05", + "3.3.5.C.01", + "3.3.5.C.02", + "3.3.6.C.01", + "3.3.6.C.02", + "3.3.6.C.03", + "3.3.6.C.04", + "3.3.6.C.05", + "3.3.6.C.06", + "3.3.7.C.01", + "3.3.8.C.01", + "3.3.8.C.02", + "3.3.8.C.03", + "3.3.8.C.04", + "3.3.8.C.05", + "3.3.9.C.01", + "3.3.10.C.01", + "3.3.10.C.02", + "3.3.10.C.03", + "3.3.10.C.04", + "3.3.11.C.01", + "3.3.12.C.01", + "3.3.13.C.01", + "3.3.13.C.02", + "3.3.14.C.01", + "3.3.14.C.02", + "3.3.14.C.03", + "3.3.15.C.01", + "3.4.10.C.01", + "3.4.10.C.02", + "17.9.35.C.01" ], - "PES-03.3": [ - "11.1.2.7" + "HRS-03.2": [ + "5.1.14.C.01" ], - "PES-04": [ - "11.1.2.6", - "11.1.3", - "11.1.3.1", - "11.1.3.2", - "11.1.3.3", - "11.1.3.4", - "11.2.9", - "11.2.9.1", - "11.2.9.2", - "11.2.9.3", - "11.2.9.4", - "11.2.9.5", - "11.2.9.6" + "HRS-04.2": [ + "9.1.7.C.01" ], - "PES-04.1": [ - "11.1.2.11", - "11.1.5", - "11.1.5.1", - "11.1.5.2", - "11.1.5.3", - "11.1.5.4", - "11.1.5.5", - "11.1.5.6" + "HRS-04.3": [ + "9.2.10.C.01", + "9.2.11.C.01", + "9.2.11.C.02", + "9.2.15.C.01", + "9.2.15.C.02", + "9.2.16.C.01" ], - "PES-05": [ - "11.1.2.13" + "HRS-04.4": [ + "9.2.15.C.01", + "9.2.15.C.02", + "9.2.16.C.01", + "16.1.39.C.01", + "16.1.39.C.02" ], - "PES-06": [ - "11.1.2.4" + "HRS-05": [ + "3.5.4.C.01", + "3.5.4.C.02", + "3.5.4.C.03", + "5.5.7.C.01", + "8.1.12.C.01", + "9.3.7.C.01", + "9.3.7.C.02", + "9.3.7.C.03", + "9.3.7.C.04", + "9.3.8.C.01", + "9.3.8.C.02", + "9.3.8.C.03", + "21.1.6.C.02", + "21.2.3.C.01" ], - "PES-06.1": [ - "11.1.2.8" + "HRS-05.1": [ + "3.5.4.C.01", + "3.5.4.C.02", + "3.5.4.C.03", + "5.5.7.C.01", + "8.1.12.C.01", + "9.1.8.C.01", + "9.3.7.C.01", + "9.3.7.C.02", + "9.3.7.C.03", + "9.3.7.C.04", + "9.3.8.C.01", + "9.3.8.C.02", + "9.3.8.C.03", + "14.3.5.C.01", + "15.1.7.C.01", + "16.4.38.C.02" ], - "PES-06.3": [ - "11.1.2.9" + "HRS-05.2": [ + "9.3.7.C.01", + "9.3.7.C.02", + "9.3.7.C.03", + "9.3.7.C.04", + "9.3.8.C.01", + "9.3.8.C.02", + "9.3.8.C.03" ], - "PES-07": [ - "11.2.2", - "11.2.2.1", - "11.2.2.2", - "11.2.2.3", - "11.2.2.4", - "11.2.2.5" + "HRS-05.3": [ + "9.3.4.C.01", + "9.3.5.C.01", + "9.3.5.C.02", + "9.3.9.C.01", + "9.3.10.C.01", + "11.1.15.C.01", + "11.1.16.C.03", + "11.1.16.C.04", + "11.1.17.C.02", + "11.1.18.C.01", + "11.1.18.C.02", + "11.1.19.C.02", + "11.2.14.C.01", + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03", + "11.8.4.C.01", + "11.8.4.C.02", + "11.8.5.C.01", + "11.8.6.C.01", + "11.8.6.C.02", + "15.1.7.C.01" ], - "PES-07.2": [ - "11.2.2.7" + "HRS-05.5": [ + "8.1.12.C.01", + "11.4.9.C.01", + "11.4.10.C.01", + "11.4.10.C.02", + "11.4.11.C.01", + "11.4.12.C.01", + "11.4.12.C.02", + "11.5.13.C.01", + "11.5.14.C.01", + "11.5.14.C.02", + "11.5.15.C.01", + "11.5.15.C.02", + "11.5.16.C.01", + "11.5.16.C.02", + "11.5.16.C.03", + "21.1.11.C.01", + "22.1.10.C.02", + "22.1.13.C.01", + "22.1.13.C.02", + "22.1.13.C.03", + "22.1.13.C.04", + "22.1.13.C.05", + "22.2.5.C.01", + "22.2.6.C.01", + "22.2.7.C.01", + "22.2.7.C.02", + "22.3.5.C.01", + "22.3.6.C.01", + "22.4.9.C.01" ], - "PES-07.4": [ - "11.2.2.6" + "HRS-06.1": [ + "9.1.8.C.01" ], - "PES-10": [ - "11.1.6", - "11.1.6.1", - "11.1.6.2", - "11.1.6.3", - "11.1.6.4", - "11.1.6.5", - "11.1.6.6", - "11.1.6.7" + "IAC-01": [ + "16.1.31.C.01", + "16.4.39.C.01", + "20.2.16.C.02" ], - "PES-12": [ - "11.2", - "11.2.1", - "11.2.1.1", - "11.2.1.2", - "11.2.1.4", - "11.2.1.5", - "11.2.1.6", - "11.2.1.7", - "11.2.1.8", - "11.2.1.9", - "11.2.1.10", - "11.2.7.4.PB" + "IAC-01.2": [ + "16.1.26.C.01" ], - "PES-12.1": [ - "11.2.3", - "11.2.3.1", - "11.2.3.2", - "11.2.3.3" + "IAC-02": [ + "16.1.32.C.01" ], - "PRI-01": [ - "5.1.1", - "5.1.1.19", - "18.1.4" + "IAC-02.1": [ + "16.1.33.C.01", + "16.1.34.C.01" ], - "PRI-01.3": [ - "5.1.1" + "IAC-06": [ + "16.1.29.C.02", + "16.4.37.C.02", + "16.7.42.C.01", + "16.7.42.C.04", + "16.7.42.C.05", + "16.7.42.C.06", + "16.7.42.C.07", + "16.7.43.C.01", + "16.7.44.C.01", + "23.3.19.C.01", + "23.3.19.C.02" ], - "PRI-01.11": [ - "7.1.1.12", - "18.1.4", - "18.1.4.1", - "18.1.4.2", - "18.1.4.3", - "18.1.4.4", - "18.1.4.5", - "18.1.4.6" + "IAC-06.1": [ + "16.7.42.C.02", + "16.7.42.C.03" ], - "PRM-01": [ - "4.5.1.1" + "IAC-06.2": [ + "16.7.42.C.03" ], - "PRM-01.1": [ - "5.1.1.2" + "IAC-07": [ + "23.3.20.C.01" ], - "PRM-01.2": [ - "4.4.5.2" + "IAC-08": [ + "9.2.11.C.01", + "9.2.11.C.02", + "16.2.4.C.01", + "16.2.5.C.01" ], - "PRM-02": [ - "4.5.1.1", - "4.5.5.3" + "IAC-10": [ + "14.3.13.C.01", + "14.3.13.C.02", + "14.3.13.C.03", + "16.1.36.C.02", + "16.1.36.C.03", + "16.1.40.C.01", + "16.1.41.C.01", + "16.1.41.C.02", + "16.1.42.C.01" ], - "PRM-02.1": [ - "4.5.5.3" + "IAC-10.1": [ + "16.1.29.C.01", + "16.1.31.C.02", + "16.1.31.C.07", + "16.1.35.C.01", + "16.1.35.C.02", + "16.1.42.C.01", + "16.1.43.C.01" ], - "PRM-03": [ - "4.5.1.2", - "4.5.5.3" + "IAC-10.4": [ + "16.1.41.C.01", + "16.1.41.C.02" ], - "PRM-04": [ - "4.5.1.1", - "6.1.5", - "6.1.5.1" + "IAC-10.5": [ + "16.1.34.C.02", + "16.1.36.C.01", + "16.1.37.C.01", + "16.1.38.C.01" ], - "PRM-05": [ - "4.4.3.1", - "4.4.5.2", - "4.5.1.1", - "6.1.5.2", - "14.1.1.2" + "IAC-10.6": [ + "16.1.36.C.01" ], - "PRM-06": [ - "4.4.3.1", - "4.4.5.2", - "4.5.1.1", - "6.1.5.5", - "13.1.2", - "14.1.1.2" + "IAC-10.11": [ + "14.3.13.C.01", + "14.3.13.C.02", + "14.3.13.C.03", + "16.1.37.C.02" ], - "PRM-07": [ - "6.1.5.4", - "14.1" + "IAC-12.1": [ + "17.10.12.C.01", + "17.10.12.C.02", + "17.10.12.C.03", + "17.10.12.C.04" ], - "RSK-01": [ - "4.4.6.1", - "4.5.5.2", - "4.8.1.1" + "IAC-15.5": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.28.C.01", + "16.1.33.C.01", + "16.1.34.C.01" ], - "RSK-01.1": [ - "4.4.6.1", - "4.4.7.2", - "4.4.7.3" + "IAC-16": [ + "16.3.5.C.01", + "16.3.6.C.01", + "16.3.6.C.02", + "16.3.7.C.01", + "16.4.36.C.01", + "16.4.36.C.02", + "16.4.36.C.03", + "16.4.37.C.01", + "16.4.37.C.03", + "16.4.38.C.01" ], - "RSK-01.3": [ - "4.4.7.1" + "IAC-16.1": [ + "16.4.40.C.01" ], - "RSK-01.4": [ - "4.4.7.1" + "IAC-16.2": [ + "23.3.18.C.01" ], - "RSK-01.5": [ - "4.4.7.1" + "IAC-18": [ + "16.4.37.C.01", + "16.4.38.C.02" ], - "RSK-03": [ - "4.4.6.1", - "4.4.7.2" + "IAC-19": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.27.C.03" ], - "RSK-03.1": [ - "4.4.7.2" + "IAC-21": [ + "16.2.4.C.01", + "23.4.10.C.01" ], - "RSK-04": [ - "4.4.6.1", - "4.4.7.1", - "4.4.7.2", - "4.4.7.3", - "4.4.7.4", - "4.6.1.1", - "6.1.5.3" + "IAC-25": [ + "16.1.44.C.01" ], - "RSK-04.1": [ - "4.4.7.2" + "IAC-29": [ + "16.1.31.C.06" ], - "RSK-04.2": [ - "4.4.6.1", - "4.4.7.1", - "4.4.7.4" + "IRO-01": [ + "7.1.7.C.01", + "7.1.7.C.02", + "7.1.7.C.03", + "7.2.18.C.01" ], - "RSK-04.3": [ - "4.4.7.3", - "4.5.5.1" + "IRO-02": [ + "5.7.4.C.01", + "7.2.18.C.01", + "7.2.18.C.02", + "7.2.19.C.01", + "7.3.9.C.01", + "7.3.10.C.01", + "20.1.25.C.02" ], - "RSK-06": [ - "4.6.1.1", - "4.7.1.1" + "IRO-02.5": [ + "7.3.10.C.01" ], - "RSK-06.1": [ - "4.4.7.4", - "4.4.8.1", - "4.4.8.2", - "4.4.8.5", - "4.7.1.3", - "4.7.1.6" + "IRO-04": [ + "5.1.12.C.01", + "5.1.12.C.02", + "5.6.3.C.01", + "5.6.3.C.02", + "7.2.18.C.01", + "7.3.5.C.01", + "7.3.9.C.01", + "7.3.10.C.01", + "16.4.39.C.02", + "16.4.42.C.01" ], - "RSK-06.2": [ - "4.4.8.1", - "4.4.8.2" + "IRO-07": [ + "7.2.18.C.01" ], - "RSK-06.3": [ - "4.4.7.1", - "4.4.8.1", - "4.4.8.2" + "IRO-08": [ + "7.3.11.C.01" ], - "RSK-06.4": [ - "4.4.6.1", - "4.4.7.1", - "4.4.8.1", - "4.4.8.2", - "4.4.8.3", - "4.4.8.4", - "4.4.8.5", - "4.5.5.2", - "4.7.1.1", - "4.7.1.4", - "4.9" + "IRO-09": [ + "3.2.16.C.01", + "7.3.6.C.01", + "7.3.6.C.02" ], - "RSK-08": [ - "4.4.7.3" + "IRO-10": [ + "7.2.18.C.01", + "7.2.18.C.02", + "7.2.20.C.01", + "7.2.20.C.02", + "7.2.20.C.03", + "7.2.21.C.01", + "7.2.23.C.01" ], - "SEA-01": [ - "14.2.5", - "14.2.5.1", - "14.2.5.2", - "14.2.5.3", - "14.2.5.4", - "14.2.5.5", - "14.2.5.6", - "14.2.5.7" + "IRO-10.2": [ + "7.2.18.C.01", + "7.2.20.C.01", + "7.2.21.C.01", + "7.2.23.C.01", + "7.3.8.C.03" ], - "SEA-02.2": [ - "4.5.4.5" + "IRO-10.4": [ + "7.2.22.C.01" ], - "SEA-05": [ - "9.5.P" + "IRO-11": [ + "7.3.12.C.01" ], - "SEA-20": [ - "12.4.4", - "12.4.4.1", - "12.4.4.2", - "12.4.4.3", - "12.4.4.4.PB" + "IRO-11.2": [ + "7.3.10.C.01", + "7.3.11.C.01", + "7.3.12.C.01" ], - "OPS-01": [ - "12", - "12.1", - "12.1.3.9.PB" + "IRO-12": [ + "7.3.7.C.01", + "7.3.7.C.02", + "7.3.7.C.03", + "7.3.7.C.04", + "7.3.7.C.05", + "7.3.7.C.06", + "7.3.8.C.01", + "7.3.8.C.02", + "7.3.8.C.03" ], - "OPS-01.1": [ - "8.3.1.11", - "12.1.1", - "12.1.1.1", - "12.1.1.2", - "12.1.1.3", - "12.1.1.4", - "12.1.1.5", - "12.1.1.6", - "12.1.1.7", - "12.1.1.8", - "12.1.1.9", - "12.1.1.10", - "12.1.1.11", - "12.1.1.12", - "12.1.1.13", - "12.1.5.P", - "12.1.5.1.PB" + "IRO-12.4": [ + "7.3.8.C.01", + "7.3.8.C.02" ], - "OPS-03": [ - "13.1.1.11.P", - "13.1.4.1.P", - "13.1.4.2.P", - "14.1.1.19.P", - "14.1.1.20.P" + "IAO-01": [ + "2.2.5.C.01", + "4.4.4.C.01", + "4.4.5.C.01", + "4.4.5.C.02", + "4.4.5.C.03", + "4.4.5.C.04", + "4.4.6.C.01", + "4.4.7.C.01", + "4.4.7.C.02", + "4.4.8.C.01", + "4.4.8.C.02", + "4.4.8.C.03", + "4.4.8.C.04", + "4.4.9.C.01", + "4.4.10.C.01", + "4.4.11.C.01", + "4.4.12.C.01", + "4.4.12.C.02", + "4.4.12.C.03", + "4.4.12.C.04", + "4.4.12.C.05" ], - "SAT-01": [ - "7.2.2.1", - "7.2.2.2", - "7.2.2.3", - "7.2.2.4", - "7.2.2.5", - "7.2.2.6", - "7.2.2.17", - "7.2.2.18" + "IAO-01.1": [ + "5.8.61.C.01", + "5.8.61.C.02", + "5.8.61.C.03", + "20.1.21.C.02", + "23.5.10.C.01" ], - "SAT-01.1": [ - "4.5.2.4", - "4.5.2.5" + "IAO-02": [ + "4.2.10.C.01", + "4.3.20.C.01", + "4.3.20.C.02", + "4.3.20.C.03", + "6.3.8.C.01", + "11.1.19.C.01", + "16.1.30.C.01", + "16.7.41.C.01", + "20.1.21.C.01", + "20.1.21.C.07", + "20.1.22.C.03", + "20.1.23.C.01", + "23.5.10.C.01" ], - "SAT-02": [ - "6.2.1.20", - "7.2.2", - "7.2.2.7", - "7.2.2.8", - "7.2.2.9", - "7.2.2.10", - "7.2.2.11", - "7.2.2.12", - "7.2.2.13", - "7.2.2.15", - "7.2.2.25" + "IAO-02.1": [ + "4.3.16.C.01" ], - "SAT-03": [ - "4.5.2.4", - "4.5.3.1", - "7.2.1.6", - "7.2.2.14", - "7.2.2.19.PB" + "IAO-02.2": [ + "4.3.20.C.01", + "4.3.20.C.02", + "4.3.20.C.03", + "20.2.13.C.01", + "20.2.13.C.02" ], - "SAT-03.3": [ - "7.2.2.16", - "7.2.2.19.PB" + "IAO-02.3": [ + "4.3.16.C.01", + "4.3.20.C.01", + "4.3.20.C.02", + "4.3.20.C.03", + "5.8.62.C.01" ], - "SAT-03.7": [ - "4.5.2.4" + "IAO-02.4": [ + "4.2.11.C.01", + "4.2.12.C.01", + "4.3.21.C.01", + "4.5.17.C.01", + "6.3.8.C.01" ], - "SAT-04": [ - "4.5.2.4", - "4.5.2.5" + "IAO-03": [ + "3.4.12.C.01", + "3.4.12.C.02", + "4.3.17.C.01", + "4.3.18.C.01", + "4.3.18.C.02", + "4.3.18.C.03", + "4.3.18.C.04", + "4.3.18.C.05", + "5.1.8.C.01", + "5.1.9.C.01", + "5.1.10.C.01", + "5.4.5.C.01", + "5.4.5.C.02", + "5.4.5.C.03" ], - "TDA-01": [ - "14", - "14.2", - "14.2.1", - "14.2.1.13.PB", - "14.2.7" + "IAO-03.2": [ + "2.2.5.C.02" ], - "TDA-01.1": [ - "14.1.1", - "14.2.7.11" + "IAO-04": [ + "6.2.5.C.01", + "6.2.6.C.01" ], - "TDA-02": [ - "14.1.1.2", - "14.1.1.3", - "14.1.1.4", - "14.1.1.5", - "14.1.1.6", - "14.1.1.7", - "14.1.1.8", - "14.1.1.9", - "14.1.1.10", - "14.1.1.11", - "14.1.1.16", - "14.2.1.3" + "IAO-05": [ + "4.2.12.C.01", + "6.3.8.C.01" ], - "TDA-04": [ - "14.1.1.15", - "14.2.7.10" + "IAO-07": [ + "2.2.5.C.01", + "4.2.11.C.01", + "4.5.18.C.01", + "4.5.18.C.02", + "4.5.18.C.03", + "20.1.21.C.04", + "20.1.22.C.01", + "20.1.22.C.03", + "20.1.22.C.05", + "23.2.16.C.03", + "23.2.16.C.04" ], - "TDA-06": [ - "14.1.1.1", - "14.2.1.2", - "14.2.1.9", - "14.2.1.10" + "MNT-01": [ + "12.5.3.C.01", + "12.5.3.C.02", + "12.5.6.C.01", + "12.5.6.C.02" ], - "TDA-06.2": [ - "14.2.7.3" + "MNT-02": [ + "11.8.10.C.01", + "11.8.10.C.04", + "12.5.3.C.01", + "12.5.3.C.02", + "12.5.6.C.01", + "12.5.6.C.02" ], - "TDA-07": [ - "14.2.1.1", - "14.2.6", - "14.2.6.1", - "14.2.6.2", - "14.2.6.3", - "14.2.6.4", - "14.2.6.5", - "14.2.6.6", - "14.2.6.7", - "14.2.6.8", - "14.2.6.9", - "14.2.6.10", - "14.2.6.11", - "14.2.6.12" + "MNT-04.3": [ + "11.8.10.C.02" ], - "TDA-08": [ - "12.1.4", - "12.1.4.1", - "12.1.4.2", - "12.1.4.3", - "12.1.4.4", - "12.1.4.5", - "12.1.4.6", - "12.1.4.7", - "12.1.4.8", - "12.1.4.9" + "MNT-06.1": [ + "12.5.4.C.01", + "12.5.4.C.02", + "12.5.4.C.03", + "12.5.4.C.04" ], - "TDA-08.1": [ - "14.2.6.11" + "MNT-08": [ + "12.5.5.C.01" ], - "TDA-09": [ - "14.2.1.4", - "14.2.7.5", - "14.2.7.6", - "14.2.7.7", - "14.2.8", - "14.2.8.1", - "14.2.8.2", - "14.2.8.3" + "MNT-09": [ + "12.5.5.C.01" ], - "TDA-10": [ - "14.3", - "14.3.1", - "14.3.1.1", - "14.3.1.2", - "14.3.1.3", - "14.3.1.4", - "14.3.1.5", - "14.3.1.6" + "MDM-01": [ + "21.1.10.C.01", + "21.1.10.C.02", + "21.1.11.C.01", + "21.1.12.C.01", + "22.1.10.C.01", + "22.1.10.C.03", + "22.1.12.C.01", + "22.1.15.C.01", + "22.1.18.C.02" ], - "TDA-18": [ - "14.2.5.9" + "MDM-03": [ + "21.1.13.C.01", + "22.1.14.C.01", + "22.1.14.C.02" ], - "TDA-20": [ - "9.4.5", - "9.4.5.1", - "9.4.5.2", - "9.4.5.3", - "9.4.5.4", - "9.4.5.5", - "9.4.5.6", - "9.4.5.7", - "9.4.5.8", - "9.4.5.9", - "14.2.1.5" + "MDM-06": [ + "21.1.12.C.01" ], - "TDA-20.1": [ - "14.2.1.6" + "NET-01": [ + "10.8.34.C.01", + "10.8.34.C.02", + "10.8.35.C.01", + "10.8.36.C.01", + "10.8.37.C.01", + "10.8.38.C.01", + "18.1.9.C.01", + "18.1.9.C.02", + "18.1.9.C.03", + "18.1.9.C.04", + "18.1.9.C.05", + "18.5.7.C.01", + "18.5.7.C.02", + "18.5.8.C.01", + "18.5.8.C.02", + "18.5.8.C.03", + "18.5.8.C.04", + "18.5.9.C.01", + "18.5.9.C.02", + "18.5.9.C.03", + "18.5.10.C.01", + "18.5.10.C.02", + "18.5.11.C.01" ], - "TDA-20.3": [ - "14.2.7.8" + "NET-01.1": [ + "2.3.26.C.01", + "2.3.26.C.02", + "16.1.25.C.01", + "16.5.12.C.02" ], - "TPM-01": [ - "4.5.3.1", - "5.1.1.20", - "5.1.1.31.P", - "15", - "15.1", - "15.1.1", - "15.1.1.1", - "15.1.1.2", - "15.1.1.3", - "15.1.1.4", - "15.1.1.5", - "15.1.1.6", - "15.1.1.7", - "15.1.1.8", - "15.1.1.9", - "15.1.1.10", - "15.1.1.11", - "15.1.1.12", - "15.1.1.13", - "15.1.1.14.B" + "NET-02.1": [ + "18.3.18.C.01", + "18.3.19.C.01" ], - "TPM-04.1": [ - "14.1.1.14", - "15.1.1.16.B" + "NET-02.2": [ + "18.2.6.C.01" ], - "TPM-05": [ - "6.3.P", - "7.1.1.11", - "8.2.3.7", - "13.1.2", - "13.1.2.2", - "14.1.1.13", - "14.2.1.12", - "14.2.7.1", - "14.2.7.2", - "14.2.7.9", - "15.1.2", - "15.1.2.1", - "15.1.2.2", - "15.1.2.3", - "15.1.2.4", - "15.1.2.5", - "15.1.2.6", - "15.1.2.7", - "15.1.2.8", - "15.1.2.9", - "15.1.2.10", - "15.1.2.11", - "15.1.2.12", - "15.1.2.13", - "15.1.2.14", - "15.1.2.15", - "15.1.2.16", - "15.1.2.17", - "15.1.2.18.PB", - "15.1.3", - "15.1.3.1", - "15.1.3.2", - "15.1.3.3", - "15.1.3.4", - "15.1.3.5", - "15.1.3.6", - "15.1.3.7", - "15.1.3.8", - "15.1.3.9", - "15.1.3.10.P", - "15.1.3.11.P", - "15.2" + "NET-02.3": [ + "19.2.15.C.01", + "19.2.16.C.01", + "19.2.16.C.02", + "19.2.17.C.01", + "19.2.17.C.02", + "19.2.18.C.01", + "19.2.19.C.01", + "19.2.19.C.02", + "19.2.20.C.01", + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.14.C.04", + "20.3.9.C.02", + "20.3.9.C.04", + "21.1.8.C.01" ], - "TPM-05.4": [ - "6.1.1.8", - "6.1.1.9", - "6.1.1.10", - "6.1.1.11", - "6.1.1.12", - "6.1.5.6", - "6.3.1.P" + "NET-03": [ + "19.1.10.C.01", + "19.1.11.C.01", + "19.1.11.C.02", + "19.1.12.C.01", + "19.1.13.C.01", + "19.1.14.C.01", + "19.1.14.C.02", + "19.1.15.C.01", + "19.1.16.C.01", + "19.1.16.C.02", + "19.1.17.C.01", + "19.1.17.C.02", + "19.1.18.C.01", + "19.1.18.C.02", + "19.1.19.C.01", + "19.1.19.C.02", + "19.1.19.C.03", + "19.1.19.C.04", + "19.1.19.C.05", + "19.1.20.C.01", + "19.1.20.C.02", + "19.1.20.C.03", + "19.1.21.C.01", + "19.1.22.C.01", + "19.1.22.C.02", + "19.1.22.C.03", + "19.1.23.C.01", + "19.3.8.C.01", + "19.3.8.C.02", + "19.3.8.C.03", + "19.3.8.C.04", + "19.3.9.C.01", + "19.3.9.C.02", + "19.3.9.C.03", + "19.4.4.C.01", + "19.4.5.C.01", + "19.4.5.C.02", + "19.4.5.C.03", + "19.4.6.C.01", + "19.5.24.C.01", + "19.5.24.C.02", + "19.5.24.C.03", + "19.5.24.C.04", + "19.5.24.C.05", + "19.5.24.C.06", + "19.5.24.C.07", + "19.5.24.C.08", + "19.5.25.C.01", + "19.5.26.C.01", + "19.5.26.C.02", + "19.5.26.C.03", + "19.5.26.C.04", + "19.5.26.C.05", + "19.5.26.C.06", + "19.5.26.C.07", + "19.5.26.C.08", + "19.5.26.C.09", + "19.5.26.C.10", + "19.5.26.C.11", + "19.5.26.C.12", + "19.5.27.C.01", + "19.5.27.C.02", + "19.5.27.C.03", + "19.5.27.C.04", + "19.5.27.C.05", + "19.5.27.C.06", + "19.5.28.C.01", + "19.5.28.C.02", + "19.5.28.C.03", + "19.5.28.C.04", + "19.5.28.C.05", + "19.5.28.C.06", + "19.5.28.C.07", + "19.5.29.C.01", + "21.3.5.C.01", + "21.3.5.C.02", + "21.3.6.C.01" ], - "TPM-08": [ - "13.1.2.1", - "15.2.1", - "15.2.1.1", - "15.2.1.2", - "15.2.1.3", - "15.2.1.4", - "15.2.1.5", - "15.2.1.6", - "15.2.1.7", - "15.2.1.8", - "15.2.1.9", - "15.2.1.10", - "15.2.1.11", - "15.2.1.12", - "15.2.1.13" + "NET-03.8": [ + "14.1.11.C.01" ], - "TPM-10": [ - "15.2.1.14", - "15.2.1.15", - "15.2.2", - "15.2.2.1", - "15.2.2.2", - "15.2.2.3" + "NET-04": [ + "18.1.13.C.01", + "18.1.13.C.02", + "18.1.14.C.01" ], - "THR-01": [ - "5.1.1.4" + "NET-04.1": [ + "18.1.13.C.01", + "18.1.13.C.02", + "18.1.14.C.01" ], - "THR-03": [ - "4.9", - "4.9.2.2", - "6.1.4.3", - "12.2.1.12", - "12.2.1.13" + "NET-05.1": [ + "14.1.13.C.01", + "14.1.13.C.02", + "14.1.13.C.03" ], - "THR-03.1": [ - "4.9", - "4.9.1.1", - "4.9.2.1", - "4.9.2.2" + "NET-06.2": [ + "20.3.9.C.02", + "20.3.9.C.03", + "20.3.9.C.04" ], - "VPM-01": [ - "5.1.1.16", - "12.6", - "12.6.1", - "12.6.1.1", - "12.6.1.2", - "12.6.1.3", - "12.6.1.4", - "12.6.1.5", - "12.6.1.6", - "12.6.1.7", - "12.6.1.8", - "12.6.1.9", - "12.6.1.11", - "12.6.1.12", - "12.6.1.13", - "12.6.1.15", - "12.6.1.16", - "12.6.1.17", - "12.6.1.18.PB" + "NET-08.1": [ + "19.1.14.C.01", + "19.1.14.C.02" ], - "VPM-02": [ - "12.6.1.14" + "NET-13": [ + "15.1.7.C.01", + "15.1.8.C.01", + "15.1.8.C.02", + "15.1.9.C.01", + "15.1.10.C.01", + "15.1.10.C.02", + "15.1.10.C.03", + "15.1.11.C.01", + "15.1.11.C.02", + "15.1.11.C.03", + "15.1.12.C.01", + "15.1.13.C.01", + "15.1.14.C.01", + "15.1.15.C.01", + "15.1.16.C.01", + "15.1.17.C.01", + "15.1.18.C.01", + "15.1.19.C.01", + "15.1.19.C.02", + "15.1.20.C.01", + "17.6.6.C.01", + "17.6.7.C.01" ], - "VPM-05": [ - "12.6.1.10" - ] - }, - "apac-mys-pdpa-2010": { - "GOV-01": [ - "9" + "NET-14": [ + "16.5.10.C.01", + "16.5.10.C.02", + "16.5.11.C.01", + "16.5.11.C.02", + "16.5.12.C.01", + "17.5.6.C.01", + "17.5.7.C.01", + "17.5.7.C.02", + "17.5.8.C.01", + "17.5.8.C.02", + "17.5.8.C.03", + "17.5.9.C.01", + "17.5.10.C.01" ], - "CPL-01": [ - "9" + "NET-14.4": [ + "16.5.11.C.01", + "16.5.11.C.02" ], - "CPL-02": [ - "9" + "NET-14.5": [ + "21.2.4.C.01", + "21.2.5.C.01", + "21.2.6.C.01", + "21.2.7.C.01", + "22.2.4.C.01", + "22.2.4.C.02" ], - "CPL-03": [ - "9" + "NET-15": [ + "18.2.5.C.01", + "18.2.5.C.02", + "18.2.6.C.01", + "18.2.7.C.01", + "18.2.8.C.01", + "18.2.25.C.01", + "18.2.26.C.01", + "18.2.27.C.01", + "18.2.28.C.01", + "18.2.28.C.02", + "18.2.29.C.01", + "18.2.29.C.02", + "18.2.29.C.03", + "18.2.30.C.01", + "18.2.31.C.01", + "18.2.32.C.01", + "18.2.34.C.01" ], - "DCH-01": [ - "9" + "NET-15.1": [ + "18.2.10.C.01", + "18.2.10.C.02", + "18.2.11.C.01", + "18.2.11.C.02", + "18.2.11.C.03", + "18.2.11.C.04", + "18.2.11.C.05", + "18.2.12.C.01", + "18.2.12.C.02", + "18.2.13.C.01", + "18.2.14.C.01", + "18.2.15.C.01", + "18.2.16.C.01", + "18.2.17.C.01", + "18.2.18.C.01", + "18.2.19.C.01", + "18.2.19.C.02", + "18.2.19.C.03", + "18.2.20.C.01", + "18.2.20.C.02", + "18.2.20.C.03", + "18.2.21.C.01", + "18.2.22.C.01", + "18.2.23.C.01", + "18.2.23.C.02", + "18.2.24.C.01", + "18.2.25.C.01" ], - "DCH-22.1": [ - "34" + "NET-15.4": [ + "18.2.33.C.01" ], - "DCH-24": [ - "9" + "NET-15.5": [ + "22.4.12.C.02", + "22.4.12.C.03" ], - "DCH-24.1": [ - "9" + "NET-17": [ + "15.2.39.C.01", + "15.2.40.C.01" ], - "DCH-25": [ - "9" + "NET-18": [ + "9.3.6.C.01", + "14.3.6.C.01", + "14.3.6.C.02", + "14.3.6.C.03", + "14.3.10.C.01", + "14.3.10.C.02", + "14.3.10.C.03", + "14.3.10.C.04", + "14.3.11.C.01", + "14.3.11.C.02", + "14.3.12.C.01", + "20.3.9.C.01", + "20.3.10.C.01", + "20.3.11.C.01", + "20.3.11.C.02", + "21.3.7.C.01", + "21.3.7.C.02", + "21.3.14.C.01" ], - "IRO-14": [ - "9" + "NET-18.1": [ + "14.3.6.C.01", + "14.3.6.C.02", + "14.3.6.C.03", + "15.2.46.C.02" ], - "PRI-01": [ - "23" + "NET-18.2": [ + "14.3.8.C.01", + "14.3.9.C.01" ], - "PRI-02": [ - "7" + "NET-20.4": [ + "15.2.36.C.01", + "15.2.36.C.02", + "15.2.36.C.03", + "15.2.36.C.04", + "15.2.36.C.05" ], - "PRI-03": [ - "7" + "PES-01": [ + "5.7.4.C.01", + "8.1.10.C.01", + "20.2.16.C.01" ], - "PRI-05": [ - "5", - "6", - "10" + "PES-01.1": [ + "8.2.7.C.01" ], - "PRI-05.2": [ - "11" + "PES-02": [ + "8.1.11.C.01", + "8.1.11.C.02" ], - "PRI-05.4": [ - "34" + "PES-02.2": [ + "8.2.8.C.01" ], - "PRI-06": [ - "12", - "30" + "PES-03.2": [ + "8.2.5.C.01" ], - "PRI-06.1": [ - "34" + "PES-03.4": [ + "8.3.3.C.01", + "8.3.4.C.01", + "8.3.4.C.02", + "8.3.5.C.01" ], - "PRI-07": [ - "9" + "PES-04": [ + "8.2.6.C.01", + "8.2.6.C.02" ], - "PRI-15": [ - "14", - "15" + "PES-04.1": [ + "17.9.36.C.02" ], - "SEA-01": [ - "9" + "PES-04.2": [ + "8.1.12.C.01", + "8.1.13.C.01", + "8.1.13.C.02" ], - "SEA-02": [ - "9" + "PES-06": [ + "9.4.4.C.01", + "9.4.5.C.01", + "9.4.5.C.02", + "9.4.6.C.01", + "9.4.6.C.02", + "9.4.7.C.01", + "9.4.8.C.01", + "9.4.9.C.01", + "9.4.10.C.01" ], - "SEA-03": [ - "9" + "PES-06.3": [ + "9.4.7.C.01" ], - "SEA-15": [ - "9" + "PES-06.4": [ + "9.4.9.C.01" ], - "TPM-04.4": [ - "9" - ] - }, - "apac-nzl-hisf-mlhsp-2023": { - "GOV-01.1": [ - "HHSP12", - "HML12", - "HML21" + "PES-06.5": [ + "9.4.9.C.01" ], - "GOV-01.2": [ - "HHSP46", - "HHSP75", - "HML12", - "HML46", - "HML75" + "PES-07": [ + "8.3.3.C.01", + "8.3.4.C.01", + "8.3.4.C.02", + "8.3.5.C.01" ], - "GOV-02": [ - "HML01", - "HHSP01" + "PES-12": [ + "8.3.3.C.01", + "8.3.4.C.01", + "8.3.4.C.02", + "8.3.5.C.01" ], - "GOV-03": [ - "HHSP67", - "HML66" + "PES-12.1": [ + "8.3.3.C.01", + "8.3.3.C.02", + "8.3.4.C.01", + "8.3.4.C.02", + "8.3.5.C.01", + "10.1.42.C.01", + "10.1.42.C.02", + "10.1.43.C.01", + "10.1.43.C.02", + "10.1.43.C.03", + "10.1.43.C.04", + "10.1.44.C.01", + "10.1.45.C.01", + "10.1.45.C.02", + "10.1.46.C.01", + "10.1.46.C.02", + "10.1.46.C.03", + "10.1.46.C.04", + "10.1.47.C.01", + "10.1.47.C.02", + "10.1.48.C.01", + "10.1.48.C.02", + "10.1.48.C.03", + "10.1.49.C.01", + "10.1.50.C.01", + "10.1.50.C.02", + "10.1.50.C.03", + "10.1.50.C.04", + "10.1.51.C.01", + "10.2.6.C.01", + "10.2.6.C.02", + "10.2.7.C.01", + "10.2.8.C.01", + "10.2.9.C.01", + "10.2.10.C.01", + "10.3.5.C.01", + "10.3.6.C.01", + "10.3.6.C.02", + "10.3.7.C.01", + "10.3.8.C.01", + "10.3.9.C.01", + "10.3.10.C.01", + "10.3.11.C.01", + "10.3.12.C.01", + "10.3.13.C.01", + "10.4.4.C.01", + "10.4.4.C.02", + "10.4.5.C.01", + "10.4.5.C.02", + "10.4.6.C.01", + "10.4.6.C.02", + "10.4.6.C.03", + "10.4.7.C.01", + "10.4.7.C.02", + "10.4.8.C.01", + "10.4.9.C.01", + "10.4.9.C.02", + "10.4.9.C.03", + "10.4.9.C.04", + "10.4.10.C.01", + "10.4.11.C.01", + "10.4.12.C.01", + "10.4.13.C.01", + "10.4.13.C.02", + "10.5.4.C.01", + "10.5.5.C.01", + "10.5.6.C.01", + "10.5.6.C.02", + "10.5.7.C.01", + "10.5.8.C.01", + "10.5.8.C.02", + "10.5.9.C.01", + "10.5.9.C.02", + "10.5.10.C.01", + "10.5.10.C.02", + "10.5.11.C.01", + "10.6.22.C.01", + "10.6.22.C.02", + "10.6.23.C.01", + "10.6.23.C.02", + "10.6.23.C.03", + "10.6.23.C.04", + "10.6.24.C.01", + "10.6.24.C.02", + "10.6.25.C.01", + "10.6.26.C.01", + "10.6.27.C.01", + "10.6.28.C.01", + "10.6.28.C.02", + "10.6.29.C.01", + "10.6.30.C.01", + "10.6.31.C.01" ], - "GOV-04": [ - "HHSP21", - "HHSP27", - "HML21", - "HML27" + "PES-12.2": [ + "11.8.9.C.01" ], - "GOV-04.1": [ - "HHSP21", - "HHSP27", - "HML21", - "HML27" - ], - "GOV-04.2": [ - "HHSP21" + "PES-13": [ + "10.7.6.C.01", + "10.7.6.C.02", + "10.7.7.C.01", + "10.7.7.C.02", + "10.7.8.C.01", + "10.7.9.C.01" ], - "GOV-05": [ - "HHSP46", - "HML46" + "PRM-01": [ + "3.2.15.C.01" ], - "GOV-15": [ - "HHSP11", - "HHSP16", - "HHSP28", - "HML11", - "HML16", - "HML28" + "PRM-01.1": [ + "2.3.25.C.01", + "2.3.25.C.02", + "2.3.29.C.01" ], - "AST-01": [ - "HHSP05", - "HHSP54", - "HML05", - "HML54" + "PRM-02": [ + "3.2.15.C.01" ], - "AST-09": [ - "HHSP06", - "HHSP45", - "HML06", - "HML45" + "PRM-05": [ + "12.1.30.C.01", + "12.1.30.C.02", + "12.1.30.C.03", + "12.1.32.C.01", + "12.1.32.C.02", + "12.1.32.C.03" ], - "BCD-01": [ - "HHSP08", - "HHSP24", - "HHSP56", - "HHSP61", - "HML08", - "HML24", - "HML61" + "PRM-06": [ + "12.1.32.C.01", + "12.1.32.C.02", + "12.1.32.C.03" ], - "BCD-01.4": [ - "HHSP24", - "HML24" + "PRM-08": [ + "3.2.19.C.01" ], - "BCD-02.1": [ - "HHSP35", - "HML35" + "RSK-01": [ + "5.1.9.C.01", + "5.3.6.C.01", + "5.3.7.C.01", + "5.3.8.C.01", + "5.3.9.C.01" ], - "BCD-02.2": [ - "HHSP35", - "HML35" + "RSK-01.1": [ + "23.2.16.C.01", + "23.2.17.C.01" ], - "BCD-05": [ - "HHSP64", - "HML63" + "RSK-02.1": [ + "23.2.16.C.01", + "23.2.17.C.01" ], - "BCD-11": [ - "HHSP17", - "HHSP56", - "HHSP69", - "HML17", - "HML56", - "HML68" + "RSK-03": [ + "2.4.13.C.01", + "2.4.13.C.02", + "2.4.13.C.03", + "2.4.13.C.04", + "2.4.13.C.05", + "2.4.13.C.06", + "2.4.13.C.07" ], - "BCD-11.1": [ - "HHSP57", - "HHSP69", - "HML57", - "HML68" + "RSK-04": [ + "2.3.27.C.01", + "2.3.27.C.02", + "5.9.23.C.01", + "22.4.7.C.01", + "23.2.16.C.02" ], - "BCD-11.10": [ - "HHSP56", - "HML56" + "RSK-06.2": [ + "11.1.18.C.03", + "12.4.5.C.01" ], - "BCD-12": [ - "HHSP17", - "HML17" + "RSK-08": [ + "16.1.30.C.01" ], - "CAP-01": [ - "HHSP61", - "HML61" + "RSK-09": [ + "2.2.7.C.01", + "12.7.14.C.01", + "12.7.14.C.02", + "12.7.14.C.03", + "12.7.15.C.01", + "12.7.15.C.02", + "12.7.16.C.01", + "12.7.16.C.02", + "12.7.16.C.03", + "12.7.17.C.01", + "12.7.18.C.01", + "12.7.18.C.02", + "12.7.19.C.01", + "12.7.19.C.02", + "12.7.20.C.01", + "12.7.20.C.02", + "12.7.20.C.03", + "12.7.20.C.04", + "12.7.20.C.05", + "12.7.21.C.01" ], - "CHG-01": [ - "HHSP18", - "HML18" + "SEA-01": [ + "2.3.28.C.01", + "20.2.14.C.01", + "20.2.14.C.03" ], - "CHG-02": [ - "HHSP18", - "HML18" + "SEA-01.1": [ + "4.3.19.C.01" ], - "CHG-03": [ - "HHSP33", - "HML33" + "SEA-01.4": [ + "1.2.15.C.01", + "2.3.28.C.01" ], - "CLD-02": [ - "HHSP51", - "HML51" + "SEA-01.5": [ + "2.3.28.C.01" ], - "CLD-04": [ - "HHSP52", - "HML52" + "SEA-13.1": [ + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.12.C.03", + "20.2.12.C.04", + "20.2.14.C.01", + "20.2.14.C.03", + "20.2.14.C.04", + "20.2.14.C.07" ], - "CLD-06": [ - "HHSP53", - "HML53" + "SEA-18": [ + "16.1.44.C.02", + "16.1.44.C.03" ], - "CPL-01": [ - "HHSP29", - "HML29" + "OPS-01.1": [ + "3.4.12.C.01", + "3.4.12.C.02", + "5.1.11.C.01", + "5.1.13.C.01", + "5.5.3.C.01", + "5.5.4.C.01", + "5.5.5.C.01", + "5.5.6.C.01", + "16.1.24.C.01", + "20.2.15.C.01", + "21.1.7.C.01", + "21.1.7.C.02" ], - "CPL-02": [ - "HHSP67", - "HML66" + "OPS-02": [ + "5.1.15.C.01" ], - "CPL-02.1": [ - "HHSP67", - "HML66" + "SAT-01": [ + "9.1.4.C.01" ], - "CFG-02": [ - "HHSP54", - "HHSP60", - "HHSP65", - "HML16", - "HML54", - "HML60", - "HML64" + "SAT-02": [ + "9.1.5.C.01", + "9.1.5.C.02", + "9.1.6.C.01", + "9.1.6.C.02", + "16.4.43.C.01", + "20.1.27.C.01" ], - "MON-01": [ - "HHSP70", - "HML70" + "SAT-03": [ + "2.1.47.C.01", + "9.1.6.C.01", + "9.1.6.C.02", + "9.1.6.C.03" ], - "MON-01.4": [ - "HHSP69", - "HML68" + "SAT-03.3": [ + "21.1.6.C.01", + "22.1.11.C.01" ], - "MON-01.12": [ - "HHSP69", - "HML68" + "TDA-01.1": [ + "12.1.31.C.01", + "12.1.32.C.01", + "12.1.32.C.02", + "12.1.32.C.03", + "12.1.33.C.01", + "12.1.34.C.01", + "12.1.34.C.02", + "12.1.35.C.01", + "12.1.36.C.01", + "12.1.37.C.01", + "12.4.3.C.01", + "12.4.4.C.01", + "12.4.4.C.02", + "12.4.4.C.03", + "12.4.4.C.04", + "12.4.4.C.05", + "12.4.4.C.06", + "12.4.5.C.01", + "12.4.6.C.01", + "12.4.7.C.01" ], - "MON-03": [ - "HHSP70", - "HML70" + "TDA-02.1": [ + "18.1.15.C.01", + "18.1.15.C.02", + "18.1.15.C.03", + "18.1.15.C.04" ], - "MON-03.2": [ - "HHSP70", - "HML70" + "TDA-04": [ + "3.4.10.C.01", + "3.4.10.C.02" ], - "MON-07.1": [ - "HHSP71", - "HML71" + "TDA-06": [ + "14.4.5.C.01" ], - "MON-11": [ - "HHSP63", - "HML69" + "TDA-06.1": [ + "14.4.6.C.01", + "14.4.6.C.02", + "14.4.6.C.03" ], - "CRY-01": [ - "HHSP37", - "HML37" + "TDA-06.2": [ + "14.4.6.C.01", + "14.4.6.C.02", + "14.4.6.C.03" ], - "DCH-01": [ - "HHSP14", - "HHSP34", - "HHSP74", - "HML14", - "HML74" + "TDA-07": [ + "14.4.4.C.01" ], - "DCH-01.2": [ - "HHSP14", - "HHSP74", - "HML14", - "HML74" + "TDA-08": [ + "20.2.14.C.06" ], - "DCH-02": [ - "HML34" + "TDA-09.4": [ + "14.5.6.C.01" ], - "DCH-12": [ - "HHSP14", - "HML14" + "TDA-09.5": [ + "14.5.6.C.01" ], - "END-01": [ - "HHSP34" + "TDA-17": [ + "12.4.7.C.01" ], - "END-04": [ - "HHSP62", - "HML62" + "TPM-01": [ + "2.2.6.C.01", + "2.2.6.C.02", + "23.2.19.C.01" ], - "HRS-01": [ - "HML02" + "TPM-02": [ + "12.7.17.C.01" ], - "HRS-03": [ - "HHSP02", - "HHSP23", - "HML02", - "HML23" + "TPM-03": [ + "12.7.14.C.01", + "12.7.14.C.02", + "12.7.14.C.03", + "12.7.15.C.01", + "12.7.15.C.02", + "12.7.16.C.01", + "12.7.16.C.02", + "12.7.16.C.03", + "12.7.17.C.01", + "12.7.18.C.01", + "12.7.18.C.02", + "12.7.19.C.01", + "12.7.19.C.02", + "12.7.20.C.01", + "12.7.20.C.02", + "12.7.20.C.03", + "12.7.20.C.04", + "12.7.20.C.05", + "12.7.21.C.01" ], - "HRS-04": [ - "HHSP20", - "HML20" + "TPM-05": [ + "2.3.30.C.01", + "20.1.20.C.05", + "20.1.23.C.02", + "20.1.23.C.03", + "20.1.24.C.01", + "20.1.25.C.01", + "23.2.19.C.01" ], - "HRS-07": [ - "HHSP03", - "HHSP72", - "HHSP73", - "HML03", - "HML72", - "HML73" + "TPM-05.1": [ + "7.2.22.C.01", + "7.2.23.C.01" ], - "HRS-07.1": [ - "HHSP03", - "HHSP73", - "HML03", - "HML73" + "THR-06": [ + "5.9.23.C.01", + "5.9.24.C.01", + "5.9.24.C.02", + "5.9.25.C.01", + "5.9.26.C.01", + "5.9.26.C.02", + "5.9.27.C.01" ], - "IAC-01.2": [ - "HHSP39", - "HML39" + "VPM-01": [ + "6.2.4.C.01" ], - "IAC-05": [ - "HHSP49", - "HML49" + "VPM-01.1": [ + "6.2.4.C.01" ], - "IAC-07": [ - "HHSP04", - "HML04" + "VPM-02": [ + "6.2.6.C.01", + "23.2.19.C.01" ], - "IAC-07.1": [ - "HHSP04", - "HML04" + "VPM-04": [ + "6.2.6.C.01", + "23.2.19.C.01" ], - "IAC-07.2": [ - "HHSP04", - "HML04" + "VPM-05": [ + "22.1.18.C.01", + "23.2.19.C.01" ], - "IAC-08": [ - "HHSP40", - "HHSP42", - "HML40", - "HML42" + "VPM-06": [ + "6.2.5.C.01" ], - "IAC-15": [ - "HHSP38", - "HML38" + "VPM-06.8": [ + "14.1.14.C.01" ], - "IAC-16": [ - "HHSP41", - "HML41" + "VPM-08": [ + "8.1.13.C.01", + "8.1.13.C.02" ], - "IAC-20": [ - "HHSP10", - "HHSP40", - "HML10", - "HML40" + "WEB-01": [ + "14.5.6.C.01", + "14.5.7.C.01", + "14.5.8.C.01" ], - "IRO-02": [ - "HHSP07", - "HML07" + "WEB-07": [ + "14.5.7.C.01", + "14.5.8.C.01" ], - "IRO-04": [ - "HHSP07", - "HML07" + "WEB-08": [ + "14.5.7.C.01", + "14.5.8.C.01" + ] + }, + "apac-nzl-privacy-act-2020": { + "CPL-01": [ + "6.2.126(1)", + "6.2.126(2)", + "6.2.126(2)(a)", + "6.2.126(2)(b)" ], - "IRO-08": [ - "HHSP74", - "HML74" + "DCH-22.1": [ + "3.1.22.7(4)" ], "IRO-10": [ - "HHSP75", - "HML75" + "6.1.115(1)", + "6.1.115(2)", + "6.1.115(3)", + "6.1.115(3)(a)", + "6.1.115(3)(b)", + "6.1.115(4)", + "6.1.115(4)(a)", + "6.1.115(4)(b)", + "6.1.117(1)", + "6.1.117(1)(a)", + "6.1.117(1)(a)(i)", + "6.1.117(1)(a)(ii)", + "6.1.117(1)(b)", + "6.1.117(1)(c)", + "6.1.117(1)(d)", + "6.1.117(1)(e)", + "6.1.117(1)(f)", + "6.1.117(2)", + "6.1.117(2)(a)", + "6.1.117(2)(b)", + "6.1.117(2)(c)", + "6.1.117(2)(d)", + "6.1.117(2)(e)", + "6.1.117(2)(f)", + "6.1.117(3)", + "6.1.117(4)", + "6.1.117(5)" ], - "IAO-01": [ - "HHSP68", - "HML67" + "PRI-01.5": [ + "3.1.22.12(1)", + "3.1.22.12(1)(a)", + "3.1.22.12(1)(b)", + "3.1.22.12(1)(c)", + "3.1.22.12(1)(d)", + "3.1.22.12(1)(e)", + "3.1.22.12(1)(f)", + "3.1.22.12(2)", + "3.1.22.12(3)" ], - "IAO-02": [ - "HHSP68", - "HML67" + "PRI-01.6": [ + "3.1.22.5(a)", + "3.1.22.5(a)(i)", + "3.1.22.5(a)(ii)", + "3.1.22.5(a)(iii)" ], - "MNT-01": [ - "HHSP15", - "HML15" + "PRI-01.11": [ + "3.1.22.4", + "3.1.22.4(a)", + "3.1.22.4(b)", + "3.1.22.4(b)(i)", + "3.1.22.4(b)(ii)", + "3.1.22.5", + "3.1.22.5(b)", + "4.1.47(1)", + "4.1.47(1)(a)", + "4.1.47(1)(b)" ], - "NET-01": [ - "HHSP49", - "HHSP54", - "HML49", - "HML54" + "PRI-02": [ + "3.1.22.3(1)", + "3.1.22.3(1)(a)", + "3.1.22.3(1)(b)", + "3.1.22.3(1)(c)", + "3.1.22.3(1)(d)", + "3.1.22.3(1)(d)(i)", + "3.1.22.3(1)(d)(ii)", + "3.1.22.3(1)(e)", + "3.1.22.3(1)(e)(i)", + "3.1.22.3(1)(e)(ii)", + "3.1.22.3(1)(f)", + "3.1.22.3(1)(g)", + "4.1.45(1)", + "4.1.45(1)(a)", + "4.1.45(1)(b)", + "4.1.45(1)(c)", + "4.1.45(2)" ], - "NET-03.7": [ - "HHSP43", - "HHSP55", - "HML43", - "HML55" + "PRI-04.2": [ + "3.1.22.2(1)" ], - "NET-06": [ - "HHSP55", - "HML55" + "PRI-05": [ + "3.1.22.9" ], - "NET-17": [ - "HHSP63", - "HML69" + "PRI-05.2": [ + "3.1.22.8" ], - "PES-01": [ - "HHSP47", - "HML47" + "PRI-05.4": [ + "3.1.22.1(1)", + "3.1.22.1(1)(a)", + "3.1.22.1(1)(b)", + "3.1.22.10(1)", + "3.1.22.10(1)(a)", + "3.1.22.10(1)(b)", + "3.1.22.10(1)(b)(i)", + "3.1.22.10(1)(b)(ii)", + "3.1.22.10(1)(c)", + "3.1.22.10(1)(d)", + "3.1.22.10(1)(e)", + "3.1.22.10(1)(e)(i)", + "3.1.22.10(1)(e)(ii)", + "3.1.22.10(1)(e)(iii)", + "3.1.22.10(1)(e)(iv)", + "3.1.22.10(1)(f)", + "3.1.22.10(1)(f)(i)", + "3.1.22.10(1)(f)(ii)" ], - "PES-01.1": [ - "HHSP13", - "HML13" + "PRI-06": [ + "3.1.22.6(1)", + "3.1.22.6(1)(a)", + "3.1.22.6(1)(b)", + "3.1.22.6(2)", + "3.1.22.7(1)", + "3.1.22.7(3)", + "3.1.22.7(3)(a)", + "4.2.59" ], - "PES-02": [ - "HHSP04", - "HML04" + "PRI-06.2": [ + "3.1.22.7(3)(b)" ], - "PES-03": [ - "HHSP48", - "HML48" + "PRI-06.4": [ + "3.1.22.7(2)", + "4.1.44(1)", + "4.1.44(2)", + "4.1.44(2)(b)", + "4.1.44(2)(c)", + "4.1.44(2)(c)(i)", + "4.1.44(2)(c)(ii)", + "4.1.44(2)(d)", + "4.2.63(1)", + "4.2.63(1)(a)", + "4.2.63(1)(b)", + "4.2.63(1)(b)(i)", + "4.2.63(1)(b)(ii)", + "4.2.63(2)", + "4.2.63(3)", + "4.2.63(3)(a)", + "4.2.63(3)(b)", + "4.2.63(3)(c)", + "4.2.64(1)", + "4.2.64(1)(a)", + "4.2.64(1)(b)", + "4.2.64(1)(b)(i)", + "4.2.64(1)(b)(ii)", + "4.2.64(2)", + "4.2.64(3)" ], - "PES-03.4": [ - "HHSP10", - "HML10" + "PRI-06.7": [ + "4.1.58(1)", + "4.1.58(1)(a)", + "4.1.58(1)(b)", + "4.1.58(1)(c)", + "4.1.58(1)(d)", + "4.1.58(1)(e)", + "4.1.58(1)(f)" ], - "PES-04": [ - "HHSP48", - "HML48" + "PRI-07": [ + "3.1.22.11(1)", + "3.1.22.11(1)(a)", + "3.1.22.11(1)(b)", + "3.1.22.11(1)(c)", + "3.1.22.11(1)(d)", + "3.1.22.11(1)(e)", + "3.1.22.11(1)(e)(i)", + "3.1.22.11(1)(e)(ii)", + "3.1.22.11(1)(e)(iii)", + "3.1.22.11(1)(e)(iv)", + "3.1.22.11(1)(f)", + "3.1.22.11(1)(f)(i)", + "3.1.22.11(1)(f)(ii)", + "3.1.22.11(1)(g)", + "3.1.22.11(1)(h)", + "3.1.22.11(1)(h)(i)", + "3.1.22.11(1)(h)(ii)", + "3.1.22.11(1)(i)" ], - "PES-05": [ - "HHSP66", - "HML65" + "PRI-07.3": [ + "3.1.22.7(5)" ], - "PRM-04": [ - "HHSP11", - "HHSP28", - "HHSP31", - "HML11", - "HML28", - "HML31" + "PRI-07.4": [ + "4.1.46(1)" ], - "PRM-05": [ - "HHSP11", - "HHSP28", - "HHSP31", - "HML31" + "PRI-07.5": [ + "4.1.46(2)", + "4.1.46(3)" ], - "RSK-01": [ - "HHSP30", - "HML30" + "PRI-17": [ + "4.1.46(2)(a)", + "4.1.46(2)(b)", + "4.1.46(3)(a)", + "4.1.46(3)(b)" + ] + }, + "apac-phl-dpa-2012": { + "CPL-01": [ + "III.11" ], - "RSK-04": [ - "HHSP32", - "HML32" + "IRO-10.2": [ + "V.20(f)" ], - "RSK-04.1": [ - "HHSP65", - "HML64" + "PRI-01": [ + "III.11" ], - "RSK-06.2": [ - "HHSP26", - "HHSP43", - "HHSP65", - "HML26", - "HML43", - "HML64" + "PRI-01.1": [ + "VI.21", + "VI.21(a)", + "VI.21(b)" ], - "SEA-01": [ - "HHSP16", - "HML16" + "PRI-01.6": [ + "V.20(a)", + "V.20(b)", + "V.20(c)", + "V.20(c)(1)", + "V.20(c)(2)", + "V.20(c)(3)", + "V.20(c)(4)", + "V.20(d)", + "V.20(e)" ], - "SAT-01": [ - "HHSP22", - "HML22" + "PRI-01.11": [ + "III.11", + "III.11(b)", + "III.11(d)" ], - "TDA-01": [ - "HHSP50", - "HML50" + "PRI-02.1": [ + "III.12" ], - "TDA-01.1": [ - "HHSP50", - "HML50" + "PRI-03": [ + "III.12(a)" ], - "TDA-02": [ - "HHSP31", - "HML31" + "PRI-03.6": [ + "IV.17" ], - "TDA-06": [ - "HHSP50", - "HML50" + "PRI-05": [ + "III.11(e)", + "III.11(f)" ], - "TDA-08": [ - "HHSP58", - "HML58" + "PRI-05.1": [ + "IV.19" ], - "TDA-17": [ - "HHSP43", - "HML43" + "PRI-05.2": [ + "III.11(c)" ], - "TDA-20": [ - "HHSP42", - "HML42" + "PRI-05.4": [ + "III.11(a)", + "III.11(c)", + "III.12(b)", + "III.12(c)", + "III.12(d)", + "III.12(e)", + "III.12(f)", + "III.13", + "III.13(a)", + "III.13(b)", + "III.13(c)", + "III.13(d)", + "III.13(e)", + "III.13(f)" ], - "TPM-01": [ - "HHSP25", - "HML25" + "PRI-06": [ + "IV.16", + "IV.16(a)", + "IV.16(b)", + "IV.16(b)(1)", + "IV.16(b)(2)", + "IV.16(b)(3)", + "IV.16(b)(4)", + "IV.16(b)(5)", + "IV.16(b)(6)", + "IV.16(b)(7)", + "IV.16(b)(8)", + "IV.16(c)", + "IV.16(c)(1)", + "IV.16(c)(2)", + "IV.16(c)(3)", + "IV.16(c)(4)", + "IV.16(c)(5)", + "IV.16(c)(6)", + "IV.16(c)(7)", + "IV.16(c)(8)", + "IV.16(d)", + "IV.16(e)", + "IV.16(f)" ], - "TPM-04.1": [ - "HHSP25", - "HML25" + "PRI-06.6": [ + "IV.18" ], - "TPM-05": [ - "HHSP09", - "HHSP36", - "HHSP72", - "HML09", - "HML36", - "HML72" + "PRI-07.1": [ + "III.14", + "V.20(d)" + ] + }, + "apac-sgp-pdpa-2012": { + "GOV-02": [ + "3.12(a)", + "3.12(c)" ], - "TPM-07": [ - "HHSP73", - "HML73" + "CPL-01": [ + "3.11(2)" ], - "TPM-08": [ - "HHSP25", - "HHSP73", - "HML25", - "HML73" + "CPL-05": [ + "3.12(d)", + "3.12(d)(i)", + "3.12(d)(ii)" ], - "VPM-01": [ - "HHSP19", - "HHSP26", - "HML19", - "HML26" + "CPL-05.1": [ + "5.21(4)" ], - "VPM-02": [ - "HHSP19", - "HHSP59", - "HML19", - "HML59" + "DCH-02": [ + "4.1.13", + "5.21(6)(b)", + "5.22(7)" ], - "VPM-04.1": [ - "HHSP44", - "HML44" + "DCH-22.1": [ + "5.22(2)(a)" ], - "VPM-05": [ - "HHSP19", - "HML19" + "IRO-02": [ + "6A.26C(2)" ], - "VPM-06": [ - "HHSP26", - "HHSP59", - "HML26", - "HML59" - ] - }, - "apac-nzl-hisf-microsmall-2023": { - "GOV-02": [ - "HMS02" + "IRO-04": [ + "6A.26C(2)", + "6A.26C(4)" ], - "AST-01": [ - "HMS12", - "HMS14" + "IRO-10": [ + "6A.26D(1)", + "6A.26D(2)", + "6A.26D(3)", + "6A.26D(4)", + "6A.26D(5)(a)", + "6A.26D(5)(b)", + "6A.26D(6)", + "6A.26D(6)(a)", + "6A.26D(6)(b)", + "6A.26D(9)", + "6A.26E", + "6A.26E(a)", + "6A.26E(b)" ], - "AST-01.4": [ - "HMS12" + "IRO-10.2": [ + "6A.26C(3)(a)", + "6A.26C(3)(b)", + "6A.26C(4)" ], - "AST-02": [ - "HMS03" + "PRI-01.1": [ + "3.11(3)", + "3.11(4)" ], - "AST-02.7": [ - "HMS14" + "PRI-01.5": [ + "6.26(1)" ], - "BCD-01": [ - "HMS21" + "PRI-01.6": [ + "6.24", + "6.24(a)", + "6.24(b)" ], - "BCD-11": [ - "HMS11" + "PRI-01.11": [ + "3.11(1)", + "4.1.14(2)(a)", + "4.1.14(2)(b)", + "4.1.15A(4)(c)", + "4.1.15A(5)(c)", + "9.3.46(2)(a)", + "9.3.46(2)(b)", + "9.3.47(2)" ], - "BCD-11.1": [ - "HMS11" + "PRI-02": [ + "3.11(5)", + "3.11(5A)", + "4.1.14(1)(a)", + "4.1.15A(4)(b)", + "4.1.15A(4)(b)(i)", + "4.1.15A(4)(b)(ii)", + "4.1.15A(4)(b)(iii)", + "4.2.20(1)(a)", + "4.2.20(1)(b)", + "4.2.20(1)(c)", + "4.2.20(2)" ], - "BCD-11.4": [ - "HMS11" + "PRI-03": [ + "4.1.13", + "4.1.14(1)(b)", + "4.1.14(3)", + "4.1.14(4)", + "4.1.15(1)", + "4.1.15(1)(a)", + "4.1.15(1)(b)", + "4.1.15(2)", + "4.1.15(3)", + "4.1.15(6)", + "4.1.15(6)(a)(i)", + "4.1.15(6)(a)(ii)", + "4.1.15(6)(b)", + "4.1.15(6)(c)", + "4.1.15(7)", + "4.1.15(9)(a)", + "4.1.15(9)(b)", + "9.3.46(1)" ], - "CFG-02": [ - "HMS09" + "PRI-03.4": [ + "4.1.16(1)", + "9.3.47(1)" ], - "MON-01": [ - "HMS18" + "PRI-03.9": [ + "4.2.19(a)", + "9.3.47(3)" ], - "MON-01.2": [ - "HMS19" + "PRI-03.10": [ + "4.1.16(4)" ], - "MON-10": [ - "HMS18" + "PRI-03.12": [ + "9.3.46(2)" ], - "MON-16": [ - "HMS19" + "PRI-04.1": [ + "4.1.17(1)(a)" ], - "DCH-06.2": [ - "HMS03" + "PRI-05": [ + "5.22A(1)", + "5.22A(2)" ], - "DCH-12": [ - "HMS09" + "PRI-05.2": [ + "6.23", + "6.23(a)", + "6.23(b)", + "6.25", + "6.25(a)", + "6.25(b)" ], - "END-02": [ - "HMS09" + "PRI-05.4": [ + "4.1.13", + "4.1.13(a)", + "4.1.13(b)", + "4.1.15(3)(a)", + "4.1.15(3)(b)", + "4.1.15(3)(c)", + "4.1.17(1)(b)", + "4.1.17(2)(a)" ], - "END-04": [ - "HMS10" + "PRI-05.5": [ + "4.1.13" ], - "HRS-03": [ - "HMS01" + "PRI-06": [ + "4.1.16(3)", + "5.21(1)", + "5.21(1)(a)", + "5.21(1)(b)", + "5.21(2)", + "5.21(5)" ], - "IAC-08": [ - "HMS07" + "PRI-06.1": [ + "5.22(1)", + "5.22(2)(a)", + "5.22(4)" ], - "IAC-20": [ - "HMS07" + "PRI-06.4": [ + "3.12(b)", + "4.1.16(2)", + "5.21(6)", + "5.21(6)(b)", + "5.21(7)", + "5.21(7)(b)" ], - "IRO-04": [ - "HMS20" + "PRI-07": [ + "4.1.17(1)(c)", + "5.22(2)(b)", + "5.22(3)" ], - "NET-02.1": [ - "HMS17" + "PRI-18": [ + "5.22(5)", + "5.22(6)" ], - "NET-03.7": [ - "HMS16" + "RSK-06": [ + "4.1.15A(5)(b)(i)", + "4.1.15A(5)(b)(ii)", + "4.1.15A(5)(b)(iii)" ], - "NET-06.3": [ - "HMS15" + "RSK-10": [ + "4.1.15A(4)(a)", + "4.1.15A(5)(a)" ], - "NET-12": [ - "HMS17" + "SAT-02": [ + "3.12(c)" + ] + }, + "apac-sgp-cyber-hygiene-practice-2019": { + "GOV-02": [ + "4.3(a)" ], - "NET-14": [ - "HMS13" + "CFG-02": [ + "4.3(a)", + "4.3(b)" ], - "NET-14.5": [ - "HMS13" + "CFG-06": [ + "4.3(b)" ], - "RSK-07": [ - "HMS05" + "END-04": [ + "4.5" ], - "TPM-05": [ - "HMS06" + "IAC-01": [ + "4.1" ], - "TPM-08": [ - "HMS04" + "IAC-06": [ + "4.6", + "4.6(b)" ], - "VPM-04.1": [ - "HMS08" + "IAC-06.1": [ + "4.6(a)" + ], + "IAC-06.2": [ + "4.6(b)" + ], + "IAC-15": [ + "4.1" + ], + "IAC-16": [ + "4.1" + ], + "IAO-03": [ + "4.3(a)" + ], + "NET-01": [ + "4.4" + ], + "NET-03": [ + "4.4" + ], + "NET-04.1": [ + "4.4" + ], + "RSK-06.2": [ + "4.2(b)", + "4.3(c)" + ], + "VPM-02": [ + "4.2(a)" + ], + "VPM-05": [ + "4.2(a)" ] }, - "apac-nzl-hisf-suppliers-2023": { + "apac-sgp-mas-trm-2021": { + "GOV-01": [ + "3.1.4" + ], "GOV-01.1": [ - "HSUP10", - "HSUP19" + "3.1.1", + "3.1.2", + "3.1.5", + "3.1.7", + "3.1.7(a)", + "3.1.7(b)", + "3.1.7(c)", + "3.1.7(d)", + "3.1.7(e)", + "3.1.7(f)", + "3.1.7(g)" ], "GOV-01.2": [ - "HSUP10", - "HSUP38", - "HSUP65" + "3.1.3", + "3.1.8(e)" ], "GOV-02": [ - "HSUP01" + "3.1.8(c)", + "3.2.1", + "3.3.1(d)", + "5.3.1", + "6.1.3", + "6.4.4", + "11.1.1" + ], + "GOV-02.1": [ + "3.2.2", + "7.3.3" ], "GOV-03": [ - "HSUP58" + "3.2.1" ], "GOV-04": [ - "HSUP19", - "HSUP23" + "3.1.3", + "3.1.8" ], "GOV-04.1": [ - "HSUP19", - "HSUP23" + "3.1.7(c)", + "3.1.8", + "3.1.8(a)", + "3.1.8(b)", + "3.1.8(c)", + "3.1.8(d)", + "3.1.8(e)" + ], + "GOV-04.2": [ + "3.1.7(c)" ], "GOV-05": [ - "HSUP38" + "4.5.3" + ], + "GOV-14": [ + "3.1.6", + "4.1.2" ], "GOV-15": [ - "HSUP14", - "HSUP24" + "4.1.2" + ], + "GOV-18": [ + "5.8.1", + "5.8.2" ], "AST-01": [ - "HSUP05", - "HSUP46" + "3.3.1" + ], + "AST-01.1": [ + "3.3.1(a)", + "8.1.2" ], "AST-01.2": [ - "HSUP27" + "3.3.1(c)" + ], + "AST-01.4": [ + "3.3.1(a)", + "6.5.1" + ], + "AST-02": [ + "3.3.1(a)", + "3.3.2", + "11.5.1" + ], + "AST-02.4": [ + "3.2.2" + ], + "AST-02.5": [ + "11.2.4", + "11.2.5", + "11.5.4" + ], + "AST-04": [ + "8.1.2" ], "AST-09": [ - "HSUP06" + "11.1.7" + ], + "AST-16": [ + "11.3.7" ], "BCD-01": [ - "HSUP08", - "HSUP22", - "HSUP53" + "8.1.1" + ], + "BCD-01.2": [ + "8.3.4" ], "BCD-01.4": [ - "HSUP22" + "8.2.1" ], - "BCD-02.1": [ - "HSUP31" + "BCD-01.7": [ + "8.2.2", + "8.2.3" ], - "BCD-02.2": [ - "HSUP31" + "BCD-03.1": [ + "13.5.1", + "13.5.2" ], - "BCD-05": [ - "HSUP56" + "BCD-04": [ + "8.2.4", + "8.3.1", + "8.3.2", + "8.3.3", + "8.3.3(a)", + "8.3.3(b)", + "13.5.2" + ], + "BCD-04.2": [ + "8.5.2", + "8.5.2(a)", + "8.5.2(b)", + "8.5.4" ], "BCD-11": [ - "HSUP15", - "HSUP48", - "HSUP60" + "8.4.1", + "8.4.2" ], - "BCD-11.1": [ - "HSUP49", - "HSUP60" + "BCD-11.2": [ + "8.4.4" ], - "BCD-11.10": [ - "HSUP48" + "BCD-11.3": [ + "11.4.3" ], - "BCD-12": [ - "HSUP15" + "BCD-11.4": [ + "8.4.4" + ], + "BCD-11.5": [ + "8.4.3" + ], + "BCD-11.7": [ + "8.1.2", + "8.5.2(c)" + ], + "BCD-11.9": [ + "11.4.3" ], "CAP-01": [ - "HSUP53" + "6.4.8" + ], + "CAP-02": [ + "6.4.8" + ], + "CAP-04": [ + "8.1.3" + ], + "CAP-05": [ + "8.1.4" ], "CHG-01": [ - "HSUP16" + "7.5.1" ], "CHG-02": [ - "HSUP16" + "7.5.2", + "7.5.4" + ], + "CHG-02.1": [ + "7.5.2" + ], + "CHG-02.2": [ + "7.5.3", + "7.5.5", + "7.5.7" ], "CHG-03": [ - "HSUP29" + "7.5.2" ], - "CLD-02": [ - "HSUP43" + "CHG-04.3": [ + "9.1.1" + ], + "CHG-04.5": [ + "7.6.2" + ], + "CHG-07": [ + "7.5.6" ], "CLD-04": [ - "HSUP44" + "6.4.1", + "6.4.4" ], - "CLD-06": [ - "HSUP45" + "CLD-05": [ + "11.4.3" ], - "CPL-01": [ - "HSUP25" + "CPL-01.6": [ + "15.1.4" ], "CPL-02": [ - "HSUP58" + "3.2.3", + "15.1.1" ], "CPL-02.1": [ - "HSUP58" + "15.1.1", + "15.1.2" ], - "CFG-02": [ - "HSUP14", - "HSUP46", - "HSUP52" + "CPL-02.2": [ + "15.1.3" ], - "MON-01": [ - "HSUP61" + "CPL-03": [ + "4.5.1", + "9.1.6", + "11.2.8" ], - "MON-01.4": [ - "HSUP60" + "CPL-03.2": [ + "4.5.1", + "11.2.8" ], - "MON-01.12": [ - "HSUP60" + "CFG-01": [ + "7.2.1" ], - "MON-03": [ - "HSUP61" + "CFG-02": [ + "6.4.4", + "7.2.2", + "11.1.5", + "11.3.1" ], - "MON-03.2": [ - "HSUP61" + "CFG-02.2": [ + "7.2.2", + "11.3.2" ], - "MON-07.1": [ - "HSUP62" + "CFG-02.7": [ + "11.3.2" ], - "MON-11": [ - "HSUP55" + "CFG-03": [ + "11.2.6" ], - "CRY-01": [ - "HSUP32" + "CFG-03.3": [ + "11.3.6" ], - "DCH-01": [ - "HSUP12", - "HSUP30", - "HSUP66" + "CFG-04": [ + "6.1.3" ], - "DCH-01.2": [ - "HSUP12", - "HSUP66" + "CFG-04.1": [ + "6.1.3" ], - "DCH-02": [ - "HSUP30" + "MON-01": [ + "6.4.7", + "12.2.1" ], - "DCH-12": [ - "HSUP12" + "MON-01.2": [ + "6.4.7", + "7.7.4", + "12.2.2" ], - "END-01": [ - "HSUP30" + "MON-01.8": [ + "12.2.6" ], - "END-04": [ - "HSUP54" + "MON-01.15": [ + "7.6.2" ], - "HRS-01": [ - "HSUP02" + "MON-02.1": [ + "12.2.5" + ], + "MON-08": [ + "12.2.2" + ], + "MON-11.3": [ + "11.3.5" + ], + "MON-16": [ + "11.5.5", + "12.2.3", + "12.2.4" + ], + "CRY-01": [ + "6.4.5", + "10.1.1", + "10.1.3", + "10.1.4" + ], + "CRY-01.5": [ + "10.1.2", + "10.1.5" + ], + "CRY-05": [ + "11.1.3" + ], + "CRY-09": [ + "6.4.5", + "10.2.1", + "10.2.2", + "10.2.3", + "10.2.4", + "10.2.5", + "10.2.6", + "10.2.8", + "10.2.10" + ], + "CRY-09.3": [ + "10.2.7", + "10.2.9" + ], + "DCH-01": [ + "11.1.1", + "11.1.2" + ], + "DCH-01.2": [ + "11.1.1(a)", + "11.1.1(b)", + "11.1.1(c)", + "11.1.6" + ], + "DCH-01.4": [ + "11.1.6" + ], + "DCH-02": [ + "3.3.1(b)" + ], + "DCH-09": [ + "11.1.7" + ], + "DCH-13.2": [ + "11.1.4" + ], + "EMB-01": [ + "11.5.1", + "11.5.2", + "11.5.3" + ], + "END-02": [ + "11.1.3", + "11.1.4", + "11.1.5" + ], + "END-04": [ + "11.3.3" + ], + "END-04.1": [ + "11.3.4" + ], + "END-15": [ + "11.4.2" + ], + "HRS-01": [ + "3.5.1" + ], + "HRS-02": [ + "3.5.1" ], "HRS-03": [ - "HSUP02", - "HSUP21" + "3.5.1" ], - "HRS-04": [ - "HSUP18" + "HRS-03.2": [ + "3.5.1", + "6.1.5" ], - "HRS-05.1": [ - "HSUP01" + "HRS-04": [ + "3.5.2" ], - "HRS-07": [ - "HSUP03", - "HSUP63", - "HSUP64" + "HRS-04.1": [ + "3.5.2" ], - "HRS-07.1": [ - "HSUP03", - "HSUP64" + "HRS-05.3": [ + "11.1.5" ], - "IAC-01.2": [ - "HSUP34" + "HRS-11": [ + "6.3.2", + "7.6.1", + "9.1.1" ], - "IAC-05": [ - "HSUP41" + "IAC-01": [ + "9.1.8", + "9.2.2" ], - "IAC-07": [ - "HSUP04", - "HSUP35" + "IAC-01.1": [ + "9.1.3" ], - "IAC-07.1": [ - "HSUP04" + "IAC-06": [ + "9.1.5" ], - "IAC-07.2": [ - "HSUP04" + "IAC-07": [ + "9.1.2" ], "IAC-08": [ - "HSUP04", - "HSUP37" + "9.1.7" + ], + "IAC-10.1": [ + "9.1.4" ], "IAC-15": [ - "HSUP33", - "HSUP35" + "9.1.8" + ], + "IAC-15.1": [ + "9.2.2" ], "IAC-16": [ - "HSUP36" + "9.2.1" ], - "IAC-20": [ - "HSUP09" + "IAC-21": [ + "9.1.7" + ], + "IRO-01": [ + "7.7.1", + "7.7.2" ], "IRO-02": [ - "HSUP07" + "7.7.2", + "7.7.3", + "7.7.3(a)", + "7.7.3(b)", + "7.7.3(c)" + ], + "IRO-03": [ + "11.3.5" ], "IRO-04": [ - "HSUP07" + "12.3.1" ], - "IRO-08": [ - "HSUP66" + "IRO-04.3": [ + "7.8.3", + "12.3.3" + ], + "IRO-06": [ + "13.3.1", + "13.3.2", + "13.5.2" + ], + "IRO-07": [ + "7.7.5", + "7.7.6" ], "IRO-10": [ - "HSUP65" + "7.7.5", + "7.7.7" + ], + "IRO-13": [ + "7.8.1", + "7.8.2", + "12.3.2" ], "IAO-01": [ - "HSUP59" + "4.5.1", + "5.6.2", + "5.7.1", + "6.1.6", + "6.1.7", + "6.4.6", + "6.5.3" + ], + "IAO-01.1": [ + "4.5.1", + "5.6.2", + "6.1.6", + "6.4.6" ], "IAO-02": [ - "HSUP59" + "4.5.1", + "5.6.2", + "6.1.6" ], - "MNT-01": [ - "HSUP13" + "IAO-02.2": [ + "5.3.3", + "5.6.3", + "6.1.6", + "6.4.6" + ], + "IAO-04": [ + "5.7.5" + ], + "IAO-06": [ + "5.7.6" + ], + "IAO-07": [ + "5.7.6" ], "NET-01": [ - "HSUP41", - "HSUP46" + "11.2.1" ], - "NET-03.7": [ - "HSUP47" + "NET-03": [ + "11.2.1" + ], + "NET-03.6": [ + "11.5.5" ], "NET-06": [ - "HSUP47" + "11.2.2" + ], + "NET-08": [ + "11.2.3" + ], + "NET-14": [ + "9.3.1", + "9.3.2" ], "NET-17": [ - "HSUP55" + "11.1.1" ], - "PES-01": [ - "HSUP11", - "HSUP39" + "NET-18": [ + "11.2.7" ], - "PES-01.1": [ - "HSUP11" + "PES-01": [ + "8.5.5", + "8.5.6" ], "PES-02": [ - "HSUP04" - ], - "PES-02.1": [ - "HSUP04" + "8.5.6(a)" ], "PES-03": [ - "HSUP40" + "8.5.6(e)" + ], + "PES-03.1": [ + "8.5.6(c)" ], "PES-03.4": [ - "HSUP09" + "8.5.6(d)" ], - "PES-04": [ - "HSUP40" + "PES-06": [ + "8.5.6(b)" ], - "PES-05": [ - "HSUP57" + "PES-08": [ + "8.5.3" + ], + "PES-08.1": [ + "8.5.3" + ], + "PES-08.2": [ + "8.5.3" + ], + "PES-10": [ + "8.5.6(f)" + ], + "PRI-02": [ + "14.4.1" + ], + "PRM-01": [ + "5.2.1", + "5.2.2" + ], + "PRM-02": [ + "5.1.4" + ], + "PRM-03": [ + "5.1.4" ], "PRM-04": [ - "HSUP24" + "5.1.1", + "5.1.3" ], "PRM-05": [ - "HSUP27" + "5.1.2", + "5.4.2", + "5.4.3", + "5.5.1" ], "PRM-06": [ - "HSUP27" + "5.1.2", + "5.5.1" + ], + "PRM-07": [ + "5.1.2", + "5.4.1", + "5.4.4", + "5.5.2", + "5.8.1" ], "RSK-01": [ - "HSUP26" + "3.1.4", + "3.1.7(a)", + "4.1.1", + "4.1.4", + "4.1.4(d)", + "4.1.5" + ], + "RSK-01.1": [ + "4.2.1" + ], + "RSK-01.3": [ + "3.1.7(d)", + "4.4.2" + ], + "RSK-01.4": [ + "4.4.2" + ], + "RSK-01.5": [ + "3.1.5", + "3.1.7(d)" + ], + "RSK-03": [ + "4.1.4(a)", + "4.2.1" + ], + "RSK-03.1": [ + "4.2.1" + ], + "RSK-03.2": [ + "4.1.3" ], "RSK-04": [ - "HSUP28" + "4.1.4(b)", + "4.3.1", + "8.5.1" + ], + "RSK-04.1": [ + "4.5.2" + ], + "RSK-04.2": [ + "4.1.4(d)" + ], + "RSK-04.3": [ + "4.1.4(d)" + ], + "RSK-06": [ + "4.1.4(c)", + "4.4.1" + ], + "RSK-06.2": [ + "4.4.1" + ], + "RSK-06.3": [ + "4.1.3", + "4.1.4(c)", + "4.4.2", + "4.4.3" ], "SEA-01": [ - "HSUP14" + "14.1.1", + "14.2.10" ], - "OPS-01.1": [ - "HSUP01" + "SEA-07.1": [ + "7.3.2" + ], + "SEA-13.1": [ + "11.4.1" + ], + "OPS-03": [ + "7.1.1" + ], + "OPS-07": [ + "6.5.1", + "6.5.2" ], "SAT-01": [ - "HSUP20" + "3.1.6" + ], + "SAT-01.1": [ + "3.6.4" + ], + "SAT-02": [ + "3.6.1" + ], + "SAT-03": [ + "3.6.1", + "3.6.2", + "3.6.3" + ], + "SAT-03.3": [ + "3.6.1" + ], + "SAT-03.6": [ + "12.1.3" + ], + "SAT-03.8": [ + "6.1.5" ], "TDA-01": [ - "HSUP42" + "5.3.2" ], "TDA-01.1": [ - "HSUP42" + "5.5.2", + "14.1.5", + "14.1.7" + ], + "TDA-01.4": [ + "6.3.1" + ], + "TDA-02": [ + "5.4.3", + "5.5.2" + ], + "TDA-02.10": [ + "5.6.1", + "5.7.2" ], "TDA-06": [ - "HSUP42" + "6.1.1", + "6.1.2", + "6.2.1", + "6.2.2" + ], + "TDA-07": [ + "5.7.3" ], "TDA-08": [ - "HSUP50" + "5.7.3" + ], + "TDA-09": [ + "5.7.4", + "5.7.5", + "6.1.6", + "6.1.7" + ], + "TDA-09.2": [ + "6.1.6" + ], + "TDA-09.3": [ + "6.1.6" + ], + "TDA-09.4": [ + "6.1.6" + ], + "TDA-17": [ + "7.3.1", + "7.3.3" ], "TDA-20": [ - "HSUP37" + "7.6.2" + ], + "TDA-20.3": [ + "5.3.4" ], "TPM-01": [ - "HSUP67" + "3.4.1", + "8.3.4" + ], + "TPM-02": [ + "5.3.1" ], "TPM-04.1": [ - "HSUP67" + "3.4.2", + "5.3.1", + "5.3.2", + "6.4.2", + "6.4.3" ], "TPM-05": [ - "HSUP63", - "HSUP68" + "3.4.2" ], - "TPM-07": [ - "HSUP64" + "TPM-05.4": [ + "3.4.2" + ], + "TPM-05.5": [ + "3.4.3" ], "TPM-08": [ - "HSUP64", - "HSUP67" + "3.4.3" + ], + "TPM-09": [ + "3.4.3" + ], + "THR-01": [ + "14.1.6" + ], + "THR-01.1": [ + "14.1.6" + ], + "THR-03": [ + "4.2.1", + "12.1.1", + "12.1.2" + ], + "THR-03.1": [ + "12.1.3" + ], + "THR-06": [ + "13.2.2" + ], + "THR-09": [ + "4.2.1" + ], + "THR-10": [ + "4.3.2", + "8.5.1" + ], + "THR-11": [ + "12.2.3" ], "VPM-01": [ - "HSUP17" + "6.1.4" + ], + "VPM-01.1": [ + "6.1.4", + "13.1.2" ], "VPM-02": [ - "HSUP17", - "HSUP51" + "6.1.4", + "13.6.1", + "13.6.1(a)", + "13.6.1(b)", + "13.6.1(c)" ], "VPM-05": [ - "HSUP17" + "7.4.1" + ], + "VPM-05.6": [ + "7.4.2" ], "VPM-06": [ - "HSUP51" + "13.1.1" + ], + "VPM-07": [ + "13.2.1", + "13.2.3", + "13.2.4" + ], + "VPM-10": [ + "8.5.1", + "13.4.1", + "13.4.2" + ], + "WEB-01": [ + "14.1.1" + ], + "WEB-04": [ + "14.1.1", + "14.1.2", + "14.1.3", + "14.1.4", + "14.2.1", + "14.2.3", + "14.2.4", + "14.2.11" + ], + "WEB-06": [ + "14.2.1", + "14.2.5", + "14.2.6", + "14.2.7", + "14.2.8", + "14.2.9" + ], + "WEB-10": [ + "14.2.2" ] }, - "apac-nzl-ism-3-9": { - "GOV-01": [ - "5.1.14.C.01" + "apac-kor-pipa-2011": { + "DCH-18.1": [ + "III.1.16(1)" ], - "GOV-01.1": [ - "3.2.9.C.01" + "HRS-01": [ + "III.2.28(1)" ], - "GOV-02": [ - "5.1.7.C.01", - "5.1.14.C.01", - "5.1.16.C.01", - "5.1.16.C.02", - "5.1.17.C.01", - "5.1.18.C.01", - "5.1.19.C.01", - "5.1.20.C.01", - "5.1.20.C.02", - "5.2.3.C.01", - "5.2.3.C.02" + "IRO-04.1": [ + "IV.34(2)" ], - "GOV-03": [ - "5.1.14.C.01", - "5.1.21.C.01", - "5.1.21.C.02" + "IRO-10": [ + "IV.34(1)", + "IV.34(1)1", + "IV.34(1)2", + "IV.34(1)3", + "IV.34(1)4", + "IV.34(1)5", + "IV.34(3)" ], - "GOV-04": [ - "3.1.8.C.01", - "3.1.8.C.02", - "3.1.8.C.03", - "3.1.9.C.01", - "3.2.8.C.01", - "3.2.8.C.02", - "3.2.8.C.03", - "3.2.8.C.04", - "3.2.8.C.05", - "3.2.9.C.01", - "3.2.10.C.01", - "3.2.10.C.02", - "3.2.10.C.03", - "3.2.10.C.04", - "3.2.11.C.01", - "3.2.11.C.02", - "3.2.11.C.03", - "3.2.12.C.01", - "3.2.12.C.02", - "3.2.12.C.03", - "3.2.13.C.01", - "3.2.13.C.02", - "3.2.14.C.01", - "3.2.15.C.01", - "3.2.16.C.01", - "3.2.17.C.01", - "3.2.18.C.01", - "3.2.19.C.01" + "PRI-01.1": [ + "IV.31(1)", + "IV.31(2)", + "IV.31(2)1", + "IV.31(2)2", + "IV.31(2)3", + "IV.31(2)4", + "IV.31(2)5", + "IV.31(2)6", + "IV.31(2)7", + "IV.31(3)", + "IV.31(4)", + "IV.31(5)" ], - "GOV-15": [ - "3.2.10.C.04", - "3.4.11.C.01" + "PRI-01.11": [ + "I.3(1)", + "I.3(2)", + "I.3(3)", + "I.3(4)", + "I.3(5)", + "I.3(6)", + "I.3(7)", + "I.3(8)", + "I.4", + "I.4.1", + "I.4.2", + "I.4.3", + "I.4.4", + "I.4.5", + "III.2.23", + "III.2.24(1)", + "III.2.24(1)1", + "III.2.24(1)2", + "III.2.24(2)", + "III.2.24(3)", + "III.2.24(4)", + "IV.29", + "V.38(3)", + "V.38(4)", + "V.38(5)", + "VIII.60" ], - "GOV-15.1": [ - "3.2.10.C.04" + "PRI-02": [ + "III.1.18(3)", + "III.1.18(3)1", + "III.1.18(3)2", + "III.1.18(3)3", + "III.1.18(3)4", + "III.1.18(3)5", + "IV.30(1)", + "IV.30(1)1", + "IV.30(1)2", + "IV.30(1)3", + "IV.30(1)4", + "IV.30(1)5", + "IV.30(1)6", + "IV.30(2)", + "IV.30(3)" ], - "GOV-15.2": [ - "3.4.11.C.01" + "PRI-03": [ + "III.1.15(2)", + "III.1.15(2)1", + "III.1.15(2)2", + "III.1.15(2)3", + "III.1.15(2)4", + "III.1.17(1)", + "III.1.17(1)1", + "III.1.17(1)2", + "III.1.17(2)", + "III.1.17(2)1", + "III.1.17(2)2", + "III.1.17(2)3", + "III.1.17(2)4", + "III.1.17(2)5", + "III.1.17(3)", + "III.1.22(3)" ], - "GOV-15.4": [ - "23.2.16.C.03", - "23.2.16.C.04" + "PRI-03.1": [ + "III.1.22(2)" ], - "GOV-15.5": [ - "23.2.18.C.01" + "PRI-03.2": [ + "III.1.20(1)", + "III.1.20(1)1", + "III.1.20(1)2", + "III.1.20(1)3", + "III.1.22(1)" ], - "AST-01": [ - "8.4.9.C.01" + "PRI-03.4": [ + "V.37(1)" ], - "AST-02": [ - "8.4.8.C.01", - "8.4.9.C.01" + "PRI-03.5": [ + "III.1.16(2)", + "III.1.22(4)" ], - "AST-04": [ - "18.1.9.C.02", - "18.1.11.C.01", - "18.1.12.C.01", - "18.1.12.C.02" + "PRI-03.6": [ + "V.38(1)", + "V.38(2)" ], - "AST-08": [ - "8.5.3.C.01", - "8.5.3.C.02", - "8.5.3.C.03", - "8.5.3.C.04", - "8.5.4.C.01", - "8.5.4.C.02", - "8.5.4.C.03", - "8.5.5.C.01" + "PRI-03.13": [ + "III.1.22(5)" ], - "AST-09": [ - "11.2.13.C.01", - "11.2.13.C.02", - "11.7.35.C.01", - "12.6.4.C.01", - "12.6.4.C.02", - "12.6.5.C.01", - "12.6.5.C.02", - "12.6.5.C.03", - "12.6.5.C.04", - "12.6.5.C.05", - "12.6.8.C.01", - "12.6.9.C.01", - "12.6.10.C.01", - "13.4.19.C.02", - "13.4.10.C.01", - "13.5.24.C.01", - "13.5.24.C.02", - "13.5.24.C.03", - "13.5.24.C.04", - "13.5.25.C.01", - "13.5.26.C.01", - "13.5.26.C.02", - "13.5.26.C.03", - "13.5.29.C.01", - "13.5.29.C.02", - "13.5.30.C.01", - "13.6.6.C.01", - "13.6.6.C.02", - "13.6.7.C.01", - "13.6.8.C.01", - "13.6.9.C.01", - "13.6.10.C.01", - "13.6.10.C.02", - "13.6.10.C.03", - "13.6.11.C.01", - "13.6.12.C.01" + "PRI-04": [ + "III.1.15(1)", + "III.1.15(1)1", + "III.1.15(1)2", + "III.1.15(1)3", + "III.1.15(1)4", + "III.1.15(1)5", + "III.1.15(1)6" ], - "AST-13": [ - "16.2.3.C.01", - "16.2.3.C.02" + "PRI-05": [ + "III.1.21(1)", + "III.1.21(2)", + "III.1.21(3)", + "III.1.21(4)" ], - "AST-14.1": [ - "11.1.8.C.01", - "11.1.10.C.01", - "11.1.10.C.02", - "11.1.10.C.03", - "11.1.11.C.01", - "11.1.11.C.02", - "11.1.12.C.01", - "11.1.13.C.01", - "21.1.16.C.01", - "21.1.16.C.02" + "PRI-05.4": [ + "III.1.18(1)", + "III.1.18(2)", + "III.1.18(2)1", + "III.1.18(2)2", + "III.1.18(2)3", + "III.1.18(2)4", + "III.1.18(2)5", + "III.1.18(2)6", + "III.1.18(2)7", + "III.1.18(2)8", + "III.1.18(2)9", + "III.1.19", + "III.1.19.1", + "III.1.19.2", + "III.2.23.1", + "III.2.23.2" ], - "AST-14.2": [ - "11.1.9.C.01", - "11.1.9.C.02", - "11.1.9.C.03" + "PRI-05.7": [ + "III.2.23" ], - "AST-16": [ - "8.1.12.C.01", - "21.1.12.C.01", - "21.4.7.C.01", - "21.4.7.C.02", - "21.4.8.C.01", - "21.4.8.C.02", - "21.4.9.C.01", - "21.4.10.C.01", - "21.4.10.C.02", - "21.4.10.C.03", - "21.4.10.C.04", - "21.4.10.C.05", - "21.4.10.C.06", - "21.4.10.C.07", - "21.4.10.C.08", - "21.4.10.C.09", - "21.4.10.C.10", - "21.4.10.C.11", - "21.4.10.C.12", - "21.4.10.C.13", - "21.4.10.C.14", - "21.4.10.C.15", - "21.4.10.C.16", - "21.4.11.C.01", - "21.4.11.C.02", - "21.4.11.C.03", - "21.4.11.C.04", - "21.4.11.C.05", - "21.4.11.C.06", - "21.4.11.C.07", - "21.4.11.C.08", - "21.4.11.C.09", - "21.4.11.C.10", - "21.4.11.C.11", - "21.4.11.C.12", - "21.4.11.C.13", - "21.4.11.C.14", - "21.4.11.C.15", - "21.4.11.C.16", - "21.4.11.C.17", - "21.4.11.C.18", - "21.4.11.C.19", - "21.4.11.C.20", - "21.4.13.C.01", - "21.4.13.C.02", - "21.4.13.C.03", - "21.4.13.C.04", - "21.4.13.C.05", - "21.4.13.C.06", - "21.4.13.C.07", - "21.4.13.C.08", - "21.4.13.C.09", - "21.4.13.C.10", - "21.4.13.C.11", - "21.4.14.C.01", - "21.4.14.C.02", - "21.4.14.C.03", - "21.4.14.C.04" + "PRI-06": [ + "V.35(1)", + "V.35(2)", + "V.35(3)", + "V.36(1)" ], - "AST-19": [ - "11.3.5.C.01", - "11.3.6.C.01", - "11.3.6.C.02", - "11.3.7.C.01", - "11.3.8.C.01", - "11.3.9.C.01", - "11.3.9.C.02", - "11.3.10.C.01", - "11.3.11.C.01", - "11.3.12.C.01", - "11.3.12.C.02", - "11.3.12.C.03", - "11.3.13.C.01", - "11.3.13.C.02", - "11.3.13.C.03" + "PRI-06.4": [ + "V.36(2)", + "V.36(3)", + "V.36(4)", + "V.36(5)", + "V.37(2)", + "V.37(2)1", + "V.37(2)2", + "V.37(2)3", + "V.37(2)4", + "V.37(3)", + "V.37(4)" ], - "AST-20": [ - "18.3.14.C.01", - "18.3.14.C.02" + "PRI-07.1": [ + "III.1.18(5)" ], - "AST-21": [ - "18.3.8.C.01", - "18.3.9.C.01", - "18.3.9.C.02", - "18.3.10.C.01", - "18.3.11.C.01", - "18.3.11.C.02", - "18.3.12.C.01", - "18.3.12.C.02", - "18.3.13.C.01", - "18.3.13.C.02", - "18.3.13.C.03", - "18.3.14.C.01", - "18.3.14.C.02", - "18.3.15.C.01", - "18.3.15.C.02", - "18.3.16.C.01", - "18.3.16.C.02", - "18.3.16.C.03", - "18.3.17.C.01" + "PRI-07.4": [ + "V.35(4)", + "V.35(4)1", + "V.35(4)2", + "V.35(4)3", + "V.35(4)3.a", + "V.35(4)3.b", + "V.35(4)3.c", + "V.35(4)3.d", + "V.35(4)3.e" ], - "AST-23": [ - "11.2.3.C.01", - "11.2.4.C.01", - "11.2.4.C.02", - "11.2.5.C.01", - "11.2.6.C.01", - "11.2.7.C.01", - "11.2.7.C.02", - "11.2.8.C.01", - "11.2.9.C.01", - "11.2.10.C.01", - "11.2.11.C.01", - "11.2.11.C.02", - "11.2.11.C.03", - "11.2.11.C.04", - "11.2.11.C.05", - "11.2.12.C.01", - "11.2.12.C.02", - "11.2.13.C.01", - "11.2.13.C.02" + "PRI-17": [ + "III.2.27(1)", + "III.2.27(1)1", + "III.2.27(1)2", + "III.2.27(1)3", + "III.2.27(2)", + "III.2.27(3)" ], - "AST-26": [ - "3.4.10.C.01", - "3.4.10.C.02", - "5.1.11.C.01", - "5.1.13.C.01", - "5.5.3.C.01", - "5.5.4.C.01", - "5.5.5.C.01", - "5.5.6.C.01", - "18.6.10.C.01" + "SAT-01": [ + "III.2.28(2)" + ] + }, + "apac-twn-pdpa-2025": { + "IRO-10": [ + "I.12", + "I.12.1", + "I.12.2" ], - "AST-28": [ - "3.4.10.C.01", - "3.4.10.C.02", - "5.1.11.C.01", - "5.1.13.C.01", - "5.5.3.C.01", - "5.5.4.C.01", - "5.5.5.C.01", - "5.5.6.C.01", - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" + "PRI-01.6": [ + "III.20-1" ], - "AST-28.1": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" + "PRI-01.11": [ + "I.5" ], - "AST-29": [ - "11.6.59.C.01", - "11.6.59.C.02", - "11.6.60.C.01", - "11.6.60.C.02", - "11.6.60.C.03", - "11.6.60.C.04", - "11.6.61.C.01", - "11.6.61.C.02", - "11.6.62.C.01", - "11.6.62.C.02", - "11.6.62.C.03", - "11.6.63.C.01", - "11.6.63.C.02", - "11.6.64.C.01", - "11.6.65.C.01", - "11.6.65.C.02", - "11.6.65.C.03", - "11.6.66.C.01", - "11.6.67.C.01", - "11.6.67.C.02", - "11.6.68.C.01", - "11.6.69.C.01", - "11.6.70.C.01", - "11.6.71.C.01", - "11.6.72.C.01", - "11.6.72.C.02", - "11.6.72.C.03" + "PRI-02": [ + "I.8-1", + "I.8.1-1", + "I.8.2-1", + "I.8.3-1", + "I.8.4-1", + "I.8.5-1", + "I.8.6-1", + "I.8-2", + "I.8.1-2", + "I.8.2-2", + "I.8.3-2", + "I.8.4-2", + "I.8.5-2", + "I.8.6-2", + "I.9", + "I.9.1", + "I.9.2", + "I.9.3", + "I.9.4", + "I.9.5" ], - "AST-29.1": [ - "11.7.29.C.01", - "11.7.29.C.02", - "11.7.30.C.01", - "11.7.30.C.02", - "11.7.30.C.03", - "11.7.31.C.01", - "11.7.31.C.02", - "11.7.32.C.01", - "11.7.32.C.02", - "11.7.32.C.03", - "11.7.32.C.04", - "11.7.33.C.01", - "11.7.33.C.02", - "11.7.33.C.03", - "11.7.34.C.01" + "PRI-03": [ + "I.7" ], - "AST-30": [ - "2.3.30.C.01", - "13.1.9.C.01", - "13.1.10.C.01", - "13.1.10.C.02", - "13.1.10.C.03", - "13.1.10.C.04", - "13.1.11.C.01", - "13.1.12.C.01", - "13.1.12.C.02", - "13.1.12.C.03", - "13.1.13.C.01", - "13.1.13.C.02", - "13.1.13.C.03", - "13.1.13.C.04", - "13.1.14.C.01" + "PRI-05.2": [ + "I.11" ], - "BCD-01": [ - "6.4.5.C.01", - "6.4.7.C.01", - "6.4.8.C.01", - "23.4.12.C.01", - "23.4.12.C.02" + "PRI-05.4": [ + "I.6", + "I.6.1", + "I.6.2", + "I.6.3", + "I.6.4", + "I.6.5", + "I.6.6", + "III.19", + "III.19.1", + "III.19.2", + "III.19.3", + "III.19.4", + "III.19.5", + "III.19.6", + "III.19.7", + "III.19.8", + "III.20", + "III.20.1", + "III.20.2", + "III.20.3", + "III.20.4", + "III.20.5", + "III.20.6", + "III.20.7" + ], + "PRI-06": [ + "I.3", + "I.3.1", + "I.3.2", + "I.3.3", + "I.3.4", + "I.3.5" + ], + "PRI-06.4": [ + "I.10", + "I.10.1", + "I.10.2", + "I.10.3" + ] + }, + "americas-arg-ppd-2018": { + "GOV-04": [ + "E.1.2-8" + ], + "AST-01": [ + "B.1.3-3" + ], + "AST-01.1": [ + "B.1.1" + ], + "AST-02": [ + "B.1.1", + "D.1.1-4" + ], + "AST-02.1": [ + "B.1.3-1" + ], + "AST-03": [ + "B.1.2-1", + "B.1.2-2" + ], + "AST-04": [ + "B.1.1", + "E.1.1-2" + ], + "AST-09": [ + "F", + "F.1.2-DS-2" ], "BCD-11": [ - "6.4.6.C.01" + "D", + "D.1.1-1" ], - "BCD-12.3": [ - "11.3.13.C.01", - "11.3.13.C.02", - "11.3.13.C.03" + "BCD-11.1": [ + "D.1.1-2", + "D.1.1-3", + "D.1.2-4" + ], + "BCD-11.2": [ + "D.1.2-DS-2" + ], + "BCD-11.4": [ + "D.1.2-2" + ], + "BCD-12": [ + "D.1.2-3", + "D.1.2-DS-4" + ], + "BCD-13": [ + "D.1.2-DS-4" + ], + "BCD-14": [ + "D.1.2-DS-4" ], "CHG-01": [ - "6.3.6.C.01" + "C", + "C.1.1-2" ], "CHG-02": [ - "6.3.6.C.02", - "6.3.7.C.01", - "6.3.7.C.02", - "6.3.7.C.03" + "C.1.1-DS" ], "CHG-02.2": [ - "6.3.8.C.01" + "C.1.1-3" ], - "CLD-01": [ - "22.1.20.C.01", - "22.1.20.C.02", - "22.1.20.C.03", - "22.1.20.C.04", - "22.1.20.C.05", - "22.1.21.C.01", - "22.1.21.C.02", - "22.1.21.C.03", - "22.1.21.C.04", - "22.1.21.C.05", - "22.1.21.C.06", - "22.1.21.C.07", - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04", - "22.1.25.C.01", - "22.1.25.C.02", - "22.1.26.C.01", - "22.1.26.C.02", - "22.1.26.C.03", - "22.1.27.C.01", - "23.1.54.C.01", - "23.1.54.C.02", - "23.2.19.C.01" + "CHG-06": [ + "C.1.1-1" ], - "CLD-01.1": [ - "23.4.9.C.01", - "23.4.9.C.02", - "23.4.9.C.03", - "23.4.10.C.01", - "23.5.11.C.01", - "23.5.12.C.01", - "23.5.12.C.02" + "CPL-02.2": [ + "E.1.4-DS-2" ], - "CLD-01.2": [ - "23.4.13.C.01", - "23.4.13.C.02", - "23.4.13.C.03" + "CPL-03": [ + "E.1.4-DS-1" ], - "CLD-02": [ - "22.1.23.C.01", - "22.1.23.C.02", - "22.1.23.C.03", - "23.1.54.C.01", - "23.1.54.C.02", - "23.1.56.C.01", - "23.2.20.C.01" + "CFG-02": [ + "B.2.4-4", + "E.1.2-5" ], - "CLD-03": [ - "22.1.24.C.02" + "CFG-02.5": [ + "E.1.2-2", + "E.1.2-DS-1" ], - "CLD-06": [ - "23.1.55.C.01", - "23.1.55.C.02", - "23.1.55.C.03", - "23.2.20.C.01" + "MON-01.4": [ + "B.2.3-3", + "B.2.3-4", + "B.2.5-DS-3" ], - "CLD-06.1": [ - "23.1.55.C.01", - "23.1.55.C.02", - "23.1.55.C.03" + "MON-01.8": [ + "B.2.5-DS-3" ], - "CLD-06.2": [ - "23.5.11.C.01", - "23.5.12.C.01", - "23.5.12.C.02" + "MON-01.15": [ + "B.2.1-3" ], - "CLD-06.4": [ - "23.5.12.C.01", - "23.5.12.C.02" + "CRY-03": [ + "A.2.1", + "A.2.3-DS" ], - "CLD-09": [ - "22.1.22.C.01", - "22.1.22.C.02", - "22.1.22.C.03", - "22.1.22.C.04", - "22.1.22.C.05", - "22.1.22.C.06", - "23.4.11.C.01", - "23.4.11.C.02" + "CRY-08": [ + "A.2.3" ], - "CLD-10": [ - "2.3.23.C.01", - "22.1.22.C.04", - "22.1.22.C.05" + "CRY-09": [ + "A.2.3" ], - "CLD-11": [ - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04" + "DCH-01.4": [ + "B.1.3-2", + "B.2.1-2" ], - "CPL-01": [ - "1.1.64.C.01", - "1.1.65.C.01", - "1.1.66.C.01", - "1.1.66.C.02", - "1.1.67.C.01" + "DCH-03.2": [ + "H.1.1" ], - "CPL-01.1": [ - "1.1.68.C.01", - "1.1.69.C.01", - "1.1.69.C.02" + "DCH-07": [ + "D.1.2-DS-3" ], - "CPL-02": [ - "6.1.7.C.01", - "23.2.18.C.01" + "DCH-07.1": [ + "D.1.2-DS-3" ], - "CPL-03": [ - "4.3.16.C.01", - "6.1.7.C.01", - "6.1.9.C.01", - "23.2.18.C.01" + "DCH-08": [ + "F.1.2-DS-1" ], - "CPL-03.1": [ - "6.1.8.C.01" + "DCH-09": [ + "D.1.2-4", + "F.1.2" ], - "CPL-03.2": [ - "6.1.7.C.01", - "6.1.9.C.01", - "23.2.18.C.01" + "DCH-09.1": [ + "F.1.1", + "F.1.4" ], - "CFG-01": [ - "4.3.19.C.01", - "12.2.5.C.01", - "12.2.5.C.02", - "12.2.6.C.01", - "12.2.6.C.02", - "18.1.10.C.01", - "18.1.10.C.02", - "18.1.10.C.03", - "18.1.10.C.04" + "DCH-23": [ + "H.1.1" ], - "CFG-01.1": [ - "4.3.19.C.01" + "END-02": [ + "E.1.2-5" ], - "CFG-02": [ - "14.1.8.C.01", - "14.1.9.C.01", - "14.1.9.C.02", - "14.1.10.C.01", - "14.1.10.C.02", - "14.3.7.C.01", - "23.2.21.C.01" + "END-04": [ + "E.1.2-6" ], - "CFG-02.4": [ - "18.1.10.C.01", - "18.1.10.C.02", - "18.1.10.C.03", - "18.1.10.C.04" + "HRS-03": [ + "B.2.2", + "E.1.2-1", + "F.1.3" ], - "CFG-02.5": [ - "18.1.10.C.01", - "18.1.10.C.02", - "18.1.10.C.03", - "18.1.10.C.04", - "23.2.21.C.01" + "HRS-03.1": [ + "B.2.2" ], - "CFG-02.6": [ - "18.1.10.C.01", - "18.1.10.C.02", - "18.1.10.C.03", - "18.1.10.C.04" + "HRS-04.2": [ + "B.2.2" ], - "CFG-02.9": [ - "16.1.50.C.01", - "16.1.50.C.02" + "IAC-01": [ + "B", + "D.1.2-1" ], - "CFG-03": [ - "18.1.15.C.01", - "18.1.15.C.02", - "18.1.15.C.03", - "18.1.15.C.04" + "IAC-01.2": [ + "B.2.3-1" ], - "CFG-03.3": [ - "14.2.4.C.01", - "14.2.5.C.01", - "14.2.5.C.02", - "14.2.5.C.03", - "14.2.5.C.04", - "14.2.6.C.01", - "14.2.7.C.01", - "14.2.7.C.02", - "14.2.7.C.03", - "14.2.7.C.04", - "14.2.7.C.05", - "14.2.7.C.06", - "14.2.7.C.07" + "IAC-08": [ + "B.1.2-3" ], - "CFG-03.4": [ - "18.7.14.C.01", - "18.7.14.C.02" + "IAC-10.1": [ + "B.2.3-7" ], - "MON-01": [ - "16.6.6.C.01", - "16.6.6.C.02", - "16.6.8.C.01", - "16.6.10.C.01", - "16.6.10.C.02" + "IAC-15.1": [ + "B.2.3-2" ], - "MON-01.1": [ - "16.6.10.C.01", - "16.6.10.C.02", - "18.4.7.C.01", - "18.4.7.C.02", - "18.4.7.C.03", - "18.4.8.C.01", - "18.4.8.C.02", - "18.4.8.C.03", - "18.4.9.C.01", - "18.4.9.C.02", - "18.4.10.C.01", - "18.4.11.C.01", - "18.4.11.C.02", - "18.4.11.C.03", - "18.4.12.C.01", - "18.4.14.C.01" + "IAC-15.3": [ + "B.2.5" ], - "MON-01.3": [ - "16.6.10.C.01", - "16.6.10.C.02", - "18.4.8.C.01", - "18.4.8.C.02", - "18.4.8.C.03" + "IAC-15.5": [ + "B.2.3-8" ], - "MON-01.5": [ - "16.6.10.C.01", - "16.6.10.C.02", - "18.4.8.C.01", - "18.4.8.C.02", - "18.4.8.C.03" + "IAC-16": [ + "B.2.1-2", + "B.2.1-3", + "B.2.3-6", + "B.2.5-DS-2" ], - "MON-01.7": [ - "16.6.10.C.01", - "16.6.10.C.02" + "IAC-23": [ + "B.2.5-DS-1" ], - "MON-01.9": [ - "14.3.6.C.02", - "16.6.10.C.01", - "16.6.10.C.02" + "IAC-28.1": [ + "B.2.3-5" ], - "MON-01.16": [ - "16.6.6.C.01", - "16.6.6.C.02", - "16.6.8.C.01", - "16.6.10.C.01", - "16.6.10.C.02" + "IRO-01": [ + "E.1.2-11", + "G" ], - "MON-02": [ - "16.6.11.C.01", - "16.6.11.C.02", - "16.6.11.C.03", - "16.6.12.C.01", - "16.6.12.C.02", - "16.6.12.C.03" + "IRO-02": [ + "E.1.2-10", + "E.1.2-11", + "G.1.1-1" ], - "MON-02.1": [ - "16.6.14.C.01", - "18.4.12.C.01" + "IRO-04": [ + "G.1.1-1" ], - "MON-02.2": [ - "16.6.11.C.01", - "16.6.11.C.02", - "16.6.11.C.03", - "16.6.12.C.01", - "16.6.12.C.02", - "16.6.12.C.03" + "IRO-07": [ + "G.1.1-2" ], - "MON-02.7": [ - "16.6.11.C.02" + "IRO-10": [ + "G.1.2" ], - "MON-03": [ - "16.6.7.C.01", - "16.6.9.C.01", - "16.6.10.C.01", - "16.6.10.C.02" + "IRO-10.2": [ + "G.1.3" ], - "MON-03.2": [ - "16.6.8.C.01", - "16.6.9.C.01", - "16.6.10.C.01", - "16.6.10.C.02" + "IAO-03": [ + "B.2.1-1", + "E.1.1-3" ], - "MON-03.7": [ - "16.6.7.C.01", - "16.6.9.C.01", - "16.6.10.C.01", - "16.6.10.C.02" + "NET-06": [ + "E.1.2-3" ], - "MON-04": [ - "16.6.13.C.01", - "16.6.13.C.02", - "16.6.13.C.03", - "16.6.13.C.04" + "NET-08": [ + "E.1.2-DS-2" ], - "MON-08": [ - "16.6.13.C.01", - "16.6.13.C.02", - "16.6.13.C.03", - "16.6.13.C.04" + "NET-17": [ + "E.1.2-DS-3" ], - "MON-08.1": [ - "16.6.13.C.01", - "16.6.13.C.02", - "16.6.13.C.03", - "16.6.13.C.04" + "PES-03": [ + "B.2.4-1", + "B.2.4-2" ], - "CRY-01": [ - "8.4.13.C.01", - "17.1.52.C.01", - "17.1.52.C.02", - "17.1.53.C.01", - "17.1.53.C.02", - "17.1.53.C.03", - "17.1.53.C.04", - "17.1.54.C.01", - "17.1.55.C.01", - "17.1.55.C.02", - "17.1.55.C.03", - "17.1.55.C.04", - "17.1.56.C.01", - "17.1.56.C.02", - "17.1.57.C.01", - "17.2.17.C.01", - "17.2.18.C.01", - "17.2.19.C.01", - "17.2.20.C.01", - "17.2.20.C.02", - "17.2.21.C.01", - "17.2.22.C.01", - "17.2.22.C.02", - "17.2.23.C.01", - "17.2.24.C.01", - "17.2.24.C.02", - "17.2.24.C.03", - "17.2.25.C.01", - "17.2.26.C.01", - "17.2.26.C.02", - "17.2.26.C.03", - "17.2.27.C.01", - "17.2.27.C.02", - "17.2.27.C.03", - "17.2.28.C.01", - "17.3.6.C.01", - "17.4.16.C.01", - "17.4.16.C.02", - "17.5.6.C.01", - "17.6.6.C.01", - "17.6.7.C.01", - "17.7.6.C.01", - "17.8.10.C.01", - "17.8.10.C.02", - "17.8.11.C.01", - "17.8.12.C.01", - "17.8.13.C.01", - "17.8.14.C.01", - "17.8.15.C.01", - "17.8.16.C.01", - "17.8.17.C.01", - "17.9.24.C.01", - "17.9.24.C.02", - "17.9.24.C.03", - "17.9.25.C.01", - "17.9.26.C.01", - "17.9.26.C.02", - "17.9.27.C.01", - "17.9.27.C.02", - "17.9.27.C.03", - "17.9.28.C.01", - "17.9.29.C.01", - "17.9.30.C.01", - "17.9.30.C.02", - "17.9.31.C.01", - "17.9.32.C.01", - "17.9.32.C.02", - "17.9.32.C.03" + "PES-03.1": [ + "B.2.4-3" ], - "CRY-05": [ - "8.4.13.C.01" + "PES-03.3": [ + "B.2.4-3", + "B.2.4-4" ], - "CRY-05.1": [ - "8.4.13.C.01" + "PES-07.5": [ + "D.1.2-DS-1" ], - "CRY-07": [ - "18.2.9.C.01", - "18.2.10.C.01", - "18.2.10.C.02", - "18.2.11.C.01", - "18.2.11.C.02", - "18.2.11.C.03", - "18.2.11.C.04", - "18.2.11.C.05", - "18.2.12.C.01", - "18.2.12.C.02", - "18.2.13.C.01", - "18.2.14.C.01", - "18.2.15.C.01", - "18.2.16.C.01", - "18.2.17.C.01", - "18.2.18.C.01", - "18.2.19.C.01", - "18.2.20.C.01", - "18.2.20.C.02", - "18.2.20.C.03", - "18.2.21.C.01", - "18.2.22.C.01", - "18.2.23.C.01", - "18.2.23.C.02", - "18.2.24.C.01", - "18.2.25.C.01" + "PES-08": [ + "D.1.2-DS-1" ], - "CRY-08": [ - "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03", - "23.3.21.C.01", - "23.3.22.C.01" + "PRI-01.6": [ + "E.1.2-1" ], - "CRY-08.1": [ - "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03" + "PRI-01.11": [ + "A", + "A.1.1", + "A.1.2", + "A.1.3", + "A.2.2-1", + "A.2.2-2" ], - "CRY-09": [ - "17.1.51.C.01", - "17.1.58.C.01", - "17.1.58.C.02", - "17.1.58.C.03", - "23.3.21.C.01", - "23.3.22.C.01", - "23.4.9.C.02", - "23.4.9.C.03" + "PRI-05.2": [ + "A.1.3" ], - "CRY-09.3": [ - "7.2.24.C.01", - "7.2.25.C.01" + "SEA-20": [ + "E.1.2-9" ], - "CRY-09.7": [ - "23.4.9.C.02", - "23.4.9.C.03" + "OPS-01.1": [ + "B.1.3-1", + "B.1.3-2", + "B.1.3-3", + "B.2.4-2", + "B.2.5" ], - "CRY-11": [ - "23.3.21.C.01", - "23.3.22.C.01" + "TDA-01": [ + "H" ], - "DCH-01": [ - "4.4.10.C.01", - "9.2.12.C.01", - "9.2.13.C.01", - "9.2.13.C.02", - "9.2.14.C.01", - "9.2.15.C.01", - "9.2.15.C.02", - "9.2.17.C.01", - "9.2.17.C.02", - "9.2.18.C.01", - "9.2.19.C.01", - "9.2.19.C.02", - "9.2.19.C.03", - "9.2.19.C.04", - "9.2.20.C.01", - "13.2.6.C.01", - "13.2.7.C.01" + "TDA-08": [ + "E.1.2-4" + ], + "THR-09": [ + "E.1.1-1" + ], + "THR-10": [ + "E.1.1-1" + ], + "VPM-01": [ + "E" + ], + "VPM-05": [ + "E.1.2-7" + ] + }, + "americas-bhs-dpa-2003": { + "CPL-01": [ + "II.4(1)", + "IV.24(6)", + "IV.24(7)", + "IV.24(7)(a)", + "IV.24(7)(b)", + "V.45(4)(a)", + "V.45(4)(b)", + "V.45(5)", + "V.45(6)", + "V.45(7)" + ], + "CPL-03": [ + "VI.55", + "VI.55(a)", + "VI.55(b)" ], "DCH-01.2": [ - "18.6.8.C.01" + "V.46(1)", + "V.46(2)", + "V.46(2)(a)", + "V.46(2)(b)" ], - "DCH-02": [ - "12.3.4.C.01", - "12.3.5.C.01", - "12.3.5.C.02", - "12.3.6.C.01", - "12.3.7.C.01", - "18.6.8.C.01" + "HRS-05": [ + "II.4(2)" ], - "DCH-02.1": [ - "4.4.9.C.01", - "13.2.8.C.01", - "13.2.9.C.01", - "18.6.9.C.01" + "IRO-04.1": [ + "V.48(1)" ], - "DCH-04": [ - "4.4.10.C.01", - "12.3.4.C.01", - "12.3.5.C.01", - "12.3.5.C.02", - "12.3.6.C.01", - "12.3.7.C.01", - "13.2.12.C.01", - "13.2.12.C.02", - "13.2.12.C.03", - "13.2.12.C.04", - "13.2.13.C.01", - "13.2.14.C.01", - "13.2.14.C.02", - "21.1.21.C.01" + "IRO-10": [ + "V.48(2)", + "V.48(3)", + "V.48(3)(a)", + "V.48(3)(b)", + "V.48(3)(c)" ], - "DCH-06": [ - "8.4.10.C.01", - "8.4.11.C.01", - "8.4.12.C.01", - "8.4.13.C.01", - "13.3.5.C.01" + "IRO-10.2": [ + "V.47(1)", + "V.47(2)", + "V.47(3)", + "V.47(4)(a)", + "V.47(4)(b)", + "V.47(4)(c)", + "V.47(4)(d)", + "V.47(4)(e)", + "V.47(4)(f)", + "V.47(4)(g)", + "V.47(4)(h)", + "V.47(5)", + "V.47(6)", + "V.47(6)(a)", + "V.47(6)(b)", + "V.47(6)(c)" ], - "DCH-06.4": [ - "8.4.13.C.01" + "IRO-12": [ + "IV.28(3)(a)", + "IV.28(3)(b)", + "IV.28(3)(b)(i)", + "IV.28(3)(b)(ii)", + "IV.28(3)(b)(iii)" ], - "DCH-07.2": [ - "8.4.13.C.01" + "IAO-03.2": [ + "V.51(1)(a)" ], - "DCH-08": [ - "11.7.35.C.01", - "12.6.6.C.01", - "12.6.6.C.02", - "12.6.7.C.01", - "12.6.7.C.02", - "13.5.23.C.01", - "13.5.24.C.01", - "13.5.24.C.02", - "13.5.24.C.03", - "13.5.24.C.04", - "13.5.25.C.01", - "13.5.26.C.01", - "13.5.26.C.02", - "13.5.26.C.03", - "13.5.29.C.01", - "13.5.29.C.02", - "13.5.30.C.01" + "PRI-01": [ + "V.45(2)(a)", + "V.45(2)(b)", + "V.45(2)(b)(i)", + "V.45(2)(b)(ii)" ], - "DCH-09": [ - "13.4.9.C.01", - "13.4.11.C.01", - "13.4.12.C.01", - "13.4.13.C.01", - "13.4.13.C.02", - "13.4.13.C.03", - "13.4.13.C.04", - "13.4.13.C.05", - "13.4.14.C.01", - "13.4.15.C.01", - "12.6.5.C.05", - "13.4.19.C.02", - "13.4.16.C.01", - "13.4.17.C.01", - "13.4.18.C.01", - "13.4.19.C.01", - "13.4.20.C.01", - "13.4.20.C.02", - "13.4.20.C.03", - "13.4.21.C.01", - "13.4.22.C.01" + "PRI-01.4": [ + "V.45(1)", + "V.45(1)(a)", + "V.45(1)(b)", + "V.45(1)(c)", + "V.45(3)", + "V.45(3)(a)", + "V.45(3)(b)", + "V.45(3)(c)", + "V.45(3)(d)", + "V.45(3)(e)", + "V.45(3)(f)", + "V.45(3)(g)", + "V.45(3)(h)", + "V.45(3)(i)", + "V.45(3)(j)" ], - "DCH-09.1": [ - "13.5.22.C.01", - "13.5.27.C.01", - "13.5.27.C.02", - "13.5.27.C.03", - "13.5.28.C.01", - "13.5.28.C.02" + "PRI-01.6": [ + "II.5(1)(f)", + "II.9(2)", + "II.11(1)", + "II.11(1)(a)", + "II.11(1)(b)", + "II.11(2)", + "V.43(4)(d)", + "V.43(4)(e)", + "V.52(1)", + "V.52(2)", + "V.52(2)(a)", + "V.52(2)(b)", + "V.52(2)(c)", + "V.52(2)(d)", + "V.52(4)" ], - "DCH-09.2": [ - "13.4.23.C.01" + "PRI-01.11": [ + "II.5(1)(a)", + "II.5(1)(b)", + "II.5(1)(c)", + "II.5(1)(d)", + "II.5(1)(e)", + "II.5(1)(f)", + "II.5(2)", + "II.5(3)", + "II.8(4)", + "V.43(4)(d)", + "V.43(4)(e)" ], - "DCH-10": [ - "13.3.4.C.01" + "PRI-02": [ + "II.8(1)", + "II.8(1)(a)", + "II.8(1)(b)", + "II.8(1)(c)", + "II.8(1)(d)", + "II.8(1)(e)", + "II.8(1)(f)", + "II.8(1)(g)", + "II.8(1)(g)(i)", + "II.8(1)(g)(ii)", + "II.8(1)(g)(iii)", + "II.8(1)(h)", + "II.8(1)(i)", + "II.8(2)", + "II.8(2)(a)", + "II.8(2)(b)", + "IV.24(1)(a)", + "IV.24(1)(b)", + "IV.24(1)(b)(i)", + "IV.24(1)(b)(ii)", + "IV.24(1)(b)(iii)", + "IV.24(1)(b)(iv)", + "IV.24(1)(b)(v)", + "IV.24(1)(c)", + "IV.24(1)(c)(i)", + "IV.24(1)(c)(ii)", + "IV.24(1)(c)(iii)", + "IV.24(1)(d)", + "IV.24(1)(e)", + "IV.24(1)(f)", + "IV.24(1)(g)", + "V.45(8)", + "V.52(3)" ], - "DCH-10.1": [ - "13.3.4.C.01" + "PRI-02.1": [ + "II.5(1)(b)" ], - "DCH-11": [ - "13.2.10.C.01", - "13.2.11.C.01" + "PRI-03": [ + "II.7(1)", + "IV.32(1)", + "IV.32(2)", + "IV.32(2)(a)", + "IV.32(2)(b)", + "IV.32(2)(c)", + "IV.32(3)", + "IV.32(4)", + "IV.32(5)", + "IV.32(6)", + "IV.36(2)" ], - "DCH-12": [ - "13.3.6.C.01", - "13.3.6.C.02", - "13.3.6.C.03", - "13.3.10.C.01" + "PRI-03.9": [ + "IV.35(1)", + "IV.35(1)(a)", + "IV.35(1)(b)", + "IV.36(1)" ], - "DCH-13.2": [ - "13.3.7.C.01", - "13.3.7.C.02", - "13.3.8.C.01", - "13.3.8.C.02", - "13.3.9.C.01", - "13.3.9.C.02", - "13.3.10.C.01" + "PRI-03.13": [ + "IV.33(1)", + "IV.33(2)", + "IV.33(3)", + "IV.33(4)", + "IV.33(4)(a)", + "IV.33(4)(b)", + "IV.33(4)(c)" ], - "DCH-14": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" + "PRI-04": [ + "II.5(1)(c)" ], - "DCH-14.2": [ - "20.1.8.C.01", - "20.2.4.C.01" + "PRI-04.1": [ + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.36(3)", + "IV.36(3)(a)", + "IV.36(3)(b)", + "IV.36(3)(c)", + "IV.36(3)(c)(i)", + "IV.36(3)(c)(ii)" ], - "DCH-14.3": [ - "16.2.5.C.01", - "16.2.6.C.01" + "PRI-05": [ + "II.5(1)(e)", + "II.9(1)", + "II.9(1)(a)", + "II.9(1)(b)", + "II.9(1)(c)" ], - "DCH-16": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" + "PRI-05.1": [ + "II.5(2)" ], - "DCH-17": [ - "20.1.11.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04" + "PRI-05.2": [ + "II.5(1)(d)", + "II.5(3)", + "II.10(1)", + "II.10(2)", + "II.10(2)(a)", + "II.10(2)(b)" ], - "END-04": [ - "14.1.9.C.02" + "PRI-05.4": [ + "IV.29(2)", + "IV.29(2)(a)", + "IV.29(2)(b)", + "IV.29(2)(c)", + "IV.29(2)(d)", + "IV.34(1)", + "IV.34(2)", + "IV.34(2)(a)", + "IV.34(2)(b)", + "IV.34(2)(c)", + "IV.34(2)(d)", + "IV.34(2)(e)", + "IV.34(2)(e)(i)", + "IV.34(2)(e)(ii)", + "IV.34(2)(f)", + "IV.34(2)(g)", + "IV.34(2)(h)", + "IV.34(2)(i)", + "IV.34(2)(j)", + "IV.34(2)(k)", + "IV.34(2)(l)", + "IV.34(2)(m)", + "IV.34(2)(n)", + "IV.34(2)(n)(i)", + "IV.34(2)(n)(ii)", + "IV.34(2)(n)(iii)", + "IV.34(2)(n)(iv)", + "IV.34(2)(o)", + "IV.34(2)(o)(a)", + "IV.34(2)(o)(b)", + "IV.34(2)(p)", + "IV.34(2)(p)(i)", + "IV.34(2)(p)(ii)", + "IV.34(2)(p)(ii)(aa)", + "IV.34(2)(p)(ii)(bb)", + "IV.34(2)(p)(ii)(cc)", + "IV.34(2)(p)(ii)(dd)", + "IV.34(2)(p)(ii)(ee)", + "IV.34(2)(p)(iii)", + "IV.34(2)(q)", + "IV.34(2)(q)(i)", + "IV.34(2)(q)(ii)", + "IV.34(2)(q)(iii)", + "IV.34(2)(r)", + "IV.34(2)(s)", + "IV.34(4)", + "IV.34(4)(a)", + "IV.34(4)(b)", + "IV.34(5)", + "IV.34(5)(a)", + "IV.34(5)(b)", + "IV.34(5)(c)", + "IV.34(5)(d)", + "IV.34(6)" ], - "END-06": [ - "14.1.12.C.01", - "14.1.12.C.02", - "14.1.12.C.03" + "PRI-05.7": [ + "V.43(4)(b)" ], - "END-07": [ - "18.4.13.C.01" + "PRI-06": [ + "IV.27(1)", + "IV.29(1)", + "IV.29(1)(a)", + "IV.29(1)(b)", + "IV.29(1)(c)", + "IV.29(1)(d)", + "IV.29(1)(e)", + "IV.29(1)(f)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(2)", + "IV.30(2)(a)", + "IV.30(2)(b)", + "IV.30(3)" ], - "END-08": [ - "15.2.21.C.01", - "15.2.23.C.01", - "15.2.23.C.02", - "15.2.23.C.03", - "15.2.24.C.01", - "15.2.24.C.02" + "PRI-06.1": [ + "IV.26(1)", + "IV.26(2)" ], - "HRS-01": [ - "9.2.10.C.01", - "9.2.11.C.01", - "9.2.11.C.02", - "14.3.5.C.01", - "15.1.7.C.01" + "PRI-06.2": [ + "IV.26(3)(a)", + "IV.26(3)(b)" ], - "HRS-02": [ - "9.2.10.C.01", - "9.2.10.C.02", - "9.2.11.C.01", - "9.2.11.C.02" + "PRI-06.4": [ + "IV.24(4)", + "IV.24(4)(a)", + "IV.24(4)(b)", + "IV.24(5)", + "IV.24(5)(a)", + "IV.24(5)(b)", + "IV.24(10)", + "IV.24(10)(a)", + "IV.24(10)(b)", + "IV.24(10)(c)", + "IV.24(10)(d)", + "IV.24(13)(f)", + "IV.27(3)", + "IV.28(5)(a)", + "IV.28(5)(b)", + "IV.29(3)(a)", + "IV.29(3)(b)" ], - "HRS-03": [ - "3.3.4.C.01", - "3.3.4.C.02", - "3.3.4.C.03", - "3.3.4.C.04", - "3.3.4.C.05", - "3.3.5.C.01", - "3.3.5.C.02", - "3.3.6.C.01", - "3.3.6.C.02", - "3.3.6.C.03", - "3.3.6.C.04", - "3.3.6.C.05", - "3.3.6.C.06", - "3.3.7.C.01", - "3.3.8.C.01", - "3.3.8.C.02", - "3.3.8.C.03", - "3.3.8.C.04", - "3.3.8.C.05", - "3.3.9.C.01", - "3.3.10.C.01", - "3.3.10.C.02", - "3.3.10.C.03", - "3.3.10.C.04", - "3.3.11.C.01", - "3.3.12.C.01", - "3.3.13.C.01", - "3.3.13.C.02", - "3.3.14.C.01", - "3.3.14.C.02", - "3.3.14.C.03", - "3.3.15.C.01", - "3.4.10.C.01", - "3.4.10.C.02" + "PRI-06.5": [ + "IV.28(1)", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(c)", + "IV.28(2)(d)", + "IV.28(2)(e)", + "IV.28(4)", + "IV.28(4)(a)", + "IV.28(4)(b)", + "IV.28(4)(c)", + "IV.28(4)(d)", + "IV.28(4)(e)" ], - "HRS-03.2": [ - "5.1.14.C.01" + "PRI-07": [ + "VI.53(1)", + "VI.54", + "VI.54(a)", + "VI.54(b)", + "VI.54(b)(i)", + "VI.54(b)(ii)", + "VI.54(b)(iii)", + "VI.54(b)(iv)", + "VI.54(b)(v)", + "VI.54(b)(vi)", + "VI.54(c)" ], - "HRS-04.2": [ - "9.1.7.C.01" + "PRI-07.1": [ + "V.51(1)(a)", + "V.51(1)(b)", + "V.51(1)(b)(i)", + "V.51(1)(b)(ii)", + "V.51(1)(b)(iii)", + "V.51(1)(b)(iv)", + "V.51(2)(a)", + "V.51(2)(b)", + "V.51(2)(c)", + "V.51(2)(d)", + "V.51(2)(e)", + "V.51(2)(f)", + "V.51(2)(g)", + "V.51(2)(h)", + "V.51(3)", + "V.51(4)", + "V.51(5)", + "V.51(5)(a)", + "V.51(5)(b)", + "V.51(6)", + "V.51(7)", + "V.51(8)" ], - "HRS-04.3": [ - "9.2.10.C.01", - "9.2.10.C.02", - "9.2.11.C.01", - "9.2.11.C.02", - "9.2.15.C.01", - "9.2.15.C.02", - "9.2.16.C.01" + "PRI-14": [ + "V.43(1)", + "V.43(2)", + "V.43(2)(a)", + "V.43(2)(b)", + "V.43(2)(c)", + "V.43(2)(d)", + "V.43(2)(e)", + "V.43(2)(f)", + "V.43(2)(g)", + "V.43(2)(h)", + "V.43(2)(i)", + "V.43(2)(j)", + "V.43(3)", + "V.43(4)", + "V.43(4)(a)", + "V.43(4)(b)", + "V.43(4)(c)" ], - "HRS-04.4": [ - "9.2.15.C.01", - "9.2.15.C.02", - "9.2.16.C.01", - "16.1.39.C.01", - "16.1.39.C.02" + "PRI-14.1": [ + "V.43(4)(c)" ], - "HRS-05": [ - "3.5.4.C.01", - "3.5.4.C.02", - "3.5.4.C.03", - "5.5.7.C.01", - "8.1.12.C.01", - "9.3.7.C.01", - "9.3.7.C.02", - "9.3.7.C.03", - "9.3.7.C.04", - "9.3.8.C.01", - "9.3.8.C.02", - "9.3.8.C.03" + "PRI-14.2": [ + "V.46(3)", + "V.46(3)(a)", + "V.46(3)(b)", + "V.46(3)(c)", + "V.46(3)(d)" ], - "HRS-05.1": [ - "3.5.4.C.01", - "3.5.4.C.02", - "3.5.4.C.03", - "5.5.7.C.01", - "8.1.12.C.01", - "9.1.8.C.01", - "9.3.7.C.01", - "9.3.7.C.02", - "9.3.7.C.03", - "9.3.7.C.04", - "9.3.8.C.01", - "9.3.8.C.02", - "9.3.8.C.03", - "14.3.5.C.01", - "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "PRI-15": [ + "V.41(1)", + "V.41(1)(a)", + "V.41(1)(b)", + "V.41(1)(c)", + "V.41(1)(d)", + "V.41(1)(e)", + "V.41(1)(f)", + "V.41(1)(g)", + "V.41(2)", + "V.41(3)" ], - "HRS-05.2": [ - "9.3.7.C.01", - "9.3.7.C.02", - "9.3.7.C.03", - "9.3.7.C.04", - "9.3.8.C.01", - "9.3.8.C.02", - "9.3.8.C.03" + "PRI-17": [ + "IV.24(2)", + "IV.24(2)(a)", + "IV.24(2)(b)", + "IV.36(4)", + "IV.36(4)(a)", + "IV.36(4)(b)" + ], + "PRI-19": [ + "IV.24(3)", + "V.49(1)", + "V.49(2)", + "V.49(2)(a)", + "V.49(2)(b)", + "V.49(2)(c)", + "V.49(3)", + "V.49(4)", + "V.49(4)(a)", + "V.49(4)(b)" ], - "HRS-05.3": [ - "9.3.4.C.01", - "9.3.5.C.01", - "9.3.5.C.02", - "9.3.9.C.01", - "9.3.10.C.01", - "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "PRI-19.3": [ + "IV.24(3)(a)", + "IV.24(3)(b)", + "IV.24(3)(c)", + "IV.24(3)(d)" ], - "HRS-05.5": [ - "8.1.12.C.01", - "11.4.9.C.01", - "11.4.10.C.01", - "11.4.10.C.02", - "11.4.11.C.01", - "11.4.12.C.01", - "11.4.12.C.02", - "11.5.13.C.01", - "11.5.14.C.01", - "11.5.14.C.02", - "11.5.15.C.01", - "11.5.15.C.02", - "11.5.16.C.01", - "11.5.16.C.02", - "11.5.16.C.03", - "21.1.11.C.01", - "21.1.11.C.02", - "21.1.22.C.01", - "21.1.22.C.02" + "RSK-10": [ + "V.50(1)", + "V.50(1)(a)", + "V.50(1)(b)", + "V.50(2)", + "V.50(2)(a)", + "V.50(2)(b)", + "V.50(2)(c)", + "V.50(3)", + "V.50(3)(a)", + "V.50(3)(b)", + "V.50(3)(c)", + "V.50(3)(d)", + "V.50(4)", + "V.50(5)", + "V.50(6)", + "V.50(7)", + "V.50(8)", + "V.50(8)(a)", + "V.50(8)(b)", + "V.50(8)(c)", + "V.50(8)(d)", + "V.50(8)(e)", + "V.50(8)(f)" + ] + }, + "americas-bmu-mba-coc-2020": { + "GOV-01": [ + "6.1" ], - "HRS-06.1": [ - "9.1.8.C.01" + "GOV-01.1": [ + "5.1" ], - "IAC-01": [ - "16.1.31.C.01" + "GOV-02": [ + "5.3", + "7.1" ], - "IAC-02": [ - "16.1.32.C.01" + "GOV-04": [ + "5.2" ], - "IAC-02.1": [ - "16.1.33.C.01", - "16.1.33.C.02", - "16.1.34.C.01" + "GOV-10": [ + "5.3-BP2" ], - "IAC-06": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01", - "23.3.19.C.01", - "23.3.19.C.02" + "GOV-15": [ + "5.3-BP2", + "5.11-BP4" ], - "IAC-06.1": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "AST-02": [ + "5.9" ], - "IAC-06.2": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "AST-03": [ + "5.9-BP1", + "5.9-BP2" ], - "IAC-06.3": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "BCD-01": [ + "6.3", + "7.1" ], - "IAC-07": [ - "23.3.20.C.01" + "BCD-01.7": [ + "7.1" ], - "IAC-08": [ - "9.2.11.C.01", - "9.2.11.C.02", - "16.2.4.C.01", - "16.2.5.C.01" + "BCD-04": [ + "7.1-BP2" ], - "IAC-10": [ - "14.3.13.C.01", - "14.3.13.C.02", - "14.3.13.C.03", - "16.1.40.C.01", - "16.1.40.C.02", - "16.1.41.C.01", - "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04", - "16.1.42.C.01" + "BCD-11": [ + "6.14" ], - "IAC-10.1": [ - "16.1.35.C.01", - "16.1.35.C.02", - "16.1.42.C.01", - "16.1.43.C.01" + "BCD-11.5": [ + "6.14" ], - "IAC-10.4": [ - "16.1.41.C.01", - "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04" + "CAP-01": [ + "6.1-BP5" ], - "IAC-10.5": [ - "16.1.36.C.01", - "16.1.37.C.01", - "16.1.38.C.01" + "CHG-01": [ + "6.1-BP2" ], - "IAC-10.6": [ - "16.1.36.C.01" + "CLD-01": [ + "5.11" ], - "IAC-10.11": [ - "14.3.13.C.01", - "14.3.13.C.02", - "14.3.13.C.03" + "CLD-06.1": [ + "5.11" ], - "IAC-12.1": [ - "17.10.12.C.01", - "17.10.12.C.02", - "17.10.12.C.03", - "17.10.12.C.04" + "CPL-01.2": [ + "5.11-BP3" ], - "IAC-15.5": [ - "16.1.33.C.01", - "16.1.33.C.02", - "16.1.34.C.01" + "CPL-01.4": [ + "5.7-BP3", + "5.11-BP3", + "6.10" ], - "IAC-16": [ - "16.3.5.C.01", - "16.3.5.C.02", - "16.3.6.C.01", - "16.3.6.C.02", - "16.3.7.C.01", - "16.4.30.C.01", - "16.4.30.C.02", - "16.4.30.C.03", - "16.4.31.C.01", - "16.4.31.C.02", - "16.4.32.C.01", - "16.4.32.C.02", - "16.4.33.C.01", - "16.4.34.C.01", - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03", - "16.4.36.C.01", - "16.4.37.C.01" + "CPL-02": [ + "5.4", + "5.6", + "5.7-BP2" ], - "IAC-16.1": [ - "16.4.34.C.01" + "CPL-03": [ + "5.7", + "6.21", + "6.22" ], - "IAC-16.2": [ - "23.3.18.C.01" + "CPL-03.2": [ + "5.7-BP1" ], - "IAC-17": [ - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03" + "CFG-01": [ + "6.1-BP1" ], - "IAC-18": [ - "16.4.37.C.01" + "CFG-02": [ + "6.15-BP5" ], - "IAC-21": [ - "16.2.4.C.01", - "16.4.31.C.01", - "16.4.31.C.02", - "23.4.10.C.01" + "MON-01": [ + "6.21" ], - "IAC-22": [ - "16.1.46.C.01", - "16.1.46.C.02" + "MON-01.4": [ + "6.21-BP6" ], - "IAC-24": [ - "16.1.45.C.01", - "16.1.45.C.02" + "MON-01.8": [ + "6.21-BP5" ], - "IAC-25": [ - "16.1.44.C.01" + "MON-03": [ + "6.21-BP6" + ], + "MON-03.1": [ + "6.21-BP2" + ], + "MON-08": [ + "6.21-BP3" + ], + "MON-08.3": [ + "6.21-BP2" + ], + "MON-10": [ + "6.21-BP1" + ], + "MON-16": [ + "6.21-BP4" + ], + "CRY-01": [ + "6.22" + ], + "DCH-01": [ + "5.3-BP3" + ], + "DCH-01.2": [ + "6.13" + ], + "DCH-02": [ + "5.3-BP2", + "5.9-BP2", + "6.8" + ], + "DCH-03.1": [ + "5.9-BP3" + ], + "DCH-09": [ + "6.17" + ], + "DCH-09.1": [ + "6.17" + ], + "DCH-18": [ + "5.5" + ], + "END-04": [ + "6.12" + ], + "HRS-04": [ + "5.13" + ], + "HRS-11": [ + "6.6" + ], + "IAC-01": [ + "6.6" + ], + "IAC-08": [ + "6.6" + ], + "IAC-15": [ + "6.6" + ], + "IAC-21.3": [ + "6.6" + ], + "IAC-28.1": [ + "6.6" ], "IRO-01": [ - "7.1.7.C.01", - "7.1.7.C.02", - "7.1.7.C.03", - "7.2.18.C.01" + "5.3-BP3", + "6.1-BP4", + "6.3", + "6.4" ], "IRO-02": [ - "5.7.4.C.01", - "7.2.17.C.01", - "7.2.17.C.02", - "7.2.18.C.01", - "7.2.19.C.01", - "7.3.9.C.01", - "7.3.10.C.01" - ], - "IRO-02.5": [ - "7.3.10.C.01" + "6.4" ], - "IRO-03": [ - "7.2.17.C.01", - "7.2.17.C.02" + "IRO-02.4": [ + "6.4" ], "IRO-04": [ - "5.1.12.C.01", - "5.1.12.C.02", - "5.6.3.C.01", - "5.6.3.C.02", - "7.2.18.C.01", - "7.3.5.C.01", - "7.3.9.C.01", - "7.3.10.C.01", - "16.1.47.C.01" + "6.4" + ], + "IRO-06": [ + "6.4" ], "IRO-07": [ - "7.2.18.C.01" + "6.4" ], - "IRO-08": [ - "7.3.11.C.01" + "IRO-10": [ + "6.4" ], - "IRO-09": [ - "3.2.16.C.01", - "7.3.6.C.01", - "7.3.6.C.02" + "IRO-10.5": [ + "6.5", + "6.5(a)", + "6.5(b)", + "6.5(c)", + "6.5(d)", + "6.5(e)" ], - "IRO-10": [ - "7.2.18.C.01", - "7.2.20.C.01", - "7.2.21.C.01", - "7.2.23.C.01" + "IRO-13": [ + "6.4" ], - "IRO-10.2": [ - "7.2.18.C.01", - "7.2.20.C.01", - "7.2.21.C.01", - "7.2.23.C.01", - "7.3.8.C.03" + "IAO-01": [ + "6.15" ], - "IRO-10.4": [ - "7.2.22.C.01" + "IAO-02": [ + "6.15-BP2" ], - "IRO-11": [ - "7.3.12.C.01" + "MDM-01": [ + "6.11" ], - "IRO-11.2": [ - "7.3.10.C.01", - "7.3.11.C.01", - "7.3.12.C.01" + "NET-02": [ + "6.18" ], - "IRO-12": [ - "7.3.7.C.01", - "7.3.7.C.02", - "7.3.7.C.03", - "7.3.7.C.04", - "7.3.7.C.05", - "7.3.7.C.06", - "7.3.8.C.01", - "7.3.8.C.02", - "7.3.8.C.03" + "NET-02.1": [ + "6.19" ], - "IRO-12.4": [ - "7.3.8.C.01", - "7.3.8.C.02" + "NET-06": [ + "6.18" ], - "IRO-14": [ - "2.1.10.C.01" + "NET-08": [ + "6.18" ], - "IRO-15": [ - "15.2.21.C.01" + "NET-17": [ + "6.9" ], - "IAO-01": [ - "2.2.5.C.01", - "4.4.4.C.01", - "4.4.5.C.01", - "4.4.5.C.02", - "4.4.5.C.03", - "4.4.5.C.04", - "4.4.6.C.01", - "4.4.7.C.01", - "4.4.7.C.02", - "4.4.8.C.01", - "4.4.8.C.02", - "4.4.8.C.03", - "4.4.8.C.04", - "4.4.9.C.01", - "4.4.10.C.01", - "4.4.11.C.01", - "4.4.12.C.01", - "4.4.12.C.02", - "4.4.12.C.03", - "4.4.12.C.04", - "4.4.12.C.05" + "PRM-04": [ + "5.14" ], - "IAO-01.1": [ - "5.8.61.C.01", - "5.8.61.C.02", - "5.8.61.C.03" + "PRM-05": [ + "5.14" ], - "IAO-02": [ - "4.2.10.C.01", - "4.3.20.C.01", - "4.3.20.C.02", - "4.3.20.C.03", - "6.3.8.C.01" + "PRM-06": [ + "6.9" ], - "IAO-02.1": [ - "4.3.16.C.01" + "PRM-07": [ + "6.20" ], - "IAO-02.2": [ - "4.3.20.C.01", - "4.3.20.C.02", - "4.3.20.C.03" + "RSK-01": [ + "5.3", + "5.11-BP1" ], - "IAO-02.3": [ - "4.3.16.C.01", - "4.3.20.C.01", - "4.3.20.C.02", - "4.3.20.C.03", - "5.8.62.C.01" + "RSK-03": [ + "5.3-BP1", + "5.5-BP1" ], - "IAO-02.4": [ - "4.2.11.C.01", - "4.2.12.C.01", - "4.3.21.C.01", - "4.5.17.C.01", - "6.3.8.C.01" + "RSK-04": [ + "5.3-BP1", + "5.5", + "5.5-BP2", + "5.11", + "6.19", + "6.19-BP1", + "6.19-BP2", + "6.19-BP3" ], - "IAO-03": [ - "3.4.12.C.01", - "3.4.12.C.02", - "4.3.17.C.01", - "4.3.18.C.01", - "4.3.18.C.02", - "4.3.18.C.03", - "4.3.18.C.04", - "4.3.18.C.05", - "5.1.8.C.01", - "5.1.9.C.01", - "5.1.10.C.01", - "5.4.5.C.01", - "5.4.5.C.02", - "5.4.5.C.03" + "RSK-04.1": [ + "5.5-BP4" ], - "IAO-03.2": [ - "2.2.5.C.02" + "RSK-06": [ + "5.3-BP1", + "5.5-BP3" ], - "IAO-04": [ - "6.2.5.C.01", - "6.2.6.C.01" + "RSK-06.2": [ + "5.11-BP4" ], - "IAO-05": [ - "4.2.12.C.01", - "6.3.8.C.01" + "RSK-06.3": [ + "5.8" ], - "IAO-07": [ - "2.2.5.C.01", - "4.2.11.C.01", - "4.5.18.C.01", - "4.5.18.C.02", - "4.5.18.C.03", - "23.2.16.C.03", - "23.2.16.C.04" + "RSK-08": [ + "5.14", + "7.1-BP1" ], - "MNT-01": [ - "12.5.3.C.01", - "12.5.3.C.02", - "12.5.6.C.01", - "12.5.6.C.02" + "SEA-01": [ + "5.3-BP3" ], - "MNT-02": [ - "12.5.3.C.01", - "12.5.3.C.02", - "12.5.6.C.01", - "12.5.6.C.02" + "OPS-01.1": [ + "5.9-BP4" ], - "MNT-06.1": [ - "12.5.4.C.01", - "12.5.4.C.02", - "12.5.4.C.03", - "12.5.4.C.04" + "SAT-02": [ + "6.7" ], - "MNT-08": [ - "12.5.5.C.01" + "TDA-01": [ + "6.1-BP3" ], - "MNT-09": [ - "12.5.5.C.01" + "TDA-02.10": [ + "5.12" ], - "MDM-01": [ - "21.1.10.C.01", - "21.1.10.C.02", - "21.1.10.C.03", - "21.1.11.C.01", - "21.1.11.C.02", - "21.1.12.C.01", - "21.1.14.C.01", - "21.1.14.C.02", - "21.1.15.C.01", - "21.1.16.C.01", - "21.1.16.C.02", - "21.1.17.C.01", - "21.1.17.C.02", - "21.1.17.C.03", - "21.1.18.C.01", - "21.1.18.C.02", - "21.1.19.C.01", - "21.1.19.C.02" + "TDA-06": [ + "6.20" ], - "MDM-03": [ - "21.1.13.C.01", - "21.1.13.C.02", - "21.1.13.C.03", - "21.1.13.C.04", - "21.1.13.C.05" + "TDA-08": [ + "6.20-BP2", + "6.20-BP3" ], - "MDM-05": [ - "21.1.20.C.01", - "21.1.20.C.02", - "21.1.20.C.03" + "TDA-09": [ + "6.20-BP1" ], - "MDM-06": [ - "21.1.12.C.01" + "TDA-17": [ + "6.16" ], - "NET-01": [ - "10.8.34.C.01", - "10.8.34.C.02", - "10.8.35.C.01", - "10.8.36.C.01", - "10.8.37.C.01", - "10.8.38.C.01", - "18.1.9.C.01", - "18.1.9.C.02", - "18.1.9.C.03", - "18.1.9.C.04", - "18.1.9.C.05", - "18.5.7.C.01", - "18.5.7.C.02", - "18.5.8.C.01", - "18.5.8.C.02", - "18.5.8.C.03", - "18.5.8.C.04", - "18.5.9.C.01", - "18.5.9.C.02", - "18.5.9.C.03", - "18.5.10.C.01", - "18.5.10.C.02", - "18.5.11.C.01" + "TPM-01": [ + "5.10" ], - "NET-01.1": [ - "2.3.26.C.01", - "2.3.26.C.02" + "TPM-04.1": [ + "5.10" ], - "NET-02.1": [ - "18.3.18.C.01", - "18.3.19.C.01" + "TPM-05": [ + "5.10", + "5.11-BP2" ], - "NET-02.2": [ - "18.2.6.C.01" + "TPM-05.4": [ + "5.10" ], - "NET-02.3": [ - "19.2.15.C.01", - "19.2.16.C.01", - "19.2.16.C.02", - "19.2.17.C.01", - "19.2.17.C.02", - "19.2.18.C.01", - "19.2.19.C.01", - "19.2.19.C.02", - "19.2.20.C.01" + "THR-03": [ + "6.2" ], - "NET-03": [ - "19.1.10.C.01", - "19.1.11.C.01", - "19.1.11.C.02", - "19.1.12.C.01", - "19.1.13.C.01", - "19.1.14.C.01", - "19.1.14.C.02", - "19.1.15.C.01", - "19.1.16.C.01", - "19.1.16.C.02", - "19.1.17.C.01", - "19.1.17.C.02", - "19.1.18.C.01", - "19.1.18.C.02", - "19.1.19.C.01", - "19.1.19.C.02", - "19.1.19.C.03", - "19.1.19.C.04", - "19.1.19.C.05", - "19.1.20.C.01", - "19.1.20.C.02", - "19.1.20.C.03", - "19.1.21.C.01", - "19.1.22.C.01", - "19.1.22.C.02", - "19.1.22.C.03", - "19.1.23.C.01", - "19.3.8.C.01", - "19.3.8.C.02", - "19.3.8.C.03", - "19.3.8.C.04", - "19.3.9.C.01", - "19.3.9.C.02", - "19.3.9.C.03", - "19.4.4.C.01", - "19.4.5.C.01", - "19.4.5.C.02", - "19.4.5.C.03", - "19.4.6.C.01", - "19.5.24.C.01", - "19.5.24.C.02", - "19.5.24.C.03", - "19.5.24.C.04", - "19.5.24.C.05", - "19.5.24.C.06", - "19.5.24.C.07", - "19.5.24.C.08", - "19.5.25.C.01", - "19.5.26.C.01", - "19.5.26.C.02", - "19.5.26.C.03", - "19.5.26.C.04", - "19.5.26.C.05", - "19.5.26.C.06", - "19.5.26.C.07", - "19.5.26.C.08", - "19.5.26.C.09", - "19.5.26.C.10", - "19.5.26.C.11", - "19.5.26.C.12", - "19.5.27.C.01", - "19.5.27.C.02", - "19.5.27.C.03", - "19.5.27.C.04", - "19.5.27.C.05", - "19.5.27.C.06", - "19.5.28.C.01", - "19.5.28.C.02", - "19.5.28.C.03", - "19.5.28.C.04", - "19.5.28.C.05", - "19.5.28.C.06", - "19.5.28.C.07", - "19.5.29.C.01" - ], - "NET-03.8": [ - "14.1.11.C.01" + "VPM-05": [ + "6.16" ], - "NET-04": [ - "18.1.13.C.01", - "18.1.13.C.02", - "18.1.14.C.01" + "VPM-06.7": [ + "6.15-BP3" ], - "NET-04.1": [ - "18.1.13.C.01", - "18.1.13.C.02", - "18.1.14.C.01" + "VPM-06.8": [ + "6.15-BP4" ], - "NET-05.1": [ - "14.1.13.C.01", - "14.1.13.C.02", - "14.1.13.C.03" + "VPM-07": [ + "6.15-BP1" ], - "NET-06.2": [ - "22.3.9.C.01", - "22.3.9.C.02", - "22.3.9.C.03", - "22.3.9.C.04", - "22.3.10.C.01", - "22.3.11.C.01", - "22.3.11.C.02" + "WEB-02": [ + "6.18" + ] + }, + "americas-bra-lgpd-2018": { + "CPL-01": [ + "VII.I.46.2" ], - "NET-08.1": [ - "19.1.14.C.01", - "19.1.14.C.02" + "IRO-10": [ + "VII.I.48", + "VII.I.48.1", + "VII.I.48.1.I", + "VII.I.48.1.II", + "VII.I.48.1.III", + "VII.I.48.1.IV", + "VII.I.48.1.V", + "VII.I.48.1.VI" ], - "NET-08.2": [ - "21.4.12.C.01", - "21.4.12.C.02", - "21.4.12.C.03" + "PRI-01.4": [ + "VI.II.41", + "VI.II.41.1", + "VI.II.41.2", + "VI.II.41.2.I", + "VI.II.41.2.II", + "VI.II.41.2.III", + "VI.II.41.2.IV", + "VI.II.41.3" ], - "NET-10": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" + "PRI-01.5": [ + "V.33", + "V.33.I", + "V.33.II", + "V.33.II(a)", + "V.33.II(b)", + "V.33.II(c)", + "V.33.II(d)", + "V.33.III", + "V.33.IV", + "V.33.V", + "V.33.VI", + "V.33.VII", + "V.33.VIII", + "V.33.IX", + "V.34", + "V.34.I", + "V.34.II", + "V.34.III", + "V.34.IV", + "V.34.V", + "V.34.VI" ], - "NET-10.1": [ - "15.2.22.C.01" + "PRI-01.6": [ + "VII.I.46", + "VII.I.46.1", + "VII.I.47", + "VII.I.49", + "VII.II.50", + "VII.II.50.1", + "VII.II.50.2", + "VII.II.50.2.I", + "VII.II.50.2.I(a)", + "VII.II.50.2.I(b)", + "VII.II.50.2.I(c)", + "VII.II.50.2.I(d)", + "VII.II.50.2.I(e)", + "VII.II.50.2.I(f)", + "VII.II.50.2.I(g)", + "VII.II.50.2.I(h)", + "VII.II.50.2.II" ], - "NET-10.3": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" + "PRI-01.11": [ + "II.I.10", + "II.I.10.I", + "II.I.10.II", + "II.I.10.II.1", + "II.I.10.II.2", + "II.II.11.I", + "II.II.11.II", + "II.II.11.II(a)", + "II.II.11.II(b)", + "II.II.11.II(c)", + "II.II.11.II(d)", + "II.II.11.II(e)", + "II.II.11.II(f)", + "II.II.11.II(g)", + "II.II.11.II(g)1", + "II.II.11.II(g)2", + "II.II.11.II(g)3", + "II.II.11.II(g)4", + "III.21" ], - "NET-13": [ - "15.1.7.C.01", - "15.1.8.C.01", - "15.1.8.C.02", - "15.1.9.C.01", - "15.1.10.C.01", - "15.1.10.C.02", - "15.1.10.C.03", - "15.1.11.C.01", - "15.1.11.C.02", - "15.1.11.C.03", - "15.1.12.C.01", - "15.1.13.C.01", - "15.1.14.C.01", - "15.1.15.C.01", - "15.1.16.C.01", - "15.1.17.C.01", - "15.1.18.C.01", - "15.1.19.C.01", - "15.1.19.C.02", - "15.1.20.C.01", - "15.2.25.C.01", - "15.2.25.C.02", - "15.2.26.C.01", - "15.2.27.C.01", - "15.2.28.C.01", - "15.2.29.C.01", - "15.2.30.C.01", - "15.2.30.C.02", - "15.2.30.C.03", - "15.2.31.C.01", - "15.2.31.C.02", - "15.2.32.C.01", - "15.2.32.C.02", - "15.2.32.C.03", - "15.2.33.C.01", - "15.2.33.C.02", - "15.2.33.C.03", - "15.2.33.C.04", - "16.7.33.C.01", - "17.6.6.C.01", - "17.6.7.C.01" + "PRI-02": [ + "II.I.9", + "II.I.9.I", + "II.I.9.II", + "II.I.9.III", + "II.I.9.IV", + "II.I.9.V", + "II.I.9.VI", + "II.I.9.VII", + "II.I.9.VII.1" ], - "NET-14": [ - "16.5.10.C.01", - "16.5.10.C.02", - "16.5.11.C.01", - "16.5.11.C.02", - "16.5.12.C.01", - "17.5.6.C.01", - "17.5.7.C.01", - "17.5.7.C.02", - "17.5.8.C.01", - "17.5.8.C.02", - "17.5.8.C.03", - "17.5.9.C.01", - "17.5.10.C.01" + "PRI-02.8": [ + "II.IV.15.I" ], - "NET-14.4": [ - "16.5.11.C.01", - "16.5.11.C.02" + "PRI-03": [ + "II.I.7.I", + "II.I.8", + "II.I.8.1", + "II.I.8.2", + "II.I.8.3", + "II.I.8.4" ], - "NET-14.5": [ - "21.2.4.C.01", - "21.2.4.C.02", - "21.2.5.C.01", - "21.2.6.C.01", - "21.2.7.C.01", - "21.2.7.C.02", - "21.3.5.C.01", - "21.3.6.C.01" + "PRI-03.1": [ + "II.I.9.VII.3" ], - "NET-15": [ - "18.2.5.C.01", - "18.2.5.C.02", - "18.2.6.C.01", - "18.2.7.C.01", - "18.2.8.C.01", - "18.2.25.C.01", - "18.2.26.C.01", - "18.2.27.C.01", - "18.2.28.C.01", - "18.2.28.C.02", - "18.2.29.C.01", - "18.2.29.C.02", - "18.2.29.C.03", - "18.2.30.C.01", - "18.2.31.C.01", - "18.2.32.C.01", - "18.2.34.C.01" + "PRI-03.2": [ + "II.I.8.6", + "II.I.9.VII.2" ], - "NET-15.1": [ - "18.2.10.C.01", - "18.2.10.C.02", - "18.2.11.C.01", - "18.2.11.C.02", - "18.2.11.C.03", - "18.2.11.C.04", - "18.2.11.C.05", - "18.2.12.C.01", - "18.2.12.C.02", - "18.2.13.C.01", - "18.2.14.C.01", - "18.2.15.C.01", - "18.2.16.C.01", - "18.2.17.C.01", - "18.2.18.C.01", - "18.2.19.C.01", - "18.2.20.C.01", - "18.2.20.C.02", - "18.2.20.C.03", - "18.2.21.C.01", - "18.2.22.C.01", - "18.2.23.C.01", - "18.2.23.C.02", - "18.2.24.C.01", - "18.2.25.C.01" + "PRI-03.4": [ + "II.I.8.5", + "II.IV.15.III" ], - "NET-15.2": [ - "21.1.16.C.01", - "21.1.16.C.02" + "PRI-03.10": [ + "II.IV.15.II", + "II.IV.15.IV" ], - "NET-15.4": [ - "18.2.33.C.01" + "PRI-03.13": [ + "II.III.14", + "II.III.14.1", + "II.III.14.2", + "II.III.14.3", + "II.III.14.4", + "II.III.14.5", + "II.III.14.6" ], - "NET-18": [ - "9.3.6.C.01", - "14.3.6.C.01", - "14.3.6.C.02", - "14.3.6.C.03", - "14.3.10.C.01", - "14.3.10.C.02", - "14.3.10.C.03", - "14.3.10.C.04", - "14.3.11.C.01", - "14.3.11.C.02", - "14.3.12.C.01", - "20.3.4.C.01", - "20.3.4.C.02", - "20.3.5.C.01", - "20.3.5.C.02", - "20.3.6.C.01", - "20.3.7.C.01", - "20.3.7.C.02", - "20.3.8.C.01", - "20.3.9.C.01", - "20.3.10.C.01", - "20.3.11.C.01", - "20.3.11.C.02", - "20.3.11.C.03", - "20.3.12.C.01", - "20.3.12.C.02", - "20.3.13.C.01", - "20.3.13.C.02", - "20.3.14.C.01", - "20.3.15.C.01", - "20.3.15.C.02", - "20.3.16.C.01" + "PRI-05": [ + "II.IV.16", + "II.IV.16.I", + "II.IV.16.II", + "II.IV.16.III", + "II.IV.16.IV" ], - "NET-18.1": [ - "14.3.6.C.01", - "14.3.6.C.02", - "14.3.6.C.03" + "PRI-05.1": [ + "II.I.7.IV" ], - "NET-18.2": [ - "14.3.8.C.01", - "14.3.9.C.01", - "20.3.14.C.01" + "PRI-05.3": [ + "II.II.13", + "II.II.13.1", + "II.II.13.2", + "II.II.13.3", + "II.II.13.4" ], - "PES-01": [ - "5.7.4.C.01", - "8.1.10.C.01" + "PRI-05.4": [ + "II.I.7.II", + "II.I.7.III", + "II.I.7.V", + "II.I.7.VI", + "II.I.7.VII", + "II.I.7.VIII", + "II.I.7.IX", + "II.I.7.X", + "II.I.7.X.1", + "II.I.7.X.2", + "II.I.7.X.3", + "II.I.7.X.4", + "II.I.7.X.5", + "II.I.7.X.6" ], - "PES-01.1": [ - "8.2.7.C.01" + "PRI-06": [ + "III.18", + "III.18.I", + "III.18.II", + "III.18.III", + "III.18.IV", + "III.18.V", + "III.18.VI", + "III.18.VII", + "III.18.VIII", + "III.18.IX", + "III.18.IX.1", + "III.18.IX.2", + "III.18.IX.3", + "III.18.IX.4" ], - "PES-02": [ - "8.1.11.C.01", - "8.1.11.C.02" + "PRI-06.4": [ + "III.18.IX.4.I", + "III.18.IX.4.II", + "III.18.IX.5" ], - "PES-02.2": [ - "8.2.8.C.01" + "PRI-06.6": [ + "III.18.IX.7", + "III.19", + "III.19.II", + "III.19.II.1", + "III.19.II.2", + "III.19.II.2.I", + "III.19.II.2.II", + "III.19.II.3" ], - "PES-03.2": [ - "8.2.5.C.01" + "PRI-06.7": [ + "III.19.I" ], - "PES-03.4": [ - "8.3.3.C.01", - "8.3.4.C.01", - "8.3.4.C.02", - "8.3.5.C.01" + "PRI-07": [ + "V.33" ], - "PES-04": [ - "8.2.6.C.01", - "8.2.6.C.02" + "PRI-07.1": [ + "VI.I.39" ], - "PES-04.2": [ - "8.1.12.C.01", - "8.1.13.C.01", - "8.1.13.C.02" + "PRI-07.3": [ + "III.18.IX.6" ], - "PES-06": [ - "9.4.4.C.01", - "9.4.5.C.01", - "9.4.5.C.02", - "9.4.6.C.01", - "9.4.6.C.02", - "9.4.7.C.01", - "9.4.8.C.01", - "9.4.9.C.01", - "9.4.10.C.01" + "PRI-14": [ + "VI.I.37" ], - "PES-06.3": [ - "9.4.7.C.01" + "PRI-19": [ + "III.20" ], - "PES-06.4": [ - "9.4.9.C.01" + "PRI-19.3": [ + "III.20", + "III.20.1" ], - "PES-06.5": [ - "9.4.9.C.01" + "RSK-10": [ + "II.I.10.II.3" + ] + }, + "americas-can-osfi-self-assessment": {}, + "americas-can-osfi-b13-2022": { + "GOV-01": [ + "1", + "1.1.2", + "1.3.1", + "2.1.1", + "3" ], - "PES-07": [ - "8.3.3.C.01", - "8.3.4.C.01", - "8.3.4.C.02", - "8.3.5.C.01" + "GOV-01.1": [ + "1", + "1.1.2", + "1.3.1" ], - "PES-12": [ - "8.3.3.C.01", - "8.3.4.C.01", - "8.3.4.C.02", - "8.3.5.C.01" + "GOV-01.2": [ + "1", + "1.1.2" ], - "PES-12.1": [ - "8.3.3.C.01", - "8.3.3.C.02", - "8.3.4.C.01", - "8.3.4.C.02", - "8.3.5.C.01", - "10.1.42.C.01", - "10.1.42.C.02", - "10.1.43.C.01", - "10.1.43.C.02", - "10.1.43.C.03", - "10.1.43.C.04", - "10.1.44.C.01", - "10.1.45.C.01", - "10.1.45.C.02", - "10.1.46.C.01", - "10.1.46.C.02", - "10.1.46.C.03", - "10.1.46.C.04", - "10.1.47.C.01", - "10.1.47.C.02", - "10.1.48.C.01", - "10.1.48.C.02", - "10.1.48.C.03", - "10.1.49.C.01", - "10.1.50.C.01", - "10.1.50.C.02", - "10.1.50.C.03", - "10.1.50.C.04", - "10.1.51.C.01", - "10.2.6.C.01", - "10.2.6.C.02", - "10.2.7.C.01", - "10.2.8.C.01", - "10.2.9.C.01", - "10.2.10.C.01", - "10.3.5.C.01", - "10.3.6.C.01", - "10.3.6.C.02", - "10.3.7.C.01", - "10.3.8.C.01", - "10.3.9.C.01", - "10.3.10.C.01", - "10.3.11.C.01", - "10.3.12.C.01", - "10.3.13.C.01", - "10.4.4.C.01", - "10.4.4.C.02", - "10.4.5.C.01", - "10.4.5.C.02", - "10.4.6.C.01", - "10.4.6.C.02", - "10.4.6.C.03", - "10.4.7.C.01", - "10.4.7.C.02", - "10.4.8.C.01", - "10.4.9.C.01", - "10.4.9.C.02", - "10.4.9.C.03", - "10.4.9.C.04", - "10.4.10.C.01", - "10.4.11.C.01", - "10.4.12.C.01", - "10.4.13.C.01", - "10.4.13.C.02", - "10.5.4.C.01", - "10.5.5.C.01", - "10.5.6.C.01", - "10.5.6.C.02", - "10.5.7.C.01", - "10.5.8.C.01", - "10.5.8.C.02", - "10.5.9.C.01", - "10.5.9.C.02", - "10.5.10.C.01", - "10.5.10.C.02", - "10.5.11.C.01", - "10.6.22.C.01", - "10.6.22.C.02", - "10.6.23.C.01", - "10.6.23.C.02", - "10.6.23.C.03", - "10.6.23.C.04", - "10.6.24.C.01", - "10.6.24.C.02", - "10.6.25.C.01", - "10.6.26.C.01", - "10.6.27.C.01", - "10.6.28.C.01", - "10.6.28.C.02", - "10.6.29.C.01", - "10.6.30.C.01", - "10.6.31.C.01" + "GOV-02": [ + "1", + "3" ], - "PES-13": [ - "10.7.6.C.01", - "10.7.6.C.02", - "10.7.7.C.01", - "10.7.7.C.02", - "10.7.8.C.01", - "10.7.9.C.01" + "GOV-03": [ + "1", + "1.3.1" ], - "PRI-07": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" + "GOV-04": [ + "1", + "1.1", + "1.1.1", + "1.1.2" ], - "PRM-01": [ - "3.2.15.C.01" + "GOV-04.1": [ + "1", + "1.1", + "1.1.1", + "1.1.2" ], - "PRM-01.1": [ - "2.3.25.C.01", - "2.3.25.C.02", - "2.3.29.C.01" + "GOV-04.2": [ + "1", + "1.1.2" ], - "PRM-02": [ - "3.2.15.C.01" + "GOV-05": [ + "1", + "1.2", + "2.8.1" ], - "PRM-05": [ - "12.1.30.C.01", - "12.1.30.C.02", - "12.1.30.C.03", - "12.1.32.C.01", - "12.1.32.C.02", - "12.1.32.C.03" + "GOV-05.1": [ + "2.8.1" ], - "PRM-06": [ - "12.1.32.C.01", - "12.1.32.C.02", - "12.1.32.C.03" + "GOV-08": [ + "1.2", + "2.1.1" ], - "PRM-08": [ - "3.2.19.C.01" + "GOV-09": [ + "1.2", + "2.1.1" ], - "RSK-01": [ - "5.1.9.C.01", - "5.3.6.C.01", - "5.3.7.C.01", - "5.3.8.C.01", - "5.3.9.C.01" + "GOV-14": [ + "1.1.1", + "3.2.1" ], - "RSK-01.1": [ - "23.2.16.C.01", - "23.2.17.C.01" + "GOV-15": [ + "1.1.1", + "2.1.1", + "3.2.1" ], - "RSK-02.1": [ - "23.2.16.C.01", - "23.2.17.C.01" + "GOV-15.1": [ + "1.1.1", + "2.1.1" ], - "RSK-03": [ - "2.4.13.C.01", - "2.4.13.C.02", - "2.4.13.C.03", - "2.4.13.C.04", - "2.4.13.C.05", - "2.4.13.C.06", - "2.4.13.C.07" + "GOV-15.2": [ + "1.1.1", + "2.1.1" ], - "RSK-04": [ - "2.3.27.C.01", - "2.3.27.C.02", - "5.9.23.C.01", - "23.2.16.C.02" + "GOV-15.3": [ + "1.1.1", + "2.1.1" ], - "RSK-06.2": [ - "12.4.5.C.01" + "GOV-15.4": [ + "1.1.1", + "2.1.1" ], - "RSK-09": [ - "2.2.7.C.01", - "12.7.14.C.01", - "12.7.14.C.02", - "12.7.14.C.03", - "12.7.15.C.01", - "12.7.15.C.02", - "12.7.16.C.01", - "12.7.16.C.02", - "12.7.16.C.03", - "12.7.17.C.01", - "12.7.18.C.01", - "12.7.18.C.02", - "12.7.19.C.01", - "12.7.19.C.02", - "12.7.20.C.01", - "12.7.20.C.02", - "12.7.20.C.03", - "12.7.20.C.04", - "12.7.20.C.05", - "12.7.21.C.01" + "GOV-15.5": [ + "1.1.1", + "2.1.1" ], - "SEA-01": [ - "1.2.13.C.01", - "1.2.13.C.02" + "AST-01": [ + "2.2", + "2.2.1", + "2.2.2", + "2.9.2" ], - "SEA-01.1": [ - "4.3.19.C.01" + "AST-01.1": [ + "2.2", + "2.2.2", + "2.9.2" ], - "SEA-02": [ - "1.2.13.C.01", - "1.2.13.C.02" + "AST-02": [ + "2.2", + "2.2.2", + "2.2.3" ], - "SEA-03": [ - "1.2.13.C.01", - "1.2.13.C.02" + "AST-02.9": [ + "2.2.3" ], - "SEA-13.1": [ - "22.2.12.C.01", - "22.2.12.C.02", - "22.2.12.C.03", - "22.2.12.C.04", - "22.2.13.C.01", - "22.2.13.C.02", - "22.2.14.C.01", - "22.2.14.C.02", - "22.2.14.C.03", - "22.2.14.C.04", - "22.2.14.C.05", - "22.2.14.C.06", - "22.2.14.C.07", - "22.2.15.C.01", - "22.2.15.C.02", - "22.2.15.C.03", - "22.2.15.C.04", - "22.2.15.C.05", - "22.2.15.C.06", - "22.2.15.C.07", - "22.2.16.C.01", - "22.2.16.C.02", - "22.2.16.C.03" + "AST-09": [ + "2.2", + "2.2.4" ], - "SEA-18": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" + "BCD-01": [ + "2.9", + "2.9.1" ], - "SEA-18.1": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" + "BCD-01.4": [ + "2.9", + "2.9.1" ], - "SEA-18.2": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" + "BCD-01.5": [ + "2.9.1" ], - "SEA-19": [ - "16.1.49.C.01", - "16.1.50.C.01", - "16.1.50.C.02" + "BCD-02": [ + "2.2.2", + "2.9.2" ], - "OPS-01.1": [ - "3.4.12.C.01", - "3.4.12.C.02", - "5.1.11.C.01", - "5.1.13.C.01", - "5.5.3.C.01", - "5.5.4.C.01", - "5.5.5.C.01", - "5.5.6.C.01" + "BCD-04": [ + "2.9.3" ], - "OPS-02": [ - "5.1.15.C.01" + "BCD-11": [ + "2.9.1" ], - "SAT-01": [ - "9.1.4.C.01" + "CAP-01": [ + "2", + "2.8.2" ], - "SAT-02": [ - "9.1.5.C.01", - "9.1.5.C.02", - "9.1.6.C.01", - "9.1.6.C.02" + "CAP-03": [ + "2.8.2" ], - "SAT-03": [ - "9.1.6.C.01", - "9.1.6.C.02", - "9.1.6.C.03" + "CAP-04": [ + "2.8.2" ], - "TDA-01.1": [ - "12.1.31.C.01", - "12.1.32.C.01", - "12.1.32.C.02", - "12.1.32.C.03", - "12.1.33.C.01", - "12.1.34.C.01", - "12.1.34.C.02", - "12.1.35.C.01", - "12.1.36.C.01", - "12.1.37.C.01", - "12.4.3.C.01", - "12.4.4.C.01", - "12.4.4.C.02", - "12.4.4.C.03", - "12.4.4.C.04", - "12.4.4.C.05", - "12.4.4.C.06", - "12.4.5.C.01", - "12.4.6.C.01", - "12.4.7.C.01" + "CHG-01": [ + "2.5", + "2.5.1" ], - "TDA-02.1": [ - "18.1.15.C.01", - "18.1.15.C.02", - "18.1.15.C.03", - "18.1.15.C.04" + "CHG-02": [ + "2.5", + "2.5.1", + "2.5.3" ], - "TDA-04": [ - "3.4.10.C.01", - "3.4.10.C.02" + "CHG-02.1": [ + "2.5", + "2.5.1" ], - "TDA-06": [ - "14.4.5.C.01" + "CHG-02.2": [ + "2.5.1" ], - "TDA-06.1": [ - "14.4.6.C.01", - "14.4.6.C.02", - "14.4.6.C.03" + "CHG-04": [ + "2.5", + "2.5.2" ], - "TDA-06.2": [ - "14.4.6.C.01", - "14.4.6.C.02", - "14.4.6.C.03" + "CHG-04.4": [ + "2.5", + "2.5.2" ], - "TDA-07": [ - "14.4.4.C.01" + "CPL-01": [ + "1.3.1" ], - "TDA-09.4": [ - "14.5.6.C.01" + "CPL-01.1": [ + "1.3.1" ], - "TDA-09.5": [ - "14.5.6.C.01" + "CPL-01.2": [ + "1.3.1" ], - "TDA-17": [ - "12.4.7.C.01" + "CFG-01": [ + "3.2.8" ], - "TPM-01": [ - "2.2.6.C.01", - "2.2.6.C.02", - "23.2.19.C.01" + "CFG-02": [ + "3.2.8" ], - "TPM-02": [ - "12.7.17.C.01" + "CFG-02.5": [ + "3.2.3" ], - "TPM-03": [ - "12.7.14.C.01", - "12.7.14.C.02", - "12.7.14.C.03", - "12.7.15.C.01", - "12.7.15.C.02", - "12.7.16.C.01", - "12.7.16.C.02", - "12.7.16.C.03", - "12.7.17.C.01", - "12.7.18.C.01", - "12.7.18.C.02", - "12.7.19.C.01", - "12.7.19.C.02", - "12.7.20.C.01", - "12.7.20.C.02", - "12.7.20.C.03", - "12.7.20.C.04", - "12.7.20.C.05", - "12.7.21.C.01" + "CFG-03": [ + "3.2.8" ], - "TPM-05": [ - "2.3.30.C.01", - "23.2.19.C.01" + "MON-01": [ + "3.3", + "3.3.1", + "3.3.2" ], - "TPM-05.1": [ - "7.2.22.C.01", - "7.2.23.C.01" + "MON-01.1": [ + "3.3.2" ], - "THR-06": [ - "5.9.23.C.01", - "5.9.24.C.01", - "5.9.24.C.02", - "5.9.25.C.01", - "5.9.26.C.01", - "5.9.26.C.02", - "5.9.27.C.01" + "MON-01.2": [ + "3.3.1" ], - "VPM-01": [ - "6.2.4.C.01" + "MON-01.8": [ + "3.3.1" ], - "VPM-01.1": [ - "6.2.4.C.01" + "MON-02": [ + "3.3.1" ], - "VPM-02": [ - "6.2.6.C.01", - "23.2.19.C.01" + "MON-02.1": [ + "3.3.1" ], - "VPM-04": [ - "6.2.6.C.01", - "23.2.19.C.01" + "MON-02.2": [ + "3.3.1", + "3.3.2" ], - "VPM-05": [ - "23.2.19.C.01" + "MON-02.7": [ + "3.3.1" ], - "VPM-06": [ - "6.2.5.C.01" + "MON-03": [ + "3.2.7", + "3.3.1" ], - "VPM-06.8": [ - "14.1.14.C.01" + "MON-11.3": [ + "3.3.2" ], - "VPM-08": [ - "8.1.13.C.01", - "8.1.13.C.02" + "MON-16": [ + "3.3.2" ], - "WEB-01": [ - "14.5.6.C.01", - "14.5.7.C.01", - "14.5.8.C.01" + "CRY-01": [ + "3.2.2" ], - "WEB-07": [ - "14.5.7.C.01", - "14.5.8.C.01" + "CRY-09": [ + "3.2.2" ], - "WEB-08": [ - "14.5.7.C.01", - "14.5.8.C.01" - ] - }, - "apac-nzl-privacy-act-2020": { - "DCH-22.1": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" + "DCH-01": [ + "2.9.2", + "3.1.4" ], - "DCH-25": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "DCH-01.2": [ + "2.9.2", + "3.1.4" ], - "IAC-02": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" + "DCH-02": [ + "2.2.2", + "3.1.4" ], - "IAC-03": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" + "DCH-06.2": [ + "2.2.2", + "3.1.4" ], - "IAC-09.2": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" + "DCH-19": [ + "2.9.2", + "3.1.4" ], - "IAO-03.2": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "HRS-11": [ + "2.5.2" ], - "PRI-01.5": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "IAC-01": [ + "3.2.7" ], - "PRI-01.6": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "IAC-06": [ + "3.2.7" ], - "PRI-01.7": [ - "Principle 11", - "P11-(1)", - "P11-(1)(a)", - "P11-(1)(b)", - "P11-(1)(c)", - "P11-(1)(d)", - "P11-(1)(e)(i)", - "P11-(1)(e)(ii)", - "P11-(1)(e)(iii)", - "P11-(1)(e)(iv)", - "P11-(1)(f)(i)", - "P11-(1)(f)(ii)", - "P11-(1)(g)", - "P11-(1)(h)(i)", - "P11-(1)(h)(ii)", - "P11-(1)(i)", - "P11-(2)", - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "IAC-16": [ + "3.2.7" ], - "PRI-02": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" + "IAC-21": [ + "3.2.7" ], - "PRI-02.1": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" + "IRO-01": [ + "2.7", + "2.7.2", + "3.3", + "3.4.1" ], - "PRI-04": [ - "Principle 1", - "P1-(1)(a)", - "P1-(1)(b)", - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)", - "Principle 4", - "P4-(a)", - "P4-(b)", - "P4-(b)(i)", - "P4-(b)(ii)" + "IRO-02": [ + "2.7", + "2.7.1", + "2.7.2", + "3.3", + "3.3.3", + "3.4.1", + "3.4.3", + "3.4.4" ], - "PRI-04.2": [ - "Principle 2", - "P2-(1)", - "P2-(2)", - "P2-(2)(a)", - "P2-(2)(b)", - "P2-(2)(c)", - "P2-(2)(d)", - "P2-(2)(e)(i)", - "P2-(2)(e)(ii)", - "P2-(2)(e)(iii)", - "P2-(2)(e)(iv)", - "P2-(2)(e)(v)", - "P2-(2)(f)", - "P2-(2)(g)(i)", - "P2-(2)(g)(ii)" + "IRO-02.4": [ + "2.7", + "3.4.2" ], - "PRI-05.1": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "IRO-03": [ + "2.7.2", + "3.1" ], - "PRI-05.2": [ - "Principle 9" + "IRO-04": [ + "2.7.1", + "2.7.2", + "3.4.3" ], - "PRI-05.4": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "IRO-04.2": [ + "2.7.3" ], - "PRI-06": [ - "Principle 6", - "P6-(1)", - "P6-(1)(a)", - "P6-(1)(b)", - "P6-(2)", - "P6-(3)" + "IRO-06": [ + "2.7.2" ], - "PRI-06.1": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" + "IRO-06.1": [ + "3.4.1" ], - "PRI-06.2": [ - "P6-(2)" + "IRO-07": [ + "2.7.2", + "3.3.3", + "3.4.4" ], - "PRI-07.1": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" - ] - }, - "apac-phl-dpa-2012": { - "GOV-01": [ - "25", - "27", - "28" + "IRO-08": [ + "3.4.5" ], - "CPL-01": [ - "25" + "IRO-09": [ + "2.7" ], - "CPL-02": [ - "25", - "29" + "IRO-10": [ + "3.4.1" ], - "CPL-03": [ - "25" + "IRO-13": [ + "2.7.3", + "3.4", + "3.4.5" ], - "DCH-01": [ - "25" + "IAO-01": [ + "2.4.4" ], - "DCH-22.1": [ - "34" + "IAO-01.1": [ + "2.4.4" ], - "DCH-24": [ - "25" + "IAO-02": [ + "2.4.4" ], - "DCH-24.1": [ - "25" + "NET-02": [ + "3.2.4" ], - "IRO-04.1": [ - "38" + "NET-06": [ + "3.2.5" ], - "PRI-01": [ - "Inferred", - "Expectation" + "NET-17": [ + "3.2.5" ], - "PRI-02.1": [ - "19" + "PES-01": [ + "3.2.10" ], - "PRI-03": [ - "19" + "PES-03": [ + "3.2.10" ], - "PRI-04": [ - "19" + "PRM-01": [ + "1.2.1" ], - "PRI-04.1": [ - "19" + "PRM-01.1": [ + "1.2.1" ], - "PRI-05": [ - "19", - "21" + "PRM-01.2": [ + "1.2.1" ], - "PRI-05.1": [ - "19" + "PRM-02": [ + "1.2.1" ], - "PRI-05.4": [ - "19", - "22", - "34" + "PRM-03": [ + "1.2.1" ], - "PRI-06": [ - "34" + "PRM-04": [ + "1.2.1", + "2.3", + "2.3.1", + "2.4.1" ], - "PRI-06.1": [ - "34" + "PRM-05": [ + "1.2.1", + "2.3", + "2.4.1", + "2.4.2", + "2.4.3", + "2.8" ], - "PRI-06.2": [ - "34" + "PRM-06": [ + "1.2.1", + "2.1", + "2.3", + "2.4.1", + "2.4.3", + "2.8" ], - "PRI-06.3": [ - "34" + "PRM-07": [ + "2.4", + "2.4.1", + "2.4.3" ], - "PRI-14.1": [ - "20" + "RSK-01": [ + "1.3", + "1.3.1", + "1.3.2", + "3.1.1" ], - "PRI-15": [ - "46", - "47", - "48" + "RSK-01.1": [ + "1.3", + "3.1.8" ], - "SEA-01": [ - "25", - "29" + "RSK-01.3": [ + "3.1.8" ], - "SEA-02": [ - "25", - "29" + "RSK-01.4": [ + "3.1.8" ], - "SEA-03": [ - "25", - "29" + "RSK-01.5": [ + "1.3", + "3.1.8" ], - "SEA-15": [ - "25" + "RSK-03": [ + "1.3", + "3.1.1" ], - "TPM-03": [ - "25", - "43" + "RSK-03.1": [ + "3.1.1" ], - "TPM-04.4": [ - "25" + "RSK-04": [ + "1.3", + "3.1.1" ], - "TPM-05": [ - "25", - "43" - ] - }, - "apac-sgp-pdpa-2012": { - "GOV-01": [ - "12", - "24" + "RSK-04.1": [ + "1.3", + "3.1.1" ], - "CPL-01": [ - "24" + "RSK-06.2": [ + "3.2.6" ], - "CPL-02": [ - "24" + "SEA-01": [ + "1.3.1", + "2", + "2.1", + "2.1.2", + "3.2", + "3.2.1" ], - "CPL-03": [ - "24" + "SEA-01.1": [ + "1.3.1" ], - "DCH-01": [ - "24", - "26" + "SEA-01.2": [ + "2", + "2.1.2", + "3.2.1" ], - "DCH-22.1": [ - "22" + "SEA-02": [ + "2", + "2.1", + "2.1.2" ], - "DCH-24": [ - "24", - "26" + "SEA-02.1": [ + "A.1" ], - "DCH-24.1": [ - "24", - "26" + "SEA-03": [ + "3.2", + "3.2.4" ], - "DCH-25": [ - "24", - "26" + "SEA-07.1": [ + "1.3.1", + "2.2", + "2.2.5" ], - "IRO-14": [ - "11" + "OPS-01": [ + "3" ], - "PRI-01": [ - "12" + "OPS-01.1": [ + "2.2.1", + "2.8", + "3" ], - "PRI-01.1": [ - "11" + "OPS-02": [ + "1.3.2" ], - "PRI-02": [ - "14" + "OPS-03": [ + "2.2.1", + "2.8" ], - "PRI-02.1": [ - "14", - "19", - "20" + "SAT-01": [ + "3.1.7" ], - "PRI-03": [ - "13" + "SAT-02": [ + "3.1.7" ], - "PRI-04": [ - "17" + "SAT-03": [ + "3.1.7" ], - "PRI-04.1": [ - "17" + "SAT-03.1": [ + "3.1.7" ], - "PRI-05": [ - "23", - "25" + "SAT-03.2": [ + "3.1.7" ], - "PRI-05.2": [ - "23" + "TDA-01": [ + "2.4.3" ], - "PRI-05.4": [ - "14" + "TDA-01.1": [ + "2.4.3" ], - "PRI-06": [ - "21" + "TDA-02.3": [ + "2.4.3", + "2.4.5" ], - "PRI-06.1": [ - "22" + "TDA-06": [ + "2.4.5" ], - "PRI-06.2": [ - "23" + "TDA-06.1": [ + "2.4.5" ], - "PRI-07": [ - "26" + "TDA-06.2": [ + "2.4.4", + "3.1.6" ], - "PRI-15": [ - "39" + "TDA-06.5": [ + "2.4.1", + "2.4.2" ], - "SEA-01": [ - "24", - "26" + "TDA-09": [ + "3.2.9" ], - "SEA-02": [ - "24", - "26" + "TDA-09.2": [ + "3.2.9" ], - "SEA-03": [ - "24", - "26" + "TDA-09.3": [ + "3.2.9" ], - "SEA-15": [ - "24", - "26" + "TDA-17": [ + "2.2.5" ], - "TPM-04.4": [ - "24", - "26" - ] - }, - "apac-sgp-cyber-hygiene-practice-2019": { - "CPL-01": [ - "3.1(a)", - "3.1(b)", - "3.1(c)" + "THR-01": [ + "3.0", + "3.1", + "3.1.1", + "3.1.6" ], - "CFG-01": [ - "4.3(a)" + "THR-02": [ + "3.1" ], - "CFG-02": [ - "4.3(a)" + "THR-03": [ + "3.0", + "3.1", + "3.1.1", + "3.1.5" ], - "CFG-02.2": [ - "4.3(a)", - "4.3(b)" + "THR-04": [ + "3.0" ], - "CFG-02.7": [ - "4.3(c)" + "THR-07": [ + "3.0" ], - "END-01": [ - "4.5" + "THR-09": [ + "3.0", + "3.1.6" ], - "END-02": [ - "4.5" + "THR-10": [ + "3.1", + "3.1.1", + "3.1.2", + "3.1.6" ], - "END-04": [ - "4.5" + "VPM-01": [ + "2.6", + "3.1" ], - "IAC-01": [ - "4.1" + "VPM-02": [ + "2.6" ], - "IAC-06": [ - "4.6(b)" + "VPM-03": [ + "3.1.3" ], - "IAC-06.1": [ - "4.6(a)" + "VPM-04": [ + "3.2.6" ], - "IAC-06.3": [ - "4.6(a)" + "VPM-05": [ + "2.6", + "2.6.1", + "3.2.6" ], - "IAC-16": [ - "4.1" + "VPM-06": [ + "3.1.2", + "3.1.3" ], - "NET-01": [ - "4.4" + "VPM-07": [ + "3.1.2" + ] + }, + "americas-can-osfi-self-assessment-2": { + "GOV-01": [ + "1.2.1" ], - "NET-02": [ - "4.4" + "GOV-01.1": [ + "1.3.2" ], - "NET-03": [ - "4.4" + "GOV-02": [ + "1.3.2", + "2.2.1" ], - "RSK-06.2": [ - "4.2(b)", - "4.3(c)" + "GOV-04": [ + "1.1.1", + "1.1.2" ], - "VPM-01": [ - "4.2(a)", - "4.2(b)" + "GOV-04.1": [ + "1.1.2" ], - "VPM-02": [ - "4.2(a)", - "4.2(b)" + "GOV-04.2": [ + "1.1.2" ], - "VPM-05": [ - "4.2(a)", - "4.2(b)" + "GOV-05.2": [ + "1.2.1" ], - "VPM-05.4": [ - "4.2(a)" - ] - }, - "apac-sgp-mas-trm-2021": { - "GOV-01.1": [ - "3.1.1", - "3.1.2", - "3.1.3", - "3.1.4", - "3.1.5", - "3.1.6", - "3.1.7(a)", - "3.1.7(b)", - "3.1.7(c)", - "3.1.7(d)", - "3.1.7(e)", - "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", - "3.1.8(e)" + "GOV-07": [ + "3.1.5" ], - "GOV-02": [ + "GOV-14": [ + "1.1.2" + ], + "GOV-15": [ "3.2.1" ], - "GOV-03": [ - "3.2.2" + "GOV-15.1": [ + "3.2.1" ], - "GOV-04": [ - "3.1.7(a)", - "3.1.7(b)", - "3.1.7(c)", - "3.1.7(d)", - "3.1.7(e)", - "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", - "3.1.8(e)" + "GOV-15.2": [ + "3.2.1" ], - "GOV-05": [ - "4.5.3", - "7.8.3" + "GOV-15.3": [ + "3.2.1" ], - "AST-01": [ - "3.3.1", - "3.3.1(a)", - "3.3.1(d)", - "7.1.1", - "11.4.1", - "11.4.2", - "11.4.3" + "GOV-15.4": [ + "3.2.1" ], - "AST-01.2": [ - "3.3.1(c)" + "GOV-15.5": [ + "3.2.1" ], - "AST-02": [ - "3.3.1(a)", - "3.3.2" + "GOV-16": [ + "2.9.3" ], - "AST-02.5": [ - "11.2.4" + "AST-01.1": [ + "2.2.2", + "2.9.1" ], - "AST-09": [ - "11.1.7" + "AST-02": [ + "2.2.2" ], - "AST-16": [ - "11.3.7" + "AST-02.4": [ + "2.2.3" ], - "AST-23": [ - "11.5.1" + "AST-02.9": [ + "2.2.2", + "2.2.3" + ], + "AST-09": [ + "2.2.4" ], "BCD-01": [ - "8.1.1", - "8.1.2", - "8.1.3", - "8.1.4", - "8.2.1", - "8.2.2", - "8.2.3", - "8.2.4", - "8.5.1", - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" + "2.9.1" ], - "BCD-01.4": [ - "8.1.4", - "8.2.1" + "BCD-01.7": [ + "2.9.1" ], "BCD-02": [ - "8.1.2" + "2.9.1" ], "BCD-04": [ - "8.2.3", - "8.3.1", - "8.3.2", - "8.3.3(a)", - "8.3.3(b)", - "8.3.4" - ], - "BCD-04.1": [ - "8.3.4" - ], - "BCD-04.2": [ - "8.2.4" - ], - "BCD-05": [ - "7.8.1", - "7.8.2", - "7.8.3" + "2.9.3" ], "BCD-11": [ - "8.4.1", - "8.4.2" - ], - "BCD-11.1": [ - "8.4.3" - ], - "BCD-11.4": [ - "8.4.4" + "2.9.1" ], "CAP-01": [ - "8.1.1" + "2.8.2" ], - "CAP-03": [ - "8.1.3" + "CAP-04": [ + "2.8.2" ], "CHG-01": [ - "7.5.1", - "7.5.2", - "7.5.3", - "7.5.4", - "7.5.5", - "7.5.6", - "7.5.7" + "2.5.1" + ], + "CHG-02": [ + "2.5.1" ], "CHG-02.1": [ - "7.5.4" + "2.5.1", + "2.5.3" ], "CHG-02.2": [ - "7.4.2", - "7.5.3", - "7.5.5", - "7.5.7" + "2.5.1" ], - "CHG-02.3": [ - "7.5.4" + "CHG-04.1": [ + "2.5.3" ], - "CHG-03": [ - "7.5.2" + "CHG-07": [ + "2.5.1" ], - "CHG-06": [ - "7.5.5" + "CFG-02": [ + "3.2.8" ], - "CPL-01": [ - "3.2.3" + "CFG-02.7": [ + "3.2.8" ], - "CPL-01.1": [ - "3.2.3", - "4.5.2", - "4.5.3" + "MON-01": [ + "3.3.1" ], - "CPL-02": [ - "3.2.3" + "MON-01.2": [ + "3.3.1" ], - "CPL-02.1": [ - "15.1.1", - "15.1.2", - "15.1.3", - "15.1.4" + "MON-01.4": [ + "3.2.7" ], - "CPL-03": [ - "4.5.1" + "MON-01.8": [ + "3.3.3" ], - "CPL-03.2": [ - "4.5.1" + "MON-02": [ + "3.3.1", + "3.3.2" ], - "CFG-01": [ - "7.2.1", - "7.2.2", - "7.3.1", - "7.3.2", - "7.3.3" + "MON-10": [ + "3.3.1" ], - "CFG-02": [ - "11.2.5", - "11.3.1", - "11.3.2" + "MON-11.3": [ + "3.3.2" ], - "CFG-02.1": [ - "11.2.5" + "MON-16": [ + "3.3.2" ], - "CFG-02.2": [ - "11.3.2" + "CRY-01": [ + "3.2.2" ], - "CFG-02.4": [ - "5.7.3" + "CRY-09": [ + "2.9.2", + "3.2.2" ], - "CFG-03.3": [ - "11.3.6" + "DCH-01": [ + "3.1.4" ], - "CFG-04.1": [ - "6.1.3" + "DCH-02": [ + "3.1.4", + "3.2.5" ], - "MON-01": [ - "12.2.1", - "12.2.2", - "12.2.3" + "DCH-06.3": [ + "3.1.4" ], - "MON-01.8": [ - "12.2.2" + "END-06.8": [ + "3.3.2" ], - "MON-01.16": [ - "12.2.1", - "12.2.2", - "12.2.3" + "HRS-03": [ + "2.7.2" ], - "MON-02": [ - "9.1.3" + "HRS-04": [ + "3.2.7" ], - "MON-02.1": [ - "12.2.5" + "HRS-11": [ + "2.5.2" ], - "MON-02.2": [ - "12.2.6" + "IAC-01": [ + "3.2.7" ], - "MON-03.2": [ - "9.2.2" + "IAC-01.2": [ + "3.2.7" ], - "MON-06": [ - "12.2.6" + "IAC-06": [ + "3.2.7" ], - "MON-09": [ - "14.2.1", - "14.2.2", - "14.2.3", - "14.2.4", - "14.2.5", - "14.2.6", - "14.2.7", - "14.2.8", - "14.2.9", - "14.2.10", - "14.2.11" + "IAC-16": [ + "3.2.7" ], - "MON-11.3": [ - "11.3.5" + "IRO-01": [ + "2.7.1", + "3.4.3" ], - "MON-16": [ - "9.2.2", - "11.5.5", - "12.2.4" + "IRO-02": [ + "2.7.1", + "2.7.2", + "2.7.3", + "3", + "3.4.1" ], - "MON-16.1": [ - "3.5.2" + "IRO-02.4": [ + "2.7.2", + "3.4.2" ], - "CRY-01": [ - "10.1.1", - "10.1.2", - "10.1.3", - "10.1.4", - "10.1.5" + "IRO-03": [ + "2.7.2" ], - "CRY-09": [ - "10.2.1", - "10.2.2", - "10.2.3", - "10.2.4", - "10.2.5", - "10.2.6", - "10.2.7", - "10.2.8", - "10.2.9", - "10.2.10" + "IRO-06": [ + "2.7.2" ], - "CRY-09.4": [ - "10.2.5" + "IRO-06.1": [ + "2.7.2" ], - "DCH-01": [ - "11.1.1", - "11.1.1(a)", - "11.1.1(b)", - "11.1.1(c)", - "11.1.2", - "11.1.3", - "11.1.4", - "11.1.5", - "11.1.6", - "11.1.7" + "IRO-07": [ + "3.4.4" ], - "DCH-01.1": [ - "3.3.1(c)" + "IRO-08": [ + "3.4.5" ], - "DCH-02": [ - "3.3.1(b)" + "IRO-13": [ + "2.7.3" ], - "DCH-08": [ - "11.1.7" + "IAO-02": [ + "2.4.4" ], - "DCH-09": [ - "11.1.7" + "IAO-04": [ + "2.4.4" ], - "DCH-21": [ - "11.1.7" + "NET-01": [ + "3.2.4" ], - "DCH-22": [ - "5.8.1", - "5.8.2" + "NET-02": [ + "3.2.4" ], - "EMB-01": [ - "11.5.1", - "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" + "NET-04": [ + "3.2.4" ], - "EMB-02": [ - "11.5.1", - "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" + "NET-08": [ + "3.2.4" ], - "EMB-05": [ - "11.5.5" + "PES-01": [ + "3.2.10" ], - "END-01": [ - "11.3.1", - "11.3.2", - "11.3.3", - "11.3.4", - "11.3.5", - "11.4.1", - "11.4.2", - "11.4.3" + "PES-01.1": [ + "3.2.10" ], - "END-04": [ - "11.3.3" + "PES-02": [ + "3.2.10" ], - "END-04.1": [ - "11.3.4" + "PES-02.1": [ + "3.2.10" ], - "END-04.3": [ - "11.3.5" + "PRM-01": [ + "2.3.1" ], - "END-08": [ - "14.1.6" + "PRM-01.1": [ + "1.2.1" ], - "HRS-01": [ - "3.5.1", - "3.5.2" + "PRM-02.1": [ + "1.3.2" ], - "HRS-02.1": [ - "3.5.2", - "6.1.5" + "PRM-04": [ + "2.3.1" ], - "HRS-03.2": [ - "3.5.1", - "6.1.5" + "PRM-05": [ + "1.2.1" ], - "HRS-04": [ - "3.5.2" + "PRM-06": [ + "1.2.1" ], - "HRS-04.1": [ - "3.5.2" + "PRM-07": [ + "2.4.1" ], - "HRS-11": [ - "9.1.1" + "RSK-01": [ + "1.3.1", + "1.3.2", + "3.1.8" ], - "IAC-01": [ - "9.1.2", - "9.1.3", - "9.1.8" + "RSK-01.1": [ + "1.3.2", + "3.1.8" ], - "IAC-05": [ - "9.1.8" + "RSK-01.3": [ + "1.3.2", + "3.1.8" ], - "IAC-06": [ - "9.1.5" + "RSK-01.4": [ + "1.3.2", + "3.1.8" ], - "IAC-08": [ - "9.1.7", - "11.1.6" + "RSK-01.5": [ + "1.3.2", + "3.1.8" ], - "IAC-10.1": [ - "9.1.4" + "RSK-04.2": [ + "1.3.2", + "3.1.3" ], - "IAC-16": [ - "9.2.1" + "RSK-06": [ + "3.2.3" ], - "IAC-17": [ - "9.1.6" + "RSK-06.2": [ + "3.2.3", + "3.2.6" ], - "IAC-21": [ - "9.1.1" + "RSK-06.4": [ + "1.3.2", + "3.2.3" ], - "IRO-01": [ - "7.7.1", - "7.7.2", - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "7.7.4", - "7.7.5", - "7.7.6", - "7.7.7" + "SEA-01": [ + "2.1.1", + "2.1.2", + "3.2.1" ], - "IRO-02": [ - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)" + "SEA-02": [ + "2.1.1", + "2.1.2" ], - "IRO-04": [ - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "12.3.1", - "12.3.2", - "12.3.3" + "SEA-07.1": [ + "2.2.5" ], - "IRO-07": [ - "7.7.5" + "OPS-01.1": [ + "2.7.2" ], - "IRO-09": [ - "7.7.5" + "OPS-03": [ + "2.8.1" ], - "IRO-10": [ - "7.7.5", - "7.7.6", - "7.7.7" + "OPS-06": [ + "3.3.2" ], - "IRO-13": [ - "7.8.1", - "7.8.2", - "7.8.3", - "12.3.3" + "SAT-01": [ + "3.1.7" ], - "IRO-16": [ - "7.7.5", - "7.7.6", - "7.7.7" + "SAT-01.1": [ + "3.1.7" ], - "IAO-01": [ - "5.1.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.6.1", - "5.6.2", - "5.6.3", - "5.7.1", - "5.7.2" + "SAT-02": [ + "3.1.7" ], - "IAO-01.1": [ - "5.7.1", - "5.7.2" + "SAT-02.1": [ + "3.1.7" ], - "IAO-02": [ - "5.7.1", - "5.7.2" + "TDA-01": [ + "2.4.3", + "2.4.4" ], - "IAO-02.2": [ - "5.7.4" + "TDA-01.1": [ + "2.4.3" ], - "IAO-02.4": [ - "5.7.6" + "TDA-01.4": [ + "2.4.3" ], - "IAO-03.2": [ - "5.4.3" + "TDA-02.3": [ + "2.4.3", + "2.4.5" ], - "IAO-04": [ - "5.7.5" + "TDA-06": [ + "2.4.2", + "2.4.5" ], - "IAO-05": [ - "4.5.2" + "TDA-06.2": [ + "3.1.6" ], - "MDM-04": [ - "14.1.7" + "TDA-09": [ + "3.2.9" ], - "MDM-06": [ - "14.1.7" + "TDA-09.3": [ + "3.2.9" ], - "MDM-07": [ - "14.1.7" + "TDA-17": [ + "2.2.5" ], - "NET-01": [ - "11.2.1", - "11.2.2", - "11.2.3", - "11.2.4", - "11.2.5", - "11.2.6", - "11.2.7", - "11.2.8" + "TPM-05": [ + "2.8.1" ], - "NET-02.1": [ - "11.2.7" + "THR-01": [ + "3.1.1", + "3.1.5" ], - "NET-03": [ - "11.2.5", - "11.2.6" + "THR-03": [ + "3.1.1", + "3.1.5" ], - "NET-03.7": [ - "11.2.6" + "THR-03.1": [ + "3.1.1", + "3.1.5" ], - "NET-04.6": [ - "11.2.5" + "THR-09": [ + "3.1.2", + "3.1.6" ], - "NET-06": [ - "11.2.6" + "THR-10": [ + "3.1.2", + "3.1.6" ], - "NET-08": [ - "11.2.3", - "11.2.4" + "VPM-01": [ + "2.6.1", + "3.2.6" ], - "NET-14": [ - "9.3.1", - "9.3.2" + "VPM-02": [ + "3.2.6" ], - "NET-14.5": [ - "9.3.1", - "9.3.2" + "VPM-04": [ + "2.6.1" ], - "PES-01": [ - "8.5.1", - "8.5.2", - "8.5.5", - "8.5.6(a)", - "8.5.6(b)", - "8.5.6(c)", - "8.5.6(d)", - "8.5.6(e)", - "8.5.6(f)" + "VPM-04.1": [ + "2.6.1" ], - "PES-02": [ - "8.5.6(a)" + "VPM-04.3": [ + "2.6.1" ], - "PES-03": [ - "8.5.6(c)", - "5.5.6(f)" + "VPM-05": [ + "2.6.1", + "3.2.6" ], - "PES-03.1": [ - "5.5.6(f)" + "VPM-05.1": [ + "3.2.6" ], - "PES-03.2": [ - "8.5.6(d)" + "VPM-06": [ + "3.1.3" + ] + }, + "americas-can-itsp-10-171-2025": { + "GOV-01": [ + "03.15.01.A" ], - "PES-03.4": [ - "8.5.6(d)" + "GOV-01.1": [ + "03.12.03" ], - "PES-04": [ - "8.5.6(e)" + "GOV-01.2": [ + "03.12.03" ], - "PES-04.1": [ - "8.5.6(e)", - "5.5.6(f)" + "GOV-02": [ + "03.15.01.A" ], - "PES-05": [ - "5.5.5" + "GOV-03": [ + "03.15.01.B", + "03.15.03.D" ], - "PES-05.2": [ - "8.5.5" + "GOV-05": [ + "03.12.03" ], - "PES-06": [ - "8.5.6(b)", - "5.5.6(f)" + "GOV-15": [ + "03.15.01.A", + "03.16.01", + "03.17.01.A" ], - "PES-07": [ - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" + "GOV-15.1": [ + "03.15.01.A", + "03.17.01.A" ], - "PES-08": [ - "8.5.3", - "8.5.4" + "GOV-15.2": [ + "03.15.01.A", + "03.17.01.A" ], - "PES-08.1": [ - "8.5.3", - "8.5.4" + "GOV-15.3": [ + "03.15.01.A", + "03.17.01.A" ], - "PES-10": [ - "5.5.6(f)" + "GOV-15.4": [ + "03.15.01.A", + "03.17.01.A" ], - "PRI-01.6": [ - "14.1.1", - "14.1.2", - "14.1.3", - "14.1.4", - "14.1.5", - "14.1.6", - "14.1.7" + "GOV-15.5": [ + "03.15.01.A", + "03.17.01.A" ], - "PRI-05": [ - "11.1.7" + "AST-01": [ + "03.01.03", + "03.01.18.A", + "03.04.11.A", + "03.07.04.A" ], - "PRM-01": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4" + "AST-01.1": [ + "03.01.03" ], - "PRM-01.1": [ - "3.1.4", - "3.1.5" + "AST-01.4": [ + "03.04.08.C" ], - "PRM-02": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.5.1", - "5.5.2" + "AST-02": [ + "03.04.08.A", + "03.04.08.C", + "03.04.10.A", + "03.04.10.B", + "03.04.11.A" ], - "PRM-03": [ - "5.2.1", - "5.2.2" + "AST-02.1": [ + "03.04.10.A", + "03.04.10.B", + "03.04.10.C" ], - "PRM-04": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.8.1", - "5.8.2" + "AST-02.4": [ + "03.04.02.B", + "03.04.06.A" ], - "PRM-05": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.3.3", - "5.5.1", - "5.5.2", - "5.6.1", - "5.6.2", - "5.6.3" + "AST-02.8": [ + "03.04.11.A", + "03.04.11.B" ], - "PRM-06": [ - "5.5.1", - "5.5.2" + "AST-02.9": [ + "03.04.08.A", + "03.04.10.A", + "03.04.10.B" ], - "PRM-07": [ - "5.1.2", - "5.1.3", - "5.1.4", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4" + "AST-03": [ + "03.09.02.A.03" ], - "RSK-01": [ - "4.1.1", - "4.1.2", - "4.1.5" + "AST-03.1": [ + "03.09.02.A.03" ], - "RSK-01.1": [ - "4.2.1", - "4.3.2" + "AST-04": [ + "03.01.03", + "03.04.11.A", + "03.04.11.B" ], - "RSK-02": [ - "4.2.1" + "AST-04.1": [ + "03.04.11.A", + "03.04.11.B" ], - "RSK-02.1": [ - "4.2.1", - "4.3.1", - "4.3.2" + "AST-04.2": [ + "03.04.11.A", + "03.04.11.B", + "03.15.02.A.04" ], - "RSK-03": [ - "4.1.3", - "4.1.4(a)" + "AST-04.3": [ + "03.01.03" ], - "RSK-04": [ - "4.1.4(b)", - "4.3.2" + "AST-05": [ + "03.07.04.A" ], - "RSK-04.1": [ - "4.1.3", - "4.1.4(d)", - "4.5.2", - "4.5.3" + "AST-09": [ + "03.07.04.C", + "03.08.03" ], - "RSK-05": [ - "4.2.1" + "AST-10": [ + "03.09.02.A.03" ], - "RSK-06": [ - "4.1.3", - "4.1.4(c)", - "4.4.1", - "4.4.2", - "4.4.3", - "13.6.1", - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" + "AST-12": [ + "03.01.18.A" ], - "RSK-06.1": [ - "4.1.5", - "4.5.3" + "AST-13": [ + "03.01.18.A" ], - "RSK-06.2": [ - "4.2.1", - "4.4.2", - "4.4.3" + "AST-14": [ + "03.01.18.A" ], - "RSK-07": [ - "4.1.5" + "AST-16": [ + "03.01.18.A" ], - "RSK-08": [ - "5.1.3", - "5.3.3" + "AST-17": [ + "03.11.01.A", + "03.16.01" ], - "RSK-09": [ - "5.3.1" + "AST-24": [ + "03.04.12.A", + "03.04.12.B" ], - "RSK-10": [ - "5.1.3", - "5.3.3" + "AST-25": [ + "03.04.12.B" ], - "SEA-01": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" + "AST-27": [ + "03.01.12.A", + "03.01.12.C" ], - "SEA-01.1": [ - "4.5.1" + "AST-31": [ + "03.01.03" ], - "SEA-02": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" + "BCD-11": [ + "03.08.09.A" ], - "SEA-03": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" + "BCD-11.4": [ + "03.08.09.A", + "03.08.09.B" ], - "SEA-07.1": [ - "7.3.1", - "7.3.2", - "7.3.3" + "CHG-01": [ + "03.04.02.B", + "03.04.03.A", + "03.04.03.D" ], - "OPS-01": [ - "7.1.1" + "CHG-02": [ + "03.04.02.B", + "03.04.03.A", + "03.04.03.B", + "03.04.03.C", + "03.07.05.A" ], - "OPS-03": [ - "7.1.1" + "CHG-02.1": [ + "03.04.02.B", + "03.04.03.A", + "03.04.03.B", + "03.07.05.A" ], - "OPS-04": [ - "12.2.1" + "CHG-02.2": [ + "03.04.03.B", + "03.04.03.C", + "03.04.04.A", + "03.04.11.B" ], - "SAT-01": [ - "3.6.1", - "3.6.4", - "6.1.5" + "CHG-02.3": [ + "03.04.04.A" ], - "SAT-02": [ - "3.6.1" + "CHG-03": [ + "03.04.03.B", + "03.04.04.A", + "03.04.11.B" ], - "SAT-03": [ - "3.6.2", - "3.6.3", - "6.1.5" + "CHG-04": [ + "03.04.02.B", + "03.04.05" ], - "SAT-03.2": [ - "9.2.2", - "11.5.5", - "12.2.4" + "CHG-04.4": [ + "03.04.05" ], - "SAT-03.3": [ - "3.6.2", - "3.6.3", - "6.1.5" + "CHG-05": [ + "03.04.11.B" ], - "SAT-03.5": [ - "6.1.5" + "CHG-06": [ + "03.04.04.B" ], - "TDA-01": [ - "5.3.1", - "5.3.2", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "CPL-01": [ + "03.04.11.A", + "03.12.01" ], - "TDA-01.1": [ - "5.8.1", - "5.8.2", - "7.6.1", - "7.6.2", - "14.4.1", - "14.4.2", - "14.4.3" + "CPL-01.1": [ + "03.12.02.A.01", + "03.12.02.A.02" ], - "TDA-02": [ - "5.3.3" + "CPL-01.2": [ + "03.04.11.A", + "03.15.02.A.04" ], - "TDA-02.3": [ - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7" + "CPL-02": [ + "03.12.01", + "03.12.03" ], - "TDA-03": [ - "5.3.3", - "6.1.3" + "CPL-02.1": [ + "03.12.01" ], - "TDA-04": [ - "6.1.4" + "CPL-03": [ + "03.12.01", + "03.12.03" ], - "TDA-05": [ - "6.1.5", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "CPL-03.2": [ + "03.04.02.B", + "03.04.08.C", + "03.12.03" ], - "TDA-06": [ - "5.3.2", - "6.1.1", - "6.1.2", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "CFG-01": [ + "03.04.01.A", + "03.04.03.A" ], - "TDA-06.3": [ - "6.1.1", - "6.1.2", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3", - "7.6.1", - "7.6.2" + "CFG-02": [ + "03.01.01.H", + "03.01.03", + "03.01.08.A", + "03.01.08.B", + "03.01.09", + "03.01.10.A", + "03.01.10.B", + "03.01.10.C", + "03.01.11", + "03.01.12.A", + "03.01.16.A", + "03.01.16.C", + "03.01.18.A", + "03.03.08.A", + "03.04.01.A", + "03.04.02.A", + "03.04.02.B", + "03.04.06.A", + "03.04.06.B", + "03.04.06.D", + "03.05.04", + "03.05.07.C", + "03.05.07.D", + "03.05.07.E", + "03.05.07.F", + "03.05.12.D", + "03.07.05.B", + "03.08.07.A", + "03.13.12.B" ], - "TDA-06.5": [ - "5.7.4", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.6", - "6.1.7" + "CFG-02.1": [ + "03.04.01.B", + "03.04.06.C" ], - "TDA-07": [ - "5.7.3" + "CFG-02.2": [ + "03.04.02.B", + "03.04.03.D", + "03.13.13.B" ], - "TDA-08": [ - "5.7.3" + "CFG-02.5": [ + "03.04.01.A", + "03.04.02.A", + "03.04.06.A", + "03.04.06.D", + "03.04.12.A", + "03.14.08.C" ], - "TDA-09": [ - "5.7.1", - "5.7.2", - "5.7.3", - "5.7.4", - "5.7.5", - "5.7.6", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.6", - "6.1.7" + "CFG-02.7": [ + "03.04.01.A", + "03.04.02.B" ], - "TDA-09.1": [ - "6.1.4" + "CFG-02.9": [ + "03.03.02.B", + "03.04.01.A", + "03.04.02.A", + "03.04.02.B", + "03.04.06.A", + "03.04.08.A", + "03.04.12.A", + "03.13.11" ], - "TDA-09.2": [ - "6.1.6" + "CFG-03": [ + "03.04.02.A", + "03.04.06.A", + "03.04.06.B", + "03.04.06.D", + "03.04.08.A" ], - "TDA-09.3": [ - "6.1.6" + "CFG-03.1": [ + "03.04.06.C", + "03.04.08.C" ], - "TDA-09.4": [ - "6.1.6" + "CFG-03.2": [ + "03.04.08.B" ], - "TDA-09.5": [ - "6.1.6" + "CFG-03.3": [ + "03.04.08.A", + "03.04.08.B", + "03.13.13.A", + "03.13.13.B" ], - "TDA-10": [ - "11.1.6" + "CFG-04": [ + "03.13.13.B" ], - "TDA-14": [ - "6.1.5" + "CFG-04.1": [ + "03.13.13.B" ], - "TDA-15": [ - "6.1.6" + "CFG-05": [ + "03.13.13.B" ], - "TDA-16": [ - "6.1.5" + "CFG-06": [ + "03.04.02.A", + "03.04.02.B", + "03.04.03.A" ], - "TDA-17": [ - "7.3.1", - "7.3.2", - "7.3.3" + "CFG-08": [ + "03.01.02" ], - "TDA-20.3": [ - "5.3.4" + "MON-01": [ + "03.03.01.A", + "03.12.03", + "03.14.06.A", + "03.14.06.A.02" ], - "TPM-01": [ - "3.4.1", - "3.4.2", - "3.4.3", - "9.1.8" + "MON-01.1": [ + "03.13.01.A" ], - "TPM-03": [ - "3.4.1", - "3.4.2" + "MON-01.3": [ + "03.13.01.A", + "03.14.06.C" ], - "TPM-03.2": [ - "3.4.1", - "3.4.2" + "MON-01.4": [ + "03.03.01.A", + "03.03.03.A", + "03.14.06.A.01", + "03.14.06.B", + "03.14.06.C" ], - "TPM-05": [ - "3.4.1", - "3.4.2", - "3.4.3" + "MON-01.8": [ + "03.03.05.A" ], - "TPM-08": [ - "3.4.3" + "MON-01.12": [ + "03.03.04.A", + "03.03.05.B" ], - "THR-01": [ - "4.2.1", - "13.5.1", - "13.5.2", - "14.3.1", - "14.3.2", - "14.3.3" + "MON-01.15": [ + "03.01.07.B" ], - "THR-02": [ - "14.3.1", - "14.3.2", - "14.3.3" + "MON-02": [ + "03.03.05.A", + "03.03.05.C" ], - "THR-03": [ - "12.1.1", - "12.1.2", - "12.1.3" + "MON-02.1": [ + "03.03.05.A", + "03.03.05.C" ], - "THR-06": [ - "13.2.2" + "MON-02.2": [ + "03.03.05.A", + "03.03.05.C" ], - "VPM-01": [ - "4.2.1", - "7.4.1", - "7.4.2" + "MON-02.3": [ + "03.03.05.C" ], - "VPM-01.1": [ - "13.1.2" + "MON-02.6": [ + "03.03.01.B" ], - "VPM-02": [ - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" + "MON-02.7": [ + "03.03.01.A" ], - "VPM-04": [ - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" + "MON-03": [ + "03.03.01.A", + "03.03.02.A", + "03.03.02.A.01", + "03.03.02.A.02", + "03.03.02.A.03", + "03.03.02.A.04", + "03.03.02.A.05", + "03.03.02.A.06", + "03.03.02.B" ], - "VPM-04.1": [ - "7.4.1", - "7.4.2" + "MON-03.2": [ + "03.03.01.A" ], - "VPM-05": [ - "7.4.1", - "7.4.2" + "MON-03.3": [ + "03.01.07.B" ], - "VPM-05.1": [ - "7.4.1", - "7.4.2" + "MON-03.6": [ + "03.03.01.B" ], - "VPM-05.3": [ - "13.6.1(b)" + "MON-05": [ + "03.03.04.B" ], - "VPM-05.4": [ - "7.4.1", - "7.4.2" + "MON-06": [ + "03.03.05.B", + "03.03.06.A" ], - "VPM-06": [ - "13.1.1", - "13.1.2" + "MON-07": [ + "03.03.02.A.02", + "03.03.07.A" ], - "VPM-07": [ - "13.2.1", - "13.2.3", - "13.2.4" + "MON-07.1": [ + "03.03.07.B" ], - "VPM-10": [ - "13.3.1", - "13.3.2", - "13.4.1", - "13.4.2" - ] - }, - "apac-kor-pipa-2011": { - "GOV-01": [ - "3", - "29", - "30" + "MON-08": [ + "03.03.03.B", + "03.03.06.B", + "03.03.08.A", + "03.03.08.B" ], - "CPL-01": [ - "3", - "29" + "MON-08.1": [ + "03.03.08.A" ], - "DCH-22.1": [ - "4", - "36" + "MON-08.2": [ + "03.03.08.A", + "03.03.08.B" ], - "DCH-24": [ - "17", - "27" + "MON-08.3": [ + "03.03.08.A" ], - "DCH-24.1": [ - "17", - "27" + "MON-10": [ + "03.03.03.B" ], - "DCH-25": [ - "17", - "26", - "27" + "MON-11": [ + "03.01.22.B" ], - "IRO-04": [ - "34" + "MON-11.3": [ + "03.14.06.A.01", + "03.14.06.A.02", + "03.14.06.B", + "03.14.06.C" ], - "IRO-04.1": [ - "34" + "MON-16": [ + "03.01.01.E", + "03.03.05.A", + "03.14.06.A.01", + "03.14.06.A.02", + "03.14.06.B", + "03.14.06.C" ], - "PRI-01": [ - "3", - "30" + "CRY-01": [ + "03.13.08", + "03.13.11" ], - "PRI-01.1": [ - "31" + "CRY-01.1": [ + "03.13.08" ], - "PRI-02": [ - "3", - "4" + "CRY-01.5": [ + "03.13.11" ], - "PRI-02.1": [ - "3", - "4" + "CRY-03": [ + "03.13.08", + "03.13.11" ], - "PRI-03": [ - "3", - "4", - "22" + "CRY-05": [ + "03.13.08", + "03.13.11" ], - "PRI-03.2": [ - "22" + "CRY-05.1": [ + "03.13.08" ], - "PRI-04": [ - "3", - "15", - "22" + "CRY-07": [ + "03.01.16.A" ], - "PRI-04.1": [ - "3", - "15" + "CRY-08": [ + "03.13.10" ], - "PRI-05": [ - "3", - "4", - "15", - "19", - "21", - "37" + "CRY-09": [ + "03.13.10" ], - "PRI-05.1": [ - "3" + "CRY-09.3": [ + "03.13.10" ], - "PRI-05.2": [ - "3" + "CRY-09.4": [ + "03.13.10" ], - "PRI-05.3": [ - "3" + "DCH-01": [ + "03.01.01.D.01", + "03.01.01.D.02", + "03.08.01" ], - "PRI-05.4": [ - "16", - "18", - "23" + "DCH-01.1": [ + "03.08.01", + "03.08.05.A" ], - "PRI-05.5": [ - "33" + "DCH-01.2": [ + "03.01.01.D.01", + "03.01.01.D.02", + "03.01.02", + "03.01.20.A", + "03.01.20.B", + "03.01.20.C.01", + "03.01.20.D", + "03.06.05.D", + "03.08.01", + "03.08.02", + "03.08.05.A", + "03.17.01.C" ], - "PRI-06": [ - "4", - "35" + "DCH-01.3": [ + "03.08.05.C" ], - "PRI-06.1": [ - "4", - "36" + "DCH-01.4": [ + "03.01.02", + "03.01.03", + "03.01.04.B", + "03.08.01", + "03.08.02", + "03.10.01.A", + "03.15.02.C", + "03.17.01.C" ], - "PRI-06.2": [ - "4", - "36" + "DCH-02": [ + "03.04.11.A", + "03.08.01", + "03.08.04" ], - "PRI-06.3": [ - "38" + "DCH-03": [ + "03.01.03", + "03.08.01", + "03.08.02" ], - "PRI-06.4": [ - "37" + "DCH-03.1": [ + "03.01.22.A", + "03.15.02.C", + "03.17.01.C" ], - "PRI-07": [ - "17", - "26", - "27" + "DCH-04": [ + "03.08.04" ], - "PRI-07.1": [ - "26", - "27" + "DCH-06": [ + "03.08.01" ], - "PRI-15": [ - "32" + "DCH-06.1": [ + "03.08.01" ], - "RSK-08": [ - "33" + "DCH-06.2": [ + "03.04.11.A", + "03.04.11.B" ], - "RSK-10": [ - "33" + "DCH-06.4": [ + "03.08.01" ], - "SEA-01": [ - "3", - "29" + "DCH-07": [ + "03.08.05.A", + "03.08.05.B", + "03.08.05.C" ], - "SEA-02": [ - "3", - "29" + "DCH-07.1": [ + "03.08.05.A", + "03.08.05.B" ], - "SEA-03": [ - "3", - "29" + "DCH-07.2": [ + "03.08.05.A" ], - "SEA-15": [ - "17", - "27" + "DCH-08": [ + "03.08.03" ], - "TPM-04.4": [ - "17", - "27" - ] - }, - "apac-twn-pdpa-2025": { - "GOV-01": [ - "27" + "DCH-09": [ + "03.07.04.C", + "03.08.03" ], - "CPL-01": [ - "27" + "DCH-10": [ + "03.08.07.A" ], - "CPL-02": [ - "27" + "DCH-10.2": [ + "03.08.07.B" ], - "DCH-01": [ - "21" + "DCH-12": [ + "03.08.07.A" ], - "DCH-22.1": [ - "3" + "DCH-13": [ + "03.01.20.A", + "03.01.20.B", + "03.01.20.C.01", + "03.01.20.C.02", + "03.01.20.D" ], - "IRO-04.1": [ - "12" + "DCH-13.1": [ + "03.01.20.A", + "03.01.20.B", + "03.01.20.C.01", + "03.01.20.C.02", + "03.01.20.D" ], - "PRI-01": [ - "Inferred", - "Expectation" + "DCH-13.2": [ + "03.01.20.A", + "03.01.20.D" ], - "PRI-02": [ - "5" + "DCH-13.3": [ + "03.01.20.B", + "03.01.20.C.01" ], - "PRI-02.1": [ - "5", - "19" + "DCH-13.4": [ + "03.01.20.A", + "03.01.20.C.01", + "03.01.20.D" ], - "PRI-02.2": [ - "5" + "DCH-14": [ + "03.01.20.B" ], - "PRI-03": [ - "5" + "DCH-14.2": [ + "03.01.20.B", + "03.01.20.C.02", + "03.12.05.A" ], - "PRI-03.1": [ - "5" + "DCH-14.3": [ + "03.01.03", + "03.01.20.C.02", + "03.12.05.A" ], - "PRI-03.2": [ - "5" + "DCH-15": [ + "03.01.22.A", + "03.01.22.B" ], - "PRI-04": [ - "5", - "19" + "DCH-17": [ + "03.01.20.A" ], - "PRI-04.1": [ - "5", - "19" + "DCH-18": [ + "03.01.20.C.02", + "03.10.07.B", + "03.14.08" ], - "PRI-05": [ - "5", - "19" + "DCH-19": [ + "03.04.11.A", + "03.04.11.B" ], - "PRI-05.4": [ - "5" + "DCH-21": [ + "03.08.03" ], - "PRI-06": [ - "3" + "DCH-24": [ + "03.04.11.A" ], - "PRI-06.1": [ - "3" + "END-01": [ + "03.01.03", + "03.14.02.A" ], - "PRM-05": [ - "27" + "END-04": [ + "03.14.02.C", + "03.14.02.C.01", + "03.14.02.C.02" ], - "SEA-01": [ - "21" + "END-04.1": [ + "03.14.02.B" ], - "SEA-02": [ - "21" + "END-04.3": [ + "03.14.02.A" ], - "SEA-03": [ - "21" - ] - }, - "americas-arg-ppd-2018": { - "CLD-09": [ - "12.1", - "12.2" + "END-04.7": [ + "03.14.02.A", + "03.14.02.C.01", + "03.14.02.C.02" ], - "CPL-01": [ - "10.1", - "10.2" + "END-07": [ + "03.14.06.A.01", + "03.14.06.A.02", + "03.14.06.B", + "03.14.06.C" ], - "DCH-09.3": [ - "4.7", - "16.7", - "25.2" + "END-10": [ + "03.13.13.A", + "03.13.13.B" ], - "DCH-22.1": [ - "16.1", - "16.3" + "END-14": [ + "03.13.12.A" ], - "PRI-02.1": [ - "6", - "27.1", - "27.2", - "28.1" + "END-14.6": [ + "03.13.12.B" ], - "PRI-03": [ - "5.1", - "5.2" + "HRS-01": [ + "03.01.01.G.02", + "03.15.03.A", + "03.15.03.D" ], - "PRI-03.2": [ - "27.3" + "HRS-02": [ + "03.01.01.C.01", + "03.01.01.C.02", + "03.01.01.D.01", + "03.01.01.D.02", + "03.01.02", + "03.09.01.A", + "03.09.01.B", + "03.15.03.B" ], - "PRI-04": [ - "4.1", - "4.2", - "6" + "HRS-02.1": [ + "03.01.02" ], - "PRI-04.1": [ - "5.2", - "7.1", - "7.2", - "7.4", - "8" + "HRS-03": [ + "03.01.22.A", + "03.02.02.A.01", + "03.06.04.A", + "03.06.05.D", + "03.07.06.A", + "03.07.06.D", + "03.08.02", + "03.15.03.B", + "03.16.03.B" ], - "PRI-05": [ - "5.1", - "4.3", - "9.2" + "HRS-03.1": [ + "03.01.22.A", + "03.15.03.B" ], - "PRI-05.1": [ - "7.3", - "9.2" + "HRS-03.2": [ + "03.07.06.D" ], - "PRI-05.2": [ - "4.5" + "HRS-04": [ + "03.09.01.A", + "03.09.01.B", + "03.09.02.B.01" ], - "PRI-05.3": [ - "4.4" + "HRS-04.1": [ + "03.01.22.A", + "03.02.02.A.01", + "03.09.01.A", + "03.09.01.B" ], - "PRI-05.4": [ - "4.3" + "HRS-04.2": [ + "03.01.22.A", + "03.02.02.A.01", + "03.06.04.A", + "03.06.04.A.01", + "03.15.03.B" ], - "PRI-06": [ - "4.6", - "13", - "14.1", - "14.2", - "14.3", - "14.4" + "HRS-05": [ + "03.01.01.H", + "03.01.22.A", + "03.15.03.A", + "03.15.03.B" ], - "PRI-06.1": [ - "16.1", - "16.3" + "HRS-05.1": [ + "03.01.12.A", + "03.01.18.A", + "03.01.22.A", + "03.15.03.A", + "03.15.03.D" ], - "PRI-06.2": [ - "16.2" + "HRS-05.2": [ + "03.15.03.A" ], - "PRI-06.4": [ - "16.2", - "16.6" + "HRS-05.3": [ + "03.01.01.H", + "03.01.12.A", + "03.01.18.A", + "03.15.03.A" ], - "PRI-06.5": [ - "16.5", - "16.7" + "HRS-05.4": [ + "03.15.03.A" ], - "PRI-06.6": [ - "15.1", - "15.2", - "15.3" + "HRS-05.5": [ + "03.01.18.A", + "03.15.03.A" ], - "PRI-07": [ - "11.1", - "11.2", - "11.3", - "11.4", - "12.1", - "16.4" + "HRS-05.7": [ + "03.15.03.C", + "03.15.03.D" ], - "PRI-07.1": [ - "11.4" + "HRS-06": [ + "03.01.18.A", + "03.12.05.A", + "03.15.03.C" ], - "PRI-15": [ - "21.1", - "21.2", - "21.3", - "24" + "HRS-06.1": [ + "03.12.05.A", + "03.15.03.C" ], - "SEA-01.1": [ - "9.1" + "HRS-07": [ + "03.01.01.F.04", + "03.01.01.F.05" ], - "TPM-04": [ - "25.1" - ] - }, - "americas-bhs-dpa-2003": { - "GOV-01": [ - "6" + "HRS-07.1": [ + "03.01.01.F.04", + "03.01.01.F.05" ], - "CPL-01": [ - "6" + "HRS-08": [ + "03.01.01.G.02", + "03.09.02.A", + "03.09.02.B.01", + "03.09.02.B.02" ], - "DCH-22.1": [ - "10" + "HRS-09": [ + "03.01.01.F.03", + "03.01.01.G.02", + "03.09.02.A", + "03.09.02.A.02", + "03.09.02.A.03", + "03.09.02.B.01" ], - "PRI-01": [ - "6" + "HRS-09.1": [ + "03.09.02.A.03" ], - "PRI-02.1": [ - "6" + "HRS-09.2": [ + "03.09.02.A.01", + "03.09.02.A.02", + "03.09.02.B.01" ], - "PRI-04": [ - "6" + "HRS-09.4": [ + "03.01.01.G.02", + "03.09.02.A.01", + "03.09.02.A.02" ], - "PRI-04.1": [ - "6" + "HRS-10": [ + "03.16.03.B" ], - "PRI-05": [ - "6", - "12" + "HRS-11": [ + "03.01.04.A" ], - "PRI-05.1": [ - "6" + "HRS-12": [ + "03.01.04.A" ], - "PRI-05.2": [ - "6" + "IAC-01": [ + "03.01.01.A", + "03.01.18.B", + "03.05.01.A", + "03.05.05.A", + "03.05.12.E" ], - "PRI-05.4": [ - "12" + "IAC-01.2": [ + "03.01.01.D.01", + "03.01.16.B", + "03.05.01.A", + "03.05.02", + "03.05.05.D", + "03.05.07.A", + "03.05.07.B", + "03.05.07.C", + "03.05.07.D", + "03.05.07.E", + "03.05.12.D", + "03.07.05.A" ], - "PRI-06": [ - "8" + "IAC-02": [ + "03.05.01.A", + "03.05.05.D" ], - "PRI-06.1": [ - "10" + "IAC-02.2": [ + "03.05.04", + "03.07.05.B" ], - "PRI-06.2": [ - "11" + "IAC-03": [ + "03.05.01.A" ], - "PRI-06.4": [ - "11" + "IAC-04": [ + "03.01.18.B", + "03.05.02" ], - "SEA-01": [ - "6", - "12" + "IAC-05": [ + "03.05.01.A", + "03.05.02" ], - "SEA-02": [ - "6", - "12" + "IAC-05.2": [ + "03.07.05.A" ], - "SEA-03": [ - "6", - "12" - ] - }, - "americas-bmu-mba-coc-2020": { - "GOV-01": [ - "4", - "5.4" + "IAC-06": [ + "03.05.03", + "03.07.05.B" ], - "GOV-01.1": [ - "5.1", - "5.6" + "IAC-06.1": [ + "03.05.03" ], - "GOV-04": [ - "5.2" + "IAC-06.2": [ + "03.05.03" ], - "GOV-05": [ - "5.7" + "IAC-06.3": [ + "03.05.03" ], - "AST-01": [ - "5.9" + "IAC-06.4": [ + "03.05.03" ], - "AST-02": [ - "5.9" + "IAC-07": [ + "03.01.01.B", + "03.01.01.G.01", + "03.01.01.G.02", + "03.01.01.G.03", + "03.05.05.A", + "03.09.02.A.01", + "03.09.02.A.02" ], - "BCD-01": [ - "6.14", - "7.1" + "IAC-07.1": [ + "03.01.01.G.01", + "03.01.01.G.02", + "03.01.01.G.03", + "03.05.05.A", + "03.09.02.B.02" ], - "BCD-11": [ - "6.14" + "IAC-07.2": [ + "03.09.02.A.01", + "03.09.02.A.02" ], - "CAP-01": [ - "6.1" + "IAC-08": [ + "03.01.01.C.01", + "03.01.01.C.02", + "03.01.01.C.03", + "03.01.02", + "03.01.05.B", + "03.01.06.A", + "03.01.12.A", + "03.03.08.B", + "03.04.05", + "03.06.05.D", + "03.07.06.A" ], - "CHG-01": [ - "6.1" + "IAC-09": [ + "03.05.05.B", + "03.05.05.C", + "03.05.05.D" ], - "CLD-01": [ - "5.11" + "IAC-09.1": [ + "03.05.05.B" ], - "CPL-01.1": [ - "5.7" + "IAC-09.2": [ + "03.05.05.D" ], - "CPL-02": [ - "5.7" + "IAC-09.5": [ + "03.01.07.B", + "03.05.05.D" ], - "CPL-02.1": [ - "5.4", - "5.6" + "IAC-10": [ + "03.05.07.A", + "03.05.07.B", + "03.05.07.C", + "03.05.07.D", + "03.05.07.E", + "03.05.07.F", + "03.05.12.A", + "03.05.12.B", + "03.05.12.C", + "03.05.12.D", + "03.05.12.E", + "03.05.12.F" ], - "CPL-03.2": [ - "5.7" + "IAC-10.1": [ + "03.05.07.E", + "03.05.07.F", + "03.05.12.B", + "03.05.12.D", + "03.05.12.E" ], - "CFG-01": [ - "6.1" + "IAC-10.3": [ + "03.05.12.A" ], - "MON-01": [ - "6.21" + "IAC-10.4": [ + "03.05.07.A", + "03.05.07.B" ], - "MON-01.16": [ - "6.21" + "IAC-10.5": [ + "03.05.07.C", + "03.05.07.D", + "03.05.12.F" ], - "MON-02": [ - "6.21" + "IAC-10.6": [ + "03.05.07.D" ], - "MON-02.2": [ - "6.21" + "IAC-10.8": [ + "03.05.07.E", + "03.05.12.D" ], - "MON-03": [ - "6.21" + "IAC-10.11": [ + "03.05.07.A", + "03.05.07.B", + "03.05.07.C", + "03.05.07.D", + "03.05.07.F" ], - "MON-08": [ - "6.21" + "IAC-11": [ + "03.05.11" ], - "CRY-01": [ - "6.22" + "IAC-14": [ + "03.05.01.B" ], - "DCH-01": [ - "6.8", - "6.10", - "6.13" + "IAC-15": [ + "03.01.01.A", + "03.01.01.B", + "03.01.01.C.01", + "03.01.01.C.02", + "03.01.01.D.01", + "03.01.01.D.02", + "03.01.01.E", + "03.01.01.F.01", + "03.01.01.F.02", + "03.01.01.F.03", + "03.01.01.F.04", + "03.01.01.F.05", + "03.01.01.G.01", + "03.01.01.G.02", + "03.01.01.G.03", + "03.01.02", + "03.01.05.B", + "03.01.05.C", + "03.01.05.D", + "03.05.07.E" ], - "DCH-02": [ - "6.8" + "IAC-15.1": [ + "03.01.01.D.01", + "03.05.05.B", + "03.05.05.C", + "03.05.05.D", + "03.05.07.C", + "03.05.07.D", + "03.05.07.E", + "03.05.07.F", + "03.05.12.D", + "03.05.12.E", + "03.05.12.F" ], - "DCH-09": [ - "6.17" + "IAC-15.3": [ + "03.01.01.F.02" ], - "END-01": [ - "5.12" + "IAC-15.5": [ + "03.01.01.C.01" ], - "END-04": [ - "6.12" + "IAC-15.6": [ + "03.01.01.F.04", + "03.01.01.F.05" ], - "HRS-01": [ - "5.13" + "IAC-15.7": [ + "03.01.01.B", + "03.01.01.E", + "03.01.05.C" ], - "HRS-04": [ - "5.13" + "IAC-16": [ + "03.01.06.A", + "03.01.07.A", + "03.01.07.B" ], - "IAC-01": [ - "6.6" + "IAC-17": [ + "03.01.01.G.03", + "03.01.05.C", + "03.01.05.D", + "03.10.01.C", + "03.10.01.D" ], - "IRO-01": [ - "6.1", - "6.3", - "6.4" + "IAC-20": [ + "03.01.01.C.03", + "03.01.01.D.01", + "03.01.01.D.02", + "03.01.02", + "03.01.03", + "03.01.04.B", + "03.01.05.A", + "03.01.05.B", + "03.01.06.A", + "03.09.02.B.02" ], - "IRO-04": [ - "6.4" + "IAC-20.1": [ + "03.01.01.C.03", + "03.01.01.D.01", + "03.01.01.D.02", + "03.01.02", + "03.01.03", + "03.01.04.B", + "03.01.05.A", + "03.01.05.B", + "03.06.05.D", + "03.10.01.A" ], - "IRO-10": [ - "6.5" + "IAC-20.4": [ + "03.01.06.C", + "03.14.08.A", + "03.14.08.C" ], - "IRO-13": [ - "6.4" + "IAC-21": [ + "03.01.01.C.03", + "03.01.01.D.01", + "03.01.01.D.02", + "03.01.02", + "03.01.04.B", + "03.01.05.A", + "03.01.05.B", + "03.01.06.A", + "03.01.07.A", + "03.03.08.A", + "03.03.08.B", + "03.04.05" ], - "IAO-01": [ - "5.14" + "IAC-21.2": [ + "03.01.06.B" ], - "IAO-02": [ - "5.14" + "IAC-21.3": [ + "03.01.06.A", + "03.01.07.A" ], - "MDM-01": [ - "6.11" + "IAC-21.4": [ + "03.01.07.B" ], - "NET-01": [ - "6.18" + "IAC-21.5": [ + "03.01.07.A" ], - "NET-02.1": [ - "6.19" + "IAC-22": [ + "03.01.08.A", + "03.01.08.B" ], - "RSK-01": [ - "5.3", - "5.8" + "IAC-24": [ + "03.01.10.A", + "03.01.10.B" ], - "RSK-01.1": [ - "5.5" + "IAC-24.1": [ + "03.01.10.C" ], - "RSK-02.1": [ - "5.5" + "IAC-25": [ + "03.01.01.H", + "03.01.11", + "03.07.05.C" ], - "RSK-03": [ - "5.5" + "IAC-28": [ + "03.05.12.A" ], - "RSK-04": [ - "5.5" + "IAC-28.1": [ + "03.01.01.B", + "03.05.05.A" ], - "RSK-04.1": [ - "5.5" + "IRO-01": [ + "03.06.01" ], - "RSK-05": [ - "5.5" + "IRO-02": [ + "03.03.04.B", + "03.06.01", + "03.06.02.A", + "03.06.02.B", + "03.06.02.C", + "03.06.02.D", + "03.06.05.B" ], - "RSK-06": [ - "5.5" + "IRO-04": [ + "03.06.01", + "03.06.05.A", + "03.06.05.A.01", + "03.06.05.A.02", + "03.06.05.A.03", + "03.06.05.A.04", + "03.06.05.A.05", + "03.06.05.A.06", + "03.06.05.B", + "03.06.05.D" ], - "RSK-06.1": [ - "5.5" + "IRO-04.2": [ + "03.06.05.C" ], - "RSK-06.2": [ - "5.8" + "IRO-04.3": [ + "03.06.04.B" ], - "SEA-01": [ - "4" + "IRO-05": [ + "03.06.04.A", + "03.06.04.A.03" ], - "SEA-02": [ - "4" + "IRO-06": [ + "03.06.03" ], - "SEA-03": [ - "4" + "IRO-07": [ + "03.06.02.B", + "03.06.02.D" ], - "SAT-01": [ - "6.7" + "IRO-09": [ + "03.06.02.A", + "03.06.02.B" ], - "TDA-06": [ - "6.20" + "IRO-10": [ + "03.06.02.B", + "03.06.02.C", + "03.06.02.D" ], - "TPM-01": [ - "5.10" + "IRO-10.2": [ + "03.06.02.B", + "03.06.02.C" ], - "THR-01": [ - "6.2" + "IRO-11": [ + "03.06.02.D" ], - "VPM-01": [ - "6.16" + "IRO-12": [ + "03.01.22.B", + "03.06.01" ], - "VPM-05": [ - "6.16" + "IRO-13": [ + "03.06.04.B" ], - "VPM-06": [ - "6.15" + "IRO-14": [ + "03.06.02.C" ], - "VPM-07": [ - "6.15" - ] - }, - "americas-bra-lgpd-2018": { - "CLD-09": [ - "33", - "34" + "IAO-01": [ + "03.12.01" ], - "CPL-01": [ - "7.1", - "7.2", - "7.3", - "7.4", - "7.5", - "7.6", - "7.7", - "7.8", - "7.9", - "7.10" + "IAO-01.1": [ + "03.12.01" ], - "DCH-01": [ - "46", - "47" + "IAO-02": [ + "03.12.01" ], - "DCH-09.3": [ - "16" + "IAO-03": [ + "03.01.16.A", + "03.04.11.A", + "03.04.11.B", + "03.15.02.A", + "03.15.02.A.01", + "03.15.02.A.02", + "03.15.02.A.03", + "03.15.02.A.04", + "03.15.02.A.05", + "03.15.02.A.06", + "03.15.02.A.07", + "03.15.02.A.08", + "03.15.02.B" ], - "DCH-22.1": [ - "18.3" + "IAO-05": [ + "03.04.11.B", + "03.12.02.A", + "03.12.02.A.01", + "03.12.02.A.02", + "03.12.02.B", + "03.12.02.B.01", + "03.12.02.B.02", + "03.12.02.B.03", + "03.14.01.A" ], - "DCH-23": [ - "12" + "MNT-01": [ + "03.04.03.C", + "03.07.04.A", + "03.07.06.A" ], - "IRO-02": [ - "48" + "MNT-02": [ + "03.04.03.C", + "03.07.04.A", + "03.07.05.A" ], - "IRO-04.1": [ - "48" + "MNT-03": [ + "03.07.04.A" ], - "IRO-10": [ - "48" + "MNT-03.1": [ + "03.07.04.A" ], - "PRI-01": [ - "6.8", - "6.10", - "50" + "MNT-04": [ + "03.07.04.A" ], - "PRI-01.1": [ - "6.8", - "6.10" + "MNT-04.1": [ + "03.07.04.B" ], - "PRI-01.4": [ - "6.8", - "6.10", - "41" + "MNT-04.3": [ + "03.07.04.C" ], - "PRI-02": [ - "6.2", - "6.6", - "8" + "MNT-05": [ + "03.01.12.D", + "03.07.05.A", + "03.07.05.B", + "03.07.05.C" ], - "PRI-02.1": [ - "6.1", - "6.3" + "MNT-05.1": [ + "03.07.05.A" ], - "PRI-03": [ - "7.1", - "15" + "MNT-05.3": [ + "03.07.05.B" ], - "PRI-04": [ - "6.2" + "MNT-05.4": [ + "03.07.05.C" ], - "PRI-04.1": [ - "6.1", - "10", - "11" + "MNT-05.5": [ + "03.07.05.A" ], - "PRI-05": [ - "6.2", - "6.9", - "13", - "14", - "15", - "21" + "MNT-06": [ + "03.07.06.A", + "03.07.06.B", + "03.07.06.C", + "03.07.06.D" ], - "PRI-06": [ - "6.4", - "9", - "17", - "18.1", - "18.2", - "20" + "MNT-06.1": [ + "03.07.06.C", + "03.07.06.D" ], - "PRI-06.1": [ - "18.3" + "MNT-06.2": [ + "03.07.06.C" ], - "PRI-06.2": [ - "18.9" + "MNT-09": [ + "03.07.04.A" ], - "PRI-06.3": [ - "18.9" + "MDM-01": [ + "03.01.18.A", + "03.01.20.D" ], - "PRI-06.4": [ - "18", - "19", - "21" + "MDM-02": [ + "03.01.18.A", + "03.01.18.B" ], - "PRI-06.5": [ - "18.4", - "18.6" + "MDM-03": [ + "03.01.18.C" ], - "PRI-06.6": [ - "18.5", - "40" + "MDM-04": [ + "03.04.12.B" ], - "PRI-07.1": [ - "35", - "39" + "MDM-06": [ + "03.01.18.A", + "03.01.18.B" ], - "PRI-10": [ - "6.5" + "MDM-07": [ + "03.01.18.A", + "03.01.18.B", + "03.01.20.D" ], - "PRI-14": [ - "38" + "MDM-11": [ + "03.01.18.B" ], - "PRI-14.1": [ - "18.7", - "37" + "NET-01": [ + "03.01.12.A", + "03.01.16.A", + "03.01.18.A", + "03.13.01.A", + "03.14.08.B" ], - "PRM-04": [ - "6.8" + "NET-02": [ + "03.13.01.B" ], - "SEA-01": [ - "6.7", - "46", - "37", - "49" + "NET-02.2": [ + "03.01.16.A", + "03.01.16.B" ], - "SEA-02": [ - "6.7", - "46", - "37", - "49" + "NET-03": [ + "03.01.12.A", + "03.01.18.A", + "03.13.01.A", + "03.13.01.B", + "03.13.01.C" ], - "SEA-03": [ - "6.7", - "46", - "37", - "49" - ] - }, - "amaericas-can-osfi-self-assessment": { - "GOV-01": [ - "6.5", - "6.6", - "6.7", - "6.23" + "NET-03.8": [ + "03.13.01.B" ], - "GOV-01.1": [ - "6.5", - "6.6", - "6.7", - "6.21", - "6.22", - "6.23", - "6.24" + "NET-04": [ + "03.01.03", + "03.13.01.A", + "03.13.01.C" ], - "GOV-02": [ - "6.1", - "6.3" + "NET-04.1": [ + "03.13.01.A", + "03.13.06" ], - "GOV-04": [ - "1.1", - "1.2", - "6.2" + "NET-05": [ + "03.01.03", + "03.01.20.C.02", + "03.12.05.A", + "03.12.05.B" ], - "GOV-05": [ - "6.9" + "NET-05.2": [ + "03.01.03", + "03.12.05.B", + "03.12.05.C" ], - "GOV-07": [ - "3.7" + "NET-06": [ + "03.13.01.B" ], - "AST-02": [ - "3.1" + "NET-06.3": [ + "03.13.01.B" ], - "AST-02.5": [ - "4.21", - "4.24" + "NET-07": [ + "03.07.05.C", + "03.13.09" ], - "AST-04": [ - "3.1" + "NET-08": [ + "03.13.01.A", + "03.14.06.C" ], - "BCD-01": [ - "2.9" + "NET-08.1": [ + "03.13.01.B" ], - "BCD-01.2": [ - "2.9" + "NET-09": [ + "03.13.15" ], - "BCD-02.1": [ - "2.9" + "NET-14": [ + "03.01.12.A", + "03.01.12.B", + "03.01.12.C", + "03.14.08.B" ], - "BCD-02.2": [ - "2.9" + "NET-14.1": [ + "03.01.12.B" ], - "BCD-02.3": [ - "2.9" + "NET-14.2": [ + "03.01.12.A" ], - "BCD-03.1": [ - "2.8" + "NET-14.3": [ + "03.01.12.C" ], - "BCD-04": [ - "2.8" + "NET-14.4": [ + "03.01.12.D" ], - "BCD-04.1": [ - "2.8" + "NET-14.5": [ + "03.01.12.A", + "03.10.06.A", + "03.10.06.B" ], - "BCD-05": [ - "5.9" + "NET-15": [ + "03.01.16.A", + "03.01.16.B" ], - "CAP-04": [ - "3.1" + "NET-15.1": [ + "03.01.16.A", + "03.01.16.B", + "03.01.16.D" ], - "CHG-01": [ - "4.17", - "4.20", - "6.11" + "NET-15.2": [ + "03.01.16.C" ], - "CHG-02": [ - "4.18", - "4.20" + "NET-15.3": [ + "03.01.16.A", + "03.01.16.C" ], - "CHG-02.2": [ - "6.11" + "NET-18": [ + "03.14.06.C" ], - "CHG-02.3": [ - "2.4", - "6.11" + "PES-01": [ + "03.08.01", + "03.08.02", + "03.10.01.A", + "03.10.07.A", + "03.10.07.A.01" ], - "CHG-04.1": [ - "6.11" + "PES-02": [ + "03.04.05", + "03.08.01", + "03.08.02", + "03.10.01.A", + "03.10.01.B", + "03.10.01.C", + "03.10.01.D", + "03.10.07.A", + "03.10.07.A.01" ], - "CPL-01.1": [ - "6.10", - "6.14" + "PES-02.1": [ + "03.04.05", + "03.08.01", + "03.08.02", + "03.10.01.B", + "03.10.01.D" ], - "CPL-02": [ - "6.10" + "PES-03": [ + "03.04.05", + "03.10.02.A", + "03.10.07.A", + "03.10.07.A.01", + "03.10.07.A.02", + "03.10.07.D" ], - "CPL-02.1": [ - "6.17", - "6.18", - "6.19", - "6.20" + "PES-03.1": [ + "03.10.02.A", + "03.10.07.A", + "03.10.07.A.01", + "03.10.07.A.02" ], - "CPL-03": [ - "6.10" + "PES-03.3": [ + "03.10.02.A", + "03.10.07.A.02", + "03.10.07.B" ], - "CPL-03.1": [ - "6.13", - "6.25" + "PES-03.4": [ + "03.10.07.A.01", + "03.10.07.A.02" ], - "CFG-02": [ - "4.16", - "4.20" + "PES-04": [ + "03.08.01", + "03.08.02", + "03.10.07.A.01", + "03.10.07.A.02", + "03.10.07.D" ], - "CFG-02.8": [ - "4.19", - "4.20" + "PES-04.1": [ + "03.08.01", + "03.08.02", + "03.10.07.A.01", + "03.10.07.A.02", + "03.10.07.D" ], - "CFG-03.2": [ - "4.19", - "4.20" + "PES-05": [ + "03.10.02.A", + "03.10.02.B" ], - "CFG-03.3": [ - "4.19", - "4.20" + "PES-05.1": [ + "03.10.02.A" ], - "CFG-04.2": [ - "4.6", - "4.9" + "PES-05.2": [ + "03.10.02.A", + "03.10.02.B" ], - "CFG-05": [ - "4.19", - "4.20" + "PES-06": [ + "03.10.01.A", + "03.10.07.C" ], - "CFG-05.1": [ - "4.19", - "4.20" + "PES-06.1": [ + "03.10.01.A", + "03.10.07.C" ], - "CFG-05.2": [ - "4.19", - "4.20" + "PES-06.2": [ + "03.10.07.C" ], - "CFG-06": [ - "4.19", - "4.20" + "PES-06.3": [ + "03.10.07.C" ], - "CFG-06.1": [ - "4.19", - "4.20" + "PES-06.6": [ + "03.10.07.C" ], - "MON-01": [ - "3.5" + "PES-07": [ + "03.10.08" ], - "MON-01.1": [ - "3.3", - "4.3", - "4.4" + "PES-11": [ + "03.10.06.A", + "03.10.06.B" ], - "MON-01.2": [ - "3.4" + "PES-12": [ + "03.10.07.E", + "03.10.08" ], - "MON-01.4": [ - "3.6" + "PES-12.1": [ + "03.10.08" ], - "MON-01.8": [ - "3.5" + "PES-12.2": [ + "03.10.07.E" ], - "MON-01.16": [ - "3.5" + "PRM-01": [ + "03.16.01" ], - "MON-02": [ - "3.2" + "PRM-05": [ + "03.16.01" ], - "MON-02.1": [ - "3.6" + "RSK-01": [ + "03.11.01.A", + "03.17.01.A", + "03.17.03.B" ], - "END-01": [ - "4.3", - "4.4" + "RSK-01.1": [ + "03.11.01.A" ], - "END-02": [ - "4.3", - "4.4" + "RSK-02": [ + "03.11.01.A" ], - "END-04": [ - "4.3", - "4.4" + "RSK-02.1": [ + "03.11.01.A", + "03.14.03.B" ], - "END-05": [ - "4.3", - "4.4" + "RSK-03": [ + "03.11.01.A" ], - "END-07": [ - "4.3", - "4.4" + "RSK-03.1": [ + "03.11.01.A", + "03.15.02.A.03" ], - "END-08": [ - "4.3", - "4.4" + "RSK-04": [ + "03.11.01.A" ], - "END-08.1": [ - "4.3", - "4.4" + "RSK-04.1": [ + "03.12.02.A.01", + "03.12.02.A.02" ], - "HRS-01": [ - "1.5" + "RSK-05": [ + "03.11.01.A" ], - "HRS-03": [ - "1.2" + "RSK-06": [ + "03.11.02.B", + "03.12.02.A.02" ], - "HRS-03.2": [ - "1.5", - "1.7" + "RSK-06.1": [ + "03.11.02.B", + "03.11.04" ], - "HRS-04": [ - "1.6" + "RSK-06.2": [ + "03.11.02.B" ], - "HRS-04.1": [ - "1.6" - ], - "IAC-01": [ - "4.22", - "4.24" - ], - "IAC-16": [ - "4.23", - "4.24" - ], - "IRO-01": [ - "1.3", - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], - "IRO-02.5": [ - "3.6" - ], - "IRO-02.6": [ - "4.13", - "4.15" - ], - "IRO-04": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], - "IRO-04.2": [ - "5.9" - ], - "IRO-05": [ - "2.8" - ], - "IRO-05.1": [ - "2.8" - ], - "IRO-06": [ - "2.8" - ], - "IRO-06.1": [ - "2.8" - ], - "IRO-07": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], - "IRO-13": [ - "5.9" - ], - "IAO-03.2": [ - "4.26", - "4.28" - ], - "IAO-04": [ - "2.7" - ], - "IAO-05": [ - "5.9" - ], - "MDM-01": [ - "4.14", - "4.15" - ], - "NET-01": [ - "4.10", - "4.15" - ], - "NET-02": [ - "4.11", - "4.12", - "4.15" - ], - "NET-02.1": [ - "4.3", - "4.4" - ], - "NET-08": [ - "4.3", - "4.4" - ], - "NET-08.2": [ - "4.3", - "4.4" - ], - "NET-17": [ - "4.1", - "4.2" - ], - "PRM-01": [ - "1.1", - "6.22" - ], - "PRM-01.1": [ - "1.1", - "6.7" - ], - "PRM-01.2": [ - "6.7" - ], - "PRM-02": [ - "1.1", - "6.22" - ], - "PRM-03": [ - "6.22" - ], - "PRM-04": [ - "6.7" - ], - "PRM-05": [ - "6.7" - ], - "RSK-01": [ - "1.3", - "6.4", - "6.8", - "6.16", - "6.24" - ], - "RSK-01.1": [ - "6.15", - "6.24" - ], - "RSK-02": [ - "6.24" + "RSK-07": [ + "03.11.01.B" ], - "RSK-02.1": [ - "6.24" + "RSK-09": [ + "03.11.01.A", + "03.17.01.A", + "03.17.01.B", + "03.17.03.A", + "03.17.03.B" ], - "RSK-03": [ - "6.24" + "RSK-09.1": [ + "03.11.01.A", + "03.11.01.B", + "03.17.03.A" ], - "RSK-04": [ - "2.1", - "6.8" + "SEA-01": [ + "03.01.12.A", + "03.01.16.A", + "03.01.16.C", + "03.01.18.A", + "03.13.01.C", + "03.16.01" ], - "RSK-04.1": [ - "6.24" + "SEA-02": [ + "03.01.12.A", + "03.01.16.A", + "03.01.18.A", + "03.13.01.C", + "03.16.01" ], - "RSK-05": [ - "2.2" + "SEA-05": [ + "03.13.04" ], - "RSK-06": [ - "2.2", - "2.7", - "6.8" + "SEA-07": [ + "03.16.02.B" ], - "RSK-06.1": [ - "6.24" + "SEA-07.1": [ + "03.16.02.A", + "03.16.02.B" ], - "RSK-06.2": [ - "6.16", - "6.24" + "SEA-18": [ + "03.01.09" ], - "RSK-09": [ - "2.3", - "4.25" + "SEA-18.1": [ + "03.01.09" ], - "SEA-02.1": [ - "6.4" + "SEA-18.2": [ + "03.01.09" ], "OPS-01": [ - "1.3", - "1.5" + "03.15.01.A", + "03.15.01.B" ], - "OPS-02": [ - "4.30" + "OPS-01.1": [ + "03.15.01.A" ], "OPS-03": [ - "1.3", - "1.5" - ], - "OPS-04": [ - "1.4" - ], - "OPS-05": [ - "4.29", - "4.30" + "03.15.01.A" ], "SAT-01": [ - "1.7", - "1.8", - "1.9" + "03.02.01.A" + ], + "SAT-01.1": [ + "03.02.01.B", + "03.02.02.A.02", + "03.02.02.B", + "03.06.04.B" ], "SAT-02": [ - "1.8", - "1.9" + "03.01.22.A", + "03.02.01.A.01", + "03.02.01.A.02", + "03.02.01.A.03", + "03.06.04.A.03" ], "SAT-02.2": [ - "1.8", - "1.9" + "03.02.01.A.03" ], "SAT-03": [ - "1.7", - "1.8", - "1.9" - ], - "SAT-03.2": [ - "1.8", - "1.9" + "03.01.22.A", + "03.02.01.A.01", + "03.02.01.A.02", + "03.02.02.A", + "03.02.02.A.01", + "03.02.02.A.02", + "03.06.04.A", + "03.06.04.A.01", + "03.06.04.A.02", + "03.06.04.A.03" ], "SAT-03.3": [ - "1.7" + "03.01.22.A", + "03.02.01.A.01", + "03.02.02.A.01" ], "SAT-03.5": [ - "1.7" + "03.02.01.A.01", + "03.02.02.A.01" ], "SAT-03.6": [ - "1.7", - "1.8", - "1.9" + "03.02.01.A.01", + "03.02.01.A.02", + "03.02.01.A.03", + "03.02.02.A.01", + "03.02.02.A.02", + "03.06.04.A.02" ], "TDA-01": [ - "4.8", - "4.9" + "03.12.01", + "03.12.03", + "03.14.01.A", + "03.16.01", + "03.17.02" + ], + "TDA-01.1": [ + "03.12.03" + ], + "TDA-02": [ + "03.16.01" + ], + "TDA-02.3": [ + "03.16.01" + ], + "TDA-02.4": [ + "03.16.01" + ], + "TDA-03": [ + "03.16.01" + ], + "TDA-05": [ + "03.16.01" ], "TDA-06": [ - "4.8", - "4.9" + "03.16.01" ], "TDA-09": [ - "4.8", - "4.9" + "03.12.01", + "03.12.03", + "03.14.01.A" ], - "TDA-15": [ - "2.7" + "TDA-09.1": [ + "03.12.03" ], "TDA-17": [ - "4.6", - "4.9" + "03.16.02.A" + ], + "TDA-17.1": [ + "03.16.02.B" ], "TPM-01": [ - "2.3", - "4.25" + "03.01.20.A", + "03.01.20.B", + "03.01.20.C.01", + "03.07.06.A", + "03.16.01", + "03.16.03.A", + "03.17.02" + ], + "TPM-01.1": [ + "03.07.06.A", + "03.07.06.B" ], "TPM-02": [ - "2.3", - "4.27" + "03.11.01.A", + "03.17.03.A" ], "TPM-03": [ - "2.3", - "4.25" + "03.11.01.A", + "03.17.01.A", + "03.17.03.A", + "03.17.03.B" + ], + "TPM-03.1": [ + "03.17.01.A", + "03.17.02", + "03.17.03.A", + "03.17.03.B" ], "TPM-03.2": [ - "2.3", - "4.25" + "03.17.03.A", + "03.17.03.B" + ], + "TPM-03.3": [ + "03.17.03.A", + "03.17.03.B" ], "TPM-04": [ - "2.3", - "4.25" + "03.16.03.A", + "03.16.03.C", + "03.17.02", + "03.17.03.A", + "03.17.03.B" ], "TPM-04.1": [ - "2.3", - "4.25", - "4.27" + "03.11.01.A", + "03.17.02", + "03.17.03.A", + "03.17.03.B" + ], + "TPM-04.4": [ + "03.16.03.A" ], "TPM-05": [ - "2.3", - "4.26", - "4.28" + "03.01.20.B", + "03.01.20.C.01", + "03.01.20.C.02", + "03.07.06.A", + "03.16.03.A", + "03.16.03.B", + "03.16.03.C", + "03.17.02", + "03.17.03.B" ], - "TPM-06": [ - "2.3" + "TPM-05.1": [ + "03.17.02" ], - "TPM-07": [ - "4.27" + "TPM-05.2": [ + "03.16.03.A", + "03.16.03.B", + "03.16.03.C", + "03.17.02", + "03.17.03.B" + ], + "TPM-05.4": [ + "03.07.06.A", + "03.07.06.B", + "03.16.03.B" + ], + "TPM-05.5": [ + "03.16.03.C", + "03.17.02", + "03.17.03.A", + "03.17.03.B" + ], + "TPM-05.6": [ + "03.01.20.C.01", + "03.16.03.C" + ], + "TPM-05.7": [ + "03.17.01.A", + "03.17.02", + "03.17.03.B" + ], + "TPM-05.8": [ + "03.01.20.A", + "03.01.20.B", + "03.01.20.C.01", + "03.16.03.A", + "03.16.03.C" ], "TPM-08": [ - "4.27" + "03.16.03.C", + "03.17.02" ], "TPM-09": [ - "2.7", - "4.27" + "03.17.02" ], "TPM-10": [ - "4.27" - ], - "TPM-11": [ - "4.28" + "03.16.01", + "03.17.02" ], "THR-01": [ - "1.3" + "03.11.02.A", + "03.14.01.A", + "03.14.03.A" ], "THR-03": [ - "3.7" + "03.02.01.A.02", + "03.02.01.A.03", + "03.11.02.A", + "03.14.03.A" + ], + "THR-03.1": [ + "03.14.03.B" + ], + "THR-05": [ + "03.02.01.A.03" + ], + "THR-06": [ + "03.14.01.A" + ], + "THR-09": [ + "03.15.02.A.03" + ], + "THR-10": [ + "03.14.03.B" + ], + "VPM-01": [ + "03.11.02.A", + "03.14.01.A" + ], + "VPM-01.1": [ + "03.11.02.A", + "03.14.01.A" ], "VPM-02": [ - "2.7" + "03.11.02.B", + "03.12.02.A.02", + "03.14.01.A" + ], + "VPM-03": [ + "03.11.02.A" ], "VPM-04": [ - "2.7" + "03.11.02.B", + "03.14.01.A" ], "VPM-05": [ - "4.5", - "4.7", - "4.9" + "03.11.02.B", + "03.12.02.A.02", + "03.14.01.A", + "03.14.01.B" ], "VPM-06": [ - "2.5" + "03.11.02.A", + "03.14.01.A" ], - "VPM-07": [ - "2.6" + "VPM-06.1": [ + "03.11.02.C" ], - "WEB-03": [ - "4.3", - "4.4" + "WEB-01": [ + "03.01.22.A" + ], + "WEB-14": [ + "03.01.22.B" ] }, - "americas-can-osfi-b13-2022": { - "GOV-01": [ - "1", - "1.1.2", - "1.3.1", - "2.1.1", - "3" - ], - "GOV-01.1": [ - "1", - "1.1.2", - "1.3.1" - ], - "GOV-01.2": [ - "1", - "1.1.2" - ], + "americas-can-pipeda-2000": { "GOV-02": [ - "1", - "3" + "P1-4.1.4" ], - "GOV-03": [ - "1", - "1.3.1" + "CPL-01": [ + "P1-4.1", + "P1-4.1.3" ], - "GOV-04": [ - "1", - "1.1", - "1.1.1", - "1.1.2" + "CPL-05": [ + "P1-4.1.2" ], - "GOV-04.1": [ - "1", - "1.1", - "1.1.1", - "1.1.2" + "CFG-01": [ + "P7-4.7.3(c)" ], - "GOV-04.2": [ - "1", - "1.1.2" + "HRS-04.2": [ + "P1-4.1.4(d)" ], - "GOV-05": [ - "1", - "1.2", - "2.8.1" + "HRS-05.7": [ + "P1-4.1.4(d)" ], - "GOV-05.1": [ - "2.8.1" + "IAC-01": [ + "P7-4.7.3(b)" ], - "GOV-08": [ - "1.2", - "2.1.1" + "PES-01": [ + "P7-4.7.3(a)" ], - "GOV-09": [ - "1.2", - "2.1.1" + "PRI-01.1": [ + "P1-4.1", + "P1-4.1.1", + "P1-4.1.2" ], - "GOV-14": [ - "1.1.1", - "3.2.1" + "PRI-01.6": [ + "P1-4.1.4(a)", + "P7-4.7", + "P7-4.7.1", + "P7-4.7.2", + "P7-4.7.3" ], - "GOV-15": [ - "1.1.1", - "2.1.1", - "3.2.1" + "PRI-01.11": [ + "P1-4.1.4(a)", + "P3-4.3.3", + "P4-4.4.1", + "P4-4.4.2" ], - "GOV-15.1": [ - "1.1.1", - "2.1.1" + "PRI-02": [ + "P2-4.2", + "P2-4.2.1", + "P2-4.2.2", + "P2-4.2.3", + "P8-4.8", + "P8-4.8.1", + "P8-4.8.2", + "P8-4.8.2(a)", + "P8-4.8.2(b)", + "P8-4.8.2(c)", + "P8-4.8.2(d)", + "P8-4.8.2(e)", + "P8-4.8.3" ], - "GOV-15.2": [ - "1.1.1", - "2.1.1" + "PRI-02.1": [ + "P2-4.2" ], - "GOV-15.3": [ - "1.1.1", - "2.1.1" + "PRI-03": [ + "P2-4.2.5", + "P3-4.3", + "P3-4.3.1", + "P3-4.3.2", + "P3-4.3.3", + "P3-4.3.4", + "P3-4.3.5", + "P3-4.3.6", + "P3-4.3.7", + "P3-4.3.7(a)", + "P3-4.3.7(b)", + "P3-4.3.7(c)", + "P3-4.3.7(d)" ], - "GOV-15.4": [ - "1.1.1", - "2.1.1" + "PRI-03.2": [ + "P2-4.2.4" ], - "GOV-15.5": [ - "1.1.1", - "2.1.1" + "PRI-03.4": [ + "P3-4.3.8" ], - "AST-01": [ - "2.2", - "2.2.1", - "2.2.2", - "2.9.2" + "PRI-04": [ + "P4-4.4" ], - "AST-01.1": [ - "2.2", - "2.2.2", - "2.9.2" + "PRI-04.1": [ + "P4-4.4" ], - "AST-02": [ - "2.2", - "2.2.2", - "2.2.3" + "PRI-05": [ + "P5-4.5.3", + "P7-4.7.5" ], - "AST-02.9": [ - "2.2.3" + "PRI-05.2": [ + "P6-4.6", + "P6-4.6.1", + "P6-4.6.2", + "P6-4.6.3" ], - "AST-09": [ - "2.2", - "2.2.4" + "PRI-05.4": [ + "P5-4.5", + "P5-4.5.3" ], - "BCD-01": [ - "2.9", - "2.9.1" + "PRI-06": [ + "P9-4.9", + "P10-4.10" ], - "BCD-01.4": [ - "2.9", - "2.9.1" + "PRI-06.1": [ + "P9-4.9.5" ], - "BCD-01.5": [ - "2.9.1" + "PRI-06.4": [ + "P1-4.1.4(b)", + "P9-4.9.1", + "P9-4.9.4", + "P10-4.10.2", + "P10-4.10.3", + "P10-4.10.4" ], - "BCD-02": [ - "2.2.2", - "2.9.2" + "PRI-06.8": [ + "P9-4.9.2" ], - "BCD-04": [ - "2.9.3" + "PRI-07.1": [ + "P1-4.1.3" ], - "BCD-11": [ - "2.9.1" + "PRI-07.3": [ + "P9-4.9.6" ], - "CAP-01": [ - "2", - "2.8.2" + "PRI-14": [ + "P5-4.5.1" ], - "CAP-03": [ - "2.8.2" + "PRI-14.1": [ + "P9-4.9.3" ], - "CAP-04": [ - "2.8.2" + "PRI-17": [ + "P9-4.9.4" ], - "CHG-01": [ - "2.5", - "2.5.1" + "PRI-18": [ + "P9-4.9.6" ], - "CHG-02": [ - "2.5", - "2.5.1", - "2.5.3" + "RSK-10": [ + "P5-4.5.1" ], - "CHG-02.1": [ - "2.5", - "2.5.1" + "OPS-01.1": [ + "P5-4.5.2" ], - "CHG-02.2": [ - "2.5.1" + "OPS-03": [ + "P5-4.5.2" ], - "CHG-04": [ - "2.5", - "2.5.2" + "SAT-02": [ + "P1-4.1.4(c)", + "P7-4.7.4" + ] + }, + "americas-chl-act-19628-1999": { + "HRS-06.1": [ + "I.7" ], - "CHG-04.4": [ - "2.5", - "2.5.2" + "PRI-01.1": [ + "I.5" ], - "CPL-01": [ - "1.3.1" + "PRI-01.6": [ + "I.7", + "I.11" ], - "CPL-01.1": [ - "1.3.1" + "PRI-01.11": [ + "I.7", + "I.11" ], - "CPL-01.2": [ - "1.3.1" + "PRI-03": [ + "I.4", + "I.8" ], - "CFG-01": [ - "3.2.8" + "PRI-03.9": [ + "I.9" ], - "CFG-02": [ - "3.2.8" + "PRI-04.1": [ + "I.4" ], - "CFG-02.5": [ - "3.2.3" + "PRI-05": [ + "I.6" ], - "CFG-03": [ - "3.2.8" + "PRI-05.2": [ + "I.9" ], - "MON-01": [ - "3.3", - "3.3.1", - "3.3.2" + "PRI-05.4": [ + "I.6", + "I.10", + "II.15" ], - "MON-01.1": [ - "3.3.2" + "PRI-06": [ + "II.12", + "II.13", + "II.14" ], - "MON-01.2": [ - "3.3.1" + "PRI-15": [ + "I.5", + "I.5(a)", + "I.5(b)", + "I.5(c)" + ] + }, + "americas-col-law-1581-2012": { + "GOV-02": [ + "VI.17(k)" ], - "MON-01.8": [ - "3.3.1" + "CPL-01": [ + "VI.17", + "VI.17(o)", + "VI.18" ], - "MON-02": [ - "3.3.1" + "DCH-02": [ + "III.5" ], - "MON-02.1": [ - "3.3.1" + "HRS-06.1": [ + "II.4(h)" ], - "MON-02.2": [ - "3.3.1", - "3.3.2" + "IRO-10.2": [ + "VI.17(n)" ], - "MON-02.7": [ - "3.3.1" + "PRI-01": [ + "VI.18(a)", + "VI.18(b)", + "VI.18(c)", + "VI.18(d)", + "VI.18(e)", + "VI.18(f)", + "VI.18(g)", + "VI.18(h)", + "VI.18(i)", + "VI.18(j)", + "VI.18(k)", + "VI.18(l)" ], - "MON-03": [ - "3.2.7", - "3.3.1" + "PRI-01.6": [ + "II.4(g)", + "VI.17(d)" ], - "MON-11.3": [ - "3.3.2" + "PRI-01.11": [ + "II.4(d)", + "II.4(g)", + "VI.17(a)", + "VI.17(e)" ], - "MON-16": [ - "3.3.2" + "PRI-02": [ + "VI.17(c)" ], - "CRY-01": [ - "3.2.2" + "PRI-03": [ + "II.4(c)", + "VI.17(b)" ], - "CRY-09": [ - "3.2.2" + "PRI-03.2": [ + "VI.17(m)" ], - "DCH-01": [ - "2.9.2", - "3.1.4" + "PRI-03.4": [ + "IV.8(e)" ], - "DCH-01.2": [ - "2.9.2", - "3.1.4" + "PRI-03.13": [ + "III.7" ], - "DCH-02": [ - "2.2.2", - "3.1.4" + "PRI-05.2": [ + "VI.17(f)", + "VI.17(g)" ], - "DCH-06.2": [ - "2.2.2", - "3.1.4" + "PRI-05.4": [ + "II.4(f)", + "III.6", + "III.6(a)", + "III.6(b)", + "III.6(c)", + "III.6(d)", + "III.6(e)", + "III.7" ], - "DCH-19": [ - "2.9.2", - "3.1.4" + "PRI-06": [ + "II.4(e)", + "IV.8(a)", + "IV.8(b)", + "IV.8(c)", + "IV.8(f)", + "IV.11", + "V.14", + "V.15", + "V.15.1" ], - "HRS-11": [ - "2.5.2" + "PRI-06.4": [ + "IV.12(a)", + "IV.12(b)", + "IV.12(c)", + "IV.12(d)", + "V.15.2", + "V.15.3", + "VI.17(j)" ], - "IAC-01": [ - "3.2.7" + "PRI-06.8": [ + "IV.9", + "IV.12" ], - "IAC-06": [ - "3.2.7" + "PRI-07": [ + "VI.17(h)" ], - "IAC-16": [ - "3.2.7" + "PRI-07.1": [ + "VI.17(i)" ], - "IAC-21": [ - "3.2.7" + "PRI-07.3": [ + "VI.17(l)" + ] + }, + "americas-mex-fdpa-2010": { + "DCH-18.1": [ + "II.13" ], - "IRO-01": [ - "2.7", - "2.7.2", - "3.3", - "3.4.1" + "DCH-22.1": [ + "III.24", + "IV.28" ], - "IRO-02": [ - "2.7", - "2.7.1", - "2.7.2", - "3.3", - "3.3.3", - "3.4.1", - "3.4.3", - "3.4.4" + "IRO-10": [ + "II.20" ], - "IRO-02.4": [ - "2.7", - "3.4.2" + "PRI-01": [ + "II.6", + "II.14" ], - "IRO-03": [ - "2.7.2", - "3.1" + "PRI-01.4": [ + "IV.30" ], - "IRO-04": [ - "2.7.1", - "2.7.2", - "3.4.3" + "PRI-01.6": [ + "II.19", + "II.21" ], - "IRO-04.2": [ - "2.7.3" + "PRI-01.9": [ + "IV.30" ], - "IRO-06": [ - "2.7.2" + "PRI-01.11": [ + "II.6", + "II.7", + "II.9", + "II.10", + "II.10.I", + "II.10.II", + "II.10.III", + "II.10.IV", + "II.10.V", + "II.10.VI", + "II.10.VII", + "III.26", + "III.26.I", + "III.26.II", + "III.26.III", + "III.26.IV", + "III.26.V", + "III.26.VI", + "III.26.VII", + "IV.34", + "IV.35" ], - "IRO-06.1": [ - "3.4.1" + "PRI-02": [ + "II.7", + "II.12", + "II.15", + "II.16", + "II.16.I", + "II.16.II", + "II.16.III", + "II.16.IV", + "II.16.V", + "II.16.VI", + "II.17", + "II.17.I", + "II.17.II", + "II.18", + "V.36" ], - "IRO-07": [ - "2.7.2", - "3.3.3", - "3.4.4" + "PRI-02.1": [ + "II.16.II" ], - "IRO-08": [ - "3.4.5" + "PRI-03": [ + "II.8", + "II.9" ], - "IRO-09": [ - "2.7" + "PRI-03.2": [ + "II.16.VI" ], - "IRO-10": [ - "3.4.1" + "PRI-03.4": [ + "II.8", + "III.25" ], - "IRO-13": [ - "2.7.3", - "3.4", - "3.4.5" + "PRI-04": [ + "II.7", + "II.12" ], - "IAO-01": [ - "2.4.4" + "PRI-04.1": [ + "II.7" ], - "IAO-01.1": [ - "2.4.4" + "PRI-05": [ + "II.11" ], - "IAO-02": [ - "2.4.4" + "PRI-05.2": [ + "II.11" ], - "NET-02": [ - "3.2.4" + "PRI-05.4": [ + "II.7", + "II.13", + "V.37", + "V.37.I", + "V.37.II", + "V.37.III", + "V.37.IV", + "V.37.V", + "V.37.VI", + "V.37.VII" ], - "NET-06": [ - "3.2.5" + "PRI-06": [ + "II.16.III", + "III.22", + "III.23", + "III.25", + "III.27", + "IV.28", + "IV.29", + "IV.29.I", + "IV.29.II", + "IV.29.III", + "IV.29.IV", + "IV.31" ], - "NET-17": [ - "3.2.5" + "PRI-06.1": [ + "III.24", + "IV.28" ], - "PES-01": [ - "3.2.10" + "PRI-06.4": [ + "IV.32", + "IV.33" ], - "PES-03": [ - "3.2.10" + "PRI-07.1": [ + "II.21" ], - "PRM-01": [ - "1.2.1" + "PRI-07.5": [ + "IV.34", + "IV.34.I", + "IV.34.II", + "IV.34.III", + "IV.34.IV", + "IV.34.V" + ] + } + }, + "framework_to_scf": { + "general-aicpa-pmf-2020": { + "M1.2-POF6": [ + "GOV-01", + "CPL-01.1" ], - "PRM-01.1": [ - "1.2.1" + "M1.3-POF4": [ + "GOV-01.3", + "GOV-03" ], - "PRM-01.2": [ - "1.2.1" + "M1.0": [ + "GOV-02", + "PRI-01" ], - "PRM-02": [ - "1.2.1" + "M1.2": [ + "GOV-02", + "PRI-01" ], - "PRM-03": [ - "1.2.1" + "M1.2-POF8": [ + "GOV-02" ], - "PRM-04": [ - "1.2.1", - "2.3", - "2.3.1", - "2.4.1" + "D6.1-POF1": [ + "GOV-02", + "PRI-01" ], - "PRM-05": [ - "1.2.1", - "2.3", - "2.4.1", - "2.4.2", - "2.4.3", - "2.8" + "M1.2-POF5": [ + "GOV-03" ], - "PRM-06": [ - "1.2.1", - "2.1", - "2.3", - "2.4.1", - "2.4.3", - "2.8" + "M1.2-POF1": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "PRI-01.1" ], - "PRM-07": [ - "2.4", - "2.4.1", - "2.4.3" + "M1.2-POF2": [ + "GOV-04.1" ], - "RSK-01": [ - "1.3", - "1.3.1", - "1.3.2", - "3.1.1" + "S7.1-POF1": [ + "AST-01" ], - "RSK-01.1": [ - "1.3", - "3.1.8" + "M1.4": [ + "AST-02", + "DCH-06.2", + "PRI-05.5" ], - "RSK-01.3": [ - "3.1.8" + "S7.2-POF2": [ + "AST-11" ], - "RSK-01.4": [ - "3.1.8" + "S7.4-POF1": [ + "BCD-01" ], - "RSK-01.5": [ - "1.3", - "3.1.8" + "S7.5-POF3": [ + "BCD-04" ], - "RSK-03": [ - "1.3", - "3.1.1" + "S7.5-POF4": [ + "BCD-11.1", + "BCD-11.5" ], - "RSK-03.1": [ - "3.1.1" + "M1.2-POF9": [ + "CPL-01" ], - "RSK-04": [ - "1.3", - "3.1.1" + "M1.2-POF7": [ + "CPL-01.1" ], - "RSK-04.1": [ - "1.3", - "3.1.1" + "M9.1-POF4": [ + "CPL-01.1" ], - "RSK-06.2": [ - "3.2.6" + "M9.1-POF5": [ + "CPL-01.1" ], - "SEA-01": [ - "1.3.1", - "2", - "2.1", - "2.1.2", - "3.2", - "3.2.1" + "M1.0-POF8": [ + "CPL-02" ], - "SEA-01.1": [ - "1.3.1" + "S7.5-POF1": [ + "CPL-02", + "CPL-03" ], - "SEA-01.2": [ - "2", - "2.1.2", - "3.2.1" + "M9.1-POF6": [ + "CPL-02" ], - "SEA-02": [ - "2", - "2.1", - "2.1.2" + "S7.5": [ + "CPL-03", + "CPL-03.2" ], - "SEA-02.1": [ - "A.1" + "S7.1-POF8": [ + "CFG-01", + "IAC-01" ], - "SEA-03": [ - "3.2", - "3.2.4" + "S7.1-POF2": [ + "MON-01", + "IAC-01", + "PES-01" ], - "SEA-07.1": [ - "1.3.1", - "2.2", - "2.2.5" + "S7.1-POF9": [ + "CRY-01" ], - "OPS-01": [ - "3" + "S7.3-POF2": [ + "CRY-03", + "CRY-05" ], - "OPS-01.1": [ - "2.2.1", - "2.8", - "3" + "S7.1-POF10": [ + "CRY-09" ], - "OPS-02": [ - "1.3.2" + "M1.0-POF4": [ + "DCH-01", + "DCH-01.2", + "DCH-01.4", + "IAC-20" ], - "OPS-03": [ - "2.2.1", - "2.8" + "S7.4": [ + "DCH-01", + "DCH-01.2" ], - "SAT-01": [ - "3.1.7" + "M1.3": [ + "DCH-02", + "PRI-05.7" ], - "SAT-02": [ - "3.1.7" + "M1.0-POF5": [ + "DCH-03.1", + "PRI-01.7" ], - "SAT-03": [ - "3.1.7" + "S7.3-POF4": [ + "DCH-12" ], - "SAT-03.1": [ - "3.1.7" + "S7.3": [ + "DCH-17", + "DCH-25", + "PRI-07" ], - "SAT-03.2": [ - "3.1.7" + "U4.2-POF1": [ + "DCH-18", + "PRI-05" ], - "TDA-01": [ - "2.4.3" + "U4.2-POF2": [ + "DCH-18" ], - "TDA-01.1": [ - "2.4.3" - ], - "TDA-02.3": [ - "2.4.3", - "2.4.5" + "M1.0-POF7": [ + "DCH-22", + "PRI-05.2" ], - "TDA-06": [ - "2.4.5" + "D6.1": [ + "DCH-25", + "PRI-01.7" ], - "TDA-06.1": [ - "2.4.5" + "S7.3-POF3": [ + "END-01", + "END-01.1" ], - "TDA-06.2": [ - "2.4.4", - "3.1.6" + "S7.1-POF11": [ + "END-04", + "END-04.1" ], - "TDA-06.5": [ - "2.4.1", - "2.4.2" + "M1.2-POF3": [ + "HRS-03", + "HRS-03.1", + "HRS-04.2", + "SAT-03", + "SAT-03.3" ], - "TDA-09": [ - "3.2.9" + "M1.2-POF4": [ + "HRS-03.2" ], - "TDA-09.2": [ - "3.2.9" + "S7.1": [ + "IAC-01" ], - "TDA-09.3": [ - "3.2.9" + "S7.1-POF3": [ + "IAC-01" ], - "TDA-17": [ - "2.2.5" + "S7.1-POF6": [ + "IAC-01", + "PES-01" ], - "THR-01": [ - "3.0", - "3.1", - "3.1.1", - "3.1.6" + "S7.1-POF7": [ + "IAC-01" ], - "THR-02": [ - "3.1" + "M1.3-POF3": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "THR-03": [ - "3.0", - "3.1", - "3.1.1", - "3.1.5" + "D6.6": [ + "IRO-04.1", + "IRO-10", + "IRO-10.2" ], - "THR-04": [ - "3.0" + "D6.6-POF2": [ + "IRO-04.1", + "IRO-10", + "IRO-10.2" ], - "THR-07": [ - "3.0" + "S7.5-POF2": [ + "IRO-06" ], - "THR-09": [ - "3.0", - "3.1.6" + "S7.1-POF5": [ + "NET-01" ], - "THR-10": [ - "3.1", - "3.1.1", - "3.1.2", - "3.1.6" + "S7.1-POF4": [ + "NET-06" ], - "VPM-01": [ - "2.6", - "3.1" + "S7.3-POF1": [ + "NET-17" ], - "VPM-02": [ - "2.6" + "S7.2-POF1": [ + "PES-02" ], - "VPM-03": [ - "3.1.3" + "S7.2-POF3": [ + "PES-02", + "PES-02.1" ], - "VPM-04": [ - "3.2.6" + "S7.2": [ + "PES-02.1", + "PES-03" ], - "VPM-05": [ - "2.6", - "2.6.1", - "3.2.6" + "S7.2-POF4": [ + "PES-03" ], - "VPM-06": [ - "3.1.2", - "3.1.3" + "S7.2-POF5": [ + "PES-03", + "PES-03.2", + "PES-03.4", + "PES-04" ], - "VPM-07": [ - "3.1.2" - ] - }, - "americas-can-itsp-10-171-2025": { - "GOV-01": [ - "03.15.01.A" + "S7.2-POF6": [ + "PES-07", + "PES-07.1", + "PES-07.2", + "PES-07.3", + "PES-07.4", + "PES-07.5", + "THR-09" ], - "GOV-01.1": [ - "03.12.03" + "N2.2-POF1": [ + "PRI-01", + "PRI-01.1", + "PRI-01.11" ], - "GOV-01.2": [ - "03.12.03" + "M1.0-POF1": [ + "PRI-01.3", + "PRI-02" ], - "GOV-02": [ - "03.15.01.A" + "M1.0-POF6": [ + "PRI-01.6" ], - "GOV-03": [ - "03.15.01.B", - "03.15.03.D" + "M1.4-POF1": [ + "PRI-01.6" ], - "GOV-05": [ - "03.12.03" + "D6.1-POF2": [ + "PRI-01.7" ], - "GOV-15": [ - "03.15.01.A", - "03.17.01.A" + "N2.1": [ + "PRI-02" ], - "GOV-15.1": [ - "03.15.01.A", - "03.17.01.A" + "N2.1-POF2": [ + "PRI-02", + "PRI-03.2" ], - "GOV-15.2": [ - "03.15.01.A", - "03.17.01.A" + "N2.1-POF3": [ + "PRI-02" ], - "GOV-15.3": [ - "03.15.01.A", - "03.17.01.A" + "N2.1-POF4": [ + "PRI-02" ], - "GOV-15.4": [ - "03.15.01.A", - "03.17.01.A" + "N2.2": [ + "PRI-02", + "PRI-03.2" ], - "GOV-15.5": [ - "03.15.01.A", - "03.17.01.A" + "C3.1-POF3": [ + "PRI-02", + "PRI-03", + "PRI-03.5" ], - "AST-01": [ - "03.01.03", - "03.01.18.A", - "03.04.11.A", - "03.07.04.A" + "M9.1-POF1": [ + "PRI-02" ], - "AST-01.1": [ - "03.01.03" + "C3.2-POF1": [ + "PRI-02.1", + "PRI-03.2" ], - "AST-02": [ - "03.04.08.A", - "03.04.08.C", - "03.04.10.A", - "03.04.10.B", - "03.04.11.A" + "N2.1-POF1": [ + "PRI-03", + "PRI-03.2" ], - "AST-02.1": [ - "03.04.10.A", - "03.04.10.B", - "03.04.10.C" + "C3.1": [ + "PRI-03" ], - "AST-02.4": [ - "03.04.02.B", - "03.04.06.A" + "C3.1-POF1": [ + "PRI-03" ], - "AST-02.8": [ - "03.04.11.A", - "03.04.11.B" + "C3.2": [ + "PRI-03" ], - "AST-02.9": [ - "03.04.08.A", - "03.04.10.A", - "03.04.10.B", - "03.04.10.C" + "C3.2-POF2": [ + "PRI-03", + "PRI-03.12" ], - "AST-03": [ - "03.09.02.A.03" + "C3.2-POF3": [ + "PRI-03", + "PRI-03.12" ], - "AST-03.1": [ - "03.09.02.A.03" + "C3.2-POF4": [ + "PRI-03" ], - "AST-04": [ - "03.01.03", - "03.04.11.A", - "03.04.11.B" + "N2.1-POF5": [ + "PRI-03.4" ], - "AST-04.1": [ - "03.04.11.A", - "03.04.11.B" + "C3.1-POF2": [ + "PRI-03.5", + "PRI-21" ], - "AST-04.2": [ - "03.04.11.A", - "03.04.11.B", - "03.15.02.A.04" + "M1.0-POF2": [ + "PRI-04", + "PRI-04.1", + "PRI-04.7" ], - "AST-04.3": [ - "03.01.03" + "C3.1-POF4": [ + "PRI-04" ], - "AST-05": [ - "03.07.04.A" + "U4.2": [ + "PRI-05" ], - "AST-09": [ - "03.07.04.C", - "03.08.03" + "U4.3": [ + "PRI-05" ], - "AST-10": [ - "03.09.02.A.03" + "U4.3-POF1": [ + "PRI-05" ], - "AST-12": [ - "03.01.18.A" + "U4.3-POF2": [ + "PRI-05" ], - "AST-13": [ - "03.01.18.A" + "U4.3-POF3": [ + "PRI-05" ], - "AST-14": [ - "03.01.18.A" + "Q8.1": [ + "PRI-05.2" ], - "AST-16": [ - "03.01.18.A" + "Q8.1-POF2": [ + "PRI-05.2" ], - "AST-17": [ - "03.11.01.A", - "03.16.01" + "M1.0-POF3": [ + "PRI-05.4" ], - "AST-24": [ - "03.04.12.A", - "03.04.12.B" + "U4.1": [ + "PRI-05.4" ], - "AST-25": [ - "03.04.12.B" + "U4.1-POF1": [ + "PRI-05.4" ], - "AST-27": [ - "03.01.12.A", - "03.01.12.C" + "Q8.1-POF3": [ + "PRI-05.4" ], - "AST-31": [ - "03.01.03" + "M1.3-POF1": [ + "PRI-05.7" ], - "BCD-11": [ - "03.08.09.A" + "D6.7": [ + "PRI-05.7", + "PRI-06", + "PRI-06.7" ], - "BCD-11.4": [ - "03.08.09.A", - "03.08.09.B" + "A5.1": [ + "PRI-06" ], - "CHG-01": [ - "03.04.02.B", - "03.04.03.A" + "A5.1-POF2": [ + "PRI-06" ], - "CHG-02": [ - "03.04.02.B", - "03.04.03.A", - "03.04.03.B", - "03.04.03.C" + "D6.7-POF1": [ + "PRI-06" ], - "CHG-02.1": [ - "03.04.02.B", - "03.04.03.A" + "D6.7-POF2": [ + "PRI-06" ], - "CHG-02.2": [ - "03.04.03.B", - "03.04.03.C", - "03.04.04.A", - "03.04.11.B" + "A5.2": [ + "PRI-06.1" ], - "CHG-02.3": [ - "03.04.04.A" + "A5.2-POF2": [ + "PRI-06.1" ], - "CHG-03": [ - "03.04.03.B", - "03.04.04.A", - "03.04.11.B" + "A5.1-POF4": [ + "PRI-06.4" ], - "CHG-04": [ - "03.04.02.B", - "03.04.05" + "A5.2-POF1": [ + "PRI-06.4" ], - "CHG-04.4": [ - "03.04.05" + "A5.2-POF3": [ + "PRI-06.4" ], - "CHG-05": [ - "03.04.11.B" + "M9.1": [ + "PRI-06.4" ], - "CHG-06": [ - "03.04.04.B" + "M9.1-POF2": [ + "PRI-06.4" ], - "CPL-01": [ - "03.04.11.A", - "03.12.01" + "M9.1-POF3": [ + "PRI-06.4" ], - "CPL-01.1": [ - "03.12.02.A.01" + "A5.1-POF3": [ + "PRI-06.7" ], - "CPL-01.2": [ - "03.04.11.A", - "03.15.02.A.04" + "A5.1-POF1": [ + "PRI-06.8" ], - "CPL-02": [ - "03.12.01", - "03.12.03" + "D6.1-POF3": [ + "PRI-07" ], - "CPL-02.1": [ - "03.12.01" + "D6.1-POF4": [ + "PRI-07" ], - "CPL-03": [ - "03.12.01", - "03.12.03" + "D6.4-POF1": [ + "PRI-07", + "TPM-04.1" ], - "CPL-03.2": [ - "03.04.08.C", - "03.12.03" + "D6.4": [ + "PRI-07.1" ], - "CFG-01": [ - "03.04.01.A" + "D6.2": [ + "PRI-14", + "PRI-14.1" ], - "CFG-02": [ - "03.01.01.H", - "03.01.08.A", - "03.01.08.B", - "03.01.09", - "03.01.10.A", - "03.01.10.B", - "03.01.10.C", - "03.01.11", - "03.01.12.A", - "03.01.16.A", - "03.01.18.A", - "03.04.01.A", - "03.04.02.A", - "03.04.06.A", - "03.04.06.B", - "03.04.06.D", - "03.05.07.D", - "03.05.07.E", - "03.05.07.F", - "03.05.12.D", - "03.08.07.A", - "03.13.12.B" + "D6.2-POF1": [ + "PRI-14", + "PRI-14.1" ], - "CFG-02.1": [ - "03.04.01.B", - "03.04.02.B" + "D6.3": [ + "PRI-14.1" ], - "CFG-02.2": [ - "03.04.02.B", - "03.04.03.D" + "D6.3-POF1": [ + "PRI-14.1" ], - "CFG-02.5": [ - "03.04.01.A", - "03.04.02.A", - "03.04.06.A", - "03.04.06.B", - "03.04.06.D", - "03.04.12.A" + "M1.3-POF2": [ + "RSK-10" ], - "CFG-02.7": [ - "03.04.01.A", - "03.04.02.B" + "D6.5": [ + "TPM-05" ], - "CFG-02.9": [ - "03.03.02.B", - "03.04.01.A", - "03.04.02.A", - "03.04.02.B", - "03.04.06.A", - "03.04.08.A", - "03.04.12.A", - "03.13.11" + "D6.5-POF2": [ + "TPM-05", + "TPM-05.2" ], - "CFG-03": [ - "03.04.02.A", - "03.04.06.A", - "03.04.06.B", - "03.04.06.D", - "03.04.08.A" + "D6.5-POF1": [ + "TPM-05.7", + "TPM-09" ], - "CFG-03.1": [ - "03.04.06.C", - "03.04.08.C" + "D6.6-POF1": [ + "TPM-05.7", + "TPM-09" + ] + }, + "general-aicpa-tsc-2017": { + "CC1.1": [ + "GOV-01", + "GOV-04", + "CPL-02", + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-07.1" ], - "CFG-03.2": [ - "03.04.08.B" + "CC1.1-POF1": [ + "GOV-01", + "GOV-14", + "HRS-01" ], - "CFG-03.3": [ - "03.04.08.A", - "03.04.08.B", - "03.13.13.A", - "03.13.13.B" + "CC1.2": [ + "GOV-01", + "GOV-01.1", + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "HRS-02", + "HRS-03", + "HRS-03.2" ], - "CFG-04": [ - "03.13.13.B" + "CC2.3-POF5": [ + "GOV-01", + "GOV-01.2", + "CPL-01" ], - "CFG-04.1": [ - "03.13.13.B" + "CC1.2-POF1": [ + "GOV-01.1", + "GOV-02", + "GOV-04.1", + "GOV-04.2", + "GOV-08", + "GOV-10", + "HRS-01", + "HRS-02", + "HRS-03" ], - "CFG-05": [ - "03.13.13.B" + "CC1.2-POF2": [ + "GOV-01.1", + "HRS-01", + "HRS-02", + "HRS-03", + "HRS-03.2" ], - "CFG-06": [ - "03.04.02.A", - "03.04.02.B", - "03.04.03.A" + "CC1.2-POF3": [ + "GOV-01.1", + "HRS-01", + "HRS-02" ], - "CFG-08": [ - "03.01.02" + "CC1.2-POF4": [ + "GOV-01.1", + "HRS-01", + "HRS-02", + "HRS-03.2" ], - "MON-01": [ - "03.03.01.A", - "03.12.03", - "03.14.06.A" + "CC1.3-POF1": [ + "GOV-01.1", + "GOV-04.1", + "GOV-04.2" ], - "MON-01.1": [ - "03.13.01.A" + "CC1.3-POF3": [ + "GOV-01.1", + "GOV-04.1", + "GOV-04.2", + "HRS-03", + "TPM-05.4" ], - "MON-01.3": [ - "03.13.01.A", - "03.14.06.C" + "CC1.5-POF3": [ + "GOV-01.1", + "HRS-01" ], - "MON-01.4": [ - "03.03.01.A", - "03.03.03.A", - "03.14.06.A.01", - "03.14.06.B", - "03.14.06.C" + "CC1.5-POF4": [ + "GOV-01.1", + "HRS-01" ], - "MON-01.8": [ - "03.03.01.B", - "03.03.05.A" + "CC1.5-POF5": [ + "GOV-01.1", + "GOV-05", + "HRS-01", + "HRS-07" ], - "MON-01.12": [ - "03.03.04.A", - "03.03.05.B" + "CC2.2-POF4": [ + "GOV-01.1", + "GOV-06", + "GOV-07" ], - "MON-01.15": [ - "03.01.07.B" + "CC2.2-POF12": [ + "GOV-01.1", + "SAT-01", + "SAT-02", + "SAT-03" ], - "MON-02": [ - "03.03.05.A", - "03.03.05.C" + "CC2.3-POF3": [ + "GOV-01.1", + "GOV-01.2" ], - "MON-02.1": [ - "03.03.05.A", - "03.03.05.C" + "CC3.1-POF11": [ + "GOV-01.1", + "GOV-01.2", + "PRM-06", + "OPS-03" ], - "MON-02.2": [ - "03.03.01.B", - "03.03.05.A", - "03.03.05.C" + "CC3.4-POF3": [ + "GOV-01.1", + "RSK-01", + "RSK-03", + "RSK-04" ], - "MON-02.3": [ - "03.03.05.C" + "CC4.2": [ + "GOV-01.1", + "GOV-01.2", + "CPL-01.1", + "IAO-04", + "IAO-05", + "RSK-06", + "TDA-15", + "TPM-09", + "VPM-02", + "VPM-04" ], - "MON-02.7": [ - "03.03.01.A" + "CC4.2-POF1": [ + "GOV-01.1", + "GOV-01.2", + "GOV-05", + "GOV-15.3", + "CPL-01.1", + "CPL-02" ], - "MON-03": [ - "03.03.01.A", - "03.03.02.A", - "03.03.02.A.01", - "03.03.02.A.02", - "03.03.02.A.03", - "03.03.02.A.04", - "03.03.02.A.05", - "03.03.02.A.06", - "03.03.02.B" + "CC4.2-POF2": [ + "GOV-01.1", + "GOV-01.2", + "CPL-01.1", + "CPL-02" ], - "MON-03.2": [ - "03.03.01.A" + "CC2.2-POF2": [ + "GOV-01.2" ], - "MON-03.3": [ - "03.01.07.B" + "CC3.1-POF10": [ + "GOV-01.2", + "GOV-06", + "GOV-17", + "PRM-06", + "OPS-03" ], - "MON-05": [ - "03.03.04.B" + "CC1.4-POF1": [ + "GOV-02", + "HRS-01" ], - "MON-06": [ - "03.03.05.B", - "03.03.06.A" + "CC2.2-POF1": [ + "GOV-02", + "GOV-09", + "OPS-03" ], - "MON-07": [ - "03.03.02.A.02", - "03.03.07.A" + "CC2.2-POF7": [ + "GOV-02", + "GOV-03", + "GOV-09" ], - "MON-07.1": [ - "03.03.07.B" + "CC5.3": [ + "GOV-02", + "GOV-03", + "HRS-03.2", + "HRS-10", + "OPS-01.1" ], - "MON-08": [ - "03.03.03.B", - "03.03.06.B", - "03.03.08.A" + "CC5.3-POF1": [ + "GOV-02", + "GOV-14" ], - "MON-08.1": [ - "03.03.08.A" + "CC7.2-POF1": [ + "GOV-02", + "MON-01", + "MON-01.2", + "MON-02", + "OPS-01.1" ], - "MON-08.2": [ - "03.03.08.A", - "03.03.08.B" + "P1.1-POF5": [ + "GOV-02", + "PRI-02" ], - "MON-08.3": [ - "03.03.08.A" + "CC5.3-POF6": [ + "GOV-03", + "GOV-05" ], - "MON-10": [ - "03.03.03.B" + "CC1.3": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "HRS-03", + "HRS-03.2", + "PRM-06" ], - "MON-11": [ - "03.01.22.B" + "CC5.3-POF2": [ + "GOV-04", + "GOV-04.1", + "HRS-03" ], - "MON-11.3": [ - "03.14.06.A.01", - "03.14.06.A.02", - "03.14.06.B", - "03.14.06.C" + "CC1.3-POF2": [ + "GOV-04.1", + "GOV-04.2" ], - "MON-16": [ - "03.01.01.E", - "03.03.05.A", - "03.14.06.A.01", - "03.14.06.A.02", - "03.14.06.B", - "03.14.06.C" + "CC1.3-POF4": [ + "GOV-04.1", + "GOV-04.2", + "HRS-03", + "TPM-05.4" ], - "CRY-01": [ - "03.13.08", - "03.13.11" + "CC1.3-POF5": [ + "GOV-04.1", + "GOV-04.2", + "HRS-03", + "TPM-05.4" ], - "CRY-01.1": [ - "03.13.08" + "CC1.3-POF6": [ + "GOV-04.1", + "GOV-04.2", + "HRS-01", + "PRI-01", + "TPM-04.3" ], - "CRY-01.5": [ - "03.13.11" + "CC1.5-POF1": [ + "GOV-04.1", + "GOV-04.2", + "HRS-03" ], - "CRY-03": [ - "03.13.08" + "CC1.1-POF3": [ + "GOV-05", + "CPL-02", + "CPL-03", + "HRS-01" ], - "CRY-05": [ - "03.13.08" + "CC1.5": [ + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "CPL-01", + "CPL-01.1", + "HRS-03.2", + "HRS-06", + "HRS-06.1", + "HRS-07", + "HRS-07.1", + "HRS-08", + "HRS-09", + "HRS-09.1", + "HRS-09.2", + "HRS-09.3" ], - "CRY-05.1": [ - "03.13.08" + "CC1.5-POF2": [ + "GOV-05", + "HRS-01" ], - "CRY-07": [ - "03.01.16.A" + "CC2.1-POF4": [ + "GOV-05", + "GOV-15", + "DCH-22", + "OPS-03" ], - "CRY-08": [ - "03.13.10" + "CC2.2": [ + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "GOV-09", + "CPL-01", + "CPL-02", + "HRS-03", + "PRM-01", + "PRM-05", + "SEA-01", + "SEA-02.1", + "OPS-01", + "OPS-01.1" ], - "CRY-09": [ - "03.13.10" + "CC4.1": [ + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "CPL-03", + "CPL-03.2", + "CPL-04", + "IAO-01", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-03.1", + "IAO-04", + "IAO-06", + "PRM-03", + "PRM-04", + "PRM-05", + "PRM-06", + "RSK-01", + "RSK-09", + "SEA-02" ], - "CRY-09.3": [ - "03.13.10" + "CC4.1-POF2": [ + "GOV-05", + "CPL-02.1" ], - "CRY-09.4": [ - "03.13.10" + "CC2.3": [ + "GOV-06", + "GOV-07", + "CPL-01", + "CPL-02", + "IRO-10", + "IRO-14", + "PRI-14" ], - "DCH-01": [ - "03.01.01.D.01", - "03.01.01.D.02", - "03.08.01" + "CC2.2-POF10": [ + "GOV-08", + "IRO-01", + "IRO-02", + "IRO-02.4", + "IRO-04" ], - "DCH-01.1": [ - "03.08.01", - "03.08.05.A" + "CC3.1-POF1": [ + "GOV-08", + "GOV-09", + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5" ], - "DCH-01.2": [ - "03.01.01.D.01", - "03.01.01.D.02", - "03.01.02", - "03.01.20.A", - "03.01.20.B", - "03.01.20.C.01", - "03.01.20.D", - "03.06.05.D", - "03.08.01", - "03.08.02", - "03.08.05.A", - "03.17.01.C" + "CC3.1-POF3": [ + "GOV-08", + "RSK-01.1" ], - "DCH-01.3": [ - "03.08.05.C" + "CC3.1-POF15": [ + "GOV-08", + "GOV-09", + "PRM-06", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "OPS-03" ], - "DCH-01.4": [ - "03.01.02", - "03.01.03", - "03.01.04.B", - "03.08.01", - "03.08.02", - "03.10.01.A", - "03.15.02.C", - "03.17.01.C" + "CC5.1-POF2": [ + "GOV-08", + "GOV-15" ], - "DCH-02": [ - "03.04.11.A", - "03.08.01", - "03.08.04" + "CC2.1-POF1": [ + "GOV-09", + "GOV-15", + "OPS-03" ], - "DCH-03": [ - "03.01.03", - "03.08.01", - "03.08.02" + "CC3.1": [ + "GOV-09", + "PRM-01", + "PRM-04", + "PRM-06", + "RSK-01", + "RSK-09", + "SEA-02" ], - "DCH-03.1": [ - "03.01.22.A", - "03.15.02.C", - "03.17.01.C" + "CC3.1-POF8": [ + "GOV-09", + "CPL-01", + "PRM-06", + "OPS-03" ], - "DCH-04": [ - "03.08.04" + "CC3.1-POF9": [ + "GOV-09", + "CPL-01", + "PRM-06", + "OPS-03" ], - "DCH-06": [ - "03.08.01" + "CC2.1-POF2": [ + "GOV-15", + "AST-04", + "OPS-03" ], - "DCH-06.1": [ - "03.08.01" + "CC2.1-POF3": [ + "GOV-15", + "OPS-03" ], - "DCH-06.2": [ - "03.04.11.A", - "03.04.11.B" + "CC3.1-POF5": [ + "GOV-15", + "CPL-01" ], - "DCH-06.4": [ - "03.08.01" + "CC5.1": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "HRS-11", + "PRM-06", + "RSK-01", + "SEA-01", + "SEA-01.1", + "SEA-02", + "OPS-01.1", + "OPS-02" ], - "DCH-07": [ - "03.08.05.A", - "03.08.05.B" + "CC5.1-POF1": [ + "GOV-15" ], - "DCH-07.1": [ - "03.08.05.A", - "03.08.05.B" + "CC5.1-POF3": [ + "GOV-15" ], - "DCH-07.2": [ - "03.08.05.A" + "CC5.1-POF4": [ + "GOV-15" ], - "DCH-08": [ - "03.08.03" + "CC5.1-POF5": [ + "GOV-15", + "PRM-01.2" ], - "DCH-09": [ - "03.07.04.C", - "03.08.03" + "CC5.1-POF6": [ + "GOV-15", + "HRS-11" ], - "DCH-10": [ - "03.08.07.A" + "CC3.1-POF6": [ + "GOV-16", + "RSK-01.1", + "RSK-05" ], - "DCH-10.2": [ - "03.08.07.B" + "CC3.2-POF3": [ + "GOV-17", + "RSK-01", + "RSK-04" ], - "DCH-12": [ - "03.08.07.A" + "CC1.4-POF2": [ + "AAT-01", + "AAT-13.1", + "HRS-01", + "HRS-02.2", + "HRS-03.2", + "HRS-13", + "TPM-01", + "TPM-08" ], - "DCH-13": [ - "03.01.20.A", - "03.01.20.B", - "03.01.20.C.01", - "03.01.20.C.02", - "03.01.20.D" + "CC1.4-POF3": [ + "AAT-11", + "AAT-13", + "HRS-01", + "HRS-02.2", + "HRS-13", + "SAT-01", + "SAT-03.7", + "TPM-01", + "TPM-08" ], - "DCH-13.1": [ - "03.01.20.A", - "03.01.20.B", - "03.01.20.C.01", - "03.01.20.C.02", - "03.01.20.D" + "CC5.3-POF5": [ + "AAT-13.1", + "HRS-03.2" ], - "DCH-13.2": [ - "03.01.20.A", - "03.01.20.D" + "CC2.1-POF6": [ + "AST-01", + "AST-02", + "AST-02.10", + "DCH-06.2", + "HRS-03", + "TPM-01.1" ], - "DCH-13.3": [ - "03.01.20.B", - "03.01.20.C.01" + "CC2.1-POF9": [ + "AST-01", + "AST-02", + "AST-02.8", + "AST-02.10", + "BCD-02.4", + "CLD-09", + "DCH-19", + "DCH-24", + "SEA-14.2", + "TPM-04.4" ], - "DCH-13.4": [ - "03.01.20.A", - "03.01.20.C.01", - "03.01.20.D" + "CC3.3-POF1": [ + "AST-01", + "HRS-01", + "THR-01", + "THR-04" ], - "DCH-14": [ - "03.01.20.B" + "CC6.1-POF1": [ + "AST-01", + "AST-02", + "AST-04.1", + "DCH-02" ], - "DCH-14.2": [ - "03.01.20.B", - "03.01.20.C.02", - "03.12.05.A" + "CC6.1-POF9": [ + "AST-01", + "IAC-01", + "IAO-01", + "IAO-07" ], - "DCH-14.3": [ - "03.01.03", - "03.01.20.C.02", - "03.12.05.A" + "CC5.2-POF1": [ + "AST-01.1" ], - "DCH-15": [ - "03.01.22.A", - "03.01.22.B" + "CC7.1-POF4": [ + "AST-02.2", + "MON-01.7", + "END-06" ], - "DCH-17": [ - "03.01.20.A" + "CC2.1-POF5": [ + "AST-02.8", + "AST-04" ], - "DCH-18": [ - "03.01.20.C.02", - "03.14.08" + "C1.1-POF1": [ + "AST-04", + "DCH-06.2" ], - "DCH-19": [ - "03.04.11.A", - "03.04.11.B" + "CC2.1": [ + "AST-04", + "DCH-01", + "DCH-01.1", + "DCH-02", + "DCH-22", + "OPS-03" ], - "DCH-21": [ - "03.08.03" + "CC2.1-POF7": [ + "AST-04.1", + "DCH-02", + "DCH-11" ], - "END-01": [ - "03.14.02.A" + "CC2.2-POF11": [ + "AST-04.1", + "AST-04.2", + "CPL-01.2", + "IAO-01.1", + "IAO-03" ], - "END-04": [ - "03.14.02.C", - "03.14.02.C.01", - "03.14.02.C.02" + "CC5.2-POF2": [ + "AST-04.2", + "CPL-01.2" ], - "END-04.1": [ - "03.14.02.B" + "CC6.7-POF3": [ + "AST-05", + "CRY-01", + "CRY-01.1", + "CRY-05", + "CRY-05.1", + "DCH-12", + "DCH-13.2" ], - "END-04.3": [ - "03.14.02.A" + "C1.2-POF2": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21", + "PRI-05" ], - "END-04.7": [ - "03.14.02.A", - "03.14.02.C.01", - "03.14.02.C.02" + "CC6.5": [ + "AST-09", + "DCH-01", + "DCH-08", + "DCH-09", + "DCH-21", + "PRI-05" ], - "END-07": [ - "03.14.06.A.01", - "03.14.06.A.02", - "03.14.06.B", - "03.14.06.C" + "CC6.5-POF2": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21", + "PRI-05" ], - "END-10": [ - "03.13.13.A", - "03.13.13.B" + "P4.3-POF2": [ + "AST-09", + "DCH-08", + "DCH-21", + "PRI-05" ], - "END-14": [ - "03.13.12.A" + "P4.3-POF3": [ + "AST-09", + "DCH-08", + "DCH-21", + "PRI-05" ], - "END-14.6": [ - "03.13.12.B" + "CC6.4-POF3": [ + "AST-10", + "HRS-09.1" ], - "HRS-01": [ - "03.01.01.G.02", - "03.15.03.A", - "03.15.03.D" + "A1.2": [ + "BCD-01", + "BCD-08", + "BCD-08.1", + "BCD-08.2", + "BCD-09", + "BCD-09.1", + "BCD-09.2", + "BCD-09.3", + "BCD-10", + "BCD-10.1", + "BCD-11", + "BCD-11.1", + "BCD-11.2", + "BCD-11.3", + "BCD-11.4", + "BCD-12", + "BCD-12.1", + "BCD-12.2", + "PES-01", + "PES-07", + "PES-07.1", + "PES-07.2", + "PES-07.3", + "PES-07.4", + "PES-07.5", + "PES-08", + "PES-08.1", + "PES-08.2", + "PES-09", + "PES-09.1", + "PES-10", + "PES-11", + "PES-12", + "PES-13", + "PES-15", + "RSK-03", + "RSK-04" ], - "HRS-02": [ - "03.01.01.C.01", - "03.01.01.C.02", - "03.01.01.D.01", - "03.01.01.D.02", - "03.01.02", - "03.09.01.A", - "03.09.01.B" + "A1.2-POF1": [ + "BCD-01", + "PES-01", + "RSK-01", + "RSK-03" ], - "HRS-02.1": [ - "03.01.02" + "A1.2-POF2": [ + "BCD-01", + "PES-01", + "PES-09", + "PES-09.1" ], - "HRS-03": [ - "03.01.22.A", - "03.06.04.A", - "03.06.05.D", - "03.07.06.A", - "03.08.02", - "03.15.03.B", - "03.16.03.B" + "A1.2-POF3": [ + "BCD-01", + "PES-01" ], - "HRS-03.1": [ - "03.01.22.A", - "03.15.03.B" + "A1.2-POF4": [ + "BCD-01", + "PES-01", + "PES-09", + "PES-09.1" ], - "HRS-03.2": [ - "03.07.06.D" + "A1.2-POF5": [ + "BCD-01", + "IRO-01", + "IRO-02", + "PES-01" ], - "HRS-04": [ - "03.09.01.A" + "A1.2-POF6": [ + "BCD-01", + "PES-01" ], - "HRS-04.1": [ - "03.01.22.A", - "03.02.02.A.01", - "03.09.01.A", - "03.09.01.B" + "A1.2-POF10": [ + "BCD-01", + "BCD-09" ], - "HRS-04.2": [ - "03.01.22.A", - "03.02.02.A.01", - "03.06.04.A", - "03.06.04.A.01", - "03.15.03.B" + "A1.2-POF11": [ + "BCD-01", + "RSK-01.1", + "SEA-01.2", + "THR-09", + "THR-10" ], - "HRS-05": [ - "03.01.01.H", - "03.01.22.A", - "03.15.03.A" + "CC7.4-POF5": [ + "BCD-01", + "IRO-01", + "IRO-02", + "IRO-04" ], - "HRS-05.1": [ - "03.01.12.A", - "03.01.18.A", - "03.01.22.A", - "03.15.03.A" + "CC7.5": [ + "BCD-01", + "BCD-02", + "BCD-02.1", + "BCD-02.2", + "BCD-02.3", + "BCD-04", + "BCD-05", + "BCD-06", + "BCD-11", + "BCD-11.1", + "BCD-12", + "BCD-13" ], - "HRS-05.2": [ - "03.15.03.A" + "CC7.5-POF1": [ + "BCD-01", + "BCD-02.1", + "BCD-02.2", + "BCD-02.3", + "BCD-12" ], - "HRS-05.3": [ - "03.01.01.H", - "03.01.12.A", - "03.01.18.A", - "03.15.03.A" + "CC7.5-POF2": [ + "BCD-01", + "BCD-01.6", + "IRO-10" ], - "HRS-05.4": [ - "03.15.03.A" + "CC7.5-POF4": [ + "BCD-01", + "BCD-06" ], - "HRS-05.5": [ - "03.01.18.A", - "03.15.03.A" + "CC7.5-POF5": [ + "BCD-01", + "BCD-06" ], - "HRS-05.7": [ - "03.15.03.B", - "03.15.03.C", - "03.15.03.D" + "CC8.1-POF15": [ + "BCD-01", + "SEA-01", + "SEA-01.2" ], - "HRS-06": [ - "03.01.18.A", - "03.12.05.A", - "03.15.03.B", - "03.15.03.C" + "CC9.1": [ + "BCD-01", + "BCD-07", + "RSK-01", + "RSK-03", + "RSK-03.1", + "TPM-01", + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04.4", + "TPM-05", + "TPM-06", + "TPM-07", + "TPM-08", + "TPM-09", + "TPM-10", + "THR-01", + "THR-09" ], - "HRS-06.1": [ - "03.12.05.A", - "03.15.03.C" + "CC9.1-POF1": [ + "BCD-01", + "RSK-06.2", + "RSK-08" ], - "HRS-07": [ - "03.01.01.F.04", - "03.01.01.F.05" + "CC9.1-POF2": [ + "BCD-01", + "RSK-06.2", + "RSK-08" ], - "HRS-07.1": [ - "03.01.01.F.04", - "03.01.01.F.05" + "A1.3": [ + "BCD-03.1", + "BCD-04" ], - "HRS-08": [ - "03.01.01.G.02", - "03.09.02.A", - "03.09.02.B.01" + "A1.3-POF1": [ + "BCD-04" ], - "HRS-09": [ - "03.01.01.F.03", - "03.01.01.G.02", - "03.09.02.A", - "03.09.02.A.03", - "03.09.02.B.01" + "A1.3-POF2": [ + "BCD-04", + "BCD-11.1", + "BCD-11.5" ], - "HRS-09.1": [ - "03.09.02.A.03" + "CC7.5-POF6": [ + "BCD-04" ], - "HRS-09.2": [ - "03.09.02.A.01", - "03.09.02.A.02", - "03.09.02.B.01" + "CC7.4-POF10": [ + "BCD-05", + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-13" ], - "HRS-09.4": [ - "03.01.01.G.02", - "03.09.02.A.01", - "03.09.02.A.02" + "CC7.5-POF3": [ + "BCD-05" ], - "HRS-10": [ - "03.16.03.B" + "A1.2-POF9": [ + "BCD-08", + "BCD-11.2", + "BCD-11.6", + "PES-01" ], - "HRS-11": [ - "03.01.04.A" + "A1.2-POF7": [ + "BCD-11", + "DCH-01", + "DCH-01.2", + "PES-01" ], - "HRS-12": [ - "03.01.04.A" + "A1.2-POF8": [ + "BCD-11" ], - "IAC-01": [ - "03.01.01.A", - "03.01.18.B", - "03.05.01.A", - "03.05.05.A", - "03.05.12.E" + "A1.1": [ + "CAP-01", + "CAP-02", + "CAP-03" ], - "IAC-01.2": [ - "03.05.01.A", - "03.05.02", - "03.05.05.D", - "03.05.07.A", - "03.05.07.B", - "03.05.07.C", - "03.05.07.D", - "03.05.07.E", - "03.05.12.D", - "03.05.12.F", - "03.07.05.A" + "A1.1-POF1": [ + "CAP-01", + "CAP-04" ], - "IAC-02": [ - "03.05.01.A" + "A1.1-POF3": [ + "CAP-01" ], - "IAC-02.2": [ - "03.05.04", - "03.07.05.B" + "A1.1-POF2": [ + "CAP-03" ], - "IAC-03": [ - "03.05.01.A" + "CC2.2-POF13": [ + "CHG-01", + "CHG-02", + "CHG-05", + "SAT-03", + "SAT-03.2" ], - "IAC-04": [ - "03.01.18.B", - "03.05.02" + "CC3.4": [ + "CHG-01", + "CHG-02", + "CHG-02.2", + "CHG-02.3", + "CHG-03", + "PRM-01", + "PRM-06", + "TPM-04.1", + "TPM-08", + "TPM-10" ], - "IAC-05": [ - "03.05.01.A", - "03.05.02" + "CC3.4-POF4": [ + "CHG-01", + "CHG-02", + "CHG-03", + "RSK-01", + "RSK-03", + "RSK-04" ], - "IAC-05.2": [ - "03.07.05.A" + "CC6.8-POF3": [ + "CHG-01", + "CHG-02" ], - "IAC-06": [ - "03.05.03", - "03.07.05.B" + "CC8.1": [ + "CHG-01", + "CHG-02", + "CHG-02.2", + "CHG-05", + "CFG-02", + "CFG-02.1", + "CFG-02.2", + "PRM-07" ], - "IAC-06.1": [ - "03.05.03" + "CC8.1-POF1": [ + "CHG-01", + "CHG-02", + "PRM-07" ], - "IAC-06.2": [ - "03.05.03" + "CC8.1-POF2": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-04" ], - "IAC-06.3": [ - "03.05.03" + "CC8.1-POF3": [ + "CHG-01", + "CHG-02", + "CHG-02.3", + "CHG-03" ], - "IAC-07": [ - "03.01.01.G.01", - "03.01.01.G.02", - "03.01.01.G.03", - "03.05.05.A", - "03.09.02.A.01", - "03.09.02.A.02" + "CC8.1-POF4": [ + "CHG-01", + "CHG-02", + "CHG-02.2" ], - "IAC-07.1": [ - "03.01.01.G.01", - "03.01.01.G.02", - "03.01.01.G.03", - "03.05.05.A", - "03.09.02.B.02" + "CC8.1-POF5": [ + "CHG-01", + "CHG-02", + "CHG-02.2" ], - "IAC-07.2": [ - "03.09.02.A.01", - "03.09.02.A.02" + "CC8.1-POF6": [ + "CHG-01", + "CHG-02", + "CFG-01", + "CFG-02", + "CFG-02.2" ], - "IAC-08": [ - "03.01.01.C.01", - "03.01.01.C.02", - "03.01.01.C.03", - "03.01.02", - "03.01.05.B", - "03.01.06.A", - "03.01.12.A", - "03.03.08.B", - "03.04.05", - "03.06.05.D", - "03.07.06.A" + "CC8.1-POF7": [ + "CHG-01", + "CHG-02", + "CHG-02.2" ], - "IAC-09": [ - "03.05.05.B", - "03.05.05.C", - "03.05.05.D" + "CC8.1-POF8": [ + "CHG-01", + "CHG-02" ], - "IAC-09.1": [ - "03.05.05.B" + "CC8.1-POF9": [ + "CHG-01", + "CHG-02", + "CHG-04", + "CHG-04.4" ], - "IAC-09.2": [ - "03.05.05.D" + "CC8.1-POF10": [ + "CHG-01", + "CHG-02", + "CHG-02.2", + "CHG-03", + "CHG-04.1" ], - "IAC-09.5": [ - "03.01.07.B", - "03.05.05.D" + "CC8.1-POF11": [ + "CHG-01", + "CHG-02", + "CHG-04.1", + "CFG-02.2" ], - "IAC-10": [ - "03.05.07.A", - "03.05.07.B", - "03.05.07.C", - "03.05.07.D", - "03.05.07.E", - "03.05.07.F", - "03.05.12.A", - "03.05.12.B", - "03.05.12.C", - "03.05.12.D", - "03.05.12.E", - "03.05.12.F" + "CC8.1-POF13": [ + "CHG-01", + "CHG-02", + "CHG-02.2", + "IAC-15.9" ], - "IAC-10.1": [ - "03.05.07.E", - "03.05.07.F", - "03.05.12.B", - "03.05.12.C", - "03.05.12.D", - "03.05.12.E", - "03.05.12.F" + "CC8.1-POF14": [ + "CHG-01", + "CHG-02", + "VPM-01", + "VPM-05" ], - "IAC-10.3": [ - "03.05.12.A" + "CC8.1-POF16": [ + "CHG-01", + "CHG-02.2", + "DCH-01", + "VPM-01", + "VPM-05" ], - "IAC-10.4": [ - "03.05.07.A", - "03.05.07.B" + "CC6.8": [ + "CHG-02.1", + "MON-01.7", + "END-04", + "END-06", + "END-07", + "NET-03", + "NET-08" ], - "IAC-10.5": [ - "03.05.07.C", - "03.05.07.D", - "03.05.12.F" + "CC6.1-POF5": [ + "CLD-01", + "CLD-11", + "NET-01", + "NET-01.1", + "NET-03", + "NET-14.3" ], - "IAC-10.6": [ - "03.05.07.D" + "CC3.1-POF14": [ + "CPL-01", + "PRM-06", + "OPS-03" ], - "IAC-10.8": [ - "03.05.07.E", - "03.05.12.D" + "CC1.1-POF4": [ + "CPL-01.1", + "HRS-07", + "RSK-06" ], - "IAC-10.11": [ - "03.05.07.A", - "03.05.07.B", - "03.05.07.C", - "03.05.07.D", - "03.05.07.F" + "CC4.2-POF3": [ + "CPL-01.1", + "CPL-02", + "IAO-05", + "RSK-04.1" ], - "IAC-11": [ - "03.05.11" + "CC4.1-POF1": [ + "CPL-02.1", + "TDA-09" ], - "IAC-14": [ - "03.05.01.B" + "CC4.1-POF3": [ + "CPL-02.1" ], - "IAC-15": [ - "03.01.01.A", - "03.01.01.B", - "03.01.01.C.01", - "03.01.01.C.02", - "03.01.01.D.01", - "03.01.01.D.02", - "03.01.01.E", - "03.01.01.F.01", - "03.01.01.F.03", - "03.01.01.F.04", - "03.01.01.F.05", - "03.01.01.G.01", - "03.01.01.G.02", - "03.01.01.G.03", - "03.01.02", - "03.01.05.B", - "03.01.05.C", - "03.01.05.D" + "CC4.1-POF4": [ + "CPL-02.1", + "IAO-02.2" ], - "IAC-15.1": [ - "03.05.05.B", - "03.05.05.C", - "03.05.05.D", - "03.05.07.C", - "03.05.07.D", - "03.05.07.E", - "03.05.07.F", - "03.05.12.D", - "03.05.12.E", - "03.05.12.F" + "CC4.1-POF5": [ + "CPL-02.1" ], - "IAC-15.3": [ - "03.01.01.F.02" + "CC4.1-POF6": [ + "CPL-02.1" ], - "IAC-15.5": [ - "03.01.01.C.01" + "CC4.1-POF7": [ + "CPL-02.1" ], - "IAC-15.6": [ - "03.01.01.F.04", - "03.01.01.F.05" + "CC4.1-POF8": [ + "CPL-02.1", + "IAO-01", + "IAO-02" ], - "IAC-15.7": [ - "03.01.01.E", - "03.01.05.C" + "CC7.2-POF4": [ + "CPL-03.2", + "MON-01.8" ], - "IAC-16": [ - "03.01.06.A", - "03.01.07.A", - "03.01.07.B" + "CC7.1": [ + "CFG-01", + "CFG-02", + "MON-01.7", + "END-06.1", + "VPM-06" ], - "IAC-17": [ - "03.01.01.G.03", - "03.01.05.C", - "03.01.05.D", - "03.10.01.C", - "03.10.01.D" + "CC7.1-POF1": [ + "CFG-01", + "CFG-02", + "CFG-02.2" ], - "IAC-20": [ - "03.01.01.C.03", - "03.01.01.D.01", - "03.01.01.D.02", - "03.01.02", - "03.01.03", - "03.01.04.B", - "03.01.05.A", - "03.01.05.B", - "03.01.06.A", - "03.09.02.B.02" + "CC8.1-POF12": [ + "CFG-01", + "CFG-02" ], - "IAC-20.1": [ - "03.01.01.C.03", - "03.01.01.D.01", - "03.01.01.D.02", - "03.01.02", - "03.01.03", - "03.01.04.B", - "03.01.05.A", - "03.06.05.D", - "03.10.01.A" + "CC6.1-POF7": [ + "CFG-02", + "CFG-03", + "IAC-01", + "IAC-21" ], - "IAC-21": [ - "03.01.01.C.03", - "03.01.01.D.01", - "03.01.01.D.02", - "03.01.04.B", - "03.01.05.A", - "03.01.05.B", - "03.01.06.A", - "03.01.07.A", - "03.03.08.A", - "03.03.08.B", - "03.04.05" + "CC6.7-POF1": [ + "CFG-02", + "CFG-03", + "DCH-17", + "NET-03.5", + "NET-04.1", + "NET-12.2", + "NET-17" ], - "IAC-21.2": [ - "03.01.06.B" + "CC7.2": [ + "CFG-02.2", + "MON-01", + "MON-01.1", + "MON-01.2", + "MON-01.3", + "MON-01.4", + "MON-01.5", + "MON-01.6", + "MON-01.8", + "MON-02", + "MON-02.1", + "MON-06", + "MON-16", + "NET-08.2", + "RSK-03", + "OPS-02" ], - "IAC-21.3": [ - "03.01.06.A", - "03.01.07.A" + "CC5.2-POF3": [ + "CFG-03", + "IAC-08", + "IAC-21" ], - "IAC-21.4": [ - "03.01.07.B" + "CC6.7": [ + "CFG-04.2", + "CRY-03", + "CRY-05", + "DCH-01", + "DCH-10", + "DCH-12", + "DCH-13", + "DCH-13.2", + "DCH-14", + "DCH-17", + "MDM-01", + "MDM-03", + "NET-13" ], - "IAC-21.5": [ - "03.01.07.A" + "CC6.8-POF1": [ + "CFG-05", + "CFG-05.2", + "END-03" ], - "IAC-22": [ - "03.01.08.A", - "03.01.08.B" + "CC6.8-POF2": [ + "CFG-05.1", + "END-03.1" ], - "IAC-24": [ - "03.01.10.A", - "03.01.10.B" + "CC7.2-POF2": [ + "MON-01.1", + "MON-01.4", + "MON-01.12", + "MON-16" ], - "IAC-24.1": [ - "03.01.10.C" + "CC7.2-POF3": [ + "MON-01.1", + "MON-01.2", + "MON-16" ], - "IAC-25": [ - "03.01.11", - "03.07.05.C" + "CC7.1-POF2": [ + "MON-01.7", + "END-06" ], - "IAC-28": [ - "03.05.12.A", - "03.05.12.C" + "CC7.1-POF3": [ + "MON-01.7", + "END-06" ], - "IAC-28.1": [ - "03.01.01.B", - "03.05.05.A" + "CC7.3": [ + "MON-02", + "MON-02.1", + "MON-06", + "END-06.2", + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-04.1", + "RSK-04", + "TPM-11" ], - "IRO-01": [ - "03.06.01" + "PI1.4": [ + "MON-03", + "MON-08", + "PES-12.2", + "TDA-06" ], - "IRO-02": [ - "03.03.04.B", - "03.06.01", - "03.06.02.A", - "03.06.02.B", - "03.06.02.C", - "03.06.02.D" + "PI1.5": [ + "MON-08", + "DCH-01", + "DCH-18", + "TDA-06" ], - "IRO-04": [ - "03.06.01", - "03.06.05.A", - "03.06.05.A.01", - "03.06.05.A.02", - "03.06.05.A.03", - "03.06.05.A.04", - "03.06.05.A.05", - "03.06.05.A.06", - "03.06.05.B" - ], - "IRO-04.2": [ - "03.06.04.B", - "03.06.05.C" + "C1.2": [ + "MON-10", + "DCH-21", + "PRI-05" ], - "IRO-04.3": [ - "03.06.04.B" + "CC6.1": [ + "CRY-01", + "CRY-03", + "CRY-05", + "CRY-08", + "CRY-09", + "CRY-09.1", + "CRY-09.2", + "IAC-01", + "IAC-02", + "IAC-03", + "IAC-04", + "IAC-05", + "IAC-08", + "IAC-09", + "IAC-09.1", + "IAC-10", + "IAC-10.8", + "IAC-15", + "IAC-16", + "IAC-20", + "IAC-21", + "NET-01", + "NET-03", + "NET-03.1", + "NET-04", + "NET-05.1", + "NET-06", + "NET-06.1" ], - "IRO-05": [ - "03.06.04.A", - "03.06.04.A.03" + "CC6.1-POF10": [ + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-08", + "CRY-09", + "CRY-09.1", + "CRY-09.2" ], - "IRO-06": [ - "03.06.03" + "CC6.1-POF11": [ + "CRY-01", + "CRY-08", + "CRY-09", + "CRY-09.1", + "CRY-09.2", + "CRY-09.3", + "CRY-09.4" ], - "IRO-09": [ - "03.06.02.A", - "03.06.02.B" + "CC6.6-POF2": [ + "CRY-01", + "IAC-01", + "IAC-01.2", + "IAC-10.1", + "NET-01", + "NET-12", + "NET-13" ], - "IRO-10": [ - "03.06.02.B", - "03.06.02.C" + "CC6.7-POF2": [ + "CRY-01", + "CRY-03", + "CRY-05", + "DCH-01" ], - "IRO-10.2": [ - "03.06.02.B", - "03.06.02.C" + "C1.1": [ + "DCH-01", + "DCH-02", + "DCH-03" ], - "IRO-11": [ - "03.06.02.D" + "C1.1-POF2": [ + "DCH-01", + "DCH-01.2" ], - "IRO-12": [ - "03.06.01" + "CC8.1-POF17": [ + "DCH-01", + "DCH-01.2", + "PRI-01" ], - "IRO-13": [ - "03.06.04.B" + "PI1.4-POF1": [ + "DCH-01", + "PRM-06", + "OPS-03", + "TDA-06" ], - "IRO-14": [ - "03.06.02.C" + "PI1.4-POF2": [ + "DCH-01", + "PRM-06", + "OPS-03", + "TDA-06" ], - "IAO-01": [ - "03.12.01" + "PI1.4-POF3": [ + "DCH-01", + "PRM-06", + "OPS-03", + "TDA-06" ], - "IAO-01.1": [ - "03.12.01" + "PI1.4-POF4": [ + "DCH-01", + "PRM-06", + "OPS-03", + "TDA-06" ], - "IAO-02": [ - "03.12.01" + "PI1.5-POF1": [ + "DCH-01", + "PRM-06", + "OPS-03", + "TDA-06" ], - "IAO-03": [ - "03.04.11.B", - "03.15.02.A", - "03.15.02.A.01", - "03.15.02.A.02", - "03.15.02.A.03", - "03.15.02.A.04", - "03.15.02.A.05", - "03.15.02.A.06", - "03.15.02.A.07", - "03.15.02.A.08", - "03.15.02.B" + "PI1.5-POF2": [ + "DCH-01", + "PRM-06", + "OPS-03", + "TDA-06" ], - "IAO-05": [ - "03.04.11.B", - "03.12.02.A", - "03.12.02.A.01", - "03.12.02.A.02", - "03.12.02.B", - "03.12.02.B.01", - "03.12.02.B.02", - "03.12.02.B.03", - "03.14.01.A" + "PI1.5-POF3": [ + "DCH-01", + "PRM-06", + "OPS-03", + "TDA-06" ], - "MNT-01": [ - "03.04.03.C", - "03.07.04.A", - "03.07.06.A" + "PI1.5-POF4": [ + "DCH-01", + "PRM-06", + "OPS-03", + "TDA-06" ], - "MNT-02": [ - "03.04.03.C", - "03.07.04.A", - "03.07.05.A" + "P6.0": [ + "DCH-03.1" ], - "MNT-03": [ - "03.07.04.A" + "P6.1-POF2": [ + "DCH-03.1", + "PRI-01.7" ], - "MNT-03.1": [ - "03.07.04.A" + "P6.1-POF3": [ + "DCH-03.1", + "PRI-01.7" ], - "MNT-04": [ - "03.07.04.A" + "P6.1-POF4": [ + "DCH-03.1", + "PRI-01.7" ], - "MNT-04.1": [ - "03.07.04.B" + "P6.4-POF1": [ + "DCH-03.1", + "PRI-01.7" ], - "MNT-04.3": [ - "03.07.04.C" + "P4.3": [ + "DCH-09.3", + "DCH-21", + "PRI-05" ], - "MNT-05": [ - "03.01.12.D", - "03.07.05.A", - "03.07.05.B", - "03.07.05.C" + "C1.1-POF3": [ + "DCH-18", + "PRI-05" ], - "MNT-05.1": [ - "03.07.05.A" + "C1.2-POF1": [ + "DCH-21", + "PRI-05" ], - "MNT-05.3": [ - "03.07.05.B" + "CC2.1-POF8": [ + "DCH-22" ], - "MNT-05.4": [ - "03.07.05.C" + "P5.1": [ + "DCH-22.1", + "PRI-06", + "PRI-06.4" ], - "MNT-05.5": [ - "03.07.05.A" + "P5.2": [ + "DCH-22.1", + "PRI-06.1", + "PRI-06.2", + "PRI-06.3", + "PRI-06.4", + "PRI-12" ], - "MNT-06": [ - "03.07.06.A", - "03.07.06.B", - "03.07.06.C", - "03.07.06.D" + "CC6.7-POF4": [ + "END-01", + "MDM-01" ], - "MNT-06.1": [ - "03.07.06.A", - "03.07.06.C", - "03.07.06.D" + "CC6.8-POF4": [ + "END-04" ], - "MNT-06.2": [ - "03.07.06.A", - "03.07.06.C" + "CC6.8-POF5": [ + "END-04.7" ], - "MNT-09": [ - "03.07.04.A" + "CC1.4": [ + "HRS-01", + "PRM-02", + "PRM-03", + "SAT-01", + "SAT-03.7" ], - "MDM-01": [ - "03.01.18.A", - "03.01.20.D" + "CC2.2-POF3": [ + "HRS-01", + "HRS-07.1", + "IRO-01", + "IRO-02" ], - "MDM-02": [ - "03.01.18.A", - "03.01.18.B" + "CC2.3-POF4": [ + "HRS-01", + "HRS-07.1" ], - "MDM-03": [ - "03.01.18.C" + "CC3.3-POF2": [ + "HRS-01", + "THR-01", + "THR-04" ], - "MDM-04": [ - "03.04.12.B" + "CC3.3-POF3": [ + "HRS-01", + "THR-01", + "THR-04" ], - "MDM-06": [ - "03.01.18.A", - "03.01.18.B" + "CC3.3-POF4": [ + "HRS-01", + "THR-01", + "THR-04" ], - "MDM-07": [ - "03.01.18.A", - "03.01.18.B", - "03.01.20.D" + "CC3.3-POF5": [ + "HRS-01", + "THR-01", + "THR-04" ], - "MDM-11": [ - "03.01.18.B" + "CC1.4-POF6": [ + "HRS-03", + "HRS-03.2" ], - "NET-01": [ - "03.01.12.A", - "03.01.16.A", - "03.01.16.B", - "03.01.18.A", - "03.13.01.A" + "CC2.2-POF5": [ + "HRS-03", + "TPM-05.4" ], - "NET-02": [ - "03.13.01.B" + "CC7.4-POF1": [ + "HRS-03", + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-07" ], - "NET-02.2": [ - "03.01.16.A", - "03.01.16.B" + "CC1.4-POF5": [ + "HRS-04" ], - "NET-03": [ - "03.01.12.A", - "03.13.01.A", - "03.13.01.B", - "03.13.01.C" + "CC1.1-POF2": [ + "HRS-05.1" ], - "NET-03.8": [ - "03.13.01.B" + "CC1.5-POF6": [ + "HRS-07" ], - "NET-04": [ - "03.01.03", - "03.13.01.A", - "03.13.01.C" + "CC7.4-POF14": [ + "HRS-07" ], - "NET-04.1": [ - "03.13.01.A", - "03.13.06" + "CC6.2-POF3": [ + "HRS-08", + "HRS-09", + "IAC-07", + "IAC-15.7", + "IAC-17" ], - "NET-05": [ - "03.01.03", - "03.01.20.C.02", - "03.12.05.A", - "03.12.05.B" + "CC1.4-POF4": [ + "HRS-13", + "HRS-13.4" ], - "NET-05.2": [ - "03.01.03", - "03.12.05.A", - "03.12.05.B", - "03.12.05.C" + "CC6.1-POF3": [ + "IAC-01", + "IAC-01.2", + "IAC-02", + "IAC-03", + "IAC-04" ], - "NET-06": [ - "03.13.01.B" + "CC6.1-POF8": [ + "IAC-01", + "IAC-02", + "IAC-04", + "IAC-05" ], - "NET-06.3": [ - "03.13.01.B" + "CC6.6": [ + "IAC-01", + "IAC-01.2", + "NET-01", + "NET-02", + "NET-03", + "NET-03.1", + "NET-04", + "NET-04.1", + "NET-08.1", + "NET-12", + "NET-12.1", + "NET-13", + "NET-14" ], - "NET-07": [ - "03.13.09" + "CC6.6-POF3": [ + "IAC-01", + "IAC-01.2", + "IAC-06", + "IAC-13", + "NET-01", + "NET-03", + "NET-04.1", + "NET-14" ], - "NET-08": [ - "03.13.01.A", - "03.14.06.C" + "CC6.1-POF4": [ + "IAC-01.2", + "IAC-02", + "IAC-03" ], - "NET-08.1": [ - "03.13.01.B" + "CC6.2": [ + "IAC-07", + "IAC-07.1", + "IAC-17" ], - "NET-09": [ - "03.13.15" + "CC6.2-POF1": [ + "IAC-07", + "IAC-07.1", + "IAC-28.1" ], - "NET-14": [ - "03.01.12.A", - "03.01.12.B", - "03.01.12.C", - "03.01.12.D" + "CC6.3-POF1": [ + "IAC-07", + "IAC-07.1", + "IAC-28.1" ], - "NET-14.1": [ - "03.01.12.B" + "CC6.3-POF2": [ + "IAC-07", + "IAC-07.1" ], - "NET-14.2": [ - "03.01.12.A" + "CC6.2-POF2": [ + "IAC-07.1", + "IAC-15.3", + "IAC-15.7", + "IAC-17" ], - "NET-14.3": [ - "03.01.12.B", - "03.01.12.C" + "CC6.1-POF12": [ + "IAC-08", + "IAC-20.1", + "IAC-21" ], - "NET-14.4": [ - "03.01.12.D" + "CC6.1-POF13": [ + "IAC-08", + "IAC-20.1", + "IAC-21", + "PRI-01.6", + "PRI-05.1" ], - "NET-14.5": [ - "03.01.12.A", - "03.01.12.C", - "03.10.06.A", - "03.10.06.B" + "CC6.3": [ + "IAC-08" ], - "NET-15": [ - "03.01.16.A", - "03.01.16.B" + "CC6.3-POF3": [ + "IAC-08" ], - "NET-15.1": [ - "03.01.16.A", - "03.01.16.B", - "03.01.16.D" + "CC6.3-POF4": [ + "IAC-17" ], - "NET-15.2": [ - "03.01.16.C" + "CC7.3-POF1": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "NET-15.3": [ - "03.01.16.A", - "03.01.16.C" + "CC7.4": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-07", + "IRO-09", + "IRO-10", + "IRO-10.2", + "IRO-10.4", + "IRO-11.2", + "IRO-14", + "RSK-06" ], - "NET-18": [ - "03.14.06.C" + "CC7.4-POF2": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "PES-01": [ - "03.08.01", - "03.08.02", - "03.10.01.A", - "03.10.07.A" + "CC7.4-POF3": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "PES-02": [ - "03.08.01", - "03.08.02", - "03.10.01.A", - "03.10.01.B", - "03.10.01.C", - "03.10.01.D", - "03.10.07.A" + "CC7.4-POF4": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "PES-02.1": [ - "03.08.01", - "03.08.02", - "03.10.01.B", - "03.10.01.D" + "CC7.4-POF6": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-09", + "IRO-10", + "IRO-10.2" ], - "PES-03": [ - "03.10.02.A", - "03.10.07.A", - "03.10.07.A.01", - "03.10.07.A.02", - "03.10.07.D" + "CC7.4-POF7": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "PES-03.1": [ - "03.10.02.A", - "03.10.07.A", - "03.10.07.A.02" + "CC7.4-POF8": [ + "IRO-01", + "IRO-02", + "IRO-04", + "RSK-06", + "VPM-02" ], - "PES-03.3": [ - "03.10.02.A", - "03.10.07.B" + "CC7.4-POF9": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-09", + "IRO-10" ], - "PES-03.4": [ - "03.10.07.A.01", - "03.10.07.A.02" + "CC7.4-POF11": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-04.2" ], - "PES-04": [ - "03.08.01", - "03.08.02", - "03.10.07.A.01", - "03.10.07.A.02", - "03.10.07.D" + "CC7.4-POF12": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "PES-04.1": [ - "03.08.01", - "03.08.02", - "03.10.07.A.01", - "03.10.07.A.02", - "03.10.07.D" + "CC7.4-POF13": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-10", + "IRO-10.2" ], - "PES-05": [ - "03.10.02.A", - "03.10.02.B" + "CC2.2-POF6": [ + "IRO-02", + "IRO-07", + "IRO-09", + "IRO-10", + "IRO-10.2", + "IRO-11.2" ], - "PES-05.1": [ - "03.10.02.A", - "03.10.02.B" + "CC2.3-POF8": [ + "IRO-02", + "IRO-04", + "IRO-09", + "IRO-10" ], - "PES-05.2": [ - "03.10.02.A", - "03.10.02.B" + "CC7.3-POF3": [ + "IRO-02" ], - "PES-06": [ - "03.10.02.B", - "03.10.07.C" + "CC7.3-POF4": [ + "IRO-02", + "IRO-04.1" ], - "PES-06.1": [ - "03.10.02.B", - "03.10.07.C" + "CC7.3-POF5": [ + "IRO-02", + "IRO-04.1" ], - "PES-06.2": [ - "03.10.07.C" + "CC7.3-POF6": [ + "IRO-02", + "RSK-01.1" ], - "PES-06.3": [ - "03.10.07.C" + "CC7.3-POF7": [ + "IRO-02", + "IRO-02.4", + "IRO-10.2" ], - "PES-06.6": [ - "03.10.07.C" + "P6.3": [ + "IRO-04.1", + "IRO-10", + "IRO-12", + "PRI-14.1" ], - "PES-07": [ - "03.10.08" + "P6.6": [ + "IRO-04.1", + "TPM-11" ], - "PES-11": [ - "03.10.06.A", - "03.10.06.B" + "P6.6-POF2": [ + "IRO-04.1" ], - "PES-12": [ - "03.10.07.E", - "03.10.08" + "P6.7": [ + "IRO-04.1", + "IRO-10" ], - "PES-12.1": [ - "03.10.08" + "CC7.3-POF2": [ + "IRO-09", + "IRO-10", + "IRO-10.2" ], - "PES-12.2": [ - "03.10.07.E" + "CC2.3-POF1": [ + "IRO-10", + "IRO-10.2", + "IRO-10.4" ], - "PRM-01": [ - "03.16.01" + "CC2.3-POF12": [ + "IRO-10.2", + "IRO-11.2", + "SAT-03.2", + "TPM-01", + "TPM-05", + "TPM-05.1", + "TPM-05.2" ], - "PRM-05": [ - "03.16.01" + "CC2.3-POF2": [ + "IRO-11.2", + "OPS-03", + "TPM-05" ], - "RSK-01": [ - "03.11.01.A", - "03.17.01.A" + "CC6.1-POF2": [ + "IAO-01", + "IAO-02", + "SEA-01", + "SEA-02" ], - "RSK-01.1": [ - "03.11.01.A" + "CC2.3-POF9": [ + "IAO-03", + "TPM-01", + "TPM-05.4" ], - "RSK-02": [ - "03.11.01.A" + "CC2.3-POF10": [ + "IAO-03", + "TDA-01", + "TPM-01", + "TPM-05" ], - "RSK-02.1": [ - "03.11.01.A", - "03.14.03.B" + "CC2.3-POF11": [ + "IAO-03", + "TPM-05", + "TPM-05.4" ], - "RSK-03": [ - "03.11.01.A" + "CC6.6-POF1": [ + "NET-01", + "NET-03", + "NET-04", + "NET-04.1" ], - "RSK-03.1": [ - "03.15.02.A.03" + "CC6.6-POF4": [ + "NET-01", + "NET-02", + "NET-03", + "NET-14.3" ], - "RSK-04": [ - "03.11.01.A" + "CC6.1-POF6": [ + "NET-04", + "NET-14.3" ], - "RSK-04.1": [ - "03.12.02.A.01", - "03.12.02.A.02" + "CC6.4": [ + "PES-01", + "PES-02", + "PES-02.1", + "PES-03" ], - "RSK-05": [ - "03.11.01.A" + "CC6.4-POF1": [ + "PES-01", + "PES-02", + "PES-02.1", + "PES-03" ], - "RSK-06": [ - "03.11.02.B", - "03.12.02.A.02" + "CC6.4-POF2": [ + "PES-01", + "PES-02", + "PES-02.1", + "PES-03", + "PES-06.6" ], - "RSK-06.1": [ - "03.11.02.B", - "03.11.04" + "CC6.4-POF4": [ + "PES-03.3", + "PES-05" ], - "RSK-06.2": [ - "03.11.02.B" + "CC2.3-POF7": [ + "PRI-01", + "PRI-02", + "TPM-05" ], - "RSK-07": [ - "03.11.01.B" + "CC8.1-POF18": [ + "PRI-01", + "PRI-04", + "PRI-04.1", + "SEA-01" ], - "RSK-09": [ - "03.11.01.A", - "03.17.01.A", - "03.17.01.B", - "03.17.03.A", - "03.17.03.B" + "P1.0": [ + "PRI-01" ], - "RSK-09.1": [ - "03.11.01.A", - "03.11.01.B", - "03.17.03.A" + "P1.1": [ + "PRI-01.2", + "PRI-01.3", + "PRI-02" ], - "SEA-01": [ - "03.01.12.A", - "03.01.16.A", - "03.01.16.B", - "03.01.16.C", - "03.01.18.A", - "03.13.01.C", - "03.16.01" + "P1.1-POF6": [ + "PRI-01.3" ], - "SEA-02": [ - "03.01.12.A", - "03.01.16.A", - "03.01.18.A", - "03.13.01.C", - "03.16.01" + "P4.2-POF2": [ + "PRI-01.6" ], - "SEA-05": [ - "03.13.04" + "P1.1-POF1": [ + "PRI-02", + "PRI-02.1" ], - "SEA-07": [ - "03.16.02.B" + "P1.1-POF2": [ + "PRI-02", + "PRI-02.1" ], - "SEA-07.1": [ - "03.16.02.A", - "03.16.02.B" + "P1.1-POF3": [ + "PRI-02", + "PRI-02.1" ], - "SEA-18": [ - "03.01.09" + "P1.1-POF4": [ + "PRI-02", + "PRI-02.1" ], - "SEA-18.1": [ - "03.01.09" + "P1.1-POF7": [ + "PRI-02" ], - "SEA-18.2": [ - "03.01.09" + "P6.7-POF1": [ + "PRI-02.1", + "PRI-04.1", + "PRM-06" ], - "OPS-01": [ - "03.15.01.A", - "03.15.01.B" + "P2.0": [ + "PRI-03" ], - "OPS-01.1": [ - "03.15.01.A" + "P2.1": [ + "PRI-03", + "PRI-03.2" ], - "OPS-03": [ - "03.15.01.B" + "P2.1-POF1": [ + "PRI-03" ], - "SAT-01": [ - "03.02.01.A" + "P2.1-POF2": [ + "PRI-03" ], - "SAT-02": [ - "03.01.22.A", - "03.02.01.A.01", - "03.02.01.A.02", - "03.02.01.A.03", - "03.02.01.B", - "03.06.04.A.03" + "P2.1-POF3": [ + "PRI-03" ], - "SAT-02.2": [ - "03.02.01.A.03" + "P2.1-POF5": [ + "PRI-03" ], - "SAT-03": [ - "03.01.22.A", - "03.02.01.A.01", - "03.02.01.A.02", - "03.02.02.A", - "03.02.02.A.01", - "03.02.02.A.02", - "03.02.02.B", - "03.06.04.A", - "03.06.04.A.01", - "03.06.04.A.02", - "03.06.04.B" + "P2.1-POF6": [ + "PRI-03" ], - "SAT-03.3": [ - "03.01.22.A", - "03.02.01.A.01", - "03.02.02.A.01" + "P3.2": [ + "PRI-03", + "PRI-03.2" ], - "SAT-03.5": [ - "03.02.01.A.01", - "03.02.02.A.01" + "P3.2-POF2": [ + "PRI-03" ], - "SAT-03.6": [ - "03.02.01.A.01", - "03.02.01.A.02", - "03.02.01.A.03", - "03.02.01.B", - "03.02.02.A.01", - "03.02.02.A.02", - "03.02.02.B", - "03.06.04.A.02" + "P3.2-POF1": [ + "PRI-03.1" ], - "SAT-03.7": [ - "03.06.04.B" + "P2.1-POF4": [ + "PRI-03.2" ], - "TDA-01": [ - "03.12.01", - "03.12.03", - "03.14.01.A", - "03.16.01", - "03.17.02" + "P3.0": [ + "PRI-04" ], - "TDA-01.1": [ - "03.12.03" + "P3.1": [ + "PRI-04", + "PRI-04.1" ], - "TDA-02": [ - "03.16.01" + "P3.1-POF1": [ + "PRI-04" ], - "TDA-02.3": [ - "03.16.01" + "P3.1-POF2": [ + "PRI-04" ], - "TDA-02.4": [ - "03.16.01" + "P3.1-POF3": [ + "PRI-04", + "PRI-04.2" ], - "TDA-03": [ - "03.16.01" + "P3.1-POF4": [ + "PRI-04", + "PRI-06.2" ], - "TDA-05": [ - "03.16.01" + "P4.0": [ + "PRI-05", + "PRI-05.4" ], - "TDA-06": [ - "03.16.01" + "P4.2": [ + "PRI-05" ], - "TDA-09": [ - "03.12.01", - "03.12.03", - "03.14.01.A" + "P4.2-POF1": [ + "PRI-05" ], - "TDA-09.1": [ - "03.12.03" + "P4.1": [ + "PRI-05.1", + "PRI-05.4" ], - "TDA-17": [ - "03.16.02.A" + "P4.1-POF1": [ + "PRI-05.4" ], - "TDA-17.1": [ - "03.16.02.B" + "P5.0": [ + "PRI-06" ], - "TPM-01": [ - "03.01.20.A", - "03.01.20.B", - "03.01.20.C.01", - "03.07.06.A", - "03.16.01", - "03.16.03.A" + "P5.1-POF1": [ + "PRI-06" ], - "TPM-01.1": [ - "03.07.06.A" + "P5.1-POF2": [ + "PRI-06" ], - "TPM-02": [ - "03.11.01.A", - "03.17.03.A" + "P5.1-POF3": [ + "PRI-06" ], - "TPM-03": [ - "03.11.01.A", - "03.17.01.A", - "03.17.03.A", - "03.17.03.B" + "P5.2-POF2": [ + "PRI-06.1", + "PRI-06.2", + "PRI-12" ], - "TPM-03.1": [ - "03.17.01.A", - "03.17.02", - "03.17.03.A", - "03.17.03.B" + "P5.2-POF3": [ + "PRI-06.2", + "PRI-06.4", + "PRI-07.4" ], - "TPM-03.2": [ - "03.17.03.A", - "03.17.03.B" - ], - "TPM-03.3": [ - "03.17.03.A", - "03.17.03.B" - ], - "TPM-04": [ - "03.16.03.A", - "03.16.03.C", - "03.17.02", - "03.17.03.A", - "03.17.03.B" - ], - "TPM-04.1": [ - "03.11.01.A", - "03.17.02", - "03.17.03.A", - "03.17.03.B" - ], - "TPM-04.4": [ - "03.16.03.A" - ], - "TPM-05": [ - "03.01.20.B", - "03.01.20.C.01", - "03.01.20.C.02", - "03.07.06.A", - "03.16.03.A", - "03.16.03.B", - "03.16.03.C", - "03.17.02", - "03.17.03.B" + "P4.3-POF1": [ + "PRI-06.4", + "PRI-06.5" ], - "TPM-05.1": [ - "03.17.02" + "P5.1-POF4": [ + "PRI-06.4", + "PRI-07.4" ], - "TPM-05.2": [ - "03.16.03.A", - "03.16.03.B", - "03.16.03.C", - "03.17.02", - "03.17.03.B" + "P5.1-POF5": [ + "PRI-06.4" ], - "TPM-05.4": [ - "03.07.06.A", - "03.16.03.B" + "P5.2-POF1": [ + "PRI-06.4", + "PRI-07.4" ], - "TPM-05.5": [ - "03.16.03.C", - "03.17.02", - "03.17.03.A", - "03.17.03.B" + "P5.2-POF4": [ + "PRI-06.4" ], - "TPM-05.6": [ - "03.01.20.C.01", - "03.16.03.C" + "P6.7-POF2": [ + "PRI-06.4", + "PRI-06.6", + "PRI-06.7" ], - "TPM-05.7": [ - "03.17.01.A", - "03.17.02", - "03.17.03.B" + "P8.1": [ + "PRI-06.4" ], - "TPM-05.8": [ - "03.01.20.A", - "03.01.20.B", - "03.01.20.C.01", - "03.16.03.A", - "03.16.03.C" + "P8.1-POF1": [ + "PRI-06.4" ], - "TPM-08": [ - "03.16.03.C", - "03.17.02" + "P8.1-POF2": [ + "PRI-06.4" ], - "TPM-09": [ - "03.17.02" + "P8.1-POF3": [ + "PRI-06.4" ], - "TPM-10": [ - "03.16.01", - "03.17.02" + "P6.1": [ + "PRI-07" ], - "THR-01": [ - "03.11.02.A", - "03.14.03.A" + "P6.1-POF1": [ + "PRI-07", + "PRI-07.1" ], - "THR-03": [ - "03.02.01.A.02", - "03.02.01.A.03", - "03.02.01.B", - "03.02.02.B", - "03.11.02.A", - "03.14.03.A" + "P6.4": [ + "PRI-07.1" ], - "THR-03.1": [ - "03.14.03.B" + "P6.4-POF3": [ + "PRI-07.1", + "TPM-05", + "TPM-05.2" ], - "THR-05": [ - "03.02.01.A.03" + "P8.0": [ + "PRI-08" ], - "THR-09": [ - "03.15.02.A.03" + "P8.1-POF6": [ + "PRI-08" ], - "THR-10": [ - "03.14.03.B" + "P7.0": [ + "PRI-10" ], - "VPM-01": [ - "03.11.02.A", - "03.14.01.A" + "P7.1": [ + "PRI-10" ], - "VPM-01.1": [ - "03.11.02.A", - "03.14.01.A" + "P7.1-POF1": [ + "PRI-10" ], - "VPM-02": [ - "03.11.02.B", - "03.12.02.A.02", - "03.14.01.A" + "P7.1-POF2": [ + "PRI-10" ], - "VPM-03": [ - "03.11.02.A" + "P8.1-POF4": [ + "PRI-14" ], - "VPM-04": [ - "03.11.02.B", - "03.14.01.A", - "03.14.01.B" + "P8.1-POF5": [ + "PRI-14" ], - "VPM-05": [ - "03.11.02.B", - "03.12.02.A.02", - "03.14.01.A", - "03.14.01.B" + "P6.2": [ + "PRI-14.1" ], - "VPM-06": [ - "03.11.02.A" + "P6.2-POF1": [ + "PRI-14.1" ], - "VPM-06.1": [ - "03.11.02.C" + "P6.3-POF1": [ + "PRI-14.1" ], - "WEB-01": [ - "03.01.22.A" + "P6.7-POF3": [ + "PRI-17", + "PRI-18" ], - "WEB-14": [ - "03.01.22.B" - ] - }, - "americas-can-pipeda-2000": { - "GOV-01": [ - "Principle 7" + "CC3.1-POF4": [ + "PRM-01", + "PRM-03" ], - "CPL-01": [ - "Principle 7" + "CC5.2": [ + "PRM-01", + "PRM-04", + "PRM-05", + "PRM-06", + "PRM-07", + "RSK-08", + "RSK-10", + "SEA-01", + "TDA-01", + "TDA-02" ], - "CPL-02": [ - "Principle 7" + "PI1.1-POF1": [ + "PRM-05", + "PRM-06", + "TDA-01.1", + "TDA-02" ], - "DCH-01": [ - "Principle 7" + "PI1.1-POF2": [ + "PRM-05", + "TDA-01.1", + "TDA-02" ], - "DCH-22.1": [ - "Principle 10" + "PI1.1-POF3": [ + "PRM-05", + "TDA-01.1", + "TDA-02" ], - "DCH-24": [ - "Sec 20" + "CC3.1-POF7": [ + "PRM-06", + "OPS-03" ], - "DCH-24.1": [ - "Sec 20" + "CC3.1-POF12": [ + "PRM-06", + "OPS-03" ], - "DCH-25": [ - "Sec 20" + "CC3.1-POF13": [ + "PRM-06", + "OPS-03" ], - "PRI-01": [ - "Principle 1", - "Principle 8" + "CC3.1-POF16": [ + "PRM-06", + "RSK-01.1", + "RSK-04", + "OPS-03" ], - "PRI-01.4": [ - "Sec 6" + "PI1.1": [ + "PRM-06", + "RSK-10", + "OPS-03", + "TDA-06", + "TDA-06.1" ], - "PRI-02": [ - "Principle 2" + "PI1.3-POF1": [ + "PRM-06", + "OPS-03", + "TDA-06" ], - "PRI-02.1": [ - "Sec 5", - "Principle 2" + "PI1.3-POF2": [ + "PRM-06", + "OPS-03", + "TDA-06" ], - "PRI-03": [ - "Sec 6", - "Sec 7", - "Principle 3" + "PI1.3-POF3": [ + "PRM-06", + "OPS-03", + "TDA-06" ], - "PRI-03.2": [ - "Sec 6", - "Sec 7", - "Principle 3" + "PI1.3-POF4": [ + "PRM-06", + "OPS-03", + "TDA-06" ], - "PRI-04": [ - "Sec 5", - "Principle 4" + "PI1.3-POF5": [ + "PRM-06", + "OPS-03", + "TDA-06" ], - "PRI-04.1": [ - "Sec 5", - "Principle 4" + "CC3.2-POF1": [ + "RSK-01", + "RSK-03", + "RSK-04" ], - "PRI-05": [ - "Sec 7", - "Sec 8", - "Principle 5", - "Principle 6" + "CC3.2-POF5": [ + "RSK-01", + "RSK-06.1" ], - "PRI-05.2": [ - "Principle 6" + "CC3.4-POF1": [ + "RSK-01", + "RSK-03", + "RSK-04" ], - "PRI-06": [ - "Principle 8", - "Principle 9" + "CC3.4-POF2": [ + "RSK-01", + "RSK-03", + "RSK-04" ], - "PRI-06.1": [ - "Principle 10" + "CC3.4-POF5": [ + "RSK-01", + "RSK-03", + "RSK-04", + "TPM-01", + "TPM-05.5", + "TPM-08", + "TPM-10" ], - "PRI-06.3": [ - "Sec 11" + "CC3.2": [ + "RSK-01.1", + "RSK-01.3", + "RSK-02", + "RSK-03", + "RSK-08", + "RSK-09", + "RSK-10", + "SEA-01" ], - "PRI-07": [ - "Sec 20", - "Sec 23" + "CC3.2-POF2": [ + "RSK-01.1", + "RSK-03", + "RSK-04" ], - "PRI-07.1": [ - "Sec 20", - "Sec 23" + "CC3.2-POF8": [ + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-04", + "RSK-05", + "RSK-09", + "TPM-02", + "TPM-04.1", + "TPM-05.6" ], - "SEA-01": [ - "Principle 7" + "CC3.1-POF2": [ + "RSK-01.3", + "RSK-01.4", + "RSK-01.5" ], - "SEA-02": [ - "Principle 7" + "CC3.2-POF4": [ + "RSK-02.1", + "RSK-05" ], - "SEA-03": [ - "Principle 7" + "CC3.2-POF6": [ + "RSK-03", + "RSK-03.1", + "RSK-04", + "THR-01", + "THR-02", + "THR-03", + "THR-09", + "THR-10" ], - "SEA-15": [ - "Sec 20" + "CC3.2-POF9": [ + "RSK-04", + "RSK-09.1", + "TPM-02", + "TPM-04.1", + "THR-10", + "VPM-01", + "VPM-01.1", + "VPM-03.1" ], - "TPM-04.4": [ - "Sec 20" - ] - }, - "americas-chl-act-19628-1999": { - "GOV-01": [ - "7" + "CC5.3-POF4": [ + "RSK-06", + "VPM-02" ], - "CPL-01": [ - "7" + "CC3.2-POF7": [ + "RSK-09", + "RSK-09.1", + "TPM-03", + "THR-01", + "THR-02", + "THR-03", + "VPM-01", + "VPM-01.1", + "VPM-06" ], - "CPL-02": [ - "7" + "CC9.2": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-04.1" ], - "CPL-03": [ - "7" + "CC9.2-POF1": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-03", + "TPM-05", + "TPM-05.2" ], - "DCH-01": [ - "7" + "CC9.2-POF2": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-03", + "TPM-04.1" ], - "DCH-22.1": [ - "13" + "CC9.2-POF3": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-03", + "TPM-04.1" ], - "DCH-24": [ - "7" + "CC9.2-POF4": [ + "RSK-09", + "TPM-01", + "TPM-03", + "TPM-05.4" ], - "DCH-24.1": [ - "7" + "CC9.2-POF7": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-03", + "TPM-05.5", + "TPM-08" ], - "PRI-01": [ - "Inferred", - "Expectation" + "CC9.2-POF8": [ + "RSK-09", + "TPM-01", + "TPM-03", + "TPM-04.1", + "TPM-05.7", + "TPM-08", + "TPM-09", + "TPM-10" ], - "PRI-01.1": [ - "7", - "11" + "CC9.2-POF9": [ + "RSK-09", + "TPM-01", + "TPM-03", + "TPM-05", + "TPM-05.2", + "TPM-05.6", + "TPM-05.7" ], - "PRI-02": [ - "5" + "CC9.2-POF10": [ + "RSK-09", + "TPM-01", + "TPM-03", + "TPM-05", + "TPM-05.2", + "TPM-05.6" ], - "PRI-02.1": [ - "5" + "CC9.2-POF11": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-04.1", + "TPM-05.6" ], - "PRI-03": [ - "4" + "CC9.2-POF12": [ + "RSK-09", + "TPM-01", + "TPM-03", + "TPM-05.4", + "TPM-05.5", + "TPM-05.6", + "TPM-08" ], - "PRI-05": [ - "9" + "CC5.3-POF3": [ + "OPS-01.1", + "OPS-03" ], - "PRI-05.4": [ - "10" + "CC2.3-POF6": [ + "OPS-03", + "TPM-05", + "TPM-05.4" ], - "PRI-06": [ - "12" + "CC2.2-POF8": [ + "SAT-01", + "SAT-02", + "SAT-03.6" ], - "PRI-06.1": [ - "13" + "CC1.4-POF7": [ + "SAT-02", + "SAT-03", + "SAT-03.7", + "SAT-03.8" ], - "SEA-01": [ - "7" + "CC2.2-POF9": [ + "SAT-03.3", + "SAT-03.5", + "TPM-05.4", + "TPM-05.5", + "VPM-01.1" ], - "SEA-02": [ - "7" + "CC5.2-POF4": [ + "TDA-01" ], - "SEA-03": [ - "7" + "PI1.2": [ + "TDA-01", + "TDA-06" ], - "SEA-15": [ - "7" + "PI1.3": [ + "TDA-01", + "TDA-06" ], - "TPM-04.4": [ - "7" - ] - }, - "americas-col-law-1581-2012": { - "GOV-01": [ - "4" + "PI1.2-POF1": [ + "TDA-06", + "TDA-18" ], - "CPL-01": [ - "4" + "PI1.2-POF2": [ + "TDA-06", + "TDA-18" ], - "DCH-22.1": [ - "8", - "11" + "PI1.2-POF3": [ + "TDA-06", + "TDA-18" ], - "DCH-24": [ - "26" + "CC1.1-POF5": [ + "TPM-01", + "TPM-03", + "TPM-05", + "TPM-05.4", + "TPM-06" ], - "DCH-24.1": [ - "26" + "CC3.3": [ + "TPM-01", + "TPM-03.1", + "TPM-04", + "TPM-04.3", + "THR-01", + "THR-02", + "THR-04" ], - "DCH-25": [ - "26" + "CC9.2-POF5": [ + "TPM-01", + "TPM-05" ], - "PRI-01": [ - "4" + "CC9.2-POF6": [ + "TPM-01", + "TPM-05", + "TPM-08" ], - "PRI-01.1": [ - "17", - "18" + "P6.4-POF2": [ + "TPM-03.2", + "TPM-05.7", + "TPM-09" ], - "PRI-02": [ - "12" + "P6.5-POF1": [ + "TPM-03.2", + "TPM-05.7", + "TPM-09" ], - "PRI-02.1": [ - "4" + "P6.5-POF2": [ + "TPM-03.2", + "TPM-05.7", + "TPM-09" ], - "PRI-03": [ - "4" + "P6.6-POF1": [ + "TPM-03.2", + "TPM-05.7", + "TPM-09" ], - "PRI-04": [ - "4" + "CC9.2-POF13": [ + "TPM-05.1", + "TPM-07", + "TPM-08", + "THR-01", + "THR-02", + "THR-03", + "VPM-01", + "VPM-01.1", + "VPM-06" ], - "PRI-04.1": [ - "4" + "P6.5": [ + "TPM-11" ], - "PRI-05": [ - "4" + "CC3.4-POF6": [ + "THR-01", + "THR-10", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-03.1", + "VPM-06" ], - "PRI-05.1": [ - "4" + "CC7.1-POF5": [ + "VPM-06" + ] + }, + "general-apec-privacy-framework-2015": { + "1": [ + "PRI-01" ], - "PRI-05.2": [ - "4" + "2": [ + "PRI-02" ], - "PRI-05.4": [ - "4", - "5", - "6", - "7" + "3": [ + "PRI-04" ], - "PRI-06": [ - "8", - "11" + "4": [ + "PRI-03.9" ], - "PRI-06.1": [ - "8", - "11" + "5": [ + "PRI-03" ], - "PRI-06.2": [ - "8", - "11" + "6": [ + "PRI-05.2" ], - "PRI-06.3": [ - "15" + "7": [ + "PRI-01.6" ], - "PRI-06.4": [ - "12", - "15" + "9": [ + "HRS-03", + "PRI-01", + "PRI-01.1" ], - "PRI-07": [ - "26" + "2-1": [ + "PRI-01.11" ], - "PRI-15": [ - "25" + "2-2": [ + "PRI-01.11" ], - "SEA-01": [ - "4", - "26" + "2(a)": [ + "PRI-02" ], - "SEA-02": [ - "4", - "26" + "2(b)": [ + "PRI-02" ], - "SEA-03": [ - "4", - "26" + "2(c)": [ + "PRI-02" ], - "SEA-15": [ - "26" + "2(d)": [ + "PRI-02" ], - "TPM-04.4": [ - "26" - ] - }, - "americas-mex-fdpa-2010": { - "GOV-01": [ - "19" + "2(e)": [ + "PRI-02", + "PRI-03" ], - "CPL-01": [ - "19" + "4(a)": [ + "PRI-03" ], - "DCH-22.1": [ - "24", - "28", - "29" + "4(b)": [ + "PRI-03.9" ], - "IRO-04.1": [ - "20" + "4(c)": [ + "PRI-04.1" ], - "PRI-01": [ - "6", - "14", - "30" + "8(c)": [ + "PRI-06", + "PRI-06.1" ], - "PRI-02": [ - "7", - "16", - "17", - "18" + "8(a)": [ + "PRI-06.7" ], - "PRI-02.1": [ - "7", - "16", - "17", - "18" + "8(b)": [ + "PRI-06.7" ], - "PRI-02.2": [ - "7" + "8(b)(i)": [ + "PRI-06.7" ], - "PRI-03": [ - "8", - "10" + "8(b)(ii)": [ + "PRI-06.7" ], - "PRI-03.2": [ - "7" + "8(b)(iii)": [ + "PRI-06.7" ], - "PRI-04": [ - "7" + "8(b)(iv)": [ + "PRI-06.7" + ] + }, + "general-bsi-200-1-1-0": { + "5": [ + "PRM-01", + "PRM-02" ], - "PRI-04.1": [ - "7" + "6": [ + "HRS-01", + "HRS-01.1", + "HRS-02", + "HRS-03.1", + "SAT-01", + "SAT-01.1", + "SAT-02", + "SAT-03", + "SAT-03.6" ], - "PRI-05": [ - "7", - "8", - "9", - "11", - "12", - "13", - "14" + "7": [ + "PRM-01", + "PRM-01.1" ], - "PRI-05.2": [ - "9" + "9": [ + "CPL-01.3", + "CPL-01.4" ], - "PRI-05.4": [ - "7", - "9" + "4.1.2": [ + "GOV-01", + "GOV-01.1", + "PRM-01.1", + "PRM-03" ], - "PRI-06": [ - "15", - "22", - "23", - "25" + "4.1.3": [ + "GOV-01", + "GOV-14", + "GOV-15", + "IRO-01", + "PRM-01", + "PRM-02" ], - "PRI-06.1": [ - "24", - "28", - "29" + "7.1": [ + "GOV-01" ], - "PRI-06.4": [ - "30" + "8.1": [ + "GOV-01" ], - "SEA-01": [ - "19", - "36", - "37" + "8.2": [ + "GOV-01" ], - "SEA-02": [ - "19", - "36", - "37" + "8.3": [ + "GOV-01" ], - "SEA-03": [ - "19", - "36", - "37" + "4.1.1": [ + "GOV-01.1", + "GOV-04" ], - "TPM-03": [ - "21" + "4.3": [ + "GOV-01.1", + "GOV-01.2", + "GOV-05" ], - "TPM-05": [ - "21" - ] - } - }, - "framework_to_scf": { - "general-aicpa-pmf-2020": { - "M1.2-POF6": [ - "GOV-01", - "CPL-01.1" + "4.4": [ + "GOV-01.1", + "GOV-01.3" ], - "M1.3-POF4": [ + "7.4": [ + "GOV-01.1", "GOV-01.3", - "GOV-03" - ], - "M1.0": [ - "GOV-02", - "PRI-01" + "CPL-01.1", + "CPL-02.1" ], - "M1.2": [ - "GOV-02", - "PRI-01" + "7.5": [ + "GOV-01.1", + "GOV-01.2", + "GOV-01.3" ], - "M1.2-POF8": [ - "GOV-02" + "8.4": [ + "GOV-01.1", + "GOV-01.2", + "GOV-01.3" ], - "D6.1-POF1": [ + "7.3": [ "GOV-02", - "PRI-01" - ], - "M1.2-POF5": [ "GOV-03" ], - "M1.2-POF1": [ + "4.1.6": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" + ], + "7.2": [ "GOV-04", "GOV-04.1", "GOV-04.2", - "PRI-01.1" + "HRS-03" ], - "M1.2-POF2": [ - "GOV-04.1" + "4.2": [ + "HRS-03.1", + "SAT-03.6", + "THR-03.1" ], - "S7.1-POF1": [ - "AST-01" + "4.1.4": [ + "PRM-01", + "PRM-04", + "PRM-05", + "PRM-06" ], - "M1.4": [ + "4.1.5": [ + "PRM-01" + ] + }, + "general-cis-csc-8-1": { + "1": [ + "AST-01", + "AST-02" + ], + "2": [ + "AST-01", "AST-02", - "DCH-06.2", - "PRI-05.5" + "CFG-01" ], - "S7.2-POF2": [ - "AST-11" + "3": [ + "DCH-01" ], - "S7.4-POF1": [ - "BCD-01" + "4": [ + "CFG-01", + "CFG-03" ], - "S7.5-POF3": [ - "BCD-04" + "5": [ + "IAC-01", + "IAC-15.1" ], - "S7.5-POF4": [ - "BCD-11.1", - "BCD-11.5" + "6": [ + "IAC-01", + "IAC-08", + "IAC-15.1" ], - "M1.2-POF9": [ - "CPL-01" + "7": [ + "VPM-01", + "VPM-04" ], - "M1.2-POF7": [ - "CPL-01.1" + "8": [ + "MON-01" ], - "M9.1-POF4": [ - "CPL-01.1" + "9": [ + "CFG-04.2", + "END-08", + "HRS-05.2", + "IRO-15", + "NET-18", + "SAT-02.2" ], - "M9.1-POF5": [ - "CPL-01.1" + "10": [ + "END-01", + "END-02", + "END-04" ], - "M1.0-POF8": [ - "CPL-02" + "11": [ + "BCD-01", + "DCH-01", + "END-02" ], - "S7.5-POF1": [ - "CPL-02", - "CPL-03" + "12": [ + "NET-01" ], - "M9.1-POF6": [ - "CPL-02" + "13": [ + "MON-01" ], - "S7.5": [ - "CPL-03", - "CPL-03.2" + "14": [ + "SAT-01" ], - "S7.1-POF8": [ - "CFG-01", - "IAC-01" + "15": [ + "TPM-01", + "TPM-05.4", + "TPM-05.5", + "TPM-08" ], - "S7.1-POF2": [ - "MON-01", - "IAC-01", - "PES-01" + "16": [ + "SEA-01", + "TDA-01", + "TDA-06", + "WEB-07", + "WEB-08" ], - "S7.1-POF9": [ - "CRY-01" + "17": [ + "IRO-01", + "IRO-02" ], - "S7.3-POF2": [ - "CRY-03", - "CRY-05" + "18": [ + "VPM-01", + "VPM-07" ], - "S7.1-POF10": [ - "CRY-09" + "2.1": [ + "AST-01", + "AST-02", + "AST-02.9" ], - "M1.0-POF4": [ - "DCH-01", - "DCH-01.2", - "DCH-01.4", - "IAC-20" + "2.2": [ + "AST-01", + "AST-02", + "AST-02.7", + "RSK-06.2", + "TDA-17" ], - "S7.4": [ - "DCH-01", - "DCH-01.2" + "1.1": [ + "AST-02" ], - "M1.3": [ - "DCH-02", - "PRI-05.7" + "2.4": [ + "AST-02", + "AST-02.2", + "AST-02.9", + "CFG-06.1", + "END-06.2" ], - "M1.0-POF5": [ - "DCH-03.1", - "PRI-01.7" + "6.6": [ + "AST-02", + "IAC-01", + "IAC-01.2" ], - "S7.3-POF4": [ - "DCH-12" + "1.2": [ + "AST-02.2", + "NET-08.3" ], - "S7.3": [ - "DCH-17", - "DCH-25", - "PRI-07" + "1.3": [ + "AST-02.2", + "AST-02.3" ], - "U4.2-POF1": [ - "DCH-18", - "PRI-05" + "1.5": [ + "AST-02.2", + "AST-02.6" ], - "U4.2-POF2": [ - "DCH-18" + "2.3": [ + "AST-02.2", + "CFG-02.8", + "CFG-03.3", + "CFG-05.1", + "CFG-06.1", + "MON-16.3", + "END-03.1", + "END-06.2", + "IRO-02" ], - "M1.0-POF7": [ - "DCH-22", - "PRI-05.2" + "13.9": [ + "AST-02.5" ], - "D6.1": [ - "DCH-25", - "PRI-01.7" + "1.4": [ + "AST-02.6" ], - "S7.3-POF3": [ - "END-01", - "END-01.1" + "16.5": [ + "AST-03.2", + "TDA-06", + "TDA-06.3", + "TDA-11", + "TDA-14.1" ], - "S7.1-POF11": [ - "END-04", - "END-04.1" + "3.8": [ + "AST-04", + "DCH-14.3" ], - "M1.2-POF3": [ - "HRS-03", - "HRS-03.1", - "HRS-04.2", - "SAT-03", - "SAT-03.3" + "12.4": [ + "AST-04" ], - "M1.2-POF4": [ - "HRS-03.2" + "3.5": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21", + "PRI-05" ], - "S7.1": [ - "IAC-01" + "4.11": [ + "AST-16", + "MDM-01", + "MDM-05" ], - "S7.1-POF3": [ - "IAC-01" + "11.1": [ + "BCD-01" ], - "S7.1-POF6": [ - "IAC-01", - "PES-01" + "11.2": [ + "BCD-11" ], - "S7.1-POF7": [ - "IAC-01" + "11.3": [ + "BCD-11.1", + "BCD-11.4", + "BCD-12", + "BCD-13", + "DCH-01" ], - "M1.3-POF3": [ - "IRO-01", - "IRO-02", - "IRO-04" + "11.5": [ + "BCD-11.1", + "BCD-11.5" ], - "D6.6": [ - "IRO-04.1", - "IRO-10", - "IRO-10.2" + "11.4": [ + "BCD-14" ], - "D6.6-POF2": [ - "IRO-04.1", - "IRO-10", - "IRO-10.2" + "18.4": [ + "CHG-06" ], - "S7.5-POF2": [ - "IRO-06" + "4.1": [ + "CFG-01", + "CFG-02", + "CFG-02.1" ], - "S7.1-POF5": [ - "NET-01" + "4.2": [ + "CFG-01", + "CFG-02" ], - "S7.1-POF4": [ - "NET-06" + "4.3": [ + "CFG-02", + "IAC-24" ], - "S7.3-POF1": [ - "NET-17" + "4.4": [ + "CFG-02", + "END-05", + "WEB-03" ], - "S7.2-POF1": [ - "PES-02" + "4.5": [ + "CFG-02", + "END-05" ], - "S7.2-POF3": [ - "PES-02", - "PES-02.1" + "4.6": [ + "CFG-02", + "CFG-03", + "CRY-06", + "MNT-05", + "NET-04", + "TDA-02.6" ], - "S7.2": [ - "PES-02.1", - "PES-03" + "4.7": [ + "CFG-02", + "IAC-01", + "IAC-10.8" ], - "S7.2-POF4": [ - "PES-03" + "4.8": [ + "CFG-02", + "CFG-03" ], - "S7.2-POF5": [ - "PES-03", - "PES-03.2", - "PES-03.4", - "PES-04" + "4.10": [ + "CFG-02", + "IAC-22" ], - "S7.2-POF6": [ - "PES-07", - "PES-07.1", - "PES-07.2", - "PES-07.3", - "PES-07.4", - "PES-07.5", - "THR-09" + "10.3": [ + "CFG-02", + "END-02" ], - "N2.2-POF1": [ - "PRI-01", - "PRI-01.1", - "PRI-01.11" + "10.4": [ + "CFG-02", + "END-02", + "END-04", + "END-04.7" ], - "M1.0-POF1": [ - "PRI-01.3", - "PRI-02" + "10.5": [ + "CFG-02", + "END-02" ], - "M1.0-POF6": [ - "PRI-01.6" + "16.7": [ + "CFG-02", + "CFG-02.5", + "TDA-06.5", + "TDA-12", + "WEB-07" ], - "M1.4-POF1": [ - "PRI-01.6" + "2.5": [ + "CFG-03.2", + "CFG-03.3" ], - "D6.1-POF2": [ - "PRI-01.7" + "2.6": [ + "CFG-03.3" ], - "N2.1": [ - "PRI-02" + "2.7": [ + "CFG-03.3", + "IAC-16", + "MNT-04", + "MNT-04.4" ], - "N2.1-POF2": [ - "PRI-02", - "PRI-03.2" + "9.1": [ + "CFG-04.2", + "CFG-05.2" ], - "N2.1-POF3": [ - "PRI-02" + "9.4": [ + "CFG-04.2", + "CFG-05.2", + "HRS-05.1", + "HRS-05.4" ], - "N2.1-POF4": [ - "PRI-02" + "8.2": [ + "MON-01", + "MON-01.4", + "MON-02", + "MON-02.7", + "MON-03" ], - "N2.2": [ - "PRI-02", - "PRI-03.2" + "13.6": [ + "MON-01", + "MON-01.13", + "MON-02.1", + "MON-02.3" ], - "C3.1-POF3": [ - "PRI-02", - "PRI-03", - "PRI-03.5" + "8.1": [ + "MON-01.8", + "MON-02" ], - "M9.1-POF1": [ - "PRI-02" + "13.11": [ + "MON-01.13" ], - "C3.2-POF1": [ - "PRI-02.1", - "PRI-03.2" + "3.14": [ + "MON-01.15", + "MON-02", + "MON-02.1", + "MON-02.3", + "MON-03", + "MON-03.1" ], - "N2.1-POF1": [ - "PRI-03", - "PRI-03.2" + "8.3": [ + "MON-02", + "MON-04" ], - "C3.1": [ - "PRI-03" + "8.4": [ + "MON-02", + "MON-07.1" ], - "C3.1-POF1": [ - "PRI-03" + "8.5": [ + "MON-02", + "MON-03" ], - "C3.2": [ - "PRI-03" + "8.6": [ + "MON-02", + "MON-02.3" ], - "C3.2-POF2": [ - "PRI-03", - "PRI-03.12" + "8.7": [ + "MON-02", + "MON-02.3" ], - "C3.2-POF3": [ - "PRI-03", - "PRI-03.12" + "8.8": [ + "MON-02", + "MON-03.3" ], - "C3.2-POF4": [ - "PRI-03" + "8.9": [ + "MON-02" ], - "N2.1-POF5": [ - "PRI-03.4" + "8.12": [ + "MON-02", + "MON-02.1", + "MON-02.3" ], - "C3.1-POF2": [ - "PRI-03.5", - "PRI-21" + "13.1": [ + "MON-02" ], - "M1.0-POF2": [ - "PRI-04", - "PRI-04.1", - "PRI-04.7" + "8.11": [ + "MON-02.2" ], - "C3.1-POF4": [ - "PRI-04" + "8.10": [ + "MON-04", + "MON-10" ], - "U4.2": [ - "PRI-05" + "3.6": [ + "CRY-01", + "CRY-05" ], - "U4.3": [ - "PRI-05" + "3.9": [ + "CRY-01", + "CRY-05", + "CRY-05.1" ], - "U4.3-POF1": [ - "PRI-05" + "3.10": [ + "CRY-01", + "CRY-03" ], - "U4.3-POF2": [ - "PRI-05" + "3.11": [ + "CRY-01", + "CRY-05" ], - "U4.3-POF3": [ - "PRI-05" + "12.3": [ + "CRY-06", + "MNT-05.3", + "NET-01" ], - "Q8.1": [ - "PRI-05.2" + "3.1": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-03", + "DCH-03.1", + "DCH-08", + "DCH-09", + "DCH-18" ], - "Q8.1-POF2": [ - "PRI-05.2" + "3.3": [ + "DCH-01", + "DCH-01.4", + "DCH-03", + "DCH-03.1", + "DCH-13.1", + "DCH-14", + "DCH-14.2", + "DCH-14.3", + "IAC-08", + "NET-04" ], - "M1.0-POF3": [ - "PRI-05.4" + "3.7": [ + "DCH-02", + "DCH-02.1" ], - "U4.1": [ - "PRI-05.4" + "3.12": [ + "DCH-02.1", + "SEA-03.1" ], - "U4.1-POF1": [ - "PRI-05.4" + "3.2": [ + "DCH-06.2", + "DCH-06.3" ], - "Q8.1-POF3": [ - "PRI-05.4" + "3.4": [ + "DCH-18" ], - "M1.3-POF1": [ - "PRI-05.7" + "10.1": [ + "END-04" ], - "D6.7": [ - "PRI-05.7", - "PRI-06", - "PRI-06.7" + "10.2": [ + "END-04.1" ], - "A5.1": [ - "PRI-06" + "10.6": [ + "END-04.3" ], - "A5.1-POF2": [ - "PRI-06" + "10.7": [ + "END-04.4" ], - "D6.7-POF1": [ - "PRI-06" + "13.7": [ + "END-06.2", + "END-07" ], - "D6.7-POF2": [ - "PRI-06" + "13.2": [ + "END-07" ], - "A5.2": [ - "PRI-06.1" + "9.6": [ + "END-08", + "IRO-15", + "NET-03", + "NET-08" ], - "A5.2-POF2": [ - "PRI-06.1" + "9.7": [ + "END-08", + "IRO-15" ], - "A5.1-POF4": [ - "PRI-06.4" + "5.6": [ + "IAC-01", + "IAC-01.2", + "IAC-02", + "IAC-09", + "IAC-15.1" ], - "A5.2-POF1": [ - "PRI-06.4" + "12.5": [ + "IAC-01.2", + "IAC-02", + "IAC-03", + "IAC-04" ], - "A5.2-POF3": [ - "PRI-06.4" + "5.5": [ + "IAC-02", + "IAC-05", + "IAC-16.1" ], - "M9.1": [ - "PRI-06.4" + "6.7": [ + "IAC-02", + "IAC-13.1", + "IAC-13.2" ], - "M9.1-POF2": [ - "PRI-06.4" + "6.3": [ + "IAC-06" ], - "M9.1-POF3": [ - "PRI-06.4" + "6.4": [ + "IAC-06" ], - "A5.1-POF3": [ - "PRI-06.7" + "6.5": [ + "IAC-06.1" ], - "A5.1-POF1": [ - "PRI-06.8" + "6.1": [ + "IAC-07" ], - "D6.1-POF3": [ - "PRI-07" + "6.2": [ + "IAC-07" ], - "D6.1-POF4": [ - "PRI-07" + "6.8": [ + "IAC-08" ], - "D6.4-POF1": [ - "PRI-07", - "TPM-04.1" + "5.2": [ + "IAC-10", + "IAC-10.1" ], - "D6.4": [ - "PRI-07.1" + "5.3": [ + "IAC-15.3" ], - "D6.2": [ - "PRI-14", - "PRI-14.1" + "5.1": [ + "IAC-16", + "IAC-16.1" ], - "D6.2-POF1": [ - "PRI-14", - "PRI-14.1" + "5.4": [ + "IAC-16", + "IAC-21", + "IAC-21.2" ], - "D6.3": [ - "PRI-14.1" + "12.8": [ + "IAC-20.4" ], - "D6.3-POF1": [ - "PRI-14.1" + "17.5": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-07" ], - "M1.3-POF2": [ - "RSK-10" + "17.1": [ + "IRO-02", + "IRO-04", + "IRO-07" ], - "D6.5": [ - "TPM-05" + "17.3": [ + "IRO-02" ], - "D6.5-POF2": [ - "TPM-05", - "TPM-05.2" + "17.4": [ + "IRO-02", + "IRO-04", + "IRO-07" ], - "D6.5-POF1": [ - "TPM-05.7", - "TPM-09" + "17.6": [ + "IRO-02", + "IRO-04", + "IRO-07", + "IRO-09" ], - "D6.6-POF1": [ - "TPM-05.7", - "TPM-09" - ] - }, - "general-aicpa-tsc-2017": { - "CC1.1": [ - "GOV-01", - "GOV-04", - "CPL-02", - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-07.1" + "17.9": [ + "IRO-02", + "IRO-04", + "IRO-07" ], - "CC1.1-POF1": [ - "GOV-01", - "GOV-14", - "HRS-01" + "17.7": [ + "IRO-06" ], - "CC1.2": [ - "GOV-01", - "GOV-01.1", - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "HRS-02", - "HRS-03", - "HRS-03.2" + "17.2": [ + "IRO-09", + "IRO-10", + "IRO-10.2", + "IRO-10.3", + "IRO-10.4" ], - "CC2.3-POF5": [ - "GOV-01", - "GOV-01.2", - "CPL-01" + "16.3": [ + "IRO-13", + "TDA-09" ], - "CC1.2-POF1": [ - "GOV-01.1", - "GOV-02", - "GOV-04.1", - "GOV-04.2", - "GOV-08", - "GOV-10", - "HRS-01", - "HRS-02", - "HRS-03" + "17.8": [ + "IRO-13" ], - "CC1.2-POF2": [ - "GOV-01.1", - "HRS-01", - "HRS-02", - "HRS-03", - "HRS-03.2" + "15.4": [ + "IAO-03.2", + "PRI-07.1", + "TPM-03.2", + "TPM-04", + "TPM-05" ], - "CC1.2-POF3": [ - "GOV-01.1", - "HRS-01", - "HRS-02" + "4.12": [ + "MDM-10" ], - "CC1.2-POF4": [ - "GOV-01.1", - "HRS-01", - "HRS-02", - "HRS-03.2" + "12.1": [ + "NET-01", + "VPM-04", + "VPM-04.1", + "VPM-05" ], - "CC1.3-POF1": [ - "GOV-01.1", - "GOV-04.1", - "GOV-04.2" + "12.2": [ + "NET-01", + "NET-02", + "SEA-01", + "SEA-02" ], - "CC1.3-POF3": [ - "GOV-01.1", - "GOV-04.1", - "GOV-04.2", - "HRS-03", - "TPM-05.4" + "12.6": [ + "NET-01", + "NET-04", + "SEA-01", + "TDA-02.1", + "TPM-04.2" ], - "CC1.5-POF3": [ - "GOV-01.1", - "HRS-01" + "13.5": [ + "NET-01.1", + "NET-03", + "NET-14.7" ], - "CC1.5-POF4": [ - "GOV-01.1", - "HRS-01" + "13.4": [ + "NET-04", + "NET-04.1" ], - "CC1.5-POF5": [ - "GOV-01.1", - "GOV-05", - "HRS-01", - "HRS-07" + "13.3": [ + "NET-08" ], - "CC2.2-POF4": [ - "GOV-01.1", - "GOV-06", - "GOV-07" + "13.8": [ + "NET-08" ], - "CC2.2-POF12": [ - "GOV-01.1", - "SAT-01", - "SAT-02", - "SAT-03" + "4.9": [ + "NET-10" ], - "CC2.3-POF3": [ - "GOV-01.1", - "GOV-01.2" + "9.5": [ + "NET-10.3", + "NET-20.4" ], - "CC3.1-POF11": [ - "GOV-01.1", - "GOV-01.2", + "12.7": [ + "NET-14", + "NET-14.1", + "NET-14.2", + "NET-14.3" + ], + "3.13": [ + "NET-17" + ], + "9.2": [ + "NET-18" + ], + "9.3": [ + "NET-18" + ], + "13.10": [ + "NET-18", + "NET-18.1", + "WEB-03" + ], + "15.7": [ + "PRM-05", "PRM-06", - "OPS-03" + "PRM-07", + "TDA-01", + "TDA-01.1", + "TPM-10" ], - "CC3.4-POF3": [ - "GOV-01.1", + "16.6": [ "RSK-01", - "RSK-03", - "RSK-04" + "RSK-01.1", + "RSK-02", + "RSK-02.1" ], - "CC4.2": [ - "GOV-01.1", - "GOV-01.2", - "CPL-01.1", - "IAO-04", - "IAO-05", + "18.3": [ "RSK-06", - "TDA-15", - "TPM-09", - "VPM-02", - "VPM-04" - ], - "CC4.2-POF1": [ - "GOV-01.1", - "GOV-01.2", - "GOV-05", - "GOV-15.3", - "CPL-01.1", - "CPL-02" + "VPM-04", + "VPM-05" ], - "CC4.2-POF2": [ - "GOV-01.1", - "GOV-01.2", - "CPL-01.1", - "CPL-02" + "15.2": [ + "RSK-09", + "TPM-01" ], - "CC2.2-POF2": [ - "GOV-01.2" + "15.5": [ + "RSK-09.1", + "TPM-04", + "TPM-04.1" ], - "CC3.1-POF10": [ - "GOV-01.2", - "GOV-06", - "GOV-17", - "PRM-06", - "OPS-03" + "16.10": [ + "SEA-01", + "SEA-01.1", + "SEA-02", + "TDA-05", + "TDA-06", + "WEB-07", + "WEB-08" ], - "CC1.4-POF1": [ - "GOV-02", - "HRS-01" + "14.1": [ + "SAT-01" ], - "CC2.2-POF1": [ - "GOV-02", - "GOV-09", - "OPS-03" + "14.3": [ + "SAT-02", + "SAT-03" ], - "CC2.2-POF7": [ - "GOV-02", - "GOV-03", - "GOV-09" + "14.7": [ + "SAT-02", + "SAT-03" ], - "CC5.3": [ - "GOV-02", - "GOV-03", - "HRS-03.2", - "HRS-10", - "OPS-01.1" + "14.8": [ + "SAT-02", + "SAT-03" ], - "CC5.3-POF1": [ - "GOV-02", - "GOV-14" + "14.2": [ + "SAT-02.2" ], - "CC7.2-POF1": [ - "GOV-02", - "MON-01", - "MON-01.2", - "MON-02", - "OPS-01.1" + "14.4": [ + "SAT-03" ], - "P1.1-POF5": [ - "GOV-02", - "PRI-02" + "14.9": [ + "SAT-03", + "SAT-03.1", + "SAT-03.7" ], - "CC5.3-POF6": [ - "GOV-03", - "GOV-05" + "16.9": [ + "SAT-03", + "SAT-03.8" ], - "CC1.3": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "HRS-03", - "HRS-03.2", - "PRM-06" + "14.6": [ + "SAT-03.2" ], - "CC5.3-POF2": [ - "GOV-04", - "GOV-04.1", - "HRS-03" + "14.5": [ + "SAT-03.3" ], - "CC1.3-POF2": [ - "GOV-04.1", - "GOV-04.2" + "16.4": [ + "TDA-02", + "TDA-02.1", + "TDA-02.5", + "TDA-04.2" ], - "CC1.3-POF4": [ - "GOV-04.1", - "GOV-04.2", - "HRS-03", - "TPM-05.4" + "16.1": [ + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-06.3", + "TDA-09.6", + "TDA-16", + "WEB-07", + "WEB-08" ], - "CC1.3-POF5": [ - "GOV-04.1", - "GOV-04.2", - "HRS-03", - "TPM-05.4" + "16.2": [ + "TDA-04.2", + "TDA-06.2", + "TDA-06.5", + "TDA-09", + "TDA-09.1", + "TDA-15", + "THR-06" ], - "CC1.3-POF6": [ - "GOV-04.1", - "GOV-04.2", - "HRS-01", - "PRI-01", - "TPM-04.3" + "16.11": [ + "TDA-06", + "TDA-06.3", + "TDA-12", + "TDA-14", + "TDA-14.1" ], - "CC1.5-POF1": [ - "GOV-04.1", - "GOV-04.2", - "HRS-03" + "16.14": [ + "TDA-06.2" ], - "CC1.1-POF3": [ - "GOV-05", - "CPL-02", - "CPL-03", - "HRS-01" + "16.12": [ + "TDA-06.5", + "TDA-09", + "TDA-09.2", + "TDA-09.3" ], - "CC1.5": [ - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "CPL-01", - "CPL-01.1", - "HRS-03.2", - "HRS-06", - "HRS-06.1", - "HRS-07", - "HRS-07.1", - "HRS-08", - "HRS-09", - "HRS-09.1", - "HRS-09.2", - "HRS-09.3" + "16.8": [ + "TDA-07", + "TDA-08" ], - "CC1.5-POF2": [ - "GOV-05", - "HRS-01" + "16.13": [ + "TDA-09.5" ], - "CC2.1-POF4": [ - "GOV-05", - "GOV-15", - "DCH-22", - "OPS-03" + "15.1": [ + "TPM-01.1" ], - "CC2.2": [ - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "GOV-09", - "CPL-01", - "CPL-02", - "HRS-03", - "PRM-01", - "PRM-05", - "SEA-01", - "SEA-02.1", - "OPS-01", - "OPS-01.1" + "15.3": [ + "TPM-02" ], - "CC4.1": [ - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "CPL-03", - "CPL-03.2", - "CPL-04", - "IAO-01", - "IAO-02", - "IAO-02.1", - "IAO-02.2", - "IAO-03.1", - "IAO-04", - "IAO-06", - "PRM-03", - "PRM-04", - "PRM-05", - "PRM-06", - "RSK-01", - "RSK-09", - "SEA-02" + "15.6": [ + "TPM-08" ], - "CC4.1-POF2": [ - "GOV-05", - "CPL-02.1" + "7.1": [ + "VPM-01" ], - "CC2.3": [ - "GOV-06", - "GOV-07", - "CPL-01", - "CPL-02", - "IRO-10", - "IRO-14", - "PRI-14" + "7.2": [ + "VPM-02" ], - "CC2.2-POF10": [ - "GOV-08", - "IRO-01", - "IRO-02", - "IRO-02.4", - "IRO-04" + "7.7": [ + "VPM-02", + "VPM-04" ], - "CC3.1-POF1": [ - "GOV-08", - "GOV-09", - "RSK-01.1", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5" - ], - "CC3.1-POF3": [ - "GOV-08", - "RSK-01.1" - ], - "CC3.1-POF15": [ - "GOV-08", - "GOV-09", - "PRM-06", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "OPS-03" + "7.3": [ + "VPM-05" ], - "CC5.1-POF2": [ - "GOV-08", - "GOV-15" + "7.4": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" ], - "CC2.1-POF1": [ - "GOV-09", - "GOV-15", - "OPS-03" + "7.5": [ + "VPM-06", + "VPM-06.7" ], - "CC3.1": [ - "GOV-09", - "PRM-01", - "PRM-04", - "PRM-06", - "RSK-01", - "RSK-09", - "SEA-02" + "7.6": [ + "VPM-06", + "VPM-06.6" ], - "CC3.1-POF8": [ - "GOV-09", - "CPL-01", - "PRM-06", - "OPS-03" + "18.1": [ + "VPM-07" ], - "CC3.1-POF9": [ - "GOV-09", - "CPL-01", - "PRM-06", - "OPS-03" + "18.2": [ + "VPM-07" ], - "CC2.1-POF2": [ - "GOV-15", - "AST-04", - "OPS-03" + "18.5": [ + "VPM-07" + ] + }, + "general-cis-csc-8-1-ig1": { + "2.1": [ + "AST-01", + "AST-02", + "AST-02.9" ], - "CC2.1-POF3": [ - "GOV-15", - "OPS-03" + "2.2": [ + "AST-01", + "AST-02", + "AST-02.7", + "RSK-06.2", + "TDA-17" ], - "CC3.1-POF5": [ - "GOV-15", - "CPL-01" + "1.1": [ + "AST-02" ], - "CC5.1": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "HRS-11", - "PRM-06", - "RSK-01", - "SEA-01", - "SEA-01.1", - "SEA-02", - "OPS-01.1", - "OPS-02" + "1.2": [ + "AST-02.2", + "NET-08.3" ], - "CC5.1-POF1": [ - "GOV-15" + "2.3": [ + "AST-02.2", + "CFG-02.8", + "CFG-03.3", + "CFG-05.1", + "CFG-06.1", + "MON-16.3", + "END-03.1", + "END-06.2", + "IRO-02" ], - "CC5.1-POF3": [ - "GOV-15" + "3.5": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21", + "PRI-05" ], - "CC5.1-POF4": [ - "GOV-15" + "11.1": [ + "BCD-01" ], - "CC5.1-POF5": [ - "GOV-15", - "PRM-01.2" + "11.2": [ + "BCD-11" ], - "CC5.1-POF6": [ - "GOV-15", - "HRS-11" + "11.3": [ + "BCD-11.1", + "BCD-11.4", + "BCD-12", + "BCD-13", + "DCH-01" ], - "CC3.1-POF6": [ - "GOV-16", - "RSK-01.1", - "RSK-05" + "11.4": [ + "BCD-14" ], - "CC3.2-POF3": [ - "GOV-17", - "RSK-01", - "RSK-04" + "4.1": [ + "CFG-01", + "CFG-02", + "CFG-02.1" ], - "CC1.4-POF2": [ - "AAT-01", - "AAT-13.1", - "HRS-01", - "HRS-02.2", - "HRS-03.2", - "HRS-13", - "TPM-01", - "TPM-08" + "4.2": [ + "CFG-01", + "CFG-02" ], - "CC1.4-POF3": [ - "AAT-11", - "AAT-13", - "HRS-01", - "HRS-02.2", - "HRS-13", - "SAT-01", - "SAT-03.7", - "TPM-01", - "TPM-08" + "4.3": [ + "CFG-02", + "IAC-24" ], - "CC5.3-POF5": [ - "AAT-13.1", - "HRS-03.2" + "4.4": [ + "CFG-02", + "END-05", + "WEB-03" ], - "CC2.1-POF6": [ - "AST-01", - "AST-02", - "AST-02.10", - "DCH-06.2", - "HRS-03", - "TPM-01.1" + "4.5": [ + "CFG-02", + "END-05" ], - "CC2.1-POF9": [ - "AST-01", - "AST-02", - "AST-02.8", - "AST-02.10", - "BCD-02.4", - "CLD-09", - "DCH-19", - "DCH-24", - "SEA-14.2", - "TPM-04.4" + "4.6": [ + "CFG-02", + "CFG-03", + "CRY-06", + "MNT-05", + "NET-04", + "TDA-02.6" ], - "CC3.3-POF1": [ - "AST-01", - "HRS-01", - "THR-01", - "THR-04" + "4.7": [ + "CFG-02", + "IAC-01", + "IAC-10.8" ], - "CC6.1-POF1": [ - "AST-01", - "AST-02", - "AST-04.1", - "DCH-02" + "10.3": [ + "CFG-02", + "END-02" ], - "CC6.1-POF9": [ - "AST-01", - "IAC-01", - "IAO-01", - "IAO-07" + "9.1": [ + "CFG-04.2", + "CFG-05.2" ], - "CC5.2-POF1": [ - "AST-01.1" + "8.2": [ + "MON-01", + "MON-01.4", + "MON-02", + "MON-02.7", + "MON-03" ], - "CC7.1-POF4": [ - "AST-02.2", - "MON-01.7", - "END-06" + "8.1": [ + "MON-01.8", + "MON-02" ], - "CC2.1-POF5": [ - "AST-02.8", - "AST-04" + "8.3": [ + "MON-02", + "MON-04" ], - "C1.1-POF1": [ - "AST-04", - "DCH-06.2" + "3.6": [ + "CRY-01", + "CRY-05" ], - "CC2.1": [ - "AST-04", + "3.1": [ "DCH-01", "DCH-01.1", + "DCH-01.2", + "DCH-01.4", "DCH-02", - "DCH-22", - "OPS-03" - ], - "CC2.1-POF7": [ - "AST-04.1", - "DCH-02", - "DCH-11" - ], - "CC2.2-POF11": [ - "AST-04.1", - "AST-04.2", - "CPL-01.2", - "IAO-01.1", - "IAO-03" - ], - "CC5.2-POF2": [ - "AST-04.2", - "CPL-01.2" - ], - "CC6.7-POF3": [ - "AST-05", - "CRY-01", - "CRY-01.1", - "CRY-05", - "CRY-05.1", - "DCH-12", - "DCH-13.2" - ], - "C1.2-POF2": [ - "AST-09", + "DCH-03", + "DCH-03.1", "DCH-08", "DCH-09", - "DCH-21", - "PRI-05" + "DCH-18" ], - "CC6.5": [ - "AST-09", + "3.3": [ "DCH-01", - "DCH-08", - "DCH-09", - "DCH-21", - "PRI-05" + "DCH-01.4", + "DCH-03", + "DCH-03.1", + "DCH-13.1", + "DCH-14", + "DCH-14.2", + "DCH-14.3", + "IAC-08", + "NET-04" ], - "CC6.5-POF2": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-21", - "PRI-05" + "3.2": [ + "DCH-06.2", + "DCH-06.3" ], - "P4.3-POF2": [ - "AST-09", - "DCH-08", - "DCH-21", - "PRI-05" + "3.4": [ + "DCH-18" ], - "P4.3-POF3": [ - "AST-09", - "DCH-08", - "DCH-21", - "PRI-05" + "10.1": [ + "END-04" ], - "CC6.4-POF3": [ - "AST-10", - "HRS-09.1" + "10.2": [ + "END-04.1" ], - "A1.2": [ - "BCD-01", - "BCD-08", - "BCD-08.1", - "BCD-08.2", - "BCD-09", - "BCD-09.1", - "BCD-09.2", - "BCD-09.3", - "BCD-10", - "BCD-10.1", - "BCD-11", - "BCD-11.1", - "BCD-11.2", - "BCD-11.3", - "BCD-11.4", - "BCD-12", - "BCD-12.1", - "BCD-12.2", - "PES-01", - "PES-07", - "PES-07.1", - "PES-07.2", - "PES-07.3", - "PES-07.4", - "PES-07.5", - "PES-08", - "PES-08.1", - "PES-08.2", - "PES-09", - "PES-09.1", - "PES-10", - "PES-11", - "PES-12", - "PES-13", - "PES-15", - "RSK-03", - "RSK-04" + "6.3": [ + "IAC-06" ], - "A1.2-POF1": [ - "BCD-01", - "PES-01", - "RSK-01", - "RSK-03" + "6.4": [ + "IAC-06" ], - "A1.2-POF2": [ - "BCD-01", - "PES-01", - "PES-09", - "PES-09.1" + "6.5": [ + "IAC-06.1" ], - "A1.2-POF3": [ - "BCD-01", - "PES-01" + "6.1": [ + "IAC-07" ], - "A1.2-POF4": [ - "BCD-01", - "PES-01", - "PES-09", - "PES-09.1" + "6.2": [ + "IAC-07" ], - "A1.2-POF5": [ - "BCD-01", - "IRO-01", - "IRO-02", - "PES-01" + "5.2": [ + "IAC-10", + "IAC-10.1" ], - "A1.2-POF6": [ - "BCD-01", - "PES-01" + "5.3": [ + "IAC-15.3" ], - "A1.2-POF10": [ - "BCD-01", - "BCD-09" + "5.1": [ + "IAC-16", + "IAC-16.1" ], - "A1.2-POF11": [ - "BCD-01", - "RSK-01.1", - "SEA-01.2", - "THR-09", - "THR-10" + "5.4": [ + "IAC-16", + "IAC-21", + "IAC-21.2" ], - "CC7.4-POF5": [ - "BCD-01", - "IRO-01", + "17.1": [ "IRO-02", - "IRO-04" + "IRO-04", + "IRO-07" ], - "CC7.5": [ - "BCD-01", - "BCD-02", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3", - "BCD-04", - "BCD-05", - "BCD-06", - "BCD-11", - "BCD-11.1", - "BCD-12", - "BCD-13" + "17.3": [ + "IRO-02" ], - "CC7.5-POF1": [ - "BCD-01", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3", - "BCD-12" + "17.2": [ + "IRO-09", + "IRO-10", + "IRO-10.2", + "IRO-10.3", + "IRO-10.4" ], - "CC7.5-POF2": [ - "BCD-01", - "BCD-01.6", - "IRO-10" + "12.1": [ + "NET-01", + "VPM-04", + "VPM-04.1", + "VPM-05" ], - "CC7.5-POF4": [ - "BCD-01", - "BCD-06" + "9.2": [ + "NET-18" ], - "CC7.5-POF5": [ - "BCD-01", - "BCD-06" + "14.1": [ + "SAT-01" ], - "CC8.1-POF15": [ - "BCD-01", - "SEA-01", - "SEA-01.2" + "14.3": [ + "SAT-02", + "SAT-03" ], - "CC9.1": [ - "BCD-01", - "BCD-07", - "RSK-01", - "RSK-03", - "RSK-03.1", - "TPM-01", - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04.4", - "TPM-05", - "TPM-06", - "TPM-07", - "TPM-08", - "TPM-09", - "TPM-10", - "THR-01", - "THR-09" + "14.7": [ + "SAT-02", + "SAT-03" ], - "CC9.1-POF1": [ - "BCD-01", - "RSK-06.2", - "RSK-08" + "14.8": [ + "SAT-02", + "SAT-03" ], - "CC9.1-POF2": [ - "BCD-01", - "RSK-06.2", - "RSK-08" + "14.2": [ + "SAT-02.2" ], - "A1.3": [ - "BCD-03.1", - "BCD-04" + "14.4": [ + "SAT-03" ], - "A1.3-POF1": [ - "BCD-04" + "14.6": [ + "SAT-03.2" ], - "A1.3-POF2": [ - "BCD-04", - "BCD-11.1", - "BCD-11.5" + "14.5": [ + "SAT-03.3" ], - "CC7.5-POF6": [ - "BCD-04" + "15.1": [ + "TPM-01.1" ], - "CC7.4-POF10": [ - "BCD-05", - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-13" + "7.1": [ + "VPM-01" ], - "CC7.5-POF3": [ - "BCD-05" + "7.2": [ + "VPM-02" ], - "A1.2-POF9": [ - "BCD-08", - "BCD-11.2", - "BCD-11.6", - "PES-01" + "7.3": [ + "VPM-05" ], - "A1.2-POF7": [ - "BCD-11", - "DCH-01", - "DCH-01.2", - "PES-01" + "7.4": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" + ] + }, + "general-cis-csc-8-1-ig2": { + "2.1": [ + "AST-01", + "AST-02", + "AST-02.9" ], - "A1.2-POF8": [ - "BCD-11" + "2.2": [ + "AST-01", + "AST-02", + "AST-02.7", + "RSK-06.2", + "TDA-17" ], - "A1.1": [ - "CAP-01", - "CAP-02", - "CAP-03" + "1.1": [ + "AST-02" ], - "A1.1-POF1": [ - "CAP-01", - "CAP-04" + "2.4": [ + "AST-02", + "AST-02.2", + "AST-02.9", + "CFG-06.1", + "END-06.2" ], - "A1.1-POF3": [ - "CAP-01" + "6.6": [ + "AST-02", + "IAC-01", + "IAC-01.2" ], - "A1.1-POF2": [ - "CAP-03" + "1.2": [ + "AST-02.2", + "NET-08.3" ], - "CC2.2-POF13": [ - "CHG-01", - "CHG-02", - "CHG-05", - "SAT-03", - "SAT-03.2" + "1.3": [ + "AST-02.2", + "AST-02.3" ], - "CC3.4": [ - "CHG-01", - "CHG-02", - "CHG-02.2", - "CHG-02.3", - "CHG-03", - "PRM-01", - "PRM-06", - "TPM-04.1", - "TPM-08", - "TPM-10" + "2.3": [ + "AST-02.2", + "CFG-02.8", + "CFG-03.3", + "CFG-05.1", + "CFG-06.1", + "MON-16.3", + "END-03.1", + "END-06.2", + "IRO-02" ], - "CC3.4-POF4": [ - "CHG-01", - "CHG-02", - "CHG-03", - "RSK-01", - "RSK-03", - "RSK-04" + "1.4": [ + "AST-02.6" ], - "CC6.8-POF3": [ - "CHG-01", - "CHG-02" + "16.5": [ + "AST-03.2", + "TDA-06", + "TDA-06.3", + "TDA-11", + "TDA-14.1" ], - "CC8.1": [ - "CHG-01", - "CHG-02", - "CHG-02.2", - "CHG-05", - "CFG-02", - "CFG-02.1", - "CFG-02.2", - "PRM-07" + "3.8": [ + "AST-04", + "DCH-14.3" ], - "CC8.1-POF1": [ - "CHG-01", - "CHG-02", - "PRM-07" + "12.4": [ + "AST-04" ], - "CC8.1-POF2": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-04" + "3.5": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21", + "PRI-05" ], - "CC8.1-POF3": [ - "CHG-01", - "CHG-02", - "CHG-02.3", - "CHG-03" + "4.11": [ + "AST-16", + "MDM-01", + "MDM-05" ], - "CC8.1-POF4": [ - "CHG-01", - "CHG-02", - "CHG-02.2" + "11.1": [ + "BCD-01" ], - "CC8.1-POF5": [ - "CHG-01", - "CHG-02", - "CHG-02.2" + "11.2": [ + "BCD-11" ], - "CC8.1-POF6": [ - "CHG-01", - "CHG-02", + "11.3": [ + "BCD-11.1", + "BCD-11.4", + "BCD-12", + "BCD-13", + "DCH-01" + ], + "11.5": [ + "BCD-11.1", + "BCD-11.5" + ], + "11.4": [ + "BCD-14" + ], + "4.1": [ "CFG-01", "CFG-02", - "CFG-02.2" + "CFG-02.1" ], - "CC8.1-POF7": [ - "CHG-01", - "CHG-02", - "CHG-02.2" + "4.2": [ + "CFG-01", + "CFG-02" ], - "CC8.1-POF8": [ - "CHG-01", - "CHG-02" + "4.3": [ + "CFG-02", + "IAC-24" ], - "CC8.1-POF9": [ - "CHG-01", - "CHG-02", - "CHG-04", - "CHG-04.4" + "4.4": [ + "CFG-02", + "END-05", + "WEB-03" ], - "CC8.1-POF10": [ - "CHG-01", - "CHG-02", - "CHG-02.2", - "CHG-03", - "CHG-04.1" + "4.5": [ + "CFG-02", + "END-05" ], - "CC8.1-POF11": [ - "CHG-01", - "CHG-02", - "CHG-04.1", - "CFG-02.2" + "4.6": [ + "CFG-02", + "CFG-03", + "CRY-06", + "MNT-05", + "NET-04", + "TDA-02.6" ], - "CC8.1-POF13": [ - "CHG-01", - "CHG-02", - "CHG-02.2", - "IAC-15.9" + "4.7": [ + "CFG-02", + "IAC-01", + "IAC-10.8" ], - "CC8.1-POF14": [ - "CHG-01", - "CHG-02", - "VPM-01", - "VPM-05" + "4.8": [ + "CFG-02", + "CFG-03" ], - "CC8.1-POF16": [ - "CHG-01", - "CHG-02.2", - "DCH-01", - "VPM-01", - "VPM-05" + "4.10": [ + "CFG-02", + "IAC-22" ], - "CC6.8": [ - "CHG-02.1", - "MON-01.7", + "10.3": [ + "CFG-02", + "END-02" + ], + "10.4": [ + "CFG-02", + "END-02", "END-04", - "END-06", - "END-07", - "NET-03", - "NET-08" + "END-04.7" ], - "CC6.1-POF5": [ - "CLD-01", - "CLD-11", - "NET-01", - "NET-01.1", - "NET-03", - "NET-14.3" + "10.5": [ + "CFG-02", + "END-02" ], - "CC3.1-POF14": [ - "CPL-01", - "PRM-06", - "OPS-03" + "16.7": [ + "CFG-02", + "CFG-02.5", + "TDA-06.5", + "TDA-12", + "WEB-07" ], - "CC1.1-POF4": [ - "CPL-01.1", - "HRS-07", - "RSK-06" + "2.5": [ + "CFG-03.2", + "CFG-03.3" ], - "CC4.2-POF3": [ - "CPL-01.1", - "CPL-02", - "IAO-05", - "RSK-04.1" + "2.6": [ + "CFG-03.3" ], - "CC4.1-POF1": [ - "CPL-02.1", - "TDA-09" + "9.1": [ + "CFG-04.2", + "CFG-05.2" ], - "CC4.1-POF3": [ - "CPL-02.1" + "9.4": [ + "CFG-04.2", + "CFG-05.2", + "HRS-05.1", + "HRS-05.4" ], - "CC4.1-POF4": [ - "CPL-02.1", - "IAO-02.2" + "8.2": [ + "MON-01", + "MON-01.4", + "MON-02", + "MON-02.7", + "MON-03" ], - "CC4.1-POF5": [ - "CPL-02.1" + "13.6": [ + "MON-01", + "MON-01.13", + "MON-02.1", + "MON-02.3" ], - "CC4.1-POF6": [ - "CPL-02.1" + "8.1": [ + "MON-01.8", + "MON-02" ], - "CC4.1-POF7": [ - "CPL-02.1" + "8.3": [ + "MON-02", + "MON-04" ], - "CC4.1-POF8": [ - "CPL-02.1", - "IAO-01", - "IAO-02" + "8.4": [ + "MON-02", + "MON-07.1" ], - "CC7.2-POF4": [ - "CPL-03.2", - "MON-01.8" + "8.5": [ + "MON-02", + "MON-03" ], - "CC7.1": [ - "CFG-01", - "CFG-02", - "MON-01.7", - "END-06.1", - "VPM-06" + "8.6": [ + "MON-02", + "MON-02.3" ], - "CC7.1-POF1": [ - "CFG-01", - "CFG-02", - "CFG-02.2" + "8.7": [ + "MON-02", + "MON-02.3" ], - "CC8.1-POF12": [ - "CFG-01", - "CFG-02" + "8.8": [ + "MON-02", + "MON-03.3" ], - "CC6.1-POF7": [ - "CFG-02", - "CFG-03", - "IAC-01", - "IAC-21" + "8.9": [ + "MON-02" ], - "CC6.7-POF1": [ - "CFG-02", - "CFG-03", - "DCH-17", - "NET-03.5", - "NET-04.1", - "NET-12.2", - "NET-17" + "13.1": [ + "MON-02" ], - "CC7.2": [ - "CFG-02.2", - "MON-01", - "MON-01.1", - "MON-01.2", - "MON-01.3", - "MON-01.4", - "MON-01.5", - "MON-01.6", - "MON-01.8", - "MON-02", - "MON-02.1", - "MON-06", - "MON-16", - "NET-08.2", - "RSK-03", - "OPS-02" + "8.11": [ + "MON-02.2" ], - "CC5.2-POF3": [ - "CFG-03", - "IAC-08", - "IAC-21" + "8.10": [ + "MON-04", + "MON-10" ], - "CC6.7": [ - "CFG-04.2", - "CRY-03", + "3.6": [ + "CRY-01", + "CRY-05" + ], + "3.9": [ + "CRY-01", "CRY-05", - "DCH-01", - "DCH-10", - "DCH-12", - "DCH-13", - "DCH-13.2", - "DCH-14", - "DCH-17", - "MDM-01", - "MDM-03", - "NET-13" + "CRY-05.1" ], - "CC6.8-POF1": [ - "CFG-05", - "CFG-05.2", - "END-03" + "3.10": [ + "CRY-01", + "CRY-03" ], - "CC6.8-POF2": [ - "CFG-05.1", - "END-03.1" + "3.11": [ + "CRY-01", + "CRY-05" ], - "CC7.2-POF2": [ - "MON-01.1", - "MON-01.4", - "MON-01.12", - "MON-16" - ], - "CC7.2-POF3": [ - "MON-01.1", - "MON-01.2", - "MON-16" - ], - "CC7.1-POF2": [ - "MON-01.7", - "END-06" - ], - "CC7.1-POF3": [ - "MON-01.7", - "END-06" - ], - "CC7.3": [ - "MON-02", - "MON-02.1", - "MON-06", - "END-06.2", - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-04.1", - "RSK-04", - "TPM-11" - ], - "PI1.4": [ - "MON-03", - "MON-08", - "PES-12.2", - "TDA-06" - ], - "PI1.5": [ - "MON-08", - "DCH-01", - "DCH-18", - "TDA-06" - ], - "C1.2": [ - "MON-10", - "DCH-21", - "PRI-05" - ], - "CC6.1": [ - "CRY-01", - "CRY-03", - "CRY-05", - "CRY-08", - "CRY-09", - "CRY-09.1", - "CRY-09.2", - "IAC-01", - "IAC-02", - "IAC-03", - "IAC-04", - "IAC-05", - "IAC-08", - "IAC-09", - "IAC-09.1", - "IAC-10", - "IAC-10.8", - "IAC-15", - "IAC-16", - "IAC-20", - "IAC-21", - "NET-01", - "NET-03", - "NET-03.1", - "NET-04", - "NET-05.1", - "NET-06", - "NET-06.1" - ], - "CC6.1-POF10": [ - "CRY-01", - "CRY-03", - "CRY-04", - "CRY-05", - "CRY-08", - "CRY-09", - "CRY-09.1", - "CRY-09.2" - ], - "CC6.1-POF11": [ - "CRY-01", - "CRY-08", - "CRY-09", - "CRY-09.1", - "CRY-09.2", - "CRY-09.3", - "CRY-09.4" - ], - "CC6.6-POF2": [ - "CRY-01", - "IAC-01", - "IAC-01.2", - "IAC-10.1", - "NET-01", - "NET-12", - "NET-13" - ], - "CC6.7-POF2": [ - "CRY-01", - "CRY-03", - "CRY-05", - "DCH-01" - ], - "C1.1": [ - "DCH-01", - "DCH-02", - "DCH-03" - ], - "C1.1-POF2": [ - "DCH-01", - "DCH-01.2" + "12.3": [ + "CRY-06", + "MNT-05.3", + "NET-01" ], - "CC8.1-POF17": [ + "3.1": [ "DCH-01", + "DCH-01.1", "DCH-01.2", - "PRI-01" - ], - "PI1.4-POF1": [ - "DCH-01", - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.4-POF2": [ - "DCH-01", - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.4-POF3": [ - "DCH-01", - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.4-POF4": [ - "DCH-01", - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.5-POF1": [ - "DCH-01", - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.5-POF2": [ - "DCH-01", - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.5-POF3": [ - "DCH-01", - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.5-POF4": [ - "DCH-01", - "PRM-06", - "OPS-03", - "TDA-06" - ], - "P6.0": [ - "DCH-03.1" - ], - "P6.1-POF2": [ - "DCH-03.1", - "PRI-01.7" - ], - "P6.1-POF3": [ - "DCH-03.1", - "PRI-01.7" - ], - "P6.1-POF4": [ + "DCH-01.4", + "DCH-02", + "DCH-03", "DCH-03.1", - "PRI-01.7" + "DCH-08", + "DCH-09", + "DCH-18" ], - "P6.4-POF1": [ + "3.3": [ + "DCH-01", + "DCH-01.4", + "DCH-03", "DCH-03.1", - "PRI-01.7" - ], - "P4.3": [ - "DCH-09.3", - "DCH-21", - "PRI-05" - ], - "C1.1-POF3": [ - "DCH-18", - "PRI-05" - ], - "C1.2-POF1": [ - "DCH-21", - "PRI-05" + "DCH-13.1", + "DCH-14", + "DCH-14.2", + "DCH-14.3", + "IAC-08", + "NET-04" ], - "CC2.1-POF8": [ - "DCH-22" + "3.7": [ + "DCH-02", + "DCH-02.1" ], - "P5.1": [ - "DCH-22.1", - "PRI-06", - "PRI-06.4" + "3.12": [ + "DCH-02.1", + "SEA-03.1" ], - "P5.2": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "PRI-06.4", - "PRI-12" + "3.2": [ + "DCH-06.2", + "DCH-06.3" ], - "CC6.7-POF4": [ - "END-01", - "MDM-01" + "3.4": [ + "DCH-18" ], - "CC6.8-POF4": [ + "10.1": [ "END-04" ], - "CC6.8-POF5": [ - "END-04.7" - ], - "CC1.4": [ - "HRS-01", - "PRM-02", - "PRM-03", - "SAT-01", - "SAT-03.7" - ], - "CC2.2-POF3": [ - "HRS-01", - "HRS-07.1", - "IRO-01", - "IRO-02" - ], - "CC2.3-POF4": [ - "HRS-01", - "HRS-07.1" - ], - "CC3.3-POF2": [ - "HRS-01", - "THR-01", - "THR-04" - ], - "CC3.3-POF3": [ - "HRS-01", - "THR-01", - "THR-04" - ], - "CC3.3-POF4": [ - "HRS-01", - "THR-01", - "THR-04" - ], - "CC3.3-POF5": [ - "HRS-01", - "THR-01", - "THR-04" - ], - "CC1.4-POF6": [ - "HRS-03", - "HRS-03.2" - ], - "CC2.2-POF5": [ - "HRS-03", - "TPM-05.4" - ], - "CC7.4-POF1": [ - "HRS-03", - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07" - ], - "CC1.4-POF5": [ - "HRS-04" - ], - "CC1.1-POF2": [ - "HRS-05.1" + "10.2": [ + "END-04.1" ], - "CC1.5-POF6": [ - "HRS-07" + "10.6": [ + "END-04.3" ], - "CC7.4-POF14": [ - "HRS-07" + "10.7": [ + "END-04.4" ], - "CC6.2-POF3": [ - "HRS-08", - "HRS-09", - "IAC-07", - "IAC-15.7", - "IAC-17" + "13.2": [ + "END-07" ], - "CC1.4-POF4": [ - "HRS-13", - "HRS-13.4" + "9.6": [ + "END-08", + "IRO-15", + "NET-03", + "NET-08" ], - "CC6.1-POF3": [ + "5.6": [ "IAC-01", + "IAC-01.2", + "IAC-02", + "IAC-09", + "IAC-15.1" + ], + "12.5": [ "IAC-01.2", "IAC-02", "IAC-03", "IAC-04" ], - "CC6.1-POF8": [ - "IAC-01", + "5.5": [ "IAC-02", - "IAC-04", - "IAC-05" - ], - "CC6.6": [ - "IAC-01", - "IAC-01.2", - "NET-01", - "NET-02", - "NET-03", - "NET-03.1", - "NET-04", - "NET-04.1", - "NET-08.1", - "NET-12", - "NET-12.1", - "NET-13", - "NET-14" - ], - "CC6.6-POF3": [ - "IAC-01", - "IAC-01.2", - "IAC-06", - "IAC-13", - "NET-01", - "NET-03", - "NET-04.1", - "NET-14" + "IAC-05", + "IAC-16.1" ], - "CC6.1-POF4": [ - "IAC-01.2", + "6.7": [ "IAC-02", - "IAC-03" - ], - "CC6.2": [ - "IAC-07", - "IAC-07.1", - "IAC-17" - ], - "CC6.2-POF1": [ - "IAC-07", - "IAC-07.1", - "IAC-28.1" - ], - "CC6.3-POF1": [ - "IAC-07", - "IAC-07.1", - "IAC-28.1" - ], - "CC6.3-POF2": [ - "IAC-07", - "IAC-07.1" - ], - "CC6.2-POF2": [ - "IAC-07.1", - "IAC-15.3", - "IAC-15.7", - "IAC-17" - ], - "CC6.1-POF12": [ - "IAC-08", - "IAC-20.1", - "IAC-21" + "IAC-13.1", + "IAC-13.2" ], - "CC6.1-POF13": [ - "IAC-08", - "IAC-20.1", - "IAC-21", - "PRI-01.6", - "PRI-05.1" + "6.3": [ + "IAC-06" ], - "CC6.3": [ - "IAC-08" + "6.4": [ + "IAC-06" ], - "CC6.3-POF3": [ - "IAC-08" + "6.5": [ + "IAC-06.1" ], - "CC6.3-POF4": [ - "IAC-17" + "6.1": [ + "IAC-07" ], - "CC7.3-POF1": [ - "IRO-01", - "IRO-02", - "IRO-04" + "6.2": [ + "IAC-07" ], - "CC7.4": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09", - "IRO-10", - "IRO-10.2", - "IRO-10.4", - "IRO-11.2", - "IRO-14", - "RSK-06" + "5.2": [ + "IAC-10", + "IAC-10.1" ], - "CC7.4-POF2": [ - "IRO-01", - "IRO-02", - "IRO-04" + "5.3": [ + "IAC-15.3" ], - "CC7.4-POF3": [ - "IRO-01", - "IRO-02", - "IRO-04" + "5.1": [ + "IAC-16", + "IAC-16.1" ], - "CC7.4-POF4": [ - "IRO-01", - "IRO-02", - "IRO-04" + "5.4": [ + "IAC-16", + "IAC-21", + "IAC-21.2" ], - "CC7.4-POF6": [ + "17.5": [ "IRO-01", "IRO-02", "IRO-04", - "IRO-09", - "IRO-10", - "IRO-10.2" - ], - "CC7.4-POF7": [ - "IRO-01", - "IRO-02", - "IRO-04" + "IRO-07" ], - "CC7.4-POF8": [ - "IRO-01", + "17.1": [ "IRO-02", "IRO-04", - "RSK-06", - "VPM-02" + "IRO-07" ], - "CC7.4-POF9": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-09", - "IRO-10" + "17.3": [ + "IRO-02" ], - "CC7.4-POF11": [ - "IRO-01", + "17.4": [ "IRO-02", "IRO-04", - "IRO-04.2" - ], - "CC7.4-POF12": [ - "IRO-01", - "IRO-02", - "IRO-04" + "IRO-07" ], - "CC7.4-POF13": [ - "IRO-01", + "17.6": [ "IRO-02", "IRO-04", - "IRO-10", - "IRO-10.2" - ], - "CC2.2-POF6": [ - "IRO-02", "IRO-07", - "IRO-09", - "IRO-10", - "IRO-10.2", - "IRO-11.2" - ], - "CC2.3-POF8": [ - "IRO-02", - "IRO-04", - "IRO-09", - "IRO-10" - ], - "CC7.3-POF3": [ - "IRO-02" - ], - "CC7.3-POF4": [ - "IRO-02", - "IRO-04.1" - ], - "CC7.3-POF5": [ - "IRO-02", - "IRO-04.1" - ], - "CC7.3-POF6": [ - "IRO-02", - "RSK-01.1" - ], - "CC7.3-POF7": [ - "IRO-02", - "IRO-02.4", - "IRO-10.2" - ], - "P6.3": [ - "IRO-04.1", - "IRO-10", - "IRO-12", - "PRI-14.1" - ], - "P6.6": [ - "IRO-04.1", - "TPM-11" - ], - "P6.6-POF2": [ - "IRO-04.1" + "IRO-09" ], - "P6.7": [ - "IRO-04.1", - "IRO-10" + "17.7": [ + "IRO-06" ], - "CC7.3-POF2": [ + "17.2": [ "IRO-09", - "IRO-10", - "IRO-10.2" - ], - "CC2.3-POF1": [ "IRO-10", "IRO-10.2", + "IRO-10.3", "IRO-10.4" ], - "CC2.3-POF12": [ - "IRO-10.2", - "IRO-11.2", - "SAT-03.2", - "TPM-01", - "TPM-05", - "TPM-05.1", - "TPM-05.2" + "16.3": [ + "IRO-13", + "TDA-09" ], - "CC2.3-POF2": [ - "IRO-11.2", - "OPS-03", + "17.8": [ + "IRO-13" + ], + "15.4": [ + "IAO-03.2", + "PRI-07.1", + "TPM-03.2", + "TPM-04", "TPM-05" ], - "CC6.1-POF2": [ - "IAO-01", - "IAO-02", + "12.1": [ + "NET-01", + "VPM-04", + "VPM-04.1", + "VPM-05" + ], + "12.2": [ + "NET-01", + "NET-02", "SEA-01", "SEA-02" ], - "CC2.3-POF9": [ - "IAO-03", - "TPM-01", - "TPM-05.4" - ], - "CC2.3-POF10": [ - "IAO-03", - "TDA-01", - "TPM-01", - "TPM-05" - ], - "CC2.3-POF11": [ - "IAO-03", - "TPM-05", - "TPM-05.4" - ], - "CC6.6-POF1": [ + "12.6": [ "NET-01", - "NET-03", "NET-04", - "NET-04.1" + "SEA-01", + "TDA-02.1", + "TPM-04.2" ], - "CC6.6-POF4": [ - "NET-01", - "NET-02", + "13.5": [ + "NET-01.1", "NET-03", - "NET-14.3" + "NET-14.7" ], - "CC6.1-POF6": [ + "13.4": [ "NET-04", - "NET-14.3" - ], - "CC6.4": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03" + "NET-04.1" ], - "CC6.4-POF1": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03" + "13.3": [ + "NET-08" ], - "CC6.4-POF2": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-06.6" + "4.9": [ + "NET-10" ], - "CC6.4-POF4": [ - "PES-03.3", - "PES-05" + "9.5": [ + "NET-10.3", + "NET-20.4" ], - "CC2.3-POF7": [ - "PRI-01", - "PRI-02", - "TPM-05" + "12.7": [ + "NET-14", + "NET-14.1", + "NET-14.2", + "NET-14.3" ], - "CC8.1-POF18": [ - "PRI-01", - "PRI-04", - "PRI-04.1", - "SEA-01" + "9.2": [ + "NET-18" ], - "P1.0": [ - "PRI-01" + "9.3": [ + "NET-18" ], - "P1.1": [ - "PRI-01.2", - "PRI-01.3", - "PRI-02" + "16.6": [ + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-02.1" ], - "P1.1-POF6": [ - "PRI-01.3" + "18.3": [ + "RSK-06", + "VPM-04", + "VPM-05" ], - "P4.2-POF2": [ - "PRI-01.6" + "15.2": [ + "RSK-09", + "TPM-01" ], - "P1.1-POF1": [ - "PRI-02", - "PRI-02.1" + "16.10": [ + "SEA-01", + "SEA-01.1", + "SEA-02", + "TDA-05", + "TDA-06", + "WEB-07", + "WEB-08" ], - "P1.1-POF2": [ - "PRI-02", - "PRI-02.1" + "14.1": [ + "SAT-01" ], - "P1.1-POF3": [ - "PRI-02", - "PRI-02.1" + "14.3": [ + "SAT-02", + "SAT-03" ], - "P1.1-POF4": [ - "PRI-02", - "PRI-02.1" + "14.7": [ + "SAT-02", + "SAT-03" ], - "P1.1-POF7": [ - "PRI-02" + "14.8": [ + "SAT-02", + "SAT-03" ], - "P6.7-POF1": [ - "PRI-02.1", - "PRI-04.1", - "PRM-06" + "14.2": [ + "SAT-02.2" ], - "P2.0": [ - "PRI-03" + "14.4": [ + "SAT-03" ], - "P2.1": [ - "PRI-03", - "PRI-03.2" + "14.9": [ + "SAT-03", + "SAT-03.1", + "SAT-03.7" ], - "P2.1-POF1": [ - "PRI-03" + "16.9": [ + "SAT-03", + "SAT-03.8" ], - "P2.1-POF2": [ - "PRI-03" + "14.6": [ + "SAT-03.2" ], - "P2.1-POF3": [ - "PRI-03" + "14.5": [ + "SAT-03.3" ], - "P2.1-POF5": [ - "PRI-03" + "16.4": [ + "TDA-02", + "TDA-02.1", + "TDA-02.5", + "TDA-04.2" ], - "P2.1-POF6": [ - "PRI-03" + "16.1": [ + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-06.3", + "TDA-09.6", + "TDA-16", + "WEB-07", + "WEB-08" ], - "P3.2": [ - "PRI-03", - "PRI-03.2" + "16.2": [ + "TDA-04.2", + "TDA-06.2", + "TDA-06.5", + "TDA-09", + "TDA-09.1", + "TDA-15", + "THR-06" ], - "P3.2-POF2": [ - "PRI-03" + "16.11": [ + "TDA-06", + "TDA-06.3", + "TDA-12", + "TDA-14", + "TDA-14.1" ], - "P3.2-POF1": [ - "PRI-03.1" + "16.8": [ + "TDA-07", + "TDA-08" ], - "P2.1-POF4": [ - "PRI-03.2" + "15.1": [ + "TPM-01.1" ], - "P3.0": [ - "PRI-04" + "15.3": [ + "TPM-02" ], - "P3.1": [ - "PRI-04", - "PRI-04.1" + "7.1": [ + "VPM-01" ], - "P3.1-POF1": [ - "PRI-04" + "7.2": [ + "VPM-02" ], - "P3.1-POF2": [ - "PRI-04" + "7.7": [ + "VPM-02", + "VPM-04" ], - "P3.1-POF3": [ - "PRI-04", - "PRI-04.2" + "7.3": [ + "VPM-05" ], - "P3.1-POF4": [ - "PRI-04", - "PRI-06.2" + "7.4": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" ], - "P4.0": [ - "PRI-05", - "PRI-05.4" + "7.5": [ + "VPM-06", + "VPM-06.7" ], - "P4.2": [ - "PRI-05" + "7.6": [ + "VPM-06", + "VPM-06.6" ], - "P4.2-POF1": [ - "PRI-05" + "18.1": [ + "VPM-07" ], - "P4.1": [ - "PRI-05.1", - "PRI-05.4" + "18.2": [ + "VPM-07" + ] + }, + "general-cis-csc-8-1-ig3": { + "2.1": [ + "AST-01", + "AST-02", + "AST-02.9" ], - "P4.1-POF1": [ - "PRI-05.4" + "2.2": [ + "AST-01", + "AST-02", + "AST-02.7", + "RSK-06.2", + "TDA-17" ], - "P5.0": [ - "PRI-06" + "1.1": [ + "AST-02" ], - "P5.1-POF1": [ - "PRI-06" + "2.4": [ + "AST-02", + "AST-02.2", + "AST-02.9", + "CFG-06.1", + "END-06.2" ], - "P5.1-POF2": [ - "PRI-06" + "6.6": [ + "AST-02", + "IAC-01", + "IAC-01.2" ], - "P5.1-POF3": [ - "PRI-06" + "1.2": [ + "AST-02.2", + "NET-08.3" ], - "P5.2-POF2": [ - "PRI-06.1", - "PRI-06.2", - "PRI-12" + "1.3": [ + "AST-02.2", + "AST-02.3" ], - "P5.2-POF3": [ - "PRI-06.2", - "PRI-06.4", - "PRI-07.4" + "1.5": [ + "AST-02.2", + "AST-02.6" ], - "P4.3-POF1": [ - "PRI-06.4", - "PRI-06.5" + "2.3": [ + "AST-02.2", + "CFG-02.8", + "CFG-03.3", + "CFG-05.1", + "CFG-06.1", + "MON-16.3", + "END-03.1", + "END-06.2", + "IRO-02" ], - "P5.1-POF4": [ - "PRI-06.4", - "PRI-07.4" + "13.9": [ + "AST-02.5" ], - "P5.1-POF5": [ - "PRI-06.4" + "1.4": [ + "AST-02.6" ], - "P5.2-POF1": [ - "PRI-06.4", - "PRI-07.4" + "16.5": [ + "AST-03.2", + "TDA-06", + "TDA-06.3", + "TDA-11", + "TDA-14.1" ], - "P5.2-POF4": [ - "PRI-06.4" + "3.8": [ + "AST-04", + "DCH-14.3" ], - "P6.7-POF2": [ - "PRI-06.4", - "PRI-06.6", - "PRI-06.7" + "12.4": [ + "AST-04" ], - "P8.1": [ - "PRI-06.4" + "3.5": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21", + "PRI-05" ], - "P8.1-POF1": [ - "PRI-06.4" + "4.11": [ + "AST-16", + "MDM-01", + "MDM-05" ], - "P8.1-POF2": [ - "PRI-06.4" + "11.1": [ + "BCD-01" ], - "P8.1-POF3": [ - "PRI-06.4" + "11.2": [ + "BCD-11" ], - "P6.1": [ - "PRI-07" + "11.3": [ + "BCD-11.1", + "BCD-11.4", + "BCD-12", + "BCD-13", + "DCH-01" ], - "P6.1-POF1": [ - "PRI-07", - "PRI-07.1" + "11.5": [ + "BCD-11.1", + "BCD-11.5" ], - "P6.4": [ - "PRI-07.1" + "11.4": [ + "BCD-14" ], - "P6.4-POF3": [ - "PRI-07.1", - "TPM-05", - "TPM-05.2" + "18.4": [ + "CHG-06" ], - "P8.0": [ - "PRI-08" + "4.1": [ + "CFG-01", + "CFG-02", + "CFG-02.1" ], - "P8.1-POF6": [ - "PRI-08" + "4.2": [ + "CFG-01", + "CFG-02" ], - "P7.0": [ - "PRI-10" + "4.3": [ + "CFG-02", + "IAC-24" ], - "P7.1": [ - "PRI-10" - ], - "P7.1-POF1": [ - "PRI-10" - ], - "P7.1-POF2": [ - "PRI-10" - ], - "P8.1-POF4": [ - "PRI-14" - ], - "P8.1-POF5": [ - "PRI-14" - ], - "P6.2": [ - "PRI-14.1" - ], - "P6.2-POF1": [ - "PRI-14.1" - ], - "P6.3-POF1": [ - "PRI-14.1" - ], - "P6.7-POF3": [ - "PRI-17", - "PRI-18" - ], - "CC3.1-POF4": [ - "PRM-01", - "PRM-03" - ], - "CC5.2": [ - "PRM-01", - "PRM-04", - "PRM-05", - "PRM-06", - "PRM-07", - "RSK-08", - "RSK-10", - "SEA-01", - "TDA-01", - "TDA-02" - ], - "PI1.1-POF1": [ - "PRM-05", - "PRM-06", - "TDA-01.1", - "TDA-02" - ], - "PI1.1-POF2": [ - "PRM-05", - "TDA-01.1", - "TDA-02" - ], - "PI1.1-POF3": [ - "PRM-05", - "TDA-01.1", - "TDA-02" - ], - "CC3.1-POF7": [ - "PRM-06", - "OPS-03" - ], - "CC3.1-POF12": [ - "PRM-06", - "OPS-03" - ], - "CC3.1-POF13": [ - "PRM-06", - "OPS-03" - ], - "CC3.1-POF16": [ - "PRM-06", - "RSK-01.1", - "RSK-04", - "OPS-03" - ], - "PI1.1": [ - "PRM-06", - "RSK-10", - "OPS-03", - "TDA-06", - "TDA-06.1" - ], - "PI1.3-POF1": [ - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.3-POF2": [ - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.3-POF3": [ - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.3-POF4": [ - "PRM-06", - "OPS-03", - "TDA-06" - ], - "PI1.3-POF5": [ - "PRM-06", - "OPS-03", - "TDA-06" - ], - "CC3.2-POF1": [ - "RSK-01", - "RSK-03", - "RSK-04" - ], - "CC3.2-POF5": [ - "RSK-01", - "RSK-06.1" - ], - "CC3.4-POF1": [ - "RSK-01", - "RSK-03", - "RSK-04" - ], - "CC3.4-POF2": [ - "RSK-01", - "RSK-03", - "RSK-04" - ], - "CC3.4-POF5": [ - "RSK-01", - "RSK-03", - "RSK-04", - "TPM-01", - "TPM-05.5", - "TPM-08", - "TPM-10" - ], - "CC3.2": [ - "RSK-01.1", - "RSK-01.3", - "RSK-02", - "RSK-03", - "RSK-08", - "RSK-09", - "RSK-10", - "SEA-01" - ], - "CC3.2-POF2": [ - "RSK-01.1", - "RSK-03", - "RSK-04" - ], - "CC3.2-POF8": [ - "RSK-01.1", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-04", - "RSK-05", - "RSK-09", - "TPM-02", - "TPM-04.1", - "TPM-05.6" - ], - "CC3.1-POF2": [ - "RSK-01.3", - "RSK-01.4", - "RSK-01.5" - ], - "CC3.2-POF4": [ - "RSK-02.1", - "RSK-05" - ], - "CC3.2-POF6": [ - "RSK-03", - "RSK-03.1", - "RSK-04", - "THR-01", - "THR-02", - "THR-03", - "THR-09", - "THR-10" - ], - "CC3.2-POF9": [ - "RSK-04", - "RSK-09.1", - "TPM-02", - "TPM-04.1", - "THR-10", - "VPM-01", - "VPM-01.1", - "VPM-03.1" - ], - "CC5.3-POF4": [ - "RSK-06", - "VPM-02" - ], - "CC3.2-POF7": [ - "RSK-09", - "RSK-09.1", - "TPM-03", - "THR-01", - "THR-02", - "THR-03", - "VPM-01", - "VPM-01.1", - "VPM-06" - ], - "CC9.2": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-04.1" - ], - "CC9.2-POF1": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-03", - "TPM-05", - "TPM-05.2" - ], - "CC9.2-POF2": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-03", - "TPM-04.1" - ], - "CC9.2-POF3": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-03", - "TPM-04.1" - ], - "CC9.2-POF4": [ - "RSK-09", - "TPM-01", - "TPM-03", - "TPM-05.4" - ], - "CC9.2-POF7": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-03", - "TPM-05.5", - "TPM-08" - ], - "CC9.2-POF8": [ - "RSK-09", - "TPM-01", - "TPM-03", - "TPM-04.1", - "TPM-05.7", - "TPM-08", - "TPM-09", - "TPM-10" - ], - "CC9.2-POF9": [ - "RSK-09", - "TPM-01", - "TPM-03", - "TPM-05", - "TPM-05.2", - "TPM-05.6", - "TPM-05.7" - ], - "CC9.2-POF10": [ - "RSK-09", - "TPM-01", - "TPM-03", - "TPM-05", - "TPM-05.2", - "TPM-05.6" - ], - "CC9.2-POF11": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-04.1", - "TPM-05.6" - ], - "CC9.2-POF12": [ - "RSK-09", - "TPM-01", - "TPM-03", - "TPM-05.4", - "TPM-05.5", - "TPM-05.6", - "TPM-08" - ], - "CC5.3-POF3": [ - "OPS-01.1", - "OPS-03" - ], - "CC2.3-POF6": [ - "OPS-03", - "TPM-05", - "TPM-05.4" - ], - "CC2.2-POF8": [ - "SAT-01", - "SAT-02", - "SAT-03.6" - ], - "CC1.4-POF7": [ - "SAT-02", - "SAT-03", - "SAT-03.7", - "SAT-03.8" - ], - "CC2.2-POF9": [ - "SAT-03.3", - "SAT-03.5", - "TPM-05.4", - "TPM-05.5", - "VPM-01.1" - ], - "CC5.2-POF4": [ - "TDA-01" - ], - "PI1.2": [ - "TDA-01", - "TDA-06" - ], - "PI1.3": [ - "TDA-01", - "TDA-06" - ], - "PI1.2-POF1": [ - "TDA-06", - "TDA-18" - ], - "PI1.2-POF2": [ - "TDA-06", - "TDA-18" - ], - "PI1.2-POF3": [ - "TDA-06", - "TDA-18" - ], - "CC1.1-POF5": [ - "TPM-01", - "TPM-03", - "TPM-05", - "TPM-05.4", - "TPM-06" - ], - "CC3.3": [ - "TPM-01", - "TPM-03.1", - "TPM-04", - "TPM-04.3", - "THR-01", - "THR-02", - "THR-04" - ], - "CC9.2-POF5": [ - "TPM-01", - "TPM-05" - ], - "CC9.2-POF6": [ - "TPM-01", - "TPM-05", - "TPM-08" - ], - "P6.4-POF2": [ - "TPM-03.2", - "TPM-05.7", - "TPM-09" - ], - "P6.5-POF1": [ - "TPM-03.2", - "TPM-05.7", - "TPM-09" - ], - "P6.5-POF2": [ - "TPM-03.2", - "TPM-05.7", - "TPM-09" - ], - "P6.6-POF1": [ - "TPM-03.2", - "TPM-05.7", - "TPM-09" - ], - "CC9.2-POF13": [ - "TPM-05.1", - "TPM-07", - "TPM-08", - "THR-01", - "THR-02", - "THR-03", - "VPM-01", - "VPM-01.1", - "VPM-06" - ], - "P6.5": [ - "TPM-11" - ], - "CC3.4-POF6": [ - "THR-01", - "THR-10", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-03.1", - "VPM-06" - ], - "CC7.1-POF5": [ - "VPM-06" - ] - }, - "general-apec-privacy-framework-2015": { - "1": [ - "PRI-01" - ], - "2": [ - "PRI-02" - ], - "3": [ - "PRI-04" - ], - "4": [ - "PRI-03.9" - ], - "5": [ - "PRI-03" - ], - "6": [ - "PRI-05.2" - ], - "7": [ - "PRI-01.6" - ], - "9": [ - "HRS-03", - "PRI-01", - "PRI-01.1" - ], - "2-1": [ - "PRI-01.11" - ], - "2-2": [ - "PRI-01.11" - ], - "2(a)": [ - "PRI-02" - ], - "2(b)": [ - "PRI-02" - ], - "2(c)": [ - "PRI-02" - ], - "2(d)": [ - "PRI-02" - ], - "2(e)": [ - "PRI-02", - "PRI-03" - ], - "4(a)": [ - "PRI-03" - ], - "4(b)": [ - "PRI-03.9" - ], - "4(c)": [ - "PRI-04.1" - ], - "8(c)": [ - "PRI-06", - "PRI-06.1" - ], - "8(a)": [ - "PRI-06.7" - ], - "8(b)": [ - "PRI-06.7" - ], - "8(b)(i)": [ - "PRI-06.7" - ], - "8(b)(ii)": [ - "PRI-06.7" - ], - "8(b)(iii)": [ - "PRI-06.7" - ], - "8(b)(iv)": [ - "PRI-06.7" - ] - }, - "general-bsi-200-1-1-0": { - "5": [ - "PRM-01", - "PRM-02" - ], - "6": [ - "HRS-01", - "HRS-01.1", - "HRS-02", - "HRS-03.1", - "SAT-01", - "SAT-01.1", - "SAT-02", - "SAT-03", - "SAT-03.6" - ], - "7": [ - "PRM-01", - "PRM-01.1" - ], - "9": [ - "CPL-01.3", - "CPL-01.4" - ], - "4.1.2": [ - "GOV-01", - "GOV-01.1", - "PRM-01.1", - "PRM-03" - ], - "4.1.3": [ - "GOV-01", - "GOV-14", - "GOV-15", - "IRO-01", - "PRM-01", - "PRM-02" - ], - "7.1": [ - "GOV-01" - ], - "8.1": [ - "GOV-01" - ], - "8.2": [ - "GOV-01" - ], - "8.3": [ - "GOV-01" - ], - "4.1.1": [ - "GOV-01.1", - "GOV-04" - ], - "4.3": [ - "GOV-01.1", - "GOV-01.2", - "GOV-05" - ], - "4.4": [ - "GOV-01.1", - "GOV-01.3" - ], - "7.4": [ - "GOV-01.1", - "GOV-01.3", - "CPL-01.1", - "CPL-02.1" - ], - "7.5": [ - "GOV-01.1", - "GOV-01.2", - "GOV-01.3" - ], - "8.4": [ - "GOV-01.1", - "GOV-01.2", - "GOV-01.3" - ], - "7.3": [ - "GOV-02", - "GOV-03" - ], - "4.1.6": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2" - ], - "7.2": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "HRS-03" - ], - "4.2": [ - "HRS-03.1", - "SAT-03.6", - "THR-03.1" - ], - "4.1.4": [ - "PRM-01", - "PRM-04", - "PRM-05", - "PRM-06" - ], - "4.1.5": [ - "PRM-01" - ] - }, - "general-cis-csc-8-1": { - "1.0": [ - "AST-01", - "AST-02" - ], - "2.0": [ - "AST-01", - "AST-02", - "CFG-01" - ], - "2.1": [ - "AST-01", - "AST-02", - "AST-02.9" - ], - "2.2": [ - "AST-01", - "AST-02", - "AST-02.7", - "RSK-06.2", - "TDA-17" - ], - "1.1": [ - "AST-02" - ], - "2.4": [ - "AST-02", - "AST-02.2", - "AST-02.9", - "CFG-06.1", - "END-06.2" - ], - "6.6": [ - "AST-02", - "IAC-01", - "IAC-01.2" - ], - "1.2": [ - "AST-02.2", - "NET-08.3" - ], - "1.3": [ - "AST-02.2", - "AST-02.3" - ], - "1.5": [ - "AST-02.2", - "AST-02.6" - ], - "2.3": [ - "AST-02.2", - "CFG-02.8", - "CFG-03.3", - "CFG-05.1", - "CFG-06.1", - "MON-16.3", - "END-03.1", - "END-06.2", - "IRO-02" - ], - "13.9": [ - "AST-02.5" - ], - "1.4": [ - "AST-02.6" - ], - "16.5": [ - "AST-03.2", - "TDA-06", - "TDA-06.3", - "TDA-11", - "TDA-14.1" - ], - "3.8": [ - "AST-04", - "DCH-14.3" - ], - "12.4": [ - "AST-04" - ], - "3.5": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-21", - "PRI-05" - ], - "4.11": [ - "AST-16", - "MDM-01", - "MDM-05" - ], - "11.0": [ - "BCD-01", - "DCH-01", - "END-02" - ], - "11.1": [ - "BCD-01" - ], - "11.2": [ - "BCD-11" - ], - "11.3": [ - "BCD-11.1", - "BCD-11.4", - "BCD-12", - "BCD-13", - "DCH-01" - ], - "11.5": [ - "BCD-11.1", - "BCD-11.5" - ], - "11.4": [ - "BCD-14" - ], - "18.4": [ - "CHG-06" - ], - "4.0": [ - "CFG-01", - "CFG-03" - ], - "4.1": [ - "CFG-01", - "CFG-02", - "CFG-02.1", - "IAC-22" - ], - "4.2": [ - "CFG-01", - "CFG-02" - ], - "4.3": [ - "CFG-02", - "IAC-24" - ], - "4.4": [ - "CFG-02", - "END-05", - "WEB-03" + "4.4": [ + "CFG-02", + "END-05", + "WEB-03" ], "4.5": [ "CFG-02", @@ -132556,6 +136650,10 @@ "CFG-02", "CFG-03" ], + "4.10": [ + "CFG-02", + "IAC-22" + ], "10.3": [ "CFG-02", "END-02" @@ -132590,14 +136688,6 @@ "MNT-04", "MNT-04.4" ], - "9.0": [ - "CFG-04.2", - "END-08", - "HRS-05.2", - "IRO-15", - "NET-18", - "SAT-02.2" - ], "9.1": [ "CFG-04.2", "CFG-05.2" @@ -132608,9 +136698,6 @@ "HRS-05.1", "HRS-05.4" ], - "8.0": [ - "MON-01" - ], "8.2": [ "MON-01", "MON-01.4", @@ -132618,9 +136705,6 @@ "MON-02.7", "MON-03" ], - "13.0": [ - "MON-01" - ], "13.6": [ "MON-01", "MON-01.13", @@ -132629,9 +136713,7 @@ ], "8.1": [ "MON-01.8", - "MON-02", - "MON-04", - "MON-10" + "MON-02" ], "13.11": [ "MON-01.13" @@ -132677,14 +136759,15 @@ "MON-02.3" ], "13.1": [ - "MON-02", - "NET-18", - "NET-18.1", - "WEB-03" + "MON-02" ], "8.11": [ "MON-02.2" ], + "8.10": [ + "MON-04", + "MON-10" + ], "3.6": [ "CRY-01", "CRY-05" @@ -132694,19 +136777,9 @@ "CRY-05", "CRY-05.1" ], - "3.1": [ + "3.10": [ "CRY-01", - "CRY-03", - "DCH-01", - "DCH-01.1", - "DCH-01.2", - "DCH-01.4", - "DCH-02", - "DCH-03", - "DCH-03.1", - "DCH-08", - "DCH-09", - "DCH-18" + "CRY-03" ], "3.11": [ "CRY-01", @@ -132717,8 +136790,17 @@ "MNT-05.3", "NET-01" ], - "3.0": [ - "DCH-01" + "3.1": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-03", + "DCH-03.1", + "DCH-08", + "DCH-09", + "DCH-18" ], "3.3": [ "DCH-01", @@ -132747,11 +136829,6 @@ "3.4": [ "DCH-18" ], - "10.0": [ - "END-01", - "END-02", - "END-04" - ], "10.1": [ "END-04" ], @@ -132781,10 +136858,6 @@ "END-08", "IRO-15" ], - "5.0": [ - "IAC-01", - "IAC-15.1" - ], "5.6": [ "IAC-01", "IAC-01.2", @@ -132792,11 +136865,6 @@ "IAC-09", "IAC-15.1" ], - "6.0": [ - "IAC-01", - "IAC-08", - "IAC-15.1" - ], "12.5": [ "IAC-01.2", "IAC-02", @@ -132850,10 +136918,6 @@ "12.8": [ "IAC-20.4" ], - "17.0": [ - "IRO-01", - "IRO-02" - ], "17.5": [ "IRO-01", "IRO-02", @@ -132911,9 +136975,6 @@ "4.12": [ "MDM-10" ], - "12.0": [ - "NET-01" - ], "12.1": [ "NET-01", "VPM-04", @@ -132970,6 +137031,11 @@ "9.3": [ "NET-18" ], + "13.10": [ + "NET-18", + "NET-18.1", + "WEB-03" + ], "15.7": [ "PRM-05", "PRM-06", @@ -132998,29 +137064,15 @@ "TPM-04", "TPM-04.1" ], - "16.0": [ - "SEA-01", - "TDA-01", - "TDA-06", - "WEB-07", - "WEB-08" - ], - "16.1": [ + "16.10": [ "SEA-01", "SEA-01.1", "SEA-02", - "TDA-02.3", "TDA-05", "TDA-06", - "TDA-06.3", - "TDA-09.6", - "TDA-16", "WEB-07", "WEB-08" ], - "14.0": [ - "SAT-01" - ], "14.1": [ "SAT-01" ], @@ -133063,6 +137115,16 @@ "TDA-02.5", "TDA-04.2" ], + "16.1": [ + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-06.3", + "TDA-09.6", + "TDA-16", + "WEB-07", + "WEB-08" + ], "16.2": [ "TDA-04.2", "TDA-06.2", @@ -133095,12 +137157,6 @@ "16.13": [ "TDA-09.5" ], - "15.0": [ - "TPM-01", - "TPM-05.4", - "TPM-05.5", - "TPM-08" - ], "15.1": [ "TPM-01.1" ], @@ -133110,17 +137166,9 @@ "15.6": [ "TPM-08" ], - "7.0": [ - "VPM-01", - "VPM-04" - ], "7.1": [ "VPM-01" ], - "18.0": [ - "VPM-01", - "VPM-07" - ], "7.2": [ "VPM-02" ], @@ -133155,5320 +137203,3794 @@ "VPM-07" ] }, - "general-cis-csc-8-1-ig1": { - "2.1": [ - "AST-01", - "AST-02", - "AST-02.9" + "general-cobit-2019": { + "EDM01.02": [ + "GOV-01" ], - "2.2": [ - "AST-01", - "AST-02", - "AST-02.7", - "RSK-06.2", - "TDA-17" + "APO01.09": [ + "GOV-01", + "GOV-02", + "OPS-01.1" ], - "1.1": [ - "AST-02" + "APO04.01": [ + "GOV-01", + "PRI-01", + "TDA-01" ], - "1.2": [ - "AST-02.2", - "NET-08.3" + "APO13.01": [ + "GOV-01" ], - "2.3": [ - "AST-02.2", - "CFG-02.8", - "CFG-03.3", - "CFG-05.1", - "CFG-06.1", - "MON-16.3", - "END-03.1", - "END-06.2", - "IRO-02" + "APO13.03": [ + "GOV-01" ], - "3.5": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-21", - "PRI-05" + "APO14.01": [ + "GOV-01.1", + "GOV-01.3", + "GOV-03", + "CHG-05", + "DCH-01" ], - "11.1": [ - "BCD-01" + "DSS06.01": [ + "GOV-01.1", + "GOV-05" ], - "11.2": [ - "BCD-11" + "MEA01.04": [ + "GOV-01.1" ], - "11.3": [ - "BCD-11.1", - "BCD-11.4", - "BCD-12", - "BCD-13", - "DCH-01" + "MEA03.02": [ + "GOV-01.1", + "GOV-03" ], - "11.4": [ - "BCD-14" + "MEA04.03": [ + "GOV-01.1" ], - "4.1": [ - "CFG-01", - "CFG-02", - "CFG-02.1" + "BAI01.06": [ + "GOV-01.2", + "PRM-04" ], - "4.2": [ - "CFG-01", - "CFG-02" + "DSS06.04": [ + "GOV-02.1", + "IAO-04", + "TDA-15", + "VPM-02", + "VPM-04" ], - "4.3": [ - "CFG-02", - "IAC-24" + "EDM01.01": [ + "GOV-03" ], - "4.4": [ - "CFG-02", - "END-05", - "WEB-03" + "EDM01.03": [ + "GOV-03", + "GOV-05" ], - "4.5": [ - "CFG-02", - "END-05" + "EDM05.01": [ + "GOV-03", + "GOV-05", + "GOV-08", + "AST-01.2", + "AST-02.9", + "AST-03.1", + "CHG-05" ], - "4.6": [ - "CFG-02", - "CFG-03", - "CRY-06", - "MNT-05", - "NET-04", - "TDA-02.6" + "APO02.02": [ + "GOV-03", + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "PRM-01.1" ], - "4.7": [ - "CFG-02", - "IAC-01", - "IAC-10.8" + "APO01.05": [ + "GOV-04" ], - "10.3": [ - "CFG-02", - "END-02" + "BAI01.03": [ + "GOV-04.1", + "AST-01.2", + "PRM-04", + "PRM-07" ], - "9.1": [ - "CFG-04.2", - "CFG-05.2" + "EDM05.03": [ + "GOV-05", + "GOV-08", + "AST-01.2", + "AST-02.9", + "AST-03.1", + "CHG-05" ], - "8.2": [ - "MON-01", - "MON-01.4", - "MON-02", - "MON-02.7", - "MON-03" + "MEA01.02": [ + "GOV-05", + "CPL-01.1", + "CPL-01.3" ], - "8.1": [ - "MON-01.8", - "MON-02" + "MEA01.03": [ + "GOV-05" ], - "8.3": [ - "MON-02", - "MON-04" - ], - "3.6": [ - "CRY-01", - "CRY-05" - ], - "3.1": [ - "DCH-01", - "DCH-01.1", - "DCH-01.2", - "DCH-01.4", - "DCH-02", - "DCH-03", - "DCH-03.1", - "DCH-08", - "DCH-09", - "DCH-18" - ], - "3.3": [ - "DCH-01", - "DCH-01.4", - "DCH-03", - "DCH-03.1", - "DCH-13.1", - "DCH-14", - "DCH-14.2", - "DCH-14.3", - "IAC-08", - "NET-04" - ], - "3.2": [ - "DCH-06.2", - "DCH-06.3" - ], - "3.4": [ - "DCH-18" - ], - "10.1": [ - "END-04" - ], - "10.2": [ - "END-04.1" - ], - "6.3": [ - "IAC-06" - ], - "6.4": [ - "IAC-06" - ], - "6.5": [ - "IAC-06.1" - ], - "6.1": [ - "IAC-07" - ], - "6.2": [ - "IAC-07" - ], - "5.2": [ - "IAC-10", - "IAC-10.1" - ], - "5.3": [ - "IAC-15.3" - ], - "5.1": [ - "IAC-16", - "IAC-16.1" + "EDM05.02": [ + "GOV-08", + "AST-01.2", + "AST-02.9", + "AST-03.1", + "CHG-05", + "IRO-10" ], - "5.4": [ - "IAC-16", - "IAC-21", - "IAC-21.2" + "APO01.01": [ + "GOV-08", + "PRM-01.1" ], - "17.1": [ - "IRO-02", - "IRO-04", - "IRO-07" + "APO01.02": [ + "GOV-08", + "PRM-01.1" ], - "17.3": [ - "IRO-02" + "APO01.03": [ + "GOV-08", + "PRM-01.1" ], - "17.2": [ - "IRO-09", - "IRO-10", - "IRO-10.2", - "IRO-10.3", - "IRO-10.4" + "APO01.04": [ + "GOV-08", + "GOV-09" ], - "12.1": [ - "NET-01", - "VPM-04", - "VPM-04.1", - "VPM-05" + "APO01.06": [ + "GOV-08", + "AST-02.9", + "AST-03", + "AST-03.1" ], - "9.2": [ - "NET-18" + "APO02.01": [ + "GOV-08", + "SEA-02" ], - "14.1": [ - "SAT-01" + "APO02.05": [ + "GOV-08", + "PRM-01.1", + "PRM-01.2" ], - "14.3": [ - "SAT-02", - "SAT-03" + "APO08.01": [ + "GOV-08", + "PRM-05", + "PRM-06" ], - "14.7": [ - "SAT-02", - "SAT-03" + "APO08.02": [ + "GOV-08" ], - "14.8": [ - "SAT-02", - "SAT-03" + "APO08.03": [ + "GOV-08" ], - "14.2": [ - "SAT-02.2" + "APO08.04": [ + "GOV-08" ], - "14.4": [ - "SAT-03" + "APO11.01": [ + "GOV-18", + "DCH-22", + "OPS-03" ], - "14.6": [ - "SAT-03.2" + "APO14.04": [ + "GOV-18" ], - "14.5": [ - "SAT-03.3" + "BAI01.07": [ + "GOV-18", + "PRM-02.1" ], - "15.1": [ - "TPM-01.1" + "BAI09.04": [ + "AST-01", + "SEA-07.1" ], - "7.1": [ - "VPM-01" + "BAI09.05": [ + "AST-01", + "AST-02", + "AST-02.7" ], - "7.2": [ - "VPM-02" + "APO09.01": [ + "AST-01.1", + "BCD-02" ], - "7.3": [ - "VPM-05" + "BAI04.02": [ + "AST-01.1", + "BCD-02", + "RSK-08" ], - "7.4": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" - ] - }, - "general-cis-csc-8-1-ig2": { - "2.1": [ - "AST-01", - "AST-02", - "AST-02.9" + "BAI09.02": [ + "AST-01.1", + "BCD-02", + "TDA-06.1" ], - "2.2": [ - "AST-01", + "APO14.08": [ "AST-02", - "AST-02.7", - "RSK-06.2", - "TDA-17" + "AST-04", + "DCH-01" ], - "1.1": [ + "BAI09.01": [ "AST-02" ], - "2.4": [ - "AST-02", - "AST-02.2", + "BAI10.02": [ "AST-02.9", - "CFG-06.1", - "END-06.2" - ], - "6.6": [ - "AST-02", - "IAC-01", - "IAC-01.2" + "CFG-02", + "CFG-02.2" ], - "1.2": [ - "AST-02.2", - "NET-08.3" + "BAI10.03": [ + "AST-02.9" ], - "1.3": [ - "AST-02.2", - "AST-02.3" + "APO01.07": [ + "AST-03" ], - "2.3": [ - "AST-02.2", - "CFG-02.8", - "CFG-03.3", - "CFG-05.1", - "CFG-06.1", - "MON-16.3", - "END-03.1", - "END-06.2", - "IRO-02" + "APO14.05": [ + "AST-04.1", + "DCH-02" ], - "1.4": [ - "AST-02.6" + "APO14.10": [ + "BCD-01", + "BCD-11", + "BCD-12" ], - "16.5": [ - "AST-03.2", - "TDA-06", - "TDA-06.3", - "TDA-11", - "TDA-14.1" + "DSS04.01": [ + "BCD-01" ], - "3.8": [ - "AST-04", - "DCH-14.3" + "DSS04.02": [ + "BCD-01" ], - "12.4": [ - "AST-04" + "DSS04.03": [ + "BCD-01" ], - "3.5": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-21", - "PRI-05" + "DSS04.07": [ + "BCD-01", + "BCD-11", + "BCD-12" ], - "4.11": [ - "AST-16", - "MDM-01", - "MDM-05" + "DSS04.06": [ + "BCD-03" ], - "11.1": [ - "BCD-01" + "DSS04.04": [ + "BCD-04" ], - "11.2": [ - "BCD-11" + "DSS04.08": [ + "BCD-05" ], - "11.3": [ - "BCD-11.1", - "BCD-11.4", - "BCD-12", - "BCD-13", - "DCH-01" + "DSS04.05": [ + "BCD-06", + "BCD-06.1" ], - "11.5": [ - "BCD-11.1", - "BCD-11.5" + "BAI04.04": [ + "CAP-01" ], - "11.4": [ - "BCD-14" + "BAI04.05": [ + "CAP-01" ], - "4.1": [ - "CFG-01", - "CFG-02", - "CFG-02.1", - "IAC-22" + "BAI06.03": [ + "CHG-01", + "CHG-02" ], - "4.2": [ - "CFG-01", - "CFG-02" + "BAI06.04": [ + "CHG-02" ], - "4.3": [ - "CFG-02", - "IAC-24" + "BAI07.01": [ + "CHG-02" ], - "4.4": [ - "CFG-02", - "END-05", - "WEB-03" + "BAI07.02": [ + "CHG-02" ], - "4.5": [ - "CFG-02", - "END-05" + "BAI07.06": [ + "CHG-02", + "TDA-08.1" ], - "4.6": [ - "CFG-02", - "CFG-03", - "CRY-06", - "MNT-05", - "NET-04", - "TDA-02.6" + "BAI07.05": [ + "CHG-02.2" ], - "4.7": [ - "CFG-02", + "DSS06.03": [ + "CHG-04.4", + "HRS-03", + "HRS-04.1", + "HRS-12", "IAC-01", - "IAC-10.8" + "IAC-07.1" ], - "4.8": [ - "CFG-02", - "CFG-03" + "BAI07.08": [ + "CHG-06" ], - "10.3": [ - "CFG-02", - "END-02" + "BAI06.02": [ + "CHG-07" ], - "10.4": [ - "CFG-02", - "END-02", - "END-04", - "END-04.7" + "MEA03.01": [ + "CPL-01" ], - "10.5": [ - "CFG-02", - "END-02" + "MEA01.05": [ + "CPL-01.1" ], - "16.7": [ - "CFG-02", - "CFG-02.5", - "TDA-06.5", - "TDA-12", - "WEB-07" + "MEA02.04": [ + "CPL-01.1", + "CPL-02.2" ], - "2.5": [ - "CFG-03.2", - "CFG-03.3" + "MEA04.04": [ + "CPL-01.2", + "IAO-01.1" ], - "2.6": [ - "CFG-03.3" + "MEA03.03": [ + "CPL-01.3" ], - "9.1": [ - "CFG-04.2", - "CFG-05.2" + "MEA02.03": [ + "CPL-01.4" ], - "9.4": [ - "CFG-04.2", - "CFG-05.2", - "HRS-05.1", - "HRS-05.4" + "MEA03.04": [ + "CPL-01.4", + "CPL-01.5", + "IAO-05" ], - "8.2": [ - "MON-01", - "MON-01.4", - "MON-02", - "MON-02.7", - "MON-03" + "MEA02.01": [ + "CPL-02", + "CPL-02.1", + "CPL-03", + "CPL-03.2" ], - "13.6": [ - "MON-01", - "MON-01.13", - "MON-02.1", - "MON-02.3" + "MEA02.02": [ + "CPL-02", + "CPL-02.1", + "CPL-03", + "CPL-03.2" ], - "8.1": [ - "MON-01.8", - "MON-02", - "MON-04", - "MON-10" + "MEA04.02": [ + "CPL-02", + "CPL-02.1" ], - "8.3": [ - "MON-02", - "MON-04" + "APO02.04": [ + "CPL-02.1" ], - "8.4": [ - "MON-02", - "MON-07.1" + "MEA04.01": [ + "CPL-03.1" ], - "8.5": [ - "MON-02", - "MON-03" + "BAI10.01": [ + "CFG-01" ], - "8.6": [ - "MON-02", - "MON-02.3" + "BAI10.05": [ + "CFG-02.1", + "CFG-02.2" ], - "8.7": [ - "MON-02", - "MON-02.3" + "BAI10.04": [ + "CFG-02.2" ], - "8.8": [ - "MON-02", - "MON-03.3" + "DSS01.03": [ + "MON-01" ], - "8.9": [ - "MON-02" + "DSS05.07": [ + "MON-01", + "MON-01.1", + "END-01", + "VPM-01", + "VPM-06" ], - "13.1": [ - "MON-02" + "MEA01.01": [ + "MON-01" ], - "8.11": [ - "MON-02.2" + "DSS06.05": [ + "MON-01.4", + "MON-03" ], - "3.6": [ - "CRY-01", - "CRY-05" + "APO14.03": [ + "DCH-01" ], - "3.9": [ - "CRY-01", - "CRY-05", - "CRY-05.1" + "APO14.09": [ + "DCH-01", + "DCH-18" ], - "3.1": [ - "CRY-01", - "CRY-03", + "DSS06.02": [ "DCH-01", - "DCH-01.1", "DCH-01.2", "DCH-01.4", - "DCH-02", - "DCH-03", - "DCH-03.1", - "DCH-08", - "DCH-09", - "DCH-18" - ], - "3.11": [ - "CRY-01", - "CRY-05" - ], - "12.3": [ - "CRY-06", - "MNT-05.3", - "NET-01" + "DCH-06.2" ], - "3.3": [ + "DSS06.06": [ "DCH-01", + "DCH-01.2", "DCH-01.4", - "DCH-03", - "DCH-03.1", - "DCH-13.1", - "DCH-14", - "DCH-14.2", - "DCH-14.3", - "IAC-08", - "NET-04" - ], - "3.7": [ - "DCH-02", - "DCH-02.1" - ], - "3.12": [ - "DCH-02.1", - "SEA-03.1" - ], - "3.2": [ - "DCH-06.2", - "DCH-06.3" - ], - "3.4": [ - "DCH-18" - ], - "10.1": [ - "END-04" - ], - "10.2": [ - "END-04.1" + "DCH-13.2" ], - "10.6": [ - "END-04.3" + "APO11.02": [ + "DCH-22", + "OPS-03" ], - "10.7": [ - "END-04.4" + "APO11.03": [ + "DCH-22", + "OPS-03" ], - "13.2": [ - "END-07" + "APO11.04": [ + "DCH-22", + "OPS-03" ], - "9.6": [ - "END-08", - "IRO-15", - "NET-03", - "NET-08" + "APO11.05": [ + "DCH-22", + "OPS-03" ], - "5.6": [ - "IAC-01", - "IAC-01.2", - "IAC-02", - "IAC-09", - "IAC-15.1" + "APO14.06": [ + "DCH-22" ], - "12.5": [ - "IAC-01.2", - "IAC-02", - "IAC-03", - "IAC-04" + "APO14.07": [ + "DCH-22", + "DCH-22.1" ], - "5.5": [ - "IAC-02", - "IAC-05", - "IAC-16.1" + "BAI08.04": [ + "DCH-22" ], - "6.7": [ - "IAC-02", - "IAC-13.1", - "IAC-13.2" + "DSS05.03": [ + "END-01", + "END-02" ], - "6.3": [ - "IAC-06" + "DSS05.01": [ + "END-04", + "END-04.1", + "END-04.7" ], - "6.4": [ - "IAC-06" + "APO07.01": [ + "HRS-01" ], - "6.5": [ - "IAC-06.1" + "APO07.04": [ + "HRS-01" ], - "6.1": [ - "IAC-07" + "APO07.05": [ + "HRS-01" ], - "6.2": [ - "IAC-07" + "APO07.06": [ + "HRS-01", + "HRS-10" ], - "5.2": [ - "IAC-10", - "IAC-10.1" + "APO01.08": [ + "HRS-03.2", + "HRS-13", + "HRS-13.1", + "PRM-08" ], - "5.3": [ - "IAC-15.3" + "APO07.03": [ + "HRS-13", + "HRS-13.1", + "HRS-13.3", + "HRS-13.4" ], - "5.1": [ - "IAC-16", - "IAC-16.1" + "APO07.02": [ + "HRS-13.2" ], - "5.4": [ - "IAC-16", - "IAC-21", - "IAC-21.2" + "DSS05.04": [ + "IAC-08", + "IAC-20" ], - "17.5": [ + "DSS02.01": [ "IRO-01", "IRO-02", - "IRO-04", - "IRO-07" + "IRO-03", + "IRO-04" ], - "17.1": [ + "DSS02.02": [ "IRO-02", - "IRO-04", - "IRO-07" + "IRO-09" ], - "17.3": [ + "DSS02.03": [ "IRO-02" ], - "17.4": [ - "IRO-02", - "IRO-04", - "IRO-07" + "DSS02.04": [ + "IRO-02" ], - "17.6": [ + "DSS02.05": [ "IRO-02", - "IRO-04", - "IRO-07", "IRO-09" ], - "17.7": [ - "IRO-06" + "DSS02.06": [ + "IRO-02" ], - "17.2": [ - "IRO-09", - "IRO-10", - "IRO-10.2", - "IRO-10.3", - "IRO-10.4" + "DSS03.02": [ + "IRO-02" ], - "16.3": [ - "IRO-13", - "TDA-09" + "DSS03.01": [ + "IRO-02.4" ], - "17.8": [ - "IRO-13" + "DSS03.04": [ + "IRO-04.2", + "IRO-04.3" ], - "15.4": [ - "IAO-03.2", - "PRI-07.1", - "TPM-03.2", - "TPM-04", - "TPM-05" + "DSS03.05": [ + "IRO-04.3" ], - "12.1": [ - "NET-01", - "VPM-04", - "VPM-04.1", - "VPM-05" + "DSS02.07": [ + "IRO-09" ], - "12.2": [ - "NET-01", - "NET-02", - "SEA-01", - "SEA-02" + "DSS03.03": [ + "IRO-13" ], - "12.6": [ - "NET-01", - "NET-04", - "SEA-01", - "TDA-02.1", - "TPM-04.2" + "MEA04.05": [ + "IAO-01" ], - "13.5": [ - "NET-01.1", - "NET-03", - "NET-14.7" + "MEA04.06": [ + "IAO-01", + "IAO-02" ], - "13.4": [ - "NET-04", - "NET-04.1" + "BAI03.06": [ + "IAO-02", + "TDA-09" ], - "13.3": [ - "NET-08" + "BAI03.08": [ + "IAO-02", + "TDA-09" ], - "4.9": [ - "NET-10" + "MEA04.07": [ + "IAO-02" ], - "9.5": [ - "NET-10.3", - "NET-20.4" + "MEA04.08": [ + "IAO-02.4" ], - "12.7": [ - "NET-14", - "NET-14.1", - "NET-14.2", - "NET-14.3" + "APO12.05": [ + "IAO-05", + "PRM-01", + "PRM-02.1", + "RSK-01", + "RSK-04.1" ], - "9.2": [ - "NET-18" + "MEA04.09": [ + "IAO-05" ], - "9.3": [ - "NET-18" + "DSS05.02": [ + "NET-01" ], - "16.6": [ - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-02.1" + "DSS01.04": [ + "PES-01", + "PES-07", + "PES-07.1", + "PES-07.2", + "PES-07.3", + "PES-07.4", + "PES-07.5", + "PES-07.6", + "PES-08", + "PES-08.1", + "PES-08.2", + "PES-08.3", + "PES-09", + "PES-09.1" ], - "18.3": [ - "RSK-06", - "VPM-04", - "VPM-05" + "DSS01.05": [ + "PES-01" ], - "15.2": [ - "RSK-09", - "TPM-01" + "DSS05.05": [ + "PES-01", + "PES-02", + "PES-02.1", + "PES-03", + "PES-03.1", + "PES-03.4", + "PES-04" ], - "16.1": [ - "SEA-01", - "SEA-01.1", - "SEA-02", - "TDA-02.3", - "TDA-05", - "TDA-06", - "TDA-06.3", - "TDA-09.6", - "TDA-16", - "WEB-07", - "WEB-08" + "DSS05.06": [ + "PES-12.2" ], - "14.1": [ - "SAT-01" + "EDM02.01": [ + "PRM-01", + "PRM-02", + "PRM-03" ], - "14.3": [ - "SAT-02", - "SAT-03" + "EDM02.02": [ + "PRM-01", + "PRM-02", + "PRM-03" ], - "14.7": [ - "SAT-02", - "SAT-03" + "EDM02.03": [ + "PRM-01", + "PRM-02", + "PRM-03" ], - "14.8": [ - "SAT-02", - "SAT-03" + "EDM02.04": [ + "PRM-01", + "PRM-02", + "PRM-03" ], - "14.2": [ - "SAT-02.2" + "EDM04.01": [ + "PRM-01", + "PRM-02", + "PRM-03" ], - "14.4": [ - "SAT-03" + "EDM04.02": [ + "PRM-01", + "PRM-02", + "PRM-03" ], - "14.9": [ - "SAT-03", - "SAT-03.1", - "SAT-03.7" + "EDM04.03": [ + "PRM-01", + "PRM-02", + "PRM-03" ], - "16.9": [ - "SAT-03", - "SAT-03.8" + "APO05.01": [ + "PRM-01" ], - "14.6": [ - "SAT-03.2" + "APO05.02": [ + "PRM-01" ], - "14.5": [ - "SAT-03.3" + "APO05.03": [ + "PRM-01" ], - "16.4": [ - "TDA-02", - "TDA-02.1", - "TDA-02.5", - "TDA-04.2" + "APO05.04": [ + "PRM-01" ], - "16.2": [ - "TDA-04.2", - "TDA-06.2", - "TDA-06.5", - "TDA-09", - "TDA-09.1", - "TDA-15", - "THR-06" + "APO05.05": [ + "PRM-01" ], - "16.11": [ - "TDA-06", - "TDA-06.3", - "TDA-12", - "TDA-14", - "TDA-14.1" + "BAI01.05": [ + "PRM-01", + "PRM-03" ], - "16.8": [ - "TDA-07", - "TDA-08" + "BAI01.08": [ + "PRM-01", + "PRM-02.1" ], - "15.1": [ - "TPM-01.1" + "BAI01.09": [ + "PRM-01", + "PRM-02.1" ], - "15.3": [ - "TPM-02" + "BAI02.02": [ + "PRM-01" ], - "7.1": [ - "VPM-01" + "BAI02.04": [ + "PRM-01", + "PRM-07" ], - "7.2": [ - "VPM-02" + "APO02.06": [ + "PRM-01.1" ], - "7.7": [ - "VPM-02", - "VPM-04" + "APO02.03": [ + "PRM-01.2" ], - "7.3": [ - "VPM-05" + "BAI02.03": [ + "PRM-02.1" ], - "7.4": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "BAI11.06": [ + "PRM-02.1", + "PRM-04" ], - "7.5": [ - "VPM-06", - "VPM-06.7" + "APO06.01": [ + "PRM-03" ], - "7.6": [ - "VPM-06", - "VPM-06.6" + "APO06.02": [ + "PRM-03" ], - "18.1": [ - "VPM-07" + "APO06.03": [ + "PRM-03" ], - "18.2": [ - "VPM-07" - ] - }, - "general-cis-csc-8-1-ig3": { - "2.1": [ - "AST-01", - "AST-02", - "AST-02.9" + "APO06.04": [ + "PRM-03" ], - "2.2": [ - "AST-01", - "AST-02", - "AST-02.7", - "RSK-06.2", - "TDA-17" + "APO06.05": [ + "PRM-03" ], - "1.1": [ - "AST-02" + "EDM03.01": [ + "PRM-04", + "RSK-01" ], - "2.4": [ - "AST-02", - "AST-02.2", - "AST-02.9", - "CFG-06.1", - "END-06.2" + "BAI01.01": [ + "PRM-04", + "PRM-07" ], - "6.6": [ - "AST-02", - "IAC-01", - "IAC-01.2" + "BAI01.02": [ + "PRM-04", + "PRM-07" ], - "1.2": [ - "AST-02.2", - "NET-08.3" + "BAI01.04": [ + "PRM-04", + "PRM-05", + "PRM-06" ], - "1.3": [ - "AST-02.2", - "AST-02.3" + "BAI03.01": [ + "PRM-04", + "PRM-05", + "PRM-06" ], - "1.5": [ - "AST-02.2", - "AST-02.6" + "BAI03.02": [ + "PRM-04", + "TDA-01" ], - "2.3": [ - "AST-02.2", - "CFG-02.8", - "CFG-03.3", - "CFG-05.1", - "CFG-06.1", - "MON-16.3", - "END-03.1", - "END-06.2", - "IRO-02" + "BAI11.01": [ + "PRM-04" ], - "13.9": [ - "AST-02.5" + "BAI11.02": [ + "PRM-04" ], - "1.4": [ - "AST-02.6" + "BAI11.03": [ + "PRM-04" ], - "16.5": [ - "AST-03.2", - "TDA-06", - "TDA-06.3", - "TDA-11", - "TDA-14.1" + "BAI11.04": [ + "PRM-04" ], - "3.8": [ - "AST-04", - "DCH-14.3" + "BAI11.05": [ + "PRM-04" ], - "12.4": [ - "AST-04" + "BAI11.07": [ + "PRM-04" ], - "3.5": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-21", - "PRI-05" + "BAI11.08": [ + "PRM-04" ], - "4.11": [ - "AST-16", - "MDM-01", - "MDM-05" + "BAI11.09": [ + "PRM-04" ], - "11.1": [ - "BCD-01" + "APO01.10": [ + "PRM-05", + "PRM-06" ], - "11.2": [ - "BCD-11" + "BAI02.01": [ + "PRM-05", + "PRM-06" ], - "11.3": [ - "BCD-11.1", - "BCD-11.4", - "BCD-12", - "BCD-13", - "DCH-01" + "BAI03.03": [ + "PRM-05", + "TDA-01.1", + "TDA-02" ], - "11.5": [ - "BCD-11.1", - "BCD-11.5" + "BAI03.04": [ + "PRM-05", + "TPM-03.1" ], - "11.4": [ - "BCD-14" + "BAI04.03": [ + "PRM-06", + "PRM-07" ], - "18.4": [ - "CHG-06" + "BAI03.09": [ + "PRM-07" ], - "4.1": [ - "CFG-01", - "CFG-02", - "CFG-02.1", - "IAC-22" + "BAI03.11": [ + "PRM-07", + "TDA-01.1" ], - "4.2": [ - "CFG-01", - "CFG-02" + "BAI05.01": [ + "PRM-07" ], - "4.3": [ - "CFG-02", - "IAC-24" + "BAI05.07": [ + "PRM-07" ], - "4.4": [ - "CFG-02", - "END-05", - "WEB-03" + "BAI09.03": [ + "PRM-07", + "SEA-07.1" ], - "4.5": [ - "CFG-02", - "END-05" + "EDM03.02": [ + "RSK-01" ], - "4.6": [ - "CFG-02", - "CFG-03", - "CRY-06", - "MNT-05", - "NET-04", - "TDA-02.6" + "EDM03.03": [ + "RSK-01" ], - "4.7": [ - "CFG-02", - "IAC-01", - "IAC-10.8" + "APO12.01": [ + "RSK-01", + "RSK-01.1", + "RSK-03", + "RSK-03.1", + "RSK-09", + "RSK-09.1", + "RSK-10" ], - "4.8": [ - "CFG-02", - "CFG-03" + "APO12.02": [ + "RSK-01", + "RSK-04", + "RSK-09", + "RSK-09.1", + "RSK-10" ], - "10.3": [ - "CFG-02", - "END-02" + "APO12.03": [ + "RSK-01", + "RSK-04.1", + "RSK-05", + "RSK-08", + "RSK-09", + "RSK-09.1", + "RSK-10" ], - "10.4": [ - "CFG-02", - "END-02", - "END-04", - "END-04.7" + "APO12.04": [ + "RSK-01", + "RSK-01.1", + "RSK-03.1", + "RSK-09", + "RSK-09.1", + "RSK-10" ], - "10.5": [ - "CFG-02", - "END-02" + "APO12.06": [ + "RSK-01", + "RSK-06", + "RSK-06.1", + "RSK-06.4" ], - "16.7": [ - "CFG-02", - "CFG-02.5", - "TDA-06.5", - "TDA-12", - "WEB-07" + "APO13.02": [ + "RSK-06.4" ], - "2.5": [ - "CFG-03.2", - "CFG-03.3" + "APO03.01": [ + "SEA-01", + "SEA-01.1", + "SEA-02", + "SEA-03" ], - "2.6": [ - "CFG-03.3" + "APO03.02": [ + "SEA-01", + "SEA-02", + "TDA-01", + "TDA-01.1", + "TDA-06" ], - "2.7": [ - "CFG-03.3", - "IAC-16", - "MNT-04", - "MNT-04.4" + "APO03.03": [ + "SEA-01", + "SEA-01.1", + "SEA-02", + "TDA-01", + "TDA-01.1" ], - "9.1": [ - "CFG-04.2", - "CFG-05.2" + "APO03.04": [ + "SEA-01", + "SEA-02" ], - "9.4": [ - "CFG-04.2", - "CFG-05.2", - "HRS-05.1", - "HRS-05.4" + "APO03.05": [ + "SEA-01", + "SEA-02" ], - "8.2": [ - "MON-01", - "MON-01.4", - "MON-02", - "MON-02.7", - "MON-03" + "APO04.05": [ + "SEA-01", + "SEA-02", + "SEA-03" ], - "13.6": [ - "MON-01", - "MON-01.13", - "MON-02.1", - "MON-02.3" + "APO04.02": [ + "SEA-02" ], - "8.1": [ - "MON-01.8", - "MON-02", - "MON-04", - "MON-10" + "APO04.03": [ + "SEA-02" ], - "13.11": [ - "MON-01.13" + "APO04.04": [ + "SEA-02" ], - "3.14": [ - "MON-01.15", - "MON-02", - "MON-02.1", - "MON-02.3", - "MON-03", - "MON-03.1" + "APO04.06": [ + "SEA-02" ], - "8.3": [ - "MON-02", - "MON-04" + "APO14.02": [ + "SEA-02.1" ], - "8.4": [ - "MON-02", - "MON-07.1" + "DSS01.01": [ + "OPS-01.1" ], - "8.5": [ - "MON-02", - "MON-03" + "APO01.11": [ + "OPS-03" ], - "8.6": [ - "MON-02", - "MON-02.3" + "APO08.05": [ + "OPS-03" ], - "8.7": [ - "MON-02", - "MON-02.3" + "APO09.02": [ + "OPS-03" ], - "8.8": [ - "MON-02", - "MON-03.3" + "APO09.03": [ + "OPS-03", + "TPM-08" ], - "8.9": [ - "MON-02" + "APO09.04": [ + "OPS-03", + "TPM-08" ], - "8.12": [ - "MON-02", - "MON-02.1", - "MON-02.3" + "APO09.05": [ + "OPS-03", + "TPM-08" ], - "13.1": [ - "MON-02", - "NET-18", - "NET-18.1", - "WEB-03" + "BAI03.05": [ + "TDA-01.1", + "TDA-02" ], - "8.11": [ - "MON-02.2" + "BAI03.10": [ + "TDA-01.1" ], - "3.6": [ - "CRY-01", - "CRY-05" + "BAI04.01": [ + "TDA-01.1" ], - "3.9": [ - "CRY-01", - "CRY-05", - "CRY-05.1" + "BAI05.02": [ + "TDA-01.1" ], - "3.1": [ - "CRY-01", - "CRY-03", - "DCH-01", - "DCH-01.1", - "DCH-01.2", - "DCH-01.4", - "DCH-02", - "DCH-03", - "DCH-03.1", - "DCH-08", - "DCH-09", - "DCH-18" + "BAI05.03": [ + "TDA-01.1" ], - "3.11": [ - "CRY-01", - "CRY-05" + "BAI05.04": [ + "TDA-01.1" ], - "12.3": [ - "CRY-06", - "MNT-05.3", - "NET-01" + "BAI05.05": [ + "TDA-01.1" ], - "3.3": [ - "DCH-01", - "DCH-01.4", - "DCH-03", - "DCH-03.1", - "DCH-13.1", - "DCH-14", - "DCH-14.2", - "DCH-14.3", - "IAC-08", - "NET-04" + "BAI05.06": [ + "TDA-01.1" ], - "3.7": [ - "DCH-02", - "DCH-02.1" + "BAI06.01": [ + "TDA-01.1" ], - "3.12": [ - "DCH-02.1", - "SEA-03.1" + "BAI07.07": [ + "TDA-01.1" ], - "3.2": [ - "DCH-06.2", - "DCH-06.3" + "BAI08.01": [ + "TDA-01.1" ], - "3.4": [ - "DCH-18" + "BAI08.02": [ + "TDA-01.1" ], - "10.1": [ - "END-04" + "BAI08.03": [ + "TDA-01.1" ], - "10.2": [ - "END-04.1" + "BAI03.12": [ + "TDA-02.3" ], - "10.6": [ - "END-04.3" + "BAI07.04": [ + "TDA-07", + "TDA-08" ], - "10.7": [ - "END-04.4" + "BAI03.07": [ + "TDA-09" ], - "13.7": [ - "END-06.2", - "END-07" + "APO10.01": [ + "TPM-01" ], - "13.2": [ - "END-07" + "APO10.02": [ + "TPM-01" ], - "9.6": [ - "END-08", - "IRO-15", - "NET-03", - "NET-08" + "APO10.03": [ + "TPM-01", + "TPM-04.4", + "TPM-05", + "TPM-06" ], - "9.7": [ - "END-08", - "IRO-15" + "APO10.04": [ + "TPM-01", + "TPM-02", + "TPM-03", + "TPM-03.3", + "TPM-04.1", + "TPM-09", + "TPM-10" ], - "5.6": [ - "IAC-01", - "IAC-01.2", - "IAC-02", - "IAC-09", - "IAC-15.1" + "APO10.05": [ + "TPM-01", + "TPM-08" ], - "12.5": [ - "IAC-01.2", - "IAC-02", - "IAC-03", - "IAC-04" + "DSS01.02": [ + "TPM-01" + ] + }, + "general-coso-2013": { + "1": [ + "GOV-01.1", + "GOV-04", + "CPL-02", + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-07.1" ], - "5.5": [ - "IAC-02", - "IAC-05", - "IAC-16.1" + "2": [ + "GOV-01", + "GOV-01.1", + "GOV-01.2", + "GOV-01.3", + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "HRS-02", + "HRS-03", + "HRS-03.2" ], - "6.7": [ - "IAC-02", - "IAC-13.1", - "IAC-13.2" + "3": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "HRS-03", + "HRS-03.2", + "PRM-06" ], - "6.3": [ - "IAC-06" + "4": [ + "HRS-01", + "HRS-02.1", + "HRS-03.1", + "HRS-03.2", + "HRS-04", + "HRS-04.1", + "HRS-04.2", + "SAT-01" ], - "6.4": [ - "IAC-06" + "5": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "HRS-01", + "HRS-03.2", + "HRS-06", + "HRS-06.1", + "HRS-07", + "HRS-07.1" ], - "6.5": [ - "IAC-06.1" + "6": [ + "GOV-08", + "GOV-09", + "PRM-01", + "PRM-04", + "PRM-06" ], - "6.1": [ - "IAC-07" + "7": [ + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.1", + "RSK-07", + "RSK-08", + "RSK-09", + "RSK-09.1", + "RSK-10" ], - "6.2": [ - "IAC-07" + "8": [ + "RSK-01", + "RSK-03", + "TPM-01", + "TPM-03.1", + "TPM-04", + "TPM-04.3", + "THR-01", + "THR-02", + "THR-04", + "THR-10", + "THR-11" ], - "6.8": [ - "IAC-08" + "9": [ + "CHG-01", + "CHG-02", + "CHG-02.2", + "CHG-02.3", + "CHG-03", + "PRM-01", + "PRM-06", + "TPM-04.1", + "TPM-08", + "TPM-10" ], - "5.2": [ - "IAC-10", - "IAC-10.1" + "10": [ + "GOV-08", + "GOV-09", + "PRM-06", + "SEA-01", + "SEA-01.1", + "SEA-02", + "OPS-01.1", + "OPS-02" ], - "5.3": [ - "IAC-15.3" + "11": [ + "PRM-04", + "PRM-05", + "PRM-06", + "PRM-07", + "SEA-01", + "SEA-01.1", + "TDA-01", + "TDA-01.1", + "TDA-02" ], - "5.1": [ - "IAC-16", - "IAC-16.1" + "12": [ + "GOV-01", + "GOV-02", + "GOV-03", + "OPS-01.1", + "TPM-05.4" ], - "5.4": [ - "IAC-16", - "IAC-21", - "IAC-21.2" + "13": [ + "AST-04", + "DCH-01", + "DCH-01.1", + "DCH-02", + "DCH-22", + "RSK-06", + "OPS-03" ], - "12.8": [ - "IAC-20.4" + "14": [ + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "CPL-01", + "CPL-02", + "HRS-03", + "PRM-01", + "PRM-05", + "SEA-01", + "SEA-02.1", + "OPS-01", + "OPS-01.1" ], - "17.5": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07" + "15": [ + "GOV-06", + "CPL-01", + "CPL-02", + "IRO-10", + "IRO-14", + "PRI-14" ], - "17.1": [ - "IRO-02", - "IRO-04", - "IRO-07" + "16": [ + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "CPL-03", + "CPL-03.2", + "CPL-04", + "IAO-01", + "IAO-02", + "IAO-02.2", + "IAO-04", + "IAO-06", + "PRM-03", + "PRM-04", + "PRM-05", + "PRM-06", + "RSK-01", + "RSK-09" ], - "17.3": [ - "IRO-02" + "17": [ + "CPL-01.1", + "IAO-04", + "IAO-05", + "RSK-06", + "TDA-15", + "TPM-09", + "VPM-02", + "VPM-04" + ] + }, + "general-csa-cmm-4-1-0": { + "GRC-01": [ + "GOV-01", + "GOV-02" ], - "17.4": [ - "IRO-02", - "IRO-04", - "IRO-07" + "GRC-05": [ + "GOV-01" ], - "17.6": [ - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09" + "A&A-01": [ + "GOV-02", + "GOV-03" ], - "17.9": [ - "IRO-02", - "IRO-04", - "IRO-07" + "AIS-01": [ + "GOV-02", + "GOV-03", + "TDA-01" ], - "17.7": [ - "IRO-06" + "BCR-01": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "17.2": [ - "IRO-09", - "IRO-10", - "IRO-10.2", - "IRO-10.3", - "IRO-10.4" + "CCC-01": [ + "GOV-02", + "GOV-03", + "CHG-01" ], - "16.3": [ - "IRO-13", - "TDA-09" + "CEK-01": [ + "GOV-02", + "GOV-03", + "CRY-01" ], - "17.8": [ - "IRO-13" + "DCS-01": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "15.4": [ - "IAO-03.2", - "PRI-07.1", - "TPM-03.2", - "TPM-04", - "TPM-05" + "DSP-01": [ + "GOV-02" ], - "4.12": [ - "MDM-10" + "IAM-01": [ + "GOV-02", + "GOV-03", + "IAC-01", + "WEB-06" ], - "12.1": [ - "NET-01", - "VPM-04", - "VPM-04.1", - "VPM-05" + "IAM-02": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "12.2": [ - "NET-01", - "NET-02", - "SEA-01", - "SEA-02" + "IPY-01": [ + "GOV-02", + "GOV-03", + "CLD-01" ], - "12.6": [ - "NET-01", - "NET-04", + "I&S-01": [ + "GOV-02", + "GOV-03", "SEA-01", - "TDA-02.1", - "TPM-04.2" + "SEA-13.1" ], - "13.5": [ - "NET-01.1", - "NET-03", - "NET-14.7" + "LOG-01": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "13.4": [ - "NET-04", - "NET-04.1" + "SEF-01": [ + "GOV-02", + "GOV-03", + "IRO-01" ], - "13.3": [ - "NET-08" + "SEF-02": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "13.8": [ - "NET-08" + "STA-01": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "4.9": [ - "NET-10" + "TVM-01": [ + "GOV-02", + "GOV-03", + "VPM-01" ], - "9.5": [ - "NET-10.3", - "NET-20.4" + "TVM-02": [ + "GOV-02", + "GOV-03", + "END-01" ], - "12.7": [ - "NET-14", - "NET-14.1", - "NET-14.2", - "NET-14.3" + "TVM-04": [ + "GOV-02", + "GOV-03", + "THR-01" ], - "3.13": [ - "NET-17" + "UEM-01": [ + "GOV-02", + "GOV-03", + "END-01" ], - "9.2": [ - "NET-18" + "CCC-08": [ + "GOV-02.1", + "CFG-02.2", + "CFG-02.7" ], - "9.3": [ - "NET-18" + "GRC-04": [ + "GOV-02.1" ], - "15.7": [ - "PRM-05", - "PRM-06", - "PRM-07", - "TDA-01", - "TDA-01.1", - "TPM-10" + "GRC-03": [ + "GOV-03" ], - "16.6": [ - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-02.1" + "GRC-06": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "HRS-03", + "TPM-05.4" ], - "18.3": [ - "RSK-06", - "VPM-04", - "VPM-05" + "AIS-03": [ + "GOV-05" ], - "15.2": [ - "RSK-09", - "TPM-01" + "DCS-17": [ + "GOV-05" ], - "15.5": [ - "RSK-09.1", - "TPM-04", - "TPM-04.1" + "SEF-05": [ + "GOV-05" ], - "16.1": [ - "SEA-01", - "SEA-01.1", - "SEA-02", - "TDA-02.3", - "TDA-05", - "TDA-06", - "TDA-06.3", - "TDA-09.6", - "TDA-16", - "WEB-07", - "WEB-08" + "TVM-12": [ + "GOV-05" ], - "14.1": [ - "SAT-01" + "GRC-08": [ + "GOV-07" ], - "14.3": [ - "SAT-02", - "SAT-03" + "DCS-09": [ + "AST-01.3", + "IAC-04" ], - "14.7": [ - "SAT-02", - "SAT-03" + "DCS-07": [ + "AST-02" ], - "14.8": [ - "SAT-02", - "SAT-03" + "DSP-03": [ + "AST-02" ], - "14.2": [ - "SAT-02.2" + "UEM-04": [ + "AST-02" ], - "14.4": [ - "SAT-03" + "DSP-05": [ + "AST-04" ], - "14.9": [ - "SAT-03", - "SAT-03.1", - "SAT-03.7" + "I&S-08": [ + "AST-04", + "AST-31.2", + "SEA-02" ], - "16.9": [ - "SAT-03", - "SAT-03.8" + "LOG-07": [ + "AST-04.1", + "CPL-01.2" ], - "14.6": [ - "SAT-03.2" + "DCS-03": [ + "AST-05", + "AST-05.1", + "BCD-11.6", + "DCH-25" ], - "14.5": [ - "SAT-03.3" + "DCS-02": [ + "AST-09", + "DCH-08", + "DCH-09" ], - "16.4": [ - "TDA-02", - "TDA-02.1", - "TDA-02.5", - "TDA-04.2" + "DSP-02": [ + "AST-09" ], - "16.2": [ - "TDA-04.2", - "TDA-06.2", - "TDA-06.5", - "TDA-09", - "TDA-09.1", - "TDA-15", - "THR-06" + "HRS-05": [ + "AST-10" ], - "16.11": [ - "TDA-06", - "TDA-06.3", - "TDA-12", - "TDA-14", - "TDA-14.1" + "BCR-02": [ + "BCD-01", + "BCD-02", + "RSK-02", + "RSK-02.1", + "RSK-08" ], - "16.14": [ - "TDA-06.2" + "BCR-03": [ + "BCD-01", + "BCD-01.4", + "BCD-01.5", + "BCD-02.1", + "BCD-02.2", + "BCD-02.3", + "BCD-10.3", + "BCD-11.7", + "BCD-12.2", + "BCD-12.4" ], - "16.12": [ - "TDA-06.5", - "TDA-09", - "TDA-09.2", - "TDA-09.3" + "BCR-05": [ + "BCD-01", + "DCH-01.4", + "DCH-03.1" ], - "16.8": [ - "TDA-07", - "TDA-08" + "BCR-09": [ + "BCD-01", + "BCD-06", + "BCD-06.1", + "BCD-06.2" ], - "16.13": [ - "TDA-09.5" + "BCR-06": [ + "BCD-01.1", + "BCD-01.2", + "BCD-04", + "BCD-11.5" ], - "15.1": [ - "TPM-01.1" + "BCR-07": [ + "BCD-01.6" ], - "15.3": [ - "TPM-02" + "BCR-10": [ + "BCD-04" ], - "15.6": [ - "TPM-08" + "DCS-15": [ + "BCD-04", + "PES-07" ], - "7.1": [ - "VPM-01" - ], - "7.2": [ - "VPM-02" - ], - "7.7": [ - "VPM-02", - "VPM-04" - ], - "7.3": [ - "VPM-05" - ], - "7.4": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" - ], - "7.5": [ - "VPM-06", - "VPM-06.7" - ], - "7.6": [ - "VPM-06", - "VPM-06.6" - ], - "18.1": [ - "VPM-07" - ], - "18.2": [ - "VPM-07" - ], - "18.5": [ - "VPM-07" - ] - }, - "general-cobit-2019": { - "EDM01.02": [ - "GOV-01" - ], - "APO01.09": [ - "GOV-01", - "GOV-02", - "OPS-01.1" - ], - "APO04.01": [ - "GOV-01", - "PRI-01", - "TDA-01" - ], - "APO13.01": [ - "GOV-01" - ], - "APO13.03": [ - "GOV-01" - ], - "APO14.01": [ - "GOV-01.1", - "GOV-01.3", - "GOV-03", - "CHG-05", - "DCH-01" - ], - "DSS06.01": [ - "GOV-01.1", - "GOV-05" - ], - "MEA01.04": [ - "GOV-01.1" - ], - "MEA03.02": [ - "GOV-01.1", - "GOV-03" - ], - "MEA04.03": [ - "GOV-01.1" + "BCR-04": [ + "BCD-06", + "BCD-06.1" ], - "BAI01.06": [ - "GOV-01.2", - "PRM-04" + "BCR-08": [ + "BCD-11", + "BCD-11.1", + "BCD-11.4", + "BCD-11.5" ], - "DSS06.04": [ - "GOV-02.1", - "IAO-04", - "TDA-15", - "VPM-02", - "VPM-04" + "BCR-11": [ + "BCD-11.7", + "BCD-12.2" ], - "EDM01.01": [ - "GOV-03" + "I&S-02": [ + "CAP-01", + "CAP-03" ], - "EDM01.03": [ - "GOV-03", - "GOV-05" + "CCC-03": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-03" ], - "EDM05.01": [ - "GOV-03", - "GOV-05", - "GOV-08", - "AST-01.2", - "AST-02.9", - "AST-03.1", + "CEK-06": [ + "CHG-01", "CHG-05" ], - "APO02.02": [ - "GOV-03", - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "PRM-01.1" - ], - "APO01.05": [ - "GOV-04" - ], - "BAI01.03": [ - "GOV-04.1", - "AST-01.2", - "PRM-04", - "PRM-07" + "CCC-02": [ + "CHG-02", + "CHG-02.2" ], - "EDM05.03": [ - "GOV-05", - "GOV-08", - "AST-01.2", - "AST-02.9", - "AST-03.1", + "CCC-05": [ + "CHG-02", + "CHG-03", "CHG-05" ], - "MEA01.02": [ - "GOV-05", - "CPL-01.1", - "CPL-01.3" - ], - "MEA01.03": [ - "GOV-05" - ], - "EDM05.02": [ - "GOV-08", - "AST-01.2", - "AST-02.9", - "AST-03.1", - "CHG-05", - "IRO-10" + "CCC-09": [ + "CHG-02", + "CHG-02.4", + "CHG-04.1", + "CFG-02.8" ], - "APO01.01": [ - "GOV-08", - "PRM-01.1" + "CEK-05": [ + "CHG-02" ], - "APO01.02": [ - "GOV-08", - "PRM-01.1" + "CCC-04": [ + "CHG-02.1", + "CHG-02.4", + "CHG-04", + "CHG-04.1", + "CHG-04.4" ], - "APO01.03": [ - "GOV-08", - "PRM-01.1" + "CCC-06": [ + "CHG-02.4", + "CFG-02", + "CFG-02.1", + "CFG-02.2" ], - "APO01.04": [ - "GOV-08", - "GOV-09" + "IPY-04": [ + "CLD-01", + "IAO-03.2", + "PRI-07.1", + "TPM-05" ], - "APO01.06": [ - "GOV-08", - "AST-02.9", - "AST-03", - "AST-03.1" + "AIS-08": [ + "CLD-04" ], - "APO02.01": [ - "GOV-08", - "SEA-02" + "IPY-02": [ + "CLD-04" ], - "APO02.05": [ - "GOV-08", - "PRM-01.1", - "PRM-01.2" + "IPY-03": [ + "CLD-04", + "CLD-07" ], - "APO08.01": [ - "GOV-08", - "PRM-05", - "PRM-06" + "DSP-19": [ + "CLD-09", + "DCH-19" ], - "APO08.02": [ - "GOV-08" + "DSP-17": [ + "CLD-10", + "DCH-01", + "DCH-02.1", + "DCH-06.2", + "DCH-06.4", + "DCH-13.3", + "IAC-20.1", + "IAO-03.2", + "PRI-05.4", + "SAT-03.3" ], - "APO08.03": [ - "GOV-08" + "A&A-04": [ + "CPL-01" ], - "APO08.04": [ - "GOV-08" + "GRC-07": [ + "CPL-01", + "CPL-01.2" ], - "APO11.01": [ - "GOV-18", - "DCH-22", - "OPS-03" + "A&A-05": [ + "CPL-01.1", + "CPL-02", + "CPL-02.1", + "CPL-03", + "CPL-03.1", + "CPL-03.2", + "CPL-04" ], - "APO14.04": [ - "GOV-18" + "A&A-06": [ + "CPL-01.1", + "IAO-05", + "RSK-01.1", + "RSK-02.1", + "RSK-04.1", + "RSK-06.1", + "RSK-06.4" ], - "BAI01.07": [ - "GOV-18", - "PRM-02.1" + "A&A-02": [ + "CPL-02", + "CPL-02.2", + "CPL-03", + "CPL-03.1" ], - "BAI09.04": [ - "AST-01", - "SEA-07.1" + "CEK-09": [ + "CPL-02", + "CPL-02.1", + "CPL-03", + "CPL-03.1", + "CPL-03.2" ], - "BAI09.05": [ - "AST-01", - "AST-02", - "AST-02.7" + "A&A-03": [ + "CPL-03" ], - "APO09.01": [ - "AST-01.1", - "BCD-02" + "DSP-18": [ + "CPL-05", + "CPL-05.1", + "CPL-05.2", + "DCH-03.1", + "PRI-07.4", + "PRI-07.5", + "PRI-14.1", + "PRI-14.2" ], - "BAI04.02": [ - "AST-01.1", - "BCD-02", - "RSK-08" + "UEM-03": [ + "CFG-01" ], - "BAI09.02": [ - "AST-01.1", - "BCD-02", - "TDA-06.1" + "UEM-07": [ + "CFG-01", + "CFG-02" ], - "APO14.08": [ - "AST-02", - "AST-04", - "DCH-01" + "AIS-02": [ + "CFG-02", + "CFG-02.4", + "CFG-02.5", + "CFG-02.7", + "CFG-02.9", + "CFG-03", + "CFG-03.1" ], - "BAI09.01": [ - "AST-02" + "I&S-04": [ + "CFG-02" ], - "BAI10.02": [ - "AST-02.9", - "CFG-02", + "CCC-07": [ "CFG-02.2" ], - "BAI10.03": [ - "AST-02.9" - ], - "APO01.07": [ - "AST-03" + "UEM-02": [ + "CFG-03.3" ], - "APO14.05": [ - "AST-04.1", - "DCH-02" + "IAM-09": [ + "CFG-05.2", + "MON-01.15", + "MON-03.3", + "IAC-08", + "IAC-09.5", + "IAC-16", + "IAC-17", + "IAC-21.1", + "IAC-21.3", + "IAC-21.4", + "IAC-21.5", + "VPM-06.3" ], - "APO14.10": [ - "BCD-01", - "BCD-11", - "BCD-12" + "LOG-03": [ + "MON-01.2", + "MON-01.4", + "MON-01.8" ], - "DSS04.01": [ - "BCD-01" + "LOG-05": [ + "MON-01.8" ], - "DSS04.02": [ - "BCD-01" + "IAM-10": [ + "MON-01.15", + "MON-03.3", + "IAC-08", + "IAC-09.5", + "IAC-16", + "IAC-16.1", + "IAC-17" ], - "DSS04.03": [ - "BCD-01" + "IAM-11": [ + "MON-01.15", + "MON-03.3", + "IAC-03", + "IAC-09.5", + "IAC-16", + "IAC-16.1", + "IAC-17", + "TPM-01", + "TPM-03", + "TPM-04" ], - "DSS04.07": [ - "BCD-01", - "BCD-11", - "BCD-12" + "LOG-09": [ + "MON-03" ], - "DSS04.06": [ - "BCD-03" + "LOG-12": [ + "MON-03" ], - "DSS04.04": [ - "BCD-04" + "LOG-02": [ + "MON-08" ], - "DSS04.08": [ - "BCD-05" + "LOG-10": [ + "MON-08" ], - "DSS04.05": [ - "BCD-06", - "BCD-06.1" + "LOG-04": [ + "MON-08.2", + "MON-10" ], - "BAI04.04": [ - "CAP-01" + "LOG-14": [ + "MON-11.3", + "MON-16", + "IRO-03" ], - "BAI04.05": [ - "CAP-01" + "CEK-02": [ + "CRY-01", + "HRS-03", + "HRS-12" ], - "BAI06.03": [ - "CHG-01", - "CHG-02" + "CEK-03": [ + "CRY-01", + "CRY-03", + "CRY-05" ], - "BAI06.04": [ - "CHG-02" + "CEK-04": [ + "CRY-01", + "DCH-01" ], - "BAI07.01": [ - "CHG-02" + "DSP-10": [ + "CRY-01", + "CRY-03", + "DCH-01", + "DCH-14", + "DCH-14.2", + "DCH-17" ], - "BAI07.02": [ - "CHG-02" + "LOG-11": [ + "CRY-01", + "CRY-08", + "CRY-09" ], - "BAI07.06": [ - "CHG-02", - "TDA-08.1" + "UEM-08": [ + "CRY-05", + "CRY-05.1" ], - "BAI07.05": [ - "CHG-02.2" + "CEK-08": [ + "CRY-08", + "CRY-09" ], - "DSS06.03": [ - "CHG-04.4", - "HRS-03", - "HRS-04.1", - "HRS-12", - "IAC-01", - "IAC-07.1" + "CEK-10": [ + "CRY-09", + "CRY-09.4" ], - "BAI07.08": [ - "CHG-06" + "CEK-11": [ + "CRY-09", + "CRY-09.4" ], - "BAI06.02": [ - "CHG-07" + "CEK-12": [ + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "MEA03.01": [ - "CPL-01" + "CEK-13": [ + "CRY-09", + "CRY-09.3" ], - "MEA01.05": [ - "CPL-01.1" + "CEK-14": [ + "CRY-09", + "CRY-09.3" ], - "MEA02.04": [ - "CPL-01.1", - "CPL-02.2" + "CEK-15": [ + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "MEA04.04": [ - "CPL-01.2", - "IAO-01.1" + "CEK-16": [ + "CRY-09", + "CRY-09.3" ], - "MEA03.03": [ - "CPL-01.3" + "CEK-17": [ + "CRY-09", + "CRY-09.3" ], - "MEA02.03": [ - "CPL-01.4" + "CEK-18": [ + "CRY-09" ], - "MEA03.04": [ - "CPL-01.4", - "CPL-01.5", - "IAO-05" + "CEK-19": [ + "CRY-09", + "CRY-09.3" ], - "MEA02.01": [ - "CPL-02", - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "CEK-20": [ + "CRY-09" ], - "MEA02.02": [ - "CPL-02", - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "CEK-21": [ + "CRY-09" ], - "MEA04.02": [ - "CPL-02", - "CPL-02.1" + "DSP-06": [ + "DCH-01.1" ], - "APO02.04": [ - "CPL-02.1" + "DCS-06": [ + "DCH-02" ], - "MEA04.01": [ - "CPL-03.1" + "DSP-04": [ + "DCH-02" ], - "BAI10.01": [ - "CFG-01" + "UEM-11": [ + "DCH-04.1", + "NET-17" ], - "BAI10.05": [ - "CFG-02.1", - "CFG-02.2" + "DCS-05": [ + "DCH-07", + "DCH-07.1", + "DCH-07.2" ], - "BAI10.04": [ - "CFG-02.2" + "LOG-08": [ + "DCH-09" ], - "DSS01.03": [ - "MON-01" + "DSP-16": [ + "DCH-18", + "PRI-05" ], - "DSS05.07": [ - "MON-01", - "MON-01.1", + "UEM-05": [ "END-01", - "VPM-01", - "VPM-06" - ], - "MEA01.01": [ - "MON-01" + "END-01.1" ], - "DSS06.05": [ - "MON-01.4", - "MON-03" + "UEM-09": [ + "END-04", + "END-04.7" ], - "APO14.03": [ - "DCH-01" + "UEM-10": [ + "END-05" ], - "APO14.09": [ - "DCH-01", - "DCH-18" + "HRS-01": [ + "HRS-01", + "HRS-04" ], - "DSS06.02": [ - "DCH-01", - "DCH-01.2", - "DCH-01.4", - "DCH-06.2" + "HRS-06": [ + "HRS-01.1", + "HRS-09" ], - "DSS06.06": [ - "DCH-01", - "DCH-01.2", - "DCH-01.4", - "DCH-13.2" + "HRS-09": [ + "HRS-03" ], - "APO11.02": [ - "DCH-22", - "OPS-03" + "HRS-13": [ + "HRS-03.1", + "HRS-04.2", + "HRS-05" ], - "APO11.03": [ - "DCH-22", - "OPS-03" + "HRS-07": [ + "HRS-04.2", + "HRS-05" ], - "APO11.04": [ - "DCH-22", - "OPS-03" + "HRS-02": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "APO11.05": [ - "DCH-22", - "OPS-03" + "HRS-08": [ + "HRS-05", + "HRS-05.1" ], - "APO14.06": [ - "DCH-22" + "HRS-03": [ + "HRS-05.1" ], - "APO14.07": [ - "DCH-22", - "DCH-22.1" + "HRS-10": [ + "HRS-06.1" ], - "BAI08.04": [ - "DCH-22" + "IAM-07": [ + "HRS-08", + "HRS-09.2", + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-15.6" ], - "DSS05.03": [ - "END-01", - "END-02" + "IAM-04": [ + "HRS-11" ], - "DSS05.01": [ - "END-04", - "END-04.1", - "END-04.7" + "IAM-03": [ + "IAC-01.3", + "IAC-16.1" ], - "APO07.01": [ - "HRS-01" + "IAM-13": [ + "IAC-02", + "IAC-03", + "IAC-04", + "IAC-05", + "IAC-06", + "IAC-10.1", + "IAC-10.2", + "IAC-21", + "WEB-06" ], - "APO07.04": [ - "HRS-01" + "IAM-06": [ + "IAC-07" ], - "APO07.05": [ - "HRS-01" + "IAM-12": [ + "IAC-09" ], - "APO07.06": [ - "HRS-01", - "HRS-10" + "IAM-14": [ + "IAC-10", + "IAC-10.1", + "IAC-10.2", + "WEB-06" ], - "APO01.08": [ - "HRS-03.2", - "HRS-13", - "HRS-13.1", - "PRM-08" + "IAM-15": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4", + "IAC-10.5", + "IAC-10.6", + "IAC-10.8", + "IAC-10.11" ], - "APO07.03": [ - "HRS-13", - "HRS-13.1", - "HRS-13.3", - "HRS-13.4" + "IAM-08": [ + "IAC-17" ], - "APO07.02": [ - "HRS-13.2" + "IAM-05": [ + "IAC-21" ], - "DSS05.04": [ - "IAC-08", - "IAC-20" + "UEM-06": [ + "IAC-24", + "IAC-24.1" ], - "DSS02.01": [ - "IRO-01", + "SEF-03": [ "IRO-02", - "IRO-03", "IRO-04" ], - "DSS02.02": [ - "IRO-02", - "IRO-09" - ], - "DSS02.03": [ - "IRO-02" - ], - "DSS02.04": [ + "SEF-06": [ "IRO-02" ], - "DSS02.05": [ + "SEF-07": [ "IRO-02", - "IRO-09" + "IRO-04" ], - "DSS02.06": [ - "IRO-02" + "SEF-08": [ + "IRO-04.1", + "IRO-10" ], - "DSS03.02": [ - "IRO-02" + "SEF-04": [ + "IRO-06" ], - "DSS03.01": [ - "IRO-02.4" + "SEF-09": [ + "IRO-10.2" ], - "DSS03.04": [ - "IRO-04.2", - "IRO-04.3" + "SEF-10": [ + "IRO-14" ], - "DSS03.05": [ - "IRO-04.3" + "AIS-05": [ + "IAO-02.2", + "TDA-09", + "TDA-09.3", + "TDA-09.5" ], - "DSS02.07": [ - "IRO-09" + "UEM-12": [ + "MDM-01" ], - "DSS03.03": [ - "IRO-13" + "UEM-13": [ + "MDM-05" ], - "MEA04.05": [ - "IAO-01" + "I&S-03": [ + "NET-01" ], - "MEA04.06": [ - "IAO-01", - "IAO-02" + "I&S-06": [ + "NET-06" ], - "BAI03.06": [ - "IAO-02", - "TDA-09" + "HRS-04": [ + "NET-14.5" ], - "BAI03.08": [ - "IAO-02", - "TDA-09" + "UEM-14": [ + "NET-14.7" ], - "MEA04.07": [ - "IAO-02" + "DCS-08": [ + "PES-03", + "PES-03.1" ], - "MEA04.08": [ - "IAO-02.4" + "LOG-13": [ + "PES-03.3" ], - "APO12.05": [ - "IAO-05", - "PRM-01", - "PRM-02.1", - "RSK-01", - "RSK-04.1" + "DCS-04": [ + "PES-04", + "PES-04.1" ], - "MEA04.09": [ - "IAO-05" + "DCS-10": [ + "PES-04", + "PES-04.1", + "PES-05" ], - "DSS05.02": [ - "NET-01" + "DCS-11": [ + "PES-05", + "PES-05.1" ], - "DSS01.04": [ - "PES-01", + "DCS-14": [ "PES-07", "PES-07.1", "PES-07.2", "PES-07.3", "PES-07.4", - "PES-07.5", - "PES-07.6", - "PES-08", - "PES-08.1", - "PES-08.2", - "PES-08.3", - "PES-09", - "PES-09.1" - ], - "DSS01.05": [ - "PES-01" + "PES-07.5" ], - "DSS05.05": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1", - "PES-03.4", - "PES-04" + "DCS-16": [ + "PES-12" ], - "DSS05.06": [ - "PES-12.2" + "DCS-13": [ + "PES-12.1" ], - "EDM02.01": [ - "PRM-01", - "PRM-02", - "PRM-03" + "DSP-08": [ + "PRI-01.11", + "TDA-09.6" ], - "EDM02.02": [ - "PRM-01", - "PRM-02", - "PRM-03" + "DSP-14": [ + "PRI-02" ], - "EDM02.03": [ - "PRM-01", - "PRM-02", - "PRM-03" + "DSP-12": [ + "PRI-02.1", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" ], - "EDM02.04": [ - "PRM-01", - "PRM-02", - "PRM-03" + "DSP-15": [ + "PRI-05.1", + "TDA-10" ], - "EDM04.01": [ - "PRM-01", - "PRM-02", - "PRM-03" + "DSP-11": [ + "PRI-06" ], - "EDM04.02": [ - "PRM-01", - "PRM-02", - "PRM-03" + "DSP-13": [ + "PRI-07", + "PRI-07.1", + "PRI-07.2", + "PRI-07.3" ], - "EDM04.03": [ - "PRM-01", - "PRM-02", - "PRM-03" + "AIS-04": [ + "PRM-07", + "TDA-01", + "TDA-02.3", + "TDA-06", + "TDA-08.1", + "TDA-09" ], - "APO05.01": [ - "PRM-01" + "CEK-07": [ + "RSK-01", + "RSK-01.1", + "RSK-02.1", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.1" ], - "APO05.02": [ - "PRM-01" + "GRC-02": [ + "RSK-01" ], - "APO05.03": [ - "PRM-01" + "DSP-09": [ + "RSK-10" ], - "APO05.04": [ - "PRM-01" + "DCS-18": [ + "SEA-01", + "SEA-01.2", + "SEA-01.3" ], - "APO05.05": [ - "PRM-01" + "DSP-07": [ + "SEA-01", + "TDA-09.6" ], - "BAI01.05": [ - "PRM-01", - "PRM-03" + "I&S-09": [ + "SEA-03" ], - "BAI01.08": [ - "PRM-01", - "PRM-02.1" + "LOG-06": [ + "SEA-20" ], - "BAI01.09": [ - "PRM-01", - "PRM-02.1" + "HRS-11": [ + "SAT-01" ], - "BAI02.02": [ - "PRM-01" + "HRS-12": [ + "SAT-02" ], - "BAI02.04": [ - "PRM-01", - "PRM-07" + "DCS-12": [ + "SAT-03" ], - "APO02.06": [ - "PRM-01.1" + "STA-09": [ + "TDA-04.2" ], - "APO02.03": [ - "PRM-01.2" + "AIS-06": [ + "TDA-06", + "TDA-06.2", + "TDA-06.3", + "TDA-07", + "TDA-08" ], - "BAI02.03": [ - "PRM-02.1" + "I&S-05": [ + "TDA-08" ], - "BAI11.06": [ - "PRM-02.1", - "PRM-04" + "I&S-07": [ + "TDA-08.1" ], - "APO06.01": [ - "PRM-03" + "AIS-07": [ + "TDA-15" ], - "APO06.02": [ - "PRM-03" + "STA-08": [ + "TPM-01.1" ], - "APO06.03": [ - "PRM-03" + "STA-16": [ + "TPM-04.1" ], - "APO06.04": [ - "PRM-03" + "STA-04": [ + "TPM-05", + "TPM-05.4" ], - "APO06.05": [ - "PRM-03" + "STA-11": [ + "TPM-05", + "TPM-05.2" ], - "EDM03.01": [ - "PRM-04", - "RSK-01" + "STA-02": [ + "TPM-05.4" ], - "BAI01.01": [ - "PRM-04", - "PRM-07" + "STA-03": [ + "TPM-05.4" ], - "BAI01.02": [ - "PRM-04", - "PRM-07" + "STA-05": [ + "TPM-05.4" ], - "BAI01.04": [ - "PRM-04", - "PRM-05", - "PRM-06" - ], - "BAI03.01": [ - "PRM-04", - "PRM-05", - "PRM-06" - ], - "BAI03.02": [ - "PRM-04", - "TDA-01" - ], - "BAI11.01": [ - "PRM-04" - ], - "BAI11.02": [ - "PRM-04" - ], - "BAI11.03": [ - "PRM-04" - ], - "BAI11.04": [ - "PRM-04" + "STA-06": [ + "TPM-05.4" ], - "BAI11.05": [ - "PRM-04" + "STA-07": [ + "TPM-05.4" ], - "BAI11.07": [ - "PRM-04" + "STA-10": [ + "TPM-08", + "TPM-10" ], - "BAI11.08": [ - "PRM-04" + "STA-12": [ + "TPM-08" ], - "BAI11.09": [ - "PRM-04" + "STA-13": [ + "TPM-08" ], - "APO01.10": [ - "PRM-05", - "PRM-06" + "STA-14": [ + "TPM-08" ], - "BAI02.01": [ - "PRM-05", - "PRM-06" + "STA-15": [ + "TPM-08" ], - "BAI03.03": [ - "PRM-05", - "TDA-01.1", - "TDA-02" + "TVM-05": [ + "THR-03", + "VPM-06.1" ], - "BAI03.04": [ - "PRM-05", - "TPM-03.1" + "TVM-06": [ + "THR-03", + "VPM-06.1" ], - "BAI04.03": [ - "PRM-06", - "PRM-07" + "TVM-10": [ + "THR-10", + "VPM-04" ], - "BAI03.09": [ - "PRM-07" + "TVM-03": [ + "VPM-01.1", + "VPM-03" ], - "BAI03.11": [ - "PRM-07", - "TDA-01.1" + "TVM-09": [ + "VPM-03" ], - "BAI05.01": [ - "PRM-07" + "TVM-08": [ + "VPM-04" ], - "BAI05.07": [ - "PRM-07" + "TVM-11": [ + "VPM-05.1" ], - "BAI09.03": [ - "PRM-07", - "SEA-07.1" + "TVM-07": [ + "VPM-07" + ] + }, + "general-csa-iot-2": { + "GVN-01": [ + "GOV-01", + "GOV-02", + "GOV-04", + "GOV-04.1", + "EMB-01", + "HRS-03" ], - "EDM03.02": [ - "RSK-01" + "GVN-02": [ + "GOV-01", + "GOV-02", + "CPL-01", + "EMB-01", + "SEA-01", + "SEA-01.1", + "SEA-02" ], - "EDM03.03": [ - "RSK-01" + "POL-03": [ + "GOV-02", + "EMB-01" ], - "APO12.01": [ + "RSM-01": [ + "GOV-16.1", + "GOV-16.2", "RSK-01", "RSK-01.1", + "RSK-02", + "RSK-02.1", "RSK-03", - "RSK-03.1", - "RSK-09", - "RSK-09.1", - "RSK-10" - ], - "APO12.02": [ - "RSK-01", "RSK-04", - "RSK-09", - "RSK-09.1", - "RSK-10" - ], - "APO12.03": [ - "RSK-01", - "RSK-04.1", "RSK-05", - "RSK-08", - "RSK-09", - "RSK-09.1", - "RSK-10" - ], - "APO12.04": [ - "RSK-01", - "RSK-01.1", - "RSK-03.1", - "RSK-09", - "RSK-09.1", - "RSK-10" - ], - "APO12.06": [ - "RSK-01", "RSK-06", "RSK-06.1", - "RSK-06.4" - ], - "APO13.02": [ - "RSK-06.4" - ], - "APO03.01": [ - "SEA-01", - "SEA-01.1", - "SEA-02", - "SEA-03" - ], - "APO03.02": [ - "SEA-01", - "SEA-02", - "TDA-01", - "TDA-01.1", - "TDA-06" - ], - "APO03.03": [ - "SEA-01", - "SEA-01.1", - "SEA-02", - "TDA-01", - "TDA-01.1" - ], - "APO03.04": [ - "SEA-01", - "SEA-02" - ], - "APO03.05": [ - "SEA-01", - "SEA-02" - ], - "APO04.05": [ - "SEA-01", - "SEA-02", - "SEA-03" - ], - "APO04.02": [ - "SEA-02" - ], - "APO04.03": [ - "SEA-02" + "RSK-08" ], - "APO04.04": [ - "SEA-02" + "SAP-10": [ + "AAT-01", + "AAT-16", + "AAT-16.11" ], - "APO04.06": [ - "SEA-02" + "ASM-02": [ + "AST-01" ], - "APO14.02": [ - "SEA-02.1" + "ASM-04": [ + "AST-01.3" ], - "DSS01.01": [ - "OPS-01.1" + "ASM-01": [ + "AST-02" ], - "APO01.11": [ - "OPS-03" + "SNT-04": [ + "AST-02", + "AST-02.2", + "AST-02.9", + "EMB-13" ], - "APO08.05": [ - "OPS-03" + "DAT-03": [ + "AST-03.2", + "AST-04", + "SEA-08.1" ], - "APO09.02": [ - "OPS-03" + "PHY-01": [ + "AST-07", + "AST-08", + "EMB-04", + "EMB-05", + "PES-01", + "PES-03", + "PES-05", + "PES-05.1", + "PES-05.2", + "PES-12" ], - "APO09.03": [ - "OPS-03", - "TPM-08" + "POL-04": [ + "AST-09", + "DCH-08", + "DCH-21", + "PRM-07", + "SEA-07.1" ], - "APO09.04": [ - "OPS-03", - "TPM-08" + "SWS-01": [ + "AST-14.1", + "CFG-02" ], - "APO09.05": [ - "OPS-03", - "TPM-08" + "SWS-03": [ + "AST-14.1", + "CFG-02.5" ], - "BAI03.05": [ - "TDA-01.1", - "TDA-02" + "IOT-05": [ + "AST-15", + "EMB-04", + "EMB-06" ], - "BAI03.10": [ - "TDA-01.1" + "IOT-09": [ + "AST-18", + "EMB-18" ], - "BAI04.01": [ - "TDA-01.1" + "GVN-03": [ + "BCD-01" ], - "BAI05.02": [ - "TDA-01.1" + "OPA-05": [ + "BCD-01.2", + "BCD-02.2", + "CPL-01", + "TPM-11" ], - "BAI05.03": [ - "TDA-01.1" + "OPA-03": [ + "BCD-04", + "BCD-12.2", + "CAP-06" ], - "BAI05.04": [ - "TDA-01.1" + "OPA-06": [ + "BCD-04", + "BCD-12", + "BCD-12.2", + "NET-01", + "SEA-02" ], - "BAI05.05": [ - "TDA-01.1" + "SNT-03": [ + "CAP-01", + "CAP-04", + "MON-01", + "EMB-05" ], - "BAI05.06": [ - "TDA-01.1" + "OPA-08": [ + "CAP-02", + "MON-01.3", + "NET-01", + "NET-02.1" ], - "BAI06.01": [ - "TDA-01.1" + "OPA-09": [ + "CAP-02", + "NET-02.1" ], - "BAI07.07": [ - "TDA-01.1" + "CCM-02": [ + "CHG-01", + "CHG-02", + "CFG-01" ], - "BAI08.01": [ - "TDA-01.1" + "CCM-08": [ + "CHG-01", + "CHG-02", + "CHG-02.2", + "CHG-02.3", + "CFG-01" ], - "BAI08.02": [ - "TDA-01.1" + "DAT-04": [ + "CHG-01", + "CRY-05", + "DCH-19" ], - "BAI08.03": [ - "TDA-01.1" + "IAM-22": [ + "CHG-01", + "CHG-02", + "IAC-12" ], - "BAI03.12": [ - "TDA-02.3" + "GVN-05": [ + "CHG-02", + "CHG-02.1", + "CHG-02.4", + "DCH-23", + "EMB-05" ], - "BAI07.04": [ - "TDA-07", - "TDA-08" + "CLS-01": [ + "CLD-01", + "CLD-02", + "CRY-01", + "CRY-08", + "CRY-09", + "IAC-10.2" ], - "BAI03.07": [ - "TDA-09" + "CLS-05": [ + "CLD-01", + "CLD-02", + "CFG-02", + "CFG-02.5", + "SEA-01", + "SEA-01.1" ], - "APO10.01": [ - "TPM-01" + "CLS-07": [ + "CLD-04", + "MON-01.3", + "MON-01.16" ], - "APO10.02": [ - "TPM-01" + "CLS-12": [ + "CLD-04", + "CLD-11", + "CLD-12", + "NET-04", + "SEA-08.1" ], - "APO10.03": [ - "TPM-01", - "TPM-04.4", - "TPM-05", - "TPM-06" + "CLS-13": [ + "CLD-04" ], - "APO10.04": [ - "TPM-01", - "TPM-02", - "TPM-03", - "TPM-03.3", - "TPM-04.1", - "TPM-09", - "TPM-10" + "CLS-02": [ + "CLD-12", + "CFG-03.3" ], - "APO10.05": [ - "TPM-01", - "TPM-08" + "CLS-04": [ + "CPL-01", + "IAO-03.2", + "PRI-07.1", + "TPM-05" ], - "DSS01.02": [ - "TPM-01" - ] - }, - "general-coso-2013": { - "1": [ - "GOV-01.1", - "GOV-04", + "GVN-04": [ + "CPL-01", + "CPL-01.1", "CPL-02", - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-07.1" - ], - "2": [ - "GOV-01", - "GOV-01.1", - "GOV-01.2", - "GOV-01.3", - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "HRS-02", - "HRS-03", - "HRS-03.2" - ], - "3": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "HRS-03", - "HRS-03.2", - "PRM-06" - ], - "4": [ - "HRS-01", - "HRS-02.1", - "HRS-03.1", - "HRS-03.2", - "HRS-04", - "HRS-04.1", - "HRS-04.2", - "SAT-01" - ], - "5": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "HRS-01", - "HRS-03.2", - "HRS-06", - "HRS-06.1", - "HRS-07", - "HRS-07.1" - ], - "6": [ - "GOV-08", - "GOV-09", - "PRM-01", - "PRM-04", - "PRM-06" + "CPL-02.1", + "CPL-03", + "CPL-03.2" ], - "7": [ - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-07", - "RSK-08", - "RSK-09", - "RSK-09.1", + "LGL-01": [ + "CPL-01", + "EMB-14", + "EMB-15", + "PRM-05", "RSK-10" ], - "8": [ - "RSK-01", - "RSK-03", - "TPM-01", - "TPM-03.1", - "TPM-04", - "TPM-04.3", - "THR-01", - "THR-02", - "THR-04", - "THR-10", - "THR-11" - ], - "9": [ - "CHG-01", - "CHG-02", - "CHG-02.2", - "CHG-02.3", - "CHG-03", - "PRM-01", + "LGL-03": [ + "CPL-01", + "CPL-02", + "PRM-05", "PRM-06", - "TPM-04.1", - "TPM-08", - "TPM-10" + "PRM-07", + "RSK-10" ], - "10": [ - "GOV-08", - "GOV-09", + "LGL-04": [ + "CPL-01", + "PRI-01", + "PRM-05", "PRM-06", - "SEA-01", - "SEA-01.1", - "SEA-02", - "OPS-01.1", - "OPS-02" + "PRM-07" ], - "11": [ - "PRM-04", + "LGL-05": [ + "CPL-01", "PRM-05", "PRM-06", "PRM-07", - "SEA-01", - "SEA-01.1", - "TDA-01", - "TDA-01.1", - "TDA-02" - ], - "12": [ - "GOV-01", - "GOV-02", - "GOV-03", - "OPS-01.1", - "TPM-05.4" - ], - "13": [ - "AST-04", - "DCH-01", - "DCH-01.1", - "DCH-02", - "DCH-22", - "RSK-06", - "OPS-03" + "TPM-05" ], - "14": [ - "GOV-05", - "GOV-05.1", - "GOV-05.2", + "LGL-06": [ "CPL-01", - "CPL-02", - "HRS-03", - "PRM-01", "PRM-05", - "SEA-01", - "SEA-02.1", - "OPS-01", - "OPS-01.1" + "PRM-06", + "PRM-07", + "TPM-05" ], - "15": [ - "GOV-06", + "LGL-07": [ "CPL-01", - "CPL-02", - "IRO-10", - "IRO-14", - "PRI-14" + "PRM-05", + "PRM-06", + "PRM-07", + "TPM-05" ], - "16": [ - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "CPL-03", - "CPL-03.2", - "CPL-04", - "IAO-01", - "IAO-02", - "IAO-02.2", - "IAO-04", - "IAO-06", - "PRM-03", - "PRM-04", + "LGL-08": [ + "CPL-01", + "DCH-01", + "DCH-19", + "DCH-25", "PRM-05", "PRM-06", - "RSK-01", - "RSK-09" + "TPM-05" ], - "17": [ - "CPL-01.1", - "IAO-04", - "IAO-05", - "RSK-06", - "TDA-15", - "TPM-09", - "VPM-02", - "VPM-04" - ] - }, - "general-csa-cmm-4-1-0": { - "GRC-01": [ - "GOV-01", - "GOV-02" + "IOT-02": [ + "CFG-02", + "CFG-02.5" ], - "GRC-05": [ - "GOV-01" + "IOT-03": [ + "CFG-02", + "END-06.1" ], - "A&A-01": [ - "GOV-02", - "GOV-03" + "IOT-07": [ + "CFG-02", + "EMB-14", + "EMB-18" ], - "AIS-01": [ - "GOV-02", - "GOV-03", - "TDA-01" + "SNT-01": [ + "CFG-02", + "NET-01", + "NET-02" ], - "BCR-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "SWS-08": [ + "CFG-02" ], - "CCC-01": [ - "GOV-02", - "GOV-03", - "CHG-01" + "CCM-03": [ + "CFG-02.2", + "CFG-06", + "EMB-05" ], - "CEK-01": [ - "GOV-02", - "GOV-03", - "CRY-01" + "SWS-02": [ + "CFG-02.2" ], - "DCS-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "SAP-09": [ + "CFG-02.5", + "EMB-19" ], - "DSP-01": [ - "GOV-02" + "IAM-07": [ + "CFG-07" ], - "IAM-01": [ - "GOV-02", - "GOV-03", - "IAC-01", - "WEB-06" + "MON-01": [ + "MON-01", + "MON-11.3", + "MON-16" ], - "IAM-02": [ - "GOV-02", - "GOV-03", - "IAC-01" + "MON-03": [ + "MON-01", + "MON-01.2", + "MON-01.4", + "MON-01.12", + "MON-03" ], - "IPY-01": [ - "GOV-02", - "GOV-03", - "CLD-01" + "MON-05": [ + "MON-01", + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-08.3" ], - "I&S-01": [ - "GOV-02", - "GOV-03", - "SEA-01", - "SEA-13.1" + "MON-07": [ + "MON-01", + "MON-02", + "MON-02.2", + "MON-02.7" ], - "LOG-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "OPA-04": [ + "MON-01.1", + "MON-01.2", + "MON-01.3", + "MON-01.13" ], - "SEF-01": [ - "GOV-02", - "GOV-03", - "IRO-01" + "CLS-08": [ + "MON-01.4", + "MON-01.8", + "EMB-12", + "EMB-13", + "EMB-16", + "EMB-17" ], - "SEF-02": [ - "GOV-02", - "GOV-03", - "TPM-01" + "MON-08": [ + "MON-01.5", + "NET-08.2" ], - "STA-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "SAP-06": [ + "MON-01.7", + "MON-16", + "END-06", + "END-07" ], - "TVM-01": [ - "GOV-02", - "GOV-03", - "VPM-01" + "MON-06": [ + "MON-03", + "MON-08.1" ], - "TVM-02": [ - "GOV-02", - "GOV-03", - "END-01" + "MON-04": [ + "MON-08", + "MON-08.2", + "IAC-08" ], - "TVM-04": [ - "GOV-02", - "GOV-03", - "THR-01" + "IAM-08": [ + "MON-11.3", + "MON-16", + "CRY-09", + "IAC-07", + "IRO-02", + "IRO-02.1", + "IRO-02.6" ], - "UEM-01": [ - "GOV-02", - "GOV-03", - "END-01" + "MON-09": [ + "MON-11.3", + "IRO-03" ], - "CCC-08": [ - "GOV-02.1", - "CFG-02.2", - "CFG-02.7" + "MON-11": [ + "MON-11.3", + "IRO-03", + "THR-03" ], - "GRC-04": [ - "GOV-02.1" + "MON-10": [ + "MON-16" ], - "GRC-03": [ - "GOV-03" + "COM-07": [ + "CRY-01", + "CRY-03", + "EMB-11" ], - "GRC-06": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "HRS-03", - "TPM-05.4" + "COM-08": [ + "CRY-01", + "CRY-03" ], - "AIS-03": [ - "GOV-05" + "COM-09": [ + "CRY-01", + "CRY-03" ], - "DCS-17": [ - "GOV-05" + "IOT-10": [ + "CRY-01", + "CRY-03", + "NET-03" ], - "SEF-05": [ - "GOV-05" + "SAP-07": [ + "CRY-01", + "CRY-03", + "CRY-04" ], - "TVM-12": [ - "GOV-05" + "SWS-11": [ + "CRY-03" ], - "GRC-08": [ - "GOV-07" + "SWS-07": [ + "CRY-07", + "NET-12.1" ], - "DCS-09": [ - "AST-01.3", - "IAC-04" + "IAM-10": [ + "CRY-08", + "CRY-09", + "CRY-09.3" ], - "DCS-07": [ - "AST-02" + "SDV-01": [ + "CRY-08", + "CRY-09" ], - "DSP-03": [ - "AST-02" + "IAM-11": [ + "CRY-09", + "CRY-09.3" ], - "UEM-04": [ - "AST-02" + "IAM-12": [ + "CRY-09" ], - "DSP-05": [ - "AST-04" + "IAM-13": [ + "CRY-09", + "CRY-09.3" ], - "I&S-08": [ - "AST-04", - "AST-31.2", - "SEA-02" + "IAM-14": [ + "CRY-09" ], - "LOG-07": [ - "AST-04.1", - "CPL-01.2" + "IAM-15": [ + "CRY-09" ], - "DCS-03": [ - "AST-05", - "AST-05.1", - "BCD-11.6", - "DCH-25" + "IAM-16": [ + "CRY-09", + "IAC-08", + "OPS-03" ], - "DCS-02": [ - "AST-09", - "DCH-08", - "DCH-09" + "SWS-10": [ + "CRY-09" ], - "DSP-02": [ - "AST-09" + "DAT-01": [ + "DCH-02", + "DCH-05", + "NET-04.5" ], - "HRS-05": [ - "AST-10" + "GVN-06": [ + "DCH-02", + "DCH-02.1", + "IRO-04.1", + "NET-04.5" ], - "BCR-02": [ - "BCD-01", - "BCD-02", - "RSK-02", - "RSK-02.1", - "RSK-08" + "VLN-04": [ + "EMB-01", + "VPM-01", + "VPM-02", + "VPM-03", + "VPM-06", + "VPM-06.2" ], - "BCR-03": [ - "BCD-01", - "BCD-01.4", - "BCD-01.5", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3", - "BCD-10.3", - "BCD-11.7", - "BCD-12.2", - "BCD-12.4" + "SAP-03": [ + "EMB-08" ], - "BCR-05": [ - "BCD-01", - "DCH-01.4", - "DCH-03.1" + "ASM-03": [ + "EMB-09" ], - "BCR-09": [ - "BCD-01", - "BCD-06", - "BCD-06.1", - "BCD-06.2" + "CCM-01": [ + "EMB-10", + "SEA-07.1" ], - "BCR-06": [ - "BCD-01.1", - "BCD-01.2", - "BCD-04", - "BCD-11.5" + "IOT-08": [ + "EMB-10", + "EMB-14" ], - "BCR-07": [ - "BCD-01.6" + "COM-01": [ + "EMB-11" ], - "BCR-10": [ - "BCD-04" + "COM-10": [ + "EMB-12" ], - "DCS-15": [ - "BCD-04", - "PES-07" + "COM-11": [ + "EMB-13" ], - "BCR-04": [ - "BCD-06", - "BCD-06.1" + "GVN-09": [ + "EMB-14", + "EMB-15" ], - "BCR-08": [ - "BCD-11", - "BCD-11.1", - "BCD-11.4", - "BCD-11.5" + "RSM-03": [ + "EMB-14", + "RSK-08", + "TPM-03.2" ], - "BCR-11": [ - "BCD-11.7", - "BCD-12.2" + "GVN-10": [ + "EMB-15" ], - "I&S-02": [ - "CAP-01", - "CAP-03" + "IAM-03": [ + "EMB-16" ], - "CCC-03": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-03" + "IOT-04": [ + "EMB-17" ], - "CEK-06": [ - "CHG-01", - "CHG-05" + "IOT-06": [ + "EMB-18" ], - "CCC-02": [ - "CHG-02", - "CHG-02.2" + "SAP-02": [ + "EMB-19" ], - "CCC-05": [ - "CHG-02", - "CHG-03", - "CHG-05" + "CLS-14": [ + "END-04", + "END-07" ], - "CCC-09": [ - "CHG-02", - "CHG-02.4", - "CHG-04.1", - "CFG-02.8" - ], - "CEK-05": [ - "CHG-02" + "IAM-17": [ + "IAC-01", + "IAC-04" ], - "CCC-04": [ - "CHG-02.1", - "CHG-02.4", - "CHG-04", - "CHG-04.1", - "CHG-04.4" + "CLS-09": [ + "IAC-01.2" ], - "CCC-06": [ - "CHG-02.4", - "CFG-02", - "CFG-02.1", - "CFG-02.2" + "CLS-11": [ + "IAC-06" ], - "IPY-04": [ - "CLD-01", - "IAO-03.2", - "PRI-07.1", - "TPM-05" + "IAM-18": [ + "IAC-10", + "IAC-10.1" ], - "AIS-08": [ - "CLD-04" + "IAM-21": [ + "IAC-10", + "IAC-10.1" ], - "IPY-02": [ - "CLD-04" + "IAM-19": [ + "IAC-10.1" ], - "IPY-03": [ - "CLD-04", - "CLD-07" + "IAM-20": [ + "IAC-10.8" ], - "DSP-19": [ - "CLD-09", - "DCH-19" + "IAM-02": [ + "IAC-16", + "IAC-17" ], - "DSP-17": [ - "CLD-10", - "DCH-01", - "DCH-02.1", - "DCH-06.2", - "DCH-06.4", - "DCH-13.3", - "IAC-20.1", - "IAO-03.2", - "PRI-05.4", - "SAT-03.3" + "IAM-04": [ + "IAC-16", + "IAC-20.3", + "IAC-21.2" ], - "A&A-04": [ - "CPL-01" + "IAM-06": [ + "IAC-21" ], - "GRC-07": [ - "CPL-01", - "CPL-01.2" + "IAM-01": [ + "IAC-29" ], - "A&A-05": [ - "CPL-01.1", - "CPL-02", - "CPL-02.1", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "CPL-04" + "IMT-01": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-07", + "IRO-08", + "TPM-05", + "TPM-11" ], - "A&A-06": [ - "CPL-01.1", - "IAO-05", - "RSK-01.1", - "RSK-02.1", - "RSK-04.1", - "RSK-06.1", - "RSK-06.4" + "IAM-09": [ + "IRO-02", + "IRO-03", + "IRO-04" ], - "A&A-02": [ - "CPL-02", - "CPL-02.2", - "CPL-03", - "CPL-03.1" + "MON-02": [ + "IRO-02", + "IRO-03" ], - "CEK-09": [ - "CPL-02", - "CPL-02.1", - "CPL-03", - "CPL-03.1", - "CPL-03.2" + "IOT-01": [ + "IAO-01", + "IAO-02.2", + "IAO-06", + "IAO-07" ], - "A&A-03": [ - "CPL-03" + "SET-01": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.2" ], - "DSP-18": [ - "CPL-05", - "CPL-05.1", - "CPL-05.2", - "DCH-03.1", - "PRI-07.4", - "PRI-07.5", - "PRI-14.1", - "PRI-14.2" + "OPA-01": [ + "MNT-01", + "MNT-02", + "MNT-03", + "MNT-03.1" ], - "UEM-03": [ - "CFG-01" + "OPA-02": [ + "MNT-03.3" ], - "UEM-07": [ - "CFG-01", - "CFG-02" + "SAP-05": [ + "MDM-01", + "MDM-03", + "MDM-06", + "MDM-07" ], - "AIS-02": [ - "CFG-02", - "CFG-02.4", - "CFG-02.5", - "CFG-02.7", - "CFG-02.9", - "CFG-03", - "CFG-03.1" + "IAM-05": [ + "MDM-09" ], - "I&S-04": [ - "CFG-02" + "OPA-07": [ + "NET-01", + "SEA-02" ], - "CCC-07": [ - "CFG-02.2" + "SNT-02": [ + "NET-01.1" ], - "UEM-02": [ - "CFG-03.3" + "SWS-04": [ + "NET-03.1", + "SEA-01", + "SEA-02" ], - "IAM-09": [ - "CFG-05.2", - "MON-01.15", - "MON-03.3", - "IAC-08", - "IAC-09.5", - "IAC-16", - "IAC-17", - "IAC-21.1", - "IAC-21.3", - "IAC-21.4", - "IAC-21.5", - "VPM-06.3" + "SWS-05": [ + "NET-04", + "NET-04.1" ], - "LOG-03": [ - "MON-01.2", - "MON-01.4", - "MON-01.8" + "SAP-01": [ + "NET-06", + "NET-06.1", + "NET-06.4" ], - "LOG-05": [ - "MON-01.8" + "CCM-06": [ + "NET-06.4", + "TDA-14.1", + "VPM-05.1" ], - "IAM-10": [ - "MON-01.15", - "MON-03.3", - "IAC-08", - "IAC-09.5", - "IAC-16", - "IAC-16.1", - "IAC-17" + "SWS-09": [ + "NET-11" ], - "IAM-11": [ - "MON-01.15", - "MON-03.3", - "IAC-03", - "IAC-09.5", - "IAC-16", - "IAC-16.1", - "IAC-17", - "TPM-01", - "TPM-03", - "TPM-04" + "SWS-06": [ + "NET-15.5", + "VPM-08" ], - "LOG-09": [ - "MON-03" + "DAT-02": [ + "NET-17" ], - "LOG-12": [ - "MON-03" + "LGL-02": [ + "PRM-04", + "PRM-05", + "PRM-06", + "PRM-07" ], - "LOG-02": [ - "MON-08" + "RSM-02": [ + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-02.1", + "RSK-05", + "RSK-06", + "RSK-06.1" ], - "LOG-10": [ - "MON-08" + "SDV-02": [ + "RSK-09", + "TDA-04.2" ], - "LOG-04": [ - "MON-08.2", - "MON-10" + "GVN-07": [ + "RSK-10" ], - "LOG-14": [ - "MON-11.3", - "MON-16", - "IRO-03" + "GVN-08": [ + "RSK-10" ], - "CEK-02": [ - "CRY-01", - "HRS-03", - "HRS-12" + "CCM-05": [ + "SEA-07.1" ], - "CEK-03": [ - "CRY-01", - "CRY-03", - "CRY-05" + "SET-05": [ + "SEA-07.1", + "THR-06" ], - "CEK-04": [ - "CRY-01", - "DCH-01" + "TRN-01": [ + "SAT-01", + "SAT-03" ], - "DSP-10": [ - "CRY-01", - "CRY-03", - "DCH-01", - "DCH-14", - "DCH-14.2", - "DCH-17" + "TRN-02": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "LOG-11": [ - "CRY-01", - "CRY-08", - "CRY-09" + "SET-06": [ + "TDA-01", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5", + "TDA-15" ], - "UEM-08": [ - "CRY-05", - "CRY-05.1" + "SDV-07": [ + "TDA-02", + "TDA-02.3", + "TDA-09", + "TDA-09.1", + "TDA-09.5" ], - "CEK-08": [ - "CRY-08", - "CRY-09" + "SDV-05": [ + "TDA-06", + "TDA-12" ], - "CEK-10": [ - "CRY-09", - "CRY-09.4" + "SDV-06": [ + "TDA-06.2" ], - "CEK-11": [ - "CRY-09", - "CRY-09.4" + "SDV-03": [ + "TDA-06.3", + "TDA-12" ], - "CEK-12": [ - "CRY-09", - "CRY-09.3", - "CRY-09.4" + "SDV-04": [ + "TDA-09.2", + "TDA-09.3" ], - "CEK-13": [ - "CRY-09", - "CRY-09.3" + "SET-02": [ + "TDA-09.5", + "VPM-07", + "VPM-07.1" ], - "CEK-14": [ - "CRY-09", - "CRY-09.3" + "POL-01": [ + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.1", + "TPM-09", + "TPM-11" ], - "CEK-15": [ - "CRY-09", - "CRY-09.3", - "CRY-09.4" + "POL-02": [ + "TPM-01", + "TPM-03", + "TPM-04", + "TPM-04.4", + "TPM-05", + "TPM-06", + "TPM-08" ], - "CEK-16": [ - "CRY-09", - "CRY-09.3" + "TRN-03": [ + "THR-06" ], - "CEK-17": [ - "CRY-09", - "CRY-09.3" + "CLS-06": [ + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-04", + "VPM-04.1", + "VPM-05", + "VPM-05.1", + "VPM-05.4" ], - "CEK-18": [ - "CRY-09" + "VLN-01": [ + "VPM-01", + "VPM-05", + "VPM-05.1" ], - "CEK-19": [ - "CRY-09", - "CRY-09.3" + "VLN-02": [ + "VPM-01.1", + "VPM-05.1" ], - "CEK-20": [ - "CRY-09" + "VLN-03": [ + "VPM-04", + "VPM-05.4" ], - "CEK-21": [ - "CRY-09" + "CCM-07": [ + "VPM-05", + "VPM-05.1", + "VPM-05.4" ], - "DSP-06": [ - "DCH-01.1" + "SET-04": [ + "VPM-07", + "VPM-07.1" ], - "DCS-06": [ - "DCH-02" + "SET-03": [ + "VPM-07.1", + "VPM-10" + ] + }, + "general-cr-cmm-2026": { + "CR1.1.4": [ + "AST-01.1", + "TPM-02" ], - "DSP-04": [ - "DCH-02" + "CR5.1.1": [ + "BCD-01" ], - "UEM-11": [ - "DCH-04.1", - "NET-17" + "CR5.2.1": [ + "BCD-01.1" ], - "DCS-05": [ - "DCH-07", - "DCH-07.1", - "DCH-07.2" + "CR5.1.2": [ + "BCD-01.7" ], - "LOG-08": [ - "DCH-09" + "CR1.1.5": [ + "BCD-02" ], - "DSP-16": [ - "DCH-18", - "PRI-05" + "CR10.1.1": [ + "BCD-02.2" ], - "UEM-05": [ - "END-01", - "END-01.1" + "CR6.3.1": [ + "BCD-03.1" ], - "UEM-09": [ - "END-04", - "END-04.7" + "CR7.2.1": [ + "BCD-03.2" ], - "UEM-10": [ - "END-05" + "CR7.2.2": [ + "BCD-04" ], - "HRS-01": [ - "HRS-01", - "HRS-04" + "CR7.2.8": [ + "BCD-04.1" ], - "HRS-06": [ - "HRS-01.1", - "HRS-09" + "CR7.2.13": [ + "BCD-06" ], - "HRS-09": [ - "HRS-03" + "CR5.1.9": [ + "BCD-07" ], - "HRS-13": [ - "HRS-03.1", - "HRS-04.2", - "HRS-05" + "CR10.2.5": [ + "BCD-09" ], - "HRS-07": [ - "HRS-04.2", - "HRS-05" + "CR5.2.6": [ + "BCD-10.4" ], - "HRS-02": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "CR10.4.4": [ + "BCD-11.1", + "BCD-13.1" ], - "HRS-08": [ - "HRS-05", - "HRS-05.1" + "CR10.2.6": [ + "BCD-11.3", + "BCD-12" ], - "HRS-03": [ - "HRS-05.1" + "CR10.2.4": [ + "BCD-11.8", + "BCD-14" ], - "HRS-10": [ - "HRS-06.1" + "CR2.2.1": [ + "MON-02.1" ], - "IAM-07": [ - "HRS-08", - "HRS-09.2", - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "IAC-15.6" + "CR3.1.1": [ + "MON-16.2" ], - "IAM-04": [ - "HRS-11" + "CR4.1.7": [ + "IRO-02.3" ], - "IAM-03": [ - "IAC-01.3", - "IAC-16.1" + "CR6.3.2": [ + "IRO-05.1" ], - "IAM-13": [ - "IAC-02", - "IAC-03", - "IAC-04", - "IAC-05", - "IAC-06", - "IAC-10.1", - "IAC-10.2", - "IAC-21", - "WEB-06" + "CR6.2.6": [ + "IRO-06", + "VPM-10" ], - "IAM-06": [ - "IAC-07" + "CR4.1.5": [ + "NET-01.1" ], - "IAM-12": [ - "IAC-09" + "CR3.1.6": [ + "PRM-02.1" ], - "IAM-14": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2", - "WEB-06" + "CR1.1.1": [ + "RSK-08" ], - "IAM-15": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4", - "IAC-10.5", - "IAC-10.6", - "IAC-10.8", - "IAC-10.11" + "CR4.3.1": [ + "SEA-01", + "SEA-01.3" ], - "IAM-08": [ - "IAC-17" + "CR4.3.6": [ + "SEA-03" ], - "IAM-05": [ - "IAC-21" + "CR4.1.3": [ + "SEA-14" ], - "UEM-06": [ - "IAC-24", - "IAC-24.1" + "CR6.2.2": [ + "SAT-02.1" ], - "SEF-03": [ - "IRO-02", - "IRO-04" + "CR8.3.1": [ + "TDA-02.10" ], - "SEF-06": [ - "IRO-02" + "CR3.1.2": [ + "TDA-06.2" ], - "SEF-07": [ - "IRO-02", - "IRO-04" + "CR8.1.2": [ + "TDA-09" ], - "SEF-08": [ - "IRO-04.1", - "IRO-10" + "CR5.3.2": [ + "TDA-17.1", + "TPM-01.1" ], - "SEF-04": [ - "IRO-06" + "CR7.3.6": [ + "TPM-11" ], - "SEF-09": [ - "IRO-10.2" + "CR3.3.2": [ + "THR-02" ], - "SEF-10": [ - "IRO-14" + "CR2.2.4": [ + "THR-07" ], - "AIS-05": [ - "IAO-02.2", - "TDA-09", - "TDA-09.3", - "TDA-09.5" + "CR2.2.6": [ + "THR-11" ], - "UEM-12": [ - "MDM-01" + "CR8.2.1": [ + "VPM-05.6" ], - "UEM-13": [ - "MDM-05" + "CR9.1.1": [ + "VPM-07" ], - "I&S-03": [ - "NET-01" + "CR9.3.2": [ + "VPM-10" + ] + }, + "general-govramp": { + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "I&S-06": [ - "NET-06" + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "HRS-04": [ - "NET-14.5" + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "UEM-14": [ - "NET-14.7" + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "DCS-08": [ - "PES-03", - "PES-03.1" + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "LOG-13": [ - "PES-03.3" + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "DCS-04": [ - "PES-04", - "PES-04.1" + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "DCS-10": [ - "PES-04", - "PES-04.1", - "PES-05" + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "DCS-11": [ - "PES-05", - "PES-05.1" + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "DCS-14": [ - "PES-07", - "PES-07.1", - "PES-07.2", - "PES-07.3", - "PES-07.4", - "PES-07.5" + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "DCS-16": [ - "PES-12" + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "DCS-13": [ - "PES-12.1" + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "DSP-08": [ - "PRI-01.11", - "TDA-09.6" + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "DSP-14": [ - "PRI-02" + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "DSP-12": [ - "PRI-02.1", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" ], - "DSP-15": [ - "PRI-05.1", - "TDA-10" + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "DSP-11": [ - "PRI-06" + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "DSP-13": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "AIS-04": [ - "PRM-07", - "TDA-01", - "TDA-02.3", - "TDA-06", - "TDA-08.1", - "TDA-09" + "CM-08": [ + "AST-02", + "AST-02.3" ], - "CEK-07": [ - "RSK-01", - "RSK-01.1", - "RSK-02.1", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1" + "CM-08(01)": [ + "AST-02.1" ], - "GRC-02": [ - "RSK-01" + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" ], - "DSP-09": [ - "RSK-10" + "CM-08(02)": [ + "AST-02.9" ], - "DCS-18": [ - "SEA-01", - "SEA-01.2", - "SEA-01.3" + "CM-08(04)": [ + "AST-03.1" ], - "DSP-07": [ - "SEA-01", - "TDA-09.6" + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "I&S-09": [ - "SEA-03" + "SA-04(01)": [ + "AST-04", + "TDA-04.1" ], - "LOG-06": [ - "SEA-20" + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" ], - "HRS-11": [ - "SAT-01" + "SA-05": [ + "AST-04.1", + "TDA-04" ], - "HRS-12": [ - "SAT-02" + "CP-02": [ + "BCD-01", + "BCD-06" ], - "DCS-12": [ - "SAT-03" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "STA-09": [ - "TDA-04.2" + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" ], - "AIS-06": [ - "TDA-06", - "TDA-06.2", - "TDA-06.3", - "TDA-07", - "TDA-08" + "CP-02(01)": [ + "BCD-01.1" ], - "I&S-05": [ - "TDA-08" + "CP-06(02)": [ + "BCD-01.4" ], - "I&S-07": [ - "TDA-08.1" + "CP-02(08)": [ + "BCD-02" ], - "AIS-07": [ - "TDA-15" + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" ], - "STA-08": [ - "TPM-01.1" + "CP-02(05)": [ + "BCD-02.2" ], - "STA-16": [ - "TPM-04.1" + "CP-03": [ + "BCD-03" ], - "STA-04": [ - "TPM-05", - "TPM-05.4" + "CP-03(01)": [ + "BCD-03.1" ], - "STA-11": [ - "TPM-05", - "TPM-05.2" + "CP-04": [ + "BCD-04", + "BCD-05" ], - "STA-02": [ - "TPM-05.4" + "CP-04(01)": [ + "BCD-04.1" ], - "STA-03": [ - "TPM-05.4" + "CP-04(02)": [ + "BCD-04.2" ], - "STA-05": [ - "TPM-05.4" + "CP-06": [ + "BCD-08" ], - "STA-06": [ - "TPM-05.4" + "CP-06(01)": [ + "BCD-08.1" ], - "STA-07": [ - "TPM-05.4" + "CP-06(03)": [ + "BCD-08.2" ], - "STA-10": [ - "TPM-08", - "TPM-10" + "CP-07": [ + "BCD-09" ], - "STA-12": [ - "TPM-08" + "CP-07(01)": [ + "BCD-09.1" ], - "STA-13": [ - "TPM-08" + "CP-07(02)": [ + "BCD-09.2" ], - "STA-14": [ - "TPM-08" + "CP-07(03)": [ + "BCD-09.3" ], - "STA-15": [ - "TPM-08" + "CP-07(04)": [ + "BCD-09.4" ], - "TVM-05": [ - "THR-03", - "VPM-06.1" + "CP-08": [ + "BCD-10" ], - "TVM-06": [ - "THR-03", - "VPM-06.1" + "CP-08(02)": [ + "BCD-10" ], - "TVM-10": [ - "THR-10", - "VPM-04" + "CP-08(01)": [ + "BCD-10.1" ], - "TVM-03": [ - "VPM-01.1", - "VPM-03" + "CP-08(03)": [ + "BCD-10.2" ], - "TVM-09": [ - "VPM-03" + "CP-08(04)": [ + "BCD-10.3" ], - "TVM-08": [ - "VPM-04" + "CP-09": [ + "BCD-11" ], - "TVM-11": [ - "VPM-05.1" + "CP-09(01)": [ + "BCD-11.1" ], - "TVM-07": [ - "VPM-07" - ] - }, - "general-csa-iot-2": { - "GVN-01": [ - "GOV-01", - "GOV-02", - "GOV-04", - "GOV-04.1", - "EMB-01", - "HRS-03" + "CP-09(03)": [ + "BCD-11.2" ], - "GVN-02": [ - "GOV-01", - "GOV-02", - "CPL-01", - "EMB-01", - "SEA-01", - "SEA-01.1", - "SEA-02" + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" ], - "POL-03": [ - "GOV-02", - "EMB-01" + "CP-09(02)": [ + "BCD-11.5" ], - "RSM-01": [ - "GOV-16.1", - "GOV-16.2", - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-02.1", - "RSK-03", - "RSK-04", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-08" + "CP-09(05)": [ + "BCD-11.6" ], - "SAP-10": [ - "AAT-01", - "AAT-16", - "AAT-16.11" + "CP-10(02)": [ + "BCD-12.1" ], - "ASM-02": [ - "AST-01" + "CP-10(04)": [ + "BCD-12.4" ], - "ASM-04": [ - "AST-01.3" - ], - "ASM-01": [ - "AST-02" + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "SNT-04": [ - "AST-02", - "AST-02.2", - "AST-02.9", - "EMB-13" + "SC-06": [ + "CAP-02" ], - "DAT-03": [ - "AST-03.2", - "AST-04", - "SEA-08.1" + "CP-02(02)": [ + "CAP-03" ], - "PHY-01": [ - "AST-07", - "AST-08", - "EMB-04", - "EMB-05", - "PES-01", - "PES-03", - "PES-05", - "PES-05.1", - "PES-05.2", - "PES-12" + "CM-03": [ + "CHG-01", + "CHG-02" ], - "POL-04": [ - "AST-09", - "DCH-08", - "DCH-21", - "PRM-07", - "SEA-07.1" + "CM-03(01)": [ + "CHG-02.1" ], - "SWS-01": [ - "AST-14.1", - "CFG-02" + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" ], - "SWS-03": [ - "AST-14.1", - "CFG-02.5" + "CM-03(04)": [ + "CHG-02.3" ], - "IOT-05": [ - "AST-15", - "EMB-04", - "EMB-06" + "CM-03(06)": [ + "CHG-02.5" ], - "IOT-09": [ - "AST-18", - "EMB-18" + "CM-04": [ + "CHG-03" ], - "GVN-03": [ - "BCD-01" + "CM-05": [ + "CHG-04", + "END-03.2" ], - "OPA-05": [ - "BCD-01.2", - "BCD-02.2", - "CPL-01", - "TPM-11" + "CM-05(01)": [ + "CHG-04.1" ], - "OPA-03": [ - "BCD-04", - "BCD-12.2", - "CAP-06" + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "OPA-06": [ - "BCD-04", - "BCD-12", - "BCD-12.2", - "NET-01", - "SEA-02" + "CM-05(05)": [ + "CHG-04.4" ], - "SNT-03": [ - "CAP-01", - "CAP-04", - "MON-01", - "EMB-05" + "CM-09": [ + "CHG-05", + "CFG-01" ], - "OPA-08": [ - "CAP-02", - "MON-01.3", - "NET-01", - "NET-02.1" + "SI-06": [ + "CHG-06" ], - "OPA-09": [ - "CAP-02", - "NET-02.1" + "SA-09(05)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" ], - "CCM-02": [ - "CHG-01", - "CHG-02", - "CFG-01" + "CA-07": [ + "CPL-02" ], - "CCM-08": [ - "CHG-01", - "CHG-02", - "CHG-02.2", - "CHG-02.3", - "CFG-01" + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" ], - "DAT-04": [ - "CHG-01", - "CRY-05", - "DCH-19" + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "IAM-22": [ - "CHG-01", - "CHG-02", - "IAC-12" + "RA-03": [ + "CPL-03.2", + "RSK-04" ], - "GVN-05": [ - "CHG-02", - "CHG-02.1", - "CHG-02.4", - "DCH-23", - "EMB-05" + "CM-02": [ + "CFG-02", + "CFG-02.1" ], - "CLS-01": [ - "CLD-01", - "CLD-02", - "CRY-01", - "CRY-08", - "CRY-09", - "IAC-10.2" + "CM-06": [ + "CFG-02", + "CFG-02.7" ], - "CLS-05": [ - "CLD-01", - "CLD-02", + "SA-08": [ "CFG-02", - "CFG-02.5", - "SEA-01", - "SEA-01.1" + "SEA-01" ], - "CLS-07": [ - "CLD-04", - "MON-01.3", - "MON-01.16" + "CM-02(02)": [ + "CFG-02.2" ], - "CLS-12": [ - "CLD-04", - "CLD-11", - "CLD-12", - "NET-04", - "SEA-08.1" + "CM-06(01)": [ + "CFG-02.2" ], - "CLS-13": [ - "CLD-04" + "CM-02(03)": [ + "CFG-02.3" ], - "CLS-02": [ - "CLD-12", + "CM-02(07)": [ + "CFG-02.5" + ], + "CM-06(02)": [ + "CFG-02.8" + ], + "CM-07": [ + "CFG-03" + ], + "CM-07(01)": [ + "CFG-03.1" + ], + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" + ], + "CM-07(05)": [ "CFG-03.3" ], - "CLS-04": [ - "CPL-01", - "IAO-03.2", - "PRI-07.1", - "TPM-05" + "SC-07(07)": [ + "CFG-03.4" ], - "GVN-04": [ - "CPL-01", - "CPL-01.1", - "CPL-02", - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "CM-10": [ + "CFG-04" ], - "LGL-01": [ - "CPL-01", - "EMB-14", - "EMB-15", - "PRM-05", - "RSK-10" + "CM-10(01)": [ + "CFG-04.1" ], - "LGL-03": [ - "CPL-01", - "CPL-02", - "PRM-05", - "PRM-06", - "PRM-07", - "RSK-10" + "CM-11": [ + "CFG-05", + "END-03" ], - "LGL-04": [ - "CPL-01", - "PRI-01", - "PRM-05", - "PRM-06", - "PRM-07" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "LGL-05": [ - "CPL-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TPM-05" + "SI-04(01)": [ + "MON-01.1" ], - "LGL-06": [ - "CPL-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TPM-05" + "SI-04(02)": [ + "MON-01.2" ], - "LGL-07": [ - "CPL-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TPM-05" + "SI-04(04)": [ + "MON-01.3" ], - "LGL-08": [ - "CPL-01", - "DCH-01", - "DCH-19", - "DCH-25", - "PRM-05", - "PRM-06", - "TPM-05" + "SI-04(05)": [ + "MON-01.4" ], - "IOT-02": [ - "CFG-02", - "CFG-02.5" + "SI-04(14)": [ + "MON-01.5" ], - "IOT-03": [ - "CFG-02", - "END-06.1" + "SI-04(23)": [ + "MON-01.6" ], - "IOT-07": [ - "CFG-02", - "EMB-14", - "EMB-18" + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" ], - "SNT-01": [ - "CFG-02", - "NET-01", - "NET-02" + "AU-02": [ + "MON-01.8", + "MON-02" ], - "SWS-08": [ - "CFG-02" + "SI-04(19)": [ + "MON-01.14" ], - "CCM-03": [ - "CFG-02.2", - "CFG-06", - "EMB-05" + "SI-04(20)": [ + "MON-01.15" ], - "SWS-02": [ - "CFG-02.2" + "AU-06": [ + "MON-02", + "MON-02.6" ], - "SAP-09": [ - "CFG-02.5", - "EMB-19" + "AU-06(03)": [ + "MON-02.1" ], - "IAM-07": [ - "CFG-07" + "SI-04(16)": [ + "MON-02.1" ], - "MON-01": [ - "MON-01", - "MON-11.3", - "MON-16" + "AU-06(04)": [ + "MON-02.2" ], - "MON-03": [ - "MON-01", - "MON-01.2", - "MON-01.4", - "MON-01.12", - "MON-03" + "AU-06(05)": [ + "MON-02.3" ], - "MON-05": [ - "MON-01", - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-08.3" + "AU-06(06)": [ + "MON-02.4" ], - "MON-07": [ - "MON-01", - "MON-02", - "MON-02.2", + "AU-06(07)": [ + "MON-02.5" + ], + "AU-12(01)": [ "MON-02.7" ], - "OPA-04": [ - "MON-01.1", - "MON-01.2", - "MON-01.3", - "MON-01.13" + "AU-12(03)": [ + "MON-02.8" ], - "CLS-08": [ - "MON-01.4", - "MON-01.8", - "EMB-12", - "EMB-13", - "EMB-16", - "EMB-17" + "AU-03": [ + "MON-03" ], - "MON-08": [ - "MON-01.5", - "NET-08.2" + "AU-03(01)": [ + "MON-03.1" ], - "SAP-06": [ - "MON-01.7", - "MON-16", - "END-06", - "END-07" + "AU-06(01)": [ + "MON-03.1" ], - "MON-06": [ - "MON-03", + "AU-04": [ + "MON-04" + ], + "AU-05": [ + "MON-05" + ], + "AU-05(02)": [ + "MON-05.1" + ], + "AU-05(01)": [ + "MON-05.2" + ], + "AU-07": [ + "MON-06" + ], + "AU-07(01)": [ + "MON-06" + ], + "AU-12": [ + "MON-06" + ], + "CA-07(03)": [ + "MON-06.2" + ], + "AU-08": [ + "MON-07", + "SEA-20" + ], + "AU-09": [ + "MON-08" + ], + "AU-09(02)": [ "MON-08.1" ], - "MON-04": [ - "MON-08", - "MON-08.2", - "IAC-08" + "AU-09(04)": [ + "MON-08.2" ], - "IAM-08": [ - "MON-11.3", - "MON-16", - "CRY-09", - "IAC-07", - "IRO-02", - "IRO-02.1", - "IRO-02.6" + "AU-09(03)": [ + "MON-08.3" ], - "MON-09": [ - "MON-11.3", - "IRO-03" + "AU-10": [ + "MON-09" ], - "MON-11": [ - "MON-11.3", - "IRO-03", - "THR-03" + "AU-11": [ + "MON-10" ], - "MON-10": [ + "SI-04(18)": [ + "MON-11.1", + "NET-17" + ], + "SI-04(22)": [ + "MON-11.2" + ], + "AC-02(12)": [ "MON-16" ], - "COM-07": [ - "CRY-01", - "CRY-03", - "EMB-11" + "SI-04(11)": [ + "MON-16" ], - "COM-08": [ + "SC-08(01)": [ "CRY-01", + "CRY-01.1", "CRY-03" ], - "COM-09": [ + "SC-13": [ "CRY-01", - "CRY-03" + "CRY-01.2", + "CRY-05" ], - "IOT-10": [ - "CRY-01", - "CRY-03", - "NET-03" + "IA-07": [ + "CRY-02", + "IAC-12" ], - "SAP-07": [ - "CRY-01", + "SC-08": [ "CRY-03", "CRY-04" ], - "SWS-11": [ - "CRY-03" + "SC-28": [ + "CRY-05", + "END-02" ], - "SWS-07": [ + "AC-18": [ "CRY-07", - "NET-12.1" + "NET-15" ], - "IAM-10": [ - "CRY-08", - "CRY-09", - "CRY-09.3" + "SC-12": [ + "CRY-08" ], - "SDV-01": [ - "CRY-08", - "CRY-09" + "SC-17": [ + "CRY-08" ], - "IAM-11": [ - "CRY-09", - "CRY-09.3" + "SC-12(02)": [ + "CRY-09.1" ], - "IAM-12": [ - "CRY-09" + "SC-12(03)": [ + "CRY-09.2" ], - "IAM-13": [ - "CRY-09", + "SC-12(01)": [ "CRY-09.3" ], - "IAM-14": [ - "CRY-09" - ], - "IAM-15": [ - "CRY-09" + "MP-02": [ + "DCH-03", + "END-01" ], - "IAM-16": [ - "CRY-09", - "IAC-08", - "OPS-03" + "MP-03": [ + "DCH-04", + "DCH-04.1" ], - "SWS-10": [ - "CRY-09" + "MP-04": [ + "DCH-06" ], - "DAT-01": [ - "DCH-02", - "DCH-05", - "NET-04.5" + "MP-05": [ + "DCH-07" ], - "GVN-06": [ - "DCH-02", - "DCH-02.1", - "IRO-04.1", - "NET-04.5" + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "VLN-04": [ - "EMB-01", - "VPM-01", - "VPM-02", - "VPM-03", - "VPM-06", - "VPM-06.2" + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" ], - "SAP-03": [ - "EMB-08" + "MP-06(01)": [ + "DCH-09.1" ], - "ASM-03": [ - "EMB-09" + "MP-06(02)": [ + "DCH-09.2" ], - "CCM-01": [ - "EMB-10", - "SEA-07.1" + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "IOT-08": [ - "EMB-10", - "EMB-14" + "AC-20": [ + "DCH-13" ], - "COM-01": [ - "EMB-11" + "AC-20(01)": [ + "DCH-13.1" ], - "COM-10": [ - "EMB-12" + "AC-20(02)": [ + "DCH-13.2" ], - "COM-11": [ - "EMB-13" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "GVN-09": [ - "EMB-14", - "EMB-15" + "AC-22": [ + "DCH-15" ], - "RSM-03": [ - "EMB-14", - "RSK-08", - "TPM-03.2" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "GVN-10": [ - "EMB-15" + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "IAM-03": [ - "EMB-16" + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "IOT-04": [ - "EMB-17" + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" ], - "IOT-06": [ - "EMB-18" + "SI-07(01)": [ + "END-06.1" ], - "SAP-02": [ - "EMB-19" + "SI-07(07)": [ + "END-06.2" ], - "CLS-14": [ - "END-04", - "END-07" + "SI-07(02)": [ + "END-06.3" ], - "IAM-17": [ - "IAC-01", - "IAC-04" + "SI-07(05)": [ + "END-06.4" ], - "CLS-09": [ - "IAC-01.2" + "SI-08": [ + "END-08" ], - "CLS-11": [ - "IAC-06" + "SI-08(02)": [ + "END-08.2" ], - "IAM-18": [ - "IAC-10", - "IAC-10.1" + "SC-18": [ + "END-10" ], - "IAM-21": [ - "IAC-10", - "IAC-10.1" + "SC-15": [ + "END-14" ], - "IAM-19": [ - "IAC-10.1" + "SC-03": [ + "END-16", + "SEA-04.1" ], - "IAM-20": [ - "IAC-10.8" + "SC-07(12)": [ + "END-16.1" ], - "IAM-02": [ - "IAC-16", - "IAC-17" + "PS-02": [ + "HRS-02", + "HRS-03.2" ], - "IAM-04": [ - "IAC-16", - "IAC-20.3", - "IAC-21.2" + "PS-03": [ + "HRS-04" ], - "IAM-06": [ - "IAC-21" + "PS-03(03)": [ + "HRS-04.1" ], - "IAM-01": [ - "IAC-29" + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "IMT-01": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-08", - "TPM-05", - "TPM-11" + "PL-04(01)": [ + "HRS-05.2" ], - "IAM-09": [ - "IRO-02", - "IRO-03", - "IRO-04" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "MON-02": [ - "IRO-02", - "IRO-03" + "PS-08": [ + "HRS-07" ], - "IOT-01": [ - "IAO-01", - "IAO-02.2", - "IAO-06", - "IAO-07" + "PS-05": [ + "HRS-08" ], - "SET-01": [ - "IAO-01", - "IAO-01.1", - "IAO-02", - "IAO-02.2" + "PS-04": [ + "HRS-09" ], - "OPA-01": [ - "MNT-01", - "MNT-02", - "MNT-03", - "MNT-03.1" + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" ], - "OPA-02": [ - "MNT-03.3" + "PS-04(02)": [ + "HRS-09.4" ], - "SAP-05": [ - "MDM-01", - "MDM-03", - "MDM-06", - "MDM-07" + "PS-07": [ + "HRS-10" ], - "IAM-05": [ - "MDM-09" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "OPA-07": [ - "NET-01", - "SEA-02" + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "SNT-02": [ - "NET-01.1" + "IA-02": [ + "IAC-02" ], - "SWS-04": [ - "NET-03.1", - "SEA-01", - "SEA-02" + "IA-02(05)": [ + "IAC-02.1" ], - "SWS-05": [ - "NET-04", - "NET-04.1" + "IA-02(08)": [ + "IAC-02.2" ], - "SAP-01": [ - "NET-06", - "NET-06.1", - "NET-06.4" + "IA-02(12)": [ + "IAC-02.3" ], - "CCM-06": [ - "NET-06.4", - "TDA-14.1", - "VPM-05.1" + "IA-08": [ + "IAC-03" ], - "SWS-09": [ - "NET-11" + "IA-08(01)": [ + "IAC-03.1" ], - "SWS-06": [ - "NET-15.5", - "VPM-08" + "IA-08(02)": [ + "IAC-03.2" ], - "DAT-02": [ - "NET-17" + "IA-08(04)": [ + "IAC-03.3" ], - "LGL-02": [ - "PRM-04", - "PRM-05", - "PRM-06", - "PRM-07" + "IA-03": [ + "IAC-04" ], - "RSM-02": [ - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-02.1", - "RSK-05", - "RSK-06", - "RSK-06.1" + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "SDV-02": [ - "RSK-09", - "TDA-04.2" + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "GVN-07": [ - "RSK-10" + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "GVN-08": [ - "RSK-10" + "AC-02(07)": [ + "IAC-08" ], - "CCM-05": [ - "SEA-07.1" + "IA-05(08)": [ + "IAC-09.5" ], - "SET-05": [ - "SEA-07.1", - "THR-06" + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "TRN-01": [ - "SAT-01", - "SAT-03" + "IA-05(02)": [ + "IAC-10.2" ], - "TRN-02": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "IA-05(06)": [ + "IAC-10.5" ], - "SET-06": [ - "TDA-01", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5", - "TDA-15" + "IA-05(07)": [ + "IAC-10.6" ], - "SDV-07": [ - "TDA-02", - "TDA-02.3", - "TDA-09", - "TDA-09.1", - "TDA-09.5" + "IA-05": [ + "IAC-10.8" ], - "SDV-05": [ - "TDA-06", - "TDA-12" + "IA-05(13)": [ + "IAC-10.10" ], - "SDV-06": [ - "TDA-06.2" + "IA-06": [ + "IAC-11" ], - "SDV-03": [ - "TDA-06.3", - "TDA-12" + "AC-02(01)": [ + "IAC-15.1" ], - "SDV-04": [ - "TDA-09.2", - "TDA-09.3" + "AC-02(02)": [ + "IAC-15.2" ], - "SET-02": [ - "TDA-09.5", - "VPM-07", - "VPM-07.1" + "AC-02(03)": [ + "IAC-15.3" ], - "POL-01": [ - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.1", - "TPM-09", - "TPM-11" + "AC-02(04)": [ + "IAC-15.4" ], - "POL-02": [ - "TPM-01", - "TPM-03", - "TPM-04", - "TPM-04.4", - "TPM-05", - "TPM-06", - "TPM-08" + "AC-02(09)": [ + "IAC-15.5" ], - "TRN-03": [ - "THR-06" + "AC-02(11)": [ + "IAC-15.8" ], - "CLS-06": [ - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-04", - "VPM-04.1", - "VPM-05", - "VPM-05.1", - "VPM-05.4" + "AC-06(07)": [ + "IAC-17" ], - "VLN-01": [ - "VPM-01", - "VPM-05", - "VPM-05.1" + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "VLN-02": [ - "VPM-01.1", - "VPM-05.1" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "VLN-03": [ - "VPM-04", - "VPM-05.4" + "AC-06(01)": [ + "IAC-21.1" ], - "CCM-07": [ - "VPM-05", - "VPM-05.1", - "VPM-05.4" + "AC-06(02)": [ + "IAC-21.2" ], - "SET-04": [ - "VPM-07", - "VPM-07.1" + "AC-06(05)": [ + "IAC-21.3" ], - "SET-03": [ - "VPM-07.1", - "VPM-10" - ] - }, - "general-cr-cmm-2026": { - "CR1.1.4": [ - "AST-01.1", - "TPM-02" + "AC-06(09)": [ + "IAC-21.4" ], - "CR5.1.1": [ - "BCD-01" + "AC-06(10)": [ + "IAC-21.5" ], - "CR5.2.1": [ - "BCD-01.1" + "AC-06(03)": [ + "IAC-21.6" ], - "CR5.1.2": [ - "BCD-01.7" + "AC-06(08)": [ + "IAC-21.7" ], - "CR1.1.5": [ - "BCD-02" + "AC-07": [ + "IAC-22" ], - "CR10.1.1": [ - "BCD-02.2" + "AC-10": [ + "IAC-23" ], - "CR6.3.1": [ - "BCD-03.1" + "AC-02(05)": [ + "IAC-24" ], - "CR7.2.1": [ - "BCD-03.2" - ], - "CR7.2.2": [ - "BCD-04" - ], - "CR7.2.8": [ - "BCD-04.1" - ], - "CR7.2.13": [ - "BCD-06" - ], - "CR5.1.9": [ - "BCD-07" - ], - "CR10.2.5": [ - "BCD-09" - ], - "CR5.2.6": [ - "BCD-10.4" - ], - "CR10.4.4": [ - "BCD-11.1", - "BCD-13.1" - ], - "CR10.2.6": [ - "BCD-11.3", - "BCD-12" - ], - "CR10.2.4": [ - "BCD-11.8", - "BCD-14" - ], - "CR2.2.1": [ - "MON-02.1" - ], - "CR3.1.1": [ - "MON-16.2" - ], - "CR4.1.7": [ - "IRO-02.3" - ], - "CR6.3.2": [ - "IRO-05.1" - ], - "CR6.2.6": [ - "IRO-06", - "VPM-10" - ], - "CR4.1.5": [ - "NET-01.1" - ], - "CR3.1.6": [ - "PRM-02.1" - ], - "CR1.1.1": [ - "RSK-08" - ], - "CR4.3.1": [ - "SEA-01", - "SEA-01.3" - ], - "CR4.3.6": [ - "SEA-03" - ], - "CR4.1.3": [ - "SEA-14" - ], - "CR6.2.2": [ - "SAT-02.1" - ], - "CR8.3.1": [ - "TDA-02.10" - ], - "CR3.1.2": [ - "TDA-06.2" - ], - "CR8.1.2": [ - "TDA-09" - ], - "CR5.3.2": [ - "TDA-17.1", - "TPM-01.1" - ], - "CR7.3.6": [ - "TPM-11" - ], - "CR3.3.2": [ - "THR-02" - ], - "CR2.2.4": [ - "THR-07" - ], - "CR2.2.6": [ - "THR-11" - ], - "CR8.2.1": [ - "VPM-05.6" - ], - "CR9.1.1": [ - "VPM-07" - ], - "CR9.3.2": [ - "VPM-10" - ] - }, - "general-govramp": { - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" - ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" - ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" - ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" - ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" - ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" - ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" - ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" - ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" - ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" - ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" - ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" - ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" - ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" - ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" - ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" - ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" - ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" - ], - "CM-08": [ - "AST-02", - "AST-02.3" - ], - "CM-08(01)": [ - "AST-02.1" - ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" - ], - "CM-08(02)": [ - "AST-02.9" - ], - "CM-08(04)": [ - "AST-03.1" - ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" - ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" - ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" - ], - "SA-05": [ - "AST-04.1", - "TDA-04" - ], - "CP-02": [ - "BCD-01", - "BCD-06" - ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" - ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" - ], - "CP-02(01)": [ - "BCD-01.1" - ], - "CP-06(02)": [ - "BCD-01.4" - ], - "CP-02(08)": [ - "BCD-02" - ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" - ], - "CP-02(05)": [ - "BCD-02.2" - ], - "CP-03": [ - "BCD-03" - ], - "CP-03(01)": [ - "BCD-03.1" - ], - "CP-04": [ - "BCD-04", - "BCD-05" - ], - "CP-04(01)": [ - "BCD-04.1" - ], - "CP-04(02)": [ - "BCD-04.2" - ], - "CP-06": [ - "BCD-08" - ], - "CP-06(01)": [ - "BCD-08.1" - ], - "CP-06(03)": [ - "BCD-08.2" - ], - "CP-07": [ - "BCD-09" - ], - "CP-07(01)": [ - "BCD-09.1" - ], - "CP-07(02)": [ - "BCD-09.2" - ], - "CP-07(03)": [ - "BCD-09.3" - ], - "CP-07(04)": [ - "BCD-09.4" - ], - "CP-08": [ - "BCD-10" - ], - "CP-08(02)": [ - "BCD-10" - ], - "CP-08(01)": [ - "BCD-10.1" - ], - "CP-08(03)": [ - "BCD-10.2" - ], - "CP-08(04)": [ - "BCD-10.3" - ], - "CP-09": [ - "BCD-11" - ], - "CP-09(01)": [ - "BCD-11.1" - ], - "CP-09(03)": [ - "BCD-11.2" - ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" - ], - "CP-09(02)": [ - "BCD-11.5" - ], - "CP-09(05)": [ - "BCD-11.6" - ], - "CP-10(02)": [ - "BCD-12.1" - ], - "CP-10(04)": [ - "BCD-12.4" - ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" - ], - "SC-06": [ - "CAP-02" - ], - "CP-02(02)": [ - "CAP-03" - ], - "CM-03": [ - "CHG-01", - "CHG-02" - ], - "CM-03(01)": [ - "CHG-02.1" - ], - "CM-03(02)": [ - "CHG-02.2", - "CHG-06" - ], - "CM-03(04)": [ - "CHG-02.3" - ], - "CM-03(06)": [ - "CHG-02.5" - ], - "CM-04": [ - "CHG-03" - ], - "CM-05": [ - "CHG-04", - "END-03.2" - ], - "CM-05(01)": [ - "CHG-04.1" - ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" - ], - "CM-05(05)": [ - "CHG-04.4" - ], - "CM-09": [ - "CHG-05", - "CFG-01" - ], - "SI-06": [ - "CHG-06" - ], - "SA-09(05)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" - ], - "CA-07": [ - "CPL-02" - ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" - ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" - ], - "RA-03": [ - "CPL-03.2", - "RSK-04" - ], - "CM-02": [ - "CFG-02", - "CFG-02.1" - ], - "CM-06": [ - "CFG-02", - "CFG-02.7" - ], - "SA-08": [ - "CFG-02", - "SEA-01" - ], - "CM-02(02)": [ - "CFG-02.2" - ], - "CM-06(01)": [ - "CFG-02.2" - ], - "CM-02(03)": [ - "CFG-02.3" - ], - "CM-02(07)": [ - "CFG-02.5" - ], - "CM-06(02)": [ - "CFG-02.8" - ], - "CM-07": [ - "CFG-03" - ], - "CM-07(01)": [ - "CFG-03.1" - ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" - ], - "CM-07(05)": [ - "CFG-03.3" - ], - "SC-07(07)": [ - "CFG-03.4" - ], - "CM-10": [ - "CFG-04" - ], - "CM-10(01)": [ - "CFG-04.1" - ], - "CM-11": [ - "CFG-05", - "END-03" - ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" - ], - "SI-04(01)": [ - "MON-01.1" - ], - "SI-04(02)": [ - "MON-01.2" - ], - "SI-04(04)": [ - "MON-01.3" - ], - "SI-04(05)": [ - "MON-01.4" - ], - "SI-04(14)": [ - "MON-01.5" - ], - "SI-04(23)": [ - "MON-01.6" - ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" - ], - "AU-02": [ - "MON-01.8", - "MON-02" - ], - "SI-04(19)": [ - "MON-01.14" - ], - "SI-04(20)": [ - "MON-01.15" - ], - "AU-06": [ - "MON-02", - "MON-02.6" - ], - "AU-06(03)": [ - "MON-02.1" - ], - "SI-04(16)": [ - "MON-02.1" - ], - "AU-06(04)": [ - "MON-02.2" - ], - "AU-06(05)": [ - "MON-02.3" - ], - "AU-06(06)": [ - "MON-02.4" - ], - "AU-06(07)": [ - "MON-02.5" - ], - "AU-12(01)": [ - "MON-02.7" - ], - "AU-12(03)": [ - "MON-02.8" - ], - "AU-03": [ - "MON-03" - ], - "AU-03(01)": [ - "MON-03.1" - ], - "AU-06(01)": [ - "MON-03.1" - ], - "AU-04": [ - "MON-04" - ], - "AU-05": [ - "MON-05" - ], - "AU-05(02)": [ - "MON-05.1" - ], - "AU-05(01)": [ - "MON-05.2" - ], - "AU-07": [ - "MON-06" - ], - "AU-07(01)": [ - "MON-06" - ], - "AU-12": [ - "MON-06" - ], - "CA-07(03)": [ - "MON-06.2" - ], - "AU-08": [ - "MON-07", - "SEA-20" - ], - "AU-09": [ - "MON-08" - ], - "AU-09(02)": [ - "MON-08.1" - ], - "AU-09(04)": [ - "MON-08.2" - ], - "AU-09(03)": [ - "MON-08.3" - ], - "AU-10": [ - "MON-09" - ], - "AU-11": [ - "MON-10" - ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" - ], - "SI-04(22)": [ - "MON-11.2" - ], - "AC-02(12)": [ - "MON-16" - ], - "SI-04(11)": [ - "MON-16" - ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" - ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" - ], - "IA-07": [ - "CRY-02", - "IAC-12" - ], - "SC-08": [ - "CRY-03", - "CRY-04" - ], - "SC-28": [ - "CRY-05", - "END-02" - ], - "AC-18": [ - "CRY-07", - "NET-15" - ], - "SC-12": [ - "CRY-08" - ], - "SC-17": [ - "CRY-08" - ], - "SC-12(02)": [ - "CRY-09.1" - ], - "SC-12(03)": [ - "CRY-09.2" - ], - "SC-12(01)": [ - "CRY-09.3" - ], - "MP-02": [ - "DCH-03", - "END-01" - ], - "MP-03": [ - "DCH-04", - "DCH-04.1" - ], - "MP-04": [ - "DCH-06" - ], - "MP-05": [ - "DCH-07" - ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" - ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" - ], - "MP-06(01)": [ - "DCH-09.1" - ], - "MP-06(02)": [ - "DCH-09.2" - ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" - ], - "AC-20": [ - "DCH-13" - ], - "AC-20(01)": [ - "DCH-13.1" - ], - "AC-20(02)": [ - "DCH-13.2" - ], - "AC-21": [ - "DCH-14", - "PRI-07" - ], - "AC-22": [ - "DCH-15" - ], - "SI-12": [ - "DCH-18", - "PRI-05" - ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" - ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" - ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" - ], - "SI-07(01)": [ - "END-06.1" - ], - "SI-07(07)": [ - "END-06.2" - ], - "SI-07(02)": [ - "END-06.3" - ], - "SI-07(05)": [ - "END-06.4" - ], - "SI-08": [ - "END-08" - ], - "SI-08(02)": [ - "END-08.2" - ], - "SC-18": [ - "END-10" - ], - "SC-15": [ - "END-14" - ], - "SC-03": [ - "END-16", - "SEA-04.1" - ], - "SC-07(12)": [ - "END-16.1" - ], - "PS-02": [ - "HRS-02", - "HRS-03.2" - ], - "PS-03": [ - "HRS-04" - ], - "PS-03(03)": [ - "HRS-04.1" - ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" - ], - "PL-04(01)": [ - "HRS-05.2" - ], - "PS-06": [ - "HRS-06", - "HRS-06.1" - ], - "PS-08": [ - "HRS-07" - ], - "PS-05": [ - "HRS-08" - ], - "PS-04": [ - "HRS-09" - ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" - ], - "PS-04(02)": [ - "HRS-09.4" - ], - "PS-07": [ - "HRS-10" - ], - "IA-04": [ - "IAC-01.2", - "IAC-09" - ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" - ], - "IA-02": [ - "IAC-02" - ], - "IA-02(05)": [ - "IAC-02.1" - ], - "IA-02(08)": [ - "IAC-02.2" - ], - "IA-02(12)": [ - "IAC-02.3" - ], - "IA-08": [ - "IAC-03" - ], - "IA-08(01)": [ - "IAC-03.1" - ], - "IA-08(02)": [ - "IAC-03.2" - ], - "IA-08(04)": [ - "IAC-03.3" - ], - "IA-03": [ - "IAC-04" - ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" - ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" - ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" - ], - "AC-02(07)": [ - "IAC-08" - ], - "IA-05(08)": [ - "IAC-09.5" - ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" - ], - "IA-05(02)": [ - "IAC-10.2" - ], - "IA-05(06)": [ - "IAC-10.5" - ], - "IA-05(07)": [ - "IAC-10.6" - ], - "IA-05": [ - "IAC-10.8" - ], - "IA-05(13)": [ - "IAC-10.10" - ], - "IA-06": [ - "IAC-11" - ], - "AC-02(01)": [ - "IAC-15.1" - ], - "AC-02(02)": [ - "IAC-15.2" - ], - "AC-02(03)": [ - "IAC-15.3" - ], - "AC-02(04)": [ - "IAC-15.4" - ], - "AC-02(09)": [ - "IAC-15.5" - ], - "AC-02(11)": [ - "IAC-15.8" - ], - "AC-06(07)": [ - "IAC-17" - ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" - ], - "AC-06": [ - "IAC-20", - "IAC-21" - ], - "AC-06(01)": [ - "IAC-21.1" - ], - "AC-06(02)": [ - "IAC-21.2" - ], - "AC-06(05)": [ - "IAC-21.3" - ], - "AC-06(09)": [ - "IAC-21.4" - ], - "AC-06(10)": [ - "IAC-21.5" - ], - "AC-06(03)": [ - "IAC-21.6" - ], - "AC-06(08)": [ - "IAC-21.7" - ], - "AC-07": [ - "IAC-22" - ], - "AC-10": [ - "IAC-23" - ], - "AC-02(05)": [ - "IAC-24" - ], - "AC-11": [ - "IAC-24" + "AC-11": [ + "IAC-24" ], "AC-11(01)": [ "IAC-24.1" @@ -146888,7 +149410,6 @@ "GOV-04", "HRS-03", "HRS-04.1", - "TPM-03.2", "TPM-05.4", "TPM-06" ], @@ -147381,6 +149902,7 @@ "5.20": [ "IRO-10.4", "TPM-01", + "TPM-03.2", "TPM-05", "TPM-08", "TPM-10" @@ -149251,7 +151773,7 @@ "PRI-04.7", "PRI-05.2" ], - "6.1": [ + "6.10": [ "IRO-10", "PRI-01", "PRI-01.1", @@ -150441,7 +152963,7 @@ "TDA-01.1" ] }, - "general-mitre-att&ck-16-1": { + "general-mitre-att_ck-16-1": { "T1011.001": [ "AST-02", "CFG-02", @@ -154063,7185 +156585,22259 @@ "NET-04", "SEA-04.1" ], - "T1559.003": [ - "CHG-04", - "CFG-02", - "CFG-03", - "MON-01", - "SEA-01", - "TDA-09", - "TDA-14" + "T1559.003": [ + "CHG-04", + "CFG-02", + "CFG-03", + "MON-01", + "SEA-01", + "TDA-09", + "TDA-14" + ], + "T1562": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "CRY-03", + "CRY-04", + "END-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-15", + "IAC-20", + "IAC-21", + "VPM-06" + ], + "T1562.001": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1562.002": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1562.004": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1562.006": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "CFG-04", + "MON-01", + "CRY-03", + "CRY-04", + "END-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-05", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-09" + ], + "T1562.007": [ + "CHG-04", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1562.009": [ + "CHG-04", + "CFG-02", + "CFG-03", + "CFG-04", + "CRY-03", + "CRY-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-05", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-09" + ], + "T1562.011": [ + "CHG-04", + "CFG-02", + "MON-01", + "END-04", + "END-06" + ], + "T1569": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "CFG-05", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1569.001": [ + "CHG-04", + "CFG-05", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1569.002": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1574.005": [ + "CHG-04", + "CFG-02", + "MON-01", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-04", + "VPM-06" + ], + "T1574.010": [ + "CHG-04", + "CFG-02", + "MON-01", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-04", + "VPM-06" + ], + "T1574.011": [ + "CHG-04", + "IAC-21" + ], + "T1574.012": [ + "CHG-04", + "CFG-03", + "END-06", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21", + "TDA-18" + ], + "T1574.014": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "IAC-20", + "IAC-21", + "TDA-18" + ], + "T1578": [ + "CHG-04", + "CFG-02", + "MON-01", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-11", + "IAC-15", + "IAC-20", + "IAC-21", + "VPM-06" + ], + "T1578.001": [ + "CHG-04", + "CFG-02", + "MON-01", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-11", + "IAC-15", + "IAC-20", + "IAC-21", + "VPM-06" + ], + "T1578.002": [ + "CHG-04", + "CFG-02", + "MON-01", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-11", + "IAC-15", + "IAC-20", + "IAC-21", + "VPM-06" + ], + "T1578.003": [ + "CHG-04", + "CFG-02", + "MON-01", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-11", + "IAC-15", + "IAC-20", + "IAC-21", + "VPM-06" + ], + "T1599": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "CRY-05", + "END-06", + "HRS-11", + "IAC-02", + "IAC-10", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1599.001": [ + "CHG-04", + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "CRY-05", + "END-06", + "HRS-11", + "IAC-02", + "IAC-10", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1611": [ + "CHG-04", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-03", + "NET-04", + "SEA-03.2", + "SEA-04", + "SEA-04.1", + "SEA-10", + "SEA-16", + "VPM-05" + ], + "T1619": [ + "CHG-04", + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-14" + ], + "T1621": [ + "CHG-04", + "IAC-02", + "IAC-04", + "IAC-10", + "IAC-15", + "IAC-21" + ], + "T1001": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1001.001": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1001.002": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1001.003": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1008": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1029": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1030": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1036": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "IAC-05", + "IAC-15", + "IAC-20", + "IAC-21", + "TDA-18" + ], + "T1036.003": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1036.005": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "IAC-05", + "IAC-15", + "IAC-20", + "IAC-21", + "TDA-18" + ], + "T1036.007": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-02" + ], + "T1037": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "IAC-20", + "NET-14" + ], + "T1037.002": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "IAC-20" + ], + "T1037.003": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "IAC-20" + ], + "T1037.004": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "IAC-20" + ], + "T1037.005": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "IAC-20" + ], + "T1048.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "IAC-20", + "NET-02.3", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1055.009": [ + "CPL-02", + "MON-01", + "END-04", + "END-10", + "IAC-20", + "IAC-21", + "NET-03", + "SEA-10", + "VPM-05" + ], + "T1056.002": [ + "CPL-02", + "MON-01", + "END-04", + "END-06" + ], + "T1070.003": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1070.007": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1070.009": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "HRS-11", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1071": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "MON-15", + "END-04", + "NET-03", + "NET-04", + "NET-07", + "NET-09", + "NET-10", + "NET-10.1", + "NET-10.2", + "NET-11" + ], + "T1071.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "MON-15", + "END-04", + "NET-03", + "NET-04", + "NET-07", + "NET-09", + "NET-10", + "NET-10.1", + "NET-10.2", + "NET-11" + ], + "T1071.002": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "MON-15", + "END-04", + "NET-03", + "NET-04", + "NET-07", + "NET-09", + "NET-10", + "NET-10.1", + "NET-10.2", + "NET-11" + ], + "T1071.003": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "MON-15", + "END-04", + "NET-03", + "NET-04", + "NET-07", + "NET-09", + "NET-10", + "NET-10.1", + "NET-10.2", + "NET-11" + ], + "T1071.004": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "MON-15", + "END-04", + "IAC-20", + "NET-03", + "NET-04", + "NET-07", + "NET-09", + "NET-10", + "NET-10.1", + "NET-10.2", + "NET-11", + "SEA-09", + "TDA-18" + ], + "T1078.001": [ + "CPL-02", + "MON-01", + "CRY-05", + "HRS-11", + "IAC-15", + "IAC-21", + "PRM-07", + "SEA-01", + "TDA-01", + "TDA-05", + "TDA-06", + "TDA-09", + "TDA-14", + "TDA-16" + ], + "T1080": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "IAC-20", + "NET-03", + "SEA-05", + "TDA-18" + ], + "T1090": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "CRY-03", + "CRY-04", + "END-04", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1090.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1090.002": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1090.003": [ + "CPL-02", + "CFG-02", + "CFG-03", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1095": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1102": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1102.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1102.002": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1102.003": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1104": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1105": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1110": [ + "CPL-02", + "CFG-02", + "MON-01", + "DCH-13", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-10", + "IAC-14", + "IAC-15", + "IAC-20", + "IAC-21", + "IAC-22" + ], + "T1110.001": [ + "CPL-02", + "CFG-02", + "MON-01", + "DCH-13", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-10", + "IAC-14", + "IAC-15", + "IAC-20", + "IAC-21", + "IAC-22" + ], + "T1110.002": [ + "CPL-02", + "CFG-02", + "MON-01", + "DCH-13", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-10", + "IAC-14", + "IAC-15", + "IAC-20", + "IAC-21", + "IAC-22" + ], + "T1110.003": [ + "CPL-02", + "CFG-02", + "MON-01", + "DCH-13", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-10", + "IAC-14", + "IAC-15", + "IAC-20", + "IAC-21", + "IAC-22" + ], + "T1110.004": [ + "CPL-02", + "CFG-02", + "MON-01", + "DCH-13", + "HRS-11", + "IAC-02", + "IAC-09", + "IAC-10", + "IAC-14", + "IAC-15", + "IAC-20", + "IAC-21", + "IAC-22" + ], + "T1111": [ + "CPL-02", + "CFG-02", + "MON-01", + "DCH-13", + "END-04", + "IAC-02", + "IAC-10" + ], + "T1132": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1132.001": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1132.002": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1187": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1201": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04" + ], + "T1204": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "END-08", + "IRO-15", + "NET-03", + "NET-04", + "TDA-18", + "VPM-05" + ], + "T1204.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-08", + "IRO-15", + "NET-03", + "NET-04", + "VPM-05" + ], + "T1204.002": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "END-08", + "IRO-15", + "NET-03", + "NET-04", + "TDA-18" + ], + "T1205": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09" + ], + "T1205.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09" + ], + "T1213.003": [ + "CPL-02", + "HRS-11", + "IAC-02", + "IAC-05", + "IAC-15", + "IAC-20", + "IAC-21", + "PRM-07", + "SEA-01", + "TDA-06", + "TDA-09", + "TDA-14", + "VPM-05", + "VPM-06" + ], + "T1213.004": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "CRY-05", + "DCH-05", + "DCH-14", + "DCH-16", + "DCH-18", + "END-06", + "HRS-11", + "IAC-02", + "IAC-03", + "IAC-09", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-04" + ], + "T1218.002": [ + "CPL-02", + "CFG-02", + "CFG-03", + "CFG-05", + "MON-01", + "END-04", + "END-06", + "IAC-20", + "SEA-10", + "TDA-18" + ], + "T1218.010": [ + "CPL-02", + "MON-01", + "END-06", + "TDA-18" + ], + "T1218.011": [ + "CPL-02", + "MON-01", + "END-06", + "TDA-18" + ], + "T1219": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "IAC-20", + "NET-03", + "NET-04", + "NET-14", + "SEA-09", + "TDA-18" + ], + "T1498": [ + "CPL-02", + "CFG-02", + "CFG-03", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1498.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1498.002": [ + "CPL-02", + "CFG-02", + "CFG-03", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1499": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1499.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1499.002": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1499.003": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1499.004": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1539": [ + "CPL-02", + "CFG-02", + "MON-01", + "DCH-13", + "END-04", + "IAC-02", + "IAC-10", + "IAC-20", + "IAC-21" + ], + "T1546.004": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "IAC-20", + "IAC-21" + ], + "T1546.013": [ + "CPL-02", + "CFG-02", + "CFG-04", + "MON-01", + "END-04", + "END-06", + "IAC-05", + "IAC-20", + "IAC-21" + ], + "T1552.001": [ + "CPL-02", + "CFG-02", + "MON-01", + "CRY-05", + "CRY-08", + "HRS-11", + "IAC-02", + "IAC-10", + "IAC-15", + "IAC-21", + "NET-03", + "NET-04", + "SEA-05", + "TDA-06", + "TDA-09", + "VPM-06" + ], + "T1552.004": [ + "CPL-02", + "CFG-02", + "MON-01", + "CRY-05", + "CRY-08", + "DCH-05", + "DCH-13", + "DCH-18", + "END-06", + "IAC-02", + "IAC-10", + "IAC-15", + "MDM-02", + "NET-03", + "NET-14", + "NET-15", + "SEA-05", + "TDA-06", + "TDA-09", + "VPM-06" + ], + "T1552.005": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "DCH-05", + "DCH-13", + "IAC-04", + "IAC-09", + "IAC-20", + "NET-03", + "NET-04", + "NET-14", + "SEA-09", + "TDA-18" + ], + "T1553.003": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "IAC-20", + "IAC-21", + "TDA-18" + ], + "T1555.001": [ + "CPL-02", + "MON-01", + "IAC-10" + ], + "T1555.002": [ + "CPL-02", + "MON-01", + "IAC-10", + "IAC-20", + "IAC-21" + ], + "T1557.004": [ + "CPL-02", + "CFG-02", + "MON-01", + "CRY-01", + "CRY-03", + "CRY-04", + "DCH-18", + "END-06", + "IAC-20", + "MDM-02", + "NET-02.3", + "NET-03", + "NET-04", + "NET-09", + "NET-12.1", + "NET-15" + ], + "T1558.004": [ + "CPL-02", + "CFG-02", + "MON-01", + "DCH-05", + "DCH-18", + "END-04", + "END-06", + "IAC-02", + "IAC-10", + "IAC-15", + "IAC-20", + "MDM-02", + "NET-14", + "NET-15", + "SEA-05", + "TDA-06", + "TDA-09", + "VPM-06" + ], + "T1558.005": [ + "CPL-02", + "MON-01", + "DCH-18", + "END-06", + "IAC-02", + "IAC-10", + "IAC-15", + "IAC-20", + "IAC-21", + "SEA-05" + ], + "T1564.004": [ + "CPL-02", + "MON-01", + "DCH-05", + "END-04", + "END-06", + "IAC-20" + ], + "T1564.010": [ + "CPL-02", + "MON-01", + "END-06" + ], + "T1566": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-08", + "IAC-05", + "IRO-15", + "NET-03", + "NET-04", + "NET-10", + "VPM-05", + "VPM-06" + ], + "T1566.001": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-08", + "IAC-05", + "IRO-15", + "NET-03", + "NET-04", + "NET-10", + "VPM-05" + ], + "T1566.002": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-08", + "IAC-05", + "IRO-15", + "NET-03", + "NET-04", + "NET-10" + ], + "T1566.003": [ + "CPL-02", + "MON-01", + "END-04", + "END-08", + "IAC-15", + "IAC-21", + "IRO-15", + "NET-03", + "NET-04", + "VPM-05" + ], + "T1568": [ + "CPL-02", + "MON-01", + "END-04", + "NET-03", + "NET-04", + "NET-10", + "NET-10.1", + "NET-10.2" + ], + "T1568.002": [ + "CPL-02", + "MON-01", + "END-04", + "NET-03", + "NET-04", + "NET-10", + "NET-10.1", + "NET-10.2" + ], + "T1570": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1571": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "NET-04" + ], + "T1572": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "IAC-20", + "NET-03", + "NET-04", + "SEA-09", + "TDA-18" + ], + "T1573": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "CRY-08", + "CRY-10", + "END-04", + "NET-03", + "NET-04", + "NET-09" + ], + "T1573.001": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "CRY-08", + "CRY-10", + "END-04", + "NET-03", + "NET-04", + "NET-09" + ], + "T1573.002": [ + "CPL-02", + "CFG-02", + "CFG-03", + "MON-01", + "CRY-08", + "CRY-10", + "END-04", + "NET-03", + "NET-04", + "NET-09" + ], + "T1574.013": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-06", + "TDA-18", + "VPM-05" + ], + "T1598": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-08", + "IAC-05", + "IRO-15", + "NET-03", + "NET-04", + "NET-10" + ], + "T1598.001": [ + "CPL-02", + "MON-01", + "END-04", + "END-08", + "IRO-15", + "NET-03", + "NET-04" + ], + "T1598.002": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-08", + "IAC-05", + "IRO-15", + "NET-03", + "NET-04", + "NET-10" + ], + "T1598.003": [ + "CPL-02", + "CFG-02", + "MON-01", + "END-04", + "END-08", + "IAC-05", + "IRO-15", + "NET-03", + "NET-04", + "NET-10" + ], + "T1027": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "IAC-20", + "VPM-05" + ], + "T1027.010": [ + "CFG-02", + "MON-01", + "END-04", + "TDA-18" + ], + "T1036.001": [ + "CFG-02", + "MON-01", + "END-06", + "IAC-05" + ], + "T1036.010": [ + "CFG-02", + "MON-01", + "IAC-02", + "IAC-15", + "IAC-20" + ], + "T1059.003": [ + "CFG-02", + "MON-01", + "END-04", + "END-06", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-14", + "SEA-10", + "TDA-18" + ], + "T1059.004": [ + "CFG-02", + "MON-01", + "END-04", + "END-06", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-14", + "SEA-10", + "TDA-18" + ], + "T1059.011": [ + "CFG-02", + "MON-01", + "END-04", + "END-06", + "IAC-15", + "IAC-20", + "IAC-21", + "SEA-10" + ], + "T1087": [ + "CFG-02", + "CFG-03", + "MON-01", + "IAC-15" + ], + "T1087.001": [ + "CFG-02", + "CFG-03", + "MON-01" + ], + "T1087.002": [ + "CFG-02", + "CFG-03", + "MON-01" + ], + "T1106": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "IAC-21", + "VPM-05" + ], + "T1114": [ + "CFG-02", + "MON-01", + "DCH-05", + "DCH-13", + "DCH-18", + "END-06", + "IAC-02", + "IAC-10", + "IAC-20", + "MDM-02", + "NET-03", + "NET-04", + "NET-11", + "NET-14" + ], + "T1114.002": [ + "CFG-02", + "MON-01", + "DCH-05", + "DCH-13", + "DCH-18", + "END-06", + "IAC-02", + "IAC-10", + "IAC-20", + "MDM-02", + "NET-04", + "NET-11", + "NET-14" + ], + "T1129": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "TDA-18" + ], + "T1134.005": [ + "CFG-02", + "DCH-13", + "HRS-11", + "IAC-20", + "IAC-21", + "NET-04", + "SEA-01", + "SEA-04.1", + "TDA-01", + "TDA-05", + "TDA-09" + ], + "T1135": [ + "CFG-02", + "CFG-03", + "MON-01" + ], + "T1137.003": [ + "CFG-02", + "END-08", + "END-10", + "IAC-21", + "IRO-15", + "VPM-05" + ], + "T1137.004": [ + "CFG-02", + "END-08", + "END-10", + "IAC-21", + "IRO-15", + "VPM-05" + ], + "T1137.005": [ + "CFG-02", + "END-08", + "END-10", + "IAC-21", + "IRO-15", + "VPM-05" + ], + "T1137.006": [ + "CFG-02", + "END-08", + "END-10", + "IAC-21", + "IRO-15" + ], + "T1199": [ + "CFG-02", + "CFG-03", + "IAC-20", + "IAC-21", + "NET-02.3", + "NET-03", + "NET-04", + "SEA-18" + ], + "T1216": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-06", + "TDA-18" + ], + "T1216.001": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-06", + "TDA-18" + ], + "T1216.002": [ + "CFG-02", + "CFG-03", + "END-06" + ], + "T1218.001": [ + "CFG-02", + "CFG-03", + "CFG-05", + "MON-01", + "END-04", + "END-06", + "END-10", + "SEA-10", + "TDA-18" + ], + "T1220": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-06", + "TDA-18" + ], + "T1482": [ + "CFG-02", + "CFG-03", + "NET-02.3", + "NET-03", + "NET-04", + "SEA-01", + "TDA-05", + "VPM-06" + ], + "T1505.003": [ + "CFG-02", + "MON-01", + "HRS-11", + "IAC-15", + "IAC-20", + "IAC-21", + "VPM-06" + ], + "T1505.005": [ + "CFG-02", + "MON-01", + "DCH-13", + "HRS-11", + "IAC-15", + "IAC-20", + "IAC-21", + "IAC-25", + "NET-14", + "VPM-06" + ], + "T1546.008": [ + "CFG-02", + "CFG-03", + "CFG-04", + "MON-01", + "END-06", + "TDA-18" + ], + "T1546.010": [ + "CFG-02", + "CFG-03", + "END-06", + "TDA-18", + "VPM-05" + ], + "T1547.002": [ + "CFG-02", + "MON-01", + "END-04", + "END-06", + "SEA-04" + ], + "T1547.005": [ + "CFG-02", + "MON-01", + "END-04", + "END-06", + "SEA-04" + ], + "T1547.008": [ + "CFG-02", + "MON-01", + "END-04", + "END-06", + "SEA-04", + "VPM-06" + ], + "T1548.001": [ + "CFG-02", + "CFG-03", + "MON-01" + ], + "T1550.001": [ + "CFG-02", + "CFG-04", + "CFG-05", + "MON-01", + "CRY-03", + "CRY-04", + "CRY-05", + "DCH-05", + "DCH-13", + "DCH-18", + "END-06", + "IAC-02", + "IAC-09", + "MDM-02", + "NET-14" + ], + "T1552.003": [ + "CFG-02", + "CFG-03", + "MON-01", + "CRY-05" + ], + "T1552.006": [ + "CFG-02", + "MON-01", + "HRS-11", + "IAC-02", + "IAC-10", + "IAC-15", + "IAC-21", + "TDA-06", + "TDA-09", + "VPM-05", + "VPM-06" + ], + "T1553.001": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-06", + "TDA-18" + ], + "T1553.004": [ + "CFG-02", + "CFG-03", + "CFG-04", + "MON-01", + "IAC-05", + "NET-10" + ], + "T1553.005": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-06", + "TDA-18" + ], + "T1555.004": [ + "CFG-02", + "CFG-03", + "MON-01", + "IAC-10" + ], + "T1555.005": [ + "CFG-02", + "MON-01", + "IAC-02", + "IAC-10", + "IAC-15", + "IAC-20", + "VPM-05" + ], + "T1556.002": [ + "CFG-02", + "CFG-03", + "MON-01" + ], + "T1560": [ + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "VPM-06" + ], + "T1560.001": [ + "CFG-02", + "MON-01", + "END-04", + "NET-03", + "VPM-06" + ], + "T1562.003": [ + "CFG-02", + "CFG-03", + "MON-01" + ], + "T1562.010": [ + "CFG-02", + "CFG-03", + "MON-01", + "CRY-03", + "CRY-04", + "END-06", + "VPM-06" + ], + "T1564.002": [ + "CFG-02", + "CFG-03", + "MON-01" + ], + "T1574.001": [ + "CFG-02", + "CFG-03", + "MON-01", + "END-04", + "END-06", + "TDA-18", + "VPM-06" + ], + "T1574.006": [ + "CFG-02", + "CFG-03", + "END-06", + "TDA-18" + ], + "T1590.002": [ + "CFG-02", + "CFG-03", + "NET-03", + "NET-04", + "SEA-03.1" + ], + "T1609": [ + "CFG-02", + "CFG-03", + "END-06", + "HRS-11", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-03", + "NET-04", + "NET-14", + "TDA-18" + ], + "T1610": [ + "CFG-02", + "CFG-03", + "MON-01", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-03", + "NET-14" + ], + "T1612": [ + "CFG-02", + "CFG-03", + "MON-01", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-03", + "NET-14", + "TDA-09", + "VPM-06" + ], + "T1648": [ + "CFG-02", + "CFG-03", + "MON-01", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-03" + ], + "T1036.008": [ + "CFG-03", + "MON-01", + "END-04", + "NET-03", + "TDA-18" + ], + "T1037.001": [ + "CFG-03", + "NET-14" + ], + "T1040": [ + "CFG-03", + "MON-01", + "CRY-03", + "CRY-04", + "DCH-05", + "DCH-18", + "END-06", + "IAC-02", + "IAC-10", + "MDM-02", + "NET-14", + "NET-15", + "SEA-05" + ], + "T1059.009": [ + "CFG-03", + "MON-01", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1112": [ + "CFG-03", + "END-06", + "IAC-21" + ], + "T1546.009": [ + "CFG-03", + "END-06", + "TDA-18" + ], + "T1555.006": [ + "CFG-03", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1564.003": [ + "CFG-03", + "END-06", + "TDA-18" + ], + "T1027.002": [ + "MON-01", + "END-04", + "END-06", + "VPM-05" + ], + "T1027.007": [ + "MON-01", + "END-04", + "END-06", + "VPM-05" + ], + "T1027.008": [ + "MON-01", + "END-04", + "END-06", + "VPM-05" + ], + "T1027.009": [ + "MON-01", + "END-04", + "END-06", + "VPM-05" + ], + "T1027.011": [ + "MON-01" + ], + "T1027.012": [ + "MON-01", + "END-04" + ], + "T1055.001": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1055.002": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1055.003": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1055.004": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1055.005": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1055.011": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1055.012": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1055.013": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1055.014": [ + "MON-01", + "END-04", + "END-10", + "IAC-21", + "NET-03", + "VPM-05" + ], + "T1070.010": [ + "MON-01", + "END-04", + "END-06" + ], + "T1071.005": [ + "MON-01", + "MON-15", + "NET-03", + "NET-04" + ], + "T1114.001": [ + "MON-01", + "DCH-05", + "DCH-13", + "DCH-18", + "END-06", + "MDM-02", + "NET-04", + "NET-11", + "NET-14" + ], + "T1205.002": [ + "MON-01", + "NET-04" + ], + "T1552.008": [ + "MON-01", + "NET-04" + ], + "T1651": [ + "MON-01", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21", + "NET-14" + ], + "T1090.004": [ + "CRY-03", + "CRY-04" + ], + "T1550.004": [ + "CRY-03", + "CRY-04", + "END-06", + "NET-09" + ], + "T1521.003": [ + "CRY-08" + ], + "T1606": [ + "CRY-08", + "HRS-11", + "IAC-15", + "IAC-20", + "IAC-21", + "VPM-05" + ], + "T1200": [ + "DCH-10", + "DCH-13", + "END-12", + "IAC-20", + "IAC-21" + ], + "T1021.007": [ + "DCH-13", + "HRS-11", + "IAC-02", + "IAC-10", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1567.001": [ + "DCH-13", + "NET-03", + "NET-04" + ], + "T1567.002": [ + "DCH-13", + "NET-03", + "NET-04" + ], + "T1589": [ + "DCH-16" + ], + "T1589.002": [ + "DCH-16" + ], + "T1589.003": [ + "DCH-16" + ], + "T1590": [ + "DCH-16" + ], + "T1591": [ + "DCH-16" + ], + "T1591.001": [ + "DCH-16" + ], + "T1591.002": [ + "DCH-16" + ], + "T1591.003": [ + "DCH-16" + ], + "T1591.004": [ + "DCH-16" + ], + "T1593.001": [ + "DCH-16" + ], + "T1593.002": [ + "DCH-16" + ], + "T1594": [ + "DCH-16" + ], + "T1595": [ + "DCH-16" + ], + "T1595.001": [ + "DCH-16" + ], + "T1595.002": [ + "DCH-16" + ], + "T1596": [ + "DCH-16" + ], + "T1596.005": [ + "DCH-16" + ], + "T1597": [ + "DCH-16" + ], + "T1027.013": [ + "END-04" + ], + "T1027.014": [ + "END-04" + ], + "T1055.015": [ + "END-04" + ], + "T1564.012": [ + "END-04" + ], + "T1087.004": [ + "HRS-11", + "IAC-02", + "IAC-03", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1538": [ + "HRS-11", + "IAC-02", + "IAC-03", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1543.005": [ + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1556.005": [ + "HRS-11", + "IAC-10", + "IAC-15", + "IAC-21" + ], + "T1580": [ + "HRS-11", + "IAC-02", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1657": [ + "HRS-11", + "IAC-21" + ], + "T1556.006": [ + "IAC-02", + "IAC-14", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1556.007": [ + "IAC-02", + "IAC-14", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1649": [ + "IAC-02", + "IAC-10" + ], + "T1098.006": [ + "IAC-10", + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1496.002": [ + "IAC-15" + ], + "T1585": [ + "IAC-15" + ], + "T1585.001": [ + "IAC-15" + ], + "T1585.002": [ + "IAC-15" + ], + "T1585.003": [ + "IAC-15" + ], + "T1586": [ + "IAC-15" + ], + "T1586.001": [ + "IAC-15" + ], + "T1586.002": [ + "IAC-15" + ], + "T1586.003": [ + "IAC-15" + ], + "T1606.001": [ + "IAC-15", + "IAC-20", + "IAC-21", + "VPM-05" + ], + "T1606.002": [ + "IAC-15", + "IAC-20", + "IAC-21" + ], + "T1654": [ + "IAC-15", + "IAC-20", + "IAC-21", + "NET-04" + ], + "T1546.011": [ + "IAC-21", + "VPM-05" + ], + "T1496.003": [ + "NET-02.1" + ], + "T1567.003": [ + "NET-03", + "NET-04", + "NET-14" + ], + "T1567.004": [ + "NET-03", + "NET-04", + "NET-14" + ], + "T1659": [ + "NET-03", + "NET-04", + "NET-14" + ], + "T1590.001": [ + "NET-03.3" + ], + "T1590.003": [ + "NET-03.3" + ], + "T1590.004": [ + "NET-03.3" + ], + "T1590.005": [ + "NET-03.3" + ], + "T1590.006": [ + "NET-03.3" + ], + "T1592": [ + "NET-03.3" + ], + "T1592.001": [ + "NET-03.3" + ], + "T1592.002": [ + "NET-03.3" + ], + "T1592.003": [ + "NET-03.3" + ], + "T1592.004": [ + "NET-03.3" + ], + "T1535": [ + "NET-09" + ], + "T1583.002": [ + "NET-10.1" + ], + "T1584.002": [ + "NET-10.1" + ], + "T1596.001": [ + "NET-10.1" + ], + "T1596.002": [ + "NET-10.4" + ], + "T1574.002": [ + "PRM-07", + "SEA-01", + "TDA-01", + "TDA-05", + "TDA-06", + "TDA-09", + "TDA-14", + "TDA-16", + "VPM-05" + ], + "T1595.003": [ + "SEA-05" + ] + }, + "general-mpa-csbp-5-3-1": { + "OR-1.0": [ + "GOV-01", + "GOV-02", + "GOV-03", + "GOV-15", + "GOV-15.1", + "SEA-01", + "OPS-01.1" + ], + "OR-5.0": [ + "AAT-01", + "AAT-02", + "AAT-02.1", + "AAT-02.4", + "CPL-01" + ], + "TS-7.0": [ + "AAT-11", + "AAT-12.1", + "AAT-12.2" + ], + "TS-7.1": [ + "AAT-20.2" + ], + "OP-3.0": [ + "AST-01", + "AST-02", + "DCH-01", + "DCH-01.2", + "DCH-01.3", + "DCH-04" + ], + "TS-5.0": [ + "AST-02", + "AST-02.9", + "CHG-01", + "CHG-02.2", + "CHG-03" + ], + "TS-1.17": [ + "AST-02.7", + "TDA-04" + ], + "TS-2.2": [ + "AST-04" + ], + "OP-3.2": [ + "AST-09", + "DCH-06", + "DCH-09", + "HRS-11" + ], + "OR-1.2": [ + "BCD-01", + "BCD-02", + "BCD-02.1", + "BCD-02.2", + "BCD-02.3", + "RSK-03.1", + "TDA-06", + "TDA-09", + "THR-09", + "THR-10" + ], + "OR-1.3": [ + "BCD-01", + "BCD-11", + "BCD-11.4", + "BCD-11.9", + "IRO-04" + ], + "OP-2.1": [ + "BCD-04.2", + "BCD-08", + "BCD-09", + "NET-14", + "PES-01", + "PES-11" + ], + "TS-2.6": [ + "CHG-02.1", + "CFG-02", + "MON-01.4", + "NET-01" + ], + "PS-3.3": [ + "CLD-01", + "CLD-02" + ], + "TS-2.0": [ + "CLD-01", + "CLD-02", + "NET-01", + "NET-02", + "NET-03", + "NET-04", + "WEB-01", + "WEB-02" + ], + "TS-2.12": [ + "CLD-01", + "CLD-02" + ], + "TS-8.2": [ + "CLD-02", + "CFG-03", + "NET-06" + ], + "TS-1.11": [ + "CLD-06.1", + "TPM-05.4" + ], + "TS-1.1": [ + "CFG-02" + ], + "TS-1.2": [ + "CFG-02", + "IAC-10.8" + ], + "TS-2.3": [ + "CFG-02", + "NET-01" + ], + "TS-2.4": [ + "CFG-02", + "CFG-02.1", + "MON-01.4", + "MON-01.8", + "NET-04", + "NET-04.1", + "NET-04.6" + ], + "TS-2.8": [ + "CFG-02", + "CFG-03", + "NET-06", + "NET-06.5", + "NET-18" + ], + "TS-1.12": [ + "CFG-02.2" + ], + "TS-1.5": [ + "MON-01", + "MON-01.2", + "MON-01.3", + "MON-01.8", + "MON-03", + "MON-08", + "SEA-20" + ], + "TS-2.7": [ + "MON-01.1", + "END-07", + "NET-01", + "NET-08" + ], + "TS-2.13": [ + "MON-01.3", + "MON-11.2", + "NET-01" + ], + "TS-1.0": [ + "CRY-01", + "CRY-03", + "CRY-05", + "DCH-18", + "END-01", + "END-01.1", + "END-02", + "END-04", + "END-04.7", + "HRS-11", + "IAC-20.4", + "NET-04", + "NET-04.1", + "NET-06.4", + "PES-04", + "PES-04.1" + ], + "TS-3.0": [ + "CRY-01", + "CRY-03", + "CRY-05" + ], + "TS-2.11": [ + "CRY-07", + "NET-02.2", + "NET-06", + "NET-15" + ], + "TS-3.2": [ + "CRY-09" + ], + "OR-1.4": [ + "DCH-01", + "DCH-01.2", + "DCH-02", + "HRS-11" + ], + "OP-1.1": [ + "DCH-01", + "DCH-01.1", + "DCH-07", + "DCH-07.1" + ], + "OP-3.1": [ + "DCH-01", + "DCH-01.4", + "DCH-23.9" + ], + "OP-1.3": [ + "DCH-06", + "DCH-06.1", + "DCH-07", + "DCH-07.1" + ], + "OP-1.2": [ + "DCH-07", + "DCH-07.1" + ], + "TS-1.16": [ + "DCH-17" + ], + "PS-1.3": [ + "DCH-18", + "PES-03.3" + ], + "PS-3.0": [ + "DCH-18", + "PES-05.1" + ], + "TS-1.3": [ + "END-01", + "END-01.1", + "END-02", + "END-04", + "END-04.1", + "END-04.7" + ], + "TS-1.4": [ + "END-01.1", + "END-04", + "IRO-02", + "MDM-01", + "MDM-05" + ], + "TS-1.9": [ + "END-08", + "NET-17" + ], + "OR-3.0": [ + "HRS-01", + "HRS-04", + "HRS-04.1", + "HRS-05" + ], + "OP-2.0": [ + "HRS-01", + "HRS-03.1", + "NET-14.5" + ], + "OR-3.1": [ + "HRS-01.1", + "HRS-02", + "HRS-02.1", + "HRS-03", + "HRS-03.1", + "HRS-04.2", + "HRS-05", + "HRS-05.7", + "HRS-06", + "HRS-06.1", + "SAT-02", + "SAT-03" + ], + "OR-3.2": [ + "HRS-01.1", + "HRS-08", + "HRS-09", + "HRS-09.1", + "HRS-09.3", + "HRS-09.4" + ], + "OR-1.1": [ + "HRS-05.1", + "HRS-05.2", + "HRS-05.3", + "HRS-05.4", + "HRS-05.5" + ], + "TS-1.6": [ + "IAC-01", + "IAC-01.2", + "IAC-02", + "IAC-06", + "IAC-09", + "IAC-09.1", + "IAC-10", + "IAC-10.1" + ], + "TS-1.8": [ + "IAC-01", + "IAC-01.1", + "IAC-01.2", + "IAC-08", + "IAC-29" + ], + "TS-1.7": [ + "IAC-01.2", + "IAC-08", + "IAC-17", + "IAC-20", + "IAC-21" + ], + "TS-1.10": [ + "IAC-08", + "NET-01", + "WEB-01", + "WEB-02" + ], + "OR-4.0": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-08", + "IRO-09", + "IRO-10" + ], + "OR-2.0": [ + "IAO-05", + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-03", + "RSK-04", + "RSK-04.3", + "RSK-05", + "RSK-06", + "RSK-06.4" + ], + "TS-6.0": [ + "NET-01.1" + ], + "TS-6.1": [ + "NET-01.1" + ], + "TS-6.2": [ + "NET-01.1" + ], + "TS-8.1": [ + "NET-09", + "NET-09.2" + ], + "TS-2.1": [ + "NET-14" + ], + "TS-2.9": [ + "NET-14" + ], + "TS-2.10": [ + "NET-18" + ], + "PS-1.5": [ + "PES-01" + ], + "PS-1.1": [ + "PES-02", + "PES-03.3", + "PES-04", + "PES-04.1", + "PES-06", + "PES-06.2" + ], + "PS-1.2": [ + "PES-02", + "PES-03", + "PES-03.1", + "PES-03.3" + ], + "OP-1.0": [ + "PES-03", + "PES-03.1", + "PES-06", + "PES-10" + ], + "PS-1.0": [ + "PES-03", + "PES-03.1", + "PES-03.4", + "PES-04", + "PES-04.1", + "PES-12" + ], + "PS-2.0": [ + "PES-04.2" + ], + "PS-1.4": [ + "PES-05", + "PES-05.1", + "PES-05.2" + ], + "PS-3.1": [ + "PES-07", + "PES-07.1", + "PES-07.2", + "PES-07.3", + "PES-07.4", + "PES-07.5", + "PES-08", + "PES-08.1", + "PES-09", + "PES-09.1" + ], + "TS-1.14": [ + "PRI-01.11", + "SEA-01" + ], + "OR-3.3": [ + "SAT-01", + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.2", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6", + "SAT-04" + ], + "TS-1.18": [ + "TDA-04" + ], + "TS-1.13": [ + "TDA-06", + "TDA-06.3", + "TDA-06.5", + "TDA-06.6", + "TDA-09" + ], + "TS-2.5": [ + "TDA-08" + ], + "TS-8.3": [ + "TDA-09", + "TDA-09.2", + "TDA-09.3" + ], + "TS-4.2": [ + "TDA-17", + "THR-03", + "VPM-04.3", + "VPM-05", + "VPM-05.1" + ], + "TS-8.0": [ + "TDA-19" + ], + "TS-1.15": [ + "TDA-20", + "TDA-20.1", + "TDA-20.2", + "TDA-20.4" + ], + "OR-3.4": [ + "TPM-01", + "TPM-05", + "TPM-05.4", + "TPM-05.6", + "TPM-05.8", + "TPM-06", + "TPM-08" + ], + "PS-3.2": [ + "TPM-01", + "TPM-05", + "TPM-05.6", + "TPM-05.8" + ], + "TS-4.0": [ + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-06" + ], + "TS-4.1": [ + "VPM-07" + ] + }, + "general-naic-insurance-data-security-model-law-668-2017": { + "3": [ + "SEA-02.1" + ], + "4.A": [ + "GOV-01" + ], + "4.B": [ + "GOV-01" + ], + "4.B(1)": [ + "GOV-01" + ], + "4.B(2)": [ + "GOV-01" + ], + "4.B(3)": [ + "GOV-01" + ], + "4.B(4)": [ + "GOV-01", + "DCH-18" + ], + "4.D(1)": [ + "GOV-01", + "RSK-01" + ], + "4.E(1)": [ + "GOV-01.1" + ], + "4.E(2)": [ + "GOV-01.1" + ], + "4.E(2)(a)": [ + "GOV-01.1" + ], + "4.E(2)(b)": [ + "GOV-01.1", + "GOV-16", + "GOV-16.1", + "GOV-16.2", + "CPL-01.1" + ], + "4.E(3)": [ + "GOV-01.1" + ], + "4.C(1)": [ + "GOV-04" + ], + "4.D(2)": [ + "GOV-09" + ], + "4.D(2)(g)": [ + "GOV-14", + "GOV-15", + "IAC-06" + ], + "4.C(4)(b)": [ + "AST-01", + "DCH-01", + "NET-01" + ], + "4.D(2)(b)": [ + "AST-01", + "DCH-01", + "PES-01", + "PRM-01", + "PRM-02", + "SEA-01" + ], + "4.C(4)(c)": [ + "BCD-01", + "IRO-01" + ], + "4.D(2)(f)": [ + "CHG-01" + ], + "4.I": [ + "CPL-01.5" + ], + "4.C(4)": [ + "CPL-02", + "CPL-03", + "CPL-03.2" + ], + "4.C(5)": [ + "CPL-03", + "CPL-03.2", + "RSK-01", + "THR-01", + "THR-09", + "THR-10" + ], + "4.D(2)(h)": [ + "MON-01" + ], + "4.D(2)(i)": [ + "MON-03", + "MON-03.2" + ], + "4.D(2)(d)": [ + "CRY-01", + "CRY-03", + "CRY-05" + ], + "4.D(2)(j)": [ + "DCH-01", + "PES-01", + "PES-07", + "PES-07.5", + "PES-08" + ], + "4.D(2)(k)": [ + "DCH-21" + ], + "4.C(4)(a)": [ + "HRS-01", + "SAT-01" + ], + "4.D(2)(a)": [ + "IAC-01" + ], + "5.A": [ + "IRO-02" + ], + "5.B(1)": [ + "IRO-02" + ], + "5.B(2)": [ + "IRO-02" + ], + "5.B(3)": [ + "IRO-02" + ], + "5.B(4)": [ + "IRO-02" + ], + "5.C": [ + "IRO-02" + ], + "5.D": [ + "IRO-02" + ], + "6.D(1)": [ + "IRO-02" + ], + "6.D(2)": [ + "IRO-02", + "IRO-10.2" + ], + "4.H(1)": [ + "IRO-04" + ], + "4.H(2)": [ + "IRO-04" + ], + "4.H(2)(a)": [ + "IRO-04" + ], + "4.H(2)(b)": [ + "IRO-04" + ], + "4.H(2)(c)": [ + "IRO-04" + ], + "4.H(2)(d)": [ + "IRO-04" + ], + "4.H(2)(e)": [ + "IRO-04" + ], + "4.H(2)(f)": [ + "IRO-04" + ], + "4.H(2)(g)": [ + "IRO-04" + ], + "6.C": [ + "IRO-04.1" + ], + "6.E(1)(a)": [ + "IRO-10" + ], + "6.E(1)(b)": [ + "IRO-10" + ], + "6.A": [ + "IRO-10.2" + ], + "6.A(1)": [ + "IRO-10.2" + ], + "6.A(2)": [ + "IRO-10.2" + ], + "6.A(2)(a)": [ + "IRO-10.2" + ], + "6.A(2)(b)": [ + "IRO-10.2" + ], + "6.A(2)(b)(i)": [ + "IRO-10.2" + ], + "6.A(2)(b)(ii)": [ + "IRO-10.2" + ], + "6.B": [ + "IRO-10.2" + ], + "6.B(1)": [ + "IRO-10.2" + ], + "6.B(2)": [ + "IRO-10.2" + ], + "6.B(3)": [ + "IRO-10.2" + ], + "6.B(4)": [ + "IRO-10.2" + ], + "6.B(5)": [ + "IRO-10.2" + ], + "6.B(6)": [ + "IRO-10.2" + ], + "6.B(7)": [ + "IRO-10.2" + ], + "6.B(8)": [ + "IRO-10.2" + ], + "6.B(9)": [ + "IRO-10.2" + ], + "6.B(10)": [ + "IRO-10.2" + ], + "6.B(11)": [ + "IRO-10.2" + ], + "6.B(12)": [ + "IRO-10.2" + ], + "6.B(13)": [ + "IRO-10.2" + ], + "6.E(2)(a)": [ + "IRO-10.2" + ], + "6.E(2)(b)": [ + "IRO-10.2" + ], + "6.F": [ + "IRO-10.2" + ], + "4.D(2)(c)": [ + "PES-01", + "PES-02" + ], + "4.D(3)": [ + "RSK-01" + ], + "4.D(5)": [ + "SAT-02", + "SAT-03" + ], + "4.D(2)(e)": [ + "TDA-01", + "TDA-06" + ], + "4.F(1)": [ + "TPM-01" + ], + "4.F(2)": [ + "TPM-05" + ], + "4.G": [ + "TPM-08" + ], + "4.D(4)": [ + "THR-01", + "VPM-01" + ], + "4.C(2)": [ + "THR-09", + "THR-10" + ], + "4.C(3)": [ + "THR-10" + ] + }, + "general-nist-100-1-ai-rmf": { + "GOVERN 2.3": [ + "GOV-01.1", + "GOV-01.2", + "GOV-04" + ], + "MAP 3.5": [ + "GOV-01.1", + "GOV-01.2", + "GOV-02", + "AAT-01", + "OPS-01", + "OPS-01.1" + ], + "MAP 5.2": [ + "GOV-01.1", + "GOV-05", + "AAT-01", + "AAT-11" + ], + "GOVERN 1.0": [ + "GOV-02", + "AAT-01", + "OPS-01.1" + ], + "GOVERN 1.2": [ + "GOV-02", + "AAT-01.2", + "SEA-01", + "SEA-01.1", + "OPS-01", + "OPS-01.1", + "TDA-01", + "TDA-01.1" + ], + "GOVERN 1.3": [ + "GOV-02", + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "CPL-01.2", + "RSK-01", + "RSK-01.1", + "RSK-01.2", + "RSK-01.3", + "OPS-01", + "OPS-01.1" + ], + "GOVERN 1.4": [ + "GOV-02", + "RSK-01", + "RSK-01.1", + "RSK-01.2", + "OPS-01", + "OPS-01.1" + ], + "GOVERN 3.2": [ + "GOV-02", + "AAT-08", + "OPS-01", + "OPS-01.1" + ], + "GOVERN 4.1": [ + "GOV-02", + "AAT-01", + "HRS-01", + "HRS-03.1", + "HRS-03.2", + "HRS-04.1", + "HRS-05.1", + "HRS-05.4", + "OPS-01", + "OPS-01.1", + "SAT-01", + "TDA-01.1", + "TDA-02.3" + ], + "GOVERN 5.1": [ + "GOV-02", + "AAT-11.1", + "OPS-01", + "OPS-01.1", + "TDA-01.1" + ], + "GOVERN 6.0": [ + "GOV-02", + "RSK-09.2", + "OPS-01", + "OPS-01.1", + "TDA-01.1" + ], + "GOVERN 6.1": [ + "GOV-02", + "AAT-12", + "OPS-01", + "OPS-01.1" + ], + "GOVERN 2.1": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "AAT-01", + "AAT-08", + "HRS-03" + ], + "GOVERN 5.0": [ + "GOV-04", + "GOV-04.1", + "AAT-11", + "AST-01.2", + "CHG-05" + ], + "GOVERN 2.0": [ + "GOV-04.1", + "AST-01", + "AST-01.2", + "HRS-03", + "HRS-04.1", + "HRS-05.1", + "HRS-05.4", + "SAT-01", + "SAT-03" + ], + "MANAGE 2.4": [ + "GOV-04.1", + "AAT-15.2", + "IRO-01", + "IRO-02", + "RSK-06.1" + ], + "GOVERN 1.5": [ + "GOV-05", + "CPL-02", + "CPL-03", + "CPL-04", + "RSK-01", + "RSK-04", + "RSK-04.1", + "RSK-08" + ], + "MEASURE 1.0": [ + "GOV-05", + "AAT-16.2" + ], + "MEASURE 1.1": [ + "GOV-05", + "AAT-16.2", + "AAT-16.3" + ], + "MEASURE 1.2": [ + "GOV-05", + "AAT-16.2" + ], + "MEASURE 4.0": [ + "GOV-05", + "AAT-16.4" + ], + "MEASURE 4.3": [ + "GOV-05", + "GOV-05.1", + "GOV-05.2", + "AAT-16.6" + ], + "MEASURE 4.1": [ + "GOV-05.1", + "GOV-05.2", + "AAT-16.1" + ], + "MAP 1.3": [ + "GOV-08", + "AAT-03.1", + "PRM-01.1" + ], + "GOVERN 4.0": [ + "GOV-14", + "GOV-15", + "RSK-12" + ], + "GOVERN 1.1": [ + "AAT-01.1", + "AST-01.2", + "CPL-01", + "CPL-01.2" + ], + "MEASURE 2.5": [ + "AAT-01.2", + "AAT-10.9" + ], + "MANAGE 2.2": [ + "AAT-01.3", + "PRM-01", + "PRM-07", + "TDA-01.1" + ], + "GOVERN 1.6": [ + "AAT-02", + "AST-02", + "BCD-02", + "DCH-02" + ], + "MAP 4.1": [ + "AAT-02.1" + ], + "MAP 4.2": [ + "AAT-02.2" + ], + "MAP 1.0": [ + "AAT-03", + "PRM-06" + ], + "MAP 1.1": [ + "AAT-03", + "AAT-04", + "PRM-06", + "RSK-08", + "RSK-10" + ], + "MAP 1.4": [ + "AAT-03", + "AAT-03.1", + "PRM-06" + ], + "MAP 3.0": [ + "AAT-03", + "AAT-03.1", + "AAT-04" + ], + "MAP 3.1": [ + "AAT-04", + "AAT-04.1" + ], + "MAP 3.2": [ + "AAT-04", + "AAT-04.2", + "RSK-01.3" + ], + "MAP 3.3": [ + "AAT-04.3", + "CPL-01.2" + ], + "MAP 4.0": [ + "AAT-04.4" + ], + "GOVERN 3.0": [ + "AAT-06" + ], + "GOVERN 3.1": [ + "AAT-07", + "TDA-01", + "TDA-01.1" + ], + "MAP 5.0": [ + "AAT-07.1" + ], + "MAP 5.1": [ + "AAT-07.2", + "RSK-02.1", + "RSK-08" + ], + "MANAGE 2.0": [ + "AAT-07.3", + "TDA-01", + "TDA-01.1" + ], + "MAP 1.2": [ + "AAT-08", + "AAT-13", + "HRS-03.2" + ], + "GOVERN 4.2": [ + "AAT-09", + "TDA-01", + "TDA-01.1", + "TDA-02.3", + "TDA-04", + "TDA-05" + ], + "GOVERN 4.3": [ + "AAT-10", + "IAO-01" + ], + "MEASURE 2.2": [ + "AAT-10", + "AAT-17", + "AAT-17.1" + ], + "MEASURE 2.0": [ + "AAT-10.1", + "AAT-10.3", + "IAO-02", + "IAO-06" + ], + "MAP 2.3": [ + "AAT-10.2", + "IAO-02.2" + ], + "MEASURE 2.1": [ + "AAT-10.2" + ], + "MEASURE 2.6": [ + "AAT-10.4", + "AAT-10.13", + "AAT-11.2" + ], + "MEASURE 2.7": [ + "AAT-10.5", + "SEA-01.2" + ], + "MEASURE 2.8": [ + "AAT-10.6" + ], + "MEASURE 2.10": [ + "AAT-10.7", + "RSK-10" + ], + "MEASURE 2.11": [ + "AAT-10.8" + ], + "MEASURE 2.9": [ + "AAT-10.9" + ], + "MEASURE 2.13": [ + "AAT-10.10", + "AAT-10.11" + ], + "MANAGE 1.1": [ + "AAT-10.10", + "AAT-15", + "AAT-15.1", + "AAT-15.2", + "IAO-01", + "IAO-05", + "IAO-07" + ], + "MEASURE 2.3": [ + "AAT-10.12" + ], + "MEASURE 2.4": [ + "AAT-10.13", + "AAT-16" + ], + "MANAGE 4.1": [ + "AAT-10.13", + "AAT-11.1", + "AAT-11.2", + "AAT-11.3" + ], + "MANAGE 4.2": [ + "AAT-10.14" + ], + "GOVERN 5.2": [ + "AAT-11.1", + "TDA-01.1" + ], + "MEASURE 1.3": [ + "AAT-11.2" + ], + "MEASURE 3.3": [ + "AAT-11.3" + ], + "MANAGE 4.3": [ + "AAT-11.4", + "IRO-10" + ], + "MAP 3.4": [ + "AAT-13.1", + "HRS-03.2" + ], + "MAP 1.6": [ + "AAT-14", + "PRI-01", + "PRI-05.4", + "PRM-05" + ], + "MAP 2.1": [ + "AAT-14.1", + "PRM-06", + "TDA-01.1" + ], + "MAP 2.2": [ + "AAT-14.2" + ], + "MANAGE 1.2": [ + "AAT-15.1", + "AAT-15.2", + "IAO-05", + "RSK-02.1", + "RSK-05", + "RSK-06" + ], + "MANAGE 1.4": [ + "AAT-15.1", + "IAO-05", + "RSK-04.1" + ], + "MEASURE 3.0": [ + "AAT-16.2", + "IAO-05", + "RSK-04.1" + ], + "MEASURE 4.2": [ + "AAT-16.5" + ], + "MANAGE 3.2": [ + "AAT-16.7" + ], + "MEASURE 3.1": [ + "AAT-17", + "IAO-02.2", + "IAO-05", + "RSK-04.1" + ], + "MEASURE 2.12": [ + "AAT-17.2" + ], + "MANAGE 2.3": [ + "AAT-17.3", + "IRO-01", + "IRO-02", + "RSK-03", + "RSK-06.1" + ], + "MEASURE 3.2": [ + "AAT-18", + "IAO-02.2", + "IAO-05", + "RSK-04.1" + ], + "MANAGE 1.0": [ + "AAT-18.1", + "RSK-01", + "RSK-03", + "RSK-04" + ], + "GOVERN 1.7": [ + "AST-09", + "AST-30", + "PRM-07", + "SEA-02.3", + "TDA-17" + ], + "MAP 2.0": [ + "AST-31", + "AST-31.1" + ], + "GOVERN 6.2": [ + "BCD-01", + "BCD-16", + "IRO-01", + "IRO-02", + "IRO-02.4", + "IRO-04" + ], + "MANAGE 4.0": [ + "IRO-04", + "IAO-03", + "IAO-05", + "RSK-06", + "RSK-06.1" + ], + "MANAGE 1.3": [ + "IAO-05", + "RSK-06.1" + ], + "MANAGE 3.1": [ + "IAO-05", + "RSK-09.1", + "RSK-09.2", + "TPM-04.1", + "TPM-08" + ], + "MANAGE 2.1": [ + "PRM-01", + "PRM-02", + "PRM-03", + "RSK-01.2", + "RSK-06.2" + ], + "MAP 1.5": [ + "RSK-01.3" + ], + "MANAGE 3.0": [ + "RSK-09", + "RSK-09.2", + "TPM-01", + "TPM-08" + ], + "GOVERN 2.2": [ + "SAT-03", + "SAT-03.5", + "SAT-03.6" + ] + }, + "general-nist-600-1-gen-ai-profile": { + "GOVERN 1.1": [ + "GOV-01", + "CPL-01" + ], + "GOVERN 1.2": [ + "GOV-01", + "AAT-01", + "OPS-01.1" + ], + "GV-1.2-002": [ + "GOV-01", + "AAT-01" + ], + "GV-1.4-001": [ + "GOV-01" + ], + "GV-1.4-002": [ + "GOV-01" + ], + "GOVERN 4.1": [ + "GOV-01", + "AAT-01" + ], + "GV-1.3-004": [ + "GOV-01.1" + ], + "GV-1.5-002": [ + "GOV-02", + "AAT-01", + "OPS-01.1" + ], + "GV-1.3-002": [ + "GOV-05", + "GOV-05.1" + ], + "MS-2.7-004": [ + "GOV-05" + ], + "GV-2.1-004": [ + "GOV-06", + "AAT-01", + "AAT-09.1", + "AAT-16.9" + ], + "GV-1.2-001": [ + "AAT-01" + ], + "GV-1.3-005": [ + "AAT-01", + "AAT-02.1" + ], + "GV-1.5-003": [ + "AAT-01", + "AAT-10", + "DCH-18" + ], + "GOVERN 1.7": [ + "AAT-01", + "AST-30" + ], + "GV-1.7-001": [ + "AAT-01" + ], + "GV-2.1-001": [ + "AAT-01", + "AAT-08" + ], + "GV-2.1-002": [ + "AAT-01", + "AAT-08" + ], + "GV-3.2-001": [ + "AAT-01" + ], + "GV-3.2-003": [ + "AAT-01", + "TDA-21" + ], + "GV-3.2-004": [ + "AAT-01", + "AAT-11.3" + ], + "GV-4.1-001": [ + "AAT-01" + ], + "GV-4.1-002": [ + "AAT-01", + "AAT-02.1", + "AAT-07.2", + "AAT-15", + "AAT-15.2" + ], + "GV-4.1-003": [ + "AAT-01", + "AAT-11" + ], + "GV-4.3-002": [ + "AAT-01", + "AAT-16.8", + "AAT-16.9", + "MON-01" + ], + "GOVERN 6.1": [ + "AAT-01", + "AAT-12" + ], + "GV-6.1-009": [ + "AAT-01", + "TPM-01", + "TPM-04.1" + ], + "GOVERN 6.2": [ + "AAT-01", + "AAT-10", + "AAT-11.4" + ], + "GV-6.2-005": [ + "AAT-01", + "AAT-09", + "TDA-01.1" + ], + "MP-3.4-003": [ + "AAT-01", + "CPL-01.4", + "TDA-01.1" + ], + "MAP 4.1": [ + "AAT-01", + "AAT-02.1" + ], + "MP-4.1-003": [ + "AAT-01", + "TDA-22" + ], + "MP-4.1-005": [ + "AAT-01", + "AAT-10.8" + ], + "MS-2.5-006": [ + "AAT-01" + ], + "MG-2.3-001": [ + "AAT-01", + "BCD-01", + "IRO-04" + ], + "MG-4.1-003": [ + "AAT-01", + "AAT-10" + ], + "MS-2.9-002": [ + "AAT-01.1", + "AAT-04.1", + "AAT-10", + "AAT-20.2" + ], + "MANAGE 2.2": [ + "AAT-01.3" + ], + "GOVERN 1.6": [ + "AAT-02", + "AST-02" + ], + "GV-1.6-001": [ + "AAT-02", + "AST-02" + ], + "GV-1.6-002": [ + "AAT-02", + "AST-02" + ], + "MANAGE 3.1": [ + "AAT-02", + "AAT-04.4" + ], + "GV-4.2-002": [ + "AAT-02.1", + "AAT-09", + "AAT-11", + "AAT-11.3", + "RSK-03" + ], + "MP-1.1-004": [ + "AAT-02.1", + "AAT-09", + "AAT-27", + "TDA-01.1" + ], + "MG-3.1-001": [ + "AAT-02.3" + ], + "MAP 1.1": [ + "AAT-03" + ], + "MP-1.1-001": [ + "AAT-03" + ], + "MP-1.1-002": [ + "AAT-03", + "AAT-07.2" + ], + "GV-2.1-003": [ + "AAT-05" + ], + "MS-3.3-004": [ + "AAT-05" + ], + "MS-2.2-001": [ + "AAT-06", + "AAT-10.8", + "AAT-12.1" + ], + "MS-2.11-001": [ + "AAT-06", + "AAT-10.8", + "AAT-26" + ], + "MS-3.3-003": [ + "AAT-06" + ], + "GOVERN 1.4": [ + "AAT-07", + "RSK-01" + ], + "MP-1.1-003": [ + "AAT-07", + "AAT-09" + ], + "MAP 1.2": [ + "AAT-07" + ], + "MP-1.2-001": [ + "AAT-07" + ], + "MP-5.1-002": [ + "AAT-07", + "AAT-07.2", + "AAT-10.17", + "AAT-12.1", + "AAT-12.3" + ], + "MEASURE 1.1": [ + "AAT-07", + "AAT-16.4" + ], + "MS-2.8-001": [ + "AAT-07", + "AAT-12" + ], + "MS-2.11-003": [ + "AAT-07" + ], + "MEASURE 3.2": [ + "AAT-07" + ], + "MS-3.2-001": [ + "AAT-07" + ], + "MANAGE 1.3": [ + "AAT-07", + "AAT-09" + ], + "GV-4.2-003": [ + "AAT-07.1" + ], + "MAP 5.1": [ + "AAT-07.1", + "AAT-07.2" + ], + "MP-5.2-001": [ + "AAT-07.1", + "AAT-07.2", + "AAT-18" + ], + "MP-5.2-002": [ + "AAT-07.1", + "AAT-11" + ], + "MS-1.3-002": [ + "AAT-07.1", + "AAT-10", + "AAT-11", + "VPM-10" + ], + "MS-3.3-001": [ + "AAT-07.1" + ], + "GOVERN 4.2": [ + "AAT-07.2", + "AAT-09" + ], + "GV-5.1-002": [ + "AAT-07.2" + ], + "MP-4.1-008": [ + "AAT-07.2", + "AAT-10" + ], + "MP-5.1-006": [ + "AAT-07.2" + ], + "MANAGE 4.2": [ + "AAT-07.3" + ], + "MG-4.2-001": [ + "AAT-07.3" + ], + "GOVERN 1.5": [ + "AAT-08", + "HRS-03" + ], + "GV-1.5-001": [ + "AAT-08", + "AAT-12.1", + "HRS-03" + ], + "GOVERN 2.1": [ + "AAT-08" + ], + "GOVERN 3.2": [ + "AAT-08" + ], + "MP-3.4-005": [ + "AAT-08" + ], + "GV-1.3-003": [ + "AAT-10" + ], + "GOVERN 4.3": [ + "AAT-10" + ], + "GV-4.3-003": [ + "AAT-10", + "AAT-11" + ], + "MAP 2.3": [ + "AAT-10", + "AAT-12.2" + ], + "MP-2.3-005": [ + "AAT-10" + ], + "MP-4.1-007": [ + "AAT-10" + ], + "MP-5.1-001": [ + "AAT-10" + ], + "MS-2.6-003": [ + "AAT-10", + "AAT-10.10" + ], + "MEASURE 2.9": [ + "AAT-10", + "AAT-20.1" + ], + "MEASURE 2.13": [ + "AAT-10" + ], + "MS-4.2-001": [ + "AAT-10", + "AAT-26" + ], + "MG-2.2-007": [ + "AAT-10" + ], + "MG-3.1-002": [ + "AAT-10" + ], + "MAP 3.4": [ + "AAT-10.1" + ], + "MEASURE 4.2": [ + "AAT-10.1" + ], + "MG-3.1-003": [ + "AAT-10.1", + "AAT-11.2" + ], + "MANAGE 4.1": [ + "AAT-10.1", + "AAT-16.5", + "AAT-16.8" + ], + "MS-1.1-003": [ + "AAT-10.2" + ], + "MEASURE 2.5": [ + "AAT-10.3" + ], + "GV-1.3-006": [ + "AAT-10.4" + ], + "MG-1.3-001": [ + "AAT-10.4", + "AAT-15.1" + ], + "MG-2.2-001": [ + "AAT-10.4" + ], + "MG-3.2-009": [ + "AAT-10.4" + ], + "MEASURE 2.7": [ + "AAT-10.5" + ], + "MS-2.7-001": [ + "AAT-10.5" + ], + "MEASURE 2.8": [ + "AAT-10.6" + ], + "MG-4.1-005": [ + "AAT-10.6" + ], + "MEASURE 2.10": [ + "AAT-10.7" + ], + "MEASURE 2.11": [ + "AAT-10.8" + ], + "MS-2.11-002": [ + "AAT-10.8" + ], + "MS-2.11-004": [ + "AAT-10.8" + ], + "MS-3.3-005": [ + "AAT-10.8", + "AAT-11" + ], + "MG-2.2-004": [ + "AAT-10.8" + ], + "MG-3.2-003": [ + "AAT-10.8" + ], + "MG-4.1-002": [ + "AAT-10.11" + ], + "MP-2.3-002": [ + "AAT-10.13" + ], + "MP-4.1-001": [ + "AAT-10.13", + "PRI-01.6" + ], + "MS-1.1-006": [ + "AAT-10.13", + "AAT-11" + ], + "MANAGE 3.2": [ + "AAT-10.13" + ], + "MG-4.1-007": [ + "AAT-10.13" + ], + "MS-2.3-003": [ + "AAT-10.15" + ], + "MS-2.3-002": [ + "AAT-10.16" + ], + "MS-2.5-001": [ + "AAT-10.16" + ], + "GV-6.1-003": [ + "AAT-10.17", + "AAT-12.1" + ], + "MS-1.1-002": [ + "AAT-10.17", + "AAT-26", + "MON-16" + ], + "MS-2.7-002": [ + "AAT-10.17" + ], + "MS-2.7-005": [ + "AAT-10.17", + "AAT-12.2" + ], + "MS-2.10-003": [ + "AAT-10.18", + "AAT-12.1" + ], + "MS-2.11-005": [ + "AAT-10.18" + ], + "GV-4.2-001": [ + "AAT-11", + "HRS-05.4" + ], + "GOVERN 5.1": [ + "AAT-11" + ], + "GV-5.1-001": [ + "AAT-11", + "AAT-11.1", + "AAT-11.3" + ], + "MP-5.1-004": [ + "AAT-11", + "AAT-11.3" + ], + "MAP 5.2": [ + "AAT-11" + ], + "MS-1.1-007": [ + "AAT-11", + "AAT-12.2" + ], + "MS-1.1-008": [ + "AAT-11", + "AAT-26.3", + "TDA-01.1", + "TDA-21", + "VPM-10" + ], + "MS-1.3-001": [ + "AAT-11" + ], + "MG-2.4-001": [ + "AAT-11" + ], + "MP-1.2-002": [ + "AAT-11.1", + "AAT-11.3" + ], + "MEASURE 1.3": [ + "AAT-11.1" + ], + "MS-2.10-002": [ + "AAT-11.1", + "AAT-11.3" + ], + "MS-4.2-005": [ + "AAT-11.1", + "AAT-11.3" + ], + "MG-2.2-006": [ + "AAT-11.1", + "AAT-11.3" + ], + "MG-3.2-007": [ + "AAT-11.1" + ], + "MS-2.7-009": [ + "AAT-11.2" + ], + "MS-1.1-004": [ + "AAT-11.3" + ], + "MS-2.7-003": [ + "AAT-11.3" + ], + "MEASURE 3.3": [ + "AAT-11.3" + ], + "MG-2.2-008": [ + "AAT-11.3" + ], + "MG-3.2-004": [ + "AAT-11.3" + ], + "MANAGE 4.3": [ + "AAT-11.4" + ], + "GV-6.1-001": [ + "AAT-12", + "AAT-12.1" + ], + "MP-4.1-002": [ + "AAT-12" + ], + "MP-4.1-006": [ + "AAT-12", + "AAT-12.2" + ], + "MP-4.1-010": [ + "AAT-12", + "TDA-22" + ], + "MS-2.6-002": [ + "AAT-12", + "AAT-17.1", + "AAT-17.2" + ], + "MG-3.1-004": [ + "AAT-12", + "AAT-26" + ], + "GV-6.1-004": [ + "AAT-12.1", + "IAO-03.2", + "TPM-05" + ], + "GV-6.1-008": [ + "AAT-12.1", + "AAT-12.4" + ], + "MP-2.1-001": [ + "AAT-12.1", + "AAT-12.3", + "RSK-01.1" + ], + "MP-2.1-002": [ + "AAT-12.1", + "AAT-12.2" + ], + "MP-2.2-001": [ + "AAT-12.1" + ], + "MS-2.2-002": [ + "AAT-12.1", + "AAT-26", + "DCH-23" + ], + "MS-2.5-003": [ + "AAT-12.1", + "AAT-26" + ], + "MS-2.5-005": [ + "AAT-12.1" + ], + "MG-2.2-002": [ + "AAT-12.1", + "AAT-12.2" + ], + "MG-2.2-003": [ + "AAT-12.1", + "AAT-12.2", + "AAT-16.4" + ], + "MG-4.1-006": [ + "AAT-12.1", + "AAT-12.2" + ], + "MS-2.7-007": [ + "AAT-12.2", + "VPM-10" + ], + "MP-3.4-001": [ + "AAT-12.3" + ], + "MS-1.1-001": [ + "AAT-12.4" + ], + "MAP 2.1": [ + "AAT-14.1" + ], + "MAP 2.2": [ + "AAT-14.2" + ], + "MS-4.2-004": [ + "AAT-15.2" + ], + "MANAGE 2.4": [ + "AAT-15.2" + ], + "MG-2.4-002": [ + "AAT-15.2" + ], + "MG-2.4-004": [ + "AAT-15.2" + ], + "MEASURE 2.6": [ + "AAT-16" + ], + "GV4.3--001": [ + "AAT-16.2" + ], + "MG-1.3-002": [ + "AAT-16.2" + ], + "MS-1.1-009": [ + "AAT-16.3" + ], + "MP-2.3-001": [ + "AAT-16.5" + ], + "MG-4.1-001": [ + "AAT-16.5" + ], + "MP-4.1-004": [ + "AAT-16.7" + ], + "MS-2.12-001": [ + "AAT-17", + "AAT-17.1", + "EMB-15" + ], + "MG-4.3-002": [ + "AAT-17" + ], + "MEASURE 2.2": [ + "AAT-17.1" + ], + "MS-2.6-001": [ + "AAT-17.1" + ], + "MS-2.8-004": [ + "AAT-17.1" + ], + "MEASURE 2.12": [ + "AAT-17.2" + ], + "MS-2.12-002": [ + "AAT-17.2" + ], + "MS-2.12-003": [ + "AAT-17.2" + ], + "MS-2.12-004": [ + "AAT-17.2" + ], + "MANAGE 2.3": [ + "AAT-17.3" + ], + "MS-1.1-005": [ + "AAT-17.4" + ], + "MS-2.7-008": [ + "AAT-17.5" + ], + "GV-1.3-007": [ + "AAT-18.1" + ], + "MG-2.4-003": [ + "AAT-18.1" + ], + "MS-2.6-005": [ + "AAT-19" + ], + "MS-2.10-001": [ + "AAT-19", + "AAT-19.8", + "VPM-10" + ], + "MP-2.2-002": [ + "AAT-20.1", + "NET-05.1" + ], + "MS-2.8-003": [ + "AAT-20.1", + "AAT-26.1" + ], + "MS-4.2-003": [ + "AAT-20.1" + ], + "MG-3.1-005": [ + "AAT-20.1" + ], + "MEASURE 2.3": [ + "AAT-20.2" + ], + "MS-2.5-002": [ + "AAT-20.3" + ], + "MP-5.1-003": [ + "AAT-22.7", + "AAT-22.8" + ], + "MP-4.1-009": [ + "AAT-23", + "AAT-27", + "SEA-09" + ], + "GV-6.2-001": [ + "AAT-25", + "AAT-25.1" + ], + "MS-4.2-002": [ + "AAT-25" + ], + "GV-6.2-006": [ + "AAT-25.1" + ], + "MP-2.3-003": [ + "AAT-26" + ], + "MS-2.6-004": [ + "AAT-26" + ], + "MS-2.9-001": [ + "AAT-26", + "TDA-22" + ], + "MP-2.3-004": [ + "AAT-26.1" + ], + "MS-2.5-004": [ + "AAT-26.1" + ], + "MP-3.4-004": [ + "AAT-26.2" + ], + "MP-3.4-006": [ + "AAT-26.3" + ], + "MS-2.8-002": [ + "AAT-26.4" + ], + "MG-2.2-005": [ + "AAT-27" + ], + "MG-3.2-005": [ + "AAT-27" + ], + "MG-3.2-008": [ + "AAT-27.1" + ], + "GV-1.1-001": [ + "CPL-01" + ], + "MG-4.3-003": [ + "CPL-01", + "IRO-10.2" + ], + "MS-2.3-001": [ + "CFG-02" + ], + "GV-6.2-002": [ + "CFG-04.1", + "TPM-04" + ], + "GV-6.2-004": [ + "MON-01" + ], + "MG-3.2-006": [ + "MON-01.2", + "MON-05.1" + ], + "MS-2.2-004": [ + "DCH-23" + ], + "GV-6.1-010": [ + "HRS-05.1", + "HRS-05.3", + "TPM-05" + ], + "MS-1.3-003": [ + "HRS-11" + ], + "GV-2.1-005": [ + "HRS-15" + ], + "GV-6.2-003": [ + "IRO-04", + "IRO-06", + "TPM-11" + ], + "MG-4.2-002": [ + "IRO-04", + "IRO-13" + ], + "MG-4.3-001": [ + "IRO-10", + "IRO-13" + ], + "MS-2.2-003": [ + "PRI-03.4" + ], + "GOVERN 1.3": [ + "OPS-01.1" + ], + "MP-3.4-002": [ + "SAT-01.1" + ], + "GV-6.1-002": [ + "SAT-02" + ], + "GV-3.2-005": [ + "TDA-06.2" + ], + "MS-2.3-004": [ + "TDA-07" + ], + "MS-2.6-006": [ + "TDA-09.4" + ], + "GV-6.2-007": [ + "TPM-01", + "TPM-05" + ], + "GV-6.1-007": [ + "TPM-01.1" + ], + "GV-6.1-005": [ + "TPM-04.1" + ], + "GV-6.1-006": [ + "TPM-04.1" + ], + "MS-2.7-006": [ + "VPM-05.3" + ], + "MS-2.6-007": [ + "VPM-06" + ], + "MP-5.1-005": [ + "VPM-10" + ] + }, + "general-nist-privacy-framework-1-0": { + "ID-P": [ + "GOV-01" + ], + "ID.BE-P": [ + "GOV-01" + ], + "GV-P": [ + "GOV-01" + ], + "GV.PO-P1": [ + "GOV-01", + "GOV-02", + "DCH-01", + "PRI-01", + "PRI-01.3" + ], + "GV.PO-P6": [ + "GOV-01", + "GOV-02", + "PRI-01", + "RSK-01" + ], + "CM-P": [ + "GOV-01" + ], + "CM.PO-P": [ + "GOV-01" + ], + "PR-P": [ + "GOV-01" + ], + "PR.PT-P": [ + "GOV-01" + ], + "PR.PO-P6": [ + "GOV-01.2", + "GOV-05" + ], + "PR.PO-P5": [ + "GOV-01.3", + "GOV-05", + "CPL-02" + ], + "ID.DE-P1": [ + "GOV-02", + "RSK-01" + ], + "GV.PO-P": [ + "GOV-02" + ], + "GV.MT-P": [ + "GOV-02", + "PRI-01" + ], + "GV.MT-P4": [ + "GOV-02", + "GOV-05", + "CPL-02", + "IAO-05" + ], + "GV.MT-P5": [ + "GOV-02", + "IRO-02", + "PRI-01.11" + ], + "GV.MT-P6": [ + "GOV-02", + "IRO-13" + ], + "GV.MT-P7": [ + "GOV-02", + "PRI-06.4" + ], + "CT.PO-P": [ + "GOV-02" + ], + "CT.PO-P1": [ + "GOV-02", + "PRI-01.11", + "PRI-03", + "PRI-03.2", + "PRI-05.4", + "PRM-04", + "PRM-05", + "PRM-06", + "PRM-07" + ], + "CT.PO-P2": [ + "GOV-02", + "PRI-01", + "PRI-01.4", + "PRI-05.4", + "PRI-07" + ], + "CT.PO-P3": [ + "GOV-02", + "PRI-03", + "PRI-03.1", + "PRI-03.2" + ], + "CM.PO-P1": [ + "GOV-02", + "PRI-01", + "PRI-01.2", + "PRI-01.3", + "PRI-02", + "PRI-02.1", + "PRI-06.2" + ], + "PR.PO-P": [ + "GOV-02" + ], + "PR.PO-P4": [ + "GOV-02", + "PES-01" + ], + "GV.MT-P2": [ + "GOV-03" + ], + "GV.PO-P3": [ + "GOV-04", + "HRS-03", + "PRI-01.1", + "PRI-01.4", + "PRI-01.8", + "TPM-05.4", + "TPM-06" + ], + "CM.PO-P2": [ + "GOV-04", + "HRS-03", + "HRS-04.1", + "PRI-01.4" + ], + "ID.IM-P5": [ + "GOV-08", + "AST-02.8", + "PRM-06", + "OPS-03" + ], + "ID.BE-P1": [ + "GOV-08", + "PRI-07.2", + "PRM-06" + ], + "ID.BE-P2": [ + "GOV-08" + ], + "GV.RM-P3": [ + "GOV-08", + "PRM-06", + "RSK-01.1", + "RSK-01.5" + ], + "GV.PO-P2": [ + "GOV-14", + "GOV-15", + "HRS-03", + "HRS-03.1", + "SEA-01", + "SEA-01.1", + "SEA-02", + "SEA-02.1" + ], + "ID.IM-P": [ + "AST-01", + "DCH-01" + ], + "PR.DS-P3": [ + "AST-01" + ], + "ID.IM-P8": [ + "AST-01.1", + "AST-01.2", + "AST-02.8", + "AST-04", + "DCH-19" + ], + "ID.IM-P1": [ + "AST-02", + "TPM-01.1" + ], + "ID.IM-P4": [ + "AST-02.8" + ], + "ID.IM-P6": [ + "AST-02.8", + "PRI-05.5", + "PRI-05.6" + ], + "ID.IM-P2": [ + "AST-03", + "AST-03.1", + "TPM-05.4" + ], + "ID.IM-P7": [ + "AST-04", + "DCH-19", + "IAO-03", + "RSK-10" + ], + "PR.PO-P7": [ + "BCD-01", + "IRO-04" + ], + "ID.BE-P3": [ + "BCD-02", + "HRS-05.4", + "IAO-03", + "PRM-06", + "OPS-02", + "TDA-06.1", + "TPM-02" + ], + "PR.PO-P8": [ + "BCD-04", + "IRO-06" + ], + "PR.PO-P3": [ + "BCD-11" + ], + "PR.PT-P4": [ + "BCD-12.2" + ], + "PR.DS-P4": [ + "CAP-01", + "CAP-03" + ], + "PR.PO-P2": [ + "CHG-01", + "CHG-02" + ], + "GV.PO-P5": [ + "CPL-01", + "PRI-01", + "PRI-01.11" + ], + "ID.DE-P5": [ + "CPL-03", + "RSK-04", + "RSK-07", + "RSK-09.1", + "TPM-04.1", + "TPM-08" + ], + "CT.DM-P9": [ + "CPL-03", + "CPL-03.2" + ], + "PR.PO-P1": [ + "CFG-01", + "CFG-02" + ], + "CT.DP-P4": [ + "CFG-02" + ], + "PR.PT-P2": [ + "CFG-02", + "CFG-03" + ], + "CT.DM-P8": [ + "MON-01", + "MON-02.2", + "DCH-18.1" + ], + "PR.DS-P6": [ + "MON-01.7", + "END-06", + "END-06.1", + "END-06.3" + ], + "PR.DS-P2": [ + "CRY-03" + ], + "PR.AC-P5": [ + "CRY-04", + "NET-02", + "NET-06" + ], + "PR.DS-P1": [ + "CRY-05" + ], + "CT.DM-P1": [ + "DCH-01", + "DCH-01.2" + ], + "CT.DM-P2": [ + "DCH-01", + "DCH-01.2" + ], + "CT.DM-P3": [ + "DCH-01", + "DCH-18" + ], + "CT.DM-P4": [ + "DCH-01", + "DCH-18" + ], + "PR.DS-P": [ + "DCH-01" + ], + "CT.DM-P7": [ + "DCH-05" + ], + "ID.IM-P3": [ + "DCH-06.2", + "PRI-05.5", + "PRI-05.6", + "PRI-05.7" + ], + "CT.DM-P5": [ + "DCH-09" + ], + "PR.PT-P1": [ + "DCH-12" + ], + "CT.DP-P2": [ + "DCH-23" + ], + "CT.DP-P3": [ + "DCH-23", + "IAC-09.6" + ], + "PR.DS-P8": [ + "END-06.1" + ], + "PR.PO-P9": [ + "HRS-01", + "PRI-01" + ], + "PR.AC-P4": [ + "HRS-11", + "IAC-21" + ], + "PR.AC-P": [ + "IAC-01" + ], + "PR.AC-P1": [ + "IAC-01" + ], + "PR.AC-P6": [ + "IAC-02", + "IAC-03", + "IAC-04" + ], + "CT.DP-P5": [ + "IAC-09.6" + ], + "CM.AW-P7": [ + "IRO-04.1", + "IRO-10", + "IRO-10.2" + ], + "CM.AW-P8": [ + "IRO-04.1", + "IRO-16" + ], + "PR.DS-P5": [ + "IRO-12", + "SEA-01" + ], + "ID.DE-P3": [ + "IAO-03.2", + "PRI-07.1", + "RSK-09", + "RSK-10", + "TPM-05" + ], + "PR.MA-P": [ + "MNT-01" + ], + "PR.MA-P1": [ + "MNT-01" + ], + "PR.MA-P2": [ + "MNT-05" + ], + "PR.PT-P3": [ + "NET-01", + "NET-02" + ], + "PR.AC-P3": [ + "NET-14", + "NET-14.5" + ], + "PR.AC-P2": [ + "PES-01", + "PES-03", + "PES-03.4", + "PES-04", + "PES-04.1" + ], + "CT-P": [ + "PRI-01" + ], + "CT.DM-P": [ + "PRI-01" + ], + "CT.DP-P": [ + "PRI-01" + ], + "CM.AW-P": [ + "PRI-01" + ], + "CM.AW-P1": [ + "PRI-01.3", + "PRI-02" + ], + "GV.MT-P3": [ + "PRI-01.11" + ], + "CM.AW-P2": [ + "PRI-01.11", + "PRI-06.4" + ], + "CM.AW-P3": [ + "PRI-01.11", + "PRM-04", + "PRM-07", + "SEA-01" + ], + "CT.DM-P10": [ + "PRI-01.12" + ], + "CT.PO-P4": [ + "PRI-06.2", + "PRI-06.4", + "PRI-10", + "PRM-04", + "PRM-07" + ], + "ID.DE-P4": [ + "PRI-06.6", + "SEA-01" + ], + "CT.DM-P6": [ + "PRI-06.6", + "PRI-06.7" + ], + "CM.AW-P5": [ + "PRI-07.3" + ], + "CM.AW-P4": [ + "PRI-09", + "PRI-14", + "PRI-14.1" + ], + "CM.AW-P6": [ + "PRI-09", + "PRI-14" + ], + "ID.RA-P": [ + "RSK-01" + ], + "ID.DE-P": [ + "RSK-01" + ], + "GV.RM-P": [ + "RSK-01" + ], + "GV.RM-P1": [ + "RSK-01" + ], + "GV.RM-P2": [ + "RSK-01.3" + ], + "GV.MT-P1": [ + "RSK-04", + "RSK-07", + "RSK-09.1", + "RSK-10" + ], + "ID.DE-P2": [ + "RSK-09", + "RSK-10" + ], + "ID.RA-P1": [ + "RSK-10" + ], + "ID.RA-P2": [ + "RSK-10" + ], + "ID.RA-P3": [ + "RSK-10" + ], + "ID.RA-P4": [ + "RSK-10" + ], + "ID.RA-P5": [ + "RSK-10" + ], + "GV.AT-P": [ + "SAT-01" + ], + "GV.AT-P1": [ + "SAT-01", + "SAT-02", + "SAT-03" + ], + "GV.AT-P2": [ + "SAT-01", + "SAT-02", + "SAT-03" + ], + "GV.AT-P3": [ + "SAT-01", + "SAT-02", + "SAT-03" + ], + "GV.AT-P4": [ + "SAT-01", + "TPM-05", + "TPM-05.4", + "TPM-06" + ], + "CT.DP-P1": [ + "TDA-01.1", + "TDA-06" + ], + "PR.DS-P7": [ + "TDA-08" + ], + "GV.PO-P4": [ + "TPM-01", + "TPM-05", + "TPM-05.4", + "TPM-06" + ], + "PR.PO-P10": [ + "VPM-01" + ] + }, + "general-nist-800-37-r2": { + "TASK P-5": [ + "GOV-02", + "GOV-15.1" + ], + "TASK P-1": [ + "GOV-04", + "HRS-03", + "TPM-05.4" + ], + "TASK P-9": [ + "GOV-04.1", + "AST-01.2", + "IAO-03.1" + ], + "TASK P-17": [ + "GOV-15", + "GOV-15.2" + ], + "TASK S-1": [ + "GOV-15.1" + ], + "TASK S-3": [ + "GOV-15.2" + ], + "TASK I-1": [ + "GOV-15.2" + ], + "TASK A-3": [ + "GOV-15.3", + "IAO-02" + ], + "TASK M-2": [ + "GOV-15.3" + ], + "TASK R-4": [ + "GOV-15.4", + "IAO-07" + ], + "TASK M-1": [ + "GOV-15.5" + ], + "TASK P-18": [ + "AST-01", + "IAO-07" + ], + "TASK P-10": [ + "AST-02" + ], + "TASK P-11": [ + "AST-04", + "CPL-01.2", + "IAO-01.1" + ], + "TASK M-7": [ + "AST-09", + "PRM-07" + ], + "TASK P-6": [ + "BCD-02", + "CFG-02.5" + ], + "TASK P-8": [ + "BCD-02", + "PRM-01.1", + "PRM-05", + "PRM-06" + ], + "TASK P-7": [ + "CPL-02", + "MON-01" + ], + "TASK P-4": [ + "CFG-02.9" + ], + "TASK S-2": [ + "CFG-02.9", + "RSK-06.2" + ], + "TASK P-12": [ + "DCH-02" + ], + "TASK C-2": [ + "DCH-02" + ], + "TASK P-13": [ + "DCH-22", + "PRM-07" + ], + "TASK C-3": [ + "IAO-02" + ], + "TASK A-1": [ + "IAO-02", + "IAO-02.1", + "IAO-02.2" + ], + "TASK A-2": [ + "IAO-02" + ], + "TASK A-4": [ + "IAO-02.4" + ], + "TASK M-5": [ + "IAO-02.4" + ], + "TASK C-1": [ + "IAO-03" + ], + "TASK S-4": [ + "IAO-03" + ], + "TASK S-5": [ + "IAO-03" + ], + "TASK S-6": [ + "IAO-03" + ], + "TASK A-5": [ + "IAO-04", + "IAO-05" + ], + "TASK M-3": [ + "IAO-04" + ], + "TASK I-2": [ + "IAO-05" + ], + "TASK A-6": [ + "IAO-05" + ], + "TASK R-3": [ + "IAO-05", + "RSK-06.4" + ], + "TASK R-1": [ + "IAO-07" + ], + "TASK R-2": [ + "IAO-07" + ], + "TASK R-5": [ + "IAO-07" + ], + "TASK M-4": [ + "IAO-07" + ], + "TASK M-6": [ + "IAO-07" + ], + "TASK P-16": [ + "PRI-01.11" + ], + "TASK P-2": [ + "RSK-01" + ], + "TASK P-3": [ + "RSK-03", + "RSK-04" + ], + "TASK P-14": [ + "RSK-03", + "RSK-04" + ], + "TASK P-15": [ + "SEA-01" + ] + }, + "general-nist-800-39": { + "TASK 4-2": [ + "CPL-02", + "RSK-01" + ], + "3.4": [ + "IAO-05" + ], + "TASK 4-1": [ + "RSK-01" + ], + "3.1": [ + "RSK-01.1" + ], + "TASK 1-1": [ + "RSK-01.1" + ], + "TASK 1-2": [ + "RSK-01.1" + ], + "TASK 1-4": [ + "RSK-01.1", + "RSK-01.4", + "RSK-01.5" + ], + "TASK 1-3": [ + "RSK-01.3" + ], + "TASK 2-1": [ + "RSK-03.1", + "THR-09", + "THR-10", + "VPM-01" + ], + "3.2": [ + "RSK-04" + ], + "TASK 2-2": [ + "RSK-04" + ], + "3.3": [ + "RSK-06", + "RSK-06.1", + "RSK-06.2", + "RSK-06.3", + "RSK-06.4" + ], + "TASK 3-1": [ + "RSK-06.2", + "RSK-06.3" + ], + "TASK 3-2": [ + "RSK-06.3" + ], + "TASK 3-3": [ + "RSK-06.4" + ], + "TASK 3-4": [ + "RSK-06.4" + ] + }, + "general-nist-800-53-r4": { + "PM-1": [ + "GOV-01", + "GOV-02", + "GOV-03" + ], + "PL-9": [ + "GOV-04", + "SEA-01.1" + ], + "PM-2": [ + "GOV-04" + ], + "PM-6": [ + "GOV-04", + "GOV-05" + ], + "IR-6": [ + "GOV-06", + "IRO-10", + "IRO-14" + ], + "PM-15": [ + "GOV-07" + ], + "PM-5": [ + "AST-01", + "AST-02" + ], + "CM-8": [ + "AST-02" + ], + "CM-8(1)": [ + "AST-02.1" + ], + "CM-8(3)": [ + "AST-02.2" + ], + "CM-8(5)": [ + "AST-02.3" + ], + "CM-8(6)": [ + "AST-02.4" + ], + "IA-3(4)": [ + "AST-02.5", + "IAC-04", + "IAC-04.1" + ], + "SC-18(2)": [ + "AST-02.7", + "END-10" + ], + "CM-8(2)": [ + "AST-02.9" + ], + "CM-8(4)": [ + "AST-03.1" + ], + "PL-2": [ + "AST-04", + "IAO-03" + ], + "SA-5(1)": [ + "AST-04" + ], + "SA-5(2)": [ + "AST-04" + ], + "SA-5(3)": [ + "AST-04" + ], + "SA-5(4)": [ + "AST-04" + ], + "SA-19(3)": [ + "AST-09" + ], + "SC-43": [ + "AST-14" + ], + "SA-18": [ + "AST-15" + ], + "SA-18(2)": [ + "AST-15.1" + ], + "CP-1": [ + "BCD-01" + ], + "CP-2": [ + "BCD-01", + "BCD-06" + ], + "IR-4(3)": [ + "BCD-01", + "IRO-02.4" + ], + "PM-8": [ + "BCD-01", + "CPL-01" + ], + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" + ], + "CP-2(1)": [ + "BCD-01.1" + ], + "CP-2(7)": [ + "BCD-01.2" + ], + "CP-2(6)": [ + "BCD-01.3" + ], + "CP-6(2)": [ + "BCD-01.4" + ], + "CP-2(8)": [ + "BCD-02" + ], + "CP-2(4)": [ + "BCD-02.1" + ], + "CP-2(5)": [ + "BCD-02.2" + ], + "CP-2(3)": [ + "BCD-02.3" + ], + "CP-3": [ + "BCD-03" + ], + "CP-3(1)": [ + "BCD-03.1" + ], + "CP-3(2)": [ + "BCD-03.2" + ], + "CP-4": [ + "BCD-04", + "BCD-05" + ], + "CP-4(1)": [ + "BCD-04.1" + ], + "CP-4(2)": [ + "BCD-04.2" + ], + "CP-13": [ + "BCD-07" + ], + "CP-6": [ + "BCD-08" + ], + "CP-6(1)": [ + "BCD-08.1" + ], + "CP-6(3)": [ + "BCD-08.2" + ], + "CP-7": [ + "BCD-09" + ], + "CP-7(1)": [ + "BCD-09.1" + ], + "CP-7(2)": [ + "BCD-09.2" + ], + "CP-7(3)": [ + "BCD-09.3" + ], + "CP-7(4)": [ + "BCD-09.4" + ], + "CP-7(6)": [ + "BCD-09.5" + ], + "CP-8": [ + "BCD-10" + ], + "CP-8(2)": [ + "BCD-10" + ], + "CP-11": [ + "BCD-10" + ], + "CP-8(1)": [ + "BCD-10.1" + ], + "CP-8(3)": [ + "BCD-10.2" + ], + "CP-8(4)": [ + "BCD-10.3" + ], + "CP-9": [ + "BCD-11" + ], + "SC-28(2)": [ + "BCD-11", + "CRY-05.2" + ], + "CP-9(1)": [ + "BCD-11.1" + ], + "CP-9(3)": [ + "BCD-11.2" + ], + "CP-9(2)": [ + "BCD-11.5" + ], + "CP-9(5)": [ + "BCD-11.6" + ], + "CP-9(6)": [ + "BCD-11.7" + ], + "CP-9(7)": [ + "BCD-11.8" + ], + "CP-10(2)": [ + "BCD-12.1" + ], + "CP-10(5)": [ + "BCD-12.2" + ], + "CP-10(4)": [ + "BCD-12.4" + ], + "CP-10(6)": [ + "BCD-13" + ], + "SC-5": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "SC-5(3)": [ + "CAP-01" + ], + "SC-5(1)": [ + "CAP-02" + ], + "SC-5(2)": [ + "CAP-02", + "CAP-03" + ], + "SC-6": [ + "CAP-02" + ], + "CP-2(2)": [ + "CAP-03" + ], + "CM-3": [ + "CHG-01", + "CHG-02" + ], + "CM-3(1)": [ + "CHG-02.1" + ], + "CM-3(2)": [ + "CHG-02.2", + "CHG-06" + ], + "CM-5(2)": [ + "CHG-02.2" + ], + "CM-3(4)": [ + "CHG-02.3" + ], + "CM-3(5)": [ + "CHG-02.4" + ], + "CM-3(6)": [ + "CHG-02.5" + ], + "CM-4": [ + "CHG-03" + ], + "CM-5": [ + "CHG-04", + "END-03.2" + ], + "CM-5(1)": [ + "CHG-04.1" + ], + "CM-5(3)": [ + "CHG-04.2" + ], + "AC-5": [ + "CHG-04.3", + "HRS-11" + ], + "CM-5(4)": [ + "CHG-04.3" + ], + "CM-5(5)": [ + "CHG-04.4" + ], + "CM-5(6)": [ + "CHG-04.5" + ], + "CM-9": [ + "CHG-05", + "CFG-01" + ], + "SI-6": [ + "CHG-06" + ], + "SA-9(5)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" + ], + "PL-1": [ + "CPL-01", + "PRM-01", + "TDA-01" + ], + "CA-7": [ + "CPL-02" + ], + "CA-7(1)": [ + "CPL-02", + "CPL-03.1" + ], + "PM-14": [ + "CPL-02" + ], + "CA-2": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" + ], + "RA-3": [ + "CPL-03.2", + "RSK-04" + ], + "CM-1": [ + "CFG-01" + ], + "CM-9(1)": [ + "CFG-01.1" + ], + "CM-2": [ + "CFG-02" + ], + "CM-2(3)": [ + "CFG-02", + "CFG-02.1", + "CFG-02.3" + ], + "CM-6": [ + "CFG-02", + "CFG-02.7" + ], + "SA-8": [ + "CFG-02", + "SEA-01" + ], + "CM-2(1)": [ + "CFG-02.1" + ], + "CM-2(2)": [ + "CFG-02.2" + ], + "CM-6(1)": [ + "CFG-02.2" + ], + "CM-2(6)": [ + "CFG-02.4" + ], + "CM-2(7)": [ + "CFG-02.5" + ], + "CM-6(2)": [ + "CFG-02.8" + ], + "CM-7": [ + "CFG-03" + ], + "CM-7(1)": [ + "CFG-03.1" + ], + "CM-7(2)": [ + "CFG-03.2", + "SEA-06" + ], + "CM-7(4)": [ + "CFG-03.3" + ], + "CM-7(5)": [ + "CFG-03.3" + ], + "SC-18(4)": [ + "CFG-03.3", + "END-10" + ], + "SC-7(7)": [ + "CFG-03.4" + ], + "CM-10": [ + "CFG-04" + ], + "CM-10(1)": [ + "CFG-04.1" + ], + "CM-11": [ + "CFG-05", + "END-03" + ], + "CM-11(1)": [ + "CFG-05.1", + "END-03.1" + ], + "CM-11(2)": [ + "CFG-05.2", + "END-03" + ], + "DM-2(1)": [ + "CFG-08.1", + "MON-03" + ], + "AU-1": [ + "MON-01" + ], + "SI-4": [ + "MON-01", + "MON-02" + ], + "SI-4(1)": [ + "MON-01.1" + ], + "SI-4(2)": [ + "MON-01.2" + ], + "SI-4(4)": [ + "MON-01.3" + ], + "SI-4(5)": [ + "MON-01.4" + ], + "SI-4(14)": [ + "MON-01.5", + "NET-08.2" + ], + "SI-4(15)": [ + "MON-01.5", + "NET-08.2" + ], + "SI-4(23)": [ + "MON-01.6" + ], + "AU-2(3)": [ + "MON-01.8", + "MON-02" + ], + "SI-4(7)": [ + "MON-01.11", + "IRO-02.1" + ], + "SI-4(12)": [ + "MON-01.12", + "MON-05.1" + ], + "SI-4(13)": [ + "MON-01.13" + ], + "SI-4(19)": [ + "MON-01.14" + ], + "SI-4(20)": [ + "MON-01.15" + ], + "AU-2": [ + "MON-02" + ], + "AU-6": [ + "MON-02" + ], + "IR-4(4)": [ + "MON-02", + "MON-02.1" + ], + "AU-6(3)": [ + "MON-02.1" + ], + "SI-4(16)": [ + "MON-02.1" + ], + "AU-6(4)": [ + "MON-02.2" + ], + "AU-6(5)": [ + "MON-02.3" + ], + "AU-6(6)": [ + "MON-02.4" + ], + "AU-6(7)": [ + "MON-02.5" + ], + "AU-6(10)": [ + "MON-02.6" + ], + "AU-12(1)": [ + "MON-02.7" + ], + "AU-12(3)": [ + "MON-02.8" + ], + "AU-3": [ + "MON-03" + ], + "AU-3(1)": [ + "MON-03.1" + ], + "AU-6(1)": [ + "MON-03.1" + ], + "AU-6(8)": [ + "MON-03.3" + ], + "AU-3(2)": [ + "MON-03.6" + ], + "AU-4": [ + "MON-04" + ], + "AU-5": [ + "MON-05" + ], + "AU-5(2)": [ + "MON-05.1" + ], + "AU-5(1)": [ + "MON-05.2" + ], + "AU-7": [ + "MON-06" + ], + "AU-7(1)": [ + "MON-06" + ], + "AU-12": [ + "MON-06" + ], + "CA-7(3)": [ + "MON-06.2" + ], + "AU-8": [ + "MON-07", + "SEA-20" + ], + "AU-8(1)": [ + "MON-07.1" + ], + "AU-9": [ + "MON-08" + ], + "AU-4(1)": [ + "MON-08.1" + ], + "AU-9(2)": [ + "MON-08.1" + ], + "AU-9(4)": [ + "MON-08.2" + ], + "AU-9(3)": [ + "MON-08.3" + ], + "AU-9(5)": [ + "MON-08.4" + ], + "AU-10": [ + "MON-09" + ], + "AU-11": [ + "MON-10" + ], + "AU-13": [ + "MON-11" + ], + "SI-4(18)": [ + "MON-11.1" + ], + "SI-4(22)": [ + "MON-11.2" + ], + "SI-4(24)": [ + "MON-11.3" + ], + "AU-14": [ + "MON-12" + ], + "AU-15": [ + "MON-13" + ], + "AU-16": [ + "MON-14" + ], + "AU-16(1)": [ + "MON-14" + ], + "AU-16(2)": [ + "MON-14.1" + ], + "SC-31": [ + "MON-15" + ], + "AC-2(12)": [ + "MON-16" + ], + "SI-4(11)": [ + "MON-16" + ], + "SC-8(1)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" + ], + "SC-8(2)": [ + "CRY-01", + "CRY-01.3", + "DCH-10" + ], + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" + ], + "SC-13(1)": [ + "CRY-01" + ], + "SI-7(6)": [ + "CRY-01" + ], + "SC-8(4)": [ + "CRY-01.4" + ], + "IA-7": [ + "CRY-02", + "IAC-12" + ], + "SC-8": [ + "CRY-03", + "CRY-04" + ], + "SC-16(1)": [ + "CRY-04", + "CRY-10" + ], + "SC-28(1)": [ + "CRY-04", + "CRY-05" + ], + "SC-28": [ + "CRY-05", + "END-02" + ], + "AC-18": [ + "CRY-07", + "NET-15" + ], + "SC-40": [ + "CRY-07", + "NET-12.1" + ], + "SC-12": [ + "CRY-08" + ], + "SC-12(4)": [ + "CRY-08" + ], + "SC-12(5)": [ + "CRY-08" + ], + "SC-17": [ + "CRY-08" + ], + "SC-12(2)": [ + "CRY-09.1" + ], + "SC-12(3)": [ + "CRY-09.2" + ], + "SC-12(1)": [ + "CRY-09.3" + ], + "SC-16": [ + "CRY-10" + ], + "SC-23(5)": [ + "CRY-11" + ], + "MP-1": [ + "DCH-01" + ], + "MP-2": [ + "DCH-03", + "END-01" + ], + "AC-3(9)": [ + "DCH-03.3" + ], + "MP-3": [ + "DCH-04" + ], + "AC-16": [ + "DCH-05" + ], + "MP-4": [ + "DCH-06" + ], + "MP-5": [ + "DCH-07" + ], + "MP-5(3)": [ + "DCH-07.1" + ], + "MP-5(4)": [ + "DCH-07.2" + ], + "MP-6": [ + "DCH-08", + "DCH-09" + ], + "MP-6(3)": [ + "DCH-09", + "DCH-09.4" + ], + "MP-6(1)": [ + "DCH-09.1" + ], + "MP-6(2)": [ + "DCH-09.2" + ], + "MP-6(7)": [ + "DCH-09.5" + ], + "MP-7": [ + "DCH-10", + "DCH-18" + ], + "MP-7(1)": [ + "DCH-10.2" + ], + "MP-8": [ + "DCH-11" + ], + "AC-20": [ + "DCH-13" + ], + "AC-20(1)": [ + "DCH-13.1" + ], + "AC-20(2)": [ + "DCH-13.2" + ], + "AC-20(5)": [ + "DCH-13.2" + ], + "AC-20(3)": [ + "DCH-13.4" + ], + "AC-21": [ + "DCH-14" + ], + "AC-21(2)": [ + "DCH-14.1" + ], + "AC-22": [ + "DCH-15" + ], + "AC-23": [ + "DCH-16" + ], + "SI-12": [ + "DCH-18" + ], + "DM-2": [ + "DCH-21", + "PRI-05" + ], + "DI-1": [ + "DCH-22" + ], + "IP-3": [ + "DCH-22.1", + "PRI-06.1" + ], + "DM-1(1)": [ + "DCH-23" + ], + "DM-3(1)": [ + "DCH-23", + "IAC-09.6", + "PRI-05.1", + "PRI-05.4" + ], + "SI-3": [ + "END-04" + ], + "SI-3(2)": [ + "END-04.1", + "VPM-01", + "VPM-05" + ], + "SI-3(1)": [ + "END-04.3" + ], + "SI-3(7)": [ + "END-04.4" + ], + "SI-3(6)": [ + "END-04.5" + ], + "SI-7": [ + "END-06" + ], + "SI-7(1)": [ + "END-06.1" + ], + "SI-7(7)": [ + "END-06.2" + ], + "SI-7(2)": [ + "END-06.3" + ], + "SI-7(5)": [ + "END-06.4" + ], + "SI-7(9)": [ + "END-06.5" + ], + "SI-7(10)": [ + "END-06.6" + ], + "SI-7(14)": [ + "END-06.7" + ], + "SI-8": [ + "END-08" + ], + "SI-8(1)": [ + "END-08.1" + ], + "SI-8(2)": [ + "END-08.2" + ], + "SC-11": [ + "END-09" + ], + "SC-18": [ + "END-10" + ], + "SC-18(1)": [ + "END-10", + "VPM-02", + "VPM-04" + ], + "SC-18(3)": [ + "END-10", + "NET-18" + ], + "SC-27": [ + "END-10" + ], + "SC-25": [ + "END-11" + ], + "SC-41": [ + "END-12" + ], + "SC-42": [ + "END-13" + ], + "SC-42(2)": [ + "END-13.1" + ], + "SC-15": [ + "END-14" + ], + "SC-15(1)": [ + "END-14" + ], + "SC-15(3)": [ + "END-14.1" + ], + "SC-15(4)": [ + "END-14.2" + ], + "SC-3": [ + "END-16", + "SEA-04.1" + ], + "SC-7(12)": [ + "END-16.1" + ], + "PS-1": [ + "HRS-01" + ], + "PS-2": [ + "HRS-02", + "HRS-03.2" + ], + "PM-13": [ + "HRS-03", + "SAT-01" + ], + "PS-3": [ + "HRS-04" + ], + "PS-3(1)": [ + "HRS-04.1" + ], + "PS-3(3)": [ + "HRS-04.1" + ], + "PS-3(2)": [ + "HRS-04.2" + ], + "PL-4": [ + "HRS-05", + "HRS-05.1" + ], + "PL-4(1)": [ + "HRS-05.2" + ], + "SC-19": [ + "HRS-05.3", + "NET-13" + ], + "PS-6": [ + "HRS-06", + "HRS-06.1" + ], + "PS-6(2)": [ + "HRS-06", + "HRS-06.1" + ], + "PS-6(3)": [ + "HRS-06.2" + ], + "PS-8": [ + "HRS-07" + ], + "PS-5": [ + "HRS-08" + ], + "PS-4": [ + "HRS-09" + ], + "PS-4(1)": [ + "HRS-09.3" + ], + "PS-4(2)": [ + "HRS-09.4" + ], + "PS-7": [ + "HRS-10" + ], + "AC-3(2)": [ + "HRS-12.1", + "IAC-20.5" + ], + "AC-1": [ + "IAC-01" + ], + "IA-1": [ + "IAC-01" + ], + "IA-2": [ + "IAC-02" + ], + "IA-2(5)": [ + "IAC-02.1" + ], + "IA-2(8)": [ + "IAC-02.2" + ], + "IA-2(9)": [ + "IAC-02.2" + ], + "IA-2(12)": [ + "IAC-02.3" + ], + "IA-8(5)": [ + "IAC-02.3" + ], + "IA-2(13)": [ + "IAC-02.4" + ], + "IA-8": [ + "IAC-03" + ], + "IA-8(1)": [ + "IAC-03.1" + ], + "IA-8(2)": [ + "IAC-03.2" + ], + "IA-8(4)": [ + "IAC-03.3" + ], + "IA-8(3)": [ + "IAC-03.5" + ], + "IA-3": [ + "IAC-04" + ], + "IA-3(1)": [ + "IAC-04" + ], + "IA-9": [ + "IAC-05" + ], + "IA-9(1)": [ + "IAC-05.1" + ], + "IA-2(11)": [ + "IAC-06", + "IAC-06.4" + ], + "IA-2(1)": [ + "IAC-06.1" + ], + "IA-2(4)": [ + "IAC-06.1", + "IAC-06.2" + ], + "IA-2(2)": [ + "IAC-06.2" + ], + "IA-2(3)": [ + "IAC-06.3" + ], + "IA-2(6)": [ + "IAC-06.4" + ], + "IA-5(3)": [ + "IAC-07", + "IAC-10.3", + "IAC-28.4" + ], + "AC-2(10)": [ + "IAC-07.2" + ], + "AC-2(7)": [ + "IAC-08" + ], + "IA-4": [ + "IAC-09" + ], + "IA-4(4)": [ + "IAC-09.1", + "IAC-09.2" + ], + "IA-4(5)": [ + "IAC-09.3" + ], + "IA-5(2)": [ + "IAC-09.3", + "IAC-10.2" + ], + "IA-5(10)": [ + "IAC-09.3" + ], + "IA-4(6)": [ + "IAC-09.4" + ], + "IA-5(8)": [ + "IAC-09.5", + "IAC-10.9" + ], + "IA-5": [ + "IAC-10", + "IAC-10.8" + ], + "IA-5(4)": [ + "IAC-10", + "IAC-10.4" + ], + "IA-5(1)": [ + "IAC-10.1" + ], + "IA-5(6)": [ + "IAC-10.5", + "IAC-18" + ], + "IA-5(7)": [ + "IAC-10.6" + ], + "IA-5(11)": [ + "IAC-10.7", + "TDA-02.2" + ], + "IA-5(5)": [ + "IAC-10.8" + ], + "IA-5(13)": [ + "IAC-10.10" + ], + "IA-5(12)": [ + "IAC-10.12" + ], + "IA-6": [ + "IAC-11" + ], + "IA-10": [ + "IAC-13" + ], + "IA-11": [ + "IAC-14" + ], + "AC-2": [ + "IAC-15" + ], + "AC-2(1)": [ + "IAC-15.1" + ], + "AC-2(2)": [ + "IAC-15.2" + ], + "AC-2(3)": [ + "IAC-15.3" + ], + "AC-2(4)": [ + "IAC-15.4" + ], + "AC-2(9)": [ + "IAC-15.5" + ], + "AC-2(13)": [ + "IAC-15.6" + ], + "AC-2(11)": [ + "IAC-15.8" + ], + "AC-6(7)": [ + "IAC-17" + ], + "AC-3": [ + "IAC-20" + ], + "AC-6": [ + "IAC-20", + "IAC-21" + ], + "AC-6(1)": [ + "IAC-21.1" + ], + "AC-6(2)": [ + "IAC-21.2" + ], + "AC-6(5)": [ + "IAC-21.3" + ], + "AC-6(9)": [ + "IAC-21.4" + ], + "AC-6(10)": [ + "IAC-21.5" + ], + "AC-6(3)": [ + "IAC-21.6" + ], + "AC-6(8)": [ + "IAC-21.7" + ], + "AC-7": [ + "IAC-22" + ], + "AC-10": [ + "IAC-23" + ], + "AC-2(5)": [ + "IAC-24" + ], + "AC-11": [ + "IAC-24" + ], + "AC-11(1)": [ + "IAC-24.1" + ], + "AC-12": [ + "IAC-25" + ], + "AC-12(1)": [ + "IAC-25.1" + ], + "AC-14": [ + "IAC-26" + ], + "AC-25": [ + "IAC-27" + ], + "AC-24": [ + "IAC-28.1" + ], + "IA-4(2)": [ + "IAC-28.1" + ], + "IR-1": [ + "IRO-01", + "IRO-04.2", + "IRO-13" + ], + "IR-4": [ + "IRO-02" + ], + "IR-4(1)": [ + "IRO-02.1" + ], + "IR-4(6)": [ + "IRO-02.2" + ], + "IR-4(2)": [ + "IRO-02.3" + ], + "IR-4(8)": [ + "IRO-02.5" + ], + "IR-8": [ + "IRO-04" + ], + "SE-2": [ + "IRO-04.1" + ], + "IR-2": [ + "IRO-05" + ], + "IR-2(1)": [ + "IRO-05.1" + ], + "IR-2(2)": [ + "IRO-05.2" + ], + "IR-3": [ + "IRO-06" + ], + "SI-4(9)": [ + "IRO-06" + ], + "IR-3(2)": [ + "IRO-06.1" + ], + "IR-10": [ + "IRO-07" + ], + "AU-10(3)": [ + "IRO-08" + ], + "IR-5": [ + "IRO-09" + ], + "IR-5(1)": [ + "IRO-09.1" + ], + "IR-6(1)": [ + "IRO-10.1" + ], + "IR-6(2)": [ + "IRO-10.3" + ], + "IR-6(3)": [ + "IRO-10.4" + ], + "IR-7": [ + "IRO-11" + ], + "IR-7(1)": [ + "IRO-11.1" + ], + "IR-7(2)": [ + "IRO-11.2" + ], + "IR-9": [ + "IRO-12" + ], + "IR-9(1)": [ + "IRO-12.1" + ], + "IR-9(2)": [ + "IRO-12.2" + ], + "IR-9(3)": [ + "IRO-12.3" + ], + "IR-9(4)": [ + "IRO-12.4" + ], + "SC-44": [ + "IRO-15" + ], + "CA-1": [ + "IAO-01" + ], + "PM-10": [ + "IAO-01" + ], + "CA-2(1)": [ + "IAO-02.1" + ], + "CA-2(2)": [ + "IAO-02.2" + ], + "CA-2(3)": [ + "IAO-02.3" + ], + "PL-2(3)": [ + "IAO-03.1" + ], + "CA-5": [ + "IAO-05" + ], + "PM-4": [ + "IAO-05", + "VPM-02" + ], + "CA-5(1)": [ + "IAO-05.1" + ], + "CM-4(2)": [ + "IAO-06" + ], + "CA-6": [ + "IAO-07" + ], + "MA-1": [ + "MNT-01" + ], + "MA-2": [ + "MNT-02" + ], + "MA-2(2)": [ + "MNT-02.1" + ], + "MA-6": [ + "MNT-03" + ], + "MA-6(1)": [ + "MNT-03.1" + ], + "MA-6(2)": [ + "MNT-03.2" + ], + "MA-6(3)": [ + "MNT-03.3" + ], + "MA-3": [ + "MNT-04" + ], + "MA-3(1)": [ + "MNT-04.1" + ], + "MA-3(2)": [ + "MNT-04.2" + ], + "MA-3(3)": [ + "MNT-04.3" + ], + "MA-3(4)": [ + "MNT-04.4" + ], + "MA-4": [ + "MNT-05" + ], + "MA-4(1)": [ + "MNT-05.1" + ], + "MA-4(2)": [ + "MNT-05.2" + ], + "MA-4(6)": [ + "MNT-05.3" + ], + "MA-4(7)": [ + "MNT-05.4" + ], + "MA-4(5)": [ + "MNT-05.5" + ], + "MA-4(3)": [ + "MNT-05.6" + ], + "MA-4(4)": [ + "MNT-05.7" + ], + "MA-5": [ + "MNT-06" + ], + "MA-5(1)": [ + "MNT-06.1" + ], + "MA-5(2)": [ + "MNT-06.1" + ], + "MA-5(3)": [ + "MNT-06.1" + ], + "MA-5(4)": [ + "MNT-06.1" + ], + "MA-5(5)": [ + "MNT-06.2" + ], + "AC-19": [ + "MDM-02" + ], + "AC-19(5)": [ + "MDM-03" + ], + "PE-3(5)": [ + "MDM-04" + ], + "AC-7(2)": [ + "MDM-05" + ], + "MP-6(8)": [ + "MDM-05" + ], + "SC-1": [ + "NET-01", + "SEA-01" + ], + "SC-7": [ + "NET-03" + ], + "SC-7(9)": [ + "NET-03", + "NET-03.2" + ], + "SC-7(11)": [ + "NET-03", + "NET-04.1" + ], + "SC-7(3)": [ + "NET-03.1" + ], + "SC-7(4)": [ + "NET-03.2" + ], + "SC-7(16)": [ + "NET-03.3" + ], + "SC-7(10)": [ + "NET-03.5", + "NET-17" + ], + "SC-7(20)": [ + "NET-03.6" + ], + "SC-7(21)": [ + "NET-03.7" + ], + "SC-7(22)": [ + "NET-03.8" + ], + "AC-4": [ + "NET-04" + ], + "CA-3(5)": [ + "NET-04.1" + ], + "SC-7(5)": [ + "NET-04.1" + ], + "AC-4(1)": [ + "NET-04.2" + ], + "AC-4(4)": [ + "NET-04.3" + ], + "AC-4(5)": [ + "NET-04.4" + ], + "AC-4(6)": [ + "NET-04.5" + ], + "AC-4(9)": [ + "NET-04.6" + ], + "AC-4(8)": [ + "NET-04.7" + ], + "AC-4(12)": [ + "NET-04.8" + ], + "AC-4(13)": [ + "NET-04.9" + ], + "AC-4(15)": [ + "NET-04.10" + ], + "AC-4(20)": [ + "NET-04.11" + ], + "CA-3": [ + "NET-05" + ], + "CA-3(1)": [ + "NET-05" + ], + "CA-3(2)": [ + "NET-05" + ], + "CA-3(3)": [ + "NET-05.1" + ], + "CA-9": [ + "NET-05.2" + ], + "AC-4(21)": [ + "NET-06" + ], + "SC-7(13)": [ + "NET-06.1" + ], + "SC-10": [ + "NET-07" + ], + "SC-23": [ + "NET-09" + ], + "SC-23(1)": [ + "NET-09.1" + ], + "SC-23(3)": [ + "NET-09.2" + ], + "SC-20": [ + "NET-10" + ], + "SC-20(2)": [ + "NET-10" + ], + "SC-22": [ + "NET-10.1" + ], + "SC-21": [ + "NET-10.2" + ], + "SC-37": [ + "NET-11" + ], + "SC-37(1)": [ + "NET-11" + ], + "SC-8(3)": [ + "NET-13" + ], + "AC-17": [ + "NET-14" + ], + "AC-17(6)": [ + "NET-14" + ], + "AC-17(1)": [ + "NET-14.1" + ], + "AC-17(2)": [ + "NET-14.2" + ], + "AC-17(3)": [ + "NET-14.3" + ], + "AC-17(4)": [ + "NET-14.4" + ], + "AC-17(9)": [ + "NET-14.8" + ], + "AC-18(1)": [ + "NET-15.1" + ], + "AC-18(3)": [ + "NET-15.2" + ], + "AC-18(4)": [ + "NET-15.3" + ], + "AC-18(5)": [ + "NET-15.4" + ], + "SC-7(8)": [ + "NET-18", + "NET-18.1" + ], + "PE-1": [ + "PES-01" + ], + "PE-2": [ + "PES-02" + ], + "PE-2(1)": [ + "PES-02.1" + ], + "PE-3": [ + "PES-03" + ], + "PE-3(2)": [ + "PES-03" + ], + "PE-3(3)": [ + "PES-03" + ], + "PE-3(4)": [ + "PES-03.2" + ], + "SC-7(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" + ], + "PE-8": [ + "PES-03.3" + ], + "PE-3(1)": [ + "PES-03.4" + ], + "PE-6": [ + "PES-05" + ], + "PE-6(1)": [ + "PES-05.1" + ], + "PE-6(4)": [ + "PES-05.2" + ], + "PE-2(2)": [ + "PES-06.2" + ], + "PE-2(3)": [ + "PES-06.3" + ], + "PE-8(1)": [ + "PES-06.4" + ], + "PE-9": [ + "PES-07" + ], + "PE-9(2)": [ + "PES-07.1" + ], + "PE-10": [ + "PES-07.2" + ], + "PE-11": [ + "PES-07.3" + ], + "PE-11(1)": [ + "PES-07.3" + ], + "PE-11(2)": [ + "PES-07.3" + ], + "PE-12": [ + "PES-07.4" + ], + "PE-15": [ + "PES-07.5" + ], + "PE-15(1)": [ + "PES-07.6" + ], + "PE-9(1)": [ + "PES-07.7" + ], + "PE-13": [ + "PES-08" + ], + "PE-13(1)": [ + "PES-08.1" + ], + "PE-13(2)": [ + "PES-08.2" + ], + "PE-13(3)": [ + "PES-08.3" + ], + "PE-14": [ + "PES-09" + ], + "PE-14(2)": [ + "PES-09.1" + ], + "PE-16": [ + "PES-10" + ], + "PE-17": [ + "PES-11" + ], + "PE-18": [ + "PES-12" + ], + "PE-18(1)": [ + "PES-12" + ], + "PE-4": [ + "PES-12.1" + ], + "PE-5": [ + "PES-12.2" + ], + "PE-19": [ + "PES-13" + ], + "PE-20": [ + "PES-14" + ], + "AR-1": [ + "PRI-01.1" + ], + "TR-2": [ + "PRI-01.2", + "PRI-02" + ], + "TR-3": [ + "PRI-01.3" + ], + "TR-1": [ + "PRI-02" + ], + "AP-2": [ + "PRI-02.1" + ], + "DI-2(1)": [ + "PRI-02.3" + ], + "TR-2(1)": [ + "PRI-02.4" + ], + "TR-1(1)": [ + "PRI-02.7" + ], + "IP-1": [ + "PRI-03" + ], + "IP-(1)": [ + "PRI-03.1" + ], + "AP-1": [ + "PRI-04", + "PRI-04.1" + ], + "DI-1(1)": [ + "PRI-04.5" + ], + "DI-1(2)": [ + "PRI-04.6" + ], + "DM-1": [ + "PRI-05.1" + ], + "DM-3": [ + "PRI-05.1" + ], + "DI-2": [ + "PRI-05.2" + ], + "UL-1": [ + "PRI-05.4" + ], + "SE-1": [ + "PRI-05.5" + ], + "IP-2": [ + "PRI-06" + ], + "IP-4": [ + "PRI-06.4", + "OPS-03" + ], + "IP-4(1)": [ + "PRI-06.4", + "OPS-03" + ], + "UL-2": [ + "PRI-07" + ], + "AR-3": [ + "PRI-07.1" + ], + "AR-4": [ + "PRI-08" + ], + "AR-6": [ + "PRI-14" + ], + "AR-8": [ + "PRI-14.1" + ], + "PM-3": [ + "PRM-02" + ], + "SA-2": [ + "PRM-03" + ], + "SA-14": [ + "PRM-05", + "TPM-02" + ], + "PM-11": [ + "PRM-06" + ], + "SA-3": [ + "PRM-07", + "SEA-07.1" + ], + "PM-9": [ + "RSK-01" + ], + "RA-1": [ + "RSK-01" + ], + "RA-2": [ + "RSK-02" + ], + "SA-12": [ + "RSK-09", + "TPM-03" + ], + "AR-2": [ + "RSK-10" + ], + "AR-7": [ + "SEA-01" + ], + "SA-13": [ + "SEA-01" + ], + "SC-7(18)": [ + "SEA-01" + ], + "SI-1": [ + "SEA-01" + ], + "PL-8": [ + "SEA-02" + ], + "PM-7": [ + "SEA-02" + ], + "PL-8(1)": [ + "SEA-03" + ], + "SC-3(5)": [ + "SEA-03" + ], + "SC-32": [ + "SEA-03.1" + ], + "SC-2": [ + "SEA-03.2" + ], + "SC-2(1)": [ + "SEA-03.2" + ], + "SC-39": [ + "SEA-04" + ], + "SC-39(1)": [ + "SEA-04.2" + ], + "SC-39(2)": [ + "SEA-04.3" + ], + "SC-4": [ + "SEA-05" + ], + "SI-13": [ + "SEA-07" + ], + "CP-12": [ + "SEA-07.2" + ], + "SC-24": [ + "SEA-07.2" + ], + "SI-17": [ + "SEA-07.3" + ], + "SI-14": [ + "SEA-08" + ], + "SI-14(1)": [ + "SEA-08.1" + ], + "SI-15": [ + "SEA-09" + ], + "SI-16": [ + "SEA-10" + ], + "SC-26": [ + "SEA-11" + ], + "SC-35": [ + "SEA-12" + ], + "SC-29": [ + "SEA-13" + ], + "SC-29(1)": [ + "SEA-13.1" + ], + "SC-30": [ + "SEA-14" + ], + "SC-30(2)": [ + "SEA-14.1" + ], + "SC-30(3)": [ + "SEA-14.2" + ], + "SC-36": [ + "SEA-15" + ], + "SC-34": [ + "SEA-16" + ], + "AC-8": [ + "SEA-18" + ], + "AC-9": [ + "SEA-19" + ], + "SC-38": [ + "OPS-01", + "OPS-04" + ], + "PL-7": [ + "OPS-02" + ], + "AT-1": [ + "SAT-01" + ], + "AT-2": [ + "SAT-02" + ], + "AT-2(1)": [ + "SAT-02.1" + ], + "AT-3": [ + "SAT-03" + ], + "AT-3(3)": [ + "SAT-03.1" + ], + "AT-3(4)": [ + "SAT-03.2" + ], + "AR-5": [ + "SAT-03.3" + ], + "AT-4": [ + "SAT-04" + ], + "SA-1": [ + "TDA-01", + "TDA-06" + ], + "SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" + ], + "SA-4(9)": [ + "TDA-02.1" + ], + "SA-4(10)": [ + "TDA-02.2" + ], + "SA-4(3)": [ + "TDA-02.3" + ], + "SA-4(6)": [ + "TDA-03" + ], + "PL-8(2)": [ + "TDA-03.1" + ], + "SA-5": [ + "TDA-04" + ], + "SA-4(1)": [ + "TDA-04.1" + ], + "SA-4(2)": [ + "TDA-04.1" + ], + "SA-17": [ + "TDA-05" + ], + "SA-15": [ + "TDA-06" + ], + "CM-4(1)": [ + "TDA-08" + ], + "SA-11": [ + "TDA-09" + ], + "SA-4(8)": [ + "TDA-09.1" + ], + "SA-11(1)": [ + "TDA-09.2" + ], + "SA-11(8)": [ + "TDA-09.3" + ], + "SA-11(4)": [ + "TDA-09.7" + ], + "SA-15(9)": [ + "TDA-10" + ], + "SA-12(10)": [ + "TDA-11" + ], + "SA-19": [ + "TDA-11" + ], + "SA-19(1)": [ + "TDA-11.1" + ], + "SA-20": [ + "TDA-12" + ], + "SA-21": [ + "TDA-13" + ], + "SA-10": [ + "TDA-14" + ], + "SA-10(1)": [ + "TDA-14.1" + ], + "SA-10(3)": [ + "TDA-14.2" + ], + "SA-11(2)": [ + "TDA-15" + ], + "SA-16": [ + "TDA-16" + ], + "SA-22": [ + "TDA-17" + ], + "SA-22(1)": [ + "TDA-17.1" + ], + "SI-10": [ + "TDA-18" + ], + "SI-11": [ + "TDA-19" + ], + "SA-12(1)": [ + "TPM-03.1" + ], + "SA-12(5)": [ + "TPM-03.2" + ], + "SA-12(15)": [ + "TPM-03.3" + ], + "SA-9": [ + "TPM-04" + ], + "SA-9(1)": [ + "TPM-04.1" + ], + "SA-9(2)": [ + "TPM-04.2" + ], + "SA-9(4)": [ + "TPM-04.3" + ], + "SA-9(3)": [ + "TPM-05" + ], + "SA-12(2)": [ + "TPM-08" + ], + "PM-16": [ + "THR-01" + ], + "SI-5": [ + "THR-03" + ], + "SI-5(1)": [ + "THR-03" + ], + "PM-12": [ + "THR-04" + ], + "AT-2(2)": [ + "THR-05" + ], + "SI-2": [ + "VPM-01", + "VPM-05" + ], + "SI-2(1)": [ + "VPM-05.1" + ], + "SI-2(2)": [ + "VPM-05.2" + ], + "SI-2(3)": [ + "VPM-05.3" + ], + "SI-2(5)": [ + "VPM-05.4" + ], + "SI-2(6)": [ + "VPM-05.5" + ], + "RA-5": [ + "VPM-06" + ], + "RA-5(1)": [ + "VPM-06.1" + ], + "RA-5(2)": [ + "VPM-06.1" + ], + "RA-5(3)": [ + "VPM-06.2" + ], + "RA-5(5)": [ + "VPM-06.3" + ], + "RA-5(6)": [ + "VPM-06.4" + ], + "RA-5(8)": [ + "VPM-06.5" + ], + "RA-5(4)": [ + "VPM-06.8" + ], + "RA-5(10)": [ + "VPM-06.9" + ], + "CA-8": [ + "VPM-07" + ], + "CA-8(1)": [ + "VPM-07.1" + ], + "RA-6": [ + "VPM-08" + ], + "CA-8(2)": [ + "VPM-10" + ], + "SC-7(17)": [ + "WEB-03" + ] + }, + "general-nist-800-53-r5-2": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" + ], + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" + ], + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" + ], + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" + ], + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" + ], + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" + ], + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" + ], + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" + ], + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" + ], + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" + ], + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" + ], + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" + ], + "PT-01": [ + "GOV-02", + "GOV-03", + "PRI-01", + "SEA-01" + ], + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" + ], + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" + ], + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" + ], + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" + ], + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" + ], + "PL-09": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" + ], + "PM-02": [ + "GOV-04" + ], + "PM-06": [ + "GOV-04", + "GOV-05" + ], + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" + ], + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" + ], + "PM-15": [ + "GOV-07", + "THR-01" + ], + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" + ], + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" + ], + "PM-32": [ + "GOV-11" + ], + "PM-05": [ + "AST-01", + "AST-02" + ], + "CM-08": [ + "AST-02", + "AST-02.3" + ], + "CM-08(01)": [ + "AST-02.1" + ], + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" + ], + "CM-08(06)": [ + "AST-02.4" + ], + "IA-03(03)": [ + "AST-02.5" + ], + "SC-07(19)": [ + "AST-02.5" + ], + "SC-18(02)": [ + "AST-02.7", + "END-10" + ], + "CM-13": [ + "AST-02.8" + ], + "CM-08(02)": [ + "AST-02.9" + ], + "CM-08(07)": [ + "AST-02.9" + ], + "CM-08(08)": [ + "AST-02.10" + ], + "CM-08(09)": [ + "AST-02.11" + ], + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" + ], + "CM-08(04)": [ + "AST-03.1" + ], + "SR-04": [ + "AST-03.2" + ], + "SR-04(01)": [ + "AST-03.2" + ], + "SR-04(02)": [ + "AST-03.2" + ], + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" + ], + "SA-04(01)": [ + "AST-04", + "TDA-04.1" + ], + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" + ], + "PE-22": [ + "AST-04.1", + "PES-16" + ], + "SA-05": [ + "AST-04.1", + "TDA-04" + ], + "SR-12": [ + "AST-09" + ], + "SC-43": [ + "AST-14" + ], + "SR-09": [ + "AST-15" + ], + "SR-09(01)": [ + "AST-15" + ], + "SR-10": [ + "AST-15.1", + "TDA-11" + ], + "CP-02": [ + "BCD-01", + "BCD-06" + ], + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" + ], + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" + ], + "PM-08": [ + "BCD-01", + "CPL-01" + ], + "CP-02(01)": [ + "BCD-01.1" + ], + "CP-02(07)": [ + "BCD-01.2" + ], + "CP-02(06)": [ + "BCD-01.3" + ], + "CP-06(02)": [ + "BCD-01.4" + ], + "CP-02(08)": [ + "BCD-02" + ], + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" + ], + "CP-02(05)": [ + "BCD-02.2" + ], + "CP-03": [ + "BCD-03" + ], + "CP-03(01)": [ + "BCD-03.1" + ], + "CP-03(02)": [ + "BCD-03.2" + ], + "CP-04": [ + "BCD-04", + "BCD-05" + ], + "CP-04(01)": [ + "BCD-04.1" + ], + "CP-04(02)": [ + "BCD-04.2" + ], + "CP-13": [ + "BCD-07" + ], + "CP-06": [ + "BCD-08" + ], + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" + ], + "CP-06(01)": [ + "BCD-08.1" + ], + "CP-06(03)": [ + "BCD-08.2" + ], + "CP-07": [ + "BCD-09" + ], + "CP-07(01)": [ + "BCD-09.1" + ], + "CP-07(02)": [ + "BCD-09.2" + ], + "CP-07(03)": [ + "BCD-09.3" + ], + "CP-07(04)": [ + "BCD-09.4" + ], + "CP-07(06)": [ + "BCD-09.5" + ], + "CP-08": [ + "BCD-10" + ], + "CP-08(02)": [ + "BCD-10" + ], + "CP-11": [ + "BCD-10" + ], + "CP-08(01)": [ + "BCD-10.1" + ], + "CP-08(03)": [ + "BCD-10.2" + ], + "CP-08(04)": [ + "BCD-10.3" + ], + "SC-47": [ + "BCD-10.4" + ], + "CP-09": [ + "BCD-11" + ], + "SC-28(02)": [ + "BCD-11", + "CRY-05.2" + ], + "CP-09(01)": [ + "BCD-11.1" + ], + "CP-09(03)": [ + "BCD-11.2" + ], + "CP-09(08)": [ + "BCD-11.4" + ], + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" + ], + "CP-09(02)": [ + "BCD-11.5" + ], + "CP-09(05)": [ + "BCD-11.6" + ], + "CP-09(06)": [ + "BCD-11.7" + ], + "CP-09(07)": [ + "BCD-11.8" + ], + "CP-10(02)": [ + "BCD-12.1" + ], + "SI-13": [ + "BCD-12.2", + "SEA-07" + ], + "CP-10(04)": [ + "BCD-12.4" + ], + "CP-10(06)": [ + "BCD-13" + ], + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "SC-05(03)": [ + "CAP-01" + ], + "SC-05(01)": [ + "CAP-02" + ], + "SC-05(02)": [ + "CAP-02", + "CAP-03" + ], + "SC-06": [ + "CAP-02" + ], + "CP-02(02)": [ + "CAP-03" + ], + "CM-03": [ + "CHG-01", + "CHG-02" + ], + "SA-08(31)": [ + "CHG-02", + "CHG-02.2", + "CHG-06" + ], + "CM-03(01)": [ + "CHG-02.1" + ], + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" + ], + "CM-03(07)": [ + "CHG-02.2" + ], + "CM-03(04)": [ + "CHG-02.3" + ], + "CM-03(05)": [ + "CHG-02.4" + ], + "CM-03(06)": [ + "CHG-02.5" + ], + "CM-04": [ + "CHG-03" + ], + "CM-05": [ + "CHG-04", + "END-03.2" + ], + "CM-05(01)": [ + "CHG-04.1" + ], + "CM-14": [ + "CHG-04.2" + ], + "SI-07(15)": [ + "CHG-04.2" + ], + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" + ], + "CM-05(04)": [ + "CHG-04.3" + ], + "CM-05(05)": [ + "CHG-04.4" + ], + "CM-05(06)": [ + "CHG-04.5" + ], + "CM-09": [ + "CHG-05", + "CFG-01" + ], + "SI-06": [ + "CHG-06" + ], + "SI-06(03)": [ + "CHG-06.1" + ], + "SC-07(29)": [ + "CLD-03", + "NET-03.8", + "NET-06.1" + ], + "SA-09(05)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" + ], + "SA-09(08)": [ + "CLD-09", + "DCH-19" + ], + "CA-07": [ + "CPL-02" + ], + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" + ], + "PM-14": [ + "CPL-02", + "PRI-08" + ], + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" + ], + "RA-03": [ + "CPL-03.2", + "RSK-04" + ], + "CM-09(01)": [ + "CFG-01.1" + ], + "CM-02": [ + "CFG-02", + "CFG-02.1" + ], + "CM-06": [ + "CFG-02", + "CFG-02.7" + ], + "PL-10": [ + "CFG-02" + ], + "SA-08": [ + "CFG-02", + "SEA-01" + ], + "SA-15(05)": [ + "CFG-02", + "SEA-01" + ], + "CM-02(02)": [ + "CFG-02.2" + ], + "CM-06(01)": [ + "CFG-02.2" + ], + "CM-02(03)": [ + "CFG-02.3" + ], + "CM-02(06)": [ + "CFG-02.4" + ], + "CM-02(07)": [ + "CFG-02.5" + ], + "CM-07(06)": [ + "CFG-02.5" + ], + "CM-07(07)": [ + "CFG-02.5" + ], + "CM-07(09)": [ + "CFG-02.5" + ], + "CM-06(02)": [ + "CFG-02.8" + ], + "PL-11": [ + "CFG-02.9" + ], + "CM-07": [ + "CFG-03" + ], + "CM-07(01)": [ + "CFG-03.1" + ], + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" + ], + "CM-07(04)": [ + "CFG-03.3" + ], + "CM-07(05)": [ + "CFG-03.3" + ], + "SC-18(04)": [ + "CFG-03.3", + "END-10" + ], + "SC-07(07)": [ + "CFG-03.4" + ], + "CM-10": [ + "CFG-04" + ], + "CM-10(01)": [ + "CFG-04.1" + ], + "CM-11": [ + "CFG-05", + "END-03" + ], + "CM-11(02)": [ + "CFG-05", + "CFG-05.2", + "END-03" + ], + "CM-11(03)": [ + "CFG-05.1", + "CFG-06", + "CFG-06.1", + "END-03.1" + ], + "CM-03(08)": [ + "CFG-06", + "CFG-06.1" + ], + "AC-03(11)": [ + "CFG-08" + ], + "PM-31": [ + "MON-01" + ], + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" + ], + "SI-04(01)": [ + "MON-01.1" + ], + "SI-04(25)": [ + "MON-01.1", + "NET-03.1" + ], + "SC-48": [ + "MON-01.2", + "THR-07" + ], + "SI-04(02)": [ + "MON-01.2" + ], + "SI-04(04)": [ + "MON-01.3" + ], + "SI-04(05)": [ + "MON-01.4" + ], + "SI-04(14)": [ + "MON-01.5" + ], + "SI-04(23)": [ + "MON-01.6" + ], + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" + ], + "AU-02": [ + "MON-01.8", + "MON-02" + ], + "IR-04(05)": [ + "MON-01.11", + "IRO-02.6" + ], + "SI-04(07)": [ + "MON-01.11", + "IRO-02.1" + ], + "SI-04(12)": [ + "MON-01.12", + "MON-05.1" + ], + "SI-04(13)": [ + "MON-01.13" + ], + "SI-04(19)": [ + "MON-01.14" + ], + "SI-04(20)": [ + "MON-01.15" + ], + "AU-14(03)": [ + "MON-01.17" + ], + "AU-06": [ + "MON-02", + "MON-02.6" + ], + "IR-04(04)": [ + "MON-02", + "MON-02.1" + ], + "AU-06(03)": [ + "MON-02.1" + ], + "AU-06(09)": [ + "MON-02.1" + ], + "SI-04(16)": [ + "MON-02.1" + ], + "AU-06(04)": [ + "MON-02.2" + ], + "AU-06(05)": [ + "MON-02.3" + ], + "SI-04(17)": [ + "MON-02.3" + ], + "AU-06(06)": [ + "MON-02.4" + ], + "AU-06(07)": [ + "MON-02.5" + ], + "AU-12(01)": [ + "MON-02.7" + ], + "AU-12(03)": [ + "MON-02.8" + ], + "AU-03": [ + "MON-03" + ], + "AU-03(01)": [ + "MON-03.1" + ], + "AU-06(01)": [ + "MON-03.1" + ], + "AU-06(08)": [ + "MON-03.3" + ], + "AU-03(03)": [ + "MON-03.5" + ], + "AU-04": [ + "MON-04" + ], + "AU-05": [ + "MON-05" + ], + "AU-05(02)": [ + "MON-05.1" + ], + "AU-05(01)": [ + "MON-05.2" + ], + "AU-07": [ + "MON-06" + ], + "AU-07(01)": [ + "MON-06" + ], + "AU-12": [ + "MON-06" + ], + "AU-12(04)": [ + "MON-06.1" + ], + "CA-07(03)": [ + "MON-06.2" + ], + "AU-08": [ + "MON-07", + "SEA-20" + ], + "SC-45": [ + "MON-07.1" + ], + "SC-45(01)": [ + "MON-07.1" + ], + "AU-09": [ + "MON-08" + ], + "AU-04(01)": [ + "MON-08.1" + ], + "AU-09(02)": [ + "MON-08.1" + ], + "AU-09(04)": [ + "MON-08.2" + ], + "AU-09(03)": [ + "MON-08.3" + ], + "AU-09(05)": [ + "MON-08.4" + ], + "AU-10": [ + "MON-09" + ], + "AU-10(01)": [ + "MON-09.1" + ], + "AU-10(02)": [ + "MON-09.1" + ], + "AU-11": [ + "MON-10" + ], + "AU-13": [ + "MON-11" + ], + "SI-04(18)": [ + "MON-11.1", + "NET-17" + ], + "SI-04(22)": [ + "MON-11.2" + ], + "AU-14": [ + "MON-12" + ], + "AU-05(05)": [ + "MON-13" + ], + "AU-16": [ + "MON-14" + ], + "AU-16(01)": [ + "MON-14" + ], + "AU-16(02)": [ + "MON-14.1" + ], + "SC-31": [ + "MON-15" + ], + "AC-02(12)": [ + "MON-16" + ], + "IR-04(13)": [ + "MON-16", + "SEA-11", + "SEA-12" + ], + "SI-04(11)": [ + "MON-16" + ], + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" + ], + "SC-08(02)": [ + "CRY-01", + "CRY-01.3", + "DCH-10" + ], + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" + ], + "SI-07(06)": [ + "CRY-01" + ], + "SC-08(04)": [ + "CRY-01.4" + ], + "IA-07": [ + "CRY-02", + "IAC-12" + ], + "SC-08": [ + "CRY-03", + "CRY-04" + ], + "SC-16(01)": [ + "CRY-04", + "CRY-10" + ], + "SC-28": [ + "CRY-05", + "END-02" + ], + "AC-18": [ + "CRY-07", + "NET-15" + ], + "SC-40": [ + "CRY-07", + "NET-12.1" + ], + "SC-12": [ + "CRY-08" + ], + "SC-17": [ + "CRY-08" + ], + "SC-28(03)": [ + "CRY-09" + ], + "SC-12(02)": [ + "CRY-09.1" + ], + "SC-12(03)": [ + "CRY-09.2" + ], + "SC-12(01)": [ + "CRY-09.3" + ], + "SA-09(06)": [ + "CRY-09.7" + ], + "SC-16": [ + "CRY-10" + ], + "SC-23(05)": [ + "CRY-11" + ], + "MP-02": [ + "DCH-03", + "END-01" + ], + "AC-03(09)": [ + "DCH-03.3" + ], + "MP-03": [ + "DCH-04", + "DCH-04.1" + ], + "AC-16": [ + "DCH-05" + ], + "AC-16(01)": [ + "DCH-05.1" + ], + "AC-16(02)": [ + "DCH-05.2" + ], + "AC-16(03)": [ + "DCH-05.3" + ], + "AC-16(04)": [ + "DCH-05.4" + ], + "AC-16(05)": [ + "DCH-05.5" + ], + "AC-16(06)": [ + "DCH-05.6" + ], + "AC-16(07)": [ + "DCH-05.7" + ], + "AC-16(08)": [ + "DCH-05.8" + ], + "AC-16(09)": [ + "DCH-05.9" + ], + "AC-16(10)": [ + "DCH-05.10" + ], + "MP-04": [ + "DCH-06" + ], + "MP-05": [ + "DCH-07" + ], + "MP-05(03)": [ + "DCH-07.1" + ], + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" + ], + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" + ], + "MP-06(01)": [ + "DCH-09.1" + ], + "MP-06(02)": [ + "DCH-09.2" + ], + "MP-06(07)": [ + "DCH-09.5" + ], + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" + ], + "MP-08": [ + "DCH-11" + ], + "MP-08(03)": [ + "DCH-11" + ], + "AC-20": [ + "DCH-13" + ], + "AC-20(01)": [ + "DCH-13.1" + ], + "AC-20(02)": [ + "DCH-13.2" + ], + "AC-20(05)": [ + "DCH-13.2" + ], + "PM-17": [ + "DCH-13.3" + ], + "AC-20(03)": [ + "DCH-13.4" + ], + "AC-21": [ + "DCH-14", + "PRI-07" + ], + "AC-21(02)": [ + "DCH-14.1" + ], + "CA-03(06)": [ + "DCH-14.2" + ], + "AC-22": [ + "DCH-15" + ], + "AC-23": [ + "DCH-16", + "PRI-05.4" + ], + "SI-12": [ + "DCH-18", + "PRI-05" + ], + "SI-12(01)": [ + "DCH-18.1", + "PRI-05.1" + ], + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" + ], + "SA-08(33)": [ + "DCH-18.2", + "END-13.3", + "PES-06.5" + ], + "SA-15(12)": [ + "DCH-18.2" + ], + "SI-12(02)": [ + "DCH-18.2", + "PRI-05.1" + ], + "SI-12(03)": [ + "DCH-21", + "PRI-05" + ], + "PM-22": [ + "DCH-22", + "PRI-10" + ], + "SI-18": [ + "DCH-22" + ], + "SI-18(01)": [ + "DCH-22" + ], + "SI-18(04)": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" + ], + "SI-18(05)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-06.2" + ], + "PT-02(01)": [ + "DCH-22.2" + ], + "PT-03(01)": [ + "DCH-22.2", + "PRI-11" + ], + "SI-18(02)": [ + "DCH-22.2" + ], + "SI-18(03)": [ + "DCH-22.3" + ], + "SI-19(01)": [ + "DCH-22.3", + "DCH-23.1" + ], + "SI-19": [ + "DCH-23" + ], + "SI-19(02)": [ + "DCH-23.2" + ], + "SI-19(03)": [ + "DCH-23.3" + ], + "SI-19(04)": [ + "DCH-23.4", + "PRI-05.3" + ], + "SI-19(05)": [ + "DCH-23.5" + ], + "SI-19(06)": [ + "DCH-23.6" + ], + "SI-19(07)": [ + "DCH-23.7" + ], + "SI-19(08)": [ + "DCH-23.8" + ], + "CM-12": [ + "DCH-24" + ], + "CM-12(01)": [ + "DCH-24.1" + ], + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" + ], + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" + ], + "SI-03(06)": [ + "END-04.5" + ], + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" + ], + "SI-07(01)": [ + "END-06.1" + ], + "SI-07(07)": [ + "END-06.2" + ], + "SI-07(02)": [ + "END-06.3" + ], + "SI-07(05)": [ + "END-06.4" + ], + "SI-07(09)": [ + "END-06.5" + ], + "SI-07(10)": [ + "END-06.6" + ], + "CM-07(08)": [ + "END-06.7" + ], + "SI-08": [ + "END-08" + ], + "SI-08(02)": [ + "END-08.2" + ], + "SC-11": [ + "END-09" + ], + "SC-18": [ + "END-10" + ], + "SC-18(01)": [ + "END-10", + "VPM-02", + "VPM-04" + ], + "SC-18(03)": [ + "END-10", + "NET-18" + ], + "SC-27": [ + "END-10" + ], + "SC-25": [ + "END-11" + ], + "SC-41": [ + "END-12" + ], + "SC-42": [ + "END-13" + ], + "SC-42(02)": [ + "END-13.1" + ], + "SC-42(04)": [ + "END-13.2" + ], + "SC-42(05)": [ + "END-13.3" + ], + "SC-42(01)": [ + "END-13.4" + ], + "SC-15": [ + "END-14" + ], + "SC-15(01)": [ + "END-14" + ], + "SC-15(03)": [ + "END-14.1" + ], + "SC-15(04)": [ + "END-14.2" + ], + "SC-03": [ + "END-16", + "SEA-04.1" + ], + "SC-07(12)": [ + "END-16.1" + ], + "PS-02": [ + "HRS-02", + "HRS-03.2" + ], + "SI-04(21)": [ + "HRS-02.2" + ], + "PM-13": [ + "HRS-03", + "SAT-01" + ], + "PS-09": [ + "HRS-03" + ], + "PS-03": [ + "HRS-04" + ], + "PS-03(01)": [ + "HRS-04.1" + ], + "PS-03(03)": [ + "HRS-04.1" + ], + "PS-03(02)": [ + "HRS-04.2" + ], + "PS-03(04)": [ + "HRS-04.3" + ], + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" + ], + "PL-04(01)": [ + "HRS-05.2" + ], + "PS-06": [ + "HRS-06", + "HRS-06.1" + ], + "PS-06(02)": [ + "HRS-06", + "HRS-06.1" + ], + "PS-06(03)": [ + "HRS-06.2" + ], + "PS-08": [ + "HRS-07" + ], + "PS-05": [ + "HRS-08" + ], + "PS-04": [ + "HRS-09" + ], + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" + ], + "PS-04(01)": [ + "HRS-09.3" + ], + "PS-04(02)": [ + "HRS-09.4" + ], + "PS-07": [ + "HRS-10" + ], + "AC-03(02)": [ + "HRS-12.1", + "IAC-20.5" + ], + "IA-04": [ + "IAC-01.2", + "IAC-09" + ], + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" + ], + "IA-02": [ + "IAC-02" + ], + "IA-02(05)": [ + "IAC-02.1" + ], + "IA-02(08)": [ + "IAC-02.2" + ], + "IA-02(12)": [ + "IAC-02.3" + ], + "IA-08(05)": [ + "IAC-02.3" + ], + "IA-02(13)": [ + "IAC-02.4" + ], + "IA-08": [ + "IAC-03" + ], + "IA-08(01)": [ + "IAC-03.1" + ], + "IA-08(02)": [ + "IAC-03.2" + ], + "IA-08(04)": [ + "IAC-03.3" + ], + "IA-08(06)": [ + "IAC-03.4" + ], + "IA-03": [ + "IAC-04" + ], + "IA-03(01)": [ + "IAC-04" + ], + "IA-03(04)": [ + "IAC-04", + "IAC-04.1" + ], + "IA-09": [ + "IAC-05" + ], + "AC-06(06)": [ + "IAC-05.2" + ], + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "IA-02(06)": [ + "IAC-06.4" + ], + "IA-12(04)": [ + "IAC-07", + "IAC-10.3", + "IAC-28.4" + ], + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" + ], + "AC-02(07)": [ + "IAC-08" + ], + "IA-04(05)": [ + "IAC-09.3" + ], + "IA-05(10)": [ + "IAC-09.3" + ], + "IA-04(06)": [ + "IAC-09.4" + ], + "IA-05(08)": [ + "IAC-09.5", + "IAC-10.9" + ], + "IA-04(08)": [ + "IAC-09.6" + ], + "IA-05": [ + "IAC-10", + "IAC-10.8" + ], + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" + ], + "IA-05(02)": [ + "IAC-10.2" + ], + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" + ], + "IA-05(07)": [ + "IAC-10.6" + ], + "IA-05(05)": [ + "IAC-10.8" + ], + "IA-05(13)": [ + "IAC-10.10" + ], + "IA-05(18)": [ + "IAC-10.11" + ], + "IA-05(12)": [ + "IAC-10.12" + ], + "IA-06": [ + "IAC-11" + ], + "IA-10": [ + "IAC-13" + ], + "IA-02(10)": [ + "IAC-13.1" + ], + "IA-05(09)": [ + "IAC-13.2" + ], + "IA-11": [ + "IAC-14" + ], + "AC-02(01)": [ + "IAC-15.1" + ], + "AC-02(02)": [ + "IAC-15.2" + ], + "AC-02(03)": [ + "IAC-15.3" + ], + "AC-02(04)": [ + "IAC-15.4" + ], + "AC-02(09)": [ + "IAC-15.5" + ], + "AC-02(11)": [ + "IAC-15.8" + ], + "AC-06(07)": [ + "IAC-17" + ], + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" + ], + "AC-06": [ + "IAC-20", + "IAC-21" + ], + "AC-03(08)": [ + "IAC-20.6" + ], + "SA-08(14)": [ + "IAC-21" + ], + "AC-06(01)": [ + "IAC-21.1" + ], + "AC-06(02)": [ + "IAC-21.2" + ], + "AC-06(05)": [ + "IAC-21.3" + ], + "AC-06(09)": [ + "IAC-21.4" + ], + "AC-06(10)": [ + "IAC-21.5" + ], + "AC-06(03)": [ + "IAC-21.6" + ], + "AC-06(08)": [ + "IAC-21.7" + ], + "AC-07": [ + "IAC-22" + ], + "AC-10": [ + "IAC-23" + ], + "AC-02(05)": [ + "IAC-24" + ], + "AC-11": [ + "IAC-24" + ], + "AC-11(01)": [ + "IAC-24.1" + ], + "AC-12": [ + "IAC-25" + ], + "AC-12(01)": [ + "IAC-25.1" + ], + "AC-14": [ + "IAC-26" + ], + "AC-25": [ + "IAC-27" + ], + "IA-12": [ + "IAC-28" + ], + "AC-24": [ + "IAC-28.1" + ], + "IA-12(01)": [ + "IAC-28.1" + ], + "IA-12(02)": [ + "IAC-28.2" + ], + "IA-12(03)": [ + "IAC-28.3" + ], + "IA-12(05)": [ + "IAC-28.5" + ], + "IR-04": [ + "IRO-02" + ], + "IR-04(01)": [ + "IRO-02.1" + ], + "IR-04(06)": [ + "IRO-02.2" + ], + "IR-04(07)": [ + "IRO-02.2" + ], + "IR-04(02)": [ + "IRO-02.3" + ], + "IR-04(08)": [ + "IRO-02.5" + ], + "IR-08": [ + "IRO-04" + ], + "IR-08(01)": [ + "IRO-04.1" + ], + "IR-03(03)": [ + "IRO-04.3" + ], + "IR-02": [ + "IRO-05" + ], + "IR-02(03)": [ + "IRO-05" + ], + "IR-02(01)": [ + "IRO-05.1" + ], + "IR-02(02)": [ + "IRO-05.2" + ], + "IR-03": [ + "IRO-06" + ], + "SI-04(09)": [ + "IRO-06" + ], + "IR-03(02)": [ + "IRO-06.1" + ], + "IR-04(11)": [ + "IRO-07" + ], + "AU-10(03)": [ + "IRO-08" + ], + "IR-04(12)": [ + "IRO-08", + "IRO-13" + ], + "IR-05": [ + "IRO-09" + ], + "IR-05(01)": [ + "IRO-09.1" + ], + "IR-06(01)": [ + "IRO-10.1" + ], + "IR-06(02)": [ + "IRO-10.3", + "IRO-13" + ], + "IR-04(10)": [ + "IRO-10.4", + "TPM-11" + ], + "IR-06(03)": [ + "IRO-10.4" + ], + "IR-07": [ + "IRO-11" + ], + "IR-07(01)": [ + "IRO-11.1" + ], + "IR-07(02)": [ + "IRO-11.2" + ], + "IR-09": [ + "IRO-12", + "IRO-12.1" + ], + "IR-09(02)": [ + "IRO-12.2" + ], + "IR-09(03)": [ + "IRO-12.3" + ], + "IR-09(04)": [ + "IRO-12.4" + ], + "SC-44": [ + "IRO-15" + ], + "IR-04(15)": [ + "IRO-16" + ], + "PM-10": [ + "IAO-01" + ], + "CA-02(01)": [ + "IAO-02.1" + ], + "CA-02(02)": [ + "IAO-02.2" + ], + "SA-11(05)": [ + "IAO-02.2", + "IAO-04", + "TDA-09", + "TDA-09.5", + "VPM-07" + ], + "CA-02(03)": [ + "IAO-02.3" + ], + "CA-05": [ + "IAO-05" + ], + "PM-04": [ + "IAO-05", + "VPM-02" + ], + "SA-15(02)": [ + "IAO-05" + ], + "CA-05(01)": [ + "IAO-05.1" + ], + "CM-04(02)": [ + "IAO-06" + ], + "CA-06": [ + "IAO-07" + ], + "MA-02": [ + "MNT-02" + ], + "MA-02(02)": [ + "MNT-02.1" + ], + "MA-06": [ + "MNT-03" + ], + "MA-06(01)": [ + "MNT-03.1" + ], + "MA-06(02)": [ + "MNT-03.2" + ], + "MA-06(03)": [ + "MNT-03.3" + ], + "MA-03": [ + "MNT-04" + ], + "MA-03(05)": [ + "MNT-04" + ], + "MA-03(06)": [ + "MNT-04" + ], + "MA-03(01)": [ + "MNT-04.1" + ], + "MA-03(02)": [ + "MNT-04.2" + ], + "MA-03(03)": [ + "MNT-04.3" + ], + "MA-03(04)": [ + "MNT-04.4" + ], + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" + ], + "MA-04(01)": [ + "MNT-05.1" + ], + "MA-04(06)": [ + "MNT-05.3" + ], + "MA-04(07)": [ + "MNT-05.4" + ], + "MA-04(05)": [ + "MNT-05.5" + ], + "MA-04(03)": [ + "MNT-05.6" + ], + "MA-04(04)": [ + "MNT-05.7" + ], + "MA-05": [ + "MNT-06" + ], + "MA-05(01)": [ + "MNT-06.1" + ], + "MA-05(02)": [ + "MNT-06.1" + ], + "MA-05(03)": [ + "MNT-06.1" + ], + "MA-05(04)": [ + "MNT-06.1" + ], + "MA-05(05)": [ + "MNT-06.2" + ], + "SR-11(02)": [ + "MNT-07" + ], + "MA-07": [ + "MNT-08" + ], + "AC-19": [ + "MDM-02" + ], + "AC-19(05)": [ + "MDM-03" + ], + "PE-03(05)": [ + "MDM-04" + ], + "AC-07(02)": [ + "MDM-05" + ], + "MP-06(08)": [ + "MDM-05" + ], + "SC-46": [ + "NET-02.3" + ], + "SC-07": [ + "NET-03" + ], + "SC-07(09)": [ + "NET-03", + "NET-03.2" + ], + "SC-07(11)": [ + "NET-03", + "NET-04.1" + ], + "SC-07(03)": [ + "NET-03.1" + ], + "SC-07(04)": [ + "NET-03.2" + ], + "SC-07(16)": [ + "NET-03.3" + ], + "SC-07(24)": [ + "NET-03.4" + ], + "SC-07(10)": [ + "NET-03.5", + "NET-17" + ], + "SC-07(20)": [ + "NET-03.6" + ], + "SC-07(21)": [ + "NET-03.7" + ], + "SC-07(22)": [ + "NET-03.8" + ], + "AC-04": [ + "NET-04" + ], + "SC-07(05)": [ + "NET-04.1" + ], + "AC-04(01)": [ + "NET-04.2" + ], + "AC-04(04)": [ + "NET-04.3" + ], + "AC-04(05)": [ + "NET-04.4" + ], + "AC-04(06)": [ + "NET-04.5" + ], + "AC-04(09)": [ + "NET-04.6" + ], + "AC-04(08)": [ + "NET-04.7" + ], + "AC-04(12)": [ + "NET-04.8" + ], + "AC-04(13)": [ + "NET-04.9" + ], + "AC-04(15)": [ + "NET-04.10" + ], + "AC-04(20)": [ + "NET-04.11" + ], + "AC-04(17)": [ + "NET-04.12" + ], + "AC-04(19)": [ + "NET-04.13" + ], + "CA-03": [ + "NET-05" + ], + "SC-07(25)": [ + "NET-05" + ], + "SC-07(26)": [ + "NET-05" + ], + "SC-07(27)": [ + "NET-05.1" + ], + "CA-09": [ + "NET-05.2" + ], + "AC-04(21)": [ + "NET-06" + ], + "SC-07(13)": [ + "NET-06.1" + ], + "SC-07(28)": [ + "NET-06.5" + ], + "SC-10": [ + "NET-07" + ], + "SI-04(15)": [ + "NET-08.2" + ], + "SC-23": [ + "NET-09" + ], + "SC-23(01)": [ + "NET-09.1" + ], + "SC-23(03)": [ + "NET-09.2" + ], + "SC-20": [ + "NET-10" + ], + "SC-20(02)": [ + "NET-10" + ], + "SC-22": [ + "NET-10.1" + ], + "SC-21": [ + "NET-10.2" + ], + "SC-37": [ + "NET-11" + ], + "SC-37(01)": [ + "NET-11" + ], + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" + ], + "SI-10": [ + "NET-12", + "TDA-18" + ], + "SC-08(03)": [ + "NET-13" + ], + "AC-17": [ + "NET-14" + ], + "AC-17(06)": [ + "NET-14" + ], + "AC-17(01)": [ + "NET-14.1" + ], + "AC-17(02)": [ + "NET-14.2" + ], + "AC-17(03)": [ + "NET-14.3" + ], + "AC-17(04)": [ + "NET-14.4" + ], + "CA-09(01)": [ + "NET-14.7" + ], + "AC-17(09)": [ + "NET-14.8" + ], + "AC-18(01)": [ + "NET-15.1" + ], + "AC-18(03)": [ + "NET-15.2" + ], + "AC-18(04)": [ + "NET-15.3" + ], + "AC-18(05)": [ + "NET-15.4" + ], + "SC-07(08)": [ + "NET-18", + "NET-18.1" + ], + "SI-04(10)": [ + "NET-18.2" + ], + "SC-07(15)": [ + "NET-18.3" + ], + "PE-02": [ + "PES-02" + ], + "PE-02(01)": [ + "PES-02.1" + ], + "PE-03": [ + "PES-03" + ], + "PE-03(02)": [ + "PES-03" + ], + "PE-03(03)": [ + "PES-03" + ], + "PE-03(04)": [ + "PES-03.2" + ], + "SC-07(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" + ], + "PE-08": [ + "PES-03.3" + ], + "PE-03(01)": [ + "PES-03.4" + ], + "PE-06": [ + "PES-05" + ], + "PE-06(01)": [ + "PES-05.1" + ], + "PE-06(04)": [ + "PES-05.2" + ], + "PE-02(02)": [ + "PES-06.2" + ], + "PE-02(03)": [ + "PES-06.3" + ], + "PE-08(01)": [ + "PES-06.4" + ], + "PE-08(03)": [ + "PES-06.5" + ], + "PE-09": [ + "PES-07" + ], + "PE-09(02)": [ + "PES-07.1" + ], + "PE-10": [ + "PES-07.2" + ], + "PE-11": [ + "PES-07.3" + ], + "PE-11(01)": [ + "PES-07.3" + ], + "PE-11(02)": [ + "PES-07.3" + ], + "PE-12": [ + "PES-07.4" + ], + "PE-15": [ + "PES-07.5" + ], + "PE-15(01)": [ + "PES-07.6" + ], + "PE-09(01)": [ + "PES-07.7" + ], + "PE-13": [ + "PES-08" + ], + "PE-13(01)": [ + "PES-08.1" + ], + "PE-13(02)": [ + "PES-08.2", + "PES-08.3" + ], + "PE-14": [ + "PES-09" + ], + "PE-14(02)": [ + "PES-09.1" + ], + "PE-16": [ + "PES-10" + ], + "PE-17": [ + "PES-11" + ], + "PE-18": [ + "PES-12" + ], + "PE-04": [ + "PES-12.1" + ], + "PE-05": [ + "PES-12.2" + ], + "PE-19": [ + "PES-13" + ], + "PE-20": [ + "PES-14" + ], + "PE-21": [ + "PES-15" + ], + "PM-18": [ + "PRI-01" + ], + "PM-19": [ + "PRI-01.1" + ], + "PT-05(02)": [ + "PRI-01.2" + ], + "PM-20": [ + "PRI-01.3" + ], + "PM-20(01)": [ + "PRI-02" + ], + "PT-05": [ + "PRI-02" + ], + "PT-03": [ + "PRI-02.1", + "PRI-05.1" + ], + "PT-02(02)": [ + "PRI-02.2" + ], + "PT-03(02)": [ + "PRI-02.2", + "PRI-10.1" + ], + "PT-08": [ + "PRI-02.3" + ], + "PT-06": [ + "PRI-02.4" + ], + "PT-06(01)": [ + "PRI-02.5" + ], + "PT-06(02)": [ + "PRI-02.6" + ], + "PT-04": [ + "PRI-03" + ], + "PT-04(01)": [ + "PRI-03.1" + ], + "PT-04(02)": [ + "PRI-03.2" + ], + "PT-05(01)": [ + "PRI-03.2" + ], + "PT-04(03)": [ + "PRI-03.4" + ], + "PT-02": [ + "PRI-04", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" + ], + "AC-04(25)": [ + "PRI-05" + ], + "PT-07": [ + "PRI-05.4", + "PRI-05.7" + ], + "PM-05(01)": [ + "PRI-05.5", + "PRI-05.6" + ], + "PT-07(01)": [ + "PRI-05.7" + ], + "PT-07(02)": [ + "PRI-05.7" + ], + "AC-03(14)": [ + "PRI-06" + ], + "PM-26": [ + "PRI-06.3", + "PRI-06.4" + ], + "PM-27": [ + "PRI-14" + ], + "PM-21": [ + "PRI-14.1" + ], + "PM-03": [ + "PRM-02" + ], + "SA-02": [ + "PRM-03" + ], + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" + ], + "PM-11": [ + "PRM-06" + ], + "SA-03": [ + "PRM-07", + "SEA-07.1" + ], + "SA-03(01)": [ + "PRM-07", + "SEA-07.1", + "TDA-07" + ], + "SA-08(30)": [ + "PRM-07", + "SEA-07.1" + ], + "PM-09": [ + "RSK-01" + ], + "PM-28": [ + "RSK-01.1" + ], + "RA-02": [ + "RSK-02" + ], + "RA-02(01)": [ + "RSK-02.1" + ], + "RA-07": [ + "RSK-06.1" + ], + "PM-30": [ + "RSK-09" + ], + "SA-09(03)": [ + "RSK-09", + "TPM-02", + "TPM-03", + "TPM-04.3", + "TPM-05.4", + "TPM-05.7" + ], + "SR-02": [ + "RSK-09", + "TPM-03" + ], + "SR-07": [ + "RSK-09", + "OPS-01" + ], + "RA-03(01)": [ + "RSK-09.1" + ], + "RA-08": [ + "RSK-10" + ], + "CA-07(04)": [ + "RSK-11" + ], + "SC-07(18)": [ + "SEA-01" + ], + "PL-08": [ + "SEA-02" + ], + "PM-07": [ + "SEA-02" + ], + "PM-07(01)": [ + "SEA-02.2" + ], + "PL-08(01)": [ + "SEA-03" + ], + "SC-03(05)": [ + "SEA-03" + ], + "SC-32": [ + "SEA-03.1" + ], + "SC-02": [ + "SEA-03.2" + ], + "SC-02(01)": [ + "SEA-03.2" + ], + "SC-39": [ + "SEA-04" + ], + "SC-39(01)": [ + "SEA-04.2" + ], + "SC-39(02)": [ + "SEA-04.3" + ], + "SC-04": [ + "SEA-05" + ], + "SA-03(03)": [ + "SEA-07.1", + "SEA-08.1" + ], + "CP-12": [ + "SEA-07.2" + ], + "SA-08(24)": [ + "SEA-07.2" + ], + "SC-24": [ + "SEA-07.2" + ], + "SI-17": [ + "SEA-07.3" + ], + "SI-14": [ + "SEA-08" + ], + "SI-14(01)": [ + "SEA-08.1" + ], + "SI-15": [ + "SEA-09" + ], + "SI-16": [ + "SEA-10" + ], + "SC-26": [ + "SEA-11" + ], + "SC-35": [ + "SEA-12" + ], + "SC-29": [ + "SEA-13" + ], + "SC-29(01)": [ + "SEA-13.1" + ], + "SC-30": [ + "SEA-14" + ], + "SC-30(04)": [ + "SEA-14" + ], + "SC-30(05)": [ + "SEA-14" + ], + "SC-30(02)": [ + "SEA-14.1" + ], + "SC-30(03)": [ + "SEA-14.2" + ], + "SC-36": [ + "SEA-15" + ], + "SC-34": [ + "SEA-16" + ], + "AC-08": [ + "SEA-18" + ], + "AC-09": [ + "SEA-19" + ], + "SC-38": [ + "OPS-01", + "OPS-04" + ], + "SA-08(32)": [ + "OPS-01.1" + ], + "PL-07": [ + "OPS-02" + ], + "IR-04(14)": [ + "OPS-04" + ], + "AT-02": [ + "SAT-02" + ], + "AT-02(01)": [ + "SAT-02.1" + ], + "AT-06": [ + "SAT-02.1" + ], + "AT-02(03)": [ + "SAT-02.2" + ], + "AT-03": [ + "SAT-03" + ], + "AT-03(02)": [ + "SAT-03" + ], + "AT-03(03)": [ + "SAT-03.1" + ], + "AT-02(04)": [ + "SAT-03.2" + ], + "AT-02(05)": [ + "SAT-03.2" + ], + "AT-03(05)": [ + "SAT-03.3" + ], + "AT-02(06)": [ + "SAT-03.6" + ], + "AT-04": [ + "SAT-04" + ], + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" + ], + "SA-23": [ + "TDA-01", + "TDA-01.1", + "TDA-12" + ], + "SA-04(09)": [ + "TDA-02.1" + ], + "SA-04(07)": [ + "TDA-02.2" + ], + "SA-04(10)": [ + "TDA-02.2" + ], + "SA-04(03)": [ + "TDA-02.3", + "TDA-06" + ], + "SR-03(01)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" + ], + "SA-04(05)": [ + "TDA-02.4" + ], + "SA-10(07)": [ + "TDA-02.7" + ], + "SA-15(13)": [ + "TDA-02.14" + ], + "SA-04(06)": [ + "TDA-03" + ], + "PL-08(02)": [ + "TDA-03.1" + ], + "SA-17": [ + "TDA-05" + ], + "SA-15": [ + "TDA-06" + ], + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" + ], + "SA-15(03)": [ + "TDA-06.1" + ], + "SA-11(02)": [ + "TDA-06.2", + "TDA-15" + ], + "SA-15(08)": [ + "TDA-06.2" + ], + "SI-02(07)": [ + "TDA-06.6" + ], + "CM-04(01)": [ + "TDA-08" + ], + "SA-11": [ + "TDA-09" + ], + "SA-11(06)": [ + "TDA-09", + "VPM-01.1" + ], + "SA-11(07)": [ + "TDA-09", + "VPM-01.1" + ], + "SA-04(08)": [ + "TDA-09.1" + ], + "SA-11(01)": [ + "TDA-09.2" + ], + "SA-11(08)": [ + "TDA-09.3" + ], + "SA-11(04)": [ + "TDA-09.7" + ], + "SA-03(02)": [ + "TDA-10" + ], + "SR-04(03)": [ + "TDA-11" + ], + "SR-04(04)": [ + "TDA-11" + ], + "SR-11": [ + "TDA-11" + ], + "SR-11(03)": [ + "TDA-11" + ], + "SR-11(01)": [ + "TDA-11.1" + ], + "SA-20": [ + "TDA-12" + ], + "SA-21": [ + "TDA-13" + ], + "SA-10": [ + "TDA-14" + ], + "SA-10(01)": [ + "TDA-14.1" + ], + "SA-10(03)": [ + "TDA-14.2" + ], + "SA-16": [ + "TDA-16" + ], + "SA-22": [ + "TDA-17", + "TDA-17.1" + ], + "SI-11": [ + "TDA-19" + ], + "SR-02(01)": [ + "TPM-03" + ], + "SR-05": [ + "TPM-03.1" + ], + "SR-03(02)": [ + "TPM-03.2" + ], + "SR-03": [ + "TPM-03.3" + ], + "SR-05(01)": [ + "TPM-03.4" + ], + "SA-09": [ + "TPM-04" + ], + "SA-09(01)": [ + "TPM-04.1" + ], + "SA-09(02)": [ + "TPM-04.2" + ], + "SA-09(04)": [ + "TPM-04.3" + ], + "SR-03(03)": [ + "TPM-05", + "TPM-05.2" + ], + "SR-08": [ + "TPM-05.1" + ], + "SR-06": [ + "TPM-08" + ], + "SR-06(01)": [ + "TPM-08" + ], + "PM-16": [ + "THR-01" + ], + "PM-16(01)": [ + "THR-03" + ], + "SI-05(01)": [ + "THR-03" + ], + "PM-12": [ + "THR-04" + ], + "AT-02(02)": [ + "THR-05" + ], + "RA-05(11)": [ + "THR-06" + ], + "RA-10": [ + "THR-07" + ], + "SI-20": [ + "THR-08" + ], + "SI-02(04)": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" + ], + "SI-02(02)": [ + "VPM-05.2" + ], + "SI-02(03)": [ + "VPM-05.3" + ], + "SI-02(05)": [ + "VPM-05.4" + ], + "SI-02(06)": [ + "VPM-05.5" + ], + "RA-05": [ + "VPM-06", + "VPM-06.1" + ], + "RA-05(02)": [ + "VPM-06.1" + ], + "RA-05(03)": [ + "VPM-06.2" + ], + "RA-05(05)": [ + "VPM-06.3" + ], + "RA-05(06)": [ + "VPM-06.4" + ], + "RA-05(08)": [ + "VPM-06.5" + ], + "RA-05(04)": [ + "VPM-06.8" + ], + "RA-05(10)": [ + "VPM-06.9" + ], + "CA-08": [ + "VPM-07" + ], + "CA-08(01)": [ + "VPM-07.1" + ], + "RA-06": [ + "VPM-08" + ], + "CA-08(02)": [ + "VPM-10" + ], + "SC-07(17)": [ + "WEB-03" + ] + }, + "general-nist-800-53-r5-2-privacy": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" + ], + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" + ], + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" + ], + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" + ], + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" + ], + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" + ], + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" + ], + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" + ], + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" + ], + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" + ], + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" + ], + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" + ], + "PT-01": [ + "GOV-02", + "GOV-03", + "PRI-01", + "SEA-01" + ], + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" + ], + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" + ], + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" + ], + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" + ], + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" + ], + "PL-09": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" + ], + "PM-06": [ + "GOV-04", + "GOV-05" + ], + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" + ], + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" + ], + "PM-15": [ + "GOV-07", + "THR-01" + ], + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" + ], + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" + ], + "PM-05": [ + "AST-01", + "AST-02" + ], + "CM-08": [ + "AST-02", + "AST-02.3" + ], + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" + ], + "SC-18(02)": [ + "AST-02.7", + "END-10" + ], + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" + ], + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" + ], + "SA-04(01)": [ + "AST-04", + "TDA-04.1" + ], + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" + ], + "PE-22": [ + "AST-04.1", + "PES-16" + ], + "SA-05": [ + "AST-04.1", + "TDA-04" + ], + "SR-12": [ + "AST-09" + ], + "SR-10": [ + "AST-15.1", + "TDA-11" + ], + "CP-02": [ + "BCD-01", + "BCD-06" + ], + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" + ], + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" + ], + "PM-08": [ + "BCD-01", + "CPL-01" + ], + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" + ], + "CP-04": [ + "BCD-04", + "BCD-05" + ], + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" + ], + "SC-28(02)": [ + "BCD-11", + "CRY-05.2" + ], + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" + ], + "SI-13": [ + "BCD-12.2", + "SEA-07" + ], + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "SC-05(02)": [ + "CAP-02", + "CAP-03" + ], + "CM-03": [ + "CHG-01", + "CHG-02" + ], + "SA-08(31)": [ + "CHG-02", + "CHG-02.2", + "CHG-06" + ], + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" + ], + "CM-04": [ + "CHG-03" + ], + "CM-05": [ + "CHG-04", + "END-03.2" + ], + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" + ], + "CM-09": [ + "CHG-05", + "CFG-01" + ], + "SC-07(29)": [ + "CLD-03", + "NET-03.8", + "NET-06.1" + ], + "SA-09(05)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" + ], + "SA-09(08)": [ + "CLD-09", + "DCH-19" + ], + "CA-07": [ + "CPL-02" + ], + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" + ], + "PM-14": [ + "CPL-02", + "PRI-08" + ], + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" + ], + "RA-03": [ + "CPL-03.2", + "RSK-04" + ], + "CM-02": [ + "CFG-02", + "CFG-02.1" + ], + "CM-06": [ + "CFG-02", + "CFG-02.7" + ], + "SA-08": [ + "CFG-02", + "SEA-01" + ], + "SA-15(05)": [ + "CFG-02", + "SEA-01" + ], + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" + ], + "SC-18(04)": [ + "CFG-03.3", + "END-10" + ], + "CM-11": [ + "CFG-05", + "END-03" + ], + "CM-11(02)": [ + "CFG-05", + "CFG-05.2", + "END-03" + ], + "CM-11(03)": [ + "CFG-05.1", + "CFG-06", + "CFG-06.1", + "END-03.1" + ], + "PM-31": [ + "MON-01" + ], + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" + ], + "SI-04(25)": [ + "MON-01.1", + "NET-03.1" + ], + "SC-48": [ + "MON-01.2", + "THR-07" + ], + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" + ], + "AU-02": [ + "MON-01.8", + "MON-02" + ], + "IR-04(05)": [ + "MON-01.11", + "IRO-02.6" + ], + "SI-04(07)": [ + "MON-01.11", + "IRO-02.1" + ], + "SI-04(12)": [ + "MON-01.12", + "MON-05.1" + ], + "AU-06": [ + "MON-02", + "MON-02.6" + ], + "IR-04(04)": [ + "MON-02", + "MON-02.1" + ], + "AU-03(03)": [ + "MON-03.5" + ], + "AU-08": [ + "MON-07", + "SEA-20" + ], + "AU-11": [ + "MON-10" + ], + "SI-04(18)": [ + "MON-11.1", + "NET-17" + ], + "IR-04(13)": [ + "MON-16", + "SEA-11", + "SEA-12" + ], + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" + ], + "SC-08(02)": [ + "CRY-01", + "CRY-01.3", + "DCH-10" + ], + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" + ], + "IA-07": [ + "CRY-02", + "IAC-12" + ], + "SC-08": [ + "CRY-03", + "CRY-04" + ], + "SC-16(01)": [ + "CRY-04", + "CRY-10" + ], + "SC-28": [ + "CRY-05", + "END-02" + ], + "AC-18": [ + "CRY-07", + "NET-15" + ], + "SC-40": [ + "CRY-07", + "NET-12.1" + ], + "MP-02": [ + "DCH-03", + "END-01" + ], + "MP-03": [ + "DCH-04", + "DCH-04.1" + ], + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" + ], + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" + ], + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" + ], + "PM-17": [ + "DCH-13.3" + ], + "AC-21": [ + "DCH-14", + "PRI-07" + ], + "AC-23": [ + "DCH-16", + "PRI-05.4" + ], + "SI-12": [ + "DCH-18", + "PRI-05" + ], + "SI-12(01)": [ + "DCH-18.1", + "PRI-05.1" + ], + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" + ], + "SA-08(33)": [ + "DCH-18.2", + "END-13.3", + "PES-06.5" + ], + "SI-12(02)": [ + "DCH-18.2", + "PRI-05.1" + ], + "SI-12(03)": [ + "DCH-21", + "PRI-05" + ], + "PM-22": [ + "DCH-22", + "PRI-10" + ], + "SI-18": [ + "DCH-22" + ], + "SI-18(04)": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" + ], + "SI-18(05)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-06.2" + ], + "PT-03(01)": [ + "DCH-22.2", + "PRI-11" + ], + "SI-19(01)": [ + "DCH-22.3", + "DCH-23.1" + ], + "SI-19": [ + "DCH-23" + ], + "SI-19(04)": [ + "DCH-23.4", + "PRI-05.3" + ], + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" + ], + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" + ], + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" + ], + "SC-18(01)": [ + "END-10", + "VPM-02", + "VPM-04" + ], + "SC-18(03)": [ + "END-10", + "NET-18" + ], + "SC-03": [ + "END-16", + "SEA-04.1" + ], + "PS-02": [ + "HRS-02", + "HRS-03.2" + ], + "PM-13": [ + "HRS-03", + "SAT-01" + ], + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" + ], + "PL-04(01)": [ + "HRS-05.2" + ], + "PS-06": [ + "HRS-06", + "HRS-06.1" + ], + "PS-06(02)": [ + "HRS-06", + "HRS-06.1" + ], + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" + ], + "AC-03(02)": [ + "HRS-12.1", + "IAC-20.5" + ], + "IA-04": [ + "IAC-01.2", + "IAC-09" + ], + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" + ], + "IA-03(04)": [ + "IAC-04", + "IAC-04.1" + ], + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "IA-12(04)": [ + "IAC-07", + "IAC-10.3", + "IAC-28.4" + ], + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" + ], + "IA-05(08)": [ + "IAC-09.5", + "IAC-10.9" + ], + "IA-05": [ + "IAC-10", + "IAC-10.8" + ], + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" + ], + "IA-05(02)": [ + "IAC-10.2" + ], + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" + ], + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" + ], + "AC-06": [ + "IAC-20", + "IAC-21" + ], + "IR-04": [ + "IRO-02" + ], + "IR-08": [ + "IRO-04" + ], + "IR-08(01)": [ + "IRO-04.1" + ], + "IR-02": [ + "IRO-05" + ], + "IR-02(03)": [ + "IRO-05" + ], + "IR-03": [ + "IRO-06" + ], + "IR-04(12)": [ + "IRO-08", + "IRO-13" + ], + "IR-05": [ + "IRO-09" + ], + "IR-06(02)": [ + "IRO-10.3", + "IRO-13" + ], + "IR-04(10)": [ + "IRO-10.4", + "TPM-11" + ], + "IR-07": [ + "IRO-11" + ], + "IR-09": [ + "IRO-12", + "IRO-12.1" + ], + "PM-10": [ + "IAO-01" + ], + "SA-11(05)": [ + "IAO-02.2", + "IAO-04", + "TDA-09", + "TDA-09.5", + "VPM-07" + ], + "CA-05": [ + "IAO-05" + ], + "PM-04": [ + "IAO-05", + "VPM-02" + ], + "CA-06": [ + "IAO-07" + ], + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" + ], + "SC-07(09)": [ + "NET-03", + "NET-03.2" + ], + "SC-07(11)": [ + "NET-03", + "NET-04.1" + ], + "SC-07(24)": [ + "NET-03.4" + ], + "SC-07(10)": [ + "NET-03.5", + "NET-17" + ], + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" + ], + "SI-10": [ + "NET-12", + "TDA-18" + ], + "SC-07(08)": [ + "NET-18", + "NET-18.1" + ], + "SC-07(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" + ], + "PE-08(03)": [ + "PES-06.5" + ], + "PE-13(02)": [ + "PES-08.2", + "PES-08.3" + ], + "PM-18": [ + "PRI-01" + ], + "PM-19": [ + "PRI-01.1" + ], + "PT-05(02)": [ + "PRI-01.2" + ], + "PM-20": [ + "PRI-01.3" + ], + "PM-20(01)": [ + "PRI-02" + ], + "PT-05": [ + "PRI-02" + ], + "PT-03": [ + "PRI-02.1", + "PRI-05.1" + ], + "PT-03(02)": [ + "PRI-02.2", + "PRI-10.1" + ], + "PT-08": [ + "PRI-02.3" + ], + "PT-06": [ + "PRI-02.4" + ], + "PT-06(01)": [ + "PRI-02.5" + ], + "PT-06(02)": [ + "PRI-02.6" + ], + "PT-04": [ + "PRI-03" + ], + "PT-02": [ + "PRI-04", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" + ], + "PT-07": [ + "PRI-05.4", + "PRI-05.7" + ], + "PM-05(01)": [ + "PRI-05.5", + "PRI-05.6" + ], + "PT-07(01)": [ + "PRI-05.7" + ], + "PT-07(02)": [ + "PRI-05.7" + ], + "AC-03(14)": [ + "PRI-06" + ], + "PM-26": [ + "PRI-06.3", + "PRI-06.4" + ], + "PM-27": [ + "PRI-14" + ], + "PM-21": [ + "PRI-14.1" + ], + "PM-03": [ + "PRM-02" + ], + "SA-02": [ + "PRM-03" + ], + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" + ], + "PM-11": [ + "PRM-06" + ], + "SA-03": [ + "PRM-07", + "SEA-07.1" + ], + "SA-03(01)": [ + "PRM-07", + "SEA-07.1", + "TDA-07" + ], + "SA-08(30)": [ + "PRM-07", + "SEA-07.1" + ], + "PM-09": [ + "RSK-01" + ], + "PM-28": [ + "RSK-01.1" + ], + "RA-07": [ + "RSK-06.1" + ], + "SR-02": [ + "RSK-09", + "TPM-03" + ], + "SR-07": [ + "RSK-09", + "OPS-01" + ], + "RA-08": [ + "RSK-10" + ], + "CA-07(04)": [ + "RSK-11" + ], + "PL-08": [ + "SEA-02" + ], + "PM-07": [ + "SEA-02" + ], + "SA-03(03)": [ + "SEA-07.1", + "SEA-08.1" + ], + "SC-38": [ + "OPS-01", + "OPS-04" + ], + "AT-02": [ + "SAT-02" + ], + "AT-03": [ + "SAT-03" + ], + "AT-03(05)": [ + "SAT-03.3" + ], + "AT-04": [ + "SAT-04" + ], + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" + ], + "SA-23": [ + "TDA-01", + "TDA-01.1", + "TDA-12" + ], + "SA-04(03)": [ + "TDA-02.3", + "TDA-06" + ], + "SR-03(01)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" + ], + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" + ], + "SA-11(02)": [ + "TDA-06.2", + "TDA-15" + ], + "SA-11": [ + "TDA-09" + ], + "SA-11(06)": [ + "TDA-09", + "VPM-01.1" + ], + "SA-11(07)": [ + "TDA-09", + "VPM-01.1" + ], + "SA-22": [ + "TDA-17", + "TDA-17.1" + ], + "SA-09": [ + "TPM-04" + ], + "SR-03(03)": [ + "TPM-05", + "TPM-05.2" + ], + "SI-02(04)": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" + ], + "RA-05": [ + "VPM-06", + "VPM-06.1" + ] + }, + "general-nist-800-53-r5-2-low": { + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" + ], + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" + ], + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" + ], + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" + ], + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" + ], + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" + ], + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" + ], + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" + ], + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" + ], + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" + ], + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" + ], + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" + ], + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" + ], + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" + ], + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" + ], + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" + ], + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" + ], + "CM-08": [ + "AST-02", + "AST-02.3" + ], + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" + ], + "SA-05": [ + "AST-04.1", + "TDA-04" + ], + "SR-12": [ + "AST-09" + ], + "SR-10": [ + "AST-15.1", + "TDA-11" + ], + "CP-02": [ + "BCD-01", + "BCD-06" + ], + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" + ], + "CP-03": [ + "BCD-03" + ], + "CP-04": [ + "BCD-04", + "BCD-05" + ], + "CP-09": [ + "BCD-11" + ], + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "CM-04": [ + "CHG-03" + ], + "CM-05": [ + "CHG-04", + "END-03.2" + ], + "CA-07": [ + "CPL-02" + ], + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" + ], + "RA-03": [ + "CPL-03.2", + "RSK-04" + ], + "CM-02": [ + "CFG-02", + "CFG-02.1" + ], + "CM-06": [ + "CFG-02", + "CFG-02.7" + ], + "PL-10": [ + "CFG-02" + ], + "SA-08": [ + "CFG-02", + "SEA-01" + ], + "PL-11": [ + "CFG-02.9" + ], + "CM-07": [ + "CFG-03" + ], + "CM-10": [ + "CFG-04" + ], + "CM-11": [ + "CFG-05", + "END-03" + ], + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" + ], + "AU-02": [ + "MON-01.8", + "MON-02" + ], + "AU-06": [ + "MON-02", + "MON-02.6" + ], + "AU-03": [ + "MON-03" + ], + "AU-04": [ + "MON-04" + ], + "AU-05": [ + "MON-05" + ], + "AU-12": [ + "MON-06" + ], + "AU-08": [ + "MON-07", + "SEA-20" + ], + "AU-09": [ + "MON-08" + ], + "AU-11": [ + "MON-10" + ], + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" + ], + "IA-07": [ + "CRY-02", + "IAC-12" + ], + "AC-18": [ + "CRY-07", + "NET-15" + ], + "SC-12": [ + "CRY-08" + ], + "MP-02": [ + "DCH-03", + "END-01" + ], + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" + ], + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" + ], + "AC-20": [ + "DCH-13" + ], + "AC-22": [ + "DCH-15" + ], + "SI-12": [ + "DCH-18", + "PRI-05" + ], + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" + ], + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" + ], + "SC-15": [ + "END-14" + ], + "PS-02": [ + "HRS-02", + "HRS-03.2" + ], + "PS-09": [ + "HRS-03" + ], + "PS-03": [ + "HRS-04" + ], + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" + ], + "PL-04(01)": [ + "HRS-05.2" + ], + "PS-06": [ + "HRS-06", + "HRS-06.1" + ], + "PS-08": [ + "HRS-07" + ], + "PS-05": [ + "HRS-08" + ], + "PS-04": [ + "HRS-09" + ], + "PS-07": [ + "HRS-10" + ], + "IA-04": [ + "IAC-01.2", + "IAC-09" + ], + "IA-02": [ + "IAC-02" + ], + "IA-02(08)": [ + "IAC-02.2" + ], + "IA-02(12)": [ + "IAC-02.3" + ], + "IA-08": [ + "IAC-03" + ], + "IA-08(01)": [ + "IAC-03.1" + ], + "IA-08(02)": [ + "IAC-03.2" + ], + "IA-08(04)": [ + "IAC-03.3" + ], + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" + ], + "IA-05": [ + "IAC-10", + "IAC-10.8" + ], + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" + ], + "IA-06": [ + "IAC-11" + ], + "IA-11": [ + "IAC-14" + ], + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" + ], + "AC-07": [ + "IAC-22" + ], + "AC-14": [ + "IAC-26" + ], + "IR-04": [ + "IRO-02" + ], + "IR-08": [ + "IRO-04" + ], + "IR-02": [ + "IRO-05" + ], + "IR-05": [ + "IRO-09" + ], + "IR-07": [ + "IRO-11" + ], + "CA-05": [ + "IAO-05" + ], + "CA-06": [ + "IAO-07" + ], + "MA-02": [ + "MNT-02" + ], + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" + ], + "MA-05": [ + "MNT-06" + ], + "SR-11(02)": [ + "MNT-07" + ], + "AC-19": [ + "MDM-02" + ], + "SC-07": [ + "NET-03" + ], + "CA-03": [ + "NET-05" + ], + "CA-09": [ + "NET-05.2" + ], + "SC-20": [ + "NET-10" + ], + "SC-22": [ + "NET-10.1" + ], + "SC-21": [ + "NET-10.2" + ], + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" + ], + "AC-17": [ + "NET-14" + ], + "PE-02": [ + "PES-02" + ], + "PE-03": [ + "PES-03" + ], + "PE-08": [ + "PES-03.3" + ], + "PE-06": [ + "PES-05" + ], + "PE-12": [ + "PES-07.4" + ], + "PE-15": [ + "PES-07.5" + ], + "PE-13": [ + "PES-08" + ], + "PE-14": [ + "PES-09" + ], + "PE-16": [ + "PES-10" + ], + "SA-02": [ + "PRM-03" + ], + "SA-03": [ + "PRM-07", + "SEA-07.1" + ], + "RA-02": [ + "RSK-02" + ], + "RA-07": [ + "RSK-06.1" + ], + "SR-02": [ + "RSK-09", + "TPM-03" + ], + "RA-03(01)": [ + "RSK-09.1" + ], + "CA-07(04)": [ + "RSK-11" + ], + "SC-39": [ + "SEA-04" + ], + "AC-08": [ + "SEA-18" + ], + "AT-02": [ + "SAT-02" + ], + "AT-03": [ + "SAT-03" + ], + "AT-04": [ + "SAT-04" + ], + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" + ], + "SA-04(10)": [ + "TDA-02.2" + ], + "SR-11": [ + "TDA-11" + ], + "SR-11(01)": [ + "TDA-11.1" + ], + "SA-22": [ + "TDA-17", + "TDA-17.1" + ], + "SR-02(01)": [ + "TPM-03" + ], + "SR-05": [ + "TPM-03.1" + ], + "SR-03": [ + "TPM-03.3" + ], + "SA-09": [ + "TPM-04" + ], + "SR-08": [ + "TPM-05.1" + ], + "AT-02(02)": [ + "THR-05" + ], + "RA-05(11)": [ + "THR-06" + ], + "RA-05": [ + "VPM-06", + "VPM-06.1" + ], + "RA-05(02)": [ + "VPM-06.1" + ] + }, + "general-nist-800-53-r5-2-mod": { + "CM-08(01)": [ + "AST-02.1" + ], + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" + ], + "SA-04(01)": [ + "AST-04", + "TDA-04.1" + ], + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" + ], + "CP-02(01)": [ + "BCD-01.1" + ], + "CP-02(08)": [ + "BCD-02" + ], + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" + ], + "CP-04(01)": [ + "BCD-04.1" + ], + "CP-06": [ + "BCD-08" + ], + "CP-06(01)": [ + "BCD-08.1" + ], + "CP-06(03)": [ + "BCD-08.2" + ], + "CP-07": [ + "BCD-09" + ], + "CP-07(01)": [ + "BCD-09.1" + ], + "CP-07(02)": [ + "BCD-09.2" + ], + "CP-07(03)": [ + "BCD-09.3" + ], + "CP-08": [ + "BCD-10" + ], + "CP-08(02)": [ + "BCD-10" + ], + "CP-08(01)": [ + "BCD-10.1" + ], + "CP-09(01)": [ + "BCD-11.1" + ], + "CP-09(08)": [ + "BCD-11.4" + ], + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" + ], + "CP-10(02)": [ + "BCD-12.1" + ], + "CM-03": [ + "CHG-01", + "CHG-02" + ], + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" + ], + "CM-03(04)": [ + "CHG-02.3" + ], + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" + ], + "CM-09": [ + "CHG-05", + "CFG-01" + ], + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" + ], + "CM-02(02)": [ + "CFG-02.2" + ], + "CM-02(03)": [ + "CFG-02.3" + ], + "CM-02(07)": [ + "CFG-02.5" + ], + "CM-07(01)": [ + "CFG-03.1" + ], + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" + ], + "CM-07(05)": [ + "CFG-03.3" + ], + "SC-07(07)": [ + "CFG-03.4" + ], + "SI-04(02)": [ + "MON-01.2" + ], + "SI-04(04)": [ + "MON-01.3" + ], + "SI-04(05)": [ + "MON-01.4" + ], + "AU-06(03)": [ + "MON-02.1" + ], + "AU-03(01)": [ + "MON-03.1" + ], + "AU-06(01)": [ + "MON-03.1" + ], + "AU-07": [ + "MON-06" + ], + "AU-07(01)": [ + "MON-06" + ], + "AU-09(04)": [ + "MON-08.2" + ], + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" + ], + "SC-08": [ + "CRY-03", + "CRY-04" + ], + "SC-28": [ + "CRY-05", + "END-02" + ], + "SC-17": [ + "CRY-08" + ], + "MP-03": [ + "DCH-04", + "DCH-04.1" + ], + "MP-04": [ + "DCH-06" + ], + "MP-05": [ + "DCH-07" + ], + "AC-20(01)": [ + "DCH-13.1" + ], + "AC-20(02)": [ + "DCH-13.2" + ], + "AC-21": [ + "DCH-14", + "PRI-07" + ], + "CM-12": [ + "DCH-24" + ], + "CM-12(01)": [ + "DCH-24.1" + ], + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" + ], + "SI-07(01)": [ + "END-06.1" + ], + "SI-07(07)": [ + "END-06.2" + ], + "SI-08": [ + "END-08" + ], + "SI-08(02)": [ + "END-08.2" + ], + "SC-18": [ + "END-10" + ], + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" + ], + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" + ], + "IA-03": [ + "IAC-04" + ], + "IA-05(02)": [ + "IAC-10.2" + ], + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" + ], + "AC-02(01)": [ + "IAC-15.1" + ], + "AC-02(02)": [ + "IAC-15.2" + ], + "AC-02(03)": [ + "IAC-15.3" + ], + "AC-02(04)": [ + "IAC-15.4" + ], + "AC-06(07)": [ + "IAC-17" + ], + "AC-06": [ + "IAC-20", + "IAC-21" + ], + "AC-06(01)": [ + "IAC-21.1" + ], + "AC-06(02)": [ + "IAC-21.2" + ], + "AC-06(05)": [ + "IAC-21.3" + ], + "AC-06(09)": [ + "IAC-21.4" + ], + "AC-06(10)": [ + "IAC-21.5" + ], + "AC-02(05)": [ + "IAC-24" + ], + "AC-11": [ + "IAC-24" + ], + "AC-11(01)": [ + "IAC-24.1" + ], + "AC-12": [ + "IAC-25" + ], + "IA-12": [ + "IAC-28" + ], + "IA-12(02)": [ + "IAC-28.2" + ], + "IA-12(03)": [ + "IAC-28.3" + ], + "IA-12(05)": [ + "IAC-28.5" + ], + "IR-04(01)": [ + "IRO-02.1" + ], + "IR-03": [ + "IRO-06" + ], + "IR-03(02)": [ + "IRO-06.1" + ], + "IR-06(01)": [ + "IRO-10.1" + ], + "IR-06(03)": [ + "IRO-10.4" + ], + "IR-07(01)": [ + "IRO-11.1" + ], + "CA-02(01)": [ + "IAO-02.1" + ], + "CM-04(02)": [ + "IAO-06" + ], + "MA-06": [ + "MNT-03" + ], + "MA-03": [ + "MNT-04" + ], + "MA-03(01)": [ + "MNT-04.1" + ], + "MA-03(02)": [ + "MNT-04.2" + ], + "MA-03(03)": [ + "MNT-04.3" + ], + "AC-19(05)": [ + "MDM-03" + ], + "SC-07(03)": [ + "NET-03.1" + ], + "SC-07(04)": [ + "NET-03.2" + ], + "AC-04": [ + "NET-04" + ], + "SC-07(05)": [ + "NET-04.1" + ], + "SC-10": [ + "NET-07" + ], + "SC-23": [ + "NET-09" + ], + "SI-10": [ + "NET-12", + "TDA-18" + ], + "AC-17(01)": [ + "NET-14.1" + ], + "AC-17(02)": [ + "NET-14.2" + ], + "AC-17(03)": [ + "NET-14.3" + ], + "AC-17(04)": [ + "NET-14.4" + ], + "AC-18(01)": [ + "NET-15.1" + ], + "AC-18(03)": [ + "NET-15.2" + ], + "SC-07(08)": [ + "NET-18", + "NET-18.1" + ], + "PE-06(01)": [ + "PES-05.1" + ], + "PE-09": [ + "PES-07" + ], + "PE-10": [ + "PES-07.2" + ], + "PE-11": [ + "PES-07.3" + ], + "PE-13(01)": [ + "PES-08.1" + ], + "PE-17": [ + "PES-11" + ], + "PE-04": [ + "PES-12.1" + ], + "PE-05": [ + "PES-12.2" + ], + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" + ], + "PL-08": [ + "SEA-02" + ], + "SC-02": [ + "SEA-03.2" + ], + "SC-04": [ + "SEA-05" + ], + "SI-16": [ + "SEA-10" + ], + "AT-02(03)": [ + "SAT-02.2" + ], + "SA-04(09)": [ + "TDA-02.1" + ], + "SA-15": [ + "TDA-06" + ], + "SA-15(03)": [ + "TDA-06.1" + ], + "SA-11": [ + "TDA-09" + ], + "SA-10": [ + "TDA-14" + ], + "SI-11": [ + "TDA-19" + ], + "SA-09(02)": [ + "TPM-04.2" + ], + "SR-06": [ + "TPM-08" + ], + "SI-02(02)": [ + "VPM-05.2" + ], + "RA-05(05)": [ + "VPM-06.3" + ] + }, + "general-nist-800-53-r5-2-high": { + "CM-08(02)": [ + "AST-02.9" + ], + "CM-08(04)": [ + "AST-03.1" + ], + "SR-09": [ + "AST-15" + ], + "SR-09(01)": [ + "AST-15" + ], + "CP-06(02)": [ + "BCD-01.4" + ], + "CP-02(05)": [ + "BCD-02.2" + ], + "CP-03(01)": [ + "BCD-03.1" + ], + "CP-04(02)": [ + "BCD-04.2" + ], + "CP-07(04)": [ + "BCD-09.4" + ], + "CP-08(03)": [ + "BCD-10.2" + ], + "CP-08(04)": [ + "BCD-10.3" + ], + "CP-09(03)": [ + "BCD-11.2" + ], + "CP-09(02)": [ + "BCD-11.5" + ], + "CP-09(05)": [ + "BCD-11.6" + ], + "CP-10(04)": [ + "BCD-12.4" + ], + "CP-02(02)": [ + "CAP-03" + ], + "CM-03(01)": [ + "CHG-02.1" + ], + "CM-03(06)": [ + "CHG-02.5" + ], + "CM-05(01)": [ + "CHG-04.1" + ], + "SI-07(15)": [ + "CHG-04.2" + ], + "SI-06": [ + "CHG-06" + ], + "CM-06(01)": [ + "CFG-02.2" + ], + "CM-06(02)": [ + "CFG-02.8" + ], + "SI-04(14)": [ + "MON-01.5" + ], + "SI-04(12)": [ + "MON-01.12", + "MON-05.1" + ], + "SI-04(20)": [ + "MON-01.15" + ], + "IR-04(04)": [ + "MON-02", + "MON-02.1" + ], + "AU-06(05)": [ + "MON-02.3" + ], + "AU-06(06)": [ + "MON-02.4" + ], + "AU-12(01)": [ + "MON-02.7" + ], + "AU-12(03)": [ + "MON-02.8" + ], + "AU-05(02)": [ + "MON-05.1" + ], + "AU-05(01)": [ + "MON-05.2" + ], + "AU-09(02)": [ + "MON-08.1" + ], + "AU-09(03)": [ + "MON-08.3" + ], + "AU-10": [ + "MON-09" + ], + "SI-04(22)": [ + "MON-11.2" + ], + "AC-02(12)": [ + "MON-16" + ], + "SC-12(01)": [ + "CRY-09.3" + ], + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" + ], + "MP-06(01)": [ + "DCH-09.1" + ], + "MP-06(02)": [ + "DCH-09.2" + ], + "CA-03(06)": [ + "DCH-14.2" + ], + "SI-07(02)": [ + "END-06.3" + ], + "SI-07(05)": [ + "END-06.4" + ], + "SC-03": [ + "END-16", + "SEA-04.1" + ], + "PS-04(02)": [ + "HRS-09.4" + ], + "IA-02(05)": [ + "IAC-02.1" + ], + "IA-12(04)": [ + "IAC-07", + "IAC-10.3", + "IAC-28.4" + ], + "AC-02(11)": [ + "IAC-15.8" + ], + "AC-06(03)": [ + "IAC-21.6" + ], + "AC-10": [ + "IAC-23" + ], + "IR-02(01)": [ + "IRO-05.1" + ], + "IR-02(02)": [ + "IRO-05.2" + ], + "IR-04(11)": [ + "IRO-07" + ], + "IR-05(01)": [ + "IRO-09.1" + ], + "CA-02(02)": [ + "IAO-02.2" + ], + "MA-02(02)": [ + "MNT-02.1" + ], + "MA-04(03)": [ + "MNT-05.6" + ], + "MA-05(01)": [ + "MNT-06.1" + ], + "SC-07(21)": [ + "NET-03.7" + ], + "AC-04(04)": [ + "NET-04.3" + ], + "AC-18(04)": [ + "NET-15.3" + ], + "AC-18(05)": [ + "NET-15.4" + ], + "SI-04(10)": [ + "NET-18.2" + ], + "PE-03(01)": [ + "PES-03.4" + ], + "PE-06(04)": [ + "PES-05.2" + ], + "PE-08(01)": [ + "PES-06.4" + ], + "PE-11(01)": [ + "PES-07.3" + ], + "PE-15(01)": [ + "PES-07.6" + ], + "PE-13(02)": [ + "PES-08.2", + "PES-08.3" + ], + "PE-18": [ + "PES-12" + ], + "SC-07(18)": [ + "SEA-01" + ], + "SC-24": [ + "SEA-07.2" + ], + "SA-04(05)": [ + "TDA-02.4" + ], + "SA-17": [ + "TDA-05" + ], + "CM-04(01)": [ + "TDA-08" + ], + "SA-21": [ + "TDA-13" + ], + "SA-16": [ + "TDA-16" + ], + "SI-05(01)": [ + "THR-03" + ], + "RA-05(04)": [ + "VPM-06.8" + ], + "CA-08": [ + "VPM-07" + ], + "CA-08(01)": [ + "VPM-07.1" + ] + }, + "general-nist-800-66-r2": { + "164.316(a)": [ + "GOV-01", + "GOV-02" + ], + "164.308(a)(1)": [ + "GOV-02", + "GOV-09", + "GOV-15.2", + "CHG-01", + "CFG-01", + "MON-01", + "MON-01.8", + "HRS-07", + "IRO-01", + "IRO-09", + "RSK-04" + ], + "164.308(a)(3)": [ + "GOV-02", + "CFG-08", + "HRS-01", + "HRS-02", + "HRS-03", + "HRS-08", + "HRS-09", + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-08", + "IAC-17", + "IAC-21", + "IAC-28.1" + ], + "164.308(a)(4)": [ + "GOV-02", + "IAC-01", + "IAC-08" + ], + "164.308(a)(6)": [ + "GOV-02", + "IRO-01", + "IRO-02" + ], + "164.308(a)(7)": [ + "GOV-02", + "AST-01", + "AST-01.1", + "BCD-01", + "BCD-02", + "BCD-02.2", + "BCD-04", + "BCD-05", + "BCD-11", + "BCD-12", + "IRO-01", + "TPM-02" + ], + "164.310(a)": [ + "GOV-02", + "BCD-09.2", + "HRS-03", + "IAC-01", + "MNT-01", + "MNT-02", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03", + "PES-06" + ], + "164.310(b)": [ + "GOV-02", + "END-01", + "HRS-05", + "HRS-05.1", + "HRS-05.3", + "PES-03.4", + "PES-04", + "OPS-01.1", + "OPS-03" + ], + "164.310(d)": [ + "GOV-02", + "AST-01", + "AST-02", + "AST-02.1", + "AST-02.9", + "AST-03", + "AST-03.1", + "AST-09", + "AST-11", + "BCD-11", + "DCH-01", + "DCH-03", + "DCH-07", + "DCH-07.1", + "DCH-09", + "DCH-13.2", + "MNT-01", + "MNT-04.3" + ], + "164.312(a)": [ + "GOV-02", + "CFG-02", + "CRY-01", + "HRS-02", + "HRS-03", + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-09", + "IAC-15", + "IAC-15.2", + "IAC-15.9", + "IAC-21", + "IAC-25" + ], + "164.312(c)": [ + "GOV-02", + "CFG-08", + "CFG-08.1", + "MON-01.7", + "MON-01.15", + "MON-16", + "DCH-01", + "DCH-01.2" + ], + "164.316(b)": [ + "GOV-02", + "GOV-03", + "CPL-02", + "CPL-03", + "DCH-18", + "OPS-01.1", + "OPS-03" + ], + "164.308(a)(2)": [ + "GOV-04" + ], + "164.314(a)": [ + "CPL-01", + "TPM-05", + "TPM-05.1", + "TPM-05.2" + ], + "164.308(a)(8)": [ + "CPL-03.2", + "IAO-01.1", + "IAO-02" + ], + "164.312(e)(1)": [ + "CFG-02", + "CRY-03", + "NET-01" + ], + "164.312(b)": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-01.16", + "MON-03", + "MON-03.2", + "MON-16" + ], + "164.310(c)": [ + "END-02", + "PES-03", + "PES-03.4", + "PES-04", + "PES-04.1" + ], + "164.312(d)": [ + "HRS-01", + "HRS-04", + "IAC-28", + "IAC-28.2", + "IAC-28.3", + "TPM-01" + ], + "164.308(a)(5)": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.2", + "SAT-03.6" + ], + "164.308(b)(1)": [ + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.2", + "TPM-05.4" + ], + "164.314(b)": [ + "TPM-05", + "TPM-05.1" + ] + }, + "general-nist-800-82-r3": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" + ], + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" + ], + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" + ], + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" + ], + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" + ], + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" + ], + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" + ], + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" + ], + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" + ], + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" + ], + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" + ], + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" + ], + "PT-01": [ + "GOV-02", + "GOV-03", + "PRI-01", + "SEA-01" + ], + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" + ], + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" + ], + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" + ], + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" + ], + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" + ], + "PL-09": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" + ], + "PM-02": [ + "GOV-04" + ], + "PM-06": [ + "GOV-04", + "GOV-05" + ], + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" + ], + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" + ], + "PM-15": [ + "GOV-07", + "THR-01" + ], + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" + ], + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" + ], + "PM-32": [ + "GOV-11" + ], + "PM-05": [ + "AST-01", + "AST-02" + ], + "CM-08": [ + "AST-02", + "AST-02.3" + ], + "CM-08(01)": [ + "AST-02.1" + ], + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" + ], + "CM-08(06)": [ + "AST-02.4" + ], + "IA-03(03)": [ + "AST-02.5" + ], + "SC-07(19)": [ + "AST-02.5" + ], + "SC-18(02)": [ + "AST-02.7", + "END-10" + ], + "CM-13": [ + "AST-02.8" + ], + "CM-08(02)": [ + "AST-02.9" + ], + "CM-08(07)": [ + "AST-02.9" + ], + "CM-08(08)": [ + "AST-02.10" + ], + "CM-08(09)": [ + "AST-02.11" + ], + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" + ], + "CM-08(04)": [ + "AST-03.1" + ], + "SR-04": [ + "AST-03.2" + ], + "SR-04(01)": [ + "AST-03.2" + ], + "SR-04(02)": [ + "AST-03.2" + ], + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" + ], + "SA-04(01)": [ + "AST-04", + "TDA-04.1" + ], + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" + ], + "PE-22": [ + "AST-04.1", + "PES-16" + ], + "SA-05": [ + "AST-04.1", + "TDA-04" + ], + "SR-12": [ + "AST-09" + ], + "SC-43": [ + "AST-14" + ], + "SR-09": [ + "AST-15" + ], + "SR-09(01)": [ + "AST-15" + ], + "SR-10": [ + "AST-15.1", + "TDA-11" + ], + "CP-02": [ + "BCD-01", + "BCD-06" + ], + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" + ], + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" + ], + "PM-08": [ + "BCD-01", + "CPL-01" + ], + "CP-02(01)": [ + "BCD-01.1" + ], + "CP-02(07)": [ + "BCD-01.2" + ], + "CP-02(06)": [ + "BCD-01.3" + ], + "CP-06(02)": [ + "BCD-01.4" + ], + "CP-02(08)": [ + "BCD-02" + ], + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" + ], + "CP-02(05)": [ + "BCD-02.2" + ], + "CP-03": [ + "BCD-03" + ], + "CP-03(01)": [ + "BCD-03.1" + ], + "CP-03(02)": [ + "BCD-03.2" + ], + "CP-04": [ + "BCD-04", + "BCD-05" + ], + "CP-04(01)": [ + "BCD-04.1" + ], + "CP-04(02)": [ + "BCD-04.2" + ], + "CP-13": [ + "BCD-07" + ], + "CP-06": [ + "BCD-08" + ], + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" + ], + "CP-06(01)": [ + "BCD-08.1" + ], + "CP-06(03)": [ + "BCD-08.2" + ], + "CP-07": [ + "BCD-09" + ], + "CP-07(01)": [ + "BCD-09.1" + ], + "CP-07(02)": [ + "BCD-09.2" + ], + "CP-07(03)": [ + "BCD-09.3" + ], + "CP-07(04)": [ + "BCD-09.4" + ], + "CP-07(06)": [ + "BCD-09.5" + ], + "CP-08": [ + "BCD-10" + ], + "CP-08(02)": [ + "BCD-10" + ], + "CP-11": [ + "BCD-10" + ], + "CP-08(01)": [ + "BCD-10.1" + ], + "CP-08(03)": [ + "BCD-10.2" + ], + "CP-08(04)": [ + "BCD-10.3" + ], + "SC-47": [ + "BCD-10.4" + ], + "CP-09": [ + "BCD-11" + ], + "SC-28(02)": [ + "BCD-11", + "CRY-05.2" + ], + "CP-09(01)": [ + "BCD-11.1" + ], + "CP-09(03)": [ + "BCD-11.2" + ], + "CP-09(08)": [ + "BCD-11.4" + ], + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" + ], + "CP-09(02)": [ + "BCD-11.5" + ], + "CP-09(05)": [ + "BCD-11.6" + ], + "CP-09(06)": [ + "BCD-11.7" + ], + "CP-09(07)": [ + "BCD-11.8" + ], + "CP-10(02)": [ + "BCD-12.1" + ], + "SI-13": [ + "BCD-12.2", + "SEA-07" + ], + "CP-10(04)": [ + "BCD-12.4" + ], + "CP-10(06)": [ + "BCD-13" + ], + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "SC-05(03)": [ + "CAP-01" + ], + "SC-05(01)": [ + "CAP-02" + ], + "SC-05(02)": [ + "CAP-02", + "CAP-03" + ], + "SC-06": [ + "CAP-02" + ], + "CP-02(02)": [ + "CAP-03" + ], + "CM-03": [ + "CHG-01", + "CHG-02" + ], + "SA-08(31)": [ + "CHG-02", + "CHG-02.2", + "CHG-06" + ], + "CM-03(01)": [ + "CHG-02.1" + ], + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" + ], + "CM-03(07)": [ + "CHG-02.2" + ], + "CM-03(04)": [ + "CHG-02.3" + ], + "CM-03(05)": [ + "CHG-02.4" + ], + "CM-03(06)": [ + "CHG-02.5" + ], + "CM-04": [ + "CHG-03" + ], + "CM-05": [ + "CHG-04", + "END-03.2" + ], + "CM-05(01)": [ + "CHG-04.1" + ], + "CM-14": [ + "CHG-04.2" + ], + "SI-07(15)": [ + "CHG-04.2" + ], + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" + ], + "CM-05(04)": [ + "CHG-04.3" + ], + "CM-05(05)": [ + "CHG-04.4" + ], + "CM-05(06)": [ + "CHG-04.5" + ], + "CM-09": [ + "CHG-05", + "CFG-01" + ], + "SI-06": [ + "CHG-06" + ], + "SI-06(03)": [ + "CHG-06.1" + ], + "SC-07(29)": [ + "CLD-03", + "NET-03.8", + "NET-06.1" + ], + "SA-09(05)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" + ], + "SA-09(08)": [ + "CLD-09", + "DCH-19" + ], + "CA-07": [ + "CPL-02" + ], + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" + ], + "PM-14": [ + "CPL-02", + "PRI-08" + ], + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" + ], + "RA-03": [ + "CPL-03.2", + "RSK-04" + ], + "CM-09(01)": [ + "CFG-01.1" + ], + "CM-02": [ + "CFG-02", + "CFG-02.1" + ], + "CM-06": [ + "CFG-02", + "CFG-02.7" + ], + "PL-10": [ + "CFG-02" + ], + "SA-08": [ + "CFG-02", + "SEA-01" + ], + "SA-15(05)": [ + "CFG-02", + "SEA-01" + ], + "CM-02(02)": [ + "CFG-02.2" + ], + "CM-06(01)": [ + "CFG-02.2" + ], + "CM-02(03)": [ + "CFG-02.3" + ], + "CM-02(06)": [ + "CFG-02.4" + ], + "CM-02(07)": [ + "CFG-02.5" + ], + "CM-07(06)": [ + "CFG-02.5" + ], + "CM-07(07)": [ + "CFG-02.5" + ], + "CM-07(09)": [ + "CFG-02.5" + ], + "CM-06(02)": [ + "CFG-02.8" + ], + "PL-11": [ + "CFG-02.9" + ], + "CM-07": [ + "CFG-03" + ], + "CM-07(01)": [ + "CFG-03.1" + ], + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" + ], + "CM-07(04)": [ + "CFG-03.3" + ], + "CM-07(05)": [ + "CFG-03.3" + ], + "SC-18(04)": [ + "CFG-03.3", + "END-10" + ], + "SC-07(07)": [ + "CFG-03.4" + ], + "CM-10": [ + "CFG-04" + ], + "CM-10(01)": [ + "CFG-04.1" + ], + "CM-11": [ + "CFG-05", + "END-03" + ], + "CM-11(02)": [ + "CFG-05", + "CFG-05.2", + "END-03" + ], + "CM-11(03)": [ + "CFG-05.1", + "CFG-06", + "CFG-06.1", + "END-03.1" + ], + "CM-03(08)": [ + "CFG-06", + "CFG-06.1" + ], + "AC-03(11)": [ + "CFG-08" + ], + "PM-31": [ + "MON-01" + ], + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" + ], + "SI-04(01)": [ + "MON-01.1" + ], + "SI-04(25)": [ + "MON-01.1", + "NET-03.1" + ], + "SC-48": [ + "MON-01.2", + "THR-07" + ], + "SI-04(02)": [ + "MON-01.2" + ], + "SI-04(04)": [ + "MON-01.3" + ], + "SI-04(05)": [ + "MON-01.4" + ], + "SI-04(14)": [ + "MON-01.5" + ], + "SI-04(23)": [ + "MON-01.6" + ], + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" + ], + "AU-02": [ + "MON-01.8", + "MON-02" + ], + "IR-04(05)": [ + "MON-01.11", + "IRO-02.6" + ], + "SI-04(07)": [ + "MON-01.11", + "IRO-02.1" + ], + "SI-04(12)": [ + "MON-01.12", + "MON-05.1" + ], + "SI-04(13)": [ + "MON-01.13" + ], + "SI-04(19)": [ + "MON-01.14" + ], + "SI-04(20)": [ + "MON-01.15" + ], + "AU-14(03)": [ + "MON-01.17" + ], + "AU-06": [ + "MON-02", + "MON-02.6" + ], + "IR-04(04)": [ + "MON-02", + "MON-02.1" + ], + "AU-06(03)": [ + "MON-02.1" + ], + "AU-06(09)": [ + "MON-02.1" + ], + "SI-04(16)": [ + "MON-02.1" + ], + "AU-06(04)": [ + "MON-02.2" + ], + "AU-06(05)": [ + "MON-02.3" + ], + "SI-04(17)": [ + "MON-02.3" + ], + "AU-06(06)": [ + "MON-02.4" + ], + "AU-06(07)": [ + "MON-02.5" + ], + "AU-12(01)": [ + "MON-02.7" + ], + "AU-12(03)": [ + "MON-02.8" + ], + "AU-03": [ + "MON-03" + ], + "AU-03(01)": [ + "MON-03.1" + ], + "AU-06(01)": [ + "MON-03.1" + ], + "AU-06(08)": [ + "MON-03.3" + ], + "AU-03(03)": [ + "MON-03.5" + ], + "AU-04": [ + "MON-04" + ], + "AU-05": [ + "MON-05" + ], + "AU-05(02)": [ + "MON-05.1" + ], + "AU-05(01)": [ + "MON-05.2" + ], + "AU-07": [ + "MON-06" + ], + "AU-07(01)": [ + "MON-06" + ], + "AU-12": [ + "MON-06" + ], + "AU-12(04)": [ + "MON-06.1" + ], + "CA-07(03)": [ + "MON-06.2" + ], + "AU-08": [ + "MON-07", + "SEA-20" + ], + "SC-45": [ + "MON-07.1" + ], + "SC-45(01)": [ + "MON-07.1" + ], + "AU-09": [ + "MON-08" + ], + "AU-04(01)": [ + "MON-08.1" + ], + "AU-09(02)": [ + "MON-08.1" + ], + "AU-09(04)": [ + "MON-08.2" + ], + "AU-09(03)": [ + "MON-08.3" + ], + "AU-09(05)": [ + "MON-08.4" + ], + "AU-10": [ + "MON-09" + ], + "AU-10(01)": [ + "MON-09.1" + ], + "AU-10(02)": [ + "MON-09.1" + ], + "AU-11": [ + "MON-10" + ], + "AU-13": [ + "MON-11" + ], + "SI-04(18)": [ + "MON-11.1", + "NET-17" + ], + "SI-04(22)": [ + "MON-11.2" + ], + "AU-14": [ + "MON-12" + ], + "AU-05(05)": [ + "MON-13" + ], + "AU-16": [ + "MON-14" + ], + "AU-16(01)": [ + "MON-14" + ], + "AU-16(02)": [ + "MON-14.1" + ], + "SC-31": [ + "MON-15" + ], + "AC-02(12)": [ + "MON-16" + ], + "IR-04(13)": [ + "MON-16", + "SEA-11", + "SEA-12" + ], + "SI-04(11)": [ + "MON-16" + ], + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" + ], + "SC-08(02)": [ + "CRY-01", + "CRY-01.3", + "DCH-10" + ], + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" + ], + "SI-07(06)": [ + "CRY-01" + ], + "SC-08(04)": [ + "CRY-01.4" + ], + "IA-07": [ + "CRY-02", + "IAC-12" + ], + "SC-08": [ + "CRY-03", + "CRY-04" + ], + "SC-16(01)": [ + "CRY-04", + "CRY-10" + ], + "SC-28": [ + "CRY-05", + "END-02" + ], + "AC-18": [ + "CRY-07", + "NET-15" + ], + "SC-40": [ + "CRY-07", + "NET-12.1" + ], + "SC-12": [ + "CRY-08" + ], + "SC-17": [ + "CRY-08" + ], + "SC-28(03)": [ + "CRY-09" + ], + "SC-12(02)": [ + "CRY-09.1" + ], + "SC-12(03)": [ + "CRY-09.2" + ], + "SC-12(01)": [ + "CRY-09.3" + ], + "SA-09(06)": [ + "CRY-09.7" + ], + "SC-16": [ + "CRY-10" + ], + "SC-23(05)": [ + "CRY-11" + ], + "MP-02": [ + "DCH-03", + "END-01" + ], + "AC-03(09)": [ + "DCH-03.3" + ], + "MP-03": [ + "DCH-04", + "DCH-04.1" + ], + "AC-16": [ + "DCH-05" + ], + "AC-16(01)": [ + "DCH-05.1" + ], + "AC-16(02)": [ + "DCH-05.2" + ], + "AC-16(03)": [ + "DCH-05.3" + ], + "AC-16(04)": [ + "DCH-05.4" + ], + "AC-16(05)": [ + "DCH-05.5" + ], + "AC-16(06)": [ + "DCH-05.6" + ], + "AC-16(07)": [ + "DCH-05.7" + ], + "AC-16(08)": [ + "DCH-05.8" + ], + "AC-16(09)": [ + "DCH-05.9" + ], + "AC-16(10)": [ + "DCH-05.10" + ], + "MP-04": [ + "DCH-06" + ], + "MP-05": [ + "DCH-07" + ], + "MP-05(03)": [ + "DCH-07.1" + ], + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" + ], + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" + ], + "MP-06(01)": [ + "DCH-09.1" + ], + "MP-06(02)": [ + "DCH-09.2" + ], + "MP-06(07)": [ + "DCH-09.5" + ], + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" + ], + "MP-08": [ + "DCH-11" + ], + "MP-08(03)": [ + "DCH-11" + ], + "AC-20": [ + "DCH-13" + ], + "AC-20(01)": [ + "DCH-13.1" + ], + "AC-20(02)": [ + "DCH-13.2" + ], + "AC-20(05)": [ + "DCH-13.2" + ], + "PM-17": [ + "DCH-13.3" + ], + "AC-20(03)": [ + "DCH-13.4" + ], + "AC-21": [ + "DCH-14", + "PRI-07" + ], + "AC-21(02)": [ + "DCH-14.1" + ], + "CA-03(06)": [ + "DCH-14.2" + ], + "AC-22": [ + "DCH-15" + ], + "AC-23": [ + "DCH-16", + "PRI-05.4" + ], + "SI-12": [ + "DCH-18", + "PRI-05" + ], + "SI-12(01)": [ + "DCH-18.1", + "PRI-05.1" + ], + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" + ], + "SA-08(33)": [ + "DCH-18.2", + "END-13.3", + "PES-06.5" + ], + "SA-15(12)": [ + "DCH-18.2" + ], + "SI-12(02)": [ + "DCH-18.2", + "PRI-05.1" + ], + "SI-12(03)": [ + "DCH-21", + "PRI-05" + ], + "PM-22": [ + "DCH-22", + "PRI-10" + ], + "SI-18": [ + "DCH-22" + ], + "SI-18(01)": [ + "DCH-22" + ], + "SI-18(04)": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" + ], + "SI-18(05)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-06.2" + ], + "PT-02(01)": [ + "DCH-22.2" + ], + "PT-03(01)": [ + "DCH-22.2", + "PRI-11" + ], + "SI-18(02)": [ + "DCH-22.2" + ], + "SI-18(03)": [ + "DCH-22.3" + ], + "SI-19(01)": [ + "DCH-22.3", + "DCH-23.1" + ], + "SI-19": [ + "DCH-23" + ], + "SI-19(02)": [ + "DCH-23.2" + ], + "SI-19(03)": [ + "DCH-23.3" + ], + "SI-19(04)": [ + "DCH-23.4", + "PRI-05.3" + ], + "SI-19(05)": [ + "DCH-23.5" + ], + "SI-19(06)": [ + "DCH-23.6" + ], + "SI-19(07)": [ + "DCH-23.7" + ], + "SI-19(08)": [ + "DCH-23.8" + ], + "CM-12": [ + "DCH-24" + ], + "CM-12(01)": [ + "DCH-24.1" + ], + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" + ], + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" + ], + "SI-03(06)": [ + "END-04.5" + ], + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" + ], + "SI-07(01)": [ + "END-06.1" + ], + "SI-07(07)": [ + "END-06.2" + ], + "SI-07(02)": [ + "END-06.3" + ], + "SI-07(05)": [ + "END-06.4" + ], + "SI-07(09)": [ + "END-06.5" + ], + "SI-07(10)": [ + "END-06.6" + ], + "CM-07(08)": [ + "END-06.7" + ], + "SI-08": [ + "END-08" + ], + "SI-08(02)": [ + "END-08.2" + ], + "SC-11": [ + "END-09" + ], + "SC-18": [ + "END-10" + ], + "SC-18(01)": [ + "END-10", + "VPM-02", + "VPM-04" + ], + "SC-18(03)": [ + "END-10", + "NET-18" + ], + "SC-27": [ + "END-10" + ], + "SC-25": [ + "END-11" + ], + "SC-41": [ + "END-12" + ], + "SC-42": [ + "END-13" + ], + "SC-42(02)": [ + "END-13.1" + ], + "SC-42(04)": [ + "END-13.2" + ], + "SC-42(05)": [ + "END-13.3" + ], + "SC-42(01)": [ + "END-13.4" + ], + "SC-15": [ + "END-14" + ], + "SC-15(01)": [ + "END-14" + ], + "SC-15(03)": [ + "END-14.1" + ], + "SC-15(04)": [ + "END-14.2" + ], + "SC-03": [ + "END-16", + "SEA-04.1" + ], + "SC-07(12)": [ + "END-16.1" + ], + "PS-02": [ + "HRS-02", + "HRS-03.2" + ], + "SI-04(21)": [ + "HRS-02.2" + ], + "PM-13": [ + "HRS-03", + "SAT-01" + ], + "PS-09": [ + "HRS-03" + ], + "PS-03": [ + "HRS-04" + ], + "PS-03(01)": [ + "HRS-04.1" + ], + "PS-03(03)": [ + "HRS-04.1" + ], + "PS-03(02)": [ + "HRS-04.2" + ], + "PS-03(04)": [ + "HRS-04.3" + ], + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" + ], + "PL-04(01)": [ + "HRS-05.2" + ], + "PS-06": [ + "HRS-06", + "HRS-06.1" + ], + "PS-06(02)": [ + "HRS-06", + "HRS-06.1" + ], + "PS-06(03)": [ + "HRS-06.2" + ], + "PS-08": [ + "HRS-07" + ], + "PS-05": [ + "HRS-08" + ], + "PS-04": [ + "HRS-09" + ], + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" + ], + "PS-04(01)": [ + "HRS-09.3" + ], + "PS-04(02)": [ + "HRS-09.4" + ], + "PS-07": [ + "HRS-10" + ], + "AC-03(02)": [ + "HRS-12.1", + "IAC-20.5" + ], + "IA-04": [ + "IAC-01.2", + "IAC-09" + ], + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" + ], + "IA-02": [ + "IAC-02" + ], + "IA-02(05)": [ + "IAC-02.1" + ], + "IA-02(08)": [ + "IAC-02.2" + ], + "IA-02(12)": [ + "IAC-02.3" + ], + "IA-08(05)": [ + "IAC-02.3" + ], + "IA-02(13)": [ + "IAC-02.4" + ], + "IA-08": [ + "IAC-03" + ], + "IA-08(01)": [ + "IAC-03.1" + ], + "IA-08(02)": [ + "IAC-03.2" + ], + "IA-08(04)": [ + "IAC-03.3" + ], + "IA-08(06)": [ + "IAC-03.4" + ], + "IA-03": [ + "IAC-04" + ], + "IA-03(01)": [ + "IAC-04" + ], + "IA-03(04)": [ + "IAC-04", + "IAC-04.1" + ], + "IA-09": [ + "IAC-05" + ], + "AC-06(06)": [ + "IAC-05.2" + ], + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "IA-02(06)": [ + "IAC-06.4" + ], + "IA-12(04)": [ + "IAC-07", + "IAC-10.3", + "IAC-28.4" + ], + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" + ], + "AC-02(07)": [ + "IAC-08" + ], + "IA-04(05)": [ + "IAC-09.3" + ], + "IA-05(10)": [ + "IAC-09.3" + ], + "IA-04(06)": [ + "IAC-09.4" + ], + "IA-05(08)": [ + "IAC-09.5", + "IAC-10.9" + ], + "IA-04(08)": [ + "IAC-09.6" + ], + "IA-05": [ + "IAC-10", + "IAC-10.8" + ], + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" + ], + "IA-05(02)": [ + "IAC-10.2" + ], + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" + ], + "IA-05(07)": [ + "IAC-10.6" + ], + "IA-05(05)": [ + "IAC-10.8" + ], + "IA-05(13)": [ + "IAC-10.10" + ], + "IA-05(18)": [ + "IAC-10.11" + ], + "IA-05(12)": [ + "IAC-10.12" + ], + "IA-06": [ + "IAC-11" + ], + "IA-10": [ + "IAC-13" + ], + "IA-02(10)": [ + "IAC-13.1" + ], + "IA-05(09)": [ + "IAC-13.2" + ], + "IA-11": [ + "IAC-14" + ], + "AC-02(01)": [ + "IAC-15.1" + ], + "AC-02(02)": [ + "IAC-15.2" + ], + "AC-02(03)": [ + "IAC-15.3" + ], + "AC-02(04)": [ + "IAC-15.4" + ], + "AC-02(09)": [ + "IAC-15.5" + ], + "AC-02(11)": [ + "IAC-15.8" + ], + "AC-06(07)": [ + "IAC-17" + ], + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" + ], + "AC-06": [ + "IAC-20", + "IAC-21" + ], + "AC-03(08)": [ + "IAC-20.6" + ], + "SA-08(14)": [ + "IAC-21" + ], + "AC-06(01)": [ + "IAC-21.1" + ], + "AC-06(02)": [ + "IAC-21.2" + ], + "AC-06(05)": [ + "IAC-21.3" + ], + "AC-06(09)": [ + "IAC-21.4" + ], + "AC-06(10)": [ + "IAC-21.5" + ], + "AC-06(03)": [ + "IAC-21.6" + ], + "AC-06(08)": [ + "IAC-21.7" + ], + "AC-07": [ + "IAC-22" + ], + "AC-10": [ + "IAC-23" + ], + "AC-02(05)": [ + "IAC-24" + ], + "AC-11": [ + "IAC-24" + ], + "AC-11(01)": [ + "IAC-24.1" + ], + "AC-12": [ + "IAC-25" + ], + "AC-12(01)": [ + "IAC-25.1" + ], + "AC-14": [ + "IAC-26" + ], + "AC-25": [ + "IAC-27" + ], + "IA-12": [ + "IAC-28" + ], + "AC-24": [ + "IAC-28.1" + ], + "IA-12(01)": [ + "IAC-28.1" + ], + "IA-12(02)": [ + "IAC-28.2" + ], + "IA-12(03)": [ + "IAC-28.3" + ], + "IA-12(05)": [ + "IAC-28.5" + ], + "IR-04": [ + "IRO-02" + ], + "IR-04(01)": [ + "IRO-02.1" + ], + "IR-04(06)": [ + "IRO-02.2" + ], + "IR-04(07)": [ + "IRO-02.2" + ], + "IR-04(02)": [ + "IRO-02.3" + ], + "IR-04(08)": [ + "IRO-02.5" + ], + "IR-08": [ + "IRO-04" + ], + "IR-08(01)": [ + "IRO-04.1" + ], + "IR-03(03)": [ + "IRO-04.3" + ], + "IR-02": [ + "IRO-05" + ], + "IR-02(03)": [ + "IRO-05" + ], + "IR-02(01)": [ + "IRO-05.1" + ], + "IR-02(02)": [ + "IRO-05.2" + ], + "IR-03": [ + "IRO-06" + ], + "SI-04(09)": [ + "IRO-06" + ], + "IR-03(02)": [ + "IRO-06.1" + ], + "IR-04(11)": [ + "IRO-07" + ], + "AU-10(03)": [ + "IRO-08" + ], + "IR-04(12)": [ + "IRO-08", + "IRO-13" + ], + "IR-05": [ + "IRO-09" + ], + "IR-05(01)": [ + "IRO-09.1" + ], + "IR-06(01)": [ + "IRO-10.1" + ], + "IR-06(02)": [ + "IRO-10.3", + "IRO-13" + ], + "IR-04(10)": [ + "IRO-10.4", + "TPM-11" + ], + "IR-06(03)": [ + "IRO-10.4" + ], + "IR-07": [ + "IRO-11" + ], + "IR-07(01)": [ + "IRO-11.1" + ], + "IR-07(02)": [ + "IRO-11.2" + ], + "IR-09": [ + "IRO-12", + "IRO-12.1" + ], + "IR-09(02)": [ + "IRO-12.2" + ], + "IR-09(03)": [ + "IRO-12.3" + ], + "IR-09(04)": [ + "IRO-12.4" + ], + "SC-44": [ + "IRO-15" + ], + "IR-04(15)": [ + "IRO-16" + ], + "PM-10": [ + "IAO-01" + ], + "CA-02(01)": [ + "IAO-02.1" + ], + "CA-02(02)": [ + "IAO-02.2" + ], + "SA-11(05)": [ + "IAO-02.2", + "IAO-04", + "TDA-09", + "TDA-09.5", + "VPM-07" + ], + "CA-02(03)": [ + "IAO-02.3" + ], + "CA-05": [ + "IAO-05" + ], + "PM-04": [ + "IAO-05", + "VPM-02" + ], + "SA-15(02)": [ + "IAO-05" + ], + "CA-05(01)": [ + "IAO-05.1" + ], + "CM-04(02)": [ + "IAO-06" + ], + "CA-06": [ + "IAO-07" + ], + "MA-02": [ + "MNT-02" + ], + "MA-02(02)": [ + "MNT-02.1" + ], + "MA-06": [ + "MNT-03" + ], + "MA-06(01)": [ + "MNT-03.1" + ], + "MA-06(02)": [ + "MNT-03.2" + ], + "MA-06(03)": [ + "MNT-03.3" + ], + "MA-03": [ + "MNT-04" + ], + "MA-03(05)": [ + "MNT-04" + ], + "MA-03(06)": [ + "MNT-04" + ], + "MA-03(01)": [ + "MNT-04.1" + ], + "MA-03(02)": [ + "MNT-04.2" + ], + "MA-03(03)": [ + "MNT-04.3" + ], + "MA-03(04)": [ + "MNT-04.4" + ], + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" + ], + "MA-04(01)": [ + "MNT-05.1" + ], + "MA-04(06)": [ + "MNT-05.3" + ], + "MA-04(07)": [ + "MNT-05.4" + ], + "MA-04(05)": [ + "MNT-05.5" + ], + "MA-04(03)": [ + "MNT-05.6" + ], + "MA-04(04)": [ + "MNT-05.7" + ], + "MA-05": [ + "MNT-06" + ], + "MA-05(01)": [ + "MNT-06.1" + ], + "MA-05(02)": [ + "MNT-06.1" + ], + "MA-05(03)": [ + "MNT-06.1" + ], + "MA-05(04)": [ + "MNT-06.1" + ], + "MA-05(05)": [ + "MNT-06.2" + ], + "SR-11(02)": [ + "MNT-07" + ], + "MA-07": [ + "MNT-08" + ], + "AC-19": [ + "MDM-02" + ], + "AC-19(05)": [ + "MDM-03" + ], + "PE-03(05)": [ + "MDM-04" + ], + "AC-07(02)": [ + "MDM-05" + ], + "MP-06(08)": [ + "MDM-05" + ], + "SC-46": [ + "NET-02.3" + ], + "SC-07": [ + "NET-03" + ], + "SC-07(09)": [ + "NET-03", + "NET-03.2" + ], + "SC-07(11)": [ + "NET-03", + "NET-04.1" + ], + "SC-07(03)": [ + "NET-03.1" + ], + "SC-07(04)": [ + "NET-03.2" + ], + "SC-07(16)": [ + "NET-03.3" + ], + "SC-07(24)": [ + "NET-03.4" + ], + "SC-07(10)": [ + "NET-03.5", + "NET-17" + ], + "SC-07(20)": [ + "NET-03.6" + ], + "SC-07(21)": [ + "NET-03.7" + ], + "SC-07(22)": [ + "NET-03.8" + ], + "AC-04": [ + "NET-04" + ], + "SC-07(05)": [ + "NET-04.1" + ], + "AC-04(01)": [ + "NET-04.2" + ], + "AC-04(04)": [ + "NET-04.3" + ], + "AC-04(05)": [ + "NET-04.4" + ], + "AC-04(06)": [ + "NET-04.5" + ], + "AC-04(09)": [ + "NET-04.6" + ], + "AC-04(08)": [ + "NET-04.7" + ], + "AC-04(12)": [ + "NET-04.8" + ], + "AC-04(13)": [ + "NET-04.9" + ], + "AC-04(15)": [ + "NET-04.10" + ], + "AC-04(20)": [ + "NET-04.11" + ], + "AC-04(17)": [ + "NET-04.12" + ], + "AC-04(19)": [ + "NET-04.13" + ], + "CA-03": [ + "NET-05" + ], + "SC-07(25)": [ + "NET-05" + ], + "SC-07(26)": [ + "NET-05" + ], + "SC-07(27)": [ + "NET-05.1" + ], + "CA-09": [ + "NET-05.2" + ], + "AC-04(21)": [ + "NET-06" + ], + "SC-07(13)": [ + "NET-06.1" + ], + "SC-07(28)": [ + "NET-06.5" + ], + "SC-10": [ + "NET-07" + ], + "SI-04(15)": [ + "NET-08.2" + ], + "SC-23": [ + "NET-09" + ], + "SC-23(01)": [ + "NET-09.1" + ], + "SC-23(03)": [ + "NET-09.2" + ], + "SC-20": [ + "NET-10" + ], + "SC-20(02)": [ + "NET-10" + ], + "SC-22": [ + "NET-10.1" + ], + "SC-21": [ + "NET-10.2" + ], + "SC-37": [ + "NET-11" + ], + "SC-37(01)": [ + "NET-11" + ], + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" + ], + "SI-10": [ + "NET-12", + "TDA-18" + ], + "SC-08(03)": [ + "NET-13" + ], + "AC-17": [ + "NET-14" + ], + "AC-17(06)": [ + "NET-14" + ], + "AC-17(01)": [ + "NET-14.1" + ], + "AC-17(02)": [ + "NET-14.2" + ], + "AC-17(03)": [ + "NET-14.3" + ], + "AC-17(04)": [ + "NET-14.4" + ], + "CA-09(01)": [ + "NET-14.7" + ], + "AC-17(09)": [ + "NET-14.8" + ], + "AC-18(01)": [ + "NET-15.1" + ], + "AC-18(03)": [ + "NET-15.2" + ], + "AC-18(04)": [ + "NET-15.3" + ], + "AC-18(05)": [ + "NET-15.4" + ], + "SC-07(08)": [ + "NET-18", + "NET-18.1" + ], + "SI-04(10)": [ + "NET-18.2" + ], + "SC-07(15)": [ + "NET-18.3" + ], + "PE-02": [ + "PES-02" + ], + "PE-02(01)": [ + "PES-02.1" + ], + "PE-03": [ + "PES-03" + ], + "PE-03(02)": [ + "PES-03" + ], + "PE-03(03)": [ + "PES-03" + ], + "PE-03(04)": [ + "PES-03.2" + ], + "SC-07(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" + ], + "PE-08": [ + "PES-03.3" + ], + "PE-03(01)": [ + "PES-03.4" + ], + "PE-06": [ + "PES-05" + ], + "PE-06(01)": [ + "PES-05.1" + ], + "PE-06(04)": [ + "PES-05.2" + ], + "PE-02(02)": [ + "PES-06.2" + ], + "PE-02(03)": [ + "PES-06.3" + ], + "PE-08(01)": [ + "PES-06.4" + ], + "PE-08(03)": [ + "PES-06.5" + ], + "PE-09": [ + "PES-07" + ], + "PE-09(02)": [ + "PES-07.1" + ], + "PE-10": [ + "PES-07.2" + ], + "PE-11": [ + "PES-07.3" + ], + "PE-11(01)": [ + "PES-07.3" + ], + "PE-11(02)": [ + "PES-07.3" + ], + "PE-12": [ + "PES-07.4" + ], + "PE-15": [ + "PES-07.5" + ], + "PE-15(01)": [ + "PES-07.6" + ], + "PE-09(01)": [ + "PES-07.7" + ], + "PE-13": [ + "PES-08" + ], + "PE-13(01)": [ + "PES-08.1" + ], + "PE-13(02)": [ + "PES-08.2", + "PES-08.3" + ], + "PE-14": [ + "PES-09" + ], + "PE-14(02)": [ + "PES-09.1" + ], + "PE-16": [ + "PES-10" + ], + "PE-17": [ + "PES-11" + ], + "PE-18": [ + "PES-12" + ], + "PE-04": [ + "PES-12.1" + ], + "PE-05": [ + "PES-12.2" + ], + "PE-19": [ + "PES-13" + ], + "PE-20": [ + "PES-14" + ], + "PE-21": [ + "PES-15" + ], + "PM-18": [ + "PRI-01" + ], + "PM-19": [ + "PRI-01.1" + ], + "PT-05(02)": [ + "PRI-01.2" + ], + "PM-20": [ + "PRI-01.3" + ], + "PM-20(01)": [ + "PRI-02" + ], + "PT-05": [ + "PRI-02" + ], + "PT-03": [ + "PRI-02.1", + "PRI-05.1" + ], + "PT-02(02)": [ + "PRI-02.2" + ], + "PT-03(02)": [ + "PRI-02.2", + "PRI-10.1" + ], + "PT-08": [ + "PRI-02.3" + ], + "PT-06": [ + "PRI-02.4" + ], + "PT-06(01)": [ + "PRI-02.5" + ], + "PT-06(02)": [ + "PRI-02.6" + ], + "PT-04": [ + "PRI-03" + ], + "PT-04(01)": [ + "PRI-03.1" + ], + "PT-04(02)": [ + "PRI-03.2" + ], + "PT-05(01)": [ + "PRI-03.2" + ], + "PT-04(03)": [ + "PRI-03.4" + ], + "PT-02": [ + "PRI-04", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" + ], + "AC-04(25)": [ + "PRI-05" + ], + "PT-07": [ + "PRI-05.4", + "PRI-05.7" + ], + "PM-05(01)": [ + "PRI-05.5", + "PRI-05.6" + ], + "PT-07(01)": [ + "PRI-05.7" + ], + "PT-07(02)": [ + "PRI-05.7" + ], + "AC-03(14)": [ + "PRI-06" + ], + "PM-26": [ + "PRI-06.3", + "PRI-06.4" + ], + "PM-27": [ + "PRI-14" + ], + "PM-21": [ + "PRI-14.1" + ], + "PM-03": [ + "PRM-02" + ], + "SA-02": [ + "PRM-03" + ], + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" + ], + "PM-11": [ + "PRM-06" + ], + "SA-03": [ + "PRM-07", + "SEA-07.1" + ], + "SA-03(01)": [ + "PRM-07", + "SEA-07.1", + "TDA-07" + ], + "SA-08(30)": [ + "PRM-07", + "SEA-07.1" + ], + "PM-09": [ + "RSK-01" + ], + "PM-28": [ + "RSK-01.1" + ], + "RA-02": [ + "RSK-02" + ], + "RA-02(01)": [ + "RSK-02.1" + ], + "RA-07": [ + "RSK-06.1" + ], + "PM-30": [ + "RSK-09" + ], + "SA-09(03)": [ + "RSK-09", + "TPM-02", + "TPM-03", + "TPM-04.3", + "TPM-05.4", + "TPM-05.7" + ], + "SR-02": [ + "RSK-09", + "TPM-03" + ], + "SR-07": [ + "RSK-09", + "OPS-01" + ], + "RA-03(01)": [ + "RSK-09.1" + ], + "RA-08": [ + "RSK-10" + ], + "CA-07(04)": [ + "RSK-11" + ], + "SC-07(18)": [ + "SEA-01" + ], + "PL-08": [ + "SEA-02" + ], + "PM-07": [ + "SEA-02" + ], + "PM-07(01)": [ + "SEA-02.2" + ], + "PL-08(01)": [ + "SEA-03" + ], + "SC-03(05)": [ + "SEA-03" + ], + "SC-32": [ + "SEA-03.1" + ], + "SC-02": [ + "SEA-03.2" + ], + "SC-02(01)": [ + "SEA-03.2" + ], + "SC-39": [ + "SEA-04" + ], + "SC-39(01)": [ + "SEA-04.2" + ], + "SC-39(02)": [ + "SEA-04.3" + ], + "SC-04": [ + "SEA-05" + ], + "SA-03(03)": [ + "SEA-07.1", + "SEA-08.1" + ], + "CP-12": [ + "SEA-07.2" + ], + "SA-08(24)": [ + "SEA-07.2" + ], + "SC-24": [ + "SEA-07.2" + ], + "SI-17": [ + "SEA-07.3" + ], + "SI-14": [ + "SEA-08" + ], + "SI-14(01)": [ + "SEA-08.1" + ], + "SI-15": [ + "SEA-09" + ], + "SI-16": [ + "SEA-10" + ], + "SC-26": [ + "SEA-11" + ], + "SC-35": [ + "SEA-12" + ], + "SC-29": [ + "SEA-13" + ], + "SC-29(01)": [ + "SEA-13.1" + ], + "SC-30": [ + "SEA-14" + ], + "SC-30(04)": [ + "SEA-14" + ], + "SC-30(05)": [ + "SEA-14" + ], + "SC-30(02)": [ + "SEA-14.1" + ], + "SC-30(03)": [ + "SEA-14.2" + ], + "SC-36": [ + "SEA-15" + ], + "SC-34": [ + "SEA-16" + ], + "AC-08": [ + "SEA-18" + ], + "AC-09": [ + "SEA-19" + ], + "SC-38": [ + "OPS-01", + "OPS-04" + ], + "SA-08(32)": [ + "OPS-01.1" + ], + "PL-07": [ + "OPS-02" + ], + "IR-04(14)": [ + "OPS-04" + ], + "AT-02": [ + "SAT-02" + ], + "AT-02(01)": [ + "SAT-02.1" + ], + "AT-06": [ + "SAT-02.1" + ], + "AT-02(03)": [ + "SAT-02.2" + ], + "AT-03": [ + "SAT-03" + ], + "AT-03(02)": [ + "SAT-03" + ], + "AT-03(03)": [ + "SAT-03.1" + ], + "AT-02(04)": [ + "SAT-03.2" + ], + "AT-02(05)": [ + "SAT-03.2" + ], + "AT-03(05)": [ + "SAT-03.3" + ], + "AT-02(06)": [ + "SAT-03.6" + ], + "AT-04": [ + "SAT-04" + ], + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" + ], + "SA-23": [ + "TDA-01", + "TDA-01.1", + "TDA-12" + ], + "SA-04(09)": [ + "TDA-02.1" + ], + "SA-04(07)": [ + "TDA-02.2" + ], + "SA-04(10)": [ + "TDA-02.2" + ], + "SA-04(03)": [ + "TDA-02.3", + "TDA-06" + ], + "SR-03(01)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" + ], + "SA-04(05)": [ + "TDA-02.4" + ], + "SA-10(07)": [ + "TDA-02.7" + ], + "SA-15(13)": [ + "TDA-02.14" + ], + "SA-04(06)": [ + "TDA-03" + ], + "PL-08(02)": [ + "TDA-03.1" + ], + "SA-17": [ + "TDA-05" + ], + "SA-15": [ + "TDA-06" + ], + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" + ], + "SA-15(03)": [ + "TDA-06.1" + ], + "SA-11(02)": [ + "TDA-06.2", + "TDA-15" + ], + "SA-15(08)": [ + "TDA-06.2" + ], + "SI-02(07)": [ + "TDA-06.6" + ], + "CM-04(01)": [ + "TDA-08" + ], + "SA-11": [ + "TDA-09" + ], + "SA-11(06)": [ + "TDA-09", + "VPM-01.1" + ], + "SA-11(07)": [ + "TDA-09", + "VPM-01.1" + ], + "SA-04(08)": [ + "TDA-09.1" + ], + "SA-11(01)": [ + "TDA-09.2" + ], + "SA-11(08)": [ + "TDA-09.3" + ], + "SA-11(04)": [ + "TDA-09.7" + ], + "SA-03(02)": [ + "TDA-10" + ], + "SR-04(03)": [ + "TDA-11" + ], + "SR-04(04)": [ + "TDA-11" + ], + "SR-11": [ + "TDA-11" + ], + "SR-11(03)": [ + "TDA-11" + ], + "SR-11(01)": [ + "TDA-11.1" + ], + "SA-20": [ + "TDA-12" + ], + "SA-21": [ + "TDA-13" + ], + "SA-10": [ + "TDA-14" + ], + "SA-10(01)": [ + "TDA-14.1" + ], + "SA-10(03)": [ + "TDA-14.2" + ], + "SA-16": [ + "TDA-16" + ], + "SA-22": [ + "TDA-17", + "TDA-17.1" + ], + "SI-11": [ + "TDA-19" + ], + "SR-02(01)": [ + "TPM-03" + ], + "SR-05": [ + "TPM-03.1" + ], + "SR-03(02)": [ + "TPM-03.2" + ], + "SR-03": [ + "TPM-03.3" + ], + "SR-05(01)": [ + "TPM-03.4" + ], + "SA-09": [ + "TPM-04" + ], + "SA-09(01)": [ + "TPM-04.1" + ], + "SA-09(02)": [ + "TPM-04.2" + ], + "SA-09(04)": [ + "TPM-04.3" + ], + "SR-03(03)": [ + "TPM-05", + "TPM-05.2" + ], + "SR-08": [ + "TPM-05.1" + ], + "SR-06": [ + "TPM-08" + ], + "SR-06(01)": [ + "TPM-08" + ], + "PM-16": [ + "THR-01" + ], + "PM-16(01)": [ + "THR-03" + ], + "SI-05(01)": [ + "THR-03" + ], + "PM-12": [ + "THR-04" + ], + "AT-02(02)": [ + "THR-05" + ], + "RA-05(11)": [ + "THR-06" + ], + "RA-10": [ + "THR-07" + ], + "SI-20": [ + "THR-08" + ], + "SI-02(04)": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" + ], + "SI-02(02)": [ + "VPM-05.2" + ], + "SI-02(03)": [ + "VPM-05.3" + ], + "SI-02(05)": [ + "VPM-05.4" + ], + "SI-02(06)": [ + "VPM-05.5" + ], + "RA-05": [ + "VPM-06", + "VPM-06.1" + ], + "RA-05(02)": [ + "VPM-06.1" + ], + "RA-05(03)": [ + "VPM-06.2" + ], + "RA-05(05)": [ + "VPM-06.3" + ], + "RA-05(06)": [ + "VPM-06.4" + ], + "RA-05(08)": [ + "VPM-06.5" + ], + "RA-05(04)": [ + "VPM-06.8" + ], + "RA-05(10)": [ + "VPM-06.9" + ], + "CA-08": [ + "VPM-07" + ], + "CA-08(01)": [ + "VPM-07.1" + ], + "RA-06": [ + "VPM-08" + ], + "CA-08(02)": [ + "VPM-10" + ], + "SC-07(17)": [ + "WEB-03" + ] + }, + "general-nist-800-82-r3-low": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" + ], + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "AT-01": [ + "GOV-02" + ], + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" + ], + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" + ], + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" + ], + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" + ], + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" + ], + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" + ], + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" + ], + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" + ], + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "TDA-01" + ], + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" + ], + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" + ], + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" + ], + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" + ], + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" + ], + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" + ], + "PM-02": [ + "GOV-04" + ], + "PM-06": [ + "GOV-04", + "GOV-05" + ], + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" + ], + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" + ], + "PM-15": [ + "GOV-07", + "THR-01" + ], + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" + ], + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" + ], + "PM-32": [ + "GOV-11" + ], + "PM-05": [ + "AST-01", + "AST-02" + ], + "CM-08": [ + "AST-02", + "AST-02.3" + ], + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" + ], + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" + ], + "SA-05": [ + "AST-04.1", + "TDA-04" + ], + "SR-12": [ + "AST-09" + ], + "SR-10": [ + "AST-15.1", + "TDA-11" + ], + "CP-02": [ + "BCD-01", + "BCD-06" + ], + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" + ], + "PM-08": [ + "BCD-01", + "CPL-01" + ], + "CP-03": [ + "BCD-03" + ], + "CP-04": [ + "BCD-04", + "BCD-05" + ], + "CP-09": [ + "BCD-11" + ], + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "CM-04": [ + "CHG-03" + ], + "CM-05": [ + "CHG-04", + "END-03.2" + ], + "SC-07(29)": [ + "CLD-03" + ], + "CA-07": [ + "CPL-02" + ], + "PM-14": [ + "CPL-02", + "PRI-08" + ], + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" + ], + "RA-03": [ + "CPL-03.2", + "RSK-04" + ], + "CM-02": [ + "CFG-02", + "CFG-02.1" + ], + "CM-06": [ + "CFG-02", + "CFG-02.7" + ], + "PL-10": [ + "CFG-02" + ], + "SA-08": [ + "CFG-02", + "SEA-01" + ], + "PL-11": [ + "CFG-02.9" + ], + "CM-07": [ + "CFG-03" + ], + "CM-10": [ + "CFG-04" + ], + "CM-11": [ + "CFG-05" + ], + "PM-31": [ + "MON-01" + ], + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" + ], + "AU-02": [ + "MON-01.8", + "MON-02" + ], + "AU-06": [ + "MON-02", + "MON-02.6" + ], + "AU-03": [ + "MON-03" + ], + "AU-04": [ + "MON-04" + ], + "AU-05": [ + "MON-05" + ], + "AU-12": [ + "MON-06" + ], + "AU-08": [ + "MON-07", + "SEA-20" + ], + "SC-45": [ + "MON-07.1" + ], + "AU-09": [ + "MON-08" + ], + "AU-04(01)": [ + "MON-08.1" + ], + "AU-11": [ + "MON-10" + ], + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" + ], + "IA-07": [ + "CRY-02", + "IAC-12" + ], + "AC-18": [ + "CRY-07", + "NET-15" + ], + "SC-12": [ + "CRY-08" + ], + "MP-02": [ + "DCH-03", + "END-01" + ], + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" + ], + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" + ], + "AC-20": [ + "DCH-13" + ], + "PM-17": [ + "DCH-13.3" + ], + "AC-22": [ + "DCH-15" + ], + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" + ], + "PM-22": [ + "DCH-22", + "PRI-10" + ], + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" + ], + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" + ], + "SC-41": [ + "END-12" + ], + "SC-15": [ + "END-14" + ], + "PS-02": [ + "HRS-02", + "HRS-03.2" + ], + "PM-13": [ + "HRS-03", + "SAT-01" + ], + "PS-09": [ + "HRS-03" + ], + "PS-03": [ + "HRS-04" + ], + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" + ], + "PL-04(01)": [ + "HRS-05.2" + ], + "PS-06": [ + "HRS-06", + "HRS-06.1" + ], + "PS-08": [ + "HRS-07" + ], + "PS-05": [ + "HRS-08" + ], + "PS-04": [ + "HRS-09" + ], + "PS-07": [ + "HRS-10" + ], + "IA-04": [ + "IAC-01.2", + "IAC-09" + ], + "IA-02": [ + "IAC-02" + ], + "IA-02(08)": [ + "IAC-02.2" + ], + "IA-02(12)": [ + "IAC-02.3" + ], + "IA-08": [ + "IAC-03" + ], + "IA-08(01)": [ + "IAC-03.1" + ], + "IA-08(02)": [ + "IAC-03.2" + ], + "IA-08(04)": [ + "IAC-03.3" + ], + "IA-03": [ + "IAC-04" + ], + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" + ], + "IA-05": [ + "IAC-10", + "IAC-10.8" + ], + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" + ], + "IA-06": [ + "IAC-11" + ], + "IA-11": [ + "IAC-14" + ], + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" + ], + "AC-07": [ + "IAC-22" + ], + "AC-14": [ + "IAC-26" + ], + "IR-04": [ + "IRO-02" + ], + "IR-08": [ + "IRO-04" + ], + "IR-02": [ + "IRO-05" + ], + "IR-05": [ + "IRO-09" + ], + "IR-07": [ + "IRO-11" + ], + "PM-10": [ + "IAO-01" + ], + "CA-05": [ + "IAO-05" + ], + "PM-04": [ + "IAO-05", + "VPM-02" + ], + "CA-06": [ + "IAO-07" + ], + "MA-02": [ + "MNT-02" + ], + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" + ], + "MA-05": [ + "MNT-06" + ], + "SR-11(02)": [ + "MNT-07" + ], + "MA-07": [ + "MNT-08" + ], + "AC-19": [ + "MDM-02" + ], + "SC-07": [ + "NET-03" + ], + "CA-03": [ + "NET-05" + ], + "CA-09": [ + "NET-05.2" + ], + "SC-07(28)": [ + "NET-06.5" + ], + "SC-20": [ + "NET-10" + ], + "SC-22": [ + "NET-10.1" + ], + "SC-21": [ + "NET-10.2" + ], + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" + ], + "AC-17": [ + "NET-14" + ], + "AC-17(09)": [ + "NET-14.8" + ], + "PE-02": [ + "PES-02" + ], + "PE-03": [ + "PES-03" + ], + "PE-08": [ + "PES-03.3" + ], + "PE-06": [ + "PES-05" + ], + "PE-12": [ + "PES-07.4" + ], + "PE-15": [ + "PES-07.5" + ], + "PE-13": [ + "PES-08" + ], + "PE-14": [ + "PES-09" + ], + "PE-16": [ + "PES-10" + ], + "PM-18": [ + "PRI-01" + ], + "PM-19": [ + "PRI-01.1" + ], + "PM-20": [ + "PRI-01.3" + ], + "PM-20(01)": [ + "PRI-02" + ], + "SI-12": [ + "PRI-05" + ], + "PM-26": [ + "PRI-06.3", + "PRI-06.4" + ], + "PM-27": [ + "PRI-14" + ], + "PM-21": [ + "PRI-14.1" + ], + "PM-03": [ + "PRM-02" + ], + "SA-02": [ + "PRM-03" + ], + "PM-11": [ + "PRM-06" + ], + "SA-03": [ + "PRM-07", + "SEA-07.1" + ], + "PM-09": [ + "RSK-01" + ], + "PM-28": [ + "RSK-01.1" + ], + "RA-02": [ + "RSK-02" + ], + "RA-07": [ + "RSK-06.1" + ], + "PM-30": [ + "RSK-09" + ], + "SR-02": [ + "RSK-09", + "TPM-03" + ], + "RA-03(01)": [ + "RSK-09.1" + ], + "CA-07(04)": [ + "RSK-11" + ], + "PM-07": [ + "SEA-02" + ], + "SC-39": [ + "SEA-04" + ], + "CP-12": [ + "SEA-07.2" + ], + "SI-17": [ + "SEA-07.3" + ], + "AC-08": [ + "SEA-18" + ], + "AT-02": [ + "SAT-02" + ], + "AT-03": [ + "SAT-03" + ], + "AT-04": [ + "SAT-04" + ], + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" + ], + "SA-04(10)": [ + "TDA-02.2" + ], + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" + ], + "SR-11": [ + "TDA-11" + ], + "SR-11(01)": [ + "TDA-11.1" + ], + "SA-22": [ + "TDA-17", + "TDA-17.1" + ], + "SR-02(01)": [ + "TPM-03" + ], + "SR-05": [ + "TPM-03.1" + ], + "SR-03": [ + "TPM-03.3" + ], + "SA-09": [ + "TPM-04" + ], + "SR-08": [ + "TPM-05.1" + ], + "PM-16": [ + "THR-01" + ], + "PM-12": [ + "THR-04" + ], + "AT-02(02)": [ + "THR-05" + ], + "RA-05(11)": [ + "THR-06" + ], + "RA-05": [ + "VPM-06", + "VPM-06.1" + ], + "RA-05(02)": [ + "VPM-06.1" + ] + }, + "general-nist-800-82-r3-mod": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" + ], + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "AT-01": [ + "GOV-02" + ], + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" + ], + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" + ], + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" + ], + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" + ], + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" + ], + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" + ], + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" + ], + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" + ], + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" + ], + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "TDA-01" + ], + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" + ], + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" + ], + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" + ], + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" + ], + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" + ], + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" + ], + "PM-02": [ + "GOV-04" + ], + "PM-06": [ + "GOV-04", + "GOV-05" + ], + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" + ], + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" + ], + "PM-15": [ + "GOV-07", + "THR-01" + ], + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" + ], + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" + ], + "PM-32": [ + "GOV-11" + ], + "PM-05": [ + "AST-01", + "AST-02" + ], + "CM-08": [ + "AST-02", + "AST-02.3" + ], + "CM-08(01)": [ + "AST-02.1" + ], + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" + ], + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" + ], + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" + ], + "SA-04(01)": [ + "AST-04", + "TDA-04.1" + ], + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" + ], + "PE-22": [ + "AST-04.1", + "PES-16" + ], + "SA-05": [ + "AST-04.1", + "TDA-04" + ], + "SR-12": [ + "AST-09" + ], + "SR-10": [ + "AST-15.1", + "TDA-11" + ], + "CP-02": [ + "BCD-01", + "BCD-06" + ], + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" + ], + "PM-08": [ + "BCD-01", + "CPL-01" + ], + "CP-02(01)": [ + "BCD-01.1" + ], + "CP-02(08)": [ + "BCD-02" + ], + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" + ], + "CP-03": [ + "BCD-03" + ], + "CP-04": [ + "BCD-04", + "BCD-05" + ], + "CP-04(01)": [ + "BCD-04.1" + ], + "CP-06": [ + "BCD-08" + ], + "CP-06(01)": [ + "BCD-08.1" + ], + "CP-06(03)": [ + "BCD-08.2" + ], + "CP-07": [ + "BCD-09" + ], + "CP-07(01)": [ + "BCD-09.1" + ], + "CP-07(02)": [ + "BCD-09.2" + ], + "CP-07(03)": [ + "BCD-09.3" + ], + "CP-08": [ + "BCD-10" + ], + "CP-08(02)": [ + "BCD-10" + ], + "CP-08(01)": [ + "BCD-10.1" + ], + "CP-09": [ + "BCD-11" + ], + "CP-09(01)": [ + "BCD-11.1" + ], + "CP-09(08)": [ + "BCD-11.4" + ], + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" + ], + "CP-10(02)": [ + "BCD-12.1" + ], + "CP-10(06)": [ + "BCD-13" + ], + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "CM-03": [ + "CHG-01", + "CHG-02" + ], + "CM-03(04)": [ + "CHG-02.3" + ], + "CM-04": [ + "CHG-03" + ], + "CM-05": [ + "CHG-04", + "END-03.2" + ], + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" + ], + "CM-09": [ + "CHG-05", + "CFG-01" + ], + "CM-03(02)": [ + "CHG-06" + ], + "SC-07(29)": [ + "CLD-03" + ], + "CA-07": [ + "CPL-02" + ], + "PM-14": [ + "CPL-02", + "PRI-08" + ], + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" + ], + "CA-07(01)": [ + "CPL-03.1" + ], + "RA-03": [ + "CPL-03.2", + "RSK-04" + ], + "CM-02": [ + "CFG-02", + "CFG-02.1" + ], + "CM-06": [ + "CFG-02", + "CFG-02.7" + ], + "PL-10": [ + "CFG-02" + ], + "SA-08": [ + "CFG-02", + "SEA-01" + ], + "CM-02(02)": [ + "CFG-02.2" + ], + "CM-02(03)": [ + "CFG-02.3" + ], + "CM-02(07)": [ + "CFG-02.5" + ], + "PL-11": [ + "CFG-02.9" + ], + "CM-07": [ + "CFG-03" + ], + "CM-07(01)": [ + "CFG-03.1" + ], + "CM-07(05)": [ + "CFG-03.3" + ], + "SC-07(07)": [ + "CFG-03.4" + ], + "CM-10": [ + "CFG-04" + ], + "CM-11": [ + "CFG-05" + ], + "PM-31": [ + "MON-01" + ], + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" + ], + "SI-04(02)": [ + "MON-01.2" + ], + "SI-04(04)": [ + "MON-01.3" + ], + "SI-04(05)": [ + "MON-01.4" + ], + "AU-02": [ + "MON-01.8", + "MON-02" + ], + "AU-06": [ + "MON-02", + "MON-02.6" + ], + "AU-06(03)": [ + "MON-02.1" + ], + "AU-03": [ + "MON-03" + ], + "AU-03(01)": [ + "MON-03.1" + ], + "AU-06(01)": [ + "MON-03.1" + ], + "AU-04": [ + "MON-04" + ], + "AU-05": [ + "MON-05" + ], + "AU-07": [ + "MON-06" + ], + "AU-07(01)": [ + "MON-06" + ], + "AU-12": [ + "MON-06" + ], + "AU-08": [ + "MON-07", + "SEA-20" + ], + "SC-45": [ + "MON-07.1" + ], + "AU-09": [ + "MON-08" + ], + "AU-04(01)": [ + "MON-08.1" + ], + "AU-09(04)": [ + "MON-08.2" + ], + "AU-11": [ + "MON-10" + ], + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" + ], + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" ], - "T1562": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", + "IA-07": [ + "CRY-02", + "IAC-12" + ], + "SC-08": [ "CRY-03", - "CRY-04", - "END-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-15", - "IAC-20", - "IAC-21", - "VPM-06" + "CRY-04" ], - "T1562.001": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "SC-28": [ + "CRY-05", + "END-02" ], - "T1562.002": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "AC-18": [ + "CRY-07", + "NET-15" ], - "T1562.004": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "SC-12": [ + "CRY-08" ], - "T1562.006": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "CFG-04", - "MON-01", - "CRY-03", - "CRY-04", - "END-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-05", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-09" + "SC-17": [ + "CRY-08" ], - "T1562.007": [ - "CHG-04", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "MP-02": [ + "DCH-03", + "END-01" ], - "T1562.009": [ - "CHG-04", - "CFG-02", - "CFG-03", - "CFG-04", - "CRY-03", - "CRY-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-05", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-09" + "MP-03": [ + "DCH-04", + "DCH-04.1" ], - "T1562.011": [ - "CHG-04", - "CFG-02", - "MON-01", - "END-04", - "END-06" + "MP-04": [ + "DCH-06" ], - "T1569": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "CFG-05", - "MON-01", - "END-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "MP-05": [ + "DCH-07" ], - "T1569.001": [ - "CHG-04", - "CFG-05", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "T1569.002": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "T1574.005": [ - "CHG-04", - "CFG-02", - "MON-01", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-04", - "VPM-06" + "AC-20": [ + "DCH-13" ], - "T1574.010": [ - "CHG-04", - "CFG-02", - "MON-01", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-04", - "VPM-06" + "AC-20(01)": [ + "DCH-13.1" ], - "T1574.011": [ - "CHG-04", - "IAC-21" + "AC-20(02)": [ + "DCH-13.2" ], - "T1574.012": [ - "CHG-04", - "CFG-03", - "END-06", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21", - "TDA-18" + "PM-17": [ + "DCH-13.3" ], - "T1574.014": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", + "AC-22": [ + "DCH-15" + ], + "SI-12": [ + "DCH-18", + "PRI-05" + ], + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" + ], + "PM-22": [ + "DCH-22", + "PRI-10" + ], + "CM-12": [ + "DCH-24" + ], + "CM-12(01)": [ + "DCH-24.1" + ], + "SI-03": [ "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" + ], + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" + ], + "SI-07": [ "END-06", - "IAC-20", - "IAC-21", + "NET-12", "TDA-18" ], - "T1578": [ - "CHG-04", - "CFG-02", - "MON-01", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-11", - "IAC-15", - "IAC-20", - "IAC-21", - "VPM-06" + "SI-07(01)": [ + "END-06.1" ], - "T1578.001": [ - "CHG-04", - "CFG-02", - "MON-01", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-11", - "IAC-15", - "IAC-20", - "IAC-21", - "VPM-06" + "SI-07(07)": [ + "END-06.2" ], - "T1578.002": [ - "CHG-04", - "CFG-02", - "MON-01", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-11", - "IAC-15", - "IAC-20", - "IAC-21", - "VPM-06" + "SI-08": [ + "END-08" ], - "T1578.003": [ - "CHG-04", - "CFG-02", - "MON-01", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-11", - "IAC-15", - "IAC-20", - "IAC-21", - "VPM-06" + "SC-18": [ + "END-10" ], - "T1599": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "CRY-05", - "END-06", - "HRS-11", - "IAC-02", - "IAC-10", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "SC-41": [ + "END-12" ], - "T1599.001": [ - "CHG-04", - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "CRY-05", - "END-06", - "HRS-11", - "IAC-02", - "IAC-10", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "SC-15": [ + "END-14" ], - "T1611": [ - "CHG-04", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-03", - "NET-04", - "SEA-03.2", - "SEA-04", - "SEA-04.1", - "SEA-10", - "SEA-16", - "VPM-05" + "PS-02": [ + "HRS-02", + "HRS-03.2" ], - "T1619": [ - "CHG-04", - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-14" + "PM-13": [ + "HRS-03", + "SAT-01" ], - "T1621": [ - "CHG-04", - "IAC-02", - "IAC-04", - "IAC-10", - "IAC-15", - "IAC-21" + "PS-09": [ + "HRS-03" ], - "T1001": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "PS-03": [ + "HRS-04" ], - "T1001.001": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "T1001.002": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "PL-04(01)": [ + "HRS-05.2" ], - "T1001.003": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "T1008": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "PS-08": [ + "HRS-07" ], - "T1029": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "PS-05": [ + "HRS-08" ], - "T1030": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "PS-04": [ + "HRS-09" ], - "T1036": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "IAC-05", - "IAC-15", - "IAC-20", - "IAC-21", - "TDA-18" + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" ], - "T1036.003": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "IAC-15", - "IAC-20", - "IAC-21" + "PS-07": [ + "HRS-10" ], - "T1036.005": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "IAC-05", - "IAC-15", - "IAC-20", - "IAC-21", - "TDA-18" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "T1036.007": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" + ], + "IA-02": [ "IAC-02" ], - "T1037": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "IAC-20", - "NET-14" + "IA-02(08)": [ + "IAC-02.2" ], - "T1037.002": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "IAC-20" + "IA-02(12)": [ + "IAC-02.3" ], - "T1037.003": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "IAC-20" + "IA-08": [ + "IAC-03" ], - "T1037.004": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "IAC-20" + "IA-08(01)": [ + "IAC-03.1" ], - "T1037.005": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "IAC-20" + "IA-08(02)": [ + "IAC-03.2" ], - "T1048.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "IAC-20", - "NET-02.3", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "IA-08(04)": [ + "IAC-03.3" ], - "T1055.009": [ - "CPL-02", - "MON-01", - "END-04", - "END-10", - "IAC-20", - "IAC-21", - "NET-03", - "SEA-10", - "VPM-05" + "IA-03": [ + "IAC-04" ], - "T1056.002": [ - "CPL-02", - "MON-01", - "END-04", - "END-06" + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "T1070.003": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "HRS-11", - "IAC-15", - "IAC-20", - "IAC-21" + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "T1070.007": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "HRS-11", + "AC-02": [ + "IAC-07.2", "IAC-15", - "IAC-20", - "IAC-21" + "NET-12", + "TDA-18" ], - "T1070.009": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "HRS-11", - "IAC-15", - "IAC-20", - "IAC-21" + "IA-05": [ + "IAC-10", + "IAC-10.8" ], - "T1071": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "MON-15", - "END-04", - "NET-03", - "NET-04", - "NET-07", - "NET-09", - "NET-10", - "NET-10.1", - "NET-10.2", - "NET-11" + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "T1071.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "MON-15", - "END-04", - "NET-03", - "NET-04", - "NET-07", - "NET-09", - "NET-10", - "NET-10.1", - "NET-10.2", - "NET-11" + "IA-05(02)": [ + "IAC-10.2" ], - "T1071.002": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "MON-15", - "END-04", - "NET-03", - "NET-04", - "NET-07", - "NET-09", - "NET-10", - "NET-10.1", - "NET-10.2", - "NET-11" + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" ], - "T1071.003": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "MON-15", - "END-04", - "NET-03", - "NET-04", - "NET-07", - "NET-09", - "NET-10", - "NET-10.1", - "NET-10.2", - "NET-11" + "IA-06": [ + "IAC-11" ], - "T1071.004": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "MON-15", - "END-04", - "IAC-20", - "NET-03", - "NET-04", - "NET-07", - "NET-09", - "NET-10", - "NET-10.1", - "NET-10.2", - "NET-11", - "SEA-09", - "TDA-18" + "IA-11": [ + "IAC-14" ], - "T1078.001": [ - "CPL-02", - "MON-01", - "CRY-05", - "HRS-11", - "IAC-15", - "IAC-21", - "PRM-07", - "SEA-01", - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-09", - "TDA-14", - "TDA-16" + "AC-02(01)": [ + "IAC-15.1" ], - "T1080": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "IAC-20", - "NET-03", - "SEA-05", - "TDA-18" + "AC-02(02)": [ + "IAC-15.2" ], - "T1090": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "CRY-03", - "CRY-04", - "END-04", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "AC-02(03)": [ + "IAC-15.3" ], - "T1090.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "AC-02(04)": [ + "IAC-15.4" ], - "T1090.002": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "AC-06(07)": [ + "IAC-17" ], - "T1090.003": [ - "CPL-02", - "CFG-02", - "CFG-03", + "AC-03": [ "IAC-20", - "NET-03", - "NET-04", - "SEA-09", + "NET-12", "TDA-18" ], - "T1095": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", + "AC-06": [ "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" - ], - "T1102": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "IAC-21" ], - "T1102.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "AC-06(01)": [ + "IAC-21.1" ], - "T1102.002": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "AC-06(02)": [ + "IAC-21.2" ], - "T1102.003": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "AC-06(05)": [ + "IAC-21.3" ], - "T1104": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "AC-06(09)": [ + "IAC-21.4" ], - "T1105": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "AC-06(10)": [ + "IAC-21.5" ], - "T1110": [ - "CPL-02", - "CFG-02", - "MON-01", - "DCH-13", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-10", - "IAC-14", - "IAC-15", - "IAC-20", - "IAC-21", + "AC-07": [ "IAC-22" ], - "T1110.001": [ - "CPL-02", - "CFG-02", - "MON-01", - "DCH-13", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-10", - "IAC-14", - "IAC-15", - "IAC-20", - "IAC-21", - "IAC-22" + "AC-02(05)": [ + "IAC-24" ], - "T1110.002": [ - "CPL-02", - "CFG-02", - "MON-01", - "DCH-13", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-10", - "IAC-14", - "IAC-15", - "IAC-20", - "IAC-21", - "IAC-22" + "AC-11": [ + "IAC-24" ], - "T1110.003": [ - "CPL-02", - "CFG-02", - "MON-01", - "DCH-13", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-10", - "IAC-14", - "IAC-15", - "IAC-20", - "IAC-21", - "IAC-22" + "AC-11(01)": [ + "IAC-24.1" ], - "T1110.004": [ - "CPL-02", - "CFG-02", - "MON-01", - "DCH-13", - "HRS-11", - "IAC-02", - "IAC-09", - "IAC-10", - "IAC-14", - "IAC-15", - "IAC-20", - "IAC-21", - "IAC-22" + "AC-12": [ + "IAC-25" ], - "T1111": [ - "CPL-02", - "CFG-02", - "MON-01", - "DCH-13", - "END-04", - "IAC-02", - "IAC-10" + "AC-14": [ + "IAC-26" ], - "T1132": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "IA-12": [ + "IAC-28" ], - "T1132.001": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "IA-12(02)": [ + "IAC-28.2" ], - "T1132.002": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "IA-12(03)": [ + "IAC-28.3" ], - "T1187": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "IA-12(05)": [ + "IAC-28.5" ], - "T1201": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04" + "IR-04": [ + "IRO-02" ], - "T1204": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "END-08", - "IRO-15", - "NET-03", - "NET-04", - "TDA-18", - "VPM-05" + "IR-04(01)": [ + "IRO-02.1" ], - "T1204.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-08", - "IRO-15", - "NET-03", - "NET-04", - "VPM-05" + "IR-08": [ + "IRO-04" ], - "T1204.002": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "END-08", - "IRO-15", - "NET-03", - "NET-04", - "TDA-18" + "IR-02": [ + "IRO-05" ], - "T1205": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09" + "IR-03": [ + "IRO-06" ], - "T1205.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09" + "IR-03(02)": [ + "IRO-06.1" ], - "T1213.003": [ - "CPL-02", - "HRS-11", - "IAC-02", - "IAC-05", - "IAC-15", - "IAC-20", - "IAC-21", - "PRM-07", - "SEA-01", - "TDA-06", - "TDA-09", - "TDA-14", - "VPM-05", - "VPM-06" + "IR-05": [ + "IRO-09" ], - "T1213.004": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "CRY-05", - "DCH-05", - "DCH-14", - "DCH-16", - "DCH-18", - "END-06", - "HRS-11", - "IAC-02", - "IAC-03", - "IAC-09", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-04" + "IR-06(01)": [ + "IRO-10.1" ], - "T1218.002": [ - "CPL-02", - "CFG-02", - "CFG-03", - "CFG-05", - "MON-01", - "END-04", - "END-06", - "IAC-20", - "SEA-10", - "TDA-18" + "IR-06(03)": [ + "IRO-10.4" ], - "T1218.010": [ - "CPL-02", - "MON-01", - "END-06", - "TDA-18" + "IR-07": [ + "IRO-11" ], - "T1218.011": [ - "CPL-02", - "MON-01", - "END-06", - "TDA-18" + "IR-07(01)": [ + "IRO-11.1" ], - "T1219": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "IAC-20", - "NET-03", - "NET-04", - "NET-14", - "SEA-09", - "TDA-18" + "PM-10": [ + "IAO-01" ], - "T1498": [ - "CPL-02", - "CFG-02", - "CFG-03", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "CA-02(01)": [ + "IAO-02.1" ], - "T1498.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "CA-05": [ + "IAO-05" ], - "T1498.002": [ - "CPL-02", - "CFG-02", - "CFG-03", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "PM-04": [ + "IAO-05", + "VPM-02" ], - "T1499": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "CM-04(02)": [ + "IAO-06" ], - "T1499.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "CA-06": [ + "IAO-07" ], - "T1499.002": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "MA-02": [ + "MNT-02" ], - "T1499.003": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "MA-06": [ + "MNT-03" ], - "T1499.004": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "MA-03": [ + "MNT-04" ], - "T1539": [ - "CPL-02", - "CFG-02", - "MON-01", - "DCH-13", - "END-04", - "IAC-02", - "IAC-10", - "IAC-20", - "IAC-21" + "MA-03(01)": [ + "MNT-04.1" ], - "T1546.004": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "IAC-20", - "IAC-21" + "MA-03(02)": [ + "MNT-04.2" ], - "T1546.013": [ - "CPL-02", - "CFG-02", - "CFG-04", - "MON-01", - "END-04", - "END-06", - "IAC-05", - "IAC-20", - "IAC-21" + "MA-03(03)": [ + "MNT-04.3" ], - "T1552.001": [ - "CPL-02", - "CFG-02", - "MON-01", - "CRY-05", - "CRY-08", - "HRS-11", - "IAC-02", - "IAC-10", - "IAC-15", - "IAC-21", - "NET-03", - "NET-04", - "SEA-05", - "TDA-06", - "TDA-09", - "VPM-06" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "T1552.004": [ - "CPL-02", - "CFG-02", - "MON-01", - "CRY-05", - "CRY-08", - "DCH-05", - "DCH-13", - "DCH-18", - "END-06", - "IAC-02", - "IAC-10", - "IAC-15", - "MDM-02", - "NET-03", - "NET-14", - "NET-15", - "SEA-05", - "TDA-06", - "TDA-09", - "VPM-06" + "MA-04(01)": [ + "MNT-05.1" ], - "T1552.005": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "DCH-05", - "DCH-13", - "IAC-04", - "IAC-09", - "IAC-20", - "NET-03", - "NET-04", - "NET-14", - "SEA-09", - "TDA-18" + "MA-05": [ + "MNT-06" ], - "T1553.003": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "IAC-20", - "IAC-21", - "TDA-18" + "SR-11(02)": [ + "MNT-07" ], - "T1555.001": [ - "CPL-02", - "MON-01", - "IAC-10" + "MA-07": [ + "MNT-08" ], - "T1555.002": [ - "CPL-02", - "MON-01", - "IAC-10", - "IAC-20", - "IAC-21" + "AC-19": [ + "MDM-02" ], - "T1557.004": [ - "CPL-02", - "CFG-02", - "MON-01", - "CRY-01", - "CRY-03", - "CRY-04", - "DCH-18", - "END-06", - "IAC-20", - "MDM-02", - "NET-02.3", - "NET-03", - "NET-04", - "NET-09", - "NET-12.1", - "NET-15" + "AC-19(05)": [ + "MDM-03" ], - "T1558.004": [ - "CPL-02", - "CFG-02", - "MON-01", - "DCH-05", - "DCH-18", - "END-04", - "END-06", - "IAC-02", - "IAC-10", - "IAC-15", - "IAC-20", - "MDM-02", - "NET-14", - "NET-15", - "SEA-05", - "TDA-06", - "TDA-09", - "VPM-06" + "SC-07": [ + "NET-03" ], - "T1558.005": [ - "CPL-02", - "MON-01", - "DCH-18", - "END-06", - "IAC-02", - "IAC-10", - "IAC-15", - "IAC-20", - "IAC-21", - "SEA-05" + "SC-07(03)": [ + "NET-03.1" ], - "T1564.004": [ - "CPL-02", - "MON-01", - "DCH-05", - "END-04", - "END-06", - "IAC-20" + "SC-07(04)": [ + "NET-03.2" ], - "T1564.010": [ - "CPL-02", - "MON-01", - "END-06" + "AC-04": [ + "NET-04" ], - "T1566": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-08", - "IAC-05", - "IRO-15", - "NET-03", - "NET-04", - "NET-10", - "VPM-05", - "VPM-06" + "SC-07(05)": [ + "NET-04.1" ], - "T1566.001": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-08", - "IAC-05", - "IRO-15", - "NET-03", - "NET-04", - "NET-10", - "VPM-05" + "CA-03": [ + "NET-05" ], - "T1566.002": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-08", - "IAC-05", - "IRO-15", - "NET-03", - "NET-04", + "CA-09": [ + "NET-05.2" + ], + "SC-07(28)": [ + "NET-06.5" + ], + "SC-23": [ + "NET-09" + ], + "SC-20": [ "NET-10" ], - "T1566.003": [ - "CPL-02", - "MON-01", - "END-04", - "END-08", - "IAC-15", - "IAC-21", - "IRO-15", - "NET-03", - "NET-04", - "VPM-05" + "SC-22": [ + "NET-10.1" ], - "T1568": [ - "CPL-02", - "MON-01", - "END-04", - "NET-03", - "NET-04", - "NET-10", - "NET-10.1", + "SC-21": [ "NET-10.2" ], - "T1568.002": [ - "CPL-02", - "MON-01", - "END-04", - "NET-03", - "NET-04", - "NET-10", - "NET-10.1", - "NET-10.2" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "T1570": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", + "SI-10": [ + "NET-12", "TDA-18" ], - "T1571": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "NET-04" + "AC-17": [ + "NET-14" ], - "T1572": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "IAC-20", - "NET-03", - "NET-04", - "SEA-09", - "TDA-18" + "AC-17(01)": [ + "NET-14.1" ], - "T1573": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "CRY-08", - "CRY-10", - "END-04", - "NET-03", - "NET-04", - "NET-09" + "AC-17(02)": [ + "NET-14.2" ], - "T1573.001": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "CRY-08", - "CRY-10", - "END-04", - "NET-03", - "NET-04", - "NET-09" + "AC-17(03)": [ + "NET-14.3" ], - "T1573.002": [ - "CPL-02", - "CFG-02", - "CFG-03", - "MON-01", - "CRY-08", - "CRY-10", - "END-04", - "NET-03", - "NET-04", - "NET-09" + "AC-17(04)": [ + "NET-14.4" ], - "T1574.013": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-06", - "TDA-18", - "VPM-05" + "AC-17(09)": [ + "NET-14.8" ], - "T1598": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-08", - "IAC-05", - "IRO-15", - "NET-03", - "NET-04", - "NET-10" + "AC-18(01)": [ + "NET-15.1" ], - "T1598.001": [ - "CPL-02", - "MON-01", - "END-04", - "END-08", - "IRO-15", - "NET-03", - "NET-04" + "AC-18(03)": [ + "NET-15.2" ], - "T1598.002": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-08", - "IAC-05", - "IRO-15", - "NET-03", - "NET-04", - "NET-10" + "SC-07(08)": [ + "NET-18", + "NET-18.1" ], - "T1598.003": [ - "CPL-02", - "CFG-02", - "MON-01", - "END-04", - "END-08", - "IAC-05", - "IRO-15", - "NET-03", - "NET-04", - "NET-10" + "PE-02": [ + "PES-02" ], - "T1027": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "IAC-20", - "VPM-05" + "PE-03": [ + "PES-03" ], - "T1027.010": [ - "CFG-02", - "MON-01", - "END-04", - "TDA-18" + "PE-08": [ + "PES-03.3" ], - "T1036.001": [ - "CFG-02", - "MON-01", - "END-06", - "IAC-05" + "PE-06": [ + "PES-05" ], - "T1036.010": [ - "CFG-02", - "MON-01", - "IAC-02", - "IAC-15", - "IAC-20" + "PE-06(01)": [ + "PES-05.1" ], - "T1059.003": [ - "CFG-02", - "MON-01", - "END-04", - "END-06", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-14", - "SEA-10", - "TDA-18" + "PE-06(04)": [ + "PES-05.2" ], - "T1059.004": [ - "CFG-02", - "MON-01", - "END-04", - "END-06", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-14", - "SEA-10", - "TDA-18" + "PE-09": [ + "PES-07" ], - "T1059.011": [ - "CFG-02", - "MON-01", - "END-04", - "END-06", - "IAC-15", - "IAC-20", - "IAC-21", - "SEA-10" + "PE-10": [ + "PES-07.2" ], - "T1087": [ - "CFG-02", - "CFG-03", - "MON-01", - "IAC-15" + "PE-11": [ + "PES-07.3" ], - "T1087.001": [ - "CFG-02", - "CFG-03", - "MON-01" + "PE-12": [ + "PES-07.4" ], - "T1087.002": [ - "CFG-02", - "CFG-03", - "MON-01" + "PE-15": [ + "PES-07.5" ], - "T1106": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "IAC-21", - "VPM-05" + "PE-13": [ + "PES-08" ], - "T1114": [ - "CFG-02", - "MON-01", - "DCH-05", - "DCH-13", - "DCH-18", - "END-06", - "IAC-02", - "IAC-10", - "IAC-20", - "MDM-02", - "NET-03", - "NET-04", - "NET-11", - "NET-14" + "PE-13(01)": [ + "PES-08.1" ], - "T1114.002": [ - "CFG-02", - "MON-01", - "DCH-05", - "DCH-13", - "DCH-18", - "END-06", - "IAC-02", - "IAC-10", - "IAC-20", - "MDM-02", - "NET-04", - "NET-11", - "NET-14" + "PE-14": [ + "PES-09" ], - "T1129": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "TDA-18" + "PE-16": [ + "PES-10" ], - "T1134.005": [ - "CFG-02", - "DCH-13", - "HRS-11", - "IAC-20", - "IAC-21", - "NET-04", - "SEA-01", - "SEA-04.1", - "TDA-01", - "TDA-05", - "TDA-09" + "PE-17": [ + "PES-11" ], - "T1135": [ - "CFG-02", - "CFG-03", - "MON-01" + "PE-04": [ + "PES-12.1" ], - "T1137.003": [ - "CFG-02", - "END-08", - "END-10", - "IAC-21", - "IRO-15", - "VPM-05" + "PE-05": [ + "PES-12.2" ], - "T1137.004": [ - "CFG-02", - "END-08", - "END-10", - "IAC-21", - "IRO-15", - "VPM-05" + "PM-18": [ + "PRI-01" ], - "T1137.005": [ - "CFG-02", - "END-08", - "END-10", - "IAC-21", - "IRO-15", - "VPM-05" + "PM-19": [ + "PRI-01.1" ], - "T1137.006": [ - "CFG-02", - "END-08", - "END-10", - "IAC-21", - "IRO-15" + "PM-20": [ + "PRI-01.3" ], - "T1199": [ - "CFG-02", - "CFG-03", - "IAC-20", - "IAC-21", - "NET-02.3", - "NET-03", - "NET-04", - "SEA-18" + "PM-20(01)": [ + "PRI-02" ], - "T1216": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-06", - "TDA-18" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "T1216.001": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-06", - "TDA-18" + "AC-21": [ + "PRI-07" ], - "T1216.002": [ - "CFG-02", - "CFG-03", - "END-06" + "PM-27": [ + "PRI-14" ], - "T1218.001": [ - "CFG-02", - "CFG-03", - "CFG-05", - "MON-01", - "END-04", - "END-06", - "END-10", - "SEA-10", - "TDA-18" + "PM-21": [ + "PRI-14.1" ], - "T1220": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-06", - "TDA-18" + "PM-03": [ + "PRM-02" ], - "T1482": [ - "CFG-02", - "CFG-03", - "NET-02.3", - "NET-03", - "NET-04", - "SEA-01", - "TDA-05", - "VPM-06" + "SA-02": [ + "PRM-03" ], - "T1505.003": [ - "CFG-02", - "MON-01", - "HRS-11", - "IAC-15", - "IAC-20", - "IAC-21", - "VPM-06" + "PM-11": [ + "PRM-06" ], - "T1505.005": [ - "CFG-02", - "MON-01", - "DCH-13", - "HRS-11", - "IAC-15", - "IAC-20", - "IAC-21", - "IAC-25", - "NET-14", - "VPM-06" + "SA-03": [ + "PRM-07", + "SEA-07.1" ], - "T1546.008": [ - "CFG-02", - "CFG-03", - "CFG-04", - "MON-01", - "END-06", - "TDA-18" + "PM-09": [ + "RSK-01" ], - "T1546.010": [ - "CFG-02", - "CFG-03", - "END-06", - "TDA-18", - "VPM-05" + "PM-28": [ + "RSK-01.1" ], - "T1547.002": [ - "CFG-02", - "MON-01", - "END-04", - "END-06", - "SEA-04" + "RA-02": [ + "RSK-02" ], - "T1547.005": [ - "CFG-02", - "MON-01", - "END-04", - "END-06", - "SEA-04" + "RA-07": [ + "RSK-06.1" ], - "T1547.008": [ - "CFG-02", - "MON-01", - "END-04", - "END-06", - "SEA-04", - "VPM-06" + "PM-30": [ + "RSK-09" ], - "T1548.001": [ - "CFG-02", - "CFG-03", - "MON-01" + "SR-02": [ + "RSK-09", + "TPM-03" ], - "T1550.001": [ - "CFG-02", - "CFG-04", - "CFG-05", - "MON-01", - "CRY-03", - "CRY-04", - "CRY-05", - "DCH-05", - "DCH-13", - "DCH-18", - "END-06", - "IAC-02", - "IAC-09", - "MDM-02", - "NET-14" + "RA-03(01)": [ + "RSK-09.1" ], - "T1552.003": [ - "CFG-02", - "CFG-03", - "MON-01", - "CRY-05" + "CA-07(04)": [ + "RSK-11" ], - "T1552.006": [ - "CFG-02", - "MON-01", - "HRS-11", - "IAC-02", - "IAC-10", - "IAC-15", - "IAC-21", - "TDA-06", - "TDA-09", - "VPM-05", - "VPM-06" + "SC-07(18)": [ + "SEA-01" ], - "T1553.001": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-06", - "TDA-18" + "PL-08": [ + "SEA-02" ], - "T1553.004": [ - "CFG-02", - "CFG-03", - "CFG-04", - "MON-01", - "IAC-05", - "NET-10" + "PM-07": [ + "SEA-02" ], - "T1553.005": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-06", - "TDA-18" + "SC-02": [ + "SEA-03.2" ], - "T1555.004": [ - "CFG-02", - "CFG-03", - "MON-01", - "IAC-10" + "SC-39": [ + "SEA-04" ], - "T1555.005": [ - "CFG-02", - "MON-01", - "IAC-02", - "IAC-10", - "IAC-15", - "IAC-20", - "VPM-05" + "SC-04": [ + "SEA-05" ], - "T1556.002": [ - "CFG-02", - "CFG-03", - "MON-01" + "CM-07(02)": [ + "SEA-06" ], - "T1560": [ - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "VPM-06" + "CP-12": [ + "SEA-07.2" ], - "T1560.001": [ - "CFG-02", - "MON-01", - "END-04", - "NET-03", - "VPM-06" + "SC-24": [ + "SEA-07.2" ], - "T1562.003": [ - "CFG-02", - "CFG-03", - "MON-01" + "SI-17": [ + "SEA-07.3" ], - "T1562.010": [ - "CFG-02", - "CFG-03", - "MON-01", - "CRY-03", - "CRY-04", - "END-06", - "VPM-06" + "SI-16": [ + "SEA-10" ], - "T1564.002": [ - "CFG-02", - "CFG-03", - "MON-01" + "AC-08": [ + "SEA-18" ], - "T1574.001": [ - "CFG-02", - "CFG-03", - "MON-01", - "END-04", - "END-06", - "TDA-18", - "VPM-06" + "AT-02": [ + "SAT-02" ], - "T1574.006": [ - "CFG-02", - "CFG-03", - "END-06", - "TDA-18" + "AT-02(03)": [ + "SAT-02.2" ], - "T1590.002": [ - "CFG-02", - "CFG-03", - "NET-03", - "NET-04", - "SEA-03.1" + "AT-03": [ + "SAT-03" ], - "T1609": [ - "CFG-02", - "CFG-03", - "END-06", - "HRS-11", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-03", - "NET-04", - "NET-14", - "TDA-18" + "AT-02(04)": [ + "SAT-03.2" ], - "T1610": [ - "CFG-02", - "CFG-03", - "MON-01", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-03", - "NET-14" + "AT-04": [ + "SAT-04" ], - "T1612": [ - "CFG-02", - "CFG-03", - "MON-01", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-03", - "NET-14", - "TDA-09", - "VPM-06" + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "T1648": [ - "CFG-02", - "CFG-03", - "MON-01", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-03" + "SA-04(09)": [ + "TDA-02.1" ], - "T1036.008": [ - "CFG-03", - "MON-01", - "END-04", - "NET-03", - "TDA-18" + "SA-04(10)": [ + "TDA-02.2" ], - "T1037.001": [ - "CFG-03", - "NET-14" + "SA-15": [ + "TDA-06" ], - "T1040": [ - "CFG-03", - "MON-01", - "CRY-03", - "CRY-04", - "DCH-05", - "DCH-18", - "END-06", - "IAC-02", - "IAC-10", - "MDM-02", - "NET-14", - "NET-15", - "SEA-05" + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" ], - "T1059.009": [ - "CFG-03", - "MON-01", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "SA-15(03)": [ + "TDA-06.1" ], - "T1112": [ - "CFG-03", - "END-06", - "IAC-21" + "SA-11": [ + "TDA-09" ], - "T1546.009": [ - "CFG-03", - "END-06", - "TDA-18" + "SR-11": [ + "TDA-11" ], - "T1555.006": [ - "CFG-03", - "IAC-15", - "IAC-20", - "IAC-21" + "SR-11(01)": [ + "TDA-11.1" ], - "T1564.003": [ - "CFG-03", - "END-06", - "TDA-18" + "SA-10": [ + "TDA-14" ], - "T1027.002": [ - "MON-01", - "END-04", - "END-06", - "VPM-05" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "T1027.007": [ - "MON-01", - "END-04", - "END-06", - "VPM-05" + "SI-11": [ + "TDA-19" ], - "T1027.008": [ - "MON-01", - "END-04", - "END-06", - "VPM-05" + "RA-09": [ + "TPM-02" ], - "T1027.009": [ - "MON-01", - "END-04", - "END-06", - "VPM-05" + "SR-02(01)": [ + "TPM-03" ], - "T1027.011": [ - "MON-01" + "SR-05": [ + "TPM-03.1" ], - "T1027.012": [ - "MON-01", - "END-04" + "SR-03": [ + "TPM-03.3" ], - "T1055.001": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "SR-05(01)": [ + "TPM-03.4" ], - "T1055.002": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "SA-09": [ + "TPM-04" ], - "T1055.003": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "SA-09(02)": [ + "TPM-04.2" ], - "T1055.004": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "SR-08": [ + "TPM-05.1" ], - "T1055.005": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "SR-06": [ + "TPM-08" ], - "T1055.011": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "PM-16": [ + "THR-01" ], - "T1055.012": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "PM-12": [ + "THR-04" ], - "T1055.013": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "AT-02(02)": [ + "THR-05" ], - "T1055.014": [ - "MON-01", - "END-04", - "END-10", - "IAC-21", - "NET-03", - "VPM-05" + "RA-05(11)": [ + "THR-06" ], - "T1070.010": [ - "MON-01", - "END-04", - "END-06" + "SI-02(02)": [ + "VPM-05.2" ], - "T1071.005": [ - "MON-01", - "MON-15", - "NET-03", - "NET-04" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "T1114.001": [ - "MON-01", - "DCH-05", - "DCH-13", - "DCH-18", - "END-06", - "MDM-02", - "NET-04", - "NET-11", - "NET-14" + "RA-05(02)": [ + "VPM-06.1" ], - "T1205.002": [ - "MON-01", - "NET-04" + "RA-05(05)": [ + "VPM-06.3" + ] + }, + "general-nist-800-82-r3-high": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" ], - "T1552.008": [ - "MON-01", - "NET-04" + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "T1651": [ - "MON-01", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21", - "NET-14" + "AT-01": [ + "GOV-02" ], - "T1090.004": [ - "CRY-03", - "CRY-04" + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "T1550.004": [ - "CRY-03", - "CRY-04", - "END-06", - "NET-09" + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "T1521.003": [ - "CRY-08" + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "T1606": [ - "CRY-08", - "HRS-11", - "IAC-15", - "IAC-20", - "IAC-21", - "VPM-05" + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "T1200": [ - "DCH-10", - "DCH-13", - "END-12", - "IAC-20", - "IAC-21" + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "T1021.007": [ - "DCH-13", - "HRS-11", - "IAC-02", - "IAC-10", - "IAC-15", - "IAC-20", - "IAC-21" + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "T1567.001": [ - "DCH-13", - "NET-03", - "NET-04" + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "T1567.002": [ - "DCH-13", - "NET-03", - "NET-04" + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "T1589": [ - "DCH-16" + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "T1589.002": [ - "DCH-16" + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "TDA-01" ], - "T1589.003": [ - "DCH-16" + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "T1590": [ - "DCH-16" + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "T1591": [ - "DCH-16" + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" ], - "T1591.001": [ - "DCH-16" + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "T1591.002": [ - "DCH-16" + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "T1591.003": [ - "DCH-16" + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "T1591.004": [ - "DCH-16" + "PM-02": [ + "GOV-04" ], - "T1593.001": [ - "DCH-16" + "PM-06": [ + "GOV-04", + "GOV-05" ], - "T1593.002": [ - "DCH-16" + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" ], - "T1594": [ - "DCH-16" + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "T1595": [ - "DCH-16" + "PM-15": [ + "GOV-07", + "THR-01" ], - "T1595.001": [ - "DCH-16" + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" ], - "T1595.002": [ - "DCH-16" + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" ], - "T1596": [ - "DCH-16" + "PM-32": [ + "GOV-11" ], - "T1596.005": [ - "DCH-16" + "PM-05": [ + "AST-01", + "AST-02" ], - "T1597": [ - "DCH-16" + "CM-08": [ + "AST-02", + "AST-02.3" ], - "T1027.013": [ - "END-04" + "CM-08(01)": [ + "AST-02.1" ], - "T1027.014": [ - "END-04" + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" ], - "T1055.015": [ - "END-04" + "CM-08(02)": [ + "AST-02.9" ], - "T1564.012": [ - "END-04" + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" ], - "T1087.004": [ - "HRS-11", - "IAC-02", - "IAC-03", - "IAC-15", - "IAC-20", - "IAC-21" + "CM-08(04)": [ + "AST-03.1" ], - "T1538": [ - "HRS-11", - "IAC-02", - "IAC-03", - "IAC-15", - "IAC-20", - "IAC-21" + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "T1543.005": [ - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "SA-04(01)": [ + "AST-04", + "TDA-04.1" ], - "T1556.005": [ - "HRS-11", - "IAC-10", - "IAC-15", - "IAC-21" + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" ], - "T1580": [ - "HRS-11", - "IAC-02", - "IAC-15", - "IAC-20", - "IAC-21" + "PE-22": [ + "AST-04.1", + "PES-16" ], - "T1657": [ - "HRS-11", - "IAC-21" + "SA-05": [ + "AST-04.1", + "TDA-04" ], - "T1556.006": [ - "IAC-02", - "IAC-14", - "IAC-15", - "IAC-20", - "IAC-21" + "SR-12": [ + "AST-09" ], - "T1556.007": [ - "IAC-02", - "IAC-14", - "IAC-15", - "IAC-20", - "IAC-21" + "SR-09": [ + "AST-15" ], - "T1649": [ - "IAC-02", - "IAC-10" + "SR-09(01)": [ + "AST-15" ], - "T1098.006": [ - "IAC-10", - "IAC-15", - "IAC-20", - "IAC-21" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "T1496.002": [ - "IAC-15" + "CP-02": [ + "BCD-01", + "BCD-06" ], - "T1585": [ - "IAC-15" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "T1585.001": [ - "IAC-15" + "PM-08": [ + "BCD-01", + "CPL-01" ], - "T1585.002": [ - "IAC-15" + "CP-02(01)": [ + "BCD-01.1" ], - "T1585.003": [ - "IAC-15" + "CP-06(02)": [ + "BCD-01.4" ], - "T1586": [ - "IAC-15" + "CP-02(08)": [ + "BCD-02" ], - "T1586.001": [ - "IAC-15" + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" ], - "T1586.002": [ - "IAC-15" + "CP-02(05)": [ + "BCD-02.2" ], - "T1586.003": [ - "IAC-15" + "CP-03": [ + "BCD-03" ], - "T1606.001": [ - "IAC-15", - "IAC-20", - "IAC-21", - "VPM-05" + "CP-03(01)": [ + "BCD-03.1" ], - "T1606.002": [ - "IAC-15", - "IAC-20", - "IAC-21" + "CP-04": [ + "BCD-04", + "BCD-05" ], - "T1654": [ - "IAC-15", - "IAC-20", - "IAC-21", - "NET-04" + "CP-04(01)": [ + "BCD-04.1" ], - "T1546.011": [ - "IAC-21", - "VPM-05" + "CP-04(02)": [ + "BCD-04.2" ], - "T1496.003": [ - "NET-02.1" + "CP-06": [ + "BCD-08" ], - "T1567.003": [ - "NET-03", - "NET-04", - "NET-14" + "CP-06(01)": [ + "BCD-08.1" ], - "T1567.004": [ - "NET-03", - "NET-04", - "NET-14" + "CP-06(03)": [ + "BCD-08.2" ], - "T1659": [ - "NET-03", - "NET-04", - "NET-14" + "CP-07": [ + "BCD-09" ], - "T1590.001": [ - "NET-03.3" + "CP-07(01)": [ + "BCD-09.1" ], - "T1590.003": [ - "NET-03.3" + "CP-07(02)": [ + "BCD-09.2" ], - "T1590.004": [ - "NET-03.3" + "CP-07(03)": [ + "BCD-09.3" ], - "T1590.005": [ - "NET-03.3" + "CP-07(04)": [ + "BCD-09.4" ], - "T1590.006": [ - "NET-03.3" + "CP-08": [ + "BCD-10" ], - "T1592": [ - "NET-03.3" + "CP-08(02)": [ + "BCD-10" ], - "T1592.001": [ - "NET-03.3" + "CP-08(01)": [ + "BCD-10.1" ], - "T1592.002": [ - "NET-03.3" + "CP-08(03)": [ + "BCD-10.2" ], - "T1592.003": [ - "NET-03.3" + "CP-08(04)": [ + "BCD-10.3" ], - "T1592.004": [ - "NET-03.3" + "SC-47": [ + "BCD-10.4" ], - "T1535": [ - "NET-09" + "CP-09": [ + "BCD-11" ], - "T1583.002": [ - "NET-10.1" + "CP-09(01)": [ + "BCD-11.1" ], - "T1584.002": [ - "NET-10.1" + "CP-09(03)": [ + "BCD-11.2" ], - "T1596.001": [ - "NET-10.1" + "CP-09(08)": [ + "BCD-11.4" ], - "T1596.002": [ - "NET-10.4" + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" ], - "T1574.002": [ - "PRM-07", - "SEA-01", - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-09", - "TDA-14", - "TDA-16", - "VPM-05" + "CP-09(02)": [ + "BCD-11.5" ], - "T1595.003": [ - "SEA-05" - ] - }, - "general-mpa-csbp-5-3-1": { - "OR-1.0": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-15", - "GOV-15.1", - "SEA-01", - "OPS-01.1" + "CP-09(05)": [ + "BCD-11.6" ], - "OR-5.0": [ - "AAT-01", - "AAT-02", - "AAT-02.1", - "AAT-02.4", - "CPL-01" + "CP-10(02)": [ + "BCD-12.1" ], - "TS-7.0": [ - "AAT-11", - "AAT-12.1", - "AAT-12.2" + "SI-13": [ + "BCD-12.2", + "SEA-07" ], - "TS-7.1": [ - "AAT-20.2" + "CP-10(04)": [ + "BCD-12.4" ], - "OP-3.0": [ - "AST-01", - "AST-02", - "DCH-01", - "DCH-01.2", - "DCH-01.3", - "DCH-04" + "CP-10(06)": [ + "BCD-13" ], - "TS-5.0": [ - "AST-02", - "AST-02.9", + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "CP-02(02)": [ + "CAP-03" + ], + "CM-03": [ "CHG-01", - "CHG-02.2", - "CHG-03" + "CHG-02" ], - "TS-1.17": [ - "AST-02.7", - "TDA-04" + "CM-03(01)": [ + "CHG-02.1" ], - "TS-2.2": [ - "AST-04" + "CM-03(04)": [ + "CHG-02.3" ], - "OP-3.2": [ - "AST-09", - "DCH-06", - "DCH-09", - "HRS-11" + "CM-03(06)": [ + "CHG-02.5" ], - "OR-1.2": [ - "BCD-01", - "BCD-02", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3", - "RSK-03.1", - "TDA-06", - "TDA-09", - "THR-09", - "THR-10" + "CM-04": [ + "CHG-03" ], - "OR-1.3": [ - "BCD-01", - "BCD-11", - "BCD-11.4", - "BCD-11.9", - "IRO-04" + "CM-05": [ + "CHG-04", + "END-03.2" ], - "OP-2.1": [ - "BCD-04.2", - "BCD-08", - "BCD-09", - "NET-14", - "PES-01", - "PES-11" + "CM-05(01)": [ + "CHG-04.1" ], - "TS-2.6": [ - "CHG-02.1", - "CFG-02", - "MON-01.4", - "NET-01" + "SI-07(15)": [ + "CHG-04.2" ], - "PS-3.3": [ - "CLD-01", - "CLD-02" + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "TS-2.0": [ - "CLD-01", - "CLD-02", - "NET-01", - "NET-02", - "NET-03", - "NET-04", - "WEB-01", - "WEB-02" + "CM-09": [ + "CHG-05", + "CFG-01" ], - "TS-2.12": [ - "CLD-01", - "CLD-02" + "CM-03(02)": [ + "CHG-06" ], - "TS-8.2": [ - "CLD-02", - "CFG-03", - "NET-06" + "SI-06": [ + "CHG-06" ], - "TS-1.11": [ - "CLD-06.1", - "TPM-05.4" + "SC-07(29)": [ + "CLD-03" ], - "TS-1.1": [ - "CFG-02" + "CA-07": [ + "CPL-02" ], - "TS-1.2": [ - "CFG-02", - "IAC-10.8" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "TS-2.3": [ + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" + ], + "CA-07(01)": [ + "CPL-03.1" + ], + "RA-03": [ + "CPL-03.2", + "RSK-04" + ], + "CM-02": [ "CFG-02", - "NET-01" + "CFG-02.1" ], - "TS-2.4": [ + "CM-06": [ "CFG-02", - "CFG-02.1", - "MON-01.4", - "MON-01.8", - "NET-04", - "NET-04.1", - "NET-04.6" + "CFG-02.7" ], - "TS-2.8": [ + "PL-10": [ + "CFG-02" + ], + "SA-08": [ "CFG-02", - "CFG-03", - "NET-06", - "NET-06.5", - "NET-18" + "SEA-01" ], - "TS-1.12": [ + "CM-02(02)": [ "CFG-02.2" ], - "TS-1.5": [ - "MON-01", - "MON-01.2", - "MON-01.3", - "MON-01.8", - "MON-03", - "MON-08", - "SEA-20" + "CM-06(01)": [ + "CFG-02.2" ], - "TS-2.7": [ - "MON-01.1", - "END-07", - "NET-01", - "NET-08" + "CM-02(03)": [ + "CFG-02.3" ], - "TS-2.13": [ - "MON-01.3", - "MON-11.2", - "NET-01" + "CM-02(07)": [ + "CFG-02.5" ], - "TS-1.0": [ - "CRY-01", - "CRY-03", - "CRY-05", - "DCH-18", - "END-01", - "END-01.1", - "END-02", - "END-04", - "END-04.7", - "HRS-11", - "IAC-20.4", - "NET-04", - "NET-04.1", - "NET-06.4", - "PES-04", - "PES-04.1" + "CM-06(02)": [ + "CFG-02.8" ], - "TS-3.0": [ - "CRY-01", - "CRY-03", - "CRY-05" + "PL-11": [ + "CFG-02.9" ], - "TS-2.11": [ - "CRY-07", - "NET-02.2", - "NET-06", - "NET-15" + "CM-07": [ + "CFG-03" ], - "TS-3.2": [ - "CRY-09" + "CM-07(01)": [ + "CFG-03.1" ], - "OR-1.4": [ - "DCH-01", - "DCH-01.2", - "DCH-02", - "HRS-11" + "CM-07(05)": [ + "CFG-03.3" ], - "OP-1.1": [ - "DCH-01", - "DCH-01.1", - "DCH-07", - "DCH-07.1" + "SC-07(07)": [ + "CFG-03.4" ], - "OP-3.1": [ - "DCH-01", - "DCH-01.4", - "DCH-23.9" + "CM-10": [ + "CFG-04" ], - "OP-1.3": [ - "DCH-06", - "DCH-06.1", - "DCH-07", - "DCH-07.1" + "CM-11": [ + "CFG-05" ], - "OP-1.2": [ - "DCH-07", - "DCH-07.1" + "AC-03(11)": [ + "CFG-08" ], - "TS-1.16": [ - "DCH-17" + "PM-31": [ + "MON-01" ], - "PS-1.3": [ - "DCH-18", - "PES-03.3" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "PS-3.0": [ - "DCH-18", - "PES-05.1" + "SI-04(02)": [ + "MON-01.2" ], - "TS-1.3": [ - "END-01", - "END-01.1", - "END-02", - "END-04", - "END-04.1", - "END-04.7" + "SI-04(04)": [ + "MON-01.3" ], - "TS-1.4": [ - "END-01.1", - "END-04", - "IRO-02", - "MDM-01", - "MDM-05" + "SI-04(05)": [ + "MON-01.4" ], - "TS-1.9": [ - "END-08", - "NET-17" + "SI-04(14)": [ + "MON-01.5" ], - "OR-3.0": [ - "HRS-01", - "HRS-04", - "HRS-04.1", - "HRS-05" + "AU-02": [ + "MON-01.8", + "MON-02" ], - "OP-2.0": [ - "HRS-01", - "HRS-03.1", - "NET-14.5" + "SI-04(12)": [ + "MON-01.12" ], - "OR-3.1": [ - "HRS-01.1", - "HRS-02", - "HRS-02.1", - "HRS-03", - "HRS-03.1", - "HRS-04.2", - "HRS-05", - "HRS-05.7", - "HRS-06", - "HRS-06.1", - "SAT-02", - "SAT-03" + "SI-04(20)": [ + "MON-01.15" ], - "OR-3.2": [ - "HRS-01.1", - "HRS-08", - "HRS-09", - "HRS-09.1", - "HRS-09.3", - "HRS-09.4" + "AU-06": [ + "MON-02", + "MON-02.6" ], - "OR-1.1": [ - "HRS-05.1", - "HRS-05.2", - "HRS-05.3", - "HRS-05.4", - "HRS-05.5" + "IR-04(04)": [ + "MON-02", + "MON-02.1" ], - "TS-1.6": [ - "IAC-01", - "IAC-01.2", - "IAC-02", - "IAC-06", - "IAC-09", - "IAC-09.1", - "IAC-10", - "IAC-10.1" + "AU-06(03)": [ + "MON-02.1" ], - "TS-1.8": [ - "IAC-01", - "IAC-01.1", - "IAC-01.2", - "IAC-08", - "IAC-29" + "AU-06(05)": [ + "MON-02.3" ], - "TS-1.7": [ - "IAC-01.2", - "IAC-08", - "IAC-17", - "IAC-20", - "IAC-21" + "AU-06(06)": [ + "MON-02.4" ], - "TS-1.10": [ - "IAC-08", - "NET-01", - "WEB-01", - "WEB-02" + "AU-12(01)": [ + "MON-02.7" ], - "OR-4.0": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-08", - "IRO-09", - "IRO-10" + "AU-12(03)": [ + "MON-02.8" ], - "OR-2.0": [ - "IAO-05", - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-03", - "RSK-04", - "RSK-04.3", - "RSK-05", - "RSK-06", - "RSK-06.4" + "AU-03": [ + "MON-03" ], - "TS-6.0": [ - "NET-01.1" + "AU-03(01)": [ + "MON-03.1" ], - "TS-6.1": [ - "NET-01.1" + "AU-06(01)": [ + "MON-03.1" ], - "TS-6.2": [ - "NET-01.1" + "AU-04": [ + "MON-04" ], - "TS-8.1": [ - "NET-09", - "NET-09.2" + "AU-05": [ + "MON-05" ], - "TS-2.1": [ - "NET-14" + "AU-05(02)": [ + "MON-05.1" ], - "TS-2.9": [ - "NET-14" + "AU-05(01)": [ + "MON-05.2" ], - "TS-2.10": [ - "NET-18" + "AU-07": [ + "MON-06" ], - "PS-1.5": [ - "PES-01" + "AU-07(01)": [ + "MON-06" ], - "PS-1.1": [ - "PES-02", - "PES-03.3", - "PES-04", - "PES-04.1", - "PES-06", - "PES-06.2" + "AU-12": [ + "MON-06" ], - "PS-1.2": [ - "PES-02", - "PES-03", - "PES-03.1", - "PES-03.3" + "AU-08": [ + "MON-07", + "SEA-20" ], - "OP-1.0": [ - "PES-03", - "PES-03.1", - "PES-06", - "PES-10" + "SC-45": [ + "MON-07.1" ], - "PS-1.0": [ - "PES-03", - "PES-03.1", - "PES-03.4", - "PES-04", - "PES-04.1", - "PES-12" + "AU-09": [ + "MON-08" ], - "PS-2.0": [ - "PES-04.2" + "AU-04(01)": [ + "MON-08.1" ], - "PS-1.4": [ - "PES-05", - "PES-05.1", - "PES-05.2" + "AU-09(02)": [ + "MON-08.1" ], - "PS-3.1": [ - "PES-07", - "PES-07.1", - "PES-07.2", - "PES-07.3", - "PES-07.4", - "PES-07.5", - "PES-08", - "PES-08.1", - "PES-09", - "PES-09.1" + "AU-09(04)": [ + "MON-08.2" ], - "TS-1.14": [ - "PRI-01.11", - "SEA-01" + "AU-09(03)": [ + "MON-08.3" ], - "OR-3.3": [ - "SAT-01", - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6", - "SAT-04" + "AU-10": [ + "MON-09" ], - "TS-1.18": [ - "TDA-04" + "AU-11": [ + "MON-10" ], - "TS-1.13": [ - "TDA-06", - "TDA-06.3", - "TDA-06.5", - "TDA-06.6", - "TDA-09" + "SI-04(22)": [ + "MON-11.2" ], - "TS-2.5": [ - "TDA-08" + "AC-02(12)": [ + "MON-16" ], - "TS-8.3": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3" + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" ], - "TS-4.2": [ - "TDA-17", - "THR-03", - "VPM-04.3", - "VPM-05", - "VPM-05.1" + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" ], - "TS-8.0": [ - "TDA-19" + "IA-07": [ + "CRY-02", + "IAC-12" ], - "TS-1.15": [ - "TDA-20", - "TDA-20.1", - "TDA-20.2", - "TDA-20.4" + "SC-08": [ + "CRY-03", + "CRY-04" ], - "OR-3.4": [ - "TPM-01", - "TPM-05", - "TPM-05.4", - "TPM-05.6", - "TPM-05.8", - "TPM-06", - "TPM-08" + "SC-28": [ + "CRY-05", + "END-02" ], - "PS-3.2": [ - "TPM-01", - "TPM-05", - "TPM-05.6", - "TPM-05.8" + "AC-18": [ + "CRY-07", + "NET-15" ], - "TS-4.0": [ - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-06" + "SC-12": [ + "CRY-08" ], - "TS-4.1": [ - "VPM-07" - ] - }, - "general-naic-insurance-data-security-model-law-668-2017": { - "3": [ - "SEA-02.1" + "SC-17": [ + "CRY-08" ], - "4.A": [ - "GOV-01" + "SC-12(01)": [ + "CRY-09.3" ], - "4.B": [ - "GOV-01" + "MP-02": [ + "DCH-03", + "END-01" ], - "4.B(1)": [ - "GOV-01" + "MP-03": [ + "DCH-04", + "DCH-04.1" ], - "4.B(2)": [ - "GOV-01" + "MP-04": [ + "DCH-06" ], - "4.B(3)": [ - "GOV-01" + "MP-05": [ + "DCH-07" ], - "4.B(4)": [ - "GOV-01", + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" + ], + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" + ], + "MP-06(01)": [ + "DCH-09.1" + ], + "MP-06(02)": [ + "DCH-09.2" + ], + "MP-07": [ + "DCH-10", + "DCH-10.2", "DCH-18" ], - "4.D(1)": [ - "GOV-01", - "RSK-01" + "AC-20": [ + "DCH-13" ], - "4.E(1)": [ - "GOV-01.1" + "AC-20(01)": [ + "DCH-13.1" ], - "4.E(2)": [ - "GOV-01.1" + "AC-20(02)": [ + "DCH-13.2" ], - "4.E(2)(a)": [ - "GOV-01.1" + "PM-17": [ + "DCH-13.3" ], - "4.E(2)(b)": [ - "GOV-01.1", - "GOV-16", - "GOV-16.1", - "GOV-16.2", - "CPL-01.1" + "CA-03(06)": [ + "DCH-14.2" ], - "4.E(3)": [ - "GOV-01.1" + "AC-22": [ + "DCH-15" ], - "4.C(1)": [ - "GOV-04" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "4.D(2)": [ - "GOV-09" + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" ], - "4.D(2)(g)": [ - "GOV-14", - "GOV-15", - "IAC-06" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "4.C(4)(b)": [ - "AST-01", - "DCH-01", - "NET-01" + "CM-12": [ + "DCH-24" ], - "4.D(2)(b)": [ - "AST-01", - "DCH-01", - "PES-01", - "PRM-01", - "PRM-02", - "SEA-01" + "CM-12(01)": [ + "DCH-24.1" ], - "4.C(4)(c)": [ - "BCD-01", - "IRO-01" + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "4.D(2)(f)": [ - "CHG-01" + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "4.I": [ - "CPL-01.5" + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" ], - "4.C(4)": [ - "CPL-02", - "CPL-03", - "CPL-03.2" + "SI-07(01)": [ + "END-06.1" ], - "4.C(5)": [ - "CPL-03", - "CPL-03.2", - "RSK-01", - "THR-01", - "THR-09", - "THR-10" + "SI-07(07)": [ + "END-06.2" ], - "4.D(2)(h)": [ - "MON-01" + "SI-07(02)": [ + "END-06.3" ], - "4.D(2)(i)": [ - "MON-03", - "MON-03.2" + "SI-07(05)": [ + "END-06.4" ], - "4.D(2)(d)": [ - "CRY-01", - "CRY-03", - "CRY-05" + "SI-08": [ + "END-08" ], - "4.D(2)(j)": [ - "DCH-01", - "PES-01", - "PES-07", - "PES-07.5", - "PES-08" + "SC-18": [ + "END-10" ], - "4.D(2)(k)": [ - "DCH-21" + "SC-41": [ + "END-12" ], - "4.C(4)(a)": [ - "HRS-01", + "SC-15": [ + "END-14" + ], + "SC-03": [ + "END-16", + "SEA-04.1" + ], + "PS-02": [ + "HRS-02", + "HRS-03.2" + ], + "PM-13": [ + "HRS-03", "SAT-01" ], - "4.D(2)(a)": [ - "IAC-01" + "PS-09": [ + "HRS-03" ], - "5.A": [ - "IRO-02" + "PS-03": [ + "HRS-04" ], - "5.B(1)": [ - "IRO-02" + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "5.B(2)": [ - "IRO-02" + "PL-04(01)": [ + "HRS-05.2" ], - "5.B(3)": [ - "IRO-02" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "5.B(4)": [ - "IRO-02" + "PS-08": [ + "HRS-07" ], - "5.C": [ - "IRO-02" + "PS-05": [ + "HRS-08" ], - "5.D": [ - "IRO-02" + "PS-04": [ + "HRS-09" ], - "6.D(1)": [ - "IRO-02" + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" ], - "6.D(2)": [ - "IRO-02", - "IRO-10.2" + "PS-04(02)": [ + "HRS-09.4" ], - "4.H(1)": [ - "IRO-04" + "PS-07": [ + "HRS-10" ], - "4.H(2)": [ - "IRO-04" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "4.H(2)(a)": [ - "IRO-04" + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "4.H(2)(b)": [ - "IRO-04" + "IA-02": [ + "IAC-02" ], - "4.H(2)(c)": [ - "IRO-04" + "IA-02(05)": [ + "IAC-02.1" ], - "4.H(2)(d)": [ - "IRO-04" + "IA-02(08)": [ + "IAC-02.2" ], - "4.H(2)(e)": [ - "IRO-04" + "IA-02(12)": [ + "IAC-02.3" ], - "4.H(2)(f)": [ - "IRO-04" + "IA-08": [ + "IAC-03" ], - "4.H(2)(g)": [ - "IRO-04" + "IA-08(01)": [ + "IAC-03.1" ], - "6.C": [ - "IRO-04.1" + "IA-08(02)": [ + "IAC-03.2" ], - "6.E(1)(a)": [ - "IRO-10" + "IA-08(04)": [ + "IAC-03.3" ], - "6.E(1)(b)": [ - "IRO-10" + "IA-03": [ + "IAC-04" ], - "6.A": [ - "IRO-10.2" + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "6.A(1)": [ - "IRO-10.2" + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "6.A(2)": [ - "IRO-10.2" + "IA-12(04)": [ + "IAC-07", + "IAC-10.3", + "IAC-28.4" ], - "6.A(2)(a)": [ - "IRO-10.2" + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "6.A(2)(b)": [ - "IRO-10.2" + "IA-05": [ + "IAC-10", + "IAC-10.8" ], - "6.A(2)(b)(i)": [ - "IRO-10.2" + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "6.A(2)(b)(ii)": [ - "IRO-10.2" + "IA-05(02)": [ + "IAC-10.2" ], - "6.B": [ - "IRO-10.2" + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" ], - "6.B(1)": [ - "IRO-10.2" + "IA-06": [ + "IAC-11" ], - "6.B(2)": [ - "IRO-10.2" + "IA-11": [ + "IAC-14" ], - "6.B(3)": [ - "IRO-10.2" + "AC-02(01)": [ + "IAC-15.1" ], - "6.B(4)": [ - "IRO-10.2" + "AC-02(02)": [ + "IAC-15.2" ], - "6.B(5)": [ - "IRO-10.2" + "AC-02(03)": [ + "IAC-15.3" ], - "6.B(6)": [ - "IRO-10.2" + "AC-02(04)": [ + "IAC-15.4" ], - "6.B(7)": [ - "IRO-10.2" + "AC-02(11)": [ + "IAC-15.8" ], - "6.B(8)": [ - "IRO-10.2" + "AC-06(07)": [ + "IAC-17" ], - "6.B(9)": [ - "IRO-10.2" + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "6.B(10)": [ - "IRO-10.2" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "6.B(11)": [ - "IRO-10.2" + "AC-06(01)": [ + "IAC-21.1" ], - "6.B(12)": [ - "IRO-10.2" + "AC-06(02)": [ + "IAC-21.2" ], - "6.B(13)": [ - "IRO-10.2" + "AC-06(05)": [ + "IAC-21.3" ], - "6.E(2)(a)": [ - "IRO-10.2" + "AC-06(09)": [ + "IAC-21.4" ], - "6.E(2)(b)": [ - "IRO-10.2" + "AC-06(10)": [ + "IAC-21.5" ], - "6.F": [ - "IRO-10.2" + "AC-07": [ + "IAC-22" ], - "4.D(2)(c)": [ - "PES-01", - "PES-02" + "AC-10": [ + "IAC-23" ], - "4.D(3)": [ - "RSK-01" + "AC-02(05)": [ + "IAC-24" ], - "4.D(5)": [ - "SAT-02", - "SAT-03" + "AC-11": [ + "IAC-24" ], - "4.D(2)(e)": [ - "TDA-01", - "TDA-06" + "AC-11(01)": [ + "IAC-24.1" ], - "4.F(1)": [ - "TPM-01" + "AC-12": [ + "IAC-25" ], - "4.F(2)": [ - "TPM-05" + "AC-14": [ + "IAC-26" ], - "4.G": [ - "TPM-08" + "IA-12": [ + "IAC-28" ], - "4.D(4)": [ - "THR-01", - "VPM-01" + "IA-12(01)": [ + "IAC-28.1" ], - "4.C(2)": [ - "THR-09", - "THR-10" + "IA-12(02)": [ + "IAC-28.2" ], - "4.C(3)": [ - "THR-10" - ] - }, - "general-nist-100-1-ai-rmf": { - "GOVERN 2.3": [ - "GOV-01.1", - "GOV-01.2", - "GOV-04" + "IA-12(03)": [ + "IAC-28.3" ], - "MAP 3.5": [ - "GOV-01.1", - "GOV-01.2", - "GOV-02", - "AAT-01", - "OPS-01", - "OPS-01.1" + "IA-12(05)": [ + "IAC-28.5" ], - "MAP 5.2": [ - "GOV-01.1", - "GOV-05", - "AAT-01", - "AAT-11" + "IR-04": [ + "IRO-02" ], - "GOVERN 1.0": [ - "GOV-02", - "AAT-01", - "OPS-01.1" + "IR-04(01)": [ + "IRO-02.1" ], - "GOVERN 1.2": [ - "GOV-02", - "AAT-01.2", - "SEA-01", - "SEA-01.1", - "OPS-01", - "OPS-01.1", - "TDA-01", - "TDA-01.1" + "IR-08": [ + "IRO-04" ], - "GOVERN 1.3": [ - "GOV-02", - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "CPL-01.2", - "RSK-01", - "RSK-01.1", - "RSK-01.2", - "RSK-01.3", - "OPS-01", - "OPS-01.1" + "IR-02": [ + "IRO-05" ], - "GOVERN 1.4": [ - "GOV-02", - "RSK-01", - "RSK-01.1", - "RSK-01.2", - "OPS-01", - "OPS-01.1" + "IR-02(01)": [ + "IRO-05.1" ], - "GOVERN 3.2": [ - "GOV-02", - "AAT-08", - "OPS-01", - "OPS-01.1" + "IR-02(02)": [ + "IRO-05.2" ], - "GOVERN 4.1": [ - "GOV-02", - "AAT-01", - "HRS-01", - "HRS-03.1", - "HRS-03.2", - "HRS-04.1", - "HRS-05.1", - "HRS-05.4", - "OPS-01", - "OPS-01.1", - "SAT-01", - "TDA-01.1", - "TDA-02.3" + "IR-03": [ + "IRO-06" ], - "GOVERN 5.1": [ - "GOV-02", - "AAT-11.1", - "OPS-01", - "OPS-01.1", - "TDA-01.1" + "IR-03(02)": [ + "IRO-06.1" ], - "GOVERN 6.0": [ - "GOV-02", - "RSK-09.2", - "OPS-01", - "OPS-01.1", - "TDA-01.1" + "IR-04(11)": [ + "IRO-07" ], - "GOVERN 6.1": [ - "GOV-02", - "AAT-12", - "OPS-01", - "OPS-01.1" + "IR-05": [ + "IRO-09" ], - "GOVERN 2.1": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "AAT-01", - "AAT-08", - "HRS-03" + "IR-05(01)": [ + "IRO-09.1" + ], + "IR-06(01)": [ + "IRO-10.1" + ], + "IR-06(03)": [ + "IRO-10.4" + ], + "IR-07": [ + "IRO-11" + ], + "IR-07(01)": [ + "IRO-11.1" + ], + "PM-10": [ + "IAO-01" ], - "GOVERN 5.0": [ - "GOV-04", - "GOV-04.1", - "AAT-11", - "AST-01.2", - "CHG-05" + "CA-02(01)": [ + "IAO-02.1" ], - "GOVERN 2.0": [ - "GOV-04.1", - "AST-01", - "AST-01.2", - "HRS-03", - "HRS-04.1", - "HRS-05.1", - "HRS-05.4", - "SAT-01", - "SAT-03" + "CA-02(02)": [ + "IAO-02.2" ], - "MANAGE 2.4": [ - "GOV-04.1", - "AAT-15.2", - "IRO-01", - "IRO-02", - "RSK-06.1" + "CA-05": [ + "IAO-05" ], - "GOVERN 1.5": [ - "GOV-05", - "CPL-02", - "CPL-03", - "CPL-04", - "RSK-01", - "RSK-04", - "RSK-04.1", - "RSK-08" + "PM-04": [ + "IAO-05", + "VPM-02" ], - "MEASURE 1.0": [ - "GOV-05", - "AAT-16.2" + "CM-04(02)": [ + "IAO-06" ], - "MEASURE 1.1": [ - "GOV-05", - "AAT-16.2", - "AAT-16.3" + "CA-06": [ + "IAO-07" ], - "MEASURE 1.2": [ - "GOV-05", - "AAT-16.2" + "MA-02": [ + "MNT-02" ], - "MEASURE 4.0": [ - "GOV-05", - "AAT-16.4" + "MA-02(02)": [ + "MNT-02.1" ], - "MEASURE 4.3": [ - "GOV-05", - "GOV-05.1", - "GOV-05.2", - "AAT-16.6" + "MA-06": [ + "MNT-03" ], - "MEASURE 4.1": [ - "GOV-05.1", - "GOV-05.2", - "AAT-16.1" + "MA-03": [ + "MNT-04" ], - "MAP 1.3": [ - "GOV-08", - "AAT-03.1", - "PRM-01.1" + "MA-03(01)": [ + "MNT-04.1" ], - "GOVERN 4.0": [ - "GOV-14", - "GOV-15", - "RSK-12" + "MA-03(02)": [ + "MNT-04.2" ], - "GOVERN 1.1": [ - "AAT-01.1", - "AST-01.2", - "CPL-01", - "CPL-01.2" + "MA-03(03)": [ + "MNT-04.3" ], - "MEASURE 2.5": [ - "AAT-01.2", - "AAT-10.9" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "MANAGE 2.2": [ - "AAT-01.3", - "PRM-01", - "PRM-07", - "TDA-01.1" + "MA-04(01)": [ + "MNT-05.1" ], - "GOVERN 1.6": [ - "AAT-02", - "AST-02", - "BCD-02", - "DCH-02" + "MA-04(03)": [ + "MNT-05.6" ], - "MAP 4.1": [ - "AAT-02.1" + "MA-05": [ + "MNT-06" ], - "MAP 4.2": [ - "AAT-02.2" + "MA-05(01)": [ + "MNT-06.1" ], - "MAP 1.0": [ - "AAT-03", - "PRM-06" + "SR-11(02)": [ + "MNT-07" ], - "MAP 1.1": [ - "AAT-03", - "AAT-04", - "PRM-06", - "RSK-08", - "RSK-10" + "MA-07": [ + "MNT-08" ], - "MAP 1.4": [ - "AAT-03", - "AAT-03.1", - "PRM-06" + "AC-19": [ + "MDM-02" ], - "MAP 3.0": [ - "AAT-03", - "AAT-03.1", - "AAT-04" + "AC-19(05)": [ + "MDM-03" ], - "MAP 3.1": [ - "AAT-04", - "AAT-04.1" + "SC-07": [ + "NET-03" ], - "MAP 3.2": [ - "AAT-04", - "AAT-04.2", - "RSK-01.3" + "SC-07(03)": [ + "NET-03.1" ], - "MAP 3.3": [ - "AAT-04.3", - "CPL-01.2" + "SC-07(04)": [ + "NET-03.2" ], - "MAP 4.0": [ - "AAT-04.4" + "SC-07(21)": [ + "NET-03.7" ], - "GOVERN 3.0": [ - "AAT-06" + "AC-04": [ + "NET-04" ], - "GOVERN 3.1": [ - "AAT-07", - "TDA-01", - "TDA-01.1" + "SC-07(05)": [ + "NET-04.1" ], - "MAP 5.0": [ - "AAT-07.1" + "AC-04(04)": [ + "NET-04.3" ], - "MAP 5.1": [ - "AAT-07.2", - "RSK-02.1", - "RSK-08" + "CA-03": [ + "NET-05" ], - "MANAGE 2.0": [ - "AAT-07.3", - "TDA-01", - "TDA-01.1" + "CA-09": [ + "NET-05.2" ], - "MAP 1.2": [ - "AAT-08", - "AAT-13", - "HRS-03.2" + "SC-07(28)": [ + "NET-06.5" ], - "GOVERN 4.2": [ - "AAT-09", - "TDA-01", - "TDA-01.1", - "TDA-02.3", - "TDA-04", - "TDA-05" + "SC-23": [ + "NET-09" ], - "GOVERN 4.3": [ - "AAT-10", - "IAO-01" + "SC-20": [ + "NET-10" ], - "MEASURE 2.2": [ - "AAT-10", - "AAT-17", - "AAT-17.1" + "SC-22": [ + "NET-10.1" ], - "MEASURE 2.0": [ - "AAT-10.1", - "AAT-10.3", - "IAO-02", - "IAO-06" + "SC-21": [ + "NET-10.2" ], - "MAP 2.3": [ - "AAT-10.2", - "IAO-02.2" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "MEASURE 2.1": [ - "AAT-10.2" + "SI-10": [ + "NET-12", + "TDA-18" ], - "MEASURE 2.6": [ - "AAT-10.4", - "AAT-10.13", - "AAT-11.2" + "AC-17": [ + "NET-14" ], - "MEASURE 2.7": [ - "AAT-10.5", - "SEA-01.2" + "AC-17(01)": [ + "NET-14.1" ], - "MEASURE 2.8": [ - "AAT-10.6" + "AC-17(02)": [ + "NET-14.2" ], - "MEASURE 2.10": [ - "AAT-10.7", - "RSK-10" + "AC-17(03)": [ + "NET-14.3" ], - "MEASURE 2.11": [ - "AAT-10.8" + "AC-17(04)": [ + "NET-14.4" ], - "MEASURE 2.9": [ - "AAT-10.9" + "AC-17(09)": [ + "NET-14.8" ], - "MEASURE 2.13": [ - "AAT-10.10", - "AAT-10.11" + "AC-18(01)": [ + "NET-15.1" ], - "MANAGE 1.1": [ - "AAT-10.10", - "AAT-15", - "AAT-15.1", - "AAT-15.2", - "IAO-01", - "IAO-05", - "IAO-07" + "AC-18(03)": [ + "NET-15.2" ], - "MEASURE 2.3": [ - "AAT-10.12" + "AC-18(04)": [ + "NET-15.3" ], - "MEASURE 2.4": [ - "AAT-10.13", - "AAT-16" + "AC-18(05)": [ + "NET-15.4" ], - "MANAGE 4.1": [ - "AAT-10.13", - "AAT-11.1", - "AAT-11.2", - "AAT-11.3" + "SC-07(08)": [ + "NET-18", + "NET-18.1" ], - "MANAGE 4.2": [ - "AAT-10.14" + "SI-04(10)": [ + "NET-18.2" ], - "GOVERN 5.2": [ - "AAT-11.1", - "TDA-01.1" + "PE-02": [ + "PES-02" ], - "MEASURE 1.3": [ - "AAT-11.2" + "PE-03": [ + "PES-03" ], - "MEASURE 3.3": [ - "AAT-11.3" + "PE-08": [ + "PES-03.3" ], - "MANAGE 4.3": [ - "AAT-11.4", - "IRO-10" + "PE-03(01)": [ + "PES-03.4" ], - "MAP 3.4": [ - "AAT-13.1", - "HRS-03.2" + "PE-06": [ + "PES-05" ], - "MAP 1.6": [ - "AAT-14", - "PRI-01", - "PRI-05.4", - "PRM-05" + "PE-06(01)": [ + "PES-05.1" ], - "MAP 2.1": [ - "AAT-14.1", - "PRM-06", - "TDA-01.1" + "PE-06(04)": [ + "PES-05.2" ], - "MAP 2.2": [ - "AAT-14.2" + "PE-08(01)": [ + "PES-06.4" ], - "MANAGE 1.2": [ - "AAT-15.1", - "AAT-15.2", - "IAO-05", - "RSK-02.1", - "RSK-05", - "RSK-06" + "PE-09": [ + "PES-07" ], - "MANAGE 1.4": [ - "AAT-15.1", - "IAO-05", - "RSK-04.1" + "PE-10": [ + "PES-07.2" ], - "MEASURE 3.0": [ - "AAT-16.2", - "IAO-05", - "RSK-04.1" + "PE-11": [ + "PES-07.3" ], - "MEASURE 4.2": [ - "AAT-16.5" + "PE-11(01)": [ + "PES-07.3" ], - "MANAGE 3.2": [ - "AAT-16.7" + "PE-12": [ + "PES-07.4" ], - "MEASURE 3.1": [ - "AAT-17", - "IAO-02.2", - "IAO-05", - "RSK-04.1" + "PE-15": [ + "PES-07.5" ], - "MEASURE 2.12": [ - "AAT-17.2" + "PE-15(01)": [ + "PES-07.6" ], - "MANAGE 2.3": [ - "AAT-17.3", - "IRO-01", - "IRO-02", - "RSK-03", - "RSK-06.1" + "PE-13": [ + "PES-08" ], - "MEASURE 3.2": [ - "AAT-18", - "IAO-02.2", - "IAO-05", - "RSK-04.1" + "PE-13(01)": [ + "PES-08.1" ], - "MANAGE 1.0": [ - "AAT-18.1", - "RSK-01", - "RSK-03", - "RSK-04" + "PE-13(02)": [ + "PES-08.3" ], - "GOVERN 1.7": [ - "AST-09", - "AST-30", - "PRM-07", - "SEA-02.3", - "TDA-17" + "PE-14": [ + "PES-09" ], - "MAP 2.0": [ - "AST-31", - "AST-31.1" + "PE-16": [ + "PES-10" ], - "GOVERN 6.2": [ - "BCD-01", - "BCD-16", - "IRO-01", - "IRO-02", - "IRO-02.4", - "IRO-04" + "PE-17": [ + "PES-11" ], - "MANAGE 4.0": [ - "IRO-04", - "IAO-03", - "IAO-05", - "RSK-06", - "RSK-06.1" + "PE-18": [ + "PES-12" ], - "MANAGE 1.3": [ - "IAO-05", - "RSK-06.1" + "PE-04": [ + "PES-12.1" ], - "MANAGE 3.1": [ - "IAO-05", - "RSK-09.1", - "RSK-09.2", - "TPM-04.1", - "TPM-08" + "PE-05": [ + "PES-12.2" ], - "MANAGE 2.1": [ - "PRM-01", - "PRM-02", - "PRM-03", - "RSK-01.2", - "RSK-06.2" + "PM-18": [ + "PRI-01" ], - "MAP 1.5": [ - "RSK-01.3" + "PM-19": [ + "PRI-01.1" ], - "MANAGE 3.0": [ - "RSK-09", - "RSK-09.2", - "TPM-01", - "TPM-08" + "PM-20": [ + "PRI-01.3" ], - "GOVERN 2.2": [ - "SAT-03", - "SAT-03.5", - "SAT-03.6" - ] - }, - "general-nist-600-1-gen-ai-profile": { - "GOVERN 1.1": [ - "GOV-01", - "CPL-01" + "PM-20(01)": [ + "PRI-02" ], - "GOVERN 1.2": [ - "GOV-01", - "AAT-01", - "OPS-01.1" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "GV-1.2-002": [ - "GOV-01", - "AAT-01" + "AC-21": [ + "PRI-07" ], - "GV-1.4-001": [ - "GOV-01" + "PM-27": [ + "PRI-14" ], - "GV-1.4-002": [ - "GOV-01" + "PM-21": [ + "PRI-14.1" ], - "GOVERN 4.1": [ - "GOV-01", - "AAT-01" + "PM-03": [ + "PRM-02" ], - "GV-1.3-004": [ - "GOV-01.1" + "SA-02": [ + "PRM-03" ], - "GV-1.5-002": [ - "GOV-02", - "AAT-01", - "OPS-01.1" + "PM-11": [ + "PRM-06" ], - "GV-1.3-002": [ - "GOV-05", - "GOV-05.1" + "SA-03": [ + "PRM-07", + "SEA-07.1" ], - "MS-2.7-004": [ - "GOV-05" + "PM-09": [ + "RSK-01" ], - "GV-2.1-004": [ - "GOV-06", - "AAT-01", - "AAT-09.1", - "AAT-16.9" + "PM-28": [ + "RSK-01.1" ], - "GV-1.2-001": [ - "AAT-01" + "RA-02": [ + "RSK-02" ], - "GV-1.3-005": [ - "AAT-01", - "AAT-02.1" + "RA-07": [ + "RSK-06.1" ], - "GV-1.5-003": [ - "AAT-01", - "AAT-10", - "DCH-18" + "PM-30": [ + "RSK-09" ], - "GOVERN 1.7": [ - "AAT-01", - "AST-30" + "SR-02": [ + "RSK-09", + "TPM-03" ], - "GV-1.7-001": [ - "AAT-01" + "RA-03(01)": [ + "RSK-09.1" ], - "GV-2.1-001": [ - "AAT-01", - "AAT-08" + "CA-07(04)": [ + "RSK-11" ], - "GV-2.1-002": [ - "AAT-01", - "AAT-08" + "SC-07(18)": [ + "SEA-01" ], - "GV-3.2-001": [ - "AAT-01" + "PL-08": [ + "SEA-02" ], - "GV-3.2-003": [ - "AAT-01", - "TDA-21" + "PM-07": [ + "SEA-02" ], - "GV-3.2-004": [ - "AAT-01", - "AAT-11.3" + "SC-02": [ + "SEA-03.2" ], - "GV-4.1-001": [ - "AAT-01" + "SC-39": [ + "SEA-04" ], - "GV-4.1-002": [ - "AAT-01", - "AAT-02.1", - "AAT-07.2", - "AAT-15", - "AAT-15.2" + "SC-04": [ + "SEA-05" ], - "GV-4.1-003": [ - "AAT-01", - "AAT-11" + "CM-07(02)": [ + "SEA-06" ], - "GV-4.3-002": [ - "AAT-01", - "AAT-16.8", - "AAT-16.9", - "MON-01" + "CP-12": [ + "SEA-07.2" ], - "GOVERN 6.1": [ - "AAT-01", - "AAT-12" + "SC-24": [ + "SEA-07.2" ], - "GV-6.1-009": [ - "AAT-01", - "TPM-01", - "TPM-04.1" + "SI-17": [ + "SEA-07.3" ], - "GOVERN 6.2": [ - "AAT-01", - "AAT-10", - "AAT-11.4" + "SI-16": [ + "SEA-10" ], - "GV-6.2-005": [ - "AAT-01", - "AAT-09", - "TDA-01.1" + "AC-08": [ + "SEA-18" ], - "MP-3.4-003": [ - "AAT-01", - "CPL-01.4", - "TDA-01.1" + "AT-02": [ + "SAT-02" ], - "MAP 4.1": [ - "AAT-01", - "AAT-02.1" + "AT-02(03)": [ + "SAT-02.2" ], - "MP-4.1-003": [ - "AAT-01", - "TDA-22" + "AT-03": [ + "SAT-03" ], - "MP-4.1-005": [ - "AAT-01", - "AAT-10.8" + "AT-02(04)": [ + "SAT-03.2" ], - "MS-2.5-006": [ - "AAT-01" + "AT-04": [ + "SAT-04" ], - "MG-2.3-001": [ - "AAT-01", - "BCD-01", - "IRO-04" + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "MG-4.1-003": [ - "AAT-01", - "AAT-10" + "SA-04(09)": [ + "TDA-02.1" ], - "MS-2.9-002": [ - "AAT-01.1", - "AAT-04.1", - "AAT-10", - "AAT-20.2" + "SA-04(10)": [ + "TDA-02.2" ], - "MANAGE 2.2": [ - "AAT-01.3" + "SA-04(05)": [ + "TDA-02.4" ], - "GOVERN 1.6": [ - "AAT-02", - "AST-02" + "SA-17": [ + "TDA-05" ], - "GV-1.6-001": [ - "AAT-02", - "AST-02" + "SA-15": [ + "TDA-06" ], - "GV-1.6-002": [ - "AAT-02", - "AST-02" + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" ], - "MANAGE 3.1": [ - "AAT-02", - "AAT-04.4" + "SA-15(03)": [ + "TDA-06.1" ], - "GV-4.2-002": [ - "AAT-02.1", - "AAT-09", - "AAT-11", - "AAT-11.3", - "RSK-03" + "CM-04(01)": [ + "TDA-08" ], - "MP-1.1-004": [ - "AAT-02.1", - "AAT-09", - "AAT-27", - "TDA-01.1" + "SA-11": [ + "TDA-09" ], - "MG-3.1-001": [ - "AAT-02.3" + "SR-11": [ + "TDA-11" ], - "MAP 1.1": [ - "AAT-03" + "SR-11(01)": [ + "TDA-11.1" ], - "MP-1.1-001": [ - "AAT-03" + "SA-21": [ + "TDA-13" ], - "MP-1.1-002": [ - "AAT-03", - "AAT-07.2" + "SA-10": [ + "TDA-14" ], - "GV-2.1-003": [ - "AAT-05" + "SA-16": [ + "TDA-16" ], - "MS-3.3-004": [ - "AAT-05" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "MS-2.2-001": [ - "AAT-06", - "AAT-10.8", - "AAT-12.1" + "SI-11": [ + "TDA-19" ], - "MS-2.11-001": [ - "AAT-06", - "AAT-10.8", - "AAT-26" + "RA-09": [ + "TPM-02" ], - "MS-3.3-003": [ - "AAT-06" + "SR-02(01)": [ + "TPM-03" ], - "GOVERN 1.4": [ - "AAT-07", - "RSK-01" + "SR-05": [ + "TPM-03.1" ], - "MP-1.1-003": [ - "AAT-07", - "AAT-09" + "SR-03": [ + "TPM-03.3" ], - "MAP 1.2": [ - "AAT-07" + "SR-05(01)": [ + "TPM-03.4" ], - "MP-1.2-001": [ - "AAT-07" + "SA-09": [ + "TPM-04" ], - "MP-5.1-002": [ - "AAT-07", - "AAT-07.2", - "AAT-10.17", - "AAT-12.1", - "AAT-12.3" + "SA-09(02)": [ + "TPM-04.2" ], - "MEASURE 1.1": [ - "AAT-07", - "AAT-16.4" + "SR-08": [ + "TPM-05.1" ], - "MS-2.8-001": [ - "AAT-07", - "AAT-12" + "SR-06": [ + "TPM-08" ], - "MS-2.11-003": [ - "AAT-07" + "PM-16": [ + "THR-01" ], - "MEASURE 3.2": [ - "AAT-07" + "PM-12": [ + "THR-04" ], - "MS-3.2-001": [ - "AAT-07" + "AT-02(02)": [ + "THR-05" ], - "MANAGE 1.3": [ - "AAT-07", - "AAT-09" + "RA-05(11)": [ + "THR-06" ], - "GV-4.2-003": [ - "AAT-07.1" + "SI-02(02)": [ + "VPM-05.2" ], - "MAP 5.1": [ - "AAT-07.1", - "AAT-07.2" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "MP-5.2-001": [ - "AAT-07.1", - "AAT-07.2", - "AAT-18" + "RA-05(02)": [ + "VPM-06.1" ], - "MP-5.2-002": [ - "AAT-07.1", - "AAT-11" + "RA-05(05)": [ + "VPM-06.3" ], - "MS-1.3-002": [ - "AAT-07.1", - "AAT-10", - "AAT-11", - "VPM-10" + "RA-05(04)": [ + "VPM-06.8" ], - "MS-3.3-001": [ - "AAT-07.1" + "CA-08": [ + "VPM-07" + ] + }, + "general-nist-800-160-vol-2-r1": { + "PM-32": [ + "GOV-11" ], - "GOVERN 4.2": [ - "AAT-07.2", - "AAT-09" + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" ], - "GV-5.1-002": [ - "AAT-07.2" + "SR-04": [ + "AST-03.2" ], - "MP-4.1-008": [ - "AAT-07.2", - "AAT-10" + "SR-04(01)": [ + "AST-03.2" ], - "MP-5.1-006": [ - "AAT-07.2" + "SR-04(02)": [ + "AST-03.2" ], - "MANAGE 4.2": [ - "AAT-07.3" + "SR-09": [ + "AST-15" ], - "MG-4.2-001": [ - "AAT-07.3" + "SR-09(01)": [ + "AST-15" ], - "GOVERN 1.5": [ - "AAT-08", - "HRS-03" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "GV-1.5-001": [ - "AAT-08", - "AAT-12.1", - "HRS-03" + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" ], - "GOVERN 2.1": [ - "AAT-08" + "CP-02(01)": [ + "BCD-01.1" ], - "GOVERN 3.2": [ - "AAT-08" + "CP-02(08)": [ + "BCD-02" ], - "MP-3.4-005": [ - "AAT-08" + "CP-02(05)": [ + "BCD-02.2" ], - "GV-1.3-003": [ - "AAT-10" + "CP-13": [ + "BCD-07" ], - "GOVERN 4.3": [ - "AAT-10" + "CP-11": [ + "BCD-10" ], - "GV-4.3-003": [ - "AAT-10", - "AAT-11" + "CP-08(03)": [ + "BCD-10.2" ], - "MAP 2.3": [ - "AAT-10", - "AAT-12.2" + "SC-47": [ + "BCD-10.4" ], - "MP-2.3-005": [ - "AAT-10" + "CP-09": [ + "BCD-11" ], - "MP-4.1-007": [ - "AAT-10" + "CP-09(01)": [ + "BCD-11.1" ], - "MP-5.1-001": [ - "AAT-10" + "CP-09(08)": [ + "BCD-11.4" ], - "MS-2.6-003": [ - "AAT-10", - "AAT-10.10" + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" ], - "MEASURE 2.9": [ - "AAT-10", - "AAT-20.1" + "CP-09(06)": [ + "BCD-11.7" ], - "MEASURE 2.13": [ - "AAT-10" + "CP-09(07)": [ + "BCD-11.8" ], - "MS-4.2-001": [ - "AAT-10", - "AAT-26" + "SC-05(03)": [ + "CAP-01" ], - "MG-2.2-007": [ - "AAT-10" + "SC-05(02)": [ + "CAP-02", + "CAP-03" ], - "MG-3.1-002": [ - "AAT-10" + "SA-08(31)": [ + "CHG-02", + "CHG-02.2", + "CHG-06" ], - "MAP 3.4": [ - "AAT-10.1" + "CM-14": [ + "CHG-04.2" ], - "MEASURE 4.2": [ - "AAT-10.1" + "SI-07(15)": [ + "CHG-04.2" ], - "MG-3.1-003": [ - "AAT-10.1", - "AAT-11.2" + "CM-05(04)": [ + "CHG-04.3" ], - "MANAGE 4.1": [ - "AAT-10.1", - "AAT-16.5", - "AAT-16.8" + "CM-05(05)": [ + "CHG-04.4" ], - "MS-1.1-003": [ - "AAT-10.2" + "CM-05(06)": [ + "CHG-04.5" ], - "MEASURE 2.5": [ - "AAT-10.3" + "SI-06": [ + "CHG-06" ], - "GV-1.3-006": [ - "AAT-10.4" + "SC-07(29)": [ + "CLD-03", + "NET-03.8", + "NET-06.1" ], - "MG-1.3-001": [ - "AAT-10.4", - "AAT-15.1" + "SA-15(05)": [ + "CFG-02", + "SEA-01" ], - "MG-2.2-001": [ - "AAT-10.4" + "CM-02(07)": [ + "CFG-02.5" ], - "MG-3.2-009": [ - "AAT-10.4" + "CM-07(06)": [ + "CFG-02.5" ], - "MEASURE 2.7": [ - "AAT-10.5" + "CM-07(07)": [ + "CFG-02.5" ], - "MS-2.7-001": [ - "AAT-10.5" + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" + ], + "CM-07(04)": [ + "CFG-03.3" + ], + "CM-07(05)": [ + "CFG-03.3" ], - "MEASURE 2.8": [ - "AAT-10.6" + "AC-03(11)": [ + "CFG-08" ], - "MG-4.1-005": [ - "AAT-10.6" + "PM-31": [ + "MON-01" ], - "MEASURE 2.10": [ - "AAT-10.7" + "SI-04(01)": [ + "MON-01.1" ], - "MEASURE 2.11": [ - "AAT-10.8" + "SI-04(25)": [ + "MON-01.1", + "NET-03.1" ], - "MS-2.11-002": [ - "AAT-10.8" + "SC-48": [ + "MON-01.2", + "THR-07" ], - "MS-2.11-004": [ - "AAT-10.8" + "SI-04(02)": [ + "MON-01.2" ], - "MS-3.3-005": [ - "AAT-10.8", - "AAT-11" + "SI-04(04)": [ + "MON-01.3" ], - "MG-2.2-004": [ - "AAT-10.8" + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" ], - "MG-3.2-003": [ - "AAT-10.8" + "SI-04(07)": [ + "MON-01.11", + "IRO-02.1" ], - "MG-4.1-002": [ - "AAT-10.11" + "SI-04(13)": [ + "MON-01.13" ], - "MP-2.3-002": [ - "AAT-10.13" + "AU-06": [ + "MON-02", + "MON-02.6" ], - "MP-4.1-001": [ - "AAT-10.13", - "PRI-01.6" + "IR-04(04)": [ + "MON-02", + "MON-02.1" ], - "MS-1.1-006": [ - "AAT-10.13", - "AAT-11" + "AU-06(03)": [ + "MON-02.1" ], - "MANAGE 3.2": [ - "AAT-10.13" + "AU-06(09)": [ + "MON-02.1" ], - "MG-4.1-007": [ - "AAT-10.13" + "SI-04(16)": [ + "MON-02.1" ], - "MS-2.3-003": [ - "AAT-10.15" + "AU-06(05)": [ + "MON-02.3" ], - "MS-2.3-002": [ - "AAT-10.16" + "SI-04(17)": [ + "MON-02.3" ], - "MS-2.5-001": [ - "AAT-10.16" + "AU-06(06)": [ + "MON-02.4" ], - "GV-6.1-003": [ - "AAT-10.17", - "AAT-12.1" + "AU-06(08)": [ + "MON-03.3" ], - "MS-1.1-002": [ - "AAT-10.17", - "AAT-26", - "MON-16" + "CA-07(03)": [ + "MON-06.2" ], - "MS-2.7-002": [ - "AAT-10.17" + "AU-09(02)": [ + "MON-08.1" ], - "MS-2.7-005": [ - "AAT-10.17", - "AAT-12.2" + "AU-09(03)": [ + "MON-08.3" ], - "MS-2.10-003": [ - "AAT-10.18", - "AAT-12.1" + "AU-09(05)": [ + "MON-08.4" ], - "MS-2.11-005": [ - "AAT-10.18" + "AU-10(02)": [ + "MON-09.1" ], - "GV-4.2-001": [ - "AAT-11", - "HRS-05.4" + "AU-13": [ + "MON-11" ], - "GOVERN 5.1": [ - "AAT-11" + "SI-04(18)": [ + "MON-11.1", + "NET-17" ], - "GV-5.1-001": [ - "AAT-11", - "AAT-11.1", - "AAT-11.3" + "AC-02(12)": [ + "MON-16" ], - "MP-5.1-004": [ - "AAT-11", - "AAT-11.3" + "IR-04(13)": [ + "MON-16", + "SEA-11", + "SEA-12" ], - "MAP 5.2": [ - "AAT-11" + "SI-04(11)": [ + "MON-16" ], - "MS-1.1-007": [ - "AAT-11", - "AAT-12.2" + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" ], - "MS-1.1-008": [ - "AAT-11", - "AAT-26.3", - "TDA-01.1", - "TDA-21", - "VPM-10" + "SI-07(06)": [ + "CRY-01" ], - "MS-1.3-001": [ - "AAT-11" + "SC-08(04)": [ + "CRY-01.4" ], - "MG-2.4-001": [ - "AAT-11" + "SC-16(01)": [ + "CRY-04", + "CRY-10" ], - "MP-1.2-002": [ - "AAT-11.1", - "AAT-11.3" + "AC-23": [ + "DCH-16", + "PRI-05.4" ], - "MEASURE 1.3": [ - "AAT-11.1" + "SI-19(04)": [ + "DCH-23.4", + "PRI-05.3" ], - "MS-2.10-002": [ - "AAT-11.1", - "AAT-11.3" + "SI-19(06)": [ + "DCH-23.6" ], - "MS-4.2-005": [ - "AAT-11.1", - "AAT-11.3" + "SI-19(08)": [ + "DCH-23.8" ], - "MG-2.2-006": [ - "AAT-11.1", - "AAT-11.3" + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" ], - "MG-3.2-007": [ - "AAT-11.1" + "SI-07(01)": [ + "END-06.1" ], - "MS-2.7-009": [ - "AAT-11.2" + "SI-07(07)": [ + "END-06.2" ], - "MS-1.1-004": [ - "AAT-11.3" + "SI-07(05)": [ + "END-06.4" ], - "MS-2.7-003": [ - "AAT-11.3" + "SI-07(09)": [ + "END-06.5" ], - "MEASURE 3.3": [ - "AAT-11.3" + "SI-07(10)": [ + "END-06.6" ], - "MG-2.2-008": [ - "AAT-11.3" + "SC-11": [ + "END-09" ], - "MG-3.2-004": [ - "AAT-11.3" + "SC-27": [ + "END-10" ], - "MANAGE 4.3": [ - "AAT-11.4" + "SC-25": [ + "END-11" ], - "GV-6.1-001": [ - "AAT-12", - "AAT-12.1" + "SC-15(01)": [ + "END-14" ], - "MP-4.1-002": [ - "AAT-12" + "SC-03": [ + "END-16", + "SEA-04.1" ], - "MP-4.1-006": [ - "AAT-12", - "AAT-12.2" + "AC-03(02)": [ + "HRS-12.1", + "IAC-20.5" ], - "MP-4.1-010": [ - "AAT-12", - "TDA-22" + "IA-02(13)": [ + "IAC-02.4" ], - "MS-2.6-002": [ - "AAT-12", - "AAT-17.1", - "AAT-17.2" + "IA-03(01)": [ + "IAC-04" ], - "MG-3.1-004": [ - "AAT-12", - "AAT-26" + "AC-06(06)": [ + "IAC-05.2" ], - "GV-6.1-004": [ - "AAT-12.1", - "IAO-03.2", - "TPM-05" + "IA-02(06)": [ + "IAC-06.4" ], - "GV-6.1-008": [ - "AAT-12.1", - "AAT-12.4" + "IA-10": [ + "IAC-13" ], - "MP-2.1-001": [ - "AAT-12.1", - "AAT-12.3", - "RSK-01.1" + "AC-06(07)": [ + "IAC-17" ], - "MP-2.1-002": [ - "AAT-12.1", - "AAT-12.2" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "MP-2.2-001": [ - "AAT-12.1" + "AC-06(01)": [ + "IAC-21.1" ], - "MS-2.2-002": [ - "AAT-12.1", - "AAT-26", - "DCH-23" + "AC-06(02)": [ + "IAC-21.2" ], - "MS-2.5-003": [ - "AAT-12.1", - "AAT-26" + "AC-06(05)": [ + "IAC-21.3" ], - "MS-2.5-005": [ - "AAT-12.1" + "AC-06(10)": [ + "IAC-21.5" ], - "MG-2.2-002": [ - "AAT-12.1", - "AAT-12.2" + "AC-06(03)": [ + "IAC-21.6" ], - "MG-2.2-003": [ - "AAT-12.1", - "AAT-12.2", - "AAT-16.4" + "AC-06(08)": [ + "IAC-21.7" ], - "MG-4.1-006": [ - "AAT-12.1", - "AAT-12.2" + "AC-12": [ + "IAC-25" ], - "MS-2.7-007": [ - "AAT-12.2", - "VPM-10" + "IR-04(02)": [ + "IRO-02.3" ], - "MP-3.4-001": [ - "AAT-12.3" + "IR-04(11)": [ + "IRO-07" ], - "MS-1.1-001": [ - "AAT-12.4" + "IR-04(12)": [ + "IRO-08", + "IRO-13" ], - "MAP 2.1": [ - "AAT-14.1" + "IR-05": [ + "IRO-09" ], - "MAP 2.2": [ - "AAT-14.2" + "IR-04(10)": [ + "IRO-10.4", + "TPM-11" ], - "MS-4.2-004": [ - "AAT-15.2" + "SC-44": [ + "IRO-15" ], - "MANAGE 2.4": [ - "AAT-15.2" + "SA-11(05)": [ + "IAO-02.2", + "IAO-04", + "TDA-09", + "TDA-09.5", + "VPM-07" ], - "MG-2.4-002": [ - "AAT-15.2" + "MA-04(04)": [ + "MNT-05.7" ], - "MG-2.4-004": [ - "AAT-15.2" + "PE-03(05)": [ + "MDM-04" ], - "MEASURE 2.6": [ - "AAT-16" + "SC-46": [ + "NET-02.3" ], - "GV4.3--001": [ - "AAT-16.2" + "SC-07": [ + "NET-03" ], - "MG-1.3-002": [ - "AAT-16.2" + "SC-07(11)": [ + "NET-03", + "NET-04.1" ], - "MS-1.1-009": [ - "AAT-16.3" + "SC-07(16)": [ + "NET-03.3" ], - "MP-2.3-001": [ - "AAT-16.5" + "SC-07(10)": [ + "NET-03.5", + "NET-17" ], - "MG-4.1-001": [ - "AAT-16.5" + "SC-07(20)": [ + "NET-03.6" ], - "MP-4.1-004": [ - "AAT-16.7" + "SC-07(21)": [ + "NET-03.7" ], - "MS-2.12-001": [ - "AAT-17", - "AAT-17.1", - "EMB-15" + "SC-07(22)": [ + "NET-03.8" ], - "MG-4.3-002": [ - "AAT-17" + "AC-04(08)": [ + "NET-04.7" ], - "MEASURE 2.2": [ - "AAT-17.1" + "AC-04(12)": [ + "NET-04.8" ], - "MS-2.6-001": [ - "AAT-17.1" + "AC-04(17)": [ + "NET-04.12" ], - "MS-2.8-004": [ - "AAT-17.1" + "AC-04(21)": [ + "NET-06" ], - "MEASURE 2.12": [ - "AAT-17.2" + "SC-07(13)": [ + "NET-06.1" ], - "MS-2.12-002": [ - "AAT-17.2" + "SC-10": [ + "NET-07" ], - "MS-2.12-003": [ - "AAT-17.2" + "SC-23(03)": [ + "NET-09.2" ], - "MS-2.12-004": [ - "AAT-17.2" + "SC-22": [ + "NET-10.1" ], - "MANAGE 2.3": [ - "AAT-17.3" + "SC-37": [ + "NET-11" ], - "MS-1.1-005": [ - "AAT-17.4" + "SI-04(10)": [ + "NET-18.2" ], - "MS-2.7-008": [ - "AAT-17.5" + "SC-07(15)": [ + "NET-18.3" ], - "GV-1.3-007": [ - "AAT-18.1" + "PE-06": [ + "PES-05" ], - "MG-2.4-003": [ - "AAT-18.1" + "PE-06(04)": [ + "PES-05.2" ], - "MS-2.6-005": [ - "AAT-19" + "PE-11(01)": [ + "PES-07.3" ], - "MS-2.10-001": [ - "AAT-19", - "AAT-19.8", - "VPM-10" + "PE-11(02)": [ + "PES-07.3" ], - "MP-2.2-002": [ - "AAT-20.1", - "NET-05.1" + "PE-09(01)": [ + "PES-07.7" ], - "MS-2.8-003": [ - "AAT-20.1", - "AAT-26.1" + "PE-17": [ + "PES-11" ], - "MS-4.2-003": [ - "AAT-20.1" + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "MG-3.1-005": [ - "AAT-20.1" + "SR-07": [ + "RSK-09", + "OPS-01" ], - "MEASURE 2.3": [ - "AAT-20.2" + "PM-07(01)": [ + "SEA-02.2" ], - "MS-2.5-002": [ - "AAT-20.3" + "PL-08(01)": [ + "SEA-03" ], - "MP-5.1-003": [ - "AAT-22.7", - "AAT-22.8" + "SC-03(05)": [ + "SEA-03" ], - "MP-4.1-009": [ - "AAT-23", - "AAT-27", - "SEA-09" + "SC-32": [ + "SEA-03.1" ], - "GV-6.2-001": [ - "AAT-25", - "AAT-25.1" + "SC-02": [ + "SEA-03.2" ], - "MS-4.2-002": [ - "AAT-25" + "SC-02(01)": [ + "SEA-03.2" ], - "GV-6.2-006": [ - "AAT-25.1" + "SC-39": [ + "SEA-04" ], - "MP-2.3-003": [ - "AAT-26" + "SC-39(01)": [ + "SEA-04.2" ], - "MS-2.6-004": [ - "AAT-26" + "SC-39(02)": [ + "SEA-04.3" ], - "MS-2.9-001": [ - "AAT-26", - "TDA-22" + "CP-12": [ + "SEA-07.2" ], - "MP-2.3-004": [ - "AAT-26.1" + "SI-14": [ + "SEA-08" ], - "MS-2.5-004": [ - "AAT-26.1" + "SI-14(01)": [ + "SEA-08.1" ], - "MP-3.4-004": [ - "AAT-26.2" + "SI-15": [ + "SEA-09" ], - "MP-3.4-006": [ - "AAT-26.3" + "SI-16": [ + "SEA-10" ], - "MS-2.8-002": [ - "AAT-26.4" + "SC-26": [ + "SEA-11" ], - "MG-2.2-005": [ - "AAT-27" + "SC-35": [ + "SEA-12" ], - "MG-3.2-005": [ - "AAT-27" + "SC-29": [ + "SEA-13" ], - "MG-3.2-008": [ - "AAT-27.1" + "SC-29(01)": [ + "SEA-13.1" ], - "GV-1.1-001": [ - "CPL-01" + "SC-30": [ + "SEA-14" ], - "MG-4.3-003": [ - "CPL-01", - "IRO-10.2" + "SC-30(04)": [ + "SEA-14" ], - "MS-2.3-001": [ - "CFG-02" + "SC-30(05)": [ + "SEA-14" ], - "GV-6.2-002": [ - "CFG-04.1", - "TPM-04" + "SC-30(02)": [ + "SEA-14.1" ], - "GV-6.2-004": [ - "MON-01" + "SC-30(03)": [ + "SEA-14.2" ], - "MG-3.2-006": [ - "MON-01.2", - "MON-05.1" + "SC-36": [ + "SEA-15" ], - "MS-2.2-004": [ - "DCH-23" + "SC-34": [ + "SEA-16" ], - "GV-6.1-010": [ - "HRS-05.1", - "HRS-05.3", - "TPM-05" + "AT-02(01)": [ + "SAT-02.1" ], - "MS-1.3-003": [ - "HRS-11" + "AT-02(03)": [ + "SAT-02.2" ], - "GV-2.1-005": [ - "HRS-15" + "AT-03(03)": [ + "SAT-03.1" ], - "GV-6.2-003": [ - "IRO-04", - "IRO-06", - "TPM-11" + "AT-02(05)": [ + "SAT-03.2" ], - "MG-4.2-002": [ - "IRO-04", - "IRO-13" + "SA-23": [ + "TDA-01", + "TDA-01.1", + "TDA-12" ], - "MG-4.3-001": [ - "IRO-10", - "IRO-13" + "SR-03(01)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" ], - "MS-2.2-003": [ - "PRI-03.4" + "PL-08(02)": [ + "TDA-03.1" ], - "GOVERN 1.3": [ - "OPS-01.1" + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" ], - "MP-3.4-002": [ - "SAT-01.1" + "SA-11(02)": [ + "TDA-06.2", + "TDA-15" ], - "GV-6.1-002": [ - "SAT-02" + "CM-04(01)": [ + "TDA-08" ], - "GV-3.2-005": [ - "TDA-06.2" + "SA-11(06)": [ + "TDA-09", + "VPM-01.1" ], - "MS-2.3-004": [ - "TDA-07" + "SA-03(02)": [ + "TDA-10" ], - "MS-2.6-006": [ - "TDA-09.4" + "SR-04(03)": [ + "TDA-11" ], - "GV-6.2-007": [ - "TPM-01", - "TPM-05" + "SR-04(04)": [ + "TDA-11" ], - "GV-6.1-007": [ - "TPM-01.1" + "SR-11": [ + "TDA-11" ], - "GV-6.1-005": [ - "TPM-04.1" + "SR-11(03)": [ + "TDA-11" ], - "GV-6.1-006": [ - "TPM-04.1" + "SA-20": [ + "TDA-12" ], - "MS-2.7-006": [ - "VPM-05.3" + "SR-05": [ + "TPM-03.1" ], - "MS-2.6-007": [ - "VPM-06" + "SR-03(02)": [ + "TPM-03.2" ], - "MP-5.1-005": [ - "VPM-10" - ] - }, - "general-nist-privacy-framework-1-0": { - "ID-P": [ - "GOV-01" + "SR-05(01)": [ + "TPM-03.4" ], - "ID.BE-P": [ - "GOV-01" + "SR-06(01)": [ + "TPM-08" ], - "GV-P": [ - "GOV-01" + "PM-16": [ + "THR-01" ], - "GV.PO-P1": [ - "GOV-01", - "GOV-02", - "DCH-01", - "PRI-01", - "PRI-01.3" + "PM-16(01)": [ + "THR-03" ], - "GV.PO-P6": [ - "GOV-01", - "GOV-02", - "PRI-01", - "RSK-01" + "RA-10": [ + "THR-07" ], - "CM-P": [ - "GOV-01" + "SI-20": [ + "THR-08" ], - "CM.PO-P": [ - "GOV-01" + "RA-05(05)": [ + "VPM-06.3" ], - "PR-P": [ - "GOV-01" + "RA-05(06)": [ + "VPM-06.4" ], - "PR.PT-P": [ - "GOV-01" + "RA-05(08)": [ + "VPM-06.5" ], - "PR.PO-P6": [ - "GOV-01.2", - "GOV-05" + "RA-05(04)": [ + "VPM-06.8" ], - "PR.PO-P5": [ - "GOV-01.3", - "GOV-05", - "CPL-02" + "RA-05(10)": [ + "VPM-06.9" ], - "ID.DE-P1": [ - "GOV-02", - "RSK-01" + "CA-08": [ + "VPM-07" ], - "GV.PO-P": [ - "GOV-02" + "CA-08(01)": [ + "VPM-07.1" ], - "GV.MT-P": [ + "CA-08(02)": [ + "VPM-10" + ] + }, + "general-nist-800-161-r1": { + "AC-1": [ "GOV-02", - "PRI-01" + "GOV-03", + "IAC-01" ], - "GV.MT-P4": [ + "AT-1": [ "GOV-02", - "GOV-05", - "CPL-02", - "IAO-05" + "GOV-03", + "SAT-01" ], - "GV.MT-P5": [ + "AU-1": [ "GOV-02", - "IRO-02", - "PRI-01.11" + "GOV-03", + "MON-01" ], - "GV.MT-P6": [ + "CA-1": [ "GOV-02", - "IRO-13" + "GOV-03", + "IAO-01" ], - "GV.MT-P7": [ + "CM-1": [ "GOV-02", - "PRI-06.4" - ], - "CT.PO-P": [ - "GOV-02" + "GOV-03", + "CFG-01" ], - "CT.PO-P1": [ + "CP-1": [ "GOV-02", - "PRI-01.11", - "PRI-03", - "PRI-03.2", - "PRI-05.4", - "PRM-04", - "PRM-05", - "PRM-06", - "PRM-07" + "GOV-03", + "BCD-01" ], - "CT.PO-P2": [ + "IA-1": [ "GOV-02", - "PRI-01", - "PRI-01.4", - "PRI-05.4", - "PRI-07" + "GOV-03", + "IAC-01" ], - "CT.PO-P3": [ + "IR-1": [ "GOV-02", - "PRI-03", - "PRI-03.1", - "PRI-03.2" + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "CM.PO-P1": [ + "MA-1": [ "GOV-02", - "PRI-01", - "PRI-01.2", - "PRI-01.3", - "PRI-02", - "PRI-02.1", - "PRI-06.2" - ], - "PR.PO-P": [ - "GOV-02" + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "PR.PO-P4": [ + "MP-1": [ "GOV-02", - "PES-01" - ], - "GV.MT-P2": [ - "GOV-03" - ], - "GV.PO-P3": [ - "GOV-04", - "HRS-03", - "PRI-01.1", - "PRI-01.4", - "PRI-01.8", - "TPM-05.4", - "TPM-06" - ], - "CM.PO-P2": [ - "GOV-04", - "HRS-03", - "HRS-04.1", - "PRI-01.4" - ], - "ID.IM-P5": [ - "GOV-08", - "AST-02.8", - "PRM-06", - "OPS-03" - ], - "ID.BE-P1": [ - "GOV-08", - "PRI-07.2", - "PRM-06" - ], - "ID.BE-P2": [ - "GOV-08" - ], - "GV.RM-P3": [ - "GOV-08", - "PRM-06", - "RSK-01.1", - "RSK-01.5" - ], - "GV.PO-P2": [ - "GOV-14", - "GOV-15", - "HRS-03", - "HRS-03.1", - "SEA-01", - "SEA-01.1", - "SEA-02", - "SEA-02.1" - ], - "ID.IM-P": [ - "AST-01", + "GOV-03", "DCH-01" ], - "PR.DS-P3": [ - "AST-01" - ], - "ID.IM-P8": [ - "AST-01.1", - "AST-01.2", - "AST-02.8", - "AST-04", - "DCH-19" - ], - "ID.IM-P1": [ - "AST-02", - "TPM-01.1" - ], - "ID.IM-P4": [ - "AST-02.8" - ], - "ID.IM-P6": [ - "AST-02.8", - "PRI-05.5", - "PRI-05.6" - ], - "ID.IM-P2": [ - "AST-03", - "AST-03.1", - "TPM-05.4" - ], - "ID.IM-P7": [ - "AST-04", - "DCH-19", - "IAO-03", - "RSK-10" - ], - "PR.PO-P7": [ - "BCD-01", - "IRO-04" + "PE-1": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "ID.BE-P3": [ - "BCD-02", - "HRS-05.4", - "IAO-03", - "PRM-06", - "OPS-02", - "TDA-06.1", - "TPM-02" + "PL-1": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "PR.PO-P8": [ - "BCD-04", - "IRO-06" + "PS-1": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "PR.PO-P3": [ - "BCD-11" + "RA-1": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "PR.PT-P4": [ - "BCD-12.2" + "SC-1": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "PR.DS-P4": [ - "CAP-01", - "CAP-03" + "SI-1": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "PR.PO-P2": [ - "CHG-01", - "CHG-02" + "SR-1": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "GV.PO-P5": [ - "CPL-01", + "PT-1": [ + "GOV-03", "PRI-01", - "PRI-01.11" - ], - "ID.DE-P5": [ - "CPL-03", - "RSK-04", - "RSK-07", - "RSK-09.1", - "TPM-04.1", - "TPM-08" + "SEA-01" ], - "CT.DM-P9": [ - "CPL-03", - "CPL-03.2" + "SA-1": [ + "GOV-03", + "TDA-01", + "TDA-06" ], - "PR.PO-P1": [ - "CFG-01", - "CFG-02" + "PL-9": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" ], - "CT.DP-P4": [ - "CFG-02" + "PM-2": [ + "GOV-04" ], - "PR.PT-P2": [ - "CFG-02", - "CFG-03" + "PM-6": [ + "GOV-04", + "GOV-05" ], - "CT.DM-P8": [ - "MON-01", - "MON-02.2", - "DCH-18.1" + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" ], - "PR.DS-P6": [ - "MON-01.7", - "END-06", - "END-06.1", - "END-06.3" + "IR-6": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "PR.DS-P2": [ - "CRY-03" + "PM-15": [ + "GOV-07", + "THR-01" ], - "PR.AC-P5": [ - "CRY-04", - "NET-02", - "NET-06" + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" ], - "PR.DS-P1": [ - "CRY-05" + "PM-32": [ + "GOV-11" ], - "CT.DM-P1": [ - "DCH-01", - "DCH-01.2" + "PM-5": [ + "AST-01", + "AST-02" ], - "CT.DM-P2": [ - "DCH-01", - "DCH-01.2" + "CM-8": [ + "AST-02", + "AST-02.3" ], - "CT.DM-P3": [ - "DCH-01", - "DCH-18" + "CM-8(1)": [ + "AST-02.1" ], - "CT.DM-P4": [ - "DCH-01", - "DCH-18" + "CM-8(6)": [ + "AST-02.4" ], - "PR.DS-P": [ - "DCH-01" + "SC-7(19)": [ + "AST-02.5" ], - "CT.DM-P7": [ - "DCH-05" + "SC-18(2)": [ + "AST-02.7", + "END-10" ], - "ID.IM-P3": [ - "DCH-06.2", - "PRI-05.5", - "PRI-05.6", - "PRI-05.7" + "CM-13": [ + "AST-02.8" ], - "CT.DM-P5": [ - "DCH-09" + "CM-8(2)": [ + "AST-02.9" ], - "PR.PT-P1": [ - "DCH-12" + "CM-8(7)": [ + "AST-02.9" ], - "CT.DP-P2": [ - "DCH-23" + "CM-8(8)": [ + "AST-02.10" ], - "CT.DP-P3": [ - "DCH-23", - "IAC-09.6" + "CM-8(9)": [ + "AST-02.11" ], - "PR.DS-P8": [ - "END-06.1" + "CM-8(4)": [ + "AST-03.1" ], - "PR.PO-P9": [ - "HRS-01", - "PRI-01" + "SR-4": [ + "AST-03.2" ], - "PR.AC-P4": [ - "HRS-11", - "IAC-21" + "PL-2": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "PR.AC-P": [ - "IAC-01" + "SA-5": [ + "AST-04.1", + "TDA-04" ], - "PR.AC-P1": [ - "IAC-01" + "SR-12": [ + "AST-09", + "TDA-11.2" ], - "PR.AC-P6": [ - "IAC-02", - "IAC-03", - "IAC-04" + "SR-9": [ + "AST-15" ], - "CT.DP-P5": [ - "IAC-09.6" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "CM.AW-P7": [ - "IRO-04.1", - "IRO-10", - "IRO-10.2" + "CP-2": [ + "BCD-01", + "BCD-06" ], - "CM.AW-P8": [ - "IRO-04.1", - "IRO-16" + "PM-8": [ + "BCD-01", + "CPL-01" ], - "PR.DS-P5": [ - "IRO-12", - "SEA-01" + "CP-2(1)": [ + "BCD-01.1" ], - "ID.DE-P3": [ - "IAO-03.2", - "PRI-07.1", - "RSK-09", - "RSK-10", - "TPM-05" + "CP-2(7)": [ + "BCD-01.2" ], - "PR.MA-P": [ - "MNT-01" + "CP-2(8)": [ + "BCD-02" ], - "PR.MA-P1": [ - "MNT-01" + "CP-3": [ + "BCD-03" ], - "PR.MA-P2": [ - "MNT-05" + "CP-3(1)": [ + "BCD-03.1" ], - "PR.PT-P3": [ - "NET-01", - "NET-02" + "CP-4": [ + "BCD-04", + "BCD-05" ], - "PR.AC-P3": [ - "NET-14", - "NET-14.5" + "CP-6": [ + "BCD-08" ], - "PR.AC-P2": [ + "PE-23": [ + "BCD-08", + "BCD-09", "PES-01", - "PES-03", - "PES-03.4", - "PES-04", - "PES-04.1" - ], - "CT-P": [ - "PRI-01" + "PES-12", + "SEA-15", + "TPM-04.4" ], - "CT.DM-P": [ - "PRI-01" + "CP-6(1)": [ + "BCD-08.1" ], - "CT.DP-P": [ - "PRI-01" + "CP-7": [ + "BCD-09" ], - "CM.AW-P": [ - "PRI-01" + "CP-8": [ + "BCD-10" ], - "CM.AW-P1": [ - "PRI-01.3", - "PRI-02" + "CP-11": [ + "BCD-10" ], - "GV.MT-P3": [ - "PRI-01.11" + "CP-8(3)": [ + "BCD-10.2" ], - "CM.AW-P2": [ - "PRI-01.11", - "PRI-06.4" + "CP-8(4)": [ + "BCD-10.3" ], - "CM.AW-P3": [ - "PRI-01.11", - "PRM-04", - "PRM-07", - "SEA-01" + "SC-47": [ + "BCD-10.4" ], - "CT.PO-P4": [ - "PRI-06.2", - "PRI-06.4", - "PRI-10", - "PRM-04", - "PRM-07" + "SC-5": [ + "CAP-02" ], - "ID.DE-P4": [ - "PRI-06.6", - "SEA-01" + "SC-5(2)": [ + "CAP-02", + "CAP-03" ], - "CT.DM-P6": [ - "PRI-06.6", - "PRI-06.7" + "CP-2(2)": [ + "CAP-03" ], - "CM.AW-P5": [ - "PRI-07.3" + "CM-3": [ + "CHG-01", + "CHG-02" ], - "CM.AW-P4": [ - "PRI-09", - "PRI-14", - "PRI-14.1" + "CM-3(1)": [ + "CHG-02.1" ], - "CM.AW-P6": [ - "PRI-09", - "PRI-14" + "CM-3(2)": [ + "CHG-02.2", + "CHG-06" ], - "ID.RA-P": [ - "RSK-01" + "CM-3(4)": [ + "CHG-02.3" ], - "ID.DE-P": [ - "RSK-01" + "CM-4": [ + "CHG-03" ], - "GV.RM-P": [ - "RSK-01" + "CM-5": [ + "CHG-04", + "END-03.2" ], - "GV.RM-P1": [ - "RSK-01" + "CM-5(1)": [ + "CHG-04.1" ], - "GV.RM-P2": [ - "RSK-01.3" + "CM-14": [ + "CHG-04.2" ], - "GV.MT-P1": [ - "RSK-04", - "RSK-07", - "RSK-09.1", - "RSK-10" + "SI-7(15)": [ + "CHG-04.2" ], - "ID.DE-P2": [ - "RSK-09", - "RSK-10" + "AC-5": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "ID.RA-P1": [ - "RSK-10" + "CM-5(6)": [ + "CHG-04.5" ], - "ID.RA-P2": [ - "RSK-10" + "CM-9": [ + "CHG-05", + "CFG-01" ], - "ID.RA-P3": [ - "RSK-10" + "SA-9(5)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" ], - "ID.RA-P4": [ - "RSK-10" + "CA-7": [ + "CPL-02" ], - "ID.RA-P5": [ - "RSK-10" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "GV.AT-P": [ - "SAT-01" + "CA-2": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "GV.AT-P1": [ - "SAT-01", - "SAT-02", - "SAT-03" + "RA-3": [ + "CPL-03.2", + "RSK-04" ], - "GV.AT-P2": [ - "SAT-01", - "SAT-02", - "SAT-03" + "CM-9(1)": [ + "CFG-01.1" ], - "GV.AT-P3": [ - "SAT-01", - "SAT-02", - "SAT-03" + "CM-2": [ + "CFG-02", + "CFG-02.1" ], - "GV.AT-P4": [ - "SAT-01", - "TPM-05", - "TPM-05.4", - "TPM-06" + "CM-6": [ + "CFG-02", + "CFG-02.7" ], - "CT.DP-P1": [ - "TDA-01.1", - "TDA-06" + "PL-10": [ + "CFG-02" ], - "PR.DS-P7": [ - "TDA-08" + "SA-8": [ + "CFG-02", + "SEA-01" ], - "GV.PO-P4": [ - "TPM-01", - "TPM-05", - "TPM-05.4", - "TPM-06" + "CM-6(1)": [ + "CFG-02.2" ], - "PR.PO-P10": [ - "VPM-01" - ] - }, - "general-nist-800-37-r2": { - "TASK P-5": [ - "GOV-02", - "GOV-15.1" + "CM-2(6)": [ + "CFG-02.4" ], - "TASK P-1": [ - "GOV-04", - "HRS-03", - "TPM-05.4" + "CM-7(6)": [ + "CFG-02.5" ], - "TASK P-9": [ - "GOV-04.1", - "AST-01.2", - "IAO-03.1" + "CM-7(7)": [ + "CFG-02.5" ], - "TASK P-17": [ - "GOV-15", - "GOV-15.2" + "CM-7(9)": [ + "CFG-02.5" ], - "TASK S-1": [ - "GOV-15.1" + "CM-6(2)": [ + "CFG-02.8" ], - "TASK S-3": [ - "GOV-15.2" + "CM-7": [ + "CFG-03" ], - "TASK I-1": [ - "GOV-15.2" + "CM-7(1)": [ + "CFG-03.1" ], - "TASK A-3": [ - "GOV-15.3", - "IAO-02" + "CM-7(4)": [ + "CFG-03.3" ], - "TASK M-2": [ - "GOV-15.3" + "CM-7(5)": [ + "CFG-03.3" ], - "TASK R-4": [ - "GOV-15.4", - "IAO-07" + "CM-10": [ + "CFG-04" ], - "TASK M-1": [ - "GOV-15.5" + "CM-8(10)": [ + "CFG-04.1", + "TDA-04", + "TDA-04.1", + "TDA-04.2", + "TDA-05" ], - "TASK P-18": [ - "AST-01", - "IAO-07" + "CM-10(1)": [ + "CFG-04.1" ], - "TASK P-10": [ - "AST-02" + "CM-11": [ + "CFG-05", + "END-03" ], - "TASK P-11": [ - "AST-04", - "CPL-01.2", - "IAO-01.1" + "CM-3(8)": [ + "CFG-06" ], - "TASK M-7": [ - "AST-09", - "PRM-07" + "PM-31": [ + "MON-01" ], - "TASK P-6": [ - "BCD-02", - "CFG-02.5" + "SI-4": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "TASK P-8": [ - "BCD-02", - "PRM-01.1", - "PRM-05", - "PRM-06" + "AU-2": [ + "MON-01.8", + "MON-02" ], - "TASK P-7": [ - "CPL-02", - "MON-01" + "SI-4(19)": [ + "MON-01.14" ], - "TASK P-4": [ - "CFG-02.9" + "AU-6": [ + "MON-02", + "MON-02.6" ], - "TASK S-2": [ - "CFG-02.9", - "RSK-06.2" + "AU-6(9)": [ + "MON-02.1" ], - "TASK P-12": [ - "DCH-02" + "SI-4(17)": [ + "MON-02.3" ], - "TASK C-2": [ - "DCH-02" + "AU-3": [ + "MON-03" ], - "TASK P-13": [ - "DCH-22", - "PRM-07" + "AU-12": [ + "MON-06" ], - "TASK C-3": [ - "IAO-02" + "CA-7(3)": [ + "MON-06.2" ], - "TASK A-1": [ - "IAO-02", - "IAO-02.1", - "IAO-02.2" + "AU-10": [ + "MON-09" ], - "TASK A-2": [ - "IAO-02" + "AU-10(1)": [ + "MON-09.1" ], - "TASK A-4": [ - "IAO-02.4" + "AU-10(2)": [ + "MON-09.1" ], - "TASK M-5": [ - "IAO-02.4" + "AU-13": [ + "MON-11" ], - "TASK C-1": [ - "IAO-03" + "AU-14": [ + "MON-12" ], - "TASK S-4": [ - "IAO-03" + "AU-16": [ + "MON-14" ], - "TASK S-5": [ - "IAO-03" + "AU-16(2)": [ + "MON-14.1" ], - "TASK S-6": [ - "IAO-03" + "SC-8": [ + "CRY-03", + "CRY-04" ], - "TASK A-5": [ - "IAO-04", - "IAO-05" + "SC-28": [ + "CRY-05", + "END-02" ], - "TASK M-3": [ - "IAO-04" + "AC-18": [ + "CRY-07", + "NET-15" ], - "TASK I-2": [ - "IAO-05" + "AC-3(9)": [ + "DCH-03.3" ], - "TASK A-6": [ - "IAO-05" + "MP-4": [ + "DCH-06" ], - "TASK R-3": [ - "IAO-05", - "RSK-06.4" + "MP-5": [ + "DCH-07" ], - "TASK R-1": [ - "IAO-07" + "MP-6": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "TASK R-2": [ - "IAO-07" + "AC-20": [ + "DCH-13" ], - "TASK R-5": [ - "IAO-07" + "AC-20(1)": [ + "DCH-13.1" ], - "TASK M-4": [ - "IAO-07" + "PM-17": [ + "DCH-13.3" ], - "TASK M-6": [ - "IAO-07" + "AC-20(3)": [ + "DCH-13.4" ], - "TASK P-16": [ - "PRI-01.11" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "TASK P-2": [ - "RSK-01" + "AC-22": [ + "DCH-15" ], - "TASK P-3": [ - "RSK-03", - "RSK-04" + "AC-23": [ + "DCH-16", + "PRI-05.4" ], - "TASK P-14": [ - "RSK-03", - "RSK-04" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "TASK P-15": [ - "SEA-01" - ] - }, - "general-nist-800-39": { - "TASK 4-2": [ - "CPL-02", - "RSK-01" + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" ], - "3.4": [ - "IAO-05" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "TASK 4-1": [ - "RSK-01" + "CM-12": [ + "DCH-24" ], - "3.1": [ - "RSK-01.1" + "CM-12(1)": [ + "DCH-24.1" ], - "TASK 1-1": [ - "RSK-01.1" + "SI-3": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "TASK 1-2": [ - "RSK-01.1" + "SI-2": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "TASK 1-4": [ - "RSK-01.1", - "RSK-01.4", - "RSK-01.5" + "SI-7": [ + "END-06", + "NET-12", + "TDA-18" ], - "TASK 1-3": [ - "RSK-01.3" + "CM-7(8)": [ + "END-06.7" ], - "TASK 2-1": [ - "RSK-03.1", - "THR-09", - "THR-10", - "VPM-01" + "SI-7(14)": [ + "END-06.7" ], - "3.2": [ - "RSK-04" + "SC-18": [ + "END-10" ], - "TASK 2-2": [ - "RSK-04" + "SC-27": [ + "END-10" ], - "3.3": [ - "RSK-06", - "RSK-06.1", - "RSK-06.2", - "RSK-06.3", - "RSK-06.4" + "PM-13": [ + "HRS-03", + "SAT-01" ], - "TASK 3-1": [ - "RSK-06.2", - "RSK-06.3" + "PS-3": [ + "HRS-04" ], - "TASK 3-2": [ - "RSK-06.3" + "PL-4": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "TASK 3-3": [ - "RSK-06.4" + "PS-6": [ + "HRS-06", + "HRS-06.1" ], - "TASK 3-4": [ - "RSK-06.4" - ] - }, - "general-nist-800-53-r4": { - "PM-1": [ - "GOV-01", - "GOV-02", - "GOV-03" + "PS-7": [ + "HRS-10" ], - "PL-9": [ - "GOV-04", - "SEA-01.1" + "IA-4": [ + "IAC-01.2", + "IAC-09" ], - "PM-2": [ - "GOV-04" + "IA-2": [ + "IAC-02" ], - "PM-6": [ - "GOV-04", - "GOV-05" + "IA-8": [ + "IAC-03" ], - "IR-6": [ - "GOV-06", - "IRO-10", - "IRO-14" + "IA-3": [ + "IAC-04" ], - "PM-15": [ - "GOV-07" + "IA-9": [ + "IAC-05" ], - "PM-5": [ - "AST-01", - "AST-02" + "AC-6(6)": [ + "IAC-05.2" ], - "CM-8": [ - "AST-02" + "AC-2": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "CM-8(1)": [ - "AST-02.1" + "IA-4(6)": [ + "IAC-09.4" ], - "CM-8(3)": [ - "AST-02.2" + "IA-5": [ + "IAC-10", + "IAC-10.8" ], - "CM-8(5)": [ - "AST-02.3" + "IA-5(5)": [ + "IAC-10.8" ], - "CM-8(6)": [ - "AST-02.4" + "IA-5(9)": [ + "IAC-13.2" ], - "IA-3(4)": [ - "AST-02.5", - "IAC-04", - "IAC-04.1" + "AC-3": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "SC-18(2)": [ - "AST-02.7", - "END-10" + "AC-6": [ + "IAC-20", + "IAC-21" ], - "CM-8(2)": [ - "AST-02.9" + "AC-3(8)": [ + "IAC-20.6" ], - "CM-8(4)": [ - "AST-03.1" + "AC-24": [ + "IAC-28.1" ], - "PL-2": [ - "AST-04", - "IAO-03" + "IR-4": [ + "IRO-02" ], - "SA-5(1)": [ - "AST-04" + "IR-4(6)": [ + "IRO-02.2" ], - "SA-5(2)": [ - "AST-04" + "IR-4(7)": [ + "IRO-02.2" ], - "SA-5(3)": [ - "AST-04" + "IR-1(1)": [ + "IRO-02.5", + "IRO-10.4" ], - "SA-5(4)": [ - "AST-04" + "IR-8": [ + "IRO-04" ], - "SA-19(3)": [ - "AST-09" + "IR-2": [ + "IRO-05" ], - "SC-43": [ - "AST-14" + "IR-3": [ + "IRO-06" ], - "SA-18": [ - "AST-15" + "IR-4(11)": [ + "IRO-07" ], - "SA-18(2)": [ - "AST-15.1" + "AU-10(3)": [ + "IRO-08" ], - "CP-1": [ - "BCD-01" + "IR-5": [ + "IRO-09" ], - "CP-2": [ - "BCD-01", - "BCD-06" + "IR-4(10)": [ + "IRO-10.4", + "TPM-11" ], - "IR-4(3)": [ - "BCD-01", - "IRO-02.4" + "IR-6(3)": [ + "IRO-10.4" ], - "PM-8": [ - "BCD-01", - "CPL-01" + "IR-7": [ + "IRO-11" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "IR-7(2)": [ + "IRO-11.2" ], - "CP-2(1)": [ - "BCD-01.1" + "IR-9": [ + "IRO-12", + "IRO-12.1" ], - "CP-2(7)": [ - "BCD-01.2" + "PM-10": [ + "IAO-01" ], - "CP-2(6)": [ - "BCD-01.3" + "CA-2(2)": [ + "IAO-02.2" ], - "CP-6(2)": [ - "BCD-01.4" + "CA-2(3)": [ + "IAO-02.3" ], - "CP-2(8)": [ - "BCD-02" + "CA-5": [ + "IAO-05" ], - "CP-2(4)": [ - "BCD-02.1" + "PM-4": [ + "IAO-05", + "VPM-02" ], - "CP-2(5)": [ - "BCD-02.2" + "CA-6": [ + "IAO-07" ], - "CP-2(3)": [ - "BCD-02.3" + "MA-2": [ + "MNT-02" ], - "CP-3": [ - "BCD-03" + "MA-2(2)": [ + "MNT-02.1" ], - "CP-3(1)": [ - "BCD-03.1" + "MA-6": [ + "MNT-03" ], - "CP-3(2)": [ - "BCD-03.2" + "MA-3": [ + "MNT-04" ], - "CP-4": [ - "BCD-04", - "BCD-05" + "MA-3(1)": [ + "MNT-04.1" ], - "CP-4(1)": [ - "BCD-04.1" + "MA-3(2)": [ + "MNT-04.2" ], - "CP-4(2)": [ - "BCD-04.2" + "MA-3(3)": [ + "MNT-04.3" ], - "CP-13": [ - "BCD-07" + "MA-4": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "CP-6": [ - "BCD-08" + "MA-4(3)": [ + "MNT-05.6" ], - "CP-6(1)": [ - "BCD-08.1" + "MA-5": [ + "MNT-06" ], - "CP-6(3)": [ - "BCD-08.2" + "MA-5(4)": [ + "MNT-06.1" ], - "CP-7": [ - "BCD-09" + "SR-11(2)": [ + "MNT-07" ], - "CP-7(1)": [ - "BCD-09.1" + "MA-7": [ + "MNT-08" ], - "CP-7(2)": [ - "BCD-09.2" + "MA-8": [ + "MNT-11", + "SEA-07" ], - "CP-7(3)": [ - "BCD-09.3" + "AC-19": [ + "MDM-02" ], - "CP-7(4)": [ - "BCD-09.4" + "PE-3(5)": [ + "MDM-04" ], - "CP-7(6)": [ - "BCD-09.5" + "SC-7": [ + "NET-03" ], - "CP-8": [ - "BCD-10" + "AC-4": [ + "NET-04" ], - "CP-8(2)": [ - "BCD-10" + "AC-4(6)": [ + "NET-04.5" ], - "CP-11": [ - "BCD-10" + "AC-4(17)": [ + "NET-04.12" ], - "CP-8(1)": [ - "BCD-10.1" + "AC-4(19)": [ + "NET-04.13" ], - "CP-8(3)": [ - "BCD-10.2" + "CA-3": [ + "NET-05" ], - "CP-8(4)": [ - "BCD-10.3" + "AC-4(21)": [ + "NET-06" ], - "CP-9": [ - "BCD-11" + "SC-7(13)": [ + "NET-06.1" ], - "SC-28(2)": [ - "BCD-11", - "CRY-05.2" + "SC-37": [ + "NET-11" ], - "CP-9(1)": [ - "BCD-11.1" + "SC-37(1)": [ + "NET-11" ], - "CP-9(3)": [ - "BCD-11.2" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "CP-9(2)": [ - "BCD-11.5" + "AC-17": [ + "NET-14" ], - "CP-9(5)": [ - "BCD-11.6" + "AC-17(6)": [ + "NET-14" ], - "CP-9(6)": [ - "BCD-11.7" + "PE-2": [ + "PES-02" ], - "CP-9(7)": [ - "BCD-11.8" + "PE-2(1)": [ + "PES-02.1" ], - "CP-10(2)": [ - "BCD-12.1" + "PE-3": [ + "PES-03" ], - "CP-10(5)": [ - "BCD-12.2" + "PE-3(2)": [ + "PES-03" ], - "CP-10(4)": [ - "BCD-12.4" + "SC-7(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" ], - "CP-10(6)": [ - "BCD-13" + "PE-3(1)": [ + "PES-03.4" ], - "SC-5": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "PE-6": [ + "PES-05" ], - "SC-5(3)": [ - "CAP-01" + "PE-16": [ + "PES-10" ], - "SC-5(1)": [ - "CAP-02" + "PE-17": [ + "PES-11" ], - "SC-5(2)": [ - "CAP-02", - "CAP-03" + "PE-18": [ + "PES-12" ], - "SC-6": [ - "CAP-02" + "PE-20": [ + "PES-14" ], - "CP-2(2)": [ - "CAP-03" + "PM-18": [ + "PRI-01" ], - "CM-3": [ - "CHG-01", - "CHG-02" + "PM-19": [ + "PRI-01.1" ], - "CM-3(1)": [ - "CHG-02.1" + "PM-20": [ + "PRI-01.3" ], - "CM-3(2)": [ - "CHG-02.2", - "CHG-06" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "CM-5(2)": [ - "CHG-02.2" + "PM-27": [ + "PRI-14" ], - "CM-3(4)": [ - "CHG-02.3" + "PM-21": [ + "PRI-14.1" ], - "CM-3(5)": [ - "CHG-02.4" + "PM-3": [ + "PRM-02" ], - "CM-3(6)": [ - "CHG-02.5" + "SA-2": [ + "PRM-03" ], - "CM-4": [ - "CHG-03" + "RA-9": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "CM-5": [ - "CHG-04", - "END-03.2" + "PM-11": [ + "PRM-06" ], - "CM-5(1)": [ - "CHG-04.1" + "SA-3": [ + "PRM-07", + "SEA-07.1" ], - "CM-5(3)": [ - "CHG-04.2" + "PM-9": [ + "RSK-01" ], - "AC-5": [ - "CHG-04.3", - "HRS-11" + "PM-28": [ + "RSK-01.1" ], - "CM-5(4)": [ - "CHG-04.3" + "RA-2": [ + "RSK-02" ], - "CM-5(5)": [ - "CHG-04.4" + "RA-7": [ + "RSK-06.1" ], - "CM-5(6)": [ - "CHG-04.5" + "PM-30": [ + "RSK-09" ], - "CM-9": [ - "CHG-05", - "CFG-01" + "SA-9(3)": [ + "RSK-09", + "TPM-02", + "TPM-03", + "TPM-05", + "TPM-05.4", + "TPM-05.7" ], - "SI-6": [ - "CHG-06" + "SR-2": [ + "RSK-09", + "TPM-03" ], - "SA-9(5)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "SR-7": [ + "RSK-09", + "OPS-01" ], - "PL-1": [ - "CPL-01", - "PRM-01", - "TDA-01" + "RA-3(1)": [ + "RSK-09.1" ], - "CA-7": [ - "CPL-02" + "PL-8": [ + "SEA-02" ], - "CA-7(1)": [ - "CPL-02", - "CPL-03.1" + "PM-7": [ + "SEA-02" ], - "PM-14": [ - "CPL-02" + "SC-4": [ + "SEA-05" ], - "CA-2": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "SC-29": [ + "SEA-13" ], - "RA-3": [ - "CPL-03.2", - "RSK-04" + "SC-30": [ + "SEA-14" ], - "CM-1": [ - "CFG-01" + "SC-30(4)": [ + "SEA-14" ], - "CM-9(1)": [ - "CFG-01.1" + "SC-30(5)": [ + "SEA-14" ], - "CM-2": [ - "CFG-02" + "SC-30(2)": [ + "SEA-14.1" ], - "CM-2(3)": [ - "CFG-02", - "CFG-02.1", - "CFG-02.3" + "SC-30(3)": [ + "SEA-14.2" ], - "CM-6": [ - "CFG-02", - "CFG-02.7" + "SC-36": [ + "SEA-15" ], - "SA-8": [ - "CFG-02", - "SEA-01" + "SC-38": [ + "OPS-01", + "OPS-04" ], - "CM-2(1)": [ - "CFG-02.1" + "PL-7": [ + "OPS-02" ], - "CM-2(2)": [ - "CFG-02.2" + "AT-2": [ + "SAT-02" ], - "CM-6(1)": [ - "CFG-02.2" + "AT-2(1)": [ + "SAT-02.1" ], - "CM-2(6)": [ - "CFG-02.4" + "AT-2(3)": [ + "SAT-02.2" ], - "CM-2(7)": [ - "CFG-02.5" + "AT-3": [ + "SAT-03" ], - "CM-6(2)": [ - "CFG-02.8" + "AT-3(2)": [ + "SAT-03" ], - "CM-7": [ - "CFG-03" + "AT-3(6)": [ + "SAT-03", + "THR-01", + "THR-03" ], - "CM-7(1)": [ - "CFG-03.1" + "AT-2(4)": [ + "SAT-03.2" ], - "CM-7(2)": [ - "CFG-03.2", - "SEA-06" + "AT-2(5)": [ + "SAT-03.2" ], - "CM-7(4)": [ - "CFG-03.3" + "AT-2(6)": [ + "SAT-03.6" ], - "CM-7(5)": [ - "CFG-03.3" + "AT-4": [ + "SAT-04" ], - "SC-18(4)": [ - "CFG-03.3", - "END-10" + "SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "SC-7(7)": [ - "CFG-03.4" + "SA-4(7)": [ + "TDA-02.2" ], - "CM-10": [ - "CFG-04" + "SR-3(1)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" ], - "CM-10(1)": [ - "CFG-04.1" + "SA-4(5)": [ + "TDA-02.4" ], - "CM-11": [ - "CFG-05", - "END-03" + "PL-8(2)": [ + "TDA-03.1" ], - "CM-11(1)": [ - "CFG-05.1", - "END-03.1" + "SA-17": [ + "TDA-05" ], - "CM-11(2)": [ - "CFG-05.2", - "END-03" + "SA-15": [ + "TDA-06" ], - "DM-2(1)": [ - "CFG-08.1", - "MON-03" + "SA-15(3)": [ + "TDA-06.1" ], - "AU-1": [ - "MON-01" + "SA-15(4)": [ + "TDA-06.2" ], - "SI-4": [ - "MON-01", - "MON-02" + "SA-15(8)": [ + "TDA-06.2" ], - "SI-4(1)": [ - "MON-01.1" + "CM-4(1)": [ + "TDA-08" ], - "SI-4(2)": [ - "MON-01.2" + "SA-11": [ + "TDA-09" ], - "SI-4(4)": [ - "MON-01.3" + "SA-4(8)": [ + "TDA-09.1" ], - "SI-4(5)": [ - "MON-01.4" + "SR-11": [ + "TDA-11" ], - "SI-4(14)": [ - "MON-01.5", - "NET-08.2" + "SR-11(3)": [ + "TDA-11" ], - "SI-4(15)": [ - "MON-01.5", - "NET-08.2" + "SR-11(1)": [ + "TDA-11.1" ], - "SI-4(23)": [ - "MON-01.6" + "SA-20": [ + "TDA-12" ], - "AU-2(3)": [ - "MON-01.8", - "MON-02" + "SA-21": [ + "TDA-13" ], - "SI-4(7)": [ - "MON-01.11", - "IRO-02.1" + "SA-21(1)": [ + "TDA-13" ], - "SI-4(12)": [ - "MON-01.12", - "MON-05.1" + "SA-10": [ + "TDA-14" ], - "SI-4(13)": [ - "MON-01.13" + "SA-16": [ + "TDA-16" ], - "SI-4(19)": [ - "MON-01.14" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "SI-4(20)": [ - "MON-01.15" + "SR-13": [ + "TPM-01.1" ], - "AU-2": [ - "MON-02" + "SR-5": [ + "TPM-03.1" ], - "AU-6": [ - "MON-02" + "SR-3": [ + "TPM-03.3" ], - "IR-4(4)": [ - "MON-02", - "MON-02.1" + "SA-9": [ + "TPM-04" ], - "AU-6(3)": [ - "MON-02.1" + "SA-9(1)": [ + "TPM-04.1" ], - "SI-4(16)": [ - "MON-02.1" + "SA-9(4)": [ + "TPM-04.3" ], - "AU-6(4)": [ - "MON-02.2" + "SR-3(3)": [ + "TPM-05", + "TPM-05.2" ], - "AU-6(5)": [ - "MON-02.3" + "SR-8": [ + "TPM-05.1" ], - "AU-6(6)": [ - "MON-02.4" + "SR-6": [ + "TPM-08" ], - "AU-6(7)": [ - "MON-02.5" + "PM-16": [ + "THR-01" ], - "AU-6(10)": [ - "MON-02.6" + "PM-12": [ + "THR-04" ], - "AU-12(1)": [ - "MON-02.7" + "AT-2(2)": [ + "THR-05" ], - "AU-12(3)": [ - "MON-02.8" + "RA-10": [ + "THR-07" ], - "AU-3": [ - "MON-03" + "SI-20": [ + "THR-08" ], - "AU-3(1)": [ - "MON-03.1" + "SI-2(5)": [ + "VPM-05.4" ], - "AU-6(1)": [ - "MON-03.1" + "RA-5": [ + "VPM-06", + "VPM-06.1" ], - "AU-6(8)": [ - "MON-03.3" + "RA-5(3)": [ + "VPM-06.2" ], - "AU-3(2)": [ - "MON-03.6" + "RA-5(6)": [ + "VPM-06.4" + ] + }, + "general-nist-800-161-r1-cscrm": { + "AC-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "AU-4": [ - "MON-04" + "AT-1": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "AU-5": [ - "MON-05" + "AU-1": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "AU-5(2)": [ - "MON-05.1" + "CA-1": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "AU-5(1)": [ - "MON-05.2" + "CM-1": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "AU-7": [ - "MON-06" + "CP-1": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "AU-7(1)": [ - "MON-06" + "IA-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "AU-12": [ - "MON-06" + "IR-1": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "CA-7(3)": [ - "MON-06.2" + "MA-1": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "AU-8": [ - "MON-07", - "SEA-20" + "MP-1": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "AU-8(1)": [ - "MON-07.1" + "PE-1": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "AU-9": [ - "MON-08" + "PL-1": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "AU-4(1)": [ - "MON-08.1" + "PS-1": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "AU-9(2)": [ - "MON-08.1" + "RA-1": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "AU-9(4)": [ - "MON-08.2" + "SC-1": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "AU-9(3)": [ - "MON-08.3" + "SI-1": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "AU-9(5)": [ - "MON-08.4" + "SR-1": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "AU-10": [ - "MON-09" + "SA-1": [ + "GOV-03", + "TDA-01", + "TDA-06" ], - "AU-11": [ - "MON-10" + "CM-8": [ + "AST-02", + "AST-02.3" ], - "AU-13": [ - "MON-11" + "PL-2": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "SI-4(18)": [ - "MON-11.1" + "SA-5": [ + "AST-04.1", + "TDA-04" ], - "SI-4(22)": [ - "MON-11.2" + "SR-12": [ + "AST-09", + "TDA-11.2" ], - "SI-4(24)": [ - "MON-11.3" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "AU-14": [ - "MON-12" + "CP-2": [ + "BCD-01", + "BCD-06" ], - "AU-15": [ - "MON-13" + "CP-3": [ + "BCD-03" ], - "AU-16": [ - "MON-14" + "CP-4": [ + "BCD-04", + "BCD-05" ], - "AU-16(1)": [ - "MON-14" + "CM-4": [ + "CHG-03" ], - "AU-16(2)": [ - "MON-14.1" + "CM-5": [ + "CHG-04", + "END-03.2" ], - "SC-31": [ - "MON-15" + "CA-2": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "AC-2(12)": [ - "MON-16" + "RA-3": [ + "CPL-03.2", + "RSK-04" ], - "SI-4(11)": [ - "MON-16" + "CM-2": [ + "CFG-02", + "CFG-02.1" ], - "SC-8(1)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "CM-6": [ + "CFG-02", + "CFG-02.7" ], - "SC-8(2)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" + "PL-10": [ + "CFG-02" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "SA-8": [ + "CFG-02", + "SEA-01" ], - "SC-13(1)": [ - "CRY-01" + "CM-7": [ + "CFG-03" ], - "SI-7(6)": [ - "CRY-01" + "CM-10": [ + "CFG-04" ], - "SC-8(4)": [ - "CRY-01.4" + "CM-11": [ + "CFG-05", + "END-03" ], - "IA-7": [ - "CRY-02", - "IAC-12" + "SI-4": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "SC-8": [ - "CRY-03", - "CRY-04" + "AU-2": [ + "MON-01.8", + "MON-02" ], - "SC-16(1)": [ - "CRY-04", - "CRY-10" + "AU-6": [ + "MON-02", + "MON-02.6" ], - "SC-28(1)": [ - "CRY-04", - "CRY-05" + "AU-3": [ + "MON-03" ], - "SC-28": [ - "CRY-05", - "END-02" + "AU-12": [ + "MON-06" ], "AC-18": [ "CRY-07", "NET-15" ], - "SC-40": [ - "CRY-07", - "NET-12.1" + "MP-6": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "SC-12": [ - "CRY-08" + "AC-20": [ + "DCH-13" ], - "SC-12(4)": [ - "CRY-08" + "AC-22": [ + "DCH-15" ], - "SC-12(5)": [ - "CRY-08" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "SC-17": [ - "CRY-08" + "SI-3": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "SC-12(2)": [ - "CRY-09.1" + "SI-2": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "SC-12(3)": [ - "CRY-09.2" + "SI-7": [ + "END-06", + "NET-12", + "TDA-18" ], - "SC-12(1)": [ - "CRY-09.3" + "PS-3": [ + "HRS-04" ], - "SC-16": [ - "CRY-10" + "PL-4": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "SC-23(5)": [ - "CRY-11" + "PS-6": [ + "HRS-06", + "HRS-06.1" ], - "MP-1": [ - "DCH-01" + "PS-7": [ + "HRS-10" ], - "MP-2": [ - "DCH-03", - "END-01" + "IA-4": [ + "IAC-01.2", + "IAC-09" ], - "AC-3(9)": [ - "DCH-03.3" + "IA-2": [ + "IAC-02" ], - "MP-3": [ - "DCH-04" + "IA-8": [ + "IAC-03" ], - "AC-16": [ - "DCH-05" + "AC-2": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "MP-4": [ - "DCH-06" + "IA-5": [ + "IAC-10", + "IAC-10.8" ], - "MP-5": [ - "DCH-07" + "AC-3": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "MP-5(3)": [ - "DCH-07.1" + "IR-8": [ + "IRO-04" ], - "MP-5(4)": [ - "DCH-07.2" + "IR-2": [ + "IRO-05" ], - "MP-6": [ - "DCH-08", - "DCH-09" + "IR-5": [ + "IRO-09" ], - "MP-6(3)": [ - "DCH-09", - "DCH-09.4" + "CA-5": [ + "IAO-05" ], - "MP-6(1)": [ - "DCH-09.1" + "CA-6": [ + "IAO-07" ], - "MP-6(2)": [ - "DCH-09.2" + "MA-4": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "MP-6(7)": [ - "DCH-09.5" + "MA-5": [ + "MNT-06" ], - "MP-7": [ - "DCH-10", - "DCH-18" + "SR-11(2)": [ + "MNT-07" ], - "MP-7(1)": [ - "DCH-10.2" + "AC-19": [ + "MDM-02" ], - "MP-8": [ - "DCH-11" + "SC-7": [ + "NET-03" ], - "AC-20": [ - "DCH-13" + "CA-3": [ + "NET-05" ], - "AC-20(1)": [ - "DCH-13.1" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "AC-20(2)": [ - "DCH-13.2" + "AC-17": [ + "NET-14" ], - "AC-20(5)": [ - "DCH-13.2" + "PE-2": [ + "PES-02" ], - "AC-20(3)": [ - "DCH-13.4" + "PE-3": [ + "PES-03" ], - "AC-21": [ - "DCH-14" + "PE-6": [ + "PES-05" ], - "AC-21(2)": [ - "DCH-14.1" + "PE-16": [ + "PES-10" ], - "AC-22": [ - "DCH-15" + "SA-2": [ + "PRM-03" ], - "AC-23": [ - "DCH-16" + "SA-3": [ + "PRM-07", + "SEA-07.1" ], - "SI-12": [ - "DCH-18" + "RA-2": [ + "RSK-02" ], - "DM-2": [ - "DCH-21", - "PRI-05" + "RA-7": [ + "RSK-06.1" ], - "DI-1": [ - "DCH-22" + "PM-30": [ + "RSK-09" ], - "IP-3": [ - "DCH-22.1", - "PRI-06.1" + "SR-2": [ + "RSK-09", + "TPM-03" ], - "DM-1(1)": [ - "DCH-23" + "RA-3(1)": [ + "RSK-09.1" ], - "DM-3(1)": [ - "DCH-23", - "IAC-09.6", - "PRI-05.1", - "PRI-05.4" + "AT-3": [ + "SAT-03" ], - "SI-3": [ - "END-04" + "AT-4": [ + "SAT-04" ], - "SI-3(2)": [ - "END-04.1", - "VPM-01", - "VPM-05" + "SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "SI-3(1)": [ - "END-04.3" + "SR-11": [ + "TDA-11" ], - "SI-3(7)": [ - "END-04.4" + "SR-11(1)": [ + "TDA-11.1" ], - "SI-3(6)": [ - "END-04.5" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "SI-7": [ - "END-06" + "SR-5": [ + "TPM-03.1" ], - "SI-7(1)": [ - "END-06.1" + "SR-3": [ + "TPM-03.3" ], - "SI-7(7)": [ - "END-06.2" + "SR-8": [ + "TPM-05.1" ], - "SI-7(2)": [ - "END-06.3" + "AT-2(2)": [ + "THR-05" ], - "SI-7(5)": [ - "END-06.4" + "RA-5": [ + "VPM-06", + "VPM-06.1" + ] + }, + "general-nist-800-161-r1-flowdown": { + "AC-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "SI-7(9)": [ - "END-06.5" + "IR-1": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "SI-7(10)": [ - "END-06.6" + "MA-1": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "SI-7(14)": [ - "END-06.7" + "PS-1": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "SI-8": [ - "END-08" + "PT-1": [ + "GOV-03", + "PRI-01", + "SEA-01" ], - "SI-8(1)": [ - "END-08.1" + "PM-5": [ + "AST-01", + "AST-02" ], - "SI-8(2)": [ - "END-08.2" + "CM-8": [ + "AST-02", + "AST-02.3" ], - "SC-11": [ - "END-09" + "PL-2": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "SC-18": [ - "END-10" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "SC-18(1)": [ - "END-10", - "VPM-02", - "VPM-04" + "CP-2(7)": [ + "BCD-01.2" ], - "SC-18(3)": [ - "END-10", - "NET-18" + "CP-3": [ + "BCD-03" ], - "SC-27": [ - "END-10" + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" ], - "SC-25": [ - "END-11" + "CM-3": [ + "CHG-01", + "CHG-02" ], - "SC-41": [ - "END-12" + "AC-5": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "SC-42": [ - "END-13" + "CM-9": [ + "CHG-05", + "CFG-01" ], - "SC-42(2)": [ - "END-13.1" + "CM-2": [ + "CFG-02", + "CFG-02.1" ], - "SC-15": [ - "END-14" + "CM-6": [ + "CFG-02", + "CFG-02.7" ], - "SC-15(1)": [ - "END-14" + "CM-7": [ + "CFG-03" ], - "SC-15(3)": [ - "END-14.1" + "SI-4": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "SC-15(4)": [ - "END-14.2" + "AU-2": [ + "MON-01.8", + "MON-02" ], - "SC-3": [ - "END-16", - "SEA-04.1" + "AU-3": [ + "MON-03" + ], + "AU-12": [ + "MON-06" + ], + "AU-13": [ + "MON-11" + ], + "AU-14": [ + "MON-12" ], - "SC-7(12)": [ - "END-16.1" + "AU-16(2)": [ + "MON-14.1" ], - "PS-1": [ - "HRS-01" + "SC-8": [ + "CRY-03", + "CRY-04" ], - "PS-2": [ - "HRS-02", - "HRS-03.2" + "SC-28": [ + "CRY-05", + "END-02" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "MP-4": [ + "DCH-06" ], - "PS-3": [ - "HRS-04" + "MP-6": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "PS-3(1)": [ - "HRS-04.1" + "AC-20": [ + "DCH-13" ], - "PS-3(3)": [ - "HRS-04.1" + "AC-23": [ + "DCH-16", + "PRI-05.4" ], - "PS-3(2)": [ - "HRS-04.2" + "SI-3": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "PL-4": [ - "HRS-05", - "HRS-05.1" + "SI-2": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "PL-4(1)": [ - "HRS-05.2" + "SI-7": [ + "END-06", + "NET-12", + "TDA-18" ], - "SC-19": [ - "HRS-05.3", - "NET-13" + "PS-3": [ + "HRS-04" ], "PS-6": [ "HRS-06", "HRS-06.1" ], - "PS-6(2)": [ - "HRS-06", - "HRS-06.1" + "IA-4": [ + "IAC-01.2", + "IAC-09" ], - "PS-6(3)": [ - "HRS-06.2" + "IA-2": [ + "IAC-02" ], - "PS-8": [ - "HRS-07" + "IA-9": [ + "IAC-05" ], - "PS-5": [ - "HRS-08" + "AC-2": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "PS-4": [ - "HRS-09" + "IA-5": [ + "IAC-10", + "IAC-10.8" ], - "PS-4(1)": [ - "HRS-09.3" + "AC-3": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "PS-4(2)": [ - "HRS-09.4" + "AC-24": [ + "IAC-28.1" ], - "PS-7": [ - "HRS-10" + "IR-8": [ + "IRO-04" ], - "AC-3(2)": [ - "HRS-12.1", - "IAC-20.5" + "IR-2": [ + "IRO-05" ], - "AC-1": [ - "IAC-01" + "IR-4(10)": [ + "IRO-10.4", + "TPM-11" ], - "IA-1": [ - "IAC-01" + "IR-6(3)": [ + "IRO-10.4" ], - "IA-2": [ - "IAC-02" + "IR-7(2)": [ + "IRO-11.2" ], - "IA-2(5)": [ - "IAC-02.1" + "IR-9": [ + "IRO-12", + "IRO-12.1" ], - "IA-2(8)": [ - "IAC-02.2" + "MA-4": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "IA-2(9)": [ - "IAC-02.2" + "MA-5(4)": [ + "MNT-06.1" ], - "IA-2(12)": [ - "IAC-02.3" + "SC-7": [ + "NET-03" ], - "IA-8(5)": [ - "IAC-02.3" + "AC-4": [ + "NET-04" ], - "IA-2(13)": [ - "IAC-02.4" + "CA-3": [ + "NET-05" ], - "IA-8": [ - "IAC-03" + "SC-7(13)": [ + "NET-06.1" ], - "IA-8(1)": [ - "IAC-03.1" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "IA-8(2)": [ - "IAC-03.2" + "AC-17": [ + "NET-14" ], - "IA-8(4)": [ - "IAC-03.3" + "PE-2": [ + "PES-02" ], - "IA-8(3)": [ - "IAC-03.5" + "PM-18": [ + "PRI-01" ], - "IA-3": [ - "IAC-04" + "RA-9": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "IA-3(1)": [ - "IAC-04" + "PM-30": [ + "RSK-09" ], - "IA-9": [ - "IAC-05" + "RA-3(1)": [ + "RSK-09.1" ], - "IA-9(1)": [ - "IAC-05.1" + "SC-36": [ + "SEA-15" ], - "IA-2(11)": [ - "IAC-06", - "IAC-06.4" + "AT-3": [ + "SAT-03" ], - "IA-2(1)": [ - "IAC-06.1" + "SA-21": [ + "TDA-13" ], - "IA-2(4)": [ - "IAC-06.1", - "IAC-06.2" + "SR-3(3)": [ + "TPM-05", + "TPM-05.2" ], - "IA-2(2)": [ - "IAC-06.2" + "AT-2(2)": [ + "THR-05" ], - "IA-2(3)": [ - "IAC-06.3" + "SI-20": [ + "THR-08" ], - "IA-2(6)": [ - "IAC-06.4" + "RA-5": [ + "VPM-06", + "VPM-06.1" + ] + }, + "general-nist-800-161-r1-level-1": { + "AC-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "IA-5(3)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" + "AT-1": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "AC-2(10)": [ - "IAC-07.2" + "AU-1": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "AC-2(7)": [ - "IAC-08" + "CA-1": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "IA-4": [ - "IAC-09" + "CM-1": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "IA-4(4)": [ - "IAC-09.1", - "IAC-09.2" + "CP-1": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "IA-4(5)": [ - "IAC-09.3" + "IA-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "IA-5(2)": [ - "IAC-09.3", - "IAC-10.2" + "IR-1": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "IA-5(10)": [ - "IAC-09.3" + "MA-1": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "IA-4(6)": [ - "IAC-09.4" + "MP-1": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "IA-5(8)": [ - "IAC-09.5", - "IAC-10.9" + "PE-1": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "IA-5": [ - "IAC-10", - "IAC-10.8" + "PS-1": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "IA-5(4)": [ - "IAC-10", - "IAC-10.4" + "RA-1": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "IA-5(1)": [ - "IAC-10.1" + "SC-1": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "IA-5(6)": [ - "IAC-10.5", - "IAC-18" + "SI-1": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "IA-5(7)": [ - "IAC-10.6" + "SR-1": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "IA-5(11)": [ - "IAC-10.7", - "TDA-02.2" + "PT-1": [ + "GOV-03", + "PRI-01", + "SEA-01" ], - "IA-5(5)": [ - "IAC-10.8" + "SA-1": [ + "GOV-03", + "TDA-01", + "TDA-06" ], - "IA-5(13)": [ - "IAC-10.10" + "PL-9": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" ], - "IA-5(12)": [ - "IAC-10.12" + "PM-2": [ + "GOV-04" ], - "IA-6": [ - "IAC-11" + "PM-6": [ + "GOV-04", + "GOV-05" ], - "IA-10": [ - "IAC-13" + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" ], - "IA-11": [ - "IAC-14" + "PM-15": [ + "GOV-07", + "THR-01" ], - "AC-2": [ - "IAC-15" + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" ], - "AC-2(1)": [ - "IAC-15.1" + "PM-8": [ + "BCD-01", + "CPL-01" ], - "AC-2(2)": [ - "IAC-15.2" + "SC-47": [ + "BCD-10.4" ], - "AC-2(3)": [ - "IAC-15.3" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "AC-2(4)": [ - "IAC-15.4" + "RA-3": [ + "CPL-03.2", + "RSK-04" ], - "AC-2(9)": [ - "IAC-15.5" + "SA-8": [ + "CFG-02", + "SEA-01" ], - "AC-2(13)": [ - "IAC-15.6" + "PM-31": [ + "MON-01" ], - "AC-2(11)": [ - "IAC-15.8" + "SI-4": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "AC-6(7)": [ - "IAC-17" + "AU-2": [ + "MON-01.8", + "MON-02" ], - "AC-3": [ - "IAC-20" + "AU-3": [ + "MON-03" ], - "AC-6": [ - "IAC-20", - "IAC-21" + "AC-18": [ + "CRY-07", + "NET-15" ], - "AC-6(1)": [ - "IAC-21.1" + "MP-4": [ + "DCH-06" ], - "AC-6(2)": [ - "IAC-21.2" + "MP-5": [ + "DCH-07" ], - "AC-6(5)": [ - "IAC-21.3" + "AC-20": [ + "DCH-13" ], - "AC-6(9)": [ - "IAC-21.4" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "AC-6(10)": [ - "IAC-21.5" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "AC-6(3)": [ - "IAC-21.6" + "PM-13": [ + "HRS-03", + "SAT-01" ], - "AC-6(8)": [ - "IAC-21.7" + "IA-2": [ + "IAC-02" ], - "AC-7": [ - "IAC-22" + "IA-3": [ + "IAC-04" ], - "AC-10": [ - "IAC-23" + "IA-4(6)": [ + "IAC-09.4" ], - "AC-2(5)": [ - "IAC-24" + "AC-24": [ + "IAC-28.1" ], - "AC-11": [ - "IAC-24" + "IR-4(6)": [ + "IRO-02.2" ], - "AC-11(1)": [ - "IAC-24.1" + "IR-4(7)": [ + "IRO-02.2" ], - "AC-12": [ - "IAC-25" + "PM-10": [ + "IAO-01" ], - "AC-12(1)": [ - "IAC-25.1" + "CA-6": [ + "IAO-07" ], - "AC-14": [ - "IAC-26" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "AC-25": [ - "IAC-27" + "PE-6": [ + "PES-05" ], - "AC-24": [ - "IAC-28.1" + "PE-18": [ + "PES-12" ], - "IA-4(2)": [ - "IAC-28.1" + "PM-18": [ + "PRI-01" ], - "IR-1": [ - "IRO-01", - "IRO-04.2", - "IRO-13" + "PM-19": [ + "PRI-01.1" ], - "IR-4": [ - "IRO-02" + "PM-20": [ + "PRI-01.3" ], - "IR-4(1)": [ - "IRO-02.1" + "PM-21": [ + "PRI-14.1" ], - "IR-4(6)": [ - "IRO-02.2" + "PM-3": [ + "PRM-02" ], - "IR-4(2)": [ - "IRO-02.3" + "SA-2": [ + "PRM-03" ], - "IR-4(8)": [ - "IRO-02.5" + "RA-9": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "IR-8": [ - "IRO-04" + "PM-11": [ + "PRM-06" ], - "SE-2": [ - "IRO-04.1" + "SA-3": [ + "PRM-07", + "SEA-07.1" ], - "IR-2": [ - "IRO-05" + "PM-9": [ + "RSK-01" ], - "IR-2(1)": [ - "IRO-05.1" + "PM-28": [ + "RSK-01.1" ], - "IR-2(2)": [ - "IRO-05.2" + "RA-2": [ + "RSK-02" ], - "IR-3": [ - "IRO-06" + "RA-7": [ + "RSK-06.1" ], - "SI-4(9)": [ - "IRO-06" + "PM-30": [ + "RSK-09" ], - "IR-3(2)": [ - "IRO-06.1" + "SA-9(3)": [ + "RSK-09", + "TPM-02", + "TPM-03", + "TPM-05", + "TPM-05.4", + "TPM-05.7" ], - "IR-10": [ - "IRO-07" + "RA-3(1)": [ + "RSK-09.1" ], - "AU-10(3)": [ - "IRO-08" + "PM-7": [ + "SEA-02" ], - "IR-5": [ - "IRO-09" + "SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "IR-5(1)": [ - "IRO-09.1" + "SA-11": [ + "TDA-09" ], - "IR-6(1)": [ - "IRO-10.1" + "SR-11": [ + "TDA-11" ], - "IR-6(2)": [ - "IRO-10.3" + "SR-5": [ + "TPM-03.1" ], - "IR-6(3)": [ - "IRO-10.4" + "SR-3": [ + "TPM-03.3" ], - "IR-7": [ - "IRO-11" + "PM-16": [ + "THR-01" ], - "IR-7(1)": [ - "IRO-11.1" + "PM-12": [ + "THR-04" ], - "IR-7(2)": [ - "IRO-11.2" + "RA-10": [ + "THR-07" + ] + }, + "general-nist-800-161-r1-level-2": { + "AC-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "IR-9": [ - "IRO-12" + "AT-1": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "IR-9(1)": [ - "IRO-12.1" + "AU-1": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "IR-9(2)": [ - "IRO-12.2" + "CA-1": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "IR-9(3)": [ - "IRO-12.3" + "CM-1": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "IR-9(4)": [ - "IRO-12.4" + "CP-1": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "SC-44": [ - "IRO-15" + "IA-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "CA-1": [ - "IAO-01" + "IR-1": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "PM-10": [ - "IAO-01" + "MA-1": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "CA-2(1)": [ - "IAO-02.1" + "MP-1": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "CA-2(2)": [ - "IAO-02.2" + "PE-1": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "CA-2(3)": [ - "IAO-02.3" + "PL-1": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "PL-2(3)": [ - "IAO-03.1" + "PS-1": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "CA-5": [ - "IAO-05" + "RA-1": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "PM-4": [ - "IAO-05", - "VPM-02" + "SC-1": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "CA-5(1)": [ - "IAO-05.1" + "SI-1": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "CM-4(2)": [ - "IAO-06" + "SR-1": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "CA-6": [ - "IAO-07" + "PT-1": [ + "GOV-03", + "PRI-01", + "SEA-01" ], - "MA-1": [ - "MNT-01" + "SA-1": [ + "GOV-03", + "TDA-01", + "TDA-06" ], - "MA-2": [ - "MNT-02" + "PL-9": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" ], - "MA-2(2)": [ - "MNT-02.1" + "PM-2": [ + "GOV-04" ], - "MA-6": [ - "MNT-03" + "PM-6": [ + "GOV-04", + "GOV-05" ], - "MA-6(1)": [ - "MNT-03.1" + "PM-15": [ + "GOV-07", + "THR-01" ], - "MA-6(2)": [ - "MNT-03.2" + "PM-32": [ + "GOV-11" ], - "MA-6(3)": [ - "MNT-03.3" + "PM-5": [ + "AST-01", + "AST-02" ], - "MA-3": [ - "MNT-04" + "CM-8": [ + "AST-02", + "AST-02.3" ], - "MA-3(1)": [ - "MNT-04.1" + "CM-13": [ + "AST-02.8" ], - "MA-3(2)": [ - "MNT-04.2" + "CM-8(8)": [ + "AST-02.10" ], - "MA-3(3)": [ - "MNT-04.3" + "SR-4": [ + "AST-03.2" ], - "MA-3(4)": [ - "MNT-04.4" + "SR-12": [ + "AST-09", + "TDA-11.2" ], - "MA-4": [ - "MNT-05" + "SR-9": [ + "AST-15" ], - "MA-4(1)": [ - "MNT-05.1" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "MA-4(2)": [ - "MNT-05.2" + "CP-2": [ + "BCD-01", + "BCD-06" ], - "MA-4(6)": [ - "MNT-05.3" + "CP-2(1)": [ + "BCD-01.1" ], - "MA-4(7)": [ - "MNT-05.4" + "CP-3": [ + "BCD-03" ], - "MA-4(5)": [ - "MNT-05.5" + "CP-3(1)": [ + "BCD-03.1" ], - "MA-4(3)": [ - "MNT-05.6" + "CP-4": [ + "BCD-04", + "BCD-05" ], - "MA-4(4)": [ - "MNT-05.7" + "CP-6": [ + "BCD-08" ], - "MA-5": [ - "MNT-06" + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" ], - "MA-5(1)": [ - "MNT-06.1" + "CP-6(1)": [ + "BCD-08.1" ], - "MA-5(2)": [ - "MNT-06.1" + "CP-7": [ + "BCD-09" ], - "MA-5(3)": [ - "MNT-06.1" + "CP-8": [ + "BCD-10" ], - "MA-5(4)": [ - "MNT-06.1" + "CP-11": [ + "BCD-10" ], - "MA-5(5)": [ - "MNT-06.2" + "CP-8(3)": [ + "BCD-10.2" ], - "AC-19": [ - "MDM-02" + "CP-8(4)": [ + "BCD-10.3" ], - "AC-19(5)": [ - "MDM-03" + "SC-47": [ + "BCD-10.4" ], - "PE-3(5)": [ - "MDM-04" + "SC-5(2)": [ + "CAP-02", + "CAP-03" ], - "AC-7(2)": [ - "MDM-05" + "CP-2(2)": [ + "CAP-03" ], - "MP-6(8)": [ - "MDM-05" + "CM-3": [ + "CHG-01", + "CHG-02" ], - "SC-1": [ - "NET-01", - "SEA-01" + "CM-3(1)": [ + "CHG-02.1" ], - "SC-7": [ - "NET-03" + "CM-3(2)": [ + "CHG-02.2", + "CHG-06" ], - "SC-7(9)": [ - "NET-03", - "NET-03.2" + "CM-3(4)": [ + "CHG-02.3" ], - "SC-7(11)": [ - "NET-03", - "NET-04.1" + "CM-5": [ + "CHG-04", + "END-03.2" ], - "SC-7(3)": [ - "NET-03.1" + "AC-5": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "SC-7(4)": [ - "NET-03.2" + "CM-9": [ + "CHG-05", + "CFG-01" ], - "SC-7(16)": [ - "NET-03.3" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "SC-7(10)": [ - "NET-03.5", - "NET-17" + "CA-2": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "SC-7(20)": [ - "NET-03.6" + "RA-3": [ + "CPL-03.2", + "RSK-04" ], - "SC-7(21)": [ - "NET-03.7" + "CM-9(1)": [ + "CFG-01.1" ], - "SC-7(22)": [ - "NET-03.8" + "CM-2": [ + "CFG-02", + "CFG-02.1" ], - "AC-4": [ - "NET-04" + "CM-6": [ + "CFG-02", + "CFG-02.7" ], - "CA-3(5)": [ - "NET-04.1" + "PL-10": [ + "CFG-02" ], - "SC-7(5)": [ - "NET-04.1" + "SA-8": [ + "CFG-02", + "SEA-01" ], - "AC-4(1)": [ - "NET-04.2" + "CM-2(6)": [ + "CFG-02.4" ], - "AC-4(4)": [ - "NET-04.3" + "CM-7(6)": [ + "CFG-02.5" ], - "AC-4(5)": [ - "NET-04.4" + "CM-7(9)": [ + "CFG-02.5" ], - "AC-4(6)": [ - "NET-04.5" + "CM-7(1)": [ + "CFG-03.1" ], - "AC-4(9)": [ - "NET-04.6" + "CM-7(4)": [ + "CFG-03.3" ], - "AC-4(8)": [ - "NET-04.7" + "CM-10": [ + "CFG-04" ], - "AC-4(12)": [ - "NET-04.8" + "CM-10(1)": [ + "CFG-04.1" ], - "AC-4(13)": [ - "NET-04.9" + "CM-11": [ + "CFG-05", + "END-03" ], - "AC-4(15)": [ - "NET-04.10" + "CM-3(8)": [ + "CFG-06" ], - "AC-4(20)": [ - "NET-04.11" + "PM-31": [ + "MON-01" ], - "CA-3": [ - "NET-05" + "SI-4": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "CA-3(1)": [ - "NET-05" + "AU-2": [ + "MON-01.8", + "MON-02" ], - "CA-3(2)": [ - "NET-05" + "SI-4(19)": [ + "MON-01.14" ], - "CA-3(3)": [ - "NET-05.1" + "AU-6": [ + "MON-02", + "MON-02.6" ], - "CA-9": [ - "NET-05.2" + "SI-4(17)": [ + "MON-02.3" ], - "AC-4(21)": [ - "NET-06" + "AU-3": [ + "MON-03" ], - "SC-7(13)": [ - "NET-06.1" + "AU-12": [ + "MON-06" + ], + "AU-10(1)": [ + "MON-09.1" ], - "SC-10": [ - "NET-07" + "AU-10(2)": [ + "MON-09.1" ], - "SC-23": [ - "NET-09" + "AU-13": [ + "MON-11" ], - "SC-23(1)": [ - "NET-09.1" + "AU-14": [ + "MON-12" ], - "SC-23(3)": [ - "NET-09.2" + "AU-16": [ + "MON-14" ], - "SC-20": [ - "NET-10" + "AU-16(2)": [ + "MON-14.1" ], - "SC-20(2)": [ - "NET-10" + "SC-8": [ + "CRY-03", + "CRY-04" ], - "SC-22": [ - "NET-10.1" + "SC-28": [ + "CRY-05", + "END-02" ], - "SC-21": [ - "NET-10.2" + "AC-18": [ + "CRY-07", + "NET-15" ], - "SC-37": [ - "NET-11" + "AC-3(9)": [ + "DCH-03.3" ], - "SC-37(1)": [ - "NET-11" + "MP-4": [ + "DCH-06" ], - "SC-8(3)": [ - "NET-13" + "MP-5": [ + "DCH-07" ], - "AC-17": [ - "NET-14" + "MP-6": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "AC-17(6)": [ - "NET-14" + "AC-20": [ + "DCH-13" ], - "AC-17(1)": [ - "NET-14.1" + "AC-20(1)": [ + "DCH-13.1" ], - "AC-17(2)": [ - "NET-14.2" + "PM-17": [ + "DCH-13.3" ], - "AC-17(3)": [ - "NET-14.3" + "AC-20(3)": [ + "DCH-13.4" ], - "AC-17(4)": [ - "NET-14.4" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "AC-17(9)": [ - "NET-14.8" + "AC-22": [ + "DCH-15" ], - "AC-18(1)": [ - "NET-15.1" + "AC-23": [ + "DCH-16", + "PRI-05.4" ], - "AC-18(3)": [ - "NET-15.2" + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" ], - "AC-18(4)": [ - "NET-15.3" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "AC-18(5)": [ - "NET-15.4" + "CM-12": [ + "DCH-24" ], - "SC-7(8)": [ - "NET-18", - "NET-18.1" + "CM-12(1)": [ + "DCH-24.1" ], - "PE-1": [ - "PES-01" + "SI-3": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "PE-2": [ - "PES-02" + "SI-2": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "PE-2(1)": [ - "PES-02.1" + "SI-7": [ + "END-06", + "NET-12", + "TDA-18" ], - "PE-3": [ - "PES-03" + "CM-7(8)": [ + "END-06.7" ], - "PE-3(2)": [ - "PES-03" + "SI-7(14)": [ + "END-06.7" ], - "PE-3(3)": [ - "PES-03" + "SC-27": [ + "END-10" ], - "PE-3(4)": [ - "PES-03.2" + "PM-13": [ + "HRS-03", + "SAT-01" ], - "SC-7(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "PS-3": [ + "HRS-04" ], - "PE-8": [ - "PES-03.3" + "PL-4": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "PE-3(1)": [ - "PES-03.4" + "PS-6": [ + "HRS-06", + "HRS-06.1" ], - "PE-6": [ - "PES-05" + "PS-7": [ + "HRS-10" ], - "PE-6(1)": [ - "PES-05.1" + "IA-4": [ + "IAC-01.2", + "IAC-09" ], - "PE-6(4)": [ - "PES-05.2" + "IA-2": [ + "IAC-02" ], - "PE-2(2)": [ - "PES-06.2" + "IA-8": [ + "IAC-03" ], - "PE-2(3)": [ - "PES-06.3" + "IA-3": [ + "IAC-04" ], - "PE-8(1)": [ - "PES-06.4" + "IA-9": [ + "IAC-05" ], - "PE-9": [ - "PES-07" + "AC-6(6)": [ + "IAC-05.2" ], - "PE-9(2)": [ - "PES-07.1" + "AC-2": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "PE-10": [ - "PES-07.2" + "IA-4(6)": [ + "IAC-09.4" ], - "PE-11": [ - "PES-07.3" + "IA-5": [ + "IAC-10", + "IAC-10.8" ], - "PE-11(1)": [ - "PES-07.3" + "AC-3": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "PE-11(2)": [ - "PES-07.3" + "AC-3(8)": [ + "IAC-20.6" ], - "PE-12": [ - "PES-07.4" + "AC-24": [ + "IAC-28.1" ], - "PE-15": [ - "PES-07.5" + "IR-4(6)": [ + "IRO-02.2" ], - "PE-15(1)": [ - "PES-07.6" + "IR-4(7)": [ + "IRO-02.2" ], - "PE-9(1)": [ - "PES-07.7" + "IR-8": [ + "IRO-04" ], - "PE-13": [ - "PES-08" + "IR-2": [ + "IRO-05" ], - "PE-13(1)": [ - "PES-08.1" + "IR-3": [ + "IRO-06" ], - "PE-13(2)": [ - "PES-08.2" + "AU-10(3)": [ + "IRO-08" ], - "PE-13(3)": [ - "PES-08.3" + "IR-5": [ + "IRO-09" ], - "PE-14": [ - "PES-09" + "IR-4(10)": [ + "IRO-10.4", + "TPM-11" ], - "PE-14(2)": [ - "PES-09.1" + "PM-10": [ + "IAO-01" ], - "PE-16": [ - "PES-10" + "CA-5": [ + "IAO-05" ], - "PE-17": [ - "PES-11" + "PM-4": [ + "IAO-05", + "VPM-02" ], - "PE-18": [ - "PES-12" + "CA-6": [ + "IAO-07" ], - "PE-18(1)": [ - "PES-12" + "MA-3": [ + "MNT-04" ], - "PE-4": [ - "PES-12.1" + "MA-4": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "PE-5": [ - "PES-12.2" + "MA-4(3)": [ + "MNT-05.6" ], - "PE-19": [ - "PES-13" + "MA-5": [ + "MNT-06" ], - "PE-20": [ - "PES-14" + "MA-5(4)": [ + "MNT-06.1" ], - "AR-1": [ - "PRI-01.1" + "SR-11(2)": [ + "MNT-07" ], - "TR-2": [ - "PRI-01.2", - "PRI-02" + "AC-19": [ + "MDM-02" ], - "TR-3": [ - "PRI-01.3" + "PE-3(5)": [ + "MDM-04" ], - "TR-1": [ - "PRI-02" + "SC-7": [ + "NET-03" ], - "AP-2": [ - "PRI-02.1" + "AC-4": [ + "NET-04" ], - "DI-2(1)": [ - "PRI-02.3" + "AC-4(6)": [ + "NET-04.5" ], - "TR-2(1)": [ - "PRI-02.4" + "AC-4(17)": [ + "NET-04.12" ], - "TR-1(1)": [ - "PRI-02.7" + "AC-4(19)": [ + "NET-04.13" ], - "IP-1": [ - "PRI-03" + "SC-37(1)": [ + "NET-11" ], - "IP-(1)": [ - "PRI-03.1" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "AP-1": [ - "PRI-04", - "PRI-04.1" + "AC-17": [ + "NET-14" ], - "DI-1(1)": [ - "PRI-04.5" + "AC-17(6)": [ + "NET-14" ], - "DI-1(2)": [ - "PRI-04.6" + "PE-2": [ + "PES-02" ], - "DM-1": [ - "PRI-05.1" + "PE-2(1)": [ + "PES-02.1" ], - "DM-3": [ - "PRI-05.1" + "PE-3": [ + "PES-03" ], - "DI-2": [ - "PRI-05.2" + "PE-3(2)": [ + "PES-03" ], - "UL-1": [ - "PRI-05.4" + "SC-7(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" ], - "SE-1": [ - "PRI-05.5" + "PE-3(1)": [ + "PES-03.4" ], - "IP-2": [ - "PRI-06" + "PE-6": [ + "PES-05" ], - "IP-4": [ - "PRI-06.4", - "OPS-03" + "PE-18": [ + "PES-12" ], - "IP-4(1)": [ - "PRI-06.4", - "OPS-03" + "PE-20": [ + "PES-14" ], - "UL-2": [ - "PRI-07" + "PM-18": [ + "PRI-01" ], - "AR-3": [ - "PRI-07.1" + "PM-20": [ + "PRI-01.3" ], - "AR-4": [ - "PRI-08" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "AR-6": [ + "PM-27": [ "PRI-14" ], - "AR-8": [ + "PM-21": [ "PRI-14.1" ], "PM-3": [ @@ -161250,8 +178846,9 @@ "SA-2": [ "PRM-03" ], - "SA-14": [ + "RA-9": [ "PRM-05", + "TDA-06.1", "TPM-02" ], "PM-11": [ @@ -161261,33 +178858,29 @@ "PRM-07", "SEA-07.1" ], - "PM-9": [ - "RSK-01" - ], - "RA-1": [ - "RSK-01" - ], "RA-2": [ "RSK-02" ], - "SA-12": [ - "RSK-09", - "TPM-03" - ], - "AR-2": [ - "RSK-10" + "RA-7": [ + "RSK-06.1" ], - "AR-7": [ - "SEA-01" + "PM-30": [ + "RSK-09" ], - "SA-13": [ - "SEA-01" + "SA-9(3)": [ + "RSK-09", + "TPM-02", + "TPM-03", + "TPM-05", + "TPM-05.4", + "TPM-05.7" ], - "SC-7(18)": [ - "SEA-01" + "SR-7": [ + "RSK-09", + "OPS-01" ], - "SI-1": [ - "SEA-01" + "RA-3(1)": [ + "RSK-09.1" ], "PL-8": [ "SEA-02" @@ -161295,72 +178888,21 @@ "PM-7": [ "SEA-02" ], - "PL-8(1)": [ - "SEA-03" - ], - "SC-3(5)": [ - "SEA-03" - ], - "SC-32": [ - "SEA-03.1" - ], - "SC-2": [ - "SEA-03.2" - ], - "SC-2(1)": [ - "SEA-03.2" - ], - "SC-39": [ - "SEA-04" - ], - "SC-39(1)": [ - "SEA-04.2" - ], - "SC-39(2)": [ - "SEA-04.3" - ], "SC-4": [ "SEA-05" ], - "SI-13": [ - "SEA-07" - ], - "CP-12": [ - "SEA-07.2" - ], - "SC-24": [ - "SEA-07.2" - ], - "SI-17": [ - "SEA-07.3" - ], - "SI-14": [ - "SEA-08" - ], - "SI-14(1)": [ - "SEA-08.1" - ], - "SI-15": [ - "SEA-09" - ], - "SI-16": [ - "SEA-10" - ], - "SC-26": [ - "SEA-11" - ], - "SC-35": [ - "SEA-12" - ], "SC-29": [ "SEA-13" ], - "SC-29(1)": [ - "SEA-13.1" - ], "SC-30": [ "SEA-14" ], + "SC-30(4)": [ + "SEA-14" + ], + "SC-30(5)": [ + "SEA-14" + ], "SC-30(2)": [ "SEA-14.1" ], @@ -161370,88 +178912,67 @@ "SC-36": [ "SEA-15" ], - "SC-34": [ - "SEA-16" - ], - "AC-8": [ - "SEA-18" - ], - "AC-9": [ - "SEA-19" - ], "SC-38": [ "OPS-01", "OPS-04" ], - "PL-7": [ - "OPS-02" - ], - "AT-1": [ - "SAT-01" - ], - "AT-2": [ - "SAT-02" - ], "AT-2(1)": [ "SAT-02.1" ], + "AT-2(3)": [ + "SAT-02.2" + ], "AT-3": [ "SAT-03" ], - "AT-3(3)": [ - "SAT-03.1" + "AT-3(2)": [ + "SAT-03" ], - "AT-3(4)": [ + "AT-3(6)": [ + "SAT-03", + "THR-01", + "THR-03" + ], + "AT-2(4)": [ "SAT-03.2" ], - "AR-5": [ - "SAT-03.3" + "AT-2(5)": [ + "SAT-03.2" + ], + "AT-2(6)": [ + "SAT-03.6" ], "AT-4": [ "SAT-04" ], - "SA-1": [ - "TDA-01", - "TDA-06" - ], "SA-4": [ "TDA-01", "TDA-02", "TPM-01", "TPM-10" ], - "SA-4(9)": [ - "TDA-02.1" - ], - "SA-4(10)": [ + "SA-4(7)": [ "TDA-02.2" ], - "SA-4(3)": [ - "TDA-02.3" - ], - "SA-4(6)": [ - "TDA-03" + "SR-3(1)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" ], "PL-8(2)": [ "TDA-03.1" ], - "SA-5": [ - "TDA-04" - ], - "SA-4(1)": [ - "TDA-04.1" - ], - "SA-4(2)": [ - "TDA-04.1" - ], "SA-17": [ "TDA-05" ], "SA-15": [ "TDA-06" ], - "CM-4(1)": [ - "TDA-08" + "SA-15(3)": [ + "TDA-06.1" + ], + "SA-15(4)": [ + "TDA-06.2" ], "SA-11": [ "TDA-09" @@ -161459,25 +178980,13 @@ "SA-4(8)": [ "TDA-09.1" ], - "SA-11(1)": [ - "TDA-09.2" - ], - "SA-11(8)": [ - "TDA-09.3" - ], - "SA-11(4)": [ - "TDA-09.7" - ], - "SA-15(9)": [ - "TDA-10" - ], - "SA-12(10)": [ + "SR-11": [ "TDA-11" ], - "SA-19": [ + "SR-11(3)": [ "TDA-11" ], - "SA-19(1)": [ + "SR-11(1)": [ "TDA-11.1" ], "SA-20": [ @@ -161486,1044 +178995,463 @@ "SA-21": [ "TDA-13" ], + "SA-21(1)": [ + "TDA-13" + ], "SA-10": [ "TDA-14" ], - "SA-10(1)": [ - "TDA-14.1" - ], - "SA-10(3)": [ - "TDA-14.2" - ], - "SA-11(2)": [ - "TDA-15" - ], "SA-16": [ "TDA-16" ], "SA-22": [ - "TDA-17" - ], - "SA-22(1)": [ + "TDA-17", "TDA-17.1" ], - "SI-10": [ - "TDA-18" - ], - "SI-11": [ - "TDA-19" + "SR-13": [ + "TPM-01.1" ], - "SA-12(1)": [ + "SR-5": [ "TPM-03.1" ], - "SA-12(5)": [ - "TPM-03.2" - ], - "SA-12(15)": [ + "SR-3": [ "TPM-03.3" ], - "SA-9": [ - "TPM-04" - ], "SA-9(1)": [ "TPM-04.1" ], - "SA-9(2)": [ - "TPM-04.2" - ], - "SA-9(4)": [ - "TPM-04.3" + "SR-3(3)": [ + "TPM-05", + "TPM-05.2" ], - "SA-9(3)": [ - "TPM-05" + "SR-8": [ + "TPM-05.1" ], - "SA-12(2)": [ + "SR-6": [ "TPM-08" ], "PM-16": [ "THR-01" ], - "SI-5": [ - "THR-03" - ], - "SI-5(1)": [ - "THR-03" - ], "PM-12": [ "THR-04" ], "AT-2(2)": [ "THR-05" ], - "SI-2": [ - "VPM-01", - "VPM-05" - ], - "SI-2(1)": [ - "VPM-05.1" - ], - "SI-2(2)": [ - "VPM-05.2" + "RA-10": [ + "THR-07" ], - "SI-2(3)": [ - "VPM-05.3" + "SI-20": [ + "THR-08" ], "SI-2(5)": [ "VPM-05.4" ], - "SI-2(6)": [ - "VPM-05.5" - ], "RA-5": [ - "VPM-06" - ], - "RA-5(1)": [ - "VPM-06.1" - ], - "RA-5(2)": [ + "VPM-06", "VPM-06.1" ], "RA-5(3)": [ "VPM-06.2" ], - "RA-5(5)": [ - "VPM-06.3" - ], "RA-5(6)": [ "VPM-06.4" - ], - "RA-5(8)": [ - "VPM-06.5" - ], - "RA-5(4)": [ - "VPM-06.8" - ], - "RA-5(10)": [ - "VPM-06.9" - ], - "CA-8": [ - "VPM-07" - ], - "CA-8(1)": [ - "VPM-07.1" - ], - "RA-6": [ - "VPM-08" - ], - "CA-8(2)": [ - "VPM-10" - ], - "SC-7(17)": [ - "WEB-03" ] }, - "general-nist-800-53-r5-2": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" - ], - "AC-01": [ + "general-nist-800-161-r1-level-3": { + "AC-1": [ "GOV-02", "GOV-03", "IAC-01" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" - ], - "AU-01": [ + "AU-1": [ "GOV-02", "GOV-03", "MON-01" ], - "CA-01": [ + "CA-1": [ "GOV-02", "GOV-03", "IAO-01" ], - "CM-01": [ + "CM-1": [ "GOV-02", "GOV-03", "CFG-01" ], - "CP-01": [ + "CP-1": [ "GOV-02", "GOV-03", "BCD-01" ], - "IA-01": [ + "IA-1": [ "GOV-02", "GOV-03", "IAC-01" ], - "IR-01": [ + "IR-1": [ "GOV-02", "GOV-03", "IRO-01", "IRO-04.2", "IRO-13" ], - "MA-01": [ + "MA-1": [ "GOV-02", "GOV-03", "MNT-01", "MNT-05.1", "MNT-05.2" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" - ], - "PE-01": [ + "PE-1": [ "GOV-02", "GOV-03", "PES-01" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" - ], - "PS-01": [ + "PS-1": [ "GOV-02", "GOV-03", "HRS-01" ], - "PT-01": [ - "GOV-02", - "GOV-03", - "PRI-01", - "SEA-01" - ], - "RA-01": [ + "RA-1": [ "GOV-02", "GOV-03", "RSK-01" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" - ], - "SC-01": [ + "SC-1": [ "GOV-02", "GOV-03", "NET-01", "SEA-01" ], - "SI-01": [ + "SI-1": [ "GOV-02", "GOV-03", "SEA-01" ], - "SR-01": [ + "SR-1": [ "GOV-02", "GOV-03", "TPM-01" ], - "PL-09": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" - ], - "PM-02": [ - "GOV-04" - ], - "PM-06": [ - "GOV-04", - "GOV-05" - ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" - ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" - ], - "PM-15": [ - "GOV-07", - "THR-01" - ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "PT-1": [ + "GOV-03", + "PRI-01", + "SEA-01" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "SA-1": [ + "GOV-03", + "TDA-01", + "TDA-06" ], "PM-32": [ "GOV-11" ], - "PM-05": [ + "PM-5": [ "AST-01", "AST-02" ], - "CM-08": [ + "CM-8": [ "AST-02", "AST-02.3" ], - "CM-08(01)": [ + "CM-8(1)": [ "AST-02.1" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" - ], - "CM-08(06)": [ + "CM-8(6)": [ "AST-02.4" ], - "IA-03(03)": [ - "AST-02.5" - ], - "SC-07(19)": [ + "SC-7(19)": [ "AST-02.5" ], - "SC-18(02)": [ + "SC-18(2)": [ "AST-02.7", "END-10" ], "CM-13": [ "AST-02.8" ], - "CM-08(02)": [ + "CM-8(2)": [ "AST-02.9" ], - "CM-08(07)": [ + "CM-8(7)": [ "AST-02.9" ], - "CM-08(08)": [ + "CM-8(8)": [ "AST-02.10" ], - "CM-08(09)": [ + "CM-8(9)": [ "AST-02.11" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" - ], - "CM-08(04)": [ + "CM-8(4)": [ "AST-03.1" ], - "SR-04": [ - "AST-03.2" - ], - "SR-04(01)": [ - "AST-03.2" - ], - "SR-04(02)": [ + "SR-4": [ "AST-03.2" ], - "PL-02": [ + "PL-2": [ "AST-04", "IAO-03", "IAO-03.1" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" - ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" - ], - "PE-22": [ - "AST-04.1", - "PES-16" - ], - "SA-05": [ + "SA-5": [ "AST-04.1", "TDA-04" ], "SR-12": [ - "AST-09" - ], - "SC-43": [ - "AST-14" - ], - "SR-09": [ - "AST-15" + "AST-09", + "TDA-11.2" ], - "SR-09(01)": [ + "SR-9": [ "AST-15" ], "SR-10": [ "AST-15.1", "TDA-11" ], - "CP-02": [ + "CP-2": [ "BCD-01", "BCD-06" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" - ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" - ], - "PM-08": [ - "BCD-01", - "CPL-01" - ], - "CP-02(01)": [ + "CP-2(1)": [ "BCD-01.1" ], - "CP-02(07)": [ + "CP-2(7)": [ "BCD-01.2" ], - "CP-02(06)": [ - "BCD-01.3" - ], - "CP-06(02)": [ - "BCD-01.4" - ], - "CP-02(08)": [ + "CP-2(8)": [ "BCD-02" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" - ], - "CP-02(05)": [ - "BCD-02.2" - ], - "CP-03": [ - "BCD-03" - ], - "CP-03(01)": [ - "BCD-03.1" - ], - "CP-03(02)": [ - "BCD-03.2" - ], - "CP-04": [ - "BCD-04", - "BCD-05" - ], - "CP-04(01)": [ - "BCD-04.1" - ], - "CP-04(02)": [ - "BCD-04.2" - ], - "CP-13": [ - "BCD-07" - ], - "CP-06": [ - "BCD-08" - ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" - ], - "CP-06(01)": [ - "BCD-08.1" - ], - "CP-06(03)": [ - "BCD-08.2" - ], - "CP-07": [ - "BCD-09" - ], - "CP-07(01)": [ - "BCD-09.1" - ], - "CP-07(02)": [ - "BCD-09.2" - ], - "CP-07(03)": [ - "BCD-09.3" - ], - "CP-07(04)": [ - "BCD-09.4" - ], - "CP-07(06)": [ - "BCD-09.5" - ], - "CP-08": [ - "BCD-10" - ], - "CP-08(02)": [ - "BCD-10" - ], - "CP-11": [ - "BCD-10" - ], - "CP-08(01)": [ - "BCD-10.1" - ], - "CP-08(03)": [ - "BCD-10.2" - ], - "CP-08(04)": [ - "BCD-10.3" - ], - "SC-47": [ - "BCD-10.4" - ], - "CP-09": [ - "BCD-11" - ], - "SC-28(02)": [ - "BCD-11", - "CRY-05.2" - ], - "CP-09(01)": [ - "BCD-11.1" - ], - "CP-09(03)": [ - "BCD-11.2" - ], - "CP-09(08)": [ - "BCD-11.4" - ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" - ], - "CP-09(02)": [ - "BCD-11.5" - ], - "CP-09(05)": [ - "BCD-11.6" - ], - "CP-09(06)": [ - "BCD-11.7" + "CP-3": [ + "BCD-03" ], - "CP-09(07)": [ - "BCD-11.8" + "CP-3(1)": [ + "BCD-03.1" ], - "CP-10(02)": [ - "BCD-12.1" + "CP-4": [ + "BCD-04", + "BCD-05" ], - "SI-13": [ - "BCD-12.2", - "SEA-07" + "CP-6": [ + "BCD-08" ], - "CP-10(04)": [ - "BCD-12.4" + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" ], - "CP-10(06)": [ - "BCD-13" + "CP-6(1)": [ + "BCD-08.1" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "CP-7": [ + "BCD-09" ], - "SC-05(03)": [ - "CAP-01" + "CP-8": [ + "BCD-10" ], - "SC-05(01)": [ - "CAP-02" + "CP-11": [ + "BCD-10" ], - "SC-05(02)": [ - "CAP-02", - "CAP-03" + "CP-8(3)": [ + "BCD-10.2" ], - "SC-06": [ - "CAP-02" + "CP-8(4)": [ + "BCD-10.3" ], - "CP-02(02)": [ + "SC-47": [ + "BCD-10.4" + ], + "CP-2(2)": [ "CAP-03" ], - "CM-03": [ + "CM-3": [ "CHG-01", "CHG-02" ], - "SA-08(31)": [ - "CHG-02", - "CHG-02.2", - "CHG-06" - ], - "CM-03(01)": [ + "CM-3(1)": [ "CHG-02.1" ], - "CM-03(02)": [ + "CM-3(2)": [ "CHG-02.2", "CHG-06" ], - "CM-03(07)": [ - "CHG-02.2" - ], - "CM-03(04)": [ + "CM-3(4)": [ "CHG-02.3" ], - "CM-03(05)": [ - "CHG-02.4" - ], - "CM-03(06)": [ - "CHG-02.5" - ], - "CM-04": [ + "CM-4": [ "CHG-03" ], - "CM-05": [ + "CM-5": [ "CHG-04", "END-03.2" ], - "CM-05(01)": [ + "CM-5(1)": [ "CHG-04.1" ], "CM-14": [ "CHG-04.2" ], - "SI-07(15)": [ + "SI-7(15)": [ "CHG-04.2" ], - "AC-05": [ + "AC-5": [ "CHG-04.3", "HRS-11", "NET-12", "TDA-18" ], - "CM-05(04)": [ - "CHG-04.3" - ], - "CM-05(05)": [ - "CHG-04.4" - ], - "CM-05(06)": [ + "CM-5(6)": [ "CHG-04.5" ], - "CM-09": [ + "CM-9": [ "CHG-05", "CFG-01" ], - "SI-06": [ - "CHG-06" - ], - "SI-06(03)": [ - "CHG-06.1" - ], - "SC-07(29)": [ - "CLD-03", - "NET-03.8", - "NET-06.1" - ], - "SA-09(05)": [ + "SA-9(5)": [ "CLD-09", "DCH-19", "TPM-04.4" ], - "SA-09(08)": [ - "CLD-09", - "DCH-19" - ], - "CA-07": [ - "CPL-02" - ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" - ], - "PM-14": [ - "CPL-02", - "PRI-08" - ], - "CA-02": [ + "CA-2": [ "CPL-03", "CPL-03.2", "IAO-02", "IAO-06", "PRM-04" ], - "RA-03": [ + "RA-3": [ "CPL-03.2", "RSK-04" ], - "CM-09(01)": [ + "CM-9(1)": [ "CFG-01.1" ], - "CM-02": [ + "CM-2": [ "CFG-02", "CFG-02.1" ], - "CM-06": [ + "CM-6": [ "CFG-02", "CFG-02.7" ], "PL-10": [ "CFG-02" ], - "SA-08": [ - "CFG-02", - "SEA-01" - ], - "SA-15(05)": [ + "SA-8": [ "CFG-02", "SEA-01" ], - "CM-02(02)": [ - "CFG-02.2" - ], - "CM-06(01)": [ + "CM-6(1)": [ "CFG-02.2" ], - "CM-02(03)": [ - "CFG-02.3" - ], - "CM-02(06)": [ + "CM-2(6)": [ "CFG-02.4" ], - "CM-02(07)": [ - "CFG-02.5" - ], - "CM-07(06)": [ + "CM-7(6)": [ "CFG-02.5" ], - "CM-07(07)": [ + "CM-7(7)": [ "CFG-02.5" ], - "CM-07(09)": [ + "CM-7(9)": [ "CFG-02.5" ], - "CM-06(02)": [ + "CM-6(2)": [ "CFG-02.8" ], - "PL-11": [ - "CFG-02.9" - ], - "CM-07": [ + "CM-7": [ "CFG-03" ], - "CM-07(01)": [ + "CM-7(1)": [ "CFG-03.1" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" - ], - "CM-07(04)": [ + "CM-7(4)": [ "CFG-03.3" ], - "CM-07(05)": [ + "CM-7(5)": [ "CFG-03.3" ], - "SC-18(04)": [ - "CFG-03.3", - "END-10" - ], - "SC-07(07)": [ - "CFG-03.4" - ], "CM-10": [ "CFG-04" ], - "CM-10(01)": [ + "CM-8(10)": [ + "CFG-04.1", + "TDA-04", + "TDA-04.1", + "TDA-04.2", + "TDA-05" + ], + "CM-10(1)": [ "CFG-04.1" ], "CM-11": [ "CFG-05", "END-03" ], - "CM-11(02)": [ - "CFG-05", - "CFG-05.2", - "END-03" - ], - "CM-11(03)": [ - "CFG-05.1", - "CFG-06", - "CFG-06.1", - "END-03.1" - ], - "CM-03(08)": [ - "CFG-06", - "CFG-06.1" - ], - "AC-03(11)": [ - "CFG-08" + "CM-3(8)": [ + "CFG-06" ], "PM-31": [ "MON-01" ], - "SI-04": [ + "SI-4": [ "MON-01", "MON-02", "NET-12", "TDA-18" ], - "SI-04(01)": [ - "MON-01.1" - ], - "SI-04(25)": [ - "MON-01.1", - "NET-03.1" - ], - "SC-48": [ - "MON-01.2", - "THR-07" - ], - "SI-04(02)": [ - "MON-01.2" - ], - "SI-04(04)": [ - "MON-01.3" - ], - "SI-04(05)": [ - "MON-01.4" - ], - "SI-04(14)": [ - "MON-01.5" - ], - "SI-04(23)": [ - "MON-01.6" - ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" - ], - "AU-02": [ + "AU-2": [ "MON-01.8", "MON-02" ], - "IR-04(05)": [ - "MON-01.11", - "IRO-02.6" - ], - "SI-04(07)": [ - "MON-01.11", - "IRO-02.1" - ], - "SI-04(12)": [ - "MON-01.12", - "MON-05.1" - ], - "SI-04(13)": [ - "MON-01.13" - ], - "SI-04(19)": [ + "SI-4(19)": [ "MON-01.14" ], - "SI-04(20)": [ - "MON-01.15" - ], - "AU-14(03)": [ - "MON-01.17" - ], - "AU-06": [ + "AU-6": [ "MON-02", "MON-02.6" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" - ], - "AU-06(03)": [ - "MON-02.1" - ], - "AU-06(09)": [ - "MON-02.1" - ], - "SI-04(16)": [ + "AU-6(9)": [ "MON-02.1" ], - "AU-06(04)": [ - "MON-02.2" - ], - "AU-06(05)": [ - "MON-02.3" - ], - "SI-04(17)": [ + "SI-4(17)": [ "MON-02.3" ], - "AU-06(06)": [ - "MON-02.4" - ], - "AU-06(07)": [ - "MON-02.5" - ], - "AU-12(01)": [ - "MON-02.7" - ], - "AU-12(03)": [ - "MON-02.8" - ], - "AU-03": [ + "AU-3": [ "MON-03" ], - "AU-03(01)": [ - "MON-03.1" - ], - "AU-06(01)": [ - "MON-03.1" - ], - "AU-06(08)": [ - "MON-03.3" - ], - "AU-03(03)": [ - "MON-03.5" - ], - "AU-04": [ - "MON-04" - ], - "AU-05": [ - "MON-05" - ], - "AU-05(02)": [ - "MON-05.1" - ], - "AU-05(01)": [ - "MON-05.2" - ], - "AU-07": [ - "MON-06" - ], - "AU-07(01)": [ - "MON-06" - ], "AU-12": [ "MON-06" ], - "AU-12(04)": [ - "MON-06.1" - ], - "CA-07(03)": [ + "CA-7(3)": [ "MON-06.2" ], - "AU-08": [ - "MON-07", - "SEA-20" - ], - "SC-45": [ - "MON-07.1" - ], - "SC-45(01)": [ - "MON-07.1" - ], - "AU-09": [ - "MON-08" - ], - "AU-04(01)": [ - "MON-08.1" - ], - "AU-09(02)": [ - "MON-08.1" - ], - "AU-09(04)": [ - "MON-08.2" - ], - "AU-09(03)": [ - "MON-08.3" - ], - "AU-09(05)": [ - "MON-08.4" - ], "AU-10": [ "MON-09" ], - "AU-10(01)": [ - "MON-09.1" - ], - "AU-10(02)": [ + "AU-10(2)": [ "MON-09.1" ], - "AU-11": [ - "MON-10" - ], "AU-13": [ "MON-11" ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" - ], - "SI-04(22)": [ - "MON-11.2" - ], "AU-14": [ "MON-12" ], - "AU-05(05)": [ - "MON-13" - ], "AU-16": [ "MON-14" ], - "AU-16(01)": [ - "MON-14" - ], - "AU-16(02)": [ + "AU-16(2)": [ "MON-14.1" ], - "SC-31": [ - "MON-15" - ], - "AC-02(12)": [ - "MON-16" - ], - "IR-04(13)": [ - "MON-16", - "SEA-11", - "SEA-12" - ], - "SI-04(11)": [ - "MON-16" - ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" - ], - "SC-08(02)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" - ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" - ], - "SI-07(06)": [ - "CRY-01" - ], - "SC-08(04)": [ - "CRY-01.4" - ], - "IA-07": [ - "CRY-02", - "IAC-12" - ], - "SC-08": [ + "SC-8": [ "CRY-03", "CRY-04" ], - "SC-16(01)": [ - "CRY-04", - "CRY-10" - ], "SC-28": [ "CRY-05", "END-02" @@ -162532,148 +179460,23 @@ "CRY-07", "NET-15" ], - "SC-40": [ - "CRY-07", - "NET-12.1" - ], - "SC-12": [ - "CRY-08" - ], - "SC-17": [ - "CRY-08" - ], - "SC-28(03)": [ - "CRY-09" - ], - "SC-12(02)": [ - "CRY-09.1" - ], - "SC-12(03)": [ - "CRY-09.2" - ], - "SC-12(01)": [ - "CRY-09.3" - ], - "SA-09(06)": [ - "CRY-09.7" - ], - "SC-16": [ - "CRY-10" - ], - "SC-23(05)": [ - "CRY-11" - ], - "MP-02": [ - "DCH-03", - "END-01" - ], - "AC-03(09)": [ + "AC-3(9)": [ "DCH-03.3" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" - ], - "AC-16": [ - "DCH-05" - ], - "AC-16(01)": [ - "DCH-05.1" - ], - "AC-16(02)": [ - "DCH-05.2" - ], - "AC-16(03)": [ - "DCH-05.3" - ], - "AC-16(04)": [ - "DCH-05.4" - ], - "AC-16(05)": [ - "DCH-05.5" - ], - "AC-16(06)": [ - "DCH-05.6" - ], - "AC-16(07)": [ - "DCH-05.7" - ], - "AC-16(08)": [ - "DCH-05.8" - ], - "AC-16(09)": [ - "DCH-05.9" - ], - "AC-16(10)": [ - "DCH-05.10" - ], - "MP-04": [ - "DCH-06" - ], - "MP-05": [ - "DCH-07" - ], - "MP-05(03)": [ - "DCH-07.1" - ], - "MP-06": [ + "MP-6": [ "DCH-08", "DCH-09", "DCH-09.3" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" - ], - "MP-06(01)": [ - "DCH-09.1" - ], - "MP-06(02)": [ - "DCH-09.2" - ], - "MP-06(07)": [ - "DCH-09.5" - ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" - ], - "MP-08": [ - "DCH-11" - ], - "MP-08(03)": [ - "DCH-11" - ], "AC-20": [ "DCH-13" ], - "AC-20(01)": [ + "AC-20(1)": [ "DCH-13.1" ], - "AC-20(02)": [ - "DCH-13.2" - ], - "AC-20(05)": [ - "DCH-13.2" - ], - "PM-17": [ - "DCH-13.3" - ], - "AC-20(03)": [ + "AC-20(3)": [ "DCH-13.4" ], - "AC-21": [ - "DCH-14", - "PRI-07" - ], - "AC-21(02)": [ - "DCH-14.1" - ], - "CA-03(06)": [ - "DCH-14.2" - ], "AC-22": [ "DCH-15" ], @@ -162685,102 +179488,13 @@ "DCH-18", "PRI-05" ], - "SI-12(01)": [ - "DCH-18.1", - "PRI-05.1" - ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" - ], - "SA-08(33)": [ - "DCH-18.2", - "END-13.3", - "PES-06.5" - ], - "SA-15(12)": [ - "DCH-18.2" - ], - "SI-12(02)": [ - "DCH-18.2", - "PRI-05.1" - ], - "SI-12(03)": [ - "DCH-21", - "PRI-05" - ], - "PM-22": [ - "DCH-22", - "PRI-10" - ], - "SI-18": [ - "DCH-22" - ], - "SI-18(01)": [ - "DCH-22" - ], - "SI-18(04)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" - ], - "SI-18(05)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" - ], - "PT-02(01)": [ - "DCH-22.2" - ], - "PT-03(01)": [ - "DCH-22.2", - "PRI-11" - ], - "SI-18(02)": [ - "DCH-22.2" - ], - "SI-18(03)": [ - "DCH-22.3" - ], - "SI-19(01)": [ - "DCH-22.3", - "DCH-23.1" - ], - "SI-19": [ - "DCH-23" - ], - "SI-19(02)": [ - "DCH-23.2" - ], - "SI-19(03)": [ - "DCH-23.3" - ], - "SI-19(04)": [ - "DCH-23.4", - "PRI-05.3" - ], - "SI-19(05)": [ - "DCH-23.5" - ], - "SI-19(06)": [ - "DCH-23.6" - ], - "SI-19(07)": [ - "DCH-23.7" - ], - "SI-19(08)": [ - "DCH-23.8" - ], "CM-12": [ "DCH-24" ], - "CM-12(01)": [ + "CM-12(1)": [ "DCH-24.1" ], - "SI-03": [ + "SI-3": [ "END-04", "END-04.1", "END-04.4", @@ -162789,34299 +179503,35996 @@ "VPM-01", "VPM-05" ], - "SI-02": [ + "SI-2": [ "END-04.1", "VPM-01", "VPM-05" ], - "SI-03(06)": [ - "END-04.5" - ], - "SI-07": [ + "SI-7": [ "END-06", "NET-12", "TDA-18" ], - "SI-07(01)": [ - "END-06.1" - ], - "SI-07(07)": [ - "END-06.2" - ], - "SI-07(02)": [ - "END-06.3" - ], - "SI-07(05)": [ - "END-06.4" - ], - "SI-07(09)": [ - "END-06.5" - ], - "SI-07(10)": [ - "END-06.6" - ], - "CM-07(08)": [ + "CM-7(8)": [ "END-06.7" ], - "SI-08": [ - "END-08" - ], - "SI-08(02)": [ - "END-08.2" - ], - "SC-11": [ - "END-09" + "SI-7(14)": [ + "END-06.7" ], "SC-18": [ "END-10" ], - "SC-18(01)": [ - "END-10", - "VPM-02", - "VPM-04" - ], - "SC-18(03)": [ - "END-10", - "NET-18" - ], "SC-27": [ "END-10" ], - "SC-25": [ - "END-11" - ], - "SC-41": [ - "END-12" - ], - "SC-42": [ - "END-13" - ], - "SC-42(02)": [ - "END-13.1" - ], - "SC-42(04)": [ - "END-13.2" - ], - "SC-42(05)": [ - "END-13.3" - ], - "SC-42(01)": [ - "END-13.4" - ], - "SC-15": [ - "END-14" - ], - "SC-15(01)": [ - "END-14" - ], - "SC-15(03)": [ - "END-14.1" - ], - "SC-15(04)": [ - "END-14.2" - ], - "SC-03": [ - "END-16", - "SEA-04.1" - ], - "SC-07(12)": [ - "END-16.1" - ], - "PS-02": [ - "HRS-02", - "HRS-03.2" - ], - "SI-04(21)": [ - "HRS-02.2" - ], - "PM-13": [ - "HRS-03", - "SAT-01" - ], - "PS-09": [ - "HRS-03" - ], - "PS-03": [ + "PS-3": [ "HRS-04" ], - "PS-03(01)": [ - "HRS-04.1" - ], - "PS-03(03)": [ - "HRS-04.1" - ], - "PS-03(02)": [ - "HRS-04.2" - ], - "PS-03(04)": [ - "HRS-04.3" - ], - "PL-04": [ + "PL-4": [ "HRS-05", "HRS-05.1", "HRS-05.3" ], - "PL-04(01)": [ - "HRS-05.2" - ], - "PS-06": [ - "HRS-06", - "HRS-06.1" - ], - "PS-06(02)": [ + "PS-6": [ "HRS-06", "HRS-06.1" ], - "PS-06(03)": [ - "HRS-06.2" - ], - "PS-08": [ - "HRS-07" - ], - "PS-05": [ - "HRS-08" - ], - "PS-04": [ - "HRS-09" - ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" - ], - "PS-04(01)": [ - "HRS-09.3" - ], - "PS-04(02)": [ - "HRS-09.4" - ], - "PS-07": [ - "HRS-10" - ], - "AC-03(02)": [ - "HRS-12.1", - "IAC-20.5" - ], - "IA-04": [ + "IA-4": [ "IAC-01.2", "IAC-09" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" - ], - "IA-02": [ + "IA-2": [ "IAC-02" ], - "IA-02(05)": [ - "IAC-02.1" - ], - "IA-02(08)": [ - "IAC-02.2" - ], - "IA-02(12)": [ - "IAC-02.3" - ], - "IA-08(05)": [ - "IAC-02.3" - ], - "IA-02(13)": [ - "IAC-02.4" - ], - "IA-08": [ + "IA-8": [ "IAC-03" ], - "IA-08(01)": [ - "IAC-03.1" - ], - "IA-08(02)": [ - "IAC-03.2" - ], - "IA-08(04)": [ - "IAC-03.3" - ], - "IA-08(06)": [ - "IAC-03.4" - ], - "IA-03": [ - "IAC-04" - ], - "IA-03(01)": [ + "IA-3": [ "IAC-04" ], - "IA-03(04)": [ - "IAC-04", - "IAC-04.1" - ], - "IA-09": [ + "IA-9": [ "IAC-05" ], - "AC-06(06)": [ + "AC-6(6)": [ "IAC-05.2" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" - ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" - ], - "IA-02(06)": [ - "IAC-06.4" - ], - "IA-12(04)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" - ], - "AC-02": [ + "AC-2": [ "IAC-07.2", "IAC-15", "NET-12", "TDA-18" ], - "AC-02(07)": [ - "IAC-08" - ], - "IA-04(05)": [ - "IAC-09.3" - ], - "IA-05(10)": [ - "IAC-09.3" - ], - "IA-04(06)": [ + "IA-4(6)": [ "IAC-09.4" ], - "IA-05(08)": [ - "IAC-09.5", - "IAC-10.9" - ], - "IA-04(08)": [ - "IAC-09.6" - ], - "IA-05": [ + "IA-5": [ "IAC-10", "IAC-10.8" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" - ], - "IA-05(02)": [ - "IAC-10.2" - ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" - ], - "IA-05(07)": [ - "IAC-10.6" - ], - "IA-05(05)": [ + "IA-5(5)": [ "IAC-10.8" ], - "IA-05(13)": [ - "IAC-10.10" - ], - "IA-05(18)": [ - "IAC-10.11" - ], - "IA-05(12)": [ - "IAC-10.12" - ], - "IA-06": [ - "IAC-11" - ], - "IA-10": [ - "IAC-13" - ], - "IA-02(10)": [ - "IAC-13.1" - ], - "IA-05(09)": [ + "IA-5(9)": [ "IAC-13.2" ], - "IA-11": [ - "IAC-14" - ], - "AC-02(01)": [ - "IAC-15.1" - ], - "AC-02(02)": [ - "IAC-15.2" - ], - "AC-02(03)": [ - "IAC-15.3" - ], - "AC-02(04)": [ - "IAC-15.4" - ], - "AC-02(09)": [ - "IAC-15.5" - ], - "AC-02(11)": [ - "IAC-15.8" - ], - "AC-06(07)": [ - "IAC-17" - ], - "AC-03": [ + "AC-3": [ "IAC-20", "NET-12", "TDA-18" ], - "AC-06": [ - "IAC-20", - "IAC-21" - ], - "AC-03(08)": [ + "AC-3(8)": [ "IAC-20.6" ], - "SA-08(14)": [ - "IAC-21" + "AC-24": [ + "IAC-28.1" ], - "AC-06(01)": [ - "IAC-21.1" + "IR-4(6)": [ + "IRO-02.2" ], - "AC-06(02)": [ - "IAC-21.2" + "IR-4(7)": [ + "IRO-02.2" ], - "AC-06(05)": [ - "IAC-21.3" + "IR-8": [ + "IRO-04" ], - "AC-06(09)": [ - "IAC-21.4" + "IR-2": [ + "IRO-05" ], - "AC-06(10)": [ - "IAC-21.5" + "IR-3": [ + "IRO-06" ], - "AC-06(03)": [ - "IAC-21.6" + "IR-4(11)": [ + "IRO-07" ], - "AC-06(08)": [ - "IAC-21.7" + "AU-10(3)": [ + "IRO-08" + ], + "IR-5": [ + "IRO-09" ], - "AC-07": [ - "IAC-22" + "IR-6(3)": [ + "IRO-10.4" ], - "AC-10": [ - "IAC-23" + "IR-7(2)": [ + "IRO-11.2" ], - "AC-02(05)": [ - "IAC-24" + "IR-9": [ + "IRO-12", + "IRO-12.1" ], - "AC-11": [ - "IAC-24" + "CA-2(2)": [ + "IAO-02.2" ], - "AC-11(01)": [ - "IAC-24.1" + "CA-2(3)": [ + "IAO-02.3" ], - "AC-12": [ - "IAC-25" + "CA-5": [ + "IAO-05" ], - "AC-12(01)": [ - "IAC-25.1" + "PM-4": [ + "IAO-05", + "VPM-02" ], - "AC-14": [ - "IAC-26" + "CA-6": [ + "IAO-07" ], - "AC-25": [ - "IAC-27" + "MA-2(2)": [ + "MNT-02.1" ], - "IA-12": [ - "IAC-28" + "MA-6": [ + "MNT-03" ], - "AC-24": [ - "IAC-28.1" + "MA-3": [ + "MNT-04" ], - "IA-12(01)": [ - "IAC-28.1" + "MA-3(1)": [ + "MNT-04.1" ], - "IA-12(02)": [ - "IAC-28.2" + "MA-3(2)": [ + "MNT-04.2" ], - "IA-12(03)": [ - "IAC-28.3" + "MA-3(3)": [ + "MNT-04.3" ], - "IA-12(05)": [ - "IAC-28.5" + "MA-4": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "IR-04": [ - "IRO-02" + "MA-4(3)": [ + "MNT-05.6" ], - "IR-04(01)": [ - "IRO-02.1" + "MA-5": [ + "MNT-06" ], - "IR-04(06)": [ - "IRO-02.2" + "MA-5(4)": [ + "MNT-06.1" ], - "IR-04(07)": [ - "IRO-02.2" + "SR-11(2)": [ + "MNT-07" ], - "IR-04(02)": [ - "IRO-02.3" + "MA-7": [ + "MNT-08" ], - "IR-04(08)": [ - "IRO-02.5" + "MA-8": [ + "MNT-11", + "SEA-07" ], - "IR-08": [ - "IRO-04" + "AC-19": [ + "MDM-02" ], - "IR-08(01)": [ - "IRO-04.1" + "PE-3(5)": [ + "MDM-04" ], - "IR-03(03)": [ - "IRO-04.3" + "AC-4": [ + "NET-04" ], - "IR-02": [ - "IRO-05" + "AC-4(6)": [ + "NET-04.5" ], - "IR-02(03)": [ - "IRO-05" + "AC-4(17)": [ + "NET-04.12" ], - "IR-02(01)": [ - "IRO-05.1" + "AC-4(19)": [ + "NET-04.13" ], - "IR-02(02)": [ - "IRO-05.2" + "CA-3": [ + "NET-05" ], - "IR-03": [ - "IRO-06" + "AC-4(21)": [ + "NET-06" ], - "SI-04(09)": [ - "IRO-06" + "SC-7(13)": [ + "NET-06.1" ], - "IR-03(02)": [ - "IRO-06.1" + "SC-37(1)": [ + "NET-11" ], - "IR-04(11)": [ - "IRO-07" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "AU-10(03)": [ - "IRO-08" + "AC-17": [ + "NET-14" ], - "IR-04(12)": [ - "IRO-08", - "IRO-13" + "AC-17(6)": [ + "NET-14" ], - "IR-05": [ - "IRO-09" + "PE-2": [ + "PES-02" ], - "IR-05(01)": [ - "IRO-09.1" + "PE-2(1)": [ + "PES-02.1" ], - "IR-06(01)": [ - "IRO-10.1" + "PE-3": [ + "PES-03" ], - "IR-06(02)": [ - "IRO-10.3", - "IRO-13" + "PE-3(2)": [ + "PES-03" ], - "IR-04(10)": [ - "IRO-10.4", - "TPM-11" + "SC-7(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" ], - "IR-06(03)": [ - "IRO-10.4" + "PE-3(1)": [ + "PES-03.4" ], - "IR-07": [ - "IRO-11" + "PE-6": [ + "PES-05" ], - "IR-07(01)": [ - "IRO-11.1" + "PE-16": [ + "PES-10" ], - "IR-07(02)": [ - "IRO-11.2" + "PE-17": [ + "PES-11" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "PE-18": [ + "PES-12" ], - "IR-09(02)": [ - "IRO-12.2" + "PE-20": [ + "PES-14" ], - "IR-09(03)": [ - "IRO-12.3" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "IR-09(04)": [ - "IRO-12.4" + "PM-27": [ + "PRI-14" ], - "SC-44": [ - "IRO-15" + "RA-9": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "IR-04(15)": [ - "IRO-16" + "PM-11": [ + "PRM-06" ], - "PM-10": [ - "IAO-01" + "SA-3": [ + "PRM-07", + "SEA-07.1" ], - "CA-02(01)": [ - "IAO-02.1" + "RA-2": [ + "RSK-02" ], - "CA-02(02)": [ - "IAO-02.2" + "RA-7": [ + "RSK-06.1" ], - "SA-11(05)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "SA-9(3)": [ + "RSK-09", + "TPM-02", + "TPM-03", + "TPM-05", + "TPM-05.4", + "TPM-05.7" ], - "CA-02(03)": [ - "IAO-02.3" + "SR-2": [ + "RSK-09", + "TPM-03" ], - "CA-05": [ - "IAO-05" + "SR-7": [ + "RSK-09", + "OPS-01" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "RA-3(1)": [ + "RSK-09.1" ], - "SA-15(02)": [ - "IAO-05" + "PL-8": [ + "SEA-02" ], - "CA-05(01)": [ - "IAO-05.1" + "SC-4": [ + "SEA-05" ], - "CM-04(02)": [ - "IAO-06" + "SC-29": [ + "SEA-13" ], - "CA-06": [ - "IAO-07" + "SC-30": [ + "SEA-14" ], - "MA-02": [ - "MNT-02" + "SC-30(4)": [ + "SEA-14" ], - "MA-02(02)": [ - "MNT-02.1" + "SC-30(5)": [ + "SEA-14" ], - "MA-06": [ - "MNT-03" + "SC-30(2)": [ + "SEA-14.1" ], - "MA-06(01)": [ - "MNT-03.1" + "SC-30(3)": [ + "SEA-14.2" ], - "MA-06(02)": [ - "MNT-03.2" + "SC-36": [ + "SEA-15" ], - "MA-06(03)": [ - "MNT-03.3" + "SC-38": [ + "OPS-01", + "OPS-04" ], - "MA-03": [ - "MNT-04" + "PL-7": [ + "OPS-02" ], - "MA-03(05)": [ - "MNT-04" + "SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "MA-03(06)": [ - "MNT-04" + "SA-4(7)": [ + "TDA-02.2" ], - "MA-03(01)": [ - "MNT-04.1" + "SR-3(1)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" ], - "MA-03(02)": [ - "MNT-04.2" + "SA-4(5)": [ + "TDA-02.4" ], - "MA-03(03)": [ - "MNT-04.3" + "PL-8(2)": [ + "TDA-03.1" ], - "MA-03(04)": [ - "MNT-04.4" + "SA-17": [ + "TDA-05" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "SA-15": [ + "TDA-06" ], - "MA-04(01)": [ - "MNT-05.1" + "SA-15(3)": [ + "TDA-06.1" ], - "MA-04(06)": [ - "MNT-05.3" + "SA-15(4)": [ + "TDA-06.2" ], - "MA-04(07)": [ - "MNT-05.4" + "SA-15(8)": [ + "TDA-06.2" ], - "MA-04(05)": [ - "MNT-05.5" + "CM-4(1)": [ + "TDA-08" ], - "MA-04(03)": [ - "MNT-05.6" + "SA-11": [ + "TDA-09" ], - "MA-04(04)": [ - "MNT-05.7" + "SA-4(8)": [ + "TDA-09.1" ], - "MA-05": [ - "MNT-06" + "SR-11": [ + "TDA-11" ], - "MA-05(01)": [ - "MNT-06.1" + "SR-11(3)": [ + "TDA-11" ], - "MA-05(02)": [ - "MNT-06.1" + "SR-11(1)": [ + "TDA-11.1" ], - "MA-05(03)": [ - "MNT-06.1" + "SA-20": [ + "TDA-12" ], - "MA-05(04)": [ - "MNT-06.1" + "SA-21": [ + "TDA-13" ], - "MA-05(05)": [ - "MNT-06.2" + "SA-21(1)": [ + "TDA-13" ], - "SR-11(02)": [ - "MNT-07" + "SA-10": [ + "TDA-14" ], - "MA-07": [ - "MNT-08" + "SA-16": [ + "TDA-16" ], - "AC-19": [ - "MDM-02" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "AC-19(05)": [ - "MDM-03" + "SR-13": [ + "TPM-01.1" ], - "PE-03(05)": [ - "MDM-04" + "SR-5": [ + "TPM-03.1" ], - "AC-07(02)": [ - "MDM-05" + "SR-3": [ + "TPM-03.3" ], - "MP-06(08)": [ - "MDM-05" + "SA-9(1)": [ + "TPM-04.1" ], - "SC-46": [ - "NET-02.3" + "SA-9(4)": [ + "TPM-04.3" ], - "SC-07": [ - "NET-03" + "SR-3(3)": [ + "TPM-05", + "TPM-05.2" ], - "SC-07(09)": [ - "NET-03", - "NET-03.2" + "SR-8": [ + "TPM-05.1" ], - "SC-07(11)": [ - "NET-03", - "NET-04.1" + "SR-6": [ + "TPM-08" ], - "SC-07(03)": [ - "NET-03.1" + "PM-12": [ + "THR-04" ], - "SC-07(04)": [ - "NET-03.2" + "RA-10": [ + "THR-07" ], - "SC-07(16)": [ - "NET-03.3" + "SI-20": [ + "THR-08" ], - "SC-07(24)": [ - "NET-03.4" + "RA-5": [ + "VPM-06", + "VPM-06.1" ], - "SC-07(10)": [ - "NET-03.5", - "NET-17" + "RA-5(3)": [ + "VPM-06.2" ], - "SC-07(20)": [ - "NET-03.6" + "RA-5(6)": [ + "VPM-06.4" + ] + }, + "general-nist-800-171-r2": { + "3.4.1": [ + "AST-01", + "AST-02", + "CFG-02" ], - "SC-07(21)": [ - "NET-03.7" + "3.8.3": [ + "AST-01", + "AST-09", + "DCH-01", + "DCH-08", + "DCH-09" ], - "SC-07(22)": [ - "NET-03.8" + "NFO - CM-8(5)": [ + "AST-02.3" ], - "AC-04": [ - "NET-04" + "NFO - MP-1": [ + "AST-05", + "DCH-01" ], - "SC-07(05)": [ - "NET-04.1" + "3.8.9": [ + "BCD-11", + "BCD-11.4" ], - "AC-04(01)": [ - "NET-04.2" + "3.4.3": [ + "CHG-01", + "CHG-02" ], - "AC-04(04)": [ - "NET-04.3" + "NFO - CM-3(2)": [ + "CHG-02.2" ], - "AC-04(05)": [ - "NET-04.4" + "3.4.4": [ + "CHG-03" ], - "AC-04(06)": [ - "NET-04.5" + "3.4.5": [ + "CHG-04", + "TDA-08" ], - "AC-04(09)": [ - "NET-04.6" + "NFO - CM-9": [ + "CHG-05", + "CFG-01" ], - "AC-04(08)": [ - "NET-04.7" + "3.1.22": [ + "CLD-01", + "CLD-02", + "CLD-06", + "CLD-10", + "DCH-15", + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "WEB-01", + "WEB-02", + "WEB-04" ], - "AC-04(12)": [ - "NET-04.8" + "NFO–PL-8": [ + "CLD-01", + "CLD-02", + "CLD-03" ], - "AC-04(13)": [ - "NET-04.9" + "3.13.2": [ + "CLD-03", + "SEA-01", + "SEA-03" ], - "AC-04(15)": [ - "NET-04.10" + "NFO - PL-1": [ + "CPL-01", + "PRM-01" ], - "AC-04(20)": [ - "NET-04.11" + "3.12.1": [ + "CPL-02", + "CPL-02.1", + "CPL-03", + "IAO-02" ], - "AC-04(17)": [ - "NET-04.12" + "3.12.3": [ + "CPL-02", + "THR-01", + "THR-03" ], - "AC-04(19)": [ - "NET-04.13" + "NFO - CA-7(1)": [ + "CPL-03.1" ], - "CA-03": [ - "NET-05" + "NFO - CM-1": [ + "CFG-01" ], - "SC-07(25)": [ - "NET-05" + "3.3.3": [ + "CFG-02", + "CFG-02.1", + "CFG-02.9", + "MON-01", + "MON-01.8", + "MON-01.16", + "MON-02" ], - "SC-07(26)": [ - "NET-05" + "3.4.2": [ + "CFG-02" ], - "SC-07(27)": [ - "NET-05.1" + "NFO - CM-2(1)": [ + "CFG-02.1" ], - "CA-09": [ - "NET-05.2" + "NFO - CM-2(7)": [ + "CFG-02.5" ], - "AC-04(21)": [ - "NET-06" + "3.4.6": [ + "CFG-03" ], - "SC-07(13)": [ - "NET-06.1" + "3.4.7": [ + "CFG-03.1", + "CFG-03.2" ], - "SC-07(28)": [ - "NET-06.5" + "3.4.8": [ + "CFG-03.3" ], - "SC-10": [ - "NET-07" + "3.13.7": [ + "CFG-03.4" ], - "SI-04(15)": [ - "NET-08.2" + "3.4.9": [ + "CFG-05", + "END-03" ], - "SC-23": [ - "NET-09" + "3.14.6": [ + "MON-01", + "MON-01.3", + "NET-08" ], - "SC-23(01)": [ - "NET-09.1" + "NFO - AU-1": [ + "MON-01" ], - "SC-23(03)": [ - "NET-09.2" + "NFO - SI-4(5)": [ + "MON-01.4" ], - "SC-20": [ - "NET-10" + "3.14.3": [ + "MON-01.8", + "THR-01", + "THR-03" ], - "SC-20(02)": [ - "NET-10" + "3.3.1": [ + "MON-02", + "MON-10" ], - "SC-22": [ - "NET-10.1" + "3.3.5": [ + "MON-02", + "MON-02.1" ], - "SC-21": [ - "NET-10.2" + "3.3.6": [ + "MON-02", + "MON-06" ], - "SC-37": [ - "NET-11" + "3.3.8": [ + "MON-02", + "MON-03.1", + "MON-08" ], - "SC-37(01)": [ - "NET-11" + "3.3.9": [ + "MON-02", + "MON-08.2" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "3.14.7": [ + "MON-02.1", + "MON-11.3", + "MON-16", + "IRO-03" ], - "SI-10": [ - "NET-12", - "TDA-18" + "3.3.2": [ + "MON-03" ], - "SC-08(03)": [ - "NET-13" + "3.3.4": [ + "MON-05" ], - "AC-17": [ - "NET-14" + "3.3.7": [ + "MON-07.1", + "SEA-20" ], - "AC-17(06)": [ - "NET-14" + "3.13.11": [ + "CRY-01" ], - "AC-17(01)": [ - "NET-14.1" + "3.8.6": [ + "CRY-01.1", + "CRY-05" ], - "AC-17(02)": [ - "NET-14.2" + "3.13.8": [ + "CRY-01.1", + "CRY-03" ], - "AC-17(03)": [ - "NET-14.3" + "NFO - SI-1": [ + "CRY-04" ], - "AC-17(04)": [ - "NET-14.4" + "3.13.16": [ + "CRY-05", + "END-02" ], - "CA-09(01)": [ - "NET-14.7" + "3.13.10": [ + "CRY-08", + "CRY-09" ], - "AC-17(09)": [ - "NET-14.8" + "3.8.1": [ + "DCH-01", + "DCH-06" ], - "AC-18(01)": [ - "NET-15.1" + "3.10.6": [ + "DCH-01.2", + "NET-14.5", + "PES-11" ], - "AC-18(03)": [ - "NET-15.2" + "3.1.3": [ + "DCH-03", + "IAC-08", + "NET-04", + "NET-18" ], - "AC-18(04)": [ - "NET-15.3" + "3.8.2": [ + "DCH-03" ], - "AC-18(05)": [ - "NET-15.4" + "3.8.4": [ + "DCH-04" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "3.8.5": [ + "DCH-07" ], - "SI-04(10)": [ - "NET-18.2" + "3.7.3": [ + "DCH-09" ], - "SC-07(15)": [ - "NET-18.3" + "3.8.7": [ + "DCH-10" ], - "PE-02": [ - "PES-02" + "3.8.8": [ + "DCH-10.2" ], - "PE-02(01)": [ - "PES-02.1" + "3.1.20": [ + "DCH-13", + "DCH-13.1", + "DCH-17" ], - "PE-03": [ - "PES-03" + "3.1.21": [ + "DCH-13.2" ], - "PE-03(02)": [ - "PES-03" + "3.14.2": [ + "END-01", + "END-04" ], - "PE-03(03)": [ - "PES-03" + "3.14.4": [ + "END-04.1" ], - "PE-03(04)": [ - "PES-03.2" + "3.14.5": [ + "END-04.7" ], - "SC-07(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "3.13.13": [ + "END-10" ], - "PE-08": [ - "PES-03.3" + "3.13.12": [ + "END-14" ], - "PE-03(01)": [ - "PES-03.4" + "NFO - PS-1": [ + "HRS-01" ], - "PE-06": [ - "PES-05" + "3.9.2": [ + "HRS-01.1", + "HRS-08", + "HRS-09" ], - "PE-06(01)": [ - "PES-05.1" + "3.9.1": [ + "HRS-04", + "HRS-04.1" ], - "PE-06(04)": [ - "PES-05.2" + "3.2.1": [ + "HRS-04.2", + "SAT-02" ], - "PE-02(02)": [ - "PES-06.2" + "3.2.2": [ + "HRS-04.2", + "SAT-03" ], - "PE-02(03)": [ - "PES-06.3" + "NFO - PL-4": [ + "HRS-05", + "HRS-05.1" ], - "PE-08(01)": [ - "PES-06.4" + "NFO - PL-4(1)": [ + "HRS-05.2" ], - "PE-08(03)": [ - "PES-06.5" + "NFO - PS-6": [ + "HRS-06" ], - "PE-09": [ - "PES-07" + "NFO - PS-8": [ + "HRS-07" ], - "PE-09(02)": [ - "PES-07.1" + "NFO - PS-7": [ + "HRS-10" ], - "PE-10": [ - "PES-07.2" + "3.1.4": [ + "HRS-11" ], - "PE-11": [ - "PES-07.3" + "3.1.1": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-15.1", + "IAC-20", + "TPM-01", + "TPM-05", + "TPM-05.2" ], - "PE-11(01)": [ - "PES-07.3" + "NFO - AC-1": [ + "IAC-01" ], - "PE-11(02)": [ - "PES-07.3" + "NFO - IA-1": [ + "IAC-01" ], - "PE-12": [ - "PES-07.4" + "3.5.1": [ + "IAC-02", + "IAC-04", + "IAC-15.1" ], - "PE-15": [ - "PES-07.5" + "3.5.2": [ + "IAC-02", + "IAC-04", + "IAC-15.1" ], - "PE-15(01)": [ - "PES-07.6" + "3.5.4": [ + "IAC-02.2" ], - "PE-09(01)": [ - "PES-07.7" + "3.5.3": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3" ], - "PE-13": [ - "PES-08" + "3.7.5": [ + "IAC-06", + "MNT-05", + "MNT-05.4" ], - "PE-13(01)": [ - "PES-08.1" + "3.1.2": [ + "IAC-08", + "IAC-15" ], - "PE-13(02)": [ - "PES-08.2", - "PES-08.3" + "3.5.5": [ + "IAC-09" ], - "PE-14": [ - "PES-09" + "3.5.8": [ + "IAC-10" ], - "PE-14(02)": [ - "PES-09.1" + "3.5.9": [ + "IAC-10" ], - "PE-16": [ - "PES-10" + "3.5.7": [ + "IAC-10.1" ], - "PE-17": [ - "PES-11" + "3.5.10": [ + "IAC-10.5" ], - "PE-18": [ - "PES-12" + "3.5.11": [ + "IAC-11" ], - "PE-04": [ - "PES-12.1" + "3.5.6": [ + "IAC-15.3" ], - "PE-05": [ - "PES-12.2" + "3.1.5": [ + "IAC-16", + "IAC-16.1", + "IAC-21", + "IAC-21.1", + "IAC-21.3" ], - "PE-19": [ - "PES-13" + "3.1.6": [ + "IAC-21.2" ], - "PE-20": [ - "PES-14" + "3.1.7": [ + "IAC-21.4", + "IAC-21.5" ], - "PE-21": [ - "PES-15" + "3.1.8": [ + "IAC-22" ], - "PM-18": [ - "PRI-01" + "3.1.10": [ + "IAC-24", + "IAC-24.1" ], - "PM-19": [ - "PRI-01.1" + "3.1.11": [ + "IAC-25" ], - "PT-05(02)": [ - "PRI-01.2" + "NFO - IR-1": [ + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "PM-20": [ - "PRI-01.3" + "3.6.1": [ + "IRO-02", + "IRO-05" ], - "PM-20(01)": [ - "PRI-02" + "3.6.2": [ + "IRO-02" ], - "PT-05": [ - "PRI-02" + "NFO - IR-8": [ + "IRO-04" ], - "PT-03": [ - "PRI-02.1", - "PRI-05.1" + "3.6.3": [ + "IRO-06" ], - "PT-02(02)": [ - "PRI-02.2" + "NFO - CA-1": [ + "IAO-01" ], - "PT-03(02)": [ - "PRI-02.2", - "PRI-10.1" + "NFO - CA-2(1)": [ + "IAO-02.1" ], - "PT-08": [ - "PRI-02.3" + "3.12.4": [ + "IAO-03", + "IAO-03.2" ], - "PT-06": [ - "PRI-02.4" + "NFO - PL-2(3)": [ + "IAO-03.1" ], - "PT-06(01)": [ - "PRI-02.5" + "3.12.2": [ + "IAO-05" ], - "PT-06(02)": [ - "PRI-02.6" + "NFO - MA-1": [ + "MNT-01" ], - "PT-04": [ - "PRI-03" + "3.7.1": [ + "MNT-02" ], - "PT-04(01)": [ - "PRI-03.1" + "3.7.2": [ + "MNT-04" ], - "PT-04(02)": [ - "PRI-03.2" + "3.7.4": [ + "MNT-04.2" ], - "PT-05(01)": [ - "PRI-03.2" + "NFO - MA-4(2)": [ + "MNT-05.2" ], - "PT-04(03)": [ - "PRI-03.4" + "3.7.6": [ + "MNT-06", + "MNT-06.1", + "MNT-06.2" ], - "PT-02": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "3.1.18": [ + "MDM-01", + "MDM-02", + "MDM-06", + "MDM-07" + ], + "3.1.19": [ + "MDM-03" ], - "AC-04(25)": [ - "PRI-05" + "3.13.1": [ + "NET-01", + "NET-02.2", + "NET-03" ], - "PT-07": [ - "PRI-05.4", - "PRI-05.7" + "NFO - SC-1": [ + "NET-01" ], - "PM-05(01)": [ - "PRI-05.5", - "PRI-05.6" + "NFO - SC-7(3)": [ + "NET-03.1" ], - "PT-07(01)": [ - "PRI-05.7" + "NFO - SC-7(4)": [ + "NET-03.2" ], - "PT-07(02)": [ - "PRI-05.7" + "3.13.6": [ + "NET-04.1" ], - "AC-03(14)": [ - "PRI-06" + "NFO - CA-3(5)": [ + "NET-04.1" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "NFO - CA-3": [ + "NET-05" ], - "PM-27": [ - "PRI-14" + "NFO - CA-9": [ + "NET-05.2" ], - "PM-21": [ - "PRI-14.1" + "3.13.5": [ + "NET-06" ], - "PM-03": [ - "PRM-02" + "3.13.9": [ + "NET-07" ], - "SA-02": [ - "PRM-03" + "3.13.15": [ + "NET-09" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "NFO - SC-20": [ + "NET-10" ], - "PM-11": [ - "PRM-06" + "NFO - SC-22": [ + "NET-10.1" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "NFO - SC-21": [ + "NET-10.2" ], - "SA-03(01)": [ - "PRM-07", - "SEA-07.1", - "TDA-07" + "3.13.14": [ + "NET-13" ], - "SA-08(30)": [ - "PRM-07", - "SEA-07.1" + "3.1.12": [ + "NET-14", + "NET-14.1", + "NET-14.5" ], - "PM-09": [ - "RSK-01" + "3.1.13": [ + "NET-14.2" ], - "PM-28": [ - "RSK-01.1" + "3.1.14": [ + "NET-14.3" ], - "RA-02": [ - "RSK-02" + "3.1.15": [ + "NET-14.4" ], - "RA-02(01)": [ - "RSK-02.1" + "3.1.16": [ + "NET-15" ], - "RA-07": [ - "RSK-06.1" + "3.1.17": [ + "NET-15.1" ], - "PM-30": [ - "RSK-09" + "3.10.2": [ + "PES-01", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "SA-09(03)": [ - "RSK-09", - "TPM-02", - "TPM-03", - "TPM-04.3", - "TPM-05.4", - "TPM-05.7" + "NFO - PE-1": [ + "PES-01" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "3.10.1": [ + "PES-02", + "PES-02.1", + "PES-03.4", + "PES-12", + "PES-12.1", + "PES-12.2" ], - "SR-07": [ - "RSK-09", - "OPS-01" + "3.10.3": [ + "PES-03", + "PES-06", + "PES-06.1", + "PES-06.3" ], - "RA-03(01)": [ - "RSK-09.1" + "3.10.5": [ + "PES-03", + "PES-04" ], - "RA-08": [ - "RSK-10" + "3.10.4": [ + "PES-03.3" ], - "CA-07(04)": [ - "RSK-11" + "NFO - PE-8": [ + "PES-03.3" ], - "SC-07(18)": [ - "SEA-01" + "NFO - PE-6(1)": [ + "PES-05.1" ], - "PL-08": [ - "SEA-02" + "NFO - PE-16": [ + "PES-10" ], - "PM-07": [ - "SEA-02" + "NFO - SA-2": [ + "PRM-03" ], - "PM-07(01)": [ - "SEA-02.2" + "NFO - SA-3": [ + "PRM-07", + "SEA-07", + "SEA-07.1" ], - "PL-08(01)": [ - "SEA-03" + "NFO - RA-1": [ + "RSK-01" ], - "SC-03(05)": [ - "SEA-03" + "3.11.1": [ + "RSK-04" ], - "SC-32": [ - "SEA-03.1" + "3.11.3": [ + "RSK-06", + "VPM-04", + "VPM-05" ], - "SC-02": [ - "SEA-03.2" + "NFO - PL-8": [ + "SEA-02" ], - "SC-02(01)": [ + "3.13.3": [ "SEA-03.2" ], - "SC-39": [ + "NFO - SC-39": [ "SEA-04" ], - "SC-39(01)": [ - "SEA-04.2" - ], - "SC-39(02)": [ - "SEA-04.3" - ], - "SC-04": [ + "3.13.4": [ "SEA-05" ], - "SA-03(03)": [ - "SEA-07.1", - "SEA-08.1" + "NFO - SI-16": [ + "SEA-10" ], - "CP-12": [ - "SEA-07.2" + "3.1.9": [ + "SEA-18", + "SEA-18.1", + "SEA-18.2" ], - "SA-08(24)": [ - "SEA-07.2" + "NFO - AT-1": [ + "SAT-01" ], - "SC-24": [ - "SEA-07.2" + "3.2.3": [ + "SAT-03.6", + "THR-05" ], - "SI-17": [ - "SEA-07.3" + "NFO - AT-4": [ + "SAT-04" ], - "SI-14": [ - "SEA-08" + "NFO - SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-05" ], - "SI-14(01)": [ - "SEA-08.1" + "NFO - SA-4(9)": [ + "TDA-02.1" ], - "SI-15": [ - "SEA-09" + "NFO - SA-4(10)": [ + "TDA-02.2" ], - "SI-16": [ - "SEA-10" + "NFO - SA-5": [ + "TDA-04" ], - "SC-26": [ - "SEA-11" + "NFO - SA-4(1)": [ + "TDA-04.1" ], - "SC-35": [ - "SEA-12" + "NFO - SA-4(2)": [ + "TDA-04.1" ], - "SC-29": [ - "SEA-13" + "NFO - SA-1": [ + "TDA-06" ], - "SC-29(01)": [ - "SEA-13.1" + "NFO - SA-11": [ + "TDA-09" ], - "SC-30": [ - "SEA-14" + "NFO - SA-10": [ + "TDA-14" ], - "SC-30(04)": [ - "SEA-14" + "NFO - SA-9": [ + "TPM-04" ], - "SC-30(05)": [ - "SEA-14" + "NFO - SA-9(2)": [ + "TPM-04.2" ], - "SC-30(02)": [ - "SEA-14.1" + "3.14.1": [ + "VPM-01", + "VPM-02", + "VPM-05" ], - "SC-30(03)": [ - "SEA-14.2" + "3.11.2": [ + "VPM-06", + "VPM-06.3" ], - "SC-36": [ - "SEA-15" + "NFO - RA-5(1)": [ + "VPM-06.1" ], - "SC-34": [ - "SEA-16" + "NFO - RA-5(2)": [ + "VPM-06.1" + ] + }, + "general-nist-800-171-r3": { + "03.15.01.a": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "OPS-01", + "OPS-01.1", + "OPS-03" ], - "AC-08": [ - "SEA-18" + "03.12.03": [ + "GOV-01.1", + "GOV-01.2", + "GOV-05", + "CPL-02", + "CPL-03", + "CPL-03.2", + "MON-01", + "TDA-01", + "TDA-01.1", + "TDA-09", + "TDA-09.1" ], - "AC-09": [ - "SEA-19" + "03.15.01.b": [ + "GOV-03", + "OPS-01" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "03.15.03.d": [ + "GOV-03", + "HRS-01", + "HRS-05.1", + "HRS-05.7" ], - "SA-08(32)": [ - "OPS-01.1" + "03.16.01": [ + "GOV-15", + "AST-17", + "PRM-01", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-01", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-03", + "TDA-05", + "TDA-06", + "TPM-01", + "TPM-10" ], - "PL-07": [ - "OPS-02" + "03.17.01.a": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "RSK-01", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-05.7" ], - "IR-04(14)": [ - "OPS-04" + "03.01.03": [ + "AST-01", + "AST-01.1", + "AST-04", + "AST-04.3", + "AST-31", + "CFG-02", + "DCH-01.4", + "DCH-03", + "DCH-14.3", + "END-01", + "IAC-20", + "IAC-20.1", + "NET-04", + "NET-05", + "NET-05.2" ], - "AT-02": [ - "SAT-02" + "03.01.18.a": [ + "AST-01", + "AST-12", + "AST-13", + "AST-14", + "AST-16", + "CFG-02", + "HRS-05.1", + "HRS-05.3", + "HRS-05.5", + "HRS-06", + "MDM-01", + "MDM-02", + "MDM-06", + "MDM-07", + "NET-01", + "NET-03", + "SEA-01", + "SEA-02" ], - "AT-02(01)": [ - "SAT-02.1" + "03.04.11.a": [ + "AST-01", + "AST-02", + "AST-02.8", + "AST-04", + "AST-04.1", + "AST-04.2", + "CPL-01", + "CPL-01.2", + "DCH-02", + "DCH-06.2", + "DCH-19", + "DCH-24", + "IAO-03" ], - "AT-06": [ - "SAT-02.1" + "03.07.04.a": [ + "AST-01", + "AST-05", + "MNT-01", + "MNT-02", + "MNT-03", + "MNT-03.1", + "MNT-04", + "MNT-09" ], - "AT-02(03)": [ - "SAT-02.2" + "03.04.08.c": [ + "AST-01.4", + "AST-02", + "CPL-03.2", + "CFG-03.1" ], - "AT-03": [ - "SAT-03" + "03.04.08.a": [ + "AST-02", + "AST-02.9", + "CFG-02.9", + "CFG-03", + "CFG-03.3" ], - "AT-03(02)": [ - "SAT-03" + "03.04.10.a": [ + "AST-02", + "AST-02.1", + "AST-02.9" ], - "AT-03(03)": [ - "SAT-03.1" + "03.04.10.b": [ + "AST-02", + "AST-02.1", + "AST-02.9" ], - "AT-02(04)": [ - "SAT-03.2" + "03.04.10.c": [ + "AST-02.1" ], - "AT-02(05)": [ - "SAT-03.2" + "03.04.02.b": [ + "AST-02.4", + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-04", + "CPL-03.2", + "CFG-02", + "CFG-02.2", + "CFG-02.7", + "CFG-02.9", + "CFG-06" ], - "AT-03(05)": [ - "SAT-03.3" + "03.04.06.a": [ + "AST-02.4", + "CFG-02", + "CFG-02.5", + "CFG-02.9", + "CFG-03" ], - "AT-02(06)": [ - "SAT-03.6" + "03.04.11.b": [ + "AST-02.8", + "AST-04", + "AST-04.1", + "AST-04.2", + "CHG-02.2", + "CHG-03", + "CHG-05", + "DCH-06.2", + "DCH-19", + "IAO-03", + "IAO-05" ], - "AT-04": [ - "SAT-04" + "03.09.02.a.03": [ + "AST-03", + "AST-03.1", + "AST-10", + "HRS-09", + "HRS-09.1" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "03.15.02.a.04": [ + "AST-04.2", + "CPL-01.2", + "IAO-03" ], - "SA-23": [ - "TDA-01", - "TDA-01.1", - "TDA-12" + "03.07.04.c": [ + "AST-09", + "DCH-09", + "MNT-04.3" ], - "SA-04(09)": [ - "TDA-02.1" + "03.08.03": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21" ], - "SA-04(07)": [ - "TDA-02.2" + "03.11.01.a": [ + "AST-17", + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-02.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-05", + "RSK-09", + "RSK-09.1", + "TPM-02", + "TPM-03", + "TPM-04.1" ], - "SA-04(10)": [ - "TDA-02.2" + "03.04.12.a": [ + "AST-24", + "CFG-02.5", + "CFG-02.9" ], - "SA-04(03)": [ - "TDA-02.3", - "TDA-06" + "03.04.12.b": [ + "AST-24", + "AST-25", + "MDM-04" ], - "SR-03(01)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "03.01.12.a": [ + "AST-27", + "CFG-02", + "HRS-05.1", + "HRS-05.3", + "IAC-08", + "NET-01", + "NET-03", + "NET-14", + "NET-14.2", + "NET-14.5", + "SEA-01", + "SEA-02" ], - "SA-04(05)": [ - "TDA-02.4" + "03.01.12.c": [ + "AST-27", + "NET-14", + "NET-14.3" ], - "SA-10(07)": [ - "TDA-02.7" + "03.08.09.a": [ + "BCD-11", + "BCD-11.4" ], - "SA-15(13)": [ - "TDA-02.14" + "03.08.09.b": [ + "BCD-11.4" ], - "SA-04(06)": [ - "TDA-03" + "03.04.03.a": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CFG-01", + "CFG-06" ], - "PL-08(02)": [ - "TDA-03.1" + "03.04.03.d": [ + "CHG-01", + "CFG-02.2" ], - "SA-17": [ - "TDA-05" + "03.04.03.b": [ + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "CHG-03" ], - "SA-15": [ - "TDA-06" + "03.04.03.c": [ + "CHG-02", + "CHG-02.2", + "MNT-01", + "MNT-02" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "03.07.05.a": [ + "CHG-02", + "CHG-02.1", + "IAC-01.2", + "IAC-05.2", + "MNT-02", + "MNT-05", + "MNT-05.1", + "MNT-05.5" ], - "SA-15(03)": [ - "TDA-06.1" + "03.04.04.a": [ + "CHG-02.2", + "CHG-02.3", + "CHG-03" ], - "SA-11(02)": [ - "TDA-06.2", - "TDA-15" + "03.04.05": [ + "CHG-04", + "CHG-04.4", + "IAC-08", + "IAC-21", + "PES-02", + "PES-02.1", + "PES-03" ], - "SA-15(08)": [ - "TDA-06.2" + "03.04.04.b": [ + "CHG-06" ], - "SI-02(07)": [ - "TDA-06.6" + "03.12.01": [ + "CPL-01", + "CPL-02", + "CPL-02.1", + "CPL-03", + "IAO-01", + "IAO-01.1", + "IAO-02", + "TDA-01", + "TDA-09" ], - "CM-04(01)": [ - "TDA-08" + "03.12.02.a.01": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1" ], - "SA-11": [ - "TDA-09" + "03.12.02.a.02": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1", + "RSK-06", + "VPM-02", + "VPM-05" ], - "SA-11(06)": [ - "TDA-09", - "VPM-01.1" + "03.04.01.a": [ + "CFG-01", + "CFG-02", + "CFG-02.5", + "CFG-02.7", + "CFG-02.9" ], - "SA-11(07)": [ - "TDA-09", - "VPM-01.1" + "03.01.01.h": [ + "CFG-02", + "HRS-05", + "HRS-05.3", + "IAC-25" ], - "SA-04(08)": [ - "TDA-09.1" + "03.01.08.a": [ + "CFG-02", + "IAC-22" ], - "SA-11(01)": [ - "TDA-09.2" + "03.01.08.b": [ + "CFG-02", + "IAC-22" ], - "SA-11(08)": [ - "TDA-09.3" + "03.01.09": [ + "CFG-02", + "SEA-18", + "SEA-18.1", + "SEA-18.2" ], - "SA-11(04)": [ - "TDA-09.7" + "03.01.10.a": [ + "CFG-02", + "IAC-24" ], - "SA-03(02)": [ - "TDA-10" + "03.01.10.b": [ + "CFG-02", + "IAC-24" ], - "SR-04(03)": [ - "TDA-11" + "03.01.10.c": [ + "CFG-02", + "IAC-24.1" ], - "SR-04(04)": [ - "TDA-11" + "03.01.11": [ + "CFG-02", + "IAC-25" ], - "SR-11": [ - "TDA-11" + "03.01.16.a": [ + "CFG-02", + "CRY-07", + "IAO-03", + "NET-01", + "NET-02.2", + "NET-15", + "NET-15.1", + "NET-15.3", + "SEA-01", + "SEA-02" ], - "SR-11(03)": [ - "TDA-11" + "03.01.16.c": [ + "CFG-02", + "NET-15.2", + "NET-15.3", + "SEA-01" ], - "SR-11(01)": [ - "TDA-11.1" + "03.03.08.a": [ + "CFG-02", + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-08.3", + "IAC-21" ], - "SA-20": [ - "TDA-12" + "03.04.02.a": [ + "CFG-02", + "CFG-02.5", + "CFG-02.9", + "CFG-03", + "CFG-06" ], - "SA-21": [ - "TDA-13" + "03.04.06.b": [ + "CFG-02", + "CFG-03" ], - "SA-10": [ - "TDA-14" + "03.04.06.d": [ + "CFG-02", + "CFG-02.5", + "CFG-03" ], - "SA-10(01)": [ - "TDA-14.1" + "03.05.04": [ + "CFG-02", + "IAC-02.2" ], - "SA-10(03)": [ - "TDA-14.2" + "03.05.07.c": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.11", + "IAC-15.1" ], - "SA-16": [ - "TDA-16" + "03.05.07.d": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.6", + "IAC-10.11", + "IAC-15.1" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "03.05.07.e": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.1", + "IAC-10.8", + "IAC-15", + "IAC-15.1" ], - "SI-11": [ - "TDA-19" + "03.05.07.f": [ + "CFG-02", + "IAC-10", + "IAC-10.1", + "IAC-10.11", + "IAC-15.1" ], - "SR-02(01)": [ - "TPM-03" + "03.05.12.d": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.1", + "IAC-10.8", + "IAC-15.1" ], - "SR-05": [ - "TPM-03.1" + "03.07.05.b": [ + "CFG-02", + "IAC-02.2", + "IAC-06", + "MNT-05", + "MNT-05.3" ], - "SR-03(02)": [ - "TPM-03.2" + "03.08.07.a": [ + "CFG-02", + "DCH-10", + "DCH-12" ], - "SR-03": [ - "TPM-03.3" + "03.13.12.b": [ + "CFG-02", + "END-14.6" ], - "SR-05(01)": [ - "TPM-03.4" + "03.04.01.b": [ + "CFG-02.1" ], - "SA-09": [ - "TPM-04" + "03.04.06.c": [ + "CFG-02.1", + "CFG-03.1" ], - "SA-09(01)": [ - "TPM-04.1" + "03.13.13.b": [ + "CFG-02.2", + "CFG-03.3", + "CFG-04", + "CFG-04.1", + "CFG-05", + "END-10" ], - "SA-09(02)": [ - "TPM-04.2" + "03.03.02.b": [ + "CFG-02.9", + "MON-03" ], - "SA-09(04)": [ - "TPM-04.3" + "03.13.11": [ + "CFG-02.9", + "CRY-01", + "CRY-01.5", + "CRY-03", + "CRY-05" ], - "SR-03(03)": [ - "TPM-05", - "TPM-05.2" + "03.04.08.b": [ + "CFG-03.2", + "CFG-03.3" ], - "SR-08": [ - "TPM-05.1" + "03.13.13.a": [ + "CFG-03.3", + "END-10" ], - "SR-06": [ - "TPM-08" + "03.01.02": [ + "CFG-08", + "DCH-01.2", + "DCH-01.4", + "HRS-02", + "HRS-02.1", + "IAC-08", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "SR-06(01)": [ - "TPM-08" + "03.03.01.a": [ + "MON-01", + "MON-01.4", + "MON-02.7", + "MON-03", + "MON-03.2" ], - "PM-16": [ - "THR-01" + "03.14.06.a": [ + "MON-01" ], - "PM-16(01)": [ - "THR-03" + "03.14.06.a.02": [ + "MON-01", + "MON-11.3", + "MON-16", + "END-07" ], - "SI-05(01)": [ - "THR-03" + "03.13.01.a": [ + "MON-01.1", + "MON-01.3", + "NET-01", + "NET-03", + "NET-04", + "NET-04.1", + "NET-08" ], - "PM-12": [ - "THR-04" + "03.14.06.c": [ + "MON-01.3", + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07", + "NET-08", + "NET-18" ], - "AT-02(02)": [ - "THR-05" + "03.03.03.a": [ + "MON-01.4" ], - "RA-05(11)": [ - "THR-06" + "03.14.06.a.01": [ + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07" ], - "RA-10": [ - "THR-07" + "03.14.06.b": [ + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07" ], - "SI-20": [ - "THR-08" + "03.03.05.a": [ + "MON-01.8", + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-16" ], - "SI-02(04)": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "03.03.04.a": [ + "MON-01.12" ], - "SI-02(02)": [ - "VPM-05.2" + "03.03.05.b": [ + "MON-01.12", + "MON-06" ], - "SI-02(03)": [ - "VPM-05.3" + "03.01.07.b": [ + "MON-01.15", + "MON-03.3", + "IAC-09.5", + "IAC-16", + "IAC-21.4" ], - "SI-02(05)": [ - "VPM-05.4" + "03.03.05.c": [ + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-02.3" ], - "SI-02(06)": [ - "VPM-05.5" + "03.03.01.b": [ + "MON-02.6", + "MON-03.6" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "03.03.02.a": [ + "MON-03" ], - "RA-05(02)": [ - "VPM-06.1" + "03.03.02.a.01": [ + "MON-03" ], - "RA-05(03)": [ - "VPM-06.2" + "03.03.02.a.02": [ + "MON-03", + "MON-07" ], - "RA-05(05)": [ - "VPM-06.3" + "03.03.02.a.03": [ + "MON-03" ], - "RA-05(06)": [ - "VPM-06.4" + "03.03.02.a.04": [ + "MON-03" ], - "RA-05(08)": [ - "VPM-06.5" + "03.03.02.a.05": [ + "MON-03" ], - "RA-05(04)": [ - "VPM-06.8" + "03.03.02.a.06": [ + "MON-03" + ], + "03.03.04.b": [ + "MON-05", + "IRO-02" ], - "RA-05(10)": [ - "VPM-06.9" + "03.03.06.a": [ + "MON-06" ], - "CA-08": [ - "VPM-07" + "03.03.07.a": [ + "MON-07" ], - "CA-08(01)": [ - "VPM-07.1" + "03.03.07.b": [ + "MON-07.1" ], - "RA-06": [ - "VPM-08" + "03.03.03.b": [ + "MON-08", + "MON-10" ], - "CA-08(02)": [ - "VPM-10" + "03.03.06.b": [ + "MON-08" ], - "SC-07(17)": [ - "WEB-03" - ] - }, - "general-nist-800-53-r5-2-privacy": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "03.03.08.b": [ + "MON-08", + "MON-08.2", + "IAC-08", + "IAC-21" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "03.01.22.b": [ + "MON-11", + "DCH-15", + "IRO-12", + "WEB-14" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "03.01.01.e": [ + "MON-16", + "IAC-15", + "IAC-15.7" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "03.13.08": [ + "CRY-01", + "CRY-01.1", + "CRY-03", + "CRY-05", + "CRY-05.1" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "03.13.10": [ + "CRY-08", + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "03.01.01.d.01": [ + "DCH-01", + "DCH-01.2", + "HRS-02", + "IAC-01.2", + "IAC-15", + "IAC-15.1", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "03.01.01.d.02": [ + "DCH-01", + "DCH-01.2", + "HRS-02", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "03.08.01": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-03", + "DCH-06", + "DCH-06.1", + "DCH-06.4", + "PES-01", + "PES-02", + "PES-02.1", + "PES-04", + "PES-04.1" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "03.08.05.a": [ + "DCH-01.1", + "DCH-01.2", + "DCH-07", + "DCH-07.1", + "DCH-07.2" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "03.01.20.a": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.2", + "DCH-13.4", + "DCH-17", + "TPM-01", + "TPM-05.8" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "03.01.20.b": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.3", + "DCH-14", + "DCH-14.2", + "TPM-01", + "TPM-05", + "TPM-05.8" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "03.01.20.c.01": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.3", + "DCH-13.4", + "TPM-01", + "TPM-05", + "TPM-05.6", + "TPM-05.8" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "03.01.20.d": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.2", + "DCH-13.4", + "MDM-01", + "MDM-07" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "03.06.05.d": [ + "DCH-01.2", + "HRS-03", + "IAC-08", + "IAC-20.1", + "IRO-04" ], - "PT-01": [ - "GOV-02", - "GOV-03", - "PRI-01", - "SEA-01" + "03.08.02": [ + "DCH-01.2", + "DCH-01.4", + "DCH-03", + "HRS-03", + "PES-01", + "PES-02", + "PES-02.1", + "PES-04", + "PES-04.1" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "03.17.01.c": [ + "DCH-01.2", + "DCH-01.4", + "DCH-03.1" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "03.08.05.c": [ + "DCH-01.3", + "DCH-07" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "03.01.04.b": [ + "DCH-01.4", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "03.10.01.a": [ + "DCH-01.4", + "IAC-20.1", + "PES-01", + "PES-02", + "PES-06", + "PES-06.1" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "03.15.02.c": [ + "DCH-01.4", + "DCH-03.1" ], - "PL-09": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "03.08.04": [ + "DCH-02", + "DCH-04" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "03.01.22.a": [ + "DCH-03.1", + "DCH-15", + "HRS-03", + "HRS-03.1", + "HRS-04.1", + "HRS-04.2", + "HRS-05", + "HRS-05.1", + "SAT-02", + "SAT-03", + "SAT-03.3", + "WEB-01" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "03.08.05.b": [ + "DCH-07", + "DCH-07.1" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "03.08.07.b": [ + "DCH-10.2" ], - "PM-15": [ - "GOV-07", - "THR-01" + "03.01.20.c.02": [ + "DCH-13", + "DCH-13.1", + "DCH-14.2", + "DCH-14.3", + "DCH-18", + "NET-05", + "TPM-05" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "03.12.05.a": [ + "DCH-14.2", + "DCH-14.3", + "HRS-06", + "HRS-06.1", + "NET-05" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "03.10.07.b": [ + "DCH-18", + "PES-03.3" ], - "PM-05": [ - "AST-01", - "AST-02" + "03.14.08": [ + "DCH-18" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "03.14.02.a": [ + "END-01", + "END-04.3", + "END-04.7" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "03.14.02.c": [ + "END-04" ], - "SC-18(02)": [ - "AST-02.7", - "END-10" + "03.14.02.c.01": [ + "END-04", + "END-04.7" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "03.14.02.c.02": [ + "END-04", + "END-04.7" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "03.14.02.b": [ + "END-04.1" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "03.13.12.a": [ + "END-14" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "03.01.01.g.02": [ + "HRS-01", + "HRS-08", + "HRS-09", + "HRS-09.4", + "IAC-07", + "IAC-07.1", + "IAC-15" ], - "PE-22": [ - "AST-04.1", - "PES-16" + "03.15.03.a": [ + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "HRS-05.3", + "HRS-05.4", + "HRS-05.5" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "03.01.01.c.01": [ + "HRS-02", + "IAC-08", + "IAC-15", + "IAC-15.5" ], - "SR-12": [ - "AST-09" + "03.01.01.c.02": [ + "HRS-02", + "IAC-08", + "IAC-15" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "03.09.01.a": [ + "HRS-02", + "HRS-04", + "HRS-04.1" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "03.09.01.b": [ + "HRS-02", + "HRS-04", + "HRS-04.1" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "03.15.03.b": [ + "HRS-02", + "HRS-03", + "HRS-03.1", + "HRS-04.2", + "HRS-05" ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" + "03.02.02.a.01": [ + "HRS-03", + "HRS-04.1", + "HRS-04.2", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "03.06.04.a": [ + "HRS-03", + "HRS-04.2", + "IRO-05", + "SAT-03" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "03.07.06.a": [ + "HRS-03", + "IAC-08", + "MNT-01", + "MNT-06", + "TPM-01", + "TPM-01.1", + "TPM-05", + "TPM-05.4" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "03.07.06.d": [ + "HRS-03", + "HRS-03.2", + "MNT-06", + "MNT-06.1" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "03.16.03.b": [ + "HRS-03", + "HRS-10", + "TPM-05", + "TPM-05.2", + "TPM-05.4" ], - "SC-28(02)": [ - "BCD-11", - "CRY-05.2" + "03.09.02.b.01": [ + "HRS-04", + "HRS-08", + "HRS-09", + "HRS-09.2" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "03.06.04.a.01": [ + "HRS-04.2", + "SAT-03" ], - "SI-13": [ - "BCD-12.2", - "SEA-07" + "03.15.03.c": [ + "HRS-05.7", + "HRS-06", + "HRS-06.1" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "03.01.01.f.04": [ + "HRS-07", + "HRS-07.1", + "IAC-15", + "IAC-15.6" ], - "SC-05(02)": [ - "CAP-02", - "CAP-03" + "03.01.01.f.05": [ + "HRS-07", + "HRS-07.1", + "IAC-15", + "IAC-15.6" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "03.09.02.a": [ + "HRS-08", + "HRS-09" ], - "SA-08(31)": [ - "CHG-02", - "CHG-02.2", - "CHG-06" + "03.09.02.b.02": [ + "HRS-08", + "IAC-07.1", + "IAC-20" ], - "CM-03(02)": [ - "CHG-02.2", - "CHG-06" + "03.01.01.f.03": [ + "HRS-09", + "IAC-15" ], - "CM-04": [ - "CHG-03" + "03.09.02.a.02": [ + "HRS-09", + "HRS-09.2", + "HRS-09.4", + "IAC-07", + "IAC-07.2" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "03.09.02.a.01": [ + "HRS-09.2", + "HRS-09.4", + "IAC-07", + "IAC-07.2" ], - "AC-05": [ - "CHG-04.3", + "03.01.04.a": [ "HRS-11", - "NET-12", - "TDA-18" + "HRS-12" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "03.01.01.a": [ + "IAC-01", + "IAC-15" ], - "SC-07(29)": [ - "CLD-03", - "NET-03.8", - "NET-06.1" + "03.01.18.b": [ + "IAC-01", + "IAC-04", + "MDM-02", + "MDM-06", + "MDM-07", + "MDM-11" ], - "SA-09(05)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "03.05.01.a": [ + "IAC-01", + "IAC-01.2", + "IAC-02", + "IAC-03", + "IAC-05" ], - "SA-09(08)": [ - "CLD-09", - "DCH-19" + "03.05.05.a": [ + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-28.1" ], - "CA-07": [ - "CPL-02" + "03.05.12.e": [ + "IAC-01", + "IAC-10", + "IAC-10.1", + "IAC-15.1" ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" + "03.01.16.b": [ + "IAC-01.2", + "NET-02.2", + "NET-15", + "NET-15.1" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "03.05.02": [ + "IAC-01.2", + "IAC-04", + "IAC-05" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "03.05.05.d": [ + "IAC-01.2", + "IAC-02", + "IAC-09", + "IAC-09.2", + "IAC-09.5", + "IAC-15.1" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "03.05.07.a": [ + "IAC-01.2", + "IAC-10", + "IAC-10.4", + "IAC-10.11" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "03.05.07.b": [ + "IAC-01.2", + "IAC-10", + "IAC-10.4", + "IAC-10.11" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "03.05.03": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "03.01.01.b": [ + "IAC-07", + "IAC-15", + "IAC-15.7", + "IAC-28.1" ], - "SA-15(05)": [ - "CFG-02", - "SEA-01" + "03.01.01.g.01": [ + "IAC-07", + "IAC-07.1", + "IAC-15" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" + "03.01.01.g.03": [ + "IAC-07", + "IAC-07.1", + "IAC-15", + "IAC-17" ], - "SC-18(04)": [ - "CFG-03.3", - "END-10" + "03.01.01.c.03": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CM-11": [ - "CFG-05", - "END-03" + "03.01.05.b": [ + "IAC-08", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CM-11(02)": [ - "CFG-05", - "CFG-05.2", - "END-03" + "03.01.06.a": [ + "IAC-08", + "IAC-16", + "IAC-20", + "IAC-21", + "IAC-21.3" ], - "CM-11(03)": [ - "CFG-05.1", - "CFG-06", - "CFG-06.1", - "END-03.1" + "03.05.05.b": [ + "IAC-09", + "IAC-09.1", + "IAC-15.1" ], - "PM-31": [ - "MON-01" + "03.05.05.c": [ + "IAC-09", + "IAC-15.1" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "03.05.12.a": [ + "IAC-10", + "IAC-10.3", + "IAC-28" ], - "SI-04(25)": [ - "MON-01.1", - "NET-03.1" + "03.05.12.b": [ + "IAC-10", + "IAC-10.1" ], - "SC-48": [ - "MON-01.2", - "THR-07" + "03.05.12.c": [ + "IAC-10" ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" + "03.05.12.f": [ + "IAC-10", + "IAC-10.5", + "IAC-15.1" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "03.05.11": [ + "IAC-11" ], - "IR-04(05)": [ - "MON-01.11", - "IRO-02.6" + "03.05.01.b": [ + "IAC-14" ], - "SI-04(07)": [ - "MON-01.11", - "IRO-02.1" + "03.01.01.f.01": [ + "IAC-15" ], - "SI-04(12)": [ - "MON-01.12", - "MON-05.1" + "03.01.01.f.02": [ + "IAC-15", + "IAC-15.3" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "03.01.05.c": [ + "IAC-15", + "IAC-15.7", + "IAC-17" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "03.01.05.d": [ + "IAC-15", + "IAC-17" ], - "AU-03(03)": [ - "MON-03.5" + "03.01.07.a": [ + "IAC-16", + "IAC-21", + "IAC-21.3", + "IAC-21.5" ], - "AU-08": [ - "MON-07", - "SEA-20" + "03.10.01.c": [ + "IAC-17", + "PES-02" ], - "AU-11": [ - "MON-10" + "03.10.01.d": [ + "IAC-17", + "PES-02", + "PES-02.1" ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" + "03.01.05.a": [ + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "IR-04(13)": [ - "MON-16", - "SEA-11", - "SEA-12" + "03.01.06.b": [ + "IAC-21.2" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "03.07.05.c": [ + "IAC-25", + "MNT-05", + "MNT-05.4", + "NET-07" ], - "SC-08(02)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" + "03.06.01": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-12" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "03.06.02.a": [ + "IRO-02", + "IRO-09" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "03.06.02.b": [ + "IRO-02", + "IRO-07", + "IRO-09", + "IRO-10", + "IRO-10.2" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "03.06.02.c": [ + "IRO-02", + "IRO-10", + "IRO-10.2", + "IRO-14" ], - "SC-16(01)": [ - "CRY-04", - "CRY-10" + "03.06.02.d": [ + "IRO-02", + "IRO-07", + "IRO-10", + "IRO-11" ], - "SC-28": [ - "CRY-05", - "END-02" + "03.06.05.b": [ + "IRO-02", + "IRO-04" ], - "AC-18": [ - "CRY-07", - "NET-15" + "03.06.05.a": [ + "IRO-04" ], - "SC-40": [ - "CRY-07", - "NET-12.1" + "03.06.05.a.01": [ + "IRO-04" ], - "MP-02": [ - "DCH-03", - "END-01" + "03.06.05.a.02": [ + "IRO-04" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "03.06.05.a.03": [ + "IRO-04" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "03.06.05.a.04": [ + "IRO-04" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" + "03.06.05.a.05": [ + "IRO-04" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "03.06.05.a.06": [ + "IRO-04" ], - "PM-17": [ - "DCH-13.3" + "03.06.05.c": [ + "IRO-04.2" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "03.06.04.b": [ + "IRO-04.3", + "IRO-13", + "SAT-01.1" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "03.06.04.a.03": [ + "IRO-05", + "SAT-02", + "SAT-03" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "03.06.03": [ + "IRO-06" ], - "SI-12(01)": [ - "DCH-18.1", - "PRI-05.1" + "03.15.02.a": [ + "IAO-03" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "03.15.02.a.01": [ + "IAO-03" ], - "SA-08(33)": [ - "DCH-18.2", - "END-13.3", - "PES-06.5" + "03.15.02.a.02": [ + "IAO-03" ], - "SI-12(02)": [ - "DCH-18.2", - "PRI-05.1" + "03.15.02.a.03": [ + "IAO-03", + "RSK-03.1", + "THR-09" ], - "SI-12(03)": [ - "DCH-21", - "PRI-05" + "03.15.02.a.05": [ + "IAO-03" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "03.15.02.a.06": [ + "IAO-03" ], - "SI-18": [ - "DCH-22" + "03.15.02.a.07": [ + "IAO-03" ], - "SI-18(04)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "03.15.02.a.08": [ + "IAO-03" ], - "SI-18(05)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "03.15.02.b": [ + "IAO-03" ], - "PT-03(01)": [ - "DCH-22.2", - "PRI-11" + "03.12.02.a": [ + "IAO-05" ], - "SI-19(01)": [ - "DCH-22.3", - "DCH-23.1" + "03.12.02.b": [ + "IAO-05" ], - "SI-19": [ - "DCH-23" + "03.12.02.b.01": [ + "IAO-05" ], - "SI-19(04)": [ - "DCH-23.4", - "PRI-05.3" + "03.12.02.b.02": [ + "IAO-05" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", + "03.12.02.b.03": [ + "IAO-05" + ], + "03.14.01.a": [ + "IAO-05", + "TDA-01", + "TDA-09", + "THR-01", + "THR-06", "VPM-01", - "VPM-05" + "VPM-01.1", + "VPM-02", + "VPM-04", + "VPM-05", + "VPM-06" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "03.07.04.b": [ + "MNT-04.1" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "03.01.12.d": [ + "MNT-05", + "NET-14.4" ], - "SC-18(01)": [ - "END-10", - "VPM-02", - "VPM-04" + "03.07.06.b": [ + "MNT-06", + "TPM-01.1", + "TPM-05.4" ], - "SC-18(03)": [ - "END-10", - "NET-18" + "03.07.06.c": [ + "MNT-06", + "MNT-06.1", + "MNT-06.2" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "03.01.18.c": [ + "MDM-03" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "03.13.01.b": [ + "NET-02", + "NET-03", + "NET-03.8", + "NET-06", + "NET-06.3", + "NET-08.1" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "03.13.01.c": [ + "NET-03", + "NET-04", + "SEA-01", + "SEA-02" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "03.13.06": [ + "NET-04.1" ], - "PL-04(01)": [ - "HRS-05.2" + "03.12.05.b": [ + "NET-05", + "NET-05.2" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "03.12.05.c": [ + "NET-05.2" ], - "PS-06(02)": [ - "HRS-06", - "HRS-06.1" + "03.13.09": [ + "NET-07" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "03.13.15": [ + "NET-09" ], - "AC-03(02)": [ - "HRS-12.1", - "IAC-20.5" + "03.01.12.b": [ + "NET-14", + "NET-14.1" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "03.10.06.a": [ + "NET-14.5", + "PES-11" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "03.10.06.b": [ + "NET-14.5", + "PES-11" ], - "IA-03(04)": [ - "IAC-04", - "IAC-04.1" + "03.01.16.d": [ + "NET-15.1" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "03.10.07.a": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "03.10.07.a.01": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1", + "PES-03.4", + "PES-04", + "PES-04.1" ], - "IA-12(04)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" + "03.10.01.b": [ + "PES-02", + "PES-02.1" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "03.10.02.a": [ + "PES-03", + "PES-03.1", + "PES-03.3", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "IA-05(08)": [ - "IAC-09.5", - "IAC-10.9" + "03.10.07.a.02": [ + "PES-03", + "PES-03.1", + "PES-03.3", + "PES-03.4", + "PES-04", + "PES-04.1" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "03.10.07.d": [ + "PES-03", + "PES-04", + "PES-04.1" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "03.10.02.b": [ + "PES-05", + "PES-05.2" ], - "IA-05(02)": [ - "IAC-10.2" + "03.10.07.c": [ + "PES-06", + "PES-06.1", + "PES-06.2", + "PES-06.3", + "PES-06.6" ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" + "03.10.08": [ + "PES-07", + "PES-12", + "PES-12.1" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "03.10.07.e": [ + "PES-12", + "PES-12.2" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "03.17.03.b": [ + "RSK-01", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7" ], - "IR-04": [ - "IRO-02" + "03.14.03.b": [ + "RSK-02.1", + "THR-03.1", + "THR-10" ], - "IR-08": [ - "IRO-04" + "03.11.02.b": [ + "RSK-06", + "RSK-06.1", + "RSK-06.2", + "VPM-02", + "VPM-04", + "VPM-05" ], - "IR-08(01)": [ - "IRO-04.1" + "03.11.04": [ + "RSK-06.1" ], - "IR-02": [ - "IRO-05" + "03.11.01.b": [ + "RSK-07", + "RSK-09.1" ], - "IR-02(03)": [ - "IRO-05" + "03.17.01.b": [ + "RSK-09" ], - "IR-03": [ - "IRO-06" + "03.17.03.a": [ + "RSK-09", + "RSK-09.1", + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05.5" ], - "IR-04(12)": [ - "IRO-08", - "IRO-13" + "03.13.04": [ + "SEA-05" ], - "IR-05": [ - "IRO-09" + "03.16.02.b": [ + "SEA-07", + "SEA-07.1", + "TDA-17.1" ], - "IR-06(02)": [ - "IRO-10.3", - "IRO-13" + "03.16.02.a": [ + "SEA-07.1", + "TDA-17" ], - "IR-04(10)": [ - "IRO-10.4", - "TPM-11" + "03.02.01.a": [ + "SAT-01" ], - "IR-07": [ - "IRO-11" + "03.02.01.b": [ + "SAT-01.1" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "03.02.02.a.02": [ + "SAT-01.1", + "SAT-03", + "SAT-03.6" ], - "PM-10": [ - "IAO-01" + "03.02.02.b": [ + "SAT-01.1" ], - "SA-11(05)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "03.02.01.a.01": [ + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" ], - "CA-05": [ - "IAO-05" + "03.02.01.a.02": [ + "SAT-02", + "SAT-03", + "SAT-03.6", + "THR-03" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "03.02.01.a.03": [ + "SAT-02", + "SAT-02.2", + "SAT-03.6", + "THR-03", + "THR-05" ], - "CA-06": [ - "IAO-07" + "03.02.02.a": [ + "SAT-03" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "03.06.04.a.02": [ + "SAT-03", + "SAT-03.6" ], - "SC-07(09)": [ - "NET-03", - "NET-03.2" + "03.17.02": [ + "TDA-01", + "TPM-01", + "TPM-03.1", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.1", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7", + "TPM-08", + "TPM-09", + "TPM-10" ], - "SC-07(11)": [ - "NET-03", - "NET-04.1" + "03.16.03.a": [ + "TPM-01", + "TPM-04", + "TPM-04.4", + "TPM-05", + "TPM-05.2", + "TPM-05.8" ], - "SC-07(24)": [ - "NET-03.4" + "03.16.03.c": [ + "TPM-04", + "TPM-05", + "TPM-05.2", + "TPM-05.5", + "TPM-05.6", + "TPM-05.8", + "TPM-08" ], - "SC-07(10)": [ - "NET-03.5", - "NET-17" + "03.11.02.a": [ + "THR-01", + "THR-03", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-06" ], - "SI-05": [ - "NET-12", - "TDA-18", + "03.14.03.a": [ + "THR-01", "THR-03" ], - "SI-10": [ - "NET-12", - "TDA-18" + "03.14.01.b": [ + "VPM-05" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "03.11.02.c": [ + "VPM-06.1" + ] + }, + "general-nist-800-171a": { + "3.4.9[a]": [ + "GOV-02" ], - "SC-07(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "3.9.2[a]": [ + "GOV-02", + "HRS-01", + "HRS-07", + "HRS-08", + "HRS-09" ], - "PE-08(03)": [ - "PES-06.5" + "3.4.1[d]": [ + "AST-02" ], - "PE-13(02)": [ - "PES-08.2", - "PES-08.3" + "3.4.1[e]": [ + "AST-02" ], - "PM-18": [ - "PRI-01" + "3.4.1[f]": [ + "AST-02", + "AST-02.1" ], - "PM-19": [ - "PRI-01.1" + "3.8.9": [ + "BCD-11", + "BCD-11.4" ], - "PT-05(02)": [ - "PRI-01.2" + "3.4.3[a]": [ + "CHG-02" ], - "PM-20": [ - "PRI-01.3" + "3.4.3[b]": [ + "CHG-02" ], - "PM-20(01)": [ - "PRI-02" + "3.4.3[c]": [ + "CHG-02" ], - "PT-05": [ - "PRI-02" + "3.4.3[d]": [ + "CHG-02" ], - "PT-03": [ - "PRI-02.1", - "PRI-05.1" + "3.4.4": [ + "CHG-03" ], - "PT-03(02)": [ - "PRI-02.2", - "PRI-10.1" + "3.4.5[a]": [ + "CHG-04", + "END-03.2" ], - "PT-08": [ - "PRI-02.3" + "3.4.5[b]": [ + "CHG-04", + "END-03.2" ], - "PT-06": [ - "PRI-02.4" + "3.4.5[c]": [ + "CHG-04", + "END-03.2" ], - "PT-06(01)": [ - "PRI-02.5" + "3.4.5[d]": [ + "CHG-04", + "END-03.2" ], - "PT-06(02)": [ - "PRI-02.6" + "3.4.5[e]": [ + "CHG-04", + "END-03.2" ], - "PT-04": [ - "PRI-03" + "3.4.5[f]": [ + "CHG-04", + "END-03.2" ], - "PT-02": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "3.4.5[g]": [ + "CHG-04", + "END-03.2" ], - "PT-07": [ - "PRI-05.4", - "PRI-05.7" + "3.4.5[h]": [ + "CHG-04", + "END-03.2" ], - "PM-05(01)": [ - "PRI-05.5", - "PRI-05.6" + "3.1.22[a]": [ + "CLD-06", + "CLD-10", + "DCH-15", + "WEB-02", + "WEB-04" ], - "PT-07(01)": [ - "PRI-05.7" + "3.1.22[b]": [ + "CLD-06", + "CLD-10", + "DCH-15", + "WEB-02", + "WEB-04" ], - "PT-07(02)": [ - "PRI-05.7" + "3.1.22[c]": [ + "CLD-06", + "CLD-10", + "DCH-15", + "WEB-02", + "WEB-04" ], - "AC-03(14)": [ - "PRI-06" + "3.1.22[d]": [ + "CLD-06", + "CLD-10", + "DCH-15", + "WEB-02", + "WEB-04" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "3.1.22[e]": [ + "CLD-06", + "CLD-10", + "DCH-15", + "WEB-02", + "WEB-04" ], - "PM-27": [ - "PRI-14" + "3.12.1[a]": [ + "CPL-02" ], - "PM-21": [ - "PRI-14.1" + "3.12.1[b]": [ + "CPL-02" ], - "PM-03": [ - "PRM-02" + "3.12.3": [ + "CPL-02" ], - "SA-02": [ - "PRM-03" + "3.4.1[a]": [ + "CFG-02", + "END-01" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "3.4.1[b]": [ + "CFG-02", + "END-01" ], - "PM-11": [ - "PRM-06" + "3.4.1[c]": [ + "CFG-02", + "END-01" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "3.4.2[a]": [ + "CFG-02", + "END-01" ], - "SA-03(01)": [ - "PRM-07", - "SEA-07.1", - "TDA-07" + "3.4.2[b]": [ + "CFG-02", + "END-01" ], - "SA-08(30)": [ - "PRM-07", - "SEA-07.1" + "3.4.6[a]": [ + "CFG-03" ], - "PM-09": [ - "RSK-01" + "3.4.6[b]": [ + "CFG-03" ], - "PM-28": [ - "RSK-01.1" + "3.4.7[a]": [ + "CFG-03.1" ], - "RA-07": [ - "RSK-06.1" + "3.4.7[b]": [ + "CFG-03.1" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "3.4.7[c]": [ + "CFG-03.1" ], - "SR-07": [ - "RSK-09", - "OPS-01" + "3.4.7[d]": [ + "CFG-03.1" ], - "RA-08": [ - "RSK-10" + "3.4.7[e]": [ + "CFG-03.1" ], - "CA-07(04)": [ - "RSK-11" + "3.4.7[f]": [ + "CFG-03.1" ], - "PL-08": [ - "SEA-02" + "3.4.7[g]": [ + "CFG-03.1" ], - "PM-07": [ - "SEA-02" + "3.4.7[h]": [ + "CFG-03.1" ], - "SA-03(03)": [ - "SEA-07.1", - "SEA-08.1" + "3.4.7[i]": [ + "CFG-03.1" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "3.4.7[j]": [ + "CFG-03.1" ], - "AT-02": [ - "SAT-02" + "3.4.7[k]": [ + "CFG-03.1" ], - "AT-03": [ - "SAT-03" + "3.4.7[l]": [ + "CFG-03.1" ], - "AT-03(05)": [ - "SAT-03.3" + "3.4.7[m]": [ + "CFG-03.1" ], - "AT-04": [ - "SAT-04" + "3.4.7[n]": [ + "CFG-03.1" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "3.4.7[o]": [ + "CFG-03.1" ], - "SA-23": [ - "TDA-01", - "TDA-01.1", - "TDA-12" + "3.4.8[a]": [ + "CFG-03.3" ], - "SA-04(03)": [ - "TDA-02.3", - "TDA-06" + "3.4.8[b]": [ + "CFG-03.3" ], - "SR-03(01)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "3.4.8[c]": [ + "CFG-03.3" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "3.13.7": [ + "CFG-03.4" ], - "SA-11(02)": [ - "TDA-06.2", - "TDA-15" + "3.4.9[b]": [ + "CFG-05" ], - "SA-11": [ - "TDA-09" + "3.4.9[c]": [ + "CFG-05" ], - "SA-11(06)": [ - "TDA-09", - "VPM-01.1" + "3.14.6[a]": [ + "MON-01.3" ], - "SA-11(07)": [ - "TDA-09", - "VPM-01.1" + "3.14.6[b]": [ + "MON-01.3" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "3.14.6[c]": [ + "MON-01.3" ], - "SA-09": [ - "TPM-04" + "3.3.3[a]": [ + "MON-01.8" ], - "SR-03(03)": [ - "TPM-05", - "TPM-05.2" + "3.3.3[b]": [ + "MON-01.8" ], - "SI-02(04)": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "3.3.3[c]": [ + "MON-01.8" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" - ] - }, - "general-nist-800-53-r5-2-low": { - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "3.14.3[a]": [ + "MON-01.8" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "3.14.3[b]": [ + "MON-01.8" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "3.14.3[c]": [ + "MON-01.8" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "3.3.5[a]": [ + "MON-02.1" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "3.3.5[b]": [ + "MON-02.1" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "3.14.7[a]": [ + "MON-02.1" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "3.14.7[b]": [ + "MON-02.1" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "3.3.1[a]": [ + "MON-03" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "3.3.1[b]": [ + "MON-03" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "3.3.1[d]": [ + "MON-03" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "3.3.2[a]": [ + "MON-03", + "MON-03.2", + "MON-03.7" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "3.3.2[b]": [ + "MON-03" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "3.3.1[c]": [ + "MON-03.2" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "3.3.4[a]": [ + "MON-05" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "3.3.4[b]": [ + "MON-05" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "3.3.4[c]": [ + "MON-05" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "3.3.6[a]": [ + "MON-06" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "3.3.6[b]": [ + "MON-06" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "3.3.7[a]": [ + "MON-07" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "3.3.7[b]": [ + "MON-07", + "MON-07.1" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "3.3.7[c]": [ + "MON-07.1" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "3.3.8[a]": [ + "MON-08" ], - "SR-12": [ - "AST-09" + "3.3.8[b]": [ + "MON-08" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "3.3.8[c]": [ + "MON-08" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "3.3.8[d]": [ + "MON-08" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "3.3.8[e]": [ + "MON-08" ], - "CP-03": [ - "BCD-03" + "3.3.8[f]": [ + "MON-08" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "3.3.9[a]": [ + "MON-08.2" ], - "CP-09": [ - "BCD-11" + "3.3.9[b]": [ + "MON-08.2" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "3.3.1[e]": [ + "MON-10" ], - "CM-04": [ - "CHG-03" + "3.3.1[f]": [ + "MON-10" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "3.13.8[a]": [ + "CRY-01", + "CRY-03" ], - "CA-07": [ - "CPL-02" + "3.13.11": [ + "CRY-01", + "CRY-03" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "3.13.8[b]": [ + "CRY-01.1" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "3.13.8[c]": [ + "CRY-01.1" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "3.8.6": [ + "CRY-05" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "3.13.10[a]": [ + "CRY-08", + "CRY-09" ], - "PL-10": [ - "CFG-02" + "3.13.10[b]": [ + "CRY-08", + "CRY-09" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "3.8.1[a]": [ + "DCH-01" ], - "PL-11": [ - "CFG-02.9" + "3.8.1[b]": [ + "DCH-01" ], - "CM-07": [ - "CFG-03" + "3.8.1[c]": [ + "DCH-01" ], - "CM-10": [ - "CFG-04" + "3.8.1[d]": [ + "DCH-01" ], - "CM-11": [ - "CFG-05", - "END-03" + "3.1.3[c]": [ + "DCH-03", + "IAC-08", + "NET-04" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "3.8.2": [ + "DCH-03" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "3.8.4[a]": [ + "DCH-04" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "3.8.4[b]": [ + "DCH-04" ], - "AU-03": [ - "MON-03" + "3.8.5[a]": [ + "DCH-07" ], - "AU-04": [ - "MON-04" + "3.8.5[b]": [ + "DCH-07" ], - "AU-05": [ - "MON-05" + "3.7.3": [ + "DCH-09" ], - "AU-12": [ - "MON-06" + "3.8.3[a]": [ + "DCH-09" ], - "AU-08": [ - "MON-07", - "SEA-20" + "3.8.3[b]": [ + "DCH-09" ], - "AU-09": [ - "MON-08" + "3.8.7": [ + "DCH-10" + ], + "3.8.8": [ + "DCH-10.2" + ], + "3.1.20[a]": [ + "DCH-13" + ], + "3.1.20[b]": [ + "DCH-13" + ], + "3.1.20[c]": [ + "DCH-13" ], - "AU-11": [ - "MON-10" + "3.1.20[d]": [ + "DCH-13" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "3.1.20[e]": [ + "DCH-13" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "3.1.20[f]": [ + "DCH-13" ], - "AC-18": [ - "CRY-07", - "NET-15" + "3.1.21[a]": [ + "DCH-13.2" ], - "SC-12": [ - "CRY-08" + "3.1.21[b]": [ + "DCH-13.2" ], - "MP-02": [ - "DCH-03", - "END-01" + "3.1.21[c]": [ + "DCH-13.2" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "3.13.16": [ + "END-02" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "3.14.2[a]": [ + "END-04" ], - "AC-20": [ - "DCH-13" + "3.14.2[b]": [ + "END-04" ], - "AC-22": [ - "DCH-15" + "3.14.5[a]": [ + "END-04" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "3.14.5[b]": [ + "END-04" ], - "SI-03": [ + "3.14.5[c]": [ "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "END-04.7" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "3.14.4": [ + "END-04.1" ], - "SC-15": [ - "END-14" + "3.13.13[a]": [ + "END-10" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "3.13.13[b]": [ + "END-10" ], - "PS-09": [ - "HRS-03" + "3.13.12[a]": [ + "END-14" ], - "PS-03": [ - "HRS-04" + "3.13.12[b]": [ + "END-14" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "3.13.12[c]": [ + "END-14" ], - "PL-04(01)": [ - "HRS-05.2" + "3.2.2[a]": [ + "HRS-01", + "SAT-03" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "3.2.2[b]": [ + "HRS-01", + "SAT-03" ], - "PS-08": [ - "HRS-07" + "3.2.2[c]": [ + "HRS-01", + "SAT-03" ], - "PS-05": [ - "HRS-08" + "3.9.1": [ + "HRS-04" ], - "PS-04": [ + "3.9.2[b]": [ + "HRS-07", + "HRS-08", "HRS-09" ], - "PS-07": [ - "HRS-10" + "3.9.2[c]": [ + "HRS-07", + "HRS-08", + "HRS-09" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "3.1.4[a]": [ + "HRS-11" ], - "IA-02": [ + "3.1.4[b]": [ + "HRS-11" + ], + "3.1.4[c]": [ + "HRS-11" + ], + "3.5.1[a]": [ "IAC-02" ], - "IA-02(08)": [ - "IAC-02.2" + "3.5.1[b]": [ + "IAC-02" ], - "IA-02(12)": [ - "IAC-02.3" + "3.5.1[c]": [ + "IAC-02" ], - "IA-08": [ - "IAC-03" + "3.5.2[a]": [ + "IAC-02" ], - "IA-08(01)": [ - "IAC-03.1" + "3.5.2[b]": [ + "IAC-02" ], - "IA-08(02)": [ - "IAC-03.2" + "3.5.2[c]": [ + "IAC-02" ], - "IA-08(04)": [ - "IAC-03.3" + "3.5.4": [ + "IAC-02.2" ], - "IA-02(01)": [ - "IAC-06", + "3.5.3[a]": [ "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "IAC-06.3" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "3.5.3[c]": [ + "IAC-06.1" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "3.5.3[d]": [ + "IAC-06.2" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "3.5.3[b]": [ + "IAC-06.3" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "3.5.5[a]": [ + "IAC-09" ], - "IA-06": [ - "IAC-11" + "3.5.5[b]": [ + "IAC-09" ], - "IA-11": [ - "IAC-14" + "3.1.5[a]": [ + "IAC-09.5" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "3.5.8[a]": [ + "IAC-10" ], - "AC-07": [ - "IAC-22" + "3.5.8[b]": [ + "IAC-10" ], - "AC-14": [ - "IAC-26" + "3.5.9": [ + "IAC-10" ], - "IR-04": [ - "IRO-02" + "3.5.7[a]": [ + "IAC-10.1" ], - "IR-08": [ - "IRO-04" + "3.5.7[b]": [ + "IAC-10.1" ], - "IR-02": [ - "IRO-05" + "3.5.7[c]": [ + "IAC-10.1" ], - "IR-05": [ - "IRO-09" + "3.5.7[d]": [ + "IAC-10.1" ], - "IR-07": [ - "IRO-11" + "3.5.10[a]": [ + "IAC-10.5" ], - "CA-05": [ - "IAO-05" + "3.5.10[b]": [ + "IAC-10.5" ], - "CA-06": [ - "IAO-07" + "3.5.11": [ + "IAC-11" ], - "MA-02": [ - "MNT-02" + "3.1.2[a]": [ + "IAC-15" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "3.1.2[b]": [ + "IAC-15" ], - "MA-05": [ - "MNT-06" + "3.5.6[a]": [ + "IAC-15.3" ], - "SR-11(02)": [ - "MNT-07" + "3.5.6[b]": [ + "IAC-15.3" ], - "AC-19": [ - "MDM-02" + "3.1.1[a]": [ + "IAC-20" ], - "SC-07": [ - "NET-03" + "3.1.1[b]": [ + "IAC-20" ], - "CA-03": [ - "NET-05" + "3.1.1[c]": [ + "IAC-20" ], - "CA-09": [ - "NET-05.2" + "3.1.1[d]": [ + "IAC-20" ], - "SC-20": [ - "NET-10" + "3.1.1[e]": [ + "IAC-20" ], - "SC-22": [ - "NET-10.1" + "3.1.1[f]": [ + "IAC-20" ], - "SC-21": [ - "NET-10.2" + "3.1.5[b]": [ + "IAC-21" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "3.1.5[c]": [ + "IAC-21" ], - "AC-17": [ - "NET-14" + "3.1.5[d]": [ + "IAC-21" ], - "PE-02": [ - "PES-02" + "3.1.6[a]": [ + "IAC-21.2" ], - "PE-03": [ - "PES-03" + "3.1.6[b]": [ + "IAC-21.2" ], - "PE-08": [ - "PES-03.3" + "3.1.7[a]": [ + "IAC-21.5" ], - "PE-06": [ - "PES-05" + "3.1.7[b]": [ + "IAC-21.5" ], - "PE-12": [ - "PES-07.4" + "3.1.7[c]": [ + "IAC-21.5" ], - "PE-15": [ - "PES-07.5" + "3.1.7[d]": [ + "IAC-21.5" ], - "PE-13": [ - "PES-08" + "3.1.8[a]": [ + "IAC-22" ], - "PE-14": [ - "PES-09" + "3.1.8[b]": [ + "IAC-22" ], - "PE-16": [ - "PES-10" + "3.1.10[a]": [ + "IAC-24" ], - "SA-02": [ - "PRM-03" + "3.1.10[b]": [ + "IAC-24" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "3.1.10[c]": [ + "IAC-24" ], - "RA-02": [ - "RSK-02" + "3.1.11[a]": [ + "IAC-25" ], - "RA-07": [ - "RSK-06.1" + "3.1.11[b]": [ + "IAC-25" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "3.6.1[a]": [ + "IRO-01", + "IRO-02" ], - "RA-03(01)": [ - "RSK-09.1" + "3.6.1[b]": [ + "IRO-01", + "IRO-02" ], - "CA-07(04)": [ - "RSK-11" + "3.6.1[c]": [ + "IRO-01", + "IRO-02" ], - "SC-39": [ - "SEA-04" + "3.6.1[d]": [ + "IRO-01", + "IRO-02" ], - "AC-08": [ - "SEA-18" + "3.6.1[e]": [ + "IRO-01", + "IRO-02" ], - "AT-02": [ - "SAT-02" + "3.6.1[f]": [ + "IRO-01", + "IRO-02" ], - "AT-03": [ - "SAT-03" + "3.6.1[g]": [ + "IRO-02" ], - "AT-04": [ - "SAT-04" + "3.6.2[a]": [ + "IRO-02" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "3.6.2[b]": [ + "IRO-02" ], - "SA-04(10)": [ - "TDA-02.2" + "3.6.2[c]": [ + "IRO-02" ], - "SR-11": [ - "TDA-11" + "3.6.2[d]": [ + "IRO-02" ], - "SR-11(01)": [ - "TDA-11.1" + "3.6.2[e]": [ + "IRO-02" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "3.6.2[f]": [ + "IRO-02" ], - "SR-02(01)": [ - "TPM-03" + "3.6.3": [ + "IRO-06" ], - "SR-05": [ - "TPM-03.1" + "3.12.4[a]": [ + "IAO-03" ], - "SR-03": [ - "TPM-03.3" + "3.12.4[b]": [ + "IAO-03" ], - "SA-09": [ - "TPM-04" + "3.12.4[c]": [ + "IAO-03" ], - "SR-08": [ - "TPM-05.1" + "3.12.4[d]": [ + "IAO-03" ], - "AT-02(02)": [ - "THR-05" + "3.12.4[e]": [ + "IAO-03" ], - "RA-05(11)": [ - "THR-06" + "3.12.4[f]": [ + "IAO-03" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "3.12.4[g]": [ + "IAO-03" ], - "RA-05(02)": [ - "VPM-06.1" - ] - }, - "general-nist-800-53-r5-2-mod": { - "CM-08(01)": [ - "AST-02.1" + "3.12.4[h]": [ + "IAO-03" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "3.12.2[a]": [ + "IAO-05" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "3.12.2[b]": [ + "IAO-05" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "3.12.2[c]": [ + "IAO-05" ], - "CP-02(01)": [ - "BCD-01.1" + "3.7.1": [ + "MNT-02" ], - "CP-02(08)": [ - "BCD-02" + "3.7.2[a]": [ + "MNT-04" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "3.7.2[b]": [ + "MNT-04" ], - "CP-04(01)": [ - "BCD-04.1" + "3.7.2[c]": [ + "MNT-04" ], - "CP-06": [ - "BCD-08" + "3.7.2[d]": [ + "MNT-04" ], - "CP-06(01)": [ - "BCD-08.1" + "3.7.4": [ + "MNT-04.2" ], - "CP-06(03)": [ - "BCD-08.2" + "3.7.5[a]": [ + "MNT-05" ], - "CP-07": [ - "BCD-09" + "3.7.5[b]": [ + "MNT-05" ], - "CP-07(01)": [ - "BCD-09.1" + "3.7.6": [ + "MNT-06" ], - "CP-07(02)": [ - "BCD-09.2" + "3.1.18[a]": [ + "MDM-02" ], - "CP-07(03)": [ - "BCD-09.3" + "3.1.18[b]": [ + "MDM-02" ], - "CP-08": [ - "BCD-10" + "3.1.18[c]": [ + "MDM-02" ], - "CP-08(02)": [ - "BCD-10" + "3.1.19[a]": [ + "MDM-03" ], - "CP-08(01)": [ - "BCD-10.1" + "3.1.19[b]": [ + "MDM-03" ], - "CP-09(01)": [ - "BCD-11.1" + "3.13.1[e]": [ + "NET-02.2", + "NET-03" ], - "CP-09(08)": [ - "BCD-11.4" + "3.13.1[g]": [ + "NET-02.2", + "NET-03" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "3.13.1[a]": [ + "NET-03" ], - "CP-10(02)": [ - "BCD-12.1" + "3.13.1[b]": [ + "NET-03" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "3.13.1[c]": [ + "NET-03" ], - "CM-03(02)": [ - "CHG-02.2", - "CHG-06" + "3.13.1[d]": [ + "NET-03" ], - "CM-03(04)": [ - "CHG-02.3" + "3.13.1[f]": [ + "NET-03" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "3.13.1[h]": [ + "NET-03" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "3.1.3[a]": [ + "NET-04" ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" + "3.1.3[b]": [ + "NET-04" ], - "CM-02(02)": [ - "CFG-02.2" + "3.1.3[d]": [ + "NET-04" ], - "CM-02(03)": [ - "CFG-02.3" + "3.1.3[e]": [ + "NET-04" ], - "CM-02(07)": [ - "CFG-02.5" + "3.13.6[a]": [ + "NET-04.1" ], - "CM-07(01)": [ - "CFG-03.1" + "3.13.6[b]": [ + "NET-04.1" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" + "3.13.5[a]": [ + "NET-06" ], - "CM-07(05)": [ - "CFG-03.3" + "3.13.5[b]": [ + "NET-06" ], - "SC-07(07)": [ - "CFG-03.4" + "3.13.9[a]": [ + "NET-07" ], - "SI-04(02)": [ - "MON-01.2" + "3.13.9[b]": [ + "NET-07" ], - "SI-04(04)": [ - "MON-01.3" + "3.13.9[c]": [ + "NET-07" ], - "SI-04(05)": [ - "MON-01.4" + "3.13.15": [ + "NET-09" ], - "AU-06(03)": [ - "MON-02.1" + "3.13.14[a]": [ + "NET-13" ], - "AU-03(01)": [ - "MON-03.1" + "3.13.14[b]": [ + "NET-13" ], - "AU-06(01)": [ - "MON-03.1" + "3.1.12[a]": [ + "NET-14.1" ], - "AU-07": [ - "MON-06" + "3.1.12[b]": [ + "NET-14.1" ], - "AU-07(01)": [ - "MON-06" + "3.1.12[c]": [ + "NET-14.1" ], - "AU-09(04)": [ - "MON-08.2" + "3.1.12[d]": [ + "NET-14.1" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "3.1.13[a]": [ + "NET-14.2" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "3.1.13[b]": [ + "NET-14.2" ], - "SC-28": [ - "CRY-05", - "END-02" + "3.1.14[a]": [ + "NET-14.3" ], - "SC-17": [ - "CRY-08" + "3.1.14[b]": [ + "NET-14.3" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "3.1.15[a]": [ + "NET-14.4" ], - "MP-04": [ - "DCH-06" + "3.1.15[b]": [ + "NET-14.4" ], - "MP-05": [ - "DCH-07" + "3.1.15[c]": [ + "NET-14.4" ], - "AC-20(01)": [ - "DCH-13.1" + "3.1.15[d]": [ + "NET-14.4" ], - "AC-20(02)": [ - "DCH-13.2" + "3.1.16[a]": [ + "NET-15" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "3.1.16[b]": [ + "NET-15" ], - "CM-12": [ - "DCH-24" + "3.1.17[a]": [ + "NET-15.1" ], - "CM-12(01)": [ - "DCH-24.1" + "3.1.17[b]": [ + "NET-15.1" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "3.10.2[a]": [ + "PES-01" ], - "SI-07(01)": [ - "END-06.1" + "3.10.2[b]": [ + "PES-01" ], - "SI-07(07)": [ - "END-06.2" + "3.10.2[c]": [ + "PES-01", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "SI-08": [ - "END-08" + "3.10.2[d]": [ + "PES-01", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "SI-08(02)": [ - "END-08.2" + "3.10.1[a]": [ + "PES-02" ], - "SC-18": [ - "END-10" + "3.10.1[b]": [ + "PES-02" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "3.10.1[c]": [ + "PES-02" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "3.10.1[d]": [ + "PES-02" ], - "IA-03": [ - "IAC-04" + "3.10.5[a]": [ + "PES-03" ], - "IA-05(02)": [ - "IAC-10.2" + "3.10.5[b]": [ + "PES-03" ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" + "3.10.5[c]": [ + "PES-03" ], - "AC-02(01)": [ - "IAC-15.1" + "3.10.4": [ + "PES-03.3" ], - "AC-02(02)": [ - "IAC-15.2" + "3.10.3[a]": [ + "PES-06", + "PES-06.1", + "PES-06.3" ], - "AC-02(03)": [ - "IAC-15.3" + "3.10.3[b]": [ + "PES-06", + "PES-06.1", + "PES-06.3" ], - "AC-02(04)": [ - "IAC-15.4" + "3.10.6[a]": [ + "PES-11" ], - "AC-06(07)": [ - "IAC-17" + "3.10.6[b]": [ + "PES-11" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "3.11.1[a]": [ + "RSK-04" ], - "AC-06(01)": [ - "IAC-21.1" + "3.11.1[b]": [ + "RSK-04" ], - "AC-06(02)": [ - "IAC-21.2" + "3.13.2[a]": [ + "SEA-01" ], - "AC-06(05)": [ - "IAC-21.3" + "3.13.2[c]": [ + "SEA-01" ], - "AC-06(09)": [ - "IAC-21.4" + "3.13.2[d]": [ + "SEA-01" ], - "AC-06(10)": [ - "IAC-21.5" + "3.13.2[f]": [ + "SEA-01" ], - "AC-02(05)": [ - "IAC-24" + "3.13.3[a]": [ + "SEA-03.2" ], - "AC-11": [ - "IAC-24" + "3.13.3[b]": [ + "SEA-03.2" ], - "AC-11(01)": [ - "IAC-24.1" + "3.13.3[c]": [ + "SEA-03.2" ], - "AC-12": [ - "IAC-25" + "3.13.4": [ + "SEA-05" ], - "IA-12": [ - "IAC-28" + "3.1.9[a]": [ + "SEA-18", + "SEA-18.1", + "SEA-18.2" ], - "IA-12(02)": [ - "IAC-28.2" + "3.1.9[b]": [ + "SEA-18", + "SEA-18.1", + "SEA-18.2" ], - "IA-12(03)": [ - "IAC-28.3" + "3.2.1[a]": [ + "SAT-02" ], - "IA-12(05)": [ - "IAC-28.5" + "3.2.1[b]": [ + "SAT-02" ], - "IR-04(01)": [ - "IRO-02.1" + "3.2.1[c]": [ + "SAT-02" ], - "IR-03": [ - "IRO-06" + "3.2.1[d]": [ + "SAT-02" ], - "IR-03(02)": [ - "IRO-06.1" + "3.13.2[b]": [ + "TDA-06" ], - "IR-06(01)": [ - "IRO-10.1" + "3.13.2[e]": [ + "TDA-06" ], - "IR-06(03)": [ - "IRO-10.4" + "3.2.3[a]": [ + "THR-05" ], - "IR-07(01)": [ - "IRO-11.1" + "3.2.3[b]": [ + "THR-05" ], - "CA-02(01)": [ - "IAO-02.1" + "3.14.1[a]": [ + "VPM-01" ], - "CM-04(02)": [ - "IAO-06" + "3.14.1[b]": [ + "VPM-01" ], - "MA-06": [ - "MNT-03" + "3.14.1[c]": [ + "VPM-01" ], - "MA-03": [ - "MNT-04" + "3.14.1[d]": [ + "VPM-01" ], - "MA-03(01)": [ - "MNT-04.1" + "3.14.1[e]": [ + "VPM-01" ], - "MA-03(02)": [ - "MNT-04.2" + "3.14.1[f]": [ + "VPM-01" ], - "MA-03(03)": [ - "MNT-04.3" + "3.11.3[a]": [ + "VPM-02" ], - "AC-19(05)": [ - "MDM-03" + "3.11.3[b]": [ + "VPM-02" ], - "SC-07(03)": [ - "NET-03.1" + "3.11.2[a]": [ + "VPM-06" ], - "SC-07(04)": [ - "NET-03.2" + "3.11.2[b]": [ + "VPM-06" ], - "AC-04": [ - "NET-04" + "3.11.2[c]": [ + "VPM-06" ], - "SC-07(05)": [ - "NET-04.1" + "3.11.2[d]": [ + "VPM-06" ], - "SC-10": [ - "NET-07" + "3.11.2[e]": [ + "VPM-06" + ] + }, + "general-nist-800-171a-r3": { + "A.03.15.01.a[01]": [ + "GOV-01", + "GOV-02" ], - "SC-23": [ - "NET-09" + "A.03.12.03[01]": [ + "GOV-01.1", + "GOV-01.2", + "GOV-05", + "CPL-02", + "CPL-03", + "MON-01", + "TDA-01", + "TDA-01.1", + "TDA-09", + "TDA-09.1" ], - "SI-10": [ - "NET-12", - "TDA-18" + "A.03.15.01.a[02]": [ + "GOV-02" ], - "AC-17(01)": [ - "NET-14.1" + "A.03.15.01.a[03]": [ + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "OPS-01", + "OPS-01.1" ], - "AC-17(02)": [ - "NET-14.2" + "A.03.15.01.a[04]": [ + "GOV-02", + "OPS-01.1", + "OPS-03" ], - "AC-17(03)": [ - "NET-14.3" + "A.03.15.01.ODP[01]": [ + "GOV-03" ], - "AC-17(04)": [ - "NET-14.4" + "A.03.15.01.b[01]": [ + "GOV-03" ], - "AC-18(01)": [ - "NET-15.1" + "A.03.15.01.b[02]": [ + "GOV-03" ], - "AC-18(03)": [ - "NET-15.2" + "A.03.15.03.d[01]": [ + "GOV-03", + "HRS-01", + "HRS-05.1" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "A.03.16.01": [ + "GOV-15", + "AST-17", + "PRM-01", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-01", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-03", + "TDA-05", + "TDA-06", + "TPM-01", + "TPM-10" ], - "PE-06(01)": [ - "PES-05.1" + "A.03.17.01.a[01]": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "RSK-01", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-05.7" + ], + "A.03.01.03[01]": [ + "AST-01", + "CFG-02", + "DCH-01.4", + "DCH-03", + "END-01", + "IAC-20", + "IAC-20.1" ], - "PE-09": [ - "PES-07" + "A.03.01.03[02]": [ + "AST-01", + "AST-01.1", + "AST-04", + "AST-04.3", + "AST-31", + "CFG-02", + "DCH-01.4", + "DCH-03", + "DCH-14.3", + "END-01", + "IAC-20", + "IAC-20.1", + "NET-04", + "NET-05", + "NET-05.2" ], - "PE-10": [ - "PES-07.2" + "A.03.01.18.a[01]": [ + "AST-01", + "AST-12", + "AST-13", + "AST-14", + "AST-16", + "HRS-05.1", + "HRS-05.3", + "HRS-05.5", + "HRS-06", + "MDM-01", + "MDM-06", + "MDM-07", + "SEA-01", + "SEA-02" ], - "PE-11": [ - "PES-07.3" + "A.03.04.11.a[02]": [ + "AST-01", + "AST-02", + "AST-02.8", + "AST-04", + "AST-04.1", + "AST-04.2", + "DCH-02", + "DCH-06.2", + "IAO-03" ], - "PE-13(01)": [ - "PES-08.1" + "A.03.07.04.a[01]": [ + "AST-01", + "MNT-01", + "MNT-04" ], - "PE-17": [ - "PES-11" + "A.03.04.08.c": [ + "AST-01.4", + "AST-02", + "CPL-03.2", + "CFG-03.1" ], - "PE-04": [ - "PES-12.1" + "A.03.04.08.a": [ + "AST-02", + "AST-02.9", + "CFG-02.9", + "CFG-03", + "CFG-03.3" ], - "PE-05": [ - "PES-12.2" + "A.03.04.10.ODP[01]": [ + "AST-02" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "A.03.04.10.a": [ + "AST-02", + "AST-02.1", + "AST-02.9" ], - "PL-08": [ - "SEA-02" + "A.03.04.10.b[01]": [ + "AST-02" ], - "SC-02": [ - "SEA-03.2" + "A.03.04.10.b[02]": [ + "AST-02", + "AST-02.1", + "AST-02.9" ], - "SC-04": [ - "SEA-05" + "A.03.04.10.c[01]": [ + "AST-02.1" ], - "SI-16": [ - "SEA-10" + "A.03.04.10.c[02]": [ + "AST-02.1" ], - "AT-02(03)": [ - "SAT-02.2" + "A.03.04.10.c[03]": [ + "AST-02.1" ], - "SA-04(09)": [ - "TDA-02.1" + "A.03.04.02.a[02]": [ + "AST-02.4", + "CFG-02" ], - "SA-15": [ - "TDA-06" + "A.03.04.06.a": [ + "AST-02.4", + "CFG-02", + "CFG-02.5", + "CFG-02.9", + "CFG-03" ], - "SA-15(03)": [ - "TDA-06.1" + "A.03.04.11.a[01]": [ + "AST-02.8", + "CPL-01", + "CPL-01.2", + "DCH-19", + "DCH-24" ], - "SA-11": [ - "TDA-09" + "A.03.04.11.a[03]": [ + "AST-02.8", + "IAO-03" ], - "SA-10": [ - "TDA-14" + "A.03.04.11.b[01]": [ + "AST-02.8", + "AST-04", + "AST-04.1", + "AST-04.2", + "CHG-02.2", + "CHG-03", + "CHG-05", + "DCH-06.2", + "DCH-19", + "IAO-03", + "IAO-05" ], - "SI-11": [ - "TDA-19" + "A.03.04.11.b[02]": [ + "AST-02.8", + "AST-04", + "AST-04.1", + "AST-04.2", + "CHG-02.2", + "CHG-03", + "CHG-05", + "DCH-06.2", + "DCH-19", + "IAO-03", + "IAO-05" ], - "SA-09(02)": [ - "TPM-04.2" + "A.03.09.02.a.03": [ + "AST-03", + "AST-03.1", + "AST-10", + "HRS-09", + "HRS-09.1" ], - "SR-06": [ - "TPM-08" + "A.03.07.04.a[02]": [ + "AST-05", + "MNT-01", + "MNT-02", + "MNT-03", + "MNT-03.1", + "MNT-04", + "MNT-09" ], - "SI-02(02)": [ - "VPM-05.2" + "A.03.07.04.c": [ + "AST-09", + "DCH-09", + "MNT-04.3" ], - "RA-05(05)": [ - "VPM-06.3" - ] - }, - "general-nist-800-53-r5-2-high": { - "CM-08(02)": [ - "AST-02.9" + "A.03.08.03": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21" ], - "CM-08(04)": [ - "AST-03.1" + "A.03.11.01.a": [ + "AST-17", + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-02.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-05", + "RSK-09", + "RSK-09.1", + "TPM-02", + "TPM-03", + "TPM-04.1" ], - "SR-09": [ - "AST-15" + "A.03.04.12.a": [ + "AST-24", + "CFG-02.5", + "CFG-02.9" ], - "SR-09(01)": [ - "AST-15" + "A.03.04.12.b": [ + "AST-24", + "AST-25", + "MDM-04" ], - "CP-06(02)": [ - "BCD-01.4" + "A.03.01.12.a[01]": [ + "AST-27", + "NET-14", + "NET-14.5" ], - "CP-02(05)": [ - "BCD-02.2" + "A.03.01.12.c[01]": [ + "AST-27", + "NET-14", + "NET-14.3" ], - "CP-03(01)": [ - "BCD-03.1" + "A.03.01.12.c[02]": [ + "AST-27", + "NET-14", + "NET-14.3" ], - "CP-04(02)": [ - "BCD-04.2" + "A.03.08.09.a": [ + "BCD-11", + "BCD-11.4" ], - "CP-07(04)": [ - "BCD-09.4" + "A.03.08.09.b": [ + "BCD-11.4" ], - "CP-08(03)": [ - "BCD-10.2" + "A.03.04.02.b[01]": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-04", + "CPL-03.2", + "CFG-02.2", + "CFG-02.9", + "CFG-06" ], - "CP-08(04)": [ - "BCD-10.3" + "A.03.04.03.a": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CFG-01", + "CFG-06" ], - "CP-09(03)": [ - "BCD-11.2" + "A.03.04.03.d[01]": [ + "CHG-01", + "CFG-02.2" ], - "CP-09(02)": [ - "BCD-11.5" + "A.03.04.03.d[02]": [ + "CHG-01", + "CFG-02.2" ], - "CP-09(05)": [ - "BCD-11.6" + "A.03.04.03.b[02]": [ + "CHG-02", + "CHG-02.1", + "CHG-02.2" ], - "CP-10(04)": [ - "BCD-12.4" + "A.03.04.03.c[01]": [ + "CHG-02", + "MNT-01", + "MNT-02" ], - "CP-02(02)": [ - "CAP-03" + "A.03.07.05.a[01]": [ + "CHG-02", + "CHG-02.1", + "IAC-01.2", + "IAC-05.2", + "MNT-02", + "MNT-05", + "MNT-05.5" ], - "CM-03(01)": [ + "A.03.04.05[05]": [ "CHG-02.1" ], - "CM-03(06)": [ - "CHG-02.5" + "A.03.04.03.c[02]": [ + "CHG-02.2" ], - "CM-05(01)": [ - "CHG-04.1" + "A.03.04.04.a": [ + "CHG-02.2", + "CHG-02.3", + "CHG-03" ], - "SI-07(15)": [ - "CHG-04.2" + "A.03.04.03.b[01]": [ + "CHG-03" ], - "SI-06": [ + "A.03.04.05[06]": [ + "CHG-04", + "CHG-04.4" + ], + "A.03.04.04.b": [ "CHG-06" ], - "CM-06(01)": [ - "CFG-02.2" + "A.03.12.01": [ + "CPL-01", + "CPL-02", + "CPL-02.1", + "CPL-03", + "IAO-01", + "IAO-01.1", + "IAO-02", + "TDA-01", + "TDA-09" ], - "CM-06(02)": [ - "CFG-02.8" + "A.03.12.02.a.01": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1" ], - "SI-04(14)": [ - "MON-01.5" + "A.03.12.02.a.02": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1", + "RSK-06", + "VPM-02", + "VPM-05" ], - "SI-04(12)": [ - "MON-01.12", - "MON-05.1" + "A.03.12.03[03]": [ + "CPL-02" ], - "SI-04(20)": [ - "MON-01.15" + "A.03.12.03[04]": [ + "CPL-02" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "A.03.12.01.ODP[01]": [ + "CPL-02.1" ], - "AU-06(05)": [ - "MON-02.3" + "A.03.12.03[02]": [ + "CPL-03.2" ], - "AU-06(06)": [ - "MON-02.4" + "A.03.04.01.a[02]": [ + "CFG-01", + "CFG-02" ], - "AU-12(01)": [ - "MON-02.7" + "A.03.01.01.h": [ + "CFG-02", + "HRS-05", + "HRS-05.3", + "IAC-25" ], - "AU-12(03)": [ - "MON-02.8" + "A.03.01.08.a": [ + "CFG-02", + "IAC-22" ], - "AU-05(02)": [ - "MON-05.1" + "A.03.01.08.b": [ + "CFG-02", + "IAC-22" ], - "AU-05(01)": [ - "MON-05.2" + "A.03.01.09": [ + "CFG-02", + "SEA-18", + "SEA-18.1", + "SEA-18.2" ], - "AU-09(02)": [ - "MON-08.1" + "A.03.01.10.a": [ + "CFG-02", + "IAC-24" ], - "AU-09(03)": [ - "MON-08.3" + "A.03.01.10.b": [ + "CFG-02", + "IAC-24" ], - "AU-10": [ - "MON-09" + "A.03.01.10.c": [ + "CFG-02", + "IAC-24.1" ], - "SI-04(22)": [ - "MON-11.2" + "A.03.01.11": [ + "CFG-02", + "IAC-25" ], - "AC-02(12)": [ - "MON-16" + "A.03.01.12.a[03]": [ + "CFG-02" ], - "SC-12(01)": [ - "CRY-09.3" + "A.03.01.16.a[03]": [ + "CFG-02", + "NET-15.3" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" + "A.03.01.16.c": [ + "CFG-02", + "NET-15.2", + "NET-15.3", + "SEA-01" ], - "MP-06(01)": [ - "DCH-09.1" + "A.03.01.18.a[02]": [ + "CFG-02", + "MDM-02" ], - "MP-06(02)": [ - "DCH-09.2" + "A.03.03.08.a[02]": [ + "CFG-02", + "IAC-21" ], - "CA-03(06)": [ - "DCH-14.2" + "A.03.04.01.a[01]": [ + "CFG-02", + "CFG-02.5", + "CFG-02.7", + "CFG-02.9" ], - "SI-07(02)": [ - "END-06.3" + "A.03.04.02.a[01]": [ + "CFG-02", + "CFG-02.5", + "CFG-02.9", + "CFG-03", + "CFG-06" ], - "SI-07(05)": [ - "END-06.4" + "A.03.04.06.ODP[01]": [ + "CFG-02" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "A.03.04.06.ODP[02]": [ + "CFG-02" ], - "PS-04(02)": [ - "HRS-09.4" + "A.03.04.06.ODP[03]": [ + "CFG-02" ], - "IA-02(05)": [ - "IAC-02.1" + "A.03.04.06.ODP[04]": [ + "CFG-02" ], - "IA-12(04)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" + "A.03.04.06.ODP[05]": [ + "CFG-02" ], - "AC-02(11)": [ - "IAC-15.8" + "A.03.04.06.b[01]": [ + "CFG-02", + "CFG-03" ], - "AC-06(03)": [ - "IAC-21.6" + "A.03.04.06.b[02]": [ + "CFG-02", + "CFG-03" ], - "AC-10": [ - "IAC-23" + "A.03.04.06.b[03]": [ + "CFG-02", + "CFG-03" ], - "IR-02(01)": [ - "IRO-05.1" + "A.03.04.06.b[04]": [ + "CFG-02", + "CFG-03" ], - "IR-02(02)": [ - "IRO-05.2" + "A.03.04.06.b[05]": [ + "CFG-02", + "CFG-03" ], - "IR-04(11)": [ - "IRO-07" + "A.03.04.06.d": [ + "CFG-02", + "CFG-02.5", + "CFG-03" ], - "IR-05(01)": [ - "IRO-09.1" + "A.03.05.04[01]": [ + "CFG-02", + "IAC-02.2" ], - "CA-02(02)": [ - "IAO-02.2" + "A.03.05.04[02]": [ + "CFG-02", + "IAC-02.2" ], - "MA-02(02)": [ - "MNT-02.1" + "A.03.05.07.c": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.11", + "IAC-15.1" ], - "MA-04(03)": [ - "MNT-05.6" + "A.03.05.07.d": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.6", + "IAC-10.11", + "IAC-15.1" ], - "MA-05(01)": [ - "MNT-06.1" + "A.03.05.07.e": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.1", + "IAC-10.8", + "IAC-15", + "IAC-15.1" ], - "SC-07(21)": [ - "NET-03.7" + "A.03.05.07.f": [ + "CFG-02", + "IAC-10", + "IAC-10.1", + "IAC-10.11", + "IAC-15.1" ], - "AC-04(04)": [ - "NET-04.3" + "A.03.05.12.d": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.1", + "IAC-10.8", + "IAC-15.1" ], - "AC-18(04)": [ - "NET-15.3" + "A.03.07.05.b[01]": [ + "CFG-02", + "IAC-06", + "MNT-05", + "MNT-05.3" ], - "AC-18(05)": [ - "NET-15.4" + "A.03.08.07.a": [ + "CFG-02", + "DCH-10", + "DCH-12" ], - "SI-04(10)": [ - "NET-18.2" + "A.03.13.12.b": [ + "CFG-02", + "END-14.6" ], - "PE-03(01)": [ - "PES-03.4" + "A.03.04.01.ODP[01]": [ + "CFG-02.1" ], - "PE-06(04)": [ - "PES-05.2" + "A.03.04.01.b[01]": [ + "CFG-02.1" ], - "PE-08(01)": [ - "PES-06.4" + "A.03.04.01.b[02]": [ + "CFG-02.1" ], - "PE-11(01)": [ - "PES-07.3" + "A.03.04.01.b[03]": [ + "CFG-02.1" ], - "PE-15(01)": [ - "PES-07.6" + "A.03.04.01.b[04]": [ + "CFG-02.1" ], - "PE-13(02)": [ - "PES-08.2", - "PES-08.3" + "A.03.04.06.c": [ + "CFG-02.1", + "CFG-03.1" ], - "PE-18": [ - "PES-12" + "A.03.13.13.b[02]": [ + "CFG-02.2" ], - "SC-07(18)": [ - "SEA-01" + "A.03.04.12.ODP[01]": [ + "CFG-02.5" ], - "SC-24": [ - "SEA-07.2" + "A.03.04.12.ODP[02]": [ + "CFG-02.5" ], - "SA-04(05)": [ - "TDA-02.4" + "A.03.04.02.b[02]": [ + "CFG-02.7" ], - "SA-17": [ - "TDA-05" + "A.03.03.02.b": [ + "CFG-02.9", + "MON-03" ], - "CM-04(01)": [ - "TDA-08" + "A.03.13.11": [ + "CFG-02.9", + "CRY-01", + "CRY-01.5", + "CRY-03", + "CRY-05" ], - "SA-21": [ - "TDA-13" + "A.03.04.02.ODP[01]": [ + "CFG-03" ], - "SA-16": [ - "TDA-16" + "A.03.04.06.ODP[06]": [ + "CFG-03.1" ], - "SI-05(01)": [ - "THR-03" + "A.03.04.08.b": [ + "CFG-03.2", + "CFG-03.3" ], - "RA-05(04)": [ - "VPM-06.8" + "A.03.04.08.ODP[01]": [ + "CFG-03.3" ], - "CA-08": [ - "VPM-07" + "A.03.13.13.a[01]": [ + "CFG-03.3", + "END-10" ], - "CA-08(01)": [ - "VPM-07.1" - ] - }, - "general-nist-800-66-r2": { - "164.316(a)": [ - "GOV-01", - "GOV-02" + "A.03.13.13.a[02]": [ + "CFG-03.3", + "CFG-04", + "CFG-04.1", + "CFG-05", + "END-10" ], - "164.308(a)(1)": [ - "GOV-02", - "GOV-09", - "GOV-15.2", - "CHG-01", - "CFG-01", - "MON-01", - "MON-01.8", - "HRS-07", - "IRO-01", - "IRO-09", - "RSK-04" + "A.03.13.13.b[01]": [ + "CFG-03.3", + "CFG-04", + "END-10" ], - "164.308(a)(3)": [ - "GOV-02", + "A.03.13.13.b[03]": [ + "CFG-03.3", + "CFG-04", + "CFG-04.1", + "CFG-05", + "END-10" + ], + "A.03.01.02[01]": [ "CFG-08", - "HRS-01", + "DCH-01.2", + "DCH-01.4", "HRS-02", - "HRS-03", - "HRS-08", - "HRS-09", - "IAC-01", - "IAC-07", - "IAC-07.1", - "IAC-07.2", + "HRS-02.1", "IAC-08", - "IAC-17", - "IAC-21", - "IAC-28.1" - ], - "164.308(a)(4)": [ - "GOV-02", - "IAC-01", - "IAC-08" - ], - "164.308(a)(6)": [ - "GOV-02", - "IRO-01", - "IRO-02" - ], - "164.308(a)(7)": [ - "GOV-02", - "AST-01", - "AST-01.1", - "BCD-01", - "BCD-02", - "BCD-02.2", - "BCD-04", - "BCD-05", - "BCD-11", - "BCD-12", - "IRO-01", - "TPM-02" - ], - "164.310(a)": [ - "GOV-02", - "BCD-09.2", - "HRS-03", - "IAC-01", - "MNT-01", - "MNT-02", - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-06" - ], - "164.310(b)": [ - "GOV-02", - "END-01", - "HRS-05", - "HRS-05.1", - "HRS-05.3", - "PES-03.4", - "PES-04", - "OPS-01.1", - "OPS-03" - ], - "164.310(d)": [ - "GOV-02", - "AST-01", - "AST-02", - "AST-02.1", - "AST-02.9", - "AST-03", - "AST-03.1", - "AST-09", - "AST-11", - "BCD-11", - "DCH-01", - "DCH-03", - "DCH-07", - "DCH-07.1", - "DCH-09", - "DCH-13.2", - "MNT-01", - "MNT-04.3" + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "164.312(a)": [ - "GOV-02", - "CFG-02", - "CRY-01", + "A.03.01.02[02]": [ + "CFG-08", + "DCH-01.2", + "DCH-01.4", "HRS-02", - "HRS-03", - "IAC-01", - "IAC-02", + "HRS-02.1", "IAC-08", - "IAC-09", "IAC-15", - "IAC-15.2", - "IAC-15.9", - "IAC-21", - "IAC-25" - ], - "164.312(c)": [ - "GOV-02", - "CFG-08", - "CFG-08.1", - "MON-01.7", - "MON-01.15", - "MON-16", - "DCH-01", - "DCH-01.2" - ], - "164.316(b)": [ - "GOV-02", - "GOV-03", - "CPL-02", - "CPL-03", - "DCH-18", - "OPS-01.1", - "OPS-03" - ], - "164.308(a)(2)": [ - "GOV-04" - ], - "164.314(a)": [ - "CPL-01", - "TPM-05", - "TPM-05.1", - "TPM-05.2" - ], - "164.308(a)(8)": [ - "CPL-03.2", - "IAO-01.1", - "IAO-02" - ], - "164.312(e)(1)": [ - "CFG-02", - "CRY-03", - "NET-01" + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "164.312(b)": [ + "A.03.03.01.a": [ "MON-01", "MON-01.4", - "MON-01.8", - "MON-01.16", + "MON-02.7", "MON-03", - "MON-03.2", - "MON-16" - ], - "164.310(c)": [ - "END-02", - "PES-03", - "PES-03.4", - "PES-04", - "PES-04.1" - ], - "164.312(d)": [ - "HRS-01", - "HRS-04", - "IAC-28", - "IAC-28.2", - "IAC-28.3", - "TPM-01" - ], - "164.308(a)(5)": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.2", - "SAT-03.6" - ], - "164.308(b)(1)": [ - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "MON-03.2" ], - "164.314(b)": [ - "TPM-05", - "TPM-05.1" - ] - }, - "general-nist-800-82-r3": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "A.03.14.06.a.01[01]": [ + "MON-01", + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "A.03.14.06.a.01[02]": [ + "MON-01", + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "A.03.14.06.a.02": [ + "MON-01", + "MON-11.3", + "MON-16" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "A.03.13.01.a[01]": [ + "MON-01.1", + "MON-01.3" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "A.03.13.01.a[03]": [ + "MON-01.3" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "A.03.14.06.b": [ + "MON-01.3", + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "A.03.14.06.c[01]": [ + "MON-01.3", + "NET-08" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "A.03.03.03.a": [ + "MON-01.4" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "A.03.03.01.ODP[02]": [ + "MON-01.8" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "A.03.03.05.ODP[01]": [ + "MON-01.8", + "MON-02" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "A.03.03.05.a": [ + "MON-01.8", + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-16" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "A.03.03.05.b": [ + "MON-01.12", + "MON-06" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "A.03.01.07.b": [ + "MON-01.15", + "MON-03.3", + "IAC-09.5", + "IAC-16", + "IAC-21.4" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "A.03.03.05.c[01]": [ + "MON-02", + "MON-02.2" ], - "PT-01": [ - "GOV-02", - "GOV-03", - "PRI-01", - "SEA-01" + "A.03.03.05.c[02]": [ + "MON-02.1", + "MON-02.3" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "A.03.03.01.b[01]": [ + "MON-02.6", + "MON-03.6" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "A.03.03.01.ODP[01]": [ + "MON-03" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "A.03.03.02.a.01": [ + "MON-03" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "A.03.03.02.a.02": [ + "MON-03", + "MON-07" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "A.03.03.02.a.03": [ + "MON-03" ], - "PL-09": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "A.03.03.02.a.04": [ + "MON-03" ], - "PM-02": [ - "GOV-04" + "A.03.03.02.a.05": [ + "MON-03" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "A.03.03.02.a.06": [ + "MON-03" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "A.03.03.01.b[02]": [ + "MON-03.6" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "A.03.03.04.ODP[01]": [ + "MON-05" ], - "PM-15": [ - "GOV-07", - "THR-01" + "A.03.03.04.ODP[02]": [ + "MON-05" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "A.03.03.04.a": [ + "MON-05" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "A.03.03.04.b": [ + "MON-05", + "IRO-02" ], - "PM-32": [ - "GOV-11" + "A.03.03.06.a[01]": [ + "MON-06" ], - "PM-05": [ - "AST-01", - "AST-02" + "A.03.03.06.a[02]": [ + "MON-06" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "A.03.03.06.a[03]": [ + "MON-06" ], - "CM-08(01)": [ - "AST-02.1" + "A.03.03.06.a[04]": [ + "MON-06" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "A.03.03.07.ODP[01]": [ + "MON-07" ], - "CM-08(06)": [ - "AST-02.4" + "A.03.03.07.a": [ + "MON-07" ], - "IA-03(03)": [ - "AST-02.5" + "A.03.03.07.b[01]": [ + "MON-07" ], - "SC-07(19)": [ - "AST-02.5" + "A.03.03.07.b[02]": [ + "MON-07.1" ], - "SC-18(02)": [ - "AST-02.7", - "END-10" + "A.03.03.03.b": [ + "MON-08", + "MON-10" ], - "CM-13": [ - "AST-02.8" + "A.03.03.06.b[01]": [ + "MON-08" ], - "CM-08(02)": [ - "AST-02.9" + "A.03.03.06.b[02]": [ + "MON-08" ], - "CM-08(07)": [ - "AST-02.9" + "A.03.03.08.a[01]": [ + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-08.3" ], - "CM-08(08)": [ - "AST-02.10" + "A.03.03.08.b": [ + "MON-08", + "MON-08.2", + "IAC-08", + "IAC-21" ], - "CM-08(09)": [ - "AST-02.11" + "A.03.01.22.b[01]": [ + "MON-11", + "DCH-15" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "A.03.01.01.e": [ + "MON-16", + "IAC-15", + "IAC-15.7" ], - "CM-08(04)": [ - "AST-03.1" + "A.03.13.08[01]": [ + "CRY-01", + "CRY-03" ], - "SR-04": [ - "AST-03.2" + "A.03.13.08[02]": [ + "CRY-01", + "CRY-01.1", + "CRY-05", + "CRY-05.1" ], - "SR-04(01)": [ - "AST-03.2" + "A.03.13.11.ODP[01]": [ + "CRY-01", + "CRY-03", + "CRY-05" ], - "SR-04(02)": [ - "AST-03.2" + "A.03.01.16.a[02]": [ + "CRY-07", + "NET-01", + "NET-02.2", + "NET-15", + "SEA-01", + "SEA-02" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "A.03.13.10[01]": [ + "CRY-08", + "CRY-09" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "A.03.13.10.ODP[01]": [ + "CRY-09" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "A.03.13.10[02]": [ + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "PE-22": [ - "AST-04.1", - "PES-16" + "A.03.01.01.d.01": [ + "DCH-01", + "DCH-01.2", + "HRS-02", + "IAC-01.2", + "IAC-15", + "IAC-15.1", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "A.03.01.01.d.02": [ + "DCH-01", + "DCH-01.2", + "HRS-02", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "SR-12": [ - "AST-09" + "A.03.08.01[01]": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-03", + "DCH-06", + "DCH-06.1", + "DCH-06.4", + "PES-01", + "PES-02", + "PES-02.1", + "PES-04", + "PES-04.1" ], - "SC-43": [ - "AST-14" + "A.03.08.01[02]": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-03", + "DCH-06", + "DCH-06.1", + "DCH-06.4", + "PES-01", + "PES-02", + "PES-02.1", + "PES-04", + "PES-04.1" ], - "SR-09": [ - "AST-15" + "A.03.08.05.a[01]": [ + "DCH-01.1", + "DCH-07" ], - "SR-09(01)": [ - "AST-15" + "A.03.01.20.a": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.2", + "DCH-13.4", + "DCH-17", + "TPM-01", + "TPM-05.8" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "A.03.01.20.b": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.3", + "DCH-14", + "DCH-14.2", + "TPM-01", + "TPM-05", + "TPM-05.8" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "A.03.01.20.c.01": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.3", + "DCH-13.4", + "TPM-01", + "TPM-05", + "TPM-05.6", + "TPM-05.8" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "A.03.01.20.d": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.2", + "DCH-13.4", + "MDM-01", + "MDM-07" ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" + "A.03.06.05.d": [ + "DCH-01.2", + "HRS-03", + "IAC-08", + "IAC-20.1", + "IRO-04" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "A.03.08.02": [ + "DCH-01.2", + "DCH-01.4", + "DCH-03", + "HRS-03", + "PES-01", + "PES-02", + "PES-02.1", + "PES-04", + "PES-04.1" ], - "CP-02(01)": [ - "BCD-01.1" + "A.03.08.05.a[02]": [ + "DCH-01.2", + "DCH-07", + "DCH-07.1", + "DCH-07.2" ], - "CP-02(07)": [ - "BCD-01.2" + "A.03.17.01.c": [ + "DCH-01.2", + "DCH-01.4", + "DCH-03.1" ], - "CP-02(06)": [ - "BCD-01.3" + "A.03.08.05.c": [ + "DCH-01.3", + "DCH-07" ], - "CP-06(02)": [ - "BCD-01.4" + "A.03.01.04.a": [ + "DCH-01.4", + "HRS-11", + "HRS-12", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CP-02(08)": [ - "BCD-02" + "A.03.10.01.a[01]": [ + "DCH-01.4", + "IAC-20.1", + "PES-01", + "PES-02" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "A.03.10.01.a[02]": [ + "DCH-01.4", + "IAC-20.1", + "PES-01", + "PES-02", + "PES-06", + "PES-06.1" ], - "CP-02(05)": [ - "BCD-02.2" + "A.03.10.01.a[03]": [ + "DCH-01.4", + "IAC-20.1", + "PES-01", + "PES-02" ], - "CP-03": [ - "BCD-03" + "A.03.15.02.c": [ + "DCH-01.4", + "DCH-03.1" ], - "CP-03(01)": [ - "BCD-03.1" + "A.03.08.04[01]": [ + "DCH-02", + "DCH-04" ], - "CP-03(02)": [ - "BCD-03.2" + "A.03.01.22.a": [ + "DCH-03.1", + "DCH-15", + "HRS-03", + "HRS-03.1", + "HRS-04.1", + "HRS-04.2", + "HRS-05", + "HRS-05.1", + "SAT-02", + "SAT-03", + "SAT-03.3", + "WEB-01" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "A.03.08.04[02]": [ + "DCH-04" ], - "CP-04(01)": [ - "BCD-04.1" + "A.03.08.04[03]": [ + "DCH-04" ], - "CP-04(02)": [ - "BCD-04.2" + "A.03.08.05.b": [ + "DCH-07", + "DCH-07.1" ], - "CP-13": [ - "BCD-07" + "A.03.08.07.ODP[01]": [ + "DCH-10" ], - "CP-06": [ - "BCD-08" + "A.03.08.07.b": [ + "DCH-10.2" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "A.03.01.20.ODP[01]": [ + "DCH-13" ], - "CP-06(01)": [ - "BCD-08.1" + "A.03.01.20.c.02": [ + "DCH-13", + "DCH-13.1", + "DCH-14.2", + "DCH-14.3", + "DCH-18", + "NET-05", + "TPM-05" ], - "CP-06(03)": [ - "BCD-08.2" + "A.03.12.05.a[01]": [ + "DCH-14.2", + "DCH-14.3", + "HRS-06", + "HRS-06.1", + "NET-05" ], - "CP-07": [ - "BCD-09" + "A.03.10.07.b": [ + "DCH-18", + "PES-03.3" ], - "CP-07(01)": [ - "BCD-09.1" + "A.03.14.08[01]": [ + "DCH-18" ], - "CP-07(02)": [ - "BCD-09.2" + "A.03.14.08[02]": [ + "DCH-18" ], - "CP-07(03)": [ - "BCD-09.3" + "A.03.14.08[03]": [ + "DCH-18" ], - "CP-07(04)": [ - "BCD-09.4" + "A.03.14.08[04]": [ + "DCH-18" ], - "CP-07(06)": [ - "BCD-09.5" + "A.03.14.02.a[01]": [ + "END-01", + "END-04", + "END-04.3", + "END-04.7" ], - "CP-08": [ - "BCD-10" + "A.03.14.02.ODP[01]": [ + "END-04" ], - "CP-08(02)": [ - "BCD-10" + "A.03.14.02.a[02]": [ + "END-04" ], - "CP-11": [ - "BCD-10" + "A.03.14.02.c.01[01]": [ + "END-04", + "END-04.7" ], - "CP-08(01)": [ - "BCD-10.1" + "A.03.14.02.c.02": [ + "END-04" ], - "CP-08(03)": [ - "BCD-10.2" + "A.03.14.02.b": [ + "END-04.1" ], - "CP-08(04)": [ - "BCD-10.3" + "A.03.14.02.c.01[02]": [ + "END-04.7" ], - "SC-47": [ - "BCD-10.4" + "A.03.13.12.ODP[01]": [ + "END-14" ], - "CP-09": [ - "BCD-11" + "A.03.13.12.a": [ + "END-14" ], - "SC-28(02)": [ - "BCD-11", - "CRY-05.2" + "A.03.01.01.ODP[01]": [ + "HRS-01", + "IAC-15" ], - "CP-09(01)": [ - "BCD-11.1" + "A.03.01.01.ODP[02]": [ + "HRS-01" ], - "CP-09(03)": [ - "BCD-11.2" + "A.03.01.01.ODP[03]": [ + "HRS-01" ], - "CP-09(08)": [ - "BCD-11.4" + "A.03.01.01.ODP[04]": [ + "HRS-01" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "A.03.01.01.g.02": [ + "HRS-01", + "HRS-08", + "HRS-09", + "HRS-09.4", + "IAC-07", + "IAC-07.1", + "IAC-15" ], - "CP-09(02)": [ - "BCD-11.5" + "A.03.15.03.a": [ + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "HRS-05.3", + "HRS-05.4", + "HRS-05.5" ], - "CP-09(05)": [ - "BCD-11.6" + "A.03.01.01.c.01": [ + "HRS-02", + "IAC-08", + "IAC-15", + "IAC-15.5" ], - "CP-09(06)": [ - "BCD-11.7" + "A.03.01.01.c.02": [ + "HRS-02", + "IAC-08", + "IAC-15" ], - "CP-09(07)": [ - "BCD-11.8" + "A.03.09.01.a": [ + "HRS-02", + "HRS-04", + "HRS-04.1" ], - "CP-10(02)": [ - "BCD-12.1" + "A.03.09.01.b": [ + "HRS-02", + "HRS-04", + "HRS-04.1" ], - "SI-13": [ - "BCD-12.2", - "SEA-07" + "A.03.15.03.b": [ + "HRS-02", + "HRS-03", + "HRS-03.1", + "HRS-04.2", + "HRS-05" ], - "CP-10(04)": [ - "BCD-12.4" + "A.03.02.02.a.01[01]": [ + "HRS-03", + "HRS-04.1", + "HRS-04.2", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" ], - "CP-10(06)": [ - "BCD-13" + "A.03.06.04.ODP[01]": [ + "HRS-03", + "HRS-04.2", + "SAT-03" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "A.03.07.06.a": [ + "HRS-03", + "IAC-08", + "MNT-01", + "MNT-06", + "TPM-01", + "TPM-05" ], - "SC-05(03)": [ - "CAP-01" + "A.03.07.06.d[02]": [ + "HRS-03", + "MNT-06.1" ], - "SC-05(01)": [ - "CAP-02" + "A.03.16.03.b": [ + "HRS-03", + "HRS-10", + "TPM-05", + "TPM-05.2", + "TPM-05.4" ], - "SC-05(02)": [ - "CAP-02", - "CAP-03" + "A.03.07.06.d[01]": [ + "HRS-03.2", + "MNT-06", + "MNT-06.1" ], - "SC-06": [ - "CAP-02" + "A.03.09.01.ODP[01]": [ + "HRS-04", + "HRS-04.1" ], - "CP-02(02)": [ - "CAP-03" + "A.03.09.02.b.01[01]": [ + "HRS-04", + "HRS-08", + "HRS-09", + "HRS-09.2" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "A.03.06.04.a.01": [ + "HRS-04.2", + "IRO-05", + "SAT-03" ], - "SA-08(31)": [ - "CHG-02", - "CHG-02.2", - "CHG-06" + "A.03.15.03.ODP[01]": [ + "HRS-05.1" ], - "CM-03(01)": [ - "CHG-02.1" + "A.03.15.03.d[02]": [ + "HRS-05.1", + "HRS-05.7" ], - "CM-03(02)": [ - "CHG-02.2", - "CHG-06" + "A.03.15.03.c": [ + "HRS-05.7", + "HRS-06", + "HRS-06.1" ], - "CM-03(07)": [ - "CHG-02.2" + "A.03.01.01.f.04": [ + "HRS-07", + "HRS-07.1", + "IAC-15", + "IAC-15.6" ], - "CM-03(04)": [ - "CHG-02.3" + "A.03.01.01.f.05": [ + "HRS-07", + "HRS-07.1", + "IAC-15", + "IAC-15.6" ], - "CM-03(05)": [ - "CHG-02.4" + "A.03.09.02.ODP[01]": [ + "HRS-08", + "HRS-09" ], - "CM-03(06)": [ - "CHG-02.5" + "A.03.09.02.a.01": [ + "HRS-08", + "HRS-09", + "HRS-09.2", + "HRS-09.4", + "IAC-07", + "IAC-07.2" ], - "CM-04": [ - "CHG-03" + "A.03.09.02.b.01[02]": [ + "HRS-08", + "IAC-07.1", + "IAC-20" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "A.03.09.02.b.02": [ + "HRS-08", + "IAC-07.1", + "IAC-20" ], - "CM-05(01)": [ - "CHG-04.1" + "A.03.01.01.f.03": [ + "HRS-09", + "IAC-15" ], - "CM-14": [ - "CHG-04.2" + "A.03.09.02.a.02[01]": [ + "HRS-09", + "HRS-09.2", + "HRS-09.4", + "IAC-07", + "IAC-07.2" ], - "SI-07(15)": [ - "CHG-04.2" + "A.03.09.02.a.02[02]": [ + "HRS-09", + "HRS-09.2", + "HRS-09.4", + "IAC-07", + "IAC-07.2" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "A.03.01.01.a[01]": [ + "IAC-01", + "IAC-15" ], - "CM-05(04)": [ - "CHG-04.3" + "A.03.01.01.a[02]": [ + "IAC-01", + "IAC-15" ], - "CM-05(05)": [ - "CHG-04.4" + "A.03.01.18.b": [ + "IAC-01", + "IAC-04", + "MDM-02", + "MDM-06", + "MDM-07", + "MDM-11" ], - "CM-05(06)": [ - "CHG-04.5" + "A.03.05.01.a[01]": [ + "IAC-01", + "IAC-01.2" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "A.03.05.05.a": [ + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-28.1" ], - "SI-06": [ - "CHG-06" + "A.03.05.12.e": [ + "IAC-01", + "IAC-10", + "IAC-10.1", + "IAC-15.1" ], - "SI-06(03)": [ - "CHG-06.1" + "A.03.01.16.b": [ + "IAC-01.2", + "NET-02.2", + "NET-15", + "NET-15.1" ], - "SC-07(29)": [ - "CLD-03", - "NET-03.8", - "NET-06.1" + "A.03.05.01.a[02]": [ + "IAC-01.2" ], - "SA-09(05)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "A.03.05.02[01]": [ + "IAC-01.2", + "IAC-04", + "IAC-05" ], - "SA-09(08)": [ - "CLD-09", - "DCH-19" + "A.03.05.02[02]": [ + "IAC-01.2", + "IAC-04", + "IAC-05" ], - "CA-07": [ - "CPL-02" + "A.03.05.05.d": [ + "IAC-01.2", + "IAC-02", + "IAC-09", + "IAC-09.2", + "IAC-09.5", + "IAC-15.1" ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" + "A.03.05.07.a[01]": [ + "IAC-01.2", + "IAC-10", + "IAC-10.4", + "IAC-10.11" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "A.03.05.07.b": [ + "IAC-01.2", + "IAC-10", + "IAC-10.4", + "IAC-10.11" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "A.03.05.01.a[03]": [ + "IAC-02", + "IAC-03", + "IAC-05" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "A.03.07.05.b[02]": [ + "IAC-02.2" ], - "CM-09(01)": [ - "CFG-01.1" + "A.03.05.02.ODP[01]": [ + "IAC-04" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "A.03.05.03[01]": [ + "IAC-06", + "IAC-06.1", + "IAC-06.3", + "IAC-06.4" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "A.03.05.03[02]": [ + "IAC-06", + "IAC-06.2", + "IAC-06.4" ], - "PL-10": [ - "CFG-02" + "A.03.01.01.b[01]": [ + "IAC-07", + "IAC-15" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "A.03.01.01.b[02]": [ + "IAC-07", + "IAC-15", + "IAC-28.1" ], - "SA-15(05)": [ - "CFG-02", - "SEA-01" + "A.03.01.01.b[03]": [ + "IAC-07", + "IAC-15" ], - "CM-02(02)": [ - "CFG-02.2" + "A.03.01.01.b[04]": [ + "IAC-07", + "IAC-15.7" ], - "CM-06(01)": [ - "CFG-02.2" + "A.03.01.01.b[05]": [ + "IAC-07", + "IAC-15.7" ], - "CM-02(03)": [ - "CFG-02.3" + "A.03.01.01.g.01": [ + "IAC-07", + "IAC-07.1", + "IAC-15" ], - "CM-02(06)": [ - "CFG-02.4" + "A.03.01.01.g.03": [ + "IAC-07", + "IAC-07.1", + "IAC-15", + "IAC-17" ], - "CM-02(07)": [ - "CFG-02.5" + "A.03.01.01.c.03": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CM-07(06)": [ - "CFG-02.5" + "A.03.01.05.ODP[01]": [ + "IAC-08" ], - "CM-07(07)": [ - "CFG-02.5" + "A.03.01.05.ODP[02]": [ + "IAC-08" ], - "CM-07(09)": [ - "CFG-02.5" + "A.03.01.05.b[01]": [ + "IAC-08", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CM-06(02)": [ - "CFG-02.8" + "A.03.01.05.b[02]": [ + "IAC-08", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "PL-11": [ - "CFG-02.9" + "A.03.01.06.a": [ + "IAC-08", + "IAC-16", + "IAC-20", + "IAC-21", + "IAC-21.3" ], - "CM-07": [ - "CFG-03" + "A.03.01.12.a[02]": [ + "IAC-08", + "NET-14" ], - "CM-07(01)": [ - "CFG-03.1" + "A.03.04.05[04]": [ + "IAC-08", + "IAC-21" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" + "A.03.05.05.ODP[01]": [ + "IAC-09" ], - "CM-07(04)": [ - "CFG-03.3" + "A.03.05.05.b[01]": [ + "IAC-09", + "IAC-09.1", + "IAC-15.1" ], - "CM-07(05)": [ - "CFG-03.3" + "A.03.05.05.b[02]": [ + "IAC-09", + "IAC-09.1", + "IAC-15.1" ], - "SC-18(04)": [ - "CFG-03.3", - "END-10" + "A.03.05.05.c": [ + "IAC-09", + "IAC-15.1" ], - "SC-07(07)": [ - "CFG-03.4" + "A.03.05.05.ODP[02]": [ + "IAC-09.2" ], - "CM-10": [ - "CFG-04" + "A.03.05.12.ODP[01]": [ + "IAC-10" ], - "CM-10(01)": [ - "CFG-04.1" + "A.03.05.12.ODP[02]": [ + "IAC-10" ], - "CM-11": [ - "CFG-05", - "END-03" + "A.03.05.12.a": [ + "IAC-10", + "IAC-10.3", + "IAC-28" ], - "CM-11(02)": [ - "CFG-05", - "CFG-05.2", - "END-03" + "A.03.05.12.b": [ + "IAC-10", + "IAC-10.1" ], - "CM-11(03)": [ - "CFG-05.1", - "CFG-06", - "CFG-06.1", - "END-03.1" + "A.03.05.12.c[01]": [ + "IAC-10" ], - "CM-03(08)": [ - "CFG-06", - "CFG-06.1" + "A.03.05.12.c[02]": [ + "IAC-10" ], - "AC-03(11)": [ - "CFG-08" + "A.03.05.12.c[03]": [ + "IAC-10" ], - "PM-31": [ - "MON-01" + "A.03.05.12.c[04]": [ + "IAC-10" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "A.03.05.12.c[05]": [ + "IAC-10" ], - "SI-04(01)": [ - "MON-01.1" + "A.03.05.12.c[06]": [ + "IAC-10" ], - "SI-04(25)": [ - "MON-01.1", - "NET-03.1" + "A.03.05.12.f[01]": [ + "IAC-10", + "IAC-10.5", + "IAC-15.1" ], - "SC-48": [ - "MON-01.2", - "THR-07" + "A.03.05.12.f[02]": [ + "IAC-10", + "IAC-10.5", + "IAC-15.1" ], - "SI-04(02)": [ - "MON-01.2" + "A.03.05.07.ODP[02]": [ + "IAC-10.1" ], - "SI-04(04)": [ - "MON-01.3" + "A.03.05.07.ODP[01]": [ + "IAC-10.4", + "IAC-10.11" ], - "SI-04(05)": [ - "MON-01.4" + "A.03.05.07.a[02]": [ + "IAC-10.4", + "IAC-10.11" ], - "SI-04(14)": [ - "MON-01.5" + "A.03.05.07.a[03]": [ + "IAC-10.4", + "IAC-10.11" ], - "SI-04(23)": [ - "MON-01.6" + "A.03.05.11": [ + "IAC-11" ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" + "A.03.05.01.ODP[01]": [ + "IAC-14" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "A.03.05.01.b": [ + "IAC-14" ], - "IR-04(05)": [ - "MON-01.11", - "IRO-02.6" + "A.03.01.01.f.01": [ + "IAC-15" ], - "SI-04(07)": [ - "MON-01.11", - "IRO-02.1" + "A.03.01.01.f.02": [ + "IAC-15", + "IAC-15.3" ], - "SI-04(12)": [ - "MON-01.12", - "MON-05.1" + "A.03.01.05.c": [ + "IAC-15", + "IAC-15.7", + "IAC-17" ], - "SI-04(13)": [ - "MON-01.13" + "A.03.01.05.d": [ + "IAC-15", + "IAC-17" ], - "SI-04(19)": [ - "MON-01.14" + "A.03.01.07.a": [ + "IAC-16", + "IAC-21", + "IAC-21.3", + "IAC-21.5" ], - "SI-04(20)": [ - "MON-01.15" + "A.03.01.05.ODP[03]": [ + "IAC-17" ], - "AU-14(03)": [ - "MON-01.17" + "A.03.10.01.c": [ + "IAC-17", + "PES-02" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "A.03.10.01.d": [ + "IAC-17", + "PES-02", + "PES-02.1" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "A.03.01.05.a": [ + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "AU-06(03)": [ - "MON-02.1" + "A.03.01.06.b": [ + "IAC-21.2" ], - "AU-06(09)": [ - "MON-02.1" + "A.03.01.06.ODP[01]": [ + "IAC-21.3" ], - "SI-04(16)": [ - "MON-02.1" + "A.03.01.08.ODP[01]": [ + "IAC-22" ], - "AU-06(04)": [ - "MON-02.2" + "A.03.01.08.ODP[02]": [ + "IAC-22" ], - "AU-06(05)": [ - "MON-02.3" + "A.03.01.08.ODP[03]": [ + "IAC-22" ], - "SI-04(17)": [ - "MON-02.3" + "A.03.01.08.ODP[04]": [ + "IAC-22" ], - "AU-06(06)": [ - "MON-02.4" + "A.03.01.10.ODP[01]": [ + "IAC-24" ], - "AU-06(07)": [ - "MON-02.5" + "A.03.01.10.ODP[02]": [ + "IAC-24" ], - "AU-12(01)": [ - "MON-02.7" + "A.03.01.01.ODP[05]": [ + "IAC-25" ], - "AU-12(03)": [ - "MON-02.8" + "A.03.01.01.ODP[06]": [ + "IAC-25" ], - "AU-03": [ - "MON-03" + "A.03.01.11.ODP[01]": [ + "IAC-25" ], - "AU-03(01)": [ - "MON-03.1" + "A.03.07.05.c[01]": [ + "IAC-25", + "MNT-05", + "MNT-05.4" ], - "AU-06(01)": [ - "MON-03.1" + "A.03.06.01[01]": [ + "IRO-01", + "IRO-04", + "IRO-12" ], - "AU-06(08)": [ - "MON-03.3" + "A.03.06.01[02]": [ + "IRO-02" ], - "AU-03(03)": [ - "MON-03.5" + "A.03.06.01[03]": [ + "IRO-02" ], - "AU-04": [ - "MON-04" + "A.03.06.01[04]": [ + "IRO-02" ], - "AU-05": [ - "MON-05" + "A.03.06.01[05]": [ + "IRO-02" ], - "AU-05(02)": [ - "MON-05.1" + "A.03.06.01[06]": [ + "IRO-02" ], - "AU-05(01)": [ - "MON-05.2" + "A.03.06.02.a[01]": [ + "IRO-02", + "IRO-09" ], - "AU-07": [ - "MON-06" + "A.03.06.02.a[02]": [ + "IRO-02", + "IRO-09" ], - "AU-07(01)": [ - "MON-06" + "A.03.06.02.b": [ + "IRO-02", + "IRO-07", + "IRO-09", + "IRO-10", + "IRO-10.2" ], - "AU-12": [ - "MON-06" + "A.03.06.02.c": [ + "IRO-02", + "IRO-10" ], - "AU-12(04)": [ - "MON-06.1" + "A.03.06.02.d": [ + "IRO-02", + "IRO-07", + "IRO-10", + "IRO-11" ], - "CA-07(03)": [ - "MON-06.2" + "A.03.06.05.b[01]": [ + "IRO-02", + "IRO-04" ], - "AU-08": [ - "MON-07", - "SEA-20" + "A.03.06.02.ODP[01]": [ + "IRO-04", + "IRO-10" ], - "SC-45": [ - "MON-07.1" + "A.03.06.02.ODP[02]": [ + "IRO-04", + "IRO-10.2", + "IRO-14" ], - "SC-45(01)": [ - "MON-07.1" + "A.03.06.05.a.01": [ + "IRO-04" ], - "AU-09": [ - "MON-08" + "A.03.06.05.a.02": [ + "IRO-04" ], - "AU-04(01)": [ - "MON-08.1" + "A.03.06.05.a.03": [ + "IRO-04" ], - "AU-09(02)": [ - "MON-08.1" + "A.03.06.05.a.04": [ + "IRO-04" ], - "AU-09(04)": [ - "MON-08.2" + "A.03.06.05.a.05": [ + "IRO-04" ], - "AU-09(03)": [ - "MON-08.3" + "A.03.06.05.a.06": [ + "IRO-04" ], - "AU-09(05)": [ - "MON-08.4" + "A.03.06.05.b[02]": [ + "IRO-04" ], - "AU-10": [ - "MON-09" + "A.03.06.05.c": [ + "IRO-04.2" ], - "AU-10(01)": [ - "MON-09.1" + "A.03.06.04.b[03]": [ + "IRO-04.3", + "IRO-13", + "SAT-01.1" ], - "AU-10(02)": [ - "MON-09.1" + "A.03.06.04.a.03": [ + "IRO-05", + "SAT-02", + "SAT-03" ], - "AU-11": [ - "MON-10" + "A.03.06.03.ODP[01]": [ + "IRO-06" ], - "AU-13": [ - "MON-11" + "A.03.06.03": [ + "IRO-06" ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" + "A.03.01.22.b[02]": [ + "IRO-12", + "WEB-14" ], - "SI-04(22)": [ - "MON-11.2" + "A.03.06.04.b[04]": [ + "IRO-13", + "SAT-01.1" ], - "AU-14": [ - "MON-12" + "A.03.01.16.a[01]": [ + "IAO-03", + "NET-02.2", + "NET-15" ], - "AU-05(05)": [ - "MON-13" + "A.03.15.02.ODP[01]": [ + "IAO-03" ], - "AU-16": [ - "MON-14" + "A.03.15.02.a.01": [ + "IAO-03" ], - "AU-16(01)": [ - "MON-14" + "A.03.15.02.a.02": [ + "IAO-03" ], - "AU-16(02)": [ - "MON-14.1" + "A.03.15.02.a.03": [ + "IAO-03" ], - "SC-31": [ - "MON-15" + "A.03.15.02.a.04": [ + "IAO-03" ], - "AC-02(12)": [ - "MON-16" + "A.03.15.02.a.05": [ + "IAO-03" ], - "IR-04(13)": [ - "MON-16", - "SEA-11", - "SEA-12" + "A.03.15.02.a.06": [ + "IAO-03" ], - "SI-04(11)": [ - "MON-16" + "A.03.15.02.a.07": [ + "IAO-03" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "A.03.15.02.a.08": [ + "IAO-03" ], - "SC-08(02)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" + "A.03.15.02.b[01]": [ + "IAO-03" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "A.03.15.02.b[02]": [ + "IAO-03" ], - "SI-07(06)": [ - "CRY-01" + "A.03.12.02.b.01": [ + "IAO-05" ], - "SC-08(04)": [ - "CRY-01.4" + "A.03.12.02.b.02": [ + "IAO-05" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "A.03.12.02.b.03": [ + "IAO-05" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "A.03.14.01.a[01]": [ + "IAO-05", + "TDA-01", + "TDA-09", + "THR-01", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-06" ], - "SC-16(01)": [ - "CRY-04", - "CRY-10" + "A.03.07.04.a[03]": [ + "MNT-04" ], - "SC-28": [ - "CRY-05", - "END-02" + "A.03.07.04.b": [ + "MNT-04.1", + "MNT-04.2" ], - "AC-18": [ - "CRY-07", - "NET-15" + "A.03.01.12.d[1]": [ + "MNT-05", + "NET-14.4" ], - "SC-40": [ - "CRY-07", - "NET-12.1" + "A.03.07.05.a[02]": [ + "MNT-05", + "MNT-05.1" ], - "SC-12": [ - "CRY-08" + "A.03.07.06.b": [ + "MNT-06", + "TPM-01.1", + "TPM-05.4" ], - "SC-17": [ - "CRY-08" + "A.03.07.06.c": [ + "MNT-06", + "MNT-06.1", + "MNT-06.2" ], - "SC-28(03)": [ - "CRY-09" + "A.03.01.18.c": [ + "MDM-03" ], - "SC-12(02)": [ - "CRY-09.1" + "A.03.01.18.a[03]": [ + "NET-01", + "NET-03" ], - "SC-12(03)": [ - "CRY-09.2" + "A.03.13.01.a[02]": [ + "NET-01", + "NET-03", + "NET-04", + "NET-04.1", + "NET-08" ], - "SC-12(01)": [ - "CRY-09.3" + "A.03.13.01.b": [ + "NET-02", + "NET-03", + "NET-03.8", + "NET-06", + "NET-06.3", + "NET-08.1" ], - "SA-09(06)": [ - "CRY-09.7" + "A.03.01.16.a[04]": [ + "NET-02.2", + "NET-15", + "NET-15.1" ], - "SC-16": [ - "CRY-10" + "A.03.13.01.a[04]": [ + "NET-03" ], - "SC-23(05)": [ - "CRY-11" + "A.03.13.01.c": [ + "NET-03", + "NET-04", + "SEA-01", + "SEA-02" ], - "MP-02": [ - "DCH-03", - "END-01" + "A.03.13.06[01]": [ + "NET-04.1" ], - "AC-03(09)": [ - "DCH-03.3" + "A.03.13.06[02]": [ + "NET-04.1" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "A.03.12.05.ODP[01]": [ + "NET-05" ], - "AC-16": [ - "DCH-05" + "A.03.12.05.ODP[02]": [ + "NET-05" ], - "AC-16(01)": [ - "DCH-05.1" + "A.03.12.05.a[02]": [ + "NET-05" ], - "AC-16(02)": [ - "DCH-05.2" + "A.03.12.05.b[01]": [ + "NET-05" ], - "AC-16(03)": [ - "DCH-05.3" + "A.03.12.05.b[02]": [ + "NET-05" ], - "AC-16(04)": [ - "DCH-05.4" + "A.03.12.05.b[03]": [ + "NET-05" ], - "AC-16(05)": [ - "DCH-05.5" + "A.03.12.05.c[01]": [ + "NET-05" ], - "AC-16(06)": [ - "DCH-05.6" + "A.03.12.05.c[02]": [ + "NET-05" ], - "AC-16(07)": [ - "DCH-05.7" + "A.03.07.05.c[02]": [ + "NET-07" ], - "AC-16(08)": [ - "DCH-05.8" + "A.03.13.09.ODP[01]": [ + "NET-07" ], - "AC-16(09)": [ - "DCH-05.9" + "A.03.13.09": [ + "NET-07" ], - "AC-16(10)": [ - "DCH-05.10" + "A.03.13.15": [ + "NET-09" ], - "MP-04": [ - "DCH-06" + "A.03.01.12.a[04]": [ + "NET-14", + "NET-14.2", + "SEA-01" ], - "MP-05": [ - "DCH-07" + "A.03.01.12.b": [ + "NET-14", + "NET-14.1" ], - "MP-05(03)": [ - "DCH-07.1" + "A.03.01.12.d[2]": [ + "NET-14.4" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "A.03.10.06.ODP[01]": [ + "NET-14.5", + "PES-11" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" + "A.03.10.06.a": [ + "NET-14.5", + "PES-11" ], - "MP-06(01)": [ - "DCH-09.1" + "A.03.10.06.b": [ + "NET-14.5", + "PES-11" ], - "MP-06(02)": [ - "DCH-09.2" + "A.03.01.16.d[01]": [ + "NET-15.1" ], - "MP-06(07)": [ - "DCH-09.5" + "A.03.01.16.d[02]": [ + "NET-15.1" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "A.03.14.06.c[02]": [ + "NET-18" ], - "MP-08": [ - "DCH-11" + "A.03.10.07.a.01": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1", + "PES-03.4", + "PES-04", + "PES-04.1" ], - "MP-08(03)": [ - "DCH-11" + "A.03.04.05[02]": [ + "PES-02" ], - "AC-20": [ - "DCH-13" + "A.03.10.01.ODP[01]": [ + "PES-02", + "PES-02.1" ], - "AC-20(01)": [ - "DCH-13.1" + "A.03.10.01.b": [ + "PES-02", + "PES-02.1" ], - "AC-20(02)": [ - "DCH-13.2" + "A.03.04.05[01]": [ + "PES-02.1" ], - "AC-20(05)": [ - "DCH-13.2" + "A.03.04.05[03]": [ + "PES-03" ], - "PM-17": [ - "DCH-13.3" + "A.03.10.02.a[01]": [ + "PES-03", + "PES-03.1", + "PES-03.3", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "AC-20(03)": [ - "DCH-13.4" + "A.03.10.07.a.02": [ + "PES-03", + "PES-03.1", + "PES-03.3", + "PES-03.4", + "PES-04", + "PES-04.1" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "A.03.10.07.d": [ + "PES-03", + "PES-04", + "PES-04.1" ], - "AC-21(02)": [ - "DCH-14.1" + "A.03.10.02.ODP[01]": [ + "PES-05" ], - "CA-03(06)": [ - "DCH-14.2" + "A.03.10.02.ODP[02]": [ + "PES-05" ], - "AC-22": [ - "DCH-15" + "A.03.10.02.a[02]": [ + "PES-05" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "A.03.10.02.b[01]": [ + "PES-05", + "PES-05.2" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "A.03.10.02.b[02]": [ + "PES-05", + "PES-05.2" ], - "SI-12(01)": [ - "DCH-18.1", - "PRI-05.1" + "A.03.10.07.c[01]": [ + "PES-06", + "PES-06.1", + "PES-06.2", + "PES-06.3", + "PES-06.6" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "A.03.10.07.c[02]": [ + "PES-06", + "PES-06.1", + "PES-06.2", + "PES-06.3", + "PES-06.6" ], - "SA-08(33)": [ - "DCH-18.2", - "END-13.3", - "PES-06.5" + "A.03.10.08": [ + "PES-07", + "PES-12", + "PES-12.1" ], - "SA-15(12)": [ - "DCH-18.2" + "A.03.10.07.e": [ + "PES-12", + "PES-12.2" ], - "SI-12(02)": [ - "DCH-18.2", - "PRI-05.1" + "A.03.17.03.b": [ + "RSK-01", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7" ], - "SI-12(03)": [ - "DCH-21", - "PRI-05" + "A.03.14.03.a": [ + "RSK-02.1", + "THR-01", + "THR-03", + "THR-03.1", + "THR-10" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "A.03.11.02.b": [ + "RSK-06", + "RSK-06.1", + "RSK-06.2", + "VPM-02", + "VPM-04", + "VPM-05" ], - "SI-18": [ - "DCH-22" + "A.03.11.04[01]": [ + "RSK-06.1" ], - "SI-18(01)": [ - "DCH-22" + "A.03.11.04[02]": [ + "RSK-06.1" ], - "SI-18(04)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "A.03.11.04[03]": [ + "RSK-06.1" ], - "SI-18(05)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "A.03.11.01.ODP[01]": [ + "RSK-07" ], - "PT-02(01)": [ - "DCH-22.2" + "A.03.11.01.b": [ + "RSK-07", + "RSK-09.1" ], - "PT-03(01)": [ - "DCH-22.2", - "PRI-11" + "A.03.17.01.ODP[01]": [ + "RSK-09" ], - "SI-18(02)": [ - "DCH-22.2" + "A.03.17.01.a[02]": [ + "RSK-09" ], - "SI-18(03)": [ - "DCH-22.3" + "A.03.17.01.a[03]": [ + "RSK-09" ], - "SI-19(01)": [ - "DCH-22.3", - "DCH-23.1" + "A.03.17.01.a[04]": [ + "RSK-09" ], - "SI-19": [ - "DCH-23" + "A.03.17.01.a[05]": [ + "RSK-09" ], - "SI-19(02)": [ - "DCH-23.2" + "A.03.17.01.a[06]": [ + "RSK-09" ], - "SI-19(03)": [ - "DCH-23.3" + "A.03.17.01.a[07]": [ + "RSK-09" ], - "SI-19(04)": [ - "DCH-23.4", - "PRI-05.3" + "A.03.17.01.a[08]": [ + "RSK-09" ], - "SI-19(05)": [ - "DCH-23.5" + "A.03.17.01.a[09]": [ + "RSK-09" ], - "SI-19(06)": [ - "DCH-23.6" + "A.03.17.01.a[10]": [ + "RSK-09" ], - "SI-19(07)": [ - "DCH-23.7" + "A.03.17.01.b[01]": [ + "RSK-09" ], - "SI-19(08)": [ - "DCH-23.8" + "A.03.17.01.b[02]": [ + "RSK-09" ], - "CM-12": [ - "DCH-24" + "A.03.17.03.ODP[01]": [ + "RSK-09", + "TPM-01" ], - "CM-12(01)": [ - "DCH-24.1" + "A.03.17.03.a[01]": [ + "RSK-09", + "RSK-09.1", + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "A.03.17.03.a[02]": [ + "RSK-09", + "TPM-05.5" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "A.03.16.01.ODP[01]": [ + "SEA-01", + "TDA-01", + "TDA-02.3" ], - "SI-03(06)": [ - "END-04.5" + "A.03.13.04[01]": [ + "SEA-05" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "A.03.13.04[02]": [ + "SEA-05" ], - "SI-07(01)": [ - "END-06.1" + "A.03.16.02.b": [ + "SEA-07", + "SEA-07.1", + "TDA-17.1" ], - "SI-07(07)": [ - "END-06.2" + "A.03.16.02.a": [ + "SEA-07.1", + "TDA-17" ], - "SI-07(02)": [ - "END-06.3" + "A.03.02.01.ODP[01]": [ + "SAT-01" ], - "SI-07(05)": [ - "END-06.4" + "A.03.02.01.ODP[02]": [ + "SAT-01" ], - "SI-07(09)": [ - "END-06.5" + "A.03.02.01.a.01[01]": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" ], - "SI-07(10)": [ - "END-06.6" + "A.03.02.01.b[01]": [ + "SAT-01.1" ], - "CM-07(08)": [ - "END-06.7" + "A.03.02.01.b[02]": [ + "SAT-01.1", + "SAT-03.6", + "THR-03" ], - "SI-08": [ - "END-08" + "A.03.02.02.b[01]": [ + "SAT-01.1" ], - "SI-08(02)": [ - "END-08.2" + "A.03.02.02.b[02]": [ + "SAT-01.1" ], - "SC-11": [ - "END-09" + "A.03.06.04.ODP[03]": [ + "SAT-01.1" ], - "SC-18": [ - "END-10" + "A.03.06.04.ODP[04]": [ + "SAT-01.1" ], - "SC-18(01)": [ - "END-10", - "VPM-02", - "VPM-04" + "A.03.06.04.b[01]": [ + "SAT-01.1" ], - "SC-18(03)": [ - "END-10", - "NET-18" + "A.03.06.04.b[02]": [ + "SAT-01.1" ], - "SC-27": [ - "END-10" + "A.03.02.01.ODP[03]": [ + "SAT-02" ], - "SC-25": [ - "END-11" + "A.03.02.01.ODP[04]": [ + "SAT-02" ], - "SC-41": [ - "END-12" + "A.03.02.01.a.03[03]": [ + "SAT-02", + "SAT-02.2" ], - "SC-42": [ - "END-13" + "A.03.02.01.a.03[04]": [ + "SAT-02" ], - "SC-42(02)": [ - "END-13.1" + "A.03.02.01.a.03[05]": [ + "SAT-02.2" ], - "SC-42(04)": [ - "END-13.2" + "A.03.02.01.a.03[06]": [ + "SAT-02.2" ], - "SC-42(05)": [ - "END-13.3" + "A.03.02.01.a.01[02]": [ + "SAT-03" ], - "SC-42(01)": [ - "END-13.4" + "A.03.02.01.a.02": [ + "SAT-03", + "SAT-03.6", + "THR-03" ], - "SC-15": [ - "END-14" + "A.03.02.02.ODP[01]": [ + "SAT-03" ], - "SC-15(01)": [ - "END-14" + "A.03.02.02.ODP[02]": [ + "SAT-03" ], - "SC-15(03)": [ - "END-14.1" + "A.03.02.02.ODP[03]": [ + "SAT-03" ], - "SC-15(04)": [ - "END-14.2" + "A.03.02.02.ODP[04]": [ + "SAT-03" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "A.03.02.02.a.01[02]": [ + "SAT-03" ], - "SC-07(12)": [ - "END-16.1" + "A.03.02.02.a.01[03]": [ + "SAT-03" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "A.03.02.02.a.02": [ + "SAT-03", + "SAT-03.6" ], - "SI-04(21)": [ - "HRS-02.2" + "A.03.06.04.ODP[02]": [ + "SAT-03" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "A.03.06.04.a.02": [ + "SAT-03", + "SAT-03.6" ], - "PS-09": [ - "HRS-03" + "A.03.17.02[04]": [ + "TDA-01", + "TPM-01", + "TPM-03.1" ], - "PS-03": [ - "HRS-04" + "A.03.17.02[05]": [ + "TDA-01", + "TPM-01", + "TPM-03.1", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.1", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7", + "TPM-08" ], - "PS-03(01)": [ - "HRS-04.1" + "A.03.17.02[06]": [ + "TDA-01", + "TPM-01", + "TPM-04", + "TPM-04.1", + "TPM-05.5", + "TPM-05.7", + "TPM-08", + "TPM-09", + "TPM-10" ], - "PS-03(03)": [ - "HRS-04.1" + "A.03.14.01.a[02]": [ + "TDA-09", + "THR-06", + "VPM-06" ], - "PS-03(02)": [ - "HRS-04.2" + "A.03.16.03.a": [ + "TPM-01", + "TPM-04", + "TPM-04.4", + "TPM-05", + "TPM-05.2", + "TPM-05.8" ], - "PS-03(04)": [ - "HRS-04.3" + "A.03.17.02[01]": [ + "TPM-03.1" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "A.03.17.02[02]": [ + "TPM-03.1", + "TPM-04", + "TPM-04.1" ], - "PL-04(01)": [ - "HRS-05.2" + "A.03.17.02[03]": [ + "TPM-03.1", + "TPM-04", + "TPM-04.1" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "A.03.16.03.c": [ + "TPM-04", + "TPM-05", + "TPM-05.2", + "TPM-05.5", + "TPM-05.6", + "TPM-05.8", + "TPM-08" ], - "PS-06(02)": [ - "HRS-06", - "HRS-06.1" + "A.03.16.03.ODP[01]": [ + "TPM-05", + "TPM-05.2" ], - "PS-06(03)": [ - "HRS-06.2" + "A.03.11.02.a[01]": [ + "THR-01", + "THR-03", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-06" ], - "PS-08": [ - "HRS-07" + "A.03.14.03.b[01]": [ + "THR-03.1" ], - "PS-05": [ - "HRS-08" + "A.03.14.03.b[02]": [ + "THR-03.1" ], - "PS-04": [ - "HRS-09" + "A.03.02.01.a.03[01]": [ + "THR-05" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "A.03.02.01.a.03[02]": [ + "THR-05" ], - "PS-04(01)": [ - "HRS-09.3" + "A.03.11.02.ODP[03]": [ + "VPM-01", + "VPM-02" ], - "PS-04(02)": [ - "HRS-09.4" + "A.03.14.01.a[03]": [ + "VPM-04", + "VPM-05" ], - "PS-07": [ - "HRS-10" + "A.03.14.01.ODP[01]": [ + "VPM-05" ], - "AC-03(02)": [ - "HRS-12.1", - "IAC-20.5" + "A.03.14.01.ODP[02]": [ + "VPM-05" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "A.03.14.01.b[01]": [ + "VPM-05" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "A.03.14.01.b[02]": [ + "VPM-05" ], - "IA-02": [ - "IAC-02" + "A.03.11.02.ODP[01]": [ + "VPM-06" ], - "IA-02(05)": [ - "IAC-02.1" + "A.03.11.02.ODP[02]": [ + "VPM-06" ], - "IA-02(08)": [ - "IAC-02.2" + "A.03.11.02.ODP[04]": [ + "VPM-06", + "VPM-06.1" ], - "IA-02(12)": [ - "IAC-02.3" + "A.03.11.02.a[02]": [ + "VPM-06" ], - "IA-08(05)": [ - "IAC-02.3" + "A.03.11.02.a[03]": [ + "VPM-06" ], - "IA-02(13)": [ - "IAC-02.4" + "A.03.11.02.a[04]": [ + "VPM-06" ], - "IA-08": [ - "IAC-03" + "A.03.11.02.c[01]": [ + "VPM-06.1" ], - "IA-08(01)": [ - "IAC-03.1" + "A.03.11.02.c[02]": [ + "VPM-06.1" + ] + }, + "general-nist-800-172-r3": { + "03.01.17E": [ + "GOV-02", + "DCH-01", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "NET-04.10", + "NET-17" ], - "IA-08(02)": [ - "IAC-03.2" + "03.05.07E": [ + "GOV-02", + "IAC-01", + "IAC-01.4" ], - "IA-08(04)": [ - "IAC-03.3" + "03.17.03E": [ + "GOV-02", + "HRS-03", + "IRO-02", + "TDA-11" ], - "IA-08(06)": [ - "IAC-03.4" + "03.04.02E": [ + "AST-02.2", + "CFG-02.2", + "CFG-02.8", + "CFG-05.1", + "END-03.1" ], - "IA-03": [ - "IAC-04" + "03.01.14E": [ + "AST-02.8", + "AST-04", + "CFG-02", + "NET-04.7", + "NET-04.8" ], - "IA-03(01)": [ - "IAC-04" + "03.04.03E": [ + "AST-02.9" ], - "IA-03(04)": [ - "IAC-04", - "IAC-04.1" + "03.04.08E": [ + "AST-02.9" ], - "IA-09": [ - "IAC-05" + "03.17.04E": [ + "AST-03.2" ], - "AC-06(06)": [ - "IAC-05.2" + "03.06.03E": [ + "AST-04.1", + "MON-16" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "03.17.02E": [ + "AST-08", + "AST-15.1", + "IAO-03", + "OPS-01.1", + "TDA-11" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "03.17.05E": [ + "AST-08", + "AST-15", + "TDA-11" ], - "IA-02(06)": [ - "IAC-06.4" + "03.04.04E": [ + "BCD-01", + "CFG-02.2" ], - "IA-12(04)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" + "03.08.04E": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "03.11.10E": [ + "BCD-02", + "PRM-04", + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "AC-02(07)": [ - "IAC-08" + "03.08.03E": [ + "BCD-11.1", + "OPS-01.1" ], - "IA-04(05)": [ - "IAC-09.3" + "03.08.02E": [ + "BCD-11.8", + "DCH-09.5" ], - "IA-05(10)": [ - "IAC-09.3" + "03.13.12E": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "IA-04(06)": [ - "IAC-09.4" + "03.04.07E": [ + "CHG-02.2", + "CHG-06" ], - "IA-05(08)": [ - "IAC-09.5", - "IAC-10.9" + "03.04.05E": [ + "CHG-04.3" ], - "IA-04(08)": [ - "IAC-09.6" + "03.12.03E": [ + "CPL-02", + "RSK-11" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "03.01.04E": [ + "CFG-02", + "IAC-23", + "IAO-03" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "03.01.16E": [ + "CFG-02", + "NET-04.9" ], - "IA-05(02)": [ - "IAC-10.2" + "03.05.01E": [ + "CFG-02", + "IAC-04" ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" + "03.05.05E": [ + "CFG-02", + "IAC-10.10" ], - "IA-05(07)": [ - "IAC-10.6" + "03.12.04E": [ + "CFG-02", + "NET-05", + "NET-05.2" ], - "IA-05(05)": [ - "IAC-10.8" + "03.13.06E": [ + "CFG-02", + "CFG-03.3", + "END-10" ], - "IA-05(13)": [ - "IAC-10.10" + "03.13.11E": [ + "CFG-02", + "END-11", + "IAO-03" ], - "IA-05(18)": [ - "IAC-10.11" + "03.13.13E": [ + "CFG-02", + "END-12" ], - "IA-05(12)": [ - "IAC-10.12" + "03.14.11E": [ + "CFG-02", + "CFG-06.1", + "END-06.2", + "END-06.8" ], - "IA-06": [ - "IAC-11" + "03.04.06E": [ + "CFG-02.3", + "DCH-18" ], - "IA-10": [ - "IAC-13" + "03.14.17E": [ + "MON-01.4", + "MON-01.12", + "MON-11.3", + "HRS-03", + "IRO-03" ], - "IA-02(10)": [ - "IAC-13.1" + "03.14.19E": [ + "MON-01.5" ], - "IA-05(09)": [ - "IAC-13.2" + "03.14.01E": [ + "MON-01.7", + "MON-01.8", + "END-06" ], - "IA-11": [ - "IAC-14" + "03.01.08E": [ + "MON-01.8", + "MON-11.3", + "MON-16", + "HRS-03", + "IRO-03" ], - "AC-02(01)": [ - "IAC-15.1" + "03.11.09E": [ + "MON-01.8", + "MON-11.3", + "IRO-01", + "IRO-03" ], - "AC-02(02)": [ - "IAC-15.2" + "03.14.18E": [ + "MON-01.12", + "MON-11.3", + "HRS-03" ], - "AC-02(03)": [ - "IAC-15.3" + "03.03.04E": [ + "MON-02.3" ], - "AC-02(04)": [ - "IAC-15.4" + "03.03.02E": [ + "MON-05", + "MON-05.1" ], - "AC-02(09)": [ - "IAC-15.5" + "03.03.01E": [ + "MON-08.1" ], - "AC-02(11)": [ - "IAC-15.8" + "03.03.03E": [ + "MON-08.4" ], - "AC-06(07)": [ - "IAC-17" + "03.11.02E": [ + "MON-11.3", + "IRO-03", + "OPS-01.1", + "THR-07" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "03.14.09E": [ + "CRY-01" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "03.08.01E": [ + "DCH-09", + "DCH-09.5" ], - "AC-03(08)": [ - "IAC-20.6" + "03.01.02E": [ + "DCH-13.4" ], - "SA-08(14)": [ - "IAC-21" + "03.10.01E": [ + "DCH-18", + "PES-05", + "PES-05.1", + "PES-05.2", + "PES-06" ], - "AC-06(01)": [ - "IAC-21.1" + "03.14.08E": [ + "END-06.1", + "IAO-03", + "OPS-01.1" ], - "AC-06(02)": [ - "IAC-21.2" + "03.14.10E": [ + "END-06.6", + "IAO-03" ], - "AC-06(05)": [ - "IAC-21.3" + "03.09.03E": [ + "HRS-01", + "HRS-06", + "OPS-01.1" ], - "AC-06(09)": [ - "IAC-21.4" + "03.09.04E": [ + "HRS-01", + "HRS-04.3" ], - "AC-06(10)": [ - "IAC-21.5" + "03.01.11E": [ + "HRS-03", + "IAC-08", + "IAC-15.1" ], - "AC-06(03)": [ - "IAC-21.6" + "03.01.01E": [ + "HRS-12.1", + "IAC-20.5" ], - "AC-06(08)": [ - "IAC-21.7" + "03.05.03E": [ + "IAC-04", + "IAC-04.1" ], - "AC-07": [ - "IAC-22" + "03.05.02E": [ + "IAC-10.1", + "IAC-10.4", + "IAC-10.5", + "IAC-10.11" ], - "AC-10": [ - "IAC-23" + "03.05.04E": [ + "IAC-10.6" ], - "AC-02(05)": [ - "IAC-24" + "03.01.07E": [ + "IAC-15.1", + "IAC-15.4" ], - "AC-11": [ - "IAC-24" + "03.05.06E": [ + "IAC-28" ], - "AC-11(01)": [ - "IAC-24.1" + "03.01.09E": [ + "IAC-29" ], - "AC-12": [ - "IAC-25" + "03.02.01E": [ + "IRO-03", + "OPS-01.1", + "SAT-01.1", + "SAT-03", + "SAT-03.2", + "SAT-03.6" ], - "AC-12(01)": [ - "IAC-25.1" + "03.06.02E": [ + "IRO-07" ], - "AC-14": [ - "IAC-26" + "03.06.04E": [ + "IRO-09.1" ], - "AC-25": [ - "IAC-27" + "03.13.14E": [ + "IRO-15", + "IAO-03" ], - "IA-12": [ - "IAC-28" + "03.12.02E": [ + "IAO-02.1" ], - "AC-24": [ - "IAC-28.1" + "03.01.06E": [ + "IAO-03", + "NET-14" ], - "IA-12(01)": [ - "IAC-28.1" + "03.13.16E": [ + "IAO-03", + "SEA-03.1" ], - "IA-12(02)": [ - "IAC-28.2" + "03.14.14E": [ + "IAO-03", + "SEA-10" ], - "IA-12(03)": [ - "IAC-28.3" + "03.14.15E": [ + "IAO-03", + "SEA-08", + "OPS-01.1" ], - "IA-12(05)": [ - "IAC-28.5" + "03.14.16E": [ + "IAO-03", + "THR-08" ], - "IR-04": [ - "IRO-02" + "03.15.01E": [ + "IAO-03", + "SEA-01.4", + "SEA-01.5", + "SEA-02", + "OPS-01.1" ], - "IR-04(01)": [ - "IRO-02.1" + "03.15.02E": [ + "IAO-03", + "SEA-03" ], - "IR-04(06)": [ - "IRO-02.2" + "03.15.03E": [ + "IAO-03", + "TDA-03.1" ], - "IR-04(07)": [ - "IRO-02.2" + "03.16.01E": [ + "IAO-03", + "TDA-01", + "TDA-01.1" ], - "IR-04(02)": [ - "IRO-02.3" + "03.07.01E": [ + "MNT-04" ], - "IR-04(08)": [ - "IRO-02.5" + "03.01.12E": [ + "NET-03", + "NET-06" ], - "IR-08": [ - "IRO-04" + "03.13.04E": [ + "NET-03", + "NET-03.7" ], - "IR-08(01)": [ - "IRO-04.1" + "03.13.10E": [ + "NET-03.8" ], - "IR-03(03)": [ - "IRO-04.3" + "03.13.15E": [ + "NET-03.8", + "NET-06.1", + "NET-06.9" ], - "IR-02": [ - "IRO-05" + "03.01.10E": [ + "NET-04.2", + "NET-04.7" ], - "IR-02(03)": [ - "IRO-05" + "03.01.13E": [ + "NET-04.5", + "NET-04.7", + "NET-04.8" ], - "IR-02(01)": [ - "IRO-05.1" + "03.01.15E": [ + "NET-04.8" ], - "IR-02(02)": [ - "IRO-05.2" + "03.13.09E": [ + "NET-06.1", + "NET-06.9" ], - "IR-03": [ - "IRO-06" + "03.01.05E": [ + "NET-14.1" ], - "SI-04(09)": [ - "IRO-06" + "03.10.02E": [ + "PES-05", + "PES-10" ], - "IR-03(02)": [ - "IRO-06.1" + "03.13.01E": [ + "PRM-05", + "PRM-06", + "SEA-13" ], - "IR-04(11)": [ - "IRO-07" + "03.13.02E": [ + "PRM-05", + "SEA-14.1" ], - "AU-10(03)": [ - "IRO-08" + "03.13.03E": [ + "PRM-05", + "SEA-14" ], - "IR-04(12)": [ - "IRO-08", - "IRO-13" + "03.14.04E": [ + "SEA-08.1" ], - "IR-05": [ - "IRO-09" + "03.14.05E": [ + "SEA-08.2" ], - "IR-05(01)": [ - "IRO-09.1" + "03.13.08E": [ + "SEA-11" ], - "IR-06(01)": [ - "IRO-10.1" + "03.13.07E": [ + "SEA-13.1", + "OPS-01.1" ], - "IR-06(02)": [ - "IRO-10.3", - "IRO-13" + "03.13.05E": [ + "SEA-14.2", + "OPS-01.1" ], - "IR-04(10)": [ - "IRO-10.4", - "TPM-11" + "03.12.01E": [ + "OPS-01.1", + "VPM-01.1", + "VPM-07" ], - "IR-06(03)": [ - "IRO-10.4" + "03.06.01E": [ + "OPS-04" ], - "IR-07": [ - "IRO-11" + "03.02.02E": [ + "SAT-02.1" ], - "IR-07(01)": [ - "IRO-11.1" + "03.02.04E": [ + "SAT-03", + "TDA-11.1" ], - "IR-07(02)": [ - "IRO-11.2" + "03.02.03E": [ + "SAT-04.1" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "03.14.12E": [ + "TDA-18" ], - "IR-09(02)": [ - "IRO-12.2" + "03.14.13E": [ + "TDA-19" ], - "IR-09(03)": [ - "IRO-12.3" + "03.17.01E": [ + "TPM-05", + "TPM-05.1" ], - "IR-09(04)": [ - "IRO-12.4" + "03.11.01E": [ + "THR-01" ], - "SC-44": [ - "IRO-15" + "03.11.08E": [ + "THR-01.1" ], - "IR-04(15)": [ - "IRO-16" + "03.11.03E": [ + "THR-01.2" ], - "PM-10": [ - "IAO-01" + "03.11.12E": [ + "THR-03" ], - "CA-02(01)": [ - "IAO-02.1" + "03.11.11E": [ + "VPM-02", + "VPM-06.8" + ] + }, + "general-nist-800-172a-r3": { + "A.03.01.17E.ODP[02]": [ + "GOV-02", + "DCH-01", + "DCH-01.2", + "DCH-01.4" ], - "CA-02(02)": [ - "IAO-02.2" + "A.03.05.07E.ODP[01]": [ + "GOV-02", + "IAC-01" ], - "SA-11(05)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "DS-A.03.17.03E.a[01]": [ + "GOV-02" ], - "CA-02(03)": [ - "IAO-02.3" + "DS-A.03.17.03E.a[02]": [ + "GOV-02" ], - "CA-05": [ - "IAO-05" + "DS-A.03.17.03E.a[03]": [ + "GOV-02" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "DS-A.03.17.03E.a[04]": [ + "GOV-02" ], - "SA-15(02)": [ - "IAO-05" + "A.03.02.03E.ODP[01]": [ + "GOV-04.1" ], - "CA-05(01)": [ - "IAO-05.1" + "DS-A.03.04.02E.a": [ + "AST-02.2" ], - "CM-04(02)": [ - "IAO-06" + "A.03.04.02E.ODP[01]": [ + "AST-02.2" ], - "CA-06": [ - "IAO-07" + "A.03.01.14E.ODP[02]": [ + "AST-02.8", + "AST-04" ], - "MA-02": [ - "MNT-02" + "DS-A.03.04.03E[01]": [ + "AST-02.9", + "CFG-02.2" ], - "MA-02(02)": [ - "MNT-02.1" + "A.03.04.03E.ODP[01]": [ + "AST-02.9" ], - "MA-06": [ - "MNT-03" + "DS-A.03.04.03E[02]": [ + "AST-02.9" ], - "MA-06(01)": [ - "MNT-03.1" + "A.03.04.03E.ODP[02]": [ + "AST-02.9" ], - "MA-06(02)": [ - "MNT-03.2" + "DS-A.03.04.03E[03]": [ + "AST-02.9" ], - "MA-06(03)": [ - "MNT-03.3" + "A.03.04.03E.ODP[03]": [ + "AST-02.9" ], - "MA-03": [ - "MNT-04" + "DS-A.03.04.04E[01]": [ + "AST-02.9" ], - "MA-03(05)": [ - "MNT-04" + "DS-A.03.04.04E[02]": [ + "AST-02.9" ], - "MA-03(06)": [ - "MNT-04" + "DS-A.03.04.04E[03]": [ + "AST-02.9" ], - "MA-03(01)": [ - "MNT-04.1" + "DS-A.03.04.08E": [ + "AST-02.9" ], - "MA-03(02)": [ - "MNT-04.2" + "DS-A.03.17.04E[01]": [ + "AST-03.2" ], - "MA-03(03)": [ - "MNT-04.3" + "A.03.17.04E.ODP[01]": [ + "AST-03.2" ], - "MA-03(04)": [ - "MNT-04.4" + "DS-A.03.17.04E[02]": [ + "AST-03.2" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "DS-A.03.17.04E[03]": [ + "AST-03.2" ], - "MA-04(01)": [ - "MNT-05.1" + "A.03.06.03E.ODP[01]": [ + "AST-04.1" ], - "MA-04(06)": [ - "MNT-05.3" + "A.03.17.02E.ODP[04]": [ + "AST-08", + "TDA-11" ], - "MA-04(07)": [ - "MNT-05.4" + "A.03.17.05E.ODP[02]": [ + "AST-08", + "AST-15" ], - "MA-04(05)": [ - "MNT-05.5" + "DS-A.03.17.02E": [ + "AST-15.1" ], - "MA-04(03)": [ - "MNT-05.6" + "DS-A.03.04.03E[04]": [ + "BCD-01" ], - "MA-04(04)": [ - "MNT-05.7" + "A.03.04.03E.ODP[04]": [ + "BCD-01" ], - "MA-05": [ - "MNT-06" + "DS-A.03.04.04E[04]": [ + "BCD-01" ], - "MA-05(01)": [ - "MNT-06.1" + "DS-A.03.08.04E[01]": [ + "BCD-01" ], - "MA-05(02)": [ - "MNT-06.1" + "A.03.08.04E.ODP[01]": [ + "BCD-01.4" ], - "MA-05(03)": [ - "MNT-06.1" + "A.03.08.04E.ODP[02]": [ + "BCD-01.4" ], - "MA-05(04)": [ - "MNT-06.1" + "DS-A.03.11.10E": [ + "BCD-02", + "PRM-05" ], - "MA-05(05)": [ - "MNT-06.2" + "DS-A.03.08.03E[01]": [ + "BCD-11.1" ], - "SR-11(02)": [ - "MNT-07" + "DS-A.03.08.03E[02]": [ + "BCD-11.1" ], - "MA-07": [ - "MNT-08" + "DS-A.03.08.02E": [ + "BCD-11.8" ], - "AC-19": [ - "MDM-02" + "DS-A.03.08.04E[02]": [ + "BCD-12" ], - "AC-19(05)": [ - "MDM-03" + "DS-A.03.13.12E.b": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "PE-03(05)": [ - "MDM-04" + "DS-A.03.04.07E[01]": [ + "CHG-02.2" ], - "AC-07(02)": [ - "MDM-05" + "DS-A.03.04.07E[03]": [ + "CHG-02.2" ], - "MP-06(08)": [ - "MDM-05" + "DS-A.03.04.05E[01]": [ + "CHG-04.3" ], - "SC-46": [ - "NET-02.3" + "A.03.04.05E.ODP[01]": [ + "CHG-04.3" ], - "SC-07": [ - "NET-03" + "DS-A.03.04.05E[02]": [ + "CHG-04.3" ], - "SC-07(09)": [ - "NET-03", - "NET-03.2" + "A.03.04.05E.ODP[02]": [ + "CHG-04.3" ], - "SC-07(11)": [ - "NET-03", - "NET-04.1" + "DS-A.03.04.07E[02]": [ + "CHG-06" ], - "SC-07(03)": [ - "NET-03.1" + "DS-A.03.12.03E[02]": [ + "CPL-02" ], - "SC-07(04)": [ - "NET-03.2" + "DS-A.03.12.03E[03]": [ + "CPL-02" ], - "SC-07(16)": [ - "NET-03.3" + "DS-A.03.12.03E[04]": [ + "CPL-02" ], - "SC-07(24)": [ - "NET-03.4" + "A.03.01.04E.ODP[01]": [ + "CFG-02", + "IAC-23" ], - "SC-07(10)": [ - "NET-03.5", - "NET-17" + "A.03.01.14E.ODP[03]": [ + "CFG-02" ], - "SC-07(20)": [ - "NET-03.6" + "A.03.01.14E.ODP[04]": [ + "CFG-02" ], - "SC-07(21)": [ - "NET-03.7" + "DS-A.03.01.16E": [ + "CFG-02" ], - "SC-07(22)": [ - "NET-03.8" + "A.03.05.01E.ODP[01]": [ + "CFG-02" ], - "AC-04": [ - "NET-04" + "DS-A.03.05.05E": [ + "CFG-02" ], - "SC-07(05)": [ - "NET-04.1" + "DS-A.03.12.04E.c": [ + "CFG-02", + "NET-05.2" ], - "AC-04(01)": [ - "NET-04.2" + "A.03.13.06E.ODP[01]": [ + "CFG-02", + "CFG-03.3" ], - "AC-04(04)": [ - "NET-04.3" + "DS-A.03.13.11E[02]": [ + "CFG-02" ], - "AC-04(05)": [ - "NET-04.4" + "A.03.13.13E.ODP[01]": [ + "CFG-02" ], - "AC-04(06)": [ - "NET-04.5" + "A.03.14.11E.ODP[01]": [ + "CFG-02" ], - "AC-04(09)": [ - "NET-04.6" + "A.03.04.02E.ODP[03]": [ + "CFG-02.2" ], - "AC-04(08)": [ - "NET-04.7" + "A.03.04.04E.ODP[01]": [ + "CFG-02.2" ], - "AC-04(12)": [ - "NET-04.8" + "DS-A.03.04.06E": [ + "CFG-02.3", + "DCH-18" ], - "AC-04(13)": [ - "NET-04.9" + "A.03.04.06E.ODP[01]": [ + "CFG-02.3" ], - "AC-04(15)": [ - "NET-04.10" + "DS-A.03.04.02E.b": [ + "CFG-02.8", + "CFG-05.1" ], - "AC-04(20)": [ - "NET-04.11" + "A.03.04.02E.ODP[02]": [ + "CFG-02.8" ], - "AC-04(17)": [ - "NET-04.12" + "DS-A.03.14.11E": [ + "CFG-06.1", + "END-06.2", + "END-06.8" ], - "AC-04(19)": [ - "NET-04.13" + "DS-A.03.14.17E": [ + "MON-01.4", + "MON-01.12", + "MON-11.3" ], - "CA-03": [ - "NET-05" + "DS-A.03.14.19E[01]": [ + "MON-01.5" ], - "SC-07(25)": [ - "NET-05" + "DS-A.03.14.19E[02]": [ + "MON-01.5" ], - "SC-07(26)": [ - "NET-05" + "DS-A.03.14.19E[03]": [ + "MON-01.5" ], - "SC-07(27)": [ - "NET-05.1" + "DS-A.03.14.01E.a[03]": [ + "MON-01.7" ], - "CA-09": [ - "NET-05.2" + "A.03.14.01E.ODP[03]": [ + "MON-01.7" ], - "AC-04(21)": [ - "NET-06" + "DS-A.03.01.08E.b": [ + "MON-01.8" ], - "SC-07(13)": [ - "NET-06.1" + "DS-A.03.11.09E[03]": [ + "MON-01.8" ], - "SC-07(28)": [ - "NET-06.5" + "DS-A.03.14.01E.b[01]": [ + "MON-01.8" ], - "SC-10": [ - "NET-07" + "A.03.14.01E.ODP[04]": [ + "MON-01.8" ], - "SI-04(15)": [ - "NET-08.2" + "DS-A.03.14.01E.b[02]": [ + "MON-01.8" ], - "SC-23": [ - "NET-09" + "A.03.14.01E.ODP[05]": [ + "MON-01.8" ], - "SC-23(01)": [ - "NET-09.1" + "DS-A.03.14.01E.b[03]": [ + "MON-01.8" ], - "SC-23(03)": [ - "NET-09.2" + "A.03.14.01E.ODP[06]": [ + "MON-01.8" ], - "SC-20": [ - "NET-10" + "DS-A.03.14.18E": [ + "MON-01.12", + "HRS-03" ], - "SC-20(02)": [ - "NET-10" + "A.03.14.18E.ODP[02]": [ + "MON-01.12" ], - "SC-22": [ - "NET-10.1" + "DS-A.03.03.04E": [ + "MON-02.3" ], - "SC-21": [ - "NET-10.2" + "A.03.03.04E.ODP[01]": [ + "MON-02.3" ], - "SC-37": [ - "NET-11" + "A.03.03.04E.ODP[02]": [ + "MON-02.3" ], - "SC-37(01)": [ - "NET-11" + "DS-A.03.03.02E": [ + "MON-05" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "A.03.03.02E.ODP[03]": [ + "MON-05" ], - "SI-10": [ - "NET-12", - "TDA-18" + "A.03.03.02E.ODP[02]": [ + "MON-05" ], - "SC-08(03)": [ - "NET-13" + "A.03.03.02E.ODP[01]": [ + "MON-05.1" ], - "AC-17": [ - "NET-14" + "DS-A.03.03.01E": [ + "MON-08.1" ], - "AC-17(06)": [ - "NET-14" + "DS-A.03.03.03E": [ + "MON-08.4" ], - "AC-17(01)": [ - "NET-14.1" + "A.03.03.03E.ODP[01]": [ + "MON-08.4" ], - "AC-17(02)": [ - "NET-14.2" + "A.03.03.03E.ODP[02]": [ + "MON-08.4" ], - "AC-17(03)": [ - "NET-14.3" + "DS-A.03.01.08E.a": [ + "MON-11.3", + "MON-16" ], - "AC-17(04)": [ - "NET-14.4" + "DS-A.03.11.02E.a.01[01]": [ + "MON-11.3", + "IRO-03" ], - "CA-09(01)": [ - "NET-14.7" + "DS-A.03.11.09E[01]": [ + "MON-11.3" ], - "AC-17(09)": [ - "NET-14.8" + "DS-A.03.11.09E[02]": [ + "MON-11.3" ], - "AC-18(01)": [ - "NET-15.1" + "A.03.14.18E.ODP[03]": [ + "MON-11.3" ], - "AC-18(03)": [ - "NET-15.2" + "DS-A.03.06.03E": [ + "MON-16" ], - "AC-18(04)": [ - "NET-15.3" + "DS-A.03.14.09E[01]": [ + "CRY-01" ], - "AC-18(05)": [ - "NET-15.4" + "DS-A.03.14.09E[02]": [ + "CRY-01" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "DS-A.03.14.09E[03]": [ + "CRY-01" ], - "SI-04(10)": [ - "NET-18.2" + "DS-A.03.01.17E.b": [ + "DCH-01.4" ], - "SC-07(15)": [ - "NET-18.3" + "A.03.01.17E.ODP[01]": [ + "DCH-02" ], - "PE-02": [ - "PES-02" + "A.03.08.01E.ODP[01]": [ + "DCH-09" ], - "PE-02(01)": [ - "PES-02.1" + "DS-A.03.08.01E": [ + "DCH-09.5" ], - "PE-03": [ - "PES-03" + "A.03.08.02E.ODP[01]": [ + "DCH-09.5" ], - "PE-03(02)": [ - "PES-03" + "DS-A.03.01.02E": [ + "DCH-13.4" ], - "PE-03(03)": [ - "PES-03" + "A.03.01.02E.ODP[01]": [ + "DCH-13.4" ], - "PE-03(04)": [ - "PES-03.2" + "A.03.10.01E.ODP[01]": [ + "DCH-18", + "PES-06" ], - "SC-07(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "DS-A.03.14.01E.a[01]": [ + "END-06" ], - "PE-08": [ - "PES-03.3" + "A.03.14.01E.ODP[01]": [ + "END-06" ], - "PE-03(01)": [ - "PES-03.4" + "DS-A.03.14.01E.a[02]": [ + "END-06" ], - "PE-06": [ - "PES-05" + "A.03.14.01E.ODP[02]": [ + "END-06" ], - "PE-06(01)": [ - "PES-05.1" + "DS-A.03.14.08E[01]": [ + "END-06.1" ], - "PE-06(04)": [ - "PES-05.2" + "A.03.14.08E.ODP[02]": [ + "END-06.1" ], - "PE-02(02)": [ - "PES-06.2" + "A.03.14.08E.ODP[04]": [ + "END-06.1" ], - "PE-02(03)": [ - "PES-06.3" + "DS-A.03.14.08E[02]": [ + "END-06.1" ], - "PE-08(01)": [ - "PES-06.4" + "A.03.14.08E.ODP[06]": [ + "END-06.1" ], - "PE-08(03)": [ - "PES-06.5" + "DS-A.03.14.08E[03]": [ + "END-06.1" ], - "PE-09": [ - "PES-07" + "A.03.14.08E.ODP[10]": [ + "END-06.1" ], - "PE-09(02)": [ - "PES-07.1" + "DS-A.03.14.10E": [ + "END-06.6" ], - "PE-10": [ - "PES-07.2" + "A.03.14.10E.ODP[01]": [ + "END-06.6" ], - "PE-11": [ - "PES-07.3" + "DS-A.03.13.06E": [ + "END-10" ], - "PE-11(01)": [ - "PES-07.3" + "DS-A.03.13.11E[01]": [ + "END-11" ], - "PE-11(02)": [ - "PES-07.3" + "DS-A.03.13.13E": [ + "END-12" ], - "PE-12": [ - "PES-07.4" + "A.03.13.13E.ODP[02]": [ + "END-12" ], - "PE-15": [ - "PES-07.5" + "A.03.13.13E.ODP[03]": [ + "END-12" ], - "PE-15(01)": [ - "PES-07.6" + "DS-A.03.09.03E.a": [ + "HRS-01" ], - "PE-09(01)": [ - "PES-07.7" + "A.03.09.04E.ODP[01]": [ + "HRS-01" ], - "PE-13": [ - "PES-08" + "A.03.01.08E.ODP[02]": [ + "HRS-03" ], - "PE-13(01)": [ - "PES-08.1" + "A.03.01.11E.ODP[01]": [ + "HRS-03" ], - "PE-13(02)": [ - "PES-08.2", - "PES-08.3" + "A.03.14.17E.ODP[01]": [ + "HRS-03" ], - "PE-14": [ - "PES-09" + "A.03.14.18E.ODP[01]": [ + "HRS-03" ], - "PE-14(02)": [ - "PES-09.1" + "A.03.17.03E.ODP[03]": [ + "HRS-03" ], - "PE-16": [ - "PES-10" + "DS-A.03.09.04E": [ + "HRS-04.3" ], - "PE-17": [ - "PES-11" + "DS-A.03.09.03E.c.01": [ + "HRS-06" ], - "PE-18": [ - "PES-12" + "DS-A.03.01.01E": [ + "HRS-12.1", + "IAC-20.5" ], - "PE-04": [ - "PES-12.1" + "A.03.01.01E.ODP[01]": [ + "HRS-12.1", + "IAC-20.5" ], - "PE-05": [ - "PES-12.2" + "DS-A.03.05.07E[01]": [ + "IAC-01.4" ], - "PE-19": [ - "PES-13" + "A.03.05.07E.ODP[02]": [ + "IAC-01.4" ], - "PE-20": [ - "PES-14" + "DS-A.03.05.07E[02]": [ + "IAC-01.4" ], - "PE-21": [ - "PES-15" + "DS-A.03.05.07E[03]": [ + "IAC-01.4" ], - "PM-18": [ - "PRI-01" + "DS-A.03.05.01E": [ + "IAC-04" ], - "PM-19": [ - "PRI-01.1" + "DS-A.03.05.03E": [ + "IAC-04" ], - "PT-05(02)": [ - "PRI-01.2" + "A.03.05.03E.ODP[01]": [ + "IAC-04.1" ], - "PM-20": [ - "PRI-01.3" + "DS-A.03.01.11E.a": [ + "IAC-08", + "IAC-15.1" ], - "PM-20(01)": [ - "PRI-02" + "DS-A.03.01.11E.b": [ + "IAC-08" ], - "PT-05": [ - "PRI-02" + "A.03.05.02E.ODP[02]": [ + "IAC-10.1" ], - "PT-03": [ - "PRI-02.1", - "PRI-05.1" + "A.03.05.02E.ODP[01]": [ + "IAC-10.4" ], - "PT-02(02)": [ - "PRI-02.2" + "DS-A.03.05.02E.b": [ + "IAC-10.5" ], - "PT-03(02)": [ - "PRI-02.2", - "PRI-10.1" + "DS-A.03.05.04E": [ + "IAC-10.6" ], - "PT-08": [ - "PRI-02.3" + "A.03.05.05E.ODP[01]": [ + "IAC-10.10" ], - "PT-06": [ - "PRI-02.4" + "DS-A.03.05.02E.a": [ + "IAC-10.11" ], - "PT-06(01)": [ - "PRI-02.5" + "DS-A.03.01.07E[01]": [ + "IAC-15.1", + "IAC-15.4" ], - "PT-06(02)": [ - "PRI-02.6" + "DS-A.03.01.07E[02]": [ + "IAC-15.1", + "IAC-15.4" ], - "PT-04": [ - "PRI-03" + "DS-A.03.01.07E[03]": [ + "IAC-15.1", + "IAC-15.4" ], - "PT-04(01)": [ - "PRI-03.1" + "DS-A.03.01.07E[04]": [ + "IAC-15.1", + "IAC-15.4" ], - "PT-04(02)": [ - "PRI-03.2" + "DS-A.03.01.07E[05]": [ + "IAC-15.1", + "IAC-15.4" ], - "PT-05(01)": [ - "PRI-03.2" + "DS-A.03.01.04E": [ + "IAC-23" ], - "PT-04(03)": [ - "PRI-03.4" + "A.03.01.04E.ODP[02]": [ + "IAC-23", + "IAO-03" ], - "PT-02": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "DS-A.03.05.06E.a": [ + "IAC-28" ], - "AC-04(25)": [ - "PRI-05" + "DS-A.03.05.06E.b": [ + "IAC-28" ], - "PT-07": [ - "PRI-05.4", - "PRI-05.7" + "DS-A.03.05.06E.c[01]": [ + "IAC-28" ], - "PM-05(01)": [ - "PRI-05.5", - "PRI-05.6" + "DS-A.03.05.06E.c[02]": [ + "IAC-28" ], - "PT-07(01)": [ - "PRI-05.7" + "DS-A.03.05.06E.c[03]": [ + "IAC-28" ], - "PT-07(02)": [ - "PRI-05.7" + "DS-A.03.01.09E.a[01]": [ + "IAC-29" ], - "AC-03(14)": [ - "PRI-06" + "DS-A.03.01.09E.a[02]": [ + "IAC-29" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "DS-A.03.01.09E.b": [ + "IAC-29" ], - "PM-27": [ - "PRI-14" + "A.03.01.09E.ODP[01]": [ + "IAC-29" ], - "PM-21": [ - "PRI-14.1" + "A.03.11.09E.ODP[02]": [ + "IRO-01" ], - "PM-03": [ - "PRM-02" + "A.03.17.03E.ODP[02]": [ + "IRO-02" ], - "SA-02": [ - "PRM-03" + "A.03.01.08E.ODP[01]": [ + "IRO-03" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "A.03.02.01E.ODP[01]": [ + "IRO-03" ], - "PM-11": [ - "PRM-06" + "A.03.11.09E.ODP[01]": [ + "IRO-03" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "A.03.14.17E.ODP[02]": [ + "IRO-03" ], - "SA-03(01)": [ - "PRM-07", - "SEA-07.1", - "TDA-07" + "DS-A.03.06.02E[01]": [ + "IRO-07" ], - "SA-08(30)": [ - "PRM-07", - "SEA-07.1" + "A.03.06.02E.ODP[01]": [ + "IRO-07" ], - "PM-09": [ - "RSK-01" + "DS-A.03.06.02E[02]": [ + "IRO-07" ], - "PM-28": [ - "RSK-01.1" + "DS-A.03.06.02E[03]": [ + "IRO-07" ], - "RA-02": [ - "RSK-02" + "DS-A.03.06.04E[01]": [ + "IRO-09.1" ], - "RA-02(01)": [ - "RSK-02.1" + "A.03.06.04E.ODP[01]": [ + "IRO-09.1" ], - "RA-07": [ - "RSK-06.1" + "DS-A.03.06.04E[02]": [ + "IRO-09.1" ], - "PM-30": [ - "RSK-09" + "A.03.06.04E.ODP[02]": [ + "IRO-09.1" ], - "SA-09(03)": [ - "RSK-09", - "TPM-02", - "TPM-03", - "TPM-04.3", - "TPM-05.4", - "TPM-05.7" + "DS-A.03.06.04E[03]": [ + "IRO-09.1" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "A.03.06.04E.ODP[03]": [ + "IRO-09.1" ], - "SR-07": [ - "RSK-09", - "OPS-01" + "DS-A.03.13.14E": [ + "IRO-15" ], - "RA-03(01)": [ - "RSK-09.1" + "DS-A.03.12.02E": [ + "IAO-02.1" ], - "RA-08": [ - "RSK-10" + "DS-A.03.01.06E": [ + "IAO-03", + "NET-14" ], - "CA-07(04)": [ - "RSK-11" + "A.03.13.11E.ODP[01]": [ + "IAO-03" ], - "SC-07(18)": [ - "SEA-01" + "A.03.13.14E.ODP[01]": [ + "IAO-03" ], - "PL-08": [ - "SEA-02" + "A.03.13.16E.ODP[03]": [ + "IAO-03" ], - "PM-07": [ - "SEA-02" + "A.03.14.08E.ODP[01]": [ + "IAO-03" ], - "PM-07(01)": [ - "SEA-02.2" + "A.03.14.08E.ODP[03]": [ + "IAO-03" ], - "PL-08(01)": [ - "SEA-03" + "A.03.14.08E.ODP[05]": [ + "IAO-03" ], - "SC-03(05)": [ - "SEA-03" + "A.03.14.08E.ODP[07]": [ + "IAO-03" ], - "SC-32": [ - "SEA-03.1" + "A.03.14.08E.ODP[11]": [ + "IAO-03" ], - "SC-02": [ - "SEA-03.2" + "A.03.14.10E.ODP[02]": [ + "IAO-03" ], - "SC-02(01)": [ - "SEA-03.2" + "A.03.14.14E.ODP[01]": [ + "IAO-03" ], - "SC-39": [ - "SEA-04" + "A.03.14.15E.ODP[01]": [ + "IAO-03" ], - "SC-39(01)": [ - "SEA-04.2" + "A.03.14.16E.ODP[01]": [ + "IAO-03" ], - "SC-39(02)": [ - "SEA-04.3" + "DS-A.03.15.01E.a.01": [ + "IAO-03", + "SEA-01.4", + "SEA-01.5" ], - "SC-04": [ - "SEA-05" + "DS-A.03.15.01E.a.03": [ + "IAO-03" ], - "SA-03(03)": [ - "SEA-07.1", - "SEA-08.1" + "DS-A.03.15.01E.b": [ + "IAO-03" ], - "CP-12": [ - "SEA-07.2" + "DS-A.03.15.01E.c": [ + "IAO-03" ], - "SA-08(24)": [ - "SEA-07.2" + "DS-A.03.15.02E.b": [ + "IAO-03" ], - "SC-24": [ - "SEA-07.2" + "A.03.15.02E.ODP[01]": [ + "IAO-03" ], - "SI-17": [ - "SEA-07.3" + "A.03.15.03E.ODP[01]": [ + "IAO-03" ], - "SI-14": [ - "SEA-08" + "A.03.15.03E.ODP[02]": [ + "IAO-03" ], - "SI-14(01)": [ - "SEA-08.1" + "A.03.16.01E.ODP[02]": [ + "IAO-03" ], - "SI-15": [ - "SEA-09" + "A.03.17.02E.ODP[01]": [ + "IAO-03" ], - "SI-16": [ - "SEA-10" + "DS-A.03.07.01E": [ + "MNT-04" ], - "SC-26": [ - "SEA-11" + "DS-A.03.13.12E.a": [ + "NET-02.1" ], - "SC-35": [ - "SEA-12" + "A.03.13.12E.ODP[01]": [ + "NET-02.1" ], - "SC-29": [ - "SEA-13" + "A.03.13.12E.ODP[02]": [ + "NET-02.1" ], - "SC-29(01)": [ - "SEA-13.1" + "A.03.13.12E.ODP[03]": [ + "NET-02.1" ], - "SC-30": [ - "SEA-14" + "A.03.01.12E.ODP[01]": [ + "NET-03", + "NET-06" ], - "SC-30(04)": [ - "SEA-14" + "DS-A.03.13.04E": [ + "NET-03" ], - "SC-30(05)": [ - "SEA-14" + "A.03.13.04E.ODP[01]": [ + "NET-03.7" ], - "SC-30(02)": [ - "SEA-14.1" + "DS-A.03.13.10E": [ + "NET-03.8" ], - "SC-30(03)": [ - "SEA-14.2" + "DS-A.03.13.15E": [ + "NET-03.8", + "NET-06.1", + "NET-06.9" ], - "SC-36": [ - "SEA-15" + "DS-A.03.01.10E": [ + "NET-04.2" ], - "SC-34": [ - "SEA-16" + "A.03.01.10E.ODP[01]": [ + "NET-04.2" ], - "AC-08": [ - "SEA-18" + "A.03.01.10E.ODP[02]": [ + "NET-04.2" ], - "AC-09": [ - "SEA-19" + "A.03.01.10E.ODP[03]": [ + "NET-04.2" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "A.03.01.10E.ODP[04]": [ + "NET-04.2" ], - "SA-08(32)": [ - "OPS-01.1" + "A.03.01.13E.ODP[01]": [ + "NET-04.5" ], - "PL-07": [ - "OPS-02" + "A.03.01.10E.ODP[05]": [ + "NET-04.7" ], - "IR-04(14)": [ - "OPS-04" + "DS-A.03.01.13E": [ + "NET-04.7", + "NET-04.8" ], - "AT-02": [ - "SAT-02" + "DS-A.03.01.14E.a": [ + "NET-04.7", + "NET-04.8" ], - "AT-02(01)": [ - "SAT-02.1" + "A.03.01.14E.ODP[01]": [ + "NET-04.7" ], - "AT-06": [ - "SAT-02.1" + "DS-A.03.01.14E.b": [ + "NET-04.7" ], - "AT-02(03)": [ - "SAT-02.2" + "DS-A.03.01.15E": [ + "NET-04.8" ], - "AT-03": [ - "SAT-03" + "A.03.01.15E.ODP[01]": [ + "NET-04.8" ], - "AT-03(02)": [ - "SAT-03" + "A.03.01.16E.ODP[01]": [ + "NET-04.9" ], - "AT-03(03)": [ - "SAT-03.1" + "DS-A.03.01.17E.a": [ + "NET-04.10", + "NET-17" ], - "AT-02(04)": [ - "SAT-03.2" + "DS-A.03.12.04E.a": [ + "NET-05" ], - "AT-02(05)": [ - "SAT-03.2" + "A.03.12.04E.ODP[01]": [ + "NET-05" ], - "AT-03(05)": [ - "SAT-03.3" + "DS-A.03.12.04E.b[01]": [ + "NET-05" ], - "AT-02(06)": [ - "SAT-03.6" + "DS-A.03.12.04E.b[02]": [ + "NET-05" ], - "AT-04": [ - "SAT-04" + "DS-A.03.12.04E.b[03]": [ + "NET-05" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "A.03.12.04E.ODP[02]": [ + "NET-05" ], - "SA-23": [ - "TDA-01", - "TDA-01.1", - "TDA-12" + "DS-A.03.12.04E.d": [ + "NET-05" ], - "SA-04(09)": [ - "TDA-02.1" + "DS-A.03.01.12E": [ + "NET-06" ], - "SA-04(07)": [ - "TDA-02.2" + "DS-A.03.13.09E": [ + "NET-06.1" ], - "SA-04(10)": [ - "TDA-02.2" + "A.03.13.09E.ODP[01]": [ + "NET-06.9" ], - "SA-04(03)": [ - "TDA-02.3", - "TDA-06" + "A.03.13.15E.ODP[01]": [ + "NET-06.9" ], - "SR-03(01)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "A.03.13.15E.ODP[02]": [ + "NET-06.9" ], - "SA-04(05)": [ - "TDA-02.4" + "DS-A.03.01.05E[01]": [ + "NET-14.1" ], - "SA-10(07)": [ - "TDA-02.7" + "DS-A.03.01.05E[02]": [ + "NET-14.1" ], - "SA-15(13)": [ - "TDA-02.14" + "DS-A.03.10.01E[02]": [ + "PES-05", + "PES-05.1" ], - "SA-04(06)": [ - "TDA-03" + "DS-A.03.10.02E.b": [ + "PES-05" ], - "PL-08(02)": [ - "TDA-03.1" + "DS-A.03.10.01E[01]": [ + "PES-05.2" ], - "SA-17": [ - "TDA-05" + "DS-A.03.10.02E.a[01]": [ + "PES-10" ], - "SA-15": [ - "TDA-06" + "A.03.10.02E.ODP[01]": [ + "PES-10" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "DS-A.03.10.02E.a[02]": [ + "PES-10" ], - "SA-15(03)": [ - "TDA-06.1" + "DS-A.03.10.02E.a[03]": [ + "PES-10" ], - "SA-11(02)": [ - "TDA-06.2", - "TDA-15" + "A.03.10.02E.ODP[02]": [ + "PES-10" ], - "SA-15(08)": [ - "TDA-06.2" + "DS-A.03.10.02E.a[04]": [ + "PES-10" ], - "SI-02(07)": [ - "TDA-06.6" + "A.03.11.10E.ODP[02]": [ + "PRM-04" ], - "CM-04(01)": [ - "TDA-08" + "A.03.13.01E.ODP[01]": [ + "PRM-05", + "PRM-06" ], - "SA-11": [ - "TDA-09" + "A.03.13.02E.ODP[01]": [ + "PRM-05" ], - "SA-11(06)": [ - "TDA-09", - "VPM-01.1" + "A.03.13.03E.ODP[01]": [ + "PRM-05" ], - "SA-11(07)": [ - "TDA-09", - "VPM-01.1" + "DS-A.03.12.03E[01]": [ + "RSK-11" ], - "SA-04(08)": [ - "TDA-09.1" + "DS-A.03.15.01E.a.02": [ + "SEA-01.4", + "SEA-01.5", + "SEA-02" ], - "SA-11(01)": [ - "TDA-09.2" + "DS-A.03.15.02E.a": [ + "SEA-03" ], - "SA-11(08)": [ - "TDA-09.3" + "A.03.15.02E.ODP[02]": [ + "SEA-03" ], - "SA-11(04)": [ - "TDA-09.7" + "DS-A.03.15.02E.c": [ + "SEA-03" ], - "SA-03(02)": [ - "TDA-10" + "DS-A.03.13.16E": [ + "SEA-03.1" ], - "SR-04(03)": [ - "TDA-11" + "A.03.13.16E.ODP[01]": [ + "SEA-03.1" ], - "SR-04(04)": [ - "TDA-11" + "A.03.13.16E.ODP[02]": [ + "SEA-03.1" ], - "SR-11": [ - "TDA-11" + "DS-A.03.14.15E.a": [ + "SEA-08" ], - "SR-11(03)": [ - "TDA-11" + "DS-A.03.14.15E.b": [ + "SEA-08" ], - "SR-11(01)": [ - "TDA-11.1" + "DS-A.03.14.15E.c": [ + "SEA-08" ], - "SA-20": [ - "TDA-12" + "A.03.14.15E.ODP[02]": [ + "SEA-08" ], - "SA-21": [ - "TDA-13" + "DS-A.03.14.04E": [ + "SEA-08.1" ], - "SA-10": [ - "TDA-14" + "A.03.14.04E.ODP[01]": [ + "SEA-08.1" ], - "SA-10(01)": [ - "TDA-14.1" + "DS-A.03.14.05E.a": [ + "SEA-08.2" ], - "SA-10(03)": [ - "TDA-14.2" + "A.03.14.05E.ODP[01]": [ + "SEA-08.2" ], - "SA-16": [ - "TDA-16" + "DS-A.03.14.05E.b": [ + "SEA-08.2" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "DS-A.03.14.14E": [ + "SEA-10" ], - "SI-11": [ - "TDA-19" + "DS-A.03.13.08E[01]": [ + "SEA-11" ], - "SR-02(01)": [ - "TPM-03" + "DS-A.03.13.08E[02]": [ + "SEA-11" ], - "SR-05": [ - "TPM-03.1" + "DS-A.03.13.08E[03]": [ + "SEA-11" ], - "SR-03(02)": [ - "TPM-03.2" + "DS-A.03.13.01E": [ + "SEA-13" ], - "SR-03": [ - "TPM-03.3" + "DS-A.03.13.07E": [ + "SEA-13.1" ], - "SR-05(01)": [ - "TPM-03.4" + "DS-A.03.13.03E": [ + "SEA-14" ], - "SA-09": [ - "TPM-04" + "DS-A.03.13.02E": [ + "SEA-14.1" ], - "SA-09(01)": [ - "TPM-04.1" + "DS-A.03.13.05E": [ + "SEA-14.2" ], - "SA-09(02)": [ - "TPM-04.2" + "A.03.13.05E.ODP[01]": [ + "SEA-14.2" ], - "SA-09(04)": [ - "TPM-04.3" + "A.03.02.01E.ODP[02]": [ + "OPS-01.1" ], - "SR-03(03)": [ - "TPM-05", - "TPM-05.2" + "A.03.08.03E.ODP[01]": [ + "OPS-01.1" ], - "SR-08": [ - "TPM-05.1" + "A.03.08.03E.ODP[02]": [ + "OPS-01.1" ], - "SR-06": [ - "TPM-08" + "DS-A.03.09.03E.b[01]": [ + "OPS-01.1" ], - "SR-06(01)": [ - "TPM-08" + "A.03.09.03E.ODP[01]": [ + "OPS-01.1" ], - "PM-16": [ - "THR-01" + "DS-A.03.09.03E.b[02]": [ + "OPS-01.1" ], - "PM-16(01)": [ - "THR-03" + "DS-A.03.09.03E.c.02": [ + "OPS-01.1" ], - "SI-05(01)": [ - "THR-03" + "A.03.09.03E.ODP[02]": [ + "OPS-01.1" ], - "PM-12": [ - "THR-04" + "A.03.11.02E.ODP[01]": [ + "OPS-01.1" ], - "AT-02(02)": [ - "THR-05" + "A.03.12.01E.ODP[01]": [ + "OPS-01.1" ], - "RA-05(11)": [ - "THR-06" + "A.03.12.04E.ODP[03]": [ + "OPS-01.1" ], - "RA-10": [ - "THR-07" + "A.03.13.05E.ODP[02]": [ + "OPS-01.1" ], - "SI-20": [ - "THR-08" + "A.03.13.05E.ODP[03]": [ + "OPS-01.1" ], - "SI-02(04)": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "A.03.13.07E.ODP[01]": [ + "OPS-01.1" ], - "SI-02(02)": [ - "VPM-05.2" + "A.03.14.05E.ODP[02]": [ + "OPS-01.1" ], - "SI-02(03)": [ - "VPM-05.3" + "A.03.14.05E.ODP[03]": [ + "OPS-01.1" ], - "SI-02(05)": [ - "VPM-05.4" + "A.03.14.05E.ODP[04]": [ + "OPS-01.1" ], - "SI-02(06)": [ - "VPM-05.5" + "A.03.14.08E.ODP[08]": [ + "OPS-01.1" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "A.03.14.08E.ODP[09]": [ + "OPS-01.1" ], - "RA-05(02)": [ - "VPM-06.1" + "A.03.14.08E.ODP[12]": [ + "OPS-01.1" ], - "RA-05(03)": [ - "VPM-06.2" + "A.03.14.15E.ODP[03]": [ + "OPS-01.1" ], - "RA-05(05)": [ - "VPM-06.3" + "A.03.15.01E.ODP[01]": [ + "OPS-01.1" ], - "RA-05(06)": [ - "VPM-06.4" + "A.03.17.02E.ODP[02]": [ + "OPS-01.1" ], - "RA-05(08)": [ - "VPM-06.5" + "A.03.17.02E.ODP[03]": [ + "OPS-01.1" ], - "RA-05(04)": [ - "VPM-06.8" + "DS-A.03.06.01E[01]": [ + "OPS-04" ], - "RA-05(10)": [ - "VPM-06.9" + "DS-A.03.06.01E[02]": [ + "OPS-04" ], - "CA-08": [ - "VPM-07" + "DS-A.03.02.01E.b[01]": [ + "SAT-01.1" ], - "CA-08(01)": [ - "VPM-07.1" + "DS-A.03.02.01E.b[02]": [ + "SAT-01.1" ], - "RA-06": [ - "VPM-08" + "A.03.02.01E.ODP[03]": [ + "SAT-01.1" ], - "CA-08(02)": [ - "VPM-10" + "DS-A.03.02.02E": [ + "SAT-02.1" ], - "SC-07(17)": [ - "WEB-03" - ] - }, - "general-nist-800-82-r3-low": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "DS-A.03.02.01E.a.02": [ + "SAT-03", + "SAT-03.2" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "A.03.02.04E.ODP[01]": [ + "SAT-03" ], - "AT-01": [ - "GOV-02" + "DS-A.03.02.01E.a.01": [ + "SAT-03.6" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "DS-A.03.02.01E.a.03": [ + "SAT-03.6" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "DS-A.03.02.03E": [ + "SAT-04.1" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "DS-A.03.16.01E": [ + "TDA-01", + "TDA-01.1" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "A.03.16.01E.ODP[01]": [ + "TDA-01.1" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "DS-A.03.15.03E": [ + "TDA-03.1" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "A.03.11.10E.ODP[01]": [ + "TDA-06.1", + "TPM-02" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "DS-A.03.17.03E.b": [ + "TDA-11" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "A.03.17.03E.ODP[01]": [ + "TDA-11" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "DS-A.03.17.05E[01]": [ + "TDA-11" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "TDA-01" + "A.03.17.05E.ODP[01]": [ + "TDA-11" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "DS-A.03.17.05E[02]": [ + "TDA-11" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "DS-A.03.02.04E": [ + "TDA-11.1" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "DS-A.03.14.12E": [ + "TDA-18" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "A.03.14.12E.ODP[01]": [ + "TDA-18" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "DS-A.03.14.13E.a": [ + "TDA-19" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "DS-A.03.14.13E.b": [ + "TDA-19" ], - "PM-02": [ - "GOV-04" + "A.03.14.13E.ODP[01]": [ + "TDA-19.1" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "A.03.17.01E.ODP[02]": [ + "TPM-05" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "DS-A.03.17.01E": [ + "TPM-05.1" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "A.03.17.01E.ODP[01]": [ + "TPM-05.1" ], - "PM-15": [ - "GOV-07", + "DS-A.03.11.01E": [ "THR-01" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "DS-A.03.11.08E": [ + "THR-01.1" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "A.03.11.08E.ODP[01]": [ + "THR-01.1" ], - "PM-32": [ - "GOV-11" + "DS-A.03.11.03E[01]": [ + "THR-01.2" ], - "PM-05": [ - "AST-01", - "AST-02" + "A.03.11.03E.ODP[01]": [ + "THR-01.2" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "A.03.11.03E.ODP[02]": [ + "THR-01.2" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "DS-A.03.11.03E[02]": [ + "THR-01.2" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "A.03.11.03E.ODP[03]": [ + "THR-01.2" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "DS-A.03.11.12E": [ + "THR-03" ], - "SR-12": [ - "AST-09" + "DS-A.03.11.02E.a.01[02]": [ + "THR-07" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "DS-A.03.11.02E.a.02[01]": [ + "THR-07" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "DS-A.03.11.02E.a.02[02]": [ + "THR-07" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "DS-A.03.11.02E.b": [ + "THR-07" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "DS-A.03.14.16E": [ + "THR-08" ], - "CP-03": [ - "BCD-03" + "A.03.12.01E.ODP[02]": [ + "VPM-01.1" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "A.03.11.11E.ODP[01]": [ + "VPM-02" ], - "CP-09": [ - "BCD-11" + "DS-A.03.11.11E[02]": [ + "VPM-02" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "DS-A.03.11.11E[01]": [ + "VPM-06.8" ], - "CM-04": [ - "CHG-03" + "DS-A.03.12.01E": [ + "VPM-07" + ] + }, + "general-nist-800-207": { + "NIST Tenet 7": [ + "GOV-05", + "AST-02.6", + "AST-02.8", + "AST-02.9", + "MON-01", + "MON-01.2", + "MON-01.4", + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-02.3", + "DCH-24.1", + "NET-14.7", + "THR-01", + "THR-03" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "NIST Tenet 1": [ + "AST-01", + "AST-01.1", + "AST-02", + "AST-02.3", + "AST-02.8", + "AST-02.9", + "AST-04", + "AST-04.1", + "CLD-01", + "CLD-13", + "DCH-01", + "DCH-02", + "DCH-06.2", + "DCH-13.4", + "DCH-24", + "MDM-01", + "MDM-02", + "MDM-06", + "MDM-07", + "PRI-05.5", + "TPM-01.1" ], - "SC-07(29)": [ - "CLD-03" + "NIST Tenet 5": [ + "AST-01", + "AST-02.2", + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.4", + "CFG-01", + "CFG-02", + "CFG-02.1", + "CFG-02.2", + "CFG-02.7", + "CFG-02.8", + "CFG-06", + "CFG-06.1", + "MON-01", + "MON-01.2", + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-02.3", + "DCH-13.1", + "NET-01.1", + "NET-08.3", + "NET-08.4", + "NET-14.1", + "NET-14.7" ], - "CA-07": [ - "CPL-02" + "NIST Tenet 6": [ + "AST-02.2", + "AST-02.5", + "AST-02.9", + "MON-01", + "IAC-01", + "IAC-01.2", + "IAC-06", + "NET-01.1" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "NIST Tenet 4": [ + "CFG-08", + "MON-02.3", + "MON-02.4", + "MON-16", + "DCH-01.2", + "DCH-01.4", + "DCH-13.3", + "DCH-14.2", + "DCH-24.1", + "DCH-25", + "DCH-25.1", + "END-01", + "IAC-01.2", + "IAC-03", + "IAC-04", + "IAC-05", + "IAC-05.2", + "IAC-08", + "IAC-09", + "IAC-13.2", + "IAC-15.1", + "MDM-09", + "NET-02.3", + "NET-04", + "NET-04.1", + "NET-04.7", + "NET-04.12", + "NET-08.3", + "NET-08.4", + "NET-14.7" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "NIST Tenet 2": [ + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-07", + "CRY-08", + "IAC-01.2", + "IAC-04", + "NET-01", + "NET-14.2", + "NET-14.5", + "NET-15" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "NIST Tenet 3": [ + "DCH-01.4", + "DCH-13.3", + "DCH-14.2", + "IAC-01.2", + "IAC-02", + "IAC-03", + "IAC-04", + "IAC-05", + "IAC-08", + "IAC-15.1", + "IAC-20.1", + "IAC-21", + "IAC-21.2", + "NET-01.1" + ] + }, + "general-nist-800-218": { + "PO.2.3": [ + "GOV-04", + "GOV-04.1" ], - "CM-02": [ + "PS.1": [ + "CHG-04", + "CHG-04.5" + ], + "PO.1": [ + "CPL-01", + "CPL-01.2", + "PRI-07.1", + "PRM-05", + "PRM-07", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-02.3", + "TDA-06", + "TPM-05" + ], + "PO.1.2": [ + "CPL-01", + "TDA-01.1", + "TDA-02" + ], + "PO.5.2": [ "CFG-02", - "CFG-02.1" + "CFG-02.4", + "CFG-02.5" ], - "CM-06": [ + "PW.9.1": [ "CFG-02", - "CFG-02.7" + "TDA-02", + "TDA-02.4", + "TDA-09.6" ], - "PL-10": [ - "CFG-02" + "PO.5": [ + "CFG-02.4", + "TDA-07", + "TDA-08", + "TDA-08.1" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "PO.2.1": [ + "HRS-01", + "HRS-03" + ], + "PO.2": [ + "HRS-03", + "HRS-03.2" + ], + "RV.3": [ + "IRO-13", + "TDA-01.1" ], - "PL-11": [ - "CFG-02.9" + "PO.1.1": [ + "PRM-05", + "TDA-01.1", + "TDA-02" ], - "CM-07": [ - "CFG-03" + "PO.3.2": [ + "OPS-01.1", + "OPS-03", + "TDA-01", + "TDA-02.3", + "TDA-06.4" ], - "CM-10": [ - "CFG-04" + "PO.4.2": [ + "OPS-01.1", + "TDA-01.1", + "TDA-02.3" ], - "CM-11": [ - "CFG-05" + "PO.2.2": [ + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" ], - "PM-31": [ - "MON-01" + "PO.3": [ + "TDA-01", + "TDA-02.3", + "TDA-06.4" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "RV.3.4": [ + "TDA-01", + "TDA-01.1", + "TDA-02.7", + "TDA-06" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "PW.1.2": [ + "TDA-01.1", + "TDA-02" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "PW.4": [ + "TDA-01.1", + "TDA-02.4", + "TDA-03" ], - "AU-03": [ - "MON-03" + "PW.4.2": [ + "TDA-01.1", + "TDA-05", + "TDA-06", + "TDA-06.3" ], - "AU-04": [ - "MON-04" + "PW.5": [ + "TDA-01.1", + "TDA-02.3", + "TDA-06" ], - "AU-05": [ - "MON-05" + "PW.5.1": [ + "TDA-01.1", + "TDA-02", + "TDA-02.4", + "TDA-06", + "TDA-09", + "TDA-09.6" ], - "AU-12": [ - "MON-06" + "PW.6.2": [ + "TDA-01.1", + "TDA-06", + "TDA-06.4" ], - "AU-08": [ - "MON-07", - "SEA-20" + "PW.8.1": [ + "TDA-01.1", + "TDA-09" ], - "SC-45": [ - "MON-07.1" + "RV.2.2": [ + "TDA-01.1", + "TDA-06.2", + "TDA-09", + "VPM-02" ], - "AU-09": [ - "MON-08" + "RV.3.3": [ + "TDA-01.1", + "TDA-09" ], - "AU-04(01)": [ - "MON-08.1" + "PW.1.3": [ + "TDA-02", + "TDA-06", + "TDA-09.6" ], - "AU-11": [ - "MON-10" + "PW.2": [ + "TDA-02", + "TDA-02.3", + "TDA-02.6", + "TDA-02.7", + "TDA-06.3", + "TDA-06.5" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "PW.4.4": [ + "TDA-02", + "TDA-02.1", + "TDA-02.5", + "TDA-02.6", + "TDA-04.2" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "PW.9.2": [ + "TDA-02", + "TDA-02.4", + "TDA-09.6" ], - "AC-18": [ - "CRY-07", - "NET-15" + "PO.3.1": [ + "TDA-02.3", + "TDA-06.4" ], - "SC-12": [ - "CRY-08" + "PO.3.3": [ + "TDA-02.3", + "TDA-02.5", + "TDA-04", + "TDA-04.1" ], - "MP-02": [ - "DCH-03", - "END-01" + "PW.6.1": [ + "TDA-02.3", + "TDA-06", + "TDA-06.4" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "RV.1": [ + "TDA-02.3", + "TDA-02.7", + "TDA-06.5", + "TDA-09", + "TDA-09.1" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "RV.2": [ + "TDA-02.3", + "TDA-09" ], - "AC-20": [ - "DCH-13" + "PW.4.1": [ + "TDA-03" ], - "PM-17": [ - "DCH-13.3" + "PS.3.2": [ + "TDA-04", + "TDA-04.2" ], - "AC-22": [ - "DCH-15" + "RV.1.1": [ + "TDA-04", + "TDA-04.1", + "TDA-04.2", + "TDA-05" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "PW.1": [ + "TDA-06", + "TDA-06.1", + "TDA-06.2", + "TDA-06.3" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "PW.1.1": [ + "TDA-06.2" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "PO.4": [ + "TDA-06.5", + "TDA-09", + "TDA-09.2", + "TDA-09.3" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "PW.2.1": [ + "TDA-06.5" ], - "SC-41": [ - "END-12" + "RV.1.2": [ + "TDA-06.5" ], - "SC-15": [ - "END-14" + "PO.5.1": [ + "TDA-07", + "TDA-08" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "PO.4.1": [ + "TDA-09" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "PW.6": [ + "TDA-09", + "TDA-09.6" ], - "PS-09": [ - "HRS-03" + "PW.7": [ + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5" ], - "PS-03": [ - "HRS-04" + "PW.7.1": [ + "TDA-09" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "PW.8.2": [ + "TDA-09" ], - "PL-04(01)": [ - "HRS-05.2" + "RV.2.1": [ + "TDA-09" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "RV.3.1": [ + "TDA-09" ], - "PS-08": [ - "HRS-07" + "RV.3.2": [ + "TDA-09" ], - "PS-05": [ - "HRS-08" + "PW.7.2": [ + "TDA-09.2", + "TDA-09.3" ], - "PS-04": [ - "HRS-09" + "PW.8": [ + "TDA-09.4", + "TDA-09.5" ], - "PS-07": [ - "HRS-10" + "PW.9": [ + "TDA-09.6" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "PS.1.1": [ + "TDA-20" ], - "IA-02": [ - "IAC-02" + "PS.2": [ + "TDA-20.1" ], - "IA-02(08)": [ - "IAC-02.2" + "PS.2.1": [ + "TDA-20.1" ], - "IA-02(12)": [ - "IAC-02.3" + "PS.3": [ + "TDA-20.2" ], - "IA-08": [ - "IAC-03" + "PS.3.1": [ + "TDA-20.2", + "TDA-20.3" ], - "IA-08(01)": [ - "IAC-03.1" + "RV.1.3": [ + "THR-06" + ] + }, + "general-nist-csf-2-0": { + "GV": [ + "GOV-01", + "GOV-05", + "PRM-01.1", + "RSK-01" ], - "IA-08(02)": [ - "IAC-03.2" + "GV.RM-01": [ + "GOV-01", + "GOV-01.1", + "GOV-05.2", + "RSK-01" ], - "IA-08(04)": [ - "IAC-03.3" + "GV.RM-03": [ + "GOV-01", + "GOV-01.1", + "RSK-01" ], - "IA-03": [ - "IAC-04" + "GV.RR-01": [ + "GOV-01", + "GOV-01.1", + "GOV-04", + "GOV-04.1", + "RSK-01", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-12" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "GV.SC": [ + "GOV-01", + "GOV-01.1", + "GOV-01.2", + "GOV-05", + "RSK-01", + "RSK-09", + "RSK-09.1", + "TPM-03" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "GV.SC-01": [ + "GOV-01", + "GOV-01.1", + "GOV-02", + "RSK-01", + "RSK-09" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "GV.SC-03": [ + "GOV-01", + "GOV-01.1", + "GOV-02", + "GOV-08", + "GOV-09", + "RSK-01", + "RSK-09" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "GV.SC-09": [ + "GOV-01", + "GOV-01.1", + "GOV-01.2", + "GOV-05", + "PRM-07", + "RSK-01", + "RSK-09", + "RSK-09.1", + "SEA-07.1", + "TDA-01.1" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "ID.RA": [ + "GOV-01", + "GOV-01.1", + "GOV-02", + "RSK-01", + "RSK-09" ], - "IA-06": [ - "IAC-11" + "PR": [ + "GOV-01", + "GOV-01.1", + "CPL-01", + "RSK-01", + "RSK-09" ], - "IA-11": [ - "IAC-14" + "PR.IR": [ + "GOV-01", + "GOV-01.1", + "RSK-01", + "SEA-01", + "SEA-01.1", + "SEA-01.2", + "SEA-02" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "GV.OV": [ + "GOV-01.1", + "GOV-01.2", + "GOV-03", + "GOV-05" ], - "AC-07": [ - "IAC-22" + "GV.OV-01": [ + "GOV-01.1", + "GOV-01.2", + "GOV-03", + "GOV-05", + "GOV-08", + "PRM-01.1" ], - "AC-14": [ - "IAC-26" + "GV.OV-02": [ + "GOV-01.1", + "GOV-03", + "RSK-01" ], - "IR-04": [ - "IRO-02" + "GV.OV-03": [ + "GOV-01.1", + "GOV-01.2", + "GOV-05", + "RSK-01" ], - "IR-08": [ - "IRO-04" + "ID": [ + "GOV-01.1", + "GOV-01.2", + "RSK-01", + "RSK-01.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-09" ], - "IR-02": [ - "IRO-05" + "GV.PO": [ + "GOV-02", + "HRS-05.7", + "HRS-07" ], - "IR-05": [ - "IRO-09" + "GV.PO-01": [ + "GOV-02", + "HRS-05.7", + "HRS-07" ], - "IR-07": [ - "IRO-11" + "ID.RA-07": [ + "GOV-02.1", + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "CHG-03", + "CHG-04" ], - "PM-10": [ - "IAO-01" + "GV.PO-02": [ + "GOV-03", + "HRS-05.7", + "HRS-07" ], - "CA-05": [ - "IAO-05" + "GV.RM": [ + "GOV-04", + "PRM-01", + "PRM-01.1", + "RSK-01", + "RSK-01.1", + "RSK-01.3", + "RSK-01.5" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "GV.RM-05": [ + "GOV-04", + "GOV-04.1", + "HRS-03", + "TPM-05.4" ], - "CA-06": [ - "IAO-07" + "GV.RR-02": [ + "GOV-04", + "HRS-02", + "HRS-03", + "TPM-05.4" ], - "MA-02": [ - "MNT-02" + "ID.IM-03": [ + "GOV-05", + "BCD-05", + "IRO-13" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "ID.RA-02": [ + "GOV-07", + "THR-03" ], - "MA-05": [ - "MNT-06" + "GV.OC": [ + "GOV-08", + "AST-01.1", + "AST-01.2", + "CPL-01", + "TPM-05.4" ], - "SR-11(02)": [ - "MNT-07" + "GV.OC-01": [ + "GOV-08", + "RSK-01.1", + "TDA-06.2" ], - "MA-07": [ - "MNT-08" + "GV.OC-04": [ + "GOV-08", + "BCD-02", + "PRM-01.1", + "TPM-02" ], - "AC-19": [ - "MDM-02" + "DE.AE-04": [ + "GOV-16", + "IRO-02", + "IRO-02.4" ], - "SC-07": [ - "NET-03" + "GV.SC-04": [ + "AST-01", + "AST-01.1", + "TPM-01", + "TPM-01.1", + "TPM-02" ], - "CA-03": [ - "NET-05" + "ID.AM": [ + "AST-01", + "AST-01.1", + "AST-01.2", + "AST-02", + "AST-03", + "AST-03.1", + "HRS-01", + "HRS-03", + "HRS-05", + "HRS-05.1", + "PES-01", + "RSK-02", + "TPM-01", + "TPM-01.1", + "TPM-05.4", + "TPM-06" ], - "CA-09": [ - "NET-05.2" + "ID.AM-08": [ + "AST-01", + "AST-01.2", + "DCH-01", + "DCH-01.1", + "PRM-07", + "SEA-07", + "SEA-07.1" ], - "SC-07(28)": [ - "NET-06.5" + "GV.OC-02": [ + "AST-01.2", + "TPM-05", + "TPM-05.4" ], - "SC-20": [ - "NET-10" + "ID.AM-01": [ + "AST-02", + "TPM-01.1" ], - "SC-22": [ - "NET-10.1" + "ID.AM-02": [ + "AST-02", + "TPM-01.1" ], - "SC-21": [ - "NET-10.2" + "ID.AM-03": [ + "AST-04", + "AST-04.2", + "DCH-19" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "ID.AM-05": [ + "AST-04.1", + "BCD-02", + "DCH-02", + "TPM-02" ], - "AC-17": [ - "NET-14" + "ID.RA-09": [ + "AST-15", + "AST-18", + "TDA-01", + "TDA-01.2", + "TDA-14", + "TDA-14.1", + "TDA-14.2" ], - "AC-17(09)": [ - "NET-14.8" + "GV.SC-08": [ + "BCD-01", + "BCD-01.2", + "IRO-01", + "IRO-02", + "IRO-02.5", + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-09", + "TPM-10", + "TPM-11" ], - "PE-02": [ - "PES-02" + "ID.IM-04": [ + "BCD-01", + "BCD-06", + "IRO-04", + "IRO-04.2" ], - "PE-03": [ - "PES-03" + "PR.IR-02": [ + "BCD-01", + "PES-01", + "PES-07", + "PES-07.5", + "PES-08", + "PES-09", + "SEA-01.2", + "THR-09" ], - "PE-08": [ - "PES-03.3" + "PR.IR-03": [ + "BCD-01", + "SEA-01", + "SEA-01.2", + "SEA-02" ], - "PE-06": [ - "PES-05" + "RS.MA-05": [ + "BCD-01", + "BCD-01.5" ], - "PE-12": [ - "PES-07.4" + "RC": [ + "BCD-01", + "BCD-12" ], - "PE-15": [ - "PES-07.5" + "RC.RP": [ + "BCD-01", + "BCD-01.4", + "BCD-02", + "BCD-02.1" ], - "PE-13": [ - "PES-08" + "RC.RP-02": [ + "BCD-01", + "BCD-01.4", + "BCD-02", + "BCD-02.1" ], - "PE-14": [ - "PES-09" + "RC.RP-04": [ + "BCD-01", + "BCD-01.4", + "BCD-02", + "BCD-02.1" ], - "PE-16": [ - "PES-10" + "RC.CO": [ + "BCD-01.1", + "BCD-01.2" ], - "PM-18": [ - "PRI-01" + "RC.RP-01": [ + "BCD-01.5", + "BCD-12" ], - "PM-19": [ - "PRI-01.1" + "RC.CO-03": [ + "BCD-01.6" ], - "PM-20": [ - "PRI-01.3" + "GV.OC-05": [ + "BCD-02", + "TDA-04.2", + "TPM-02" ], - "PM-20(01)": [ - "PRI-02" + "ID.IM-02": [ + "BCD-05", + "CPL-03", + "CPL-03.2", + "IRO-13", + "IAO-02", + "IAO-02.4", + "IAO-05", + "TDA-09", + "TDA-09.1", + "TPM-04.1", + "TPM-08" ], - "SI-12": [ - "PRI-05" + "PR.DS-11": [ + "BCD-11", + "BCD-11.1", + "BCD-11.5", + "BCD-11.6" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "RC.RP-05": [ + "BCD-12" ], - "PM-27": [ - "PRI-14" + "RC.RP-03": [ + "BCD-13", + "BCD-13.1" ], - "PM-21": [ - "PRI-14.1" + "PR.IR-04": [ + "CAP-01", + "CAP-02", + "CAP-03", + "CAP-04", + "CAP-05" ], - "PM-03": [ - "PRM-02" + "GV.OC-03": [ + "CPL-01", + "CPL-02", + "PRI-01", + "TPM-05", + "TPM-05.2" ], - "SA-02": [ - "PRM-03" + "GV.SC-05": [ + "CPL-01", + "CPL-01.2", + "IAO-03.2", + "PRI-07.1", + "RSK-01", + "RSK-09", + "TPM-05", + "TPM-05.2" ], - "PM-11": [ - "PRM-06" + "ID.IM-01": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-02.4", + "IAO-05", + "TDA-09", + "TDA-09.1", + "TPM-04.1", + "TPM-08" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "PR.PS": [ + "CFG-01", + "CFG-02", + "CFG-02.1", + "CFG-02.5", + "MNT-01", + "MNT-02" ], - "PM-09": [ - "RSK-01" + "PR.PS-01": [ + "CFG-01" ], - "PM-28": [ - "RSK-01.1" + "PR.PS-05": [ + "CFG-01", + "CFG-02", + "CFG-03", + "CFG-03.2", + "CFG-05", + "END-03" ], - "RA-02": [ - "RSK-02" + "PR.DS-10": [ + "CFG-02", + "CRY-01", + "DCH-01", + "IAC-21" ], - "RA-07": [ - "RSK-06.1" + "PR.PS-04": [ + "MON-01", + "MON-01.4", + "MON-03" ], - "PM-30": [ - "RSK-09" + "DE.CM-01": [ + "MON-01", + "MON-01.1", + "MON-01.3", + "MON-01.4", + "MON-01.8" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "DE.CM-03": [ + "MON-01", + "MON-16", + "MON-16.1", + "MON-16.3", + "NET-18" ], - "RA-03(01)": [ - "RSK-09.1" + "DE.CM-06": [ + "MON-01", + "MON-16.2", + "MON-16.4" ], - "CA-07(04)": [ - "RSK-11" + "DE.CM-09": [ + "MON-01", + "MON-01.7", + "END-01", + "END-04", + "END-06" ], - "PM-07": [ - "SEA-02" + "DE.AE": [ + "MON-01", + "MON-01.8", + "MON-01.12", + "IRO-01", + "IRO-02", + "IRO-02.4" ], - "SC-39": [ - "SEA-04" + "DE.AE-06": [ + "MON-01.8", + "MON-01.12", + "MON-02", + "MON-02.1", + "IRO-02", + "IRO-02.4", + "IRO-04", + "IRO-07", + "IRO-09", + "IRO-10" ], - "CP-12": [ - "SEA-07.2" + "DE.AE-03": [ + "MON-02", + "MON-02.1", + "IRO-02", + "IRO-02.5" ], - "SI-17": [ - "SEA-07.3" + "DE.CM": [ + "MON-11.3", + "MON-16", + "IRO-03", + "THR-02" ], - "AC-08": [ - "SEA-18" + "PR.DS-01": [ + "CRY-01", + "CRY-01.1", + "CRY-05", + "DCH-01" ], - "AT-02": [ - "SAT-02" + "PR.DS-02": [ + "CRY-01", + "CRY-03", + "CRY-04", + "DCH-01" ], - "AT-03": [ - "SAT-03" + "PR.DS": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", + "DCH-01.3", + "DCH-01.4", + "DCH-02", + "DCH-03" ], - "AT-04": [ - "SAT-04" + "ID.AM-07": [ + "DCH-06", + "DCH-06.2", + "DCH-06.3", + "PRI-05", + "PRI-05.5" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "GV.RR-04": [ + "HRS-01", + "HRS-03.1" ], - "SA-04(10)": [ - "TDA-02.2" + "PR.AA-05": [ + "HRS-02", + "HRS-11", + "IAC-01", + "IAC-01.2", + "IAC-02", + "IAC-03", + "IAC-04", + "IAC-05", + "IAC-08", + "IAC-21" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "GV.RR": [ + "HRS-03", + "TPM-05.4" ], - "SR-11": [ - "TDA-11" + "PR.AA": [ + "IAC-01", + "IAC-01.2", + "PES-01", + "PES-02", + "PES-03" ], - "SR-11(01)": [ - "TDA-11.1" + "PR.AA-03": [ + "IAC-01.2", + "IAC-02", + "IAC-03", + "IAC-04", + "IAC-05" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "PR.AA-04": [ + "IAC-01.2", + "IAC-02.2", + "IAC-03.5" ], - "SR-02(01)": [ - "TPM-03" + "PR.AA-01": [ + "IAC-02", + "IAC-03", + "IAC-04", + "IAC-05" ], - "SR-05": [ - "TPM-03.1" + "PR.AA-02": [ + "IAC-28" ], - "SR-03": [ - "TPM-03.3" + "RS": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-07", + "IRO-09", + "IRO-10" ], - "SA-09": [ - "TPM-04" + "RS.MI": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "SR-08": [ - "TPM-05.1" + "DE.AE-02": [ + "IRO-02", + "IRO-02.4" ], - "PM-16": [ - "THR-01" + "DE.AE-08": [ + "IRO-02", + "IRO-02.4" ], - "PM-12": [ - "THR-04" + "RS.MA": [ + "IRO-02", + "IRO-04", + "IRO-07" ], - "AT-02(02)": [ - "THR-05" + "RS.MA-01": [ + "IRO-02", + "IRO-02.5", + "IRO-04", + "IRO-07", + "IRO-10" ], - "RA-05(11)": [ - "THR-06" + "RS.MA-02": [ + "IRO-02", + "IRO-04" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "RS.MA-04": [ + "IRO-02", + "IRO-04", + "IRO-07" ], - "RA-05(02)": [ - "VPM-06.1" - ] - }, - "general-nist-800-82-r3-mod": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "RS.AN": [ + "IRO-02", + "IRO-08" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "RS.AN-06": [ + "IRO-02", + "IRO-08", + "IRO-09" ], - "AT-01": [ - "GOV-02" + "RS.CO": [ + "IRO-02", + "IRO-02.5", + "IRO-06.1", + "IRO-09", + "IRO-10", + "IRO-10.2", + "IRO-10.4" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "RS.CO-02": [ + "IRO-02", + "IRO-10", + "IRO-10.2", + "IRO-10.4" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "RS.CO-03": [ + "IRO-02", + "IRO-10", + "IRO-10.2", + "IRO-10.4" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "RS.MI-01": [ + "IRO-02" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "RS.MI-02": [ + "IRO-02" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "RC.RP-06": [ + "IRO-02", + "IRO-09" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "RS.MA-03": [ + "IRO-02.4" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "RS.AN-08": [ + "IRO-02.4" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "RS.AN-07": [ + "IRO-08" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "RS.AN-03": [ + "IRO-13" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "TDA-01" + "RC.CO-04": [ + "IRO-16" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "ID.RA-01": [ + "IAO-01", + "IAO-02", + "IAO-05", + "RSK-04", + "RSK-04.1", + "TDA-09", + "VPM-01", + "VPM-06" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "PR.PS-02": [ + "MNT-01", + "MNT-02", + "MNT-03", + "MNT-03.1", + "PRM-07", + "SEA-07.1", + "TDA-17", + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-05" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "PR.PS-03": [ + "MNT-01", + "MNT-02", + "MNT-03", + "MNT-03.1", + "PRM-07", + "SEA-07.1", + "TDA-17" ], - "SC-01": [ - "GOV-02", - "GOV-03", + "PR.IR-01": [ "NET-01", - "SEA-01" - ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "NET-02", + "SEA-01", + "SEA-02" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "PR.AA-06": [ + "PES-01", + "PES-02", + "PES-02.1", + "PES-03" ], - "PM-02": [ - "GOV-04" + "DE.CM-02": [ + "PES-01", + "PES-03", + "PES-03.3", + "PES-05" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "GV.RR-03": [ + "PRM-01", + "PRM-02", + "PRM-03" ], - "PM-29": [ - "GOV-04", + "GV.RM-04": [ "RSK-01", - "RSK-09" + "RSK-01.1", + "RSK-06", + "RSK-06.1", + "RSK-06.2" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "GV.RM-06": [ + "RSK-01", + "RSK-01.1", + "RSK-04", + "RSK-04.1" ], - "PM-15": [ - "GOV-07", - "THR-01" + "ID.IM": [ + "RSK-01", + "RSK-09", + "OPS-01", + "OPS-01.1" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "GV.RM-07": [ + "RSK-01.1" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "ID.RA-05": [ + "RSK-01.1", + "RSK-02.1", + "RSK-04", + "RSK-05", + "RSK-06", + "RSK-06.1", + "THR-02", + "THR-09", + "THR-10" ], - "PM-32": [ - "GOV-11" + "ID.RA-06": [ + "RSK-01.1", + "RSK-02.1", + "RSK-05", + "RSK-06", + "RSK-06.1", + "RSK-06.2" ], - "PM-05": [ - "AST-01", - "AST-02" + "GV.RM-02": [ + "RSK-01.3", + "RSK-01.5" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "GV.SC-10": [ + "RSK-09", + "TPM-01", + "TPM-05.2", + "TPM-05.3" ], - "CM-08(01)": [ - "AST-02.1" + "PR.AT": [ + "SAT-01", + "SAT-02", + "SAT-03" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "PR.AT-01": [ + "SAT-02", + "SAT-03", + "SAT-03.6" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "PR.AT-02": [ + "SAT-03", + "SAT-03.5", + "SAT-03.6", + "SAT-03.7" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "PR.PS-06": [ + "TDA-01", + "TDA-01.1", + "TDA-06", + "TDA-06.1", + "TDA-06.2", + "TDA-06.3", + "TDA-09" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "GV.SC-06": [ + "TPM-01", + "TPM-02", + "TPM-03", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-04.3", + "TPM-04.4", + "TPM-05", + "TPM-05.2", + "TPM-05.3", + "TPM-05.4", + "TPM-05.5", + "TPM-05.6", + "TPM-05.7", + "TPM-06", + "TPM-09" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "GV.SC-07": [ + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-08", + "TPM-09" ], - "PE-22": [ - "AST-04.1", - "PES-16" + "ID.AM-04": [ + "TPM-01.1" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "ID.RA-10": [ + "TPM-01.1", + "TPM-02", + "TPM-04.1" ], - "SR-12": [ - "AST-09" + "GV.SC-02": [ + "TPM-05", + "TPM-05.2", + "TPM-05.4" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "ID.RA-03": [ + "THR-01", + "THR-02", + "THR-03", + "THR-04", + "THR-05", + "THR-07", + "THR-09" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "ID.RA-08": [ + "THR-01", + "THR-02", + "THR-03", + "VPM-01", + "VPM-02", + "VPM-03" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "DE": [ + "THR-01", + "THR-02", + "THR-03", + "THR-07", + "THR-09", + "THR-10" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "DE.AE-07": [ + "THR-01", + "THR-03", + "THR-10" ], - "CP-02(01)": [ - "BCD-01.1" + "ID.RA-04": [ + "THR-09", + "THR-10" + ] + }, + "general-nist-cswp-39": { + "3": [ + "QTS-03" ], - "CP-02(08)": [ - "BCD-02" + "4": [ + "QTS-06" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "5": [ + "QTS-02", + "QTS-03", + "QTS-04" ], - "CP-03": [ - "BCD-03" + "6": [ + "QTS-03" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "6.4": [ + "CLD-02", + "QTS-06" ], - "CP-04(01)": [ - "BCD-04.1" + "3.1.1": [ + "CPL-01" ], - "CP-06": [ - "BCD-08" + "3.1.2": [ + "CPL-01" ], - "CP-06(01)": [ - "BCD-08.1" + "5.1": [ + "CPL-01" ], - "CP-06(03)": [ - "BCD-08.2" + "3.1": [ + "CRY-01.5" ], - "CP-07": [ - "BCD-09" + "3.3": [ + "CRY-09" ], - "CP-07(01)": [ - "BCD-09.1" + "4.4": [ + "EMB-18" ], - "CP-07(02)": [ - "BCD-09.2" + "6.1": [ + "PRM-01", + "PRM-02", + "PRM-02.1" ], - "CP-07(03)": [ - "BCD-09.3" + "6.5": [ + "PRM-01.2", + "QTS-02.3" ], - "CP-08": [ - "BCD-10" + "5.3": [ + "QTS-03" ], - "CP-08(02)": [ - "BCD-10" + "5.4": [ + "QTS-06" ], - "CP-08(01)": [ - "BCD-10.1" + "6.2": [ + "QTS-06" ], - "CP-09": [ - "BCD-11" + "6.3": [ + "QTS-06" ], - "CP-09(01)": [ - "BCD-11.1" + "5.2": [ + "QTS-06.5" + ] + }, + "general-oecd-privacy-principles-2010": { + "1": [ + "PRI-03", + "PRI-03.7", + "PRI-04.1" ], - "CP-09(08)": [ - "BCD-11.4" + "2": [ + "PRI-10" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "3": [ + "PRI-02.1" ], - "CP-10(02)": [ - "BCD-12.1" + "4": [ + "PRI-03.9", + "PRI-05.4" ], - "CP-10(06)": [ - "BCD-13" + "5": [ + "PRI-01.6" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "6": [ + "PRI-01.3" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "8": [ + "PRI-01", + "PRI-01.1" ], - "CM-03(04)": [ - "CHG-02.3" + "4(a)": [ + "PRI-03" ], - "CM-04": [ - "CHG-03" + "4(b)": [ + "PRI-04.1" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "7(a)": [ + "PRI-06" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "7(b)(i)": [ + "PRI-06.4" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "7(b)(ii)": [ + "PRI-06.4" ], - "CM-03(02)": [ - "CHG-06" + "7(b)(iii)": [ + "PRI-06.4" ], - "SC-07(29)": [ - "CLD-03" + "7(c)": [ + "PRI-06.4" ], - "CA-07": [ - "CPL-02" + "7(d)": [ + "PRI-06.4" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "7(b)": [ + "PRI-06.7" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "7(b)(iv)": [ + "PRI-06.7" + ] + }, + "general-owasp-top-10-2025": { + "A05:2025": [ + "CFG-01", + "CFG-02", + "CFG-03", + "MON-01.7", + "EMB-01", + "EMB-05", + "EMB-06", + "END-16", + "IAO-02.2", + "IAO-04", + "PRI-07.1", + "SEA-01", + "SEA-01.1", + "SEA-03", + "SEA-03.2", + "SEA-04", + "SEA-04.1", + "SEA-04.2", + "SEA-04.3", + "SEA-05", + "SEA-06", + "SEA-07.2", + "SEA-08", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5", + "TPM-01", + "TPM-03", + "TPM-04", + "TPM-04.1", + "TPM-04.2", + "TPM-04.4", + "TPM-08", + "TPM-09", + "VPM-01", + "VPM-02", + "VPM-03", + "VPM-04", + "VPM-06" ], - "CA-07(01)": [ - "CPL-03.1" + "A01:2025": [ + "CFG-02", + "MON-01", + "MON-01.1", + "MON-01.2", + "MON-01.3", + "MON-01.4", + "MON-01.7", + "MON-01.8", + "MON-01.16", + "MON-08", + "EMB-01", + "END-16", + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-08", + "IAC-09", + "IAC-09.1", + "IAC-09.2", + "IAC-09.3", + "IAC-09.5", + "IAC-09.6", + "IAC-15.6", + "IAC-16.1", + "IAC-17", + "IAC-20", + "IAC-20.1", + "IAC-20.2", + "IAC-20.3", + "IAC-21", + "IAC-21.1", + "IAC-21.2", + "IAC-21.3", + "IAC-21.4", + "IAC-21.5", + "IAC-24", + "IAC-24.1", + "IAC-25", + "IAC-26", + "IAO-02.2", + "IAO-04", + "PRI-07.1", + "SEA-01", + "SEA-01.1", + "SEA-03", + "SEA-03.2", + "SEA-04", + "SEA-04.1", + "SEA-04.2", + "SEA-04.3", + "SEA-05", + "SEA-06", + "SEA-07.2", + "SEA-08", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "A02:2025": [ + "CFG-02", + "MON-01.7", + "CRY-01", + "EMB-01", + "IAO-02.2", + "IAO-04", + "PRI-07.1", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5", + "TPM-01", + "TPM-03", + "TPM-04", + "TPM-04.1", + "TPM-04.2", + "TPM-04.4", + "TPM-08", + "TPM-09" ], - "CM-02": [ + "A04:2025": [ "CFG-02", - "CFG-02.1" + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-08", + "CRY-09", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-02.3", + "TDA-04", + "TDA-04.1", + "TDA-05", + "TDA-06", + "TDA-06.2", + "TDA-06.3", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5" ], - "CM-06": [ + "A06:2025": [ "CFG-02", - "CFG-02.7" + "IAO-02.2", + "IAO-04", + "PRM-04", + "PRM-05", + "PRM-06", + "PRM-07", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5", + "TDA-17" ], - "PL-10": [ - "CFG-02" + "A09:2025": [ + "CFG-02", + "MON-01", + "MON-01.1", + "MON-01.2", + "MON-01.3", + "MON-01.4", + "MON-01.7", + "MON-01.8", + "MON-01.10", + "MON-01.16", + "MON-02", + "MON-02.1", + "MON-03", + "MON-03.2", + "MON-03.3", + "MON-03.4", + "MON-05", + "MON-06.1", + "MON-07", + "MON-07.1", + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-10", + "EMB-01", + "IAO-02.2", + "IAO-04", + "PRI-07.1", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5" ], - "SA-08": [ + "A10:2025": [ "CFG-02", - "SEA-01" + "EMB-01", + "IAO-02.2", + "IAO-04", + "PRI-07.1", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5", + "TDA-19" ], - "CM-02(02)": [ - "CFG-02.2" + "A07:2025": [ + "IAC-01", + "IAC-02.1", + "IAC-02.2", + "IAC-02.3", + "IAC-03", + "IAC-03.1", + "IAC-03.2", + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-09", + "IAC-10.1", + "IAC-10.2", + "IAC-10.4", + "IAC-10.6", + "IAC-10.8", + "IAC-14", + "IAO-02.2", + "IAO-04", + "PRI-07.1", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5" ], - "CM-02(03)": [ - "CFG-02.3" + "A03:2025": [ + "RSK-09", + "RSK-09.1", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-04.2", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5", + "TPM-01", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-04.2", + "TPM-04.3", + "TPM-04.4", + "TPM-05" ], - "CM-02(07)": [ - "CFG-02.5" + "A08:2025": [ + "TDA-01", + "TDA-01.1", + "TDA-01.2", + "TDA-02", + "TDA-04", + "TDA-04.1", + "TDA-06", + "TDA-06.2", + "TDA-06.3", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5", + "TDA-18", + "TDA-19" + ] + }, + "general-pci-dss-4-0-1": { + "12.4": [ + "GOV-01", + "GOV-04", + "CPL-01" ], - "PL-11": [ - "CFG-02.9" + "A3.1.2": [ + "GOV-01" ], - "CM-07": [ - "CFG-03" + "1.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "CM-07(01)": [ - "CFG-03.1" + "2.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "CM-07(05)": [ - "CFG-03.3" + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-07(07)": [ - "CFG-03.4" + "3.7.1": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "CM-10": [ - "CFG-04" + "3.7.2": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "CM-11": [ - "CFG-05" + "3.7.3": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "PM-31": [ - "MON-01" + "3.7.5": [ + "GOV-02", + "CRY-04", + "CRY-09", + "CRY-09.3", + "OPS-01.1" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "3.7.6": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "SI-04(02)": [ - "MON-01.2" + "3.7.7": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "SI-04(04)": [ - "MON-01.3" + "3.7.8": [ + "GOV-02", + "HRS-03", + "OPS-01.1" ], - "SI-04(05)": [ - "MON-01.4" + "4.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "5.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" + ], + "6.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" + ], + "7.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" + ], + "8.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" + ], + "8.3.8": [ + "GOV-02", + "IAC-01", + "OPS-01", + "OPS-01.1", + "SAT-01", + "SAT-02", + "SAT-03" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "9.1.1": [ + "GOV-02", + "GOV-03", + "PES-01", + "OPS-01", + "OPS-01.1" ], - "AU-06(03)": [ - "MON-02.1" + "10.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-03": [ - "MON-03" + "11.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-03(01)": [ - "MON-03.1" + "12.1": [ + "GOV-02", + "GOV-03" ], - "AU-06(01)": [ - "MON-03.1" + "12.1.1": [ + "GOV-02", + "GOV-03" ], - "AU-04": [ - "MON-04" + "12.1.2": [ + "GOV-02", + "GOV-03" ], - "AU-05": [ - "MON-05" + "12.1.3": [ + "GOV-02", + "GOV-04", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1" ], - "AU-07": [ - "MON-06" + "1.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1", + "SAT-03", + "SAT-03.5" ], - "AU-07(01)": [ - "MON-06" + "2.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "AU-12": [ - "MON-06" + "3.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "AU-08": [ - "MON-07", - "SEA-20" + "4.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "SC-45": [ - "MON-07.1" + "5.1.2": [ + "GOV-04", + "END-04.2", + "HRS-03", + "HRS-03.1" ], - "AU-09": [ - "MON-08" + "6.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "AU-04(01)": [ - "MON-08.1" + "7.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "AU-09(04)": [ - "MON-08.2" + "8.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "AU-11": [ - "MON-10" + "9.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1", + "PES-03" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "10.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "11.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "12.1.4": [ + "GOV-04", + "IRO-10" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "A3.1.1": [ + "GOV-04", + "CPL-01" ], - "SC-28": [ - "CRY-05", - "END-02" + "A3.1.3": [ + "GOV-04", + "HRS-03" ], - "AC-18": [ - "CRY-07", - "NET-15" + "6.3.1": [ + "GOV-07", + "IAO-04", + "TDA-15", + "THR-03", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-05.1" ], - "SC-12": [ - "CRY-08" + "A3.2.5": [ + "GOV-10", + "AST-04.1", + "AST-04.2", + "AST-04.3", + "DCH-06.3" ], - "SC-17": [ - "CRY-08" + "A3.3": [ + "GOV-14" ], - "MP-02": [ - "DCH-03", - "END-01" + "A3.3.3": [ + "GOV-14" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "6.3.2": [ + "AST-01", + "AST-02", + "AST-04.3", + "TDA-04.2", + "VPM-01.1", + "VPM-05.1" ], - "MP-04": [ - "DCH-06" + "9.5.1": [ + "AST-01", + "AST-02", + "AST-06", + "AST-07", + "AST-15", + "AST-15.1", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "MP-05": [ - "DCH-07" + "9.5.1.1": [ + "AST-01", + "AST-02", + "AST-07" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "11.2": [ + "AST-01", + "AST-02", + "CFG-02", + "MON-01.5", + "NET-02.2", + "NET-08.2", + "NET-12", + "NET-12.1", + "NET-15", + "NET-15.5" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "11.2.2": [ + "AST-01", + "AST-02", + "NET-02.2", + "NET-12.1", + "NET-15" ], - "AC-20": [ - "DCH-13" + "2.2.2": [ + "AST-03", + "IAC-10.8" ], - "AC-20(01)": [ - "DCH-13.1" + "2.2.4": [ + "AST-03", + "CFG-03", + "RSK-06.2" ], - "AC-20(02)": [ - "DCH-13.2" + "2.2.5": [ + "AST-03", + "TDA-02.6" ], - "PM-17": [ - "DCH-13.3" + "6.5.2": [ + "AST-03", + "CHG-01", + "CHG-02.2", + "CHG-03", + "CHG-06", + "CHG-06.1", + "IAC-10.8" ], - "AC-22": [ - "DCH-15" + "1.2.3": [ + "AST-04", + "AST-04.2", + "NET-02.2", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "1.2.4": [ + "AST-04", + "NET-06", + "NET-08.1", + "TDA-02.1" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "12.5.2.1": [ + "AST-04.2", + "AST-04.3", + "CFG-03.1", + "TPM-05.5" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "12.5.1": [ + "AST-04.3", + "CPL-01.2", + "PRI-05.5" ], - "CM-12": [ - "DCH-24" + "9.4": [ + "AST-05", + "CRY-05", + "CRY-05.1", + "DCH-01", + "DCH-06", + "DCH-06.1", + "DCH-06.4", + "DCH-07", + "DCH-08" ], - "CM-12(01)": [ - "DCH-24.1" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "9.5": [ + "AST-06", + "AST-07" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "9.5.1.2": [ + "AST-07", + "AST-08", + "AST-15.1" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "9.5.1.2.1": [ + "AST-08" ], - "SI-07(01)": [ - "END-06.1" + "9.4.7": [ + "AST-09", + "DCH-09", + "DCH-09.1", + "DCH-18", + "PRI-05" ], - "SI-07(07)": [ - "END-06.2" + "9.4.1.2": [ + "BCD-02.4", + "BCD-11", + "DCH-06", + "DCH-06.1", + "DCH-06.2" ], - "SI-08": [ - "END-08" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "SC-18": [ - "END-10" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "SC-41": [ - "END-12" + "1.2.2": [ + "CHG-01", + "CHG-02", + "CHG-02.1" ], - "SC-15": [ - "END-14" + "6.5": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "6.5.1": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "OPS-01.1" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "6.5.3": [ + "CHG-01", + "TDA-07", + "TDA-08" ], - "PS-09": [ - "HRS-03" + "12.4.2": [ + "CHG-01", + "CHG-02", + "CLD-12", + "CPL-01", + "CPL-01.1", + "CPL-03", + "CPL-03.2", + "CFG-02.1", + "CFG-03.1", + "MON-01.8", + "TPM-05", + "TPM-08" ], - "PS-03": [ - "HRS-04" + "6.5.6": [ + "CHG-02", + "CHG-03", + "CFG-02.4", + "TDA-08", + "TDA-08.1", + "TDA-09" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "A3.2.2.1": [ + "CHG-02.2", + "CHG-06" ], - "PL-04(01)": [ - "HRS-05.2" + "10.7": [ + "CHG-02.4", + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "IRO-01", + "MNT-03", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "TPM-11" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "A3.2.2": [ + "CHG-03", + "RSK-08", + "RSK-10" ], - "PS-08": [ - "HRS-07" + "A3.2.3": [ + "CHG-03", + "CPL-01.2", + "TPM-05.5" ], - "PS-05": [ - "HRS-08" + "1.2.8": [ + "CHG-04", + "CFG-02.6", + "NET-06", + "NET-08.1" ], - "PS-04": [ - "HRS-09" + "10.7.3": [ + "CHG-06", + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "IRO-01", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "TPM-11" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "1.2.1": [ + "CLD-01", + "CFG-02", + "CFG-02.5", + "NET-06", + "NET-08.1", + "SEA-03" ], - "PS-07": [ - "HRS-10" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "A1.1": [ + "CLD-06" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "A1.1.1": [ + "CLD-06" ], - "IA-02": [ - "IAC-02" + "A1.1.2": [ + "CLD-06" ], - "IA-02(08)": [ - "IAC-02.2" + "A1.1.3": [ + "CLD-06" ], - "IA-02(12)": [ - "IAC-02.3" + "A1.1.4": [ + "CLD-06", + "NET-06", + "NET-08.1" ], - "IA-08": [ - "IAC-03" + "12.4.1": [ + "CLD-06.1", + "TPM-05.4" ], - "IA-08(01)": [ - "IAC-03.1" + "A1.2": [ + "CLD-06.2", + "CLD-06.3", + "CLD-06.4" ], - "IA-08(02)": [ - "IAC-03.2" + "A1.2.1": [ + "CLD-06.2" ], - "IA-08(04)": [ - "IAC-03.3" + "A1.2.2": [ + "CLD-06.3" ], - "IA-03": [ - "IAC-04" + "A1.2.3": [ + "CLD-06.4", + "IRO-10", + "IAO-04", + "TDA-15" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "A3.1": [ + "CPL-01" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "12.5": [ + "CPL-01.2" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "12.5.2": [ + "CPL-01.2", + "CFG-03.1", + "NET-06", + "NET-08.1", + "TPM-04.4" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "A3.2": [ + "CPL-01.2" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "A3.2.1": [ + "CPL-01.2", + "NET-06", + "NET-08.1", + "TPM-05.5" ], - "IA-05(02)": [ - "IAC-10.2" + "10.7.1": [ + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "END-16", + "IRO-01", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "SEA-04.1", + "TPM-11" ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" + "10.7.2": [ + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "IRO-01", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "TPM-11" ], - "IA-06": [ - "IAC-11" + "11.1": [ + "CPL-03", + "CPL-03.2" ], - "IA-11": [ - "IAC-14" + "1.2.7": [ + "CPL-03.2", + "CFG-03.1", + "NET-04.6", + "NET-06", + "NET-08.1" ], - "AC-02(01)": [ - "IAC-15.1" + "2.1": [ + "CFG-01", + "CFG-01.1" ], - "AC-02(02)": [ - "IAC-15.2" + "2.2": [ + "CFG-01", + "CFG-02" ], - "AC-02(03)": [ - "IAC-15.3" + "8.5": [ + "CFG-01", + "CFG-02", + "CFG-02.5", + "SEA-01" ], - "AC-02(04)": [ - "IAC-15.4" + "1.1": [ + "CFG-02", + "NET-01", + "NET-04", + "PRM-04", + "PRM-05", + "SEA-01.1" ], - "AC-06(07)": [ - "IAC-17" + "1.2.6": [ + "CFG-02", + "CFG-03", + "NET-06", + "NET-08.1", + "RSK-06.2", + "TDA-02.6" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "2.2.1": [ + "CFG-02" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "8.3.2": [ + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-05" ], - "AC-06(01)": [ - "IAC-21.1" + "10.2": [ + "CFG-02", + "CFG-02.5", + "MON-01.4", + "MON-03", + "MON-03.2", + "MON-07" ], - "AC-06(02)": [ - "IAC-21.2" + "10.2.1": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "AC-06(05)": [ - "IAC-21.3" + "10.2.1.1": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "AC-06(09)": [ + "10.2.1.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3", "IAC-21.4" ], - "AC-06(10)": [ - "IAC-21.5" - ], - "AC-07": [ - "IAC-22" + "10.2.1.3": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "AC-02(05)": [ - "IAC-24" + "10.2.1.4": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "AC-11": [ - "IAC-24" + "10.2.1.5": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "AC-11(01)": [ - "IAC-24.1" + "10.2.1.6": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "AC-12": [ - "IAC-25" + "10.2.1.7": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "AC-14": [ - "IAC-26" + "10.2.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "IA-12": [ - "IAC-28" + "10.6": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "IA-12(02)": [ - "IAC-28.2" + "10.6.1": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "IA-12(03)": [ - "IAC-28.3" + "10.6.2": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "IA-12(05)": [ - "IAC-28.5" + "10.6.3": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "IR-04": [ - "IRO-02" + "1.5": [ + "CFG-02.5", + "END-01", + "END-02" ], - "IR-04(01)": [ - "IRO-02.1" + "1.5.1": [ + "CFG-02.5", + "CFG-03.4", + "DCH-13.1", + "END-01", + "END-02", + "END-05" ], - "IR-08": [ - "IRO-04" + "1.2.5": [ + "CFG-03", + "NET-06", + "NET-08.1", + "TDA-02.5", + "TPM-04.2" ], - "IR-02": [ - "IRO-05" + "1.4": [ + "CFG-03", + "NET-02", + "NET-03", + "NET-03.8", + "NET-08.1" ], - "IR-03": [ - "IRO-06" + "1.4.1": [ + "CFG-03", + "NET-02", + "NET-03", + "NET-03.8", + "NET-06", + "NET-08.1", + "NET-09", + "SEA-03" ], - "IR-03(02)": [ - "IRO-06.1" + "1.4.2": [ + "CFG-03", + "NET-03", + "NET-03.1", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "IR-05": [ - "IRO-09" + "11.6.1": [ + "CFG-03.1", + "MON-01.7", + "END-06", + "WEB-13" ], - "IR-06(01)": [ - "IRO-10.1" + "12.3.1": [ + "CFG-03.1", + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.2", + "RSK-07" ], - "IR-06(03)": [ - "IRO-10.4" + "12.3.4": [ + "CFG-03.1", + "SEA-02.3", + "SEA-07.1" ], - "IR-07": [ - "IRO-11" + "12.6.2": [ + "CFG-03.1", + "SAT-01" ], - "IR-07(01)": [ - "IRO-11.1" + "12.6.3": [ + "CFG-03.1", + "HRS-03.1", + "HRS-05.7", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.6", + "SAT-04" ], - "PM-10": [ - "IAO-01" + "10.1": [ + "MON-01" ], - "CA-02(01)": [ - "IAO-02.1" + "10.4.3": [ + "MON-01", + "MON-01.4", + "MON-01.8" ], - "CA-05": [ - "IAO-05" + "A3.3.1": [ + "MON-01", + "MON-05", + "IRO-09" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "A3.5": [ + "MON-01", + "MON-01.11", + "IRO-01" ], - "CM-04(02)": [ - "IAO-06" + "1.4.3": [ + "MON-01.1", + "NET-04", + "NET-08", + "NET-08.2" ], - "CA-06": [ - "IAO-07" + "11.5": [ + "MON-01.1", + "MON-01.7", + "END-06", + "NET-08", + "SAT-03.2" ], - "MA-02": [ - "MNT-02" + "11.5.1": [ + "MON-01.1", + "NET-03", + "NET-08", + "SAT-03.2" ], - "MA-06": [ - "MNT-03" + "11.5.1.1": [ + "MON-01.1", + "MON-11.1", + "MON-15", + "NET-08", + "SAT-03.2" ], - "MA-03": [ - "MNT-04" + "10.4": [ + "MON-01.2", + "MON-01.4", + "MON-01.7", + "MON-01.8", + "MON-02", + "MON-02.2" ], - "MA-03(01)": [ - "MNT-04.1" + "10.4.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.2" ], - "MA-03(02)": [ - "MNT-04.2" + "10.4.1.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.1", + "MON-02.2" ], - "MA-03(03)": [ - "MNT-04.3" + "10.3.4": [ + "MON-01.7", + "END-06" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "11.5.2": [ + "MON-01.7", + "END-06" ], - "MA-04(01)": [ - "MNT-05.1" + "10.4.2": [ + "MON-01.8" ], - "MA-05": [ - "MNT-06" + "10.4.2.1": [ + "MON-01.8" ], - "SR-11(02)": [ - "MNT-07" + "3.1": [ + "MON-01.10", + "MON-16" ], - "MA-07": [ - "MNT-08" + "A3.2.6.1": [ + "MON-01.11", + "MON-01.12", + "MON-16", + "MON-16.1", + "MON-16.3" ], - "AC-19": [ - "MDM-02" + "10.3.3": [ + "MON-02", + "MON-02.2", + "MON-08.1" ], - "AC-19(05)": [ - "MDM-03" + "12.10.5": [ + "MON-02.1", + "IRO-02", + "IRO-04", + "NET-12.1" ], - "SC-07": [ - "NET-03" + "6.4.2": [ + "MON-03", + "IAO-04", + "TDA-15", + "VPM-05.1", + "WEB-01", + "WEB-03" ], - "SC-07(03)": [ - "NET-03.1" + "7.2.6": [ + "MON-03.7", + "IAC-20", + "IAC-20.1", + "IAC-20.2", + "IAC-21" ], - "SC-07(04)": [ - "NET-03.2" + "10.3": [ + "MON-08", + "MON-08.2" ], - "AC-04": [ - "NET-04" + "10.3.1": [ + "MON-08", + "MON-08.2" ], - "SC-07(05)": [ - "NET-04.1" + "10.3.2": [ + "MON-08", + "MON-08.2" ], - "CA-03": [ - "NET-05" + "10.5": [ + "MON-10", + "DCH-18" ], - "CA-09": [ - "NET-05.2" + "10.5.1": [ + "MON-10", + "DCH-18", + "PRI-05" ], - "SC-07(28)": [ - "NET-06.5" + "2.2.7": [ + "CRY-01", + "CRY-02", + "CRY-06", + "MNT-05.3" ], - "SC-23": [ - "NET-09" + "3.3.2": [ + "CRY-01", + "CRY-05" ], - "SC-20": [ - "NET-10" + "12.3.3": [ + "CRY-01", + "CRY-01.5" ], - "SC-22": [ - "NET-10.1" + "3.6.1.1": [ + "CRY-02", + "CRY-09", + "IAC-12" ], - "SC-21": [ - "NET-10.2" + "3.6.1.2": [ + "CRY-02", + "CRY-09", + "IAC-12" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "4.2": [ + "CRY-03" ], - "SI-10": [ + "4.2.1": [ + "CRY-03", "NET-12", - "TDA-18" - ], - "AC-17": [ - "NET-14" - ], - "AC-17(01)": [ - "NET-14.1" - ], - "AC-17(02)": [ - "NET-14.2" + "NET-15.1" ], - "AC-17(03)": [ - "NET-14.3" + "4.2.1.2": [ + "CRY-03", + "CRY-07", + "NET-12.1" ], - "AC-17(04)": [ - "NET-14.4" + "A2.1": [ + "CRY-03", + "WEB-10" ], - "AC-17(09)": [ - "NET-14.8" + "A2.1.1": [ + "CRY-03", + "WEB-10" ], - "AC-18(01)": [ - "NET-15.1" + "A2.1.2": [ + "CRY-03", + "WEB-10" ], - "AC-18(03)": [ - "NET-15.2" + "3.5": [ + "CRY-05", + "DCH-01.2" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "3.5.1.2": [ + "CRY-05" ], - "PE-02": [ - "PES-02" + "3.5.1.3": [ + "CRY-05" ], - "PE-03": [ - "PES-03" + "2.3.1": [ + "CRY-07", + "IAC-10.8", + "NET-12.1", + "NET-15.1" ], - "PE-08": [ - "PES-03.3" + "2.3.2": [ + "CRY-07", + "CRY-09.3", + "NET-12.1", + "NET-15.1" ], - "PE-06": [ - "PES-05" + "3.6.1": [ + "CRY-08.1", + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "PE-06(01)": [ - "PES-05.1" + "3.5.1.1": [ + "CRY-09" ], - "PE-06(04)": [ - "PES-05.2" + "3.6": [ + "CRY-09" ], - "PE-09": [ - "PES-07" + "3.6.1.3": [ + "CRY-09" ], - "PE-10": [ - "PES-07.2" + "3.6.1.4": [ + "CRY-09" ], - "PE-11": [ - "PES-07.3" + "3.7": [ + "CRY-09", + "OPS-01.1" ], - "PE-12": [ - "PES-07.4" + "3.7.4": [ + "CRY-09" ], - "PE-15": [ - "PES-07.5" + "4.2.1.1": [ + "CRY-09" ], - "PE-13": [ - "PES-08" + "3.7.9": [ + "CRY-09.6" ], - "PE-13(01)": [ - "PES-08.1" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "PE-14": [ - "PES-09" + "3.5.1": [ + "DCH-01.2" ], - "PE-16": [ - "PES-10" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "PE-17": [ - "PES-11" + "7.1": [ + "DCH-03.1", + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "PE-04": [ - "PES-12.1" + "3.4.1": [ + "DCH-03.2", + "END-16", + "PRI-05.3" ], - "PE-05": [ - "PES-12.2" + "9.1": [ + "DCH-06", + "DCH-06.1", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03" ], - "PM-18": [ - "PRI-01" + "9.4.5": [ + "DCH-06.2" ], - "PM-19": [ - "PRI-01.1" + "9.4.5.1": [ + "DCH-06.2" ], - "PM-20": [ - "PRI-01.3" + "A3.2.5.1": [ + "DCH-06.3" ], - "PM-20(01)": [ - "PRI-02" + "3.3": [ + "DCH-06.5" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "3.3.1": [ + "DCH-06.5" ], - "AC-21": [ - "PRI-07" + "3.3.1.1": [ + "DCH-06.5" ], - "PM-27": [ - "PRI-14" + "3.3.1.2": [ + "DCH-06.5" ], - "PM-21": [ - "PRI-14.1" + "3.3.1.3": [ + "DCH-06.5" ], - "PM-03": [ - "PRM-02" + "3.3.3": [ + "DCH-06.5" ], - "SA-02": [ - "PRM-03" + "9.4.3": [ + "DCH-07", + "DCH-07.1" ], - "PM-11": [ - "PRM-06" + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "1.4.4": [ + "DCH-15", + "NET-05.1" ], - "PM-09": [ - "RSK-01" + "3.2": [ + "DCH-18" ], - "PM-28": [ - "RSK-01.1" + "3.2.1": [ + "DCH-18", + "TPM-04.4" ], - "RA-02": [ - "RSK-02" + "11.4.1": [ + "DCH-18", + "IAO-04", + "TDA-15", + "VPM-07", + "VPM-07.1" ], - "RA-07": [ - "RSK-06.1" + "5.1": [ + "END-01" ], - "PM-30": [ - "RSK-09" + "5.2": [ + "END-04" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "5.2.1": [ + "END-04" ], - "RA-03(01)": [ - "RSK-09.1" + "5.2.2": [ + "END-04" ], - "CA-07(04)": [ - "RSK-11" + "5.3": [ + "END-04", + "END-04.1", + "END-04.7" ], - "SC-07(18)": [ - "SEA-01" + "5.3.1": [ + "END-04", + "END-04.1" ], - "PL-08": [ - "SEA-02" + "5.3.2": [ + "END-04", + "END-04.7" ], - "PM-07": [ - "SEA-02" + "5.3.2.1": [ + "END-04", + "END-04.7" ], - "SC-02": [ - "SEA-03.2" + "5.3.3": [ + "END-04", + "END-04.7" ], - "SC-39": [ - "SEA-04" + "5.3.4": [ + "END-04", + "END-04.3" ], - "SC-04": [ - "SEA-05" + "5.3.5": [ + "END-04", + "END-04.7" ], - "CM-07(02)": [ - "SEA-06" + "5.2.3": [ + "END-04.6" ], - "CP-12": [ - "SEA-07.2" + "5.2.3.1": [ + "END-04.6" ], - "SC-24": [ - "SEA-07.2" + "5.4": [ + "END-08" ], - "SI-17": [ - "SEA-07.3" + "5.4.1": [ + "END-08" ], - "SI-16": [ - "SEA-10" + "2.2.3": [ + "END-16", + "END-16.1", + "SEA-04.1" ], - "AC-08": [ - "SEA-18" + "11.4.5": [ + "END-16", + "NET-06", + "NET-08.1", + "SEA-04.1", + "TDA-07", + "VPM-07", + "VPM-07.1" ], - "AT-02": [ - "SAT-02" + "11.4.6": [ + "END-16", + "NET-06", + "NET-08.1", + "SEA-04.1", + "TDA-07", + "VPM-07", + "VPM-07.1" ], - "AT-02(03)": [ - "SAT-02.2" + "12.2": [ + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "AT-03": [ - "SAT-03" + "12.2.1": [ + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "AT-02(04)": [ - "SAT-03.2" + "12.7": [ + "HRS-01", + "HRS-02", + "HRS-02.1", + "HRS-04", + "HRS-04.1" ], - "AT-04": [ - "SAT-04" + "12.7.1": [ + "HRS-01", + "HRS-02", + "HRS-02.1", + "HRS-04", + "HRS-04.1" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "6.2.2": [ + "HRS-03.2", + "IAO-04", + "SAT-03", + "SAT-03.8", + "TDA-06.3", + "TDA-13", + "TDA-15" ], - "SA-04(09)": [ - "TDA-02.1" + "8.2.5": [ + "HRS-09", + "HRS-09.2", + "IAC-07.1", + "IAC-07.2", + "IAC-20.6" ], - "SA-04(10)": [ - "TDA-02.2" + "6.5.4": [ + "HRS-11" ], - "SA-15": [ - "TDA-06" + "7.2": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "7.2.1": [ + "IAC-01", + "IAC-02", + "IAC-03", + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "SA-15(03)": [ - "TDA-06.1" + "7.3": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "SA-11": [ - "TDA-09" + "7.3.1": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "SR-11": [ - "TDA-11" + "7.3.2": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "SR-11(01)": [ - "TDA-11.1" + "7.3.3": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "SA-10": [ - "TDA-14" + "8.1": [ + "IAC-01", + "IAC-02" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "8.2": [ + "IAC-01", + "IAC-02", + "IAC-09", + "IAC-09.1" ], - "SI-11": [ - "TDA-19" + "8.3.3": [ + "IAC-01", + "IAC-02", + "IAC-10", + "IAC-10.1", + "IAC-28" ], - "RA-09": [ - "TPM-02" + "8.5.1": [ + "IAC-01", + "IAC-02.2", + "IAC-06", + "SEA-01" ], - "SR-02(01)": [ - "TPM-03" + "8.6.1": [ + "IAC-01", + "IAC-05.1", + "IAC-15", + "IAC-15.7", + "IAC-19", + "IAC-20.3", + "IAC-21" ], - "SR-05": [ - "TPM-03.1" + "A3.4": [ + "IAC-01" ], - "SR-03": [ - "TPM-03.3" + "8.3": [ + "IAC-02", + "IAC-10", + "IAC-10.1" ], - "SR-05(01)": [ - "TPM-03.4" + "8.3.9": [ + "IAC-02", + "IAC-10", + "IAC-10.1" ], - "SA-09": [ - "TPM-04" + "8.2.2": [ + "IAC-02.1", + "IAC-15.5", + "IAC-19" ], - "SA-09(02)": [ - "TPM-04.2" + "8.2.3": [ + "IAC-03.2", + "IAC-05", + "IAC-05.1", + "IAC-06", + "NET-14", + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.3" ], - "SR-08": [ - "TPM-05.1" + "8.4": [ + "IAC-06" ], - "SR-06": [ - "TPM-08" + "8.4.2": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4" ], - "PM-16": [ - "THR-01" + "8.4.3": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2" ], - "PM-12": [ - "THR-04" + "8.4.1": [ + "IAC-06.1" ], - "AT-02(02)": [ - "THR-05" + "7.2.3": [ + "IAC-07", + "IAC-07.1", + "IAC-16", + "IAC-21.3" ], - "RA-05(11)": [ - "THR-06" + "8.2.4": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-15" ], - "SI-02(02)": [ - "VPM-05.2" + "8.3.5": [ + "IAC-07", + "IAC-10", + "IAC-10.1" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "1.3": [ + "IAC-08", + "IAC-21", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1", + "NET-15.1" ], - "RA-05(02)": [ - "VPM-06.1" + "7.2.2": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "RA-05(05)": [ - "VPM-06.3" - ] - }, - "general-nist-800-82-r3-high": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "7.2.5": [ + "IAC-08", + "IAC-16", + "IAC-20", + "IAC-20.1", + "NET-14" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "8.2.1": [ + "IAC-09", + "IAC-09.1" ], - "AT-01": [ - "GOV-02" + "8.3.1": [ + "IAC-10", + "IAC-10.1", + "IAC-10.2" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "8.3.7": [ + "IAC-10", + "IAC-10.1" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "8.3.10.1": [ + "IAC-10", + "IAC-10.1" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "8.3.11": [ + "IAC-10", + "IAC-10.2", + "IAC-10.5", + "IAC-10.7", + "IAC-18", + "PES-02", + "PES-02.1" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "8.6.3": [ + "IAC-10", + "IAC-10.1" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "8.3.6": [ + "IAC-10.1" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "8.6.2": [ + "IAC-10.6" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "8.2.8": [ + "IAC-14", + "IAC-24", + "IAC-25", + "NET-07" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "8.3.10": [ + "IAC-15", + "WEB-06" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "8.6": [ + "IAC-15", + "IAC-15.7", + "IAC-20.3", + "IAC-21" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "TDA-01" + "8.2.6": [ + "IAC-15.3" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "7.2.4": [ + "IAC-16.1", + "IAC-17" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "7.2.5.1": [ + "IAC-17" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "A3.4.1": [ + "IAC-17" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "3.4": [ + "IAC-21" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "3.4.2": [ + "IAC-21", + "NET-14" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "8.3.4": [ + "IAC-22" ], - "PM-02": [ - "GOV-04" + "12.10": [ + "IRO-01", + "IRO-02", + "IRO-02.4", + "IRO-04" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "A3.3.1.2": [ + "IRO-02", + "IRO-13", + "RSK-06", + "TPM-09", + "VPM-02" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "12.10.7": [ + "IRO-04", + "IRO-12", + "IRO-12.3" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "12.10.2": [ + "IRO-04.2", + "IRO-06" ], - "PM-15": [ - "GOV-07", - "THR-01" + "12.10.6": [ + "IRO-04.2", + "IRO-13" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "12.10.4": [ + "IRO-05" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "12.10.4.1": [ + "IRO-05" ], - "PM-32": [ - "GOV-11" + "12.10.3": [ + "IRO-07" ], - "PM-05": [ - "AST-01", - "AST-02" + "A3.2.5.2": [ + "IRO-12", + "IRO-12.3" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "6.2.1": [ + "IAO-04", + "SEA-01", + "TDA-01", + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-15" ], - "CM-08(01)": [ - "AST-02.1" + "6.2.3": [ + "IAO-04", + "TDA-06.5", + "TDA-09", + "TDA-15" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "6.2.3.1": [ + "IAO-04", + "TDA-09", + "TDA-15" ], - "CM-08(02)": [ - "AST-02.9" + "6.2.4": [ + "IAO-04", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5", + "TDA-15" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "6.4.1": [ + "IAO-04", + "TDA-15", + "VPM-05.1", + "VPM-06", + "VPM-06.6", + "WEB-01", + "WEB-03" ], - "CM-08(04)": [ - "AST-03.1" + "11.4.4": [ + "IAO-04", + "TDA-15", + "VPM-07" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "12.4.2.1": [ + "IAO-04", + "TDA-15", + "TPM-05", + "TPM-08" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "11.3": [ + "MNT-03", + "VPM-01", + "VPM-02", + "VPM-03", + "VPM-04", + "VPM-06" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "8.2.7": [ + "MNT-05", + "MNT-05.1", + "MNT-05.4", + "NET-14", + "NET-14.6" ], - "PE-22": [ - "AST-04.1", - "PES-16" + "1.2": [ + "NET-01", + "SEA-01", + "SEA-02" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "11.2.1": [ + "NET-01", + "NET-02.2", + "NET-03.1", + "NET-12.1", + "NET-15", + "NET-15.5" ], - "SR-12": [ - "AST-09" + "1.3.3": [ + "NET-02.2", + "NET-03", + "NET-03.7", + "NET-04.1", + "NET-04.7", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "SR-09": [ - "AST-15" + "2.3": [ + "NET-02.2", + "NET-12.1", + "NET-15" ], - "SR-09(01)": [ - "AST-15" + "1.4.5": [ + "NET-03.3", + "VPM-06.8" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "1.3.2": [ + "NET-03.5", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "1.3.1": [ + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "A3.2.4": [ + "NET-06", + "NET-08.1", + "VPM-07" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "4.1": [ + "NET-12" ], - "CP-02(01)": [ - "BCD-01.1" + "4.2.2": [ + "NET-12.2" ], - "CP-06(02)": [ - "BCD-01.4" + "A3.2.6": [ + "NET-17" ], - "CP-02(08)": [ - "BCD-02" + "9.2": [ + "PES-01", + "PES-02", + "PES-02.1", + "PES-03", + "PES-03.1" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "9.2.1": [ + "PES-02", + "PES-02.1", + "PES-03", + "PES-03.1", + "PES-03.3" ], - "CP-02(05)": [ - "BCD-02.2" + "9.3": [ + "PES-02", + "PES-02.1", + "PES-03.1" ], - "CP-03": [ - "BCD-03" + "9.3.1": [ + "PES-02", + "PES-02.1", + "PES-03.1" ], - "CP-03(01)": [ - "BCD-03.1" + "9.3.1.1": [ + "PES-02.1", + "PES-04", + "PES-04.1" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "9.2.4": [ + "PES-03.2", + "PES-12" ], - "CP-04(01)": [ - "BCD-04.1" + "9.2.1.1": [ + "PES-03.3", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "CP-04(02)": [ - "BCD-04.2" + "9.3.2": [ + "PES-06", + "PES-06.1", + "PES-06.2", + "PES-06.3", + "OPS-01", + "OPS-01.1" ], - "CP-06": [ - "BCD-08" + "9.3.3": [ + "PES-06", + "PES-06.6" ], - "CP-06(01)": [ - "BCD-08.1" + "9.3.4": [ + "PES-06", + "PES-06.4", + "PES-06.5" ], - "CP-06(03)": [ - "BCD-08.2" + "9.2.2": [ + "PES-12", + "PES-12.1", + "PES-12.2" ], - "CP-07": [ - "BCD-09" + "9.2.3": [ + "PES-12", + "PES-12.1", + "PES-12.2" ], - "CP-07(01)": [ - "BCD-09.1" + "12.9.1": [ + "PRI-01.6", + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "CP-07(02)": [ - "BCD-09.2" + "6.5.5": [ + "PRI-05.1", + "PRI-05.4", + "TDA-10" ], - "CP-07(03)": [ - "BCD-09.3" + "A3.1.4": [ + "PRI-08", + "SAT-01" ], - "CP-07(04)": [ - "BCD-09.4" + "12.3": [ + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-05", + "RSK-06" ], - "CP-08": [ - "BCD-10" + "12.3.2": [ + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-06.2", + "RSK-07" ], - "CP-08(02)": [ - "BCD-10" + "6.1": [ + "SEA-01" ], - "CP-08(01)": [ - "BCD-10.1" + "6.2": [ + "SEA-01", + "TDA-01", + "TDA-02.3", + "TDA-05", + "TDA-06" ], - "CP-08(03)": [ - "BCD-10.2" + "A3.3.2": [ + "SEA-02.3" ], - "CP-08(04)": [ - "BCD-10.3" + "9.5.1.3": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "SC-47": [ - "BCD-10.4" + "12.6": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "CP-09": [ - "BCD-11" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "CP-09(01)": [ - "BCD-11.1" + "12.6.3.1": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "CP-09(03)": [ - "BCD-11.2" + "12.6.3.2": [ + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "CP-09(08)": [ - "BCD-11.4" + "2.2.6": [ + "TDA-05.1" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "12.8": [ + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "CP-09(02)": [ - "BCD-11.5" + "12.9": [ + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "CP-09(05)": [ - "BCD-11.6" + "12.9.2": [ + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "CP-10(02)": [ - "BCD-12.1" + "A2.1.3": [ + "TPM-01" ], - "SI-13": [ - "BCD-12.2", - "SEA-07" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "CP-10(04)": [ - "BCD-12.4" + "12.8.3": [ + "TPM-04.1" ], - "CP-10(06)": [ - "BCD-13" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "12.5.3": [ + "TPM-05.5" ], - "CP-02(02)": [ - "CAP-03" + "12.8.4": [ + "TPM-08" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "6.3": [ + "THR-01", + "VPM-01", + "VPM-05.1" ], - "CM-03(01)": [ - "CHG-02.1" + "A3.5.1": [ + "THR-01" ], - "CM-03(04)": [ - "CHG-02.3" + "6.3.3": [ + "VPM-01", + "VPM-04", + "VPM-05", + "VPM-05.1" ], - "CM-03(06)": [ - "CHG-02.5" + "11.3.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.1", + "VPM-06.2", + "VPM-06.7" ], - "CM-04": [ - "CHG-03" + "11.3.1.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "11.3.1.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.7" ], - "CM-05(01)": [ - "CHG-04.1" + "11.3.1.3": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.7" ], - "SI-07(15)": [ - "CHG-04.2" + "11.3.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.6" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "11.3.2.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.2", + "VPM-06.6" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "6.4": [ + "VPM-05.1", + "WEB-01", + "WEB-03" ], - "CM-03(02)": [ - "CHG-06" + "6.4.3": [ + "VPM-05.1", + "WEB-01.1" ], - "SI-06": [ - "CHG-06" + "11.4": [ + "VPM-07" ], - "SC-07(29)": [ - "CLD-03" + "11.4.2": [ + "VPM-07", + "VPM-07.1" ], - "CA-07": [ - "CPL-02" + "11.4.3": [ + "VPM-07", + "VPM-07.1" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "11.4.7": [ + "VPM-07" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "11.6": [ + "WEB-13" + ] + }, + "general-pci-dss-4-0-1-saq-a": { + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "CA-07(01)": [ - "CPL-03.1" + "6.3.1": [ + "GOV-07", + "IAO-04", + "TDA-15", + "THR-03", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-05.1" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "2.2.2": [ + "AST-03", + "IAC-10.8" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "PL-10": [ - "CFG-02" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "CM-02(02)": [ - "CFG-02.2" + "11.6.1": [ + "CFG-03.1", + "MON-01.7", + "END-06", + "WEB-13" ], - "CM-06(01)": [ - "CFG-02.2" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "CM-02(03)": [ - "CFG-02.3" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "CM-02(07)": [ - "CFG-02.5" + "9.4.3": [ + "DCH-07", + "DCH-07.1" ], - "CM-06(02)": [ - "CFG-02.8" + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "PL-11": [ - "CFG-02.9" + "3.2.1": [ + "DCH-18", + "TPM-04.4" ], - "CM-07": [ - "CFG-03" + "8.2.5": [ + "HRS-09", + "HRS-09.2", + "IAC-07.1", + "IAC-07.2", + "IAC-20.6" ], - "CM-07(01)": [ - "CFG-03.1" + "8.3.9": [ + "IAC-02", + "IAC-10", + "IAC-10.1" ], - "CM-07(05)": [ - "CFG-03.3" + "8.2.2": [ + "IAC-02.1", + "IAC-15.5", + "IAC-19" ], - "SC-07(07)": [ - "CFG-03.4" + "8.3.5": [ + "IAC-07", + "IAC-10", + "IAC-10.1" ], - "CM-10": [ - "CFG-04" + "8.2.1": [ + "IAC-09", + "IAC-09.1" ], - "CM-11": [ - "CFG-05" + "8.3.1": [ + "IAC-10", + "IAC-10.1", + "IAC-10.2" ], - "AC-03(11)": [ - "CFG-08" + "8.3.7": [ + "IAC-10", + "IAC-10.1" ], - "PM-31": [ - "MON-01" + "8.3.6": [ + "IAC-10.1" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "SI-04(02)": [ - "MON-01.2" + "12.8.3": [ + "TPM-04.1" ], - "SI-04(04)": [ - "MON-01.3" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "SI-04(05)": [ - "MON-01.4" + "12.8.4": [ + "TPM-08" ], - "SI-04(14)": [ - "MON-01.5" + "6.3.3": [ + "VPM-01", + "VPM-04", + "VPM-05", + "VPM-05.1" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "11.3.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.6" ], - "SI-04(12)": [ - "MON-01.12" + "11.3.2.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.2", + "VPM-06.6" ], - "SI-04(20)": [ - "MON-01.15" + "6.4.3": [ + "VPM-05.1", + "WEB-01.1" + ] + }, + "general-pci-dss-4-0-1-saq-a-ep": { + "1.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "2.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-06(03)": [ - "MON-02.1" + "4.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-06(05)": [ - "MON-02.3" + "5.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-06(06)": [ - "MON-02.4" + "6.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-12(01)": [ - "MON-02.7" + "8.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-12(03)": [ - "MON-02.8" + "8.3.8": [ + "GOV-02", + "IAC-01", + "OPS-01", + "OPS-01.1", + "SAT-01", + "SAT-02", + "SAT-03" ], - "AU-03": [ - "MON-03" + "12.1.1": [ + "GOV-02", + "GOV-03" ], - "AU-03(01)": [ - "MON-03.1" + "12.1.2": [ + "GOV-02", + "GOV-03" ], - "AU-06(01)": [ - "MON-03.1" + "12.1.3": [ + "GOV-02", + "GOV-04", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1" ], - "AU-04": [ - "MON-04" + "12.1.4": [ + "GOV-04", + "IRO-10" ], - "AU-05": [ - "MON-05" + "6.3.1": [ + "GOV-07", + "IAO-04", + "TDA-15", + "THR-03", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-05.1" ], - "AU-05(02)": [ - "MON-05.1" + "6.3.2": [ + "AST-01", + "AST-02", + "AST-04.3", + "TDA-04.2", + "VPM-01.1", + "VPM-05.1" ], - "AU-05(01)": [ - "MON-05.2" + "2.2.2": [ + "AST-03", + "IAC-10.8" ], - "AU-07": [ - "MON-06" + "2.2.4": [ + "AST-03", + "CFG-03", + "RSK-06.2" ], - "AU-07(01)": [ - "MON-06" + "2.2.5": [ + "AST-03", + "TDA-02.6" ], - "AU-12": [ - "MON-06" + "6.5.2": [ + "AST-03", + "CHG-01", + "CHG-02.2", + "CHG-03", + "CHG-06", + "CHG-06.1", + "IAC-10.8" ], - "AU-08": [ - "MON-07", - "SEA-20" + "1.2.3": [ + "AST-04", + "AST-04.2", + "NET-02.2", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "SC-45": [ - "MON-07.1" + "1.2.4": [ + "AST-04", + "NET-06", + "NET-08.1", + "TDA-02.1" ], - "AU-09": [ - "MON-08" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "AU-04(01)": [ - "MON-08.1" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "AU-09(02)": [ - "MON-08.1" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "AU-09(04)": [ - "MON-08.2" + "1.2.2": [ + "CHG-01", + "CHG-02", + "CHG-02.1" ], - "AU-09(03)": [ - "MON-08.3" + "6.5.1": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "OPS-01.1" ], - "AU-10": [ - "MON-09" + "1.2.8": [ + "CHG-04", + "CFG-02.6", + "NET-06", + "NET-08.1" ], - "AU-11": [ - "MON-10" + "1.2.1": [ + "CLD-01", + "CFG-02", + "CFG-02.5", + "NET-06", + "NET-08.1", + "SEA-03" ], - "SI-04(22)": [ - "MON-11.2" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "AC-02(12)": [ - "MON-16" + "1.2.7": [ + "CPL-03.2", + "CFG-03.1", + "NET-04.6", + "NET-06", + "NET-08.1" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "1.2.6": [ + "CFG-02", + "CFG-03", + "NET-06", + "NET-08.1", + "RSK-06.2", + "TDA-02.6" ], - "SC-13": [ + "2.2.1": [ + "CFG-02" + ], + "8.3.2": [ + "CFG-02", "CRY-01", - "CRY-01.2", + "CRY-03", "CRY-05" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "10.2.1": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "10.2.1.1": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "SC-28": [ - "CRY-05", - "END-02" + "10.2.1.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3", + "IAC-21.4" ], - "AC-18": [ - "CRY-07", - "NET-15" + "10.2.1.3": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "SC-12": [ - "CRY-08" + "10.2.1.4": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "SC-17": [ - "CRY-08" + "10.2.1.5": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "SC-12(01)": [ - "CRY-09.3" + "10.2.1.6": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "MP-02": [ - "DCH-03", - "END-01" + "10.2.1.7": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "10.2.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "MP-04": [ - "DCH-06" + "10.6.1": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "MP-05": [ - "DCH-07" + "10.6.2": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "10.6.3": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" + "1.5.1": [ + "CFG-02.5", + "CFG-03.4", + "DCH-13.1", + "END-01", + "END-02", + "END-05" ], - "MP-06(01)": [ - "DCH-09.1" + "1.2.5": [ + "CFG-03", + "NET-06", + "NET-08.1", + "TDA-02.5", + "TPM-04.2" ], - "MP-06(02)": [ - "DCH-09.2" + "1.4.1": [ + "CFG-03", + "NET-02", + "NET-03", + "NET-03.8", + "NET-06", + "NET-08.1", + "NET-09", + "SEA-03" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "1.4.2": [ + "CFG-03", + "NET-03", + "NET-03.1", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "AC-20": [ - "DCH-13" + "11.6.1": [ + "CFG-03.1", + "MON-01.7", + "END-06", + "WEB-13" ], - "AC-20(01)": [ - "DCH-13.1" + "12.3.1": [ + "CFG-03.1", + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.2", + "RSK-07" ], - "AC-20(02)": [ - "DCH-13.2" + "10.4.3": [ + "MON-01", + "MON-01.4", + "MON-01.8" ], - "PM-17": [ - "DCH-13.3" + "1.4.3": [ + "MON-01.1", + "NET-04", + "NET-08", + "NET-08.2" ], - "CA-03(06)": [ - "DCH-14.2" + "11.5.1": [ + "MON-01.1", + "NET-03", + "NET-08", + "SAT-03.2" ], - "AC-22": [ - "DCH-15" + "10.4.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.2" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "10.4.1.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.1", + "MON-02.2" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "10.3.4": [ + "MON-01.7", + "END-06" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "11.5.2": [ + "MON-01.7", + "END-06" ], - "CM-12": [ - "DCH-24" + "10.4.2": [ + "MON-01.8" ], - "CM-12(01)": [ - "DCH-24.1" + "10.4.2.1": [ + "MON-01.8" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "10.3.3": [ + "MON-02", + "MON-02.2", + "MON-08.1" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "6.4.2": [ + "MON-03", + "IAO-04", + "TDA-15", + "VPM-05.1", + "WEB-01", + "WEB-03" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "10.3.1": [ + "MON-08", + "MON-08.2" ], - "SI-07(01)": [ - "END-06.1" + "10.3.2": [ + "MON-08", + "MON-08.2" ], - "SI-07(07)": [ - "END-06.2" + "10.5.1": [ + "MON-10", + "DCH-18", + "PRI-05" ], - "SI-07(02)": [ - "END-06.3" + "2.2.7": [ + "CRY-01", + "CRY-02", + "CRY-06", + "MNT-05.3" ], - "SI-07(05)": [ - "END-06.4" + "4.2.1": [ + "CRY-03", + "NET-12", + "NET-15.1" ], - "SI-08": [ - "END-08" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "SC-18": [ - "END-10" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "SC-41": [ - "END-12" + "3.3.1": [ + "DCH-06.5" ], - "SC-15": [ - "END-14" + "3.3.1.2": [ + "DCH-06.5" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "3.3.1.3": [ + "DCH-06.5" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "9.4.3": [ + "DCH-07", + "DCH-07.1" + ], + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "1.4.4": [ + "DCH-15", + "NET-05.1" ], - "PS-09": [ - "HRS-03" + "3.2.1": [ + "DCH-18", + "TPM-04.4" ], - "PS-03": [ - "HRS-04" + "11.4.1": [ + "DCH-18", + "IAO-04", + "TDA-15", + "VPM-07", + "VPM-07.1" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "5.2.1": [ + "END-04" ], - "PL-04(01)": [ - "HRS-05.2" + "5.2.2": [ + "END-04" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "5.3.1": [ + "END-04", + "END-04.1" ], - "PS-08": [ - "HRS-07" + "5.3.2": [ + "END-04", + "END-04.7" ], - "PS-05": [ - "HRS-08" + "5.3.2.1": [ + "END-04", + "END-04.7" ], - "PS-04": [ - "HRS-09" + "5.3.3": [ + "END-04", + "END-04.7" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "5.3.4": [ + "END-04", + "END-04.3" ], - "PS-04(02)": [ - "HRS-09.4" + "5.3.5": [ + "END-04", + "END-04.7" ], - "PS-07": [ - "HRS-10" + "5.2.3": [ + "END-04.6" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "5.2.3.1": [ + "END-04.6" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "5.4.1": [ + "END-08" ], - "IA-02": [ - "IAC-02" + "2.2.3": [ + "END-16", + "END-16.1", + "SEA-04.1" ], - "IA-02(05)": [ - "IAC-02.1" + "11.4.5": [ + "END-16", + "NET-06", + "NET-08.1", + "SEA-04.1", + "TDA-07", + "VPM-07", + "VPM-07.1" ], - "IA-02(08)": [ - "IAC-02.2" + "6.2.2": [ + "HRS-03.2", + "IAO-04", + "SAT-03", + "SAT-03.8", + "TDA-06.3", + "TDA-13", + "TDA-15" ], - "IA-02(12)": [ - "IAC-02.3" + "8.2.5": [ + "HRS-09", + "HRS-09.2", + "IAC-07.1", + "IAC-07.2", + "IAC-20.6" ], - "IA-08": [ - "IAC-03" + "8.3.3": [ + "IAC-01", + "IAC-02", + "IAC-10", + "IAC-10.1", + "IAC-28" ], - "IA-08(01)": [ - "IAC-03.1" + "8.5.1": [ + "IAC-01", + "IAC-02.2", + "IAC-06", + "SEA-01" ], - "IA-08(02)": [ - "IAC-03.2" + "8.6.1": [ + "IAC-01", + "IAC-05.1", + "IAC-15", + "IAC-15.7", + "IAC-19", + "IAC-20.3", + "IAC-21" ], - "IA-08(04)": [ - "IAC-03.3" + "8.3.9": [ + "IAC-02", + "IAC-10", + "IAC-10.1" ], - "IA-03": [ - "IAC-04" + "8.2.2": [ + "IAC-02.1", + "IAC-15.5", + "IAC-19" ], - "IA-02(01)": [ + "8.4.2": [ "IAC-06", "IAC-06.1", "IAC-06.2", "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "IAC-06.4" ], - "IA-02(02)": [ + "8.4.3": [ "IAC-06", "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "IAC-06.2" ], - "IA-12(04)": [ + "8.4.1": [ + "IAC-06.1" + ], + "7.2.3": [ "IAC-07", - "IAC-10.3", - "IAC-28.4" + "IAC-07.1", + "IAC-16", + "IAC-21.3" ], - "AC-02": [ + "8.2.4": [ + "IAC-07", + "IAC-07.1", "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "IAC-10", + "IAC-15" ], - "IA-05": [ + "8.3.5": [ + "IAC-07", "IAC-10", - "IAC-10.8" + "IAC-10.1" ], - "IA-05(01)": [ + "7.2.2": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" + ], + "7.2.5": [ + "IAC-08", + "IAC-16", + "IAC-20", + "IAC-20.1", + "NET-14" + ], + "8.2.1": [ + "IAC-09", + "IAC-09.1" + ], + "8.3.1": [ "IAC-10", "IAC-10.1", - "IAC-10.4" - ], - "IA-05(02)": [ "IAC-10.2" ], - "IA-05(06)": [ + "8.3.7": [ + "IAC-10", + "IAC-10.1" + ], + "8.3.11": [ + "IAC-10", + "IAC-10.2", "IAC-10.5", - "IAC-18" + "IAC-10.7", + "IAC-18", + "PES-02", + "PES-02.1" ], - "IA-06": [ - "IAC-11" + "8.6.3": [ + "IAC-10", + "IAC-10.1" ], - "IA-11": [ - "IAC-14" + "8.3.6": [ + "IAC-10.1" ], - "AC-02(01)": [ - "IAC-15.1" + "8.6.2": [ + "IAC-10.6" ], - "AC-02(02)": [ - "IAC-15.2" + "8.2.8": [ + "IAC-14", + "IAC-24", + "IAC-25", + "NET-07" ], - "AC-02(03)": [ + "8.2.6": [ "IAC-15.3" ], - "AC-02(04)": [ - "IAC-15.4" - ], - "AC-02(11)": [ - "IAC-15.8" - ], - "AC-06(07)": [ + "7.2.4": [ + "IAC-16.1", "IAC-17" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" - ], - "AC-06": [ - "IAC-20", - "IAC-21" - ], - "AC-06(01)": [ - "IAC-21.1" - ], - "AC-06(02)": [ - "IAC-21.2" - ], - "AC-06(05)": [ - "IAC-21.3" - ], - "AC-06(09)": [ - "IAC-21.4" - ], - "AC-06(10)": [ - "IAC-21.5" - ], - "AC-07": [ + "8.3.4": [ "IAC-22" ], - "AC-10": [ - "IAC-23" + "12.10.3": [ + "IRO-07" ], - "AC-02(05)": [ - "IAC-24" + "6.2.1": [ + "IAO-04", + "SEA-01", + "TDA-01", + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-15" ], - "AC-11": [ - "IAC-24" + "6.2.4": [ + "IAO-04", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5", + "TDA-15" ], - "AC-11(01)": [ - "IAC-24.1" + "6.4.1": [ + "IAO-04", + "TDA-15", + "VPM-05.1", + "VPM-06", + "VPM-06.6", + "WEB-01", + "WEB-03" ], - "AC-12": [ - "IAC-25" + "11.4.4": [ + "IAO-04", + "TDA-15", + "VPM-07" ], - "AC-14": [ - "IAC-26" + "8.2.7": [ + "MNT-05", + "MNT-05.1", + "MNT-05.4", + "NET-14", + "NET-14.6" ], - "IA-12": [ - "IAC-28" + "1.3.3": [ + "NET-02.2", + "NET-03", + "NET-03.7", + "NET-04.1", + "NET-04.7", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "IA-12(01)": [ - "IAC-28.1" + "1.4.5": [ + "NET-03.3", + "VPM-06.8" ], - "IA-12(02)": [ - "IAC-28.2" + "1.3.2": [ + "NET-03.5", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "IA-12(03)": [ - "IAC-28.3" + "1.3.1": [ + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "IA-12(05)": [ - "IAC-28.5" + "4.2.2": [ + "NET-12.2" ], - "IR-04": [ - "IRO-02" + "9.2.1": [ + "PES-02", + "PES-02.1", + "PES-03", + "PES-03.1", + "PES-03.3" ], - "IR-04(01)": [ - "IRO-02.1" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "IR-08": [ - "IRO-04" + "12.6.3.1": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "IR-02": [ - "IRO-05" + "2.2.6": [ + "TDA-05.1" ], - "IR-02(01)": [ - "IRO-05.1" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "IR-02(02)": [ - "IRO-05.2" + "12.8.3": [ + "TPM-04.1" ], - "IR-03": [ - "IRO-06" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "IR-03(02)": [ - "IRO-06.1" + "12.8.4": [ + "TPM-08" ], - "IR-04(11)": [ - "IRO-07" + "6.3.3": [ + "VPM-01", + "VPM-04", + "VPM-05", + "VPM-05.1" ], - "IR-05": [ - "IRO-09" + "11.3.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.6" ], - "IR-05(01)": [ - "IRO-09.1" + "11.3.2.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.2", + "VPM-06.6" ], - "IR-06(01)": [ - "IRO-10.1" + "6.4.3": [ + "VPM-05.1", + "WEB-01.1" ], - "IR-06(03)": [ - "IRO-10.4" + "11.4.3": [ + "VPM-07", + "VPM-07.1" + ] + }, + "general-pci-dss-4-0-1-saq-b": { + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "IR-07": [ - "IRO-11" + "12.1.1": [ + "GOV-02", + "GOV-03" ], - "IR-07(01)": [ - "IRO-11.1" + "12.1.2": [ + "GOV-02", + "GOV-03" ], - "PM-10": [ - "IAO-01" + "12.1.3": [ + "GOV-02", + "GOV-04", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1" ], - "CA-02(01)": [ - "IAO-02.1" + "9.5.1": [ + "AST-01", + "AST-02", + "AST-06", + "AST-07", + "AST-15", + "AST-15.1", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "CA-02(02)": [ - "IAO-02.2" + "9.5.1.1": [ + "AST-01", + "AST-02", + "AST-07" ], - "CA-05": [ - "IAO-05" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "9.5.1.2": [ + "AST-07", + "AST-08", + "AST-15.1" ], - "CM-04(02)": [ - "IAO-06" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "CA-06": [ - "IAO-07" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "MA-02": [ - "MNT-02" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "MA-02(02)": [ - "MNT-02.1" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "MA-06": [ - "MNT-03" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "MA-03": [ - "MNT-04" + "3.4.1": [ + "DCH-03.2", + "END-16", + "PRI-05.3" ], - "MA-03(01)": [ - "MNT-04.1" + "3.3.1": [ + "DCH-06.5" ], - "MA-03(02)": [ - "MNT-04.2" + "3.3.1.1": [ + "DCH-06.5" ], - "MA-03(03)": [ - "MNT-04.3" + "3.3.1.2": [ + "DCH-06.5" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "3.3.1.3": [ + "DCH-06.5" ], - "MA-04(01)": [ - "MNT-05.1" + "9.4.3": [ + "DCH-07", + "DCH-07.1" ], - "MA-04(03)": [ - "MNT-05.6" + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "MA-05": [ - "MNT-06" + "7.2.2": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "MA-05(01)": [ - "MNT-06.1" + "9.5.1.3": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "SR-11(02)": [ - "MNT-07" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "MA-07": [ - "MNT-08" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "AC-19": [ - "MDM-02" + "12.8.3": [ + "TPM-04.1" ], - "AC-19(05)": [ - "MDM-03" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "SC-07": [ - "NET-03" + "12.8.4": [ + "TPM-08" + ] + }, + "general-pci-dss-4-0-1-saq-b-ip": { + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-07(03)": [ - "NET-03.1" + "8.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-07(04)": [ - "NET-03.2" + "9.1.1": [ + "GOV-02", + "GOV-03", + "PES-01", + "OPS-01", + "OPS-01.1" ], - "SC-07(21)": [ - "NET-03.7" + "12.1.1": [ + "GOV-02", + "GOV-03" ], - "AC-04": [ - "NET-04" + "12.1.2": [ + "GOV-02", + "GOV-03" ], - "SC-07(05)": [ - "NET-04.1" + "12.1.3": [ + "GOV-02", + "GOV-04", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1" ], - "AC-04(04)": [ - "NET-04.3" + "6.3.1": [ + "GOV-07", + "IAO-04", + "TDA-15", + "THR-03", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-05.1" ], - "CA-03": [ - "NET-05" + "9.5.1": [ + "AST-01", + "AST-02", + "AST-06", + "AST-07", + "AST-15", + "AST-15.1", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "CA-09": [ - "NET-05.2" + "9.5.1.1": [ + "AST-01", + "AST-02", + "AST-07" ], - "SC-07(28)": [ - "NET-06.5" + "2.2.2": [ + "AST-03", + "IAC-10.8" ], - "SC-23": [ - "NET-09" + "1.2.3": [ + "AST-04", + "AST-04.2", + "NET-02.2", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "SC-20": [ - "NET-10" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "SC-22": [ - "NET-10.1" + "9.5.1.2": [ + "AST-07", + "AST-08", + "AST-15.1" ], - "SC-21": [ - "NET-10.2" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "SI-10": [ - "NET-12", - "TDA-18" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "AC-17": [ - "NET-14" + "1.2.6": [ + "CFG-02", + "CFG-03", + "NET-06", + "NET-08.1", + "RSK-06.2", + "TDA-02.6" ], - "AC-17(01)": [ - "NET-14.1" + "1.2.5": [ + "CFG-03", + "NET-06", + "NET-08.1", + "TDA-02.5", + "TPM-04.2" ], - "AC-17(02)": [ - "NET-14.2" + "1.4.2": [ + "CFG-03" ], - "AC-17(03)": [ - "NET-14.3" + "1.4.3": [ + "MON-01.1", + "NET-04", + "NET-08", + "NET-08.2" ], - "AC-17(04)": [ - "NET-14.4" + "2.2.7": [ + "CRY-01", + "CRY-02", + "CRY-06", + "MNT-05.3" ], - "AC-17(09)": [ - "NET-14.8" + "A2.1.1": [ + "CRY-03", + "WEB-10" ], - "AC-18(01)": [ + "2.3.1": [ + "CRY-07", + "IAC-10.8", + "NET-12.1", "NET-15.1" ], - "AC-18(03)": [ - "NET-15.2" - ], - "AC-18(04)": [ - "NET-15.3" - ], - "AC-18(05)": [ - "NET-15.4" - ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" - ], - "SI-04(10)": [ - "NET-18.2" - ], - "PE-02": [ - "PES-02" - ], - "PE-03": [ - "PES-03" - ], - "PE-08": [ - "PES-03.3" - ], - "PE-03(01)": [ - "PES-03.4" - ], - "PE-06": [ - "PES-05" - ], - "PE-06(01)": [ - "PES-05.1" + "2.3.2": [ + "CRY-07", + "CRY-09.3", + "NET-12.1", + "NET-15.1" ], - "PE-06(04)": [ - "PES-05.2" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "PE-08(01)": [ - "PES-06.4" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "PE-09": [ - "PES-07" + "3.4.1": [ + "DCH-03.2", + "END-16", + "PRI-05.3" ], - "PE-10": [ - "PES-07.2" + "3.3.1": [ + "DCH-06.5" ], - "PE-11": [ - "PES-07.3" + "3.3.1.1": [ + "DCH-06.5" ], - "PE-11(01)": [ - "PES-07.3" + "3.3.1.2": [ + "DCH-06.5" ], - "PE-12": [ - "PES-07.4" + "3.3.1.3": [ + "DCH-06.5" ], - "PE-15": [ - "PES-07.5" + "9.4.3": [ + "DCH-07", + "DCH-07.1" ], - "PE-15(01)": [ - "PES-07.6" + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "PE-13": [ - "PES-08" + "11.4.5": [ + "END-16", + "NET-06", + "NET-08.1", + "SEA-04.1", + "TDA-07", + "VPM-07", + "VPM-07.1" ], - "PE-13(01)": [ - "PES-08.1" + "8.2.2": [ + "IAC-02.1", + "IAC-15.5", + "IAC-19" ], - "PE-13(02)": [ - "PES-08.3" + "8.4.3": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2" ], - "PE-14": [ - "PES-09" + "7.2.2": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "PE-16": [ - "PES-10" + "8.2.7": [ + "MNT-05", + "MNT-05.1", + "MNT-05.4", + "NET-14", + "NET-14.6" ], - "PE-17": [ - "PES-11" + "1.3.3": [ + "NET-02.2", + "NET-03", + "NET-03.7", + "NET-04.1", + "NET-04.7", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "PE-18": [ - "PES-12" + "1.3.2": [ + "NET-03.5", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "PE-04": [ - "PES-12.1" + "1.3.1": [ + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "PE-05": [ + "9.2.2": [ + "PES-12", + "PES-12.1", "PES-12.2" ], - "PM-18": [ - "PRI-01" + "9.5.1.3": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "PM-19": [ - "PRI-01.1" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "PM-20": [ - "PRI-01.3" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "PM-20(01)": [ - "PRI-02" + "12.8.3": [ + "TPM-04.1" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "AC-21": [ - "PRI-07" + "12.8.4": [ + "TPM-08" ], - "PM-27": [ - "PRI-14" + "6.3.3": [ + "VPM-01", + "VPM-04", + "VPM-05", + "VPM-05.1" ], - "PM-21": [ - "PRI-14.1" + "11.3.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.6" + ] + }, + "general-pci-dss-4-0-1-saq-c": { + "2.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "PM-03": [ - "PRM-02" + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SA-02": [ - "PRM-03" + "5.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "PM-11": [ - "PRM-06" + "8.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "8.3.8": [ + "GOV-02", + "IAC-01", + "OPS-01", + "OPS-01.1", + "SAT-01", + "SAT-02", + "SAT-03" + ], + "9.1.1": [ + "GOV-02", + "GOV-03", + "PES-01", + "OPS-01", + "OPS-01.1" ], - "PM-09": [ - "RSK-01" + "10.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "PM-28": [ - "RSK-01.1" + "12.1.1": [ + "GOV-02", + "GOV-03" ], - "RA-02": [ - "RSK-02" + "12.1.2": [ + "GOV-02", + "GOV-03" ], - "RA-07": [ - "RSK-06.1" + "12.1.3": [ + "GOV-02", + "GOV-04", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1" ], - "PM-30": [ - "RSK-09" + "6.3.1": [ + "GOV-07", + "IAO-04", + "TDA-15", + "THR-03", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-05.1" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "9.5.1": [ + "AST-01", + "AST-02", + "AST-06", + "AST-07", + "AST-15", + "AST-15.1", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "RA-03(01)": [ - "RSK-09.1" + "9.5.1.1": [ + "AST-01", + "AST-02", + "AST-07" ], - "CA-07(04)": [ - "RSK-11" + "11.2.2": [ + "AST-01", + "AST-02", + "NET-02.2", + "NET-12.1", + "NET-15" ], - "SC-07(18)": [ - "SEA-01" + "2.2.2": [ + "AST-03", + "IAC-10.8" ], - "PL-08": [ - "SEA-02" + "2.2.4": [ + "AST-03", + "CFG-03", + "RSK-06.2" ], - "PM-07": [ - "SEA-02" + "2.2.5": [ + "AST-03", + "TDA-02.6" ], - "SC-02": [ - "SEA-03.2" + "6.5.2": [ + "AST-03", + "CHG-01", + "CHG-02.2", + "CHG-03", + "CHG-06", + "CHG-06.1", + "IAC-10.8" ], - "SC-39": [ - "SEA-04" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "SC-04": [ - "SEA-05" + "9.5.1.2": [ + "AST-07", + "AST-08", + "AST-15.1" ], - "CM-07(02)": [ - "SEA-06" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "CP-12": [ - "SEA-07.2" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "SC-24": [ - "SEA-07.2" + "6.5.1": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "OPS-01.1" ], - "SI-17": [ - "SEA-07.3" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "SI-16": [ - "SEA-10" + "2.2.1": [ + "CFG-02" ], - "AC-08": [ - "SEA-18" + "8.3.2": [ + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-05" ], - "AT-02": [ - "SAT-02" + "10.2.1.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3", + "IAC-21.4" ], - "AT-02(03)": [ - "SAT-02.2" + "10.2.1.4": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "AT-03": [ - "SAT-03" + "10.2.1.5": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "AT-02(04)": [ - "SAT-03.2" + "10.2.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "AT-04": [ - "SAT-04" + "10.6.1": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "10.6.2": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "SA-04(09)": [ - "TDA-02.1" + "10.6.3": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "SA-04(10)": [ - "TDA-02.2" + "12.3.1": [ + "CFG-03.1", + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.2", + "RSK-07" ], - "SA-04(05)": [ - "TDA-02.4" + "10.4.3": [ + "MON-01", + "MON-01.4", + "MON-01.8" ], - "SA-17": [ - "TDA-05" + "10.4.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.2" ], - "SA-15": [ - "TDA-06" + "10.4.1.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.1", + "MON-02.2" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "10.3.4": [ + "MON-01.7", + "END-06" ], - "SA-15(03)": [ - "TDA-06.1" + "11.5.2": [ + "MON-01.7", + "END-06" ], - "CM-04(01)": [ - "TDA-08" + "10.4.2": [ + "MON-01.8" ], - "SA-11": [ - "TDA-09" + "10.4.2.1": [ + "MON-01.8" ], - "SR-11": [ - "TDA-11" + "10.3.3": [ + "MON-02", + "MON-02.2", + "MON-08.1" ], - "SR-11(01)": [ - "TDA-11.1" + "10.3.1": [ + "MON-08", + "MON-08.2" ], - "SA-21": [ - "TDA-13" + "10.3.2": [ + "MON-08", + "MON-08.2" ], - "SA-10": [ - "TDA-14" + "10.5.1": [ + "MON-10", + "DCH-18", + "PRI-05" ], - "SA-16": [ - "TDA-16" + "2.2.7": [ + "CRY-01", + "CRY-02", + "CRY-06", + "MNT-05.3" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "4.2.1": [ + "CRY-03", + "NET-12", + "NET-15.1" ], - "SI-11": [ - "TDA-19" + "4.2.1.2": [ + "CRY-03", + "CRY-07", + "NET-12.1" ], - "RA-09": [ - "TPM-02" + "A2.1.1": [ + "CRY-03", + "WEB-10" ], - "SR-02(01)": [ - "TPM-03" + "2.3.1": [ + "CRY-07", + "IAC-10.8", + "NET-12.1", + "NET-15.1" ], - "SR-05": [ - "TPM-03.1" + "2.3.2": [ + "CRY-07", + "CRY-09.3", + "NET-12.1", + "NET-15.1" ], - "SR-03": [ - "TPM-03.3" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "SR-05(01)": [ - "TPM-03.4" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "SA-09": [ - "TPM-04" + "3.4.1": [ + "DCH-03.2", + "END-16", + "PRI-05.3" ], - "SA-09(02)": [ - "TPM-04.2" + "3.3.1": [ + "DCH-06.5" ], - "SR-08": [ - "TPM-05.1" + "3.3.1.2": [ + "DCH-06.5" ], - "SR-06": [ - "TPM-08" + "3.3.1.3": [ + "DCH-06.5" ], - "PM-16": [ - "THR-01" + "9.4.3": [ + "DCH-07", + "DCH-07.1" ], - "PM-12": [ - "THR-04" + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "AT-02(02)": [ - "THR-05" + "5.2.1": [ + "END-04" ], - "RA-05(11)": [ - "THR-06" + "5.2.2": [ + "END-04" ], - "SI-02(02)": [ - "VPM-05.2" + "5.3.1": [ + "END-04", + "END-04.1" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "5.3.2": [ + "END-04", + "END-04.7" ], - "RA-05(02)": [ - "VPM-06.1" + "5.3.2.1": [ + "END-04", + "END-04.7" ], - "RA-05(05)": [ - "VPM-06.3" + "5.3.3": [ + "END-04", + "END-04.7" ], - "RA-05(04)": [ - "VPM-06.8" + "5.3.4": [ + "END-04", + "END-04.3" ], - "CA-08": [ - "VPM-07" - ] - }, - "general-nist-800-160-vol-2-r1": { - "PM-32": [ - "GOV-11" + "5.3.5": [ + "END-04", + "END-04.7" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "5.2.3": [ + "END-04.6" ], - "SR-04": [ - "AST-03.2" + "5.2.3.1": [ + "END-04.6" ], - "SR-04(01)": [ - "AST-03.2" + "5.4.1": [ + "END-08" ], - "SR-04(02)": [ - "AST-03.2" + "2.2.3": [ + "END-16", + "END-16.1", + "SEA-04.1" ], - "SR-09": [ - "AST-15" + "11.4.5": [ + "END-16", + "NET-06", + "NET-08.1", + "SEA-04.1", + "TDA-07", + "VPM-07", + "VPM-07.1" ], - "SR-09(01)": [ - "AST-15" + "12.2.1": [ + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "6.2.2": [ + "HRS-03.2", + "IAO-04", + "SAT-03", + "SAT-03.8", + "TDA-06.3", + "TDA-13", + "TDA-15" ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" + "8.2.5": [ + "HRS-09", + "HRS-09.2", + "IAC-07.1", + "IAC-07.2", + "IAC-20.6" ], - "CP-02(01)": [ - "BCD-01.1" + "8.3.3": [ + "IAC-01", + "IAC-02", + "IAC-10", + "IAC-10.1", + "IAC-28" ], - "CP-02(08)": [ - "BCD-02" + "8.5.1": [ + "IAC-01", + "IAC-02.2", + "IAC-06", + "SEA-01" ], - "CP-02(05)": [ - "BCD-02.2" + "8.6.1": [ + "IAC-01", + "IAC-05.1", + "IAC-15", + "IAC-15.7", + "IAC-19", + "IAC-20.3", + "IAC-21" ], - "CP-13": [ - "BCD-07" + "8.3.9": [ + "IAC-02", + "IAC-10", + "IAC-10.1" ], - "CP-11": [ - "BCD-10" + "8.2.2": [ + "IAC-02.1", + "IAC-15.5", + "IAC-19" ], - "CP-08(03)": [ - "BCD-10.2" + "8.4.2": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4" ], - "SC-47": [ - "BCD-10.4" + "8.4.3": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2" ], - "CP-09": [ - "BCD-11" + "8.4.1": [ + "IAC-06.1" ], - "CP-09(01)": [ - "BCD-11.1" + "7.2.3": [ + "IAC-07", + "IAC-07.1", + "IAC-16", + "IAC-21.3" ], - "CP-09(08)": [ - "BCD-11.4" + "8.2.4": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-15" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "8.3.5": [ + "IAC-07", + "IAC-10", + "IAC-10.1" ], - "CP-09(06)": [ - "BCD-11.7" + "7.2.2": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CP-09(07)": [ - "BCD-11.8" + "7.2.5": [ + "IAC-08", + "IAC-16", + "IAC-20", + "IAC-20.1", + "NET-14" ], - "SC-05(03)": [ - "CAP-01" + "8.2.1": [ + "IAC-09", + "IAC-09.1" ], - "SC-05(02)": [ - "CAP-02", - "CAP-03" + "8.3.1": [ + "IAC-10", + "IAC-10.1", + "IAC-10.2" ], - "SA-08(31)": [ - "CHG-02", - "CHG-02.2", - "CHG-06" + "8.3.7": [ + "IAC-10", + "IAC-10.1" ], - "CM-14": [ - "CHG-04.2" + "8.6.3": [ + "IAC-10", + "IAC-10.1" ], - "SI-07(15)": [ - "CHG-04.2" + "8.3.6": [ + "IAC-10.1" ], - "CM-05(04)": [ - "CHG-04.3" + "8.6.2": [ + "IAC-10.6" ], - "CM-05(05)": [ - "CHG-04.4" + "8.2.8": [ + "IAC-14", + "IAC-24", + "IAC-25", + "NET-07" ], - "CM-05(06)": [ - "CHG-04.5" + "8.2.6": [ + "IAC-15.3" ], - "SI-06": [ - "CHG-06" + "7.2.4": [ + "IAC-16.1", + "IAC-17" ], - "SC-07(29)": [ - "CLD-03", - "NET-03.8", - "NET-06.1" + "8.3.4": [ + "IAC-22" ], - "SA-15(05)": [ - "CFG-02", - "SEA-01" + "12.10.3": [ + "IRO-07" ], - "CM-02(07)": [ - "CFG-02.5" + "6.2.1": [ + "IAO-04", + "SEA-01", + "TDA-01", + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-15" ], - "CM-07(06)": [ - "CFG-02.5" + "6.2.3.1": [ + "IAO-04", + "TDA-09", + "TDA-15" ], - "CM-07(07)": [ - "CFG-02.5" + "6.2.4": [ + "IAO-04", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5", + "TDA-15" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" + "8.2.7": [ + "MNT-05", + "MNT-05.1", + "MNT-05.4", + "NET-14", + "NET-14.6" ], - "CM-07(04)": [ - "CFG-03.3" + "11.2.1": [ + "NET-01", + "NET-02.2", + "NET-03.1", + "NET-12.1", + "NET-15", + "NET-15.5" ], - "CM-07(05)": [ - "CFG-03.3" + "1.3.3": [ + "NET-02.2", + "NET-03", + "NET-03.7", + "NET-04.1", + "NET-04.7", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "AC-03(11)": [ - "CFG-08" + "1.3.2": [ + "NET-03.5", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "PM-31": [ - "MON-01" + "1.3.1": [ + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "SI-04(01)": [ - "MON-01.1" + "4.2.2": [ + "NET-12.2" ], - "SI-04(25)": [ - "MON-01.1", - "NET-03.1" + "9.2.1": [ + "PES-02", + "PES-02.1", + "PES-03", + "PES-03.1", + "PES-03.3" ], - "SC-48": [ - "MON-01.2", - "THR-07" + "9.2.1.1": [ + "PES-03.3", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "SI-04(02)": [ - "MON-01.2" + "9.2.2": [ + "PES-12", + "PES-12.1", + "PES-12.2" ], - "SI-04(04)": [ - "MON-01.3" + "9.5.1.3": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "SI-04(07)": [ - "MON-01.11", - "IRO-02.1" + "12.6.3.1": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "SI-04(13)": [ - "MON-01.13" + "2.2.6": [ + "TDA-05.1" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "12.8.3": [ + "TPM-04.1" ], - "AU-06(03)": [ - "MON-02.1" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "AU-06(09)": [ - "MON-02.1" + "12.8.4": [ + "TPM-08" ], - "SI-04(16)": [ - "MON-02.1" + "6.3.3": [ + "VPM-01", + "VPM-04", + "VPM-05", + "VPM-05.1" ], - "AU-06(05)": [ - "MON-02.3" + "11.3.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.1", + "VPM-06.2", + "VPM-06.7" ], - "SI-04(17)": [ - "MON-02.3" + "11.3.1.3": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.7" ], - "AU-06(06)": [ - "MON-02.4" + "11.3.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.6" ], - "AU-06(08)": [ - "MON-03.3" + "11.3.2.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.2", + "VPM-06.6" + ] + }, + "general-pci-dss-4-0-1-saq-c-vt": { + "2.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "CA-07(03)": [ - "MON-06.2" + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-09(02)": [ - "MON-08.1" + "8.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AU-09(03)": [ - "MON-08.3" + "9.1.1": [ + "GOV-02", + "GOV-03", + "PES-01", + "OPS-01", + "OPS-01.1" ], - "AU-09(05)": [ - "MON-08.4" + "12.1.1": [ + "GOV-02", + "GOV-03" ], - "AU-10(02)": [ - "MON-09.1" + "12.1.2": [ + "GOV-02", + "GOV-03" ], - "AU-13": [ - "MON-11" + "6.3.1": [ + "GOV-07", + "IAO-04", + "TDA-15", + "THR-03", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-05.1" ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" + "2.2.2": [ + "AST-03", + "IAC-10.8" ], - "AC-02(12)": [ - "MON-16" + "2.2.4": [ + "AST-03", + "CFG-03", + "RSK-06.2" ], - "IR-04(13)": [ - "MON-16", - "SEA-11", - "SEA-12" + "2.2.5": [ + "AST-03", + "TDA-02.6" ], - "SI-04(11)": [ - "MON-16" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "SI-07(06)": [ - "CRY-01" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "SC-08(04)": [ - "CRY-01.4" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "SC-16(01)": [ - "CRY-04", - "CRY-10" + "1.5.1": [ + "CFG-02.5", + "CFG-03.4", + "DCH-13.1", + "END-01", + "END-02", + "END-05" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "2.2.7": [ + "CRY-01", + "CRY-02", + "CRY-06", + "MNT-05.3" ], - "SI-19(04)": [ - "DCH-23.4", - "PRI-05.3" + "4.2.1.2": [ + "CRY-03", + "CRY-07", + "NET-12.1" ], - "SI-19(06)": [ - "DCH-23.6" + "2.3.1": [ + "CRY-07", + "IAC-10.8", + "NET-12.1", + "NET-15.1" ], - "SI-19(08)": [ - "DCH-23.8" + "2.3.2": [ + "CRY-07", + "CRY-09.3", + "NET-12.1", + "NET-15.1" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "SI-07(01)": [ - "END-06.1" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "SI-07(07)": [ - "END-06.2" + "3.4.1": [ + "DCH-03.2", + "END-16", + "PRI-05.3" ], - "SI-07(05)": [ - "END-06.4" + "3.3.1": [ + "DCH-06.5" ], - "SI-07(09)": [ - "END-06.5" + "3.3.1.2": [ + "DCH-06.5" ], - "SI-07(10)": [ - "END-06.6" + "9.4.3": [ + "DCH-07", + "DCH-07.1" ], - "SC-11": [ - "END-09" + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "SC-27": [ - "END-10" + "5.2.1": [ + "END-04" ], - "SC-25": [ - "END-11" + "5.2.2": [ + "END-04" ], - "SC-15(01)": [ - "END-14" + "5.3.1": [ + "END-04", + "END-04.1" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "5.3.2": [ + "END-04", + "END-04.7" ], - "AC-03(02)": [ - "HRS-12.1", - "IAC-20.5" + "5.3.3": [ + "END-04", + "END-04.7" ], - "IA-02(13)": [ - "IAC-02.4" + "5.3.4": [ + "END-04", + "END-04.3" ], - "IA-03(01)": [ - "IAC-04" + "5.3.5": [ + "END-04", + "END-04.7" ], - "AC-06(06)": [ - "IAC-05.2" + "5.4.1": [ + "END-08" + ], + "8.2.5": [ + "HRS-09", + "HRS-09.2", + "IAC-07.1", + "IAC-07.2", + "IAC-20.6" ], - "IA-02(06)": [ - "IAC-06.4" + "8.2.2": [ + "IAC-02.1", + "IAC-15.5", + "IAC-19" ], - "IA-10": [ - "IAC-13" + "8.4.1": [ + "IAC-06.1" ], - "AC-06(07)": [ - "IAC-17" + "8.2.4": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-15" ], - "AC-06": [ + "7.2.2": [ + "IAC-08", "IAC-20", + "IAC-20.1", "IAC-21" ], - "AC-06(01)": [ - "IAC-21.1" - ], - "AC-06(02)": [ - "IAC-21.2" + "8.2.1": [ + "IAC-09", + "IAC-09.1" ], - "AC-06(05)": [ - "IAC-21.3" + "8.3.1": [ + "IAC-10", + "IAC-10.1", + "IAC-10.2" ], - "AC-06(10)": [ - "IAC-21.5" + "8.3.6": [ + "IAC-10.1" ], - "AC-06(03)": [ - "IAC-21.6" + "1.3.3": [ + "NET-02.2", + "NET-03", + "NET-03.7", + "NET-04.1", + "NET-04.7", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "AC-06(08)": [ - "IAC-21.7" + "1.3.2": [ + "NET-03.5", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "AC-12": [ - "IAC-25" + "1.3.1": [ + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "IR-04(02)": [ - "IRO-02.3" + "9.2.1": [ + "PES-02", + "PES-02.1", + "PES-03", + "PES-03.1", + "PES-03.3" ], - "IR-04(11)": [ - "IRO-07" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "IR-04(12)": [ - "IRO-08", - "IRO-13" + "12.6.3.1": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "IR-05": [ - "IRO-09" + "2.2.6": [ + "TDA-05.1" ], - "IR-04(10)": [ - "IRO-10.4", - "TPM-11" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "SC-44": [ - "IRO-15" + "12.8.3": [ + "TPM-04.1" ], - "SA-11(05)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "MA-04(04)": [ - "MNT-05.7" + "12.8.4": [ + "TPM-08" ], - "PE-03(05)": [ - "MDM-04" + "6.3.3": [ + "VPM-01", + "VPM-04", + "VPM-05", + "VPM-05.1" + ] + }, + "general-pci-dss-4-0-1-saq-d-merchant": { + "1.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-46": [ - "NET-02.3" + "2.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-07": [ - "NET-03" + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-07(11)": [ - "NET-03", - "NET-04.1" + "3.7.1": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "SC-07(16)": [ - "NET-03.3" + "3.7.2": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "SC-07(10)": [ - "NET-03.5", - "NET-17" + "3.7.3": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "SC-07(20)": [ - "NET-03.6" + "3.7.5": [ + "GOV-02", + "CRY-04", + "CRY-09", + "CRY-09.3", + "OPS-01.1" ], - "SC-07(21)": [ - "NET-03.7" + "3.7.6": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "SC-07(22)": [ - "NET-03.8" + "3.7.7": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "AC-04(08)": [ - "NET-04.7" + "3.7.8": [ + "GOV-02", + "HRS-03", + "OPS-01.1" ], - "AC-04(12)": [ - "NET-04.8" + "4.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AC-04(17)": [ - "NET-04.12" + "5.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AC-04(21)": [ - "NET-06" + "6.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-07(13)": [ - "NET-06.1" + "7.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-10": [ - "NET-07" + "8.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-23(03)": [ - "NET-09.2" + "8.3.8": [ + "GOV-02", + "IAC-01", + "OPS-01", + "OPS-01.1", + "SAT-01", + "SAT-02", + "SAT-03" ], - "SC-22": [ - "NET-10.1" + "9.1.1": [ + "GOV-02", + "GOV-03", + "PES-01", + "OPS-01", + "OPS-01.1" ], - "SC-37": [ - "NET-11" + "10.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SI-04(10)": [ - "NET-18.2" + "11.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "SC-07(15)": [ - "NET-18.3" + "12.1.1": [ + "GOV-02", + "GOV-03" ], - "PE-06": [ - "PES-05" + "12.1.2": [ + "GOV-02", + "GOV-03" ], - "PE-06(04)": [ - "PES-05.2" + "12.1.3": [ + "GOV-02", + "GOV-04", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1" ], - "PE-11(01)": [ - "PES-07.3" + "1.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1", + "SAT-03", + "SAT-03.5" ], - "PE-11(02)": [ - "PES-07.3" + "2.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "PE-09(01)": [ - "PES-07.7" + "3.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "PE-17": [ - "PES-11" + "4.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "5.1.2": [ + "GOV-04", + "END-04.2", + "HRS-03", + "HRS-03.1" ], - "SR-07": [ - "RSK-09", - "OPS-01" + "6.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "PM-07(01)": [ - "SEA-02.2" + "7.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "PL-08(01)": [ - "SEA-03" + "8.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "SC-03(05)": [ - "SEA-03" + "9.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1", + "PES-03" ], - "SC-32": [ - "SEA-03.1" + "10.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "SC-02": [ - "SEA-03.2" + "11.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "SC-02(01)": [ - "SEA-03.2" + "12.1.4": [ + "GOV-04", + "IRO-10" ], - "SC-39": [ - "SEA-04" + "6.3.1": [ + "GOV-07", + "IAO-04", + "TDA-15", + "THR-03", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-05.1" ], - "SC-39(01)": [ - "SEA-04.2" + "6.3.2": [ + "AST-01", + "AST-02", + "AST-04.3", + "TDA-04.2", + "VPM-01.1", + "VPM-05.1" ], - "SC-39(02)": [ - "SEA-04.3" + "9.5.1": [ + "AST-01", + "AST-02", + "AST-06", + "AST-07", + "AST-15", + "AST-15.1", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "CP-12": [ - "SEA-07.2" + "9.5.1.1": [ + "AST-01", + "AST-02", + "AST-07" ], - "SI-14": [ - "SEA-08" + "11.2.2": [ + "AST-01", + "AST-02", + "NET-02.2", + "NET-12.1", + "NET-15" ], - "SI-14(01)": [ - "SEA-08.1" + "2.2.2": [ + "AST-03", + "IAC-10.8" ], - "SI-15": [ - "SEA-09" + "2.2.4": [ + "AST-03", + "CFG-03", + "RSK-06.2" ], - "SI-16": [ - "SEA-10" + "2.2.5": [ + "AST-03", + "TDA-02.6" ], - "SC-26": [ - "SEA-11" + "6.5.2": [ + "AST-03", + "CHG-01", + "CHG-02.2", + "CHG-03", + "CHG-06", + "CHG-06.1", + "IAC-10.8" ], - "SC-35": [ - "SEA-12" + "1.2.3": [ + "AST-04", + "AST-04.2", + "NET-02.2", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "SC-29": [ - "SEA-13" + "1.2.4": [ + "AST-04", + "NET-06", + "NET-08.1", + "TDA-02.1" ], - "SC-29(01)": [ - "SEA-13.1" + "12.5.1": [ + "AST-04.3", + "CPL-01.2", + "PRI-05.5" ], - "SC-30": [ - "SEA-14" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "SC-30(04)": [ - "SEA-14" + "9.5.1.2": [ + "AST-07", + "AST-08", + "AST-15.1" ], - "SC-30(05)": [ - "SEA-14" + "9.5.1.2.1": [ + "AST-08" ], - "SC-30(02)": [ - "SEA-14.1" + "9.4.7": [ + "AST-09", + "DCH-09", + "DCH-09.1", + "DCH-18", + "PRI-05" ], - "SC-30(03)": [ - "SEA-14.2" + "9.4.1.2": [ + "BCD-02.4", + "BCD-11", + "DCH-06", + "DCH-06.1", + "DCH-06.2" ], - "SC-36": [ - "SEA-15" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "SC-34": [ - "SEA-16" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "AT-02(01)": [ - "SAT-02.1" + "1.2.2": [ + "CHG-01", + "CHG-02", + "CHG-02.1" ], - "AT-02(03)": [ - "SAT-02.2" + "6.5.1": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "OPS-01.1" ], - "AT-03(03)": [ - "SAT-03.1" + "6.5.3": [ + "CHG-01", + "TDA-07", + "TDA-08" ], - "AT-02(05)": [ - "SAT-03.2" + "6.5.6": [ + "CHG-02", + "CHG-03", + "CFG-02.4", + "TDA-08", + "TDA-08.1", + "TDA-09" ], - "SA-23": [ - "TDA-01", - "TDA-01.1", - "TDA-12" + "1.2.8": [ + "CHG-04", + "CFG-02.6", + "NET-06", + "NET-08.1" ], - "SR-03(01)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "10.7.3": [ + "CHG-06", + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "IRO-01", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "TPM-11" ], - "PL-08(02)": [ - "TDA-03.1" + "1.2.1": [ + "CLD-01", + "CFG-02", + "CFG-02.5", + "NET-06", + "NET-08.1", + "SEA-03" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "SA-11(02)": [ - "TDA-06.2", - "TDA-15" + "12.5.2": [ + "CPL-01.2", + "CFG-03.1", + "NET-06", + "NET-08.1", + "TPM-04.4" ], - "CM-04(01)": [ - "TDA-08" + "10.7.2": [ + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "IRO-01", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "TPM-11" ], - "SA-11(06)": [ - "TDA-09", - "VPM-01.1" + "1.2.7": [ + "CPL-03.2", + "CFG-03.1", + "NET-04.6", + "NET-06", + "NET-08.1" ], - "SA-03(02)": [ - "TDA-10" + "1.2.6": [ + "CFG-02", + "CFG-03", + "NET-06", + "NET-08.1", + "RSK-06.2", + "TDA-02.6" ], - "SR-04(03)": [ - "TDA-11" + "2.2.1": [ + "CFG-02" ], - "SR-04(04)": [ - "TDA-11" + "8.3.2": [ + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-05" ], - "SR-11": [ - "TDA-11" + "10.2.1": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "SR-11(03)": [ - "TDA-11" + "10.2.1.1": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "SA-20": [ - "TDA-12" + "10.2.1.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3", + "IAC-21.4" ], - "SR-05": [ - "TPM-03.1" + "10.2.1.3": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "SR-03(02)": [ - "TPM-03.2" + "10.2.1.4": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "SR-05(01)": [ - "TPM-03.4" + "10.2.1.5": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "SR-06(01)": [ - "TPM-08" + "10.2.1.6": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "PM-16": [ - "THR-01" + "10.2.1.7": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "PM-16(01)": [ - "THR-03" + "10.2.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "RA-10": [ - "THR-07" + "10.6.1": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "SI-20": [ - "THR-08" + "10.6.2": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "RA-05(05)": [ - "VPM-06.3" + "10.6.3": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "RA-05(06)": [ - "VPM-06.4" + "1.5.1": [ + "CFG-02.5", + "CFG-03.4", + "DCH-13.1", + "END-01", + "END-02", + "END-05" ], - "RA-05(08)": [ - "VPM-06.5" + "1.2.5": [ + "CFG-03", + "NET-06", + "NET-08.1", + "TDA-02.5", + "TPM-04.2" ], - "RA-05(04)": [ - "VPM-06.8" + "1.4.1": [ + "CFG-03", + "NET-02", + "NET-03", + "NET-03.8", + "NET-06", + "NET-08.1", + "NET-09", + "SEA-03" ], - "RA-05(10)": [ - "VPM-06.9" + "1.4.2": [ + "CFG-03", + "NET-03", + "NET-03.1", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "CA-08": [ - "VPM-07" + "11.6.1": [ + "CFG-03.1", + "MON-01.7", + "END-06", + "WEB-13" ], - "CA-08(01)": [ - "VPM-07.1" + "12.3.1": [ + "CFG-03.1", + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.2", + "RSK-07" ], - "CA-08(02)": [ - "VPM-10" - ] - }, - "general-nist-800-161-r1": { - "AC-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "12.3.4": [ + "CFG-03.1", + "SEA-02.3", + "SEA-07.1" ], - "AT-1": [ - "GOV-02", - "GOV-03", + "12.6.2": [ + "CFG-03.1", "SAT-01" ], - "AU-1": [ - "GOV-02", - "GOV-03", - "MON-01" + "12.6.3": [ + "CFG-03.1", + "HRS-03.1", + "HRS-05.7", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.6", + "SAT-04" ], - "CA-1": [ - "GOV-02", - "GOV-03", - "IAO-01" + "10.4.3": [ + "MON-01", + "MON-01.4", + "MON-01.8" ], - "CM-1": [ - "GOV-02", - "GOV-03", - "CFG-01" + "1.4.3": [ + "MON-01.1", + "NET-04", + "NET-08", + "NET-08.2" ], - "CP-1": [ - "GOV-02", - "GOV-03", - "BCD-01" + "11.5.1": [ + "MON-01.1", + "NET-03", + "NET-08", + "SAT-03.2" ], - "IA-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "10.4.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.2" ], - "IR-1": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "10.4.1.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.1", + "MON-02.2" ], - "MA-1": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "10.3.4": [ + "MON-01.7", + "END-06" ], - "MP-1": [ - "GOV-02", - "GOV-03", - "DCH-01" + "11.5.2": [ + "MON-01.7", + "END-06" ], - "PE-1": [ - "GOV-02", - "GOV-03", - "PES-01" + "10.4.2": [ + "MON-01.8" ], - "PL-1": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "10.4.2.1": [ + "MON-01.8" ], - "PS-1": [ - "GOV-02", - "GOV-03", - "HRS-01" + "10.3.3": [ + "MON-02", + "MON-02.2", + "MON-08.1" ], - "RA-1": [ - "GOV-02", - "GOV-03", - "RSK-01" + "12.10.5": [ + "MON-02.1", + "IRO-02", + "IRO-04", + "NET-12.1" ], - "SC-1": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "6.4.2": [ + "MON-03", + "IAO-04", + "TDA-15", + "VPM-05.1", + "WEB-01", + "WEB-03" ], - "SI-1": [ - "GOV-02", - "GOV-03", - "SEA-01" + "7.2.6": [ + "MON-03.7", + "IAC-20", + "IAC-20.1", + "IAC-20.2", + "IAC-21" ], - "SR-1": [ - "GOV-02", - "GOV-03", - "TPM-01" + "10.3.1": [ + "MON-08", + "MON-08.2" ], - "PT-1": [ - "GOV-03", - "PRI-01", - "SEA-01" + "10.3.2": [ + "MON-08", + "MON-08.2" ], - "SA-1": [ - "GOV-03", - "TDA-01", - "TDA-06" + "10.5.1": [ + "MON-10", + "DCH-18", + "PRI-05" ], - "PL-9": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "2.2.7": [ + "CRY-01", + "CRY-02", + "CRY-06", + "MNT-05.3" ], - "PM-2": [ - "GOV-04" + "3.3.2": [ + "CRY-01", + "CRY-05" ], - "PM-6": [ - "GOV-04", - "GOV-05" + "12.3.3": [ + "CRY-01", + "CRY-01.5" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "3.6.1.2": [ + "CRY-02", + "CRY-09", + "IAC-12" ], - "IR-6": [ - "GOV-06", - "IRO-10", - "IRO-14" + "4.2.1": [ + "CRY-03", + "NET-12", + "NET-15.1" ], - "PM-15": [ - "GOV-07", - "THR-01" + "4.2.1.2": [ + "CRY-03", + "CRY-07", + "NET-12.1" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "A2.1.1": [ + "CRY-03", + "WEB-10" ], - "PM-32": [ - "GOV-11" + "3.5.1.2": [ + "CRY-05" ], - "PM-5": [ - "AST-01", - "AST-02" + "3.5.1.3": [ + "CRY-05" ], - "CM-8": [ - "AST-02", - "AST-02.3" + "2.3.1": [ + "CRY-07", + "IAC-10.8", + "NET-12.1", + "NET-15.1" ], - "CM-8(1)": [ - "AST-02.1" + "2.3.2": [ + "CRY-07", + "CRY-09.3", + "NET-12.1", + "NET-15.1" ], - "CM-8(6)": [ - "AST-02.4" + "3.6.1": [ + "CRY-08.1", + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "SC-7(19)": [ - "AST-02.5" + "3.5.1.1": [ + "CRY-09" ], - "SC-18(2)": [ - "AST-02.7", - "END-10" + "3.6.1.3": [ + "CRY-09" ], - "CM-13": [ - "AST-02.8" + "3.6.1.4": [ + "CRY-09" ], - "CM-8(2)": [ - "AST-02.9" + "3.7.4": [ + "CRY-09" ], - "CM-8(7)": [ - "AST-02.9" + "4.2.1.1": [ + "CRY-09" ], - "CM-8(8)": [ - "AST-02.10" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "CM-8(9)": [ - "AST-02.11" + "3.5.1": [ + "DCH-01.2" ], - "CM-8(4)": [ - "AST-03.1" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "SR-4": [ - "AST-03.2" + "3.4.1": [ + "DCH-03.2", + "END-16", + "PRI-05.3" ], - "PL-2": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "9.4.5": [ + "DCH-06.2" ], - "SA-5": [ - "AST-04.1", - "TDA-04" + "9.4.5.1": [ + "DCH-06.2" ], - "SR-12": [ - "AST-09", - "TDA-11.2" + "3.3.1": [ + "DCH-06.5" ], - "SR-9": [ - "AST-15" + "3.3.1.2": [ + "DCH-06.5" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "3.3.1.3": [ + "DCH-06.5" ], - "CP-2": [ - "BCD-01", - "BCD-06" + "9.4.3": [ + "DCH-07", + "DCH-07.1" ], - "PM-8": [ - "BCD-01", - "CPL-01" + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "CP-2(1)": [ - "BCD-01.1" + "1.4.4": [ + "DCH-15", + "NET-05.1" ], - "CP-2(7)": [ - "BCD-01.2" + "3.2.1": [ + "DCH-18", + "TPM-04.4" ], - "CP-2(8)": [ - "BCD-02" + "11.4.1": [ + "DCH-18", + "IAO-04", + "TDA-15", + "VPM-07", + "VPM-07.1" ], - "CP-3": [ - "BCD-03" + "5.2.1": [ + "END-04" ], - "CP-3(1)": [ - "BCD-03.1" + "5.2.2": [ + "END-04" ], - "CP-4": [ - "BCD-04", - "BCD-05" + "5.3.1": [ + "END-04", + "END-04.1" ], - "CP-6": [ - "BCD-08" + "5.3.2": [ + "END-04", + "END-04.7" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "5.3.2.1": [ + "END-04", + "END-04.7" ], - "CP-6(1)": [ - "BCD-08.1" + "5.3.3": [ + "END-04", + "END-04.7" ], - "CP-7": [ - "BCD-09" + "5.3.4": [ + "END-04", + "END-04.3" ], - "CP-8": [ - "BCD-10" + "5.3.5": [ + "END-04", + "END-04.7" ], - "CP-11": [ - "BCD-10" + "5.2.3": [ + "END-04.6" ], - "CP-8(3)": [ - "BCD-10.2" + "5.2.3.1": [ + "END-04.6" ], - "CP-8(4)": [ - "BCD-10.3" + "5.4.1": [ + "END-08" ], - "SC-47": [ - "BCD-10.4" + "2.2.3": [ + "END-16", + "END-16.1", + "SEA-04.1" ], - "SC-5": [ - "CAP-02" + "11.4.5": [ + "END-16", + "NET-06", + "NET-08.1", + "SEA-04.1", + "TDA-07", + "VPM-07", + "VPM-07.1" ], - "SC-5(2)": [ - "CAP-02", - "CAP-03" + "12.2.1": [ + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "CP-2(2)": [ - "CAP-03" + "12.7.1": [ + "HRS-01", + "HRS-02", + "HRS-02.1", + "HRS-04", + "HRS-04.1" ], - "CM-3": [ - "CHG-01", - "CHG-02" + "6.2.2": [ + "HRS-03.2", + "IAO-04", + "SAT-03", + "SAT-03.8", + "TDA-06.3", + "TDA-13", + "TDA-15" ], - "CM-3(1)": [ - "CHG-02.1" + "8.2.5": [ + "HRS-09", + "HRS-09.2", + "IAC-07.1", + "IAC-07.2", + "IAC-20.6" ], - "CM-3(2)": [ - "CHG-02.2", - "CHG-06" + "6.5.4": [ + "HRS-11" ], - "CM-3(4)": [ - "CHG-02.3" + "7.2.1": [ + "IAC-01", + "IAC-02", + "IAC-03", + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CM-4": [ - "CHG-03" + "7.3.1": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "CM-5": [ - "CHG-04", - "END-03.2" + "7.3.2": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "CM-5(1)": [ - "CHG-04.1" + "7.3.3": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "CM-14": [ - "CHG-04.2" + "8.3.3": [ + "IAC-01", + "IAC-02", + "IAC-10", + "IAC-10.1", + "IAC-28" ], - "SI-7(15)": [ - "CHG-04.2" + "8.5.1": [ + "IAC-01", + "IAC-02.2", + "IAC-06", + "SEA-01" ], - "AC-5": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "8.6.1": [ + "IAC-01", + "IAC-05.1", + "IAC-15", + "IAC-15.7", + "IAC-19", + "IAC-20.3", + "IAC-21" ], - "CM-5(6)": [ - "CHG-04.5" + "8.3.9": [ + "IAC-02", + "IAC-10", + "IAC-10.1" ], - "CM-9": [ - "CHG-05", - "CFG-01" + "8.2.2": [ + "IAC-02.1", + "IAC-15.5", + "IAC-19" ], - "SA-9(5)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "8.4.2": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4" ], - "CA-7": [ - "CPL-02" + "8.4.3": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "8.4.1": [ + "IAC-06.1" ], - "CA-2": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "7.2.3": [ + "IAC-07", + "IAC-07.1", + "IAC-16", + "IAC-21.3" ], - "RA-3": [ - "CPL-03.2", - "RSK-04" + "8.2.4": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-15" ], - "CM-9(1)": [ - "CFG-01.1" + "8.3.5": [ + "IAC-07", + "IAC-10", + "IAC-10.1" ], - "CM-2": [ - "CFG-02", - "CFG-02.1" + "7.2.2": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CM-6": [ - "CFG-02", - "CFG-02.7" + "7.2.5": [ + "IAC-08", + "IAC-16", + "IAC-20", + "IAC-20.1", + "NET-14" ], - "PL-10": [ - "CFG-02" + "8.2.1": [ + "IAC-09", + "IAC-09.1" ], - "SA-8": [ - "CFG-02", - "SEA-01" + "8.3.1": [ + "IAC-10", + "IAC-10.1", + "IAC-10.2" ], - "CM-6(1)": [ - "CFG-02.2" + "8.3.7": [ + "IAC-10", + "IAC-10.1" ], - "CM-2(6)": [ - "CFG-02.4" + "8.3.11": [ + "IAC-10", + "IAC-10.2", + "IAC-10.5", + "IAC-10.7", + "IAC-18", + "PES-02", + "PES-02.1" ], - "CM-7(6)": [ - "CFG-02.5" + "8.6.3": [ + "IAC-10", + "IAC-10.1" ], - "CM-7(7)": [ - "CFG-02.5" + "8.3.6": [ + "IAC-10.1" ], - "CM-7(9)": [ - "CFG-02.5" + "8.6.2": [ + "IAC-10.6" ], - "CM-6(2)": [ - "CFG-02.8" + "8.2.8": [ + "IAC-14", + "IAC-24", + "IAC-25", + "NET-07" ], - "CM-7": [ - "CFG-03" + "8.2.6": [ + "IAC-15.3" ], - "CM-7(1)": [ - "CFG-03.1" + "7.2.4": [ + "IAC-16.1", + "IAC-17" ], - "CM-7(4)": [ - "CFG-03.3" + "7.2.5.1": [ + "IAC-17" ], - "CM-7(5)": [ - "CFG-03.3" + "3.4.2": [ + "IAC-21", + "NET-14" ], - "CM-10": [ - "CFG-04" + "8.3.4": [ + "IAC-22" ], - "CM-8(10)": [ - "CFG-04.1", - "TDA-04", - "TDA-04.1", - "TDA-04.2", - "TDA-05" + "12.10.7": [ + "IRO-04", + "IRO-12", + "IRO-12.3" ], - "CM-10(1)": [ - "CFG-04.1" + "12.10.2": [ + "IRO-04.2", + "IRO-06" ], - "CM-11": [ - "CFG-05", - "END-03" + "12.10.6": [ + "IRO-04.2", + "IRO-13" ], - "CM-3(8)": [ - "CFG-06" + "12.10.4": [ + "IRO-05" ], - "PM-31": [ - "MON-01" + "12.10.4.1": [ + "IRO-05" ], - "SI-4": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "12.10.3": [ + "IRO-07" ], - "AU-2": [ - "MON-01.8", - "MON-02" + "6.2.1": [ + "IAO-04", + "SEA-01", + "TDA-01", + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-15" ], - "SI-4(19)": [ - "MON-01.14" + "6.2.3": [ + "IAO-04", + "TDA-06.5", + "TDA-09", + "TDA-15" ], - "AU-6": [ - "MON-02", - "MON-02.6" + "6.2.3.1": [ + "IAO-04", + "TDA-09", + "TDA-15" ], - "AU-6(9)": [ - "MON-02.1" + "6.2.4": [ + "IAO-04", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5", + "TDA-15" ], - "SI-4(17)": [ - "MON-02.3" + "6.4.1": [ + "IAO-04", + "TDA-15", + "VPM-05.1", + "VPM-06", + "VPM-06.6", + "WEB-01", + "WEB-03" ], - "AU-3": [ - "MON-03" + "11.4.4": [ + "IAO-04", + "TDA-15", + "VPM-07" ], - "AU-12": [ - "MON-06" + "8.2.7": [ + "MNT-05", + "MNT-05.1", + "MNT-05.4", + "NET-14", + "NET-14.6" ], - "CA-7(3)": [ - "MON-06.2" + "11.2.1": [ + "NET-01", + "NET-02.2", + "NET-03.1", + "NET-12.1", + "NET-15", + "NET-15.5" ], - "AU-10": [ - "MON-09" + "1.3.3": [ + "NET-02.2", + "NET-03", + "NET-03.7", + "NET-04.1", + "NET-04.7", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "AU-10(1)": [ - "MON-09.1" + "1.4.5": [ + "NET-03.3", + "VPM-06.8" ], - "AU-10(2)": [ - "MON-09.1" + "1.3.2": [ + "NET-03.5", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "AU-13": [ - "MON-11" + "1.3.1": [ + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "AU-14": [ - "MON-12" + "4.2.2": [ + "NET-12.2" ], - "AU-16": [ - "MON-14" + "9.2.1": [ + "PES-02", + "PES-02.1", + "PES-03", + "PES-03.1", + "PES-03.3" ], - "AU-16(2)": [ - "MON-14.1" + "9.3.1": [ + "PES-02", + "PES-02.1", + "PES-03.1" ], - "SC-8": [ - "CRY-03", - "CRY-04" + "9.3.1.1": [ + "PES-02.1", + "PES-04", + "PES-04.1" ], - "SC-28": [ - "CRY-05", - "END-02" + "9.2.4": [ + "PES-03.2", + "PES-12" ], - "AC-18": [ - "CRY-07", - "NET-15" + "9.2.1.1": [ + "PES-03.3", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "AC-3(9)": [ - "DCH-03.3" + "9.3.2": [ + "PES-06", + "PES-06.1", + "PES-06.2", + "PES-06.3", + "OPS-01", + "OPS-01.1" ], - "MP-4": [ - "DCH-06" + "9.3.3": [ + "PES-06", + "PES-06.6" ], - "MP-5": [ - "DCH-07" + "9.3.4": [ + "PES-06", + "PES-06.4", + "PES-06.5" ], - "MP-6": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "9.2.2": [ + "PES-12", + "PES-12.1", + "PES-12.2" ], - "AC-20": [ - "DCH-13" + "9.2.3": [ + "PES-12", + "PES-12.1", + "PES-12.2" ], - "AC-20(1)": [ - "DCH-13.1" + "6.5.5": [ + "PRI-05.1", + "PRI-05.4", + "TDA-10" ], - "PM-17": [ - "DCH-13.3" + "12.3.2": [ + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-06.2", + "RSK-07" ], - "AC-20(3)": [ - "DCH-13.4" + "9.5.1.3": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "AC-22": [ - "DCH-15" + "12.6.3.1": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "12.6.3.2": [ + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "2.2.6": [ + "TDA-05.1" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "12.8.3": [ + "TPM-04.1" ], - "CM-12": [ - "DCH-24" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "CM-12(1)": [ - "DCH-24.1" + "12.8.4": [ + "TPM-08" ], - "SI-3": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", + "6.3.3": [ "VPM-01", - "VPM-05" + "VPM-04", + "VPM-05", + "VPM-05.1" ], - "SI-2": [ - "END-04.1", - "VPM-01", - "VPM-05" + "11.3.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.1", + "VPM-06.2", + "VPM-06.7" ], - "SI-7": [ - "END-06", - "NET-12", - "TDA-18" + "11.3.1.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06" ], - "CM-7(8)": [ - "END-06.7" + "11.3.1.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.7" ], - "SI-7(14)": [ - "END-06.7" + "11.3.1.3": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.7" ], - "SC-18": [ - "END-10" + "11.3.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.6" ], - "SC-27": [ - "END-10" + "11.3.2.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.2", + "VPM-06.6" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "6.4.3": [ + "VPM-05.1", + "WEB-01.1" ], - "PS-3": [ - "HRS-04" + "11.4.2": [ + "VPM-07", + "VPM-07.1" ], - "PL-4": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "11.4.3": [ + "VPM-07", + "VPM-07.1" + ] + }, + "general-pci-dss-4-0-1-saq-d-service-provider": { + "1.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "PS-6": [ - "HRS-06", - "HRS-06.1" + "2.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "PS-7": [ - "HRS-10" + "3.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "IA-4": [ - "IAC-01.2", - "IAC-09" + "3.7.1": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "IA-2": [ - "IAC-02" + "3.7.2": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "IA-8": [ - "IAC-03" + "3.7.3": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "IA-3": [ - "IAC-04" + "3.7.5": [ + "GOV-02", + "CRY-04", + "CRY-09", + "CRY-09.3", + "OPS-01.1" ], - "IA-9": [ - "IAC-05" + "3.7.6": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "AC-6(6)": [ - "IAC-05.2" + "3.7.7": [ + "GOV-02", + "CRY-09", + "OPS-01.1" ], - "AC-2": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "3.7.8": [ + "GOV-02", + "HRS-03", + "OPS-01.1" ], - "IA-4(6)": [ - "IAC-09.4" + "4.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "IA-5": [ - "IAC-10", - "IAC-10.8" + "5.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "IA-5(5)": [ - "IAC-10.8" + "6.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "IA-5(9)": [ - "IAC-13.2" + "7.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AC-3": [ - "IAC-20", - "NET-12", - "TDA-18" + "8.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "AC-6": [ - "IAC-20", - "IAC-21" + "8.3.8": [ + "GOV-02", + "IAC-01", + "OPS-01", + "OPS-01.1", + "SAT-01", + "SAT-02", + "SAT-03" ], - "AC-3(8)": [ - "IAC-20.6" + "9.1.1": [ + "GOV-02", + "GOV-03", + "PES-01", + "OPS-01", + "OPS-01.1" ], - "AC-24": [ - "IAC-28.1" + "10.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "IR-4": [ - "IRO-02" + "11.1.1": [ + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1" ], - "IR-4(6)": [ - "IRO-02.2" + "12.1.1": [ + "GOV-02", + "GOV-03" ], - "IR-4(7)": [ - "IRO-02.2" + "12.1.2": [ + "GOV-02", + "GOV-03" ], - "IR-1(1)": [ - "IRO-02.5", - "IRO-10.4" + "12.1.3": [ + "GOV-02", + "GOV-04", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1" ], - "IR-8": [ - "IRO-04" + "1.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1", + "SAT-03", + "SAT-03.5" ], - "IR-2": [ - "IRO-05" + "2.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "IR-3": [ - "IRO-06" + "3.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "IR-4(11)": [ - "IRO-07" + "5.1.2": [ + "GOV-04", + "END-04.2", + "HRS-03", + "HRS-03.1" ], - "AU-10(3)": [ - "IRO-08" + "6.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "IR-5": [ - "IRO-09" + "7.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "IR-4(10)": [ - "IRO-10.4", - "TPM-11" + "8.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "IR-6(3)": [ - "IRO-10.4" + "9.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1", + "PES-03" ], - "IR-7": [ - "IRO-11" + "10.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "IR-7(2)": [ - "IRO-11.2" + "11.1.2": [ + "GOV-04", + "HRS-03", + "HRS-03.1" ], - "IR-9": [ - "IRO-12", - "IRO-12.1" + "12.1.4": [ + "GOV-04", + "IRO-10" ], - "PM-10": [ - "IAO-01" + "6.3.1": [ + "GOV-07", + "IAO-04", + "TDA-15", + "THR-03", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-05.1" ], - "CA-2(2)": [ - "IAO-02.2" + "6.3.2": [ + "AST-01", + "AST-02", + "AST-04.3", + "TDA-04.2", + "VPM-01.1", + "VPM-05.1" ], - "CA-2(3)": [ - "IAO-02.3" + "9.5.1": [ + "AST-01", + "AST-02", + "AST-06", + "AST-07", + "AST-15", + "AST-15.1", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "CA-5": [ - "IAO-05" + "9.5.1.1": [ + "AST-01", + "AST-02", + "AST-07" ], - "PM-4": [ - "IAO-05", - "VPM-02" + "11.2.2": [ + "AST-01", + "AST-02", + "NET-02.2", + "NET-12.1", + "NET-15" ], - "CA-6": [ - "IAO-07" + "2.2.2": [ + "AST-03", + "IAC-10.8" ], - "MA-2": [ - "MNT-02" + "2.2.4": [ + "AST-03", + "CFG-03", + "RSK-06.2" ], - "MA-2(2)": [ - "MNT-02.1" + "2.2.5": [ + "AST-03", + "TDA-02.6" ], - "MA-6": [ - "MNT-03" + "6.5.2": [ + "AST-03", + "CHG-01", + "CHG-02.2", + "CHG-03", + "CHG-06", + "CHG-06.1", + "IAC-10.8" ], - "MA-3": [ - "MNT-04" + "1.2.3": [ + "AST-04", + "AST-04.2", + "NET-02.2", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "MA-3(1)": [ - "MNT-04.1" + "1.2.4": [ + "AST-04", + "NET-06", + "NET-08.1", + "TDA-02.1" ], - "MA-3(2)": [ - "MNT-04.2" + "12.5.2.1": [ + "AST-04.2", + "AST-04.3", + "CFG-03.1", + "TPM-05.5" ], - "MA-3(3)": [ - "MNT-04.3" + "12.5.1": [ + "AST-04.3", + "CPL-01.2", + "PRI-05.5" ], - "MA-4": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "9.4.4": [ + "AST-05", + "AST-05.1" ], - "MA-4(3)": [ - "MNT-05.6" + "9.5.1.2": [ + "AST-07", + "AST-08", + "AST-15.1" ], - "MA-5": [ - "MNT-06" + "9.5.1.2.1": [ + "AST-08" ], - "MA-5(4)": [ - "MNT-06.1" + "9.4.7": [ + "AST-09", + "DCH-09", + "DCH-09.1", + "DCH-18", + "PRI-05" ], - "SR-11(2)": [ - "MNT-07" + "9.4.1.2": [ + "BCD-02.4", + "BCD-11", + "DCH-06", + "DCH-06.1", + "DCH-06.2" ], - "MA-7": [ - "MNT-08" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "MA-8": [ - "MNT-11", - "SEA-07" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "AC-19": [ - "MDM-02" + "1.2.2": [ + "CHG-01", + "CHG-02", + "CHG-02.1" ], - "PE-3(5)": [ - "MDM-04" + "6.5.1": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "OPS-01.1" ], - "SC-7": [ - "NET-03" + "6.5.3": [ + "CHG-01", + "TDA-07", + "TDA-08" ], - "AC-4": [ - "NET-04" + "12.4.2": [ + "CHG-01", + "CHG-02", + "CLD-12", + "CPL-01", + "CPL-01.1", + "CPL-03", + "CPL-03.2", + "CFG-02.1", + "CFG-03.1", + "MON-01.8", + "TPM-05", + "TPM-08" ], - "AC-4(6)": [ - "NET-04.5" + "6.5.6": [ + "CHG-02", + "CHG-03", + "CFG-02.4", + "TDA-08", + "TDA-08.1", + "TDA-09" ], - "AC-4(17)": [ - "NET-04.12" + "1.2.8": [ + "CHG-04", + "CFG-02.6", + "NET-06", + "NET-08.1" ], - "AC-4(19)": [ - "NET-04.13" + "10.7.3": [ + "CHG-06", + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "IRO-01", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "TPM-11" ], - "CA-3": [ - "NET-05" + "1.2.1": [ + "CLD-01", + "CFG-02", + "CFG-02.5", + "NET-06", + "NET-08.1", + "SEA-03" ], - "AC-4(21)": [ - "NET-06" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "SC-7(13)": [ - "NET-06.1" + "A1.1.1": [ + "CLD-06" ], - "SC-37": [ - "NET-11" + "A1.1.2": [ + "CLD-06" ], - "SC-37(1)": [ - "NET-11" + "A1.1.3": [ + "CLD-06" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "A1.1.4": [ + "CLD-06", + "NET-06", + "NET-08.1" ], - "AC-17": [ - "NET-14" + "12.4.1": [ + "CLD-06.1", + "TPM-05.4" ], - "AC-17(6)": [ - "NET-14" + "A1.2.1": [ + "CLD-06.2" ], - "PE-2": [ - "PES-02" + "A1.2.2": [ + "CLD-06.3" ], - "PE-2(1)": [ - "PES-02.1" + "A1.2.3": [ + "CLD-06.4", + "IRO-10", + "IAO-04", + "TDA-15" ], - "PE-3": [ - "PES-03" + "12.5.2": [ + "CPL-01.2", + "CFG-03.1", + "NET-06", + "NET-08.1", + "TPM-04.4" ], - "PE-3(2)": [ - "PES-03" + "10.7.1": [ + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "END-16", + "IRO-01", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "SEA-04.1", + "TPM-11" ], - "SC-7(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "10.7.2": [ + "CPL-02", + "CPL-03", + "CPL-03.2", + "CFG-02.8", + "MON-01", + "MON-01.4", + "END-06.2", + "IRO-01", + "RSK-06", + "RSK-06.1", + "SEA-01.1", + "TPM-11" ], - "PE-3(1)": [ - "PES-03.4" + "1.2.7": [ + "CPL-03.2", + "CFG-03.1", + "NET-04.6", + "NET-06", + "NET-08.1" ], - "PE-6": [ - "PES-05" + "1.2.6": [ + "CFG-02", + "CFG-03", + "NET-06", + "NET-08.1", + "RSK-06.2", + "TDA-02.6" ], - "PE-16": [ - "PES-10" + "2.2.1": [ + "CFG-02" ], - "PE-17": [ - "PES-11" + "8.3.2": [ + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-05" ], - "PE-18": [ - "PES-12" + "10.2.1": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "PE-20": [ - "PES-14" + "10.2.1.1": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "PM-18": [ - "PRI-01" + "10.2.1.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3", + "IAC-21.4" ], - "PM-19": [ - "PRI-01.1" + "10.2.1.3": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "PM-20": [ - "PRI-01.3" + "10.2.1.4": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "10.2.1.5": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "PM-27": [ - "PRI-14" + "10.2.1.6": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "PM-21": [ - "PRI-14.1" + "10.2.1.7": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2", + "MON-03.3" ], - "PM-3": [ - "PRM-02" + "10.2.2": [ + "CFG-02", + "CFG-02.5", + "MON-03", + "MON-03.2" ], - "SA-2": [ - "PRM-03" + "10.6.1": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "RA-9": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "10.6.2": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "PM-11": [ - "PRM-06" + "10.6.3": [ + "CFG-02", + "CFG-02.5", + "MON-02.7", + "MON-07", + "MON-07.1", + "SEA-20" ], - "SA-3": [ - "PRM-07", - "SEA-07.1" + "1.5.1": [ + "CFG-02.5", + "CFG-03.4", + "DCH-13.1", + "END-01", + "END-02", + "END-05" ], - "PM-9": [ - "RSK-01" + "1.2.5": [ + "CFG-03", + "NET-06", + "NET-08.1", + "TDA-02.5", + "TPM-04.2" ], - "PM-28": [ - "RSK-01.1" + "1.4.1": [ + "CFG-03", + "NET-02", + "NET-03", + "NET-03.8", + "NET-06", + "NET-08.1", + "NET-09", + "SEA-03" ], - "RA-2": [ - "RSK-02" + "1.4.2": [ + "CFG-03", + "NET-03", + "NET-03.1", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "RA-7": [ - "RSK-06.1" + "11.6.1": [ + "CFG-03.1", + "MON-01.7", + "END-06", + "WEB-13" ], - "PM-30": [ - "RSK-09" + "12.3.1": [ + "CFG-03.1", + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.2", + "RSK-07" ], - "SA-9(3)": [ - "RSK-09", - "TPM-02", - "TPM-03", - "TPM-05", - "TPM-05.4", - "TPM-05.7" + "12.3.4": [ + "CFG-03.1", + "SEA-02.3", + "SEA-07.1" ], - "SR-2": [ - "RSK-09", - "TPM-03" + "12.6.2": [ + "CFG-03.1", + "SAT-01" ], - "SR-7": [ - "RSK-09", - "OPS-01" + "12.6.3": [ + "CFG-03.1", + "HRS-03.1", + "HRS-05.7", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.6", + "SAT-04" ], - "RA-3(1)": [ - "RSK-09.1" + "10.4.3": [ + "MON-01", + "MON-01.4", + "MON-01.8" ], - "PL-8": [ - "SEA-02" + "1.4.3": [ + "MON-01.1", + "NET-04", + "NET-08", + "NET-08.2" ], - "PM-7": [ - "SEA-02" + "11.5.1": [ + "MON-01.1", + "NET-03", + "NET-08", + "SAT-03.2" ], - "SC-4": [ - "SEA-05" + "11.5.1.1": [ + "MON-01.1", + "MON-11.1", + "MON-15", + "NET-08", + "SAT-03.2" ], - "SC-29": [ - "SEA-13" + "10.4.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.2" ], - "SC-30": [ - "SEA-14" + "10.4.1.1": [ + "MON-01.2", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.1", + "MON-02.2" ], - "SC-30(4)": [ - "SEA-14" + "10.3.4": [ + "MON-01.7", + "END-06" ], - "SC-30(5)": [ - "SEA-14" + "11.5.2": [ + "MON-01.7", + "END-06" ], - "SC-30(2)": [ - "SEA-14.1" + "10.4.2": [ + "MON-01.8" ], - "SC-30(3)": [ - "SEA-14.2" + "10.4.2.1": [ + "MON-01.8" ], - "SC-36": [ - "SEA-15" + "10.3.3": [ + "MON-02", + "MON-02.2", + "MON-08.1" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "12.10.5": [ + "MON-02.1", + "IRO-02", + "IRO-04", + "NET-12.1" ], - "PL-7": [ - "OPS-02" + "6.4.2": [ + "MON-03", + "IAO-04", + "TDA-15", + "VPM-05.1", + "WEB-01", + "WEB-03" ], - "AT-2": [ - "SAT-02" + "7.2.6": [ + "MON-03.7", + "IAC-20", + "IAC-20.1", + "IAC-20.2", + "IAC-21" ], - "AT-2(1)": [ - "SAT-02.1" + "10.3.1": [ + "MON-08", + "MON-08.2" ], - "AT-2(3)": [ - "SAT-02.2" + "10.3.2": [ + "MON-08", + "MON-08.2" ], - "AT-3": [ - "SAT-03" + "10.5.1": [ + "MON-10", + "DCH-18", + "PRI-05" ], - "AT-3(2)": [ - "SAT-03" + "2.2.7": [ + "CRY-01", + "CRY-02", + "CRY-06", + "MNT-05.3" ], - "AT-3(6)": [ - "SAT-03", - "THR-01", - "THR-03" + "3.3.2": [ + "CRY-01", + "CRY-05" ], - "AT-2(4)": [ - "SAT-03.2" + "12.3.3": [ + "CRY-01", + "CRY-01.5" ], - "AT-2(5)": [ - "SAT-03.2" + "3.6.1.1": [ + "CRY-02", + "CRY-09", + "IAC-12" ], - "AT-2(6)": [ - "SAT-03.6" + "3.6.1.2": [ + "CRY-02", + "CRY-09", + "IAC-12" ], - "AT-4": [ - "SAT-04" + "4.2.1": [ + "CRY-03", + "NET-12", + "NET-15.1" ], - "SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "4.2.1.2": [ + "CRY-03", + "CRY-07", + "NET-12.1" ], - "SA-4(7)": [ - "TDA-02.2" + "A2.1.1": [ + "CRY-03", + "WEB-10" ], - "SR-3(1)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "A2.1.2": [ + "CRY-03", + "WEB-10" ], - "SA-4(5)": [ - "TDA-02.4" + "3.5.1.2": [ + "CRY-05" ], - "PL-8(2)": [ - "TDA-03.1" + "3.5.1.3": [ + "CRY-05" ], - "SA-17": [ - "TDA-05" + "2.3.1": [ + "CRY-07", + "IAC-10.8", + "NET-12.1", + "NET-15.1" ], - "SA-15": [ - "TDA-06" + "2.3.2": [ + "CRY-07", + "CRY-09.3", + "NET-12.1", + "NET-15.1" ], - "SA-15(3)": [ - "TDA-06.1" + "3.6.1": [ + "CRY-08.1", + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "SA-15(4)": [ - "TDA-06.2" + "3.5.1.1": [ + "CRY-09" ], - "SA-15(8)": [ - "TDA-06.2" + "3.6.1.3": [ + "CRY-09" ], - "CM-4(1)": [ - "TDA-08" + "3.6.1.4": [ + "CRY-09" ], - "SA-11": [ - "TDA-09" + "3.7.4": [ + "CRY-09" ], - "SA-4(8)": [ - "TDA-09.1" + "4.2.1.1": [ + "CRY-09" ], - "SR-11": [ - "TDA-11" + "3.7.9": [ + "CRY-09.6" ], - "SR-11(3)": [ - "TDA-11" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "SR-11(1)": [ - "TDA-11.1" + "3.5.1": [ + "DCH-01.2" ], - "SA-20": [ - "TDA-12" + "9.4.2": [ + "DCH-02", + "RSK-02" ], - "SA-21": [ - "TDA-13" + "3.4.1": [ + "DCH-03.2", + "END-16", + "PRI-05.3" ], - "SA-21(1)": [ - "TDA-13" + "9.4.5": [ + "DCH-06.2" ], - "SA-10": [ - "TDA-14" + "9.4.5.1": [ + "DCH-06.2" ], - "SA-16": [ - "TDA-16" + "3.3.1": [ + "DCH-06.5" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "3.3.1.2": [ + "DCH-06.5" ], - "SR-13": [ - "TPM-01.1" + "3.3.1.3": [ + "DCH-06.5" ], - "SR-5": [ - "TPM-03.1" + "3.3.3": [ + "DCH-06.5" ], - "SR-3": [ - "TPM-03.3" + "9.4.3": [ + "DCH-07", + "DCH-07.1" ], - "SA-9": [ - "TPM-04" + "9.4.6": [ + "DCH-08", + "DCH-18", + "PRI-05" ], - "SA-9(1)": [ - "TPM-04.1" + "1.4.4": [ + "DCH-15", + "NET-05.1" ], - "SA-9(4)": [ - "TPM-04.3" + "3.2.1": [ + "DCH-18", + "TPM-04.4" ], - "SR-3(3)": [ - "TPM-05", - "TPM-05.2" + "11.4.1": [ + "DCH-18", + "IAO-04", + "TDA-15", + "VPM-07", + "VPM-07.1" ], - "SR-8": [ - "TPM-05.1" + "5.2.1": [ + "END-04" ], - "SR-6": [ - "TPM-08" + "5.2.2": [ + "END-04" ], - "PM-16": [ - "THR-01" + "5.3.1": [ + "END-04", + "END-04.1" ], - "PM-12": [ - "THR-04" + "5.3.2": [ + "END-04", + "END-04.7" ], - "AT-2(2)": [ - "THR-05" + "5.3.2.1": [ + "END-04", + "END-04.7" ], - "RA-10": [ - "THR-07" + "5.3.3": [ + "END-04", + "END-04.7" ], - "SI-20": [ - "THR-08" + "5.3.4": [ + "END-04", + "END-04.3" ], - "SI-2(5)": [ - "VPM-05.4" + "5.3.5": [ + "END-04", + "END-04.7" ], - "RA-5": [ - "VPM-06", - "VPM-06.1" + "5.2.3": [ + "END-04.6" ], - "RA-5(3)": [ - "VPM-06.2" + "5.2.3.1": [ + "END-04.6" ], - "RA-5(6)": [ - "VPM-06.4" - ] - }, - "general-nist-800-161-r1-cscrm": { - "AC-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "5.4.1": [ + "END-08" ], - "AT-1": [ - "GOV-02", - "GOV-03", - "SAT-01" + "2.2.3": [ + "END-16", + "END-16.1", + "SEA-04.1" ], - "AU-1": [ - "GOV-02", - "GOV-03", - "MON-01" + "11.4.5": [ + "END-16", + "NET-06", + "NET-08.1", + "SEA-04.1", + "TDA-07", + "VPM-07", + "VPM-07.1" ], - "CA-1": [ - "GOV-02", - "GOV-03", - "IAO-01" + "11.4.6": [ + "END-16", + "NET-06", + "NET-08.1", + "SEA-04.1", + "TDA-07", + "VPM-07", + "VPM-07.1" ], - "CM-1": [ - "GOV-02", - "GOV-03", - "CFG-01" + "12.2.1": [ + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "CP-1": [ - "GOV-02", - "GOV-03", - "BCD-01" + "12.7.1": [ + "HRS-01", + "HRS-02", + "HRS-02.1", + "HRS-04", + "HRS-04.1" ], - "IA-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "6.2.2": [ + "HRS-03.2", + "IAO-04", + "SAT-03", + "SAT-03.8", + "TDA-06.3", + "TDA-13", + "TDA-15" ], - "IR-1": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "8.2.5": [ + "HRS-09", + "HRS-09.2", + "IAC-07.1", + "IAC-07.2", + "IAC-20.6" ], - "MA-1": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "6.5.4": [ + "HRS-11" ], - "MP-1": [ - "GOV-02", - "GOV-03", - "DCH-01" + "7.2.1": [ + "IAC-01", + "IAC-02", + "IAC-03", + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "PE-1": [ - "GOV-02", - "GOV-03", - "PES-01" + "7.3.1": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "PL-1": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "7.3.2": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "PS-1": [ - "GOV-02", - "GOV-03", - "HRS-01" + "7.3.3": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-21" ], - "RA-1": [ - "GOV-02", - "GOV-03", - "RSK-01" + "8.3.3": [ + "IAC-01", + "IAC-02", + "IAC-10", + "IAC-10.1", + "IAC-28" ], - "SC-1": [ - "GOV-02", - "GOV-03", - "NET-01", + "8.5.1": [ + "IAC-01", + "IAC-02.2", + "IAC-06", "SEA-01" ], - "SI-1": [ - "GOV-02", - "GOV-03", - "SEA-01" + "8.6.1": [ + "IAC-01", + "IAC-05.1", + "IAC-15", + "IAC-15.7", + "IAC-19", + "IAC-20.3", + "IAC-21" ], - "SR-1": [ - "GOV-02", - "GOV-03", - "TPM-01" + "8.3.9": [ + "IAC-02", + "IAC-10", + "IAC-10.1" ], - "SA-1": [ - "GOV-03", - "TDA-01", - "TDA-06" + "8.2.2": [ + "IAC-02.1", + "IAC-15.5", + "IAC-19" ], - "CM-8": [ - "AST-02", - "AST-02.3" + "8.2.3": [ + "IAC-03.2", + "IAC-05", + "IAC-05.1", + "IAC-06", + "NET-14", + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.3" ], - "PL-2": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "8.4.2": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4" ], - "SA-5": [ - "AST-04.1", - "TDA-04" + "8.4.3": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2" ], - "SR-12": [ - "AST-09", - "TDA-11.2" + "8.4.1": [ + "IAC-06.1" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "7.2.3": [ + "IAC-07", + "IAC-07.1", + "IAC-16", + "IAC-21.3" ], - "CP-2": [ - "BCD-01", - "BCD-06" + "8.2.4": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-15" ], - "CP-3": [ - "BCD-03" + "8.3.5": [ + "IAC-07", + "IAC-10", + "IAC-10.1" ], - "CP-4": [ - "BCD-04", - "BCD-05" + "7.2.2": [ + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "CM-4": [ - "CHG-03" + "7.2.5": [ + "IAC-08", + "IAC-16", + "IAC-20", + "IAC-20.1", + "NET-14" ], - "CM-5": [ - "CHG-04", - "END-03.2" + "8.2.1": [ + "IAC-09", + "IAC-09.1" ], - "CA-2": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "8.3.1": [ + "IAC-10", + "IAC-10.1", + "IAC-10.2" ], - "RA-3": [ - "CPL-03.2", - "RSK-04" + "8.3.7": [ + "IAC-10", + "IAC-10.1" ], - "CM-2": [ - "CFG-02", - "CFG-02.1" + "8.3.10.1": [ + "IAC-10", + "IAC-10.1" ], - "CM-6": [ - "CFG-02", - "CFG-02.7" + "8.3.11": [ + "IAC-10", + "IAC-10.2", + "IAC-10.5", + "IAC-10.7", + "IAC-18", + "PES-02", + "PES-02.1" ], - "PL-10": [ - "CFG-02" + "8.6.3": [ + "IAC-10", + "IAC-10.1" ], - "SA-8": [ - "CFG-02", - "SEA-01" + "8.3.6": [ + "IAC-10.1" ], - "CM-7": [ - "CFG-03" + "8.6.2": [ + "IAC-10.6" ], - "CM-10": [ - "CFG-04" + "8.2.8": [ + "IAC-14", + "IAC-24", + "IAC-25", + "NET-07" ], - "CM-11": [ - "CFG-05", - "END-03" + "8.3.10": [ + "IAC-15", + "WEB-06" ], - "SI-4": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "8.2.6": [ + "IAC-15.3" ], - "AU-2": [ - "MON-01.8", - "MON-02" + "7.2.4": [ + "IAC-16.1", + "IAC-17" ], - "AU-6": [ - "MON-02", - "MON-02.6" + "7.2.5.1": [ + "IAC-17" ], - "AU-3": [ - "MON-03" + "3.4.2": [ + "IAC-21", + "NET-14" ], - "AU-12": [ - "MON-06" + "8.3.4": [ + "IAC-22" ], - "AC-18": [ - "CRY-07", - "NET-15" + "12.10.7": [ + "IRO-04", + "IRO-12", + "IRO-12.3" ], - "MP-6": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "12.10.2": [ + "IRO-04.2", + "IRO-06" ], - "AC-20": [ - "DCH-13" + "12.10.6": [ + "IRO-04.2", + "IRO-13" ], - "AC-22": [ - "DCH-15" + "12.10.4": [ + "IRO-05" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "12.10.4.1": [ + "IRO-05" ], - "SI-3": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "12.10.3": [ + "IRO-07" ], - "SI-2": [ - "END-04.1", - "VPM-01", - "VPM-05" + "6.2.1": [ + "IAO-04", + "SEA-01", + "TDA-01", + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-15" ], - "SI-7": [ - "END-06", - "NET-12", - "TDA-18" + "6.2.3": [ + "IAO-04", + "TDA-06.5", + "TDA-09", + "TDA-15" ], - "PS-3": [ - "HRS-04" + "6.2.3.1": [ + "IAO-04", + "TDA-09", + "TDA-15" ], - "PL-4": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "6.2.4": [ + "IAO-04", + "TDA-06", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5", + "TDA-15" ], - "PS-6": [ - "HRS-06", - "HRS-06.1" + "6.4.1": [ + "IAO-04", + "TDA-15", + "VPM-05.1", + "VPM-06", + "VPM-06.6", + "WEB-01", + "WEB-03" ], - "PS-7": [ - "HRS-10" + "11.4.4": [ + "IAO-04", + "TDA-15", + "VPM-07" ], - "IA-4": [ - "IAC-01.2", - "IAC-09" + "12.4.2.1": [ + "IAO-04", + "TDA-15", + "TPM-05", + "TPM-08" ], - "IA-2": [ - "IAC-02" + "8.2.7": [ + "MNT-05", + "MNT-05.1", + "MNT-05.4", + "NET-14", + "NET-14.6" ], - "IA-8": [ - "IAC-03" + "11.2.1": [ + "NET-01", + "NET-02.2", + "NET-03.1", + "NET-12.1", + "NET-15", + "NET-15.5" ], - "AC-2": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "1.3.3": [ + "NET-02.2", + "NET-03", + "NET-03.7", + "NET-04.1", + "NET-04.7", + "NET-06", + "NET-08.1", + "NET-12.1" ], - "IA-5": [ - "IAC-10", - "IAC-10.8" + "1.4.5": [ + "NET-03.3", + "VPM-06.8" ], - "AC-3": [ - "IAC-20", - "NET-12", - "TDA-18" + "1.3.2": [ + "NET-03.5", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "IR-8": [ - "IRO-04" + "1.3.1": [ + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "IR-2": [ - "IRO-05" + "4.2.2": [ + "NET-12.2" ], - "IR-5": [ - "IRO-09" + "9.2.1": [ + "PES-02", + "PES-02.1", + "PES-03", + "PES-03.1", + "PES-03.3" ], - "CA-5": [ - "IAO-05" + "9.3.1": [ + "PES-02", + "PES-02.1", + "PES-03.1" ], - "CA-6": [ - "IAO-07" + "9.3.1.1": [ + "PES-02.1", + "PES-04", + "PES-04.1" ], - "MA-4": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "9.2.4": [ + "PES-03.2", + "PES-12" ], - "MA-5": [ - "MNT-06" + "9.2.1.1": [ + "PES-03.3", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "SR-11(2)": [ - "MNT-07" + "9.3.2": [ + "PES-06", + "PES-06.1", + "PES-06.2", + "PES-06.3", + "OPS-01", + "OPS-01.1" ], - "AC-19": [ - "MDM-02" + "9.3.3": [ + "PES-06", + "PES-06.6" ], - "SC-7": [ - "NET-03" + "9.3.4": [ + "PES-06", + "PES-06.4", + "PES-06.5" ], - "CA-3": [ - "NET-05" + "9.2.2": [ + "PES-12", + "PES-12.1", + "PES-12.2" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "9.2.3": [ + "PES-12", + "PES-12.1", + "PES-12.2" ], - "AC-17": [ - "NET-14" + "12.9.1": [ + "PRI-01.6", + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "PE-2": [ - "PES-02" + "6.5.5": [ + "PRI-05.1", + "PRI-05.4", + "TDA-10" ], - "PE-3": [ - "PES-03" + "9.5.1.3": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "PE-6": [ - "PES-05" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "PE-16": [ - "PES-10" + "12.6.3.1": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "SA-2": [ - "PRM-03" + "12.6.3.2": [ + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "SA-3": [ - "PRM-07", - "SEA-07.1" + "2.2.6": [ + "TDA-05.1" ], - "RA-2": [ - "RSK-02" + "12.9.2": [ + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "RA-7": [ - "RSK-06.1" + "A2.1.3": [ + "TPM-01" ], - "PM-30": [ - "RSK-09" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "SR-2": [ - "RSK-09", - "TPM-03" + "12.8.3": [ + "TPM-04.1" ], - "RA-3(1)": [ - "RSK-09.1" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "AT-3": [ - "SAT-03" + "12.5.3": [ + "TPM-05.5" ], - "AT-4": [ - "SAT-04" + "12.8.4": [ + "TPM-08" ], - "SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "6.3.3": [ + "VPM-01", + "VPM-04", + "VPM-05", + "VPM-05.1" ], - "SR-11": [ - "TDA-11" + "11.3.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.1", + "VPM-06.2", + "VPM-06.7" ], - "SR-11(1)": [ - "TDA-11.1" + "11.3.1.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "11.3.1.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.7" ], - "SR-5": [ - "TPM-03.1" + "11.3.1.3": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.7" ], - "SR-3": [ - "TPM-03.3" + "11.3.2": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.6" ], - "SR-8": [ - "TPM-05.1" + "11.3.2.1": [ + "VPM-01.1", + "VPM-02", + "VPM-06", + "VPM-06.2", + "VPM-06.6" ], - "AT-2(2)": [ - "THR-05" + "6.4.3": [ + "VPM-05.1", + "WEB-01.1" ], - "RA-5": [ - "VPM-06", - "VPM-06.1" + "11.4.2": [ + "VPM-07", + "VPM-07.1" + ], + "11.4.3": [ + "VPM-07", + "VPM-07.1" + ], + "11.4.7": [ + "VPM-07" ] }, - "general-nist-800-161-r1-flowdown": { - "AC-1": [ + "general-pci-dss-4-0-1-saq-p2pe": { + "3.1.1": [ "GOV-02", "GOV-03", - "IAC-01" + "OPS-01", + "OPS-01.1" ], - "IR-1": [ + "9.1.1": [ "GOV-02", "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "PES-01", + "OPS-01", + "OPS-01.1" ], - "MA-1": [ + "12.1.1": [ "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "GOV-03" ], - "PS-1": [ + "12.1.2": [ "GOV-02", - "GOV-03", - "HRS-01" + "GOV-03" ], - "PT-1": [ - "GOV-03", - "PRI-01", - "SEA-01" + "12.1.3": [ + "GOV-02", + "GOV-04", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1" ], - "PM-5": [ + "9.5.1": [ "AST-01", - "AST-02" - ], - "CM-8": [ "AST-02", - "AST-02.3" - ], - "PL-2": [ - "AST-04", - "IAO-03", - "IAO-03.1" - ], - "SR-10": [ + "AST-06", + "AST-07", + "AST-15", "AST-15.1", - "TDA-11" - ], - "CP-2(7)": [ - "BCD-01.2" - ], - "CP-3": [ - "BCD-03" - ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" - ], - "CM-3": [ - "CHG-01", - "CHG-02" - ], - "AC-5": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" - ], - "CM-9": [ - "CHG-05", - "CFG-01" - ], - "CM-2": [ - "CFG-02", - "CFG-02.1" - ], - "CM-6": [ - "CFG-02", - "CFG-02.7" - ], - "CM-7": [ - "CFG-03" - ], - "SI-4": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" - ], - "AU-2": [ - "MON-01.8", - "MON-02" - ], - "AU-3": [ - "MON-03" + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "AU-12": [ - "MON-06" + "9.5.1.1": [ + "AST-01", + "AST-02", + "AST-07" ], - "AU-13": [ - "MON-11" + "9.5.1.2": [ + "AST-07", + "AST-08", + "AST-15.1" ], - "AU-14": [ - "MON-12" + "9.4.1.1": [ + "BCD-11", + "BCD-11.2" ], - "AU-16(2)": [ - "MON-14.1" + "12.10.1": [ + "BCD-11", + "HRS-03", + "IRO-04", + "IRO-10", + "NET-12.1" ], - "SC-8": [ - "CRY-03", - "CRY-04" + "12.8.1": [ + "CLD-01", + "NET-14", + "TPM-01", + "TPM-01.1", + "TPM-05.5" ], - "SC-28": [ - "CRY-05", - "END-02" + "9.4.1": [ + "DCH-01", + "DCH-01.1", + "DCH-06", + "DCH-06.1" ], - "MP-4": [ - "DCH-06" + "3.3.1.2": [ + "DCH-06.5" ], - "MP-6": [ + "9.4.6": [ "DCH-08", - "DCH-09", - "DCH-09.3" - ], - "AC-20": [ - "DCH-13" - ], - "AC-23": [ - "DCH-16", - "PRI-05.4" - ], - "SI-3": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" - ], - "SI-2": [ - "END-04.1", - "VPM-01", - "VPM-05" - ], - "SI-7": [ - "END-06", - "NET-12", - "TDA-18" - ], - "PS-3": [ - "HRS-04" - ], - "PS-6": [ - "HRS-06", - "HRS-06.1" - ], - "IA-4": [ - "IAC-01.2", - "IAC-09" - ], - "IA-2": [ - "IAC-02" + "DCH-18", + "PRI-05" ], - "IA-9": [ - "IAC-05" + "3.2.1": [ + "DCH-18", + "TPM-04.4" ], - "AC-2": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "9.5.1.3": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "IA-5": [ - "IAC-10", - "IAC-10.8" + "12.6.1": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-04" ], - "AC-3": [ - "IAC-20", - "NET-12", - "TDA-18" + "12.8.2": [ + "TPM-04", + "TPM-05", + "TPM-05.4" ], - "AC-24": [ - "IAC-28.1" + "12.8.3": [ + "TPM-04.1" ], - "IR-8": [ - "IRO-04" + "12.8.5": [ + "TPM-05", + "TPM-05.4" ], - "IR-2": [ - "IRO-05" + "12.8.4": [ + "TPM-08" + ] + }, + "general-scf-dpmp-2025": {}, + "general-shared-assessments-sig-2025": { + "R.6": [ + "GOV-04.1" ], - "IR-4(10)": [ - "IRO-10.4", - "TPM-11" + "B.1": [ + "GOV-08" ], - "IR-6(3)": [ - "IRO-10.4" + "P.8": [ + "GOV-10", + "CLD-11", + "DCH-01.1", + "PRI-13", + "SEA-11", + "TPM-05.1", + "TPM-07" ], - "IR-7(2)": [ - "IRO-11.2" + "K.1": [ + "GOV-14", + "BCD-11", + "BCD-14", + "CAP-01", + "HRS-13.4" ], - "IR-9": [ - "IRO-12", - "IRO-12.1" + "R.1": [ + "AAT-01", + "AAT-03" ], - "MA-4": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "R.1.1": [ + "AAT-01.1" ], - "MA-5(4)": [ - "MNT-06.1" + "R.1.1.1": [ + "AAT-01.2" ], - "SC-7": [ - "NET-03" + "R.2": [ + "AAT-01.3" ], - "AC-4": [ - "NET-04" + "R.5": [ + "AAT-02" ], - "CA-3": [ - "NET-05" + "R.2.1": [ + "AAT-03.1" ], - "SC-7(13)": [ - "NET-06.1" + "R.4.1": [ + "AAT-04.2", + "AAT-06" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "R.10": [ + "AAT-08" ], - "AC-17": [ - "NET-14" + "R.14": [ + "AAT-09" ], - "PE-2": [ - "PES-02" + "R.16": [ + "AAT-13.1" ], - "PM-18": [ - "PRI-01" + "R.18.1": [ + "AAT-15.1" ], - "RA-9": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "R.13": [ + "AAT-16.5" ], - "PM-30": [ - "RSK-09" + "D.1": [ + "AST-01" ], - "RA-3(1)": [ - "RSK-09.1" + "G.3": [ + "AST-02.11", + "NET-05.2" ], - "SC-36": [ - "SEA-15" + "P.3.1": [ + "AST-04.1" ], - "AT-3": [ - "SAT-03" + "O.9": [ + "AST-14.2" ], - "SA-21": [ - "TDA-13" + "M.1.1": [ + "AST-20", + "EMB-01", + "EMB-13", + "END-01", + "TDA-05.2" ], - "SR-3(3)": [ - "TPM-05", - "TPM-05.2" + "N.9": [ + "AST-22" ], - "AT-2(2)": [ - "THR-05" + "R.9": [ + "AST-31.1" ], - "SI-20": [ - "THR-08" + "K.4": [ + "BCD-01", + "BCD-02.2", + "BCD-10.4", + "BCD-11.2", + "BCD-13" ], - "RA-5": [ - "VPM-06", - "VPM-06.1" - ] - }, - "general-nist-800-161-r1-level-1": { - "AC-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "F.1": [ + "BCD-02.4" ], - "AT-1": [ - "GOV-02", - "GOV-03", - "SAT-01" + "R.8": [ + "BCD-16" ], - "AU-1": [ - "GOV-02", - "GOV-03", - "MON-01" + "N.2": [ + "CAP-02", + "CAP-03", + "CLD-02", + "CLD-06", + "EMB-11", + "NET-01", + "SEA-16" ], - "CA-1": [ - "GOV-02", - "GOV-03", - "IAO-01" + "G.2": [ + "CHG-02.1" ], - "CM-1": [ - "GOV-02", - "GOV-03", - "CFG-01" + "J.1": [ + "CLD-01" ], - "CP-1": [ - "GOV-02", - "GOV-03", - "BCD-01" + "N.11": [ + "CLD-12", + "CFG-02", + "CFG-02.9", + "TDA-09.6" ], - "IA-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "L.1": [ + "CPL-01", + "PRI-14" ], - "IR-1": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "I.1.1": [ + "CFG-02.4", + "TDA-08" ], - "MA-1": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "N.7": [ + "MON-01.1", + "MON-01.5", + "END-07", + "NET-08", + "NET-08.2" ], - "MP-1": [ - "GOV-02", - "GOV-03", - "DCH-01" + "J.5": [ + "MON-01.8", + "MON-02.3", + "MON-02.4", + "MON-16.1", + "MON-16.2", + "IRO-03" ], - "PE-1": [ - "GOV-02", - "GOV-03", - "PES-01" + "P.6": [ + "MON-03.5", + "DCH-18.1", + "PES-06.5", + "PRI-01.7", + "PRI-04.1" ], - "PS-1": [ - "GOV-02", - "GOV-03", - "HRS-01" + "D.3": [ + "MON-10" ], - "RA-1": [ - "GOV-02", - "GOV-03", - "RSK-01" + "P.3": [ + "DCH-01", + "PRI-01" ], - "SC-1": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "L.6": [ + "DCH-25.1" ], - "SI-1": [ - "GOV-02", - "GOV-03", - "SEA-01" + "U.1.5.1": [ + "END-04", + "END-04.2", + "END-04.4" ], - "SR-1": [ - "GOV-02", - "GOV-03", - "TPM-01" + "J.5.1": [ + "END-04.6" ], - "PT-1": [ - "GOV-03", - "PRI-01", - "SEA-01" + "J.4": [ + "END-06.2", + "IRO-01" ], - "SA-1": [ - "GOV-03", - "TDA-01", - "TDA-06" + "P.2.2.1": [ + "END-13.1" ], - "PL-9": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "M.3": [ + "END-14.1", + "END-14.2", + "END-14.6" ], - "PM-2": [ - "GOV-04" + "M.1.12": [ + "HRS-05.5" ], - "PM-6": [ - "GOV-04", - "GOV-05" + "U.1.3": [ + "IAC-10.8" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "U.1.4": [ + "IAC-25" ], - "PM-15": [ - "GOV-07", - "THR-01" + "K.7": [ + "IRO-12.3" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "M.1.3": [ + "MDM-01", + "MDM-04" ], - "PM-8": [ - "BCD-01", - "CPL-01" + "M.1.2": [ + "MDM-09", + "MDM-11" ], - "SC-47": [ - "BCD-10.4" + "N.5": [ + "NET-03.1", + "NET-03.2", + "NET-14" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "N.3.1": [ + "NET-05.1" ], - "RA-3": [ - "CPL-03.2", - "RSK-04" + "N.8": [ + "NET-10", + "NET-10.1", + "WEB-02" ], - "SA-8": [ - "CFG-02", - "SEA-01" + "P.2.4": [ + "NET-10.2" ], - "PM-31": [ - "MON-01" + "U.1.2": [ + "NET-15.2" ], - "SI-4": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "P.5.3": [ + "PRI-04.2", + "RSK-06" ], - "AU-2": [ - "MON-01.8", - "MON-02" + "P.5.1": [ + "PRI-05.2", + "SEA-09.1" ], - "AU-3": [ - "MON-03" + "P.2.3": [ + "PRI-05.4" ], - "AC-18": [ - "CRY-07", - "NET-15" + "O.12": [ + "PRI-16" ], - "MP-4": [ - "DCH-06" + "P.5": [ + "RSK-10" ], - "MP-5": [ - "DCH-07" + "T.3": [ + "SEA-08.1" ], - "AC-20": [ - "DCH-13" + "P.4": [ + "SAT-03.5", + "SAT-03.6" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "C.4": [ + "TDA-22.1" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "K.6": [ + "TPM-10" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "T.2": [ + "THR-06", + "VPM-01", + "VPM-05.1", + "VPM-06.3" ], - "IA-2": [ - "IAC-02" + "N.4": [ + "VPM-05" + ] + }, + "general-sparta": { + "CM0005": [ + "GOV-01" ], - "IA-3": [ - "IAC-04" + "CM0088": [ + "GOV-02" ], - "IA-4(6)": [ - "IAC-09.4" + "CM0049": [ + "AAT-12.1", + "AAT-12.2", + "AST-03.2" ], - "AC-24": [ - "IAC-28.1" + "CM0013": [ + "AST-01.1" ], - "IR-4(6)": [ - "IRO-02.2" + "CM0022": [ + "AST-01.1", + "AST-04", + "AST-31", + "TDA-06.1", + "TPM-02" ], - "IR-4(7)": [ - "IRO-02.2" + "CM0026": [ + "AST-03.2", + "RSK-09", + "TPM-03" ], - "PM-10": [ - "IAO-01" + "CM0001": [ + "AST-04.1", + "DCH-01", + "DCH-01.2", + "DCH-02" ], - "CA-6": [ - "IAO-07" + "CM0028": [ + "AST-15", + "TDA-11" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "CM0057": [ + "AST-15" ], - "PE-6": [ - "PES-05" + "CM0070": [ + "BCD-10.4" ], - "PE-18": [ - "PES-12" + "CM0056": [ + "BCD-11" ], - "PM-18": [ - "PRI-01" + "CM0021": [ + "CHG-04.2" ], - "PM-19": [ - "PRI-01.1" + "CM0023": [ + "CFG-01", + "CFG-02.2" ], - "PM-20": [ - "PRI-01.3" + "CM0037": [ + "CFG-02", + "CFG-02.5", + "EMB-04", + "EMB-06" ], - "PM-21": [ - "PRI-14.1" + "CM0047": [ + "CFG-02", + "CFG-02.5", + "CFG-03", + "CFG-03.3" ], - "PM-3": [ - "PRM-02" + "CM0069": [ + "CFG-03.3" ], - "SA-2": [ - "PRM-03" + "CM0090": [ + "MON-01" ], - "RA-9": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "CM0032": [ + "MON-01.1" ], - "PM-11": [ - "PRM-06" + "CM0073": [ + "MON-01.3", + "MON-11.1", + "NET-08" ], - "SA-3": [ - "PRM-07", - "SEA-07.1" + "CM0052": [ + "MON-16.1", + "IRO-02.2", + "THR-04", + "THR-05" ], - "PM-9": [ - "RSK-01" + "CM0050": [ + "CRY-01" ], - "PM-28": [ - "RSK-01.1" + "CM0030": [ + "CRY-09" ], - "RA-2": [ - "RSK-02" + "CM0014": [ + "END-06.5", + "END-06.6" ], - "RA-7": [ - "RSK-06.1" + "CM0054": [ + "HRS-12.1" ], - "PM-30": [ - "RSK-09" + "CM0031": [ + "IAC-01.2", + "IAC-02" ], - "SA-9(3)": [ - "RSK-09", - "TPM-02", - "TPM-03", - "TPM-05", - "TPM-05.4", - "TPM-05.7" + "CM0035": [ + "IAC-10.5" ], - "RA-3(1)": [ - "RSK-09.1" + "CM0039": [ + "IAC-21" ], - "PM-7": [ - "SEA-02" + "CM0036": [ + "IAC-25" ], - "SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "CM0089": [ + "IAO-01" ], - "SA-11": [ - "TDA-09" + "CM0002": [ + "NET-01" ], - "SR-11": [ - "TDA-11" + "CM0033": [ + "NET-01" ], - "SR-5": [ - "TPM-03.1" + "CM0038": [ + "NET-06" ], - "SR-3": [ - "TPM-03.3" + "CM0053": [ + "PES-01" ], - "PM-16": [ - "THR-01" + "CM0040": [ + "SEA-05" ], - "PM-12": [ - "THR-04" + "CM0044": [ + "SEA-07.2" ], - "RA-10": [ - "THR-07" - ] - }, - "general-nist-800-161-r1-level-2": { - "AC-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "CM0074": [ + "SEA-15" ], - "AT-1": [ - "GOV-02", - "GOV-03", - "SAT-01" + "CM0041": [ + "SAT-03", + "SAT-03.2", + "SAT-03.3", + "SAT-03.6" ], - "AU-1": [ - "GOV-02", - "GOV-03", - "MON-01" + "CM0007": [ + "TDA-03", + "VPM-01" ], - "CA-1": [ - "GOV-02", - "GOV-03", - "IAO-01" + "CM0012": [ + "TDA-04.2" ], - "CM-1": [ - "GOV-02", - "GOV-03", - "CFG-01" + "CM0017": [ + "TDA-06", + "TDA-06.3" ], - "CP-1": [ - "GOV-02", - "GOV-03", - "BCD-01" + "CM0043": [ + "TDA-06", + "TDA-06.3", + "TDA-06.5", + "TDA-09.2", + "TDA-09.3" ], - "IA-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "CM0020": [ + "TDA-06.2" ], - "IR-1": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "CM0004": [ + "TDA-07" ], - "MA-1": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "CM0019": [ + "TDA-09.2" ], - "MP-1": [ - "GOV-02", - "GOV-03", - "DCH-01" + "CM0018": [ + "TDA-09.3" ], - "PE-1": [ - "GOV-02", - "GOV-03", - "PES-01" + "CM0024": [ + "TDA-11", + "TDA-11.1" ], - "PL-1": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "CM0025": [ + "TPM-01", + "TPM-04.1" ], - "PS-1": [ - "GOV-02", - "GOV-03", - "HRS-01" + "CM0027": [ + "TPM-03", + "TPM-03.1" ], - "RA-1": [ - "GOV-02", - "GOV-03", - "RSK-01" + "CM0009": [ + "THR-01" ], - "SC-1": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "CM0016": [ + "VPM-01", + "VPM-03", + "VPM-03.1" ], - "SI-1": [ - "GOV-02", - "GOV-03", - "SEA-01" + "CM0010": [ + "VPM-05" ], - "SR-1": [ - "GOV-02", - "GOV-03", - "TPM-01" + "CM0008": [ + "VPM-06", + "VPM-07" ], - "PT-1": [ - "GOV-03", - "PRI-01", - "SEA-01" + "CM0011": [ + "VPM-06" + ] + }, + "general-swift-cscf-2025": { + "2.4": [ + "GOV-15", + "AST-04", + "AST-04.1", + "DCH-03.1", + "DCH-14", + "DCH-14.2", + "DCH-25", + "NET-02", + "NET-02.3", + "NET-04", + "NET-05", + "NET-05.2" ], - "SA-1": [ - "GOV-03", - "TDA-01", - "TDA-06" + "3.1": [ + "AST-09", + "NET-14.5", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03", + "PES-04", + "PES-04.1", + "PES-05", + "PES-06", + "PES-06.3", + "PES-12" ], - "PL-9": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "2.9": [ + "AST-14", + "MON-16", + "DCH-01", + "DCH-01.2", + "DCH-25", + "DCH-25.1", + "SAT-03.2" ], - "PM-2": [ - "GOV-04" + "1.5": [ + "AST-27", + "IAC-20.4", + "NET-03", + "NET-04", + "NET-04.1", + "NET-06", + "NET-06.3", + "NET-14", + "WEB-02" ], - "PM-6": [ - "GOV-04", - "GOV-05" + "2.6": [ + "AST-27", + "CFG-02.5", + "CRY-01", + "CRY-03", + "CRY-04", + "IAC-20.4", + "NET-01", + "NET-06.3" ], - "PM-15": [ - "GOV-07", - "THR-01" + "6.3": [ + "AST-28", + "AST-28.1", + "MON-02", + "MON-02.2", + "IRO-01", + "IRO-02" ], - "PM-32": [ - "GOV-11" + "2.8": [ + "BCD-02", + "PRM-05", + "PRM-06", + "TPM-01", + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-04.3", + "TPM-04.4", + "TPM-05", + "TPM-05.2", + "TPM-05.4", + "TPM-05.5", + "TPM-05.6", + "TPM-05.7", + "TPM-08", + "TPM-09", + "TPM-10" ], - "PM-5": [ - "AST-01", - "AST-02" + "1.3": [ + "CFG-01", + "CFG-02", + "SEA-01", + "SEA-02", + "SEA-13.1" ], - "CM-8": [ - "AST-02", - "AST-02.3" + "2.3": [ + "CFG-01", + "CFG-02", + "CFG-02.1", + "CFG-02.2", + "CFG-02.5", + "CFG-02.8", + "CFG-02.9", + "CFG-03", + "CFG-03.3", + "IAC-21" ], - "CM-13": [ - "AST-02.8" + "2.10": [ + "CFG-02", + "CFG-02.5", + "CFG-02.7", + "CFG-02.9", + "CFG-03", + "IAC-20", + "IAC-21" ], - "CM-8(8)": [ - "AST-02.10" + "4.1": [ + "CFG-02", + "CFG-02.5", + "IAC-01", + "IAC-10", + "IAC-10.1" ], - "SR-4": [ - "AST-03.2" + "5.2": [ + "CFG-02", + "CRY-01", + "IAC-01", + "IAC-10.7" ], - "SR-12": [ - "AST-09", - "TDA-11.2" + "6.4": [ + "MON-01", + "MON-01.16", + "MON-02", + "MON-02.2", + "MON-08", + "MON-10", + "DCH-18" ], - "SR-9": [ - "AST-15" + "6.5A": [ + "MON-01", + "MON-01.1", + "END-07", + "NET-08" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "6.2": [ + "MON-01.7", + "MON-02", + "MON-02.2", + "END-06", + "END-06.1", + "IRO-01", + "IRO-02" ], - "CP-2": [ - "BCD-01", - "BCD-06" + "6.1": [ + "MON-02", + "MON-02.2", + "END-01", + "END-04", + "END-04.1", + "IRO-01", + "IRO-02" ], - "CP-2(1)": [ - "BCD-01.1" + "2.1": [ + "CRY-03", + "CRY-04", + "DCH-03.1", + "DCH-03.3", + "DCH-14", + "DCH-14.2" ], - "CP-3": [ - "BCD-03" + "2.5A": [ + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-05.1", + "DCH-01", + "DCH-01.2", + "DCH-25" ], - "CP-3(1)": [ - "BCD-03.1" + "2.11A": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", + "DCH-03.1", + "DCH-14", + "PRM-05", + "PRM-06" ], - "CP-4": [ - "BCD-04", - "BCD-05" + "5.1": [ + "HRS-01", + "HRS-02", + "HRS-04.1", + "HRS-11", + "IAC-08", + "IAC-20", + "IAC-21" ], - "CP-6": [ - "BCD-08" + "5.3A": [ + "HRS-01", + "HRS-02.1", + "HRS-04", + "HRS-04.1", + "HRS-10" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "4.2": [ + "IAC-06" ], - "CP-6(1)": [ - "BCD-08.1" + "1.2": [ + "IAC-08", + "IAC-16", + "IAC-21", + "IAC-21.2", + "IAC-21.3" ], - "CP-7": [ - "BCD-09" + "5.4": [ + "IAC-10", + "IAC-10.5", + "IAC-10.6", + "IAC-10.11" ], - "CP-8": [ - "BCD-10" + "7.1": [ + "IRO-01", + "IRO-02", + "IRO-02.4", + "IRO-04", + "IRO-06" ], - "CP-11": [ - "BCD-10" + "7.3A": [ + "IAO-01.1", + "TDA-09.5", + "VPM-07" ], - "CP-8(3)": [ - "BCD-10.2" + "1.1": [ + "NET-01", + "NET-02", + "NET-04", + "NET-04.1", + "NET-06", + "NET-06.1", + "NET-06.3", + "NET-06.4", + "WEB-02" ], - "CP-8(4)": [ - "BCD-10.3" + "1.4": [ + "NET-01", + "NET-06", + "NET-06.3", + "NET-06.5", + "NET-18", + "NET-18.1" ], - "SC-47": [ - "BCD-10.4" + "7.4A": [ + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-04.2", + "THR-03", + "THR-09", + "THR-10" ], - "SC-5(2)": [ - "CAP-02", - "CAP-03" + "7.2": [ + "SAT-01", + "SAT-01.1", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "CP-2(2)": [ - "CAP-03" + "2.2": [ + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-03", + "VPM-04", + "VPM-04.1", + "VPM-04.3", + "VPM-05", + "VPM-05.1", + "VPM-05.8" ], - "CM-3": [ - "CHG-01", - "CHG-02" + "2.7": [ + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-04", + "VPM-06", + "VPM-06.1", + "VPM-06.2", + "VPM-06.4" + ] + }, + "general-tisax-6-0-3": { + "1.2.1": [ + "GOV-01", + "GOV-01.1", + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "GOV-05", + "GOV-15", + "GOV-15.1", + "CPL-01", + "CPL-01.2" ], - "CM-3(1)": [ - "CHG-02.1" + "1.1.1": [ + "GOV-02", + "GOV-08", + "GOV-09", + "CPL-01" ], - "CM-3(2)": [ - "CHG-02.2", - "CHG-06" + "1.5.1": [ + "GOV-02", + "GOV-02.1", + "GOV-03", + "CPL-01.1", + "CPL-02", + "CPL-02.1" ], - "CM-3(4)": [ - "CHG-02.3" + "7.1.1": [ + "GOV-02", + "CPL-01" ], - "CM-5": [ - "CHG-04", - "END-03.2" + "9.1.1": [ + "GOV-02" ], - "AC-5": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "1.2.2": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "AST-01.2", + "HRS-02", + "HRS-03", + "HRS-03.2" ], - "CM-9": [ - "CHG-05", - "CFG-01" + "1.2.4": [ + "GOV-04.1", + "GOV-15.1", + "AST-04.1", + "HRS-03", + "TPM-05", + "TPM-05.4" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "7.1.2": [ + "GOV-09", + "CPL-01", + "PRI-01", + "PRI-01.6" ], - "CA-2": [ - "CPL-03", - "CPL-03.2", + "5.3.1": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "CHG-03", + "CFG-01", "IAO-02", - "IAO-06", - "PRM-04" - ], - "RA-3": [ - "CPL-03.2", - "RSK-04" + "PRM-04", + "PRM-07", + "SEA-01", + "SEA-01.1", + "SEA-02" ], - "CM-9(1)": [ - "CFG-01.1" + "5.3.2": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "PRM-05" ], - "CM-2": [ - "CFG-02", - "CFG-02.1" + "3.1.3": [ + "AST-01", + "AST-09", + "MNT-04.3", + "PES-10" ], - "CM-6": [ - "CFG-02", - "CFG-02.7" + "5.3.3": [ + "AST-01", + "AST-02.1", + "PES-10" ], - "PL-10": [ - "CFG-02" + "1.3.1": [ + "AST-01.1", + "AST-01.2", + "AST-03" ], - "SA-8": [ - "CFG-02", - "SEA-01" + "1.3.4": [ + "AST-02.7", + "CFG-03.2", + "CFG-04", + "CFG-05" ], - "CM-2(6)": [ - "CFG-02.4" + "1.2.3": [ + "AST-04.1", + "DCH-02", + "PRM-04", + "PRM-05" ], - "CM-7(6)": [ - "CFG-02.5" + "8.2.4": [ + "AST-04.1", + "DCH-02" ], - "CM-7(9)": [ - "CFG-02.5" + "8.2.6": [ + "AST-04.1", + "DCH-01.2", + "DCH-02", + "DCH-06", + "DCH-09.3", + "END-13.2" ], - "CM-7(1)": [ - "CFG-03.1" + "5.2.8": [ + "BCD-01", + "BCD-02" ], - "CM-7(4)": [ - "CFG-03.3" + "5.2.9": [ + "BCD-11" ], - "CM-10": [ - "CFG-04" + "5.2.1": [ + "CHG-01", + "CHG-02" ], - "CM-10(1)": [ - "CFG-04.1" + "5.2.2": [ + "CHG-02.3", + "CHG-03" ], - "CM-11": [ - "CFG-05", - "END-03" + "5.2.6": [ + "CPL-02", + "CPL-02.1", + "CPL-03", + "CPL-03.2" ], - "CM-3(8)": [ - "CFG-06" + "1.5.2": [ + "CPL-03", + "CPL-03.2", + "IAO-05" ], - "PM-31": [ - "MON-01" + "3.1.4": [ + "CFG-02", + "MDM-01" ], - "SI-4": [ + "5.2.4": [ "MON-01", + "MON-01.4", "MON-02", - "NET-12", - "TDA-18" + "MON-02.1", + "MON-02.2" ], - "AU-2": [ - "MON-01.8", - "MON-02" + "5.1.1": [ + "CRY-01" ], - "SI-4(19)": [ - "MON-01.14" + "5.1.2": [ + "DCH-01", + "DCH-02", + "NET-01" ], - "AU-6": [ - "MON-02", - "MON-02.6" + "1.3.2": [ + "DCH-01.2", + "DCH-01.4", + "DCH-02" ], - "SI-4(17)": [ - "MON-02.3" + "8.2.7": [ + "DCH-07.1", + "HRS-05.1" ], - "AU-3": [ - "MON-03" + "5.2.3": [ + "END-02", + "END-04" ], - "AU-12": [ - "MON-06" + "8.2.5": [ + "HRS-01", + "HRS-05.1", + "IAC-07" ], - "AU-10(1)": [ - "MON-09.1" + "2.1.1": [ + "HRS-02", + "HRS-02.1", + "HRS-03", + "HRS-03.2", + "HRS-04", + "HRS-04.1" ], - "AU-10(2)": [ - "MON-09.1" + "9.7.2": [ + "HRS-03", + "SAT-03" ], - "AU-13": [ - "MON-11" + "2.1.3": [ + "HRS-03.1", + "SAT-02" ], - "AU-14": [ - "MON-12" + "2.1.2": [ + "HRS-05", + "HRS-06", + "HRS-06.1" ], - "AU-16": [ - "MON-14" + "9.7.1": [ + "HRS-05" ], - "AU-16(2)": [ - "MON-14.1" + "6.1.2": [ + "HRS-06.1" ], - "SC-8": [ - "CRY-03", - "CRY-04" + "4.1.1": [ + "IAC-01" ], - "SC-28": [ - "CRY-05", - "END-02" + "4.1.2": [ + "IAC-02" ], - "AC-18": [ - "CRY-07", - "NET-15" + "4.1.3": [ + "IAC-02", + "IAC-07", + "IAC-10.5", + "IAC-10.8", + "IAC-15.5" ], - "AC-3(9)": [ - "DCH-03.3" + "4.2.1": [ + "IAC-07", + "IAC-08", + "IAC-17", + "IAC-21", + "IAC-28.1" ], - "MP-4": [ - "DCH-06" + "1.6.1": [ + "IRO-02", + "IRO-03" ], - "MP-5": [ - "DCH-07" + "1.6.2": [ + "IRO-02", + "IRO-09", + "IRO-10", + "IRO-13" ], - "MP-6": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "1.6.3": [ + "IRO-02", + "IRO-04", + "IRO-07" ], - "AC-20": [ - "DCH-13" + "9.6.2": [ + "IRO-02", + "IRO-04", + "IRO-10.2" ], - "AC-20(1)": [ - "DCH-13.1" + "5.2.7": [ + "NET-01", + "NET-06" ], - "PM-17": [ - "DCH-13.3" + "2.1.4": [ + "NET-14", + "NET-14.5", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "AC-20(3)": [ - "DCH-13.4" + "8.1.2": [ + "PES-01" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "8.1.1": [ + "PES-01.1", + "OPS-02" ], - "AC-22": [ - "DCH-15" + "3.1.1": [ + "PES-01.2" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "8.1.3": [ + "PES-03" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "5.3.4": [ + "PES-03.4", + "PES-04", + "PES-18" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "8.1.5": [ + "PES-04" ], - "CM-12": [ - "DCH-24" + "8.1.8": [ + "PES-04", + "PES-18" ], - "CM-12(1)": [ - "DCH-24.1" + "8.1.6": [ + "PES-05", + "PES-05.1" ], - "SI-3": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "8.1.7": [ + "PES-06" ], - "SI-2": [ - "END-04.1", - "VPM-01", - "VPM-05" + "8.1.4": [ + "PES-12" ], - "SI-7": [ - "END-06", - "NET-12", - "TDA-18" + "9.5.1": [ + "PRI-01.5" ], - "CM-7(8)": [ - "END-06.7" + "9.5.2": [ + "PRI-01.5", + "PRI-04.1", + "PRI-07", + "PRI-07.1" ], - "SI-7(14)": [ - "END-06.7" + "9.5.3": [ + "PRI-01.5" ], - "SC-27": [ - "END-10" + "9.2.1": [ + "PRI-01.7" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "9.6.1": [ + "PRI-06.4" ], - "PS-3": [ - "HRS-04" + "9.3.1": [ + "PRI-15" ], - "PL-4": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "8.3.1": [ + "PRM-05", + "TPM-05", + "TPM-05.1" ], - "PS-6": [ - "HRS-06", - "HRS-06.1" + "1.4.1": [ + "RSK-01", + "RSK-01.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-04.1" ], - "PS-7": [ - "HRS-10" + "9.4.1": [ + "RSK-10" ], - "IA-4": [ - "IAC-01.2", - "IAC-09" + "9.8.1": [ + "OPS-01.1", + "OPS-05" ], - "IA-2": [ - "IAC-02" + "8.2.3": [ + "SAT-01", + "SAT-02", + "SAT-04" ], - "IA-8": [ - "IAC-03" + "1.3.3": [ + "TPM-01", + "TPM-04.1", + "TPM-05", + "TPM-05.4" ], - "IA-3": [ - "IAC-04" + "6.1.1": [ + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-08" ], - "IA-9": [ - "IAC-05" + "8.2.1": [ + "TPM-05" ], - "AC-6(6)": [ - "IAC-05.2" + "8.2.2": [ + "TPM-05", + "TPM-05.6", + "TPM-05.8" ], - "AC-2": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "5.2.5": [ + "THR-03", + "VPM-01.1", + "VPM-02", + "VPM-03", + "VPM-03.1" + ] + }, + "general-ul-2900-1-2017": { + "4.1(e)": [ + "CHG-04.5" ], - "IA-4(6)": [ - "IAC-09.4" + "4.1(g)": [ + "IAO-01.1" ], - "IA-5": [ - "IAC-10", - "IAC-10.8" + "4.1(h)": [ + "IAO-02.2" ], - "AC-3": [ - "IAC-20", - "NET-12", - "TDA-18" + "12.1(g)": [ + "IAO-05" ], - "AC-3(8)": [ - "IAC-20.6" + "12.1(h)": [ + "IAO-05" ], - "AC-24": [ - "IAC-28.1" + "12.1(a)": [ + "PRM-05" ], - "IR-4(6)": [ - "IRO-02.2" + "12.1(f)": [ + "RSK-01.3" ], - "IR-4(7)": [ - "IRO-02.2" + "12.1(d)": [ + "RSK-04" ], - "IR-8": [ - "IRO-04" + "12.1(e)": [ + "RSK-04" ], - "IR-2": [ - "IRO-05" + "12.1": [ + "RSK-10", + "TDA-06.2" ], - "IR-3": [ - "IRO-06" + "7.1": [ + "TDA-01.1" ], - "AU-10(3)": [ - "IRO-08" + "7.1.1": [ + "TDA-01.1" ], - "IR-5": [ - "IRO-09" + "7.1.2": [ + "TDA-01.1" ], - "IR-4(10)": [ - "IRO-10.4", - "TPM-11" + "7.1.3": [ + "TDA-01.1" ], - "PM-10": [ - "IAO-01" + "7.1.4": [ + "TDA-01.1" ], - "CA-5": [ - "IAO-05" + "7.1.5": [ + "TDA-01.1" ], - "PM-4": [ - "IAO-05", - "VPM-02" + "8.1": [ + "TDA-01.1" ], - "CA-6": [ - "IAO-07" + "8.2": [ + "TDA-01.1" ], - "MA-3": [ - "MNT-04" + "8.3": [ + "TDA-01.1" ], - "MA-4": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "8.3(a)": [ + "TDA-01.1" ], - "MA-4(3)": [ - "MNT-05.6" + "8.3(b)": [ + "TDA-01.1" ], - "MA-5": [ - "MNT-06" + "8.3(c)": [ + "TDA-01.1" ], - "MA-5(4)": [ - "MNT-06.1" + "8.3(c)(i)": [ + "TDA-01.1" ], - "SR-11(2)": [ - "MNT-07" + "8.3(c)(ii)": [ + "TDA-01.1" ], - "AC-19": [ - "MDM-02" + "8.3(c)(iii)": [ + "TDA-01.1" ], - "PE-3(5)": [ - "MDM-04" + "8.3(d)": [ + "TDA-01.1" ], - "SC-7": [ - "NET-03" + "8.3(e)": [ + "TDA-01.1" ], - "AC-4": [ - "NET-04" + "8.3(f)": [ + "TDA-01.1" ], - "AC-4(6)": [ - "NET-04.5" + "8.4": [ + "TDA-01.1" ], - "AC-4(17)": [ - "NET-04.12" + "8.4(a)": [ + "TDA-01.1" ], - "AC-4(19)": [ - "NET-04.13" + "8.4(b)": [ + "TDA-01.1" ], - "SC-37(1)": [ - "NET-11" + "8.5": [ + "TDA-01.1" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "8.6": [ + "TDA-01.1" ], - "AC-17": [ - "NET-14" + "8.7": [ + "TDA-01.1" ], - "AC-17(6)": [ - "NET-14" + "8.8": [ + "TDA-01.1" ], - "PE-2": [ - "PES-02" + "8.9": [ + "TDA-01.1" ], - "PE-2(1)": [ - "PES-02.1" + "9.1": [ + "TDA-01.1" ], - "PE-3": [ - "PES-03" + "10.1": [ + "TDA-01.1" ], - "PE-3(2)": [ - "PES-03" + "10.2": [ + "TDA-01.1" ], - "SC-7(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "10.3": [ + "TDA-01.1" ], - "PE-3(1)": [ - "PES-03.4" + "10.4": [ + "TDA-01.1" ], - "PE-6": [ - "PES-05" + "11.1": [ + "TDA-01.1" ], - "PE-18": [ - "PES-12" + "11.2": [ + "TDA-01.1" ], - "PE-20": [ - "PES-14" + "11.3": [ + "TDA-01.1" ], - "PM-18": [ - "PRI-01" + "11.4": [ + "TDA-01.1" ], - "PM-20": [ - "PRI-01.3" + "11.5": [ + "TDA-01.1" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "11.5(a)": [ + "TDA-01.1" ], - "PM-27": [ - "PRI-14" + "11.5(b)": [ + "TDA-01.1" ], - "PM-21": [ - "PRI-14.1" + "11.5(c)": [ + "TDA-01.1" ], - "PM-3": [ - "PRM-02" + "11.6": [ + "TDA-01.1" ], - "SA-2": [ - "PRM-03" + "11.6(a)": [ + "TDA-01.1" ], - "RA-9": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "11.6(b)": [ + "TDA-01.1" ], - "PM-11": [ - "PRM-06" + "11.6(c)": [ + "TDA-01.1" ], - "SA-3": [ - "PRM-07", - "SEA-07.1" + "11.7": [ + "TDA-01.1" ], - "RA-2": [ - "RSK-02" + "11.8": [ + "TDA-01.1" ], - "RA-7": [ - "RSK-06.1" + "14.1": [ + "TDA-01.3" ], - "PM-30": [ - "RSK-09" + "14.2": [ + "TDA-01.3" ], - "SA-9(3)": [ - "RSK-09", - "TPM-02", - "TPM-03", - "TPM-05", - "TPM-05.4", - "TPM-05.7" + "4.1": [ + "TDA-04" ], - "SR-7": [ - "RSK-09", - "OPS-01" + "4.1(a)": [ + "TDA-04" ], - "RA-3(1)": [ - "RSK-09.1" + "5.1": [ + "TDA-04" ], - "PL-8": [ - "SEA-02" + "5.1(a)": [ + "TDA-04" ], - "PM-7": [ - "SEA-02" + "5.1(b)": [ + "TDA-04" ], - "SC-4": [ - "SEA-05" + "6.1": [ + "TDA-04" ], - "SC-29": [ - "SEA-13" + "6.2": [ + "TDA-04" ], - "SC-30": [ - "SEA-14" + "6.3": [ + "TDA-04" ], - "SC-30(4)": [ - "SEA-14" + "6.4": [ + "TDA-04" ], - "SC-30(5)": [ - "SEA-14" + "6.5": [ + "TDA-04" ], - "SC-30(2)": [ - "SEA-14.1" + "6.6": [ + "TDA-04" ], - "SC-30(3)": [ - "SEA-14.2" + "6.7": [ + "TDA-04" ], - "SC-36": [ - "SEA-15" + "6.8": [ + "TDA-04" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "6.9": [ + "TDA-04" ], - "AT-2(1)": [ - "SAT-02.1" + "6.10": [ + "TDA-04" ], - "AT-2(3)": [ - "SAT-02.2" + "4.1(b)": [ + "TDA-04.1" ], - "AT-3": [ - "SAT-03" + "4.1(b)(1)": [ + "TDA-04.1" ], - "AT-3(2)": [ - "SAT-03" + "4.1(b)(2)": [ + "TDA-04.1" ], - "AT-3(6)": [ - "SAT-03", - "THR-01", - "THR-03" + "4.1(b)(3)": [ + "TDA-04.1" ], - "AT-2(4)": [ - "SAT-03.2" + "4.1(b)(4)": [ + "TDA-04.1" ], - "AT-2(5)": [ - "SAT-03.2" + "4.1(c)": [ + "TDA-04.2" ], - "AT-2(6)": [ - "SAT-03.6" + "4.1(f)": [ + "TDA-06" ], - "AT-4": [ - "SAT-04" + "12.1(b)": [ + "TDA-06.2", + "THR-09" ], - "SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "12.3": [ + "TDA-09" ], - "SA-4(7)": [ - "TDA-02.2" + "12.3(a)": [ + "TDA-09" ], - "SR-3(1)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "12.3(b)": [ + "TDA-09" ], - "PL-8(2)": [ - "TDA-03.1" + "12.3(c)": [ + "TDA-09" ], - "SA-17": [ - "TDA-05" + "12.4": [ + "TDA-09" ], - "SA-15": [ - "TDA-06" + "12.4(a)": [ + "TDA-09" ], - "SA-15(3)": [ - "TDA-06.1" + "12.4(b)": [ + "TDA-09" ], - "SA-15(4)": [ - "TDA-06.2" + "12.4(c)": [ + "TDA-09" ], - "SA-11": [ + "12.4(d)": [ "TDA-09" ], - "SA-4(8)": [ - "TDA-09.1" + "12.5": [ + "TDA-09" ], - "SR-11": [ - "TDA-11" + "12.5(a)": [ + "TDA-09" ], - "SR-11(3)": [ - "TDA-11" + "12.5(b)": [ + "TDA-09" ], - "SR-11(1)": [ - "TDA-11.1" + "12.5(c)": [ + "TDA-09" ], - "SA-20": [ - "TDA-12" + "12.6": [ + "TDA-09" ], - "SA-21": [ - "TDA-13" + "13.1": [ + "TDA-09" ], - "SA-21(1)": [ - "TDA-13" + "17.1": [ + "TDA-09" ], - "SA-10": [ - "TDA-14" + "17.2": [ + "TDA-09" ], - "SA-16": [ - "TDA-16" + "17.3": [ + "TDA-09" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "17.3(a)": [ + "TDA-09" ], - "SR-13": [ - "TPM-01.1" + "17.3(b)": [ + "TDA-09" ], - "SR-5": [ - "TPM-03.1" + "17.3(c)": [ + "TDA-09" ], - "SR-3": [ - "TPM-03.3" + "18.1": [ + "TDA-09.2" ], - "SA-9(1)": [ - "TPM-04.1" + "18.2": [ + "TDA-09.2" ], - "SR-3(3)": [ - "TPM-05", - "TPM-05.2" + "18.3": [ + "TDA-09.2" ], - "SR-8": [ - "TPM-05.1" + "18.4": [ + "TDA-09.2" ], - "SR-6": [ - "TPM-08" + "18.5": [ + "TDA-09.2" ], - "PM-16": [ - "THR-01" + "15.1": [ + "TDA-09.4" ], - "PM-12": [ - "THR-04" + "15.1(a)": [ + "TDA-09.4" ], - "AT-2(2)": [ - "THR-05" + "15.1(b)": [ + "TDA-09.4" ], - "RA-10": [ - "THR-07" + "15.1(c)": [ + "TDA-09.4" ], - "SI-20": [ - "THR-08" + "15.1(d)": [ + "TDA-09.4" ], - "SI-2(5)": [ - "VPM-05.4" + "15.1(e)": [ + "TDA-09.4" ], - "RA-5": [ - "VPM-06", - "VPM-06.1" + "15.1(f)": [ + "TDA-09.4" ], - "RA-5(3)": [ - "VPM-06.2" + "15.1(g)": [ + "TDA-09.4" ], - "RA-5(6)": [ - "VPM-06.4" - ] - }, - "general-nist-800-161-r1-level-3": { - "AC-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "15.1(h)": [ + "TDA-09.4" ], - "AU-1": [ - "GOV-02", - "GOV-03", - "MON-01" + "15.1(i)": [ + "TDA-09.4" ], - "CA-1": [ - "GOV-02", - "GOV-03", - "IAO-01" + "15.2": [ + "TDA-09.4" ], - "CM-1": [ - "GOV-02", - "GOV-03", - "CFG-01" + "15.3": [ + "TDA-09.4" ], - "CP-1": [ - "GOV-02", - "GOV-03", - "BCD-01" + "15.4": [ + "TDA-09.4" ], - "IA-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "15.5": [ + "TDA-09.4" ], - "IR-1": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "15.6": [ + "TDA-09.4" ], - "MA-1": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "15.7": [ + "TDA-09.4" ], - "PE-1": [ - "GOV-02", - "GOV-03", - "PES-01" + "15.8": [ + "TDA-09.4" ], - "PS-1": [ - "GOV-02", - "GOV-03", - "HRS-01" + "15.9": [ + "TDA-09.4" ], - "RA-1": [ - "GOV-02", - "GOV-03", - "RSK-01" + "15.10": [ + "TDA-09.4" ], - "SC-1": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "15.11": [ + "TDA-09.4" ], - "SI-1": [ - "GOV-02", - "GOV-03", - "SEA-01" + "16.1": [ + "TDA-09.5" ], - "SR-1": [ - "GOV-02", - "GOV-03", - "TPM-01" + "16.1(a)": [ + "TDA-09.5" ], - "PT-1": [ - "GOV-03", - "PRI-01", - "SEA-01" + "16.1(b)": [ + "TDA-09.5" ], - "SA-1": [ - "GOV-03", - "TDA-01", - "TDA-06" + "16.1(c)": [ + "TDA-09.5" ], - "PM-32": [ - "GOV-11" + "16.2": [ + "TDA-09.5" ], - "PM-5": [ - "AST-01", - "AST-02" + "16.2(a)": [ + "TDA-09.5" ], - "CM-8": [ - "AST-02", - "AST-02.3" + "16.2(b)": [ + "TDA-09.5" ], - "CM-8(1)": [ - "AST-02.1" + "16.2(c)": [ + "TDA-09.5" ], - "CM-8(6)": [ - "AST-02.4" + "16.2(d)": [ + "TDA-09.5" ], - "SC-7(19)": [ - "AST-02.5" + "16.2(e)": [ + "TDA-09.5" ], - "SC-18(2)": [ - "AST-02.7", - "END-10" + "16.3": [ + "TDA-09.5" ], - "CM-13": [ - "AST-02.8" + "16.4": [ + "TDA-09.5" ], - "CM-8(2)": [ - "AST-02.9" + "12.2": [ + "TDA-15" ], - "CM-8(7)": [ - "AST-02.9" + "12.2(a)": [ + "TDA-15" ], - "CM-8(8)": [ - "AST-02.10" + "12.2(b)": [ + "TDA-15" ], - "CM-8(9)": [ - "AST-02.11" + "4.1(d)": [ + "TDA-20" ], - "CM-8(4)": [ - "AST-03.1" + "12.1(c)": [ + "THR-10" + ] + }, + "general-ul-2900-2-2-2016": { + "10.1": [ + "CRY-01", + "TDA-01.1" ], - "SR-4": [ - "AST-03.2" + "8.3": [ + "EMB-14", + "EMB-15", + "NET-14" ], - "PL-2": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "9.2": [ + "EMB-14", + "EMB-15" ], - "SA-5": [ - "AST-04.1", - "TDA-04" + "8.10(b)": [ + "END-09" + ], + "8.5": [ + "IAC-01" ], - "SR-12": [ - "AST-09", - "TDA-11.2" + "8.7": [ + "IAC-01" ], - "SR-9": [ - "AST-15" + "8.6": [ + "IAC-01.2" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "8.9": [ + "IAC-10" ], - "CP-2": [ - "BCD-01", - "BCD-06" + "8.10": [ + "IAC-10.5" ], - "CP-2(1)": [ - "BCD-01.1" + "8.11": [ + "IAC-10.5" ], - "CP-2(7)": [ - "BCD-01.2" + "8.8": [ + "IAC-14" ], - "CP-2(8)": [ - "BCD-02" + "8.2": [ + "NET-14" ], - "CP-3": [ - "BCD-03" + "9.6": [ + "SEA-07.3" ], - "CP-3(1)": [ - "BCD-03.1" + "4.1": [ + "TDA-01.1" ], - "CP-4": [ - "BCD-04", - "BCD-05" + "5.1": [ + "TDA-01.1" ], - "CP-6": [ - "BCD-08" + "6.1": [ + "TDA-01.1" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "7.1": [ + "TDA-01.1" ], - "CP-6(1)": [ - "BCD-08.1" + "8.1": [ + "TDA-01.1" ], - "CP-7": [ - "BCD-09" + "8.4": [ + "TDA-01.1" ], - "CP-8": [ - "BCD-10" + "9.1": [ + "TDA-01.1" ], - "CP-11": [ - "BCD-10" + "9.3": [ + "TDA-01.1" ], - "CP-8(3)": [ - "BCD-10.2" + "9.4": [ + "TDA-01.1" ], - "CP-8(4)": [ - "BCD-10.3" + "9.5": [ + "TDA-01.1" ], - "SC-47": [ - "BCD-10.4" + "11.1": [ + "TDA-01.1" ], - "CP-2(2)": [ - "CAP-03" + "11.2": [ + "TDA-01.1" ], - "CM-3": [ - "CHG-01", - "CHG-02" + "11.4(a)": [ + "TDA-01.1" ], - "CM-3(1)": [ - "CHG-02.1" + "11.4(b)": [ + "TDA-01.1" ], - "CM-3(2)": [ - "CHG-02.2", - "CHG-06" + "11.4(c)": [ + "TDA-01.1" ], - "CM-3(4)": [ - "CHG-02.3" + "12.1": [ + "TDA-01.1" ], - "CM-4": [ - "CHG-03" + "13.1": [ + "TDA-01.1", + "TDA-09" ], - "CM-5": [ - "CHG-04", - "END-03.2" + "14.1": [ + "TDA-01.1", + "TDA-01.3" ], - "CM-5(1)": [ - "CHG-04.1" + "15.1.1": [ + "TDA-01.1" ], - "CM-14": [ - "CHG-04.2" + "15.1.2": [ + "TDA-01.1" ], - "SI-7(15)": [ - "CHG-04.2" + "16.1": [ + "TDA-01.1", + "TDA-09.5", + "VPM-07" ], - "AC-5": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "17.1": [ + "TDA-01.1", + "TDA-09" ], - "CM-5(6)": [ - "CHG-04.5" + "18.1": [ + "TDA-01.1", + "TDA-09.2" ], - "CM-9": [ - "CHG-05", - "CFG-01" + "19.1": [ + "TDA-01.1", + "TDA-09.2" ], - "SA-9(5)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "11.3": [ + "TDA-06" ], - "CA-2": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "11.3(a)": [ + "TDA-06" ], - "RA-3": [ - "CPL-03.2", - "RSK-04" + "11.3(b)": [ + "TDA-06" ], - "CM-9(1)": [ - "CFG-01.1" + "11.3(c)": [ + "TDA-06" ], - "CM-2": [ - "CFG-02", - "CFG-02.1" + "11.3(d)": [ + "TDA-06" ], - "CM-6": [ - "CFG-02", - "CFG-02.7" + "11.5": [ + "TDA-06" ], - "PL-10": [ - "CFG-02" + "11.6": [ + "TDA-06" ], - "SA-8": [ - "CFG-02", - "SEA-01" + "11.7": [ + "TDA-06" ], - "CM-6(1)": [ - "CFG-02.2" + "11.8": [ + "TDA-06" ], - "CM-2(6)": [ - "CFG-02.4" + "15.2.1": [ + "TDA-09.4" ], - "CM-7(6)": [ - "CFG-02.5" + "15.2.2": [ + "TDA-09.4" ], - "CM-7(7)": [ - "CFG-02.5" + "15.2.3": [ + "TDA-09.4" ], - "CM-7(9)": [ - "CFG-02.5" + "15.2.4": [ + "TDA-09.4" ], - "CM-6(2)": [ - "CFG-02.8" + "15.2.5": [ + "TDA-09.4" ], - "CM-7": [ - "CFG-03" + "15.2.6": [ + "TDA-09.4" ], - "CM-7(1)": [ - "CFG-03.1" + "15.3.1": [ + "TDA-09.4" ], - "CM-7(4)": [ - "CFG-03.3" + "15.3.2": [ + "TDA-09.4" ], - "CM-7(5)": [ - "CFG-03.3" + "15.3.3": [ + "TDA-09.4" ], - "CM-10": [ - "CFG-04" + "15.3.4": [ + "TDA-09.4" ], - "CM-8(10)": [ - "CFG-04.1", - "TDA-04", - "TDA-04.1", - "TDA-04.2", - "TDA-05" + "11.4": [ + "VPM-05.8" + ] + }, + "general-un-155-2021": { + "7.2.2.2(a)": [ + "GOV-01" ], - "CM-10(1)": [ - "CFG-04.1" + "7.1.1": [ + "CPL-01" ], - "CM-11": [ - "CFG-05", - "END-03" + "7.2.2.1": [ + "CPL-01.4" ], - "CM-3(8)": [ - "CFG-06" + "7.2.2.2": [ + "CPL-01.4" ], - "PM-31": [ - "MON-01" + "7.2.2.2(g)": [ + "MON-01", + "MON-16", + "THR-01", + "THR-03", + "THR-10", + "VPM-01", + "VPM-04" ], - "SI-4": [ + "7.2.2.2(h)": [ "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "MON-11.3", + "IRO-03", + "THR-03" ], - "AU-2": [ - "MON-01.8", - "MON-02" + "7.2.2.5": [ + "IAO-01", + "PRM-04", + "PRM-05", + "PRM-07", + "RSK-09", + "RSK-09.1", + "TDA-01.1", + "TDA-02", + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.4", + "TPM-05.6", + "TPM-05.7", + "TPM-06", + "TPM-08", + "TPM-09" ], - "SI-4(19)": [ - "MON-01.14" + "7.2.2.2(e)": [ + "IAO-01.1", + "IAO-02" ], - "AU-6": [ - "MON-02", - "MON-02.6" + "7.2.2.2(d)": [ + "IAO-05", + "RSK-06" ], - "AU-6(9)": [ - "MON-02.1" + "7.2.2.1(a)": [ + "PRM-07" ], - "SI-4(17)": [ - "MON-02.3" + "7.2.2.1(b)": [ + "PRM-07" ], - "AU-3": [ - "MON-03" + "7.2.2.1(c)": [ + "PRM-07" ], - "AU-12": [ - "MON-06" + "7.2.2.2(b)": [ + "RSK-01", + "RSK-01.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "THR-09", + "THR-10" ], - "CA-7(3)": [ - "MON-06.2" + "7.2.2.2(c)": [ + "RSK-02", + "RSK-04.2", + "RSK-06" ], - "AU-10": [ - "MON-09" + "7.2.2.2(f)": [ + "RSK-04.2", + "RSK-07" ], - "AU-10(2)": [ - "MON-09.1" + "7.2.2.3": [ + "RSK-06", + "RSK-06.1", + "RSK-06.2", + "RSK-06.3", + "RSK-06.4", + "TDA-09", + "TDA-09.1", + "TDA-15" ], - "AU-13": [ - "MON-11" + "3.1": [ + "TDA-01.1" ], - "AU-14": [ - "MON-12" + "3.2": [ + "TDA-01.1" ], - "AU-16": [ - "MON-14" + "3.2.1": [ + "TDA-01.1" ], - "AU-16(2)": [ - "MON-14.1" + "3.2.2": [ + "TDA-01.1" ], - "SC-8": [ - "CRY-03", - "CRY-04" + "3.2.3": [ + "TDA-01.1" ], - "SC-28": [ - "CRY-05", - "END-02" + "3.3": [ + "TDA-01.1" ], - "AC-18": [ - "CRY-07", - "NET-15" + "3.3(a)": [ + "TDA-01.1" ], - "AC-3(9)": [ - "DCH-03.3" + "3.3(b)": [ + "TDA-01.1" ], - "MP-6": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "4.1": [ + "TDA-01.1" ], - "AC-20": [ - "DCH-13" + "4.1.1": [ + "TDA-01.1" ], - "AC-20(1)": [ - "DCH-13.1" + "4.1.2": [ + "TDA-01.1" ], - "AC-20(3)": [ - "DCH-13.4" + "4.2": [ + "TDA-01.1" ], - "AC-22": [ - "DCH-15" + "4.3": [ + "TDA-01.1" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "4.4": [ + "TDA-01.1" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "5.4": [ + "TDA-01.1" ], - "CM-12": [ - "DCH-24" + "7.3.1": [ + "TDA-01.1" ], - "CM-12(1)": [ - "DCH-24.1" + "7.3.2": [ + "TDA-01.1" ], - "SI-3": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "7.3.3": [ + "TDA-01.1" ], - "SI-2": [ - "END-04.1", - "VPM-01", - "VPM-05" + "7.3.4": [ + "TDA-01.1" ], - "SI-7": [ - "END-06", - "NET-12", - "TDA-18" + "7.3.5": [ + "TDA-01.1" ], - "CM-7(8)": [ - "END-06.7" + "7.3.6": [ + "TDA-01.1" ], - "SI-7(14)": [ - "END-06.7" + "7.3.7": [ + "TDA-01.1" ], - "SC-18": [ - "END-10" + "7.3.7(a)": [ + "TDA-01.1" ], - "SC-27": [ - "END-10" + "7.3.7(b)": [ + "TDA-01.1" ], - "PS-3": [ - "HRS-04" + "7.3.7(c)": [ + "TDA-01.1" ], - "PL-4": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "7.3.8": [ + "TDA-01.1" ], - "PS-6": [ - "HRS-06", - "HRS-06.1" + "7.4.1": [ + "TDA-01.1" ], - "IA-4": [ - "IAC-01.2", - "IAC-09" + "7.4.2": [ + "TDA-01.1" ], - "IA-2": [ - "IAC-02" + "8.1": [ + "TDA-01.1" ], - "IA-8": [ - "IAC-03" + "8.1.1": [ + "TDA-01.1" ], - "IA-3": [ - "IAC-04" + "8.1.2": [ + "TDA-01.1" ], - "IA-9": [ - "IAC-05" + "8.1.3": [ + "TDA-01.1" ], - "AC-6(6)": [ - "IAC-05.2" + "9.1": [ + "TDA-01.1" ], - "AC-2": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "9.1.1": [ + "TDA-01.1" ], - "IA-4(6)": [ - "IAC-09.4" + "9.1.2": [ + "TDA-01.1" ], - "IA-5": [ - "IAC-10", - "IAC-10.8" + "11.1": [ + "TDA-01.1" ], - "IA-5(5)": [ - "IAC-10.8" + "7.2.2.4": [ + "TDA-09.1" ], - "IA-5(9)": [ - "IAC-13.2" + "7.2.2.4(a)": [ + "TDA-09.1" ], - "AC-3": [ - "IAC-20", - "NET-12", - "TDA-18" + "7.2.2.4(b)": [ + "TDA-09.1" + ] + }, + "general-un-ece-wp-29-2020": { + "7.2.2.2(a)": [ + "GOV-01" ], - "AC-3(8)": [ - "IAC-20.6" + "7.1.1": [ + "CPL-01" ], - "AC-24": [ - "IAC-28.1" + "7.2.2.1": [ + "CPL-01.4" ], - "IR-4(6)": [ - "IRO-02.2" + "7.2.2.2": [ + "CPL-01.4" ], - "IR-4(7)": [ - "IRO-02.2" + "7.2.2.2(g)": [ + "MON-01", + "MON-16", + "THR-01", + "THR-03", + "THR-10", + "VPM-01", + "VPM-04" ], - "IR-8": [ - "IRO-04" + "7.2.2.2(h)": [ + "MON-01", + "MON-11.3", + "IRO-03", + "THR-03" ], - "IR-2": [ - "IRO-05" + "7.2.2.2(e)": [ + "IAO-01", + "IAO-01.1", + "IAO-02" ], - "IR-3": [ - "IRO-06" + "7.2.2.5": [ + "IAO-01", + "PRM-04", + "PRM-05", + "PRM-07", + "RSK-09", + "RSK-09.1", + "TDA-01.1", + "TDA-02", + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.4", + "TPM-05.6", + "TPM-05.7", + "TPM-06", + "TPM-08", + "TPM-09" ], - "IR-4(11)": [ - "IRO-07" + "7.2.2.2(d)": [ + "IAO-05", + "RSK-06" ], - "AU-10(3)": [ - "IRO-08" + "7.2.2.1(a)": [ + "PRM-07" ], - "IR-5": [ - "IRO-09" + "7.2.2.1(b)": [ + "PRM-07" ], - "IR-6(3)": [ - "IRO-10.4" + "7.2.2.1(c)": [ + "PRM-07" ], - "IR-7(2)": [ - "IRO-11.2" + "7.2.2.2(b)": [ + "RSK-01", + "RSK-01.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "THR-09", + "THR-10" ], - "IR-9": [ - "IRO-12", - "IRO-12.1" + "7.2.2.2(c)": [ + "RSK-02", + "RSK-04.2", + "RSK-06" ], - "CA-2(2)": [ - "IAO-02.2" + "7.2.2.2(f)": [ + "RSK-04.2", + "RSK-07" ], - "CA-2(3)": [ - "IAO-02.3" + "7.2.2.3": [ + "RSK-06", + "RSK-06.1", + "RSK-06.2", + "RSK-06.3", + "RSK-06.4", + "TDA-09", + "TDA-09.1", + "TDA-15" ], - "CA-5": [ - "IAO-05" + "3.1": [ + "TDA-01.1" ], - "PM-4": [ - "IAO-05", - "VPM-02" + "3.2": [ + "TDA-01.1" ], - "CA-6": [ - "IAO-07" + "3.2.1": [ + "TDA-01.1" ], - "MA-2(2)": [ - "MNT-02.1" + "3.2.2": [ + "TDA-01.1" ], - "MA-6": [ - "MNT-03" + "3.2.3": [ + "TDA-01.1" ], - "MA-3": [ - "MNT-04" + "3.3": [ + "TDA-01.1" ], - "MA-3(1)": [ - "MNT-04.1" + "3.3(a)": [ + "TDA-01.1" ], - "MA-3(2)": [ - "MNT-04.2" + "3.3(b)": [ + "TDA-01.1" ], - "MA-3(3)": [ - "MNT-04.3" + "4.1": [ + "TDA-01.1" ], - "MA-4": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "4.1.1": [ + "TDA-01.1" ], - "MA-4(3)": [ - "MNT-05.6" + "4.1.2": [ + "TDA-01.1" ], - "MA-5": [ - "MNT-06" + "4.2": [ + "TDA-01.1" ], - "MA-5(4)": [ - "MNT-06.1" + "4.3": [ + "TDA-01.1" ], - "SR-11(2)": [ - "MNT-07" + "4.4": [ + "TDA-01.1" ], - "MA-7": [ - "MNT-08" + "5.4": [ + "TDA-01.1" ], - "MA-8": [ - "MNT-11", - "SEA-07" + "7.3.1": [ + "TDA-01.1" ], - "AC-19": [ - "MDM-02" + "7.3.2": [ + "TDA-01.1" ], - "PE-3(5)": [ - "MDM-04" + "7.3.3": [ + "TDA-01.1" ], - "AC-4": [ - "NET-04" + "7.3.4": [ + "TDA-01.1" ], - "AC-4(6)": [ - "NET-04.5" + "7.3.5": [ + "TDA-01.1" ], - "AC-4(17)": [ - "NET-04.12" + "7.3.6": [ + "TDA-01.1" ], - "AC-4(19)": [ - "NET-04.13" + "7.3.7": [ + "TDA-01.1" ], - "CA-3": [ - "NET-05" + "7.3.7(a)": [ + "TDA-01.1" ], - "AC-4(21)": [ - "NET-06" + "7.3.7(b)": [ + "TDA-01.1" ], - "SC-7(13)": [ - "NET-06.1" + "7.3.7(c)": [ + "TDA-01.1" ], - "SC-37(1)": [ - "NET-11" + "7.3.8": [ + "TDA-01.1" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "7.4.1": [ + "TDA-01.1" ], - "AC-17": [ - "NET-14" + "8.1": [ + "TDA-01.1" ], - "AC-17(6)": [ - "NET-14" + "8.1.1": [ + "TDA-01.1" ], - "PE-2": [ - "PES-02" + "8.1.2": [ + "TDA-01.1" ], - "PE-2(1)": [ - "PES-02.1" + "8.1.3": [ + "TDA-01.1" ], - "PE-3": [ - "PES-03" + "9.1": [ + "TDA-01.1" ], - "PE-3(2)": [ - "PES-03" + "9.1.1": [ + "TDA-01.1" ], - "SC-7(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "9.1.2": [ + "TDA-01.1" ], - "PE-3(1)": [ - "PES-03.4" + "11.1": [ + "TDA-01.1" ], - "PE-6": [ - "PES-05" + "7.2.2.4": [ + "TDA-09", + "TDA-09.1" ], - "PE-16": [ - "PES-10" + "7.2.2.4(a)": [ + "TDA-09.1" ], - "PE-17": [ - "PES-11" + "7.2.2.4(b)": [ + "TDA-09.1" + ] + }, + "usa-federal-dow-cert-rmm-1-2": { + "ADM:GG1": [ + "GOV-01" ], - "PE-18": [ - "PES-12" + "ADM:GG2.GP1": [ + "GOV-01" ], - "PE-20": [ - "PES-14" + "ADM:GG3": [ + "GOV-01" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "AM:GG1": [ + "GOV-01" ], - "PM-27": [ - "PRI-14" + "AM:GG2.GP1": [ + "GOV-01" ], - "RA-9": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "AM:GG3": [ + "GOV-01" ], - "PM-11": [ - "PRM-06" + "COMM:GG1": [ + "GOV-01" ], - "SA-3": [ - "PRM-07", - "SEA-07.1" + "COMM:GG2.GP1": [ + "GOV-01" ], - "RA-2": [ - "RSK-02" + "COMM:GG3": [ + "GOV-01" ], - "RA-7": [ - "RSK-06.1" + "COMP:GG2.GP1": [ + "GOV-01" ], - "SA-9(3)": [ - "RSK-09", - "TPM-02", - "TPM-03", - "TPM-05", - "TPM-05.4", - "TPM-05.7" + "COMP:GG3": [ + "GOV-01" ], - "SR-2": [ - "RSK-09", - "TPM-03" + "CTRL:GG1": [ + "GOV-01" ], - "SR-7": [ - "RSK-09", - "OPS-01" + "CTRL:GG1.GP1": [ + "GOV-01", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "RA-3(1)": [ - "RSK-09.1" + "CTRL:GG2": [ + "GOV-01" ], - "PL-8": [ - "SEA-02" + "CTRL:GG2.GP1": [ + "GOV-01" ], - "SC-4": [ - "SEA-05" + "CTRL:GG2.GP2": [ + "GOV-01" ], - "SC-29": [ - "SEA-13" + "CTRL:GG3": [ + "GOV-01" ], - "SC-30": [ - "SEA-14" + "EC:GG1": [ + "GOV-01" ], - "SC-30(4)": [ - "SEA-14" + "EC:GG2.GP1": [ + "GOV-01" ], - "SC-30(5)": [ - "SEA-14" + "EC:GG3": [ + "GOV-01" ], - "SC-30(2)": [ - "SEA-14.1" + "EF:GG1": [ + "GOV-01" ], - "SC-30(3)": [ - "SEA-14.2" + "EF:GG2.GP1": [ + "GOV-01" ], - "SC-36": [ - "SEA-15" + "EF:GG3": [ + "GOV-01" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "EXD:GG1": [ + "GOV-01" ], - "PL-7": [ - "OPS-02" + "EXD:GG2.GP1": [ + "GOV-01" ], - "SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "EXD:GG3": [ + "GOV-01" ], - "SA-4(7)": [ - "TDA-02.2" + "FRM:GG1": [ + "GOV-01" ], - "SR-3(1)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "FRM:GG2.GP1": [ + "GOV-01" ], - "SA-4(5)": [ - "TDA-02.4" + "FRM:GG3": [ + "GOV-01" ], - "PL-8(2)": [ - "TDA-03.1" + "HRM:GG1": [ + "GOV-01" ], - "SA-17": [ - "TDA-05" + "HRM:GG2.GP1": [ + "GOV-01" ], - "SA-15": [ - "TDA-06" + "HRM:GG3": [ + "GOV-01" ], - "SA-15(3)": [ - "TDA-06.1" + "ID:GG1": [ + "GOV-01" ], - "SA-15(4)": [ - "TDA-06.2" + "ID:GG2.GP1": [ + "GOV-01" ], - "SA-15(8)": [ - "TDA-06.2" + "ID:GG3": [ + "GOV-01" ], - "CM-4(1)": [ - "TDA-08" + "IMC:GG1": [ + "GOV-01" ], - "SA-11": [ - "TDA-09" + "IMC:GG2.GP1": [ + "GOV-01" ], - "SA-4(8)": [ - "TDA-09.1" + "IMC:GG3": [ + "GOV-01" ], - "SR-11": [ - "TDA-11" + "KIM:GG1": [ + "GOV-01" ], - "SR-11(3)": [ - "TDA-11" + "KIM:GG2.GP1": [ + "GOV-01" ], - "SR-11(1)": [ - "TDA-11.1" + "KIM:GG3": [ + "GOV-01" ], - "SA-20": [ - "TDA-12" + "MA:GG1": [ + "GOV-01" ], - "SA-21": [ - "TDA-13" + "MA:GG2.GP1": [ + "GOV-01" ], - "SA-21(1)": [ - "TDA-13" + "MA:GG3": [ + "GOV-01" ], - "SA-10": [ - "TDA-14" + "MON:GG1": [ + "GOV-01" ], - "SA-16": [ - "TDA-16" + "MON:GG2.GP1": [ + "GOV-01" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "MON:GG3": [ + "GOV-01" ], - "SR-13": [ - "TPM-01.1" + "OPD:GG1": [ + "GOV-01" ], - "SR-5": [ - "TPM-03.1" + "OPD:GG2.GP1": [ + "GOV-01" ], - "SR-3": [ - "TPM-03.3" + "OPD:GG3": [ + "GOV-01" ], - "SA-9(1)": [ - "TPM-04.1" + "OPF:GG1": [ + "GOV-01" ], - "SA-9(4)": [ - "TPM-04.3" + "OPF:GG2.GP1": [ + "GOV-01" ], - "SR-3(3)": [ - "TPM-05", - "TPM-05.2" + "OPF:GG3": [ + "GOV-01" ], - "SR-8": [ - "TPM-05.1" + "OTA:GG1": [ + "GOV-01" ], - "SR-6": [ - "TPM-08" + "OTA:GG2.GP1": [ + "GOV-01" ], - "PM-12": [ - "THR-04" + "OTA:GG3": [ + "GOV-01" ], - "RA-10": [ - "THR-07" + "PM:GG1": [ + "GOV-01" ], - "SI-20": [ - "THR-08" + "PM:GG2.GP1": [ + "GOV-01" ], - "RA-5": [ - "VPM-06", - "VPM-06.1" + "PM:GG3": [ + "GOV-01" ], - "RA-5(3)": [ - "VPM-06.2" + "RISK:GG1": [ + "GOV-01" ], - "RA-5(6)": [ - "VPM-06.4" - ] - }, - "general-nist-800-171-r2": { - "3.4.1": [ - "AST-01", - "AST-02", - "CFG-02" + "RISK:GG2.GP1": [ + "GOV-01" ], - "3.8.3": [ - "AST-01", - "AST-09", - "DCH-01", - "DCH-08", - "DCH-09" + "RISK:GG3": [ + "GOV-01" ], - "NFO - CM-8(5)": [ - "AST-02.3" + "RRD:GG1": [ + "GOV-01" ], - "NFO - MP-1": [ - "AST-05", - "DCH-01" + "RRD:GG2.GP1": [ + "GOV-01" ], - "3.8.9": [ - "BCD-11", - "BCD-11.4" + "RRD:GG3": [ + "GOV-01" ], - "3.4.3": [ - "CHG-01", - "CHG-02" + "RRM:GG1": [ + "GOV-01" ], - "NFO - CM-3(2)": [ - "CHG-02.2" + "RRM:GG2.GP1": [ + "GOV-01" ], - "3.4.4": [ - "CHG-03" + "RRM:GG3": [ + "GOV-01" ], - "3.4.5": [ - "CHG-04", - "TDA-08" + "RTSE:GG1": [ + "GOV-01" ], - "NFO - CM-9": [ - "CHG-05", - "CFG-01" + "RTSE:GG2.GP1": [ + "GOV-01" ], - "3.1.22": [ - "CLD-01", - "CLD-02", - "CLD-06", - "CLD-10", - "DCH-15", - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "WEB-01", - "WEB-02", - "WEB-04" + "RTSE:GG3": [ + "GOV-01" ], - "NFO–PL-8": [ - "CLD-01", - "CLD-02", - "CLD-03" + "SC:GG1": [ + "GOV-01" ], - "3.13.2": [ - "CLD-03", - "SEA-01", - "SEA-03" + "SC:GG2.GP1": [ + "GOV-01" ], - "NFO - PL-1": [ - "CPL-01", - "PRM-01" + "SC:GG3": [ + "GOV-01" ], - "3.12.1": [ - "CPL-02", - "CPL-02.1", - "CPL-03", - "IAO-02" + "TM:GG1": [ + "GOV-01" ], - "3.12.3": [ - "CPL-02", - "THR-01", - "THR-03" + "TM:GG2": [ + "GOV-01" ], - "NFO - CA-7(1)": [ - "CPL-03.1" + "TM:GG2.GP1": [ + "GOV-01" ], - "NFO - CM-1": [ - "CFG-01" + "TM:GG3": [ + "GOV-01" ], - "3.3.3": [ - "CFG-02", - "CFG-02.1", - "CFG-02.9", - "MON-01", - "MON-01.8", - "MON-01.16", - "MON-02" + "VAR:GG1": [ + "GOV-01" ], - "3.4.2": [ - "CFG-02" + "VAR:GG2.GP1": [ + "GOV-01" ], - "NFO - CM-2(1)": [ - "CFG-02.1" + "VAR:GG3": [ + "GOV-01" ], - "NFO - CM-2(7)": [ - "CFG-02.5" + "GG1": [ + "GOV-01" ], - "3.4.6": [ - "CFG-03" + "GG1.GP1": [ + "GOV-01", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "3.4.7": [ - "CFG-03.1", - "CFG-03.2" + "GG2": [ + "GOV-01" ], - "3.4.8": [ - "CFG-03.3" + "GG2.GP1": [ + "GOV-01" ], - "3.13.7": [ - "CFG-03.4" + "GG2.GP2": [ + "GOV-01" ], - "3.4.9": [ - "CFG-05", - "END-03" + "GG3": [ + "GOV-01" ], - "3.14.6": [ - "MON-01", - "MON-01.3", - "NET-08" + "GG3.GP1": [ + "GOV-01" ], - "NFO - AU-1": [ - "MON-01" + "ADM:GG2.GP10": [ + "GOV-01.1" ], - "NFO - SI-4(5)": [ - "MON-01.4" + "AM:GG2.GP10": [ + "GOV-01.1" ], - "3.14.3": [ - "MON-01.8", - "THR-01", - "THR-03" + "COMM:GG2.GP10": [ + "GOV-01.1" ], - "3.3.1": [ - "MON-02", - "MON-10" + "COMP:GG2.GP10": [ + "GOV-01.1" ], - "3.3.5": [ - "MON-02", - "MON-02.1" + "CTRL:GG2.GP10": [ + "GOV-01.1" ], - "3.3.6": [ - "MON-02", - "MON-06" + "EC:GG2.GP10": [ + "GOV-01.1" ], - "3.3.8": [ - "MON-02", - "MON-03.1", - "MON-08" + "EF:SG3": [ + "GOV-01.1" ], - "3.3.9": [ - "MON-02", - "MON-08.2" + "EF:SG4": [ + "GOV-01.1" ], - "3.14.7": [ - "MON-02.1", - "MON-11.3", - "MON-16", - "IRO-03" + "EF:SG4.SP1": [ + "GOV-01.1" ], - "3.3.2": [ - "MON-03" + "EF:SG4.SP2": [ + "GOV-01.1" ], - "3.3.4": [ - "MON-05" + "EF:GG1.GP1": [ + "GOV-01.1", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "3.3.7": [ - "MON-07.1", - "SEA-20" + "EF:GG2": [ + "GOV-01.1" ], - "3.13.11": [ - "CRY-01" + "EF:GG2.GP2": [ + "GOV-01.1" ], - "3.8.6": [ - "CRY-01.1", - "CRY-05" + "EF:GG2.GP10": [ + "GOV-01.1" ], - "3.13.8": [ - "CRY-01.1", - "CRY-03" + "EXD:GG2.GP10": [ + "GOV-01.1" ], - "NFO - SI-1": [ - "CRY-04" + "FRM:GG2.GP10": [ + "GOV-01.1" ], - "3.13.16": [ - "CRY-05", - "END-02" + "HRM:GG2.GP10": [ + "GOV-01.1" ], - "3.13.10": [ - "CRY-08", - "CRY-09" + "ID:GG2.GP10": [ + "GOV-01.1" ], - "3.8.1": [ - "DCH-01", - "DCH-06" + "IMC:GG2.GP10": [ + "GOV-01.1" ], - "3.10.6": [ - "DCH-01.2", - "NET-14.5", - "PES-11" + "KIM:GG2.GP10": [ + "GOV-01.1" ], - "3.1.3": [ - "DCH-03", - "IAC-08", - "NET-04", - "NET-18" + "MA:GG2.GP10": [ + "GOV-01.1" ], - "3.8.2": [ - "DCH-03" + "MON:GG2.GP10": [ + "GOV-01.1" ], - "3.8.4": [ - "DCH-04" + "OPD:GG2.GP10": [ + "GOV-01.1" ], - "3.8.5": [ - "DCH-07" + "OPF:GG2.GP10": [ + "GOV-01.1" ], - "3.7.3": [ - "DCH-09" + "OTA:GG2.GP10": [ + "GOV-01.1" ], - "3.8.7": [ - "DCH-10" + "PM:GG2.GP10": [ + "GOV-01.1" ], - "3.8.8": [ - "DCH-10.2" + "RISK:GG2.GP10": [ + "GOV-01.1" ], - "3.1.20": [ - "DCH-13", - "DCH-13.1", - "DCH-17" + "RRD:GG2.GP10": [ + "GOV-01.1" ], - "3.1.21": [ - "DCH-13.2" + "RRM:GG2.GP10": [ + "GOV-01.1" ], - "3.14.2": [ - "END-01", - "END-04" + "RTSE:GG2.GP10": [ + "GOV-01.1" ], - "3.14.4": [ - "END-04.1" + "SC:GG2.GP10": [ + "GOV-01.1" ], - "3.14.5": [ - "END-04.7" + "TM:GG2.GP10": [ + "GOV-01.1" ], - "3.13.13": [ - "END-10" + "VAR:GG2.GP10": [ + "GOV-01.1" ], - "3.13.12": [ - "END-14" + "GG2.GP10": [ + "GOV-01.1" ], - "NFO - PS-1": [ - "HRS-01" + "EF:SG3.SP1": [ + "GOV-01.3" ], - "3.9.2": [ - "HRS-01.1", - "HRS-08", - "HRS-09" + "EF:SG3.SP3": [ + "GOV-01.3" ], - "3.9.1": [ - "HRS-04", - "HRS-04.1" + "EF:SG4.SP3": [ + "GOV-01.3" ], - "3.2.1": [ - "HRS-04.2", - "SAT-02" + "ADM:SG1.SP3": [ + "GOV-04.1", + "AST-03", + "AST-03.1" ], - "3.2.2": [ - "HRS-04.2", - "SAT-03" + "MA:SG1": [ + "GOV-05" ], - "NFO - PL-4": [ - "HRS-05", - "HRS-05.1" + "MA:SG1.SP1": [ + "GOV-05" ], - "NFO - PL-4(1)": [ - "HRS-05.2" + "MA:SG1.SP2": [ + "GOV-05" ], - "NFO - PS-6": [ - "HRS-06" + "MA:SG1.SP3": [ + "GOV-05" ], - "NFO - PS-8": [ - "HRS-07" + "MA:SG1.SP4": [ + "GOV-05" ], - "NFO - PS-7": [ - "HRS-10" + "MA:SG2": [ + "GOV-05" ], - "3.1.4": [ - "HRS-11" + "MA:SG2.SP1": [ + "GOV-05" ], - "3.1.1": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-15.1", - "IAC-20", - "TPM-01", - "TPM-05", - "TPM-05.2" + "MA:SG2.SP2": [ + "GOV-05" ], - "NFO - AC-1": [ - "IAC-01" + "MA:SG2.SP3": [ + "GOV-05" ], - "NFO - IA-1": [ - "IAC-01" + "MA:SG2.SP4": [ + "GOV-05" ], - "3.5.1": [ - "IAC-02", - "IAC-04", - "IAC-15.1" + "MA:GG1.GP1": [ + "GOV-05", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "3.5.2": [ - "IAC-02", - "IAC-04", - "IAC-15.1" + "MA:GG2": [ + "GOV-05" ], - "3.5.4": [ - "IAC-02.2" + "MA:GG2.GP2": [ + "GOV-05" ], - "3.5.3": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "CTRL:SG1": [ + "GOV-09" ], - "3.7.5": [ - "IAC-06", - "MNT-05", - "MNT-05.4" + "CTRL:SG1.SP1": [ + "GOV-09" ], - "3.1.2": [ - "IAC-08", - "IAC-15" + "EF:SG3.SP2": [ + "GOV-14" ], - "3.5.5": [ - "IAC-09" + "CTRL:SG2.SP1": [ + "GOV-15.1" ], - "3.5.8": [ - "IAC-10" + "EC:SG2": [ + "GOV-15.1" ], - "3.5.9": [ - "IAC-10" + "EC:SG2.SP2": [ + "GOV-15.1" ], - "3.5.7": [ - "IAC-10.1" + "KIM:SG2": [ + "GOV-15.1" ], - "3.5.10": [ - "IAC-10.5" + "KIM:SG2.SP2": [ + "GOV-15.1" ], - "3.5.11": [ - "IAC-11" + "TM:SG2": [ + "GOV-15.1" ], - "3.5.6": [ - "IAC-15.3" + "TM:SG2.SP2": [ + "GOV-15.1" ], - "3.1.5": [ - "IAC-16", - "IAC-16.1", - "IAC-21", - "IAC-21.1", - "IAC-21.3" + "CTRL:SG2": [ + "GOV-15.2" ], - "3.1.6": [ - "IAC-21.2" + "CTRL:SG3": [ + "GOV-15.3" ], - "3.1.7": [ - "IAC-21.4", - "IAC-21.5" + "CTRL:SG3.SP1": [ + "GOV-15.3" ], - "3.1.8": [ - "IAC-22" + "CTRL:SG4": [ + "GOV-15.3" ], - "3.1.10": [ - "IAC-24", - "IAC-24.1" + "CTRL:SG4.SP1": [ + "GOV-15.3" ], - "3.1.11": [ - "IAC-25" + "ADM:GG2.GP9": [ + "GOV-19.2" ], - "NFO - IR-1": [ - "IRO-01", - "IRO-04.2", - "IRO-13" + "AM:GG2.GP9": [ + "GOV-19.2" ], - "3.6.1": [ - "IRO-02", - "IRO-05" + "COMM:GG2.GP9": [ + "GOV-19.2" ], - "3.6.2": [ - "IRO-02" + "COMP:GG2.GP9": [ + "GOV-19.2" ], - "NFO - IR-8": [ - "IRO-04" + "CTRL:GG2.GP9": [ + "GOV-19.2" ], - "3.6.3": [ - "IRO-06" + "EC:GG2.GP9": [ + "GOV-19.2" ], - "NFO - CA-1": [ - "IAO-01" + "EF:GG2.GP9": [ + "GOV-19.2" ], - "NFO - CA-2(1)": [ - "IAO-02.1" + "EXD:GG2.GP9": [ + "GOV-19.2" ], - "3.12.4": [ - "IAO-03", - "IAO-03.2" + "FRM:GG2.GP9": [ + "GOV-19.2" ], - "NFO - PL-2(3)": [ - "IAO-03.1" + "HRM:GG2.GP9": [ + "GOV-19.2" ], - "3.12.2": [ - "IAO-05" + "ID:GG2.GP9": [ + "GOV-19.2" ], - "NFO - MA-1": [ - "MNT-01" + "IMC:GG2.GP9": [ + "GOV-19.2" ], - "3.7.1": [ - "MNT-02" + "KIM:GG2.GP9": [ + "GOV-19.2" ], - "3.7.2": [ - "MNT-04" + "MA:GG2.GP9": [ + "GOV-19.2" ], - "3.7.4": [ - "MNT-04.2" + "MON:GG2.GP9": [ + "GOV-19.2" ], - "NFO - MA-4(2)": [ - "MNT-05.2" + "OPD:GG2.GP9": [ + "GOV-19.2" ], - "3.7.6": [ - "MNT-06", - "MNT-06.1", - "MNT-06.2" + "OPF:GG2.GP9": [ + "GOV-19.2" ], - "3.1.18": [ - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07" + "OTA:GG2.GP9": [ + "GOV-19.2" ], - "3.1.19": [ - "MDM-03" + "PM:GG2.GP9": [ + "GOV-19.2" ], - "3.13.1": [ - "NET-01", - "NET-02.2", - "NET-03" + "RISK:GG2.GP9": [ + "GOV-19.2" ], - "NFO - SC-1": [ - "NET-01" + "RRD:GG2.GP9": [ + "GOV-19.2" ], - "NFO - SC-7(3)": [ - "NET-03.1" + "RRM:GG2.GP9": [ + "GOV-19.2" ], - "NFO - SC-7(4)": [ - "NET-03.2" + "RTSE:GG2.GP9": [ + "GOV-19.2" ], - "3.13.6": [ - "NET-04.1" + "SC:GG2.GP9": [ + "GOV-19.2" ], - "NFO - CA-3(5)": [ - "NET-04.1" + "TM:GG2.GP9": [ + "GOV-19.2" ], - "NFO - CA-3": [ - "NET-05" + "VAR:GG2.GP9": [ + "GOV-19.2" ], - "NFO - CA-9": [ - "NET-05.2" + "GG2.GP9": [ + "GOV-19.2" ], - "3.13.5": [ - "NET-06" + "ADM:SG1": [ + "AST-01" ], - "3.13.9": [ - "NET-07" + "ADM:SG1.SP2": [ + "AST-01", + "SEA-02.1" ], - "3.13.15": [ - "NET-09" + "ADM:GG1.GP1": [ + "AST-01", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "NFO - SC-20": [ - "NET-10" + "ADM:GG2": [ + "AST-01" ], - "NFO - SC-22": [ - "NET-10.1" + "ADM:GG2.GP2": [ + "AST-01" ], - "NFO - SC-21": [ - "NET-10.2" + "KIM:SG1": [ + "AST-01" ], - "3.13.14": [ - "NET-13" + "KIM:SG1.SP1": [ + "AST-01" ], - "3.1.12": [ - "NET-14", - "NET-14.1", - "NET-14.5" + "KIM:SG1.SP2": [ + "AST-01" ], - "3.1.13": [ - "NET-14.2" + "TM:SG4.SP4": [ + "AST-01" ], - "3.1.14": [ - "NET-14.3" + "ADM:SG2": [ + "AST-01.1" ], - "3.1.15": [ - "NET-14.4" + "ADM:SG2.SP1": [ + "AST-01.1", + "PRI-05.5", + "PRM-06", + "RSK-02", + "TPM-04" ], - "3.1.16": [ - "NET-15" + "ADM:SG2.SP2": [ + "AST-01.1", + "BCD-02" ], - "3.1.17": [ - "NET-15.1" + "ADM:GG2.GP7": [ + "AST-01.2" ], - "3.10.2": [ - "PES-01", - "PES-05", - "PES-05.1", - "PES-05.2" + "AM:GG2.GP7": [ + "AST-01.2" ], - "NFO - PE-1": [ - "PES-01" + "COMM:GG2.GP7": [ + "AST-01.2" ], - "3.10.1": [ - "PES-02", - "PES-02.1", - "PES-03.4", - "PES-12", - "PES-12.1", - "PES-12.2" + "COMP:GG2.GP7": [ + "AST-01.2" ], - "3.10.3": [ - "PES-03", - "PES-06", - "PES-06.1", - "PES-06.3" + "CTRL:GG2.GP7": [ + "AST-01.2" ], - "3.10.5": [ - "PES-03", - "PES-04" + "EC:GG2.GP7": [ + "AST-01.2" ], - "3.10.4": [ - "PES-03.3" + "EF:GG2.GP7": [ + "AST-01.2" ], - "NFO - PE-8": [ - "PES-03.3" + "EXD:GG2.GP7": [ + "AST-01.2" ], - "NFO - PE-6(1)": [ - "PES-05.1" + "FRM:GG2.GP7": [ + "AST-01.2" ], - "NFO - PE-16": [ - "PES-10" + "HRM:GG2.GP7": [ + "AST-01.2" ], - "NFO - SA-2": [ - "PRM-03" + "ID:GG2.GP7": [ + "AST-01.2" ], - "NFO - SA-3": [ - "PRM-07", - "SEA-07", - "SEA-07.1" + "IMC:GG2.GP7": [ + "AST-01.2" ], - "NFO - RA-1": [ - "RSK-01" + "KIM:GG2.GP7": [ + "AST-01.2" ], - "3.11.1": [ - "RSK-04" + "MA:GG2.GP7": [ + "AST-01.2" ], - "3.11.3": [ - "RSK-06", - "VPM-04", - "VPM-05" + "MON:GG2.GP7": [ + "AST-01.2" ], - "NFO - PL-8": [ - "SEA-02" + "OPD:GG2.GP7": [ + "AST-01.2" ], - "3.13.3": [ - "SEA-03.2" + "OPF:GG2.GP7": [ + "AST-01.2" ], - "NFO - SC-39": [ - "SEA-04" + "OTA:GG2.GP7": [ + "AST-01.2" ], - "3.13.4": [ - "SEA-05" + "PM:GG2.GP7": [ + "AST-01.2" ], - "NFO - SI-16": [ - "SEA-10" + "RISK:GG2.GP7": [ + "AST-01.2" ], - "3.1.9": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "RRD:GG2.GP7": [ + "AST-01.2" ], - "NFO - AT-1": [ - "SAT-01" + "RRM:GG2.GP7": [ + "AST-01.2" ], - "3.2.3": [ - "SAT-03.6", - "THR-05" + "RTSE:GG2.GP7": [ + "AST-01.2" ], - "NFO - AT-4": [ - "SAT-04" + "SC:GG2.GP7": [ + "AST-01.2" ], - "NFO - SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-05" + "TM:GG2.GP7": [ + "AST-01.2" ], - "NFO - SA-4(9)": [ - "TDA-02.1" + "VAR:GG2.GP7": [ + "AST-01.2" ], - "NFO - SA-4(10)": [ - "TDA-02.2" + "GG2.GP7": [ + "AST-01.2" ], - "NFO - SA-5": [ - "TDA-04" + "ADM:SG1.SP1": [ + "AST-02" ], - "NFO - SA-4(1)": [ - "TDA-04.1" + "ADM:SG3.SP1": [ + "AST-02.9", + "CHG-01" ], - "NFO - SA-4(2)": [ - "TDA-04.1" + "ADM:SG3.SP2": [ + "AST-02.9", + "CHG-02" ], - "NFO - SA-1": [ - "TDA-06" + "TM:SG1": [ + "AST-31" ], - "NFO - SA-11": [ - "TDA-09" + "TM:SG1.SP1": [ + "AST-31" ], - "NFO - SA-10": [ - "TDA-14" + "COMM:SG1": [ + "BCD-01" ], - "NFO - SA-9": [ - "TPM-04" + "COMM:SG1.SP1": [ + "BCD-01" ], - "NFO - SA-9(2)": [ - "TPM-04.2" + "COMM:SG1.SP2": [ + "BCD-01" ], - "3.14.1": [ - "VPM-01", - "VPM-02", - "VPM-05" + "COMM:SG1.SP3": [ + "BCD-01" ], - "3.11.2": [ - "VPM-06", - "VPM-06.3" + "COMM:SG2": [ + "BCD-01" ], - "NFO - RA-5(1)": [ - "VPM-06.1" + "COMM:SG2.SP1": [ + "BCD-01" ], - "NFO - RA-5(2)": [ - "VPM-06.1" - ] - }, - "general-nist-800-171-r3": { - "03.15.01.a": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "OPS-01", - "OPS-01.1" + "COMM:SG2.SP2": [ + "BCD-01" ], - "03.12.03": [ - "GOV-01.1", - "GOV-01.2", - "GOV-05", - "CPL-02", - "CPL-03", - "CPL-03.2", - "MON-01", - "TDA-01", - "TDA-01.1", - "TDA-09", - "TDA-09.1" + "COMM:SG2.SP3": [ + "BCD-01" ], - "03.15.01.b": [ - "GOV-03", - "OPS-01", - "OPS-03" + "COMM:SG3": [ + "BCD-01" ], - "03.15.03.d": [ - "GOV-03", - "HRS-01", - "HRS-05.1", - "HRS-05.7" + "COMM:SG3.SP1": [ + "BCD-01" ], - "03.17.01.a": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "RSK-01", - "RSK-09", - "TPM-03", - "TPM-03.1", - "TPM-05.7" + "COMM:SG3.SP2": [ + "BCD-01" ], - "03.01.03": [ - "AST-01", - "AST-01.1", - "AST-04", - "AST-04.3", - "AST-31", - "DCH-01.4", - "DCH-03", - "DCH-14.3", - "IAC-20", - "IAC-20.1", - "NET-04", - "NET-05", - "NET-05.2" + "COMM:GG1.GP1": [ + "BCD-01", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "03.01.18.a": [ - "AST-01", - "AST-12", - "AST-13", - "AST-14", - "AST-16", - "CFG-02", - "HRS-05.1", - "HRS-05.3", - "HRS-05.5", - "HRS-06", - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07", - "NET-01", - "SEA-01", - "SEA-02" + "COMM:GG2": [ + "BCD-01" ], - "03.04.11.a": [ - "AST-01", - "AST-02", - "AST-02.8", - "AST-04", - "AST-04.1", - "AST-04.2", - "CPL-01", - "CPL-01.2", - "DCH-02", - "DCH-06.2", - "DCH-19" + "COMM:GG2.GP2": [ + "BCD-01" ], - "03.07.04.a": [ - "AST-01", - "AST-05", - "MNT-01", - "MNT-02", - "MNT-03", - "MNT-03.1", - "MNT-04", - "MNT-09" + "EC:SG1": [ + "BCD-01" ], - "03.04.08.a": [ - "AST-02", - "AST-02.9", - "CFG-02.9", - "CFG-03", - "CFG-03.3" + "EC:SG4.SP1": [ + "BCD-01", + "CAP-01" ], - "03.04.08.c": [ - "AST-02", - "CPL-03.2", - "CFG-03.1" + "EC:SG4.SP3": [ + "BCD-01" ], - "03.04.10.a": [ - "AST-02", - "AST-02.1", - "AST-02.9" + "EC:SG4.SP4": [ + "BCD-01" ], - "03.04.10.b": [ - "AST-02", - "AST-02.1", - "AST-02.9" + "SC:SG3.SP2": [ + "BCD-01" ], - "03.04.10.c": [ - "AST-02.1", - "AST-02.9" + "SC:SG3.SP3": [ + "BCD-01" ], - "03.04.02.b": [ - "AST-02.4", - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-04", - "CFG-02.1", - "CFG-02.2", - "CFG-02.7", - "CFG-02.9", - "CFG-06" + "SC:SG3.SP4": [ + "BCD-01" ], - "03.04.06.a": [ - "AST-02.4", - "CFG-02", - "CFG-02.5", - "CFG-02.9", - "CFG-03" + "SC:SG3.SP5": [ + "BCD-01" ], - "03.04.11.b": [ - "AST-02.8", - "AST-04", - "AST-04.1", - "AST-04.2", - "CHG-02.2", - "CHG-03", - "CHG-05", - "DCH-06.2", - "DCH-19", - "IAO-03", - "IAO-05" + "SC:SG4": [ + "BCD-01" ], - "03.09.02.a.03": [ - "AST-03", - "AST-03.1", - "AST-10", - "HRS-09", - "HRS-09.1" + "SC:SG4.SP1": [ + "BCD-01" ], - "03.15.02.a.04": [ - "AST-04.2", - "CPL-01.2", - "IAO-03" + "SC:SG4.SP2": [ + "BCD-01" ], - "03.07.04.c": [ - "AST-09", - "DCH-09", - "MNT-04.3" + "SC:SG5": [ + "BCD-01" ], - "03.08.03": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-21" + "SC:SG5.SP1": [ + "BCD-01" ], - "03.11.01.a": [ - "AST-17", - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-02.1", - "RSK-03", - "RSK-04", - "RSK-05", - "RSK-09", - "RSK-09.1", - "TPM-02", - "TPM-03", - "TPM-04.1" + "SC:SG5.SP2": [ + "BCD-01" ], - "03.16.01": [ - "AST-17", - "PRM-01", - "PRM-05", - "SEA-01", - "SEA-02", - "TDA-01", - "TDA-02", - "TDA-02.3", - "TDA-02.4", - "TDA-03", - "TDA-05", - "TDA-06", - "TPM-01", - "TPM-10" + "SC:SG5.SP3": [ + "BCD-01" ], - "03.04.12.a": [ - "AST-24", - "CFG-02.5", - "CFG-02.9" + "SC:SG5.SP4": [ + "BCD-01" ], - "03.04.12.b": [ - "AST-24", - "AST-25", - "MDM-04" + "SC:SG6": [ + "BCD-01" ], - "03.01.12.a": [ - "AST-27", - "CFG-02", - "HRS-05.1", - "HRS-05.3", - "IAC-08", - "NET-01", - "NET-03", - "NET-14", - "NET-14.2", - "NET-14.5", - "SEA-01", - "SEA-02" + "SC:SG6.SP1": [ + "BCD-01" ], - "03.01.12.c": [ - "AST-27", - "NET-14", - "NET-14.3", - "NET-14.5" + "SC:SG6.SP2": [ + "BCD-01" ], - "03.08.09.a": [ - "BCD-11", - "BCD-11.4" + "SC:SG7": [ + "BCD-01" ], - "03.08.09.b": [ - "BCD-11.4" + "SC:SG7.SP1": [ + "BCD-01" ], - "03.04.03.a": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CFG-06" + "SC:SG7.SP2": [ + "BCD-01" ], - "03.04.03.b": [ - "CHG-02", - "CHG-02.2", - "CHG-03" + "SC:GG1.GP1": [ + "BCD-01", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "03.04.03.c": [ - "CHG-02", - "CHG-02.2", - "MNT-01", - "MNT-02" + "SC:GG2": [ + "BCD-01" ], - "03.04.04.a": [ - "CHG-02.2", - "CHG-02.3", - "CHG-03" + "SC:GG2.GP2": [ + "BCD-01" ], - "03.04.05": [ - "CHG-04", - "CHG-04.4", - "IAC-08", - "IAC-21" + "TM:SG5": [ + "BCD-01" ], - "03.04.04.b": [ - "CHG-06" + "TM:SG5.SP1": [ + "BCD-01" ], - "03.12.01": [ - "CPL-01", - "CPL-02", - "CPL-02.1", - "CPL-03", - "IAO-01", - "IAO-01.1", - "IAO-02", - "TDA-01", - "TDA-09" + "TM:SG5.SP2": [ + "BCD-01" ], - "03.12.02.a.01": [ - "CPL-01.1", - "IAO-05", - "RSK-04.1" + "TM:SG5.SP3": [ + "BCD-01" ], - "03.04.01.a": [ - "CFG-01", - "CFG-02", - "CFG-02.5", - "CFG-02.7", - "CFG-02.9" + "TM:SG5.SP4": [ + "BCD-01" ], - "03.01.01.h": [ - "CFG-02", - "HRS-05", - "HRS-05.3", - "IAC-25" + "TM:GG1.GP1": [ + "BCD-01", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "03.01.08.a": [ - "CFG-02", - "IAC-22" + "TM:GG2.GP2": [ + "BCD-01" ], - "03.01.08.b": [ - "CFG-02", - "IAC-22" + "EC:SG1.SP1": [ + "BCD-01.7" ], - "03.01.09": [ - "CFG-02", - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "PM:SG3.SP3": [ + "BCD-01.7" ], - "03.01.10.a": [ - "CFG-02", - "IAC-24" + "PM:SG3.SP4": [ + "BCD-01.7" ], - "03.01.10.b": [ - "CFG-02", - "IAC-24" + "PM:SG3.SP5": [ + "BCD-01.7" ], - "03.01.10.c": [ - "CFG-02", - "IAC-24.1" + "EC:SG1.SP2": [ + "BCD-02" ], - "03.01.11": [ - "CFG-02", - "IAC-25" + "TM:SG1.SP2": [ + "BCD-02" ], - "03.01.16.a": [ - "CFG-02", - "CRY-07", - "NET-01", - "NET-02.2", - "NET-15", - "NET-15.1", - "NET-15.3", - "SEA-01", - "SEA-02" + "TM:SG4": [ + "CHG-01" ], - "03.04.02.a": [ - "CFG-02", - "CFG-02.5", - "CFG-02.9", - "CFG-03", - "CFG-06" + "TM:SG4.SP1": [ + "CHG-01" ], - "03.04.06.b": [ - "CFG-02", - "CFG-02.5", - "CFG-03" + "TM:SG4.SP2": [ + "CHG-01" ], - "03.04.06.d": [ - "CFG-02", - "CFG-02.5", - "CFG-03" + "TM:SG4.SP3": [ + "CHG-01" ], - "03.05.07.d": [ - "CFG-02", - "IAC-01.2", - "IAC-10", - "IAC-10.5", - "IAC-10.6", - "IAC-10.11", - "IAC-15.1" + "COMP:SG1": [ + "CPL-01" ], - "03.05.07.e": [ - "CFG-02", - "IAC-01.2", - "IAC-10", - "IAC-10.1", - "IAC-10.8", - "IAC-15.1" + "COMP:SG1.SP1": [ + "CPL-01" ], - "03.05.07.f": [ - "CFG-02", - "IAC-10", - "IAC-10.1", - "IAC-10.11", - "IAC-15.1" + "COMP:SG1.SP2": [ + "CPL-01" ], - "03.05.12.d": [ - "CFG-02", - "IAC-01.2", - "IAC-10", - "IAC-10.1", - "IAC-10.8", - "IAC-15.1" + "COMP:SG1.SP3": [ + "CPL-01" ], - "03.08.07.a": [ - "CFG-02", - "DCH-10", - "DCH-12" + "COMP:SG2": [ + "CPL-01" ], - "03.13.12.b": [ - "CFG-02", - "END-14.6" + "COMP:SG2.SP1": [ + "CPL-01" ], - "03.04.01.b": [ - "CFG-02.1" + "COMP:SG2.SP2": [ + "CPL-01" ], - "03.04.03.d": [ - "CFG-02.2" + "COMP:SG2.SP3": [ + "CPL-01" ], - "03.03.02.b": [ - "CFG-02.9", - "MON-03" + "COMP:GG1": [ + "CPL-01" ], - "03.13.11": [ - "CFG-02.9", - "CRY-01", - "CRY-01.5" + "COMP:GG1.GP1": [ + "CPL-01", + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "03.04.06.c": [ - "CFG-03.1" + "COMP:GG2": [ + "CPL-01" ], - "03.04.08.b": [ - "CFG-03.2", - "CFG-03.3" + "COMP:GG2.GP2": [ + "CPL-01" ], - "03.13.13.a": [ - "CFG-03.3", - "END-10" + "COMP:SG3.SP3": [ + "CPL-01.1" ], - "03.13.13.b": [ - "CFG-03.3", - "CFG-04", - "CFG-04.1", - "CFG-05", - "END-10" + "COMP:SG3.SP1": [ + "CPL-01.3" ], - "03.01.02": [ - "CFG-08", - "DCH-01.2", - "DCH-01.4", - "HRS-02", - "HRS-02.1", - "IAC-08", - "IAC-15", - "IAC-20", - "IAC-20.1" + "COMP:SG3.SP2": [ + "CPL-01.3" ], - "03.03.01.a": [ - "MON-01", - "MON-01.4", - "MON-02.7", - "MON-03", - "MON-03.2" + "COMP:SG3": [ + "CPL-01.5" ], - "03.14.06.a": [ - "MON-01" + "ADM:GG2.GP8": [ + "CPL-02" ], - "03.13.01.a": [ - "MON-01.1", - "MON-01.3", - "NET-01", - "NET-03", - "NET-04", - "NET-04.1", - "NET-08" + "AM:GG2.GP8": [ + "CPL-02" ], - "03.14.06.c": [ - "MON-01.3", - "MON-01.4", - "MON-11.3", - "MON-16", - "END-07", - "NET-08", - "NET-18" + "COMM:GG2.GP8": [ + "CPL-02" ], - "03.03.03.a": [ - "MON-01.4" + "COMP:SG4": [ + "CPL-02" ], - "03.14.06.a.01": [ - "MON-01.4", - "MON-11.3", - "MON-16", - "END-07" + "COMP:GG2.GP8": [ + "CPL-02" ], - "03.14.06.b": [ - "MON-01.4", - "MON-11.3", - "MON-16", - "END-07" + "CTRL:GG2.GP8": [ + "CPL-02" ], - "03.03.01.b": [ - "MON-01.8", - "MON-02.2" + "EC:GG2.GP8": [ + "CPL-02" ], - "03.03.05.a": [ - "MON-01.8", - "MON-02", - "MON-02.1", - "MON-02.2", - "MON-16" + "EF:GG2.GP8": [ + "CPL-02" ], - "03.03.04.a": [ - "MON-01.12" + "EXD:GG2.GP8": [ + "CPL-02" ], - "03.03.05.b": [ - "MON-01.12", - "MON-06" + "FRM:GG2.GP8": [ + "CPL-02" ], - "03.01.07.b": [ - "MON-01.15", - "MON-03.3", - "IAC-09.5", - "IAC-16", - "IAC-21.4" + "HRM:GG2.GP8": [ + "CPL-02" ], - "03.03.05.c": [ - "MON-02", - "MON-02.1", - "MON-02.2", - "MON-02.3" + "ID:GG2.GP8": [ + "CPL-02" ], - "03.03.02.a": [ - "MON-03" + "IMC:GG2.GP8": [ + "CPL-02" ], - "03.03.02.a.01": [ - "MON-03" + "KIM:GG2.GP8": [ + "CPL-02" ], - "03.03.02.a.02": [ - "MON-03", - "MON-07" + "MA:GG2.GP8": [ + "CPL-02" ], - "03.03.02.a.03": [ - "MON-03" + "MON:GG2.GP8": [ + "CPL-02" ], - "03.03.02.a.04": [ - "MON-03" + "OPD:GG2.GP8": [ + "CPL-02" ], - "03.03.02.a.05": [ - "MON-03" + "OPF:GG2.GP8": [ + "CPL-02" ], - "03.03.02.a.06": [ - "MON-03" + "OTA:GG2.GP8": [ + "CPL-02" ], - "03.03.04.b": [ - "MON-05", - "IRO-02" + "PM:GG2.GP8": [ + "CPL-02" ], - "03.03.06.a": [ - "MON-06" + "RISK:GG2.GP8": [ + "CPL-02" ], - "03.03.07.a": [ - "MON-07" + "RRD:GG2.GP8": [ + "CPL-02" ], - "03.03.07.b": [ - "MON-07.1" + "RRM:GG2.GP8": [ + "CPL-02" ], - "03.03.03.b": [ - "MON-08", - "MON-10" + "RTSE:GG2.GP8": [ + "CPL-02" ], - "03.03.06.b": [ - "MON-08" + "SC:GG2.GP8": [ + "CPL-02" ], - "03.03.08.a": [ - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-08.3", - "IAC-21" + "TM:GG2.GP8": [ + "CPL-02" ], - "03.03.08.b": [ - "MON-08.2", - "IAC-08", - "IAC-21" + "VAR:GG2.GP8": [ + "CPL-02" ], - "03.01.22.b": [ - "MON-11", - "DCH-15", - "WEB-14" + "GG2.GP8": [ + "CPL-02" ], - "03.14.06.a.02": [ - "MON-11.3", - "MON-16", - "END-07" + "COMP:SG4.SP1": [ + "CPL-03.1" ], - "03.01.01.e": [ - "MON-16", - "IAC-15", - "IAC-15.7" + "ADM:GG3.GP2": [ + "CPL-13" ], - "03.13.08": [ - "CRY-01", - "CRY-01.1", - "CRY-03", - "CRY-05", - "CRY-05.1" + "AM:GG1.GP1": [ + "CPL-13", + "IAC-01", + "PRM-06", + "OPS-01.1" ], - "03.13.10": [ - "CRY-08", - "CRY-09", - "CRY-09.3", - "CRY-09.4" + "AM:GG3.GP2": [ + "CPL-13" ], - "03.01.01.d.01": [ - "DCH-01", - "DCH-01.2", - "HRS-02", - "IAC-15", - "IAC-20", - "IAC-20.1", - "IAC-21" + "COMM:GG3.GP2": [ + "CPL-13" ], - "03.01.01.d.02": [ - "DCH-01", - "DCH-01.2", - "HRS-02", - "IAC-15", - "IAC-20", - "IAC-20.1", - "IAC-21" + "COMP:GG3.GP2": [ + "CPL-13" ], - "03.08.01": [ - "DCH-01", - "DCH-01.1", - "DCH-01.2", - "DCH-01.4", - "DCH-02", - "DCH-03", - "DCH-06", - "DCH-06.1", - "DCH-06.4", + "CTRL:GG3.GP2": [ + "CPL-13" + ], + "EC:GG1.GP1": [ + "CPL-13", "PES-01", - "PES-02", - "PES-02.1", - "PES-04", - "PES-04.1" + "PRM-06", + "OPS-01.1" ], - "03.08.05.a": [ - "DCH-01.1", - "DCH-01.2", - "DCH-07", - "DCH-07.1", - "DCH-07.2" + "EC:GG3.GP2": [ + "CPL-13" ], - "03.01.20.a": [ - "DCH-01.2", - "DCH-13", - "DCH-13.1", - "DCH-13.2", - "DCH-13.4", - "DCH-17", - "TPM-01", - "TPM-05.8" + "EF:GG3.GP2": [ + "CPL-13" ], - "03.01.20.b": [ - "DCH-01.2", - "DCH-13", - "DCH-13.1", - "DCH-13.3", - "DCH-14", - "DCH-14.2", - "TPM-01", - "TPM-05", - "TPM-05.8" + "EXD:GG1.GP1": [ + "CPL-13", + "PRM-06", + "OPS-01.1", + "TPM-01" ], - "03.01.20.c.01": [ - "DCH-01.2", - "DCH-13", - "DCH-13.1", - "DCH-13.3", - "DCH-13.4", - "TPM-01", - "TPM-05", - "TPM-05.6", - "TPM-05.8" + "EXD:GG3.GP2": [ + "CPL-13" ], - "03.01.20.d": [ - "DCH-01.2", - "DCH-13", - "DCH-13.1", - "DCH-13.2", - "DCH-13.4", - "MDM-01", - "MDM-07" + "FRM:GG1.GP1": [ + "CPL-13", + "PRM-01", + "PRM-06", + "OPS-01.1" ], - "03.06.05.d": [ - "DCH-01.2", - "HRS-03", - "IAC-08", - "IAC-20.1" + "FRM:GG3.GP2": [ + "CPL-13" ], - "03.08.02": [ - "DCH-01.2", - "DCH-01.4", - "DCH-03", - "HRS-03", - "PES-01", - "PES-02", - "PES-02.1", - "PES-04", - "PES-04.1" + "HRM:GG1.GP1": [ + "CPL-13", + "HRS-01", + "PRM-06", + "OPS-01.1" ], - "03.17.01.c": [ - "DCH-01.2", - "DCH-01.4", - "DCH-03.1" + "HRM:GG3.GP2": [ + "CPL-13" ], - "03.08.05.c": [ - "DCH-01.3" + "ID:GG1.GP1": [ + "CPL-13", + "IAC-01", + "PRM-06", + "OPS-01.1" ], - "03.01.04.b": [ - "DCH-01.4", - "IAC-20", - "IAC-20.1", - "IAC-21" + "ID:GG3.GP2": [ + "CPL-13" ], - "03.10.01.a": [ - "DCH-01.4", - "IAC-20.1", - "PES-01", - "PES-02" + "IMC:GG1.GP1": [ + "CPL-13", + "IRO-01", + "PRM-06", + "OPS-01.1" ], - "03.15.02.c": [ - "DCH-01.4", - "DCH-03.1" + "IMC:GG3.GP2": [ + "CPL-13" ], - "03.08.04": [ - "DCH-02", - "DCH-04" + "KIM:GG1.GP1": [ + "CPL-13", + "DCH-01", + "PRM-06", + "OPS-01.1" ], - "03.01.22.a": [ - "DCH-03.1", - "DCH-15", - "HRS-03", - "HRS-03.1", - "HRS-04.1", - "HRS-04.2", - "HRS-05", - "HRS-05.1", - "SAT-02", - "SAT-03", - "SAT-03.3", - "WEB-01" + "KIM:GG3.GP2": [ + "CPL-13" ], - "03.08.05.b": [ - "DCH-07", - "DCH-07.1" + "MA:GG3.GP2": [ + "CPL-13" ], - "03.08.07.b": [ - "DCH-10.2" + "MON:GG1.GP1": [ + "CPL-13", + "MON-01", + "PRM-06", + "OPS-01.1" ], - "03.01.20.c.02": [ - "DCH-13", - "DCH-13.1", - "DCH-14.2", - "DCH-14.3", - "DCH-18", - "NET-05", - "TPM-05" + "MON:GG3.GP2": [ + "CPL-13" ], - "03.12.05.a": [ - "DCH-14.2", - "DCH-14.3", - "HRS-06", - "HRS-06.1", - "NET-05", - "NET-05.2" + "OPD:GG1.GP1": [ + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "03.14.08": [ - "DCH-18" + "OPD:GG3.GP2": [ + "CPL-13" ], - "03.14.02.a": [ - "END-01", - "END-04.3", - "END-04.7" + "OPF:GG1.GP1": [ + "CPL-13", + "PRM-06", + "OPS-01.1" ], - "03.14.02.c": [ - "END-04" + "OPF:GG3.GP2": [ + "CPL-13" ], - "03.14.02.c.01": [ - "END-04", - "END-04.7" + "OTA:GG1.GP1": [ + "CPL-13", + "PRM-06", + "OPS-01.1", + "SAT-01" ], - "03.14.02.c.02": [ - "END-04", - "END-04.7" + "OTA:GG3.GP2": [ + "CPL-13" ], - "03.14.02.b": [ - "END-04.1" + "PM:GG1.GP1": [ + "CPL-13", + "HRS-01", + "PRM-06", + "OPS-01.1" ], - "03.13.12.a": [ - "END-14" + "PM:GG3.GP2": [ + "CPL-13" ], - "03.01.01.g.02": [ - "HRS-01", - "HRS-08", - "HRS-09", - "HRS-09.4", - "IAC-07", - "IAC-07.1", - "IAC-15" + "RISK:GG1.GP1": [ + "CPL-13", + "PRM-06", + "RSK-01", + "OPS-01.1" ], - "03.15.03.a": [ - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "HRS-05.3", - "HRS-05.4", - "HRS-05.5" + "RISK:GG3.GP2": [ + "CPL-13" ], - "03.01.01.c.01": [ - "HRS-02", - "IAC-08", - "IAC-15", - "IAC-15.5" + "RRD:GG1.GP1": [ + "CPL-13", + "PRM-06", + "SEA-01.2", + "OPS-01.1" ], - "03.01.01.c.02": [ - "HRS-02", - "IAC-08", - "IAC-15" + "RRD:GG3.GP2": [ + "CPL-13" ], - "03.09.01.a": [ - "HRS-02", - "HRS-04", - "HRS-04.1" + "RRM:GG1.GP1": [ + "CPL-13", + "PRM-06", + "SEA-01.2", + "OPS-01.1" ], - "03.09.01.b": [ - "HRS-02", - "HRS-04", - "HRS-04.1" + "RRM:GG3.GP2": [ + "CPL-13" ], - "03.06.04.a": [ - "HRS-03", - "HRS-04.2", - "IRO-05", - "SAT-03" + "RTSE:GG1.GP1": [ + "CPL-13", + "PRM-06", + "SEA-01", + "OPS-01.1" ], - "03.07.06.a": [ - "HRS-03", - "IAC-08", - "MNT-01", - "MNT-06", - "MNT-06.1", - "MNT-06.2", - "TPM-01", - "TPM-01.1", - "TPM-05", - "TPM-05.4" + "RTSE:GG3.GP2": [ + "CPL-13" ], - "03.15.03.b": [ - "HRS-03", - "HRS-03.1", - "HRS-04.2", - "HRS-05.7", - "HRS-06" + "SC:GG3.GP2": [ + "CPL-13" ], - "03.16.03.b": [ - "HRS-03", - "HRS-10", - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "TM:GG3.GP2": [ + "CPL-13" ], - "03.07.06.d": [ - "HRS-03.2", - "MNT-06", - "MNT-06.1" + "VAR:GG1.GP1": [ + "CPL-13", + "PRM-06", + "OPS-01.1", + "VPM-01" ], - "03.02.02.a.01": [ - "HRS-04.1", - "HRS-04.2", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6" + "VAR:GG3.GP2": [ + "CPL-13" ], - "03.06.04.a.01": [ - "HRS-04.2", - "SAT-03" + "GG3.GP2": [ + "CPL-13" ], - "03.15.03.c": [ - "HRS-05.7", - "HRS-06", - "HRS-06.1" + "OPD:SG1.SP2": [ + "CFG-02.9" + ], + "MON:SG1": [ + "MON-01" + ], + "MON:SG1.SP1": [ + "MON-01" + ], + "MON:SG1.SP2": [ + "MON-01" + ], + "MON:SG1.SP3": [ + "MON-01" + ], + "MON:SG1.SP4": [ + "MON-01" + ], + "MON:SG2": [ + "MON-01" + ], + "MON:SG2.SP1": [ + "MON-01" + ], + "MON:SG2.SP2": [ + "MON-01" + ], + "MON:SG2.SP3": [ + "MON-01" ], - "03.01.01.f.04": [ - "HRS-07", - "HRS-07.1", - "IAC-15", - "IAC-15.6" + "MON:SG2.SP4": [ + "MON-01" ], - "03.01.01.f.05": [ - "HRS-07", - "HRS-07.1", - "IAC-15", - "IAC-15.6" + "MON:GG2": [ + "MON-01" ], - "03.09.02.a": [ - "HRS-08", - "HRS-09" + "MON:GG2.GP2": [ + "MON-01" ], - "03.09.02.b.01": [ - "HRS-08", - "HRS-09", - "HRS-09.2" + "IMC:SG2": [ + "MON-01.4" ], - "03.01.01.f.03": [ - "HRS-09", - "IAC-15" + "IMC:SG2.SP1": [ + "MON-01.4" ], - "03.09.02.a.01": [ - "HRS-09.2", - "HRS-09.4", - "IAC-07", - "IAC-07.2" + "IMC:SG2.SP2": [ + "MON-01.4" ], - "03.09.02.a.02": [ - "HRS-09.2", - "HRS-09.4", - "IAC-07", - "IAC-07.2" + "KIM:SG4": [ + "DCH-01" ], - "03.01.04.a": [ - "HRS-11", - "HRS-12" + "KIM:SG4.SP1": [ + "DCH-01" ], - "03.01.01.a": [ - "IAC-01", - "IAC-15" + "KIM:SG4.SP2": [ + "DCH-01" ], - "03.01.18.b": [ - "IAC-01", - "IAC-04", - "MDM-02", - "MDM-06", - "MDM-07", - "MDM-11" + "KIM:SG4.SP3": [ + "DCH-01" ], - "03.05.01.a": [ - "IAC-01", - "IAC-01.2", - "IAC-02", - "IAC-03", - "IAC-05" + "KIM:SG5": [ + "DCH-01" ], - "03.05.05.a": [ - "IAC-01", - "IAC-07", - "IAC-07.1", - "IAC-28.1" + "KIM:SG5.SP1": [ + "DCH-01" ], - "03.05.12.e": [ - "IAC-01", - "IAC-10", - "IAC-10.1", - "IAC-15.1" + "KIM:SG5.SP2": [ + "DCH-01" ], - "03.05.02": [ - "IAC-01.2", - "IAC-04", - "IAC-05" + "KIM:SG5.SP3": [ + "DCH-01" ], - "03.05.05.d": [ - "IAC-01.2", - "IAC-02", - "IAC-09", - "IAC-09.2", - "IAC-09.5", - "IAC-15.1" + "KIM:SG6": [ + "DCH-01" ], - "03.05.07.a": [ - "IAC-01.2", - "IAC-10", - "IAC-10.4", - "IAC-10.11" + "KIM:SG6.SP1": [ + "DCH-01" ], - "03.05.07.b": [ - "IAC-01.2", - "IAC-10", - "IAC-10.4", - "IAC-10.11" + "KIM:SG6.SP2": [ + "DCH-01" ], - "03.05.07.c": [ - "IAC-01.2", - "IAC-10", - "IAC-10.5", - "IAC-10.11", - "IAC-15.1" + "KIM:GG2": [ + "DCH-01" ], - "03.05.12.f": [ - "IAC-01.2", - "IAC-10", - "IAC-10.1", - "IAC-10.5", - "IAC-15.1" + "KIM:GG2.GP2": [ + "DCH-01" ], - "03.07.05.a": [ - "IAC-01.2", - "IAC-05.2", - "MNT-02", - "MNT-05", - "MNT-05.1", - "MNT-05.5" + "HRM:SG1": [ + "HRS-01" ], - "03.05.04": [ - "IAC-02.2" + "HRM:SG1.SP1": [ + "HRS-01" ], - "03.07.05.b": [ - "IAC-02.2", - "IAC-06", - "MNT-05", - "MNT-05.3" + "HRM:SG1.SP2": [ + "HRS-01" ], - "03.05.03": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "HRM:SG2.SP1": [ + "HRS-01" ], - "03.01.01.g.01": [ - "IAC-07", - "IAC-07.1", - "IAC-15" + "HRM:SG2.SP2": [ + "HRS-01" ], - "03.01.01.g.03": [ - "IAC-07", - "IAC-07.1", - "IAC-15", - "IAC-17" + "HRM:SG3": [ + "HRS-01" ], - "03.09.02.b.02": [ - "IAC-07.1", - "IAC-20" + "HRM:SG3.SP3": [ + "HRS-01" ], - "03.01.01.c.03": [ - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "HRM:SG4": [ + "HRS-01" ], - "03.01.05.b": [ - "IAC-08", - "IAC-15", - "IAC-20", - "IAC-21" + "HRM:SG4.SP1": [ + "HRS-01" ], - "03.01.06.a": [ - "IAC-08", - "IAC-16", - "IAC-20", - "IAC-21", - "IAC-21.3" + "HRM:SG4.SP2": [ + "HRS-01" ], - "03.05.05.b": [ - "IAC-09", - "IAC-09.1", - "IAC-15.1" + "HRM:SG4.SP3": [ + "HRS-01" ], - "03.05.05.c": [ - "IAC-09", - "IAC-15.1" + "HRM:GG2": [ + "HRS-01" ], - "03.05.12.a": [ - "IAC-10", - "IAC-10.3", - "IAC-28" + "HRM:GG2.GP2": [ + "HRS-01" ], - "03.05.12.b": [ - "IAC-10", - "IAC-10.1" + "PM:SG3": [ + "HRS-01" ], - "03.05.12.c": [ - "IAC-10", - "IAC-10.1", - "IAC-28" + "PM:SG3.SP1": [ + "HRS-01" ], - "03.05.11": [ - "IAC-11" + "PM:SG3.SP2": [ + "HRS-01" ], - "03.05.01.b": [ - "IAC-14" + "PM:GG2": [ + "HRS-01" ], - "03.01.01.b": [ - "IAC-15", - "IAC-28.1" + "PM:GG2.GP2": [ + "HRS-01" ], - "03.01.01.f.01": [ - "IAC-15" + "ADM:GG2.GP4": [ + "HRS-03" ], - "03.01.05.c": [ - "IAC-15", - "IAC-15.7", - "IAC-17" + "ADM:GG2.GP6": [ + "HRS-03" ], - "03.01.05.d": [ - "IAC-15", - "IAC-17" + "AM:GG2.GP4": [ + "HRS-03" ], - "03.01.01.f.02": [ - "IAC-15.3" + "AM:GG2.GP6": [ + "HRS-03" ], - "03.01.07.a": [ - "IAC-16", - "IAC-21", - "IAC-21.3", - "IAC-21.5" + "COMM:GG2.GP4": [ + "HRS-03" ], - "03.10.01.c": [ - "IAC-17", - "PES-02" + "COMM:GG2.GP6": [ + "HRS-03" ], - "03.10.01.d": [ - "IAC-17", - "PES-02", - "PES-02.1" + "COMP:GG2.GP4": [ + "HRS-03" ], - "03.01.05.a": [ - "IAC-20", - "IAC-20.1", - "IAC-21" + "COMP:GG2.GP6": [ + "HRS-03" ], - "03.01.06.b": [ - "IAC-21.2" + "CTRL:GG2.GP4": [ + "HRS-03" ], - "03.07.05.c": [ - "IAC-25", - "MNT-05", - "MNT-05.4" + "CTRL:GG2.GP6": [ + "HRS-03" ], - "03.06.01": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-12" + "EC:GG2.GP4": [ + "HRS-03" ], - "03.06.02.a": [ - "IRO-02", - "IRO-09" + "EC:GG2.GP6": [ + "HRS-03" ], - "03.06.02.b": [ - "IRO-02", - "IRO-09", - "IRO-10", - "IRO-10.2" + "EF:GG2.GP4": [ + "HRS-03" ], - "03.06.02.c": [ - "IRO-02", - "IRO-10", - "IRO-10.2", - "IRO-14" + "EF:GG2.GP6": [ + "HRS-03" ], - "03.06.02.d": [ - "IRO-02", - "IRO-11" + "EXD:GG2.GP4": [ + "HRS-03" ], - "03.06.05.a": [ - "IRO-04" + "EXD:GG2.GP6": [ + "HRS-03" ], - "03.06.05.a.01": [ - "IRO-04" + "FRM:GG2.GP4": [ + "HRS-03" ], - "03.06.05.a.02": [ - "IRO-04" + "FRM:GG2.GP6": [ + "HRS-03" ], - "03.06.05.a.03": [ - "IRO-04" + "HRM:SG3.SP1": [ + "HRS-03" ], - "03.06.05.a.04": [ - "IRO-04" + "HRM:GG2.GP4": [ + "HRS-03" ], - "03.06.05.a.05": [ - "IRO-04" + "HRM:GG2.GP6": [ + "HRS-03" ], - "03.06.05.a.06": [ - "IRO-04" + "ID:GG2.GP4": [ + "HRS-03" ], - "03.06.05.b": [ - "IRO-04" + "ID:GG2.GP6": [ + "HRS-03" ], - "03.06.04.b": [ - "IRO-04.2", - "IRO-04.3", - "IRO-13", - "SAT-03", - "SAT-03.7" + "IMC:GG2.GP4": [ + "HRS-03" ], - "03.06.05.c": [ - "IRO-04.2" + "IMC:GG2.GP6": [ + "HRS-03" ], - "03.06.04.a.03": [ - "IRO-05", - "SAT-02" + "KIM:GG2.GP4": [ + "HRS-03" ], - "03.06.03": [ - "IRO-06" + "KIM:GG2.GP6": [ + "HRS-03" ], - "03.15.02.a": [ - "IAO-03" + "MA:GG2.GP4": [ + "HRS-03" ], - "03.15.02.a.01": [ - "IAO-03" + "MA:GG2.GP6": [ + "HRS-03" ], - "03.15.02.a.02": [ - "IAO-03" + "MON:GG2.GP4": [ + "HRS-03" ], - "03.15.02.a.03": [ - "IAO-03", - "RSK-03.1", - "THR-09" + "MON:GG2.GP6": [ + "HRS-03" ], - "03.15.02.a.05": [ - "IAO-03" + "OPD:GG2.GP4": [ + "HRS-03" ], - "03.15.02.a.06": [ - "IAO-03" + "OPD:GG2.GP6": [ + "HRS-03" ], - "03.15.02.a.07": [ - "IAO-03" + "OPF:GG2.GP4": [ + "HRS-03" ], - "03.15.02.a.08": [ - "IAO-03" + "OPF:GG2.GP6": [ + "HRS-03" ], - "03.15.02.b": [ - "IAO-03" + "OTA:GG2.GP4": [ + "HRS-03" ], - "03.12.02.a": [ - "IAO-05" + "OTA:GG2.GP6": [ + "HRS-03" ], - "03.12.02.a.02": [ - "IAO-05", - "RSK-04.1", - "RSK-06", - "VPM-02", - "VPM-05" + "PM:GG2.GP4": [ + "HRS-03" ], - "03.12.02.b": [ - "IAO-05" + "PM:GG2.GP6": [ + "HRS-03" ], - "03.12.02.b.01": [ - "IAO-05" + "RISK:GG2.GP4": [ + "HRS-03" ], - "03.12.02.b.02": [ - "IAO-05" + "RISK:GG2.GP6": [ + "HRS-03" ], - "03.12.02.b.03": [ - "IAO-05" + "RRD:GG2.GP4": [ + "HRS-03" ], - "03.14.01.a": [ - "IAO-05", - "TDA-01", - "TDA-09", - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-04", - "VPM-05" + "RRD:GG2.GP6": [ + "HRS-03" ], - "03.07.04.b": [ - "MNT-04.1" + "RRM:GG2.GP4": [ + "HRS-03" ], - "03.01.12.d": [ - "MNT-05", - "NET-14", - "NET-14.4" + "RRM:GG2.GP6": [ + "HRS-03" ], - "03.07.06.b": [ - "MNT-06" + "RTSE:GG2.GP4": [ + "HRS-03" ], - "03.07.06.c": [ - "MNT-06", - "MNT-06.1", - "MNT-06.2" + "RTSE:GG2.GP6": [ + "HRS-03" ], - "03.01.18.c": [ - "MDM-03" + "SC:GG2.GP4": [ + "HRS-03" ], - "03.01.16.b": [ - "NET-01", - "NET-02.2", - "NET-15", - "NET-15.1", - "SEA-01" + "SC:GG2.GP6": [ + "HRS-03" ], - "03.13.01.b": [ - "NET-02", - "NET-03", - "NET-03.8", - "NET-06", - "NET-06.3", - "NET-08.1" + "TM:GG2.GP4": [ + "HRS-03" ], - "03.13.01.c": [ - "NET-03", - "NET-04", - "SEA-01", - "SEA-02" + "TM:GG2.GP6": [ + "HRS-03" ], - "03.13.06": [ - "NET-04.1" + "VAR:GG2.GP4": [ + "HRS-03" ], - "03.12.05.b": [ - "NET-05", - "NET-05.2" + "VAR:GG2.GP6": [ + "HRS-03" ], - "03.12.05.c": [ - "NET-05.2" + "GG2.GP4": [ + "HRS-03" ], - "03.13.09": [ - "NET-07" + "GG2.GP6": [ + "HRS-03" ], - "03.13.15": [ - "NET-09" + "HRM:SG3.SP2": [ + "HRS-03.1" ], - "03.01.12.b": [ - "NET-14", - "NET-14.1", - "NET-14.3" + "HRM:SG3.SP4": [ + "HRS-07" ], - "03.10.06.a": [ - "NET-14.5", - "PES-11" + "HRM:SG1.SP3": [ + "HRS-13" ], - "03.10.06.b": [ - "NET-14.5", - "PES-11" + "HRM:SG2": [ + "HRS-13.1" ], - "03.01.16.d": [ - "NET-15.1" + "PM:SG1": [ + "HRS-13.2" ], - "03.01.16.c": [ - "NET-15.2", - "NET-15.3", - "SEA-01" + "PM:SG1.SP1": [ + "HRS-13.2" ], - "03.10.07.a": [ - "PES-01", - "PES-02", - "PES-03", - "PES-03.1" + "PM:SG2": [ + "HRS-13.2" ], - "03.10.01.b": [ - "PES-02", - "PES-02.1" + "PM:SG2.SP1": [ + "HRS-13.2" ], - "03.10.02.a": [ - "PES-03", - "PES-03.1", - "PES-03.3", - "PES-05", - "PES-05.1", - "PES-05.2" + "AM:SG1": [ + "IAC-01" ], - "03.10.07.a.01": [ - "PES-03", - "PES-03.4", - "PES-04", - "PES-04.1" + "AM:GG2": [ + "IAC-01" ], - "03.10.07.a.02": [ - "PES-03", - "PES-03.1", - "PES-03.4", - "PES-04", - "PES-04.1" + "AM:GG2.GP2": [ + "IAC-01" ], - "03.10.07.d": [ - "PES-03", - "PES-04", - "PES-04.1" + "ID:SG1": [ + "IAC-01" ], - "03.10.07.b": [ - "PES-03.3" + "ID:SG1.SP1": [ + "IAC-01" ], - "03.10.02.b": [ - "PES-05", - "PES-05.1", - "PES-05.2", - "PES-06", - "PES-06.1" + "ID:SG1.SP2": [ + "IAC-01" ], - "03.10.07.c": [ - "PES-06", - "PES-06.1", - "PES-06.2", - "PES-06.3", - "PES-06.6" + "ID:SG1.SP3": [ + "IAC-01" ], - "03.10.08": [ - "PES-07", - "PES-12", - "PES-12.1" + "ID:SG2": [ + "IAC-01" ], - "03.10.07.e": [ - "PES-12", - "PES-12.2" + "ID:SG2.SP1": [ + "IAC-01" ], - "03.14.03.b": [ - "RSK-02.1", - "THR-03.1", - "THR-10" + "ID:SG2.SP2": [ + "IAC-01" ], - "03.11.02.b": [ - "RSK-06", - "RSK-06.1", - "RSK-06.2", - "VPM-02", - "VPM-04", - "VPM-05" + "ID:SG2.SP3": [ + "IAC-01" ], - "03.11.04": [ - "RSK-06.1" + "ID:SG2.SP4": [ + "IAC-01" ], - "03.11.01.b": [ - "RSK-07", - "RSK-09.1" + "ID:GG2": [ + "IAC-01" ], - "03.17.01.b": [ - "RSK-09" + "ID:GG2.GP2": [ + "IAC-01" ], - "03.17.03.a": [ - "RSK-09", - "RSK-09.1", - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-05.5" + "AM:SG1.SP1": [ + "IAC-08" ], - "03.17.03.b": [ - "RSK-09", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-05.2", - "TPM-05.5", - "TPM-05.7" + "AM:SG1.SP2": [ + "IAC-15.7" ], - "03.13.04": [ - "SEA-05" + "AM:SG1.SP3": [ + "IAC-17" ], - "03.16.02.b": [ - "SEA-07", - "SEA-07.1", - "TDA-17.1" + "AM:SG1.SP4": [ + "IAC-17" ], - "03.16.02.a": [ - "SEA-07.1", - "TDA-17" + "IMC:SG1": [ + "IRO-01" ], - "03.02.01.a": [ - "SAT-01" + "IMC:SG1.SP1": [ + "IRO-01" ], - "03.02.01.a.01": [ - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6" + "IMC:SG1.SP2": [ + "IRO-01" ], - "03.02.01.a.02": [ - "SAT-02", - "SAT-03", - "SAT-03.6", - "THR-03" + "IMC:GG2": [ + "IRO-01" ], - "03.02.01.a.03": [ - "SAT-02", - "SAT-02.2", - "SAT-03.6", - "THR-03", - "THR-05" + "IMC:GG2.GP2": [ + "IRO-01" ], - "03.02.01.b": [ - "SAT-02", - "SAT-03.6", - "THR-03" + "IMC:SG2.SP4": [ + "IRO-02" ], - "03.02.02.a": [ - "SAT-03" + "IMC:SG3": [ + "IRO-02" ], - "03.02.02.a.02": [ - "SAT-03", - "SAT-03.6" + "IMC:SG3.SP1": [ + "IRO-02" ], - "03.02.02.b": [ - "SAT-03", - "SAT-03.6", - "THR-03" + "IMC:SG3.SP2": [ + "IRO-02" ], - "03.06.04.a.02": [ - "SAT-03", - "SAT-03.6" + "IMC:SG4": [ + "IRO-02" ], - "03.17.02": [ - "TDA-01", - "TPM-03.1", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-05.1", - "TPM-05.2", - "TPM-05.5", - "TPM-05.7", - "TPM-08", - "TPM-09", - "TPM-10" + "IMC:SG4.SP1": [ + "IRO-02" ], - "03.16.03.a": [ - "TPM-01", - "TPM-04", - "TPM-04.4", - "TPM-05", - "TPM-05.2", - "TPM-05.8" + "IMC:SG4.SP2": [ + "IRO-02" ], - "03.16.03.c": [ - "TPM-04", - "TPM-05", - "TPM-05.2", - "TPM-05.5", - "TPM-05.6", - "TPM-05.8", - "TPM-08" + "IMC:SG4.SP3": [ + "IRO-02" ], - "03.11.02.a": [ - "THR-01", - "THR-03", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-06" + "IMC:SG4.SP4": [ + "IRO-02" ], - "03.14.03.a": [ - "THR-01", - "THR-03" + "IMC:SG2.SP3": [ + "IRO-08" ], - "03.14.01.b": [ - "VPM-04", - "VPM-05" + "IMC:SG5": [ + "IRO-13" ], - "03.11.02.c": [ - "VPM-06.1" - ] - }, - "general-nist-800-171a": { - "3.4.9[a]": [ - "GOV-02" + "IMC:SG5.SP1": [ + "IRO-13" ], - "3.9.2[a]": [ - "GOV-02", - "HRS-01", - "HRS-07", - "HRS-08", - "HRS-09" + "IMC:SG5.SP2": [ + "IRO-13" ], - "3.4.1[d]": [ - "AST-02" + "EC:SG4": [ + "PES-01" ], - "3.4.1[e]": [ - "AST-02" + "EC:SG4.SP2": [ + "PES-01" ], - "3.4.1[f]": [ - "AST-02", - "AST-02.1" + "EC:GG2": [ + "PES-01" ], - "3.8.9": [ - "BCD-11", - "BCD-11.4" + "EC:GG2.GP2": [ + "PES-01" ], - "3.4.3[a]": [ - "CHG-02" + "EF:SG1.SP3": [ + "PRM-01" ], - "3.4.3[b]": [ - "CHG-02" + "FRM:SG1": [ + "PRM-01" ], - "3.4.3[c]": [ - "CHG-02" + "FRM:SG1.SP1": [ + "PRM-01" ], - "3.4.3[d]": [ - "CHG-02" + "FRM:SG1.SP2": [ + "PRM-01" ], - "3.4.4": [ - "CHG-03" + "FRM:SG2": [ + "PRM-01" ], - "3.4.5[a]": [ - "CHG-04", - "END-03.2" + "FRM:SG2.SP1": [ + "PRM-01" ], - "3.4.5[b]": [ - "CHG-04", - "END-03.2" + "FRM:SG2.SP2": [ + "PRM-01" ], - "3.4.5[c]": [ - "CHG-04", - "END-03.2" + "FRM:SG2.SP3": [ + "PRM-01" ], - "3.4.5[d]": [ - "CHG-04", - "END-03.2" + "FRM:SG3": [ + "PRM-01" ], - "3.4.5[e]": [ - "CHG-04", - "END-03.2" + "FRM:SG3.SP1": [ + "PRM-01" ], - "3.4.5[f]": [ - "CHG-04", - "END-03.2" + "FRM:SG4": [ + "PRM-01" ], - "3.4.5[g]": [ - "CHG-04", - "END-03.2" + "FRM:SG4.SP1": [ + "PRM-01" ], - "3.4.5[h]": [ - "CHG-04", - "END-03.2" + "FRM:SG4.SP2": [ + "PRM-01" ], - "3.1.22[a]": [ - "CLD-06", - "CLD-10", - "DCH-15", - "WEB-02", - "WEB-04" + "FRM:SG5": [ + "PRM-01" ], - "3.1.22[b]": [ - "CLD-06", - "CLD-10", - "DCH-15", - "WEB-02", - "WEB-04" + "FRM:SG5.SP1": [ + "PRM-01" ], - "3.1.22[c]": [ - "CLD-06", - "CLD-10", - "DCH-15", - "WEB-02", - "WEB-04" + "FRM:SG5.SP2": [ + "PRM-01" ], - "3.1.22[d]": [ - "CLD-06", - "CLD-10", - "DCH-15", - "WEB-02", - "WEB-04" + "FRM:SG5.SP3": [ + "PRM-01" ], - "3.1.22[e]": [ - "CLD-06", - "CLD-10", - "DCH-15", - "WEB-02", - "WEB-04" + "FRM:GG2": [ + "PRM-01" ], - "3.12.1[a]": [ - "CPL-02" + "FRM:GG2.GP2": [ + "PRM-01" ], - "3.12.1[b]": [ - "CPL-02" + "SC:SG1": [ + "PRM-01" ], - "3.12.3": [ - "CPL-02" + "SC:SG1.SP1": [ + "PRM-01" ], - "3.4.1[a]": [ - "CFG-02", - "END-01" + "SC:SG1.SP2": [ + "PRM-01" ], - "3.4.1[b]": [ - "CFG-02", - "END-01" + "SC:SG2": [ + "PRM-01" ], - "3.4.1[c]": [ - "CFG-02", - "END-01" + "SC:SG2.SP1": [ + "PRM-01" ], - "3.4.2[a]": [ - "CFG-02", - "END-01" + "EF:SG1": [ + "PRM-01.1" ], - "3.4.2[b]": [ - "CFG-02", - "END-01" + "EF:SG1.SP1": [ + "PRM-01.1" ], - "3.4.6[a]": [ - "CFG-03" + "EF:SG1.SP2": [ + "PRM-01.1" ], - "3.4.6[b]": [ - "CFG-03" + "EF:SG2.SP1": [ + "PRM-01.1" ], - "3.4.7[a]": [ - "CFG-03.1" + "ADM:GG2.GP3": [ + "PRM-02" ], - "3.4.7[b]": [ - "CFG-03.1" + "AM:GG2.GP3": [ + "PRM-02" ], - "3.4.7[c]": [ - "CFG-03.1" + "COMM:GG2.GP3": [ + "PRM-02" ], - "3.4.7[d]": [ - "CFG-03.1" + "COMP:GG2.GP3": [ + "PRM-02" ], - "3.4.7[e]": [ - "CFG-03.1" + "CTRL:GG2.GP3": [ + "PRM-02" ], - "3.4.7[f]": [ - "CFG-03.1" + "EC:SG4.SP5": [ + "PRM-02" ], - "3.4.7[g]": [ - "CFG-03.1" + "EC:GG2.GP3": [ + "PRM-02" ], - "3.4.7[h]": [ - "CFG-03.1" + "EF:SG2": [ + "PRM-02" ], - "3.4.7[i]": [ - "CFG-03.1" + "EF:GG2.GP3": [ + "PRM-02" ], - "3.4.7[j]": [ - "CFG-03.1" + "EXD:GG2.GP3": [ + "PRM-02" ], - "3.4.7[k]": [ - "CFG-03.1" + "FRM:GG2.GP3": [ + "PRM-02" ], - "3.4.7[l]": [ - "CFG-03.1" + "HRM:GG2.GP3": [ + "PRM-02" ], - "3.4.7[m]": [ - "CFG-03.1" + "ID:GG2.GP3": [ + "PRM-02" ], - "3.4.7[n]": [ - "CFG-03.1" + "IMC:GG2.GP3": [ + "PRM-02" ], - "3.4.7[o]": [ - "CFG-03.1" + "KIM:GG2.GP3": [ + "PRM-02" ], - "3.4.8[a]": [ - "CFG-03.3" + "MA:GG2.GP3": [ + "PRM-02" ], - "3.4.8[b]": [ - "CFG-03.3" + "MON:GG2.GP3": [ + "PRM-02" ], - "3.4.8[c]": [ - "CFG-03.3" + "OPD:GG2.GP3": [ + "PRM-02" ], - "3.13.7": [ - "CFG-03.4" + "OPF:GG2.GP3": [ + "PRM-02" ], - "3.4.9[b]": [ - "CFG-05" + "OTA:GG2.GP3": [ + "PRM-02" ], - "3.4.9[c]": [ - "CFG-05" + "PM:GG2.GP3": [ + "PRM-02" ], - "3.14.6[a]": [ - "MON-01.3" + "RISK:GG2.GP3": [ + "PRM-02" ], - "3.14.6[b]": [ - "MON-01.3" + "RRD:GG2.GP3": [ + "PRM-02" ], - "3.14.6[c]": [ - "MON-01.3" + "RRM:GG2.GP3": [ + "PRM-02" ], - "3.3.3[a]": [ - "MON-01.8" + "RTSE:GG2.GP3": [ + "PRM-02" ], - "3.3.3[b]": [ - "MON-01.8" + "SC:GG2.GP3": [ + "PRM-02" ], - "3.3.3[c]": [ - "MON-01.8" + "TM:GG2.GP3": [ + "PRM-02" ], - "3.14.3[a]": [ - "MON-01.8" + "VAR:GG2.GP3": [ + "PRM-02" ], - "3.14.3[b]": [ - "MON-01.8" + "GG2.GP3": [ + "PRM-02" ], - "3.14.3[c]": [ - "MON-01.8" + "EF:SG2.SP2": [ + "PRM-04" ], - "3.3.5[a]": [ - "MON-02.1" + "SC:SG2.SP2": [ + "PRM-06" ], - "3.3.5[b]": [ - "MON-02.1" + "SC:SG2.SP3": [ + "PRM-06" ], - "3.14.7[a]": [ - "MON-02.1" + "SC:SG3": [ + "PRM-06" ], - "3.14.7[b]": [ - "MON-02.1" + "SC:SG3.SP1": [ + "PRM-06" ], - "3.3.1[a]": [ - "MON-03" + "ADM:SG3": [ + "PRM-07" ], - "3.3.1[b]": [ - "MON-03" + "RISK:SG1": [ + "RSK-01" ], - "3.3.1[d]": [ - "MON-03" + "RISK:SG1.SP1": [ + "RSK-01" ], - "3.3.2[a]": [ - "MON-03", - "MON-03.2", - "MON-03.7" + "RISK:SG1.SP2": [ + "RSK-01" ], - "3.3.2[b]": [ - "MON-03" + "RISK:SG4.SP3": [ + "RSK-01" ], - "3.3.1[c]": [ - "MON-03.2" + "RISK:SG6": [ + "RSK-01" ], - "3.3.4[a]": [ - "MON-05" + "RISK:SG6.SP1": [ + "RSK-01" ], - "3.3.4[b]": [ - "MON-05" + "RISK:SG6.SP2": [ + "RSK-01" ], - "3.3.4[c]": [ - "MON-05" + "RISK:GG2": [ + "RSK-01" ], - "3.3.6[a]": [ - "MON-06" + "RISK:GG2.GP2": [ + "RSK-01" ], - "3.3.6[b]": [ - "MON-06" + "TM:SG3": [ + "RSK-01" ], - "3.3.7[a]": [ - "MON-07" + "TM:SG3.SP1": [ + "RSK-01" ], - "3.3.7[b]": [ - "MON-07", - "MON-07.1" + "RISK:SG2": [ + "RSK-01.5" ], - "3.3.7[c]": [ - "MON-07.1" + "RISK:SG2.SP1": [ + "RSK-01.5" ], - "3.3.8[a]": [ - "MON-08" + "RISK:SG4.SP2": [ + "RSK-02" ], - "3.3.8[b]": [ - "MON-08" + "RISK:SG4": [ + "RSK-02.1" ], - "3.3.8[c]": [ - "MON-08" + "EC:SG3": [ + "RSK-03" ], - "3.3.8[d]": [ - "MON-08" + "KIM:SG3": [ + "RSK-03" ], - "3.3.8[e]": [ - "MON-08" + "KIM:SG3.SP1": [ + "RSK-03" ], - "3.3.8[f]": [ - "MON-08" + "RISK:SG3": [ + "RSK-03" ], - "3.3.9[a]": [ - "MON-08.2" + "RISK:SG3.SP1": [ + "RSK-03" ], - "3.3.9[b]": [ - "MON-08.2" + "RISK:SG3.SP2": [ + "RSK-03" ], - "3.3.1[e]": [ - "MON-10" + "EC:SG3.SP1": [ + "RSK-04" ], - "3.3.1[f]": [ - "MON-10" + "RISK:SG4.SP1": [ + "RSK-04" ], - "3.13.8[a]": [ - "CRY-01", - "CRY-03" + "RISK:SG2.SP2": [ + "RSK-04.2" ], - "3.13.11": [ - "CRY-01", - "CRY-03" + "RISK:SG5": [ + "RSK-06" ], - "3.13.8[b]": [ - "CRY-01.1" + "EC:SG3.SP2": [ + "RSK-06.4" ], - "3.13.8[c]": [ - "CRY-01.1" + "KIM:SG3.SP2": [ + "RSK-06.4" ], - "3.8.6": [ - "CRY-05" + "PM:SG2.SP2": [ + "RSK-06.4" ], - "3.13.10[a]": [ - "CRY-08", - "CRY-09" + "RISK:SG5.SP1": [ + "RSK-06.4" ], - "3.13.10[b]": [ - "CRY-08", - "CRY-09" + "RISK:SG5.SP2": [ + "RSK-06.4" ], - "3.8.1[a]": [ - "DCH-01" + "TM:SG3.SP2": [ + "RSK-06.4" ], - "3.8.1[b]": [ - "DCH-01" + "RTSE:SG1": [ + "SEA-01" ], - "3.8.1[c]": [ - "DCH-01" + "RTSE:SG1.SP1": [ + "SEA-01" ], - "3.8.1[d]": [ - "DCH-01" + "RTSE:SG1.SP2": [ + "SEA-01" ], - "3.1.3[c]": [ - "DCH-03", - "IAC-08", - "NET-04" + "RTSE:SG1.SP3": [ + "SEA-01" ], - "3.8.2": [ - "DCH-03" + "RTSE:SG1.SP4": [ + "SEA-01" ], - "3.8.4[a]": [ - "DCH-04" + "RTSE:SG1.SP5": [ + "SEA-01" ], - "3.8.4[b]": [ - "DCH-04" + "RTSE:SG2": [ + "SEA-01" ], - "3.8.5[a]": [ - "DCH-07" + "RTSE:SG2.SP1": [ + "SEA-01" ], - "3.8.5[b]": [ - "DCH-07" + "RTSE:SG2.SP2": [ + "SEA-01" ], - "3.7.3": [ - "DCH-09" + "RTSE:SG3": [ + "SEA-01" ], - "3.8.3[a]": [ - "DCH-09" + "RTSE:GG2": [ + "SEA-01" ], - "3.8.3[b]": [ - "DCH-09" + "RTSE:GG2.GP2": [ + "SEA-01" ], - "3.8.7": [ - "DCH-10" + "EC:SG2.SP1": [ + "SEA-01.3" ], - "3.8.8": [ - "DCH-10.2" + "KIM:SG2.SP1": [ + "SEA-01.3" ], - "3.1.20[a]": [ - "DCH-13" + "RRD:SG1": [ + "SEA-01.3" ], - "3.1.20[b]": [ - "DCH-13" + "RRD:SG1.SP1": [ + "SEA-01.3" ], - "3.1.20[c]": [ - "DCH-13" + "RRD:SG2": [ + "SEA-01.3" ], - "3.1.20[d]": [ - "DCH-13" + "RRD:SG2.SP1": [ + "SEA-01.3" ], - "3.1.20[e]": [ - "DCH-13" + "RRD:SG2.SP2": [ + "SEA-01.3" ], - "3.1.20[f]": [ - "DCH-13" + "RRD:SG3": [ + "SEA-01.3" ], - "3.1.21[a]": [ - "DCH-13.2" + "RRD:SG3.SP1": [ + "SEA-01.3" ], - "3.1.21[b]": [ - "DCH-13.2" + "RRD:SG3.SP2": [ + "SEA-01.3" ], - "3.1.21[c]": [ - "DCH-13.2" + "RRD:SG3.SP3": [ + "SEA-01.3" ], - "3.13.16": [ - "END-02" + "RRD:GG2": [ + "SEA-01.3" ], - "3.14.2[a]": [ - "END-04" + "RRD:GG2.GP2": [ + "SEA-01.3" ], - "3.14.2[b]": [ - "END-04" + "RRM:SG1": [ + "SEA-01.3" ], - "3.14.5[a]": [ - "END-04" + "RRM:SG1.SP1": [ + "SEA-01.3" ], - "3.14.5[b]": [ - "END-04" + "RRM:SG1.SP2": [ + "SEA-01.3" ], - "3.14.5[c]": [ - "END-04", - "END-04.7" + "RRM:SG1.SP3": [ + "SEA-01.3" ], - "3.14.4": [ - "END-04.1" + "RRM:SG1.SP4": [ + "SEA-01.3" ], - "3.13.13[a]": [ - "END-10" + "RRM:SG1.SP5": [ + "SEA-01.3" ], - "3.13.13[b]": [ - "END-10" + "RRM:GG2": [ + "SEA-01.3" ], - "3.13.12[a]": [ - "END-14" + "RRM:GG2.GP2": [ + "SEA-01.3" ], - "3.13.12[b]": [ - "END-14" + "RTSE:SG3.SP1": [ + "SEA-01.3" ], - "3.13.12[c]": [ - "END-14" + "RTSE:SG3.SP2": [ + "SEA-01.3" ], - "3.2.2[a]": [ - "HRS-01", - "SAT-03" + "TM:SG2.SP1": [ + "SEA-01.3" ], - "3.2.2[b]": [ - "HRS-01", - "SAT-03" + "ADM:GG3.GP1": [ + "OPS-01.1" ], - "3.2.2[c]": [ - "HRS-01", - "SAT-03" + "AM:GG3.GP1": [ + "OPS-01.1" ], - "3.9.1": [ - "HRS-04" + "COMM:GG3.GP1": [ + "OPS-01.1" ], - "3.9.2[b]": [ - "HRS-07", - "HRS-08", - "HRS-09" + "COMP:GG3.GP1": [ + "OPS-01.1" ], - "3.9.2[c]": [ - "HRS-07", - "HRS-08", - "HRS-09" + "CTRL:GG3.GP1": [ + "OPS-01.1" ], - "3.1.4[a]": [ - "HRS-11" + "EC:GG3.GP1": [ + "OPS-01.1" ], - "3.1.4[b]": [ - "HRS-11" + "EF:GG3.GP1": [ + "OPS-01.1" ], - "3.1.4[c]": [ - "HRS-11" + "EXD:GG3.GP1": [ + "OPS-01.1" ], - "3.5.1[a]": [ - "IAC-02" + "FRM:GG3.GP1": [ + "OPS-01.1" ], - "3.5.1[b]": [ - "IAC-02" + "HRM:GG3.GP1": [ + "OPS-01.1" ], - "3.5.1[c]": [ - "IAC-02" + "ID:GG3.GP1": [ + "OPS-01.1" ], - "3.5.2[a]": [ - "IAC-02" + "IMC:GG3.GP1": [ + "OPS-01.1" ], - "3.5.2[b]": [ - "IAC-02" + "KIM:GG3.GP1": [ + "OPS-01.1" ], - "3.5.2[c]": [ - "IAC-02" + "MA:GG3.GP1": [ + "OPS-01.1" ], - "3.5.4": [ - "IAC-02.2" + "MON:GG3.GP1": [ + "OPS-01.1" ], - "3.5.3[a]": [ - "IAC-06.1", - "IAC-06.3" + "OPD:SG1": [ + "OPS-01.1" ], - "3.5.3[c]": [ - "IAC-06.1" + "OPD:SG1.SP1": [ + "OPS-01.1" ], - "3.5.3[d]": [ - "IAC-06.2" + "OPD:GG3.GP1": [ + "OPS-01.1" ], - "3.5.3[b]": [ - "IAC-06.3" + "OPF:GG3.GP1": [ + "OPS-01.1" ], - "3.5.5[a]": [ - "IAC-09" + "OTA:GG3.GP1": [ + "OPS-01.1" ], - "3.5.5[b]": [ - "IAC-09" + "PM:GG3.GP1": [ + "OPS-01.1" ], - "3.1.5[a]": [ - "IAC-09.5" + "RISK:GG3.GP1": [ + "OPS-01.1" ], - "3.5.8[a]": [ - "IAC-10" + "RRD:GG3.GP1": [ + "OPS-01.1" ], - "3.5.8[b]": [ - "IAC-10" + "RRM:GG3.GP1": [ + "OPS-01.1" ], - "3.5.9": [ - "IAC-10" + "RTSE:GG3.GP1": [ + "OPS-01.1" ], - "3.5.7[a]": [ - "IAC-10.1" + "SC:GG3.GP1": [ + "OPS-01.1" ], - "3.5.7[b]": [ - "IAC-10.1" + "TM:GG3.GP1": [ + "OPS-01.1" ], - "3.5.7[c]": [ - "IAC-10.1" + "VAR:GG3.GP1": [ + "OPS-01.1" ], - "3.5.7[d]": [ - "IAC-10.1" + "OTA:SG1": [ + "SAT-01" ], - "3.5.10[a]": [ - "IAC-10.5" + "OTA:SG1.SP1": [ + "SAT-01" ], - "3.5.10[b]": [ - "IAC-10.5" + "OTA:SG1.SP2": [ + "SAT-01" ], - "3.5.11": [ - "IAC-11" + "OTA:SG1.SP3": [ + "SAT-01" ], - "3.1.2[a]": [ - "IAC-15" + "OTA:SG2": [ + "SAT-01" ], - "3.1.2[b]": [ - "IAC-15" + "OTA:SG2.SP1": [ + "SAT-01" ], - "3.5.6[a]": [ - "IAC-15.3" + "OTA:SG2.SP2": [ + "SAT-01" ], - "3.5.6[b]": [ - "IAC-15.3" + "OTA:SG2.SP3": [ + "SAT-01" ], - "3.1.1[a]": [ - "IAC-20" + "OTA:SG3": [ + "SAT-01" ], - "3.1.1[b]": [ - "IAC-20" + "OTA:SG3.SP1": [ + "SAT-01" ], - "3.1.1[c]": [ - "IAC-20" + "OTA:SG3.SP2": [ + "SAT-01" ], - "3.1.1[d]": [ - "IAC-20" + "OTA:SG3.SP3": [ + "SAT-01" ], - "3.1.1[e]": [ - "IAC-20" + "OTA:SG4": [ + "SAT-01" ], - "3.1.1[f]": [ - "IAC-20" + "OTA:SG4.SP1": [ + "SAT-01" ], - "3.1.5[b]": [ - "IAC-21" + "OTA:SG4.SP2": [ + "SAT-01" ], - "3.1.5[c]": [ - "IAC-21" + "OTA:SG4.SP3": [ + "SAT-01" ], - "3.1.5[d]": [ - "IAC-21" + "OTA:GG2": [ + "SAT-01" ], - "3.1.6[a]": [ - "IAC-21.2" + "OTA:GG2.GP2": [ + "SAT-01" ], - "3.1.6[b]": [ - "IAC-21.2" + "ADM:GG2.GP5": [ + "SAT-03" ], - "3.1.7[a]": [ - "IAC-21.5" + "AM:GG2.GP5": [ + "SAT-03" ], - "3.1.7[b]": [ - "IAC-21.5" + "COMM:GG2.GP5": [ + "SAT-03" ], - "3.1.7[c]": [ - "IAC-21.5" + "COMP:GG2.GP5": [ + "SAT-03" ], - "3.1.7[d]": [ - "IAC-21.5" + "CTRL:GG2.GP5": [ + "SAT-03" ], - "3.1.8[a]": [ - "IAC-22" + "EC:GG2.GP5": [ + "SAT-03" ], - "3.1.8[b]": [ - "IAC-22" + "EF:GG2.GP5": [ + "SAT-03" ], - "3.1.10[a]": [ - "IAC-24" + "EXD:GG2.GP5": [ + "SAT-03" ], - "3.1.10[b]": [ - "IAC-24" + "FRM:GG2.GP5": [ + "SAT-03" ], - "3.1.10[c]": [ - "IAC-24" + "HRM:GG2.GP5": [ + "SAT-03" ], - "3.1.11[a]": [ - "IAC-25" + "ID:GG2.GP5": [ + "SAT-03" ], - "3.1.11[b]": [ - "IAC-25" + "IMC:GG2.GP5": [ + "SAT-03" ], - "3.6.1[a]": [ - "IRO-01", - "IRO-02" + "KIM:GG2.GP5": [ + "SAT-03" ], - "3.6.1[b]": [ - "IRO-01", - "IRO-02" + "MA:GG2.GP5": [ + "SAT-03" ], - "3.6.1[c]": [ - "IRO-01", - "IRO-02" + "MON:GG2.GP5": [ + "SAT-03" ], - "3.6.1[d]": [ - "IRO-01", - "IRO-02" + "OPD:GG2.GP5": [ + "SAT-03" ], - "3.6.1[e]": [ - "IRO-01", - "IRO-02" + "OPF:GG2.GP5": [ + "SAT-03" ], - "3.6.1[f]": [ - "IRO-01", - "IRO-02" + "OTA:GG2.GP5": [ + "SAT-03" ], - "3.6.1[g]": [ - "IRO-02" + "PM:GG2.GP5": [ + "SAT-03" ], - "3.6.2[a]": [ - "IRO-02" + "RISK:GG2.GP5": [ + "SAT-03" ], - "3.6.2[b]": [ - "IRO-02" + "RRD:GG2.GP5": [ + "SAT-03" ], - "3.6.2[c]": [ - "IRO-02" + "RRM:GG2.GP5": [ + "SAT-03" ], - "3.6.2[d]": [ - "IRO-02" + "RTSE:GG2.GP5": [ + "SAT-03" ], - "3.6.2[e]": [ - "IRO-02" + "SC:GG2.GP5": [ + "SAT-03" ], - "3.6.2[f]": [ - "IRO-02" + "TM:GG2.GP5": [ + "SAT-03" ], - "3.6.3": [ - "IRO-06" + "VAR:GG2.GP5": [ + "SAT-03" ], - "3.12.4[a]": [ - "IAO-03" + "GG2.GP5": [ + "SAT-03" ], - "3.12.4[b]": [ - "IAO-03" + "EXD:GG2": [ + "TPM-01" ], - "3.12.4[c]": [ - "IAO-03" + "EXD:GG2.GP2": [ + "TPM-01" ], - "3.12.4[d]": [ - "IAO-03" + "EXD:SG1": [ + "TPM-01.1" ], - "3.12.4[e]": [ - "IAO-03" + "EXD:SG1.SP1": [ + "TPM-01.1" ], - "3.12.4[f]": [ - "IAO-03" + "EXD:SG1.SP2": [ + "TPM-02" ], - "3.12.4[g]": [ - "IAO-03" + "EXD:SG2": [ + "TPM-03" ], - "3.12.4[h]": [ - "IAO-03" + "EXD:SG2.SP1": [ + "TPM-03" ], - "3.12.2[a]": [ - "IAO-05" + "EXD:SG2.SP2": [ + "TPM-03" ], - "3.12.2[b]": [ - "IAO-05" + "EXD:SG3": [ + "TPM-03" ], - "3.12.2[c]": [ - "IAO-05" + "EXD:SG3.SP1": [ + "TPM-03" ], - "3.7.1": [ - "MNT-02" + "EXD:SG3.SP2": [ + "TPM-03" ], - "3.7.2[a]": [ - "MNT-04" + "EXD:SG3.SP3": [ + "TPM-04.1" ], - "3.7.2[b]": [ - "MNT-04" + "EXD:SG3.SP4": [ + "TPM-05" ], - "3.7.2[c]": [ - "MNT-04" + "EXD:SG4": [ + "TPM-08" ], - "3.7.2[d]": [ - "MNT-04" + "EXD:SG4.SP1": [ + "TPM-08" ], - "3.7.4": [ - "MNT-04.2" + "EXD:SG4.SP2": [ + "TPM-09" ], - "3.7.5[a]": [ - "MNT-05" + "VAR:SG1": [ + "VPM-01" ], - "3.7.5[b]": [ - "MNT-05" + "VAR:SG1.SP1": [ + "VPM-01" ], - "3.7.6": [ - "MNT-06" + "VAR:SG1.SP2": [ + "VPM-01" ], - "3.1.18[a]": [ - "MDM-02" + "VAR:SG2": [ + "VPM-01" ], - "3.1.18[b]": [ - "MDM-02" + "VAR:SG2.SP1": [ + "VPM-01" ], - "3.1.18[c]": [ - "MDM-02" + "VAR:SG2.SP2": [ + "VPM-01" ], - "3.1.19[a]": [ - "MDM-03" + "VAR:SG2.SP3": [ + "VPM-01" ], - "3.1.19[b]": [ - "MDM-03" + "VAR:SG3": [ + "VPM-01" ], - "3.13.1[e]": [ - "NET-02.2", - "NET-03" + "VAR:SG3.SP1": [ + "VPM-01" ], - "3.13.1[g]": [ - "NET-02.2", - "NET-03" + "VAR:SG4": [ + "VPM-01" ], - "3.13.1[a]": [ - "NET-03" + "VAR:SG4.SP1": [ + "VPM-01" ], - "3.13.1[b]": [ - "NET-03" + "VAR:GG2": [ + "VPM-01" ], - "3.13.1[c]": [ - "NET-03" + "VAR:GG2.GP2": [ + "VPM-01" + ] + }, + "usa-federal-law-coppa-2024": { + "Sec. 6502.(a)(1)": [ + "CPL-01", + "PRI-04" ], - "3.13.1[d]": [ - "NET-03" + "Sec. 6502.(b)(1)(D)": [ + "PRI-01.6", + "PRI-01.11" ], - "3.13.1[f]": [ - "NET-03" + "Sec. 6502.(b)(1)(A)(i)": [ + "PRI-02" ], - "3.13.1[h]": [ - "NET-03" + "Sec. 6502.(b)(1)(B)(ii)": [ + "PRI-03.4", + "PRI-03.6" ], - "3.1.3[a]": [ - "NET-04" + "Sec. 6502.(b)(1)(B)": [ + "PRI-03.6", + "PRI-06" ], - "3.1.3[b]": [ - "NET-04" + "Sec. 6502.(b)(1)(A)(ii)": [ + "PRI-03.13" ], - "3.1.3[d]": [ - "NET-04" + "Sec. 6502.(b)(1)(B)(i)": [ + "PRI-05.7" ], - "3.1.3[e]": [ - "NET-04" + "Sec. 6502.(b)(1)(B)(iii)": [ + "PRI-06" + ] + }, + "usa-federal-dhs-cisa-ssdaf-2024": { + "1": [ + "CFG-02.4", + "TDA-07", + "TDA-08", + "TDA-08.1" ], - "3.13.6[a]": [ - "NET-04.1" + "2": [ + "TDA-01.1", + "TDA-02.3", + "TDA-04.2", + "TDA-06.3", + "TDA-06.4", + "TDA-09", + "TDA-14.1", + "TDA-15", + "TDA-20" ], - "3.13.6[b]": [ - "NET-04.1" + "3": [ + "TDA-20", + "TDA-20.1", + "TDA-20.3" ], - "3.13.5[a]": [ - "NET-06" + "4": [ + "TDA-09", + "TDA-09.2", + "TDA-09.3" ], - "3.13.5[b]": [ - "NET-06" + "1.f": [ + "GOV-01", + "GOV-15", + "MON-01", + "IRO-01" ], - "3.13.9[a]": [ - "NET-07" + "1.b.": [ + "MON-01", + "MON-03", + "MON-03.2" ], - "3.13.9[b]": [ - "NET-07" + "1.b.i": [ + "MON-01.3", + "MON-02.7" ], - "3.13.9[c]": [ - "NET-07" + "1.b.ii": [ + "MON-01.4", + "MON-02.7" ], - "3.13.15": [ - "NET-09" + "1.e": [ + "CRY-01", + "TDA-02", + "TDA-02.4", + "TDA-06" ], - "3.13.14[a]": [ - "NET-13" + "1.c": [ + "IAC-06" ], - "3.13.14[b]": [ - "NET-13" + "1.d": [ + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-02.1", + "TDA-04.1", + "TDA-05", + "TDA-06.1", + "TDA-06.2", + "TDA-06.3", + "TDA-09.6" ], - "3.1.12[a]": [ - "NET-14.1" + "4.b": [ + "TDA-01", + "VPM-01", + "VPM-02" ], - "3.1.12[b]": [ - "NET-14.1" + "1.a": [ + "TDA-07", + "TDA-08" ], - "3.1.12[c]": [ - "NET-14.1" + "4.a": [ + "TDA-09", + "TDA-15" ], - "3.1.12[d]": [ - "NET-14.1" + "4.c": [ + "THR-06", + "VPM-02" + ] + }, + "usa-federal-dhs-cisa-tic-3-0": { + "3.UNI.PEPAR": [ + "GOV-01", + "GOV-01.1", + "GOV-02", + "CPL-01.1", + "CPL-02" ], - "3.1.13[a]": [ - "NET-14.2" + "3.PEP.WE.ACONT": [ + "GOV-02", + "IAC-01" ], - "3.1.13[b]": [ - "NET-14.2" + "3.UNI.IDMRP": [ + "GOV-02", + "END-01" ], - "3.1.14[a]": [ - "NET-14.3" + "3.UNL.GPAUD": [ + "GOV-02", + "CPL-01" ], - "3.1.14[b]": [ - "NET-14.3" + "3.PEP.DA.DINVE": [ + "AST-02", + "DCH-06.2" ], - "3.1.15[a]": [ - "NET-14.4" + "3.UNI.INVENT": [ + "AST-02", + "AST-02.5" ], - "3.1.15[b]": [ - "NET-14.4" + "3.PEP.DA.DAUTE": [ + "AST-02.8", + "DCH-14.3" ], - "3.1.15[c]": [ - "NET-14.4" + "3.UNI.IRPIH": [ + "BCD-01", + "IRO-01", + "IRO-02", + "IRO-04" ], - "3.1.15[d]": [ - "NET-14.4" + "3.UNI.RESIL": [ + "BCD-01", + "SEA-01", + "SEA-01.2" ], - "3.1.16[a]": [ - "NET-15" + "3.UNL.STEXE": [ + "BCD-04", + "IRO-05.1", + "IRO-06", + "TDA-09.5", + "VPM-07", + "VPM-10" ], - "3.1.16[b]": [ - "NET-15" + "3.UNI.BRECO": [ + "BCD-11", + "CFG-02.3" ], - "3.1.17[a]": [ - "NET-15.1" + "3.PEP.EM.MCQUE": [ + "BCD-12.3" ], - "3.1.17[b]": [ - "NET-15.1" + "3.PEP.RE.EEXPS": [ + "CAP-05" ], - "3.10.2[a]": [ - "PES-01" + "3.PEP.RE.RDELI": [ + "CAP-06" ], - "3.10.2[b]": [ - "PES-01" + "3.UNI.CMANA": [ + "CHG-01", + "CHG-02", + "CHG-04.1", + "CFG-01", + "CFG-02.2" ], - "3.10.2[c]": [ - "PES-01", - "PES-05", - "PES-05.1", - "PES-05.2" + "3.UNI.EUSSE": [ + "CLD-01", + "CLD-02", + "CLD-06", + "SEA-05" ], - "3.10.2[d]": [ - "PES-01", - "PES-05", - "PES-05.1", - "PES-05.2" + "3.PEP.EM.LCTPR": [ + "CFG-02", + "CFG-02.5", + "NET-18" ], - "3.10.1[a]": [ - "PES-02" + "3.UNI.AACCO": [ + "MON-01", + "MON-01.4", + "MON-02.7", + "MON-03", + "MON-03.2" ], - "3.10.1[b]": [ - "PES-02" + "3.UNI.CLMAN": [ + "MON-01", + "MON-01.2", + "MON-02" ], - "3.10.1[c]": [ - "PES-02" + "3.UNI.SAWAR": [ + "MON-01", + "MON-02.1" ], - "3.10.1[d]": [ - "PES-02" + "3.UNL.CMREP": [ + "MON-01", + "MON-02.1", + "MON-02.2", + "MON-06" ], - "3.10.5[a]": [ - "PES-03" + "3.UNI.TSYNC": [ + "MON-07.1", + "SEA-20" ], - "3.10.5[b]": [ - "PES-03" + "3.UNI.DTDIS": [ + "MON-11.3", + "MON-16", + "IRO-03", + "SAT-03.2", + "THR-02", + "THR-11" ], - "3.10.5[c]": [ - "PES-03" + "3.PEP.ID.BBASE": [ + "MON-16", + "SAT-03.2", + "THR-11" ], - "3.10.4": [ - "PES-03.3" + "3.PEP.EM.EETRA": [ + "CRY-03" ], - "3.10.3[a]": [ - "PES-06", - "PES-06.1", - "PES-06.3" + "3.PEP.UN.ECOMM": [ + "CRY-03" ], - "3.10.3[b]": [ - "PES-06", - "PES-06.1", - "PES-06.3" + "3.PEP.DA.PDRES": [ + "CRY-05", + "DCH-01", + "DCH-01.2" ], - "3.10.6[a]": [ - "PES-11" + "3.PEP.DA.PDTRA": [ + "CRY-05" ], - "3.10.6[b]": [ - "PES-11" + "3.PEP.IN.CTLMO": [ + "CRY-12" ], - "3.11.1[a]": [ - "RSK-04" + "3.PEP.DA.DLABE": [ + "DCH-02", + "DCH-04", + "DCH-22.2" ], - "3.11.1[b]": [ - "RSK-04" + "3.PEP.EM.PDPRO": [ + "END-04", + "IRO-15" ], - "3.13.2[a]": [ - "SEA-01" + "3.PEP.FI.AMALW": [ + "END-04" ], - "3.13.2[c]": [ - "SEA-01" + "3.PEP.IN.EDRES": [ + "END-04" ], - "3.13.2[d]": [ - "SEA-01" + "3.PEP.IN.IDPSY": [ + "END-07" ], - "3.13.2[f]": [ - "SEA-01" + "3.PEP.SE.ACMIT": [ + "END-07", + "END-10" ], - "3.13.3[a]": [ - "SEA-03.2" + "3.PEP.WE.ACMIT": [ + "END-07", + "END-10" ], - "3.13.3[b]": [ - "SEA-03.2" + "3.PEP.EM.APPRO": [ + "END-08" ], - "3.13.3[c]": [ - "SEA-03.2" + "3.PEP.EM.ASPRO": [ + "END-08" ], - "3.13.4": [ - "SEA-05" + "3.PEP.UN.APPRO": [ + "END-08" ], - "3.1.9[a]": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "3.PEP.UN.IVERI": [ + "END-14.3" ], - "3.1.9[b]": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "3.PEP.UN.CTERM": [ + "END-14.4" ], - "3.2.1[a]": [ - "SAT-02" + "3.PEP.UN.LCTPR": [ + "END-14.5" ], - "3.2.1[b]": [ - "SAT-02" + "3.PEP.UN.MFPRO": [ + "END-14.5", + "END-14.6" ], - "3.2.1[c]": [ - "SAT-02" + "3.PEP.UN.MLPRO": [ + "END-14.5" ], - "3.2.1[d]": [ - "SAT-02" + "3.UNI.UATRA": [ + "HRS-01", + "HRS-02", + "HRS-02.1", + "HRS-03", + "HRS-03.1", + "SAT-01", + "SAT-02", + "SAT-03" ], - "3.13.2[b]": [ - "TDA-06" + "3.PEP.DA.ACONT": [ + "IAC-01" ], - "3.13.2[e]": [ - "TDA-06" + "3.PEP.ID.EIAMA": [ + "IAC-01" ], - "3.2.3[a]": [ - "THR-05" + "3.PEP.NE.ACONT": [ + "IAC-01", + "NET-01" ], - "3.2.3[b]": [ - "THR-05" + "3.PEP.SE.ACONT": [ + "IAC-01" ], - "3.14.1[a]": [ - "VPM-01" + "3.PEP.ID.EINVE": [ + "IAC-01.2", + "IAC-15.1", + "IAC-16.1" ], - "3.14.1[b]": [ - "VPM-01" + "3.UNI.SAUTH": [ + "IAC-01.2", + "IAC-06", + "WEB-06" ], - "3.14.1[c]": [ - "VPM-01" + "3.PEP.ID.SIDEN": [ + "IAC-04", + "IAC-05" ], - "3.14.1[d]": [ - "VPM-01" + "3.PEP.ID.MAUTH": [ + "IAC-06" ], - "3.14.1[e]": [ - "VPM-01" + "3.PEP.ID.SMANA": [ + "IAC-10", + "IAC-10.5", + "IAC-10.11" ], - "3.14.1[f]": [ - "VPM-01" + "3.PEP.ID.AAUTH": [ + "IAC-13" ], - "3.11.3[a]": [ - "VPM-02" + "3.PEP.IN.AACON": [ + "IAC-13" ], - "3.11.3[b]": [ - "VPM-02" + "3.PEP.ID.CAUTH": [ + "IAC-13.3" ], - "3.11.2[a]": [ - "VPM-06" + "3.UNI.LPRIV": [ + "IAC-21" ], - "3.11.2[b]": [ - "VPM-06" + "3.PEP.EM.E3AEP": [ + "IRO-15", + "NET-08" ], - "3.11.2[c]": [ - "VPM-06" + "3.PEP.EM.MFPRO": [ + "IRO-15", + "NET-20" ], - "3.11.2[d]": [ - "VPM-06" + "3.PEP.FI.DCHAM": [ + "IRO-15" ], - "3.11.2[e]": [ - "VPM-06" - ] - }, - "general-nist-800-171a-r3": { - "A.03.15.01.a[01]": [ - "GOV-02" + "3.UNI.SADMI": [ + "MNT-01", + "MNT-05.3", + "OPS-03" ], - "A.03.15.01.a[02]": [ - "GOV-02" + "3.PEP.RE.DDSPR": [ + "NET-02.1" ], - "A.03.15.01.a[03]": [ - "GOV-02", - "OPS-01.1" + "3.PEP.NE.NSEGM": [ + "NET-06" ], - "A.03.15.01.a[04]": [ - "GOV-02", - "OPS-01.1" + "3.PEP.NE.MICRO": [ + "NET-06.6" ], - "A.03.15.01.ODP[01]": [ - "GOV-03" + "3.PEP.IN.NDRES": [ + "NET-08" ], - "A.03.15.01.b[01]": [ - "GOV-03", - "OPS-01.1" + "3.PEP.NE.HCONT": [ + "NET-08.3" ], - "A.03.15.01.b[02]": [ - "GOV-03", - "OPS-01.1" + "3.PEP.NE.RCONT": [ + "NET-08.4" ], - "A.03.16.01": [ - "GOV-15", - "TDA-02.3" + "3.PEP.DO.DNVAC": [ + "NET-10.2", + "NET-18.5" ], - "A.03.04.08.c": [ - "AST-01.4" + "3.PEP.DO.DNVAD": [ + "NET-10.2" ], - "A.03.04.10.ODP[01]": [ - "AST-02" + "3.PEP.DO.DNMON": [ + "NET-10.4" ], - "A.03.04.10.a": [ - "AST-02" + "3.PEP.EN.RDACC": [ + "NET-14" ], - "A.03.04.10.b[01]": [ - "AST-02" + "3.PEP.EN.VPNET": [ + "NET-14", + "NET-14.3", + "NET-14.5", + "NET-14.6" ], - "A.03.04.10.b[02]": [ - "AST-02" + "3.PEP.DA.DLPRE": [ + "NET-17" ], - "A.03.04.10.c[01]": [ - "AST-02.1" + "3.PEP.EM.DLPRE": [ + "NET-17" ], - "A.03.04.10.c[02]": [ - "AST-02.1" + "3.PEP.FI.DLPRE": [ + "NET-17" ], - "A.03.04.10.c[03]": [ - "AST-02.1" + "3.PEP.SE.DLPRE": [ + "NET-17" ], - "A.03.04.11.a[01]": [ - "AST-02.8", - "DCH-24" + "3.PEP.UN.DLPRE": [ + "NET-17" ], - "A.03.04.11.a[02]": [ - "AST-02.8", - "IAO-03" + "3.PEP.WE.DLPRE": [ + "NET-17" ], - "A.03.04.11.a[03]": [ - "AST-02.8", - "IAO-03" + "3.PEP.DO.DNSIN": [ + "NET-18" ], - "A.03.04.11.b[01]": [ - "AST-02.8", - "CHG-05", - "IAO-03" + "3.PEP.DO.PDSER": [ + "NET-18" ], - "A.03.04.11.b[02]": [ - "AST-02.8", - "CHG-05", - "IAO-03" + "3.PEP.EM.CFILT": [ + "NET-18" ], - "A.03.09.02.a.03": [ - "AST-10", - "HRS-09", - "HRS-09.1" + "3.PEP.EM.MLPRO": [ + "NET-18" ], - "A.03.04.12.a": [ - "AST-24" + "3.PEP.SE.MCFIL": [ + "NET-18" ], - "A.03.04.12.b": [ - "AST-25" + "3.PEP.WE.CFILT": [ + "NET-18" ], - "A.03.08.09.a": [ - "BCD-11.4" + "3.PEP.WE.DCFIL": [ + "NET-18" ], - "A.03.08.09.b": [ - "BCD-11.4" + "3.PEP.WE.DREPF": [ + "NET-18" ], - "A.03.04.03.d[01]": [ - "CHG-01", - "CFG-02.2" + "3.PEP.WE.DRESF": [ + "NET-18" ], - "A.03.04.03.d[02]": [ - "CHG-01", - "CFG-02.2" + "3.PEP.WE.MCFIL": [ + "NET-18" ], - "A.03.04.03.a": [ - "CHG-02", - "CFG-01" + "3.PEP.WE.BINSP": [ + "NET-18.2" ], - "A.03.04.03.c[01]": [ - "CHG-02", - "MNT-02" + "3.PEP.SE.PCENF": [ + "NET-18.4" ], - "A.03.04.03.b[02]": [ - "CHG-02.1" + "3.PEP.WE.PCENF": [ + "NET-18.4" ], - "A.03.04.05[05]": [ - "CHG-02.1" + "3.PEP.NE.IADEN": [ + "NET-18.6" ], - "A.03.04.03.c[02]": [ - "CHG-02.2" + "3.PEP.WE.BCONT": [ + "NET-18.7" ], - "A.03.04.03.b[01]": [ - "CHG-03" + "3.PEP.WE.APROX": [ + "NET-18.8" ], - "A.03.04.04.a": [ - "CHG-03" + "3.PEP.WE.CDENY": [ + "NET-18.9" ], - "A.03.04.05[06]": [ - "CHG-04.4" + "3.PEP.FI.CDREC": [ + "NET-19" ], - "A.03.04.04.b": [ - "CHG-06" + "3.PE P.EM.EDRPR": [ + "NET-20.1" ], - "A.03.12.03[01]": [ - "CPL-02" + "3.PEP.EM.SDENY": [ + "NET-20.2" ], - "A.03.12.03[03]": [ - "CPL-02" + "3.PEP.EM.ARCHA": [ + "NET-20.3" ], - "A.03.12.03[04]": [ - "CPL-02" + "3.PEP.EM.DSVIE": [ + "NET-20.4" ], - "A.03.12.01.ODP[01]": [ - "CPL-02.1" + "3.PEP.EM.DSOEM": [ + "NET-20.5" ], - "A.03.12.01": [ - "CPL-03" + "3.PEP.EM.UDSOE": [ + "NET-20.5" ], - "A.03.12.03[02]": [ - "CPL-03.2" + "3.PEP.EM.EOEMA": [ + "NET-20.6" ], - "A.03.01.03[01]": [ - "CFG-02", - "END-01" + "3.PEP.EM.AEPRO": [ + "NET-20.7" ], - "A.03.01.16.a[03]": [ - "CFG-02" + "3.PEP.EM.ELABE": [ + "NET-20.8" ], - "A.03.01.16.c": [ - "CFG-02" + "3.PEP.EM.UTIPP": [ + "NET-20.9" ], - "A.03.01.18.a[02]": [ - "CFG-02" + "3.PEP.EN.CMONI": [ + "PRM-01", + "PRM-03" ], - "A.03.03.08.a[02]": [ - "CFG-02" + "3.UNL.RLMAN": [ + "PRM-07", + "SEA-07.1" ], - "A.03.04.01.a[01]": [ - "CFG-02" + "3 UNL.SCRMA": [ + "RSK-09" ], - "A.03.04.01.a[02]": [ - "CFG-02" + "3.PEP.IN.DPLAT": [ + "SEA-11" ], - "A.03.04.02.a[01]": [ - "CFG-02" + "3.PEP.EN.ACONT": [ + "SEA-21" ], - "A.03.04.02.a[02]": [ - "CFG-02" + "3.PEP.EN.SOARE": [ + "OPS-06" ], - "A.03.04.06.ODP[01]": [ - "CFG-02" + "3.PEP.EN.SITDE": [ + "OPS-07" ], - "A.03.04.06.ODP[02]": [ - "CFG-02" + "3.UNI.ETINT": [ + "THR-01", + "THR-03" ], - "A.03.04.06.ODP[03]": [ - "CFG-02" + "3.UNI.VMANG": [ + "THR-03", + "VPM-01", + "VPM-04", + "VPM-06" ], - "A.03.04.06.ODP[04]": [ - "CFG-02" + "3.UNI.PMANA": [ + "VPM-05" + ] + }, + "usa-federal-dhs-cisa-cpg-2-0": { + "1.B": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "A.03.04.06.ODP[05]": [ - "CFG-02" + "1.C": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "A.03.04.06.b[01]": [ - "CFG-02" + "4.A": [ + "GOV-06", + "IRO-10" ], - "A.03.04.06.b[02]": [ - "CFG-02" + "1.A": [ + "AST-01", + "AST-02", + "TPM-01.1" ], - "A.03.04.06.b[03]": [ - "CFG-02" + "2.P": [ + "AST-04", + "AST-04.2" ], - "A.03.04.06.b[04]": [ - "CFG-02" + "2.F": [ + "AST-27", + "NET-04", + "NET-04.1", + "NET-06" ], - "A.03.04.06.b[05]": [ - "CFG-02" + "5.A": [ + "BCD-01", + "BCD-02.1", + "BCD-02.2", + "IRO-01", + "IRO-02" ], - "A.03.05.04[01]": [ - "CFG-02", - "IAC-02.2" + "2.R": [ + "BCD-11", + "BCD-11.1", + "BCD-11.2" ], - "A.03.05.04[02]": [ - "CFG-02", - "IAC-02.2" + "2.Q": [ + "CHG-01", + "CFG-01", + "CFG-05", + "CFG-05.2", + "IAO-01", + "IAO-02", + "IAO-06", + "IAO-07" ], - "A.03.05.07.c": [ + "2.A": [ + "CFG-01", "CFG-02", - "IAC-10.5" + "IAC-10.8" ], - "A.03.05.07.d": [ + "2.O": [ + "CFG-01", "CFG-02", - "IAC-10.5" + "CFG-02.1", + "CFG-02.7" ], - "A.03.05.07.e": [ + "1.E": [ "CFG-02", - "IAC-15" + "RSK-06.2", + "SEA-01", + "SEA-03", + "VPM-01.1", + "VPM-02", + "VPM-04" ], - "A.03.05.07.f": [ + "2.B": [ "CFG-02", + "IAC-10", "IAC-10.1" ], - "A.03.07.05.b[02]": [ + "2.G": [ "CFG-02", - "IAC-02.2", - "MNT-05.3" - ], - "A.03.04.01.ODP[01]": [ - "CFG-02.1" + "MON-01.4", + "MON-02", + "MON-02.2", + "MON-16" ], - "A.03.04.01.b[01]": [ - "CFG-02.1" + "2.H": [ + "CFG-02", + "IAC-06" ], - "A.03.04.01.b[02]": [ - "CFG-02.1" + "2.K": [ + "CFG-02", + "CFG-02.1", + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "SEA-02.3" ], - "A.03.04.01.b[03]": [ - "CFG-02.1" + "2.N": [ + "CFG-02", + "END-10" ], - "A.03.04.01.b[04]": [ - "CFG-02.1" + "2.V": [ + "CFG-02", + "DCH-12", + "EMB-04" ], - "A.03.04.06.c": [ - "CFG-02.1" + "2.W": [ + "CFG-02.5", + "CFG-03", + "NET-04", + "NET-04.1" ], - "A.03.04.12.ODP[01]": [ - "CFG-02.5" + "2.X": [ + "CFG-02.5", + "NET-02", + "NET-04", + "NET-04.1", + "NET-06.5" ], - "A.03.04.12.ODP[02]": [ - "CFG-02.5" + "1.D": [ + "MON-01", + "MON-02.3", + "EMB-01", + "IRO-09", + "IRO-13", + "PRM-08", + "SAT-05" ], - "A.03.04.02.b[01]": [ - "CFG-02.7" + "2.T": [ + "MON-01", + "MON-01.3", + "MON-01.4", + "MON-01.8", + "MON-01.12", + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-02.3", + "MON-05" ], - "A.03.04.02.b[02]": [ - "CFG-02.7" + "2.U": [ + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-10" ], - "A.03.03.02.b": [ - "CFG-02.9", - "MON-03" + "2.L": [ + "DCH-01", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-03", + "IAC-01", + "IAC-08", + "IAC-10", + "IAC-10.1", + "IAC-10.11" ], - "A.03.04.02.ODP[01]": [ - "CFG-03" + "2.D": [ + "HRS-08", + "HRS-09", + "IAC-07", + "IAC-07.1", + "IAC-07.2" ], - "A.03.04.06.d": [ - "CFG-03" + "2.E": [ + "IAC-01", + "IAC-08", + "IAC-16" ], - "A.03.04.06.ODP[06]": [ - "CFG-03.1" + "2.C": [ + "IAC-10.9" ], - "A.03.04.08.ODP[01]": [ - "CFG-03.3" + "2.S": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-04.2", + "IRO-04.3", + "IRO-06" ], - "A.03.04.08.a": [ - "CFG-03.3" + "3.A": [ + "IRO-03", + "THR-01", + "THR-02", + "THR-03", + "THR-09" ], - "A.03.04.08.b": [ - "CFG-03.3" + "1.F": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.2", + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-07" ], - "A.03.13.13.b[03]": [ - "CFG-03.3", - "END-10" + "2.M": [ + "NET-10.3", + "NET-13", + "NET-18" ], - "A.03.01.02[01]": [ - "CFG-08" + "2.I": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.6" ], - "A.03.14.06.a.01[01]": [ - "MON-01" + "2.J": [ + "SAT-03", + "SAT-03.4", + "SAT-03.5" ], - "A.03.14.06.a.01[02]": [ - "MON-01" + "1.G": [ + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-05", + "TPM-05.1", + "THR-01" ], - "A.03.14.06.a.02": [ - "MON-01" + "1.H": [ + "TPM-01", + "TPM-01.1", + "TPM-03", + "TPM-03.3", + "TPM-04", + "TPM-05", + "TPM-05.7", + "TPM-08", + "THR-01" ], - "A.03.13.01.a[01]": [ - "MON-01.3" + "1.I": [ + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-10" ], - "A.03.13.01.a[03]": [ - "MON-01.3" + "4.B": [ + "THR-06", + "THR-06.1" ], - "A.03.14.06.c[01]": [ - "MON-01.3" + "4.C": [ + "THR-06.1" + ] + }, + "usa-federal-fbi-cjis-6-0": { + "5.1": [ + "GOV-01", + "DCH-14" ], - "A.03.14.06.c[02]": [ - "MON-01.3" + "5.1.1": [ + "GOV-01", + "DCH-14" ], - "A.03.03.02.a.01": [ - "MON-01.4" + "AC-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "A.03.03.03.a": [ - "MON-01.4" + "AT-1": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "A.03.03.01.ODP[02]": [ - "MON-01.8" + "AU-1": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "A.03.03.01.b[01]": [ - "MON-01.8" + "CA-1": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "A.03.03.05.ODP[01]": [ - "MON-01.8", - "MON-02" + "CM-1": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "A.03.03.05.a": [ - "MON-01.8", - "MON-02" + "CP-1": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "A.03.03.05.b": [ - "MON-01.12", - "MON-06" + "IA-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "A.03.03.05.c[01]": [ - "MON-02" + "IR-1": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "A.03.03.05.c[02]": [ - "MON-02.1" + "MA-1": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "A.03.03.01.ODP[01]": [ - "MON-03" + "MP-1": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "A.03.03.01.a": [ - "MON-03" + "PE-1": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "A.03.03.01.b[02]": [ - "MON-03" + "PL-1": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "A.03.03.02.a.02": [ - "MON-03" + "PS-1": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "A.03.03.02.a.03": [ - "MON-03" + "RA-1": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "A.03.03.02.a.04": [ - "MON-03" + "SA-1": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" ], - "A.03.03.02.a.05": [ - "MON-03" + "SC-1": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "A.03.03.02.a.06": [ - "MON-03" + "SI-1": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "A.03.01.07.b": [ - "MON-03.3" + "SR-1": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "A.03.03.04.ODP[01]": [ - "MON-05" + "PL-9": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" ], - "A.03.03.04.ODP[02]": [ - "MON-05" + "IR-6": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "A.03.03.04.a": [ - "MON-05" + "CM-8": [ + "AST-02", + "AST-02.3" ], - "A.03.03.04.b": [ - "MON-05" + "CM-8(1)": [ + "AST-02.1" ], - "A.03.03.06.a[01]": [ - "MON-06" + "CM-8(3)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" ], - "A.03.03.06.a[02]": [ - "MON-06" + "PL-2": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "A.03.03.06.a[03]": [ - "MON-06" + "SA-4(1)": [ + "AST-04", + "TDA-04.1" ], - "A.03.03.06.a[04]": [ - "MON-06" + "SA-4(2)": [ + "AST-04", + "TDA-04.1", + "TDA-20" ], - "A.03.03.07.ODP[01]": [ - "MON-07" + "SA-5": [ + "AST-04.1", + "TDA-04" ], - "A.03.03.07.a": [ - "MON-07" + "SR-12": [ + "AST-09" ], - "A.03.03.07.b[01]": [ - "MON-07" + "5.20.1.3": [ + "AST-14.1" ], - "A.03.03.07.b[02]": [ - "MON-07.1" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "A.03.03.03.b": [ - "MON-08", - "MON-10" + "CP-2": [ + "BCD-01", + "BCD-06" ], - "A.03.03.06.b[01]": [ - "MON-08" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "A.03.03.06.b[02]": [ - "MON-08" + "CP-2(1)": [ + "BCD-01.1" ], - "A.03.03.08.a[01]": [ - "MON-08" + "CP-2(8)": [ + "BCD-02" ], - "A.03.03.08.b": [ - "MON-08", - "MON-08.2" + "CP-2(3)": [ + "BCD-02.1", + "BCD-02.3" ], - "A.03.14.06.b": [ - "MON-16" + "CP-3": [ + "BCD-03" ], - "A.03.13.08[01]": [ - "CRY-01", - "CRY-03" + "CP-4": [ + "BCD-04", + "BCD-05" ], - "A.03.13.08[02]": [ - "CRY-01", - "CRY-05" + "CP-4(1)": [ + "BCD-04.1" ], - "A.03.13.11.ODP[01]": [ - "CRY-01", - "CRY-03", - "CRY-05" + "CP-6": [ + "BCD-08" ], - "A.03.13.11": [ - "CRY-01", - "CRY-03", - "CRY-05" + "CP-6(1)": [ + "BCD-08.1" ], - "A.03.13.10.ODP[01]": [ - "CRY-09" + "CP-6(3)": [ + "BCD-08.2" ], - "A.03.13.10[01]": [ - "CRY-09" + "CP-7": [ + "BCD-09" ], - "A.03.13.10[02]": [ - "CRY-09" + "CP-7(1)": [ + "BCD-09.1" ], - "A.03.15.02.c": [ - "DCH-01.4", - "DCH-03.1", - "IAO-03" + "CP-7(2)": [ + "BCD-09.2" ], - "A.03.17.01.c": [ - "DCH-01.4", - "DCH-03.1", - "RSK-09" + "CP-7(3)": [ + "BCD-09.3" ], - "A.03.08.02": [ - "DCH-03" + "CP-8": [ + "BCD-10" ], - "A.03.08.04[01]": [ - "DCH-04" + "CP-8(2)": [ + "BCD-10" ], - "A.03.08.04[02]": [ - "DCH-04" + "CP-8(1)": [ + "BCD-10.1" ], - "A.03.08.04[03]": [ - "DCH-04" + "CP-9": [ + "BCD-11" ], - "A.03.08.01[01]": [ - "DCH-06" + "CP-9(1)": [ + "BCD-11.1" ], - "A.03.08.01[02]": [ - "DCH-06" + "CP-9(8)": [ + "BCD-11.4" ], - "A.03.08.05.a[01]": [ - "DCH-07" + "SC-28(1)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" ], - "A.03.08.05.a[02]": [ - "DCH-07" + "CP-10(2)": [ + "BCD-12.1" ], - "A.03.08.05.b": [ - "DCH-07" + "SC-5": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "A.03.08.05.c": [ - "DCH-07" + "CM-3": [ + "CHG-01", + "CHG-02" ], - "A.03.08.03": [ - "DCH-09" + "CM-3(2)": [ + "CHG-02.2", + "CHG-06" ], - "A.03.08.07.ODP[01]": [ - "DCH-10" + "CM-3(4)": [ + "CHG-02.3" ], - "A.03.08.07.a": [ - "DCH-10" + "CM-4": [ + "CHG-03" ], - "A.03.08.07.b": [ - "DCH-10.2" + "CM-5": [ + "CHG-04", + "END-03.2" ], - "A.03.01.20.ODP[01]": [ - "DCH-13" + "AC-5": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "A.03.01.20.a": [ - "DCH-13" + "CM-9": [ + "CHG-05", + "CFG-01" ], - "A.03.01.20.b": [ - "DCH-13" + "4.1.1": [ + "CPL-01", + "DCH-02" ], - "A.03.01.20.c.01": [ - "DCH-13" + "4.2.1": [ + "CPL-01", + "DCH-02" ], - "A.03.01.20.c.02": [ - "DCH-13" + "4.2.2": [ + "CPL-01", + "DCH-02", + "PRI-05", + "PRI-05.1", + "PRI-05.4" ], - "A.03.01.20.d": [ - "DCH-13.2" + "4.3": [ + "CPL-01", + "DCH-02", + "PRI-05", + "PRI-05.1", + "PRI-05.4" ], - "A.03.01.22.a": [ - "DCH-15" + "CA-7": [ + "CPL-02" ], - "A.03.01.22.b[01]": [ - "DCH-15" + "CA-7(1)": [ + "CPL-02", + "CPL-03.1" ], - "A.03.01.22.b[02]": [ - "DCH-15", - "IRO-12" + "CA-2": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "A.03.14.08[01]": [ - "DCH-18" + "RA-3": [ + "CPL-03.2", + "RSK-04" ], - "A.03.14.08[02]": [ - "DCH-18" + "CM-2": [ + "CFG-02", + "CFG-02.1" ], - "A.03.14.08[03]": [ - "DCH-18" + "CM-6": [ + "CFG-02", + "CFG-02.7" ], - "A.03.14.08[04]": [ - "DCH-18" + "PL-10": [ + "CFG-02" ], - "A.03.14.02.ODP[01]": [ - "END-04" + "SA-8": [ + "CFG-02", + "SEA-01" ], - "A.03.14.02.a[01]": [ - "END-04" + "CM-2(2)": [ + "CFG-02.2" ], - "A.03.14.02.a[02]": [ - "END-04" + "CM-2(3)": [ + "CFG-02.3" ], - "A.03.14.02.c.02": [ - "END-04" + "CM-2(7)": [ + "CFG-02.5" ], - "A.03.14.02.b": [ - "END-04.1" + "PL-11": [ + "CFG-02.9" ], - "A.03.14.02.c.01[01]": [ - "END-04.7" + "CM-7": [ + "CFG-03" ], - "A.03.14.02.c.01[02]": [ - "END-04.7" + "CM-7(1)": [ + "CFG-03.1" ], - "A.03.13.13.a[01]": [ - "END-10" + "CM-7(2)": [ + "CFG-03.2", + "SEA-06" ], - "A.03.13.13.a[02]": [ - "END-10" + "CM-7(5)": [ + "CFG-03.3" ], - "A.03.13.13.b[01]": [ - "END-10" + "SC-7(7)": [ + "CFG-03.4" ], - "A.03.13.13.b[02]": [ - "END-10" + "CM-10": [ + "CFG-04" ], - "A.03.13.12.ODP[01]": [ - "END-14" + "CM-11": [ + "CFG-05", + "END-03" ], - "A.03.13.12.a": [ - "END-14" + "SI-4": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "A.03.13.12.b": [ - "END-14.6" + "SI-4(2)": [ + "MON-01.2" ], - "A.03.01.01.ODP[01]": [ - "HRS-01", - "IAC-15" + "SI-4(4)": [ + "MON-01.3" ], - "A.03.01.01.ODP[02]": [ - "HRS-01" + "SI-4(5)": [ + "MON-01.4" ], - "A.03.01.01.ODP[03]": [ - "HRS-01" + "AU-2": [ + "MON-01.8", + "MON-02" ], - "A.03.01.01.ODP[04]": [ - "HRS-01" + "AU-6": [ + "MON-02", + "MON-02.6" ], - "A.03.06.05.d": [ - "HRS-03", - "IAC-08", - "IAC-20.1", - "IRO-04" + "AU-6(3)": [ + "MON-02.1" ], - "A.03.09.01.ODP[01]": [ - "HRS-04", - "HRS-04.1" + "AU-3": [ + "MON-03" ], - "A.03.09.01.a": [ - "HRS-04" + "AU-3(1)": [ + "MON-03.1" ], - "A.03.09.01.b": [ - "HRS-04" + "AU-6(1)": [ + "MON-03.1" ], - "A.03.09.02.b.01[01]": [ - "HRS-04", - "HRS-08" + "AU-3(3)": [ + "MON-03.5" ], - "A.03.15.03.b": [ - "HRS-05" + "AU-4": [ + "MON-04" ], - "A.03.15.03.ODP[01]": [ - "HRS-05.1" + "AU-5": [ + "MON-05" ], - "A.03.15.03.a": [ - "HRS-05.1", - "HRS-05.2", - "HRS-05.3", - "HRS-05.5" + "AU-7": [ + "MON-06" ], - "A.03.15.03.d[01]": [ - "HRS-05.1" + "AU-7(1)": [ + "MON-06" ], - "A.03.15.03.d[02]": [ - "HRS-05.1" + "AU-12": [ + "MON-06" ], - "A.03.15.03.c": [ - "HRS-05.7" + "AU-8": [ + "MON-07", + "SEA-20" ], - "A.03.09.02.ODP[01]": [ - "HRS-08", - "HRS-09" + "AU-9": [ + "MON-08" ], - "A.03.09.02.b.01[02]": [ - "HRS-08" + "AU-9(4)": [ + "MON-08.2" ], - "A.03.09.02.b.02": [ - "HRS-08" + "AU-11": [ + "MON-10" ], - "A.03.09.02.a.01": [ - "HRS-09" + "SC-8(1)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" ], - "A.03.09.02.a.02[01]": [ - "HRS-09" + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" ], - "A.03.09.02.a.02[02]": [ - "HRS-09" + "IA-7": [ + "CRY-02", + "IAC-12" ], - "A.03.01.04.a": [ - "HRS-11" + "SC-8": [ + "CRY-03", + "CRY-04" ], - "A.03.01.01.d.01": [ - "IAC-01.2" + "SC-28": [ + "CRY-05", + "END-02" ], - "A.03.01.01.d.02": [ - "IAC-01.2" + "AC-18": [ + "CRY-07", + "NET-15" ], - "A.03.01.16.b": [ - "IAC-01.2", - "NET-02.2" + "SC-12": [ + "CRY-08" ], - "A.03.05.01.a[01]": [ - "IAC-01.2" + "SC-17": [ + "CRY-08" ], - "A.03.05.01.a[02]": [ - "IAC-01.2" + "4.2.3.1": [ + "DCH-01", + "PRI-05", + "PRI-05.1", + "PRI-05.4" ], - "A.03.05.01.a[03]": [ - "IAC-02" + "4.2.3.3": [ + "DCH-01.1", + "DCH-03.1" ], - "A.03.05.05.d": [ - "IAC-02", - "IAC-09.2" + "4.2.4": [ + "DCH-01.2" ], - "A.03.05.02.ODP[01]": [ - "IAC-04" + "MP-2": [ + "DCH-03", + "END-01" ], - "A.03.05.02[01]": [ - "IAC-04" + "MP-3": [ + "DCH-04", + "DCH-04.1" ], - "A.03.05.02[02]": [ - "IAC-04" + "MP-4": [ + "DCH-06" ], - "A.03.05.03[01]": [ - "IAC-06", - "IAC-06.4" + "MP-5": [ + "DCH-07" ], - "A.03.05.03[02]": [ - "IAC-06", - "IAC-06.4" + "MP-6": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "A.03.07.05.b[01]": [ - "IAC-06" + "MP-7": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "A.03.01.01.b[01]": [ - "IAC-07", - "IAC-15.7" + "AC-20": [ + "DCH-13" ], - "A.03.01.01.b[02]": [ - "IAC-07", - "IAC-15.7" + "AC-20(1)": [ + "DCH-13.1" ], - "A.03.01.01.b[03]": [ - "IAC-07", - "IAC-15.7" + "AC-20(2)": [ + "DCH-13.2" ], - "A.03.01.01.b[04]": [ - "IAC-07", - "IAC-15.7" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "A.03.01.01.b[05]": [ - "IAC-07", - "IAC-15.7" + "AC-22": [ + "DCH-15" ], - "A.03.05.05.a": [ - "IAC-07" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "A.03.01.01.c.02": [ - "IAC-08" + "SI-12(1)": [ + "DCH-18.1", + "PRI-05.1" ], - "A.03.01.01.c.03": [ - "IAC-08" + "SI-12(2)": [ + "DCH-18.2", + "PRI-05.1" ], - "A.03.01.05.ODP[01]": [ - "IAC-08" + "SI-12(3)": [ + "DCH-21", + "PRI-05" ], - "A.03.01.05.ODP[02]": [ - "IAC-08" + "CM-12": [ + "DCH-24" ], - "A.03.01.05.b[01]": [ - "IAC-08", - "IAC-20.1" + "CM-12(1)": [ + "DCH-24.1" ], - "A.03.01.05.b[02]": [ - "IAC-08", - "IAC-20.1" + "5.20.4.3": [ + "END-02" ], - "A.03.04.05[04]": [ - "IAC-08" + "SI-3": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "A.03.05.05.ODP[01]": [ - "IAC-09" + "SI-2": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "A.03.05.05.b[01]": [ - "IAC-09" + "SI-7": [ + "END-06", + "NET-12", + "TDA-18" ], - "A.03.05.05.b[02]": [ - "IAC-09" + "SI-7(1)": [ + "END-06.1" ], - "A.03.05.05.c": [ - "IAC-09" + "SI-7(7)": [ + "END-06.2" ], - "A.03.05.05.ODP[02]": [ - "IAC-09.2" + "SI-8": [ + "END-08" ], - "A.03.05.12.ODP[01]": [ - "IAC-10" + "SI-8(2)": [ + "END-08.2" ], - "A.03.05.12.ODP[02]": [ - "IAC-10" + "SC-18": [ + "END-10" ], - "A.03.05.12.a": [ - "IAC-10" + "SC-15": [ + "END-14" ], - "A.03.05.12.b": [ - "IAC-10" + "PS-2": [ + "HRS-02", + "HRS-03.2" ], - "A.03.05.12.c[01]": [ - "IAC-10" + "PS-9": [ + "HRS-03" ], - "A.03.05.12.c[02]": [ - "IAC-10" + "PS-3": [ + "HRS-04" ], - "A.03.05.12.c[03]": [ - "IAC-10" + "PL-4": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "A.03.05.12.c[04]": [ - "IAC-10" + "PL-4(1)": [ + "HRS-05.2" ], - "A.03.05.12.c[05]": [ - "IAC-10" + "PS-6": [ + "HRS-06", + "HRS-06.1" ], - "A.03.05.12.c[06]": [ - "IAC-10" + "PS-8": [ + "HRS-07" ], - "A.03.05.12.d": [ - "IAC-10" + "PS-5": [ + "HRS-08" ], - "A.03.05.12.e": [ - "IAC-10" + "PS-4": [ + "HRS-09" ], - "A.03.05.12.f[01]": [ - "IAC-10", - "IAC-10.5" + "AC-2(13)": [ + "HRS-09.2", + "IAC-15.6" ], - "A.03.05.12.f[02]": [ - "IAC-10", - "IAC-10.5" + "PS-7": [ + "HRS-10" ], - "A.03.05.07.ODP[02]": [ - "IAC-10.1" + "IA-4": [ + "IAC-01.2", + "IAC-09" ], - "A.03.05.07.ODP[01]": [ - "IAC-10.4", - "IAC-10.11" + "IA-4(4)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "A.03.05.07.a[01]": [ - "IAC-10.4", - "IAC-10.11" + "IA-2": [ + "IAC-02" ], - "A.03.05.07.a[02]": [ - "IAC-10.4", - "IAC-10.11" + "IA-2(8)": [ + "IAC-02.2" ], - "A.03.05.07.a[03]": [ - "IAC-10.4", - "IAC-10.11" + "IA-2(12)": [ + "IAC-02.3" ], - "A.03.05.07.b": [ - "IAC-10.4", - "IAC-10.11" + "IA-8": [ + "IAC-03" ], - "A.03.05.11": [ - "IAC-11" + "IA-8(1)": [ + "IAC-03.1" ], - "A.03.05.01.ODP[01]": [ - "IAC-14" + "IA-8(2)": [ + "IAC-03.2" ], - "A.03.05.01.b": [ - "IAC-14" + "IA-8(4)": [ + "IAC-03.3" ], - "A.03.01.01.a[01]": [ - "IAC-15", - "IAC-15.7" + "IA-3": [ + "IAC-04" ], - "A.03.01.01.a[02]": [ - "IAC-15", - "IAC-15.7" + "IA-2(1)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "A.03.01.01.c.01": [ + "IA-2(2)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" + ], + "AC-2": [ + "IAC-07.2", "IAC-15", - "IAC-15.7" + "NET-12", + "TDA-18" ], - "A.03.01.01.e": [ - "IAC-15" + "IA-5": [ + "IAC-10", + "IAC-10.8" ], - "A.03.01.01.f.01": [ - "IAC-15" + "IA-5(1)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "A.03.01.01.f.02": [ - "IAC-15", - "IAC-15.3" + "IA-5(2)": [ + "IAC-10.2" ], - "A.03.01.01.f.03": [ - "IAC-15" + "IA-5(6)": [ + "IAC-10.5", + "IAC-18" ], - "A.03.01.01.f.04": [ - "IAC-15" + "IA-6": [ + "IAC-11" ], - "A.03.01.01.f.05": [ - "IAC-15" + "IA-11": [ + "IAC-14" ], - "A.03.01.01.g.01": [ - "IAC-15" + "AC-2(1)": [ + "IAC-15.1" ], - "A.03.01.01.g.02": [ - "IAC-15" + "AC-2(2)": [ + "IAC-15.2" ], - "A.03.01.01.g.03": [ - "IAC-15" + "AC-2(3)": [ + "IAC-15.3" ], - "A.03.01.05.ODP[03]": [ - "IAC-17" + "AC-2(4)": [ + "IAC-15.4" ], - "A.03.01.05.c": [ + "AC-6(7)": [ "IAC-17" ], - "A.03.01.05.d": [ - "IAC-17" + "AC-3": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "A.03.01.02[02]": [ + "AC-6": [ + "IAC-20", "IAC-21" ], - "A.03.01.05.a": [ - "IAC-21" + "AC-6(1)": [ + "IAC-21.1" ], - "A.03.01.06.b": [ + "AC-6(2)": [ "IAC-21.2" ], - "A.03.01.06.ODP[01]": [ + "AC-6(5)": [ "IAC-21.3" ], - "A.03.01.06.a": [ - "IAC-21.3" + "AC-6(9)": [ + "IAC-21.4" ], - "A.03.01.07.a": [ + "AC-6(10)": [ "IAC-21.5" ], - "A.03.01.08.ODP[01]": [ - "IAC-22" - ], - "A.03.01.08.ODP[02]": [ - "IAC-22" - ], - "A.03.01.08.ODP[03]": [ - "IAC-22" - ], - "A.03.01.08.ODP[04]": [ - "IAC-22" - ], - "A.03.01.08.a": [ - "IAC-22" - ], - "A.03.01.08.b": [ + "AC-7": [ "IAC-22" ], - "A.03.01.10.ODP[01]": [ - "IAC-24" - ], - "A.03.01.10.ODP[02]": [ - "IAC-24" - ], - "A.03.01.10.a": [ + "AC-2(5)": [ "IAC-24" ], - "A.03.01.10.b": [ + "AC-11": [ "IAC-24" ], - "A.03.01.10.c": [ + "AC-11(1)": [ "IAC-24.1" ], - "A.03.01.01.ODP[05]": [ + "AC-12": [ "IAC-25" ], - "A.03.01.01.ODP[06]": [ - "IAC-25" + "AC-14": [ + "IAC-26" ], - "A.03.01.01.h": [ - "IAC-25" + "IA-12": [ + "IAC-28" ], - "A.03.01.11.ODP[01]": [ - "IAC-25" + "IA-12(2)": [ + "IAC-28.2" ], - "A.03.01.11": [ - "IAC-25" + "IA-12(3)": [ + "IAC-28.3" ], - "A.03.07.05.c[01]": [ - "IAC-25", - "MNT-05.4" + "IA-12(5)": [ + "IAC-28.5" ], - "A.03.06.01[01]": [ + "5.20.5": [ "IRO-01" ], - "A.03.06.01[02]": [ - "IRO-02" - ], - "A.03.06.01[03]": [ - "IRO-02" - ], - "A.03.06.01[04]": [ - "IRO-02" - ], - "A.03.06.01[05]": [ - "IRO-02" - ], - "A.03.06.01[06]": [ + "IR-4": [ "IRO-02" ], - "A.03.06.02.b": [ - "IRO-02", - "IRO-07", - "IRO-10" - ], - "A.03.06.02.ODP[01]": [ - "IRO-04", - "IRO-10" - ], - "A.03.06.02.ODP[02]": [ - "IRO-04", - "IRO-10.2", - "IRO-14" - ], - "A.03.06.05.a.01": [ - "IRO-04" - ], - "A.03.06.05.a.02": [ - "IRO-04" - ], - "A.03.06.05.a.03": [ - "IRO-04" - ], - "A.03.06.05.a.04": [ - "IRO-04" - ], - "A.03.06.05.a.05": [ - "IRO-04" - ], - "A.03.06.05.a.06": [ - "IRO-04" - ], - "A.03.06.05.b[01]": [ - "IRO-04" + "IR-4(1)": [ + "IRO-02.1" ], - "A.03.06.05.b[02]": [ + "IR-8": [ "IRO-04" ], - "A.03.06.05.c": [ - "IRO-04.2" - ], - "A.03.06.04.ODP[01]": [ - "IRO-05" + "IR-8(1)": [ + "IRO-04.1" ], - "A.03.06.04.ODP[02]": [ + "IR-2": [ "IRO-05" ], - "A.03.06.04.ODP[03]": [ + "IR-2(3)": [ "IRO-05" ], - "A.03.06.04.ODP[04]": [ - "IRO-05", - "IRO-13" + "IR-3": [ + "IRO-06" ], - "A.03.06.04.a.01": [ - "IRO-05", - "SAT-03" + "IR-3(2)": [ + "IRO-06.1" ], - "A.03.06.04.b[01]": [ - "IRO-05" + "IR-5": [ + "IRO-09" ], - "A.03.06.04.b[02]": [ - "IRO-05" + "IR-6(1)": [ + "IRO-10.1" ], - "A.03.06.04.b[03]": [ - "IRO-05" + "IR-6(3)": [ + "IRO-10.4" ], - "A.03.06.04.b[04]": [ - "IRO-05" + "IR-7": [ + "IRO-11" ], - "A.03.06.03.ODP[01]": [ - "IRO-06" + "IR-7(1)": [ + "IRO-11.1" ], - "A.03.06.03": [ - "IRO-06" + "CA-2(1)": [ + "IAO-02.1" ], - "A.03.06.02.d": [ - "IRO-07", - "IRO-10", - "IRO-11" + "CA-5": [ + "IAO-05" ], - "A.03.06.02.a[01]": [ - "IRO-09" + "CM-4(2)": [ + "IAO-06" ], - "A.03.06.02.a[02]": [ - "IRO-09" + "CA-6": [ + "IAO-07" ], - "A.03.06.02.c": [ - "IRO-10" + "MA-2": [ + "MNT-02" ], - "A.03.15.02.ODP[01]": [ - "IAO-03" + "MA-6": [ + "MNT-03" ], - "A.03.15.02.a.01": [ - "IAO-03" + "MA-3": [ + "MNT-04" ], - "A.03.15.02.a.02": [ - "IAO-03" + "MA-3(1)": [ + "MNT-04.1" ], - "A.03.15.02.a.03": [ - "IAO-03" + "MA-3(2)": [ + "MNT-04.2" ], - "A.03.15.02.a.04": [ - "IAO-03" + "MA-3(3)": [ + "MNT-04.3" ], - "A.03.15.02.a.05": [ - "IAO-03" + "MA-4": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "A.03.15.02.a.06": [ - "IAO-03" + "MA-5": [ + "MNT-06" ], - "A.03.15.02.a.07": [ - "IAO-03" + "5.20": [ + "MDM-01" ], - "A.03.15.02.a.08": [ - "IAO-03" + "5.20.1.2": [ + "MDM-01" ], - "A.03.15.02.b[01]": [ - "IAO-03" + "5.20.1.4": [ + "MDM-01" ], - "A.03.15.02.b[02]": [ - "IAO-03" + "5.20.2": [ + "MDM-01" ], - "A.03.12.02.a.01": [ - "IAO-05" + "5.20.3": [ + "MDM-01" ], - "A.03.12.02.a.02": [ - "IAO-05" + "5.20.4": [ + "MDM-01" ], - "A.03.12.02.b.01": [ - "IAO-05" + "5.20.4.2": [ + "MDM-01" ], - "A.03.12.02.b.02": [ - "IAO-05" + "5.20.6": [ + "MDM-01" ], - "A.03.12.02.b.03": [ - "IAO-05" + "5.20.7": [ + "MDM-01" ], - "A.03.07.04.a[01]": [ - "MNT-04" + "5.20.7.1": [ + "MDM-01" ], - "A.03.07.04.a[02]": [ - "MNT-04" + "5.20.7.2": [ + "MDM-01" ], - "A.03.07.04.a[03]": [ - "MNT-04" + "5.20.7.3": [ + "MDM-01" ], - "A.03.07.04.b": [ - "MNT-04.2" + "AC-19": [ + "MDM-02" ], - "A.03.07.04.c": [ - "MNT-04.3" + "AC-19(5)": [ + "MDM-03" ], - "A.03.07.05.a[01]": [ - "MNT-05" + "SC-7": [ + "NET-03" ], - "A.03.07.05.a[02]": [ - "MNT-05" + "SC-7(3)": [ + "NET-03.1" ], - "A.03.07.06.a": [ - "MNT-06" + "SC-7(4)": [ + "NET-03.2" ], - "A.03.07.06.b": [ - "MNT-06" + "AC-4": [ + "NET-04" ], - "A.03.07.06.c": [ - "MNT-06", - "MNT-06.1", - "MNT-06.2" + "SC-7(5)": [ + "NET-04.1" ], - "A.03.07.06.d[01]": [ - "MNT-06" + "CA-3": [ + "NET-05" ], - "A.03.07.06.d[02]": [ - "MNT-06" + "CA-9": [ + "NET-05.2" ], - "A.03.01.18.a[01]": [ - "MDM-01" + "SC-10": [ + "NET-07" ], - "A.03.01.18.b": [ - "MDM-02" + "SC-23": [ + "NET-09" ], - "A.03.01.18.c": [ - "MDM-03" + "SC-20": [ + "NET-10" ], - "A.03.01.16.a[01]": [ - "NET-02.2", - "NET-15" + "SC-22": [ + "NET-10.1" ], - "A.03.01.16.a[02]": [ - "NET-02.2", - "NET-15" + "SC-21": [ + "NET-10.2" ], - "A.03.01.16.a[04]": [ - "NET-02.2", - "NET-15" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "A.03.01.18.a[03]": [ - "NET-03" + "SI-10": [ + "NET-12", + "TDA-18" ], - "A.03.13.01.a[02]": [ - "NET-03" + "AC-17": [ + "NET-14" ], - "A.03.13.01.a[04]": [ - "NET-03" + "AC-17(1)": [ + "NET-14.1" ], - "A.03.13.01.c": [ - "NET-03" + "AC-17(2)": [ + "NET-14.2" ], - "A.03.01.03[02]": [ - "NET-04", - "NET-05" + "AC-17(3)": [ + "NET-14.3" ], - "A.03.13.06[01]": [ - "NET-04.1" + "AC-17(4)": [ + "NET-14.4" ], - "A.03.13.06[02]": [ - "NET-04.1" + "5.20.1": [ + "NET-15" ], - "A.03.12.05.ODP[01]": [ - "NET-05" + "5.20.1.1": [ + "NET-15" ], - "A.03.12.05.ODP[02]": [ - "NET-05" + "AC-18(1)": [ + "NET-15.1" ], - "A.03.12.05.a[01]": [ - "NET-05" + "AC-18(3)": [ + "NET-15.2" ], - "A.03.12.05.a[02]": [ - "NET-05" + "SC-7(8)": [ + "NET-18", + "NET-18.1" ], - "A.03.12.05.b[01]": [ - "NET-05" + "PE-2": [ + "PES-02" ], - "A.03.12.05.b[02]": [ - "NET-05" + "PE-3": [ + "PES-03" ], - "A.03.12.05.b[03]": [ - "NET-05" + "PE-8": [ + "PES-03.3" ], - "A.03.12.05.c[01]": [ - "NET-05" + "PE-6": [ + "PES-05" ], - "A.03.12.05.c[02]": [ - "NET-05" + "PE-6(1)": [ + "PES-05.1" ], - "A.03.13.01.b": [ - "NET-06" + "PE-8(3)": [ + "PES-06.5" ], - "A.03.07.05.c[02]": [ - "NET-07" + "PE-9": [ + "PES-07" ], - "A.03.13.09.ODP[01]": [ - "NET-07" + "PE-10": [ + "PES-07.2" ], - "A.03.13.09": [ - "NET-07" + "PE-11": [ + "PES-07.3" ], - "A.03.13.15": [ - "NET-09" + "PE-12": [ + "PES-07.4" ], - "A.03.01.12.a[01]": [ - "NET-14" + "PE-15": [ + "PES-07.5" ], - "A.03.01.12.a[02]": [ - "NET-14" + "PE-13": [ + "PES-08" ], - "A.03.01.12.a[03]": [ - "NET-14" + "PE-13(1)": [ + "PES-08.1" ], - "A.03.01.12.a[04]": [ - "NET-14" + "PE-14": [ + "PES-09" ], - "A.03.01.12.b": [ - "NET-14" + "PE-16": [ + "PES-10" ], - "A.03.01.12.c[01]": [ - "NET-14" + "PE-17": [ + "PES-11" ], - "A.03.01.12.c[02]": [ - "NET-14" + "PE-4": [ + "PES-12.1" ], - "A.03.01.12.d[1]": [ - "NET-14", - "NET-14.4" + "PE-5": [ + "PES-12.2" ], - "A.03.01.12.d[2]": [ - "NET-14", - "NET-14.4" + "4.2.3.2": [ + "PRI-05", + "PRI-05.1", + "PRI-05.4" ], - "A.03.10.06.ODP[01]": [ - "NET-14.5", - "PES-11" + "AC-3(14)": [ + "PRI-06" ], - "A.03.10.06.a": [ - "NET-14.5", - "PES-11" + "SA-2": [ + "PRM-03" ], - "A.03.10.06.b": [ - "NET-14.5", - "PES-11" + "RA-9": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "A.03.01.16.d[01]": [ - "NET-15.1" + "SA-3": [ + "PRM-07", + "SEA-07.1" ], - "A.03.01.16.d[02]": [ - "NET-15.1" + "RA-2": [ + "RSK-02" ], - "A.03.04.05[02]": [ - "PES-02" + "RA-7": [ + "RSK-06.1" ], - "A.03.10.01.ODP[01]": [ - "PES-02", - "PES-02.1" + "5.20.7.2.1": [ + "RSK-06.2" ], - "A.03.10.01.a[01]": [ - "PES-02" + "SR-2": [ + "RSK-09", + "TPM-03" ], - "A.03.10.01.a[02]": [ - "PES-02" + "CA-7(4)": [ + "RSK-11" ], - "A.03.10.01.a[03]": [ - "PES-02" + "PL-8": [ + "SEA-02" ], - "A.03.10.01.c": [ - "PES-02" + "SC-2": [ + "SEA-03.2" ], - "A.03.10.01.d": [ - "PES-02" + "SC-4": [ + "SEA-05" ], - "A.03.10.07.a.01": [ - "PES-02" + "SI-16": [ + "SEA-10" ], - "A.03.04.05[01]": [ - "PES-02.1" + "AC-8": [ + "SEA-18" ], - "A.03.10.01.b": [ - "PES-02.1" + "5.1.2": [ + "OPS-03" ], - "A.03.04.05[03]": [ - "PES-03" + "AT-2": [ + "SAT-02" ], - "A.03.10.07.a.02": [ - "PES-03" + "AT-2(3)": [ + "SAT-02.2" ], - "A.03.10.07.d": [ - "PES-03" + "AT-3": [ + "SAT-03" ], - "A.03.10.07.b": [ - "PES-03.3" + "AT-3(5)": [ + "SAT-03.3" ], - "A.03.10.02.ODP[01]": [ - "PES-05" + "AT-4": [ + "SAT-04" ], - "A.03.10.02.ODP[02]": [ - "PES-05" + "SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "A.03.10.02.a[01]": [ - "PES-05" + "SA-4(9)": [ + "TDA-02.1" ], - "A.03.10.02.a[02]": [ - "PES-05" + "SA-4(10)": [ + "TDA-02.2" ], - "A.03.10.02.b[01]": [ - "PES-05" + "SA-15": [ + "TDA-06" ], - "A.03.10.02.b[02]": [ - "PES-05" + "SA-11": [ + "TDA-09" ], - "A.03.10.07.c[01]": [ - "PES-06", - "PES-06.1", - "PES-06.3" + "SA-10": [ + "TDA-14" ], - "A.03.10.07.c[02]": [ - "PES-06", - "PES-06.1", - "PES-06.3" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "A.03.10.08": [ - "PES-12.1" + "SI-11": [ + "TDA-19" ], - "A.03.10.07.e": [ - "PES-12.2" + "SR-2(1)": [ + "TPM-03" ], - "A.03.17.03.b": [ - "RSK-01", - "RSK-09" + "SR-5": [ + "TPM-03.1" ], - "A.03.11.01.a": [ - "RSK-01.1", - "RSK-03", - "RSK-03.1", - "RSK-04", - "RSK-09" + "SA-9": [ + "TPM-04" ], - "A.03.11.01.b": [ - "RSK-04", - "RSK-07" + "SA-9(2)": [ + "TPM-04.2" ], - "A.03.11.04[01]": [ - "RSK-06.1" + "SR-8": [ + "TPM-05.1" ], - "A.03.11.04[02]": [ - "RSK-06.1" + "AT-2(2)": [ + "THR-05" ], - "A.03.11.04[03]": [ - "RSK-06.1" + "RA-5(11)": [ + "THR-06" ], - "A.03.11.01.ODP[01]": [ - "RSK-07" + "5.20.4.1": [ + "VPM-05" ], - "A.03.17.01.ODP[01]": [ - "RSK-09" + "SI-2(2)": [ + "VPM-05.2" ], - "A.03.17.01.a[01]": [ - "RSK-09" + "RA-5": [ + "VPM-06", + "VPM-06.1" ], - "A.03.17.01.a[02]": [ - "RSK-09" + "RA-5(2)": [ + "VPM-06.1" ], - "A.03.17.01.a[03]": [ - "RSK-09" + "RA-5(5)": [ + "VPM-06.3" + ] + }, + "usa-federal-doe-c2m2-2-1": { + "PROGRAM-1f": [ + "GOV-01" ], - "A.03.17.01.a[04]": [ - "RSK-09" + "PROGRAM-1g": [ + "GOV-01", + "CPL-01" ], - "A.03.17.01.a[05]": [ - "RSK-09" + "PROGRAM-2b": [ + "GOV-01" ], - "A.03.17.01.a[06]": [ - "RSK-09" + "PROGRAM-2i": [ + "GOV-01" ], - "A.03.17.01.a[07]": [ - "RSK-09" + "RISK-1f": [ + "GOV-01.1", + "PRM-01" ], - "A.03.17.01.a[08]": [ - "RSK-09" + "PROGRAM-2a": [ + "GOV-01.1" ], - "A.03.17.01.a[09]": [ - "RSK-09" + "PROGRAM-2c": [ + "GOV-01.1" ], - "A.03.17.01.a[10]": [ - "RSK-09" + "PROGRAM-2d": [ + "GOV-01.1" ], - "A.03.17.01.b[01]": [ - "RSK-09" + "PROGRAM-2g": [ + "GOV-01.2", + "GOV-05" ], - "A.03.17.01.b[02]": [ - "RSK-09" + "ASSET-5c": [ + "GOV-02" ], - "A.03.17.03.ODP[01]": [ - "RSK-09", - "TPM-01" + "THREAT-3c": [ + "GOV-02" ], - "A.03.17.03.a[01]": [ - "RSK-09", - "TPM-04.1" + "RISK-5c": [ + "GOV-02" ], - "A.03.17.03.a[02]": [ - "RSK-09" + "ACCESS-4c": [ + "GOV-02" ], - "A.03.16.01.ODP[01]": [ - "SEA-01", - "TDA-01", - "TDA-02.3" + "SITUATION-4c": [ + "GOV-02" ], - "A.03.13.04[01]": [ - "SEA-05" + "RESPONSE-5c": [ + "GOV-02" ], - "A.03.13.04[02]": [ - "SEA-05" + "THIRD-PARTIES-3c": [ + "GOV-02" ], - "A.03.01.09": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "WORKFORCE-5c": [ + "GOV-02" ], - "A.03.02.01.ODP[01]": [ - "SAT-01" + "ARCHITECTURE-6c": [ + "GOV-02" ], - "A.03.02.01.ODP[02]": [ - "SAT-01" + "PROGRAM-3c": [ + "GOV-02" ], - "A.03.02.01.a.01[01]": [ - "SAT-01" + "PROGRAM-1h": [ + "GOV-03" ], - "A.03.02.01.a.01[02]": [ - "SAT-01" + "ASSET-5d": [ + "GOV-04" ], - "A.03.02.01.ODP[03]": [ - "SAT-02" + "THREAT-3d": [ + "GOV-04" ], - "A.03.02.01.ODP[04]": [ - "SAT-02" + "RISK-5d": [ + "GOV-04" ], - "A.03.02.01.a.03[03]": [ - "SAT-02" + "ACCESS-4d": [ + "GOV-04" ], - "A.03.02.01.a.03[04]": [ - "SAT-02" + "SITUATION-4d": [ + "GOV-04" ], - "A.03.02.01.a.03[05]": [ - "SAT-02" + "RESPONSE-5d": [ + "GOV-04" ], - "A.03.02.01.a.03[06]": [ - "SAT-02" + "THIRD-PARTIES-3d": [ + "GOV-04" ], - "A.03.02.02.ODP[01]": [ - "SAT-03" + "WORKFORCE-5d": [ + "GOV-04" ], - "A.03.02.02.ODP[02]": [ - "SAT-03" + "ARCHITECTURE-6d": [ + "GOV-04" ], - "A.03.02.02.ODP[03]": [ - "SAT-03" + "PROGRAM-2e": [ + "GOV-04" ], - "A.03.02.02.ODP[04]": [ - "SAT-03" + "PROGRAM-3d": [ + "GOV-04" ], - "A.03.02.02.a.01[01]": [ - "SAT-03" + "RISK-1e": [ + "GOV-04.1", + "GOV-04.2" ], - "A.03.02.02.a.01[02]": [ - "SAT-03" + "PROGRAM-2f": [ + "GOV-04.1", + "GOV-04.2" ], - "A.03.02.02.a.01[03]": [ - "SAT-03" + "ASSET-5f": [ + "GOV-05" ], - "A.03.02.02.a.02": [ - "SAT-03" + "THREAT-3f": [ + "GOV-05" ], - "A.03.02.02.b[01]": [ - "SAT-03" + "RISK-5f": [ + "GOV-05" ], - "A.03.02.02.b[02]": [ - "SAT-03" + "ACCESS-4f": [ + "GOV-05" ], - "A.03.06.04.a.02": [ - "SAT-03" + "SITUATION-3d": [ + "GOV-05", + "MON-06", + "MON-06.2" ], - "A.03.06.04.a.03": [ - "SAT-03" + "SITUATION-4f": [ + "GOV-05" ], - "A.03.02.01.a.02": [ - "SAT-03.6" + "RESPONSE-5f": [ + "GOV-05" ], - "A.03.02.01.b[01]": [ - "SAT-03.6" + "THIRD-PARTIES-3f": [ + "GOV-05" ], - "A.03.02.01.b[02]": [ - "SAT-03.6" + "WORKFORCE-5f": [ + "GOV-05" ], - "A.03.17.02[04]": [ - "TDA-01" + "ARCHITECTURE-6f": [ + "GOV-05" ], - "A.03.17.02[05]": [ - "TDA-01" + "PROGRAM-3f": [ + "GOV-05" ], - "A.03.17.02[06]": [ - "TDA-01" + "PROGRAM-2j": [ + "GOV-07" ], - "A.03.16.02.a": [ - "TDA-17" + "ARCHITECTURE-1f": [ + "GOV-15", + "GOV-15.1", + "SEA-01.1" ], - "A.03.16.02.b": [ - "TDA-17.1" + "ARCHITECTURE-1g": [ + "GOV-15.1" ], - "A.03.17.02[01]": [ - "TPM-03.1" + "ASSET-1d": [ + "AST-01", + "AST-02", + "AST-02.9", + "TDA-06.1" ], - "A.03.17.02[02]": [ - "TPM-03.1" + "ASSET-1h": [ + "AST-01", + "AST-09", + "SEA-07.1" ], - "A.03.17.02[03]": [ - "TPM-03.1" + "ASSET-2e": [ + "AST-01", + "AST-02.9" ], - "A.03.16.03.ODP[01]": [ - "TPM-05", - "TPM-05.2" + "ASSET-1a": [ + "AST-01.1", + "AST-02" ], - "A.03.16.03.a": [ - "TPM-05" + "RISK-2m": [ + "AST-01.1", + "BCD-02", + "RSK-01.1", + "RSK-03" ], - "A.03.16.03.b": [ + "THIRD-PARTIES-1a": [ + "AST-01.1", + "BCD-02", + "TPM-04", "TPM-05.4" ], - "A.03.16.03.c": [ - "TPM-05.5", - "TPM-05.6", - "TPM-05.8", - "TPM-08" + "ASSET-1b": [ + "AST-02" ], - "A.03.14.03.a": [ - "THR-03" + "ASSET-1e": [ + "AST-02" ], - "A.03.14.03.b[01]": [ - "THR-03.1" + "ASSET-1f": [ + "AST-02" ], - "A.03.14.03.b[02]": [ - "THR-03.1" + "ASSET-1g": [ + "AST-02" ], - "A.03.02.01.a.03[01]": [ - "THR-05" + "ASSET-2a": [ + "AST-02" ], - "A.03.02.01.a.03[02]": [ - "THR-05" + "ASSET-2b": [ + "AST-02" ], - "A.03.11.02.ODP[03]": [ - "VPM-01", - "VPM-02" + "ASSET-2f": [ + "AST-02" ], - "A.03.11.02.a[01]": [ - "VPM-01.1", - "VPM-06" + "ASSET-2g": [ + "AST-02", + "AST-02.1", + "AST-02.9" ], - "A.03.11.02.b": [ - "VPM-04", - "VPM-05" + "RISK-2h": [ + "AST-02", + "BCD-02" ], - "A.03.14.01.ODP[01]": [ - "VPM-05" + "ARCHITECTURE-2k": [ + "AST-02.5" ], - "A.03.14.01.ODP[02]": [ - "VPM-05" + "ASSET-2h": [ + "AST-09", + "DCH-09" ], - "A.03.14.01.a[01]": [ - "VPM-05" + "ASSET-2c": [ + "AST-31", + "BCD-02", + "TDA-06.1" ], - "A.03.14.01.a[02]": [ - "VPM-05" + "ASSET-2d": [ + "AST-31", + "PRM-06", + "TDA-06.1" ], - "A.03.14.01.a[03]": [ - "VPM-05" + "RESPONSE-4d": [ + "BCD-01" ], - "A.03.14.01.b[01]": [ - "VPM-05" + "RESPONSE-4g": [ + "BCD-01.4", + "BCD-01.7" ], - "A.03.14.01.b[02]": [ - "VPM-05" + "RESPONSE-4h": [ + "BCD-01.5" ], - "A.03.11.02.ODP[01]": [ - "VPM-06" + "RESPONSE-4a": [ + "BCD-01.7" ], - "A.03.11.02.ODP[02]": [ - "VPM-06" + "RESPONSE-4e": [ + "BCD-01.7" ], - "A.03.11.02.ODP[04]": [ - "VPM-06", - "VPM-06.1" + "RESPONSE-4f": [ + "BCD-01.7" ], - "A.03.11.02.a[02]": [ - "VPM-06" + "RESPONSE-4m": [ + "BCD-01.7" ], - "A.03.11.02.a[03]": [ - "VPM-06" + "ASSET-1c": [ + "BCD-02", + "TDA-06.1" ], - "A.03.11.02.a[04]": [ - "VPM-06" + "RESPONSE-4i": [ + "BCD-04" ], - "A.03.11.02.c[01]": [ - "VPM-06", - "VPM-06.1" + "RESPONSE-4n": [ + "BCD-04" ], - "A.03.11.02.c[02]": [ - "VPM-06", - "VPM-06.1" - ] - }, - "general-nist-800-172": { - "3.1.2e": [ - "AST-02", - "DCH-06.2", - "IAC-08", - "PES-03" + "RESPONSE-4o": [ + "BCD-05" ], - "3.5.3e": [ - "AST-02.5" + "RESPONSE-4p": [ + "BCD-06" ], - "3.1.3e": [ - "AST-02.8", - "AST-04", - "NET-02.3", - "NET-04" + "RESPONSE-4b": [ + "BCD-11", + "BCD-11.1" ], - "3.4.1e": [ - "AST-02.9" + "RESPONSE-4j": [ + "BCD-11", + "BCD-11.4", + "BCD-11.9" ], - "3.4.3e": [ - "AST-02.9" + "RESPONSE-4k": [ + "BCD-11.2" ], - "3.14.3e": [ - "AST-04.1", - "CPL-01.2", - "NET-06", - "NET-06.4" + "RESPONSE-4c": [ + "BCD-15" ], - "3.14.1e": [ - "AST-18", - "CRY-13", - "TDA-01.2" + "RESPONSE-4l": [ + "BCD-15" ], - "3.14.5e": [ - "BCD-02.4", - "DCH-01.2" + "ARCHITECTURE-3i": [ + "CAP-01", + "MNT-01" ], - "3.13.2e": [ + "ASSET-4a": [ "CHG-01" ], - "3.11.5e": [ - "CPL-01.2", - "CPL-03", - "RSK-03.1", - "RSK-04", - "THR-09" - ], - "3.4.2e": [ - "CFG-02.2", - "CFG-02.8", - "CFG-06", - "CFG-06.1" - ], - "3.5.2e": [ - "CFG-02.7", - "IAC-01.2", - "IAC-10.11" - ], - "3.14.7e": [ - "CFG-06.1", - "TDA-01.2", - "TDA-14.1", - "TDA-14.2" + "ASSET-4c": [ + "CHG-01", + "CHG-02.2", + "CHG-02.3", + "CHG-03" ], - "3.14.2e": [ - "MON-01", - "MON-16" + "ASSET-4g": [ + "CHG-01" ], - "3.14.6e": [ - "MON-01.1", - "THR-03", - "THR-07" + "ASSET-4b": [ + "CHG-02", + "CHG-02.2" ], - "3.11.2e": [ - "MON-11.3", - "THR-07" + "ARCHITECTURE-3l": [ + "CHG-02", + "CFG-02" ], - "3.9.1e": [ - "HRS-02", - "HRS-03", - "HRS-04", - "HRS-04.1" + "ASSET-4d": [ + "CHG-02.2", + "CHG-03" ], - "3.9.2e": [ - "HRS-02.1", - "HRS-07", - "HRS-07.1", - "HRS-07.3" + "ASSET-4f": [ + "CHG-02.2", + "CHG-07" ], - "3.5.1e": [ - "IAC-02.2", - "IAC-04" + "ASSET-4h": [ + "CHG-02.2" ], - "3.1.1e": [ - "IAC-20.5" + "ASSET-4i": [ + "CHG-02.2" ], - "3.6.2e": [ - "IRO-07" + "THREAT-1h": [ + "CHG-02.2", + "CHG-02.3", + "VPM-03", + "VPM-03.1" ], - "3.11.4e": [ - "IAO-03" + "ASSET-4e": [ + "CHG-04", + "CHG-04.4", + "CHG-06" ], - "3.13.4e": [ - "NET-02", - "NET-03.7", - "PES-04.1", - "PES-12", - "PES-18" + "RISK-2l": [ + "CPL-01.1", + "SEA-01.1", + "VPM-05.1", + "VPM-05.3" ], - "3.11.1e": [ - "RSK-04", - "RSK-04.2", - "THR-03", - "THR-07" + "ARCHITECTURE-1i": [ + "CPL-01.1", + "CPL-01.3", + "CPL-01.4", + "CPL-02", + "CPL-03.2" ], - "3.11.7e": [ - "RSK-06", - "RSK-09" + "RISK-4c": [ + "CPL-02", + "CPL-03.2", + "IAO-01" ], - "3.11.6e": [ - "RSK-06.1", - "RSK-09", - "RSK-09.1" + "PROGRAM-2h": [ + "CPL-02" ], - "3.14.4e": [ - "SEA-08.1" + "ASSET-3a": [ + "CFG-02" ], - "3.13.1e": [ - "SEA-13" + "ASSET-3b": [ + "CFG-02" ], - "3.13.3e": [ - "SEA-14" + "ASSET-3c": [ + "CFG-02" ], - "3.13.5e": [ - "SEA-15" + "SITUATION-1c": [ + "CFG-02", + "MON-01.4" ], - "3.6.1e": [ - "OPS-04" + "SITUATION-1d": [ + "CFG-02", + "MON-01.4" ], - "3.11.3e": [ - "OPS-06" + "ARCHITECTURE-2e": [ + "CFG-02", + "NET-04", + "NET-04.1" ], - "3.2.1e": [ - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.6" + "ARCHITECTURE-3b": [ + "CFG-02", + "END-01" ], - "3.2.2e": [ - "SAT-03.1", - "SAT-03.6" + "ARCHITECTURE-3d": [ + "CFG-02", + "CFG-03" ], - "3.12.1e": [ - "VPM-07" - ] - }, - "general-nist-800-207": { - "NIST Tenet 7": [ - "GOV-05", - "AST-02.6", - "AST-02.8", - "AST-02.9", - "MON-01", - "MON-01.2", - "MON-01.4", - "MON-02", - "MON-02.1", - "MON-02.2", - "MON-02.3", - "DCH-24.1", - "NET-14.7", - "THR-01", - "THR-03" + "ARCHITECTURE-3e": [ + "CFG-02" ], - "NIST Tenet 1": [ - "AST-01", - "AST-01.1", - "AST-02", - "AST-02.3", - "AST-02.8", - "AST-02.9", - "AST-04", - "AST-04.1", - "CLD-01", - "CLD-13", - "DCH-01", - "DCH-02", - "DCH-06.2", - "DCH-13.4", - "DCH-24", - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07", - "PRI-05.5", - "TPM-01.1" + "ARCHITECTURE-3f": [ + "CFG-02", + "END-02" ], - "NIST Tenet 5": [ - "AST-01", - "AST-02.2", - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.4", - "CFG-01", + "ARCHITECTURE-3g": [ "CFG-02", - "CFG-02.1", - "CFG-02.2", - "CFG-02.7", - "CFG-02.8", - "CFG-06", - "CFG-06.1", - "MON-01", - "MON-01.2", - "MON-02", - "MON-02.1", - "MON-02.2", - "MON-02.3", - "DCH-13.1", - "NET-01.1", - "NET-08.3", - "NET-08.4", - "NET-14.1", - "NET-14.7" + "DCH-12" ], - "NIST Tenet 6": [ - "AST-02.2", - "AST-02.5", - "AST-02.9", - "MON-01", - "IAC-01", - "IAC-01.2", - "IAC-06", - "NET-01.1" + "ARCHITECTURE-3h": [ + "CFG-02", + "CFG-02.9", + "END-02" ], - "NIST Tenet 4": [ - "CFG-08", - "MON-02.3", - "MON-02.4", - "MON-16", - "DCH-01.2", - "DCH-01.4", - "DCH-13.3", - "DCH-14.2", - "DCH-24.1", - "DCH-25", - "DCH-25.1", - "END-01", - "IAC-01.2", - "IAC-03", - "IAC-04", - "IAC-05", - "IAC-05.2", - "IAC-08", - "IAC-09", - "IAC-13.2", - "IAC-15.1", - "MDM-09", - "NET-02.3", - "NET-04", - "NET-04.1", - "NET-04.7", - "NET-04.12", - "NET-08.3", - "NET-08.4", - "NET-14.7" + "ASSET-3d": [ + "CFG-02.1", + "CFG-02.9" ], - "NIST Tenet 2": [ - "CRY-01", - "CRY-03", - "CRY-04", - "CRY-07", - "CRY-08", - "IAC-01.2", - "IAC-04", - "NET-01", - "NET-14.2", - "NET-14.5", - "NET-15" + "ASSET-3e": [ + "CFG-02.1", + "CFG-02.2" ], - "NIST Tenet 3": [ - "DCH-01.4", - "DCH-13.3", - "DCH-14.2", - "IAC-01.2", - "IAC-02", - "IAC-03", - "IAC-04", - "IAC-05", - "IAC-08", - "IAC-15.1", - "IAC-20.1", - "IAC-21", - "IAC-21.2", - "NET-01.1" - ] - }, - "general-nist-800-218": { - "PO.2.3": [ - "GOV-04", - "GOV-04.1" + "SITUATION-1f": [ + "CFG-02.5", + "CFG-02.9", + "MON-01.4", + "MON-01.16" ], - "PS.1": [ - "CHG-04", - "CHG-04.5" + "ARCHITECTURE-3k": [ + "CFG-02.5" ], - "PO.1": [ - "CPL-01", - "CPL-01.2", - "PRI-07.1", - "PRM-05", - "PRM-07", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-02.3", - "TDA-06", - "TPM-05" + "ARCHITECTURE-3m": [ + "CFG-03.3" ], - "PO.1.2": [ - "CPL-01", - "TDA-01.1", - "TDA-02" + "SITUATION-1a": [ + "MON-01", + "MON-01.4", + "MON-01.16" ], - "PO.5.2": [ - "CFG-02", - "CFG-02.4", - "CFG-02.5" + "SITUATION-2c": [ + "MON-01" ], - "PW.9.1": [ - "CFG-02", - "TDA-02", - "TDA-02.4", - "TDA-09.6" + "SITUATION-3g": [ + "MON-01", + "MON-01.13", + "MON-01.16" ], - "PO.5": [ - "CFG-02.4", - "TDA-07", - "TDA-08", - "TDA-08.1" + "RESPONSE-1d": [ + "MON-01.2", + "MON-02.1", + "MON-02.3" ], - "PO.2.1": [ - "HRS-01", - "HRS-03" + "SITUATION-2b": [ + "MON-01.3", + "MON-01.8" ], - "PO.2": [ - "HRS-03", - "HRS-03.2" + "SITUATION-1b": [ + "MON-01.4" ], - "RV.3": [ - "IRO-13", - "TDA-01.1" + "SITUATION-2e": [ + "MON-01.4", + "MON-01.8" ], - "PO.1.1": [ - "PRM-05", - "TDA-01.1", - "TDA-02" + "SITUATION-2a": [ + "MON-01.8" ], - "PO.3.2": [ - "OPS-01.1", - "OPS-03", - "TDA-01", - "TDA-02.3", - "TDA-06.4" + "SITUATION-2i": [ + "MON-01.8", + "MON-11.3", + "MON-16", + "IRO-03" ], - "PO.4.2": [ - "OPS-01.1", - "TDA-01.1", - "TDA-02.3" + "SITUATION-2f": [ + "MON-01.16" ], - "PO.2.2": [ - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6" + "SITUATION-2g": [ + "MON-01.16" ], - "PO.3": [ - "TDA-01", - "TDA-02.3", - "TDA-06.4" + "RESPONSE-1e": [ + "MON-01.16" ], - "RV.3.4": [ - "TDA-01", - "TDA-01.1", - "TDA-02.7", - "TDA-06" + "SITUATION-1e": [ + "MON-02", + "MON-02.1" ], - "PW.1.2": [ - "TDA-01.1", - "TDA-02" + "SITUATION-3e": [ + "MON-02.1", + "THR-03" ], - "PW.4": [ - "TDA-01.1", - "TDA-02.4", - "TDA-03" + "SITUATION-3a": [ + "MON-06", + "MON-06.2" ], - "PW.4.2": [ - "TDA-01.1", - "TDA-05", - "TDA-06", - "TDA-06.3" + "SITUATION-3b": [ + "MON-06" ], - "PW.5": [ - "TDA-01.1", - "TDA-02.3", - "TDA-06" + "SITUATION-3c": [ + "MON-06", + "MON-06.2" ], - "PW.5.1": [ - "TDA-01.1", - "TDA-02", - "TDA-02.4", - "TDA-06", - "TDA-09", - "TDA-09.6" + "SITUATION-3f": [ + "MON-06" ], - "PW.6.2": [ - "TDA-01.1", - "TDA-06", - "TDA-06.4" + "SITUATION-2d": [ + "MON-11.3", + "MON-16", + "IRO-03" ], - "PW.8.1": [ - "TDA-01.1", - "TDA-09" + "SITUATION-2h": [ + "MON-11.3", + "MON-16", + "IRO-03", + "RSK-01.1" ], - "RV.2.2": [ - "TDA-01.1", - "TDA-06.2", - "TDA-09", - "VPM-02" + "ACCESS-2i": [ + "MON-16" ], - "RV.3.3": [ - "TDA-01.1", - "TDA-09" + "ARCHITECTURE-5d": [ + "CRY-01", + "CRY-03", + "CRY-05" ], - "PW.1.3": [ - "TDA-02", - "TDA-06", - "TDA-09.6" + "ARCHITECTURE-5c": [ + "CRY-03" ], - "PW.2": [ - "TDA-02", - "TDA-02.3", - "TDA-02.6", - "TDA-02.7", - "TDA-06.3", - "TDA-06.5" + "ARCHITECTURE-5a": [ + "CRY-05" ], - "PW.4.4": [ - "TDA-02", - "TDA-02.1", - "TDA-02.5", - "TDA-02.6", - "TDA-04.2" + "ARCHITECTURE-5b": [ + "CRY-05" ], - "PW.9.2": [ - "TDA-02", - "TDA-02.4", - "TDA-09.6" + "ARCHITECTURE-5e": [ + "CRY-09" ], - "PO.3.1": [ - "TDA-02.3", - "TDA-06.4" + "ARCHITECTURE-2j": [ + "EMB-01", + "NET-06.4" ], - "PO.3.3": [ - "TDA-02.3", - "TDA-02.5", - "TDA-04", - "TDA-04.1" + "WORKFORCE-1g": [ + "HRS-01", + "HRS-07", + "HRS-07.1", + "HRS-09" ], - "PW.6.1": [ - "TDA-02.3", - "TDA-06", - "TDA-06.4" + "WORKFORCE-3e": [ + "HRS-01" ], - "RV.1": [ - "TDA-02.3", - "TDA-02.7", - "TDA-06.5", - "TDA-09", - "TDA-09.1" + "WORKFORCE-3f": [ + "HRS-01" ], - "RV.2": [ - "TDA-02.3", - "TDA-09" + "ACCESS-3h": [ + "HRS-02", + "HRS-02.1", + "HRS-04.1" ], - "PW.4.1": [ - "TDA-03" + "WORKFORCE-3a": [ + "HRS-02", + "HRS-03" ], - "PS.3.2": [ - "TDA-04", - "TDA-04.2" + "THREAT-2a": [ + "HRS-03", + "TPM-04", + "TPM-05.4" ], - "RV.1.1": [ - "TDA-04", - "TDA-04.1", - "TDA-04.2", - "TDA-05" + "RESPONSE-3a": [ + "HRS-03", + "IRO-07" ], - "PW.1": [ - "TDA-06", - "TDA-06.1", - "TDA-06.2", - "TDA-06.3" + "WORKFORCE-3b": [ + "HRS-03" ], - "PW.1.1": [ - "TDA-06.2" + "WORKFORCE-3c": [ + "HRS-03" ], - "PO.4": [ - "TDA-06.5", - "TDA-09", - "TDA-09.2", - "TDA-09.3" + "WORKFORCE-3d": [ + "HRS-03" ], - "PW.2.1": [ - "TDA-06.5" + "WORKFORCE-1e": [ + "HRS-03.1", + "HRS-04.2", + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "HRS-05.3", + "HRS-05.4", + "HRS-05.5", + "HRS-05.7", + "HRS-06" ], - "RV.1.2": [ - "TDA-06.5" + "WORKFORCE-2a": [ + "HRS-03.1", + "HRS-04.2", + "SAT-01", + "SAT-02" ], - "PO.5.1": [ - "TDA-07", - "TDA-08" + "ASSET-5e": [ + "HRS-03.2" ], - "PO.4.1": [ - "TDA-09" + "THREAT-3e": [ + "HRS-03.2" ], - "PW.6": [ - "TDA-09", - "TDA-09.6" + "RISK-5e": [ + "HRS-03.2" ], - "PW.7": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5" + "ACCESS-4e": [ + "HRS-03.2" ], - "PW.7.1": [ - "TDA-09" + "SITUATION-4e": [ + "HRS-03.2" ], - "PW.8.2": [ - "TDA-09" + "RESPONSE-5e": [ + "HRS-03.2" ], - "RV.2.1": [ - "TDA-09" + "THIRD-PARTIES-3e": [ + "HRS-03.2" ], - "RV.3.1": [ - "TDA-09" + "WORKFORCE-5e": [ + "HRS-03.2" ], - "RV.3.2": [ - "TDA-09" + "ARCHITECTURE-6e": [ + "HRS-03.2" ], - "PW.7.2": [ - "TDA-09.2", - "TDA-09.3" + "PROGRAM-3e": [ + "HRS-03.2" ], - "PW.8": [ - "TDA-09.4", - "TDA-09.5" + "WORKFORCE-1a": [ + "HRS-04" ], - "PW.9": [ - "TDA-09.6" + "WORKFORCE-1b": [ + "HRS-04" ], - "PS.1.1": [ - "TDA-20" + "WORKFORCE-1c": [ + "HRS-04" ], - "PS.2": [ - "TDA-20.1" + "WORKFORCE-1f": [ + "HRS-04", + "HRS-04.1", + "IAC-28" ], - "PS.2.1": [ - "TDA-20.1" + "WORKFORCE-1d": [ + "HRS-08", + "HRS-09" ], - "PS.3": [ - "TDA-20.2" + "ACCESS-2e": [ + "HRS-11" ], - "PS.3.1": [ - "TDA-20.2", - "TDA-20.3" + "ACCESS-3f": [ + "HRS-11", + "PES-02", + "PES-02.1", + "PES-02.2", + "PES-03" ], - "RV.1.3": [ - "THR-06" - ] - }, - "general-nist-csf-2-0": { - "GV": [ - "GOV-01", - "GOV-05", - "PRM-01.1", - "RSK-01" + "WORKFORCE-4b": [ + "HRS-13" ], - "GV.RM-01": [ - "GOV-01", - "GOV-01.1", - "GOV-05.2", - "RSK-01" + "WORKFORCE-4c": [ + "HRS-13" ], - "GV.RM-03": [ - "GOV-01", - "GOV-01.1", - "RSK-01" + "ACCESS-2a": [ + "IAC-01" ], - "GV.RR-01": [ - "GOV-01", - "GOV-01.1", - "GOV-04", - "GOV-04.1", - "RSK-01", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-12" + "ACCESS-2c": [ + "IAC-01" ], - "GV.SC": [ - "GOV-01", - "GOV-01.1", - "GOV-01.2", - "GOV-05", - "RSK-01", - "RSK-09", - "RSK-09.1", - "TPM-03" + "ACCESS-2f": [ + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-21.3", + "IAC-28.1" ], - "GV.SC-01": [ - "GOV-01", - "GOV-01.1", - "GOV-02", - "RSK-01", - "RSK-09" + "ARCHITECTURE-3a": [ + "IAC-01", + "PES-01" ], - "GV.SC-03": [ - "GOV-01", - "GOV-01.1", - "GOV-02", - "GOV-08", - "GOV-09", - "RSK-01", - "RSK-09" + "ACCESS-1b": [ + "IAC-01.2", + "IAC-10", + "IAC-10.1", + "IAC-10.2" ], - "GV.SC-09": [ - "GOV-01", - "GOV-01.1", - "GOV-01.2", - "GOV-05", - "PRM-07", - "RSK-01", - "RSK-09", - "RSK-09.1", - "SEA-07.1", - "TDA-01.1" + "ACCESS-1h": [ + "IAC-06", + "IAC-06.1", + "IAC-06.3", + "IAC-16" ], - "ID.RA": [ - "GOV-01", - "GOV-01.1", - "GOV-02", - "RSK-01", - "RSK-09" + "ACCESS-1i": [ + "IAC-06" ], - "PR": [ - "GOV-01", - "GOV-01.1", - "CPL-01", - "RSK-01", - "RSK-09" + "ACCESS-1a": [ + "IAC-07" ], - "PR.IR": [ - "GOV-01", - "GOV-01.1", - "RSK-01", - "SEA-01", - "SEA-01.1", - "SEA-01.2", - "SEA-02" + "ACCESS-1c": [ + "IAC-07" ], - "GV.OV": [ - "GOV-01.1", - "GOV-01.2", - "GOV-03", - "GOV-05" + "ACCESS-1f": [ + "IAC-07" ], - "GV.OV-01": [ - "GOV-01.1", - "GOV-01.2", - "GOV-03", - "GOV-05", - "GOV-08", - "PRM-01.1" + "ACCESS-2g": [ + "IAC-07", + "IAC-07.1", + "IAC-21.3", + "IAC-28.1" ], - "GV.OV-02": [ - "GOV-01.1", - "GOV-03", - "RSK-01" + "ACCESS-2h": [ + "IAC-07.1", + "IAC-17" ], - "GV.OV-03": [ - "GOV-01.1", - "GOV-01.2", - "GOV-05", - "RSK-01" + "ACCESS-1g": [ + "IAC-08", + "IAC-16", + "IAC-21" ], - "ID": [ - "GOV-01.1", - "GOV-01.2", - "RSK-01", - "RSK-01.1", - "RSK-03", - "RSK-03.1", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-09" + "ACCESS-2b": [ + "IAC-08", + "IAC-15", + "IAC-16", + "IAC-17" ], - "GV.PO": [ - "GOV-02", - "HRS-05.7", - "HRS-07" + "ARCHITECTURE-3c": [ + "IAC-08", + "IAC-21" ], - "GV.PO-01": [ - "GOV-02", - "HRS-05.7", - "HRS-07" + "ACCESS-1d": [ + "IAC-10.1" ], - "ID.RA-07": [ - "GOV-02.1", - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "CHG-03", - "CHG-04" + "ACCESS-1j": [ + "IAC-15.3" ], - "GV.PO-02": [ - "GOV-03", - "HRS-05.7", - "HRS-07" + "ACCESS-1e": [ + "IAC-17" ], - "GV.RM": [ - "GOV-04", - "PRM-01", - "PRM-01.1", - "RSK-01", - "RSK-01.1", - "RSK-01.3", - "RSK-01.5" + "ACCESS-2d": [ + "IAC-20", + "IAC-21" ], - "GV.RM-05": [ - "GOV-04", - "GOV-04.1", - "HRS-03", - "TPM-05.4" + "RESPONSE-1a": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "GV.RR-02": [ - "GOV-04", - "HRS-02", - "HRS-03", - "TPM-05.4" + "RESPONSE-1b": [ + "IRO-02", + "IRO-02.4" ], - "ID.IM-03": [ - "GOV-05", - "BCD-05", - "IRO-13" + "RESPONSE-1f": [ + "IRO-02" ], - "ID.RA-02": [ - "GOV-07", - "THR-03" + "RESPONSE-2a": [ + "IRO-02", + "IRO-02.4" ], - "GV.OC": [ - "GOV-08", - "AST-01.1", - "AST-01.2", - "CPL-01", - "TPM-05.4" + "RESPONSE-2b": [ + "IRO-02", + "IRO-02.4" ], - "GV.OC-01": [ - "GOV-08", - "RSK-01.1", - "TDA-06.2" + "RESPONSE-3b": [ + "IRO-02", + "IRO-04" ], - "GV.OC-04": [ - "GOV-08", - "BCD-02", - "PRM-01.1", - "TPM-02" + "RESPONSE-3c": [ + "IRO-02", + "IRO-10", + "IRO-10.2" ], - "DE.AE-04": [ - "GOV-16", + "RESPONSE-3e": [ + "IRO-02", + "IRO-04" + ], + "RESPONSE-3l": [ "IRO-02", + "IRO-04" + ], + "RESPONSE-2c": [ "IRO-02.4" ], - "GV.SC-04": [ - "AST-01", - "AST-01.1", - "TPM-01", - "TPM-01.1", - "TPM-02" + "RESPONSE-2d": [ + "IRO-02.4" ], - "ID.AM": [ - "AST-01", - "AST-01.1", - "AST-01.2", - "AST-02", - "AST-03", - "AST-03.1", - "HRS-01", - "HRS-03", - "HRS-05", - "HRS-05.1", - "PES-01", - "RSK-02", - "TPM-01", - "TPM-01.1", - "TPM-05.4", - "TPM-06" + "RESPONSE-2e": [ + "IRO-02.4" ], - "ID.AM-08": [ - "AST-01", - "AST-01.2", - "DCH-01", - "DCH-01.1", - "PRM-07", - "SEA-07", - "SEA-07.1" + "RESPONSE-2h": [ + "IRO-02.4" ], - "GV.OC-02": [ - "AST-01.2", - "TPM-05", - "TPM-05.4" + "RESPONSE-3d": [ + "IRO-04" ], - "ID.AM-01": [ - "AST-02", - "TPM-01.1" + "RESPONSE-3f": [ + "IRO-04" ], - "ID.AM-02": [ - "AST-02", - "TPM-01.1" + "RESPONSE-3g": [ + "IRO-06" ], - "ID.AM-03": [ - "AST-04", - "AST-04.2", - "DCH-19" + "RESPONSE-3j": [ + "IRO-06.1", + "IRO-11.2" ], - "ID.AM-05": [ - "AST-04.1", - "BCD-02", - "DCH-02", - "TPM-02" + "RESPONSE-1c": [ + "IRO-09" ], - "ID.RA-09": [ - "AST-15", - "AST-18", - "TDA-01", - "TDA-01.2", - "TDA-14", - "TDA-14.1", - "TDA-14.2" + "RESPONSE-2f": [ + "IRO-09", + "IRO-09.3" ], - "GV.SC-08": [ - "BCD-01", - "BCD-01.2", - "IRO-01", - "IRO-02", - "IRO-02.5", - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-09", - "TPM-10", - "TPM-11" + "RESPONSE-2i": [ + "IRO-09.4" ], - "ID.IM-04": [ - "BCD-01", - "BCD-06", - "IRO-04", - "IRO-04.2" + "RESPONSE-2g": [ + "IRO-10", + "IRO-10.2" ], - "PR.IR-02": [ - "BCD-01", - "PES-01", - "PES-07", - "PES-07.5", - "PES-08", - "PES-09", - "SEA-01.2", - "THR-09" + "RESPONSE-3k": [ + "IRO-11.2" ], - "PR.IR-03": [ - "BCD-01", - "SEA-01", - "SEA-01.2", - "SEA-02" + "RESPONSE-3h": [ + "IRO-13" ], - "RS.MA-05": [ - "BCD-01", - "BCD-01.5" + "RESPONSE-3i": [ + "IRO-13" ], - "RC": [ - "BCD-01", - "BCD-12" + "RISK-4d": [ + "IAO-02" ], - "RC.RP": [ - "BCD-01", - "BCD-01.4", - "BCD-02", - "BCD-02.1" + "RISK-3f": [ + "IAO-05", + "RSK-04.1" ], - "RC.RP-02": [ - "BCD-01", - "BCD-01.4", - "BCD-02", - "BCD-02.1" + "RISK-3g": [ + "IAO-05" ], - "RC.RP-04": [ - "BCD-01", - "BCD-01.4", - "BCD-02", - "BCD-02.1" + "ARCHITECTURE-2a": [ + "NET-01" ], - "RC.CO": [ - "BCD-01.1", - "BCD-01.2" + "ARCHITECTURE-2c": [ + "NET-01", + "NET-02" ], - "RC.RP-01": [ - "BCD-01.5", - "BCD-12" + "ARCHITECTURE-2f": [ + "NET-01" ], - "RC.CO-03": [ - "BCD-01.6" + "ARCHITECTURE-5f": [ + "NET-03.5", + "NET-17", + "NET-18" ], - "GV.OC-05": [ - "BCD-02", - "TDA-04.2", - "TPM-02" + "ARCHITECTURE-2l": [ + "NET-03.6" ], - "ID.IM-02": [ - "BCD-05", - "CPL-03", - "CPL-03.2", - "IRO-13", - "IAO-02", - "IAO-02.4", - "IAO-05", - "TDA-09", - "TDA-09.1", - "TPM-04.1", - "TPM-08" + "ARCHITECTURE-2b": [ + "NET-06" ], - "PR.DS-11": [ - "BCD-11", - "BCD-11.1", - "BCD-11.5", - "BCD-11.6" + "ARCHITECTURE-2d": [ + "NET-06" ], - "RC.RP-05": [ - "BCD-12" + "ARCHITECTURE-2h": [ + "NET-06" ], - "RC.RP-03": [ - "BCD-13", - "BCD-13.1" + "ARCHITECTURE-2i": [ + "NET-06.4" ], - "PR.IR-04": [ - "CAP-01", - "CAP-02", - "CAP-03", - "CAP-04", - "CAP-05" + "ARCHITECTURE-2g": [ + "NET-18" ], - "GV.OC-03": [ - "CPL-01", - "CPL-02", - "PRI-01", - "TPM-05", - "TPM-05.2" + "ACCESS-3a": [ + "PES-01", + "PES-03" ], - "GV.SC-05": [ - "CPL-01", - "CPL-01.2", - "IAO-03.2", - "PRI-07.1", - "RSK-01", - "RSK-09", - "TPM-05", - "TPM-05.2" + "ACCESS-3d": [ + "PES-01", + "PES-02", + "PES-03" ], - "ID.IM-01": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-02.4", - "IAO-05", - "TDA-09", - "TDA-09.1", - "TPM-04.1", - "TPM-08" + "ARCHITECTURE-3j": [ + "PES-01" ], - "PR.PS": [ - "CFG-01", - "CFG-02", - "CFG-02.1", - "CFG-02.5", - "MNT-01", - "MNT-02" + "ACCESS-3b": [ + "PES-02" ], - "PR.PS-01": [ - "CFG-01" + "ACCESS-3g": [ + "PES-02", + "PES-03" ], - "PR.PS-05": [ - "CFG-01", - "CFG-02", - "CFG-03", - "CFG-03.2", - "CFG-05", - "END-03" + "ACCESS-3i": [ + "PES-02" ], - "PR.DS-10": [ - "CFG-02", - "CRY-01", - "DCH-01", - "IAC-21" + "ACCESS-3e": [ + "PES-02.1", + "PES-03" ], - "PR.PS-04": [ - "MON-01", - "MON-01.4", - "MON-03" + "ACCESS-3j": [ + "PES-03" ], - "DE.CM-01": [ - "MON-01", - "MON-01.1", - "MON-01.3", - "MON-01.4", - "MON-01.8" + "ACCESS-3c": [ + "PES-03.3" ], - "DE.CM-03": [ - "MON-01", - "MON-16", - "MON-16.1", - "MON-16.3", - "NET-18" + "ARCHITECTURE-1e": [ + "PRM-01" ], - "DE.CM-06": [ - "MON-01", - "MON-16.2", - "MON-16.4" + "RISK-1a": [ + "PRM-01.1" ], - "DE.CM-09": [ - "MON-01", - "MON-01.7", - "END-01", - "END-04", - "END-06" + "ARCHITECTURE-1a": [ + "PRM-01.1" ], - "DE.AE": [ - "MON-01", - "MON-01.8", - "MON-01.12", - "IRO-01", - "IRO-02", - "IRO-02.4" + "PROGRAM-1a": [ + "PRM-01.1" ], - "DE.AE-06": [ - "MON-01.8", - "MON-01.12", - "MON-02", - "MON-02.1", - "IRO-02", - "IRO-02.4", - "IRO-04", - "IRO-07", - "IRO-09", - "IRO-10" + "PROGRAM-1b": [ + "PRM-01.1" ], - "DE.AE-03": [ - "MON-02", - "MON-02.1", - "IRO-02", - "IRO-02.5" + "PROGRAM-1c": [ + "PRM-01.1" ], - "DE.CM": [ - "MON-11.3", - "MON-16", - "IRO-03", - "THR-02" + "PROGRAM-1d": [ + "PRM-01.1" ], - "PR.DS-01": [ - "CRY-01", - "CRY-01.1", - "CRY-05", - "DCH-01" + "PROGRAM-1e": [ + "PRM-01.1" ], - "PR.DS-02": [ - "CRY-01", - "CRY-03", - "CRY-04", - "DCH-01" + "ASSET-5b": [ + "PRM-03" ], - "PR.DS": [ - "DCH-01", - "DCH-01.1", - "DCH-01.2", - "DCH-01.3", - "DCH-01.4", - "DCH-02", - "DCH-03" + "THREAT-3b": [ + "PRM-03" ], - "ID.AM-07": [ - "DCH-06", - "DCH-06.2", - "DCH-06.3", - "PRI-05", - "PRI-05.5" + "RISK-5b": [ + "PRM-03" + ], + "ACCESS-4b": [ + "PRM-03" + ], + "SITUATION-4b": [ + "PRM-03" ], - "GV.RR-04": [ - "HRS-01", - "HRS-03.1" + "RESPONSE-5b": [ + "PRM-03" ], - "PR.AA-05": [ - "HRS-02", - "HRS-11", - "IAC-01", - "IAC-01.2", - "IAC-02", - "IAC-03", - "IAC-04", - "IAC-05", - "IAC-08", - "IAC-21" + "THIRD-PARTIES-3b": [ + "PRM-03" ], - "GV.RR": [ - "HRS-03", - "TPM-05.4" + "WORKFORCE-5b": [ + "PRM-03" ], - "PR.AA": [ - "IAC-01", - "IAC-01.2", - "PES-01", - "PES-02", - "PES-03" + "ARCHITECTURE-6b": [ + "PRM-03" ], - "PR.AA-03": [ - "IAC-01.2", - "IAC-02", - "IAC-03", - "IAC-04", - "IAC-05" + "PROGRAM-3b": [ + "PRM-03" ], - "PR.AA-04": [ - "IAC-01.2", - "IAC-02.2", - "IAC-03.5" + "RISK-1b": [ + "RSK-01" ], - "PR.AA-01": [ - "IAC-02", - "IAC-03", - "IAC-04", - "IAC-05" + "RISK-1c": [ + "RSK-01" ], - "PR.AA-02": [ - "IAC-28" + "RISK-1d": [ + "RSK-01" ], - "RS": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09", - "IRO-10" + "RISK-1g": [ + "RSK-01" ], - "RS.MI": [ - "IRO-01", - "IRO-02", - "IRO-04" + "RISK-1h": [ + "RSK-01" ], - "DE.AE-02": [ - "IRO-02", - "IRO-02.4" + "RISK-3b": [ + "RSK-01.1" ], - "DE.AE-08": [ - "IRO-02", - "IRO-02.4" + "RISK-2d": [ + "RSK-02" ], - "RS.MA": [ - "IRO-02", - "IRO-04", - "IRO-07" + "RISK-2i": [ + "RSK-02" ], - "RS.MA-01": [ - "IRO-02", - "IRO-02.5", - "IRO-04", - "IRO-07", - "IRO-10" + "RISK-3a": [ + "RSK-02" ], - "RS.MA-02": [ - "IRO-02", - "IRO-04" + "RISK-2a": [ + "RSK-03" ], - "RS.MA-04": [ - "IRO-02", - "IRO-04", - "IRO-07" + "RISK-2b": [ + "RSK-03" ], - "RS.AN": [ - "IRO-02", - "IRO-08" + "RISK-2c": [ + "RSK-03" ], - "RS.AN-06": [ - "IRO-02", - "IRO-08", - "IRO-09" + "RISK-2g": [ + "RSK-03", + "RSK-04", + "RSK-04.2" ], - "RS.CO": [ - "IRO-02", - "IRO-02.5", - "IRO-06.1", - "IRO-09", - "IRO-10", - "IRO-10.2", - "IRO-10.4" + "RISK-2e": [ + "RSK-03.1", + "RSK-04.1" ], - "RS.CO-02": [ - "IRO-02", - "IRO-10", - "IRO-10.2", - "IRO-10.4" + "RISK-2j": [ + "RSK-03.1", + "THR-09" ], - "RS.CO-03": [ - "IRO-02", - "IRO-10", - "IRO-10.2", - "IRO-10.4" + "RISK-2f": [ + "RSK-04.1" ], - "RS.MI-01": [ - "IRO-02" + "RISK-3c": [ + "RSK-04.2" ], - "RS.MI-02": [ - "IRO-02" + "RISK-3d": [ + "RSK-04.2" ], - "RC.RP-06": [ - "IRO-02", - "IRO-09" + "RISK-3e": [ + "RSK-04.2" ], - "RS.MA-03": [ - "IRO-02.4" + "RISK-4b": [ + "RSK-04.2", + "RSK-06.3" ], - "RS.AN-08": [ - "IRO-02.4" + "RISK-4e": [ + "RSK-06", + "RSK-06.1" ], - "RS.AN-07": [ - "IRO-08" + "RISK-4a": [ + "RSK-06.3" ], - "RS.AN-03": [ - "IRO-13" + "ARCHITECTURE-1b": [ + "SEA-01", + "SEA-02", + "SEA-03" ], - "RC.CO-04": [ - "IRO-16" + "ARCHITECTURE-1j": [ + "SEA-01", + "SEA-01.2", + "SEA-01.3", + "SEA-02" ], - "ID.RA-01": [ - "IAO-01", - "IAO-02", - "IAO-05", - "RSK-04", - "RSK-04.1", - "TDA-09", - "VPM-01", - "VPM-06" + "ARCHITECTURE-5g": [ + "SEA-01" ], - "PR.PS-02": [ - "MNT-01", - "MNT-02", - "MNT-03", - "MNT-03.1", - "PRM-07", - "SEA-07.1", - "TDA-17", - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-05" + "ARCHITECTURE-5h": [ + "SEA-01" ], - "PR.PS-03": [ - "MNT-01", - "MNT-02", - "MNT-03", - "MNT-03.1", - "PRM-07", - "SEA-07.1", - "TDA-17" + "ARCHITECTURE-1c": [ + "SEA-02" ], - "PR.IR-01": [ - "NET-01", - "NET-02", - "SEA-01", + "ARCHITECTURE-1d": [ "SEA-02" ], - "PR.AA-06": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03" + "ARCHITECTURE-1h": [ + "SEA-02" ], - "DE.CM-02": [ - "PES-01", - "PES-03", - "PES-03.3", - "PES-05" + "ARCHITECTURE-1k": [ + "SEA-02" ], - "GV.RR-03": [ - "PRM-01", - "PRM-02", - "PRM-03" + "ASSET-5a": [ + "OPS-01.1" ], - "GV.RM-04": [ - "RSK-01", - "RSK-01.1", - "RSK-06", - "RSK-06.1", - "RSK-06.2" + "THREAT-3a": [ + "OPS-01.1" ], - "GV.RM-06": [ - "RSK-01", - "RSK-01.1", - "RSK-04", - "RSK-04.1" + "RISK-5a": [ + "OPS-01.1" ], - "ID.IM": [ - "RSK-01", - "RSK-09", - "OPS-01", + "ACCESS-4a": [ "OPS-01.1" ], - "GV.RM-07": [ - "RSK-01.1" + "SITUATION-4a": [ + "OPS-01.1" ], - "ID.RA-05": [ - "RSK-01.1", - "RSK-02.1", - "RSK-04", - "RSK-05", - "RSK-06", - "RSK-06.1", - "THR-02", - "THR-09", - "THR-10" + "RESPONSE-5a": [ + "OPS-01.1" ], - "ID.RA-06": [ - "RSK-01.1", - "RSK-02.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-06.2" + "THIRD-PARTIES-3a": [ + "OPS-01.1" ], - "GV.RM-02": [ - "RSK-01.3", - "RSK-01.5" + "WORKFORCE-5a": [ + "OPS-01.1" ], - "GV.SC-10": [ - "RSK-09", - "TPM-01", - "TPM-05.2", - "TPM-05.3" + "ARCHITECTURE-6a": [ + "OPS-01.1" ], - "PR.AT": [ + "PROGRAM-3a": [ + "OPS-01.1" + ], + "WORKFORCE-2b": [ "SAT-01", - "SAT-02", + "SAT-02" + ], + "WORKFORCE-2c": [ + "SAT-01", + "SAT-02" + ], + "WORKFORCE-4f": [ + "SAT-01" + ], + "WORKFORCE-2g": [ + "SAT-01.1" + ], + "WORKFORCE-4e": [ + "SAT-01.1" + ], + "WORKFORCE-2d": [ + "SAT-02" + ], + "WORKFORCE-4d": [ + "SAT-02" + ], + "WORKFORCE-2e": [ "SAT-03" ], - "PR.AT-01": [ - "SAT-02", - "SAT-03", - "SAT-03.6" + "WORKFORCE-2f": [ + "SAT-03" ], - "PR.AT-02": [ - "SAT-03", - "SAT-03.5", - "SAT-03.6", - "SAT-03.7" + "WORKFORCE-4a": [ + "SAT-03" ], - "PR.PS-06": [ + "ARCHITECTURE-4a": [ + "TDA-01", + "TDA-06" + ], + "ARCHITECTURE-4b": [ + "TDA-01", + "TDA-02", + "TPM-04.1" + ], + "ARCHITECTURE-4e": [ "TDA-01", + "TDA-02", + "TPM-04.1" + ], + "ARCHITECTURE-4c": [ "TDA-01.1", - "TDA-06", - "TDA-06.1", - "TDA-06.2", - "TDA-06.3", - "TDA-09" + "TDA-02", + "TDA-09.6" ], - "GV.SC-06": [ - "TPM-01", - "TPM-02", - "TPM-03", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-04.3", - "TPM-04.4", - "TPM-05", - "TPM-05.2", - "TPM-05.3", - "TPM-05.4", - "TPM-05.5", - "TPM-05.6", - "TPM-05.7", - "TPM-06", - "TPM-09" + "ARCHITECTURE-4f": [ + "TDA-05", + "TDA-06.5" ], - "GV.SC-07": [ - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-03", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-08", - "TPM-09" + "ARCHITECTURE-4d": [ + "TDA-06" ], - "ID.AM-04": [ + "ARCHITECTURE-4h": [ + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.5" + ], + "ARCHITECTURE-4g": [ + "TDA-14.1" + ], + "THIRD-PARTIES-2i": [ + "TDA-17", + "TDA-17.1", + "TPM-04.1" + ], + "THIRD-PARTIES-1b": [ "TPM-01.1" ], - "ID.RA-10": [ + "THIRD-PARTIES-1d": [ "TPM-01.1", + "TPM-02" + ], + "THIRD-PARTIES-1c": [ "TPM-02", "TPM-04.1" ], - "GV.SC-02": [ - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "THIRD-PARTIES-1e": [ + "TPM-02" ], - "ID.RA-03": [ - "THR-01", - "THR-02", + "THIRD-PARTIES-1f": [ + "TPM-02" + ], + "THIRD-PARTIES-2j": [ + "TPM-03.1" + ], + "THIRD-PARTIES-2k": [ + "TPM-03.1" + ], + "THIRD-PARTIES-2l": [ + "TPM-03.1" + ], + "THIRD-PARTIES-2m": [ + "TPM-03.1" + ], + "THIRD-PARTIES-2a": [ + "TPM-04.1" + ], + "THIRD-PARTIES-2b": [ + "TPM-04.1" + ], + "THIRD-PARTIES-2c": [ + "TPM-05" + ], + "THIRD-PARTIES-2e": [ + "TPM-05" + ], + "THIRD-PARTIES-2f": [ + "TPM-05" + ], + "THIRD-PARTIES-2g": [ + "TPM-05" + ], + "THIRD-PARTIES-2h": [ + "TPM-05" + ], + "THIRD-PARTIES-2d": [ + "TPM-05.5", + "TPM-08" + ], + "THREAT-1a": [ "THR-03", - "THR-04", - "THR-05", - "THR-07", - "THR-09" + "VPM-06.1" ], - "ID.RA-08": [ - "THR-01", - "THR-02", + "THREAT-1b": [ "THR-03", - "VPM-01", - "VPM-02", - "VPM-03" + "VPM-03", + "VPM-03.1" ], - "DE": [ - "THR-01", - "THR-02", + "THREAT-1e": [ "THR-03", - "THR-07", - "THR-09", - "THR-10" + "VPM-01.1", + "VPM-06.1", + "VPM-06.2" ], - "DE.AE-07": [ - "THR-01", + "THREAT-2f": [ + "THR-03" + ], + "THREAT-2j": [ + "THR-03" + ], + "THREAT-2k": [ "THR-03", - "THR-10" + "THR-03.1" ], - "ID.RA-04": [ - "THR-09", - "THR-10" - ] - }, - "general-oecd-privacy-principles-2010": { - "1": [ - "PRI-03", - "PRI-03.7", - "PRI-04.1" + "RISK-2k": [ + "THR-03" ], - "2": [ - "PRI-10" + "THREAT-1i": [ + "THR-03.1", + "VPM-04", + "VPM-05.3" ], - "3": [ - "PRI-02.1" + "THREAT-2b": [ + "THR-03.1", + "VPM-03", + "VPM-03.1" ], - "4": [ - "PRI-03.9", - "PRI-05.4" + "THREAT-2h": [ + "THR-03.1" ], - "5": [ - "PRI-01.6" + "THREAT-1m": [ + "THR-06" ], - "6": [ - "PRI-01.3" + "THREAT-2c": [ + "THR-10" ], - "8": [ - "PRI-01", - "PRI-01.1" + "THREAT-2e": [ + "THR-10" ], - "4(a)": [ - "PRI-03" + "THREAT-2g": [ + "THR-10" ], - "4(b)": [ - "PRI-04.1" + "THREAT-2i": [ + "THR-10" ], - "7(a)": [ - "PRI-06" + "THREAT-1j": [ + "VPM-01" ], - "7(b)(i)": [ - "PRI-06.4" + "THREAT-1g": [ + "VPM-03", + "VPM-03.1" ], - "7(b)(ii)": [ - "PRI-06.4" + "THREAT-2d": [ + "VPM-03", + "VPM-04" ], - "7(b)(iii)": [ - "PRI-06.4" + "THREAT-1d": [ + "VPM-04" ], - "7(c)": [ - "PRI-06.4" + "THREAT-1l": [ + "VPM-05.1" ], - "7(d)": [ - "PRI-06.4" + "THREAT-1c": [ + "VPM-06" ], - "7(b)": [ - "PRI-06.7" + "THREAT-1f": [ + "VPM-06" ], - "7(b)(iv)": [ - "PRI-06.7" + "THREAT-1k": [ + "VPM-06" ] }, - "general-owasp-top-10-2025": { - "A05:2025": [ - "CFG-01", - "CFG-02", - "CFG-03", - "MON-01.7", - "EMB-01", - "EMB-05", - "EMB-06", - "END-16", - "IAO-02.2", - "IAO-04", - "PRI-07.1", - "SEA-01", - "SEA-01.1", - "SEA-03", - "SEA-03.2", - "SEA-04", - "SEA-04.1", - "SEA-04.2", - "SEA-04.3", - "SEA-05", - "SEA-06", - "SEA-07.2", - "SEA-08", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5", - "TPM-01", - "TPM-03", - "TPM-04", - "TPM-04.1", - "TPM-04.2", - "TPM-04.4", - "TPM-08", - "TPM-09", - "VPM-01", - "VPM-02", - "VPM-03", - "VPM-04", - "VPM-06" + "usa-federal-dow-cmmc-2-level-1": { + "MP.L1-B.1.VII": [ + "AST-01", + "AST-09", + "DCH-01", + "DCH-08", + "DCH-09" ], - "A01:2025": [ - "CFG-02", - "MON-01", - "MON-01.1", - "MON-01.2", - "MON-01.3", - "MON-01.4", - "MON-01.7", - "MON-01.8", - "MON-01.16", - "MON-08", - "EMB-01", - "END-16", + "AC.L1-B.1.IV": [ + "CLD-01", + "CLD-02", + "CLD-06", + "CLD-10", + "DCH-15", + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "WEB-01", + "WEB-02", + "WEB-04" + ], + "AC.L1-B.1.III": [ + "DCH-13", + "DCH-13.1", + "DCH-17" + ], + "SI.L1-B.1.XIII": [ + "END-01", + "END-04" + ], + "SI.L1-B.1.XV": [ + "END-04", + "END-04.7" + ], + "SI.L1-B.1.XIV": [ + "END-04.1" + ], + "AC.L1-B.1.I": [ "IAC-01", - "IAC-07", - "IAC-07.1", - "IAC-07.2", + "IAC-02", "IAC-08", - "IAC-09", - "IAC-09.1", - "IAC-09.2", - "IAC-09.3", - "IAC-09.5", - "IAC-09.6", - "IAC-15.6", - "IAC-16.1", - "IAC-17", + "IAC-15.1", "IAC-20", - "IAC-20.1", - "IAC-20.2", - "IAC-20.3", - "IAC-21", - "IAC-21.1", - "IAC-21.2", - "IAC-21.3", - "IAC-21.4", - "IAC-21.5", - "IAC-24", - "IAC-24.1", - "IAC-25", - "IAC-26", - "IAO-02.2", - "IAO-04", - "PRI-07.1", - "SEA-01", - "SEA-01.1", - "SEA-03", - "SEA-03.2", - "SEA-04", - "SEA-04.1", - "SEA-04.2", - "SEA-04.3", - "SEA-05", - "SEA-06", - "SEA-07.2", - "SEA-08", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5" - ], - "A02:2025": [ - "CFG-02", - "MON-01.7", - "CRY-01", - "EMB-01", - "IAO-02.2", - "IAO-04", - "PRI-07.1", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5", "TPM-01", - "TPM-03", - "TPM-04", - "TPM-04.1", - "TPM-04.2", - "TPM-04.4", - "TPM-08", - "TPM-09" + "TPM-05", + "TPM-05.2" ], - "A04:2025": [ - "CFG-02", - "CRY-01", - "CRY-03", - "CRY-04", - "CRY-05", - "CRY-08", - "CRY-09", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-02.3", - "TDA-04", - "TDA-04.1", - "TDA-05", - "TDA-06", - "TDA-06.2", - "TDA-06.3", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5" + "IA.L1-B.1.V": [ + "IAC-02", + "IAC-04", + "IAC-15.1" ], - "A06:2025": [ - "CFG-02", - "IAO-02.2", - "IAO-04", - "PRM-04", - "PRM-05", - "PRM-06", - "PRM-07", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5", - "TDA-17" + "IA.L1-B.1.VI": [ + "IAC-02", + "IAC-04", + "IAC-15.1" ], - "A09:2025": [ - "CFG-02", - "MON-01", - "MON-01.1", - "MON-01.2", - "MON-01.3", - "MON-01.4", - "MON-01.7", - "MON-01.8", - "MON-01.10", - "MON-01.16", - "MON-02", - "MON-02.1", - "MON-03", - "MON-03.2", - "MON-03.3", - "MON-03.4", - "MON-05", - "MON-06.1", - "MON-07", - "MON-07.1", - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-10", - "EMB-01", - "IAO-02.2", - "IAO-04", - "PRI-07.1", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5" + "AC.L1-B.1.II": [ + "IAC-08", + "IAC-15" ], - "A10:2025": [ - "CFG-02", - "EMB-01", - "IAO-02.2", - "IAO-04", - "PRI-07.1", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5", - "TDA-19" + "SC.L1-B.1.X": [ + "NET-01", + "NET-02.2", + "NET-03" ], - "A07:2025": [ - "IAC-01", - "IAC-02.1", - "IAC-02.2", - "IAC-02.3", - "IAC-03", - "IAC-03.1", - "IAC-03.2", - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-09", - "IAC-10.1", - "IAC-10.2", - "IAC-10.4", - "IAC-10.6", - "IAC-10.8", - "IAC-14", - "IAO-02.2", - "IAO-04", - "PRI-07.1", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5" + "SC.L1-B.1.XI": [ + "NET-06" ], - "A03:2025": [ - "RSK-09", - "RSK-09.1", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-04.2", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TPM-01", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-04.2", - "TPM-04.3", - "TPM-04.4", - "TPM-05" + "PE.L1-B.1.VIII": [ + "PES-02", + "PES-02.1", + "PES-03.4", + "PES-04", + "PES-12", + "PES-12.1", + "PES-12.2" ], - "A08:2025": [ - "TDA-01", - "TDA-01.1", - "TDA-01.2", - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-06", - "TDA-06.2", - "TDA-06.3", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5", - "TDA-18", - "TDA-19" + "PE.L1-B.1.IX": [ + "PES-03", + "PES-06", + "PES-06.1", + "PES-06.3" + ], + "SI.L1-B.1.XII": [ + "VPM-01", + "VPM-02", + "VPM-05" ] }, - "general-pci-dss-4-0-1": { - "12.4": [ - "GOV-01", - "GOV-04", - "CPL-01" + "usa-federal-dow-cmmc-2-level-1-aos": { + "MP.L1-B.1.VII[a]": [ + "DCH-09" + ], + "MP.L1-B.1.VII[b]": [ + "DCH-09" + ], + "AC.L1-B.1.III[a]": [ + "DCH-13" + ], + "AC.L1-B.1.III[b]": [ + "DCH-13" + ], + "AC.L1-B.1.III[c]": [ + "DCH-13" + ], + "AC.L1-B.1.III[d]": [ + "DCH-13" + ], + "AC.L1-B.1.III[e]": [ + "DCH-13" + ], + "AC.L1-B.1.III[f]": [ + "DCH-13" + ], + "AC.L1-B.1.IV[a]": [ + "DCH-15" + ], + "AC.L1-B.1.IV[b]": [ + "DCH-15" + ], + "AC.L1-B.1.IV[c]": [ + "DCH-15" + ], + "AC.L1-B.1.IV[d]": [ + "DCH-15" + ], + "AC.L1-B.1.IV[e]": [ + "DCH-15" + ], + "SI.L1-B.1.XIII[a]": [ + "END-04" + ], + "SI.L1-B.1.XIII[b]": [ + "END-04" ], - "A3.1.2": [ - "GOV-01" + "SI.L1-B.1.XV[a]": [ + "END-04" ], - "1.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SI.L1-B.1.XV[b]": [ + "END-04" ], - "2.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SI.L1-B.1.XIV[a]": [ + "END-04.1" ], - "3.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SI.L1-B.1.XV[c]": [ + "END-04.7" ], - "3.7.1": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "IA.L1-B.1.V[a]": [ + "IAC-02" ], - "3.7.2": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "IA.L1-B.1.V[c]": [ + "IAC-02" ], - "3.7.3": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "IA.L1-B.1.VI[a]": [ + "IAC-02" ], - "3.7.5": [ - "GOV-02", - "CRY-04", - "CRY-09", - "CRY-09.3", - "OPS-01.1" + "IA.L1-B.1.VI[b]": [ + "IAC-02" ], - "3.7.6": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "IA.L1-B.1.VI[c]": [ + "IAC-02" ], - "3.7.7": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "AC.L1-B.1.II[a]": [ + "IAC-15" ], - "3.7.8": [ - "GOV-02", - "HRS-03", - "OPS-01.1" + "AC.L1-B.1.II[b]": [ + "IAC-15" ], - "4.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "AC.L1-B.1.I[a]": [ + "IAC-20" ], - "5.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "AC.L1-B.1.I[b]": [ + "IAC-20" ], - "6.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "AC.L1-B.1.Ic]": [ + "IAC-20" ], - "7.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "AC.L1-B.1.I[d]": [ + "IAC-20" ], - "8.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "AC.L1-B.1.I[e]": [ + "IAC-20" ], - "8.3.8": [ - "GOV-02", - "IAC-01", - "OPS-01", - "OPS-01.1", - "SAT-01", - "SAT-02", - "SAT-03" + "AC.L1-B.1.I[f]": [ + "IAC-20" ], - "9.1.1": [ - "GOV-02", - "GOV-03", - "PES-01", - "OPS-01", - "OPS-01.1" + "IA.L1-B.1.V[b]": [ + "IAC-20" ], - "10.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC.L1-B.1.X[a]": [ + "NET-03" ], - "11.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC.L1-B.1.X[b]": [ + "NET-03" ], - "12.1": [ - "GOV-02", - "GOV-03" + "SC.L1-B.1.X[c]": [ + "NET-03" ], - "12.1.1": [ - "GOV-02", - "GOV-03" + "SC.L1-B.1.X[d]": [ + "NET-03" ], - "12.1.2": [ - "GOV-02", - "GOV-03" + "SC.L1-B.1.X[e]": [ + "NET-03" ], - "12.1.3": [ - "GOV-02", - "GOV-04", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1" + "SC.L1-B.1.X[f]": [ + "NET-03" ], - "1.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1", - "SAT-03", - "SAT-03.5" + "SC.L1-B.1.X[g]": [ + "NET-03" ], - "2.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "SC.L1-B.1.X[h]": [ + "NET-03" ], - "3.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "SC.L1-B.1.XI[a]": [ + "NET-06" ], - "4.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "SC.L1-B.1.XI[b]": [ + "NET-06" ], - "5.1.2": [ - "GOV-04", - "END-04.2", - "HRS-03", - "HRS-03.1" + "PE.L1-B.1.VIII[a]": [ + "PES-02" ], - "6.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "PE.L1-B.1.VIII[b]": [ + "PES-02" ], - "7.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "PE.L1-B.1.VIII[c]": [ + "PES-02" ], - "8.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "PE.L1-B.1.VIII[d]": [ + "PES-02" ], - "9.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1", + "PE.L1-B.1.IX[a]": [ "PES-03" ], - "10.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "PE.L1-B.1.IX[d]": [ + "PES-03" ], - "11.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "PE.L1-B.1.IX[e]": [ + "PES-03" ], - "12.1.4": [ - "GOV-04", - "IRO-10" + "PE.L1-B.1.IX[f]": [ + "PES-03" ], - "A3.1.1": [ - "GOV-04", - "CPL-01" + "PE.L1-B.1.IX[c]": [ + "PES-03.3" ], - "A3.1.3": [ - "GOV-04", - "HRS-03" + "PE.L1-B.1.IX[b]": [ + "PES-06.3" ], - "6.3.1": [ - "GOV-07", - "IAO-04", - "TDA-15", - "THR-03", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-05.1" + "SI.L1-B.1.XII[a]": [ + "VPM-01" ], - "A3.2.5": [ - "GOV-10", - "AST-04.1", - "AST-04.2", - "AST-04.3", - "DCH-06.3" + "SI.L1-B.1.XII[b]": [ + "VPM-01" ], - "A3.3": [ - "GOV-14" + "SI.L1-B.1.XII[c]": [ + "VPM-01" ], - "A3.3.3": [ - "GOV-14" + "SI.L1-B.1.XII[d]": [ + "VPM-01" ], - "6.3.2": [ - "AST-01", - "AST-02", - "AST-04.3", - "TDA-04.2", - "VPM-01.1", - "VPM-05.1" + "SI.L1-B.1.XII[e]": [ + "VPM-01" ], - "9.5.1": [ + "SI.L1-B.1.XII[f]": [ + "VPM-01" + ] + }, + "usa-federal-dow-cmmc-2-level-2": { + "CML2.-3.4.1": [ "AST-01", "AST-02", - "AST-06", - "AST-07", - "AST-15", - "AST-15.1", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "CFG-02" ], - "9.5.1.1": [ + "MPL2.-3.8.3": [ "AST-01", - "AST-02", - "AST-07" + "AST-09", + "DCH-01", + "DCH-08", + "DCH-09" ], - "11.2": [ - "AST-01", - "AST-02", - "CFG-02", - "MON-01.5", - "NET-02.2", - "NET-08.2", - "NET-12", - "NET-12.1", - "NET-15", - "NET-15.5" + "MPL2.-3.8.9": [ + "BCD-11", + "BCD-11.4" ], - "11.2.2": [ - "AST-01", - "AST-02", - "NET-02.2", - "NET-12.1", - "NET-15" + "CML2.-3.4.3": [ + "CHG-01", + "CHG-02" ], - "2.2.2": [ - "AST-03", - "IAC-10.8" + "CML2.-3.4.4": [ + "CHG-03" ], - "2.2.4": [ - "AST-03", - "CFG-03", - "RSK-06.2" + "CML2.-3.4.5": [ + "CHG-04", + "TDA-08" ], - "2.2.5": [ - "AST-03", - "TDA-02.6" + "ACL2.-3.1.22": [ + "CLD-01", + "CLD-02", + "CLD-06", + "CLD-10", + "DCH-15", + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "WEB-01", + "WEB-02", + "WEB-04" ], - "6.5.2": [ - "AST-03", - "CHG-01", - "CHG-02.2", - "CHG-03", - "CHG-06", - "CHG-06.1", - "IAC-10.8" + "SCL2.-3.13.2": [ + "CLD-03", + "SEA-01", + "SEA-03" ], - "1.2.3": [ - "AST-04", - "AST-04.2", - "NET-02.2", - "NET-06", - "NET-08.1", - "NET-12.1" + "CAL2.-3.12.1": [ + "CPL-02", + "CPL-02.1", + "CPL-03", + "IAO-02" ], - "1.2.4": [ - "AST-04", - "NET-06", - "NET-08.1", - "TDA-02.1" + "CAL2.-3.12.3": [ + "CPL-02", + "THR-01", + "THR-03" ], - "12.5.2.1": [ - "AST-04.2", - "AST-04.3", + "AUL2.-3.3.3": [ + "CFG-02", + "CFG-02.1", + "CFG-02.9", + "MON-01", + "MON-01.8", + "MON-01.16", + "MON-02" + ], + "CML2.-3.4.2": [ + "CFG-02" + ], + "CML2.-3.4.6": [ + "CFG-03" + ], + "CML2.-3.4.7": [ "CFG-03.1", - "TPM-05.5" + "CFG-03.2" ], - "12.5.1": [ - "AST-04.3", - "CPL-01.2", - "PRI-05.5" + "CML2.-3.4.8": [ + "CFG-03.3" ], - "9.4": [ - "AST-05", + "SCL2.-3.13.7": [ + "CFG-03.4" + ], + "CML2.-3.4.9": [ + "CFG-05", + "END-03" + ], + "SIL2.-3.14.6": [ + "MON-01", + "MON-01.3", + "NET-08" + ], + "SIL2.-3.14.3": [ + "MON-01.8", + "THR-01", + "THR-03" + ], + "AUL2.-3.3.1": [ + "MON-02", + "MON-10" + ], + "AUL2.-3.3.5": [ + "MON-02", + "MON-02.1" + ], + "AUL2.-3.3.6": [ + "MON-02", + "MON-06" + ], + "AUL2.-3.3.8": [ + "MON-02", + "MON-03.1", + "MON-08" + ], + "AUL2.-3.3.9": [ + "MON-02", + "MON-08.2" + ], + "SIL2.-3.14.7": [ + "MON-02.1", + "MON-11.3", + "MON-16", + "IRO-03" + ], + "AUL2.-3.3.2": [ + "MON-03" + ], + "AUL2.-3.3.4": [ + "MON-05" + ], + "AUL2.-3.3.7": [ + "MON-07.1", + "SEA-20" + ], + "SCL2.-3.13.11": [ + "CRY-01" + ], + "MPL2.-3.8.6": [ + "CRY-01.1", + "CRY-05" + ], + "SCL2.-3.13.8": [ + "CRY-01.1", + "CRY-03" + ], + "SCL2.-3.13.16": [ "CRY-05", - "CRY-05.1", - "DCH-01", - "DCH-06", - "DCH-06.1", - "DCH-06.4", - "DCH-07", - "DCH-08" + "END-02" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "SCL2.-3.13.10": [ + "CRY-08", + "CRY-09" ], - "9.5": [ - "AST-06", - "AST-07" + "MPL2.-3.8.1": [ + "DCH-01", + "DCH-06" ], - "9.5.1.2": [ - "AST-07", - "AST-08", - "AST-15.1" + "PEL2.-3.10.6": [ + "DCH-01.2", + "NET-14.5", + "PES-11" ], - "9.5.1.2.1": [ - "AST-08" + "ACL2.-3.1.3": [ + "DCH-03", + "IAC-08", + "NET-04", + "NET-18" ], - "9.4.7": [ - "AST-09", - "DCH-09", - "DCH-09.1", - "DCH-18", - "PRI-05" + "MPL2.-3.8.2": [ + "DCH-03" ], - "9.4.1.2": [ - "BCD-02.4", - "BCD-11", - "DCH-06", - "DCH-06.1", - "DCH-06.2" + "MPL2.-3.8.4": [ + "DCH-04" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "MPL2.-3.8.5": [ + "DCH-07" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "MAL2.-3.7.3": [ + "DCH-09" ], - "1.2.2": [ - "CHG-01", - "CHG-02", - "CHG-02.1" + "MPL2.-3.8.7": [ + "DCH-10" ], - "6.5": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2" + "MPL2.-3.8.8": [ + "DCH-10.2" ], - "6.5.1": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "OPS-01.1" + "ACL2.-3.1.20": [ + "DCH-13", + "DCH-13.1", + "DCH-17" ], - "6.5.3": [ - "CHG-01", - "TDA-07", - "TDA-08" + "ACL2.-3.1.21": [ + "DCH-13.2" ], - "12.4.2": [ - "CHG-01", - "CHG-02", - "CLD-12", - "CPL-01", - "CPL-01.1", - "CPL-03", - "CPL-03.2", - "CFG-02.1", - "CFG-03.1", - "MON-01.8", - "TPM-05", - "TPM-08" + "SIL2.-3.14.2": [ + "END-01", + "END-04" ], - "6.5.6": [ - "CHG-02", - "CHG-03", - "CFG-02.4", - "TDA-08", - "TDA-08.1", - "TDA-09" + "SIL2.-3.14.4": [ + "END-04.1" ], - "A3.2.2.1": [ - "CHG-02.2", - "CHG-06" + "SIL2.-3.14.5": [ + "END-04.7" ], - "10.7": [ - "CHG-02.4", - "CPL-02", - "CPL-03", - "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "IRO-01", - "MNT-03", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "TPM-11" + "SCL2.-3.13.13": [ + "END-10" ], - "A3.2.2": [ - "CHG-03", - "RSK-08", - "RSK-10" + "SCL2.-3.13.12": [ + "END-14" ], - "A3.2.3": [ - "CHG-03", - "CPL-01.2", - "TPM-05.5" + "PSL2.-3.9.2": [ + "HRS-01.1", + "HRS-08", + "HRS-09" ], - "1.2.8": [ - "CHG-04", - "CFG-02.6", - "NET-06", - "NET-08.1" + "PSL2.-3.9.1": [ + "HRS-04", + "HRS-04.1" ], - "10.7.3": [ - "CHG-06", - "CPL-02", - "CPL-03", - "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "IRO-01", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "TPM-11" + "ATL2.-3.2.1": [ + "HRS-04.2", + "SAT-02" ], - "1.2.1": [ - "CLD-01", - "CFG-02", - "CFG-02.5", - "NET-06", - "NET-08.1", - "SEA-03" + "ATL2.-3.2.2": [ + "HRS-04.2", + "SAT-03" ], - "12.8.1": [ - "CLD-01", - "NET-14", + "ACL2.-3.1.4": [ + "HRS-11" + ], + "ACL2.-3.1.1": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-15.1", + "IAC-20", "TPM-01", - "TPM-01.1", - "TPM-05.5" + "TPM-05", + "TPM-05.2" ], - "A1.1": [ - "CLD-06" + "IAL2.-3.5.1": [ + "IAC-02", + "IAC-04", + "IAC-15.1" ], - "A1.1.1": [ - "CLD-06" + "IAL2.-3.5.2": [ + "IAC-02", + "IAC-04", + "IAC-15.1" ], - "A1.1.2": [ - "CLD-06" + "IAL2.-3.5.4": [ + "IAC-02.2" ], - "A1.1.3": [ - "CLD-06" + "IAL2.-3.5.3": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3" ], - "A1.1.4": [ - "CLD-06", - "NET-06", - "NET-08.1" + "MAL2.-3.7.5": [ + "IAC-06", + "MNT-05", + "MNT-05.4" ], - "12.4.1": [ - "CLD-06.1", - "TPM-05.4" + "ACL2.-3.1.2": [ + "IAC-08", + "IAC-15" ], - "A1.2": [ - "CLD-06.2", - "CLD-06.3", - "CLD-06.4" + "IAL2.-3.5.5": [ + "IAC-09" ], - "A1.2.1": [ - "CLD-06.2" + "IAL2.-3.5.8": [ + "IAC-10" ], - "A1.2.2": [ - "CLD-06.3" + "IAL2.-3.5.9": [ + "IAC-10" ], - "A1.2.3": [ - "CLD-06.4", - "IRO-10", - "IAO-04", - "TDA-15" + "IAL2.-3.5.7": [ + "IAC-10.1" ], - "A3.1": [ - "CPL-01" + "IAL2.-3.5.10": [ + "IAC-10.5" ], - "12.5": [ - "CPL-01.2" + "IAL2.-3.5.11": [ + "IAC-11" ], - "12.5.2": [ - "CPL-01.2", - "CFG-03.1", - "NET-06", - "NET-08.1", - "TPM-04.4" + "IAL2.-3.5.6": [ + "IAC-15.3" ], - "A3.2": [ - "CPL-01.2" + "ACL2.-3.1.5": [ + "IAC-16", + "IAC-16.1", + "IAC-21", + "IAC-21.1", + "IAC-21.3" ], - "A3.2.1": [ - "CPL-01.2", - "NET-06", - "NET-08.1", - "TPM-05.5" + "ACL2.-3.1.6": [ + "IAC-21.2" ], - "10.7.1": [ - "CPL-02", - "CPL-03", - "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "END-16", - "IRO-01", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "SEA-04.1", - "TPM-11" + "ACL2.-3.1.7": [ + "IAC-21.4", + "IAC-21.5" ], - "10.7.2": [ - "CPL-02", - "CPL-03", - "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "IRO-01", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "TPM-11" + "ACL2.-3.1.8": [ + "IAC-22" ], - "11.1": [ - "CPL-03", - "CPL-03.2" + "ACL2.-3.1.10": [ + "IAC-24", + "IAC-24.1" ], - "1.2.7": [ - "CPL-03.2", - "CFG-03.1", - "NET-04.6", - "NET-06", - "NET-08.1" + "ACL2.-3.1.11": [ + "IAC-25" ], - "2.1": [ - "CFG-01", - "CFG-01.1" + "IRL2.-3.6.1": [ + "IRO-02", + "IRO-05" ], - "2.2": [ - "CFG-01", - "CFG-02" + "IRL2.-3.6.2": [ + "IRO-02" ], - "8.5": [ - "CFG-01", - "CFG-02", - "CFG-02.5", - "SEA-01" + "IRL2.-3.6.3": [ + "IRO-06" ], - "1.1": [ - "CFG-02", + "CAL2.-3.12.4": [ + "IAO-03", + "IAO-03.2" + ], + "CAL2.-3.12.2": [ + "IAO-05" + ], + "MAL2.-3.7.1": [ + "MNT-02" + ], + "MAL2.-3.7.2": [ + "MNT-04" + ], + "MAL2.-3.7.4": [ + "MNT-04.2" + ], + "MAL2.-3.7.6": [ + "MNT-06", + "MNT-06.1", + "MNT-06.2" + ], + "ACL2.-3.1.18": [ + "MDM-01", + "MDM-02", + "MDM-06", + "MDM-07" + ], + "ACL2.-3.1.19": [ + "MDM-03" + ], + "SCL2.-3.13.1": [ "NET-01", - "NET-04", - "PRM-04", - "PRM-05", - "SEA-01.1" + "NET-02.2", + "NET-03" ], - "1.2.6": [ - "CFG-02", - "CFG-03", - "NET-06", - "NET-08.1", - "RSK-06.2", - "TDA-02.6" + "SCL2.-3.13.6": [ + "NET-04.1" ], - "2.2.1": [ - "CFG-02" + "SCL2.-3.13.5": [ + "NET-06" ], - "8.3.2": [ - "CFG-02", - "CRY-01", - "CRY-03", - "CRY-05" + "SCL2.-3.13.9": [ + "NET-07" ], - "10.2": [ - "CFG-02", - "CFG-02.5", - "MON-01.4", - "MON-03", - "MON-03.2", - "MON-07" + "SCL2.-3.13.15": [ + "NET-09" ], - "10.2.1": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "SCL2.-3.13.14": [ + "NET-13" ], - "10.2.1.1": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "ACL2.-3.1.12": [ + "NET-14", + "NET-14.1", + "NET-14.5" ], - "10.2.1.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3", - "IAC-21.4" + "ACL2.-3.1.13": [ + "NET-14.2" ], - "10.2.1.3": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "ACL2.-3.1.14": [ + "NET-14.3" ], - "10.2.1.4": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "ACL2.-3.1.15": [ + "NET-14.4" ], - "10.2.1.5": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "ACL2.-3.1.16": [ + "NET-15" ], - "10.2.1.6": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "ACL2.-3.1.17": [ + "NET-15.1" ], - "10.2.1.7": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "PEL2.-3.10.2": [ + "PES-01", + "PES-05", + "PES-05.1", + "PES-05.2" ], - "10.2.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "PEL2.-3.10.1": [ + "PES-02", + "PES-02.1", + "PES-03.4", + "PES-12", + "PES-12.1", + "PES-12.2" ], - "10.6": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "PEL2.-3.10.3": [ + "PES-03", + "PES-06", + "PES-06.1", + "PES-06.3" + ], + "PEL2.-3.10.5": [ + "PES-03", + "PES-04" + ], + "PEL2.-3.10.4": [ + "PES-03.3" + ], + "RAL2.-3.11.1": [ + "RSK-04" + ], + "RAL2.-3.11.3": [ + "RSK-06", + "VPM-04", + "VPM-05" + ], + "SCL2.-3.13.3": [ + "SEA-03.2" + ], + "SCL2.-3.13.4": [ + "SEA-05" ], - "10.6.1": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "ACL2.-3.1.9": [ + "SEA-18", + "SEA-18.1", + "SEA-18.2" ], - "10.6.2": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "ATL2.-3.2.3": [ + "SAT-03.6", + "THR-05" ], - "10.6.3": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "SIL2.-3.14.1": [ + "VPM-01", + "VPM-02", + "VPM-05" ], - "1.5": [ - "CFG-02.5", - "END-01", - "END-02" + "RAL2.-3.11.2": [ + "VPM-06", + "VPM-06.3" + ] + }, + "usa-federal-dow-cmmc-2-level-3": { + "AC.L3-3.1.2E": [ + "AST-02", + "DCH-06.2", + "IAC-08", + "PES-03" ], - "1.5.1": [ - "CFG-02.5", - "CFG-03.4", - "DCH-13.1", - "END-01", - "END-02", - "END-05" + "IA.L3-3.5.3E": [ + "AST-02.5" ], - "1.2.5": [ - "CFG-03", - "NET-06", - "NET-08.1", - "TDA-02.5", - "TPM-04.2" + "AC.L3-3.1.3E": [ + "AST-02.8", + "AST-04", + "NET-02.3", + "NET-04" ], - "1.4": [ - "CFG-03", - "NET-02", - "NET-03", - "NET-03.8", - "NET-08.1" + "CM.L3-3.4.1E": [ + "AST-02.9" ], - "1.4.1": [ - "CFG-03", - "NET-02", - "NET-03", - "NET-03.8", - "NET-06", - "NET-08.1", - "NET-09", - "SEA-03" + "CM.L3-3.4.3E": [ + "AST-02.9" ], - "1.4.2": [ - "CFG-03", - "NET-03", - "NET-03.1", - "NET-04", - "NET-04.1", + "SI.L3-3.14.3E": [ + "AST-04.1", + "CPL-01.2", "NET-06", - "NET-08.1" + "NET-06.4" ], - "11.6.1": [ - "CFG-03.1", - "MON-01.7", - "END-06", - "WEB-13" + "SI.L3-3.14.1E": [ + "AST-18", + "CRY-13", + "TDA-01.2" ], - "12.3.1": [ - "CFG-03.1", - "RSK-01.1", - "RSK-03", + "RA.L3-3.11.5E": [ + "CPL-01.2", + "CPL-03", + "RSK-03.1", "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.2", - "RSK-07" + "THR-09" ], - "12.3.4": [ - "CFG-03.1", - "SEA-02.3", - "SEA-07.1" + "CM.L3-3.4.2E": [ + "CFG-02.2", + "CFG-02.8", + "CFG-06", + "CFG-06.1" ], - "12.6.2": [ - "CFG-03.1", - "SAT-01" + "SI.L3-3.14.6E": [ + "MON-01.1", + "THR-03", + "THR-07" ], - "12.6.3": [ - "CFG-03.1", - "HRS-03.1", - "HRS-05.7", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.6", - "SAT-04" + "RA.L3-3.11.2E": [ + "MON-11.3", + "THR-07" ], - "10.1": [ - "MON-01" + "PS.L3-3.9.2E": [ + "HRS-02.1", + "HRS-07", + "HRS-07.1", + "HRS-07.3" ], - "10.4.3": [ - "MON-01", - "MON-01.4", - "MON-01.8" + "IA.L3-3.5.1E": [ + "IAC-02.2", + "IAC-04" ], - "A3.3.1": [ - "MON-01", - "MON-05", - "IRO-09" + "IR.L3-3.6.2E": [ + "IRO-07" ], - "A3.5": [ - "MON-01", - "MON-01.11", - "IRO-01" + "RA.L3-3.11.4E": [ + "IAO-03" ], - "1.4.3": [ - "MON-01.1", - "NET-04", - "NET-08", - "NET-08.2" + "SC.L3-3.13.4E": [ + "NET-02", + "NET-03.7", + "PES-04.1", + "PES-12", + "PES-18" ], - "11.5": [ - "MON-01.1", - "MON-01.7", - "END-06", - "NET-08", - "SAT-03.2" + "RA.L3-3.11.1E": [ + "RSK-04", + "RSK-04.2", + "THR-03", + "THR-07" ], - "11.5.1": [ - "MON-01.1", - "NET-03", - "NET-08", - "SAT-03.2" + "RA.L3-3.11.7E": [ + "RSK-06", + "RSK-09" ], - "11.5.1.1": [ - "MON-01.1", - "MON-11.1", - "MON-15", - "NET-08", - "SAT-03.2" + "RA.L3-3.11.6E": [ + "RSK-06.1", + "RSK-09", + "RSK-09.1" ], - "10.4": [ - "MON-01.2", - "MON-01.4", - "MON-01.7", - "MON-01.8", - "MON-02", - "MON-02.2" + "IR.L3-3.6.1E": [ + "OPS-04" ], - "10.4.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", - "MON-02", - "MON-02.2" + "RA.L3-3.11.3E": [ + "OPS-06" ], - "10.4.1.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", - "MON-02", - "MON-02.1", - "MON-02.2" + "AT.L3-3.2.1E": [ + "SAT-02.2", + "SAT-03", + "SAT-03.2", + "SAT-03.6" ], - "10.3.4": [ - "MON-01.7", - "END-06" + "AT.L3-3.2.2E": [ + "SAT-03.1", + "SAT-03.6" ], - "11.5.2": [ - "MON-01.7", - "END-06" + "CA.L3-3.12.1E": [ + "VPM-07" + ] + }, + "usa-federal-doc-data-privacy-framework-2023": { + "II.4.a": [ + "GOV-15", + "PRI-01.6", + "SEA-01" ], - "10.4.2": [ - "MON-01.8" + "II.7.c": [ + "CPL-01" ], - "10.4.2.1": [ - "MON-01.8" + "III.5.a": [ + "CPL-01", + "CPL-01.3" ], - "3.1": [ - "MON-01.10", - "MON-16" + "III.5.b.i": [ + "CPL-01" ], - "A3.2.6.1": [ - "MON-01.11", - "MON-01.12", - "MON-16", - "MON-16.1", - "MON-16.3" + "II.7.b": [ + "CPL-01.3" ], - "10.3.3": [ - "MON-02", - "MON-02.2", - "MON-08.1" + "III.5.b.ii": [ + "CPL-05.2" ], - "12.10.5": [ - "MON-02.1", - "IRO-02", - "IRO-04", - "NET-12.1" + "III.8.c.i": [ + "DCH-03.1" ], - "6.4.2": [ - "MON-03", - "IAO-04", - "TDA-15", - "VPM-05.1", - "WEB-01", - "WEB-03" + "III.8.d.i": [ + "DCH-03.1" ], - "7.2.6": [ - "MON-03.7", - "IAC-20", - "IAC-20.1", - "IAC-20.2", - "IAC-21" + "III.14.d.i": [ + "DCH-03.1" ], - "10.3": [ - "MON-08", - "MON-08.2" + "III.14.a.i": [ + "DCH-23" ], - "10.3.1": [ - "MON-08", - "MON-08.2" + "III.14.g.i": [ + "DCH-23" ], - "10.3.2": [ - "MON-08", - "MON-08.2" + "III.9.b.iii": [ + "HRS-01", + "PRI-01.5" ], - "10.5": [ - "MON-10", - "DCH-18" + "III.15.a": [ + "PRI-01" ], - "10.5.1": [ - "MON-10", - "DCH-18", - "PRI-05" + "II.3.a": [ + "PRI-01.5", + "TPM-05" ], - "2.2.7": [ - "CRY-01", - "CRY-02", - "CRY-06", - "MNT-05.3" + "II.3.b": [ + "PRI-01.5", + "TPM-05" ], - "3.3.2": [ - "CRY-01", - "CRY-05" + "III.9.b.i": [ + "PRI-01.5" ], - "12.3.3": [ - "CRY-01", - "CRY-01.5" + "III.9.b.ii": [ + "PRI-01.5" ], - "3.6.1.1": [ - "CRY-02", - "CRY-09", - "IAC-12" + "III.9.c.i": [ + "PRI-01.5" ], - "3.6.1.2": [ - "CRY-02", - "CRY-09", - "IAC-12" + "III.9.d.i": [ + "PRI-01.5" ], - "4.2": [ - "CRY-03" + "III.9.d.ii": [ + "PRI-01.5" ], - "4.2.1": [ - "CRY-03", - "NET-12", - "NET-15.1" + "III.9.e.i": [ + "PRI-01.5" ], - "4.2.1.2": [ - "CRY-03", - "CRY-07", - "NET-12.1" + "III.10.a.i": [ + "PRI-01.5", + "TPM-05" ], - "A2.1": [ - "CRY-03", - "WEB-10" + "III.10.a.ii.1": [ + "PRI-01.5", + "TPM-05", + "TPM-05.2" ], - "A2.1.1": [ - "CRY-03", - "WEB-10" + "III.10.a.ii.2": [ + "PRI-01.5", + "TPM-05", + "TPM-05.2" ], - "A2.1.2": [ - "CRY-03", - "WEB-10" + "III.10.a.ii.3": [ + "PRI-01.5", + "TPM-05", + "TPM-05.2" ], - "3.5": [ - "CRY-05", - "DCH-01.2" + "III.10.a.iii": [ + "PRI-01.5", + "TPM-05", + "TPM-05.2" ], - "3.5.1.2": [ - "CRY-05" + "III.10.b.i": [ + "PRI-01.5" ], - "3.5.1.3": [ - "CRY-05" + "III.10.c.i": [ + "PRI-01.5" ], - "2.3.1": [ - "CRY-07", - "IAC-10.8", - "NET-12.1", - "NET-15.1" + "III.8.c.ii": [ + "PRI-01.7" ], - "2.3.2": [ - "CRY-07", - "CRY-09.3", - "NET-12.1", - "NET-15.1" + "III.14.e.i": [ + "PRI-01.7" ], - "3.6.1": [ - "CRY-08.1", - "CRY-09", - "CRY-09.3", - "CRY-09.4" + "II.1.a.i": [ + "PRI-02" ], - "3.5.1.1": [ - "CRY-09" + "II.1.a.ii": [ + "PRI-02" ], - "3.6": [ - "CRY-09" + "II.1.a.iii": [ + "PRI-02" ], - "3.6.1.3": [ - "CRY-09" + "II.1.a.iv": [ + "PRI-02", + "PRI-02.1" ], - "3.6.1.4": [ - "CRY-09" + "II.1.a.v": [ + "PRI-02" ], - "3.7": [ - "CRY-09", - "OPS-01.1" + "II.1.a.vi": [ + "PRI-02" ], - "3.7.4": [ - "CRY-09" + "II.1.a.vii": [ + "PRI-02" ], - "4.2.1.1": [ - "CRY-09" + "II.1.a.viii": [ + "PRI-02" ], - "3.7.9": [ - "CRY-09.6" + "II.1.a.ix": [ + "PRI-02" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "II.1.a.x": [ + "PRI-02" ], - "3.5.1": [ - "DCH-01.2" + "II.1.a.xi": [ + "PRI-02" ], - "9.4.2": [ - "DCH-02", - "RSK-02" + "II.1.a.xii": [ + "PRI-02" ], - "7.1": [ - "DCH-03.1", - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "II.1.a.xiii": [ + "PRI-02" ], - "3.4.1": [ - "DCH-03.2", - "END-16", - "PRI-05.3" + "II.1.b": [ + "PRI-02" ], - "9.1": [ - "DCH-06", - "DCH-06.1", - "PES-01", - "PES-02", - "PES-02.1", - "PES-03" + "III.11.d.i": [ + "PRI-02", + "PRI-06.4" ], - "9.4.5": [ - "DCH-06.2" + "III.11.d.ii": [ + "PRI-02" ], - "9.4.5.1": [ - "DCH-06.2" + "III.14.b.ii": [ + "PRI-02", + "PRI-03.2" ], - "A3.2.5.1": [ - "DCH-06.3" + "II.5.a": [ + "PRI-02.1", + "PRI-04", + "PRI-04.5", + "PRI-05.2" ], - "3.3": [ - "DCH-06.5" + "II.2.a": [ + "PRI-03" ], - "3.3.1": [ - "DCH-06.5" + "II.2.c": [ + "PRI-03", + "PRI-03.7", + "PRI-05.4" ], - "3.3.1.1": [ - "DCH-06.5" + "III.14.b.i": [ + "PRI-03.2" ], - "3.3.1.2": [ - "DCH-06.5" + "II.2.b": [ + "PRI-03.6" ], - "3.3.1.3": [ - "DCH-06.5" + "III.12.a": [ + "PRI-03.7" ], - "3.3.3": [ - "DCH-06.5" + "III.12.b": [ + "PRI-03.7" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "III.14.c.i": [ + "PRI-03.9" ], - "9.4.6": [ - "DCH-08", - "DCH-18", + "II.5.b": [ "PRI-05" ], - "1.4.4": [ - "DCH-15", - "NET-05.1" - ], - "3.2": [ - "DCH-18" + "II.6.a": [ + "PRI-06", + "PRI-06.1" ], - "3.2.1": [ - "DCH-18", - "TPM-04.4" + "III.8.a.i": [ + "PRI-06" ], - "11.4.1": [ - "DCH-18", - "IAO-04", - "TDA-15", - "VPM-07", - "VPM-07.1" + "III.8.a.i.1": [ + "PRI-06" ], - "5.1": [ - "END-01" + "III.8.a.i.2": [ + "PRI-06" ], - "5.2": [ - "END-04" + "III.8.a.i.3": [ + "PRI-06" ], - "5.2.1": [ - "END-04" + "III.8.a.iii": [ + "PRI-06" ], - "5.2.2": [ - "END-04" + "III.8.b.i": [ + "PRI-06" ], - "5.3": [ - "END-04", - "END-04.1", - "END-04.7" + "III.8.b.ii": [ + "PRI-06" ], - "5.3.1": [ - "END-04", - "END-04.1" + "III.8.d.ii": [ + "PRI-06" ], - "5.3.2": [ - "END-04", - "END-04.7" + "III.8.e.i": [ + "PRI-06" ], - "5.3.2.1": [ - "END-04", - "END-04.7" + "III.8.f.i": [ + "PRI-06" ], - "5.3.3": [ - "END-04", - "END-04.7" + "III.14.e.ii": [ + "PRI-06" ], - "5.3.4": [ - "END-04", - "END-04.3" + "II.7.a.i": [ + "PRI-06.4" ], - "5.3.5": [ - "END-04", - "END-04.7" + "III.8.i.i": [ + "PRI-06.4" ], - "5.2.3": [ - "END-04.6" + "III.8.g.i": [ + "PRI-07.5" ], - "5.2.3.1": [ - "END-04.6" + "III.8.h.i": [ + "PRI-07.5" ], - "5.4": [ - "END-08" + "II.7.a.ii": [ + "OPS-01.1" ], - "5.4.1": [ - "END-08" + "II.7.d": [ + "TPM-05", + "TPM-05.2" + ] + }, + "usa-federal-dow-zt-roadmap-1-1": { + "6.1.1": [ + "GOV-02" ], - "2.2.3": [ - "END-16", - "END-16.1", - "SEA-04.1" + "2.3.7": [ + "GOV-02.1", + "CRY-09.6", + "SEA-07.1" ], - "11.4.5": [ - "END-16", - "NET-06", - "NET-08.1", - "SEA-04.1", - "TDA-07", - "VPM-07", - "VPM-07.1" + "2.7.3": [ + "GOV-02.1", + "MON-01.2", + "END-06.8" ], - "11.4.6": [ - "END-16", - "NET-06", - "NET-08.1", - "SEA-04.1", - "TDA-07", - "VPM-07", - "VPM-07.1" + "4.7.6": [ + "AAT-01", + "CLD-15", + "DCH-27", + "NET-17" ], - "12.2": [ - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "6.4": [ + "AAT-01", + "AAT-32" ], - "12.2.1": [ - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "6.4.1": [ + "AAT-01" ], - "12.7": [ - "HRS-01", - "HRS-02", - "HRS-02.1", - "HRS-04", - "HRS-04.1" + "6.4.2": [ + "AAT-01", + "AAT-32" ], - "12.7.1": [ - "HRS-01", - "HRS-02", - "HRS-02.1", - "HRS-04", - "HRS-04.1" + "6.2": [ + "AAT-32" ], "6.2.2": [ - "HRS-03.2", - "IAO-04", - "SAT-03", - "SAT-03.8", - "TDA-06.3", - "TDA-13", - "TDA-15" - ], - "8.2.5": [ - "HRS-09", - "HRS-09.2", - "IAC-07.1", - "IAC-07.2", - "IAC-20.6" + "AAT-32" ], - "6.5.4": [ - "HRS-11" + "6.3": [ + "AAT-32" ], - "7.2": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "6.3.1": [ + "AAT-32" ], - "7.2.1": [ - "IAC-01", - "IAC-02", - "IAC-03", - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "7.6": [ + "AAT-32" ], - "7.3": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "6.2.1": [ + "AAT-32.1" ], - "7.3.1": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "6.5.1": [ + "AAT-32.1" ], - "7.3.2": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "6.7.4": [ + "AAT-32.1", + "OPS-06" ], - "7.3.3": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "2.2": [ + "AST-01", + "NET-14.7" ], - "8.1": [ - "IAC-01", - "IAC-02" + "2.1": [ + "AST-02", + "AST-31.3" ], - "8.2": [ - "IAC-01", - "IAC-02", - "IAC-09", - "IAC-09.1" + "2.1.1": [ + "AST-02", + "AST-02.9" ], - "8.3.3": [ - "IAC-01", - "IAC-02", - "IAC-10", - "IAC-10.1", - "IAC-28" + "3.1": [ + "AST-02" ], - "8.5.1": [ - "IAC-01", - "IAC-02.2", - "IAC-06", - "SEA-01" + "3.1.1": [ + "AST-02", + "TDA-04.2" ], - "8.6.1": [ - "IAC-01", - "IAC-05.1", - "IAC-15", - "IAC-15.7", - "IAC-19", - "IAC-20.3", - "IAC-21" + "4.1.1": [ + "AST-02.8", + "AST-04" ], - "A3.4": [ - "IAC-01" + "5.1": [ + "AST-02.8", + "AST-04" ], - "8.3": [ - "IAC-02", - "IAC-10", - "IAC-10.1" + "2.4": [ + "AST-16", + "NET-14", + "NET-14.7" ], - "8.3.9": [ - "IAC-02", - "IAC-10", - "IAC-10.1" + "2.4.2": [ + "AST-16", + "EMB-01", + "END-01", + "IAC-29" ], - "8.2.2": [ - "IAC-02.1", - "IAC-15.5", - "IAC-19" + "4.4.6": [ + "AST-28.1", + "MON-02.1" ], - "8.2.3": [ - "IAC-03.2", - "IAC-05", - "IAC-05.1", - "IAC-06", - "NET-14", - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.3" + "3.4.6": [ + "AST-31.3", + "THR-11" ], - "8.4": [ - "IAC-06" + "5.1.2": [ + "AST-31.3", + "DCH-05", + "NET-04.7" ], - "8.4.2": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4" + "5.2.4": [ + "AST-32" ], - "8.4.3": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2" + "7.2.4": [ + "AST-32", + "MON-02.3" ], - "8.4.1": [ - "IAC-06.1" + "7.1.1": [ + "CAP-01", + "CAP-03", + "CAP-05" ], - "7.2.3": [ - "IAC-07", - "IAC-07.1", - "IAC-16", - "IAC-21.3" + "6.6": [ + "CLD-04" ], - "8.2.4": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "IAC-10", - "IAC-15" + "6.6.2": [ + "CLD-04", + "CFG-02" ], - "8.3.5": [ - "IAC-07", - "IAC-10", - "IAC-10.1" + "6.6.3": [ + "CLD-04", + "CFG-02" ], - "1.3": [ - "IAC-08", - "IAC-21", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1", - "NET-15.1" + "3.4": [ + "CLD-04.1" ], - "7.2.2": [ - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "3.4.1": [ + "CLD-04.1" ], - "7.2.5": [ - "IAC-08", - "IAC-16", - "IAC-20", - "IAC-20.1", - "NET-14" + "4.7.4": [ + "CLD-09", + "CLD-15", + "DCH-27", + "NET-17" ], - "8.2.1": [ - "IAC-09", - "IAC-09.1" + "4.7": [ + "CLD-15", + "CFG-08", + "DCH-27", + "IAC-21" ], - "8.3.1": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "4.7.1": [ + "CLD-15" ], - "8.3.7": [ - "IAC-10", - "IAC-10.1" + "4.7.2": [ + "CLD-15" ], - "8.3.10.1": [ - "IAC-10", - "IAC-10.1" + "4.7.3": [ + "CLD-15" ], - "8.3.11": [ - "IAC-10", - "IAC-10.2", - "IAC-10.5", - "IAC-10.7", - "IAC-18", - "PES-02", - "PES-02.1" + "4.7.5": [ + "CLD-15" ], - "8.6.3": [ - "IAC-10", - "IAC-10.1" + "4.7.7": [ + "CLD-15", + "DCH-27", + "NET-17" ], - "8.3.6": [ - "IAC-10.1" + "6.6.1": [ + "CPL-01", + "CPL-03" ], - "8.6.2": [ - "IAC-10.6" + "1.8.2": [ + "CFG-02", + "IAC-10" ], - "8.2.8": [ - "IAC-14", - "IAC-24", - "IAC-25", - "NET-07" + "2.5.1": [ + "CFG-02", + "CFG-02.2", + "NET-14.7" ], - "8.3.10": [ - "IAC-15", - "WEB-06" + "3.5": [ + "MON-01" ], - "8.6": [ - "IAC-15", - "IAC-15.7", - "IAC-20.3", - "IAC-21" + "7.3.1": [ + "MON-01" ], - "8.2.6": [ - "IAC-15.3" + "2.7.2": [ + "MON-01.2", + "END-01.1", + "END-06.2", + "END-06.8" ], - "7.2.4": [ - "IAC-16.1", - "IAC-17" + "5.2.2": [ + "MON-01.2", + "NET-04.7", + "NET-06.7" ], - "7.2.5.1": [ - "IAC-17" + "7.2": [ + "MON-01.2" ], - "A3.4.1": [ - "IAC-17" + "7.2.1": [ + "MON-01.2" ], - "3.4": [ - "IAC-21" + "2.3.3": [ + "MON-01.7", + "IAC-29" ], - "3.4.2": [ - "IAC-21", - "NET-14" + "2.3.5": [ + "MON-01.7", + "IAC-29", + "NET-14.7" ], - "8.3.4": [ - "IAC-22" + "7.1.2": [ + "MON-01.16" ], - "12.10": [ - "IRO-01", - "IRO-02", - "IRO-02.4", - "IRO-04" + "3.5.1": [ + "MON-02", + "MON-02.1", + "MON-02.3" ], - "A3.3.1.2": [ - "IRO-02", - "IRO-13", - "RSK-06", - "TPM-09", - "VPM-02" + "3.5.2": [ + "MON-02", + "MON-02.1", + "MON-02.3" ], - "12.10.7": [ - "IRO-04", - "IRO-12", - "IRO-12.3" + "7.1": [ + "MON-02", + "MON-02.7", + "MON-03" ], - "12.10.2": [ - "IRO-04.2", - "IRO-06" + "4.4.3": [ + "MON-02.1", + "MON-18" ], - "12.10.6": [ - "IRO-04.2", - "IRO-13" + "4.4.4": [ + "MON-02.1", + "MON-18" ], - "12.10.4": [ - "IRO-05" + "4.4.5": [ + "MON-02.1", + "MON-18" ], - "12.10.4.1": [ - "IRO-05" + "7.2.2": [ + "MON-02.1" ], - "12.10.3": [ - "IRO-07" + "7.1.3": [ + "MON-02.2", + "MON-06.2" ], - "A3.2.5.2": [ - "IRO-12", - "IRO-12.3" + "7.2.3": [ + "MON-02.2", + "MON-02.3" ], - "6.2.1": [ - "IAO-04", - "SEA-01", - "TDA-01", - "TDA-02.3", - "TDA-05", - "TDA-06", - "TDA-15" + "1.6.1": [ + "MON-16" ], - "6.2.3": [ - "IAO-04", - "TDA-06.5", - "TDA-09", - "TDA-15" + "1.6.2": [ + "MON-16", + "IAC-29" ], - "6.2.3.1": [ - "IAO-04", - "TDA-09", - "TDA-15" + "1.6.3": [ + "MON-16", + "IAC-29" ], - "6.2.4": [ - "IAO-04", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TDA-15" + "2.3.1": [ + "MON-16", + "IAC-29" ], - "6.4.1": [ - "IAO-04", - "TDA-15", - "VPM-05.1", - "VPM-06", - "VPM-06.6", - "WEB-01", - "WEB-03" + "2.3.2": [ + "MON-16", + "IAC-29" ], - "11.4.4": [ - "IAO-04", - "TDA-15", - "VPM-07" + "7.2.5": [ + "MON-16", + "THR-11" ], - "12.4.2.1": [ - "IAO-04", - "TDA-15", - "TPM-05", - "TPM-08" + "7.3.2": [ + "MON-16", + "THR-11" ], - "11.3": [ - "MNT-03", - "VPM-01", - "VPM-02", - "VPM-03", - "VPM-04", - "VPM-06" + "7.4": [ + "MON-16", + "THR-11" ], - "8.2.7": [ - "MNT-05", - "MNT-05.1", - "MNT-05.4", - "NET-14", - "NET-14.6" + "7.4.1": [ + "MON-16" ], - "1.2": [ - "NET-01", - "SEA-01", - "SEA-02" + "7.4.2": [ + "MON-16", + "THR-11" ], - "11.2.1": [ - "NET-01", - "NET-02.2", - "NET-03.1", - "NET-12.1", - "NET-15", - "NET-15.5" + "7.4.3": [ + "MON-16" ], - "1.3.3": [ - "NET-02.2", - "NET-03", - "NET-03.7", - "NET-04.1", - "NET-04.7", - "NET-06", - "NET-08.1", - "NET-12.1" + "7.4.4": [ + "MON-16" ], - "2.3": [ - "NET-02.2", - "NET-12.1", - "NET-15" + "4.5": [ + "CRY-01", + "CRY-03", + "CRY-05", + "DCH-27" ], - "1.4.5": [ - "NET-03.3", - "VPM-06.8" + "1.9.1": [ + "CRY-08", + "IAC-01.2", + "IAC-10.2" ], - "1.3.2": [ - "NET-03.5", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "2.1.2": [ + "CRY-08", + "IAC-04", + "IAC-10.2" ], - "1.3.1": [ - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "2.3.6": [ + "CRY-08", + "CRY-09" ], - "A3.2.4": [ - "NET-06", - "NET-08.1", - "VPM-07" + "5.4.4": [ + "DCH-01.2" ], "4.1": [ - "NET-12" + "DCH-02", + "TDA-06.2" ], - "4.2.2": [ - "NET-12.2" + "4.2": [ + "DCH-02", + "PRI-11" ], - "A3.2.6": [ - "NET-17" + "4.3.3": [ + "DCH-05", + "PRI-11" ], - "9.2": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1" + "4.3.5": [ + "DCH-05" ], - "9.2.1": [ - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1", - "PES-03.3" + "1.6": [ + "DCH-05.1", + "IAC-29" ], - "9.3": [ - "PES-02", - "PES-02.1", - "PES-03.1" + "4.3.4": [ + "DCH-27", + "NET-17" ], - "9.3.1": [ - "PES-02", - "PES-02.1", - "PES-03.1" + "4.4.2": [ + "DCH-27", + "HRS-05.1" ], - "9.3.1.1": [ - "PES-02.1", - "PES-04", - "PES-04.1" + "4.5.1": [ + "DCH-27" ], - "9.2.4": [ - "PES-03.2", - "PES-12" + "4.5.2": [ + "DCH-27" ], - "9.2.1.1": [ - "PES-03.3", - "PES-05", - "PES-05.1", - "PES-05.2" + "4.5.3": [ + "DCH-27" ], - "9.3.2": [ - "PES-06", - "PES-06.1", - "PES-06.2", - "PES-06.3", - "OPS-01", - "OPS-01.1" + "4.5.4": [ + "DCH-27" ], - "9.3.3": [ - "PES-06", - "PES-06.6" + "4.5.5": [ + "DCH-27" ], - "9.3.4": [ - "PES-06", - "PES-06.4", - "PES-06.5" + "2.4.3": [ + "END-01", + "NET-14.7" ], - "9.2.2": [ - "PES-12", - "PES-12.1", - "PES-12.2" + "2.4.4": [ + "END-01", + "NET-14.7" ], - "9.2.3": [ - "PES-12", - "PES-12.1", - "PES-12.2" + "2.6": [ + "END-01.1" ], - "12.9.1": [ - "PRI-01.6", - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.4" + "2.6.1": [ + "END-01.1" ], - "6.5.5": [ - "PRI-05.1", - "PRI-05.4", - "TDA-10" + "2.6.2": [ + "END-01.1" ], - "A3.1.4": [ - "PRI-08", - "SAT-01" + "2.6.3": [ + "END-01.1" ], - "12.3": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-05", - "RSK-06" + "2.7": [ + "END-01.1", + "END-06.2" ], - "12.3.2": [ - "RSK-01.1", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-06.2", - "RSK-07" + "2.3.4": [ + "END-06.2" ], - "6.1": [ - "SEA-01" + "2.7.1": [ + "END-06.2" ], - "6.2": [ - "SEA-01", - "TDA-01", - "TDA-02.3", - "TDA-05", - "TDA-06" + "1.1.1": [ + "IAC-01", + "IAC-01.2", + "IAC-28" ], - "A3.3.2": [ - "SEA-02.3" + "1.2.4": [ + "IAC-01" ], - "9.5.1.3": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "1.2.5": [ + "IAC-01" ], - "12.6": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "1.5.2": [ + "IAC-01" ], - "12.6.1": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "1.5.3": [ + "IAC-01" ], - "12.6.3.1": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "1.5.4": [ + "IAC-01" ], - "12.6.3.2": [ - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "1.9": [ + "IAC-01", + "IAC-01.2", + "IAC-10.2" ], - "2.2.6": [ - "TDA-05.1" + "1.2.1": [ + "IAC-01.2", + "IAC-16", + "IAC-29" ], - "12.8": [ - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "2.1.3": [ + "IAC-01.2", + "IAC-04", + "IAC-13.2" ], - "12.9": [ - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.4" + "2.1.4": [ + "IAC-01.2", + "IAC-04", + "IAC-13.2" ], - "12.9.2": [ - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.4" + "1.1": [ + "IAC-01.3" ], - "A2.1.3": [ - "TPM-01" + "1.8.1": [ + "IAC-02.3", + "IAC-10.1" ], - "12.8.2": [ - "TPM-04", - "TPM-05", - "TPM-05.4" + "1.3": [ + "IAC-06" ], - "12.8.3": [ - "TPM-04.1" + "1.3.1": [ + "IAC-06" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "1.3.3": [ + "IAC-06", + "IAC-29" ], - "12.5.3": [ - "TPM-05.5" + "1.3.2": [ + "IAC-06.4" ], - "12.8.4": [ - "TPM-08" + "1.9.3": [ + "IAC-06.5", + "IAC-10.12" ], - "6.3": [ - "THR-01", - "VPM-01", - "VPM-05.1" + "1.2": [ + "IAC-08", + "IAC-29" ], - "A3.5.1": [ - "THR-01" + "1.9.2": [ + "IAC-10.12" ], - "6.3.3": [ - "VPM-01", - "VPM-04", - "VPM-05", - "VPM-05.1" + "1.5": [ + "IAC-13.2" ], - "11.3.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.1", - "VPM-06.2", - "VPM-06.7" + "1.5.1": [ + "IAC-13.2" ], - "11.3.1.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06" + "1.8": [ + "IAC-13.3", + "IAC-29" ], - "11.3.1.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.7" + "1.8.4": [ + "IAC-13.3", + "IAC-29" ], - "11.3.1.3": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.7" + "1.2.2": [ + "IAC-16", + "IAC-29" ], - "11.3.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.6" + "1.4": [ + "IAC-16" ], - "11.3.2.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.2", - "VPM-06.6" + "1.4.1": [ + "IAC-16" ], - "6.4": [ - "VPM-05.1", - "WEB-01", - "WEB-03" + "1.4.2": [ + "IAC-16", + "IAC-29" ], - "6.4.3": [ - "VPM-05.1", - "WEB-01.1" + "1.4.3": [ + "IAC-16" ], - "11.4": [ - "VPM-07" + "1.4.4": [ + "IAC-16", + "IAC-29" ], - "11.4.2": [ - "VPM-07", - "VPM-07.1" + "1.8.3": [ + "IAC-16.3" ], - "11.4.3": [ - "VPM-07", - "VPM-07.1" + "1.7.1": [ + "IAC-17" ], - "11.4.7": [ - "VPM-07" + "1.7": [ + "IAC-21" ], - "11.6": [ - "WEB-13" - ] - }, - "general-pci-dss-4-0-1-saq-a": { - "3.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "1.2.3": [ + "IAC-29" ], - "6.3.1": [ - "GOV-07", - "IAO-04", - "TDA-15", - "THR-03", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-05.1" + "5.2.5": [ + "IAC-29.1" ], - "2.2.2": [ - "AST-03", - "IAC-10.8" + "6.1.3": [ + "IAC-29.1", + "IAC-29.2" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "6.1.2": [ + "IAC-29.2" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "6.1.4": [ + "IAC-29.2" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "6.7.2": [ + "IRO-02", + "IRO-02.4" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "6.7.1": [ + "IRO-04", + "OPS-01.1" ], - "11.6.1": [ - "CFG-03.1", - "MON-01.7", - "END-06", - "WEB-13" + "5.1.1": [ + "NET-01", + "NET-01.1" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "6.2.3": [ + "NET-01.1" ], - "9.4.2": [ - "DCH-02", - "RSK-02" + "4.4": [ + "NET-04.5" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "3.4.2": [ + "NET-04.7" ], - "9.4.6": [ - "DCH-08", - "DCH-18", - "PRI-05" + "5.2": [ + "NET-04.7" ], - "3.2.1": [ - "DCH-18", - "TPM-04.4" + "6.1": [ + "NET-04.7" ], - "8.2.5": [ - "HRS-09", - "HRS-09.2", - "IAC-07.1", - "IAC-07.2", - "IAC-20.6" + "5.2.3": [ + "NET-06" ], - "8.3.9": [ - "IAC-02", - "IAC-10", - "IAC-10.1" + "5.3": [ + "NET-06" ], - "8.2.2": [ - "IAC-02.1", - "IAC-15.5", - "IAC-19" + "5.3.2": [ + "NET-06" ], - "8.3.5": [ - "IAC-07", - "IAC-10", - "IAC-10.1" + "3.4.7": [ + "NET-06.6", + "NET-06.7" ], - "8.2.1": [ - "IAC-09", - "IAC-09.1" + "5.3.1": [ + "NET-06.6" ], - "8.3.1": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "5.4": [ + "NET-06.6" ], - "8.3.7": [ - "IAC-10", - "IAC-10.1" + "5.4.1": [ + "NET-06.6" ], - "8.3.6": [ - "IAC-10.1" + "5.4.2": [ + "NET-06.6", + "NET-06.7" ], - "12.8.2": [ - "TPM-04", - "TPM-05", - "TPM-05.4" + "5.4.3": [ + "NET-06.6" ], - "12.8.3": [ - "TPM-04.1" + "5.2.1": [ + "NET-06.7" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "2.2.2": [ + "NET-14.3", + "NET-14.7" ], - "12.8.4": [ - "TPM-08" + "2.4.1": [ + "NET-14.3", + "NET-14.7" ], - "6.3.3": [ - "VPM-01", - "VPM-04", - "VPM-05", - "VPM-05.1" + "2.2.1": [ + "NET-14.7" ], - "11.3.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.6" + "4.4.1": [ + "NET-17" ], - "11.3.2.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.2", - "VPM-06.6" + "4.6": [ + "NET-17" ], - "6.4.3": [ - "VPM-05.1", - "WEB-01.1" - ] - }, - "general-pci-dss-4-0-1-saq-a-ep": { - "1.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "4.6.1": [ + "NET-17" ], - "2.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "4.6.2": [ + "NET-17" ], - "3.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "4.6.3": [ + "NET-17" ], - "4.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "4.6.4": [ + "NET-17" ], - "5.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "4.3": [ + "PRI-11" ], - "6.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "4.3.2": [ + "PRI-11" ], - "8.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "2.3": [ + "PRM-02.1" ], - "8.3.8": [ - "GOV-02", - "IAC-01", - "OPS-01", - "OPS-01.1", - "SAT-01", - "SAT-02", - "SAT-03" + "3.3": [ + "RSK-01", + "RSK-09", + "TDA-04.2", + "TDA-09" ], - "12.1.1": [ - "GOV-02", - "GOV-03" + "3.4.3": [ + "SEA-13.1" ], - "12.1.2": [ - "GOV-02", - "GOV-03" + "6.7": [ + "OPS-04" ], - "12.1.3": [ - "GOV-02", - "GOV-04", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1" + "7.3": [ + "OPS-04" ], - "12.1.4": [ - "GOV-04", - "IRO-10" + "7.5": [ + "OPS-04", + "THR-03.1" ], - "6.3.1": [ - "GOV-07", - "IAO-04", - "TDA-15", - "THR-03", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-05.1" + "6.5.3": [ + "OPS-05" ], - "6.3.2": [ - "AST-01", - "AST-02", - "AST-04.3", - "TDA-04.2", - "VPM-01.1", - "VPM-05.1" + "6.5": [ + "OPS-06" ], - "2.2.2": [ - "AST-03", - "IAC-10.8" + "6.5.2": [ + "OPS-06" ], - "2.2.4": [ - "AST-03", - "CFG-03", - "RSK-06.2" + "3.2": [ + "TDA-01", + "TDA-06" ], - "2.2.5": [ - "AST-03", - "TDA-02.6" + "3.2.2": [ + "TDA-01", + "TDA-01.4" ], - "6.5.2": [ - "AST-03", - "CHG-01", - "CHG-02.2", - "CHG-03", - "CHG-06", - "CHG-06.1", - "IAC-10.8" + "3.2.1": [ + "TDA-01.4" ], - "1.2.3": [ - "AST-04", - "AST-04.2", - "NET-02.2", - "NET-06", - "NET-08.1", - "NET-12.1" + "3.4.4": [ + "TDA-04.2" ], - "1.2.4": [ - "AST-04", - "NET-06", - "NET-08.1", - "TDA-02.1" + "3.2.4": [ + "TDA-06" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "3.2.3": [ + "TDA-09" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "3.3.4": [ + "TDA-09" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "3.3.1": [ + "TDA-20", + "TDA-20.4" ], - "1.2.2": [ - "CHG-01", - "CHG-02", - "CHG-02.1" + "3.3.3": [ + "THR-03" ], - "6.5.1": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "OPS-01.1" + "6.7.3": [ + "THR-03" ], - "1.2.8": [ - "CHG-04", - "CFG-02.6", - "NET-06", - "NET-08.1" + "7.5.1": [ + "THR-03.1" ], - "1.2.1": [ - "CLD-01", - "CFG-02", - "CFG-02.5", - "NET-06", - "NET-08.1", - "SEA-03" + "7.5.2": [ + "THR-03.1" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "3.4.5": [ + "THR-11" ], - "1.2.7": [ - "CPL-03.2", - "CFG-03.1", - "NET-04.6", - "NET-06", - "NET-08.1" + "2.5": [ + "VPM-01", + "VPM-05", + "VPM-05.1" ], - "1.2.6": [ - "CFG-02", - "CFG-03", - "NET-06", - "NET-08.1", - "RSK-06.2", - "TDA-02.6" + "3.3.2": [ + "VPM-01" + ] + }, + "usa-federal-dow-zta-reference-architecture-2-0": { + "8.5": [ + "GOV-10" ], "2.2.1": [ - "CFG-02" + "AST-01", + "AST-02.6", + "AST-02.9" ], - "8.3.2": [ - "CFG-02", - "CRY-01", - "CRY-03", - "CRY-05" + "4.2": [ + "AST-03.2", + "AST-18", + "RSK-09", + "TDA-04.2", + "TDA-06.3" ], - "10.2.1": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "2.2.2": [ + "CHG-04.1", + "CFG-02.2" ], - "10.2.1.1": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "2.2.3": [ + "CFG-02.2" ], - "10.2.1.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3", - "IAC-21.4" + "6.5": [ + "MON-01" ], - "10.2.1.3": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "6.2": [ + "MON-01.2" ], - "10.2.1.4": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "1.2": [ + "MON-16", + "THR-11" ], - "10.2.1.5": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "6.7": [ + "MON-16" ], - "10.2.1.6": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "5.1": [ + "CRY-01" ], - "10.2.1.7": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "5.1.1": [ + "CRY-03" ], - "10.2.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "5.1.2": [ + "CRY-05" ], - "10.6.1": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "5.0": [ + "DCH-01", + "DCH-01.2", + "DCH-01.4", + "DCH-02" ], - "10.6.2": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "5.6": [ + "DCH-02" ], - "10.6.3": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "5.6.1": [ + "DCH-04.1" ], - "1.5.1": [ - "CFG-02.5", - "CFG-03.4", - "DCH-13.1", - "END-01", - "END-02", - "END-05" + "5.3": [ + "DCH-27" ], - "1.2.5": [ - "CFG-03", - "NET-06", - "NET-08.1", - "TDA-02.5", - "TPM-04.2" + "1.1": [ + "IAC-06" ], - "1.4.1": [ - "CFG-03", - "NET-02", - "NET-03", - "NET-03.8", - "NET-06", - "NET-08.1", - "NET-09", - "SEA-03" + "1.0": [ + "IAC-13.3" ], - "1.4.2": [ - "CFG-03", - "NET-03", - "NET-03.1", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "2.0": [ + "IAC-15.8" ], - "11.6.1": [ - "CFG-03.1", - "MON-01.7", - "END-06", - "WEB-13" + "2.3": [ + "IAC-16" ], - "12.3.1": [ - "CFG-03.1", - "RSK-01.1", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.2", - "RSK-07" + "2.4": [ + "IAC-16" ], - "10.4.3": [ - "MON-01", - "MON-01.4", - "MON-01.8" + "3.0": [ + "NET-01", + "NET-01.1", + "SEA-01", + "SEA-02", + "SEA-03" ], - "1.4.3": [ - "MON-01.1", - "NET-04", - "NET-08", - "NET-08.2" + "3.1": [ + "NET-06" ], - "11.5.1": [ - "MON-01.1", - "NET-03", - "NET-08", - "SAT-03.2" + "3.2": [ + "NET-06.6" ], - "10.4.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", - "MON-02", - "MON-02.2" + "2.2": [ + "NET-14.7" ], - "10.4.1.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", - "MON-02", - "MON-02.1", - "MON-02.2" + "5.4": [ + "NET-17" ], - "10.3.4": [ - "MON-01.7", - "END-06" + "3.2.1": [ + "PRM-06" ], - "11.5.2": [ - "MON-01.7", - "END-06" + "8.6": [ + "RSK-01" + ] + }, + "usa-federal-dow-dfars-252-204-7012": { + "252.204-7012(b)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "TPM-05", + "TPM-05.2" ], - "10.4.2": [ - "MON-01.8" + "252.204-7012(b)(2)(i)": [ + "GOV-15.1" ], - "10.4.2.1": [ - "MON-01.8" + "252.204-7012(b)(2)(ii)(A)": [ + "GOV-15.1" ], - "10.3.3": [ - "MON-02", - "MON-02.2", - "MON-08.1" + "252.204-7012(b)(3)": [ + "GOV-15.1" ], - "6.4.2": [ - "MON-03", - "IAO-04", - "TDA-15", - "VPM-05.1", - "WEB-01", - "WEB-03" + "252.204-7012(b)(2)(ii)(B)": [ + "GOV-17", + "IAO-05", + "RSK-06.2" ], - "10.3.1": [ - "MON-08", - "MON-08.2" + "252.204-7012(b)(1)(i)": [ + "CPL-01" ], - "10.3.2": [ - "MON-08", - "MON-08.2" + "252.204-7012(b)(1)(ii)": [ + "CPL-01" ], - "10.5.1": [ - "MON-10", - "DCH-18", - "PRI-05" + "252.204-7012(k)": [ + "CPL-01" ], - "2.2.7": [ - "CRY-01", - "CRY-02", - "CRY-06", - "MNT-05.3" + "252.204-7012(c)(1)(i)": [ + "IRO-02" ], - "4.2.1": [ - "CRY-03", - "NET-12", - "NET-15.1" + "252.204-7012(e)": [ + "IRO-08" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "252.204-7012(c)(1)(ii)": [ + "IRO-10.2" ], - "9.4.2": [ - "DCH-02", - "RSK-02" + "252.204-7012(c)(2)": [ + "IRO-10.2" ], - "3.3.1": [ - "DCH-06.5" + "252.204-7012(c)(3)": [ + "IRO-10.2" ], - "3.3.1.2": [ - "DCH-06.5" + "252.204-7012(d)": [ + "IRO-10.2" ], - "3.3.1.3": [ - "DCH-06.5" + "252.204-7012(f)": [ + "IRO-11.2" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "252.204-7012(g)": [ + "IRO-11.2" ], - "9.4.6": [ - "DCH-08", - "DCH-18", - "PRI-05" + "252.204-7012(b)(2)(ii)(C)": [ + "RSK-06.2" ], - "1.4.4": [ - "DCH-15", - "NET-05.1" + "252.204-7012(b)(2)(ii)(D)": [ + "TPM-01" ], - "3.2.1": [ - "DCH-18", - "TPM-04.4" + "252.204-7012(m)(1)": [ + "TPM-05" ], - "11.4.1": [ - "DCH-18", - "IAO-04", - "TDA-15", - "VPM-07", - "VPM-07.1" + "252.204-7012(m)(2)(i)": [ + "TPM-05.2" + ] + }, + "usa-federal-eo-14028": { + "4e(i)(F)": [ + "GOV-01", + "GOV-15", + "MON-01", + "IRO-01" ], - "5.2.1": [ - "END-04" + "4e(ii)": [ + "CPL-01.3" ], - "5.2.2": [ - "END-04" + "4e(v)": [ + "CPL-01.5" ], - "5.3.1": [ - "END-04", - "END-04.1" + "4e(ix)": [ + "CPL-01.5" ], - "5.3.2": [ - "END-04", - "END-04.7" + "4e(x)": [ + "CPL-01.5" ], - "5.3.2.1": [ - "END-04", - "END-04.7" + "4e(i)": [ + "CFG-02.4", + "TDA-07", + "TDA-08", + "TDA-08.1" ], - "5.3.3": [ - "END-04", - "END-04.7" + "4e(i)(B)": [ + "MON-01", + "MON-01.3", + "MON-01.4", + "MON-02.7", + "MON-03", + "MON-03.2" ], - "5.3.4": [ - "END-04", - "END-04.3" + "4e(i)(E)": [ + "CRY-01", + "TDA-02", + "TDA-02.4", + "TDA-06" ], - "5.3.5": [ - "END-04", - "END-04.7" + "4e(i)(C)": [ + "IAC-06" ], - "5.2.3": [ - "END-04.6" + "4e(i)(D)": [ + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-02.1", + "TDA-04.1", + "TDA-05", + "TDA-06.1", + "TDA-06.2", + "TDA-06.3", + "TDA-09.6" ], - "5.2.3.1": [ - "END-04.6" + "4e(iv)": [ + "TDA-01", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-15", + "THR-06", + "VPM-01", + "VPM-02" ], - "5.4.1": [ - "END-08" + "4e(iii)": [ + "TDA-01.1", + "TDA-02.3", + "TDA-04.2", + "TDA-06.3", + "TDA-06.4", + "TDA-09", + "TDA-14.1", + "TDA-15", + "TDA-20" ], - "2.2.3": [ - "END-16", - "END-16.1", - "SEA-04.1" + "4e(vii)": [ + "TDA-04.2" ], - "11.4.5": [ - "END-16", - "NET-06", - "NET-08.1", - "SEA-04.1", + "4e(i)(A)": [ "TDA-07", - "VPM-07", - "VPM-07.1" + "TDA-08" ], - "6.2.2": [ - "HRS-03.2", - "IAO-04", - "SAT-03", - "SAT-03.8", - "TDA-06.3", - "TDA-13", - "TDA-15" + "4e(vi)": [ + "TDA-20", + "TDA-20.1", + "TDA-20.3" ], - "8.2.5": [ - "HRS-09", - "HRS-09.2", - "IAC-07.1", - "IAC-07.2", - "IAC-20.6" + "4e(viii)": [ + "THR-06" + ] + }, + "usa-federal-law-facta-fcra-2023": { + "606(b)": [ + "HRS-07.1" ], - "8.3.3": [ - "IAC-01", - "IAC-02", - "IAC-10", - "IAC-10.1", - "IAC-28" + "623(a)(1)(A)": [ + "PRI-01.11" ], - "8.5.1": [ - "IAC-01", - "IAC-02.2", - "IAC-06", - "SEA-01" + "623(a)(1)(B)": [ + "PRI-01.11" ], - "8.6.1": [ - "IAC-01", - "IAC-05.1", - "IAC-15", - "IAC-15.7", - "IAC-19", - "IAC-20.3", - "IAC-21" + "623(a)(1)(B)(i)": [ + "PRI-01.11" ], - "8.3.9": [ - "IAC-02", - "IAC-10", - "IAC-10.1" + "623(a)(1)(B)(ii)": [ + "PRI-01.11" ], - "8.2.2": [ - "IAC-02.1", - "IAC-15.5", - "IAC-19" + "615(e)(2)(A)": [ + "THR-01" + ] + }, + "usa-federal-far-52-204-21": { + "52.204-21(b)(1)": [ + "GOV-01", + "GOV-02", + "GOV-04", + "GOV-04.1", + "GOV-15", + "DCH-01", + "DCH-01.2" ], - "8.4.2": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4" + "52.204-21(b)(1)(vii)": [ + "AST-01", + "AST-09", + "DCH-01", + "DCH-08", + "DCH-09" ], - "8.4.3": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2" + "52.204-21(b)(1)(iv)": [ + "CLD-01", + "CLD-02", + "CLD-06", + "CLD-10", + "DCH-15", + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "WEB-01", + "WEB-02", + "WEB-04" ], - "8.4.1": [ - "IAC-06.1" + "52.204-21(b)(1)(iii)": [ + "DCH-13", + "DCH-13.1", + "DCH-17" ], - "7.2.3": [ - "IAC-07", - "IAC-07.1", - "IAC-16", - "IAC-21.3" + "52.204-21(b)(1)(xiii)": [ + "END-01", + "END-04" ], - "8.2.4": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "IAC-10", - "IAC-15" + "52.204-21(b)(1)(xv)": [ + "END-04", + "END-04.7" ], - "8.3.5": [ - "IAC-07", - "IAC-10", - "IAC-10.1" + "52.204-21(b)(1)(xiv)": [ + "END-04.1" ], - "7.2.2": [ + "52.204-21(b)(1)(i)": [ + "IAC-01", + "IAC-02", "IAC-08", + "IAC-15.1", "IAC-20", - "IAC-20.1", - "IAC-21" + "TPM-01", + "TPM-05", + "TPM-05.2" ], - "7.2.5": [ - "IAC-08", - "IAC-16", - "IAC-20", - "IAC-20.1", - "NET-14" + "52.204-21(b)(1)(v)": [ + "IAC-02", + "IAC-04", + "IAC-15.1" ], - "8.2.1": [ - "IAC-09", - "IAC-09.1" + "52.204-21(b)(1)(vi)": [ + "IAC-02", + "IAC-04", + "IAC-15.1" ], - "8.3.1": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "52.204-21(b)(1)(ii)": [ + "IAC-08", + "IAC-15" ], - "8.3.7": [ - "IAC-10", - "IAC-10.1" + "52.204-21(b)(1)(x)": [ + "NET-01", + "NET-02.2", + "NET-03" ], - "8.3.11": [ - "IAC-10", - "IAC-10.2", - "IAC-10.5", - "IAC-10.7", - "IAC-18", + "52.204-21(b)(1)(xi)": [ + "NET-06" + ], + "52.204-21(b)(1)(viii)": [ "PES-02", - "PES-02.1" + "PES-02.1", + "PES-03.4", + "PES-04", + "PES-12", + "PES-12.1", + "PES-12.2" ], - "8.6.3": [ - "IAC-10", - "IAC-10.1" + "52.204-21(b)(1)(ix)": [ + "PES-03", + "PES-06", + "PES-06.1", + "PES-06.3" ], - "8.3.6": [ - "IAC-10.1" + "52.204-21(a)": [ + "SEA-02.1" ], - "8.6.2": [ - "IAC-10.6" + "52.204-21(b)(1)(xii)": [ + "VPM-01", + "VPM-02", + "VPM-05" + ] + }, + "usa-federal-far-52-204-25": { + "52.204-25(d)(2)(i)": [ + "GOV-17" ], - "8.2.8": [ - "IAC-14", - "IAC-24", - "IAC-25", - "NET-07" + "52.204-25(d)(2)(ii)": [ + "GOV-17" ], - "8.2.6": [ - "IAC-15.3" + "52.204-25(d)": [ + "GOV-17" ], - "7.2.4": [ - "IAC-16.1", - "IAC-17" + "52.204-25(b)(1)": [ + "AST-17" ], - "8.3.4": [ - "IAC-22" + "52.204-25(b)(2)": [ + "AST-17" + ] + }, + "usa-federal-far-52-204-27": { + "52.204-27(b)": [ + "AST-17" ], - "12.10.3": [ - "IRO-07" + "52.204-27(c)": [ + "TPM-05", + "TPM-05.2" + ] + }, + "usa-federal-sro-fca-crm-2023": { + "609.930(a)": [ + "GOV-01", + "GOV-08", + "GOV-09", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "DCH-01", + "RSK-01", + "RSK-01.1", + "RSK-01.2", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.1", + "RSK-06.2" ], - "6.2.1": [ - "IAO-04", - "SEA-01", - "TDA-01", - "TDA-02.3", - "TDA-05", - "TDA-06", - "TDA-15" + "609.930(d)": [ + "GOV-01", + "CPL-01", + "PRI-01" ], - "6.2.4": [ - "IAO-04", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TDA-15" + "609.930(b)(1)": [ + "GOV-01.1" ], - "6.4.1": [ - "IAO-04", - "TDA-15", - "VPM-05.1", - "VPM-06", - "VPM-06.6", - "WEB-01", - "WEB-03" + "609.930(b)(2)": [ + "GOV-01.1" ], - "11.4.4": [ - "IAO-04", - "TDA-15", - "VPM-07" + "609.930(e)": [ + "GOV-01.2" ], - "8.2.7": [ - "MNT-05", - "MNT-05.1", - "MNT-05.4", - "NET-14", - "NET-14.6" + "609.930(c)(5)": [ + "GOV-02", + "TPM-01" ], - "1.3.3": [ - "NET-02.2", - "NET-03", - "NET-03.7", - "NET-04.1", - "NET-04.7", - "NET-06", - "NET-08.1", - "NET-12.1" + "609.930(b)(3)": [ + "GOV-04", + "HRS-01", + "HRS-02", + "HRS-03", + "HRS-03.2" ], - "1.4.5": [ - "NET-03.3", - "VPM-06.8" + "609.930(c)(6)": [ + "GOV-09", + "CPL-02", + "CPL-02.1", + "CPL-02.2" ], - "1.3.2": [ - "NET-03.5", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "609.930(c)(3)(iii)": [ + "BCD-01", + "BCD-02.1", + "IRO-02" ], - "1.3.1": [ - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "609.930(c)(1)(ii)": [ + "CPL-01", + "CPL-01.1", + "CPL-01.4", + "CPL-03.2" ], - "4.2.2": [ - "NET-12.2" + "609.930(c)(6)(iii)": [ + "CPL-01.4", + "CPL-03.2" ], - "9.2.1": [ - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1", - "PES-03.3" + "609.935(c)": [ + "CPL-01.4" ], - "12.6.1": [ + "609.930(c)(6)(i)": [ + "CPL-02" + ], + "609.930(c)(6)(ii)": [ + "CPL-03.1" + ], + "609.945": [ + "DCH-01", + "DCH-18" + ], + "609.930(c)(4)": [ + "HRS-01", + "HRS-01.1", + "HRS-03", + "HRS-03.1", + "HRS-05", + "HRS-05.1", + "HRS-05.7", + "HRS-06", + "HRS-06.1", "SAT-01", "SAT-02", "SAT-03", - "SAT-04" + "SAT-03.6", + "TPM-01", + "TPM-05", + "TPM-06" ], - "12.6.3.1": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "609.930(c)(3)": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-04.2" ], - "2.2.6": [ - "TDA-05.1" + "609.930(c)(3)(i)": [ + "IRO-02" ], - "12.8.2": [ + "609.930(c)(3)(ii)": [ + "IRO-02" + ], + "609.930(c)(3)(iv)": [ + "IRO-09" + ], + "609.930(c)(3)(v)": [ + "IRO-10", + "IRO-10.2" + ], + "609.930(c)(3)(vi)": [ + "IRO-10" + ], + "609.935(d)": [ + "PRM-01" + ], + "609.935(e)": [ + "PRM-01", + "PRM-05", + "PRM-06", + "PRM-07" + ], + "609.935": [ + "PRM-01.1" + ], + "609.935(a)": [ + "PRM-01.1" + ], + "609.935(b)": [ + "PRM-03" + ], + "609.930(c)(1)(i)": [ + "RSK-03" + ], + "609.930(c)(1)": [ + "RSK-04" + ], + "609.930(c)(5)(i)": [ + "TPM-02", + "TPM-03.2", "TPM-04", - "TPM-05", - "TPM-05.4" + "TPM-04.1" ], - "12.8.3": [ + "609.930(c)(5)(iii)": [ "TPM-04.1" ], - "12.8.5": [ + "609.930(c)(5)(ii)": [ "TPM-05", - "TPM-05.4" + "TPM-08" ], - "12.8.4": [ + "609.930(c)(5)(iv)": [ "TPM-08" ], - "6.3.3": [ + "609.930(c)(2)": [ "VPM-01", + "VPM-01.1", + "VPM-03", "VPM-04", - "VPM-05", - "VPM-05.1" + "VPM-05" + ] + }, + "usa-federal-fda-21-cfr-part-11-2025": { + "11.10": [ + "GOV-02", + "CHG-01", + "CHG-02", + "CPL-01", + "CPL-02", + "CPL-03", + "CPL-03.2", + "MON-01", + "MON-01.16", + "MON-02", + "MON-03", + "MON-03.2", + "MON-07", + "MON-07.1", + "MON-08", + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-08", + "CRY-09", + "DCH-01", + "DCH-18", + "HRS-03.2", + "HRS-05.1", + "IAC-01", + "IAC-02", + "IAC-04", + "IAC-08", + "IAC-21", + "IAO-01", + "MNT-01", + "SEA-01", + "SEA-02", + "SEA-03", + "OPS-01", + "OPS-01.1", + "OPS-03", + "SAT-01", + "SAT-03", + "SAT-03.5", + "TDA-09.4" ], - "11.3.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.6" + "11.30": [ + "GOV-15", + "IAO-03" ], - "11.3.2.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.2", - "VPM-06.6" + "11.10(k)(2)": [ + "CHG-02" + ], + "11.10(b)": [ + "CPL-01", + "CPL-02", + "CPL-03", + "CPL-03.2", + "MON-02", + "MON-03", + "MON-03.2", + "MON-07", + "MON-07.1", + "MON-08", + "DCH-01", + "IAO-01" + ], + "11.10(c)": [ + "CPL-01", + "CPL-02", + "CPL-03", + "CPL-03.2", + "MON-02", + "MON-03", + "MON-03.2", + "MON-07", + "MON-07.1", + "MON-08", + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "DCH-01", + "IAO-01" + ], + "11.10(a)": [ + "CPL-02", + "CPL-03", + "CPL-03.2", + "MON-01.7", + "DCH-01", + "IAO-01", + "IAO-01.1", + "IAO-02" ], - "6.4.3": [ - "VPM-05.1", - "WEB-01.1" + "11.300(e)": [ + "CPL-03.2" ], - "11.4.3": [ - "VPM-07", - "VPM-07.1" - ] - }, - "general-pci-dss-4-0-1-saq-b": { - "3.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "11.10(d)": [ + "CFG-02", + "DCH-01", + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-20", + "IAC-21" ], - "12.1.1": [ - "GOV-02", - "GOV-03" + "11.50(a)": [ + "CFG-02" ], - "12.1.2": [ - "GOV-02", - "GOV-03" + "11.50(a)(1)": [ + "CFG-02" ], - "12.1.3": [ - "GOV-02", - "GOV-04", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1" + "11.50(a)(2)": [ + "CFG-02" ], - "9.5.1": [ - "AST-01", - "AST-02", - "AST-06", - "AST-07", - "AST-15", - "AST-15.1", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "11.50(a)(3)": [ + "CFG-02" ], - "9.5.1.1": [ - "AST-01", - "AST-02", - "AST-07" + "11.50(b)": [ + "CFG-02" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "11.70": [ + "CFG-02" ], - "9.5.1.2": [ - "AST-07", - "AST-08", - "AST-15.1" + "11.200(a)(1)": [ + "CFG-02" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "11.200(b)": [ + "CFG-02" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "11.10(e)": [ + "MON-01", + "MON-02", + "MON-03", + "MON-03.2", + "MON-07", + "MON-07.1", + "MON-08", + "DCH-18" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "11.300(c)": [ + "CRY-09" ], - "9.4.1": [ + "11.10(k)": [ "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" - ], - "9.4.2": [ - "DCH-02", - "RSK-02" + "OPS-01.1" ], - "3.4.1": [ - "DCH-03.2", - "END-16", - "PRI-05.3" + "11.10(k)(1)": [ + "DCH-03.1" ], - "3.3.1": [ - "DCH-06.5" + "11.10(i)": [ + "HRS-01", + "HRS-02", + "HRS-02.1", + "HRS-03", + "HRS-03.2", + "HRS-04.2" ], - "3.3.1.1": [ - "DCH-06.5" + "11.10(j)": [ + "HRS-01", + "HRS-01.1", + "HRS-04.2", + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "3.3.1.2": [ - "DCH-06.5" + "11.10(g)": [ + "IAC-01", + "IAC-17" ], - "3.3.1.3": [ - "DCH-06.5" + "11.100(a)": [ + "IAC-01" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "11.300(d)": [ + "IAC-10.5" ], - "9.4.6": [ - "DCH-08", - "DCH-18", - "PRI-05" + "11.100(b)": [ + "IAC-28" ], - "7.2.2": [ - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "11.10(f)": [ + "OPS-01.1" ], - "9.5.1.3": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "11.10(h)": [ + "TDA-18" + ] + }, + "usa-federal-gsa-fedramp-5-low": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" ], - "12.6.1": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "12.8.2": [ - "TPM-04", - "TPM-05", - "TPM-05.4" + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "12.8.3": [ - "TPM-04.1" + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "12.8.4": [ - "TPM-08" - ] - }, - "general-pci-dss-4-0-1-saq-b-ip": { - "3.1.1": [ + "CM-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "CFG-01" ], - "8.1.1": [ + "CP-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "BCD-01" ], - "9.1.1": [ + "IA-01": [ "GOV-02", "GOV-03", - "PES-01", - "OPS-01", - "OPS-01.1" + "IAC-01" ], - "12.1.1": [ + "IR-01": [ "GOV-02", - "GOV-03" + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "12.1.2": [ + "MA-01": [ "GOV-02", - "GOV-03" + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "12.1.3": [ + "MP-01": [ "GOV-02", - "GOV-04", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1" + "GOV-03", + "DCH-01" ], - "6.3.1": [ - "GOV-07", - "IAO-04", - "TDA-15", - "THR-03", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-05.1" + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "9.5.1": [ - "AST-01", - "AST-02", - "AST-06", - "AST-07", - "AST-15", - "AST-15.1", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "9.5.1.1": [ - "AST-01", - "AST-02", - "AST-07" + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "2.2.2": [ - "AST-03", - "IAC-10.8" + "PT-01": [ + "GOV-02", + "GOV-03", + "PRI-01", + "SEA-01" ], - "1.2.3": [ - "AST-04", - "AST-04.2", - "NET-02.2", - "NET-06", - "NET-08.1", - "NET-12.1" + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" ], - "9.5.1.2": [ - "AST-07", - "AST-08", - "AST-15.1" + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "PL-09": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" ], - "1.2.6": [ - "CFG-02", - "CFG-03", - "NET-06", - "NET-08.1", - "RSK-06.2", - "TDA-02.6" + "PM-06": [ + "GOV-04", + "GOV-05" ], - "1.2.5": [ - "CFG-03", - "NET-06", - "NET-08.1", - "TDA-02.5", - "TPM-04.2" + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" ], - "1.4.2": [ - "CFG-03" + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "1.4.3": [ - "MON-01.1", - "NET-04", - "NET-08", - "NET-08.2" + "PM-15": [ + "GOV-07", + "THR-01" ], - "2.2.7": [ - "CRY-01", - "CRY-02", - "CRY-06", - "MNT-05.3" + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" ], - "A2.1.1": [ - "CRY-03", - "WEB-10" + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" ], - "2.3.1": [ - "CRY-07", - "IAC-10.8", - "NET-12.1", - "NET-15.1" + "PM-05": [ + "AST-01", + "AST-02" ], - "2.3.2": [ - "CRY-07", - "CRY-09.3", - "NET-12.1", - "NET-15.1" + "CM-08": [ + "AST-02", + "AST-02.3" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" ], - "9.4.2": [ - "DCH-02", - "RSK-02" + "SC-18(02)": [ + "AST-02.7", + "END-10" ], - "3.4.1": [ - "DCH-03.2", - "END-16", - "PRI-05.3" + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" ], - "3.3.1": [ - "DCH-06.5" + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "3.3.1.1": [ - "DCH-06.5" + "SA-04(01)": [ + "AST-04", + "TDA-04.1" ], - "3.3.1.2": [ - "DCH-06.5" + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" ], - "3.3.1.3": [ - "DCH-06.5" + "PE-22": [ + "AST-04.1", + "PES-16" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "SA-05": [ + "AST-04.1", + "TDA-04" ], - "9.4.6": [ - "DCH-08", - "DCH-18", - "PRI-05" + "SR-12": [ + "AST-09" ], - "11.4.5": [ - "END-16", - "NET-06", - "NET-08.1", - "SEA-04.1", - "TDA-07", - "VPM-07", - "VPM-07.1" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "8.2.2": [ - "IAC-02.1", - "IAC-15.5", - "IAC-19" + "CP-02": [ + "BCD-01", + "BCD-06" ], - "8.4.3": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "7.2.2": [ - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" ], - "8.2.7": [ - "MNT-05", - "MNT-05.1", - "MNT-05.4", - "NET-14", - "NET-14.6" + "PM-08": [ + "BCD-01", + "CPL-01" ], - "1.3.3": [ - "NET-02.2", - "NET-03", - "NET-03.7", - "NET-04.1", - "NET-04.7", - "NET-06", - "NET-08.1", - "NET-12.1" + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" ], - "1.3.2": [ - "NET-03.5", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "CP-03": [ + "BCD-03" ], - "1.3.1": [ - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "CP-04": [ + "BCD-04", + "BCD-05" ], - "9.2.2": [ + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", "PES-12", - "PES-12.1", - "PES-12.2" + "SEA-15", + "TPM-04.4" ], - "9.5.1.3": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "CP-09": [ + "BCD-11" ], - "12.6.1": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "SC-28(02)": [ + "BCD-11", + "CRY-05.2" ], - "12.8.2": [ - "TPM-04", - "TPM-05", - "TPM-05.4" + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" ], - "12.8.3": [ - "TPM-04.1" + "SI-13": [ + "BCD-12.2", + "SEA-07" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "12.8.4": [ - "TPM-08" + "SC-05(02)": [ + "CAP-02", + "CAP-03" ], - "6.3.3": [ - "VPM-01", - "VPM-04", - "VPM-05", - "VPM-05.1" + "CM-03": [ + "CHG-01", + "CHG-02" ], - "11.3.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.6" - ] - }, - "general-pci-dss-4-0-1-saq-c": { - "2.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SA-08(31)": [ + "CHG-02", + "CHG-02.2", + "CHG-06" ], - "3.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" ], - "5.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "CM-04": [ + "CHG-03" ], - "8.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "CM-05": [ + "CHG-04", + "END-03.2" ], - "8.3.8": [ - "GOV-02", - "IAC-01", - "OPS-01", - "OPS-01.1", - "SAT-01", - "SAT-02", - "SAT-03" + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "9.1.1": [ - "GOV-02", - "GOV-03", - "PES-01", - "OPS-01", - "OPS-01.1" + "CM-09": [ + "CHG-05", + "CFG-01" ], - "10.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC-07(29)": [ + "CLD-03", + "NET-03.8", + "NET-06.1" ], - "12.1.1": [ - "GOV-02", - "GOV-03" + "SA-09(05)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" ], - "12.1.2": [ - "GOV-02", - "GOV-03" + "SA-09(08)": [ + "CLD-09", + "DCH-19" ], - "12.1.3": [ - "GOV-02", - "GOV-04", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1" + "CA-07": [ + "CPL-02" ], - "6.3.1": [ - "GOV-07", - "IAO-04", - "TDA-15", - "THR-03", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-05.1" + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" ], - "9.5.1": [ - "AST-01", - "AST-02", - "AST-06", - "AST-07", - "AST-15", - "AST-15.1", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "9.5.1.1": [ - "AST-01", - "AST-02", - "AST-07" + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "11.2.2": [ - "AST-01", - "AST-02", - "NET-02.2", - "NET-12.1", - "NET-15" + "RA-03": [ + "CPL-03.2", + "RSK-04" ], - "2.2.2": [ - "AST-03", - "IAC-10.8" + "CM-02": [ + "CFG-02", + "CFG-02.1" ], - "2.2.4": [ - "AST-03", - "CFG-03", - "RSK-06.2" + "CM-06": [ + "CFG-02", + "CFG-02.7" ], - "2.2.5": [ - "AST-03", - "TDA-02.6" + "PL-10": [ + "CFG-02" ], - "6.5.2": [ - "AST-03", - "CHG-01", - "CHG-02.2", - "CHG-03", - "CHG-06", - "CHG-06.1", - "IAC-10.8" + "SA-08": [ + "CFG-02", + "SEA-01" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "SA-15(05)": [ + "CFG-02", + "SEA-01" ], - "9.5.1.2": [ - "AST-07", - "AST-08", - "AST-15.1" + "PL-11": [ + "CFG-02.9" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "CM-07": [ + "CFG-03" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" ], - "6.5.1": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "OPS-01.1" + "SC-18(04)": [ + "CFG-03.3", + "END-10" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "CM-10": [ + "CFG-04" ], - "2.2.1": [ - "CFG-02" + "CM-11": [ + "CFG-05", + "END-03" ], - "8.3.2": [ - "CFG-02", - "CRY-01", - "CRY-03", - "CRY-05" + "CM-11(02)": [ + "CFG-05", + "CFG-05.2", + "END-03" ], - "10.2.1.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3", - "IAC-21.4" + "CM-11(03)": [ + "CFG-05.1", + "CFG-06", + "CFG-06.1", + "END-03.1" ], - "10.2.1.4": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "10.2.1.5": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "SI-04(25)": [ + "MON-01.1", + "NET-03.1" ], - "10.2.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "SC-48": [ + "MON-01.2", + "THR-07" ], - "10.6.1": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" ], - "10.6.2": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "AU-02": [ + "MON-01.8", + "MON-02" ], - "10.6.3": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "IR-04(05)": [ + "MON-01.11", + "IRO-02.6" ], - "12.3.1": [ - "CFG-03.1", - "RSK-01.1", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.2", - "RSK-07" + "SI-04(07)": [ + "MON-01.11", + "IRO-02.1" ], - "10.4.3": [ - "MON-01", - "MON-01.4", - "MON-01.8" + "SI-04(12)": [ + "MON-01.12", + "MON-05.1" ], - "10.4.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", + "AU-06": [ "MON-02", - "MON-02.2" + "MON-02.6" ], - "10.4.1.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", + "IR-04(04)": [ "MON-02", - "MON-02.1", - "MON-02.2" + "MON-02.1" ], - "10.3.4": [ - "MON-01.7", - "END-06" + "AU-03": [ + "MON-03" ], - "11.5.2": [ - "MON-01.7", - "END-06" + "AU-04": [ + "MON-04" ], - "10.4.2": [ - "MON-01.8" + "AU-05": [ + "MON-05" ], - "10.4.2.1": [ - "MON-01.8" + "AU-12": [ + "MON-06" ], - "10.3.3": [ - "MON-02", - "MON-02.2", - "MON-08.1" + "AU-08": [ + "MON-07", + "SEA-20" ], - "10.3.1": [ - "MON-08", - "MON-08.2" + "AU-09": [ + "MON-08" ], - "10.3.2": [ - "MON-08", - "MON-08.2" + "AU-11": [ + "MON-10" ], - "10.5.1": [ - "MON-10", - "DCH-18", - "PRI-05" + "SI-04(18)": [ + "MON-11.1", + "NET-17" ], - "2.2.7": [ + "IR-04(13)": [ + "MON-16", + "SEA-11", + "SEA-12" + ], + "SC-08(01)": [ "CRY-01", - "CRY-02", - "CRY-06", - "MNT-05.3" + "CRY-01.1", + "CRY-03" ], - "4.2.1": [ - "CRY-03", - "NET-12", - "NET-15.1" + "SC-08(02)": [ + "CRY-01", + "CRY-01.3", + "DCH-10" + ], + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" + ], + "IA-07": [ + "CRY-02", + "IAC-12" ], - "4.2.1.2": [ + "SC-08": [ "CRY-03", - "CRY-07", - "NET-12.1" + "CRY-04" ], - "A2.1.1": [ - "CRY-03", - "WEB-10" + "SC-16(01)": [ + "CRY-04", + "CRY-10" ], - "2.3.1": [ + "SC-28": [ + "CRY-05", + "END-02" + ], + "AC-18": [ "CRY-07", - "IAC-10.8", - "NET-12.1", - "NET-15.1" + "NET-15" ], - "2.3.2": [ + "SC-40": [ "CRY-07", - "CRY-09.3", - "NET-12.1", - "NET-15.1" + "NET-12.1" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "SC-12": [ + "CRY-08" ], - "9.4.2": [ - "DCH-02", - "RSK-02" + "MP-02": [ + "DCH-03", + "END-01" ], - "3.4.1": [ - "DCH-03.2", - "END-16", - "PRI-05.3" + "MP-03": [ + "DCH-04", + "DCH-04.1" ], - "3.3.1": [ - "DCH-06.5" + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "3.3.1.2": [ - "DCH-06.5" + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" ], - "3.3.1.3": [ - "DCH-06.5" + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "AC-20": [ + "DCH-13" ], - "9.4.6": [ - "DCH-08", + "AC-21": [ + "DCH-14", + "PRI-07" + ], + "AC-22": [ + "DCH-15" + ], + "AC-23": [ + "DCH-16", + "PRI-05.4" + ], + "SI-12": [ "DCH-18", "PRI-05" ], - "5.2.1": [ - "END-04" + "SI-12(01)": [ + "DCH-18.1", + "PRI-05.1" ], - "5.2.2": [ - "END-04" + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" ], - "5.3.1": [ - "END-04", - "END-04.1" + "SA-08(33)": [ + "DCH-18.2", + "END-13.3", + "PES-06.5" ], - "5.3.2": [ - "END-04", - "END-04.7" + "SI-12(02)": [ + "DCH-18.2", + "PRI-05.1" ], - "5.3.2.1": [ - "END-04", - "END-04.7" + "SI-12(03)": [ + "DCH-21", + "PRI-05" ], - "5.3.3": [ - "END-04", - "END-04.7" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "5.3.4": [ - "END-04", - "END-04.3" + "SI-18(04)": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" ], - "5.3.5": [ + "SI-18(05)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-06.2" + ], + "PT-03(01)": [ + "DCH-22.2", + "PRI-11" + ], + "SI-19(01)": [ + "DCH-22.3", + "DCH-23.1" + ], + "SI-19(04)": [ + "DCH-23.4", + "PRI-05.3" + ], + "SI-03": [ "END-04", - "END-04.7" + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "5.2.3": [ - "END-04.6" + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "5.2.3.1": [ - "END-04.6" + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" ], - "5.4.1": [ - "END-08" + "SC-18(01)": [ + "END-10", + "VPM-02", + "VPM-04" ], - "2.2.3": [ + "SC-18(03)": [ + "END-10", + "NET-18" + ], + "SC-15": [ + "END-14" + ], + "SC-03": [ "END-16", - "END-16.1", "SEA-04.1" ], - "11.4.5": [ - "END-16", - "NET-06", - "NET-08.1", - "SEA-04.1", - "TDA-07", - "VPM-07", - "VPM-07.1" + "PS-02": [ + "HRS-02", + "HRS-03.2" ], - "12.2.1": [ - "HRS-01", + "PM-13": [ + "HRS-03", + "SAT-01" + ], + "PS-09": [ + "HRS-03" + ], + "PS-03": [ + "HRS-04" + ], + "PL-04": [ "HRS-05", "HRS-05.1", "HRS-05.3" ], - "6.2.2": [ - "HRS-03.2", - "IAO-04", - "SAT-03", - "SAT-03.8", - "TDA-06.3", - "TDA-13", - "TDA-15" + "PL-04(01)": [ + "HRS-05.2" ], - "8.2.5": [ - "HRS-09", + "PS-06": [ + "HRS-06", + "HRS-06.1" + ], + "PS-06(02)": [ + "HRS-06", + "HRS-06.1" + ], + "PS-08": [ + "HRS-07" + ], + "PS-05": [ + "HRS-08" + ], + "PS-04": [ + "HRS-09" + ], + "AC-02(13)": [ "HRS-09.2", - "IAC-07.1", - "IAC-07.2", - "IAC-20.6" + "IAC-15.6" ], - "8.3.3": [ - "IAC-01", - "IAC-02", - "IAC-10", - "IAC-10.1", - "IAC-28" + "PS-07": [ + "HRS-10" ], - "8.5.1": [ - "IAC-01", - "IAC-02.2", - "IAC-06", - "SEA-01" + "AC-03(02)": [ + "HRS-12.1", + "IAC-20.5" ], - "8.6.1": [ - "IAC-01", - "IAC-05.1", - "IAC-15", - "IAC-15.7", - "IAC-19", - "IAC-20.3", - "IAC-21" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "8.3.9": [ - "IAC-02", - "IAC-10", - "IAC-10.1" + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "8.2.2": [ - "IAC-02.1", - "IAC-15.5", - "IAC-19" + "IA-02": [ + "IAC-02" ], - "8.4.2": [ + "IA-02(08)": [ + "IAC-02.2" + ], + "IA-02(12)": [ + "IAC-02.3" + ], + "IA-08": [ + "IAC-03" + ], + "IA-08(01)": [ + "IAC-03.1" + ], + "IA-08(02)": [ + "IAC-03.2" + ], + "IA-08(04)": [ + "IAC-03.3" + ], + "IA-03(04)": [ + "IAC-04", + "IAC-04.1" + ], + "IA-02(01)": [ "IAC-06", "IAC-06.1", "IAC-06.2", "IAC-06.3", - "IAC-06.4" + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "8.4.3": [ + "IA-02(02)": [ "IAC-06", "IAC-06.1", - "IAC-06.2" - ], - "8.4.1": [ - "IAC-06.1" + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "7.2.3": [ + "IA-12(04)": [ "IAC-07", - "IAC-07.1", - "IAC-16", - "IAC-21.3" + "IAC-10.3", + "IAC-28.4" ], - "8.2.4": [ - "IAC-07", - "IAC-07.1", + "AC-02": [ "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" + ], + "IA-05(08)": [ + "IAC-09.5", + "IAC-10.9" + ], + "IA-05": [ "IAC-10", - "IAC-15" + "IAC-10.8" ], - "8.3.5": [ - "IAC-07", + "IA-05(01)": [ "IAC-10", - "IAC-10.1" + "IAC-10.1", + "IAC-10.4" ], - "7.2.2": [ - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "IA-05(02)": [ + "IAC-10.2" ], - "7.2.5": [ - "IAC-08", - "IAC-16", + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" + ], + "IA-06": [ + "IAC-11" + ], + "IA-11": [ + "IAC-14" + ], + "AC-03": [ "IAC-20", - "IAC-20.1", - "NET-14" + "NET-12", + "TDA-18" ], - "8.2.1": [ - "IAC-09", - "IAC-09.1" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "8.3.1": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "AC-07": [ + "IAC-22" ], - "8.3.7": [ - "IAC-10", - "IAC-10.1" + "AC-14": [ + "IAC-26" ], - "8.6.3": [ - "IAC-10", - "IAC-10.1" + "IR-04": [ + "IRO-02" ], - "8.3.6": [ - "IAC-10.1" + "IR-08": [ + "IRO-04" ], - "8.6.2": [ - "IAC-10.6" + "IR-02": [ + "IRO-05" ], - "8.2.8": [ - "IAC-14", - "IAC-24", - "IAC-25", - "NET-07" + "IR-04(12)": [ + "IRO-08", + "IRO-13" ], - "8.2.6": [ - "IAC-15.3" + "IR-05": [ + "IRO-09" ], - "7.2.4": [ - "IAC-16.1", - "IAC-17" + "IR-06(02)": [ + "IRO-10.3", + "IRO-13" ], - "8.3.4": [ - "IAC-22" + "IR-04(10)": [ + "IRO-10.4", + "TPM-11" ], - "12.10.3": [ - "IRO-07" + "IR-07": [ + "IRO-11" ], - "6.2.1": [ - "IAO-04", - "SEA-01", - "TDA-01", - "TDA-02.3", - "TDA-05", - "TDA-06", - "TDA-15" + "IR-09": [ + "IRO-12", + "IRO-12.1" ], - "6.2.3.1": [ - "IAO-04", - "TDA-09", - "TDA-15" + "CA-02(01)": [ + "IAO-02.1" ], - "6.2.4": [ + "SA-11(05)": [ + "IAO-02.2", "IAO-04", - "TDA-06", "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", "TDA-09.5", - "TDA-15" + "VPM-07" ], - "8.2.7": [ - "MNT-05", - "MNT-05.1", - "MNT-05.4", - "NET-14", - "NET-14.6" + "CA-05": [ + "IAO-05" ], - "11.2.1": [ - "NET-01", - "NET-02.2", - "NET-03.1", - "NET-12.1", - "NET-15", - "NET-15.5" + "PM-04": [ + "IAO-05", + "VPM-02" ], - "1.3.3": [ - "NET-02.2", - "NET-03", - "NET-03.7", - "NET-04.1", - "NET-04.7", - "NET-06", - "NET-08.1", - "NET-12.1" + "CA-06": [ + "IAO-07" ], - "1.3.2": [ - "NET-03.5", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "MA-02": [ + "MNT-02" ], - "1.3.1": [ - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "4.2.2": [ - "NET-12.2" + "MA-05": [ + "MNT-06" ], - "9.2.1": [ - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1", - "PES-03.3" + "SR-11(02)": [ + "MNT-07" ], - "9.2.1.1": [ - "PES-03.3", - "PES-05", - "PES-05.1", - "PES-05.2" + "AC-19": [ + "MDM-02" ], - "9.2.2": [ - "PES-12", - "PES-12.1", - "PES-12.2" + "SC-07": [ + "NET-03" ], - "9.5.1.3": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "SC-07(09)": [ + "NET-03", + "NET-03.2" ], - "12.6.1": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "SC-07(11)": [ + "NET-03", + "NET-04.1" ], - "12.6.3.1": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "SC-07(10)": [ + "NET-03.5", + "NET-17" ], - "2.2.6": [ - "TDA-05.1" + "CA-03": [ + "NET-05" ], - "12.8.2": [ - "TPM-04", - "TPM-05", - "TPM-05.4" + "CA-09": [ + "NET-05.2" ], - "12.8.3": [ - "TPM-04.1" + "SC-20": [ + "NET-10" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "SC-22": [ + "NET-10.1" ], - "12.8.4": [ - "TPM-08" + "SC-21": [ + "NET-10.2" ], - "6.3.3": [ - "VPM-01", - "VPM-04", - "VPM-05", - "VPM-05.1" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "11.3.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.1", - "VPM-06.2", - "VPM-06.7" + "SI-10": [ + "NET-12", + "TDA-18" ], - "11.3.1.3": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.7" + "AC-17": [ + "NET-14" ], - "11.3.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.6" + "SC-07(08)": [ + "NET-18", + "NET-18.1" ], - "11.3.2.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.2", - "VPM-06.6" - ] - }, - "general-pci-dss-4-0-1-saq-c-vt": { - "2.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "PE-02": [ + "PES-02" ], - "3.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "PE-03": [ + "PES-03" ], - "8.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC-07(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" ], - "9.1.1": [ - "GOV-02", - "GOV-03", - "PES-01", - "OPS-01", - "OPS-01.1" + "PE-08": [ + "PES-03.3" ], - "12.1.1": [ - "GOV-02", - "GOV-03" + "PE-06": [ + "PES-05" ], - "12.1.2": [ - "GOV-02", - "GOV-03" + "PE-12": [ + "PES-07.4" ], - "6.3.1": [ - "GOV-07", - "IAO-04", - "TDA-15", - "THR-03", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-05.1" + "PE-15": [ + "PES-07.5" ], - "2.2.2": [ - "AST-03", - "IAC-10.8" + "PE-13": [ + "PES-08" ], - "2.2.4": [ - "AST-03", - "CFG-03", - "RSK-06.2" + "PE-13(02)": [ + "PES-08.2", + "PES-08.3" ], - "2.2.5": [ - "AST-03", - "TDA-02.6" + "PE-14": [ + "PES-09" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "PE-16": [ + "PES-10" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "PT-03": [ + "PRI-02.1", + "PRI-05.1" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "PT-03(02)": [ + "PRI-02.2", + "PRI-10.1" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "PT-02": [ + "PRI-04", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" ], - "1.5.1": [ - "CFG-02.5", - "CFG-03.4", - "DCH-13.1", - "END-01", - "END-02", - "END-05" + "PT-07": [ + "PRI-05.4", + "PRI-05.7" ], - "2.2.7": [ - "CRY-01", - "CRY-02", - "CRY-06", - "MNT-05.3" + "PM-05(01)": [ + "PRI-05.5", + "PRI-05.6" ], - "4.2.1.2": [ - "CRY-03", - "CRY-07", - "NET-12.1" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "2.3.1": [ - "CRY-07", - "IAC-10.8", - "NET-12.1", - "NET-15.1" + "SA-02": [ + "PRM-03" ], - "2.3.2": [ - "CRY-07", - "CRY-09.3", - "NET-12.1", - "NET-15.1" + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "SA-03": [ + "PRM-07", + "SEA-07.1" ], - "9.4.2": [ - "DCH-02", + "SA-03(01)": [ + "PRM-07", + "SEA-07.1", + "TDA-07" + ], + "SA-08(30)": [ + "PRM-07", + "SEA-07.1" + ], + "RA-02": [ "RSK-02" ], - "3.4.1": [ - "DCH-03.2", - "END-16", - "PRI-05.3" + "RA-07": [ + "RSK-06.1" ], - "3.3.1": [ - "DCH-06.5" + "SR-02": [ + "RSK-09", + "TPM-03" ], - "3.3.1.2": [ - "DCH-06.5" + "SR-07": [ + "RSK-09", + "OPS-01" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "RA-03(01)": [ + "RSK-09.1" ], - "9.4.6": [ - "DCH-08", - "DCH-18", - "PRI-05" + "CA-07(04)": [ + "RSK-11" ], - "5.2.1": [ - "END-04" + "PL-08": [ + "SEA-02" ], - "5.2.2": [ - "END-04" + "SC-39": [ + "SEA-04" ], - "5.3.1": [ - "END-04", - "END-04.1" + "SA-03(03)": [ + "SEA-07.1", + "SEA-08.1" ], - "5.3.2": [ - "END-04", - "END-04.7" + "AC-08": [ + "SEA-18" ], - "5.3.3": [ - "END-04", - "END-04.7" + "SC-38": [ + "OPS-01", + "OPS-04" ], - "5.3.4": [ - "END-04", - "END-04.3" + "AT-02": [ + "SAT-02" ], - "5.3.5": [ - "END-04", - "END-04.7" + "AT-03": [ + "SAT-03" ], - "5.4.1": [ - "END-08" + "AT-04": [ + "SAT-04" ], - "8.2.5": [ - "HRS-09", - "HRS-09.2", - "IAC-07.1", - "IAC-07.2", - "IAC-20.6" + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "8.2.2": [ - "IAC-02.1", - "IAC-15.5", - "IAC-19" + "SA-23": [ + "TDA-01", + "TDA-01.1", + "TDA-12" ], - "8.4.1": [ - "IAC-06.1" + "SA-04(10)": [ + "TDA-02.2" ], - "8.2.4": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "IAC-10", - "IAC-15" + "SA-04(03)": [ + "TDA-02.3", + "TDA-06" ], - "7.2.2": [ - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "SR-03(01)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" ], - "8.2.1": [ - "IAC-09", - "IAC-09.1" + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" ], - "8.3.1": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "SA-11(02)": [ + "TDA-06.2", + "TDA-15" ], - "8.3.6": [ - "IAC-10.1" + "SA-11(06)": [ + "TDA-09", + "VPM-01.1" ], - "1.3.3": [ - "NET-02.2", - "NET-03", - "NET-03.7", - "NET-04.1", - "NET-04.7", - "NET-06", - "NET-08.1", - "NET-12.1" + "SA-11(07)": [ + "TDA-09", + "VPM-01.1" ], - "1.3.2": [ - "NET-03.5", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "SR-11": [ + "TDA-11" ], - "1.3.1": [ - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "SR-11(01)": [ + "TDA-11.1" ], - "9.2.1": [ - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1", - "PES-03.3" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "12.6.1": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "SR-02(01)": [ + "TPM-03" ], - "12.6.3.1": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "SR-05": [ + "TPM-03.1" ], - "2.2.6": [ - "TDA-05.1" + "SR-03": [ + "TPM-03.3" ], - "12.8.2": [ - "TPM-04", + "SA-09": [ + "TPM-04" + ], + "SR-03(03)": [ "TPM-05", - "TPM-05.4" + "TPM-05.2" ], - "12.8.3": [ - "TPM-04.1" + "SR-08": [ + "TPM-05.1" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "AT-02(02)": [ + "THR-05" ], - "12.8.4": [ - "TPM-08" + "RA-05(11)": [ + "THR-06" ], - "6.3.3": [ - "VPM-01", - "VPM-04", + "SI-02(04)": [ "VPM-05", - "VPM-05.1" - ] - }, - "general-pci-dss-4-0-1-saq-d-merchant": { - "1.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" ], - "2.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "3.1.1": [ + "RA-05(02)": [ + "VPM-06.1" + ], + "CA-08": [ + "VPM-07" + ] + }, + "usa-federal-gsa-fedramp-5-mod": { + "PM-01": [ + "GOV-01", "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "GOV-03" ], - "3.7.1": [ + "AC-01": [ "GOV-02", - "CRY-09", - "OPS-01.1" + "GOV-03", + "IAC-01" ], - "3.7.2": [ + "AT-01": [ "GOV-02", - "CRY-09", - "OPS-01.1" + "GOV-03", + "SAT-01" ], - "3.7.3": [ + "AU-01": [ "GOV-02", - "CRY-09", - "OPS-01.1" + "GOV-03", + "MON-01" ], - "3.7.5": [ + "CA-01": [ "GOV-02", - "CRY-04", - "CRY-09", - "CRY-09.3", - "OPS-01.1" + "GOV-03", + "IAO-01" ], - "3.7.6": [ + "CM-01": [ "GOV-02", - "CRY-09", - "OPS-01.1" + "GOV-03", + "CFG-01" ], - "3.7.7": [ + "CP-01": [ "GOV-02", - "CRY-09", - "OPS-01.1" + "GOV-03", + "BCD-01" ], - "3.7.8": [ + "IA-01": [ "GOV-02", - "HRS-03", - "OPS-01.1" + "GOV-03", + "IAC-01" ], - "4.1.1": [ + "IR-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "5.1.1": [ + "MA-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "6.1.1": [ + "MP-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "DCH-01" ], - "7.1.1": [ + "PE-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "PES-01" ], - "8.1.1": [ + "PL-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "CPL-01", + "PRM-01", + "TDA-01" ], - "8.3.8": [ + "PS-01": [ "GOV-02", - "IAC-01", - "OPS-01", - "OPS-01.1", - "SAT-01", - "SAT-02", - "SAT-03" + "GOV-03", + "HRS-01" ], - "9.1.1": [ + "PT-01": [ "GOV-02", "GOV-03", - "PES-01", - "OPS-01", - "OPS-01.1" + "PRI-01", + "SEA-01" ], - "10.1.1": [ + "RA-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "RSK-01" ], - "11.1.1": [ + "SA-01": [ "GOV-02", "GOV-03", - "OPS-01", - "OPS-01.1" + "TDA-01", + "TDA-06" ], - "12.1.1": [ + "SC-01": [ "GOV-02", - "GOV-03" + "GOV-03", + "NET-01", + "SEA-01" ], - "12.1.2": [ + "SI-01": [ "GOV-02", - "GOV-03" + "GOV-03", + "SEA-01" ], - "12.1.3": [ + "SR-01": [ "GOV-02", - "GOV-04", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1" + "GOV-03", + "TPM-01" ], - "1.1.2": [ + "PL-09": [ "GOV-04", - "HRS-03", - "HRS-03.1", - "SAT-03", - "SAT-03.5" + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" ], - "2.1.2": [ + "PM-06": [ "GOV-04", - "HRS-03", - "HRS-03.1" + "GOV-05" ], - "3.1.2": [ + "PM-29": [ "GOV-04", - "HRS-03", - "HRS-03.1" + "RSK-01", + "RSK-09" ], - "4.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "5.1.2": [ - "GOV-04", - "END-04.2", - "HRS-03", - "HRS-03.1" + "PM-15": [ + "GOV-07", + "THR-01" ], - "6.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" ], - "7.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" ], - "8.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "PM-05": [ + "AST-01", + "AST-02" ], - "9.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1", - "PES-03" + "CM-08": [ + "AST-02", + "AST-02.3" ], - "10.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "CM-08(01)": [ + "AST-02.1" ], - "11.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" ], - "12.1.4": [ - "GOV-04", - "IRO-10" + "SC-18(02)": [ + "AST-02.7", + "END-10" ], - "6.3.1": [ - "GOV-07", - "IAO-04", - "TDA-15", - "THR-03", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-05.1" + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" ], - "6.3.2": [ - "AST-01", - "AST-02", - "AST-04.3", - "TDA-04.2", - "VPM-01.1", - "VPM-05.1" + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "9.5.1": [ - "AST-01", - "AST-02", - "AST-06", - "AST-07", - "AST-15", + "SA-04(01)": [ + "AST-04", + "TDA-04.1" + ], + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" + ], + "PE-22": [ + "AST-04.1", + "PES-16" + ], + "SA-05": [ + "AST-04.1", + "TDA-04" + ], + "SR-12": [ + "AST-09" + ], + "SR-10": [ "AST-15.1", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "TDA-11" ], - "9.5.1.1": [ - "AST-01", - "AST-02", - "AST-07" + "CP-02": [ + "BCD-01", + "BCD-06" ], - "11.2.2": [ - "AST-01", - "AST-02", - "NET-02.2", - "NET-12.1", - "NET-15" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "2.2.2": [ - "AST-03", - "IAC-10.8" + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" ], - "2.2.4": [ - "AST-03", - "CFG-03", - "RSK-06.2" + "PM-08": [ + "BCD-01", + "CPL-01" ], - "2.2.5": [ - "AST-03", - "TDA-02.6" + "CP-02(01)": [ + "BCD-01.1" ], - "6.5.2": [ - "AST-03", - "CHG-01", - "CHG-02.2", - "CHG-03", - "CHG-06", - "CHG-06.1", - "IAC-10.8" + "CP-02(08)": [ + "BCD-02" ], - "1.2.3": [ - "AST-04", - "AST-04.2", - "NET-02.2", - "NET-06", - "NET-08.1", - "NET-12.1" + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" ], - "1.2.4": [ - "AST-04", - "NET-06", - "NET-08.1", - "TDA-02.1" + "CP-03": [ + "BCD-03" ], - "12.5.1": [ - "AST-04.3", - "CPL-01.2", - "PRI-05.5" + "CP-04": [ + "BCD-04", + "BCD-05" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "CP-04(01)": [ + "BCD-04.1" ], - "9.5.1.2": [ - "AST-07", - "AST-08", - "AST-15.1" + "CP-06": [ + "BCD-08" ], - "9.5.1.2.1": [ - "AST-08" + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" ], - "9.4.7": [ - "AST-09", - "DCH-09", - "DCH-09.1", - "DCH-18", - "PRI-05" + "CP-06(01)": [ + "BCD-08.1" ], - "9.4.1.2": [ - "BCD-02.4", - "BCD-11", - "DCH-06", - "DCH-06.1", - "DCH-06.2" + "CP-06(03)": [ + "BCD-08.2" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "CP-07": [ + "BCD-09" ], - "12.10.1": [ + "CP-07(01)": [ + "BCD-09.1" + ], + "CP-07(02)": [ + "BCD-09.2" + ], + "CP-07(03)": [ + "BCD-09.3" + ], + "CP-08": [ + "BCD-10" + ], + "CP-08(02)": [ + "BCD-10" + ], + "CP-08(01)": [ + "BCD-10.1" + ], + "CP-09": [ + "BCD-11" + ], + "SC-28(02)": [ "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "CRY-05.2" ], - "1.2.2": [ - "CHG-01", - "CHG-02", - "CHG-02.1" + "CP-09(01)": [ + "BCD-11.1" ], - "6.5.1": [ + "CP-09(08)": [ + "BCD-11.4" + ], + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" + ], + "CP-10(02)": [ + "BCD-12.1" + ], + "SI-13": [ + "BCD-12.2", + "SEA-07" + ], + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "SC-05(02)": [ + "CAP-02", + "CAP-03" + ], + "CM-03": [ "CHG-01", + "CHG-02" + ], + "SA-08(31)": [ "CHG-02", - "CHG-02.1", "CHG-02.2", - "OPS-01.1" + "CHG-06" ], - "6.5.3": [ - "CHG-01", - "TDA-07", - "TDA-08" + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" ], - "6.5.6": [ - "CHG-02", - "CHG-03", - "CFG-02.4", - "TDA-08", - "TDA-08.1", - "TDA-09" + "CM-03(04)": [ + "CHG-02.3" ], - "1.2.8": [ + "CM-04": [ + "CHG-03" + ], + "CM-05": [ "CHG-04", - "CFG-02.6", - "NET-06", - "NET-08.1" + "END-03.2" ], - "10.7.3": [ - "CHG-06", - "CPL-02", - "CPL-03", - "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "IRO-01", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "TPM-11" + "CM-05(01)": [ + "CHG-04.1" ], - "1.2.1": [ - "CLD-01", - "CFG-02", - "CFG-02.5", - "NET-06", - "NET-08.1", - "SEA-03" + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "CM-05(05)": [ + "CHG-04.4" ], - "12.5.2": [ - "CPL-01.2", - "CFG-03.1", - "NET-06", - "NET-08.1", + "CM-09": [ + "CHG-05", + "CFG-01" + ], + "SI-06": [ + "CHG-06" + ], + "SC-07(29)": [ + "CLD-03", + "NET-03.8", + "NET-06.1" + ], + "SA-09(05)": [ + "CLD-09", + "DCH-19", "TPM-04.4" ], - "10.7.2": [ + "SA-09(08)": [ + "CLD-09", + "DCH-19" + ], + "CA-07": [ + "CPL-02" + ], + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" + ], + "PM-14": [ "CPL-02", + "PRI-08" + ], + "CA-02": [ "CPL-03", "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "IRO-01", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "TPM-11" + "IAO-02", + "IAO-06", + "PRM-04" ], - "1.2.7": [ + "RA-03": [ "CPL-03.2", - "CFG-03.1", - "NET-04.6", - "NET-06", - "NET-08.1" + "RSK-04" ], - "1.2.6": [ + "CM-02": [ "CFG-02", - "CFG-03", - "NET-06", - "NET-08.1", - "RSK-06.2", - "TDA-02.6" + "CFG-02.1" ], - "2.2.1": [ + "CM-06": [ + "CFG-02", + "CFG-02.7" + ], + "PL-10": [ "CFG-02" ], - "8.3.2": [ + "SA-08": [ "CFG-02", - "CRY-01", - "CRY-03", - "CRY-05" + "SEA-01" ], - "10.2.1": [ + "SA-15(05)": [ "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "SEA-01" ], - "10.2.1.1": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "CM-02(02)": [ + "CFG-02.2" ], - "10.2.1.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3", - "IAC-21.4" + "CM-06(01)": [ + "CFG-02.2" ], - "10.2.1.3": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "CM-02(03)": [ + "CFG-02.3" ], - "10.2.1.4": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "CM-02(07)": [ + "CFG-02.5" ], - "10.2.1.5": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "PL-11": [ + "CFG-02.9" ], - "10.2.1.6": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "CM-07": [ + "CFG-03" ], - "10.2.1.7": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "CM-07(01)": [ + "CFG-03.1" ], - "10.2.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" ], - "10.6.1": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "CM-07(05)": [ + "CFG-03.3" ], - "10.6.2": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "SC-18(04)": [ + "CFG-03.3", + "END-10" ], - "10.6.3": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "SC-07(07)": [ + "CFG-03.4" ], - "1.5.1": [ - "CFG-02.5", - "CFG-03.4", - "DCH-13.1", - "END-01", - "END-02", - "END-05" + "CM-10": [ + "CFG-04" ], - "1.2.5": [ - "CFG-03", - "NET-06", - "NET-08.1", - "TDA-02.5", - "TPM-04.2" + "CM-11": [ + "CFG-05", + "END-03" ], - "1.4.1": [ - "CFG-03", - "NET-02", - "NET-03", - "NET-03.8", - "NET-06", - "NET-08.1", - "NET-09", - "SEA-03" + "CM-11(02)": [ + "CFG-05", + "CFG-05.2", + "END-03" ], - "1.4.2": [ - "CFG-03", - "NET-03", - "NET-03.1", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "CM-11(03)": [ + "CFG-05.1", + "CFG-06", + "CFG-06.1", + "END-03.1" ], - "11.6.1": [ - "CFG-03.1", - "MON-01.7", - "END-06", - "WEB-13" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "12.3.1": [ - "CFG-03.1", - "RSK-01.1", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.2", - "RSK-07" + "SI-04(01)": [ + "MON-01.1" ], - "12.3.4": [ - "CFG-03.1", - "SEA-02.3", - "SEA-07.1" + "SI-04(25)": [ + "MON-01.1", + "NET-03.1" ], - "12.6.2": [ - "CFG-03.1", - "SAT-01" + "SC-48": [ + "MON-01.2", + "THR-07" ], - "12.6.3": [ - "CFG-03.1", - "HRS-03.1", - "HRS-05.7", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.6", - "SAT-04" + "SI-04(02)": [ + "MON-01.2" ], - "10.4.3": [ - "MON-01", - "MON-01.4", - "MON-01.8" + "SI-04(04)": [ + "MON-01.3" ], - "1.4.3": [ - "MON-01.1", - "NET-04", - "NET-08", - "NET-08.2" + "SI-04(05)": [ + "MON-01.4" ], - "11.5.1": [ - "MON-01.1", - "NET-03", - "NET-08", - "SAT-03.2" + "SI-04(23)": [ + "MON-01.6" ], - "10.4.1": [ - "MON-01.2", - "MON-01.4", + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" + ], + "AU-02": [ "MON-01.8", + "MON-02" + ], + "IR-04(05)": [ + "MON-01.11", + "IRO-02.6" + ], + "SI-04(07)": [ + "MON-01.11", + "IRO-02.1" + ], + "SI-04(12)": [ + "MON-01.12", + "MON-05.1" + ], + "AU-06": [ "MON-02", - "MON-02.2" + "MON-02.6" ], - "10.4.1.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", + "IR-04(04)": [ "MON-02", - "MON-02.1", - "MON-02.2" + "MON-02.1" ], - "10.3.4": [ - "MON-01.7", - "END-06" + "AU-06(03)": [ + "MON-02.1" ], - "11.5.2": [ - "MON-01.7", - "END-06" + "SI-04(16)": [ + "MON-02.1" ], - "10.4.2": [ - "MON-01.8" + "AU-03": [ + "MON-03" ], - "10.4.2.1": [ - "MON-01.8" + "AU-03(01)": [ + "MON-03.1" ], - "10.3.3": [ - "MON-02", - "MON-02.2", - "MON-08.1" + "AU-06(01)": [ + "MON-03.1" ], - "12.10.5": [ - "MON-02.1", - "IRO-02", - "IRO-04", - "NET-12.1" + "AU-04": [ + "MON-04" ], - "6.4.2": [ - "MON-03", - "IAO-04", - "TDA-15", - "VPM-05.1", - "WEB-01", - "WEB-03" + "AU-05": [ + "MON-05" ], - "7.2.6": [ - "MON-03.7", - "IAC-20", - "IAC-20.1", - "IAC-20.2", - "IAC-21" + "AU-07": [ + "MON-06" ], - "10.3.1": [ - "MON-08", - "MON-08.2" + "AU-07(01)": [ + "MON-06" ], - "10.3.2": [ - "MON-08", + "AU-12": [ + "MON-06" + ], + "AU-08": [ + "MON-07", + "SEA-20" + ], + "SC-45": [ + "MON-07.1" + ], + "SC-45(01)": [ + "MON-07.1" + ], + "AU-09": [ + "MON-08" + ], + "AU-09(04)": [ "MON-08.2" ], - "10.5.1": [ - "MON-10", - "DCH-18", - "PRI-05" + "AU-11": [ + "MON-10" ], - "2.2.7": [ + "SI-04(18)": [ + "MON-11.1", + "NET-17" + ], + "AC-02(12)": [ + "MON-16" + ], + "IR-04(13)": [ + "MON-16", + "SEA-11", + "SEA-12" + ], + "SC-08(01)": [ "CRY-01", - "CRY-02", - "CRY-06", - "MNT-05.3" + "CRY-01.1", + "CRY-03" ], - "3.3.2": [ + "SC-08(02)": [ "CRY-01", - "CRY-05" + "CRY-01.3", + "DCH-10" ], - "12.3.3": [ + "SC-13": [ "CRY-01", - "CRY-01.5" + "CRY-01.2", + "CRY-05" ], - "3.6.1.2": [ + "IA-07": [ "CRY-02", - "CRY-09", "IAC-12" ], - "4.2.1": [ - "CRY-03", - "NET-12", - "NET-15.1" - ], - "4.2.1.2": [ - "CRY-03", - "CRY-07", - "NET-12.1" - ], - "A2.1.1": [ + "SC-08": [ "CRY-03", - "WEB-10" + "CRY-04" ], - "3.5.1.2": [ - "CRY-05" + "SC-16(01)": [ + "CRY-04", + "CRY-10" ], - "3.5.1.3": [ - "CRY-05" + "SC-28": [ + "CRY-05", + "END-02" ], - "2.3.1": [ + "AC-18": [ "CRY-07", - "IAC-10.8", - "NET-12.1", - "NET-15.1" + "NET-15" ], - "2.3.2": [ + "SC-40": [ "CRY-07", - "CRY-09.3", - "NET-12.1", - "NET-15.1" + "NET-12.1" ], - "3.6.1": [ - "CRY-08.1", - "CRY-09", - "CRY-09.3", - "CRY-09.4" + "SC-12": [ + "CRY-08" ], - "3.5.1.1": [ - "CRY-09" + "SC-17": [ + "CRY-08" ], - "3.6.1.3": [ - "CRY-09" + "MP-02": [ + "DCH-03", + "END-01" ], - "3.6.1.4": [ - "CRY-09" + "MP-03": [ + "DCH-04", + "DCH-04.1" ], - "3.7.4": [ - "CRY-09" + "MP-04": [ + "DCH-06" ], - "4.2.1.1": [ - "CRY-09" + "MP-05": [ + "DCH-07" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" + ], + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" + ], + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" + ], + "AC-20": [ + "DCH-13" ], - "3.5.1": [ - "DCH-01.2" + "AC-20(01)": [ + "DCH-13.1" ], - "9.4.2": [ - "DCH-02", - "RSK-02" + "AC-20(02)": [ + "DCH-13.2" ], - "3.4.1": [ - "DCH-03.2", - "END-16", - "PRI-05.3" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "9.4.5": [ - "DCH-06.2" + "AC-22": [ + "DCH-15" ], - "9.4.5.1": [ - "DCH-06.2" + "AC-23": [ + "DCH-16", + "PRI-05.4" ], - "3.3.1": [ - "DCH-06.5" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "3.3.1.2": [ - "DCH-06.5" + "SI-12(01)": [ + "DCH-18.1", + "PRI-05.1" ], - "3.3.1.3": [ - "DCH-06.5" + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "SA-08(33)": [ + "DCH-18.2", + "END-13.3", + "PES-06.5" ], - "9.4.6": [ - "DCH-08", - "DCH-18", + "SI-12(02)": [ + "DCH-18.2", + "PRI-05.1" + ], + "SI-12(03)": [ + "DCH-21", "PRI-05" ], - "1.4.4": [ - "DCH-15", - "NET-05.1" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "3.2.1": [ - "DCH-18", - "TPM-04.4" + "SI-18(04)": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" ], - "11.4.1": [ - "DCH-18", - "IAO-04", - "TDA-15", - "VPM-07", - "VPM-07.1" + "SI-18(05)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-06.2" ], - "5.2.1": [ - "END-04" + "PT-03(01)": [ + "DCH-22.2", + "PRI-11" ], - "5.2.2": [ - "END-04" + "SI-19(01)": [ + "DCH-22.3", + "DCH-23.1" ], - "5.3.1": [ - "END-04", - "END-04.1" + "SI-19(04)": [ + "DCH-23.4", + "PRI-05.3" ], - "5.3.2": [ - "END-04", - "END-04.7" + "CM-12": [ + "DCH-24" ], - "5.3.2.1": [ - "END-04", - "END-04.7" + "CM-12(01)": [ + "DCH-24.1" ], - "5.3.3": [ + "SI-03": [ "END-04", - "END-04.7" + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "5.3.4": [ - "END-04", - "END-04.3" + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "5.3.5": [ - "END-04", - "END-04.7" + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" ], - "5.2.3": [ - "END-04.6" + "SI-07(01)": [ + "END-06.1" ], - "5.2.3.1": [ - "END-04.6" + "SI-07(07)": [ + "END-06.2" ], - "5.4.1": [ + "SI-08": [ "END-08" ], - "2.2.3": [ + "SI-08(02)": [ + "END-08.2" + ], + "SC-18": [ + "END-10" + ], + "SC-18(01)": [ + "END-10", + "VPM-02", + "VPM-04" + ], + "SC-18(03)": [ + "END-10", + "NET-18" + ], + "SC-15": [ + "END-14" + ], + "SC-03": [ "END-16", - "END-16.1", "SEA-04.1" ], - "11.4.5": [ - "END-16", - "NET-06", - "NET-08.1", - "SEA-04.1", - "TDA-07", - "VPM-07", - "VPM-07.1" + "SC-07(12)": [ + "END-16.1" ], - "12.2.1": [ - "HRS-01", + "PS-02": [ + "HRS-02", + "HRS-03.2" + ], + "PM-13": [ + "HRS-03", + "SAT-01" + ], + "PS-09": [ + "HRS-03" + ], + "PS-03": [ + "HRS-04" + ], + "PS-03(03)": [ + "HRS-04.1" + ], + "PL-04": [ "HRS-05", "HRS-05.1", "HRS-05.3" ], - "12.7.1": [ - "HRS-01", - "HRS-02", - "HRS-02.1", - "HRS-04", - "HRS-04.1" + "PL-04(01)": [ + "HRS-05.2" ], - "6.2.2": [ - "HRS-03.2", - "IAO-04", - "SAT-03", - "SAT-03.8", - "TDA-06.3", - "TDA-13", - "TDA-15" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "8.2.5": [ - "HRS-09", + "PS-06(02)": [ + "HRS-06", + "HRS-06.1" + ], + "PS-08": [ + "HRS-07" + ], + "PS-05": [ + "HRS-08" + ], + "PS-04": [ + "HRS-09" + ], + "AC-02(13)": [ "HRS-09.2", - "IAC-07.1", - "IAC-07.2", - "IAC-20.6" + "IAC-15.6" ], - "6.5.4": [ - "HRS-11" + "PS-07": [ + "HRS-10" ], - "7.2.1": [ - "IAC-01", - "IAC-02", - "IAC-03", - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "AC-03(02)": [ + "HRS-12.1", + "IAC-20.5" ], - "7.3.1": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "7.3.2": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "7.3.3": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "IA-02": [ + "IAC-02" ], - "8.3.3": [ - "IAC-01", - "IAC-02", - "IAC-10", - "IAC-10.1", - "IAC-28" + "IA-02(05)": [ + "IAC-02.1" ], - "8.5.1": [ - "IAC-01", - "IAC-02.2", - "IAC-06", - "SEA-01" + "IA-02(08)": [ + "IAC-02.2" ], - "8.6.1": [ - "IAC-01", - "IAC-05.1", - "IAC-15", - "IAC-15.7", - "IAC-19", - "IAC-20.3", - "IAC-21" + "IA-02(12)": [ + "IAC-02.3" ], - "8.3.9": [ - "IAC-02", - "IAC-10", - "IAC-10.1" + "IA-08": [ + "IAC-03" ], - "8.2.2": [ - "IAC-02.1", - "IAC-15.5", - "IAC-19" + "IA-08(01)": [ + "IAC-03.1" ], - "8.4.2": [ + "IA-08(02)": [ + "IAC-03.2" + ], + "IA-08(04)": [ + "IAC-03.3" + ], + "IA-03": [ + "IAC-04" + ], + "IA-03(04)": [ + "IAC-04", + "IAC-04.1" + ], + "IA-02(01)": [ "IAC-06", "IAC-06.1", "IAC-06.2", "IAC-06.3", - "IAC-06.4" + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "8.4.3": [ + "IA-02(02)": [ "IAC-06", "IAC-06.1", - "IAC-06.2" + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "8.4.1": [ - "IAC-06.1" + "IA-02(06)": [ + "IAC-06.4" ], - "7.2.3": [ + "IA-12(04)": [ "IAC-07", - "IAC-07.1", - "IAC-16", - "IAC-21.3" + "IAC-10.3", + "IAC-28.4" ], - "8.2.4": [ - "IAC-07", - "IAC-07.1", + "AC-02": [ "IAC-07.2", - "IAC-10", - "IAC-15" - ], - "8.3.5": [ - "IAC-07", - "IAC-10", - "IAC-10.1" + "IAC-15", + "NET-12", + "TDA-18" ], - "7.2.2": [ - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "AC-02(07)": [ + "IAC-08" ], - "7.2.5": [ - "IAC-08", - "IAC-16", - "IAC-20", - "IAC-20.1", - "NET-14" + "IA-05(08)": [ + "IAC-09.5", + "IAC-10.9" ], - "8.2.1": [ - "IAC-09", - "IAC-09.1" + "IA-05": [ + "IAC-10", + "IAC-10.8" ], - "8.3.1": [ + "IA-05(01)": [ "IAC-10", "IAC-10.1", - "IAC-10.2" + "IAC-10.4" ], - "8.3.7": [ - "IAC-10", - "IAC-10.1" + "IA-05(02)": [ + "IAC-10.2" ], - "8.3.11": [ - "IAC-10", - "IAC-10.2", + "IA-05(06)": [ "IAC-10.5", - "IAC-10.7", - "IAC-18", - "PES-02", - "PES-02.1" - ], - "8.6.3": [ - "IAC-10", - "IAC-10.1" - ], - "8.3.6": [ - "IAC-10.1" + "IAC-18" ], - "8.6.2": [ + "IA-05(07)": [ "IAC-10.6" ], - "8.2.8": [ - "IAC-14", - "IAC-24", - "IAC-25", - "NET-07" - ], - "8.2.6": [ - "IAC-15.3" - ], - "7.2.4": [ - "IAC-16.1", - "IAC-17" + "IA-06": [ + "IAC-11" ], - "7.2.5.1": [ - "IAC-17" + "IA-11": [ + "IAC-14" ], - "3.4.2": [ - "IAC-21", - "NET-14" + "AC-02(01)": [ + "IAC-15.1" ], - "8.3.4": [ - "IAC-22" + "AC-02(02)": [ + "IAC-15.2" ], - "12.10.7": [ - "IRO-04", - "IRO-12", - "IRO-12.3" + "AC-02(03)": [ + "IAC-15.3" ], - "12.10.2": [ - "IRO-04.2", - "IRO-06" + "AC-02(04)": [ + "IAC-15.4" ], - "12.10.6": [ - "IRO-04.2", - "IRO-13" + "AC-02(09)": [ + "IAC-15.5" ], - "12.10.4": [ - "IRO-05" + "AC-06(07)": [ + "IAC-17" ], - "12.10.4.1": [ - "IRO-05" + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "12.10.3": [ - "IRO-07" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "6.2.1": [ - "IAO-04", - "SEA-01", - "TDA-01", - "TDA-02.3", - "TDA-05", - "TDA-06", - "TDA-15" + "AC-06(01)": [ + "IAC-21.1" ], - "6.2.3": [ - "IAO-04", - "TDA-06.5", - "TDA-09", - "TDA-15" + "AC-06(02)": [ + "IAC-21.2" ], - "6.2.3.1": [ - "IAO-04", - "TDA-09", - "TDA-15" + "AC-06(05)": [ + "IAC-21.3" ], - "6.2.4": [ - "IAO-04", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TDA-15" + "AC-06(09)": [ + "IAC-21.4" ], - "6.4.1": [ - "IAO-04", - "TDA-15", - "VPM-05.1", - "VPM-06", - "VPM-06.6", - "WEB-01", - "WEB-03" + "AC-06(10)": [ + "IAC-21.5" ], - "11.4.4": [ - "IAO-04", - "TDA-15", - "VPM-07" + "AC-07": [ + "IAC-22" ], - "8.2.7": [ - "MNT-05", - "MNT-05.1", - "MNT-05.4", - "NET-14", - "NET-14.6" + "AC-02(05)": [ + "IAC-24" ], - "11.2.1": [ - "NET-01", - "NET-02.2", - "NET-03.1", - "NET-12.1", - "NET-15", - "NET-15.5" + "AC-11": [ + "IAC-24" ], - "1.3.3": [ - "NET-02.2", - "NET-03", - "NET-03.7", - "NET-04.1", - "NET-04.7", - "NET-06", - "NET-08.1", - "NET-12.1" + "AC-11(01)": [ + "IAC-24.1" ], - "1.4.5": [ - "NET-03.3", - "VPM-06.8" + "AC-12": [ + "IAC-25" ], - "1.3.2": [ - "NET-03.5", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "AC-14": [ + "IAC-26" ], - "1.3.1": [ - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "IA-12": [ + "IAC-28" ], - "4.2.2": [ - "NET-12.2" + "IA-12(02)": [ + "IAC-28.2" ], - "9.2.1": [ - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1", - "PES-03.3" + "IA-12(03)": [ + "IAC-28.3" ], - "9.3.1": [ - "PES-02", - "PES-02.1", - "PES-03.1" + "IA-12(05)": [ + "IAC-28.5" ], - "9.3.1.1": [ - "PES-02.1", - "PES-04", - "PES-04.1" + "IR-04": [ + "IRO-02" ], - "9.2.4": [ - "PES-03.2", - "PES-12" + "IR-04(01)": [ + "IRO-02.1" ], - "9.2.1.1": [ - "PES-03.3", - "PES-05", - "PES-05.1", - "PES-05.2" + "IR-08": [ + "IRO-04" ], - "9.3.2": [ - "PES-06", - "PES-06.1", - "PES-06.2", - "PES-06.3", - "OPS-01", - "OPS-01.1" + "IR-02": [ + "IRO-05" ], - "9.3.3": [ - "PES-06", - "PES-06.6" + "IR-03": [ + "IRO-06" ], - "9.3.4": [ - "PES-06", - "PES-06.4", - "PES-06.5" + "IR-03(02)": [ + "IRO-06.1" ], - "9.2.2": [ - "PES-12", - "PES-12.1", - "PES-12.2" + "IR-04(12)": [ + "IRO-08", + "IRO-13" ], - "9.2.3": [ - "PES-12", - "PES-12.1", - "PES-12.2" + "IR-05": [ + "IRO-09" ], - "6.5.5": [ - "PRI-05.1", - "PRI-05.4", - "TDA-10" + "IR-06(01)": [ + "IRO-10.1" ], - "12.3.2": [ - "RSK-01.1", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-06.2", - "RSK-07" + "IR-06(02)": [ + "IRO-10.3", + "IRO-13" ], - "9.5.1.3": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "IR-04(10)": [ + "IRO-10.4", + "TPM-11" ], - "12.6.1": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "IR-06(03)": [ + "IRO-10.4" ], - "12.6.3.1": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "IR-07": [ + "IRO-11" ], - "12.6.3.2": [ - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "IR-07(01)": [ + "IRO-11.1" ], - "2.2.6": [ - "TDA-05.1" + "IR-09": [ + "IRO-12", + "IRO-12.1" ], - "12.8.2": [ - "TPM-04", - "TPM-05", - "TPM-05.4" + "IR-09(02)": [ + "IRO-12.2" ], - "12.8.3": [ - "TPM-04.1" + "IR-09(03)": [ + "IRO-12.3" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "IR-09(04)": [ + "IRO-12.4" ], - "12.8.4": [ - "TPM-08" + "CA-02(01)": [ + "IAO-02.1" ], - "6.3.3": [ - "VPM-01", - "VPM-04", - "VPM-05", - "VPM-05.1" + "SA-11(05)": [ + "IAO-02.2", + "IAO-04", + "TDA-09", + "TDA-09.5", + "VPM-07" ], - "11.3.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.1", - "VPM-06.2", - "VPM-06.7" + "CA-02(03)": [ + "IAO-02.3" ], - "11.3.1.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06" + "CA-05": [ + "IAO-05" ], - "11.3.1.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.7" + "PM-04": [ + "IAO-05", + "VPM-02" ], - "11.3.1.3": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.7" + "CM-04(02)": [ + "IAO-06" ], - "11.3.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.6" + "CA-06": [ + "IAO-07" ], - "11.3.2.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.2", - "VPM-06.6" + "MA-02": [ + "MNT-02" ], - "6.4.3": [ - "VPM-05.1", - "WEB-01.1" + "MA-06": [ + "MNT-03" ], - "11.4.2": [ - "VPM-07", - "VPM-07.1" + "MA-03": [ + "MNT-04" ], - "11.4.3": [ - "VPM-07", - "VPM-07.1" - ] - }, - "general-pci-dss-4-0-1-saq-d-service-provider": { - "1.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "MA-03(01)": [ + "MNT-04.1" ], - "2.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "MA-03(02)": [ + "MNT-04.2" ], - "3.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "MA-03(03)": [ + "MNT-04.3" ], - "3.7.1": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "3.7.2": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "MA-05": [ + "MNT-06" ], - "3.7.3": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "MA-05(01)": [ + "MNT-06.1" ], - "3.7.5": [ - "GOV-02", - "CRY-04", - "CRY-09", - "CRY-09.3", - "OPS-01.1" + "SR-11(02)": [ + "MNT-07" ], - "3.7.6": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "AC-19": [ + "MDM-02" ], - "3.7.7": [ - "GOV-02", - "CRY-09", - "OPS-01.1" + "AC-19(05)": [ + "MDM-03" ], - "3.7.8": [ - "GOV-02", - "HRS-03", - "OPS-01.1" + "SC-07": [ + "NET-03" ], - "4.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC-07(09)": [ + "NET-03", + "NET-03.2" ], - "5.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC-07(11)": [ + "NET-03", + "NET-04.1" ], - "6.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC-07(03)": [ + "NET-03.1" ], - "7.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC-07(04)": [ + "NET-03.2" ], - "8.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SC-07(10)": [ + "NET-03.5", + "NET-17" ], - "8.3.8": [ - "GOV-02", - "IAC-01", - "OPS-01", - "OPS-01.1", - "SAT-01", - "SAT-02", - "SAT-03" + "AC-04": [ + "NET-04" ], - "9.1.1": [ - "GOV-02", - "GOV-03", - "PES-01", - "OPS-01", - "OPS-01.1" + "SC-07(05)": [ + "NET-04.1" ], - "10.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "CA-03": [ + "NET-05" ], - "11.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "CA-09": [ + "NET-05.2" ], - "12.1.1": [ - "GOV-02", - "GOV-03" + "AC-04(21)": [ + "NET-06" ], - "12.1.2": [ - "GOV-02", - "GOV-03" + "SC-10": [ + "NET-07" ], - "12.1.3": [ - "GOV-02", - "GOV-04", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1" + "SC-23": [ + "NET-09" ], - "1.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1", - "SAT-03", - "SAT-03.5" + "SC-20": [ + "NET-10" ], - "2.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "SC-22": [ + "NET-10.1" ], - "3.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "SC-21": [ + "NET-10.2" ], - "5.1.2": [ - "GOV-04", - "END-04.2", - "HRS-03", - "HRS-03.1" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "6.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "SI-10": [ + "NET-12", + "TDA-18" ], - "7.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "AC-17": [ + "NET-14" ], - "8.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "AC-17(01)": [ + "NET-14.1" ], - "9.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1", - "PES-03" + "AC-17(02)": [ + "NET-14.2" ], - "10.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "AC-17(03)": [ + "NET-14.3" ], - "11.1.2": [ - "GOV-04", - "HRS-03", - "HRS-03.1" + "AC-17(04)": [ + "NET-14.4" ], - "12.1.4": [ - "GOV-04", - "IRO-10" + "AC-18(01)": [ + "NET-15.1" ], - "6.3.1": [ - "GOV-07", - "IAO-04", - "TDA-15", - "THR-03", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-05.1" + "AC-18(03)": [ + "NET-15.2" ], - "6.3.2": [ - "AST-01", - "AST-02", - "AST-04.3", - "TDA-04.2", - "VPM-01.1", - "VPM-05.1" + "SC-07(08)": [ + "NET-18", + "NET-18.1" ], - "9.5.1": [ - "AST-01", - "AST-02", - "AST-06", - "AST-07", - "AST-15", - "AST-15.1", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "PE-02": [ + "PES-02" ], - "9.5.1.1": [ - "AST-01", - "AST-02", - "AST-07" + "PE-03": [ + "PES-03" ], - "11.2.2": [ - "AST-01", - "AST-02", - "NET-02.2", - "NET-12.1", - "NET-15" + "SC-07(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" ], - "2.2.2": [ - "AST-03", - "IAC-10.8" + "PE-08": [ + "PES-03.3" ], - "2.2.4": [ - "AST-03", - "CFG-03", - "RSK-06.2" + "PE-06": [ + "PES-05" ], - "2.2.5": [ - "AST-03", - "TDA-02.6" + "PE-06(01)": [ + "PES-05.1" ], - "6.5.2": [ - "AST-03", - "CHG-01", - "CHG-02.2", - "CHG-03", - "CHG-06", - "CHG-06.1", - "IAC-10.8" + "PE-09": [ + "PES-07" ], - "1.2.3": [ - "AST-04", - "AST-04.2", - "NET-02.2", - "NET-06", - "NET-08.1", - "NET-12.1" + "PE-10": [ + "PES-07.2" ], - "1.2.4": [ - "AST-04", - "NET-06", - "NET-08.1", - "TDA-02.1" + "PE-11": [ + "PES-07.3" ], - "12.5.2.1": [ - "AST-04.2", - "AST-04.3", - "CFG-03.1", - "TPM-05.5" + "PE-12": [ + "PES-07.4" ], - "12.5.1": [ - "AST-04.3", - "CPL-01.2", - "PRI-05.5" + "PE-15": [ + "PES-07.5" ], - "9.4.4": [ - "AST-05", - "AST-05.1" + "PE-13": [ + "PES-08" ], - "9.5.1.2": [ - "AST-07", - "AST-08", - "AST-15.1" + "PE-13(01)": [ + "PES-08.1" ], - "9.5.1.2.1": [ - "AST-08" + "PE-13(02)": [ + "PES-08.2", + "PES-08.3" ], - "9.4.7": [ - "AST-09", - "DCH-09", - "DCH-09.1", - "DCH-18", - "PRI-05" + "PE-14": [ + "PES-09" ], - "9.4.1.2": [ - "BCD-02.4", - "BCD-11", - "DCH-06", - "DCH-06.1", - "DCH-06.2" + "PE-16": [ + "PES-10" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "PE-17": [ + "PES-11" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "PE-04": [ + "PES-12.1" ], - "1.2.2": [ - "CHG-01", - "CHG-02", - "CHG-02.1" + "PE-05": [ + "PES-12.2" ], - "6.5.1": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "OPS-01.1" + "PT-03": [ + "PRI-02.1", + "PRI-05.1" ], - "6.5.3": [ - "CHG-01", - "TDA-07", - "TDA-08" + "PT-03(02)": [ + "PRI-02.2", + "PRI-10.1" ], - "12.4.2": [ - "CHG-01", - "CHG-02", - "CLD-12", - "CPL-01", - "CPL-01.1", - "CPL-03", - "CPL-03.2", - "CFG-02.1", - "CFG-03.1", - "MON-01.8", - "TPM-05", - "TPM-08" + "PT-02": [ + "PRI-04", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" ], - "6.5.6": [ - "CHG-02", - "CHG-03", - "CFG-02.4", - "TDA-08", - "TDA-08.1", - "TDA-09" + "PT-07": [ + "PRI-05.4", + "PRI-05.7" ], - "1.2.8": [ - "CHG-04", - "CFG-02.6", - "NET-06", - "NET-08.1" + "PM-05(01)": [ + "PRI-05.5", + "PRI-05.6" ], - "10.7.3": [ - "CHG-06", - "CPL-02", - "CPL-03", - "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "IRO-01", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "TPM-11" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "1.2.1": [ - "CLD-01", - "CFG-02", - "CFG-02.5", - "NET-06", - "NET-08.1", - "SEA-03" + "SA-02": [ + "PRM-03" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "A1.1.1": [ - "CLD-06" + "SA-03": [ + "PRM-07", + "SEA-07.1" ], - "A1.1.2": [ - "CLD-06" + "SA-03(01)": [ + "PRM-07", + "SEA-07.1", + "TDA-07" ], - "A1.1.3": [ - "CLD-06" + "SA-08(30)": [ + "PRM-07", + "SEA-07.1" ], - "A1.1.4": [ - "CLD-06", - "NET-06", - "NET-08.1" + "RA-02": [ + "RSK-02" ], - "12.4.1": [ - "CLD-06.1", - "TPM-05.4" + "RA-07": [ + "RSK-06.1" ], - "A1.2.1": [ - "CLD-06.2" + "SR-02": [ + "RSK-09", + "TPM-03" ], - "A1.2.2": [ - "CLD-06.3" + "SR-07": [ + "RSK-09", + "OPS-01" ], - "A1.2.3": [ - "CLD-06.4", - "IRO-10", - "IAO-04", - "TDA-15" + "RA-03(01)": [ + "RSK-09.1" ], - "12.5.2": [ - "CPL-01.2", - "CFG-03.1", - "NET-06", - "NET-08.1", - "TPM-04.4" + "CA-07(04)": [ + "RSK-11" ], - "10.7.1": [ - "CPL-02", - "CPL-03", - "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "END-16", - "IRO-01", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "SEA-04.1", - "TPM-11" + "SC-07(18)": [ + "SEA-01" ], - "10.7.2": [ - "CPL-02", - "CPL-03", - "CPL-03.2", - "CFG-02.8", - "MON-01", - "MON-01.4", - "END-06.2", - "IRO-01", - "RSK-06", - "RSK-06.1", - "SEA-01.1", - "TPM-11" + "PL-08": [ + "SEA-02" ], - "1.2.7": [ - "CPL-03.2", - "CFG-03.1", - "NET-04.6", - "NET-06", - "NET-08.1" + "SC-02": [ + "SEA-03.2" ], - "1.2.6": [ - "CFG-02", - "CFG-03", - "NET-06", - "NET-08.1", - "RSK-06.2", - "TDA-02.6" + "SC-39": [ + "SEA-04" ], - "2.2.1": [ - "CFG-02" + "SC-04": [ + "SEA-05" ], - "8.3.2": [ - "CFG-02", - "CRY-01", - "CRY-03", - "CRY-05" + "SA-03(03)": [ + "SEA-07.1", + "SEA-08.1" ], - "10.2.1": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "SI-16": [ + "SEA-10" ], - "10.2.1.1": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "AC-08": [ + "SEA-18" ], - "10.2.1.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3", - "IAC-21.4" + "SC-38": [ + "OPS-01", + "OPS-04" ], - "10.2.1.3": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "AT-02": [ + "SAT-02" ], - "10.2.1.4": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "AT-02(03)": [ + "SAT-02.2" ], - "10.2.1.5": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "AT-03": [ + "SAT-03" ], - "10.2.1.6": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "AT-04": [ + "SAT-04" ], - "10.2.1.7": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2", - "MON-03.3" + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "10.2.2": [ - "CFG-02", - "CFG-02.5", - "MON-03", - "MON-03.2" + "SA-23": [ + "TDA-01", + "TDA-01.1", + "TDA-12" ], - "10.6.1": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "SA-04(09)": [ + "TDA-02.1" ], - "10.6.2": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "SA-04(10)": [ + "TDA-02.2" ], - "10.6.3": [ - "CFG-02", - "CFG-02.5", - "MON-02.7", - "MON-07", - "MON-07.1", - "SEA-20" + "SA-04(03)": [ + "TDA-02.3", + "TDA-06" ], - "1.5.1": [ - "CFG-02.5", - "CFG-03.4", - "DCH-13.1", - "END-01", - "END-02", - "END-05" + "SR-03(01)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" ], - "1.2.5": [ - "CFG-03", - "NET-06", - "NET-08.1", - "TDA-02.5", - "TPM-04.2" + "SA-15": [ + "TDA-06" ], - "1.4.1": [ - "CFG-03", - "NET-02", - "NET-03", - "NET-03.8", - "NET-06", - "NET-08.1", - "NET-09", - "SEA-03" + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" ], - "1.4.2": [ - "CFG-03", - "NET-03", - "NET-03.1", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "SA-15(03)": [ + "TDA-06.1" ], - "11.6.1": [ - "CFG-03.1", - "MON-01.7", - "END-06", - "WEB-13" + "SA-11(02)": [ + "TDA-06.2", + "TDA-15" ], - "12.3.1": [ - "CFG-03.1", - "RSK-01.1", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.2", - "RSK-07" + "SA-11": [ + "TDA-09" ], - "12.3.4": [ - "CFG-03.1", - "SEA-02.3", - "SEA-07.1" + "SA-11(06)": [ + "TDA-09", + "VPM-01.1" ], - "12.6.2": [ - "CFG-03.1", - "SAT-01" + "SA-11(07)": [ + "TDA-09", + "VPM-01.1" ], - "12.6.3": [ - "CFG-03.1", - "HRS-03.1", - "HRS-05.7", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.6", - "SAT-04" + "SA-11(01)": [ + "TDA-09.2" ], - "10.4.3": [ - "MON-01", - "MON-01.4", - "MON-01.8" + "SR-11": [ + "TDA-11" ], - "1.4.3": [ - "MON-01.1", - "NET-04", - "NET-08", - "NET-08.2" + "SR-11(01)": [ + "TDA-11.1" ], - "11.5.1": [ - "MON-01.1", - "NET-03", - "NET-08", - "SAT-03.2" + "SA-10": [ + "TDA-14" ], - "11.5.1.1": [ - "MON-01.1", - "MON-11.1", - "MON-15", - "NET-08", - "SAT-03.2" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "10.4.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", - "MON-02", - "MON-02.2" + "SI-11": [ + "TDA-19" ], - "10.4.1.1": [ - "MON-01.2", - "MON-01.4", - "MON-01.8", - "MON-02", - "MON-02.1", - "MON-02.2" + "SR-02(01)": [ + "TPM-03" ], - "10.3.4": [ - "MON-01.7", - "END-06" + "SR-05": [ + "TPM-03.1" ], - "11.5.2": [ - "MON-01.7", - "END-06" + "SR-03": [ + "TPM-03.3" ], - "10.4.2": [ - "MON-01.8" + "SA-09": [ + "TPM-04" ], - "10.4.2.1": [ - "MON-01.8" + "SA-09(01)": [ + "TPM-04.1" ], - "10.3.3": [ - "MON-02", - "MON-02.2", - "MON-08.1" + "SA-09(02)": [ + "TPM-04.2" ], - "12.10.5": [ - "MON-02.1", - "IRO-02", - "IRO-04", - "NET-12.1" + "SR-03(03)": [ + "TPM-05", + "TPM-05.2" ], - "6.4.2": [ - "MON-03", - "IAO-04", - "TDA-15", - "VPM-05.1", - "WEB-01", - "WEB-03" + "SR-08": [ + "TPM-05.1" ], - "7.2.6": [ - "MON-03.7", - "IAC-20", - "IAC-20.1", - "IAC-20.2", - "IAC-21" + "SR-06": [ + "TPM-08" ], - "10.3.1": [ - "MON-08", - "MON-08.2" + "AT-02(02)": [ + "THR-05" ], - "10.3.2": [ - "MON-08", - "MON-08.2" + "RA-05(11)": [ + "THR-06" ], - "10.5.1": [ - "MON-10", - "DCH-18", - "PRI-05" + "SI-02(04)": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" ], - "2.2.7": [ - "CRY-01", - "CRY-02", - "CRY-06", - "MNT-05.3" + "SI-02(02)": [ + "VPM-05.2" ], - "3.3.2": [ - "CRY-01", - "CRY-05" + "SI-02(03)": [ + "VPM-05.3" ], - "12.3.3": [ - "CRY-01", - "CRY-01.5" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "3.6.1.1": [ - "CRY-02", - "CRY-09", - "IAC-12" + "RA-05(02)": [ + "VPM-06.1" ], - "3.6.1.2": [ - "CRY-02", - "CRY-09", - "IAC-12" + "RA-05(03)": [ + "VPM-06.2" ], - "4.2.1": [ - "CRY-03", - "NET-12", - "NET-15.1" + "RA-05(05)": [ + "VPM-06.3" ], - "4.2.1.2": [ - "CRY-03", - "CRY-07", - "NET-12.1" + "CA-08": [ + "VPM-07" ], - "A2.1.1": [ - "CRY-03", - "WEB-10" + "CA-08(01)": [ + "VPM-07.1" ], - "A2.1.2": [ - "CRY-03", - "WEB-10" + "CA-08(02)": [ + "VPM-10" + ] + }, + "usa-federal-gsa-fedramp-5-high": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" ], - "3.5.1.2": [ - "CRY-05" + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "3.5.1.3": [ - "CRY-05" + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "2.3.1": [ - "CRY-07", - "IAC-10.8", - "NET-12.1", - "NET-15.1" + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "2.3.2": [ - "CRY-07", - "CRY-09.3", - "NET-12.1", - "NET-15.1" + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "3.6.1": [ - "CRY-08.1", - "CRY-09", - "CRY-09.3", - "CRY-09.4" + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "3.5.1.1": [ - "CRY-09" + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "3.6.1.3": [ - "CRY-09" + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "3.6.1.4": [ - "CRY-09" + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "3.7.4": [ - "CRY-09" + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "4.2.1.1": [ - "CRY-09" + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "3.7.9": [ - "CRY-09.6" + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "3.5.1": [ - "DCH-01.2" + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "9.4.2": [ - "DCH-02", - "RSK-02" + "PT-01": [ + "GOV-02", + "GOV-03", + "PRI-01", + "SEA-01" ], - "3.4.1": [ - "DCH-03.2", - "END-16", - "PRI-05.3" + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "9.4.5": [ - "DCH-06.2" + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" ], - "9.4.5.1": [ - "DCH-06.2" + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "3.3.1": [ - "DCH-06.5" + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "3.3.1.2": [ - "DCH-06.5" + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "3.3.1.3": [ - "DCH-06.5" + "PL-09": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" ], - "3.3.3": [ - "DCH-06.5" + "PM-06": [ + "GOV-04", + "GOV-05" ], - "9.4.3": [ - "DCH-07", - "DCH-07.1" + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" ], - "9.4.6": [ - "DCH-08", - "DCH-18", - "PRI-05" + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "1.4.4": [ - "DCH-15", - "NET-05.1" + "PM-15": [ + "GOV-07", + "THR-01" ], - "3.2.1": [ - "DCH-18", - "TPM-04.4" + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" ], - "11.4.1": [ - "DCH-18", - "IAO-04", - "TDA-15", - "VPM-07", - "VPM-07.1" + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" ], - "5.2.1": [ - "END-04" + "PM-05": [ + "AST-01", + "AST-02" ], - "5.2.2": [ - "END-04" + "CM-08": [ + "AST-02", + "AST-02.3" ], - "5.3.1": [ - "END-04", - "END-04.1" + "CM-08(01)": [ + "AST-02.1" ], - "5.3.2": [ - "END-04", - "END-04.7" + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" ], - "5.3.2.1": [ - "END-04", - "END-04.7" + "SC-18(02)": [ + "AST-02.7", + "END-10" ], - "5.3.3": [ - "END-04", - "END-04.7" + "CM-08(02)": [ + "AST-02.9" ], - "5.3.4": [ - "END-04", - "END-04.3" + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" ], - "5.3.5": [ - "END-04", - "END-04.7" + "CM-08(04)": [ + "AST-03.1" ], - "5.2.3": [ - "END-04.6" + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "5.2.3.1": [ - "END-04.6" + "SA-04(01)": [ + "AST-04", + "TDA-04.1" ], - "5.4.1": [ - "END-08" + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" ], - "2.2.3": [ - "END-16", - "END-16.1", - "SEA-04.1" + "PE-22": [ + "AST-04.1", + "PES-16" ], - "11.4.5": [ - "END-16", - "NET-06", - "NET-08.1", - "SEA-04.1", - "TDA-07", - "VPM-07", - "VPM-07.1" + "SA-05": [ + "AST-04.1", + "TDA-04" ], - "11.4.6": [ - "END-16", - "NET-06", - "NET-08.1", - "SEA-04.1", - "TDA-07", - "VPM-07", - "VPM-07.1" + "SR-12": [ + "AST-09" ], - "12.2.1": [ - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "SR-09": [ + "AST-15" ], - "12.7.1": [ - "HRS-01", - "HRS-02", - "HRS-02.1", - "HRS-04", - "HRS-04.1" + "SR-09(01)": [ + "AST-15" ], - "6.2.2": [ - "HRS-03.2", - "IAO-04", - "SAT-03", - "SAT-03.8", - "TDA-06.3", - "TDA-13", - "TDA-15" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "8.2.5": [ - "HRS-09", - "HRS-09.2", - "IAC-07.1", - "IAC-07.2", - "IAC-20.6" + "CP-02": [ + "BCD-01", + "BCD-06" + ], + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "6.5.4": [ - "HRS-11" + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" ], - "7.2.1": [ - "IAC-01", - "IAC-02", - "IAC-03", - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "PM-08": [ + "BCD-01", + "CPL-01" ], - "7.3.1": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "CP-02(01)": [ + "BCD-01.1" ], - "7.3.2": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "CP-06(02)": [ + "BCD-01.4" ], - "7.3.3": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-21" + "CP-02(08)": [ + "BCD-02" ], - "8.3.3": [ - "IAC-01", - "IAC-02", - "IAC-10", - "IAC-10.1", - "IAC-28" + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" ], - "8.5.1": [ - "IAC-01", - "IAC-02.2", - "IAC-06", - "SEA-01" + "CP-02(05)": [ + "BCD-02.2" ], - "8.6.1": [ - "IAC-01", - "IAC-05.1", - "IAC-15", - "IAC-15.7", - "IAC-19", - "IAC-20.3", - "IAC-21" + "CP-03": [ + "BCD-03" ], - "8.3.9": [ - "IAC-02", - "IAC-10", - "IAC-10.1" + "CP-03(01)": [ + "BCD-03.1" ], - "8.2.2": [ - "IAC-02.1", - "IAC-15.5", - "IAC-19" + "CP-04": [ + "BCD-04", + "BCD-05" ], - "8.2.3": [ - "IAC-03.2", - "IAC-05", - "IAC-05.1", - "IAC-06", - "NET-14", - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.3" + "CP-04(01)": [ + "BCD-04.1" ], - "8.4.2": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4" + "CP-04(02)": [ + "BCD-04.2" ], - "8.4.3": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2" + "CP-06": [ + "BCD-08" ], - "8.4.1": [ - "IAC-06.1" + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" ], - "7.2.3": [ - "IAC-07", - "IAC-07.1", - "IAC-16", - "IAC-21.3" + "CP-06(01)": [ + "BCD-08.1" ], - "8.2.4": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "IAC-10", - "IAC-15" + "CP-06(03)": [ + "BCD-08.2" ], - "8.3.5": [ - "IAC-07", - "IAC-10", - "IAC-10.1" + "CP-07": [ + "BCD-09" ], - "7.2.2": [ - "IAC-08", - "IAC-20", - "IAC-20.1", - "IAC-21" + "CP-07(01)": [ + "BCD-09.1" ], - "7.2.5": [ - "IAC-08", - "IAC-16", - "IAC-20", - "IAC-20.1", - "NET-14" + "CP-07(02)": [ + "BCD-09.2" ], - "8.2.1": [ - "IAC-09", - "IAC-09.1" + "CP-07(03)": [ + "BCD-09.3" ], - "8.3.1": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "CP-07(04)": [ + "BCD-09.4" ], - "8.3.7": [ - "IAC-10", - "IAC-10.1" + "CP-08": [ + "BCD-10" ], - "8.3.10.1": [ - "IAC-10", - "IAC-10.1" + "CP-08(02)": [ + "BCD-10" ], - "8.3.11": [ - "IAC-10", - "IAC-10.2", - "IAC-10.5", - "IAC-10.7", - "IAC-18", - "PES-02", - "PES-02.1" + "CP-08(01)": [ + "BCD-10.1" ], - "8.6.3": [ - "IAC-10", - "IAC-10.1" + "CP-08(03)": [ + "BCD-10.2" ], - "8.3.6": [ - "IAC-10.1" + "CP-08(04)": [ + "BCD-10.3" ], - "8.6.2": [ - "IAC-10.6" + "CP-09": [ + "BCD-11" ], - "8.2.8": [ - "IAC-14", - "IAC-24", - "IAC-25", - "NET-07" + "SC-28(02)": [ + "BCD-11", + "CRY-05.2" ], - "8.3.10": [ - "IAC-15", - "WEB-06" + "CP-09(01)": [ + "BCD-11.1" ], - "8.2.6": [ - "IAC-15.3" + "CP-09(03)": [ + "BCD-11.2" ], - "7.2.4": [ - "IAC-16.1", - "IAC-17" + "CP-09(08)": [ + "BCD-11.4" ], - "7.2.5.1": [ - "IAC-17" + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" ], - "3.4.2": [ - "IAC-21", - "NET-14" + "CP-09(02)": [ + "BCD-11.5" ], - "8.3.4": [ - "IAC-22" + "CP-09(05)": [ + "BCD-11.6" ], - "12.10.7": [ - "IRO-04", - "IRO-12", - "IRO-12.3" + "CP-10(02)": [ + "BCD-12.1" ], - "12.10.2": [ - "IRO-04.2", - "IRO-06" + "SI-13": [ + "BCD-12.2", + "SEA-07" ], - "12.10.6": [ - "IRO-04.2", - "IRO-13" + "CP-10(04)": [ + "BCD-12.4" ], - "12.10.4": [ - "IRO-05" + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "12.10.4.1": [ - "IRO-05" + "SC-05(02)": [ + "CAP-02", + "CAP-03" ], - "12.10.3": [ - "IRO-07" + "CP-02(02)": [ + "CAP-03" ], - "6.2.1": [ - "IAO-04", - "SEA-01", - "TDA-01", - "TDA-02.3", - "TDA-05", - "TDA-06", - "TDA-15" + "CM-03": [ + "CHG-01", + "CHG-02" ], - "6.2.3": [ - "IAO-04", - "TDA-06.5", - "TDA-09", - "TDA-15" + "SA-08(31)": [ + "CHG-02", + "CHG-02.2", + "CHG-06" ], - "6.2.3.1": [ - "IAO-04", - "TDA-09", - "TDA-15" + "CM-03(01)": [ + "CHG-02.1" ], - "6.2.4": [ - "IAO-04", - "TDA-06", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TDA-15" + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" ], - "6.4.1": [ - "IAO-04", - "TDA-15", - "VPM-05.1", - "VPM-06", - "VPM-06.6", - "WEB-01", - "WEB-03" + "CM-03(04)": [ + "CHG-02.3" ], - "11.4.4": [ - "IAO-04", - "TDA-15", - "VPM-07" + "CM-03(06)": [ + "CHG-02.5" ], - "12.4.2.1": [ - "IAO-04", - "TDA-15", - "TPM-05", - "TPM-08" + "CM-04": [ + "CHG-03" ], - "8.2.7": [ - "MNT-05", - "MNT-05.1", - "MNT-05.4", - "NET-14", - "NET-14.6" + "CM-05": [ + "CHG-04", + "END-03.2" ], - "11.2.1": [ - "NET-01", - "NET-02.2", - "NET-03.1", - "NET-12.1", - "NET-15", - "NET-15.5" + "CM-05(01)": [ + "CHG-04.1" ], - "1.3.3": [ - "NET-02.2", - "NET-03", - "NET-03.7", - "NET-04.1", - "NET-04.7", - "NET-06", - "NET-08.1", - "NET-12.1" + "CM-14": [ + "CHG-04.2" ], - "1.4.5": [ - "NET-03.3", - "VPM-06.8" + "SI-07(15)": [ + "CHG-04.2" ], - "1.3.2": [ - "NET-03.5", - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "1.3.1": [ - "NET-04", - "NET-04.1", - "NET-06", - "NET-08.1" + "CM-05(05)": [ + "CHG-04.4" ], - "4.2.2": [ - "NET-12.2" + "CM-09": [ + "CHG-05", + "CFG-01" ], - "9.2.1": [ - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1", - "PES-03.3" + "SI-06": [ + "CHG-06" ], - "9.3.1": [ - "PES-02", - "PES-02.1", - "PES-03.1" + "SC-07(29)": [ + "CLD-03", + "NET-03.8", + "NET-06.1" ], - "9.3.1.1": [ - "PES-02.1", - "PES-04", - "PES-04.1" + "SA-09(05)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" ], - "9.2.4": [ - "PES-03.2", - "PES-12" + "SA-09(08)": [ + "CLD-09", + "DCH-19" ], - "9.2.1.1": [ - "PES-03.3", - "PES-05", - "PES-05.1", - "PES-05.2" + "CA-07": [ + "CPL-02" ], - "9.3.2": [ - "PES-06", - "PES-06.1", - "PES-06.2", - "PES-06.3", - "OPS-01", - "OPS-01.1" + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" ], - "9.3.3": [ - "PES-06", - "PES-06.6" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "9.3.4": [ - "PES-06", - "PES-06.4", - "PES-06.5" + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "9.2.2": [ - "PES-12", - "PES-12.1", - "PES-12.2" + "RA-03": [ + "CPL-03.2", + "RSK-04" ], - "9.2.3": [ - "PES-12", - "PES-12.1", - "PES-12.2" + "CM-02": [ + "CFG-02", + "CFG-02.1" ], - "12.9.1": [ - "PRI-01.6", - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.4" + "CM-06": [ + "CFG-02", + "CFG-02.7" ], - "6.5.5": [ - "PRI-05.1", - "PRI-05.4", - "TDA-10" + "PL-10": [ + "CFG-02" ], - "9.5.1.3": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "SA-08": [ + "CFG-02", + "SEA-01" ], - "12.6.1": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "SA-15(05)": [ + "CFG-02", + "SEA-01" ], - "12.6.3.1": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "CM-02(02)": [ + "CFG-02.2" ], - "12.6.3.2": [ - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "CM-06(01)": [ + "CFG-02.2" ], - "2.2.6": [ - "TDA-05.1" + "CM-02(03)": [ + "CFG-02.3" ], - "12.9.2": [ - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.4" + "CM-02(07)": [ + "CFG-02.5" ], - "A2.1.3": [ - "TPM-01" + "CM-06(02)": [ + "CFG-02.8" ], - "12.8.2": [ - "TPM-04", - "TPM-05", - "TPM-05.4" + "PL-11": [ + "CFG-02.9" ], - "12.8.3": [ - "TPM-04.1" + "CM-07": [ + "CFG-03" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "CM-07(01)": [ + "CFG-03.1" ], - "12.5.3": [ - "TPM-05.5" + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" ], - "12.8.4": [ - "TPM-08" + "CM-07(05)": [ + "CFG-03.3" ], - "6.3.3": [ - "VPM-01", - "VPM-04", - "VPM-05", - "VPM-05.1" + "SC-18(04)": [ + "CFG-03.3", + "END-10" ], - "11.3.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.1", - "VPM-06.2", - "VPM-06.7" + "SC-07(07)": [ + "CFG-03.4" ], - "11.3.1.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06" + "CM-10": [ + "CFG-04" ], - "11.3.1.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.7" + "CM-11": [ + "CFG-05", + "END-03" ], - "11.3.1.3": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.7" + "CM-11(02)": [ + "CFG-05", + "CFG-05.2", + "END-03" ], - "11.3.2": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.6" + "CM-11(03)": [ + "CFG-05.1", + "CFG-06", + "CFG-06.1", + "END-03.1" ], - "11.3.2.1": [ - "VPM-01.1", - "VPM-02", - "VPM-06", - "VPM-06.2", - "VPM-06.6" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "6.4.3": [ - "VPM-05.1", - "WEB-01.1" + "SI-04(01)": [ + "MON-01.1" ], - "11.4.2": [ - "VPM-07", - "VPM-07.1" + "SI-04(25)": [ + "MON-01.1", + "NET-03.1" ], - "11.4.3": [ - "VPM-07", - "VPM-07.1" + "SC-48": [ + "MON-01.2", + "THR-07" ], - "11.4.7": [ - "VPM-07" - ] - }, - "general-pci-dss-4-0-1-saq-p2pe": { - "3.1.1": [ - "GOV-02", - "GOV-03", - "OPS-01", - "OPS-01.1" + "SI-04(02)": [ + "MON-01.2" ], - "9.1.1": [ - "GOV-02", - "GOV-03", - "PES-01", - "OPS-01", - "OPS-01.1" + "SI-04(04)": [ + "MON-01.3" ], - "12.1.1": [ - "GOV-02", - "GOV-03" + "SI-04(05)": [ + "MON-01.4" ], - "12.1.2": [ - "GOV-02", - "GOV-03" + "SI-04(14)": [ + "MON-01.5" ], - "12.1.3": [ - "GOV-02", - "GOV-04", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1" + "SI-04(23)": [ + "MON-01.6" ], - "9.5.1": [ - "AST-01", - "AST-02", - "AST-06", - "AST-07", - "AST-15", - "AST-15.1", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" ], - "9.5.1.1": [ - "AST-01", - "AST-02", - "AST-07" + "AU-02": [ + "MON-01.8", + "MON-02" ], - "9.5.1.2": [ - "AST-07", - "AST-08", - "AST-15.1" + "IR-04(05)": [ + "MON-01.11", + "IRO-02.6" ], - "9.4.1.1": [ - "BCD-11", - "BCD-11.2" + "SI-04(07)": [ + "MON-01.11", + "IRO-02.1" ], - "12.10.1": [ - "BCD-11", - "HRS-03", - "IRO-04", - "IRO-10", - "NET-12.1" + "SI-04(12)": [ + "MON-01.12", + "MON-05.1" ], - "12.8.1": [ - "CLD-01", - "NET-14", - "TPM-01", - "TPM-01.1", - "TPM-05.5" + "SI-04(19)": [ + "MON-01.14" ], - "9.4.1": [ - "DCH-01", - "DCH-01.1", - "DCH-06", - "DCH-06.1" + "SI-04(20)": [ + "MON-01.15" ], - "3.3.1.2": [ - "DCH-06.5" + "AU-06": [ + "MON-02", + "MON-02.6" ], - "9.4.6": [ - "DCH-08", - "DCH-18", - "PRI-05" + "IR-04(04)": [ + "MON-02", + "MON-02.1" ], - "3.2.1": [ - "DCH-18", - "TPM-04.4" + "AU-06(03)": [ + "MON-02.1" ], - "9.5.1.3": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "SI-04(16)": [ + "MON-02.1" ], - "12.6.1": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-04" + "AU-06(04)": [ + "MON-02.2" ], - "12.8.2": [ - "TPM-04", - "TPM-05", - "TPM-05.4" + "AU-06(05)": [ + "MON-02.3" ], - "12.8.3": [ - "TPM-04.1" + "AU-06(06)": [ + "MON-02.4" ], - "12.8.5": [ - "TPM-05", - "TPM-05.4" + "AU-06(07)": [ + "MON-02.5" ], - "12.8.4": [ - "TPM-08" - ] - }, - "general-scf-dpmp-2025": { - "1.0": [ - "GOV-01", - "PRI-01", - "PRI-01.3", - "PRI-01.11" + "AU-12(01)": [ + "MON-02.7" ], - "11.5": [ - "GOV-01.2", - "GOV-05", - "PRI-14" + "AU-12(03)": [ + "MON-02.8" ], - "11.8": [ - "GOV-01.2" + "AU-03": [ + "MON-03" ], - "11.2": [ - "GOV-02", - "PRI-01.3" + "AU-03(01)": [ + "MON-03.1" ], - "11.3": [ - "GOV-03", - "CPL-03" + "AU-06(01)": [ + "MON-03.1" ], - "11.1": [ - "GOV-08", - "PRI-07.2" + "AU-04": [ + "MON-04" ], - "5.9": [ - "GOV-10", - "PRI-05.2" + "AU-05": [ + "MON-05" ], - "7.0": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "MON-01", - "MON-02", - "IAC-01", - "PRI-01.6", - "SEA-01.1", - "TDA-01", - "TDA-09" + "AU-05(02)": [ + "MON-05.1" ], - "7.1": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "CHG-02", - "CHG-03", - "CLD-01", - "CLD-02", - "HRS-04", - "IAC-01.2", - "IAC-06", - "IAC-08", - "IAC-16", - "IAC-21", - "IAC-28.1", - "PRI-01.6", - "SEA-01", - "SEA-02", - "TDA-01.1", - "TDA-02.3", - "TDA-02.4", - "TDA-02.6", - "TDA-02.7", - "TDA-02.8", - "TDA-02.9", - "TDA-02.10", - "TDA-02.11", - "TDA-06", - "TDA-06.5", - "TDA-22" + "AU-05(01)": [ + "MON-05.2" ], - "5.2": [ - "AST-02", - "AST-02.8", - "AST-04", - "CFG-08.1", - "DCH-01.3", - "PRI-11" + "AU-07": [ + "MON-06" ], - "5.3": [ - "AST-03", - "AST-03.1" + "AU-07(01)": [ + "MON-06" ], - "11.7": [ - "BCD-02", - "TDA-06.1", - "TPM-02" + "AU-12": [ + "MON-06" ], - "2.4": [ - "CPL-01", - "PRI-03.5" + "AU-08": [ + "MON-07", + "SEA-20" ], - "11.6": [ - "CPL-01", - "CPL-01.1", - "CPL-01.2", - "CPL-01.3", - "CPL-01.4", - "MON-10", - "PRI-02.3", - "PRI-02.4", - "PRI-02.5", - "PRI-02.6" + "SC-45": [ + "MON-07.1" ], - "11.4": [ - "CPL-02", - "PRI-13" + "SC-45(01)": [ + "MON-07.1" ], - "7.12": [ - "CFG-01", - "CFG-02", - "TDA-09" + "AU-09": [ + "MON-08" ], - "7.13": [ - "MON-02", - "MON-02.1" + "AU-09(02)": [ + "MON-08.1" ], - "7.2": [ - "CRY-01", - "CRY-03", - "CRY-05" + "AU-09(04)": [ + "MON-08.2" ], - "5.0": [ - "DCH-01", - "PRI-02.2", - "PRI-05", - "PRI-11" + "AU-09(03)": [ + "MON-08.3" ], - "1.2": [ - "DCH-02", - "PRI-05.7" + "AU-10": [ + "MON-09" ], - "5.5": [ - "DCH-09.3", - "DCH-21" + "AU-11": [ + "MON-10" ], - "5.4": [ - "DCH-18", - "DCH-18.1" + "SI-04(18)": [ + "MON-11.1", + "NET-17" ], - "3.3": [ - "DCH-18.1", - "PRI-05.1", - "PRI-05.4" + "SI-04(22)": [ + "MON-11.2" ], - "3.2": [ - "DCH-18.2" + "AC-02(12)": [ + "MON-16" ], - "5.15": [ - "DCH-22.1", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-03", - "VPM-04", - "VPM-04.2", - "VPM-05" + "IR-04(13)": [ + "MON-16", + "SEA-11", + "SEA-12" ], - "6.1": [ - "DCH-22.1", - "PRI-06.4", - "PRI-06.8", - "PRI-07.4" + "SI-04(11)": [ + "MON-16" ], - "6.2": [ - "DCH-22.1", - "PRI-12" + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" ], - "5.1": [ - "DCH-23", - "PRI-05.3", - "PRI-09" + "SC-08(02)": [ + "CRY-01", + "CRY-01.3", + "DCH-10" ], - "5.6": [ - "DCH-24", - "DCH-25", - "SEA-15", - "TPM-04.4" + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" ], - "7.4": [ - "EMB-01", - "END-13.1", - "END-13.2", - "END-13.3" + "IA-07": [ + "CRY-02", + "IAC-12" ], - "7.9": [ - "HRS-01" + "SC-08": [ + "CRY-03", + "CRY-04" ], - "7.7": [ - "HRS-05.1", - "HRS-05.2" + "SC-16(01)": [ + "CRY-04", + "CRY-10" ], - "7.8": [ - "HRS-07" + "SC-28": [ + "CRY-05", + "END-02" ], - "8.0": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-06", - "IRO-11" + "AC-18": [ + "CRY-07", + "NET-15" ], - "8.1": [ - "IRO-02", - "IRO-07" + "SC-40": [ + "CRY-07", + "NET-12.1" ], - "8.2": [ - "IRO-10", - "IRO-11.2" + "SC-12": [ + "CRY-08" ], - "7.11": [ - "IAO-01", - "IAO-07", - "RSK-11", - "TDA-09" + "SC-17": [ + "CRY-08" ], - "5.13": [ - "IAO-03", - "PRI-09" + "SC-12(01)": [ + "CRY-09.3" ], - "9.3": [ - "IAO-05", - "RSK-04.1", - "RSK-11" + "MP-02": [ + "DCH-03", + "END-01" ], - "7.3": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-04", - "PES-05", - "PES-06" + "MP-03": [ + "DCH-04", + "DCH-04.1" ], - "1.1": [ - "PRI-01", - "PRI-01.1", - "PRI-01.4", - "PRI-17.2" + "MP-04": [ + "DCH-06" ], - "4.0": [ - "PRI-01.2", - "PRI-02", - "PRI-14.2" + "MP-05": [ + "DCH-07" ], - "4.1": [ - "PRI-02.1", - "PRI-14.2" + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "2.0": [ - "PRI-03" + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" ], - "2.1": [ - "PRI-03" + "MP-06(01)": [ + "DCH-09.1" ], - "2.2": [ - "PRI-03" + "MP-06(02)": [ + "DCH-09.2" ], - "2.5": [ - "PRI-03.1", - "PRI-03.3" + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "2.3": [ - "PRI-03.2", - "PRI-03.4" + "AC-20": [ + "DCH-13" ], - "5.14": [ - "PRI-03.2" + "AC-20(01)": [ + "DCH-13.1" ], - "2.6": [ - "PRI-03.6" + "AC-20(02)": [ + "DCH-13.2" ], - "6.0": [ - "PRI-03.7", - "PRI-06", - "PRI-07.4" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "2.7": [ - "PRI-03.8" + "CA-03(06)": [ + "DCH-14.2" ], - "3.0": [ - "PRI-04" + "AC-22": [ + "DCH-15" ], - "3.1": [ - "PRI-04.1" + "AC-23": [ + "DCH-16", + "PRI-05.4" ], - "1.5": [ - "PRI-05.5", - "PRI-05.6" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "1.7": [ - "PRI-05.7" + "SI-12(01)": [ + "DCH-18.1", + "PRI-05.1" ], - "6.3": [ - "PRI-06.1" + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" ], - "6.4": [ - "PRI-06.2", - "PRI-07.3" + "SA-08(33)": [ + "DCH-18.2", + "END-13.3", + "PES-06.5" ], - "6.5": [ - "PRI-06.3" + "SI-12(02)": [ + "DCH-18.2", + "PRI-05.1" ], - "6.6": [ - "PRI-06.5" + "SI-12(03)": [ + "DCH-21", + "PRI-05" ], - "5.7": [ - "PRI-06.6", - "PRI-06.7" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "10.2": [ - "PRI-07" + "SI-18(04)": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" ], - "10.3": [ - "PRI-07.1", - "TPM-05", - "TPM-05.2" + "SI-18(05)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-06.2" ], - "10.4": [ - "PRI-08", - "TPM-04", - "TPM-05.4", - "TPM-05.5", - "TPM-08", - "TPM-09", - "TPM-10" + "PT-03(01)": [ + "DCH-22.2", + "PRI-11" ], - "5.11": [ - "PRI-10", - "PRI-10.1" + "SI-19(01)": [ + "DCH-22.3", + "DCH-23.1" ], - "5.16": [ - "PRI-10.2" + "SI-19(04)": [ + "DCH-23.4", + "PRI-05.3" ], - "5.8": [ - "PRI-14", - "PRI-14.1" + "CM-12": [ + "DCH-24" ], - "1.3": [ - "PRI-15" + "CM-12(01)": [ + "DCH-24.1" ], - "1.8": [ - "PRI-17" + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "1.9": [ - "PRI-17.1" + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "1.4": [ - "PRM-01" + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" ], - "11.0": [ - "PRM-02", - "TPM-01" + "SI-07(01)": [ + "END-06.1" ], - "5.12": [ - "PRM-04", - "PRM-05", - "PRM-06", - "PRM-07", - "PRM-08", - "SEA-01", - "TDA-06" + "SI-07(07)": [ + "END-06.2" ], - "9.0": [ - "RSK-01", - "RSK-06.2", - "RSK-11" + "SI-07(02)": [ + "END-06.3" ], - "9.1": [ - "RSK-04", - "RSK-04.3", - "RSK-04.4" + "SI-07(05)": [ + "END-06.4" ], - "9.4": [ - "RSK-06.1" + "SI-08": [ + "END-08" ], - "9.2": [ - "RSK-08", - "RSK-09", - "RSK-09.1" + "SI-08(02)": [ + "END-08.2" ], - "9.5": [ - "RSK-10" + "SC-18": [ + "END-10" ], - "1.6": [ - "SAT-01", - "SAT-02", - "SAT-02.1", - "SAT-03", - "SAT-03.1", - "SAT-03.2", - "SAT-03.3", - "SAT-03.6", - "SAT-04" + "SC-18(01)": [ + "END-10", + "VPM-02", + "VPM-04" ], - "7.6": [ - "SAT-01" + "SC-18(03)": [ + "END-10", + "NET-18" ], - "7.5": [ - "TDA-17" + "SC-15": [ + "END-14" ], - "10.0": [ - "TPM-01", - "TPM-04", - "TPM-08", - "TPM-09", - "TPM-10" + "SC-03": [ + "END-16", + "SEA-04.1" ], - "10.1": [ - "TPM-03", - "TPM-04" - ] - }, - "general-shared-assessments-sig-2025": { - "R.6": [ - "GOV-04.1" + "SC-07(12)": [ + "END-16.1" ], - "B.1": [ - "GOV-08" + "PS-02": [ + "HRS-02", + "HRS-03.2" ], - "P.8": [ - "GOV-10", - "CLD-11", - "DCH-01.1", - "PRI-13", - "SEA-11", - "TPM-05.1", - "TPM-07" + "PM-13": [ + "HRS-03", + "SAT-01" ], - "K.1": [ - "GOV-14", - "BCD-11", - "BCD-14", - "CAP-01", - "HRS-13.4" + "PS-09": [ + "HRS-03" ], - "R.1": [ - "AAT-01", - "AAT-03" + "PS-03": [ + "HRS-04" ], - "R.1.1": [ - "AAT-01.1" + "PS-03(03)": [ + "HRS-04.1" ], - "R.1.1.1": [ - "AAT-01.2" + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "R.2": [ - "AAT-01.3" + "PL-04(01)": [ + "HRS-05.2" ], - "R.5": [ - "AAT-02" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "R.2.1": [ - "AAT-03.1" + "PS-06(02)": [ + "HRS-06", + "HRS-06.1" ], - "R.4.1": [ - "AAT-04.2", - "AAT-06" + "PS-08": [ + "HRS-07" ], - "R.10": [ - "AAT-08" + "PS-05": [ + "HRS-08" ], - "R.14": [ - "AAT-09" + "PS-04": [ + "HRS-09" ], - "R.16": [ - "AAT-13.1" + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" ], - "R.18.1": [ - "AAT-15.1" + "PS-04(02)": [ + "HRS-09.4" ], - "R.13": [ - "AAT-16.5" + "PS-07": [ + "HRS-10" ], - "D.1": [ - "AST-01" + "AC-03(02)": [ + "HRS-12.1", + "IAC-20.5" ], - "G.3": [ - "AST-02.11", - "NET-05.2" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "P.3.1": [ - "AST-04.1" + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "O.9": [ - "AST-14.2" + "IA-02": [ + "IAC-02" ], - "M.1.1": [ - "AST-20", - "EMB-01", - "EMB-13", - "END-01", - "TDA-05.2" + "IA-02(05)": [ + "IAC-02.1" ], - "N.9": [ - "AST-22" + "IA-02(08)": [ + "IAC-02.2" ], - "R.9": [ - "AST-31.1" + "IA-02(12)": [ + "IAC-02.3" ], - "K.4": [ - "BCD-01", - "BCD-02.2", - "BCD-10.4", - "BCD-11.2", - "BCD-13" + "IA-08": [ + "IAC-03" ], - "F.1": [ - "BCD-02.4" + "IA-08(01)": [ + "IAC-03.1" ], - "R.8": [ - "BCD-16" + "IA-08(02)": [ + "IAC-03.2" ], - "N.2": [ - "CAP-02", - "CAP-03", - "CLD-02", - "CLD-06", - "EMB-11", - "NET-01", - "SEA-16" + "IA-08(04)": [ + "IAC-03.3" ], - "G.2": [ - "CHG-02.1" + "IA-03": [ + "IAC-04" ], - "J.1": [ - "CLD-01" + "IA-03(04)": [ + "IAC-04", + "IAC-04.1" ], - "N.11": [ - "CLD-12", - "CFG-02", - "CFG-02.9", - "TDA-09.6" + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "L.1": [ - "CPL-01", - "PRI-14" + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "I.1.1": [ - "CFG-02.4", - "TDA-08" + "IA-02(06)": [ + "IAC-06.4" ], - "N.7": [ - "MON-01.1", - "MON-01.5", - "END-07", - "NET-08", - "NET-08.2" + "IA-12(04)": [ + "IAC-07", + "IAC-10.3", + "IAC-28.4" ], - "J.5": [ - "MON-01.8", - "MON-02.3", - "MON-02.4", - "MON-16.1", - "MON-16.2", - "IRO-03" + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "P.6": [ - "MON-03.5", - "DCH-18.1", - "PES-06.5", - "PRI-01.7", - "PRI-04.1" + "AC-02(07)": [ + "IAC-08" ], - "D.3": [ - "MON-10" + "IA-05(08)": [ + "IAC-09.5", + "IAC-10.9" ], - "P.3": [ - "DCH-01", - "PRI-01" + "IA-05": [ + "IAC-10", + "IAC-10.8" ], - "L.6": [ - "DCH-25.1" + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "U.1.5.1": [ - "END-04", - "END-04.2", - "END-04.4" + "IA-05(02)": [ + "IAC-10.2" ], - "J.5.1": [ - "END-04.6" + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" ], - "J.4": [ - "END-06.2", - "IRO-01" + "IA-05(07)": [ + "IAC-10.6" ], - "P.2.2.1": [ - "END-13.1" + "IA-05(13)": [ + "IAC-10.10" ], - "M.3": [ - "END-14.1", - "END-14.2", - "END-14.6" + "IA-06": [ + "IAC-11" ], - "M.1.12": [ - "HRS-05.5" + "IA-11": [ + "IAC-14" ], - "U.1.3": [ - "IAC-10.8" + "AC-02(01)": [ + "IAC-15.1" ], - "U.1.4": [ - "IAC-25" + "AC-02(02)": [ + "IAC-15.2" ], - "K.7": [ - "IRO-12.3" + "AC-02(03)": [ + "IAC-15.3" ], - "M.1.3": [ - "MDM-01", - "MDM-04" + "AC-02(04)": [ + "IAC-15.4" ], - "M.1.2": [ - "MDM-09", - "MDM-11" + "AC-02(09)": [ + "IAC-15.5" ], - "N.5": [ - "NET-03.1", - "NET-03.2", - "NET-14" + "AC-02(11)": [ + "IAC-15.8" ], - "N.3.1": [ - "NET-05.1" + "AC-06(07)": [ + "IAC-17" ], - "N.8": [ - "NET-10", - "NET-10.1", - "WEB-02" + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "P.2.4": [ - "NET-10.2" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "U.1.2": [ - "NET-15.2" + "AC-06(01)": [ + "IAC-21.1" ], - "P.5.3": [ - "PRI-04.2", - "RSK-06" + "AC-06(02)": [ + "IAC-21.2" ], - "P.5.1": [ - "PRI-05.2", - "SEA-09.1" + "AC-06(05)": [ + "IAC-21.3" ], - "P.2.3": [ - "PRI-05.4" + "AC-06(09)": [ + "IAC-21.4" ], - "O.12": [ - "PRI-16" + "AC-06(10)": [ + "IAC-21.5" ], - "P.5": [ - "RSK-10" + "AC-06(03)": [ + "IAC-21.6" ], - "T.3": [ - "SEA-08.1" + "AC-06(08)": [ + "IAC-21.7" ], - "P.4": [ - "SAT-03.5", - "SAT-03.6" + "AC-07": [ + "IAC-22" ], - "C.4": [ - "TDA-22.1" + "AC-10": [ + "IAC-23" ], - "K.6": [ - "TPM-10" + "AC-02(05)": [ + "IAC-24" ], - "T.2": [ - "THR-06", - "VPM-01", - "VPM-05.1", - "VPM-06.3" + "AC-11": [ + "IAC-24" ], - "N.4": [ - "VPM-05" - ] - }, - "general-sparta": { - "CM0005": [ - "GOV-01" + "AC-11(01)": [ + "IAC-24.1" ], - "CM0088": [ - "GOV-02" + "AC-12": [ + "IAC-25" ], - "CM0049": [ - "AAT-12.1", - "AAT-12.2", - "AST-03.2" + "AC-14": [ + "IAC-26" ], - "CM0013": [ - "AST-01.1" + "IA-12": [ + "IAC-28" ], - "CM0022": [ - "AST-01.1", - "AST-04", - "AST-31", - "TDA-06.1", - "TPM-02" + "IA-12(02)": [ + "IAC-28.2" ], - "CM0026": [ - "AST-03.2", - "RSK-09", - "TPM-03" + "IA-12(03)": [ + "IAC-28.3" ], - "CM0001": [ - "AST-04.1", - "DCH-01", - "DCH-01.2", - "DCH-02" + "IA-12(05)": [ + "IAC-28.5" ], - "CM0028": [ - "AST-15", - "TDA-11" + "IR-04": [ + "IRO-02" ], - "CM0057": [ - "AST-15" + "IR-04(01)": [ + "IRO-02.1" ], - "CM0070": [ - "BCD-10.4" + "IR-04(06)": [ + "IRO-02.2" ], - "CM0056": [ - "BCD-11" + "IR-04(02)": [ + "IRO-02.3" ], - "CM0021": [ - "CHG-04.2" + "IR-08": [ + "IRO-04" ], - "CM0023": [ - "CFG-01", - "CFG-02.2" + "IR-02": [ + "IRO-05" ], - "CM0037": [ - "CFG-02", - "CFG-02.5", - "EMB-04", - "EMB-06" + "IR-02(01)": [ + "IRO-05.1" ], - "CM0047": [ - "CFG-02", - "CFG-02.5", - "CFG-03", - "CFG-03.3" + "IR-02(02)": [ + "IRO-05.2" ], - "CM0069": [ - "CFG-03.3" + "IR-03": [ + "IRO-06" ], - "CM0090": [ - "MON-01" + "IR-03(02)": [ + "IRO-06.1" ], - "CM0032": [ - "MON-01.1" + "IR-04(11)": [ + "IRO-07" ], - "CM0073": [ - "MON-01.3", - "MON-11.1", - "NET-08" + "IR-04(12)": [ + "IRO-08", + "IRO-13" ], - "CM0052": [ - "MON-16.1", - "IRO-02.2", - "THR-04", - "THR-05" + "IR-05": [ + "IRO-09" ], - "CM0050": [ - "CRY-01" + "IR-05(01)": [ + "IRO-09.1" ], - "CM0030": [ - "CRY-09" + "IR-06(01)": [ + "IRO-10.1" ], - "CM0014": [ - "END-06.5", - "END-06.6" + "IR-06(02)": [ + "IRO-10.3", + "IRO-13" ], - "CM0054": [ - "HRS-12.1" + "IR-04(10)": [ + "IRO-10.4", + "TPM-11" ], - "CM0031": [ - "IAC-01.2", - "IAC-02" + "IR-06(03)": [ + "IRO-10.4" ], - "CM0035": [ - "IAC-10.5" + "IR-07": [ + "IRO-11" ], - "CM0039": [ - "IAC-21" + "IR-07(01)": [ + "IRO-11.1" ], - "CM0036": [ - "IAC-25" + "IR-09": [ + "IRO-12", + "IRO-12.1" ], - "CM0089": [ - "IAO-01" + "IR-09(02)": [ + "IRO-12.2" ], - "CM0002": [ - "NET-01" + "IR-09(03)": [ + "IRO-12.3" ], - "CM0033": [ - "NET-01" + "IR-09(04)": [ + "IRO-12.4" ], - "CM0038": [ - "NET-06" + "CA-02(01)": [ + "IAO-02.1" ], - "CM0053": [ - "PES-01" + "CA-02(02)": [ + "IAO-02.2" ], - "CM0040": [ - "SEA-05" + "SA-11(05)": [ + "IAO-02.2", + "IAO-04", + "TDA-09", + "TDA-09.5", + "VPM-07" ], - "CM0044": [ - "SEA-07.2" + "CA-02(03)": [ + "IAO-02.3" ], - "CM0074": [ - "SEA-15" + "CA-05": [ + "IAO-05" ], - "CM0041": [ - "SAT-03", - "SAT-03.2", - "SAT-03.3", - "SAT-03.6" + "PM-04": [ + "IAO-05", + "VPM-02" ], - "CM0007": [ - "TDA-03", - "VPM-01" + "CM-04(02)": [ + "IAO-06" ], - "CM0012": [ - "TDA-04.2" + "CA-06": [ + "IAO-07" ], - "CM0017": [ - "TDA-06", - "TDA-06.3" + "MA-02": [ + "MNT-02" ], - "CM0043": [ - "TDA-06", - "TDA-06.3", - "TDA-06.5", - "TDA-09.2", - "TDA-09.3" + "MA-02(02)": [ + "MNT-02.1" ], - "CM0020": [ - "TDA-06.2" + "MA-06": [ + "MNT-03" ], - "CM0004": [ - "TDA-07" + "MA-03": [ + "MNT-04" ], - "CM0019": [ - "TDA-09.2" + "MA-03(01)": [ + "MNT-04.1" ], - "CM0018": [ - "TDA-09.3" + "MA-03(02)": [ + "MNT-04.2" ], - "CM0024": [ - "TDA-11", - "TDA-11.1" + "MA-03(03)": [ + "MNT-04.3" ], - "CM0025": [ - "TPM-01", - "TPM-04.1" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "CM0027": [ - "TPM-03", - "TPM-03.1" + "MA-04(03)": [ + "MNT-05.6" ], - "CM0009": [ - "THR-01" + "MA-05": [ + "MNT-06" ], - "CM0016": [ - "VPM-01", - "VPM-03", - "VPM-03.1" + "MA-05(01)": [ + "MNT-06.1" ], - "CM0010": [ - "VPM-05" + "SR-11(02)": [ + "MNT-07" ], - "CM0008": [ - "VPM-06", - "VPM-07" + "AC-19": [ + "MDM-02" ], - "CM0011": [ - "VPM-06" - ] - }, - "general-swift-cscf-2025": { - "2.4": [ - "GOV-15", - "AST-04", - "AST-04.1", - "DCH-03.1", - "DCH-14", - "DCH-14.2", - "DCH-25", - "NET-02", - "NET-02.3", - "NET-04", - "NET-05", - "NET-05.2" + "AC-19(05)": [ + "MDM-03" ], - "3.1": [ - "AST-09", - "NET-14.5", - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-04", - "PES-04.1", - "PES-05", - "PES-06", - "PES-06.3", - "PES-12" + "SC-07": [ + "NET-03" ], - "2.9": [ - "AST-14", - "MON-16", - "DCH-01", - "DCH-01.2", - "DCH-25", - "DCH-25.1", - "SAT-03.2" + "SC-07(09)": [ + "NET-03", + "NET-03.2" ], - "1.5": [ - "AST-27", - "IAC-20.4", + "SC-07(11)": [ "NET-03", - "NET-04", - "NET-04.1", - "NET-06", - "NET-06.3", - "NET-14", - "WEB-02" + "NET-04.1" ], - "2.6": [ - "AST-27", - "CFG-02.5", - "CRY-01", - "CRY-03", - "CRY-04", - "IAC-20.4", - "NET-01", - "NET-06.3" + "SC-07(03)": [ + "NET-03.1" ], - "6.3": [ - "AST-28", - "AST-28.1", - "MON-02", - "MON-02.2", - "IRO-01", - "IRO-02" + "SC-07(04)": [ + "NET-03.2" ], - "2.8": [ - "BCD-02", - "PRM-05", - "PRM-06", - "TPM-01", - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-04.3", - "TPM-04.4", - "TPM-05", - "TPM-05.2", - "TPM-05.4", - "TPM-05.5", - "TPM-05.6", - "TPM-05.7", - "TPM-08", - "TPM-09", - "TPM-10" + "SC-07(10)": [ + "NET-03.5", + "NET-17" + ], + "SC-07(20)": [ + "NET-03.6" ], - "1.3": [ - "CFG-01", - "CFG-02", - "SEA-01", - "SEA-02", - "SEA-13.1" + "SC-07(21)": [ + "NET-03.7" ], - "2.3": [ - "CFG-01", - "CFG-02", - "CFG-02.1", - "CFG-02.2", - "CFG-02.5", - "CFG-02.8", - "CFG-02.9", - "CFG-03", - "CFG-03.3", - "IAC-21" + "AC-04": [ + "NET-04" ], - "2.10": [ - "CFG-02", - "CFG-02.5", - "CFG-02.7", - "CFG-02.9", - "CFG-03", - "IAC-20", - "IAC-21" + "SC-07(05)": [ + "NET-04.1" ], - "4.1": [ - "CFG-02", - "CFG-02.5", - "IAC-01", - "IAC-10", - "IAC-10.1" + "AC-04(04)": [ + "NET-04.3" ], - "5.2": [ - "CFG-02", - "CRY-01", - "IAC-01", - "IAC-10.7" + "CA-03": [ + "NET-05" ], - "6.4": [ - "MON-01", - "MON-01.16", - "MON-02", - "MON-02.2", - "MON-08", - "MON-10", - "DCH-18" + "CA-09": [ + "NET-05.2" ], - "6.5A": [ - "MON-01", - "MON-01.1", - "END-07", - "NET-08" + "AC-04(21)": [ + "NET-06" ], - "6.2": [ - "MON-01.7", - "MON-02", - "MON-02.2", - "END-06", - "END-06.1", - "IRO-01", - "IRO-02" + "SC-10": [ + "NET-07" ], - "6.1": [ - "MON-02", - "MON-02.2", - "END-01", - "END-04", - "END-04.1", - "IRO-01", - "IRO-02" + "SC-23": [ + "NET-09" ], - "2.1": [ - "CRY-03", - "CRY-04", - "DCH-03.1", - "DCH-03.3", - "DCH-14", - "DCH-14.2" + "SC-20": [ + "NET-10" ], - "2.5A": [ - "CRY-03", - "CRY-04", - "CRY-05", - "CRY-05.1", - "DCH-01", - "DCH-01.2", - "DCH-25" + "SC-22": [ + "NET-10.1" ], - "2.11A": [ - "DCH-01", - "DCH-01.1", - "DCH-01.2", - "DCH-03.1", - "DCH-14", - "PRM-05", - "PRM-06" + "SC-21": [ + "NET-10.2" ], - "5.1": [ - "HRS-01", - "HRS-02", - "HRS-04.1", - "HRS-11", - "IAC-08", - "IAC-20", - "IAC-21" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "5.3A": [ - "HRS-01", - "HRS-02.1", - "HRS-04", - "HRS-04.1", - "HRS-10" + "SI-10": [ + "NET-12", + "TDA-18" ], - "4.2": [ - "IAC-06" + "AC-17": [ + "NET-14" ], - "1.2": [ - "IAC-08", - "IAC-16", - "IAC-21", - "IAC-21.2", - "IAC-21.3" + "AC-17(01)": [ + "NET-14.1" ], - "5.4": [ - "IAC-10", - "IAC-10.5", - "IAC-10.6", - "IAC-10.11" + "AC-17(02)": [ + "NET-14.2" ], - "7.1": [ - "IRO-01", - "IRO-02", - "IRO-02.4", - "IRO-04", - "IRO-06" + "AC-17(03)": [ + "NET-14.3" ], - "7.3A": [ - "IAO-01.1", - "TDA-09.5", - "VPM-07" + "AC-17(04)": [ + "NET-14.4" ], - "1.1": [ - "NET-01", - "NET-02", - "NET-04", - "NET-04.1", - "NET-06", - "NET-06.1", - "NET-06.3", - "NET-06.4", - "WEB-02" + "AC-18(01)": [ + "NET-15.1" ], - "1.4": [ - "NET-01", - "NET-06", - "NET-06.3", - "NET-06.5", + "AC-18(03)": [ + "NET-15.2" + ], + "AC-18(04)": [ + "NET-15.3" + ], + "AC-18(05)": [ + "NET-15.4" + ], + "SC-07(08)": [ "NET-18", "NET-18.1" ], - "7.4A": [ - "RSK-01.1", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-03", - "RSK-03.1", - "RSK-04", - "RSK-04.2", - "THR-03", - "THR-09", - "THR-10" + "SI-04(10)": [ + "NET-18.2" ], - "7.2": [ - "SAT-01", - "SAT-01.1", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "PE-02": [ + "PES-02" ], - "2.2": [ - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-03", - "VPM-04", - "VPM-04.1", - "VPM-04.3", - "VPM-05", - "VPM-05.1", - "VPM-05.8" + "PE-03": [ + "PES-03" ], - "2.7": [ - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-04", - "VPM-06", - "VPM-06.1", - "VPM-06.2", - "VPM-06.4" - ] - }, - "general-tisax-6-0-3": { - "1.2.1": [ - "GOV-01", - "GOV-01.1", - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "GOV-05", - "GOV-15", - "GOV-15.1", - "CPL-01", - "CPL-01.2" + "SC-07(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" ], - "1.1.1": [ - "GOV-02", - "GOV-08", - "GOV-09", - "CPL-01" + "PE-08": [ + "PES-03.3" ], - "1.5.1": [ - "GOV-02", - "GOV-02.1", - "GOV-03", - "CPL-01.1", - "CPL-02", - "CPL-02.1" + "PE-03(01)": [ + "PES-03.4" ], - "7.1.1": [ - "GOV-02", - "CPL-01" + "PE-06": [ + "PES-05" ], - "9.1.1": [ - "GOV-02" + "PE-06(01)": [ + "PES-05.1" ], - "1.2.2": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "AST-01.2", - "HRS-02", - "HRS-03", - "HRS-03.2" + "PE-06(04)": [ + "PES-05.2" ], - "1.2.4": [ - "GOV-04.1", - "GOV-15.1", - "AST-04.1", - "HRS-03", - "TPM-05", - "TPM-05.4" + "PE-08(01)": [ + "PES-06.4" ], - "7.1.2": [ - "GOV-09", - "CPL-01", - "PRI-01", - "PRI-01.6" + "PE-09": [ + "PES-07" ], - "5.3.1": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "CHG-03", - "CFG-01", - "IAO-02", - "PRM-04", - "PRM-07", - "SEA-01", - "SEA-01.1", - "SEA-02" + "PE-10": [ + "PES-07.2" ], - "5.3.2": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "PRM-05" + "PE-11": [ + "PES-07.3" ], - "3.1.3": [ - "AST-01", - "AST-09", - "MNT-04.3", - "PES-10" + "PE-11(01)": [ + "PES-07.3" ], - "5.3.3": [ - "AST-01", - "AST-02.1", + "PE-12": [ + "PES-07.4" + ], + "PE-15": [ + "PES-07.5" + ], + "PE-15(01)": [ + "PES-07.6" + ], + "PE-13": [ + "PES-08" + ], + "PE-13(01)": [ + "PES-08.1" + ], + "PE-13(02)": [ + "PES-08.2", + "PES-08.3" + ], + "PE-14": [ + "PES-09" + ], + "PE-14(02)": [ + "PES-09.1" + ], + "PE-16": [ "PES-10" ], - "1.3.1": [ - "AST-01.1", - "AST-01.2", - "AST-03" + "PE-17": [ + "PES-11" ], - "1.3.4": [ - "AST-02.7", - "CFG-03.2", - "CFG-04", - "CFG-05" + "PE-18": [ + "PES-12" ], - "1.2.3": [ - "AST-04.1", - "DCH-02", - "PRM-04", - "PRM-05" + "PE-04": [ + "PES-12.1" ], - "8.2.4": [ - "AST-04.1", - "DCH-02" + "PE-05": [ + "PES-12.2" ], - "8.2.6": [ - "AST-04.1", - "DCH-01.2", - "DCH-02", - "DCH-06", - "DCH-09.3", - "END-13.2" + "PT-03": [ + "PRI-02.1", + "PRI-05.1" ], - "5.2.8": [ - "BCD-01", - "BCD-02" + "PT-03(02)": [ + "PRI-02.2", + "PRI-10.1" ], - "5.2.9": [ - "BCD-11" + "PT-02": [ + "PRI-04", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" ], - "5.2.1": [ - "CHG-01", - "CHG-02" + "PT-07": [ + "PRI-05.4", + "PRI-05.7" ], - "5.2.2": [ - "CHG-02.3", - "CHG-03" + "PM-05(01)": [ + "PRI-05.5", + "PRI-05.6" ], - "5.2.6": [ - "CPL-02", - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "1.5.2": [ - "CPL-03", - "CPL-03.2", - "IAO-05" + "SA-02": [ + "PRM-03" ], - "3.1.4": [ - "CFG-02", - "MDM-01" + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "5.2.4": [ - "MON-01", - "MON-01.4", - "MON-02", - "MON-02.1", - "MON-02.2" + "SA-03": [ + "PRM-07", + "SEA-07.1" ], - "5.1.1": [ - "CRY-01" + "SA-03(01)": [ + "PRM-07", + "SEA-07.1", + "TDA-07" ], - "5.1.2": [ - "DCH-01", - "DCH-02", - "NET-01" + "SA-08(30)": [ + "PRM-07", + "SEA-07.1" ], - "1.3.2": [ - "DCH-01.2", - "DCH-01.4", - "DCH-02" + "RA-02": [ + "RSK-02" ], - "8.2.7": [ - "DCH-07.1", - "HRS-05.1" + "RA-07": [ + "RSK-06.1" ], - "5.2.3": [ - "END-02", - "END-04" + "SR-02": [ + "RSK-09", + "TPM-03" ], - "8.2.5": [ - "HRS-01", - "HRS-05.1", - "IAC-07" + "SR-07": [ + "RSK-09", + "OPS-01" ], - "2.1.1": [ - "HRS-02", - "HRS-02.1", - "HRS-03", - "HRS-03.2", - "HRS-04", - "HRS-04.1" + "RA-03(01)": [ + "RSK-09.1" ], - "9.7.2": [ - "HRS-03", - "SAT-03" + "CA-07(04)": [ + "RSK-11" ], - "2.1.3": [ - "HRS-03.1", - "SAT-02" + "SC-07(18)": [ + "SEA-01" ], - "2.1.2": [ - "HRS-05", - "HRS-06", - "HRS-06.1" + "PL-08": [ + "SEA-02" ], - "9.7.1": [ - "HRS-05" + "SC-02": [ + "SEA-03.2" ], - "6.1.2": [ - "HRS-06.1" + "SC-39": [ + "SEA-04" ], - "4.1.1": [ - "IAC-01" + "SC-04": [ + "SEA-05" ], - "4.1.2": [ - "IAC-02" + "SA-03(03)": [ + "SEA-07.1", + "SEA-08.1" ], - "4.1.3": [ - "IAC-02", - "IAC-07", - "IAC-10.5", - "IAC-10.8", - "IAC-15.5" + "SC-24": [ + "SEA-07.2" ], - "4.2.1": [ - "IAC-07", - "IAC-08", - "IAC-17", - "IAC-21", - "IAC-28.1" + "SI-16": [ + "SEA-10" ], - "1.6.1": [ - "IRO-02", - "IRO-03" + "AC-08": [ + "SEA-18" ], - "1.6.2": [ - "IRO-02", - "IRO-09", - "IRO-10", - "IRO-13" + "SC-38": [ + "OPS-01", + "OPS-04" ], - "1.6.3": [ - "IRO-02", - "IRO-04", - "IRO-07" + "AT-02": [ + "SAT-02" ], - "9.6.2": [ - "IRO-02", - "IRO-04", - "IRO-10.2" + "AT-02(03)": [ + "SAT-02.2" ], - "5.2.7": [ - "NET-01", - "NET-06" + "AT-03": [ + "SAT-03" ], - "2.1.4": [ - "NET-14", - "NET-14.5", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "AT-04": [ + "SAT-04" ], - "8.1.2": [ - "PES-01" + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "8.1.1": [ - "PES-01.1", - "OPS-02" + "SA-23": [ + "TDA-01", + "TDA-01.1", + "TDA-12" ], - "3.1.1": [ - "PES-01.2" + "SA-04(09)": [ + "TDA-02.1" ], - "8.1.3": [ - "PES-03" + "SA-04(10)": [ + "TDA-02.2" ], - "5.3.4": [ - "PES-03.4", - "PES-04", - "PES-18" + "SA-04(03)": [ + "TDA-02.3", + "TDA-06" ], - "8.1.5": [ - "PES-04" + "SR-03(01)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" ], - "8.1.8": [ - "PES-04", - "PES-18" + "SA-04(05)": [ + "TDA-02.4" ], - "8.1.6": [ - "PES-05", - "PES-05.1" + "SA-17": [ + "TDA-05" ], - "8.1.7": [ - "PES-06" + "SA-15": [ + "TDA-06" ], - "8.1.4": [ - "PES-12" + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" ], - "9.5.1": [ - "PRI-01.5" + "SA-15(03)": [ + "TDA-06.1" ], - "9.5.2": [ - "PRI-01.5", - "PRI-04.1", - "PRI-07", - "PRI-07.1" + "SA-11(02)": [ + "TDA-06.2", + "TDA-15" ], - "9.5.3": [ - "PRI-01.5" + "CM-04(01)": [ + "TDA-08" ], - "9.2.1": [ - "PRI-01.7" + "SA-11": [ + "TDA-09" ], - "9.6.1": [ - "PRI-06.4" + "SA-11(06)": [ + "TDA-09", + "VPM-01.1" ], - "9.3.1": [ - "PRI-15" + "SA-11(07)": [ + "TDA-09", + "VPM-01.1" ], - "8.3.1": [ - "PRM-05", - "TPM-05", - "TPM-05.1" + "SA-11(01)": [ + "TDA-09.2" ], - "1.4.1": [ - "RSK-01", - "RSK-01.1", - "RSK-03", - "RSK-03.1", - "RSK-04", - "RSK-04.1" + "SR-11": [ + "TDA-11" ], - "9.4.1": [ - "RSK-10" + "SR-11(01)": [ + "TDA-11.1" ], - "9.8.1": [ - "OPS-01.1", - "OPS-05" + "SA-21": [ + "TDA-13" ], - "8.2.3": [ - "SAT-01", - "SAT-02", - "SAT-04" + "SA-10": [ + "TDA-14" ], - "1.3.3": [ - "TPM-01", - "TPM-04.1", - "TPM-05", - "TPM-05.4" + "SA-16": [ + "TDA-16" ], - "6.1.1": [ - "TPM-04.1", - "TPM-05", - "TPM-05.2", - "TPM-08" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "8.2.1": [ - "TPM-05" + "SI-11": [ + "TDA-19" ], - "8.2.2": [ + "SR-02(01)": [ + "TPM-03" + ], + "SR-05": [ + "TPM-03.1" + ], + "SR-03": [ + "TPM-03.3" + ], + "SA-09": [ + "TPM-04" + ], + "SA-09(01)": [ + "TPM-04.1" + ], + "SA-09(02)": [ + "TPM-04.2" + ], + "SR-03(03)": [ "TPM-05", - "TPM-05.6", - "TPM-05.8" + "TPM-05.2" ], - "5.2.5": [ - "THR-03", - "VPM-01.1", - "VPM-02", - "VPM-03", - "VPM-03.1" - ] - }, - "general-ul-2900-1-2017": { - "4.1(e)": [ - "CHG-04.5" + "SR-08": [ + "TPM-05.1" ], - "4.1(g)": [ - "IAO-01.1" + "SR-06": [ + "TPM-08" ], - "4.1(h)": [ - "IAO-02.2" + "SI-05(01)": [ + "THR-03" ], - "12.1(g)": [ - "IAO-05" + "AT-02(02)": [ + "THR-05" ], - "12.1(h)": [ - "IAO-05" + "RA-05(11)": [ + "THR-06" ], - "12.1(a)": [ - "PRM-05" + "SI-02(04)": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" ], - "12.1(f)": [ - "RSK-01.3" + "SI-02(02)": [ + "VPM-05.2" ], - "12.1(d)": [ - "RSK-04" + "SI-02(03)": [ + "VPM-05.3" ], - "12.1(e)": [ - "RSK-04" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "12.1": [ - "RSK-10", - "TDA-06.2" + "RA-05(02)": [ + "VPM-06.1" ], - "7.1": [ - "TDA-01.1" + "RA-05(03)": [ + "VPM-06.2" ], - "7.1.1": [ - "TDA-01.1" + "RA-05(05)": [ + "VPM-06.3" ], - "7.1.2": [ - "TDA-01.1" + "RA-05(08)": [ + "VPM-06.5" ], - "7.1.3": [ - "TDA-01.1" + "RA-05(04)": [ + "VPM-06.8" ], - "7.1.4": [ - "TDA-01.1" + "CA-08": [ + "VPM-07" ], - "7.1.5": [ - "TDA-01.1" + "CA-08(01)": [ + "VPM-07.1" ], - "8.1": [ - "TDA-01.1" + "CA-08(02)": [ + "VPM-10" + ] + }, + "usa-federal-gsa-fedramp-5-li-saas": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" ], - "8.2": [ - "TDA-01.1" + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "8.3": [ - "TDA-01.1" + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "8.3(a)": [ - "TDA-01.1" + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "8.3(b)": [ - "TDA-01.1" + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "8.3(c)": [ - "TDA-01.1" + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "8.3(c)(i)": [ - "TDA-01.1" + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "8.3(c)(ii)": [ - "TDA-01.1" + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "8.3(c)(iii)": [ - "TDA-01.1" + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "8.3(d)": [ - "TDA-01.1" + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "8.3(e)": [ - "TDA-01.1" + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "8.3(f)": [ - "TDA-01.1" + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "8.4": [ - "TDA-01.1" + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "8.4(a)": [ - "TDA-01.1" + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "8.4(b)": [ - "TDA-01.1" + "PT-01": [ + "GOV-02", + "GOV-03", + "PRI-01", + "SEA-01" ], - "8.5": [ - "TDA-01.1" + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "8.6": [ - "TDA-01.1" + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" ], - "8.7": [ - "TDA-01.1" + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "8.8": [ - "TDA-01.1" + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "8.9": [ - "TDA-01.1" + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "9.1": [ - "TDA-01.1" + "PL-09": [ + "GOV-04", + "MON-03.6", + "END-04.3", + "END-08.1", + "SEA-01.1", + "VPM-05.1" ], - "10.1": [ - "TDA-01.1" + "PM-06": [ + "GOV-04", + "GOV-05" ], - "10.2": [ - "TDA-01.1" + "PM-29": [ + "GOV-04", + "RSK-01", + "RSK-09" ], - "10.3": [ - "TDA-01.1" + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "10.4": [ - "TDA-01.1" + "PM-15": [ + "GOV-07", + "THR-01" ], - "11.1": [ - "TDA-01.1" + "PM-23": [ + "GOV-10", + "PRI-10", + "PRI-13" ], - "11.2": [ - "TDA-01.1" + "PM-24": [ + "GOV-10", + "PRI-02.2", + "PRI-02.3", + "PRI-05.2", + "PRI-10", + "PRI-13" ], - "11.3": [ - "TDA-01.1" + "PM-05": [ + "AST-01", + "AST-02" ], - "11.4": [ - "TDA-01.1" + "CM-08": [ + "AST-02", + "AST-02.3" ], - "11.5": [ - "TDA-01.1" + "CM-08(03)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" + ], + "SC-18(02)": [ + "AST-02.7", + "END-10" ], - "11.5(a)": [ - "TDA-01.1" + "SA-04(12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" ], - "11.5(b)": [ - "TDA-01.1" + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "11.5(c)": [ - "TDA-01.1" + "SA-04(01)": [ + "AST-04", + "TDA-04.1" ], - "11.6": [ - "TDA-01.1" + "SA-04(02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" ], - "11.6(a)": [ - "TDA-01.1" + "PE-22": [ + "AST-04.1", + "PES-16" ], - "11.6(b)": [ - "TDA-01.1" + "SA-05": [ + "AST-04.1", + "TDA-04" ], - "11.6(c)": [ - "TDA-01.1" + "SR-12": [ + "AST-09" ], - "11.7": [ - "TDA-01.1" + "SR-10": [ + "AST-15.1", + "TDA-11" ], - "11.8": [ - "TDA-01.1" + "CP-02": [ + "BCD-01", + "BCD-06" ], - "14.1": [ - "TDA-01.3" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "14.2": [ - "TDA-01.3" + "IR-04(03)": [ + "BCD-01", + "IRO-02.4" ], - "4.1": [ - "TDA-04" + "PM-08": [ + "BCD-01", + "CPL-01" ], - "4.1(a)": [ - "TDA-04" + "CP-02(03)": [ + "BCD-02.1", + "BCD-02.3" ], - "5.1": [ - "TDA-04" + "CP-03": [ + "BCD-03" ], - "5.1(a)": [ - "TDA-04" + "CP-04": [ + "BCD-04", + "BCD-05" ], - "5.1(b)": [ - "TDA-04" + "PE-23": [ + "BCD-08", + "BCD-09", + "PES-01", + "PES-12", + "SEA-15", + "TPM-04.4" ], - "6.1": [ - "TDA-04" + "CP-09": [ + "BCD-11" ], - "6.2": [ - "TDA-04" + "SC-28(02)": [ + "BCD-11", + "CRY-05.2" ], - "6.3": [ - "TDA-04" + "SC-28(01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" ], - "6.4": [ - "TDA-04" + "SI-13": [ + "BCD-12.2", + "SEA-07" ], - "6.5": [ - "TDA-04" + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "6.6": [ - "TDA-04" + "SC-05(02)": [ + "CAP-02", + "CAP-03" ], - "6.7": [ - "TDA-04" + "CM-03": [ + "CHG-01", + "CHG-02" ], - "6.8": [ - "TDA-04" + "SA-08(31)": [ + "CHG-02", + "CHG-02.2", + "CHG-06" ], - "6.9": [ - "TDA-04" + "CM-03(02)": [ + "CHG-02.2", + "CHG-06" ], - "6.10": [ - "TDA-04" + "CM-04": [ + "CHG-03" ], - "4.1(b)": [ - "TDA-04.1" + "CM-05": [ + "CHG-04", + "END-03.2" ], - "4.1(b)(1)": [ - "TDA-04.1" + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "4.1(b)(2)": [ - "TDA-04.1" + "CM-09": [ + "CHG-05", + "CFG-01" ], - "4.1(b)(3)": [ - "TDA-04.1" + "SC-07(29)": [ + "CLD-03", + "NET-03.8", + "NET-06.1" ], - "4.1(b)(4)": [ - "TDA-04.1" + "SA-09(05)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" ], - "4.1(c)": [ - "TDA-04.2" + "SA-09(08)": [ + "CLD-09", + "DCH-19" ], - "4.1(f)": [ - "TDA-06" + "CA-07": [ + "CPL-02" ], - "12.1(b)": [ - "TDA-06.2", - "THR-09" + "CA-07(01)": [ + "CPL-02", + "CPL-03.1" ], - "12.3": [ - "TDA-09" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "12.3(a)": [ - "TDA-09" + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "12.3(b)": [ - "TDA-09" + "RA-03": [ + "CPL-03.2", + "RSK-04" ], - "12.3(c)": [ - "TDA-09" + "CM-02": [ + "CFG-02", + "CFG-02.1" ], - "12.4": [ - "TDA-09" + "CM-06": [ + "CFG-02", + "CFG-02.7" ], - "12.4(a)": [ - "TDA-09" + "PL-10": [ + "CFG-02" ], - "12.4(b)": [ - "TDA-09" + "SA-08": [ + "CFG-02", + "SEA-01" ], - "12.4(c)": [ - "TDA-09" + "SA-15(05)": [ + "CFG-02", + "SEA-01" ], - "12.4(d)": [ - "TDA-09" + "PL-11": [ + "CFG-02.9" ], - "12.5": [ - "TDA-09" + "CM-07": [ + "CFG-03" ], - "12.5(a)": [ - "TDA-09" + "CM-07(02)": [ + "CFG-03.2", + "SEA-06" ], - "12.5(b)": [ - "TDA-09" + "SC-18(04)": [ + "CFG-03.3", + "END-10" ], - "12.5(c)": [ - "TDA-09" + "CM-10": [ + "CFG-04" ], - "12.6": [ - "TDA-09" + "CM-11": [ + "CFG-05", + "END-03" ], - "13.1": [ - "TDA-09" + "CM-11(02)": [ + "CFG-05", + "CFG-05.2", + "END-03" ], - "17.1": [ - "TDA-09" + "CM-11(03)": [ + "CFG-05.1", + "CFG-06", + "CFG-06.1", + "END-03.1" ], - "17.2": [ - "TDA-09" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "17.3": [ - "TDA-09" + "SI-04(25)": [ + "MON-01.1", + "NET-03.1" ], - "17.3(a)": [ - "TDA-09" + "SC-48": [ + "MON-01.2", + "THR-07" ], - "17.3(b)": [ - "TDA-09" + "SI-04(24)": [ + "MON-01.7", + "MON-11.3" ], - "17.3(c)": [ - "TDA-09" + "AU-02": [ + "MON-01.8", + "MON-02" ], - "18.1": [ - "TDA-09.2" + "IR-04(05)": [ + "MON-01.11", + "IRO-02.6" ], - "18.2": [ - "TDA-09.2" + "SI-04(07)": [ + "MON-01.11", + "IRO-02.1" ], - "18.3": [ - "TDA-09.2" + "SI-04(12)": [ + "MON-01.12", + "MON-05.1" ], - "18.4": [ - "TDA-09.2" + "AU-06": [ + "MON-02", + "MON-02.6" ], - "18.5": [ - "TDA-09.2" + "IR-04(04)": [ + "MON-02", + "MON-02.1" ], - "15.1": [ - "TDA-09.4" + "AU-03": [ + "MON-03" ], - "15.1(a)": [ - "TDA-09.4" + "AU-04": [ + "MON-04" ], - "15.1(b)": [ - "TDA-09.4" + "AU-05": [ + "MON-05" ], - "15.1(c)": [ - "TDA-09.4" + "AU-12": [ + "MON-06" ], - "15.1(d)": [ - "TDA-09.4" + "AU-08": [ + "MON-07", + "SEA-20" ], - "15.1(e)": [ - "TDA-09.4" + "AU-09": [ + "MON-08" ], - "15.1(f)": [ - "TDA-09.4" + "AU-11": [ + "MON-10" ], - "15.1(g)": [ - "TDA-09.4" + "SI-04(18)": [ + "MON-11.1", + "NET-17" ], - "15.1(h)": [ - "TDA-09.4" + "IR-04(13)": [ + "MON-16", + "SEA-11", + "SEA-12" ], - "15.1(i)": [ - "TDA-09.4" + "SC-08(01)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" ], - "15.2": [ - "TDA-09.4" + "SC-08(02)": [ + "CRY-01", + "CRY-01.3", + "DCH-10" ], - "15.3": [ - "TDA-09.4" + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" ], - "15.4": [ - "TDA-09.4" + "IA-07": [ + "CRY-02", + "IAC-12" ], - "15.5": [ - "TDA-09.4" + "SC-08": [ + "CRY-03", + "CRY-04" ], - "15.6": [ - "TDA-09.4" + "SC-16(01)": [ + "CRY-04", + "CRY-10" ], - "15.7": [ - "TDA-09.4" + "SC-28": [ + "CRY-05", + "END-02" ], - "15.8": [ - "TDA-09.4" + "AC-18": [ + "CRY-07", + "NET-15" ], - "15.9": [ - "TDA-09.4" + "SC-40": [ + "CRY-07", + "NET-12.1" ], - "15.10": [ - "TDA-09.4" + "SC-12": [ + "CRY-08" ], - "15.11": [ - "TDA-09.4" + "MP-02": [ + "DCH-03", + "END-01" ], - "16.1": [ - "TDA-09.5" + "MP-03": [ + "DCH-04", + "DCH-04.1" ], - "16.1(a)": [ - "TDA-09.5" + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "16.1(b)": [ - "TDA-09.5" + "MP-06(03)": [ + "DCH-09", + "DCH-09.3", + "DCH-09.4" ], - "16.1(c)": [ - "TDA-09.5" + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "16.2": [ - "TDA-09.5" + "AC-20": [ + "DCH-13" ], - "16.2(a)": [ - "TDA-09.5" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "16.2(b)": [ - "TDA-09.5" + "AC-22": [ + "DCH-15" ], - "16.2(c)": [ - "TDA-09.5" + "AC-23": [ + "DCH-16", + "PRI-05.4" ], - "16.2(d)": [ - "TDA-09.5" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "16.2(e)": [ - "TDA-09.5" + "SI-12(01)": [ + "DCH-18.1", + "PRI-05.1" ], - "16.3": [ - "TDA-09.5" + "PM-25": [ + "DCH-18.2", + "END-13.3", + "PES-06.5", + "PRI-05.1", + "PRI-05.4" ], - "16.4": [ - "TDA-09.5" + "SA-08(33)": [ + "DCH-18.2", + "END-13.3", + "PES-06.5" ], - "12.2": [ - "TDA-15" + "SI-12(02)": [ + "DCH-18.2", + "PRI-05.1" ], - "12.2(a)": [ - "TDA-15" + "SI-12(03)": [ + "DCH-21", + "PRI-05" ], - "12.2(b)": [ - "TDA-15" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "4.1(d)": [ - "TDA-20" + "SI-18(04)": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" ], - "12.1(c)": [ - "THR-10" - ] - }, - "general-ul-2900-2-2-2016": { - "10.1": [ - "CRY-01", - "TDA-01.1" + "SI-18(05)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-06.2" ], - "8.3": [ - "EMB-14", - "EMB-15", - "NET-14" + "PT-03(01)": [ + "DCH-22.2", + "PRI-11" ], - "9.2": [ - "EMB-14", - "EMB-15" + "SI-19(01)": [ + "DCH-22.3", + "DCH-23.1" ], - "8.10(b)": [ - "END-09" + "SI-19(04)": [ + "DCH-23.4", + "PRI-05.3" ], - "8.5": [ - "IAC-01" + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "8.7": [ - "IAC-01" + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "8.6": [ - "IAC-01.2" + "SI-07": [ + "END-06", + "NET-12", + "TDA-18" ], - "8.9": [ - "IAC-10" + "SC-18(01)": [ + "END-10", + "VPM-02", + "VPM-04" ], - "8.10": [ - "IAC-10.5" + "SC-18(03)": [ + "END-10", + "NET-18" ], - "8.11": [ - "IAC-10.5" + "SC-15": [ + "END-14" ], - "8.8": [ - "IAC-14" + "SC-03": [ + "END-16", + "SEA-04.1" ], - "8.2": [ - "NET-14" + "PS-02": [ + "HRS-02", + "HRS-03.2" ], - "9.6": [ - "SEA-07.3" + "PM-13": [ + "HRS-03", + "SAT-01" ], - "4.1": [ - "TDA-01.1" + "PS-09": [ + "HRS-03" ], - "5.1": [ - "TDA-01.1" + "PS-03": [ + "HRS-04" ], - "6.1": [ - "TDA-01.1" + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "7.1": [ - "TDA-01.1" + "PL-04(01)": [ + "HRS-05.2" ], - "8.1": [ - "TDA-01.1" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "8.4": [ - "TDA-01.1" + "PS-06(02)": [ + "HRS-06", + "HRS-06.1" ], - "9.1": [ - "TDA-01.1" + "PS-08": [ + "HRS-07" ], - "9.3": [ - "TDA-01.1" + "PS-05": [ + "HRS-08" ], - "9.4": [ - "TDA-01.1" + "PS-04": [ + "HRS-09" ], - "9.5": [ - "TDA-01.1" + "AC-02(13)": [ + "HRS-09.2", + "IAC-15.6" ], - "11.1": [ - "TDA-01.1" + "PS-07": [ + "HRS-10" ], - "11.2": [ - "TDA-01.1" + "AC-03(02)": [ + "HRS-12.1", + "IAC-20.5" ], - "11.4(a)": [ - "TDA-01.1" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "11.4(b)": [ - "TDA-01.1" + "IA-04(04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "11.4(c)": [ - "TDA-01.1" + "IA-02": [ + "IAC-02" ], - "12.1": [ - "TDA-01.1" + "IA-02(08)": [ + "IAC-02.2" ], - "13.1": [ - "TDA-01.1", - "TDA-09" + "IA-02(12)": [ + "IAC-02.3" ], - "14.1": [ - "TDA-01.1", - "TDA-01.3" + "IA-08": [ + "IAC-03" ], - "15.1.1": [ - "TDA-01.1" + "IA-08(01)": [ + "IAC-03.1" ], - "15.1.2": [ - "TDA-01.1" + "IA-08(02)": [ + "IAC-03.2" ], - "16.1": [ - "TDA-01.1", - "TDA-09.5", - "VPM-07" + "IA-08(04)": [ + "IAC-03.3" ], - "17.1": [ - "TDA-01.1", - "TDA-09" + "IA-03(04)": [ + "IAC-04", + "IAC-04.1" ], - "18.1": [ - "TDA-01.1", - "TDA-09.2" + "IA-02(01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "19.1": [ - "TDA-01.1", - "TDA-09.2" + "IA-02(02)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "11.3": [ - "TDA-06" + "IA-12(04)": [ + "IAC-07", + "IAC-10.3", + "IAC-28.4" ], - "11.3(a)": [ - "TDA-06" + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "11.3(b)": [ - "TDA-06" + "IA-05(08)": [ + "IAC-09.5", + "IAC-10.9" ], - "11.3(c)": [ - "TDA-06" + "IA-05": [ + "IAC-10", + "IAC-10.8" ], - "11.3(d)": [ - "TDA-06" + "IA-05(01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "11.5": [ - "TDA-06" + "IA-05(02)": [ + "IAC-10.2" ], - "11.6": [ - "TDA-06" + "IA-05(06)": [ + "IAC-10.5", + "IAC-18" ], - "11.7": [ - "TDA-06" + "IA-06": [ + "IAC-11" ], - "11.8": [ - "TDA-06" + "IA-11": [ + "IAC-14" ], - "15.2.1": [ - "TDA-09.4" + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "15.2.2": [ - "TDA-09.4" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "15.2.3": [ - "TDA-09.4" + "AC-07": [ + "IAC-22" ], - "15.2.4": [ - "TDA-09.4" + "AC-14": [ + "IAC-26" ], - "15.2.5": [ - "TDA-09.4" + "IR-04": [ + "IRO-02" ], - "15.2.6": [ - "TDA-09.4" + "IR-08": [ + "IRO-04" ], - "15.3.1": [ - "TDA-09.4" + "IR-02": [ + "IRO-05" ], - "15.3.2": [ - "TDA-09.4" + "IR-04(12)": [ + "IRO-08", + "IRO-13" ], - "15.3.3": [ - "TDA-09.4" + "IR-05": [ + "IRO-09" ], - "15.3.4": [ - "TDA-09.4" + "IR-06(02)": [ + "IRO-10.3", + "IRO-13" ], - "11.4": [ - "VPM-05.8" - ] - }, - "general-un-155-2021": { - "7.2.2.2(a)": [ - "GOV-01" + "IR-04(10)": [ + "IRO-10.4", + "TPM-11" ], - "7.1.1": [ - "CPL-01" + "IR-07": [ + "IRO-11" ], - "7.2.2.1": [ - "CPL-01.4" + "IR-09": [ + "IRO-12", + "IRO-12.1" ], - "7.2.2.2": [ - "CPL-01.4" + "CA-02(01)": [ + "IAO-02.1" ], - "7.2.2.2(g)": [ - "MON-01", - "MON-16", - "THR-01", - "THR-03", - "THR-10", - "VPM-01", - "VPM-04" + "SA-11(05)": [ + "IAO-02.2", + "IAO-04", + "TDA-09", + "TDA-09.5", + "VPM-07" ], - "7.2.2.2(h)": [ - "MON-01", - "MON-11.3", - "IRO-03", - "THR-03" + "CA-05": [ + "IAO-05" ], - "7.2.2.5": [ - "IAO-01", - "PRM-04", - "PRM-05", - "PRM-07", - "RSK-09", - "RSK-09.1", - "TDA-01.1", - "TDA-02", - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-05.2", - "TPM-05.4", - "TPM-05.6", - "TPM-05.7", - "TPM-06", - "TPM-08", - "TPM-09" + "PM-04": [ + "IAO-05", + "VPM-02" ], - "7.2.2.2(e)": [ - "IAO-01.1", - "IAO-02" + "CA-06": [ + "IAO-07" ], - "7.2.2.2(d)": [ - "IAO-05", - "RSK-06" + "MA-02": [ + "MNT-02" ], - "7.2.2.1(a)": [ - "PRM-07" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "7.2.2.1(b)": [ - "PRM-07" + "MA-05": [ + "MNT-06" ], - "7.2.2.1(c)": [ - "PRM-07" + "SR-11(02)": [ + "MNT-07" ], - "7.2.2.2(b)": [ - "RSK-01", - "RSK-01.1", - "RSK-03", - "RSK-03.1", - "RSK-04", - "THR-09", - "THR-10" + "AC-19": [ + "MDM-02" ], - "7.2.2.2(c)": [ - "RSK-02", - "RSK-04.2", - "RSK-06" + "SC-07": [ + "NET-03" ], - "7.2.2.2(f)": [ - "RSK-04.2", - "RSK-07" + "SC-07(09)": [ + "NET-03", + "NET-03.2" ], - "7.2.2.3": [ - "RSK-06", - "RSK-06.1", - "RSK-06.2", - "RSK-06.3", - "RSK-06.4", - "TDA-09", - "TDA-09.1", - "TDA-15" + "SC-07(11)": [ + "NET-03", + "NET-04.1" ], - "3.1": [ - "TDA-01.1" + "SC-07(10)": [ + "NET-03.5", + "NET-17" ], - "3.2": [ - "TDA-01.1" + "CA-03": [ + "NET-05" ], - "3.2.1": [ - "TDA-01.1" + "CA-09": [ + "NET-05.2" ], - "3.2.2": [ - "TDA-01.1" + "SC-20": [ + "NET-10" ], - "3.2.3": [ - "TDA-01.1" + "SC-22": [ + "NET-10.1" ], - "3.3": [ - "TDA-01.1" + "SC-21": [ + "NET-10.2" ], - "3.3(a)": [ - "TDA-01.1" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "3.3(b)": [ - "TDA-01.1" + "SI-10": [ + "NET-12", + "TDA-18" ], - "4.1": [ - "TDA-01.1" + "AC-17": [ + "NET-14" ], - "4.1.1": [ - "TDA-01.1" + "SC-07(08)": [ + "NET-18", + "NET-18.1" ], - "4.1.2": [ - "TDA-01.1" + "PE-02": [ + "PES-02" ], - "4.2": [ - "TDA-01.1" + "PE-03": [ + "PES-03" ], - "4.3": [ - "TDA-01.1" + "SC-07(14)": [ + "PES-03.2", + "PES-12", + "PES-12.1" ], - "4.4": [ - "TDA-01.1" + "PE-08": [ + "PES-03.3" ], - "5.4": [ - "TDA-01.1" + "PE-06": [ + "PES-05" ], - "7.3.1": [ - "TDA-01.1" + "PE-12": [ + "PES-07.4" ], - "7.3.2": [ - "TDA-01.1" + "PE-15": [ + "PES-07.5" ], - "7.3.3": [ - "TDA-01.1" + "PE-13": [ + "PES-08" ], - "7.3.4": [ - "TDA-01.1" + "PE-13(02)": [ + "PES-08.2", + "PES-08.3" ], - "7.3.5": [ - "TDA-01.1" + "PE-14": [ + "PES-09" ], - "7.3.6": [ - "TDA-01.1" + "PE-16": [ + "PES-10" + ], + "PT-03": [ + "PRI-02.1", + "PRI-05.1" ], - "7.3.7": [ - "TDA-01.1" + "PT-03(02)": [ + "PRI-02.2", + "PRI-10.1" ], - "7.3.7(a)": [ - "TDA-01.1" + "PT-02": [ + "PRI-04", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" ], - "7.3.7(b)": [ - "TDA-01.1" + "PT-07": [ + "PRI-05.4", + "PRI-05.7" ], - "7.3.7(c)": [ - "TDA-01.1" + "PM-05(01)": [ + "PRI-05.5", + "PRI-05.6" ], - "7.3.8": [ - "TDA-01.1" + "PM-26": [ + "PRI-06.3", + "PRI-06.4" ], - "7.4.1": [ - "TDA-01.1" + "SA-02": [ + "PRM-03" ], - "7.4.2": [ - "TDA-01.1" + "RA-09": [ + "PRM-05", + "TDA-06.1", + "TPM-02" ], - "8.1": [ - "TDA-01.1" + "SA-03": [ + "PRM-07", + "SEA-07.1" ], - "8.1.1": [ - "TDA-01.1" + "SA-03(01)": [ + "PRM-07", + "SEA-07.1", + "TDA-07" ], - "8.1.2": [ - "TDA-01.1" + "SA-08(30)": [ + "PRM-07", + "SEA-07.1" ], - "8.1.3": [ - "TDA-01.1" + "RA-02": [ + "RSK-02" ], - "9.1": [ - "TDA-01.1" + "RA-07": [ + "RSK-06.1" ], - "9.1.1": [ - "TDA-01.1" + "SR-02": [ + "RSK-09", + "TPM-03" ], - "9.1.2": [ - "TDA-01.1" + "SR-07": [ + "RSK-09", + "OPS-01" ], - "11.1": [ - "TDA-01.1" + "RA-03(01)": [ + "RSK-09.1" ], - "7.2.2.4": [ - "TDA-09.1" + "CA-07(04)": [ + "RSK-11" ], - "7.2.2.4(a)": [ - "TDA-09.1" + "PL-08": [ + "SEA-02" ], - "7.2.2.4(b)": [ - "TDA-09.1" - ] - }, - "general-un-ece-wp-29-2020": { - "7.2.2.2(a)": [ - "GOV-01" + "SC-39": [ + "SEA-04" ], - "7.1.1": [ - "CPL-01" + "SA-03(03)": [ + "SEA-07.1", + "SEA-08.1" ], - "7.2.2.1": [ - "CPL-01.4" + "AC-08": [ + "SEA-18" ], - "7.2.2.2": [ - "CPL-01.4" + "SC-38": [ + "OPS-01", + "OPS-04" ], - "7.2.2.2(g)": [ - "MON-01", - "MON-16", - "THR-01", - "THR-03", - "THR-10", - "VPM-01", - "VPM-04" + "AT-02": [ + "SAT-02" ], - "7.2.2.2(h)": [ - "MON-01", - "MON-11.3", - "IRO-03", - "THR-03" + "AT-03": [ + "SAT-03" ], - "7.2.2.2(e)": [ - "IAO-01", - "IAO-01.1", - "IAO-02" + "AT-04": [ + "SAT-04" ], - "7.2.2.5": [ - "IAO-01", - "PRM-04", - "PRM-05", - "PRM-07", - "RSK-09", - "RSK-09.1", - "TDA-01.1", + "SA-04": [ + "TDA-01", "TDA-02", "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-05.2", - "TPM-05.4", - "TPM-05.6", - "TPM-05.7", - "TPM-06", - "TPM-08", - "TPM-09" - ], - "7.2.2.2(d)": [ - "IAO-05", - "RSK-06" - ], - "7.2.2.1(a)": [ - "PRM-07" + "TPM-10" ], - "7.2.2.1(b)": [ - "PRM-07" + "SA-23": [ + "TDA-01", + "TDA-01.1", + "TDA-12" ], - "7.2.2.1(c)": [ - "PRM-07" + "SA-04(10)": [ + "TDA-02.2" ], - "7.2.2.2(b)": [ - "RSK-01", - "RSK-01.1", - "RSK-03", - "RSK-03.1", - "RSK-04", - "THR-09", - "THR-10" + "SA-04(03)": [ + "TDA-02.3", + "TDA-06" ], - "7.2.2.2(c)": [ - "RSK-02", - "RSK-04.2", - "RSK-06" + "SR-03(01)": [ + "TDA-02.3", + "TDA-03.1", + "TPM-03.1" ], - "7.2.2.2(f)": [ - "RSK-04.2", - "RSK-07" + "PM-30(01)": [ + "TDA-06.1", + "TDA-12", + "TPM-02" ], - "7.2.2.3": [ - "RSK-06", - "RSK-06.1", - "RSK-06.2", - "RSK-06.3", - "RSK-06.4", - "TDA-09", - "TDA-09.1", + "SA-11(02)": [ + "TDA-06.2", "TDA-15" ], - "3.1": [ - "TDA-01.1" + "SA-11(06)": [ + "TDA-09", + "VPM-01.1" ], - "3.2": [ - "TDA-01.1" + "SA-11(07)": [ + "TDA-09", + "VPM-01.1" ], - "3.2.1": [ - "TDA-01.1" + "SR-11": [ + "TDA-11" ], - "3.2.2": [ - "TDA-01.1" + "SR-11(01)": [ + "TDA-11.1" ], - "3.2.3": [ - "TDA-01.1" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "3.3": [ - "TDA-01.1" + "SR-02(01)": [ + "TPM-03" ], - "3.3(a)": [ - "TDA-01.1" + "SR-05": [ + "TPM-03.1" ], - "3.3(b)": [ - "TDA-01.1" + "SR-03": [ + "TPM-03.3" ], - "4.1": [ - "TDA-01.1" + "SA-09": [ + "TPM-04" ], - "4.1.1": [ - "TDA-01.1" + "SR-03(03)": [ + "TPM-05", + "TPM-05.2" ], - "4.1.2": [ - "TDA-01.1" + "SR-08": [ + "TPM-05.1" ], - "4.2": [ - "TDA-01.1" + "AT-02(02)": [ + "THR-05" ], - "4.3": [ - "TDA-01.1" + "RA-05(11)": [ + "THR-06" ], - "4.4": [ - "TDA-01.1" + "SI-02(04)": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" ], - "5.4": [ - "TDA-01.1" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "7.3.1": [ - "TDA-01.1" + "RA-05(02)": [ + "VPM-06.1" ], - "7.3.2": [ - "TDA-01.1" + "CA-08": [ + "VPM-07" + ] + }, + "usa-federal-law-33-cfr-part-101-subpart-f": { + "101.620(b)(1)": [ + "GOV-01" ], - "7.3.3": [ - "TDA-01.1" + "101.625(d)(14)": [ + "GOV-01.2", + "GOV-02.1", + "THR-03.1" ], - "7.3.4": [ - "TDA-01.1" + "101.645(a)": [ + "GOV-01.2" ], - "7.3.5": [ - "TDA-01.1" + "101.625(d)(5)": [ + "GOV-02", + "GOV-03", + "GOV-15", + "IAO-03" ], - "7.3.6": [ - "TDA-01.1" + "101.620(b)(2)": [ + "GOV-04", + "GOV-04.1", + "HRS-03" ], - "7.3.7": [ - "TDA-01.1" + "101.620(b)(3)": [ + "GOV-04", + "IRO-14" ], - "7.3.7(a)": [ - "TDA-01.1" + "101.625(c)": [ + "GOV-04" ], - "7.3.7(b)": [ - "TDA-01.1" + "101.625(d)(2)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3" ], - "7.3.7(c)": [ - "TDA-01.1" + "101.650(c)": [ + "GOV-15", + "IAO-03" ], - "7.3.8": [ - "TDA-01.1" + "101.625(d)(12)": [ + "GOV-17" ], - "7.4.1": [ - "TDA-01.1" + "101.625(d)(13)": [ + "GOV-17" ], - "8.1": [ - "TDA-01.1" + "101.630(d)": [ + "GOV-17" ], - "8.1.1": [ - "TDA-01.1" + "101.630(e)(2)": [ + "GOV-17" ], - "8.1.2": [ - "TDA-01.1" + "101.630(e)(2)(ii)": [ + "GOV-17" ], - "8.1.3": [ - "TDA-01.1" + "101.630(e)(3)": [ + "GOV-17" ], - "9.1": [ - "TDA-01.1" + "101.630(e)(4)": [ + "GOV-17" ], - "9.1.1": [ - "TDA-01.1" + "101.630(f)(3)": [ + "GOV-17" ], - "9.1.2": [ - "TDA-01.1" + "101.630(f)(5)": [ + "GOV-17" ], - "11.1": [ - "TDA-01.1" + "101.650(i)(2)": [ + "AST-01", + "AST-01.5", + "AST-02.2" ], - "7.2.2.4": [ - "TDA-09", - "TDA-09.1" + "101.650(b)(1)": [ + "AST-01.4" ], - "7.2.2.4(a)": [ - "TDA-09.1" + "101.650(b)(3)": [ + "AST-02" ], - "7.2.2.4(b)": [ - "TDA-09.1" - ] - }, - "usa-federal-dow-cert-rmm-1-2": { - "ADM:GG1": [ - "GOV-01" + "101.650(b)(4)": [ + "AST-04" ], - "ADM:GG2.GP1": [ - "GOV-01" + "101.650(g)(4)": [ + "BCD-11" ], - "ADM:GG3": [ - "GOV-01" + "101.650(f)(1)": [ + "CAP-01" ], - "AM:GG1": [ - "GOV-01" + "101.620(a)": [ + "CPL-01" ], - "AM:GG2.GP1": [ - "GOV-01" + "101.620(b)(4)": [ + "CPL-01" ], - "AM:GG3": [ - "GOV-01" + "101.620(b)(5)": [ + "CPL-01" ], - "COMM:GG1": [ - "GOV-01" + "101.650(b)": [ + "CPL-01" ], - "COMM:GG2.GP1": [ - "GOV-01" + "101.650(e)": [ + "CPL-01" ], - "COMM:GG3": [ - "GOV-01" + "101.650(e)(3)": [ + "CPL-01" ], - "COMP:GG2.GP1": [ - "GOV-01" + "101.650(f)": [ + "CPL-01" ], - "COMP:GG3": [ - "GOV-01" + "101.650(g)": [ + "CPL-01" ], - "CTRL:GG1": [ - "GOV-01" + "101.650(h)": [ + "CPL-01" ], - "CTRL:GG1.GP1": [ - "GOV-01", - "CPL-13", - "PRM-06", - "OPS-01.1" + "101.650(i)": [ + "CPL-01" ], - "CTRL:GG2": [ - "GOV-01" + "101.605(a)": [ + "CPL-01.2" ], - "CTRL:GG2.GP1": [ - "GOV-01" + "101.605(b)": [ + "CPL-01.2" ], - "CTRL:GG2.GP2": [ - "GOV-01" + "101.625(d)": [ + "CPL-01.2" ], - "CTRL:GG3": [ - "GOV-01" + "101.630(d)(2)": [ + "CPL-01.2" ], - "EC:GG1": [ - "GOV-01" + "101.625(d)(6)": [ + "CPL-01.3", + "CPL-05.2" ], - "EC:GG2.GP1": [ - "GOV-01" + "101.660": [ + "CPL-01.3" ], - "EC:GG3": [ - "GOV-01" + "101.650(g)(3)": [ + "CPL-01.4" ], - "EF:GG1": [ - "GOV-01" + "101.630(f)(4)": [ + "CPL-01.6" ], - "EF:GG2.GP1": [ - "GOV-01" + "101.630(f)(4)(i)": [ + "CPL-01.6" ], - "EF:GG3": [ - "GOV-01" + "101.625(d)(7)": [ + "CPL-02", + "CPL-02.3" ], - "EXD:GG1": [ - "GOV-01" + "101.625(d)(3)": [ + "CPL-02.2" ], - "EXD:GG2.GP1": [ - "GOV-01" + "101.630(f)(1)": [ + "CPL-03" ], - "EXD:GG3": [ - "GOV-01" + "101.630(f)(2)": [ + "CPL-03" ], - "FRM:GG1": [ - "GOV-01" + "101.630(f)(4)(ii)": [ + "CPL-03.1" ], - "FRM:GG2.GP1": [ - "GOV-01" + "101.630(f)(4)(iii)": [ + "CPL-03.1" ], - "FRM:GG3": [ - "GOV-01" + "101.640": [ + "CPL-13", + "DCH-18" ], - "HRM:GG1": [ - "GOV-01" + "101.650(b)(2)": [ + "CFG-02", + "CFG-02.5" ], - "HRM:GG2.GP1": [ - "GOV-01" + "101.650(c)(2)": [ + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-05" ], - "HRM:GG3": [ - "GOV-01" + "101.650(c)(1)": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-08", + "MON-08.2", + "MON-10" ], - "ID:GG1": [ - "GOV-01" + "101.650(f)(3)": [ + "MON-01", + "MON-01.3" ], - "ID:GG2.GP1": [ - "GOV-01" + "101.650(h)(2)": [ + "MON-01.3", + "MON-01.4" ], - "ID:GG3": [ - "GOV-01" + "101.630(b)": [ + "DCH-01", + "DCH-01.4" ], - "IMC:GG1": [ - "GOV-01" + "101.625(d)(11)": [ + "DCH-18" ], - "IMC:GG2.GP1": [ - "GOV-01" + "101.650(e)(3)(v)": [ + "EMB-03", + "NET-06.5" ], - "IMC:GG3": [ - "GOV-01" + "101.650(a)(7)": [ + "HRS-01.1", + "IAC-07" ], - "KIM:GG1": [ - "GOV-01" + "101.625(a)": [ + "HRS-02", + "HRS-03" ], - "KIM:GG2.GP1": [ - "GOV-01" + "101.625(d)(8)": [ + "HRS-03.1", + "HRS-04.2", + "SAT-01", + "SAT-01.1", + "SAT-03.6", + "THR-03.1" ], - "KIM:GG3": [ - "GOV-01" + "101.625(e)": [ + "HRS-03.2" ], - "MA:GG1": [ - "GOV-01" + "101.625(e)(1)": [ + "HRS-03.2" ], - "MA:GG2.GP1": [ - "GOV-01" + "101.625(e)(2)": [ + "HRS-03.2" ], - "MA:GG3": [ - "GOV-01" + "101.625(e)(3)": [ + "HRS-03.2" ], - "MON:GG1": [ - "GOV-01" + "101.625(e)(4)": [ + "HRS-03.2" ], - "MON:GG2.GP1": [ - "GOV-01" + "101.625(e)(5)": [ + "HRS-03.2" ], - "MON:GG3": [ - "GOV-01" + "101.625(e)(6)": [ + "HRS-03.2" ], - "OPD:GG1": [ - "GOV-01" + "101.625(e)(7)": [ + "HRS-03.2" ], - "OPD:GG2.GP1": [ - "GOV-01" + "101.625(e)(8)": [ + "HRS-03.2" ], - "OPD:GG3": [ - "GOV-01" + "101.625(e)(9)": [ + "HRS-03.2" ], - "OPF:GG1": [ - "GOV-01" + "101.625(e)(10)": [ + "HRS-03.2" ], - "OPF:GG2.GP1": [ - "GOV-01" + "101.625(e)(11)": [ + "HRS-03.2" ], - "OPF:GG3": [ - "GOV-01" + "101.625(e)(12)": [ + "HRS-03.2" ], - "OTA:GG1": [ - "GOV-01" + "101.650(a)(6)": [ + "HRS-11", + "IAC-15.10", + "IAC-16.2" ], - "OTA:GG2.GP1": [ - "GOV-01" + "101.650(a)": [ + "IAC-01" ], - "OTA:GG3": [ - "GOV-01" + "101.650(a)(4)": [ + "IAC-06" ], - "PM:GG1": [ - "GOV-01" + "101.650(a)(3)": [ + "IAC-10.1" ], - "PM:GG2.GP1": [ - "GOV-01" + "101.650(a)(2)": [ + "IAC-10.8" ], - "PM:GG3": [ - "GOV-01" + "101.650(a)(5)": [ + "IAC-21" ], - "RISK:GG1": [ - "GOV-01" + "101.650(a)(1)": [ + "IAC-22" ], - "RISK:GG2.GP1": [ - "GOV-01" + "101.625(d)(4)": [ + "IRO-02" ], - "RISK:GG3": [ - "GOV-01" + "101.620(b)(6)": [ + "IRO-04" ], - "RRD:GG1": [ - "GOV-01" + "101.650(g)(2)": [ + "IRO-04" ], - "RRD:GG2.GP1": [ - "GOV-01" + "101.635(a)(1)": [ + "IRO-06", + "IRO-06.1" ], - "RRD:GG3": [ - "GOV-01" + "101.635(b)(1)": [ + "IRO-06" ], - "RRM:GG1": [ - "GOV-01" + "101.635(b)(2)": [ + "IRO-06" ], - "RRM:GG2.GP1": [ - "GOV-01" + "101.635(b)(3)": [ + "IRO-06" ], - "RRM:GG3": [ - "GOV-01" + "101.635(c)(1)": [ + "IRO-06" ], - "RTSE:GG1": [ - "GOV-01" + "101.635(c)(2)": [ + "IRO-06" ], - "RTSE:GG2.GP1": [ - "GOV-01" + "101.635(c)(2)(i)": [ + "IRO-06" ], - "RTSE:GG3": [ - "GOV-01" + "101.635(c)(2)(ii)": [ + "IRO-06" ], - "SC:GG1": [ - "GOV-01" + "101.635(c)(2)(iii)": [ + "IRO-06" ], - "SC:GG2.GP1": [ - "GOV-01" + "101.635(c)(2)(iv)": [ + "IRO-06" ], - "SC:GG3": [ - "GOV-01" + "101.635(c)(3)": [ + "IRO-06" ], - "TM:GG1": [ - "GOV-01" + "101.635(c)(4)": [ + "IRO-06" ], - "TM:GG2": [ - "GOV-01" + "101.635(c)(5)": [ + "IRO-06" ], - "TM:GG2.GP1": [ - "GOV-01" + "101.625(d)(10)": [ + "IRO-10", + "IRO-10.2", + "IRO-10.5" ], - "TM:GG3": [ - "GOV-01" + "101.620(b)(7)": [ + "IRO-10.2" ], - "VAR:GG1": [ - "GOV-01" + "101.650(g)(1)": [ + "IRO-10.2" ], - "VAR:GG2.GP1": [ - "GOV-01" + "101.635(c)(6)": [ + "IRO-13" ], - "VAR:GG3": [ - "GOV-01" + "101.650(e)(1)": [ + "IAO-02" ], - "GG1": [ - "GOV-01" + "101.650(e)(1)(i)": [ + "IAO-02" ], - "GG1.GP1": [ - "GOV-01", - "CPL-13", - "PRM-06", - "OPS-01.1" + "101.650(e)(1)(ii)": [ + "IAO-02" ], - "GG2": [ - "GOV-01" + "101.650(e)(1)(iii)": [ + "IAO-02.4" ], - "GG2.GP1": [ - "GOV-01" + "101.630(a)": [ + "IAO-03" ], - "GG2.GP2": [ - "GOV-01" + "101.630(c)": [ + "IAO-03" ], - "GG3": [ - "GOV-01" + "101.630(c)(1)": [ + "IAO-03" ], - "GG3.GP1": [ - "GOV-01" + "101.630(c)(2)": [ + "IAO-03" ], - "ADM:GG2.GP10": [ - "GOV-01.1" + "101.630(c)(3)": [ + "IAO-03" ], - "AM:GG2.GP10": [ - "GOV-01.1" + "101.630(c)(4)": [ + "IAO-03" ], - "COMM:GG2.GP10": [ - "GOV-01.1" + "101.630(c)(5)": [ + "IAO-03" ], - "COMP:GG2.GP10": [ - "GOV-01.1" + "101.630(c)(6)": [ + "IAO-03" ], - "CTRL:GG2.GP10": [ - "GOV-01.1" + "101.630(c)(7)": [ + "IAO-03" ], - "EC:GG2.GP10": [ - "GOV-01.1" + "101.630(c)(8)": [ + "IAO-03" ], - "EF:SG3": [ - "GOV-01.1" + "101.630(c)(9)": [ + "IAO-03" ], - "EF:SG4": [ - "GOV-01.1" + "101.630(c)(10)": [ + "IAO-03" ], - "EF:SG4.SP1": [ - "GOV-01.1" + "101.630(c)(11)": [ + "IAO-03" ], - "EF:SG4.SP2": [ - "GOV-01.1" + "101.630(c)(12)": [ + "IAO-03" ], - "EF:GG1.GP1": [ - "GOV-01.1", - "CPL-13", - "PRM-06", - "OPS-01.1" + "101.630(c)(13)": [ + "IAO-03" ], - "EF:GG2": [ - "GOV-01.1" + "101.630(c)(14)": [ + "IAO-03" ], - "EF:GG2.GP2": [ - "GOV-01.1" + "101.650(e)(1)(v)": [ + "IAO-03" ], - "EF:GG2.GP10": [ - "GOV-01.1" + "101.650(e)(1)(iv)": [ + "IAO-05" ], - "EXD:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(3)": [ + "MNT-06.1", + "MNT-06.2", + "PES-06.3" ], - "FRM:GG2.GP10": [ - "GOV-01.1" + "101.650(h)(1)": [ + "NET-06" ], - "HRM:GG2.GP10": [ - "GOV-01.1" + "101.650(e)(3)(iv)": [ + "NET-06.5", + "SEA-03" ], - "ID:GG2.GP10": [ - "GOV-01.1" + "101.650(i)(1)": [ + "PES-02", + "PES-02.1", + "PES-03" ], - "IMC:GG2.GP10": [ - "GOV-01.1" + "101.625(d)(1)": [ + "RSK-04" ], - "KIM:GG2.GP10": [ - "GOV-01.1" + "101.615": [ + "SEA-02.1" ], - "MA:GG2.GP10": [ - "GOV-01.1" + "101.650(d)": [ + "SAT-01" ], - "MON:GG2.GP10": [ - "GOV-01.1" + "101.625(d)(9)": [ + "SAT-02", + "SAT-03" ], - "OPD:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(1)": [ + "SAT-02" ], - "OPF:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(1)(i)": [ + "SAT-02" ], - "OTA:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(1)(ii)": [ + "SAT-02" ], - "PM:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(1)(iii)": [ + "SAT-02" ], - "RISK:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(1)(iv)": [ + "SAT-02" ], - "RRD:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(1)(v)": [ + "SAT-03" ], - "RRM:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(2)": [ + "SAT-03" ], - "RTSE:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(2)(i)": [ + "SAT-03" ], - "SC:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(2)(ii)": [ + "SAT-03" ], - "TM:GG2.GP10": [ - "GOV-01.1" + "101.650(d)(4)": [ + "SAT-03", + "SAT-04" ], - "VAR:GG2.GP10": [ - "GOV-01.1" + "101.650(f)(2)": [ + "TPM-05" ], - "GG2.GP10": [ - "GOV-01.1" + "101.650(e)(3)(ii)": [ + "THR-03", + "VPM-05.4" ], - "EF:SG3.SP1": [ - "GOV-01.3" + "101.650(e)(3)(iii)": [ + "THR-03.1" ], - "EF:SG3.SP3": [ - "GOV-01.3" + "101.625(d)(15)": [ + "VPM-01.1", + "VPM-02", + "VPM-03", + "VPM-05" ], - "EF:SG4.SP3": [ - "GOV-01.3" + "101.650(e)(3)(i)": [ + "VPM-05" ], - "ADM:SG1.SP3": [ - "GOV-04.1", - "AST-03", - "AST-03.1" + "101.650(e)(3)(vi)": [ + "VPM-06" ], - "MA:SG1": [ - "GOV-05" + "101.650(e)(2)": [ + "VPM-07" + ] + }, + "usa-federal-law-ferpa-2010": { + "1232h(c)(1)(C)(i)": [ + "CPL-01" ], - "MA:SG1.SP1": [ - "GOV-05" + "1232g(d)": [ + "DCH-03.1" ], - "MA:SG1.SP2": [ - "GOV-05" + "1232h(c)(1)(B)": [ + "DCH-03.1" ], - "MA:SG1.SP3": [ - "GOV-05" + "1232h(c)(1)(B)(i)": [ + "DCH-03.1" ], - "MA:SG1.SP4": [ - "GOV-05" + "1232h(c)(1)(B)(ii)": [ + "DCH-03.1" ], - "MA:SG2": [ - "GOV-05" + "1232h(c)(1)(B)(iii)": [ + "DCH-03.1" ], - "MA:SG2.SP1": [ - "GOV-05" + "1232h(c)(1)(B)(iv)": [ + "DCH-03.1" ], - "MA:SG2.SP2": [ - "GOV-05" + "1232h(c)(1)(B)(v)": [ + "DCH-03.1" ], - "MA:SG2.SP3": [ - "GOV-05" + "1232h(c)(1)(B)(vi)": [ + "DCH-03.1" ], - "MA:SG2.SP4": [ - "GOV-05" + "1232h(c)(1)(B)(vii)": [ + "DCH-03.1" ], - "MA:GG1.GP1": [ - "GOV-05", - "CPL-13", - "PRM-06", - "OPS-01.1" + "1232h(c)(1)(B)(viii)": [ + "DCH-03.1" ], - "MA:GG2": [ - "GOV-05" + "1232h(a)": [ + "PRI-01.11" ], - "MA:GG2.GP2": [ - "GOV-05" + "1232h(c)(1)(C)(ii)": [ + "PRI-01.11" ], - "CTRL:SG1": [ - "GOV-09" + "1232h(c)(1)(D)": [ + "PRI-01.11" ], - "CTRL:SG1.SP1": [ - "GOV-09" + "1232h(c)(1)(E)": [ + "PRI-01.11" ], - "EF:SG3.SP2": [ - "GOV-14" + "1232h(c)(1)(F)(i)": [ + "PRI-01.11" ], - "CTRL:SG2.SP1": [ - "GOV-15.1" + "1232h(c)(1)(F)(ii)": [ + "PRI-01.11" ], - "EC:SG2": [ - "GOV-15.1" + "1232h(b)": [ + "PRI-03" ], - "EC:SG2.SP2": [ - "GOV-15.1" + "1232h(b)(1)": [ + "PRI-03" ], - "KIM:SG2": [ - "GOV-15.1" + "1232h(b)(2)": [ + "PRI-03" ], - "KIM:SG2.SP2": [ - "GOV-15.1" + "1232h(b)(3)": [ + "PRI-03" ], - "TM:SG2": [ - "GOV-15.1" + "1232h(b)(4)": [ + "PRI-03" ], - "TM:SG2.SP2": [ - "GOV-15.1" + "1232h(b)(5)": [ + "PRI-03" ], - "CTRL:SG2": [ - "GOV-15.2" + "1232h(b)(6)": [ + "PRI-03" ], - "CTRL:SG3": [ - "GOV-15.3" + "1232h(b)(7)": [ + "PRI-03" ], - "CTRL:SG3.SP1": [ - "GOV-15.3" + "1232h(b)(8)": [ + "PRI-03" ], - "CTRL:SG4": [ - "GOV-15.3" + "1232h(c)(1)(A)(ii)": [ + "PRI-06" + ] + }, + "usa-federal-sro-finra": { + "248.30(a)(2)(ii)": [ + "GOV-01" ], - "CTRL:SG4.SP1": [ - "GOV-15.3" + "248.201(e)": [ + "GOV-01" ], - "ADM:GG2.GP9": [ - "GOV-19.2" + "248.201(e)(1)": [ + "GOV-01.1" ], - "AM:GG2.GP9": [ - "GOV-19.2" + "248.201(e)(2)": [ + "GOV-01.1" ], - "COMM:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(1)": [ + "GOV-02" ], - "COMP:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(2)": [ + "GOV-02" ], - "CTRL:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(2)(iii)": [ + "CFG-08", + "DCH-01", + "IAC-20" ], - "EC:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(2)(i)": [ + "DCH-01" ], - "EF:GG2.GP9": [ - "GOV-19.2" + "248.30(b)(1)": [ + "DCH-21" ], - "EXD:GG2.GP9": [ - "GOV-19.2" + "248.30(b)(2)": [ + "DCH-21" ], - "FRM:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(3)": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "HRM:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(3)(i)": [ + "IRO-02", + "IRO-02.4" ], - "ID:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(3)(ii)": [ + "IRO-02" ], - "IMC:GG2.GP9": [ - "GOV-19.2" + "248.201(d)(1)": [ + "IRO-02.2" ], - "KIM:GG2.GP9": [ - "GOV-19.2" + "248.201(d)(2)": [ + "IRO-02.2" ], - "MA:GG2.GP9": [ - "GOV-19.2" + "248.201(d)(2)(i)": [ + "IRO-02.2" ], - "MON:GG2.GP9": [ - "GOV-19.2" + "248.201(d)(2)(ii)": [ + "IRO-02.2" ], - "OPD:GG2.GP9": [ - "GOV-19.2" + "248.201(d)(2)(iii)": [ + "IRO-02.2" ], - "OPF:GG2.GP9": [ - "GOV-19.2" + "248.201(d)(2)(iv)": [ + "IRO-02.2" ], - "OTA:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(3)(iii)": [ + "IRO-10" ], - "PM:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(i)": [ + "IRO-10", + "IRO-16" ], - "RISK:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(ii)": [ + "IRO-10" ], - "RRD:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(iii)": [ + "IRO-10" ], - "RRM:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(iv)": [ + "IRO-10" ], - "RTSE:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(iv)(A)": [ + "IRO-10" ], - "SC:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(iv)(B)": [ + "IRO-10" ], - "TM:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(iv)(C)": [ + "IRO-10" ], - "VAR:GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(iv)(D)": [ + "IRO-10" ], - "GG2.GP9": [ - "GOV-19.2" + "248.30(a)(4)(iv)(E)": [ + "IRO-10" ], - "ADM:SG1": [ - "AST-01" + "248.30(a)(4)(iv)(F)": [ + "IRO-10" ], - "ADM:SG1.SP2": [ - "AST-01", - "SEA-02.1" + "248.30(a)(4)(iv)(G)": [ + "IRO-10" ], - "ADM:GG1.GP1": [ - "AST-01", - "CPL-13", - "PRM-06", - "OPS-01.1" + "248.30(a)(4)(iv)(H)": [ + "IRO-10" ], - "ADM:GG2": [ - "AST-01" + "248.30(a)(5)(i)(B)": [ + "IRO-10" ], - "ADM:GG2.GP2": [ - "AST-01" + "248.30(a)(5)(ii)": [ + "IRO-10", + "TPM-05" ], - "KIM:SG1": [ - "AST-01" + "248.30(a)(5)(iii)": [ + "IRO-10" ], - "KIM:SG1.SP1": [ - "AST-01" + "248.201(e)(3)": [ + "SAT-03" ], - "KIM:SG1.SP2": [ - "AST-01" + "248.30(a)(5)(i)": [ + "TPM-01" ], - "TM:SG4.SP4": [ - "AST-01" + "248.30(a)(5)(i)(A)": [ + "TPM-01" ], - "ADM:SG2": [ - "AST-01.1" + "248.201(e)(4)": [ + "TPM-01" + ] + }, + "usa-federal-omb-fipps-1973": { + "1": [ + "PRI-06", + "PRI-06.1" ], - "ADM:SG2.SP1": [ - "AST-01.1", - "PRI-05.5", - "PRM-06", - "RSK-02", - "TPM-04" + "2": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "HRS-01", + "HRS-01.1", + "HRS-02", + "HRS-03", + "HRS-04.1", + "HRS-04.2", + "PRI-01", + "PRI-01.1", + "PRI-01.11", + "SAT-03", + "SAT-03.3" ], - "ADM:SG2.SP2": [ - "AST-01.1", - "BCD-02" + "3": [ + "PRI-02.1", + "PRI-04.1" ], - "ADM:GG2.GP7": [ - "AST-01.2" + "4": [ + "PRI-01.11", + "PRI-04", + "PRI-05", + "PRI-05.4" ], - "AM:GG2.GP7": [ - "AST-01.2" + "5": [ + "PRI-10" ], - "COMM:GG2.GP7": [ - "AST-01.2" + "6": [ + "PRI-06", + "PRI-06.4" ], - "COMP:GG2.GP7": [ - "AST-01.2" + "7": [ + "PRI-02", + "PRI-02.1", + "PRI-02.8" ], - "CTRL:GG2.GP7": [ - "AST-01.2" + "8": [ + "PRI-01.3", + "PRI-01.6", + "PRI-02" + ] + }, + "usa-federal-law-ftc-act": { + "45(a)(1)": [ + "GOV-01", + "GOV-01.1", + "GOV-08", + "GOV-14", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "SEA-01", + "SEA-02", + "SEA-03", + "TDA-01", + "TDA-01.1", + "TDA-06" + ] + }, + "usa-federal-law-glba-cfr-314-2023": { + "314.3(a)": [ + "GOV-01" ], - "EC:GG2.GP7": [ - "AST-01.2" + "314.3(b)(1)": [ + "GOV-01", + "GOV-09" ], - "EF:GG2.GP7": [ - "AST-01.2" + "314.3(b)(2)": [ + "GOV-01", + "GOV-09" ], - "EXD:GG2.GP7": [ - "AST-01.2" + "314.3(b)(3)": [ + "GOV-01", + "GOV-09" ], - "FRM:GG2.GP7": [ - "AST-01.2" + "314.4(a)": [ + "GOV-01", + "GOV-04", + "TPM-01", + "TPM-05" ], - "HRM:GG2.GP7": [ - "AST-01.2" + "314.4(b)": [ + "GOV-01", + "GOV-03", + "RSK-01", + "RSK-04" ], - "ID:GG2.GP7": [ - "AST-01.2" + "314.4(c)": [ + "GOV-01", + "GOV-02", + "CPL-01", + "SEA-01", + "SEA-01.1" ], - "IMC:GG2.GP7": [ - "AST-01.2" + "314.4(a)(2)": [ + "GOV-01.1", + "GOV-04", + "TPM-01", + "TPM-05" ], - "KIM:GG2.GP7": [ - "AST-01.2" + "314.4(i)": [ + "GOV-01.2" ], - "MA:GG2.GP7": [ - "AST-01.2" + "314.4(i)(1)": [ + "GOV-01.2" ], - "MON:GG2.GP7": [ - "AST-01.2" + "314.4(i)(2)": [ + "GOV-01.2" ], - "OPD:GG2.GP7": [ - "AST-01.2" + "314.4(c)(8)": [ + "GOV-02", + "OPS-01.1" ], - "OPF:GG2.GP7": [ - "AST-01.2" + "314.4(e)": [ + "GOV-02", + "OPS-01.1" ], - "OTA:GG2.GP7": [ - "AST-01.2" + "314.4(g)": [ + "GOV-03" ], - "PM:GG2.GP7": [ - "AST-01.2" + "314.4(a)(1)": [ + "GOV-04", + "TPM-01", + "TPM-05" ], - "RISK:GG2.GP7": [ - "AST-01.2" + "314.4(a)(3)": [ + "GOV-04", + "TPM-01", + "TPM-05" ], - "RRD:GG2.GP7": [ - "AST-01.2" + "314.4(c)(6)(i)": [ + "AST-09", + "DCH-08", + "DCH-21", + "PRI-05" ], - "RRM:GG2.GP7": [ - "AST-01.2" + "314.4(c)(7)": [ + "CHG-01", + "CHG-02", + "OPS-01", + "OPS-01.1" ], - "RTSE:GG2.GP7": [ - "AST-01.2" + "314.4(d)(1)": [ + "CPL-02", + "CPL-03" ], - "SC:GG2.GP7": [ - "AST-01.2" + "314.4(c)(3)": [ + "CRY-01" ], - "TM:GG2.GP7": [ - "AST-01.2" + "314.4(c)(1)(i)": [ + "DCH-01", + "IAC-01", + "IAC-20", + "IAC-21" ], - "VAR:GG2.GP7": [ - "AST-01.2" + "314.4(c)(6)(ii)": [ + "DCH-01", + "DCH-18" ], - "GG2.GP7": [ - "AST-01.2" + "314.4(e)(2)": [ + "HRS-01", + "HRS-03.2", + "HRS-04.1" ], - "ADM:SG1.SP1": [ - "AST-02" + "314.4(c)(1)": [ + "IAC-01" ], - "ADM:SG3.SP1": [ - "AST-02.9", - "CHG-01" + "314.4(c)(1)(ii)": [ + "IAC-01", + "IAC-08" ], - "ADM:SG3.SP2": [ - "AST-02.9", - "CHG-02" + "314.4(c)(5)": [ + "IAC-06" ], - "TM:SG1": [ - "AST-31" + "314.4(h)": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "TM:SG1.SP1": [ - "AST-31" + "314.4(h)(1)": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "COMM:SG1": [ - "BCD-01" + "314.4(h)(2)": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "COMM:SG1.SP1": [ - "BCD-01" + "314.4(h)(3)": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-07" ], - "COMM:SG1.SP2": [ - "BCD-01" + "314.4(h)(4)": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-10" ], - "COMM:SG1.SP3": [ - "BCD-01" + "314.4(h)(5)": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "COMM:SG2": [ - "BCD-01" + "314.4(h)(6)": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-09" ], - "COMM:SG2.SP1": [ - "BCD-01" + "314.4(h)(7)": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-04.2", + "IRO-13" ], - "COMM:SG2.SP2": [ - "BCD-01" + "314.4(c)(2)": [ + "RSK-03", + "RSK-04.1", + "RSK-05", + "RSK-06", + "RSK-06.1", + "RSK-06.2" ], - "COMM:SG2.SP3": [ - "BCD-01" + "314.4(b)(1)": [ + "RSK-04" ], - "COMM:SG3": [ - "BCD-01" + "314.4(b)(1)(i)": [ + "RSK-04" ], - "COMM:SG3.SP1": [ - "BCD-01" + "314.4(b)(1)(ii)": [ + "RSK-04" ], - "COMM:SG3.SP2": [ - "BCD-01" + "314.4(b)(1)(iii)": [ + "RSK-04" ], - "COMM:GG1.GP1": [ - "BCD-01", - "CPL-13", - "PRM-06", - "OPS-01.1" + "314.4(b)(2)": [ + "RSK-07" ], - "COMM:GG2": [ - "BCD-01" + "314.2": [ + "SEA-02.1" ], - "COMM:GG2.GP2": [ - "BCD-01" + "314.4(e)(1)": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6" ], - "EC:SG1": [ - "BCD-01" + "314.4(e)(3)": [ + "SAT-03.5" ], - "EC:SG4.SP1": [ - "BCD-01", - "CAP-01" + "314.4(e)(4)": [ + "SAT-03.7" ], - "EC:SG4.SP3": [ - "BCD-01" + "314.4(c)(4)": [ + "TDA-01", + "TDA-06" ], - "EC:SG4.SP4": [ - "BCD-01" + "314.4(f)": [ + "TPM-01" ], - "SC:SG3.SP2": [ - "BCD-01" + "314.4(f)(1)": [ + "TPM-02", + "TPM-03", + "TPM-03.2", + "TPM-04", + "TPM-04.1", + "TPM-04.4" ], - "SC:SG3.SP3": [ - "BCD-01" + "314.4(f)(2)": [ + "TPM-04" ], - "SC:SG3.SP4": [ - "BCD-01" + "314.4(f)(3)": [ + "TPM-04", + "TPM-04.1", + "TPM-08" ], - "SC:SG3.SP5": [ - "BCD-01" + "314.4(d)(2)": [ + "VPM-01", + "VPM-06", + "VPM-07" ], - "SC:SG4": [ - "BCD-01" + "314.4(d)(2)(ii)": [ + "VPM-06" ], - "SC:SG4.SP1": [ - "BCD-01" + "314.4(d)(2)(i)": [ + "VPM-07" + ] + }, + "usa-federal-hhs-45-cfr-155-260-2016": { + "155.260(a)(3)": [ + "GOV-01", + "PRI-01" ], - "SC:SG4.SP2": [ - "BCD-01" + "155.260(d)": [ + "GOV-02" ], - "SC:SG5": [ - "BCD-01" + "155.260(d)(1)": [ + "GOV-02" ], - "SC:SG5.SP1": [ - "BCD-01" + "155.260(d)(2)": [ + "GOV-02" ], - "SC:SG5.SP2": [ - "BCD-01" + "155.260(a)(5)": [ + "GOV-03" ], - "SC:SG5.SP3": [ - "BCD-01" + "155.260(a)(3)(viii)": [ + "GOV-15", + "CPL-02", + "MON-01" ], - "SC:SG5.SP4": [ - "BCD-01" + "155.260(a)(4)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "CPL-01" ], - "SC:SG6": [ - "BCD-01" + "155.260(a)(4)(i)": [ + "GOV-15" ], - "SC:SG6.SP1": [ - "BCD-01" + "155.260(a)(4)(iii)": [ + "GOV-15" ], - "SC:SG6.SP2": [ - "BCD-01" + "155.260(c)": [ + "GOV-15", + "HRS-05" ], - "SC:SG7": [ - "BCD-01" + "155.260(a)(6)": [ + "CLD-04", + "CFG-02", + "CRY-03" ], - "SC:SG7.SP1": [ - "BCD-01" + "155.260(b)(3)(i)": [ + "CPL-01" ], - "SC:SG7.SP2": [ - "BCD-01" + "155.260(b)(3)(ii)": [ + "CPL-01" ], - "SC:GG1.GP1": [ - "BCD-01", - "CPL-13", - "PRM-06", - "OPS-01.1" + "155.260(b)(3)(iii)": [ + "CPL-01" ], - "SC:GG2": [ - "BCD-01" + "155.260(b)(3)(iii)(A)": [ + "CPL-01" ], - "SC:GG2.GP2": [ - "BCD-01" + "155.260(b)(3)(iii)(B)": [ + "CPL-01" ], - "TM:SG5": [ - "BCD-01" + "155.260(b)(3)(iii)(C)": [ + "CPL-01" ], - "TM:SG5.SP1": [ - "BCD-01" + "155.260(e)(1)": [ + "CPL-01" ], - "TM:SG5.SP2": [ - "BCD-01" + "155.260(e)(2)": [ + "CPL-01" ], - "TM:SG5.SP3": [ - "BCD-01" + "155.260(e)(3)": [ + "CPL-01" ], - "TM:SG5.SP4": [ - "BCD-01" + "155.260(e)(4)": [ + "CPL-01" ], - "TM:GG1.GP1": [ - "BCD-01", - "CPL-13", - "PRM-06", - "OPS-01.1" + "155.260(a)(4)(iv)": [ + "DCH-01" ], - "TM:GG2.GP2": [ - "BCD-01" + "155.260(a)(4)(v)": [ + "DCH-01" ], - "EC:SG1.SP1": [ - "BCD-01.7" + "155.260(a)(4)(ii)": [ + "DCH-01.4", + "DCH-02", + "IAC-08" ], - "PM:SG3.SP3": [ - "BCD-01.7" + "155.260(a)(4)(vi)": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "PM:SG3.SP4": [ - "BCD-01.7" + "155.260(a)(2)": [ + "DCH-10.1" ], - "PM:SG3.SP5": [ - "BCD-01.7" + "155.260(a)(3)(vi)": [ + "DCH-22.1", + "PRI-05.2" ], - "EC:SG1.SP2": [ - "BCD-02" + "155.260(a)(3)(vii)": [ + "PRI-01.6" ], - "TM:SG1.SP2": [ - "BCD-02" + "155.260(a)(1)": [ + "PRI-01.7" ], - "TM:SG4": [ - "CHG-01" + "155.260(a)(1)(ii)": [ + "PRI-01.7" ], - "TM:SG4.SP1": [ - "CHG-01" + "155.260(a)(1)(iii)": [ + "PRI-01.7" ], - "TM:SG4.SP2": [ - "CHG-01" + "155.260(a)(1)(iii)(A)": [ + "PRI-01.7" ], - "TM:SG4.SP3": [ - "CHG-01" + "155.260(a)(3)(iii)": [ + "PRI-02" ], - "COMP:SG1": [ - "CPL-01" + "155.260(a)(3)(iv)": [ + "PRI-03" ], - "COMP:SG1.SP1": [ - "CPL-01" + "155.260(a)(3)(v)": [ + "PRI-05.4" ], - "COMP:SG1.SP2": [ - "CPL-01" + "155.260(a)(3)(i)": [ + "PRI-06" ], - "COMP:SG1.SP3": [ - "CPL-01" + "155.260(a)(3)(ii)": [ + "PRI-06.3" ], - "COMP:SG2": [ - "CPL-01" + "155.260(e)": [ + "PRI-07" ], - "COMP:SG2.SP1": [ - "CPL-01" + "155.260(b)(2)": [ + "TPM-05" ], - "COMP:SG2.SP2": [ - "CPL-01" + "155.260(b)(2)(i)": [ + "TPM-05" ], - "COMP:SG2.SP3": [ - "CPL-01" + "155.260(b)(2)(ii)": [ + "TPM-05" ], - "COMP:GG1": [ - "CPL-01" + "155.260(b)(2)(iii)": [ + "TPM-05" ], - "COMP:GG1.GP1": [ - "CPL-01", - "CPL-13", - "PRM-06", - "OPS-01.1" + "155.260(b)(2)(iv)": [ + "TPM-05" ], - "COMP:GG2": [ - "CPL-01" + "155.260(b)(2)(v)": [ + "TPM-05.2" + ] + }, + "usa-federal-law-hipaa-simplification-2013": { + "§ 164.306(a)(1)": [ + "GOV-01", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5" ], - "COMP:GG2.GP2": [ - "CPL-01" + "§ 164.306(a)(2)": [ + "GOV-01" ], - "COMP:SG3.SP3": [ - "CPL-01.1" + "§ 164.306(a)(3)": [ + "GOV-01", + "DCH-01", + "RSK-01" ], - "COMP:SG3.SP1": [ - "CPL-01.3" + "§ 164.316(a)": [ + "GOV-01", + "GOV-02" ], - "COMP:SG3.SP2": [ - "CPL-01.3" + "§ 164.530(c)(1)": [ + "GOV-01" ], - "COMP:SG3": [ - "CPL-01.5" + "§ 164.530(i)(1)": [ + "GOV-01", + "CPL-01", + "PRI-01" ], - "ADM:GG2.GP8": [ - "CPL-02" + "§ 164.308(a)(1)(i)": [ + "GOV-02", + "CHG-01", + "CFG-01", + "MON-01", + "IRO-01" ], - "AM:GG2.GP8": [ - "CPL-02" + "§ 164.308(a)(3)(i)": [ + "GOV-02", + "CFG-08", + "IAC-01", + "IAC-08", + "IAC-21" ], - "COMM:GG2.GP8": [ - "CPL-02" + "§ 164.308(a)(4)(i)": [ + "GOV-02", + "IAC-01" ], - "COMP:SG4": [ - "CPL-02" + "§ 164.308(a)(4)(ii)(A)": [ + "GOV-02" ], - "COMP:GG2.GP8": [ - "CPL-02" + "§ 164.308(a)(6)(i)": [ + "GOV-02", + "IRO-01" ], - "CTRL:GG2.GP8": [ - "CPL-02" + "§ 164.308(a)(7)(i)": [ + "GOV-02", + "BCD-01", + "IRO-01" ], - "EC:GG2.GP8": [ - "CPL-02" + "§ 164.310(a)(1)": [ + "GOV-02", + "PES-01" ], - "EF:GG2.GP8": [ - "CPL-02" + "§ 164.310(a)(2)(ii)": [ + "GOV-02", + "PES-01", + "PES-03" ], - "EXD:GG2.GP8": [ - "CPL-02" + "§ 164.310(a)(2)(iv)": [ + "GOV-02", + "MNT-01", + "MNT-02", + "PES-01" ], - "FRM:GG2.GP8": [ - "CPL-02" + "§ 164.310(b)": [ + "GOV-02", + "END-01", + "HRS-05", + "HRS-05.1", + "HRS-05.3", + "PES-03.4", + "PES-04", + "OPS-01.1", + "OPS-03" ], - "HRM:GG2.GP8": [ - "CPL-02" + "§ 164.310(d)(1)": [ + "GOV-02", + "AST-01", + "AST-11", + "DCH-01", + "DCH-03", + "DCH-07", + "DCH-07.1", + "DCH-13.2", + "MNT-01", + "MNT-04.3" ], - "ID:GG2.GP8": [ - "CPL-02" + "§ 164.310(d)(2)(i)": [ + "GOV-02", + "AST-01", + "AST-09" ], - "IMC:GG2.GP8": [ - "CPL-02" + "§ 164.312(a)(1)": [ + "GOV-02", + "HRS-02", + "HRS-03", + "IAC-01", + "IAC-08", + "IAC-21" ], - "KIM:GG2.GP8": [ - "CPL-02" + "§ 164.312(c)(1)": [ + "GOV-02", + "DCH-01", + "DCH-01.2" ], - "MA:GG2.GP8": [ - "CPL-02" + "§ 164.316(b)(1)(i)": [ + "GOV-02" ], - "MON:GG2.GP8": [ - "CPL-02" + "§ 164.530(j)(1)(i)": [ + "GOV-02" ], - "OPD:GG2.GP8": [ - "CPL-02" + "§ 164.306(d)(3)(ii)(B)(1)": [ + "GOV-02.1" ], - "OPF:GG2.GP8": [ - "CPL-02" + "§ 164.316(b)(1)(ii)": [ + "GOV-03", + "CPL-03" ], - "OTA:GG2.GP8": [ + "§ 164.316(b)(2)(iii)": [ + "GOV-03", "CPL-02" ], - "PM:GG2.GP8": [ - "CPL-02" + "§ 164.530(i)(2)(i)": [ + "GOV-03" ], - "RISK:GG2.GP8": [ - "CPL-02" + "§ 164.530(i)(2)(ii)": [ + "GOV-03" ], - "RRD:GG2.GP8": [ - "CPL-02" + "§ 164.530(i)(2)(iii)": [ + "GOV-03" ], - "RRM:GG2.GP8": [ - "CPL-02" + "§ 164.530(i)(3)": [ + "GOV-03" ], - "RTSE:GG2.GP8": [ - "CPL-02" + "§ 164.308(a)(2)": [ + "GOV-04" ], - "SC:GG2.GP8": [ - "CPL-02" + "§ 164.306(b)(2)(i)": [ + "GOV-08", + "PRM-06" ], - "TM:GG2.GP8": [ - "CPL-02" + "§ 164.306(b)(1)": [ + "GOV-09", + "GOV-15", + "SEA-01", + "SEA-02", + "SEA-03" ], - "VAR:GG2.GP8": [ - "CPL-02" + "§ 164.308(a)(1)(ii)(B)": [ + "GOV-09", + "GOV-15.2" ], - "GG2.GP8": [ - "CPL-02" + "§ 164.306(d)(3)(ii)(A)": [ + "GOV-15.2" ], - "COMP:SG4.SP1": [ - "CPL-03.1" + "§ 164.308(a)(7)(ii)(E)": [ + "AST-01", + "AST-01.1", + "BCD-02", + "TPM-02" ], - "ADM:GG3.GP2": [ - "CPL-13" + "§ 164.310(d)(2)(iii)": [ + "AST-02", + "AST-02.1", + "AST-02.9", + "AST-03", + "AST-03.1" ], - "AM:GG1.GP1": [ - "CPL-13", - "IAC-01", - "PRM-06", - "OPS-01.1" + "§ 164.310(d)(2)(ii)": [ + "AST-09", + "DCH-09" ], - "AM:GG3.GP2": [ - "CPL-13" + "§ 164.308(a)(7)(ii)(C)": [ + "BCD-01", + "BCD-02.2" ], - "COMM:GG3.GP2": [ - "CPL-13" + "§ 164.308(a)(7)(ii)(D)": [ + "BCD-04", + "BCD-05" ], - "COMP:GG3.GP2": [ - "CPL-13" + "§ 164.310(a)(2)(i)": [ + "BCD-09.2", + "HRS-03", + "PES-02", + "PES-02.1" ], - "CTRL:GG3.GP2": [ - "CPL-13" + "§ 164.308(a)(7)(ii)(A)": [ + "BCD-11" ], - "EC:GG1.GP1": [ - "CPL-13", - "PES-01", - "PRM-06", - "OPS-01.1" + "§ 164.310(d)(2)(iv)": [ + "BCD-11" ], - "EC:GG3.GP2": [ - "CPL-13" + "§ 164.308(a)(7)(ii)(B)": [ + "BCD-12" ], - "EF:GG3.GP2": [ - "CPL-13" + "§ 164.306(c)": [ + "CPL-01" ], - "EXD:GG1.GP1": [ - "CPL-13", - "PRM-06", - "OPS-01.1", - "TPM-01" + "§ 164.306(d)(1)": [ + "CPL-01" ], - "EXD:GG3.GP2": [ - "CPL-13" + "§ 164.306(d)(2)": [ + "CPL-01" ], - "FRM:GG1.GP1": [ - "CPL-13", - "PRM-01", - "PRM-06", - "OPS-01.1" + "§ 164.314(a)(1)": [ + "CPL-01" ], - "FRM:GG3.GP2": [ - "CPL-13" + "§ 164.314(a)(2)(ii)": [ + "CPL-01" ], - "HRM:GG1.GP1": [ - "CPL-13", - "HRS-01", - "PRM-06", - "OPS-01.1" + "§ 164.504(g)(1)": [ + "CPL-01" ], - "HRM:GG3.GP2": [ - "CPL-13" + "§ 164.306(d)(3)(i)": [ + "CPL-02", + "CPL-03", + "CPL-03.2" ], - "ID:GG1.GP1": [ - "CPL-13", - "IAC-01", - "PRM-06", - "OPS-01.1" + "§ 164.306(e)": [ + "CPL-03.2" ], - "ID:GG3.GP2": [ - "CPL-13" + "§ 164.308(a)(8)": [ + "CPL-03.2", + "IAO-01.1", + "IAO-02" ], - "IMC:GG1.GP1": [ - "CPL-13", - "IRO-01", - "PRM-06", - "OPS-01.1" + "§ 164.312(a)(2)(iii)": [ + "CFG-02", + "IAC-25" ], - "IMC:GG3.GP2": [ - "CPL-13" + "§ 164.312(e)(1)": [ + "CFG-02", + "CRY-03", + "NET-01" ], - "KIM:GG1.GP1": [ - "CPL-13", - "DCH-01", - "PRM-06", - "OPS-01.1" + "§ 164.312(e)(2)(i)": [ + "CFG-02", + "CRY-04", + "NET-01" ], - "KIM:GG3.GP2": [ - "CPL-13" + "§ 164.312(e)(2)(ii)": [ + "CFG-02", + "CRY-01", + "OPS-03" ], - "MA:GG3.GP2": [ - "CPL-13" + "§ 164.312(c)(2)": [ + "CFG-08", + "CFG-08.1", + "MON-01.7", + "MON-01.15", + "MON-16" ], - "MON:GG1.GP1": [ - "CPL-13", + "§ 164.308(a)(1)(ii)(D)": [ "MON-01", - "PRM-06", - "OPS-01.1" - ], - "MON:GG3.GP2": [ - "CPL-13" + "MON-01.8", + "IRO-09" ], - "OPD:GG1.GP1": [ - "CPL-13", - "PRM-06", - "OPS-01.1" + "§ 164.312(b)": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-01.16", + "MON-03", + "MON-03.2", + "MON-16" ], - "OPD:GG3.GP2": [ - "CPL-13" + "§ 164.312(a)(2)(iv)": [ + "CRY-01" ], - "OPF:GG1.GP1": [ - "CPL-13", - "PRM-06", - "OPS-01.1" + "§ 164.514(d)(3)(i)": [ + "DCH-01", + "DCH-01.2", + "DCH-03.1" ], - "OPF:GG3.GP2": [ - "CPL-13" + "§ 164.530(c)(2)(i)": [ + "DCH-01", + "DCH-01.2" ], - "OTA:GG1.GP1": [ - "CPL-13", - "PRM-06", - "OPS-01.1", - "SAT-01" + "§ 164.510(b)(1)(i)": [ + "DCH-03.1" ], - "OTA:GG3.GP2": [ - "CPL-13" + "§ 164.510(b)(1)(ii)": [ + "DCH-03.1" ], - "PM:GG1.GP1": [ - "CPL-13", - "HRS-01", - "PRM-06", - "OPS-01.1" + "§ 164.510(b)(2)": [ + "DCH-03.1" ], - "PM:GG3.GP2": [ - "CPL-13" + "§ 164.510(b)(4)": [ + "DCH-03.1", + "PRI-05.4" ], - "RISK:GG1.GP1": [ - "CPL-13", - "PRM-06", - "RSK-01", - "OPS-01.1" + "§ 164.510(b)(5)": [ + "DCH-03.1" ], - "RISK:GG3.GP2": [ - "CPL-13" + "§ 164.512": [ + "DCH-03.1", + "PRI-05.4" ], - "RRD:GG1.GP1": [ - "CPL-13", - "PRM-06", - "SEA-01.2", - "OPS-01.1" + "§ 164.512(a)(1)": [ + "DCH-03.1" ], - "RRD:GG3.GP2": [ - "CPL-13" + "§ 164.512(c)(1)": [ + "DCH-03.1" ], - "RRM:GG1.GP1": [ - "CPL-13", - "PRM-06", - "SEA-01.2", - "OPS-01.1" + "§ 164.512(c)(1)(i)": [ + "DCH-03.1" ], - "RRM:GG3.GP2": [ - "CPL-13" + "§ 164.512(c)(1)(ii)": [ + "DCH-03.1" ], - "RTSE:GG1.GP1": [ - "CPL-13", - "PRM-06", - "SEA-01", - "OPS-01.1" + "§ 164.512(c)(1)(iii)(A)": [ + "DCH-03.1" ], - "RTSE:GG3.GP2": [ - "CPL-13" + "§ 164.512(c)(1)(iii)(B)": [ + "DCH-03.1" ], - "SC:GG3.GP2": [ - "CPL-13" + "§ 164.512(c)(2)": [ + "DCH-03.1" ], - "TM:GG3.GP2": [ - "CPL-13" + "§ 164.512(c)(2)(i)": [ + "DCH-03.1" ], - "VAR:GG1.GP1": [ - "CPL-13", - "PRM-06", - "OPS-01.1", - "VPM-01" + "§ 164.512(c)(2)(ii)": [ + "DCH-03.1" ], - "VAR:GG3.GP2": [ - "CPL-13" + "§ 164.512(d)(1)": [ + "DCH-03.1" ], - "GG3.GP2": [ - "CPL-13" + "§ 164.512(d)(1)(i)": [ + "DCH-03.1" ], - "OPD:SG1.SP2": [ - "CFG-02.9" + "§ 164.512(d)(1)(ii)": [ + "DCH-03.1" ], - "MON:SG1": [ - "MON-01" + "§ 164.512(d)(1)(iii)": [ + "DCH-03.1" ], - "MON:SG1.SP1": [ - "MON-01" + "§ 164.512(d)(1)(iv)": [ + "DCH-03.1" ], - "MON:SG1.SP2": [ - "MON-01" + "§ 164.512(e)(1)": [ + "DCH-03.1" ], - "MON:SG1.SP3": [ - "MON-01" + "§ 164.512(e)(1)(i)": [ + "DCH-03.1" ], - "MON:SG1.SP4": [ - "MON-01" + "§ 164.512(e)(1)(ii)": [ + "DCH-03.1" ], - "MON:SG2": [ - "MON-01" + "§ 164.512(e)(1)(ii)(A)": [ + "DCH-03.1" ], - "MON:SG2.SP1": [ - "MON-01" + "§ 164.512(e)(1)(ii)(B)": [ + "DCH-03.1" ], - "MON:SG2.SP2": [ - "MON-01" + "§ 164.512(e)(1)(iii)": [ + "DCH-03.1" ], - "MON:SG2.SP3": [ - "MON-01" + "§ 164.512(e)(1)(iii)(A)": [ + "DCH-03.1" ], - "MON:SG2.SP4": [ - "MON-01" + "§ 164.512(e)(1)(iii)(B)": [ + "DCH-03.1" ], - "MON:GG2": [ - "MON-01" + "§ 164.512(e)(1)(iii)(C)": [ + "DCH-03.1" ], - "MON:GG2.GP2": [ - "MON-01" + "§ 164.512(e)(1)(iii)(C)(1)": [ + "DCH-03.1" ], - "IMC:SG2": [ - "MON-01.4" + "§ 164.512(e)(1)(iii)(C)(2)": [ + "DCH-03.1" ], - "IMC:SG2.SP1": [ - "MON-01.4" + "§ 164.512(e)(1)(iv)": [ + "DCH-03.1" ], - "IMC:SG2.SP2": [ - "MON-01.4" + "§ 164.512(e)(1)(iv)(A)": [ + "DCH-03.1" ], - "KIM:SG4": [ - "DCH-01" + "§ 164.512(e)(1)(iv)(B)": [ + "DCH-03.1" ], - "KIM:SG4.SP1": [ - "DCH-01" + "§ 164.512(e)(1)(v)": [ + "DCH-03.1" ], - "KIM:SG4.SP2": [ - "DCH-01" + "§ 164.512(e)(1)(v)(A)": [ + "DCH-03.1" ], - "KIM:SG4.SP3": [ - "DCH-01" + "§ 164.512(e)(1)(v)(B)": [ + "DCH-03.1" ], - "KIM:SG5": [ - "DCH-01" + "§ 164.512(e)(1)(vi)": [ + "DCH-03.1" ], - "KIM:SG5.SP1": [ - "DCH-01" + "§ 164.512(f)": [ + "DCH-03.1" ], - "KIM:SG5.SP2": [ - "DCH-01" + "§ 164.512(f)(1)": [ + "DCH-03.1" ], - "KIM:SG5.SP3": [ - "DCH-01" + "§ 164.512(f)(1)(i)": [ + "DCH-03.1" ], - "KIM:SG6": [ - "DCH-01" + "§ 164.512(f)(1)(ii)(A)": [ + "DCH-03.1" ], - "KIM:SG6.SP1": [ - "DCH-01" + "§ 164.512(f)(1)(ii)(B)": [ + "DCH-03.1" ], - "KIM:SG6.SP2": [ - "DCH-01" + "§ 164.512(f)(1)(ii)(C)": [ + "DCH-03.1" ], - "KIM:GG2": [ - "DCH-01" + "§ 164.512(f)(1)(ii)(C)(1)": [ + "DCH-03.1" ], - "KIM:GG2.GP2": [ - "DCH-01" + "§ 164.512(f)(1)(ii)(C)(2)": [ + "DCH-03.1" ], - "HRM:SG1": [ - "HRS-01" + "§ 164.512(f)(1)(ii)(C)(3)": [ + "DCH-03.1" ], - "HRM:SG1.SP1": [ - "HRS-01" + "§ 164.512(f)(2)": [ + "DCH-03.1" ], - "HRM:SG1.SP2": [ - "HRS-01" + "§ 164.512(f)(2)(i)(A)": [ + "DCH-03.1" ], - "HRM:SG2.SP1": [ - "HRS-01" + "§ 164.512(f)(2)(i)(B)": [ + "DCH-03.1" ], - "HRM:SG2.SP2": [ - "HRS-01" + "§ 164.512(f)(2)(i)(C)": [ + "DCH-03.1" ], - "HRM:SG3": [ - "HRS-01" + "§ 164.512(f)(2)(i)(D)": [ + "DCH-03.1" ], - "HRM:SG3.SP3": [ - "HRS-01" + "§ 164.512(f)(2)(i)(E)": [ + "DCH-03.1" ], - "HRM:SG4": [ - "HRS-01" + "§ 164.512(f)(2)(i)(F)": [ + "DCH-03.1" ], - "HRM:SG4.SP1": [ - "HRS-01" + "§ 164.512(f)(2)(i)(G)": [ + "DCH-03.1" ], - "HRM:SG4.SP2": [ - "HRS-01" + "§ 164.512(f)(2)(i)(H)": [ + "DCH-03.1" ], - "HRM:SG4.SP3": [ - "HRS-01" + "§ 164.512(f)(2)(ii)": [ + "DCH-03.1" ], - "HRM:GG2": [ - "HRS-01" + "§ 164.512(f)(3)": [ + "DCH-03.1" ], - "HRM:GG2.GP2": [ - "HRS-01" + "§ 164.512(f)(3)(i)": [ + "DCH-03.1" ], - "PM:SG3": [ - "HRS-01" + "§ 164.512(f)(3)(ii)": [ + "DCH-03.1" ], - "PM:SG3.SP1": [ - "HRS-01" + "§ 164.512(f)(3)(ii)(A)": [ + "DCH-03.1" ], - "PM:SG3.SP2": [ - "HRS-01" + "§ 164.512(f)(3)(ii)(B)": [ + "DCH-03.1" ], - "PM:GG2": [ - "HRS-01" + "§ 164.512(f)(3)(ii)(C)": [ + "DCH-03.1" ], - "PM:GG2.GP2": [ - "HRS-01" + "§ 164.512(f)(4)": [ + "DCH-03.1" ], - "ADM:GG2.GP4": [ - "HRS-03" + "§ 164.512(f)(5)": [ + "DCH-03.1" ], - "ADM:GG2.GP6": [ - "HRS-03" + "§ 164.512(f)(6)(i)": [ + "DCH-03.1" ], - "AM:GG2.GP4": [ - "HRS-03" + "§ 164.512(f)(6)(i)(A)": [ + "DCH-03.1" ], - "AM:GG2.GP6": [ - "HRS-03" + "§ 164.512(f)(6)(i)(B)": [ + "DCH-03.1" ], - "COMM:GG2.GP4": [ - "HRS-03" + "§ 164.512(f)(6)(i)(C)": [ + "DCH-03.1" ], - "COMM:GG2.GP6": [ - "HRS-03" + "§ 164.512(f)(6)(ii)": [ + "DCH-03.1" ], - "COMP:GG2.GP4": [ - "HRS-03" + "§ 164.512(g)(1)": [ + "DCH-03.1" ], - "COMP:GG2.GP6": [ - "HRS-03" + "§ 164.512(g)(2)": [ + "DCH-03.1" ], - "CTRL:GG2.GP4": [ - "HRS-03" + "§ 164.512(h)": [ + "DCH-03.1" ], - "CTRL:GG2.GP6": [ - "HRS-03" + "§ 164.512(i)(1)": [ + "DCH-03.1", + "PRI-05.4" ], - "EC:GG2.GP4": [ - "HRS-03" + "§ 164.512(j)(1)": [ + "DCH-03.1", + "PRI-05.4" ], - "EC:GG2.GP6": [ - "HRS-03" + "§ 164.514(d)(3)(ii)(A)": [ + "DCH-03.1" ], - "EF:GG2.GP4": [ - "HRS-03" + "§ 164.514(d)(3)(ii)(B)": [ + "DCH-03.1" ], - "EF:GG2.GP6": [ - "HRS-03" + "§ 164.514(d)(3)(iii)": [ + "DCH-03.1" ], - "EXD:GG2.GP4": [ - "HRS-03" + "§ 164.514(d)(3)(iii)(A)": [ + "DCH-03.1" ], - "EXD:GG2.GP6": [ - "HRS-03" + "§ 164.514(d)(3)(iii)(B)": [ + "DCH-03.1" ], - "FRM:GG2.GP4": [ - "HRS-03" + "§ 164.514(d)(3)(iii)(C)": [ + "DCH-03.1" ], - "FRM:GG2.GP6": [ - "HRS-03" + "§ 164.514(d)(3)(iii)(D)": [ + "DCH-03.1" ], - "HRM:SG3.SP1": [ - "HRS-03" + "§ 164.514(d)(4)": [ + "DCH-03.1" ], - "HRM:GG2.GP4": [ - "HRS-03" + "§ 164.514(d)(4)(i)": [ + "DCH-03.1" ], - "HRM:GG2.GP6": [ - "HRS-03" + "§ 164.514(d)(4)(ii)": [ + "DCH-03.1" ], - "ID:GG2.GP4": [ - "HRS-03" + "§ 164.514(d)(4)(iii)(A)": [ + "DCH-03.1" ], - "ID:GG2.GP6": [ - "HRS-03" + "§ 164.514(d)(4)(iii)(B)": [ + "DCH-03.1" ], - "IMC:GG2.GP4": [ - "HRS-03" + "§ 164.514(d)(5)": [ + "DCH-03.1" ], - "IMC:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(1)": [ + "DCH-03.1" ], - "KIM:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)": [ + "DCH-03.1" ], - "KIM:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(2)(i)": [ + "DCH-03.1" ], - "MA:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)(ii)": [ + "DCH-03.1" ], - "MA:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(2)(iii)": [ + "DCH-03.1" ], - "MON:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)(iv)": [ + "DCH-03.1" ], - "MON:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(2)(v)": [ + "DCH-03.1" ], - "OPD:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)(vi)": [ + "DCH-03.1" ], - "OPD:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(2)(vii)": [ + "DCH-03.1" ], - "OPF:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)(viii)": [ + "DCH-03.1" ], - "OPF:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(2)(ix)": [ + "DCH-03.1" ], - "OTA:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)(x)": [ + "DCH-03.1" ], - "OTA:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(2)(xi)": [ + "DCH-03.1" ], - "PM:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)(xii)": [ + "DCH-03.1" ], - "PM:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(2)(xiii)": [ + "DCH-03.1" ], - "RISK:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)(xiv)": [ + "DCH-03.1" ], - "RISK:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(2)(xv)": [ + "DCH-03.1" ], - "RRD:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(2)(xvi)": [ + "DCH-03.1" ], - "RRD:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(3)(i)": [ + "DCH-03.1" ], - "RRM:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(3)(ii)": [ + "DCH-03.1" ], - "RRM:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(4)(i)": [ + "DCH-03.1" ], - "RTSE:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(4)(ii)": [ + "DCH-03.1" ], - "RTSE:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(4)(ii)(A)": [ + "DCH-03.1" ], - "SC:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(4)(ii)(B)": [ + "DCH-03.1" ], - "SC:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(4)(ii)(C)": [ + "DCH-03.1" ], - "TM:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(4)(ii)(C)(1)": [ + "DCH-03.1" ], - "TM:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(4)(ii)(C)(2)": [ + "DCH-03.1" ], - "VAR:GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(4)(ii)(C)(3)": [ + "DCH-03.1" ], - "VAR:GG2.GP6": [ - "HRS-03" + "§ 164.514(e)(4)(ii)(C)(4)": [ + "DCH-03.1" ], - "GG2.GP4": [ - "HRS-03" + "§ 164.514(e)(4)(ii)(C)(5)": [ + "DCH-03.1" ], - "GG2.GP6": [ - "HRS-03" + "§ 164.532(a)": [ + "DCH-03.1", + "PRI-05.4" ], - "HRM:SG3.SP2": [ - "HRS-03.1" + "§ 164.532(b)": [ + "DCH-03.1", + "PRI-05.4" ], - "HRM:SG3.SP4": [ - "HRS-07" + "§ 164.532(c)": [ + "DCH-03.1", + "PRI-05.4" ], - "HRM:SG1.SP3": [ - "HRS-13" + "§ 164.532(c)(1)": [ + "DCH-03.1" ], - "HRM:SG2": [ - "HRS-13.1" + "§ 164.532(d)": [ + "DCH-03.1" ], - "PM:SG1": [ - "HRS-13.2" + "§ 164.316(b)(2)(i)": [ + "DCH-18" ], - "PM:SG1.SP1": [ - "HRS-13.2" + "§ 164.530(j)(2)": [ + "DCH-18" ], - "PM:SG2": [ - "HRS-13.2" + "§ 164.502(b)(1)": [ + "DCH-18.1" ], - "PM:SG2.SP1": [ - "HRS-13.2" + "§ 164.526(a)(1)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-12" ], - "AM:SG1": [ - "IAC-01" + "§ 164.526(b)(1)": [ + "DCH-22.1", + "PRI-06.1", + "PRI-12" ], - "AM:GG2": [ - "IAC-01" + "§ 164.310(c)": [ + "END-02", + "PES-03", + "PES-03.4", + "PES-04", + "PES-04.1" ], - "AM:GG2.GP2": [ - "IAC-01" + "§ 164.308(a)(3)(ii)(A)": [ + "HRS-01", + "IAC-07.1", + "IAC-08", + "IAC-28.1" ], - "ID:SG1": [ - "IAC-01" + "§ 164.312(d)": [ + "HRS-01", + "HRS-04", + "IAC-28", + "IAC-28.2", + "IAC-28.3", + "TPM-01" ], - "ID:SG1.SP1": [ - "IAC-01" + "§ 164.530(e)(2)": [ + "HRS-01" ], - "ID:SG1.SP2": [ - "IAC-01" + "§ 164.308(a)(3)(ii)(B)": [ + "HRS-02", + "HRS-03", + "IAC-17" ], - "ID:SG1.SP3": [ - "IAC-01" + "§ 164.530(a)(2)": [ + "HRS-02", + "HRS-03" ], - "ID:SG2": [ - "IAC-01" + "§ 164.530(b)(1)": [ + "HRS-05.7", + "SAT-03" ], - "ID:SG2.SP1": [ - "IAC-01" + "§ 164.502(a)": [ + "HRS-06.1", + "PRI-01" ], - "ID:SG2.SP2": [ - "IAC-01" + "§ 164.308(a)(1)(ii)(C)": [ + "HRS-07" ], - "ID:SG2.SP3": [ - "IAC-01" + "§ 164.530(e)(1)": [ + "HRS-07" ], - "ID:SG2.SP4": [ - "IAC-01" + "§ 164.308(a)(3)(ii)(C)": [ + "HRS-08", + "HRS-09", + "IAC-07", + "IAC-07.2" ], - "ID:GG2": [ + "§ 164.308(a)(4)(ii)(B)": [ "IAC-01" ], - "ID:GG2.GP2": [ - "IAC-01" + "§ 164.310(a)(2)(iii)": [ + "IAC-01", + "PES-02", + "PES-03", + "PES-06" ], - "AM:SG1.SP1": [ + "§ 164.530(c)(2)(ii)": [ + "IAC-01", "IAC-08" ], - "AM:SG1.SP2": [ - "IAC-15.7" - ], - "AM:SG1.SP3": [ - "IAC-17" - ], - "AM:SG1.SP4": [ - "IAC-17" + "§ 164.312(a)(2)(i)": [ + "IAC-02", + "IAC-09" ], - "IMC:SG1": [ - "IRO-01" + "§ 164.308(a)(4)(ii)(C)": [ + "IAC-08" ], - "IMC:SG1.SP1": [ - "IRO-01" + "§ 164.514(d)(2)(i)(A)": [ + "IAC-08" ], - "IMC:SG1.SP2": [ - "IRO-01" + "§ 164.514(d)(2)(i)(B)": [ + "IAC-08" ], - "IMC:GG2": [ - "IRO-01" + "§ 164.514(d)(2)(ii)": [ + "IAC-08" ], - "IMC:GG2.GP2": [ - "IRO-01" + "§ 164.312(a)(2)(ii)": [ + "IAC-15", + "IAC-15.2", + "IAC-15.9" ], - "IMC:SG2.SP4": [ + "§ 164.308(a)(6)(ii)": [ "IRO-02" ], - "IMC:SG3": [ + "§ 164.412": [ "IRO-02" ], - "IMC:SG3.SP1": [ + "§ 164.412(a)": [ "IRO-02" ], - "IMC:SG3.SP2": [ + "§ 164.412(b)": [ "IRO-02" ], - "IMC:SG4": [ + "§ 164.530(f)": [ "IRO-02" ], - "IMC:SG4.SP1": [ - "IRO-02" + "§ 164.404(a)(1)": [ + "IRO-04.1" ], - "IMC:SG4.SP2": [ - "IRO-02" + "§ 164.404(a)(2)": [ + "IRO-04.1" ], - "IMC:SG4.SP3": [ - "IRO-02" + "§ 164.404(c)(1)(A)": [ + "IRO-04.1" ], - "IMC:SG4.SP4": [ - "IRO-02" + "§ 164.404(c)(1)(B)": [ + "IRO-04.1" ], - "IMC:SG2.SP3": [ - "IRO-08" + "§ 164.404(c)(1)(C)": [ + "IRO-04.1" ], - "IMC:SG5": [ - "IRO-13" + "§ 164.404(c)(1)(D)": [ + "IRO-04.1" ], - "IMC:SG5.SP1": [ - "IRO-13" + "§ 164.404(c)(1)(E)": [ + "IRO-04.1" ], - "IMC:SG5.SP2": [ - "IRO-13" + "§ 164.404(c)(2)": [ + "IRO-04.1" ], - "EC:SG4": [ - "PES-01" + "§ 164.404(d)(1)(i)": [ + "IRO-04.1" ], - "EC:SG4.SP2": [ - "PES-01" + "§ 164.404(d)(1)(ii)": [ + "IRO-04.1" ], - "EC:GG2": [ - "PES-01" + "§ 164.404(d)(2)": [ + "IRO-04.1" ], - "EC:GG2.GP2": [ - "PES-01" + "§ 164.404(d)(2)(i)": [ + "IRO-04.1" ], - "EF:SG1.SP3": [ - "PRM-01" + "§ 164.404(d)(2)(ii)(A)": [ + "IRO-04.1" ], - "FRM:SG1": [ - "PRM-01" + "§ 164.404(d)(2)(ii)(B)": [ + "IRO-04.1" ], - "FRM:SG1.SP1": [ - "PRM-01" + "§ 164.404(d)(3)": [ + "IRO-04.1" ], - "FRM:SG1.SP2": [ - "PRM-01" + "§ 164.406(a)": [ + "IRO-04.1" ], - "FRM:SG2": [ - "PRM-01" + "§ 164.406(b)": [ + "IRO-04.1" ], - "FRM:SG2.SP1": [ - "PRM-01" + "§ 164.406(c)": [ + "IRO-04.1" ], - "FRM:SG2.SP2": [ - "PRM-01" + "§ 164.410(c)(1)": [ + "IRO-04.1" ], - "FRM:SG2.SP3": [ - "PRM-01" + "§ 164.404(b)": [ + "IRO-10" ], - "FRM:SG3": [ - "PRM-01" + "§ 164.408(a)": [ + "IRO-10" ], - "FRM:SG3.SP1": [ - "PRM-01" + "§ 164.408(b)": [ + "IRO-10" ], - "FRM:SG4": [ - "PRM-01" + "§ 164.408(c)": [ + "IRO-10" ], - "FRM:SG4.SP1": [ - "PRM-01" + "§ 164.410(a)(1)": [ + "IRO-10.2", + "TPM-05.1" ], - "FRM:SG4.SP2": [ - "PRM-01" + "§ 164.308(b)(3)": [ + "IAO-03.2", + "TPM-05" ], - "FRM:SG5": [ - "PRM-01" + "§ 164.530(a)(1)(i)": [ + "PRI-01", + "PRI-01.1" ], - "FRM:SG5.SP1": [ - "PRM-01" + "§ 164.530(i)(4)(i)(A)": [ + "PRI-01" ], - "FRM:SG5.SP2": [ - "PRM-01" + "§ 164.530(i)(4)(i)(B)": [ + "PRI-01" ], - "FRM:SG5.SP3": [ - "PRM-01" + "§ 164.530(i)(5)": [ + "PRI-01" ], - "FRM:GG2": [ - "PRM-01" + "§ 164.530(i)(5)(i)": [ + "PRI-01" ], - "FRM:GG2.GP2": [ - "PRM-01" + "§ 164.530(i)(5)(ii)": [ + "PRI-01" ], - "SC:SG1": [ - "PRM-01" + "§ 164.530(a)(1)(ii)": [ + "PRI-01.4" ], - "SC:SG1.SP1": [ - "PRM-01" + "§ 164.520(a)(1)": [ + "PRI-02" ], - "SC:SG1.SP2": [ - "PRM-01" + "§ 164.520(a)(2)(i)": [ + "PRI-02" ], - "SC:SG2": [ - "PRM-01" + "§ 164.520(a)(2)(i)(A)": [ + "PRI-02" ], - "SC:SG2.SP1": [ - "PRM-01" + "§ 164.520(a)(2)(i)(B)": [ + "PRI-02" ], - "EF:SG1": [ - "PRM-01.1" + "§ 164.520(a)(2)(ii)": [ + "PRI-02" ], - "EF:SG1.SP1": [ - "PRM-01.1" + "§ 164.520(a)(2)(ii)(A)": [ + "PRI-02" ], - "EF:SG1.SP2": [ - "PRM-01.1" + "§ 164.520(a)(2)(ii)(B)": [ + "PRI-02" ], - "EF:SG2.SP1": [ - "PRM-01.1" + "§ 164.520(a)(2)(iii)": [ + "PRI-02" ], - "ADM:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)": [ + "PRI-02" ], - "AM:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(i)": [ + "PRI-02" ], - "COMM:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(ii)": [ + "PRI-02" ], - "COMP:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(ii)(A)": [ + "PRI-02" ], - "CTRL:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(ii)(B)": [ + "PRI-02" ], - "EC:SG4.SP5": [ - "PRM-02" + "§ 164.520(b)(1)(ii)(C)": [ + "PRI-02" ], - "EC:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(ii)(D)": [ + "PRI-02" ], - "EF:SG2": [ - "PRM-02" + "§ 164.520(b)(1)(ii)(E)": [ + "PRI-02" ], - "EF:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(iv)": [ + "PRI-02" ], - "EXD:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(iv)(A)": [ + "PRI-02" ], - "FRM:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(iv)(B)": [ + "PRI-02" ], - "HRM:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(iv)(C)": [ + "PRI-02" ], - "ID:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(iv)(D)": [ + "PRI-02" ], - "IMC:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(iv)(E)": [ + "PRI-02" ], - "KIM:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(iv)(F)": [ + "PRI-02" ], - "MA:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(v)": [ + "PRI-02" ], - "MON:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(v)(A)": [ + "PRI-02" ], - "OPD:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(v)(B)": [ + "PRI-02" ], - "OPF:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(v)(C)": [ + "PRI-02" ], - "OTA:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(vi)": [ + "PRI-02" ], - "PM:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(vii)": [ + "PRI-02" ], - "RISK:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(1)(viii)": [ + "PRI-02" ], - "RRD:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(2)(i)": [ + "PRI-02" ], - "RRM:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(2)(ii)": [ + "PRI-02" ], - "RTSE:GG2.GP3": [ - "PRM-02" + "§ 164.520(b)(3)": [ + "PRI-02" ], - "SC:GG2.GP3": [ - "PRM-02" + "§ 164.520(c)": [ + "PRI-02" ], - "TM:GG2.GP3": [ - "PRM-02" + "§ 164.520(c)(1)(i)": [ + "PRI-02" ], - "VAR:GG2.GP3": [ - "PRM-02" + "§ 164.520(c)(1)(i)(A)": [ + "PRI-02" ], - "GG2.GP3": [ - "PRM-02" + "§ 164.520(c)(1)(i)(B)": [ + "PRI-02" ], - "EF:SG2.SP2": [ - "PRM-04" + "§ 164.520(c)(1)(ii)": [ + "PRI-02" ], - "SC:SG2.SP2": [ - "PRM-06" + "§ 164.520(c)(1)(iii)": [ + "PRI-02" ], - "SC:SG2.SP3": [ - "PRM-06" + "§ 164.520(c)(1)(iv)": [ + "PRI-02" ], - "SC:SG3": [ - "PRM-06" + "§ 164.520(c)(1)(v)": [ + "PRI-02" ], - "SC:SG3.SP1": [ - "PRM-06" + "§ 164.520(c)(1)(v)(A)": [ + "PRI-02" ], - "ADM:SG3": [ - "PRM-07" + "§ 164.520(c)(1)(v)(B)": [ + "PRI-02" ], - "RISK:SG1": [ - "RSK-01" + "§ 164.530(i)(4)(i)(C)": [ + "PRI-02" ], - "RISK:SG1.SP1": [ - "RSK-01" + "§ 164.502(a)(3)": [ + "PRI-02.1" ], - "RISK:SG1.SP2": [ - "RSK-01" + "§ 164.508(c)(1)(i)": [ + "PRI-02.1" ], - "RISK:SG4.SP3": [ - "RSK-01" + "§ 164.508(c)(1)(ii)": [ + "PRI-02.1" ], - "RISK:SG6": [ - "RSK-01" + "§ 164.508(c)(1)(iii)": [ + "PRI-02.1" ], - "RISK:SG6.SP1": [ - "RSK-01" + "§ 164.508(c)(1)(iv)": [ + "PRI-02.1" ], - "RISK:SG6.SP2": [ - "RSK-01" + "§ 164.508(c)(2)(i)(A)": [ + "PRI-02.1" ], - "RISK:GG2": [ - "RSK-01" + "§ 164.508(c)(2)(i)(B)": [ + "PRI-02.1" ], - "RISK:GG2.GP2": [ - "RSK-01" + "§ 164.506(b)(1)": [ + "PRI-03" ], - "TM:SG3": [ - "RSK-01" + "§ 164.508(a)(2)": [ + "PRI-03" ], - "TM:SG3.SP1": [ - "RSK-01" + "§ 164.508(c)(1)(v)": [ + "PRI-03" ], - "RISK:SG2": [ - "RSK-01.5" + "§ 164.508(c)(3)": [ + "PRI-03" ], - "RISK:SG2.SP1": [ - "RSK-01.5" + "§ 164.510(b)(2)(i)": [ + "PRI-03" ], - "RISK:SG4.SP2": [ - "RSK-02" + "§ 164.510(b)(2)(ii)": [ + "PRI-03" ], - "RISK:SG4": [ - "RSK-02.1" + "§ 164.510(b)(2)(iii)": [ + "PRI-03" ], - "EC:SG3": [ - "RSK-03" + "§ 164.510(b)(3)": [ + "PRI-03" ], - "KIM:SG3": [ - "RSK-03" + "§ 164.514(f)(2)(ii)": [ + "PRI-03" ], - "KIM:SG3.SP1": [ - "RSK-03" + "§ 164.514(f)(2)(iv)": [ + "PRI-03" ], - "RISK:SG3": [ - "RSK-03" + "§ 164.514(f)(2)(v)": [ + "PRI-03" ], - "RISK:SG3.SP1": [ - "RSK-03" + "§ 164.502(a)(5)(ii)(A)": [ + "PRI-03.3" ], - "RISK:SG3.SP2": [ - "RSK-03" + "§ 164.508(c)(2)(ii)(A)": [ + "PRI-03.5" ], - "EC:SG3.SP1": [ - "RSK-04" + "§ 164.508(c)(2)(ii)(B)": [ + "PRI-03.5" ], - "RISK:SG4.SP1": [ - "RSK-04" + "§ 164.514(f)(2)(iii)": [ + "PRI-03.5" ], - "RISK:SG2.SP2": [ - "RSK-04.2" + "§ 164.502(g)(1)": [ + "PRI-03.6" ], - "RISK:SG5": [ - "RSK-06" + "§ 164.502(g)(2)": [ + "PRI-03.6" ], - "EC:SG3.SP2": [ - "RSK-06.4" + "§ 164.502(g)(3)(i)": [ + "PRI-03.6" ], - "KIM:SG3.SP2": [ - "RSK-06.4" + "§ 164.502(g)(3)(i)(A)": [ + "PRI-03.6" ], - "PM:SG2.SP2": [ - "RSK-06.4" + "§ 164.502(a)(1)(i)": [ + "PRI-04.1" ], - "RISK:SG5.SP1": [ - "RSK-06.4" + "§ 164.502(a)(1)(ii)": [ + "PRI-04.1" ], - "RISK:SG5.SP2": [ - "RSK-06.4" + "§ 164.502(a)(1)(iii)": [ + "PRI-04.1" ], - "TM:SG3.SP2": [ - "RSK-06.4" + "§ 164.502(a)(5)(i)": [ + "PRI-04.1" ], - "RTSE:SG1": [ - "SEA-01" + "§ 164.502(i)": [ + "PRI-04.1" ], - "RTSE:SG1.SP1": [ - "SEA-01" + "§ 164.508(a)(2)(i)(B)": [ + "PRI-05.1" ], - "RTSE:SG1.SP2": [ - "SEA-01" + "§ 164.502(c)": [ + "PRI-05.4" ], - "RTSE:SG1.SP3": [ - "SEA-01" + "§ 164.502(d)(1)": [ + "PRI-05.4" ], - "RTSE:SG1.SP4": [ - "SEA-01" + "§ 164.504(g)(2)": [ + "PRI-05.4" ], - "RTSE:SG1.SP5": [ - "SEA-01" + "§ 164.506(a)": [ + "PRI-05.4" ], - "RTSE:SG2": [ - "SEA-01" + "§ 164.506(c)(1)": [ + "PRI-05.4", + "PRI-07" ], - "RTSE:SG2.SP1": [ - "SEA-01" + "§ 164.506(c)(5)": [ + "PRI-05.4" ], - "RTSE:SG2.SP2": [ - "SEA-01" + "§ 164.508(a)(1)": [ + "PRI-05.4", + "PRI-07" ], - "RTSE:SG3": [ - "SEA-01" + "§ 164.508(a)(2)(i)(C)": [ + "PRI-05.4" ], - "RTSE:GG2": [ - "SEA-01" + "§ 164.510(a)(1)(i)(A)": [ + "PRI-05.4" ], - "RTSE:GG2.GP2": [ - "SEA-01" + "§ 164.510(a)(1)(i)(B)": [ + "PRI-05.4" ], - "EC:SG2.SP1": [ - "SEA-01.3" + "§ 164.510(a)(1)(i)(C)": [ + "PRI-05.4" ], - "KIM:SG2.SP1": [ - "SEA-01.3" + "§ 164.510(a)(1)(i)(D)": [ + "PRI-05.4" ], - "RRD:SG1": [ - "SEA-01.3" + "§ 164.510(a)(1)(ii)(A)": [ + "PRI-05.4" ], - "RRD:SG1.SP1": [ - "SEA-01.3" + "§ 164.510(a)(1)(ii)(B)": [ + "PRI-05.4" ], - "RRD:SG2": [ - "SEA-01.3" + "§ 164.512(j)(1)(i)(A)": [ + "PRI-05.4" ], - "RRD:SG2.SP1": [ - "SEA-01.3" + "§ 164.512(j)(1)(i)(B)": [ + "PRI-05.4" ], - "RRD:SG2.SP2": [ - "SEA-01.3" + "§ 164.512(j)(1)(ii)": [ + "PRI-05.4" ], - "RRD:SG3": [ - "SEA-01.3" + "§ 164.512(j)(1)(ii)(A)": [ + "PRI-05.4" ], - "RRD:SG3.SP1": [ - "SEA-01.3" + "§ 164.512(j)(1)(ii)(B)": [ + "PRI-05.4" ], - "RRD:SG3.SP2": [ - "SEA-01.3" + "§ 164.512(j)(2)(i)": [ + "PRI-05.4" ], - "RRD:SG3.SP3": [ - "SEA-01.3" + "§ 164.512(j)(2)(ii)": [ + "PRI-05.4" ], - "RRD:GG2": [ - "SEA-01.3" + "§ 164.512(j)(3)": [ + "PRI-05.4" ], - "RRD:GG2.GP2": [ - "SEA-01.3" + "§ 164.512(j)(4)": [ + "PRI-05.4" ], - "RRM:SG1": [ - "SEA-01.3" + "§ 164.512(k)(1)(i)": [ + "PRI-05.4" ], - "RRM:SG1.SP1": [ - "SEA-01.3" + "§ 164.512(k)(1)(i)(A)": [ + "PRI-05.4" ], - "RRM:SG1.SP2": [ - "SEA-01.3" + "§ 164.512(k)(1)(i)(B)": [ + "PRI-05.4" ], - "RRM:SG1.SP3": [ - "SEA-01.3" + "§ 164.512(k)(1)(ii)": [ + "PRI-05.4" ], - "RRM:SG1.SP4": [ - "SEA-01.3" + "§ 164.512(k)(1)(iii)": [ + "PRI-05.4" ], - "RRM:SG1.SP5": [ - "SEA-01.3" + "§ 164.512(k)(1)(iv)": [ + "PRI-05.4" ], - "RRM:GG2": [ - "SEA-01.3" + "§ 164.512(k)(2)": [ + "PRI-05.4" ], - "RRM:GG2.GP2": [ - "SEA-01.3" + "§ 164.512(k)(3)": [ + "PRI-05.4" ], - "RTSE:SG3.SP1": [ - "SEA-01.3" + "§ 164.512(k)(4)": [ + "PRI-05.4" ], - "RTSE:SG3.SP2": [ - "SEA-01.3" + "§ 164.512(k)(4)(i)": [ + "PRI-05.4" ], - "TM:SG2.SP1": [ - "SEA-01.3" + "§ 164.512(k)(4)(ii)": [ + "PRI-05.4" ], - "ADM:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(4)(iii)": [ + "PRI-05.4" ], - "AM:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(i)": [ + "PRI-05.4" ], - "COMM:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(i)(A)": [ + "PRI-05.4" ], - "COMP:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(i)(B)": [ + "PRI-05.4" ], - "CTRL:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(i)(C)": [ + "PRI-05.4" ], - "EC:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(i)(D)": [ + "PRI-05.4" ], - "EF:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(i)(E)": [ + "PRI-05.4" ], - "EXD:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(i)(F)": [ + "PRI-05.4" ], - "FRM:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(ii)": [ + "PRI-05.4" ], - "HRM:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(5)(iii)": [ + "PRI-05.4" ], - "ID:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(6)(i)": [ + "PRI-05.4" ], - "IMC:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(6)(ii)": [ + "PRI-05.4" ], - "KIM:GG3.GP1": [ - "OPS-01.1" + "§ 164.512(k)(6)(ii)(1)": [ + "PRI-05.4" ], - "MA:GG3.GP1": [ - "OPS-01.1" + "§ 164.514(f)(2)(i)": [ + "PRI-05.4" ], - "MON:GG3.GP1": [ - "OPS-01.1" + "§ 164.514(g)": [ + "PRI-05.4" ], - "OPD:SG1": [ - "OPS-01.1" + "§ 164.530(i)(4)(ii)": [ + "PRI-05.4" ], - "OPD:SG1.SP1": [ - "OPS-01.1" + "§ 164.530(i)(4)(ii)(B)": [ + "PRI-05.4" ], - "OPD:GG3.GP1": [ - "OPS-01.1" + "§ 164.502(a)(2)(i)": [ + "PRI-06" ], - "OPF:GG3.GP1": [ - "OPS-01.1" + "§ 164.502(a)(2)(ii)": [ + "PRI-06" ], - "OTA:GG3.GP1": [ - "OPS-01.1" + "§ 164.514(h)(1)(i)": [ + "PRI-06" ], - "PM:GG3.GP1": [ - "OPS-01.1" + "§ 164.514(h)(1)(ii)": [ + "PRI-06" ], - "RISK:GG3.GP1": [ - "OPS-01.1" + "§ 164.524(a)(1)": [ + "PRI-06" ], - "RRD:GG3.GP1": [ - "OPS-01.1" + "§ 164.524(a)(1)(i)": [ + "PRI-06" ], - "RRM:GG3.GP1": [ - "OPS-01.1" + "§ 164.524(a)(1)(ii)": [ + "PRI-06" ], - "RTSE:GG3.GP1": [ - "OPS-01.1" + "§ 164.524(a)(1)(iii)": [ + "PRI-06" ], - "SC:GG3.GP1": [ - "OPS-01.1" + "§ 164.524(a)(1)(iii)(A)": [ + "PRI-06" ], - "TM:GG3.GP1": [ - "OPS-01.1" + "§ 164.524(a)(1)(iii)(B)": [ + "PRI-06" ], - "VAR:GG3.GP1": [ - "OPS-01.1" + "§ 164.524(a)(2)": [ + "PRI-06" ], - "OTA:SG1": [ - "SAT-01" + "§ 164.524(a)(2)(i)": [ + "PRI-06" ], - "OTA:SG1.SP1": [ - "SAT-01" + "§ 164.524(a)(2)(ii)": [ + "PRI-06" ], - "OTA:SG1.SP2": [ - "SAT-01" + "§ 164.524(a)(2)(iii)": [ + "PRI-06" ], - "OTA:SG1.SP3": [ - "SAT-01" + "§ 164.524(a)(2)(iv)": [ + "PRI-06" ], - "OTA:SG2": [ - "SAT-01" + "§ 164.524(a)(2)(v)": [ + "PRI-06" ], - "OTA:SG2.SP1": [ - "SAT-01" + "§ 164.524(a)(3)": [ + "PRI-06" ], - "OTA:SG2.SP2": [ - "SAT-01" + "§ 164.524(a)(3)(i)": [ + "PRI-06" ], - "OTA:SG2.SP3": [ - "SAT-01" + "§ 164.524(a)(3)(ii)": [ + "PRI-06" ], - "OTA:SG3": [ - "SAT-01" + "§ 164.524(a)(3)(iii)": [ + "PRI-06" ], - "OTA:SG3.SP1": [ - "SAT-01" + "§ 164.524(a)(4)": [ + "PRI-06" ], - "OTA:SG3.SP2": [ - "SAT-01" + "§ 164.524(b)(1)": [ + "PRI-06" ], - "OTA:SG3.SP3": [ - "SAT-01" + "§ 164.524(b)(2)(i)": [ + "PRI-06" ], - "OTA:SG4": [ - "SAT-01" + "§ 164.524(b)(2)(i)(A)": [ + "PRI-06" ], - "OTA:SG4.SP1": [ - "SAT-01" + "§ 164.524(b)(2)(i)(B)": [ + "PRI-06" ], - "OTA:SG4.SP2": [ - "SAT-01" + "§ 164.524(b)(2)(ii)": [ + "PRI-06" ], - "OTA:SG4.SP3": [ - "SAT-01" + "§ 164.524(b)(2)(ii)(A)": [ + "PRI-06" ], - "OTA:GG2": [ - "SAT-01" + "§ 164.524(b)(2)(ii)(B)": [ + "PRI-06" ], - "OTA:GG2.GP2": [ - "SAT-01" + "§ 164.524(c)": [ + "PRI-06" ], - "ADM:GG2.GP5": [ - "SAT-03" + "§ 164.524(c)(1)": [ + "PRI-06" ], - "AM:GG2.GP5": [ - "SAT-03" + "§ 164.524(c)(3)(i)": [ + "PRI-06" ], - "COMM:GG2.GP5": [ - "SAT-03" + "§ 164.524(c)(3)(ii)": [ + "PRI-06" ], - "COMP:GG2.GP5": [ - "SAT-03" + "§ 164.524(c)(4)": [ + "PRI-06" + ], + "§ 164.524(c)(4)(i)": [ + "PRI-06" + ], + "§ 164.524(c)(4)(ii)": [ + "PRI-06" + ], + "§ 164.524(c)(4)(iii)": [ + "PRI-06" + ], + "§ 164.524(c)(4)(iv)": [ + "PRI-06" ], - "CTRL:GG2.GP5": [ - "SAT-03" + "§ 164.524(d)": [ + "PRI-06" ], - "EC:GG2.GP5": [ - "SAT-03" + "§ 164.524(d)(1)": [ + "PRI-06" ], - "EF:GG2.GP5": [ - "SAT-03" + "§ 164.524(d)(2)": [ + "PRI-06" ], - "EXD:GG2.GP5": [ - "SAT-03" + "§ 164.526(a)(2)": [ + "PRI-06.1" ], - "FRM:GG2.GP5": [ - "SAT-03" + "§ 164.526(a)(2)(i)": [ + "PRI-06.1" ], - "HRM:GG2.GP5": [ - "SAT-03" + "§ 164.526(a)(2)(ii)": [ + "PRI-06.1" ], - "ID:GG2.GP5": [ - "SAT-03" + "§ 164.526(a)(2)(iii)": [ + "PRI-06.1" ], - "IMC:GG2.GP5": [ - "SAT-03" + "§ 164.526(a)(2)(iv)": [ + "PRI-06.1" ], - "KIM:GG2.GP5": [ - "SAT-03" + "§ 164.526(c)": [ + "PRI-06.2" ], - "MA:GG2.GP5": [ - "SAT-03" + "§ 164.526(c)(1)": [ + "PRI-06.2" ], - "MON:GG2.GP5": [ - "SAT-03" + "§ 164.526(c)(2)": [ + "PRI-06.2" ], - "OPD:GG2.GP5": [ - "SAT-03" + "§ 164.526(c)(3)": [ + "PRI-06.2" ], - "OPF:GG2.GP5": [ - "SAT-03" + "§ 164.526(c)(3)(i)": [ + "PRI-06.2" ], - "OTA:GG2.GP5": [ - "SAT-03" + "§ 164.526(c)(3)(ii)": [ + "PRI-06.2" ], - "PM:GG2.GP5": [ - "SAT-03" + "§ 164.524(d)(4)": [ + "PRI-06.3" ], - "RISK:GG2.GP5": [ - "SAT-03" + "§ 164.526(b)(2)(i)": [ + "PRI-06.4" ], - "RRD:GG2.GP5": [ - "SAT-03" + "§ 164.526(b)(2)(i)(A)": [ + "PRI-06.4" ], - "RRM:GG2.GP5": [ - "SAT-03" + "§ 164.526(b)(2)(i)(B)": [ + "PRI-06.4" ], - "RTSE:GG2.GP5": [ - "SAT-03" + "§ 164.526(b)(2)(ii)": [ + "PRI-06.4" ], - "SC:GG2.GP5": [ - "SAT-03" + "§ 164.526(b)(2)(ii)(A)": [ + "PRI-06.4" ], - "TM:GG2.GP5": [ - "SAT-03" + "§ 164.526(b)(2)(ii)(B)": [ + "PRI-06.4" ], - "VAR:GG2.GP5": [ - "SAT-03" + "§ 164.526(d)": [ + "PRI-06.4" ], - "GG2.GP5": [ - "SAT-03" + "§ 164.526(d)(1)": [ + "PRI-06.4" ], - "EXD:GG2": [ - "TPM-01" + "§ 164.526(d)(1)(i)": [ + "PRI-06.4" ], - "EXD:GG2.GP2": [ - "TPM-01" + "§ 164.526(d)(1)(ii)": [ + "PRI-06.4" ], - "EXD:SG1": [ - "TPM-01.1" + "§ 164.526(d)(1)(iii)": [ + "PRI-06.4" ], - "EXD:SG1.SP1": [ - "TPM-01.1" + "§ 164.526(d)(1)(iv)": [ + "PRI-06.4" ], - "EXD:SG1.SP2": [ - "TPM-02" + "§ 164.526(d)(2)": [ + "PRI-06.4" ], - "EXD:SG2": [ - "TPM-03" + "§ 164.526(d)(3)": [ + "PRI-06.4" ], - "EXD:SG2.SP1": [ - "TPM-03" + "§ 164.526(d)(4)": [ + "PRI-06.4" ], - "EXD:SG2.SP2": [ - "TPM-03" + "§ 164.526(d)(5)(i)": [ + "PRI-06.4" ], - "EXD:SG3": [ - "TPM-03" + "§ 164.526(d)(5)(ii)": [ + "PRI-06.4" ], - "EXD:SG3.SP1": [ - "TPM-03" + "§ 164.526(d)(5)(iii)": [ + "PRI-06.4" ], - "EXD:SG3.SP2": [ - "TPM-03" + "§ 164.526(e)": [ + "PRI-06.4", + "PRI-12" ], - "EXD:SG3.SP3": [ - "TPM-04.1" + "§ 164.526(f)": [ + "PRI-06.4", + "PRI-12" ], - "EXD:SG3.SP4": [ - "TPM-05" + "§ 164.530(d)(1)": [ + "PRI-06.4" ], - "EXD:SG4": [ - "TPM-08" + "§ 164.530(d)(2)": [ + "PRI-06.4" ], - "EXD:SG4.SP1": [ - "TPM-08" + "§ 164.524(c)(2)(i)": [ + "PRI-06.6" ], - "EXD:SG4.SP2": [ - "TPM-09" + "§ 164.524(c)(2)(ii)": [ + "PRI-06.6" ], - "VAR:SG1": [ - "VPM-01" + "§ 164.506(c)(2)": [ + "PRI-07" ], - "VAR:SG1.SP1": [ - "VPM-01" + "§ 164.506(c)(3)": [ + "PRI-07" ], - "VAR:SG1.SP2": [ - "VPM-01" + "§ 164.506(c)(4)": [ + "PRI-07" ], - "VAR:SG2": [ - "VPM-01" + "§ 164.508(a)(4)(i)": [ + "PRI-07" ], - "VAR:SG2.SP1": [ - "VPM-01" + "§ 164.504(e)(2)(i)": [ + "PRI-07.1", + "TPM-05" ], - "VAR:SG2.SP2": [ - "VPM-01" + "§ 164.504(e)(2)(ii)(A)": [ + "PRI-07.1" ], - "VAR:SG2.SP3": [ - "VPM-01" + "§ 164.504(e)(2)(ii)(B)": [ + "PRI-07.1" ], - "VAR:SG3": [ - "VPM-01" + "§ 164.504(e)(2)(ii)(C)": [ + "PRI-07.1" ], - "VAR:SG3.SP1": [ - "VPM-01" + "§ 164.504(e)(4)(i)": [ + "PRI-07.1" ], - "VAR:SG4": [ - "VPM-01" + "§ 164.504(e)(4)(i)(A)": [ + "PRI-07.1" ], - "VAR:SG4.SP1": [ - "VPM-01" + "§ 164.504(e)(4)(i)(B)": [ + "PRI-07.1" ], - "VAR:GG2": [ - "VPM-01" + "§ 164.504(e)(4)(i)(B)(ii)": [ + "PRI-07.1" ], - "VAR:GG2.GP2": [ - "VPM-01" - ] - }, - "usa-federal-law-coppa-2024": { - "Sec. 6502.(a)(1)": [ - "CPL-01", - "PRI-04" + "§ 164.504(e)(4)(i)(B)(ii)(A)": [ + "PRI-07.1" ], - "Sec. 6502.(b)(1)(D)": [ - "PRI-01.6", - "PRI-01.11" + "§ 164.524(d)(2)(i)": [ + "PRI-07.4" ], - "Sec. 6502.(b)(1)(A)(i)": [ - "PRI-02" + "§ 164.524(d)(2)(ii)": [ + "PRI-07.4" ], - "Sec. 6502.(b)(1)(B)(ii)": [ - "PRI-03.4", - "PRI-03.6" + "§ 164.524(d)(2)(iii)": [ + "PRI-07.4" ], - "Sec. 6502.(b)(1)(B)": [ - "PRI-03.6", - "PRI-06" + "§ 164.524(d)(3)": [ + "PRI-07.4" ], - "Sec. 6502.(b)(1)(A)(ii)": [ - "PRI-03.13" + "§ 164.512(i)(1)(i)(B)": [ + "PRI-10" ], - "Sec. 6502.(b)(1)(B)(i)": [ - "PRI-05.7" + "§ 164.512(i)(1)(i)(B)(1)": [ + "PRI-10" ], - "Sec. 6502.(b)(1)(B)(iii)": [ - "PRI-06" - ] - }, - "usa-federal-dhs-cisa-ssdaf-2024": { - "1": [ - "CFG-02.4", - "TDA-07", - "TDA-08", - "TDA-08.1" + "§ 164.512(i)(1)(i)(B)(2)": [ + "PRI-10" ], - "2": [ - "TDA-01.1", - "TDA-02.3", - "TDA-04.2", - "TDA-06.3", - "TDA-06.4", - "TDA-09", - "TDA-14.1", - "TDA-15", - "TDA-20" + "§ 164.512(i)(1)(i)(B)(3)": [ + "PRI-10" ], - "3": [ - "TDA-20", - "TDA-20.1", - "TDA-20.3" + "§ 164.528(a)(1)": [ + "PRI-14.1" ], - "4": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3" + "§ 164.528(a)(1)(i)": [ + "PRI-14.1" ], - "1.f": [ - "GOV-01", - "GOV-15", - "MON-01", - "IRO-01" + "§ 164.528(a)(1)(ii)": [ + "PRI-14.1" ], - "1.b.": [ - "MON-01", - "MON-03", - "MON-03.2" + "§ 164.528(a)(1)(iii)": [ + "PRI-14.1" ], - "1.b.i": [ - "MON-01.3", - "MON-02.7" + "§ 164.528(a)(1)(iv)": [ + "PRI-14.1" ], - "1.b.ii": [ - "MON-01.4", - "MON-02.7" + "§ 164.528(a)(1)(v)": [ + "PRI-14.1" ], - "1.e": [ - "CRY-01", - "TDA-02", - "TDA-02.4", - "TDA-06" + "§ 164.528(a)(1)(vi)": [ + "PRI-14.1" ], - "1.c": [ - "IAC-06" + "§ 164.528(a)(1)(vii)": [ + "PRI-14.1" ], - "1.d": [ - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-02.1", - "TDA-04.1", - "TDA-05", - "TDA-06.1", - "TDA-06.2", - "TDA-06.3", - "TDA-09.6" + "§ 164.528(a)(1)(viii)": [ + "PRI-14.1" ], - "4.b": [ - "TDA-01", - "VPM-01", - "VPM-02" + "§ 164.528(a)(1)(ix)": [ + "PRI-14.1" ], - "1.a": [ - "TDA-07", - "TDA-08" + "§ 164.528(b)": [ + "PRI-14.1" ], - "4.a": [ - "TDA-09", - "TDA-15" + "§ 164.528(b)(1)": [ + "PRI-14.1" ], - "4.c": [ - "THR-06", - "VPM-02" - ] - }, - "usa-federal-dhs-cisa-tic-3-0": { - "3.UNI.PEPAR": [ - "GOV-01", - "GOV-01.1", - "GOV-02", - "CPL-01.1", - "CPL-02" + "§ 164.528(b)(2)": [ + "PRI-14.1" ], - "3.PEP.WE.ACONT": [ - "GOV-02", - "IAC-01" + "§ 164.528(b)(2)(i)": [ + "PRI-14.1" ], - "3.UNI.IDMRP": [ - "GOV-02", - "END-01" + "§ 164.528(b)(2)(ii)": [ + "PRI-14.1" ], - "3.UNL.GPAUD": [ - "GOV-02", - "CPL-01" + "§ 164.528(b)(2)(iii)": [ + "PRI-14.1" ], - "3.PEP.DA.DINVE": [ - "AST-02", - "DCH-06.2" + "§ 164.528(b)(2)(iv)": [ + "PRI-14.1" ], - "3.UNI.INVENT": [ - "AST-02", - "AST-02.5" + "§ 164.528(b)(3)": [ + "PRI-14.1" ], - "3.PEP.DA.DAUTE": [ - "AST-02.8", - "DCH-14.3" + "§ 164.528(b)(3)(i)": [ + "PRI-14.1" ], - "3.UNI.IRPIH": [ - "BCD-01", - "IRO-01", - "IRO-02", - "IRO-04" + "§ 164.528(b)(3)(ii)": [ + "PRI-14.1" ], - "3.UNI.RESIL": [ - "BCD-01", - "SEA-01", - "SEA-01.2" + "§ 164.528(b)(3)(iii)": [ + "PRI-14.1" ], - "3.UNL.STEXE": [ - "BCD-04", - "IRO-05.1", - "IRO-06", - "TDA-09.5", - "VPM-07", - "VPM-10" + "§ 164.528(b)(4)(i)": [ + "PRI-14.1" ], - "3.UNI.BRECO": [ - "BCD-11", - "CFG-02.3" + "§ 164.528(b)(4)(i)(A)": [ + "PRI-14.1" ], - "3.PEP.EM.MCQUE": [ - "BCD-12.3" + "§ 164.528(b)(4)(i)(B)": [ + "PRI-14.1" ], - "3.PEP.RE.EEXPS": [ - "CAP-05" + "§ 164.528(b)(4)(i)(C)": [ + "PRI-14.1" ], - "3.PEP.RE.RDELI": [ - "CAP-06" + "§ 164.528(b)(4)(i)(D)": [ + "PRI-14.1" ], - "3.UNI.CMANA": [ - "CHG-01", - "CHG-02", - "CHG-04.1", - "CFG-01", - "CFG-02.2" + "§ 164.528(b)(4)(i)(E)": [ + "PRI-14.1" ], - "3.UNI.EUSSE": [ - "CLD-01", - "CLD-02", - "CLD-06", - "SEA-05" + "§ 164.528(b)(4)(i)(F)": [ + "PRI-14.1" ], - "3.PEP.EM.LCTPR": [ - "CFG-02", - "CFG-02.5", - "NET-18" + "§ 164.528(b)(4)(ii)": [ + "PRI-14.1" ], - "3.UNI.AACCO": [ - "MON-01", - "MON-01.4", - "MON-02.7", - "MON-03", - "MON-03.2" + "§ 164.528(c)(1)": [ + "PRI-14.1" ], - "3.UNI.CLMAN": [ - "MON-01", - "MON-01.2", - "MON-02" + "§ 164.528(c)(1)(i)": [ + "PRI-14.1" ], - "3.UNI.SAWAR": [ - "MON-01", - "MON-02.1" + "§ 164.528(c)(1)(ii)": [ + "PRI-14.1" ], - "3.UNL.CMREP": [ - "MON-01", - "MON-02.1", - "MON-02.2", - "MON-06" + "§ 164.528(c)(1)(ii)(A)": [ + "PRI-14.1" ], - "3.UNI.TSYNC": [ - "MON-07.1", - "SEA-20" + "§ 164.528(c)(1)(ii)(B)": [ + "PRI-14.1" ], - "3.UNI.DTDIS": [ - "MON-11.3", - "MON-16", - "IRO-03", - "SAT-03.2", - "THR-02", - "THR-11" + "§ 164.528(c)(2)": [ + "PRI-14.1" ], - "3.PEP.ID.BBASE": [ - "MON-16", - "SAT-03.2", - "THR-11" + "§ 164.528(d)": [ + "PRI-14.1" ], - "3.PEP.EM.EETRA": [ - "CRY-03" + "§ 164.528(d)(1)": [ + "PRI-14.1" ], - "3.PEP.UN.ECOMM": [ - "CRY-03" + "§ 164.528(d)(2)": [ + "PRI-14.1" ], - "3.PEP.DA.PDRES": [ - "CRY-05", - "DCH-01", - "DCH-01.2" + "§ 164.528(d)(3)": [ + "PRI-14.1" ], - "3.PEP.DA.PDTRA": [ - "CRY-05" + "§ 164.306(b)(2)(iii)": [ + "PRM-03" ], - "3.PEP.IN.CTLMO": [ - "CRY-12" + "§ 164.306(b)(2)(ii)": [ + "PRM-05", + "SEA-02" ], - "3.PEP.DA.DLABE": [ - "DCH-02", - "DCH-04", - "DCH-22.2" + "§ 164.306(b)(2)(iv)": [ + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-03", + "RSK-03.1", + "RSK-04", + "THR-09", + "THR-10" ], - "3.PEP.EM.PDPRO": [ - "END-04", - "IRO-15" + "§ 164.308(a)(1)(ii)(A)": [ + "RSK-04" ], - "3.PEP.FI.AMALW": [ - "END-04" + "§ 164.306(d)(3)(ii)(B)(2)": [ + "RSK-06.2" ], - "3.PEP.IN.EDRES": [ - "END-04" + "§ 164.103": [ + "SEA-02.1" ], - "3.PEP.IN.IDPSY": [ - "END-07" + "§ 164.304": [ + "SEA-02.1" ], - "3.PEP.SE.ACMIT": [ - "END-07", - "END-10" + "§ 164.402": [ + "SEA-02.1" ], - "3.PEP.WE.ACMIT": [ - "END-07", - "END-10" + "§ 164.501": [ + "SEA-02.1" ], - "3.PEP.EM.APPRO": [ - "END-08" + "§ 164.504(a)": [ + "SEA-02.1" ], - "3.PEP.EM.ASPRO": [ - "END-08" + "§ 164.316(b)(2)(ii)": [ + "OPS-01.1", + "OPS-03" ], - "3.PEP.UN.APPRO": [ - "END-08" + "§ 164.308(a)(5)(i)": [ + "SAT-01", + "SAT-02" ], - "3.PEP.UN.IVERI": [ - "END-14.3" + "§ 164.530(b)(2)(i)": [ + "SAT-02" ], - "3.PEP.UN.CTERM": [ - "END-14.4" + "§ 164.530(b)(2)(i)(A)": [ + "SAT-02" ], - "3.PEP.UN.LCTPR": [ - "END-14.5" + "§ 164.530(b)(2)(i)(B)": [ + "SAT-02" ], - "3.PEP.UN.MFPRO": [ - "END-14.5", - "END-14.6" + "§ 164.530(b)(2)(i)(C)": [ + "SAT-02" ], - "3.PEP.UN.MLPRO": [ - "END-14.5" + "§ 164.530(b)(2)(ii)": [ + "SAT-02" ], - "3.UNI.UATRA": [ - "HRS-01", - "HRS-02", - "HRS-02.1", - "HRS-03", - "HRS-03.1", - "SAT-01", - "SAT-02", + "§ 164.308(a)(5)(ii)(C)": [ "SAT-03" ], - "3.PEP.DA.ACONT": [ - "IAC-01" + "§ 164.308(a)(5)(ii)(D)": [ + "SAT-03" ], - "3.PEP.ID.EIAMA": [ - "IAC-01" + "§ 164.308(a)(5)(ii)(B)": [ + "SAT-03.2" ], - "3.PEP.NE.ACONT": [ - "IAC-01", - "NET-01" + "§ 164.308(a)(5)(ii)(A)": [ + "SAT-03.6" ], - "3.PEP.SE.ACONT": [ - "IAC-01" + "§ 164.308(b)(1)": [ + "TPM-01", + "TPM-04", + "TPM-05", + "TPM-05.2", + "TPM-05.4" ], - "3.PEP.ID.EINVE": [ - "IAC-01.2", - "IAC-15.1", - "IAC-16.1" + "§ 164.308(b)(2)": [ + "TPM-05", + "TPM-05.2", + "TPM-05.6" ], - "3.UNI.SAUTH": [ - "IAC-01.2", - "IAC-06", - "WEB-06" + "§ 164.314(a)(2)(iii)": [ + "TPM-05", + "TPM-05.2" ], - "3.PEP.ID.SIDEN": [ - "IAC-04", - "IAC-05" + "§ 164.314(b)(1)": [ + "TPM-05" ], - "3.PEP.ID.MAUTH": [ - "IAC-06" + "§ 164.314(b)(2)(i)": [ + "TPM-05" ], - "3.PEP.ID.SMANA": [ - "IAC-10", - "IAC-10.5", - "IAC-10.11" + "§ 164.314(b)(2)(ii)": [ + "TPM-05" ], - "3.PEP.ID.AAUTH": [ - "IAC-13" + "§ 164.314(b)(2)(iii)": [ + "TPM-05" ], - "3.PEP.IN.AACON": [ - "IAC-13" + "§ 164.502(a)(4)(i)": [ + "TPM-05" ], - "3.PEP.ID.CAUTH": [ - "IAC-13.3" + "§ 164.502(a)(4)(ii)": [ + "TPM-05" ], - "3.UNI.LPRIV": [ - "IAC-21" + "§ 164.502(e)(1)(i)": [ + "TPM-05", + "TPM-05.6" ], - "3.PEP.EM.E3AEP": [ - "IRO-15", - "NET-08" + "§ 164.502(e)(2)": [ + "TPM-05" ], - "3.PEP.EM.MFPRO": [ - "IRO-15", - "NET-20" + "§ 164.504(e)(2)(i)(A)": [ + "TPM-05" ], - "3.PEP.FI.DCHAM": [ - "IRO-15" + "§ 164.504(e)(2)(i)(B)": [ + "TPM-05" ], - "3.UNI.SADMI": [ - "MNT-01", - "MNT-05.3", - "OPS-03" + "§ 164.504(e)(2)(ii)(J)": [ + "TPM-05" ], - "3.PEP.RE.DDSPR": [ - "NET-02.1" + "§ 164.504(e)(4)(i)(B)(ii)(B)(1)": [ + "TPM-05" ], - "3.PEP.NE.NSEGM": [ - "NET-06" + "§ 164.504(e)(4)(i)(B)(ii)(B)(2)": [ + "TPM-05" ], - "3.PEP.NE.MICRO": [ - "NET-06.6" + "§ 164.504(f)(1)(i)": [ + "TPM-05" ], - "3.PEP.IN.NDRES": [ - "NET-08" + "§ 164.504(f)(2)(i)": [ + "TPM-05" ], - "3.PEP.NE.HCONT": [ - "NET-08.3" + "§ 164.504(f)(2)(ii)": [ + "TPM-05" ], - "3.PEP.NE.RCONT": [ - "NET-08.4" + "§ 164.504(f)(2)(ii)(A)": [ + "TPM-05" ], - "3.PEP.DO.DNVAC": [ - "NET-10.2", - "NET-18.5" + "§ 164.504(f)(2)(ii)(B)": [ + "TPM-05" ], - "3.PEP.DO.DNVAD": [ - "NET-10.2" + "§ 164.504(f)(2)(ii)(C)": [ + "TPM-05" ], - "3.PEP.DO.DNMON": [ - "NET-10.4" + "§ 164.504(f)(2)(ii)(D)": [ + "TPM-05" ], - "3.PEP.EN.RDACC": [ - "NET-14" + "§ 164.504(f)(2)(ii)(E)": [ + "TPM-05" ], - "3.PEP.EN.VPNET": [ - "NET-14", - "NET-14.3", - "NET-14.5", - "NET-14.6" + "§ 164.504(f)(2)(ii)(F)": [ + "TPM-05" ], - "3.PEP.DA.DLPRE": [ - "NET-17" + "§ 164.504(f)(2)(ii)(G)": [ + "TPM-05" ], - "3.PEP.EM.DLPRE": [ - "NET-17" + "§ 164.504(f)(2)(ii)(H)": [ + "TPM-05" ], - "3.PEP.FI.DLPRE": [ - "NET-17" + "§ 164.504(f)(2)(ii)(I)": [ + "TPM-05" ], - "3.PEP.SE.DLPRE": [ - "NET-17" + "§ 164.504(f)(2)(ii)(J)": [ + "TPM-05" ], - "3.PEP.UN.DLPRE": [ - "NET-17" + "§ 164.504(f)(2)(iii)(A)": [ + "TPM-05" ], - "3.PEP.WE.DLPRE": [ - "NET-17" + "§ 164.504(f)(2)(iii)(B)": [ + "TPM-05" ], - "3.PEP.DO.DNSIN": [ - "NET-18" + "§ 164.504(f)(2)(iii)(C)": [ + "TPM-05" ], - "3.PEP.DO.PDSER": [ - "NET-18" + "§ 164.504(f)(3)(i)": [ + "TPM-05" ], - "3.PEP.EM.CFILT": [ - "NET-18" + "§ 164.504(f)(3)(ii)": [ + "TPM-05" ], - "3.PEP.EM.MLPRO": [ - "NET-18" + "§ 164.504(f)(3)(iii)": [ + "TPM-05" ], - "3.PEP.SE.MCFIL": [ - "NET-18" + "§ 164.504(f)(3)(iv)": [ + "TPM-05" ], - "3.PEP.WE.CFILT": [ - "NET-18" + "§ 164.314(a)(2)(i)(C)": [ + "TPM-05.1" ], - "3.PEP.WE.DCFIL": [ - "NET-18" + "§ 164.314(b)(2)(iv)": [ + "TPM-05.1" ], - "3.PEP.WE.DREPF": [ - "NET-18" + "§ 164.410(a)(2)": [ + "TPM-05.1" ], - "3.PEP.WE.DRESF": [ - "NET-18" + "§ 164.410(b)": [ + "TPM-05.1" ], - "3.PEP.WE.MCFIL": [ - "NET-18" + "§ 164.410(c)(2)": [ + "TPM-05.1" ], - "3.PEP.WE.BINSP": [ - "NET-18.2" + "§ 164.314(a)(2)(i)(B)": [ + "TPM-05.2" ], - "3.PEP.SE.PCENF": [ - "NET-18.4" + "§ 164.502(e)(1)(ii)": [ + "TPM-05.2", + "TPM-05.6" ], - "3.PEP.WE.PCENF": [ - "NET-18.4" + "§ 164.504(e)(2)(ii)(D)": [ + "TPM-05.2" ], - "3.PEP.NE.IADEN": [ - "NET-18.6" + "§ 164.504(e)(2)(iii)": [ + "TPM-05.7" + ] + }, + "usa-federal-law-hipaa-security-rule-2013": { + "§ 164.306(a)(1)": [ + "GOV-01", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5" ], - "3.PEP.WE.BCONT": [ - "NET-18.7" + "§ 164.306(a)(2)": [ + "GOV-01" ], - "3.PEP.WE.APROX": [ - "NET-18.8" + "§ 164.306(a)(3)": [ + "GOV-01", + "DCH-01", + "RSK-01" ], - "3.PEP.WE.CDENY": [ - "NET-18.9" + "§ 164.316(a)": [ + "GOV-01", + "GOV-02" ], - "3.PEP.FI.CDREC": [ - "NET-19" + "§ 164.308(a)(1)(i)": [ + "GOV-02", + "CHG-01", + "CFG-01", + "MON-01", + "IRO-01" ], - "3.PE P.EM.EDRPR": [ - "NET-20.1" + "§ 164.308(a)(3)(i)": [ + "GOV-02", + "CFG-08", + "IAC-01", + "IAC-08", + "IAC-21" ], - "3.PEP.EM.SDENY": [ - "NET-20.2" + "§ 164.308(a)(4)(i)": [ + "GOV-02", + "IAC-01" ], - "3.PEP.EM.ARCHA": [ - "NET-20.3" + "§ 164.308(a)(4)(ii)(A)": [ + "GOV-02" ], - "3.PEP.EM.DSVIE": [ - "NET-20.4" + "§ 164.308(a)(6)(i)": [ + "GOV-02", + "IRO-01" ], - "3.PEP.EM.DSOEM": [ - "NET-20.5" + "§ 164.308(a)(7)(i)": [ + "GOV-02", + "BCD-01", + "IRO-01" ], - "3.PEP.EM.UDSOE": [ - "NET-20.5" + "§ 164.310(a)(1)": [ + "GOV-02", + "PES-01" ], - "3.PEP.EM.EOEMA": [ - "NET-20.6" + "§ 164.310(a)(2)(ii)": [ + "GOV-02", + "PES-01", + "PES-03" ], - "3.PEP.EM.AEPRO": [ - "NET-20.7" + "§ 164.310(a)(2)(iv)": [ + "GOV-02", + "MNT-01", + "MNT-02", + "PES-01" ], - "3.PEP.EM.ELABE": [ - "NET-20.8" + "§ 164.310(b)": [ + "GOV-02", + "END-01", + "HRS-05", + "HRS-05.1", + "HRS-05.3", + "PES-03.4", + "PES-04", + "OPS-01.1", + "OPS-03" ], - "3.PEP.EM.UTIPP": [ - "NET-20.9" + "§ 164.310(d)(1)": [ + "GOV-02", + "AST-01", + "AST-11", + "DCH-01", + "DCH-03", + "DCH-07", + "DCH-07.1", + "DCH-13.2", + "MNT-01", + "MNT-04.3" ], - "3.PEP.EN.CMONI": [ - "PRM-01", - "PRM-03" + "§ 164.310(d)(2)(i)": [ + "GOV-02", + "AST-01", + "AST-09" ], - "3.UNL.RLMAN": [ - "PRM-07", - "SEA-07.1" + "§ 164.312(a)(1)": [ + "GOV-02", + "HRS-02", + "HRS-03", + "IAC-01", + "IAC-08", + "IAC-21" ], - "3 UNL.SCRMA": [ - "RSK-09" + "§ 164.312(c)(1)": [ + "GOV-02", + "DCH-01", + "DCH-01.2" ], - "3.PEP.IN.DPLAT": [ - "SEA-11" + "§ 164.316(b)(1)(i)": [ + "GOV-02" ], - "3.PEP.EN.ACONT": [ - "SEA-21" + "§ 164.306(d)(3)(ii)(B)(1)": [ + "GOV-02.1" ], - "3.PEP.EN.SOARE": [ - "OPS-06" + "§ 164.316(b)(1)(ii)": [ + "GOV-03", + "CPL-03" ], - "3.PEP.EN.SITDE": [ - "OPS-07" + "§ 164.316(b)(2)(iii)": [ + "GOV-03", + "CPL-02" ], - "3.UNI.ETINT": [ - "THR-01", - "THR-03" + "§ 164.308(a)(2)": [ + "GOV-04" ], - "3.UNI.VMANG": [ - "THR-03", - "VPM-01", - "VPM-04", - "VPM-06" + "§ 164.306(b)(2)(i)": [ + "GOV-08", + "PRM-06" ], - "3.UNI.PMANA": [ - "VPM-05" - ] - }, - "usa-federal-dhs-cisa-cpg-2-0": { - "1.B": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "§ 164.306(b)(1)": [ + "GOV-09", + "GOV-15", + "SEA-01", + "SEA-02", + "SEA-03" ], - "1.C": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "§ 164.308(a)(1)(ii)(B)": [ + "GOV-09", + "GOV-15.2" ], - "4.A": [ - "GOV-06", - "IRO-10" + "§ 164.306(d)(3)(ii)(A)": [ + "GOV-15.2" ], - "1.A": [ + "§ 164.308(a)(7)(ii)(E)": [ "AST-01", - "AST-02", - "TPM-01.1" + "AST-01.1", + "BCD-02", + "TPM-02" ], - "2.P": [ - "AST-04", - "AST-04.2" + "§ 164.310(d)(2)(iii)": [ + "AST-02", + "AST-02.1", + "AST-02.9", + "AST-03", + "AST-03.1" ], - "2.F": [ - "AST-27", - "NET-04", - "NET-04.1", - "NET-06" + "§ 164.310(d)(2)(ii)": [ + "AST-09", + "DCH-09" ], - "5.A": [ + "§ 164.308(a)(7)(ii)(C)": [ "BCD-01", - "BCD-02.1", - "BCD-02.2", - "IRO-01", - "IRO-02" + "BCD-02.2" ], - "2.R": [ - "BCD-11", - "BCD-11.1", - "BCD-11.2" + "§ 164.308(a)(7)(ii)(D)": [ + "BCD-04", + "BCD-05" ], - "2.Q": [ - "CHG-01", - "CFG-01", - "CFG-05", - "CFG-05.2", - "IAO-01", - "IAO-02", - "IAO-06", - "IAO-07" + "§ 164.310(a)(2)(i)": [ + "BCD-09.2", + "HRS-03", + "PES-02", + "PES-02.1" ], - "2.A": [ - "CFG-01", - "CFG-02", - "IAC-10.8" + "§ 164.308(a)(7)(ii)(A)": [ + "BCD-11" ], - "2.O": [ - "CFG-01", - "CFG-02", - "CFG-02.1", - "CFG-02.7" + "§ 164.310(d)(2)(iv)": [ + "BCD-11" ], - "1.E": [ - "CFG-02", - "RSK-06.2", - "SEA-01", - "SEA-03", - "VPM-01.1", - "VPM-02", - "VPM-04" + "§ 164.308(a)(7)(ii)(B)": [ + "BCD-12" ], - "2.B": [ - "CFG-02", - "IAC-10", - "IAC-10.1" + "§ 164.306(c)": [ + "CPL-01" ], - "2.G": [ - "CFG-02", - "MON-01.4", - "MON-02", - "MON-02.2", - "MON-16" + "§ 164.306(d)(1)": [ + "CPL-01" ], - "2.H": [ + "§ 164.306(d)(2)": [ + "CPL-01" + ], + "§ 164.314(a)(1)": [ + "CPL-01" + ], + "§ 164.314(a)(2)(ii)": [ + "CPL-01" + ], + "§ 164.306(d)(3)(i)": [ + "CPL-02", + "CPL-03", + "CPL-03.2" + ], + "§ 164.306(e)": [ + "CPL-03.2" + ], + "§ 164.308(a)(8)": [ + "CPL-03.2", + "IAO-01.1", + "IAO-02" + ], + "§ 164.312(a)(2)(iii)": [ "CFG-02", - "IAC-06" + "IAC-25" ], - "2.K": [ + "§ 164.312(e)(1)": [ "CFG-02", - "CFG-02.1", - "CRY-01", "CRY-03", - "CRY-04", - "CRY-05", - "SEA-02.3" + "NET-01" ], - "2.N": [ + "§ 164.312(e)(2)(i)": [ "CFG-02", - "END-10" + "CRY-04", + "NET-01" ], - "2.V": [ + "§ 164.312(e)(2)(ii)": [ "CFG-02", - "DCH-12", - "EMB-04" - ], - "2.W": [ - "CFG-02.5", - "CFG-03", - "NET-04", - "NET-04.1" + "CRY-01", + "OPS-03" ], - "2.X": [ - "CFG-02.5", - "NET-02", - "NET-04", - "NET-04.1", - "NET-06.5" + "§ 164.312(c)(2)": [ + "CFG-08", + "CFG-08.1", + "MON-01.7", + "MON-01.15", + "MON-16" ], - "1.D": [ + "§ 164.308(a)(1)(ii)(D)": [ "MON-01", - "MON-02.3", - "EMB-01", - "IRO-09", - "IRO-13", - "PRM-08", - "SAT-05" + "MON-01.8", + "IRO-09" ], - "2.T": [ + "§ 164.312(b)": [ "MON-01", - "MON-01.3", "MON-01.4", "MON-01.8", - "MON-01.12", - "MON-02", - "MON-02.1", - "MON-02.2", - "MON-02.3", - "MON-05" + "MON-01.16", + "MON-03", + "MON-03.2", + "MON-16" ], - "2.U": [ - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-10" + "§ 164.312(a)(2)(iv)": [ + "CRY-01" ], - "2.L": [ - "DCH-01", - "DCH-01.2", - "DCH-01.4", - "DCH-02", - "DCH-03", - "IAC-01", + "§ 164.316(b)(2)(i)": [ + "DCH-18" + ], + "§ 164.310(c)": [ + "END-02", + "PES-03", + "PES-03.4", + "PES-04", + "PES-04.1" + ], + "§ 164.308(a)(3)(ii)(A)": [ + "HRS-01", + "IAC-07.1", "IAC-08", - "IAC-10", - "IAC-10.1", - "IAC-10.11" + "IAC-28.1" ], - "2.D": [ + "§ 164.312(d)": [ + "HRS-01", + "HRS-04", + "IAC-28", + "IAC-28.2", + "IAC-28.3", + "TPM-01" + ], + "§ 164.308(a)(3)(ii)(B)": [ + "HRS-02", + "HRS-03", + "IAC-17" + ], + "§ 164.308(a)(1)(ii)(C)": [ + "HRS-07" + ], + "§ 164.308(a)(3)(ii)(C)": [ "HRS-08", "HRS-09", "IAC-07", - "IAC-07.1", "IAC-07.2" ], - "2.E": [ - "IAC-01", - "IAC-08", - "IAC-16" + "§ 164.308(a)(4)(ii)(B)": [ + "IAC-01" + ], + "§ 164.310(a)(2)(iii)": [ + "IAC-01", + "PES-02", + "PES-03", + "PES-06" + ], + "§ 164.312(a)(2)(i)": [ + "IAC-02", + "IAC-09" + ], + "§ 164.308(a)(4)(ii)(C)": [ + "IAC-08" + ], + "§ 164.312(a)(2)(ii)": [ + "IAC-15", + "IAC-15.2", + "IAC-15.9" + ], + "§ 164.308(a)(6)(ii)": [ + "IRO-02" + ], + "§ 164.308(b)(3)": [ + "IAO-03.2", + "TPM-05" + ], + "§ 164.306(b)(2)(iii)": [ + "PRM-03" ], - "2.C": [ - "IAC-10.9" + "§ 164.306(b)(2)(ii)": [ + "PRM-05", + "SEA-02" ], - "2.S": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-04.2", - "IRO-04.3", - "IRO-06" + "§ 164.306(b)(2)(iv)": [ + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-03", + "RSK-03.1", + "RSK-04", + "THR-09", + "THR-10" ], - "3.A": [ - "IRO-03", - "THR-01", - "THR-02", - "THR-03", - "THR-09" + "§ 164.308(a)(1)(ii)(A)": [ + "RSK-04" ], - "1.F": [ - "IAO-01", - "IAO-01.1", - "IAO-02", - "IAO-02.2", - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-07" + "§ 164.306(d)(3)(ii)(B)(2)": [ + "RSK-06.2" ], - "2.M": [ - "NET-10.3", - "NET-13", - "NET-18" + "§ 164.316(b)(2)(ii)": [ + "OPS-01.1", + "OPS-03" ], - "2.I": [ + "§ 164.308(a)(5)(i)": [ "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.6" + "SAT-02" ], - "2.J": [ - "SAT-03", - "SAT-03.4", - "SAT-03.5" + "§ 164.308(a)(5)(ii)(C)": [ + "SAT-03" ], - "1.G": [ - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-05", - "TPM-05.1", - "THR-01" + "§ 164.308(a)(5)(ii)(D)": [ + "SAT-03" ], - "1.H": [ + "§ 164.308(a)(5)(ii)(B)": [ + "SAT-03.2" + ], + "§ 164.308(a)(5)(ii)(A)": [ + "SAT-03.6" + ], + "§ 164.308(b)(1)": [ "TPM-01", - "TPM-01.1", - "TPM-03", - "TPM-03.3", "TPM-04", "TPM-05", - "TPM-05.7", - "TPM-08", - "THR-01" + "TPM-05.2", + "TPM-05.4" ], - "1.I": [ - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-10" + "§ 164.308(b)(2)": [ + "TPM-05", + "TPM-05.2", + "TPM-05.6" ], - "4.B": [ - "THR-06", - "THR-06.1" + "§ 164.314(a)(2)(iii)": [ + "TPM-05", + "TPM-05.2" ], - "4.C": [ - "THR-06.1" + "§ 164.314(b)(1)": [ + "TPM-05" + ], + "§ 164.314(b)(2)(i)": [ + "TPM-05" + ], + "§ 164.314(b)(2)(ii)": [ + "TPM-05" + ], + "§ 164.314(b)(2)(iii)": [ + "TPM-05" + ], + "§ 164.314(a)(2)(i)(C)": [ + "TPM-05.1" + ], + "§ 164.314(b)(2)(iv)": [ + "TPM-05.1" + ], + "§ 164.314(a)(2)(i)(B)": [ + "TPM-05.2" ] }, - "usa-federal-fbi-cjis-6-0": { - "5.1": [ + "usa-federal-irs-1075-2021": { + "PM-1": [ "GOV-01", - "DCH-14" + "GOV-02", + "GOV-03" ], - "5.1.1": [ - "GOV-01", - "DCH-14" + "2.C.2": [ + "GOV-02" + ], + "2.C.2-1": [ + "GOV-02" + ], + "2.C.2-2": [ + "GOV-02" + ], + "2.C.2-3": [ + "GOV-02" + ], + "2.C.2-4": [ + "GOV-02" + ], + "2.C.2-5": [ + "GOV-02" + ], + "2.C.2-6": [ + "GOV-02" + ], + "2.C.2-7": [ + "GOV-02" + ], + "2.C.2-8": [ + "GOV-02" + ], + "2.C.2-9": [ + "GOV-02" + ], + "2.C.2-10": [ + "GOV-02" + ], + "2.C.2-11": [ + "GOV-02" + ], + "2.C.2-12": [ + "GOV-02" + ], + "2.C.2-13": [ + "GOV-02" + ], + "2.C.2-14": [ + "GOV-02" + ], + "2.C.2-15": [ + "GOV-02" + ], + "2.C.2-16": [ + "GOV-02" + ], + "2.C.2-17": [ + "GOV-02" + ], + "2.C.2-18": [ + "GOV-02" ], "AC-1": [ "GOV-02", @@ -197154,6 +215565,12 @@ "GOV-03", "HRS-01" ], + "PT-1": [ + "GOV-02", + "GOV-03", + "PRI-01", + "SEA-01" + ], "RA-1": [ "GOV-02", "GOV-03", @@ -197181,41 +215598,88 @@ "GOV-03", "TPM-01" ], - "PL-9": [ + "PM-2": [ + "GOV-04" + ], + "PM-29": [ "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "RSK-01", + "RSK-09" ], "IR-6": [ "GOV-06", "IRO-10", "IRO-14" ], + "3.3.1.l": [ + "GOV-15", + "GOV-15.1" + ], + "2.B.7.1": [ + "AST-01" + ], + "2.B.7.2": [ + "AST-01" + ], + "2.B.7.3": [ + "AST-01" + ], + "PM-5": [ + "AST-01", + "AST-02" + ], + "CM-8(CE-1)": [ + "AST-02.1" + ], + "CM-8(CE-3)": [ + "AST-02.2" + ], + "CM-8(CE-3).a": [ + "AST-02.2" + ], + "CM-8(CE-3).b": [ + "AST-02.2" + ], + "CM-8(CE-3).b.1": [ + "AST-02.2" + ], + "CM-8(CE-3).b.2": [ + "AST-02.2" + ], + "CM-8(CE-3).b.3": [ + "AST-02.2" + ], "CM-8": [ - "AST-02", "AST-02.3" ], - "CM-8(1)": [ - "AST-02.1" + "SC-18(CE-2)": [ + "AST-02.7", + "END-10" ], - "CM-8(3)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "2.A.2": [ + "AST-02.8" + ], + "CM-13": [ + "AST-02.8" + ], + "SA-4(CE-12)": [ + "AST-03", + "DCH-01.1", + "PRI-09" + ], + "SA-4(CE-12).a": [ + "AST-03" ], "PL-2": [ "AST-04", "IAO-03", "IAO-03.1" ], - "SA-4(1)": [ + "SA-4(CE-1)": [ "AST-04", "TDA-04.1" ], - "SA-4(2)": [ + "SA-4(CE-2)": [ "AST-04", "TDA-04.1", "TDA-20" @@ -197224,16 +215688,31 @@ "AST-04.1", "TDA-04" ], - "SR-12": [ + "2.F.3.1": [ "AST-09" ], - "5.20.1.3": [ - "AST-14.1" - ], "SR-10": [ "AST-15.1", "TDA-11" ], + "3.3.5": [ + "AST-23" + ], + "3.3.5.a-1": [ + "AST-23" + ], + "3.3.5.b-1": [ + "AST-23" + ], + "3.3.5.a-2": [ + "AST-23" + ], + "3.3.5.b-2": [ + "AST-23" + ], + "3.3.5.c-2": [ + "AST-23" + ], "CP-2": [ "BCD-01", "BCD-06" @@ -197243,13 +215722,13 @@ "BCD-01.4", "BCD-12" ], - "CP-2(1)": [ + "CP-2(CE-1)": [ "BCD-01.1" ], - "CP-2(8)": [ + "CP-2(CE-8)": [ "BCD-02" ], - "CP-2(3)": [ + "CP-2(CE-3)": [ "BCD-02.1", "BCD-02.3" ], @@ -197260,80 +215739,48 @@ "BCD-04", "BCD-05" ], - "CP-4(1)": [ + "CP-4(CE-1)": [ "BCD-04.1" ], - "CP-6": [ - "BCD-08" - ], - "CP-6(1)": [ - "BCD-08.1" - ], - "CP-6(3)": [ - "BCD-08.2" - ], - "CP-7": [ - "BCD-09" - ], - "CP-7(1)": [ - "BCD-09.1" - ], - "CP-7(2)": [ - "BCD-09.2" - ], - "CP-7(3)": [ - "BCD-09.3" - ], - "CP-8": [ - "BCD-10" - ], - "CP-8(2)": [ - "BCD-10" - ], - "CP-8(1)": [ - "BCD-10.1" - ], "CP-9": [ "BCD-11" ], - "CP-9(1)": [ - "BCD-11.1" - ], - "CP-9(8)": [ + "CP-9(CE-8)": [ "BCD-11.4" ], - "SC-28(1)": [ + "SC-28(CE-1)": [ "BCD-11.4", "CRY-04", "CRY-05", "DCH-07.2" ], - "CP-10(2)": [ + "CP-10(CE-2)": [ "BCD-12.1" ], - "SC-5": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" - ], "CM-3": [ "CHG-01", "CHG-02" ], - "CM-3(2)": [ - "CHG-02.2", - "CHG-06" + "CM-3(CE-2)": [ + "CHG-02.2" ], - "CM-3(4)": [ + "CM-3(CE-4)": [ "CHG-02.3" ], "CM-4": [ "CHG-03" ], "CM-5": [ - "CHG-04", - "END-03.2" + "CHG-04" + ], + "CM-5(IRS-Defined)-1": [ + "CHG-04" + ], + "CM-5(IRS-Defined)-2": [ + "CHG-04" + ], + "CM-14": [ + "CHG-04.2" ], "AC-5": [ "CHG-04.3", @@ -197341,38 +215788,52 @@ "NET-12", "TDA-18" ], + "CM-5(CE-5)": [ + "CHG-04.4" + ], + "CM-5(CE-5).a": [ + "CHG-04.4" + ], + "CM-5(CE-5).b": [ + "CHG-04.4" + ], "CM-9": [ "CHG-05", "CFG-01" ], - "4.1.1": [ - "CPL-01", - "DCH-02" + "3.3.1.h": [ + "CLD-02" ], - "4.2.1": [ - "CPL-01", - "DCH-02" + "SA-9(CE-5)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" ], - "4.2.2": [ - "CPL-01", - "DCH-02", - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "SA-9(CE-8)": [ + "CLD-09", + "DCH-19" ], - "4.3": [ - "CPL-01", - "DCH-02", - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "2.E.6.1": [ + "CPL-01" + ], + "2.D.9": [ + "CPL-01.1" + ], + "2.D.3": [ + "CPL-02" + ], + "2.D.8": [ + "CPL-02" + ], + "3.3.1.i": [ + "CPL-02" ], "CA-7": [ "CPL-02" ], - "CA-7(1)": [ + "PM-14": [ "CPL-02", - "CPL-03.1" + "PRI-08" ], "CA-2": [ "CPL-03", @@ -197381,51 +215842,121 @@ "IAO-06", "PRM-04" ], + "CA-7(CE-1)": [ + "CPL-03.1" + ], "RA-3": [ "CPL-03.2", "RSK-04" ], + "3.3.8.b": [ + "CFG-02" + ], "CM-2": [ "CFG-02", "CFG-02.1" ], + "CM-2(IRS-Defined)": [ + "CFG-02", + "CFG-02.1" + ], "CM-6": [ "CFG-02", "CFG-02.7" ], - "PL-10": [ - "CFG-02" + "CM-6(IRS-Defined)": [ + "CFG-02", + "CFG-02.7" ], "SA-8": [ "CFG-02", "SEA-01" ], - "CM-2(2)": [ + "CM-2(CE-2)": [ "CFG-02.2" ], - "CM-2(3)": [ + "CM-2(CE-3)": [ "CFG-02.3" ], - "CM-2(7)": [ + "CM-2(CE-7)": [ "CFG-02.5" ], - "PL-11": [ - "CFG-02.9" + "CM-2(CE-7).a": [ + "CFG-02.5" + ], + "CM-2(CE-7).b": [ + "CFG-02.5" + ], + "CM-7(CE-9)": [ + "CFG-02.5" + ], + "CM-7(CE-9).a": [ + "CFG-02.5" + ], + "CM-7(CE-9).b": [ + "CFG-02.5" + ], + "CM-7(CE-9).c": [ + "CFG-02.5" ], "CM-7": [ "CFG-03" ], - "CM-7(1)": [ + "CM-7(IRS-Defined)": [ + "CFG-03" + ], + "CM-7(CE-1)": [ "CFG-03.1" ], - "CM-7(2)": [ - "CFG-03.2", - "SEA-06" + "CM-7(CE-1).a": [ + "CFG-03.1" ], - "CM-7(5)": [ + "CM-7(CE-1).b": [ + "CFG-03.1" + ], + "CM-7(CE-5)": [ "CFG-03.3" ], - "SC-7(7)": [ + "CM-7(CE-5).a": [ + "CFG-03.3" + ], + "CM-7(CE-5).b": [ + "CFG-03.3" + ], + "CM-7(CE-5).c": [ + "CFG-03.3" + ], + "SC-7(CE-7)": [ + "CFG-03.4" + ], + "SC-7(CE-7).a": [ + "CFG-03.4" + ], + "SC-7(CE-7).b": [ + "CFG-03.4" + ], + "SC-7(CE-7).b.1": [ + "CFG-03.4" + ], + "SC-7(CE-7).b.2": [ + "CFG-03.4" + ], + "SC-7(CE-7).b.3": [ + "CFG-03.4" + ], + "SC-7(CE-7).c": [ + "CFG-03.4" + ], + "SC-7(CE-7).c.1": [ + "CFG-03.4" + ], + "SC-7(CE-7).c.2": [ + "CFG-03.4" + ], + "SC-7(CE-7).c.3": [ + "CFG-03.4" + ], + "SC-7(CE-7).c.4": [ "CFG-03.4" ], "CM-10": [ @@ -197435,42 +215966,74 @@ "CFG-05", "END-03" ], + "AC-3(CE-11)": [ + "CFG-08" + ], "SI-4": [ "MON-01", "MON-02", "NET-12", "TDA-18" ], - "SI-4(2)": [ + "SI-4(IRS-Defined)": [ + "MON-01" + ], + "SI-4(CE-1)": [ + "MON-01.1" + ], + "SI-4(CE-2)": [ "MON-01.2" ], - "SI-4(4)": [ + "SI-4(CE-4)": [ "MON-01.3" ], - "SI-4(5)": [ + "SI-4(CE-4).a": [ + "MON-01.3" + ], + "SI-4(CE-4).b": [ + "MON-01.3" + ], + "SI-4(CE-5)": [ "MON-01.4" ], + "SI-4(CE-24)": [ + "MON-01.7", + "MON-11.3" + ], "AU-2": [ "MON-01.8", "MON-02" ], + "SI-4(CE-12)": [ + "MON-01.12", + "MON-05.1" + ], "AU-6": [ "MON-02", "MON-02.6" ], - "AU-6(3)": [ + "AU-6(CE-3)": [ + "MON-02.1" + ], + "AU-6(CE-9)": [ "MON-02.1" ], + "AU-6(CE-7)": [ + "MON-02.5" + ], + "AU-12(CE-1)": [ + "MON-02.7" + ], "AU-3": [ "MON-03" ], - "AU-3(1)": [ + "AU-3(CE-1)": [ "MON-03.1" ], - "AU-6(1)": [ + "AU-6(CE-1)": [ "MON-03.1" ], - "AU-3(3)": [ + "AU-3(CE-3)": [ "MON-03.5" ], "AU-4": [ @@ -197479,10 +216042,13 @@ "AU-5": [ "MON-05" ], + "AU-5(CE-1)": [ + "MON-05.2" + ], "AU-7": [ "MON-06" ], - "AU-7(1)": [ + "AU-7(CE-1)": [ "MON-06" ], "AU-12": [ @@ -197492,16 +216058,75 @@ "MON-07", "SEA-20" ], + "SC-45": [ + "MON-07.1" + ], + "SC-45(CE-1)": [ + "MON-07.1" + ], + "SC-45(CE-1).a": [ + "MON-07.1" + ], + "SC-45(CE-1).b": [ + "MON-07.1" + ], "AU-9": [ "MON-08" ], - "AU-9(4)": [ + "AU-9(CE-4)": [ "MON-08.2" ], "AU-11": [ "MON-10" ], - "SC-8(1)": [ + "SI-4(CE-18)": [ + "MON-11.1", + "NET-17" + ], + "AU-16": [ + "MON-14" + ], + "AU-16(CE-1)": [ + "MON-14" + ], + "AU-16(CE-2)": [ + "MON-14.1" + ], + "AC-2(CE-12)": [ + "MON-16" + ], + "AC-2(CE-12).a": [ + "MON-16" + ], + "AC-2(CE-12).b": [ + "MON-16" + ], + "SI-4(CE-11)": [ + "MON-16" + ], + "2.E.2": [ + "CRY-01", + "DCH-17" + ], + "2.E.3": [ + "CRY-01" + ], + "2.E.3-1": [ + "CRY-01" + ], + "2.E.3-2": [ + "CRY-01" + ], + "2.E.3-3": [ + "CRY-01" + ], + "2.E.3-4": [ + "CRY-01" + ], + "2.E.3-5": [ + "CRY-01" + ], + "SC-8(CE-1)": [ "CRY-01", "CRY-01.1", "CRY-03" @@ -197515,17 +216140,30 @@ "CRY-02", "IAC-12" ], + "3.3.1.d": [ + "CRY-03" + ], "SC-8": [ "CRY-03", "CRY-04" ], + "SC-8(IRS-Defined)": [ + "CRY-03", + "CRY-04" + ], + "2.B.6-1": [ + "CRY-05", + "DCH-04" + ], + "3.3.1.e": [ + "CRY-05" + ], "SC-28": [ "CRY-05", "END-02" ], "AC-18": [ - "CRY-07", - "NET-15" + "CRY-07" ], "SC-12": [ "CRY-08" @@ -197533,36 +216171,131 @@ "SC-17": [ "CRY-08" ], - "4.2.3.1": [ + "SA-9(CE-6)": [ + "CRY-09.7" + ], + "SC-23(CE-5)": [ + "CRY-11" + ], + "2.B.2": [ "DCH-01", - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "PES-01" ], - "4.2.3.3": [ - "DCH-01.1", - "DCH-03.1" + "2.B.4": [ + "DCH-01", + "DCH-07", + "DCH-07.1" ], - "4.2.4": [ + "2.B.5": [ + "DCH-01", + "PES-12" + ], + "2.C.5": [ + "DCH-01", + "DCH-01.2" + ], + "2.C.5.1": [ + "DCH-01" + ], + "2.C.5.1-1": [ + "DCH-01" + ], + "2.C.5.1-2": [ + "DCH-01" + ], + "2.C.5.1-3": [ + "DCH-01" + ], + "2.C.7": [ + "DCH-01.2" + ], + "2.C.7-1": [ + "DCH-01.2" + ], + "2.C.7-2": [ + "DCH-01.2" + ], + "2.C.8": [ + "DCH-01.2" + ], + "2.C.8.1": [ + "DCH-01.2" + ], + "2.C.8.2": [ "DCH-01.2" ], "MP-2": [ "DCH-03", "END-01" ], + "AC-3(CE-9)": [ + "DCH-03.3" + ], + "AC-3(CE-9).a": [ + "DCH-03.3" + ], + "AC-3(CE-9).b": [ + "DCH-03.3" + ], "MP-3": [ "DCH-04", "DCH-04.1" ], + "2.D.5": [ + "DCH-06" + ], "MP-4": [ "DCH-06" ], + "2.B.6": [ + "DCH-06.1" + ], + "2.B.6-2": [ + "DCH-06.1" + ], + "2.B.6-3": [ + "DCH-06.1" + ], + "2.B.4.1": [ + "DCH-07" + ], "MP-5": [ "DCH-07" ], + "MP-5(CE-3)": [ + "DCH-07.1" + ], + "2.F.3-1": [ + "DCH-08" + ], + "2.F.3-2": [ + "DCH-08" + ], + "2.F.3.1-1": [ + "DCH-09" + ], + "2.F.3.1-2": [ + "DCH-09" + ], + "2.F.3.1-3": [ + "DCH-09" + ], + "3.3.1.j": [ + "DCH-09" + ], + "2.F.4-2": [ + "DCH-09.1" + ], + "MP-6(CE-1)": [ + "DCH-09.1" + ], "MP-6": [ - "DCH-08", - "DCH-09", + "DCH-09.3" + ], + "MP-6(IRS-Defined)-1": [ + "DCH-09.3" + ], + "MP-6(IRS-Defined)-2": [ "DCH-09.3" ], "MP-7": [ @@ -197570,46 +216303,59 @@ "DCH-10.2", "DCH-18" ], + "MP-7(IRS-Defined)": [ + "DCH-10" + ], + "MP-7(IRS-Defined).a": [ + "DCH-10" + ], + "MP-7(IRS-Defined).b": [ + "DCH-10" + ], "AC-20": [ "DCH-13" ], - "AC-20(1)": [ - "DCH-13.1" + "AC-20(IRS-Defined)": [ + "DCH-13" ], - "AC-20(2)": [ + "AC-20(CE-2)": [ + "DCH-13.2" + ], + "AC-20(CE-5)": [ "DCH-13.2" ], + "AC-20(CE-3)": [ + "DCH-13.4" + ], "AC-21": [ "DCH-14", "PRI-07" ], + "2.E.6.2": [ + "DCH-14.2" + ], "AC-22": [ "DCH-15" ], + "AC-23": [ + "DCH-16" + ], "SI-12": [ "DCH-18", "PRI-05" ], - "SI-12(1)": [ - "DCH-18.1", - "PRI-05.1" - ], - "SI-12(2)": [ + "SI-12(CE-2)": [ "DCH-18.2", "PRI-05.1" ], - "SI-12(3)": [ - "DCH-21", - "PRI-05" + "2.D.7": [ + "DCH-21" ], "CM-12": [ "DCH-24" ], - "CM-12(1)": [ - "DCH-24.1" - ], - "5.20.4.3": [ - "END-02" + "CM-12(CE-1)": [ + "DCH-24" ], "SI-3": [ "END-04", @@ -197625,29 +216371,64 @@ "VPM-01", "VPM-05" ], + "SI-3(IRS-Defined)-1": [ + "END-04.7" + ], + "SI-3(IRS-Defined)-2": [ + "END-04.7" + ], "SI-7": [ "END-06", "NET-12", "TDA-18" ], - "SI-7(1)": [ + "SI-7(CE-1)": [ "END-06.1" ], - "SI-7(7)": [ + "SI-7(CE-7)": [ + "END-06.2" + ], + "SI-7(CE-7).a": [ + "END-06.2" + ], + "SI-7(CE-7).b": [ "END-06.2" ], + "SI-7(CE-10)": [ + "END-06.6" + ], "SI-8": [ "END-08" ], - "SI-8(2)": [ + "SI-8(CE-2)": [ "END-08.2" ], "SC-18": [ "END-10" ], + "SC-18(CE-1)": [ + "END-10", + "VPM-02", + "VPM-04" + ], "SC-15": [ "END-14" ], + "SC-15(CE-4)": [ + "END-14.2" + ], + "SC-7(CE-12)": [ + "END-16.1" + ], + "2.C.3-1": [ + "HRS-01" + ], + "2.C.3-2": [ + "HRS-01" + ], + "2.C.3-5": [ + "HRS-01" + ], "PS-2": [ "HRS-02", "HRS-03.2" @@ -197655,16620 +216436,14463 @@ "PS-9": [ "HRS-03" ], - "PS-3": [ + "2.C.3": [ "HRS-04" ], - "PL-4": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" - ], - "PL-4(1)": [ - "HRS-05.2" - ], - "PS-6": [ - "HRS-06", - "HRS-06.1" - ], - "PS-8": [ - "HRS-07" - ], - "PS-5": [ - "HRS-08" - ], - "PS-4": [ - "HRS-09" - ], - "AC-2(13)": [ - "HRS-09.2", - "IAC-15.6" - ], - "PS-7": [ - "HRS-10" - ], - "IA-4": [ - "IAC-01.2", - "IAC-09" - ], - "IA-4(4)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" - ], - "IA-2": [ - "IAC-02" - ], - "IA-2(8)": [ - "IAC-02.2" - ], - "IA-2(12)": [ - "IAC-02.3" - ], - "IA-8": [ - "IAC-03" - ], - "IA-8(1)": [ - "IAC-03.1" - ], - "IA-8(2)": [ - "IAC-03.2" - ], - "IA-8(4)": [ - "IAC-03.3" - ], - "IA-3": [ - "IAC-04" - ], - "IA-2(1)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" - ], - "IA-2(2)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" - ], - "AC-2": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" - ], - "IA-5": [ - "IAC-10", - "IAC-10.8" - ], - "IA-5(1)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" - ], - "IA-5(2)": [ - "IAC-10.2" - ], - "IA-5(6)": [ - "IAC-10.5", - "IAC-18" - ], - "IA-6": [ - "IAC-11" - ], - "IA-11": [ - "IAC-14" - ], - "AC-2(1)": [ - "IAC-15.1" - ], - "AC-2(2)": [ - "IAC-15.2" - ], - "AC-2(3)": [ - "IAC-15.3" - ], - "AC-2(4)": [ - "IAC-15.4" + "2.C.3-3": [ + "HRS-04" ], - "AC-6(7)": [ - "IAC-17" + "2.C.3-6": [ + "HRS-04" ], - "AC-3": [ - "IAC-20", - "NET-12", - "TDA-18" + "2.C.3-6.1": [ + "HRS-04" ], - "AC-6": [ - "IAC-20", - "IAC-21" + "2.C.3-6.2": [ + "HRS-04" ], - "AC-6(1)": [ - "IAC-21.1" + "2.C.3-6.3": [ + "HRS-04" ], - "AC-6(2)": [ - "IAC-21.2" + "PS-3": [ + "HRS-04" ], - "AC-6(5)": [ - "IAC-21.3" + "2.C.3-4": [ + "HRS-04.1" ], - "AC-6(9)": [ - "IAC-21.4" + "PL-4": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "AC-6(10)": [ - "IAC-21.5" + "PL-4(CE-1)": [ + "HRS-05.2" ], - "AC-7": [ - "IAC-22" + "PL-4(CE-1).a": [ + "HRS-05.2" ], - "AC-2(5)": [ - "IAC-24" + "PL-4(CE-1).b": [ + "HRS-05.2" ], - "AC-11": [ - "IAC-24" + "PL-4(CE-1).c": [ + "HRS-05.2" ], - "AC-11(1)": [ - "IAC-24.1" + "3.3.2": [ + "HRS-05.3" ], - "AC-12": [ - "IAC-25" + "3.3.2.a-1": [ + "HRS-05.3" ], - "AC-14": [ - "IAC-26" + "3.3.2.b-1": [ + "HRS-05.3" ], - "IA-12": [ - "IAC-28" + "3.3.2.a-2": [ + "HRS-05.3" ], - "IA-12(2)": [ - "IAC-28.2" + "3.3.2.b-2": [ + "HRS-05.3" ], - "IA-12(3)": [ - "IAC-28.3" + "3.3.2.c-2": [ + "HRS-05.3" ], - "IA-12(5)": [ - "IAC-28.5" + "3.3.2.a-3": [ + "HRS-05.3" ], - "5.20.5": [ - "IRO-01" + "3.3.2.b-3": [ + "HRS-05.3" ], - "IR-4": [ - "IRO-02" + "3.3.2.c-3": [ + "HRS-05.3" ], - "IR-4(1)": [ - "IRO-02.1" + "3.3.2.d-3": [ + "HRS-05.3" ], - "IR-8": [ - "IRO-04" + "3.3.2.e-3": [ + "HRS-05.3" ], - "IR-8(1)": [ - "IRO-04.1" + "3.3.3": [ + "HRS-05.3" ], - "IR-2": [ - "IRO-05" + "3.3.3.a-1": [ + "HRS-05.3" ], - "IR-2(3)": [ - "IRO-05" + "3.3.3.b-1": [ + "HRS-05.3" ], - "IR-3": [ - "IRO-06" + "3.3.3.a-2": [ + "HRS-05.3" ], - "IR-3(2)": [ - "IRO-06.1" + "3.3.3.b-2": [ + "HRS-05.3" ], - "IR-5": [ - "IRO-09" + "3.3.3.c-2": [ + "HRS-05.3" ], - "IR-6(1)": [ - "IRO-10.1" + "3.3.3.d-2": [ + "HRS-05.3" ], - "IR-6(3)": [ - "IRO-10.4" + "3.3.3.d.1-2": [ + "HRS-05.3" ], - "IR-7": [ - "IRO-11" + "3.3.3.d.2-2": [ + "HRS-05.3" ], - "IR-7(1)": [ - "IRO-11.1" + "3.3.3.a-3": [ + "HRS-05.3" ], - "CA-2(1)": [ - "IAO-02.1" + "3.3.3.b-3": [ + "HRS-05.3" ], - "CA-5": [ - "IAO-05" + "PL-4(IRS-Defined)": [ + "HRS-05.3" ], - "CM-4(2)": [ - "IAO-06" + "PS-6": [ + "HRS-06", + "HRS-06.1" ], - "CA-6": [ - "IAO-07" + "PS-6(CE-3)": [ + "HRS-06.2" ], - "MA-2": [ - "MNT-02" + "PS-6(CE-3).a": [ + "HRS-06.2" ], - "MA-6": [ - "MNT-03" + "PS-6(CE-3).b": [ + "HRS-06.2" ], - "MA-3": [ - "MNT-04" + "2.C.4.2": [ + "HRS-07" ], - "MA-3(1)": [ - "MNT-04.1" + "PS-8": [ + "HRS-07" ], - "MA-3(2)": [ - "MNT-04.2" + "2.C.4.1": [ + "HRS-08" ], - "MA-3(3)": [ - "MNT-04.3" + "PS-5": [ + "HRS-08" ], - "MA-4": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "2.C.4.3": [ + "HRS-09" ], - "MA-5": [ - "MNT-06" + "PS-4": [ + "HRS-09" ], - "5.20": [ - "MDM-01" + "AC-2(CE-13)": [ + "HRS-09.2", + "IAC-15.6" ], - "5.20.1.2": [ - "MDM-01" + "PS-7": [ + "HRS-10" ], - "5.20.1.4": [ - "MDM-01" + "AC-2(CE-7)": [ + "IAC-01" ], - "5.20.2": [ - "MDM-01" + "AC-2(CE-7).a": [ + "IAC-01" ], - "5.20.3": [ - "MDM-01" + "AC-2(CE-7).b": [ + "IAC-01" ], - "5.20.4": [ - "MDM-01" + "AC-2(CE-7).c": [ + "IAC-01" ], - "5.20.4.2": [ - "MDM-01" + "AC-2(CE-7).d": [ + "IAC-01" ], - "5.20.6": [ - "MDM-01" + "IA-4": [ + "IAC-01.2", + "IAC-09" ], - "5.20.7": [ - "MDM-01" + "IA-4(CE-4)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "5.20.7.1": [ - "MDM-01" + "IA-4(IRS-Defined)": [ + "IAC-01.2", + "IAC-09" ], - "5.20.7.2": [ - "MDM-01" + "IA-2(CE-8)": [ + "IAC-02.2" ], - "5.20.7.3": [ - "MDM-01" + "IA-8": [ + "IAC-03" ], - "AC-19": [ - "MDM-02" + "IA-8(IRS-Defined)": [ + "IAC-03" ], - "AC-19(5)": [ - "MDM-03" + "IA-8(CE-2)": [ + "IAC-03.2" ], - "SC-7": [ - "NET-03" + "IA-8(CE-2).a": [ + "IAC-03.2" ], - "SC-7(3)": [ - "NET-03.1" + "IA-8(CE-2).b": [ + "IAC-03.2" ], - "SC-7(4)": [ - "NET-03.2" + "IA-8(CE-4)": [ + "IAC-03.3" ], - "AC-4": [ - "NET-04" + "IA-3": [ + "IAC-04" ], - "SC-7(5)": [ - "NET-04.1" + "IA-3(CE-1)": [ + "IAC-04" ], - "CA-3": [ - "NET-05" + "IA-9": [ + "IAC-05" ], - "CA-9": [ - "NET-05.2" + "AC-6(CE-6)": [ + "IAC-05.2" ], - "SC-10": [ - "NET-07" + "3.3.1.k": [ + "IAC-06" ], - "SC-23": [ - "NET-09" + "IA-2(CE-1)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "SC-20": [ - "NET-10" + "IA-2(CE-2)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "SC-22": [ - "NET-10.1" + "IA-2(CE-6)": [ + "IAC-06.4" ], - "SC-21": [ - "NET-10.2" + "IA-2(CE-6).a": [ + "IAC-06.4" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "IA-2(CE-6).b": [ + "IAC-06.4" ], - "SI-10": [ + "AC-2": [ + "IAC-07.2", + "IAC-15", "NET-12", "TDA-18" ], - "AC-17": [ - "NET-14" - ], - "AC-17(1)": [ - "NET-14.1" - ], - "AC-17(2)": [ - "NET-14.2" - ], - "AC-17(3)": [ - "NET-14.3" + "2.D.6": [ + "IAC-08" ], - "AC-17(4)": [ - "NET-14.4" + "IA-5": [ + "IAC-10", + "IAC-10.8" ], - "5.20.1": [ - "NET-15" + "IA-5(CE-1).c": [ + "IAC-10" ], - "5.20.1.1": [ - "NET-15" + "IA-5(CE-1).d": [ + "IAC-10" ], - "AC-18(1)": [ - "NET-15.1" + "IA-5(CE-1).e": [ + "IAC-10" ], - "AC-18(3)": [ - "NET-15.2" + "IA-5(IRS-Defined)-1": [ + "IAC-10" ], - "SC-7(8)": [ - "NET-18", - "NET-18.1" + "IA-5(IRS-Defined)-2": [ + "IAC-10" ], - "PE-2": [ - "PES-02" + "IA-5(IRS-Defined)-2.a": [ + "IAC-10" ], - "PE-3": [ - "PES-03" + "IA-5(IRS-Defined)-2.b": [ + "IAC-10" ], - "PE-8": [ - "PES-03.3" + "IA-5(IRS-Defined)-2.c": [ + "IAC-10" ], - "PE-6": [ - "PES-05" + "IA-5(IRS-Defined)-2.d": [ + "IAC-10" ], - "PE-6(1)": [ - "PES-05.1" + "IA-5(CE-1)": [ + "IAC-10.1" ], - "PE-8(3)": [ - "PES-06.5" + "IA-5(CE-1).f": [ + "IAC-10.1" ], - "PE-9": [ - "PES-07" + "IA-5(CE-1).h": [ + "IAC-10.1" ], - "PE-10": [ - "PES-07.2" + "IA-5(CE-1).h.1": [ + "IAC-10.1" ], - "PE-11": [ - "PES-07.3" + "IA-5(CE-1).h.2": [ + "IAC-10.1" ], - "PE-12": [ - "PES-07.4" + "IA-5(CE-1).h.3": [ + "IAC-10.1" ], - "PE-15": [ - "PES-07.5" + "IA-5(CE-1).h.4": [ + "IAC-10.1" ], - "PE-13": [ - "PES-08" + "IA-5(CE-1).h.5": [ + "IAC-10.1" ], - "PE-13(1)": [ - "PES-08.1" + "IA-5(CE-1).h.5.i": [ + "IAC-10.1" ], - "PE-14": [ - "PES-09" + "IA-5(CE-1).h.5.ii": [ + "IAC-10.1" ], - "PE-16": [ - "PES-10" + "IA-5(CE-1).h.6": [ + "IAC-10.1" ], - "PE-17": [ - "PES-11" + "IA-5(CE-1).h.6.i": [ + "IAC-10.1" ], - "PE-4": [ - "PES-12.1" + "IA-5(CE-1).h.6.ii": [ + "IAC-10.1" ], - "PE-5": [ - "PES-12.2" + "IA-5(CE-1).h.7": [ + "IAC-10.1" ], - "4.2.3.2": [ - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "IA-5(CE-2)": [ + "IAC-10.2" ], - "AC-3(14)": [ - "PRI-06" + "IA-5(CE-2).a": [ + "IAC-10.2" ], - "SA-2": [ - "PRM-03" + "IA-5(CE-2).a.1": [ + "IAC-10.2" ], - "RA-9": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "IA-5(CE-2).a.2": [ + "IAC-10.2" ], - "SA-3": [ - "PRM-07", - "SEA-07.1" + "IA-5(CE-2).b": [ + "IAC-10.2" ], - "RA-2": [ - "RSK-02" + "IA-5(CE-2).b.1": [ + "IAC-10.2" ], - "RA-7": [ - "RSK-06.1" + "IA-5(CE-2).b.2": [ + "IAC-10.2" ], - "5.20.7.2.1": [ - "RSK-06.2" + "IA-5(CE-1).a": [ + "IAC-10.4" ], - "SR-2": [ - "RSK-09", - "TPM-03" + "IA-5(CE-1).b": [ + "IAC-10.4" ], - "CA-7(4)": [ - "RSK-11" + "IA-5(CE-1).g": [ + "IAC-10.4" ], - "PL-8": [ - "SEA-02" + "IA-5(CE-6)": [ + "IAC-10.5", + "IAC-18" ], - "SC-2": [ - "SEA-03.2" + "IA-5(CE-7)": [ + "IAC-10.6" ], - "SC-4": [ - "SEA-05" + "IA-5(CE-5)": [ + "IAC-10.8" ], - "SI-16": [ - "SEA-10" + "IA-5(CE-12)": [ + "IAC-10.12" ], - "AC-8": [ - "SEA-18" + "IA-6": [ + "IAC-11" ], - "5.1.2": [ - "OPS-03" + "IA-11": [ + "IAC-14" ], - "AT-2": [ - "SAT-02" + "AC-2(CE-1)": [ + "IAC-15.1" ], - "AT-2(3)": [ - "SAT-02.2" + "AC-2(CE-2)": [ + "IAC-15.2" ], - "AT-3": [ - "SAT-03" + "AC-2(CE-3)": [ + "IAC-15.3" ], - "AT-3(5)": [ - "SAT-03.3" + "AC-2(CE-3).a": [ + "IAC-15.3" ], - "AT-4": [ - "SAT-04" + "AC-2(CE-3).b": [ + "IAC-15.3" ], - "SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "AC-2(CE-3).c": [ + "IAC-15.3" ], - "SA-4(9)": [ - "TDA-02.1" + "AC-2(CE-3).d": [ + "IAC-15.3" ], - "SA-4(10)": [ - "TDA-02.2" + "AC-2(CE-4)": [ + "IAC-15.4" ], - "SA-15": [ - "TDA-06" + "AC-2(CE-9)": [ + "IAC-15.5" ], - "SA-11": [ - "TDA-09" + "AC-6(CE-7)": [ + "IAC-17" ], - "SA-10": [ - "TDA-14" + "AC-6(CE-7).a": [ + "IAC-17" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "AC-6(CE-7).b": [ + "IAC-17" ], - "SI-11": [ - "TDA-19" + "AC-3": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "SR-2(1)": [ - "TPM-03" + "AC-6": [ + "IAC-20", + "IAC-21" ], - "SR-5": [ - "TPM-03.1" + "AC-6(CE-1)": [ + "IAC-21.1" ], - "SA-9": [ - "TPM-04" + "AC-6(CE-1).a": [ + "IAC-21.1" ], - "SA-9(2)": [ - "TPM-04.2" + "AC-6(CE-1).b": [ + "IAC-21.1" ], - "SR-8": [ - "TPM-05.1" + "AC-6(CE-2)": [ + "IAC-21.2" ], - "AT-2(2)": [ - "THR-05" + "AC-6(IRS-Defined)-1": [ + "IAC-21.2" ], - "RA-5(11)": [ - "THR-06" + "AC-6(IRS-Defined)-2": [ + "IAC-21.2" ], - "5.20.4.1": [ - "VPM-05" + "AC-6(CE-9)": [ + "IAC-21.4" ], - "SI-2(2)": [ - "VPM-05.2" + "AC-6(CE-10)": [ + "IAC-21.5" ], - "RA-5": [ - "VPM-06", - "VPM-06.1" + "AC-6(CE-8)": [ + "IAC-21.7" ], - "RA-5(2)": [ - "VPM-06.1" + "AC-7": [ + "IAC-22" ], - "RA-5(5)": [ - "VPM-06.3" - ] - }, - "usa-federal-doe-c2m2-2-1": { - "PROGRAM-1f": [ - "GOV-01" + "AC-11": [ + "IAC-24" ], - "PROGRAM-1g": [ - "GOV-01", - "CPL-01" + "AC-11(CE-1)": [ + "IAC-24.1" ], - "PROGRAM-2b": [ - "GOV-01" + "AC-12": [ + "IAC-25" ], - "PROGRAM-2i": [ - "GOV-01" + "AC-12(CE-1)": [ + "IAC-25.1" ], - "RISK-1f": [ - "GOV-01.1", - "PRM-01" + "AC-14": [ + "IAC-26" ], - "PROGRAM-2a": [ - "GOV-01.1" + "IA-12": [ + "IAC-28" ], - "PROGRAM-2c": [ - "GOV-01.1" + "IA-12(CE-1)": [ + "IAC-28.1" ], - "PROGRAM-2d": [ - "GOV-01.1" + "IA-12(CE-2)": [ + "IAC-28.2" ], - "PROGRAM-2g": [ - "GOV-01.2", - "GOV-05" + "IA-12(CE-3)": [ + "IAC-28.3" ], - "ASSET-5c": [ - "GOV-02" + "IA-12(CE-5)": [ + "IAC-28.5" ], - "THREAT-3c": [ - "GOV-02" + "1.8.4": [ + "IRO-01" ], - "RISK-5c": [ - "GOV-02" + "IR-4": [ + "IRO-02" ], - "ACCESS-4c": [ - "GOV-02" + "IR-4(CE-1)": [ + "IRO-02.1" ], - "SITUATION-4c": [ - "GOV-02" + "IR-4(CE-6)": [ + "IRO-02.2" ], - "RESPONSE-5c": [ - "GOV-02" + "IR-4(CE-8)": [ + "IRO-02.5" ], - "THIRD-PARTIES-3c": [ - "GOV-02" + "IR-8": [ + "IRO-04" ], - "WORKFORCE-5c": [ - "GOV-02" + "IR-8(CE-1)": [ + "IRO-04.1" ], - "ARCHITECTURE-6c": [ - "GOV-02" + "IR-8(CE-1).a": [ + "IRO-04.1" ], - "PROGRAM-3c": [ - "GOV-02" + "IR-8(CE-1).b": [ + "IRO-04.1" ], - "PROGRAM-1h": [ - "GOV-03" + "IR-8(CE-1).c": [ + "IRO-04.1" ], - "ASSET-5d": [ - "GOV-04" + "IR-3(CE-3)": [ + "IRO-04.3" ], - "THREAT-3d": [ - "GOV-04" + "IR-3(CE-3).a": [ + "IRO-04.3" ], - "RISK-5d": [ - "GOV-04" + "IR-3(CE-3).b": [ + "IRO-04.3" ], - "ACCESS-4d": [ - "GOV-04" + "IR-3(CE-3).c": [ + "IRO-04.3" ], - "SITUATION-4d": [ - "GOV-04" + "IR-2": [ + "IRO-05" ], - "RESPONSE-5d": [ - "GOV-04" + "IR-2(CE-3)": [ + "IRO-05" ], - "THIRD-PARTIES-3d": [ - "GOV-04" + "IR-2(CE-1)": [ + "IRO-05.1" ], - "WORKFORCE-5d": [ - "GOV-04" + "IR-3": [ + "IRO-06" ], - "ARCHITECTURE-6d": [ - "GOV-04" + "IR-3(CE-2)": [ + "IRO-06.1" ], - "PROGRAM-2e": [ - "GOV-04" + "IR-5": [ + "IRO-09" ], - "PROGRAM-3d": [ - "GOV-04" + "IR-6(CE-1)": [ + "IRO-10.1" ], - "RISK-1e": [ - "GOV-04.1", - "GOV-04.2" + "IR-6(CE-3)": [ + "IRO-10.3" ], - "PROGRAM-2f": [ - "GOV-04.1", - "GOV-04.2" + "IR-7": [ + "IRO-10.4" ], - "ASSET-5f": [ - "GOV-05" + "IR-7(CE-1)": [ + "IRO-11" ], - "THREAT-3f": [ - "GOV-05" + "IR-7(CE-2)": [ + "IRO-11.2" ], - "RISK-5f": [ - "GOV-05" + "IR-7(CE-2).a": [ + "IRO-11.2" ], - "ACCESS-4f": [ - "GOV-05" + "IR-7(CE-2).b": [ + "IRO-11.2" ], - "SITUATION-3d": [ - "GOV-05", - "MON-06", - "MON-06.2" + "IR-9": [ + "IRO-12" ], - "SITUATION-4f": [ - "GOV-05" + "IR-6(CE-2)": [ + "IRO-13" ], - "RESPONSE-5f": [ - "GOV-05" + "PM-10": [ + "IAO-01" ], - "THIRD-PARTIES-3f": [ - "GOV-05" + "CA-2(CE-1)": [ + "IAO-02.1" ], - "WORKFORCE-5f": [ - "GOV-05" + "SA-11(CE-5)": [ + "IAO-02.2", + "IAO-04", + "TDA-09", + "TDA-09.5", + "VPM-07" ], - "ARCHITECTURE-6f": [ - "GOV-05" + "2.E.4.3": [ + "IAO-03" ], - "PROGRAM-3f": [ - "GOV-05" + "2.E.4.3-1.1": [ + "IAO-03" ], - "PROGRAM-2j": [ - "GOV-07" + "2.E.4.3-1.2": [ + "IAO-03" ], - "ARCHITECTURE-1f": [ - "GOV-15", - "GOV-15.1", - "SEA-01.1" + "2.E.4.3-1.3": [ + "IAO-03" ], - "ARCHITECTURE-1g": [ - "GOV-15.1" + "2.E.4.3-1.4": [ + "IAO-03" ], - "ASSET-1d": [ - "AST-01", - "AST-02", - "AST-02.9", - "TDA-06.1" + "2.E.4.3-1.5": [ + "IAO-03" ], - "ASSET-1h": [ - "AST-01", - "AST-09", - "SEA-07.1" + "2.E.4.3-2.1": [ + "IAO-03" ], - "ASSET-2e": [ - "AST-01", - "AST-02.9" + "2.E.4.3-2.2": [ + "IAO-03" ], - "ASSET-1a": [ - "AST-01.1", - "AST-02" + "2.E.4.3-2.3": [ + "IAO-03" ], - "RISK-2m": [ - "AST-01.1", - "BCD-02", - "RSK-01.1", - "RSK-03" + "2.E.4.3-2.4": [ + "IAO-03" ], - "THIRD-PARTIES-1a": [ - "AST-01.1", - "BCD-02", - "TPM-04", - "TPM-05.4" + "2.E.6.1-1": [ + "IAO-03" ], - "ASSET-1b": [ - "AST-02" + "2.E.6.1-2": [ + "IAO-03" ], - "ASSET-1e": [ - "AST-02" + "2.E.6.1-3": [ + "IAO-03" ], - "ASSET-1f": [ - "AST-02" + "2.E.6.1-4": [ + "IAO-03" ], - "ASSET-1g": [ - "AST-02" + "PL-2(IRS-Defined)": [ + "IAO-03" ], - "ASSET-2a": [ - "AST-02" + "SA-11(CE-5).a": [ + "IAO-04" ], - "ASSET-2b": [ - "AST-02" + "SA-11(CE-5).b": [ + "IAO-04" ], - "ASSET-2f": [ - "AST-02" + "2.E.5": [ + "IAO-05" ], - "ASSET-2g": [ - "AST-02", - "AST-02.1", - "AST-02.9" + "2.E.5-1": [ + "IAO-05" ], - "RISK-2h": [ - "AST-02", - "BCD-02" + "2.E.5-2": [ + "IAO-05" ], - "ARCHITECTURE-2k": [ - "AST-02.5" + "2.E.5-3": [ + "IAO-05" ], - "ASSET-2h": [ - "AST-09", - "DCH-09" + "CA-5": [ + "IAO-05" ], - "ASSET-2c": [ - "AST-31", - "BCD-02", - "TDA-06.1" + "CA-5(IRS-Defined)-1": [ + "IAO-05" ], - "ASSET-2d": [ - "AST-31", - "PRM-06", - "TDA-06.1" + "CA-5(IRS-Defined)-2": [ + "IAO-05" ], - "RESPONSE-4d": [ - "BCD-01" + "PM-4": [ + "IAO-05", + "VPM-02" ], - "RESPONSE-4g": [ - "BCD-01.4", - "BCD-01.7" + "CM-4(CE-2)": [ + "IAO-06" ], - "RESPONSE-4h": [ - "BCD-01.5" + "CA-6": [ + "IAO-07" ], - "RESPONSE-4a": [ - "BCD-01.7" + "MA-2": [ + "MNT-02" ], - "RESPONSE-4e": [ - "BCD-01.7" + "MA-6": [ + "MNT-03" ], - "RESPONSE-4f": [ - "BCD-01.7" + "MA-3": [ + "MNT-04" ], - "RESPONSE-4m": [ - "BCD-01.7" + "MA-3(CE-5)": [ + "MNT-04" ], - "ASSET-1c": [ - "BCD-02", - "TDA-06.1" + "MA-3(CE-1)": [ + "MNT-04.1" ], - "RESPONSE-4i": [ - "BCD-04" + "MA-3(CE-2)": [ + "MNT-04.2" ], - "RESPONSE-4n": [ - "BCD-04" + "MA-3(CE-3)": [ + "MNT-04.3" ], - "RESPONSE-4o": [ - "BCD-05" + "MA-3(CE-3).a": [ + "MNT-04.3" ], - "RESPONSE-4p": [ - "BCD-06" + "MA-3(CE-3).b": [ + "MNT-04.3" ], - "RESPONSE-4b": [ - "BCD-11", - "BCD-11.1" + "MA-3(CE-3).c": [ + "MNT-04.3" ], - "RESPONSE-4j": [ - "BCD-11", - "BCD-11.4", - "BCD-11.9" + "MA-3(CE-3).d": [ + "MNT-04.3" ], - "RESPONSE-4k": [ - "BCD-11.2" + "MA-3(CE-4)": [ + "MNT-04.4" ], - "RESPONSE-4c": [ - "BCD-15" + "MA-4": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "RESPONSE-4l": [ - "BCD-15" + "MA-4(CE-1)": [ + "MNT-05.1" ], - "ARCHITECTURE-3i": [ - "CAP-01", - "MNT-01" + "MA-4(CE-1).a": [ + "MNT-05.1" ], - "ASSET-4a": [ - "CHG-01" + "MA-4(CE-1).b": [ + "MNT-05.1" ], - "ASSET-4c": [ - "CHG-01", - "CHG-02.2", - "CHG-02.3", - "CHG-03" + "MA-4(CE-6)": [ + "MNT-05.3" ], - "ASSET-4g": [ - "CHG-01" + "MA-4(CE-7)": [ + "MNT-05.4" ], - "ASSET-4b": [ - "CHG-02", - "CHG-02.2" + "MA-4(CE-4)": [ + "MNT-05.7" ], - "ARCHITECTURE-3l": [ - "CHG-02", - "CFG-02" + "MA-4(CE-4).a": [ + "MNT-05.7" ], - "ASSET-4d": [ - "CHG-02.2", - "CHG-03" + "MA-4(CE-4).b": [ + "MNT-05.7" ], - "ASSET-4f": [ - "CHG-02.2", - "CHG-07" + "MA-4(CE-4).b.1": [ + "MNT-05.7" ], - "ASSET-4h": [ - "CHG-02.2" + "MA-4(CE-4).b.2": [ + "MNT-05.7" ], - "ASSET-4i": [ - "CHG-02.2" + "MA-5": [ + "MNT-06" ], - "THREAT-1h": [ - "CHG-02.2", - "CHG-02.3", - "VPM-03", - "VPM-03.1" + "MA-5(CE-5)": [ + "MNT-06.2" ], - "ASSET-4e": [ - "CHG-04", - "CHG-04.4", - "CHG-06" + "SR-11(CE-2)": [ + "MNT-07" ], - "RISK-2l": [ - "CPL-01.1", - "SEA-01.1", - "VPM-05.1", - "VPM-05.3" + "3.3.4": [ + "MDM-01" ], - "ARCHITECTURE-1i": [ - "CPL-01.1", - "CPL-01.3", - "CPL-01.4", - "CPL-02", - "CPL-03.2" + "AC-19": [ + "MDM-02" ], - "RISK-4c": [ - "CPL-02", - "CPL-03.2", - "IAO-01" + "AC-19(CE-5)": [ + "MDM-03" ], - "PROGRAM-2h": [ - "CPL-02" + "AC-7(CE-2)": [ + "MDM-05" ], - "ASSET-3a": [ - "CFG-02" + "3.3.6": [ + "NET-01" ], - "ASSET-3b": [ - "CFG-02" + "SC-7": [ + "NET-03" ], - "ASSET-3c": [ - "CFG-02" + "SC-7(CE-9)": [ + "NET-03" ], - "SITUATION-1c": [ - "CFG-02", - "MON-01.4" + "SC-7(CE-9).a": [ + "NET-03" ], - "SITUATION-1d": [ - "CFG-02", - "MON-01.4" + "SC-7(CE-9).b": [ + "NET-03" ], - "ARCHITECTURE-2e": [ - "CFG-02", - "NET-04", + "SC-7(CE-11)": [ + "NET-03", "NET-04.1" ], - "ARCHITECTURE-3b": [ - "CFG-02", - "END-01" - ], - "ARCHITECTURE-3d": [ - "CFG-02", - "CFG-03" + "SC-7(IRS-Defined)-1": [ + "NET-03" ], - "ARCHITECTURE-3e": [ - "CFG-02" + "SC-7(IRS-Defined)-2": [ + "NET-03" ], - "ARCHITECTURE-3f": [ - "CFG-02", - "END-02" + "SC-7(CE-3)": [ + "NET-03.1" ], - "ARCHITECTURE-3g": [ - "CFG-02", - "DCH-12" + "SC-7(CE-4)": [ + "NET-03.2" ], - "ARCHITECTURE-3h": [ - "CFG-02", - "CFG-02.9", - "END-02" + "SC-7(CE-4).a": [ + "NET-03.2" ], - "ASSET-3d": [ - "CFG-02.1", - "CFG-02.9" + "SC-7(CE-4).b": [ + "NET-03.2" ], - "ASSET-3e": [ - "CFG-02.1", - "CFG-02.2" + "SC-7(CE-4).c": [ + "NET-03.2" ], - "SITUATION-1f": [ - "CFG-02.5", - "CFG-02.9", - "MON-01.4", - "MON-01.16" + "SC-7(CE-4).d": [ + "NET-03.2" ], - "ARCHITECTURE-3k": [ - "CFG-02.5" + "SC-7(CE-4).e": [ + "NET-03.2" ], - "ARCHITECTURE-3m": [ - "CFG-03.3" + "SC-7(CE-4).f": [ + "NET-03.2" ], - "SITUATION-1a": [ - "MON-01", - "MON-01.4", - "MON-01.16" + "SC-7(CE-4).g": [ + "NET-03.2" ], - "SITUATION-2c": [ - "MON-01" + "SC-7(CE-4).h": [ + "NET-03.2" ], - "SITUATION-3g": [ - "MON-01", - "MON-01.13", - "MON-01.16" + "SC-7(CE-10)": [ + "NET-03.5" ], - "RESPONSE-1d": [ - "MON-01.2", - "MON-02.1", - "MON-02.3" + "SC-7(CE-10).a": [ + "NET-03.5" ], - "SITUATION-2b": [ - "MON-01.3", - "MON-01.8" + "SC-7(CE-10).b": [ + "NET-03.5" ], - "SITUATION-1b": [ - "MON-01.4" + "AC-4": [ + "NET-04" ], - "SITUATION-2e": [ - "MON-01.4", - "MON-01.8" + "SC-7(CE-5)": [ + "NET-04.1" ], - "SITUATION-2a": [ - "MON-01.8" + "2.E.4.1": [ + "NET-05" ], - "SITUATION-2i": [ - "MON-01.8", - "MON-11.3", - "MON-16", - "IRO-03" + "CA-3": [ + "NET-05" ], - "SITUATION-2f": [ - "MON-01.16" + "CA-9": [ + "NET-05.2" ], - "SITUATION-2g": [ - "MON-01.16" + "SC-10": [ + "NET-07" ], - "RESPONSE-1e": [ - "MON-01.16" + "SC-23": [ + "NET-09" ], - "SITUATION-1e": [ - "MON-02", - "MON-02.1" + "SC-23(CE-1)": [ + "NET-09.1" ], - "SITUATION-3e": [ - "MON-02.1", - "THR-03" + "SC-23(CE-3)": [ + "NET-09.2" ], - "SITUATION-3a": [ - "MON-06", - "MON-06.2" + "SC-20": [ + "NET-10" ], - "SITUATION-3b": [ - "MON-06" + "SC-20(CE-2)": [ + "NET-10" ], - "SITUATION-3c": [ - "MON-06", - "MON-06.2" + "SC-22": [ + "NET-10.1" ], - "SITUATION-3f": [ - "MON-06" + "SC-21": [ + "NET-10.2" ], - "SITUATION-2d": [ - "MON-11.3", - "MON-16", - "IRO-03" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "SITUATION-2h": [ - "MON-11.3", - "MON-16", - "IRO-03", - "RSK-01.1" + "SI-10": [ + "NET-12", + "TDA-18" ], - "ACCESS-2i": [ - "MON-16" + "AC-17": [ + "NET-14" ], - "ARCHITECTURE-5d": [ - "CRY-01", - "CRY-03", - "CRY-05" + "AC-17(CE-1)": [ + "NET-14.1" ], - "ARCHITECTURE-5c": [ - "CRY-03" + "AC-17(CE-2)": [ + "NET-14.2" ], - "ARCHITECTURE-5a": [ - "CRY-05" + "AC-17(CE-3)": [ + "NET-14.3" ], - "ARCHITECTURE-5b": [ - "CRY-05" + "AC-17(CE-4)": [ + "NET-14.4" ], - "ARCHITECTURE-5e": [ - "CRY-09" + "AC-17(CE-4).a": [ + "NET-14.4" ], - "ARCHITECTURE-2j": [ - "EMB-01", - "NET-06.4" + "AC-17(CE-4).b": [ + "NET-14.4" ], - "WORKFORCE-1g": [ - "HRS-01", - "HRS-07", - "HRS-07.1", - "HRS-09" + "2.B.7": [ + "NET-14.5" ], - "WORKFORCE-3e": [ - "HRS-01" + "CA-9(CE-1)": [ + "NET-14.7" ], - "WORKFORCE-3f": [ - "HRS-01" + "AC-17(CE-9)": [ + "NET-14.8" ], - "ACCESS-3h": [ - "HRS-02", - "HRS-02.1", - "HRS-04.1" + "AC-18(IRS-Defined)-1": [ + "NET-15" ], - "WORKFORCE-3a": [ - "HRS-02", - "HRS-03" + "AC-18(IRS-Defined)-2": [ + "NET-15" ], - "THREAT-2a": [ - "HRS-03", - "TPM-04", - "TPM-05.4" + "AC-18(IRS-Defined)-3": [ + "NET-15" ], - "RESPONSE-3a": [ - "HRS-03", - "IRO-07" + "AC-18(IRS-Defined)-4": [ + "NET-15" ], - "WORKFORCE-3b": [ - "HRS-03" + "AC-18(CE-1)": [ + "NET-15.1" ], - "WORKFORCE-3c": [ - "HRS-03" + "AC-18(CE-3)": [ + "NET-15.2" ], - "WORKFORCE-3d": [ - "HRS-03" + "SC-7(CE-8)": [ + "NET-18", + "NET-18.1" ], - "WORKFORCE-1e": [ - "HRS-03.1", - "HRS-04.2", - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "HRS-05.3", - "HRS-05.4", - "HRS-05.5", - "HRS-05.7", - "HRS-06" + "SI-4(CE-10)": [ + "NET-18.2" ], - "WORKFORCE-2a": [ - "HRS-03.1", - "HRS-04.2", - "SAT-01", - "SAT-02" + "SC-7(CE-15)": [ + "NET-18.3" ], - "ASSET-5e": [ - "HRS-03.2" + "PE-1(IRS-Defined)-1": [ + "PES-01" ], - "THREAT-3e": [ - "HRS-03.2" + "PE-1(IRS-Defined)-2": [ + "PES-01" ], - "RISK-5e": [ - "HRS-03.2" + "PE-1(IRS-Defined)-3": [ + "PES-01" ], - "ACCESS-4e": [ - "HRS-03.2" + "2.B.3.2": [ + "PES-02" ], - "SITUATION-4e": [ - "HRS-03.2" + "2.B.3.2-1": [ + "PES-02" ], - "RESPONSE-5e": [ - "HRS-03.2" + "2.B.3.2-2": [ + "PES-02" ], - "THIRD-PARTIES-3e": [ - "HRS-03.2" + "2.B.3.2-3": [ + "PES-02" ], - "WORKFORCE-5e": [ - "HRS-03.2" + "2.B.3.2-4": [ + "PES-02" ], - "ARCHITECTURE-6e": [ - "HRS-03.2" + "2.B.3.2-5": [ + "PES-02" ], - "PROGRAM-3e": [ - "HRS-03.2" + "PE-2": [ + "PES-02" ], - "WORKFORCE-1a": [ - "HRS-04" + "2.B.3.4": [ + "PES-03" ], - "WORKFORCE-1b": [ - "HRS-04" + "PE-3": [ + "PES-03" ], - "WORKFORCE-1c": [ - "HRS-04" + "PE-3(CE-2)": [ + "PES-03" ], - "WORKFORCE-1f": [ - "HRS-04", - "HRS-04.1", - "IAC-28" + "2.B.3.5": [ + "PES-03.3" ], - "WORKFORCE-1d": [ - "HRS-08", - "HRS-09" + "2.B.3.5-1": [ + "PES-03.3" ], - "ACCESS-2e": [ - "HRS-11" + "2.B.3.5-2": [ + "PES-03.3" ], - "ACCESS-3f": [ - "HRS-11", - "PES-02", - "PES-02.1", - "PES-02.2", - "PES-03" + "2.B.3.5-3": [ + "PES-03.3" ], - "WORKFORCE-4b": [ - "HRS-13" + "PE-8": [ + "PES-03.3" ], - "WORKFORCE-4c": [ - "HRS-13" + "2.B.3": [ + "PES-04", + "PES-04.1" ], - "ACCESS-2a": [ - "IAC-01" + "2.B.3.3": [ + "PES-04" ], - "ACCESS-2c": [ - "IAC-01" + "PE-6": [ + "PES-05" ], - "ACCESS-2f": [ - "IAC-01", - "IAC-07", - "IAC-07.1", - "IAC-21.3", - "IAC-28.1" + "PE-6(CE-1)": [ + "PES-05.1" ], - "ARCHITECTURE-3a": [ - "IAC-01", - "PES-01" + "2.B.3.1": [ + "PES-06", + "PES-06.2" ], - "ACCESS-1b": [ - "IAC-01.2", - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "2.B.3.1-1": [ + "PES-06" ], - "ACCESS-1h": [ - "IAC-06", - "IAC-06.1", - "IAC-06.3", - "IAC-16" + "2.B.3.1-2": [ + "PES-06" ], - "ACCESS-1i": [ - "IAC-06" + "2.B.3.1-3": [ + "PES-06" ], - "ACCESS-1a": [ - "IAC-07" + "2.B.3.1-4": [ + "PES-06" ], - "ACCESS-1c": [ - "IAC-07" + "2.B.3.1-5": [ + "PES-06" ], - "ACCESS-1f": [ - "IAC-07" + "2.B.3.1-6": [ + "PES-06" ], - "ACCESS-2g": [ - "IAC-07", - "IAC-07.1", - "IAC-21.3", - "IAC-28.1" + "2.B.3.1-7": [ + "PES-06" ], - "ACCESS-2h": [ - "IAC-07.1", - "IAC-17" + "PE-16": [ + "PES-10" ], - "ACCESS-1g": [ - "IAC-08", - "IAC-16", - "IAC-21" + "PE-17": [ + "PES-11" ], - "ACCESS-2b": [ - "IAC-08", - "IAC-15", - "IAC-16", - "IAC-17" + "PE-4": [ + "PES-12.1" ], - "ARCHITECTURE-3c": [ - "IAC-08", - "IAC-21" + "PE-5": [ + "PES-12.2" ], - "ACCESS-1d": [ - "IAC-10.1" + "PM-18": [ + "PRI-01" ], - "ACCESS-1j": [ - "IAC-15.3" + "PM-19": [ + "PRI-01.1" ], - "ACCESS-1e": [ - "IAC-17" + "PT-2": [ + "PRI-04", + "PRI-04.1", + "PRI-05.1", + "PRI-05.4" ], - "ACCESS-2d": [ - "IAC-20", - "IAC-21" + "PM-5(CE-1)": [ + "PRI-05.5", + "PRI-05.6" ], - "RESPONSE-1a": [ - "IRO-01", - "IRO-02", - "IRO-04" + "PM-21": [ + "PRI-14.1" ], - "RESPONSE-1b": [ - "IRO-02", - "IRO-02.4" + "PM-3": [ + "PRM-02" ], - "RESPONSE-1f": [ - "IRO-02" + "SA-2": [ + "PRM-03" ], - "RESPONSE-2a": [ - "IRO-02", - "IRO-02.4" + "SA-3": [ + "PRM-07", + "SEA-07.1" ], - "RESPONSE-2b": [ - "IRO-02", - "IRO-02.4" + "PM-9": [ + "RSK-01" ], - "RESPONSE-3b": [ - "IRO-02", - "IRO-04" + "RA-7": [ + "RSK-06.1" ], - "RESPONSE-3c": [ - "IRO-02", - "IRO-10", - "IRO-10.2" + "SA-9(CE-3)": [ + "RSK-09", + "TPM-02", + "TPM-03", + "TPM-04.3", + "TPM-05.4", + "TPM-05.7" ], - "RESPONSE-3e": [ - "IRO-02", - "IRO-04" + "SR-2": [ + "RSK-09", + "TPM-03" ], - "RESPONSE-3l": [ - "IRO-02", - "IRO-04" + "RA-3(CE-1)": [ + "RSK-09.1" ], - "RESPONSE-2c": [ - "IRO-02.4" + "RA-3(CE-1).c": [ + "RSK-09.1" ], - "RESPONSE-2d": [ - "IRO-02.4" + "RA-3(CE-1).d": [ + "RSK-09.1" ], - "RESPONSE-2e": [ - "IRO-02.4" + "RA-8": [ + "RSK-10" ], - "RESPONSE-2h": [ - "IRO-02.4" + "CA-7(CE-4)": [ + "RSK-11" ], - "RESPONSE-3d": [ - "IRO-04" + "CA-7(CE-4).a": [ + "RSK-11" ], - "RESPONSE-3f": [ - "IRO-04" + "CA-7(CE-4).b": [ + "RSK-11" ], - "RESPONSE-3g": [ - "IRO-06" + "CA-7(CE-4).c": [ + "RSK-11" ], - "RESPONSE-3j": [ - "IRO-06.1", - "IRO-11.2" + "SC-7(CE-18)": [ + "SEA-01" ], - "RESPONSE-1c": [ - "IRO-09" + "PL-8": [ + "SEA-02" ], - "RESPONSE-2f": [ - "IRO-09", - "IRO-09.3" + "PM-7": [ + "SEA-02" ], - "RESPONSE-2i": [ - "IRO-09.4" + "PM-7(IRS-Defined)": [ + "SEA-02" ], - "RESPONSE-2g": [ - "IRO-10", - "IRO-10.2" + "PL-8(CE-1)": [ + "SEA-03" ], - "RESPONSE-3k": [ - "IRO-11.2" + "PL-8(CE-1).a": [ + "SEA-03" ], - "RESPONSE-3h": [ - "IRO-13" + "PL-8(CE-1).b": [ + "SEA-03" ], - "RESPONSE-3i": [ - "IRO-13" + "SC-2": [ + "SEA-03.2" ], - "RISK-4d": [ - "IAO-02" + "SC-2(CE-1)": [ + "SEA-03.2" ], - "RISK-3f": [ - "IAO-05", - "RSK-04.1" + "SC-39": [ + "SEA-04" ], - "RISK-3g": [ - "IAO-05" + "SC-4": [ + "SEA-05" ], - "ARCHITECTURE-2a": [ - "NET-01" + "SI-16": [ + "SEA-10" ], - "ARCHITECTURE-2c": [ - "NET-01", - "NET-02" + "SC-35": [ + "SEA-12" ], - "ARCHITECTURE-2f": [ - "NET-01" + "3.3.7": [ + "SEA-13.1" ], - "ARCHITECTURE-5f": [ - "NET-03.5", - "NET-17", - "NET-18" + "AC-8": [ + "SEA-18" ], - "ARCHITECTURE-2l": [ - "NET-03.6" + "2.D.2": [ + "SAT-01" ], - "ARCHITECTURE-2b": [ - "NET-06" + "2.D.2.1": [ + "SAT-02", + "SAT-03" ], - "ARCHITECTURE-2d": [ - "NET-06" + "AT-2": [ + "SAT-02" ], - "ARCHITECTURE-2h": [ - "NET-06" + "AT-2(IRS-Defined)-1": [ + "SAT-02" ], - "ARCHITECTURE-2i": [ - "NET-06.4" + "AT-2(IRS-Defined)-2": [ + "SAT-02" ], - "ARCHITECTURE-2g": [ - "NET-18" + "AT-2(CE-1)": [ + "SAT-02.1" ], - "ACCESS-3a": [ - "PES-01", - "PES-03" + "AT-6": [ + "SAT-02.1" ], - "ACCESS-3d": [ - "PES-01", - "PES-02", - "PES-03" + "AT-2(CE-3)": [ + "SAT-02.2" ], - "ARCHITECTURE-3j": [ - "PES-01" + "AT-3": [ + "SAT-03" ], - "ACCESS-3b": [ - "PES-02" + "AT-2(CE-4)": [ + "SAT-03.2" ], - "ACCESS-3g": [ - "PES-02", - "PES-03" + "2.D.2.1-1.1": [ + "SAT-03.3" ], - "ACCESS-3i": [ - "PES-02" + "2.D.2.1-1.2": [ + "SAT-03.3" ], - "ACCESS-3e": [ - "PES-02.1", - "PES-03" + "2.D.2.1-1.3": [ + "SAT-03.3" ], - "ACCESS-3j": [ - "PES-03" + "2.D.2.1-1.4": [ + "SAT-03.3" ], - "ACCESS-3c": [ - "PES-03.3" + "2.D.2.1-2.1": [ + "SAT-03.3" ], - "ARCHITECTURE-1e": [ - "PRM-01" + "2.D.2.1-2.2": [ + "SAT-03.3" ], - "RISK-1a": [ - "PRM-01.1" + "2.D.2.1-2.3": [ + "SAT-03.3" ], - "ARCHITECTURE-1a": [ - "PRM-01.1" + "2.D.2.1-2.4": [ + "SAT-03.3" ], - "PROGRAM-1a": [ - "PRM-01.1" + "2.D.2.1-2.5": [ + "SAT-03.3" ], - "PROGRAM-1b": [ - "PRM-01.1" + "2.D.2.1-2.6": [ + "SAT-03.3" ], - "PROGRAM-1c": [ - "PRM-01.1" + "2.D.2.1-2.7": [ + "SAT-03.3" ], - "PROGRAM-1d": [ - "PRM-01.1" + "AT-4": [ + "SAT-04" ], - "PROGRAM-1e": [ - "PRM-01.1" + "SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "ASSET-5b": [ - "PRM-03" + "SA-4(CE-9)": [ + "TDA-02.1" ], - "THREAT-3b": [ - "PRM-03" + "SA-10(CE-7)": [ + "TDA-02.7" ], - "RISK-5b": [ - "PRM-03" + "SA-15": [ + "TDA-06" ], - "ACCESS-4b": [ - "PRM-03" + "SA-15(CE-3)": [ + "TDA-06.1" ], - "SITUATION-4b": [ - "PRM-03" + "SA-15(CE-3).a": [ + "TDA-06.1" ], - "RESPONSE-5b": [ - "PRM-03" + "SA-15(CE-3).b": [ + "TDA-06.1" ], - "THIRD-PARTIES-3b": [ - "PRM-03" + "SA-11": [ + "TDA-09" ], - "WORKFORCE-5b": [ - "PRM-03" + "SA-11(CE-6)": [ + "TDA-09", + "VPM-01.1" ], - "ARCHITECTURE-6b": [ - "PRM-03" + "SA-4(CE-8)": [ + "TDA-09.1" ], - "PROGRAM-3b": [ - "PRM-03" + "SA-11(CE-1)": [ + "TDA-09.2" ], - "RISK-1b": [ - "RSK-01" + "SA-11(CE-4)": [ + "TDA-09.7" ], - "RISK-1c": [ - "RSK-01" + "SA-3(CE-2)": [ + "TDA-10" ], - "RISK-1d": [ - "RSK-01" + "SA-3(CE-2).a": [ + "TDA-10" ], - "RISK-1g": [ - "RSK-01" + "SA-3(CE-2).b": [ + "TDA-10" ], - "RISK-1h": [ - "RSK-01" + "SR-11": [ + "TDA-11" ], - "RISK-3b": [ - "RSK-01.1" + "SR-11(CE-1)": [ + "TDA-11.1" ], - "RISK-2d": [ - "RSK-02" + "SA-10": [ + "TDA-14" ], - "RISK-2i": [ - "RSK-02" + "SA-10(CE-1)": [ + "TDA-14.1" ], - "RISK-3a": [ - "RSK-02" + "SA-10(CE-3)": [ + "TDA-14.2" ], - "RISK-2a": [ - "RSK-03" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "RISK-2b": [ - "RSK-03" + "SI-11": [ + "TDA-19" ], - "RISK-2c": [ - "RSK-03" + "1.9.3": [ + "TPM-01" ], - "RISK-2g": [ - "RSK-03", - "RSK-04", - "RSK-04.2" + "SR-2(CE-1)": [ + "TPM-03" ], - "RISK-2e": [ - "RSK-03.1", - "RSK-04.1" + "SR-3(CE-2)": [ + "TPM-03.2" ], - "RISK-2j": [ - "RSK-03.1", - "THR-09" + "SR-3": [ + "TPM-03.3" ], - "RISK-2f": [ - "RSK-04.1" + "2.C.9": [ + "TPM-04" ], - "RISK-3c": [ - "RSK-04.2" + "2.C.9-1": [ + "TPM-04" ], - "RISK-3d": [ - "RSK-04.2" + "2.C.9-2": [ + "TPM-04" ], - "RISK-3e": [ - "RSK-04.2" + "2.C.9-3": [ + "TPM-04" ], - "RISK-4b": [ - "RSK-04.2", - "RSK-06.3" + "2.C.9-4": [ + "TPM-04" ], - "RISK-4e": [ - "RSK-06", - "RSK-06.1" + "2.C.9-5": [ + "TPM-04" ], - "RISK-4a": [ - "RSK-06.3" + "2.C.9-6": [ + "TPM-04" ], - "ARCHITECTURE-1b": [ - "SEA-01", - "SEA-02", - "SEA-03" + "2.C.9-7": [ + "TPM-04" ], - "ARCHITECTURE-1j": [ - "SEA-01", - "SEA-01.2", - "SEA-01.3", - "SEA-02" + "2.C.9-7.1": [ + "TPM-04" ], - "ARCHITECTURE-5g": [ - "SEA-01" + "2.C.9-7.2": [ + "TPM-04" ], - "ARCHITECTURE-5h": [ - "SEA-01" + "2.C.9-8": [ + "TPM-04" ], - "ARCHITECTURE-1c": [ - "SEA-02" + "2.C.9-9": [ + "TPM-04" ], - "ARCHITECTURE-1d": [ - "SEA-02" + "2.C.9-10": [ + "TPM-04" ], - "ARCHITECTURE-1h": [ - "SEA-02" + "SA-4(IRS-Defined)-1": [ + "TPM-04" ], - "ARCHITECTURE-1k": [ - "SEA-02" + "SA-4(IRS-Defined)-2": [ + "TPM-04" ], - "ASSET-5a": [ - "OPS-01.1" + "SA-9": [ + "TPM-04" ], - "THREAT-3a": [ - "OPS-01.1" + "2.C.10": [ + "TPM-04.1" ], - "RISK-5a": [ - "OPS-01.1" + "SA-9(CE-1)": [ + "TPM-04.1" ], - "ACCESS-4a": [ - "OPS-01.1" + "SA-9(CE-1).a": [ + "TPM-04.1" ], - "SITUATION-4a": [ - "OPS-01.1" + "SA-9(CE-1).b": [ + "TPM-04.1" ], - "RESPONSE-5a": [ - "OPS-01.1" + "SA-9(CE-2)": [ + "TPM-04.2" ], - "THIRD-PARTIES-3a": [ - "OPS-01.1" + "3.3.1.g": [ + "TPM-05" ], - "WORKFORCE-5a": [ - "OPS-01.1" + "SA-4(CE-12).b": [ + "TPM-05" ], - "ARCHITECTURE-6a": [ - "OPS-01.1" + "SR-3(CE-3)": [ + "TPM-05", + "TPM-05.2" ], - "PROGRAM-3a": [ - "OPS-01.1" + "SR-6": [ + "TPM-08" ], - "WORKFORCE-2b": [ - "SAT-01", - "SAT-02" + "PM-12": [ + "THR-04" ], - "WORKFORCE-2c": [ - "SAT-01", - "SAT-02" + "AT-2(CE-2)": [ + "THR-05" ], - "WORKFORCE-4f": [ - "SAT-01" + "RA-5(IRS-Defined)": [ + "VPM-01" ], - "WORKFORCE-2g": [ - "SAT-01.1" + "SI-2(CE-4)": [ + "VPM-05", + "VPM-05.1", + "VPM-05.2", + "VPM-05.4" ], - "WORKFORCE-4e": [ - "SAT-01.1" + "SI-2(IRS-Defined)": [ + "VPM-05" ], - "WORKFORCE-2d": [ - "SAT-02" + "SI-2(CE-2)": [ + "VPM-05.2" ], - "WORKFORCE-4d": [ - "SAT-02" + "SI-2(CE-3)": [ + "VPM-05.3" ], - "WORKFORCE-2e": [ - "SAT-03" + "SI-2(CE-3).a": [ + "VPM-05.3" ], - "WORKFORCE-2f": [ - "SAT-03" + "SI-2(CE-3).b": [ + "VPM-05.3" ], - "WORKFORCE-4a": [ - "SAT-03" + "SI-2(CE-5)": [ + "VPM-05.4" ], - "ARCHITECTURE-4a": [ - "TDA-01", - "TDA-06" + "SI-2(CE-6)": [ + "VPM-05.5" ], - "ARCHITECTURE-4b": [ - "TDA-01", - "TDA-02", - "TPM-04.1" + "RA-5": [ + "VPM-06", + "VPM-06.1" ], - "ARCHITECTURE-4e": [ - "TDA-01", - "TDA-02", - "TPM-04.1" + "RA-5(CE-2)": [ + "VPM-06.1" ], - "ARCHITECTURE-4c": [ - "TDA-01.1", - "TDA-02", - "TDA-09.6" + "RA-5(CE-5)": [ + "VPM-06.3" ], - "ARCHITECTURE-4f": [ - "TDA-05", - "TDA-06.5" + "RA-5(CE-4)": [ + "VPM-06.8" ], - "ARCHITECTURE-4d": [ - "TDA-06" + "CA-8": [ + "VPM-07" ], - "ARCHITECTURE-4h": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.5" + "3.3.8": [ + "WEB-01" ], - "ARCHITECTURE-4g": [ - "TDA-14.1" + "3.3.8.c": [ + "WEB-01" ], - "THIRD-PARTIES-2i": [ - "TDA-17", - "TDA-17.1", - "TPM-04.1" + "3.3.8.a": [ + "WEB-02" ], - "THIRD-PARTIES-1b": [ - "TPM-01.1" + "SC-7(CE-17)": [ + "WEB-03" + ] + }, + "usa-federal-cms-marse-2-0": { + "PM-1": [ + "GOV-01", + "GOV-02", + "GOV-03" ], - "THIRD-PARTIES-1d": [ - "TPM-01.1", - "TPM-02" + "PM-1.a": [ + "GOV-01" ], - "THIRD-PARTIES-1c": [ - "TPM-02", - "TPM-04.1" + "PM-1.a.1": [ + "GOV-01" ], - "THIRD-PARTIES-1e": [ - "TPM-02" + "PM-1.a.2": [ + "GOV-01" ], - "THIRD-PARTIES-1f": [ - "TPM-02" + "PM-1.a.3": [ + "GOV-01" ], - "THIRD-PARTIES-2j": [ - "TPM-03.1" + "PM-1.a.4": [ + "GOV-01" ], - "THIRD-PARTIES-2k": [ - "TPM-03.1" + "PM-1.b": [ + "GOV-01" ], - "THIRD-PARTIES-2l": [ - "TPM-03.1" + "PM-1.c": [ + "GOV-01" ], - "THIRD-PARTIES-2m": [ - "TPM-03.1" + "PM-1.d": [ + "GOV-01" ], - "THIRD-PARTIES-2a": [ - "TPM-04.1" + "AC-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "THIRD-PARTIES-2b": [ - "TPM-04.1" + "AC-1.a": [ + "GOV-02" ], - "THIRD-PARTIES-2c": [ - "TPM-05" + "AT-1": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "THIRD-PARTIES-2e": [ - "TPM-05" + "AT-1.a": [ + "GOV-02" ], - "THIRD-PARTIES-2f": [ - "TPM-05" + "AT-1.c": [ + "GOV-02" ], - "THIRD-PARTIES-2g": [ - "TPM-05" + "AT-1.d": [ + "GOV-02" ], - "THIRD-PARTIES-2h": [ - "TPM-05" + "AU-1": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "THIRD-PARTIES-2d": [ - "TPM-05.5", - "TPM-08" + "AU-1.a": [ + "GOV-02" ], - "THREAT-1a": [ - "THR-03", - "VPM-06.1" + "CA-1": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "THREAT-1b": [ - "THR-03", - "VPM-03", - "VPM-03.1" + "CA-1.a": [ + "GOV-02" ], - "THREAT-1e": [ - "THR-03", - "VPM-01.1", - "VPM-06.1", - "VPM-06.2" + "CA-1.c": [ + "GOV-02" ], - "THREAT-2f": [ - "THR-03" + "CM-1": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "THREAT-2j": [ - "THR-03" + "CM-1.a": [ + "GOV-02" ], - "THREAT-2k": [ - "THR-03", - "THR-03.1" + "CP-1": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "RISK-2k": [ - "THR-03" + "CP-1.a": [ + "GOV-02" ], - "THREAT-1i": [ - "THR-03.1", - "VPM-04", - "VPM-05.3" + "IA-1": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "THREAT-2b": [ - "THR-03.1", - "VPM-03", - "VPM-03.1" + "IA-1.a": [ + "GOV-02" ], - "THREAT-2h": [ - "THR-03.1" + "IR-1": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "THREAT-1m": [ - "THR-06" + "IR-1.a": [ + "GOV-02" ], - "THREAT-2c": [ - "THR-10" + "MA-1": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "THREAT-2e": [ - "THR-10" + "MA-1.a": [ + "GOV-02" ], - "THREAT-2g": [ - "THR-10" + "MP-1": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "THREAT-2i": [ - "THR-10" + "MP-1.a": [ + "GOV-02" ], - "THREAT-1j": [ - "VPM-01" + "MP-1-IS.1": [ + "GOV-02" ], - "THREAT-1g": [ - "VPM-03", - "VPM-03.1" + "PE-1": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "THREAT-2d": [ - "VPM-03", - "VPM-04" + "PE-1.a": [ + "GOV-02" ], - "THREAT-1d": [ - "VPM-04" + "PL-1": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "THREAT-1l": [ - "VPM-05.1" + "PL-1.a": [ + "GOV-02" ], - "THREAT-1c": [ - "VPM-06" + "PS-1": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "THREAT-1f": [ - "VPM-06" + "PS-1.a": [ + "GOV-02" ], - "THREAT-1k": [ - "VPM-06" - ] - }, - "usa-federal-dow-cmmc-2-level-1": { - "MP.L1-B.1.VII": [ - "AST-01", - "AST-09", - "DCH-01", - "DCH-08", - "DCH-09" + "RA-1": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "AC.L1-B.1.IV": [ - "CLD-01", - "CLD-02", - "CLD-06", - "CLD-10", - "DCH-15", - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "WEB-01", - "WEB-02", - "WEB-04" + "SA-1": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" ], - "AC.L1-B.1.III": [ - "DCH-13", - "DCH-13.1", - "DCH-17" + "SA-1.a": [ + "GOV-02" ], - "SI.L1-B.1.XIII": [ - "END-01", - "END-04" + "SC-1": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "SI.L1-B.1.XV": [ - "END-04", - "END-04.7" + "SC-1.a": [ + "GOV-02" ], - "SI.L1-B.1.XIV": [ - "END-04.1" + "SI-1": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "AC.L1-B.1.I": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-15.1", - "IAC-20", - "TPM-01", - "TPM-05", - "TPM-05.2" + "SI-1.a": [ + "GOV-02" ], - "IA.L1-B.1.V": [ - "IAC-02", - "IAC-04", - "IAC-15.1" + "PM-2": [ + "GOV-04" ], - "IA.L1-B.1.VI": [ - "IAC-02", - "IAC-04", - "IAC-15.1" + "PM-6": [ + "GOV-04", + "GOV-05" ], - "AC.L1-B.1.II": [ - "IAC-08", - "IAC-15" + "IR-6": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "SC.L1-B.1.X": [ - "NET-01", - "NET-02.2", - "NET-03" + "PM-15": [ + "GOV-07", + "THR-01" ], - "SC.L1-B.1.XI": [ - "NET-06" + "PM-15.a": [ + "GOV-07" ], - "PE.L1-B.1.VIII": [ - "PES-02", - "PES-02.1", - "PES-03.4", - "PES-04", - "PES-12", - "PES-12.1", - "PES-12.2" + "PM-15.b": [ + "GOV-07" ], - "PE.L1-B.1.IX": [ - "PES-03", - "PES-06", - "PES-06.1", - "PES-06.3" + "PM-15.c": [ + "GOV-07" ], - "SI.L1-B.1.XII": [ - "VPM-01", - "VPM-02", - "VPM-05" - ] - }, - "usa-federal-dow-cmmc-2-level-1-aos": { - "MP.L1-B.1.VII[a]": [ - "DCH-09" + "PM-5": [ + "AST-01", + "AST-02" ], - "MP.L1-B.1.VII[b]": [ - "DCH-09" + "CM-8": [ + "AST-02", + "AST-02.3" ], - "AC.L1-B.1.III[a]": [ - "DCH-13" + "CM-8.a": [ + "AST-02" ], - "AC.L1-B.1.III[b]": [ - "DCH-13" + "CM-8.a.1": [ + "AST-02" ], - "AC.L1-B.1.III[c]": [ - "DCH-13" + "CM-8.a.2": [ + "AST-02" ], - "AC.L1-B.1.III[d]": [ - "DCH-13" + "CM-8.a.3": [ + "AST-02" ], - "AC.L1-B.1.III[e]": [ - "DCH-13" + "CM-8.a.4": [ + "AST-02" ], - "AC.L1-B.1.III[f]": [ - "DCH-13" + "CM-8.b": [ + "AST-02" ], - "AC.L1-B.1.IV[a]": [ - "DCH-15" + "CM-8-IS.1": [ + "AST-02" ], - "AC.L1-B.1.IV[b]": [ - "DCH-15" + "CM-8-IS.2": [ + "AST-02" ], - "AC.L1-B.1.IV[c]": [ - "DCH-15" + "CM-8(1)": [ + "AST-02.1" ], - "AC.L1-B.1.IV[d]": [ - "DCH-15" + "CM-8(3)": [ + "AST-02.2", + "CFG-05.1", + "END-03.1" ], - "AC.L1-B.1.IV[e]": [ - "DCH-15" + "CM-8(3).a": [ + "AST-02.2" ], - "SI.L1-B.1.XIII[a]": [ - "END-04" + "CM-8(3).b": [ + "AST-02.2" ], - "SI.L1-B.1.XIII[b]": [ - "END-04" + "CM-8(3)-IS": [ + "AST-02.2" ], - "SI.L1-B.1.XV[a]": [ - "END-04" + "CM-8(3)-IS.1": [ + "AST-02.2" ], - "SI.L1-B.1.XV[b]": [ - "END-04" + "CM-8(3)-IS.2": [ + "AST-02.2" ], - "SI.L1-B.1.XIV[a]": [ - "END-04.1" + "CM-8(5)": [ + "AST-02.3" ], - "SI.L1-B.1.XV[c]": [ - "END-04.7" + "PL-2": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "IA.L1-B.1.V[a]": [ - "IAC-02" + "SA-4(1)": [ + "AST-04", + "TDA-04.1" ], - "IA.L1-B.1.V[c]": [ - "IAC-02" + "SA-4(2)": [ + "AST-04", + "TDA-04.1", + "TDA-20" ], - "IA.L1-B.1.VI[a]": [ - "IAC-02" + "SA-5": [ + "AST-04.1", + "TDA-04" ], - "IA.L1-B.1.VI[b]": [ - "IAC-02" + "SC-19": [ + "AST-21" ], - "IA.L1-B.1.VI[c]": [ - "IAC-02" + "SC-19.a": [ + "AST-21" ], - "AC.L1-B.1.II[a]": [ - "IAC-15" + "SC-19.b": [ + "AST-21" ], - "AC.L1-B.1.II[b]": [ - "IAC-15" + "CP-2": [ + "BCD-01", + "BCD-01.7", + "BCD-06" ], - "AC.L1-B.1.I[a]": [ - "IAC-20" + "CP-2.a.1": [ + "BCD-01" ], - "AC.L1-B.1.I[b]": [ - "IAC-20" + "CP-2.a.2": [ + "BCD-01" ], - "AC.L1-B.1.Ic]": [ - "IAC-20" + "CP-2.a.3": [ + "BCD-01" ], - "AC.L1-B.1.I[d]": [ - "IAC-20" + "CP-2.a.4": [ + "BCD-01" ], - "AC.L1-B.1.I[e]": [ - "IAC-20" + "CP-2.a.5": [ + "BCD-01" ], - "AC.L1-B.1.I[f]": [ - "IAC-20" + "CP-2.a.6": [ + "BCD-01" ], - "IA.L1-B.1.V[b]": [ - "IAC-20" + "CP-2.b": [ + "BCD-01" ], - "SC.L1-B.1.X[a]": [ - "NET-03" + "CP-2.c": [ + "BCD-01" ], - "SC.L1-B.1.X[b]": [ - "NET-03" + "CP-2.d": [ + "BCD-01" ], - "SC.L1-B.1.X[c]": [ - "NET-03" + "CP-2.e": [ + "BCD-01", + "BCD-06" ], - "SC.L1-B.1.X[d]": [ - "NET-03" + "CP-2.f": [ + "BCD-01" ], - "SC.L1-B.1.X[e]": [ - "NET-03" + "CP-2.g": [ + "BCD-01" ], - "SC.L1-B.1.X[f]": [ - "NET-03" + "CP-2-IS.1": [ + "BCD-01" ], - "SC.L1-B.1.X[g]": [ - "NET-03" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "SC.L1-B.1.X[h]": [ - "NET-03" + "PM-8": [ + "BCD-01", + "CPL-01" ], - "SC.L1-B.1.XI[a]": [ - "NET-06" + "CP-2(1)": [ + "BCD-01.1" ], - "SC.L1-B.1.XI[b]": [ - "NET-06" + "CP-2.a": [ + "BCD-01.7" ], - "PE.L1-B.1.VIII[a]": [ - "PES-02" + "CP-2(8)": [ + "BCD-02" ], - "PE.L1-B.1.VIII[b]": [ - "PES-02" + "CP-2(3)": [ + "BCD-02.1" ], - "PE.L1-B.1.VIII[c]": [ - "PES-02" + "CP-3": [ + "BCD-03" ], - "PE.L1-B.1.VIII[d]": [ - "PES-02" + "CP-3.a": [ + "BCD-03" ], - "PE.L1-B.1.IX[a]": [ - "PES-03" + "CP-3.b": [ + "BCD-03" ], - "PE.L1-B.1.IX[d]": [ - "PES-03" + "CP-3.c": [ + "BCD-03" ], - "PE.L1-B.1.IX[e]": [ - "PES-03" + "CP-4": [ + "BCD-04", + "BCD-05" ], - "PE.L1-B.1.IX[f]": [ - "PES-03" + "CP-4.a": [ + "BCD-04" ], - "PE.L1-B.1.IX[c]": [ - "PES-03.3" + "CP-4.b": [ + "BCD-04" ], - "PE.L1-B.1.IX[b]": [ - "PES-06.3" + "CP-4.c": [ + "BCD-04" ], - "SI.L1-B.1.XII[a]": [ - "VPM-01" + "CP-4-IS.1": [ + "BCD-04" ], - "SI.L1-B.1.XII[b]": [ - "VPM-01" + "CP-4(1)": [ + "BCD-04.1" ], - "SI.L1-B.1.XII[c]": [ - "VPM-01" + "CP-6": [ + "BCD-08" ], - "SI.L1-B.1.XII[d]": [ - "VPM-01" + "CP-6.a": [ + "BCD-08" ], - "SI.L1-B.1.XII[e]": [ - "VPM-01" + "CP-6.b": [ + "BCD-08" ], - "SI.L1-B.1.XII[f]": [ - "VPM-01" - ] - }, - "usa-federal-dow-cmmc-2-level-2": { - "CML2.-3.4.1": [ - "AST-01", - "AST-02", - "CFG-02" + "CP-6(1)": [ + "BCD-08.1" ], - "MPL2.-3.8.3": [ - "AST-01", - "AST-09", - "DCH-01", - "DCH-08", - "DCH-09" + "CP-6(3)": [ + "BCD-08.2" ], - "MPL2.-3.8.9": [ - "BCD-11", - "BCD-11.4" + "CP-7": [ + "BCD-09" ], - "CML2.-3.4.3": [ - "CHG-01", - "CHG-02" + "CP-7.a": [ + "BCD-09" ], - "CML2.-3.4.4": [ - "CHG-03" + "CP-7.b": [ + "BCD-09" ], - "CML2.-3.4.5": [ - "CHG-04", - "TDA-08" + "CP-7.c": [ + "BCD-09" ], - "ACL2.-3.1.22": [ - "CLD-01", - "CLD-02", - "CLD-06", - "CLD-10", - "DCH-15", - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "WEB-01", - "WEB-02", - "WEB-04" + "CP-7-IS.1": [ + "BCD-09" ], - "SCL2.-3.13.2": [ - "CLD-03", - "SEA-01", - "SEA-03" + "CP-7(1)": [ + "BCD-09.1" ], - "CAL2.-3.12.1": [ - "CPL-02", - "CPL-02.1", - "CPL-03", - "IAO-02" + "CP-7(2)": [ + "BCD-09.2" ], - "CAL2.-3.12.3": [ - "CPL-02", - "THR-01", - "THR-03" + "CP-7(3)": [ + "BCD-09.3" ], - "AUL2.-3.3.3": [ - "CFG-02", - "CFG-02.1", - "CFG-02.9", - "MON-01", - "MON-01.8", - "MON-01.16", - "MON-02" + "CP-8": [ + "BCD-10" ], - "CML2.-3.4.2": [ - "CFG-02" + "CP-8-IS.a": [ + "BCD-10" ], - "CML2.-3.4.6": [ - "CFG-03" + "CP-8-IS.b": [ + "BCD-10" ], - "CML2.-3.4.7": [ - "CFG-03.1", - "CFG-03.2" + "CP-8(2)": [ + "BCD-10" ], - "CML2.-3.4.8": [ - "CFG-03.3" + "CP-8(1)": [ + "BCD-10.1" ], - "SCL2.-3.13.7": [ - "CFG-03.4" + "CP-8(1).a": [ + "BCD-10.1" ], - "CML2.-3.4.9": [ - "CFG-05", - "END-03" + "CP-8(1).b": [ + "BCD-10.1" ], - "SIL2.-3.14.6": [ - "MON-01", - "MON-01.3", - "NET-08" + "CP-9": [ + "BCD-11" ], - "SIL2.-3.14.3": [ - "MON-01.8", - "THR-01", - "THR-03" + "CP-9.a": [ + "BCD-11" ], - "AUL2.-3.3.1": [ - "MON-02", - "MON-10" + "CP-9.b": [ + "BCD-11" ], - "AUL2.-3.3.5": [ - "MON-02", - "MON-02.1" + "CP-9.c": [ + "BCD-11" ], - "AUL2.-3.3.6": [ - "MON-02", - "MON-06" + "CP-9.d": [ + "BCD-11" ], - "AUL2.-3.3.8": [ - "MON-02", - "MON-03.1", - "MON-08" + "CP-9-IS.1": [ + "BCD-11" ], - "AUL2.-3.3.9": [ - "MON-02", - "MON-08.2" + "CP-9-IS.2": [ + "BCD-11" ], - "SIL2.-3.14.7": [ - "MON-02.1", - "MON-11.3", - "MON-16", - "IRO-03" + "CP-9-IS.3": [ + "BCD-11" ], - "AUL2.-3.3.2": [ - "MON-03" + "CP-9-IS.4": [ + "BCD-11" ], - "AUL2.-3.3.4": [ - "MON-05" + "CP-9(1)": [ + "BCD-11.1" ], - "AUL2.-3.3.7": [ - "MON-07.1", - "SEA-20" + "CP-9(1)-IS.1": [ + "BCD-11.1" ], - "SCL2.-3.13.11": [ - "CRY-01" + "CP-10-IS.1": [ + "BCD-12" ], - "MPL2.-3.8.6": [ - "CRY-01.1", - "CRY-05" + "CP-10-IS.1.a": [ + "BCD-12" ], - "SCL2.-3.13.8": [ - "CRY-01.1", - "CRY-03" + "CP-10-IS.1.b": [ + "BCD-12" ], - "SCL2.-3.13.16": [ - "CRY-05", - "END-02" + "CP-10-IS.1.c": [ + "BCD-12", + "CFG-02" ], - "SCL2.-3.13.10": [ - "CRY-08", - "CRY-09" + "CP-10-IS.1.d": [ + "BCD-12" ], - "MPL2.-3.8.1": [ - "DCH-01", - "DCH-06" + "CP-10-IS.1.e": [ + "BCD-12" ], - "PEL2.-3.10.6": [ - "DCH-01.2", - "NET-14.5", - "PES-11" + "CP-10(2)": [ + "BCD-12.1" ], - "ACL2.-3.1.3": [ - "DCH-03", - "IAC-08", - "NET-04", - "NET-18" + "SC-5": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "MPL2.-3.8.2": [ - "DCH-03" + "SC-6": [ + "CAP-02" ], - "MPL2.-3.8.4": [ - "DCH-04" + "CP-2(2)": [ + "CAP-03" ], - "MPL2.-3.8.5": [ - "DCH-07" + "CM-3": [ + "CHG-01", + "CHG-02" ], - "MAL2.-3.7.3": [ - "DCH-09" + "CM-3.e": [ + "CHG-01", + "DCH-18" ], - "MPL2.-3.8.7": [ - "DCH-10" + "CM-3.f": [ + "CHG-01" ], - "MPL2.-3.8.8": [ - "DCH-10.2" + "CM-3.g": [ + "CHG-01" ], - "ACL2.-3.1.20": [ - "DCH-13", - "DCH-13.1", - "DCH-17" + "CM-1-IS.3": [ + "CHG-02" ], - "ACL2.-3.1.21": [ - "DCH-13.2" + "CM-3.a": [ + "CHG-02" ], - "SIL2.-3.14.2": [ - "END-01", - "END-04" + "CM-3.b": [ + "CHG-02" ], - "SIL2.-3.14.4": [ - "END-04.1" + "CM-3.c": [ + "CHG-02" ], - "SIL2.-3.14.5": [ - "END-04.7" + "CM-3.d": [ + "CHG-02" ], - "SCL2.-3.13.13": [ - "END-10" + "CM-3-IS.1": [ + "CHG-02" ], - "SCL2.-3.13.12": [ - "END-14" + "CM-3-IS.2": [ + "CHG-02" ], - "PSL2.-3.9.2": [ - "HRS-01.1", - "HRS-08", - "HRS-09" + "CM-3(2)": [ + "CHG-02.2", + "CHG-06" ], - "PSL2.-3.9.1": [ - "HRS-04", - "HRS-04.1" + "CM-4": [ + "CHG-03" ], - "ATL2.-3.2.1": [ - "HRS-04.2", - "SAT-02" + "CM-4-IS.1": [ + "CHG-03" ], - "ATL2.-3.2.2": [ - "HRS-04.2", - "SAT-03" + "CM-5": [ + "CHG-04", + "END-03.2" ], - "ACL2.-3.1.4": [ - "HRS-11" + "CM-5(1)": [ + "CHG-04.1" ], - "ACL2.-3.1.1": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-15.1", - "IAC-20", - "TPM-01", - "TPM-05", - "TPM-05.2" + "AC-5": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "IAL2.-3.5.1": [ - "IAC-02", - "IAC-04", - "IAC-15.1" + "CM-5(5)": [ + "CHG-04.4" ], - "IAL2.-3.5.2": [ - "IAC-02", - "IAC-04", - "IAC-15.1" + "CM-5(5).a": [ + "CHG-04.4" ], - "IAL2.-3.5.4": [ - "IAC-02.2" + "CM-5(5).b": [ + "CHG-04.4" ], - "IAL2.-3.5.3": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "CM-3-IS.3": [ + "CHG-05" ], - "MAL2.-3.7.5": [ - "IAC-06", - "MNT-05", - "MNT-05.4" + "CM-9": [ + "CHG-05", + "CFG-01" ], - "ACL2.-3.1.2": [ - "IAC-08", - "IAC-15" + "SI-6": [ + "CHG-06" ], - "IAL2.-3.5.5": [ - "IAC-09" + "SI-6.a": [ + "CHG-06" ], - "IAL2.-3.5.8": [ - "IAC-10" + "SI-6.b": [ + "CHG-06" ], - "IAL2.-3.5.9": [ - "IAC-10" + "SI-6.c": [ + "CHG-06" ], - "IAL2.-3.5.7": [ - "IAC-10.1" + "SI-6.d": [ + "CHG-06" ], - "IAL2.-3.5.10": [ - "IAC-10.5" + "SA-9(5)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" ], - "IAL2.-3.5.11": [ - "IAC-11" + "CA-7-IS.2": [ + "CPL-01.5", + "CPL-02" ], - "IAL2.-3.5.6": [ - "IAC-15.3" + "CA-7": [ + "CPL-02" ], - "ACL2.-3.1.5": [ - "IAC-16", - "IAC-16.1", - "IAC-21", - "IAC-21.1", - "IAC-21.3" + "CA-7.1": [ + "CPL-02" ], - "ACL2.-3.1.6": [ - "IAC-21.2" + "CA-7.2": [ + "CPL-02" ], - "ACL2.-3.1.7": [ - "IAC-21.4", - "IAC-21.5" + "CA-7.3": [ + "CPL-02" ], - "ACL2.-3.1.8": [ - "IAC-22" + "CA-7.4": [ + "CPL-02" ], - "ACL2.-3.1.10": [ - "IAC-24", - "IAC-24.1" + "CA-7.5": [ + "CPL-02" ], - "ACL2.-3.1.11": [ - "IAC-25" + "CA-7.6": [ + "CPL-02" ], - "IRL2.-3.6.1": [ - "IRO-02", - "IRO-05" + "CA-7.7": [ + "CPL-02" ], - "IRL2.-3.6.2": [ - "IRO-02" + "CA-7.8": [ + "CPL-02" ], - "IRL2.-3.6.3": [ - "IRO-06" + "CA-7-IS": [ + "CPL-02" ], - "CAL2.-3.12.4": [ - "IAO-03", - "IAO-03.2" + "CA-7-IS.1": [ + "CPL-02" ], - "CAL2.-3.12.2": [ - "IAO-05" + "CA-7-IS.3": [ + "CPL-02" ], - "MAL2.-3.7.1": [ - "MNT-02" + "CA-7(1)": [ + "CPL-02", + "CPL-03.1" ], - "MAL2.-3.7.2": [ - "MNT-04" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "MAL2.-3.7.4": [ - "MNT-04.2" + "CA-2": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "MAL2.-3.7.6": [ - "MNT-06", - "MNT-06.1", - "MNT-06.2" + "RA-3": [ + "CPL-03.2", + "RSK-04" ], - "ACL2.-3.1.18": [ - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07" + "CM-1-IS": [ + "CFG-01" + ], + "CM-1-IS.1": [ + "CFG-01" ], - "ACL2.-3.1.19": [ - "MDM-03" + "CM-9.a": [ + "CFG-01" ], - "SCL2.-3.13.1": [ - "NET-01", - "NET-02.2", - "NET-03" + "CM-9.b": [ + "CFG-01" ], - "SCL2.-3.13.6": [ - "NET-04.1" + "CM-9.c": [ + "CFG-01" ], - "SCL2.-3.13.5": [ - "NET-06" + "CM-9.d": [ + "CFG-01" ], - "SCL2.-3.13.9": [ - "NET-07" + "AC-3-IS.1": [ + "CFG-02" ], - "SCL2.-3.13.15": [ - "NET-09" + "AC-3-IS.2": [ + "CFG-02" ], - "SCL2.-3.13.14": [ - "NET-13" + "AC-3-IS.3": [ + "CFG-02" ], - "ACL2.-3.1.12": [ - "NET-14", - "NET-14.1", - "NET-14.5" + "AC-3-IS.4": [ + "CFG-02" ], - "ACL2.-3.1.13": [ - "NET-14.2" + "AC-6-IS.5": [ + "CFG-02" ], - "ACL2.-3.1.14": [ - "NET-14.3" + "AC-8-IS.1": [ + "CFG-02" ], - "ACL2.-3.1.15": [ - "NET-14.4" + "AC-8-IS.2": [ + "CFG-02" ], - "ACL2.-3.1.16": [ - "NET-15" + "AC-8-IS.3": [ + "CFG-02" ], - "ACL2.-3.1.17": [ - "NET-15.1" + "AC-17-IS.2": [ + "CFG-02" ], - "PEL2.-3.10.2": [ - "PES-01", - "PES-05", - "PES-05.1", - "PES-05.2" + "AC-18-IS.1": [ + "CFG-02" ], - "PEL2.-3.10.1": [ - "PES-02", - "PES-02.1", - "PES-03.4", - "PES-12", - "PES-12.1", - "PES-12.2" + "AC-18-IS.1.a": [ + "CFG-02" ], - "PEL2.-3.10.3": [ - "PES-03", - "PES-06", - "PES-06.1", - "PES-06.3" + "AC-18-IS.1.b": [ + "CFG-02" ], - "PEL2.-3.10.5": [ - "PES-03", - "PES-04" + "AC-18-IS.1.c": [ + "CFG-02" ], - "PEL2.-3.10.4": [ - "PES-03.3" + "AC-18-IS.1.d": [ + "CFG-02" ], - "RAL2.-3.11.1": [ - "RSK-04" + "AC-18-IS.1.e": [ + "CFG-02" ], - "RAL2.-3.11.3": [ - "RSK-06", - "VPM-04", - "VPM-05" + "AC-18-IS.1.f": [ + "CFG-02" ], - "SCL2.-3.13.3": [ - "SEA-03.2" + "AC-18-IS.1.g": [ + "CFG-02" ], - "SCL2.-3.13.4": [ - "SEA-05" + "AC-18-IS.1.h": [ + "CFG-02" ], - "ACL2.-3.1.9": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "AC-18-IS.1.i": [ + "CFG-02" ], - "ATL2.-3.2.3": [ - "SAT-03.6", - "THR-05" + "AC-18-IS.1.j": [ + "CFG-02" ], - "SIL2.-3.14.1": [ - "VPM-01", - "VPM-02", - "VPM-05" + "AC-18-IS.1.k": [ + "CFG-02" ], - "RAL2.-3.11.2": [ - "VPM-06", - "VPM-06.3" - ] - }, - "usa-federal-dow-cmmc-2-level-3": { - "AC.L3-3.1.2E": [ - "AST-02", - "DCH-06.2", - "IAC-08", - "PES-03" + "AC-18-IS.1.l": [ + "CFG-02" ], - "IA.L3-3.5.3E": [ - "AST-02.5" + "AC-19-IS.2": [ + "CFG-02" ], - "AC.L3-3.1.3E": [ - "AST-02.8", - "AST-04", - "NET-02.3", - "NET-04" + "AC-19(5)-IS": [ + "CFG-02" ], - "CM.L3-3.4.1E": [ - "AST-02.9" + "AU-2-IS.1": [ + "CFG-02" ], - "CM.L3-3.4.3E": [ - "AST-02.9" + "AU-2-IS.1.a": [ + "CFG-02" ], - "SI.L3-3.14.3E": [ - "AST-04.1", - "CPL-01.2", - "NET-06", - "NET-06.4" + "AU-2-IS.1.b": [ + "CFG-02" ], - "SI.L3-3.14.1E": [ - "AST-18", - "CRY-13", - "TDA-01.2" + "AU-2-IS.1.c": [ + "CFG-02" ], - "RA.L3-3.11.5E": [ - "CPL-01.2", - "CPL-03", - "RSK-03.1", - "RSK-04", - "THR-09" + "AU-2-IS.1.d": [ + "CFG-02" ], - "CM.L3-3.4.2E": [ - "CFG-02.2", - "CFG-02.8", - "CFG-06", - "CFG-06.1" + "AU-2-IS.1.e": [ + "CFG-02" ], - "SI.L3-3.14.6E": [ - "MON-01.1", - "THR-03", - "THR-07" + "AU-2-IS.1.f": [ + "CFG-02" ], - "RA.L3-3.11.2E": [ - "MON-11.3", - "THR-07" + "AU-2-IS.1.g": [ + "CFG-02" ], - "PS.L3-3.9.2E": [ - "HRS-02.1", - "HRS-07", - "HRS-07.1", - "HRS-07.3" + "AU-2-IS.1.h": [ + "CFG-02" ], - "IA.L3-3.5.1E": [ - "IAC-02.2", - "IAC-04" + "AU-2-IS.1.i": [ + "CFG-02" ], - "IR.L3-3.6.2E": [ - "IRO-07" + "AU-2-IS.1.j": [ + "CFG-02" ], - "RA.L3-3.11.4E": [ - "IAO-03" + "AU-2-IS.1.k": [ + "CFG-02" ], - "SC.L3-3.13.4E": [ - "NET-02", - "NET-03.7", - "PES-04.1", - "PES-12", - "PES-18" + "AU-2-IS.1.l": [ + "CFG-02" ], - "RA.L3-3.11.1E": [ - "RSK-04", - "RSK-04.2", - "THR-03", - "THR-07" + "AU-2-IS.1.m": [ + "CFG-02" ], - "RA.L3-3.11.7E": [ - "RSK-06", - "RSK-09" + "AU-2-IS.1.n": [ + "CFG-02" ], - "RA.L3-3.11.6E": [ - "RSK-06.1", - "RSK-09", - "RSK-09.1" + "AU-2-IS.1.o": [ + "CFG-02" ], - "IR.L3-3.6.1E": [ - "OPS-04" + "AU-2-IS.1.p": [ + "CFG-02" ], - "RA.L3-3.11.3E": [ - "OPS-06" + "AU-2-IS.1.q": [ + "CFG-02" ], - "AT.L3-3.2.1E": [ - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.6" + "AU-2-IS.1.r": [ + "CFG-02" ], - "AT.L3-3.2.2E": [ - "SAT-03.1", - "SAT-03.6" + "AU-2-IS.1.s": [ + "CFG-02" ], - "CA.L3-3.12.1E": [ - "VPM-07" - ] - }, - "usa-federal-doc-data-privacy-framework-2023": { - "II.4.a": [ - "GOV-15", - "PRI-01.6", - "SEA-01" + "AU-2-IS.1.t": [ + "CFG-02" ], - "II.7.c": [ - "CPL-01" + "AU-2-IS.1.u": [ + "CFG-02" ], - "III.5.a": [ - "CPL-01", - "CPL-01.3" + "AU-2-IS.1.v": [ + "CFG-02" ], - "III.5.b.i": [ - "CPL-01" + "AU-2-IS.1.w": [ + "CFG-02" ], - "II.7.b": [ - "CPL-01.3" + "AU-2-IS.1.x": [ + "CFG-02" ], - "III.5.b.ii": [ - "CPL-05.2" + "AU-2-IS.1.y": [ + "CFG-02" ], - "III.8.c.i": [ - "DCH-03.1" + "AU-2-IS.2": [ + "CFG-02" ], - "III.8.d.i": [ - "DCH-03.1" + "AU-2-IS.2.a": [ + "CFG-02" ], - "III.14.d.i": [ - "DCH-03.1" + "AU-2-IS.2.b": [ + "CFG-02" ], - "III.14.a.i": [ - "DCH-23" + "AU-2-IS.2.c": [ + "CFG-02" ], - "III.14.g.i": [ - "DCH-23" + "AU-2-IS.2.d": [ + "CFG-02" ], - "III.9.b.iii": [ - "HRS-01", - "PRI-01.5" + "AU-2-IS.2.e": [ + "CFG-02" ], - "III.15.a": [ - "PRI-01" + "AU-2-IS.2.f": [ + "CFG-02" ], - "II.3.a": [ - "PRI-01.5", - "TPM-05" + "AU-2-IS.2.g": [ + "CFG-02" ], - "II.3.b": [ - "PRI-01.5", - "TPM-05" + "AU-2-IS.2.h": [ + "CFG-02" ], - "III.9.b.i": [ - "PRI-01.5" + "AU-2-IS.3": [ + "CFG-02" ], - "III.9.b.ii": [ - "PRI-01.5" + "AU-8(1)-IS.2": [ + "CFG-02" ], - "III.9.c.i": [ - "PRI-01.5" + "AU-8(1)-IS.3": [ + "CFG-02" ], - "III.9.d.i": [ - "PRI-01.5" + "CM-2": [ + "CFG-02", + "CFG-02.1" ], - "III.9.d.ii": [ - "PRI-01.5" + "CM-6": [ + "CFG-02", + "CFG-02.7" ], - "III.9.e.i": [ - "PRI-01.5" + "CM-6.a": [ + "CFG-02" ], - "III.10.a.i": [ - "PRI-01.5", - "TPM-05" + "CM-6.b": [ + "CFG-02" ], - "III.10.a.ii.1": [ - "PRI-01.5", - "TPM-05", - "TPM-05.2" + "CM-6-IS.2": [ + "CFG-02" ], - "III.10.a.ii.2": [ - "PRI-01.5", - "TPM-05", - "TPM-05.2" + "CM-6-IS.3": [ + "CFG-02" ], - "III.10.a.ii.3": [ - "PRI-01.5", - "TPM-05", - "TPM-05.2" + "CM-7-IS.2": [ + "CFG-02" ], - "III.10.a.iii": [ - "PRI-01.5", - "TPM-05", - "TPM-05.2" + "IA-2(11)-IS": [ + "CFG-02" ], - "III.10.b.i": [ - "PRI-01.5" + "SA-8": [ + "CFG-02", + "SEA-01" ], - "III.10.c.i": [ - "PRI-01.5" + "SA-11-IS.2": [ + "CFG-02" ], - "III.8.c.ii": [ - "PRI-01.7" + "CM-2(1)": [ + "CFG-02.1" ], - "III.14.e.i": [ - "PRI-01.7" + "CM-2(1).a": [ + "CFG-02.1" ], - "II.1.a.i": [ - "PRI-02" + "CM-2(1).b": [ + "CFG-02.1" ], - "II.1.a.ii": [ - "PRI-02" + "CM-2(1).c": [ + "CFG-02.1" ], - "II.1.a.iii": [ - "PRI-02" + "CM-2(1).d": [ + "CFG-02.1" ], - "II.1.a.iv": [ - "PRI-02", - "PRI-02.1" + "CM-1-IS.2": [ + "CFG-02.2" ], - "II.1.a.v": [ - "PRI-02" + "CM-6.d": [ + "CFG-02.2" ], - "II.1.a.vi": [ - "PRI-02" + "CM-6(1)": [ + "CFG-02.2" ], - "II.1.a.vii": [ - "PRI-02" + "CM-2(3)": [ + "CFG-02.3" ], - "II.1.a.viii": [ - "PRI-02" + "CM-6.c": [ + "CFG-02.7" ], - "II.1.a.ix": [ - "PRI-02" + "CM-6-IS.1": [ + "CFG-02.9" ], - "II.1.a.x": [ - "PRI-02" + "CM-6-IS.1.a": [ + "CFG-02.9" ], - "II.1.a.xi": [ - "PRI-02" + "CM-6-IS.1.b": [ + "CFG-02.9" ], - "II.1.a.xii": [ - "PRI-02" + "CM-6-IS.1.c": [ + "CFG-02.9" ], - "II.1.a.xiii": [ - "PRI-02" + "CM-6-IS.1.d": [ + "CFG-02.9" ], - "II.1.b": [ - "PRI-02" + "CM-7": [ + "CFG-03" ], - "III.11.d.i": [ - "PRI-02", - "PRI-06.4" + "CM-7.a": [ + "CFG-03" ], - "III.11.d.ii": [ - "PRI-02" + "CM-7.b": [ + "CFG-03" ], - "III.14.b.ii": [ - "PRI-02", - "PRI-03.2" + "CM-7-IS.1": [ + "CFG-03" ], - "II.5.a": [ - "PRI-02.1", - "PRI-04", - "PRI-04.5", - "PRI-05.2" + "CM-7(1)": [ + "CFG-03.1" ], - "II.2.a": [ - "PRI-03" + "CM-7(1).a": [ + "CFG-03.1" ], - "II.2.c": [ - "PRI-03", - "PRI-03.7", - "PRI-05.4" + "CM-7(1).b": [ + "CFG-03.1" ], - "III.14.b.i": [ - "PRI-03.2" + "CM-7(2)": [ + "CFG-03.2", + "SEA-06" ], - "II.2.b": [ - "PRI-03.6" + "CM-7(4)": [ + "CFG-03.3" ], - "III.12.a": [ - "PRI-03.7" + "CM-7(4).a": [ + "CFG-03.3" ], - "III.12.b": [ - "PRI-03.7" + "CM-7(4).b": [ + "CFG-03.3" ], - "III.14.c.i": [ - "PRI-03.9" + "CM-7(4).c": [ + "CFG-03.3" ], - "II.5.b": [ - "PRI-05" + "SC-7(7)": [ + "CFG-03.4" ], - "II.6.a": [ - "PRI-06", - "PRI-06.1" + "CM-10": [ + "CFG-04" ], - "III.8.a.i": [ - "PRI-06" + "CM-10.a": [ + "CFG-04" ], - "III.8.a.i.1": [ - "PRI-06" + "CM-10.b": [ + "CFG-04" ], - "III.8.a.i.2": [ - "PRI-06" + "CM-10.c": [ + "CFG-04" ], - "III.8.a.i.3": [ - "PRI-06" + "CM-10(1)": [ + "CFG-04.1" ], - "III.8.a.iii": [ - "PRI-06" + "CM-10(1).a": [ + "CFG-04.1" ], - "III.8.b.i": [ - "PRI-06" + "CM-10(1).b": [ + "CFG-04.1" ], - "III.8.b.ii": [ - "PRI-06" + "CM-10(1).c": [ + "CFG-04.1" ], - "III.8.d.ii": [ - "PRI-06" + "CM-11": [ + "CFG-05", + "END-03" ], - "III.8.e.i": [ - "PRI-06" + "CM-11.a": [ + "CFG-05" ], - "III.8.f.i": [ - "PRI-06" + "CM-11.b": [ + "CFG-05" ], - "III.14.e.ii": [ - "PRI-06" + "CM-11.c": [ + "CFG-05" ], - "II.7.a.i": [ - "PRI-06.4" + "SI-4": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "III.8.i.i": [ - "PRI-06.4" + "SI-4.a": [ + "MON-01" ], - "III.8.g.i": [ - "PRI-07.5" + "SI-4.a.1": [ + "MON-01" ], - "III.8.h.i": [ - "PRI-07.5" + "SI-4.a.2": [ + "MON-01" ], - "II.7.a.ii": [ - "OPS-01.1" + "SI-4.b": [ + "MON-01" ], - "II.7.d": [ - "TPM-05", - "TPM-05.2" - ] - }, - "usa-federal-dow-zt-roadmap-1-1": { - "6.1.1": [ - "GOV-02" + "SI-4.c": [ + "MON-01" ], - "2.3.7": [ - "GOV-02.1", - "CRY-09.6", - "SEA-07.1" + "SI-4.d": [ + "MON-01" ], - "2.7.3": [ - "GOV-02.1", - "MON-01.2", - "END-06.8" + "SI-4.e": [ + "MON-01" ], - "4.7.6": [ - "AAT-01", - "CLD-15", - "DCH-27", - "NET-17" + "SI-4.f": [ + "MON-01" ], - "6.4": [ - "AAT-01", - "AAT-32" + "SI-4.g": [ + "MON-01" ], - "6.4.1": [ - "AAT-01" + "SI-4.g.1": [ + "MON-01" ], - "6.4.2": [ - "AAT-01", - "AAT-32" + "SI-4.g.2": [ + "MON-01" ], - "6.2": [ - "AAT-32" + "SI-4.h": [ + "MON-01" ], - "6.2.2": [ - "AAT-32" + "SI-4.i": [ + "MON-01" ], - "6.3": [ - "AAT-32" + "SI-4.j": [ + "MON-01" ], - "6.3.1": [ - "AAT-32" + "SI-4.k": [ + "MON-01" ], - "7.6": [ - "AAT-32" + "SI-4-IS.1": [ + "MON-01" ], - "6.2.1": [ - "AAT-32.1" + "SI-4(1)": [ + "MON-01.1" ], - "6.5.1": [ - "AAT-32.1" + "SI-4(2)": [ + "MON-01.2" ], - "6.7.4": [ - "AAT-32.1", - "OPS-06" + "SI-4(4)": [ + "MON-01.3" ], - "2.2": [ - "AST-01", - "NET-14.7" + "SI-4(5)": [ + "MON-01.4" ], - "2.1": [ - "AST-02", - "AST-31.3" + "SI-4(5).a": [ + "MON-01.4" ], - "2.1.1": [ - "AST-02", - "AST-02.9" + "SI-4(5).b": [ + "MON-01.4" ], - "3.1": [ - "AST-02" + "SI-4(5).c": [ + "MON-01.4" ], - "3.1.1": [ - "AST-02", - "TDA-04.2" + "SI-4(5).d": [ + "MON-01.4" ], - "4.1.1": [ - "AST-02.8", - "AST-04" + "SI-4(14)": [ + "MON-01.5" ], - "5.1": [ - "AST-02.8", - "AST-04" + "AU-2": [ + "MON-01.8", + "MON-02" ], - "2.4": [ - "AST-16", - "NET-14", - "NET-14.7" + "AU-6-IS.1": [ + "MON-01.8" ], - "2.4.2": [ - "AST-16", - "EMB-01", - "END-01", - "IAC-29" + "AU-6-IS.2": [ + "MON-01.8" ], - "4.4.6": [ - "AST-28.1", - "MON-02.1" + "AU-6-IS.3": [ + "MON-01.8" ], - "3.4.6": [ - "AST-31.3", - "THR-11" + "AU-6-IS.4": [ + "MON-01.8" ], - "5.1.2": [ - "AST-31.3", - "DCH-05", - "NET-04.7" + "AU-6-IS.5": [ + "MON-01.8" ], - "5.2.4": [ - "AST-32" + "AU-6-IS.6": [ + "MON-01.8" ], - "7.2.4": [ - "AST-32", - "MON-02.3" + "AU-6-IS.7": [ + "MON-01.8" ], - "7.1.1": [ - "CAP-01", - "CAP-03", - "CAP-05" + "AU-2.a": [ + "MON-02" ], - "6.6": [ - "CLD-04" + "AU-2.b": [ + "MON-02" ], - "6.6.2": [ - "CLD-04", - "CFG-02" + "AU-2.c": [ + "MON-02" ], - "6.6.3": [ - "CLD-04", - "CFG-02" + "AU-6": [ + "MON-02", + "MON-02.6" ], - "3.4.1": [ - "CLD-04.1" + "AU-6.a": [ + "MON-02" ], - "4.7.4": [ - "CLD-09", - "CLD-15", - "DCH-27", - "NET-17" + "AU-6(3)": [ + "MON-02.1" ], - "4.7": [ - "CLD-15", - "CFG-08", - "DCH-27", - "IAC-21" + "AU-6.b": [ + "MON-02.6" ], - "4.7.1": [ - "CLD-15" + "AU-12(1)": [ + "MON-02.7" ], - "4.7.2": [ - "CLD-15" + "AU-3": [ + "MON-03" ], - "4.7.3": [ - "CLD-15" + "AU-3(1).a": [ + "MON-03" ], - "4.7.5": [ - "CLD-15" + "AU-3(1).b": [ + "MON-03" ], - "4.7.7": [ - "CLD-15", - "DCH-27", - "NET-17" + "AU-3(1).c": [ + "MON-03" ], - "6.6.1": [ - "CPL-01", - "CPL-03" + "AU-3(1)-IS.1": [ + "MON-03" ], - "1.8.2": [ - "CFG-02", - "IAC-10" + "AU-3(1)-IS.1.a": [ + "MON-03" ], - "2.5.1": [ - "CFG-02", - "CFG-02.2", - "NET-14.7" + "AU-3(1)-IS.1.b": [ + "MON-03" ], - "3.5": [ - "MON-01" + "AU-3(1)-IS.1.c": [ + "MON-03" ], - "7.3.1": [ - "MON-01" + "AU-3(1)-IS.1.d": [ + "MON-03" ], - "2.7.2": [ - "MON-01.2", - "END-01.1", - "END-06.2", - "END-06.8" + "AU-3(1)-IS.2": [ + "MON-03" ], - "5.2.2": [ - "MON-01.2", - "NET-04.7", - "NET-06.7" + "AU-3(1)": [ + "MON-03.1" ], - "7.2": [ - "MON-01.2" + "AU-6(1)": [ + "MON-03.1" ], - "7.2.1": [ - "MON-01.2" + "AU-2(3)": [ + "MON-03.6" ], - "2.3.3": [ - "MON-01.7", - "IAC-29" + "AU-2(3)-IS.1": [ + "MON-03.6" ], - "2.3.5": [ - "MON-01.7", - "IAC-29", - "NET-14.7" + "AU-4": [ + "MON-04" ], - "7.1.2": [ - "MON-01.16" + "AU-5": [ + "MON-05" ], - "3.5.1": [ - "MON-02", - "MON-02.1", - "MON-02.3" + "AU-5(1)": [ + "MON-05.2" ], - "3.5.2": [ - "MON-02", - "MON-02.1", - "MON-02.3" + "AU-7": [ + "MON-06" ], - "7.1": [ - "MON-02", - "MON-02.7", - "MON-03" + "AU-7.a": [ + "MON-06" ], - "4.4.3": [ - "MON-02.1", - "MON-18" + "AU-7.b": [ + "MON-06" ], - "4.4.4": [ - "MON-02.1", - "MON-18" + "AU-7(1)": [ + "MON-06" ], - "4.4.5": [ - "MON-02.1", - "MON-18" + "AU-12": [ + "MON-06" ], - "7.2.2": [ - "MON-02.1" + "AU-12.a": [ + "MON-06" ], - "7.1.3": [ - "MON-02.2", - "MON-06.2" + "AU-12.b": [ + "MON-06" ], - "7.2.3": [ - "MON-02.2", - "MON-02.3" + "AU-12.c": [ + "MON-06" ], - "1.6.1": [ - "MON-16" + "AU-12-IS": [ + "MON-06" ], - "1.6.2": [ - "MON-16", - "IAC-29" + "AU-8": [ + "MON-07", + "SEA-20" ], - "1.6.3": [ - "MON-16", - "IAC-29" + "AU-8.b": [ + "MON-07" ], - "2.3.1": [ - "MON-16", - "IAC-29" + "AU-9": [ + "MON-08" ], - "2.3.2": [ - "MON-16", - "IAC-29" + "AU-9(4)": [ + "MON-08.2" ], - "7.2.5": [ - "MON-16", - "THR-11" + "AU-10": [ + "MON-09" ], - "7.3.2": [ - "MON-16", - "THR-11" + "AU-11": [ + "MON-10" ], - "7.4": [ - "MON-16", - "THR-11" + "AU-11-IS.1": [ + "MON-10" ], - "7.4.1": [ - "MON-16" + "AU-11-IS.2": [ + "MON-10" ], - "7.4.2": [ - "MON-16", - "THR-11" + "AU-16": [ + "MON-14" ], - "7.4.3": [ - "MON-16" + "SC-8(1)": [ + "CRY-01", + "CRY-01.1", + "CRY-03" ], - "7.4.4": [ - "MON-16" + "SC-8(2)": [ + "CRY-01", + "CRY-01.3", + "DCH-10" ], - "4.5": [ + "SC-13": [ "CRY-01", + "CRY-01.2", + "CRY-05" + ], + "IA-7": [ + "CRY-02", + "IAC-12" + ], + "SC-8": [ "CRY-03", + "CRY-04" + ], + "SC-8-IS.1": [ + "CRY-04" + ], + "SC-28": [ "CRY-05", - "DCH-27" + "END-02" ], - "1.9.1": [ - "CRY-08", - "IAC-01.2", - "IAC-10.2" + "SC-28-iS": [ + "CRY-05" ], - "2.1.2": [ - "CRY-08", - "IAC-04", - "IAC-10.2" + "AC-18": [ + "CRY-07", + "NET-15" ], - "2.3.6": [ - "CRY-08", - "CRY-09" + "SC-12": [ + "CRY-08" ], - "5.4.4": [ - "DCH-01.2" + "SC-17": [ + "CRY-08" ], - "4.1": [ - "DCH-02", - "TDA-06.2" + "SC-12(2)": [ + "CRY-09.1" + ], + "SI-12": [ + "DCH-01", + "DCH-18", + "PRI-05" + ], + "MP-2": [ + "DCH-03", + "END-01" + ], + "AC-3(9)": [ + "DCH-03.3" ], - "4.2": [ - "DCH-02", - "PRI-11" + "AC-3(9).a": [ + "DCH-03.3" ], - "4.3.3": [ - "DCH-05", - "PRI-11" + "AC-3(9).b": [ + "DCH-03.3" ], - "4.3.5": [ - "DCH-05" + "MP-3": [ + "DCH-04", + "DCH-04.1" ], - "1.6": [ - "DCH-05.1", - "IAC-29" + "MP-3.a": [ + "DCH-04" ], - "4.3.4": [ - "DCH-27", - "NET-17" + "MP-3.b": [ + "DCH-04" ], - "4.4.2": [ - "DCH-27", - "HRS-05.1" + "MP-4": [ + "DCH-06" ], - "4.5.1": [ - "DCH-27" + "MP-4.a": [ + "DCH-06" ], - "4.5.2": [ - "DCH-27" + "MP-4.b": [ + "DCH-06" ], - "4.5.3": [ - "DCH-27" + "MP-4-IS.1": [ + "DCH-06" ], - "4.5.4": [ - "DCH-27" + "MP-5": [ + "DCH-07" ], - "4.5.5": [ - "DCH-27" + "MP-5.a": [ + "DCH-07" ], - "2.4.3": [ - "END-01", - "NET-14.7" + "MP-5.b": [ + "DCH-07" ], - "2.4.4": [ - "END-01", - "NET-14.7" + "MP-5.c": [ + "DCH-07" ], - "2.6": [ - "END-01.1" + "MP-5.d": [ + "DCH-07" ], - "2.6.1": [ - "END-01.1" + "MP-5-IS.1": [ + "DCH-07" ], - "2.6.2": [ - "END-01.1" + "MP-5-IS.2": [ + "DCH-07" ], - "2.6.3": [ - "END-01.1" + "MP-5-IS.3": [ + "DCH-07" ], - "2.7": [ - "END-01.1", - "END-06.2" + "MP-CMS-1": [ + "DCH-07" ], - "2.3.4": [ - "END-06.2" + "MP-CMS-1-IS.1": [ + "DCH-07" ], - "2.7.1": [ - "END-06.2" + "MP-CMS-1-IS.1.a": [ + "DCH-07" ], - "1.1.1": [ - "IAC-01", - "IAC-01.2", - "IAC-28" + "MP-CMS-1-IS.1.b": [ + "DCH-07" ], - "1.2.4": [ - "IAC-01" + "MP-CMS-1-IS.1.c": [ + "DCH-07" ], - "1.2.5": [ - "IAC-01" + "MP-CMS-1-IS.1.d": [ + "DCH-07" ], - "1.5.2": [ - "IAC-01" + "MP-CMS-1-IS.1.e": [ + "DCH-07" ], - "1.5.3": [ - "IAC-01" + "MP-CMS-1-IS.1.f": [ + "DCH-07" ], - "1.5.4": [ - "IAC-01" + "MP-5(4)": [ + "DCH-07.2" ], - "1.9": [ - "IAC-01", - "IAC-01.2", - "IAC-10.2" + "MP-6": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "1.2.1": [ - "IAC-01.2", - "IAC-16", - "IAC-29" + "MP-6.a": [ + "DCH-09" ], - "2.1.3": [ - "IAC-01.2", - "IAC-04", - "IAC-13.2" + "MP-6.b": [ + "DCH-09" ], - "2.1.4": [ - "IAC-01.2", - "IAC-04", - "IAC-13.2" + "MP-6-IS.1": [ + "DCH-09" ], - "1.1": [ - "IAC-01.3" + "MP-6-IS.2": [ + "DCH-09" ], - "1.8.1": [ - "IAC-02.3", - "IAC-10.1" + "MP-6-IS.4": [ + "DCH-09" ], - "1.3": [ - "IAC-06" + "MP-6-IS.3": [ + "DCH-09.1" ], - "1.3.1": [ - "IAC-06" + "MP-6-IS.3.a": [ + "DCH-09.1" ], - "1.3.3": [ - "IAC-06", - "IAC-29" + "MP-6-IS.3.b": [ + "DCH-09.1" ], - "1.3.2": [ - "IAC-06.4" + "MP-6-IS.3.c": [ + "DCH-09.1" ], - "1.9.3": [ - "IAC-06.5", - "IAC-10.12" + "MP-6-IS.3.d": [ + "DCH-09.1" ], - "1.2": [ - "IAC-08", - "IAC-29" + "MP-6-IS.3.e": [ + "DCH-09.1" ], - "1.9.2": [ - "IAC-10.12" + "MP-6(1)": [ + "DCH-09.1" ], - "1.5": [ - "IAC-13.2" + "MP-6(1)-IS": [ + "DCH-09.1" ], - "1.5.1": [ - "IAC-13.2" + "MP-6(2)": [ + "DCH-09.2" ], - "1.8": [ - "IAC-13.3", - "IAC-29" + "MP-7": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "1.8.4": [ - "IAC-13.3", - "IAC-29" + "MP-7(1)": [ + "DCH-10.2" ], - "1.2.2": [ - "IAC-16", - "IAC-29" + "AC-20": [ + "DCH-13" ], - "1.4": [ - "IAC-16" + "AC-20.a": [ + "DCH-13" ], - "1.4.1": [ - "IAC-16" + "AC-20.b": [ + "DCH-13" ], - "1.4.2": [ - "IAC-16", - "IAC-29" + "AC-20-IS": [ + "DCH-13" ], - "1.4.3": [ - "IAC-16" + "AC-20-IS.1": [ + "DCH-13" ], - "1.4.4": [ - "IAC-16", - "IAC-29" + "AC-20-IS.2": [ + "DCH-13" ], - "1.8.3": [ - "IAC-16.3" + "AC-20-IS.3": [ + "DCH-13" ], - "1.7.1": [ - "IAC-17" + "AC-20(1)": [ + "DCH-13.1" ], - "1.7": [ - "IAC-21" + "AC-20(1).a": [ + "DCH-13.1" ], - "1.2.3": [ - "IAC-29" + "AC-20(1).b": [ + "DCH-13.1" ], - "5.2.5": [ - "IAC-29.1" + "AC-20(2)": [ + "DCH-13.2" ], - "6.1.3": [ - "IAC-29.1", - "IAC-29.2" + "AC-20(2)-IS.a": [ + "DCH-13.2" ], - "6.1.2": [ - "IAC-29.2" + "AC-21": [ + "DCH-14", + "PRI-07" ], - "6.1.4": [ - "IAC-29.2" + "AC-21.a": [ + "DCH-14" ], - "6.7.2": [ - "IRO-02", - "IRO-02.4" + "AC-21.b": [ + "DCH-14" ], - "6.7.1": [ - "IRO-04", - "OPS-01.1" + "AC-22": [ + "DCH-15" ], - "5.1.1": [ - "NET-01", - "NET-01.1" + "AC-22.a": [ + "DCH-15" ], - "6.2.3": [ - "NET-01.1" + "AC-22.b": [ + "DCH-15" ], - "4.4": [ - "NET-04.5" + "AC-22.c": [ + "DCH-15" ], - "3.4.2": [ - "NET-04.7" + "AC-22.d": [ + "DCH-15" ], - "5.2": [ - "NET-04.7" + "SI-12-IS.1": [ + "DCH-18" ], - "6.1": [ - "NET-04.7" + "DM-2": [ + "DCH-21", + "PRI-05" ], - "5.2.3": [ - "NET-06" + "DM-2.b": [ + "DCH-21" ], - "5.3": [ - "NET-06" + "DM-2.c": [ + "DCH-21" ], - "5.3.2": [ - "NET-06" + "DI-1": [ + "DCH-22" ], - "3.4.7": [ - "NET-06.6", - "NET-06.7" + "DI-1.a": [ + "DCH-22" ], - "5.3.1": [ - "NET-06.6" + "DI-1.b": [ + "DCH-22" ], - "5.4": [ - "NET-06.6" + "DI-1.c": [ + "DCH-22" ], - "5.4.1": [ - "NET-06.6" + "DI-1.d": [ + "DCH-22" ], - "5.4.2": [ - "NET-06.6", - "NET-06.7" + "IP-3": [ + "DCH-22.1", + "PRI-06.1" ], - "5.4.3": [ - "NET-06.6" + "DM-1(1)": [ + "DCH-23" ], - "5.2.1": [ - "NET-06.7" + "SI-3": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "2.2.2": [ - "NET-14.3", - "NET-14.7" + "SI-3.a": [ + "END-04" ], - "2.4.1": [ - "NET-14.3", - "NET-14.7" + "SI-3.b": [ + "END-04" ], - "2.2.1": [ - "NET-14.7" + "SI-3.c": [ + "END-04" ], - "4.4.1": [ - "NET-17" + "SI-3.c.1": [ + "END-04" ], - "4.6": [ - "NET-17" + "SI-3.c.2": [ + "END-04" ], - "4.6.1": [ - "NET-17" + "SI-3.d": [ + "END-04" ], - "4.6.2": [ - "NET-17" + "SI-2": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "4.6.3": [ - "NET-17" + "SI-3(2)": [ + "END-04.1" ], - "4.6.4": [ - "NET-17" + "SI-3(1)": [ + "END-04.3" ], - "4.3": [ - "PRI-11" + "SI-7": [ + "END-06", + "NET-12", + "TDA-18" ], - "4.3.2": [ - "PRI-11" + "SI-7(1)": [ + "END-06.1" ], - "2.3": [ - "PRM-02.1" + "SI-7(7)": [ + "END-06.2" ], - "3.3": [ - "RSK-01", - "RSK-09", - "TDA-04.2", - "TDA-09" + "SI-8": [ + "END-08" ], - "3.4.3": [ - "SEA-13.1" + "SI-8.a": [ + "END-08" ], - "6.7": [ - "OPS-04" + "SI-8.b": [ + "END-08" ], - "7.3": [ - "OPS-04" + "SI-8(1)": [ + "END-08" ], - "7.5": [ - "OPS-04", - "THR-03.1" + "SI-8(2)": [ + "END-08.2" ], - "6.5.3": [ - "OPS-05" + "SC-18": [ + "END-10" ], - "6.5": [ - "OPS-06" + "SC-18.a": [ + "END-10" ], - "6.5.2": [ - "OPS-06" + "SC-18.b": [ + "END-10" ], - "3.2": [ - "TDA-01", - "TDA-06" + "SC-18.c": [ + "END-10" ], - "3.2.2": [ - "TDA-01", - "TDA-01.4" + "SC-15": [ + "END-14" ], - "3.2.1": [ - "TDA-01.4" + "SC-15.a": [ + "END-14" ], - "3.4.4": [ - "TDA-04.2" + "SC-15.b": [ + "END-14" ], - "3.2.4": [ - "TDA-06" + "SC-7(12)": [ + "END-16.1" ], - "3.2.3": [ - "TDA-09" + "PS-2": [ + "HRS-02", + "HRS-03.2" ], - "3.3.4": [ - "TDA-09" + "PS-2.a": [ + "HRS-02" ], - "3.3.1": [ - "TDA-20", - "TDA-20.4" + "PS-2.b": [ + "HRS-02" ], - "3.3.3": [ - "THR-03" + "PS-2.c": [ + "HRS-02" ], - "6.7.3": [ - "THR-03" + "PM-13": [ + "HRS-03", + "SAT-01" ], - "7.5.1": [ - "THR-03.1" + "PS-3": [ + "HRS-04" ], - "7.5.2": [ - "THR-03.1" + "PS-3.a": [ + "HRS-04" ], - "3.4.5": [ - "THR-11" + "PS-3.b": [ + "HRS-04" ], - "2.5": [ - "VPM-01", - "VPM-05", - "VPM-05.1" + "PS-3.c": [ + "HRS-04" ], - "3.3.2": [ - "VPM-01" - ] - }, - "usa-federal-dow-zta-reference-architecture-2-0": { - "8.5": [ - "GOV-10" + "PS-3-IS.1": [ + "HRS-04" ], - "2.2.1": [ - "AST-01", - "AST-02.6", - "AST-02.9" + "PS-3-IS.2": [ + "HRS-04" ], - "4.2": [ - "AST-03.2", - "AST-18", - "RSK-09", - "TDA-04.2", - "TDA-06.3" + "PL-4": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "2.2.2": [ - "CHG-04.1", - "CFG-02.2" + "PL-4.a": [ + "HRS-05.1" ], - "2.2.3": [ - "CFG-02.2" + "PL-4.b": [ + "HRS-05.1" ], - "6.5": [ - "MON-01" + "PL-4.c": [ + "HRS-05.1" ], - "6.2": [ - "MON-01.2" + "PL-4.d": [ + "HRS-05.1" ], - "1.2": [ - "MON-16", - "THR-11" + "PL-4-IS": [ + "HRS-05.1" ], - "6.7": [ - "MON-16" + "PL-4(1)": [ + "HRS-05.2" ], - "5.1": [ - "CRY-01" + "PS-6": [ + "HRS-06", + "HRS-06.1" ], - "5.1.1": [ - "CRY-03" + "PS-6.a": [ + "HRS-06" ], - "5.1.2": [ - "CRY-05" + "PS-6.b": [ + "HRS-06" ], - "5.0": [ - "DCH-01", - "DCH-01.2", - "DCH-01.4", - "DCH-02" + "PS-6.c": [ + "HRS-06" ], - "5.6": [ - "DCH-02" + "PS-6.c.1": [ + "HRS-06" ], - "5.6.1": [ - "DCH-04.1" + "PS-6.c.2": [ + "HRS-06" ], - "5.3": [ - "DCH-27" + "PS-8": [ + "HRS-07" ], - "1.1": [ - "IAC-06" + "PS-8.a": [ + "HRS-07" ], - "1.0": [ - "IAC-13.3" + "PS-8.b": [ + "HRS-07" ], - "2.0": [ - "IAC-15.8" + "PS-5": [ + "HRS-08" ], - "2.3": [ - "IAC-16" + "PS-5.a": [ + "HRS-08" ], - "2.4": [ - "IAC-16" + "PS-5.b": [ + "HRS-08" ], - "3.0": [ - "NET-01", - "NET-01.1", - "SEA-01", - "SEA-02", - "SEA-03" + "PS-5.b.1": [ + "HRS-08" ], - "3.1": [ - "NET-06" + "PS-5.b.2": [ + "HRS-08" ], - "3.2": [ - "NET-06.6" + "PS-5.b.3": [ + "HRS-08" ], - "2.2": [ - "NET-14.7" + "PS-5.b.4": [ + "HRS-08" ], - "5.4": [ - "NET-17" + "PS-5.c": [ + "HRS-08" ], - "3.2.1": [ - "PRM-06" + "PS-5.d": [ + "HRS-08" ], - "8.6": [ - "RSK-01" - ] - }, - "usa-federal-dow-dfars-252-204-7012": { - "252.204-7012(b)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "TPM-05", - "TPM-05.2" + "PS-4": [ + "HRS-09" ], - "252.204-7012(b)(2)(i)": [ - "GOV-15.1" + "PS-4.a": [ + "HRS-09" ], - "252.204-7012(b)(2)(ii)(A)": [ - "GOV-15.1" + "PS-4.b": [ + "HRS-09" ], - "252.204-7012(b)(3)": [ - "GOV-15.1" + "PS-4.c": [ + "HRS-09" ], - "252.204-7012(b)(2)(ii)(B)": [ - "GOV-17", - "IAO-05", - "RSK-06.2" + "PS-4.d": [ + "HRS-09" ], - "252.204-7012(b)(1)(i)": [ - "CPL-01" + "PS-4.e": [ + "HRS-09" ], - "252.204-7012(b)(1)(ii)": [ - "CPL-01" + "PS-4.f": [ + "HRS-09" ], - "252.204-7012(k)": [ - "CPL-01" + "PS-4.g": [ + "HRS-09" ], - "252.204-7012(c)(1)(i)": [ - "IRO-02" + "PS-4-IS.1": [ + "HRS-09" ], - "252.204-7012(e)": [ - "IRO-08" + "PS-4-IS.2": [ + "HRS-09" ], - "252.204-7012(c)(1)(ii)": [ - "IRO-10.2" + "PS-7": [ + "HRS-10" ], - "252.204-7012(c)(2)": [ - "IRO-10.2" + "PS-7.a": [ + "HRS-10" ], - "252.204-7012(c)(3)": [ - "IRO-10.2" + "PS-7.b": [ + "HRS-10" ], - "252.204-7012(d)": [ - "IRO-10.2" + "PS-7.c": [ + "HRS-10" ], - "252.204-7012(f)": [ - "IRO-11.2" + "PS-7.d": [ + "HRS-10" ], - "252.204-7012(g)": [ - "IRO-11.2" + "PS-7.e": [ + "HRS-10" ], - "252.204-7012(b)(2)(ii)(C)": [ - "RSK-06.2" + "PS-7-IS.1": [ + "HRS-10" ], - "252.204-7012(b)(2)(ii)(D)": [ - "TPM-01" + "AC-5.a": [ + "HRS-11" ], - "252.204-7012(m)(1)": [ - "TPM-05" + "AC-5.b": [ + "HRS-11" ], - "252.204-7012(m)(2)(i)": [ - "TPM-05.2" - ] - }, - "usa-federal-eo-14028": { - "4e(i)(F)": [ - "GOV-01", - "GOV-15", - "MON-01", - "IRO-01" + "AC-5.c": [ + "HRS-11" ], - "4e(ii)": [ - "CPL-01.3" + "AC-5-IS.1": [ + "HRS-11" ], - "4e(v)": [ - "CPL-01.5" + "AC-5-IS.2": [ + "HRS-11" ], - "4e(ix)": [ - "CPL-01.5" + "AC-5-IS.3": [ + "HRS-11" ], - "4e(x)": [ - "CPL-01.5" + "AC-5-IS.4": [ + "HRS-11" ], - "4e(i)": [ - "CFG-02.4", - "TDA-07", - "TDA-08", - "TDA-08.1" + "AC-5-IS.5": [ + "HRS-11" ], - "4e(i)(B)": [ - "MON-01", - "MON-01.3", - "MON-01.4", - "MON-02.7", - "MON-03", - "MON-03.2" + "AC-2-IS.3": [ + "IAC-01.2", + "IAC-15.1" ], - "4e(i)(E)": [ - "CRY-01", - "TDA-02", - "TDA-02.4", - "TDA-06" + "IA-4": [ + "IAC-01.2", + "IAC-09" ], - "4e(i)(C)": [ - "IAC-06" + "IA-2": [ + "IAC-02" ], - "4e(i)(D)": [ - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-02.1", - "TDA-04.1", - "TDA-05", - "TDA-06.1", - "TDA-06.2", - "TDA-06.3", - "TDA-09.6" + "IA-2-IS.1": [ + "IAC-02" ], - "4e(iv)": [ - "TDA-01", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-15", - "THR-06", - "VPM-01", - "VPM-02" + "IA-2-IS.2": [ + "IAC-02" ], - "4e(iii)": [ - "TDA-01.1", - "TDA-02.3", - "TDA-04.2", - "TDA-06.3", - "TDA-06.4", - "TDA-09", - "TDA-14.1", - "TDA-15", - "TDA-20" + "IA-2-IS.3": [ + "IAC-02" ], - "4e(vii)": [ - "TDA-04.2" + "IA-2(8)": [ + "IAC-02.2" ], - "4e(i)(A)": [ - "TDA-07", - "TDA-08" + "IA-8": [ + "IAC-03" ], - "4e(vi)": [ - "TDA-20", - "TDA-20.1", - "TDA-20.3" + "IA-8-IS": [ + "IAC-03" ], - "4e(viii)": [ - "THR-06" - ] - }, - "usa-federal-law-facta-fcra-2023": { - "606(b)": [ - "HRS-07.1" + "IA-3": [ + "IAC-04" ], - "623(a)(1)(A)": [ - "PRI-01.11" + "IA-3-IS.1": [ + "IAC-04" ], - "623(a)(1)(B)": [ - "PRI-01.11" + "IA-2(1)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "623(a)(1)(B)(i)": [ - "PRI-01.11" + "IA-2(2)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "623(a)(1)(B)(ii)": [ - "PRI-01.11" + "IA-2(11)": [ + "IAC-06" ], - "615(e)(2)(A)": [ - "THR-01" - ] - }, - "usa-federal-far-52-204-21": { - "52.204-21(b)(1)": [ - "GOV-01", - "GOV-02", - "GOV-04", - "GOV-04.1", - "GOV-15", - "DCH-01", - "DCH-01.2" + "IA-2(3)": [ + "IAC-06.3" ], - "52.204-21(b)(1)(vii)": [ - "AST-01", - "AST-09", - "DCH-01", - "DCH-08", - "DCH-09" + "AC-2": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "52.204-21(b)(1)(iv)": [ - "CLD-01", - "CLD-02", - "CLD-06", - "CLD-10", - "DCH-15", - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "WEB-01", - "WEB-02", - "WEB-04" + "AC-2(7)": [ + "IAC-08" ], - "52.204-21(b)(1)(iii)": [ - "DCH-13", - "DCH-13.1", - "DCH-17" + "AC-2(7).a": [ + "IAC-08" ], - "52.204-21(b)(1)(xiii)": [ - "END-01", - "END-04" + "AC-2(7).b": [ + "IAC-08" ], - "52.204-21(b)(1)(xv)": [ - "END-04", - "END-04.7" + "AC-2(7).c": [ + "IAC-08" ], - "52.204-21(b)(1)(xiv)": [ - "END-04.1" + "AC-2(7).d": [ + "IAC-08" ], - "52.204-21(b)(1)(i)": [ - "IAC-01", - "IAC-02", - "IAC-08", - "IAC-15.1", - "IAC-20", - "TPM-01", - "TPM-05", - "TPM-05.2" + "IA-4.a": [ + "IAC-09" ], - "52.204-21(b)(1)(v)": [ - "IAC-02", - "IAC-04", - "IAC-15.1" + "IA-4.b": [ + "IAC-09" ], - "52.204-21(b)(1)(vi)": [ - "IAC-02", - "IAC-04", - "IAC-15.1" + "IA-4.c": [ + "IAC-09" ], - "52.204-21(b)(1)(ii)": [ - "IAC-08", - "IAC-15" + "IA-4.d": [ + "IAC-09" ], - "52.204-21(b)(1)(x)": [ - "NET-01", - "NET-02.2", - "NET-03" + "IA-4.e": [ + "IAC-09" ], - "52.204-21(b)(1)(xi)": [ - "NET-06" + "IA-4-IS.1": [ + "IAC-09" ], - "52.204-21(b)(1)(viii)": [ - "PES-02", - "PES-02.1", - "PES-03.4", - "PES-04", - "PES-12", - "PES-12.1", - "PES-12.2" + "IA-4-IS.2": [ + "IAC-09" ], - "52.204-21(b)(1)(ix)": [ - "PES-03", - "PES-06", - "PES-06.1", - "PES-06.3" + "IA-5": [ + "IAC-10", + "IAC-10.8" ], - "52.204-21(a)": [ - "SEA-02.1" + "IA-5(1)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "52.204-21(b)(1)(xii)": [ - "VPM-01", - "VPM-02", - "VPM-05" - ] - }, - "usa-federal-far-52-204-25": { - "52.204-25(d)(2)(i)": [ - "GOV-17" + "IA-5(1).a": [ + "IAC-10.1" ], - "52.204-25(d)(2)(ii)": [ - "GOV-17" + "IA-5(1).b": [ + "IAC-10.1" ], - "52.204-25(d)": [ - "GOV-17" + "IA-5(1).c": [ + "IAC-10.1" ], - "52.204-25(b)(1)": [ - "AST-17" + "IA-5(1).d": [ + "IAC-10.1" ], - "52.204-25(b)(2)": [ - "AST-17" - ] - }, - "usa-federal-far-52-204-27": { - "52.204-27(b)": [ - "AST-17" + "IA-5(1).d.1": [ + "IAC-10.1" ], - "52.204-27(c)": [ - "TPM-05", - "TPM-05.2" - ] - }, - "usa-federal-sro-fca-crm-2023": { - "609.930(a)": [ - "GOV-01", - "GOV-08", - "GOV-09", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "DCH-01", - "RSK-01", - "RSK-01.1", - "RSK-01.2", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-03", - "RSK-03.1", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-06.2" + "IA-5(1).d.2": [ + "IAC-10.1" ], - "609.930(d)": [ - "GOV-01", - "CPL-01", - "PRI-01" + "IA-5(1).d.3": [ + "IAC-10.1" ], - "609.930(b)(1)": [ - "GOV-01.1" + "IA-5(1).e": [ + "IAC-10.1" ], - "609.930(b)(2)": [ - "GOV-01.1" + "IA-5(1).f": [ + "IAC-10.1" ], - "609.930(e)": [ - "GOV-01.2" + "IA-5(1).g": [ + "IAC-10.1" ], - "609.930(c)(5)": [ - "GOV-02", - "TPM-01" + "IA-5(1).h": [ + "IAC-10.1" ], - "609.930(b)(3)": [ - "GOV-04", - "HRS-01", - "HRS-02", - "HRS-03", - "HRS-03.2" + "IA-5(2)": [ + "IAC-10.2" ], - "609.930(c)(6)": [ - "GOV-09", - "CPL-02", - "CPL-02.1", - "CPL-02.2" + "IA-5(2).a": [ + "IAC-10.2" ], - "609.930(c)(3)(iii)": [ - "BCD-01", - "BCD-02.1", - "IRO-02" + "IA-5(2).b": [ + "IAC-10.2" ], - "609.930(c)(1)(ii)": [ - "CPL-01", - "CPL-01.1", - "CPL-01.4", - "CPL-03.2" + "IA-5(2).c": [ + "IAC-10.2" ], - "609.930(c)(6)(iii)": [ - "CPL-01.4", - "CPL-03.2" + "IA-5(2).d": [ + "IAC-10.2" ], - "609.935(c)": [ - "CPL-01.4" + "IA-5(3)": [ + "IAC-10.3" ], - "609.930(c)(6)(i)": [ - "CPL-02" + "IA-5(7)": [ + "IAC-10.6" ], - "609.930(c)(6)(ii)": [ - "CPL-03.1" + "IA-5(11)": [ + "IAC-10.7" ], - "609.945": [ - "DCH-01", - "DCH-18" + "IA-6": [ + "IAC-11" ], - "609.930(c)(4)": [ - "HRS-01", - "HRS-01.1", - "HRS-03", - "HRS-03.1", - "HRS-05", - "HRS-05.1", - "HRS-05.7", - "HRS-06", - "HRS-06.1", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.6", - "TPM-01", - "TPM-05", - "TPM-06" + "AC-2.a": [ + "IAC-15" ], - "609.930(c)(3)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-04.2" + "AC-2.b": [ + "IAC-15" ], - "609.930(c)(3)(i)": [ - "IRO-02" + "AC-2.c": [ + "IAC-15" ], - "609.930(c)(3)(ii)": [ - "IRO-02" + "AC-2.d": [ + "IAC-15" ], - "609.930(c)(3)(iv)": [ - "IRO-09" + "AC-2.e": [ + "IAC-15" ], - "609.930(c)(3)(v)": [ - "IRO-10", - "IRO-10.2" + "AC-2.f": [ + "IAC-15" ], - "609.930(c)(3)(vi)": [ - "IRO-10" + "AC-2.f.1": [ + "IAC-15" ], - "609.935(d)": [ - "PRM-01" + "AC-2.f.1(i)": [ + "IAC-15" ], - "609.935(e)": [ - "PRM-01", - "PRM-05", - "PRM-06", - "PRM-07" + "AC-2.f.1(ii)": [ + "IAC-15" ], - "609.935": [ - "PRM-01.1" + "AC-2.f.1(iii)": [ + "IAC-15" ], - "609.935(a)": [ - "PRM-01.1" + "AC-2.f.2": [ + "IAC-15" ], - "609.935(b)": [ - "PRM-03" + "AC-2.f.3": [ + "IAC-15" ], - "609.930(c)(1)(i)": [ - "RSK-03" + "AC-2.f.3(i)": [ + "IAC-15" ], - "609.930(c)(1)": [ - "RSK-04" + "AC-2.f.3(ii)": [ + "IAC-15" ], - "609.930(c)(5)(i)": [ - "TPM-02", - "TPM-03.2", - "TPM-04", - "TPM-04.1" + "AC-2.f.3(iii)": [ + "IAC-15" ], - "609.930(c)(5)(iii)": [ - "TPM-04.1" + "AC-2.g": [ + "IAC-15" ], - "609.930(c)(5)(ii)": [ - "TPM-05", - "TPM-08" + "AC-2-IS.1": [ + "IAC-15" ], - "609.930(c)(5)(iv)": [ - "TPM-08" + "AC-2-IS.2": [ + "IAC-15" ], - "609.930(c)(2)": [ - "VPM-01", - "VPM-01.1", - "VPM-03", - "VPM-04", - "VPM-05" - ] - }, - "usa-federal-fda-21-cfr-part-11-2025": { - "11.10": [ - "GOV-02", - "CHG-01", - "CHG-02", - "CPL-01", - "CPL-02", - "CPL-03", - "CPL-03.2", - "MON-01", - "MON-01.16", - "MON-02", - "MON-03", - "MON-03.2", - "MON-07", - "MON-07.1", - "MON-08", - "CRY-01", - "CRY-03", - "CRY-04", - "CRY-05", - "CRY-08", - "CRY-09", - "DCH-01", - "DCH-18", - "HRS-03.2", - "HRS-05.1", - "IAC-01", - "IAC-02", - "IAC-04", - "IAC-08", - "IAC-21", - "IAO-01", - "MNT-01", - "SEA-01", - "SEA-02", - "SEA-03", - "OPS-01", - "OPS-01.1", - "OPS-03", - "SAT-01", - "SAT-03", - "SAT-03.5", - "TDA-09.4" + "AC-2-IS.4": [ + "IAC-15" ], - "11.30": [ - "GOV-15", - "IAO-03" + "AC-2(1)": [ + "IAC-15.1" ], - "11.10(k)(2)": [ - "CHG-02" + "AC-2(2)": [ + "IAC-15.2" ], - "11.10(b)": [ - "CPL-01", - "CPL-02", - "CPL-03", - "CPL-03.2", - "MON-02", - "MON-03", - "MON-03.2", - "MON-07", - "MON-07.1", - "MON-08", - "DCH-01", - "IAO-01" + "AC-2(3)": [ + "IAC-15.3" ], - "11.10(c)": [ - "CPL-01", - "CPL-02", - "CPL-03", - "CPL-03.2", - "MON-02", - "MON-03", - "MON-03.2", - "MON-07", - "MON-07.1", - "MON-08", - "CRY-01", - "CRY-03", - "CRY-04", - "CRY-05", - "DCH-01", - "IAO-01" + "AC-2(3).a": [ + "IAC-15.3" ], - "11.10(a)": [ - "CPL-02", - "CPL-03", - "CPL-03.2", - "MON-01.7", - "DCH-01", - "IAO-01", - "IAO-01.1", - "IAO-02" + "AC-2(3).b": [ + "IAC-15.3" ], - "11.300(e)": [ - "CPL-03.2" + "AC-2(4)": [ + "IAC-15.4" ], - "11.10(d)": [ - "CFG-02", - "DCH-01", - "IAC-01", - "IAC-02", - "IAC-08", + "AC-3": [ "IAC-20", - "IAC-21" + "NET-12", + "TDA-18" ], - "11.50(a)": [ - "CFG-02" + "AC-6": [ + "IAC-20", + "IAC-21" ], - "11.50(a)(1)": [ - "CFG-02" + "AC-6-IS.1": [ + "IAC-21" ], - "11.50(a)(2)": [ - "CFG-02" + "AC-6-IS.2": [ + "IAC-21" ], - "11.50(a)(3)": [ - "CFG-02" + "AC-6-IS.3": [ + "IAC-21" ], - "11.50(b)": [ - "CFG-02" + "AC-6-IS.4": [ + "IAC-21" ], - "11.70": [ - "CFG-02" + "AC-6(1)": [ + "IAC-21.1" ], - "11.200(a)(1)": [ - "CFG-02" + "AC-6(1).a": [ + "IAC-21.1" ], - "11.200(b)": [ - "CFG-02" + "AC-6(1).b": [ + "IAC-21.1" ], - "11.10(e)": [ - "MON-01", - "MON-02", - "MON-03", - "MON-03.2", - "MON-07", - "MON-07.1", - "MON-08", - "DCH-18" + "AC-6(1).c": [ + "IAC-21.1" ], - "11.300(c)": [ - "CRY-09" + "AC-6(1).d": [ + "IAC-21.1" ], - "11.10(k)": [ - "DCH-01", - "OPS-01.1" + "AC-6(1).e": [ + "IAC-21.1" ], - "11.10(k)(1)": [ - "DCH-03.1" + "AC-6(1)-IS.1": [ + "IAC-21.1" ], - "11.10(i)": [ - "HRS-01", - "HRS-02", - "HRS-02.1", - "HRS-03", - "HRS-03.2", - "HRS-04.2" + "AC-6(2)": [ + "IAC-21.2" ], - "11.10(j)": [ - "HRS-01", - "HRS-01.1", - "HRS-04.2", - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "AC-6(2).a": [ + "IAC-21.2" ], - "11.10(g)": [ - "IAC-01", - "IAC-17" + "AC-6(2).b": [ + "IAC-21.2" ], - "11.100(a)": [ - "IAC-01" + "AC-6(2).c": [ + "IAC-21.2" ], - "11.300(d)": [ - "IAC-10.5" + "AC-6(2).d": [ + "IAC-21.2" ], - "11.100(b)": [ - "IAC-28" + "AC-6(2).e": [ + "IAC-21.2" ], - "11.10(f)": [ - "OPS-01.1" + "AC-6(2)-IS.1": [ + "IAC-21.2" ], - "11.10(h)": [ - "TDA-18" - ] - }, - "usa-federal-gsa-fedramp-5-low": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "AC-6(5)": [ + "IAC-21.3" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "AC-6(9)": [ + "IAC-21.4" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "AC-6(10)": [ + "IAC-21.5" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "AC-7": [ + "IAC-22" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "AC-7.a": [ + "IAC-22" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "AC-7.b": [ + "IAC-22" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "AC-7-IS.1": [ + "IAC-22" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "AC-10": [ + "IAC-23" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "AC-11": [ + "IAC-24" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "AC-11.a": [ + "IAC-24" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "AC-11.b": [ + "IAC-24" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "AC-11(1)": [ + "IAC-24.1" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "AC-12": [ + "IAC-25" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "AC-14": [ + "IAC-26" ], - "PT-01": [ - "GOV-02", - "GOV-03", - "PRI-01", - "SEA-01" + "AC-14.a": [ + "IAC-26" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "AC-14.b": [ + "IAC-26" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "IR-4": [ + "IRO-02" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "IR-4.a": [ + "IRO-02" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "IR-4.b": [ + "IRO-02" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "IR-4.c": [ + "IRO-02" ], - "PL-09": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "IR-4.d": [ + "IRO-02" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "IR-4.e": [ + "IRO-02" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "IR-4.f": [ + "IRO-02" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "IR-4.g": [ + "IRO-02" ], - "PM-15": [ - "GOV-07", - "THR-01" + "IR-4.h": [ + "IRO-02" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "IR-4-IS": [ + "IRO-02" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "SE-2": [ + "IRO-02" ], - "PM-05": [ - "AST-01", - "AST-02" + "SE-2.a": [ + "IRO-02" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "SE-2.b": [ + "IRO-02" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "SE-2.c": [ + "IRO-02" ], - "SC-18(02)": [ - "AST-02.7", - "END-10" + "IR-4(1)": [ + "IRO-02.1" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "IR-8": [ + "IRO-04" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "IR-8.a": [ + "IRO-04" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "IR-8.a.1": [ + "IRO-04" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "IR-8.a.2": [ + "IRO-04" ], - "PE-22": [ - "AST-04.1", - "PES-16" + "IR-8.a.3": [ + "IRO-04" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "IR-8.a.4": [ + "IRO-04" ], - "SR-12": [ - "AST-09" + "IR-8.a.5": [ + "IRO-04" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "IR-8.a.6": [ + "IRO-04" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "IR-8.a.7": [ + "IRO-04" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "IR-8.a.8": [ + "IRO-04" ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" + "IR-8.a.9": [ + "IRO-04" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "IR-8.a.9(i)": [ + "IRO-04" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "IR-8.a.9(ii)": [ + "IRO-04" ], - "CP-03": [ - "BCD-03" + "IR-8.a.9(iii)": [ + "IRO-04" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "IR-8.a.9(iv)": [ + "IRO-04" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "IR-8.a.9(v)": [ + "IRO-04" ], - "CP-09": [ - "BCD-11" + "IR-8.a.9(vi)": [ + "IRO-04" ], - "SC-28(02)": [ - "BCD-11", - "CRY-05.2" + "IR-8.a.9(vii)": [ + "IRO-04" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "IR-8.a.9(viii)": [ + "IRO-04" ], - "SI-13": [ - "BCD-12.2", - "SEA-07" + "IR-8.b": [ + "IRO-04" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "IR-8.c": [ + "IRO-04" ], - "SC-05(02)": [ - "CAP-02", - "CAP-03" + "IR-8.d": [ + "IRO-04" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "IR-8.e": [ + "IRO-04" ], - "SA-08(31)": [ - "CHG-02", - "CHG-02.2", - "CHG-06" + "IR-8-IS.1": [ + "IRO-04" ], - "CM-03(02)": [ - "CHG-02.2", - "CHG-06" + "IR-8-IS.2": [ + "IRO-04" ], - "CM-04": [ - "CHG-03" + "IR-8-IS.3": [ + "IRO-04" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "IR-2": [ + "IRO-05" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "IR-2-1": [ + "IRO-05" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "IR-2-1a": [ + "IRO-05" ], - "SC-07(29)": [ - "CLD-03", - "NET-03.8", - "NET-06.1" + "IR-2-1b": [ + "IRO-05" ], - "SA-09(05)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "IR-2-1c": [ + "IRO-05" ], - "SA-09(08)": [ - "CLD-09", - "DCH-19" + "IR-2-2": [ + "IRO-05" ], - "CA-07": [ - "CPL-02" + "IR-2-2a": [ + "IRO-05" ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" + "IR-2-2b": [ + "IRO-05" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "IR-2-2c": [ + "IRO-05" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "IR-2-2d": [ + "IRO-05" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "IR-3": [ + "IRO-06" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "IR-3.a": [ + "IRO-06" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "IR-3.b": [ + "IRO-06" ], - "PL-10": [ - "CFG-02" + "IR-3.c": [ + "IRO-06" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "IR-3(2)": [ + "IRO-06" ], - "SA-15(05)": [ - "CFG-02", - "SEA-01" + "IR-5": [ + "IRO-09" ], - "PL-11": [ - "CFG-02.9" + "IR-6.a": [ + "IRO-10" ], - "CM-07": [ - "CFG-03" + "IR-6.b": [ + "IRO-10" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" + "IR-6(1)": [ + "IRO-10.1" ], - "SC-18(04)": [ - "CFG-03.3", - "END-10" + "IR-7": [ + "IRO-11" ], - "CM-10": [ - "CFG-04" + "IR-7(1)": [ + "IRO-11.1" ], - "CM-11": [ - "CFG-05", - "END-03" + "IR-9": [ + "IRO-12", + "IRO-12.1" ], - "CM-11(02)": [ - "CFG-05", - "CFG-05.2", - "END-03" + "IR-9.a": [ + "IRO-12" ], - "CM-11(03)": [ - "CFG-05.1", - "CFG-06", - "CFG-06.1", - "END-03.1" + "IR-9.b": [ + "IRO-12" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "IR-9.c": [ + "IRO-12" ], - "SI-04(25)": [ - "MON-01.1", - "NET-03.1" + "IR-9.d": [ + "IRO-12" ], - "SC-48": [ - "MON-01.2", - "THR-07" + "IR-9.e": [ + "IRO-12" ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" + "PM-10-1": [ + "IAO-01" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "PM-10-1a": [ + "IAO-01" ], - "IR-04(05)": [ - "MON-01.11", - "IRO-02.6" + "PM-10-1b": [ + "IAO-01" ], - "SI-04(07)": [ - "MON-01.11", - "IRO-02.1" + "PM-10-1c": [ + "IAO-01" ], - "SI-04(12)": [ - "MON-01.12", - "MON-05.1" + "PM-10-2": [ + "IAO-01" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "PM-10-2a": [ + "IAO-01" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "PM-10-2b": [ + "IAO-01" ], - "AU-03": [ - "MON-03" + "PM-10-2c": [ + "IAO-01" ], - "AU-04": [ - "MON-04" + "PM-10-2d": [ + "IAO-01" ], - "AU-05": [ - "MON-05" + "CA-2.a": [ + "IAO-02" ], - "AU-12": [ - "MON-06" + "CA-2.a.1": [ + "IAO-02" ], - "AU-08": [ - "MON-07", - "SEA-20" + "CA-2.a.2": [ + "IAO-02" ], - "AU-09": [ - "MON-08" + "CA-2.a.3": [ + "IAO-02" ], - "AU-11": [ - "MON-10" + "CA-2.b": [ + "IAO-02" ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" + "CA-2.c": [ + "IAO-02" ], - "IR-04(13)": [ - "MON-16", - "SEA-11", - "SEA-12" + "CA-2.d": [ + "IAO-02" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "CA-2-IS.1": [ + "IAO-02" ], - "SC-08(02)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" + "CA-2-IS.2": [ + "IAO-02" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "CA-2-IS.3": [ + "IAO-02" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "CA-2-IS.4": [ + "IAO-02" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "CA-2(1)": [ + "IAO-02.1" ], - "SC-16(01)": [ - "CRY-04", - "CRY-10" + "CA-2(1)-IS": [ + "IAO-02.1" ], - "SC-28": [ - "CRY-05", - "END-02" + "PL-2.a": [ + "IAO-03" ], - "AC-18": [ - "CRY-07", - "NET-15" + "PL-2.a.1": [ + "IAO-03" ], - "SC-40": [ - "CRY-07", - "NET-12.1" + "PL-2.a.2": [ + "IAO-03" ], - "SC-12": [ - "CRY-08" + "PL-2.a.3": [ + "IAO-03" ], - "MP-02": [ - "DCH-03", - "END-01" + "PL-2.a.4": [ + "IAO-03" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "PL-2.a.5": [ + "IAO-03" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "PL-2.a.6": [ + "IAO-03" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" + "PL-2.a.7": [ + "IAO-03" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "PL-2.a.8": [ + "IAO-03" ], - "AC-20": [ - "DCH-13" + "PL-2.a.9": [ + "IAO-03" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "PL-2.b": [ + "IAO-03" ], - "AC-22": [ - "DCH-15" + "PL-2.c": [ + "IAO-03" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "PL-2.d": [ + "IAO-03" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "PL-2.d.1": [ + "IAO-03" ], - "SI-12(01)": [ - "DCH-18.1", - "PRI-05.1" + "PL-2.d.2": [ + "IAO-03" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "PL-2.d.3": [ + "IAO-03" ], - "SA-08(33)": [ - "DCH-18.2", - "END-13.3", - "PES-06.5" + "PL-2.d.4": [ + "IAO-03" ], - "SI-12(02)": [ - "DCH-18.2", - "PRI-05.1" + "PL-2.d.5": [ + "IAO-03" ], - "SI-12(03)": [ - "DCH-21", - "PRI-05" + "PL-2.e": [ + "IAO-03" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "PL-2-IS": [ + "IAO-03" ], - "SI-18(04)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "PL-2(3)": [ + "IAO-03" ], - "SI-18(05)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "CA-5": [ + "IAO-05" ], - "PT-03(01)": [ - "DCH-22.2", - "PRI-11" + "CA-5.a": [ + "IAO-05" ], - "SI-19(01)": [ - "DCH-22.3", - "DCH-23.1" + "CA-5.b": [ + "IAO-05" ], - "SI-19(04)": [ - "DCH-23.4", - "PRI-05.3" + "CA-5.c": [ + "IAO-05" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "CA-5-IS.1": [ + "IAO-05" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "PM-4": [ + "IAO-05", + "VPM-02" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "PM-4.a": [ + "IAO-05" ], - "SC-18(01)": [ - "END-10", - "VPM-02", - "VPM-04" + "PM-4.a.1": [ + "IAO-05" ], - "SC-18(03)": [ - "END-10", - "NET-18" + "PM-4.a.2": [ + "IAO-05" ], - "SC-15": [ - "END-14" + "PM-4.a.3": [ + "IAO-05" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "PM-4.b": [ + "IAO-05" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "PM-4-IS.1": [ + "IAO-05" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "CA-5(1)": [ + "IAO-05.1" ], - "PS-09": [ - "HRS-03" + "CM-4(2)": [ + "IAO-06" ], - "PS-03": [ - "HRS-04" + "CA-6": [ + "IAO-07" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "CA-6.a": [ + "IAO-07" ], - "PL-04(01)": [ - "HRS-05.2" + "CA-6.b": [ + "IAO-07" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "CA-6.b.1": [ + "IAO-07" ], - "PS-06(02)": [ - "HRS-06", - "HRS-06.1" + "CA-6.b.2": [ + "IAO-07" ], - "PS-08": [ - "HRS-07" + "CA-6.b.3": [ + "IAO-07" ], - "PS-05": [ - "HRS-08" + "CA-6.b.4": [ + "IAO-07" ], - "PS-04": [ - "HRS-09" + "CA-6.b.5": [ + "IAO-07" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "CA-6.b.6": [ + "IAO-07" ], - "PS-07": [ - "HRS-10" + "CA-6.c": [ + "IAO-07" ], - "AC-03(02)": [ - "HRS-12.1", - "IAC-20.5" + "CA-6.c.1": [ + "IAO-07" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "CA-6.c.2": [ + "IAO-07" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "CA-6.c.3": [ + "IAO-07" ], - "IA-02": [ - "IAC-02" + "CA-6.c.4": [ + "IAO-07" ], - "IA-02(08)": [ - "IAC-02.2" + "CA-6.c.5": [ + "IAO-07" ], - "IA-02(12)": [ - "IAC-02.3" + "CA-6.c.6": [ + "IAO-07" ], - "IA-08": [ - "IAC-03" + "MA-2": [ + "MNT-02" ], - "IA-08(01)": [ - "IAC-03.1" + "MA-2.a": [ + "MNT-02" ], - "IA-08(02)": [ - "IAC-03.2" + "MA-2.b": [ + "MNT-02" ], - "IA-08(04)": [ - "IAC-03.3" + "MA-2.c": [ + "MNT-02" ], - "IA-03(04)": [ - "IAC-04", - "IAC-04.1" + "MA-2.d": [ + "MNT-02" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "MA-2.e": [ + "MNT-02" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "MA-2.f": [ + "MNT-02" ], - "IA-12(04)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" + "MA-2-IS.1": [ + "MNT-02" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "MA-6": [ + "MNT-03" ], - "IA-05(08)": [ - "IAC-09.5", - "IAC-10.9" + "MA-3": [ + "MNT-04" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "MA-3(1)": [ + "MNT-04.1" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "MA-3(2)": [ + "MNT-04.2" ], - "IA-05(02)": [ - "IAC-10.2" + "MA-3(3)": [ + "MNT-04.3" ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" + "MA-3(3).a": [ + "MNT-04.3" ], - "IA-06": [ - "IAC-11" + "MA-3(3).b": [ + "MNT-04.3" ], - "IA-11": [ - "IAC-14" + "MA-3(3).c": [ + "MNT-04.3" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "MA-3(3).d": [ + "MNT-04.3" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "MA-4": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "AC-07": [ - "IAC-22" + "MA-4.a": [ + "MNT-05" ], - "AC-14": [ - "IAC-26" + "MA-4.b": [ + "MNT-05" ], - "IR-04": [ - "IRO-02" + "MA-4.c": [ + "MNT-05" ], - "IR-08": [ - "IRO-04" + "MA-4.d": [ + "MNT-05" ], - "IR-02": [ - "IRO-05" + "MA-4(2)": [ + "MNT-05" ], - "IR-04(12)": [ - "IRO-08", - "IRO-13" + "MA-4(1)": [ + "MNT-05.1" ], - "IR-05": [ - "IRO-09" + "MA-4(1).a": [ + "MNT-05.1" ], - "IR-06(02)": [ - "IRO-10.3", - "IRO-13" + "MA-4(1).b": [ + "MNT-05.1" ], - "IR-04(10)": [ - "IRO-10.4", - "TPM-11" + "MA-4(3)": [ + "MNT-05.6" ], - "IR-07": [ - "IRO-11" + "MA-4(3).a": [ + "MNT-05.6" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "MA-4(3).b": [ + "MNT-05.6" ], - "CA-02(01)": [ - "IAO-02.1" + "MA-5": [ + "MNT-06" ], - "SA-11(05)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "MA-5.a": [ + "MNT-06" ], - "CA-05": [ - "IAO-05" + "MA-5.b": [ + "MNT-06" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "MA-5.c": [ + "MNT-06" ], - "CA-06": [ - "IAO-07" + "AC-19": [ + "MDM-02" ], - "MA-02": [ - "MNT-02" + "AC-19.a": [ + "MDM-02" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "AC-19.b": [ + "MDM-02" ], - "MA-05": [ - "MNT-06" + "AC-19.c": [ + "MDM-02" ], - "SR-11(02)": [ - "MNT-07" + "AC-19.d": [ + "MDM-02" ], - "AC-19": [ + "AC-19.e": [ "MDM-02" ], - "SC-07": [ - "NET-03" + "AC-19.f": [ + "MDM-02" ], - "SC-07(09)": [ - "NET-03", - "NET-03.2" + "AC-19.g": [ + "MDM-02" ], - "SC-07(11)": [ - "NET-03", - "NET-04.1" + "AC-19.h": [ + "MDM-02" ], - "SC-07(10)": [ - "NET-03.5", - "NET-17" + "AC-19-IS.1": [ + "MDM-02" ], - "CA-03": [ - "NET-05" + "AC-19-IS.3": [ + "MDM-02" ], - "CA-09": [ - "NET-05.2" + "AC-19(5)": [ + "MDM-03" ], - "SC-20": [ - "NET-10" + "SC-5.a": [ + "NET-02.1" ], - "SC-22": [ - "NET-10.1" + "SC-5.b": [ + "NET-02.1" ], - "SC-21": [ - "NET-10.2" + "SC-5.c": [ + "NET-02.1" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "SC-5-IS": [ + "NET-02.1" ], - "SI-10": [ - "NET-12", - "TDA-18" + "SC-7": [ + "NET-03" ], - "AC-17": [ - "NET-14" + "SC-7.a": [ + "NET-03" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "SC-7.b": [ + "NET-03" ], - "PE-02": [ - "PES-02" + "SC-7.c": [ + "NET-03" ], - "PE-03": [ - "PES-03" + "SC-7-IS.1": [ + "NET-03" ], - "SC-07(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "SC-7-IS.2": [ + "NET-03" ], - "PE-08": [ - "PES-03.3" + "SC-7-IS.3": [ + "NET-03" ], - "PE-06": [ - "PES-05" + "SC-7(3)": [ + "NET-03.1" ], - "PE-12": [ - "PES-07.4" + "SC-7(4)": [ + "NET-03.2" ], - "PE-15": [ - "PES-07.5" + "SC-7(4).a": [ + "NET-03.2" ], - "PE-13": [ - "PES-08" + "SC-7(4).b": [ + "NET-03.2" ], - "PE-13(02)": [ - "PES-08.2", - "PES-08.3" + "SC-7(4).c": [ + "NET-03.2" ], - "PE-14": [ - "PES-09" + "SC-7(4).d": [ + "NET-03.2" ], - "PE-16": [ - "PES-10" + "SC-7(4).e": [ + "NET-03.2" ], - "PT-03": [ - "PRI-02.1", - "PRI-05.1" + "SC-7(4).f": [ + "NET-03.2" ], - "PT-03(02)": [ - "PRI-02.2", - "PRI-10.1" + "AC-4": [ + "NET-04" ], - "PT-02": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "SC-7(5)": [ + "NET-04.1" ], - "PT-07": [ - "PRI-05.4", - "PRI-05.7" + "CA-3": [ + "NET-05" ], - "PM-05(01)": [ - "PRI-05.5", - "PRI-05.6" + "CA-3.a": [ + "NET-05" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "CA-3.b": [ + "NET-05" ], - "SA-02": [ - "PRM-03" + "CA-3.c": [ + "NET-05" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "CA-3.d": [ + "NET-05" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "CA-3-IS.1": [ + "NET-05" ], - "SA-03(01)": [ - "PRM-07", - "SEA-07.1", - "TDA-07" + "CA-3-IS.2": [ + "NET-05" ], - "SA-08(30)": [ - "PRM-07", - "SEA-07.1" + "CA-3-IS.3": [ + "NET-05" ], - "RA-02": [ - "RSK-02" + "CA-3(5)": [ + "NET-05.1" ], - "RA-07": [ - "RSK-06.1" + "CA-9": [ + "NET-05.2" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "CA-9.a": [ + "NET-05.2" ], - "SR-07": [ - "RSK-09", - "OPS-01" + "CA-9.b": [ + "NET-05.2" ], - "RA-03(01)": [ - "RSK-09.1" + "SC-7(13)": [ + "NET-06.1" ], - "CA-07(04)": [ - "RSK-11" + "SC-10": [ + "NET-07" ], - "PL-08": [ - "SEA-02" + "SC-10.a": [ + "NET-07" ], - "SC-39": [ - "SEA-04" + "SC-10.b": [ + "NET-07" ], - "SA-03(03)": [ - "SEA-07.1", - "SEA-08.1" + "SC-23": [ + "NET-09" ], - "AC-08": [ - "SEA-18" + "SC-20": [ + "NET-10" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "SC-20.a": [ + "NET-10" ], - "AT-02": [ - "SAT-02" + "SC-20.b": [ + "NET-10" ], - "AT-03": [ - "SAT-03" + "SC-20-IS.1": [ + "NET-10" ], - "AT-04": [ - "SAT-04" + "SC-22": [ + "NET-10.1" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "SC-21": [ + "NET-10.2" ], - "SA-23": [ - "TDA-01", - "TDA-01.1", - "TDA-12" + "SI-5": [ + "NET-12", + "TDA-18", + "THR-03" ], - "SA-04(10)": [ - "TDA-02.2" + "SI-10": [ + "NET-12", + "TDA-18" ], - "SA-04(03)": [ - "TDA-02.3", - "TDA-06" + "SC-ACA-1": [ + "NET-13" ], - "SR-03(01)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "SC-ACA-1-IS.a": [ + "NET-13" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "SC-ACA-2": [ + "NET-13" ], - "SA-11(02)": [ - "TDA-06.2", - "TDA-15" + "SC-ACA-2.a": [ + "NET-13" ], - "SA-11(06)": [ - "TDA-09", - "VPM-01.1" + "SC-ACA-2-IS.1": [ + "NET-13" ], - "SA-11(07)": [ - "TDA-09", - "VPM-01.1" + "SC-ACA-2-IS.1.a": [ + "NET-13" ], - "SR-11": [ - "TDA-11" + "SC-ACA-2-IS.1.b": [ + "NET-13" ], - "SR-11(01)": [ - "TDA-11.1" + "SC-ACA-2-IS.1.c": [ + "NET-13" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "AC-17": [ + "NET-14" ], - "SR-02(01)": [ - "TPM-03" + "AC-17.a": [ + "NET-14" ], - "SR-05": [ - "TPM-03.1" + "AC-17.a.1": [ + "NET-14" ], - "SR-03": [ - "TPM-03.3" + "AC-17.a.2": [ + "NET-14" ], - "SA-09": [ - "TPM-04" + "AC-17.a.3": [ + "NET-14" ], - "SR-03(03)": [ - "TPM-05", - "TPM-05.2" + "AC-17.b": [ + "NET-14" ], - "SR-08": [ - "TPM-05.1" + "AC-17-IS.1": [ + "NET-14" ], - "AT-02(02)": [ - "THR-05" + "AC-17-IS.3": [ + "NET-14" ], - "RA-05(11)": [ - "THR-06" + "AC-17(1)": [ + "NET-14.1" ], - "SI-02(04)": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "AC-17(2)": [ + "NET-14.2" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "AC-17(3)": [ + "NET-14.3" ], - "RA-05(02)": [ - "VPM-06.1" + "AC-17(4)": [ + "NET-14.4" ], - "CA-08": [ - "VPM-07" - ] - }, - "usa-federal-gsa-fedramp-5-mod": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "AC-17(4).a": [ + "NET-14.4" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "AC-17(4).b": [ + "NET-14.4" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "AC-18.a": [ + "NET-15" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "AC-18.b": [ + "NET-15" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "AC-18.c": [ + "NET-15" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "AC-18(1)": [ + "NET-15.1" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "SC-7(8)": [ + "NET-18", + "NET-18.1" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "SC-7(8)-IS.1": [ + "NET-18.1" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "PE-2": [ + "PES-02" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "PE-2.a": [ + "PES-02" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "PE-2.b": [ + "PES-02" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "PE-2.c": [ + "PES-02" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "PE-2-IS.1": [ + "PES-02" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "PE-2-IS.2": [ + "PES-02" ], - "PT-01": [ - "GOV-02", - "GOV-03", - "PRI-01", - "SEA-01" + "PE-3-IS.3": [ + "PES-02" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "PE-2(1)": [ + "PES-02.1" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "PE-3": [ + "PES-03" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "PE-3.a": [ + "PES-03" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "PE-3.b": [ + "PES-03" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "PE-3.c": [ + "PES-03" ], - "PL-09": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "PE-3.d": [ + "PES-03" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "PE-3.e": [ + "PES-03" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "PE-3.f": [ + "PES-03" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "PE-3.g": [ + "PES-03" ], - "PM-15": [ - "GOV-07", - "THR-01" + "PE-3.h": [ + "PES-03" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "PE-3.i": [ + "PES-03" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "PE-3-IS.1": [ + "PES-03" ], - "PM-05": [ - "AST-01", - "AST-02" + "PE-3-IS.4": [ + "PES-03" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "PE-8": [ + "PES-03.3" ], - "CM-08(01)": [ - "AST-02.1" + "PE-8.a": [ + "PES-03.3" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "PE-8.b": [ + "PES-03.3" ], - "SC-18(02)": [ - "AST-02.7", - "END-10" + "PE-3-IS.2": [ + "PES-03.4" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "PE-6": [ + "PES-05" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "PE-6.a": [ + "PES-05" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "PE-6.b": [ + "PES-05" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "PE-6.c": [ + "PES-05" ], - "PE-22": [ - "AST-04.1", - "PES-16" + "PE-6-IS.1": [ + "PES-05" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "PE-6(1)": [ + "PES-05.1" + ], + "PE-3-IS.5": [ + "PES-06" ], - "SR-12": [ - "AST-09" + "PE-9": [ + "PES-07" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "PE-9-IS.1": [ + "PES-07" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "PE-10": [ + "PES-07.2" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "PE-10.a": [ + "PES-07.2" ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" + "PE-10.b": [ + "PES-07.2" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "PE-10.c": [ + "PES-07.2" ], - "CP-02(01)": [ - "BCD-01.1" + "PE-11": [ + "PES-07.3" ], - "CP-02(08)": [ - "BCD-02" + "PE-12": [ + "PES-07.4" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "PE-15": [ + "PES-07.5" ], - "CP-03": [ - "BCD-03" + "PE-13": [ + "PES-08" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "PE-13(1)": [ + "PES-08.1" ], - "CP-04(01)": [ - "BCD-04.1" + "PE-13(3)": [ + "PES-08.2" ], - "CP-06": [ - "BCD-08" + "PE-13(2)": [ + "PES-08.3" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "PE-14": [ + "PES-09" ], - "CP-06(01)": [ - "BCD-08.1" + "PE-14.a": [ + "PES-09" ], - "CP-06(03)": [ - "BCD-08.2" + "PE-14.b": [ + "PES-09" ], - "CP-07": [ - "BCD-09" + "PE-14-IS.1": [ + "PES-09" ], - "CP-07(01)": [ - "BCD-09.1" + "PE-14-IS.2": [ + "PES-09" ], - "CP-07(02)": [ - "BCD-09.2" + "PE-14-IS.3": [ + "PES-09" ], - "CP-07(03)": [ - "BCD-09.3" + "PE-16": [ + "PES-10" ], - "CP-08": [ - "BCD-10" + "PE-16-IS.1": [ + "PES-10" ], - "CP-08(02)": [ - "BCD-10" + "PE-17": [ + "PES-11" ], - "CP-08(01)": [ - "BCD-10.1" + "PE-17.a": [ + "PES-11" ], - "CP-09": [ - "BCD-11" + "PE-17.b": [ + "PES-11" ], - "SC-28(02)": [ - "BCD-11", - "CRY-05.2" + "PE-17.c": [ + "PES-11" ], - "CP-09(01)": [ - "BCD-11.1" + "PE-17-IS.1": [ + "PES-11" ], - "CP-09(08)": [ - "BCD-11.4" + "PE-4-IS.1": [ + "PES-12" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "PE-18": [ + "PES-12" ], - "CP-10(02)": [ - "BCD-12.1" + "PE-4": [ + "PES-12.1" ], - "SI-13": [ - "BCD-12.2", - "SEA-07" + "PE-5": [ + "PES-12.2" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "AR-1": [ + "PRI-01" ], - "SC-05(02)": [ - "CAP-02", - "CAP-03" + "AR-1.b": [ + "PRI-01" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "AR-1.c": [ + "PRI-01" ], - "SA-08(31)": [ - "CHG-02", - "CHG-02.2", - "CHG-06" + "AR-1.d": [ + "PRI-01" ], - "CM-03(02)": [ - "CHG-02.2", - "CHG-06" + "AR-1.e": [ + "PRI-01" ], - "CM-03(04)": [ - "CHG-02.3" + "AR-1.f": [ + "PRI-01" ], - "CM-04": [ - "CHG-03" + "AR-1.a": [ + "PRI-01.1" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "TR-2": [ + "PRI-01.2", + "PRI-02.4" ], - "CM-05(01)": [ - "CHG-04.1" + "TR-2.c": [ + "PRI-01.2" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "TR-3": [ + "PRI-01.3" ], - "CM-05(05)": [ - "CHG-04.4" + "TR-3.a": [ + "PRI-01.3" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "TR-3.b": [ + "PRI-01.3" ], - "SI-06": [ - "CHG-06" + "TR-1": [ + "PRI-02" ], - "SC-07(29)": [ - "CLD-03", - "NET-03.8", - "NET-06.1" + "TR-1.a": [ + "PRI-02" ], - "SA-09(05)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "TR-1.a.1": [ + "PRI-02" ], - "SA-09(08)": [ - "CLD-09", - "DCH-19" + "TR-1.a.2": [ + "PRI-02" ], - "CA-07": [ - "CPL-02" + "TR-1.a.3": [ + "PRI-02" ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" + "TR-1.a.4": [ + "PRI-02" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "TR-1.b": [ + "PRI-02" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "TR-1.b.1": [ + "PRI-02" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "TR-1.b.2": [ + "PRI-02" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "TR-1.b.3": [ + "PRI-02" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "TR-1.b.4": [ + "PRI-02" ], - "PL-10": [ - "CFG-02" + "TR-1.b.5": [ + "PRI-02" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "TR-1.b.6": [ + "PRI-02" ], - "SA-15(05)": [ - "CFG-02", - "SEA-01" + "TR-1.c": [ + "PRI-02" ], - "CM-02(02)": [ - "CFG-02.2" + "AP-2": [ + "PRI-02.1" ], - "CM-06(01)": [ - "CFG-02.2" + "DI-2(1)": [ + "PRI-02.3" ], - "CM-02(03)": [ - "CFG-02.3" + "TR-2.a": [ + "PRI-02.4" ], - "CM-02(07)": [ - "CFG-02.5" + "TR-2.b": [ + "PRI-02.4" ], - "PL-11": [ - "CFG-02.9" + "TR-2(1)": [ + "PRI-02.4" ], - "CM-07": [ - "CFG-03" + "TR-1(1)": [ + "PRI-02.7" ], - "CM-07(01)": [ - "CFG-03.1" + "IP-1": [ + "PRI-03" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" + "IP-1.a": [ + "PRI-03" ], - "CM-07(05)": [ - "CFG-03.3" + "IP-1.b": [ + "PRI-03" ], - "SC-18(04)": [ - "CFG-03.3", - "END-10" + "IP-1.c": [ + "PRI-03" ], - "SC-07(07)": [ - "CFG-03.4" + "IP-1.d": [ + "PRI-03" ], - "CM-10": [ - "CFG-04" + "IP-1(1)": [ + "PRI-03" ], - "CM-11": [ - "CFG-05", - "END-03" + "AP-1": [ + "PRI-04.1" ], - "CM-11(02)": [ - "CFG-05", - "CFG-05.2", - "END-03" + "DI-1(1)": [ + "PRI-04.5" ], - "CM-11(03)": [ - "CFG-05.1", - "CFG-06", - "CFG-06.1", - "END-03.1" + "DI-1(2)": [ + "PRI-04.6" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "DM-2.a": [ + "PRI-05" ], - "SI-04(01)": [ - "MON-01.1" + "DM-1": [ + "PRI-05.1" ], - "SI-04(25)": [ - "MON-01.1", - "NET-03.1" + "DM-1.a": [ + "PRI-05.1" ], - "SC-48": [ - "MON-01.2", - "THR-07" + "DM-1.b": [ + "PRI-05.1" ], - "SI-04(02)": [ - "MON-01.2" + "DM-1.c": [ + "PRI-05.1" ], - "SI-04(04)": [ - "MON-01.3" + "DM-3": [ + "PRI-05.1" ], - "SI-04(05)": [ - "MON-01.4" + "DM-3.a": [ + "PRI-05.1" ], - "SI-04(23)": [ - "MON-01.6" + "DM-3.b": [ + "PRI-05.1" ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" + "DM-3(1)": [ + "PRI-05.1" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "DI-2": [ + "PRI-05.2" ], - "IR-04(05)": [ - "MON-01.11", - "IRO-02.6" + "DI-2.a": [ + "PRI-05.2" ], - "SI-04(07)": [ - "MON-01.11", - "IRO-02.1" + "DI-2.b": [ + "PRI-05.2" ], - "SI-04(12)": [ - "MON-01.12", - "MON-05.1" + "UL-1": [ + "PRI-05.4" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "SE-1": [ + "PRI-05.5" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "SE-1.a": [ + "PRI-05.5" ], - "AU-06(03)": [ - "MON-02.1" + "SE-1.b": [ + "PRI-05.5" ], - "SI-04(16)": [ - "MON-02.1" + "IP-2": [ + "PRI-06" ], - "AU-03": [ - "MON-03" + "IP-2.a": [ + "PRI-06" ], - "AU-03(01)": [ - "MON-03.1" + "IP-2.b": [ + "PRI-06" ], - "AU-06(01)": [ - "MON-03.1" + "IP-2.c": [ + "PRI-06" ], - "AU-04": [ - "MON-04" + "IP-2.d": [ + "PRI-06" ], - "AU-05": [ - "MON-05" + "IP-3.a": [ + "PRI-06" ], - "AU-07": [ - "MON-06" + "IP-3.b": [ + "PRI-06.1" ], - "AU-07(01)": [ - "MON-06" + "IP-4": [ + "PRI-06.4", + "OPS-03" ], - "AU-12": [ - "MON-06" + "IP-4(1)": [ + "PRI-06.4", + "OPS-03" ], - "AU-08": [ - "MON-07", - "SEA-20" + "UL-2": [ + "PRI-07" ], - "SC-45": [ - "MON-07.1" + "UL-2.a": [ + "PRI-07" ], - "SC-45(01)": [ - "MON-07.1" + "UL-2.b": [ + "PRI-07" ], - "AU-09": [ - "MON-08" + "UL-2.c": [ + "PRI-07" ], - "AU-09(04)": [ - "MON-08.2" + "UL-2.d": [ + "PRI-07" ], - "AU-11": [ - "MON-10" + "AR-3": [ + "PRI-07.1" ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" + "AR-3.a": [ + "PRI-07.1" ], - "AC-02(12)": [ - "MON-16" + "AR-3.b": [ + "PRI-07.1" ], - "IR-04(13)": [ - "MON-16", - "SEA-11", - "SEA-12" + "PM-14.a": [ + "PRI-08" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "PM-14.a.1": [ + "PRI-08" ], - "SC-08(02)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" + "PM-14.a.2": [ + "PRI-08" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "PM-14.b": [ + "PRI-08" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "AR-4": [ + "PRI-08" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "AR-4.a": [ + "PRI-08" ], - "SC-16(01)": [ - "CRY-04", - "CRY-10" + "AR-4.b": [ + "PRI-08" ], - "SC-28": [ - "CRY-05", - "END-02" + "AR-6": [ + "PRI-14" ], - "AC-18": [ - "CRY-07", - "NET-15" + "DM-2(1)": [ + "PRI-14" ], - "SC-40": [ - "CRY-07", - "NET-12.1" + "AU-2-IS.4": [ + "PRI-14.1" ], - "SC-12": [ - "CRY-08" + "AR-8": [ + "PRI-14.1" ], - "SC-17": [ - "CRY-08" + "AR-8.a": [ + "PRI-14.1" ], - "MP-02": [ - "DCH-03", - "END-01" + "AR-8.a.1": [ + "PRI-14.1" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "AR-8.a.2": [ + "PRI-14.1" ], - "MP-04": [ - "DCH-06" + "AR-8.b": [ + "PRI-14.1" ], - "MP-05": [ - "DCH-07" + "AR-8.c": [ + "PRI-14.1" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "PM-3": [ + "PRM-02" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" + "PM-3.a": [ + "PRM-02" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "PM-3.b": [ + "PRM-02" ], - "AC-20": [ - "DCH-13" + "PM-3.c": [ + "PRM-02" ], - "AC-20(01)": [ - "DCH-13.1" + "SA-2": [ + "PRM-03" ], - "AC-20(02)": [ - "DCH-13.2" + "SA-2.a": [ + "PRM-03" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "SA-2.b": [ + "PRM-03" ], - "AC-22": [ - "DCH-15" + "SA-2.c": [ + "PRM-03" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "SA-2.d": [ + "PRM-03" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "PM-11": [ + "PRM-06" ], - "SI-12(01)": [ - "DCH-18.1", - "PRI-05.1" + "PM-11.a": [ + "PRM-06" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "PM-11.b": [ + "PRM-06" ], - "SA-08(33)": [ - "DCH-18.2", - "END-13.3", - "PES-06.5" + "SA-3": [ + "PRM-07", + "SEA-07.1" ], - "SI-12(02)": [ - "DCH-18.2", - "PRI-05.1" + "SA-3.a": [ + "PRM-07" ], - "SI-12(03)": [ - "DCH-21", - "PRI-05" + "SA-3.b": [ + "PRM-07" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "SA-3.c": [ + "PRM-07" ], - "SI-18(04)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "SA-3.d": [ + "PRM-07" ], - "SI-18(05)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "RA-1.a": [ + "RSK-01" ], - "PT-03(01)": [ - "DCH-22.2", - "PRI-11" + "RA-1.b": [ + "RSK-01" ], - "SI-19(01)": [ - "DCH-22.3", - "DCH-23.1" + "PM-9": [ + "RSK-01" ], - "SI-19(04)": [ - "DCH-23.4", - "PRI-05.3" + "PM-9.a": [ + "RSK-01" ], - "CM-12": [ - "DCH-24" + "PM-9.b": [ + "RSK-01" ], - "CM-12(01)": [ - "DCH-24.1" + "PM-9.c": [ + "RSK-01" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "RA-2": [ + "RSK-02" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "RA-2.a": [ + "RSK-02" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "RA-2.b": [ + "RSK-02" ], - "SI-07(01)": [ - "END-06.1" + "RA-2.e": [ + "RSK-02" ], - "SI-07(07)": [ - "END-06.2" + "RA-3.a": [ + "RSK-04" ], - "SI-08": [ - "END-08" + "RA-3.b": [ + "RSK-04" ], - "SI-08(02)": [ - "END-08.2" + "RA-3.c": [ + "RSK-04" ], - "SC-18": [ - "END-10" + "RA-3.d": [ + "RSK-04" ], - "SC-18(01)": [ - "END-10", - "VPM-02", - "VPM-04" + "RA-3.e": [ + "RSK-04" ], - "SC-18(03)": [ - "END-10", - "NET-18" + "RA-3-IS.1": [ + "RSK-04" ], - "SC-15": [ - "END-14" + "RA-3-IS.2": [ + "RSK-04" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "AR-2": [ + "RSK-10" ], - "SC-07(12)": [ - "END-16.1" + "AR-2.a": [ + "RSK-10" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "AR-2.b": [ + "RSK-10" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "SC-7(18)": [ + "SEA-01" ], - "PS-09": [ - "HRS-03" + "AR-7": [ + "SEA-01" ], - "PS-03": [ - "HRS-04" + "PL-8": [ + "SEA-02" ], - "PS-03(03)": [ - "HRS-04.1" + "PL-8.a": [ + "SEA-02" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "PL-8.a.1": [ + "SEA-02" ], - "PL-04(01)": [ - "HRS-05.2" + "PL-8.a.2": [ + "SEA-02" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "PL-8.a.3": [ + "SEA-02" ], - "PS-06(02)": [ - "HRS-06", - "HRS-06.1" + "PL-8.b": [ + "SEA-02" ], - "PS-08": [ - "HRS-07" + "PL-8.c": [ + "SEA-02" ], - "PS-05": [ - "HRS-08" + "PM-7": [ + "SEA-02" ], - "PS-04": [ - "HRS-09" + "SC-32": [ + "SEA-03.1" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "SC-32-iS": [ + "SEA-03.1" ], - "PS-07": [ - "HRS-10" + "SC-2": [ + "SEA-03.2" ], - "AC-03(02)": [ - "HRS-12.1", - "IAC-20.5" + "SC-39": [ + "SEA-04" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "SC-4": [ + "SEA-05" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "SC-4-IS.1": [ + "SEA-05" ], - "IA-02": [ - "IAC-02" + "SC-4-IS.2": [ + "SEA-05" ], - "IA-02(05)": [ - "IAC-02.1" + "SI-16": [ + "SEA-10" ], - "IA-02(08)": [ - "IAC-02.2" + "AC-8": [ + "SEA-18" ], - "IA-02(12)": [ - "IAC-02.3" + "AC-8.a": [ + "SEA-18" ], - "IA-08": [ - "IAC-03" + "AC-8.b": [ + "SEA-18" ], - "IA-08(01)": [ - "IAC-03.1" + "AC-8.c": [ + "SEA-18" ], - "IA-08(02)": [ - "IAC-03.2" + "AC-8.c.1": [ + "SEA-18" ], - "IA-08(04)": [ - "IAC-03.3" + "AC-8.c.2": [ + "SEA-18" ], - "IA-03": [ - "IAC-04" + "AC-8.c.3": [ + "SEA-18" ], - "IA-03(04)": [ - "IAC-04", - "IAC-04.1" + "AU-8.a": [ + "SEA-20" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "AU-8(1)": [ + "SEA-20" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "AU-8(1)-IS.1": [ + "SEA-20" ], - "IA-02(06)": [ - "IAC-06.4" + "AC-1.b": [ + "OPS-01.1" ], - "IA-12(04)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" + "AT-1.b": [ + "OPS-01.1" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "AU-1.b": [ + "OPS-01.1" ], - "AC-02(07)": [ - "IAC-08" + "CA-1.b": [ + "OPS-01.1" ], - "IA-05(08)": [ - "IAC-09.5", - "IAC-10.9" + "CA-1.d": [ + "OPS-01.1" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "CM-1.b": [ + "OPS-01.1" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "CP-1.b": [ + "OPS-01.1" ], - "IA-05(02)": [ - "IAC-10.2" + "IA-1.b": [ + "OPS-01.1" ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" + "IR-1.b": [ + "OPS-01.1" ], - "IA-05(07)": [ - "IAC-10.6" + "MA-1.b": [ + "OPS-01.1" ], - "IA-06": [ - "IAC-11" + "MP-1.b": [ + "OPS-01.1" ], - "IA-11": [ - "IAC-14" + "MP-1-IS.2": [ + "OPS-01.1" ], - "AC-02(01)": [ - "IAC-15.1" + "PE-1.b": [ + "OPS-01.1" ], - "AC-02(02)": [ - "IAC-15.2" + "PL-1.b": [ + "OPS-01.1" ], - "AC-02(03)": [ - "IAC-15.3" + "PS-1.b": [ + "OPS-01.1" ], - "AC-02(04)": [ - "IAC-15.4" + "SA-1.b": [ + "OPS-01.1" ], - "AC-02(09)": [ - "IAC-15.5" + "SC-1.b": [ + "OPS-01.1" ], - "AC-06(07)": [ - "IAC-17" + "SI-1.b": [ + "OPS-01.1" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "AT-1.e": [ + "SAT-01" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "AT-1-IS.1": [ + "SAT-01" ], - "AC-06(01)": [ - "IAC-21.1" + "AT-2": [ + "SAT-02" ], - "AC-06(02)": [ - "IAC-21.2" + "AT-2.a": [ + "SAT-02" ], - "AC-06(05)": [ - "IAC-21.3" + "AT-2.b": [ + "SAT-02" ], - "AC-06(09)": [ - "IAC-21.4" + "AT-2-IS.1": [ + "SAT-02" ], - "AC-06(10)": [ - "IAC-21.5" + "AT-2-IS.2": [ + "SAT-02" ], - "AC-07": [ - "IAC-22" + "AT-3": [ + "SAT-03" ], - "AC-02(05)": [ - "IAC-24" + "AT-3.a": [ + "SAT-03" ], - "AC-11": [ - "IAC-24" + "AT-3.b": [ + "SAT-03" ], - "AC-11(01)": [ - "IAC-24.1" + "AT-3-IS.1": [ + "SAT-03" ], - "AC-12": [ - "IAC-25" + "AR-5": [ + "SAT-03.3" ], - "AC-14": [ - "IAC-26" + "AR-5.a": [ + "SAT-03.3" ], - "IA-12": [ - "IAC-28" + "AR-5.b": [ + "SAT-03.3" ], - "IA-12(02)": [ - "IAC-28.2" + "AR-5.c": [ + "SAT-03.3" ], - "IA-12(03)": [ - "IAC-28.3" + "AT-4": [ + "SAT-04" ], - "IA-12(05)": [ - "IAC-28.5" + "AT-4.a": [ + "SAT-04" ], - "IR-04": [ - "IRO-02" + "AT-4.b": [ + "SAT-04" ], - "IR-04(01)": [ - "IRO-02.1" + "SA-4": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "IR-08": [ - "IRO-04" + "SA-4.a": [ + "TDA-01" ], - "IR-02": [ - "IRO-05" + "SA-4.b": [ + "TDA-01" ], - "IR-03": [ - "IRO-06" + "SA-4.c": [ + "TDA-01" ], - "IR-03(02)": [ - "IRO-06.1" + "SA-4.d": [ + "TDA-01" ], - "IR-04(12)": [ - "IRO-08", - "IRO-13" + "SA-4.e": [ + "TDA-01" ], - "IR-05": [ - "IRO-09" + "SA-4.f": [ + "TDA-01" ], - "IR-06(01)": [ - "IRO-10.1" + "SA-4.g": [ + "TDA-01" ], - "IR-06(02)": [ - "IRO-10.3", - "IRO-13" + "SA-4.h": [ + "TDA-01" ], - "IR-04(10)": [ - "IRO-10.4", - "TPM-11" + "SA-4-IS.1": [ + "TDA-01" ], - "IR-06(03)": [ - "IRO-10.4" + "SA-4-IS.2": [ + "TDA-01" ], - "IR-07": [ - "IRO-11" + "SA-4-IS.2.a": [ + "TDA-01" ], - "IR-07(01)": [ - "IRO-11.1" + "SA-4-IS.2.b": [ + "TDA-01" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "SA-4-IS.2.c": [ + "TDA-01" ], - "IR-09(02)": [ - "IRO-12.2" + "SA-4-IS.2.d": [ + "TDA-01" ], - "IR-09(03)": [ - "IRO-12.3" + "SA-4-IS.2.e": [ + "TDA-01" ], - "IR-09(04)": [ - "IRO-12.4" + "SA-4(9)": [ + "TDA-02.1" ], - "CA-02(01)": [ - "IAO-02.1" + "SA-5.a": [ + "TDA-04" ], - "SA-11(05)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "SA-5.a.1": [ + "TDA-04" ], - "CA-02(03)": [ - "IAO-02.3" + "SA-5.a.2": [ + "TDA-04" ], - "CA-05": [ - "IAO-05" + "SA-5.a.3": [ + "TDA-04" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "SA-5.b": [ + "TDA-04" ], - "CM-04(02)": [ - "IAO-06" + "SA-5.b.1": [ + "TDA-04" ], - "CA-06": [ - "IAO-07" + "SA-5.b.2": [ + "TDA-04" ], - "MA-02": [ - "MNT-02" + "SA-5.b.3": [ + "TDA-04" ], - "MA-06": [ - "MNT-03" + "SA-5.c": [ + "TDA-04" ], - "MA-03": [ - "MNT-04" + "SA-5-IS.1": [ + "TDA-04" ], - "MA-03(01)": [ - "MNT-04.1" + "SA-5-IS.2": [ + "TDA-04" ], - "MA-03(02)": [ - "MNT-04.2" + "SA-5-IS.3": [ + "TDA-04" ], - "MA-03(03)": [ - "MNT-04.3" + "SA-5-IS.4": [ + "TDA-04" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "CM-4(1)": [ + "TDA-08" ], - "MA-05": [ - "MNT-06" + "SA-11": [ + "TDA-09" ], - "MA-05(01)": [ - "MNT-06.1" + "SA-11.a": [ + "TDA-09" ], - "SR-11(02)": [ - "MNT-07" + "SA-11.b": [ + "TDA-09" ], - "AC-19": [ - "MDM-02" + "SA-11.c": [ + "TDA-09" ], - "AC-19(05)": [ - "MDM-03" + "SA-11.d": [ + "TDA-09" ], - "SC-07": [ - "NET-03" + "SA-11.e": [ + "TDA-09" ], - "SC-07(09)": [ - "NET-03", - "NET-03.2" + "SA-11-IS.1": [ + "TDA-09" ], - "SC-07(11)": [ - "NET-03", - "NET-04.1" + "SA-11-IS.3": [ + "TDA-09" ], - "SC-07(03)": [ - "NET-03.1" + "SA-11(1)": [ + "TDA-09.2" ], - "SC-07(04)": [ - "NET-03.2" + "SA-11(1)-IS.1": [ + "TDA-09.2" ], - "SC-07(10)": [ - "NET-03.5", - "NET-17" + "SA-11(1)-IS.2": [ + "TDA-09.2" ], - "AC-04": [ - "NET-04" + "SA-10": [ + "TDA-14" ], - "SC-07(05)": [ - "NET-04.1" + "SA-10.a": [ + "TDA-14" ], - "CA-03": [ - "NET-05" + "SA-10.b": [ + "TDA-14" ], - "CA-09": [ - "NET-05.2" + "SA-10.c": [ + "TDA-14" ], - "AC-04(21)": [ - "NET-06" + "SA-10.d": [ + "TDA-14" ], - "SC-10": [ - "NET-07" + "SA-10.e": [ + "TDA-14" ], - "SC-23": [ - "NET-09" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "SC-20": [ - "NET-10" + "SA-22.a": [ + "TDA-17" ], - "SC-22": [ - "NET-10.1" + "SA-22.b": [ + "TDA-17" ], - "SC-21": [ - "NET-10.2" + "SI-11": [ + "TDA-19" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "SI-11.a": [ + "TDA-19" ], - "SI-10": [ - "NET-12", - "TDA-18" + "SI-11.b": [ + "TDA-19" ], - "AC-17": [ - "NET-14" + "SA-9": [ + "TPM-04" ], - "AC-17(01)": [ - "NET-14.1" + "SA-9.a": [ + "TPM-04" ], - "AC-17(02)": [ - "NET-14.2" + "SA-9.b": [ + "TPM-04" ], - "AC-17(03)": [ - "NET-14.3" + "SA-9.c": [ + "TPM-04" ], - "AC-17(04)": [ - "NET-14.4" + "SA-9.d": [ + "TPM-04" ], - "AC-18(01)": [ - "NET-15.1" + "SA-9.e": [ + "TPM-04" ], - "AC-18(03)": [ - "NET-15.2" + "SA-9-IS.1": [ + "TPM-04" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "SA-9-IS.2": [ + "TPM-04" ], - "PE-02": [ - "PES-02" + "SA-9-IS.3": [ + "TPM-04" ], - "PE-03": [ - "PES-03" + "SA-9(1)": [ + "TPM-04.1" ], - "SC-07(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "SA-9(1)-IS.1": [ + "TPM-04.1" ], - "PE-08": [ - "PES-03.3" + "SA-9(2)": [ + "TPM-04.2" ], - "PE-06": [ - "PES-05" + "CM-3-IS.4": [ + "TPM-05" ], - "PE-06(01)": [ - "PES-05.1" + "CM-2(1)-IS": [ + "TPM-08" ], - "PE-09": [ - "PES-07" + "CM-2(1)-IS.1": [ + "TPM-08" ], - "PE-10": [ - "PES-07.2" + "CM-2(1)-IS.2": [ + "TPM-08" ], - "PE-11": [ - "PES-07.3" + "CM-2(1)-IS.3": [ + "TPM-08" ], - "PE-12": [ - "PES-07.4" + "PM-16": [ + "THR-01" ], - "PE-15": [ - "PES-07.5" + "SI-5.a": [ + "THR-03" ], - "PE-13": [ - "PES-08" + "SI-5.b": [ + "THR-03" ], - "PE-13(01)": [ - "PES-08.1" + "SI-5.c": [ + "THR-03" ], - "PE-13(02)": [ - "PES-08.2", - "PES-08.3" + "SI-5.d": [ + "THR-03" ], - "PE-14": [ - "PES-09" + "PM-12": [ + "THR-04" ], - "PE-16": [ - "PES-10" + "AT-2(2)": [ + "THR-05" ], - "PE-17": [ - "PES-11" + "SI-2.a": [ + "VPM-01" ], - "PE-04": [ - "PES-12.1" + "SI-2.b": [ + "VPM-01" ], - "PE-05": [ - "PES-12.2" + "SI-2.c": [ + "VPM-01" ], - "PT-03": [ - "PRI-02.1", - "PRI-05.1" + "SI-2.d": [ + "VPM-01" ], - "PT-03(02)": [ - "PRI-02.2", - "PRI-10.1" + "SI-2(1)": [ + "VPM-05.1" ], - "PT-02": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "SI-2(2)": [ + "VPM-05.2" ], - "PT-07": [ - "PRI-05.4", - "PRI-05.7" + "RA-5": [ + "VPM-06", + "VPM-06.1" ], - "PM-05(01)": [ - "PRI-05.5", - "PRI-05.6" + "RA-5.a": [ + "VPM-06" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "RA-5.b": [ + "VPM-06" ], - "SA-02": [ - "PRM-03" + "RA-5.b.1": [ + "VPM-06" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "RA-5.b.2": [ + "VPM-06" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "RA-5.b.3": [ + "VPM-06" ], - "SA-03(01)": [ - "PRM-07", - "SEA-07.1", - "TDA-07" + "RA-5.c": [ + "VPM-06" ], - "SA-08(30)": [ - "PRM-07", - "SEA-07.1" + "RA-5.d": [ + "VPM-06" ], - "RA-02": [ - "RSK-02" + "RA-5.e": [ + "VPM-06" ], - "RA-07": [ - "RSK-06.1" + "RA-5-IS.1": [ + "VPM-06" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "RA-5-IS.2": [ + "VPM-06" ], - "SR-07": [ - "RSK-09", - "OPS-01" + "RA-5(1)": [ + "VPM-06" ], - "RA-03(01)": [ - "RSK-09.1" + "RA-5(2)": [ + "VPM-06.1" ], - "CA-07(04)": [ - "RSK-11" + "RA-5(3)": [ + "VPM-06.2" ], - "SC-07(18)": [ + "RA-5(5)": [ + "VPM-06.3" + ] + }, + "usa-federal-nerc-cip-2024": { + "CIP-003-8 1.1.4": [ + "GOV-01", "SEA-01" ], - "PL-08": [ - "SEA-02" + "CIP-002-5.1a 2.1": [ + "GOV-03" ], - "SC-02": [ - "SEA-03.2" + "CIP-002-5.1a 2.2": [ + "GOV-03" ], - "SC-39": [ - "SEA-04" + "CIP-003-8 R1": [ + "GOV-03" ], - "SC-04": [ - "SEA-05" + "CIP-003-8 R4": [ + "GOV-04" ], - "SA-03(03)": [ - "SEA-07.1", - "SEA-08.1" + "CIP-003-8 1.1": [ + "AST-01" ], - "SI-16": [ - "SEA-10" + "CIP-003-8 1.2.5": [ + "AST-01" ], - "AC-08": [ - "SEA-18" + "CIP-003-8 R2": [ + "AST-01" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "CIP-011-3 R1": [ + "AST-01" ], - "AT-02": [ - "SAT-02" + "CIP-011-3 1.2": [ + "AST-01", + "AST-01.1", + "DCH-01", + "END-01" ], - "AT-02(03)": [ - "SAT-02.2" + "CIP-003-8 R3": [ + "AST-01.2" ], - "AT-03": [ - "SAT-03" + "CIP-011-3 1.1": [ + "AST-02" ], - "AT-04": [ - "SAT-04" + "CIP-011-3 2.2": [ + "AST-30" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "CIP-003-8 1.1.6": [ + "BCD-01" ], - "SA-23": [ - "TDA-01", - "TDA-01.1", - "TDA-12" + "CIP-009-6 R1": [ + "BCD-01" ], - "SA-04(09)": [ - "TDA-02.1" + "CIP-009-6 R2": [ + "BCD-01" ], - "SA-04(10)": [ - "TDA-02.2" + "CIP-009-6 R3": [ + "BCD-01" ], - "SA-04(03)": [ - "TDA-02.3", - "TDA-06" + "CIP-009-6 1.1": [ + "BCD-01.5" ], - "SR-03(01)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "CIP-009-6 2.1": [ + "BCD-04" ], - "SA-15": [ - "TDA-06" + "CIP-009-6 2.3": [ + "BCD-04" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "CIP-009-6 3.1": [ + "BCD-04" ], - "SA-15(03)": [ - "TDA-06.1" + "CIP-009-6 3.1.1": [ + "BCD-05" ], - "SA-11(02)": [ - "TDA-06.2", - "TDA-15" + "CIP-009-6 3.1.2": [ + "BCD-05" ], - "SA-11": [ - "TDA-09" + "CIP-009-6 3.1.3": [ + "BCD-06" ], - "SA-11(06)": [ - "TDA-09", - "VPM-01.1" + "CIP-009-6 3.2.1": [ + "BCD-06" ], - "SA-11(07)": [ - "TDA-09", - "VPM-01.1" + "CIP-009-6 3.2": [ + "BCD-06.1" ], - "SA-11(01)": [ - "TDA-09.2" + "CIP-009-6 3.2.2": [ + "BCD-06.2" ], - "SR-11": [ - "TDA-11" + "CIP-009-6 1.3": [ + "BCD-11" ], - "SR-11(01)": [ - "TDA-11.1" + "CIP-009-6 1.4": [ + "BCD-11", + "BCD-11.1" ], - "SA-10": [ - "TDA-14" + "CIP-009-6 2.2": [ + "BCD-11.1" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "CIP-003-8 1.1.7": [ + "CHG-01", + "CFG-01", + "VPM-01" ], - "SI-11": [ - "TDA-19" + "CIP-010-4 1.4.2": [ + "CHG-02.2" ], - "SR-02(01)": [ - "TPM-03" + "CIP-010-4 1.5.1": [ + "CHG-02.2" ], - "SR-05": [ - "TPM-03.1" + "CIP-010-4 1.5.2": [ + "CHG-02.2" ], - "SR-03": [ - "TPM-03.3" + "CIP-003-8 1.1.9": [ + "CPL-01" ], - "SA-09": [ - "TPM-04" + "CIP-003-8 1.2.6": [ + "CPL-01" ], - "SA-09(01)": [ - "TPM-04.1" + "CIP-006-6 R3": [ + "CPL-03.2" ], - "SA-09(02)": [ - "TPM-04.2" + "CIP-006-6 3.1": [ + "CPL-03.2" ], - "SR-03(03)": [ - "TPM-05", - "TPM-05.2" + "CIP-010-3 R1": [ + "CFG-01" ], - "SR-08": [ - "TPM-05.1" + "CIP-010-4 1.1": [ + "CFG-02" ], - "SR-06": [ - "TPM-08" + "CIP-010-4 1.1.1": [ + "CFG-02" ], - "AT-02(02)": [ - "THR-05" + "CIP-010-4 1.1.2": [ + "CFG-02" ], - "RA-05(11)": [ - "THR-06" + "CIP-010-4 1.1.3": [ + "CFG-02" ], - "SI-02(04)": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "CIP-010-4 1.1.4": [ + "CFG-02" ], - "SI-02(02)": [ - "VPM-05.2" + "CIP-010-4 1.1.5": [ + "CFG-02" ], - "SI-02(03)": [ - "VPM-05.3" + "CIP-010-4 2.1": [ + "CFG-02", + "CFG-02.1" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "CIP-010-4 1.3": [ + "CFG-02.1" ], - "RA-05(02)": [ - "VPM-06.1" + "CIP-010-4 1.2": [ + "CFG-02.7" ], - "RA-05(03)": [ - "VPM-06.2" + "CIP-010-4 1.4": [ + "CFG-02.7" ], - "RA-05(05)": [ - "VPM-06.3" + "CIP-010-4 1.4.3": [ + "CFG-02.7" ], - "CA-08": [ - "VPM-07" + "CIP-010-4 1.5": [ + "CFG-02.7" ], - "CA-08(01)": [ - "VPM-07.1" + "CIP-010-4 1.6": [ + "CFG-02.7" ], - "CA-08(02)": [ - "VPM-10" - ] - }, - "usa-federal-gsa-fedramp-5-high": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "CIP-010-4 1.4.1": [ + "CFG-02.9" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "CIP-010-4 1.6.1": [ + "CFG-02.9" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "CIP-010-4 1.6.2": [ + "CFG-02.9" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "CIP-007-6 1.1": [ + "CFG-03" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "CIP-007-6 4.1": [ + "MON-01.4", + "MON-03" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "CIP-007-6 4.2": [ + "MON-01.4" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "CIP-007-6 4.1.1": [ + "MON-03" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "CIP-007-6 4.1.2": [ + "MON-03" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "CIP-007-6 4.1.3": [ + "MON-03" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "CIP-007-6 4.2.2": [ + "MON-05" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "CIP-006-6 1.9": [ + "MON-10", + "DCH-18" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "CIP-006-6 2.3": [ + "MON-10" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "CIP-007-6 4.3": [ + "MON-10" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "CIP-006-6 1.4": [ + "MON-16.3", + "PES-03.3", + "PES-05" ], - "PT-01": [ - "GOV-02", - "GOV-03", - "PRI-01", - "SEA-01" + "CIP-007-6 4.4": [ + "MON-17" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "CIP-006-6 1.10": [ + "CRY-01", + "PES-03", + "PES-12", + "PES-12.1" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "CIP-003-8 1.1.8": [ + "DCH-01" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "CIP-011-3 2.1": [ + "DCH-09" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "CIP-007-6 3.1": [ + "END-04", + "END-14.5" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "CIP-007-6 3.2": [ + "END-04" ], - "PL-09": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "CIP-007-6 3.3": [ + "END-04", + "END-04.4" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "CIP-007-6 4.2.1": [ + "END-04" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "CIP-007-6 1.2": [ + "END-12" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "CIP-003-8 1.1.1": [ + "HRS-01" ], - "PM-15": [ - "GOV-07", - "THR-01" + "CIP-004-7 R3": [ + "HRS-01", + "RSK-04" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "CIP-004-7 5.3": [ + "HRS-01.1", + "IAC-20.6" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "CIP-004-7 5.4": [ + "HRS-01.1" ], - "PM-05": [ - "AST-01", - "AST-02" + "CIP-004-7 6.3": [ + "HRS-01.1", + "IAC-07" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "CIP-008-6 1.3": [ + "HRS-03", + "IRO-07" ], - "CM-08(01)": [ - "AST-02.1" + "CIP-009-6 1.2": [ + "HRS-03" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "CIP-004-7 R2": [ + "HRS-03.1", + "SAT-02" ], - "SC-18(02)": [ - "AST-02.7", - "END-10" + "CIP-004-7 2.2": [ + "HRS-03.1", + "SAT-02", + "SAT-03" ], - "CM-08(02)": [ - "AST-02.9" + "CIP-004-7 3.1": [ + "HRS-04" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "CIP-004-7 3.2": [ + "HRS-04" ], - "CM-08(04)": [ - "AST-03.1" + "CIP-004-7 3.2.1": [ + "HRS-04" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "CIP-004-7 3.2.2": [ + "HRS-04" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "CIP-004-7 3.3": [ + "HRS-04" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "CIP-004-7 3.4": [ + "HRS-04" ], - "PE-22": [ - "AST-04.1", - "PES-16" + "CIP-004-7 3.5": [ + "HRS-04" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "CIP-003-8 1.1.2": [ + "IAC-01", + "NET-01" ], - "SR-12": [ - "AST-09" + "CIP-003-8 1.2.3": [ + "IAC-01" ], - "SR-09": [ - "AST-15" + "CIP-004-7 R4": [ + "IAC-01" ], - "SR-09(01)": [ - "AST-15" + "CIP-004-7 4.1.1": [ + "IAC-01" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "CIP-004-7 R6": [ + "IAC-01" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "CIP-007-6 5.1": [ + "IAC-01", + "IAC-01.2" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "CIP-007-6 5.2": [ + "IAC-01.3" ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" + "CIP-005-7 1.4": [ + "IAC-04" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "CIP-005-7 2.3": [ + "IAC-06", + "NET-14" ], - "CP-02(01)": [ - "BCD-01.1" + "CIP-004-7 6.1.1": [ + "IAC-07" ], - "CP-06(02)": [ - "BCD-01.4" + "CIP-004-7 6.1.2": [ + "IAC-07", + "PES-02" ], - "CP-02(08)": [ - "BCD-02" + "CIP-004-7 4.1": [ + "IAC-08" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "CIP-007-6 5.6": [ + "IAC-10" + ], + "CIP-007-6 5.5.1": [ + "IAC-10.1" ], - "CP-02(05)": [ - "BCD-02.2" + "CIP-007-6 5.5.2": [ + "IAC-10.1" ], - "CP-03": [ - "BCD-03" + "CIP-007-6 5.4": [ + "IAC-10.8" ], - "CP-03(01)": [ - "BCD-03.1" + "CIP-007-6 5.3": [ + "IAC-15", + "IAC-15.5" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "CIP-004-7 4.3": [ + "IAC-17" ], - "CP-04(01)": [ - "BCD-04.1" + "CIP-004-7 6.2": [ + "IAC-17" ], - "CP-04(02)": [ - "BCD-04.2" + "CIP-004-7 6.2.1": [ + "IAC-17" ], - "CP-06": [ - "BCD-08" + "CIP-004-7 6.2.2": [ + "IAC-17" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "CIP-004-7 R5": [ + "IAC-20.6" ], - "CP-06(01)": [ - "BCD-08.1" + "CIP-004-7 5.1": [ + "IAC-20.6" ], - "CP-06(03)": [ - "BCD-08.2" + "CIP-004-7 5.2": [ + "IAC-20.6" ], - "CP-07": [ - "BCD-09" + "CIP-013-2 1.2.3": [ + "IAC-20.6" ], - "CP-07(01)": [ - "BCD-09.1" + "CIP-007-6 5.7": [ + "IAC-22" ], - "CP-07(02)": [ - "BCD-09.2" + "CIP-005-7 2.5": [ + "IAC-25", + "NET-14.6", + "NET-14.8" ], - "CP-07(03)": [ - "BCD-09.3" + "CIP-005-7 3.2": [ + "IAC-25", + "NET-14.6", + "NET-14.8" ], - "CP-07(04)": [ - "BCD-09.4" + "CIP-004-7 6.1": [ + "IAC-28.1" ], - "CP-08": [ - "BCD-10" + "CIP-003-8 1.1.5": [ + "IRO-01" ], - "CP-08(02)": [ - "BCD-10" + "CIP-003-8 1.2.4": [ + "IRO-01" ], - "CP-08(01)": [ - "BCD-10.1" + "CIP-008-6 1.1": [ + "IRO-01", + "IRO-02", + "IRO-02.4", + "IRO-04" ], - "CP-08(03)": [ - "BCD-10.2" + "CIP-008-6 3.2": [ + "IRO-01" ], - "CP-08(04)": [ - "BCD-10.3" + "CIP-008-6 1.2.1": [ + "IRO-02", + "IRO-02.4", + "IRO-03" ], - "CP-09": [ - "BCD-11" + "CIP-008-6 1.4": [ + "IRO-02", + "IRO-04" ], - "SC-28(02)": [ - "BCD-11", - "CRY-05.2" + "CIP-008-6 1.2.2": [ + "IRO-02.4", + "IRO-03" ], - "CP-09(01)": [ - "BCD-11.1" + "CIP-008-6 R1": [ + "IRO-04" ], - "CP-09(03)": [ - "BCD-11.2" + "CIP-008-6 R2": [ + "IRO-04" ], - "CP-09(08)": [ - "BCD-11.4" + "CIP-008-6 2.2": [ + "IRO-04" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "CIP-008-6 R3": [ + "IRO-04" ], - "CP-09(02)": [ - "BCD-11.5" + "CIP-008-6 3.1.2": [ + "IRO-04.2", + "IRO-13" ], - "CP-09(05)": [ - "BCD-11.6" + "CIP-008-6 3.1.3": [ + "IRO-04.2", + "IRO-05" ], - "CP-10(02)": [ - "BCD-12.1" + "CIP-008-6 3.2.1": [ + "IRO-04.2" ], - "SI-13": [ - "BCD-12.2", - "SEA-07" + "CIP-008-6 3.2.2": [ + "IRO-04.2", + "IRO-05" ], - "CP-10(04)": [ - "BCD-12.4" + "CIP-008-6 2.1": [ + "IRO-06" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "CIP-008-6 3.1": [ + "IRO-06" ], - "SC-05(02)": [ - "CAP-02", - "CAP-03" + "CIP-008-6 2.3": [ + "IRO-08", + "IRO-09" ], - "CP-02(02)": [ - "CAP-03" + "CIP-009-6 1.5": [ + "IRO-08" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "CIP-008-6 4.2": [ + "IRO-10", + "IRO-10.2", + "IRO-10.5" ], - "SA-08(31)": [ - "CHG-02", - "CHG-02.2", - "CHG-06" + "CIP-008-6 4.3": [ + "IRO-10" ], - "CM-03(01)": [ - "CHG-02.1" + "CIP-013-2 1.2.2": [ + "IRO-10.4", + "TPM-11" ], - "CM-03(02)": [ - "CHG-02.2", - "CHG-06" + "CIP-008-6 R4": [ + "IRO-10.5" ], - "CM-03(04)": [ - "CHG-02.3" + "CIP-008-6 4.1": [ + "IRO-10.5" ], - "CM-03(06)": [ - "CHG-02.5" + "CIP-008-6 4.1.1": [ + "IRO-10.5" ], - "CM-04": [ - "CHG-03" + "CIP-008-6 4.1.2": [ + "IRO-10.5" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "CIP-008-6 4.1.3": [ + "IRO-10.5" ], - "CM-05(01)": [ - "CHG-04.1" + "CIP-008-6 3.1.1": [ + "IRO-13" ], - "CM-14": [ - "CHG-04.2" + "CIP-007-6 2.4": [ + "IAO-05", + "VPM-02" ], - "SI-07(15)": [ - "CHG-04.2" + "CIP-005-7 3.1": [ + "MNT-05.5", + "NET-14.6" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "CIP-005-7 1.1": [ + "NET-01" ], - "CM-05(05)": [ - "CHG-04.4" + "CIP-005-7 1.2": [ + "NET-01" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "CIP-005-7 1.5": [ + "NET-03", + "NET-08" ], - "SI-06": [ - "CHG-06" + "CIP-005-7 1.3": [ + "NET-04" ], - "SC-07(29)": [ - "CLD-03", - "NET-03.8", - "NET-06.1" + "CIP-005-7 2.1": [ + "NET-14" ], - "SA-09(05)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "CIP-005-7 2.4": [ + "NET-14", + "NET-14.6" ], - "SA-09(08)": [ - "CLD-09", - "DCH-19" + "CIP-005-7 2.2": [ + "NET-14.2" ], - "CA-07": [ - "CPL-02" + "CIP-003-8 1.1.3": [ + "PES-01" ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" + "CIP-003-8 1.2.2": [ + "PES-01" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "CIP-006-6 R1": [ + "PES-01.1" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "CIP-006-6 1.1": [ + "PES-01.1", + "PES-03", + "OPS-01.1" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "CIP-006-6 1.2": [ + "PES-01.2", + "PES-02.1", + "PES-06", + "PES-06.3" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "CIP-004-7 4.1.2": [ + "PES-02", + "PES-06.3" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "CIP-004-7 4.2": [ + "PES-02" ], - "PL-10": [ - "CFG-02" + "CIP-006-6 1.3": [ + "PES-03", + "PES-06", + "PES-06.3" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "CIP-006-6 1.5": [ + "PES-03", + "PES-03.1", + "PES-05.1" ], - "SA-15(05)": [ - "CFG-02", - "SEA-01" + "CIP-006-6 1.8": [ + "PES-03.3" ], - "CM-02(02)": [ - "CFG-02.2" + "CIP-006-6 1.6": [ + "PES-05" ], - "CM-06(01)": [ - "CFG-02.2" + "CIP-006-6 1.7": [ + "PES-05", + "PES-05.1" ], - "CM-02(03)": [ - "CFG-02.3" + "CIP-006-6 R2": [ + "PES-06" ], - "CM-02(07)": [ - "CFG-02.5" + "CIP-006-6 2.2": [ + "PES-06", + "PES-06.2" ], - "CM-06(02)": [ - "CFG-02.8" + "CIP-006-6 2.1": [ + "PES-06.3" ], - "PL-11": [ - "CFG-02.9" + "CIP-013-2 1.1": [ + "RSK-01" ], - "CM-07": [ - "CFG-03" + "CIP-002-5.1a 1.1": [ + "RSK-02.1" ], - "CM-07(01)": [ - "CFG-03.1" + "CIP-002-5.1a 1.2": [ + "RSK-02.1" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" + "CIP-002-5.1a 1.3": [ + "RSK-02.1" ], - "CM-07(05)": [ - "CFG-03.3" + "CIP-013-2 R1": [ + "RSK-09" ], - "SC-18(04)": [ - "CFG-03.3", - "END-10" + "CIP-013-2 R2": [ + "RSK-09" ], - "SC-07(07)": [ - "CFG-03.4" + "CIP-013-2 R3": [ + "RSK-09" ], - "CM-10": [ - "CFG-04" + "CIP-003-8 1.2.1": [ + "SAT-01" ], - "CM-11": [ - "CFG-05", - "END-03" + "CIP-004-7 1.1": [ + "SAT-02" ], - "CM-11(02)": [ - "CFG-05", - "CFG-05.2", - "END-03" + "CIP-004-7 2.1.1": [ + "SAT-02" ], - "CM-11(03)": [ - "CFG-05.1", - "CFG-06", - "CFG-06.1", - "END-03.1" + "CIP-004-7 2.1.2": [ + "SAT-02" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "CIP-004-7 2.1.3": [ + "SAT-02" ], - "SI-04(01)": [ - "MON-01.1" + "CIP-004-7 2.1.4": [ + "SAT-02" ], - "SI-04(25)": [ - "MON-01.1", - "NET-03.1" + "CIP-004-7 2.1.5": [ + "SAT-02" ], - "SC-48": [ - "MON-01.2", - "THR-07" + "CIP-004-7 2.1.6": [ + "SAT-02" ], - "SI-04(02)": [ - "MON-01.2" + "CIP-004-7 2.1.7": [ + "SAT-02" ], - "SI-04(04)": [ - "MON-01.3" + "CIP-004-7 2.1.8": [ + "SAT-02" ], - "SI-04(05)": [ - "MON-01.4" + "CIP-004-7 2.1.9": [ + "SAT-02" ], - "SI-04(14)": [ - "MON-01.5" + "CIP-004-7 2.3": [ + "SAT-03" ], - "SI-04(23)": [ - "MON-01.6" + "CIP-013-2 1.2.4": [ + "TDA-02.11" ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" + "CIP-013-2 1.2.5": [ + "TPM-03" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "CIP-013-2 1.2.6": [ + "TPM-03" ], - "IR-04(05)": [ - "MON-01.11", - "IRO-02.6" + "CIP-013-2 1.2.1": [ + "TPM-05.1", + "TPM-11" ], - "SI-04(07)": [ - "MON-01.11", - "IRO-02.1" + "CIP-007-6 1.3": [ + "VPM-01", + "VPM-05" ], - "SI-04(12)": [ - "MON-01.12", - "MON-05.1" + "CIP-007-6 2.1": [ + "VPM-01" ], - "SI-04(19)": [ - "MON-01.14" + "CIP-007-6 2.2": [ + "VPM-02" ], - "SI-04(20)": [ - "MON-01.15" + "CIP-007-6 2.3": [ + "VPM-02", + "VPM-05" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "CIP-010-4 3.1": [ + "VPM-06" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "CIP-010-4 3.2.1": [ + "VPM-06" ], - "AU-06(03)": [ - "MON-02.1" + "CIP-010-4 3.2.2": [ + "VPM-06" ], - "SI-04(16)": [ - "MON-02.1" + "CIP-010-4 3.3": [ + "VPM-06" ], - "AU-06(04)": [ - "MON-02.2" + "CIP-010-4 3.4": [ + "VPM-06" + ] + }, + "usa-federal-nispom-2020": { + "§117.18(b)": [ + "GOV-01" ], - "AU-06(05)": [ - "MON-02.3" + "§117.18(b)(1)": [ + "GOV-02" ], - "AU-06(06)": [ - "MON-02.4" + "§117.18(a)(1)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5" ], - "AU-06(07)": [ - "MON-02.5" + "§117.18(e)": [ + "GOV-15" ], - "AU-12(01)": [ - "MON-02.7" + "§117.18(a)(2)": [ + "GOV-15.1" ], - "AU-12(03)": [ - "MON-02.8" + "§117.18(e)(1)": [ + "GOV-15.1" ], - "AU-03": [ - "MON-03" + "§117.18(e)(2)": [ + "GOV-15.1" ], - "AU-03(01)": [ - "MON-03.1" + "§117.18(e)(3)": [ + "GOV-15.1" ], - "AU-06(01)": [ - "MON-03.1" + "§117.18(e)(4)": [ + "GOV-15.2" ], - "AU-04": [ - "MON-04" + "§117.18(e)(5)": [ + "GOV-15.3" ], - "AU-05": [ - "MON-05" + "§117.18(e)(6)": [ + "GOV-15.4" ], - "AU-05(02)": [ - "MON-05.1" + "§117.18(e)(7)": [ + "GOV-15.5" ], - "AU-05(01)": [ - "MON-05.2" + "§117.18(e)(7)(i)": [ + "GOV-15.5" ], - "AU-07": [ - "MON-06" + "§117.18(e)(7)(ii)": [ + "GOV-15.5" ], - "AU-07(01)": [ - "MON-06" + "§117.18(e)(7)(iii)": [ + "GOV-15.5" ], - "AU-12": [ - "MON-06" + "§117.18(e)(7)(iv)": [ + "GOV-15.5" ], - "AU-08": [ - "MON-07", - "SEA-20" + "§117.18(b)(6)": [ + "CHG-01" ], - "SC-45": [ - "MON-07.1" + "§117.18(f)": [ + "CPL-01" ], - "SC-45(01)": [ - "MON-07.1" + "§117.18(c)(1)(i)": [ + "CPL-01.5" ], - "AU-09": [ - "MON-08" + "§117.15(d)(2)": [ + "MON-01.1" ], - "AU-09(02)": [ - "MON-08.1" + "§117.15(d)(2)(i)": [ + "MON-01.1" ], - "AU-09(04)": [ - "MON-08.2" + "§117.15(d)(2)(i)(A)": [ + "MON-01.1" ], - "AU-09(03)": [ - "MON-08.3" + "§117.15(d)(2)(i)(B)": [ + "MON-01.1" ], - "AU-10": [ - "MON-09" + "§117.15(d)(2)(i)(C)": [ + "MON-01.1" ], - "AU-11": [ - "MON-10" + "§117.15(d)(2)(i)(D)": [ + "MON-01.1" ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" + "§117.15(d)(2)(i)(E)": [ + "MON-01.1" ], - "SI-04(22)": [ - "MON-11.2" + "§117.15(d)(2)(ii)": [ + "MON-01.1" ], - "AC-02(12)": [ - "MON-16" + "§117.15(d)(2)(iii)": [ + "MON-01.1" ], - "IR-04(13)": [ - "MON-16", - "SEA-11", - "SEA-12" + "§117.15(d)(2)(iv)": [ + "MON-01.1" ], - "SI-04(11)": [ - "MON-16" + "§117.15(d)(2)(v)": [ + "MON-01.1" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "§117.15(d)(3)": [ + "MON-01.8" ], - "SC-08(02)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" + "§117.15(d)(3)(i)": [ + "MON-01.8" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "§117.15(d)(3)(i)(A)": [ + "MON-01.8" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "§117.15(d)(3)(i)(B)": [ + "MON-01.8" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "§117.15(d)(3)(ii)": [ + "MON-01.8" ], - "SC-16(01)": [ - "CRY-04", - "CRY-10" + "§117.15(d)(3)(ii)(A)": [ + "MON-01.8" ], - "SC-28": [ - "CRY-05", - "END-02" + "§117.15(d)(3)(ii)(B)": [ + "MON-01.8" ], - "AC-18": [ - "CRY-07", - "NET-15" + "§117.15(d)(3)(ii)(C)": [ + "MON-01.8" ], - "SC-40": [ - "CRY-07", - "NET-12.1" + "§117.15(d)(3)(ii)(D)": [ + "MON-01.8" ], - "SC-12": [ - "CRY-08" + "§117.15(d)(3)(iii)": [ + "MON-01.8" ], - "SC-17": [ - "CRY-08" + "§117.15(a)": [ + "DCH-01.2" ], - "SC-12(01)": [ - "CRY-09.3" + "§117.15(a)(1)": [ + "DCH-01.2" ], - "MP-02": [ - "DCH-03", - "END-01" + "§117.15(a)(2)": [ + "DCH-01.2" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "§117.15(a)(2)(i)": [ + "DCH-01.2" ], - "MP-04": [ - "DCH-06" + "§117.15(a)(2)(ii)": [ + "DCH-01.2" ], - "MP-05": [ - "DCH-07" + "§117.15(a)(3)": [ + "DCH-01.2" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "§117.15(a)(3)(i)": [ + "DCH-01.2" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" + "§117.15(a)(3)(ii)": [ + "DCH-01.2" ], - "MP-06(01)": [ - "DCH-09.1" + "§117.15(a)(3)(iii)": [ + "DCH-01.2" ], - "MP-06(02)": [ - "DCH-09.2" + "§117.15(a)(3)(iii)(A)": [ + "DCH-01.2" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "§117.15(a)(3)(iii)(B)": [ + "DCH-01.2" ], - "AC-20": [ - "DCH-13" + "§117.15(a)(3)(iii)(C)": [ + "DCH-01.2" ], - "AC-20(01)": [ - "DCH-13.1" + "§117.15(a)(3)(iii)(D)": [ + "DCH-01.2" ], - "AC-20(02)": [ - "DCH-13.2" + "§117.15(a)(3)(iii)(E)": [ + "DCH-01.2" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "§117.15(a)(3)(iii)(F)": [ + "DCH-01.2" ], - "CA-03(06)": [ - "DCH-14.2" + "§117.15(a)(3)(iv)": [ + "DCH-01.2" ], - "AC-22": [ - "DCH-15" + "§117.15(a)(3)(iv)(A)": [ + "DCH-01.2" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "§117.15(a)(3)(iv)(B)": [ + "DCH-01.2" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "§117.15(b)": [ + "DCH-01.2" ], - "SI-12(01)": [ - "DCH-18.1", - "PRI-05.1" + "§117.15(c)": [ + "DCH-01.2" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "§117.15(c)(1)": [ + "DCH-01.2" ], - "SA-08(33)": [ - "DCH-18.2", - "END-13.3", - "PES-06.5" + "§117.15(c)(2)": [ + "DCH-01.2" ], - "SI-12(02)": [ - "DCH-18.2", - "PRI-05.1" + "§117.15(c)(3)": [ + "DCH-01.2" ], - "SI-12(03)": [ - "DCH-21", - "PRI-05" + "§117.15(e)(2)": [ + "DCH-01.2" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "§117.15(e)(3)": [ + "DCH-01.2" ], - "SI-18(04)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "§117.15(e)(3)(i)": [ + "DCH-01.2" ], - "SI-18(05)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "§117.15(e)(3)(ii)": [ + "DCH-01.2" ], - "PT-03(01)": [ - "DCH-22.2", - "PRI-11" + "§117.15(e)(3)(iii)": [ + "DCH-01.2" ], - "SI-19(01)": [ - "DCH-22.3", - "DCH-23.1" + "§117.15(e)(3)(iv)": [ + "DCH-01.2" ], - "SI-19(04)": [ - "DCH-23.4", - "PRI-05.3" + "§117.15(e)(6)": [ + "DCH-01.2" ], - "CM-12": [ - "DCH-24" + "§117.15(f)": [ + "DCH-01.2" ], - "CM-12(01)": [ - "DCH-24.1" + "§117.15(f)(1)": [ + "DCH-01.2" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "§117.15(f)(2)": [ + "DCH-01.2" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "§117.15(f)(3)": [ + "DCH-01.2" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "§117.15(h)": [ + "DCH-03.1" ], - "SI-07(01)": [ - "END-06.1" + "§117.15(h)(1)": [ + "DCH-03.1" ], - "SI-07(07)": [ - "END-06.2" + "§117.15(h)(2)": [ + "DCH-03.1" ], - "SI-07(02)": [ - "END-06.3" + "§117.15(h)(2)(i)": [ + "DCH-03.1" ], - "SI-07(05)": [ - "END-06.4" + "§117.15(h)(2)(i)(A)": [ + "DCH-03.1" ], - "SI-08": [ - "END-08" + "§117.15(h)(2)(i)(B)": [ + "DCH-03.1" ], - "SI-08(02)": [ - "END-08.2" + "§117.19(b)(3)(i)": [ + "DCH-03.1" ], - "SC-18": [ - "END-10" + "§117.19(b)(4)(i)": [ + "DCH-03.1" ], - "SC-18(01)": [ - "END-10", - "VPM-02", - "VPM-04" + "§117.19(b)(5)(i)": [ + "DCH-03.1" ], - "SC-18(03)": [ - "END-10", - "NET-18" + "§117.14(a)(1)": [ + "DCH-04" ], - "SC-15": [ - "END-14" + "§117.14(a)(2)": [ + "DCH-04" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "§117.14(b)": [ + "DCH-04" ], - "SC-07(12)": [ - "END-16.1" + "§117.14(c)": [ + "DCH-04" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "§117.14(d)": [ + "DCH-04" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "§117.14(e)": [ + "DCH-04" ], - "PS-09": [ - "HRS-03" + "§117.14(f)": [ + "DCH-04" ], - "PS-03": [ - "HRS-04" + "§117.14(f)(1)": [ + "DCH-04" ], - "PS-03(03)": [ - "HRS-04.1" + "§117.14(f)(2)": [ + "DCH-04" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "§117.14(g)": [ + "DCH-04" ], - "PL-04(01)": [ - "HRS-05.2" + "§117.14(g)(1)": [ + "DCH-04" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "§117.14(g)(2)": [ + "DCH-04" ], - "PS-06(02)": [ - "HRS-06", - "HRS-06.1" + "§117.14(h)": [ + "DCH-04" ], - "PS-08": [ - "HRS-07" + "§117.14(i)": [ + "DCH-04" ], - "PS-05": [ - "HRS-08" + "§117.14(i)(1)": [ + "DCH-04" ], - "PS-04": [ - "HRS-09" + "§117.14(i)(1)(i)": [ + "DCH-04" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "§117.14(i)(1)(ii)": [ + "DCH-04" ], - "PS-04(02)": [ - "HRS-09.4" + "§117.14(i)(2)": [ + "DCH-04" ], - "PS-07": [ - "HRS-10" + "§117.14(i)(3)": [ + "DCH-04" ], - "AC-03(02)": [ - "HRS-12.1", - "IAC-20.5" + "§117.14(i)(4)": [ + "DCH-04" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "§117.14(j)": [ + "DCH-04" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "§117.14(j)(1)": [ + "DCH-04" ], - "IA-02": [ - "IAC-02" + "§117.14(j)(1)(i)": [ + "DCH-04" ], - "IA-02(05)": [ - "IAC-02.1" + "§117.14(j)(1)(ii)": [ + "DCH-04" ], - "IA-02(08)": [ - "IAC-02.2" + "§117.14(j)(1)(iii)": [ + "DCH-04" ], - "IA-02(12)": [ - "IAC-02.3" + "§117.14(j)(2)": [ + "DCH-04" ], - "IA-08": [ - "IAC-03" + "§117.14(j)(3)": [ + "DCH-04" ], - "IA-08(01)": [ - "IAC-03.1" + "§117.14(k)": [ + "DCH-04" ], - "IA-08(02)": [ - "IAC-03.2" + "§117.14(k)(1)": [ + "DCH-04" ], - "IA-08(04)": [ - "IAC-03.3" + "§117.14(k)(2)": [ + "DCH-04" ], - "IA-03": [ - "IAC-04" + "§117.14(k)(3)": [ + "DCH-04" ], - "IA-03(04)": [ - "IAC-04", - "IAC-04.1" + "§117.14(k)(3)(i)": [ + "DCH-04" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "§117.14(k)(3)(ii)": [ + "DCH-04" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "§117.14(k)(3)(iii)": [ + "DCH-04" ], - "IA-02(06)": [ - "IAC-06.4" + "§117.14(l)": [ + "DCH-04" ], - "IA-12(04)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" + "§117.14(m)": [ + "DCH-04" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "§117.14(m)(1)": [ + "DCH-04" ], - "AC-02(07)": [ - "IAC-08" + "§117.14(m)(2)": [ + "DCH-04" ], - "IA-05(08)": [ - "IAC-09.5", - "IAC-10.9" + "§117.14(m)(2)(i)": [ + "DCH-04" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "§117.14(m)(2)(ii)": [ + "DCH-04" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "§117.14(m)(2)(iii)": [ + "DCH-04" ], - "IA-05(02)": [ - "IAC-10.2" + "§117.14(m)(3)": [ + "DCH-04" ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" + "§117.14(n)": [ + "DCH-04" ], - "IA-05(07)": [ - "IAC-10.6" + "§117.14(n)(1)": [ + "DCH-04" ], - "IA-05(13)": [ - "IAC-10.10" + "§117.14(n)(2)": [ + "DCH-04" ], - "IA-06": [ - "IAC-11" + "§117.14(n)(3)": [ + "DCH-04" ], - "IA-11": [ - "IAC-14" + "§117.14(o)": [ + "DCH-04" ], - "AC-02(01)": [ - "IAC-15.1" + "§117.14(p)": [ + "DCH-04" ], - "AC-02(02)": [ - "IAC-15.2" + "§117.14(q)": [ + "DCH-04" ], - "AC-02(03)": [ - "IAC-15.3" + "§117.15(f)(4)": [ + "DCH-07.1" ], - "AC-02(04)": [ - "IAC-15.4" + "§117.15(f)(4)(i)": [ + "DCH-07.1" ], - "AC-02(09)": [ - "IAC-15.5" + "§117.15(f)(4)(ii)": [ + "DCH-07.1" ], - "AC-02(11)": [ - "IAC-15.8" + "§117.15(f)(4)(iii)": [ + "DCH-07.1" ], - "AC-06(07)": [ - "IAC-17" + "§117.15(f)(4)(iv)": [ + "DCH-07.1" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "§117.15(h)(8)(iii)": [ + "DCH-08" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "§117.15(i)": [ + "DCH-08" ], - "AC-06(01)": [ - "IAC-21.1" + "§117.15(i)(1)": [ + "DCH-08" ], - "AC-06(02)": [ - "IAC-21.2" + "§117.15(i)(2)": [ + "DCH-08" ], - "AC-06(05)": [ - "IAC-21.3" + "§117.15(g)": [ + "DCH-21" ], - "AC-06(09)": [ - "IAC-21.4" + "§117.15(g)(1)": [ + "DCH-21" ], - "AC-06(10)": [ - "IAC-21.5" + "§117.15(g)(2)": [ + "DCH-21" ], - "AC-06(03)": [ - "IAC-21.6" + "§117.18(c)(2)": [ + "HRS-03" ], - "AC-06(08)": [ - "IAC-21.7" + "§117.18(c)(2)(i)": [ + "HRS-03" ], - "AC-07": [ - "IAC-22" + "§117.18(c)(2)(ii)": [ + "HRS-03" ], - "AC-10": [ - "IAC-23" + "§117.18(c)(2)(iii)": [ + "HRS-03" ], - "AC-02(05)": [ - "IAC-24" + "§117.18(c)(2)(iv)": [ + "HRS-03" ], - "AC-11": [ - "IAC-24" + "§117.18(c)(2)(v)": [ + "HRS-03" ], - "AC-11(01)": [ - "IAC-24.1" + "§117.18(c)(2)(vi)": [ + "HRS-03" ], - "AC-12": [ - "IAC-25" + "§117.18(c)(2)(vii)": [ + "HRS-03" ], - "AC-14": [ - "IAC-26" + "§117.18(c)(2)(vii)(A)": [ + "HRS-03" ], - "IA-12": [ - "IAC-28" + "§117.18(c)(2)(vii)(B)": [ + "HRS-03" ], - "IA-12(02)": [ - "IAC-28.2" + "§117.18(c)(2)(vii)(C)": [ + "HRS-03" ], - "IA-12(03)": [ - "IAC-28.3" + "§117.18(c)(2)(vii)(D)": [ + "HRS-03" ], - "IA-12(05)": [ - "IAC-28.5" + "§117.18(c)(2)(vii)(E)": [ + "HRS-03" ], - "IR-04": [ - "IRO-02" + "§117.18(c)(2)(vii)(F)": [ + "HRS-03" ], - "IR-04(01)": [ - "IRO-02.1" + "§117.18(c)(2)(vii)(G)": [ + "HRS-03" ], - "IR-04(06)": [ - "IRO-02.2" + "§117.18(c)(2)(vii)(H)": [ + "HRS-03" ], - "IR-04(02)": [ - "IRO-02.3" + "§117.18(c)(2)(vii)(I)": [ + "HRS-03" ], - "IR-08": [ - "IRO-04" + "§117.18(c)(3)": [ + "HRS-03" ], - "IR-02": [ - "IRO-05" + "§117.18(c)(3)(i)": [ + "HRS-03" ], - "IR-02(01)": [ - "IRO-05.1" + "§117.18(c)(3)(ii)": [ + "HRS-03" ], - "IR-02(02)": [ - "IRO-05.2" + "§117.18(c)(3)(iii)": [ + "HRS-03" ], - "IR-03": [ - "IRO-06" + "§117.18(c)(4)": [ + "HRS-03" ], - "IR-03(02)": [ - "IRO-06.1" + "§117.18(c)(4)(i)": [ + "HRS-03" ], - "IR-04(11)": [ - "IRO-07" + "§117.18(c)(4)(ii)": [ + "HRS-03" ], - "IR-04(12)": [ - "IRO-08", - "IRO-13" + "§117.18(c)(4)(iii)": [ + "HRS-03" ], - "IR-05": [ - "IRO-09" + "§117.18(c)(4)(iv)": [ + "HRS-03" ], - "IR-05(01)": [ - "IRO-09.1" + "§117.18(c)(4)(v)": [ + "HRS-03" ], - "IR-06(01)": [ - "IRO-10.1" + "§117.18(c)(4)(vi)": [ + "HRS-03" ], - "IR-06(02)": [ - "IRO-10.3", - "IRO-13" + "§117.15(e)(5)": [ + "IAC-10" ], - "IR-04(10)": [ - "IRO-10.4", - "TPM-11" + "§117.18(b)(2)": [ + "IRO-01" ], - "IR-06(03)": [ - "IRO-10.4" + "§117.15(e)(4)": [ + "PES-03" ], - "IR-07": [ - "IRO-11" + "§117.18(c)(1)(ii)": [ + "PRM-02" ], - "IR-07(01)": [ - "IRO-11.1" + "§117.18(d)": [ + "PRM-07" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "§117.18(d)(1)": [ + "PRM-07" ], - "IR-09(02)": [ - "IRO-12.2" + "§117.18(d)(2)": [ + "PRM-07" ], - "IR-09(03)": [ - "IRO-12.3" + "§117.18(d)(3)": [ + "PRM-07" ], - "IR-09(04)": [ - "IRO-12.4" + "§117.18(b)(7)": [ + "SEA-18" ], - "CA-02(01)": [ - "IAO-02.1" + "§117.18(b)(3)": [ + "SAT-01" ], - "CA-02(02)": [ - "IAO-02.2" + "§117.12(e)": [ + "SAT-02" ], - "SA-11(05)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "§117.12(i)": [ + "SAT-02" ], - "CA-02(03)": [ - "IAO-02.3" + "§117.12(j)": [ + "SAT-02" ], - "CA-05": [ - "IAO-05" + "§117.12(k)": [ + "SAT-02" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "§117.12(l)": [ + "SAT-02" ], - "CM-04(02)": [ - "IAO-06" + "§117.12(a)": [ + "SAT-03", + "SAT-03.3" ], - "CA-06": [ - "IAO-07" + "§117.12(b)": [ + "SAT-03" ], - "MA-02": [ - "MNT-02" + "§117.12(e)(6)": [ + "SAT-03" ], - "MA-02(02)": [ - "MNT-02.1" + "§117.12(d)": [ + "SAT-03.3" ], - "MA-06": [ - "MNT-03" + "§117.12(e)(3)": [ + "SAT-03.3" ], - "MA-03": [ - "MNT-04" + "§117.12(e)(4)": [ + "SAT-03.3" ], - "MA-03(01)": [ - "MNT-04.1" + "§117.12(e)(5)": [ + "SAT-03.3" ], - "MA-03(02)": [ - "MNT-04.2" + "§117.12(f)": [ + "SAT-03.3" ], - "MA-03(03)": [ - "MNT-04.3" + "§117.12(h)": [ + "SAT-03.3" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "§117.12(h)(1)": [ + "SAT-03.3" ], - "MA-04(03)": [ - "MNT-05.6" + "§117.12(h)(2)": [ + "SAT-03.3" ], - "MA-05": [ - "MNT-06" + "§117.12(h)(2)(i)": [ + "SAT-03.3" ], - "MA-05(01)": [ - "MNT-06.1" + "§117.12(h)(2)(ii)": [ + "SAT-03.3" ], - "SR-11(02)": [ - "MNT-07" + "§117.12(h)(2)(iii)": [ + "SAT-03.3" ], - "AC-19": [ - "MDM-02" + "§117.12(h)(2)(iv)": [ + "SAT-03.3" ], - "AC-19(05)": [ - "MDM-03" + "§117.12(h)(2)(v)": [ + "SAT-03.3" ], - "SC-07": [ - "NET-03" + "§117.12(h)(2)(vi)": [ + "SAT-03.3" ], - "SC-07(09)": [ - "NET-03", - "NET-03.2" + "§117.12(h)(2)(vii)": [ + "SAT-03.3" ], - "SC-07(11)": [ - "NET-03", - "NET-04.1" + "§117.12(e)(1)": [ + "SAT-03.6" ], - "SC-07(03)": [ - "NET-03.1" + "§117.12(e)(2)": [ + "SAT-03.6" ], - "SC-07(04)": [ - "NET-03.2" + "§117.12(g)(3)": [ + "SAT-04" ], - "SC-07(10)": [ - "NET-03.5", - "NET-17" + "§117.12(h)(3)": [ + "SAT-04" ], - "SC-07(20)": [ - "NET-03.6" + "§117.18(b)(5)": [ + "THR-01" ], - "SC-07(21)": [ - "NET-03.7" + "§117.18(b)(4)": [ + "THR-04" ], - "AC-04": [ - "NET-04" + "§117.18(b)(4)(i)": [ + "THR-04" ], - "SC-07(05)": [ - "NET-04.1" + "§117.18(b)(4)(ii)": [ + "THR-04" ], - "AC-04(04)": [ - "NET-04.3" + "§117.18(b)(4)(iii)": [ + "THR-04" ], - "CA-03": [ - "NET-05" + "§117.18(b)(4)(iv)": [ + "THR-04" ], - "CA-09": [ - "NET-05.2" + "§117.12(g)": [ + "THR-05" ], - "AC-04(21)": [ - "NET-06" + "§117.12(g)(1)": [ + "THR-05" ], - "SC-10": [ - "NET-07" + "§117.12(g)(1)(i)": [ + "THR-05" ], - "SC-23": [ - "NET-09" + "§117.12(g)(1)(ii)": [ + "THR-05" ], - "SC-20": [ - "NET-10" + "§117.12(g)(1)(iii)": [ + "THR-05" ], - "SC-22": [ - "NET-10.1" + "§117.12(g)(1)(iv)": [ + "THR-05" ], - "SC-21": [ - "NET-10.2" + "§117.12(g)(2)": [ + "THR-05" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "§117.12(g)(2)(i)": [ + "THR-05" ], - "SI-10": [ - "NET-12", - "TDA-18" + "§117.12(g)(2)(ii)": [ + "THR-05" ], - "AC-17": [ - "NET-14" + "§117.12(g)(2)(iii)": [ + "THR-05" ], - "AC-17(01)": [ - "NET-14.1" + "§117.12(g)(2)(iv)": [ + "THR-05" + ] + }, + "usa-federal-dow-safeguarding-nnpi-2010": { + "13-2.b(2)": [ + "GOV-02" ], - "AC-17(02)": [ - "NET-14.2" + "9-2.b": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5" ], - "AC-17(03)": [ - "NET-14.3" + "9-3.a": [ + "GOV-15.4" ], - "AC-17(04)": [ - "NET-14.4" + "9-3.b": [ + "GOV-15.4" ], - "AC-18(01)": [ - "NET-15.1" + "9-3.d": [ + "GOV-15.4", + "MDM-06" ], - "AC-18(03)": [ - "NET-15.2" + "6-2.a": [ + "AST-09" ], - "AC-18(04)": [ - "NET-15.3" + "6-3": [ + "AST-09" ], - "AC-18(05)": [ - "NET-15.4" + "6-3.a": [ + "AST-09" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "11-3.a(4)(d)": [ + "AST-09" ], - "SI-04(10)": [ - "NET-18.2" + "11-3.a(5)(c)": [ + "AST-09" ], - "PE-02": [ - "PES-02" + "11-3.c": [ + "AST-09" ], - "PE-03": [ - "PES-03" + "11-3.a(5)(a)": [ + "AST-30" ], - "SC-07(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "11-3.a(5)(b)": [ + "AST-30" ], - "PE-08": [ - "PES-03.3" + "9-3.c": [ + "CLD-09", + "DCH-07" ], - "PE-03(01)": [ - "PES-03.4" + "9-2.d": [ + "CPL-01" ], - "PE-06": [ - "PES-05" + "9-5": [ + "CPL-01" ], - "PE-06(01)": [ - "PES-05.1" + "11-2": [ + "CPL-01" ], - "PE-06(04)": [ - "PES-05.2" + "11-3.b(2)": [ + "CPL-01" ], - "PE-08(01)": [ - "PES-06.4" + "11-6": [ + "CPL-01" ], - "PE-09": [ - "PES-07" + "13-3": [ + "CPL-01" ], - "PE-10": [ - "PES-07.2" + "13-3.a": [ + "CPL-01" ], - "PE-11": [ - "PES-07.3" + "13-4": [ + "CPL-01" ], - "PE-11(01)": [ - "PES-07.3" + "12-2.d": [ + "CRY-01" ], - "PE-12": [ - "PES-07.4" + "12-2.e(1)": [ + "CRY-01" ], - "PE-15": [ - "PES-07.5" + "9-2": [ + "DCH-01", + "DCH-01.2" ], - "PE-15(01)": [ - "PES-07.6" + "9-2.a": [ + "DCH-01.2", + "DCH-01.4" ], - "PE-13": [ - "PES-08" + "8-3.a(2)": [ + "DCH-03.1", + "PES-04.1" ], - "PE-13(01)": [ - "PES-08.1" + "2-6": [ + "DCH-04" ], - "PE-13(02)": [ - "PES-08.2", - "PES-08.3" + "2-7": [ + "DCH-04" ], - "PE-14": [ - "PES-09" + "2-7.a(1)": [ + "DCH-04" ], - "PE-14(02)": [ - "PES-09.1" + "2-7.a(2)": [ + "DCH-04" ], - "PE-16": [ - "PES-10" + "2-7.a(3)": [ + "DCH-04" ], - "PE-17": [ - "PES-11" + "2-7.b": [ + "DCH-04" ], - "PE-18": [ - "PES-12" + "2-7.b(1)(a)": [ + "DCH-04" ], - "PE-04": [ - "PES-12.1" + "2-7.b(1)(b)": [ + "DCH-04" ], - "PE-05": [ - "PES-12.2" + "2-7.b(2)(a)": [ + "DCH-04" ], - "PT-03": [ - "PRI-02.1", - "PRI-05.1" + "2-7.b(2)(b)": [ + "DCH-04" ], - "PT-03(02)": [ - "PRI-02.2", - "PRI-10.1" + "2-7.c(1)": [ + "DCH-04" ], - "PT-02": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "2-7.c(2)": [ + "DCH-04" ], - "PT-07": [ - "PRI-05.4", - "PRI-05.7" + "2-7.c(2)(a)": [ + "DCH-04" ], - "PM-05(01)": [ - "PRI-05.5", - "PRI-05.6" + "2-7.c(2)(b)": [ + "DCH-04" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "2-7.c(2)(c)": [ + "DCH-04" ], - "SA-02": [ - "PRM-03" + "9-2.c": [ + "DCH-04" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "11-5": [ + "DCH-07" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "11-5.a": [ + "DCH-07" ], - "SA-03(01)": [ - "PRM-07", - "SEA-07.1", - "TDA-07" + "11-5.b": [ + "DCH-07" ], - "SA-08(30)": [ - "PRM-07", - "SEA-07.1" + "6-1.a": [ + "DCH-21" ], - "RA-02": [ - "RSK-02" + "6-1.b": [ + "DCH-21" ], - "RA-07": [ - "RSK-06.1" + "6-1.c": [ + "DCH-21" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "6-3.b": [ + "DCH-21" ], - "SR-07": [ - "RSK-09", - "OPS-01" + "9-2.e": [ + "HRS-03" ], - "RA-03(01)": [ - "RSK-09.1" + "9-3.e": [ + "IRO-12" ], - "CA-07(04)": [ - "RSK-11" + "9-4": [ + "IRO-12" ], - "SC-07(18)": [ - "SEA-01" + "11-3.a(4)(a)": [ + "IAO-01" ], - "PL-08": [ - "SEA-02" + "11-3.a(4)(b)": [ + "IAO-02" ], - "SC-02": [ - "SEA-03.2" + "11-3.a(4)(c)": [ + "IAO-02" ], - "SC-39": [ - "SEA-04" + "11-3.a(2)(b)3": [ + "IAO-03" ], - "SC-04": [ - "SEA-05" + "11-3.b(3)": [ + "IAO-03" ], - "SA-03(03)": [ - "SEA-07.1", - "SEA-08.1" + "11-3.a(3)(c)": [ + "IAO-07" ], - "SC-24": [ - "SEA-07.2" + "12-2.a": [ + "NET-03.2" ], - "SI-16": [ - "SEA-10" + "8-3.a": [ + "PES-06" ], - "AC-08": [ - "SEA-18" + "8-3.a(1)": [ + "PES-06" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "8-3.a(3)": [ + "PES-06" ], - "AT-02": [ - "SAT-02" + "12-2.b": [ + "SAT-03.3" ], - "AT-02(03)": [ - "SAT-02.2" + "7-2": [ + "TPM-05", + "TPM-05.2" ], - "AT-03": [ - "SAT-03" + "7-3": [ + "TPM-05" ], - "AT-04": [ - "SAT-04" + "7-4": [ + "TPM-05", + "TPM-05.2" ], - "SA-04": [ - "TDA-01", - "TDA-02", + "7-5": [ + "TPM-05", + "TPM-05.2" + ] + }, + "usa-federal-sec-cybersecurity-rule-2023": { + "17 CFR 229.106(b)(1)(iii)": [ + "GOV-01.1", + "GOV-01.2", + "RSK-09", + "RSK-09.1", "TPM-01", - "TPM-10" + "TPM-02", + "TPM-03", + "TPM-05" ], - "SA-23": [ - "TDA-01", - "TDA-01.1", - "TDA-12" + "17 CFR 229.106(c)(1)": [ + "GOV-01.1", + "GOV-01.2", + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "SA-04(09)": [ - "TDA-02.1" + "17 CFR 229.106(c)(2)": [ + "GOV-01.1", + "GOV-16" ], - "SA-04(10)": [ - "TDA-02.2" + "17 CFR 229.106(c)(2)(i)": [ + "GOV-01.1", + "GOV-04" ], - "SA-04(03)": [ - "TDA-02.3", - "TDA-06" + "17 CFR 229.106(c)(2)(iii)": [ + "GOV-01.1", + "GOV-01.2" ], - "SR-03(01)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "Form 8-K Item 1.05(a)": [ + "GOV-01.1", + "GOV-04", + "GOV-06", + "GOV-16", + "IRO-01", + "IRO-02", + "IRO-02.4", + "IRO-04", + "IRO-07", + "IRO-10" ], - "SA-04(05)": [ - "TDA-02.4" + "17 CFR 229.106(c)(2)(ii)": [ + "GOV-01.2" ], - "SA-17": [ - "TDA-05" + "17 CFR 229.106(b)(1)(ii)": [ + "GOV-04", + "HRS-03.2", + "TPM-05.4" ], - "SA-15": [ - "TDA-06" + "17 CFR 229.106(b)(1)(i)": [ + "GOV-15", + "RSK-01", + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-04" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "17 CFR 229.105(a)": [ + "GOV-16", + "GOV-16.1", + "GOV-16.2", + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-03.1", + "RSK-04.1" ], - "SA-15(03)": [ - "TDA-06.1" + "17 CFR 229.105(b)": [ + "GOV-16", + "GOV-16.1", + "GOV-16.2", + "GOV-17", + "RSK-02", + "RSK-03.1", + "RSK-04.1" ], - "SA-11(02)": [ - "TDA-06.2", - "TDA-15" + "17 CFR 229.106(a)": [ + "GOV-16", + "GOV-16.2", + "RSK-04", + "THR-10" ], - "CM-04(01)": [ - "TDA-08" + "17 CFR 229.106(b)(2)": [ + "GOV-16", + "GOV-16.1", + "GOV-16.2" ], - "SA-11": [ - "TDA-09" + "17 CFR 229.106(d)": [ + "GOV-17" ], - "SA-11(06)": [ - "TDA-09", - "VPM-01.1" + "17 CFR 229.106(b)(1)": [ + "RSK-01", + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-02.1", + "RSK-03", + "RSK-04", + "RSK-05", + "RSK-06", + "RSK-06.1" + ] + }, + "usa-federal-law-sox-2002": { + "404(a)(1)": [ + "GOV-01" ], - "SA-11(07)": [ - "TDA-09", - "VPM-01.1" + "404(a)": [ + "CPL-01.4" ], - "SA-11(01)": [ - "TDA-09.2" + "404(a)(2)": [ + "CPL-01.4" ], - "SR-11": [ - "TDA-11" + "404(b)": [ + "CPL-01.4" ], - "SR-11(01)": [ - "TDA-11.1" + "302(a)": [ + "CPL-01.7" ], - "SA-21": [ - "TDA-13" + "302(a)(4)": [ + "CPL-01.7" ], - "SA-10": [ - "TDA-14" + "302(a)(4)(A)": [ + "CPL-01.7" ], - "SA-16": [ - "TDA-16" + "302(a)(4)(B)": [ + "CPL-01.7" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "302(a)(4)(C)": [ + "CPL-01.7" ], - "SI-11": [ - "TDA-19" + "302(a)(4)(D)": [ + "CPL-01.7" ], - "SR-02(01)": [ - "TPM-03" + "302(a)(1)": [ + "CPL-01.8" ], - "SR-05": [ - "TPM-03.1" + "302(a)(2)": [ + "CPL-01.8" ], - "SR-03": [ - "TPM-03.3" + "302(a)(3)": [ + "CPL-01.8" ], - "SA-09": [ - "TPM-04" + "302(a)(5)": [ + "CPL-01.8" ], - "SA-09(01)": [ - "TPM-04.1" + "302(a)(5)(A)": [ + "CPL-01.8" ], - "SA-09(02)": [ - "TPM-04.2" + "302(a)(5)(B)": [ + "CPL-01.8" ], - "SR-03(03)": [ - "TPM-05", - "TPM-05.2" + "302(a)(6)": [ + "CPL-01.8" + ] + }, + "usa-federal-tsa-security-directive-1580-82-2022-01": { + "III.B": [ + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "SR-08": [ - "TPM-05.1" + "III.B.1.d": [ + "GOV-02", + "NET-04" + ], + "III.C.1": [ + "GOV-02", + "GOV-02.1", + "GOV-15", + "GOV-15.1", + "GOV-15.2" + ], + "III.C.1.a": [ + "GOV-02" ], - "SR-06": [ - "TPM-08" + "III.C.1.b": [ + "GOV-02", + "GOV-02.1", + "RSK-06.2" ], - "SI-05(01)": [ - "THR-03" + "III.C.3": [ + "GOV-02", + "GOV-02.1", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "RSK-06.2" ], - "AT-02(02)": [ - "THR-05" + "III.D": [ + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "RSK-06.2" ], - "RA-05(11)": [ - "THR-06" + "III.D.1": [ + "GOV-15" ], - "SI-02(04)": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "II.B.1": [ + "GOV-17" ], - "SI-02(02)": [ - "VPM-05.2" + "III.F.3": [ + "GOV-17" ], - "SI-02(03)": [ - "VPM-05.3" + "V.A.1": [ + "GOV-17" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "VI.A": [ + "GOV-17" ], - "RA-05(02)": [ - "VPM-06.1" + "VI.B": [ + "GOV-17" ], - "RA-05(03)": [ - "VPM-06.2" + "VI.B.1": [ + "GOV-17" ], - "RA-05(05)": [ - "VPM-06.3" + "VI.B.2": [ + "GOV-17" ], - "RA-05(08)": [ - "VPM-06.5" + "VI.C": [ + "GOV-17" ], - "RA-05(04)": [ - "VPM-06.8" + "VI.D": [ + "GOV-17" ], - "CA-08": [ - "VPM-07" + "III.B.1.a": [ + "AST-01.1", + "AST-04" ], - "CA-08(01)": [ - "VPM-07.1" + "III.A": [ + "AST-01.2", + "AST-03" ], - "CA-08(02)": [ - "VPM-10" - ] - }, - "usa-federal-gsa-fedramp-5-li-saas": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "III.B.1.b": [ + "AST-04", + "NET-05" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "III.B.1.c": [ + "AST-04", + "AST-04.1", + "AST-04.2", + "NET-03", + "NET-06.3" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "II.B.2": [ + "CPL-01" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "II.B.3": [ + "CPL-01" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "IV.C.1": [ + "CPL-01.3" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "IV.C.2": [ + "CPL-03.3" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "IV.C.2.a": [ + "CPL-03.3" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "IV.C.2.b": [ + "CPL-03.3" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "IV.C.2.c": [ + "CPL-03.3" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "IV.C.2.d": [ + "CPL-03.3" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "IV.C.2.e": [ + "CPL-03.3" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "IV.C.2.e.i": [ + "CPL-03.3" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "IV.C.2.e.ii": [ + "CPL-03.3" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "IV.C.2.e.iii": [ + "CPL-03.3" ], - "PT-01": [ - "GOV-02", - "GOV-03", - "PRI-01", - "SEA-01" + "IV.C.2.e.iv": [ + "CPL-03.3" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "IV.C.2.f": [ + "CPL-03.3" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "III.C": [ + "CFG-01", + "IAC-01", + "PES-01" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "III.D.2.c": [ + "CFG-02.2", + "CFG-05.1" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "III.D.3": [ + "MON-01" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "III.D.3.a": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-01.16", + "MON-03" ], - "PL-09": [ - "GOV-04", - "MON-03.6", - "END-04.3", - "END-08.1", - "SEA-01.1", - "VPM-05.1" + "III.D.3.b": [ + "MON-01", + "MON-01.16", + "MON-03.2", + "MON-10" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "III.D.2.a": [ + "MON-01.3", + "NET-18" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "III.D.2.b": [ + "MON-01.3", + "MON-16" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "III.C.5": [ + "EMB-10", + "NET-01", + "NET-02.3" ], - "PM-15": [ - "GOV-07", - "THR-01" + "III.D.1.d": [ + "END-03", + "END-10" ], - "PM-23": [ - "GOV-10", - "PRI-10", - "PRI-13" + "III.D.1.a": [ + "END-08" ], - "PM-24": [ - "GOV-10", - "PRI-02.2", - "PRI-02.3", - "PRI-05.2", - "PRI-10", - "PRI-13" + "III.C.2": [ + "IAC-06", + "IAO-05", + "RSK-06.2" ], - "PM-05": [ - "AST-01", - "AST-02" + "III.C.4": [ + "IAC-15.5", + "IAC-19" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "III.C.4.a": [ + "IAC-15.5", + "IAC-19" ], - "CM-08(03)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" + "III.C.4.b": [ + "IAC-15.5", + "IAC-19" ], - "SC-18(02)": [ - "AST-02.7", - "END-10" + "III.D.2.d": [ + "IRO-01", + "IRO-02", + "OPS-06" ], - "SA-04(12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "III.F": [ + "IAO-01" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "III.F.1": [ + "IAO-01" ], - "SA-04(01)": [ - "AST-04", - "TDA-04.1" + "III.F.2.b": [ + "IAO-01", + "IAO-01.1", + "IAO-02" ], - "SA-04(02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "III.F.2.a": [ + "IAO-02" ], - "PE-22": [ - "AST-04.1", - "PES-16" + "III.F.2.c": [ + "IAO-02" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "III.B.2": [ + "IAO-03" ], - "SR-12": [ - "AST-09" + "III.B.2.a": [ + "IAO-03" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "III.B.2.b": [ + "IAO-03" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "III.E.3": [ + "IAO-05", + "RSK-06.2" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "III.D.1.b": [ + "NET-18", + "NET-18.1" ], - "IR-04(03)": [ - "BCD-01", - "IRO-02.4" + "III.D.1.c": [ + "NET-18" ], - "PM-08": [ - "BCD-01", - "CPL-01" + "III.D.1.e": [ + "NET-18" ], - "CP-02(03)": [ - "BCD-02.1", - "BCD-02.3" + "III.D.4": [ + "RSK-06", + "RSK-06.2" ], - "CP-03": [ - "BCD-03" + "III.D.2": [ + "OPS-01.1" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "III.E": [ + "VPM-01" ], - "PE-23": [ - "BCD-08", - "BCD-09", - "PES-01", - "PES-12", - "SEA-15", - "TPM-04.4" + "III.E.1": [ + "VPM-01", + "VPM-05" ], - "CP-09": [ - "BCD-11" + "III.E.2.a": [ + "VPM-01", + "VPM-02", + "VPM-05.3" ], - "SC-28(02)": [ - "BCD-11", - "CRY-05.2" + "III.E.2.b": [ + "VPM-01", + "VPM-02", + "VPM-03" + ] + }, + "usa-state-ak-pipa-2009": { + "45.48.500 - .590": [ + "AST-09", + "DCH-09.3" ], - "SC-28(01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "45.48.400": [ + "DCH-03.1" ], - "SI-13": [ - "BCD-12.2", - "SEA-07" + "45.48.430": [ + "DCH-03.1" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "45.48.430.1": [ + "DCH-03.1" ], - "SC-05(02)": [ - "CAP-02", - "CAP-03" + "45.48.430.2": [ + "DCH-03.1" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "45.48.430.3": [ + "DCH-03.1" ], - "SA-08(31)": [ - "CHG-02", - "CHG-02.2", - "CHG-06" + "45.48.430.4": [ + "DCH-03.1" ], - "CM-03(02)": [ - "CHG-02.2", - "CHG-06" + "45.48.430.5": [ + "DCH-03.1" ], - "CM-04": [ - "CHG-03" + "45.48.430.6": [ + "DCH-03.1" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "45.48.750": [ + "DCH-03.2" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "45.48.400 - .480": [ + "PRI-04.1" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "45.48.410": [ + "PRI-04.1" ], - "SC-07(29)": [ - "CLD-03", - "NET-03.8", - "NET-06.1" + "45.48.410.1": [ + "PRI-04.1" ], - "SA-09(05)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "45.48.410.2": [ + "PRI-04.1" ], - "SA-09(08)": [ - "CLD-09", - "DCH-19" + "45.48.410.3": [ + "PRI-04.1" ], - "CA-07": [ - "CPL-02" + "45.48.410.4": [ + "PRI-04.1" ], - "CA-07(01)": [ - "CPL-02", - "CPL-03.1" + "45.48.410.5": [ + "PRI-04.1" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "45.48.410.6": [ + "PRI-04.1" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "45.48.410.7": [ + "PRI-04.1" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "45.48.410.8": [ + "PRI-04.1" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "45.48.420": [ + "PRI-04.1" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "45.48.420.1": [ + "PRI-04.1" ], - "PL-10": [ - "CFG-02" + "45.48.420.2": [ + "PRI-04.1" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "45.48.420.3": [ + "PRI-04.1" ], - "SA-15(05)": [ - "CFG-02", - "SEA-01" + "45.48.420.4": [ + "PRI-04.1" + ] + }, + "usa-state-ca-sb327-2018": { + "1798.91.04(b)(2)": [ + "IAC-10.8", + "TDA-01.1" ], - "PL-11": [ - "CFG-02.9" + "1798.91.04(a)": [ + "TDA-01.1" ], - "CM-07": [ - "CFG-03" + "1798.91.04(a)(1)": [ + "TDA-01.1" ], - "CM-07(02)": [ - "CFG-03.2", - "SEA-06" + "1798.91.04(a)(2)": [ + "TDA-01.1" ], - "SC-18(04)": [ - "CFG-03.3", - "END-10" + "1798.91.04(a)(3)": [ + "TDA-01.1" ], - "CM-10": [ - "CFG-04" + "1798.91.04(b)": [ + "TDA-01.1" ], - "CM-11": [ - "CFG-05", - "END-03" + "1798.91.04(b)(1)": [ + "TDA-01.1", + "TDA-02.4" + ] + }, + "usa-state-ca-ccpa-cpra-2026": { + "7001": [ + "SEA-02.1" ], - "CM-11(02)": [ - "CFG-05", - "CFG-05.2", - "END-03" + "7123(b)(1)": [ + "GOV-01", + "GOV-02" ], - "CM-11(03)": [ - "CFG-05.1", - "CFG-06", - "CFG-06.1", - "END-03.1" + "7123(b)(3)": [ + "GOV-04", + "GOV-15", + "CPL-01", + "CPL-01.1", + "CPL-01.2", + "CPL-01.3" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "7124(a)": [ + "GOV-17" ], - "SI-04(25)": [ - "MON-01.1", - "NET-03.1" + "7124(b)": [ + "GOV-17" ], - "SC-48": [ - "MON-01.2", - "THR-07" + "7124(c)": [ + "GOV-17" ], - "SI-04(24)": [ - "MON-01.7", - "MON-11.3" + "7124(c)(1)": [ + "GOV-17" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "7124(c)(2)": [ + "GOV-17" ], - "IR-04(05)": [ - "MON-01.11", - "IRO-02.6" + "7124(c)(3)": [ + "GOV-17" ], - "SI-04(07)": [ - "MON-01.11", - "IRO-02.1" + "7124(d)": [ + "GOV-17" ], - "SI-04(12)": [ - "MON-01.12", - "MON-05.1" + "7124(d)(1)": [ + "GOV-17" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "7124(d)(2)": [ + "GOV-17" ], - "IR-04(04)": [ - "MON-02", - "MON-02.1" + "7124(d)(3)": [ + "GOV-17" ], - "AU-03": [ - "MON-03" + "7124(d)(4)": [ + "GOV-17" ], - "AU-04": [ - "MON-04" + "7124(d)(5)": [ + "GOV-17" ], - "AU-05": [ - "MON-05" + "7157(a)": [ + "GOV-17" ], - "AU-12": [ - "MON-06" + "7157(a)(1)": [ + "GOV-17" ], - "AU-08": [ - "MON-07", - "SEA-20" + "7157(a)(2)": [ + "GOV-17" ], - "AU-09": [ - "MON-08" + "7157(b)": [ + "GOV-17" ], - "AU-11": [ - "MON-10" + "7157(b)(1)": [ + "GOV-17" ], - "SI-04(18)": [ - "MON-11.1", - "NET-17" + "7157(b)(2)": [ + "GOV-17" ], - "IR-04(13)": [ - "MON-16", - "SEA-11", - "SEA-12" + "7157(b)(3)": [ + "GOV-17" ], - "SC-08(01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "7157(b)(4)": [ + "GOV-17" ], - "SC-08(02)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" + "7157(b)(5)": [ + "GOV-17" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "7157(b)(6)": [ + "GOV-17" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "7157(c)": [ + "GOV-17" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "7157(c)(1)": [ + "GOV-17" ], - "SC-16(01)": [ - "CRY-04", - "CRY-10" + "7157(c)(2)": [ + "GOV-17" ], - "SC-28": [ - "CRY-05", - "END-02" + "7157(c)(3)": [ + "GOV-17" ], - "AC-18": [ - "CRY-07", - "NET-15" + "7157(d)": [ + "GOV-17" ], - "SC-40": [ - "CRY-07", - "NET-12.1" + "7157(e)": [ + "GOV-17" ], - "SC-12": [ - "CRY-08" + "7123(c)(4)": [ + "AST-02" ], - "MP-02": [ - "DCH-03", - "END-01" + "7123(c)(4)(B)": [ + "AST-02", + "CFG-01", + "CFG-02", + "CFG-03.3" ], - "MP-03": [ + "7123(c)(4)(A)": [ + "AST-02.8", + "AST-04", + "AST-04.1", + "DCH-02", "DCH-04", - "DCH-04.1" - ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "DCH-04.1", + "DCH-06.2", + "DCH-22.2", + "NET-04.5", + "PRI-05.5" ], - "MP-06(03)": [ - "DCH-09", - "DCH-09.3", - "DCH-09.4" + "7123(c)(18)": [ + "BCD-01" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "7123(c)(4)(C)": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "IAO-01", + "IAO-06", + "IAO-07" ], - "AC-20": [ - "DCH-13" + "7123(c)(5)(D)": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "CHG-02.3", + "CHG-03", + "CHG-04", + "CHG-06", + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-03", + "VPM-04", + "VPM-05", + "VPM-05.1", + "VPM-06" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "7123(c)(5)(E)": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "CHG-02.3", + "CHG-03", + "CHG-06" ], - "AC-22": [ - "DCH-15" + "7123(c)(5)(B)": [ + "CLD-01", + "CLD-02", + "CLD-03", + "CFG-02", + "CFG-02.4", + "CFG-02.5", + "CFG-02.9", + "NET-01", + "NET-02", + "NET-03", + "NET-04", + "NET-04.1", + "NET-06", + "NET-06.1", + "SEA-01", + "SEA-01.1", + "SEA-02" ], - "AC-23": [ - "DCH-16", - "PRI-05.4" + "7123(c)(10)": [ + "CLD-02", + "CLD-03", + "NET-02", + "NET-06", + "NET-06.1" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "7013(h)": [ + "CPL-01" ], - "SI-12(01)": [ - "DCH-18.1", - "PRI-05.1" + "7022(d)": [ + "CPL-01", + "PRI-07.1" ], - "PM-25": [ - "DCH-18.2", - "END-13.3", - "PES-06.5", - "PRI-05.1", - "PRI-05.4" + "7023(e)": [ + "CPL-01" ], - "SA-08(33)": [ - "DCH-18.2", - "END-13.3", - "PES-06.5" + "7050(b)": [ + "CPL-01", + "PRI-07.1" ], - "SI-12(02)": [ - "DCH-18.2", - "PRI-05.1" + "7072(b)": [ + "CPL-01" ], - "SI-12(03)": [ - "DCH-21", - "PRI-05" + "7200(a)": [ + "CPL-01" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "7200(b)": [ + "CPL-01" ], - "SI-18(04)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "7123(b)(2)": [ + "CPL-01.2", + "CPL-01.4" ], - "SI-18(05)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "7122(c)": [ + "CPL-01.3", + "HRS-05.1" ], - "PT-03(01)": [ - "DCH-22.2", - "PRI-11" + "7122(a)": [ + "CPL-01.4" ], - "SI-19(01)": [ - "DCH-22.3", - "DCH-23.1" + "7122(b)": [ + "CPL-01.4", + "CPL-03" ], - "SI-19(04)": [ - "DCH-23.4", - "PRI-05.3" + "7122(d)": [ + "CPL-01.4", + "CPL-01.6" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "7122(e)": [ + "CPL-01.4" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "7122(f)": [ + "CPL-01.4", + "CPL-02" ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" + "7123(a)": [ + "CPL-01.4" ], - "SC-18(01)": [ - "END-10", - "VPM-02", - "VPM-04" + "7123(b)": [ + "CPL-01.4" ], - "SC-18(03)": [ - "END-10", - "NET-18" + "7123(c)": [ + "CPL-01.4" ], - "SC-15": [ - "END-14" + "7123(e)": [ + "CPL-01.5" ], - "SC-03": [ - "END-16", - "SEA-04.1" + "7123(e)(1)": [ + "CPL-01.5" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "7123(e)(2)": [ + "CPL-01.5" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "7123(e)(3)": [ + "CPL-01.5" ], - "PS-09": [ - "HRS-03" + "7123(e)(4)": [ + "CPL-01.5" ], - "PS-03": [ - "HRS-04" + "7123(e)(5)": [ + "CPL-01.5" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "7123(e)(6)": [ + "CPL-01.5" ], - "PL-04(01)": [ - "HRS-05.2" + "7123(e)(7)": [ + "CPL-01.5" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "7123(e)(8)": [ + "CPL-01.5" ], - "PS-06(02)": [ - "HRS-06", - "HRS-06.1" + "7123(e)(9)": [ + "CPL-01.5" ], - "PS-08": [ - "HRS-07" + "7123(e)(10)": [ + "CPL-01.5" ], - "PS-05": [ - "HRS-08" + "7123(f)": [ + "CPL-01.5" ], - "PS-04": [ - "HRS-09" + "7122(a)(1)": [ + "CPL-01.6" ], - "AC-02(13)": [ - "HRS-09.2", - "IAC-15.6" + "7122(a)(3)": [ + "CPL-02", + "CPL-02.1" ], - "PS-07": [ - "HRS-10" + "7120(a)": [ + "CPL-03" ], - "AC-03(02)": [ - "HRS-12.1", - "IAC-20.5" + "7122(a)(2)": [ + "CPL-03.1" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "7123(c)(5)": [ + "CFG-01", + "CFG-02" ], - "IA-04(04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "7123(c)(11)": [ + "CFG-01", + "CFG-02", + "CFG-02.9", + "CFG-03" ], - "IA-02": [ - "IAC-02" + "7123(c)(5)(A)": [ + "CFG-02", + "CFG-02.1", + "VPM-04.1", + "VPM-05" ], - "IA-02(08)": [ - "IAC-02.2" + "7123(c)(7)": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-02", + "MON-02.2", + "MON-02.7", + "MON-03", + "MON-03.2", + "MON-08" ], - "IA-02(12)": [ - "IAC-02.3" + "7123(c)(8)(A)": [ + "MON-01.1", + "MON-01.2", + "MON-01.3", + "MON-11.3", + "NET-01", + "NET-02", + "NET-03", + "NET-08" ], - "IA-08": [ - "IAC-03" + "7123(c)(2)": [ + "CRY-01", + "CRY-03", + "CRY-05" ], - "IA-08(01)": [ - "IAC-03.1" + "7123(c)(5)(C)": [ + "DCH-03.2", + "DCH-23.4", + "PRI-05.3" ], - "IA-08(02)": [ - "IAC-03.2" + "7123(c)(16)": [ + "DCH-08", + "DCH-09", + "DCH-09.3", + "DCH-18" ], - "IA-08(04)": [ - "IAC-03.3" + "7153(a)": [ + "DCH-14", + "TPM-05" ], - "IA-03(04)": [ - "IAC-04", - "IAC-04.1" + "7122(g)": [ + "DCH-18" ], - "IA-02(01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "7155(c)": [ + "DCH-18" ], - "IA-02(02)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "7023(c)": [ + "DCH-22", + "DCH-22.1", + "PRI-06", + "PRI-07.1", + "PRI-07.3", + "PRI-10" ], - "IA-12(04)": [ - "IAC-07", - "IAC-10.3", - "IAC-28.4" + "7123(c)(9)": [ + "END-04" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "7123(c)(3)(A)(i)": [ + "HRS-01.1", + "IAC-02", + "IAC-08" ], - "IA-05(08)": [ - "IAC-09.5", - "IAC-10.9" + "7123(c)(3)(A)(ii)": [ + "HRS-01.1", + "IAC-03", + "IAC-08", + "TPM-05", + "TPM-05.4" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "7123(c)(3)(C)": [ + "HRS-01.1", + "IAC-01", + "IAC-21.3", + "IAC-28.1" ], - "IA-05(01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "7123(c)(3)(B)": [ + "HRS-02", + "IAC-08", + "IAC-16", + "IAC-21", + "IAC-21.3" ], - "IA-05(02)": [ - "IAC-10.2" + "7123(c)(1)": [ + "IAC-01" ], - "IA-05(06)": [ - "IAC-10.5", - "IAC-18" + "7123(c)(3)": [ + "IAC-01", + "IAC-01.2" ], - "IA-06": [ - "IAC-11" + "7123(c)(1)(B)": [ + "IAC-01.2", + "IAC-10", + "IAC-10.1", + "IAC-10.14" ], - "IA-11": [ - "IAC-14" + "7123(c)(3)(A)(iii)": [ + "IAC-03", + "IAC-08", + "IAC-21", + "TPM-05" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "7123(c)(1)(A)": [ + "IAC-06" ], - "AC-06": [ - "IAC-20", + "7123(c)(3)(A)": [ + "IAC-08", "IAC-21" ], - "AC-07": [ - "IAC-22" + "7123(c)(17)": [ + "IRO-01" ], - "AC-14": [ - "IAC-26" + "7123(c)(17)(B)": [ + "IRO-01" ], - "IR-04": [ - "IRO-02" + "7027(m)(2)": [ + "IRO-02", + "PRI-01.11" ], - "IR-08": [ + "7123(c)(17)(B)(i)": [ + "IRO-02", "IRO-04" ], - "IR-02": [ - "IRO-05" + "7123(c)(17)(A)": [ + "IRO-02.4" ], - "IR-04(12)": [ - "IRO-08", - "IRO-13" + "7123(c)(17)(B)(ii)": [ + "IRO-06" ], - "IR-05": [ - "IRO-09" + "7123(c)(8)": [ + "NET-01" ], - "IR-06(02)": [ - "IRO-10.3", - "IRO-13" + "7123(c)(8)(B)": [ + "NET-17" ], - "IR-04(10)": [ - "IRO-10.4", - "TPM-11" + "7123(c)(3)(D)": [ + "PES-01", + "PES-02", + "PES-02.1", + "PES-03", + "PES-04", + "PES-04.1", + "PES-05", + "PES-06" ], - "IR-07": [ - "IRO-11" + "7002(a)": [ + "PRI-01" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "7023(d)(4)": [ + "PRI-01.6" ], - "CA-02(01)": [ - "IAO-02.1" + "7024(f)": [ + "PRI-01.6" ], - "SA-11(05)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "7027(m)": [ + "PRI-01.7", + "PRI-01.11", + "PRI-02.1" ], - "CA-05": [ - "IAO-05" + "7016(a)": [ + "PRI-01.10" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "7016(b)": [ + "PRI-01.10" ], - "CA-06": [ - "IAO-07" + "7016(c)": [ + "PRI-01.10" ], - "MA-02": [ - "MNT-02" + "7016(d)": [ + "PRI-01.10" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "7016(d)(1)": [ + "PRI-01.10" ], - "MA-05": [ - "MNT-06" + "7016(d)(2)": [ + "PRI-01.10" ], - "SR-11(02)": [ - "MNT-07" + "7016(d)(3)": [ + "PRI-01.10" ], - "AC-19": [ - "MDM-02" + "7016(d)(4)": [ + "PRI-01.10" ], - "SC-07": [ - "NET-03" + "7016(d)(5)": [ + "PRI-01.10" ], - "SC-07(09)": [ - "NET-03", - "NET-03.2" + "7016(d)(5)(A)": [ + "PRI-01.10" ], - "SC-07(11)": [ - "NET-03", - "NET-04.1" + "7016(d)(5)(B)": [ + "PRI-01.10" ], - "SC-07(10)": [ - "NET-03.5", - "NET-17" + "7027(k)": [ + "PRI-01.10", + "PRI-06.4" ], - "CA-03": [ - "NET-05" + "7081(a)": [ + "PRI-01.10" ], - "CA-09": [ - "NET-05.2" + "7081(a)(1)": [ + "PRI-01.10" ], - "SC-20": [ - "NET-10" + "7081(a)(2)": [ + "PRI-01.10" ], - "SC-22": [ - "NET-10.1" + "7081(a)(3)": [ + "PRI-01.10" ], - "SC-21": [ - "NET-10.2" + "7081(a)(4)": [ + "PRI-01.10" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "7081(a)(5)": [ + "PRI-01.10" ], - "SI-10": [ - "NET-12", - "TDA-18" + "7081(a)(6)": [ + "PRI-01.10" ], - "AC-17": [ - "NET-14" + "7081(a)(7)": [ + "PRI-01.10" ], - "SC-07(08)": [ - "NET-18", - "NET-18.1" + "7081(a)(8)": [ + "PRI-01.10" ], - "PE-02": [ - "PES-02" + "7081(b)": [ + "PRI-01.10" ], - "PE-03": [ - "PES-03" + "7002(b)": [ + "PRI-01.11" ], - "SC-07(14)": [ - "PES-03.2", - "PES-12", - "PES-12.1" + "7002(b)(1)": [ + "PRI-01.11" ], - "PE-08": [ - "PES-03.3" + "7002(b)(2)": [ + "PRI-01.11" ], - "PE-06": [ - "PES-05" + "7002(b)(3)": [ + "PRI-01.11" ], - "PE-12": [ - "PES-07.4" + "7002(d)": [ + "PRI-01.11" ], - "PE-15": [ - "PES-07.5" + "7002(d)(1)": [ + "PRI-01.11" ], - "PE-13": [ - "PES-08" + "7002(d)(2)": [ + "PRI-01.11" ], - "PE-13(02)": [ - "PES-08.2", - "PES-08.3" + "7027(m)(1)": [ + "PRI-01.11" ], - "PE-14": [ - "PES-09" + "7027(m)(3)": [ + "PRI-01.11" ], - "PE-16": [ - "PES-10" + "7027(m)(4)": [ + "PRI-01.11" ], - "PT-03": [ - "PRI-02.1", - "PRI-05.1" + "7027(m)(5)": [ + "PRI-01.11" ], - "PT-03(02)": [ - "PRI-02.2", - "PRI-10.1" + "7027(m)(6)": [ + "PRI-01.11" ], - "PT-02": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "7027(m)(7)": [ + "PRI-01.11" ], - "PT-07": [ - "PRI-05.4", - "PRI-05.7" + "7027(m)(8)": [ + "PRI-01.11" ], - "PM-05(01)": [ - "PRI-05.5", - "PRI-05.6" + "7002(b)(5)": [ + "PRI-02" ], - "PM-26": [ - "PRI-06.3", - "PRI-06.4" + "7003(a)": [ + "PRI-02", + "PRI-17" ], - "SA-02": [ - "PRM-03" + "7004(a)(1)": [ + "PRI-02" ], - "RA-09": [ - "PRM-05", - "TDA-06.1", - "TPM-02" + "7010(a)": [ + "PRI-02" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "7011(a)": [ + "PRI-02" ], - "SA-03(01)": [ - "PRM-07", - "SEA-07.1", - "TDA-07" + "7011(b)": [ + "PRI-02" ], - "SA-08(30)": [ - "PRM-07", - "SEA-07.1" + "7011(c)": [ + "PRI-02" ], - "RA-02": [ - "RSK-02" + "7011(d)": [ + "PRI-02" ], - "RA-07": [ - "RSK-06.1" + "7011(e)": [ + "PRI-02" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "7011(e)(1)": [ + "PRI-02" ], - "SR-07": [ - "RSK-09", - "OPS-01" + "7011(e)(1)(A)": [ + "PRI-02" ], - "RA-03(01)": [ - "RSK-09.1" + "7011(e)(1)(B)": [ + "PRI-02" ], - "CA-07(04)": [ - "RSK-11" + "7011(e)(1)(C)": [ + "PRI-02" ], - "PL-08": [ - "SEA-02" + "7011(e)(1)(D)": [ + "PRI-02" ], - "SC-39": [ - "SEA-04" + "7011(e)(1)(E)": [ + "PRI-02" ], - "SA-03(03)": [ - "SEA-07.1", - "SEA-08.1" + "7011(e)(1)(F)": [ + "PRI-02" ], - "AC-08": [ - "SEA-18" + "7011(e)(1)(G)": [ + "PRI-02" ], - "SC-38": [ - "OPS-01", - "OPS-04" + "7011(e)(1)(H)": [ + "PRI-02" ], - "AT-02": [ - "SAT-02" + "7011(e)(1)(I)": [ + "PRI-02" ], - "AT-03": [ - "SAT-03" + "7011(e)(1)(J)": [ + "PRI-02" ], - "AT-04": [ - "SAT-04" + "7011(e)(2)": [ + "PRI-02" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "7011(e)(2)(A)": [ + "PRI-02" ], - "SA-23": [ - "TDA-01", - "TDA-01.1", - "TDA-12" + "7011(e)(2)(B)": [ + "PRI-02" ], - "SA-04(10)": [ - "TDA-02.2" + "7011(e)(2)(C)": [ + "PRI-02" ], - "SA-04(03)": [ - "TDA-02.3", - "TDA-06" + "7011(e)(2)(D)": [ + "PRI-02" ], - "SR-03(01)": [ - "TDA-02.3", - "TDA-03.1", - "TPM-03.1" + "7011(e)(2)(E)": [ + "PRI-02" ], - "PM-30(01)": [ - "TDA-06.1", - "TDA-12", - "TPM-02" + "7011(e)(2)(F)": [ + "PRI-02" ], - "SA-11(02)": [ - "TDA-06.2", - "TDA-15" + "7011(e)(2)(G)": [ + "PRI-02" ], - "SA-11(06)": [ - "TDA-09", - "VPM-01.1" + "7011(e)(2)(H)": [ + "PRI-02" ], - "SA-11(07)": [ - "TDA-09", - "VPM-01.1" + "7011(e)(3)": [ + "PRI-02" ], - "SR-11": [ - "TDA-11" + "7011(e)(3)(A)": [ + "PRI-02" ], - "SR-11(01)": [ - "TDA-11.1" + "7011(e)(3)(B)": [ + "PRI-02" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "7011(e)(3)(C)": [ + "PRI-02" ], - "SR-02(01)": [ - "TPM-03" + "7011(e)(3)(D)": [ + "PRI-02" ], - "SR-05": [ - "TPM-03.1" + "7011(e)(3)(E)": [ + "PRI-02" ], - "SR-03": [ - "TPM-03.3" + "7011(e)(3)(F)": [ + "PRI-02" ], - "SA-09": [ - "TPM-04" + "7011(e)(3)(G)": [ + "PRI-02" ], - "SR-03(03)": [ - "TPM-05", - "TPM-05.2" + "7011(e)(3)(H)": [ + "PRI-02" ], - "SR-08": [ - "TPM-05.1" + "7011(e)(3)(I)": [ + "PRI-02" ], - "AT-02(02)": [ - "THR-05" + "7011(e)(3)(J)": [ + "PRI-02" ], - "RA-05(11)": [ - "THR-06" + "7011(e)(4)": [ + "PRI-02" ], - "SI-02(04)": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "7011(e)(5)": [ + "PRI-02" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "7012(f)": [ + "PRI-02" ], - "RA-05(02)": [ - "VPM-06.1" + "7012(g)(1)": [ + "PRI-02" ], - "CA-08": [ - "VPM-07" - ] - }, - "usa-federal-law-ferpa-2010": { - "1232h(c)(1)(C)(i)": [ - "CPL-01" + "7013(c)": [ + "PRI-02" ], - "1232g(d)": [ - "DCH-03.1" + "7013(e)": [ + "PRI-02" ], - "1232h(c)(1)(B)": [ - "DCH-03.1" + "7013(e)(1)": [ + "PRI-02" ], - "1232h(c)(1)(B)(i)": [ - "DCH-03.1" + "7013(e)(2)": [ + "PRI-02" ], - "1232h(c)(1)(B)(ii)": [ - "DCH-03.1" + "7013(e)(3)": [ + "PRI-02" ], - "1232h(c)(1)(B)(iii)": [ - "DCH-03.1" + "7013(g)(2)": [ + "PRI-02" ], - "1232h(c)(1)(B)(iv)": [ - "DCH-03.1" + "7014(b)": [ + "PRI-02" ], - "1232h(c)(1)(B)(v)": [ - "DCH-03.1" + "7014(c)": [ + "PRI-02" ], - "1232h(c)(1)(B)(vi)": [ - "DCH-03.1" + "7014(d)": [ + "PRI-02" ], - "1232h(c)(1)(B)(vii)": [ - "DCH-03.1" + "7014(e)(1)": [ + "PRI-02" ], - "1232h(c)(1)(B)(viii)": [ - "DCH-03.1" + "7014(e)(2)": [ + "PRI-02" ], - "1232h(a)": [ - "PRI-01.11" + "7014(e)(3)": [ + "PRI-02" ], - "1232h(c)(1)(C)(ii)": [ - "PRI-01.11" + "7014(g)(1)": [ + "PRI-02" ], - "1232h(c)(1)(D)": [ - "PRI-01.11" + "7014(g)(2)": [ + "PRI-02" ], - "1232h(c)(1)(E)": [ - "PRI-01.11" + "7014(h)": [ + "PRI-02", + "PRI-21.1" ], - "1232h(c)(1)(F)(i)": [ - "PRI-01.11" + "7025(g)(2)": [ + "PRI-02" ], - "1232h(c)(1)(F)(ii)": [ - "PRI-01.11" + "7025(g)(2)(A)": [ + "PRI-02" ], - "1232h(b)": [ - "PRI-03" + "7025(g)(2)(B)": [ + "PRI-02" ], - "1232h(b)(1)": [ - "PRI-03" + "7025(g)(2)(C)": [ + "PRI-02" ], - "1232h(b)(2)": [ - "PRI-03" + "7025(g)(2)(D)": [ + "PRI-02" ], - "1232h(b)(3)": [ - "PRI-03" + "7072(a)": [ + "PRI-02" ], - "1232h(b)(4)": [ - "PRI-03" + "7002(a)(1)": [ + "PRI-02.1" ], - "1232h(b)(5)": [ - "PRI-03" + "7002(a)(2)": [ + "PRI-02.1" ], - "1232h(b)(6)": [ - "PRI-03" + "7002(b)(4)": [ + "PRI-02.1" ], - "1232h(b)(7)": [ - "PRI-03" + "7002(c)": [ + "PRI-02.8" ], - "1232h(b)(8)": [ - "PRI-03" + "7002(c)(1)": [ + "PRI-02.8" ], - "1232h(c)(1)(A)(ii)": [ - "PRI-06" - ] - }, - "usa-federal-sro-finra": { - "248.30(a)(2)(ii)": [ - "GOV-01" + "7002(c)(2)": [ + "PRI-02.8" ], - "248.201(e)": [ - "GOV-01" + "7002(c)(3)": [ + "PRI-02.8" ], - "248.201(e)(1)": [ - "GOV-01.1" + "7003(b)(1)": [ + "PRI-02.9" ], - "248.201(e)(2)": [ - "GOV-01.1" + "7003(b)(2)": [ + "PRI-02.9" ], - "248.30(a)(1)": [ - "GOV-02" + "7003(b)(3)": [ + "PRI-02.9" ], - "248.30(a)(2)": [ - "GOV-02" + "7004(a)(2)": [ + "PRI-02.10" ], - "248.30(a)(2)(iii)": [ - "CFG-08", - "DCH-01", - "IAC-20" + "7004(a)(4)": [ + "PRI-02.11" ], - "248.30(a)(2)(i)": [ - "DCH-01" + "7004(b)": [ + "PRI-02.11" ], - "248.30(b)(1)": [ - "DCH-21" + "7004(c)": [ + "PRI-02.11" ], - "248.30(b)(2)": [ - "DCH-21" + "7004(a)(5)": [ + "PRI-02.12" ], - "248.30(a)(3)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "7014(a)": [ + "PRI-02.13" ], - "248.30(a)(3)(i)": [ - "IRO-02", - "IRO-02.4" + "7014(e)": [ + "PRI-02.13" ], - "248.30(a)(3)(ii)": [ - "IRO-02" + "7014(f)": [ + "PRI-02.13" ], - "248.201(d)(1)": [ - "IRO-02.2" + "7014(f)(1)": [ + "PRI-02.13" ], - "248.201(d)(2)": [ - "IRO-02.2" + "7014(f)(2)": [ + "PRI-02.13" ], - "248.201(d)(2)(i)": [ - "IRO-02.2" + "7014(e)(3)(A)": [ + "PRI-02.14" ], - "248.201(d)(2)(ii)": [ - "IRO-02.2" + "7014(e)(3)(B)": [ + "PRI-02.14" ], - "248.201(d)(2)(iii)": [ - "IRO-02.2" + "7014(e)(3)(C)": [ + "PRI-02.14" ], - "248.201(d)(2)(iv)": [ - "IRO-02.2" + "7014(e)(3)(D)": [ + "PRI-02.14" ], - "248.30(a)(3)(iii)": [ - "IRO-10" + "7002(e)": [ + "PRI-03" ], - "248.30(a)(4)(i)": [ - "IRO-10", - "IRO-16" + "7010(b)": [ + "PRI-03" ], - "248.30(a)(4)(ii)": [ - "IRO-10" + "7012(a)": [ + "PRI-03" ], - "248.30(a)(4)(iii)": [ - "IRO-10" + "7012(b)": [ + "PRI-03" ], - "248.30(a)(4)(iv)": [ - "IRO-10" + "7012(c)": [ + "PRI-03" ], - "248.30(a)(4)(iv)(A)": [ - "IRO-10" + "7012(d)": [ + "PRI-03" ], - "248.30(a)(4)(iv)(B)": [ - "IRO-10" + "7012(e)": [ + "PRI-03" ], - "248.30(a)(4)(iv)(C)": [ - "IRO-10" + "7012(e)(1)": [ + "PRI-03" ], - "248.30(a)(4)(iv)(D)": [ - "IRO-10" + "7012(e)(2)": [ + "PRI-03" ], - "248.30(a)(4)(iv)(E)": [ - "IRO-10" + "7012(e)(3)": [ + "PRI-03" ], - "248.30(a)(4)(iv)(F)": [ - "IRO-10" + "7012(e)(4)": [ + "PRI-03" ], - "248.30(a)(4)(iv)(G)": [ - "IRO-10" + "7012(e)(5)": [ + "PRI-03" ], - "248.30(a)(4)(iv)(H)": [ - "IRO-10" + "7012(e)(6)": [ + "PRI-03" ], - "248.30(a)(5)(i)(B)": [ - "IRO-10" + "7027(c)": [ + "PRI-03" ], - "248.30(a)(5)(ii)": [ - "IRO-10", - "TPM-05" + "7027(d)": [ + "PRI-03", + "PRI-06" ], - "248.30(a)(5)(iii)": [ - "IRO-10" + "7002(f)": [ + "PRI-03.2", + "PRI-04" ], - "248.201(e)(3)": [ - "SAT-03" + "7010(f)": [ + "PRI-03.2", + "PRI-03.7" ], - "248.30(a)(5)(i)": [ - "TPM-01" + "7022(g)": [ + "PRI-03.2" ], - "248.30(a)(5)(i)(A)": [ - "TPM-01" + "7022(h)": [ + "PRI-03.2" ], - "248.201(e)(4)": [ - "TPM-01" - ] - }, - "usa-federal-omb-fipps-1973": { - "1": [ - "PRI-06", - "PRI-06.1" + "7025(c)(5)": [ + "PRI-03.2", + "PRI-03.8" ], - "2": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "HRS-01", - "HRS-01.1", - "HRS-02", - "HRS-03", - "HRS-04.1", - "HRS-04.2", - "PRI-01", - "PRI-01.1", - "PRI-01.11", - "SAT-03", - "SAT-03.3" + "7026(k)": [ + "PRI-03.2" ], - "3": [ - "PRI-02.1", - "PRI-04.1" + "7027(l)": [ + "PRI-03.2" ], - "4": [ - "PRI-01.11", - "PRI-04", - "PRI-05", - "PRI-05.4" + "7221(i)": [ + "PRI-03.2" ], - "5": [ - "PRI-10" + "7221(k)": [ + "PRI-03.2" ], - "6": [ - "PRI-06", - "PRI-06.4" + "7080(a)": [ + "PRI-03.5" ], - "7": [ - "PRI-02", - "PRI-02.1", - "PRI-02.8" + "7080(b)": [ + "PRI-03.5" ], - "8": [ - "PRI-01.3", - "PRI-01.6", - "PRI-02" - ] - }, - "usa-federal-law-ftc-act": { - "45(a)(1)": [ - "GOV-01", - "GOV-01.1", - "GOV-08", - "GOV-14", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "SEA-01", - "SEA-02", - "SEA-03", - "TDA-01", - "TDA-01.1", - "TDA-06" - ] - }, - "usa-federal-law-glba-cfr-314-2023": { - "314.3(a)": [ - "GOV-01" + "7221(l)": [ + "PRI-03.5" ], - "314.3(b)(1)": [ - "GOV-01", - "GOV-09" + "7026(j)": [ + "PRI-03.6" ], - "314.3(b)(2)": [ - "GOV-01", - "GOV-09" + "7027(j)": [ + "PRI-03.6", + "PRI-07.5" ], - "314.3(b)(3)": [ - "GOV-01", - "GOV-09" + "7063(a)": [ + "PRI-03.6" ], - "314.4(a)": [ - "GOV-01", - "GOV-04", - "TPM-01", - "TPM-05" + "7063(a)(1)": [ + "PRI-03.6" ], - "314.4(b)": [ - "GOV-01", - "GOV-03", - "RSK-01", - "RSK-04" + "7063(a)(2)": [ + "PRI-03.6" ], - "314.4(c)": [ - "GOV-01", - "GOV-02", - "CPL-01", - "SEA-01", - "SEA-01.1" + "7063(b)": [ + "PRI-03.6" ], - "314.4(a)(2)": [ - "GOV-01.1", - "GOV-04", - "TPM-01", - "TPM-05" + "7063(c)": [ + "PRI-03.6" ], - "314.4(i)": [ - "GOV-01.2" + "7063(d)": [ + "PRI-03.6" ], - "314.4(i)(1)": [ - "GOV-01.2" + "7221(j)": [ + "PRI-03.6" ], - "314.4(i)(2)": [ - "GOV-01.2" + "7010(e)": [ + "PRI-03.7" ], - "314.4(c)(8)": [ - "GOV-02", - "OPS-01.1" + "7025(c)(4)": [ + "PRI-03.7" ], - "314.4(e)": [ - "GOV-02", - "OPS-01.1" + "7027(b)": [ + "PRI-03.7", + "PRI-03.9" ], - "314.4(g)": [ - "GOV-03" + "7027(i)": [ + "PRI-03.7" ], - "314.4(a)(1)": [ - "GOV-04", - "TPM-01", - "TPM-05" + "7025(a)": [ + "PRI-03.8" ], - "314.4(a)(3)": [ - "GOV-04", - "TPM-01", - "TPM-05" + "7025(b)": [ + "PRI-03.8" ], - "314.4(c)(6)(i)": [ - "AST-09", - "DCH-08", - "DCH-21", - "PRI-05" + "7025(b)(1)": [ + "PRI-03.8" ], - "314.4(c)(7)": [ - "CHG-01", - "CHG-02", - "OPS-01", - "OPS-01.1" + "7025(b)(2)": [ + "PRI-03.8" ], - "314.4(d)(1)": [ - "CPL-02", - "CPL-03" + "7025(c)": [ + "PRI-03.8" ], - "314.4(c)(3)": [ - "CRY-01" + "7025(c)(1)": [ + "PRI-03.8" ], - "314.4(c)(1)(i)": [ - "DCH-01", - "IAC-01", - "IAC-20", - "IAC-21" + "7025(c)(2)": [ + "PRI-03.8" ], - "314.4(c)(6)(ii)": [ - "DCH-01", - "DCH-18" + "7025(c)(3)": [ + "PRI-03.8" ], - "314.4(e)(2)": [ - "HRS-01", - "HRS-03.2", - "HRS-04.1" + "7025(c)(6)": [ + "PRI-03.8" ], - "314.4(c)(1)": [ - "IAC-01" + "7025(d)": [ + "PRI-03.8" ], - "314.4(c)(1)(ii)": [ - "IAC-01", - "IAC-08" + "7025(e)": [ + "PRI-03.8" ], - "314.4(c)(5)": [ - "IAC-06" + "7025(f)": [ + "PRI-03.8" ], - "314.4(h)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "7025(f)(1)": [ + "PRI-03.8" ], - "314.4(h)(1)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "7025(f)(2)": [ + "PRI-03.8" ], - "314.4(h)(2)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "7025(f)(3)": [ + "PRI-03.8" ], - "314.4(h)(3)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07" + "7025(g)": [ + "PRI-03.8" ], - "314.4(h)(4)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-10" + "7025(g)(1)": [ + "PRI-03.8" ], - "314.4(h)(5)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "7025(g)(3)": [ + "PRI-03.8" ], - "314.4(h)(6)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-09" + "7022(f)(3)": [ + "PRI-03.9" ], - "314.4(h)(7)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-04.2", - "IRO-13" + "7027(g)(1)": [ + "PRI-03.9", + "PRI-03.10" ], - "314.4(c)(2)": [ - "RSK-03", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-06.2" + "7028(a)": [ + "PRI-03.12" ], - "314.4(b)(1)": [ - "RSK-04" + "7028(b)": [ + "PRI-03.12" ], - "314.4(b)(1)(i)": [ - "RSK-04" + "7028(c)": [ + "PRI-03.12" ], - "314.4(b)(1)(ii)": [ - "RSK-04" + "7070(a)": [ + "PRI-03.13" ], - "314.4(b)(1)(iii)": [ - "RSK-04" + "7070(a)(1)": [ + "PRI-03.13" ], - "314.4(b)(2)": [ - "RSK-07" + "7070(a)(2)": [ + "PRI-03.13" ], - "314.2": [ - "SEA-02.1" + "7070(a)(2)(A)": [ + "PRI-03.13" ], - "314.4(e)(1)": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6" + "7070(a)(2)(B)": [ + "PRI-03.13" ], - "314.4(e)(3)": [ - "SAT-03.5" + "7070(a)(2)(C)": [ + "PRI-03.13" ], - "314.4(e)(4)": [ - "SAT-03.7" + "7070(a)(2)(D)": [ + "PRI-03.13" ], - "314.4(c)(4)": [ - "TDA-01", - "TDA-06" + "7070(a)(2)(E)": [ + "PRI-03.13" ], - "314.4(f)": [ - "TPM-01" + "7070(a)(2)(F)": [ + "PRI-03.13" ], - "314.4(f)(1)": [ - "TPM-02", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-04.1", - "TPM-04.4" + "7070(b)": [ + "PRI-03.13" ], - "314.4(f)(2)": [ - "TPM-04" + "7070(c)": [ + "PRI-03.13" ], - "314.4(f)(3)": [ - "TPM-04", - "TPM-04.1", - "TPM-08" + "7071(a)": [ + "PRI-03.13" ], - "314.4(d)(2)": [ - "VPM-01", - "VPM-06", - "VPM-07" + "7071(b)": [ + "PRI-03.13" ], - "314.4(d)(2)(ii)": [ - "VPM-06" + "7023(d)(3)": [ + "PRI-05.4" ], - "314.4(d)(2)(i)": [ - "VPM-07" - ] - }, - "usa-federal-hhs-45-cfr-155-260-2016": { - "155.260(a)(3)": [ - "GOV-01", - "PRI-01" + "7026(f)": [ + "PRI-05.4" ], - "155.260(d)": [ - "GOV-02" + "7026(f)(1)": [ + "PRI-05.4" ], - "155.260(d)(1)": [ - "GOV-02" + "7027(a)": [ + "PRI-05.4" ], - "155.260(d)(2)": [ - "GOV-02" + "7024(j)": [ + "PRI-05.7", + "PRI-06" ], - "155.260(a)(5)": [ - "GOV-03" + "7024(l)": [ + "PRI-05.7", + "TPM-01", + "TPM-01.1" ], - "155.260(a)(3)(viii)": [ - "GOV-15", - "CPL-02", - "MON-01" + "7020(a)": [ + "PRI-06" ], - "155.260(a)(4)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "CPL-01" + "7020(b)": [ + "PRI-06" ], - "155.260(a)(4)(i)": [ - "GOV-15" + "7020(c)": [ + "PRI-06" ], - "155.260(a)(4)(iii)": [ - "GOV-15" + "7020(d)": [ + "PRI-06" ], - "155.260(c)": [ - "GOV-15", - "HRS-05" + "7020(e)": [ + "PRI-06" ], - "155.260(a)(6)": [ - "CLD-04", - "CFG-02", - "CRY-03" + "7020(f)": [ + "PRI-06" ], - "155.260(b)(3)(i)": [ - "CPL-01" + "7020(f)(1)": [ + "PRI-06" ], - "155.260(b)(3)(ii)": [ - "CPL-01" + "7020(f)(2)": [ + "PRI-06" ], - "155.260(b)(3)(iii)": [ - "CPL-01" + "7022(b)": [ + "PRI-06" ], - "155.260(b)(3)(iii)(A)": [ - "CPL-01" + "7023(d)(1)": [ + "PRI-06", + "PRI-06.1", + "PRI-06.3" ], - "155.260(b)(3)(iii)(B)": [ - "CPL-01" + "7024(g)": [ + "PRI-06", + "PRI-06.6", + "PRI-06.7", + "WEB-06" ], - "155.260(b)(3)(iii)(C)": [ - "CPL-01" + "7024(h)": [ + "PRI-06" ], - "155.260(e)(1)": [ - "CPL-01" + "7027(e)": [ + "PRI-06", + "WEB-06" ], - "155.260(e)(2)": [ - "CPL-01" + "7023(a)": [ + "PRI-06.1", + "PRI-06.4", + "PRI-12.1" ], - "155.260(e)(3)": [ - "CPL-01" + "7023(b)": [ + "PRI-06.1", + "PRI-07.4", + "PRI-12", + "PRI-12.1" ], - "155.260(e)(4)": [ - "CPL-01" + "7023(d)(2)": [ + "PRI-06.1" ], - "155.260(a)(4)(iv)": [ - "DCH-01" + "7022(e)": [ + "PRI-06.2", + "PRI-06.4" ], - "155.260(a)(4)(v)": [ - "DCH-01" + "7023(f)": [ + "PRI-06.2" ], - "155.260(a)(4)(ii)": [ - "DCH-01.4", - "DCH-02", - "IAC-08" + "7023(f)(3)": [ + "PRI-06.3", + "PRI-06.4" ], - "155.260(a)(4)(vi)": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "7021(a)": [ + "PRI-06.4" ], - "155.260(a)(2)": [ - "DCH-10.1" + "7021(b)": [ + "PRI-06.4" ], - "155.260(a)(3)(vi)": [ - "DCH-22.1", - "PRI-05.2" + "7022(f)": [ + "PRI-06.4" ], - "155.260(a)(3)(vii)": [ - "PRI-01.6" + "7022(f)(1)": [ + "PRI-06.4" ], - "155.260(a)(1)": [ - "PRI-01.7" + "7023(d)(2)(A)": [ + "PRI-06.4" ], - "155.260(a)(1)(ii)": [ - "PRI-01.7" + "7023(d)(2)(B)": [ + "PRI-06.4" ], - "155.260(a)(1)(iii)": [ - "PRI-01.7" + "7023(d)(2)(C)": [ + "PRI-06.4" ], - "155.260(a)(1)(iii)(A)": [ - "PRI-01.7" + "7023(d)(2)(D)": [ + "PRI-06.4" ], - "155.260(a)(3)(iii)": [ - "PRI-02" + "7023(f)(1)": [ + "PRI-06.4" ], - "155.260(a)(3)(iv)": [ - "PRI-03" + "7023(f)(2)": [ + "PRI-06.4" ], - "155.260(a)(3)(v)": [ - "PRI-05.4" + "7023(f)(4)": [ + "PRI-06.4" ], - "155.260(a)(3)(i)": [ - "PRI-06" + "7023(i)": [ + "PRI-06.4" ], - "155.260(a)(3)(ii)": [ - "PRI-06.3" + "7023(j)": [ + "PRI-06.4" ], - "155.260(e)": [ - "PRI-07" + "7023(k)": [ + "PRI-06.4" ], - "155.260(b)(2)": [ - "TPM-05" + "7024(c)": [ + "PRI-06.4" ], - "155.260(b)(2)(i)": [ - "TPM-05" + "7024(c)(1)": [ + "PRI-06.4" ], - "155.260(b)(2)(ii)": [ - "TPM-05" + "7024(c)(2)": [ + "PRI-06.4" ], - "155.260(b)(2)(iii)": [ - "TPM-05" + "7024(c)(3)": [ + "PRI-06.4" ], - "155.260(b)(2)(iv)": [ - "TPM-05" + "7024(c)(4)": [ + "PRI-06.4" ], - "155.260(b)(2)(v)": [ - "TPM-05.2" - ] - }, - "usa-federal-law-hipaa-simplification-2013": { - "164.306(a)(1)": [ - "GOV-01", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5" + "7024(d)": [ + "PRI-06.4" ], - "164.306(a)(2)": [ - "GOV-01" + "7024(d)(1)": [ + "PRI-06.4" ], - "164.306(a)(3)": [ - "GOV-01", - "DCH-01", - "RSK-01" + "7024(d)(2)": [ + "PRI-06.4" ], - "164.316(a)": [ - "GOV-01", - "GOV-02" + "7024(e)": [ + "PRI-06.4" ], - "164.530(c)(1)": [ - "GOV-01" + "7024(e)(1)": [ + "PRI-06.4" ], - "164.530(i)(1)": [ - "GOV-01", - "CPL-01", - "PRI-01" + "7024(e)(2)": [ + "PRI-06.4" ], - "164.308(a)(1)(i)": [ - "GOV-02", - "CHG-01", - "CFG-01", - "MON-01", - "IRO-01" + "7024(k)": [ + "PRI-06.4" ], - "164.308(a)(3)(i)": [ - "GOV-02", - "CFG-08", - "IAC-01", - "IAC-08", - "IAC-21" + "7024(k)(1)": [ + "PRI-06.4" ], - "164.308(a)(4)(i)": [ - "GOV-02", - "IAC-01" + "7024(k)(2)": [ + "PRI-06.4" ], - "164.308(a)(4)(ii)(A)": [ - "GOV-02" + "7024(k)(3)": [ + "PRI-06.4" ], - "164.308(a)(6)(i)": [ - "GOV-02", - "IRO-01" + "7024(k)(4)": [ + "PRI-06.4" ], - "164.308(a)(7)(i)": [ - "GOV-02", - "BCD-01", - "IRO-01" + "7024(k)(5)": [ + "PRI-06.4" ], - "164.310(a)(1)": [ - "GOV-02", - "PES-01" + "7024(k)(6)": [ + "PRI-06.4" ], - "164.310(a)(2)(ii)": [ - "GOV-02", - "PES-01", - "PES-03" + "7027(h)": [ + "PRI-06.4" ], - "164.310(a)(2)(iv)": [ - "GOV-02", - "MNT-01", - "MNT-02", - "PES-01" + "7022(b)(1)": [ + "PRI-06.5" ], - "164.310(b)": [ - "GOV-02", - "END-01", - "HRS-05", - "HRS-05.1", - "HRS-05.3", - "PES-03.4", - "PES-04", - "OPS-01.1", - "OPS-03" + "7022(f)(2)": [ + "PRI-06.5" ], - "164.310(d)(1)": [ - "GOV-02", - "AST-01", - "AST-11", - "DCH-01", - "DCH-03", - "DCH-07", - "DCH-07.1", - "DCH-13.2", - "MNT-01", - "MNT-04.3" + "7060(a)": [ + "PRI-06.8" ], - "164.310(d)(2)(i)": [ - "GOV-02", - "AST-01", - "AST-09" + "7060(b)": [ + "PRI-06.8", + "PRI-21.1" ], - "164.312(a)(1)": [ - "GOV-02", - "HRS-02", - "HRS-03", - "IAC-01", - "IAC-08", - "IAC-21" + "7060(c)": [ + "PRI-06.8" ], - "164.312(c)(1)": [ - "GOV-02", - "DCH-01", - "DCH-01.2" + "7060(c)(1)": [ + "PRI-06.8" ], - "164.316(b)(1)(i)": [ - "GOV-02" + "7060(c)(2)": [ + "PRI-06.8" ], - "164.530(j)(1)(i)": [ - "GOV-02" + "7060(c)(3)": [ + "PRI-06.8" ], - "164.306(d)(3)(ii)(B)(1)": [ - "GOV-02.1" + "7060(c)(3)(A)": [ + "PRI-06.8" ], - "164.316(b)(1)(ii)": [ - "GOV-03", - "CPL-03" + "7060(c)(3)(B)": [ + "PRI-06.8" ], - "164.316(b)(2)(iii)": [ - "GOV-03", - "CPL-02" + "7060(c)(3)(C)": [ + "PRI-06.8" ], - "164.530(i)(2)(i)": [ - "GOV-03" + "7060(c)(3)(D)": [ + "PRI-06.8" ], - "164.530(i)(2)(ii)": [ - "GOV-03" + "7060(c)(3)(E)": [ + "PRI-06.8" ], - "164.530(i)(2)(iii)": [ - "GOV-03" + "7060(c)(3)(F)": [ + "PRI-06.8" ], - "164.530(i)(3)": [ - "GOV-03" + "7060(d)": [ + "PRI-06.8" ], - "164.308(a)(2)": [ - "GOV-04" + "7060(e)": [ + "PRI-06.8" ], - "164.306(b)(2)(i)": [ - "GOV-08", - "PRM-06" + "7060(f)": [ + "PRI-06.8" ], - "164.306(b)(1)": [ - "GOV-09", - "GOV-15", - "SEA-01", - "SEA-02", - "SEA-03" + "7060(g)": [ + "PRI-06.8" ], - "164.308(a)(1)(ii)(B)": [ - "GOV-09", - "GOV-15.2" + "7060(h)": [ + "PRI-06.8" ], - "164.306(d)(3)(ii)(A)": [ - "GOV-15.2" + "7061(a)": [ + "PRI-06.8" ], - "164.308(a)(7)(ii)(E)": [ - "AST-01", - "AST-01.1", - "BCD-02", - "TPM-02" + "7061(b)": [ + "PRI-06.8" ], - "164.310(d)(2)(iii)": [ - "AST-02", - "AST-02.1", - "AST-02.9", - "AST-03", - "AST-03.1" + "7062(a)": [ + "PRI-06.8" ], - "164.310(d)(2)(ii)": [ - "AST-09", - "DCH-09" + "7062(b)": [ + "PRI-06.8" ], - "164.308(a)(7)(ii)(C)": [ - "BCD-01", - "BCD-02.2" + "7062(c)": [ + "PRI-06.8" ], - "164.308(a)(7)(ii)(D)": [ - "BCD-04", - "BCD-05" + "7062(d)": [ + "PRI-06.8" ], - "164.310(a)(2)(i)": [ - "BCD-09.2", - "HRS-03", - "PES-02", - "PES-02.1" + "7062(f)": [ + "PRI-06.8" ], - "164.308(a)(7)(ii)(A)": [ - "BCD-11" + "7062(g)": [ + "PRI-06.8" ], - "164.310(d)(2)(iv)": [ - "BCD-11" + "7012(g)(2)": [ + "PRI-07.1", + "TPM-05" ], - "164.308(a)(7)(ii)(B)": [ - "BCD-12" + "7022(c)": [ + "PRI-07.1" ], - "164.306(c)": [ - "CPL-01" + "7022(c)(1)": [ + "PRI-07.1" ], - "164.306(d)(1)": [ - "CPL-01" + "7022(c)(2)": [ + "PRI-07.1" ], - "164.306(d)(2)": [ - "CPL-01" + "7022(c)(3)": [ + "PRI-07.1" ], - "164.314(a)(1)": [ - "CPL-01" + "7022(c)(4)": [ + "PRI-07.1" ], - "164.314(a)(2)(ii)": [ - "CPL-01" + "7024(i)": [ + "PRI-07.1" ], - "164.504(g)(1)": [ - "CPL-01" + "7050(a)": [ + "PRI-07.1" ], - "164.306(d)(3)(i)": [ - "CPL-02", - "CPL-03", - "CPL-03.2" + "7050(a)(1)": [ + "PRI-07.1" ], - "164.306(e)": [ - "CPL-03.2" + "7050(a)(2)": [ + "PRI-07.1" ], - "164.308(a)(8)": [ - "CPL-03.2", - "IAO-01.1", - "IAO-02" + "7050(a)(3)": [ + "PRI-07.1" ], - "164.312(a)(2)(iii)": [ - "CFG-02", - "IAC-25" + "7050(a)(4)": [ + "PRI-07.1" ], - "164.312(e)(1)": [ - "CFG-02", - "CRY-03", - "NET-01" + "7050(c)": [ + "PRI-07.1" ], - "164.312(e)(2)(i)": [ - "CFG-02", - "CRY-04", - "NET-01" + "7050(d)": [ + "PRI-07.1" ], - "164.312(e)(2)(ii)": [ - "CFG-02", - "CRY-01", - "OPS-03" + "7050(e)": [ + "PRI-07.1" ], - "164.312(c)(2)": [ - "CFG-08", - "CFG-08.1", - "MON-01.7", - "MON-01.15", - "MON-16" + "7050(f)": [ + "PRI-07.1" ], - "164.308(a)(1)(ii)(D)": [ - "MON-01", - "MON-01.8", - "IRO-09" + "7050(g)": [ + "PRI-07.1" ], - "164.312(b)": [ - "MON-01", - "MON-01.4", - "MON-01.8", - "MON-01.16", - "MON-03", - "MON-03.2", - "MON-16" + "7050(h)": [ + "PRI-07.1" ], - "164.312(a)(2)(iv)": [ - "CRY-01" + "7050(h)(1)": [ + "PRI-07.1" ], - "164.514(d)(3)(i)": [ - "DCH-01", - "DCH-01.2", - "DCH-03.1" + "7050(h)(2)": [ + "PRI-07.1" ], - "164.530(c)(2)(i)": [ - "DCH-01", - "DCH-01.2" + "7051(a)": [ + "PRI-07.1", + "TPM-05" ], - "164.510(b)(1)(i)": [ - "DCH-03.1" + "7051(a)(1)": [ + "PRI-07.1" ], - "164.510(b)(1)(ii)": [ - "DCH-03.1" + "7051(a)(2)": [ + "PRI-07.1" ], - "164.510(b)(2)": [ - "DCH-03.1" + "7051(a)(3)": [ + "PRI-07.1" ], - "164.510(b)(4)": [ - "DCH-03.1", - "PRI-05.4" + "7051(a)(4)": [ + "PRI-07.1" ], - "164.510(b)(5)": [ - "DCH-03.1" + "7051(a)(5)": [ + "PRI-07.1" ], - "164.512": [ - "DCH-03.1", - "PRI-05.4" + "7051(a)(6)": [ + "PRI-07.1" ], - "164.512(a)(1)": [ - "DCH-03.1" + "7051(a)(7)": [ + "PRI-07.1" ], - "164.512(c)(1)": [ - "DCH-03.1" + "7051(a)(8)": [ + "PRI-07.1" ], - "164.512(c)(1)(i)": [ - "DCH-03.1" + "7051(a)(9)": [ + "PRI-07.1" ], - "164.512(c)(1)(ii)": [ - "DCH-03.1" + "7053(a)(1)": [ + "PRI-07.1" ], - "164.512(c)(1)(iii)(A)": [ - "DCH-03.1" + "7053(a)(2)": [ + "PRI-07.1" ], - "164.512(c)(1)(iii)(B)": [ - "DCH-03.1" + "7053(a)(3)": [ + "PRI-07.1" ], - "164.512(c)(2)": [ - "DCH-03.1" + "7053(a)(4)": [ + "PRI-07.1" ], - "164.512(c)(2)(i)": [ - "DCH-03.1" + "7022(b)(2)": [ + "PRI-07.3" ], - "164.512(c)(2)(ii)": [ - "DCH-03.1" + "7022(b)(3)": [ + "PRI-07.3" ], - "164.512(d)(1)": [ - "DCH-03.1" + "7022(f)(4)": [ + "PRI-07.3" ], - "164.512(d)(1)(i)": [ - "DCH-03.1" + "7026(f)(2)": [ + "PRI-07.3" ], - "164.512(d)(1)(ii)": [ - "DCH-03.1" + "7027(g)(2)": [ + "PRI-07.3" ], - "164.512(d)(1)(iii)": [ - "DCH-03.1" + "7027(g)(3)": [ + "PRI-07.3" ], - "164.512(d)(1)(iv)": [ - "DCH-03.1" + "7022(a)": [ + "PRI-07.4" ], - "164.512(e)(1)": [ - "DCH-03.1" + "7024(a)": [ + "PRI-07.4" ], - "164.512(e)(1)(i)": [ - "DCH-03.1" + "7024(b)": [ + "PRI-07.4" ], - "164.512(e)(1)(ii)": [ - "DCH-03.1" + "7026(e)": [ + "PRI-07.4" ], - "164.512(e)(1)(ii)(A)": [ - "DCH-03.1" + "7023(g)": [ + "PRI-07.5" ], - "164.512(e)(1)(ii)(B)": [ - "DCH-03.1" + "7023(h)": [ + "PRI-07.5" ], - "164.512(e)(1)(iii)": [ - "DCH-03.1" + "7027(f)": [ + "PRI-07.5" ], - "164.512(e)(1)(iii)(A)": [ - "DCH-03.1" + "7023(b)(1)": [ + "PRI-12" ], - "164.512(e)(1)(iii)(B)": [ - "DCH-03.1" + "7023(b)(1)(A)": [ + "PRI-12" ], - "164.512(e)(1)(iii)(C)": [ - "DCH-03.1" + "7023(b)(1)(B)": [ + "PRI-12" ], - "164.512(e)(1)(iii)(C)(1)": [ - "DCH-03.1" + "7023(b)(1)(C)": [ + "PRI-12" ], - "164.512(e)(1)(iii)(C)(2)": [ - "DCH-03.1" + "7023(b)(2)": [ + "PRI-12" ], - "164.512(e)(1)(iv)": [ - "DCH-03.1" + "7004(a)(3)": [ + "PRI-17" ], - "164.512(e)(1)(iv)(A)": [ - "DCH-03.1" + "7222(b)": [ + "PRI-17" ], - "164.512(e)(1)(iv)(B)": [ - "DCH-03.1" + "7222(b)(1)": [ + "PRI-17" ], - "164.512(e)(1)(v)": [ - "DCH-03.1" + "7222(b)(2)": [ + "PRI-17" ], - "164.512(e)(1)(v)(A)": [ - "DCH-03.1" + "7222(b)(3)": [ + "PRI-17" ], - "164.512(e)(1)(v)(B)": [ - "DCH-03.1" + "7222(b)(3)(A)": [ + "PRI-17" ], - "164.512(e)(1)(vi)": [ - "DCH-03.1" + "7222(b)(4)": [ + "PRI-17" ], - "164.512(f)": [ - "DCH-03.1" + "7222(b)(4)(A)": [ + "PRI-17" ], - "164.512(f)(1)": [ - "DCH-03.1" + "7222(c)": [ + "PRI-17" ], - "164.512(f)(1)(i)": [ - "DCH-03.1" + "7222(c)(1)": [ + "PRI-17" ], - "164.512(f)(1)(ii)(A)": [ - "DCH-03.1" + "7222(c)(2)": [ + "PRI-17" ], - "164.512(f)(1)(ii)(B)": [ - "DCH-03.1" + "7222(c)(2)(A)": [ + "PRI-17" ], - "164.512(f)(1)(ii)(C)": [ - "DCH-03.1" + "7222(c)(2)(B)": [ + "PRI-17" ], - "164.512(f)(1)(ii)(C)(1)": [ - "DCH-03.1" + "7222(c)(2)(C)": [ + "PRI-17" ], - "164.512(f)(1)(ii)(C)(2)": [ - "DCH-03.1" + "7222(d)": [ + "PRI-17" ], - "164.512(f)(1)(ii)(C)(3)": [ - "DCH-03.1" + "7222(e)": [ + "PRI-17" ], - "164.512(f)(2)": [ - "DCH-03.1" + "7222(f)": [ + "PRI-17" ], - "164.512(f)(2)(i)(A)": [ - "DCH-03.1" + "7222(g)": [ + "PRI-17" ], - "164.512(f)(2)(i)(B)": [ - "DCH-03.1" + "7222(h)": [ + "PRI-17" ], - "164.512(f)(2)(i)(C)": [ - "DCH-03.1" + "7222(i)": [ + "PRI-17" ], - "164.512(f)(2)(i)(D)": [ - "DCH-03.1" + "7222(j)": [ + "PRI-17" ], - "164.512(f)(2)(i)(E)": [ - "DCH-03.1" + "7222(k)": [ + "PRI-17" ], - "164.512(f)(2)(i)(F)": [ - "DCH-03.1" + "7003(c)": [ + "PRI-17.1" ], - "164.512(f)(2)(i)(G)": [ - "DCH-03.1" + "7003(d)": [ + "PRI-17.1" ], - "164.512(f)(2)(i)(H)": [ - "DCH-03.1" + "7010(g)": [ + "PRI-17.2" ], - "164.512(f)(2)(ii)": [ - "DCH-03.1" + "7080(e)": [ + "PRI-17.2" ], - "164.512(f)(3)": [ - "DCH-03.1" + "7101(a)": [ + "PRI-17.3" ], - "164.512(f)(3)(i)": [ - "DCH-03.1" + "7101(b)": [ + "PRI-17.3" ], - "164.512(f)(3)(ii)": [ - "DCH-03.1" + "7101(c)": [ + "PRI-17.3" ], - "164.512(f)(3)(ii)(A)": [ - "DCH-03.1" + "7101(d)": [ + "PRI-17.3" ], - "164.512(f)(3)(ii)(B)": [ - "DCH-03.1" + "7101(e)": [ + "PRI-17.3" ], - "164.512(f)(3)(ii)(C)": [ - "DCH-03.1" + "7102(a)(1)": [ + "PRI-17.4" ], - "164.512(f)(4)": [ - "DCH-03.1" + "7102(a)(1)(A)": [ + "PRI-17.4" ], - "164.512(f)(5)": [ - "DCH-03.1" + "7102(a)(1)(B)": [ + "PRI-17.4" ], - "164.512(f)(6)(i)": [ - "DCH-03.1" + "7102(a)(1)(C)": [ + "PRI-17.4" ], - "164.512(f)(6)(i)(A)": [ - "DCH-03.1" + "7102(a)(1)(D)": [ + "PRI-17.4" ], - "164.512(f)(6)(i)(B)": [ - "DCH-03.1" + "7102(a)(1)(E)": [ + "PRI-17.4" ], - "164.512(f)(6)(i)(C)": [ - "DCH-03.1" + "7102(a)(1)(F)": [ + "PRI-17.4" ], - "164.512(f)(6)(ii)": [ - "DCH-03.1" + "7102(a)(1)(G)": [ + "PRI-17.4" ], - "164.512(g)(1)": [ - "DCH-03.1" + "7102(a)(1)(H)": [ + "PRI-17.4" ], - "164.512(g)(2)": [ - "DCH-03.1" + "7102(a)(2)": [ + "PRI-17.5" ], - "164.512(h)": [ - "DCH-03.1" + "7102(b)": [ + "PRI-17.5" ], - "164.512(i)(1)": [ - "DCH-03.1", - "PRI-05.4" + "7010(c)": [ + "PRI-19.1" ], - "164.512(j)(1)": [ - "DCH-03.1", - "PRI-05.4" + "7220(a)": [ + "PRI-19.1" ], - "164.514(d)(3)(ii)(A)": [ - "DCH-03.1" + "7220(b)": [ + "PRI-19.1" ], - "164.514(d)(3)(ii)(B)": [ - "DCH-03.1" + "7220(b)(1)": [ + "PRI-19.1" ], - "164.514(d)(3)(iii)": [ - "DCH-03.1" + "7220(b)(2)": [ + "PRI-19.1" ], - "164.514(d)(3)(iii)(A)": [ - "DCH-03.1" + "7220(b)(3)": [ + "PRI-19.1" ], - "164.514(d)(3)(iii)(B)": [ - "DCH-03.1" + "7220(c)": [ + "PRI-19.1" ], - "164.514(d)(3)(iii)(C)": [ - "DCH-03.1" + "7220(c)(1)": [ + "PRI-19.1" ], - "164.514(d)(3)(iii)(D)": [ - "DCH-03.1" + "7220(c)(2)": [ + "PRI-19.1" ], - "164.514(d)(4)": [ - "DCH-03.1" + "7220(c)(2)(A)": [ + "PRI-19.1" ], - "164.514(d)(4)(i)": [ - "DCH-03.1" + "7220(c)(2)(B)": [ + "PRI-19.1" ], - "164.514(d)(4)(ii)": [ - "DCH-03.1" + "7220(c)(3)": [ + "PRI-19.1" ], - "164.514(d)(4)(iii)(A)": [ - "DCH-03.1" + "7220(c)(4)": [ + "PRI-19.1" ], - "164.514(d)(4)(iii)(B)": [ - "DCH-03.1" + "7220(c)(5)": [ + "PRI-19.1" ], - "164.514(d)(5)": [ - "DCH-03.1" + "7220(c)(5)(A)": [ + "PRI-19.1" + ], + "7220(c)(5)(B)": [ + "PRI-19.1" ], - "164.514(e)(1)": [ - "DCH-03.1" + "7220(c)(5)(C)": [ + "PRI-19.1" ], - "164.514(e)(2)": [ - "DCH-03.1" + "7220(e)": [ + "PRI-19.1" ], - "164.514(e)(2)(i)": [ - "DCH-03.1" + "7220(e)(1)": [ + "PRI-19.1" ], - "164.514(e)(2)(ii)": [ - "DCH-03.1" + "7220(e)(2)": [ + "PRI-19.1" ], - "164.514(e)(2)(iii)": [ - "DCH-03.1" + "7220(e)(3)": [ + "PRI-19.1" ], - "164.514(e)(2)(iv)": [ - "DCH-03.1" + "7220(e)(4)": [ + "PRI-19.1" ], - "164.514(e)(2)(v)": [ - "DCH-03.1" + "7010(d)": [ + "PRI-19.2" ], - "164.514(e)(2)(vi)": [ - "DCH-03.1" + "7221(a)": [ + "PRI-19.2" ], - "164.514(e)(2)(vii)": [ - "DCH-03.1" + "7221(b)": [ + "PRI-19.2" ], - "164.514(e)(2)(viii)": [ - "DCH-03.1" + "7221(b)(1)": [ + "PRI-19.2" ], - "164.514(e)(2)(ix)": [ - "DCH-03.1" + "7221(b)(1)(A)": [ + "PRI-19.2" ], - "164.514(e)(2)(x)": [ - "DCH-03.1" + "7221(b)(1)(B)": [ + "PRI-19.2" ], - "164.514(e)(2)(xi)": [ - "DCH-03.1" + "7221(b)(2)": [ + "PRI-19.2" ], - "164.514(e)(2)(xii)": [ - "DCH-03.1" + "7221(b)(2)(A)": [ + "PRI-19.2" ], - "164.514(e)(2)(xiii)": [ - "DCH-03.1" + "7221(b)(2)(B)": [ + "PRI-19.2" ], - "164.514(e)(2)(xiv)": [ - "DCH-03.1" + "7221(b)(3)": [ + "PRI-19.2" ], - "164.514(e)(2)(xv)": [ - "DCH-03.1" + "7221(b)(3)(A)": [ + "PRI-19.2" ], - "164.514(e)(2)(xvi)": [ - "DCH-03.1" + "7221(b)(3)(B)": [ + "PRI-19.2" ], - "164.514(e)(3)(i)": [ - "DCH-03.1" + "7221(c)": [ + "PRI-19.2" ], - "164.514(e)(3)(ii)": [ - "DCH-03.1" + "7221(d)": [ + "PRI-19.2" ], - "164.514(e)(4)(i)": [ - "DCH-03.1" + "7221(e)": [ + "PRI-19.2" ], - "164.514(e)(4)(ii)": [ - "DCH-03.1" + "7221(f)": [ + "PRI-19.2" ], - "164.514(e)(4)(ii)(A)": [ - "DCH-03.1" + "7221(g)": [ + "PRI-19.2" ], - "164.514(e)(4)(ii)(B)": [ - "DCH-03.1" + "7221(h)": [ + "PRI-19.2" ], - "164.514(e)(4)(ii)(C)": [ - "DCH-03.1" + "7221(m)": [ + "PRI-19.2" ], - "164.514(e)(4)(ii)(C)(1)": [ - "DCH-03.1" + "7221(n)": [ + "PRI-19.2" ], - "164.514(e)(4)(ii)(C)(2)": [ - "DCH-03.1" + "7221(n)(1)": [ + "PRI-19.2" ], - "164.514(e)(4)(ii)(C)(3)": [ - "DCH-03.1" + "7221(n)(2)": [ + "PRI-19.2" ], - "164.514(e)(4)(ii)(C)(4)": [ - "DCH-03.1" + "7222(a)": [ + "PRI-19.3" ], - "164.514(e)(4)(ii)(C)(5)": [ - "DCH-03.1" + "7012(i)": [ + "PRI-20" ], - "164.532(a)": [ - "DCH-03.1", - "PRI-05.4" + "7013(a)": [ + "PRI-21" ], - "164.532(b)": [ - "DCH-03.1", - "PRI-05.4" + "7013(b)": [ + "PRI-21" ], - "164.532(c)": [ - "DCH-03.1", - "PRI-05.4" + "7013(d)": [ + "PRI-21" ], - "164.532(c)(1)": [ - "DCH-03.1" + "7013(f)": [ + "PRI-21" ], - "164.532(d)": [ - "DCH-03.1" + "7013(f)(1)": [ + "PRI-21" ], - "164.316(b)(2)(i)": [ - "DCH-18" + "7013(f)(2)": [ + "PRI-21" ], - "164.530(j)(2)": [ - "DCH-18" + "7026(a)": [ + "PRI-21", + "PRI-21.1" ], - "164.502(b)(1)": [ - "DCH-18.1" + "7026(b)": [ + "PRI-21.1" ], - "164.526(a)(1)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-12" + "7026(c)": [ + "PRI-21.1" ], - "164.526(b)(1)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-12" + "7026(d)": [ + "PRI-21.1" ], - "164.310(c)": [ - "END-02", - "PES-03", - "PES-03.4", - "PES-04", - "PES-04.1" + "7026(g)": [ + "PRI-21.1" ], - "164.308(a)(3)(ii)(A)": [ - "HRS-01", - "IAC-07.1", - "IAC-08", - "IAC-28.1" + "7026(h)": [ + "PRI-21.1" ], - "164.312(d)": [ - "HRS-01", - "HRS-04", - "IAC-28", - "IAC-28.2", - "IAC-28.3", - "TPM-01" + "7015(a)": [ + "PRI-21.2" ], - "164.530(e)(2)": [ - "HRS-01" + "7015(b)": [ + "PRI-21.2" ], - "164.308(a)(3)(ii)(B)": [ - "HRS-02", - "HRS-03", - "IAC-17" + "7015(b)(1)": [ + "PRI-21.2" ], - "164.530(a)(2)": [ - "HRS-02", - "HRS-03" + "7015(b)(2)": [ + "PRI-21.2" ], - "164.530(b)(1)": [ - "HRS-05.7", - "SAT-03" + "7015(b)(3)": [ + "PRI-21.2" ], - "164.502(a)": [ - "HRS-06.1", - "PRI-01" + "7015(c)": [ + "PRI-21.2" ], - "164.308(a)(1)(ii)(C)": [ - "HRS-07" + "7015(c)(1)": [ + "PRI-21.2" ], - "164.530(e)(1)": [ - "HRS-07" + "7015(c)(2)": [ + "PRI-21.2" ], - "164.308(a)(3)(ii)(C)": [ - "HRS-08", - "HRS-09", - "IAC-07", - "IAC-07.2" + "7100(b)": [ + "PRM-01.1", + "PRM-05" ], - "164.308(a)(4)(ii)(B)": [ - "IAC-01" + "7102(a)": [ + "PRM-01.1" ], - "164.310(a)(2)(iii)": [ - "IAC-01", - "PES-02", - "PES-03", - "PES-06" + "7152(a)": [ + "RSK-04", + "RSK-04.2", + "RSK-10" ], - "164.530(c)(2)(ii)": [ - "IAC-01", - "IAC-08" + "7155(a)": [ + "RSK-04", + "RSK-07", + "RSK-10" ], - "164.312(a)(2)(i)": [ - "IAC-02", - "IAC-09" + "7150(a)": [ + "RSK-04.3" ], - "164.308(a)(4)(ii)(C)": [ - "IAC-08" + "7150(b)": [ + "RSK-04.3" ], - "164.514(d)(2)(i)(A)": [ - "IAC-08" + "7150(b)(1)": [ + "RSK-04.3" ], - "164.514(d)(2)(i)(B)": [ - "IAC-08" + "7150(b)(2)": [ + "RSK-04.3" ], - "164.514(d)(2)(ii)": [ - "IAC-08" + "7150(b)(2)(A)": [ + "RSK-04.3" ], - "164.312(a)(2)(ii)": [ - "IAC-15", - "IAC-15.2", - "IAC-15.9" + "7150(b)(3)": [ + "RSK-04.3" ], - "164.308(a)(6)(ii)": [ - "IRO-02" + "7150(b)(4)": [ + "RSK-04.3" ], - "164.412": [ - "IRO-02" + "7150(b)(5)": [ + "RSK-04.3" ], - "164.412(a)": [ - "IRO-02" + "7150(b)(6)": [ + "RSK-04.3" ], - "164.412(b)": [ - "IRO-02" + "7155(a)(1)": [ + "RSK-04.3" ], - "164.530(f)": [ - "IRO-02" + "7155(a)(2)": [ + "RSK-04.3" ], - "164.404(a)(1)": [ - "IRO-04.1" + "7155(a)(3)": [ + "RSK-04.3" ], - "164.404(a)(2)": [ - "IRO-04.1" + "7155(b)": [ + "RSK-04.3" ], - "164.404(c)(1)(A)": [ - "IRO-04.1" + "7151(a)": [ + "RSK-04.4" ], - "164.404(c)(1)(B)": [ - "IRO-04.1" + "7151(b)": [ + "RSK-04.4" ], - "164.404(c)(1)(C)": [ - "IRO-04.1" + "7002(d)(3)": [ + "RSK-06.2" ], - "164.404(c)(1)(D)": [ - "IRO-04.1" + "7152(a)(1)": [ + "RSK-10" ], - "164.404(c)(1)(E)": [ - "IRO-04.1" + "7152(a)(2)": [ + "RSK-10" ], - "164.404(c)(2)": [ - "IRO-04.1" + "7152(a)(3)": [ + "RSK-10" ], - "164.404(d)(1)(i)": [ - "IRO-04.1" + "7152(a)(3)(A)": [ + "RSK-10" ], - "164.404(d)(1)(ii)": [ - "IRO-04.1" + "7152(a)(3)(B)": [ + "RSK-10" ], - "164.404(d)(2)": [ - "IRO-04.1" + "7152(a)(3)(C)": [ + "RSK-10" ], - "164.404(d)(2)(i)": [ - "IRO-04.1" + "7152(a)(3)(D)": [ + "RSK-10" ], - "164.404(d)(2)(ii)(A)": [ - "IRO-04.1" + "7152(a)(3)(E)": [ + "RSK-10" ], - "164.404(d)(2)(ii)(B)": [ - "IRO-04.1" + "7152(a)(3)(F)": [ + "RSK-10" ], - "164.404(d)(3)": [ - "IRO-04.1" + "7152(a)(3)(G)": [ + "RSK-10" ], - "164.406(a)": [ - "IRO-04.1" + "7152(a)(3)(G)(i)": [ + "RSK-10" ], - "164.406(b)": [ - "IRO-04.1" + "7152(a)(3)(G)(ii)": [ + "RSK-10" ], - "164.406(c)": [ - "IRO-04.1" + "7152(a)(4)": [ + "RSK-10" ], - "164.410(c)(1)": [ - "IRO-04.1" + "7152(a)(5)": [ + "RSK-10" ], - "164.404(b)": [ - "IRO-10" + "7152(a)(5)(A)": [ + "RSK-10" ], - "164.408(a)": [ - "IRO-10" + "7152(a)(5)(B)": [ + "RSK-10" ], - "164.408(b)": [ - "IRO-10" + "7152(a)(5)(C)": [ + "RSK-10" ], - "164.408(c)": [ - "IRO-10" + "7152(a)(5)(D)": [ + "RSK-10" ], - "164.410(a)(1)": [ - "IRO-10.2", - "TPM-05.1" + "7152(a)(5)(E)": [ + "RSK-10" ], - "164.308(b)(3)": [ - "IAO-03.2", - "TPM-05" + "7152(a)(5)(F)": [ + "RSK-10" ], - "164.530(a)(1)(i)": [ - "PRI-01", - "PRI-01.1" + "7152(a)(5)(G)": [ + "RSK-10" ], - "164.530(i)(4)(i)(A)": [ - "PRI-01" + "7152(a)(5)(H)": [ + "RSK-10" ], - "164.530(i)(4)(i)(B)": [ - "PRI-01" + "7152(a)(6)": [ + "RSK-10" ], - "164.530(i)(5)": [ - "PRI-01" + "7152(a)(6)(A)": [ + "RSK-10" ], - "164.530(i)(5)(i)": [ - "PRI-01" + "7152(a)(6)(A)(i)": [ + "RSK-10" ], - "164.530(i)(5)(ii)": [ - "PRI-01" + "7152(a)(6)(A)(ii)": [ + "RSK-10" ], - "164.530(a)(1)(ii)": [ - "PRI-01.4" + "7152(a)(6)(A)(iii)": [ + "RSK-10" ], - "164.520(a)(1)": [ - "PRI-02" + "7152(a)(6)(A)(iv)": [ + "RSK-10" ], - "164.520(a)(2)(i)": [ - "PRI-02" + "7152(a)(7)": [ + "RSK-10" ], - "164.520(a)(2)(i)(A)": [ - "PRI-02" + "7152(a)(8)": [ + "RSK-10" ], - "164.520(a)(2)(i)(B)": [ - "PRI-02" + "7152(a)(9)": [ + "RSK-10" ], - "164.520(a)(2)(ii)": [ - "PRI-02" + "7154(a)": [ + "RSK-10" ], - "164.520(a)(2)(ii)(A)": [ - "PRI-02" + "7156(a)": [ + "RSK-10" ], - "164.520(a)(2)(ii)(B)": [ - "PRI-02" + "7156(b)": [ + "RSK-10" ], - "164.520(a)(2)(iii)": [ - "PRI-02" + "7123(c)(12)": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6", + "SAT-04" ], - "164.520(b)(1)": [ - "PRI-02" + "7100(a)": [ + "SAT-02", + "SAT-03", + "SAT-03.3" ], - "164.520(b)(1)(i)": [ - "PRI-02" + "7123(c)(13)": [ + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.6", + "SAT-04" ], - "164.520(b)(1)(ii)": [ - "PRI-02" + "7123(c)(14)": [ + "TDA-01", + "TDA-01.1", + "TDA-01.3", + "TDA-01.4", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-02.6", + "TDA-02.7", + "TDA-02.8", + "TDA-02.9", + "TDA-02.10", + "TDA-02.11", + "TDA-02.13", + "TDA-05", + "TDA-06", + "TDA-06.1", + "TDA-06.2", + "TDA-06.3", + "TDA-06.4", + "TDA-06.5", + "TDA-06.6", + "TDA-07", + "TDA-08", + "TDA-08.1", + "TDA-09", + "TDA-09.6", + "TDA-10", + "TDA-14", + "TDA-15", + "TDA-20", + "TDA-20.4", + "TDA-21", + "TDA-22" ], - "164.520(b)(1)(ii)(A)": [ - "PRI-02" + "7123(c)(6)": [ + "TDA-02.11", + "TDA-02.13", + "TDA-09.5", + "THR-06", + "THR-06.1", + "VPM-01", + "VPM-06", + "VPM-07" ], - "164.520(b)(1)(ii)(B)": [ - "PRI-02" + "7052(a)": [ + "TPM-01", + "TPM-05.4" ], - "164.520(b)(1)(ii)(C)": [ - "PRI-02" + "7123(c)(15)": [ + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03", + "TPM-04", + "TPM-04.1", + "TPM-04.3", + "TPM-04.4", + "TPM-05", + "TPM-05.1", + "TPM-05.2", + "TPM-05.4", + "TPM-05.5", + "TPM-05.6", + "TPM-05.7", + "TPM-06", + "TPM-07", + "TPM-08", + "TPM-09", + "TPM-10" ], - "164.520(b)(1)(ii)(D)": [ - "PRI-02" + "7052(b)": [ + "TPM-05", + "TPM-05.2" ], - "164.520(b)(1)(ii)(E)": [ - "PRI-02" + "7053(a)": [ + "TPM-05", + "TPM-05.2" ], - "164.520(b)(1)(iv)": [ - "PRI-02" + "7053(a)(6)": [ + "TPM-05" ], - "164.520(b)(1)(iv)(A)": [ - "PRI-02" + "7051(b)": [ + "TPM-05.2" ], - "164.520(b)(1)(iv)(B)": [ - "PRI-02" + "7053(a)(5)": [ + "TPM-05.7", + "TPM-09" ], - "164.520(b)(1)(iv)(C)": [ - "PRI-02" + "7051(c)": [ + "TPM-08" ], - "164.520(b)(1)(iv)(D)": [ - "PRI-02" + "7053(b)": [ + "TPM-08" + ] + }, + "usa-state-ca-sb1386-2002": { + "1798.29(a)": [ + "IRO-01", + "IRO-02", + "IRO-10", + "IRO-10.2" ], - "164.520(b)(1)(iv)(E)": [ - "PRI-02" + "1798.29(c)": [ + "IRO-10" ], - "164.520(b)(1)(iv)(F)": [ - "PRI-02" + "1798.82(a)": [ + "IRO-10" ], - "164.520(b)(1)(v)": [ - "PRI-02" + "1798.82(b)": [ + "IRO-10" ], - "164.520(b)(1)(v)(A)": [ - "PRI-02" + "1798.82(c)": [ + "IRO-10" ], - "164.520(b)(1)(v)(B)": [ - "PRI-02" + "1798.29(b)": [ + "IRO-10.2" + ] + }, + "usa-state-co-privacy-act-2021": { + "6-1-1305(1)": [ + "CPL-01" ], - "164.520(b)(1)(v)(C)": [ - "PRI-02" + "6-1-1305(2)": [ + "CPL-01" ], - "164.520(b)(1)(vi)": [ - "PRI-02" + "6-1-1305(2)(b)": [ + "CPL-01" ], - "164.520(b)(1)(vii)": [ - "PRI-02" + "6-1-1305(2)(c)": [ + "CPL-01" ], - "164.520(b)(1)(viii)": [ - "PRI-02" + "6-1-1308(6)": [ + "CPL-01" ], - "164.520(b)(2)(i)": [ - "PRI-02" + "6-1-1305(3)(a)": [ + "HRS-06.1" ], - "164.520(b)(2)(ii)": [ - "PRI-02" + "6-1-1305(3)(b)": [ + "IAO-03.2" ], - "164.520(b)(3)": [ - "PRI-02" + "6-1-1305(2)(a)": [ + "PRI-01.6", + "PRI-01.11" ], - "164.520(c)": [ - "PRI-02" + "6-1-1305(4)": [ + "PRI-01.6", + "PRI-01.11" ], - "164.520(c)(1)(i)": [ - "PRI-02" + "6-1-1308(5)": [ + "PRI-01.6", + "PRI-01.11" ], - "164.520(c)(1)(i)(A)": [ - "PRI-02" + "6-1-1308(3)": [ + "PRI-01.11" ], - "164.520(c)(1)(i)(B)": [ - "PRI-02" + "6-1-1308(4)": [ + "PRI-01.11" ], - "164.520(c)(1)(ii)": [ - "PRI-02" + "6-1-1308(7)": [ + "PRI-01.11" ], - "164.520(c)(1)(iii)": [ + "6-1-1308(1)(a)": [ "PRI-02" ], - "164.520(c)(1)(iv)": [ + "6-1-1308(1)(a)(III)": [ "PRI-02" ], - "164.520(c)(1)(v)": [ + "6-1-1308(1)(a)(IV)": [ "PRI-02" ], - "164.520(c)(1)(v)(A)": [ + "6-1-1308(1)(a)(V)": [ "PRI-02" ], - "164.520(c)(1)(v)(B)": [ - "PRI-02" + "6-1-1308(1)(b)": [ + "PRI-02", + "PRI-03.3" ], - "164.530(i)(4)(i)(C)": [ + "6-1-1308(2)": [ "PRI-02" ], - "164.502(a)(3)": [ - "PRI-02.1" - ], - "164.508(c)(1)(i)": [ + "6-1-1308(1)(a)(II)": [ "PRI-02.1" ], - "164.508(c)(1)(ii)": [ - "PRI-02.1" + "6-1-1308(1)(c)(I)": [ + "PRI-03.5" ], - "164.508(c)(1)(iii)": [ - "PRI-02.1" + "6-1-1308(1)(c)(II)": [ + "PRI-03.5" ], - "164.508(c)(1)(iv)": [ - "PRI-02.1" + "6-1-1306(1)(a)(II)": [ + "PRI-03.6" ], - "164.508(c)(2)(i)(A)": [ - "PRI-02.1" + "6-1-1308(1)(a)(I)": [ + "PRI-05.7" ], - "164.508(c)(2)(i)(B)": [ - "PRI-02.1" + "6-1-1306(1)": [ + "PRI-06", + "PRI-06.4", + "PRI-06.8", + "PRI-17" ], - "164.506(b)(1)": [ - "PRI-03" + "6-1-1306(1)(b)": [ + "PRI-06" ], - "164.508(a)(2)": [ - "PRI-03" + "6-1-1306(2)(c)": [ + "PRI-06" ], - "164.508(c)(1)(v)": [ - "PRI-03" + "6-1-1306(1)(c)": [ + "PRI-06.1" ], - "164.508(c)(3)": [ - "PRI-03" + "6-1-1306(3)(a)": [ + "PRI-06.3" ], - "164.510(b)(2)(i)": [ - "PRI-03" + "6-1-1306(2)(a)": [ + "PRI-06.4" ], - "164.510(b)(2)(ii)": [ - "PRI-03" + "6-1-1306(2)(b)": [ + "PRI-06.4" ], - "164.510(b)(2)(iii)": [ - "PRI-03" + "6-1-1306(3)(b)": [ + "PRI-06.4" ], - "164.510(b)(3)": [ - "PRI-03" + "6-1-1306(3)(c)": [ + "PRI-06.4" ], - "164.514(f)(2)(ii)": [ - "PRI-03" + "6-1-1306(1)(d)": [ + "PRI-06.5" ], - "164.514(f)(2)(iv)": [ - "PRI-03" + "6-1-1306(1)(e)": [ + "PRI-06.6", + "PRI-06.7" ], - "164.514(f)(2)(v)": [ - "PRI-03" + "6-1-1306(2)(d)": [ + "PRI-06.8" ], - "164.502(a)(5)(ii)(A)": [ - "PRI-03.3" + "6-1-1306(1)(a)(I)": [ + "PRI-21" ], - "164.508(c)(2)(ii)(A)": [ - "PRI-03.5" + "6-1-1306(1)(a)(I)(A)": [ + "PRI-21" ], - "164.508(c)(2)(ii)(B)": [ - "PRI-03.5" + "6-1-1306(1)(a)(I)(B)": [ + "PRI-21" ], - "164.514(f)(2)(iii)": [ - "PRI-03.5" + "6-1-1306(1)(a)(I)(C)": [ + "PRI-21" ], - "164.502(g)(1)": [ - "PRI-03.6" + "6-1-1306(1)(a)(III)": [ + "PRI-21" ], - "164.502(g)(2)": [ - "PRI-03.6" + "6-1-1306(1)(a)(IV)(A)": [ + "PRI-21" ], - "164.502(g)(3)(i)": [ - "PRI-03.6" + "6-1-1306(1)(a)(IV)(B)": [ + "PRI-21" ], - "164.502(g)(3)(i)(A)": [ - "PRI-03.6" + "6-1-1306(1)(a)(IV)(C)": [ + "PRI-21" ], - "164.502(a)(1)(i)": [ - "PRI-04.1" + "6-1-1305(5)": [ + "TPM-05" ], - "164.502(a)(1)(ii)": [ - "PRI-04.1" + "6-1-1305(5)(a)": [ + "TPM-05" ], - "164.502(a)(1)(iii)": [ - "PRI-04.1" + "6-1-1305(5)(b)": [ + "TPM-05" ], - "164.502(a)(5)(i)": [ - "PRI-04.1" + "6-1-1305(5)(c)": [ + "TPM-05" ], - "164.502(i)": [ - "PRI-04.1" + "6-1-1305(5)(d)": [ + "TPM-05" ], - "164.508(a)(2)(i)(B)": [ - "PRI-05.1" + "6-1-1305(5)(d)(I)": [ + "TPM-05" ], - "164.502(c)": [ - "PRI-05.4" + "6-1-1305(5)(d)(II)(A)": [ + "TPM-05" ], - "164.502(d)(1)": [ - "PRI-05.4" + "6-1-1305(5)(d)(II)(B)": [ + "TPM-05", + "TPM-08" + ] + }, + "usa-state-il-bipa-2008": { + "15(e)(1)": [ + "PRI-01.6", + "PRI-01.11" ], - "164.504(g)(2)": [ - "PRI-05.4" + "15(e)(2)": [ + "PRI-01.6", + "PRI-01.11" ], - "164.506(a)": [ - "PRI-05.4" + "15(a)": [ + "PRI-02", + "PRI-05" ], - "164.506(c)(1)": [ - "PRI-05.4", - "PRI-07" + "15(b)(1)": [ + "PRI-02" ], - "164.506(c)(5)": [ - "PRI-05.4" + "15(b)(2)": [ + "PRI-02" ], - "164.508(a)(1)": [ - "PRI-05.4", - "PRI-07" + "15(b)(3)": [ + "PRI-03" ], - "164.508(a)(2)(i)(C)": [ - "PRI-05.4" + "15(d)": [ + "PRI-03" ], - "164.510(a)(1)(i)(A)": [ - "PRI-05.4" + "15(d)(1)": [ + "PRI-03" ], - "164.510(a)(1)(i)(B)": [ - "PRI-05.4" + "15(d)(2)": [ + "PRI-03" ], - "164.510(a)(1)(i)(C)": [ - "PRI-05.4" + "15(d)(3)": [ + "PRI-03" ], - "164.510(a)(1)(i)(D)": [ - "PRI-05.4" + "15(d)(4)": [ + "PRI-03" ], - "164.510(a)(1)(ii)(A)": [ - "PRI-05.4" + "15(c)": [ + "PRI-03.3" + ] + }, + "usa-state-il-ipa-2009": { + "15": [ + "CPL-01" ], - "164.510(a)(1)(ii)(B)": [ - "PRI-05.4" + "25": [ + "CPL-01" ], - "164.512(j)(1)(i)(A)": [ - "PRI-05.4" + "35(a)": [ + "GOV-02" ], - "164.512(j)(1)(i)(B)": [ - "PRI-05.4" + "37(a)": [ + "GOV-02" ], - "164.512(j)(1)(ii)": [ - "PRI-05.4" + "35(c)": [ + "GOV-15" ], - "164.512(j)(1)(ii)(A)": [ - "PRI-05.4" + "37(c)": [ + "GOV-15" ], - "164.512(j)(1)(ii)(B)": [ - "PRI-05.4" + "35(b)": [ + "GOV-17" ], - "164.512(j)(2)(i)": [ - "PRI-05.4" + "37(b)": [ + "GOV-17" ], - "164.512(j)(2)(ii)": [ - "PRI-05.4" + "35(a)(1)": [ + "CPL-01" ], - "164.512(j)(3)": [ - "PRI-05.4" + "37(a)(1)": [ + "CPL-01" ], - "164.512(j)(4)": [ - "PRI-05.4" + "35(a)(4)": [ + "DCH-03.2" ], - "164.512(k)(1)(i)": [ - "PRI-05.4" + "37(a)(4)": [ + "DCH-03.2" ], - "164.512(k)(1)(i)(A)": [ - "PRI-05.4" + "35(a)(3)": [ + "HRS-03" ], - "164.512(k)(1)(i)(B)": [ - "PRI-05.4" + "37(a)(3)": [ + "HRS-03" ], - "164.512(k)(1)(ii)": [ - "PRI-05.4" + "10(a)(1)": [ + "PRI-01.7" ], - "164.512(k)(1)(iii)": [ - "PRI-05.4" + "10(a)(2)": [ + "PRI-01.7" ], - "164.512(k)(1)(iv)": [ - "PRI-05.4" + "10(a)(4)": [ + "PRI-01.7" ], - "164.512(k)(2)": [ - "PRI-05.4" + "10(b)(1)": [ + "PRI-01.7", + "PRI-04", + "PRI-04.1" ], - "164.512(k)(3)": [ - "PRI-05.4" + "10(c)": [ + "PRI-01.7" ], - "164.512(k)(4)": [ - "PRI-05.4" + "10(c)(1)": [ + "PRI-01.7" ], - "164.512(k)(4)(i)": [ - "PRI-05.4" + "10(c)(2)": [ + "PRI-01.7" ], - "164.512(k)(4)(ii)": [ - "PRI-05.4" + "10(c)(5)": [ + "PRI-01.7" ], - "164.512(k)(4)(iii)": [ - "PRI-05.4" + "10(a)(3)": [ + "PRI-01.11" ], - "164.512(k)(5)(i)": [ - "PRI-05.4" + "10(b)(2)": [ + "PRI-01.11" ], - "164.512(k)(5)(i)(A)": [ - "PRI-05.4" + "10(b)(3)": [ + "PRI-01.11" ], - "164.512(k)(5)(i)(B)": [ - "PRI-05.4" + "10(c)(3)": [ + "PRI-01.11" ], - "164.512(k)(5)(i)(C)": [ - "PRI-05.4" + "10(c)(4)": [ + "PRI-01.11" ], - "164.512(k)(5)(i)(D)": [ - "PRI-05.4" + "10(c)(6)": [ + "PRI-01.11" ], - "164.512(k)(5)(i)(E)": [ - "PRI-05.4" + "10(d)": [ + "PRI-01.11" ], - "164.512(k)(5)(i)(F)": [ - "PRI-05.4" + "35(a)(5)": [ + "PRI-02" ], - "164.512(k)(5)(ii)": [ - "PRI-05.4" + "37(a)(5)": [ + "PRI-02" ], - "164.512(k)(5)(iii)": [ - "PRI-05.4" + "35(a)(2)": [ + "SAT-03.3" ], - "164.512(k)(6)(i)": [ - "PRI-05.4" + "37(a)(2)": [ + "SAT-03.3" + ] + }, + "usa-state-il-pipa-2006": { + "25": [ + "GOV-17" ], - "164.512(k)(6)(ii)": [ - "PRI-05.4" + "30": [ + "DCH-18" ], - "164.512(k)(6)(ii)(1)": [ - "PRI-05.4" + "12(f)": [ + "GOV-17" ], - "164.514(f)(2)(i)": [ - "PRI-05.4" + "40(b)(2)": [ + "DCH-08" ], - "164.514(g)": [ - "PRI-05.4" + "40(b)": [ + "DCH-21" ], - "164.530(i)(4)(ii)": [ - "PRI-05.4" + "40(b)(1)": [ + "DCH-21" ], - "164.530(i)(4)(ii)(B)": [ - "PRI-05.4" + "40(c)": [ + "DCH-21" ], - "164.502(a)(2)(i)": [ - "PRI-06" + "12(g)": [ + "IRO-01" ], - "164.502(a)(2)(ii)": [ - "PRI-06" + "12(g)(i)": [ + "IRO-01" ], - "164.514(h)(1)(i)": [ - "PRI-06" + "12(g)(ii)": [ + "IRO-01" ], - "164.514(h)(1)(ii)": [ - "PRI-06" + "12(g)(iii)": [ + "IRO-01" ], - "164.524(a)(1)": [ - "PRI-06" + "12(g)(iv)": [ + "IRO-01" ], - "164.524(a)(1)(i)": [ - "PRI-06" + "12(g)(v)": [ + "IRO-01" ], - "164.524(a)(1)(ii)": [ - "PRI-06" + "10(a)": [ + "IRO-10" ], - "164.524(a)(1)(iii)": [ - "PRI-06" + "10(a)(1)": [ + "IRO-10" ], - "164.524(a)(1)(iii)(A)": [ - "PRI-06" + "10(a)(1)(A)": [ + "IRO-10" ], - "164.524(a)(1)(iii)(B)": [ - "PRI-06" + "10(a)(1)(B)": [ + "IRO-10" ], - "164.524(a)(2)": [ - "PRI-06" + "10(a)(1)(C)": [ + "IRO-10" ], - "164.524(a)(2)(i)": [ - "PRI-06" + "10(a)(2)": [ + "IRO-10" ], - "164.524(a)(2)(ii)": [ - "PRI-06" + "10(b)": [ + "IRO-10" ], - "164.524(a)(2)(iii)": [ - "PRI-06" + "10(b-5)": [ + "IRO-10" ], - "164.524(a)(2)(iv)": [ - "PRI-06" + "10(c)": [ + "IRO-10" ], - "164.524(a)(2)(v)": [ - "PRI-06" + "10(c)(1)": [ + "IRO-10" ], - "164.524(a)(3)": [ - "PRI-06" + "10(c)(2)": [ + "IRO-10" ], - "164.524(a)(3)(i)": [ - "PRI-06" + "10(c)(3)": [ + "IRO-10" ], - "164.524(a)(3)(ii)": [ - "PRI-06" + "10(d)": [ + "IRO-10" ], - "164.524(a)(3)(iii)": [ - "PRI-06" + "10(e)(2)": [ + "IRO-10" ], - "164.524(a)(4)": [ - "PRI-06" + "10(e)(2)(A)": [ + "IRO-10" ], - "164.524(b)(1)": [ - "PRI-06" + "10(e)(2)(B)": [ + "IRO-10" ], - "164.524(b)(2)(i)": [ - "PRI-06" + "10(e)(2)(C)": [ + "IRO-10" ], - "164.524(b)(2)(i)(A)": [ - "PRI-06" + "12(a)": [ + "IRO-10" ], - "164.524(b)(2)(i)(B)": [ - "PRI-06" + "12(a)(1)": [ + "IRO-10" ], - "164.524(b)(2)(ii)": [ - "PRI-06" + "12(a)(1)(i)": [ + "IRO-10" ], - "164.524(b)(2)(ii)(A)": [ - "PRI-06" + "12(a)(1)(ii)": [ + "IRO-10" ], - "164.524(b)(2)(ii)(B)": [ - "PRI-06" + "12(a)(1)(iii)": [ + "IRO-10" ], - "164.524(c)": [ - "PRI-06" + "12(a)(2)": [ + "IRO-10" ], - "164.524(c)(1)": [ - "PRI-06" + "12(a-5)": [ + "IRO-10" ], - "164.524(c)(3)(i)": [ - "PRI-06" + "12(b)": [ + "IRO-10" ], - "164.524(c)(3)(ii)": [ - "PRI-06" + "12(b)(1)": [ + "IRO-10" ], - "164.524(c)(4)": [ - "PRI-06" + "12(b)(2)": [ + "IRO-10" ], - "164.524(c)(4)(i)": [ - "PRI-06" + "12(b)(3)": [ + "IRO-10" ], - "164.524(c)(4)(ii)": [ - "PRI-06" + "12(b)(3)(i)": [ + "IRO-10" ], - "164.524(c)(4)(iii)": [ - "PRI-06" + "12(b)(3)(ii)": [ + "IRO-10" ], - "164.524(c)(4)(iv)": [ - "PRI-06" + "12(b)(3)(iii)": [ + "IRO-10" ], - "164.524(d)": [ - "PRI-06" + "12(c)": [ + "IRO-10" ], - "164.524(d)(1)": [ - "PRI-06" + "12(d)": [ + "IRO-10" ], - "164.524(d)(2)": [ - "PRI-06" + "12(e)": [ + "IRO-10" ], - "164.526(a)(2)": [ - "PRI-06.1" + "12(e)(A)": [ + "IRO-10" ], - "164.526(a)(2)(i)": [ - "PRI-06.1" + "12(e)(B)": [ + "IRO-10" ], - "164.526(a)(2)(ii)": [ - "PRI-06.1" + "12(e)(C)": [ + "IRO-10" ], - "164.526(a)(2)(iii)": [ - "PRI-06.1" + "12(e)(D)": [ + "IRO-10" ], - "164.526(a)(2)(iv)": [ - "PRI-06.1" + "45(b)": [ + "IAO-03.2", + "PRI-07.1" ], - "164.526(c)": [ - "PRI-06.2" + "45(a)": [ + "PRI-01.6", + "PRI-01.11" + ] + }, + "usa-state-ma-201-cmr-17-2008": { + "17.03(1)": [ + "GOV-01", + "GOV-02" ], - "164.526(c)(1)": [ - "PRI-06.2" + "17.03(1)(a)": [ + "GOV-01" ], - "164.526(c)(2)": [ - "PRI-06.2" + "17.03(1)(b)": [ + "GOV-01" ], - "164.526(c)(3)": [ - "PRI-06.2" + "17.03(1)(c)": [ + "GOV-01" ], - "164.526(c)(3)(i)": [ - "PRI-06.2" + "17.03(1)(d)": [ + "GOV-01" ], - "164.526(c)(3)(ii)": [ - "PRI-06.2" + "17.03(2)": [ + "GOV-01" ], - "164.524(d)(4)": [ - "PRI-06.3" + "17.03(2)(c)": [ + "GOV-02" ], - "164.526(b)(2)(i)": [ - "PRI-06.4" + "17.04": [ + "GOV-02" ], - "164.526(b)(2)(i)(A)": [ - "PRI-06.4" + "17.03(2)(a)": [ + "GOV-04" ], - "164.526(b)(2)(i)(B)": [ - "PRI-06.4" + "17.03(2)(b)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "RSK-01.1", + "RSK-02", + "RSK-02.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-04.1", + "RSK-05", + "RSK-06", + "THR-03", + "THR-09", + "THR-10" ], - "164.526(b)(2)(ii)": [ - "PRI-06.4" + "17.03(2)(b)3": [ + "CPL-02", + "MON-01.8" ], - "164.526(b)(2)(ii)(A)": [ - "PRI-06.4" + "17.03(2)(h)": [ + "CPL-02" ], - "164.526(b)(2)(ii)(B)": [ - "PRI-06.4" + "17.03(2)(i)": [ + "CPL-02" ], - "164.526(d)": [ - "PRI-06.4" + "17.04(4)": [ + "MON-01.8" ], - "164.526(d)(1)": [ - "PRI-06.4" + "17.04(3)": [ + "CRY-01", + "CRY-03" ], - "164.526(d)(1)(i)": [ - "PRI-06.4" + "17.04(5)": [ + "CRY-01", + "CRY-05" ], - "164.526(d)(1)(ii)": [ - "PRI-06.4" + "17.03(2)(g)": [ + "DCH-01.2", + "PES-03" ], - "164.526(d)(1)(iii)": [ - "PRI-06.4" + "17.04(6)": [ + "END-02" ], - "164.526(d)(1)(iv)": [ - "PRI-06.4" + "17.03(2)(b)2": [ + "HRS-01", + "HRS-01.1", + "HRS-03", + "HRS-03.1" ], - "164.526(d)(2)": [ - "PRI-06.4" + "17.03(2)(e)": [ + "HRS-01.1", + "HRS-09" ], - "164.526(d)(3)": [ - "PRI-06.4" + "17.03(2)(d)": [ + "HRS-07" ], - "164.526(d)(4)": [ - "PRI-06.4" + "17.04(1)": [ + "IAC-01", + "IAC-01.2" ], - "164.526(d)(5)(i)": [ - "PRI-06.4" + "17.04(2)": [ + "IAC-01" ], - "164.526(d)(5)(ii)": [ - "PRI-06.4" + "17.04(2)(a)": [ + "IAC-08", + "IAC-21" ], - "164.526(d)(5)(iii)": [ - "PRI-06.4" + "17.04(1)(b)": [ + "IAC-10" ], - "164.526(e)": [ - "PRI-06.4", - "PRI-12" + "17.04(2)(b)": [ + "IAC-10", + "IAC-10.8", + "IAC-15" ], - "164.526(f)": [ - "PRI-06.4", - "PRI-12" + "17.04(1)(c)": [ + "IAC-10.5" ], - "164.530(d)(1)": [ - "PRI-06.4" + "17.04(1)(a)": [ + "IAC-15" ], - "164.530(d)(2)": [ - "PRI-06.4" + "17.04(1)(d)": [ + "IAC-15" ], - "164.524(c)(2)(i)": [ - "PRI-06.6" + "17.04(1)(e)": [ + "IAC-22" ], - "164.524(c)(2)(ii)": [ - "PRI-06.6" + "17.03(2)(j)": [ + "IRO-09.3", + "IRO-13" ], - "164.506(c)(2)": [ - "PRI-07" + "17.03(2)(b)1": [ + "SAT-02" ], - "164.506(c)(3)": [ - "PRI-07" + "17.04(8)": [ + "SAT-02", + "SAT-03.3" ], - "164.506(c)(4)": [ - "PRI-07" + "17.03(2)(f)": [ + "TPM-01" ], - "164.508(a)(4)(i)": [ - "PRI-07" + "17.03(2)(f)1": [ + "TPM-04.1" ], - "164.504(e)(2)(i)": [ - "PRI-07.1", + "17.03(2)(f)2": [ "TPM-05" ], - "164.504(e)(2)(ii)(A)": [ - "PRI-07.1" + "17.04(7)": [ + "VPM-04.1", + "VPM-05" + ] + }, + "usa-state-nv-privacy-law-2023": { + "603A.525.2": [ + "GOV-02" ], - "164.504(e)(2)(ii)(B)": [ - "PRI-07.1" + "603A.525.2(a)": [ + "GOV-02" ], - "164.504(e)(2)(ii)(C)": [ - "PRI-07.1" + "603A.210.2": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "164.504(e)(4)(i)": [ - "PRI-07.1" + "603A.215.1": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "164.504(e)(4)(i)(A)": [ - "PRI-07.1" + "603A.500.2(c)": [ + "CPL-01" ], - "164.504(e)(4)(i)(B)": [ - "PRI-07.1" + "603A.525.2(b)": [ + "CPL-01" ], - "164.504(e)(4)(i)(B)(ii)": [ - "PRI-07.1" + "603A.215.2(a)": [ + "CRY-03" ], - "164.504(e)(4)(i)(B)(ii)(A)": [ - "PRI-07.1" + "603A.200.1": [ + "DCH-01", + "DCH-08", + "DCH-18", + "DCH-21" ], - "164.524(d)(2)(i)": [ - "PRI-07.4" + "603A.215.2(b)": [ + "DCH-01.1", + "DCH-01.2" ], - "164.524(d)(2)(ii)": [ - "PRI-07.4" + "603A.495.3(b)": [ + "DCH-03.1" ], - "164.524(d)(2)(iii)": [ - "PRI-07.4" + "603A.500.2": [ + "DCH-03.1" ], - "164.524(d)(3)": [ - "PRI-07.4" + "603A.220.1": [ + "IRO-10" ], - "164.512(i)(1)(i)(B)": [ - "PRI-10" + "603A.220.2": [ + "IRO-10" ], - "164.512(i)(1)(i)(B)(1)": [ - "PRI-10" + "603A.220.3": [ + "IRO-10" ], - "164.512(i)(1)(i)(B)(2)": [ - "PRI-10" + "603A.220.4": [ + "IRO-10" ], - "164.512(i)(1)(i)(B)(3)": [ - "PRI-10" + "603A.220.4(a)": [ + "IRO-10" ], - "164.528(a)(1)": [ - "PRI-14.1" + "603A.220.4(b)": [ + "IRO-10" ], - "164.528(a)(1)(i)": [ - "PRI-14.1" + "603A.220.4(c)": [ + "IRO-10" ], - "164.528(a)(1)(ii)": [ - "PRI-14.1" + "603A.220.4(c)(1)": [ + "IRO-10" ], - "164.528(a)(1)(iii)": [ - "PRI-14.1" + "603A.220.4(c)(2)": [ + "IRO-10" ], - "164.528(a)(1)(iv)": [ - "PRI-14.1" + "603A.220.4(c)(3)": [ + "IRO-10" ], - "164.528(a)(1)(v)": [ - "PRI-14.1" + "603A.220.6": [ + "IRO-10" ], - "164.528(a)(1)(vi)": [ - "PRI-14.1" + "603A.210.1": [ + "PRI-01.6", + "PRI-01.11" ], - "164.528(a)(1)(vii)": [ - "PRI-14.1" + "603A.510.3(b)": [ + "PRI-01.11" ], - "164.528(a)(1)(viii)": [ - "PRI-14.1" + "603A.525.1": [ + "PRI-01.11" ], - "164.528(a)(1)(ix)": [ - "PRI-14.1" + "603A.525.1(a)": [ + "PRI-01.11" ], - "164.528(b)": [ - "PRI-14.1" + "603A.525.1(b)": [ + "PRI-01.11" ], - "164.528(b)(1)": [ - "PRI-14.1" + "603A.525.2(c)": [ + "PRI-01.11" ], - "164.528(b)(2)": [ - "PRI-14.1" + "603A.340.1": [ + "PRI-02" ], - "164.528(b)(2)(i)": [ - "PRI-14.1" + "603A.340.1(b)": [ + "PRI-02" ], - "164.528(b)(2)(ii)": [ - "PRI-14.1" + "603A.340.1(c)": [ + "PRI-02" ], - "164.528(b)(2)(iii)": [ - "PRI-14.1" + "603A.340.1(d)": [ + "PRI-02" ], - "164.528(b)(2)(iv)": [ - "PRI-14.1" + "603A.340.1(e)": [ + "PRI-02" ], - "164.528(b)(3)": [ - "PRI-14.1" + "603A.345.1": [ + "PRI-02" ], - "164.528(b)(3)(i)": [ - "PRI-14.1" + "603A.346.1": [ + "PRI-02" ], - "164.528(b)(3)(ii)": [ - "PRI-14.1" + "603A.495.1": [ + "PRI-02" ], - "164.528(b)(3)(iii)": [ - "PRI-14.1" + "603A.495.1(a)": [ + "PRI-02" ], - "164.528(b)(4)(i)": [ - "PRI-14.1" + "603A.495.1(b)": [ + "PRI-02" ], - "164.528(b)(4)(i)(A)": [ - "PRI-14.1" + "603A.495.1(c)": [ + "PRI-02" ], - "164.528(b)(4)(i)(B)": [ - "PRI-14.1" + "603A.495.1(d)": [ + "PRI-02" ], - "164.528(b)(4)(i)(C)": [ - "PRI-14.1" + "603A.495.1(e)": [ + "PRI-02" ], - "164.528(b)(4)(i)(D)": [ - "PRI-14.1" + "603A.495.1(f)": [ + "PRI-02" ], - "164.528(b)(4)(i)(E)": [ - "PRI-14.1" + "603A.495.1(g)": [ + "PRI-02" ], - "164.528(b)(4)(i)(F)": [ - "PRI-14.1" + "603A.495.1(h)": [ + "PRI-02" ], - "164.528(b)(4)(ii)": [ - "PRI-14.1" + "603A.495.1(i)": [ + "PRI-02" ], - "164.528(c)(1)": [ - "PRI-14.1" + "603A.495.1(j)": [ + "PRI-02" ], - "164.528(c)(1)(i)": [ - "PRI-14.1" + "603A.495.1(k)": [ + "PRI-02" ], - "164.528(c)(1)(ii)": [ - "PRI-14.1" + "603A.495.2": [ + "PRI-02" ], - "164.528(c)(1)(ii)(A)": [ - "PRI-14.1" + "603A.500.2(a)": [ + "PRI-03" ], - "164.528(c)(1)(ii)(B)": [ - "PRI-14.1" + "603A.500.2(b)": [ + "PRI-03" ], - "164.528(c)(2)": [ - "PRI-14.1" + "603A.500.3": [ + "PRI-03" ], - "164.528(d)": [ - "PRI-14.1" + "603A.500.3(a)": [ + "PRI-03" ], - "164.528(d)(1)": [ - "PRI-14.1" + "603A.500.3(b)": [ + "PRI-03" ], - "164.528(d)(2)": [ - "PRI-14.1" + "603A.500.3(c)": [ + "PRI-03" ], - "164.528(d)(3)": [ - "PRI-14.1" + "603A.500.3(d)": [ + "PRI-03", + "PRI-03.4" ], - "164.306(b)(2)(iii)": [ - "PRM-03" + "603A.535.5": [ + "PRI-03" ], - "164.306(b)(2)(ii)": [ - "PRM-05", - "SEA-02" + "603A.535.6": [ + "PRI-03" ], - "164.306(b)(2)(iv)": [ - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-03", - "RSK-03.1", - "RSK-04", - "THR-09", - "THR-10" + "603A.535.6(a)": [ + "PRI-03" ], - "164.308(a)(1)(ii)(A)": [ - "RSK-04" + "603A.535.6(b)": [ + "PRI-03" ], - "164.306(d)(3)(ii)(B)(2)": [ - "RSK-06.2" + "603A.535.6(c)": [ + "PRI-03" ], - "164.103": [ - "SEA-02.1" + "603A.535.6(d)": [ + "PRI-03" ], - "164.304": [ - "SEA-02.1" + "603A.535.7": [ + "PRI-03" ], - "164.402": [ - "SEA-02.1" + "603A.505.1(c)": [ + "PRI-03.4" ], - "164.501": [ - "SEA-02.1" + "603A.535.4": [ + "PRI-03.4" ], - "164.504(a)": [ - "SEA-02.1" + "603A.535.2": [ + "PRI-03.5" ], - "164.316(b)(2)(ii)": [ - "OPS-01.1", - "OPS-03" + "603A.495.3(a)": [ + "PRI-04" ], - "164.308(a)(5)(i)": [ - "SAT-01", - "SAT-02" + "603A.495.3(c)": [ + "PRI-04" ], - "164.530(b)(2)(i)": [ - "SAT-02" + "603A.500.1(a)": [ + "PRI-04" ], - "164.530(b)(2)(i)(A)": [ - "SAT-02" + "603A.500.1(b)": [ + "PRI-04" ], - "164.530(b)(2)(i)(B)": [ - "SAT-02" + "603A.535.1": [ + "PRI-04" ], - "164.530(b)(2)(i)(C)": [ - "SAT-02" + "603A.535.1(a)": [ + "PRI-04" ], - "164.530(b)(2)(ii)": [ - "SAT-02" + "603A.535.1(b)": [ + "PRI-04" ], - "164.308(a)(5)(ii)(C)": [ - "SAT-03" + "603A.340.1(a)": [ + "PRI-05.7" ], - "164.308(a)(5)(ii)(D)": [ - "SAT-03" + "603A.345.2": [ + "PRI-06" ], - "164.308(a)(5)(ii)(B)": [ - "SAT-03.2" + "603A.346.2": [ + "PRI-06" ], - "164.308(a)(5)(ii)(A)": [ - "SAT-03.6" + "603A.505.1(a)": [ + "PRI-06" ], - "164.308(b)(1)": [ - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "603A.505.1(b)": [ + "PRI-06" ], - "164.308(b)(2)": [ - "TPM-05", - "TPM-05.2", - "TPM-05.6" + "603A.505.2": [ + "PRI-06" ], - "164.314(a)(2)(iii)": [ - "TPM-05", - "TPM-05.2" + "603A.505.2(a)": [ + "PRI-06" ], - "164.314(b)(1)": [ - "TPM-05" + "603A.510.3(a)(1)": [ + "PRI-06" ], - "164.314(b)(2)(i)": [ - "TPM-05" + "603A.510.3(a)(2)": [ + "PRI-06" ], - "164.314(b)(2)(ii)": [ - "TPM-05" + "603A.520.1": [ + "PRI-06.3" ], - "164.314(b)(2)(iii)": [ - "TPM-05" + "603A.520.1(a)": [ + "PRI-06.3" ], - "164.502(a)(4)(i)": [ - "TPM-05" + "603A.520.1(b)": [ + "PRI-06.3" ], - "164.502(a)(4)(ii)": [ - "TPM-05" + "603A.520.2": [ + "PRI-06.3" ], - "164.502(e)(1)(i)": [ - "TPM-05", - "TPM-05.6" + "603A.520.2(a)": [ + "PRI-06.3" ], - "164.502(e)(2)": [ - "TPM-05" + "603A.520.2(b)": [ + "PRI-06.3" ], - "164.504(e)(2)(i)(A)": [ - "TPM-05" + "603A.520.2(c)": [ + "PRI-06.3" ], - "164.504(e)(2)(i)(B)": [ - "TPM-05" + "603A.345.3": [ + "PRI-06.4" ], - "164.504(e)(2)(ii)(J)": [ - "TPM-05" + "603A.345.4": [ + "PRI-06.4" ], - "164.504(e)(4)(i)(B)(ii)(B)(1)": [ - "TPM-05" + "603A.346.3": [ + "PRI-06.4" ], - "164.504(e)(4)(i)(B)(ii)(B)(2)": [ - "TPM-05" + "603A.346.4": [ + "PRI-06.4" ], - "164.504(f)(1)(i)": [ - "TPM-05" + "603A.510.1": [ + "PRI-06.4" ], - "164.504(f)(2)(i)": [ - "TPM-05" + "603A.510.2": [ + "PRI-06.4" ], - "164.504(f)(2)(ii)": [ - "TPM-05" + "603A.510.2(a)": [ + "PRI-06.4" ], - "164.504(f)(2)(ii)(A)": [ - "TPM-05" + "603A.510.2(b)": [ + "PRI-06.4" ], - "164.504(f)(2)(ii)(B)": [ - "TPM-05" + "603A.505.1(d)": [ + "PRI-06.5" ], - "164.504(f)(2)(ii)(C)": [ - "TPM-05" + "603A.515.1": [ + "PRI-06.5" ], - "164.504(f)(2)(ii)(D)": [ - "TPM-05" + "603A.515.1(a)": [ + "PRI-06.5" ], - "164.504(f)(2)(ii)(E)": [ - "TPM-05" + "603A.515.1(b)": [ + "PRI-06.5" ], - "164.504(f)(2)(ii)(F)": [ - "TPM-05" + "603A.515.2": [ + "PRI-06.5" ], - "164.504(f)(2)(ii)(G)": [ - "TPM-05" + "603A.515.3": [ + "PRI-06.5" ], - "164.504(f)(2)(ii)(H)": [ - "TPM-05" + "603A.505.2(b)": [ + "PRI-06.8" ], - "164.504(f)(2)(ii)(I)": [ - "TPM-05" + "603A.210.3": [ + "PRI-07.1" ], - "164.504(f)(2)(ii)(J)": [ - "TPM-05" + "603A.495.3(d)": [ + "PRI-07.1" ], - "164.504(f)(2)(iii)(A)": [ - "TPM-05" + "603A.530.1": [ + "PRI-07.1" ], - "164.504(f)(2)(iii)(B)": [ - "TPM-05" + "603A.530.2": [ + "PRI-07.1" ], - "164.504(f)(2)(iii)(C)": [ - "TPM-05" + "603A.530.3": [ + "PRI-07.1" ], - "164.504(f)(3)(i)": [ - "TPM-05" + "603A.530.3(a)": [ + "PRI-07.1" ], - "164.504(f)(3)(ii)": [ - "TPM-05" + "603A.530.3(b)": [ + "PRI-07.1" ], - "164.504(f)(3)(iii)": [ - "TPM-05" + "603A.535.3": [ + "PRI-14" ], - "164.504(f)(3)(iv)": [ - "TPM-05" + "603A.535.3(a)": [ + "PRI-14" ], - "164.314(a)(2)(i)(C)": [ - "TPM-05.1" + "603A.535.3(b)": [ + "PRI-14" ], - "164.314(b)(2)(iv)": [ - "TPM-05.1" + "603A.535.3(c)": [ + "PRI-14" ], - "164.410(a)(2)": [ - "TPM-05.1" + "603A.535.3(d)": [ + "PRI-14" ], - "164.410(b)": [ - "TPM-05.1" + "603A.535.3(e)": [ + "PRI-14" ], - "164.410(c)(2)": [ - "TPM-05.1" + "603A.535.3(f)": [ + "PRI-14" ], - "164.314(a)(2)(i)(B)": [ - "TPM-05.2" + "603A.535.3(g)": [ + "PRI-14" ], - "164.502(e)(1)(ii)": [ - "TPM-05.2", - "TPM-05.6" + "603A.535.3(h)": [ + "PRI-14" ], - "164.504(e)(2)(ii)(D)": [ - "TPM-05.2" + "603A.535.3(i)": [ + "PRI-14" ], - "164.504(e)(2)(iii)": [ - "TPM-05.7" + "603A.535.8": [ + "PRI-14" ] }, - "usa-federal-law-hipaa-security-rule-2013": { - "164.306(a)(1)": [ + "usa-state-nv-regulation-5-2024": { + "5.260.1": [ "GOV-01", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5" - ], - "164.306(a)(2)": [ - "GOV-01" + "PRI-01", + "PRI-01.6" ], - "164.306(a)(3)": [ - "GOV-01", - "DCH-01", - "RSK-01" + "5.260.4(b)": [ + "GOV-01.2", + "IRO-13" ], - "164.316(a)": [ - "GOV-01", - "GOV-02" + "5.260.4(c)": [ + "GOV-01.2", + "IRO-10" ], - "164.308(a)(1)(i)": [ + "5.260.6": [ "GOV-02", - "CHG-01", - "CFG-01", - "MON-01", - "IRO-01" + "OPS-01.1" ], - "164.308(a)(3)(i)": [ - "GOV-02", - "CFG-08", - "IAC-01", - "IAC-08", - "IAC-21" + "5.260.5(a)": [ + "GOV-04" ], - "164.308(a)(4)(i)": [ - "GOV-02", - "IAC-01" + "5.260.4": [ + "GOV-16" ], - "164.308(a)(4)(ii)(A)": [ - "GOV-02" + "5.260.5(b)": [ + "CPL-02.1", + "CPL-02.2", + "DCH-18" ], - "164.308(a)(6)(i)": [ - "GOV-02", - "IRO-01" + "5.260.5(c)": [ + "CPL-03", + "DCH-18", + "TPM-05.8" ], - "164.308(a)(7)(i)": [ - "GOV-02", - "BCD-01", - "IRO-01" + "5.260.3": [ + "CPL-03.1", + "RSK-04", + "RSK-04.1", + "RSK-07" ], - "164.310(a)(1)": [ - "GOV-02", - "PES-01" + "5.260.4(a)": [ + "IRO-10" ], - "164.310(a)(2)(ii)": [ - "GOV-02", - "PES-01", - "PES-03" + "5.260.2": [ + "SEA-02.1" + ] + }, + "usa-state-nv-sb220-2019": { + "2.3": [ + "PRI-05.4" ], - "164.310(a)(2)(iv)": [ - "GOV-02", - "MNT-01", - "MNT-02", - "PES-01" + "2.1": [ + "PRI-06" ], - "164.310(b)": [ - "GOV-02", - "END-01", - "HRS-05", - "HRS-05.1", - "HRS-05.3", - "PES-03.4", - "PES-04", - "OPS-01.1", - "OPS-03" + "2.2": [ + "PRI-06" ], - "164.310(d)(1)": [ - "GOV-02", - "AST-01", - "AST-11", - "DCH-01", - "DCH-03", - "DCH-07", - "DCH-07.1", - "DCH-13.2", - "MNT-01", - "MNT-04.3" + "2.4": [ + "PRI-06.4" + ] + }, + "usa-state-ny-dfs-23-nycrr500-2023-amd2": { + "500.2(a)": [ + "GOV-01" ], - "164.310(d)(2)(i)": [ - "GOV-02", - "AST-01", - "AST-09" + "500.2(b)": [ + "GOV-01" ], - "164.312(a)(1)": [ - "GOV-02", - "HRS-02", - "HRS-03", - "IAC-01", - "IAC-08", - "IAC-21" + "500.2(b)(1)": [ + "GOV-01", + "RSK-01", + "RSK-03", + "RSK-04" ], - "164.312(c)(1)": [ + "500.2(b)(2)": [ + "GOV-01", "GOV-02", - "DCH-01", - "DCH-01.2" - ], - "164.316(b)(1)(i)": [ - "GOV-02" - ], - "164.306(d)(3)(ii)(B)(1)": [ - "GOV-02.1" + "SEA-01", + "SEA-02", + "SEA-03", + "OPS-01.1" ], - "164.316(b)(1)(ii)": [ - "GOV-03", - "CPL-03" + "500.2(b)(3)": [ + "GOV-01", + "MON-01" ], - "164.316(b)(2)(iii)": [ - "GOV-03", - "CPL-02" + "500.2(b)(4)": [ + "GOV-01", + "IRO-01" ], - "164.308(a)(2)": [ - "GOV-04" + "500.2(b)(5)": [ + "GOV-01", + "BCD-01" ], - "164.306(b)(2)(i)": [ - "GOV-08", - "PRM-06" + "500.2(b)(6)": [ + "GOV-01", + "CPL-01" ], - "164.306(b)(1)": [ - "GOV-09", - "GOV-15", - "SEA-01", - "SEA-02", - "SEA-03" + "500.2(d)": [ + "GOV-01", + "CPL-01", + "SEA-02.2", + "TPM-05", + "TPM-05.4" ], - "164.308(a)(1)(ii)(B)": [ - "GOV-09", - "GOV-15.2" + "500.2(e)": [ + "GOV-01", + "CPL-01", + "CPL-05", + "CPL-05.2" ], - "164.306(d)(3)(ii)(A)": [ - "GOV-15.2" + "500.3(a)": [ + "GOV-01", + "GOV-02" ], - "164.308(a)(7)(ii)(E)": [ - "AST-01", - "AST-01.1", - "BCD-02", - "TPM-02" + "500.4(b)": [ + "GOV-01.1", + "GOV-01.2", + "GOV-04.1", + "GOV-04.2", + "GOV-16", + "GOV-16.1", + "GOV-16.2" ], - "164.310(d)(2)(iii)": [ - "AST-02", - "AST-02.1", - "AST-02.9", - "AST-03", - "AST-03.1" + "500.4(b)(1)": [ + "GOV-01.1", + "TPM-05.6" ], - "164.310(d)(2)(ii)": [ - "AST-09", - "DCH-09" + "500.4(b)(2)": [ + "GOV-01.1", + "TPM-05.6" ], - "164.308(a)(7)(ii)(C)": [ - "BCD-01", - "BCD-02.2" + "500.4(b)(3)": [ + "GOV-01.1", + "GOV-16", + "GOV-16.1", + "GOV-16.2", + "TPM-05.6" ], - "164.308(a)(7)(ii)(D)": [ - "BCD-04", - "BCD-05" + "500.4(b)(4)": [ + "GOV-01.1", + "TPM-05.6" ], - "164.310(a)(2)(i)": [ - "BCD-09.2", - "HRS-03", - "PES-02", - "PES-02.1" + "500.4(b)(5)": [ + "GOV-01.1", + "GOV-16", + "GOV-16.1", + "GOV-16.2", + "TPM-05.6" ], - "164.308(a)(7)(ii)(A)": [ - "BCD-11" + "500.4(b)(6)": [ + "GOV-01.1", + "GOV-04.1", + "CPL-01.1", + "RSK-06", + "TPM-09", + "VPM-02" ], - "164.310(d)(2)(iv)": [ - "BCD-11" + "500.4(d)": [ + "GOV-01.1" ], - "164.308(a)(7)(ii)(B)": [ - "BCD-12" + "500.4(d)(1)": [ + "GOV-01.1" ], - "164.306(c)": [ - "CPL-01" + "500.4(d)(2)": [ + "GOV-01.1" ], - "164.306(d)(1)": [ - "CPL-01" + "500.4(d)(3)": [ + "GOV-01.1" ], - "164.306(d)(2)": [ - "CPL-01" + "500.4(d)(4)": [ + "GOV-01.1", + "PRM-02", + "PRM-03" ], - "164.314(a)(1)": [ - "CPL-01" + "500.4(c)": [ + "GOV-01.2" ], - "164.314(a)(2)(ii)": [ - "CPL-01" + "500.3": [ + "GOV-02", + "OPS-01.1" ], - "164.306(d)(3)(i)": [ - "CPL-02", - "CPL-03", - "CPL-03.2" + "500.3(b)": [ + "GOV-02", + "DCH-01" ], - "164.306(e)": [ - "CPL-03.2" + "500.3(c)": [ + "GOV-02", + "AST-01" ], - "164.308(a)(8)": [ - "CPL-03.2", - "IAO-01.1", - "IAO-02" + "500.3(d)": [ + "GOV-02", + "IAC-01" ], - "164.312(a)(2)(iii)": [ - "CFG-02", - "IAC-25" + "500.3(e)": [ + "GOV-02", + "BCD-01" ], - "164.312(e)(1)": [ - "CFG-02", - "CRY-03", - "NET-01" + "500.3(f)": [ + "GOV-02", + "CAP-01" ], - "164.312(e)(2)(i)": [ - "CFG-02", - "CRY-04", + "500.3(g)": [ + "GOV-02", "NET-01" ], - "164.312(e)(2)(ii)": [ - "CFG-02", - "CRY-01", - "OPS-03" - ], - "164.312(c)(2)": [ - "CFG-08", - "CFG-08.1", - "MON-01.7", - "MON-01.15", - "MON-16" + "500.3(h)": [ + "GOV-02", + "SAT-01" ], - "164.308(a)(1)(ii)(D)": [ - "MON-01", - "MON-01.8", - "IRO-09" + "500.3(i)": [ + "GOV-02", + "TDA-01" ], - "164.312(b)": [ - "MON-01", - "MON-01.4", - "MON-01.8", - "MON-01.16", - "MON-03", - "MON-03.2", - "MON-16" + "500.3(j)": [ + "GOV-02", + "PES-01" ], - "164.312(a)(2)(iv)": [ - "CRY-01" + "500.3(k)": [ + "GOV-02", + "PRI-01" ], - "164.316(b)(2)(i)": [ - "DCH-18" + "500.3(l)": [ + "GOV-02", + "TPM-01" ], - "164.310(c)": [ - "END-02", - "PES-03", - "PES-03.4", - "PES-04", - "PES-04.1" + "500.3(m)": [ + "GOV-02", + "RSK-01" ], - "164.308(a)(3)(ii)(A)": [ - "HRS-01", - "IAC-07.1", - "IAC-08", - "IAC-28.1" + "500.3(n)": [ + "GOV-02", + "IRO-01" ], - "164.312(d)": [ - "HRS-01", - "HRS-04", - "IAC-28", - "IAC-28.2", - "IAC-28.3", - "TPM-01" + "500.3(o)": [ + "GOV-02", + "VPM-01" ], - "164.308(a)(3)(ii)(B)": [ - "HRS-02", - "HRS-03", - "IAC-17" + "500.5": [ + "GOV-02" ], - "164.308(a)(1)(ii)(C)": [ - "HRS-07" + "500.7(b)": [ + "GOV-02", + "IAC-01", + "IAC-10", + "IAC-10.1" ], - "164.308(a)(3)(ii)(C)": [ - "HRS-08", - "HRS-09", - "IAC-07", - "IAC-07.2" + "500.8(a)": [ + "GOV-02", + "OPS-01.1", + "TDA-01", + "TDA-06", + "TDA-06.5", + "TDA-09", + "TDA-09.6" ], - "164.308(a)(4)(ii)(B)": [ - "IAC-01" + "500.11(a)": [ + "GOV-02", + "TPM-01" ], - "164.310(a)(2)(iii)": [ - "IAC-01", - "PES-02", - "PES-03", - "PES-06" + "500.13(a)": [ + "GOV-02", + "AST-01", + "AST-02" ], - "164.312(a)(2)(i)": [ - "IAC-02", - "IAC-09" + "500.14(a)(1)": [ + "GOV-02", + "MON-16", + "SAT-03.2" ], - "164.308(a)(4)(ii)(C)": [ - "IAC-08" + "500.15(a)": [ + "GOV-02", + "CRY-01", + "CRY-03", + "CRY-05" ], - "164.312(a)(2)(ii)": [ - "IAC-15", - "IAC-15.2", - "IAC-15.9" + "500.9(b)(3)": [ + "GOV-02.1", + "RSK-02", + "RSK-02.1", + "RSK-05", + "RSK-06", + "RSK-06.1", + "RSK-06.2" ], - "164.308(a)(6)(ii)": [ - "IRO-02" + "500.12(b)": [ + "GOV-02.1", + "RSK-06", + "RSK-06.2" ], - "164.308(b)(3)": [ - "IAO-03.2", - "TPM-05" + "500.15(b)": [ + "GOV-02.1", + "CRY-01", + "CRY-01.1", + "RSK-06.2" ], - "164.306(b)(2)(iii)": [ - "PRM-03" + "500.8(b)": [ + "GOV-03" ], - "164.306(b)(2)(ii)": [ - "PRM-05", - "SEA-02" + "500.4(a)": [ + "GOV-04" ], - "164.306(b)(2)(iv)": [ - "RSK-01", + "500.9(b)(1)": [ + "GOV-16", + "GOV-16.1", + "GOV-16.2", "RSK-01.1", - "RSK-02", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", "RSK-03", "RSK-03.1", "RSK-04", + "THR-03", "THR-09", "THR-10" ], - "164.308(a)(1)(ii)(A)": [ + "500.9(b)(2)": [ + "GOV-16", + "GOV-16.1", + "GOV-16.2", "RSK-04" ], - "164.306(d)(3)(ii)(B)(2)": [ - "RSK-06.2" + "500.17(a)(1)": [ + "GOV-17", + "IRO-10", + "IRO-10.2", + "IRO-14" ], - "164.316(b)(2)(ii)": [ - "OPS-01.1", - "OPS-03" + "500.17(a)(2)": [ + "GOV-17", + "CPL-01", + "CPL-05", + "CPL-05.2" ], - "164.308(a)(5)(i)": [ - "SAT-01", - "SAT-02" + "500.13(a)(1)": [ + "AST-02" ], - "164.308(a)(5)(ii)(C)": [ - "SAT-03" + "500.13(a)(1)(i)": [ + "AST-02" ], - "164.308(a)(5)(ii)(D)": [ - "SAT-03" + "500.13(a)(1)(ii)": [ + "AST-02" ], - "164.308(a)(5)(ii)(B)": [ - "SAT-03.2" + "500.13(a)(1)(iii)": [ + "AST-02" ], - "164.308(a)(5)(ii)(A)": [ - "SAT-03.6" + "500.13(a)(1)(iv)": [ + "AST-02" ], - "164.308(b)(1)": [ - "TPM-01", - "TPM-04", - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "500.13(a)(1)(v)": [ + "AST-02" ], - "164.308(b)(2)": [ - "TPM-05", - "TPM-05.2", - "TPM-05.6" + "500.13(a)(2)": [ + "AST-02" ], - "164.314(a)(2)(iii)": [ - "TPM-05", - "TPM-05.2" + "500.13(b)": [ + "AST-09", + "DCH-18" ], - "164.314(b)(1)": [ - "TPM-05" + "500.16(a)(2)": [ + "BCD-01" ], - "164.314(b)(2)(i)": [ - "TPM-05" + "500.16(a)(2)(i)": [ + "BCD-01", + "BCD-02" ], - "164.314(b)(2)(ii)": [ - "TPM-05" + "500.16(a)(2)(ii)": [ + "BCD-01", + "BCD-01.5", + "HRS-02", + "HRS-03" ], - "164.314(b)(2)(iii)": [ - "TPM-05" + "500.16(a)(2)(iii)": [ + "BCD-01", + "BCD-01.6" ], - "164.314(a)(2)(i)(C)": [ - "TPM-05.1" + "500.16(a)(2)(iv)": [ + "BCD-01", + "BCD-02.2" ], - "164.314(b)(2)(iv)": [ - "TPM-05.1" + "500.16(a)(2)(v)": [ + "BCD-01", + "BCD-01.4", + "BCD-11" ], - "164.314(a)(2)(i)(B)": [ - "TPM-05.2" - ] - }, - "usa-federal-irs-1075-2021": { - "PM-1": [ - "GOV-01", - "GOV-02", - "GOV-03" + "500.16(a)(2)(vi)": [ + "BCD-01", + "BCD-02" ], - "2.C.2": [ - "GOV-02" + "500.16(b)": [ + "BCD-01", + "IRO-04" ], - "2.C.2-1": [ - "GOV-02" + "500.16(c)": [ + "BCD-03" ], - "2.C.2-2": [ - "GOV-02" + "500.16(d)(1)": [ + "BCD-04", + "IRO-06" ], - "2.C.2-3": [ - "GOV-02" + "500.16(d)(2)": [ + "BCD-04" ], - "2.C.2-4": [ - "GOV-02" + "500.16(e)": [ + "BCD-11", + "BCD-11.1", + "BCD-11.4" ], - "2.C.2-5": [ - "GOV-02" + "500.17(b)(1)": [ + "CPL-01" ], - "2.C.2-6": [ - "GOV-02" + "500.17(b)(1)(i)": [ + "CPL-01" ], - "2.C.2-7": [ - "GOV-02" + "500.17(b)(1)(i)(a)": [ + "CPL-01" ], - "2.C.2-8": [ - "GOV-02" + "500.17(b)(1)(i)(b)": [ + "CPL-01" ], - "2.C.2-9": [ - "GOV-02" + "500.17(b)(1)(ii)": [ + "CPL-01" ], - "2.C.2-10": [ - "GOV-02" + "500.17(b)(1)(ii)(a)": [ + "CPL-01" ], - "2.C.2-11": [ - "GOV-02" + "500.17(b)(1)(ii)(b)": [ + "CPL-01" ], - "2.C.2-12": [ - "GOV-02" + "500.17(b)(1)(ii)(c)": [ + "CPL-01" ], - "2.C.2-13": [ - "GOV-02" + "500.17(b)(2)": [ + "CPL-01" ], - "2.C.2-14": [ - "GOV-02" + "500.17(b)(3)": [ + "CPL-01" ], - "2.C.2-15": [ - "GOV-02" + "500.17(c)": [ + "CPL-01", + "IRO-10" ], - "2.C.2-16": [ - "GOV-02" + "500.2(c)": [ + "CPL-03", + "CPL-03.1" ], - "2.C.2-17": [ - "GOV-02" + "500.6(a)": [ + "CFG-02" ], - "2.C.2-18": [ - "GOV-02" + "500.7(a)(5)": [ + "CFG-02", + "IAC-20.3" ], - "AC-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "500.6(a)(1)": [ + "MON-01", + "MON-03" ], - "AT-1": [ - "GOV-02", - "GOV-03", - "SAT-01" + "500.6(a)(2)": [ + "MON-01", + "MON-02", + "MON-03" ], - "AU-1": [ - "GOV-02", - "GOV-03", - "MON-01" + "500.14(b)(2)": [ + "MON-01.2", + "MON-02" ], - "CA-1": [ - "GOV-02", - "GOV-03", - "IAO-01" + "500.7(c)": [ + "MON-01.15", + "MON-03", + "MON-03.3" ], - "CM-1": [ - "GOV-02", - "GOV-03", - "CFG-01" + "500.6(b)": [ + "MON-10", + "DCH-18", + "IAC-01.1" ], - "CP-1": [ - "GOV-02", - "GOV-03", - "BCD-01" + "500.11(b)(2)": [ + "CRY-01", + "TPM-05", + "TPM-05.2" + ], + "500.18": [ + "DCH-01", + "DCH-01.2" + ], + "500.14(a)(2)": [ + "END-02", + "END-04", + "END-08", + "NET-01", + "NET-18" ], - "IA-1": [ - "GOV-02", - "GOV-03", - "IAC-01" + "500.14(b)(1)": [ + "END-02", + "END-06.2", + "END-07" ], - "IR-1": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "500.10(a)(1)": [ + "HRS-01", + "HRS-03", + "HRS-03.2", + "HRS-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.4" ], - "MA-1": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "500.10(a)(2)": [ + "HRS-03.1", + "HRS-04.2", + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6", + "THR-01" ], - "MP-1": [ - "GOV-02", - "GOV-03", - "DCH-01" + "500.7(a)(6)": [ + "HRS-08", + "HRS-09" ], - "PE-1": [ - "GOV-02", - "GOV-03", - "PES-01" + "500.7(a)(1)": [ + "IAC-01", + "IAC-08", + "IAC-16", + "IAC-17", + "IAC-21" ], - "PL-1": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "500.11(b)(1)": [ + "IAC-06", + "TPM-05", + "TPM-05.2", + "TPM-05.3" ], - "PS-1": [ - "GOV-02", - "GOV-03", - "HRS-01" + "500.12(a)": [ + "IAC-06" ], - "PT-1": [ - "GOV-02", - "GOV-03", - "PRI-01", - "SEA-01" + "500.12(a)(1)": [ + "IAC-06" ], - "RA-1": [ - "GOV-02", - "GOV-03", - "RSK-01" + "500.12(a)(2)": [ + "IAC-06" ], - "SA-1": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "500.12(a)(3)": [ + "IAC-06.1", + "IAC-06.3" ], - "SC-1": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "500.7(c)(2)": [ + "IAC-10.1", + "IAC-10.4" ], - "SI-1": [ - "GOV-02", - "GOV-03", - "SEA-01" + "500.7(a)(4)": [ + "IAC-15.3", + "IAC-15.7", + "IAC-16.1" ], - "SR-1": [ - "GOV-02", - "GOV-03", - "TPM-01" + "500.7(a)(3)": [ + "IAC-16" ], - "PM-2": [ - "GOV-04" + "500.7(c)(1)": [ + "IAC-16" ], - "PM-29": [ - "GOV-04", - "RSK-01", - "RSK-09" + "500.7(a)(2)": [ + "IAC-21" ], - "IR-6": [ - "GOV-06", - "IRO-10", - "IRO-14" + "500.16(a)": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "3.3.1.l": [ - "GOV-15", - "GOV-15.1" + "500.16(a)(1)": [ + "IRO-04" ], - "2.B.7.1": [ - "AST-01" + "500.16(a)(1)(i)": [ + "IRO-04" ], - "2.B.7.2": [ - "AST-01" + "500.16(a)(1)(ii)": [ + "IRO-04" ], - "2.B.7.3": [ - "AST-01" + "500.16(a)(1)(iii)": [ + "IRO-04" ], - "PM-5": [ - "AST-01", - "AST-02" + "500.16(a)(1)(iv)": [ + "IRO-04" ], - "CM-8(CE-1)": [ - "AST-02.1" + "500.16(a)(1)(v)": [ + "IRO-04" ], - "CM-8(CE-3)": [ - "AST-02.2" + "500.16(a)(1)(vi)": [ + "IRO-04" ], - "CM-8(CE-3).a": [ - "AST-02.2" + "500.16(a)(1)(vii)": [ + "IRO-04" ], - "CM-8(CE-3).b": [ - "AST-02.2" + "500.16(a)(1)(viii)": [ + "IRO-04" ], - "CM-8(CE-3).b.1": [ - "AST-02.2" + "500.16(a)(1)(ix)": [ + "IRO-04.2" ], - "CM-8(CE-3).b.2": [ - "AST-02.2" + "500.17(c)(1)": [ + "IRO-10" ], - "CM-8(CE-3).b.3": [ - "AST-02.2" + "500.17(c)(2)": [ + "IRO-10" ], - "CM-8": [ - "AST-02.3" + "500.9(a)": [ + "RSK-01", + "RSK-04", + "RSK-04.1", + "RSK-07" ], - "SC-18(CE-2)": [ - "AST-02.7", - "END-10" + "500.9(b)": [ + "RSK-01", + "RSK-04" ], - "2.A.2": [ - "AST-02.8" + "500.1": [ + "SEA-02.1" ], - "CM-13": [ - "AST-02.8" + "500.14(a)(3)": [ + "SAT-01" ], - "SA-4(CE-12)": [ - "AST-03", - "DCH-01.1", - "PRI-09" + "500.10(a)(3)": [ + "SAT-03.7", + "THR-01" ], - "SA-4(CE-12).a": [ - "AST-03" + "500.4(a)(1)": [ + "TPM-01", + "TPM-05.1", + "TPM-05.4" ], - "PL-2": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "500.4(a)(2)": [ + "TPM-01", + "TPM-05.1", + "TPM-05.4" ], - "SA-4(CE-1)": [ - "AST-04", - "TDA-04.1" + "500.4(a)(3)": [ + "TPM-01", + "TPM-05.1", + "TPM-05.4" ], - "SA-4(CE-2)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "500.11(a)(1)": [ + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2" ], - "SA-5": [ - "AST-04.1", - "TDA-04" + "500.11(b)": [ + "TPM-01", + "TPM-05", + "TPM-05.2" ], - "2.F.3.1": [ - "AST-09" + "500.11(a)(4)": [ + "TPM-02", + "TPM-05.5", + "TPM-08" ], - "SR-10": [ - "AST-15.1", - "TDA-11" + "500.11(a)(3)": [ + "TPM-04.1", + "TPM-05.5", + "TPM-05.6", + "TPM-08" ], - "3.3.5": [ - "AST-23" + "500.10(b)": [ + "TPM-05", + "TPM-05.4", + "TPM-06" ], - "3.3.5.a-1": [ - "AST-23" + "500.11(a)(2)": [ + "TPM-05", + "TPM-05.2" ], - "3.3.5.b-1": [ - "AST-23" + "500.11(b)(3)": [ + "TPM-05", + "TPM-05.1", + "TPM-05.2" ], - "3.3.5.a-2": [ - "AST-23" + "500.11(b)(4)": [ + "TPM-05", + "TPM-05.2", + "TPM-05.6" ], - "3.3.5.b-2": [ - "AST-23" + "500.5(a)(1)": [ + "VPM-01.1", + "VPM-07" ], - "3.3.5.c-2": [ - "AST-23" + "500.5(c)": [ + "VPM-02", + "VPM-03", + "VPM-03.1" ], - "CP-2": [ - "BCD-01", - "BCD-06" + "500.5(b)": [ + "VPM-04" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "500.5(a)(2)": [ + "VPM-06" + ] + }, + "usa-state-ny-shield-act-2019": { + "899-bb.2(b)(ii)": [ + "GOV-01" ], - "CP-2(CE-1)": [ - "BCD-01.1" + "899-bb.2(c)": [ + "GOV-01" ], - "CP-2(CE-8)": [ - "BCD-02" + "899-bb.2(b)(ii)(A)(6)": [ + "GOV-03" ], - "CP-2(CE-3)": [ - "BCD-02.1", - "BCD-02.3" + "899-bb.2(b)(ii)(A)(1)": [ + "GOV-04" ], - "CP-3": [ - "BCD-03" + "899-bb.2(b)(ii)(B)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5" ], - "CP-4": [ - "BCD-04", - "BCD-05" + "899-bb.2(b)(ii)(B)(4)": [ + "GOV-15.3" ], - "CP-4(CE-1)": [ - "BCD-04.1" + "899-bb.2(b)(ii)(A)(3)": [ + "CPL-02" ], - "CP-9": [ - "BCD-11" + "899-bb.2(b)(ii)(B)(3)": [ + "MON-01.8" ], - "CP-9(CE-8)": [ - "BCD-11.4" + "899-bb.2(b)(ii)(C)(2)": [ + "MON-01.8", + "PES-05" ], - "SC-28(CE-1)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "899-bb.2(b)(ii)(C)": [ + "DCH-01", + "PES-01" ], - "CP-10(CE-2)": [ - "BCD-12.1" + "899-bb.2(b)(ii)(C)(3)": [ + "DCH-01.2" ], - "CM-3": [ - "CHG-01", - "CHG-02" + "899-bb.2(b)(ii)(C)(1)": [ + "DCH-06", + "DCH-08", + "DCH-21" ], - "CM-3(CE-2)": [ - "CHG-02.2" + "3.2": [ + "IRO-10" ], - "CM-3(CE-4)": [ - "CHG-02.3" + "3.2(a)": [ + "IRO-10" ], - "CM-4": [ - "CHG-03" + "3.2(b)": [ + "IRO-10" ], - "CM-5": [ - "CHG-04" + "3.3": [ + "IRO-10" ], - "CM-5(IRS-Defined)-1": [ - "CHG-04" + "3.5": [ + "IRO-10" ], - "CM-5(IRS-Defined)-2": [ - "CHG-04" + "3.5(a)": [ + "IRO-10" ], - "CM-14": [ - "CHG-04.2" + "3.5(b)": [ + "IRO-10" ], - "AC-5": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "3.5(c)": [ + "IRO-10" ], - "CM-5(CE-5)": [ - "CHG-04.4" + "3.5(d)": [ + "IRO-10" ], - "CM-5(CE-5).a": [ - "CHG-04.4" + "3.5(d)(1)": [ + "IRO-10" ], - "CM-5(CE-5).b": [ - "CHG-04.4" + "3.5(d)(2)": [ + "IRO-10" ], - "CM-9": [ - "CHG-05", - "CFG-01" + "3.5(d)(3)": [ + "IRO-10" ], - "3.3.1.h": [ - "CLD-02" + "3.8(a)": [ + "IRO-10" ], - "SA-9(CE-5)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" + "3.8(b)": [ + "IRO-10" ], - "SA-9(CE-8)": [ - "CLD-09", - "DCH-19" + "3.9": [ + "IRO-10" ], - "2.E.6.1": [ - "CPL-01" + "5.2": [ + "IRO-10" ], - "2.D.9": [ - "CPL-01.1" + "5.2(a)": [ + "IRO-10" ], - "2.D.3": [ - "CPL-02" + "5.2(b)": [ + "IRO-10" ], - "2.D.8": [ - "CPL-02" + "5.3": [ + "IRO-10" ], - "3.3.1.i": [ - "CPL-02" + "5.6": [ + "IRO-10" ], - "CA-7": [ - "CPL-02" + "5.7(a)": [ + "IRO-10" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "5.7(b)": [ + "IRO-10" ], - "CA-2": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "5.9": [ + "IRO-10" ], - "CA-7(CE-1)": [ - "CPL-03.1" + "5.10": [ + "IRO-10" ], - "RA-3": [ - "CPL-03.2", - "RSK-04" + "899-bb.2(b)(ii)(B)(1)": [ + "NET-01", + "TDA-01" ], - "3.3.8.b": [ - "CFG-02" + "899-bb.2(a)": [ + "PRI-01.6", + "PRI-01.11" ], - "CM-2": [ - "CFG-02", - "CFG-02.1" + "899-bb.2(b)(ii)(A)": [ + "PRI-01.11" ], - "CM-2(IRS-Defined)": [ - "CFG-02", - "CFG-02.1" + "899-bb.2(b)(ii)(C)(4)": [ + "PRI-05" ], - "CM-6": [ - "CFG-02", - "CFG-02.7" + "899-bb.2(b)(ii)(A)(2)": [ + "RSK-01" ], - "CM-6(IRS-Defined)": [ - "CFG-02", - "CFG-02.7" + "899-bb.2(b)(ii)(B)(2)": [ + "RSK-04" ], - "SA-8": [ - "CFG-02", - "SEA-01" + "899-bb.2(b)(ii)(A)(4)": [ + "SAT-02" ], - "CM-2(CE-2)": [ - "CFG-02.2" + "5.8": [ + "SAT-02" ], - "CM-2(CE-3)": [ - "CFG-02.3" + "899-bb.2(b)(ii)(A)(5)": [ + "TPM-03.1" + ] + }, + "usa-state-or-ors-646a-2025": { + "646A.586(3)": [ + "CPL-05.2" ], - "CM-2(CE-7)": [ - "CFG-02.5" + "646A.586(6)": [ + "DCH-18" ], - "CM-2(CE-7).a": [ - "CFG-02.5" + "646A.583(1)(a)(A)": [ + "DCH-23" ], - "CM-2(CE-7).b": [ - "CFG-02.5" + "646A.578(1)(c)": [ + "PRI-01.6", + "PRI-01.11" ], - "CM-7(CE-9)": [ - "CFG-02.5" + "646A.578(2)(a)": [ + "PRI-01.11" ], - "CM-7(CE-9).a": [ - "CFG-02.5" + "646A.578(2)(b)": [ + "PRI-01.11" ], - "CM-7(CE-9).b": [ - "CFG-02.5" + "646A.578(2)(c)": [ + "PRI-01.11" ], - "CM-7(CE-9).c": [ - "CFG-02.5" + "646A.578(2)(d)": [ + "PRI-01.11" ], - "CM-7": [ - "CFG-03" + "646A.581(1)": [ + "PRI-01.11" ], - "CM-7(IRS-Defined)": [ - "CFG-03" + "646A.581(1)(a)": [ + "PRI-01.11" ], - "CM-7(CE-1)": [ - "CFG-03.1" + "646A.581(1)(b)": [ + "PRI-01.11" ], - "CM-7(CE-1).a": [ - "CFG-03.1" + "646A.581(1)(c)": [ + "PRI-01.11" ], - "CM-7(CE-1).b": [ - "CFG-03.1" + "646A.583(1)(b)": [ + "PRI-01.11" ], - "CM-7(CE-5)": [ - "CFG-03.3" + "646A.578(1)(a)": [ + "PRI-02" ], - "CM-7(CE-5).a": [ - "CFG-03.3" + "646A.578(4)": [ + "PRI-02" ], - "CM-7(CE-5).b": [ - "CFG-03.3" + "646A.578(4)(a)": [ + "PRI-02" ], - "CM-7(CE-5).c": [ - "CFG-03.3" + "646A.578(4)(b)": [ + "PRI-02" ], - "SC-7(CE-7)": [ - "CFG-03.4" + "646A.578(4)(c)": [ + "PRI-02" ], - "SC-7(CE-7).a": [ - "CFG-03.4" + "646A.578(4)(d)": [ + "PRI-02" ], - "SC-7(CE-7).b": [ - "CFG-03.4" + "646A.578(4)(e)": [ + "PRI-02" ], - "SC-7(CE-7).b.1": [ - "CFG-03.4" + "646A.578(4)(f)": [ + "PRI-02" ], - "SC-7(CE-7).b.2": [ - "CFG-03.4" + "646A.578(4)(g)": [ + "PRI-02" ], - "SC-7(CE-7).b.3": [ - "CFG-03.4" + "646A.578(4)(h)": [ + "PRI-02" ], - "SC-7(CE-7).c": [ - "CFG-03.4" + "646A.578(4)(i)": [ + "PRI-02" ], - "SC-7(CE-7).c.1": [ - "CFG-03.4" + "646A.578(5)(b)": [ + "PRI-02" ], - "SC-7(CE-7).c.2": [ - "CFG-03.4" + "646A.583(1)(a)(B)": [ + "PRI-02" ], - "SC-7(CE-7).c.3": [ - "CFG-03.4" + "646A.578(6)": [ + "PRI-03" ], - "SC-7(CE-7).c.4": [ - "CFG-03.4" + "646A.583(1)(a)(C)": [ + "PRI-03" ], - "CM-10": [ - "CFG-04" + "646A.576(7)": [ + "PRI-03.4" ], - "CM-11": [ - "CFG-05", - "END-03" + "646A.578(1)(d)": [ + "PRI-03.4" ], - "AC-3(CE-11)": [ - "CFG-08" + "646A.576(3)": [ + "PRI-03.6" ], - "SI-4": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "646A.576(4)": [ + "PRI-03.6" ], - "SI-4(IRS-Defined)": [ - "MON-01" + "646A.578(5)(c)": [ + "PRI-03.8" ], - "SI-4(CE-1)": [ - "MON-01.1" + "646A.578(5)(c)(A)": [ + "PRI-03.8" ], - "SI-4(CE-2)": [ - "MON-01.2" + "646A.578(5)(c)(B)": [ + "PRI-03.8" ], - "SI-4(CE-4)": [ - "MON-01.3" + "646A.578(5)(c)(C)": [ + "PRI-03.8" ], - "SI-4(CE-4).a": [ - "MON-01.3" + "646A.578(5)(c)(D)": [ + "PRI-03.8" ], - "SI-4(CE-4).b": [ - "MON-01.3" + "646A.578(5)(c)(E)": [ + "PRI-03.8" ], - "SI-4(CE-5)": [ - "MON-01.4" + "646A.576(7)(a)": [ + "PRI-03.10" ], - "SI-4(CE-24)": [ - "MON-01.7", - "MON-11.3" + "646A.576(7)(b)": [ + "PRI-03.10" ], - "AU-2": [ - "MON-01.8", - "MON-02" + "646A.578(1)(b)": [ + "PRI-04" ], - "SI-4(CE-12)": [ - "MON-01.12", - "MON-05.1" + "646A.574(1)(a)": [ + "PRI-06" ], - "AU-6": [ - "MON-02", - "MON-02.6" + "646A.574(1)(a)(A)": [ + "PRI-06" ], - "AU-6(CE-3)": [ - "MON-02.1" + "646A.574(1)(a)(B)": [ + "PRI-06" ], - "AU-6(CE-9)": [ - "MON-02.1" + "646A.574(1)(a)(B)(i)": [ + "PRI-06" ], - "AU-6(CE-7)": [ - "MON-02.5" + "646A.574(1)(a)(B)(ii)": [ + "PRI-06" ], - "AU-12(CE-1)": [ - "MON-02.7" + "646A.576(1)": [ + "PRI-06" ], - "AU-3": [ - "MON-03" + "646A.578(5)": [ + "PRI-06" ], - "AU-3(CE-1)": [ - "MON-03.1" + "646A.578(5)(a)": [ + "PRI-06" ], - "AU-6(CE-1)": [ - "MON-03.1" + "646A.578(5)(a)(A)": [ + "PRI-06" ], - "AU-3(CE-3)": [ - "MON-03.5" + "646A.578(5)(a)(B)": [ + "PRI-06" ], - "AU-4": [ - "MON-04" + "646A.578(5)(a)(C)": [ + "PRI-06" ], - "AU-5": [ - "MON-05" + "646A.574(1)(b)": [ + "PRI-06.1" ], - "AU-5(CE-1)": [ - "MON-05.2" + "646A.576(6)": [ + "PRI-06.3" ], - "AU-7": [ - "MON-06" + "646A.576(6)(a)": [ + "PRI-06.3" ], - "AU-7(CE-1)": [ - "MON-06" + "646A.576(6)(b)": [ + "PRI-06.3" ], - "AU-12": [ - "MON-06" + "646A.576(6)(c)": [ + "PRI-06.3" ], - "AU-8": [ - "MON-07", - "SEA-20" + "646A.576(6)(d)": [ + "PRI-06.3" ], - "SC-45": [ - "MON-07.1" + "646A.576(5)": [ + "PRI-06.4" ], - "SC-45(CE-1)": [ - "MON-07.1" + "646A.576(5)(a)": [ + "PRI-06.4" ], - "SC-45(CE-1).a": [ - "MON-07.1" + "646A.576(5)(b)": [ + "PRI-06.4" ], - "SC-45(CE-1).b": [ - "MON-07.1" + "646A.576(5)(c)": [ + "PRI-06.4" ], - "AU-9": [ - "MON-08" + "646A.576(5)(d)": [ + "PRI-06.4" ], - "AU-9(CE-4)": [ - "MON-08.2" + "646A.576(5)(e)": [ + "PRI-06.4" ], - "AU-11": [ - "MON-10" + "646A.576(5)(e)(A)": [ + "PRI-06.4" ], - "SI-4(CE-18)": [ - "MON-11.1", - "NET-17" + "646A.576(5)(e)(B)": [ + "PRI-06.4" ], - "AU-16": [ - "MON-14" + "646A.574(1)(c)": [ + "PRI-06.5" ], - "AU-16(CE-1)": [ - "MON-14" + "646A.574(2)": [ + "PRI-06.6" ], - "AU-16(CE-2)": [ - "MON-14.1" + "646A.574(1)(a)(C)": [ + "PRI-06.7" ], - "AC-2(CE-12)": [ - "MON-16" + "646A.576(2)": [ + "PRI-06.8" ], - "AC-2(CE-12).a": [ - "MON-16" + "646A.581(2)": [ + "PRI-07.1", + "TPM-05" ], - "AC-2(CE-12).b": [ - "MON-16" + "646A.574(1)(d)": [ + "PRI-21" ], - "SI-4(CE-11)": [ - "MON-16" + "646A.574(1)(d)(A)": [ + "PRI-21" ], - "2.E.2": [ - "CRY-01", - "DCH-17" + "646A.574(1)(d)(B)": [ + "PRI-21" ], - "2.E.3": [ - "CRY-01" + "646A.574(1)(d)(C)": [ + "PRI-21" ], - "2.E.3-1": [ - "CRY-01" + "646A.586(1)(a)": [ + "RSK-10" ], - "2.E.3-2": [ - "CRY-01" + "646A.586(1)(b)": [ + "RSK-10" ], - "2.E.3-3": [ - "CRY-01" + "646A.586(1)(b)(A)": [ + "RSK-10" ], - "2.E.3-4": [ - "CRY-01" + "646A.586(1)(b)(B)": [ + "RSK-10" ], - "2.E.3-5": [ - "CRY-01" + "646A.586(1)(b)(C)": [ + "RSK-10" ], - "SC-8(CE-1)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "646A.586(1)(b)(D)": [ + "RSK-10" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "646A.586(1)(b)(D)(i)": [ + "RSK-10" ], - "IA-7": [ - "CRY-02", - "IAC-12" + "646A.586(1)(b)(D)(ii)": [ + "RSK-10" ], - "3.3.1.d": [ - "CRY-03" + "646A.586(1)(b)(D)(iii)": [ + "RSK-10" ], - "SC-8": [ - "CRY-03", - "CRY-04" + "646A.586(1)(b)(D)(iv)": [ + "RSK-10" ], - "SC-8(IRS-Defined)": [ - "CRY-03", - "CRY-04" + "646A.586(1)(c)": [ + "RSK-10" ], - "2.B.6-1": [ - "CRY-05", - "DCH-04" + "646A.586(2)": [ + "RSK-10" ], - "3.3.1.e": [ - "CRY-05" + "646A.586(4)": [ + "RSK-10" ], - "SC-28": [ - "CRY-05", - "END-02" + "646A.586(5)": [ + "RSK-10" ], - "AC-18": [ - "CRY-07" + "646A.581(2)(a)": [ + "TPM-05" ], - "SC-12": [ - "CRY-08" + "646A.581(2)(b)": [ + "TPM-05" ], - "SC-17": [ - "CRY-08" + "646A.581(2)(c)": [ + "TPM-05" ], - "SA-9(CE-6)": [ - "CRY-09.7" + "646A.581(2)(d)": [ + "TPM-05" ], - "SC-23(CE-5)": [ - "CRY-11" + "646A.581(2)(e)": [ + "TPM-05" ], - "2.B.2": [ - "DCH-01", - "PES-01" + "646A.581(2)(f)": [ + "TPM-05" ], - "2.B.4": [ - "DCH-01", - "DCH-07", - "DCH-07.1" + "646A.581(2)(g)": [ + "TPM-05" ], - "2.B.5": [ - "DCH-01", - "PES-12" + "646A.581(2)(h)": [ + "TPM-05" + ] + }, + "usa-state-or-cpa-2023": { + "Section 7(1)(b)": [ + "CPL-01" ], - "2.C.5": [ - "DCH-01", - "DCH-01.2" + "Section 8(3)": [ + "CPL-01.3" ], - "2.C.5.1": [ - "DCH-01" + "Section 8(6)": [ + "DCH-18" ], - "2.C.5.1-1": [ - "DCH-01" + "Section 7(1)(a)(A)": [ + "DCH-23" ], - "2.C.5.1-2": [ - "DCH-01" + "Section 7(1)(a)(B)": [ + "PRI-01.3" ], - "2.C.5.1-3": [ - "DCH-01" + "Section 5(1)(c)": [ + "PRI-01.6" ], - "2.C.7": [ - "DCH-01.2" + "Section 6(1)(b)": [ + "PRI-01.6" ], - "2.C.7-1": [ - "DCH-01.2" + "Section 5(1)(a)": [ + "PRI-02", + "PRI-02.1" ], - "2.C.7-2": [ - "DCH-01.2" + "Section 5(4)(a)": [ + "PRI-02", + "PRI-05.7" ], - "2.C.8": [ - "DCH-01.2" + "Section 5(4)(b)": [ + "PRI-02", + "PRI-02.1" ], - "2.C.8.1": [ - "DCH-01.2" + "Section 5(4)(c)": [ + "PRI-02" ], - "2.C.8.2": [ - "DCH-01.2" + "Section 5(4)(d)": [ + "PRI-02" ], - "MP-2": [ - "DCH-03", - "END-01" + "Section 5(4)(e)": [ + "PRI-02", + "PRI-05.7" ], - "AC-3(CE-9)": [ - "DCH-03.3" + "Section 5(4)(f)": [ + "PRI-02" ], - "AC-3(CE-9).a": [ - "DCH-03.3" + "Section 5(4)(g)": [ + "PRI-02" ], - "AC-3(CE-9).b": [ - "DCH-03.3" + "Section 5(4)(h)": [ + "PRI-02", + "PRI-02.1" ], - "MP-3": [ - "DCH-04", - "DCH-04.1" + "Section 5(4)(i)": [ + "PRI-02" ], - "2.D.5": [ - "DCH-06" + "Section 5(2)(b)": [ + "PRI-03", + "PRI-04", + "PRI-04.1" ], - "MP-4": [ - "DCH-06" + "Section 5(2)(c)": [ + "PRI-03", + "PRI-05.4" ], - "2.B.6": [ - "DCH-06.1" + "Section 5(1)(d)": [ + "PRI-03.4" ], - "2.B.6-2": [ - "DCH-06.1" + "Section 5(2)(d)": [ + "PRI-03.5" ], - "2.B.6-3": [ - "DCH-06.1" + "Section 4(4)": [ + "PRI-03.6" ], - "2.B.4.1": [ - "DCH-07" + "Section 3(1)(d)(A)": [ + "PRI-03.7" ], - "MP-5": [ - "DCH-07" + "Section 3(1)(d)(B)": [ + "PRI-03.7" ], - "MP-5(CE-3)": [ - "DCH-07.1" + "Section 3(1)(d)(C)": [ + "PRI-03.7" ], - "2.F.3-1": [ - "DCH-08" + "Section 5(6)": [ + "PRI-03.7" ], - "2.F.3-2": [ - "DCH-08" + "Section 5(5)(c)": [ + "PRI-03.8" ], - "2.F.3.1-1": [ - "DCH-09" + "Section 5(5)(c)(A)": [ + "PRI-03.8" ], - "2.F.3.1-2": [ - "DCH-09" + "Section 5(5)(c)(B)": [ + "PRI-03.8" ], - "2.F.3.1-3": [ - "DCH-09" + "Section 5(5)(c)(C)": [ + "PRI-03.8" ], - "3.3.1.j": [ - "DCH-09" + "Section 5(5)(c)(D)": [ + "PRI-03.8" ], - "2.F.4-2": [ - "DCH-09.1" + "Section 5(5)(c)(E)": [ + "PRI-03.8" ], - "MP-6(CE-1)": [ - "DCH-09.1" + "Section 5(1)(b)": [ + "PRI-04" ], - "MP-6": [ - "DCH-09.3" + "Section 4(7)(a)": [ + "PRI-05" ], - "MP-6(IRS-Defined)-1": [ - "DCH-09.3" + "Section 7(1)(c)": [ + "PRI-05.1" ], - "MP-6(IRS-Defined)-2": [ - "DCH-09.3" + "Section 4(7)(b)": [ + "PRI-05.4" ], - "MP-7": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "Section 5(2)(a)": [ + "PRI-05.4" ], - "MP-7(IRS-Defined)": [ - "DCH-10" + "Section 3(1)(a)(A)": [ + "PRI-06" ], - "MP-7(IRS-Defined).a": [ - "DCH-10" + "Section 3(1)(b)": [ + "PRI-06.1" ], - "MP-7(IRS-Defined).b": [ - "DCH-10" + "Section 4(6)(a)": [ + "PRI-06.3" ], - "AC-20": [ - "DCH-13" + "Section 4(5)(a)": [ + "PRI-06.4" ], - "AC-20(IRS-Defined)": [ - "DCH-13" + "Section 4(5)(b)": [ + "PRI-06.4" ], - "AC-20(CE-2)": [ - "DCH-13.2" + "Section 4(5)(c)": [ + "PRI-06.4" ], - "AC-20(CE-5)": [ - "DCH-13.2" + "Section 4(5)(d)": [ + "PRI-06.4" ], - "AC-20(CE-3)": [ - "DCH-13.4" + "Section 4(5)(e)": [ + "PRI-06.4" ], - "AC-21": [ - "DCH-14", - "PRI-07" + "Section 4(5)(e)(A)": [ + "PRI-06.4" ], - "2.E.6.2": [ - "DCH-14.2" + "Section 4(5)(e)(B)": [ + "PRI-06.4", + "PRI-07.4" ], - "AC-22": [ - "DCH-15" + "Section 4(6)(b)": [ + "PRI-06.4" ], - "AC-23": [ - "DCH-16" + "Section 4(6)(c)": [ + "PRI-06.4" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "Section 4(6)(d)": [ + "PRI-06.4" ], - "SI-12(CE-2)": [ - "DCH-18.2", - "PRI-05.1" + "Section 5(5)(a)(A)": [ + "PRI-06.4" ], - "2.D.7": [ - "DCH-21" + "Section 5(5)(a)(B)": [ + "PRI-06.4" ], - "CM-12": [ - "DCH-24" + "Section 5(5)(a)(C)": [ + "PRI-06.4" ], - "CM-12(CE-1)": [ - "DCH-24" + "Section 5(5)(b)": [ + "PRI-06.4" ], - "SI-3": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "Section 3(1)(c)": [ + "PRI-06.5" ], - "SI-2": [ - "END-04.1", - "VPM-01", - "VPM-05" + "Section 3(2)": [ + "PRI-06.6", + "PRI-06.7" ], - "SI-3(IRS-Defined)-1": [ - "END-04.7" + "Section 3(1)(a)(C)": [ + "PRI-06.7" ], - "SI-3(IRS-Defined)-2": [ - "END-04.7" + "Section 6(1)(a)": [ + "PRI-07", + "PRI-07.1", + "PRI-07.2" ], - "SI-7": [ - "END-06", - "NET-12", - "TDA-18" + "Section 6(1)(c)": [ + "PRI-07", + "RSK-10" ], - "SI-7(CE-1)": [ - "END-06.1" + "Section 6(1)": [ + "PRI-07.1" ], - "SI-7(CE-7)": [ - "END-06.2" + "Section 6(2)": [ + "PRI-07.1" ], - "SI-7(CE-7).a": [ - "END-06.2" + "Section 7(1)(a)(C)": [ + "PRI-07.1" ], - "SI-7(CE-7).b": [ - "END-06.2" + "Section 3(1)(a)(B)(i)": [ + "PRI-14.1" ], - "SI-7(CE-10)": [ - "END-06.6" + "Section 3(1)(a)(B)(ii)": [ + "PRI-14.1" ], - "SI-8": [ - "END-08" + "Section 8(1)(a)": [ + "RSK-10" ], - "SI-8(CE-2)": [ - "END-08.2" + "Section 8(1)(c)": [ + "RSK-10" ], - "SC-18": [ - "END-10" + "Section 8(2)": [ + "RSK-10" ], - "SC-18(CE-1)": [ - "END-10", - "VPM-02", - "VPM-04" + "Section 6(2)(a)": [ + "TPM-05" ], - "SC-15": [ - "END-14" + "Section 6(2)(b)": [ + "TPM-05" ], - "SC-15(CE-4)": [ - "END-14.2" + "Section 6(2)(c)": [ + "TPM-05" ], - "SC-7(CE-12)": [ - "END-16.1" + "Section 6(2)(d)": [ + "TPM-05" ], - "2.C.3-1": [ - "HRS-01" + "Section 6(2)(e)": [ + "TPM-05" ], - "2.C.3-2": [ - "HRS-01" + "Section 6(2)(f)": [ + "TPM-05" ], - "2.C.3-5": [ - "HRS-01" + "Section 6(2)(g)": [ + "TPM-05" ], - "PS-2": [ - "HRS-02", - "HRS-03.2" + "Section 6(2)(h)": [ + "TPM-05" + ] + }, + "usa-state-tn-tipa-2025": { + "47-18-3206(c)": [ + "CPL-05", + "CPL-05.2", + "RSK-10" ], - "PS-9": [ - "HRS-03" + "47-18-3203(a)(2)(C)": [ + "DCH-23", + "PRI-06.5" ], - "2.C.3": [ - "HRS-04" + "47-18-3204(a)(3)": [ + "PRI-01.6" ], - "2.C.3-3": [ - "HRS-04" + "47-18-3204(a)(1)": [ + "PRI-02", + "PRI-04" ], - "2.C.3-6": [ - "HRS-04" + "47-18-3204(c)": [ + "PRI-02" ], - "2.C.3-6.1": [ - "HRS-04" + "47-18-3204(c)(1)": [ + "PRI-02" ], - "2.C.3-6.2": [ - "HRS-04" + "47-18-3204(c)(2)": [ + "PRI-02", + "PRI-02.1" ], - "2.C.3-6.3": [ - "HRS-04" + "47-18-3204(c)(3)": [ + "PRI-02" ], - "PS-3": [ - "HRS-04" + "47-18-3204(c)(4)": [ + "PRI-02" ], - "2.C.3-4": [ - "HRS-04.1" + "47-18-3204(c)(5)": [ + "PRI-02" ], - "PL-4": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "47-18-3204(d)": [ + "PRI-02", + "PRI-03.3" ], - "PL-4(CE-1)": [ - "HRS-05.2" + "47-18-3204(e)(1)": [ + "PRI-02" ], - "PL-4(CE-1).a": [ - "HRS-05.2" + "47-18-3203(a)(2)(E)": [ + "PRI-03" ], - "PL-4(CE-1).b": [ - "HRS-05.2" + "47-18-3203(b)": [ + "PRI-03", + "PRI-03.1", + "PRI-03.7" ], - "PL-4(CE-1).c": [ - "HRS-05.2" + "47-18-3204(a)(6)": [ + "PRI-03", + "PRI-05.4" ], - "3.3.2": [ - "HRS-05.3" + "47-18-3203(a)(2)(E)(i)": [ + "PRI-03.1", + "PRI-03.3" ], - "3.3.2.a-1": [ - "HRS-05.3" + "47-18-3203(a)(2)(E)(ii)": [ + "PRI-03.1", + "PRI-03.3" ], - "3.3.2.b-1": [ - "HRS-05.3" + "47-18-3203(a)(2)(E)(iii)": [ + "PRI-03.1", + "PRI-03.3" ], - "3.3.2.a-2": [ - "HRS-05.3" + "47-18-3203(a)(1)": [ + "PRI-03.6", + "PRI-06" ], - "3.3.2.b-2": [ - "HRS-05.3" + "47-18-3204(a)(2)": [ + "PRI-04", + "PRI-05.1" ], - "3.3.2.c-2": [ - "HRS-05.3" + "47-18-3204(a)(5)": [ + "PRI-04.1" ], - "3.3.2.a-3": [ - "HRS-05.3" + "47-18-3204(b)": [ + "PRI-04.1" ], - "3.3.2.b-3": [ - "HRS-05.3" + "47-18-3203(a)(2)(C)(i)(a)": [ + "PRI-05", + "PRI-06.5" ], - "3.3.2.c-3": [ - "HRS-05.3" + "47-18-3204(a)(4)": [ + "PRI-05" ], - "3.3.2.d-3": [ - "HRS-05.3" + "47-18-3207(a)(1)": [ + "PRI-05.1" ], - "3.3.2.e-3": [ - "HRS-05.3" + "47-18-3207(a)(2)": [ + "PRI-05.1" ], - "3.3.3": [ - "HRS-05.3" + "47-18-3207(a)(3)": [ + "PRI-05.1" ], - "3.3.3.a-1": [ - "HRS-05.3" + "47-18-3207(b)(1)": [ + "PRI-05.1" ], - "3.3.3.b-1": [ - "HRS-05.3" + "47-18-3207(b)(2)": [ + "PRI-05.1" ], - "3.3.3.a-2": [ - "HRS-05.3" + "47-18-3207(b)(3)": [ + "PRI-05.1", + "PRI-06.4" ], - "3.3.3.b-2": [ - "HRS-05.3" + "47-18-3207(b)(3)(A)": [ + "PRI-05.1", + "PRI-06.4" ], - "3.3.3.c-2": [ - "HRS-05.3" + "47-18-3207(b)(3)(B)": [ + "PRI-05.1", + "PRI-06.4" ], - "3.3.3.d-2": [ - "HRS-05.3" + "47-18-3207(b)(3)(C)": [ + "PRI-05.1", + "PRI-06.4" ], - "3.3.3.d.1-2": [ - "HRS-05.3" + "47-18-3203(a)(2)(C)(i)(b)": [ + "PRI-05.4", + "PRI-06.5" ], - "3.3.3.d.2-2": [ - "HRS-05.3" + "47-18-3203(a)(2)(C)(ii)": [ + "PRI-05.4", + "PRI-06.5" ], - "3.3.3.a-3": [ - "HRS-05.3" + "47-18-3207(b)": [ + "PRI-05.4" ], - "3.3.3.b-3": [ - "HRS-05.3" + "47-18-3207(c)": [ + "PRI-05.4" ], - "PL-4(IRS-Defined)": [ - "HRS-05.3" + "47-18-3207(d)": [ + "PRI-05.4" ], - "PS-6": [ - "HRS-06", - "HRS-06.1" + "47-18-3203(a)(2)(A)": [ + "PRI-06" ], - "PS-6(CE-3)": [ - "HRS-06.2" + "47-18-3203(a)(2)(B)": [ + "PRI-06.1" ], - "PS-6(CE-3).a": [ - "HRS-06.2" + "47-18-3203(b)(1)": [ + "PRI-06.2", + "PRI-06.4" ], - "PS-6(CE-3).b": [ - "HRS-06.2" + "47-18-3203(c)": [ + "PRI-06.3" ], - "2.C.4.2": [ - "HRS-07" + "47-18-3203(b)(2)": [ + "PRI-06.4" ], - "PS-8": [ - "HRS-07" + "47-18-3203(b)(3)": [ + "PRI-06.4" ], - "2.C.4.1": [ - "HRS-08" + "47-18-3203(b)(4)": [ + "PRI-06.4", + "PRI-07.4" ], - "PS-5": [ - "HRS-08" + "47-18-3204(e)(1)(A)": [ + "PRI-06.4" ], - "2.C.4.3": [ - "HRS-09" + "47-18-3204(e)(1)(B)": [ + "PRI-06.4" ], - "PS-4": [ - "HRS-09" + "47-18-3204(e)(1)(C)": [ + "PRI-06.4" ], - "AC-2(CE-13)": [ - "HRS-09.2", - "IAC-15.6" + "47-18-3204(e)(2)": [ + "PRI-06.4" ], - "PS-7": [ - "HRS-10" + "47-18-3203(a)(2)(D)": [ + "PRI-06.6", + "PRI-06.7" ], - "AC-2(CE-7)": [ - "IAC-01" + "47-18-3205(a)": [ + "PRI-07.1" ], - "AC-2(CE-7).a": [ - "IAC-01" + "47-18-3205(a)(1)": [ + "PRI-07.1" ], - "AC-2(CE-7).b": [ - "IAC-01" + "47-18-3205(a)(2)": [ + "PRI-07.1" ], - "AC-2(CE-7).c": [ - "IAC-01" + "47-18-3205(b)": [ + "PRI-07.1" ], - "AC-2(CE-7).d": [ - "IAC-01" + "47-18-3205(b)(1)": [ + "PRI-07.1" ], - "IA-4": [ - "IAC-01.2", - "IAC-09" + "47-18-3205(b)(2)": [ + "PRI-07.1" ], - "IA-4(CE-4)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "47-18-3205(b)(3)": [ + "PRI-07.1" ], - "IA-4(IRS-Defined)": [ - "IAC-01.2", - "IAC-09" + "47-18-3205(b)(4)": [ + "PRI-07.1" ], - "IA-2(CE-8)": [ - "IAC-02.2" + "47-18-3205(b)(5)": [ + "PRI-07.1" ], - "IA-8": [ - "IAC-03" + "47-18-3205(c)": [ + "PRI-07.1" ], - "IA-8(IRS-Defined)": [ - "IAC-03" + "47-18-3205(d)": [ + "PRI-07.1", + "PRI-07.2" ], - "IA-8(CE-2)": [ - "IAC-03.2" + "47-18-3206(a)": [ + "RSK-10" ], - "IA-8(CE-2).a": [ - "IAC-03.2" + "47-18-3206(a)(1)": [ + "RSK-10" ], - "IA-8(CE-2).b": [ - "IAC-03.2" + "47-18-3206(a)(2)": [ + "RSK-10" ], - "IA-8(CE-4)": [ - "IAC-03.3" + "47-18-3206(a)(3)": [ + "RSK-10" ], - "IA-3": [ - "IAC-04" + "47-18-3206(a)(3)(A)": [ + "RSK-10" ], - "IA-3(CE-1)": [ - "IAC-04" + "47-18-3206(a)(3)(B)": [ + "RSK-10" ], - "IA-9": [ - "IAC-05" + "47-18-3206(a)(3)(C)": [ + "RSK-10" ], - "AC-6(CE-6)": [ - "IAC-05.2" + "47-18-3206(a)(3)(D)": [ + "RSK-10" ], - "3.3.1.k": [ - "IAC-06" + "47-18-3206(a)(4)": [ + "RSK-10" ], - "IA-2(CE-1)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "47-18-3206(a)(5)": [ + "RSK-10" ], - "IA-2(CE-2)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "47-18-3206(b)": [ + "RSK-10" ], - "IA-2(CE-6)": [ - "IAC-06.4" + "47-18-3206(d)": [ + "RSK-10" ], - "IA-2(CE-6).a": [ - "IAC-06.4" + "47-18-3206(e)": [ + "RSK-10" ], - "IA-2(CE-6).b": [ - "IAC-06.4" + "47-18-3206(f)": [ + "RSK-10" ], - "AC-2": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "47-18-3201": [ + "SEA-02.1" + ] + }, + "usa-state-tx-bc521-2009": { + "521.053(b)": [ + "IRO-10" ], - "2.D.6": [ - "IAC-08" + "521.053(b-1)": [ + "IRO-10" ], - "IA-5": [ - "IAC-10", - "IAC-10.8" + "521.053(c)": [ + "IRO-10" ], - "IA-5(CE-1).c": [ - "IAC-10" + "521.053(d)": [ + "IRO-10" ], - "IA-5(CE-1).d": [ - "IAC-10" + "521.053(e)": [ + "IRO-10" ], - "IA-5(CE-1).e": [ - "IAC-10" + "521.053(e)(1)": [ + "IRO-10" ], - "IA-5(IRS-Defined)-1": [ - "IAC-10" + "521.053(e)(2)": [ + "IRO-10" ], - "IA-5(IRS-Defined)-2": [ - "IAC-10" + "521.053(e)(3)": [ + "IRO-10" ], - "IA-5(IRS-Defined)-2.a": [ - "IAC-10" + "521.053(f)": [ + "IRO-10" ], - "IA-5(IRS-Defined)-2.b": [ - "IAC-10" + "521.053(f)(1)": [ + "IRO-10" ], - "IA-5(IRS-Defined)-2.c": [ - "IAC-10" + "521.053(f)(2)": [ + "IRO-10" ], - "IA-5(IRS-Defined)-2.d": [ - "IAC-10" + "521.053(f)(3)": [ + "IRO-10" ], - "IA-5(CE-1)": [ - "IAC-10.1" + "521.053(g)": [ + "IRO-10" ], - "IA-5(CE-1).f": [ - "IAC-10.1" + "521.053(h)": [ + "IRO-10" ], - "IA-5(CE-1).h": [ - "IAC-10.1" + "521.053(i)": [ + "IRO-10" ], - "IA-5(CE-1).h.1": [ - "IAC-10.1" + "521.053(i)(1)": [ + "IRO-10" ], - "IA-5(CE-1).h.2": [ - "IAC-10.1" + "521.053(i)(2)": [ + "IRO-10" ], - "IA-5(CE-1).h.3": [ - "IAC-10.1" + "521.053(i)(3)": [ + "IRO-10" ], - "IA-5(CE-1).h.4": [ - "IAC-10.1" + "521.053(i)(4)": [ + "IRO-10" ], - "IA-5(CE-1).h.5": [ - "IAC-10.1" + "521.053(i)(5)": [ + "IRO-10" ], - "IA-5(CE-1).h.5.i": [ - "IAC-10.1" + "521.053(i)(6)": [ + "IRO-10" ], - "IA-5(CE-1).h.5.ii": [ - "IAC-10.1" + "521.052(a)": [ + "PRI-01.6", + "PRI-01.11" ], - "IA-5(CE-1).h.6": [ - "IAC-10.1" + "521.051(a)": [ + "PRI-01.11", + "PRI-05.4" ], - "IA-5(CE-1).h.6.i": [ - "IAC-10.1" + "521.052(b)": [ + "PRI-05" ], - "IA-5(CE-1).h.6.ii": [ - "IAC-10.1" + "521.052(b)(1)": [ + "PRI-05" ], - "IA-5(CE-1).h.7": [ - "IAC-10.1" + "521.052(b)(2)": [ + "PRI-05" ], - "IA-5(CE-2)": [ - "IAC-10.2" + "521.052(b)(3)": [ + "PRI-05" + ] + }, + "usa-state-tx-cdpa-2025": { + "541.101(b)(2)": [ + "CPL-01", + "PRI-01" ], - "IA-5(CE-2).a": [ - "IAC-10.2" + "541.106(a)(1)": [ + "DCH-23" ], - "IA-5(CE-2).a.1": [ - "IAC-10.2" + "541.101(a)(2)": [ + "PRI-01" ], - "IA-5(CE-2).a.2": [ - "IAC-10.2" + "541.204(c)": [ + "PRI-01" ], - "IA-5(CE-2).b": [ - "IAC-10.2" + "541.053(b)": [ + "PRI-02" ], - "IA-5(CE-2).b.1": [ - "IAC-10.2" + "541.055(c)": [ + "PRI-02" ], - "IA-5(CE-2).b.2": [ - "IAC-10.2" + "541.055(d)": [ + "PRI-02" ], - "IA-5(CE-1).a": [ - "IAC-10.4" + "541.102(a)(1)": [ + "PRI-02", + "PRI-05.7" ], - "IA-5(CE-1).b": [ - "IAC-10.4" + "541.102(a)(2)": [ + "PRI-02", + "PRI-02.1" ], - "IA-5(CE-1).g": [ - "IAC-10.4" + "541.102(a)(3)": [ + "PRI-02" ], - "IA-5(CE-6)": [ - "IAC-10.5", - "IAC-18" + "541.102(a)(4)": [ + "PRI-02" ], - "IA-5(CE-7)": [ - "IAC-10.6" + "541.102(a)(5)": [ + "PRI-02" ], - "IA-5(CE-5)": [ - "IAC-10.8" + "541.102(a)(6)": [ + "PRI-02" ], - "IA-5(CE-12)": [ - "IAC-10.12" + "541.102(b)": [ + "PRI-02" ], - "IA-6": [ - "IAC-11" + "541.103": [ + "PRI-02" ], - "IA-11": [ - "IAC-14" + "541.106(a)(2)": [ + "PRI-02" ], - "AC-2(CE-1)": [ - "IAC-15.1" + "541.101(b)(1)": [ + "PRI-02.1", + "PRI-04" ], - "AC-2(CE-2)": [ - "IAC-15.2" + "541.101(b)(4)": [ + "PRI-03", + "PRI-03.3" ], - "AC-2(CE-3)": [ - "IAC-15.3" + "541.107(a)": [ + "PRI-03" ], - "AC-2(CE-3).a": [ - "IAC-15.3" + "541.101(b)(3)": [ + "PRI-03.5" ], - "AC-2(CE-3).b": [ - "IAC-15.3" + "541.101(c)": [ + "PRI-03.5" ], - "AC-2(CE-3).c": [ - "IAC-15.3" + "541.055(e)": [ + "PRI-03.6" ], - "AC-2(CE-3).d": [ - "IAC-15.3" + "541.055(e)(1)": [ + "PRI-03.6" ], - "AC-2(CE-4)": [ - "IAC-15.4" + "541.055(e)(2)": [ + "PRI-03.6" ], - "AC-2(CE-9)": [ - "IAC-15.5" + "541.055(e)(3)": [ + "PRI-03.6" ], - "AC-6(CE-7)": [ - "IAC-17" + "541.055(e)(4)": [ + "PRI-03.6" ], - "AC-6(CE-7).a": [ - "IAC-17" + "541.051(b)(5)(A)": [ + "PRI-03.7" ], - "AC-6(CE-7).b": [ - "IAC-17" + "541.051(b)(5)(B)": [ + "PRI-03.7" ], - "AC-3": [ - "IAC-20", - "NET-12", - "TDA-18" + "541.051(b)(5)(C)": [ + "PRI-03.7" ], - "AC-6": [ - "IAC-20", - "IAC-21" + "541.052(f)(2)": [ + "PRI-03.7", + "PRI-03.9", + "PRI-05.4" ], - "AC-6(CE-1)": [ - "IAC-21.1" + "541.052(a)": [ + "PRI-03.9" ], - "AC-6(CE-1).a": [ - "IAC-21.1" + "541.101(a)(1)": [ + "PRI-04" ], - "AC-6(CE-1).b": [ - "IAC-21.1" + "541.204(a)": [ + "PRI-05.4" ], - "AC-6(CE-2)": [ - "IAC-21.2" + "541.204(a)(1)": [ + "PRI-05.4" ], - "AC-6(IRS-Defined)-1": [ - "IAC-21.2" + "541.204(a)(2)": [ + "PRI-05.4" ], - "AC-6(IRS-Defined)-2": [ - "IAC-21.2" + "541.204(b)": [ + "PRI-05.4" ], - "AC-6(CE-9)": [ - "IAC-21.4" + "541.051(a)": [ + "PRI-06" ], - "AC-6(CE-10)": [ - "IAC-21.5" + "541.055(a)(1)": [ + "PRI-06", + "PRI-18" ], - "AC-6(CE-8)": [ - "IAC-21.7" + "541.051(b)(2)": [ + "PRI-06.1" ], - "AC-7": [ - "IAC-22" + "541.053(a)": [ + "PRI-06.3", + "PRI-18" ], - "AC-11": [ - "IAC-24" + "541.051(b)(1)": [ + "PRI-06.4" ], - "AC-11(CE-1)": [ - "IAC-24.1" + "541.052(b)": [ + "PRI-06.4" ], - "AC-12": [ - "IAC-25" + "541.052(c)": [ + "PRI-06.4" ], - "AC-12(CE-1)": [ - "IAC-25.1" + "541.052(d)": [ + "PRI-06.4" ], - "AC-14": [ - "IAC-26" + "541.053(c)": [ + "PRI-06.4" ], - "IA-12": [ - "IAC-28" + "541.053(d)": [ + "PRI-06.4" ], - "IA-12(CE-1)": [ - "IAC-28.1" + "541.055(a)(2)": [ + "PRI-06.4" ], - "IA-12(CE-2)": [ - "IAC-28.2" + "541.055(a)(3)": [ + "PRI-06.4", + "WEB-06" ], - "IA-12(CE-3)": [ - "IAC-28.3" + "541.055(b)": [ + "PRI-06.4" ], - "IA-12(CE-5)": [ - "IAC-28.5" + "541.051(b)(3)": [ + "PRI-06.5" ], - "1.8.4": [ - "IRO-01" + "541.051(b)(4)": [ + "PRI-06.7" ], - "IR-4": [ - "IRO-02" + "541.104(a)(1)": [ + "PRI-07.1" ], - "IR-4(CE-1)": [ - "IRO-02.1" + "541.104(a)(2)": [ + "PRI-07.1" ], - "IR-4(CE-6)": [ - "IRO-02.2" + "541.104(a)(3)": [ + "PRI-07.1" ], - "IR-4(CE-8)": [ - "IRO-02.5" + "541.104(b)(1)": [ + "PRI-07.1" ], - "IR-8": [ - "IRO-04" + "541.104(b)(2)": [ + "PRI-07.1" ], - "IR-8(CE-1)": [ - "IRO-04.1" + "541.104(b)(3)": [ + "PRI-07.1" ], - "IR-8(CE-1).a": [ - "IRO-04.1" + "541.104(b)(4)": [ + "PRI-07.1" ], - "IR-8(CE-1).b": [ - "IRO-04.1" + "541.104(b)(5)": [ + "PRI-07.1" ], - "IR-8(CE-1).c": [ - "IRO-04.1" + "541.104(b)(6)(A)": [ + "PRI-07.1" ], - "IR-3(CE-3)": [ - "IRO-04.3" + "541.104(b)(6)(B)": [ + "PRI-07.1" ], - "IR-3(CE-3).a": [ - "IRO-04.3" + "541.104(b)(6)(C)": [ + "PRI-07.1" ], - "IR-3(CE-3).b": [ - "IRO-04.3" + "541.104(b)(6)(D)": [ + "PRI-07.1" ], - "IR-3(CE-3).c": [ - "IRO-04.3" + "541.104(b)(6)(E)": [ + "PRI-07.1" ], - "IR-2": [ - "IRO-05" + "541.104(c)": [ + "PRI-07.1" ], - "IR-2(CE-3)": [ - "IRO-05" + "541.106(a)(3)": [ + "PRI-07.1" ], - "IR-2(CE-1)": [ - "IRO-05.1" + "541.106(d)": [ + "PRI-07.1" ], - "IR-3": [ - "IRO-06" + "541.052(e)": [ + "PRI-07.4" ], - "IR-3(CE-2)": [ - "IRO-06.1" + "541.052(f)(1)": [ + "PRI-14" ], - "IR-5": [ - "IRO-09" + "541.105(a)(1)": [ + "RSK-10" ], - "IR-6(CE-1)": [ - "IRO-10.1" + "541.105(a)(2)": [ + "RSK-10" + ], + "541.105(a)(3)(A)": [ + "RSK-10" ], - "IR-6(CE-3)": [ - "IRO-10.3" + "541.105(a)(3)(B)": [ + "RSK-10" ], - "IR-7": [ - "IRO-10.4" + "541.105(a)(3)(C)": [ + "RSK-10" ], - "IR-7(CE-1)": [ - "IRO-11" + "541.105(a)(3)(D)": [ + "RSK-10" ], - "IR-7(CE-2)": [ - "IRO-11.2" + "541.105(a)(4)": [ + "RSK-10" ], - "IR-7(CE-2).a": [ - "IRO-11.2" + "541.105(a)(5)": [ + "RSK-10" ], - "IR-7(CE-2).b": [ - "IRO-11.2" + "541.105(b)(1)": [ + "RSK-10" ], - "IR-9": [ - "IRO-12" + "541.105(b)(2)(A)": [ + "RSK-10" ], - "IR-6(CE-2)": [ - "IRO-13" + "541.105(b)(2)(B)": [ + "RSK-10" ], - "PM-10": [ - "IAO-01" + "541.105(b)(2)(C)": [ + "RSK-10" ], - "CA-2(CE-1)": [ - "IAO-02.1" + "541.105(b)(2)(D)": [ + "RSK-10" ], - "SA-11(CE-5)": [ - "IAO-02.2", - "IAO-04", - "TDA-09", - "TDA-09.5", - "VPM-07" + "541.105(c)": [ + "RSK-10" ], - "2.E.4.3": [ - "IAO-03" + "541.105(d)": [ + "RSK-10" ], - "2.E.4.3-1.1": [ - "IAO-03" + "541.105(e)": [ + "RSK-10" ], - "2.E.4.3-1.2": [ - "IAO-03" + "541.105(f)": [ + "RSK-10" ], - "2.E.4.3-1.3": [ - "IAO-03" + "541.001": [ + "SEA-02.1" ], - "2.E.4.3-1.4": [ - "IAO-03" + "541.104(a)": [ + "TPM-05" ], - "2.E.4.3-1.5": [ - "IAO-03" + "541.104(b)": [ + "TPM-05" + ] + }, + "usa-state-tx-dir-security-control-standards-catalog-2-2": { + "PM-01": [ + "GOV-01", + "GOV-02", + "GOV-03" ], - "2.E.4.3-2.1": [ - "IAO-03" + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "2.E.4.3-2.2": [ - "IAO-03" + "AC-18-SID": [ + "GOV-02" ], - "2.E.4.3-2.3": [ - "IAO-03" + "AT-01": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "2.E.4.3-2.4": [ - "IAO-03" + "AU-01": [ + "GOV-02", + "GOV-03", + "MON-01" ], - "2.E.6.1-1": [ - "IAO-03" + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "2.E.6.1-2": [ - "IAO-03" + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "2.E.6.1-3": [ - "IAO-03" + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "2.E.6.1-4": [ - "IAO-03" + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "PL-2(IRS-Defined)": [ - "IAO-03" + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "SA-11(CE-5).a": [ - "IAO-04" + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "SA-11(CE-5).b": [ - "IAO-04" + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "2.E.5": [ - "IAO-05" + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "2.E.5-1": [ - "IAO-05" + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "2.E.5-2": [ - "IAO-05" + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "2.E.5-3": [ - "IAO-05" + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "CA-5": [ - "IAO-05" + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01", + "TDA-06" ], - "CA-5(IRS-Defined)-1": [ - "IAO-05" + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "CA-5(IRS-Defined)-2": [ - "IAO-05" + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "PM-4": [ - "IAO-05", - "VPM-02" + "SR-01": [ + "GOV-02", + "GOV-03", + "TPM-01" ], - "CM-4(CE-2)": [ - "IAO-06" + "PM-02": [ + "GOV-04" ], - "CA-6": [ - "IAO-07" + "PM-02-SID": [ + "GOV-04" ], - "MA-2": [ - "MNT-02" + "PM-06": [ + "GOV-04", + "GOV-05" ], - "MA-6": [ - "MNT-03" + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "MA-3": [ - "MNT-04" + "PM-15": [ + "GOV-07", + "THR-01" ], - "MA-3(CE-5)": [ - "MNT-04" + "PL-01-SID": [ + "GOV-17" ], - "MA-3(CE-1)": [ - "MNT-04.1" + "PM-05": [ + "AST-01", + "AST-02" ], - "MA-3(CE-2)": [ - "MNT-04.2" + "CM-08": [ + "AST-02", + "AST-02.3" ], - "MA-3(CE-3)": [ - "MNT-04.3" + "PM-05-SID": [ + "AST-02" ], - "MA-3(CE-3).a": [ - "MNT-04.3" + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "MA-3(CE-3).b": [ - "MNT-04.3" + "SA-05": [ + "AST-04.1", + "TDA-04" ], - "MA-3(CE-3).c": [ - "MNT-04.3" + "SR-12": [ + "AST-09" ], - "MA-3(CE-3).d": [ - "MNT-04.3" + "CP-02": [ + "BCD-01", + "BCD-06" ], - "MA-3(CE-4)": [ - "MNT-04.4" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "MA-4": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "CP-02-SID": [ + "BCD-01.7" ], - "MA-4(CE-1)": [ - "MNT-05.1" + "CP-03": [ + "BCD-03" ], - "MA-4(CE-1).a": [ - "MNT-05.1" + "CP-04": [ + "BCD-04", + "BCD-05" ], - "MA-4(CE-1).b": [ - "MNT-05.1" + "CP-04-SID": [ + "BCD-04" ], - "MA-4(CE-6)": [ - "MNT-05.3" + "CP-06": [ + "BCD-08" ], - "MA-4(CE-7)": [ - "MNT-05.4" + "CP-07": [ + "BCD-09" ], - "MA-4(CE-4)": [ - "MNT-05.7" + "CP-08": [ + "BCD-10" ], - "MA-4(CE-4).a": [ - "MNT-05.7" + "CP-11": [ + "BCD-10" ], - "MA-4(CE-4).b": [ - "MNT-05.7" + "CP-06-SID": [ + "BCD-11" ], - "MA-4(CE-4).b.1": [ - "MNT-05.7" + "CP-09": [ + "BCD-11" ], - "MA-4(CE-4).b.2": [ - "MNT-05.7" + "CP-09(3)": [ + "BCD-11.2" ], - "MA-5": [ - "MNT-06" + "CP-09(2)": [ + "BCD-11.5" ], - "MA-5(CE-5)": [ - "MNT-06.2" + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "SR-11(CE-2)": [ - "MNT-07" + "CM-03": [ + "CHG-01", + "CHG-02" ], - "3.3.4": [ - "MDM-01" + "CM-03-SID": [ + "CHG-02" ], - "AC-19": [ - "MDM-02" + "CM-04": [ + "CHG-03" ], - "AC-19(CE-5)": [ - "MDM-03" + "CM-05": [ + "CHG-04", + "END-03.2" ], - "AC-7(CE-2)": [ - "MDM-05" + "AC-05": [ + "CHG-04.3", + "HRS-11", + "NET-12", + "TDA-18" ], - "3.3.6": [ - "NET-01" + "AT-02-SID": [ + "CPL-01" ], - "SC-7": [ - "NET-03" + "AT-03-SID": [ + "CPL-01" ], - "SC-7(CE-9)": [ - "NET-03" + "CA-07": [ + "CPL-02" ], - "SC-7(CE-9).a": [ - "NET-03" + "PM-14": [ + "CPL-02", + "PRI-08" ], - "SC-7(CE-9).b": [ - "NET-03" + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "SC-7(CE-11)": [ - "NET-03", - "NET-04.1" + "CA-02-SID": [ + "CPL-03" ], - "SC-7(IRS-Defined)-1": [ - "NET-03" + "RA-03": [ + "CPL-03.2", + "RSK-04" ], - "SC-7(IRS-Defined)-2": [ - "NET-03" + "AC-07-SID.3": [ + "CFG-02" ], - "SC-7(CE-3)": [ - "NET-03.1" + "AC-07-SID.3.a": [ + "CFG-02" ], - "SC-7(CE-4)": [ - "NET-03.2" + "AC-07-SID.3.b": [ + "CFG-02" ], - "SC-7(CE-4).a": [ - "NET-03.2" + "AC-07-SID.3.c": [ + "CFG-02" ], - "SC-7(CE-4).b": [ - "NET-03.2" + "AC-07-SID.3.d": [ + "CFG-02" ], - "SC-7(CE-4).c": [ - "NET-03.2" + "AC-07-SID.3.e": [ + "CFG-02" ], - "SC-7(CE-4).d": [ - "NET-03.2" + "AC-07-SID.3.f": [ + "CFG-02" ], - "SC-7(CE-4).e": [ - "NET-03.2" + "AC-07-SID.3.g": [ + "CFG-02" ], - "SC-7(CE-4).f": [ - "NET-03.2" + "AC-18-SID.1": [ + "CFG-02" ], - "SC-7(CE-4).g": [ - "NET-03.2" + "CM-02": [ + "CFG-02", + "CFG-02.1" ], - "SC-7(CE-4).h": [ - "NET-03.2" + "CM-06": [ + "CFG-02", + "CFG-02.7" ], - "SC-7(CE-10)": [ - "NET-03.5" + "PL-10": [ + "CFG-02" ], - "SC-7(CE-10).a": [ - "NET-03.5" + "PL-10-SID": [ + "CFG-02" ], - "SC-7(CE-10).b": [ - "NET-03.5" + "PL-10-SID.1": [ + "CFG-02" ], - "AC-4": [ - "NET-04" + "PL-10-SID.2": [ + "CFG-02" ], - "SC-7(CE-5)": [ - "NET-04.1" + "SA-08": [ + "CFG-02", + "SEA-01" ], - "2.E.4.1": [ - "NET-05" + "PL-11": [ + "CFG-02.9" ], - "CA-3": [ - "NET-05" + "PL-11-SID": [ + "CFG-02.9" ], - "CA-9": [ - "NET-05.2" + "PL-11-SID.1": [ + "CFG-02.9" ], - "SC-10": [ - "NET-07" + "PL-11-SID.2": [ + "CFG-02.9" ], - "SC-23": [ - "NET-09" + "CM-07": [ + "CFG-03" ], - "SC-23(CE-1)": [ - "NET-09.1" + "CM-10": [ + "CFG-04" ], - "SC-23(CE-3)": [ - "NET-09.2" + "CM-11": [ + "CFG-05", + "END-03" ], - "SC-20": [ - "NET-10" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "SC-20(CE-2)": [ - "NET-10" + "AT-02": [ + "MON-01.8", + "MON-02" ], - "SC-22": [ - "NET-10.1" + "AU-02": [ + "MON-01.8", + "MON-02" ], - "SC-21": [ - "NET-10.2" + "AU-06": [ + "MON-02", + "MON-02.6" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "AU-02-SID": [ + "MON-02.7" ], - "SI-10": [ - "NET-12", - "TDA-18" + "AU-03": [ + "MON-03" ], - "AC-17": [ - "NET-14" + "AU-04": [ + "MON-04" ], - "AC-17(CE-1)": [ - "NET-14.1" + "AU-05": [ + "MON-05" ], - "AC-17(CE-2)": [ - "NET-14.2" + "AU-12": [ + "MON-06" ], - "AC-17(CE-3)": [ - "NET-14.3" + "AU-08": [ + "MON-07", + "SEA-20" ], - "AC-17(CE-4)": [ - "NET-14.4" + "AU-09": [ + "MON-08" ], - "AC-17(CE-4).a": [ - "NET-14.4" + "AU-11": [ + "MON-10" ], - "AC-17(CE-4).b": [ - "NET-14.4" + "SC-13": [ + "CRY-01", + "CRY-01.2", + "CRY-05" ], - "2.B.7": [ - "NET-14.5" + "SC-13-SID": [ + "CRY-01" ], - "CA-9(CE-1)": [ - "NET-14.7" + "IA-07": [ + "CRY-02", + "IAC-12" ], - "AC-17(CE-9)": [ - "NET-14.8" + "SC-08": [ + "CRY-03", + "CRY-04" ], - "AC-18(IRS-Defined)-1": [ - "NET-15" + "SC-08-SID": [ + "CRY-03" ], - "AC-18(IRS-Defined)-2": [ + "AC-18": [ + "CRY-07", "NET-15" ], - "AC-18(IRS-Defined)-3": [ - "NET-15" + "SC-12": [ + "CRY-08" ], - "AC-18(IRS-Defined)-4": [ - "NET-15" + "RA-02-SID": [ + "DCH-02" ], - "AC-18(CE-1)": [ - "NET-15.1" + "MP-02": [ + "DCH-03", + "END-01" ], - "AC-18(CE-3)": [ - "NET-15.2" + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "SC-7(CE-8)": [ - "NET-18", - "NET-18.1" + "MP-06(1)": [ + "DCH-09.1" ], - "SI-4(CE-10)": [ - "NET-18.2" + "MP-06(1)-SID": [ + "DCH-09.1" ], - "SC-7(CE-15)": [ - "NET-18.3" + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "PE-1(IRS-Defined)-1": [ - "PES-01" + "AC-20": [ + "DCH-13" ], - "PE-1(IRS-Defined)-2": [ - "PES-01" + "AC-22": [ + "DCH-15" ], - "PE-1(IRS-Defined)-3": [ - "PES-01" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "2.B.3.2": [ - "PES-02" + "PM-22": [ + "DCH-22", + "PRI-10" ], - "2.B.3.2-1": [ - "PES-02" + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "2.B.3.2-2": [ - "PES-02" + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "2.B.3.2-3": [ - "PES-02" + "SI-08": [ + "END-08" ], - "2.B.3.2-4": [ - "PES-02" + "SC-15": [ + "END-14" ], - "2.B.3.2-5": [ - "PES-02" + "PS-04-SID": [ + "HRS-01.1" ], - "PE-2": [ - "PES-02" + "PS-05-SID": [ + "HRS-01.1" ], - "2.B.3.4": [ - "PES-03" + "PS-02": [ + "HRS-02", + "HRS-03.2" ], - "PE-3": [ - "PES-03" + "PS-09": [ + "HRS-03" ], - "PE-3(CE-2)": [ - "PES-03" + "PS-03": [ + "HRS-04" ], - "2.B.3.5": [ - "PES-03.3" + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "2.B.3.5-1": [ - "PES-03.3" + "PL-04(1)": [ + "HRS-05.2" ], - "2.B.3.5-2": [ - "PES-03.3" + "AC-19-SID": [ + "HRS-05.3" ], - "2.B.3.5-3": [ - "PES-03.3" + "PL-04-SID": [ + "HRS-05.7" ], - "PE-8": [ - "PES-03.3" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "2.B.3.3": [ - "PES-04" + "PS-08": [ + "HRS-07" ], - "PE-6": [ - "PES-05" + "PS-05": [ + "HRS-08" ], - "PE-6(CE-1)": [ - "PES-05.1" + "PS-04": [ + "HRS-09" ], - "2.B.3.1": [ - "PES-06", - "PES-06.2" + "PS-07": [ + "HRS-10" ], - "2.B.3.1-1": [ - "PES-06" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "2.B.3.1-2": [ - "PES-06" + "IA-02": [ + "IAC-02" ], - "2.B.3.1-3": [ - "PES-06" + "IA-08": [ + "IAC-03" ], - "2.B.3.1-4": [ - "PES-06" + "IA-02(1)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "2.B.3.1-5": [ - "PES-06" + "IA-02(2)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "2.B.3.1-6": [ - "PES-06" + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "2.B.3.1-7": [ - "PES-06" + "IA-05": [ + "IAC-10", + "IAC-10.8" ], - "PE-16": [ - "PES-10" + "IA-05(1)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "PE-17": [ - "PES-11" + "IA-06": [ + "IAC-11" ], - "PE-4": [ - "PES-12.1" + "IA-11": [ + "IAC-14" ], - "PE-5": [ - "PES-12.2" + "IA-02-SID": [ + "IAC-15" ], - "PM-18": [ - "PRI-01" + "IA-08-SID": [ + "IAC-15" ], - "PM-19": [ - "PRI-01.1" + "AC-02(3)": [ + "IAC-15.3" ], - "PT-2": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "PM-5(CE-1)": [ - "PRI-05.5", - "PRI-05.6" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "PM-21": [ - "PRI-14.1" + "AC-06-SID": [ + "IAC-21" ], - "PM-3": [ - "PRM-02" + "AC-07": [ + "IAC-22" ], - "SA-2": [ - "PRM-03" + "AC-07-SID.1": [ + "IAC-22" ], - "SA-3": [ - "PRM-07", - "SEA-07.1" + "AC-07-SID.2": [ + "IAC-22" ], - "PM-9": [ - "RSK-01" + "AC-14": [ + "IAC-26" ], - "RA-7": [ - "RSK-06.1" + "IR-04": [ + "IRO-02" ], - "SA-9(CE-3)": [ - "RSK-09", - "TPM-02", - "TPM-03", - "TPM-04.3", - "TPM-05.4", - "TPM-05.7" + "IR-08-SID": [ + "IRO-02.4" ], - "SR-2": [ - "RSK-09", - "TPM-03" + "IR-08": [ + "IRO-04" ], - "RA-3(CE-1)": [ - "RSK-09.1" + "IR-01-SID": [ + "IRO-04.2" ], - "RA-3(CE-1).c": [ - "RSK-09.1" + "IR-02": [ + "IRO-05" ], - "RA-3(CE-1).d": [ - "RSK-09.1" + "IR-02-SID": [ + "IRO-05" ], - "RA-8": [ - "RSK-10" + "IR-03": [ + "IRO-06" ], - "CA-7(CE-4)": [ - "RSK-11" + "IR-05": [ + "IRO-09" ], - "CA-7(CE-4).a": [ - "RSK-11" + "IR-06-SID": [ + "IRO-10" ], - "CA-7(CE-4).b": [ - "RSK-11" + "IR-07": [ + "IRO-11" ], - "CA-7(CE-4).c": [ - "RSK-11" + "IR-09": [ + "IRO-12", + "IRO-12.1" ], - "SC-7(CE-18)": [ - "SEA-01" + "PM-10": [ + "IAO-01" ], - "PL-8": [ - "SEA-02" + "AC-20-SID": [ + "IAO-03.2" ], - "PM-7": [ - "SEA-02" + "SA-04-SID": [ + "IAO-03.2" ], - "PM-7(IRS-Defined)": [ - "SEA-02" + "SA-09-SID": [ + "IAO-03.2" ], - "PL-8(CE-1)": [ - "SEA-03" + "CA-05": [ + "IAO-05" ], - "PL-8(CE-1).a": [ - "SEA-03" + "PM-04": [ + "IAO-05", + "VPM-02" ], - "PL-8(CE-1).b": [ - "SEA-03" + "CA-06": [ + "IAO-07" ], - "SC-2": [ - "SEA-03.2" + "CA-06-SID": [ + "IAO-07" ], - "SC-2(CE-1)": [ - "SEA-03.2" + "MA-02": [ + "MNT-02" ], - "SC-39": [ - "SEA-04" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "SC-4": [ - "SEA-05" + "MA-05": [ + "MNT-06" ], - "SI-16": [ - "SEA-10" + "AC-19": [ + "MDM-02" ], - "SC-35": [ - "SEA-12" + "SC-07": [ + "NET-03" ], - "3.3.7": [ - "SEA-13.1" + "CA-03": [ + "NET-05" ], - "AC-8": [ - "SEA-18" + "CA-03-SID": [ + "NET-05" ], - "2.D.2": [ - "SAT-01" + "CA-09": [ + "NET-05.2" ], - "2.D.2.1": [ - "SAT-02", - "SAT-03" + "SC-20": [ + "NET-10" ], - "AT-2": [ - "SAT-02" + "SC-22": [ + "NET-10.1" ], - "AT-2(IRS-Defined)-1": [ - "SAT-02" + "SC-21": [ + "NET-10.2" ], - "AT-2(IRS-Defined)-2": [ - "SAT-02" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "AT-2(CE-1)": [ - "SAT-02.1" + "SI-10": [ + "NET-12", + "TDA-18" ], - "AT-6": [ - "SAT-02.1" + "AC-17": [ + "NET-14" ], - "AT-2(CE-3)": [ - "SAT-02.2" + "AC-18-SID.2": [ + "NET-15.1" ], - "AT-3": [ - "SAT-03" + "AC-18-SID.3": [ + "NET-15.5" ], - "AT-2(CE-4)": [ - "SAT-03.2" + "PE-02": [ + "PES-02" ], - "2.D.2.1-1.1": [ - "SAT-03.3" + "PE-03": [ + "PES-03" ], - "2.D.2.1-1.2": [ - "SAT-03.3" + "PE-08": [ + "PES-03.3" ], - "2.D.2.1-1.3": [ - "SAT-03.3" + "PE-06": [ + "PES-05" ], - "2.D.2.1-1.4": [ - "SAT-03.3" + "PE-12": [ + "PES-07.4" ], - "2.D.2.1-2.1": [ - "SAT-03.3" + "PE-15": [ + "PES-07.5" ], - "2.D.2.1-2.2": [ - "SAT-03.3" + "PE-13": [ + "PES-08" ], - "2.D.2.1-2.3": [ - "SAT-03.3" + "PE-14": [ + "PES-09" ], - "2.D.2.1-2.4": [ - "SAT-03.3" + "PE-16": [ + "PES-10" ], - "2.D.2.1-2.5": [ - "SAT-03.3" + "PE-17": [ + "PES-11" ], - "2.D.2.1-2.6": [ - "SAT-03.3" + "PM-05(1)": [ + "PRI-05.5", + "PRI-05.6" ], - "2.D.2.1-2.7": [ - "SAT-03.3" + "PM-03": [ + "PRM-02" ], - "AT-4": [ - "SAT-04" + "SA-02": [ + "PRM-03" ], - "SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "PM-11": [ + "PRM-06" ], - "SA-4(CE-9)": [ - "TDA-02.1" + "SA-03": [ + "PRM-07", + "SEA-07.1" ], - "SA-10(CE-7)": [ - "TDA-02.7" + "PM-09": [ + "RSK-01" ], - "SA-15": [ - "TDA-06" + "RA-02": [ + "RSK-02" ], - "SA-15(CE-3)": [ - "TDA-06.1" + "RA-03-SID": [ + "RSK-04" ], - "SA-15(CE-3).a": [ - "TDA-06.1" + "RA-07": [ + "RSK-06.1" ], - "SA-15(CE-3).b": [ - "TDA-06.1" + "SR-02": [ + "RSK-09", + "TPM-03" ], - "SA-11": [ - "TDA-09" + "RA-03(1)": [ + "RSK-09.1" ], - "SA-11(CE-6)": [ - "TDA-09", - "VPM-01.1" + "CA-07(4)": [ + "RSK-11" ], - "SA-4(CE-8)": [ - "TDA-09.1" + "PM-07": [ + "SEA-02" ], - "SA-11(CE-1)": [ - "TDA-09.2" + "SC-39": [ + "SEA-04" ], - "SA-11(CE-4)": [ - "TDA-09.7" + "AC-08": [ + "SEA-18" ], - "SA-3(CE-2)": [ - "TDA-10" + "AT-03": [ + "SAT-03" ], - "SA-3(CE-2).a": [ - "TDA-10" + "PE-01-SID": [ + "SAT-03" ], - "SA-3(CE-2).b": [ - "TDA-10" + "AT-04": [ + "SAT-04" ], - "SR-11": [ - "TDA-11" + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "SR-11(CE-1)": [ - "TDA-11.1" + "SA-11": [ + "TDA-09" ], "SA-10": [ "TDA-14" ], - "SA-10(CE-1)": [ - "TDA-14.1" - ], - "SA-10(CE-3)": [ - "TDA-14.2" - ], "SA-22": [ "TDA-17", "TDA-17.1" ], - "SI-11": [ - "TDA-19" - ], - "1.9.3": [ - "TPM-01" - ], - "SR-2(CE-1)": [ - "TPM-03" - ], - "SR-3(CE-2)": [ - "TPM-03.2" + "SR-05": [ + "TPM-03.1" ], - "SR-3": [ + "SR-03": [ "TPM-03.3" ], - "2.C.9": [ - "TPM-04" - ], - "2.C.9-1": [ - "TPM-04" - ], - "2.C.9-2": [ - "TPM-04" - ], - "2.C.9-3": [ - "TPM-04" - ], - "2.C.9-4": [ - "TPM-04" - ], - "2.C.9-5": [ - "TPM-04" - ], - "2.C.9-6": [ + "SA-09": [ "TPM-04" ], - "2.C.9-7": [ - "TPM-04" + "SR-08": [ + "TPM-05.1" ], - "2.C.9-7.1": [ - "TPM-04" + "PM-16": [ + "THR-01" ], - "2.C.9-7.2": [ - "TPM-04" + "AT-02(2)": [ + "THR-05" ], - "2.C.9-8": [ - "TPM-04" + "RA-05(11)": [ + "THR-06" ], - "2.C.9-9": [ - "TPM-04" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "2.C.9-10": [ - "TPM-04" + "RA-05-SID": [ + "VPM-06" ], - "SA-4(IRS-Defined)-1": [ - "TPM-04" + "RA-05(2)": [ + "VPM-06.1" ], - "SA-4(IRS-Defined)-2": [ - "TPM-04" + "CA-08": [ + "VPM-07" ], - "SA-9": [ - "TPM-04" + "CA-08-SID": [ + "VPM-07" + ] + }, + "usa-state-tx-sb820-2019": { + "11.175(b)": [ + "GOV-02" ], - "2.C.10": [ - "TPM-04.1" + "11.175(b)(1)": [ + "GOV-02" ], - "SA-9(CE-1)": [ - "TPM-04.1" + "11.175(b)(2)": [ + "GOV-02" ], - "SA-9(CE-1).a": [ - "TPM-04.1" + "11.175(d)": [ + "GOV-04" ], - "SA-9(CE-1).b": [ - "TPM-04.1" + "11.175(c)": [ + "CPL-01" ], - "SA-9(CE-2)": [ - "TPM-04.2" + "11.175(e)": [ + "IRO-10" ], - "3.3.1.g": [ - "TPM-05" + "11.175(f)": [ + "IRO-10" + ] + }, + "usa-state-tx-sb2610-2025": { + "542.004(a)(1)": [ + "GOV-01" ], - "SA-4(CE-12).b": [ - "TPM-05" + "542.004(a)(4)(A)": [ + "CPL-01" ], - "SR-3(CE-3)": [ - "TPM-05", - "TPM-05.2" + "542.004(a)(4)(B)": [ + "CPL-01" ], - "SR-6": [ - "TPM-08" + "542.004(a)(4)(C)": [ + "CPL-01" ], - "PM-12": [ - "THR-04" + "542.004(b)": [ + "CPL-01" ], - "AT-2(CE-2)": [ - "THR-05" + "542.004(b)(2)": [ + "CPL-01" ], - "RA-5(IRS-Defined)": [ - "VPM-01" + "542.004(b)(2)(A)": [ + "CPL-01" ], - "SI-2(CE-4)": [ - "VPM-05", - "VPM-05.1", - "VPM-05.2", - "VPM-05.4" + "542.004(b)(2)(B)": [ + "CPL-01" ], - "SI-2(IRS-Defined)": [ - "VPM-05" + "542.004(b)(2)(C)": [ + "CPL-01" ], - "SI-2(CE-2)": [ - "VPM-05.2" + "542.004(b)(2)(D)": [ + "CPL-01" ], - "SI-2(CE-3)": [ - "VPM-05.3" + "542.004(b)(3)": [ + "CPL-01" ], - "SI-2(CE-3).a": [ - "VPM-05.3" + "542.004(c)": [ + "CPL-01" ], - "SI-2(CE-3).b": [ - "VPM-05.3" + "542.002": [ + "CPL-01.2" ], - "SI-2(CE-5)": [ - "VPM-05.4" + "542.002(1)": [ + "CPL-01.2" ], - "SI-2(CE-6)": [ - "VPM-05.5" + "542.002(2)": [ + "CPL-01.2" ], - "RA-5": [ - "VPM-06", - "VPM-06.1" + "542.004(a)(2)": [ + "CPL-01.3" ], - "RA-5(CE-2)": [ - "VPM-06.1" + "542.004(b)(1)": [ + "CPL-01.3" ], - "RA-5(CE-5)": [ - "VPM-06.3" + "542.004(b)(1)(A)": [ + "CPL-01.3" ], - "RA-5(CE-4)": [ - "VPM-06.8" + "542.004(b)(1)(B)": [ + "CPL-01.3" ], - "CA-8": [ - "VPM-07" + "542.004(b)(1)(C)": [ + "CPL-01.3" ], - "3.3.8": [ - "WEB-01" + "542.004(b)(1)(D)": [ + "CPL-01.3" ], - "3.3.8.c": [ - "WEB-01" + "542.004(b)(1)(E)": [ + "CPL-01.3" ], - "3.3.8.a": [ - "WEB-02" + "542.004(b)(1)(F)": [ + "CPL-01.3" ], - "SC-7(CE-17)": [ - "WEB-03" - ] - }, - "usa-federal-cms-marse-2-0": { - "PM-1": [ - "GOV-01", - "GOV-02", - "GOV-03" + "542.004(b)(1)(G)": [ + "CPL-01.3" ], - "PM-1.a": [ - "GOV-01" + "542.004(b)(1)(H)": [ + "CPL-01.3" ], - "PM-1.a.1": [ - "GOV-01" + "542.004(b)(1)(I)": [ + "CPL-01.3" ], - "PM-1.a.2": [ - "GOV-01" + "542.004(b)(1)(J)": [ + "CPL-01.3" ], - "PM-1.a.3": [ - "GOV-01" + "542.004(a)(3)(A)": [ + "DCH-01.2" ], - "PM-1.a.4": [ - "GOV-01" + "542.004(a)(3)(B)": [ + "DCH-01.2" ], - "PM-1.b": [ - "GOV-01" + "542.004(a)(3)(C)": [ + "DCH-01.2" ], - "PM-1.c": [ - "GOV-01" + "542.001(1)": [ + "SEA-02.1" ], - "PM-1.d": [ - "GOV-01" + "542.001(2)": [ + "SEA-02.1" ], - "AC-1": [ + "542.001(3)": [ + "SEA-02.1" + ] + }, + "usa-state-tx-txramp-2-0-level-1": { + "AC-01": [ "GOV-02", "GOV-03", "IAC-01" ], - "AC-1.a": [ - "GOV-02" - ], - "AT-1": [ + "AT-01": [ "GOV-02", "GOV-03", "SAT-01" ], - "AT-1.a": [ - "GOV-02" - ], - "AT-1.c": [ - "GOV-02" - ], - "AT-1.d": [ - "GOV-02" - ], - "AU-1": [ + "AU-01": [ "GOV-02", "GOV-03", "MON-01" ], - "AU-1.a": [ - "GOV-02" - ], - "CA-1": [ + "CA-01": [ "GOV-02", "GOV-03", "IAO-01" ], - "CA-1.a": [ - "GOV-02" - ], - "CA-1.c": [ - "GOV-02" - ], - "CM-1": [ + "CM-01": [ "GOV-02", "GOV-03", "CFG-01" ], - "CM-1.a": [ - "GOV-02" - ], - "CP-1": [ + "CP-01": [ "GOV-02", "GOV-03", "BCD-01" ], - "CP-1.a": [ - "GOV-02" - ], - "IA-1": [ + "IA-01": [ "GOV-02", "GOV-03", "IAC-01" ], - "IA-1.a": [ - "GOV-02" - ], - "IR-1": [ + "IR-01": [ "GOV-02", "GOV-03", "IRO-01", "IRO-04.2", "IRO-13" ], - "IR-1.a": [ - "GOV-02" - ], - "MA-1": [ + "MA-01": [ "GOV-02", "GOV-03", "MNT-01", "MNT-05.1", "MNT-05.2" ], - "MA-1.a": [ - "GOV-02" - ], - "MP-1": [ + "MP-01": [ "GOV-02", "GOV-03", "DCH-01" ], - "MP-1.a": [ - "GOV-02" - ], - "MP-1-IS.1": [ - "GOV-02" - ], - "PE-1": [ + "PE-01": [ "GOV-02", "GOV-03", "PES-01" ], - "PE-1.a": [ - "GOV-02" - ], - "PL-1": [ + "PL-01": [ "GOV-02", "GOV-03", "CPL-01", "PRM-01", "TDA-01" ], - "PL-1.a": [ - "GOV-02" - ], - "PS-1": [ + "PS-01": [ "GOV-02", "GOV-03", "HRS-01" ], - "PS-1.a": [ - "GOV-02" - ], - "RA-1": [ + "RA-01": [ "GOV-02", "GOV-03", "RSK-01" ], - "SA-1": [ + "SA-01": [ "GOV-02", "GOV-03", "TDA-01", "TDA-06" ], - "SA-1.a": [ - "GOV-02" - ], - "SC-1": [ + "SC-01": [ "GOV-02", "GOV-03", "NET-01", "SEA-01" ], - "SC-1.a": [ - "GOV-02" - ], - "SI-1": [ + "SI-01": [ "GOV-02", "GOV-03", "SEA-01" ], - "SI-1.a": [ - "GOV-02" - ], - "PM-2": [ - "GOV-04" - ], - "PM-6": [ - "GOV-04", - "GOV-05" - ], - "IR-6": [ + "IR-06": [ "GOV-06", "IRO-10", "IRO-14" ], - "PM-15": [ - "GOV-07", - "THR-01" - ], - "PM-15.a": [ - "GOV-07" - ], - "PM-15.b": [ - "GOV-07" - ], - "PM-15.c": [ - "GOV-07" - ], - "PM-5": [ - "AST-01", - "AST-02" - ], - "CM-8": [ + "CM-08": [ "AST-02", "AST-02.3" ], - "CM-8.a": [ - "AST-02" - ], - "CM-8.a.1": [ - "AST-02" - ], - "CM-8.a.2": [ - "AST-02" - ], - "CM-8.a.3": [ - "AST-02" - ], - "CM-8.a.4": [ - "AST-02" - ], - "CM-8.b": [ - "AST-02" - ], - "CM-8-IS.1": [ - "AST-02" - ], - "CM-8-IS.2": [ - "AST-02" - ], - "CM-8(1)": [ - "AST-02.1" - ], - "CM-8(3)": [ - "AST-02.2", - "CFG-05.1", - "END-03.1" - ], - "CM-8(3).a": [ - "AST-02.2" - ], - "CM-8(3).b": [ - "AST-02.2" - ], - "CM-8(3)-IS": [ - "AST-02.2" - ], - "CM-8(3)-IS.1": [ - "AST-02.2" - ], - "CM-8(3)-IS.2": [ - "AST-02.2" - ], - "CM-8(5)": [ - "AST-02.3" - ], - "PL-2": [ + "PL-02": [ "AST-04", "IAO-03", "IAO-03.1" ], - "SA-4(1)": [ - "AST-04", - "TDA-04.1" - ], - "SA-4(2)": [ - "AST-04", - "TDA-04.1", - "TDA-20" - ], - "SA-5": [ + "SA-05": [ "AST-04.1", "TDA-04" ], - "SC-19": [ - "AST-21" - ], - "SC-19.a": [ - "AST-21" - ], - "SC-19.b": [ - "AST-21" - ], - "CP-2": [ - "BCD-01", - "BCD-01.7", - "BCD-06" - ], - "CP-2.a.1": [ - "BCD-01" - ], - "CP-2.a.2": [ - "BCD-01" - ], - "CP-2.a.3": [ - "BCD-01" - ], - "CP-2.a.4": [ - "BCD-01" - ], - "CP-2.a.5": [ - "BCD-01" - ], - "CP-2.a.6": [ - "BCD-01" - ], - "CP-2.b": [ - "BCD-01" - ], - "CP-2.c": [ - "BCD-01" - ], - "CP-2.d": [ - "BCD-01" - ], - "CP-2.e": [ + "CP-02": [ "BCD-01", "BCD-06" ], - "CP-2.f": [ - "BCD-01" - ], - "CP-2.g": [ - "BCD-01" - ], - "CP-2-IS.1": [ - "BCD-01" - ], "CP-10": [ "BCD-01", "BCD-01.4", "BCD-12" ], - "PM-8": [ - "BCD-01", - "CPL-01" - ], - "CP-2(1)": [ - "BCD-01.1" - ], - "CP-2.a": [ - "BCD-01.7" - ], - "CP-2(8)": [ - "BCD-02" - ], - "CP-2(3)": [ - "BCD-02.1" - ], - "CP-3": [ - "BCD-03" - ], - "CP-3.a": [ - "BCD-03" - ], - "CP-3.b": [ - "BCD-03" - ], - "CP-3.c": [ + "CP-03": [ "BCD-03" ], - "CP-4": [ + "CP-04": [ "BCD-04", "BCD-05" ], - "CP-4.a": [ - "BCD-04" - ], - "CP-4.b": [ - "BCD-04" - ], - "CP-4.c": [ - "BCD-04" - ], - "CP-4-IS.1": [ - "BCD-04" - ], - "CP-4(1)": [ - "BCD-04.1" - ], - "CP-6": [ - "BCD-08" - ], - "CP-6.a": [ - "BCD-08" - ], - "CP-6.b": [ - "BCD-08" - ], - "CP-6(1)": [ - "BCD-08.1" - ], - "CP-6(3)": [ - "BCD-08.2" - ], - "CP-7": [ - "BCD-09" - ], - "CP-7.a": [ - "BCD-09" - ], - "CP-7.b": [ - "BCD-09" - ], - "CP-7.c": [ - "BCD-09" - ], - "CP-7-IS.1": [ - "BCD-09" - ], - "CP-7(1)": [ - "BCD-09.1" - ], - "CP-7(2)": [ - "BCD-09.2" - ], - "CP-7(3)": [ - "BCD-09.3" - ], - "CP-8": [ - "BCD-10" - ], - "CP-8-IS.a": [ - "BCD-10" - ], - "CP-8-IS.b": [ - "BCD-10" - ], - "CP-8(2)": [ - "BCD-10" - ], - "CP-8(1)": [ - "BCD-10.1" - ], - "CP-8(1).a": [ - "BCD-10.1" - ], - "CP-8(1).b": [ - "BCD-10.1" - ], - "CP-9": [ - "BCD-11" - ], - "CP-9.a": [ - "BCD-11" - ], - "CP-9.b": [ - "BCD-11" - ], - "CP-9.c": [ - "BCD-11" - ], - "CP-9.d": [ - "BCD-11" - ], - "CP-9-IS.1": [ - "BCD-11" - ], - "CP-9-IS.2": [ - "BCD-11" - ], - "CP-9-IS.3": [ - "BCD-11" - ], - "CP-9-IS.4": [ + "CP-09": [ "BCD-11" ], - "CP-9(1)": [ - "BCD-11.1" - ], - "CP-9(1)-IS.1": [ - "BCD-11.1" - ], - "CP-10-IS.1": [ - "BCD-12" - ], - "CP-10-IS.1.a": [ - "BCD-12" - ], - "CP-10-IS.1.b": [ - "BCD-12" - ], - "CP-10-IS.1.c": [ - "BCD-12", - "CFG-02" - ], - "CP-10-IS.1.d": [ - "BCD-12" - ], - "CP-10-IS.1.e": [ - "BCD-12" - ], - "SC-5": [ + "SC-05": [ "CAP-01", "CAP-02", "CAP-03", "NET-02.1" ], - "SC-6": [ - "CAP-02" - ], - "CP-2(2)": [ - "CAP-03" - ], - "CM-3": [ - "CHG-01", - "CHG-02" - ], - "CM-3.e": [ - "CHG-01", - "DCH-18" - ], - "CM-3.f": [ - "CHG-01" - ], - "CM-3.g": [ - "CHG-01" - ], - "CM-1-IS.3": [ - "CHG-02" - ], - "CM-3.a": [ - "CHG-02" - ], - "CM-3.b": [ - "CHG-02" - ], - "CM-3.c": [ - "CHG-02" - ], - "CM-3.d": [ - "CHG-02" - ], - "CM-3-IS.1": [ - "CHG-02" - ], - "CM-3-IS.2": [ - "CHG-02" - ], - "CM-3(2)": [ - "CHG-02.2", - "CHG-06" - ], - "CM-4": [ - "CHG-03" - ], - "CM-4-IS.1": [ + "CM-04": [ "CHG-03" ], - "CM-5": [ + "CM-05": [ "CHG-04", "END-03.2" ], - "CM-5(1)": [ - "CHG-04.1" - ], - "AC-5": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" - ], - "CM-5(5)": [ - "CHG-04.4" - ], - "CM-5(5).a": [ - "CHG-04.4" - ], - "CM-5(5).b": [ - "CHG-04.4" - ], - "CM-3-IS.3": [ - "CHG-05" - ], - "CM-9": [ - "CHG-05", - "CFG-01" - ], - "SI-6": [ - "CHG-06" - ], - "SI-6.a": [ - "CHG-06" - ], - "SI-6.b": [ - "CHG-06" - ], - "SI-6.c": [ - "CHG-06" - ], - "SI-6.d": [ - "CHG-06" - ], - "SA-9(5)": [ - "CLD-09", - "DCH-19", - "TPM-04.4" - ], - "CA-7-IS.2": [ - "CPL-01.5", - "CPL-02" - ], - "CA-7": [ - "CPL-02" - ], - "CA-7.1": [ - "CPL-02" - ], - "CA-7.2": [ - "CPL-02" - ], - "CA-7.3": [ - "CPL-02" - ], - "CA-7.4": [ - "CPL-02" - ], - "CA-7.5": [ - "CPL-02" - ], - "CA-7.6": [ - "CPL-02" - ], - "CA-7.7": [ - "CPL-02" - ], - "CA-7.8": [ - "CPL-02" - ], - "CA-7-IS": [ - "CPL-02" - ], - "CA-7-IS.1": [ - "CPL-02" - ], - "CA-7-IS.3": [ + "CA-07": [ "CPL-02" ], - "CA-7(1)": [ - "CPL-02", - "CPL-03.1" - ], - "PM-14": [ - "CPL-02", - "PRI-08" - ], - "CA-2": [ + "CA-02": [ "CPL-03", "CPL-03.2", "IAO-02", "IAO-06", "PRM-04" ], - "RA-3": [ + "RA-03": [ "CPL-03.2", "RSK-04" ], - "CM-1-IS": [ - "CFG-01" - ], - "CM-1-IS.1": [ - "CFG-01" - ], - "CM-9.a": [ - "CFG-01" - ], - "CM-9.b": [ - "CFG-01" - ], - "CM-9.c": [ - "CFG-01" - ], - "CM-9.d": [ - "CFG-01" - ], - "AC-3-IS.1": [ - "CFG-02" - ], - "AC-3-IS.2": [ - "CFG-02" - ], - "AC-3-IS.3": [ - "CFG-02" - ], - "AC-3-IS.4": [ - "CFG-02" - ], - "AC-6-IS.5": [ - "CFG-02" - ], - "AC-8-IS.1": [ - "CFG-02" - ], - "AC-8-IS.2": [ - "CFG-02" - ], - "AC-8-IS.3": [ - "CFG-02" - ], - "AC-17-IS.2": [ - "CFG-02" - ], - "AC-18-IS.1": [ - "CFG-02" - ], - "AC-18-IS.1.a": [ - "CFG-02" - ], - "AC-18-IS.1.b": [ - "CFG-02" - ], - "AC-18-IS.1.c": [ - "CFG-02" - ], - "AC-18-IS.1.d": [ - "CFG-02" - ], - "AC-18-IS.1.e": [ - "CFG-02" - ], - "AC-18-IS.1.f": [ - "CFG-02" - ], - "AC-18-IS.1.g": [ - "CFG-02" - ], - "AC-18-IS.1.h": [ - "CFG-02" - ], - "AC-18-IS.1.i": [ - "CFG-02" - ], - "AC-18-IS.1.j": [ - "CFG-02" - ], - "AC-18-IS.1.k": [ - "CFG-02" - ], - "AC-18-IS.1.l": [ - "CFG-02" - ], - "AC-19-IS.2": [ - "CFG-02" - ], - "AC-19(5)-IS": [ - "CFG-02" - ], - "AU-2-IS.1": [ - "CFG-02" - ], - "AU-2-IS.1.a": [ - "CFG-02" - ], - "AU-2-IS.1.b": [ - "CFG-02" - ], - "AU-2-IS.1.c": [ - "CFG-02" - ], - "AU-2-IS.1.d": [ - "CFG-02" - ], - "AU-2-IS.1.e": [ - "CFG-02" + "CM-02": [ + "CFG-02", + "CFG-02.1" ], - "AU-2-IS.1.f": [ - "CFG-02" + "CM-06": [ + "CFG-02", + "CFG-02.7" ], - "AU-2-IS.1.g": [ - "CFG-02" + "CM-07": [ + "CFG-03" ], - "AU-2-IS.1.h": [ - "CFG-02" + "CM-10": [ + "CFG-04" ], - "AU-2-IS.1.i": [ - "CFG-02" + "CM-11": [ + "CFG-05", + "END-03" ], - "AU-2-IS.1.j": [ - "CFG-02" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "AU-2-IS.1.k": [ - "CFG-02" + "AU-02": [ + "MON-01.8", + "MON-02" ], - "AU-2-IS.1.l": [ - "CFG-02" + "AU-06": [ + "MON-02", + "MON-02.6" ], - "AU-2-IS.1.m": [ - "CFG-02" + "AU-03": [ + "MON-03" ], - "AU-2-IS.1.n": [ - "CFG-02" + "AU-04": [ + "MON-04" ], - "AU-2-IS.1.o": [ - "CFG-02" + "AU-05": [ + "MON-05" ], - "AU-2-IS.1.p": [ - "CFG-02" + "AU-12": [ + "MON-06" ], - "AU-2-IS.1.q": [ - "CFG-02" + "AU-08": [ + "MON-07", + "SEA-20" ], - "AU-2-IS.1.r": [ - "CFG-02" + "AU-09": [ + "MON-08" ], - "AU-2-IS.1.s": [ - "CFG-02" + "AU-11": [ + "MON-10" ], - "AU-2-IS.1.t": [ - "CFG-02" + "IA-07": [ + "CRY-02", + "IAC-12" ], - "AU-2-IS.1.u": [ - "CFG-02" + "AC-18": [ + "CRY-07", + "NET-15" ], - "AU-2-IS.1.v": [ - "CFG-02" + "SC-12": [ + "CRY-08" ], - "AU-2-IS.1.w": [ - "CFG-02" + "MP-02": [ + "DCH-03", + "END-01" ], - "AU-2-IS.1.x": [ - "CFG-02" + "MP-06": [ + "DCH-08", + "DCH-09", + "DCH-09.3" ], - "AU-2-IS.1.y": [ - "CFG-02" + "MP-07": [ + "DCH-10", + "DCH-10.2", + "DCH-18" ], - "AU-2-IS.2": [ - "CFG-02" + "AC-20": [ + "DCH-13" ], - "AU-2-IS.2.a": [ - "CFG-02" + "SI-12": [ + "DCH-18", + "PRI-05" ], - "AU-2-IS.2.b": [ - "CFG-02" + "SI-03": [ + "END-04", + "END-04.1", + "END-04.4", + "NET-12", + "TDA-18", + "VPM-01", + "VPM-05" ], - "AU-2-IS.2.c": [ - "CFG-02" + "SI-02": [ + "END-04.1", + "VPM-01", + "VPM-05" ], - "AU-2-IS.2.d": [ - "CFG-02" + "PS-02": [ + "HRS-02", + "HRS-03.2" ], - "AU-2-IS.2.e": [ - "CFG-02" + "PS-03": [ + "HRS-04" ], - "AU-2-IS.2.f": [ - "CFG-02" + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "AU-2-IS.2.g": [ - "CFG-02" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "AU-2-IS.2.h": [ - "CFG-02" + "PS-08": [ + "HRS-07" ], - "AU-2-IS.3": [ - "CFG-02" + "PS-05": [ + "HRS-08" ], - "AU-8(1)-IS.2": [ - "CFG-02" + "PS-04": [ + "HRS-09" ], - "AU-8(1)-IS.3": [ - "CFG-02" + "PS-07": [ + "HRS-10" ], - "CM-2": [ - "CFG-02", - "CFG-02.1" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "CM-6": [ - "CFG-02", - "CFG-02.7" + "IA-02": [ + "IAC-02" ], - "CM-6.a": [ - "CFG-02" + "IA-08": [ + "IAC-03" ], - "CM-6.b": [ - "CFG-02" + "IA-02 (01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "CM-6-IS.2": [ - "CFG-02" + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "CM-6-IS.3": [ - "CFG-02" + "IA-05": [ + "IAC-10", + "IAC-10.8" ], - "CM-7-IS.2": [ - "CFG-02" + "IA-05 (01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "IA-2(11)-IS": [ - "CFG-02" + "IA-06": [ + "IAC-11" ], - "SA-8": [ - "CFG-02", - "SEA-01" + "IA-11": [ + "IAC-14" ], - "SA-11-IS.2": [ - "CFG-02" + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "CM-2(1)": [ - "CFG-02.1" + "AC-07": [ + "IAC-22" ], - "CM-2(1).a": [ - "CFG-02.1" + "AC-14": [ + "IAC-26" ], - "CM-2(1).b": [ - "CFG-02.1" + "IR-04": [ + "IRO-02" ], - "CM-2(1).c": [ - "CFG-02.1" + "IR-08": [ + "IRO-04" ], - "CM-2(1).d": [ - "CFG-02.1" + "IR-02": [ + "IRO-05" ], - "CM-1-IS.2": [ - "CFG-02.2" + "IR-05": [ + "IRO-09" ], - "CM-6.d": [ - "CFG-02.2" + "IR-07": [ + "IRO-11" ], - "CM-6(1)": [ - "CFG-02.2" + "CA-05": [ + "IAO-05" ], - "CM-2(3)": [ - "CFG-02.3" + "CA-06": [ + "IAO-07" ], - "CM-6.c": [ - "CFG-02.7" + "MA-02": [ + "MNT-02" ], - "CM-6-IS.1": [ - "CFG-02.9" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "CM-6-IS.1.a": [ - "CFG-02.9" + "MA-05": [ + "MNT-06" ], - "CM-6-IS.1.b": [ - "CFG-02.9" + "AC-19": [ + "MDM-02" ], - "CM-6-IS.1.c": [ - "CFG-02.9" + "SC-07": [ + "NET-03" ], - "CM-6-IS.1.d": [ - "CFG-02.9" + "CA-03": [ + "NET-05" ], - "CM-7": [ - "CFG-03" + "CA-09": [ + "NET-05.2" ], - "CM-7.a": [ - "CFG-03" + "SC-20": [ + "NET-10" ], - "CM-7.b": [ - "CFG-03" + "SC-22": [ + "NET-10.1" ], - "CM-7-IS.1": [ - "CFG-03" + "SC-21": [ + "NET-10.2" ], - "CM-7(1)": [ - "CFG-03.1" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "CM-7(1).a": [ - "CFG-03.1" + "AC-17": [ + "NET-14" ], - "CM-7(1).b": [ - "CFG-03.1" + "PE-02": [ + "PES-02" ], - "CM-7(2)": [ - "CFG-03.2", - "SEA-06" + "PE-03": [ + "PES-03" ], - "CM-7(4)": [ - "CFG-03.3" + "PE-08": [ + "PES-03.3" ], - "CM-7(4).a": [ - "CFG-03.3" + "PE-06": [ + "PES-05" ], - "CM-7(4).b": [ - "CFG-03.3" + "PE-15": [ + "PES-07.5" ], - "CM-7(4).c": [ - "CFG-03.3" + "PE-13": [ + "PES-08" ], - "SC-7(7)": [ - "CFG-03.4" + "PE-14": [ + "PES-09" ], - "CM-10": [ - "CFG-04" + "PE-16": [ + "PES-10" ], - "CM-10.a": [ - "CFG-04" + "SA-03": [ + "PRM-07", + "SEA-07.1" ], - "CM-10.b": [ - "CFG-04" + "RA-02": [ + "RSK-02" ], - "CM-10.c": [ - "CFG-04" + "RA-07": [ + "RSK-06.1" ], - "CM-10(1)": [ - "CFG-04.1" + "CA-07 (04)": [ + "RSK-11" ], - "CM-10(1).a": [ - "CFG-04.1" + "SC-39": [ + "SEA-04" ], - "CM-10(1).b": [ - "CFG-04.1" + "AT-02": [ + "SAT-02" ], - "CM-10(1).c": [ - "CFG-04.1" + "AT-03": [ + "SAT-03" ], - "CM-11": [ - "CFG-05", - "END-03" + "AT-04": [ + "SAT-04" ], - "CM-11.a": [ - "CFG-05" + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "CM-11.b": [ - "CFG-05" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "CM-11.c": [ - "CFG-05" + "SA-09": [ + "TPM-04" ], - "SI-4": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "SI-4.a": [ - "MON-01" + "RA-05 (02)": [ + "VPM-06.1" + ] + }, + "usa-state-tx-txramp-2-0-level-2": { + "AC-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "SI-4.a.1": [ - "MON-01" + "AT-01": [ + "GOV-02", + "GOV-03", + "SAT-01" ], - "SI-4.a.2": [ + "AU-01": [ + "GOV-02", + "GOV-03", "MON-01" ], - "SI-4.b": [ - "MON-01" + "CA-01": [ + "GOV-02", + "GOV-03", + "IAO-01" ], - "SI-4.c": [ - "MON-01" + "CM-01": [ + "GOV-02", + "GOV-03", + "CFG-01" ], - "SI-4.d": [ - "MON-01" + "CP-01": [ + "GOV-02", + "GOV-03", + "BCD-01" ], - "SI-4.e": [ - "MON-01" + "IA-01": [ + "GOV-02", + "GOV-03", + "IAC-01" ], - "SI-4.f": [ - "MON-01" + "IR-01": [ + "GOV-02", + "GOV-03", + "IRO-01", + "IRO-04.2", + "IRO-13" ], - "SI-4.g": [ - "MON-01" + "MA-01": [ + "GOV-02", + "GOV-03", + "MNT-01", + "MNT-05.1", + "MNT-05.2" ], - "SI-4.g.1": [ - "MON-01" + "MP-01": [ + "GOV-02", + "GOV-03", + "DCH-01" ], - "SI-4.g.2": [ - "MON-01" + "PE-01": [ + "GOV-02", + "GOV-03", + "PES-01" ], - "SI-4.h": [ - "MON-01" + "PL-01": [ + "GOV-02", + "GOV-03", + "CPL-01", + "PRM-01", + "TDA-01" ], - "SI-4.i": [ - "MON-01" + "PS-01": [ + "GOV-02", + "GOV-03", + "HRS-01" ], - "SI-4.j": [ - "MON-01" + "RA-01": [ + "GOV-02", + "GOV-03", + "RSK-01" ], - "SI-4.k": [ - "MON-01" + "SA-01": [ + "GOV-02", + "GOV-03", + "TDA-01" ], - "SI-4-IS.1": [ - "MON-01" + "SC-01": [ + "GOV-02", + "GOV-03", + "NET-01", + "SEA-01" ], - "SI-4(1)": [ - "MON-01.1" + "SI-01": [ + "GOV-02", + "GOV-03", + "SEA-01" ], - "SI-4(2)": [ - "MON-01.2" + "IR-06": [ + "GOV-06", + "IRO-10", + "IRO-14" ], - "SI-4(4)": [ - "MON-01.3" + "CM-08": [ + "AST-02", + "AST-02.3" ], - "SI-4(5)": [ - "MON-01.4" + "CM-08 (01)": [ + "AST-02.1" ], - "SI-4(5).a": [ - "MON-01.4" + "PL-02": [ + "AST-04", + "IAO-03", + "IAO-03.1" ], - "SI-4(5).b": [ - "MON-01.4" + "SA-04 (01)": [ + "AST-04", + "TDA-04.1" ], - "SI-4(5).c": [ - "MON-01.4" + "SA-04 (02)": [ + "AST-04", + "TDA-04.1", + "TDA-20" ], - "SI-4(5).d": [ - "MON-01.4" + "SA-05": [ + "AST-04.1", + "TDA-04" ], - "SI-4(14)": [ - "MON-01.5" + "CP-02": [ + "BCD-01", + "BCD-06" ], - "AU-2": [ - "MON-01.8", - "MON-02" + "CP-10": [ + "BCD-01", + "BCD-01.4", + "BCD-12" ], - "AU-6-IS.1": [ - "MON-01.8" + "CP-03": [ + "BCD-03" ], - "AU-6-IS.2": [ - "MON-01.8" + "CP-04": [ + "BCD-04", + "BCD-05" ], - "AU-6-IS.3": [ - "MON-01.8" + "CP-06": [ + "BCD-08" ], - "AU-6-IS.4": [ - "MON-01.8" + "CP-07": [ + "BCD-09" ], - "AU-6-IS.5": [ - "MON-01.8" + "CP-08": [ + "BCD-10" ], - "AU-6-IS.6": [ - "MON-01.8" + "CP-09": [ + "BCD-11" ], - "AU-6-IS.7": [ - "MON-01.8" + "CP-09 (01)": [ + "BCD-11.1" ], - "AU-2.a": [ - "MON-02" + "CP-09 (08)": [ + "BCD-11.4" ], - "AU-2.b": [ - "MON-02" + "SC-28 (01)": [ + "BCD-11.4", + "CRY-04", + "CRY-05", + "DCH-07.2" ], - "AU-2.c": [ - "MON-02" + "SC-05": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" ], - "AU-6": [ - "MON-02", - "MON-02.6" + "CM-03": [ + "CHG-01", + "CHG-02" ], - "AU-6.a": [ - "MON-02" + "CM-03 (02)": [ + "CHG-02.2", + "CHG-06" ], - "AU-6(3)": [ - "MON-02.1" + "CM-03 (04)": [ + "CHG-02.3" ], - "AU-6.b": [ - "MON-02.6" + "CM-04": [ + "CHG-03" ], - "AU-12(1)": [ - "MON-02.7" + "CM-05": [ + "CHG-04", + "END-03.2" ], - "AU-3": [ - "MON-03" + "AC-05": [ + "CHG-04.3" ], - "AU-3(1).a": [ - "MON-03" + "CM-05 (05)": [ + "CHG-04.4" ], - "AU-3(1).b": [ - "MON-03" + "CM-09": [ + "CHG-05", + "CFG-01" ], - "AU-3(1).c": [ - "MON-03" + "SA-09 (05)": [ + "CLD-09", + "DCH-19", + "TPM-04.4" ], - "AU-3(1)-IS.1": [ - "MON-03" + "CA-07": [ + "CPL-02" ], - "AU-3(1)-IS.1.a": [ - "MON-03" + "CA-02": [ + "CPL-03", + "CPL-03.2", + "IAO-02", + "IAO-06", + "PRM-04" ], - "AU-3(1)-IS.1.b": [ - "MON-03" + "RA-03": [ + "CPL-03.2", + "RSK-04" ], - "AU-3(1)-IS.1.c": [ - "MON-03" + "CM-02": [ + "CFG-02", + "CFG-02.1" ], - "AU-3(1)-IS.1.d": [ - "MON-03" + "CM-06": [ + "CFG-02", + "CFG-02.7" ], - "AU-3(1)-IS.2": [ - "MON-03" + "SA-08": [ + "CFG-02", + "SEA-01" ], - "AU-3(1)": [ - "MON-03.1" + "CM-02 (03)": [ + "CFG-02.3" ], - "AU-6(1)": [ - "MON-03.1" + "CM-07": [ + "CFG-03" ], - "AU-2(3)": [ - "MON-03.6" + "CM-07 (01)": [ + "CFG-03.1" ], - "AU-2(3)-IS.1": [ - "MON-03.6" + "CM-07 (02)": [ + "CFG-03.2", + "SEA-06" ], - "AU-4": [ - "MON-04" + "CM-07 (05)": [ + "CFG-03.3" ], - "AU-5": [ - "MON-05" + "CM-10": [ + "CFG-04" ], - "AU-5(1)": [ - "MON-05.2" + "CM-11": [ + "CFG-05", + "END-03" ], - "AU-7": [ - "MON-06" + "SI-04": [ + "MON-01", + "MON-02", + "NET-12", + "TDA-18" ], - "AU-7.a": [ - "MON-06" + "SI-04 (04)": [ + "MON-01.3" ], - "AU-7.b": [ - "MON-06" + "AU-02": [ + "MON-01.8", + "MON-02" ], - "AU-7(1)": [ - "MON-06" + "AU-06": [ + "MON-02", + "MON-02.6" ], - "AU-12": [ - "MON-06" + "AU-03": [ + "MON-03" ], - "AU-12.a": [ - "MON-06" + "AU-03 (01)": [ + "MON-03.1" ], - "AU-12.b": [ - "MON-06" + "AU-04": [ + "MON-04" ], - "AU-12.c": [ - "MON-06" + "AU-05": [ + "MON-05" ], - "AU-12-IS": [ + "AU-12": [ "MON-06" ], - "AU-8": [ + "AU-09": [ "MON-07", - "SEA-20" - ], - "AU-8.b": [ - "MON-07" - ], - "AU-9": [ "MON-08" ], - "AU-9(4)": [ - "MON-08.2" - ], - "AU-10": [ - "MON-09" - ], "AU-11": [ "MON-10" ], - "AU-11-IS.1": [ - "MON-10" - ], - "AU-11-IS.2": [ - "MON-10" - ], - "AU-16": [ - "MON-14" + "AC-02 (12)": [ + "MON-16" ], - "SC-8(1)": [ + "SC-08 (01)": [ "CRY-01", "CRY-01.1", "CRY-03" ], - "SC-8(2)": [ - "CRY-01", - "CRY-01.3", - "DCH-10" - ], "SC-13": [ "CRY-01", "CRY-01.2", "CRY-05" ], - "IA-7": [ + "IA-07": [ "CRY-02", "IAC-12" ], - "SC-8": [ + "SC-08": [ "CRY-03", "CRY-04" ], - "SC-8-IS.1": [ - "CRY-04" - ], "SC-28": [ "CRY-05", "END-02" ], - "SC-28-iS": [ - "CRY-05" - ], "AC-18": [ "CRY-07", "NET-15" @@ -214279,252 +230903,47 @@ "SC-17": [ "CRY-08" ], - "SC-12(2)": [ - "CRY-09.1" - ], - "SI-12": [ - "DCH-01", - "DCH-18", - "PRI-05" - ], - "MP-2": [ + "MP-02": [ "DCH-03", "END-01" ], - "AC-3(9)": [ - "DCH-03.3" - ], - "AC-3(9).a": [ - "DCH-03.3" - ], - "AC-3(9).b": [ - "DCH-03.3" - ], - "MP-3": [ + "MP-03": [ "DCH-04", "DCH-04.1" ], - "MP-3.a": [ - "DCH-04" - ], - "MP-3.b": [ - "DCH-04" - ], - "MP-4": [ - "DCH-06" - ], - "MP-4.a": [ - "DCH-06" - ], - "MP-4.b": [ - "DCH-06" - ], - "MP-4-IS.1": [ + "MP-04": [ "DCH-06" ], - "MP-5": [ - "DCH-07" - ], - "MP-5.a": [ - "DCH-07" - ], - "MP-5.b": [ - "DCH-07" - ], - "MP-5.c": [ - "DCH-07" - ], - "MP-5.d": [ - "DCH-07" - ], - "MP-5-IS.1": [ - "DCH-07" - ], - "MP-5-IS.2": [ - "DCH-07" - ], - "MP-5-IS.3": [ - "DCH-07" - ], - "MP-CMS-1": [ - "DCH-07" - ], - "MP-CMS-1-IS.1": [ - "DCH-07" - ], - "MP-CMS-1-IS.1.a": [ - "DCH-07" - ], - "MP-CMS-1-IS.1.b": [ - "DCH-07" - ], - "MP-CMS-1-IS.1.c": [ - "DCH-07" - ], - "MP-CMS-1-IS.1.d": [ - "DCH-07" - ], - "MP-CMS-1-IS.1.e": [ - "DCH-07" - ], - "MP-CMS-1-IS.1.f": [ + "MP-05": [ "DCH-07" ], - "MP-5(4)": [ - "DCH-07.2" - ], - "MP-6": [ + "MP-06": [ "DCH-08", "DCH-09", "DCH-09.3" ], - "MP-6.a": [ - "DCH-09" - ], - "MP-6.b": [ - "DCH-09" - ], - "MP-6-IS.1": [ - "DCH-09" - ], - "MP-6-IS.2": [ - "DCH-09" - ], - "MP-6-IS.4": [ - "DCH-09" - ], - "MP-6-IS.3": [ - "DCH-09.1" - ], - "MP-6-IS.3.a": [ - "DCH-09.1" - ], - "MP-6-IS.3.b": [ - "DCH-09.1" - ], - "MP-6-IS.3.c": [ - "DCH-09.1" - ], - "MP-6-IS.3.d": [ - "DCH-09.1" - ], - "MP-6-IS.3.e": [ - "DCH-09.1" - ], - "MP-6(1)": [ - "DCH-09.1" - ], - "MP-6(1)-IS": [ - "DCH-09.1" - ], - "MP-6(2)": [ - "DCH-09.2" - ], - "MP-7": [ + "MP-07": [ "DCH-10", "DCH-10.2", "DCH-18" ], - "MP-7(1)": [ - "DCH-10.2" - ], "AC-20": [ "DCH-13" ], - "AC-20.a": [ - "DCH-13" - ], - "AC-20.b": [ - "DCH-13" - ], - "AC-20-IS": [ - "DCH-13" - ], - "AC-20-IS.1": [ - "DCH-13" - ], - "AC-20-IS.2": [ - "DCH-13" - ], - "AC-20-IS.3": [ - "DCH-13" - ], - "AC-20(1)": [ - "DCH-13.1" - ], - "AC-20(1).a": [ - "DCH-13.1" - ], - "AC-20(1).b": [ + "AC-20 (01)": [ "DCH-13.1" ], - "AC-20(2)": [ - "DCH-13.2" - ], - "AC-20(2)-IS.a": [ - "DCH-13.2" - ], - "AC-21": [ - "DCH-14", - "PRI-07" - ], - "AC-21.a": [ - "DCH-14" - ], - "AC-21.b": [ - "DCH-14" - ], "AC-22": [ "DCH-15" ], - "AC-22.a": [ - "DCH-15" - ], - "AC-22.b": [ - "DCH-15" - ], - "AC-22.c": [ - "DCH-15" - ], - "AC-22.d": [ - "DCH-15" - ], - "SI-12-IS.1": [ - "DCH-18" - ], - "DM-2": [ - "DCH-21", + "SI-12": [ + "DCH-18", "PRI-05" ], - "DM-2.b": [ - "DCH-21" - ], - "DM-2.c": [ - "DCH-21" - ], - "DI-1": [ - "DCH-22" - ], - "DI-1.a": [ - "DCH-22" - ], - "DI-1.b": [ - "DCH-22" - ], - "DI-1.c": [ - "DCH-22" - ], - "DI-1.d": [ - "DCH-22" - ], - "IP-3": [ - "DCH-22.1", - "PRI-06.1" - ], - "DM-1(1)": [ - "DCH-23" + "CM-12": [ + "DCH-24" ], - "SI-3": [ + "SI-03": [ "END-04", "END-04.1", "END-04.4", @@ -214533,48907 +230952,45101 @@ "VPM-01", "VPM-05" ], - "SI-3.a": [ - "END-04" - ], - "SI-3.b": [ - "END-04" - ], - "SI-3.c": [ - "END-04" - ], - "SI-3.c.1": [ - "END-04" - ], - "SI-3.c.2": [ - "END-04" - ], - "SI-3.d": [ - "END-04" - ], - "SI-2": [ + "SI-02": [ "END-04.1", "VPM-01", "VPM-05" ], - "SI-3(2)": [ - "END-04.1" - ], - "SI-3(1)": [ - "END-04.3" - ], - "SI-7": [ + "SI-07": [ "END-06", "NET-12", "TDA-18" ], - "SI-7(1)": [ + "SI-07 (01)": [ "END-06.1" ], - "SI-7(7)": [ + "SI-07 (07)": [ "END-06.2" ], - "SI-8": [ - "END-08" - ], - "SI-8.a": [ - "END-08" - ], - "SI-8.b": [ - "END-08" - ], - "SI-8(1)": [ - "END-08" - ], - "SI-8(2)": [ - "END-08.2" - ], - "SC-18": [ - "END-10" - ], - "SC-18.a": [ - "END-10" - ], - "SC-18.b": [ - "END-10" - ], - "SC-18.c": [ + "SC-18": [ "END-10" ], "SC-15": [ "END-14" ], - "SC-15.a": [ - "END-14" - ], - "SC-15.b": [ - "END-14" - ], - "SC-7(12)": [ - "END-16.1" - ], - "PS-2": [ + "PS-02": [ "HRS-02", "HRS-03.2" ], - "PS-2.a": [ - "HRS-02" - ], - "PS-2.b": [ - "HRS-02" - ], - "PS-2.c": [ - "HRS-02" + "PS-03": [ + "HRS-04" ], - "PM-13": [ - "HRS-03", - "SAT-01" + "PL-04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.3" ], - "PS-3": [ - "HRS-04" + "PL-04 (01)": [ + "HRS-05.2" ], - "PS-3.a": [ - "HRS-04" + "PS-06": [ + "HRS-06", + "HRS-06.1" ], - "PS-3.b": [ - "HRS-04" + "PS-08": [ + "HRS-07" ], - "PS-3.c": [ - "HRS-04" + "PS-05": [ + "HRS-08" ], - "PS-3-IS.1": [ - "HRS-04" + "PS-04": [ + "HRS-09" ], - "PS-3-IS.2": [ - "HRS-04" + "PS-07": [ + "HRS-10" ], - "PL-4": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "IA-04": [ + "IAC-01.2", + "IAC-09" ], - "PL-4.a": [ - "HRS-05.1" + "IA-04 (04)": [ + "IAC-01.2", + "IAC-09.1", + "IAC-09.2" ], - "PL-4.b": [ - "HRS-05.1" + "IA-02": [ + "IAC-02" ], - "PL-4.c": [ - "HRS-05.1" + "IA-02 (08)": [ + "IAC-02.2" ], - "PL-4.d": [ - "HRS-05.1" + "IA-08": [ + "IAC-03" ], - "PL-4-IS": [ - "HRS-05.1" + "IA-03": [ + "IAC-04" ], - "PL-4(1)": [ - "HRS-05.2" + "IA-02 (01)": [ + "IAC-06", + "IAC-06.1", + "IAC-06.2", + "IAC-06.3", + "IAC-06.4", + "IAC-10.7", + "TDA-02.2" ], - "PS-6": [ - "HRS-06", - "HRS-06.1" + "AC-02": [ + "IAC-07.2", + "IAC-15", + "NET-12", + "TDA-18" ], - "PS-6.a": [ - "HRS-06" + "AC-02 (07)": [ + "IAC-08" ], - "PS-6.b": [ - "HRS-06" + "IA-05": [ + "IAC-10", + "IAC-10.8" ], - "PS-6.c": [ - "HRS-06" + "IA-05 (01)": [ + "IAC-10", + "IAC-10.1", + "IAC-10.4" ], - "PS-6.c.1": [ - "HRS-06" + "IA-05 (02)": [ + "IAC-10.2" ], - "PS-6.c.2": [ - "HRS-06" + "IA-05 (06)": [ + "IAC-10.5", + "IAC-18" ], - "PS-8": [ - "HRS-07" + "IA-05 (07)": [ + "IAC-10.6" ], - "PS-8.a": [ - "HRS-07" + "IA-06": [ + "IAC-11" ], - "PS-8.b": [ - "HRS-07" + "IA-11": [ + "IAC-14" ], - "PS-5": [ - "HRS-08" + "AC-02 (03)": [ + "IAC-15.3" ], - "PS-5.a": [ - "HRS-08" + "AC-02 (09)": [ + "IAC-15.5" ], - "PS-5.b": [ - "HRS-08" + "AC-06 (07)": [ + "IAC-17" ], - "PS-5.b.1": [ - "HRS-08" + "AC-03": [ + "IAC-20", + "NET-12", + "TDA-18" ], - "PS-5.b.2": [ - "HRS-08" + "AC-06": [ + "IAC-20", + "IAC-21" ], - "PS-5.b.3": [ - "HRS-08" + "AC-06 (01)": [ + "IAC-21.1" ], - "PS-5.b.4": [ - "HRS-08" + "AC-06 (02)": [ + "IAC-21.2" ], - "PS-5.c": [ - "HRS-08" + "AC-06 (05)": [ + "IAC-21.3" ], - "PS-5.d": [ - "HRS-08" + "AC-06 (09)": [ + "IAC-21.4" ], - "PS-4": [ - "HRS-09" + "AC-06 (10)": [ + "IAC-21.5" ], - "PS-4.a": [ - "HRS-09" + "AC-07": [ + "IAC-22" ], - "PS-4.b": [ - "HRS-09" + "AC-02 (05)": [ + "IAC-24" ], - "PS-4.c": [ - "HRS-09" + "AC-11": [ + "IAC-24" ], - "PS-4.d": [ - "HRS-09" + "AC-12": [ + "IAC-25" ], - "PS-4.e": [ - "HRS-09" + "AC-14": [ + "IAC-26" ], - "PS-4.f": [ - "HRS-09" + "IR-04": [ + "IRO-02" ], - "PS-4.g": [ - "HRS-09" + "IR-08": [ + "IRO-04" ], - "PS-4-IS.1": [ - "HRS-09" + "IR-02": [ + "IRO-05" ], - "PS-4-IS.2": [ - "HRS-09" + "IR-03": [ + "IRO-06" ], - "PS-7": [ - "HRS-10" + "IR-03 (02)": [ + "IRO-06.1" ], - "PS-7.a": [ - "HRS-10" + "IR-05": [ + "IRO-09" ], - "PS-7.b": [ - "HRS-10" + "IR-07": [ + "IRO-11" ], - "PS-7.c": [ - "HRS-10" + "IR-09": [ + "IRO-12", + "IRO-12.1" ], - "PS-7.d": [ - "HRS-10" + "CA-05": [ + "IAO-05" ], - "PS-7.e": [ - "HRS-10" + "CM-04 (02)": [ + "IAO-06" ], - "PS-7-IS.1": [ - "HRS-10" + "CA-06": [ + "IAO-07" ], - "AC-5.a": [ - "HRS-11" + "MA-02": [ + "MNT-02" ], - "AC-5.b": [ - "HRS-11" + "MA-06": [ + "MNT-03" ], - "AC-5.c": [ - "HRS-11" + "MA-03": [ + "MNT-04" ], - "AC-5-IS.1": [ - "HRS-11" + "MA-03 (01)": [ + "MNT-04.1" ], - "AC-5-IS.2": [ - "HRS-11" + "MA-03 (02)": [ + "MNT-04.2" ], - "AC-5-IS.3": [ - "HRS-11" + "MA-03 (03)": [ + "MNT-04.3" ], - "AC-5-IS.4": [ - "HRS-11" + "MA-04": [ + "MNT-05", + "MNT-05.1", + "MNT-05.2" ], - "AC-5-IS.5": [ - "HRS-11" + "MA-05": [ + "MNT-06" ], - "AC-2-IS.3": [ - "IAC-01.2", - "IAC-15.1" + "AC-19": [ + "MDM-02" ], - "IA-4": [ - "IAC-01.2", - "IAC-09" + "AC-19 (05)": [ + "MDM-03" ], - "IA-2": [ - "IAC-02" + "SC-07": [ + "NET-03" ], - "IA-2-IS.1": [ - "IAC-02" + "SC-07 (03)": [ + "NET-03.1" ], - "IA-2-IS.2": [ - "IAC-02" + "SC-07 (04)": [ + "NET-03.2" ], - "IA-2-IS.3": [ - "IAC-02" + "AC-04": [ + "NET-04" ], - "IA-2(8)": [ - "IAC-02.2" + "SC-07 (05)": [ + "NET-04.1" ], - "IA-8": [ - "IAC-03" + "CA-03": [ + "NET-05" ], - "IA-8-IS": [ - "IAC-03" + "CA-09": [ + "NET-05.2" ], - "IA-3": [ - "IAC-04" + "SC-10": [ + "NET-07" ], - "IA-3-IS.1": [ - "IAC-04" + "SC-23": [ + "NET-09" ], - "IA-2(1)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "SC-20": [ + "NET-10" ], - "IA-2(2)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "SC-22": [ + "NET-10.1" ], - "IA-2(11)": [ - "IAC-06" + "SC-21": [ + "NET-10.2" ], - "IA-2(3)": [ - "IAC-06.3" + "SI-05": [ + "NET-12", + "TDA-18", + "THR-03" ], - "AC-2": [ - "IAC-07.2", - "IAC-15", + "SI-10": [ "NET-12", "TDA-18" ], - "AC-2(7)": [ - "IAC-08" - ], - "AC-2(7).a": [ - "IAC-08" - ], - "AC-2(7).b": [ - "IAC-08" + "AC-17": [ + "NET-14" ], - "AC-2(7).c": [ - "IAC-08" + "AC-17 (01)": [ + "NET-14.1" ], - "AC-2(7).d": [ - "IAC-08" + "AC-17 (02)": [ + "NET-14.2" ], - "IA-4.a": [ - "IAC-09" + "AC-17 (03)": [ + "NET-14.3" ], - "IA-4.b": [ - "IAC-09" + "AC-17 (04)": [ + "NET-14.4" ], - "IA-4.c": [ - "IAC-09" + "AC-17 (09)": [ + "NET-14.8" ], - "IA-4.d": [ - "IAC-09" + "PE-02": [ + "PES-02" ], - "IA-4.e": [ - "IAC-09" + "PE-03": [ + "PES-03" ], - "IA-4-IS.1": [ - "IAC-09" + "PE-08": [ + "PES-03.3" ], - "IA-4-IS.2": [ - "IAC-09" + "PE-06": [ + "PES-05" ], - "IA-5": [ - "IAC-10", - "IAC-10.8" + "PE-06 (01)": [ + "PES-05.1" ], - "IA-5(1)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "PE-09": [ + "PES-07" ], - "IA-5(1).a": [ - "IAC-10.1" + "PE-10": [ + "PES-07.2" ], - "IA-5(1).b": [ - "IAC-10.1" + "PE-11": [ + "PES-07.3" ], - "IA-5(1).c": [ - "IAC-10.1" + "PE-12": [ + "PES-07.4" ], - "IA-5(1).d": [ - "IAC-10.1" + "PE-15": [ + "PES-07.5" ], - "IA-5(1).d.1": [ - "IAC-10.1" + "PE-13": [ + "PES-08" ], - "IA-5(1).d.2": [ - "IAC-10.1" + "PE-14": [ + "PES-09" ], - "IA-5(1).d.3": [ - "IAC-10.1" + "PE-16": [ + "PES-10" ], - "IA-5(1).e": [ - "IAC-10.1" + "PE-17": [ + "PES-11" ], - "IA-5(1).f": [ - "IAC-10.1" + "PE-04": [ + "PES-12.1" ], - "IA-5(1).g": [ - "IAC-10.1" + "PE-05": [ + "PES-12.2" ], - "IA-5(1).h": [ - "IAC-10.1" + "SA-03": [ + "PRM-07", + "SEA-07.1", + "TDA-06" ], - "IA-5(2)": [ - "IAC-10.2" + "RA-02": [ + "RSK-02" ], - "IA-5(2).a": [ - "IAC-10.2" + "RA-07": [ + "RSK-06.1" ], - "IA-5(2).b": [ - "IAC-10.2" + "CA-07 (04)": [ + "RSK-11" ], - "IA-5(2).c": [ - "IAC-10.2" + "PL-08": [ + "SEA-02" ], - "IA-5(2).d": [ - "IAC-10.2" + "SC-02": [ + "SEA-03.2" ], - "IA-5(3)": [ - "IAC-10.3" + "SC-39": [ + "SEA-04" ], - "IA-5(7)": [ - "IAC-10.6" + "SC-04": [ + "SEA-05" ], - "IA-5(11)": [ - "IAC-10.7" + "SI-16": [ + "SEA-10" ], - "IA-6": [ - "IAC-11" + "AU-08": [ + "SEA-20" ], - "AC-2.a": [ - "IAC-15" + "AT-02": [ + "SAT-02" ], - "AC-2.b": [ - "IAC-15" + "AT-02 (03)": [ + "SAT-02.2" ], - "AC-2.c": [ - "IAC-15" + "AT-03": [ + "SAT-03" ], - "AC-2.d": [ - "IAC-15" + "AT-04": [ + "SAT-04" ], - "AC-2.e": [ - "IAC-15" + "SA-04": [ + "TDA-01", + "TDA-02", + "TPM-01", + "TPM-10" ], - "AC-2.f": [ - "IAC-15" + "SA-04 (09)": [ + "TDA-02.1" ], - "AC-2.f.1": [ - "IAC-15" + "SA-15": [ + "TDA-06" ], - "AC-2.f.1(i)": [ - "IAC-15" + "SA-11": [ + "TDA-09" ], - "AC-2.f.1(ii)": [ - "IAC-15" + "SA-10": [ + "TDA-14" ], - "AC-2.f.1(iii)": [ - "IAC-15" + "SA-10 (01)": [ + "TDA-14.1" ], - "AC-2.f.2": [ - "IAC-15" + "SA-22": [ + "TDA-17", + "TDA-17.1" ], - "AC-2.f.3": [ - "IAC-15" + "SI-11": [ + "TDA-19" ], - "AC-2.f.3(i)": [ - "IAC-15" + "SA-09": [ + "TPM-04" ], - "AC-2.f.3(ii)": [ - "IAC-15" + "SA-09 (02)": [ + "TPM-04.2" ], - "AC-2.f.3(iii)": [ - "IAC-15" + "AT-02 (02)": [ + "THR-05" ], - "AC-2.g": [ - "IAC-15" + "RA-05": [ + "VPM-06", + "VPM-06.1" ], - "AC-2-IS.1": [ - "IAC-15" + "RA-05 (02)": [ + "VPM-06.1" ], - "AC-2-IS.2": [ - "IAC-15" + "RA-05 (03)": [ + "VPM-06.2" ], - "AC-2-IS.4": [ - "IAC-15" + "RA-05 (05)": [ + "VPM-06.3" ], - "AC-2(1)": [ - "IAC-15.1" + "CA-08": [ + "VPM-07" + ] + }, + "usa-state-va-cdpa-2023": { + "59.1-580.C": [ + "GOV-17", + "RSK-10" ], - "AC-2(2)": [ - "IAC-15.2" + "59.1-581.E": [ + "CPL-01", + "PRI-07.1" ], - "AC-2(3)": [ - "IAC-15.3" + "59.1-579.B.4": [ + "CPL-01.4", + "PRI-07.1" ], - "AC-2(3).a": [ - "IAC-15.3" + "59.1-577.A.2": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" ], - "AC-2(3).b": [ - "IAC-15.3" + "59.1-581.A.1": [ + "DCH-23", + "PRI-05.3" ], - "AC-2(4)": [ - "IAC-15.4" + "59.1-578.A.3": [ + "PRI-01", + "PRI-01.6" ], - "AC-3": [ - "IAC-20", - "NET-12", - "TDA-18" + "59.1-581.A.2": [ + "PRI-01.3", + "PRI-02" ], - "AC-6": [ - "IAC-20", - "IAC-21" + "59.1-579.B": [ + "PRI-01.5", + "PRI-07.1" ], - "AC-6-IS.1": [ - "IAC-21" + "59.1-579.A.1": [ + "PRI-01.6", + "PRI-01.11", + "PRI-07.1" ], - "AC-6-IS.2": [ - "IAC-21" + "59.1-579.B.1": [ + "PRI-01.6" ], - "AC-6-IS.3": [ - "IAC-21" + "59.1-577.1.B": [ + "PRI-01.11" ], - "AC-6-IS.4": [ - "IAC-21" + "59.1-577.1.C": [ + "PRI-01.11", + "PRI-03.3", + "PRI-05.4" ], - "AC-6(1)": [ - "IAC-21.1" + "59.1-577.1.E": [ + "PRI-01.11", + "PRI-03.5" ], - "AC-6(1).a": [ - "IAC-21.1" + "59.1-578.A.4": [ + "PRI-01.11", + "PRI-03.5" ], - "AC-6(1).b": [ - "IAC-21.1" + "59.1-578.F.1.d": [ + "PRI-01.11", + "PRI-03.9" ], - "AC-6(1).c": [ - "IAC-21.1" + "59.1-578.F.2": [ + "PRI-01.11", + "PRI-04" ], - "AC-6(1).d": [ - "IAC-21.1" + "59.1-579.A.2": [ + "PRI-01.11", + "PRI-07.1" ], - "AC-6(1).e": [ - "IAC-21.1" + "59.1-579.A.3": [ + "PRI-01.11", + "PRI-07.1" ], - "AC-6(1)-IS.1": [ - "IAC-21.1" + "59.1-578.C": [ + "PRI-02" ], - "AC-6(2)": [ - "IAC-21.2" + "59.1-578.C.1": [ + "PRI-02" ], - "AC-6(2).a": [ - "IAC-21.2" + "59.1-578.C.2": [ + "PRI-02", + "PRI-02.1" ], - "AC-6(2).b": [ - "IAC-21.2" + "59.1-578.C.3": [ + "PRI-02" ], - "AC-6(2).c": [ - "IAC-21.2" + "59.1-578.C.4": [ + "PRI-02", + "PRI-05.7" ], - "AC-6(2).d": [ - "IAC-21.2" + "59.1-578.C.5": [ + "PRI-02", + "TPM-01.1" ], - "AC-6(2).e": [ - "IAC-21.2" + "59.1-578.D": [ + "PRI-02", + "PRI-03" ], - "AC-6(2)-IS.1": [ - "IAC-21.2" + "59.1-578.E": [ + "PRI-02" ], - "AC-6(5)": [ - "IAC-21.3" + "59.1-578.A.5": [ + "PRI-03", + "PRI-03.6" ], - "AC-6(9)": [ - "IAC-21.4" + "59.1-578.F.1": [ + "PRI-03.3", + "PRI-03.12", + "PRI-03.13", + "PRI-04" ], - "AC-6(10)": [ - "IAC-21.5" + "59.1-578.F.1.a": [ + "PRI-03.3" ], - "AC-7": [ - "IAC-22" + "59.1-577.A": [ + "PRI-03.6", + "PRI-03.7", + "PRI-06" ], - "AC-7.a": [ - "IAC-22" + "59.1-577.1.D": [ + "PRI-03.6" ], - "AC-7.b": [ - "IAC-22" + "59.1-578.F.3": [ + "PRI-03.6" ], - "AC-7-IS.1": [ - "IAC-22" + "59.1-577.A.5": [ + "PRI-03.7", + "PRI-21", + "PRI-21.1" ], - "AC-10": [ - "IAC-23" + "59.1-579.B.2": [ + "PRI-03.10", + "PRI-07.3" ], - "AC-11": [ - "IAC-24" + "59.1-578.F.1.b": [ + "PRI-03.12", + "PRI-03.13", + "PRI-04.1" ], - "AC-11.a": [ - "IAC-24" + "59.1-578.A.1": [ + "PRI-04" ], - "AC-11.b": [ - "IAC-24" + "59.1-578.F.1.c": [ + "PRI-04", + "PRI-04.1", + "PRI-05.4" ], - "AC-11(1)": [ - "IAC-24.1" + "59.1-578.A.2": [ + "PRI-05.4" ], - "AC-12": [ - "IAC-25" + "59.1-577.A.1": [ + "PRI-06" ], - "AC-14": [ - "IAC-26" + "59.1-577.A.3": [ + "PRI-06", + "PRI-06.5" ], - "AC-14.a": [ - "IAC-26" + "59.1-577.A.4": [ + "PRI-06", + "PRI-06.6", + "PRI-06.7" ], - "AC-14.b": [ - "IAC-26" + "59.1-577.C": [ + "PRI-06.3", + "PRI-06.4" ], - "IR-4": [ - "IRO-02" + "59.1-577.B.1": [ + "PRI-06.4" ], - "IR-4.a": [ - "IRO-02" + "59.1-577.B.2": [ + "PRI-06.4", + "PRI-17" ], - "IR-4.b": [ - "IRO-02" + "59.1-577.B.3": [ + "PRI-06.4" ], - "IR-4.c": [ - "IRO-02" + "59.1-577.B.4": [ + "PRI-06.4" ], - "IR-4.d": [ - "IRO-02" + "59.1-578.B": [ + "PRI-07.1" ], - "IR-4.e": [ - "IRO-02" + "59.1-579.A": [ + "PRI-07.1" ], - "IR-4.f": [ - "IRO-02" + "59.1-579.B.3": [ + "PRI-07.1" ], - "IR-4.g": [ - "IRO-02" + "59.1-579.B.5": [ + "PRI-07.1", + "TPM-05", + "TPM-05.2" ], - "IR-4.h": [ - "IRO-02" + "59.1-581.A.3": [ + "PRI-07.1" ], - "IR-4-IS": [ - "IRO-02" + "59.1-577.B.5": [ + "PRI-17.3" ], - "SE-2": [ - "IRO-02" + "59.1-580.A": [ + "RSK-10" ], - "SE-2.a": [ - "IRO-02" + "59.1-580.A.1": [ + "RSK-10" ], - "SE-2.b": [ - "IRO-02" + "59.1-580.A.2": [ + "RSK-10" ], - "SE-2.c": [ - "IRO-02" + "59.1-580.A.3": [ + "RSK-10" ], - "IR-4(1)": [ - "IRO-02.1" + "59.1-580.A.4": [ + "RSK-10" ], - "IR-8": [ - "IRO-04" + "59.1-580.A.5": [ + "RSK-10" ], - "IR-8.a": [ - "IRO-04" + "59.1-580.B": [ + "RSK-10" ], - "IR-8.a.1": [ - "IRO-04" + "59.1-580.D": [ + "RSK-10" ], - "IR-8.a.2": [ - "IRO-04" + "59.1-580.E": [ + "RSK-10" ], - "IR-8.a.3": [ - "IRO-04" + "59.1-580.F": [ + "RSK-10" ], - "IR-8.a.4": [ - "IRO-04" + "59.1-580.G": [ + "RSK-10" ], - "IR-8.a.5": [ - "IRO-04" + "59.1-575": [ + "SEA-02.1" + ] + }, + "usa-state-vt-act-171-2018": { + "2447(a)(1)": [ + "GOV-01" ], - "IR-8.a.6": [ - "IRO-04" + "2447(a)(1)(A)": [ + "GOV-01" ], - "IR-8.a.7": [ - "IRO-04" + "2447(a)(1)(B)": [ + "GOV-01" ], - "IR-8.a.8": [ - "IRO-04" + "2447(a)(1)(C)": [ + "GOV-01" ], - "IR-8.a.9": [ - "IRO-04" + "2447(a)(1)(D)": [ + "GOV-01" ], - "IR-8.a.9(i)": [ - "IRO-04" + "2447(b)": [ + "GOV-01" ], - "IR-8.a.9(ii)": [ - "IRO-04" + "2447(c)": [ + "GOV-01" ], - "IR-8.a.9(iii)": [ - "IRO-04" + "2447(b)(8)(B)": [ + "GOV-03" ], - "IR-8.a.9(iv)": [ - "IRO-04" + "2447(b)(9)": [ + "GOV-03" ], - "IR-8.a.9(v)": [ - "IRO-04" + "2447(b)(9)(A)": [ + "GOV-03" ], - "IR-8.a.9(vi)": [ - "IRO-04" + "2447(b)(9)(B)": [ + "GOV-03" ], - "IR-8.a.9(vii)": [ - "IRO-04" + "2447(b)(1)": [ + "GOV-04" ], - "IR-8.a.9(viii)": [ - "IRO-04" + "2446(a)(2)": [ + "CPL-01" ], - "IR-8.b": [ - "IRO-04" + "2446(a)(3)": [ + "CPL-01" ], - "IR-8.c": [ - "IRO-04" + "2446(a)(3)(A)": [ + "CPL-01" ], - "IR-8.d": [ - "IRO-04" + "2446(a)(3)(B)": [ + "CPL-01" ], - "IR-8.e": [ - "IRO-04" + "2446(a)(3)(B)(i)": [ + "CPL-01" ], - "IR-8-IS.1": [ - "IRO-04" + "2446(a)(3)(B)(ii)": [ + "CPL-01" ], - "IR-8-IS.2": [ - "IRO-04" + "2446(a)(3)(B)(iii)": [ + "CPL-01" ], - "IR-8-IS.3": [ - "IRO-04" + "2446(a)(3)(C)": [ + "CPL-01" ], - "IR-2": [ - "IRO-05" + "2446(a)(3)(D)": [ + "CPL-01" ], - "IR-2-1": [ - "IRO-05" + "2446(a)(3)(E)": [ + "CPL-01" ], - "IR-2-1a": [ - "IRO-05" + "2446(a)(3)(F)": [ + "CPL-01" ], - "IR-2-1b": [ - "IRO-05" + "2446(a)(3)(G)": [ + "CPL-01" ], - "IR-2-1c": [ - "IRO-05" + "2447(b)(2)(C)": [ + "CPL-02", + "MON-01.8" ], - "IR-2-2": [ - "IRO-05" + "2447(b)(8)(A)": [ + "CPL-02" ], - "IR-2-2a": [ - "IRO-05" + "2447(c)(4)": [ + "MON-01.8" ], - "IR-2-2b": [ - "IRO-05" + "2447(c)(3)": [ + "CRY-03" ], - "IR-2-2c": [ - "IRO-05" + "2447(c)(5)": [ + "CRY-03" ], - "IR-2-2d": [ - "IRO-05" + "2447(b)(3)": [ + "DCH-01.2" ], - "IR-3": [ - "IRO-06" + "2447(c)(6)": [ + "END-02", + "VPM-04.1" ], - "IR-3.a": [ - "IRO-06" + "2447(c)(7)": [ + "END-04.1" ], - "IR-3.b": [ - "IRO-06" + "2447(b)(5)": [ + "HRS-01.1" ], - "IR-3.c": [ - "IRO-06" + "2447(b)(2)(B)": [ + "HRS-05" ], - "IR-3(2)": [ - "IRO-06" + "2447(b)(4)": [ + "HRS-07" ], - "IR-5": [ - "IRO-09" + "2447(c)(1)": [ + "IAC-01" ], - "IR-6.a": [ - "IRO-10" + "2447(c)(1)(A)": [ + "IAC-01.2" ], - "IR-6.b": [ - "IRO-10" + "2447(c)(1)(B)": [ + "IAC-01.2" ], - "IR-6(1)": [ - "IRO-10.1" + "2447(c)(2)": [ + "IAC-01.2" ], - "IR-7": [ - "IRO-11" + "2447(c)(2)(A)": [ + "IAC-08" ], - "IR-7(1)": [ - "IRO-11.1" + "2447(c)(2)(B)": [ + "IAC-08" ], - "IR-9": [ - "IRO-12", - "IRO-12.1" + "2447(c)(1)(A)(ii)": [ + "IAC-10" ], - "IR-9.a": [ - "IRO-12" + "2447(c)(1)(A)(iii)": [ + "IAC-10.5" ], - "IR-9.b": [ - "IRO-12" + "2447(c)(1)(A)(i)": [ + "IAC-15" ], - "IR-9.c": [ - "IRO-12" + "2447(c)(1)(A)(iv)": [ + "IAC-15" ], - "IR-9.d": [ - "IRO-12" + "2447(c)(1)(A)(v)": [ + "IAC-22" ], - "IR-9.e": [ - "IRO-12" + "2447(b)(10)(A)": [ + "IRO-09.3" ], - "PM-10-1": [ - "IAO-01" + "2447(b)(10)(B)": [ + "IRO-13" ], - "PM-10-1a": [ - "IAO-01" + "2447(b)(7)": [ + "PES-03" ], - "PM-10-1b": [ - "IAO-01" + "2447(a)(2)": [ + "PRI-01.6", + "PRI-01.11" ], - "PM-10-1c": [ - "IAO-01" + "2433(a)(1)": [ + "PRI-01.11", + "PRI-04" ], - "PM-10-2": [ - "IAO-01" + "2433(a)(2)(A)": [ + "PRI-01.11" ], - "PM-10-2a": [ - "IAO-01" + "2433(a)(2)(B)": [ + "PRI-01.11" ], - "PM-10-2b": [ - "IAO-01" + "2433(a)(2)(C)": [ + "PRI-01.11" ], - "PM-10-2c": [ - "IAO-01" + "2446(a)(1)": [ + "PRI-15" ], - "PM-10-2d": [ - "IAO-01" + "2447(b)(2)": [ + "RSK-01", + "THR-01" ], - "CA-2.a": [ - "IAO-02" + "2447(b)(2)(A)": [ + "SAT-02" ], - "CA-2.a.1": [ - "IAO-02" + "2447(c)(8)": [ + "SAT-03.3" ], - "CA-2.a.2": [ - "IAO-02" + "2447(b)(6)": [ + "TPM-01" ], - "CA-2.a.3": [ - "IAO-02" + "2447(b)(6)(A)": [ + "TPM-04.1" ], - "CA-2.b": [ - "IAO-02" + "2447(b)(6)(B)": [ + "TPM-05" + ] + }, + "emea-eu-ai-act-2024": { + "Article 17.2": [ + "GOV-01", + "GOV-15" ], - "CA-2.c": [ - "IAO-02" + "Article 17.1(m)": [ + "GOV-04", + "GOV-04.1" ], - "CA-2.d": [ - "IAO-02" + "Article 17.1(e)": [ + "GOV-15.2", + "AAT-01.1", + "AAT-02.2", + "CFG-02" ], - "CA-2-IS.1": [ - "IAO-02" + "Article 16(c)": [ + "GOV-18" ], - "CA-2-IS.2": [ - "IAO-02" + "Article 17.1": [ + "GOV-18" ], - "CA-2-IS.3": [ - "IAO-02" + "Article 17.1(c)": [ + "AAT-01" ], - "CA-2-IS.4": [ - "IAO-02" + "Article 9.1": [ + "AAT-02.1", + "RSK-01" ], - "CA-2(1)": [ - "IAO-02.1" + "Article 55.1(d)": [ + "AAT-02.3" ], - "CA-2(1)-IS": [ - "IAO-02.1" + "Article 55.2": [ + "AAT-02.3" ], - "PL-2.a": [ - "IAO-03" + "Article 8.1": [ + "AAT-03", + "RSK-01", + "TDA-21" ], - "PL-2.a.1": [ - "IAO-03" + "Article 9.2(b)": [ + "AAT-04.2", + "AAT-09" ], - "PL-2.a.2": [ - "IAO-03" + "Article 9.2(a)": [ + "AAT-07", + "AAT-09" ], - "PL-2.a.3": [ - "IAO-03" + "Article 27.2": [ + "AAT-07.1", + "AAT-10" ], - "PL-2.a.4": [ - "IAO-03" + "Article 27.4": [ + "AAT-07.1" ], - "PL-2.a.5": [ - "IAO-03" + "Article 9.9": [ + "AAT-07.2", + "RSK-01" ], - "PL-2.a.6": [ - "IAO-03" + "Article 13.1": [ + "AAT-09", + "AAT-09.1", + "AAT-20", + "AAT-20.1" ], - "PL-2.a.7": [ - "IAO-03" + "Article 17.1(g)": [ + "AAT-09", + "RSK-01" ], - "PL-2.a.8": [ - "IAO-03" + "Article 6.1": [ + "AAT-09.1" ], - "PL-2.a.9": [ - "IAO-03" + "Article 6.1(a)": [ + "AAT-09.1" ], - "PL-2.b": [ - "IAO-03" + "Article 6.3": [ + "AAT-09.1", + "AST-31.2" ], - "PL-2.c": [ - "IAO-03" + "Article 51.1": [ + "AAT-09.1" ], - "PL-2.d": [ - "IAO-03" + "Article 51.1(a)": [ + "AAT-09.1" ], - "PL-2.d.1": [ - "IAO-03" + "Article 51.2": [ + "AAT-09.1" ], - "PL-2.d.2": [ - "IAO-03" + "Article 9.6": [ + "AAT-10", + "AAT-10.3", + "AAT-10.4", + "AAT-10.5" ], - "PL-2.d.3": [ - "IAO-03" + "Article 11.1": [ + "AAT-10", + "AAT-14", + "CPL-01.3", + "IAO-03", + "TDA-04", + "TDA-22" ], - "PL-2.d.4": [ - "IAO-03" + "Article 16(f)": [ + "AAT-10", + "CPL-01.4" ], - "PL-2.d.5": [ - "IAO-03" + "Article 17.1(b)": [ + "AAT-10", + "AAT-20" ], - "PL-2.e": [ - "IAO-03" + "Article 17.1(d)": [ + "AAT-10" ], - "PL-2-IS": [ - "IAO-03" + "Article 23.1": [ + "AAT-10" ], - "PL-2(3)": [ - "IAO-03" + "Article 23.1(a)": [ + "AAT-10" ], - "CA-5": [ - "IAO-05" + "Article 27.1": [ + "AAT-10" ], - "CA-5.a": [ - "IAO-05" + "Article 27.1(a)": [ + "AAT-10" ], - "CA-5.b": [ - "IAO-05" + "Article 27.1(b)": [ + "AAT-10" ], - "CA-5.c": [ - "IAO-05" + "Article 27.1(c)": [ + "AAT-10" ], - "CA-5-IS.1": [ - "IAO-05" + "Article 27.1(d)": [ + "AAT-10" ], - "PM-4": [ - "IAO-05", - "VPM-02" + "Article 27.1(e)": [ + "AAT-10" ], - "PM-4.a": [ - "IAO-05" + "Article 27.1(f)": [ + "AAT-10" ], - "PM-4.a.1": [ - "IAO-05" + "Article 55.1(a)": [ + "AAT-10" ], - "PM-4.a.2": [ - "IAO-05" + "Article 55.1(b)": [ + "AAT-10" ], - "PM-4.a.3": [ - "IAO-05" + "Article 60.1": [ + "AAT-10" ], - "PM-4.b": [ - "IAO-05" + "Article 60.2": [ + "AAT-10" ], - "PM-4-IS.1": [ - "IAO-05" + "Article 60.3": [ + "AAT-10" ], - "CA-5(1)": [ - "IAO-05.1" + "Article 60.4(a)": [ + "AAT-10" ], - "CM-4(2)": [ - "IAO-06" + "Article 60.4(b)": [ + "AAT-10" ], - "CA-6": [ - "IAO-07" + "Article 60.4(c)": [ + "AAT-10" ], - "CA-6.a": [ - "IAO-07" + "Article 60.4(d)": [ + "AAT-10" ], - "CA-6.b": [ - "IAO-07" + "Article 60.4(e)": [ + "AAT-10" ], - "CA-6.b.1": [ - "IAO-07" + "Article 60.4(f)": [ + "AAT-10" ], - "CA-6.b.2": [ - "IAO-07" + "Article 60.4(g)": [ + "AAT-10" ], - "CA-6.b.3": [ - "IAO-07" + "Article 60.4(h)": [ + "AAT-10" ], - "CA-6.b.4": [ - "IAO-07" + "Article 60.4(i)": [ + "AAT-10" ], - "CA-6.b.5": [ - "IAO-07" + "Article 60.4(j)": [ + "AAT-10" ], - "CA-6.b.6": [ - "IAO-07" + "Article 60.4(k)": [ + "AAT-10" ], - "CA-6.c": [ - "IAO-07" + "Article 10.2(f)": [ + "AAT-10.8" ], - "CA-6.c.1": [ - "IAO-07" + "Article 10.2(g)": [ + "AAT-10.8" ], - "CA-6.c.2": [ - "IAO-07" + "Article 10.4": [ + "AAT-10.8" ], - "CA-6.c.3": [ - "IAO-07" + "Article 10.5": [ + "AAT-10.8", + "PRI-01", + "PRI-05.7" ], - "CA-6.c.4": [ - "IAO-07" + "Article 10.5(a)": [ + "AAT-10.8" ], - "CA-6.c.5": [ - "IAO-07" + "Article 9.7": [ + "AAT-10.12", + "AAT-24" ], - "CA-6.c.6": [ - "IAO-07" + "Article 10.3": [ + "AAT-10.12", + "DCH-18.2", + "DCH-22" ], - "MA-2": [ - "MNT-02" + "Article 17.1(h)": [ + "AAT-10.13", + "AAT-11.2", + "AAT-16" ], - "MA-2.a": [ - "MNT-02" + "Article 27.3": [ + "AAT-10.15" ], - "MA-2.b": [ - "MNT-02" + "Article 60.7": [ + "AAT-10.15", + "AAT-16.9" ], - "MA-2.c": [ - "MNT-02" + "Article 60.8": [ + "AAT-10.15" ], - "MA-2.d": [ - "MNT-02" + "Article 17.1(i)": [ + "AAT-11.4" ], - "MA-2.e": [ - "MNT-02" + "Article 17.1(f)": [ + "AAT-12", + "AAT-12.1", + "AAT-12.2", + "DCH-01", + "DCH-02", + "DCH-22" ], - "MA-2.f": [ - "MNT-02" + "Article 53.1(c)": [ + "AAT-12", + "TDA-21" ], - "MA-2-IS.1": [ - "MNT-02" + "Article 53.1(d)": [ + "AAT-12.3" ], - "MA-6": [ - "MNT-03" + "Article 4": [ + "AAT-13.1" ], - "MA-3": [ - "MNT-04" + "Article 12.2(a)": [ + "AAT-14", + "AAT-16", + "AAT-16.3" ], - "MA-3(1)": [ - "MNT-04.1" + "Article 14.2": [ + "AAT-15.2", + "AAT-16", + "AAT-17", + "AAT-22.1" ], - "MA-3(2)": [ - "MNT-04.2" + "Article 14.4(d)": [ + "AAT-15.2" ], - "MA-3(3)": [ - "MNT-04.3" + "Article 14.4(e)": [ + "AAT-15.2" ], - "MA-3(3).a": [ - "MNT-04.3" + "Article 12.1": [ + "AAT-16", + "AAT-16.8", + "MON-01.4" ], - "MA-3(3).b": [ - "MNT-04.3" + "Article 12.2(b)": [ + "AAT-16" ], - "MA-3(3).c": [ - "MNT-04.3" + "Article 12.2(c)": [ + "AAT-16" ], - "MA-3(3).d": [ - "MNT-04.3" + "Article 15.3": [ + "AAT-16", + "AAT-20.2" ], - "MA-4": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "Article 72.1": [ + "AAT-16" ], - "MA-4.a": [ - "MNT-05" + "Article 72.2": [ + "AAT-16" ], - "MA-4.b": [ - "MNT-05" + "Article 72.3": [ + "AAT-16" ], - "MA-4.c": [ - "MNT-05" + "Article 72.4": [ + "AAT-16" ], - "MA-4.d": [ - "MNT-05" + "Article 12.2": [ + "AAT-16.8" ], - "MA-4(2)": [ - "MNT-05" + "Article 12.3(a)": [ + "AAT-16.8" ], - "MA-4(1)": [ - "MNT-05.1" + "Article 12.3(b)": [ + "AAT-16.8" ], - "MA-4(1).a": [ - "MNT-05.1" + "Article 12.3(c)": [ + "AAT-16.8" ], - "MA-4(1).b": [ - "MNT-05.1" + "Article 12.3(d)": [ + "AAT-16.8" ], - "MA-4(3)": [ - "MNT-05.6" + "Article 16(e)": [ + "AAT-16.8" ], - "MA-4(3).a": [ - "MNT-05.6" + "Article 26.6": [ + "AAT-16.8" ], - "MA-4(3).b": [ - "MNT-05.6" + "Article 55.1(c)": [ + "AAT-16.9" ], - "MA-5": [ - "MNT-06" + "Article 73.1": [ + "AAT-16.9" ], - "MA-5.a": [ - "MNT-06" + "Article 73.2": [ + "AAT-16.9" ], - "MA-5.b": [ - "MNT-06" + "Article 73.3": [ + "AAT-16.9" ], - "MA-5.c": [ - "MNT-06" + "Article 73.4": [ + "AAT-16.9" ], - "AC-19": [ - "MDM-02" + "Article 73.5": [ + "AAT-16.9" ], - "AC-19.a": [ - "MDM-02" + "Article 73.6": [ + "AAT-16.10" ], - "AC-19.b": [ - "MDM-02" + "Article 20.2": [ + "AAT-17.3", + "AAT-18", + "AAT-18.1" ], - "AC-19.c": [ - "MDM-02" + "Article 5.1": [ + "AAT-19" ], - "AC-19.d": [ - "MDM-02" + "Article 5.1(a)": [ + "AAT-19.1" ], - "AC-19.e": [ - "MDM-02" + "Article 5.1(b)": [ + "AAT-19.2" ], - "AC-19.f": [ - "MDM-02" + "Article 5.1(c)": [ + "AAT-19.3" ], - "AC-19.g": [ - "MDM-02" + "Article 5.1(c)(i)": [ + "AAT-19.4" ], - "AC-19.h": [ - "MDM-02" + "Article 5.1(c)(ii)": [ + "AAT-19.4" ], - "AC-19-IS.1": [ - "MDM-02" + "Article 5.1(d)": [ + "AAT-19.5" ], - "AC-19-IS.3": [ - "MDM-02" + "Article 5.1(e)": [ + "AAT-19.6" ], - "AC-19(5)": [ - "MDM-03" + "Article 5.1(f)": [ + "AAT-19.7" ], - "SC-5.a": [ - "NET-02.1" + "Article 5.1(g)": [ + "AAT-19.8" ], - "SC-5.b": [ - "NET-02.1" + "Article 14.1": [ + "AAT-20", + "TDA-02.3" ], - "SC-5.c": [ - "NET-02.1" + "Article 14.3(a)": [ + "AAT-20", + "CFG-02.5" ], - "SC-5-IS": [ - "NET-02.1" + "Article 14.3(b)": [ + "AAT-20", + "AAT-20.1", + "PRM-05", + "TDA-01.1" ], - "SC-7": [ - "NET-03" + "Article 15.1": [ + "AAT-20" ], - "SC-7.a": [ - "NET-03" + "Article 15.4": [ + "AAT-20", + "SEA-01.2" ], - "SC-7.b": [ - "NET-03" + "Article 15.5": [ + "AAT-20" ], - "SC-7.c": [ - "NET-03" + "Article 16(a)": [ + "AAT-20" ], - "SC-7-IS.1": [ - "NET-03" + "Article 14.4": [ + "AAT-20.1", + "AAT-20.2", + "TDA-01" ], - "SC-7-IS.2": [ - "NET-03" + "Article 14.4(a)": [ + "AAT-20.1", + "AAT-20.2" ], - "SC-7-IS.3": [ - "NET-03" + "Article 13.2": [ + "AAT-20.2" ], - "SC-7(3)": [ - "NET-03.1" + "Article 13.3(a)": [ + "AAT-20.2" ], - "SC-7(4)": [ - "NET-03.2" + "Article 13.3(b)(i)": [ + "AAT-20.2" ], - "SC-7(4).a": [ - "NET-03.2" + "Article 13.3(b)(ii)": [ + "AAT-20.2" ], - "SC-7(4).b": [ - "NET-03.2" + "Article 13.3(b)(iii)": [ + "AAT-20.2" ], - "SC-7(4).c": [ - "NET-03.2" + "Article 13.3(b)(iv)": [ + "AAT-20.2" ], - "SC-7(4).d": [ - "NET-03.2" + "Article 13.3(b)(v)": [ + "AAT-20.2" ], - "SC-7(4).e": [ - "NET-03.2" + "Article 13.3(b)(vi)": [ + "AAT-20.2" ], - "SC-7(4).f": [ - "NET-03.2" + "Article 13.3(b)(vii)": [ + "AAT-20.2" ], - "AC-4": [ - "NET-04" + "Article 13.3(c)": [ + "AAT-20.2" ], - "SC-7(5)": [ - "NET-04.1" + "Article 13.3(d)": [ + "AAT-20.2" ], - "CA-3": [ - "NET-05" + "Article 13.3(e)": [ + "AAT-20.2" ], - "CA-3.a": [ - "NET-05" + "Article 13.3(f)": [ + "AAT-20.2" ], - "CA-3.b": [ - "NET-05" + "Article 53.1(b)": [ + "AAT-20.2" ], - "CA-3.c": [ - "NET-05" + "Article 53.1(b)(i)": [ + "AAT-20.2" ], - "CA-3.d": [ - "NET-05" + "Article 16(i)": [ + "AAT-21" ], - "CA-3-IS.1": [ - "NET-05" + "Article 22.3(e)": [ + "AAT-21" ], - "CA-3-IS.2": [ - "NET-05" + "Article 26.8": [ + "AAT-21" ], - "CA-3-IS.3": [ - "NET-05" + "Article 49.1": [ + "AAT-21" ], - "CA-3(5)": [ - "NET-05.1" + "Article 49.2": [ + "AAT-21" ], - "CA-9": [ - "NET-05.2" + "Article 49.3": [ + "AAT-21" ], - "CA-9.a": [ - "NET-05.2" + "Article 52.1": [ + "AAT-21" ], - "CA-9.b": [ - "NET-05.2" + "Article 52.2": [ + "AAT-21" ], - "SC-7(13)": [ - "NET-06.1" + "Article 26.1": [ + "AAT-22" ], - "SC-10": [ - "NET-07" + "Article 14.3": [ + "AAT-22.2" ], - "SC-10.a": [ - "NET-07" + "Article 14.4(b)": [ + "AAT-22.3" ], - "SC-10.b": [ - "NET-07" + "Article 14.4(c)": [ + "AAT-22.3" ], - "SC-23": [ - "NET-09" + "Article 14.5": [ + "AAT-22.3" ], - "SC-20": [ - "NET-10" + "Article 26.2": [ + "AAT-22.4" ], - "SC-20.a": [ - "NET-10" + "Article 26.4": [ + "AAT-22.5" ], - "SC-20.b": [ - "NET-10" + "Article 26.5": [ + "AAT-22.6" ], - "SC-20-IS.1": [ - "NET-10" + "Article 26.7": [ + "AAT-22.7" ], - "SC-22": [ - "NET-10.1" + "Article 26.11": [ + "AAT-22.8" ], - "SC-21": [ - "NET-10.2" + "Article 50.1": [ + "AAT-22.8" ], - "SI-5": [ - "NET-12", - "TDA-18", - "THR-03" + "Article 50.3": [ + "AAT-22.8" ], - "SI-10": [ - "NET-12", - "TDA-18" + "Article 50.5": [ + "AAT-22.8" ], - "SC-ACA-1": [ - "NET-13" + "Article 50.2": [ + "AAT-23" ], - "SC-ACA-1-IS.a": [ - "NET-13" + "Article 50.4": [ + "AAT-23" ], - "SC-ACA-2": [ - "NET-13" + "Article 61.1": [ + "AAT-24" ], - "SC-ACA-2.a": [ - "NET-13" + "Article 61.1(a)": [ + "AAT-24" ], - "SC-ACA-2-IS.1": [ - "NET-13" + "Article 61.1(b)": [ + "AAT-24" ], - "SC-ACA-2-IS.1.a": [ - "NET-13" + "Article 61.1(c)": [ + "AAT-24" ], - "SC-ACA-2-IS.1.b": [ - "NET-13" + "Article 61.1(d)": [ + "AAT-24" ], - "SC-ACA-2-IS.1.c": [ - "NET-13" + "Article 61.1(e)": [ + "AAT-24" ], - "AC-17": [ - "NET-14" + "Article 61.2": [ + "AAT-24" ], - "AC-17.a": [ - "NET-14" + "Article 16(l)": [ + "CPL-01" ], - "AC-17.a.1": [ - "NET-14" + "Article 17.1(a)": [ + "CPL-01" ], - "AC-17.a.2": [ - "NET-14" + "Article 21.3": [ + "CPL-01" ], - "AC-17.a.3": [ - "NET-14" + "Article 40.1": [ + "CPL-01" ], - "AC-17.b": [ - "NET-14" + "Article 10.2(h)": [ + "CPL-01.1" ], - "AC-17-IS.1": [ - "NET-14" + "Article 16(j)": [ + "CPL-01.1" ], - "AC-17-IS.3": [ - "NET-14" + "Article 20.1": [ + "CPL-01.1" ], - "AC-17(1)": [ - "NET-14.1" + "Article 41.5": [ + "CPL-01.1" ], - "AC-17(2)": [ - "NET-14.2" + "Article 16(k)": [ + "CPL-01.3" ], - "AC-17(3)": [ - "NET-14.3" + "Article 21.1": [ + "CPL-01.3", + "CPL-05" ], - "AC-17(4)": [ - "NET-14.4" + "Article 22.3": [ + "CPL-01.3", + "CPL-08" ], - "AC-17(4).a": [ - "NET-14.4" + "Article 22.3(a)": [ + "CPL-01.3" ], - "AC-17(4).b": [ - "NET-14.4" + "Article 43.1": [ + "CPL-01.4" ], - "AC-18.a": [ - "NET-15" + "Article 43.1(a)": [ + "CPL-01.4" ], - "AC-18.b": [ - "NET-15" + "Article 43.1(b)(a)": [ + "CPL-01.4" ], - "AC-18.c": [ - "NET-15" + "Article 43.1(b)(b)": [ + "CPL-01.4" ], - "AC-18(1)": [ - "NET-15.1" + "Article 43.1(b)(c)": [ + "CPL-01.4" ], - "SC-7(8)": [ - "NET-18", - "NET-18.1" + "Article 43.1(b)(d)": [ + "CPL-01.4" ], - "SC-7(8)-IS.1": [ - "NET-18.1" + "Article 43.2": [ + "CPL-01.4" ], - "PE-2": [ - "PES-02" + "Article 43.3": [ + "CPL-01.4" ], - "PE-2.a": [ - "PES-02" + "Article 43.4": [ + "CPL-01.4" ], - "PE-2.b": [ - "PES-02" + "Article 16(g)": [ + "CPL-01.5" ], - "PE-2.c": [ - "PES-02" + "Article 47.1": [ + "CPL-01.5" ], - "PE-2-IS.1": [ - "PES-02" + "Article 47.2": [ + "CPL-01.5" ], - "PE-2-IS.2": [ - "PES-02" + "Article 47.3": [ + "CPL-01.5" ], - "PE-3-IS.3": [ - "PES-02" + "Article 47.4": [ + "CPL-01.5" ], - "PE-2(1)": [ - "PES-02.1" + "Article 79.4": [ + "CPL-02.3" ], - "PE-3": [ - "PES-03" + "Article 80.4": [ + "CPL-02.3" ], - "PE-3.a": [ - "PES-03" + "Article 80.5": [ + "CPL-02.3" ], - "PE-3.b": [ - "PES-03" + "Article 82.2": [ + "CPL-02.3" ], - "PE-3.c": [ - "PES-03" + "Article 93.1(a)": [ + "CPL-02.3" ], - "PE-3.d": [ - "PES-03" + "Article 93.1(b)": [ + "CPL-02.3" ], - "PE-3.e": [ - "PES-03" + "Article 93.1(c)": [ + "CPL-02.3" ], - "PE-3.f": [ - "PES-03" + "Article 22.3(c)": [ + "CPL-05" ], - "PE-3.g": [ - "PES-03" + "Article 22.3(d)": [ + "CPL-05" ], - "PE-3.h": [ - "PES-03" + "Article 24.5": [ + "CPL-05" ], - "PE-3.i": [ - "PES-03" + "Article 24.6": [ + "CPL-05" ], - "PE-3-IS.1": [ - "PES-03" + "Article 91.4": [ + "CPL-05" ], - "PE-3-IS.4": [ - "PES-03" + "Article 91.5": [ + "CPL-05" ], - "PE-8": [ - "PES-03.3" + "Article 92.4": [ + "CPL-05" ], - "PE-8.a": [ - "PES-03.3" + "Article 92.5": [ + "CPL-05" ], - "PE-8.b": [ - "PES-03.3" + "Article 21.2": [ + "CPL-05.2" ], - "PE-3-IS.2": [ - "PES-03.4" + "Article 22.1": [ + "CPL-08" ], - "PE-6": [ - "PES-05" + "Article 22.2": [ + "CPL-08" ], - "PE-6.a": [ - "PES-05" + "Article 23.1(d)": [ + "CPL-08" ], - "PE-6.b": [ - "PES-05" + "Article 54.1": [ + "CPL-08" ], - "PE-6.c": [ - "PES-05" + "Article 54.2": [ + "CPL-08.1" ], - "PE-6-IS.1": [ - "PES-05" + "Article 54.3": [ + "CPL-08.1" ], - "PE-6(1)": [ - "PES-05.1" + "Article 54.3(a)": [ + "CPL-08.1" ], - "PE-3-IS.5": [ - "PES-06" + "Article 54.3(b)": [ + "CPL-08.1" ], - "PE-9": [ - "PES-07" + "Article 54.3(c)": [ + "CPL-08.1" ], - "PE-9-IS.1": [ - "PES-07" + "Article 54.3(d)": [ + "CPL-08.1" ], - "PE-10": [ - "PES-07.2" + "Article 54.4": [ + "CPL-08.1" ], - "PE-10.a": [ - "PES-07.2" + "Article 54.5": [ + "CPL-08.1" ], - "PE-10.b": [ - "PES-07.2" + "Article 19.1": [ + "MON-10" ], - "PE-10.c": [ - "PES-07.2" + "Article 19.2": [ + "MON-10" ], - "PE-11": [ - "PES-07.3" + "Article 16(d)": [ + "DCH-18" ], - "PE-12": [ - "PES-07.4" + "Article 18.1": [ + "DCH-18" ], - "PE-15": [ - "PES-07.5" + "Article 18.1(a)": [ + "DCH-18" ], - "PE-13": [ - "PES-08" + "Article 18.1(b)": [ + "DCH-18" ], - "PE-13(1)": [ - "PES-08.1" + "Article 18.1(c)": [ + "DCH-18" ], - "PE-13(3)": [ - "PES-08.2" + "Article 18.1(d)": [ + "DCH-18" ], - "PE-13(2)": [ - "PES-08.3" + "Article 18.1(e)": [ + "DCH-18" ], - "PE-14": [ - "PES-09" + "Article 18.3": [ + "DCH-18" ], - "PE-14.a": [ - "PES-09" + "Article 10.2": [ + "DCH-18.2" ], - "PE-14.b": [ - "PES-09" + "Article 10.2(a)": [ + "DCH-18.2" ], - "PE-14-IS.1": [ - "PES-09" + "Article 10.2(b)": [ + "DCH-18.2" ], - "PE-14-IS.2": [ - "PES-09" + "Article 10.2(c)": [ + "DCH-18.2" ], - "PE-14-IS.3": [ - "PES-09" + "Article 10.2(d)": [ + "DCH-18.2" ], - "PE-16": [ - "PES-10" + "Article 10.2(e)": [ + "DCH-18.2" ], - "PE-16-IS.1": [ - "PES-10" + "Article 10.6": [ + "DCH-18.2" ], - "PE-17": [ - "PES-11" + "Article 10.5(b)": [ + "DCH-23", + "PRI-01.6" ], - "PE-17.a": [ - "PES-11" + "Article 17.1(j)": [ + "IRO-10", + "IRO-10.2" ], - "PE-17.b": [ - "PES-11" + "Article 9.8": [ + "IAO-01", + "IAO-02" ], - "PE-17.c": [ - "PES-11" + "Article 10.5(c)": [ + "PRI-01.6", + "PRI-05.4" ], - "PE-17-IS.1": [ - "PES-11" + "Article 10.5(e)": [ + "PRI-05" ], - "PE-4-IS.1": [ - "PES-12" + "Article 10.5(d)": [ + "PRI-05.4" ], - "PE-18": [ - "PES-12" + "Article 10.5(f)": [ + "PRI-14" ], - "PE-4": [ - "PES-12.1" + "Article 17.1(l)": [ + "PRM-03", + "RSK-09" ], - "PE-5": [ - "PES-12.2" + "Article 9.2": [ + "RSK-01" ], - "AR-1": [ - "PRI-01" + "Article 9.4": [ + "RSK-01", + "RSK-06.1" ], - "AR-1.b": [ - "PRI-01" + "Article 9.5": [ + "RSK-01", + "RSK-06.1" ], - "AR-1.c": [ - "PRI-01" + "Article 9.2(c)": [ + "RSK-03", + "RSK-04" ], - "AR-1.d": [ - "PRI-01" + "Article 9.2(d)": [ + "RSK-06" ], - "AR-1.e": [ - "PRI-01" + "Article 9.5(a)": [ + "RSK-06.1" ], - "AR-1.f": [ - "PRI-01" + "Article 9.5(b)": [ + "RSK-06.1", + "RSK-06.2" ], - "AR-1.a": [ - "PRI-01.1" + "Article 26.9": [ + "RSK-10" ], - "TR-2": [ - "PRI-01.2", - "PRI-02.4" + "Article 3": [ + "SEA-02.1" ], - "TR-2.c": [ - "PRI-01.2" + "Article 9.5(c)": [ + "SAT-03" ], - "TR-3": [ - "PRI-01.3" + "Article 8.2": [ + "TDA-21" ], - "TR-3.a": [ - "PRI-01.3" + "Article 10.1": [ + "TDA-21" ], - "TR-3.b": [ - "PRI-01.3" + "Article 23.1(c)": [ + "TDA-21" ], - "TR-1": [ - "PRI-02" + "Article 23.2": [ + "TDA-21" ], - "TR-1.a": [ - "PRI-02" + "Article 23.3": [ + "TDA-21" ], - "TR-1.a.1": [ - "PRI-02" + "Article 23.4": [ + "TDA-21" ], - "TR-1.a.2": [ - "PRI-02" + "Article 23.5": [ + "TDA-21" ], - "TR-1.a.3": [ - "PRI-02" + "Article 23.6": [ + "TDA-21" ], - "TR-1.a.4": [ - "PRI-02" + "Article 23.7": [ + "TDA-21" ], - "TR-1.b": [ - "PRI-02" + "Article 24.1": [ + "TDA-21" ], - "TR-1.b.1": [ - "PRI-02" + "Article 24.2": [ + "TDA-21" ], - "TR-1.b.2": [ - "PRI-02" + "Article 24.3": [ + "TDA-21" ], - "TR-1.b.3": [ - "PRI-02" + "Article 24.4": [ + "TDA-21" ], - "TR-1.b.4": [ - "PRI-02" + "Article 25.1": [ + "TDA-21" ], - "TR-1.b.5": [ - "PRI-02" + "Article 25.1(a)": [ + "TDA-21" ], - "TR-1.b.6": [ - "PRI-02" + "Article 25.1(b)": [ + "TDA-21" ], - "TR-1.c": [ - "PRI-02" + "Article 25.1(c)": [ + "TDA-21" ], - "AP-2": [ - "PRI-02.1" + "Article 25.2": [ + "TDA-21" ], - "DI-2(1)": [ - "PRI-02.3" + "Article 25.4": [ + "TDA-21" ], - "TR-2.a": [ - "PRI-02.4" + "Article 48.1": [ + "TDA-21" ], - "TR-2.b": [ - "PRI-02.4" + "Article 48.2": [ + "TDA-21" ], - "TR-2(1)": [ - "PRI-02.4" + "Article 48.3": [ + "TDA-21" ], - "TR-1(1)": [ - "PRI-02.7" + "Article 48.4": [ + "TDA-21" ], - "IP-1": [ - "PRI-03" + "Article 48.5": [ + "TDA-21" ], - "IP-1.a": [ - "PRI-03" + "Article 53.1(b)(ii)": [ + "TDA-21" ], - "IP-1.b": [ - "PRI-03" + "Article 111.3": [ + "TDA-21" ], - "IP-1.c": [ - "PRI-03" + "Article 11.2": [ + "TDA-22" ], - "IP-1.d": [ - "PRI-03" + "Article 17.1(k)": [ + "TDA-22" ], - "IP-1(1)": [ - "PRI-03" + "Article 23.1(b)": [ + "TDA-22" ], - "AP-1": [ - "PRI-04.1" + "Article 53.1(a)": [ + "TDA-22" + ] + }, + "emea-eu-cyber-resilience-act-2024": { + "Article 13(23)": [ + "GOV-17", + "TDA-01.1" ], - "DI-1(1)": [ - "PRI-04.5" + "Article 19(8)": [ + "GOV-17" ], - "DI-1(2)": [ - "PRI-04.6" + "Article 20(6)": [ + "GOV-17" ], - "DM-2.a": [ - "PRI-05" + "Article 12(1)": [ + "AAT-09.1" ], - "DM-1": [ - "PRI-05.1" + "Article 6": [ + "CPL-01" ], - "DM-1.a": [ - "PRI-05.1" + "Article 6(a)": [ + "CPL-01" ], - "DM-1.b": [ - "PRI-05.1" + "Article 6(b)": [ + "CPL-01" ], - "DM-1.c": [ - "PRI-05.1" + "Article 12(1)(a)": [ + "CPL-01" ], - "DM-3": [ - "PRI-05.1" + "Article 12(1)(b)": [ + "CPL-01" ], - "DM-3.a": [ - "PRI-05.1" + "Article 19(7)": [ + "CPL-01" ], - "DM-3.b": [ - "PRI-05.1" + "Article 23(1)": [ + "CPL-01" ], - "DM-3(1)": [ - "PRI-05.1" + "Article 23(1)(a)": [ + "CPL-01" ], - "DI-2": [ - "PRI-05.2" + "Article 23(1)(b)": [ + "CPL-01" ], - "DI-2.a": [ - "PRI-05.2" + "Article 24(2)": [ + "CPL-01" ], - "DI-2.b": [ - "PRI-05.2" + "Article 13(1)": [ + "CPL-01.3", + "TDA-01.1" ], - "UL-1": [ - "PRI-05.4" + "Article 32(5)": [ + "CPL-01.3" ], - "SE-1": [ - "PRI-05.5" + "Article 12(3)": [ + "CPL-01.4" ], - "SE-1.a": [ - "PRI-05.5" + "Article 13(12)": [ + "CPL-01.4" ], - "SE-1.b": [ - "PRI-05.5" + "Article 19(2)(a)": [ + "CPL-01.4" ], - "IP-2": [ - "PRI-06" + "Article 32(1)": [ + "CPL-01.4", + "IAO-02", + "IAO-02.2" ], - "IP-2.a": [ - "PRI-06" + "Article 32(1)(a)": [ + "CPL-01.4" ], - "IP-2.b": [ - "PRI-06" + "Article 32(1)(b)": [ + "CPL-01.4" ], - "IP-2.c": [ - "PRI-06" + "Article 32(1)(c)": [ + "CPL-01.4" ], - "IP-2.d": [ - "PRI-06" + "Article 32(1)(d)": [ + "CPL-01.4" ], - "IP-3.a": [ - "PRI-06" + "Article 32(3)": [ + "CPL-01.4" ], - "IP-3.b": [ - "PRI-06.1" + "Article 32(3)(a)": [ + "CPL-01.4" ], - "IP-4": [ - "PRI-06.4", - "OPS-03" + "Article 32(3)(b)": [ + "CPL-01.4" ], - "IP-4(1)": [ - "PRI-06.4", - "OPS-03" + "Article 32(6)": [ + "CPL-01.4" ], - "UL-2": [ - "PRI-07" + "Article 12(1)(c)": [ + "CPL-01.5" ], - "UL-2.a": [ - "PRI-07" + "Article 20(5)": [ + "CPL-01.5" ], - "UL-2.b": [ - "PRI-07" + "Article 18(1)": [ + "CPL-01.7" ], - "UL-2.c": [ - "PRI-07" + "Article 53": [ + "CPL-05.2" ], - "UL-2.d": [ - "PRI-07" + "Article 13(17)": [ + "CPL-07", + "TDA-01.1" ], - "AR-3": [ - "PRI-07.1" + "Article 13(13)": [ + "DCH-18", + "TDA-01.1" ], - "AR-3.a": [ - "PRI-07.1" + "Article 19(6)": [ + "DCH-18", + "TDA-01.1" ], - "AR-3.b": [ - "PRI-07.1" + "Article 23(2)": [ + "DCH-18" ], - "PM-14.a": [ - "PRI-08" + "Article 14(5)": [ + "IRO-02.4" ], - "PM-14.a.1": [ - "PRI-08" + "Article 14(5)(a)": [ + "IRO-02.4" ], - "PM-14.a.2": [ - "PRI-08" + "Article 14(5)(b)": [ + "IRO-02.4" ], - "PM-14.b": [ - "PRI-08" + "Article 14(8)": [ + "IRO-10" ], - "AR-4": [ - "PRI-08" + "Article 15(1)": [ + "IRO-10" ], - "AR-4.a": [ - "PRI-08" + "Article 15(2)": [ + "IRO-10" ], - "AR-4.b": [ - "PRI-08" + "Article 14(1)": [ + "IRO-10.2", + "TDA-02.11" ], - "AR-6": [ - "PRI-14" + "Article 14(3)": [ + "IRO-10.2" ], - "DM-2(1)": [ - "PRI-14" + "Article 14(4)(a)": [ + "IRO-10.2" ], - "AU-2-IS.4": [ - "PRI-14.1" + "Article 14(4)(b)": [ + "IRO-10.2" ], - "AR-8": [ - "PRI-14.1" + "Article 14(4)(c)": [ + "IRO-10.2" ], - "AR-8.a": [ - "PRI-14.1" + "Article 14(4)(i)": [ + "IRO-10.2" ], - "AR-8.a.1": [ - "PRI-14.1" + "Article 14(4)(i)(ii)": [ + "IRO-10.2" ], - "AR-8.a.2": [ - "PRI-14.1" + "Article 14(4)(i)(iii)": [ + "IRO-10.2" ], - "AR-8.b": [ - "PRI-14.1" + "Article 13(2)": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-05", + "IAO-06", + "IAO-07" ], - "AR-8.c": [ - "PRI-14.1" + "Article 13(3)": [ + "IAO-02.2", + "IAO-03" ], - "PM-3": [ - "PRM-02" + "Article 13(7)": [ + "IAO-03", + "TDA-04", + "TDA-04.1" ], - "PM-3.a": [ - "PRM-02" + "Article 19(2)(b)": [ + "IAO-03" ], - "PM-3.b": [ - "PRM-02" + "Article 31(1)": [ + "IAO-03", + "TDA-04", + "TDA-04.1" ], - "PM-3.c": [ - "PRM-02" + "Article 31(2)": [ + "IAO-03" ], - "SA-2": [ - "PRM-03" + "Article 31(3)": [ + "IAO-03" ], - "SA-2.a": [ - "PRM-03" + "Article 24(1)": [ + "IAO-03.2", + "TDA-01.1", + "TDA-02", + "TDA-06" ], - "SA-2.b": [ - "PRM-03" + "Article 13(6)": [ + "IAO-04", + "VPM-02" ], - "SA-2.c": [ - "PRM-03" + "Article 13(21)": [ + "IAO-04", + "TDA-01.1" ], - "SA-2.d": [ - "PRM-03" + "Article 13(14)": [ + "PRM-04", + "PRM-07", + "TDA-01.1" ], - "PM-11": [ - "PRM-06" + "Article 13(5)": [ + "TDA-01.1" ], - "PM-11.a": [ - "PRM-06" + "Article 13(8)": [ + "TDA-01.1", + "TDA-02.9" ], - "PM-11.b": [ - "PRM-06" + "Article 13(10)": [ + "TDA-01.1" ], - "SA-3": [ - "PRM-07", - "SEA-07.1" + "Article 13(11)": [ + "TDA-01.1", + "TDA-02.9" ], - "SA-3.a": [ - "PRM-07" + "Article 13(15)": [ + "TDA-01.1" ], - "SA-3.b": [ - "PRM-07" + "Article 13(16)": [ + "TDA-01.1" ], - "SA-3.c": [ - "PRM-07" + "Article 13(18)": [ + "TDA-01.1" ], - "SA-3.d": [ - "PRM-07" + "Article 13(19)": [ + "TDA-01.1" ], - "RA-1.a": [ - "RSK-01" + "Article 13(20)": [ + "TDA-01.1" ], - "RA-1.b": [ - "RSK-01" + "Article 13(22)": [ + "TDA-01.1" ], - "PM-9": [ - "RSK-01" + "Article 19(1)": [ + "TDA-01.1" ], - "PM-9.a": [ - "RSK-01" + "Article 19(2)": [ + "TDA-01.1" ], - "PM-9.b": [ - "RSK-01" + "Article 19(2)(c)": [ + "TDA-01.1" ], - "PM-9.c": [ - "RSK-01" + "Article 19(2)(d)": [ + "TDA-01.1" ], - "RA-2": [ - "RSK-02" + "Article 19(3)": [ + "TDA-01.1" ], - "RA-2.a": [ - "RSK-02" + "Article 19(4)": [ + "TDA-01.1" ], - "RA-2.b": [ - "RSK-02" + "Article 19(5)": [ + "TDA-01.1" ], - "RA-2.e": [ - "RSK-02" + "Article 20(1)": [ + "TDA-01.1" ], - "RA-3.a": [ - "RSK-04" + "Article 20(2)": [ + "TDA-01.1" ], - "RA-3.b": [ - "RSK-04" + "Article 20(2)(a)": [ + "TDA-01.1" ], - "RA-3.c": [ - "RSK-04" + "Article 20(2)(b)": [ + "TDA-01.1" ], - "RA-3.d": [ - "RSK-04" + "Article 20(3)": [ + "TDA-01.1", + "TDA-02.11" ], - "RA-3.e": [ - "RSK-04" + "Article 20(4)": [ + "TDA-01.1", + "TDA-02.11" ], - "RA-3-IS.1": [ - "RSK-04" + "Article 30(1)": [ + "TDA-01.1" ], - "RA-3-IS.2": [ - "RSK-04" + "Article 30(2)": [ + "TDA-01.1" ], - "AR-2": [ - "RSK-10" + "Article 30(3)": [ + "TDA-01.1" ], - "AR-2.a": [ - "RSK-10" + "Article 30(4)": [ + "TDA-01.1" ], - "AR-2.b": [ - "RSK-10" + "Article 13(9)": [ + "TDA-02.9" ], - "SC-7(18)": [ - "SEA-01" + "Article 14(2)(a)": [ + "TDA-02.11" ], - "AR-7": [ - "SEA-01" + "Article 14(2)(b)": [ + "TDA-02.11" ], - "PL-8": [ - "SEA-02" + "Article 14(2)(c)": [ + "TDA-02.11" ], - "PL-8.a": [ - "SEA-02" + "Article 14(2)(i)": [ + "TDA-02.11" ], - "PL-8.a.1": [ - "SEA-02" + "Article 14(2)(i)(ii)": [ + "TDA-02.11" ], - "PL-8.a.2": [ - "SEA-02" + "Article 14(2)(i)(iii)": [ + "TDA-02.11" ], - "PL-8.a.3": [ - "SEA-02" + "Article 13(4)": [ + "TDA-04" + ] + }, + "emea-eu-cyber-resilience-act-annex-i-2024": { + "Annex I, Part II": [ + "CPL-01" ], - "PL-8.b": [ - "SEA-02" + "Annex I, Part I(2)": [ + "IAO-01", + "IAO-02.2" ], - "PL-8.c": [ - "SEA-02" + "Annex I, Part II(3)": [ + "IAO-01", + "IAO-02.2", + "IAO-04", + "TDA-02.9" ], - "PM-7": [ - "SEA-02" + "Annex I, Part II(2)": [ + "IAO-04", + "TDA-01.1", + "TDA-02.9", + "VPM-02" ], - "SC-32": [ - "SEA-03.1" + "Annex I, Part I(2)(g)": [ + "PRI-01.11", + "TDA-01.1" ], - "SC-32-iS": [ - "SEA-03.1" + "Annex I, Part I(1)": [ + "TDA-01.1", + "TDA-02.12" ], - "SC-2": [ - "SEA-03.2" + "Annex I, Part I(2)(h)": [ + "TDA-01.1", + "TDA-06" ], - "SC-39": [ - "SEA-04" + "Annex I, Part I(2)(i)": [ + "TDA-01.1", + "TDA-06" ], - "SC-4": [ - "SEA-05" + "Annex I, Part I(2)(j)": [ + "TDA-01.1", + "TDA-06" ], - "SC-4-IS.1": [ - "SEA-05" + "Annex I, Part I(2)(k)": [ + "TDA-01.1", + "TDA-06" ], - "SC-4-IS.2": [ - "SEA-05" + "Annex I, Part I(2)(m)": [ + "TDA-01.1" ], - "SI-16": [ - "SEA-10" + "Annex I, Part II(1)": [ + "TDA-01.1", + "TDA-04.2" ], - "AC-8": [ - "SEA-18" + "Annex I, Part I(2)(a)": [ + "TDA-01.3", + "TDA-02", + "TDA-02.8" ], - "AC-8.a": [ - "SEA-18" + "Annex I, Part I(2)(e)": [ + "TDA-02", + "TDA-02.4", + "TDA-06" ], - "AC-8.b": [ - "SEA-18" + "Annex I, Part I(2)(f)": [ + "TDA-02", + "TDA-02.4", + "TDA-06" ], - "AC-8.c": [ - "SEA-18" + "Annex I, Part I(2)(b)": [ + "TDA-02.4" ], - "AC-8.c.1": [ - "SEA-18" + "Annex I, Part I(2)(d)": [ + "TDA-02.8" ], - "AC-8.c.2": [ - "SEA-18" + "Annex I, Part I(2)(c)": [ + "TDA-02.9" ], - "AC-8.c.3": [ - "SEA-18" + "Annex I, Part I(2)(l)": [ + "TDA-02.9" ], - "AU-8.a": [ - "SEA-20" + "Annex I, Part II(4)": [ + "TDA-02.9" ], - "AU-8(1)": [ - "SEA-20" + "Annex I, Part II(5)": [ + "TDA-02.9", + "TDA-02.11" ], - "AU-8(1)-IS.1": [ - "SEA-20" + "Annex I, Part II(6)": [ + "TDA-02.9", + "TDA-02.11" ], - "AC-1.b": [ - "OPS-01.1" + "Annex I, Part II(7)": [ + "TDA-02.9" ], - "AT-1.b": [ - "OPS-01.1" + "Annex I, Part II(8)": [ + "TDA-02.9" + ] + }, + "emea-eu-eba-ict-srm-2025": { + "3.4.1.30": [ + "GOV-01" ], - "AU-1.b": [ - "OPS-01.1" + "3.2.1.2": [ + "GOV-01.1", + "HRS-03" ], - "CA-1.b": [ - "OPS-01.1" + "3.2.1.3": [ + "GOV-01.1", + "HRS-01", + "HRS-13", + "HRS-13.1", + "HRS-13.3", + "PRM-03" ], - "CA-1.d": [ - "OPS-01.1" + "3.2.1.4": [ + "GOV-01.1", + "GOV-08", + "PRM-01.1" ], - "CM-1.b": [ - "OPS-01.1" + "3.3.1.13(e)": [ + "GOV-01.2", + "RSK-01" ], - "CP-1.b": [ - "OPS-01.1" + "3.3.5.24": [ + "GOV-01.2" ], - "IA-1.b": [ - "OPS-01.1" + "3.4.6.48": [ + "GOV-01.3", + "CPL-02" ], - "IR-1.b": [ - "OPS-01.1" + "3.4.1.28": [ + "GOV-02" ], - "MA-1.b": [ - "OPS-01.1" + "3.4.5.38": [ + "GOV-02", + "MON-01.2", + "MON-02", + "MON-11.3", + "MON-16" ], - "MP-1.b": [ + "3.5.50": [ + "GOV-02", "OPS-01.1" ], - "MP-1-IS.2": [ - "OPS-01.1" + "3.3.1.14": [ + "GOV-03", + "RSK-01" ], - "PE-1.b": [ - "OPS-01.1" + "3.3.1.11": [ + "GOV-04", + "GOV-04.1", + "CPL-02", + "CPL-02.1" ], - "PL-1.b": [ - "OPS-01.1" + "3.3.1.12": [ + "GOV-04.1", + "HRS-03" ], - "PS-1.b": [ - "OPS-01.1" + "3.5.51": [ + "GOV-05" ], - "SA-1.b": [ - "OPS-01.1" + "3.7.5.91": [ + "GOV-06", + "BCD-01", + "BCD-10.4", + "IRO-10", + "IRO-10.2", + "IRO-14", + "IRO-16" ], - "SC-1.b": [ - "OPS-01.1" + "3.2.2.5": [ + "GOV-08", + "PRM-01.1" ], - "SI-1.b": [ - "OPS-01.1" + "3.3.4.22": [ + "GOV-15", + "GOV-15.1" ], - "AT-1.e": [ - "SAT-01" + "3.4.1.30(a)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "AT-1-IS.1": [ - "SAT-01" + "3.4.1.30(b)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "AT-2": [ - "SAT-02" + "3.4.1.30(c)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "AT-2.a": [ - "SAT-02" + "3.4.1.30(d)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "AT-2.b": [ - "SAT-02" + "3.4.1.30(e)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "AT-2-IS.1": [ - "SAT-02" + "3.4.1.30(f)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "AT-2-IS.2": [ - "SAT-02" + "3.4.1.30(g)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" ], - "AT-3": [ - "SAT-03" + "3.5.53": [ + "AST-01", + "AST-02" ], - "AT-3.a": [ - "SAT-03" + "3.5.54": [ + "AST-01", + "AST-01.1", + "AST-01.2", + "AST-02", + "AST-02.9", + "DCH-02" ], - "AT-3.b": [ - "SAT-03" + "3.3.3.17": [ + "AST-01.1", + "AST-04.1", + "DCH-02" ], - "AT-3-IS.1": [ - "SAT-03" + "3.3.3.18": [ + "AST-01.1", + "AST-04.1", + "DCH-02" ], - "AR-5": [ - "SAT-03.3" + "3.3.2.16": [ + "AST-02", + "BCD-02", + "TPM-02" ], - "AR-5.a": [ - "SAT-03.3" + "3.7.77": [ + "BCD-01" ], - "AR-5.b": [ - "SAT-03.3" + "3.7.1.78": [ + "BCD-01", + "BCD-02", + "RSK-08" ], - "AR-5.c": [ - "SAT-03.3" + "3.7.1.79": [ + "BCD-01", + "SEA-01", + "SEA-02", + "SEA-03" ], - "AT-4": [ - "SAT-04" + "3.7.2.80": [ + "BCD-01" ], - "AT-4.a": [ - "SAT-04" + "3.7.3.83": [ + "BCD-01", + "BCD-01.7" ], - "AT-4.b": [ - "SAT-04" + "3.7.3.85": [ + "BCD-01" ], - "SA-4": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "3.7.3.86": [ + "BCD-01", + "BCD-10.3", + "TPM-03" ], - "SA-4.a": [ - "TDA-01" + "3.7.2.81": [ + "BCD-01.4" ], - "SA-4.b": [ - "TDA-01" + "3.7.2.82": [ + "BCD-01.7" ], - "SA-4.c": [ - "TDA-01" + "3.7.3.84": [ + "BCD-01.7" ], - "SA-4.d": [ - "TDA-01" + "3.7.3.84(a)": [ + "BCD-01.7" ], - "SA-4.e": [ - "TDA-01" + "3.7.3.84(b)": [ + "BCD-01.7" ], - "SA-4.f": [ - "TDA-01" + "3.7.3.84(c)": [ + "BCD-01.7", + "BCD-05" ], - "SA-4.g": [ - "TDA-01" + "3.7.4.87": [ + "BCD-04" ], - "SA-4.h": [ - "TDA-01" + "3.7.4.89": [ + "BCD-04" ], - "SA-4-IS.1": [ - "TDA-01" + "3.7.4.89(a)": [ + "BCD-04" ], - "SA-4-IS.2": [ - "TDA-01" + "3.7.4.89(b)": [ + "BCD-04" ], - "SA-4-IS.2.a": [ - "TDA-01" + "3.7.4.89(c)": [ + "BCD-04" ], - "SA-4-IS.2.b": [ - "TDA-01" + "3.7.4.90": [ + "BCD-04", + "BCD-05", + "BCD-06" ], - "SA-4-IS.2.c": [ - "TDA-01" + "3.7.4.88": [ + "BCD-05", + "BCD-06" ], - "SA-4-IS.2.d": [ - "TDA-01" + "3.5.57": [ + "BCD-11" ], - "SA-4-IS.2.e": [ - "TDA-01" + "3.5.58": [ + "BCD-11.2" ], - "SA-4(9)": [ - "TDA-02.1" + "3.5.56": [ + "CAP-01" ], - "SA-5.a": [ - "TDA-04" + "3.4.4.37": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "CHG-02.3", + "CHG-03" ], - "SA-5.a.1": [ - "TDA-04" + "3.6.3.75": [ + "CHG-01", + "CHG-02" ], - "SA-5.a.2": [ - "TDA-04" + "3.6.3.76": [ + "CHG-03" ], - "SA-5.a.3": [ - "TDA-04" + "3.1.1": [ + "CPL-01" ], - "SA-5.b": [ - "TDA-04" + "3.8.92": [ + "CPL-01" ], - "SA-5.b.1": [ - "TDA-04" + "3.8.93": [ + "CPL-01" ], - "SA-5.b.2": [ - "TDA-04" + "3.8.94": [ + "CPL-01" ], - "SA-5.b.3": [ - "TDA-04" + "3.8.95": [ + "CPL-01" ], - "SA-5.c": [ - "TDA-04" + "3.8.96": [ + "CPL-01" ], - "SA-5-IS.1": [ - "TDA-04" + "3.8.97": [ + "CPL-01" ], - "SA-5-IS.2": [ - "TDA-04" + "3.8.98": [ + "CPL-01" ], - "SA-5-IS.3": [ - "TDA-04" + "3.3.6.27": [ + "CPL-01.1", + "IAO-05" ], - "SA-5-IS.4": [ - "TDA-04" + "3.3.3.19": [ + "CPL-02" ], - "CM-4(1)": [ - "TDA-08" + "3.3.6.25": [ + "CPL-02", + "CPL-02.1", + "CPL-03.1" ], - "SA-11": [ - "TDA-09" + "3.4.6.41": [ + "CPL-02", + "CPL-03", + "CPL-03.1", + "CPL-03.2" ], - "SA-11.a": [ - "TDA-09" + "3.4.6.46": [ + "CPL-02", + "CFG-02.1" ], - "SA-11.b": [ - "TDA-09" + "3.3.6.26": [ + "CPL-03", + "CPL-03.2" ], - "SA-11.c": [ - "TDA-09" + "3.4.6.44": [ + "CPL-03" ], - "SA-11.d": [ - "TDA-09" + "3.4.4.36(b)": [ + "CFG-02" ], - "SA-11.e": [ - "TDA-09" + "3.4.5.39": [ + "MON-01", + "MON-01.2", + "MON-02", + "MON-02.1" ], - "SA-11-IS.1": [ - "TDA-09" + "3.5.52": [ + "MON-01", + "MON-02", + "MON-02.2" ], - "SA-11-IS.3": [ - "TDA-09" + "3.4.4.36(e)": [ + "MON-01.7", + "END-06" ], - "SA-11(1)": [ - "TDA-09.2" + "3.4.5.38(a)": [ + "MON-02.1" ], - "SA-11(1)-IS.1": [ - "TDA-09.2" + "3.4.5.38(b)": [ + "MON-02.1" + ], + "3.4.5.38(c)": [ + "MON-02.1" ], - "SA-11(1)-IS.2": [ - "TDA-09.2" + "3.4.5.40": [ + "MON-02.1" ], - "SA-10": [ - "TDA-14" + "3.4.2.31(c)": [ + "MON-16.4", + "IAC-15" ], - "SA-10.a": [ - "TDA-14" + "3.4.2.31(d)": [ + "MON-16.4", + "IAC-16" ], - "SA-10.b": [ - "TDA-14" + "3.4.4.36(f)": [ + "CRY-01", + "CRY-03", + "CRY-05" ], - "SA-10.c": [ - "TDA-14" + "3.4.4.36(d)": [ + "END-01" ], - "SA-10.d": [ - "TDA-14" + "3.4.1.29": [ + "HRS-03" ], - "SA-10.e": [ - "TDA-14" + "3.4.2.31(g)": [ + "IAC-01", + "IAC-01.2" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "3.4.2.31(e)": [ + "IAC-07", + "IAC-17" ], - "SA-22.a": [ - "TDA-17" + "3.4.2.32": [ + "IAC-08" ], - "SA-22.b": [ - "TDA-17" + "3.4.2.31(b)": [ + "IAC-15.5" ], - "SI-11": [ - "TDA-19" + "3.4.2.31(f)": [ + "IAC-17" ], - "SI-11.a": [ - "TDA-19" + "3.4.2.31(a)": [ + "IAC-21" ], - "SI-11.b": [ - "TDA-19" + "3.5.1.59": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "SA-9": [ - "TPM-04" + "3.5.1.60": [ + "IRO-01", + "IRO-02", + "IRO-04" ], - "SA-9.a": [ - "TPM-04" + "3.5.1.60(a)": [ + "IRO-02" ], - "SA-9.b": [ - "TPM-04" + "3.5.1.60(b)": [ + "IRO-02" ], - "SA-9.c": [ - "TPM-04" + "3.5.1.60(c)": [ + "IRO-02" ], - "SA-9.d": [ - "TPM-04" + "3.5.1.60(d)": [ + "IRO-02" ], - "SA-9.e": [ - "TPM-04" + "3.5.1.60(d)(i)": [ + "IRO-02" ], - "SA-9-IS.1": [ - "TPM-04" + "3.5.1.60(d)(ii)": [ + "IRO-02" ], - "SA-9-IS.2": [ - "TPM-04" + "3.5.1.60(e)": [ + "IRO-02" ], - "SA-9-IS.3": [ - "TPM-04" + "3.5.1.60(f)": [ + "IRO-02" ], - "SA-9(1)": [ - "TPM-04.1" + "3.5.1.60(f)(i)": [ + "IRO-02" ], - "SA-9(1)-IS.1": [ - "TPM-04.1" + "3.5.1.60(f)(ii)": [ + "IRO-02" ], - "SA-9(2)": [ - "TPM-04.2" + "3.4.6.42": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-03.2", + "IAO-04", + "IAO-05", + "IAO-06", + "IAO-07" ], - "CM-3-IS.4": [ - "TPM-05" + "3.4.6.43": [ + "IAO-01" ], - "CM-2(1)-IS": [ - "TPM-08" + "3.4.6.43(a)": [ + "IAO-01" ], - "CM-2(1)-IS.1": [ - "TPM-08" + "3.4.6.43(b)": [ + "IAO-01" ], - "CM-2(1)-IS.2": [ - "TPM-08" + "3.4.6.45": [ + "IAO-01" ], - "CM-2(1)-IS.3": [ - "TPM-08" + "3.6.2.69": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-03.2", + "IAO-04", + "IAO-05", + "IAO-06", + "IAO-07" ], - "PM-16": [ - "THR-01" + "3.6.2.70": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-03.2", + "IAO-04", + "IAO-05", + "IAO-06", + "IAO-07" ], - "SI-5.a": [ - "THR-03" + "3.6.2.71": [ + "IAO-02", + "IAO-02.2" ], - "SI-5.b": [ - "THR-03" + "3.4.6.47": [ + "IAO-02.2" ], - "SI-5.c": [ - "THR-03" + "3.3.1.13(d)": [ + "IAO-05", + "RSK-01", + "RSK-04.1" ], - "SI-5.d": [ - "THR-03" + "3.4.4.36(c)": [ + "NET-06" ], - "PM-12": [ - "THR-04" + "3.4.3.33": [ + "PES-01" ], - "AT-2(2)": [ - "THR-05" + "3.4.3.34": [ + "PES-02", + "PES-02.1" ], - "SI-2.a": [ - "VPM-01" + "3.4.3.35": [ + "PES-07", + "PES-07.1", + "PES-07.5", + "PES-08", + "PES-09" ], - "SI-2.b": [ - "VPM-01" + "3.6.1.61": [ + "PRM-01", + "PRM-02", + "PRM-04" ], - "SI-2.c": [ - "VPM-01" + "3.6.1.62": [ + "PRM-01", + "PRM-02", + "PRM-02.1", + "PRM-04" ], - "SI-2.d": [ - "VPM-01" + "3.6.1.66": [ + "PRM-01", + "PRM-02", + "PRM-02.1", + "PRM-04" ], - "SI-2(1)": [ - "VPM-05.1" + "3.6.2.74": [ + "PRM-01", + "PRM-04", + "TDA-01" ], - "SI-2(2)": [ - "VPM-05.2" + "3.2.2.5(a)": [ + "PRM-01.1" ], - "RA-5": [ - "VPM-06", - "VPM-06.1" + "3.2.2.5(b)": [ + "PRM-01.1" ], - "RA-5.a": [ - "VPM-06" + "3.2.2.5(c)": [ + "PRM-01.1" ], - "RA-5.b": [ - "VPM-06" + "3.2.2.6": [ + "PRM-01.1", + "OPS-02" ], - "RA-5.b.1": [ - "VPM-06" + "3.3.1.10": [ + "PRM-04", + "RSK-01", + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-05" ], - "RA-5.b.2": [ - "VPM-06" + "3.3.1.13(f)": [ + "PRM-04", + "PRM-07", + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-07" ], - "RA-5.b.3": [ - "VPM-06" + "3.6.1.63": [ + "PRM-04" ], - "RA-5.c": [ - "VPM-06" + "3.6.1.63(a)": [ + "PRM-04" ], - "RA-5.d": [ - "VPM-06" + "3.6.1.63(b)": [ + "PRM-04" ], - "RA-5.e": [ - "VPM-06" + "3.6.1.63(c)": [ + "PRM-04" ], - "RA-5-IS.1": [ - "VPM-06" + "3.6.1.63(d)": [ + "PRM-04" ], - "RA-5-IS.2": [ - "VPM-06" + "3.6.1.63(e)": [ + "PRM-04" ], - "RA-5(1)": [ - "VPM-06" + "3.6.1.63(f)": [ + "PRM-04" ], - "RA-5(2)": [ - "VPM-06.1" + "3.6.1.64": [ + "PRM-04", + "PRM-05", + "PRM-06" ], - "RA-5(3)": [ - "VPM-06.2" + "3.6.1.65": [ + "PRM-04" ], - "RA-5(5)": [ - "VPM-06.3" - ] - }, - "usa-federal-nerc-cip-2024": { - "CIP-003-8 1.1.4": [ - "GOV-01", - "SEA-01" + "3.6.2.68": [ + "PRM-05", + "PRM-06" ], - "CIP-002-5.1a 2.1": [ - "GOV-03" + "3.3.2.15": [ + "PRM-06" ], - "CIP-002-5.1a 2.2": [ - "GOV-03" + "3.5.55": [ + "PRM-07", + "SEA-07.1", + "TPM-05.4", + "TPM-05.5" ], - "CIP-003-8 R1": [ - "GOV-03" + "3.2.3.7": [ + "RSK-01", + "TPM-01" ], - "CIP-003-8 R4": [ - "GOV-04" + "3.3.1.13": [ + "RSK-01" ], - "CIP-003-8 1.1": [ - "AST-01" + "3.3.4.23": [ + "RSK-01", + "RSK-06", + "RSK-06.2" ], - "CIP-003-8 1.2.5": [ - "AST-01" + "3.3.1.13(a)": [ + "RSK-01.5" ], - "CIP-003-8 R2": [ - "AST-01" + "3.3.1.13(b)": [ + "RSK-03", + "RSK-04" ], - "CIP-011-3 R1": [ - "AST-01" + "3.3.1.13(c)": [ + "RSK-06", + "RSK-06.1", + "RSK-06.2" ], - "CIP-011-3 1.2": [ - "AST-01", - "AST-01.1", - "DCH-01", - "END-01" + "3.3.3.20": [ + "RSK-08" ], - "CIP-003-8 R3": [ - "AST-01.2" + "3.4.2.31": [ + "OPS-01.1" ], - "CIP-011-3 1.1": [ - "AST-02" + "3.4.4.36": [ + "OPS-01.1" ], - "CIP-011-3 2.2": [ - "AST-30" + "3.4.7.49": [ + "SAT-01", + "SAT-02", + "SAT-03" ], - "CIP-003-8 1.1.6": [ - "BCD-01" + "3.6.2.67": [ + "TDA-01" ], - "CIP-009-6 R1": [ - "BCD-01" + "3.6.2.73": [ + "TDA-04", + "TDA-20" ], - "CIP-009-6 R2": [ - "BCD-01" + "3.6.2.72": [ + "TDA-07", + "TDA-08" ], - "CIP-009-6 R3": [ - "BCD-01" + "3.2.3.8": [ + "TPM-05", + "TPM-05.2", + "TPM-05.4" ], - "CIP-009-6 1.1": [ - "BCD-01.5" + "3.2.3.8(a)": [ + "TPM-05" ], - "CIP-009-6 2.1": [ - "BCD-04" + "3.2.3.8(b)": [ + "TPM-05", + "TPM-11" ], - "CIP-009-6 2.3": [ - "BCD-04" + "3.2.3.9": [ + "TPM-05.6", + "TPM-08" ], - "CIP-009-6 3.1": [ - "BCD-04" + "3.3.3.21": [ + "THR-03", + "VPM-01" ], - "CIP-009-6 3.1.1": [ - "BCD-05" + "3.4.4.36(a)": [ + "VPM-01" + ] + }, + "emea-eu-dora-2023": { + "Article 5.1": [ + "GOV-01" ], - "CIP-009-6 3.1.2": [ - "BCD-05" + "Article 9.4": [ + "GOV-01" ], - "CIP-009-6 3.1.3": [ - "BCD-06" + "Article 16.1(a)": [ + "GOV-01" ], - "CIP-009-6 3.2.1": [ - "BCD-06" + "Article 16.1(b)": [ + "GOV-01" ], - "CIP-009-6 3.2": [ - "BCD-06.1" + "Article 16.1(c)": [ + "GOV-01" ], - "CIP-009-6 3.2.2": [ - "BCD-06.2" + "Article 16.1(d)": [ + "GOV-01" ], - "CIP-009-6 1.3": [ - "BCD-11" + "Article 16.1(e)": [ + "GOV-01" ], - "CIP-009-6 1.4": [ - "BCD-11", - "BCD-11.1" + "Article 16.1(f)": [ + "GOV-01" ], - "CIP-009-6 2.2": [ - "BCD-11.1" + "Article 16.1(g)": [ + "GOV-01" ], - "CIP-003-8 1.1.7": [ - "CHG-01", - "CFG-01", - "VPM-01" + "Article 16.1(h)": [ + "GOV-01" ], - "CIP-010-4 1.4.2": [ - "CHG-02.2" + "Article 16.2": [ + "GOV-01" ], - "CIP-010-4 1.5.1": [ - "CHG-02.2" + "Article 5.2": [ + "GOV-01.1", + "GOV-04" ], - "CIP-010-4 1.5.2": [ - "CHG-02.2" + "Article 5.2(a)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-003-8 1.1.9": [ - "CPL-01" + "Article 5.2(b)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-003-8 1.2.6": [ - "CPL-01" + "Article 5.2(c)": [ + "GOV-01.1", + "GOV-04", + "HRS-03" ], - "CIP-006-6 R3": [ - "CPL-03.2" + "Article 5.2(d)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-006-6 3.1": [ - "CPL-03.2" + "Article 5.2(e)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-010-3 R1": [ - "CFG-01" + "Article 5.2(f)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-010-4 1.1": [ - "CFG-02" + "Article 5.2(g)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-010-4 1.1.1": [ - "CFG-02" + "Article 5.2(h)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-010-4 1.1.2": [ - "CFG-02" + "Article 5.2(i)(i)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-010-4 1.1.3": [ - "CFG-02" + "Article 5.2(i)(ii)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-010-4 1.1.4": [ - "CFG-02" + "Article 5.2(i)(iii)": [ + "GOV-01.1", + "GOV-04" ], - "CIP-010-4 1.1.5": [ - "CFG-02" + "Article 5.2(i)": [ + "GOV-01.2" ], - "CIP-010-4 2.1": [ - "CFG-02", - "CFG-02.1" + "Article 13.5": [ + "GOV-01.2" ], - "CIP-010-4 1.3": [ - "CFG-02.1" + "Article 6.2": [ + "GOV-02", + "RSK-01", + "OPS-01.1" ], - "CIP-010-4 1.2": [ - "CFG-02.7" + "Article 9.4(a)": [ + "GOV-02" ], - "CIP-010-4 1.4": [ - "CFG-02.7" + "Article 9.4(d)": [ + "GOV-02", + "IAC-01" ], - "CIP-010-4 1.4.3": [ - "CFG-02.7" + "Article 9.4(e)": [ + "GOV-02", + "CHG-01", + "CHG-02", + "OPS-01.1" ], - "CIP-010-4 1.5": [ - "CFG-02.7" + "Article 9.4(f)": [ + "GOV-02", + "VPM-01", + "VPM-05" ], - "CIP-010-4 1.6": [ - "CFG-02.7" + "Article 5.3": [ + "GOV-04" ], - "CIP-010-4 1.4.1": [ - "CFG-02.9" + "Article 13.4": [ + "GOV-05" ], - "CIP-010-4 1.6.1": [ - "CFG-02.9" + "Article 31.4": [ + "GOV-06" ], - "CIP-010-4 1.6.2": [ - "CFG-02.9" + "Article 45.1": [ + "GOV-07", + "THR-01" ], - "CIP-007-6 1.1": [ - "CFG-03" + "Article 45.1(a)": [ + "GOV-07", + "THR-01" ], - "CIP-007-6 4.1": [ - "MON-01.4", - "MON-03" + "Article 45.1(b)": [ + "GOV-07", + "THR-01" ], - "CIP-007-6 4.2": [ - "MON-01.4" + "Article 45.1(c)": [ + "GOV-07", + "THR-01" ], - "CIP-007-6 4.1.1": [ - "MON-03" + "Article 45.2": [ + "GOV-07", + "THR-01" ], - "CIP-007-6 4.1.2": [ - "MON-03" + "Article 7": [ + "GOV-15" ], - "CIP-007-6 4.1.3": [ - "MON-03" + "Article 7(a)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "PRM-01", + "PRM-02", + "PRM-03", + "PRM-04", + "PRM-05", + "PRM-07" ], - "CIP-007-6 4.2.2": [ - "MON-05" + "Article 7(b)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "PRM-01", + "PRM-02", + "PRM-03", + "PRM-04", + "PRM-05", + "PRM-07" ], - "CIP-006-6 1.9": [ - "MON-10", - "DCH-18" + "Article 7(c)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "PRM-01", + "PRM-02", + "PRM-03", + "PRM-04", + "PRM-05", + "PRM-07" ], - "CIP-006-6 2.3": [ - "MON-10" + "Article 7(d)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "PRM-01", + "PRM-02", + "PRM-03", + "PRM-04", + "PRM-05", + "PRM-07" ], - "CIP-007-6 4.3": [ - "MON-10" + "Article 9.3": [ + "GOV-15" ], - "CIP-006-6 1.4": [ - "MON-16.3", - "PES-03.3", - "PES-05" + "Article 8.5": [ + "AST-01.1" ], - "CIP-007-6 4.4": [ - "MON-17" + "Article 8.4": [ + "AST-02", + "AST-04", + "BCD-02", + "TPM-02" ], - "CIP-006-6 1.10": [ - "CRY-01", - "PES-03", - "PES-12", - "PES-12.1" + "Article 8.6": [ + "AST-02", + "AST-02.1" ], - "CIP-003-8 1.1.8": [ - "DCH-01" + "Article 11.1": [ + "BCD-01" ], - "CIP-011-3 2.1": [ - "DCH-09" + "Article 11.2": [ + "BCD-01" ], - "CIP-007-6 3.1": [ - "END-04", - "END-14.5" + "Article 11.2(a)": [ + "BCD-01" ], - "CIP-007-6 3.2": [ - "END-04" + "Article 11.2(b)": [ + "BCD-01" ], - "CIP-007-6 3.3": [ - "END-04", - "END-04.4" + "Article 11.2(c)": [ + "BCD-01" ], - "CIP-007-6 4.2.1": [ - "END-04" + "Article 11.2(d)": [ + "BCD-01" ], - "CIP-007-6 1.2": [ - "END-12" + "Article 11.2(e)": [ + "BCD-01" ], - "CIP-003-8 1.1.1": [ - "HRS-01" + "Article 11.3": [ + "BCD-01" ], - "CIP-004-7 R3": [ - "HRS-01", - "RSK-04" + "Article 11.4": [ + "BCD-01", + "BCD-04" ], - "CIP-004-7 5.3": [ - "HRS-01.1", - "IAC-20.6" + "Article 11.5": [ + "BCD-01", + "RSK-08" ], - "CIP-004-7 5.4": [ - "HRS-01.1" + "Article 11.6(a)": [ + "BCD-01", + "BCD-04" ], - "CIP-004-7 6.3": [ - "HRS-01.1", - "IAC-07" + "Article 11.6(b)": [ + "BCD-01", + "BCD-04" ], - "CIP-008-6 1.3": [ - "HRS-03", - "IRO-07" + "Article 11.7": [ + "BCD-01" ], - "CIP-009-6 1.2": [ - "HRS-03" + "Article 11.8": [ + "BCD-01" ], - "CIP-004-7 R2": [ - "HRS-03.1", - "SAT-02" + "Article 11.9": [ + "BCD-01" ], - "CIP-004-7 2.2": [ - "HRS-03.1", - "SAT-02", - "SAT-03" + "Article 11.10": [ + "BCD-01" ], - "CIP-004-7 3.1": [ - "HRS-04" + "Article 11.11": [ + "BCD-01" ], - "CIP-004-7 3.2": [ - "HRS-04" + "Article 12.1": [ + "BCD-01", + "BCD-11" ], - "CIP-004-7 3.2.1": [ - "HRS-04" + "Article 12.1(a)": [ + "BCD-01", + "BCD-11" ], - "CIP-004-7 3.2.2": [ - "HRS-04" + "Article 12.1(b)": [ + "BCD-01", + "BCD-11" ], - "CIP-004-7 3.3": [ - "HRS-04" + "Article 12.6": [ + "BCD-01.4" ], - "CIP-004-7 3.4": [ - "HRS-04" + "Article 11.6 (end)": [ + "BCD-04" ], - "CIP-004-7 3.5": [ - "HRS-04" + "Article 24.1": [ + "BCD-04" ], - "CIP-003-8 1.1.2": [ - "IAC-01", - "NET-01" + "Article 24.2": [ + "BCD-04" ], - "CIP-003-8 1.2.3": [ - "IAC-01" + "Article 24.3": [ + "BCD-04" ], - "CIP-004-7 R4": [ - "IAC-01" + "Article 24.4": [ + "BCD-04" ], - "CIP-004-7 4.1.1": [ - "IAC-01" + "Article 24.5": [ + "BCD-04" ], - "CIP-004-7 R6": [ - "IAC-01" + "Article 24.6": [ + "BCD-04" ], - "CIP-007-6 5.1": [ - "IAC-01", - "IAC-01.2" + "Article 13.2": [ + "BCD-05", + "IRO-13" ], - "CIP-007-6 5.2": [ - "IAC-01.3" + "Article 13.2(a)": [ + "BCD-05", + "IRO-13" ], - "CIP-005-7 1.4": [ - "IAC-04" + "Article 13.2(b)": [ + "BCD-05", + "IRO-13" ], - "CIP-005-7 2.3": [ - "IAC-06", - "NET-14" + "Article 13.2(c)": [ + "BCD-05", + "IRO-13" ], - "CIP-004-7 6.1.1": [ - "IAC-07" + "Article 13.2(d)": [ + "BCD-05", + "IRO-13" ], - "CIP-004-7 6.1.2": [ - "IAC-07", - "PES-02" + "Article 13.3": [ + "BCD-05", + "IRO-13" ], - "CIP-004-7 4.1": [ - "IAC-08" + "Article 12.5": [ + "BCD-09" ], - "CIP-007-6 5.6": [ - "IAC-10" + "Article 12.5(a)": [ + "BCD-09", + "BCD-09.1" ], - "CIP-007-6 5.5.1": [ - "IAC-10.1" + "Article 12.5(b)": [ + "BCD-09" ], - "CIP-007-6 5.5.2": [ - "IAC-10.1" + "Article 12.5(c)": [ + "BCD-09", + "BCD-09.2" ], - "CIP-007-6 5.4": [ - "IAC-10.8" + "Article 12.2": [ + "BCD-11", + "BCD-11.1", + "BCD-11.5" ], - "CIP-007-6 5.3": [ - "IAC-15", - "IAC-15.5" + "Article 12.7": [ + "BCD-11.1", + "BCD-11.5" ], - "CIP-004-7 4.3": [ - "IAC-17" + "Article 12.3": [ + "BCD-11.2", + "BCD-11.6" ], - "CIP-004-7 6.2": [ - "IAC-17" + "Article 12.4": [ + "BCD-11.7", + "BCD-12.2" ], - "CIP-004-7 6.2.1": [ - "IAC-17" + "Article 4.1": [ + "CPL-01" ], - "CIP-004-7 6.2.2": [ - "IAC-17" + "Article 4.2": [ + "CPL-01" ], - "CIP-004-7 R5": [ - "IAC-20.6" + "Article 4.3": [ + "CPL-01" ], - "CIP-004-7 5.1": [ - "IAC-20.6" + "Article 5.4": [ + "CPL-01" ], - "CIP-004-7 5.2": [ - "IAC-20.6" + "Article 23": [ + "CPL-01.2" ], - "CIP-013-2 1.2.3": [ - "IAC-20.6" + "Article 9.3(a)": [ + "CFG-01", + "CFG-02", + "SEA-01", + "SEA-02", + "SEA-03" ], - "CIP-007-6 5.7": [ - "IAC-22" + "Article 9.3(b)": [ + "CFG-01", + "CFG-02", + "SEA-01", + "SEA-02", + "SEA-03" ], - "CIP-005-7 2.5": [ - "IAC-25", - "NET-14.6", - "NET-14.8" + "Article 9.3(c)": [ + "CFG-01", + "CFG-02", + "SEA-01", + "SEA-02", + "SEA-03" ], - "CIP-005-7 3.2": [ - "IAC-25", - "NET-14.6", - "NET-14.8" + "Article 9.3(d)": [ + "CFG-01", + "CFG-02", + "SEA-01", + "SEA-02", + "SEA-03" ], - "CIP-004-7 6.1": [ - "IAC-28.1" + "Article 10.3": [ + "MON-01" ], - "CIP-003-8 1.1.5": [ - "IRO-01" + "Article 10.1": [ + "MON-16" ], - "CIP-003-8 1.2.4": [ - "IRO-01" + "Article 9.4(c)": [ + "IAC-21" ], - "CIP-008-6 1.1": [ + "Article 9.4(b)": [ "IRO-01", "IRO-02", - "IRO-02.4", - "IRO-04" - ], - "CIP-008-6 3.2": [ - "IRO-01" + "IRO-02.1", + "IRO-02.6" ], - "CIP-008-6 1.2.1": [ + "Article 14.1": [ + "IRO-01", "IRO-02", - "IRO-02.4", - "IRO-03" + "IRO-07", + "IRO-10", + "IRO-11" ], - "CIP-008-6 1.4": [ + "Article 14.2": [ + "IRO-01", "IRO-02", - "IRO-04" + "IRO-07", + "IRO-10", + "IRO-11" ], - "CIP-008-6 1.2.2": [ - "IRO-02.4", - "IRO-03" + "Article 14.3": [ + "IRO-01", + "IRO-02", + "IRO-07", + "IRO-10", + "IRO-11" ], - "CIP-008-6 R1": [ + "Article 17.1": [ + "IRO-01", "IRO-04" ], - "CIP-008-6 R2": [ + "Article 17.2": [ + "IRO-01", "IRO-04" ], - "CIP-008-6 2.2": [ - "IRO-04" + "Article 17.3": [ + "IRO-01" ], - "CIP-008-6 R3": [ + "Article 17.3(a)": [ + "IRO-01", "IRO-04" ], - "CIP-008-6 3.1.2": [ - "IRO-04.2", - "IRO-13" - ], - "CIP-008-6 3.1.3": [ - "IRO-04.2", - "IRO-05" - ], - "CIP-008-6 3.2.1": [ - "IRO-04.2" + "Article 17.3(b)": [ + "IRO-01", + "IRO-04" ], - "CIP-008-6 3.2.2": [ - "IRO-04.2", - "IRO-05" + "Article 17.3(c)": [ + "IRO-01", + "IRO-04" ], - "CIP-008-6 2.1": [ - "IRO-06" + "Article 17.3(d)": [ + "IRO-01", + "IRO-04" ], - "CIP-008-6 3.1": [ - "IRO-06" + "Article 17.3(e)": [ + "IRO-01", + "IRO-04" ], - "CIP-008-6 2.3": [ - "IRO-08", - "IRO-09" + "Article 17.3(f)": [ + "IRO-01", + "IRO-04" ], - "CIP-009-6 1.5": [ - "IRO-08" + "Article 18.1": [ + "IRO-02" ], - "CIP-008-6 4.2": [ - "IRO-10", - "IRO-10.2", - "IRO-10.5" + "Article 18.1(a)": [ + "IRO-02" ], - "CIP-008-6 4.3": [ - "IRO-10" + "Article 18.1(b)": [ + "IRO-02" ], - "CIP-013-2 1.2.2": [ - "IRO-10.4", - "TPM-11" + "Article 18.1(c)": [ + "IRO-02" ], - "CIP-008-6 R4": [ - "IRO-10.5" + "Article 18.1(d)": [ + "IRO-02" ], - "CIP-008-6 4.1": [ - "IRO-10.5" + "Article 18.1(e)": [ + "IRO-02" ], - "CIP-008-6 4.1.1": [ - "IRO-10.5" + "Article 18.1(f)": [ + "IRO-02" ], - "CIP-008-6 4.1.2": [ - "IRO-10.5" + "Article 18.2": [ + "IRO-02" ], - "CIP-008-6 4.1.3": [ - "IRO-10.5" + "Article 19.1": [ + "IRO-10" ], - "CIP-008-6 3.1.1": [ - "IRO-13" + "Article 19.2": [ + "IRO-10" ], - "CIP-007-6 2.4": [ - "IAO-05", - "VPM-02" + "Article 19.3": [ + "IRO-10" ], - "CIP-005-7 3.1": [ - "MNT-05.5", - "NET-14.6" + "Article 19.4": [ + "IRO-10" ], - "CIP-005-7 1.1": [ - "NET-01" + "Article 19.4(a)": [ + "IRO-10" ], - "CIP-005-7 1.2": [ - "NET-01" + "Article 19.4(b)": [ + "IRO-10" ], - "CIP-005-7 1.5": [ - "NET-03", - "NET-08" + "Article 19.4(c)": [ + "IRO-10" ], - "CIP-005-7 1.3": [ - "NET-04" + "Article 19.5": [ + "IRO-10" ], - "CIP-005-7 2.1": [ - "NET-14" + "Article 45.3": [ + "IRO-10", + "THR-01" ], - "CIP-005-7 2.4": [ - "NET-14", - "NET-14.6" + "Article 10.2": [ + "NET-08" ], - "CIP-005-7 2.2": [ - "NET-14.2" + "Article 6.8": [ + "PRM-01.1", + "RSK-01" ], - "CIP-003-8 1.1.3": [ - "PES-01" + "Article 6.8(a)": [ + "PRM-01.1", + "RSK-01" ], - "CIP-003-8 1.2.2": [ - "PES-01" + "Article 6.8(b)": [ + "PRM-01.1", + "RSK-01" ], - "CIP-006-6 R1": [ - "PES-01.1" + "Article 6.8(c)": [ + "PRM-01.1", + "RSK-01" ], - "CIP-006-6 1.1": [ - "PES-01.1", - "PES-03", - "OPS-01.1" + "Article 6.8(d)": [ + "PRM-01.1", + "RSK-01" ], - "CIP-006-6 1.2": [ - "PES-01.2", - "PES-02.1", - "PES-06", - "PES-06.3" + "Article 6.8(e)": [ + "PRM-01.1", + "RSK-01" ], - "CIP-004-7 4.1.2": [ - "PES-02", - "PES-06.3" + "Article 6.8(f)": [ + "PRM-01.1", + "RSK-01" ], - "CIP-004-7 4.2": [ - "PES-02" + "Article 6.8(g)": [ + "PRM-01.1", + "RSK-01" ], - "CIP-006-6 1.3": [ - "PES-03", - "PES-06", - "PES-06.3" + "Article 6.8(h)": [ + "PRM-01.1", + "RSK-01" ], - "CIP-006-6 1.5": [ - "PES-03", - "PES-03.1", - "PES-05.1" + "Article 8.1": [ + "PRM-06" ], - "CIP-006-6 1.8": [ - "PES-03.3" + "Article 6.1": [ + "RSK-01" ], - "CIP-006-6 1.6": [ - "PES-05" + "Article 6.3": [ + "RSK-01" ], - "CIP-006-6 1.7": [ - "PES-05", - "PES-05.1" + "Article 6.4": [ + "RSK-01" ], - "CIP-006-6 R2": [ - "PES-06" + "Article 6.5": [ + "RSK-01" ], - "CIP-006-6 2.2": [ - "PES-06", - "PES-06.2" + "Article 6.6": [ + "RSK-01" ], - "CIP-006-6 2.1": [ - "PES-06.3" + "Article 6.7": [ + "RSK-01" ], - "CIP-013-2 1.1": [ + "Article 6.9": [ "RSK-01" ], - "CIP-002-5.1a 1.1": [ - "RSK-02.1" + "Article 6.10": [ + "RSK-01" ], - "CIP-002-5.1a 1.2": [ - "RSK-02.1" + "Article 11.6": [ + "RSK-01" ], - "CIP-002-5.1a 1.3": [ - "RSK-02.1" + "Article 8.2": [ + "RSK-01.1", + "RSK-03" ], - "CIP-013-2 R1": [ - "RSK-09" + "Article 8.3": [ + "RSK-04" ], - "CIP-013-2 R2": [ - "RSK-09" + "Article 8.7": [ + "RSK-04", + "SEA-02.3" ], - "CIP-013-2 R3": [ - "RSK-09" + "Article 28.1": [ + "RSK-09", + "TPM-01.1" ], - "CIP-003-8 1.2.1": [ - "SAT-01" + "Article 28.1(a)": [ + "RSK-09", + "TPM-01.1", + "TPM-05" ], - "CIP-004-7 1.1": [ - "SAT-02" + "Article 28.1(b)": [ + "RSK-09", + "TPM-01.1" ], - "CIP-004-7 2.1.1": [ - "SAT-02" + "Article 28.1(b)(i)": [ + "RSK-09", + "TPM-01.1" ], - "CIP-004-7 2.1.2": [ - "SAT-02" + "Article 28.1(b)(ii)": [ + "RSK-09", + "TPM-01.1" ], - "CIP-004-7 2.1.3": [ - "SAT-02" + "Article 28.2": [ + "RSK-09", + "TPM-01.1" ], - "CIP-004-7 2.1.4": [ - "SAT-02" + "Article 28.3": [ + "RSK-09", + "TPM-01.1" ], - "CIP-004-7 2.1.5": [ - "SAT-02" + "Article 28.4": [ + "RSK-09" ], - "CIP-004-7 2.1.6": [ - "SAT-02" + "Article 28.4(a)": [ + "RSK-09", + "RSK-09.1", + "TPM-01.1", + "TPM-04.1" ], - "CIP-004-7 2.1.7": [ - "SAT-02" + "Article 28.4(b)": [ + "RSK-09", + "RSK-09.1", + "TPM-01.1", + "TPM-04.1" ], - "CIP-004-7 2.1.8": [ - "SAT-02" + "Article 28.4(c)": [ + "RSK-09", + "RSK-09.1", + "TPM-01.1", + "TPM-04.1" ], - "CIP-004-7 2.1.9": [ - "SAT-02" + "Article 28.4(d)": [ + "RSK-09", + "RSK-09.1", + "TPM-01.1", + "TPM-04.1" ], - "CIP-004-7 2.3": [ - "SAT-03" + "Article 28.4(e)": [ + "RSK-09", + "RSK-09.1", + "TPM-01.1", + "TPM-04.1" ], - "CIP-013-2 1.2.4": [ - "TDA-02.11" + "Article 28.5": [ + "RSK-09", + "TPM-01.1" ], - "CIP-013-2 1.2.5": [ - "TPM-03" + "Article 28.6": [ + "RSK-09", + "TPM-01.1", + "TPM-08" ], - "CIP-013-2 1.2.6": [ - "TPM-03" + "Article 28.7(a)": [ + "RSK-09", + "TPM-01.1", + "TPM-05.7" ], - "CIP-013-2 1.2.1": [ - "TPM-05.1", - "TPM-11" + "Article 28.7(b)": [ + "RSK-09", + "TPM-01.1", + "TPM-05.7" ], - "CIP-007-6 1.3": [ - "VPM-01", - "VPM-05" + "Article 28.7(c)": [ + "RSK-09", + "TPM-01.1", + "TPM-05.7" ], - "CIP-007-6 2.1": [ - "VPM-01" + "Article 28.7(d)": [ + "RSK-09", + "TPM-01.1", + "TPM-05.7" ], - "CIP-007-6 2.2": [ - "VPM-02" + "Article 28.8": [ + "RSK-09", + "TPM-01.1", + "TPM-05.7" ], - "CIP-007-6 2.3": [ - "VPM-02", - "VPM-05" + "Article 28.8(a)": [ + "RSK-09", + "TPM-01.1", + "TPM-05.7" ], - "CIP-010-4 3.1": [ - "VPM-06" + "Article 28.8(b)": [ + "RSK-09", + "TPM-01.1", + "TPM-05.7" ], - "CIP-010-4 3.2.1": [ - "VPM-06" + "Article 28.8(c)": [ + "RSK-09", + "TPM-01.1", + "TPM-05.7" ], - "CIP-010-4 3.2.2": [ - "VPM-06" + "Article 9 (end)": [ + "SEA-01" ], - "CIP-010-4 3.3": [ - "VPM-06" + "Article 9.1": [ + "OPS-01", + "OPS-02", + "OPS-03" ], - "CIP-010-4 3.4": [ - "VPM-06" - ] - }, - "usa-federal-nispom-2020": { - "§117.18(b)": [ - "GOV-01" + "Article 9.2": [ + "OPS-01", + "OPS-01.1", + "OPS-02", + "OPS-03" ], - "§117.18(b)(1)": [ - "GOV-02" + "Article 13.6": [ + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.6" ], - "§117.18(a)(1)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5" + "Article 13.7": [ + "TDA-01", + "TDA-01.1" ], - "§117.18(e)": [ - "GOV-15" + "Article 28.8 (end)": [ + "TDA-17.1" ], - "§117.18(a)(2)": [ - "GOV-15.1" + "Article 30.3 (end)": [ + "TPM-01" ], - "§117.18(e)(1)": [ - "GOV-15.1" + "Article 31.12": [ + "TPM-01" ], - "§117.18(e)(2)": [ - "GOV-15.1" + "Article 30.3(f)": [ + "TPM-03" ], - "§117.18(e)(3)": [ - "GOV-15.1" + "Article 29.1 (end)": [ + "TPM-03.1" ], - "§117.18(e)(4)": [ - "GOV-15.2" + "Article 29.1": [ + "TPM-04" ], - "§117.18(e)(5)": [ - "GOV-15.3" + "Article 29.1(a)": [ + "TPM-04.1" ], - "§117.18(e)(6)": [ - "GOV-15.4" + "Article 29.1(b)": [ + "TPM-04.1" ], - "§117.18(e)(7)": [ - "GOV-15.5" + "Article 29.2": [ + "TPM-05", + "TPM-05.2" ], - "§117.18(e)(7)(i)": [ - "GOV-15.5" + "Article 30.1": [ + "TPM-05" ], - "§117.18(e)(7)(ii)": [ - "GOV-15.5" + "Article 30.2": [ + "TPM-05" ], - "§117.18(e)(7)(iii)": [ - "GOV-15.5" + "Article 30.2(a)": [ + "TPM-05" ], - "§117.18(e)(7)(iv)": [ - "GOV-15.5" + "Article 30.2(b)": [ + "TPM-05" ], - "§117.18(b)(6)": [ - "CHG-01" + "Article 30.2(c)": [ + "TPM-05" ], - "§117.18(f)": [ - "CPL-01" + "Article 30.2(d)": [ + "TPM-05" ], - "§117.18(c)(1)(i)": [ - "CPL-01.5" + "Article 30.2(e)": [ + "TPM-05" ], - "§117.15(d)(2)": [ - "MON-01.1" + "Article 30.2(f)": [ + "TPM-05" ], - "§117.15(d)(2)(i)": [ - "MON-01.1" + "Article 30.2(g)": [ + "TPM-05" ], - "§117.15(d)(2)(i)(A)": [ - "MON-01.1" + "Article 30.2(h)": [ + "TPM-05" ], - "§117.15(d)(2)(i)(B)": [ - "MON-01.1" + "Article 30.2(i)": [ + "TPM-05" ], - "§117.15(d)(2)(i)(C)": [ - "MON-01.1" + "Article 30.3": [ + "TPM-05" ], - "§117.15(d)(2)(i)(D)": [ - "MON-01.1" + "Article 30.3(a)": [ + "TPM-05" ], - "§117.15(d)(2)(i)(E)": [ - "MON-01.1" + "Article 30.3(b)": [ + "TPM-05" ], - "§117.15(d)(2)(ii)": [ - "MON-01.1" + "Article 30.3(c)": [ + "TPM-05" ], - "§117.15(d)(2)(iii)": [ - "MON-01.1" + "Article 30.3(d)": [ + "TPM-05" ], - "§117.15(d)(2)(iv)": [ - "MON-01.1" + "Article 30.3(e)(i)": [ + "TPM-05" ], - "§117.15(d)(2)(v)": [ - "MON-01.1" + "Article 30.3(e)(ii)": [ + "TPM-05" ], - "§117.15(d)(3)": [ - "MON-01.8" + "Article 30.3(e)(iii)": [ + "TPM-05" ], - "§117.15(d)(3)(i)": [ - "MON-01.8" + "Article 30.3(e)(iv)": [ + "TPM-05" ], - "§117.15(d)(3)(i)(A)": [ - "MON-01.8" + "Article 30.3(f)(i)": [ + "TPM-05" ], - "§117.15(d)(3)(i)(B)": [ - "MON-01.8" + "Article 30.4": [ + "TPM-05" ], - "§117.15(d)(3)(ii)": [ - "MON-01.8" + "Article 28.7": [ + "TPM-05.7" ], - "§117.15(d)(3)(ii)(A)": [ - "MON-01.8" + "Article 30.3(e)": [ + "TPM-08" ], - "§117.15(d)(3)(ii)(B)": [ - "MON-01.8" + "Article 13.1": [ + "THR-01", + "THR-03" ], - "§117.15(d)(3)(ii)(C)": [ - "MON-01.8" + "Article 25.1": [ + "VPM-01", + "VPM-06" ], - "§117.15(d)(3)(ii)(D)": [ - "MON-01.8" + "Article 25.2": [ + "VPM-01", + "VPM-06" ], - "§117.15(d)(3)(iii)": [ - "MON-01.8" + "Article 25.3": [ + "VPM-01", + "VPM-06" ], - "§117.15(a)": [ - "DCH-01.2" + "Article 26.1": [ + "VPM-07" ], - "§117.15(a)(1)": [ - "DCH-01.2" + "Article 26.2": [ + "VPM-07" ], - "§117.15(a)(2)": [ - "DCH-01.2" + "Article 26.3": [ + "VPM-07" ], - "§117.15(a)(2)(i)": [ - "DCH-01.2" + "Article 26.4": [ + "VPM-07" ], - "§117.15(a)(2)(ii)": [ - "DCH-01.2" + "Article 26.5": [ + "VPM-07" ], - "§117.15(a)(3)": [ - "DCH-01.2" + "Article 26.6": [ + "VPM-07" ], - "§117.15(a)(3)(i)": [ - "DCH-01.2" + "Article 26.7": [ + "VPM-07" ], - "§117.15(a)(3)(ii)": [ - "DCH-01.2" + "Article 26.8": [ + "VPM-07" ], - "§117.15(a)(3)(iii)": [ - "DCH-01.2" + "Article 26.8(a)": [ + "VPM-07" ], - "§117.15(a)(3)(iii)(A)": [ - "DCH-01.2" + "Article 26.8(b)": [ + "VPM-07" ], - "§117.15(a)(3)(iii)(B)": [ - "DCH-01.2" + "Article 26.8(c)": [ + "VPM-07" ], - "§117.15(a)(3)(iii)(C)": [ - "DCH-01.2" + "Article 27.1": [ + "VPM-07.1" ], - "§117.15(a)(3)(iii)(D)": [ - "DCH-01.2" + "Article 27.1(a)": [ + "VPM-07.1" ], - "§117.15(a)(3)(iii)(E)": [ - "DCH-01.2" + "Article 27.1(b)": [ + "VPM-07.1" ], - "§117.15(a)(3)(iii)(F)": [ - "DCH-01.2" + "Article 27.1(c)": [ + "VPM-07.1" ], - "§117.15(a)(3)(iv)": [ - "DCH-01.2" + "Article 27.1(d)": [ + "VPM-07.1" ], - "§117.15(a)(3)(iv)(A)": [ - "DCH-01.2" + "Article 27.1(e)": [ + "VPM-07.1" ], - "§117.15(a)(3)(iv)(B)": [ - "DCH-01.2" + "Article 27.2": [ + "VPM-07.1" ], - "§117.15(b)": [ - "DCH-01.2" + "Article 27.2(a)": [ + "VPM-07.1" ], - "§117.15(c)": [ - "DCH-01.2" + "Article 27.2(b)": [ + "VPM-07.1" ], - "§117.15(c)(1)": [ - "DCH-01.2" + "Article 27.2(c)": [ + "VPM-07.1" ], - "§117.15(c)(2)": [ - "DCH-01.2" + "Article 27.3": [ + "VPM-07.1" + ] + }, + "emea-eu-gdpr-2016": { + "Article 24.2": [ + "GOV-02" ], - "§117.15(c)(3)": [ - "DCH-01.2" + "Article 32.1(c)": [ + "BCD-01" ], - "§117.15(e)(2)": [ - "DCH-01.2" + "Article 3.1": [ + "CPL-01.2" ], - "§117.15(e)(3)": [ - "DCH-01.2" + "Article 3.2": [ + "CPL-01.2" ], - "§117.15(e)(3)(i)": [ - "DCH-01.2" + "Article 3.2(a)": [ + "CPL-01.2" ], - "§117.15(e)(3)(ii)": [ - "DCH-01.2" + "Article 3.2(b)": [ + "CPL-01.2" ], - "§117.15(e)(3)(iii)": [ - "DCH-01.2" + "Article 3.3": [ + "CPL-01.2" ], - "§117.15(e)(3)(iv)": [ - "DCH-01.2" + "Article 5.2": [ + "CPL-01.3" ], - "§117.15(e)(6)": [ - "DCH-01.2" + "Article 12.1": [ + "CPL-01.3" ], - "§117.15(f)": [ - "DCH-01.2" + "Article 30.4": [ + "CPL-01.3" ], - "§117.15(f)(1)": [ - "DCH-01.2" + "Article 31": [ + "CPL-01.3" ], - "§117.15(f)(2)": [ - "DCH-01.2" + "Article 32.1(d)": [ + "CPL-02", + "CPL-02.2" ], - "§117.15(f)(3)": [ - "DCH-01.2" + "Article 32.1(a)": [ + "CRY-01", + "PRI-01.6" ], - "§117.15(h)": [ - "DCH-03.1" + "Article 44": [ + "DCH-25" ], - "§117.15(h)(1)": [ - "DCH-03.1" + "Article 45.1": [ + "DCH-25", + "PRI-01.5" ], - "§117.15(h)(2)": [ - "DCH-03.1" + "Article 46.1": [ + "DCH-25", + "PRI-01.5" ], - "§117.15(h)(2)(i)": [ - "DCH-03.1" + "Article 46.2": [ + "DCH-25" ], - "§117.15(h)(2)(i)(A)": [ - "DCH-03.1" + "Article 46.2(a)": [ + "DCH-25" ], - "§117.15(h)(2)(i)(B)": [ - "DCH-03.1" + "Article 49.1": [ + "DCH-25" ], - "§117.19(b)(3)(i)": [ - "DCH-03.1" + "Article 49.1(a)": [ + "DCH-25" ], - "§117.19(b)(4)(i)": [ - "DCH-03.1" + "Article 49.1(b)": [ + "DCH-25" ], - "§117.19(b)(5)(i)": [ - "DCH-03.1" + "Article 49.1(c)": [ + "DCH-25" ], - "§117.14(a)(1)": [ - "DCH-04" + "Article 49.1(d)": [ + "DCH-25" ], - "§117.14(a)(2)": [ - "DCH-04" + "Article 49.1(e)": [ + "DCH-25" ], - "§117.14(b)": [ - "DCH-04" + "Article 49.1(f)": [ + "DCH-25" ], - "§117.14(c)": [ - "DCH-04" + "Article 49.1(g)": [ + "DCH-25" ], - "§117.14(d)": [ - "DCH-04" + "Article 49.2": [ + "DCH-25" ], - "§117.14(e)": [ - "DCH-04" + "Article 49.3": [ + "DCH-25" ], - "§117.14(f)": [ - "DCH-04" + "Article 49.4": [ + "DCH-25" ], - "§117.14(f)(1)": [ - "DCH-04" + "Article 49.6": [ + "DCH-25" ], - "§117.14(f)(2)": [ - "DCH-04" + "Article 32.4": [ + "HRS-02", + "HRS-03", + "IAC-08" ], - "§117.14(g)": [ - "DCH-04" + "Article 33.1": [ + "IRO-04.1", + "IRO-10.2" ], - "§117.14(g)(1)": [ - "DCH-04" + "Article 33.5": [ + "IRO-09" ], - "§117.14(g)(2)": [ - "DCH-04" + "Article 34.1": [ + "IRO-10" ], - "§117.14(h)": [ - "DCH-04" + "Article 34.2": [ + "IRO-10" ], - "§117.14(i)": [ - "DCH-04" + "Article 33.2": [ + "IRO-10.2" ], - "§117.14(i)(1)": [ - "DCH-04" + "Article 33.3(a)": [ + "IRO-10.2" ], - "§117.14(i)(1)(i)": [ - "DCH-04" + "Article 33.3(b)": [ + "IRO-10.2" ], - "§117.14(i)(1)(ii)": [ - "DCH-04" + "Article 33.3(c)": [ + "IRO-10.2" ], - "§117.14(i)(2)": [ - "DCH-04" + "Article 33.3(d)": [ + "IRO-10.2" ], - "§117.14(i)(3)": [ - "DCH-04" + "Article 33.4": [ + "IRO-10.2" ], - "§117.14(i)(4)": [ - "DCH-04" + "Article 5.1(a)": [ + "PRI-01" ], - "§117.14(j)": [ - "DCH-04" + "Article 9.1": [ + "PRI-01" ], - "§117.14(j)(1)": [ - "DCH-04" + "Article 12.2": [ + "PRI-01" ], - "§117.14(j)(1)(i)": [ - "DCH-04" + "Article 27.1": [ + "PRI-01.4" ], - "§117.14(j)(1)(ii)": [ - "DCH-04" + "Article 27.3": [ + "PRI-01.4" ], - "§117.14(j)(1)(iii)": [ - "DCH-04" + "Article 27.4": [ + "PRI-01.4" ], - "§117.14(j)(2)": [ - "DCH-04" + "Article 27.5": [ + "PRI-01.4" ], - "§117.14(j)(3)": [ - "DCH-04" + "Article 35.2": [ + "PRI-01.4" ], - "§117.14(k)": [ - "DCH-04" + "Article 37.1": [ + "PRI-01.4" ], - "§117.14(k)(1)": [ - "DCH-04" + "Article 37.1(a)": [ + "PRI-01.4" ], - "§117.14(k)(2)": [ - "DCH-04" + "Article 37.1(b)": [ + "PRI-01.4" ], - "§117.14(k)(3)": [ - "DCH-04" + "Article 37.1(c)": [ + "PRI-01.4" ], - "§117.14(k)(3)(i)": [ - "DCH-04" + "Article 37.2": [ + "PRI-01.4" ], - "§117.14(k)(3)(ii)": [ - "DCH-04" + "Article 37.3": [ + "PRI-01.4" ], - "§117.14(k)(3)(iii)": [ - "DCH-04" + "Article 37.4": [ + "PRI-01.4" ], - "§117.14(l)": [ - "DCH-04" + "Article 37.5": [ + "PRI-01.4" ], - "§117.14(m)": [ - "DCH-04" + "Article 37.6": [ + "PRI-01.4" ], - "§117.14(m)(1)": [ - "DCH-04" + "Article 37.7": [ + "PRI-01.4" ], - "§117.14(m)(2)": [ - "DCH-04" + "Article 38.1": [ + "PRI-01.4" ], - "§117.14(m)(2)(i)": [ - "DCH-04" + "Article 38.2": [ + "PRI-01.4" ], - "§117.14(m)(2)(ii)": [ - "DCH-04" + "Article 38.3": [ + "PRI-01.4" ], - "§117.14(m)(2)(iii)": [ - "DCH-04" + "Article 38.4": [ + "PRI-01.4" ], - "§117.14(m)(3)": [ - "DCH-04" + "Article 38.5": [ + "PRI-01.4" ], - "§117.14(n)": [ - "DCH-04" + "Article 38.6": [ + "PRI-01.4" ], - "§117.14(n)(1)": [ - "DCH-04" + "Article 39.1": [ + "PRI-01.4" ], - "§117.14(n)(2)": [ - "DCH-04" + "Article 39.1(a)": [ + "PRI-01.4" ], - "§117.14(n)(3)": [ - "DCH-04" + "Article 39.1(b)": [ + "PRI-01.4" ], - "§117.14(o)": [ - "DCH-04" + "Article 39.1(c)": [ + "PRI-01.4" ], - "§117.14(p)": [ - "DCH-04" + "Article 39.1(d)": [ + "PRI-01.4" ], - "§117.14(q)": [ - "DCH-04" + "Article 39.1(e)": [ + "PRI-01.4" ], - "§117.15(f)(4)": [ - "DCH-07.1" + "Article 39.2": [ + "PRI-01.4" ], - "§117.15(f)(4)(i)": [ - "DCH-07.1" + "Article 46.2(b)": [ + "PRI-01.5" ], - "§117.15(f)(4)(ii)": [ - "DCH-07.1" + "Article 5.1(f)": [ + "PRI-01.6" ], - "§117.15(f)(4)(iii)": [ - "DCH-07.1" + "Article 24.1": [ + "PRI-01.6" ], - "§117.15(f)(4)(iv)": [ - "DCH-07.1" + "Article 25.1": [ + "PRI-01.6" ], - "§117.15(h)(8)(iii)": [ - "DCH-08" + "Article 25.2": [ + "PRI-01.6" ], - "§117.15(i)": [ - "DCH-08" + "Article 32.1": [ + "PRI-01.6" ], - "§117.15(i)(1)": [ - "DCH-08" + "Article 32.1(b)": [ + "PRI-01.6" ], - "§117.15(i)(2)": [ - "DCH-08" + "Article 12.7": [ + "PRI-02" ], - "§117.15(g)": [ - "DCH-21" + "Article 13.1(a)": [ + "PRI-02" ], - "§117.15(g)(1)": [ - "DCH-21" + "Article 13.1(b)": [ + "PRI-02" ], - "§117.15(g)(2)": [ - "DCH-21" + "Article 13.1(c)": [ + "PRI-02", + "PRI-02.1" ], - "§117.18(c)(2)": [ - "HRS-03" + "Article 13.1(d)": [ + "PRI-02" ], - "§117.18(c)(2)(i)": [ - "HRS-03" + "Article 13.1(e)": [ + "PRI-02", + "PRI-05.7" ], - "§117.18(c)(2)(ii)": [ - "HRS-03" + "Article 13.2": [ + "PRI-02" ], - "§117.18(c)(2)(iii)": [ - "HRS-03" + "Article 13.2(a)": [ + "PRI-02" ], - "§117.18(c)(2)(iv)": [ - "HRS-03" + "Article 13.2(b)": [ + "PRI-02" ], - "§117.18(c)(2)(v)": [ - "HRS-03" + "Article 13.2(c)": [ + "PRI-02" ], - "§117.18(c)(2)(vi)": [ - "HRS-03" + "Article 13.2(d)": [ + "PRI-02" ], - "§117.18(c)(2)(vii)": [ - "HRS-03" + "Article 13.2(e)": [ + "PRI-02" ], - "§117.18(c)(2)(vii)(A)": [ - "HRS-03" + "Article 13.2(f)": [ + "PRI-02" ], - "§117.18(c)(2)(vii)(B)": [ - "HRS-03" + "Article 13.3": [ + "PRI-02" ], - "§117.18(c)(2)(vii)(C)": [ - "HRS-03" + "Article 14.1(a)": [ + "PRI-02" ], - "§117.18(c)(2)(vii)(D)": [ - "HRS-03" + "Article 14.1(b)": [ + "PRI-02" ], - "§117.18(c)(2)(vii)(E)": [ - "HRS-03" + "Article 14.1(c)": [ + "PRI-02", + "PRI-02.1" ], - "§117.18(c)(2)(vii)(F)": [ - "HRS-03" + "Article 14.1(d)": [ + "PRI-02", + "PRI-05.7" ], - "§117.18(c)(2)(vii)(G)": [ - "HRS-03" + "Article 14.1(e)": [ + "PRI-02" ], - "§117.18(c)(2)(vii)(H)": [ - "HRS-03" + "Article 14.1(f)": [ + "PRI-02" ], - "§117.18(c)(2)(vii)(I)": [ - "HRS-03" + "Article 14.2": [ + "PRI-02" ], - "§117.18(c)(3)": [ - "HRS-03" + "Article 14.2(a)": [ + "PRI-02" ], - "§117.18(c)(3)(i)": [ - "HRS-03" + "Article 14.2(b)": [ + "PRI-02" ], - "§117.18(c)(3)(ii)": [ - "HRS-03" + "Article 14.2(c)": [ + "PRI-02" ], - "§117.18(c)(3)(iii)": [ - "HRS-03" + "Article 14.2(d)": [ + "PRI-02" ], - "§117.18(c)(4)": [ - "HRS-03" + "Article 14.2(e)": [ + "PRI-02" ], - "§117.18(c)(4)(i)": [ - "HRS-03" + "Article 14.2(f)": [ + "PRI-02" ], - "§117.18(c)(4)(ii)": [ - "HRS-03" + "Article 14.2(g)": [ + "PRI-02" ], - "§117.18(c)(4)(iii)": [ - "HRS-03" + "Article 14.3(a)": [ + "PRI-02" ], - "§117.18(c)(4)(iv)": [ - "HRS-03" + "Article 14.3(b)": [ + "PRI-02" ], - "§117.18(c)(4)(v)": [ - "HRS-03" + "Article 14.3(c)": [ + "PRI-02" ], - "§117.18(c)(4)(vi)": [ - "HRS-03" + "Article 14.4": [ + "PRI-02" ], - "§117.15(e)(5)": [ - "IAC-10" + "Article 14.5(a)": [ + "PRI-02" ], - "§117.18(b)(2)": [ - "IRO-01" + "Article 7.1": [ + "PRI-03" ], - "§117.15(e)(4)": [ - "PES-03" + "Article 7.2": [ + "PRI-03" ], - "§117.18(c)(1)(ii)": [ - "PRM-02" + "Article 9.2(a)": [ + "PRI-03" ], - "§117.18(d)": [ - "PRM-07" + "Article 21.1": [ + "PRI-03" ], - "§117.18(d)(1)": [ - "PRM-07" + "Article 21.2": [ + "PRI-03" ], - "§117.18(d)(2)": [ - "PRM-07" + "Article 21.3": [ + "PRI-03" ], - "§117.18(d)(3)": [ - "PRM-07" + "Article 21.4": [ + "PRI-03" ], - "§117.18(b)(7)": [ - "SEA-18" + "Article 21.5": [ + "PRI-03" ], - "§117.18(b)(3)": [ - "SAT-01" + "Article 21.6": [ + "PRI-03" ], - "§117.12(e)": [ - "SAT-02" + "Article 7.3": [ + "PRI-03.4" ], - "§117.12(i)": [ - "SAT-02" + "Article 8.1": [ + "PRI-03.6", + "PRI-04" ], - "§117.12(j)": [ - "SAT-02" + "Article 8.2": [ + "PRI-03.6" ], - "§117.12(k)": [ - "SAT-02" + "Article 18.2": [ + "PRI-03.9" ], - "§117.12(l)": [ - "SAT-02" + "Article 18.3": [ + "PRI-03.11" ], - "§117.12(a)": [ - "SAT-03", - "SAT-03.3" + "Article 19": [ + "PRI-03.11" ], - "§117.12(b)": [ - "SAT-03" + "Article 5.1(b)": [ + "PRI-04" ], - "§117.12(e)(6)": [ - "SAT-03" + "Article 5.1(c)": [ + "PRI-04" ], - "§117.12(d)": [ - "SAT-03.3" + "Article 9.2(b)": [ + "PRI-04.1" ], - "§117.12(e)(3)": [ - "SAT-03.3" + "Article 9.2(c)": [ + "PRI-04.1" ], - "§117.12(e)(4)": [ - "SAT-03.3" + "Article 9.2(d)": [ + "PRI-04.1" ], - "§117.12(e)(5)": [ - "SAT-03.3" + "Article 9.2(e)": [ + "PRI-04.1" ], - "§117.12(f)": [ - "SAT-03.3" + "Article 9.2(f)": [ + "PRI-04.1" ], - "§117.12(h)": [ - "SAT-03.3" + "Article 9.2(g)": [ + "PRI-04.1" ], - "§117.12(h)(1)": [ - "SAT-03.3" + "Article 9.2(h)": [ + "PRI-04.1" ], - "§117.12(h)(2)": [ - "SAT-03.3" + "Article 9.2(i)": [ + "PRI-04.1" ], - "§117.12(h)(2)(i)": [ - "SAT-03.3" + "Article 9.2(j)": [ + "PRI-04.1" ], - "§117.12(h)(2)(ii)": [ - "SAT-03.3" + "Article 9.3": [ + "PRI-04.1" ], - "§117.12(h)(2)(iii)": [ - "SAT-03.3" + "Article 10": [ + "PRI-04.1" ], - "§117.12(h)(2)(iv)": [ - "SAT-03.3" + "Article 5.1(e)": [ + "PRI-05", + "PRI-05.8" ], - "§117.12(h)(2)(v)": [ - "SAT-03.3" + "Article 5.1(d)": [ + "PRI-05.2" ], - "§117.12(h)(2)(vi)": [ - "SAT-03.3" + "Article 12.3": [ + "PRI-06" ], - "§117.12(h)(2)(vii)": [ - "SAT-03.3" + "Article 12.5(b)": [ + "PRI-06" ], - "§117.12(e)(1)": [ - "SAT-03.6" + "Article 12.6": [ + "PRI-06" ], - "§117.12(e)(2)": [ - "SAT-03.6" + "Article 15.1": [ + "PRI-06" ], - "§117.12(g)(3)": [ - "SAT-04" + "Article 15.1(a)": [ + "PRI-06" ], - "§117.12(h)(3)": [ - "SAT-04" + "Article 15.1(b)": [ + "PRI-06" ], - "§117.18(b)(5)": [ - "THR-01" + "Article 15.1(c)": [ + "PRI-06" ], - "§117.18(b)(4)": [ - "THR-04" + "Article 15.1(d)": [ + "PRI-06" ], - "§117.18(b)(4)(i)": [ - "THR-04" + "Article 15.1(e)": [ + "PRI-06" ], - "§117.18(b)(4)(ii)": [ - "THR-04" + "Article 15.1(g)": [ + "PRI-06" ], - "§117.18(b)(4)(iii)": [ - "THR-04" + "Article 15.1(h)": [ + "PRI-06" ], - "§117.18(b)(4)(iv)": [ - "THR-04" + "Article 15.2": [ + "PRI-06" ], - "§117.12(g)": [ - "THR-05" + "Article 15.3": [ + "PRI-06" ], - "§117.12(g)(1)": [ - "THR-05" + "Article 15.4": [ + "PRI-06" ], - "§117.12(g)(1)(i)": [ - "THR-05" + "Article 16": [ + "PRI-06" ], - "§117.12(g)(1)(ii)": [ - "THR-05" + "Article 17.1": [ + "PRI-06" ], - "§117.12(g)(1)(iii)": [ - "THR-05" + "Article 18.1": [ + "PRI-06" ], - "§117.12(g)(1)(iv)": [ - "THR-05" + "Article 18.1(a)": [ + "PRI-06" ], - "§117.12(g)(2)": [ - "THR-05" + "Article 18.1(b)": [ + "PRI-06" ], - "§117.12(g)(2)(i)": [ - "THR-05" + "Article 18.1(c)": [ + "PRI-06" ], - "§117.12(g)(2)(ii)": [ - "THR-05" + "Article 18.1(d)": [ + "PRI-06" ], - "§117.12(g)(2)(iii)": [ - "THR-05" + "Article 12.4": [ + "PRI-06.4" ], - "§117.12(g)(2)(iv)": [ - "THR-05" - ] - }, - "usa-federal-dow-safeguarding-nnpi-2010": { - "13-2.b(2)": [ - "GOV-02" + "Article 17.1(a)": [ + "PRI-06.5" ], - "9-2.b": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5" + "Article 17.1(b)": [ + "PRI-06.5" ], - "9-3.a": [ - "GOV-15.4" + "Article 17.1(c)": [ + "PRI-06.5" ], - "9-3.b": [ - "GOV-15.4" + "Article 17.1(d)": [ + "PRI-06.5" ], - "9-3.d": [ - "GOV-15.4", - "MDM-06" + "Article 17.1(e)": [ + "PRI-06.5" ], - "6-2.a": [ - "AST-09" + "Article 17.1(f)": [ + "PRI-06.5" ], - "6-3": [ - "AST-09" + "Article 17.2": [ + "PRI-06.5" ], - "6-3.a": [ - "AST-09" + "Article 17.3": [ + "PRI-06.5" ], - "11-3.a(4)(d)": [ - "AST-09" + "Article 17.3(a)": [ + "PRI-06.5" ], - "11-3.a(5)(c)": [ - "AST-09" + "Article 17.3(b)": [ + "PRI-06.5" ], - "11-3.c": [ - "AST-09" + "Article 17.3(c)": [ + "PRI-06.5" ], - "11-3.a(5)(a)": [ - "AST-30" + "Article 17.3(d)": [ + "PRI-06.5" ], - "11-3.a(5)(b)": [ - "AST-30" + "Article 17.3(e)": [ + "PRI-06.5" ], - "9-3.c": [ - "CLD-09", - "DCH-07" + "Article 20.1": [ + "PRI-06.6", + "PRI-06.7" ], - "9-2.d": [ - "CPL-01" + "Article 20.1(b)": [ + "PRI-06.7" ], - "9-5": [ - "CPL-01" + "Article 28.1": [ + "PRI-07.1" ], - "11-2": [ - "CPL-01" + "Article 28.2": [ + "PRI-07.1" ], - "11-3.b(2)": [ - "CPL-01" + "Article 28.3": [ + "PRI-07.1" ], - "11-6": [ - "CPL-01" + "Article 28.3(a)": [ + "PRI-07.1" ], - "13-3": [ - "CPL-01" + "Article 28.3(b)": [ + "PRI-07.1" ], - "13-3.a": [ - "CPL-01" + "Article 28.3(c)": [ + "PRI-07.1" ], - "13-4": [ - "CPL-01" + "Article 28.3(d)": [ + "PRI-07.1" ], - "12-2.d": [ - "CRY-01" + "Article 28.3(e)": [ + "PRI-07.1" ], - "12-2.e(1)": [ - "CRY-01" + "Article 28.3(f)": [ + "PRI-07.1" ], - "9-2": [ - "DCH-01", - "DCH-01.2" + "Article 28.3(g)": [ + "PRI-07.1" ], - "9-2.a": [ - "DCH-01.2", - "DCH-01.4" + "Article 28.3(h)": [ + "PRI-07.1" ], - "8-3.a(2)": [ - "DCH-03.1", - "PES-04.1" + "Article 28.4": [ + "PRI-07.1" ], - "2-6": [ - "DCH-04" + "Article 28.5": [ + "PRI-07.1" ], - "2-7": [ - "DCH-04" + "Article 28.6": [ + "PRI-07.1" ], - "2-7.a(1)": [ - "DCH-04" + "Article 28.7": [ + "PRI-07.1" ], - "2-7.a(2)": [ - "DCH-04" + "Article 28.8": [ + "PRI-07.1" ], - "2-7.a(3)": [ - "DCH-04" + "Article 28.9": [ + "PRI-07.1" ], - "2-7.b": [ - "DCH-04" + "Article 28.10": [ + "PRI-07.1" ], - "2-7.b(1)(a)": [ - "DCH-04" + "Article 29": [ + "PRI-07.1" ], - "2-7.b(1)(b)": [ - "DCH-04" + "Article 46.3(a)": [ + "PRI-07.1" ], - "2-7.b(2)(a)": [ - "DCH-04" + "Article 30.1": [ + "PRI-14" ], - "2-7.b(2)(b)": [ - "DCH-04" + "Article 30.1(a)": [ + "PRI-14" ], - "2-7.c(1)": [ - "DCH-04" + "Article 30.1(b)": [ + "PRI-14" ], - "2-7.c(2)": [ - "DCH-04" + "Article 30.1(c)": [ + "PRI-14" ], - "2-7.c(2)(a)": [ - "DCH-04" + "Article 30.1(d)": [ + "PRI-14" ], - "2-7.c(2)(b)": [ - "DCH-04" + "Article 30.1(e)": [ + "PRI-14" ], - "2-7.c(2)(c)": [ - "DCH-04" + "Article 30.1(f)": [ + "PRI-14" ], - "9-2.c": [ - "DCH-04" + "Article 30.1(g)": [ + "PRI-14" ], - "11-5": [ - "DCH-07" + "Article 30.2": [ + "PRI-14" ], - "11-5.a": [ - "DCH-07" + "Article 30.2(a)": [ + "PRI-14" ], - "11-5.b": [ - "DCH-07" + "Article 30.2(b)": [ + "PRI-14" ], - "6-1.a": [ - "DCH-21" + "Article 30.2(c)": [ + "PRI-14" ], - "6-1.b": [ - "DCH-21" + "Article 30.2(d)": [ + "PRI-14" ], - "6-1.c": [ - "DCH-21" + "Article 30.3": [ + "PRI-14" ], - "6-3.b": [ - "DCH-21" + "Article 32.2": [ + "RSK-01" ], - "9-2.e": [ - "HRS-03" + "Article 35.1": [ + "RSK-10" ], - "9-3.e": [ - "IRO-12" + "Article 35.3(a)": [ + "RSK-10" ], - "9-4": [ - "IRO-12" + "Article 35.3(b)": [ + "RSK-10" ], - "11-3.a(4)(a)": [ - "IAO-01" + "Article 35.3(c)": [ + "RSK-10" ], - "11-3.a(4)(b)": [ - "IAO-02" + "Article 35.7(a)": [ + "RSK-10" ], - "11-3.a(4)(c)": [ - "IAO-02" + "Article 35.7(b)": [ + "RSK-10" ], - "11-3.a(2)(b)3": [ - "IAO-03" + "Article 35.7(c)": [ + "RSK-10" ], - "11-3.b(3)": [ - "IAO-03" + "Article 35.7(d)": [ + "RSK-10" ], - "11-3.a(3)(c)": [ - "IAO-07" + "Article 35.8": [ + "RSK-10" ], - "12-2.a": [ - "NET-03.2" + "Article 35.9": [ + "RSK-10" ], - "8-3.a": [ - "PES-06" + "Article 35.11": [ + "RSK-10" ], - "8-3.a(1)": [ - "PES-06" + "Article 36.1": [ + "RSK-10" ], - "8-3.a(3)": [ - "PES-06" + "Article 4": [ + "SEA-02.1" + ] + }, + "emea-eu-nis2-2022": { + "Article 21.1": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "CPL-01", + "CPL-03", + "CPL-03.2", + "RSK-01", + "RSK-04", + "SEA-01" ], - "12-2.b": [ - "SAT-03.3" + "Article 21.2": [ + "GOV-01" ], - "7-2": [ - "TPM-05", - "TPM-05.2" + "Article 21.2(a)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "RSK-01" ], - "7-3": [ - "TPM-05" + "Article 21.2(b)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "IRO-01", + "IRO-02" ], - "7-4": [ - "TPM-05", - "TPM-05.2" + "Article 21.2(c)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "BCD-01", + "BCD-11", + "BCD-12" ], - "7-5": [ - "TPM-05", - "TPM-05.2" - ] - }, - "usa-federal-sec-cybersecurity-rule-2023": { - "17 CFR 229.106(b)(1)(iii)": [ - "GOV-01.1", - "GOV-01.2", + "Article 21.2(d)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "RSK-01", "RSK-09", - "RSK-09.1", "TPM-01", - "TPM-02", - "TPM-03", - "TPM-05" + "TPM-03" ], - "17 CFR 229.106(c)(1)": [ - "GOV-01.1", - "GOV-01.2", - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "Article 21.2(e)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "MNT-01", + "NET-01", + "TDA-01", + "TPM-01", + "VPM-01" ], - "17 CFR 229.106(c)(2)": [ + "Article 21.2(f)": [ + "GOV-01", "GOV-01.1", - "GOV-16" + "GOV-02", + "GOV-05", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "RSK-01" ], - "17 CFR 229.106(c)(2)(i)": [ - "GOV-01.1", - "GOV-04" + "Article 21.2(g)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "SAT-01" ], - "17 CFR 229.106(c)(2)(iii)": [ - "GOV-01.1", - "GOV-01.2" + "Article 21.2(h)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "CRY-01" ], - "Form 8-K Item 1.05(a)": [ - "GOV-01.1", - "GOV-04", - "GOV-06", - "GOV-16", + "Article 21.2(i)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "AST-01", + "AST-02", + "HRS-01", + "IAC-01" + ], + "Article 21.2(j)": [ + "GOV-01", + "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "IAC-01", + "IAC-06" + ], + "Article 21.4": [ + "CPL-01.1", + "IAO-04", + "IAO-05", + "RSK-06", + "TDA-15", + "TPM-09", + "VPM-02", + "VPM-04", + "VPM-05.1" + ], + "Article 21.5": [ + "CFG-02", + "NET-01", + "SEA-01" + ], + "Article 23.1": [ "IRO-01", "IRO-02", - "IRO-02.4", - "IRO-04", - "IRO-07", "IRO-10" ], - "17 CFR 229.106(c)(2)(ii)": [ - "GOV-01.2" + "Article 23.3": [ + "IRO-02.4" ], - "17 CFR 229.106(b)(1)(ii)": [ - "GOV-04", - "HRS-03.2", - "TPM-05.4" + "Article 23.3(a)": [ + "IRO-02.4" ], - "17 CFR 229.106(b)(1)(i)": [ - "GOV-15", - "RSK-01", - "RSK-01.1", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-04" + "Article 23.3(b)": [ + "IRO-02.4" ], - "17 CFR 229.105(a)": [ - "GOV-16", - "GOV-16.1", - "GOV-16.2", - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-03.1", - "RSK-04.1" + "Article 23.2": [ + "IRO-10", + "IRO-10.4", + "IRO-16" ], - "17 CFR 229.105(b)": [ - "GOV-16", - "GOV-16.1", - "GOV-16.2", - "GOV-17", - "RSK-02", - "RSK-03.1", - "RSK-04.1" + "Article 23.4": [ + "IRO-10" ], - "17 CFR 229.106(a)": [ - "GOV-16", - "GOV-16.2", - "RSK-04", - "THR-10" + "Article 23.4(a)": [ + "IRO-10" ], - "17 CFR 229.106(b)(2)": [ - "GOV-16", - "GOV-16.1", - "GOV-16.2" + "Article 23.4(b)": [ + "IRO-10" ], - "17 CFR 229.106(d)": [ - "GOV-17" + "Article 23.4(c)": [ + "IRO-10" ], - "17 CFR 229.106(b)(1)": [ - "RSK-01", - "RSK-01.1", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-02.1", - "RSK-03", - "RSK-04", - "RSK-05", - "RSK-06", - "RSK-06.1" - ] - }, - "usa-federal-law-sox-2002": { - "404(a)(1)": [ - "GOV-01" + "Article 23.4(d)": [ + "IRO-10" ], - "404(a)": [ - "CPL-01.4" + "Article 23.4(d)(i)": [ + "IRO-10" ], - "404(a)(2)": [ - "CPL-01.4" + "Article 23.4(d)(ii)": [ + "IRO-10", + "IRO-13" ], - "404(b)": [ - "CPL-01.4" + "Article 23.4(d)(iii)": [ + "IRO-10" ], - "302(a)": [ - "CPL-01.7" + "Article 23.4(d)(iv)": [ + "IRO-10" ], - "302(a)(4)": [ - "CPL-01.7" + "Article 23.4(e)": [ + "IRO-10" ], - "302(a)(4)(A)": [ - "CPL-01.7" + "Article 21.3": [ + "PRM-04", + "PRM-05", + "PRM-07", + "RSK-09", + "TDA-01", + "TDA-06", + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-04.4", + "TPM-05", + "TPM-05.2", + "TPM-05.4", + "TPM-05.5", + "TPM-05.6", + "TPM-05.7", + "TPM-06", + "TPM-08", + "TPM-09", + "TPM-10" + ] + }, + "emea-eu-nis2-annex-2024": { + "1.1.1(a)": [ + "GOV-01", + "NET-01" ], - "302(a)(4)(B)": [ - "CPL-01.7" + "1.1.1(b)": [ + "GOV-01", + "GOV-08" ], - "302(a)(4)(C)": [ - "CPL-01.7" + "6.7.1": [ + "GOV-01", + "GOV-15" ], - "302(a)(4)(D)": [ - "CPL-01.7" + "1.1.1(k)": [ + "GOV-01.1", + "GOV-02" ], - "302(a)(1)": [ - "CPL-01.8" + "1.2.3": [ + "GOV-01.2", + "GOV-17" ], - "302(a)(2)": [ - "CPL-01.8" + "2.1.1": [ + "GOV-01.2", + "RSK-01", + "RSK-04", + "RSK-06" ], - "302(a)(3)": [ - "CPL-01.8" + "2.2.1": [ + "GOV-01.2", + "CPL-01.4" ], - "302(a)(5)": [ - "CPL-01.8" + "2.2.2": [ + "GOV-01.2" ], - "302(a)(5)(A)": [ - "CPL-01.8" + "2.3.3": [ + "GOV-01.2" ], - "302(a)(5)(B)": [ - "CPL-01.8" + "13.2.2(c)": [ + "GOV-01.2", + "IRO-10" ], - "302(a)(6)": [ - "CPL-01.8" - ] - }, - "usa-federal-tsa-security-directive-1580-82-2022-01": { - "III.B": [ - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "1.1.1(d)": [ + "GOV-01.3" ], - "III.B.1.d": [ - "GOV-02", - "NET-04" + "1.1.1(e)": [ + "GOV-01.3" ], - "III.C.1": [ + "1.1.1(f)": [ "GOV-02", - "GOV-02.1", - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "HRS-05.7" ], - "III.C.1.a": [ + "1.1.1(i)": [ "GOV-02" ], - "III.C.1.b": [ + "5.1.6": [ "GOV-02", - "GOV-02.1", - "RSK-06.2" + "GOV-03", + "RSK-09", + "TPM-03" ], - "III.C.3": [ + "7.1": [ "GOV-02", - "GOV-02.1", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "RSK-06.2" + "RSK-01", + "OPS-01.1" ], - "III.D": [ + "9.1": [ "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "RSK-06.2" + "CRY-01", + "OPS-01.1" ], - "III.D.1": [ - "GOV-15" + "11.1.1": [ + "GOV-02", + "IAC-01" ], - "II.B.1": [ - "GOV-17" + "1.1.2": [ + "GOV-03" ], - "III.F.3": [ - "GOV-17" + "2.3.1": [ + "GOV-03", + "CPL-03.1" ], - "V.A.1": [ - "GOV-17" + "6.7.3": [ + "GOV-03", + "SEA-07.1" ], - "VI.A": [ - "GOV-17" + "1.1.1(g)": [ + "GOV-04", + "HRS-03" ], - "VI.B": [ - "GOV-17" + "1.2.1": [ + "GOV-04", + "HRS-03" ], - "VI.B.1": [ - "GOV-17" + "1.2.4": [ + "GOV-04", + "HRS-03" ], - "VI.B.2": [ - "GOV-17" + "1.1.1(j)": [ + "GOV-05" ], - "VI.C": [ - "GOV-17" + "1.1.1(c)": [ + "GOV-09" ], - "VI.D": [ - "GOV-17" + "6.2.1": [ + "GOV-15", + "SEA-01", + "TDA-01" ], - "III.B.1.a": [ - "AST-01.1", - "AST-04" + "12.1.1": [ + "AST-01", + "AST-04.1", + "DCH-02" ], - "III.A": [ - "AST-01.2", - "AST-03" + "12.1.3": [ + "AST-01", + "AST-04.1" ], - "III.B.1.b": [ - "AST-04", - "NET-05" + "12.2.1": [ + "AST-01" ], - "III.B.1.c": [ - "AST-04", - "AST-04.1", - "AST-04.2", - "NET-03", - "NET-06.3" + "12.2.2(a)": [ + "AST-01" ], - "II.B.2": [ - "CPL-01" + "12.2.3": [ + "AST-01" ], - "II.B.3": [ - "CPL-01" + "12.3.3": [ + "AST-01" ], - "IV.C.1": [ - "CPL-01.3" + "5.2(b)": [ + "AST-02" ], - "IV.C.2": [ - "CPL-03.3" + "12.4.1": [ + "AST-02" ], - "IV.C.2.a": [ - "CPL-03.3" + "12.4.2": [ + "AST-02" ], - "IV.C.2.b": [ - "CPL-03.3" + "12.4.2(a)": [ + "AST-02", + "AST-04.3" ], - "IV.C.2.c": [ - "CPL-03.3" + "12.4.2(b)": [ + "AST-02", + "AST-04.3" ], - "IV.C.2.d": [ - "CPL-03.3" + "12.4.3": [ + "AST-02.1" ], - "IV.C.2.e": [ - "CPL-03.3" + "6.7.2(a)": [ + "AST-04" ], - "IV.C.2.e.i": [ - "CPL-03.3" + "11.7.2": [ + "AST-04.1", + "IAC-10" ], - "IV.C.2.e.ii": [ - "CPL-03.3" + "12.2.2(c)": [ + "AST-05" ], - "IV.C.2.e.iii": [ - "CPL-03.3" + "3.1.2": [ + "BCD-01" ], - "IV.C.2.e.iv": [ - "CPL-03.3" + "4.1.1": [ + "BCD-01" ], - "IV.C.2.f": [ - "CPL-03.3" + "4.1.2": [ + "BCD-01" ], - "III.C": [ - "CFG-01", - "IAC-01", - "PES-01" + "4.1.2(a)": [ + "BCD-01" ], - "III.D.2.c": [ - "CFG-02.2", - "CFG-05.1" + "4.1.2(b)": [ + "BCD-01" + ], + "4.1.2(c)": [ + "BCD-01", + "BCD-01.6" + ], + "4.1.2(d)": [ + "BCD-01" + ], + "4.1.2(e)": [ + "BCD-01" + ], + "4.1.2(f)": [ + "BCD-01", + "BCD-01.4" + ], + "4.1.2(g)": [ + "BCD-01", + "BCD-11", + "BCD-11.7" ], - "III.D.3": [ - "MON-01" + "4.1.2(h)": [ + "BCD-01", + "BCD-02.1", + "BCD-02.3" ], - "III.D.3.a": [ - "MON-01", - "MON-01.4", - "MON-01.8", - "MON-01.16", - "MON-03" + "4.2.2": [ + "BCD-01" ], - "III.D.3.b": [ - "MON-01", - "MON-01.16", - "MON-03.2", - "MON-10" + "4.2.5": [ + "BCD-01" ], - "III.D.2.a": [ - "MON-01.3", - "NET-18" + "4.3.1": [ + "BCD-01", + "IRO-01" ], - "III.D.2.b": [ - "MON-01.3", - "MON-16" + "12.1.2(c)": [ + "BCD-01" ], - "III.C.5": [ - "EMB-10", - "NET-01", - "NET-02.3" + "13.2.2(a)": [ + "BCD-01", + "PES-01" ], - "III.D.1.d": [ - "END-03", - "END-10" + "4.3.3": [ + "BCD-01.1", + "IRO-07" ], - "III.D.1.a": [ - "END-08" + "4.2.2(a)": [ + "BCD-01.4" ], - "III.C.2": [ - "IAC-06", - "IAO-05", - "RSK-06.2" + "4.1.4": [ + "BCD-04", + "BCD-05" ], - "III.C.4": [ - "IAC-15.5", - "IAC-19" + "4.2.6": [ + "BCD-04" ], - "III.C.4.a": [ - "IAC-15.5", - "IAC-19" + "4.3.4": [ + "BCD-04" ], - "III.C.4.b": [ - "IAC-15.5", - "IAC-19" + "4.2.2(c)": [ + "BCD-04.2", + "BCD-11" ], - "III.D.2.d": [ - "IRO-01", - "IRO-02", - "OPS-06" + "4.3.2(b)": [ + "BCD-10.4" ], - "III.F": [ - "IAO-01" + "4.2.1": [ + "BCD-11", + "BCD-11.7" ], - "III.F.1": [ - "IAO-01" + "4.2.2(b)": [ + "BCD-11", + "BCD-11.1" ], - "III.F.2.b": [ - "IAO-01", - "IAO-01.1", - "IAO-02" + "4.2.2(f)": [ + "BCD-11", + "DCH-18" ], - "III.F.2.a": [ - "IAO-02" + "4.2.4(a)": [ + "BCD-11.7" ], - "III.F.2.c": [ - "IAO-02" + "4.2.4(b)": [ + "BCD-11.7" ], - "III.B.2": [ - "IAO-03" + "4.2.4(d)": [ + "BCD-11.7" ], - "III.B.2.a": [ - "IAO-03" + "13.1.2(b)": [ + "BCD-11.7" ], - "III.B.2.b": [ - "IAO-03" + "4.2.2(d)": [ + "BCD-11.9" ], - "III.E.3": [ - "IAO-05", - "RSK-06.2" + "4.2.2(e)": [ + "BCD-12", + "BCD-13" ], - "III.D.1.b": [ - "NET-18", - "NET-18.1" + "4.2.3": [ + "BCD-13", + "BCD-13.1" ], - "III.D.1.c": [ - "NET-18" + "5.1.7(d)": [ + "CHG-01", + "TPM-10" ], - "III.D.1.e": [ - "NET-18" + "6.4.1": [ + "CHG-01", + "CHG-02" ], - "III.D.4": [ - "RSK-06", - "RSK-06.2" + "6.4.4": [ + "CHG-01" ], - "III.D.2": [ - "OPS-01.1" + "6.6.1": [ + "CHG-01", + "VPM-01" ], - "III.E": [ + "6.10.2(d)": [ + "CHG-01", + "IRO-04", + "RSK-01", "VPM-01" ], - "III.E.1": [ - "VPM-01", - "VPM-05" + "6.4.2": [ + "CHG-02" ], - "III.E.2.a": [ - "VPM-01", - "VPM-02", - "VPM-05.3" + "6.4.3": [ + "CHG-07", + "CHG-07.1" ], - "III.E.2.b": [ - "VPM-01", - "VPM-02", - "VPM-03" - ] - }, - "usa-state-ak-pipa-2009": { - "45.48.500 - .590": [ - "AST-09", - "DCH-09.3" + "2.2.3": [ + "CPL-01.4", + "MON-01" ], - "45.48.400": [ - "DCH-03.1" + "2.3.2": [ + "CPL-02.1", + "CPL-02.2" ], - "45.48.430": [ - "DCH-03.1" + "2.3.4": [ + "CPL-02.2" ], - "45.48.430.1": [ - "DCH-03.1" + "6.3.1": [ + "CFG-01" ], - "45.48.430.2": [ - "DCH-03.1" + "6.3.2": [ + "CFG-01" ], - "45.48.430.3": [ - "DCH-03.1" + "6.3.2(a)": [ + "CFG-02" ], - "45.48.430.4": [ - "DCH-03.1" + "6.3.2(b)": [ + "CFG-02" ], - "45.48.430.5": [ - "DCH-03.1" + "6.3.3": [ + "CFG-02", + "CFG-02.1" ], - "45.48.430.6": [ - "DCH-03.1" + "12.3.2(b)": [ + "CFG-02" ], - "45.48.750": [ - "DCH-03.2" + "6.7.2(f)": [ + "CFG-03", + "NET-04" ], - "45.48.400 - .480": [ - "PRI-04.1" + "3.2.1": [ + "MON-01", + "IRO-01" ], - "45.48.410": [ - "PRI-04.1" + "3.2.2": [ + "MON-01", + "MON-01.2" ], - "45.48.410.1": [ - "PRI-04.1" + "3.2.6": [ + "MON-01", + "MON-02", + "MON-02.9", + "MON-07.1" ], - "45.48.410.2": [ - "PRI-04.1" + "13.1.2(f)": [ + "MON-01", + "PES-05", + "PES-09" ], - "45.48.410.3": [ - "PRI-04.1" + "3.2.3(a)": [ + "MON-01.3" ], - "45.48.410.4": [ - "PRI-04.1" + "3.2.3": [ + "MON-01.8", + "MON-03", + "MON-10" ], - "45.48.410.5": [ - "PRI-04.1" + "3.2.4": [ + "MON-01.8" ], - "45.48.410.6": [ - "PRI-04.1" + "3.2.3(i)": [ + "MON-02.4" ], - "45.48.410.7": [ - "PRI-04.1" + "3.2.7": [ + "MON-02.9" ], - "45.48.410.8": [ - "PRI-04.1" + "3.2.3(c)": [ + "MON-03" ], - "45.48.420": [ - "PRI-04.1" + "3.2.3(d)": [ + "MON-03" ], - "45.48.420.1": [ - "PRI-04.1" + "3.2.3(e)": [ + "MON-03" ], - "45.48.420.2": [ - "PRI-04.1" + "3.2.3(f)": [ + "MON-03" ], - "45.48.420.3": [ - "PRI-04.1" + "3.2.3(g)": [ + "MON-03" ], - "45.48.420.4": [ - "PRI-04.1" - ] - }, - "usa-state-ca-sb327-2018": { - "1798.91.04(b)(2)": [ - "IAC-10.8", - "TDA-01.1" + "3.2.3(h)": [ + "MON-03" ], - "1798.91.04(a)": [ - "TDA-01.1" + "3.2.3(j)": [ + "MON-03" ], - "1798.91.04(a)(1)": [ - "TDA-01.1" + "3.2.3(k)": [ + "MON-03" ], - "1798.91.04(a)(2)": [ - "TDA-01.1" + "3.2.3(l)": [ + "MON-03" ], - "1798.91.04(a)(3)": [ - "TDA-01.1" + "11.5.2(d)": [ + "MON-03", + "MON-03.3" ], - "1798.91.04(b)": [ - "TDA-01.1" + "11.5.2(b)": [ + "MON-03.2", + "IAC-09.1" ], - "1798.91.04(b)(1)": [ - "TDA-01.1", - "TDA-02.4" - ] - }, - "usa-state-ca-ccpa-cpra-2026": { - "7001": [ - "SEA-02.1" + "3.2.5": [ + "MON-10" ], - "7123(b)(1)": [ - "GOV-01", - "GOV-02" + "13.1.2(d)": [ + "MON-16", + "PES-07" ], - "7123(b)(3)": [ - "GOV-04", - "GOV-15", - "CPL-01", - "CPL-01.1", - "CPL-01.2", - "CPL-01.3" + "3.2.3(b)": [ + "MON-16.4" ], - "7124(a)": [ - "GOV-17" + "11.2.2(f)": [ + "MON-16.4" ], - "7124(b)": [ - "GOV-17" + "3.4.2(c)": [ + "MON-17" ], - "7124(c)": [ - "GOV-17" + "3.4.2(d)": [ + "MON-17" ], - "7124(c)(1)": [ - "GOV-17" + "9.2(a)": [ + "CRY-01" ], - "7124(c)(2)": [ - "GOV-17" + "9.2(b)": [ + "CRY-01" ], - "7124(c)(3)": [ - "GOV-17" + "9.2(c)(vi)": [ + "CRY-09" ], - "7124(d)": [ - "GOV-17" + "9.2(c)(vii)": [ + "CRY-09" ], - "7124(d)(1)": [ - "GOV-17" + "9.2(c)(viii)": [ + "CRY-09" ], - "7124(d)(2)": [ - "GOV-17" + "9.2(c)(ix)": [ + "CRY-09" ], - "7124(d)(3)": [ - "GOV-17" + "9.2(c)(x)": [ + "CRY-09" ], - "7124(d)(4)": [ - "GOV-17" + "9.2(c)(xi)": [ + "CRY-09" ], - "7124(d)(5)": [ - "GOV-17" + "9.2(c)(xii)": [ + "CRY-09" ], - "7157(a)": [ - "GOV-17" + "9.3": [ + "CRY-09" ], - "7157(a)(1)": [ - "GOV-17" + "9.2(c)(v)": [ + "CRY-09.3", + "CRY-09.4" ], - "7157(a)(2)": [ - "GOV-17" + "9.2(c)(i)": [ + "CRY-09.4" ], - "7157(b)": [ - "GOV-17" + "9.2(c)(ii)": [ + "CRY-09.4", + "CRY-11" ], - "7157(b)(1)": [ - "GOV-17" + "9.2(c)(iii)": [ + "CRY-09.4" ], - "7157(b)(2)": [ - "GOV-17" + "9.2(c)(iv)": [ + "CRY-09.4" ], - "7157(b)(3)": [ - "GOV-17" + "2.1.3": [ + "DCH-02", + "RSK-04", + "RSK-04.2", + "RSK-08" ], - "7157(b)(4)": [ - "GOV-17" + "12.1.2(a)": [ + "DCH-02" ], - "7157(b)(5)": [ - "GOV-17" + "12.1.2(b)": [ + "DCH-02.1" ], - "7157(b)(6)": [ - "GOV-17" + "12.3.2(c)": [ + "DCH-07", + "DCH-07.2" ], - "7157(c)": [ - "GOV-17" + "12.3.1": [ + "DCH-12" ], - "7157(c)(1)": [ - "GOV-17" + "12.3.2(a)": [ + "DCH-12" ], - "7157(c)(2)": [ - "GOV-17" + "12.3.2(d)": [ + "DCH-12" ], - "7157(c)(3)": [ - "GOV-17" + "1.1.1(h)": [ + "DCH-18" ], - "7157(d)": [ - "GOV-17" + "6.2.2(f)": [ + "DCH-18.2", + "TDA-10" ], - "7157(e)": [ - "GOV-17" + "6.9.1": [ + "END-01", + "END-04", + "NET-01" ], - "7123(c)(4)": [ - "AST-02" + "6.9.2": [ + "END-04", + "END-04.1" ], - "7123(c)(4)(B)": [ - "AST-02", - "CFG-01", - "CFG-02", - "CFG-03.3" + "10.1.1": [ + "HRS-01", + "HRS-03" ], - "7123(c)(4)(A)": [ - "AST-02.8", - "AST-04", - "AST-04.1", - "DCH-02", - "DCH-04", - "DCH-04.1", - "DCH-06.2", - "DCH-22.2", - "NET-04.5", - "PRI-05.5" + "10.1.3": [ + "HRS-01", + "HRS-02" ], - "7123(c)(18)": [ - "BCD-01" + "10.2.3": [ + "HRS-01" ], - "7123(c)(4)(C)": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "IAO-01", - "IAO-06", - "IAO-07" + "10.1.2(b)": [ + "HRS-01.1", + "HRS-02", + "HRS-02.1" ], - "7123(c)(5)(D)": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "CHG-02.3", - "CHG-03", - "CHG-04", - "CHG-06", - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-03", - "VPM-04", - "VPM-05", - "VPM-05.1", - "VPM-06" + "10.3.1": [ + "HRS-01.1", + "HRS-09", + "IAC-07.2" ], - "7123(c)(5)(E)": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "CHG-02.3", - "CHG-03", - "CHG-06" + "1.2.6": [ + "HRS-03", + "IAC-07.1" ], - "7123(c)(5)(B)": [ - "CLD-01", - "CLD-02", - "CLD-03", - "CFG-02", - "CFG-02.4", - "CFG-02.5", - "CFG-02.9", - "NET-01", - "NET-02", - "NET-03", - "NET-04", - "NET-04.1", - "NET-06", - "NET-06.1", - "SEA-01", - "SEA-01.1", - "SEA-02" + "2.1.2(i)": [ + "HRS-03" ], - "7123(c)(10)": [ - "CLD-02", - "CLD-03", - "NET-02", - "NET-06", - "NET-06.1" + "3.1.2(c)": [ + "HRS-03", + "IRO-07" ], - "7013(h)": [ - "CPL-01" + "3.1.3": [ + "HRS-03", + "IRO-07" ], - "7022(d)": [ - "CPL-01", - "PRI-07.1" + "4.2.4(c)": [ + "HRS-03", + "HRS-13.3", + "PRM-08" ], - "7023(e)": [ - "CPL-01" + "4.3.2(a)": [ + "HRS-03", + "TPM-05", + "TPM-05.4" ], - "7050(b)": [ - "CPL-01", - "PRI-07.1" + "8.1.1": [ + "HRS-03.1", + "SAT-02", + "TPM-05", + "TPM-05.4" ], - "7072(b)": [ - "CPL-01" + "10.1.2(a)": [ + "HRS-03.1", + "TPM-05.4" ], - "7200(a)": [ - "CPL-01" + "10.1.2(c)": [ + "HRS-03.1" ], - "7200(b)": [ - "CPL-01" + "10.1.2(d)": [ + "HRS-04", + "HRS-04.1" ], - "7123(b)(2)": [ - "CPL-01.2", - "CPL-01.4" + "10.2.1": [ + "HRS-04", + "HRS-10", + "TDA-13", + "TPM-06" ], - "7122(c)": [ - "CPL-01.3", - "HRS-05.1" + "10.2.2(a)": [ + "HRS-04" ], - "7122(a)": [ - "CPL-01.4" + "10.2.2(b)": [ + "HRS-04" ], - "7122(b)": [ - "CPL-01.4", - "CPL-03" + "1.2.2": [ + "HRS-05", + "TPM-05" ], - "7122(d)": [ - "CPL-01.4", - "CPL-01.6" + "10.3.2": [ + "HRS-05", + "HRS-06.1" ], - "7122(e)": [ - "CPL-01.4" + "12.2.2(b)": [ + "HRS-05.1" ], - "7122(f)": [ - "CPL-01.4", - "CPL-02" + "10.4.1": [ + "HRS-07", + "HRS-07.1" ], - "7123(a)": [ - "CPL-01.4" + "10.4.2": [ + "HRS-07.2" ], - "7123(b)": [ - "CPL-01.4" + "12.5": [ + "HRS-09", + "HRS-09.1" ], - "7123(c)": [ - "CPL-01.4" + "1.2.5": [ + "HRS-11" ], - "7123(e)": [ - "CPL-01.5" + "11.2.2(a)": [ + "HRS-11", + "IAC-07", + "IAC-08", + "IAC-20.6", + "IAC-21" ], - "7123(e)(1)": [ - "CPL-01.5" + "3.3.1": [ + "HRS-15", + "SAT-03.2" ], - "7123(e)(2)": [ - "CPL-01.5" + "11.1.2(a)": [ + "IAC-01" ], - "7123(e)(3)": [ - "CPL-01.5" + "11.1.2(b)": [ + "IAC-01" ], - "7123(e)(4)": [ - "CPL-01.5" + "11.1.2(c)": [ + "IAC-01" ], - "7123(e)(5)": [ - "CPL-01.5" + "11.1.3": [ + "IAC-01" ], - "7123(e)(6)": [ - "CPL-01.5" + "11.3.1": [ + "IAC-01" ], - "7123(e)(7)": [ - "CPL-01.5" + "11.5.1": [ + "IAC-01" ], - "7123(e)(8)": [ - "CPL-01.5" + "11.5.2(c)": [ + "IAC-01", + "IAC-15" ], - "7123(e)(9)": [ - "CPL-01.5" + "11.6.4": [ + "IAC-01" ], - "7123(e)(10)": [ - "CPL-01.5" + "11.3.2(a)": [ + "IAC-01.2", + "IAC-06" ], - "7123(f)": [ - "CPL-01.5" + "11.4.2(c)": [ + "IAC-01.2", + "NET-15.1" ], - "7122(a)(1)": [ - "CPL-01.6" + "11.6.1": [ + "IAC-01.2" ], - "7122(a)(3)": [ - "CPL-02", - "CPL-02.1" + "11.6.3": [ + "IAC-01.2" ], - "7120(a)": [ - "CPL-03" + "11.2.2(e)": [ + "IAC-01.3" ], - "7122(a)(2)": [ - "CPL-03.1" + "11.5.2(a)": [ + "IAC-02", + "IAC-04" ], - "7123(c)(5)": [ - "CFG-01", - "CFG-02" + "11.7.1": [ + "IAC-06", + "IAC-13.3" ], - "7123(c)(11)": [ - "CFG-01", - "CFG-02", - "CFG-02.9", - "CFG-03" + "11.2.1": [ + "IAC-07" ], - "7123(c)(5)(A)": [ - "CFG-02", - "CFG-02.1", - "VPM-04.1", - "VPM-05" + "11.2.2(b)": [ + "IAC-07", + "IAC-20.6" ], - "7123(c)(7)": [ - "MON-01", - "MON-01.4", - "MON-01.8", - "MON-02", - "MON-02.2", - "MON-02.7", - "MON-03", - "MON-03.2", - "MON-08" + "11.2.2(d)": [ + "IAC-07", + "IAC-08", + "IAC-21" ], - "7123(c)(8)(A)": [ - "MON-01.1", - "MON-01.2", - "MON-01.3", - "MON-11.3", - "NET-01", - "NET-02", - "NET-03", - "NET-08" + "11.4.1": [ + "IAC-08" ], - "7123(c)(2)": [ - "CRY-01", - "CRY-03", - "CRY-05" + "11.6.2(a)": [ + "IAC-10" ], - "7123(c)(5)(C)": [ - "DCH-03.2", - "DCH-23.4", - "PRI-05.3" + "11.6.2(b)": [ + "IAC-10.5" ], - "7123(c)(16)": [ - "DCH-08", - "DCH-09", - "DCH-09.3", - "DCH-18" + "11.6.2(c)": [ + "IAC-10.13" ], - "7153(a)": [ - "DCH-14", - "TPM-05" + "11.2.2(c)": [ + "IAC-15", + "IAC-28.1" ], - "7122(g)": [ - "DCH-18" + "11.5.3": [ + "IAC-15.5" ], - "7155(c)": [ - "DCH-18" + "11.6.2(f)": [ + "IAC-16" ], - "7023(c)": [ - "DCH-22", - "DCH-22.1", - "PRI-06", - "PRI-07.1", - "PRI-07.3", - "PRI-10" + "11.2.3": [ + "IAC-17" ], - "7123(c)(9)": [ - "END-04" + "11.3.3": [ + "IAC-17" ], - "7123(c)(3)(A)(i)": [ - "HRS-01.1", - "IAC-02", - "IAC-08" + "11.5.4": [ + "IAC-17" ], - "7123(c)(3)(A)(ii)": [ - "HRS-01.1", - "IAC-03", - "IAC-08", - "TPM-05", - "TPM-05.4" + "6.7.2(e)": [ + "IAC-20.4" ], - "7123(c)(3)(C)": [ - "HRS-01.1", - "IAC-01", - "IAC-21.3", - "IAC-28.1" + "11.3.2(d)": [ + "IAC-20.4", + "IAC-21" ], - "7123(c)(3)(B)": [ - "HRS-02", - "IAC-08", - "IAC-16", + "11.4.2(a)": [ + "IAC-20.4" + ], + "6.7.2(g)": [ "IAC-21", + "NET-04" + ], + "11.3.2(c)": [ + "IAC-21" + ], + "11.3.2(b)": [ "IAC-21.3" ], - "7123(c)(1)": [ - "IAC-01" + "11.6.2(d)": [ + "IAC-22" ], - "7123(c)(3)": [ - "IAC-01", - "IAC-01.2" + "11.6.2(e)": [ + "IAC-25" ], - "7123(c)(1)(B)": [ - "IAC-01.2", - "IAC-10", - "IAC-10.1", - "IAC-10.14" + "3.1.1": [ + "IRO-01", + "IRO-04" ], - "7123(c)(3)(A)(iii)": [ - "IAC-03", - "IAC-08", - "IAC-21", - "TPM-05" + "3.5.1": [ + "IRO-01", + "IRO-04" ], - "7123(c)(1)(A)": [ - "IAC-06" + "3.1.2(b)": [ + "IRO-02", + "IRO-04", + "IRO-10", + "IRO-10.2" ], - "7123(c)(3)(A)": [ - "IAC-08", - "IAC-21" + "3.4.1": [ + "IRO-02", + "IRO-02.4" ], - "7123(c)(17)": [ - "IRO-01" + "3.4.2(e)": [ + "IRO-02" ], - "7123(c)(17)(B)": [ - "IRO-01" + "3.5.2(a)": [ + "IRO-02" ], - "7027(m)(2)": [ - "IRO-02", - "PRI-01.11" + "3.5.2(b)": [ + "IRO-02" ], - "7123(c)(17)(B)(i)": [ + "3.5.2(c)": [ + "IRO-02" + ], + "3.5.3(b)": [ "IRO-02", - "IRO-04" + "IRO-09" ], - "7123(c)(17)(A)": [ + "3.1.2(a)": [ "IRO-02.4" ], - "7123(c)(17)(B)(ii)": [ - "IRO-06" - ], - "7123(c)(8)": [ - "NET-01" - ], - "7123(c)(8)(B)": [ - "NET-17" + "3.4.2(a)": [ + "IRO-02.4" ], - "7123(c)(3)(D)": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-04", - "PES-04.1", - "PES-05", - "PES-06" + "3.1.2(d)": [ + "IRO-04" ], - "7002(a)": [ - "PRI-01" + "3.5.5": [ + "IRO-06" ], - "7023(d)(4)": [ - "PRI-01.6" + "3.5.3(a)": [ + "IRO-07" ], - "7024(f)": [ - "PRI-01.6" + "3.5.4": [ + "IRO-09" ], - "7027(m)": [ - "PRI-01.7", - "PRI-01.11", - "PRI-02.1" + "6.10.2(a)": [ + "IRO-09", + "THR-03", + "VPM-01" ], - "7016(a)": [ - "PRI-01.10" + "3.4.2(b)": [ + "IRO-09.2" ], - "7016(b)": [ - "PRI-01.10" + "3.6.1": [ + "IRO-13" ], - "7016(c)": [ - "PRI-01.10" + "3.6.2": [ + "IRO-13" ], - "7016(d)": [ - "PRI-01.10" + "3.6.3": [ + "IRO-13" ], - "7016(d)(1)": [ - "PRI-01.10" + "6.5.1": [ + "IAO-01", + "TDA-09" ], - "7016(d)(2)": [ - "PRI-01.10" + "6.5.2(a)": [ + "IAO-01", + "IAO-02" ], - "7016(d)(3)": [ - "PRI-01.10" + "6.5.3": [ + "IAO-01" ], - "7016(d)(4)": [ - "PRI-01.10" + "6.5.2(c)": [ + "IAO-01.1", + "IAO-02.4" ], - "7016(d)(5)": [ - "PRI-01.10" + "6.5.2(b)": [ + "IAO-02" ], - "7016(d)(5)(A)": [ - "PRI-01.10" + "6.5.2(d)": [ + "IAO-05" ], - "7016(d)(5)(B)": [ - "PRI-01.10" + "4.3.2(c)": [ + "MNT-01" ], - "7027(k)": [ - "PRI-01.10", - "PRI-06.4" + "6.7.2(h)": [ + "MNT-05" ], - "7081(a)": [ - "PRI-01.10" + "6.7.2(b)": [ + "NET-01" ], - "7081(a)(1)": [ - "PRI-01.10" + "6.7.2(i)": [ + "NET-01" ], - "7081(a)(2)": [ - "PRI-01.10" + "6.8.3": [ + "NET-01" ], - "7081(a)(3)": [ - "PRI-01.10" + "6.7.2(c)": [ + "NET-04" ], - "7081(a)(4)": [ - "PRI-01.10" + "6.8.1": [ + "NET-06" ], - "7081(a)(5)": [ - "PRI-01.10" + "6.8.2(a)": [ + "NET-06" ], - "7081(a)(6)": [ - "PRI-01.10" + "6.8.2(b)": [ + "NET-06" ], - "7081(a)(7)": [ - "PRI-01.10" + "6.8.2(c)": [ + "NET-06" ], - "7081(a)(8)": [ - "PRI-01.10" + "6.8.2(d)": [ + "NET-06", + "NET-08.1" ], - "7081(b)": [ - "PRI-01.10" + "6.8.2(e)": [ + "NET-06" ], - "7002(b)": [ - "PRI-01.11" + "6.8.2(f)": [ + "NET-06" ], - "7002(b)(1)": [ - "PRI-01.11" + "6.8.2(g)": [ + "NET-06" ], - "7002(b)(2)": [ - "PRI-01.11" + "6.8.2(h)": [ + "NET-06", + "TDA-07" ], - "7002(b)(3)": [ - "PRI-01.11" + "6.7.2(l)": [ + "NET-10", + "NET-18" ], - "7002(d)": [ - "PRI-01.11" + "6.7.2(d)": [ + "NET-14" ], - "7002(d)(1)": [ - "PRI-01.11" + "13.1.1": [ + "PES-01" ], - "7002(d)(2)": [ - "PRI-01.11" + "13.1.3": [ + "PES-01" ], - "7027(m)(1)": [ - "PRI-01.11" + "13.2.1": [ + "PES-01", + "THR-09" ], - "7027(m)(3)": [ - "PRI-01.11" + "13.2.3": [ + "PES-01" ], - "7027(m)(4)": [ - "PRI-01.11" + "13.3.2(a)": [ + "PES-01" ], - "7027(m)(5)": [ - "PRI-01.11" + "13.3.3": [ + "PES-01" ], - "7027(m)(6)": [ - "PRI-01.11" + "13.3.1": [ + "PES-02", + "PES-03" ], - "7027(m)(7)": [ - "PRI-01.11" + "13.1.2(c)": [ + "PES-03" ], - "7027(m)(8)": [ - "PRI-01.11" + "13.3.2(b)": [ + "PES-03", + "PES-03.1" ], - "7002(b)(5)": [ - "PRI-02" + "13.3.2(d)": [ + "PES-03.3", + "PES-05" ], - "7003(a)": [ - "PRI-02", - "PRI-17" + "13.3.2(c)": [ + "PES-04" ], - "7004(a)(1)": [ - "PRI-02" + "13.1.2(a)": [ + "PES-07.3", + "PES-07.4" ], - "7010(a)": [ - "PRI-02" + "6.2.2(a)": [ + "PRM-05", + "PRM-06" ], - "7011(a)": [ - "PRI-02" + "2.1.2": [ + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-06" ], - "7011(b)": [ - "PRI-02" + "2.1.2(a)": [ + "RSK-01" ], - "7011(c)": [ - "PRI-02" + "2.1.2(c)": [ + "RSK-01", + "RSK-01.1" ], - "7011(d)": [ - "PRI-02" + "2.1.2(d)": [ + "RSK-01", + "RSK-03", + "RSK-03.1", + "TPM-04.1" ], - "7011(e)": [ - "PRI-02" + "6.1.1": [ + "RSK-01", + "RSK-04" ], - "7011(e)(1)": [ - "PRI-02" + "6.1.3": [ + "RSK-01", + "RSK-04.2" ], - "7011(e)(1)(A)": [ - "PRI-02" + "7.3": [ + "RSK-01" ], - "7011(e)(1)(B)": [ - "PRI-02" + "2.1.2(e)": [ + "RSK-01.2", + "RSK-04", + "RSK-05" ], - "7011(e)(1)(C)": [ - "PRI-02" + "2.1.2(b)": [ + "RSK-01.3", + "RSK-01.5" ], - "7011(e)(1)(D)": [ - "PRI-02" + "13.2.2(b)": [ + "RSK-01.4" ], - "7011(e)(1)(E)": [ - "PRI-02" + "2.1.2(f)": [ + "RSK-04" ], - "7011(e)(1)(F)": [ - "PRI-02" + "6.1.2": [ + "RSK-04.2" ], - "7011(e)(1)(G)": [ - "PRI-02" + "6.1.2(a)": [ + "RSK-04.2" ], - "7011(e)(1)(H)": [ - "PRI-02" + "6.1.2(b)": [ + "RSK-04.2" ], - "7011(e)(1)(I)": [ - "PRI-02" + "6.1.2(c)": [ + "RSK-04.2" ], - "7011(e)(1)(J)": [ - "PRI-02" + "6.1.2(d)": [ + "RSK-04.2" ], - "7011(e)(2)": [ - "PRI-02" + "6.1.2(e)": [ + "RSK-04.2" ], - "7011(e)(2)(A)": [ - "PRI-02" + "6.1.2(f)": [ + "RSK-04.2" ], - "7011(e)(2)(B)": [ - "PRI-02" + "7.2": [ + "RSK-04.2" ], - "7011(e)(2)(C)": [ - "PRI-02" + "7.2(a)": [ + "RSK-04.2" ], - "7011(e)(2)(D)": [ - "PRI-02" + "7.2(b)": [ + "RSK-04.2" ], - "7011(e)(2)(E)": [ - "PRI-02" + "7.2(c)": [ + "RSK-04.2" ], - "7011(e)(2)(F)": [ - "PRI-02" + "7.2(d)": [ + "RSK-04.2" ], - "7011(e)(2)(G)": [ - "PRI-02" + "7.2(e)": [ + "RSK-04.2" ], - "7011(e)(2)(H)": [ - "PRI-02" + "7.2(f)": [ + "RSK-04.2" ], - "7011(e)(3)": [ - "PRI-02" + "2.1.2(g)": [ + "RSK-06" ], - "7011(e)(3)(A)": [ - "PRI-02" + "2.1.2(j)": [ + "RSK-06" ], - "7011(e)(3)(B)": [ - "PRI-02" + "6.6.1(d)": [ + "RSK-06.2" ], - "7011(e)(3)(C)": [ - "PRI-02" + "2.1.4": [ + "RSK-07" ], - "7011(e)(3)(D)": [ - "PRI-02" + "4.1.3": [ + "RSK-08" ], - "7011(e)(3)(E)": [ - "PRI-02" + "5.1.1": [ + "RSK-09", + "TDA-01" ], - "7011(e)(3)(F)": [ - "PRI-02" + "5.1.5": [ + "RSK-09", + "TPM-05" ], - "7011(e)(3)(G)": [ - "PRI-02" + "5.1.3": [ + "RSK-09.1" ], - "7011(e)(3)(H)": [ - "PRI-02" + "2.1.2(h)": [ + "RSK-11" ], - "7011(e)(3)(I)": [ - "PRI-02" + "6.2.2(b)": [ + "SEA-01" ], - "7011(e)(3)(J)": [ - "PRI-02" + "6.2.2(c)": [ + "SEA-01", + "TDA-01", + "TDA-07" ], - "7011(e)(4)": [ - "PRI-02" + "4.2.4": [ + "SEA-01.2" ], - "7011(e)(5)": [ - "PRI-02" + "11.4.2(b)": [ + "SEA-04" ], - "7012(f)": [ - "PRI-02" + "6.7.2(j)": [ + "SEA-07.1" ], - "7012(g)(1)": [ - "PRI-02" + "6.7.2(k)": [ + "SEA-07.1" ], - "7013(c)": [ - "PRI-02" + "8.1.3": [ + "SAT-01" ], - "7013(e)": [ - "PRI-02" + "8.2.5": [ + "SAT-01" ], - "7013(e)(1)": [ - "PRI-02" + "8.1.2(a)": [ + "SAT-01.1" ], - "7013(e)(2)": [ - "PRI-02" + "8.1.2": [ + "SAT-02" ], - "7013(e)(3)": [ - "PRI-02" + "8.2.1": [ + "SAT-03" ], - "7013(g)(2)": [ - "PRI-02" + "8.2.2": [ + "SAT-03" ], - "7014(b)": [ - "PRI-02" + "8.2.3": [ + "SAT-03" ], - "7014(c)": [ - "PRI-02" + "8.2.3(a)": [ + "SAT-03" ], - "7014(d)": [ - "PRI-02" + "8.2.3(c)": [ + "SAT-03" ], - "7014(e)(1)": [ - "PRI-02" + "8.2.4": [ + "SAT-03" ], - "7014(e)(2)": [ - "PRI-02" + "3.3.2": [ + "SAT-03.2", + "TPM-05" ], - "7014(e)(3)": [ - "PRI-02" + "8.1.2(b)": [ + "SAT-03.6" ], - "7014(g)(1)": [ - "PRI-02" + "8.1.2(c)": [ + "SAT-03.6" ], - "7014(g)(2)": [ - "PRI-02" + "8.2.3(b)": [ + "SAT-03.6" ], - "7014(h)": [ - "PRI-02", - "PRI-21.1" + "6.2.4": [ + "TDA-01" ], - "7025(g)(2)": [ - "PRI-02" + "6.10.2(e)": [ + "TDA-02.11" ], - "7025(g)(2)(A)": [ - "PRI-02" + "6.2.2(d)": [ + "TDA-09" ], - "7025(g)(2)(B)": [ - "PRI-02" + "6.2.2(e)": [ + "TDA-10.1" ], - "7025(g)(2)(C)": [ - "PRI-02" + "6.6.1(c)": [ + "TDA-14.1", + "VPM-05.8" ], - "7025(g)(2)(D)": [ - "PRI-02" + "6.2.3": [ + "TPM-01", + "TPM-05" ], - "7072(a)": [ - "PRI-02" + "5.2": [ + "TPM-01.1" ], - "7002(a)(1)": [ - "PRI-02.1" + "5.2(a)": [ + "TPM-01.1" ], - "7002(a)(2)": [ - "PRI-02.1" + "5.1.2": [ + "TPM-05" ], - "7002(b)(4)": [ - "PRI-02.1" + "5.1.2(a)": [ + "TPM-05" ], - "7002(c)": [ - "PRI-02.8" + "5.1.2(b)": [ + "TPM-05" ], - "7002(c)(1)": [ - "PRI-02.8" + "5.1.2(c)": [ + "TPM-05" ], - "7002(c)(2)": [ - "PRI-02.8" + "5.1.2(d)": [ + "TPM-05" ], - "7002(c)(3)": [ - "PRI-02.8" + "5.1.4": [ + "TPM-05" ], - "7003(b)(1)": [ - "PRI-02.9" + "5.1.4(a)": [ + "TPM-05" ], - "7003(b)(2)": [ - "PRI-02.9" + "5.1.4(b)": [ + "TPM-05" ], - "7003(b)(3)": [ - "PRI-02.9" + "5.1.4(c)": [ + "TPM-05", + "TPM-06" ], - "7004(a)(2)": [ - "PRI-02.10" + "5.1.4(d)": [ + "TPM-05" ], - "7004(a)(4)": [ - "PRI-02.11" + "5.1.4(e)": [ + "TPM-05" ], - "7004(b)": [ - "PRI-02.11" + "5.1.4(f)": [ + "TPM-05" ], - "7004(c)": [ - "PRI-02.11" + "5.1.4(g)": [ + "TPM-05", + "TPM-05.2" ], - "7004(a)(5)": [ - "PRI-02.12" + "5.1.4(h)": [ + "TPM-05" ], - "7014(a)": [ - "PRI-02.13" + "13.1.2(e)": [ + "TPM-05" ], - "7014(e)": [ - "PRI-02.13" + "5.1.7(a)": [ + "TPM-08" ], - "7014(f)": [ - "PRI-02.13" + "5.1.7(b)": [ + "TPM-08" ], - "7014(f)(1)": [ - "PRI-02.13" + "5.1.7(c)": [ + "TPM-08" ], - "7014(f)(2)": [ - "PRI-02.13" + "6.10.1": [ + "VPM-01", + "VPM-02" ], - "7014(e)(3)(A)": [ - "PRI-02.14" + "6.10.2(c)": [ + "VPM-02" ], - "7014(e)(3)(B)": [ - "PRI-02.14" + "6.10.3": [ + "VPM-02" ], - "7014(e)(3)(C)": [ - "PRI-02.14" + "6.6.2": [ + "VPM-04.3" ], - "7014(e)(3)(D)": [ - "PRI-02.14" + "6.6.1(a)": [ + "VPM-05" ], - "7002(e)": [ - "PRI-03" + "6.10.4": [ + "VPM-05.4", + "VPM-06.1" ], - "7010(b)": [ - "PRI-03" + "6.6.1(b)": [ + "VPM-05.6" ], - "7012(a)": [ - "PRI-03" + "6.10.2(b)": [ + "VPM-06" + ] + }, + "emea-eu-psd2-2015": { + "95(1)": [ + "GOV-01", + "IRO-01" ], - "7012(b)": [ - "PRI-03" + "97(3)": [ + "GOV-01", + "CPL-01" ], - "7012(c)": [ - "PRI-03" + "98(1)": [ + "GOV-01.4" ], - "7012(d)": [ - "PRI-03" + "98(1)(a)": [ + "GOV-01.4" ], - "7012(e)": [ - "PRI-03" + "98(1)(b)": [ + "GOV-01.4" ], - "7012(e)(1)": [ - "PRI-03" + "98(1)(c)": [ + "GOV-01.4" ], - "7012(e)(2)": [ - "PRI-03" + "98(1)(d)": [ + "GOV-01.4" ], - "7012(e)(3)": [ - "PRI-03" + "98(2)": [ + "GOV-01.4" ], - "7012(e)(4)": [ - "PRI-03" + "98(3)": [ + "GOV-01.4" ], - "7012(e)(5)": [ - "PRI-03" + "98(4)": [ + "GOV-01.4" ], - "7012(e)(6)": [ - "PRI-03" + "98(5)": [ + "GOV-01.4" ], - "7027(c)": [ - "PRI-03" + "96(6)": [ + "GOV-17" ], - "7027(d)": [ - "PRI-03", - "PRI-06" + "24(1)": [ + "HRS-06.1" ], - "7002(f)": [ - "PRI-03.2", - "PRI-04" + "96(1)": [ + "IRO-10", + "IRO-10.5" ], - "7010(f)": [ - "PRI-03.2", - "PRI-03.7" + "94(1)": [ + "PRI-01.11" ], - "7022(g)": [ - "PRI-03.2" + "94(2)": [ + "PRI-01.11" ], - "7022(h)": [ - "PRI-03.2" + "95(2)": [ + "RSK-04" ], - "7025(c)(5)": [ - "PRI-03.2", - "PRI-03.8" + "97(1)": [ + "WEB-06" ], - "7026(k)": [ - "PRI-03.2" + "97(1)(a)": [ + "WEB-06" ], - "7027(l)": [ - "PRI-03.2" + "97(1)(b)": [ + "WEB-06" ], - "7221(i)": [ - "PRI-03.2" + "97(1)(c)": [ + "WEB-06" ], - "7221(k)": [ - "PRI-03.2" + "97(2)": [ + "WEB-06" + ] + }, + "emea-aut-dpa-2018": { + "§ 37(3)": [ + "CPL-01.3" ], - "7080(a)": [ - "PRI-03.5" + "§ 51": [ + "CPL-05.2" ], - "7080(b)": [ - "PRI-03.5" + "§ 52": [ + "CPL-05.2" ], - "7221(l)": [ - "PRI-03.5" + "§ 53": [ + "CPL-05.2" ], - "7026(j)": [ - "PRI-03.6" + "§ 12(2)": [ + "END-13.2", + "PRI-03" ], - "7027(j)": [ - "PRI-03.6", - "PRI-07.5" + "§ 6(3)": [ + "HRS-05.7", + "SAT-03.3" ], - "7063(a)": [ - "PRI-03.6" + "§ 5(1)": [ + "HRS-06.1", + "PRI-01.4" ], - "7063(a)(1)": [ - "PRI-03.6" + "§ 55(1)": [ + "IRO-10" ], - "7063(a)(2)": [ - "PRI-03.6" + "§ 55(2)": [ + "IRO-10" ], - "7063(b)": [ - "PRI-03.6" + "§ 56(1)": [ + "IRO-10" ], - "7063(c)": [ - "PRI-03.6" + "§ 56(2)": [ + "IRO-10" ], - "7063(d)": [ - "PRI-03.6" + "§ 57(1)": [ + "PRI-01.4" ], - "7221(j)": [ - "PRI-03.6" + "§ 57(2)": [ + "PRI-01.4" ], - "7010(e)": [ - "PRI-03.7" + "§ 57(3)": [ + "PRI-01.4" ], - "7025(c)(4)": [ - "PRI-03.7" + "§ 57(4)": [ + "PRI-01.4" ], - "7027(b)": [ - "PRI-03.7", - "PRI-03.9" + "§ 58(1)": [ + "PRI-01.5" ], - "7027(i)": [ - "PRI-03.7" + "§ 58(2)": [ + "PRI-01.5" ], - "7025(a)": [ - "PRI-03.8" + "§ 58(3)": [ + "PRI-01.5" ], - "7025(b)": [ - "PRI-03.8" + "§ 59(1)": [ + "PRI-01.5" ], - "7025(b)(1)": [ - "PRI-03.8" + "§ 59(2)": [ + "PRI-01.5" ], - "7025(b)(2)": [ - "PRI-03.8" + "§ 59(3)": [ + "PRI-01.5" ], - "7025(c)": [ - "PRI-03.8" + "§ 59(5)": [ + "PRI-01.5" ], - "7025(c)(1)": [ - "PRI-03.8" + "§ 59(6)": [ + "PRI-01.5" ], - "7025(c)(2)": [ - "PRI-03.8" + "§ 59(7)": [ + "PRI-01.5" ], - "7025(c)(3)": [ - "PRI-03.8" + "§ 6(1)": [ + "PRI-01.6" ], - "7025(c)(6)": [ - "PRI-03.8" + "§ 13(1)": [ + "PRI-01.6" ], - "7025(d)": [ - "PRI-03.8" + "§ 54(1)": [ + "PRI-01.6" ], - "7025(e)": [ - "PRI-03.8" + "§ 1(1)": [ + "PRI-01.11" ], - "7025(f)": [ - "PRI-03.8" + "§ 1(2)": [ + "PRI-01.11" ], - "7025(f)(1)": [ - "PRI-03.8" + "§ 1(3)": [ + "PRI-01.11" ], - "7025(f)(2)": [ - "PRI-03.8" + "§ 1(4)": [ + "PRI-01.11" ], - "7025(f)(3)": [ - "PRI-03.8" + "§ 6(2)": [ + "PRI-01.11" ], - "7025(g)": [ - "PRI-03.8" + "§ 8(1)": [ + "PRI-01.11", + "PRI-03" ], - "7025(g)(1)": [ - "PRI-03.8" + "§ 8(2)": [ + "PRI-01.11" ], - "7025(g)(3)": [ - "PRI-03.8" + "§ 8(3)": [ + "PRI-01.11" ], - "7022(f)(3)": [ - "PRI-03.9" + "§ 37(1)": [ + "PRI-01.11" ], - "7027(g)(1)": [ - "PRI-03.9", - "PRI-03.10" + "§ 37(5)": [ + "PRI-01.11" ], - "7028(a)": [ - "PRI-03.12" + "§ 37(8)": [ + "PRI-01.11" ], - "7028(b)": [ - "PRI-03.12" + "§ 45(3)": [ + "PRI-01.11" ], - "7028(c)": [ - "PRI-03.12" + "§ 43(1)": [ + "PRI-02" ], - "7070(a)": [ - "PRI-03.13" + "§ 43(2)": [ + "PRI-02" ], - "7070(a)(1)": [ - "PRI-03.13" + "§ 43(3)": [ + "PRI-02" ], - "7070(a)(2)": [ - "PRI-03.13" + "§ 43(4)": [ + "PRI-02" ], - "7070(a)(2)(A)": [ - "PRI-03.13" + "§ 12(1)": [ + "PRI-03" ], - "7070(a)(2)(B)": [ - "PRI-03.13" + "§ 12(3)": [ + "PRI-03" ], - "7070(a)(2)(C)": [ - "PRI-03.13" + "§ 12(4)": [ + "PRI-03" ], - "7070(a)(2)(D)": [ - "PRI-03.13" + "§ 13(3)": [ + "PRI-05" ], - "7070(a)(2)(E)": [ - "PRI-03.13" + "§ 37(2)": [ + "PRI-05" ], - "7070(a)(2)(F)": [ - "PRI-03.13" + "§ 7(2)": [ + "PRI-05.1" ], - "7070(b)": [ - "PRI-03.13" + "§ 37(6)": [ + "PRI-05.2" ], - "7070(c)": [ - "PRI-03.13" + "§ 37(7)": [ + "PRI-05.2" ], - "7071(a)": [ - "PRI-03.13" + "§ 7(1)": [ + "PRI-05.4" ], - "7071(b)": [ - "PRI-03.13" + "§ 7(6)": [ + "PRI-05.4" ], - "7023(d)(3)": [ + "§ 38": [ "PRI-05.4" ], - "7026(f)": [ + "§ 39": [ "PRI-05.4" ], - "7026(f)(1)": [ + "§ 40(1)": [ "PRI-05.4" ], - "7027(a)": [ + "§ 40(2)": [ "PRI-05.4" ], - "7024(j)": [ - "PRI-05.7", - "PRI-06" + "§ 40(3)": [ + "PRI-05.4" ], - "7024(l)": [ - "PRI-05.7", - "TPM-01", - "TPM-01.1" + "§ 37(4)": [ + "PRI-05.7" ], - "7020(a)": [ + "§ 42(1)": [ "PRI-06" ], - "7020(b)": [ + "§ 42(2)": [ "PRI-06" ], - "7020(c)": [ + "§ 44(1)": [ "PRI-06" ], - "7020(d)": [ + "§ 44(5)": [ "PRI-06" ], - "7020(e)": [ - "PRI-06" + "§ 45(1)": [ + "PRI-06.1" ], - "7020(f)": [ - "PRI-06" + "§ 45(5)": [ + "PRI-06.2" ], - "7020(f)(1)": [ - "PRI-06" + "§ 42(3)": [ + "PRI-06.4" ], - "7020(f)(2)": [ - "PRI-06" + "§ 42(4)": [ + "PRI-06.4" ], - "7022(b)": [ - "PRI-06" + "§ 42(5)": [ + "PRI-06.4" ], - "7023(d)(1)": [ - "PRI-06", - "PRI-06.1", - "PRI-06.3" + "§ 42(6)": [ + "PRI-06.4" ], - "7024(g)": [ - "PRI-06", - "PRI-06.6", - "PRI-06.7", - "WEB-06" + "§ 45(8)": [ + "PRI-06.4" ], - "7024(h)": [ - "PRI-06" + "§ 45(9)": [ + "PRI-06.4" ], - "7027(e)": [ - "PRI-06", - "WEB-06" + "§ 44(3)": [ + "PRI-06.4" ], - "7023(a)": [ - "PRI-06.1", + "§ 44(4)": [ "PRI-06.4", - "PRI-12.1" + "PRI-07.5" ], - "7023(b)": [ - "PRI-06.1", - "PRI-07.4", - "PRI-12", - "PRI-12.1" + "§ 45(4)": [ + "PRI-06.4" ], - "7023(d)(2)": [ - "PRI-06.1" + "§ 45(2)": [ + "PRI-06.5" ], - "7022(e)": [ - "PRI-06.2", - "PRI-06.4" + "§ 48(1)": [ + "PRI-07.1" ], - "7023(f)": [ - "PRI-06.2" + "§ 48(2)": [ + "PRI-07.1" ], - "7023(f)(3)": [ - "PRI-06.3", - "PRI-06.4" + "§ 48(3)": [ + "PRI-07.1" ], - "7021(a)": [ - "PRI-06.4" + "§ 48(4)": [ + "PRI-07.1" ], - "7021(b)": [ - "PRI-06.4" + "§ 48(5)": [ + "PRI-07.1" ], - "7022(f)": [ - "PRI-06.4" + "§ 48(6)": [ + "PRI-07.1" ], - "7022(f)(1)": [ - "PRI-06.4" + "§ 47": [ + "PRI-07.2" ], - "7023(d)(2)(A)": [ - "PRI-06.4" + "§ 13(2)": [ + "PRI-14" ], - "7023(d)(2)(B)": [ - "PRI-06.4" + "§ 49(1)": [ + "PRI-14" ], - "7023(d)(2)(C)": [ - "PRI-06.4" + "§ 49(2)": [ + "PRI-14" ], - "7023(d)(2)(D)": [ - "PRI-06.4" + "§ 49(3)": [ + "PRI-14" ], - "7023(f)(1)": [ - "PRI-06.4" + "§ 50(1)": [ + "PRI-14" ], - "7023(f)(2)": [ - "PRI-06.4" + "§ 50(2)": [ + "PRI-14" ], - "7023(f)(4)": [ - "PRI-06.4" + "§ 50(3)": [ + "PRI-14" ], - "7023(i)": [ - "PRI-06.4" + "§ 50(5)": [ + "PRI-14" ], - "7023(j)": [ - "PRI-06.4" + "§ 41(1)": [ + "PRI-19" ], - "7023(k)": [ - "PRI-06.4" + "§ 41(2)": [ + "PRI-19" ], - "7024(c)": [ - "PRI-06.4" + "§ 41(3)": [ + "PRI-19" + ] + }, + "emea-bel-act-30-2018": { + "Title 2, Chapter II, Art. 29(5)": [ + "CPL-01.3" ], - "7024(c)(1)": [ - "PRI-06.4" + "Title 4, Chapter III, Section 3, Art. 198": [ + "DCH-23" ], - "7024(c)(2)": [ - "PRI-06.4" + "Title 4, Chapter III, Section 3, Art. 199": [ + "DCH-23" ], - "7024(c)(3)": [ - "PRI-06.4" + "Title 4, Chapter III, Section 3, Art. 200": [ + "DCH-23" ], - "7024(c)(4)": [ - "PRI-06.4" + "Title 4, Chapter III, Section 3, Art. 201": [ + "DCH-23" ], - "7024(d)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 61(1)": [ + "IRO-10" ], - "7024(d)(1)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 61(2)": [ + "IRO-10" ], - "7024(d)(2)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 61(3)": [ + "IRO-10" ], - "7024(e)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 61(4)": [ + "IRO-10" ], - "7024(e)(1)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 61(5)": [ + "IRO-10" ], - "7024(e)(2)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 61(6)": [ + "IRO-10" ], - "7024(k)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 62(1)": [ + "IRO-10" ], - "7024(k)(1)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 62(2)": [ + "IRO-10" ], - "7024(k)(2)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 62(3)": [ + "IRO-10" ], - "7024(k)(3)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 62(4)": [ + "IRO-10" ], - "7024(k)(4)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 4, Art. 62(5)": [ + "IRO-10" ], - "7024(k)(5)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 5, Art. 63": [ + "PRI-01.4" ], - "7024(k)(6)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 5, Art. 64": [ + "PRI-01.4" ], - "7027(h)": [ - "PRI-06.4" + "Title 2, Chapter IV, Section 5, Art. 65": [ + "PRI-01.4" ], - "7022(b)(1)": [ - "PRI-06.5" + "Title 4, Chapter II, Art. 190": [ + "PRI-01.4" ], - "7022(f)(2)": [ - "PRI-06.5" + "Title 4, Chapter II, Art. 191": [ + "PRI-01.4" ], - "7060(a)": [ - "PRI-06.8" + "Title 4, Chapter II, Art. 192": [ + "PRI-01.4" ], - "7060(b)": [ - "PRI-06.8", - "PRI-21.1" + "Title 2, Chapter V, Art. 66(1)": [ + "PRI-01.5" ], - "7060(c)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 66(2)": [ + "PRI-01.5" ], - "7060(c)(1)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 67": [ + "PRI-01.5" ], - "7060(c)(2)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 68(1)": [ + "PRI-01.5" ], - "7060(c)(3)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 68(2)": [ + "PRI-01.5" ], - "7060(c)(3)(A)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 68(3)": [ + "PRI-01.5" ], - "7060(c)(3)(B)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 69(1)": [ + "PRI-01.5" ], - "7060(c)(3)(C)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 69(2)": [ + "PRI-01.5" ], - "7060(c)(3)(D)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 69(3)": [ + "PRI-01.5" ], - "7060(c)(3)(E)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 70(1)": [ + "PRI-01.5" ], - "7060(c)(3)(F)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 70(2)": [ + "PRI-01.5" ], - "7060(d)": [ - "PRI-06.8" + "Title 2, Chapter V, Art. 70(3)": [ + "PRI-01.5" ], - "7060(e)": [ - "PRI-06.8" + "Title 2, Chapter II, Art. 34(2)": [ + "PRI-01.6" ], - "7060(f)": [ - "PRI-06.8" + "Title 2, Chapter III, Art. 45(4)": [ + "PRI-01.6" ], - "7060(g)": [ - "PRI-06.8" + "Title 2, Chapter IV, Section 1, Art. 50": [ + "PRI-01.6" ], - "7060(h)": [ - "PRI-06.8" + "Title 2, Chapter IV, Section 1, Art. 51(1)": [ + "PRI-01.6" ], - "7061(a)": [ - "PRI-06.8" + "Title 2, Chapter IV, Section 1, Art. 51(2)": [ + "PRI-01.6" ], - "7061(b)": [ - "PRI-06.8" + "Title 2, Chapter IV, Section 4, Art. 60(1)": [ + "PRI-01.6" ], - "7062(a)": [ - "PRI-06.8" + "Title 2, Chapter IV, Section 4, Art. 60(2)": [ + "PRI-01.6" ], - "7062(b)": [ - "PRI-06.8" + "Title 1, Section III, Art. 14(2)": [ + "PRI-01.11" ], - "7062(c)": [ - "PRI-06.8" + "Title 2, Chapter II, Art. 28": [ + "PRI-01.11" ], - "7062(d)": [ - "PRI-06.8" + "Title 2, Chapter II, Art. 32(1)": [ + "PRI-01.11" ], - "7062(f)": [ - "PRI-06.8" + "Title 2, Chapter II, Art. 32(3)": [ + "PRI-01.11", + "PRI-17" ], - "7062(g)": [ - "PRI-06.8" + "Title 2, Chapter II, Art. 34(1)": [ + "PRI-01.11" ], - "7012(g)(2)": [ - "PRI-07.1", - "TPM-05" + "Title 2, Chapter III, Art. 39(3)": [ + "PRI-01.11" ], - "7022(c)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 45(3)": [ + "PRI-01.11" ], - "7022(c)(1)": [ - "PRI-07.1" + "Title 4, Chapter III, Section 2, Art. 194": [ + "PRI-01.11" ], - "7022(c)(2)": [ - "PRI-07.1" + "Title 4, Chapter III, Section 2, Art. 195": [ + "PRI-01.11" ], - "7022(c)(3)": [ - "PRI-07.1" + "Title 4, Chapter III, Section 2, Art. 196": [ + "PRI-01.11" ], - "7022(c)(4)": [ - "PRI-07.1" + "Title 4, Chapter III, Section 2, Art. 197": [ + "PRI-01.11" ], - "7024(i)": [ - "PRI-07.1" + "Title 4, Chapter III, Section 3, Art. 202(1)": [ + "PRI-01.11" ], - "7050(a)": [ - "PRI-07.1" + "Title 4, Chapter III, Section 3, Art. 202(2)": [ + "PRI-01.11" ], - "7050(a)(1)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 37(1)": [ + "PRI-02" ], - "7050(a)(2)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 37(2)": [ + "PRI-02" + ], + "Title 4, Chapter III, Section 1, Art. 193": [ + "PRI-02" + ], + "Title 1, Chapter II, Art. 7": [ + "PRI-03.3" + ], + "Title 2, Chapter II, Art. 29(1)": [ + "PRI-04" + ], + "Title 2, Chapter II, Art. 29(2)": [ + "PRI-04" + ], + "Title 1, Section III, Art. 14(4)": [ + "PRI-04.1" + ], + "Title 2, Chapter II, Art. 33(1)": [ + "PRI-04.1" + ], + "Title 2, Chapter II, Art. 33(2)": [ + "PRI-04.1" + ], + "Title 2, Chapter II, Art. 30": [ + "PRI-05" + ], + "Title 2, Chapter II, Art. 32(2)": [ + "PRI-05.2" + ], + "Title 1, Chapter II, Art. 8(3)": [ + "PRI-05.4" + ], + "Title 1, Chapter II, Art. 9": [ + "PRI-05.4" ], - "7050(a)(3)": [ - "PRI-07.1" + "Title 1, Chapter II, Art. 10(1)": [ + "PRI-05.4" ], - "7050(a)(4)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 45(2)": [ + "PRI-05.4" ], - "7050(c)": [ - "PRI-07.1" + "Title 1, Chapter II, Art. 8(2)": [ + "PRI-05.7" ], - "7050(d)": [ - "PRI-07.1" + "Title 1, Chapter II, Art. 10(2)": [ + "PRI-05.7" ], - "7050(e)": [ - "PRI-07.1" + "Title 2, Chapter II, Art. 31": [ + "PRI-05.7" ], - "7050(f)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 36(2)": [ + "PRI-06" ], - "7050(g)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 38(1)": [ + "PRI-06" ], - "7050(h)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 38(2)": [ + "PRI-06" ], - "7050(h)(1)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 39(1)": [ + "PRI-06" ], - "7050(h)(2)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 39(5)": [ + "PRI-06.2" ], - "7051(a)": [ - "PRI-07.1", - "TPM-05" + "Title 2, Chapter III, Art. 39(6)": [ + "PRI-06.2" ], - "7051(a)(1)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 36(3)": [ + "PRI-06.4" ], - "7051(a)(2)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 38(3)": [ + "PRI-06.4" ], - "7051(a)(3)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 39(4)": [ + "PRI-06.4" ], - "7051(a)(4)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 40": [ + "PRI-06.4" ], - "7051(a)(5)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 39(2)": [ + "PRI-06.5" ], - "7051(a)(6)": [ + "Title 2, Chapter IV, Section 3, Art. 53(1)": [ "PRI-07.1" ], - "7051(a)(7)": [ + "Title 2, Chapter IV, Section 3, Art. 53(2)": [ "PRI-07.1" ], - "7051(a)(8)": [ + "Title 2, Chapter IV, Section 3, Art. 53(3)": [ "PRI-07.1" ], - "7051(a)(9)": [ + "Title 2, Chapter IV, Section 3, Art. 53(4)": [ "PRI-07.1" ], - "7053(a)(1)": [ + "Title 2, Chapter IV, Section 3, Art. 53(5)": [ "PRI-07.1" ], - "7053(a)(2)": [ + "Title 2, Chapter IV, Section 3, Art. 54": [ "PRI-07.1" ], - "7053(a)(3)": [ - "PRI-07.1" + "Title 2, Chapter IV, Section 2, Art. 52": [ + "PRI-07.2" ], - "7053(a)(4)": [ - "PRI-07.1" + "Title 2, Chapter III, Art. 36(4)": [ + "PRI-07.4" ], - "7022(b)(2)": [ - "PRI-07.3" + "Title 2, Chapter III, Art. 36(5)": [ + "PRI-07.5" ], - "7022(b)(3)": [ - "PRI-07.3" + "Title 1, Section III, Art. 14(3)": [ + "PRI-14" ], - "7022(f)(4)": [ - "PRI-07.3" + "Title 2, Chapter III, Art. 45(5)": [ + "PRI-14" ], - "7026(f)(2)": [ - "PRI-07.3" + "Title 2, Chapter IV, Section 4, Art. 55(1)": [ + "PRI-14" ], - "7027(g)(2)": [ - "PRI-07.3" + "Title 2, Chapter IV, Section 4, Art. 55(2)": [ + "PRI-14" ], - "7027(g)(3)": [ - "PRI-07.3" + "Title 2, Chapter IV, Section 4, Art. 55(3)": [ + "PRI-14" ], - "7022(a)": [ - "PRI-07.4" + "Title 2, Chapter IV, Section 4, Art. 56(1)": [ + "PRI-14" ], - "7024(a)": [ - "PRI-07.4" + "Title 2, Chapter IV, Section 4, Art. 56(2)": [ + "PRI-14" ], - "7024(b)": [ - "PRI-07.4" + "Title 2, Chapter IV, Section 4, Art. 56(3)": [ + "PRI-14" ], - "7026(e)": [ - "PRI-07.4" + "Title 2, Chapter IV, Section 4, Art. 57": [ + "PRI-14" ], - "7023(g)": [ - "PRI-07.5" + "Title 2, Chapter IV, Section 4, Art. 58": [ + "PRI-14" ], - "7023(h)": [ - "PRI-07.5" + "Title 2, Chapter III, Art. 36(1)": [ + "PRI-17" ], - "7027(f)": [ - "PRI-07.5" + "Title 2, Chapter III, Art. 38(4)": [ + "PRI-18" ], - "7023(b)(1)": [ - "PRI-12" + "Title 2, Chapter II, Art. 35": [ + "PRI-19" + ] + }, + "emea-deu-fdpa-2017": { + "3.5.79(3)": [ + "GOV-17" ], - "7023(b)(1)(A)": [ - "PRI-12" + "3.4.76(5)": [ + "CPL-01" ], - "7023(b)(1)(B)": [ - "PRI-12" + "3.4.77": [ + "CPL-01" ], - "7023(b)(1)(C)": [ - "PRI-12" + "3.2.48(2)7": [ + "CRY-01" ], - "7023(b)(2)": [ - "PRI-12" + "3.4.64(2)": [ + "DCH-23" ], - "7004(a)(3)": [ - "PRI-17" + "3.2.48(2)8": [ + "HRS-05" ], - "7222(b)": [ - "PRI-17" + "2.1.2.27(1)": [ + "IAC-08" ], - "7222(b)(1)": [ - "PRI-17" + "3.2.48(2)4": [ + "IAC-08" ], - "7222(b)(2)": [ - "PRI-17" + "3.4.65(1)": [ + "IRO-04.1", + "IRO-10.2" ], - "7222(b)(3)": [ - "PRI-17" + "3.4.65(2)": [ + "IRO-04.1", + "IRO-10.2" ], - "7222(b)(3)(A)": [ - "PRI-17" + "3.4.66(1)": [ + "IRO-10" ], - "7222(b)(4)": [ - "PRI-17" + "3.4.66(2)": [ + "IRO-10" ], - "7222(b)(4)(A)": [ - "PRI-17" + "3.4.65(3)": [ + "IRO-10.2" ], - "7222(c)": [ - "PRI-17" + "3.4.65(3)1": [ + "IRO-10.2" ], - "7222(c)(1)": [ - "PRI-17" + "3.4.65(3)2": [ + "IRO-10.2" ], - "7222(c)(2)": [ - "PRI-17" + "3.4.65(3)3": [ + "IRO-10.2" ], - "7222(c)(2)(A)": [ - "PRI-17" + "3.4.65(3)4": [ + "IRO-10.2" ], - "7222(c)(2)(B)": [ - "PRI-17" + "3.4.65(4)": [ + "IRO-10.2" ], - "7222(c)(2)(C)": [ - "PRI-17" + "3.4.65(5)": [ + "IRO-10.2" ], - "7222(d)": [ - "PRI-17" + "3.4.65(6)": [ + "IRO-10.2" ], - "7222(e)": [ - "PRI-17" + "2.1.2.26(5)": [ + "PRI-01" ], - "7222(f)": [ - "PRI-17" + "2.1.1.22(2)4": [ + "PRI-01.4" ], - "7222(g)": [ - "PRI-17" + "2.3.38(1)": [ + "PRI-01.4" ], - "7222(h)": [ - "PRI-17" + "2.3.38(2)": [ + "PRI-01.4" ], - "7222(i)": [ - "PRI-17" + "3.4.62(3)": [ + "PRI-01.5", + "PRI-07.2" ], - "7222(j)": [ - "PRI-17" + "3.4.62(4)": [ + "PRI-01.5", + "PRI-07.2" ], - "7222(k)": [ - "PRI-17" + "3.4.62(5)": [ + "PRI-01.5", + "PRI-07.2" ], - "7003(c)": [ - "PRI-17.1" + "3.4.62(5)1": [ + "PRI-01.5", + "PRI-07.2" ], - "7003(d)": [ - "PRI-17.1" + "3.4.62(5)2": [ + "PRI-01.5", + "PRI-01.6", + "PRI-07.2" ], - "7010(g)": [ - "PRI-17.2" + "3.4.62(5)3": [ + "PRI-01.5", + "PRI-07.2" ], - "7080(e)": [ - "PRI-17.2" + "3.4.62(5)4": [ + "PRI-01.5", + "PRI-05", + "PRI-07.2" ], - "7101(a)": [ - "PRI-17.3" + "3.4.62(5)5": [ + "PRI-01.5", + "PRI-07.2" ], - "7101(b)": [ - "PRI-17.3" + "3.4.62(5)6": [ + "PRI-01.5", + "PRI-07.2" ], - "7101(c)": [ - "PRI-17.3" + "3.4.62(5)7": [ + "PRI-01.5", + "PRI-07.2" ], - "7101(d)": [ - "PRI-17.3" + "3.4.62(5)8": [ + "PRI-01.5" ], - "7101(e)": [ - "PRI-17.3" + "3.4.62(5)9": [ + "PRI-01.5", + "PRI-07.2" ], - "7102(a)(1)": [ - "PRI-17.4" + "3.4.62(6)": [ + "PRI-01.5" ], - "7102(a)(1)(A)": [ - "PRI-17.4" + "3.4.62(7)": [ + "PRI-01.5" ], - "7102(a)(1)(B)": [ - "PRI-17.4" + "3.4.63": [ + "PRI-01.5", + "PRI-07.2" ], - "7102(a)(1)(C)": [ - "PRI-17.4" + "3.5.78(1)": [ + "PRI-01.5" ], - "7102(a)(1)(D)": [ - "PRI-17.4" + "3.5.78(1)1": [ + "PRI-01.5" ], - "7102(a)(1)(E)": [ - "PRI-17.4" + "3.5.78(1)2": [ + "PRI-01.5" ], - "7102(a)(1)(F)": [ - "PRI-17.4" + "3.5.78(2)": [ + "PRI-01.5" ], - "7102(a)(1)(G)": [ - "PRI-17.4" + "3.5.78(3)": [ + "PRI-01.5" ], - "7102(a)(1)(H)": [ - "PRI-17.4" + "3.5.78(4)": [ + "PRI-01.5" ], - "7102(a)(2)": [ - "PRI-17.5" + "3.5.79(1)": [ + "PRI-01.5" ], - "7102(b)": [ - "PRI-17.5" + "3.5.79(1)1": [ + "PRI-01.5" ], - "7010(c)": [ - "PRI-19.1" + "2.1.1.22(2)5": [ + "PRI-01.6" ], - "7220(a)": [ - "PRI-19.1" + "2.1.1.22(2)6": [ + "PRI-01.6" ], - "7220(b)": [ - "PRI-19.1" + "2.1.1.22(2)7": [ + "PRI-01.6" ], - "7220(b)(1)": [ - "PRI-19.1" + "2.1.2.28(1)": [ + "PRI-01.6" ], - "7220(b)(2)": [ - "PRI-19.1" + "3.2.53": [ + "PRI-01.6" ], - "7220(b)(3)": [ - "PRI-19.1" + "3.4.64(1)": [ + "PRI-01.6" ], - "7220(c)": [ - "PRI-19.1" + "3.4.64(2)1": [ + "PRI-01.6" ], - "7220(c)(1)": [ - "PRI-19.1" + "3.4.64(2)2": [ + "PRI-01.6" ], - "7220(c)(2)": [ - "PRI-19.1" + "3.4.64(3)": [ + "PRI-01.6" ], - "7220(c)(2)(A)": [ - "PRI-19.1" + "3.4.64(3)1": [ + "PRI-01.6" ], - "7220(c)(2)(B)": [ - "PRI-19.1" + "3.4.64(3)2": [ + "PRI-01.6" ], - "7220(c)(3)": [ - "PRI-19.1" + "3.4.64(3)3": [ + "PRI-01.6" ], - "7220(c)(4)": [ - "PRI-19.1" + "3.4.64(3)4": [ + "PRI-01.6" ], - "7220(c)(5)": [ - "PRI-19.1" + "3.4.64(3)5": [ + "PRI-01.6" ], - "7220(c)(5)(A)": [ - "PRI-19.1" + "3.4.64(3)6": [ + "PRI-01.6" ], - "7220(c)(5)(B)": [ - "PRI-19.1" + "3.4.64(3)7": [ + "PRI-01.6" ], - "7220(c)(5)(C)": [ - "PRI-19.1" + "3.4.64(3)8": [ + "PRI-01.6" ], - "7220(e)": [ - "PRI-19.1" + "3.4.64(3)9": [ + "PRI-01.6" ], - "7220(e)(1)": [ - "PRI-19.1" + "3.4.64(3)10": [ + "PRI-01.6" ], - "7220(e)(2)": [ - "PRI-19.1" + "3.4.64(3)11": [ + "PRI-01.6" ], - "7220(e)(3)": [ - "PRI-19.1" + "3.4.64(3)12": [ + "PRI-01.6" ], - "7220(e)(4)": [ - "PRI-19.1" + "3.4.64(3)13": [ + "PRI-01.6" ], - "7010(d)": [ - "PRI-19.2" + "3.4.64(3)14": [ + "PRI-01.6" ], - "7221(a)": [ - "PRI-19.2" + "3.4.71(2)": [ + "PRI-01.6" ], - "7221(b)": [ - "PRI-19.2" + "2.2.32(1)1": [ + "PRI-01.11" ], - "7221(b)(1)": [ - "PRI-19.2" + "2.2.32(1)2": [ + "PRI-01.11" ], - "7221(b)(1)(A)": [ - "PRI-19.2" + "2.2.32(1)3": [ + "PRI-01.11" ], - "7221(b)(1)(B)": [ - "PRI-19.2" + "2.2.32(1)4": [ + "PRI-01.11" ], - "7221(b)(2)": [ - "PRI-19.2" + "2.2.32(1)5": [ + "PRI-01.11" ], - "7221(b)(2)(A)": [ - "PRI-19.2" + "2.2.32(2)": [ + "PRI-01.11" ], - "7221(b)(2)(B)": [ - "PRI-19.2" + "2.2.32(3)": [ + "PRI-01.11" ], - "7221(b)(3)": [ - "PRI-19.2" + "2.2.33(1)1(a)": [ + "PRI-01.11" ], - "7221(b)(3)(A)": [ - "PRI-19.2" + "2.2.33(1)1(b)": [ + "PRI-01.11" ], - "7221(b)(3)(B)": [ - "PRI-19.2" + "2.2.33(1)2": [ + "PRI-01.11" ], - "7221(c)": [ - "PRI-19.2" + "2.2.33(2)": [ + "PRI-01.11", + "PRI-17" ], - "7221(d)": [ - "PRI-19.2" + "2.2.35(3)": [ + "PRI-01.11" ], - "7221(e)": [ - "PRI-19.2" + "2.2.36": [ + "PRI-01.11" ], - "7221(f)": [ - "PRI-19.2" + "3.1.47.1": [ + "PRI-01.11" ], - "7221(g)": [ - "PRI-19.2" + "3.2.48(2)": [ + "PRI-01.11" ], - "7221(h)": [ - "PRI-19.2" + "3.2.48(2)1": [ + "PRI-01.11" ], - "7221(m)": [ - "PRI-19.2" + "3.2.48(2)5": [ + "PRI-01.11" ], - "7221(n)": [ - "PRI-19.2" + "3.3.57(4)": [ + "PRI-01.11" ], - "7221(n)(1)": [ - "PRI-19.2" + "3.3.58(3)": [ + "PRI-01.11" ], - "7221(n)(2)": [ - "PRI-19.2" + "3.3.58(3)1": [ + "PRI-01.11" ], - "7222(a)": [ - "PRI-19.3" + "3.3.58(3)2": [ + "PRI-01.11" ], - "7012(i)": [ - "PRI-20" + "3.3.58(3)3": [ + "PRI-01.11" ], - "7013(a)": [ - "PRI-21" + "3.3.58(4)": [ + "PRI-01.11" ], - "7013(b)": [ - "PRI-21" + "3.3.59(3)": [ + "PRI-01.11", + "PRI-03.5" ], - "7013(d)": [ - "PRI-21" + "3.4.71(1)": [ + "PRI-01.11" ], - "7013(f)": [ - "PRI-21" + "3.4.74(1)": [ + "PRI-01.11", + "PRI-05.2" ], - "7013(f)(1)": [ - "PRI-21" + "3.4.74(2)": [ + "PRI-01.11", + "PRI-17" ], - "7013(f)(2)": [ - "PRI-21" + "3.5.80(1)": [ + "PRI-01.11" ], - "7026(a)": [ - "PRI-21", - "PRI-21.1" + "3.5.80(1)1": [ + "PRI-01.11" ], - "7026(b)": [ - "PRI-21.1" + "3.5.80(1)2": [ + "PRI-01.11" ], - "7026(c)": [ - "PRI-21.1" + "3.5.80(1)3": [ + "PRI-01.11" ], - "7026(d)": [ - "PRI-21.1" + "3.5.80(1)4": [ + "PRI-01.11" ], - "7026(g)": [ - "PRI-21.1" + "3.5.80(1)5": [ + "PRI-01.11" ], - "7026(h)": [ - "PRI-21.1" + "3.5.80(2)": [ + "PRI-01.11" ], - "7015(a)": [ - "PRI-21.2" + "3.5.80(3)": [ + "PRI-01.11" ], - "7015(b)": [ - "PRI-21.2" + "3.7.83(2)": [ + "PRI-01.11" ], - "7015(b)(1)": [ - "PRI-21.2" + "3.7.83(3)": [ + "PRI-01.11" ], - "7015(b)(2)": [ - "PRI-21.2" + "3.7.83(4)": [ + "PRI-01.11" ], - "7015(b)(3)": [ - "PRI-21.2" + "3.7.83(5)": [ + "PRI-01.11" ], - "7015(c)": [ - "PRI-21.2" + "3.2.51(4)": [ + "PRI-02" ], - "7015(c)(1)": [ - "PRI-21.2" + "3.3.55": [ + "PRI-02" ], - "7015(c)(2)": [ - "PRI-21.2" + "3.3.55.1": [ + "PRI-02" ], - "7100(b)": [ - "PRM-01.1", - "PRM-05" + "3.3.55.2": [ + "PRI-02" ], - "7102(a)": [ - "PRM-01.1" + "3.3.55.3": [ + "PRI-02" ], - "7152(a)": [ - "RSK-04", - "RSK-04.2", - "RSK-10" + "3.3.55.4": [ + "PRI-02" ], - "7155(a)": [ - "RSK-04", - "RSK-07", - "RSK-10" + "3.3.55.5": [ + "PRI-02" ], - "7150(a)": [ - "RSK-04.3" + "3.3.56(1)": [ + "PRI-02" ], - "7150(b)": [ - "RSK-04.3" + "3.3.56(1)1": [ + "PRI-02" ], - "7150(b)(1)": [ - "RSK-04.3" + "3.3.56(1)2": [ + "PRI-02", + "PRI-02.1" ], - "7150(b)(2)": [ - "RSK-04.3" + "3.3.56(1)3": [ + "PRI-02" ], - "7150(b)(2)(A)": [ - "RSK-04.3" + "3.3.56(1)4": [ + "PRI-02" ], - "7150(b)(3)": [ - "RSK-04.3" + "3.3.56(1)5": [ + "PRI-02" ], - "7150(b)(4)": [ - "RSK-04.3" + "3.3.56(2)1": [ + "PRI-02" ], - "7150(b)(5)": [ - "RSK-04.3" + "3.3.56(2)2": [ + "PRI-02" ], - "7150(b)(6)": [ - "RSK-04.3" + "3.3.56(2)3": [ + "PRI-02" ], - "7155(a)(1)": [ - "RSK-04.3" + "3.3.56(3)": [ + "PRI-02" ], - "7155(a)(2)": [ - "RSK-04.3" + "2.1.2.26(2)": [ + "PRI-03", + "PRI-04.1" ], - "7155(a)(3)": [ - "RSK-04.3" + "2.1.2.26(3)": [ + "PRI-03", + "PRI-04.1", + "PRI-05.7" ], - "7155(b)": [ - "RSK-04.3" + "2.1.2.27(4)": [ + "PRI-03" ], - "7151(a)": [ - "RSK-04.4" + "3.2.51(1)": [ + "PRI-03" ], - "7151(b)": [ - "RSK-04.4" + "3.2.51(2)": [ + "PRI-03" ], - "7002(d)(3)": [ - "RSK-06.2" + "3.2.51(5)": [ + "PRI-03", + "PRI-05.7" ], - "7152(a)(1)": [ - "RSK-10" + "3.2.51(3)": [ + "PRI-03.4" ], - "7152(a)(2)": [ - "RSK-10" + "3.4.75(3)": [ + "PRI-03.11", + "PRI-06.2" ], - "7152(a)(3)": [ - "RSK-10" + "3.1.47.2": [ + "PRI-04" ], - "7152(a)(3)(A)": [ - "RSK-10" + "3.1.47.3": [ + "PRI-04" ], - "7152(a)(3)(B)": [ - "RSK-10" + "3.1.47.6": [ + "PRI-04" ], - "7152(a)(3)(C)": [ - "RSK-10" + "2.1.2.26(1)": [ + "PRI-04.1" ], - "7152(a)(3)(D)": [ - "RSK-10" + "2.1.2.26(4)": [ + "PRI-04.1", + "PRI-05.7" ], - "7152(a)(3)(E)": [ - "RSK-10" + "3.2.49": [ + "PRI-04.1" ], - "7152(a)(3)(F)": [ - "RSK-10" + "3.2.50": [ + "PRI-04.1", + "PRI-05.3" ], - "7152(a)(3)(G)": [ - "RSK-10" + "3.3.56(2)": [ + "PRI-04.7" ], - "7152(a)(3)(G)(i)": [ - "RSK-10" + "3.1.47.5": [ + "PRI-05" ], - "7152(a)(3)(G)(ii)": [ - "RSK-10" + "3.2.48(2)2": [ + "PRI-05" ], - "7152(a)(4)": [ - "RSK-10" + "3.3.58(2)": [ + "PRI-05", + "PRI-06", + "PRI-06.5" ], - "7152(a)(5)": [ - "RSK-10" + "3.4.75(2)": [ + "PRI-05" ], - "7152(a)(5)(A)": [ - "RSK-10" + "3.4.75(4)": [ + "PRI-05" ], - "7152(a)(5)(B)": [ - "RSK-10" + "2.1.2.27(3)": [ + "PRI-05.1" ], - "7152(a)(5)(C)": [ - "RSK-10" + "3.1.47.4": [ + "PRI-05.2" ], - "7152(a)(5)(D)": [ - "RSK-10" + "3.2.48(2)6": [ + "PRI-05.3" ], - "7152(a)(5)(E)": [ - "RSK-10" + "2.1.1.22(1)": [ + "PRI-05.4" ], - "7152(a)(5)(F)": [ - "RSK-10" + "2.1.1.22(1)1": [ + "PRI-05.4" ], - "7152(a)(5)(G)": [ - "RSK-10" + "2.1.1.22(1)1(a)": [ + "PRI-05.4" ], - "7152(a)(5)(H)": [ - "RSK-10" + "2.1.1.22(1)1(b)": [ + "PRI-05.4" ], - "7152(a)(6)": [ - "RSK-10" + "2.1.1.22(1)1(c)": [ + "PRI-05.4" ], - "7152(a)(6)(A)": [ - "RSK-10" + "2.1.1.22(1)1(d)": [ + "PRI-05.4" ], - "7152(a)(6)(A)(i)": [ - "RSK-10" + "2.1.1.22(1)2(a)": [ + "PRI-05.4" ], - "7152(a)(6)(A)(ii)": [ - "RSK-10" + "2.1.1.22(1)2(b)": [ + "PRI-05.4" ], - "7152(a)(6)(A)(iii)": [ - "RSK-10" + "2.1.1.22(2)": [ + "PRI-05.4" ], - "7152(a)(6)(A)(iv)": [ - "RSK-10" + "2.1.1.22(2)1": [ + "PRI-05.4" ], - "7152(a)(7)": [ - "RSK-10" + "2.1.1.22(2)2": [ + "PRI-05.4" ], - "7152(a)(8)": [ - "RSK-10" + "2.1.1.22(2)3": [ + "PRI-05.4" ], - "7152(a)(9)": [ - "RSK-10" + "2.1.1.22(2)8": [ + "PRI-05.4" ], - "7154(a)": [ - "RSK-10" + "2.1.1.22(2)9": [ + "PRI-05.4" ], - "7156(a)": [ - "RSK-10" + "2.1.1.22(2)10": [ + "PRI-05.4" ], - "7156(b)": [ - "RSK-10" + "2.1.1.24(1)": [ + "PRI-05.4" ], - "7123(c)(12)": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6", - "SAT-04" + "2.1.1.24(1)1": [ + "PRI-05.4" ], - "7100(a)": [ - "SAT-02", - "SAT-03", - "SAT-03.3" + "2.1.1.24(1)2": [ + "PRI-05.4" ], - "7123(c)(13)": [ - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.6", - "SAT-04" + "2.1.1.24(2)": [ + "PRI-05.4" ], - "7123(c)(14)": [ - "TDA-01", - "TDA-01.1", - "TDA-01.3", - "TDA-01.4", - "TDA-02", - "TDA-02.3", - "TDA-02.4", - "TDA-02.6", - "TDA-02.7", - "TDA-02.8", - "TDA-02.9", - "TDA-02.10", - "TDA-02.11", - "TDA-02.13", - "TDA-05", - "TDA-06", - "TDA-06.1", - "TDA-06.2", - "TDA-06.3", - "TDA-06.4", - "TDA-06.5", - "TDA-06.6", - "TDA-07", - "TDA-08", - "TDA-08.1", - "TDA-09", - "TDA-09.6", - "TDA-10", - "TDA-14", - "TDA-15", - "TDA-20", - "TDA-20.4", - "TDA-21", - "TDA-22" + "2.2.33(1)2(a)": [ + "PRI-05.4" ], - "7123(c)(6)": [ - "TDA-02.11", - "TDA-02.13", - "TDA-09.5", - "THR-06", - "THR-06.1", - "VPM-01", - "VPM-06", - "VPM-07" + "2.2.33(1)3(b)": [ + "PRI-05.4" ], - "7052(a)": [ - "TPM-01", - "TPM-05.4" + "3.2.52": [ + "PRI-05.4" ], - "7123(c)(15)": [ - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-03", - "TPM-04", - "TPM-04.1", - "TPM-04.3", - "TPM-04.4", - "TPM-05", - "TPM-05.1", - "TPM-05.2", - "TPM-05.4", - "TPM-05.5", - "TPM-05.6", - "TPM-05.7", - "TPM-06", - "TPM-07", - "TPM-08", - "TPM-09", - "TPM-10" + "2.1.2.26(7)": [ + "PRI-05.7" ], - "7052(b)": [ - "TPM-05", - "TPM-05.2" + "3.2.48(1)": [ + "PRI-05.7" ], - "7053(a)": [ - "TPM-05", - "TPM-05.2" + "3.4.70(2)": [ + "PRI-05.7" ], - "7053(a)(6)": [ - "TPM-05" + "3.4.72": [ + "PRI-05.7" ], - "7051(b)": [ - "TPM-05.2" + "3.4.72.1": [ + "PRI-05.7" ], - "7053(a)(5)": [ - "TPM-05.7", - "TPM-09" + "3.4.72.2": [ + "PRI-05.7" ], - "7051(c)": [ - "TPM-08" + "3.4.72.3": [ + "PRI-05.7" ], - "7053(b)": [ - "TPM-08" - ] - }, - "usa-state-ca-sb1386-2002": { - "1798.29(a)": [ - "IRO-01", - "IRO-02", - "IRO-10", - "IRO-10.2" + "3.4.72.4": [ + "PRI-05.7" ], - "1798.29(c)": [ - "IRO-10" + "3.4.72.5": [ + "PRI-05.7" ], - "1798.82(a)": [ - "IRO-10" + "3.4.73": [ + "PRI-05.7" ], - "1798.82(b)": [ - "IRO-10" + "3.3.57(1)": [ + "PRI-06" ], - "1798.82(c)": [ - "IRO-10" + "3.3.57(1)2": [ + "PRI-06" ], - "1798.29(b)": [ - "IRO-10.2" - ] - }, - "usa-state-co-privacy-act-2021": { - "6-1-1305(1)": [ - "CPL-01" + "3.3.57(1)3": [ + "PRI-06" ], - "6-1-1305(2)": [ - "CPL-01" + "3.3.57(1)4": [ + "PRI-06", + "PRI-14.1" ], - "6-1-1305(2)(b)": [ - "CPL-01" + "3.3.57(1)5": [ + "PRI-06" ], - "6-1-1305(2)(c)": [ - "CPL-01" + "3.3.57(1)6": [ + "PRI-06", + "PRI-06.1" ], - "6-1-1308(6)": [ - "CPL-01" + "3.3.57(1)7": [ + "PRI-06" ], - "6-1-1305(3)(a)": [ - "HRS-06.1" + "3.3.57(1)8": [ + "PRI-06" ], - "6-1-1305(3)(b)": [ - "IAO-03.2" + "3.3.58(1)": [ + "PRI-06", + "PRI-06.1", + "PRI-06.2" ], - "6-1-1305(2)(a)": [ - "PRI-01.6", - "PRI-01.11" + "3.4.75(1)": [ + "PRI-06.1" ], - "6-1-1305(4)": [ - "PRI-01.6", - "PRI-01.11" + "3.3.58(5)": [ + "PRI-06.2", + "PRI-07.3" ], - "6-1-1308(5)": [ - "PRI-01.6", - "PRI-01.11" + "2.2.34(2)": [ + "PRI-06.4", + "PRI-07.5", + "PRI-17" ], - "6-1-1308(3)": [ - "PRI-01.11" + "2.2.35(2)": [ + "PRI-06.4" ], - "6-1-1308(4)": [ - "PRI-01.11" + "3.3.57(6)": [ + "PRI-06.4", + "PRI-17" ], - "6-1-1308(7)": [ - "PRI-01.11" + "3.3.59(2)": [ + "PRI-06.4", + "PRI-17" ], - "6-1-1308(1)(a)": [ - "PRI-02" + "2.2.35(1)": [ + "PRI-06.5" ], - "6-1-1308(1)(a)(III)": [ - "PRI-02" + "3.3.57(3)": [ + "PRI-06.8" ], - "6-1-1308(1)(a)(IV)": [ - "PRI-02" + "3.3.59(4)": [ + "PRI-06.8", + "PRI-07.5" ], - "6-1-1308(1)(a)(V)": [ - "PRI-02" + "3.5.79(1)2": [ + "PRI-07" ], - "6-1-1308(1)(b)": [ - "PRI-02", - "PRI-03.3" + "3.5.81(1)": [ + "PRI-07" ], - "6-1-1308(2)": [ - "PRI-02" + "3.5.81(1)1": [ + "PRI-07" ], - "6-1-1308(1)(a)(II)": [ - "PRI-02.1" + "3.5.81(1)2": [ + "PRI-07" ], - "6-1-1308(1)(c)(I)": [ - "PRI-03.5" + "3.5.81(1)3": [ + "PRI-07" ], - "6-1-1308(1)(c)(II)": [ - "PRI-03.5" + "3.5.81(2)": [ + "PRI-07" ], - "6-1-1306(1)(a)(II)": [ - "PRI-03.6" + "3.5.81(3)": [ + "PRI-07" ], - "6-1-1308(1)(a)(I)": [ - "PRI-05.7" + "3.5.81(4)": [ + "PRI-07" ], - "6-1-1306(1)": [ - "PRI-06", - "PRI-06.4", - "PRI-06.8", - "PRI-17" + "3.4.62(1)": [ + "PRI-07.2" ], - "6-1-1306(1)(b)": [ - "PRI-06" + "3.4.62(2)": [ + "PRI-07.2" ], - "6-1-1306(2)(c)": [ - "PRI-06" + "3.4.70(1)": [ + "PRI-14" ], - "6-1-1306(1)(c)": [ - "PRI-06.1" + "3.4.70(1)1": [ + "PRI-14" ], - "6-1-1306(3)(a)": [ - "PRI-06.3" + "3.4.70(1)2": [ + "PRI-14" ], - "6-1-1306(2)(a)": [ - "PRI-06.4" + "3.4.70(1)3": [ + "PRI-14" ], - "6-1-1306(2)(b)": [ - "PRI-06.4" + "3.4.70(1)4": [ + "PRI-14" ], - "6-1-1306(3)(b)": [ - "PRI-06.4" + "3.4.70(1)5": [ + "PRI-14" ], - "6-1-1306(3)(c)": [ - "PRI-06.4" + "3.4.70(1)6": [ + "PRI-14" ], - "6-1-1306(1)(d)": [ - "PRI-06.5" + "3.4.70(1)7": [ + "PRI-14" ], - "6-1-1306(1)(e)": [ - "PRI-06.6", - "PRI-06.7" + "3.4.70(1)8": [ + "PRI-14" ], - "6-1-1306(2)(d)": [ - "PRI-06.8" + "3.4.70(1)9": [ + "PRI-14" ], - "6-1-1306(1)(a)(I)": [ - "PRI-21" + "3.4.70(2)1": [ + "PRI-14" ], - "6-1-1306(1)(a)(I)(A)": [ - "PRI-21" + "3.4.70(2)2": [ + "PRI-14" ], - "6-1-1306(1)(a)(I)(B)": [ - "PRI-21" + "3.4.70(2)3": [ + "PRI-14" ], - "6-1-1306(1)(a)(I)(C)": [ - "PRI-21" + "3.4.70(4)": [ + "PRI-14" ], - "6-1-1306(1)(a)(III)": [ - "PRI-21" + "3.4.76(1)": [ + "PRI-14" ], - "6-1-1306(1)(a)(IV)(A)": [ - "PRI-21" + "3.4.76(1)1": [ + "PRI-14" ], - "6-1-1306(1)(a)(IV)(B)": [ - "PRI-21" + "3.4.76(1)2": [ + "PRI-14" ], - "6-1-1306(1)(a)(IV)(C)": [ - "PRI-21" + "3.4.76(1)3": [ + "PRI-14" ], - "6-1-1305(5)": [ - "TPM-05" + "3.4.76(1)4": [ + "PRI-14" ], - "6-1-1305(5)(a)": [ - "TPM-05" + "3.4.76(1)5": [ + "PRI-14" ], - "6-1-1305(5)(b)": [ - "TPM-05" + "3.4.76(1)6": [ + "PRI-14" ], - "6-1-1305(5)(c)": [ - "TPM-05" + "3.4.76(2)": [ + "PRI-14" ], - "6-1-1305(5)(d)": [ - "TPM-05" + "3.4.76(3)": [ + "PRI-14" ], - "6-1-1305(5)(d)(I)": [ - "TPM-05" + "3.4.76(4)": [ + "PRI-14" ], - "6-1-1305(5)(d)(II)(A)": [ - "TPM-05" + "3.5.79(2)": [ + "PRI-14", + "PRI-14.1" ], - "6-1-1305(5)(d)(II)(B)": [ - "TPM-05", - "TPM-08" - ] - }, - "usa-state-il-bipa-2008": { - "15(e)(1)": [ - "PRI-01.6", - "PRI-01.11" + "3.3.57(8)": [ + "PRI-17", + "PRI-17.3" ], - "15(e)(2)": [ - "PRI-01.6", - "PRI-01.11" + "3.3.58(6)": [ + "PRI-17" ], - "15(a)": [ - "PRI-02", - "PRI-05" + "3.3.59(1)": [ + "PRI-17" ], - "15(b)(1)": [ - "PRI-02" + "2.2.37(1)1": [ + "PRI-19" ], - "15(b)(2)": [ - "PRI-02" + "2.2.37(1)2": [ + "PRI-19" ], - "15(b)(3)": [ - "PRI-03" + "2.2.37(2)": [ + "PRI-19" ], - "15(d)": [ - "PRI-03" + "3.2.54(1)": [ + "PRI-19" ], - "15(d)(1)": [ - "PRI-03" + "3.2.54(2)": [ + "PRI-19" ], - "15(d)(2)": [ - "PRI-03" + "3.2.54(3)": [ + "PRI-19" ], - "15(d)(3)": [ - "PRI-03" + "3.4.67(1)": [ + "RSK-10" ], - "15(d)(4)": [ - "PRI-03" + "3.4.67(2)": [ + "RSK-10" ], - "15(c)": [ - "PRI-03.3" - ] - }, - "usa-state-il-ipa-2009": { - "15": [ - "CPL-01" + "3.4.67(3)": [ + "RSK-10" ], - "25": [ - "CPL-01" + "3.4.67(4)": [ + "RSK-10" ], - "35(a)": [ - "GOV-02" + "3.4.67(4)1": [ + "RSK-10" ], - "37(a)": [ - "GOV-02" + "3.4.67(4)2": [ + "RSK-10" ], - "35(c)": [ - "GOV-15" + "3.4.67(4)3": [ + "RSK-10" ], - "37(c)": [ - "GOV-15" + "3.4.67(4)4": [ + "RSK-10" ], - "35(b)": [ - "GOV-17" + "3.4.67(5)": [ + "RSK-10" ], - "37(b)": [ - "GOV-17" + "3.2.48(2)3": [ + "SAT-02" + ] + }, + "emea-deu-bsrit-2017": { + "3.1": [ + "GOV-01", + "RSK-01" ], - "35(a)(1)": [ - "CPL-01" + "4.1": [ + "GOV-01" ], - "37(a)(1)": [ - "CPL-01" + "4.8": [ + "GOV-01", + "GOV-02" ], - "35(a)(4)": [ - "DCH-03.2" + "1.1": [ + "GOV-01.1", + "PRM-01.1" ], - "37(a)(4)": [ - "DCH-03.2" + "1.2": [ + "GOV-01.1", + "PRM-01.1" ], - "35(a)(3)": [ - "HRS-03" + "1.2(a)": [ + "GOV-01.1", + "PRM-01.1" ], - "37(a)(3)": [ - "HRS-03" + "1.2(b)": [ + "GOV-01.1", + "PRM-01.1" ], - "10(a)(1)": [ - "PRI-01.7" + "1.2(c)": [ + "GOV-01.1", + "PRM-01.1" ], - "10(a)(2)": [ - "PRI-01.7" + "1.2(d)": [ + "GOV-01.1", + "PRM-01.1", + "SEA-01", + "SEA-01.4", + "SEA-02" ], - "10(a)(4)": [ - "PRI-01.7" + "1.2(e)": [ + "GOV-01.1", + "BCD-01", + "PRM-01.1" ], - "10(b)(1)": [ - "PRI-01.7", - "PRI-04", - "PRI-04.1" + "1.2(f)": [ + "GOV-01.1", + "PRM-01.1", + "TDA-01" ], - "10(c)": [ - "PRI-01.7" + "2.1": [ + "GOV-01.1", + "GOV-01.4", + "CPL-01" ], - "10(c)(1)": [ - "PRI-01.7" + "2.2": [ + "GOV-01.1", + "GOV-01.3" ], - "10(c)(2)": [ - "PRI-01.7" + "2.3": [ + "GOV-01.1", + "PRM-01", + "PRM-02", + "PRM-03" ], - "10(c)(5)": [ - "PRI-01.7" + "2.4": [ + "GOV-01.1" ], - "10(a)(3)": [ - "PRI-01.11" + "2.5": [ + "GOV-01.1", + "GOV-05" ], - "10(b)(2)": [ - "PRI-01.11" + "4.3": [ + "GOV-01.1" ], - "10(b)(3)": [ - "PRI-01.11" + "3.11": [ + "GOV-01.2" ], - "10(c)(3)": [ - "PRI-01.11" + "4.10": [ + "GOV-01.2", + "GOV-04.1" ], - "10(c)(4)": [ - "PRI-01.11" + "7.5": [ + "GOV-01.2", + "PRM-01" ], - "10(c)(6)": [ - "PRI-01.11" + "4.4": [ + "GOV-01.3", + "GOV-03" ], - "10(d)": [ - "PRI-01.11" + "4.2": [ + "GOV-02", + "GOV-03" ], - "35(a)(5)": [ - "PRI-02" + "4.5": [ + "GOV-04", + "GOV-04.1" ], - "37(a)(5)": [ - "PRI-02" + "4.6": [ + "GOV-04", + "GOV-04.1" ], - "35(a)(2)": [ - "SAT-03.3" + "4.9": [ + "GOV-05", + "SAT-01", + "SAT-01.1" ], - "37(a)(2)": [ - "SAT-03.3" - ] - }, - "usa-state-il-pipa-2006": { - "25": [ - "GOV-17" + "3.4": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "RSK-03.2", + "RSK-13" ], - "30": [ - "DCH-18" + "3.6": [ + "GOV-15", + "GOV-15.1", + "IAO-03" ], - "12(f)": [ - "GOV-17" + "5.1": [ + "GOV-15", + "GOV-15.1" ], - "40(b)(2)": [ - "DCH-08" + "5.2": [ + "GOV-15.2" ], - "40(b)": [ - "DCH-21" + "3.3": [ + "AST-01.1", + "AST-02", + "RSK-03.1", + "THR-09" ], - "40(b)(1)": [ - "DCH-21" + "8.2": [ + "AST-02" ], - "40(c)": [ - "DCH-21" + "10.1": [ + "BCD-01" ], - "12(g)": [ - "IRO-01" + "10.2": [ + "BCD-01" ], - "12(g)(i)": [ - "IRO-01" + "10.3": [ + "BCD-01" ], - "12(g)(ii)": [ - "IRO-01" + "10.5": [ + "BCD-01", + "BCD-04", + "BCD-08", + "BCD-09" ], - "12(g)(iii)": [ - "IRO-01" + "10.4": [ + "BCD-04" ], - "12(g)(iv)": [ - "IRO-01" + "8.7": [ + "BCD-11" ], - "12(g)(v)": [ - "IRO-01" + "8.8": [ + "CAP-01", + "CAP-03", + "CAP-04" ], - "10(a)": [ - "IRO-10" + "8.4": [ + "CHG-01" ], - "10(a)(1)": [ - "IRO-10" + "8.5": [ + "CHG-02" ], - "10(a)(1)(A)": [ - "IRO-10" + "3.7": [ + "CPL-03" ], - "10(a)(1)(B)": [ - "IRO-10" + "5.6": [ + "CPL-03", + "CPL-03.2" ], - "10(a)(1)(C)": [ - "IRO-10" + "6.8": [ + "CFG-02" ], - "10(a)(2)": [ - "IRO-10" + "8.6": [ + "CFG-02.8" ], - "10(b)": [ - "IRO-10" + "6.7": [ + "MON-01.8", + "MON-01.16" ], - "10(b-5)": [ - "IRO-10" + "5.5": [ + "MON-01.16", + "MON-16" ], - "10(c)": [ - "IRO-10" + "6.3": [ + "MON-03" ], - "10(c)(1)": [ - "IRO-10" + "5.4": [ + "MON-11.3", + "IRO-03" ], - "10(c)(2)": [ - "IRO-10" + "7.13": [ + "DCH-02", + "TDA-01.1" ], - "10(c)(3)": [ - "IRO-10" + "7.14": [ + "DCH-02", + "TDA-01.1" ], - "10(d)": [ - "IRO-10" + "6.1": [ + "IAC-01" ], - "10(e)(2)": [ - "IRO-10" + "6.2": [ + "IAC-01" ], - "10(e)(2)(A)": [ - "IRO-10" + "6.4": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2" ], - "10(e)(2)(B)": [ - "IRO-10" + "6.5": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2" ], - "10(e)(2)(C)": [ - "IRO-10" + "6.6": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2" ], - "12(a)": [ - "IRO-10" + "4.7": [ + "IRO-01", + "IRO-02", + "IRO-02.4" ], - "12(a)(1)": [ - "IRO-10" + "7.11": [ + "IAO-01", + "IAO-02", + "IAO-02.2", + "IAO-06", + "IAO-07" ], - "12(a)(1)(i)": [ - "IRO-10" + "3.8": [ + "IAO-05" ], - "12(a)(1)(ii)": [ - "IRO-10" + "7.4": [ + "PRM-01" ], - "12(a)(1)(iii)": [ - "IRO-10" + "8.3": [ + "PRM-01", + "SEA-07.1" ], - "12(a)(2)": [ - "IRO-10" + "7.1": [ + "PRM-04", + "PRM-07" ], - "12(a-5)": [ - "IRO-10" + "7.2": [ + "PRM-04", + "PRM-07" ], - "12(b)": [ - "IRO-10" + "7.3": [ + "PRM-04", + "PRM-07" ], - "12(b)(1)": [ - "IRO-10" + "7.6": [ + "PRM-05", + "PRM-06", + "TDA-06" ], - "12(b)(2)": [ - "IRO-10" + "3.2": [ + "RSK-01" ], - "12(b)(3)": [ - "IRO-10" + "3.5": [ + "RSK-01" ], - "12(b)(3)(i)": [ - "IRO-10" + "3.9": [ + "RSK-04", + "RSK-06.3" ], - "12(b)(3)(ii)": [ - "IRO-10" + "11.1": [ + "RSK-06", + "OPS-03" ], - "12(b)(3)(iii)": [ - "IRO-10" + "8.1": [ + "OPS-03" ], - "12(c)": [ - "IRO-10" + "11.2": [ + "OPS-03" ], - "12(d)": [ - "IRO-10" + "11.3": [ + "OPS-03" ], - "12(e)": [ - "IRO-10" + "11.4": [ + "OPS-03" ], - "12(e)(A)": [ - "IRO-10" + "11.5": [ + "OPS-03" ], - "12(e)(B)": [ - "IRO-10" + "11.6": [ + "OPS-03" ], - "12(e)(C)": [ - "IRO-10" + "11.7": [ + "OPS-03" ], - "12(e)(D)": [ - "IRO-10" + "11.8": [ + "OPS-03" ], - "45(b)": [ - "IAO-03.2", - "PRI-07.1" + "7.7": [ + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-06", + "TDA-09" ], - "45(a)": [ - "PRI-01.6", - "PRI-01.11" - ] - }, - "usa-state-ma-201-cmr-17-2008": { - "17.03(1)": [ - "GOV-01", - "GOV-02" + "7.8": [ + "TDA-01", + "TDA-01.1", + "TDA-06", + "TDA-09" ], - "17.03(1)(a)": [ - "GOV-01" + "7.9": [ + "TDA-01", + "TDA-01.1", + "TDA-06", + "TDA-09", + "TDA-20" ], - "17.03(1)(b)": [ - "GOV-01" + "7.10": [ + "TDA-01", + "TDA-01.1", + "TDA-06", + "TDA-09" ], - "17.03(1)(c)": [ - "GOV-01" + "7.12": [ + "TDA-01.1", + "TDA-02.9", + "TDA-09" ], - "17.03(1)(d)": [ - "GOV-01" + "9.1": [ + "TPM-01" ], - "17.03(2)": [ - "GOV-01" + "9.3": [ + "TPM-03.1", + "TPM-08" ], - "17.03(2)(c)": [ - "GOV-02" + "9.2": [ + "TPM-04", + "TPM-04.1" ], - "17.04": [ - "GOV-02" + "9.5": [ + "TPM-04.1" ], - "17.03(2)(a)": [ - "GOV-04" + "9.4": [ + "TPM-05", + "TPM-05.2" ], - "17.03(2)(b)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "RSK-01.1", - "RSK-02", - "RSK-02.1", - "RSK-03", - "RSK-03.1", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", + "3.10": [ + "THR-01", "THR-03", "THR-09", "THR-10" ], - "17.03(2)(b)3": [ - "CPL-02", - "MON-01.8" + "5.3": [ + "THR-01", + "THR-03", + "THR-09", + "THR-10" + ] + }, + "emea-deu-c5-2020": { + "OIS-01": [ + "GOV-01", + "GOV-01.1", + "GOV-01.4", + "GOV-09" ], - "17.03(2)(h)": [ - "CPL-02" + "OIS-01-BP1": [ + "GOV-01" ], - "17.03(2)(i)": [ - "CPL-02" + "OIS-01-DOAR": [ + "GOV-01" ], - "17.04(4)": [ - "MON-01.8" + "SPN-01": [ + "GOV-01.2" ], - "17.04(3)": [ - "CRY-01", - "CRY-03" + "OIS-01-BP3": [ + "GOV-01.3", + "CPL-03" ], - "17.04(5)": [ - "CRY-01", - "CRY-05" + "SA-02-BP2": [ + "GOV-01.3", + "GOV-03" ], - "17.03(2)(g)": [ - "DCH-01.2", - "PES-03" + "RB-22-DOAR": [ + "GOV-01.4", + "CFG-02" ], - "17.04(6)": [ - "END-02" + "OIS-02": [ + "GOV-02", + "GOV-09" ], - "17.03(2)(b)2": [ - "HRS-01", - "HRS-01.1", - "HRS-03", - "HRS-03.1" + "OIS-06": [ + "GOV-02", + "RSK-01" ], - "17.03(2)(e)": [ - "HRS-01.1", - "HRS-09" + "SA-01": [ + "GOV-02" ], - "17.03(2)(d)": [ - "HRS-07" + "SA-01-BP1": [ + "GOV-02" ], - "17.04(1)": [ - "IAC-01", - "IAC-01.2" + "SA-01-BP2": [ + "GOV-02" ], - "17.04(2)": [ - "IAC-01" + "SA-01-BP3": [ + "GOV-02", + "HRS-03" ], - "17.04(2)(a)": [ - "IAC-08", - "IAC-21" + "SA-01-BP4": [ + "GOV-02", + "GOV-04.1", + "GOV-14" ], - "17.04(1)(b)": [ - "IAC-10" + "SA-01-BP5": [ + "GOV-02", + "SEA-01.4" ], - "17.04(2)(b)": [ - "IAC-10", - "IAC-10.8", - "IAC-15" + "SA-01-BP6": [ + "GOV-02", + "CPL-01" ], - "17.04(1)(c)": [ - "IAC-10.5" + "MDM-01": [ + "GOV-02", + "MDM-01" ], - "17.04(1)(a)": [ - "IAC-15" + "SA-03": [ + "GOV-02.1" ], - "17.04(1)(d)": [ - "IAC-15" + "SA-02": [ + "GOV-03" ], - "17.04(1)(e)": [ - "IAC-22" + "SA-02-BP1": [ + "GOV-03" ], - "17.03(2)(j)": [ - "IRO-09.3", - "IRO-13" + "SA-02-BP3": [ + "GOV-03", + "PRM-02.1" ], - "17.03(2)(b)1": [ - "SAT-02" + "OIS-01-BP2": [ + "GOV-05", + "CPL-03" ], - "17.04(8)": [ - "SAT-02", - "SAT-03.3" + "OIS-05": [ + "GOV-06", + "THR-03" ], - "17.03(2)(f)": [ - "TPM-01" + "DLL-01-BP1": [ + "GOV-09", + "GOV-15.1", + "SEA-01", + "TPM-05" ], - "17.03(2)(f)1": [ - "TPM-04.1" + "UP-01-BP2": [ + "GOV-15", + "CLD-01", + "IAO-03", + "SEA-01", + "SEA-01.4", + "TDA-06" ], - "17.03(2)(f)2": [ - "TPM-05" + "AM-03": [ + "AST-01" ], - "17.04(7)": [ - "VPM-04.1", - "VPM-05" - ] - }, - "usa-state-nv-regulation-5-2024": { - "5.260.1": [ - "GOV-01", - "PRI-01", - "PRI-01.6" + "AM-02": [ + "AST-01.2", + "AST-03", + "DCH-02" ], - "5.260.4(b)": [ - "GOV-01.2", - "IRO-13" + "AM-01": [ + "AST-02", + "AST-02.1", + "AST-02.9" ], - "5.260.4(c)": [ - "GOV-01.2", - "IRO-10" + "RB-12": [ + "AST-02", + "AST-02.9", + "BCD-02" ], - "5.260.6": [ - "GOV-02", - "OPS-01.1" + "AM-01-DOAR": [ + "AST-02.9" ], - "5.260.5(a)": [ - "GOV-04" + "KOS-06": [ + "AST-04" ], - "5.260.4": [ - "GOV-16" + "AM-04": [ + "AST-09", + "AST-10", + "HRS-05" ], - "5.260.5(b)": [ - "CPL-02.1", - "CPL-02.2", - "DCH-18" + "UP-01-BP4": [ + "BCD-01", + "IRO-01" ], - "5.260.5(c)": [ - "CPL-03", - "DCH-18", - "TPM-05.8" + "RB-06": [ + "BCD-01", + "BCD-11", + "DCH-18" ], - "5.260.3": [ - "CPL-03.1", - "RSK-04", - "RSK-04.1", - "RSK-07" + "BCM-01": [ + "BCD-01" ], - "5.260.4(a)": [ - "IRO-10" + "BCM-02": [ + "BCD-01" ], - "5.260.2": [ - "SEA-02.1" - ] - }, - "usa-state-nv-sb220-2019": { - "2.3": [ - "PRI-05.4" + "BCM-02-BP1": [ + "BCD-01" ], - "2.1": [ - "PRI-06" + "BCM-02-BP2": [ + "BCD-01" ], - "2.2": [ - "PRI-06" + "BCM-02-BP3": [ + "BCD-01" ], - "2.4": [ - "PRI-06.4" - ] - }, - "usa-state-ny-dfs-23-nycrr500-2023-amd2": { - "500.2(a)": [ - "GOV-01" + "BCM-02-BP4": [ + "BCD-01", + "BCD-02" ], - "500.2(b)": [ - "GOV-01" + "BCM-02-BP5": [ + "BCD-01", + "RSK-08" ], - "500.2(b)(1)": [ - "GOV-01", - "RSK-01", - "RSK-03", - "RSK-04" + "BCM-02-BP6": [ + "BCD-01", + "BCD-01.4" ], - "500.2(b)(2)": [ - "GOV-01", - "GOV-02", - "SEA-01", - "SEA-02", - "SEA-03", - "OPS-01.1" + "BCM-02-BP7": [ + "BCD-01", + "BCD-02.3" ], - "500.2(b)(3)": [ - "GOV-01", - "MON-01" + "BCM-02-BP8": [ + "BCD-01", + "BCD-01.4" ], - "500.2(b)(4)": [ - "GOV-01", - "IRO-01" + "BCM-02-BP9": [ + "BCD-01", + "BCD-01.4" ], - "500.2(b)(5)": [ - "GOV-01", + "BCM-02-BP10": [ "BCD-01" ], - "500.2(b)(6)": [ - "GOV-01", - "CPL-01" + "BCM-03": [ + "BCD-01" ], - "500.2(d)": [ - "GOV-01", - "CPL-01", - "SEA-02.2", - "TPM-05", - "TPM-05.4" + "BCM-03-BP1": [ + "BCD-01" ], - "500.2(e)": [ - "GOV-01", - "CPL-01", - "CPL-05", - "CPL-05.2" + "BCM-03-BP2": [ + "BCD-01" ], - "500.3(a)": [ - "GOV-01", - "GOV-02" + "BCM-03-BP3": [ + "BCD-01" ], - "500.4(b)": [ - "GOV-01.1", - "GOV-01.2", - "GOV-04.1", - "GOV-04.2", - "GOV-16", - "GOV-16.1", - "GOV-16.2" + "BCM-03-BP4": [ + "BCD-01" ], - "500.4(b)(1)": [ - "GOV-01.1", - "TPM-05.6" + "BCM-03-BP5": [ + "BCD-01" ], - "500.4(b)(2)": [ - "GOV-01.1", - "TPM-05.6" + "BCM-03-BP6": [ + "BCD-01" ], - "500.4(b)(3)": [ - "GOV-01.1", - "GOV-16", - "GOV-16.1", - "GOV-16.2", - "TPM-05.6" + "BCM-03-BP7": [ + "BCD-01" ], - "500.4(b)(4)": [ - "GOV-01.1", - "TPM-05.6" + "BCM-03-BP8": [ + "BCD-01" ], - "500.4(b)(5)": [ - "GOV-01.1", - "GOV-16", - "GOV-16.1", - "GOV-16.2", - "TPM-05.6" + "BCM-05": [ + "BCD-02.4", + "TPM-05" ], - "500.4(b)(6)": [ - "GOV-01.1", - "GOV-04.1", - "CPL-01.1", - "RSK-06", - "TPM-09", - "VPM-02" + "PS-03-BP6": [ + "BCD-04", + "PES-08" ], - "500.4(d)": [ - "GOV-01.1" + "BCM-04": [ + "BCD-04", + "BCD-06", + "RSK-08" ], - "500.4(d)(1)": [ - "GOV-01.1" + "BCM-04-DOAR": [ + "BCD-04" ], - "500.4(d)(2)": [ - "GOV-01.1" + "BCM-05-DOAR": [ + "BCD-04" ], - "500.4(d)(3)": [ - "GOV-01.1" + "RB-07": [ + "BCD-11", + "BCD-11.1" ], - "500.4(d)(4)": [ - "GOV-01.1", - "PRM-02", - "PRM-03" + "RB-09": [ + "BCD-11.2" ], - "500.4(c)": [ - "GOV-01.2" + "RB-06-DOAR": [ + "BCD-11.4" ], - "500.3": [ - "GOV-02", - "OPS-01.1" + "RB-08": [ + "BCD-11.5" ], - "500.3(b)": [ - "GOV-02", - "DCH-01" + "RB-01": [ + "CAP-01", + "CAP-03" ], - "500.3(c)": [ - "GOV-02", - "AST-01" + "RB-01-DOAR": [ + "CAP-03" ], - "500.3(d)": [ - "GOV-02", - "IAC-01" + "RB-02": [ + "CAP-04", + "CAP-05" ], - "500.3(e)": [ - "GOV-02", - "BCD-01" + "BEI-03": [ + "CHG-01" ], - "500.3(f)": [ - "GOV-02", - "CAP-01" + "BEI-03-BP1": [ + "CHG-01" ], - "500.3(g)": [ - "GOV-02", - "NET-01" + "BEI-03-BP2": [ + "CHG-01", + "CHG-05" ], - "500.3(h)": [ - "GOV-02", - "SAT-01" + "BEI-05": [ + "CHG-01" ], - "500.3(i)": [ - "GOV-02", - "TDA-01" + "BEI-06": [ + "CHG-01", + "CHG-03", + "RSK-04" ], - "500.3(j)": [ - "GOV-02", - "PES-01" + "BEI-08": [ + "CHG-01", + "CHG-02" ], - "500.3(k)": [ - "GOV-02", - "PRI-01" + "BEI-09-DOAR": [ + "CHG-02" ], - "500.3(l)": [ - "GOV-02", - "TPM-01" + "BEI-12": [ + "CHG-02.1", + "HRS-11", + "IAC-08" ], - "500.3(m)": [ - "GOV-02", - "RSK-01" + "BEI-03-BP3": [ + "CHG-02.2" ], - "500.3(n)": [ - "GOV-02", - "IRO-01" + "BEI-03-BP4": [ + "CHG-02.2" ], - "500.3(o)": [ - "GOV-02", - "VPM-01" + "BEI-07": [ + "CHG-02.2" ], - "500.5": [ - "GOV-02" + "BEI-09": [ + "CHG-02.2", + "IAC-28.1" ], - "500.7(b)": [ - "GOV-02", - "IAC-01", - "IAC-10", - "IAC-10.1" + "BEI-04": [ + "CHG-03" ], - "500.8(a)": [ - "GOV-02", - "OPS-01.1", - "TDA-01", - "TDA-06", - "TDA-06.5", - "TDA-09", - "TDA-09.6" + "BEI-10": [ + "CHG-07", + "CHG-07.1" ], - "500.11(a)": [ - "GOV-02", + "UP-01": [ + "CLD-01", + "TDA-04", "TPM-01" ], - "500.13(a)": [ - "GOV-02", - "AST-01", - "AST-02" - ], - "500.14(a)(1)": [ - "GOV-02", - "MON-16", - "SAT-03.2" - ], - "500.15(a)": [ - "GOV-02", - "CRY-01", - "CRY-03", - "CRY-05" + "UP-01-BP1": [ + "CLD-01", + "TPM-03.2", + "TPM-05", + "TPM-05.5" ], - "500.9(b)(3)": [ - "GOV-02.1", - "RSK-02", - "RSK-02.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-06.2" + "RB-05": [ + "CLD-01", + "CFG-02", + "END-04" ], - "500.12(b)": [ - "GOV-02.1", - "RSK-06", - "RSK-06.2" + "PI-02": [ + "CLD-01.2", + "CLD-07", + "CPL-01" ], - "500.15(b)": [ - "GOV-02.1", - "CRY-01", - "CRY-01.1", - "RSK-06.2" + "PI-05": [ + "CLD-01.2", + "DCH-09" ], - "500.8(b)": [ - "GOV-03" + "PI-01": [ + "CLD-04", + "CLD-07", + "DCH-02" ], - "500.4(a)": [ - "GOV-04" + "PI-04": [ + "CLD-04", + "NET-12" ], - "500.9(b)(1)": [ - "GOV-16", - "GOV-16.1", - "GOV-16.2", - "RSK-01.1", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-03", - "RSK-03.1", - "RSK-04", - "THR-03", - "THR-09", - "THR-10" + "RB-23": [ + "CLD-06", + "DCH-01" ], - "500.9(b)(2)": [ - "GOV-16", - "GOV-16.1", - "GOV-16.2", - "RSK-04" + "UP-01-BP5": [ + "CLD-06.1", + "HRS-03", + "IAO-03", + "TPM-05.4" ], - "500.17(a)(1)": [ - "GOV-17", - "IRO-10", - "IRO-10.2", - "IRO-14" + "UP-01-BP6": [ + "CLD-06.1", + "TPM-05", + "TPM-05.2", + "TPM-05.4" ], - "500.17(a)(2)": [ - "GOV-17", - "CPL-01", - "CPL-05", - "CPL-05.2" + "OIS-03": [ + "CLD-06.1", + "TPM-05", + "TPM-05.4", + "TPM-10" ], - "500.13(a)(1)": [ - "AST-02" + "RB-10": [ + "CLD-06.2", + "MON-01", + "MON-02", + "MON-02.2", + "MON-03" ], - "500.13(a)(1)(i)": [ - "AST-02" + "PI-03": [ + "CLD-07" ], - "500.13(a)(1)(ii)": [ - "AST-02" + "UP-02": [ + "CLD-09", + "DCH-19" ], - "500.13(a)(1)(iii)": [ - "AST-02" + "RB-03": [ + "CLD-09", + "DCH-19" ], - "500.13(a)(1)(iv)": [ - "AST-02" + "DLL-01-BP2": [ + "CPL-01", + "TPM-05", + "TPM-05.2" ], - "500.13(a)(1)(v)": [ - "AST-02" + "COM-01": [ + "CPL-01" ], - "500.13(a)(2)": [ - "AST-02" + "SPN-02": [ + "CPL-01.1", + "CPL-02", + "CPL-02.2" ], - "500.13(b)": [ - "AST-09", - "DCH-18" + "UP-04": [ + "CPL-01.3", + "TPM-05.8" ], - "500.16(a)(2)": [ - "BCD-01" + "SPN-03-DOAR": [ + "CPL-01.3" ], - "500.16(a)(2)(i)": [ - "BCD-01", - "BCD-02" + "COM-02-DOAR": [ + "CPL-01.3" ], - "500.16(a)(2)(ii)": [ - "BCD-01", - "BCD-01.5", - "HRS-02", - "HRS-03" + "COM-03-DOAR": [ + "CPL-01.3" ], - "500.16(a)(2)(iii)": [ - "BCD-01", - "BCD-01.6" + "RB-05-DOAR": [ + "CPL-02", + "CPL-02.2" ], - "500.16(a)(2)(iv)": [ - "BCD-01", - "BCD-02.2" + "COM-02": [ + "CPL-02", + "CPL-02.2" ], - "500.16(a)(2)(v)": [ - "BCD-01", - "BCD-01.4", - "BCD-11" + "SPN-03": [ + "CPL-02.1" ], - "500.16(a)(2)(vi)": [ - "BCD-01", - "BCD-02" + "SPN-02-DOAR": [ + "CPL-02.2" ], - "500.16(b)": [ - "BCD-01", - "IRO-04" + "COM-02-BP1": [ + "CPL-02.2" ], - "500.16(c)": [ - "BCD-03" + "COM-02-BP2": [ + "CPL-02.2" ], - "500.16(d)(1)": [ - "BCD-04", - "IRO-06" + "COM-02-BP3": [ + "CPL-02.2" ], - "500.16(d)(2)": [ - "BCD-04" + "COM-03": [ + "CPL-02.2" ], - "500.16(e)": [ - "BCD-11", - "BCD-11.1", - "BCD-11.4" + "RB-22": [ + "CFG-02" ], - "500.17(b)(1)": [ - "CPL-01" + "IDM-11": [ + "CFG-02" ], - "500.17(b)(1)(i)": [ - "CPL-01" + "IDM-11-BP1": [ + "CFG-02" ], - "500.17(b)(1)(i)(a)": [ - "CPL-01" + "IDM-11-BP2": [ + "CFG-02" ], - "500.17(b)(1)(i)(b)": [ - "CPL-01" + "IDM-11-BP3": [ + "CFG-02" ], - "500.17(b)(1)(ii)": [ - "CPL-01" + "IDM-11-BP4": [ + "CFG-02" ], - "500.17(b)(1)(ii)(a)": [ - "CPL-01" + "IDM-11-BP5": [ + "CFG-02" ], - "500.17(b)(1)(ii)(b)": [ - "CPL-01" + "IDM-11-DOAR": [ + "CFG-02" ], - "500.17(b)(1)(ii)(c)": [ - "CPL-01" + "IDM-11-DOAR-BP1": [ + "CFG-02" ], - "500.17(b)(2)": [ - "CPL-01" + "IDM-11-DOAR-BP2": [ + "CFG-02" ], - "500.17(b)(3)": [ - "CPL-01" + "IDM-11-DOAR-BP3": [ + "CFG-02" ], - "500.17(c)": [ - "CPL-01", - "IRO-10" + "IDM-11-DOAR-BP4": [ + "CFG-02" ], - "500.2(c)": [ - "CPL-03", - "CPL-03.1" + "IDM-11-DOAR-BP5": [ + "CFG-02" ], - "500.6(a)": [ + "IDM-11-DOAR-BP6": [ "CFG-02" ], - "500.7(a)(5)": [ - "CFG-02", - "IAC-20.3" + "IDM-11-DOAR-BP7": [ + "CFG-02" ], - "500.6(a)(1)": [ - "MON-01", - "MON-03" + "RB-13": [ + "MON-02", + "MON-10" ], - "500.6(a)(2)": [ - "MON-01", + "RB-16-DOAR": [ "MON-02", - "MON-03" + "MON-05.1" ], - "500.14(b)(2)": [ - "MON-01.2", - "MON-02" + "SIM-05": [ + "MON-02", + "MON-02.2" ], - "500.7(c)": [ - "MON-01.15", - "MON-03", - "MON-03.3" + "RB-14": [ + "MON-02.7", + "MON-03.2" ], - "500.6(b)": [ - "MON-10", - "DCH-18", - "IAC-01.1" + "RB-15": [ + "MON-02.8", + "IAC-08" ], - "500.11(b)(2)": [ - "CRY-01", - "TPM-05", - "TPM-05.2" + "RB-16": [ + "MON-03.2", + "MON-06", + "MON-08" ], - "500.18": [ - "DCH-01", - "DCH-01.2" + "KRY-01": [ + "CRY-01" ], - "500.14(a)(2)": [ - "END-02", - "END-04", - "END-08", - "NET-01", - "NET-18" + "KRY-01-BP1": [ + "CRY-01" ], - "500.14(b)(1)": [ - "END-02", - "END-06.2", - "END-07" + "KRY-01-BP2": [ + "CRY-01" ], - "500.10(a)(1)": [ - "HRS-01", - "HRS-03", - "HRS-03.2", - "HRS-04.1", - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "KRY-01-BP3": [ + "CRY-01" ], - "500.10(a)(2)": [ - "HRS-03.1", - "HRS-04.2", - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6", - "THR-01" + "KRY-01-BP4": [ + "CRY-01" ], - "500.7(a)(6)": [ - "HRS-08", - "HRS-09" + "KRY-02": [ + "CRY-01", + "CRY-03", + "CRY-05" ], - "500.7(a)(1)": [ - "IAC-01", - "IAC-08", - "IAC-16", - "IAC-17", - "IAC-21" + "KRY-02-DOAR": [ + "CRY-03" ], - "500.11(b)(1)": [ - "IAC-06", - "TPM-05", - "TPM-05.2", - "TPM-05.3" + "KRY-03": [ + "CRY-05", + "CRY-09" ], - "500.12(a)": [ - "IAC-06" + "KRY-04": [ + "CRY-09" ], - "500.12(a)(1)": [ - "IAC-06" + "KRY-04-BP1": [ + "CRY-09" ], - "500.12(a)(2)": [ - "IAC-06" + "KRY-04-BP3": [ + "CRY-09" ], - "500.12(a)(3)": [ - "IAC-06.1", - "IAC-06.3" + "KRY-04-BP4": [ + "CRY-09" ], - "500.7(c)(2)": [ - "IAC-10.1", - "IAC-10.4" + "KRY-04-BP5": [ + "CRY-09" ], - "500.7(a)(4)": [ - "IAC-15.3", - "IAC-15.7", - "IAC-16.1" + "KRY-04-BP6": [ + "CRY-09" ], - "500.7(a)(3)": [ - "IAC-16" + "KRY-04-BP7": [ + "CRY-09" ], - "500.7(c)(1)": [ - "IAC-16" + "KRY-04-BP8": [ + "CRY-09" ], - "500.7(a)(2)": [ - "IAC-21" + "AM-07": [ + "DCH-01", + "DCH-01.2" ], - "500.16(a)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "AM-06": [ + "DCH-01.1", + "DCH-02", + "DCH-04" ], - "500.16(a)(1)": [ - "IRO-04" + "RB-11": [ + "DCH-01.2" ], - "500.16(a)(1)(i)": [ - "IRO-04" + "AM-05": [ + "DCH-02" ], - "500.16(a)(1)(ii)": [ - "IRO-04" + "SIM-02": [ + "DCH-02", + "DCH-11" ], - "500.16(a)(1)(iii)": [ - "IRO-04" + "AM-08": [ + "DCH-07", + "DCH-14.2" ], - "500.16(a)(1)(iv)": [ - "IRO-04" + "HR-02": [ + "HRS-01", + "HRS-05", + "HRS-05.7", + "HRS-06" ], - "500.16(a)(1)(v)": [ - "IRO-04" + "KOS-08-DOAR": [ + "HRS-01" ], - "500.16(a)(1)(vi)": [ - "IRO-04" + "HR-01-DOAR": [ + "HRS-02", + "HRS-04.1" ], - "500.16(a)(1)(vii)": [ - "IRO-04" + "OIS-03-BP1": [ + "HRS-03" ], - "500.16(a)(1)(viii)": [ - "IRO-04" + "OIS-03-BP2": [ + "HRS-03" ], - "500.16(a)(1)(ix)": [ - "IRO-04.2" + "OIS-03-BP3": [ + "HRS-03" ], - "500.17(c)(1)": [ - "IRO-10" + "HR-01": [ + "HRS-04", + "HRS-04.1" ], - "500.17(c)(2)": [ - "IRO-10" + "HR-01-BP1": [ + "HRS-04" ], - "500.9(a)": [ - "RSK-01", - "RSK-04", - "RSK-04.1", - "RSK-07" + "HR-01-BP2": [ + "HRS-04" ], - "500.9(b)": [ - "RSK-01", - "RSK-04" + "HR-01-BP3": [ + "HRS-04" ], - "500.1": [ - "SEA-02.1" + "HR-01-BP4": [ + "HRS-04" ], - "500.14(a)(3)": [ - "SAT-01" + "HR-05": [ + "HRS-05", + "HRS-08", + "HRS-09" ], - "500.10(a)(3)": [ - "SAT-03.7", - "THR-01" + "IDM-07-DOAR": [ + "HRS-06.1" ], - "500.4(a)(1)": [ - "TPM-01", - "TPM-05.1", - "TPM-05.4" + "KOS-08": [ + "HRS-06.1" ], - "500.4(a)(2)": [ - "TPM-01", - "TPM-05.1", - "TPM-05.4" + "HR-04": [ + "HRS-07" ], - "500.4(a)(3)": [ - "TPM-01", - "TPM-05.1", - "TPM-05.4" + "IDM-04": [ + "HRS-08", + "IAC-07" ], - "500.11(a)(1)": [ - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-05.2" + "OIS-04": [ + "HRS-11" ], - "500.11(b)": [ - "TPM-01", - "TPM-05", - "TPM-05.2" + "OIS-04-BP1": [ + "HRS-11" ], - "500.11(a)(4)": [ - "TPM-02", - "TPM-05.5", - "TPM-08" + "OIS-04-BP2": [ + "HRS-11" ], - "500.11(a)(3)": [ - "TPM-04.1", - "TPM-05.5", - "TPM-05.6", - "TPM-08" + "OIS-04-BP3": [ + "HRS-11" ], - "500.10(b)": [ - "TPM-05", - "TPM-05.4", - "TPM-06" + "OIS-04-DOAR": [ + "HRS-11", + "RSK-06.2" ], - "500.11(a)(2)": [ - "TPM-05", - "TPM-05.2" + "IDM-01-BP2": [ + "HRS-11" ], - "500.11(b)(3)": [ - "TPM-05", - "TPM-05.1", - "TPM-05.2" + "IDM-01-BP3": [ + "HRS-11", + "IAC-08" ], - "500.11(b)(4)": [ - "TPM-05", - "TPM-05.2", - "TPM-05.6" + "IDM-01": [ + "IAC-01", + "IAC-08" ], - "500.5(a)(1)": [ - "VPM-01.1", - "VPM-07" + "IDM-03": [ + "IAC-01" ], - "500.5(c)": [ - "VPM-02", - "VPM-03", - "VPM-03.1" + "IDM-02": [ + "IAC-01.2", + "IAC-15" ], - "500.5(b)": [ - "VPM-04" + "IDM-03-BP2": [ + "IAC-01.2", + "IAC-15.1", + "IAC-21" ], - "500.5(a)(2)": [ - "VPM-06" - ] - }, - "usa-state-ny-shield-act-2019": { - "899-bb.2(b)(ii)": [ - "GOV-01" + "IDM-08-BP2": [ + "IAC-01.2", + "IAC-15.1" ], - "899-bb.2(c)": [ - "GOV-01" + "RB-15-DOAR": [ + "IAC-06", + "IAC-06.3" ], - "899-bb.2(b)(ii)(A)(6)": [ - "GOV-03" + "IDM-08-BP3": [ + "IAC-06" ], - "899-bb.2(b)(ii)(A)(1)": [ - "GOV-04" + "IDM-01-BP1": [ + "IAC-07", + "IAC-28.1" ], - "899-bb.2(b)(ii)(B)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5" + "IDM-01-BP5": [ + "IAC-07" ], - "899-bb.2(b)(ii)(B)(4)": [ - "GOV-15.3" + "IDM-03-BP3": [ + "IAC-07", + "IAC-28.1" ], - "899-bb.2(b)(ii)(A)(3)": [ - "CPL-02" + "IDM-03-BP4": [ + "IAC-07", + "IAC-21", + "IAC-28.1" ], - "899-bb.2(b)(ii)(B)(3)": [ - "MON-01.8" + "IDM-05": [ + "IAC-07", + "IAC-17" ], - "899-bb.2(b)(ii)(C)(2)": [ - "MON-01.8", - "PES-05" + "IDM-07": [ + "IAC-10.5" ], - "899-bb.2(b)(ii)(C)": [ - "DCH-01", - "PES-01" + "IDM-08": [ + "IAC-10.5" ], - "899-bb.2(b)(ii)(C)(3)": [ - "DCH-01.2" + "IDM-09": [ + "IAC-15.9", + "IAC-28.1" ], - "899-bb.2(b)(ii)(C)(1)": [ - "DCH-06", - "DCH-08", - "DCH-21" + "IDM-06": [ + "IAC-16", + "IAC-28.1" ], - "3.2": [ - "IRO-10" + "IDM-01-BP4": [ + "IAC-17" ], - "3.2(a)": [ - "IRO-10" + "IDM-05-DOAR": [ + "IAC-17" ], - "3.2(b)": [ - "IRO-10" + "IDM-09-DOAR": [ + "IAC-17" ], - "3.3": [ - "IRO-10" + "IDM-12": [ + "IAC-20.3", + "IAC-21" ], - "3.5": [ - "IRO-10" + "IDM-03-BP1": [ + "IAC-21" ], - "3.5(a)": [ - "IRO-10" + "IDM-10": [ + "IAC-21" ], - "3.5(b)": [ - "IRO-10" + "IDM-13": [ + "IAC-21", + "TDA-20" ], - "3.5(c)": [ - "IRO-10" + "IDM-08-BP1": [ + "IAC-28" ], - "3.5(d)": [ - "IRO-10" + "IDM-01-BP6": [ + "IAC-28.1" ], - "3.5(d)(1)": [ - "IRO-10" + "SIM-01": [ + "IRO-01" ], - "3.5(d)(2)": [ - "IRO-10" + "SIM-07": [ + "IRO-01", + "IRO-02.4", + "IRO-09" ], - "3.5(d)(3)": [ - "IRO-10" + "SIM-03": [ + "IRO-02.4", + "IRO-04" ], - "3.8(a)": [ - "IRO-10" + "SIM-01-DOAR": [ + "IRO-08" ], - "3.8(b)": [ - "IRO-10" + "RB-20": [ + "IRO-10", + "TPM-05.1" ], - "3.9": [ - "IRO-10" + "SIM-04": [ + "IRO-10", + "IRO-13" ], - "5.2": [ - "IRO-10" + "UP-01-BP3": [ + "IAO-03" ], - "5.2(a)": [ - "IRO-10" + "BEI-02": [ + "IAO-03.2", + "TDA-06" ], - "5.2(b)": [ - "IRO-10" + "BEI-02-BP1": [ + "IAO-03.2" ], - "5.3": [ - "IRO-10" + "BEI-02-BP2": [ + "IAO-03.2" ], - "5.6": [ - "IRO-10" + "BEI-02-BP3": [ + "IAO-03.2" ], - "5.7(a)": [ - "IRO-10" + "BEI-02-BP4": [ + "IAO-03.2" ], - "5.7(b)": [ - "IRO-10" + "PS-05": [ + "MNT-01" ], - "5.9": [ - "IRO-10" + "MDM-01-BP2": [ + "MDM-01" ], - "5.10": [ - "IRO-10" + "MDM-01-BP3": [ + "MDM-01" ], - "899-bb.2(b)(ii)(B)(1)": [ - "NET-01", - "TDA-01" + "MDM-01-BP5": [ + "MDM-01" ], - "899-bb.2(a)": [ - "PRI-01.6", - "PRI-01.11" + "MDM-01-DOAR": [ + "MDM-01" ], - "899-bb.2(b)(ii)(A)": [ - "PRI-01.11" + "MDM-01-BP1": [ + "MDM-03" ], - "899-bb.2(b)(ii)(C)(4)": [ - "PRI-05" + "MDM-01-BP4": [ + "MDM-04" ], - "899-bb.2(b)(ii)(A)(2)": [ - "RSK-01" + "MDM-01-BP6": [ + "MDM-06" ], - "899-bb.2(b)(ii)(B)(2)": [ - "RSK-04" + "KOS-01": [ + "NET-02", + "NET-02.1", + "NET-03", + "NET-08" ], - "899-bb.2(b)(ii)(A)(4)": [ - "SAT-02" + "KOS-03-DOAR": [ + "NET-02" ], - "5.8": [ - "SAT-02" + "KOS-03": [ + "NET-02.3", + "NET-03" ], - "899-bb.2(b)(ii)(A)(5)": [ - "TPM-03.1" - ] - }, - "usa-state-or-ors-646a-2025": { - "646A.586(3)": [ - "CPL-05.2" + "KOS-02": [ + "NET-03", + "NET-03.8" ], - "646A.586(6)": [ - "DCH-18" + "RB-23-DOAR": [ + "NET-06" ], - "646A.583(1)(a)(A)": [ - "DCH-23" + "KOS-05": [ + "NET-06", + "NET-06.4" ], - "646A.578(1)(c)": [ - "PRI-01.6", - "PRI-01.11" + "KOS-05-DOAR": [ + "NET-06.2" ], - "646A.578(2)(a)": [ - "PRI-01.11" + "KOS-04": [ + "NET-06.8" ], - "646A.578(2)(b)": [ - "PRI-01.11" + "KOS-01-DOAR": [ + "NET-08" ], - "646A.578(2)(c)": [ - "PRI-01.11" + "PS-01": [ + "PES-01" ], - "646A.578(2)(d)": [ - "PRI-01.11" + "PS-02": [ + "PES-01", + "PES-01.1" ], - "646A.581(1)": [ - "PRI-01.11" + "PS-03": [ + "PES-01", + "PES-01.1" ], - "646A.581(1)(a)": [ - "PRI-01.11" + "PS-01-DOAR": [ + "PES-01.2" ], - "646A.581(1)(b)": [ - "PRI-01.11" + "PS-03-BP1": [ + "PES-01.2", + "PES-08" ], - "646A.581(1)(c)": [ - "PRI-01.11" + "PS-02-DOAR": [ + "PES-03" ], - "646A.583(1)(b)": [ - "PRI-01.11" + "PS-04": [ + "PES-07", + "PES-07.3", + "PES-07.7", + "PES-12.1" ], - "646A.578(1)(a)": [ - "PRI-02" + "PS-03-BP2": [ + "PES-08" ], - "646A.578(4)": [ - "PRI-02" + "PS-03-BP4": [ + "PES-08" ], - "646A.578(4)(a)": [ - "PRI-02" + "PS-03-BP5": [ + "PES-08.1", + "PES-08.2" ], - "646A.578(4)(b)": [ - "PRI-02" + "PS-03-BP3": [ + "PES-09" ], - "646A.578(4)(c)": [ - "PRI-02" + "PS-03-DOAR": [ + "PES-09" ], - "646A.578(4)(d)": [ - "PRI-02" + "SA-02-DOAR": [ + "PRM-01.1" ], - "646A.578(4)(e)": [ - "PRI-02" + "OIS-07": [ + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-04.2", + "RSK-09" ], - "646A.578(4)(f)": [ - "PRI-02" + "OIS-07-DOAR": [ + "RSK-01.3", + "RSK-01.5" ], - "646A.578(4)(g)": [ - "PRI-02" + "OIS-03-DOAR": [ + "RSK-03", + "RSK-03.1", + "RSK-04.1" ], - "646A.578(4)(h)": [ - "PRI-02" + "SA-03-DOAR": [ + "RSK-06.2" ], - "646A.578(4)(i)": [ - "PRI-02" + "PS-04-DOAR": [ + "RSK-09", + "TPM-03", + "TPM-04" ], - "646A.578(5)(b)": [ - "PRI-02" + "HR-03": [ + "SAT-01", + "SAT-02", + "SAT-03" ], - "646A.583(1)(a)(B)": [ - "PRI-02" + "HR-03-BP1": [ + "SAT-03" ], - "646A.578(6)": [ - "PRI-03" + "HR-03-BP4": [ + "SAT-03" ], - "646A.583(1)(a)(C)": [ - "PRI-03" + "HR-03-DOAR": [ + "SAT-03" ], - "646A.576(7)": [ - "PRI-03.4" + "HR-03-BP2": [ + "SAT-03.3" ], - "646A.578(1)(d)": [ - "PRI-03.4" + "HR-03-BP3": [ + "SAT-03.6" ], - "646A.576(3)": [ - "PRI-03.6" + "BEI-01": [ + "TDA-01" ], - "646A.576(4)": [ - "PRI-03.6" + "RB-21-DOAR": [ + "TDA-02.11" ], - "646A.578(5)(c)": [ - "PRI-03.8" + "KOS-07": [ + "TDA-04" ], - "646A.578(5)(c)(A)": [ - "PRI-03.8" + "BEI-01-BP1": [ + "TDA-06" ], - "646A.578(5)(c)(B)": [ - "PRI-03.8" + "BEI-01-BP4": [ + "TDA-06" ], - "646A.578(5)(c)(C)": [ - "PRI-03.8" + "BEI-01-DOAR": [ + "TDA-06" ], - "646A.578(5)(c)(D)": [ - "PRI-03.8" + "BEI-01-BP3": [ + "TDA-06.7" ], - "646A.578(5)(c)(E)": [ - "PRI-03.8" + "BEI-01-BP2": [ + "TDA-08" ], - "646A.576(7)(a)": [ - "PRI-03.10" + "BEI-11": [ + "TDA-08" ], - "646A.576(7)(b)": [ - "PRI-03.10" + "DLL-01": [ + "TPM-01", + "TPM-05" ], - "646A.578(1)(b)": [ - "PRI-04" + "DLL-02": [ + "TPM-01", + "TPM-08" ], - "646A.574(1)(a)": [ - "PRI-06" + "UP-03": [ + "TPM-05" ], - "646A.574(1)(a)(A)": [ - "PRI-06" + "DLL-01-BP3": [ + "TPM-05" ], - "646A.574(1)(a)(B)": [ - "PRI-06" + "DLL-01-BP4": [ + "TPM-05", + "TPM-05.2" ], - "646A.574(1)(a)(B)(i)": [ - "PRI-06" + "DLL-01-DOAR": [ + "TPM-05.2" ], - "646A.574(1)(a)(B)(ii)": [ - "PRI-06" + "SIM-06": [ + "TPM-05.4" ], - "646A.576(1)": [ - "PRI-06" + "DLL-02-BP1": [ + "TPM-08" ], - "646A.578(5)": [ - "PRI-06" + "DLL-02-BP2": [ + "TPM-08" ], - "646A.578(5)(a)": [ - "PRI-06" + "DLL-02-BP3": [ + "TPM-08" ], - "646A.578(5)(a)(A)": [ - "PRI-06" + "OIS-05-DOAR": [ + "THR-01", + "THR-03.1" ], - "646A.578(5)(a)(B)": [ - "PRI-06" + "RB-17": [ + "VPM-01" ], - "646A.578(5)(a)(C)": [ - "PRI-06" + "RB-17-BP2": [ + "VPM-01", + "VPM-04", + "VPM-05", + "VPM-05.1" ], - "646A.574(1)(b)": [ - "PRI-06.1" + "RB-17-BP1": [ + "VPM-03", + "VPM-03.1", + "VPM-06" ], - "646A.576(6)": [ - "PRI-06.3" + "RB-19": [ + "VPM-03", + "VPM-03.1", + "VPM-04" ], - "646A.576(6)(a)": [ - "PRI-06.3" + "RB-21": [ + "VPM-04", + "VPM-06" ], - "646A.576(6)(b)": [ - "PRI-06.3" + "RB-18": [ + "VPM-07" ], - "646A.576(6)(c)": [ - "PRI-06.3" + "RB-18-DOAR": [ + "VPM-07" + ] + }, + "emea-grc-pirppd-1997": { + "B.7.7": [ + "GOV-17" ], - "646A.576(6)(d)": [ - "PRI-06.3" + "B.8.2": [ + "GOV-17" ], - "646A.576(5)": [ - "PRI-06.4" + "B.5.3": [ + "CPL-01" ], - "646A.576(5)(a)": [ - "PRI-06.4" + "B.10.2": [ + "HRS-01", + "PRI-01.6" ], - "646A.576(5)(b)": [ - "PRI-06.4" + "B.9.1.b": [ + "PRI-01.5" ], - "646A.576(5)(c)": [ - "PRI-06.4" + "B.9.2": [ + "PRI-01.5" ], - "646A.576(5)(d)": [ - "PRI-06.4" + "B.9.2.f": [ + "PRI-01.6", + "PRI-01.11" ], - "646A.576(5)(e)": [ - "PRI-06.4" + "B.10.1": [ + "PRI-01.6" ], - "646A.576(5)(e)(A)": [ - "PRI-06.4" + "B.10.3": [ + "PRI-01.6" ], - "646A.576(5)(e)(B)": [ - "PRI-06.4" + "C.11.3": [ + "PRI-01.7", + "PRI-02", + "PRI-17" ], - "646A.574(1)(c)": [ - "PRI-06.5" + "B.4.1.a": [ + "PRI-01.11", + "PRI-04", + "PRI-04.1" ], - "646A.574(2)": [ - "PRI-06.6" + "B.4.1.b": [ + "PRI-01.11", + "PRI-04", + "PRI-04.1" ], - "646A.574(1)(a)(C)": [ - "PRI-06.7" + "B.7.2.b": [ + "PRI-01.11" ], - "646A.576(2)": [ - "PRI-06.8" + "B.7.2.c": [ + "PRI-01.11" ], - "646A.581(2)": [ - "PRI-07.1", - "TPM-05" + "B.7.2.d": [ + "PRI-01.11" ], - "646A.574(1)(d)": [ - "PRI-21" + "B.7.2.e": [ + "PRI-01.11" ], - "646A.574(1)(d)(A)": [ - "PRI-21" + "B.7.2.f": [ + "PRI-01.11", + "PRI-05.1" ], - "646A.574(1)(d)(B)": [ - "PRI-21" + "B.7.2.g": [ + "PRI-01.11" ], - "646A.574(1)(d)(C)": [ - "PRI-21" + "C.11.4": [ + "PRI-01.11" ], - "646A.586(1)(a)": [ - "RSK-10" + "C.11.5": [ + "PRI-01.11" ], - "646A.586(1)(b)": [ - "RSK-10" + "C.12.3": [ + "PRI-01.11" ], - "646A.586(1)(b)(A)": [ - "RSK-10" + "C.11.1": [ + "PRI-02" ], - "646A.586(1)(b)(B)": [ - "RSK-10" + "C.11.1.a": [ + "PRI-02" ], - "646A.586(1)(b)(C)": [ - "RSK-10" + "C.11.1.b": [ + "PRI-02" ], - "646A.586(1)(b)(D)": [ - "RSK-10" + "C.11.1.c": [ + "PRI-02" ], - "646A.586(1)(b)(D)(i)": [ - "RSK-10" + "C.11.1.d": [ + "PRI-02" ], - "646A.586(1)(b)(D)(ii)": [ - "RSK-10" + "C.11.2": [ + "PRI-02" ], - "646A.586(1)(b)(D)(iii)": [ - "RSK-10" + "B.5.1": [ + "PRI-03" ], - "646A.586(1)(b)(D)(iv)": [ - "RSK-10" + "B.7.2.a": [ + "PRI-03" ], - "646A.586(1)(c)": [ - "RSK-10" + "B.7.1": [ + "PRI-03.3", + "PRI-05.4" ], - "646A.586(2)": [ - "RSK-10" + "B.9.1": [ + "PRI-03.3", + "PRI-07" ], - "646A.586(4)": [ - "RSK-10" + "B.9.1.a": [ + "PRI-03.3" ], - "646A.586(5)": [ - "RSK-10" + "B.5.2": [ + "PRI-04.1" ], - "646A.581(2)(a)": [ - "TPM-05" + "B.5.2.a": [ + "PRI-04.1" ], - "646A.581(2)(b)": [ - "TPM-05" + "B.5.2.b": [ + "PRI-04.1" ], - "646A.581(2)(c)": [ - "TPM-05" + "B.5.2.c": [ + "PRI-04.1" ], - "646A.581(2)(d)": [ - "TPM-05" + "B.5.2.d": [ + "PRI-04.1" ], - "646A.581(2)(e)": [ - "TPM-05" + "B.5.2.e": [ + "PRI-04.1" ], - "646A.581(2)(f)": [ - "TPM-05" + "B.8.3": [ + "PRI-04.1", + "PRI-05.4" ], - "646A.581(2)(g)": [ - "TPM-05" + "B.4.1.d": [ + "PRI-05" ], - "646A.581(2)(h)": [ - "TPM-05" - ] - }, - "usa-state-or-cpa-2023": { - "Section 7(1)(b)": [ - "CPL-01" + "B.4.2": [ + "PRI-05" ], - "Section 8(3)": [ - "CPL-01.3" + "B.7.2": [ + "PRI-05.4" ], - "Section 8(6)": [ - "DCH-18" + "C.12.1": [ + "PRI-06" ], - "Section 7(1)(a)(A)": [ - "DCH-23" + "C.12.2": [ + "PRI-06" ], - "Section 7(1)(a)(B)": [ - "PRI-01.3" + "C.12.2.a": [ + "PRI-06" ], - "Section 5(1)(c)": [ - "PRI-01.6" + "C.12.2.b": [ + "PRI-06" ], - "Section 6(1)(b)": [ - "PRI-01.6" + "C.12.2.c": [ + "PRI-06" ], - "Section 5(1)(a)": [ - "PRI-02", - "PRI-02.1" + "C.12.2.d": [ + "PRI-06", + "PRI-19.3" ], - "Section 5(4)(a)": [ - "PRI-02", - "PRI-05.7" + "C.12.2.e": [ + "PRI-06", + "PRI-06.1", + "PRI-06.5" ], - "Section 5(4)(b)": [ - "PRI-02", - "PRI-02.1" + "C.12.2.f": [ + "PRI-06", + "PRI-07.3" ], - "Section 5(4)(c)": [ - "PRI-02" + "B.4.1.c": [ + "PRI-06.1", + "PRI-10" ], - "Section 5(4)(d)": [ - "PRI-02" + "B.9.2.a": [ + "PRI-07" ], - "Section 5(4)(e)": [ - "PRI-02", - "PRI-05.7" + "B.9.2.b": [ + "PRI-07" ], - "Section 5(4)(f)": [ - "PRI-02" + "B.9.2.b.i": [ + "PRI-07" ], - "Section 5(4)(g)": [ - "PRI-02" + "B.9.2.b.ii": [ + "PRI-07" ], - "Section 5(4)(h)": [ - "PRI-02", - "PRI-02.1" + "B.9.2.b.iii": [ + "PRI-07" ], - "Section 5(4)(i)": [ - "PRI-02" + "B.9.2.c": [ + "PRI-07" ], - "Section 5(2)(b)": [ - "PRI-03", - "PRI-04", - "PRI-04.1" + "B.9.2.d": [ + "PRI-07" ], - "Section 5(2)(c)": [ - "PRI-03", - "PRI-05.4" + "B.9.2.e": [ + "PRI-07" ], - "Section 5(1)(d)": [ - "PRI-03.4" + "B.10.4": [ + "PRI-07.1" ], - "Section 5(2)(d)": [ - "PRI-03.5" + "B.8.1": [ + "PRI-07.2" ], - "Section 4(4)": [ - "PRI-03.6" + "B.6.1": [ + "PRI-15" ], - "Section 3(1)(d)(A)": [ - "PRI-03.7" + "B.6.2": [ + "PRI-15" ], - "Section 3(1)(d)(B)": [ - "PRI-03.7" + "B.6.2.a": [ + "PRI-15" ], - "Section 3(1)(d)(C)": [ - "PRI-03.7" + "B.6.2.b": [ + "PRI-15" ], - "Section 5(6)": [ - "PRI-03.7" + "B.6.2.c": [ + "PRI-15" ], - "Section 5(5)(c)": [ - "PRI-03.8" + "B.6.2.d": [ + "PRI-15" ], - "Section 5(5)(c)(A)": [ - "PRI-03.8" + "B.6.2.e": [ + "PRI-15" ], - "Section 5(5)(c)(B)": [ - "PRI-03.8" + "B.6.2.f": [ + "PRI-15" ], - "Section 5(5)(c)(C)": [ - "PRI-03.8" + "B.6.2.g": [ + "PRI-15" + ], + "B.6.2.h": [ + "PRI-15" + ], + "B.6.3": [ + "PRI-15" + ], + "B.6.4": [ + "PRI-15" + ] + }, + "emea-hun-act-cxii-2011": { + "II.13.16(3)": [ + "GOV-17" + ], + "II.5.5(2)(b)": [ + "CPL-01", + "PRI-04.1" ], - "Section 5(5)(c)(D)": [ - "PRI-03.8" + "II.5.6(1)(a)": [ + "CPL-01", + "PRI-01.11" ], - "Section 5(5)(c)(E)": [ - "PRI-03.8" + "II.5.6(5)(a)": [ + "CPL-01", + "PRI-04.1" ], - "Section 5(1)(b)": [ - "PRI-04" + "II.4.4(3)": [ + "DCH-02", + "PRI-04.1" ], - "Section 4(7)(a)": [ - "PRI-05" + "II.11.12(2)": [ + "DCH-23" ], - "Section 7(1)(c)": [ - "PRI-05.1" + "II.18.24(2)": [ + "HRS-03", + "PRI-01.4" ], - "Section 4(7)(b)": [ - "PRI-05.4" + "II.6.7(1)": [ + "PRI-01", + "PRI-01.11" ], - "Section 5(2)(a)": [ - "PRI-05.4" + "II.18.24(1)(a)": [ + "PRI-01.4" ], - "Section 3(1)(a)(A)": [ - "PRI-06" + "II.18.24(1)(b)": [ + "PRI-01.4" ], - "Section 3(1)(b)": [ - "PRI-06.1" + "II.18.24(1)(c)": [ + "PRI-01.4" ], - "Section 4(6)(a)": [ - "PRI-06.3" + "II.18.24(2)(a)": [ + "PRI-01.4" ], - "Section 4(5)(a)": [ - "PRI-06.4" + "II.18.24(2)(b)": [ + "PRI-01.4" ], - "Section 4(5)(b)": [ - "PRI-06.4" + "II.18.24(2)(c)": [ + "PRI-01.4" ], - "Section 4(5)(c)": [ - "PRI-06.4" + "II.18.24(2)(d)": [ + "PRI-01.4" ], - "Section 4(5)(d)": [ - "PRI-06.4" + "II.18.24(2)(e)": [ + "PRI-01.4" ], - "Section 4(5)(e)": [ - "PRI-06.4" + "II.18.24(2)(f)": [ + "PRI-01.4" ], - "Section 4(5)(e)(A)": [ - "PRI-06.4" + "II.7.8(1)(b)": [ + "PRI-01.5", + "PRI-07", + "PRI-07.1" ], - "Section 4(5)(e)(B)": [ - "PRI-06.4", - "PRI-07.4" + "II.8.9(3)": [ + "PRI-01.5", + "PRI-07", + "PRI-07.1" ], - "Section 4(6)(b)": [ - "PRI-06.4" + "II.8.9(5)": [ + "PRI-01.5", + "PRI-07", + "PRI-07.1" ], - "Section 4(6)(c)": [ - "PRI-06.4" + "II.6.7(2)": [ + "PRI-01.6" ], - "Section 4(6)(d)": [ - "PRI-06.4" + "II.6.7(3)": [ + "PRI-01.6" ], - "Section 5(5)(a)(A)": [ - "PRI-06.4" + "II.6.7(4)": [ + "PRI-01.6" ], - "Section 5(5)(a)(B)": [ - "PRI-06.4" + "II.6.7(5)(a)": [ + "PRI-01.6" ], - "Section 5(5)(a)(C)": [ - "PRI-06.4" + "II.6.7(5)(b)": [ + "PRI-01.6" ], - "Section 5(5)(b)": [ - "PRI-06.4" + "II.6.7(5)(c)": [ + "PRI-01.6" ], - "Section 3(1)(c)": [ - "PRI-06.5" + "II.6.7(5)(d)": [ + "PRI-01.6" ], - "Section 3(2)": [ - "PRI-06.6", - "PRI-06.7" + "II.6.7(5)(e)": [ + "PRI-01.6" ], - "Section 3(1)(a)(C)": [ - "PRI-06.7" + "II.6.7(5)(f)": [ + "PRI-01.6" ], - "Section 6(1)(a)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "II.6.7(6)": [ + "PRI-01.6" ], - "Section 6(1)(c)": [ - "PRI-07", - "RSK-10" + "II.5.6(5)(b)": [ + "PRI-01.11" ], - "Section 6(1)": [ + "II.8.9(1)(c)": [ + "PRI-01.11", "PRI-07.1" ], - "Section 6(2)": [ - "PRI-07.1" + "II.8.9(1)(d)": [ + "PRI-01.11" ], - "Section 7(1)(a)(C)": [ + "II.10.11(1)(a)": [ + "PRI-01.11", "PRI-07.1" ], - "Section 3(1)(a)(B)(i)": [ - "PRI-14.1" + "II.13.16(1)": [ + "PRI-01.11", + "PRI-07.4" ], - "Section 3(1)(a)(B)(ii)": [ - "PRI-14.1" + "II.13.17(3)": [ + "PRI-01.11" ], - "Section 8(1)(a)": [ - "RSK-10" + "II.13.17(4)": [ + "PRI-01.11" ], - "Section 8(1)(c)": [ - "RSK-10" + "II.13.17(5)": [ + "PRI-01.11" ], - "Section 8(2)": [ - "RSK-10" + "II.14.20(4)(e)": [ + "PRI-01.11" ], - "Section 6(2)(a)": [ - "TPM-05" + "II.14.20(4)(f)": [ + "PRI-01.11", + "PRI-02.13" ], - "Section 6(2)(b)": [ - "TPM-05" + "II.15.21(1)(a)": [ + "PRI-01.11", + "PRI-03", + "PRI-03.4" ], - "Section 6(2)(c)": [ - "TPM-05" + "II.15.21(1)(b)": [ + "PRI-01.11", + "PRI-03", + "PRI-03.4" ], - "Section 6(2)(d)": [ - "TPM-05" + "II.15.21(1)(c)": [ + "PRI-01.11", + "PRI-03" ], - "Section 6(2)(e)": [ - "TPM-05" + "II.15.21(3)": [ + "PRI-01.11", + "PRI-06.4" ], - "Section 6(2)(f)": [ - "TPM-05" + "II.15.21(7)": [ + "PRI-01.11", + "PRI-05" ], - "Section 6(2)(g)": [ - "TPM-05" + "II.18.24(3)": [ + "PRI-01.11" ], - "Section 6(2)(h)": [ - "TPM-05" - ] - }, - "usa-state-tn-tipa-2025": { - "47-18-3206(c)": [ - "CPL-05", - "CPL-05.2", - "RSK-10" + "II.5.6(4)": [ + "PRI-02", + "PRI-03" ], - "47-18-3203(a)(2)(C)": [ - "DCH-23", - "PRI-06.5" + "II.7.8(1)(a)": [ + "PRI-02", + "PRI-03" ], - "47-18-3204(a)(3)": [ - "PRI-01.6" + "II.14.20(1)": [ + "PRI-02", + "PRI-03.7" ], - "47-18-3204(a)(1)": [ + "II.14.20(2)": [ "PRI-02", - "PRI-04" + "PRI-02.1" ], - "47-18-3204(c)": [ + "II.14.20(4)(a)": [ "PRI-02" ], - "47-18-3204(c)(1)": [ + "II.14.20(4)(b)": [ "PRI-02" ], - "47-18-3204(c)(2)": [ + "II.14.20(4)(d)": [ "PRI-02", + "PRI-05" + ], + "II.8.9(1)(a)": [ "PRI-02.1" ], - "47-18-3204(c)(3)": [ - "PRI-02" + "II.14.20(4)(c)": [ + "PRI-02.1" ], - "47-18-3204(c)(4)": [ - "PRI-02" + "II.5.5(1)(a)": [ + "PRI-03" ], - "47-18-3204(c)(5)": [ - "PRI-02" + "II.5.5(2)(a)": [ + "PRI-03" ], - "47-18-3204(d)": [ - "PRI-02", + "II.5.6(3)": [ + "PRI-03", "PRI-03.3" ], - "47-18-3204(e)(1)": [ - "PRI-02" - ], - "47-18-3203(a)(2)(E)": [ + "II.8.9(4)": [ "PRI-03" ], - "47-18-3203(b)": [ - "PRI-03", - "PRI-03.1", - "PRI-03.7" - ], - "47-18-3204(a)(6)": [ + "II.11.12(3)(a)": [ "PRI-03", "PRI-05.4" ], - "47-18-3203(a)(2)(E)(i)": [ - "PRI-03.1", - "PRI-03.3" - ], - "47-18-3203(a)(2)(E)(ii)": [ - "PRI-03.1", - "PRI-03.3" + "II.5.6(2)": [ + "PRI-03.6" ], - "47-18-3203(a)(2)(E)(iii)": [ - "PRI-03.1", - "PRI-03.3" + "II.13.18(1)": [ + "PRI-03.11", + "PRI-07.3" ], - "47-18-3203(a)(1)": [ - "PRI-03.6", - "PRI-06" + "II.4.4(1)": [ + "PRI-04", + "PRI-04.1" ], - "47-18-3204(a)(2)": [ + "II.4.4(2)": [ "PRI-04", - "PRI-05.1" + "PRI-04.1" ], - "47-18-3204(a)(5)": [ + "II.11.12(1)": [ + "PRI-04", "PRI-04.1" ], - "47-18-3204(b)": [ + "II.12.13(2)": [ + "PRI-04", + "PRI-05.4" + ], + "II.4.4(5)": [ "PRI-04.1" ], - "47-18-3203(a)(2)(C)(i)(a)": [ - "PRI-05", - "PRI-06.5" + "II.5.5(1)(b)": [ + "PRI-04.1" ], - "47-18-3204(a)(4)": [ - "PRI-05" + "II.5.5(2)(c)": [ + "PRI-04.1" ], - "47-18-3207(a)(1)": [ - "PRI-05.1" + "II.5.5(3)": [ + "PRI-04.1" ], - "47-18-3207(a)(2)": [ - "PRI-05.1" + "II.5.5(4)": [ + "PRI-04.1" ], - "47-18-3207(a)(3)": [ - "PRI-05.1" + "II.5.6(1)(b)": [ + "PRI-04.1" ], - "47-18-3207(b)(1)": [ - "PRI-05.1" + "II.10.11(1)(b)": [ + "PRI-04.1" ], - "47-18-3207(b)(2)": [ - "PRI-05.1" + "II.8.9(1)(b)": [ + "PRI-05" ], - "47-18-3207(b)(3)": [ - "PRI-05.1", - "PRI-06.4" + "II.13.15(3)": [ + "PRI-05" ], - "47-18-3207(b)(3)(A)": [ - "PRI-05.1", - "PRI-06.4" + "II.13.17(2)(a)": [ + "PRI-05" ], - "47-18-3207(b)(3)(B)": [ - "PRI-05.1", - "PRI-06.4" + "II.13.17(2)(b)": [ + "PRI-05" ], - "47-18-3207(b)(3)(C)": [ - "PRI-05.1", - "PRI-06.4" + "II.13.17(2)(c)": [ + "PRI-05" ], - "47-18-3203(a)(2)(C)(i)(b)": [ - "PRI-05.4", - "PRI-06.5" + "II.13.17(2)(d)": [ + "PRI-05" ], - "47-18-3203(a)(2)(C)(ii)": [ - "PRI-05.4", - "PRI-06.5" + "II.13.17(2)(e)": [ + "PRI-05" ], - "47-18-3207(b)": [ - "PRI-05.4" + "II.4.4(4)": [ + "PRI-05.2" ], - "47-18-3207(c)": [ - "PRI-05.4" + "II.13.17(1)": [ + "PRI-05.2", + "PRI-06.1" ], - "47-18-3207(d)": [ + "II.11.12(3)(b)": [ "PRI-05.4" ], - "47-18-3203(a)(2)(A)": [ + "II.13.14(a)": [ "PRI-06" ], - "47-18-3203(a)(2)(B)": [ - "PRI-06.1" - ], - "47-18-3203(b)(1)": [ - "PRI-06.2", - "PRI-06.4" - ], - "47-18-3203(c)": [ - "PRI-06.3" + "II.13.14(b)": [ + "PRI-06" ], - "47-18-3203(b)(2)": [ - "PRI-06.4" + "II.13.14(c)": [ + "PRI-06" ], - "47-18-3203(b)(3)": [ + "II.13.15(1)": [ + "PRI-06", "PRI-06.4" ], - "47-18-3203(b)(4)": [ + "II.13.15(2)": [ + "PRI-06", "PRI-06.4", - "PRI-07.4" + "PRI-14", + "PRI-14.1" ], - "47-18-3204(e)(1)(A)": [ + "II.13.15(4)": [ + "PRI-06", "PRI-06.4" ], - "47-18-3204(e)(1)(B)": [ - "PRI-06.4" + "II.13.16(2)": [ + "PRI-06.4", + "PRI-17" ], - "47-18-3204(e)(1)(C)": [ - "PRI-06.4" + "II.13.18(2)": [ + "PRI-06.4", + "PRI-17" ], - "47-18-3204(e)(2)": [ + "II.15.21(2)": [ "PRI-06.4" ], - "47-18-3203(a)(2)(D)": [ - "PRI-06.6", - "PRI-06.7" - ], - "47-18-3205(a)": [ - "PRI-07.1" - ], - "47-18-3205(a)(1)": [ - "PRI-07.1" - ], - "47-18-3205(a)(2)": [ - "PRI-07.1" - ], - "47-18-3205(b)": [ + "II.8.9(1)": [ "PRI-07.1" ], - "47-18-3205(b)(1)": [ + "II.8.9(1)(e)": [ "PRI-07.1" ], - "47-18-3205(b)(2)": [ + "II.8.9(2)": [ "PRI-07.1" ], - "47-18-3205(b)(3)": [ + "II.9.10(1)": [ "PRI-07.1" ], - "47-18-3205(b)(4)": [ + "II.9.10(2)": [ "PRI-07.1" ], - "47-18-3205(b)(5)": [ + "II.9.10(3)": [ "PRI-07.1" ], - "47-18-3205(c)": [ + "II.9.10(4)": [ "PRI-07.1" ], - "47-18-3205(d)": [ - "PRI-07.1", - "PRI-07.2" - ], - "47-18-3206(a)": [ - "RSK-10" - ], - "47-18-3206(a)(1)": [ - "RSK-10" - ], - "47-18-3206(a)(2)": [ - "RSK-10" - ], - "47-18-3206(a)(3)": [ - "RSK-10" - ], - "47-18-3206(a)(3)(A)": [ - "RSK-10" - ], - "47-18-3206(a)(3)(B)": [ - "RSK-10" - ], - "47-18-3206(a)(3)(C)": [ - "RSK-10" - ], - "47-18-3206(a)(3)(D)": [ - "RSK-10" - ], - "47-18-3206(a)(4)": [ - "RSK-10" - ], - "47-18-3206(a)(5)": [ - "RSK-10" - ], - "47-18-3206(b)": [ - "RSK-10" - ], - "47-18-3206(d)": [ - "RSK-10" - ], - "47-18-3206(e)": [ - "RSK-10" - ], - "47-18-3206(f)": [ - "RSK-10" - ], - "47-18-3201": [ - "SEA-02.1" + "II.10.11(2)": [ + "PRI-19" ] }, - "usa-state-tx-bc521-2009": { - "521.053(b)": [ - "IRO-10" + "emea-irl-dpa-2018": { + "s.83": [ + "CPL-01" ], - "521.053(b-1)": [ + "s.85": [ "IRO-10" ], - "521.053(c)": [ + "s.86": [ "IRO-10" ], - "521.053(d)": [ - "IRO-10" + "s.87": [ + "IRO-10.2" ], - "521.053(e)": [ - "IRO-10" + "s.88": [ + "PRI-01.4" ], - "521.053(e)(1)": [ - "IRO-10" + "s.96": [ + "PRI-01.5" ], - "521.053(e)(2)": [ - "IRO-10" + "s.97": [ + "PRI-01.5" ], - "521.053(e)(3)": [ - "IRO-10" + "s.98": [ + "PRI-01.5" ], - "521.053(f)": [ - "IRO-10" + "s.99": [ + "PRI-01.5" ], - "521.053(f)(1)": [ - "IRO-10" + "s.100": [ + "PRI-01.5" ], - "521.053(f)(2)": [ - "IRO-10" + "s.72": [ + "PRI-01.6" ], - "521.053(f)(3)": [ - "IRO-10" + "s.75": [ + "PRI-01.6" ], - "521.053(g)": [ - "IRO-10" + "s.76": [ + "PRI-01.6" ], - "521.053(h)": [ - "IRO-10" + "s.77": [ + "PRI-01.6" ], - "521.053(i)": [ - "IRO-10" + "s.78": [ + "PRI-01.6" ], - "521.053(i)(1)": [ - "IRO-10" + "s.71": [ + "PRI-01.11" ], - "521.053(i)(2)": [ - "IRO-10" + "s.94": [ + "PRI-01.11" ], - "521.053(i)(3)": [ - "IRO-10" + "s.90": [ + "PRI-02" ], - "521.053(i)(4)": [ - "IRO-10" + "s.74": [ + "PRI-05.2" ], - "521.053(i)(5)": [ - "IRO-10" + "s.45": [ + "PRI-05.4" ], - "521.053(i)(6)": [ - "IRO-10" + "s.46": [ + "PRI-05.4" ], - "521.052(a)": [ - "PRI-01.6", - "PRI-01.11" + "s.47": [ + "PRI-05.4" ], - "521.051(a)": [ - "PRI-01.11", + "s.48": [ "PRI-05.4" ], - "521.052(b)": [ - "PRI-05" + "s.49": [ + "PRI-05.4" ], - "521.052(b)(1)": [ - "PRI-05" + "s.50": [ + "PRI-05.4" ], - "521.052(b)(2)": [ - "PRI-05" + "s.51": [ + "PRI-05.4" ], - "521.052(b)(3)": [ - "PRI-05" - ] - }, - "usa-state-tx-cdpa-2025": { - "541.101(b)(2)": [ - "CPL-01", - "PRI-01" + "s.52": [ + "PRI-05.4" ], - "541.106(a)(1)": [ - "DCH-23" + "s.53": [ + "PRI-05.4" ], - "541.101(a)(2)": [ - "PRI-01" + "s.54": [ + "PRI-05.4" ], - "541.204(c)": [ - "PRI-01" + "s.55": [ + "PRI-05.4" ], - "541.053(b)": [ - "PRI-02" + "s.73": [ + "PRI-05.4" ], - "541.055(c)": [ - "PRI-02" + "s.56": [ + "PRI-06" ], - "541.055(d)": [ - "PRI-02" + "s.57": [ + "PRI-06" ], - "541.102(a)(1)": [ - "PRI-02", - "PRI-05.7" + "s.58": [ + "PRI-06" ], - "541.102(a)(2)": [ - "PRI-02", - "PRI-02.1" + "s.59": [ + "PRI-06" ], - "541.102(a)(3)": [ - "PRI-02" + "s.60": [ + "PRI-06" ], - "541.102(a)(4)": [ - "PRI-02" + "s.61": [ + "PRI-06" ], - "541.102(a)(5)": [ - "PRI-02" + "s.91": [ + "PRI-06" ], - "541.102(a)(6)": [ - "PRI-02" + "s.92": [ + "PRI-06" ], - "541.102(b)": [ - "PRI-02" + "s.93": [ + "PRI-06.4" ], - "541.103": [ - "PRI-02" + "s.80": [ + "PRI-07.1" ], - "541.106(a)(2)": [ - "PRI-02" + "s.79": [ + "PRI-07.2" ], - "541.101(b)(1)": [ - "PRI-02.1", - "PRI-04" + "s.81": [ + "PRI-14" ], - "541.101(b)(4)": [ - "PRI-03", - "PRI-03.3" + "s.82": [ + "PRI-14" ], - "541.107(a)": [ - "PRI-03" + "s.89": [ + "PRI-19" ], - "541.101(b)(3)": [ - "PRI-03.5" + "s.84": [ + "RSK-10" + ] + }, + "emea-isr-cmo-2-0": { + "3": [ + "RSK-01" ], - "541.101(c)": [ - "PRI-03.5" + "2.A": [ + "GOV-01", + "GOV-01.1", + "PRM-01.1" ], - "541.055(e)": [ - "PRI-03.6" + "4.2, Stage 0": [ + "GOV-01" ], - "541.055(e)(1)": [ - "PRI-03.6" + "4.1, Stage 5": [ + "GOV-01.3", + "CPL-02", + "CPL-02.1" ], - "541.055(e)(2)": [ - "PRI-03.6" + "Appendix A, 1.1": [ + "GOV-01.3", + "GOV-03" ], - "541.055(e)(3)": [ - "PRI-03.6" + "4.2, Stage 1.1": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "541.055(e)(4)": [ - "PRI-03.6" + "4.2, Stage 5": [ + "GOV-05", + "CPL-03" ], - "541.051(b)(5)(A)": [ - "PRI-03.7" + "Appendix D": [ + "GOV-05" ], - "541.051(b)(5)(B)": [ - "PRI-03.7" + "4.1, Stage 1": [ + "AST-02", + "AST-04" ], - "541.051(b)(5)(C)": [ - "PRI-03.7" + "Appendix A, 14.1": [ + "BCD-11" ], - "541.052(f)(2)": [ - "PRI-03.7", - "PRI-03.9", - "PRI-05.4" + "Appendix A, 7.1": [ + "CAP-02" ], - "541.052(a)": [ - "PRI-03.9" + "Appendix A, 6.1": [ + "CLD-02", + "CLD-10" ], - "541.101(a)(1)": [ - "PRI-04" + "Appendix A, 5.1": [ + "CLD-06.1" ], - "541.204(a)": [ - "PRI-05.4" + "Appendix A, 3.1": [ + "CFG-02", + "CRY-01" ], - "541.204(a)(1)": [ - "PRI-05.4" + "Appendix A, 4.1": [ + "CFG-02" ], - "541.204(a)(2)": [ - "PRI-05.4" + "Appendix A, 4.2": [ + "CFG-02" ], - "541.204(b)": [ - "PRI-05.4" + "Appendix A, 12.2": [ + "MON-03" ], - "541.051(a)": [ - "PRI-06" + "Appendix A, 5.2": [ + "DCH-01.2", + "DCH-02", + "DCH-14" ], - "541.055(a)(1)": [ - "PRI-06", - "PRI-18" + "Appendix A, 2.1": [ + "END-04", + "END-04.7" ], - "541.051(b)(2)": [ - "PRI-06.1" + "Appendix A, 2.2": [ + "END-04.1" ], - "541.053(a)": [ - "PRI-06.3", - "PRI-18" + "Appendix A, 9.1": [ + "HRS-05.1" ], - "541.051(b)(1)": [ - "PRI-06.4" + "Appendix A, 9.2": [ + "HRS-08", + "HRS-09", + "IAC-07", + "IAC-07.1", + "IAC-07.2" ], - "541.052(b)": [ - "PRI-06.4" + "Appendix A, 8.2": [ + "IAC-01" ], - "541.052(c)": [ - "PRI-06.4" + "Appendix A, 8.1": [ + "IAC-15" ], - "541.052(d)": [ - "PRI-06.4" + "Appendix A, 12.1": [ + "IRO-02" ], - "541.053(c)": [ - "PRI-06.4" + "Appendix B": [ + "IRO-02.4", + "THR-10" ], - "541.053(d)": [ - "PRI-06.4" + "Appendix A, 13.1": [ + "IRO-09" ], - "541.055(a)(2)": [ - "PRI-06.4" + "4.2, Stage 1.3": [ + "IAO-01.1" ], - "541.055(a)(3)": [ - "PRI-06.4", - "WEB-06" + "4.2, Stage 4": [ + "IAO-05", + "RSK-06.4" ], - "541.055(b)": [ - "PRI-06.4" + "Appendix A, 7.3": [ + "NET-03" ], - "541.051(b)(3)": [ - "PRI-06.5" + "Appendix A, 7.4": [ + "NET-03.1", + "NET-04.1" ], - "541.051(b)(4)": [ - "PRI-06.7" + "Appendix A, 7.5": [ + "NET-06.9" ], - "541.104(a)(1)": [ - "PRI-07.1" + "Appendix A, 7.2": [ + "NET-10" ], - "541.104(a)(2)": [ - "PRI-07.1" + "Appendix A, 11.1": [ + "PES-07.4" ], - "541.104(a)(3)": [ - "PRI-07.1" + "Appendix A, 11.2": [ + "PES-08" ], - "541.104(b)(1)": [ - "PRI-07.1" + "Appendix F": [ + "PRI-01" ], - "541.104(b)(2)": [ - "PRI-07.1" + "4.1, Stage 4": [ + "PRM-01", + "PRM-01.1", + "PRM-02.1", + "PRM-03" ], - "541.104(b)(3)": [ - "PRI-07.1" + "4.2, Stage 1.2": [ + "PRM-01.1", + "OPS-02" ], - "541.104(b)(4)": [ - "PRI-07.1" + "4.1, Stages 2-3": [ + "PRM-01.2" ], - "541.104(b)(5)": [ - "PRI-07.1" + "2.D": [ + "PRM-02.1" ], - "541.104(b)(6)(A)": [ - "PRI-07.1" + "4.2, Stage 2.1": [ + "RSK-01.1", + "RSK-03" ], - "541.104(b)(6)(B)": [ - "PRI-07.1" + "4.2, Stage 2.2": [ + "RSK-04", + "RSK-04.1" ], - "541.104(b)(6)(C)": [ - "PRI-07.1" + "4.2, Stage 2.3": [ + "RSK-04", + "RSK-06" ], - "541.104(b)(6)(D)": [ - "PRI-07.1" + "4.2, Stage 3.1": [ + "RSK-06.3" ], - "541.104(b)(6)(E)": [ - "PRI-07.1" + "Appendix C": [ + "SEA-01.1" ], - "541.104(c)": [ - "PRI-07.1" + "2.E": [ + "SEA-03" ], - "541.106(a)(3)": [ - "PRI-07.1" + "Appendix A, 10.1": [ + "TPM-01" ], - "541.106(d)": [ - "PRI-07.1" + "2.B": [ + "THR-01" + ] + }, + "emea-isr-ppl-5741-2025": { + "s.17B": [ + "GOV-04" ], - "541.052(e)": [ - "PRI-07.4" + "s.17B2": [ + "HRS-03", + "PRI-01.4" ], - "541.052(f)(1)": [ - "PRI-14" + "s.17B3": [ + "HRS-03.2" ], - "541.105(a)(1)": [ - "RSK-10" + "s.16": [ + "HRS-06.1", + "PRI-01.11" ], - "541.105(a)(2)": [ - "RSK-10" + "s.17B1": [ + "PRI-01.4" ], - "541.105(a)(3)(A)": [ - "RSK-10" + "s.17": [ + "PRI-01.6" ], - "541.105(a)(3)(B)": [ - "RSK-10" + "s.1": [ + "PRI-01.11", + "PRI-03" ], - "541.105(a)(3)(C)": [ - "RSK-10" + "s.2": [ + "PRI-01.11" ], - "541.105(a)(3)(D)": [ - "RSK-10" + "s.2A": [ + "PRI-01.11" ], - "541.105(a)(4)": [ - "RSK-10" + "s.3": [ + "PRI-01.11" ], - "541.105(a)(5)": [ - "RSK-10" + "s.11": [ + "PRI-02" ], - "541.105(b)(1)": [ - "RSK-10" + "s.13": [ + "PRI-06" ], - "541.105(b)(2)(A)": [ - "RSK-10" + "s.14": [ + "PRI-06", + "PRI-06.1" ], - "541.105(b)(2)(B)": [ - "RSK-10" + "s.13A": [ + "PRI-07.1" ], - "541.105(b)(2)(C)": [ - "RSK-10" + "s.8": [ + "PRI-15" ], - "541.105(b)(2)(D)": [ - "RSK-10" + "s.8A": [ + "PRI-15" ], - "541.105(c)": [ - "RSK-10" + "s.9": [ + "PRI-15" ], - "541.105(d)": [ - "RSK-10" + "s.10": [ + "PRI-15" + ] + }, + "emea-ita-pdpc-2018": { + "Article 1(1)": [ + "CPL-01" ], - "541.105(e)": [ - "RSK-10" + "Article 2-o(1)": [ + "HRS-03" ], - "541.105(f)": [ - "RSK-10" + "Article 2-o(2)": [ + "HRS-03" ], - "541.001": [ - "SEA-02.1" + "Article 2-q(1)": [ + "PRI-01.4" ], - "541.104(a)": [ - "TPM-05" + "Article 115(1)": [ + "PRI-01.6" ], - "541.104(b)": [ - "TPM-05" - ] - }, - "usa-state-tx-dir-security-control-standards-catalog-2-2": { - "PM-01": [ - "GOV-01", - "GOV-02", - "GOV-03" + "Article 115(2)": [ + "PRI-01.6" ], - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "Article 75(1)": [ + "PRI-01.11" ], - "AC-18-SID": [ - "GOV-02" + "Article 102(1)": [ + "PRI-01.11" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "Article 102(2)(a)": [ + "PRI-01.11" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "Article 102(2)(b)": [ + "PRI-01.11" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "Article 102(2)(c)": [ + "PRI-01.11" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "Article 106(1)": [ + "PRI-01.11" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "Article 106(2)(a)": [ + "PRI-01.11" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "Article 106(2)(b)": [ + "PRI-01.11" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "Article 106(2)(c)": [ + "PRI-01.11" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "Article 106(2)(d)": [ + "PRI-01.11" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "Article 106(2)(g)": [ + "PRI-01.11" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "Article 106(2)(h)": [ + "PRI-01.11" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "Article 106(2)(i)": [ + "PRI-01.11" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "Article 126(1)": [ + "PRI-01.11" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "Article 126(2)": [ + "PRI-01.11" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "Article 126(3)": [ + "PRI-01.11" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "Article 126(4)": [ + "PRI-01.11" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "Article 2-d(2)": [ + "PRI-02" ], - "SR-01": [ - "GOV-02", - "GOV-03", - "TPM-01" + "Article 77(1)(a)": [ + "PRI-02" ], - "PM-02": [ - "GOV-04" + "Article 77(1)(b)": [ + "PRI-02" ], - "PM-02-SID": [ - "GOV-04" + "Article 78(1)": [ + "PRI-02" ], - "PM-06": [ - "GOV-04", - "GOV-05" + "Article 78(2)": [ + "PRI-02" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "Article 78(3)": [ + "PRI-02" ], - "PM-15": [ - "GOV-07", - "THR-01" + "Article 132-c(1)": [ + "PRI-02" ], - "PL-01-SID": [ - "GOV-17" + "Article 2-d(1)": [ + "PRI-03.3" ], - "PM-05": [ - "AST-01", - "AST-02" + "Article 82(2)(a)": [ + "PRI-03.6" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "Article 99(1)": [ + "PRI-03.9" ], - "PM-05-SID": [ - "AST-02" + "Article 99(3)": [ + "PRI-05", + "PRI-05.1" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "Article 105(1)": [ + "PRI-05.1" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "Article 105(2)": [ + "PRI-05.1" ], - "SR-12": [ - "AST-09" + "Article 105(3)": [ + "PRI-05.1" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "Article 105(4)": [ + "PRI-05.1" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "Article 2-f(1)": [ + "PRI-05.4" ], - "CP-02-SID": [ - "BCD-01.7" + "Article 2-g(1)": [ + "PRI-05.4" ], - "CP-03": [ - "BCD-03" + "Article 101(1)": [ + "PRI-05.4" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "Article 101(2)": [ + "PRI-05.4" ], - "CP-04-SID": [ - "BCD-04" + "Article 101(3)": [ + "PRI-05.4" ], - "CP-06": [ - "BCD-08" + "Article 122(1)": [ + "PRI-05.4" ], - "CP-07": [ - "BCD-09" + "Article 110(2)": [ + "PRI-14" + ] + }, + "emea-ken-pda-2019": { + "IV.31(5)": [ + "GOV-17" ], - "CP-08": [ - "BCD-10" + "IV.37(1)": [ + "CPL-01" ], - "CP-11": [ - "BCD-10" + "IV.37(1)(a)": [ + "CPL-01" ], - "CP-06-SID": [ - "BCD-11" + "IV.37(1)(b)": [ + "CPL-01" ], - "CP-09": [ - "BCD-11" + "IV.37(2)": [ + "CPL-01" ], - "CP-09(3)": [ - "BCD-11.2" + "IV.37(3)": [ + "CPL-01" ], - "CP-09(2)": [ - "BCD-11.5" + "IV.32(1)": [ + "CPL-01.3" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "IV.39(2)": [ + "DCH-23", + "PRI-05" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "IV.25(h)": [ + "DCH-25", + "PRI-01.5", + "PRI-07", + "PRI-07.1" ], - "CM-03-SID": [ - "CHG-02" + "IV.43(1)(b)": [ + "IRO-10" ], - "CM-04": [ - "CHG-03" + "IV.43(2)": [ + "IRO-10" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "IV.43(3)": [ + "IRO-10" ], - "AC-05": [ - "CHG-04.3", - "HRS-11", - "NET-12", - "TDA-18" + "IV.43(4)": [ + "IRO-10" ], - "AT-02-SID": [ - "CPL-01" + "IV.43(5)": [ + "IRO-10" + ], + "IV.43(5)(a)": [ + "IRO-10" ], - "AT-03-SID": [ - "CPL-01" + "IV.43(5)(b)": [ + "IRO-10" ], - "CA-07": [ - "CPL-02" + "IV.43(5)(c)": [ + "IRO-10" ], - "PM-14": [ - "CPL-02", - "PRI-08" + "IV.43(5)(d)": [ + "IRO-10" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "IV.43(5)(e)": [ + "IRO-10" ], - "CA-02-SID": [ - "CPL-03" + "IV.43(6)": [ + "IRO-10" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "IV.43(7)": [ + "IRO-10" ], - "AC-07-SID.3": [ - "CFG-02" + "IV.43(8)": [ + "IRO-10" ], - "AC-07-SID.3.a": [ - "CFG-02" + "IV.43(8)(a)": [ + "IRO-10" ], - "AC-07-SID.3.b": [ - "CFG-02" + "IV.43(8)(b)": [ + "IRO-10" ], - "AC-07-SID.3.c": [ - "CFG-02" + "IV.43(8)(c)": [ + "IRO-10" ], - "AC-07-SID.3.d": [ - "CFG-02" + "IV.43(1)(a)": [ + "IRO-10.2" ], - "AC-07-SID.3.e": [ - "CFG-02" + "IV.25": [ + "PRI-01" ], - "AC-07-SID.3.f": [ - "CFG-02" + "III.24(1)": [ + "PRI-01.4" ], - "AC-07-SID.3.g": [ - "CFG-02" + "III.24(1)(a)": [ + "PRI-01.4" ], - "AC-18-SID.1": [ - "CFG-02" + "III.24(1)(b)": [ + "PRI-01.4" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "III.24(1)(c)": [ + "PRI-01.4" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "III.24(2)": [ + "PRI-01.4" ], - "PL-10": [ - "CFG-02" + "III.24(3)": [ + "PRI-01.4" ], - "PL-10-SID": [ - "CFG-02" + "III.24(4)": [ + "PRI-01.4" ], - "PL-10-SID.1": [ - "CFG-02" + "III.24(5)": [ + "PRI-01.4" ], - "PL-10-SID.2": [ - "CFG-02" + "III.24(6)": [ + "PRI-01.4" ], - "SA-08": [ - "CFG-02", - "SEA-01" + "III.24(7)": [ + "PRI-01.4" ], - "PL-11": [ - "CFG-02.9" + "III.24(7)(a)": [ + "PRI-01.4" ], - "PL-11-SID": [ - "CFG-02.9" + "III.24(7)(b)": [ + "PRI-01.4" ], - "PL-11-SID.1": [ - "CFG-02.9" + "III.24(7)(c)": [ + "PRI-01.4" ], - "PL-11-SID.2": [ - "CFG-02.9" + "III.24(7)(d)": [ + "PRI-01.4" ], - "CM-07": [ - "CFG-03" + "III.24(7)(e)": [ + "PRI-01.4" ], - "CM-10": [ - "CFG-04" + "VI.49(1)": [ + "PRI-01.5" ], - "CM-11": [ - "CFG-05", - "END-03" + "VI.49(2)": [ + "PRI-01.5" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "VI.49(3)": [ + "PRI-01.5" ], - "AT-02": [ - "MON-01.8", - "MON-02" + "VI.50": [ + "PRI-01.5" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "IV.41(1)": [ + "PRI-01.6" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "IV.41(1)(a)": [ + "PRI-01.6" ], - "AU-02-SID": [ - "MON-02.7" + "IV.41(1)(b)": [ + "PRI-01.6" ], - "AU-03": [ - "MON-03" + "IV.41(2)": [ + "PRI-01.6" ], - "AU-04": [ - "MON-04" + "IV.41(3)": [ + "PRI-01.6" ], - "AU-05": [ - "MON-05" + "IV.41(3)(a)": [ + "PRI-01.6" ], - "AU-12": [ - "MON-06" + "IV.41(3)(b)": [ + "PRI-01.6" ], - "AU-08": [ - "MON-07", - "SEA-20" + "IV.41(3)(c)": [ + "PRI-01.6" ], - "AU-09": [ - "MON-08" + "IV.41(3)(d)": [ + "PRI-01.6" ], - "AU-11": [ - "MON-10" + "IV.41(3)(e)": [ + "PRI-01.6" ], - "SC-13": [ - "CRY-01", - "CRY-01.2", - "CRY-05" + "IV.41(4)": [ + "PRI-01.6" ], - "SC-13-SID": [ - "CRY-01" + "IV.41(4)(a)": [ + "PRI-01.6" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "IV.41(4)(b)": [ + "PRI-01.6" ], - "SC-08": [ - "CRY-03", - "CRY-04" + "IV.41(4)(c)": [ + "PRI-01.6" ], - "SC-08-SID": [ - "CRY-03" + "IV.41(4)(d)": [ + "PRI-01.6" ], - "AC-18": [ - "CRY-07", - "NET-15" + "IV.41(4)(e)": [ + "PRI-01.6" ], - "SC-12": [ - "CRY-08" + "IV.41(4)(f)": [ + "PRI-01.6" ], - "RA-02-SID": [ - "DCH-02" + "IV.42(1)": [ + "PRI-01.6" ], - "MP-02": [ - "DCH-03", - "END-01" + "IV.42(1)(a)": [ + "PRI-01.6" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "IV.42(1)(b)": [ + "PRI-01.6" ], - "MP-06(1)": [ - "DCH-09.1" + "IV.42(1)(c)": [ + "PRI-01.6" ], - "MP-06(1)-SID": [ - "DCH-09.1" + "IV.42(1)(d)": [ + "PRI-01.6" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "IV.42(2)": [ + "PRI-01.6" ], - "AC-20": [ - "DCH-13" + "IV.42(2)(a)": [ + "PRI-01.6", + "PRI-07.1" ], - "AC-22": [ - "DCH-15" + "IV.42(2)(b)": [ + "PRI-01.6", + "PRI-07.1" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "IV.42(3)": [ + "PRI-01.6", + "PRI-07.1" ], - "PM-22": [ - "DCH-22", - "PRI-10" + "IV.42(4)": [ + "PRI-01.6", + "PRI-07.1" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "IV.25(b)": [ + "PRI-01.11", + "PRI-05.4" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "IV.25(d)": [ + "PRI-01.11" ], - "SI-08": [ - "END-08" + "IV.26": [ + "PRI-01.11" ], - "SC-15": [ - "END-14" + "IV.28(2)": [ + "PRI-01.11" ], - "PS-04-SID": [ - "HRS-01.1" + "IV.28(2)(a)": [ + "PRI-01.11" ], - "PS-05-SID": [ - "HRS-01.1" + "IV.28(2)(b)": [ + "PRI-01.11" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "IV.28(2)(e)": [ + "PRI-01.11" ], - "PS-09": [ - "HRS-03" + "IV.28(2)(f)": [ + "PRI-01.11" ], - "PS-03": [ - "HRS-04" + "IV.28(2)(f)(i)": [ + "PRI-01.11" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "IV.28(2)(f)(ii)": [ + "PRI-01.11" ], - "PL-04(1)": [ - "HRS-05.2" + "IV.28(2)(f)(iii)": [ + "PRI-01.11" ], - "AC-19-SID": [ - "HRS-05.3" + "IV.28(3)": [ + "PRI-01.11", + "PRI-04.1", + "PRI-05.4" ], - "PL-04-SID": [ - "HRS-05.7" + "IV.33(2)": [ + "PRI-01.11", + "PRI-03.13" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "IV.33(3)": [ + "PRI-01.11" ], - "PS-08": [ - "HRS-07" + "IV.33(3)(a)": [ + "PRI-01.11" ], - "PS-05": [ - "HRS-08" + "IV.33(3)(b)": [ + "PRI-01.11" ], - "PS-04": [ - "HRS-09" + "IV.33(3)(c)": [ + "PRI-01.11" ], - "PS-07": [ - "HRS-10" + "IV.33(3)(d)": [ + "PRI-01.11" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "IV.33(3)(e)": [ + "PRI-01.11" ], - "IA-02": [ - "IAC-02" + "IV.34(1)(c)": [ + "PRI-01.11" ], - "IA-08": [ - "IAC-03" + "IV.34(1)(d)": [ + "PRI-01.11" ], - "IA-02(1)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "IV.34(2)(a)": [ + "PRI-01.11" ], - "IA-02(2)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "IV.35(2)": [ + "PRI-01.11" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "IV.35(2)(a)": [ + "PRI-01.11" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "IV.35(2)(b)": [ + "PRI-01.11" ], - "IA-05(1)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "IV.35(2)(c)": [ + "PRI-01.11" ], - "IA-06": [ - "IAC-11" + "IV.25(e)": [ + "PRI-02" ], - "IA-11": [ - "IAC-14" + "IV.26(a)": [ + "PRI-02" ], - "IA-02-SID": [ - "IAC-15" + "IV.29": [ + "PRI-02" ], - "IA-08-SID": [ - "IAC-15" + "IV.29(a)": [ + "PRI-02" ], - "AC-02(3)": [ - "IAC-15.3" + "IV.29(b)": [ + "PRI-02" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "IV.29(c)": [ + "PRI-02" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "IV.29(d)": [ + "PRI-02" ], - "AC-06-SID": [ - "IAC-21" + "IV.29(e)": [ + "PRI-02" ], - "AC-07": [ - "IAC-22" + "IV.29(f)": [ + "PRI-02" ], - "AC-07-SID.1": [ - "IAC-22" + "IV.29(g)": [ + "PRI-02" ], - "AC-07-SID.2": [ - "IAC-22" + "IV.29(h)": [ + "PRI-02" ], - "AC-14": [ - "IAC-26" + "IV.35(1)": [ + "PRI-02.2", + "PRI-19", + "PRI-19.2" ], - "IR-04": [ - "IRO-02" + "IV.26(c)": [ + "PRI-03", + "PRI-03.4" ], - "IR-08-SID": [ - "IRO-02.4" + "IV.28(2)(c)": [ + "PRI-03" ], - "IR-08": [ - "IRO-04" + "IV.32(4)": [ + "PRI-03", + "PRI-03.5" ], - "IR-01-SID": [ - "IRO-04.2" + "IV.36": [ + "PRI-03.3", + "PRI-05.4" ], - "IR-02": [ - "IRO-05" + "IV.32(2)": [ + "PRI-03.4" ], - "IR-02-SID": [ - "IRO-05" + "IV.32(3)": [ + "PRI-03.4" ], - "IR-03": [ - "IRO-06" + "IV.27(a)": [ + "PRI-03.6", + "PRI-03.13", + "PRI-04" ], - "IR-05": [ - "IRO-09" + "IV.27(b)": [ + "PRI-03.6" ], - "IR-06-SID": [ - "IRO-10" + "IV.27(c)": [ + "PRI-03.6" ], - "IR-07": [ - "IRO-11" + "IV.28(2)(d)": [ + "PRI-03.6", + "PRI-03.13" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "IV.28(1)": [ + "PRI-03.7", + "PRI-04.2" ], - "PM-10": [ - "IAO-01" + "IV.33(4)": [ + "PRI-03.13" ], - "AC-20-SID": [ - "IAO-03.2" + "IV.25(c)": [ + "PRI-04" ], - "SA-04-SID": [ - "IAO-03.2" + "IV.25(a)": [ + "PRI-04.1", + "PRI-05.4" ], - "SA-09-SID": [ - "IAO-03.2" + "IV.25(g)": [ + "PRI-05" ], - "CA-05": [ - "IAO-05" + "IV.34(1)(b)": [ + "PRI-05" ], - "PM-04": [ - "IAO-05", - "VPM-02" + "IV.34(3)": [ + "PRI-05" ], - "CA-06": [ - "IAO-07" + "IV.39(1)": [ + "PRI-05" ], - "CA-06-SID": [ - "IAO-07" + "IV.39(1)(a)": [ + "PRI-05" ], - "MA-02": [ - "MNT-02" + "IV.39(1)(b)": [ + "PRI-05" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "IV.39(1)(c)": [ + "PRI-05" ], - "MA-05": [ - "MNT-06" + "IV.39(1)(d)": [ + "PRI-05" ], - "AC-19": [ - "MDM-02" + "IV.30(1)(b)(viii)": [ + "PRI-05.1" ], - "SC-07": [ - "NET-03" + "IV.25(f)": [ + "PRI-05.2", + "PRI-06.1" ], - "CA-03": [ - "NET-05" + "IV.30(1)": [ + "PRI-05.4" ], - "CA-03-SID": [ - "NET-05" + "IV.30(1)(a)": [ + "PRI-05.4" ], - "CA-09": [ - "NET-05.2" + "IV.30(1)(b)": [ + "PRI-05.4" ], - "SC-20": [ - "NET-10" + "IV.30(1)(b)(i)": [ + "PRI-05.4" ], - "SC-22": [ - "NET-10.1" + "IV.30(1)(b)(ii)": [ + "PRI-05.4" ], - "SC-21": [ - "NET-10.2" + "IV.30(1)(b)(iii)": [ + "PRI-05.4" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "IV.30(1)(b)(iv)": [ + "PRI-05.4" ], - "SI-10": [ - "NET-12", - "TDA-18" + "IV.30(1)(b)(v)": [ + "PRI-05.4" ], - "AC-17": [ - "NET-14" + "IV.30(1)(b)(vi)": [ + "PRI-05.4" ], - "AC-18-SID.2": [ - "NET-15.1" + "IV.30(1)(b)(vii)": [ + "PRI-05.4" ], - "AC-18-SID.3": [ - "NET-15.5" + "IV.30(2)": [ + "PRI-05.4" ], - "PE-02": [ - "PES-02" + "IV.33(1)": [ + "PRI-05.4" ], - "PE-03": [ - "PES-03" + "IV.33(1)(a)": [ + "PRI-05.4" ], - "PE-08": [ - "PES-03.3" + "IV.33(1)(b)": [ + "PRI-05.4" ], - "PE-06": [ - "PES-05" + "V.45": [ + "PRI-05.4" ], - "PE-12": [ - "PES-07.4" + "V.45(a)": [ + "PRI-05.4" ], - "PE-15": [ - "PES-07.5" + "V.45(a)(i)": [ + "PRI-05.4" ], - "PE-13": [ - "PES-08" + "V.45(a)(ii)": [ + "PRI-05.4" ], - "PE-14": [ - "PES-09" + "V.45(b)": [ + "PRI-05.4" ], - "PE-16": [ - "PES-10" + "V.45(c)": [ + "PRI-05.4" ], - "PE-17": [ - "PES-11" + "V.45(c)(i)": [ + "PRI-05.4" ], - "PM-05(1)": [ - "PRI-05.5", - "PRI-05.6" + "V.45(c)(ii)": [ + "PRI-05.4" ], - "PM-03": [ - "PRM-02" + "V.45(c)(iii)": [ + "PRI-05.4" ], - "SA-02": [ - "PRM-03" + "V.46(1)": [ + "PRI-05.4" ], - "PM-11": [ - "PRM-06" + "V.46(1)(a)": [ + "PRI-05.4" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "V.46(1)(b)": [ + "PRI-05.4" ], - "PM-09": [ - "RSK-01" + "V.46(2)(a)": [ + "PRI-05.4" ], - "RA-02": [ - "RSK-02" + "V.46(2)(b)": [ + "PRI-05.4" ], - "RA-03-SID": [ - "RSK-04" + "IV.26(b)": [ + "PRI-06" ], - "RA-07": [ - "RSK-06.1" + "IV.27": [ + "PRI-06" ], - "SR-02": [ - "RSK-09", - "TPM-03" + "IV.34(1)": [ + "PRI-06" ], - "RA-03(1)": [ - "RSK-09.1" + "IV.35(3)(b)(i)": [ + "PRI-06" ], - "CA-07(4)": [ - "RSK-11" + "IV.35(3)(b)(ii)": [ + "PRI-06" ], - "PM-07": [ - "SEA-02" + "IV.38(1)": [ + "PRI-06", + "PRI-06.6", + "PRI-06.7" ], - "SC-39": [ - "SEA-04" + "IV.38(2)": [ + "PRI-06", + "PRI-06.6", + "PRI-06.7" ], - "AC-08": [ - "SEA-18" + "IV.38(3)": [ + "PRI-06", + "PRI-06.6" ], - "AT-03": [ - "SAT-03" + "IV.40(1)": [ + "PRI-06" ], - "PE-01-SID": [ - "SAT-03" + "IV.40(1)(a)": [ + "PRI-06", + "PRI-06.1" ], - "AT-04": [ - "SAT-04" + "IV.40(1)(b)": [ + "PRI-06", + "PRI-06.5" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "IV.26(d)": [ + "PRI-06.1" ], - "SA-11": [ - "TDA-09" + "IV.34(1)(a)": [ + "PRI-06.1" ], - "SA-10": [ - "TDA-14" + "IV.35(4)(a)": [ + "PRI-06.4" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "IV.35(4)(b)": [ + "PRI-06.4" ], - "SR-05": [ - "TPM-03.1" + "IV.35(4)(c)": [ + "PRI-06.4" ], - "SR-03": [ - "TPM-03.3" + "IV.35(4)(c)(i)": [ + "PRI-06.4" ], - "SA-09": [ - "TPM-04" + "IV.35(4)(c)(ii)": [ + "PRI-06.4" ], - "SR-08": [ - "TPM-05.1" + "IV.38(4)": [ + "PRI-06.4" ], - "PM-16": [ - "THR-01" + "IV.26(e)": [ + "PRI-06.5" ], - "AT-02(2)": [ - "THR-05" + "IV.40(3)": [ + "PRI-06.5", + "PRI-07.1", + "PRI-07.3" ], - "RA-05(11)": [ - "THR-06" + "IV.40(2)(a)": [ + "PRI-07.1" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "IV.40(2)(b)": [ + "PRI-07.1" ], - "RA-05-SID": [ - "VPM-06" + "IV.40(2)": [ + "PRI-07.3" ], - "RA-05(2)": [ - "VPM-06.1" + "IV.34(2)(b)": [ + "PRI-17" ], - "CA-08": [ - "VPM-07" + "IV.35(3)(a)": [ + "PRI-17", + "PRI-19.1" ], - "CA-08-SID": [ - "VPM-07" - ] - }, - "usa-state-tx-sb820-2019": { - "11.175(b)": [ - "GOV-02" + "IV.31(1)": [ + "RSK-10" ], - "11.175(b)(1)": [ - "GOV-02" + "IV.31(2)": [ + "RSK-10" ], - "11.175(b)(2)": [ - "GOV-02" + "IV.31(2)(a)": [ + "RSK-10" ], - "11.175(d)": [ - "GOV-04" + "IV.31(2)(b)": [ + "RSK-10" ], - "11.175(c)": [ - "CPL-01" + "IV.31(2)(c)": [ + "RSK-10" ], - "11.175(e)": [ - "IRO-10" + "IV.31(2)(d)": [ + "RSK-10" ], - "11.175(f)": [ - "IRO-10" + "IV.31(3)": [ + "RSK-10" ] }, - "usa-state-tx-sb2610-2025": { - "542.004(a)(1)": [ - "GOV-01" + "emea-nga-dpr-2019": { + "4.1(6)": [ + "GOV-17" ], - "542.004(a)(4)(A)": [ - "CPL-01" + "4.1(7)": [ + "GOV-17" ], - "542.004(a)(4)(B)": [ + "2.1(2)": [ "CPL-01" ], - "542.004(a)(4)(C)": [ + "2.1(3)": [ "CPL-01" ], - "542.004(b)": [ + "3.1(16)": [ "CPL-01" ], - "542.004(b)(2)": [ + "4.1(1)": [ "CPL-01" ], - "542.004(b)(2)(A)": [ - "CPL-01" + "3.1(4)": [ + "CPL-01.3", + "PRI-07.5" ], - "542.004(b)(2)(B)": [ - "CPL-01" + "4.1(5)": [ + "CPL-01.4" ], - "542.004(b)(2)(C)": [ - "CPL-01" + "4.1(5)a": [ + "CPL-01.4" ], - "542.004(b)(2)(D)": [ - "CPL-01" + "4.1(5)b": [ + "CPL-01.4" ], - "542.004(b)(3)": [ - "CPL-01" + "4.1(5)c": [ + "CPL-01.4" ], - "542.004(c)": [ - "CPL-01" + "4.1(5)d": [ + "CPL-01.4" ], - "542.002": [ - "CPL-01.2" + "4.1(5)e": [ + "CPL-01.4" ], - "542.002(1)": [ - "CPL-01.2" + "4.1(5)f": [ + "CPL-01.4" ], - "542.002(2)": [ - "CPL-01.2" + "4.1(5)g": [ + "CPL-01.4" ], - "542.004(a)(2)": [ - "CPL-01.3" + "4.1(5)h": [ + "CPL-01.4" ], - "542.004(b)(1)": [ - "CPL-01.3" + "4.1(5)i": [ + "CPL-01.4" ], - "542.004(b)(1)(A)": [ - "CPL-01.3" + "4.1(5)j": [ + "CPL-01.4" ], - "542.004(b)(1)(B)": [ - "CPL-01.3" + "2.11": [ + "DCH-25", + "PRI-01.5" ], - "542.004(b)(1)(C)": [ - "CPL-01.3" + "4.1(3)": [ + "PRI-01" ], - "542.004(b)(1)(D)": [ - "CPL-01.3" + "4.1(2)": [ + "PRI-01.4" ], - "542.004(b)(1)(E)": [ - "CPL-01.3" + "2.11(a)": [ + "PRI-01.5" ], - "542.004(b)(1)(F)": [ - "CPL-01.3" + "2.11(b)": [ + "PRI-01.5" ], - "542.004(b)(1)(G)": [ - "CPL-01.3" + "2.11(c)": [ + "PRI-01.5" ], - "542.004(b)(1)(H)": [ - "CPL-01.3" + "2.11(d)": [ + "PRI-01.5" ], - "542.004(b)(1)(I)": [ - "CPL-01.3" + "2.11(e)": [ + "PRI-01.5" ], - "542.004(b)(1)(J)": [ - "CPL-01.3" + "2.12": [ + "PRI-01.5" ], - "542.004(a)(3)(A)": [ - "DCH-01.2" + "2.1(1)(d)": [ + "PRI-01.6" ], - "542.004(a)(3)(B)": [ - "DCH-01.2" + "2.6": [ + "PRI-01.6", + "PRI-01.11" ], - "542.004(a)(3)(C)": [ - "DCH-01.2" + "2.4(a)": [ + "PRI-01.11" ], - "542.001(1)": [ - "SEA-02.1" + "2.4(b)": [ + "PRI-01.11" ], - "542.001(2)": [ - "SEA-02.1" + "2.8": [ + "PRI-01.11" ], - "542.001(3)": [ - "SEA-02.1" - ] - }, - "usa-state-tx-txramp-2-0-level-1": { - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "2.9": [ + "PRI-01.11" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "2.12(b)": [ + "PRI-01.11" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "2.12(c)": [ + "PRI-01.11" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "2.12(d)": [ + "PRI-01.11" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "2.12(e)": [ + "PRI-01.11" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "2.12(f)": [ + "PRI-01.11" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "3.1(3)": [ + "PRI-01.11" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "3.1(3)(a)": [ + "PRI-01.11" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "2.3(1)": [ + "PRI-02", + "PRI-02.1", + "PRI-04.1" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "2.5": [ + "PRI-02" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "2.5(a)": [ + "PRI-02" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "2.5(b)": [ + "PRI-02" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "2.5(c)": [ + "PRI-02" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "2.5(d)": [ + "PRI-02" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01", - "TDA-06" + "2.5(e)": [ + "PRI-02" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "2.5(f)": [ + "PRI-02" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "2.5(g)": [ + "PRI-02" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "2.5(h)": [ + "PRI-02" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "2.5(i)": [ + "PRI-02" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "3.1(1)": [ + "PRI-02" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "3.1(7)": [ + "PRI-02" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "3.1(7)(a)": [ + "PRI-02" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "3.1(7)(b)": [ + "PRI-02" ], - "CP-03": [ - "BCD-03" + "3.1(7)(c)": [ + "PRI-02" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "3.1(7)(d)": [ + "PRI-02" ], - "CP-09": [ - "BCD-11" + "3.1(7)(e)": [ + "PRI-02" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "3.1(7)(f)": [ + "PRI-02" ], - "CM-04": [ - "CHG-03" + "3.1(7)(g)": [ + "PRI-02" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "3.1(7)(h)": [ + "PRI-02" ], - "CA-07": [ - "CPL-02" + "3.1(7)(i)": [ + "PRI-02" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "3.1(7)(j)": [ + "PRI-02" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "3.1(7)(k)": [ + "PRI-02" ], - "CM-02": [ - "CFG-02", - "CFG-02.1" + "3.1(7)(l)": [ + "PRI-02" ], - "CM-06": [ - "CFG-02", - "CFG-02.7" + "3.1(7)(m)": [ + "PRI-02" ], - "CM-07": [ - "CFG-03" + "3.1(7)(n)": [ + "PRI-02" ], - "CM-10": [ - "CFG-04" + "3.1(8)": [ + "PRI-02", + "PRI-14", + "PRI-14.1", + "PRI-14.2" ], - "CM-11": [ - "CFG-05", - "END-03" + "2.3(2)": [ + "PRI-03" ], - "SI-04": [ - "MON-01", - "MON-02", - "NET-12", - "TDA-18" + "2.3(2)(a)": [ + "PRI-03" ], - "AU-02": [ - "MON-01.8", - "MON-02" + "2.3(2)(b)": [ + "PRI-03" + ], + "2.3(2)(c)": [ + "PRI-03" + ], + "2.3(2)(d)": [ + "PRI-03" + ], + "2.3(2)(e)": [ + "PRI-03" + ], + "2.8(b)": [ + "PRI-03" + ], + "2.12(a)": [ + "PRI-03", + "PRI-07" + ], + "3.1(14)(a)": [ + "PRI-03" + ], + "3.1(14)(b)": [ + "PRI-03" + ], + "3.1(14)(c)": [ + "PRI-03" ], - "AU-06": [ - "MON-02", - "MON-02.6" + "2.8(a)": [ + "PRI-03.4", + "PRI-06" ], - "AU-03": [ - "MON-03" + "3.1(9)(b)": [ + "PRI-03.4", + "PRI-06" ], - "AU-04": [ - "MON-04" + "3.1(9)(a)": [ + "PRI-05", + "PRI-06" ], - "AU-05": [ - "MON-05" + "2.1(1)(a)": [ + "PRI-05.4" ], - "AU-12": [ - "MON-06" + "2.1(1)(a)(i)": [ + "PRI-05.4" ], - "AU-08": [ - "MON-07", - "SEA-20" + "2.1(1)(a)(ii)": [ + "PRI-05.4" ], - "AU-09": [ - "MON-08" + "2.1(1)(b)": [ + "PRI-05.4" ], - "AU-11": [ - "MON-10" + "2.1(1)(c)": [ + "PRI-05.4" ], - "IA-07": [ - "CRY-02", - "IAC-12" + "2.2(a)": [ + "PRI-05.4" ], - "AC-18": [ - "CRY-07", - "NET-15" + "2.2(c)": [ + "PRI-05.4" ], - "SC-12": [ - "CRY-08" + "2.2(d)": [ + "PRI-05.4" ], - "MP-02": [ - "DCH-03", - "END-01" + "2.2(e)": [ + "PRI-05.4" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "3.1(12)": [ + "PRI-05.4" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", - "DCH-18" + "3.1(9)": [ + "PRI-06" ], - "AC-20": [ - "DCH-13" + "3.1(9)(c)": [ + "PRI-06" ], - "SI-12": [ - "DCH-18", - "PRI-05" + "3.1(9)(d)": [ + "PRI-06" ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" + "3.1(9)(e)": [ + "PRI-06", + "PRI-06.5" ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" + "3.1(11)": [ + "PRI-06" ], - "PS-02": [ - "HRS-02", - "HRS-03.2" + "3.1(11)(a)": [ + "PRI-06" ], - "PS-03": [ - "HRS-04" + "3.1(11)(b)": [ + "PRI-06" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" + "3.1(11)(c)": [ + "PRI-06" ], - "PS-06": [ - "HRS-06", - "HRS-06.1" + "3.1(11)(d)": [ + "PRI-06" ], - "PS-08": [ - "HRS-07" + "3.1(15)": [ + "PRI-06", + "PRI-06.6" ], - "PS-05": [ - "HRS-08" + "3.1(2)": [ + "PRI-06.4", + "PRI-17" ], - "PS-04": [ - "HRS-09" + "3.1(3)(b)": [ + "PRI-06.4" ], - "PS-07": [ - "HRS-10" + "3.1(5)": [ + "PRI-06.4", + "PRI-06.8" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "3.1(13)": [ + "PRI-06.4" ], - "IA-02": [ - "IAC-02" + "3.1(14)": [ + "PRI-06.6", + "PRI-06.7" ], - "IA-08": [ - "IAC-03" + "2.7": [ + "PRI-07.1" ], - "IA-02 (01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "3.1(10)": [ + "PRI-07.3" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "4.1(4)": [ + "PRI-15" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "3.1(6)": [ + "PRI-17" + ] + }, + "emea-nor-pda-2018": { + "8": [ + "PRI-04.1" ], - "IA-05 (01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "9": [ + "PRI-05.4" ], - "IA-06": [ - "IAC-11" + "12": [ + "PRI-05.4" ], - "IA-11": [ - "IAC-14" + "16": [ + "PRI-07.5" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "18": [ + "PRI-01.4" ], - "AC-07": [ - "IAC-22" + "18(a)": [ + "PRI-01.4" ], - "AC-14": [ - "IAC-26" + "18(b)": [ + "PRI-01.4" ], - "IR-04": [ - "IRO-02" + "18(c)": [ + "PRI-01.4" ], - "IR-08": [ - "IRO-04" + "18(d)": [ + "PRI-01.4" + ] + }, + "emea-pol-act-10-2018": { + "Art. 8": [ + "PRI-01.4" ], - "IR-02": [ - "IRO-05" + "Art. 11a": [ + "PRI-01.4" ], - "IR-05": [ - "IRO-09" + "Art. 11": [ + "PRI-02" + ] + }, + "emea-qat-pdppl-2020": { + "3.11.2": [ + "GOV-04.1", + "AST-01.2" ], - "IR-07": [ - "IRO-11" + "3.8": [ + "CPL-01" ], - "CA-05": [ - "IAO-05" + "3.11.7": [ + "CPL-01.4", + "CPL-02" ], - "CA-06": [ - "IAO-07" + "3.11.5": [ + "IRO-01", + "PRI-01" ], - "MA-02": [ - "MNT-02" + "3.14": [ + "IRO-10.2" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "3.11": [ + "PRI-01" ], - "MA-05": [ - "MNT-06" + "3.15": [ + "PRI-01.5" ], - "AC-19": [ - "MDM-02" + "3.13": [ + "PRI-01.6", + "PRI-01.11" ], - "SC-07": [ - "NET-03" + "2.4": [ + "PRI-01.11", + "PRI-03", + "PRI-04.1" ], - "CA-03": [ - "NET-05" + "2.6.3": [ + "PRI-01.11" ], - "CA-09": [ - "NET-05.2" + "3.8.1": [ + "PRI-01.11" ], - "SC-20": [ - "NET-10" + "3.8.2": [ + "PRI-01.11" ], - "SC-22": [ - "NET-10.1" + "3.8.3": [ + "PRI-01.11" ], - "SC-21": [ - "NET-10.2" + "3.8.4": [ + "PRI-01.11" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "3.10": [ + "PRI-01.11", + "PRI-05.4" ], - "AC-17": [ - "NET-14" + "3.11.1": [ + "PRI-01.11", + "PRI-04.1", + "RSK-10" ], - "PE-02": [ - "PES-02" + "3.11.6": [ + "PRI-01.11", + "PRI-06" ], - "PE-03": [ - "PES-03" + "4.17.3": [ + "PRI-01.11", + "PRI-06.8" ], - "PE-08": [ - "PES-03.3" + "4.17.4": [ + "PRI-01.11", + "PRI-05.4" ], - "PE-06": [ - "PES-05" + "4.17.5": [ + "PRI-01.11" ], - "PE-15": [ - "PES-07.5" + "3.9": [ + "PRI-02" ], - "PE-13": [ - "PES-08" + "3.9.1": [ + "PRI-02" ], - "PE-14": [ - "PES-09" + "3.9.2": [ + "PRI-02" ], - "PE-16": [ - "PES-10" + "3.9.3": [ + "PRI-02" ], - "SA-03": [ - "PRM-07", - "SEA-07.1" + "3.9.4": [ + "PRI-02" ], - "RA-02": [ - "RSK-02" + "4.17.1": [ + "PRI-02" ], - "RA-07": [ - "RSK-06.1" + "2.5.2": [ + "PRI-03", + "PRI-06" ], - "CA-07 (04)": [ - "RSK-11" + "3.12": [ + "PRI-03.3", + "PRI-04", + "PRI-07" ], - "SC-39": [ - "SEA-04" + "2.5.1": [ + "PRI-03.4", + "PRI-06" ], - "AT-02": [ - "SAT-02" + "4.17.2": [ + "PRI-03.13" ], - "AT-03": [ - "SAT-03" + "4.16": [ + "PRI-05.4" ], - "AT-04": [ - "SAT-04" + "4.17": [ + "PRI-05.4" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "2.5.3": [ + "PRI-06", + "PRI-06.5" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "2.5.4": [ + "PRI-06", + "PRI-06.1" ], - "SA-09": [ - "TPM-04" + "2.6": [ + "PRI-06" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "2.6.1": [ + "PRI-06" ], - "RA-05 (02)": [ - "VPM-06.1" - ] - }, - "usa-state-tx-txramp-2-0-level-2": { - "AC-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "2.6.2": [ + "PRI-06", + "PRI-17" ], - "AT-01": [ - "GOV-02", - "GOV-03", - "SAT-01" + "3.11.4": [ + "PRI-06.4", + "PRI-17" ], - "AU-01": [ - "GOV-02", - "GOV-03", - "MON-01" + "3.11.3": [ + "SAT-03", + "SAT-03.3" ], - "CA-01": [ - "GOV-02", - "GOV-03", - "IAO-01" + "3.11.8": [ + "TPM-05", + "TPM-05.6", + "TPM-05.8", + "TPM-08" + ] + }, + "emea-rus-152-fz-2025": { + "Art. 13.1": [ + "DCH-23", + "PRI-05.3" ], - "CM-01": [ - "GOV-02", - "GOV-03", - "CFG-01" + "Art. 22.1": [ + "PRI-01.4" ], - "CP-01": [ - "GOV-02", - "GOV-03", - "BCD-01" + "Art. 12": [ + "PRI-01.5" ], - "IA-01": [ - "GOV-02", - "GOV-03", - "IAC-01" + "Art. 7": [ + "PRI-01.6" ], - "IR-01": [ - "GOV-02", - "GOV-03", - "IRO-01", - "IRO-04.2", - "IRO-13" + "Art. 18.1": [ + "PRI-01.6", + "PRI-01.11" ], - "MA-01": [ - "GOV-02", - "GOV-03", - "MNT-01", - "MNT-05.1", - "MNT-05.2" + "Art. 19": [ + "PRI-01.6" ], - "MP-01": [ - "GOV-02", - "GOV-03", - "DCH-01" + "Art. 5": [ + "PRI-01.11" ], - "PE-01": [ - "GOV-02", - "GOV-03", - "PES-01" + "Art. 6": [ + "PRI-01.11", + "PRI-03" ], - "PL-01": [ - "GOV-02", - "GOV-03", - "CPL-01", - "PRM-01", - "TDA-01" + "Art. 11": [ + "PRI-01.11", + "PRI-05.4" ], - "PS-01": [ - "GOV-02", - "GOV-03", - "HRS-01" + "Art. 18": [ + "PRI-02" ], - "RA-01": [ - "GOV-02", - "GOV-03", - "RSK-01" + "Art. 9": [ + "PRI-03" ], - "SA-01": [ - "GOV-02", - "GOV-03", - "TDA-01" + "Art. 10.1": [ + "PRI-03" ], - "SC-01": [ - "GOV-02", - "GOV-03", - "NET-01", - "SEA-01" + "Art. 10": [ + "PRI-05.4", + "PRI-05.7" ], - "SI-01": [ - "GOV-02", - "GOV-03", - "SEA-01" + "Art. 13": [ + "PRI-05.4" ], - "IR-06": [ - "GOV-06", - "IRO-10", - "IRO-14" + "Art. 14": [ + "PRI-06" ], - "CM-08": [ - "AST-02", - "AST-02.3" + "Art. 15": [ + "PRI-06" ], - "CM-08 (01)": [ - "AST-02.1" + "Art. 20": [ + "PRI-06" ], - "PL-02": [ - "AST-04", - "IAO-03", - "IAO-03.1" + "Art. 17": [ + "PRI-06.3" ], - "SA-04 (01)": [ - "AST-04", - "TDA-04.1" + "Art. 21": [ + "PRI-06.4" ], - "SA-04 (02)": [ - "AST-04", - "TDA-04.1", - "TDA-20" + "Art. 22": [ + "PRI-15" ], - "SA-05": [ - "AST-04.1", - "TDA-04" + "Art. 16": [ + "PRI-19", + "PRI-19.2", + "PRI-19.3" + ] + }, + "emea-sau-cscc-1-2019": { + "1-1-1": [ + "GOV-01", + "GOV-08", + "GOV-14", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "PRM-01.1", + "OPS-02" ], - "CP-02": [ - "BCD-01", - "BCD-06" + "2-1-1": [ + "GOV-15" ], - "CP-10": [ - "BCD-01", - "BCD-01.4", - "BCD-12" + "1-3-1": [ + "AST-01", + "CHG-01", + "IAO-01", + "PRM-01" ], - "CP-03": [ - "BCD-03" + "3-1-1-2": [ + "AST-01.1", + "BCD-02" ], - "CP-04": [ - "BCD-04", - "BCD-05" + "2-1-1-2": [ + "AST-01.2", + "AST-03" ], - "CP-06": [ - "BCD-08" + "2-1-1-1": [ + "AST-02", + "BCD-02" ], - "CP-07": [ - "BCD-09" + "2-6-1-5": [ + "AST-05.1", + "DCH-14.2", + "DCH-17", + "DCH-25", + "NET-02.3" ], - "CP-08": [ - "BCD-10" + "2-3-1-4": [ + "AST-27", + "IAC-20.4", + "NET-06", + "NET-06.3" ], - "CP-09": [ - "BCD-11" + "2-2-1-8": [ + "AST-28", + "MON-03.7", + "IAC-20.2" ], - "CP-09 (01)": [ - "BCD-11.1" + "2-8-1": [ + "BCD-01" ], - "CP-09 (08)": [ - "BCD-11.4" + "3-1-1": [ + "BCD-01" ], - "SC-28 (01)": [ - "BCD-11.4", - "CRY-04", - "CRY-05", - "DCH-07.2" + "3-1-1-1": [ + "BCD-01" ], - "SC-05": [ - "CAP-01", - "CAP-02", - "CAP-03", - "NET-02.1" + "2-8-1-1": [ + "BCD-02", + "BCD-11" ], - "CM-03": [ - "CHG-01", - "CHG-02" + "3-1-1-4": [ + "BCD-03.1", + "BCD-04" ], - "CM-03 (02)": [ - "CHG-02.2", - "CHG-06" + "3-1-1-3": [ + "BCD-04" ], - "CM-03 (04)": [ - "CHG-02.3" + "2-8-1-2": [ + "BCD-11" ], - "CM-04": [ - "CHG-03" + "2-8-1-3": [ + "BCD-11", + "BCD-11.4", + "BCD-11.9", + "BCD-11.10" ], - "CM-05": [ - "CHG-04", - "END-03.2" + "2-8-2": [ + "BCD-11.1", + "BCD-12" ], - "AC-05": [ - "CHG-04.3" + "1-3-2-2": [ + "CHG-04.5", + "TDA-20", + "TDA-20.3" ], - "CM-05 (05)": [ - "CHG-04.4" + "4-2-1": [ + "CLD-01" ], - "CM-09": [ - "CHG-05", - "CFG-01" + "1-3-2-3": [ + "CLD-04", + "CFG-02", + "TDA-06" ], - "SA-09 (05)": [ + "4-2-1-1": [ "CLD-09", - "DCH-19", - "TPM-04.4" + "DCH-26" ], - "CA-07": [ + "1-4-1": [ "CPL-02" ], - "CA-02": [ - "CPL-03", - "CPL-03.2", - "IAO-02", - "IAO-06", - "PRM-04" + "1-4-2": [ + "CPL-02.1", + "CPL-03.1" ], - "RA-03": [ - "CPL-03.2", - "RSK-04" + "2-3-1-6": [ + "CFG-01", + "CFG-02", + "CFG-02.1", + "CFG-02.2" ], - "CM-02": [ + "2-2-1-5": [ "CFG-02", - "CFG-02.1" + "IAC-10.1" ], - "CM-06": [ + "2-2-1-6": [ "CFG-02", - "CFG-02.7" + "IAC-10.5", + "IAC-10.11" ], - "SA-08": [ + "2-3-1-7": [ "CFG-02", - "SEA-01" + "IAC-10.8" ], - "CM-02 (03)": [ - "CFG-02.3" + "2-4-1-3": [ + "CFG-02", + "NET-06.5", + "NET-18.1" ], - "CM-07": [ - "CFG-03" + "2-12-1": [ + "CFG-02", + "WEB-01" ], - "CM-07 (01)": [ - "CFG-03.1" + "2-4-1-2": [ + "CFG-02.1", + "NET-04.6" ], - "CM-07 (02)": [ - "CFG-03.2", - "SEA-06" + "2-6-1-3": [ + "CFG-02.5", + "DCH-01", + "DCH-01.2", + "DCH-01.4", + "DCH-03.1" ], - "CM-07 (05)": [ + "2-3-1-1": [ "CFG-03.3" ], - "CM-10": [ - "CFG-04" - ], - "CM-11": [ - "CFG-05", - "END-03" + "2-11-1": [ + "MON-01" ], - "SI-04": [ - "MON-01", + "2-11-1-3": [ + "MON-01.2", "MON-02", - "NET-12", - "TDA-18" - ], - "SI-04 (04)": [ - "MON-01.3" - ], - "AU-02": [ - "MON-01.8", - "MON-02" + "MON-02.1", + "MON-02.2", + "MON-03.2" ], - "AU-06": [ + "2-11-1-4": [ + "MON-01.2", "MON-02", - "MON-02.6" - ], - "AU-03": [ - "MON-03" - ], - "AU-03 (01)": [ - "MON-03.1" + "MON-02.1" ], - "AU-04": [ - "MON-04" + "2-11-1-1": [ + "MON-01.4" ], - "AU-05": [ - "MON-05" + "2-11-1-2": [ + "MON-01.8" ], - "AU-12": [ - "MON-06" + "2-11-1-5": [ + "MON-03", + "MON-08", + "MON-08.1" ], - "AU-09": [ - "MON-07", + "2-3-1-8": [ "MON-08" ], - "AU-11": [ - "MON-10" - ], - "AC-02 (12)": [ - "MON-16" + "2-11-2": [ + "MON-08", + "MON-08.1", + "MON-10", + "DCH-18" ], - "SC-08 (01)": [ - "CRY-01", - "CRY-01.1", - "CRY-03" + "2-7-1": [ + "CRY-01" ], - "SC-13": [ + "2-7-1-3": [ "CRY-01", - "CRY-01.2", - "CRY-05" - ], - "IA-07": [ - "CRY-02", - "IAC-12" + "CRY-01.5" ], - "SC-08": [ + "2-3-1-5": [ "CRY-03", - "CRY-04" - ], - "SC-28": [ - "CRY-05", - "END-02" - ], - "AC-18": [ - "CRY-07", + "CRY-04", + "NET-01", "NET-15" ], - "SC-12": [ - "CRY-08" - ], - "SC-17": [ - "CRY-08" - ], - "MP-02": [ - "DCH-03", - "END-01" + "2-7-1-1": [ + "CRY-03", + "CRY-04" ], - "MP-03": [ - "DCH-04", - "DCH-04.1" + "2-7-1-2": [ + "CRY-05" ], - "MP-04": [ - "DCH-06" + "2-6-1": [ + "DCH-01" ], - "MP-05": [ - "DCH-07" + "2-6-1-1": [ + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-02.1", + "PRI-05.3" ], - "MP-06": [ - "DCH-08", - "DCH-09", - "DCH-09.3" + "2-6-1-2": [ + "DCH-02" ], - "MP-07": [ - "DCH-10", - "DCH-10.2", + "2-6-1-4": [ "DCH-18" ], - "AC-20": [ - "DCH-13" - ], - "AC-20 (01)": [ - "DCH-13.1" - ], - "AC-22": [ - "DCH-15" - ], - "SI-12": [ - "DCH-18", - "PRI-05" - ], - "CM-12": [ - "DCH-24" - ], - "SI-03": [ - "END-04", - "END-04.1", - "END-04.4", - "NET-12", - "TDA-18", - "VPM-01", - "VPM-05" - ], - "SI-02": [ - "END-04.1", - "VPM-01", - "VPM-05" - ], - "SI-07": [ - "END-06", - "NET-12", - "TDA-18" - ], - "SI-07 (01)": [ - "END-06.1" - ], - "SI-07 (07)": [ - "END-06.2" - ], - "SC-18": [ - "END-10" + "2-3-1-2": [ + "END-01", + "END-02" ], - "SC-15": [ - "END-14" + "1-5-1": [ + "HRS-01" ], - "PS-02": [ + "1-5-1-2": [ "HRS-02", - "HRS-03.2" + "HRS-04.3" ], - "PS-03": [ + "1-5-1-1": [ "HRS-04" ], - "PL-04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.3" - ], - "PL-04 (01)": [ - "HRS-05.2" - ], - "PS-06": [ - "HRS-06", - "HRS-06.1" - ], - "PS-08": [ - "HRS-07" - ], - "PS-05": [ - "HRS-08" + "2-2-1": [ + "IAC-01" ], - "PS-04": [ - "HRS-09" + "2-2-1-7": [ + "IAC-05", + "IAC-15", + "IAC-16" ], - "PS-07": [ - "HRS-10" + "2-2-1-3": [ + "IAC-06", + "IAC-06.2" ], - "IA-04": [ - "IAC-01.2", - "IAC-09" + "2-2-1-4": [ + "IAC-06", + "IAC-06.1", + "IAC-06.3" ], - "IA-04 (04)": [ - "IAC-01.2", - "IAC-09.1", - "IAC-09.2" + "2-2-2": [ + "IAC-17" ], - "IA-02": [ - "IAC-02" + "1-3-2": [ + "IAO-01", + "TDA-01" ], - "IA-02 (08)": [ - "IAC-02.2" + "2-13-4": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-05", + "IAO-06", + "IAO-07" ], - "IA-08": [ - "IAC-03" + "1-3-1-1": [ + "IAO-01.1", + "IAO-02", + "IAO-02.2" ], - "IA-03": [ - "IAC-04" + "1-3-1-2": [ + "IAO-02", + "IAO-06" ], - "IA-02 (01)": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3", - "IAC-06.4", - "IAC-10.7", - "TDA-02.2" + "1-3-2-1": [ + "IAO-04", + "TDA-09", + "TDA-09.2", + "TDA-09.3" ], - "AC-02": [ - "IAC-07.2", - "IAC-15", - "NET-12", - "TDA-18" + "2-5-1": [ + "MDM-01" ], - "AC-02 (07)": [ - "IAC-08" + "2-5-1-1": [ + "MDM-02", + "MDM-11" ], - "IA-05": [ - "IAC-10", - "IAC-10.8" + "2-5-1-2": [ + "MDM-03" ], - "IA-05 (01)": [ - "IAC-10", - "IAC-10.1", - "IAC-10.4" + "2-4-1": [ + "NET-01" ], - "IA-05 (02)": [ - "IAC-10.2" + "2-4-1-5": [ + "NET-02", + "NET-03" ], - "IA-05 (06)": [ - "IAC-10.5", - "IAC-18" + "2-4-1-8": [ + "NET-02.1" ], - "IA-05 (07)": [ - "IAC-10.6" + "2-4-1-4": [ + "NET-04", + "NET-04.1", + "NET-15", + "NET-15.2" ], - "IA-06": [ - "IAC-11" + "2-4-1-6": [ + "NET-04", + "NET-04.1", + "NET-06.3", + "NET-06.5" ], - "IA-11": [ - "IAC-14" + "2-4-1-7": [ + "NET-04", + "NET-04.1", + "NET-06.3" ], - "AC-02 (03)": [ - "IAC-15.3" + "2-4-1-9": [ + "NET-04", + "NET-04.1" ], - "AC-02 (09)": [ - "IAC-15.5" + "2-4-1-1": [ + "NET-06" ], - "AC-06 (07)": [ - "IAC-17" + "2-2-1-1": [ + "NET-14", + "NET-14.5" ], - "AC-03": [ - "IAC-20", - "NET-12", - "TDA-18" + "2-2-1-2": [ + "NET-14", + "NET-14.1", + "NET-14.5" ], - "AC-06": [ - "IAC-20", - "IAC-21" + "2-13-1": [ + "PRM-01", + "PRM-05", + "PRM-07", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-06" ], - "AC-06 (01)": [ - "IAC-21.1" + "2-13-2": [ + "PRM-04", + "PRM-05", + "TDA-01.1", + "TDA-02", + "TDA-06" ], - "AC-06 (02)": [ - "IAC-21.2" + "1-2-1": [ + "RSK-01", + "RSK-04.2" ], - "AC-06 (05)": [ - "IAC-21.3" + "1-2-1-1": [ + "RSK-04" ], - "AC-06 (09)": [ - "IAC-21.4" + "1-2-1-2": [ + "RSK-04.1" ], - "AC-06 (10)": [ - "IAC-21.5" + "2-12-2": [ + "SEA-02", + "WEB-07" ], - "AC-07": [ - "IAC-22" + "2-13-3": [ + "TDA-02" ], - "AC-02 (05)": [ - "IAC-24" + "2-13-3-1": [ + "TDA-02" ], - "AC-11": [ - "IAC-24" + "2-13-3-2": [ + "TDA-02" ], - "AC-12": [ - "IAC-25" + "2-13-3-3": [ + "TDA-02" ], - "AC-14": [ - "IAC-26" + "2-13-3-4": [ + "TDA-02" ], - "IR-04": [ - "IRO-02" + "1-3-2-4": [ + "TDA-07", + "TDA-08", + "TDA-08.1" ], - "IR-08": [ - "IRO-04" + "4-1-1": [ + "TPM-01" ], - "IR-02": [ - "IRO-05" + "4-1-1-1": [ + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-04", + "TPM-04.1", + "TPM-05" ], - "IR-03": [ - "IRO-06" + "4-1-1-2": [ + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-04", + "TPM-04.1", + "TPM-05" ], - "IR-03 (02)": [ - "IRO-06.1" + "2-3-1-3": [ + "VPM-01", + "VPM-05" ], - "IR-05": [ - "IRO-09" + "2-9-1": [ + "VPM-01" ], - "IR-07": [ - "IRO-11" + "2-9-2": [ + "VPM-01", + "VPM-06", + "VPM-06.2" ], - "IR-09": [ - "IRO-12", - "IRO-12.1" + "2-10-1-1": [ + "VPM-01.1", + "VPM-07" ], - "CA-05": [ - "IAO-05" + "2-9-1-2": [ + "VPM-02", + "VPM-03" ], - "CM-04 (02)": [ - "IAO-06" + "2-9-1-3": [ + "VPM-04" ], - "CA-06": [ - "IAO-07" + "2-9-1-1": [ + "VPM-06", + "VPM-06.6", + "VPM-06.7" ], - "MA-02": [ - "MNT-02" + "2-10-1": [ + "VPM-07" ], - "MA-06": [ - "MNT-03" + "2-10-1-2": [ + "VPM-07", + "VPM-07.1" ], - "MA-03": [ - "MNT-04" + "2-10-2": [ + "VPM-07" ], - "MA-03 (01)": [ - "MNT-04.1" + "2-12-1-1": [ + "WEB-01", + "WEB-04", + "WEB-06", + "WEB-08", + "WEB-10" ], - "MA-03 (02)": [ - "MNT-04.2" + "2-12-1-2": [ + "WEB-01", + "WEB-07" + ] + }, + "emea-sau-cgiot-2024": { + "1-1-2": [ + "GOV-01", + "EMB-01", + "RSK-03", + "RSK-06" ], - "MA-03 (03)": [ - "MNT-04.3" + "1-1-4": [ + "GOV-01.1", + "GOV-03", + "GOV-05" ], - "MA-04": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2" + "1-2-1": [ + "GOV-02", + "OPS-01.1" ], - "MA-05": [ - "MNT-06" + "1-2-3": [ + "GOV-03", + "CPL-01" ], - "AC-19": [ - "MDM-02" + "1-4-6": [ + "GOV-03" ], - "AC-19 (05)": [ - "MDM-03" + "1-8-3": [ + "GOV-03" ], - "SC-07": [ - "NET-03" + "1-1-3": [ + "GOV-05.1" ], - "SC-07 (03)": [ - "NET-03.1" + "1-6-1": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "CPL-01" ], - "SC-07 (04)": [ - "NET-03.2" + "4-1-4": [ + "AST-01.1" ], - "AC-04": [ - "NET-04" + "2-1-1": [ + "AST-02" ], - "SC-07 (05)": [ - "NET-04.1" + "2-1-2": [ + "AST-02.1", + "AST-02.9" ], - "CA-03": [ - "NET-05" + "2-6-2": [ + "AST-08", + "AST-15", + "EMB-06" ], - "CA-09": [ - "NET-05.2" + "2-13-2": [ + "AST-08" ], - "SC-10": [ - "NET-07" + "2-5-1": [ + "AST-09", + "CFG-02", + "EMB-01", + "EMB-02", + "SEA-01" ], - "SC-23": [ - "NET-09" + "2-15-3": [ + "AST-09", + "SEA-07.1" ], - "SC-20": [ - "NET-10" + "2-15-1": [ + "AST-18", + "TDA-02.5" ], - "SC-22": [ - "NET-10.1" + "2-8-1": [ + "BCD-01", + "BCD-11" ], - "SC-21": [ - "NET-10.2" + "2-12-2": [ + "BCD-01", + "BCD-12", + "IRO-02", + "IRO-04", + "IRO-10", + "IRO-13" ], - "SI-05": [ - "NET-12", - "TDA-18", - "THR-03" + "3-1-1": [ + "BCD-01", + "EMB-08" ], - "SI-10": [ - "NET-12", - "TDA-18" + "2-8-2": [ + "BCD-11", + "BCD-11.1" ], - "AC-17": [ - "NET-14" + "2-8-3": [ + "BCD-11.5" ], - "AC-17 (01)": [ - "NET-14.1" + "1-5-3": [ + "CHG-01", + "CHG-02.2", + "CHG-05" ], - "AC-17 (02)": [ - "NET-14.2" + "4-2-1": [ + "CLD-01", + "CLD-02" ], - "AC-17 (03)": [ - "NET-14.3" + "4-2-2": [ + "CLD-02" ], - "AC-17 (04)": [ - "NET-14.4" + "2-6-1": [ + "CPL-01", + "DCH-02", + "PES-16" ], - "AC-17 (09)": [ - "NET-14.8" + "2-7-1": [ + "CPL-01" ], - "PE-02": [ - "PES-02" + "1-7-3": [ + "CPL-01.1", + "CPL-02" ], - "PE-03": [ - "PES-03" + "1-7-1": [ + "CPL-02.2", + "CPL-03.2" ], - "PE-08": [ - "PES-03.3" + "1-7-2": [ + "CPL-03.1" ], - "PE-06": [ - "PES-05" + "1-2-2": [ + "CFG-02" ], - "PE-06 (01)": [ - "PES-05.1" + "2-6-3": [ + "CFG-02", + "END-13.3" ], - "PE-09": [ - "PES-07" + "2-14-2": [ + "CFG-02", + "CFG-03.3" ], - "PE-10": [ - "PES-07.2" + "2-15-2": [ + "CFG-02", + "IAO-01", + "IAO-02" ], - "PE-11": [ - "PES-07.3" + "2-14-4": [ + "CFG-02.1" ], - "PE-12": [ - "PES-07.4" + "2-11-1": [ + "MON-01", + "MON-01.2", + "MON-01.8", + "MON-10" ], - "PE-15": [ - "PES-07.5" + "2-4-1": [ + "CRY-03", + "CRY-04", + "NET-01" ], - "PE-13": [ - "PES-08" + "2-4-2": [ + "CRY-03", + "CRY-04" ], - "PE-14": [ - "PES-09" + "2-4-3": [ + "CRY-03", + "CRY-04" ], - "PE-16": [ - "PES-10" + "2-7-2": [ + "CRY-03", + "CRY-05" ], - "PE-17": [ - "PES-11" + "1-1-1": [ + "EMB-01" ], - "PE-04": [ - "PES-12.1" + "2-4-6": [ + "EMB-01", + "EMB-07", + "VPM-05" ], - "PE-05": [ - "PES-12.2" + "2-14-1": [ + "EMB-04" ], - "SA-03": [ - "PRM-07", - "SEA-07.1", - "TDA-06" + "2-11-2": [ + "EMB-05", + "EMB-09" ], - "RA-02": [ - "RSK-02" + "3-1-2": [ + "EMB-08" ], - "RA-07": [ - "RSK-06.1" + "1-3-2": [ + "HRS-01", + "HRS-03" ], - "CA-07 (04)": [ - "RSK-11" + "1-8-1": [ + "HRS-01", + "HRS-01.1", + "HRS-02", + "HRS-03" ], - "PL-08": [ - "SEA-02" + "1-8-2": [ + "HRS-01.1", + "IAC-15.7", + "IAC-17" ], - "SC-02": [ - "SEA-03.2" + "1-3-1": [ + "HRS-03" ], - "SC-39": [ - "SEA-04" + "2-2-1": [ + "HRS-11", + "IAC-08", + "IAC-16", + "IAC-21" ], - "SC-04": [ - "SEA-05" + "2-2-2": [ + "IAC-10", + "IAC-10.1", + "IAC-10.8", + "IAC-22" ], - "SI-16": [ - "SEA-10" + "2-2-3": [ + "IAC-17" ], - "AU-08": [ - "SEA-20" + "2-12-1": [ + "IRO-04", + "TDA-06.2" ], - "AT-02": [ - "SAT-02" + "2-12-3": [ + "IRO-13" ], - "AT-02 (03)": [ - "SAT-02.2" + "1-5-2": [ + "IAO-01", + "PRM-07" ], - "AT-03": [ - "SAT-03" + "4-1-5": [ + "IAO-01", + "IAO-02" ], - "AT-04": [ - "SAT-04" + "4-2-3": [ + "IAO-01", + "IAO-02" ], - "SA-04": [ - "TDA-01", - "TDA-02", - "TPM-01", - "TPM-10" + "4-2-4": [ + "IAO-02" ], - "SA-04 (09)": [ - "TDA-02.1" + "2-3-1": [ + "NET-01", + "NET-13" ], - "SA-15": [ - "TDA-06" + "2-3-2": [ + "NET-01", + "NET-13" ], - "SA-11": [ - "TDA-09" + "2-4-5": [ + "NET-01", + "NET-03" ], - "SA-10": [ - "TDA-14" + "2-4-4": [ + "NET-06" ], - "SA-10 (01)": [ - "TDA-14.1" + "2-13-1": [ + "PES-05", + "PES-05.1" ], - "SA-22": [ - "TDA-17", - "TDA-17.1" + "1-4-1": [ + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-06" ], - "SI-11": [ - "TDA-19" + "1-4-5": [ + "RSK-01.5", + "RSK-03", + "RSK-06" ], - "SA-09": [ - "TPM-04" + "1-4-2": [ + "RSK-03.1" ], - "SA-09 (02)": [ - "TPM-04.2" + "1-4-4": [ + "RSK-03.1", + "RSK-04", + "THR-09", + "THR-10" ], - "AT-02 (02)": [ - "THR-05" + "1-4-3": [ + "RSK-04.1" ], - "RA-05": [ - "VPM-06", - "VPM-06.1" + "1-5-1": [ + "SEA-01" ], - "RA-05 (02)": [ - "VPM-06.1" + "1-9-1": [ + "SAT-01", + "SAT-02", + "SAT-03" ], - "RA-05 (03)": [ - "VPM-06.2" + "1-9-2": [ + "SAT-02", + "SAT-03.6" ], - "RA-05 (05)": [ - "VPM-06.3" + "4-1-3": [ + "TDA-04.2" ], - "CA-08": [ - "VPM-07" - ] - }, - "usa-state-va-cdpa-2023": { - "59.1-580.C": [ - "GOV-17", - "RSK-10" + "2-14-3": [ + "TDA-06", + "TDA-06.5" ], - "59.1-581.E": [ - "CPL-01", - "PRI-07.1" + "4-1-1": [ + "TPM-05" ], - "59.1-579.B.4": [ - "CPL-01.4", - "PRI-07.1" + "4-2-5": [ + "TPM-05" ], - "59.1-577.A.2": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "4-1-2": [ + "TPM-05.6" ], - "59.1-581.A.1": [ - "DCH-23", - "PRI-05.3" + "4-1-6": [ + "TPM-08", + "TPM-09" ], - "59.1-578.A.3": [ - "PRI-01", - "PRI-01.6" + "2-12-4": [ + "THR-01", + "THR-03", + "THR-03.1" ], - "59.1-581.A.2": [ - "PRI-01.3", - "PRI-02" + "2-9-1": [ + "VPM-01", + "VPM-02", + "VPM-06" ], - "59.1-579.B": [ - "PRI-01.5", - "PRI-07.1" + "2-9-2": [ + "VPM-05" ], - "59.1-579.A.1": [ - "PRI-01.6", - "PRI-01.11", - "PRI-07.1" + "2-10-1": [ + "VPM-07" ], - "59.1-579.B.1": [ - "PRI-01.6" + "2-10-2": [ + "VPM-10" + ] + }, + "emea-sau-ecc-1-2018": { + "1-2-1": [ + "GOV-01" ], - "59.1-577.1.B": [ - "PRI-01.11" + "2-1-1": [ + "GOV-01", + "GOV-02" ], - "59.1-577.1.C": [ - "PRI-01.11", - "PRI-03.3", - "PRI-05.4" + "1-1-1": [ + "GOV-01.1", + "GOV-08", + "PRM-01.1" ], - "59.1-577.1.E": [ - "PRI-01.11", - "PRI-03.5" + "1-2-3": [ + "GOV-01.1", + "PRM-01" ], - "59.1-578.A.4": [ - "PRI-01.11", - "PRI-03.5" + "1-4-1": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "HRS-03" ], - "59.1-578.F.1.d": [ - "PRI-01.11", - "PRI-03.9" + "1-8-3": [ + "GOV-01.2", + "CPL-02", + "CPL-02.1" ], - "59.1-578.F.2": [ - "PRI-01.11", - "PRI-04" + "1-1-3": [ + "GOV-01.3", + "GOV-03", + "PRM-01", + "PRM-01.1", + "PRM-02" ], - "59.1-579.A.2": [ - "PRI-01.11", - "PRI-07.1" + "1-3-4": [ + "GOV-01.3", + "GOV-03", + "OPS-01.1" ], - "59.1-579.A.3": [ - "PRI-01.11", - "PRI-07.1" + "2-3-4": [ + "GOV-01.3" ], - "59.1-578.C": [ - "PRI-02" + "1-3-1": [ + "GOV-02" ], - "59.1-578.C.1": [ - "PRI-02" + "1-3-3": [ + "GOV-02", + "CFG-02" ], - "59.1-578.C.2": [ - "PRI-02", - "PRI-02.1" + "2-1-2": [ + "GOV-02", + "GOV-15" ], - "59.1-578.C.3": [ - "PRI-02" + "2-1-3": [ + "GOV-02", + "HRS-05.1" ], - "59.1-578.C.4": [ - "PRI-02", - "PRI-05.7" + "2-1-4": [ + "GOV-02", + "GOV-15", + "HRS-05.1" ], - "59.1-578.C.5": [ - "PRI-02", - "TPM-01.1" + "2-2-1": [ + "GOV-02", + "IAC-01" ], - "59.1-578.D": [ - "PRI-02", - "PRI-03" + "2-2-2": [ + "GOV-02", + "GOV-15" ], - "59.1-578.E": [ - "PRI-02" + "1-4-2": [ + "GOV-03", + "HRS-01", + "HRS-03" ], - "59.1-578.A.5": [ - "PRI-03", - "PRI-03.6" + "2-1-6": [ + "GOV-03" ], - "59.1-578.F.1": [ - "PRI-03.3", - "PRI-03.12", - "PRI-03.13", - "PRI-04" + "2-4-4": [ + "GOV-03" ], - "59.1-578.F.1.a": [ - "PRI-03.3" + "2-5-4": [ + "GOV-03" ], - "59.1-577.A": [ - "PRI-03.6", - "PRI-03.7", - "PRI-06" + "2-6-4": [ + "GOV-03" ], - "59.1-577.1.D": [ - "PRI-03.6" + "2-7-4": [ + "GOV-03" ], - "59.1-578.F.3": [ - "PRI-03.6" + "2-8-4": [ + "GOV-03" ], - "59.1-577.A.5": [ - "PRI-03.7", - "PRI-21", - "PRI-21.1" + "2-9-4": [ + "GOV-03" ], - "59.1-579.B.2": [ - "PRI-03.10", - "PRI-07.3" + "2-10-4": [ + "GOV-03" ], - "59.1-578.F.1.b": [ - "PRI-03.12", - "PRI-03.13", - "PRI-04.1" + "2-11-4": [ + "GOV-03" ], - "59.1-578.A.1": [ - "PRI-04" + "2-12-4": [ + "GOV-03" ], - "59.1-578.F.1.c": [ - "PRI-04", - "PRI-04.1", - "PRI-05.4" + "2-13-4": [ + "GOV-03" ], - "59.1-578.A.2": [ - "PRI-05.4" + "2-14-4": [ + "GOV-03", + "PES-01" ], - "59.1-577.A.1": [ - "PRI-06" + "2-15-4": [ + "GOV-03", + "WEB-01" ], - "59.1-577.A.3": [ - "PRI-06", - "PRI-06.5" + "3-1-4": [ + "GOV-03" ], - "59.1-577.A.4": [ - "PRI-06", - "PRI-06.6", - "PRI-06.7" + "4-1-4": [ + "GOV-03" ], - "59.1-577.C": [ - "PRI-06.3", - "PRI-06.4" + "4-2-4": [ + "GOV-03" ], - "59.1-577.B.1": [ - "PRI-06.4" + "5-1-4": [ + "GOV-03", + "EMB-01" ], - "59.1-577.B.2": [ - "PRI-06.4", - "PRI-17" + "1-2-2": [ + "GOV-04" ], - "59.1-577.B.3": [ - "PRI-06.4" + "1-9-2": [ + "GOV-14", + "GOV-15", + "HRS-01" ], - "59.1-577.B.4": [ - "PRI-06.4" + "1-3-2": [ + "GOV-15", + "CPL-03" ], - "59.1-578.B": [ - "PRI-07.1" + "1-10-2": [ + "GOV-15", + "SAT-01" ], - "59.1-579.A": [ - "PRI-07.1" + "2-3-2": [ + "GOV-15", + "PES-01" ], - "59.1-579.B.3": [ - "PRI-07.1" + "2-4-2": [ + "GOV-15" ], - "59.1-579.B.5": [ - "PRI-07.1", - "TPM-05", - "TPM-05.2" + "2-5-2": [ + "GOV-15", + "NET-01" ], - "59.1-581.A.3": [ - "PRI-07.1" + "2-6-2": [ + "GOV-15", + "MDM-01" ], - "59.1-577.B.5": [ - "PRI-17.3" + "2-8-2": [ + "GOV-15", + "CRY-01" ], - "59.1-580.A": [ - "RSK-10" + "2-9-2": [ + "GOV-15", + "BCD-01" ], - "59.1-580.A.1": [ - "RSK-10" + "2-10-2": [ + "GOV-15", + "VPM-01" ], - "59.1-580.A.2": [ - "RSK-10" + "2-11-2": [ + "GOV-15", + "VPM-07" ], - "59.1-580.A.3": [ - "RSK-10" + "2-12-2": [ + "GOV-15", + "MON-01" ], - "59.1-580.A.4": [ - "RSK-10" + "2-13-2": [ + "GOV-15", + "IRO-01", + "THR-01" ], - "59.1-580.A.5": [ - "RSK-10" + "2-14-2": [ + "GOV-15", + "PES-01" ], - "59.1-580.B": [ - "RSK-10" + "2-15-2": [ + "GOV-15", + "WEB-01" ], - "59.1-580.D": [ - "RSK-10" + "3-1-2": [ + "GOV-15", + "BCD-01" ], - "59.1-580.E": [ - "RSK-10" + "4-2-2": [ + "GOV-15", + "CLD-01" ], - "59.1-580.F": [ - "RSK-10" + "5-1-2": [ + "GOV-15", + "EMB-01" ], - "59.1-580.G": [ - "RSK-10" + "2-1-5": [ + "AST-04.1", + "DCH-02", + "DCH-04" ], - "59.1-575": [ - "SEA-02.1" - ] - }, - "usa-state-vt-act-171-2018": { - "2447(a)(1)": [ - "GOV-01" + "2-14-3-4": [ + "AST-09" ], - "2447(a)(1)(A)": [ - "GOV-01" + "2-6-1": [ + "AST-16", + "MDM-01" ], - "2447(a)(1)(B)": [ - "GOV-01" + "3-1-1": [ + "BCD-01" ], - "2447(a)(1)(C)": [ - "GOV-01" + "3-1-3-1": [ + "BCD-01" ], - "2447(a)(1)(D)": [ - "GOV-01" + "3-1-3-2": [ + "BCD-01", + "BCD-01.1", + "BCD-01.2" ], - "2447(b)": [ - "GOV-01" + "3-1-3-3": [ + "BCD-01" ], - "2447(c)": [ - "GOV-01" + "2-9-1": [ + "BCD-01.4", + "PRM-05", + "PRM-06" ], - "2447(b)(8)(B)": [ - "GOV-03" + "2-4-3-3": [ + "BCD-11" ], - "2447(b)(9)": [ - "GOV-03" + "2-9-3-1": [ + "BCD-11" ], - "2447(b)(9)(A)": [ - "GOV-03" + "2-9-3-2": [ + "BCD-11" ], - "2447(b)(9)(B)": [ - "GOV-03" + "2-9-3-3": [ + "BCD-11.1" ], - "2447(b)(1)": [ - "GOV-04" + "4-2-1": [ + "CLD-01" ], - "2446(a)(2)": [ - "CPL-01" + "4-2-3-1": [ + "CLD-01", + "CLD-01.1", + "CLD-01.2", + "DCH-02" ], - "2446(a)(3)": [ - "CPL-01" + "4-2-3-2": [ + "CLD-01", + "CLD-02" ], - "2446(a)(3)(A)": [ - "CPL-01" + "4-2-3-3": [ + "CLD-01", + "CLD-09", + "DCH-26" ], - "2446(a)(3)(B)": [ - "CPL-01" + "4-1-3-2": [ + "CLD-09", + "CPL-08", + "DCH-26", + "TPM-01" ], - "2446(a)(3)(B)(i)": [ + "1-7-1": [ "CPL-01" ], - "2446(a)(3)(B)(ii)": [ + "1-7-2": [ "CPL-01" ], - "2446(a)(3)(B)(iii)": [ - "CPL-01" + "1-8-1": [ + "CPL-02", + "CPL-03" ], - "2446(a)(3)(C)": [ - "CPL-01" + "1-8-2": [ + "CPL-03", + "CPL-03.1" ], - "2446(a)(3)(D)": [ - "CPL-01" + "2-2-4": [ + "CPL-03" ], - "2446(a)(3)(E)": [ - "CPL-01" + "2-4-1": [ + "CFG-02" ], - "2446(a)(3)(F)": [ - "CPL-01" + "5-1-3-7": [ + "CFG-02.1", + "CFG-02.2", + "CFG-02.5" ], - "2446(a)(3)(G)": [ - "CPL-01" + "5-1-3-5": [ + "CFG-02.5", + "DCH-10", + "DCH-13.2" ], - "2447(b)(2)(C)": [ - "CPL-02", - "MON-01.8" + "5-1-3-6": [ + "CFG-02.5", + "MDM-06", + "MDM-07" ], - "2447(b)(8)(A)": [ - "CPL-02" + "1-6-3-2": [ + "CFG-09.3", + "TDA-02.3" ], - "2447(c)(4)": [ - "MON-01.8" + "2-12-1": [ + "MON-01" ], - "2447(c)(3)": [ - "CRY-03" + "5-1-3-3": [ + "MON-01", + "MON-01.2", + "EMB-05", + "EMB-09" ], - "2447(c)(5)": [ - "CRY-03" + "2-12-3-3": [ + "MON-01.2" ], - "2447(b)(3)": [ - "DCH-01.2" + "2-12-3-4": [ + "MON-01.2" ], - "2447(c)(6)": [ - "END-02", - "VPM-04.1" + "2-12-3-1": [ + "MON-01.4" ], - "2447(c)(7)": [ - "END-04.1" + "2-12-3-2": [ + "MON-01.4" ], - "2447(b)(5)": [ - "HRS-01.1" + "2-14-3-3": [ + "MON-08", + "MON-10", + "PES-01", + "PES-03.3" ], - "2447(b)(2)(B)": [ - "HRS-05" + "2-12-3-5": [ + "MON-10" ], - "2447(b)(4)": [ - "HRS-07" + "2-8-1": [ + "CRY-01" ], - "2447(c)(1)": [ - "IAC-01" + "2-8-3-1": [ + "CRY-01" ], - "2447(c)(1)(A)": [ - "IAC-01.2" + "2-8-3-3": [ + "CRY-03", + "CRY-05" ], - "2447(c)(1)(B)": [ - "IAC-01.2" + "2-8-3-2": [ + "CRY-09" ], - "2447(c)(2)": [ - "IAC-01.2" + "2-7-1": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2" ], - "2447(c)(2)(A)": [ - "IAC-08" + "2-7-3-1": [ + "DCH-01.1" ], - "2447(c)(2)(B)": [ - "IAC-08" + "2-7-2": [ + "DCH-01.4" ], - "2447(c)(1)(A)(ii)": [ - "IAC-10" + "2-7-3-2": [ + "DCH-02" ], - "2447(c)(1)(A)(iii)": [ - "IAC-10.5" + "2-7-3-3": [ + "DCH-02" ], - "2447(c)(1)(A)(i)": [ - "IAC-15" + "2-3-3-2": [ + "DCH-13.2" ], - "2447(c)(1)(A)(iv)": [ - "IAC-15" + "5-1-1": [ + "EMB-01" ], - "2447(c)(1)(A)(v)": [ - "IAC-22" + "5-1-3-1": [ + "EMB-01", + "NET-06", + "NET-06.3" ], - "2447(b)(10)(A)": [ - "IRO-09.3" + "5-1-3-2": [ + "EMB-01", + "NET-06", + "NET-06.3" ], - "2447(b)(10)(B)": [ - "IRO-13" + "2-3-3-1": [ + "END-04" ], - "2447(b)(7)": [ - "PES-03" + "5-1-3-10": [ + "END-04" ], - "2447(a)(2)": [ - "PRI-01.6", - "PRI-01.11" + "2-4-3-4": [ + "END-06.8" ], - "2433(a)(1)": [ - "PRI-01.11", - "PRI-04" + "2-4-3-1": [ + "END-08" ], - "2433(a)(2)(A)": [ - "PRI-01.11" + "1-9-1": [ + "HRS-01", + "HRS-03", + "HRS-05" ], - "2433(a)(2)(B)": [ - "PRI-01.11" + "1-9-3": [ + "HRS-01" ], - "2433(a)(2)(C)": [ - "PRI-01.11" + "1-9-4": [ + "HRS-01" ], - "2446(a)(1)": [ - "PRI-15" + "1-9-6": [ + "HRS-01" ], - "2447(b)(2)": [ - "RSK-01", - "THR-01" + "1-9-4-1": [ + "HRS-03.1", + "HRS-04.2", + "HRS-05.7" ], - "2447(b)(2)(A)": [ - "SAT-02" + "1-9-3-2": [ + "HRS-04", + "HRS-04.1" ], - "2447(c)(8)": [ - "SAT-03.3" + "1-9-4-2": [ + "HRS-04.2", + "HRS-05.2", + "HRS-05.3", + "HRS-05.4", + "HRS-05.5", + "HRS-05.7" ], - "2447(b)(6)": [ - "TPM-01" + "1-9-3-1": [ + "HRS-05", + "HRS-05.1", + "HRS-06", + "HRS-06.1" ], - "2447(b)(6)(A)": [ - "TPM-04.1" + "2-15-3-4": [ + "HRS-05.1", + "HRS-05.3", + "WEB-01" ], - "2447(b)(6)(B)": [ + "4-1-2-1": [ + "HRS-06.1", "TPM-05" - ] - }, - "emea-eu-ai-act-2024": { - "Article 17.2": [ - "GOV-01", - "GOV-15" ], - "Article 17.1(m)": [ - "GOV-04", - "GOV-04.1" + "2-2-3": [ + "IAC-01" ], - "Article 17.1(e)": [ - "GOV-15.2", - "AAT-01.1", - "AAT-02.2", - "CFG-02" + "2-2-3-1": [ + "IAC-01.2" ], - "Article 16(c)": [ - "GOV-18" + "2-2-3-2": [ + "IAC-06" ], - "Article 17.1": [ - "GOV-18" + "2-4-3-2": [ + "IAC-06" ], - "Article 17.1(c)": [ - "AAT-01" + "2-15-3-5": [ + "IAC-06", + "WEB-01" ], - "Article 9.1": [ - "AAT-02.1", - "RSK-01" + "1-9-5": [ + "IAC-07" ], - "Article 55.1(d)": [ - "AAT-02.3" + "2-2-3-3": [ + "IAC-08" ], - "Article 55.2": [ - "AAT-02.3" + "2-6-3-2": [ + "IAC-08" ], - "Article 8.1": [ - "AAT-03", - "RSK-01", - "TDA-21" + "2-2-3-4": [ + "IAC-16" ], - "Article 9.2(b)": [ - "AAT-04.2", - "AAT-09" + "2-2-3-5": [ + "IAC-17" ], - "Article 9.2(a)": [ - "AAT-07", - "AAT-09" + "2-13-1": [ + "IRO-01", + "THR-01" ], - "Article 27.2": [ - "AAT-07.1", - "AAT-10" + "2-13-3-1": [ + "IRO-01", + "IRO-04" ], - "Article 27.4": [ - "AAT-07.1" + "2-13-3-2": [ + "IRO-02.4" ], - "Article 9.9": [ - "AAT-07.2", - "RSK-01" + "2-13-3-3": [ + "IRO-10", + "IRO-10.2" ], - "Article 13.1": [ - "AAT-09", - "AAT-09.1", - "AAT-20", - "AAT-20.1" + "2-13-3-4": [ + "IRO-10", + "IRO-10.2" ], - "Article 17.1(g)": [ - "AAT-09", - "RSK-01" + "1-6-2": [ + "IAO-01" ], - "Article 6.1": [ - "AAT-09.1" + "2-11-3-1": [ + "IAO-01.1", + "VPM-07" ], - "Article 6.1(a)": [ - "AAT-09.1" + "1-6-2-1": [ + "IAO-02", + "IAO-02.2" ], - "Article 6.3": [ - "AAT-09.1", - "AST-31.2" + "1-6-2-2": [ + "IAO-02", + "IAO-02.2" ], - "Article 51.1": [ - "AAT-09.1" + "1-5-3": [ + "IAO-04", + "RSK-04" ], - "Article 51.1(a)": [ - "AAT-09.1" + "1-6-3-5": [ + "IAO-06" ], - "Article 51.2": [ - "AAT-09.1" + "2-6-3-1": [ + "MDM-03" ], - "Article 9.6": [ - "AAT-10", - "AAT-10.3", - "AAT-10.4", - "AAT-10.5" + "2-6-3-3": [ + "MDM-05" ], - "Article 11.1": [ - "AAT-10", - "AAT-14", - "CPL-01.3", - "IAO-03", - "TDA-04", - "TDA-22" + "2-5-1": [ + "NET-01" ], - "Article 16(f)": [ - "AAT-10", - "CPL-01.4" + "2-5-3-8": [ + "NET-02" ], - "Article 17.1(b)": [ - "AAT-10", - "AAT-20" + "5-1-3-4": [ + "NET-03.7" ], - "Article 17.1(d)": [ - "AAT-10" + "2-5-3-5": [ + "NET-04" ], - "Article 23.1": [ - "AAT-10" + "2-5-3-1": [ + "NET-06" ], - "Article 23.1(a)": [ - "AAT-10" + "2-5-3-2": [ + "NET-06", + "TDA-08" ], - "Article 27.1": [ - "AAT-10" + "2-5-3-6": [ + "NET-08" ], - "Article 27.1(a)": [ - "AAT-10" + "2-5-3-7": [ + "NET-10" ], - "Article 27.1(b)": [ - "AAT-10" + "2-4-3-5": [ + "NET-10.3" ], - "Article 27.1(c)": [ - "AAT-10" + "2-5-3-4": [ + "NET-15", + "NET-15.1" ], - "Article 27.1(d)": [ - "AAT-10" + "2-5-3-3": [ + "NET-18" ], - "Article 27.1(e)": [ - "AAT-10" + "2-3-1": [ + "PES-01" ], - "Article 27.1(f)": [ - "AAT-10" + "2-14-1": [ + "PES-01" ], - "Article 55.1(a)": [ - "AAT-10" + "2-14-3-1": [ + "PES-01" ], - "Article 55.1(b)": [ - "AAT-10" + "2-14-3-2": [ + "PES-01", + "PES-05", + "PES-05.1" ], - "Article 60.1": [ - "AAT-10" + "2-14-3-5": [ + "PES-01", + "PES-04", + "PES-04.1" ], - "Article 60.2": [ - "AAT-10" + "1-1-2": [ + "PRM-01.1" ], - "Article 60.3": [ - "AAT-10" + "1-6-4": [ + "PRM-02.1" ], - "Article 60.4(a)": [ - "AAT-10" + "1-5-2": [ + "PRM-04", + "RSK-01", + "RSK-04.2" ], - "Article 60.4(b)": [ - "AAT-10" + "1-6-1": [ + "PRM-04", + "PRM-05" ], - "Article 60.4(c)": [ - "AAT-10" + "1-5-3-1": [ + "PRM-07" ], - "Article 60.4(d)": [ - "AAT-10" + "1-5-3-2": [ + "PRM-07" ], - "Article 60.4(e)": [ - "AAT-10" + "1-5-3-3": [ + "PRM-07" ], - "Article 60.4(f)": [ - "AAT-10" + "1-5-3-4": [ + "PRM-07" ], - "Article 60.4(g)": [ - "AAT-10" + "1-5-1": [ + "RSK-01", + "RSK-04.2" ], - "Article 60.4(h)": [ - "AAT-10" + "1-5-4": [ + "RSK-01" ], - "Article 60.4(i)": [ - "AAT-10" + "1-6-3-1": [ + "SEA-01", + "TDA-06" ], - "Article 60.4(j)": [ - "AAT-10" + "1-6-3-4": [ + "SEA-01", + "SEA-02", + "TDA-01.1" ], - "Article 60.4(k)": [ - "AAT-10" + "2-15-3-3": [ + "SEA-01", + "WEB-10" ], - "Article 10.2(f)": [ - "AAT-10.8" + "2-15-3-2": [ + "SEA-03", + "WEB-01" ], - "Article 10.2(g)": [ - "AAT-10.8" + "2-3-3-4": [ + "SEA-20" ], - "Article 10.4": [ - "AAT-10.8" + "1-10-1": [ + "SAT-01", + "SAT-02" ], - "Article 10.5": [ - "AAT-10.8", - "PRI-01", - "PRI-05.7" + "2-6-3-4": [ + "SAT-02" ], - "Article 10.5(a)": [ - "AAT-10.8" + "1-10-3-1": [ + "SAT-02.2", + "SAT-03.2" ], - "Article 9.7": [ - "AAT-10.12", - "AAT-24" + "1-10-4-1": [ + "SAT-03" ], - "Article 10.3": [ - "AAT-10.12", - "DCH-18.2", - "DCH-22" + "1-10-4-2": [ + "SAT-03" ], - "Article 17.1(h)": [ - "AAT-10.13", - "AAT-11.2", - "AAT-16" + "1-10-4-3": [ + "SAT-03" ], - "Article 27.3": [ - "AAT-10.15" + "1-10-5": [ + "SAT-03" ], - "Article 60.7": [ - "AAT-10.15", - "AAT-16.9" + "1-10-3-2": [ + "SAT-03.3" ], - "Article 60.8": [ - "AAT-10.15" + "1-10-3-3": [ + "SAT-03.6" ], - "Article 17.1(i)": [ - "AAT-11.4" + "1-10-3-4": [ + "SAT-03.6" ], - "Article 17.1(f)": [ - "AAT-12", - "AAT-12.1", - "AAT-12.2", - "DCH-01", - "DCH-02", - "DCH-22" + "1-6-3-3": [ + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5" ], - "Article 53.1(c)": [ - "AAT-12", - "TDA-21" + "4-1-1": [ + "TPM-01" ], - "Article 53.1(d)": [ - "AAT-12.3" + "4-1-3-1": [ + "TPM-03", + "TPM-04.1" ], - "Article 4": [ - "AAT-13.1" + "4-1-2-2": [ + "TPM-05", + "TPM-05.4", + "TPM-11" ], - "Article 12.2(a)": [ - "AAT-14", - "AAT-16", - "AAT-16.3" + "4-1-2-3": [ + "TPM-05", + "TPM-05.2" ], - "Article 14.2": [ - "AAT-15.2", - "AAT-16", - "AAT-17", - "AAT-22.1" + "2-13-3-5": [ + "THR-01", + "THR-03" ], - "Article 14.4(d)": [ - "AAT-15.2" + "2-10-1": [ + "VPM-01" ], - "Article 14.4(e)": [ - "AAT-15.2" + "5-1-3-8": [ + "VPM-01", + "VPM-01.1", + "VPM-02" ], - "Article 12.1": [ - "AAT-16", - "AAT-16.8", - "MON-01.4" + "2-10-3-2": [ + "VPM-03" ], - "Article 12.2(b)": [ - "AAT-16" + "2-10-3-3": [ + "VPM-03" ], - "Article 12.2(c)": [ - "AAT-16" + "2-3-3-3": [ + "VPM-05" ], - "Article 15.3": [ - "AAT-16", - "AAT-20.2" + "2-10-3-4": [ + "VPM-05" ], - "Article 72.1": [ - "AAT-16" + "5-1-3-9": [ + "VPM-05" ], - "Article 72.2": [ - "AAT-16" + "2-10-3-5": [ + "VPM-05.4" ], - "Article 72.3": [ - "AAT-16" + "2-10-3-1": [ + "VPM-06" ], - "Article 72.4": [ - "AAT-16" + "2-11-1": [ + "VPM-07" ], - "Article 12.2": [ - "AAT-16.8" + "2-11-3-2": [ + "VPM-07" ], - "Article 12.3(a)": [ - "AAT-16.8" + "2-15-1": [ + "WEB-01" ], - "Article 12.3(b)": [ - "AAT-16.8" + "2-15-3": [ + "WEB-01" ], - "Article 12.3(c)": [ - "AAT-16.8" + "2-15-3-1": [ + "WEB-03" + ] + }, + "emea-sau-otcc-1-2022": { + "1-1-2": [ + "GOV-01.4", + "GOV-02" ], - "Article 12.3(d)": [ - "AAT-16.8" + "1-1-1": [ + "GOV-02" ], - "Article 16(e)": [ - "AAT-16.8" + "1-1-3": [ + "GOV-03" ], - "Article 26.6": [ - "AAT-16.8" + "1-4-2": [ + "GOV-05", + "CPL-03", + "PRM-01", + "PRM-02", + "PRM-02.1", + "PRM-03" ], - "Article 55.1(c)": [ - "AAT-16.9" + "1-7-2": [ + "GOV-05", + "CPL-03", + "HRS-01" ], - "Article 73.1": [ - "AAT-16.9" + "2-2-1-4": [ + "AAT-30.2" ], - "Article 73.2": [ - "AAT-16.9" + "2-1-1": [ + "AST-01" ], - "Article 73.3": [ - "AAT-16.9" + "2-1-2": [ + "AST-01", + "CPL-03" ], - "Article 73.4": [ - "AAT-16.9" + "2-1-1-4": [ + "AST-01.2" ], - "Article 73.5": [ - "AAT-16.9" + "2-1-1-1": [ + "AST-02" ], - "Article 73.6": [ - "AAT-16.10" + "2-1-1-2": [ + "AST-02.9" ], - "Article 20.2": [ - "AAT-17.3", - "AAT-18", - "AAT-18.1" + "2-4-1-16": [ + "AST-04" ], - "Article 5.1": [ - "AAT-19" + "2-8-1": [ + "BCD-01" ], - "Article 5.1(a)": [ - "AAT-19.1" + "2-8-2": [ + "BCD-01", + "CPL-03" ], - "Article 5.1(b)": [ - "AAT-19.2" + "3-1-1": [ + "BCD-01", + "CAP-01" ], - "Article 5.1(c)": [ - "AAT-19.3" + "2-12-1-1": [ + "BCD-01.1", + "IRO-04" ], - "Article 5.1(c)(i)": [ - "AAT-19.4" + "3-1-1-1": [ + "BCD-01.4", + "SEA-01.2" ], - "Article 5.1(c)(ii)": [ - "AAT-19.4" + "3-1-1-3": [ + "BCD-01.7" ], - "Article 5.1(d)": [ - "AAT-19.5" + "3-1-1-4": [ + "BCD-01.7" ], - "Article 5.1(e)": [ - "AAT-19.6" + "2-1-1-5": [ + "BCD-02" ], - "Article 5.1(f)": [ - "AAT-19.7" + "3-1-1-5": [ + "BCD-02.2", + "BCD-02.3" ], - "Article 5.1(g)": [ - "AAT-19.8" + "3-1-1-6": [ + "BCD-04" ], - "Article 14.1": [ - "AAT-20", - "TDA-02.3" + "2-8-1-1": [ + "BCD-11", + "BCD-11.6" ], - "Article 14.3(a)": [ - "AAT-20", - "CFG-02.5" + "2-8-1-3": [ + "BCD-11" ], - "Article 14.3(b)": [ - "AAT-20", - "AAT-20.1", - "PRM-05", - "TDA-01.1" + "2-8-1-2": [ + "BCD-11.2" ], - "Article 15.1": [ - "AAT-20" + "2-8-1-4": [ + "BCD-11.4" ], - "Article 15.4": [ - "AAT-20", - "SEA-01.2" + "3-1-1-2": [ + "BCD-11.7" ], - "Article 15.5": [ - "AAT-20" + "3-1-2": [ + "CAP-01", + "CPL-03" ], - "Article 16(a)": [ - "AAT-20" + "1-5-1": [ + "CHG-01" ], - "Article 14.4": [ - "AAT-20.1", - "AAT-20.2", - "TDA-01" + "1-5-2": [ + "CHG-01" ], - "Article 14.4(a)": [ - "AAT-20.1", - "AAT-20.2" + "1-5-3": [ + "CHG-01" ], - "Article 13.2": [ - "AAT-20.2" + "1-5-3-1": [ + "CHG-02" ], - "Article 13.3(a)": [ - "AAT-20.2" + "1-5-3-4": [ + "CHG-02", + "CHG-04" ], - "Article 13.3(b)(i)": [ - "AAT-20.2" + "1-5-3-2": [ + "CHG-02.2" ], - "Article 13.3(b)(ii)": [ - "AAT-20.2" + "1-5-4": [ + "CHG-02.3", + "CHG-03", + "CHG-06", + "CPL-03" ], - "Article 13.3(b)(iii)": [ - "AAT-20.2" + "1-5-3-5": [ + "CHG-04.1" ], - "Article 13.3(b)(iv)": [ - "AAT-20.2" + "2-2-1-6": [ + "CHG-08" ], - "Article 13.3(b)(v)": [ - "AAT-20.2" + "1-6-1": [ + "CPL-03" ], - "Article 13.3(b)(vi)": [ - "AAT-20.2" + "2-2-2": [ + "CPL-03", + "IAC-01" ], - "Article 13.3(b)(vii)": [ - "AAT-20.2" + "2-3-2": [ + "CPL-03", + "PES-01" ], - "Article 13.3(c)": [ - "AAT-20.2" + "2-4-2": [ + "CPL-03", + "NET-01" ], - "Article 13.3(d)": [ - "AAT-20.2" + "2-5-2": [ + "CPL-03", + "MDM-01" ], - "Article 13.3(e)": [ - "AAT-20.2" + "2-6-2": [ + "CPL-03", + "DCH-01" ], - "Article 13.3(f)": [ - "AAT-20.2" + "2-7-2": [ + "CPL-03", + "CRY-01" ], - "Article 53.1(b)": [ - "AAT-20.2" + "2-9-2": [ + "CPL-03", + "VPM-01" ], - "Article 53.1(b)(i)": [ - "AAT-20.2" + "2-10-2": [ + "CPL-03", + "VPM-01" ], - "Article 16(i)": [ - "AAT-21" + "2-11-2": [ + "CPL-03", + "MON-01" ], - "Article 22.3(e)": [ - "AAT-21" + "2-12-2": [ + "CPL-03", + "IRO-01" ], - "Article 26.8": [ - "AAT-21" + "2-13-1-9": [ + "CPL-03" ], - "Article 49.1": [ - "AAT-21" + "2-13-2": [ + "CPL-03", + "PES-01" ], - "Article 49.2": [ - "AAT-21" + "4-1-2": [ + "CPL-03", + "TPM-01" ], - "Article 49.3": [ - "AAT-21" + "1-6-2": [ + "CPL-03.1" ], - "Article 52.1": [ - "AAT-21" + "2-2-1-8": [ + "CFG-02", + "IAC-10.1" ], - "Article 52.2": [ - "AAT-21" + "2-4-1-4": [ + "CFG-02", + "NET-15" ], - "Article 26.1": [ - "AAT-22" + "2-3-1-11": [ + "CFG-02.2", + "CFG-02.8" ], - "Article 14.3": [ - "AAT-22.2" + "2-2-1-5": [ + "CFG-02.5" ], - "Article 14.4(b)": [ - "AAT-22.3" + "2-4-1-14": [ + "CFG-03" ], - "Article 14.4(c)": [ - "AAT-22.3" + "2-3-1-2": [ + "CFG-03.1" ], - "Article 14.5": [ - "AAT-22.3" + "2-3-1-6": [ + "CFG-03.3" ], - "Article 26.2": [ - "AAT-22.4" + "2-11-1": [ + "MON-01" ], - "Article 26.4": [ - "AAT-22.5" + "2-11-1-10": [ + "MON-01" ], - "Article 26.5": [ - "AAT-22.6" + "2-11-1-3": [ + "MON-01.2" ], - "Article 26.7": [ - "AAT-22.7" + "2-11-1-1": [ + "MON-01.4" ], - "Article 26.11": [ - "AAT-22.8" + "2-11-1-4": [ + "MON-01.8" ], - "Article 50.1": [ - "AAT-22.8" + "2-11-1-9": [ + "MON-01.16", + "MON-02.6" ], - "Article 50.3": [ - "AAT-22.8" + "2-11-1-5": [ + "MON-02" ], - "Article 50.5": [ - "AAT-22.8" + "2-11-1-6": [ + "MON-02" ], - "Article 50.2": [ - "AAT-23" + "2-11-1-7": [ + "MON-02" ], - "Article 50.4": [ - "AAT-23" + "2-11-1-8": [ + "MON-02" ], - "Article 61.1": [ - "AAT-24" + "2-11-1-2": [ + "MON-03" ], - "Article 61.1(a)": [ - "AAT-24" + "2-3-1-10": [ + "MON-08" ], - "Article 61.1(b)": [ - "AAT-24" + "2-3-1-12": [ + "MON-16", + "END-06.8", + "NET-08" ], - "Article 61.1(c)": [ - "AAT-24" + "2-6-1": [ + "CRY-01", + "DCH-01" ], - "Article 61.1(d)": [ - "AAT-24" + "2-7-1": [ + "CRY-01" ], - "Article 61.1(e)": [ - "AAT-24" + "2-6-1-1": [ + "CRY-03", + "CRY-05" ], - "Article 61.2": [ - "AAT-24" + "2-1-1-3": [ + "DCH-01.2" ], - "Article 16(l)": [ - "CPL-01" + "2-3-1-9": [ + "DCH-12" ], - "Article 17.1(a)": [ - "CPL-01" + "2-6-1-4": [ + "DCH-17" ], - "Article 21.3": [ - "CPL-01" + "1-4-1": [ + "EMB-01" ], - "Article 40.1": [ - "CPL-01" + "2-3-1-1": [ + "END-04", + "END-06.8" ], - "Article 10.2(h)": [ - "CPL-01.1" + "2-3-1-8": [ + "END-04" ], - "Article 16(j)": [ - "CPL-01.1" + "1-7-1": [ + "HRS-01", + "HRS-04", + "HRS-10" ], - "Article 20.1": [ - "CPL-01.1" + "1-2-1-2": [ + "HRS-02", + "HRS-03" ], - "Article 41.5": [ - "CPL-01.1" + "1-2-1": [ + "HRS-03" ], - "Article 16(k)": [ - "CPL-01.3" + "2-5-1-1": [ + "HRS-05.5", + "MDM-07" + ], + "2-5-1-2": [ + "HRS-05.5" + ], + "2-2-1": [ + "IAC-01" + ], + "2-2-1-2": [ + "IAC-02" ], - "Article 21.1": [ - "CPL-01.3", - "CPL-05" + "2-2-1-10": [ + "IAC-07", + "IAC-17" ], - "Article 22.3": [ - "CPL-01.3", - "CPL-08" + "2-2-1-11": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2" ], - "Article 22.3(a)": [ - "CPL-01.3" + "2-2-1-3": [ + "IAC-10.8" ], - "Article 43.1": [ - "CPL-01.4" + "2-2-1-9": [ + "IAC-10.11" ], - "Article 43.1(a)": [ - "CPL-01.4" + "2-3-1-7": [ + "IAC-20.4" ], - "Article 43.1(b)(a)": [ - "CPL-01.4" + "2-3-1-4": [ + "IAC-21" ], - "Article 43.1(b)(b)": [ - "CPL-01.4" + "2-12-1": [ + "IRO-01" ], - "Article 43.1(b)(c)": [ - "CPL-01.4" + "2-12-1-3": [ + "IRO-02", + "IRO-04" ], - "Article 43.1(b)(d)": [ - "CPL-01.4" + "2-12-1-4": [ + "IRO-02", + "IRO-07" ], - "Article 43.2": [ - "CPL-01.4" + "2-12-1-5": [ + "IRO-04" ], - "Article 43.3": [ - "CPL-01.4" + "2-12-1-6": [ + "IRO-05" ], - "Article 43.4": [ - "CPL-01.4" + "2-12-1-7": [ + "IRO-06" ], - "Article 16(g)": [ - "CPL-01.5" + "2-12-1-2": [ + "IRO-13" ], - "Article 47.1": [ - "CPL-01.5" + "1-5-3-3": [ + "IAO-01", + "IAO-02.2", + "IAO-06", + "IAO-07" ], - "Article 47.2": [ - "CPL-01.5" + "1-4-1-2": [ + "IAO-02", + "IAO-02.2", + "IAO-06", + "IAO-07" ], - "Article 47.3": [ - "CPL-01.5" + "2-10-1-4": [ + "IAO-02.2" ], - "Article 47.4": [ - "CPL-01.5" + "1-3-1-7": [ + "IAO-05", + "RSK-06.2" ], - "Article 79.4": [ - "CPL-02.3" + "2-5-1": [ + "MDM-01" ], - "Article 80.4": [ - "CPL-02.3" + "2-5-1-4": [ + "MDM-01" ], - "Article 80.5": [ - "CPL-02.3" + "2-5-1-3": [ + "MDM-02", + "MDM-06", + "MDM-07" ], - "Article 82.2": [ - "CPL-02.3" + "2-5-1-5": [ + "MDM-03" ], - "Article 93.1(a)": [ - "CPL-02.3" + "2-6-1-3": [ + "MDM-05" ], - "Article 93.1(b)": [ - "CPL-02.3" + "2-4-1": [ + "NET-01" ], - "Article 93.1(c)": [ - "CPL-02.3" + "2-3-1-13": [ + "NET-03", + "NET-08" ], - "Article 22.3(c)": [ - "CPL-05" + "2-4-1-12": [ + "NET-03", + "NET-06.9" ], - "Article 22.3(d)": [ - "CPL-05" + "2-4-1-6": [ + "NET-04", + "NET-06.9" ], - "Article 24.5": [ - "CPL-05" + "2-4-1-8": [ + "NET-04" ], - "Article 24.6": [ - "CPL-05" + "2-4-1-9": [ + "NET-04", + "NET-06.9" ], - "Article 91.4": [ - "CPL-05" + "2-4-1-10": [ + "NET-04", + "NET-06.9", + "NET-14" ], - "Article 91.5": [ - "CPL-05" + "2-4-1-1": [ + "NET-06", + "NET-06.9" ], - "Article 92.4": [ - "CPL-05" + "2-4-1-2": [ + "NET-06", + "NET-06.3" ], - "Article 92.5": [ - "CPL-05" + "2-4-1-5": [ + "NET-06", + "NET-06.9" ], - "Article 21.2": [ - "CPL-05.2" + "2-4-1-3": [ + "NET-06.3" ], - "Article 22.1": [ - "CPL-08" + "2-4-1-7": [ + "NET-06.5", + "NET-14.3" ], - "Article 22.2": [ - "CPL-08" + "2-4-1-13": [ + "NET-06.9", + "WEB-02" ], - "Article 23.1(d)": [ - "CPL-08" + "2-2-1-7": [ + "NET-14", + "NET-14.1", + "NET-14.2" ], - "Article 54.1": [ - "CPL-08" + "2-6-1-2": [ + "NET-17" ], - "Article 54.2": [ - "CPL-08.1" + "2-4-1-11": [ + "NET-18.1" ], - "Article 54.3": [ - "CPL-08.1" + "2-3-1": [ + "PES-01" ], - "Article 54.3(a)": [ - "CPL-08.1" + "2-13-1": [ + "PES-01" ], - "Article 54.3(b)": [ - "CPL-08.1" + "2-13-1-1": [ + "PES-02" ], - "Article 54.3(c)": [ - "CPL-08.1" + "2-13-1-3": [ + "PES-03" ], - "Article 54.3(d)": [ - "CPL-08.1" + "2-13-1-5": [ + "PES-03.4" ], - "Article 54.4": [ - "CPL-08.1" + "2-13-1-4": [ + "PES-04" ], - "Article 54.5": [ - "CPL-08.1" + "2-13-1-2": [ + "PES-05", + "PES-05.1" ], - "Article 19.1": [ - "MON-10" + "2-13-1-7": [ + "PES-05.2" ], - "Article 19.2": [ - "MON-10" + "2-13-1-6": [ + "PES-06" ], - "Article 16(d)": [ - "DCH-18" + "1-4-1-1": [ + "PRM-04", + "PRM-05", + "PRM-07" ], - "Article 18.1": [ - "DCH-18" + "1-4-1-3": [ + "PRM-04", + "SEA-01" ], - "Article 18.1(a)": [ - "DCH-18" + "1-3-1": [ + "RSK-01" ], - "Article 18.1(b)": [ - "DCH-18" + "1-3-1-2": [ + "RSK-04" ], - "Article 18.1(c)": [ - "DCH-18" + "1-3-1-4": [ + "RSK-04" ], - "Article 18.1(d)": [ - "DCH-18" + "1-3-1-5": [ + "RSK-04" ], - "Article 18.1(e)": [ - "DCH-18" + "1-3-1-3": [ + "RSK-04.1" ], - "Article 18.3": [ - "DCH-18" + "1-3-1-1": [ + "RSK-04.2" ], - "Article 10.2": [ - "DCH-18.2" + "1-3-1-6": [ + "RSK-06.2", + "RSK-06.3", + "RSK-06.4" ], - "Article 10.2(a)": [ - "DCH-18.2" + "2-2-1-1": [ + "SEA-07.1" ], - "Article 10.2(b)": [ - "DCH-18.2" + "1-8-1": [ + "SAT-01" ], - "Article 10.2(c)": [ - "DCH-18.2" + "1-8-2": [ + "SAT-02" ], - "Article 10.2(d)": [ - "DCH-18.2" + "1-8-2-1": [ + "SAT-03", + "SAT-03.7" ], - "Article 10.2(e)": [ - "DCH-18.2" + "2-13-1-8": [ + "SAT-03", + "SAT-03.6" ], - "Article 10.6": [ - "DCH-18.2" + "1-8-2-2": [ + "SAT-03.6" ], - "Article 10.5(b)": [ - "DCH-23", - "PRI-01.6" + "1-4-1-4": [ + "TDA-07" ], - "Article 17.1(j)": [ - "IRO-10", - "IRO-10.2" + "4-1-1": [ + "TPM-01" ], - "Article 9.8": [ - "IAO-01", - "IAO-02" + "4-1-1-2": [ + "TPM-04.1" ], - "Article 10.5(c)": [ - "PRI-01.6", - "PRI-05.4" + "4-1-1-1": [ + "TPM-05" ], - "Article 10.5(e)": [ - "PRI-05" + "4-1-1-3": [ + "TPM-05" ], - "Article 10.5(d)": [ - "PRI-05.4" + "1-2-1-1": [ + "TPM-05.4" ], - "Article 10.5(f)": [ - "PRI-14" + "4-1-1-4": [ + "TPM-08" ], - "Article 17.1(l)": [ - "PRM-03", - "RSK-09" + "2-12-1-8": [ + "THR-01", + "THR-03" ], - "Article 9.2": [ - "RSK-01" + "2-9-1": [ + "VPM-01" ], - "Article 9.4": [ - "RSK-01", - "RSK-06.1" + "2-10-1": [ + "VPM-01" ], - "Article 9.5": [ - "RSK-01", - "RSK-06.1" + "2-9-1-1": [ + "VPM-01.1" ], - "Article 9.2(c)": [ - "RSK-03", - "RSK-04" + "2-10-1-1": [ + "VPM-01.1" ], - "Article 9.2(d)": [ - "RSK-06" + "2-9-1-2": [ + "VPM-02" ], - "Article 9.5(a)": [ - "RSK-06.1" + "2-3-1-3": [ + "VPM-05" ], - "Article 9.5(b)": [ - "RSK-06.1", - "RSK-06.2" + "2-4-1-15": [ + "VPM-05", + "VPM-05.8" ], - "Article 26.9": [ - "RSK-10" + "2-9-1-3": [ + "VPM-06" ], - "Article 3": [ - "SEA-02.1" + "2-10-1-2": [ + "VPM-07" ], - "Article 9.5(c)": [ - "SAT-03" + "2-10-1-3": [ + "VPM-07" + ] + }, + "emea-sau-pdpl-2023": { + "Article 2.1": [ + "CPL-01" ], - "Article 8.2": [ - "TDA-21" + "Article 30.3": [ + "CPL-01" ], - "Article 10.1": [ - "TDA-21" + "Article 2.2": [ + "CPL-01.2" ], - "Article 23.1(c)": [ - "TDA-21" + "Article 30.4.a": [ + "CPL-01.3" ], - "Article 23.2": [ - "TDA-21" + "Article 15.3": [ + "DCH-03.1" ], - "Article 23.3": [ - "TDA-21" + "Article 15.4": [ + "DCH-03.1" ], - "Article 23.4": [ - "TDA-21" + "Article 15.5": [ + "DCH-03.1" ], - "Article 23.5": [ - "TDA-21" + "Article 15.6": [ + "DCH-03.1" ], - "Article 23.6": [ - "TDA-21" + "Article 16.1": [ + "DCH-03.1" ], - "Article 23.7": [ - "TDA-21" + "Article 16.2": [ + "DCH-03.1" ], - "Article 24.1": [ - "TDA-21" + "Article 16.3": [ + "DCH-03.1" ], - "Article 24.2": [ - "TDA-21" + "Article 16.4": [ + "DCH-03.1" ], - "Article 24.3": [ - "TDA-21" + "Article 16.5": [ + "DCH-03.1" ], - "Article 24.4": [ - "TDA-21" + "Article 16.6": [ + "DCH-03.1" ], - "Article 25.1": [ - "TDA-21" + "Article 16.7": [ + "DCH-03.1" ], - "Article 25.1(a)": [ - "TDA-21" + "Article 16.8": [ + "DCH-03.1" ], - "Article 25.1(b)": [ - "TDA-21" + "Article 16.9": [ + "DCH-03.1" ], - "Article 25.1(c)": [ - "TDA-21" + "Article 11.3": [ + "DCH-18.1", + "PRI-05.4" ], - "Article 25.2": [ - "TDA-21" + "Article 17.1": [ + "DCH-22.1", + "PRI-12" ], - "Article 25.4": [ - "TDA-21" + "Article 10": [ + "DCH-22.3", + "PRI-04.2", + "PRI-04.4" ], - "Article 48.1": [ - "TDA-21" + "Article 29.1": [ + "DCH-25" ], - "Article 48.2": [ - "TDA-21" + "Article 30.2": [ + "HRS-03", + "PRI-01.4" ], - "Article 48.3": [ - "TDA-21" + "Article 20.1": [ + "IRO-04.1" ], - "Article 48.4": [ - "TDA-21" + "Article 20.2": [ + "IRO-04.1" ], - "Article 48.5": [ - "TDA-21" + "Article 11.2": [ + "PRI-01", + "PRI-04.7" ], - "Article 53.1(b)(ii)": [ - "TDA-21" + "Article 29.2.b": [ + "PRI-01.5" ], - "Article 111.3": [ - "TDA-21" + "Article 19": [ + "PRI-01.6" ], - "Article 11.2": [ - "TDA-22" + "Article 23.1": [ + "PRI-01.7" ], - "Article 17.1(k)": [ - "TDA-22" + "Article 23.2": [ + "PRI-01.7" ], - "Article 23.1(b)": [ - "TDA-22" + "Article 29.2.c": [ + "PRI-01.7" ], - "Article 53.1(a)": [ - "TDA-22" - ] - }, - "emea-eu-cyber-resilience-act-2022": { - "Article 10.13": [ - "CPL-01.3" + "Article 4.1": [ + "PRI-02" ], - "Article 10.2": [ - "CPL-01.4" + "Article 12": [ + "PRI-02" ], - "Article 10.7": [ - "CPL-01.4", - "TDA-22" + "Article 13.2": [ + "PRI-02", + "PRI-02.1" ], - "Article 13.2(a)": [ - "CPL-01.4", - "TDA-01.1" + "Article 13.4": [ + "PRI-02" ], - "Article 24.1": [ - "CPL-01.4" + "Article 13.5": [ + "PRI-02" ], - "Article 24.1(a)": [ - "CPL-01.4" + "Article 13.6": [ + "PRI-02" ], - "Article 24.1(b)": [ - "CPL-01.4" + "Article 11.1": [ + "PRI-02.1" ], - "Article 24.1(c)": [ - "CPL-01.4" + "Article 13.3": [ + "PRI-02.1" ], - "Article 10.12": [ - "CPL-02.3", - "TDA-21" + "Article 5.1": [ + "PRI-03" ], - "Article 13.6": [ - "CPL-02.3", - "TDA-01.1" + "Article 10.1": [ + "PRI-03" ], - "Article 14.4": [ - "CPL-02.3", - "TDA-01.1" + "Article 15.1": [ + "PRI-03" ], - "Article 13.8": [ - "CPL-03.3" + "Article 24.1": [ + "PRI-03" ], - "Article 14.5": [ - "CPL-03.3" + "Article 25.1": [ + "PRI-03" ], - "Article 12.1": [ - "CPL-08" + "Article 25.2": [ + "PRI-03" ], - "Article 12.3": [ - "CPL-08.1" + "Article 25.3": [ + "PRI-03" ], - "Article 12.3(a)": [ - "CPL-08.1" + "Article 26": [ + "PRI-03" ], - "Article 12.3(b)": [ - "CPL-08.1" + "Article 5.2": [ + "PRI-03.4" ], - "Article 12.3(c)": [ - "CPL-08.1" + "Article 7": [ + "PRI-03.5" ], - "Article 10.8": [ - "DCH-18" + "Article 13.1": [ + "PRI-04.1" ], - "Article 13.7": [ - "DCH-18" + "Article 14": [ + "PRI-04.4", + "PRI-04.5", + "PRI-05.2" ], - "Article 11.2": [ - "IRO-10.5" + "Article 15.2": [ + "PRI-04.4" ], "Article 11.4": [ - "IRO-10.5" + "PRI-05" ], - "Article 3": [ - "SEA-02.1" + "Article 18.1": [ + "PRI-05" ], - "Article 5": [ - "TDA-01.1" + "Article 18.2.a": [ + "PRI-05" ], - "Article 5.1": [ - "TDA-01.1" + "Article 18.2.b": [ + "PRI-05" ], - "Article 5.2": [ - "TDA-01.1" + "Article 4.2": [ + "PRI-06" ], - "Article 10.1": [ - "TDA-01.1" + "Article 4.3": [ + "PRI-06" ], - "Article 10.5": [ - "TDA-01.1" + "Article 4.4": [ + "PRI-06" ], - "Article 10.6": [ - "TDA-01.1", - "TDA-02.9" + "Article 4.5": [ + "PRI-06" ], - "Article 10.9": [ - "TDA-01.1" + "Article 21": [ + "PRI-06" ], - "Article 10.10": [ - "TDA-01.1" + "Article 8": [ + "PRI-07", + "TPM-05", + "TPM-08" ], - "Article 10.11": [ - "TDA-01.1" + "Article 31": [ + "PRI-14" ], - "Article 13.1": [ - "TDA-01.1" + "Article 31.1": [ + "PRI-14" ], - "Article 13.2": [ - "TDA-01.1" + "Article 31.2": [ + "PRI-14" ], - "Article 13.2(b)": [ - "TDA-01.1", - "TDA-22" + "Article 31.3": [ + "PRI-14" ], - "Article 13.2(c)": [ - "TDA-01.1" + "Article 31.4": [ + "PRI-14" ], - "Article 13.3": [ - "TDA-01.1" + "Article 31.5": [ + "PRI-14" ], - "Article 13.4": [ - "TDA-01.1" + "Article 31.6": [ + "PRI-14" ], - "Article 13.5": [ - "TDA-01.1" + "Article 24.2": [ + "PRI-14.2" ], - "Article 14.1": [ - "TDA-01.1" + "Article 22": [ + "RSK-10" + ] + }, + "emea-sau-sacs-002-2022": { + "VII.B.TPC-69": [ + "GOV-01.3", + "BCD-01.7" ], - "Article 14.2": [ - "TDA-01.1" + "VII.B.TPC-24": [ + "GOV-02", + "DCH-02" ], - "Article 14.2(a)": [ - "TDA-01.1" + "VII.B.TPC-25": [ + "GOV-02" ], - "Article 14.2(b)": [ - "TDA-01.1" + "VII.A.TPC-19": [ + "AST-09", + "DCH-09", + "DCH-18" ], - "Article 14.3": [ - "TDA-01.1" + "VII.B.TPC-66": [ + "AST-09", + "DCH-09" ], - "Article 11.7": [ - "TDA-02.11", - "TDA-04.2" + "VII.B.TPC-64": [ + "BCD-01", + "BCD-11" ], - "Article 11.1": [ - "TDA-02.13" + "VII.B.TPC-67": [ + "BCD-01.7" ], - "Article 23.1": [ - "TDA-22" + "VII.B.TPC-68": [ + "BCD-01.7" ], - "Article 23.2": [ - "TDA-22" + "VII.B.TPC-68(a)": [ + "BCD-01.7" ], - "Article 23.3": [ - "TDA-22" + "VII.B.TPC-68(b)": [ + "BCD-01.7" ], - "Article 23.4": [ - "TDA-22" + "VII.B.TPC-68(c)": [ + "BCD-01.7" ], - "Article 10.3": [ - "TDA-22.1" + "VII.B.TPC-68(d)": [ + "BCD-01.7" ], - "Article 10.4": [ - "TPM-03" - ] - }, - "emea-eu-cyber-resilience-act-annexes-2022": { - "Annex 6 Module A.1": [ - "CPL-01.4" + "VII.B.TPC-68(e)": [ + "BCD-01.7" ], - "Annex 4": [ - "CPL-01.5" + "VII.B.TPC-68(f)": [ + "BCD-01.7" ], - "Annex 4.1": [ - "CPL-01.5" + "VII.B.TPC-68(g)": [ + "BCD-01.7" ], - "Annex 4.2": [ - "CPL-01.5" + "VII.B.TPC-68(h)": [ + "BCD-01.7" ], - "Annex 4.3": [ - "CPL-01.5" + "VII.B.TPC-68(i)": [ + "BCD-01.7" ], - "Annex 4.4": [ - "CPL-01.5" + "VII.B.TPC-70": [ + "BCD-04" ], - "Annex 4.5": [ - "CPL-01.5" + "VII.B.TPC-65": [ + "BCD-11.2", + "BCD-11.4" ], - "Annex 4.6": [ - "CPL-01.5" + "VII.B.TPC-50": [ + "BCD-11.4" ], - "Annex 4.7": [ - "CPL-01.5" + "VII.B.TPC-92": [ + "CAP-02" ], - "Annex 4.8": [ - "CPL-01.5" + "VII.A.TPC-2": [ + "CFG-02", + "IAC-10.1" ], - "Annex 6 Module A.4": [ - "CPL-01.5" + "VII.A.TPC-2-BP1": [ + "CFG-02" ], - "Annex 6 Module A.4.2": [ - "CPL-01.5" + "VII.A.TPC-2-BP2": [ + "CFG-02" ], - "Annex 6 Module C.3.2": [ - "CPL-01.5", - "DCH-18" + "VII.A.TPC-2-BP3": [ + "CFG-02" ], - "Annex 6 Module H.3.1": [ - "CPL-03.1" + "VII.A.TPC-2-BP4": [ + "CFG-02" ], - "Annex 6 Module H.3.5": [ - "CPL-03.1" + "VII.A.TPC-2-BP5": [ + "CFG-02" ], - "Annex 6 Module H.4.2": [ - "CPL-03.3" + "VII.A.TPC-10": [ + "CFG-02" ], - "Annex 6 Module A.5": [ - "CPL-08", - "CPL-08.1" + "VII.B.TPC-56": [ + "CFG-02" ], - "Annex 6 Module C.4": [ - "CPL-08", - "CPL-08.1" + "VII.B.TPC-62": [ + "CFG-02", + "IAC-10" ], - "Annex 1.1(3)(e)": [ - "DCH-01.2", - "DCH-01.4", - "IAC-21", - "PRI-05.4" + "VII.B.TPC-63": [ + "CFG-02" ], - "Annex 6 Module B.9": [ - "DCH-18" + "VII.B.TPC-63-BP1": [ + "CFG-02" ], - "Annex 1.1(3)(j)": [ - "TDA-01.1" + "VII.B.TPC-63-BP2": [ + "CFG-02" ], - "Annex 1.2(2)": [ - "TDA-01.1", - "TDA-02.9" + "VII.B.TPC-63-BP3": [ + "CFG-02" ], - "Annex 2.1": [ - "TDA-01.1" + "VII.B.TPC-63-BP4": [ + "CFG-02" ], - "Annex 2.2": [ - "TDA-01.1", - "THR-06.1" + "VII.B.TPC-83": [ + "MON-01.15" ], - "Annex 2.3": [ - "TDA-01.1" + "VII.B.TPC-81": [ + "MON-02.1" ], - "Annex 2.4": [ - "TDA-01.1" + "VII.B.TPC-87": [ + "MON-03" ], - "Annex 2.5": [ - "TDA-01.1" + "VII.B.TPC-75": [ + "MON-10" ], - "Annex 2.6": [ - "TDA-01.1" + "VII.B.TPC-80": [ + "MON-11.3", + "MON-16", + "IRO-03" ], - "Annex 2.7": [ - "TDA-01.1" + "VII.B.TPC-54": [ + "CRY-01" ], - "Annex 2.8": [ - "TDA-01.1" + "VII.B.TPC-52": [ + "CRY-03" ], - "Annex 2.9": [ - "TDA-01.1" + "VII.B.TPC-53": [ + "CRY-03" ], - "Annex 2.9(a)": [ - "TDA-01.1" + "VII.B.TPC-42": [ + "CRY-07", + "NET-15.1" ], - "Annex 2.9(b)": [ - "TDA-01.1" + "VII.B.TPC-55": [ + "CRY-09" ], - "Annex 2.9(c)": [ - "TDA-01.1" + "VII.B.TPC-39": [ + "DCH-01.2", + "DCH-01.4" ], - "Annex 2.9(d)": [ - "TDA-01.1" + "VII.B.TPC-58": [ + "DCH-01.2" ], - "Annex 6 Module A.3": [ - "TDA-01.1", - "TDA-02" + "VII.B.TPC-36": [ + "DCH-13", + "NET-05.1", + "TPM-04" ], - "Annex 6 Module A.4.1": [ - "TDA-01.1" + "VII.A.TPC-12": [ + "END-04" ], - "Annex 6 Module C.2.1": [ - "TDA-01.1" + "VII.A.TPC-22": [ + "END-05" ], - "Annex 6 Module C.3.1": [ - "TDA-01.1" + "VII.A.TPC-16": [ + "END-08" ], - "Annex 6 Module H.2": [ - "TDA-01.1" + "VII.B.TPC-26": [ + "HRS-01", + "HRS-03", + "HRS-03.2" ], - "Annex 6 Module H.3.2": [ - "TDA-01.1" + "VII.A.TPC-18": [ + "HRS-01.1" ], - "Annex 6 Module H.3.4": [ - "TDA-01.1" + "VII.B.TPC-71": [ + "HRS-01.1" ], - "Annex 6 Module H.5.1": [ - "TDA-01.1" + "VII.A.TPC-1": [ + "HRS-05", + "HRS-05.1" ], - "Annex 6 Module H.5.2": [ - "TDA-01.1" + "VII.A.TPC-8": [ + "HRS-05.3", + "SAT-02" ], - "Annex 6 Module H.6": [ - "TDA-01.1" + "VII.B.TPC-84": [ + "HRS-05.5", + "MDM-06" ], - "Annex 1.1(1)": [ - "TDA-02" + "VII.A.TPC-9": [ + "HRS-06.1", + "SAT-02" ], - "Annex 1.1(3)(b)": [ - "TDA-02" + "VII.A.TPC-6": [ + "HRS-09.4", + "IAC-07" ], - "Annex 1.1(3)(c)": [ - "TDA-02" + "VII.B.TPC-32": [ + "IAC-02", + "IAC-03", + "IAC-15" ], - "Annex 1.1(3)(d)": [ - "TDA-02" + "VII.A.TPC-4": [ + "IAC-06" ], - "Annex 1.1(3)(f)": [ - "TDA-02" + "VII.A.TPC-5": [ + "IAC-06" ], - "Annex 1.1(3)(g)": [ - "TDA-02" + "VII.B.TPC-37": [ + "IAC-06" ], - "Annex 1.1(3)(i)": [ - "TDA-02" + "VII.B.TPC-44": [ + "IAC-06" ], - "Annex 1.1(3)(a)": [ - "TDA-02.4" + "VII.B.TPC-45": [ + "IAC-06" ], - "Annex 1.1(2)": [ - "TDA-02.8" + "VII.B.TPC-34": [ + "IAC-08", + "IAC-21" ], - "Annex 1.1(3)(h)": [ - "TDA-02.8" + "VII.A.TPC-3": [ + "IAC-10.5" ], - "Annex 1.1(3)(k)": [ - "TDA-02.9" + "VII.B.TPC-33": [ + "IAC-17" ], - "Annex 1.2(7)": [ - "TDA-02.9" + "VII.A.TPC-23": [ + "IRO-01" ], - "Annex 1.2(8)": [ - "TDA-02.9" + "VII.B.TPC-89": [ + "IRO-02", + "IRO-13" ], - "Annex 1.2(3)": [ - "TDA-02.10" + "VII.A.TPC-23-BP2": [ + "IRO-04", + "TPM-05" ], - "Annex 1.2(4)": [ - "TDA-02.11" + "VII.B.TPC-88": [ + "IRO-04" ], - "Annex 1.2(6)": [ - "TDA-02.11", - "TDA-04.2" + "VII.B.TPC-90": [ + "IRO-09" ], - "Annex 3 Class 1.1": [ - "TDA-02.12" + "VII.A.TPC-23-BP1": [ + "IRO-10" ], - "Annex 3 Class 1.2": [ - "TDA-02.12" + "VII.B.TPC-72": [ + "IAO-02.2", + "IAO-04", + "IAO-06", + "IAO-07" ], - "Annex 3 Class 1.3": [ - "TDA-02.12" + "VII.B.TPC-73": [ + "IAO-06", + "IAO-07" ], - "Annex 3 Class 1.4": [ - "TDA-02.12" + "VII.B.TPC-59": [ + "MDM-05" ], - "Annex 3 Class 1.5": [ - "TDA-02.12" + "VII.B.TPC-76": [ + "NET-03" ], - "Annex 3 Class 1.6": [ - "TDA-02.12" + "VII.B.TPC-40": [ + "NET-06" ], - "Annex 3 Class 1.7": [ - "TDA-02.12" + "VII.B.TPC-38": [ + "NET-06.3", + "PES-18" ], - "Annex 3 Class 1.8": [ - "TDA-02.12" + "VII.B.TPC-77": [ + "NET-08" ], - "Annex 3 Class 1.9": [ - "TDA-02.12" + "VII.A.TPC-13": [ + "NET-10.3" ], - "Annex 3 Class 1.10": [ - "TDA-02.12" + "VII.A.TPC-14": [ + "NET-10.3" ], - "Annex 3 Class 1.11": [ - "TDA-02.12" + "VII.A.TPC-15": [ + "NET-10.3" ], - "Annex 3 Class 1.12": [ - "TDA-02.12" + "VII.B.TPC-35": [ + "NET-14.4" ], - "Annex 3 Class 1.13": [ - "TDA-02.12" + "VII.B.TPC-57": [ + "NET-18" ], - "Annex 3 Class 1.14": [ - "TDA-02.12" + "VII.B.TPC-57-BP1": [ + "NET-18" ], - "Annex 3 Class 1.15": [ - "TDA-02.12" + "VII.B.TPC-57-BP2": [ + "NET-18" ], - "Annex 3 Class 1.16": [ - "TDA-02.12" + "VII.B.TPC-57-BP3": [ + "NET-18" ], - "Annex 3 Class 1.17": [ - "TDA-02.12" + "VII.B.TPC-86": [ + "PES-02", + "PES-02.1" ], - "Annex 3 Class 1.18": [ - "TDA-02.12" + "VII.B.TPC-82": [ + "PES-03" ], - "Annex 3 Class 1.19": [ - "TDA-02.12" + "VII.B.TPC-46": [ + "PES-03.2", + "PES-03.4" ], - "Annex 3 Class 1.20": [ - "TDA-02.12" + "VII.B.TPC-49": [ + "PES-04.1", + "PES-18" ], - "Annex 3 Class 1.21": [ - "TDA-02.12" + "VII.B.TPC-47": [ + "PES-06" ], - "Annex 3 Class 1.22": [ - "TDA-02.12" + "VII.B.TPC-47-BP2": [ + "PES-06" ], - "Annex 3 Class 1.23": [ - "TDA-02.12" + "VII.B.TPC-47-BP3": [ + "PES-06" ], - "Annex 3 Class 2.1": [ - "TDA-02.12" + "VII.B.TPC-47-BP1": [ + "PES-06.2" ], - "Annex 3 Class 2.2": [ - "TDA-02.12" + "VII.B.TPC-48": [ + "PES-06.3" ], - "Annex 3 Class 2.3": [ - "TDA-02.12" + "VII.B.TPC-31": [ + "RSK-04" ], - "Annex 3 Class 2.4": [ - "TDA-02.12" + "VII.A.TPC-7": [ + "SAT-02" ], - "Annex 3 Class 2.5": [ - "TDA-02.12" + "VII.A.TPC-7.1": [ + "SAT-02" ], - "Annex 3 Class 2.6": [ - "TDA-02.12" + "VII.A.TPC-7.2": [ + "SAT-02" ], - "Annex 3 Class 2.7": [ - "TDA-02.12" + "VII.A.TPC-7.4": [ + "SAT-02" ], - "Annex 3 Class 2.8": [ - "TDA-02.12" + "VII.A.TPC-7.5": [ + "SAT-02" ], - "Annex 3 Class 2.9": [ - "TDA-02.12" + "VII.A.TPC-7.3": [ + "SAT-02.2" ], - "Annex 3 Class 2.10": [ - "TDA-02.12" + "VII.B.TPC-74": [ + "TDA-06" ], - "Annex 3 Class 2.11": [ - "TDA-02.12" + "VII.B.TPC-51": [ + "TDA-17" ], - "Annex 3 Class 2.12": [ - "TDA-02.12" + "VII.B.TPC-60": [ + "TDA-18" ], - "Annex 3 Class 2.13": [ - "TDA-02.12" + "VII.B.TPC-61": [ + "TDA-19", + "TDA-19.1" ], - "Annex 3 Class 2.14": [ - "TDA-02.12" + "VII.A.TPC-17": [ + "TPM-05" ], - "Annex 3 Class 2.15": [ - "TDA-02.12" + "VII.A.TPC-20": [ + "TPM-05.8" ], - "Annex 1.2(1)": [ - "TDA-04.2" + "VII.A.TPC-21": [ + "TPM-05.8" ], - "Annex 5": [ - "TDA-22" + "VII.B.TPC-91": [ + "VPM-02" ], - "Annex 5.1": [ - "TDA-22" + "VII.B.TPC-91-BP1": [ + "VPM-02" ], - "Annex 5.1(a)": [ - "TDA-22" + "VII.B.TPC-91-BP2": [ + "VPM-02" ], - "Annex 5.1(b)": [ - "TDA-22" + "VII.B.TPC-91-BP3": [ + "VPM-02" ], - "Annex 5.1(c)": [ - "TDA-22" + "VII.A.TPC-11": [ + "VPM-05" ], - "Annex 5.1(d)": [ - "TDA-22" + "VII.B.TPC-85": [ + "VPM-06" ], - "Annex 5.2": [ - "TDA-22" + "VII.B.TPC-78": [ + "VPM-06.1" ], - "Annex 5.2(a)": [ - "TDA-22" + "VII.B.TPC-27": [ + "VPM-07" ], - "Annex 5.2(b)": [ - "TDA-22" + "VII.B.TPC-28": [ + "VPM-07" ], - "Annex 5.2(c)": [ - "TDA-22" + "VII.B.TPC-29": [ + "VPM-07" ], - "Annex 5.3": [ - "TDA-22" + "VII.B.TPC-41": [ + "WEB-02" ], - "Annex 5.4": [ - "TDA-22" + "VII.B.TPC-79": [ + "WEB-03" + ] + }, + "emea-sau-sama-csf-1-2017": { + "3.1.1": [ + "GOV-01" ], - "Annex 5.5": [ - "TDA-22" + "3.1.1.1": [ + "GOV-01.1" ], - "Annex 5.6": [ - "TDA-22" + "3.1.1.2": [ + "GOV-01.1" ], - "Annex 5.7": [ - "TDA-22" + "3.1.1.3": [ + "GOV-01.1" ], - "Annex 6 Module A.2": [ - "TDA-22" + "3.1.1.3.a": [ + "GOV-01.1" ], - "Annex 1.2(5)": [ - "THR-06" - ] - }, - "emea-eu-eba-ict-srm-2025": { - "3.2.1(2)": [ + "3.1.1.3.b": [ "GOV-01.1" ], - "3.2.1(3)": [ - "GOV-01.1", - "PRM-03", - "SAT-01", - "SAT-03" + "3.1.1.3.c": [ + "GOV-01.1" ], - "3.2.1(4)": [ - "GOV-01.1", - "GOV-08", - "PRM-01.1" + "3.1.1.4": [ + "GOV-01.1" ], - "3.3.1(13)(e)": [ - "GOV-01.2", - "RSK-01" + "3.1.1.4.a": [ + "GOV-01.1" ], - "3.3.5(24)": [ - "GOV-01.2" + "3.1.1.4.b": [ + "GOV-01.1" ], - "3.4.1(28)": [ - "GOV-02" + "3.1.1.4.c": [ + "GOV-01.1" ], - "3.4.1(29)": [ - "GOV-02" + "3.1.1.4.d": [ + "GOV-01.1" ], - "3.4.5(38)": [ - "GOV-02", - "MON-11.3", - "MON-16", - "OPS-01.1" + "3.1.1.5": [ + "GOV-01.1" ], - "3.3.1(14)": [ - "GOV-03", - "RSK-01" + "3.1.1.6": [ + "GOV-01.1" ], - "3.3.1(11)": [ - "GOV-04", - "GOV-04.1", - "CPL-02.1" + "3.1.1.7": [ + "GOV-01.1" ], - "3.3.1(12)": [ - "GOV-04", - "HRS-03" + "3.1.1.8": [ + "GOV-01.1" ], - "3.7.5(91)": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", - "GOV-06", - "BCD-10", - "BCD-10.4", - "IRO-10", - "IRO-10.2", - "IRO-14", - "IRO-16" + "3.1.1.9": [ + "GOV-01.1" ], - "3.2.1(5)(c)": [ - "GOV-09", - "PRM-01.1" + "3.1.1.9.a": [ + "GOV-01.1" ], - "3.3.4(22)": [ - "GOV-15", - "GOV-15.1" + "3.1.1.9.b": [ + "GOV-01.1" ], - "3.4.1(30)(a)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "3.1.1.9.c": [ + "GOV-01.1" + ], + "3.2.3": [ + "GOV-01.4" + ], + "3.2.3.1": [ + "GOV-01.4" ], - "3.4.1(30)(b)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "3.2.3.1.a": [ + "GOV-01.4" ], - "3.4.1(30)(c)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "3.2.3.1.b": [ + "GOV-01.4" ], - "3.4.1(30)(d)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "3.2.3.1.c": [ + "GOV-01.4" ], - "3.4.1(30)(e)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "3.1.3": [ + "GOV-02" ], - "3.4.1(30)(f)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "3.1.3.1": [ + "GOV-02" ], - "3.4.1(30)(g)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "3.1.3.3": [ + "GOV-02" ], - "3.3.4(23)": [ - "GOV-15.1" + "3.1.3.3.a": [ + "GOV-02" ], - "3.4.6(41)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.3.b": [ + "GOV-02" ], - "3.4.6(42)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.3.c": [ + "GOV-02" ], - "3.4.6(43)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.3.d": [ + "GOV-02" ], - "3.4.6(43)(a)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.4": [ + "GOV-02" ], - "3.4.6(43)(b)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.4.a": [ + "GOV-02" ], - "3.4.6(44)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.4.b": [ + "GOV-02" ], - "3.4.6(45)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.4.c": [ + "GOV-02" ], - "3.4.6(46)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.4.d": [ + "GOV-02" ], - "3.4.6(47)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.4.e": [ + "GOV-02" ], - "3.4.6(48)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" + "3.1.3.4.f": [ + "GOV-02" ], - "3.5(53)": [ - "AST-01", - "AST-02" + "3.1.3.4.f.1": [ + "GOV-02" ], - "3.5(54)": [ - "AST-01", - "AST-01.1", - "AST-01.2", - "AST-02", - "DCH-02" + "3.1.3.4.f.2": [ + "GOV-02" ], - "3.3.3(17)": [ - "AST-01.1", - "AST-04.1", - "DCH-02" + "3.1.3.4.f.3": [ + "GOV-02" ], - "3.3.3(18)": [ - "AST-01.1", - "AST-04.1", - "DCH-02" + "3.1.3.4.f.4": [ + "GOV-02" ], - "3.3.2(16)": [ - "AST-01.2", - "TPM-05.4" + "3.1.3.4.f.5": [ + "GOV-02" ], - "3.7(77)": [ - "BCD-01" + "3.1.3.4.f.6": [ + "GOV-02" ], - "3.7.1(78)": [ - "BCD-01", - "BCD-02", - "RSK-08" + "3.1.3.4.f.7": [ + "GOV-02" ], - "3.7.1(79)": [ - "BCD-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.1.3.4.f.8": [ + "GOV-02" ], - "3.7.2(80)": [ - "BCD-01" + "3.3.5.1": [ + "GOV-02", + "IAC-01" ], - "3.7.2(81)": [ - "BCD-01" + "3.3.5.4": [ + "GOV-02" ], - "3.7.2(82)": [ - "BCD-01", - "RSK-01.1", - "RSK-03", - "RSK-04" + "3.3.5.4.a": [ + "GOV-02" ], - "3.7.3(83)": [ - "BCD-01", - "BCD-02", - "BCD-12" + "3.3.5.4.b": [ + "GOV-02" ], - "3.7.3(84)(a)": [ - "BCD-01" + "3.3.5.4.b.1": [ + "GOV-02" ], - "3.7.3(84)(b)": [ - "BCD-01" + "3.3.5.4.b.2": [ + "GOV-02" ], - "3.7.3(84)(c)": [ - "BCD-01" + "3.3.5.4.b.3": [ + "GOV-02" ], - "3.7.3(85)": [ - "BCD-01" + "3.3.5.4.b.4": [ + "GOV-02" ], - "3.7.3(86)": [ - "BCD-01", - "BCD-10.3" + "3.3.5.4.b.5": [ + "GOV-02" ], - "3.7.4(87)": [ - "BCD-04" + "3.3.5.4.b.6": [ + "GOV-02" ], - "3.7.4(89)": [ - "BCD-04" + "3.3.5.4.b.7": [ + "GOV-02" ], - "3.7.4(89)(a)": [ - "BCD-04" + "3.3.5.4.c": [ + "GOV-02" ], - "3.7.4(89)(b)": [ - "BCD-04" + "3.3.5.4.d": [ + "GOV-02" ], - "3.7.4(89)(c)": [ - "BCD-04" + "3.3.5.4.e": [ + "GOV-02" ], - "3.7.4(90)": [ - "BCD-04", - "BCD-05", - "BCD-06" + "3.3.5.4.f": [ + "GOV-02" ], - "3.7.4(88)": [ - "BCD-05", - "BCD-06" + "3.3.5.4.f.1": [ + "GOV-02" ], - "3.5(57)": [ - "BCD-11" + "3.3.5.4.f.1.a": [ + "GOV-02" ], - "3.5(58)": [ - "BCD-11.2" + "3.3.5.4.f.1.b": [ + "GOV-02" ], - "3.5(56)": [ - "CAP-01" + "3.3.5.4.f.2": [ + "GOV-02" ], - "3.4.4(37)": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "CHG-02.3", - "CHG-03" + "3.3.5.4.f.3": [ + "GOV-02" ], - "3.6.3(75)": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "CHG-02.3", - "CHG-03" + "3.3.5.4.f.4": [ + "GOV-02" ], - "3.6.3(76)": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "CHG-02.3", - "CHG-03" + "3.3.5.4.f.4.a": [ + "GOV-02" ], - "3.1(1)": [ - "CPL-01" + "3.3.5.4.f.4.b": [ + "GOV-02" ], - "3.8(92)": [ - "CPL-01" + "3.3.5.4.f.4.c": [ + "GOV-02" ], - "3.8(93)": [ - "CPL-01" + "3.3.8": [ + "GOV-02" ], - "3.8(94)": [ - "CPL-01" + "3.3.8.1": [ + "GOV-02" ], - "3.8(95)": [ - "CPL-01" + "3.3.8.4": [ + "GOV-02" ], - "3.8(96)": [ - "CPL-01" + "3.3.8.5": [ + "GOV-02" ], - "3.8(97)": [ - "CPL-01" + "3.3.8.6": [ + "GOV-02" ], - "3.8(98)": [ - "CPL-01" + "3.3.8.6.a": [ + "GOV-02" ], - "3.3.6(25)": [ - "CPL-02.1", - "CPL-03.1" + "3.3.8.6.b": [ + "GOV-02" ], - "3.3.6(26)": [ - "CPL-03", - "CPL-03.2" + "3.3.8.6.c": [ + "GOV-02" ], - "3.3.6(27)": [ - "CPL-03", - "CPL-03.2" + "3.3.8.6.d": [ + "GOV-02" ], - "3.4.4(36)(b)": [ - "CFG-02" + "3.3.8.6.e": [ + "GOV-02" ], - "3.4.5(39)": [ - "MON-01", - "MON-01.2", - "MON-01.8", - "MON-01.16" + "3.3.8.6.f": [ + "GOV-02" ], - "3.4.5(40)": [ - "MON-01", - "MON-01.2", - "MON-01.8", - "MON-01.16" + "3.3.8.6.g": [ + "GOV-02" ], - "3.5(52)": [ - "MON-01", - "MON-01.16", - "MON-02", - "MON-02.2", - "MON-03" + "3.3.8.6.h": [ + "GOV-02" ], - "3.4.4(36)(e)": [ - "MON-01.7", - "END-06" + "3.3.8.6.h.1": [ + "GOV-02" ], - "3.4.5(38)(a)": [ - "MON-11.3", - "MON-16" + "3.3.8.6.h.2": [ + "GOV-02" ], - "3.4.5(38)(b)": [ - "MON-11.3", - "MON-16" + "3.3.8.6.h.3": [ + "GOV-02" ], - "3.4.5(38)(c)": [ - "MON-11.3", - "MON-16" + "3.3.8.6.h.4": [ + "GOV-02" ], - "3.4.4(36)(f)": [ - "CRY-01", - "CRY-03", - "CRY-05" + "3.3.8.6.h.5": [ + "GOV-02" ], - "3.3.3(19)": [ - "DCH-02" + "3.3.8.6.i": [ + "GOV-02" ], - "3.4.4(36)(d)": [ - "END-01" + "3.3.8.6.j": [ + "GOV-02" ], - "3.3.2(15)": [ - "HRS-01", - "HRS-02", - "HRS-03" + "3.3.10": [ + "GOV-02", + "MDM-01" ], - "3.4.2.(32)": [ - "IAC-08" + "3.3.10.1": [ + "GOV-02" ], - "3.5.1(59)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.3.2": [ + "GOV-03" ], - "3.5.1(60)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.4": [ + "GOV-04" ], - "3.5.1(60)(a)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.4.4": [ + "GOV-04" ], - "3.5.1(60)(b)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.4.4.a": [ + "GOV-04" ], - "3.5.1(60)(c)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.4.4.a.1": [ + "GOV-04" ], - "3.5.1(60)(d)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09" + "3.1.4.4.a.2": [ + "GOV-04" ], - "3.5.1(60)(d)(i)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07" + "3.1.4.4.a.3": [ + "GOV-04" ], - "3.5.1(60)(d)(ii)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-09" + "3.1.4.4.a.4": [ + "GOV-04" ], - "3.5.1(60)(e)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.4.4.b": [ + "GOV-04" ], - "3.5.1(60)(f)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.4.4.c": [ + "GOV-04" ], - "3.5.1(60)(f)(i)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.4.4.d": [ + "GOV-04" ], - "3.5.1(60)(f)(ii)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.1.4.4.e": [ + "GOV-04" ], - "3.6.2(70)": [ - "IAO-01", - "IAO-02", - "IAO-02.2", - "IAO-06", - "IAO-07", - "TDA-09", - "TDA-15" + "3.1.4.4.e.1": [ + "GOV-04" ], - "3.6.2(71)": [ - "IAO-02", - "IAO-02.2", - "IAO-06", - "IAO-07", - "TDA-09" + "3.1.4.4.e.2": [ + "GOV-04" ], - "3.3.1(13)(d)": [ - "IAO-05", - "RSK-01", - "RSK-04.1" + "3.1.4.4.e.3": [ + "GOV-04" ], - "3.4.4(36)(c)": [ - "NET-06" + "3.1.4.4.e.4": [ + "GOV-04" ], - "3.4.3(33)": [ - "PES-01" + "3.1.4.4.e.5": [ + "GOV-04" ], - "3.4.3(34)": [ - "PES-02.1" + "3.1.4.4.f": [ + "GOV-04" ], - "3.4.3(35)": [ - "PES-07", - "PES-07.1", - "PES-07.5", - "PES-08", - "PES-09" + "3.1.4.4.g": [ + "GOV-04" ], - "3.2.1(6)": [ - "PRM-01", - "OPS-02" + "3.1.4.4.g.1": [ + "GOV-04" ], - "3.6.1(61)": [ - "PRM-01", - "PRM-02", - "PRM-04" + "3.1.4.4.g.2": [ + "GOV-04" ], - "3.6.1(62)": [ - "PRM-01", - "PRM-02", - "PRM-04" + "3.1.4.4.g.3": [ + "GOV-04" ], - "3.6.1(64)": [ - "PRM-01", - "PRM-04", - "PRM-05", - "PRM-06" + "3.1.4.4.h": [ + "GOV-04" ], - "3.6.1(65)": [ - "PRM-01", - "PRM-04", - "PRM-05", - "PRM-06" + "3.1.4.4.i": [ + "GOV-04" ], - "3.6.1(66)": [ - "PRM-01", - "PRM-04", - "RSK-01.1" + "3.1.4.4.i.1": [ + "GOV-04" ], - "3.2.1(5)(a)": [ - "PRM-01.1" + "3.1.4.4.i.2": [ + "GOV-04" ], - "3.2.1(5)(b)": [ - "PRM-01.1" + "3.1.4.4.i.3": [ + "GOV-04" ], - "3.3.1(10)": [ - "PRM-04", - "RSK-01", - "RSK-01.1", - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05" + "3.1.4.4.i.4": [ + "GOV-04" ], - "3.3.1(13)(f)": [ - "PRM-04", - "PRM-07", - "RSK-01", - "RSK-07" + "3.1.4.1": [ + "GOV-04.1" ], - "3.6.1(63)(a)": [ - "PRM-04", - "PRM-07" + "3.1.4.1.a": [ + "GOV-04.1" ], - "3.6.1(63)(b)": [ - "PRM-04", - "PRM-07" + "3.1.4.1.b": [ + "GOV-04.1" ], - "3.6.1(63)(c)": [ - "PRM-04", - "PRM-07" + "3.1.4.1.c": [ + "GOV-04.1" ], - "3.6.1(63)(d)": [ - "PRM-04", - "PRM-07" + "3.1.4.1.c.1": [ + "GOV-04.1" ], - "3.6.1(63)(e)": [ - "PRM-04", - "PRM-07" + "3.1.4.1.c.2": [ + "GOV-04.1" ], - "3.6.1(63)(f)": [ - "PRM-04", - "PRM-07" + "3.1.4.1.c.3": [ + "GOV-04.1" ], - "3.5(51)": [ - "PRM-05", - "PRM-06" + "3.1.4.2": [ + "GOV-04.1" ], - "3.6.2(68)": [ - "PRM-05", - "PRM-06", - "TDA-01.1", - "TDA-02", - "TDA-15" + "3.1.4.2.a": [ + "GOV-04.1" ], - "3.5(55)": [ - "PRM-07", - "SEA-07.1", - "TPM-05.4", - "TPM-05.5" + "3.1.4.2.b": [ + "GOV-04.1" ], - "3.2.3(7)": [ - "RSK-01", - "TPM-01" + "3.1.4.2.c": [ + "GOV-04.1" ], - "3.3.1(13)(a)": [ - "RSK-01", - "RSK-01.5" + "3.1.4.2.c.1": [ + "GOV-04.1" ], - "3.3.1(13)(b)": [ - "RSK-01", - "RSK-03", - "RSK-04" + "3.1.4.2.c.2": [ + "GOV-04.1" ], - "3.3.1(13)(c)": [ - "RSK-01", - "RSK-06", - "RSK-06.1", - "RSK-06.2" + "3.1.4.2.c.3": [ + "GOV-04.1" ], - "3.3.3(20)": [ - "RSK-04" + "3.1.4.2.c.4": [ + "GOV-04.1" ], - "3.4.2.(31)": [ - "OPS-01.1" + "3.1.4.2.c.5": [ + "GOV-04.1" ], - "3.4.2(31)(a)": [ - "OPS-01.1" + "3.1.4.2.c.6": [ + "GOV-04.1" ], - "3.4.2(31)(b)": [ - "OPS-01.1" + "3.1.4.3": [ + "GOV-04.1" ], - "3.4.2(31)(c)": [ - "OPS-01.1" + "3.1.4.3.a": [ + "GOV-04.1" ], - "3.4.2(31)(d)": [ - "OPS-01.1" + "3.1.4.3.b": [ + "GOV-04.1" ], - "3.4.2(31)(e)": [ - "OPS-01.1" + "3.1.4.3.c": [ + "GOV-04.1" ], - "3.4.2(31)(f)": [ - "OPS-01.1" + "3.1.4.5": [ + "GOV-04.1" ], - "3.4.2(31)(g)": [ - "OPS-01.1" + "3.1.4.5.a": [ + "GOV-04.1" ], - "3.5(50)": [ - "OPS-01.1" + "3.4.2.3": [ + "GOV-19.3" ], - "3.4.7(49)": [ - "SAT-01", - "SAT-02", - "SAT-03" + "3.4.2.3.a": [ + "GOV-19.3" ], - "3.6.2(67)": [ - "TDA-01" + "3.4.2.3.b": [ + "GOV-19.3" ], - "3.6.2(74)": [ - "TDA-01", - "TDA-02.3", - "TPM-01", - "TPM-03", - "TPM-03.1", - "TPM-04.1" + "3.4.2.3.c": [ + "GOV-19.3" ], - "3.6.2(69)": [ - "TDA-02.3", - "TDA-02.4", - "TDA-02.7", - "TDA-04.1", - "TDA-05", - "TDA-06", - "TDA-06.2", - "TDA-06.5", - "TDA-07", - "TDA-08", - "TDA-09", - "TDA-15" + "3.3.3": [ + "AST-01" ], - "3.6.2(73)": [ - "TDA-04", - "TDA-20" + "3.3.3.1": [ + "AST-01" ], - "3.6.2(72)": [ - "TDA-07", - "TDA-08" + "3.3.3.3": [ + "AST-01", + "AST-02.9" ], - "3.2.3(8)": [ - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "3.3.3.3.a": [ + "AST-02.9" ], - "3.2.3(8)(a)": [ - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "3.3.3.3.b": [ + "AST-02.9" ], - "3.2.3(8)(b)": [ - "TPM-05", - "TPM-05.2", - "TPM-05.4", - "TPM-11" + "3.3.3.3.c": [ + "AST-02.9" ], - "3.2.3(9)": [ - "TPM-05.6", - "TPM-08" + "3.3.3.3.d": [ + "AST-02.9" ], - "3.3.3(21)": [ - "THR-03", - "VPM-01" + "3.3.3.3.e": [ + "AST-02.9" ], - "3.4.4(36)(a)": [ - "VPM-01" - ] - }, - "emea-eu-dora-2023": { - "Article 5.1": [ - "GOV-01" + "3.3.2.3.e": [ + "AST-09", + "PES-10", + "PES-12" ], - "Article 9.4": [ - "GOV-01" + "3.3.11": [ + "AST-09" ], - "Article 16.1(a)": [ - "GOV-01" + "3.3.11.1": [ + "AST-09" ], - "Article 16.1(b)": [ - "GOV-01" + "3.3.11.4": [ + "AST-09" ], - "Article 16.1(c)": [ - "GOV-01" + "3.3.11.5": [ + "AST-09" ], - "Article 16.1(d)": [ - "GOV-01" + "3.3.1.3.e.2": [ + "AST-10", + "HRS-01.1" ], - "Article 16.1(e)": [ - "GOV-01" + "3.3.10.4": [ + "AST-16" ], - "Article 16.1(f)": [ - "GOV-01" + "3.3.10.4.a": [ + "AST-16" ], - "Article 16.1(g)": [ - "GOV-01" + "3.3.10.4.b": [ + "AST-16" ], - "Article 16.1(h)": [ - "GOV-01" + "3.3.10.4.c": [ + "AST-16" ], - "Article 16.2": [ - "GOV-01" + "3.3.10.4.d": [ + "AST-16" ], - "Article 5.2": [ - "GOV-01.1", - "GOV-04" + "3.3.10.4.e": [ + "AST-16" ], - "Article 5.2(a)": [ - "GOV-01.1", - "GOV-04" + "3.3.7": [ + "CHG-01" ], - "Article 5.2(b)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.1": [ + "CHG-01" ], - "Article 5.2(c)": [ - "GOV-01.1", - "GOV-04", - "HRS-03" + "3.3.7.4": [ + "CHG-01" ], - "Article 5.2(d)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.4.c": [ + "CHG-02" ], - "Article 5.2(e)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.4.d": [ + "CHG-02" ], - "Article 5.2(f)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.4.e": [ + "CHG-02" ], - "Article 5.2(g)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.4.i": [ + "CHG-02" ], - "Article 5.2(h)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.4.b": [ + "CHG-02.2" ], - "Article 5.2(i)(i)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.4.a": [ + "CHG-03" ], - "Article 5.2(i)(ii)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.4.f": [ + "CHG-06" ], - "Article 5.2(i)(iii)": [ - "GOV-01.1", - "GOV-04" + "3.3.7.4.h": [ + "CHG-07" ], - "Article 5.2(i)": [ - "GOV-01.2" + "3.4.3": [ + "CLD-01" ], - "Article 13.5": [ - "GOV-01.2" + "3.4.3.1": [ + "CLD-01" ], - "Article 6.2": [ - "GOV-02", - "RSK-01", - "OPS-01.1" + "3.4.3.3": [ + "CLD-01" ], - "Article 9.4(a)": [ - "GOV-02" + "3.4.3.4": [ + "CLD-01" ], - "Article 9.4(d)": [ - "GOV-02", - "IAC-01" + "3.4.3.4.a": [ + "CLD-01" ], - "Article 9.4(e)": [ - "GOV-02", - "CHG-01", - "CHG-02", - "OPS-01.1" + "3.4.3.4.a.1": [ + "CLD-01" ], - "Article 9.4(f)": [ - "GOV-02", - "VPM-01", - "VPM-05" + "3.4.3.4.a.2": [ + "CLD-01" ], - "Article 5.3": [ - "GOV-04" + "3.4.3.4.a.3": [ + "CLD-01" ], - "Article 13.4": [ - "GOV-05" + "3.4.3.4.b": [ + "CLD-01" ], - "Article 31.4": [ - "GOV-06" + "3.4.3.4.b.1": [ + "CLD-01" ], - "Article 45.1": [ - "GOV-07", - "THR-01" + "3.4.3.4.c": [ + "CLD-01" ], - "Article 45.1(a)": [ - "GOV-07", - "THR-01" + "3.4.3.4.c.1": [ + "CLD-01" ], - "Article 45.1(b)": [ - "GOV-07", - "THR-01" + "3.4.3.4.d": [ + "CLD-01" ], - "Article 45.1(c)": [ - "GOV-07", - "THR-01" + "3.4.3.4.d.1": [ + "CLD-01" ], - "Article 45.2": [ - "GOV-07", - "THR-01" + "3.4.3.4.e": [ + "CLD-01" ], - "Article 7": [ - "GOV-15" + "3.4.3.4.e.1": [ + "CLD-01" ], - "Article 7(a)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "PRM-01", - "PRM-02", - "PRM-03", - "PRM-04", - "PRM-05", - "PRM-07" + "3.4.3.4.f": [ + "CLD-01" ], - "Article 7(b)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "PRM-01", - "PRM-02", - "PRM-03", - "PRM-04", - "PRM-05", - "PRM-07" + "3.4.3.4.f.1": [ + "CLD-01" ], - "Article 7(c)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "PRM-01", - "PRM-02", - "PRM-03", - "PRM-04", - "PRM-05", - "PRM-07" + "3.4.3.4.g": [ + "CLD-01" ], - "Article 7(d)": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "PRM-01", - "PRM-02", - "PRM-03", - "PRM-04", - "PRM-05", - "PRM-07" + "3.4.3.4.g.1": [ + "CLD-01" ], - "Article 9.3": [ - "GOV-15" + "3.4.3.4.g.2": [ + "CLD-01" ], - "Article 8.5": [ - "AST-01.1" + "3.4.3.4.g.3": [ + "CLD-01" ], - "Article 8.4": [ - "AST-02", - "AST-04", - "BCD-02", - "TPM-02" + "3.4.3.4.h": [ + "CLD-01.2" ], - "Article 8.6": [ - "AST-02", - "AST-02.1" + "3.4.3.4.h.1": [ + "CLD-01.2" ], - "Article 11.1": [ - "BCD-01" + "3.4.3.4.h.2": [ + "CLD-01.2" ], - "Article 11.2": [ - "BCD-01" + "3.4.3.4.h.3": [ + "CLD-01.2" ], - "Article 11.2(a)": [ - "BCD-01" + "3.2.2": [ + "CPL-01" ], - "Article 11.2(b)": [ - "BCD-01" + "3.2.2.1": [ + "CPL-01" ], - "Article 11.2(c)": [ - "BCD-01" + "3.2.2.1.a": [ + "CPL-01" ], - "Article 11.2(d)": [ - "BCD-01" + "3.2.2.1.b": [ + "CPL-01" ], - "Article 11.2(e)": [ - "BCD-01" + "3.2.2.1.c": [ + "CPL-01" ], - "Article 11.3": [ - "BCD-01" + "3.2.5": [ + "CPL-02" ], - "Article 11.4": [ - "BCD-01", - "BCD-04" + "3.2.5.1": [ + "CPL-02.1" ], - "Article 11.5": [ - "BCD-01", - "RSK-08" + "3.2.5.2": [ + "CPL-02.2" ], - "Article 11.6(a)": [ - "BCD-01", - "BCD-04" + "3.2.4": [ + "CPL-03" ], - "Article 11.6(b)": [ - "BCD-01", - "BCD-04" + "3.2.4.1": [ + "CPL-03" ], - "Article 11.7": [ - "BCD-01" + "3.2.4.2": [ + "CPL-03" ], - "Article 11.8": [ - "BCD-01" + "3.2.4.3": [ + "CPL-03" ], - "Article 11.9": [ - "BCD-01" + "3.2.4.4": [ + "CPL-03" ], - "Article 11.10": [ - "BCD-01" + "3.2.4.5": [ + "CPL-03" ], - "Article 11.11": [ - "BCD-01" + "3.2.4.5.a": [ + "CPL-03" ], - "Article 12.1": [ - "BCD-01", - "BCD-11" + "3.2.4.5.b": [ + "CPL-03" ], - "Article 12.1(a)": [ - "BCD-01", - "BCD-11" + "3.2.4.5.c": [ + "CPL-03" ], - "Article 12.1(b)": [ - "BCD-01", - "BCD-11" + "3.3.1.2": [ + "CPL-03" ], - "Article 12.6": [ - "BCD-01.4" + "3.3.2.2": [ + "CPL-03" ], - "Article 11.6 (end)": [ - "BCD-04" + "3.3.3.2": [ + "CPL-03" ], - "Article 24.1": [ - "BCD-04" + "3.3.4.2": [ + "CPL-03" ], - "Article 24.2": [ - "BCD-04" + "3.3.5.2": [ + "CPL-03" ], - "Article 24.3": [ - "BCD-04" + "3.3.5.3": [ + "CPL-03" ], - "Article 24.4": [ - "BCD-04" + "3.3.6.2": [ + "CPL-03" ], - "Article 24.5": [ - "BCD-04" + "3.3.6.3": [ + "CPL-03" ], - "Article 24.6": [ - "BCD-04" + "3.3.7.2": [ + "CPL-03" ], - "Article 13.2": [ - "BCD-05", - "IRO-13" + "3.3.7.3": [ + "CPL-03" ], - "Article 13.2(a)": [ - "BCD-05", - "IRO-13" + "3.3.8.2": [ + "CPL-03" ], - "Article 13.2(b)": [ - "BCD-05", - "IRO-13" + "3.3.8.3": [ + "CPL-03" ], - "Article 13.2(c)": [ - "BCD-05", - "IRO-13" + "3.3.9.2": [ + "CPL-03" ], - "Article 13.2(d)": [ - "BCD-05", - "IRO-13" + "3.3.9.3": [ + "CPL-03" ], - "Article 13.3": [ - "BCD-05", - "IRO-13" + "3.3.10.2": [ + "CPL-03" ], - "Article 12.5": [ - "BCD-09" + "3.3.10.3": [ + "CPL-03" ], - "Article 12.5(a)": [ - "BCD-09", - "BCD-09.1" + "3.3.11.2": [ + "CPL-03" ], - "Article 12.5(b)": [ - "BCD-09" + "3.3.11.3": [ + "CPL-03" ], - "Article 12.5(c)": [ - "BCD-09", - "BCD-09.2" + "3.3.14.2": [ + "CPL-03" ], - "Article 12.2": [ - "BCD-11", - "BCD-11.1", - "BCD-11.5" + "3.3.14.4.i": [ + "CPL-03" ], - "Article 12.7": [ - "BCD-11.1", - "BCD-11.5" + "3.3.14.4.l": [ + "CPL-03" ], - "Article 12.3": [ - "BCD-11.2", - "BCD-11.6" + "3.3.15": [ + "CPL-03" ], - "Article 12.4": [ - "BCD-11.7", - "BCD-12.2" + "3.3.15.2": [ + "CPL-03" ], - "Article 4.1": [ - "CPL-01" + "3.3.16": [ + "CPL-03" ], - "Article 4.2": [ - "CPL-01" + "3.3.16.2": [ + "CPL-03" ], - "Article 4.3": [ - "CPL-01" + "3.3.17.2": [ + "CPL-03" ], - "Article 5.4": [ - "CPL-01" + "3.4.1.2": [ + "CPL-03" ], - "Article 23": [ - "CPL-01.2" + "3.4.1.3": [ + "CPL-03" ], - "Article 9.3(a)": [ - "CFG-01", - "CFG-02", - "SEA-01", - "SEA-02", - "SEA-03" + "3.4.2": [ + "CPL-03" ], - "Article 9.3(b)": [ - "CFG-01", - "CFG-02", - "SEA-01", - "SEA-02", - "SEA-03" + "3.4.2.2": [ + "CPL-03" ], - "Article 9.3(c)": [ - "CFG-01", - "CFG-02", - "SEA-01", - "SEA-02", - "SEA-03" + "3.4.3.2": [ + "CPL-03" ], - "Article 9.3(d)": [ - "CFG-01", - "CFG-02", - "SEA-01", - "SEA-02", - "SEA-03" + "3.3.6": [ + "CFG-02" ], - "Article 10.3": [ + "3.3.6.1": [ + "CFG-02" + ], + "3.3.13.4.c.2": [ + "CFG-02" + ], + "3.3.14": [ "MON-01" ], - "Article 10.1": [ - "MON-16" + "3.3.14.1": [ + "MON-01" ], - "Article 9.4(c)": [ - "IAC-21" + "3.3.14.3": [ + "MON-01" ], - "Article 9.4(b)": [ - "IRO-01", - "IRO-02", - "IRO-02.1", - "IRO-02.6" + "3.3.14.4": [ + "MON-01" ], - "Article 14.1": [ - "IRO-01", - "IRO-02", - "IRO-07", - "IRO-10", - "IRO-11" + "3.3.14.4.a": [ + "MON-01" ], - "Article 14.2": [ - "IRO-01", - "IRO-02", - "IRO-07", - "IRO-10", - "IRO-11" + "3.3.14.4.b": [ + "MON-01" ], - "Article 14.3": [ - "IRO-01", - "IRO-02", - "IRO-07", - "IRO-10", - "IRO-11" + "3.3.14.4.c": [ + "MON-01" ], - "Article 17.1": [ - "IRO-01", - "IRO-04" + "3.3.14.4.d": [ + "MON-01" ], - "Article 17.2": [ - "IRO-01", - "IRO-04" + "3.3.14.4.e": [ + "MON-01" ], - "Article 17.3": [ - "IRO-01" + "3.3.14.4.f": [ + "MON-01" ], - "Article 17.3(a)": [ - "IRO-01", - "IRO-04" + "3.3.14.4.g": [ + "MON-01" ], - "Article 17.3(b)": [ - "IRO-01", - "IRO-04" + "3.3.14.4.j": [ + "MON-01.2" ], - "Article 17.3(c)": [ - "IRO-01", - "IRO-04" + "3.3.14.4.k": [ + "MON-01.2" ], - "Article 17.3(d)": [ - "IRO-01", - "IRO-04" + "3.3.14.3.a": [ + "MON-03" ], - "Article 17.3(e)": [ - "IRO-01", - "IRO-04" + "3.3.14.4.h": [ + "MON-08" ], - "Article 17.3(f)": [ - "IRO-01", - "IRO-04" + "3.3.9": [ + "CRY-01" ], - "Article 18.1": [ - "IRO-02" + "3.3.9.1": [ + "CRY-01" ], - "Article 18.1(a)": [ - "IRO-02" + "3.3.9.4": [ + "CRY-01" ], - "Article 18.1(b)": [ - "IRO-02" + "3.3.9.4.a": [ + "CRY-01" ], - "Article 18.1(c)": [ - "IRO-02" + "3.3.9.4.b": [ + "CRY-01" ], - "Article 18.1(d)": [ - "IRO-02" + "3.3.9.4.c": [ + "CRY-01" ], - "Article 18.1(e)": [ - "IRO-02" + "3.3.1": [ + "HRS-01" ], - "Article 18.1(f)": [ - "IRO-02" + "3.3.1.1": [ + "HRS-01" ], - "Article 18.2": [ - "IRO-02" + "3.3.1.3": [ + "HRS-01" ], - "Article 19.1": [ - "IRO-10" + "3.3.1.3.e.1": [ + "HRS-01.1" ], - "Article 19.2": [ - "IRO-10" + "3.1.4.6": [ + "HRS-03" ], - "Article 19.3": [ - "IRO-10" + "3.1.4.6.a": [ + "HRS-03" ], - "Article 19.4": [ - "IRO-10" + "3.3.1.3.a": [ + "HRS-03", + "HRS-06.1" ], - "Article 19.4(a)": [ - "IRO-10" + "3.3.1.3.d": [ + "HRS-04", + "HRS-04.1" ], - "Article 19.4(b)": [ - "IRO-10" + "3.3.1.3.b": [ + "HRS-04.2", + "HRS-05.7", + "SAT-02" ], - "Article 19.4(c)": [ - "IRO-10" + "3.3.1.3.e": [ + "HRS-06.2" ], - "Article 19.5": [ - "IRO-10" + "3.3.1.3.c": [ + "HRS-07" ], - "Article 45.3": [ - "IRO-10", - "THR-01" + "3.3.5": [ + "IAC-21" ], - "Article 10.2": [ - "NET-08" + "3.3.15.1": [ + "IRO-01" ], - "Article 6.8": [ - "PRM-01.1", - "RSK-01" + "3.3.15.3": [ + "IRO-02" ], - "Article 6.8(a)": [ - "PRM-01.1", - "RSK-01" + "3.3.15.4": [ + "IRO-02" ], - "Article 6.8(b)": [ - "PRM-01.1", - "RSK-01" + "3.3.15.4.a": [ + "IRO-02" ], - "Article 6.8(c)": [ - "PRM-01.1", - "RSK-01" + "3.3.15.4.b": [ + "IRO-02" ], - "Article 6.8(d)": [ - "PRM-01.1", - "RSK-01" + "3.3.15.4.c": [ + "IRO-02" ], - "Article 6.8(e)": [ - "PRM-01.1", - "RSK-01" + "3.3.15.4.d": [ + "IRO-02" ], - "Article 6.8(f)": [ - "PRM-01.1", - "RSK-01" + "3.3.15.4.e": [ + "IRO-02" ], - "Article 6.8(g)": [ - "PRM-01.1", - "RSK-01" + "3.3.15.4.f": [ + "IRO-02" ], - "Article 6.8(h)": [ - "PRM-01.1", - "RSK-01" + "3.3.15.4.g": [ + "IRO-02" ], - "Article 8.1": [ - "PRM-06" + "3.3.15.4.h": [ + "IRO-02" ], - "Article 6.1": [ - "RSK-01" + "3.3.15.4.i": [ + "IRO-02" ], - "Article 6.3": [ - "RSK-01" + "3.3.15.4.j": [ + "IRO-02" ], - "Article 6.4": [ - "RSK-01" + "3.3.15.7": [ + "IRO-10.5" ], - "Article 6.5": [ - "RSK-01" + "3.3.15.7.a": [ + "IRO-10.5" ], - "Article 6.6": [ - "RSK-01" + "3.3.15.7.b": [ + "IRO-10.5" ], - "Article 6.7": [ - "RSK-01" + "3.3.15.7.c": [ + "IRO-10.5" ], - "Article 6.9": [ - "RSK-01" + "3.3.15.7.d": [ + "IRO-10.5" ], - "Article 6.10": [ - "RSK-01" + "3.3.15.7.e": [ + "IRO-10.5" ], - "Article 11.6": [ - "RSK-01" + "3.3.15.7.f": [ + "IRO-10.5" ], - "Article 8.2": [ - "RSK-01.1", - "RSK-03" + "3.3.15.7.g": [ + "IRO-10.5" ], - "Article 8.3": [ - "RSK-04" + "3.3.15.7.h": [ + "IRO-10.5" ], - "Article 8.7": [ - "RSK-04", - "SEA-02.3" + "3.3.15.7.i": [ + "IRO-10.5" ], - "Article 28.1": [ - "RSK-09", - "TPM-01.1" + "3.3.15.7.j": [ + "IRO-10.5" ], - "Article 28.1(a)": [ - "RSK-09", - "TPM-01.1", - "TPM-05" + "3.3.15.7.k": [ + "IRO-10.5" ], - "Article 28.1(b)": [ - "RSK-09", - "TPM-01.1" + "3.3.7.4.b.1": [ + "IAO-02.2" ], - "Article 28.1(b)(i)": [ - "RSK-09", - "TPM-01.1" + "3.3.7.4.b.2": [ + "IAO-02.2" ], - "Article 28.1(b)(ii)": [ - "RSK-09", - "TPM-01.1" + "3.3.7.4.b.3": [ + "IAO-02.2" ], - "Article 28.2": [ - "RSK-09", - "TPM-01.1" + "3.3.7.4.b.4": [ + "IAO-02.2" ], - "Article 28.3": [ - "RSK-09", - "TPM-01.1" + "3.2.1.4-2.2": [ + "IAO-05", + "RSK-06.4" ], - "Article 28.4": [ - "RSK-09" + "3.3.2": [ + "PES-01" ], - "Article 28.4(a)": [ - "RSK-09", - "RSK-09.1", - "TPM-01.1", - "TPM-04.1" + "3.3.2.1": [ + "PES-01" ], - "Article 28.4(b)": [ - "RSK-09", - "RSK-09.1", - "TPM-01.1", - "TPM-04.1" + "3.3.2.3": [ + "PES-01" ], - "Article 28.4(c)": [ - "RSK-09", - "RSK-09.1", - "TPM-01.1", - "TPM-04.1" + "3.3.2.3.a": [ + "PES-03" ], - "Article 28.4(d)": [ - "RSK-09", - "RSK-09.1", - "TPM-01.1", - "TPM-04.1" + "3.3.2.3.c": [ + "PES-04" ], - "Article 28.4(e)": [ - "RSK-09", - "RSK-09.1", - "TPM-01.1", - "TPM-04.1" + "3.3.2.3.b": [ + "PES-05.1" ], - "Article 28.5": [ - "RSK-09", - "TPM-01.1" + "3.3.2.3.d": [ + "PES-07" ], - "Article 28.6": [ - "RSK-09", - "TPM-01.1", - "TPM-08" + "3.1.5.1": [ + "PRM-01", + "PRM-04" ], - "Article 28.7(a)": [ - "RSK-09", - "TPM-01.1", - "TPM-05.7" + "3.1.2": [ + "PRM-01.1" ], - "Article 28.7(b)": [ - "RSK-09", - "TPM-01.1", - "TPM-05.7" + "3.1.2.1": [ + "PRM-01.1" ], - "Article 28.7(c)": [ - "RSK-09", - "TPM-01.1", - "TPM-05.7" + "3.1.2.2": [ + "PRM-01.1" ], - "Article 28.7(d)": [ - "RSK-09", - "TPM-01.1", - "TPM-05.7" + "3.1.2.2.a": [ + "PRM-01.1" ], - "Article 28.8": [ - "RSK-09", - "TPM-01.1", - "TPM-05.7" + "3.1.2.2.b": [ + "PRM-01.1" ], - "Article 28.8(a)": [ - "RSK-09", - "TPM-01.1", - "TPM-05.7" + "3.1.2.2.c": [ + "PRM-01.1" ], - "Article 28.8(b)": [ - "RSK-09", - "TPM-01.1", - "TPM-05.7" + "3.1.2.3": [ + "PRM-01.1" ], - "Article 28.8(c)": [ - "RSK-09", - "TPM-01.1", - "TPM-05.7" + "3.1.2.3.a": [ + "PRM-01.1" ], - "Article 9 (end)": [ - "SEA-01" + "3.1.2.3.b": [ + "PRM-01.1" ], - "Article 9.1": [ - "OPS-01", - "OPS-02", - "OPS-03" + "3.1.2.3.c": [ + "PRM-01.1" ], - "Article 9.2": [ - "OPS-01", - "OPS-01.1", - "OPS-02", - "OPS-03" + "3.1.1.10": [ + "PRM-03" ], - "Article 13.6": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.6" + "3.1.5": [ + "PRM-04", + "PRM-07" ], - "Article 13.7": [ - "TDA-01", - "TDA-01.1" + "3.1.5.2": [ + "PRM-04" ], - "Article 28.8 (end)": [ - "TDA-17.1" + "3.1.5.2.a": [ + "PRM-04" ], - "Article 30.3 (end)": [ - "TPM-01" + "3.1.5.2.b": [ + "PRM-04" ], - "Article 31.12": [ - "TPM-01" + "3.1.5.2.c": [ + "PRM-04" ], - "Article 30.3(f)": [ - "TPM-03" + "3.1.5.2.d": [ + "PRM-04" ], - "Article 29.1 (end)": [ - "TPM-03.1" + "3.1.5.2.e": [ + "PRM-04" ], - "Article 29.1": [ - "TPM-04" + "3.1.5.2.f": [ + "PRM-04" ], - "Article 29.1(a)": [ - "TPM-04.1" + "3.2.1": [ + "RSK-01" ], - "Article 29.1(b)": [ - "TPM-04.1" + "3.2.1.1-1": [ + "RSK-01" ], - "Article 29.2": [ - "TPM-05", - "TPM-05.2" + "3.2.1.2-1": [ + "RSK-01" ], - "Article 30.1": [ - "TPM-05" + "3.2.1.3-1": [ + "RSK-01" ], - "Article 30.2": [ - "TPM-05" + "3.2.1.4-1": [ + "RSK-01" ], - "Article 30.2(a)": [ - "TPM-05" + "3.2.1.5": [ + "RSK-01" ], - "Article 30.2(b)": [ - "TPM-05" + "3.2.1.5.a": [ + "RSK-01" ], - "Article 30.2(c)": [ - "TPM-05" + "3.2.1.5.b": [ + "RSK-01" ], - "Article 30.2(d)": [ - "TPM-05" + "3.2.1.5.c": [ + "RSK-01" ], - "Article 30.2(e)": [ - "TPM-05" + "3.2.1.6": [ + "RSK-01" ], - "Article 30.2(f)": [ - "TPM-05" + "3.2.1.6.a": [ + "RSK-01" ], - "Article 30.2(g)": [ - "TPM-05" + "3.2.1.6.b": [ + "RSK-01" ], - "Article 30.2(h)": [ - "TPM-05" + "3.2.1.6.c": [ + "RSK-01" ], - "Article 30.2(i)": [ - "TPM-05" + "3.2.1.6.d": [ + "RSK-01" ], - "Article 30.3": [ - "TPM-05" + "3.2.1.7": [ + "RSK-01" ], - "Article 30.3(a)": [ - "TPM-05" + "3.2.1.8": [ + "RSK-01" ], - "Article 30.3(b)": [ - "TPM-05" + "3.2.1.8.a": [ + "RSK-01" ], - "Article 30.3(c)": [ - "TPM-05" + "3.2.1.8.b": [ + "RSK-01" ], - "Article 30.3(d)": [ - "TPM-05" + "3.2.1.8.c": [ + "RSK-01" ], - "Article 30.3(e)(i)": [ - "TPM-05" + "3.2.1.8.d": [ + "RSK-01" ], - "Article 30.3(e)(ii)": [ - "TPM-05" + "3.2.1.11": [ + "RSK-01.3", + "RSK-01.5" ], - "Article 30.3(e)(iii)": [ - "TPM-05" + "3.2.1.4-1.a": [ + "RSK-03" ], - "Article 30.3(e)(iv)": [ - "TPM-05" + "3.2.1.1-2": [ + "RSK-03" ], - "Article 30.3(f)(i)": [ - "TPM-05" + "3.2.1.1-2.1": [ + "RSK-03" ], - "Article 30.4": [ - "TPM-05" + "3.2.1.1-2.3": [ + "RSK-03" ], - "Article 28.7": [ - "TPM-05.7" + "3.2.1.1-2.2": [ + "RSK-03.1", + "RSK-04.1" ], - "Article 30.3(e)": [ - "TPM-08" + "3.2.1.4-1.b": [ + "RSK-04" ], - "Article 13.1": [ - "THR-01", - "THR-03" + "3.2.1.2-2": [ + "RSK-04" ], - "Article 25.1": [ - "VPM-01", - "VPM-06" + "3.2.1.2-2.1": [ + "RSK-04" ], - "Article 25.2": [ - "VPM-01", - "VPM-06" + "3.2.1.2-2.2": [ + "RSK-04" ], - "Article 25.3": [ - "VPM-01", - "VPM-06" + "3.2.1.4-1.c": [ + "RSK-04.1" ], - "Article 26.1": [ - "VPM-07" + "3.2.1.9": [ + "RSK-04.4" ], - "Article 26.2": [ - "VPM-07" + "3.2.1.3-2": [ + "RSK-06" ], - "Article 26.3": [ - "VPM-07" + "3.2.1.3-2.1": [ + "RSK-06" ], - "Article 26.4": [ - "VPM-07" + "3.2.1.4-1.d": [ + "RSK-06.1", + "RSK-11" ], - "Article 26.5": [ - "VPM-07" + "3.2.1.3-2.6": [ + "RSK-06.2" ], - "Article 26.6": [ - "VPM-07" + "3.2.1.3-2.6.a": [ + "RSK-06.2" ], - "Article 26.7": [ - "VPM-07" + "3.2.1.3-2.6.b": [ + "RSK-06.2" ], - "Article 26.8": [ - "VPM-07" + "3.2.1.3-2.6.b.1": [ + "RSK-06.2" ], - "Article 26.8(a)": [ - "VPM-07" + "3.2.1.3-2.6.b.2": [ + "RSK-06.2" ], - "Article 26.8(b)": [ - "VPM-07" + "3.2.1.3-2.6.b.3": [ + "RSK-06.2" ], - "Article 26.8(c)": [ - "VPM-07" + "3.2.1.3-2.6.c": [ + "RSK-06.2" ], - "Article 27.1": [ - "VPM-07.1" + "3.2.1.3-2.6.d": [ + "RSK-06.2" ], - "Article 27.1(a)": [ - "VPM-07.1" + "3.2.1.10": [ + "RSK-06.3", + "RSK-13" ], - "Article 27.1(b)": [ - "VPM-07.1" + "3.2.1.3-2.3": [ + "RSK-06.3" ], - "Article 27.1(c)": [ - "VPM-07.1" + "3.2.1.3-2.3.a": [ + "RSK-06.3" ], - "Article 27.1(d)": [ - "VPM-07.1" + "3.2.1.3-2.3.b": [ + "RSK-06.3" ], - "Article 27.1(e)": [ - "VPM-07.1" + "3.2.1.3-2.3.b.1": [ + "RSK-06.3" ], - "Article 27.2": [ - "VPM-07.1" + "3.2.1.3-2.3.b.2": [ + "RSK-06.3" ], - "Article 27.2(a)": [ - "VPM-07.1" + "3.2.1.3-2.4": [ + "RSK-06.3" ], - "Article 27.2(b)": [ - "VPM-07.1" + "3.2.1.3-2.5": [ + "RSK-06.3" ], - "Article 27.2(c)": [ - "VPM-07.1" + "3.2.1.3-2.5.a": [ + "RSK-06.3" ], - "Article 27.3": [ - "VPM-07.1" - ] - }, - "emea-eu-gdpr-2016": { - "Article 24.2": [ - "GOV-02" + "3.2.1.3-2.5.b": [ + "RSK-06.3" ], - "Article 32.1(c)": [ - "BCD-01" + "3.2.1.3-2.5.c": [ + "RSK-06.3" ], - "Article 3.1": [ - "CPL-01.2" + "3.2.1.3-2.2": [ + "RSK-06.4" ], - "Article 3.2": [ - "CPL-01.2" + "3.2.1.3-2.7": [ + "RSK-06.4" ], - "Article 3.2(a)": [ - "CPL-01.2" + "3.2.1.4-2": [ + "RSK-06.4" ], - "Article 3.2(b)": [ - "CPL-01.2" + "3.2.1.4-2.1": [ + "RSK-06.4" ], - "Article 3.3": [ - "CPL-01.2" + "3.2.1.4-2.1.a": [ + "RSK-06.4" ], - "Article 5.2": [ - "CPL-01.3" + "3.2.1.4-2.1.b": [ + "RSK-06.4" ], - "Article 12.1": [ - "CPL-01.3" + "3.3.4": [ + "SEA-01.4" ], - "Article 30.4": [ - "CPL-01.3" + "3.3.4.1": [ + "SEA-01.4" ], - "Article 31": [ - "CPL-01.3" + "3.3.4.3": [ + "SEA-01.4" ], - "Article 32.1(d)": [ - "CPL-02", - "CPL-02.2" + "3.3.4.3.a": [ + "SEA-01.4" ], - "Article 32.1(a)": [ - "CRY-01", - "PRI-01.6" + "3.3.4.3.b": [ + "SEA-01.4" ], - "Article 44": [ - "DCH-25" + "3.3.4.3.c": [ + "SEA-01.4" ], - "Article 45.1": [ - "DCH-25", - "PRI-01.5" + "3.3.4.3.d": [ + "SEA-01.4" ], - "Article 46.1": [ - "DCH-25", - "PRI-01.5" + "3.3.4.3.e": [ + "SEA-01.4" ], - "Article 46.2": [ - "DCH-25" + "3.1.6": [ + "SAT-01" ], - "Article 46.2(a)": [ - "DCH-25" + "3.1.6.1": [ + "SAT-01" ], - "Article 49.1": [ - "DCH-25" + "3.1.6.2": [ + "SAT-01" ], - "Article 49.1(a)": [ - "DCH-25" + "3.1.6.2.a": [ + "SAT-01" ], - "Article 49.1(b)": [ - "DCH-25" + "3.1.6.2.b": [ + "SAT-01" ], - "Article 49.1(c)": [ - "DCH-25" + "3.1.6.2.c": [ + "SAT-01" ], - "Article 49.1(d)": [ - "DCH-25" + "3.1.6.3": [ + "SAT-01" ], - "Article 49.1(e)": [ - "DCH-25" + "3.1.6.4": [ + "SAT-01" ], - "Article 49.1(f)": [ - "DCH-25" + "3.1.6.5": [ + "SAT-01" ], - "Article 49.1(g)": [ - "DCH-25" + "3.1.6.5.a": [ + "SAT-01" ], - "Article 49.2": [ - "DCH-25" + "3.1.6.5.b": [ + "SAT-01" ], - "Article 49.3": [ - "DCH-25" + "3.1.6.5.c": [ + "SAT-01" ], - "Article 49.4": [ - "DCH-25" + "3.1.6.6": [ + "SAT-01.1" ], - "Article 49.6": [ - "DCH-25" + "3.1.6.6.a": [ + "SAT-01.1" ], - "Article 32.4": [ - "HRS-02", - "HRS-03", - "IAC-08" + "3.1.6.6.b": [ + "SAT-01.1" ], - "Article 33.1": [ - "IRO-04.1", - "IRO-10.2" + "3.1.6.7": [ + "SAT-02" ], - "Article 33.5": [ - "IRO-09" + "3.1.7": [ + "SAT-02" ], - "Article 34.1": [ - "IRO-10" + "3.1.7.1": [ + "SAT-03" ], - "Article 34.2": [ - "IRO-10" + "3.1.7.1.a": [ + "SAT-03" ], - "Article 33.2": [ - "IRO-10.2" + "3.1.7.1.b": [ + "SAT-03" ], - "Article 33.3(a)": [ - "IRO-10.2" + "3.1.7.1.c": [ + "SAT-03" ], - "Article 33.3(b)": [ - "IRO-10.2" + "3.1.7.1.d": [ + "SAT-03" ], - "Article 33.3(c)": [ - "IRO-10.2" + "3.1.7.2": [ + "SAT-03" ], - "Article 33.3(d)": [ - "IRO-10.2" + "3.3.6.4": [ + "TDA-06" ], - "Article 33.4": [ - "IRO-10.2" + "3.3.6.5": [ + "TDA-06" ], - "Article 5.1(a)": [ - "PRI-01" + "3.3.6.5.a": [ + "TDA-06" ], - "Article 9.1": [ - "PRI-01" + "3.3.6.5.b": [ + "TDA-06" ], - "Article 12.2": [ - "PRI-01" + "3.3.6.5.c": [ + "TDA-06" ], - "Article 27.1": [ - "PRI-01.4" + "3.3.6.5.d": [ + "TDA-06" ], - "Article 27.3": [ - "PRI-01.4" + "3.3.6.5.e": [ + "TDA-06" ], - "Article 27.4": [ - "PRI-01.4" + "3.3.6.5.f": [ + "TDA-06" ], - "Article 27.5": [ - "PRI-01.4" + "3.3.6.5.g": [ + "TDA-06" ], - "Article 35.2": [ - "PRI-01.4" + "3.3.7.4.g": [ + "TDA-08" ], - "Article 37.1": [ - "PRI-01.4" + "3.4.1": [ + "TPM-01" ], - "Article 37.1(a)": [ - "PRI-01.4" + "3.4.1.1": [ + "TPM-01" ], - "Article 37.1(b)": [ - "PRI-01.4" + "3.4.1.4": [ + "TPM-01" ], - "Article 37.1(c)": [ - "PRI-01.4" + "3.4.1.4.a": [ + "TPM-01" ], - "Article 37.2": [ - "PRI-01.4" + "3.4.1.6": [ + "TPM-01" ], - "Article 37.3": [ - "PRI-01.4" + "3.4.1.6.a": [ + "TPM-01" ], - "Article 37.4": [ - "PRI-01.4" + "3.4.2.1": [ + "TPM-01" ], - "Article 37.5": [ - "PRI-01.4" + "3.4.1.4.b": [ + "TPM-05" ], - "Article 37.6": [ - "PRI-01.4" + "3.4.1.4.c": [ + "TPM-05" ], - "Article 37.7": [ - "PRI-01.4" + "3.4.1.5": [ + "TPM-05" ], - "Article 38.1": [ - "PRI-01.4" + "3.4.1.5.a": [ + "TPM-05" ], - "Article 38.2": [ - "PRI-01.4" + "3.4.1.5.b": [ + "TPM-05" ], - "Article 38.3": [ - "PRI-01.4" + "3.4.1.5.c": [ + "TPM-05" ], - "Article 38.4": [ - "PRI-01.4" + "3.4.1.5.d": [ + "TPM-05" ], - "Article 38.5": [ - "PRI-01.4" + "3.4.1.5.e": [ + "TPM-05" ], - "Article 38.6": [ - "PRI-01.4" + "3.4.1.5.f": [ + "TPM-05" ], - "Article 39.1": [ - "PRI-01.4" + "3.4.1.5.g": [ + "TPM-05" ], - "Article 39.1(a)": [ - "PRI-01.4" + "3.3.11.6": [ + "TPM-08" ], - "Article 39.1(b)": [ - "PRI-01.4" + "3.3.16.1": [ + "THR-01" ], - "Article 39.1(c)": [ - "PRI-01.4" + "3.3.16.3": [ + "THR-01" ], - "Article 39.1(d)": [ - "PRI-01.4" + "3.3.16.3.a": [ + "THR-01" ], - "Article 39.1(e)": [ - "PRI-01.4" + "3.3.16.3.c": [ + "THR-01" ], - "Article 39.2": [ - "PRI-01.4" + "3.3.16.3.d": [ + "THR-01" ], - "Article 46.2(b)": [ - "PRI-01.5" + "3.3.16.3.e": [ + "THR-01" ], - "Article 5.1(f)": [ - "PRI-01.6" + "3.3.16.3.b": [ + "THR-03" ], - "Article 24.1": [ - "PRI-01.6" + "3.3.16.3.f": [ + "THR-03.1" ], - "Article 25.1": [ - "PRI-01.6" + "3.3.17": [ + "VPM-01" ], - "Article 25.2": [ - "PRI-01.6" + "3.3.17.1": [ + "VPM-01" ], - "Article 32.1": [ - "PRI-01.6" + "3.3.17.3": [ + "VPM-01" ], - "Article 32.1(b)": [ - "PRI-01.6" + "3.3.17.3.a": [ + "VPM-01" ], - "Article 12.7": [ - "PRI-02" + "3.3.17.3.b": [ + "VPM-01" ], - "Article 13.1(a)": [ - "PRI-02" + "3.3.17.3.c": [ + "VPM-01" ], - "Article 13.1(b)": [ - "PRI-02" + "3.3.17.3.d": [ + "VPM-01" ], - "Article 13.1(c)": [ - "PRI-02", - "PRI-02.1" + "3.3.17.3.e": [ + "VPM-01" ], - "Article 13.1(d)": [ - "PRI-02" + "3.3.17.3.f": [ + "VPM-01" + ] + }, + "emea-srb-act-9-2018": { + "IV.1.49": [ + "CPL-01" ], - "Article 13.1(e)": [ - "PRI-02", - "PRI-05.7" + "IV.1.44": [ + "CPL-08" ], - "Article 13.2": [ - "PRI-02" + "IV.2.50(1)": [ + "DCH-23" ], - "Article 13.2(a)": [ - "PRI-02" + "IV.2.52": [ + "IRO-10" ], - "Article 13.2(b)": [ - "PRI-02" + "IV.2.52(1)": [ + "IRO-10" ], - "Article 13.2(c)": [ - "PRI-02" + "IV.2.52(2)": [ + "IRO-10" ], - "Article 13.2(d)": [ - "PRI-02" + "IV.2.52(3)": [ + "IRO-10" ], - "Article 13.2(e)": [ - "PRI-02" + "IV.2.52(4)": [ + "IRO-10" ], - "Article 13.2(f)": [ - "PRI-02" + "IV.2.53": [ + "IRO-10" ], - "Article 13.3": [ - "PRI-02" + "IV.4.56": [ + "PRI-01.4" ], - "Article 14.1(a)": [ - "PRI-02" + "IV.4.56(1)": [ + "PRI-01.4" ], - "Article 14.1(b)": [ - "PRI-02" + "IV.4.56(2)": [ + "PRI-01.4" ], - "Article 14.1(c)": [ - "PRI-02", - "PRI-02.1" + "IV.4.56(3)": [ + "PRI-01.4" ], - "Article 14.1(d)": [ - "PRI-02", - "PRI-05.7" + "IV.4.57": [ + "PRI-01.4" ], - "Article 14.1(e)": [ - "PRI-02" + "IV.4.58": [ + "PRI-01.4" ], - "Article 14.1(f)": [ - "PRI-02" + "IV.4.58(1)": [ + "PRI-01.4" ], - "Article 14.2": [ - "PRI-02" + "IV.4.58(2)": [ + "PRI-01.4" ], - "Article 14.2(a)": [ - "PRI-02" + "IV.4.58(3)": [ + "PRI-01.4" ], - "Article 14.2(b)": [ - "PRI-02" + "IV.4.58(4)": [ + "PRI-01.4" ], - "Article 14.2(c)": [ - "PRI-02" + "V.63": [ + "PRI-01.5" ], - "Article 14.2(d)": [ - "PRI-02" + "V.63(1)": [ + "PRI-01.5" ], - "Article 14.2(e)": [ - "PRI-02" + "V.63(2)": [ + "PRI-01.5" ], - "Article 14.2(f)": [ - "PRI-02" + "V.63(3)": [ + "PRI-01.5" ], - "Article 14.2(g)": [ - "PRI-02" + "V.63(4)": [ + "PRI-01.5" ], - "Article 14.3(a)": [ - "PRI-02" + "V.64": [ + "PRI-01.5" ], - "Article 14.3(b)": [ - "PRI-02" + "V.64(1)": [ + "PRI-01.5" ], - "Article 14.3(c)": [ - "PRI-02" + "V.64(2)": [ + "PRI-01.5" ], - "Article 14.4": [ - "PRI-02" + "V.64(3)": [ + "PRI-01.5" ], - "Article 14.5(a)": [ - "PRI-02" + "V.65-1": [ + "PRI-01.5" ], - "Article 7.1": [ - "PRI-03" + "V.65-1(1)": [ + "PRI-01.5" ], - "Article 7.2": [ - "PRI-03" + "V.65-1(2)": [ + "PRI-01.5" ], - "Article 9.2(a)": [ - "PRI-03" + "V.65-1(3)": [ + "PRI-01.5" ], - "Article 21.1": [ - "PRI-03" + "V.65-1(4)": [ + "PRI-01.5" ], - "Article 21.2": [ - "PRI-03" + "V.65-1(5)": [ + "PRI-01.5" ], - "Article 21.3": [ - "PRI-03" + "V.65-2": [ + "PRI-01.5" ], - "Article 21.4": [ - "PRI-03" + "V.65-2(1)": [ + "PRI-01.5" ], - "Article 21.5": [ - "PRI-03" + "V.65-2(2)": [ + "PRI-01.5" ], - "Article 21.6": [ - "PRI-03" + "V.66": [ + "PRI-01.5" ], - "Article 7.3": [ - "PRI-03.4" + "V.66(1)": [ + "PRI-01.5" ], - "Article 8.1": [ - "PRI-03.6", - "PRI-04" + "V.66(2)": [ + "PRI-01.5" ], - "Article 8.2": [ - "PRI-03.6" + "V.67-1": [ + "PRI-01.5" ], - "Article 18.2": [ - "PRI-03.9" + "V.67-1(1)": [ + "PRI-01.5" ], - "Article 18.3": [ - "PRI-03.11" + "V.67-1(2)": [ + "PRI-01.5" ], - "Article 19": [ - "PRI-03.11" + "V.67-1(3)": [ + "PRI-01.5" ], - "Article 5.1(b)": [ - "PRI-04" + "V.67-2": [ + "PRI-01.5" ], - "Article 5.1(c)": [ - "PRI-04" + "V.67-2(1)": [ + "PRI-01.5" ], - "Article 9.2(b)": [ - "PRI-04.1" + "V.67-2(2)": [ + "PRI-01.5" ], - "Article 9.2(c)": [ - "PRI-04.1" + "V.67-2(3)": [ + "PRI-01.5" ], - "Article 9.2(d)": [ - "PRI-04.1" + "V.67-2(4)": [ + "PRI-01.5" ], - "Article 9.2(e)": [ - "PRI-04.1" + "V.67-2(5)": [ + "PRI-01.5" ], - "Article 9.2(f)": [ - "PRI-04.1" + "V.67-2(6)": [ + "PRI-01.5" ], - "Article 9.2(g)": [ - "PRI-04.1" + "V.67-2(7)": [ + "PRI-01.5" ], - "Article 9.2(h)": [ - "PRI-04.1" + "V.67-2(8)": [ + "PRI-01.5" ], - "Article 9.2(i)": [ - "PRI-04.1" + "V.67-2(9)": [ + "PRI-01.5" ], - "Article 9.2(j)": [ - "PRI-04.1" + "V.67-2(10)": [ + "PRI-01.5" ], - "Article 9.3": [ - "PRI-04.1" + "V.67-2(11)": [ + "PRI-01.5" ], - "Article 10": [ - "PRI-04.1" + "V.67-2(12)": [ + "PRI-01.5" ], - "Article 5.1(e)": [ - "PRI-05", - "PRI-05.8" + "V.67-2(13)": [ + "PRI-01.5" ], - "Article 5.1(d)": [ - "PRI-05.2" + "V.67-2(14)": [ + "PRI-01.5" ], - "Article 12.3": [ - "PRI-06" + "V.68": [ + "PRI-01.5" ], - "Article 12.5(b)": [ - "PRI-06" + "V.69-1": [ + "PRI-01.5" ], - "Article 12.6": [ - "PRI-06" + "V.69-1(1)": [ + "PRI-01.5" ], - "Article 15.1": [ - "PRI-06" + "V.69-1(2)": [ + "PRI-01.5" ], - "Article 15.1(a)": [ - "PRI-06" + "V.69-1(3)": [ + "PRI-01.5" ], - "Article 15.1(b)": [ - "PRI-06" + "V.69-1(4)": [ + "PRI-01.5" ], - "Article 15.1(c)": [ - "PRI-06" + "V.69-1(5)": [ + "PRI-01.5" ], - "Article 15.1(d)": [ - "PRI-06" + "V.69-1(6)": [ + "PRI-01.5" ], - "Article 15.1(e)": [ - "PRI-06" + "V.69-1(7)": [ + "PRI-01.5" ], - "Article 15.1(g)": [ - "PRI-06" + "V.69-2": [ + "PRI-01.5" ], - "Article 15.1(h)": [ - "PRI-06" + "V.69-2(1)": [ + "PRI-01.5" ], - "Article 15.2": [ - "PRI-06" + "V.69-2(2)": [ + "PRI-01.5" ], - "Article 15.3": [ - "PRI-06" + "V.69-2(3)": [ + "PRI-01.5" ], - "Article 15.4": [ - "PRI-06" + "V.69-2(4)": [ + "PRI-01.5" ], - "Article 16": [ - "PRI-06" + "V.70": [ + "PRI-01.5" ], - "Article 17.1": [ - "PRI-06" + "V.70(1)": [ + "PRI-01.5" ], - "Article 18.1": [ - "PRI-06" + "V.70(2)": [ + "PRI-01.5" ], - "Article 18.1(a)": [ - "PRI-06" + "V.70(3)": [ + "PRI-01.5" ], - "Article 18.1(b)": [ - "PRI-06" + "V.70(4)": [ + "PRI-01.5" ], - "Article 18.1(c)": [ - "PRI-06" + "V.70(5)": [ + "PRI-01.5" ], - "Article 18.1(d)": [ - "PRI-06" + "V.71": [ + "PRI-01.5" ], - "Article 12.4": [ - "PRI-06.4" + "V.71(1)": [ + "PRI-01.5" ], - "Article 17.1(a)": [ - "PRI-06.5" + "V.71(2)": [ + "PRI-01.5" ], - "Article 17.1(b)": [ - "PRI-06.5" + "V.71(3)": [ + "PRI-01.5" ], - "Article 17.1(c)": [ - "PRI-06.5" + "V.71(4)": [ + "PRI-01.5" ], - "Article 17.1(d)": [ - "PRI-06.5" + "V.71(5)": [ + "PRI-01.5" ], - "Article 17.1(e)": [ - "PRI-06.5" + "V.72": [ + "PRI-01.5" ], - "Article 17.1(f)": [ - "PRI-06.5" + "V.72(1)": [ + "PRI-01.5" ], - "Article 17.2": [ - "PRI-06.5" + "V.72(2)": [ + "PRI-01.5" ], - "Article 17.3": [ - "PRI-06.5" + "V.72(3)": [ + "PRI-01.5" ], - "Article 17.3(a)": [ - "PRI-06.5" + "V.72(4)": [ + "PRI-01.5" ], - "Article 17.3(b)": [ - "PRI-06.5" + "II.6(5)": [ + "PRI-01.6", + "PRI-05.4" ], - "Article 17.3(c)": [ - "PRI-06.5" + "II.8": [ + "PRI-01.6", + "PRI-05" ], - "Article 17.3(d)": [ - "PRI-06.5" + "IV.1.41": [ + "PRI-01.6" ], - "Article 17.3(e)": [ - "PRI-06.5" + "IV.1.42": [ + "PRI-01.6" ], - "Article 20.1": [ - "PRI-06.6", - "PRI-06.7" + "IV.1.42(1)": [ + "PRI-01.6" ], - "Article 20.1(b)": [ - "PRI-06.7" + "IV.1.42(2)": [ + "PRI-01.6" ], - "Article 28.1": [ - "PRI-07.1" + "IV.2.50": [ + "PRI-01.6" ], - "Article 28.2": [ - "PRI-07.1" + "IV.2.50(2)": [ + "PRI-01.6" ], - "Article 28.3": [ - "PRI-07.1" + "IV.2.50(3)": [ + "PRI-01.6" ], - "Article 28.3(a)": [ - "PRI-07.1" + "IV.2.50(4)": [ + "PRI-01.6" + ], + "IV.2.51": [ + "PRI-01.6" ], - "Article 28.3(b)": [ - "PRI-07.1" + "IV.2.51(1)": [ + "PRI-01.6" ], - "Article 28.3(c)": [ - "PRI-07.1" + "IV.2.51(2)": [ + "PRI-01.6" ], - "Article 28.3(d)": [ - "PRI-07.1" + "IV.2.51(3)": [ + "PRI-01.6" ], - "Article 28.3(e)": [ - "PRI-07.1" + "IV.2.51(4)": [ + "PRI-01.6" ], - "Article 28.3(f)": [ - "PRI-07.1" + "IV.2.51(5)": [ + "PRI-01.6" ], - "Article 28.3(g)": [ - "PRI-07.1" + "IV.2.51(6)": [ + "PRI-01.6" ], - "Article 28.3(h)": [ - "PRI-07.1" + "IV.2.51(7)": [ + "PRI-01.6" ], - "Article 28.4": [ - "PRI-07.1" + "IV.2.51(8)": [ + "PRI-01.6" ], - "Article 28.5": [ - "PRI-07.1" + "IV.2.51(9)": [ + "PRI-01.6" ], - "Article 28.6": [ - "PRI-07.1" + "IV.2.51(10)": [ + "PRI-01.6" ], - "Article 28.7": [ - "PRI-07.1" + "II.5": [ + "PRI-01.11" ], - "Article 28.8": [ - "PRI-07.1" + "II.5(1)": [ + "PRI-01.11" ], - "Article 28.9": [ - "PRI-07.1" + "II.5(2)": [ + "PRI-01.11" ], - "Article 28.10": [ - "PRI-07.1" + "II.5(3)": [ + "PRI-01.11" ], - "Article 29": [ - "PRI-07.1" + "II.5(4)": [ + "PRI-01.11" ], - "Article 46.3(a)": [ - "PRI-07.1" + "II.5(5)": [ + "PRI-01.11" ], - "Article 30.1": [ - "PRI-14" + "II.5(6)": [ + "PRI-01.11" ], - "Article 30.1(a)": [ - "PRI-14" + "II.6": [ + "PRI-01.11" ], - "Article 30.1(b)": [ - "PRI-14" + "II.12": [ + "PRI-01.11", + "PRI-05.4" ], - "Article 30.1(c)": [ - "PRI-14" + "III.1.21(1)": [ + "PRI-01.11" ], - "Article 30.1(d)": [ - "PRI-14" + "III.1.22(1)": [ + "PRI-01.11" ], - "Article 30.1(e)": [ - "PRI-14" + "III.2.24-4": [ + "PRI-01.11" ], - "Article 30.1(f)": [ - "PRI-14" + "III.2.24-4(1)": [ + "PRI-01.11" ], - "Article 30.1(g)": [ - "PRI-14" + "III.2.24-4(2)": [ + "PRI-01.11" ], - "Article 30.2": [ - "PRI-14" + "III.2.24-4(3)": [ + "PRI-01.11" ], - "Article 30.2(a)": [ - "PRI-14" + "III.2.24-4(4)": [ + "PRI-01.11" ], - "Article 30.2(b)": [ - "PRI-14" + "III.2.25-1": [ + "PRI-01.11" ], - "Article 30.2(c)": [ - "PRI-14" + "III.2.25-1(1)": [ + "PRI-01.11" ], - "Article 30.2(d)": [ - "PRI-14" + "III.2.25-1(2)": [ + "PRI-01.11" ], - "Article 30.3": [ - "PRI-14" + "III.2.25-1(3)": [ + "PRI-01.11" ], - "Article 32.2": [ - "RSK-01" + "III.2.25-1(4)": [ + "PRI-01.11" ], - "Article 35.1": [ - "RSK-10" + "III.2.25-1(5)": [ + "PRI-01.11" ], - "Article 35.3(a)": [ - "RSK-10" + "III.2.25-2": [ + "PRI-01.11" ], - "Article 35.3(b)": [ - "RSK-10" + "III.2.25-2(1)": [ + "PRI-01.11" ], - "Article 35.3(c)": [ - "RSK-10" + "III.2.25-2(2)": [ + "PRI-01.11" ], - "Article 35.7(a)": [ - "RSK-10" + "III.2.25-2(3)": [ + "PRI-01.11" ], - "Article 35.7(b)": [ - "RSK-10" + "III.2.25-2(4)": [ + "PRI-01.11" ], - "Article 35.7(c)": [ - "RSK-10" + "III.2.25-3": [ + "PRI-01.11" ], - "Article 35.7(d)": [ - "RSK-10" + "III.2.25-3(1)": [ + "PRI-01.11" ], - "Article 35.8": [ - "RSK-10" + "III.2.25-3(2)": [ + "PRI-01.11" ], - "Article 35.9": [ - "RSK-10" + "III.2.25-3(3)": [ + "PRI-01.11" ], - "Article 35.11": [ - "RSK-10" + "III.2.25-3(4)": [ + "PRI-01.11" ], - "Article 36.1": [ - "RSK-10" + "III.2.25-3(5)": [ + "PRI-01.11" ], - "Article 4": [ - "SEA-02.1" - ] - }, - "emea-eu-nis2-2022": { - "Article 21.1": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "CPL-01", - "CPL-03", - "CPL-03.2", - "RSK-01", - "RSK-04", - "SEA-01" + "III.2.28": [ + "PRI-01.11" ], - "Article 21.2": [ - "GOV-01" + "III.2.28(1)": [ + "PRI-01.11" ], - "Article 21.2(a)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "RSK-01" + "III.2.28(2)": [ + "PRI-01.11" ], - "Article 21.2(b)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "IRO-01", - "IRO-02" + "III.2.28(3)": [ + "PRI-01.11" ], - "Article 21.2(c)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "BCD-01", - "BCD-11", - "BCD-12" + "III.2.28(4)": [ + "PRI-01.11" ], - "Article 21.2(d)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "RSK-01", - "RSK-09", - "TPM-01", - "TPM-03" + "III.2.28(5)": [ + "PRI-01.11" ], - "Article 21.2(e)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "MNT-01", - "NET-01", - "TDA-01", - "TPM-01", - "VPM-01" + "III.3.31(1)": [ + "PRI-01.11" ], - "Article 21.2(f)": [ - "GOV-01", - "GOV-01.1", - "GOV-02", - "GOV-05", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "RSK-01" + "III.3.31(2)": [ + "PRI-01.11" ], - "Article 21.2(g)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "SAT-01" + "III.3.31(3)": [ + "PRI-01.11" ], - "Article 21.2(h)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "CRY-01" + "III.3.31(4)": [ + "PRI-01.11" ], - "Article 21.2(i)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "AST-01", - "AST-02", - "HRS-01", - "IAC-01" + "III.3.32(1)": [ + "PRI-01.11" ], - "Article 21.2(j)": [ - "GOV-01", - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "IAC-01", - "IAC-06" + "III.3.32(2)": [ + "PRI-01.11" ], - "Article 21.4": [ - "CPL-01.1", - "IAO-04", - "IAO-05", - "RSK-06", - "TDA-15", - "TPM-09", - "VPM-02", - "VPM-04", - "VPM-05.1" + "III.3.34(1)": [ + "PRI-01.11" ], - "Article 21.5": [ - "CFG-02", - "NET-01", - "SEA-01" + "III.3.34(2)": [ + "PRI-01.11" ], - "Article 23.1": [ - "IRO-01", - "IRO-02", - "IRO-10" + "III.3.34(3)": [ + "PRI-01.11" ], - "Article 23.3": [ - "IRO-02.4" + "III.3.34(4)": [ + "PRI-01.11" ], - "Article 23.3(a)": [ - "IRO-02.4" + "III.3.34(5)": [ + "PRI-01.11" ], - "Article 23.3(b)": [ - "IRO-02.4" + "III.4.38(1)": [ + "PRI-01.11" ], - "Article 23.2": [ - "IRO-10", - "IRO-10.4", - "IRO-16" + "III.4.38(2)": [ + "PRI-01.11" ], - "Article 23.4": [ - "IRO-10" + "III.4.38(3)": [ + "PRI-01.11" ], - "Article 23.4(a)": [ - "IRO-10" + "III.1.21": [ + "PRI-02" ], - "Article 23.4(b)": [ - "IRO-10" + "III.2.23-1": [ + "PRI-02" ], - "Article 23.4(c)": [ - "IRO-10" + "III.2.23-1(1)": [ + "PRI-02" ], - "Article 23.4(d)": [ - "IRO-10" + "III.2.23-1(2)": [ + "PRI-02" ], - "Article 23.4(d)(i)": [ - "IRO-10" + "III.2.23-1(3)": [ + "PRI-02" ], - "Article 23.4(d)(ii)": [ - "IRO-10", - "IRO-13" + "III.2.23-1(4)": [ + "PRI-02" ], - "Article 23.4(d)(iii)": [ - "IRO-10" + "III.2.23-1(5)": [ + "PRI-02" ], - "Article 23.4(d)(iv)": [ - "IRO-10" + "III.2.23-1(6)": [ + "PRI-02" ], - "Article 23.4(e)": [ - "IRO-10" + "III.2.23-2": [ + "PRI-02" ], - "Article 21.3": [ - "PRM-04", - "PRM-05", - "PRM-07", - "RSK-09", - "TDA-01", - "TDA-06", - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-04.4", - "TPM-05", - "TPM-05.2", - "TPM-05.4", - "TPM-05.5", - "TPM-05.6", - "TPM-05.7", - "TPM-06", - "TPM-08", - "TPM-09", - "TPM-10" - ] - }, - "emea-eu-nis2-annex-2024": { - "1.1.1(a)": [ - "GOV-01", - "NET-01" + "III.2.23-2(1)": [ + "PRI-02" ], - "1.1.1(b)": [ - "GOV-01", - "GOV-08" + "III.2.23-2(2)": [ + "PRI-02" ], - "6.7.1": [ - "GOV-01", - "GOV-15" + "III.2.23-2(3)": [ + "PRI-02" ], - "1.1.1(k)": [ - "GOV-01.1", - "GOV-02" + "III.2.23-2(4)": [ + "PRI-02" ], - "1.2.3": [ - "GOV-01.2", - "GOV-17" + "III.2.23-2(5)": [ + "PRI-02" ], - "2.1.1": [ - "GOV-01.2", - "RSK-01", - "RSK-04", - "RSK-06" + "III.2.23-2(6)": [ + "PRI-02" ], - "2.2.1": [ - "GOV-01.2", - "CPL-01.4" + "III.2.24-1": [ + "PRI-02" ], - "2.2.2": [ - "GOV-01.2" + "III.2.24-1(1)": [ + "PRI-02" ], - "2.3.3": [ - "GOV-01.2" + "III.2.24-1(2)": [ + "PRI-02" ], - "13.2.2(c)": [ - "GOV-01.2", - "IRO-10" + "III.2.24-1(3)": [ + "PRI-02" ], - "1.1.1(d)": [ - "GOV-01.3" + "III.2.24-1(4)": [ + "PRI-02" ], - "1.1.1(e)": [ - "GOV-01.3" + "III.2.24-1(5)": [ + "PRI-02" ], - "1.1.1(f)": [ - "GOV-02", - "HRS-05.7" + "III.2.24-1(6)": [ + "PRI-02" ], - "1.1.1(i)": [ - "GOV-02" + "III.2.24-2": [ + "PRI-02" ], - "5.1.6": [ - "GOV-02", - "GOV-03", - "RSK-09", - "TPM-03" + "III.2.24-2(1)": [ + "PRI-02" ], - "7.1": [ - "GOV-02", - "RSK-01", - "OPS-01.1" + "III.2.24-2(2)": [ + "PRI-02" ], - "9.1": [ - "GOV-02", - "CRY-01", - "OPS-01.1" + "III.2.24-2(3)": [ + "PRI-02" ], - "11.1.1": [ - "GOV-02", - "IAC-01" + "III.2.24-2(4)": [ + "PRI-02" ], - "1.1.2": [ - "GOV-03" + "III.2.24-2(5)": [ + "PRI-02" ], - "2.3.1": [ - "GOV-03", - "CPL-03.1" + "III.2.24-2(6)": [ + "PRI-02" ], - "6.7.3": [ - "GOV-03", - "SEA-07.1" + "III.2.24-2(7)": [ + "PRI-02" ], - "1.1.1(g)": [ - "GOV-04", - "HRS-03" + "III.2.24-3": [ + "PRI-02" ], - "1.2.1": [ - "GOV-04", - "HRS-03" + "III.2.24-3(1)": [ + "PRI-02" ], - "1.2.4": [ - "GOV-04", - "HRS-03" + "III.2.24-3(2)": [ + "PRI-02" ], - "1.1.1(j)": [ - "GOV-05" + "III.2.24-3(3)": [ + "PRI-02" ], - "1.1.1(c)": [ - "GOV-09" + "II.15": [ + "PRI-03", + "PRI-14" ], - "6.2.1": [ - "GOV-15", - "SEA-01", - "TDA-01" + "III.3.31": [ + "PRI-03" ], - "12.1.1": [ - "AST-01", - "AST-04.1", - "DCH-02" + "II.16": [ + "PRI-03.3" ], - "12.1.3": [ - "AST-01", - "AST-04.1" + "III.3.30-1(2)": [ + "PRI-03.4" ], - "12.2.1": [ - "AST-01" + "III.4.37": [ + "PRI-03.4" ], - "12.2.2(a)": [ - "AST-01" + "II.14": [ + "PRI-04.1" ], - "12.2.3": [ - "AST-01" + "III.3.30-1(1)": [ + "PRI-05" ], - "12.3.3": [ - "AST-01" + "II.11": [ + "PRI-05.2", + "PRI-07.3" ], - "5.2(b)": [ - "AST-02" + "II.6(1)": [ + "PRI-05.4" ], - "12.4.1": [ - "AST-02" + "II.6(2)": [ + "PRI-05.4" ], - "12.4.2": [ - "AST-02" + "II.6(3)": [ + "PRI-05.4" ], - "12.4.2(a)": [ - "AST-02", - "AST-04.3" + "II.6(4)": [ + "PRI-05.4" ], - "12.4.2(b)": [ - "AST-02", - "AST-04.3" + "II.7": [ + "PRI-05.4" ], - "12.4.3": [ - "AST-02.1" + "II.7(1)": [ + "PRI-05.4" ], - "6.7.2(a)": [ - "AST-04" + "II.7(2)": [ + "PRI-05.4" ], - "11.7.2": [ - "AST-04.1", - "IAC-10" + "II.12(1)": [ + "PRI-05.4" ], - "12.2.2(c)": [ - "AST-05" + "II.12(2)": [ + "PRI-05.4" ], - "3.1.2": [ - "BCD-01" + "II.12(3)": [ + "PRI-05.4" ], - "4.1.1": [ - "BCD-01" + "II.12(4)": [ + "PRI-05.4" ], - "4.1.2": [ - "BCD-01" + "II.12(5)": [ + "PRI-05.4" ], - "4.1.2(a)": [ - "BCD-01" + "II.12(6)": [ + "PRI-05.4" ], - "4.1.2(b)": [ - "BCD-01" + "II.13": [ + "PRI-05.4" ], - "4.1.2(c)": [ - "BCD-01", - "BCD-01.6" + "II.17": [ + "PRI-05.4" ], - "4.1.2(d)": [ - "BCD-01" + "II.17(1)": [ + "PRI-05.4" ], - "4.1.2(e)": [ - "BCD-01" + "II.17(2)": [ + "PRI-05.4" ], - "4.1.2(f)": [ - "BCD-01", - "BCD-01.4" + "II.17(3)": [ + "PRI-05.4" ], - "4.1.2(g)": [ - "BCD-01", - "BCD-11", - "BCD-11.7" + "II.17(4)": [ + "PRI-05.4" ], - "4.1.2(h)": [ - "BCD-01", - "BCD-02.1", - "BCD-02.3" + "II.17(5)": [ + "PRI-05.4" ], - "4.2.2": [ - "BCD-01" + "II.17(6)": [ + "PRI-05.4" ], - "4.2.5": [ - "BCD-01" + "II.17(7)": [ + "PRI-05.4" ], - "4.3.1": [ - "BCD-01", - "IRO-01" + "II.17(8)": [ + "PRI-05.4" ], - "12.1.2(c)": [ - "BCD-01" + "II.17(9)": [ + "PRI-05.4" ], - "13.2.2(a)": [ - "BCD-01", - "PES-01" + "II.17(10)": [ + "PRI-05.4" ], - "4.3.3": [ - "BCD-01.1", - "IRO-07" + "II.18": [ + "PRI-05.4" ], - "4.2.2(a)": [ - "BCD-01.4" + "II.18(1)": [ + "PRI-05.4" ], - "4.1.4": [ - "BCD-04", - "BCD-05" + "II.18(2)": [ + "PRI-05.4" ], - "4.2.6": [ - "BCD-04" + "II.18(3)": [ + "PRI-05.4" ], - "4.3.4": [ - "BCD-04" + "II.19": [ + "PRI-05.4" ], - "4.2.2(c)": [ - "BCD-04.2", - "BCD-11" + "II.20": [ + "PRI-05.4" ], - "4.3.2(b)": [ - "BCD-10.4" + "IV.1.46": [ + "PRI-05.4" ], - "4.2.1": [ - "BCD-11", - "BCD-11.7" + "IV.1.47-1": [ + "PRI-05.4" ], - "4.2.2(b)": [ - "BCD-11", - "BCD-11.1" + "IV.1.47-1(1)": [ + "PRI-05.4" ], - "4.2.2(f)": [ - "BCD-11", - "DCH-18" + "IV.1.47-1(2)": [ + "PRI-05.4" ], - "4.2.4(a)": [ - "BCD-11.7" + "IV.1.47-1(3)": [ + "PRI-05.4" ], - "4.2.4(b)": [ - "BCD-11.7" + "IV.1.47-1(4)": [ + "PRI-05.4" ], - "4.2.4(d)": [ - "BCD-11.7" + "IV.1.47-1(5)": [ + "PRI-05.4" ], - "13.1.2(b)": [ - "BCD-11.7" + "IV.1.47-1(6)": [ + "PRI-05.4" ], - "4.2.2(d)": [ - "BCD-11.9" + "IV.1.47-1(7)": [ + "PRI-05.4" ], - "4.2.2(e)": [ - "BCD-12", - "BCD-13" + "III.2.26": [ + "PRI-06" ], - "4.2.3": [ - "BCD-13", - "BCD-13.1" + "III.2.26(1)": [ + "PRI-06" ], - "5.1.7(d)": [ - "CHG-01", - "TPM-10" + "III.2.26(2)": [ + "PRI-06" ], - "6.4.1": [ - "CHG-01", - "CHG-02" + "III.2.26(3)": [ + "PRI-06" ], - "6.4.4": [ - "CHG-01" + "III.2.26(4)": [ + "PRI-06" ], - "6.6.1": [ - "CHG-01", - "VPM-01" + "III.2.26(5)": [ + "PRI-06" ], - "6.10.2(d)": [ - "CHG-01", - "IRO-04", - "RSK-01", - "VPM-01" + "III.2.26(6)": [ + "PRI-06" ], - "6.4.2": [ - "CHG-02" + "III.2.26(7)": [ + "PRI-06" ], - "6.4.3": [ - "CHG-07", - "CHG-07.1" + "III.2.26(8)": [ + "PRI-06" ], - "2.2.3": [ - "CPL-01.4", - "MON-01" + "III.2.27": [ + "PRI-06" ], - "2.3.2": [ - "CPL-02.1", - "CPL-02.2" + "III.2.27(1)": [ + "PRI-06" ], - "2.3.4": [ - "CPL-02.2" + "III.2.27(2)": [ + "PRI-06" ], - "6.3.1": [ - "CFG-01" + "III.2.27(3)": [ + "PRI-06" ], - "6.3.2": [ - "CFG-01" + "III.2.27(4)": [ + "PRI-06" ], - "6.3.2(a)": [ - "CFG-02" + "III.2.27(5)": [ + "PRI-06" ], - "6.3.2(b)": [ - "CFG-02" + "III.2.27(6)": [ + "PRI-06" ], - "6.3.3": [ - "CFG-02", - "CFG-02.1" + "III.2.27(7)": [ + "PRI-06" ], - "12.3.2(b)": [ - "CFG-02" + "III.3.29": [ + "PRI-06.1" ], - "6.7.2(f)": [ - "CFG-03", - "NET-04" + "III.1.22": [ + "PRI-06.4" ], - "3.2.1": [ - "MON-01", - "IRO-01" + "III.3.34": [ + "PRI-06.4", + "PRI-17" ], - "3.2.2": [ - "MON-01", - "MON-01.2" + "III.3.30-1": [ + "PRI-06.5" ], - "3.2.6": [ - "MON-01", - "MON-02", - "MON-02.9", - "MON-07.1" + "III.3.32": [ + "PRI-06.5" ], - "13.1.2(f)": [ - "MON-01", - "PES-05", - "PES-09" + "III.3.36": [ + "PRI-06.6" ], - "3.2.3(a)": [ - "MON-01.3" + "IV.1.45-1": [ + "PRI-07.1" ], - "3.2.3": [ - "MON-01.8", - "MON-03", - "MON-10" + "IV.1.45-1(1)": [ + "PRI-07.1" ], - "3.2.4": [ - "MON-01.8" + "IV.1.45-1(2)": [ + "PRI-07.1" ], - "3.2.3(i)": [ - "MON-02.4" + "IV.1.45-1(3)": [ + "PRI-07.1" ], - "3.2.7": [ - "MON-02.9" + "IV.1.45-1(4)": [ + "PRI-07.1" ], - "3.2.3(c)": [ - "MON-03" + "IV.1.45-1(5)": [ + "PRI-07.1" ], - "3.2.3(d)": [ - "MON-03" + "IV.1.45-1(6)": [ + "PRI-07.1" ], - "3.2.3(e)": [ - "MON-03" + "IV.1.45-1(7)": [ + "PRI-07.1" ], - "3.2.3(f)": [ - "MON-03" + "IV.1.45-1(8)": [ + "PRI-07.1" ], - "3.2.3(g)": [ - "MON-03" + "IV.1.45-2": [ + "PRI-07.1" ], - "3.2.3(h)": [ - "MON-03" + "IV.1.45-2(1)": [ + "PRI-07.1" ], - "3.2.3(j)": [ - "MON-03" + "IV.1.45-2(2)": [ + "PRI-07.1" ], - "3.2.3(k)": [ - "MON-03" + "IV.1.45-2(3)": [ + "PRI-07.1" ], - "3.2.3(l)": [ - "MON-03" + "IV.1.45-2(4)": [ + "PRI-07.1" ], - "11.5.2(d)": [ - "MON-03", - "MON-03.3" + "IV.1.45-2(5)": [ + "PRI-07.1" ], - "11.5.2(b)": [ - "MON-03.2", - "IAC-09.1" + "IV.1.45-2(6)": [ + "PRI-07.1" ], - "3.2.5": [ - "MON-10" + "IV.1.43": [ + "PRI-07.2" ], - "13.1.2(d)": [ - "MON-16", - "PES-07" + "III.1.21(2)": [ + "PRI-07.5" ], - "3.2.3(b)": [ - "MON-16.4" + "III.1.22(2)": [ + "PRI-07.5" ], - "11.2.2(f)": [ - "MON-16.4" + "IV.1.47-2": [ + "PRI-14" ], - "3.4.2(c)": [ - "MON-17" + "IV.1.47-2(1)": [ + "PRI-14" ], - "3.4.2(d)": [ - "MON-17" + "IV.1.47-2(2)": [ + "PRI-14" ], - "9.2(a)": [ - "CRY-01" + "IV.1.47-2(3)": [ + "PRI-14" ], - "9.2(b)": [ - "CRY-01" + "IV.1.47-2(4)": [ + "PRI-14" ], - "9.2(c)(vi)": [ - "CRY-09" + "IV.1.47-2(5)": [ + "PRI-14" ], - "9.2(c)(vii)": [ - "CRY-09" + "IV.1.47-2(6)": [ + "PRI-14" ], - "9.2(c)(viii)": [ - "CRY-09" + "IV.1.47-2(7)": [ + "PRI-14" ], - "9.2(c)(ix)": [ - "CRY-09" + "IV.1.47-2(8)": [ + "PRI-14" ], - "9.2(c)(x)": [ - "CRY-09" + "IV.1.47-2(9)": [ + "PRI-14" ], - "9.2(c)(xi)": [ - "CRY-09" + "IV.1.47-3": [ + "PRI-14" ], - "9.2(c)(xii)": [ - "CRY-09" + "IV.1.47-3(1)": [ + "PRI-14" ], - "9.3": [ - "CRY-09" + "IV.1.47-3(2)": [ + "PRI-14" ], - "9.2(c)(v)": [ - "CRY-09.3", - "CRY-09.4" + "IV.1.47-3(3)": [ + "PRI-14" ], - "9.2(c)(i)": [ - "CRY-09.4" + "IV.1.47-3(4)": [ + "PRI-14" ], - "9.2(c)(ii)": [ - "CRY-09.4", - "CRY-11" + "IV.1.47-4": [ + "PRI-14" ], - "9.2(c)(iii)": [ - "CRY-09.4" + "IV.1.47-4(1)": [ + "PRI-14" ], - "9.2(c)(iv)": [ - "CRY-09.4" + "IV.1.47-4(2)": [ + "PRI-14" ], - "2.1.3": [ - "DCH-02", - "RSK-04", - "RSK-04.2", - "RSK-08" + "IV.1.47-4(3)": [ + "PRI-14" ], - "12.1.2(a)": [ - "DCH-02" + "IV.1.47-4(4)": [ + "PRI-14" ], - "12.1.2(b)": [ - "DCH-02.1" + "III.3.33": [ + "PRI-14.2" ], - "12.3.2(c)": [ - "DCH-07", - "DCH-07.2" + "III.4.39": [ + "PRI-19" ], - "12.3.1": [ - "DCH-12" + "III.4.38": [ + "PRI-19.2" ], - "12.3.2(a)": [ - "DCH-12" + "IV.3.54-1": [ + "RSK-10" ], - "12.3.2(d)": [ - "DCH-12" + "IV.3.54-1(1)": [ + "RSK-10" ], - "1.1.1(h)": [ - "DCH-18" + "IV.3.54-1(2)": [ + "RSK-10" ], - "6.2.2(f)": [ - "DCH-18.2", - "TDA-10" + "IV.3.54-1(3)": [ + "RSK-10" ], - "6.9.1": [ - "END-01", - "END-04", - "NET-01" + "IV.3.54-2": [ + "RSK-10" ], - "6.9.2": [ - "END-04", - "END-04.1" + "IV.3.54-2(1)": [ + "RSK-10" ], - "10.1.1": [ - "HRS-01", - "HRS-03" + "IV.3.54-2(2)": [ + "RSK-10" ], - "10.1.3": [ - "HRS-01", - "HRS-02" + "IV.3.54-2(3)": [ + "RSK-10" ], - "10.2.3": [ - "HRS-01" + "IV.3.54-2(4)": [ + "RSK-10" ], - "10.1.2(b)": [ - "HRS-01.1", - "HRS-02", - "HRS-02.1" + "IV.3.55-1": [ + "RSK-10" ], - "10.3.1": [ - "HRS-01.1", - "HRS-09", - "IAC-07.2" + "IV.3.55-1(1)": [ + "RSK-10" ], - "1.2.6": [ - "HRS-03", - "IAC-07.1" + "IV.3.55-1(2)": [ + "RSK-10" ], - "2.1.2(i)": [ - "HRS-03" + "IV.3.55-2": [ + "RSK-10" ], - "3.1.2(c)": [ - "HRS-03", - "IRO-07" + "IV.3.55-2(1)": [ + "RSK-10" ], - "3.1.3": [ - "HRS-03", - "IRO-07" + "IV.3.55-2(2)": [ + "RSK-10" ], - "4.2.4(c)": [ - "HRS-03", - "HRS-13.3", - "PRM-08" + "IV.3.55-2(3)": [ + "RSK-10" ], - "4.3.2(a)": [ - "HRS-03", - "TPM-05", - "TPM-05.4" + "IV.3.55-2(4)": [ + "RSK-10" ], - "8.1.1": [ - "HRS-03.1", - "SAT-02", - "TPM-05", - "TPM-05.4" + "IV.3.55-2(5)": [ + "RSK-10" ], - "10.1.2(a)": [ - "HRS-03.1", - "TPM-05.4" + "IV.3.55-2(6)": [ + "RSK-10" + ] + }, + "emea-zaf-popia-2013": { + "3.A.7.22(1)": [ + "IRO-10" ], - "10.1.2(c)": [ - "HRS-03.1" + "3.A.7.22(1)(a)": [ + "IRO-10" ], - "10.1.2(d)": [ - "HRS-04", - "HRS-04.1" + "3.A.7.22(1)(b)": [ + "IRO-10" ], - "10.2.1": [ - "HRS-04", - "HRS-10", - "TDA-13", - "TPM-06" + "3.A.7.22(2)": [ + "IRO-10" ], - "10.2.2(a)": [ - "HRS-04" + "3.A.7.22(3)": [ + "IRO-10" ], - "10.2.2(b)": [ - "HRS-04" + "3.A.7.22(4)": [ + "IRO-10" ], - "1.2.2": [ - "HRS-05", - "TPM-05" + "3.A.7.22(4)(a)": [ + "IRO-10" ], - "10.3.2": [ - "HRS-05", - "HRS-06.1" + "3.A.7.22(4)(b)": [ + "IRO-10" ], - "12.2.2(b)": [ - "HRS-05.1" + "3.A.7.22(4)(c)": [ + "IRO-10" ], - "10.4.1": [ - "HRS-07", - "HRS-07.1" + "3.A.7.22(4)(d)": [ + "IRO-10" ], - "10.4.2": [ - "HRS-07.2" + "3.A.7.22(4)(e)": [ + "IRO-10" ], - "12.5": [ - "HRS-09", - "HRS-09.1" + "3.A.7.22(5)": [ + "IRO-10" ], - "1.2.5": [ - "HRS-11" + "3.A.7.22(5)(a)": [ + "IRO-10" ], - "11.2.2(a)": [ - "HRS-11", - "IAC-07", - "IAC-08", - "IAC-20.6", - "IAC-21" + "3.A.7.22(5)(b)": [ + "IRO-10" ], - "3.3.1": [ - "HRS-15", - "SAT-03.2" + "3.A.7.22(5)(c)": [ + "IRO-10" ], - "11.1.2(a)": [ - "IAC-01" + "3.A.7.22(5)(d)": [ + "IRO-10" ], - "11.1.2(b)": [ - "IAC-01" + "3.A.7.22(6)": [ + "IRO-10" ], - "11.1.2(c)": [ - "IAC-01" + "9.72(1)": [ + "PRI-01.5" ], - "11.1.3": [ - "IAC-01" + "9.72(1)(a)": [ + "PRI-01.5" ], - "11.3.1": [ - "IAC-01" + "9.72(1)(a)(i)": [ + "PRI-01.5" ], - "11.5.1": [ - "IAC-01" + "9.72(1)(a)(ii)": [ + "PRI-01.5" ], - "11.5.2(c)": [ - "IAC-01", - "IAC-15" + "9.72(1)(b)": [ + "PRI-01.5" ], - "11.6.4": [ - "IAC-01" + "9.72(1)(c)": [ + "PRI-01.5" ], - "11.3.2(a)": [ - "IAC-01.2", - "IAC-06" + "9.72(1)(d)": [ + "PRI-01.5" ], - "11.4.2(c)": [ - "IAC-01.2", - "NET-15.1" + "9.72(1)(e)": [ + "PRI-01.5" ], - "11.6.1": [ - "IAC-01.2" + "9.72(1)(e)(i)": [ + "PRI-01.5" ], - "11.6.3": [ - "IAC-01.2" + "9.72(1)(e)(ii)": [ + "PRI-01.5" ], - "11.2.2(e)": [ - "IAC-01.3" + "9.72(2)": [ + "PRI-01.5" ], - "11.5.2(a)": [ - "IAC-02", - "IAC-04" + "9.72(2)(a)": [ + "PRI-01.5" ], - "11.7.1": [ - "IAC-06", - "IAC-13.3" + "9.72(2)(b)": [ + "PRI-01.5" ], - "11.2.1": [ - "IAC-07" + "3.A.7.19(1)": [ + "PRI-01.6" ], - "11.2.2(b)": [ - "IAC-07", - "IAC-20.6" + "3.A.7.19(1)(a)": [ + "PRI-01.6" ], - "11.2.2(d)": [ - "IAC-07", - "IAC-08", - "IAC-21" + "3.A.7.19(1)(b)": [ + "PRI-01.6" ], - "11.4.1": [ - "IAC-08" + "3.A.7.19(2)": [ + "PRI-01.6" ], - "11.6.2(a)": [ - "IAC-10" + "3.A.7.19(2)(a)": [ + "PRI-01.6" ], - "11.6.2(b)": [ - "IAC-10.5" + "3.A.7.19(2)(b)": [ + "PRI-01.6" ], - "11.6.2(c)": [ - "IAC-10.13" + "3.A.7.19(2)(c)": [ + "PRI-01.6" ], - "11.2.2(c)": [ - "IAC-15", - "IAC-28.1" + "3.A.7.19(2)(d)": [ + "PRI-01.6" ], - "11.5.3": [ - "IAC-15.5" + "3.A.7.19(3)": [ + "PRI-01.6" ], - "11.6.2(f)": [ - "IAC-16" + "2.5(1)": [ + "PRI-01.11" ], - "11.2.3": [ - "IAC-17" + "2.5(1)(a)": [ + "PRI-01.11" ], - "11.3.3": [ - "IAC-17" + "2.5(1)(a)(i)": [ + "PRI-01.11" ], - "11.5.4": [ - "IAC-17" + "2.5(1)(a)(ii)": [ + "PRI-01.11" ], - "6.7.2(e)": [ - "IAC-20.4" + "2.5(1)(b)": [ + "PRI-01.11" ], - "11.3.2(d)": [ - "IAC-20.4", - "IAC-21" + "2.5(1)(c)": [ + "PRI-01.11" ], - "11.4.2(a)": [ - "IAC-20.4" + "2.5(1)(d)": [ + "PRI-01.11" ], - "6.7.2(g)": [ - "IAC-21", - "NET-04" + "2.5(1)(e)": [ + "PRI-01.11" ], - "11.3.2(c)": [ - "IAC-21" + "2.5(1)(e)(i)": [ + "PRI-01.11" ], - "11.3.2(b)": [ - "IAC-21.3" + "2.5(1)(e)(ii)": [ + "PRI-01.11" ], - "11.6.2(d)": [ - "IAC-22" + "2.5(1)(f)": [ + "PRI-01.11" ], - "11.6.2(e)": [ - "IAC-25" + "2.5(1)(g)": [ + "PRI-01.11" ], - "3.1.1": [ - "IRO-01", - "IRO-04" + "2.5(1)(h)": [ + "PRI-01.11" ], - "3.5.1": [ - "IRO-01", - "IRO-04" + "2.5(1)(i)": [ + "PRI-01.11" ], - "3.1.2(b)": [ - "IRO-02", - "IRO-04", - "IRO-10", - "IRO-10.2" + "3.A.2.9(1)": [ + "PRI-01.11" ], - "3.4.1": [ - "IRO-02", - "IRO-02.4" + "3.A.2.9(1)(a)": [ + "PRI-01.11" ], - "3.4.2(e)": [ - "IRO-02" + "3.A.2.9(1)(b)": [ + "PRI-01.11" ], - "3.5.2(a)": [ - "IRO-02" + "3.A.2.10": [ + "PRI-01.11" ], - "3.5.2(b)": [ - "IRO-02" + "3.A.2.11(2)(a)": [ + "PRI-01.11" ], - "3.5.2(c)": [ - "IRO-02" + "3.A.2.12(2)": [ + "PRI-01.11" ], - "3.5.3(b)": [ - "IRO-02", - "IRO-09" + "3.A.2.12(2)(a)": [ + "PRI-01.11" ], - "3.1.2(a)": [ - "IRO-02.4" + "3.A.2.12(2)(b)": [ + "PRI-01.11" ], - "3.4.2(a)": [ - "IRO-02.4" + "3.A.2.12(2)(c)": [ + "PRI-01.11" ], - "3.1.2(d)": [ - "IRO-04" + "3.A.2.12(2)(d)": [ + "PRI-01.11" ], - "3.5.5": [ - "IRO-06" + "3.A.2.12(2)(d)(i)": [ + "PRI-01.11" ], - "3.5.3(a)": [ - "IRO-07" + "3.A.2.12(2)(d)(ii)": [ + "PRI-01.11" ], - "3.5.4": [ - "IRO-09" + "3.A.2.12(2)(d)(iii)": [ + "PRI-01.11" ], - "6.10.2(a)": [ - "IRO-09", - "THR-03", - "VPM-01" + "3.A.2.12(2)(d)(iv)": [ + "PRI-01.11" ], - "3.4.2(b)": [ - "IRO-09.2" + "3.A.2.12(2)(d)(v)": [ + "PRI-01.11" ], - "3.6.1": [ - "IRO-13" + "3.A.2.12(2)(e)": [ + "PRI-01.11" ], - "3.6.2": [ - "IRO-13" + "3.A.2.12(2)(f)": [ + "PRI-01.11" ], - "3.6.3": [ - "IRO-13" + "3.A.6.17": [ + "PRI-01.11" ], - "6.5.1": [ - "IAO-01", - "TDA-09" + "3.A.6.18(1)": [ + "PRI-01.11" ], - "6.5.2(a)": [ - "IAO-01", - "IAO-02" + "3.A.6.18(1)(a)": [ + "PRI-01.11" ], - "6.5.3": [ - "IAO-01" + "3.A.6.18(1)(b)": [ + "PRI-01.11" ], - "6.5.2(c)": [ - "IAO-01.1", - "IAO-02.4" + "3.A.6.18(1)(c)": [ + "PRI-01.11" ], - "6.5.2(b)": [ - "IAO-02" + "3.A.6.18(1)(d)": [ + "PRI-01.11" ], - "6.5.2(d)": [ - "IAO-05" + "3.A.6.18(1)(e)": [ + "PRI-01.11" ], - "4.3.2(c)": [ - "MNT-01" + "3.A.6.18(1)(f)": [ + "PRI-01.11" ], - "6.7.2(h)": [ - "MNT-05" + "3.A.6.18(1)(g)": [ + "PRI-01.11" ], - "6.7.2(b)": [ - "NET-01" + "3.A.6.18(1)(h)": [ + "PRI-01.11" ], - "6.7.2(i)": [ - "NET-01" + "3.A.6.18(1)(h)(i)": [ + "PRI-01.11" ], - "6.8.3": [ - "NET-01" + "3.A.6.18(1)(h)(ii)": [ + "PRI-01.11" ], - "6.7.2(c)": [ - "NET-04" + "3.A.6.18(1)(h)(iii)": [ + "PRI-01.11" ], - "6.8.1": [ - "NET-06" + "3.A.6.18(1)(h)(iv)": [ + "PRI-01.11" ], - "6.8.2(a)": [ - "NET-06" + "3.A.6.18(1)(h)(v)": [ + "PRI-01.11" ], - "6.8.2(b)": [ - "NET-06" + "3.A.6.18(2)": [ + "PRI-01.11" ], - "6.8.2(c)": [ - "NET-06" + "3.A.6.18(2)(a)": [ + "PRI-01.11" ], - "6.8.2(d)": [ - "NET-06", - "NET-08.1" + "3.A.6.18(2)(b)": [ + "PRI-01.11" ], - "6.8.2(e)": [ - "NET-06" + "3.A.6.18(3)": [ + "PRI-01.11" ], - "6.8.2(f)": [ - "NET-06" + "3.A.6.18(4)": [ + "PRI-01.11" ], - "6.8.2(g)": [ - "NET-06" + "3.A.6.18(4)(a)": [ + "PRI-01.11" ], - "6.8.2(h)": [ - "NET-06", - "TDA-07" + "3.A.6.18(4)(b)": [ + "PRI-01.11" ], - "6.7.2(l)": [ - "NET-10", - "NET-18" + "3.A.6.18(4)(c)": [ + "PRI-01.11" ], - "6.7.2(d)": [ - "NET-14" + "3.A.6.18(4)(c)(i)": [ + "PRI-01.11" ], - "13.1.1": [ - "PES-01" + "3.A.6.18(4)(c)(ii)": [ + "PRI-01.11" ], - "13.1.3": [ - "PES-01" + "3.A.6.18(4)(c)(iii)": [ + "PRI-01.11" ], - "13.2.1": [ - "PES-01", - "THR-09" + "3.A.6.18(4)(c)(iv)": [ + "PRI-01.11" ], - "13.2.3": [ - "PES-01" + "3.A.6.18(4)(d)": [ + "PRI-01.11" ], - "13.3.2(a)": [ - "PES-01" + "3.A.6.18(4)(e)": [ + "PRI-01.11" ], - "13.3.3": [ - "PES-01" + "3.A.6.18(4)(f)": [ + "PRI-01.11" ], - "13.3.1": [ - "PES-02", - "PES-03" + "3.A.6.18(4)(f)(i)": [ + "PRI-01.11" ], - "13.1.2(c)": [ - "PES-03" + "3.A.6.18(4)(f)(ii)": [ + "PRI-01.11" ], - "13.3.2(b)": [ - "PES-03", - "PES-03.1" + "3.A.7.20(1)": [ + "PRI-01.11" ], - "13.3.2(d)": [ - "PES-03.3", - "PES-05" + "3.A.7.20(1)(a)": [ + "PRI-01.11" ], - "13.3.2(c)": [ - "PES-04" + "3.A.7.20(1)(b)": [ + "PRI-01.11" ], - "13.1.2(a)": [ - "PES-07.3", - "PES-07.4" + "3.A.3.13(1)": [ + "PRI-02" ], - "6.2.2(a)": [ - "PRM-05", - "PRM-06" + "3.A.3.13(2)": [ + "PRI-02" ], - "2.1.2": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-06" + "6.57(1)": [ + "PRI-03" ], - "2.1.2(a)": [ - "RSK-01" + "6.57(1)(a)": [ + "PRI-03" ], - "2.1.2(c)": [ - "RSK-01", - "RSK-01.1" + "6.57(1)(a)(i)": [ + "PRI-03" ], - "2.1.2(d)": [ - "RSK-01", - "RSK-03", - "RSK-03.1", - "TPM-04.1" + "6.57(1)(a)(ii)": [ + "PRI-03" ], - "6.1.1": [ - "RSK-01", - "RSK-04" + "6.57(1)(b)": [ + "PRI-03" ], - "6.1.3": [ - "RSK-01", - "RSK-04.2" + "6.57(1)(c)": [ + "PRI-03" ], - "7.3": [ - "RSK-01" + "6.57(1)(d)": [ + "PRI-03" ], - "2.1.2(e)": [ - "RSK-01.2", - "RSK-04", - "RSK-05" + "6.57(2)": [ + "PRI-03" ], - "2.1.2(b)": [ - "RSK-01.3", - "RSK-01.5" + "6.57(3)": [ + "PRI-03" ], - "13.2.2(b)": [ - "RSK-01.4" + "6.57(4)": [ + "PRI-03" ], - "2.1.2(f)": [ - "RSK-04" + "3.C.34": [ + "PRI-03.3" ], - "6.1.2": [ - "RSK-04.2" + "3.C.35(1)": [ + "PRI-03.3" ], - "6.1.2(a)": [ - "RSK-04.2" + "3.C.35(1)(a)": [ + "PRI-03.3" ], - "6.1.2(b)": [ - "RSK-04.2" + "3.C.35(1)(b)": [ + "PRI-03.3" ], - "6.1.2(c)": [ - "RSK-04.2" + "3.C.35(1)(c)": [ + "PRI-03.3" ], - "6.1.2(d)": [ - "RSK-04.2" + "3.C.35(1)(d)": [ + "PRI-03.3" ], - "6.1.2(e)": [ - "RSK-04.2" + "3.C.35(1)(d)(i)": [ + "PRI-03.3" ], - "6.1.2(f)": [ - "RSK-04.2" + "3.C.35(1)(d)(ii)": [ + "PRI-03.3" ], - "7.2": [ - "RSK-04.2" + "3.C.35(1)(d)(iii)": [ + "PRI-03.3" ], - "7.2(a)": [ - "RSK-04.2" + "3.C.35(1)(e)": [ + "PRI-03.3" ], - "7.2(b)": [ - "RSK-04.2" + "3.C.35(2)": [ + "PRI-03.3" ], - "7.2(c)": [ - "RSK-04.2" + "3.C.35(3)": [ + "PRI-03.3" ], - "7.2(d)": [ - "RSK-04.2" + "3.C.35(3)(a)": [ + "PRI-03.3" ], - "7.2(e)": [ - "RSK-04.2" + "3.C.35(3)(a)(i)": [ + "PRI-03.3" ], - "7.2(f)": [ - "RSK-04.2" + "3.C.35(3)(a)(ii)": [ + "PRI-03.3" ], - "2.1.2(g)": [ - "RSK-06" + "3.C.35(3)(b)": [ + "PRI-03.3" ], - "2.1.2(j)": [ - "RSK-06" + "3.C.35(3)(b)(i)": [ + "PRI-03.3" ], - "6.6.1(d)": [ - "RSK-06.2" + "3.C.35(3)(b)(ii)": [ + "PRI-03.3" ], - "2.1.4": [ - "RSK-07" + "3.C.35(3)(b)(iii)": [ + "PRI-03.3" ], - "4.1.3": [ - "RSK-08" + "3.C.35(3)(c)": [ + "PRI-03.3" ], - "5.1.1": [ - "RSK-09", - "TDA-01" + "3.C.35(3)(d)": [ + "PRI-03.3" ], - "5.1.5": [ - "RSK-09", - "TPM-05" + "3.A.2.11(2)(b)": [ + "PRI-03.4" ], - "5.1.3": [ - "RSK-09.1" + "3.A.2.11(3)": [ + "PRI-03.4" ], - "2.1.2(h)": [ - "RSK-11" + "3.A.2.11(3)(a)": [ + "PRI-03.4" ], - "6.2.2(b)": [ - "SEA-01" + "3.A.2.11(3)(b)": [ + "PRI-03.4" ], - "6.2.2(c)": [ - "SEA-01", - "TDA-01", - "TDA-07" + "3.A.2.11(4)": [ + "PRI-03.4" ], - "4.2.4": [ - "SEA-01.2" + "3.A.2.12(1)": [ + "PRI-03.7" ], - "11.4.2(b)": [ - "SEA-04" + "3.A.2.11(1)": [ + "PRI-04.1" ], - "6.7.2(j)": [ - "SEA-07.1" + "3.A.2.11(1)(a)": [ + "PRI-04.1" ], - "6.7.2(k)": [ - "SEA-07.1" + "3.A.2.11(1)(b)": [ + "PRI-04.1" ], - "8.1.3": [ - "SAT-01" + "3.A.2.11(1)(c)": [ + "PRI-04.1" ], - "8.2.5": [ - "SAT-01" + "3.A.2.11(1)(d)": [ + "PRI-04.1" ], - "8.1.2(a)": [ - "SAT-01.1" + "3.A.2.11(1)(e)": [ + "PRI-04.1" ], - "8.1.2": [ - "SAT-02" + "3.A.2.11(1)(f)": [ + "PRI-04.1" ], - "8.2.1": [ - "SAT-03" + "3.A.3.14(1)": [ + "PRI-05" ], - "8.2.2": [ - "SAT-03" + "3.A.3.14(1)(a)": [ + "PRI-05" ], - "8.2.3": [ - "SAT-03" + "3.A.3.14(1)(b)": [ + "PRI-05" ], - "8.2.3(a)": [ - "SAT-03" + "3.A.3.14(1)(c)": [ + "PRI-05" ], - "8.2.3(c)": [ - "SAT-03" + "3.A.3.14(1)(d)": [ + "PRI-05" ], - "8.2.4": [ - "SAT-03" + "3.A.3.14(2)": [ + "PRI-05" ], - "3.3.2": [ - "SAT-03.2", - "TPM-05" + "3.A.3.14(3)": [ + "PRI-05" ], - "8.1.2(b)": [ - "SAT-03.6" + "3.A.3.14(3)(a)": [ + "PRI-05" ], - "8.1.2(c)": [ - "SAT-03.6" + "3.A.3.14(3)(b)": [ + "PRI-05" ], - "8.2.3(b)": [ - "SAT-03.6" + "3.A.3.14(4)": [ + "PRI-05" ], - "6.2.4": [ - "TDA-01" + "3.A.3.14(5)": [ + "PRI-05" ], - "6.10.2(e)": [ - "TDA-02.11" + "3.A.3.14(6)": [ + "PRI-05" ], - "6.2.2(d)": [ - "TDA-09" + "3.A.3.14(6)(a)": [ + "PRI-05" ], - "6.2.2(e)": [ - "TDA-10.1" + "3.A.3.14(6)(b)": [ + "PRI-05" ], - "6.6.1(c)": [ - "TDA-14.1", - "VPM-05.8" + "3.A.3.14(6)(c)": [ + "PRI-05" ], - "6.2.3": [ - "TPM-01", - "TPM-05" + "3.A.3.14(6)(d)": [ + "PRI-05" ], - "5.2": [ - "TPM-01.1" + "3.A.3.14(7)": [ + "PRI-05" ], - "5.2(a)": [ - "TPM-01.1" + "3.A.5.16(1)": [ + "PRI-05.2" ], - "5.1.2": [ - "TPM-05" + "3.A.5.16(2)": [ + "PRI-05.2" ], - "5.1.2(a)": [ - "TPM-05" + "3.A.4.15(1)": [ + "PRI-05.4" ], - "5.1.2(b)": [ - "TPM-05" + "3.A.4.15(2)": [ + "PRI-05.4" ], - "5.1.2(c)": [ - "TPM-05" + "3.A.4.15(2)(a)": [ + "PRI-05.4" ], - "5.1.2(d)": [ - "TPM-05" + "3.A.4.15(2)(b)": [ + "PRI-05.4" ], - "5.1.4": [ - "TPM-05" + "3.A.4.15(2)(c)": [ + "PRI-05.4" ], - "5.1.4(a)": [ - "TPM-05" + "3.A.4.15(2)(d)": [ + "PRI-05.4" ], - "5.1.4(b)": [ - "TPM-05" + "3.A.4.15(2)(e)": [ + "PRI-05.4" ], - "5.1.4(c)": [ - "TPM-05", - "TPM-06" + "3.A.4.15(3)": [ + "PRI-05.4" ], - "5.1.4(d)": [ - "TPM-05" + "3.A.4.15(3)(a)": [ + "PRI-05.4" ], - "5.1.4(e)": [ - "TPM-05" + "3.A.4.15(3)(b)": [ + "PRI-05.4" ], - "5.1.4(f)": [ - "TPM-05" + "3.A.4.15(3)(c)": [ + "PRI-05.4" ], - "5.1.4(g)": [ - "TPM-05", - "TPM-05.2" + "3.A.4.15(3)(c)(i)": [ + "PRI-05.4" ], - "5.1.4(h)": [ - "TPM-05" + "3.A.4.15(3)(c)(ii)": [ + "PRI-05.4" ], - "13.1.2(e)": [ - "TPM-05" + "3.A.4.15(3)(c)(iii)": [ + "PRI-05.4" ], - "5.1.7(a)": [ - "TPM-08" + "3.A.4.15(3)(c)(iv)": [ + "PRI-05.4" ], - "5.1.7(b)": [ - "TPM-08" + "3.A.4.15(3)(d)": [ + "PRI-05.4" ], - "5.1.7(c)": [ - "TPM-08" + "3.A.4.15(3)(d)(i)": [ + "PRI-05.4" ], - "6.10.1": [ - "VPM-01", - "VPM-02" + "3.A.4.15(3)(d)(ii)": [ + "PRI-05.4" ], - "6.10.2(c)": [ - "VPM-02" + "3.A.4.15(3)(e)": [ + "PRI-05.4" ], - "6.10.3": [ - "VPM-02" + "3.A.4.15(3)(f)": [ + "PRI-05.4" ], - "6.6.2": [ - "VPM-04.3" + "3.B.26(1)": [ + "PRI-05.4" ], - "6.6.1(a)": [ - "VPM-05" + "3.B.26(1)(a)": [ + "PRI-05.4" ], - "6.10.4": [ - "VPM-05.4", - "VPM-06.1" + "3.B.26(1)(b)": [ + "PRI-05.4" ], - "6.6.1(b)": [ - "VPM-05.6" + "3.B.26(1)(b)(i)": [ + "PRI-05.4" ], - "6.10.2(b)": [ - "VPM-06" - ] - }, - "emea-us-psd2-2015": { - "3": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-05", - "CPL-01", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "CPL-04" + "3.B.26(1)(b)(ii)": [ + "PRI-05.4" ], - "4": [ - "IAC-01", - "IAC-03", - "IAC-05", - "IAC-06", - "IAC-10", - "IAC-10.1", - "WEB-06" + "3.B.27(1)": [ + "PRI-05.4" ], - "19": [ - "IAC-10.4", - "IAC-10.5" + "3.B.27(1)(a)": [ + "PRI-05.4" ], - "20": [ - "CRY-01", - "CRY-03", - "CRY-04" + "3.B.27(1)(b)": [ + "PRI-05.4" ], - "22": [ - "IAC-10.5", - "NET-11" + "3.B.27(1)(c)": [ + "PRI-05.4" ], - "24": [ - "AST-09", - "DCH-08", - "DCH-09.3", - "DCH-21", - "PRI-05" + "3.B.27(1)(d)": [ + "PRI-05.4" ], - "25": [ - "IAC-04" + "3.B.27(1)(d)(i)": [ + "PRI-05.4" ], - "26": [ - "MON-09" + "3.B.27(1)(d)(ii)": [ + "PRI-05.4" ], - "29": [ - "CPL-01", - "CPL-03" + "3.B.27(1)(e)": [ + "PRI-05.4" ], - "30": [ - "CRY-01", - "CRY-03", - "CRY-04" - ] - }, - "emea-aut-fappd-2000": { - "Sec 14": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-04", - "AST-01", - "AST-02", - "AST-03", - "AST-04", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "CPL-01", - "CFG-01", - "MON-01", - "MON-01.16", - "CRY-01", - "DCH-01", - "EMB-01", - "END-01", - "HRS-01", - "IAC-01", - "IRO-01", - "IAO-01", - "MNT-01", - "MDM-01", - "NET-01", - "PES-01", - "PRI-01", - "PRM-01", - "RSK-01", - "SEA-01", - "SEA-02", - "SEA-03", - "OPS-01", - "SAT-01", - "TDA-01", - "TPM-01", - "THR-01", - "VPM-01", - "WEB-01", - "WEB-02" + "3.B.27(1)(f)": [ + "PRI-05.4" ], - "Sec 15": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-04", - "AST-01", - "AST-02", - "AST-03", - "AST-04", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "CPL-01", - "CFG-01", - "MON-01", - "MON-01.16", - "CRY-01", - "DCH-01", - "EMB-01", - "END-01", - "HRS-01", - "IAC-01", - "IRO-01", - "IAO-01", - "MNT-01", - "MDM-01", - "NET-01", - "PES-01", - "PRI-01", - "PRM-01", - "RSK-01", - "SEA-01", - "SEA-02", - "SEA-03", - "OPS-01", - "SAT-01", - "TDA-01", - "TPM-01", - "THR-01", - "VPM-01", - "WEB-01", - "WEB-02" + "3.B.27(2)": [ + "PRI-05.4" ], - "Sec 27": [ - "DCH-22.1", - "PRI-06.1" + "3.B.27(3)": [ + "PRI-05.4" ], - "Sec 10": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "IRO-14", - "PRI-07", - "PRI-07.1", - "SEA-15", - "TPM-04.4" + "3.A.8.23(1)": [ + "PRI-06" ], - "Sec 6": [ - "PRI-02.1", - "PRI-04", - "PRI-04.1" + "3.A.8.23(1)(a)": [ + "PRI-06" ], - "Sec 8": [ - "PRI-03", - "PRI-03.2" + "3.A.8.23(1)(b)": [ + "PRI-06" ], - "Sec 7": [ - "PRI-05" + "3.A.8.23(1)(b)(i)": [ + "PRI-06" ], - "Sec 12": [ - "PRI-05.1", - "PRI-05.4" + "3.A.8.23(1)(b)(ii)": [ + "PRI-06" ], - "Sec 26": [ + "3.A.8.23(1)(b)(iii)": [ "PRI-06" ], - "Sec 28": [ - "PRI-06.3" + "3.A.8.23(1)(b)(iv)": [ + "PRI-06" ], - "Sec 16": [ - "PRI-15" + "3.A.8.23(2)": [ + "PRI-06" ], - "Sec 17": [ - "PRI-15" - ] - }, - "emea-bel-act-8-1992": { - "4": [ - "PRI-01" + "3.A.8.23(3)": [ + "PRI-06" ], - "9": [ - "PRI-02" + "3.A.8.23(3)(a)": [ + "PRI-06" ], - "10": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "3.A.8.23(3)(b)": [ + "PRI-06" ], - "12": [ - "DCH-22.1", - "PRI-06", + "3.A.8.24(1)": [ "PRI-06.1" ], - "16": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-04", - "AST-01", - "AST-02", - "AST-03", - "AST-04", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "CPL-01", - "CFG-01", - "MON-01", - "MON-01.16", - "CRY-01", - "DCH-01", - "EMB-01", - "END-01", - "HRS-01", - "IAC-01", - "IRO-01", - "IAO-01", - "MNT-01", - "MDM-01", - "NET-01", - "PES-01", - "PRM-01", - "RSK-01", - "SEA-01", - "SEA-02", - "SEA-03", - "OPS-01", - "SAT-01", - "TDA-01", - "TPM-01", - "THR-01", - "VPM-01", - "WEB-01", - "WEB-02" - ], - "17": [ - "PRI-15" + "3.A.8.24(1)(a)": [ + "PRI-06.1" ], - "21": [ - "PRI-05", - "PRI-05.1", - "PRI-05.4", - "RSK-08" + "3.A.8.24(1)(b)": [ + "PRI-06.1" ], - "45754": [ - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1" + "3.A.8.24(3)": [ + "PRI-06.2" ], - "Chapter 4 - 16": [ - "DCH-24", - "DCH-24.1", - "SEA-15", - "TPM-04.4" + "3.A.8.24(4)": [ + "PRI-06.2" ], - "4-7": [ - "PRI-05", - "PRI-05.1", - "PRI-05.4" - ] - }, - "emea-deu-fdpa-2017": { - "Sec 9": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.A.8.23(4)(a)": [ + "PRI-06.4" ], - "Sec 9a": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.A.8.23(4)(b)": [ + "PRI-06.4" ], - "Annex": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.A.8.23(5)": [ + "PRI-06.4" ], - "Sec 4b": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.A.8.24(2)": [ + "PRI-06.4" ], - "Sec 16": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.A.8.24(2)(a)": [ + "PRI-06.4" ], - "Sec 20": [ - "DCH-22.1", - "PRI-05", - "PRI-06.1" + "3.A.8.24(2)(b)": [ + "PRI-06.4" ], - "Inferred": [ - "PRI-01" + "3.A.8.24(2)(c)": [ + "PRI-06.4" ], - "Expectation": [ - "PRI-01" + "3.A.8.24(2)(d)": [ + "PRI-06.4" ], - "Sec 4d": [ - "PRI-01.1", - "PRI-15" + "3.A.7.21(1)": [ + "PRI-07.1" ], - "Sec 4f": [ - "PRI-01.1" + "3.A.7.21(2)": [ + "PRI-07.1" ], - "Sec 4g": [ - "PRI-01.1" + "3.A.3.14(8)": [ + "PRI-17", + "PRI-18" ], - "Sec 4": [ - "PRI-02", - "PRI-04", - "PRI-04.1" + "8.71(1)": [ + "PRI-19" ], - "Sec 19": [ - "PRI-02", - "PRI-06" + "8.71(2)": [ + "PRI-19" ], - "Sec 4a": [ - "PRI-03" + "8.71(2)(a)": [ + "PRI-19" ], - "Sec 11": [ - "PRI-03" + "8.71(2)(a)(i)": [ + "PRI-19" ], - "Sec 3a": [ - "PRI-05" + "8.71(2)(a)(ii)": [ + "PRI-19" ], - "Sec 5": [ - "PRI-05" + "8.71(2)(b)": [ + "PRI-19" ], - "Sec 13": [ - "PRI-05" + "8.71(3)": [ + "PRI-19" ], - "Sec 14": [ - "PRI-05" + "8.71(3)(b)": [ + "PRI-19.1" ], - "Sec 4e": [ - "PRI-15" + "8.71(3)(a)": [ + "PRI-19.2" ] }, - "emea-deu-bsrit-2017": { - "4.1": [ + "emea-esp-decree-311-2022": { + "Article 8(1)": [ "GOV-01" ], - "1.1": [ - "GOV-01.1", - "PRM-01.1" - ], - "1.2": [ - "GOV-01.1", - "PRM-01.1" - ], - "1.2(a)": [ - "GOV-01.1", - "PRM-01.1" + "Article 8(2)": [ + "GOV-01" ], - "1.2(b)": [ - "GOV-01.1", - "PRM-01.1" + "Article 8(5)": [ + "GOV-01" ], - "1.2(c)": [ - "GOV-01.1", - "PRM-01.1" + "Article 9(1)": [ + "GOV-01" ], - "1.2(d)": [ - "GOV-01.1", - "PRM-01.1" + "Article 9(1)(a)": [ + "GOV-01" ], - "1.2(e)": [ - "GOV-01.1", - "PRM-01.1" + "Article 9(1)(b)": [ + "GOV-01" ], - "1.2(f)": [ - "GOV-01.1", - "PRM-01.1" + "Article 9(2)": [ + "GOV-01" ], - "2.1": [ - "GOV-01.1" + "Article 10(1)": [ + "GOV-01" ], - "2.2": [ - "GOV-01.1" + "Article 10(2)": [ + "GOV-01" ], - "2.3": [ - "GOV-01.1", - "PRM-01", - "PRM-02", - "PRM-03" + "Article 10(3)": [ + "GOV-01" ], - "2.4": [ - "GOV-01.1" + "Article 12(6)(a)": [ + "GOV-01" ], - "2.5": [ + "Article 12(1)(d)": [ "GOV-01.1" ], - "3.9": [ - "GOV-01.2", - "RSK-01" - ], - "3.11": [ - "GOV-01.2", - "RSK-01" + "Article 31(6)": [ + "GOV-01.2" ], - "4.10": [ - "GOV-01.2", - "GOV-04.1", - "GOV-04.2" + "Article 12(6)(ñ)": [ + "GOV-01.3" ], - "7.5": [ - "GOV-01.2", - "PRM-01" + "Article 27": [ + "GOV-01.3" ], - "4.2": [ - "GOV-02", - "GOV-03" + "Article 12(1)(b)": [ + "GOV-01.4" ], - "4.3": [ + "Article 11(3)": [ "GOV-02" ], - "4.8": [ - "GOV-02", - "GOV-03" + "Article 12(1)": [ + "GOV-02" ], - "4.4": [ - "GOV-04" + "Article 12(6)": [ + "GOV-02" ], - "4.5": [ + "Article 13(3)": [ "GOV-04", "GOV-04.1", - "GOV-04.2" + "TPM-05.4" ], - "4.6": [ - "GOV-04", + "Article 11(2)": [ "GOV-04.1", - "GOV-04.2" + "AST-01.2", + "TPM-05.4" ], - "5.1": [ + "Article 12(1)(a)": [ + "GOV-08" + ], + "Article 13(2)(d)": [ + "GOV-15" + ], + "Article 15(1)": [ "GOV-15", + "CPL-03", + "SAT-03" + ], + "Article 28(2)": [ "GOV-15.1" ], - "5.2": [ - "GOV-15.2" + "Article 14(1)": [ + "GOV-19.3", + "RSK-11", + "SEA-02.2" ], - "12.2": [ - "AST-01", - "AST-01.1", - "AST-02", - "BCD-02" + "Article 16(2)": [ + "GOV-19.3", + "HRS-03.2" ], - "8.2": [ - "AST-02", - "OPS-03" + "Article 11(1)": [ + "AST-01.2" ], - "12.4": [ + "Article 40(1)": [ "AST-04.1", "DCH-02" ], - "10.1": [ - "BCD-01" + "Article 40(2)": [ + "AST-04.1" ], - "10.2": [ + "Article 12(6)(n)": [ "BCD-01" ], - "10.3": [ + "Article 22(2)": [ "BCD-01" ], - "10.5": [ - "BCD-01", - "BCD-08", - "BCD-09" + "Article 26": [ + "BCD-11" ], - "10.4": [ - "BCD-04" + "Article 37": [ + "CPL-01" ], - "8.7": [ - "BCD-11" + "Article 38(1)": [ + "CPL-01.3" ], - "8.8": [ - "CAP-01", - "CAP-03", - "CAP-04" + "Article 31(1)": [ + "CPL-01.4" + ], + "Article 31(2)": [ + "CPL-01.4" + ], + "Article 31(3)": [ + "CPL-01.4" + ], + "Article 31(4)": [ + "CPL-01.4" + ], + "Article 31(5)": [ + "CPL-01.4" + ], + "Article 31(7)": [ + "CPL-01.4" + ], + "Article 38(2)": [ + "CPL-01.5" + ], + "Article 16(1)": [ + "CPL-02", + "PRM-04" + ], + "Article 12(7)": [ + "CFG-02" + ], + "Article 20(a)": [ + "CFG-02" + ], + "Article 20(c)": [ + "CFG-02", + "CFG-03" ], - "8.4": [ - "CHG-01" + "Article 20(d)": [ + "CFG-02" ], - "8.5": [ - "CHG-02" + "Single Transitional Provision(3)": [ + "CFG-02" ], - "12.5": [ - "CPL-01" + "Article 21(2)": [ + "CFG-02.2" ], - "5.6": [ - "CPL-02", - "CPL-03", - "CPL-03.2", - "VPM-01", - "VPM-06", - "VPM-07", - "VPM-10" + "Article 8(3)": [ + "MON-01" ], - "6.8": [ - "CFG-01", - "CFG-02" + "Article 12(6)(l)": [ + "MON-01" ], - "8.6": [ - "CFG-02.8" + "Article 24(1)": [ + "MON-01" ], - "5.5": [ - "MON-01", - "MON-01.8", - "MON-01.16", - "MON-16" + "Article 24(2)": [ + "MON-01" ], - "6.3": [ - "MON-01", - "MON-01.16", + "Article 20(b)": [ "MON-03" ], - "6.7": [ - "MON-01", - "MON-01.14", - "MON-01.15", - "MON-01.16" + "Article 12(6)(j)": [ + "CRY-01" ], - "5.4": [ - "MON-11.3", - "IRO-03" + "Article 22(3)": [ + "DCH-01", + "DCH-01.2" ], - "7.13": [ - "DCH-02", - "TDA-01", - "TDA-01.1", - "TDA-09" + "Article 22(1)": [ + "DCH-13", + "DCH-13.2", + "MDM-01" ], - "7.14": [ - "DCH-02", - "TDA-01", - "TDA-01.1", - "TDA-09" + "Article 23": [ + "END-02", + "NET-05" ], - "6.1": [ - "IAC-01" + "Article 12(6)(c)": [ + "HRS-01" ], - "6.2": [ - "IAC-01", - "IAC-08", - "IAC-15", - "IAC-15.7", - "IAC-17", - "IAC-21" + "Article 16(3)": [ + "HRS-02", + "SAT-03" ], - "6.4": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2" + "Article 12(1)(c)": [ + "HRS-03" ], - "6.5": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2" + "Article 13(2)": [ + "HRS-03", + "HRS-05.7" ], - "6.6": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2" + "Article 12(6)(d)": [ + "HRS-05" ], - "4.7": [ - "IRO-01", - "IRO-02" + "Article 13(1)": [ + "HRS-05" ], - "7.11": [ - "IAO-01", - "IAO-02", - "IAO-02.2", - "TDA-01", - "TDA-01.1", - "TDA-09" + "Article 15(2)": [ + "HRS-05.1", + "IAO-03" ], - "7.4": [ - "PRM-01" + "Article 12(6)(e)": [ + "IAC-01" ], - "8.3": [ - "PRM-01", - "SEA-07.1" + "Article 24(3)": [ + "IAC-01" ], - "7.1": [ - "PRM-04", - "PRM-07" + "Article 17": [ + "IAC-08" ], - "7.2": [ - "PRM-04", - "PRM-07" + "Article 12(6)(h)": [ + "IAC-21" ], - "7.3": [ - "PRM-04", - "PRM-07" + "Article 20": [ + "IAC-21" ], - "3.1": [ - "RSK-01" + "Article 8(4)": [ + "IRO-01" ], - "3.2": [ - "RSK-01" + "Article 12(6)(m)": [ + "IRO-01" ], - "3.3": [ - "RSK-01", - "RSK-03.1", - "THR-09" + "Article 25(1)": [ + "IRO-01" ], - "3.4": [ - "RSK-01" + "Article 25(2)": [ + "IRO-02" ], - "3.5": [ - "RSK-01" + "Article 34(1)(a)": [ + "IRO-02" ], - "3.6": [ - "RSK-01" + "Article 33(7)": [ + "IRO-10.5" ], - "3.7": [ - "RSK-01" + "Article 13(2)(c)": [ + "IAO-01" ], - "3.8": [ - "RSK-01" + "Article 21(1)": [ + "IAO-01", + "IAO-07" ], - "3.10": [ - "RSK-01", - "RSK-04", - "THR-01", - "THR-10" + "Article 12(1)(e)": [ + "IAO-03" ], - "12.3": [ - "RSK-01" + "Article 12(6)(k)": [ + "NET-01" ], - "12.1": [ - "SEA-01", - "SEA-02", - "SEA-03" + "Article 18": [ + "NET-01" ], - "8.1": [ - "OPS-03" + "Article 12(6)(f)": [ + "PES-01" ], - "11.1": [ - "OPS-03" + "Article 5(a)": [ + "PRI-01.6" ], - "11.2": [ - "OPS-03" + "Article 5(b)": [ + "PRI-01.6" ], - "11.3": [ - "OPS-03" + "Article 5(c)": [ + "PRI-01.6" ], - "11.4": [ - "OPS-03" + "Article 5(d)": [ + "PRI-01.6" ], - "11.5": [ - "OPS-03" + "Article 5(e)": [ + "PRI-01.6" ], - "11.6": [ - "OPS-03" + "Article 5(f)": [ + "PRI-01.6" ], - "11.7": [ - "OPS-03" + "Article 5(g)": [ + "PRI-01.6" ], - "11.8": [ - "OPS-03" + "Article 13(2)(a)": [ + "PRM-05", + "PRM-06" ], - "4.9": [ - "SAT-01" + "Article 13(2)(b)": [ + "PRM-05", + "PRM-06" ], - "7.7": [ - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-06", - "TDA-09" + "Article 7(2)": [ + "RSK-01" ], - "7.8": [ - "TDA-01", - "TDA-01.1", - "TDA-06", - "TDA-09" + "Article 12(6)(b)": [ + "RSK-01" ], - "7.9": [ - "TDA-01", - "TDA-01.1", - "TDA-06", - "TDA-09", - "TDA-20" + "Article 14(2)": [ + "RSK-01.1", + "RSK-04" ], - "7.10": [ - "TDA-01", - "TDA-01.1", - "TDA-06", - "TDA-09" + "Article 3(3)": [ + "RSK-06" ], - "7.12": [ - "TDA-01", - "TDA-01.1", - "TDA-09" + "Article 28(3)": [ + "RSK-06.2" ], - "7.6": [ - "TDA-06" + "Article 14(3)": [ + "RSK-06.4" ], - "9.1": [ - "TPM-01" + "Article 3(2)": [ + "RSK-10" ], - "9.3": [ - "TPM-03.1" + "Article 12(1)(f)": [ + "RSK-10" ], - "9.2": [ - "TPM-04", - "TPM-04.1" + "Article 6(2)": [ + "SAT-03" ], - "9.5": [ - "TPM-04.1" + "Article 12(6)(g)": [ + "TDA-01" ], - "9.4": [ - "TPM-05" + "Article 19(1)": [ + "TDA-01" ], - "5.3": [ - "THR-01", - "THR-03", - "THR-09", - "THR-10" + "Article 13(5)": [ + "TPM-05.4", + "TPM-06" + ], + "Article 12(6)(i)": [ + "VPM-01" ] }, - "emea-deu-c5-2020": { - "OIS-01": [ + "emea-esp-ccn-stic-825-2026": { + "org.1": [ "GOV-01", "GOV-02", "GOV-03", - "GOV-09" + "PRI-01", + "PRI-01.3" ], - "OIS-02": [ + "org.2": [ + "GOV-01", "GOV-02", - "GOV-09" + "GOV-03", + "PRI-01", + "PRI-01.3" ], - "SP-01": [ + "org.3": [ + "GOV-01", "GOV-02", - "CPL-01", + "GOV-03", "OPS-01", - "OPS-01.1" - ], - "SP-02": [ - "GOV-03" + "OPS-01.1", + "OPS-03" ], - "OIS-03": [ - "GOV-04" + "op.mon.2": [ + "GOV-01.2", + "GOV-05", + "CPL-01", + "CPL-01.1", + "CPL-01.2", + "CPL-03" ], - "COM-04": [ - "GOV-05" + "org.4": [ + "GOV-04", + "HRS-03", + "HRS-04.1", + "TPM-05.4", + "TPM-06" ], - "OIS-05": [ - "GOV-06", - "MON-02.6" + "mp.info.2": [ + "GOV-10", + "AST-04.1", + "DCH-01", + "DCH-02" ], - "AM-03": [ + "op.cont.3": [ "AST-01", - "CFG-01", - "CFG-02" + "AST-01.1", + "BCD-01", + "BCD-01.1", + "BCD-01.2", + "BCD-04", + "IRO-06", + "RSK-08" ], - "AM-01": [ + "op.pl.2": [ + "AST-01.1", + "AST-01.2", "AST-02", - "AST-02.1" + "AST-02.8", + "AST-03", + "AST-03.1", + "AST-04", + "DCH-01", + "DCH-02", + "PRI-05.5", + "PRM-05" ], - "AM-02": [ + "op.exp.1": [ + "AST-01.1", + "AST-01.2", "AST-02", - "AST-02.1", - "AST-02.2", - "AST-06.1", - "CFG-02", - "CFG-03.3", - "DCH-02" + "AST-02.8", + "AST-03", + "AST-03.1", + "AST-04", + "DCH-01", + "DCH-02", + "PRI-05.5", + "PRM-05" ], - "SP-03": [ - "AST-02.4", - "CPL-02", - "RSK-03", - "RSK-04", - "RSK-04.1" + "op.exp.2": [ + "AST-02.9", + "CFG-01", + "CFG-01.1", + "CFG-02", + "CFG-02.1", + "CFG-03" ], - "COS-07": [ - "AST-04" + "op.exp.3": [ + "AST-02.9", + "CFG-01", + "CFG-01.1", + "CFG-02", + "CFG-02.1", + "CFG-03" ], - "AM-04": [ - "AST-09", - "AST-10" + "op.ext.3": [ + "AST-03.2", + "IAO-01", + "IAO-02", + "IAO-02.2", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-04.4", + "TPM-05", + "TPM-05.1" ], - "PI-03": [ - "AST-09", - "DCH-08", - "DCH-21", - "PRI-05" + "op.mon.1": [ + "AST-04", + "NET-01", + "NET-02", + "NET-03", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "AM-05": [ - "AST-10", - "HRS-05", - "HRS-05.5" + "mp.com.1": [ + "AST-04", + "NET-01", + "NET-02", + "NET-03", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" ], - "BCM-01": [ - "BCD-01" + "mp.eq.1": [ + "AST-06", + "END-01", + "PES-04" ], - "BCM-02": [ - "BCD-01", - "BCD-02", - "CHG-03", - "RSK-08", - "RSK-10" + "mp.eq.2": [ + "AST-06", + "END-01", + "PES-04" ], - "BCM-03": [ - "BCD-01" + "mp.eq.3": [ + "AST-06", + "AST-07", + "AST-12", + "END-01", + "END-02", + "IAC-22", + "MDM-01", + "MDM-02", + "MDM-05" ], - "OPS-06": [ - "BCD-01.4", - "BCD-11", - "BCD-11.1", - "BCD-11.2" + "mp.eq.4": [ + "AST-06", + "AST-07", + "AST-12", + "END-01", + "END-02", + "IAC-22", + "MDM-01", + "MDM-02", + "MDM-05" ], - "OPS-08": [ - "BCD-01.4", - "BCD-11.1" + "mp.si.3": [ + "AST-11", + "AST-12", + "DCH-01", + "DCH-03", + "DCH-06", + "DCH-07", + "DCH-07.2", + "DCH-08", + "DCH-10", + "DCH-10.1", + "DCH-12" ], - "OPS-09": [ - "BCD-01.4", - "BCD-08.1", - "BCD-09.1", - "BCD-11.3", - "CRY-04" + "mp.si.4": [ + "AST-11", + "AST-12", + "DCH-01", + "DCH-03", + "DCH-06", + "DCH-07", + "DCH-07.2", + "DCH-08", + "DCH-10", + "DCH-10.1", + "DCH-12" ], - "PS-02": [ - "BCD-04", - "BCD-11.7", - "PES-11" + "mp.si.5": [ + "AST-11", + "AST-12", + "DCH-01", + "DCH-03", + "DCH-06", + "DCH-07", + "DCH-07.2", + "DCH-08", + "DCH-10", + "DCH-10.1", + "DCH-12" ], - "PS-06": [ + "op.cont.1": [ + "BCD-01", + "BCD-01.1", + "BCD-01.2", "BCD-04", - "PES-07", - "PES-07.3", - "PES-09", - "PES-09.1" + "IRO-05", + "IRO-06.1", + "IRO-11.2" ], - "BCM-04": [ + "op.cont.2": [ + "BCD-01", + "BCD-01.1", + "BCD-01.2", "BCD-04", - "BCD-05", - "BCD-06" + "IRO-05", + "IRO-06.1", + "IRO-11.2" ], - "PSS-12": [ + "op.cont.4": [ "BCD-08", "BCD-09", - "BCD-11.2", - "CLD-09", - "TPM-04.4" - ], - "OPS-07": [ - "BCD-11.1" + "BCD-11.7" ], - "OPS-01": [ - "CAP-01", - "CAP-03" + "mp.info.6": [ + "BCD-11", + "BCD-11.1", + "BCD-11.2", + "BCD-11.4" ], - "OPS-02": [ + "op.pl.4": [ "CAP-01", "CAP-03" ], - "OPS-03": [ + "mp.s.4": [ "CAP-01", "CAP-03" ], - "DEV-03": [ - "CHG-01" - ], - "DEV-08": [ + "op.exp.5": [ "CHG-01", "CHG-02", "CHG-02.2", - "CHG-04.5", + "PRM-07", + "TDA-14" + ], + "op.nub.1": [ + "CLD-01" + ], + "mp.info.4": [ + "CLD-04", + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-04", + "PRM-05", + "SEA-01", + "SEA-02", "TDA-06" ], - "IDM-02": [ - "CHG-02.1", - "IAC-07", - "IAC-09.5", - "IAC-28.1", - "OPS-01.1" + "mp.s.2": [ + "CLD-04", + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-04", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-06" ], - "DEV-06": [ - "CHG-02.2" + "op.acc.6": [ + "CFG-02", + "END-01", + "END-02", + "END-09", + "SEA-17" ], - "DEV-09": [ - "CHG-02.2", - "CHG-02.3", - "CHG-04", - "CHG-04.4" + "mp.sw.1": [ + "CFG-02", + "CFG-02.4", + "IAO-04", + "PRM-07", + "TDA-01", + "TDA-02", + "TDA-02.3", + "TDA-06", + "TDA-07", + "TDA-08", + "TDA-09" ], - "DEV-05": [ - "CHG-02.3", - "CHG-03" + "op.exp.8": [ + "MON-01", + "MON-01.4", + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-03", + "MON-03.3", + "MON-06", + "MON-08" ], - "PSS-08": [ - "CHG-04.4", - "HRS-03", - "HRS-04.1", - "HRS-12", - "IAC-07.1", - "IAC-08" + "op.mon.3": [ + "MON-11", + "MON-11.3", + "THR-01", + "THR-02", + "THR-03", + "THR-03.1" ], - "DEV-07": [ - "CHG-04.5", - "TDA-06", - "TDA-20" + "op.exp.10": [ + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "COS-01": [ - "CLD-01", - "CLD-02", - "CLD-03", - "SEA-01", - "SEA-02", - "SEA-03" + "mp.si.2": [ + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "COS-02": [ - "CLD-01", - "CLD-02", - "CLD-03" + "mp.info.3": [ + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "COS-05": [ - "CLD-03" + "mp.s.1": [ + "CRY-03", + "DCH-07", + "DCH-07.1", + "DCH-14", + "DCH-17", + "HRS-05", + "HRS-05.1", + "HRS-06", + "HRS-06.1", + "NET-01", + "NET-04", + "NET-04.1", + "NET-13", + "NET-18", + "PES-01" ], - "PI-01": [ - "CLD-04", - "CLD-07", - "DCH-02" + "mp.si.1": [ + "DCH-04" + ], + "op.exp.6": [ + "END-04", + "END-04.1" + ], + "op.pl.1": [ + "HRS-04", + "HRS-04.1" + ], + "mp.per.1": [ + "HRS-04", + "HRS-04.1" + ], + "op.acc.3": [ + "HRS-11", + "HRS-12" + ], + "op.acc.4": [ + "HRS-11", + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-10.11", + "IAC-15", + "IAC-15.1", + "IAC-15.2", + "IAC-16", + "IAC-16.1", + "IAC-17", + "IAC-19", + "IAC-20", + "IAC-20.1", + "IAC-20.2", + "IAC-20.3", + "IAC-21", + "IAC-21.3", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03" + ], + "op.acc.5": [ + "HRS-11", + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-10.11", + "IAC-15", + "IAC-15.1", + "IAC-15.2", + "IAC-16", + "IAC-16.1", + "IAC-17", + "IAC-19", + "IAC-20", + "IAC-20.1", + "IAC-20.2", + "IAC-20.3", + "IAC-21", + "IAC-21.3", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03" ], - "PSS-11": [ - "CLD-05", - "CLD-08", + "op.acc.2": [ + "IAC-01", + "IAC-02", "IAC-08", - "SEA-13.1" + "IAC-15", + "IAC-16", + "IAC-17", + "IAC-21", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03", + "PES-04", + "PES-04.1" ], - "OPS-24": [ - "CLD-06", - "SEA-05" + "op.acc.1": [ + "IAC-03", + "IAC-04", + "IAC-05", + "IAC-07", + "IAC-09", + "IAC-09.1", + "IAC-09.4", + "IAC-15", + "IAC-15.3", + "IAC-15.5" ], - "PI-02": [ - "CLD-07", - "CLD-09", - "CPL-01", - "IAO-03.2", - "PRI-07.1", - "TPM-04.4", - "TPM-05" + "op.exp.7": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-13" ], - "COS-04": [ - "CLD-11", + "op.exp.9": [ + "IRO-02", + "IRO-04", + "IRO-07", + "IRO-08" + ], + "mp.sw.2": [ + "IAO-02", + "IAO-02.2", + "TDA-02", + "TDA-02.3", + "TDA-06.1", + "TDA-09" + ], + "op.exp.4": [ + "MNT-01", + "MNT-02", + "MNT-03" + ], + "mp.com.2": [ + "NET-01", "NET-03", - "NET-03.1", - "NET-06.1" + "NET-08", + "NET-15", + "TPM-05", + "TPM-08" ], - "COM-01": [ - "CPL-01", - "CPL-03.2" + "mp.com.3": [ + "NET-01", + "NET-03", + "NET-08", + "NET-15", + "TPM-05", + "TPM-08" ], - "COM-03": [ - "CPL-03", - "CPL-03.1", - "CPL-04" + "op.ext.4": [ + "NET-06", + "NET-06.1", + "WEB-02" ], - "COM-02": [ - "CPL-04" + "mp.com.4": [ + "NET-06", + "NET-06.1", + "WEB-02" ], - "INQ-01": [ - "CPL-05" + "mp.s.3": [ + "NET-18" ], - "INQ-02": [ - "CPL-05.1" + "mp.if.1": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1", + "PES-04" ], - "INQ-03": [ - "CPL-05.2" + "mp.if.3": [ + "PES-01", + "PES-04", + "PES-12", + "RSK-01", + "RSK-04" ], - "INQ-04": [ - "CPL-05.2" + "mp.if.5": [ + "PES-01", + "PES-04", + "PES-12", + "RSK-01", + "RSK-04" ], - "OPS-23": [ - "CFG-02" + "mp.if.6": [ + "PES-01", + "PES-04", + "PES-12", + "RSK-01", + "RSK-04" ], - "OPS-10": [ - "MON-01", - "MON-01.16" + "mp.if.2": [ + "PES-03.1", + "PES-03.3", + "PES-04.1", + "PES-06", + "PES-10" ], - "OPS-13": [ - "MON-01.2", - "MON-01.4", - "MON-02.1", - "MON-02.2" + "mp.if.7": [ + "PES-03.1", + "PES-03.3", + "PES-04.1", + "PES-06", + "PES-10" ], - "OPS-14": [ - "MON-02", - "MON-10" + "mp.if.4": [ + "PES-07", + "PES-07.1", + "PES-07.2", + "PES-07.3", + "PES-07.4" ], - "OPS-15": [ - "MON-03" + "mp.info.1": [ + "PRI-01", + "PRI-01.6", + "PRI-02", + "PRI-02.1" ], - "OPS-16": [ - "MON-03.3", - "MON-08", - "MON-08.2" + "op.pl.3": [ + "PRM-01", + "PRM-04", + "PRM-05", + "PRM-07", + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-06", + "RSK-06.1", + "SEA-02" ], - "OPS-17": [ - "MON-05", - "MON-05.1" + "mp.per.3": [ + "SAT-01", + "SAT-02", + "SAT-03" ], - "CRY-01": [ - "CRY-01" + "mp.per.4": [ + "SAT-01", + "SAT-02", + "SAT-03" ], - "CRY-02": [ - "CRY-03" + "op.ext.1": [ + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-04.3", + "TPM-05", + "TPM-06", + "TPM-08", + "TPM-09", + "TPM-11" ], - "CRY-03": [ - "CRY-05", - "CRY-05.1" + "op.ext.2": [ + "TPM-03", + "TPM-03.1", + "TPM-03.3", + "TPM-08", + "TPM-10" + ] + }, + "emea-che-fadp-2025": { + "2.2.14.1.b": [ + "CPL-01" ], - "CRY-04": [ - "CRY-09" + "2.2.14.1.c": [ + "CPL-01" ], - "COS-08": [ - "DCH-01", - "DCH-02" + "2.2.14.1.d": [ + "CPL-01" ], - "AM-06": [ - "DCH-01.1", - "DCH-02", - "DCH-04" + "2.2.14.1.a": [ + "CPL-01.2" ], - "OPS-04": [ - "END-04" + "2.2.15.2": [ + "CPL-05.2" ], - "OPS-05": [ - "END-04" + "2.2.14.1": [ + "CPL-08" ], - "HR-01": [ - "HRS-04", - "HRS-04.1" + "2.2.14.2": [ + "CPL-08" ], - "HR-02": [ - "HRS-05", - "HRS-06" + "2.2.14.3": [ + "CPL-08" ], - "HR-03": [ - "HRS-05", - "HRS-05.1", - "SAT-01", - "SAT-02" + "2.1.7.3": [ + "DCH-18.1", + "END-13.3" ], - "HR-06": [ - "HRS-06.1", - "IAO-03.2", - "PRI-07.1", - "TPM-05" + "5.30.1": [ + "HRS-05" ], - "IDM-08": [ - "HRS-06.1", - "IAC-10", - "IAC-10.5" + "5.30.2": [ + "HRS-05" ], - "PSS-07": [ - "HRS-06.1", - "IAC-10.1", - "IAC-10.4", - "IAC-10.5" + "5.30.2.a": [ + "HRS-05" ], - "HR-04": [ - "HRS-07" + "5.30.2.b": [ + "HRS-05" ], - "HR-05": [ - "HRS-08", - "HRS-09" + "5.30.2.c": [ + "HRS-05" ], - "IDM-04": [ - "HRS-08", - "IAC-15.2" + "5.30.3": [ + "HRS-05" ], - "OIS-04": [ - "HRS-11" + "3.24.1": [ + "IRO-10" ], - "IDM-01": [ - "HRS-11", - "IAC-01", - "IAC-02", - "IAC-07", - "IAC-09", - "IAC-28.1" + "3.24.2": [ + "IRO-10" ], - "PSS-05": [ - "IAC-01", - "IAC-02", - "IAC-03", - "IAC-03.2", - "IAC-04", - "IAC-05", - "WEB-06" + "3.24.3": [ + "IRO-10" ], - "PSS-09": [ - "IAC-01", - "IAC-02", - "IAC-03", - "IAC-03.2", - "IAC-04", - "IAC-05", - "IAC-07", - "IAC-15.2" + "3.24.4": [ + "IRO-10" ], - "PS-04": [ - "IAC-07.1", - "PES-03", - "PES-03.4", - "PES-04", - "PES-06" + "3.24.5": [ + "IRO-10" ], - "IDM-09": [ - "IAC-10.1", - "IAC-10.2" + "3.24.5.a": [ + "IRO-10" ], - "IDM-03": [ - "IAC-15.3" + "3.24.5.b": [ + "IRO-10" ], - "IDM-06": [ - "IAC-16", - "IAC-20.3" + "3.24.5.c": [ + "IRO-10" ], - "IDM-05": [ - "IAC-17" + "3.24.5bis": [ + "IRO-10" + ], + "3.24.6": [ + "IRO-10" + ], + "2.1.10.1": [ + "PRI-01.4" + ], + "2.1.10.2": [ + "PRI-01.4" + ], + "2.1.10.2.b": [ + "PRI-01.4" + ], + "2.3.16.1": [ + "PRI-01.5" + ], + "2.3.16.2": [ + "PRI-01.5" + ], + "2.3.16.2.a": [ + "PRI-01.5" + ], + "2.3.16.2.b": [ + "PRI-01.5" + ], + "2.3.16.2.c": [ + "PRI-01.5" + ], + "2.3.16.2.d": [ + "PRI-01.5" + ], + "2.3.16.2.e": [ + "PRI-01.5" ], - "IDM-07": [ - "IAC-21" + "2.3.16.3": [ + "PRI-01.5" ], - "PSS-06": [ - "IAC-23", - "IAC-24", - "IAC-25", - "NET-09", - "NET-09.1" + "2.1.7.2": [ + "PRI-01.6" ], - "SIM-01": [ - "IRO-01" + "2.1.8.1": [ + "PRI-01.6" ], - "SIM-02": [ - "IRO-02", - "IRO-04.1" + "2.1.8.2": [ + "PRI-01.6" ], - "OPS-21": [ - "IRO-02.5", - "IRO-12.3" + "2.1.6.1": [ + "PRI-01.11" ], - "SIM-03": [ - "IRO-08", - "IRO-10" + "2.1.6.2": [ + "PRI-01.11" ], - "SIM-04": [ - "IRO-10" + "2.1.7.1": [ + "PRI-01.11" ], - "PSS-02": [ - "IRO-10.3", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-03", - "VPM-04", - "VPM-06", - "VPM-06.6", - "VPM-06.7", - "VPM-07", - "VPM-07.1" + "4.25.6": [ + "PRI-01.11" ], - "SIM-05": [ - "IRO-13" + "2.2.15.3": [ + "PRI-02" ], - "PSS-10": [ - "NET-01", - "NET-02", - "NET-03" + "3.19.1": [ + "PRI-02" ], - "COS-03": [ - "NET-03.2", - "NET-04", - "NET-04.6", - "NET-05" + "3.19.2": [ + "PRI-02" ], - "COS-06": [ - "NET-06", - "SEA-05" + "3.19.2.a": [ + "PRI-02" ], - "PS-01": [ - "PES-01", - "PES-07", - "PES-07.3", - "PES-07.5", - "PES-08" + "3.19.2.b": [ + "PRI-02" ], - "PS-03": [ - "PES-03", - "PES-03.1" + "3.19.2.c": [ + "PRI-02" ], - "PS-05": [ - "PES-08", - "PES-08.1", - "PES-08.2", - "PES-08.3" + "3.19.3": [ + "PRI-02" ], - "PS-07": [ - "PES-09", - "PES-09.1" + "3.19.4": [ + "PRI-02" ], - "OPS-11": [ - "PRI-05" + "3.19.5": [ + "PRI-02" ], - "OPS-12": [ - "PRI-05" + "3.21.1": [ + "PRI-02" ], - "OIS-06": [ - "RSK-01" + "2.1.6.6": [ + "PRI-03" ], - "OIS-07": [ - "RSK-04", - "RSK-09" + "2.1.6.7": [ + "PRI-03" ], - "PSS-01": [ - "OPS-05" + "2.1.6.7.a": [ + "PRI-03" ], - "DEV-04": [ - "SAT-01", - "SAT-02", - "SAT-03", - "SAT-03.4" + "2.1.6.7.b": [ + "PRI-03" ], - "DEV-01": [ - "TDA-01" + "2.1.6.7.c": [ + "PRI-03" ], - "DEV-02": [ - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-05", - "TDA-06", - "TDA-07", - "TDA-09", - "TDA-13", - "TDA-14", - "TDA-15" + "2.1.6.3": [ + "PRI-04" ], - "DEV-10": [ - "TDA-07", - "TDA-08" + "2.1.6.4": [ + "PRI-05" ], - "PSS-04": [ - "TDA-19" + "2.1.6.5": [ + "PRI-05.2" ], - "SSO-01": [ - "TPM-01" + "3.21.2": [ + "PRI-06" ], - "SSO-03": [ - "TPM-01", - "TPM-02", - "TPM-03" + "4.25.1": [ + "PRI-06" ], - "SSO-02": [ - "TPM-02", - "TPM-03", - "TPM-03.2", - "TPM-03.3", - "TPM-04.1", - "TPM-05" + "4.25.2": [ + "PRI-06" ], - "SSO-05": [ - "TPM-03.1", - "TPM-04", - "TPM-05", - "TPM-08", - "TPM-10" + "4.25.2.a": [ + "PRI-06" ], - "SSO-04": [ - "TPM-04.1", - "TPM-07", - "TPM-08", - "TPM-09", - "TPM-10" + "4.25.2.b": [ + "PRI-06" ], - "OPS-18": [ - "VPM-01", - "VPM-02", - "VPM-03", - "VPM-04" + "4.25.2.c": [ + "PRI-06" ], - "OPS-22": [ - "VPM-03", - "VPM-06" + "4.25.2.d": [ + "PRI-06" ], - "PSS-03": [ - "VPM-05", - "VPM-05.1", - "VPM-06", - "VPM-06.1" + "4.25.2.e": [ + "PRI-06" ], - "OPS-19": [ - "VPM-05.3", - "VPM-07", - "VPM-07.1" + "4.25.2.f": [ + "PRI-06" ], - "OPS-20": [ - "VPM-06.4", - "VPM-06.5" - ] - }, - "emea-grc-pirppd-1997": { - "4": [ - "PRI-04", - "PRI-04.1", - "PRI-05" + "4.25.2.g": [ + "PRI-06" ], - "5": [ - "PRI-03" + "4.25.3": [ + "PRI-06" ], - "6": [ - "PRI-15" + "4.25.4": [ + "PRI-06" ], - "7": [ - "PRI-05" + "4.25.5": [ + "PRI-06" ], - "9": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "4.28.1": [ + "PRI-06" ], - "10": [ - "GOV-01", - "CPL-01", - "CPL-02" + "4.28.1.a": [ + "PRI-06" ], - "11": [ + "4.28.1.b": [ "PRI-06" ], - "12": [ + "4.28.2": [ "PRI-06" ], - "13": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.3" + "4.25.7": [ + "PRI-06.4" ], - "Inferred": [ - "PRI-01" + "4.28.3": [ + "PRI-06.4" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-hun-isdfi-2011": { - "4": [ - "PRI-04", - "PRI-04.1" + "2.1.12.1": [ + "PRI-14" ], - "5": [ - "PRI-04", - "PRI-04.1", - "PRI-05" + "2.1.12.2": [ + "PRI-14" ], - "6": [ - "PRI-03" + "2.1.12.2.a": [ + "PRI-14" ], - "7": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "2.1.12.2.b": [ + "PRI-14" ], - "8": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "2.1.12.2.c": [ + "PRI-14" ], - "9": [ - "PRI-05.1", - "PRI-05.4" + "2.1.12.2.d": [ + "PRI-14" ], - "14": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "PRI-06.4" + "2.1.12.2.e": [ + "PRI-14" ], - "15": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "PRI-06.4" + "2.1.12.2.f": [ + "PRI-14" ], - "17": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "PRI-06.4" + "2.1.12.2.g": [ + "PRI-14" ], - "18": [ - "PRI-06.2", - "PRI-06.3" + "2.1.12.3": [ + "PRI-14" ], - "24": [ - "PRI-01.1" + "2.2.15.1": [ + "PRI-14" ], - "65": [ - "PRI-15" + "3.21.3.a": [ + "PRI-19", + "PRI-19.3" ], - "66": [ - "PRI-15" + "3.21.3.b": [ + "PRI-19.2" ], - "Inferred": [ - "PRI-01" + "3.22.1": [ + "RSK-10" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-irl-dpa-2003": { - "2": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-22.1", - "DCH-24", - "DCH-24.1", - "PRI-01.1", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "3.22.2": [ + "RSK-10" ], - "17": [ - "PRI-15" + "3.22.2.a": [ + "RSK-10" ], - "Inferred": [ - "PRI-01" + "3.22.2.b": [ + "RSK-10" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-isr-cmo-1-0": { - "3.2": [ - "GOV-01" + "3.22.3": [ + "RSK-10" ], - "4.25": [ - "GOV-01", - "GOV-02", - "MDM-01" + "3.22.4": [ + "RSK-10" ], - "1.1": [ - "GOV-02", - "GOV-03" + "3.22.5": [ + "RSK-10" ], - "4.1": [ - "GOV-02", - "IAC-01" + "3.22.5.a": [ + "RSK-10" ], - "5.2": [ - "GOV-02", - "GOV-03", - "DCH-01" + "3.22.5.b": [ + "RSK-10" ], - "5.3": [ - "GOV-02", - "DCH-01", - "DCH-02" + "3.22.5.c": [ + "RSK-10" ], - "9.1": [ - "GOV-02", - "GOV-03", - "NET-01" + "2.1.10.2.a": [ + "SAT-03" + ] + }, + "emea-tur-lppd-2016": { + "9(1)": [ + "PRI-01.5" ], - "10.1": [ - "GOV-02", - "GOV-03", - "CLD-06", - "CFG-02.4", - "TDA-07", - "TDA-08" + "9(2)": [ + "PRI-01.5" ], - "11.2": [ - "GOV-02", - "GOV-03", - "CLD-01" + "9(3)": [ + "PRI-01.5" ], - "12.1": [ - "GOV-02", - "EMB-01" + "9(3)(a)": [ + "PRI-01.5" ], - "13.1": [ - "GOV-02", - "GOV-03", - "MDM-01" + "9(3)(b)": [ + "PRI-01.5" ], - "14.1": [ - "GOV-02", - "GOV-03", - "CFG-01" + "9(3)(c)": [ + "PRI-01.5" ], - "15.1": [ - "GOV-02", - "GOV-03", - "DCH-01" + "9(3)(ç)": [ + "PRI-01.5" ], - "17.1": [ - "GOV-02", - "GOV-03", - "IAO-01", - "TDA-01" + "9(3)(d)": [ + "PRI-01.5" ], - "18.1": [ - "GOV-02", - "GOV-03", - "PES-01" + "9(3)(e)": [ + "PRI-01.5" ], - "20.1": [ - "GOV-02", - "SAT-01" + "9(4)": [ + "PRI-01.5" ], - "21.1": [ - "GOV-02", - "GOV-03", - "MON-01", - "MON-01.16" + "9(4)(a)": [ + "PRI-01.5" ], - "22.1": [ - "GOV-02", - "GOV-03", - "VPM-01" + "9(4)(b)": [ + "PRI-01.5" ], - "24.1": [ - "GOV-02", - "GOV-03", - "IRO-01" + "9(4)(c)": [ + "PRI-01.5" ], - "25.1": [ - "GOV-02", - "GOV-03", - "BCD-01" + "9(4)(ç)": [ + "PRI-01.5" ], - "6.8": [ - "AST-02.4", - "MON-01", - "MON-01.16", - "RSK-04.1", - "RSK-08" + "9(5)": [ + "PRI-01.5" ], - "23.6": [ - "AST-02.5", - "MON-01.1", - "END-07", - "NET-08", - "NET-08.2" + "9(6)": [ + "PRI-01.5" ], - "3.1": [ - "AST-02.7", - "CPL-02", - "CPL-03", - "CPL-03.2" + "9(6)(a)": [ + "PRI-01.5" ], - "15.4": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-09.3", - "DCH-21", - "PRI-05" + "9(6)(b)": [ + "PRI-01.5" ], - "17.21": [ - "AST-09", - "TDA-11", - "TDA-11.1" + "9(6)(c)": [ + "PRI-01.5" ], - "11.12": [ - "AST-10", - "DCH-21" + "9(6)(ç)": [ + "PRI-01.5" ], - "12.6": [ - "AST-12", - "AST-13" + "9(6)(d)": [ + "PRI-01.5" ], - "11.7": [ - "BCD-01", - "BCD-08", - "BCD-09" + "9(6)(e)": [ + "PRI-01.5" ], - "25.2": [ - "BCD-01.1", - "CAP-01", - "CAP-03" + "9(6)(f)": [ + "PRI-01.5" ], - "21.15": [ - "BCD-02.1", - "BCD-02.3", - "MON-08.1", - "MON-10", - "MON-13" + "9(7)": [ + "PRI-01.5" ], - "21.16": [ - "BCD-02.1", - "BCD-02.3", - "MON-08", - "CRY-01" + "9(8)": [ + "PRI-01.5" ], - "18.15": [ - "BCD-02.2", - "PES-07.3" + "9(9)": [ + "PRI-01.5" ], - "25.23": [ - "BCD-02.2", - "BCD-04" + "9(10)": [ + "PRI-01.5" ], - "25.3": [ - "BCD-03", - "SAT-03" + "9(11)": [ + "PRI-01.5" ], - "25.4": [ - "BCD-03.1", - "BCD-04" + "12(1)": [ + "PRI-01.6" ], - "25.5": [ - "BCD-03.1" + "12(1)(a)": [ + "PRI-01.6" ], - "25.8": [ - "BCD-03.2" + "12(1)(b)": [ + "PRI-01.6" ], - "25.6": [ - "BCD-04", - "BCD-04.1" + "12(1)(c)": [ + "PRI-01.6" ], - "25.7": [ - "BCD-04", - "BCD-04.1", - "BCD-08", - "BCD-09" + "12(2)": [ + "PRI-01.6" ], - "25.9": [ - "BCD-04", - "BCD-11", - "BCD-11.1", - "BCD-12", - "BCD-12.1" + "12(3)": [ + "PRI-01.6" ], - "25.10": [ - "BCD-08", - "BCD-09" + "12(4)": [ + "PRI-01.6" ], - "25.11": [ - "BCD-08.1", - "BCD-09.1" + "12(5)": [ + "PRI-01.6" ], - "25.13": [ - "BCD-08.2", - "BCD-09.2" + "10(1)": [ + "PRI-02" ], - "25.12": [ - "BCD-09.3", - "BCD-11.3", - "BCD-12", - "BCD-12.2", - "BCD-13" + "10(1)(a)": [ + "PRI-02" ], - "21.14": [ - "BCD-09.3", - "BCD-10", - "BCD-10.1", - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-09" + "10(1)(b)": [ + "PRI-02" ], - "25.16": [ - "BCD-10" + "10(1)(c)": [ + "PRI-02" ], - "25.17": [ - "BCD-10.1", - "TPM-05", - "TPM-11" + "10(1)(ç)": [ + "PRI-02" ], - "25.19": [ - "BCD-11.1" + "10(1)(d)": [ + "PRI-02" ], - "25.20": [ - "BCD-11.2" + "11(1)": [ + "PRI-02" ], - "25.22": [ - "BCD-11.3", - "BCD-12" + "11(1)(a)": [ + "PRI-02" ], - "25.18": [ - "BCD-11.4", - "BCD-13" + "11(1)(b)": [ + "PRI-02" ], - "25.21": [ - "BCD-12.1" + "11(1)(c)": [ + "PRI-02" ], - "12.26": [ - "BCD-12.2" + "11(1)(ç)": [ + "PRI-02" ], - "10.6": [ - "CHG-01", - "CHG-02", - "CHG-02.2", - "CHG-03", - "CHG-06", - "IAO-01", - "IAO-02", - "IAO-06", - "IAO-07" + "11(1)(d)": [ + "PRI-02" ], - "14.6": [ - "CHG-01", - "CHG-02.2" + "11(1)(e)": [ + "PRI-02" ], - "14.7": [ - "CHG-01", - "CHG-02", - "CHG-02.1" + "11(1)(f)": [ + "PRI-02" ], - "12.21": [ - "CHG-02.2", - "VPM-05", - "VPM-05.1" + "11(1)(g)": [ + "PRI-02" ], - "12.30": [ - "CHG-02.2", - "CHG-06", - "CPL-03.2", - "VPM-06", - "VPM-07" + "11(1)(ğ)": [ + "PRI-02" ], - "14.8": [ - "CHG-02.2", - "CHG-02.3", - "CHG-03" + "4(1)": [ + "PRI-05.4" ], - "14.9": [ - "CHG-02.2" + "4(2)": [ + "PRI-05.4" ], - "14.10": [ - "CHG-02.2", - "CHG-06" + "4(2)(a)": [ + "PRI-05.4" ], - "10.4": [ - "CHG-04.4", - "HRS-11" + "4(2)(b)": [ + "PRI-05.4" ], - "9.2": [ - "CLD-03", - "NET-06", - "NET-06.1" + "4(2)(c)": [ + "PRI-05.4" ], - "11.3": [ - "CLD-06", - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-05", - "TPM-06" + "4(2)(ç)": [ + "PRI-05.4" ], - "11.6": [ - "CLD-10", - "DCH-01", - "DCH-01.1", - "DCH-13", - "DCH-13.3", - "DCH-19" + "4(2)(d)": [ + "PRI-05.4" ], - "9.10": [ - "CLD-11", - "MON-01", - "MON-01.3", - "MON-01.16", - "NET-03.1" + "5(1)": [ + "PRI-05.4" ], - "11.8": [ - "CLD-11", - "NET-03" + "5(2)": [ + "PRI-05.4" ], - "16.4": [ - "CLD-11", - "NET-03", - "NET-03.1", - "NET-05", - "NET-05.1" + "5(2)(a)": [ + "PRI-05.4" ], - "1.3": [ - "CPL-01", - "CPL-02" + "5(2)(b)": [ + "PRI-05.4" ], - "3.3": [ - "CPL-03.2", - "CFG-01", - "CFG-02", - "CFG-02.1", - "CFG-02.2" + "5(2)(c)": [ + "PRI-05.4" ], - "9.22": [ - "CFG-01", - "CFG-02.2", - "CFG-02.6" + "5(2)(ç)": [ + "PRI-05.4" ], - "9.23": [ - "CFG-01", - "CFG-02.2", - "NET-03" + "5(2)(d)": [ + "PRI-05.4" ], - "4.9": [ - "CFG-02", - "CFG-03", - "IAC-08" + "5(2)(e)": [ + "PRI-05.4" ], - "4.12": [ - "CFG-02", - "CFG-02.5" + "5(2)(f)": [ + "PRI-05.4" ], - "4.15": [ - "CFG-02", - "CFG-03.4", - "IAC-23" + "6(1)": [ + "PRI-05.4" ], - "6.1": [ - "CFG-02" + "6(2)": [ + "PRI-05.4" ], - "9.21": [ - "CFG-02", - "CFG-02.5" + "6(3)": [ + "PRI-05.4" ], - "12.13": [ - "CFG-02", - "CFG-03", - "NET-15.3" + "6(3)(a)": [ + "PRI-05.4" ], - "12.24": [ - "CFG-02", - "DCH-12", - "END-07" + "6(3)(b)": [ + "PRI-05.4" ], - "12.29": [ - "CFG-02", - "IAC-01", - "IAC-08", - "IAC-21", - "TDA-02.1" + "6(3)(c)": [ + "PRI-05.4" ], - "13.5": [ - "CFG-02", - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07" + "6(3)(ç)": [ + "PRI-05.4" ], - "13.6": [ - "CFG-02", - "CRY-03", - "CRY-04", - "NET-12" + "6(3)(d)": [ + "PRI-05.4" ], - "14.2": [ - "CFG-02" + "6(3)(e)": [ + "PRI-05.4" ], - "15.6": [ - "CFG-02", - "DCH-01", - "HRS-05.1", - "HRS-05.3", - "HRS-05.4", - "HRS-05.5", - "SEA-01", - "SEA-02", - "SEA-03" + "6(3)(f)": [ + "PRI-05.4" ], - "14.3": [ - "CFG-02.1", - "CFG-02.2" + "6(3)(g)": [ + "PRI-05.4" ], - "6.2": [ - "CFG-02.2" + "6(4)": [ + "PRI-05.4" ], - "6.4": [ - "CFG-02.2", - "MON-01.7", - "END-06" + "7(1)": [ + "PRI-05.4" ], - "14.4": [ - "CFG-02.2" + "7(2)": [ + "PRI-05.4" ], - "14.5": [ - "CFG-02.3" + "7(3)": [ + "PRI-05.4" ], - "10.2": [ - "CFG-02.4" + "13(1)": [ + "PRI-06" ], - "10.7": [ - "CFG-02.5", - "CFG-02.9" + "13(2)": [ + "PRI-06" ], - "4.8": [ - "CFG-03", - "IAC-01", - "IAC-08" + "13(3)": [ + "PRI-06" ], - "12.9": [ - "CFG-03", - "NET-04.1", - "TDA-02.1" + "8(1)": [ + "PRI-07" ], - "6.7": [ - "CFG-03.3" + "8(2)": [ + "PRI-07" ], - "9.13": [ - "CFG-03.4" + "8(2)(a)": [ + "PRI-07" ], - "6.3": [ - "CFG-05", - "CFG-05.2", - "END-03", - "END-03.1" + "8(2)(b)": [ + "PRI-07" ], - "4.6": [ - "MON-01", - "MON-01.16", - "MON-02", - "MON-02.1", - "MON-03", - "IAC-15" + "8(3)": [ + "PRI-07" ], - "11.11": [ - "MON-01", - "MON-01.1", - "MON-01.2", - "MON-01.16", - "TPM-07" + "16(1)": [ + "PRI-15" ], - "12.31": [ - "MON-01", - "MON-01.2", - "MON-01.8", - "MON-01.16" + "16(2)": [ + "PRI-15" ], - "13.9": [ - "MON-01", - "MON-01.16", - "MDM-01", - "MDM-02", - "MDM-04" + "16(3)": [ + "PRI-15" ], - "7.4": [ - "MON-01.1", - "END-07", - "NET-08" + "16(3)(a)": [ + "PRI-15" ], - "12.18": [ - "MON-01.1", - "END-07", - "NET-08", - "NET-08.2" + "16(3)(b)": [ + "PRI-15" ], - "9.9": [ - "MON-01.3" + "16(3)(c)": [ + "PRI-15" ], - "10.9": [ - "MON-01.3", - "NET-03", - "NET-04" + "16(3)(ç)": [ + "PRI-15" ], - "21.2": [ - "MON-01.4", - "MON-03" + "16(3)(d)": [ + "PRI-15" ], - "21.4": [ - "MON-01.4", - "MON-02", - "MON-03.1", - "MON-08", - "MON-10" + "16(3)(e)": [ + "PRI-15" ], - "7.6": [ - "MON-01.5", - "NET-08" + "16(3)(f)": [ + "PRI-15" ], - "12.19": [ - "MON-01.7", - "END-06" + "16(4)": [ + "PRI-15" ], - "21.3": [ - "MON-01.8", - "MON-02", - "MON-06" + "16(5)": [ + "PRI-15" + ] + }, + "emea-uae-niaf-2023": { + "3.1.1": [ + "AST-02" ], - "21.11": [ - "MON-01.8", - "MON-06" + "3.4": [ + "BCD-01", + "BCD-02" ], - "9.14": [ - "MON-01.9", - "NET-18", - "NET-18.1" + "3.4.1": [ + "BCD-01", + "BCD-04" ], - "21.20": [ - "MON-01.9", - "MON-06", - "MON-16" + "3.4.2": [ + "BCD-01", + "BCD-01.5" ], - "12.17": [ - "MON-02", - "MON-02.1", - "MON-03", - "MON-03.2" + "3.4.3": [ + "BCD-01", + "BCD-02.1" ], - "21.6": [ - "MON-02", - "MON-02.1" + "3.2.1": [ + "CFG-02", + "SEA-01" ], - "21.12": [ - "MON-02", - "MON-02.1" + "3.2.3": [ + "HRS-01", + "HRS-01.1" ], - "21.13": [ - "MON-02.1" + "3.3": [ + "IRO-01" ], - "21.19": [ - "MON-02.1", - "MON-06" + "3.3.2": [ + "IRO-01", + "IRO-02" ], - "21.5": [ - "MON-03", - "MON-03.4" + "3.3.1": [ + "IRO-02", + "IRO-09" ], - "21.7": [ - "MON-03" + "3.3.3": [ + "IRO-10", + "IRO-10.2" ], - "21.10": [ - "MON-03", - "MON-03.3", - "MON-12", - "MON-15", - "MON-16", - "MON-16.1", - "MON-16.2", - "MON-16.3" + "3.2": [ + "IAO-05" ], - "21.21": [ - "MON-03.3", - "MON-03.4" + "3.2.2": [ + "PES-01", + "PES-03" ], - "21.8": [ - "MON-04" + "3.1.2": [ + "RSK-08" ], - "21.9": [ - "MON-05", - "MON-05.1" + "3.1.3": [ + "VPM-06" + ] + }, + "emea-gbr-caf-4-0": { + "A1.a": [ + "GOV-01.1" ], - "21.17": [ - "MON-08.1", - "MON-10" + "A1.c": [ + "GOV-01.1", + "GOV-04" ], - "21.18": [ - "MON-12" + "A1": [ + "GOV-02" ], - "4.7": [ - "MON-16" + "B1": [ + "GOV-02" ], - "8.1": [ - "CRY-01" + "B1.b": [ + "GOV-02" ], - "8.8": [ - "CRY-01" + "B1.a": [ + "GOV-03" ], - "15.7": [ - "CRY-01", - "CRY-01.1", - "CRY-05", - "CRY-05.1", - "DCH-01", - "DCH-07", - "DCH-07.1" + "A1.b": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "4.37": [ - "CRY-02", - "END-09", - "IAC-01", - "IAC-10.5", - "IAC-12" + "B4.a": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "SEA-01" ], - "12.10": [ - "CRY-02", - "CRY-03", - "CRY-04" + "A2.c": [ + "GOV-19", + "CPL-01.4" ], - "4.22": [ - "CRY-03", - "CRY-04", - "CRY-07" + "A3": [ + "AST-01", + "AST-01.1" ], - "8.4": [ - "CRY-03", - "NET-12" + "A3.a (point 2)": [ + "AST-01.1" ], - "8.5": [ - "CRY-03" + "A3.a (point 4)": [ + "AST-01.2", + "AST-03" ], - "8.6": [ - "CRY-03", - "NET-12" + "A3.a (point 1)": [ + "AST-02" ], - "9.8": [ - "CRY-03", - "CRY-04", - "NET-14.2" + "B3.a": [ + "AST-04", + "DCH-02", + "DCH-06.2", + "DCH-14.3", + "DCH-19" ], - "9.20": [ - "CRY-03", - "CRY-04", - "NET-12" + "B5.a": [ + "BCD-01" ], - "8.7": [ - "CRY-05", - "MDM-03" + "A3.a (point 3)": [ + "BCD-02" ], - "8.2": [ - "CRY-08", - "CRY-09" + "B5.c": [ + "BCD-11" ], - "8.9": [ - "CRY-08", - "CRY-09", - "CRY-09.4" + "B4": [ + "CFG-01", + "CFG-02" ], - "8.10": [ - "CRY-09" + "B4.c": [ + "CFG-01" ], - "8.3": [ - "CRY-09.3" + "B4.b": [ + "CFG-02" ], - "8.11": [ - "CRY-09.3", - "CRY-09.4" + "C1": [ + "MON-01" ], - "5.1": [ - "DCH-01", - "DCH-17", - "HRS-05", - "HRS-05.1" + "C1.a": [ + "MON-01.4", + "MON-01.8", + "MON-03" ], - "5.5": [ - "DCH-01" + "C1.c": [ + "MON-01.4" ], - "15.2": [ - "DCH-02", - "DCH-04" + "C1.b": [ + "MON-08", + "MON-10" ], - "10.5": [ - "DCH-03.1", - "DCH-14", - "DCH-17", - "DCH-25", - "PRI-07", - "SEA-05" + "C1.f": [ + "MON-16", + "IRO-03", + "THR-09" ], - "15.3": [ - "DCH-06" + "C1.d": [ + "MON-17" ], - "15.8": [ - "DCH-09.1", - "DCH-09.2" + "B3.b": [ + "CRY-03" ], - "5.4": [ - "DCH-14", - "DCH-17", - "HRS-05.3" + "B3.c": [ + "CRY-05" ], - "12.2": [ - "EMB-01", - "OPS-01.1" + "B3": [ + "DCH-01" ], - "12.3": [ - "EMB-01", - "OPS-01.1" + "B3.e": [ + "DCH-09" ], - "7.1": [ + "B3.d": [ "END-01", - "END-02", - "END-04" + "MDM-01" ], - "7.3": [ - "END-01", - "END-02", - "END-04" + "C1.e": [ + "HRS-03.2" ], - "15.5": [ - "END-01", - "END-02", - "END-04" + "B2": [ + "IAC-01" ], - "12.20": [ - "END-04", - "END-04.3", - "END-04.6" + "B2.d": [ + "IAC-01" ], - "7.9": [ - "END-04.1" + "B2.a": [ + "IAC-02", + "IAC-03" ], - "7.7": [ - "END-04.3" + "B2.b": [ + "IAC-04" ], - "7.8": [ - "END-04.4" + "B2.c": [ + "IAC-16" ], - "7.5": [ - "END-04.7", - "END-07" + "D1": [ + "IRO-01" ], - "12.25": [ - "END-04.7" + "D1.b": [ + "IRO-02" ], - "7.2": [ - "END-06.2", - "IRO-02", + "D1.a": [ "IRO-04" ], - "5.6": [ - "END-14" - ], - "19.1": [ - "HRS-01", - "HRS-02" + "D1.c": [ + "IRO-06" ], - "4.13": [ - "HRS-03", - "HRS-05.2" + "D2": [ + "IRO-13" ], - "18.10": [ - "HRS-03", - "PES-01", - "PES-05", - "TPM-06" + "D2.a": [ + "IRO-13" ], - "19.2": [ - "HRS-04", - "HRS-04.1" + "D2.b": [ + "IRO-13" ], - "19.3": [ - "HRS-05", - "HRS-05.1" + "A2": [ + "RSK-01" ], - "19.4": [ - "HRS-05", - "HRS-06.1" + "A2.a": [ + "RSK-01" ], - "19.6": [ - "HRS-05.1", - "HRS-05.2", - "HRS-05.3", - "HRS-05.4", - "HRS-05.5", - "HRS-06" + "A4": [ + "RSK-09", + "TPM-01" ], - "19.7": [ - "HRS-05.2" + "A4.a": [ + "RSK-09" ], - "9.5": [ - "HRS-05.3", - "NET-03.2" + "B5.b": [ + "SEA-01", + "SEA-01.3" ], - "13.2": [ - "HRS-05.5", - "MDM-02" + "B5": [ + "SEA-01.3" ], - "13.3": [ - "HRS-05.5", - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07" + "A3.a (point 5)": [ + "SEA-07.1" ], - "13.7": [ - "HRS-05.5", - "MDM-02" + "B6.a": [ + "SAT-01" ], - "13.10": [ - "HRS-05.5", - "MDM-01" + "B6": [ + "SAT-02" ], - "19.8": [ - "HRS-07" + "B6.b": [ + "SAT-03" ], - "19.9": [ - "HRS-08", - "HRS-09" + "A4.b": [ + "TDA-06" ], - "19.10": [ - "HRS-09", - "HRS-09.1", - "HRS-09.2", - "HRS-09.3" + "A2.b": [ + "THR-01", + "THR-09" ], - "19.5": [ - "HRS-10", - "TPM-05", - "TPM-06" + "C2": [ + "THR-07" ], - "4.11": [ - "HRS-11", - "IAC-08" + "C2.a (point 1)": [ + "THR-07" ], - "4.34": [ - "IAC-01", - "IAC-02", - "IAC-02.1" + "C2.a (point 2)": [ + "THR-07" ], - "12.15": [ - "IAC-01", - "IAC-09", - "IAC-09.1", - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "C2.a (point 3)": [ + "THR-07" ], - "12.28": [ - "IAC-01", - "IAC-08" + "C2.a (point 4)": [ + "THR-07" ], - "4.2": [ - "IAC-02", - "IAC-03", - "IAC-05", - "IAC-08", - "IAC-16" + "C2.a (point 5)": [ + "THR-07" ], - "4.31": [ - "IAC-02", - "IAC-02.2" + "C2.a (point 6)": [ + "THR-07" ], - "4.21": [ - "IAC-03", - "IAC-06" + "C2.a (point 7)": [ + "THR-07" ], - "4.33": [ - "IAC-04" + "C2.a (point 8)": [ + "THR-07" ], - "4.32": [ - "IAC-06" + "B4.d": [ + "VPM-01" + ] + }, + "emea-gbr-cap-1850-2020": { + "A1": [ + "GOV-01", + "GOV-02" ], - "4.29": [ - "IAC-06.1" + "B1": [ + "GOV-01", + "IAO-03", + "IAO-03.2" ], - "4.30": [ - "IAC-06.3" + "B4": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "IAO-03" ], - "4.10": [ - "IAC-08", - "IAC-21" + "A4": [ + "AST-01.1", + "BCD-02", + "TPM-02", + "TPM-03", + "TPM-04.1" ], - "4.20": [ - "IAC-08", - "MNT-05.3", - "MNT-05.4", - "NET-14.4" + "C1": [ + "MON-01" ], - "4.35": [ - "IAC-10", - "IAC-10.1" + "B3": [ + "CRY-01", + "CRY-03", + "CRY-05" ], - "12.16": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2" + "C2": [ + "END-04" ], - "4.36": [ - "IAC-11" + "B2": [ + "IAC-01", + "IAC-01.2", + "IAC-15.1" ], - "4.3": [ - "IAC-15", - "IAC-17" + "D1": [ + "IRO-01", + "IRO-02" ], - "4.4": [ - "IAC-15", - "IAC-15.2" + "D2": [ + "IRO-04.3", + "IRO-13" ], - "4.5": [ - "IAC-15.3" + "A2": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-03", + "IAO-03.2", + "IAO-06", + "IAO-07", + "RSK-01", + "RSK-03", + "RSK-04" ], - "4.14": [ - "IAC-22" + "A3": [ + "IAO-03" ], - "4.16": [ - "IAC-24", - "NET-07" + "B5": [ + "SEA-01.2", + "SEA-01.3" ], - "24.2": [ - "IRO-02", - "IRO-04" + "B6": [ + "SAT-02", + "SAT-03" + ] + }, + "emea-gbr-cyber-essentials-requirements-3-3": { + "1": [ + "END-05", + "NET-03" ], - "24.4": [ - "IRO-02.1" + "2": [ + "AST-01" ], - "24.3": [ - "IRO-04" + "3": [ + "VPM-05" ], - "24.8": [ - "IRO-04", - "IRO-10" + "4": [ + "IAC-01", + "IAC-01.2" ], - "24.9": [ - "IRO-04", - "IRO-07" + "5": [ + "END-04" ], - "24.10": [ - "IRO-05", - "IRO-06" + "5-BP2-2": [ + "AST-01.4", + "CFG-03.3" ], - "24.11": [ - "IRO-05", - "IRO-06" + "3-BP1": [ + "AST-02.7" ], - "24.12": [ - "IRO-06" + "2-BP3": [ + "CFG-02", + "CFG-03" ], - "24.7": [ - "IRO-07" + "2-BP4": [ + "CFG-02" ], - "24.5": [ - "IRO-09", - "IRO-09.1" + "5-BP2": [ + "CFG-03.3" ], - "24.6": [ - "IRO-10" + "5-BP2-1": [ + "CFG-03.3" ], - "17.11": [ - "IRO-10.4", - "RSK-09", - "RSK-09.1", - "TPM-03" + "5-BP1": [ + "END-04" ], - "16.5": [ - "IAO-01", - "IAO-02", - "IAO-03.2", - "IAO-06", - "IAO-07", - "TPM-03", - "TPM-04.1" + "5-BP1-1": [ + "END-04.1" ], - "17.16": [ - "IAO-01", - "IAO-02", - "IAO-02.1", - "IAO-02.2", - "IAO-02.3", - "VPM-07.1" + "5-BP1-2": [ + "END-04.7" ], - "17.18": [ - "IAO-01", - "IAO-02" + "5-BP1-3": [ + "END-04.7" ], - "17.2": [ - "IAO-02", - "IAO-02.1", - "IAO-02.2", - "IAO-02.3" + "2-BP5": [ + "IAC-01.2" ], - "4.18": [ - "MNT-05", - "MNT-05.4", - "NET-14.1" + "4-BP2": [ + "IAC-01.2" ], - "12.7": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2", - "MNT-05.3", - "MNT-05.4", - "MNT-05.5", - "MNT-06", - "MNT-06.1" + "4-BP4": [ + "IAC-06" ], - "4.28": [ - "MDM-01" + "4-BP6": [ + "IAC-07", + "IAC-16" ], - "13.8": [ - "MDM-01", - "MDM-05" + "2-BP2": [ + "IAC-10.8" ], - "4.27": [ - "MDM-02" + "2-BP1": [ + "IAC-15", + "IAC-17", + "IAC-21" ], - "4.26": [ - "MDM-03" + "4-BP1": [ + "IAC-15" ], - "13.4": [ - "MDM-03" + "4-BP3": [ + "IAC-15", + "IAC-15.3" ], - "9.17": [ - "NET-02", - "SEA-07.2" + "2-BP6": [ + "IAC-15.1" ], - "9.3": [ - "NET-02.1", - "NET-03" + "4-BP5": [ + "IAC-16.4" ], - "9.18": [ - "NET-02.2", - "NET-03", - "NET-06" + "5-BP1-4": [ + "NET-18" ], - "9.11": [ - "NET-03.1", - "NET-05.1" + "3-BP2": [ + "TDA-17" ], - "9.19": [ - "NET-03.3", - "NET-06" + "3-BP4": [ + "VPM-05" ], - "9.12": [ - "NET-04", - "NET-04.1" + "3-BP4-1": [ + "VPM-05" ], - "9.16": [ - "NET-04", - "NET-04.3", - "NET-04.4" + "3-BP4-2": [ + "VPM-05" ], - "12.11": [ - "NET-04", - "NET-06" + "3-BP4-3": [ + "VPM-05" ], - "9.24": [ - "NET-04.6" + "3-BP3": [ + "VPM-05.4" + ] + }, + "emea-gbr-def-stan-05-138-2024": { + "1100": [ + "GOV-02", + "OPS-01.1" ], - "12.8": [ - "NET-05.1" + "1101": [ + "GOV-01.1", + "GOV-02", + "GOV-04.1" ], - "10.8": [ - "NET-06", - "SEA-05" + "1102": [ + "GOV-04", + "HRS-03" ], - "12.4": [ - "NET-06", - "NET-06.1" + "1103": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "12.5": [ - "NET-06", - "NET-06.1" + "1200": [ + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-06" ], - "9.4": [ - "NET-07" + "1201": [ + "RSK-01" ], - "4.24": [ - "NET-08.2", - "NET-15", - "NET-15.2" + "1202": [ + "GOV-01.1", + "RSK-04" ], - "17.25": [ - "NET-09", - "TDA-06" + "1203": [ + "AST-04" ], - "9.6": [ - "NET-10" + "1204": [ + "RSK-01", + "RSK-04", + "THR-01", + "THR-03", + "THR-03.1" ], - "9.7": [ - "NET-10.1", - "NET-10.2" + "1205": [ + "IAO-01", + "IAO-02", + "IAO-06" ], - "4.17": [ - "NET-14", - "NET-14.4" + "1206": [ + "CPL-02", + "CPL-02.2", + "CPL-03.2" ], - "4.19": [ - "NET-14.3" + "1300": [ + "AST-01", + "HRS-01" ], - "12.12": [ - "NET-15" + "1301": [ + "AST-01", + "AST-02", + "AST-02.9" ], - "12.14": [ - "NET-15", - "NET-15.1" + "1400": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-03" ], - "4.23": [ - "NET-15.4" + "1401": [ + "TPM-05", + "TPM-05.2" ], - "9.15": [ + "1500": [ "PES-01", + "PES-02", "PES-03", - "PES-04", - "PES-12.1" + "PES-03.3", + "PES-05", + "PES-05.1" ], - "12.27": [ - "PES-01", - "PES-02", + "1501": [ + "PES-19" + ], + "1502": [ "PES-02.1", - "PES-03", - "PES-03.1" + "PES-03.4" ], - "18.2": [ - "PES-01", + "1503": [ + "IAC-01.1", + "PES-06.1", + "PES-06.2", + "PES-06.6" + ], + "2100": [ + "GOV-02", + "GOV-03", "OPS-01.1" ], - "18.3": [ - "PES-02", - "PES-06" + "2101": [ + "GOV-02", + "GOV-03", + "OPS-01.1" ], - "18.4": [ - "PES-02.1", - "PES-03" + "2200": [ + "IAC-01", + "IAC-01.2", + "IAC-08" ], - "18.6": [ - "PES-03.1", - "PES-03.2", - "PES-04", - "PES-04.1" + "2201": [ + "IAC-06" ], - "18.8": [ - "PES-03.1", - "PES-05" + "2202": [ + "AST-01", + "AST-02", + "AST-02.4" ], - "18.11": [ - "PES-03.2", - "PES-05", - "PES-05.1" + "2203": [ + "MON-01", + "MON-01.15" ], - "18.5": [ - "PES-03.3" + "2204": [ + "CFG-02", + "CFG-03" ], - "18.9": [ - "PES-05.1" + "2205": [ + "IAC-21" ], - "18.12": [ - "PES-06" + "2206": [ + "IAC-08", + "IAC-21" ], - "18.14": [ - "PES-07.3" + "2207": [ + "HRS-11" ], - "18.16": [ - "PES-07.4" + "2208": [ + "IAC-01" ], - "18.19": [ - "PES-07.5" + "2209": [ + "IAC-01.2", + "IAC-15.1" ], - "18.17": [ - "PES-08", - "PES-08.1", - "PES-08.2" + "2210": [ + "IAC-01", + "IAC-01.2" ], - "18.18": [ - "PES-09", - "PES-09.1" + "2211": [ + "IAC-10.8" ], - "18.20": [ - "PES-10" + "2212": [ + "IAC-10.11" ], - "18.21": [ - "PES-11" + "2213": [ + "IAC-10.4" ], - "18.7": [ - "PES-12", - "PES-12.2" + "2214": [ + "IAC-22" ], - "18.13": [ - "PES-12", - "PES-12.1" + "2215": [ + "IAC-02.2" ], - "18.22": [ - "PES-12" + "2216": [ + "MON-03.3", + "IAC-21.5" ], - "11.1": [ - "PRI-07.1", - "TPM-05", - "TPM-06" + "2217": [ + "IAC-01.3" ], - "17.5": [ - "PRM-01", - "PRM-02", - "PRM-03", - "PRM-04", - "PRM-05", - "PRM-06", - "PRM-07" + "2218": [ + "IAC-02", + "IAC-15.1" ], - "17.8": [ - "PRM-02", - "PRM-04", - "PRM-07" + "2300": [ + "DCH-01" ], - "17.9": [ - "PRM-02", - "PRM-04", - "TDA-01", - "TDA-01.1", - "TDA-06" + "2301": [ + "AST-04", + "DCH-01.4", + "DCH-02", + "DCH-03", + "IAO-03" ], - "17.6": [ - "PRM-05", - "PRM-06", - "TDA-04", - "TDA-04.1", - "TDA-05", - "TDA-06" + "2302": [ + "CRY-03", + "DCH-07", + "DCH-07.2" ], - "17.4": [ - "PRM-07", - "TDA-09", - "TDA-09.1" + "2303": [ + "NET-07" ], - "1.2": [ - "RSK-01", - "RSK-03", - "RSK-04" + "2304": [ + "CRY-01", + "IAC-01.2", + "NET-15.1" ], - "2.1": [ - "RSK-01", - "SEA-01", - "SEA-02", - "SEA-03" + "2305": [ + "CFG-03.4", + "IAC-06", + "NET-12", + "NET-14", + "NET-14.2", + "NET-14.5" ], - "2.2": [ - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-07" + "2306": [ + "CRY-03", + "NET-14.2" ], - "16.6": [ - "RSK-08", - "RSK-09.1", - "RSK-10", - "TPM-02" + "2307": [ + "NET-14.3" ], - "16.3": [ - "RSK-09", - "TPM-03", - "TPM-04.1", - "TPM-04.2", - "TPM-04.3", - "TPM-04.4" + "2308": [ + "DCH-01", + "DCH-01.2", + "DCH-06" ], - "17.3": [ - "RSK-09", - "RSK-09.1", - "RSK-10", - "TDA-09", - "TDA-09.1", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TPM-01", - "TPM-03", - "TPM-04.1" + "2309": [ + "MDM-01", + "MDM-03" ], - "17.7": [ - "SEA-01", - "SEA-02", - "SEA-03" + "2310": [ + "AST-02", + "CFG-02", + "CRY-05", + "DCH-10", + "DCH-12" ], - "23.5": [ - "SEA-11", - "SEA-12" + "2311": [ + "HRS-14", + "HRS-14.1" ], - "22.2": [ - "OPS-01.1", - "VPM-01" + "2312": [ + "CFG-02.5", + "PES-11" ], - "20.2": [ - "SAT-02", - "SAT-03" + "2313": [ + "DCH-09" ], - "20.4": [ - "SAT-02.2" + "2314": [ + "CPL-01" ], - "20.3": [ - "SAT-03.3" + "2315": [ + "NET-10", + "NET-10.3", + "NET-20.4" ], - "17.10": [ - "TDA-04", - "TDA-04.1" + "2316": [ + "NET-03.4", + "NET-04" ], - "11.9": [ - "TDA-06", - "TDA-09", - "TDA-09.5" + "2317": [ + "CRY-01", + "CRY-05", + "END-01" ], - "17.20": [ - "TDA-06", - "TDA-14.1" + "2318": [ + "CRY-01" ], - "17.12": [ - "TDA-09", - "TDA-09.1" + "2319": [ + "CRY-09" ], - "17.15": [ - "TDA-09", - "TDA-09.5" + "2320": [ + "NET-17" ], - "17.14": [ - "TDA-09.2" + "2321": [ + "DCH-15", + "HRS-03", + "SAT-03", + "WEB-14" ], - "17.19": [ - "TDA-09.3" + "2322": [ + "AST-16", + "HRS-05.5", + "MDM-01" ], - "17.24": [ - "TDA-09.4" + "2323": [ + "AST-09", + "DCH-09", + "DCH-09.1", + "TPM-05" ], - "17.17": [ - "TDA-09.5", - "VPM-07", - "VPM-07.1" + "2400": [ + "CFG-02", + "SEA-01" ], - "10.3": [ - "TDA-10" + "2401": [ + "CFG-02" ], - "17.13": [ - "TDA-15" + "2402": [ + "VPM-01", + "VPM-02", + "VPM-05", + "VPM-06" ], - "12.23": [ - "TDA-17" + "2403": [ + "VPM-07" ], - "17.22": [ - "TDA-18" + "2404": [ + "CHG-01" ], - "17.23": [ - "TDA-19" + "2405": [ + "VPM-01", + "VPM-05", + "VPM-05.6", + "VPM-05.7" ], - "11.10": [ - "TPM-01", - "TPM-05" + "2406": [ + "PRI-02", + "SEA-18" ], - "16.1": [ - "TPM-01", - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-04" + "2407": [ + "PRI-02", + "SEA-18" ], - "16.2": [ - "TPM-03.2", - "TPM-05" + "2408": [ + "IAC-24" ], - "22.4": [ - "TPM-04", - "TPM-05", - "VPM-07", - "VPM-07.1" + "2409": [ + "CFG-03.3" ], - "11.5": [ - "TPM-07", - "TPM-08" + "2410": [ + "AST-01.4" ], - "11.4": [ - "TPM-08" + "2411": [ + "END-01", + "END-02", + "END-04", + "IRO-15", + "NET-07", + "NET-08", + "NET-18" ], - "23.1": [ - "THR-01" + "2412": [ + "AST-21" ], - "23.4": [ - "THR-01" + "2413": [ + "END-10" ], - "23.3": [ - "THR-02" + "2414": [ + "NET-09" ], - "23.2": [ - "THR-03" + "2415": [ + "CFG-02.2" ], - "22.8": [ - "VPM-02", - "VPM-03" + "2416": [ + "SEA-05" ], - "22.11": [ - "VPM-02", - "VPM-04", - "VPM-05.1", - "VPM-05.2" + "2417": [ + "NET-14.4" ], - "22.13": [ - "VPM-02" + "2418": [ + "CFG-02", + "CFG-02.1", + "CFG-02.9" ], - "22.6": [ - "VPM-04", - "VPM-06", - "VPM-06.2" + "2419": [ + "IAC-11" ], - "12.22": [ - "VPM-04.1", - "VPM-05.3" + "2420": [ + "IAC-11" ], - "22.12": [ - "VPM-05.1", - "VPM-05.2" + "2421": [ + "MON-07.1", + "SEA-20" ], - "3.4": [ - "VPM-06", - "VPM-07" + "2422": [ + "CHG-04", + "IAC-08", + "PES-02.1" ], - "9.25": [ - "VPM-06" + "2423": [ + "AST-02.9" ], - "22.3": [ - "VPM-06", - "VPM-06.6", - "VPM-06.7" + "2424": [ + "IAC-15", + "IAC-16", + "IAC-16.1" ], - "22.7": [ - "VPM-06.1" + "2425": [ + "END-06", + "END-06.1" ], - "22.9": [ - "VPM-06.3" + "2426": [ + "END-04", + "END-04.1", + "END-04.7" ], - "22.10": [ - "VPM-06.4", - "VPM-06.5" + "2427": [ + "MON-01", + "NET-03" ], - "22.5": [ - "VPM-07", - "VPM-07.1" - ] - }, - "emea-isr-ppl-5741-1981": { - "8": [ - "PRI-02.1", - "PRI-05", - "PRI-05.1", - "PRI-05.4", - "PRI-15" + "2428": [ + "NET-04" ], - "9": [ - "PRI-15" + "2430": [ + "CFG-03", + "CFG-03.1" ], - "13": [ - "PRI-06" + "2500": [ + "SEA-01.2" ], - "14": [ - "DCH-22.1", - "PRI-06.1" + "2501": [ + "BCD-01", + "SEA-01.2" ], - "16": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "PRI-01.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "2502": [ + "BCD-01" + ], + "2503": [ + "BCD-04" + ], + "2504": [ + "BCD-11", + "BCD-11.1" + ], + "2505": [ + "BCD-11", + "BCD-11.1", + "BCD-11.2", + "BCD-11.5" ], - "17": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "PRI-01.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "2506": [ + "BCD-11.4", + "BCD-11.6", + "DCH-07" ], - "Inferred": [ - "PRI-01" + "2507": [ + "CFG-03", + "CFG-03.1", + "NET-04.1" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-ita-pdpc-2003": { - "7": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "2508": [ + "NET-06" ], - "9": [ - "PRI-06.4" + "2509": [ + "END-08", + "NET-20.7" ], - "10": [ - "PRI-06.2" + "2510": [ + "MNT-04.2" ], - "11": [ - "PRI-02", - "PRI-04", - "PRI-04.1", - "PRI-05" + "2511": [ + "MNT-02", + "MNT-03" ], - "13": [ - "PRI-02", - "PRI-02.1", - "PRI-05.1", - "PRI-05.4" + "2512": [ + "IAC-06", + "MNT-05" ], - "20": [ - "PRI-05.1", - "PRI-05.4" + "2513": [ + "MNT-06.1" ], - "23": [ - "PRI-03" + "2600": [ + "HRS-03.1", + "SAT-02" ], - "24": [ - "PRI-03" + "2601": [ + "RSK-12", + "SAT-03.6" ], - "26": [ - "CPL-01", - "PRI-15" + "2602": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.2", + "SAT-03.3", + "SAT-03.6" ], - "30": [ - "PRI-01.1" + "2603": [ + "HRS-03.1", + "SAT-02", + "SAT-03.6" ], - "31": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "2604": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "HRS-05.3" ], - "33": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "2605": [ + "SAT-02.1", + "SAT-03.1" ], - "34": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "2700": [ + "HRS-04" ], - "35": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "2701": [ + "HRS-04" ], - "37": [ - "PRI-02", - "PRI-15" + "2702": [ + "HRS-01", + "HRS-01.1", + "IAC-07" ], - "42": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "2703": [ + "HRS-15" ], - "Inferred": [ - "PRI-01" + "2704": [ + "PES-07.3", + "PES-08.2", + "PES-09" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-ken-pda-2019": { - "2": [ - "SEA-02.1" + "3100": [ + "MON-01" ], - "20": [ - "PRI-15" + "3101": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-17.1", + "HRS-03" ], - "36": [ - "PRI-04.1", - "PRI-05.1" + "3102": [ + "MON-01", + "MON-01.2", + "MON-01.8", + "MON-17.1", + "HRS-03" ], - "44": [ - "PRI-05.4" + "3103": [ + "MON-08", + "MON-10" ], - "50": [ - "DCH-25", - "DCH-26" + "3104": [ + "MON-03", + "IRO-08" ], - "54": [ - "CPL-01" + "3105": [ + "IRO-01", + "IRO-02" ], - "25(h)": [ - "CLD-09", - "DCH-14.2", - "DCH-19", - "DCH-25", - "PRI-07", - "PRI-07.1" + "3106": [ + "MON-01", + "SAT-03.6" ], - "4(a)": [ - "CPL-01" + "3107": [ + "MON-03.2", + "MON-10" ], - "4(b)(i)": [ - "CPL-01" + "3108": [ + "MON-06" ], - "4(b)(ii)": [ - "CPL-01" + "3109": [ + "MON-17" ], - "51(1)": [ - "CPL-01" + "3110": [ + "THR-03", + "THR-03.1" ], - "51(2)(a)": [ - "CPL-01" + "3200": [ + "MON-16" ], - "51(2)(b)": [ - "CPL-01" + "3201": [ + "IRO-03" ], - "51(2)(c)": [ - "CPL-01" + "3202": [ + "MON-16" ], - "52(1)(a)": [ - "CPL-01" + "3203": [ + "MON-16" ], - "52(1)(b)": [ - "CPL-01" + "3204": [ + "AST-02.2" ], - "52(1)(c)": [ - "CPL-01" + "4100": [ + "BCD-01" ], - "52(2)": [ - "CPL-01" + "4101": [ + "IRO-04" ], - "52(3)": [ - "CPL-01" + "4102": [ + "IRO-04" ], - "55(1)(a)": [ - "CPL-01" + "4103": [ + "IRO-06" ], - "55(1)(b)": [ - "CPL-01" + "4104": [ + "IRO-01", + "IRO-02" ], - "55(2)": [ - "CPL-01" + "4105": [ + "IRO-06" ], - "39(2)": [ - "DCH-23", - "PRI-05" + "4106": [ + "MON-16.3" ], - "48(a)": [ - "DCH-25" + "4200": [ + "IRO-13" ], - "48(b)": [ - "DCH-25" + "4201": [ + "RSK-04.1", + "RSK-08" ], - "48(c)(i)": [ - "DCH-25" + "4202": [ + "BCD-12", + "BCD-12.2" ], - "48(c)(ii)": [ - "DCH-25" + "0001": [ + "CPL-01" ], - "48(c)(iii)": [ - "DCH-25" + "0002": [ + "CPL-01" + ] + }, + "emea-gbr-def-stan-05-138-l0-2024": { + "2314": [ + "CPL-01" ], - "48(c)(iv)": [ - "DCH-25" + "2500": [ + "SEA-01.2" ], - "48(c)(v)": [ - "DCH-25" + "0001": [ + "CPL-01" + ] + }, + "emea-gbr-def-stan-05-138-l1-2024": { + "1100": [ + "GOV-02", + "OPS-01.1" ], - "48(c)(vi)": [ - "DCH-25" + "1102": [ + "GOV-04", + "HRS-03" ], - "49(1)": [ - "DCH-25" + "1200": [ + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-06" ], - "49(2)": [ - "DCH-25" + "1202": [ + "GOV-01.1", + "RSK-04" ], - "49(3)": [ - "DCH-25" + "1203": [ + "AST-04" ], - "43(1)(b)": [ - "IRO-04.1" + "1300": [ + "AST-01", + "HRS-01" ], - "43(2)": [ - "IRO-04.1" + "1400": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-03" ], - "43(3)": [ - "IRO-04.1" + "1401": [ + "TPM-05", + "TPM-05.2" ], - "43(4)": [ - "IRO-04.1" + "1500": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.3", + "PES-05", + "PES-05.1" ], - "43(5)": [ - "IRO-04.1" + "1501": [ + "PES-19" ], - "43(5)(a)": [ - "IRO-04.1" + "1502": [ + "PES-02.1", + "PES-03.4" ], - "43(5)(b)": [ - "IRO-04.1" + "1503": [ + "IAC-01.1", + "PES-06.1", + "PES-06.2", + "PES-06.6" ], - "43(5)(c)": [ - "IRO-04.1" + "2100": [ + "GOV-02", + "GOV-03", + "OPS-01.1" ], - "43(5)(d)": [ - "IRO-04.1" + "2200": [ + "IAC-01", + "IAC-01.2", + "IAC-08" ], - "43(5)(e)": [ - "IRO-04.1" + "2204": [ + "CFG-02", + "CFG-03" ], - "43(6)": [ - "IRO-04.1" + "2205": [ + "IAC-21" ], - "43(7)": [ - "IRO-04.1" + "2206": [ + "IAC-08", + "IAC-21" ], - "43(8)(a)": [ - "IRO-04.1" + "2207": [ + "HRS-11" ], - "43(8)(b)": [ - "IRO-04.1" + "2210": [ + "IAC-01", + "IAC-01.2" ], - "43(8)(c)": [ - "IRO-04.1" + "2211": [ + "IAC-10.8" ], - "30(1)(a)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2213": [ + "IAC-10.4" ], - "30(1)(b)(i)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2214": [ + "IAC-22" ], - "30(1)(b)(ii)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2215": [ + "IAC-02.2" ], - "30(1)(b)(iii)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2217": [ + "IAC-01.3" ], - "30(1)(b)(iv)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2218": [ + "IAC-02", + "IAC-15.1" ], - "30(1)(b)(v)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2300": [ + "DCH-01" ], - "30(1)(b)(vi)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2303": [ + "NET-07" ], - "30(1)(b)(vii)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2304": [ + "CRY-01", + "IAC-01.2", + "NET-15.1" ], - "30(1)(b)(viii)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2305": [ + "CFG-03.4", + "IAC-06", + "NET-12", + "NET-14", + "NET-14.2", + "NET-14.5" ], - "30(2)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2306": [ + "CRY-03", + "NET-14.2" ], - "30(3)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "2307": [ + "NET-14.3" ], - "24(1)": [ - "PRI-01.4" + "2310": [ + "AST-02", + "CFG-02", + "CRY-05", + "DCH-10", + "DCH-12" ], - "24(1)(a)": [ - "PRI-01.4" + "2311": [ + "HRS-14", + "HRS-14.1" ], - "24(1)(b)": [ - "PRI-01.4" + "2312": [ + "CFG-02.5", + "PES-11" ], - "24(1)(c)": [ - "PRI-01.4" + "2314": [ + "CPL-01" ], - "24(2)": [ - "PRI-01.4" + "2315": [ + "NET-10", + "NET-10.3", + "NET-20.4" ], - "24(3)": [ - "PRI-01.4" + "2316": [ + "NET-03.4", + "NET-04" ], - "24(4)": [ - "PRI-01.4" + "2317": [ + "CRY-01", + "CRY-05", + "END-01" ], - "24(5)": [ - "PRI-01.4" + "2318": [ + "CRY-01" ], - "24(6)": [ - "PRI-01.4" + "2319": [ + "CRY-09" ], - "24(7)(a)": [ - "PRI-01.4" + "2321": [ + "DCH-15", + "HRS-03", + "SAT-03", + "WEB-14" ], - "24(7)(b)": [ - "PRI-01.4" + "2322": [ + "AST-16", + "HRS-05.5", + "MDM-01" ], - "24(7)(c)": [ - "PRI-01.4" + "2323": [ + "AST-09", + "DCH-09", + "DCH-09.1", + "TPM-05" ], - "24(7)(d)": [ - "PRI-01.4" + "2400": [ + "CFG-02", + "SEA-01" ], - "24(7)(e)": [ - "PRI-01.4" + "2401": [ + "CFG-02" ], - "29(f)": [ - "PRI-01.6", - "PRI-02" + "2402": [ + "VPM-01", + "VPM-02", + "VPM-05", + "VPM-06" ], - "41(1)": [ - "PRI-01.6" + "2403": [ + "VPM-07" ], - "41(1)(a)": [ - "PRI-01.6" + "2404": [ + "CHG-01" ], - "41(1)(b)": [ - "PRI-01.6" + "2405": [ + "VPM-01", + "VPM-05", + "VPM-05.6", + "VPM-05.7" ], - "41(2)": [ - "PRI-01.6" + "2407": [ + "PRI-02", + "SEA-18" ], - "41(3)(a)": [ - "PRI-01.6" + "2408": [ + "IAC-24" ], - "41(3)(b)": [ - "PRI-01.6" + "2409": [ + "CFG-03.3" ], - "41(3)(c)": [ - "PRI-01.6" + "2410": [ + "AST-01.4" ], - "41(3)(d)": [ - "PRI-01.6" + "2411": [ + "END-01", + "END-02", + "END-04", + "IRO-15", + "NET-07", + "NET-08", + "NET-18" ], - "41(3)(e)": [ - "PRI-01.6" + "2412": [ + "AST-21" ], - "41(4)(a)": [ - "PRI-01.6" + "2413": [ + "END-10" ], - "41(4)(b)": [ - "PRI-01.6" + "2414": [ + "NET-09" ], - "41(4)(c)": [ - "PRI-01.6" + "2417": [ + "NET-14.4" ], - "41(4)(d)": [ - "PRI-01.6" + "2418": [ + "CFG-02", + "CFG-02.1", + "CFG-02.9" ], - "41(4)(e)": [ - "PRI-01.6" + "2419": [ + "IAC-11" ], - "41(4)(f)": [ - "PRI-01.6" + "2420": [ + "IAC-11" ], - "42(1)(a)": [ - "PRI-01.6" + "2421": [ + "MON-07.1", + "SEA-20" ], - "42(1)(b)": [ - "PRI-01.6" + "2422": [ + "CHG-04", + "IAC-08", + "PES-02.1" ], - "42(1)(c)": [ - "PRI-01.6" + "2423": [ + "AST-02.9" ], - "42(1)(d)": [ - "PRI-01.6" + "2426": [ + "END-04", + "END-04.1", + "END-04.7" ], - "42(2)(a)": [ - "PRI-01.6", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "2427": [ + "MON-01", + "NET-03" ], - "42(2)(b)": [ - "PRI-01.6", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "2428": [ + "NET-04" ], - "42(3)": [ - "PRI-01.6", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "2500": [ + "SEA-01.2" ], - "42(4)": [ - "PRI-01.6" + "2501": [ + "BCD-01", + "SEA-01.2" ], - "25(e)": [ - "PRI-02" + "2502": [ + "BCD-01" ], - "26(a)": [ - "PRI-02", - "PRI-03.7", - "PRI-06" + "2504": [ + "BCD-11", + "BCD-11.1" ], - "29(a)": [ - "PRI-02" + "2507": [ + "CFG-03", + "CFG-03.1", + "NET-04.1" ], - "29(b)": [ - "PRI-02" + "2508": [ + "NET-06" ], - "29(c)": [ - "PRI-02", - "PRI-02.1" + "2509": [ + "END-08", + "NET-20.7" ], - "29(d)": [ - "PRI-02" + "2510": [ + "MNT-04.2" ], - "29(e)": [ - "PRI-02" + "2511": [ + "MNT-02", + "MNT-03" ], - "29(g)": [ - "PRI-02" + "2512": [ + "IAC-06", + "MNT-05" ], - "29(h)": [ - "PRI-02" + "2513": [ + "MNT-06.1" ], - "35(1)": [ - "PRI-02.2" + "2600": [ + "HRS-03.1", + "SAT-02" ], - "35(2)": [ - "PRI-02.2" + "2603": [ + "HRS-03.1", + "SAT-02", + "SAT-03.6" ], - "35(2)(a)": [ - "PRI-02.2" + "2604": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "HRS-05.3" ], - "35(2)(b)": [ - "PRI-02.2" + "2700": [ + "HRS-04" ], - "35(2)(c)": [ - "PRI-02.2" + "2701": [ + "HRS-04" ], - "35(3)": [ - "PRI-02.2" + "2702": [ + "HRS-01", + "HRS-01.1", + "IAC-07" ], - "35(3)(a)": [ - "PRI-02.2" + "2703": [ + "HRS-15" ], - "35(3)(b)(i)": [ - "PRI-02.2" + "2704": [ + "PES-07.3", + "PES-08.2", + "PES-09" ], - "35(3)(b)(ii)": [ - "PRI-02.2" + "3100": [ + "MON-01" ], - "35(4)(a)": [ - "PRI-02.2" + "3101": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-17.1", + "HRS-03" ], - "35(4)(b)": [ - "PRI-02.2" + "3107": [ + "MON-03.2", + "MON-10" ], - "35(4)(c)(i)": [ - "PRI-02.2" + "3108": [ + "MON-06" ], - "35(4)(c)(ii)": [ - "PRI-02.2" + "3109": [ + "MON-17" ], - "32(1)": [ - "PRI-03" + "3200": [ + "MON-16" ], - "32(4)": [ - "PRI-03", - "PRI-03.5" + "3201": [ + "IRO-03" ], - "32(2)": [ - "PRI-03.2", - "PRI-03.4" + "3203": [ + "MON-16" ], - "32(3)": [ - "PRI-03.2", - "PRI-03.4" + "3204": [ + "AST-02.2" ], - "26(c)": [ - "PRI-03.4", - "PRI-03.7", - "PRI-06" + "4100": [ + "BCD-01" ], - "27(a)": [ - "PRI-03.6", - "PRI-04" + "4104": [ + "IRO-01", + "IRO-02" ], - "27(b)": [ - "PRI-03.6" + "4106": [ + "MON-16.3" ], - "27(c)": [ - "PRI-03.6" + "4200": [ + "IRO-13" ], - "25(c)": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1" + "0001": [ + "CPL-01" + ] + }, + "emea-gbr-def-stan-05-138-l2-2024": { + "1100": [ + "GOV-02", + "OPS-01.1" ], - "25(d)": [ - "PRI-04" + "1101": [ + "GOV-01.1", + "GOV-02", + "GOV-04.1" ], - "28(2)(a)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1102": [ + "GOV-04", + "HRS-03" ], - "28(2)(b)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1103": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "28(2)(c)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1200": [ + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-06" ], - "28(2)(d)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1201": [ + "RSK-01" ], - "28(2)(e)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1202": [ + "GOV-01.1", + "RSK-04" ], - "28(2)(f)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1203": [ + "AST-04" ], - "28(2)(f)(i)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1205": [ + "IAO-01", + "IAO-02", + "IAO-06" ], - "28(2)(f)(ii)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1206": [ + "CPL-02", + "CPL-02.2", + "CPL-03.2" ], - "28(2)(f)(iii)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "1300": [ + "AST-01", + "HRS-01" ], - "28(3)": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1" + "1301": [ + "AST-01", + "AST-02", + "AST-02.9" ], - "33(1)(a)": [ - "PRI-04.1", - "PRI-05.1" + "1400": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-03" ], - "33(1)(b)": [ - "PRI-04.1", - "PRI-05.1" + "1401": [ + "TPM-05", + "TPM-05.2" ], - "33(2)": [ - "PRI-04.1", - "PRI-05.1" + "1500": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.3", + "PES-05", + "PES-05.1" ], - "33(3)(a)": [ - "PRI-04.1", - "PRI-05.1" + "1501": [ + "PES-19" ], - "33(3)(b)": [ - "PRI-04.1", - "PRI-05.1" + "1502": [ + "PES-02.1", + "PES-03.4" ], - "33(3)(c)": [ - "PRI-04.1", - "PRI-05.1" + "1503": [ + "IAC-01.1", + "PES-06.1", + "PES-06.2", + "PES-06.6" ], - "33(3)(d)": [ - "PRI-04.1", - "PRI-05.1" + "2100": [ + "GOV-02", + "GOV-03", + "OPS-01.1" ], - "33(3)(e)": [ - "PRI-04.1", - "PRI-05.1" + "2101": [ + "GOV-02", + "GOV-03", + "OPS-01.1" ], - "33(4)": [ - "PRI-04.1", - "PRI-05.1" + "2200": [ + "IAC-01", + "IAC-01.2", + "IAC-08" ], - "37(1)(a)": [ - "PRI-04.1", - "PRI-05.1" + "2201": [ + "IAC-06" ], - "37(1)(b)": [ - "PRI-04.1", - "PRI-05.1" + "2202": [ + "AST-01", + "AST-02", + "AST-02.4" ], - "37(2)": [ - "PRI-04.1", - "PRI-05.1" + "2203": [ + "MON-01", + "MON-01.15" ], - "28(1)": [ - "PRI-04.2" + "2204": [ + "CFG-02", + "CFG-03" ], - "25(g)": [ - "PRI-05" + "2205": [ + "IAC-21" ], - "34(3)": [ - "PRI-05", - "PRI-05.1" + "2206": [ + "IAC-08", + "IAC-21" ], - "39(1)": [ - "PRI-05" + "2207": [ + "HRS-11" ], - "39(1)(a)": [ - "PRI-05" + "2208": [ + "IAC-01" ], - "39(1)(b)": [ - "PRI-05" + "2210": [ + "IAC-01", + "IAC-01.2" ], - "39(1)(c)": [ - "PRI-05" + "2211": [ + "IAC-10.8" ], - "39(1)(d)": [ - "PRI-05" + "2212": [ + "IAC-10.11" ], - "25(a)": [ - "PRI-05.1" + "2213": [ + "IAC-10.4" ], - "25(b)": [ - "PRI-05.1" + "2214": [ + "IAC-22" ], - "34(1)(a)": [ - "PRI-05.1" + "2215": [ + "IAC-02.2" ], - "34(1)(b)": [ - "PRI-05.1" + "2216": [ + "MON-03.3", + "IAC-21.5" ], - "34(1)(c)": [ - "PRI-05.1" + "2217": [ + "IAC-01.3" ], - "34(1)(d)": [ - "PRI-05.1" + "2218": [ + "IAC-02", + "IAC-15.1" ], - "34(2)(a)": [ - "PRI-05.1" + "2301": [ + "AST-04", + "DCH-01.4", + "DCH-02", + "DCH-03", + "IAO-03" ], - "34(2)(b)": [ - "PRI-05.1" + "2302": [ + "CRY-03", + "DCH-07", + "DCH-07.2" ], - "53(1)": [ - "PRI-05.1" + "2303": [ + "NET-07" ], - "53(2)": [ - "PRI-05.1" + "2304": [ + "CRY-01", + "IAC-01.2", + "NET-15.1" ], - "53(3)(a)": [ - "PRI-05.1" + "2305": [ + "CFG-03.4", + "IAC-06", + "NET-12", + "NET-14", + "NET-14.2", + "NET-14.5" ], - "53(3)(b)": [ - "PRI-05.1" + "2306": [ + "CRY-03", + "NET-14.2" ], - "53(4)": [ - "PRI-05.1" + "2307": [ + "NET-14.3" ], - "25(f)": [ - "PRI-05.2", - "PRI-06.1" + "2308": [ + "DCH-01", + "DCH-01.2", + "DCH-06" ], - "45(a)": [ - "PRI-05.4" + "2309": [ + "MDM-01", + "MDM-03" ], - "45(a)(i)": [ - "PRI-05.4" + "2310": [ + "AST-02", + "CFG-02", + "CRY-05", + "DCH-10", + "DCH-12" ], - "45(a)(ii)": [ - "PRI-05.4" + "2311": [ + "HRS-14", + "HRS-14.1" ], - "45(b)": [ - "PRI-05.4" + "2312": [ + "CFG-02.5", + "PES-11" ], - "45(c)(i)": [ - "PRI-05.4" + "2313": [ + "DCH-09" ], - "45(c)(ii)": [ - "PRI-05.4" + "2314": [ + "CPL-01" ], - "45(c)(iii)": [ - "PRI-05.4" + "2315": [ + "NET-10", + "NET-10.3", + "NET-20.4" ], - "46(1)(a)": [ - "PRI-05.4" + "2316": [ + "NET-03.4", + "NET-04" ], - "46(1)(b)": [ - "PRI-05.4" + "2317": [ + "CRY-01", + "CRY-05", + "END-01" ], - "46(2)(a)": [ - "PRI-05.4" + "2318": [ + "CRY-01" ], - "46(2)(b)": [ - "PRI-05.4" + "2319": [ + "CRY-09" ], - "47(1)": [ - "PRI-05.4", - "PRI-05.7" + "2320": [ + "NET-17" ], - "47(2)(a)": [ - "PRI-05.4", - "PRI-05.7" + "2321": [ + "DCH-15", + "HRS-03", + "SAT-03", + "WEB-14" ], - "47(2)(b)": [ - "PRI-05.4", - "PRI-05.7" + "2322": [ + "AST-16", + "HRS-05.5", + "MDM-01" ], - "47(2)(c)": [ - "PRI-05.4", - "PRI-05.7" + "2323": [ + "AST-09", + "DCH-09", + "DCH-09.1", + "TPM-05" ], - "47(2)(d)": [ - "PRI-05.4", - "PRI-05.7" + "2400": [ + "CFG-02", + "SEA-01" ], - "47(3)": [ - "PRI-05.4", - "PRI-05.7" + "2401": [ + "CFG-02" ], - "26(b)": [ - "PRI-06" + "2402": [ + "VPM-01", + "VPM-02", + "VPM-05", + "VPM-06" ], - "26(d)": [ - "PRI-06", - "PRI-06.1" + "2403": [ + "VPM-07" ], - "26(e)": [ - "PRI-06", - "PRI-06.5" + "2404": [ + "CHG-01" ], - "40(1)(a)": [ - "PRI-06.1" + "2405": [ + "VPM-01", + "VPM-05", + "VPM-05.6", + "VPM-05.7" ], - "40(2)(a)": [ - "PRI-06.1", - "PRI-07.1", - "PRI-07.3" + "2406": [ + "PRI-02", + "SEA-18" ], - "40(1)(b)": [ - "PRI-06.4", - "PRI-06.5" + "2407": [ + "PRI-02", + "SEA-18" ], - "40(2)(b)": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.3" + "2408": [ + "IAC-24" ], - "40(3)": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.3" + "2409": [ + "CFG-03.3" ], - "38(1)": [ - "PRI-06.6", - "PRI-06.7" + "2410": [ + "AST-01.4" ], - "38(2)": [ - "PRI-06.6", - "PRI-06.7" + "2411": [ + "END-01", + "END-02", + "END-04", + "IRO-15", + "NET-07", + "NET-08", + "NET-18" ], - "38(3)": [ - "PRI-06.6", - "PRI-06.7" + "2412": [ + "AST-21" ], - "38(4)": [ - "PRI-06.6", - "PRI-06.7" + "2413": [ + "END-10" ], - "38(5)(a)": [ - "PRI-06.6", - "PRI-06.7" + "2414": [ + "NET-09" ], - "38(5)(b)": [ - "PRI-06.6", - "PRI-06.7" + "2416": [ + "SEA-05" ], - "38(6)": [ - "PRI-06.6", - "PRI-06.7" + "2417": [ + "NET-14.4" ], - "38(7)": [ - "PRI-06.6", - "PRI-06.7" + "2418": [ + "CFG-02", + "CFG-02.1", + "CFG-02.9" ], - "40(2)": [ - "PRI-07.1", - "PRI-07.3" + "2419": [ + "IAC-11" ], - "18(1)": [ - "PRI-15" + "2420": [ + "IAC-11" ], - "18(2)": [ - "PRI-15" + "2421": [ + "MON-07.1", + "SEA-20" ], - "18(2)(a)": [ - "PRI-15" + "2422": [ + "CHG-04", + "IAC-08", + "PES-02.1" ], - "18(2)(b)": [ - "PRI-15" + "2423": [ + "AST-02.9" ], - "18(2)(c)": [ - "PRI-15" + "2424": [ + "IAC-15", + "IAC-16", + "IAC-16.1" ], - "18(2)(d)": [ - "PRI-15" + "2426": [ + "END-04", + "END-04.1", + "END-04.7" ], - "19(1)": [ - "PRI-15" + "2427": [ + "MON-01", + "NET-03" ], - "19(2)": [ - "PRI-15" + "2428": [ + "NET-04" ], - "19(2)(a)": [ - "PRI-15" + "2430": [ + "CFG-03", + "CFG-03.1" ], - "19(2)(b)": [ - "PRI-15" + "2500": [ + "SEA-01.2" ], - "19(2)(c)": [ - "PRI-15" + "2501": [ + "BCD-01", + "SEA-01.2" ], - "19(2)(d)": [ - "PRI-15" + "2503": [ + "BCD-04" ], - "19(2)(e)": [ - "PRI-15" + "2505": [ + "BCD-11", + "BCD-11.1", + "BCD-11.2", + "BCD-11.5" ], - "19(2)(f)": [ - "PRI-15" + "2506": [ + "BCD-11.4", + "BCD-11.6", + "DCH-07" ], - "19(2)(g)": [ - "PRI-15" + "2507": [ + "CFG-03", + "CFG-03.1", + "NET-04.1" ], - "19(3)": [ - "PRI-15" + "2508": [ + "NET-06" ], - "19(4)": [ - "PRI-15" + "2509": [ + "END-08", + "NET-20.7" ], - "19(5)": [ - "PRI-15" + "2510": [ + "MNT-04.2" ], - "19(6)": [ - "PRI-15" + "2511": [ + "MNT-02", + "MNT-03" ], - "19(7)": [ - "PRI-15" + "2512": [ + "IAC-06", + "MNT-05" ], - "31(1)": [ - "RSK-10" + "2513": [ + "MNT-06.1" ], - "31(2)(a)": [ - "RSK-10" + "2600": [ + "HRS-03.1", + "SAT-02" ], - "31(2)(b)": [ - "RSK-10" + "2601": [ + "RSK-12", + "SAT-03.6" ], - "31(2)(c)": [ - "RSK-10" + "2602": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.2", + "SAT-03.3", + "SAT-03.6" ], - "31(2)(d)": [ - "RSK-10" + "2603": [ + "HRS-03.1", + "SAT-02", + "SAT-03.6" ], - "31(3)": [ - "RSK-10" + "2604": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "HRS-05.3" ], - "31(4)": [ - "RSK-10" + "2605": [ + "SAT-02.1", + "SAT-03.1" ], - "31(5)": [ - "RSK-10" + "2700": [ + "HRS-04" ], - "31(6)": [ - "RSK-10" - ] - }, - "emea-nga-dpr-2019": { - "4.1(1)": [ - "GOV-02", - "CPL-01" + "2701": [ + "HRS-04" ], - "2.1(2)": [ - "CPL-01" + "2702": [ + "HRS-01", + "HRS-01.1", + "IAC-07" ], - "2.1(3)": [ - "CPL-01" + "2703": [ + "HRS-15" ], - "3.1(16)": [ - "CPL-01" + "2704": [ + "PES-07.3", + "PES-08.2", + "PES-09" ], - "4.1(6)": [ - "CPL-01", - "CPL-02" + "3100": [ + "MON-01" ], - "4.1(7)": [ - "CPL-01", - "CPL-02" + "3101": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-17.1", + "HRS-03" ], - "4.1(5)(a)": [ - "CPL-02" + "3103": [ + "MON-08", + "MON-10" ], - "4.1(5)(b)": [ - "CPL-02" + "3104": [ + "MON-03", + "IRO-08" ], - "4.1(5)(c)": [ - "CPL-02" + "3105": [ + "IRO-01", + "IRO-02" ], - "4.1(5)(d)": [ - "CPL-02" + "3106": [ + "MON-01", + "SAT-03.6" ], - "4.1(5)(e)": [ - "CPL-02" + "3107": [ + "MON-03.2", + "MON-10" ], - "4.1(5)(f)": [ - "CPL-02" + "3108": [ + "MON-06" ], - "4.1(5)(g)": [ - "CPL-02" + "3109": [ + "MON-17" ], - "4.1(5)(h)": [ - "CPL-02" + "3110": [ + "THR-03", + "THR-03.1" ], - "4.1(5)(i)": [ - "CPL-02" + "3200": [ + "MON-16" ], - "4.1(5)(j)": [ - "CPL-02" + "3201": [ + "IRO-03" ], - "2.11": [ - "DCH-25" + "3202": [ + "MON-16" ], - "2.11(a)": [ - "DCH-25" + "3203": [ + "MON-16" ], - "2.11(b)": [ - "DCH-25" + "3204": [ + "AST-02.2" ], - "2.11(c)": [ - "DCH-25" + "4100": [ + "BCD-01" ], - "2.11(d)": [ - "DCH-25" + "4101": [ + "IRO-04" ], - "2.11(e)": [ - "DCH-25" + "4102": [ + "IRO-04" ], - "2.12": [ - "DCH-25" + "4103": [ + "IRO-06" ], - "2.12(a)": [ - "DCH-25" + "4104": [ + "IRO-01", + "IRO-02" ], - "2.12(b)": [ - "DCH-25" + "4105": [ + "IRO-06" ], - "2.12(c)": [ - "DCH-25" + "4106": [ + "MON-16.3" ], - "2.12(d)": [ - "DCH-25" + "4200": [ + "IRO-13" ], - "2.12(e)": [ - "DCH-25" + "4201": [ + "RSK-04.1", + "RSK-08" ], - "2.12(f)": [ - "DCH-25" + "0001": [ + "CPL-01" ], - "4.1(3)": [ - "PRI-01", - "PRI-01.4" + "0002": [ + "CPL-01" + ] + }, + "emea-gbr-def-stan-05-138-l3-2024": { + "1100": [ + "GOV-02", + "OPS-01.1" ], - "4.1(2)": [ - "PRI-01.4" + "1101": [ + "GOV-01.1", + "GOV-02", + "GOV-04.1" ], - "2.1(1)(d)": [ - "PRI-01.6" + "1102": [ + "GOV-04", + "HRS-03" ], - "2.6": [ - "PRI-01.6" + "1103": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "2.5": [ - "PRI-02" + "1200": [ + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-06" ], - "2.5(a)": [ - "PRI-02" + "1201": [ + "RSK-01" ], - "2.5(b)": [ - "PRI-02" + "1202": [ + "GOV-01.1", + "RSK-04" ], - "2.5(c)": [ - "PRI-02" + "1203": [ + "AST-04" ], - "2.5(d)": [ - "PRI-02" + "1204": [ + "RSK-01", + "RSK-04", + "THR-01", + "THR-03", + "THR-03.1" ], - "2.5(e)": [ - "PRI-02" + "1205": [ + "IAO-01", + "IAO-02", + "IAO-06" ], - "2.5(f)": [ - "PRI-02" + "1206": [ + "CPL-02", + "CPL-02.2", + "CPL-03.2" ], - "2.5(g)": [ - "PRI-02" + "1300": [ + "AST-01", + "HRS-01" ], - "2.5(h)": [ - "PRI-02" + "1301": [ + "AST-01", + "AST-02", + "AST-02.9" ], - "2.5(i)": [ - "PRI-02" + "1400": [ + "RSK-09", + "RSK-09.1", + "TPM-01", + "TPM-03" ], - "3.1(1)": [ - "PRI-02", - "PRI-06" + "1401": [ + "TPM-05", + "TPM-05.2" ], - "3.1(7)(a)": [ - "PRI-02" + "1500": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.3", + "PES-05", + "PES-05.1" ], - "3.1(7)(b)": [ - "PRI-02" + "1501": [ + "PES-19" ], - "3.1(7)(c)": [ - "PRI-02" + "1502": [ + "PES-02.1", + "PES-03.4" ], - "3.1(7)(d)": [ - "PRI-02" + "1503": [ + "IAC-01.1", + "PES-06.1", + "PES-06.2", + "PES-06.6" ], - "3.1(7)(e)": [ - "PRI-02" + "2100": [ + "GOV-02", + "GOV-03", + "OPS-01.1" ], - "3.1(7)(f)": [ - "PRI-02" + "2101": [ + "GOV-02", + "GOV-03", + "OPS-01.1" ], - "3.1(7)(g)": [ - "PRI-02" + "2200": [ + "IAC-01", + "IAC-01.2", + "IAC-08" ], - "3.1(7)(h)": [ - "PRI-02" + "2201": [ + "IAC-06" ], - "3.1(7)(i)": [ - "PRI-02" + "2202": [ + "AST-01", + "AST-02", + "AST-02.4" ], - "3.1(7)(j)": [ - "PRI-02" + "2203": [ + "MON-01", + "MON-01.15" ], - "3.1(7)(k)": [ - "PRI-02" + "2204": [ + "CFG-02", + "CFG-03" ], - "3.1(7)(l)": [ - "PRI-02" + "2205": [ + "IAC-21" ], - "3.1(7)(m)": [ - "PRI-02" + "2206": [ + "IAC-08", + "IAC-21" ], - "3.1(7)(n)": [ - "PRI-02" + "2207": [ + "HRS-11" ], - "3.1(9)": [ - "PRI-02" + "2208": [ + "IAC-01" ], - "3.1(9)(a)": [ - "PRI-02" + "2209": [ + "IAC-01.2", + "IAC-15.1" ], - "3.1(9)(b)": [ - "PRI-02" + "2210": [ + "IAC-01", + "IAC-01.2" ], - "3.1(9)(c)": [ - "PRI-02" + "2211": [ + "IAC-10.8" ], - "3.1(9)(d)": [ - "PRI-02" + "2212": [ + "IAC-10.11" ], - "3.1(9)(e)": [ - "PRI-02" + "2213": [ + "IAC-10.4" ], - "2.3(1)": [ - "PRI-02.1" + "2214": [ + "IAC-22" ], - "2.2(a)": [ - "PRI-03", - "PRI-04.1" + "2215": [ + "IAC-02.2" ], - "2.3(2)": [ - "PRI-03" + "2216": [ + "MON-03.3", + "IAC-21.5" ], - "2.3(2)(a)": [ - "PRI-03" + "2217": [ + "IAC-01.3" ], - "2.3(2)(b)": [ - "PRI-03" + "2218": [ + "IAC-02", + "IAC-15.1" ], - "2.3(2)(c)": [ - "PRI-03" + "2301": [ + "AST-04", + "DCH-01.4", + "DCH-02", + "DCH-03", + "IAO-03" ], - "2.3(2)(d)": [ - "PRI-03" + "2302": [ + "CRY-03", + "DCH-07", + "DCH-07.2" ], - "2.3(2)(e)": [ - "PRI-03" + "2303": [ + "NET-07" ], - "2.8": [ - "PRI-03.4", - "PRI-06.4" + "2304": [ + "CRY-01", + "IAC-01.2", + "NET-15.1" ], - "2.8(a)": [ - "PRI-03.4", - "PRI-06.4" + "2305": [ + "CFG-03.4", + "IAC-06", + "NET-12", + "NET-14", + "NET-14.2", + "NET-14.5" ], - "2.8(b)": [ - "PRI-03.4", - "PRI-06.4" + "2306": [ + "CRY-03", + "NET-14.2" ], - "2.1(1)(a)": [ - "PRI-04.1" + "2307": [ + "NET-14.3" ], - "2.1(1)(a)(i)": [ - "PRI-04.1" + "2308": [ + "DCH-01", + "DCH-01.2", + "DCH-06" ], - "2.1(1)(a)(ii)": [ - "PRI-04.1" + "2309": [ + "MDM-01", + "MDM-03" ], - "2.2(b)": [ - "PRI-04.1" + "2310": [ + "AST-02", + "CFG-02", + "CRY-05", + "DCH-10", + "DCH-12" ], - "2.2(c)": [ - "PRI-04.1" + "2311": [ + "HRS-14", + "HRS-14.1" ], - "2.2(d)": [ - "PRI-04.1" + "2312": [ + "CFG-02.5", + "PES-11" ], - "2.2(e)": [ - "PRI-04.1" + "2313": [ + "DCH-09" ], - "2.4(a)": [ - "PRI-04.1" + "2314": [ + "CPL-01" ], - "2.1(1)(c)": [ - "PRI-05" + "2315": [ + "NET-10", + "NET-10.3", + "NET-20.4" ], - "2.1(1)(b)": [ - "PRI-05.1" + "2316": [ + "NET-03.4", + "NET-04" ], - "3.1(12)": [ - "PRI-05.1", - "PRI-05.4" + "2317": [ + "CRY-01", + "CRY-05", + "END-01" ], - "3.1(3)": [ - "PRI-06" + "2318": [ + "CRY-01" ], - "3.1(3)(a)": [ - "PRI-06" + "2319": [ + "CRY-09" ], - "3.1(3)(b)": [ - "PRI-06" + "2320": [ + "NET-17" ], - "3.1(13)": [ - "PRI-06.2", - "PRI-06.4", - "PRI-06.5" + "2321": [ + "DCH-15", + "HRS-03", + "SAT-03", + "WEB-14" ], - "3.1(2)": [ - "PRI-06.4" + "2322": [ + "AST-16", + "HRS-05.5", + "MDM-01" ], - "3.1(4)": [ - "PRI-06.4" + "2323": [ + "AST-09", + "DCH-09", + "DCH-09.1", + "TPM-05" ], - "3.1(5)": [ - "PRI-06.4" + "2400": [ + "CFG-02", + "SEA-01" ], - "3.1(11)(a)": [ - "PRI-06.4" + "2401": [ + "CFG-02" ], - "3.1(11)(b)": [ - "PRI-06.4" + "2402": [ + "VPM-01", + "VPM-02", + "VPM-05", + "VPM-06" ], - "3.1(11)(c)": [ - "PRI-06.4" + "2403": [ + "VPM-07" ], - "3.1(11)(d)": [ - "PRI-06.4" + "2404": [ + "CHG-01" ], - "3.1(6)": [ - "PRI-06.6", - "PRI-06.7" + "2405": [ + "VPM-01", + "VPM-05", + "VPM-05.6", + "VPM-05.7" ], - "3.1(14)": [ - "PRI-06.6", - "PRI-06.7" + "2406": [ + "PRI-02", + "SEA-18" ], - "3.1(14)(a)": [ - "PRI-06.6", - "PRI-06.7" + "2407": [ + "PRI-02", + "SEA-18" ], - "3.1(14)(b)": [ - "PRI-06.6", - "PRI-06.7" + "2408": [ + "IAC-24" ], - "3.1(14)(c)": [ - "PRI-06.6", - "PRI-06.7" + "2409": [ + "CFG-03.3" ], - "3.1(15)": [ - "PRI-06.6" + "2410": [ + "AST-01.4" ], - "2.4(b)": [ - "PRI-07", - "PRI-07.1" + "2411": [ + "END-01", + "END-02", + "END-04", + "IRO-15", + "NET-07", + "NET-08", + "NET-18" ], - "2.7": [ - "PRI-07.1" + "2412": [ + "AST-21" ], - "3.1(10)": [ - "PRI-07.3" + "2413": [ + "END-10" ], - "1.3": [ - "SEA-02.1" - ] - }, - "emea-nor-pda-2018": { - "8": [ - "PRI-05" + "2414": [ + "NET-09" ], - "9": [ - "PRI-05.4" + "2415": [ + "CFG-02.2" ], - "11": [ - "PRI-05", - "PRI-05.1", - "PRI-05.2" + "2416": [ + "SEA-05" ], - "13": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "2417": [ + "NET-14.4" ], - "14": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "2418": [ + "CFG-02", + "CFG-02.1", + "CFG-02.9" ], - "15": [ - "PRI-05" + "2419": [ + "IAC-11" ], - "18": [ - "PRI-06" + "2420": [ + "IAC-11" ], - "27": [ - "DCH-22.1", - "PRI-05", - "PRI-05.1", - "PRI-06.1" + "2421": [ + "MON-07.1", + "SEA-20" ], - "28": [ - "PRI-05" + "2422": [ + "CHG-04", + "IAC-08", + "PES-02.1" ], - "29": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "2423": [ + "AST-02.9" ], - "31": [ - "PRI-02" + "2424": [ + "IAC-15", + "IAC-16", + "IAC-16.1" ], - "32": [ - "PRI-02.1" + "2425": [ + "END-06", + "END-06.1" ], - "33": [ - "PRI-15" + "2426": [ + "END-04", + "END-04.1", + "END-04.7" ], - "Inferred": [ - "PRI-01" + "2427": [ + "MON-01", + "NET-03" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-pol-act-29-1997": { - "1": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "2428": [ + "NET-04" ], - "23": [ - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05" + "2430": [ + "CFG-03", + "CFG-03.1" ], - "26": [ - "PRI-05", - "PRI-05.1" + "2500": [ + "SEA-01.2" ], - "27": [ - "PRI-05.4" + "2501": [ + "BCD-01", + "SEA-01.2" ], - "31": [ - "TPM-03", - "TPM-05" + "2503": [ + "BCD-04" ], - "32": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2" + "2505": [ + "BCD-11", + "BCD-11.1", + "BCD-11.2", + "BCD-11.5" ], - "36": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "2506": [ + "BCD-11.4", + "BCD-11.6", + "DCH-07" + ], + "2507": [ + "CFG-03", + "CFG-03.1", + "NET-04.1" ], - "40": [ - "PRI-15" + "2508": [ + "NET-06" ], - "46": [ - "PRI-01.1" + "2509": [ + "END-08", + "NET-20.7" ], - "47": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "2510": [ + "MNT-04.2" ], - "Inferred": [ - "PRI-01" + "2511": [ + "MNT-02", + "MNT-03" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-qat-pdppl-2020": { - "1": [ - "SEA-02.1" + "2512": [ + "IAC-06", + "MNT-05" ], - "2": [ - "CPL-01", - "PRI-01" + "2513": [ + "MNT-06.1" ], - "3": [ - "PRI-01" + "2600": [ + "HRS-03.1", + "SAT-02" ], - "4": [ - "PRI-03" + "2601": [ + "RSK-12", + "SAT-03.6" ], - "6": [ - "PRI-06" + "2602": [ + "SAT-02", + "SAT-02.2", + "SAT-03", + "SAT-03.2", + "SAT-03.3", + "SAT-03.6" ], - "10": [ - "PRI-01.4", - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-05.4" + "2603": [ + "HRS-03.1", + "SAT-02", + "SAT-03.6" ], - "12": [ - "PRI-07.1", - "TPM-05", - "TPM-05.2" + "2604": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "HRS-05.3" ], - "13": [ - "PRI-01.6" + "2605": [ + "SAT-02.1", + "SAT-03.1" ], - "14": [ - "IRO-04.1", - "IRO-10", - "IRO-10.2" + "2700": [ + "HRS-04" ], - "15": [ - "CLD-09", - "DCH-19", - "DCH-25", - "PRI-01.5" + "2701": [ + "HRS-04" ], - "16": [ - "PRI-05.4" + "2702": [ + "HRS-01", + "HRS-01.1", + "IAC-07" ], - "22": [ - "PRI-05.4" + "2703": [ + "HRS-15" ], - "8.4": [ - "GOV-02" + "2704": [ + "PES-07.3", + "PES-08.2", + "PES-09" ], - "8.3": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "PRI-01.6" + "3100": [ + "MON-01" ], - "11.1": [ - "GOV-15.1", - "GOV-15.3", - "GOV-15.4", - "IAO-01", - "IAO-02", - "IAO-03", - "PRM-05" + "3102": [ + "MON-01", + "MON-01.2", + "MON-01.8", + "MON-17.1", + "HRS-03" ], - "11.3": [ - "GOV-15.2", - "IAO-01", - "PRM-05", - "SAT-01", - "SAT-03", - "SAT-03.3" + "3103": [ + "MON-08", + "MON-10" ], - "11.5": [ - "GOV-15.2", - "IAO-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TDA-01", - "TDA-01.1" + "3104": [ + "MON-03", + "IRO-08" ], - "11.6": [ - "GOV-15.2", - "IAO-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TDA-01", - "TDA-01.1" + "3105": [ + "IRO-01", + "IRO-02" ], - "11.2": [ - "GOV-15.3", - "IAO-01", - "IAO-02", - "PRM-05" + "3106": [ + "MON-01", + "SAT-03.6" ], - "11.7": [ - "GOV-15.5", - "CPL-03", - "CPL-03.2", - "IAO-01", - "PRM-05" + "3107": [ + "MON-03.2", + "MON-10" ], - "11.8": [ - "GOV-15.5", - "CPL-03", - "CPL-03.2", - "IAO-01", - "PRM-05" + "3108": [ + "MON-06" ], - "11.4": [ - "IAO-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TDA-01", - "TDA-01.1" + "3109": [ + "MON-17" ], - "8.1": [ - "PRI-01", - "PRI-01.1", - "PRI-02", - "PRI-02.1" + "3110": [ + "THR-03", + "THR-03.1" ], - "8.2": [ - "PRI-01.4", - "PRI-05.1", - "PRI-05.4", - "RSK-10" + "3200": [ + "MON-16" ], - "6.1": [ - "PRI-02", - "PRI-02.1" + "3201": [ + "IRO-03" ], - "9.1": [ - "PRI-02", - "PRI-04" + "3202": [ + "MON-16" ], - "9.3": [ - "PRI-02" + "3203": [ + "MON-16" ], - "9.4": [ - "PRI-02", - "PRI-05.1", - "PRI-05.4" + "3204": [ + "AST-02.2" ], - "17.1": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "4100": [ + "BCD-01" ], - "17.2": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "4101": [ + "IRO-04" ], - "17.3": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "4102": [ + "IRO-04" ], - "17.4": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "4103": [ + "IRO-06" ], - "17.5": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "4104": [ + "IRO-01", + "IRO-02" ], - "5.2": [ - "PRI-03" + "4105": [ + "IRO-06" ], - "5.1": [ - "PRI-03.4" + "4106": [ + "MON-16.3" ], - "9.2": [ - "PRI-04.1" + "4200": [ + "IRO-13" ], - "18.1": [ - "PRI-04.1" + "4201": [ + "RSK-04.1", + "RSK-08" ], - "18.2": [ - "PRI-04.1" + "4202": [ + "BCD-12", + "BCD-12.2" ], - "18.3": [ - "PRI-04.1" + "0001": [ + "CPL-01" ], - "18.4": [ - "PRI-04.1" + "0002": [ + "CPL-01" + ] + }, + "emea-gbr-dpa-2018": { + "Section 67(1)": [ + "IRO-10" ], - "21.1": [ - "PRI-06" + "Section 67(1)(a)": [ + "IRO-10" ], - "21.2": [ - "PRI-06" + "Section 67(1)(b)": [ + "IRO-10" ], - "5.4": [ - "PRI-06.1", - "PRI-06.4" + "Section 67(2)": [ + "IRO-10" ], - "6.2": [ - "PRI-06.1", - "PRI-06.2", - "PRI-14", - "PRI-14.1", - "PRI-14.2" + "Section 67(3)": [ + "IRO-10" ], - "5.3": [ - "PRI-06.4", - "PRI-06.5" + "Section 67(4)": [ + "IRO-10" ], - "6.3": [ - "PRI-06.4", - "PRI-06.6", - "PRI-06.7" - ] - }, - "emea-rus-federal-law-27-2006": { - "5": [ - "PRI-02.1", - "PRI-04", - "PRI-04.1", - "PRI-05" + "Section 67(4)(a)": [ + "IRO-10" ], - "6": [ - "PRI-03", - "PRI-05.4" + "Section 67(4)(b)": [ + "IRO-10" ], - "7": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "Section 67(4)(c)": [ + "IRO-10" ], - "9": [ - "PRI-03" + "Section 67(4)(d)": [ + "IRO-10" ], - "10": [ - "PRI-05.4" + "Section 67(5)": [ + "IRO-10" ], - "12": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "Section 67(6)": [ + "IRO-10" ], - "14": [ - "PRI-06" + "Section 67(6)(a)": [ + "IRO-10" ], - "16": [ - "PRI-05.6" + "Section 67(6)(b)": [ + "IRO-10" ], - "17": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.3" + "Section 67(6)(c)": [ + "IRO-10" ], - "18": [ - "PRI-06.2" + "Section 67(7)": [ + "IRO-10" ], - "19": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "Section 67(9)": [ + "IRO-10" ], - "22": [ - "PRI-02" + "Section 68(1)": [ + "IRO-10" ], - "23": [ - "PRI-01.1", - "PRI-15" + "Section 68(2)": [ + "IRO-10" ], - "Inferred": [ - "PRI-01" + "Section 68(2)(a)": [ + "IRO-10" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-sau-cscc-1-2019": { - "1-1": [ - "GOV-09", - "PRM-01", - "PRM-01.1", - "PRM-02", - "PRM-03" + "Section 68(2)(b)": [ + "IRO-10" ], - "2-1": [ - "AST-01" + "Section 68(2)(c)": [ + "IRO-10" ], - "2-5": [ - "AST-01", - "AST-16", - "END-01", - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.3", - "MDM-01" + "Section 68(2)(d)": [ + "IRO-10" ], - "2-1-1-1": [ - "AST-02" + "Section 68(3)": [ + "IRO-10" ], - "2-1-1-2": [ - "AST-03" + "Section 68(3)(a)": [ + "IRO-10" ], - "2-6-1-5": [ - "AST-05.1", - "DCH-14.2", - "DCH-17", - "DCH-25" + "Section 68(3)(b)": [ + "IRO-10" ], - "2-3-1-4": [ - "AST-27", - "IAC-20.4", - "NET-06" + "Section 68(3)(c)": [ + "IRO-10" ], - "2-2-1-8": [ - "AST-28", - "IAC-20.2" + "Section 68(4)": [ + "IRO-10" ], - "2-8": [ - "BCD-01" + "Section 68(5)": [ + "IRO-10" ], - "3-1": [ - "BCD-01" + "Section 68(6)": [ + "IRO-10" ], - "3-1-1-1": [ - "BCD-01", - "BCD-04.2", - "BCD-08", - "BCD-09" + "Section 68(6)(a)": [ + "IRO-10" ], - "3-1-1-2": [ - "BCD-01", - "BCD-02" + "Section 68(6)(b)": [ + "IRO-10" ], - "2-8-1-1": [ - "BCD-02" + "Section 68(7)": [ + "IRO-10" ], - "3-1-1-4": [ - "BCD-03.1" + "Section 68(7)(a)": [ + "IRO-10" ], - "2-8-1-2": [ - "BCD-11" + "Section 68(7)(b)": [ + "IRO-10" ], - "2-8-1-3": [ - "BCD-11", - "BCD-11.4" + "Section 68(7)(c)": [ + "IRO-10" ], - "2-8-2": [ - "BCD-11.1", - "BCD-12" + "Section 68(7)(e)": [ + "IRO-10" ], - "3-1-1-3": [ - "BCD-11.5" + "Section 68(8)": [ + "IRO-10" ], - "1-3-1-2": [ - "CHG-02.2", - "CHG-03", - "PRM-05" + "Section 68(9)": [ + "IRO-10" ], - "1-3-2-2": [ - "CHG-04.5", - "TDA-20.3" + "Section 69(1)": [ + "PRI-01.4" ], - "4-2": [ - "CLD-01" + "Section 69(2)": [ + "PRI-01.4" ], - "1-3-2-3": [ - "CLD-04", - "CFG-02", - "CFG-02.5", - "TDA-06" + "Section 69(2)(a)": [ + "PRI-01.4" ], - "4-2-1-1": [ - "CLD-09" + "Section 69(2)(b)": [ + "PRI-01.4" ], - "1-4": [ - "CPL-01", - "CPL-02" + "Section 69(3)": [ + "PRI-01.4" ], - "1-4-2": [ - "CPL-02.1", - "CPL-03.1" + "Section 70(1)": [ + "PRI-01.4" ], - "2-13-4": [ - "CPL-02.1", - "CPL-03", - "PRM-07" + "Section 70(2)": [ + "PRI-01.4" ], - "1-4-1": [ - "CPL-03", - "CPL-03.2" + "Section 70(2)(a)": [ + "PRI-01.4" ], - "2-3-1-6": [ - "CFG-01", - "CFG-02.1", - "NET-04.6" + "Section 70(2)(b)": [ + "PRI-01.4" ], - "2-3-1-7": [ - "CFG-02", - "CFG-02.5" + "Section 70(3)": [ + "PRI-01.4" ], - "2-3-1-1": [ - "CFG-03.3" + "Section 70(3)(a)": [ + "PRI-01.4" ], - "2-11": [ - "MON-01", - "MON-01.16" + "Section 70(3)(b)": [ + "PRI-01.4" ], - "2-11-1-3": [ - "MON-01.2", - "MON-02", - "MON-02.1", - "MON-02.2", - "MON-03.2" + "Section 70(3)(c)": [ + "PRI-01.4" ], - "2-11-1-4": [ - "MON-01.2", - "MON-02", - "MON-02.1" + "Section 70(4)": [ + "PRI-01.4" ], - "2-11-1-1": [ - "MON-01.4" + "Section 70(4)(a)": [ + "PRI-01.4" ], - "2-11-1-2": [ - "MON-01.8" + "Section 70(4)(b)": [ + "PRI-01.4" ], - "2-3-1-8": [ - "MON-02.5", - "MON-08" + "Section 70(5)": [ + "PRI-01.4" ], - "2-11-1-5": [ - "MON-03", - "MON-08", - "MON-08.1" + "Section 71(1)": [ + "PRI-01.4" ], - "2-11-2": [ - "MON-08", - "MON-08.1", - "MON-10", - "DCH-18" + "Section 71(1)(a)": [ + "PRI-01.4" ], - "2-7": [ - "CRY-01" + "Section 71(1)(b)": [ + "PRI-01.4" ], - "2-7-1-3": [ - "CRY-01", - "CRY-01.5" + "Section 71(1)(c)": [ + "PRI-01.4" ], - "2-3-1-5": [ - "CRY-03", - "NET-01", - "NET-15" + "Section 71(1)(d)": [ + "PRI-01.4" ], - "2-7-1-1": [ - "CRY-03" + "Section 71(1)(e)": [ + "PRI-01.4" ], - "2-7-1-2": [ - "CRY-05" + "Section 71(1)(f)": [ + "PRI-01.4" ], - "2-6": [ - "DCH-01" + "Section 71(2)": [ + "PRI-01.4" ], - "2-6-1-3": [ - "DCH-01", - "DCH-03.1" + "Section 71(2)(a)": [ + "PRI-01.4" ], - "2-6-1-2": [ - "DCH-02" + "Section 71(2)(b)": [ + "PRI-01.4" ], - "2-6-1-1": [ - "DCH-02.1" + "Section 71(2)(c)": [ + "PRI-01.4" ], - "2-6-1-4": [ - "DCH-18" + "Section 71(2)(d)": [ + "PRI-01.4" ], - "2-3-1-2": [ - "END-01", - "END-02" + "Section 71(3)": [ + "PRI-01.4" ], - "1-5": [ - "HRS-01" + "Section 78": [ + "PRI-01.5" ], - "1-5-1-2": [ - "HRS-02", - "HRS-04.3" + "Section 78(1)": [ + "PRI-01.5" ], - "1-5-1-1": [ - "HRS-04" + "Section 78(1)(a)": [ + "PRI-01.5" ], - "2-2": [ - "IAC-01" + "Section 78(1)(b)": [ + "PRI-01.5" ], - "2-2-1-5": [ - "IAC-01", - "IAC-10.1" + "Section 78(1)(b)(i)": [ + "PRI-01.5" ], - "2-2-1-7": [ - "IAC-02.1", - "IAC-15" + "Section 78(1)(b)(ii)": [ + "PRI-01.5" ], - "2-2-1-3": [ - "IAC-06", - "IAC-06.2" + "Section 78(1A)": [ + "PRI-01.5" ], - "2-2-1-4": [ - "IAC-06", - "IAC-06.1", - "IAC-06.3" + "Section 78(1A)(a)": [ + "PRI-01.5" ], - "2-2-1-6": [ - "IAC-10", - "IAC-10.5", - "IAC-10.11" + "Section 78(1A)(b)": [ + "PRI-01.5" ], - "2-2-2": [ - "IAC-18" + "Section 78(2)": [ + "PRI-01.5" ], - "2-5-1-1": [ - "MDM-02", - "MDM-06", - "MDM-11" + "Section 78(3)": [ + "PRI-01.5" ], - "2-5-1-2": [ - "MDM-03" + "Section 78(3)(a)": [ + "PRI-01.5" ], - "2-4": [ - "NET-01" + "Section 78(3)(b)": [ + "PRI-01.5" ], - "2-4-1-5": [ - "NET-01", - "NET-02" + "Section 78(3)(c)": [ + "PRI-01.5" ], - "2-4-1-8": [ - "NET-02.1" + "Section 78(4)": [ + "PRI-01.5" ], - "2-4-1-4": [ - "NET-04", - "NET-04.1", - "NET-15", - "NET-15.2" + "Section 78(5)": [ + "PRI-01.5" ], - "2-4-1-6": [ - "NET-04", - "NET-04.1", - "NET-06.3", - "NET-06.5" + "Section 78(5)(a)": [ + "PRI-01.5" ], - "2-4-1-7": [ - "NET-04", - "NET-04.1", - "NET-06.3" + "Section 78(5)(b)": [ + "PRI-01.5" ], - "2-4-1-9": [ - "NET-04", - "NET-04.1" + "Section 78(6)": [ + "PRI-01.5" ], - "2-4-1-2": [ - "NET-04.6" + "Section 78(7)": [ + "PRI-01.5" ], - "2-4-1-1": [ - "NET-06" + "Section 78(7)(a)": [ + "PRI-01.5" ], - "2-4-1-3": [ - "NET-06.5", - "NET-18.1" + "Section 78(7)(b)": [ + "PRI-01.5" ], - "2-2-1-1": [ - "NET-14", - "NET-14.5" + "Section 55(3)": [ + "PRI-01.6" ], - "2-2-1-2": [ - "NET-14", - "NET-14.5" + "Section 55(3)(a)": [ + "PRI-01.6" ], - "2-3": [ - "PES-01" + "Section 55(3)(b)": [ + "PRI-01.6" ], - "1-1-1": [ - "PRM-01.1" + "Section 55(3)(c)": [ + "PRI-01.6" ], - "1-3": [ - "PRM-04" + "Section 55(3)(d)": [ + "PRI-01.6" ], - "2-13-1": [ - "PRM-04", - "PRM-05", - "TDA-01.1", - "TDA-02", - "TDA-06" + "Section 56(1)": [ + "PRI-01.6" ], - "2-13-2": [ - "PRM-04", - "PRM-05", - "TDA-01.1", - "TDA-02", - "TDA-06" + "Section 56(2)": [ + "PRI-01.6" ], - "2-13-3-1": [ - "PRM-04", - "PRM-05", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-06" + "Section 56(3)": [ + "PRI-01.6" ], - "2-13-3-2": [ - "PRM-04", - "PRM-05", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-06" + "Section 57(1)": [ + "PRI-01.6" ], - "2-13-3-3": [ - "PRM-04", - "PRM-05", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-06" + "Section 57(1)(a)": [ + "PRI-01.6" ], - "2-13-3-4": [ - "PRM-04", - "PRM-05", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-06" + "Section 57(1)(b)": [ + "PRI-01.6" ], - "1-2": [ - "RSK-01" + "Section 57(2)": [ + "PRI-01.6" ], - "1-2-1-1": [ - "RSK-04" + "Section 57(3)": [ + "PRI-01.6" ], - "1-2-1-2": [ - "RSK-04.1" + "Section 57(4)": [ + "PRI-01.6" ], - "2-13": [ - "TDA-01" + "Section 57(4)(a)": [ + "PRI-01.6" ], - "1-3-2-4": [ - "TDA-07", - "TDA-08", - "TDA-08.1" + "Section 57(4)(b)": [ + "PRI-01.6" ], - "1-3-1-1": [ - "TDA-09" + "Section 57(4)(c)": [ + "PRI-01.6" ], - "1-3-2-1": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-15" + "Section 57(4)(d)": [ + "PRI-01.6" ], - "4-1": [ - "TPM-01" + "Section 57(5)": [ + "PRI-01.6" ], - "4-1-1-1": [ - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-04", - "TPM-04.1", - "TPM-05" + "Section 66(1)": [ + "PRI-01.6" ], - "4-1-1-2": [ - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-04", - "TPM-04.1", - "TPM-05" + "Section 66(2)": [ + "PRI-01.6" ], - "4-1-1": [ - "TPM-05" + "Section 66(2)(a)": [ + "PRI-01.6" ], - "2-3-1-3": [ - "VPM-01", - "VPM-05" + "Section 66(2)(b)": [ + "PRI-01.6" ], - "2-9": [ - "VPM-01" + "Section 66(2)(c)": [ + "PRI-01.6" ], - "2-9-2": [ - "VPM-01", - "VPM-06" + "Section 66(2)(d)": [ + "PRI-01.6" ], - "2-10-1-1": [ - "VPM-01.1", - "VPM-07" + "Section 66(3)": [ + "PRI-01.6" ], - "2-9-1-2": [ - "VPM-02", - "VPM-03" + "Section 45(4)": [ + "PRI-01.11" ], - "2-9-1-3": [ - "VPM-04" + "Section 45(4)(a)": [ + "PRI-01.11" ], - "2-9-1-1": [ - "VPM-06" + "Section 45(4)(b)": [ + "PRI-01.11" ], - "2-9-2-1": [ - "VPM-06.2" + "Section 45(4)(c)": [ + "PRI-01.11" ], - "2-10": [ - "VPM-07" + "Section 45(4)(e)": [ + "PRI-01.11" ], - "2-10-1-2": [ - "VPM-07", - "VPM-07.1" + "Section 47(2)": [ + "PRI-01.11" ], - "2-10-2": [ - "VPM-07" + "Section 44(1)": [ + "PRI-02" ], - "2-12": [ - "WEB-01", - "WEB-04" + "Section 44(1)(a)": [ + "PRI-02" ], - "2-12-1-1": [ - "WEB-01", - "WEB-04", - "WEB-06", - "WEB-08", - "WEB-10", - "WEB-12" + "Section 44(1)(b)": [ + "PRI-02" ], - "2-12-1-2": [ - "WEB-01", - "WEB-04", - "WEB-07" - ] - }, - "emea-sau-cgiot-2024": { - "1-1-2": [ - "GOV-01", - "EMB-01", - "RSK-03", - "RSK-06" + "Section 44(1)(c)": [ + "PRI-02" ], - "1-1-4": [ - "GOV-01.1", - "GOV-03", - "GOV-05" + "Section 44(1)(d)": [ + "PRI-02" ], - "1-2-1": [ - "GOV-02", - "OPS-01.1" + "Section 44(1)(d)(i)": [ + "PRI-02" ], - "1-2-3": [ - "GOV-03", - "CPL-01" + "Section 44(1)(d)(ii)": [ + "PRI-02" ], - "1-4-6": [ - "GOV-03" + "Section 44(1)(d)(iii)": [ + "PRI-02" ], - "1-8-3": [ - "GOV-03" + "Section 44(1)(e)": [ + "PRI-02" ], - "1-1-3": [ - "GOV-05.1" + "Section 44(2)": [ + "PRI-02" ], - "1-6-1": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "CPL-01" + "Section 44(2)(b)": [ + "PRI-02" ], - "4-1-4": [ - "AST-01.1" + "Section 44(2)(c)": [ + "PRI-02" ], - "2-1-1": [ - "AST-02" + "Section 44(2)(d)": [ + "PRI-02" ], - "2-1-2": [ - "AST-02.1", - "AST-02.9" + "Section 44(3)": [ + "PRI-02" ], - "2-6-2": [ - "AST-08", - "AST-15", - "EMB-06" + "Section 69(4)": [ + "PRI-02" ], - "2-13-2": [ - "AST-08" + "Section 47(4)": [ + "PRI-03.4", + "PRI-05.4" ], - "2-5-1": [ - "AST-09", - "CFG-02", - "EMB-01", - "EMB-02", - "SEA-01" + "Section 44(2)(a)": [ + "PRI-04.1" ], - "2-15-3": [ - "AST-09", - "SEA-07.1" + "Section 46(1)": [ + "PRI-05.2", + "PRI-06.1" ], - "2-15-1": [ - "AST-18", - "TDA-02.5" + "Section 47(3)": [ + "PRI-05.2" ], - "2-8-1": [ - "BCD-01", - "BCD-11" + "Section 44(4)": [ + "PRI-05.4" ], - "2-12-2": [ - "BCD-01", - "BCD-12", - "IRO-02", - "IRO-04", - "IRO-10", - "IRO-13" + "Section 44(4)(a)": [ + "PRI-05.4" ], - "3-1-1": [ - "BCD-01", - "EMB-08" + "Section 44(4)(b)": [ + "PRI-05.4" ], - "2-8-2": [ - "BCD-11", - "BCD-11.1" + "Section 44(4)(c)": [ + "PRI-05.4" ], - "2-8-3": [ - "BCD-11.5" + "Section 44(4)(e)": [ + "PRI-05.4" ], - "1-5-3": [ - "CHG-01", - "CHG-02.2", - "CHG-05" + "Section 45(1)": [ + "PRI-06" ], - "4-2-1": [ - "CLD-01", - "CLD-02" + "Section 45(1)(a)": [ + "PRI-06" ], - "4-2-2": [ - "CLD-02" + "Section 45(1)(b)": [ + "PRI-06" ], - "2-6-1": [ - "CPL-01", - "DCH-02", - "PES-16" + "Section 45(2)": [ + "PRI-06" ], - "2-7-1": [ - "CPL-01" + "Section 45(2)(a)": [ + "PRI-06" ], - "1-7-3": [ - "CPL-01.1", - "CPL-02" + "Section 45(2)(b)": [ + "PRI-06" ], - "1-7-1": [ - "CPL-02.2", - "CPL-03.2" + "Section 45(2)(c)": [ + "PRI-06" ], - "1-7-2": [ - "CPL-03.1" + "Section 45(2)(d)": [ + "PRI-06" ], - "1-2-2": [ - "CFG-02" + "Section 45(2)(e)": [ + "PRI-06" ], - "2-6-3": [ - "CFG-02", - "END-13.3" + "Section 45(2)(e)(i)": [ + "PRI-06" ], - "2-14-2": [ - "CFG-02", - "CFG-03.3" + "Section 45(2)(e)(ii)": [ + "PRI-06" ], - "2-15-2": [ - "CFG-02", - "IAO-01", - "IAO-02" + "Section 45(2)(f)": [ + "PRI-06" ], - "2-14-4": [ - "CFG-02.1" + "Section 45(2)(g)": [ + "PRI-06" ], - "2-11-1": [ - "MON-01", - "MON-01.2", - "MON-01.8", - "MON-10" + "Section 45(2A)": [ + "PRI-06" ], - "2-4-1": [ - "CRY-03", - "CRY-04", - "NET-01" + "Section 46(2)": [ + "PRI-06.1" ], - "2-4-2": [ - "CRY-03", - "CRY-04" + "Section 46(3)": [ + "PRI-06.1" ], - "2-4-3": [ - "CRY-03", - "CRY-04" + "Section 46(4)": [ + "PRI-06.1" ], - "2-7-2": [ - "CRY-03", - "CRY-05" + "Section 48(1)": [ + "PRI-06.2" ], - "1-1-1": [ - "EMB-01" + "Section 48(1)(a)": [ + "PRI-06.2" ], - "2-4-6": [ - "EMB-01", - "EMB-07", - "VPM-05" + "Section 48(1)(b)": [ + "PRI-06.2" ], - "2-14-1": [ - "EMB-04" + "Section 48(1)(b)(i)": [ + "PRI-06.2" ], - "2-11-2": [ - "EMB-05", - "EMB-09" + "Section 48(1)(b)(ii)": [ + "PRI-06.2" ], - "3-1-2": [ - "EMB-08" + "Section 48(1)(b)(iii)": [ + "PRI-06.2" ], - "1-3-2": [ - "HRS-01", - "HRS-03" + "Section 48(1)(b)(iv)": [ + "PRI-06.2" + ], + "Section 48(2)": [ + "PRI-06.2" + ], + "Section 48(2)(a)": [ + "PRI-06.2" ], - "1-8-1": [ - "HRS-01", - "HRS-01.1", - "HRS-02", - "HRS-03" + "Section 48(2)(b)": [ + "PRI-06.2" ], - "1-8-2": [ - "HRS-01.1", - "IAC-15.7", - "IAC-17" + "Section 48(3)": [ + "PRI-06.2" ], - "1-3-1": [ - "HRS-03" + "Section 48(3)(a)": [ + "PRI-06.2" ], - "2-2-1": [ - "HRS-11", - "IAC-08", - "IAC-16", - "IAC-21" + "Section 48(3)(b)": [ + "PRI-06.2" ], - "2-2-2": [ - "IAC-10", - "IAC-10.1", - "IAC-10.8", - "IAC-22" + "Section 48(3)(c)": [ + "PRI-06.2" ], - "2-2-3": [ - "IAC-17" + "Section 48(3)(e)": [ + "PRI-06.2" ], - "2-12-1": [ - "IRO-04", - "TDA-06.2" + "Section 48(4)": [ + "PRI-06.2" ], - "2-12-3": [ - "IRO-13" + "Section 48(4)(a)": [ + "PRI-06.2" ], - "1-5-2": [ - "IAO-01", - "PRM-07" + "Section 48(4)(b)": [ + "PRI-06.2" ], - "4-1-5": [ - "IAO-01", - "IAO-02" + "Section 48(4)(c)": [ + "PRI-06.2" ], - "4-2-3": [ - "IAO-01", - "IAO-02" + "Section 48(4)(d)": [ + "PRI-06.2" ], - "4-2-4": [ - "IAO-02" + "Section 48(5)": [ + "PRI-06.2" ], - "2-3-1": [ - "NET-01", - "NET-13" + "Section 48(6)": [ + "PRI-06.2" ], - "2-3-2": [ - "NET-01", - "NET-13" + "Section 48(6)(a)": [ + "PRI-06.2" ], - "2-4-5": [ - "NET-01", - "NET-03" + "Section 48(6)(b)": [ + "PRI-06.2" ], - "2-4-4": [ - "NET-06" + "Section 48(7)": [ + "PRI-06.2" ], - "2-13-1": [ - "PES-05", - "PES-05.1" + "Section 48(9)": [ + "PRI-06.2" ], - "1-4-1": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-06" + "Section 48(9)(a)": [ + "PRI-06.2" ], - "1-4-5": [ - "RSK-01.5", - "RSK-03", - "RSK-06" + "Section 48(9)(b)": [ + "PRI-06.2" ], - "1-4-2": [ - "RSK-03.1" + "Section 48(10)": [ + "PRI-06.2" ], - "1-4-4": [ - "RSK-03.1", - "RSK-04", - "THR-09", - "THR-10" + "Section 45(3)": [ + "PRI-06.4" ], - "1-4-3": [ - "RSK-04.1" + "Section 45(3)(a)": [ + "PRI-06.4" ], - "1-5-1": [ - "SEA-01" + "Section 45(3)(b)": [ + "PRI-06.4" ], - "1-9-1": [ - "SAT-01", - "SAT-02", - "SAT-03" + "Section 45(5)": [ + "PRI-06.4" ], - "1-9-2": [ - "SAT-02", - "SAT-03.6" + "Section 45(5)(a)": [ + "PRI-06.4" ], - "4-1-3": [ - "TDA-04.2" + "Section 45(5)(b)": [ + "PRI-06.4" ], - "2-14-3": [ - "TDA-06", - "TDA-06.5" + "Section 45(5)(c)": [ + "PRI-06.4" ], - "4-1-1": [ - "TPM-05" + "Section 45(5)(d)": [ + "PRI-06.4" ], - "4-2-5": [ - "TPM-05" + "Section 45(5)(e)": [ + "PRI-06.4" ], - "4-1-2": [ - "TPM-05.6" + "Section 52(6)": [ + "PRI-06.4" ], - "4-1-6": [ - "TPM-08", - "TPM-09" + "Section 53(6)": [ + "PRI-06.4" ], - "2-12-4": [ - "THR-01", - "THR-03", - "THR-03.1" + "Section 53(6)(a)": [ + "PRI-06.4" ], - "2-9-1": [ - "VPM-01", - "VPM-02", - "VPM-06" + "Section 53(6)(b)": [ + "PRI-06.4" ], - "2-9-2": [ - "VPM-05" + "Section 53(7)": [ + "PRI-06.4" ], - "2-10-1": [ - "VPM-07" + "Section 53(7)(a)": [ + "PRI-06.4" ], - "2-10-2": [ - "VPM-10" - ] - }, - "emea-sau-ecc-1-2018": { - "1-2-1": [ - "GOV-01" + "Section 53(7)(b)": [ + "PRI-06.4" ], - "1-3-2": [ - "GOV-01", - "CPL-02", - "CPL-03" + "Section 47(1)": [ + "PRI-06.5" ], - "1-3-1": [ - "GOV-02" + "Section 47(1)(a)": [ + "PRI-06.5" ], - "1-3-3": [ - "GOV-02", - "CFG-02" + "Section 47(1)(b)": [ + "PRI-06.5" ], - "1-1-3": [ - "GOV-03", - "PRM-01", - "PRM-02" + "Section 52(1)": [ + "PRI-06.7" ], - "1-3-4": [ - "GOV-03" + "Section 52(2)": [ + "PRI-06.7" ], - "1-6-4": [ - "GOV-03", - "PRM-03", - "PRM-04" + "Section 52(3)": [ + "PRI-06.7" ], - "1-9-6": [ - "GOV-03", - "HRS-01" + "Section 52(5)": [ + "PRI-06.7" ], - "1-10-5": [ - "GOV-03", - "SAT-01" + "Section 52(4)": [ + "PRI-06.8" ], - "2-2-4": [ - "GOV-03", - "IAC-01" + "Section 52(4)(a)": [ + "PRI-06.8" ], - "2-3-4": [ - "GOV-03", - "MON-01", - "MON-01.16", - "DCH-01", - "END-01", - "PES-01", - "VPM-01" + "Section 52(4)(b)": [ + "PRI-06.8" ], - "2-4-4": [ - "GOV-03", - "BCD-01", - "CFG-01", - "END-01", - "NET-01" + "Section 59(1)": [ + "PRI-07.1" ], - "2-5-4": [ - "GOV-03", - "CFG-01", - "NET-01", - "TDA-01" + "Section 59(2)": [ + "PRI-07.1" ], - "2-6-4": [ - "GOV-03", - "AST-01", - "HRS-01", - "HRS-05.3", - "MDM-01" + "Section 59(2)(a)": [ + "PRI-07.1" ], - "2-7-4": [ - "GOV-03", - "DCH-01" + "Section 59(2)(b)": [ + "PRI-07.1" ], - "2-8-4": [ - "GOV-03", - "CRY-01" + "Section 59(3)": [ + "PRI-07.1" ], - "2-9-4": [ - "GOV-03", - "BCD-01" + "Section 59(4)": [ + "PRI-07.1" ], - "2-10-4": [ - "GOV-03", - "THR-01", - "VPM-01" + "Section 59(5)": [ + "PRI-07.1" ], - "2-11-4": [ - "GOV-03", - "VPM-01" + "Section 59(5)(a)": [ + "PRI-07.1" ], - "2-12-4": [ - "GOV-03", - "MON-01", - "MON-01.16", - "MON-03.6" + "Section 59(5)(b)": [ + "PRI-07.1" ], - "2-13-4": [ - "GOV-03", - "IRO-01", - "THR-01" + "Section 59(5)(c)": [ + "PRI-07.1" ], - "2-14-4": [ - "GOV-03", - "PES-01" + "Section 59(5)(d)": [ + "PRI-07.1" ], - "2-15-4": [ - "GOV-03", - "WEB-01" + "Section 59(6)": [ + "PRI-07.1" ], - "3-1-4": [ - "GOV-03", - "BCD-01", - "BCD-06" + "Section 59(6)(a)": [ + "PRI-07.1" ], - "4-1-4": [ - "GOV-03", - "TPM-01" + "Section 59(6)(b)": [ + "PRI-07.1" ], - "4-2-4": [ - "GOV-03", - "CLD-01" + "Section 59(6)(c)": [ + "PRI-07.1" ], - "5-1-4": [ - "GOV-03", - "EMB-01" + "Section 59(6)(d)": [ + "PRI-07.1" ], - "1-2-2": [ - "GOV-04" + "Section 59(6)(d)(i)": [ + "PRI-07.1" ], - "1-4-1": [ - "GOV-04" + "Section 59(6)(d)(ii)": [ + "PRI-07.1" ], - "1-4-2": [ - "GOV-04" + "Section 59(6)(e)": [ + "PRI-07.1" ], - "1-5-2": [ - "GOV-04", - "RSK-01" + "Section 59(6)(f)": [ + "PRI-07.1" ], - "1-1-1": [ - "GOV-08", - "PRM-01.1" + "Section 59(7)": [ + "PRI-07.1" ], - "2-1-1": [ - "AST-01" + "Section 59(7A)": [ + "PRI-07.1" ], - "2-1-2": [ - "AST-01" + "Section 59(8)": [ + "PRI-07.1" ], - "2-6-1": [ - "AST-01", - "AST-16" + "Section 60": [ + "PRI-07.1" ], - "2-6-2": [ - "AST-01", - "AST-16" + "Section 60(a)": [ + "PRI-07.1" ], - "2-14-3-4": [ - "AST-09" + "Section 60(b)": [ + "PRI-07.1" ], - "2-9-1": [ - "BCD-01" + "Section 63": [ + "PRI-07.1" ], - "2-9-2": [ - "BCD-01" + "Section 58(1)": [ + "PRI-07.2" ], - "2-9-3": [ - "BCD-01", - "BCD-11" + "Section 58(2)": [ + "PRI-07.2" ], - "2-9-3-1": [ - "BCD-01" + "Section 58(3)": [ + "PRI-07.2" ], - "3-1-1": [ - "BCD-01" + "Section 53(1)": [ + "PRI-07.4" ], - "3-1-2": [ - "BCD-01" + "Section 53(1)(a)": [ + "PRI-07.4" ], - "3-1-3": [ - "BCD-01" + "Section 53(1)(b)": [ + "PRI-07.4" ], - "3-1-3-1": [ - "BCD-01" + "Section 53(2)": [ + "PRI-07.4" ], - "3-1-3-2": [ - "BCD-01", - "BCD-01.1", - "BCD-01.2" + "Section 53(3)": [ + "PRI-07.4" ], - "3-1-3-3": [ - "BCD-01" + "Section 53(4)": [ + "PRI-07.4" ], - "2-9-3-2": [ - "BCD-01.4", - "BCD-02", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3" + "Section 53(4A)": [ + "PRI-07.4" ], - "2-9-3-3": [ - "BCD-11.1" + "Section 53(4A)(a)": [ + "PRI-07.4" ], - "2-4-3-3": [ - "BCD-12", - "BCD-12.1" + "Section 53(4A)(b)": [ + "PRI-07.4" ], - "1-6-2": [ - "CHG-01" + "Section 53(5)": [ + "PRI-07.4" ], - "1-6-3-5": [ - "CHG-02", - "CHG-02.2" + "Section 61(1)": [ + "PRI-14" ], - "1-6-2-1": [ - "CHG-02.2" + "Section 61(2)": [ + "PRI-14" ], - "1-6-2-2": [ - "CHG-02.3", - "CFG-01", - "CFG-02.1" + "Section 61(2)(a)": [ + "PRI-14" ], - "4-2-1": [ - "CLD-01" + "Section 61(2)(b)": [ + "PRI-14" ], - "4-2-2": [ - "CLD-01" + "Section 61(2)(c)": [ + "PRI-14" ], - "4-2-3": [ - "CLD-01" + "Section 61(2)(d)": [ + "PRI-14" ], - "4-2-3-2": [ - "CLD-01", - "CLD-02" + "Section 61(2)(e)": [ + "PRI-14" ], - "4-1-3-2": [ - "CLD-09" + "Section 61(2)(f)": [ + "PRI-14" ], - "4-2-3-3": [ - "CLD-09" + "Section 61(2)(f)(i)": [ + "PRI-14" ], - "1-7-1": [ - "CPL-01" + "Section 61(2)(f)(ii)": [ + "PRI-14" ], - "1-7-2": [ - "CPL-01" + "Section 61(2)(g)": [ + "PRI-14" ], - "1-8-1": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "Section 61(2)(h)": [ + "PRI-14" ], - "1-8-3": [ - "CPL-02.1" + "Section 61(2)(h)(i)": [ + "PRI-14" ], - "1-8-2": [ - "CPL-03.1" + "Section 61(2)(j)": [ + "PRI-14" ], - "2-4-1": [ - "CFG-02", - "CFG-04.2" + "Section 61(2)(k)": [ + "PRI-14" ], - "2-4-2": [ - "CFG-02" + "Section 61(3)": [ + "PRI-14" ], - "5-1-3-7": [ - "CFG-02", - "CFG-02.5" + "Section 61(4)": [ + "PRI-14" ], - "2-5-3-5": [ - "CFG-03", - "NET-04", - "TDA-02.1" + "Section 61(4)(a)": [ + "PRI-14" ], - "2-5-3-3": [ - "CFG-04.2", - "NET-18" + "Section 61(4)(b)": [ + "PRI-14" ], - "2-12-1": [ - "MON-01", - "MON-01.16" + "Section 61(4)(c)": [ + "PRI-14" ], - "2-12-2": [ - "MON-01", - "MON-01.16" + "Section 61(4)(d)": [ + "PRI-14" ], - "2-12-3": [ - "MON-01", - "MON-01.16" + "Section 61(4)(e)": [ + "PRI-14" ], - "5-1-3-3": [ - "MON-01", - "MON-01.2", - "MON-01.16" + "Section 61(4)(f)": [ + "PRI-14" ], - "2-5-3-6": [ - "MON-01.1", - "NET-08" + "Section 61(5)": [ + "PRI-14" ], - "2-12-3-3": [ - "MON-01.2" + "Section 62(1)": [ + "PRI-14" ], - "2-12-3-1": [ - "MON-01.4", - "MON-01.12" + "Section 62(1)(a)": [ + "PRI-14" ], - "2-12-3-4": [ - "MON-01.8", - "MON-02.2" + "Section 62(1)(b)": [ + "PRI-14" ], - "2-12-3-2": [ - "MON-01.14", - "MON-01.15", - "MON-03.3" + "Section 62(1)(c)": [ + "PRI-14" ], - "2-12-3-5": [ - "MON-04", - "MON-08", - "MON-10" + "Section 62(1)(d)": [ + "PRI-14" ], - "2-3-3-4": [ - "MON-07", - "MON-07.1" + "Section 62(1)(e)": [ + "PRI-14" ], - "2-14-3-3": [ - "MON-08", - "MON-10", - "PES-03.3" + "Section 62(1)(f)": [ + "PRI-14" ], - "2-8-1": [ - "CRY-01" + "Section 62(2)": [ + "PRI-14" ], - "2-8-2": [ - "CRY-01" + "Section 62(2)(a)": [ + "PRI-14" ], - "2-8-3": [ - "CRY-01" + "Section 62(2)(b)": [ + "PRI-14" ], - "2-8-3-1": [ - "CRY-01", - "CRY-02" + "Section 62(3)": [ + "PRI-14" ], - "2-8-3-3": [ - "CRY-03", - "CRY-05" + "Section 62(3)(a)": [ + "PRI-14" ], - "2-5-3-4": [ - "CRY-07" + "Section 62(3)(b)": [ + "PRI-14" ], - "2-8-3-2": [ - "CRY-09" + "Section 62(3)(b)(i)": [ + "PRI-14" ], - "2-1-6": [ - "DCH-01" + "Section 62(3)(b)(ii)": [ + "PRI-14" ], - "2-3-3": [ - "DCH-01" + "Section 62(4)": [ + "PRI-14" ], - "2-3-3-2": [ - "DCH-01", - "DCH-06", - "DCH-10", - "DCH-12", - "PES-03.4" + "Section 62(4)(a)": [ + "PRI-14" ], - "2-7-1": [ - "DCH-01" + "Section 62(4)(b)": [ + "PRI-14" ], - "2-7-2": [ - "DCH-01" + "Section 62(4)(c)": [ + "PRI-14" ], - "2-7-3": [ - "DCH-01" + "Section 62(4)(d)": [ + "PRI-14" ], - "2-7-3-3": [ - "DCH-01" + "Section 62(5)": [ + "PRI-14" ], - "2-7-3-1": [ - "DCH-01.1" + "Section 44(5)": [ + "PRI-17" ], - "2-1-5": [ - "DCH-02" + "Section 44(5)(a)": [ + "PRI-17" ], - "2-7-3-2": [ - "DCH-02" + "Section 44(5)(b)": [ + "PRI-17" ], - "4-2-3-1": [ - "DCH-02", - "DCH-13", - "DCH-24", - "PRI-06.6", - "SEA-05" + "Section 44(5)(c)": [ + "PRI-17" ], - "5-1-3-5": [ - "DCH-13.2" + "Section 44(5)(d)": [ + "PRI-17" ], - "5-1-1": [ - "EMB-01" + "Section 44(5)(e)": [ + "PRI-17" ], - "5-1-2": [ - "EMB-01" + "Section 44(6)": [ + "PRI-17" ], - "5-1-3": [ - "EMB-01" + "Section 44(7)(a)": [ + "PRI-17.3" ], - "2-3-3-1": [ - "END-04" + "Section 44(7)(b)": [ + "PRI-17.3" ], - "2-4-3-4": [ - "END-04", - "END-04.4" + "Section 45(7)(a)": [ + "PRI-17.3" ], - "5-1-3-10": [ - "END-04" + "Section 45(7)(b)": [ + "PRI-17.3" ], - "2-4-3-1": [ - "END-08" + "Section 50(1)": [ + "PRI-19" ], - "1-9-1": [ - "HRS-01", - "HRS-10" + "Section 50(1)(a)": [ + "PRI-19" ], - "1-9-2": [ - "HRS-02", - "HRS-03.2" + "Section 50(1)(b)": [ + "PRI-19" ], - "1-9-3": [ - "HRS-04", - "HRS-06" + "Section 50(1)(b)(i)": [ + "PRI-19" ], - "1-9-3-2": [ - "HRS-04", - "HRS-04.1", - "HRS-05" + "Section 50(1)(b)(ii)": [ + "PRI-19" ], - "1-9-4": [ - "HRS-04.2" + "Section 50(2)": [ + "PRI-19" ], - "1-9-4-1": [ - "HRS-04.2" + "Section 50C(1)": [ + "PRI-19" ], - "1-9-3-1": [ - "HRS-05", - "HRS-05.1", - "HRS-06.1" + "Section 50C(1)(a)": [ + "PRI-19" ], - "1-9-4-2": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "HRS-05.3", - "HRS-05.4", - "HRS-05.5" + "Section 50C(1)(b)": [ + "PRI-19" ], - "2-1-3": [ - "HRS-05.1", - "HRS-05.3", - "HRS-05.4" + "Section 50C(2)": [ + "PRI-19" ], - "2-1-4": [ - "HRS-05.1" + "Section 50C(2)(a)": [ + "PRI-19" ], - "2-15-3-4": [ - "HRS-05.1", - "HRS-05.3" + "Section 50C(2)(b)": [ + "PRI-19" ], - "2-2-1": [ - "IAC-01" + "Section 50C(2)(c)": [ + "PRI-19" ], - "2-2-2": [ - "IAC-01" + "Section 50C(2)(d)": [ + "PRI-19" ], - "2-2-3": [ - "IAC-02", - "IAC-03", - "IAC-05" + "Section 50C(3)": [ + "PRI-19" ], - "2-2-3-2": [ - "IAC-06" + "Section 50C(3)(a)": [ + "PRI-19" ], - "2-4-3-2": [ - "IAC-06" + "Section 50C(3)(b)": [ + "PRI-19" ], - "2-15-3-5": [ - "IAC-06" + "Section 50C(3)(c)": [ + "PRI-19" ], - "2-2-3-3": [ - "IAC-08" + "Section 50C(4)": [ + "PRI-19" ], - "2-2-3-1": [ - "IAC-09.1", - "IAC-10", - "IAC-10.1" + "Section 50C(4)(a)": [ + "PRI-19" ], - "2-2-3-4": [ - "IAC-16" + "Section 50C(4)(b)": [ + "PRI-19" ], - "1-9-5": [ - "IAC-17" + "Section 50C(4)(c)": [ + "PRI-19" ], - "2-2-3-5": [ - "IAC-17" + "Section 50C(4)(d)": [ + "PRI-19" ], - "2-13-1": [ - "IRO-01", - "THR-01" + "Section 50C(4)(e)": [ + "PRI-19" ], - "2-13-2": [ - "IRO-01", - "THR-01" + "Section 50C(5)": [ + "PRI-19" ], - "2-13-3": [ - "IRO-01", - "THR-01" + "Section 64(1)": [ + "RSK-10" ], - "2-13-3-2": [ - "IRO-01", - "IRO-02", - "IRO-04" + "Section 64(2)": [ + "RSK-10" ], - "2-13-3-1": [ - "IRO-04" + "Section 64(3)": [ + "RSK-10" ], - "2-13-3-3": [ - "IRO-10", - "IRO-10.2" + "Section 64(3)(a)": [ + "RSK-10" ], - "2-13-3-4": [ - "IRO-10", - "IRO-10.2" + "Section 64(3)(b)": [ + "RSK-10" ], - "2-6-3": [ - "MDM-01" + "Section 64(3)(c)": [ + "RSK-10" ], - "2-6-3-1": [ - "MDM-01", - "MDM-03" + "Section 64(3)(d)": [ + "RSK-10" ], - "2-6-3-2": [ - "MDM-01", - "MDM-02" + "Section 64(4)": [ + "RSK-10" + ] + }, + "apac-aus-essential-8-2024": { + "ML1-P1": [ + "AST-02", + "TDA-17", + "VPM-05", + "VPM-06", + "VPM-06.1" ], - "2-6-3-3": [ - "MDM-01", - "MDM-05" + "ML1-P2": [ + "AST-02", + "TDA-17", + "VPM-05", + "VPM-06", + "VPM-06.1" ], - "2-6-3-4": [ - "MDM-01" + "ML2-P1": [ + "AST-02", + "TDA-17", + "VPM-05", + "VPM-06", + "VPM-06.1" ], - "5-1-3-6": [ - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07" + "ML2-P2": [ + "AST-02", + "TDA-17", + "VPM-05", + "VPM-06", + "VPM-06.1" ], - "2-5-1": [ - "NET-01" + "ML3-P1": [ + "AST-02", + "TDA-17", + "VPM-05", + "VPM-06", + "VPM-06.1" ], - "2-5-2": [ - "NET-01" + "ML3-P2": [ + "AST-02", + "SEA-07.1", + "TDA-17", + "VPM-05", + "VPM-06", + "VPM-06.1" ], - "2-5-3-1": [ - "NET-02" + "ML2-P4": [ + "AST-27", + "MON-02.2", + "MON-03.3", + "MON-08", + "MON-17", + "IAC-08", + "IAC-15.3", + "IAC-15.9", + "IAC-16", + "IAC-16.4", + "IAC-21", + "IAC-21.2", + "IAC-21.3", + "IRO-02", + "IRO-10", + "SEA-22" ], - "5-1-3-4": [ - "NET-03.7" + "ML3-P4": [ + "AST-27", + "CFG-02", + "MON-02.2", + "MON-03.3", + "MON-08", + "MON-17", + "IAC-08", + "IAC-15.3", + "IAC-15.9", + "IAC-16", + "IAC-16.4", + "IAC-20.4", + "IAC-21", + "IAC-21.2", + "IAC-21.3", + "IRO-02", + "IRO-10", + "SEA-22" ], - "5-1-3-2": [ - "NET-05.1", - "NET-06" + "ML1-P8": [ + "BCD-01.4", + "BCD-11", + "BCD-11.2", + "BCD-11.5", + "BCD-11.9", + "BCD-11.10" ], - "5-1-3-1": [ - "NET-05.2", - "NET-06" + "ML2-P8": [ + "BCD-01.4", + "BCD-11", + "BCD-11.2", + "BCD-11.5", + "BCD-11.9", + "BCD-11.10" ], - "2-4-3-5": [ - "NET-10" + "ML3-P8": [ + "BCD-01.4", + "BCD-11", + "BCD-11.2", + "BCD-11.5", + "BCD-11.9", + "BCD-11.10" ], - "2-5-3-7": [ - "NET-10" + "ML1-P6": [ + "CFG-02" ], - "2-5-3-8": [ - "NET-18", - "NET-18.1" + "ML1-P7": [ + "CFG-02" ], - "2-3-1": [ - "PES-01" + "ML2-P5": [ + "CFG-02", + "CFG-02.1", + "CFG-03.2", + "CFG-03.3", + "MON-02.2", + "MON-03", + "MON-08", + "MON-17", + "IRO-02", + "IRO-10" ], - "2-3-2": [ - "PES-01" + "ML2-P6": [ + "CFG-02" ], - "2-14-1": [ - "PES-01" + "ML2-P7": [ + "CFG-02", + "MON-02.2", + "MON-08", + "MON-17", + "IRO-02", + "IRO-10" ], - "2-14-2": [ - "PES-01" + "ML3-P5": [ + "CFG-02", + "CFG-02.1", + "CFG-03.2", + "CFG-03.3", + "MON-02.2", + "MON-03", + "MON-08", + "MON-17", + "IRO-02", + "IRO-10" ], - "2-14-3": [ - "PES-01" + "ML3-P6": [ + "CFG-02", + "CFG-02.1" ], - "2-14-3-1": [ - "PES-02", - "PES-03", - "PES-03.1" + "ML3-P7": [ + "CFG-02", + "MON-02.2", + "MON-03.3", + "MON-08", + "MON-17", + "IRO-02", + "IRO-10" ], - "2-14-3-5": [ - "PES-04", - "PES-04.1" + "ML1-P5": [ + "CFG-03.3" ], - "2-14-3-2": [ - "PES-05", - "PES-05.1" + "ML2-P3": [ + "MON-02.2", + "MON-03", + "MON-08", + "MON-17", + "IAC-06", + "IAC-06.2", + "IAC-06.3", + "IRO-02", + "IRO-10" ], - "1-2-3": [ - "PRM-01" + "ML3-P3": [ + "MON-02.2", + "MON-03", + "MON-08", + "MON-17", + "IAC-06", + "IAC-06.2", + "IAC-06.3", + "IRO-02", + "IRO-10" ], - "1-1-2": [ - "PRM-01.1" + "ML1-P3": [ + "IAC-06" ], - "1-6-1": [ - "PRM-04", - "PRM-05" + "ML1-P4": [ + "IAC-08", + "IAC-16", + "IAC-16.4", + "IAC-21", + "IAC-21.2", + "IAC-21.3" + ] + }, + "apac-aus-privacy-principles-2026": { + "1.1.3": [ + "GOV-02", + "PRI-02" ], - "1-5-1": [ - "RSK-01" + "1.1.2.a": [ + "CPL-01" ], - "1-5-4": [ - "RSK-01", - "RSK-07" + "1.1.2.b": [ + "CPL-07" ], - "1-5-3": [ - "RSK-04" + "3.9.2": [ + "DCH-03.1" ], - "1-5-3-2": [ - "RSK-07", - "TDA-09", - "TDA-15" + "3.9.2.a": [ + "DCH-03.1" ], - "1-5-3-4": [ - "RSK-08", - "RSK-10", - "TDA-09", - "TDA-15", - "TPM-04.1" + "3.9.2.b": [ + "DCH-03.1" ], - "1-5-3-3": [ - "RSK-09", - "RSK-09.1", - "TPM-01" + "3.9.2.c": [ + "DCH-03.1" ], - "1-6-3-4": [ - "SEA-01", - "SEA-02", - "SEA-03", - "TDA-05" + "3.9.2.d": [ + "DCH-03.1" ], - "2-4-3": [ - "SEA-01", - "SEA-02", - "SEA-03" + "3.9.2.e": [ + "DCH-03.1" ], - "2-15-3-3": [ - "SEA-01", - "SEA-02", - "SEA-03", - "TDA-02.1" + "3.9.2.f": [ + "DCH-03.1" ], - "1-6-3-2": [ - "SEA-08.1" + "3.9.3": [ + "DCH-03.1" ], - "1-10-1": [ - "SAT-01" + "3.9.3.a": [ + "DCH-03.1" ], - "1-10-2": [ - "SAT-02" + "3.9.3.b": [ + "DCH-03.1" ], - "1-10-3": [ - "SAT-02", - "SAT-02.2", - "SAT-03" + "3.9.3.c": [ + "DCH-03.1" ], - "1-10-3-1": [ - "SAT-02", - "SAT-03" + "3.8.1": [ + "PRI-01.5" ], - "1-10-3-2": [ - "SAT-02", - "SAT-03" + "3.8.1.a": [ + "PRI-01.5" ], - "1-10-3-3": [ - "SAT-02", - "SAT-03" + "3.8.1.b": [ + "PRI-01.5" ], - "1-10-3-4": [ - "SAT-02", - "SAT-03" + "3.8.2": [ + "PRI-01.5" ], - "1-10-4": [ - "SAT-03" + "3.8.2.a": [ + "PRI-01.5" ], - "1-10-4-1": [ - "SAT-03", - "SAT-03.5" + "3.8.2.a.i": [ + "PRI-01.5" ], - "1-10-4-2": [ - "SAT-03", - "SAT-03.3" + "3.8.2.a.ii": [ + "PRI-01.5" ], - "1-10-4-3": [ - "SAT-03" + "3.8.2.b": [ + "PRI-01.5" ], - "1-6-3": [ - "TDA-01" + "3.8.2.b.i": [ + "PRI-01.5" ], - "1-6-3-1": [ - "TDA-06" + "3.8.2.b.ii": [ + "PRI-01.5" ], - "2-5-3-2": [ - "TDA-08" + "3.8.2.c": [ + "PRI-01.5" ], - "1-6-3-3": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5" + "3.8.2.d": [ + "PRI-01.5" ], - "4-1-1": [ - "TPM-01" + "3.8.2.e": [ + "PRI-01.5" ], - "4-1-2": [ - "TPM-01", - "TPM-05" + "3.8.2.f": [ + "PRI-01.5" ], - "4-1-3": [ - "TPM-01" + "3.8.2.f.i": [ + "PRI-01.5" ], - "4-1-3-1": [ - "TPM-04.1" + "3.8.2.f.ii": [ + "PRI-01.5" ], - "4-1-2-1": [ - "TPM-05" + "4.11.1": [ + "PRI-01.6" ], - "4-1-2-2": [ - "TPM-05", - "TPM-11" + "4.11.1.a": [ + "PRI-01.6" ], - "4-1-2-3": [ - "TPM-05", - "TPM-09" + "4.11.1.b": [ + "PRI-01.6" + ], + "3.6.1": [ + "PRI-01.7", + "PRI-05.4" ], - "2-10-3-5": [ - "THR-03", - "VPM-05.4" + "1.1.2": [ + "PRI-01.11" ], - "2-13-3-5": [ - "THR-03" + "2.3.1": [ + "PRI-01.11", + "PRI-04.1" ], - "2-10-1": [ - "VPM-01" + "2.3.2": [ + "PRI-01.11", + "PRI-04.1" ], - "2-10-2": [ - "VPM-01" + "2.3.5": [ + "PRI-01.11" ], - "2-10-3": [ - "VPM-01" + "2.3.7": [ + "PRI-01.11" ], - "2-11-1": [ - "VPM-01" + "2.4.1": [ + "PRI-01.11" ], - "2-11-2": [ - "VPM-01" + "2.4.1.a": [ + "PRI-01.11" ], - "2-11-3": [ - "VPM-01" + "2.4.1.b": [ + "PRI-01.11" ], - "5-1-3-8": [ - "VPM-01", - "VPM-01.1", - "VPM-02" + "2.4.2": [ + "PRI-01.11" ], - "2-11-3-1": [ - "VPM-01.1", - "VPM-06.2", - "VPM-07" + "2.4.3": [ + "PRI-01.11" ], - "2-10-3-3": [ - "VPM-02", - "VPM-04" + "2.4.3.a": [ + "PRI-01.11" ], - "2-10-3-2": [ - "VPM-03" + "2.4.3.b": [ + "PRI-01.11" ], - "2-3-3-3": [ - "VPM-05" + "2.4.4": [ + "PRI-01.11" ], - "2-10-3-4": [ - "VPM-05" + "3.9.1": [ + "PRI-01.11" ], - "5-1-3-9": [ - "VPM-05" + "3.9.1.a": [ + "PRI-01.11" ], - "2-10-3-1": [ - "VPM-06" + "3.9.1.b": [ + "PRI-01.11" ], - "2-15-1": [ - "WEB-01" + "5.12.7": [ + "PRI-01.11" ], - "2-15-2": [ - "WEB-01" + "5.12.8": [ + "PRI-01.11" ], - "2-15-3": [ - "WEB-01" + "5.12.8.a": [ + "PRI-01.11" ], - "2-15-3-1": [ - "WEB-03" - ] - }, - "emea-sau-otcc-1-2022": { - "1-1": [ - "GOV-01", - "GOV-02" + "5.12.8.b": [ + "PRI-01.11" ], - "1-1-1": [ - "GOV-02" + "1.1.4": [ + "PRI-02" ], - "1-1-3": [ - "GOV-03" + "1.1.4.a": [ + "PRI-02" ], - "1-2": [ - "GOV-04", - "HRS-03" + "1.1.4.b": [ + "PRI-02" ], - "1-2-1-2": [ - "GOV-04" + "1.1.4.c": [ + "PRI-02" ], - "2-3": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "NET-01" + "1.1.4.d": [ + "PRI-02" ], - "2-3-2": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "EMB-01", - "EMB-10" + "1.1.4.e": [ + "PRI-02" ], - "2-1": [ - "AST-01", - "AST-02" + "1.1.4.f": [ + "PRI-02" ], - "2-1-1-4": [ - "AST-01.2" + "1.1.4.g": [ + "PRI-02" ], - "2-1-1": [ - "AST-02", - "AST-02.9" + "1.1.5": [ + "PRI-02" ], - "2-1-1-3": [ - "AST-02", - "AST-02.9" + "1.1.5.a": [ + "PRI-02" ], - "2-1-1-1": [ - "AST-02.1" + "1.1.5.b": [ + "PRI-02" ], - "2-3-1-11": [ - "AST-02.2", - "CFG-02.8", - "CFG-03.2", - "CFG-05.1", - "MON-16.3" + "1.1.6": [ + "PRI-02" ], - "2-4-1-16": [ - "AST-02.8", - "AST-04", - "AST-04.2", - "EMB-13", - "NET-04" + "2.5.1": [ + "PRI-02" ], - "2-1-1-2": [ - "AST-02.9" + "2.5.1.a": [ + "PRI-02" ], - "2-6-1-4": [ - "AST-05", - "DCH-02.1", - "DCH-03.1", - "DCH-07", - "DCH-07.1" + "2.5.1.b": [ + "PRI-02" ], - "2-6-1-3": [ - "AST-09", - "AST-30", - "DCH-08", - "DCH-09" + "2.5.2": [ + "PRI-02" ], - "3-1": [ - "BCD-01" + "2.5.2.a": [ + "PRI-02" ], - "3-1-1": [ - "BCD-01" + "2.5.2.b": [ + "PRI-02" ], - "3-1-1-1": [ - "BCD-01" + "2.5.2.b.i": [ + "PRI-02" ], - "3-1-1-2": [ - "BCD-01", - "BCD-11.7" + "2.5.2.b.ii": [ + "PRI-02" ], - "3-1-1-3": [ - "BCD-01" + "2.5.2.c": [ + "PRI-02" ], - "3-1-1-4": [ - "BCD-01" + "2.5.2.d": [ + "PRI-02" ], - "3-1-1-5": [ - "BCD-01", - "EMB-19" + "2.5.2.e": [ + "PRI-02" ], - "3-1-1-6": [ - "BCD-01", - "BCD-03.1", - "BCD-04" + "2.5.2.f": [ + "PRI-02" ], - "3-1-2": [ - "BCD-01" + "2.5.2.g": [ + "PRI-02" ], - "2-1-1-5": [ - "BCD-02" + "2.5.2.h": [ + "PRI-02" ], - "2-8": [ - "BCD-11" + "2.5.2.i": [ + "PRI-02" ], - "2-8-1": [ - "BCD-11" + "2.5.2.j": [ + "PRI-02" ], - "2-8-1-1": [ - "BCD-11" + "1.2.1": [ + "PRI-02.13" ], - "2-8-1-2": [ - "BCD-11" + "2.3.6": [ + "PRI-04.2" ], - "2-8-1-3": [ - "BCD-11" + "2.3.6.a": [ + "PRI-04.2" ], - "2-8-1-4": [ - "BCD-11", - "BCD-11.2", - "BCD-11.4", - "BCD-11.6" + "2.3.6.a.ii": [ + "PRI-04.2" ], - "2-8-2": [ - "BCD-11" + "2.3.6.b": [ + "PRI-04.2" ], - "1-5": [ - "CHG-01", - "CHG-02" + "4.11.2": [ + "PRI-05" ], - "1-5-1": [ - "CHG-01", - "CHG-02" + "4.11.2.a": [ + "PRI-05" ], - "1-5-2": [ - "CHG-01", - "CHG-02", - "CHG-02.3", - "CHG-03", - "EMB-06" + "4.11.2.b": [ + "PRI-05" ], - "1-5-3": [ - "CHG-02", - "EMB-06" + "4.11.2.c": [ + "PRI-05" ], - "1-5-3-1": [ - "CHG-02" + "4.11.2.d": [ + "PRI-05" ], - "1-5-3-4": [ - "CHG-02.1", - "CHG-04" + "4.10.1": [ + "PRI-05.2" ], - "1-5-3-2": [ - "CHG-02.2" + "4.10.2": [ + "PRI-05.2" ], - "1-5-4": [ - "CHG-02.4", - "CHG-03", - "CHG-04.1", - "MON-01.7", - "EMB-05", - "EMB-06", - "EMB-07", - "END-06" + "2.3.3": [ + "PRI-05.4" ], - "2-2-1-6": [ - "CHG-04.3" + "2.3.3.a": [ + "PRI-05.4" ], - "1-6": [ - "CPL-01.1", - "CPL-02", - "CPL-03", - "EMB-01", - "EMB-10" + "2.3.3.a.i": [ + "PRI-05.4" ], - "1-6-1": [ - "CPL-01.1", - "CPL-02", - "CPL-03", - "CPL-03.1", - "EMB-10" + "2.3.3.a.ii": [ + "PRI-05.4" ], - "1-6-2": [ - "CPL-03", - "CPL-03.1", - "EMB-10" + "2.3.3.b": [ + "PRI-05.4" ], - "2-2-1-5": [ - "CFG-02", - "CFG-02.5", - "CFG-03" + "2.3.4": [ + "PRI-05.4" ], - "2-3-1-1": [ - "CFG-02", - "NET-01", - "NET-02", - "NET-03" + "2.3.4.a": [ + "PRI-05.4" ], - "2-3-1-7": [ - "CFG-02", - "CFG-02.5", - "CFG-02.9", - "IAC-20.4" + "2.3.4.b": [ + "PRI-05.4" ], - "2-3-1-2": [ - "CFG-02.1" + "2.3.4.c": [ + "PRI-05.4" ], - "2-3-1-4": [ - "CFG-03", - "IAC-21" + "2.3.4.d": [ + "PRI-05.4" ], - "2-3-1-6": [ - "CFG-03.3", - "EMB-06" + "2.3.4.d.i": [ + "PRI-05.4" ], - "2-11": [ - "MON-01", - "MON-01.16" + "2.3.4.d.ii": [ + "PRI-05.4" ], - "2-11-1": [ - "MON-01", - "MON-01.16" + "2.3.4.e": [ + "PRI-05.4" ], - "2-11-2": [ - "MON-01", - "MON-01.16", - "MON-02.2" + "2.3.4.e.i": [ + "PRI-05.4" ], - "2-11-1-3": [ - "MON-02", - "MON-02.7" + "2.3.4.e.ii": [ + "PRI-05.4" ], - "2-11-1-9": [ - "MON-02", - "MON-02.2" + "3.6.1.a": [ + "PRI-05.4" ], - "2-11-1-4": [ - "MON-02.1", - "MON-02.3" + "3.6.1.b": [ + "PRI-05.4" ], - "2-11-1-5": [ - "MON-02.1", - "MON-02.3" + "3.6.2": [ + "PRI-05.4" ], - "2-11-1-6": [ - "MON-02.1", - "MON-02.3" + "3.6.2.a": [ + "PRI-05.4" ], - "2-11-1-7": [ - "MON-02.1", - "MON-02.3" + "3.6.2.a.i": [ + "PRI-05.4" ], - "2-11-1-8": [ - "MON-02.1", - "MON-02.3" + "3.6.2.a.ii": [ + "PRI-05.4" ], - "2-11-1-10": [ - "MON-02.1", - "MON-02.3" + "3.6.2.b": [ + "PRI-05.4" ], - "2-11-1-1": [ - "MON-02.7" + "3.6.2.c": [ + "PRI-05.4" ], - "2-11-1-2": [ - "MON-02.7", - "MON-05" + "3.6.2.d": [ + "PRI-05.4" ], - "2-3-1-10": [ - "MON-08" + "3.6.2.e": [ + "PRI-05.4" ], - "2-3-1-12": [ - "MON-16", - "MON-16.3", - "IRO-03", - "SAT-03.2" + "3.6.3": [ + "PRI-05.4" ], - "2-2-1-4": [ - "CRY-01", - "CRY-03", - "CRY-04", - "EMB-07", - "EMB-13", - "IAC-24", - "IAC-25" + "3.6.4": [ + "PRI-05.4" ], - "2-7": [ - "CRY-01" + "3.6.4.a": [ + "PRI-05.4" ], - "2-7-1": [ - "CRY-01" + "3.6.4.b": [ + "PRI-05.4" ], - "2-7-2": [ - "CRY-01", - "EMB-10" + "3.7.1": [ + "PRI-05.4" ], - "2-3-1-8": [ - "CRY-05.1", - "DCH-13.2", - "END-04", - "END-04.7" + "3.7.2": [ + "PRI-05.4" ], - "2-3-1-9": [ - "CRY-05.1", - "DCH-13.2" + "3.7.2.a": [ + "PRI-05.4" ], - "2-6": [ - "DCH-01" + "3.7.2.b": [ + "PRI-05.4" ], - "2-6-1": [ - "DCH-01" + "3.7.2.c": [ + "PRI-05.4" ], - "2-6-1-1": [ - "DCH-01", - "DCH-01.2", - "DCH-02" + "3.7.2.d": [ + "PRI-05.4" ], - "2-6-2": [ - "DCH-01" + "3.7.3": [ + "PRI-05.4" ], - "1-1-2": [ - "EMB-01", - "SEA-01", - "SEA-02", - "SEA-03", - "TDA-01", - "TDA-01.1", - "TDA-04" + "3.7.3.a": [ + "PRI-05.4" ], - "2-1-2": [ - "EMB-01", - "EMB-10" + "3.7.3.a.i": [ + "PRI-05.4" ], - "2-3-1-5": [ - "EMB-06" + "3.7.3.a.ii": [ + "PRI-05.4" ], - "2-9-2": [ - "EMB-10", - "VPM-01" + "3.7.3.b": [ + "PRI-05.4" ], - "2-2-1-7": [ - "EMB-13", - "MNT-05", - "NET-14" + "3.7.3.b.i": [ + "PRI-05.4" ], - "2-4-1": [ - "EMB-13", - "NET-01" + "3.7.3.b.ii": [ + "PRI-05.4" ], - "2-4-1-1": [ - "EMB-13", - "NET-06", - "NET-06.3" + "3.7.3.c": [ + "PRI-05.4" ], - "2-4-1-2": [ - "EMB-13", - "NET-02.3", - "NET-03", - "NET-03.8", - "NET-06" + "3.7.3.d": [ + "PRI-05.4" ], - "2-4-1-3": [ - "EMB-13", - "NET-06", - "NET-06.4" + "3.7.3.d.i": [ + "PRI-05.4" ], - "2-4-1-4": [ - "EMB-13", - "NET-15" + "3.7.3.d.ii": [ + "PRI-05.4" ], - "2-4-1-5": [ - "EMB-13", - "NET-06", - "NET-15" + "3.7.3.e": [ + "PRI-05.4" ], - "2-4-1-6": [ - "EMB-13", - "NET-03", - "NET-04", - "NET-04.1" + "3.7.4": [ + "PRI-05.4" ], - "2-4-1-7": [ - "EMB-13", - "NET-04", - "NET-06.5" + "3.7.5": [ + "PRI-05.4" ], - "2-4-1-8": [ - "EMB-13", - "NET-04", - "NET-04.1" + "3.7.5.a": [ + "PRI-05.4" ], - "2-4-1-9": [ - "EMB-13", - "NET-06.4" + "3.7.5.b": [ + "PRI-05.4" ], - "2-4-1-10": [ - "EMB-13", - "NET-04", - "NET-06", - "NET-06.4", - "WEB-02" + "3.7.5.c": [ + "PRI-05.4" ], - "2-4-1-11": [ - "EMB-13", - "NET-06.4" + "3.7.6": [ + "PRI-06" ], - "2-4-1-12": [ - "EMB-13", - "NET-06.4" + "3.7.6.a": [ + "PRI-06" ], - "2-4-1-13": [ - "EMB-13", - "NET-06.4", - "WEB-02" + "3.7.6.b": [ + "PRI-06" ], - "2-4-1-14": [ - "EMB-13", - "NET-04", - "NET-04.1" + "3.7.6.c": [ + "PRI-06" ], - "2-4-1-15": [ - "EMB-13", - "EMB-14", - "VPM-05" + "3.7.6.d": [ + "PRI-06" ], - "1-5-3-3": [ - "EMB-14" + "3.7.6.e": [ + "PRI-06" ], - "2-5": [ - "END-01", - "MDM-01" + "3.7.7": [ + "PRI-06" ], - "2-5-1": [ - "END-01", - "MDM-01" + "3.7.7.a": [ + "PRI-06" ], - "2-5-1-1": [ - "END-01", - "MDM-01" + "3.7.7.b": [ + "PRI-06" ], - "2-5-1-2": [ - "END-01", - "MDM-01" + "5.12.1": [ + "PRI-06" ], - "2-5-1-3": [ - "END-01", - "MDM-01" + "5.13.1": [ + "PRI-06.1" ], - "2-5-1-4": [ - "END-01", - "MDM-01", - "MDM-07" + "5.13.1.a": [ + "PRI-06.1" ], - "2-5-1-5": [ - "END-01", - "MDM-01" + "5.13.1.b": [ + "PRI-06.1" ], - "2-5-2": [ - "END-01", - "MDM-01", - "NET-01" + "5.13.1.b.i": [ + "PRI-06.1" ], - "1-7": [ - "HRS-01" + "5.13.2": [ + "PRI-06.2" ], - "1-7-2": [ - "HRS-01" + "5.13.2.a": [ + "PRI-06.2" ], - "1-8": [ - "HRS-01", - "HRS-04.2", - "SAT-01", - "SAT-02" + "5.13.2.b": [ + "PRI-06.2" ], - "1-2-1": [ - "HRS-03" + "5.13.3": [ + "PRI-06.2" ], - "1-2-1-1": [ - "HRS-03", - "TPM-05.4" + "5.13.3.a": [ + "PRI-06.2" ], - "1-7-1": [ - "HRS-04", - "HRS-04.1" + "5.13.3.b": [ + "PRI-06.2" ], - "2-2": [ - "IAC-01" + "5.13.3.c": [ + "PRI-06.2" ], - "2-2-1": [ - "IAC-01" + "5.12.3": [ + "PRI-06.4" ], - "2-2-1-10": [ - "IAC-07.1", - "IAC-07.2", - "IAC-15", - "IAC-17" + "5.12.3.a": [ + "PRI-06.4" ], - "2-2-1-11": [ - "IAC-07.2" + "5.12.3.b": [ + "PRI-06.4" ], - "2-2-1-8": [ - "IAC-10", - "IAC-10.1" + "5.12.3.c": [ + "PRI-06.4" ], - "2-2-1-3": [ - "IAC-10.8" + "5.12.3.d": [ + "PRI-06.4" ], - "2-2-1-9": [ - "IAC-10.11" + "5.12.3.e": [ + "PRI-06.4" ], - "2-2-1-2": [ - "IAC-15.7" + "5.12.3.f": [ + "PRI-06.4" ], - "2-12": [ - "IRO-01" + "5.12.3.g": [ + "PRI-06.4" ], - "2-12-1": [ - "IRO-01" + "5.12.3.h": [ + "PRI-06.4" ], - "2-12-2": [ - "IRO-01" + "5.12.3.h.ii": [ + "PRI-06.4" ], - "2-12-2-1": [ - "IRO-02" + "5.12.3.i": [ + "PRI-06.4" ], - "2-12-2-2": [ - "IRO-02", - "IRO-04" + "5.12.3.j": [ + "PRI-06.4" ], - "2-12-2-3": [ - "IRO-02", - "IRO-04" + "5.12.4": [ + "PRI-06.4" ], - "2-12-2-4": [ - "IRO-02", - "IRO-04" + "5.12.4.a": [ + "PRI-06.4" ], - "2-12-2-5": [ - "IRO-02", - "IRO-04" + "5.12.4.a.i": [ + "PRI-06.4" ], - "2-12-2-6": [ - "IRO-02", - "IRO-05" + "5.12.4.a.ii": [ + "PRI-06.4" ], - "2-12-2-7": [ - "IRO-02", - "IRO-06" + "5.12.4.b": [ + "PRI-06.4" ], - "2-12-2-8": [ - "IRO-02", - "IRO-06.1", - "THR-02", - "THR-03" + "5.12.5": [ + "PRI-06.4" ], - "1-4-1-2": [ - "IAO-01", - "PRM-04", - "TDA-09" + "5.12.5.a": [ + "PRI-06.4" ], - "1-3-1-6": [ - "IAO-05", - "RSK-04.1", - "RSK-06.2" + "5.12.5.b": [ + "PRI-06.4" ], - "2-13-1-7": [ - "MNT-01", - "MNT-06", - "MNT-06.1", - "PES-06.3" + "5.12.6": [ + "PRI-06.4" ], - "2-3-1": [ - "NET-01" + "5.13.4": [ + "PRI-06.4" ], - "2-4": [ - "NET-01" + "5.13.4.a": [ + "PRI-06.4" ], - "2-4-2": [ - "NET-01" + "5.13.5": [ + "PRI-06.4" ], - "2-3-1-13": [ - "NET-05.1", - "NET-05.2", - "NET-06.5" + "5.13.5.a": [ + "PRI-06.4" ], - "2-2-1-1": [ - "NET-06.4" + "5.13.5.a.i": [ + "PRI-06.4" ], - "2-6-1-2": [ - "NET-17" + "5.13.5.a.ii": [ + "PRI-06.4" ], - "2-13": [ - "PES-01" + "5.13.5.b": [ + "PRI-06.4" ], - "2-13-1": [ - "PES-01" + "1.2.2.a": [ + "PRI-06.8" ], - "2-13-1-8": [ - "PES-01" + "1.2.2.b": [ + "PRI-06.8" ], - "2-13-1-9": [ - "PES-01", - "VPM-10" + "5.12.3.h.i": [ + "PRI-07.4" ], - "2-13-2": [ - "PES-01" + "5.13.1.b.ii": [ + "PRI-12.1" ], - "2-13-1-1": [ - "PES-02" + "3.6.5": [ + "PRI-14.2" ], - "2-13-1-3": [ - "PES-03", - "PES-03.1" + "5.12.9": [ + "PRI-17" ], - "2-13-1-4": [ - "PES-03.2", - "PES-04" + "5.12.9.a": [ + "PRI-17" ], - "2-13-1-5": [ - "PES-03.4", - "PES-04.1" + "5.12.9.b": [ + "PRI-17" ], - "2-13-1-2": [ - "PES-05.1" + "5.12.9.c": [ + "PRI-17" ], - "2-13-1-6": [ - "PES-06" + "5.12.10": [ + "PRI-17" + ] + }, + "apac-aus-ism-2026-march": { + "ISM-0047": [ + "GOV-01", + "GOV-02" ], - "1-4": [ - "PRM-02" + "ISM-0725": [ + "GOV-01.1", + "GOV-04", + "HRS-03" ], - "1-4-1": [ - "PRM-02", - "PRM-05" + "ISM-1998": [ + "GOV-01.1" ], - "1-4-1-1": [ - "PRM-02", - "PRM-05" + "ISM-1999": [ + "GOV-01.1" ], - "1-4-2": [ - "PRM-05" + "ISM-2002": [ + "GOV-01.1" ], - "1-3": [ - "RSK-01" + "ISM-2003": [ + "GOV-01.1" ], - "1-3-1": [ - "RSK-01" + "ISM-2005": [ + "GOV-01.1", + "GOV-21", + "BCD-02", + "IAO-03" ], - "1-3-1-1": [ - "RSK-01" + "ISM-2006": [ + "GOV-01.1", + "IRO-06" ], - "1-3-1-4": [ - "RSK-01.1", - "RSK-02", - "RSK-02.1" + "ISM-0718": [ + "GOV-01.2" ], - "1-3-1-5": [ - "RSK-01.1", - "RSK-02", - "RSK-02.1" + "ISM-1918": [ + "GOV-01.2" ], - "1-3-1-2": [ - "RSK-04" + "ISM-2000": [ + "GOV-01.2" ], - "1-3-1-3": [ - "RSK-04.1" + "ISM-1478": [ + "GOV-02" ], - "1-3-1-7": [ - "RSK-06.2" + "ISM-1551": [ + "GOV-02" ], - "1-8-1": [ - "SAT-03", - "SAT-03.2", - "SAT-03.5", - "SAT-03.6" + "ISM-1602": [ + "GOV-02" ], - "1-8-2": [ - "SAT-03", - "SAT-03.2", - "SAT-03.5", - "SAT-03.6" + "ISM-1784": [ + "GOV-02", + "IRO-04" ], - "1-8-3": [ - "SAT-03", - "SAT-03.2", - "SAT-03.5", - "SAT-03.6", - "THR-03" + "ISM-1785": [ + "GOV-02", + "RSK-09", + "TPM-01" ], - "4-1-1-1": [ - "TDA-01.1", - "TPM-01", - "TPM-05" + "ISM-2074": [ + "GOV-02", + "AAT-01" ], - "1-4-1-4": [ - "TDA-07", - "TDA-08" + "ISM-0888": [ + "GOV-03" ], - "1-4-1-3": [ - "TDA-09.6" + "ISM-1617": [ + "GOV-03" ], - "4-1": [ - "TPM-01" + "ISM-0714": [ + "GOV-04" ], - "4-1-1": [ - "TPM-01" + "ISM-0717": [ + "GOV-04", + "HRS-03" ], - "4-1-1-2": [ - "TPM-01", - "TPM-02", - "TPM-04.1" + "ISM-0720": [ + "GOV-04", + "HRS-03", + "PRM-01", + "PRM-01.1", + "PRM-05", + "SAT-01" ], - "4-1-1-3": [ - "TPM-01", - "TPM-04", - "TPM-05" + "ISM-0724": [ + "GOV-04", + "GOV-05", + "HRS-03" ], - "4-1-1-4": [ - "TPM-01", - "TPM-04.1", - "TPM-08" + "ISM-0726": [ + "GOV-04", + "HRS-03", + "RSK-01" ], - "4-1-2": [ - "TPM-01" + "ISM-0731": [ + "GOV-04", + "HRS-03", + "RSK-09", + "TPM-03" ], - "2-9": [ - "VPM-01" + "ISM-0732": [ + "GOV-04", + "HRS-03", + "PRM-01", + "PRM-02", + "PRM-03" ], - "2-9-1": [ - "VPM-01" + "ISM-0733": [ + "GOV-04", + "HRS-03", + "IRO-07", + "IRO-09", + "IRO-10", + "IRO-10.2" ], - "2-9-1-1": [ - "VPM-01.1" + "ISM-0734": [ + "GOV-04", + "BCD-01", + "HRS-03" ], - "2-9-1-2": [ - "VPM-02", - "VPM-03", - "VPM-04" + "ISM-0735": [ + "GOV-04", + "HRS-03", + "SAT-01" ], - "2-9-1-3": [ - "VPM-03", - "VPM-04" + "ISM-1997": [ + "GOV-04" ], - "2-3-1-3": [ - "VPM-05", - "VPM-05.4" + "ISM-2001": [ + "GOV-14" ], - "2-10": [ - "VPM-07" + "ISM-1633": [ + "GOV-15" ], - "2-10-1": [ - "VPM-07" + "ISM-1634": [ + "GOV-15", + "GOV-15.1" ], - "2-10-1-1": [ - "VPM-07" + "ISM-1635": [ + "GOV-15", + "GOV-15.2" ], - "2-10-1-2": [ - "VPM-07" + "ISM-1636": [ + "GOV-15", + "GOV-15.3" ], - "2-10-1-3": [ - "VPM-07" + "ISM-0027": [ + "GOV-15.4", + "IAO-01", + "IAO-07" ], - "2-10-1-4": [ - "VPM-07" + "ISM-1526": [ + "GOV-15.5", + "PRM-07", + "RSK-03" ], - "2-10-2": [ - "VPM-07" - ] - }, - "emea-sau-pdpl-2023": { - "Article 2.1": [ - "CPL-01" + "ISM-1587": [ + "GOV-17" ], - "Article 30.3": [ - "CPL-01" + "ISM-2072": [ + "AAT-01" ], - "Article 2.2": [ - "CPL-01.2" + "ISM-2084": [ + "AAT-03" ], - "Article 30.4.a": [ - "CPL-01.3" + "ISM-2086": [ + "AAT-12.1" ], - "Article 15.3": [ - "DCH-03.1" + "ISM-2087": [ + "AAT-12.1" ], - "Article 15.4": [ - "DCH-03.1" + "ISM-2088": [ + "AAT-12.5" ], - "Article 15.5": [ - "DCH-03.1" + "ISM-2103": [ + "AAT-12.6" ], - "Article 15.6": [ - "DCH-03.1" + "ISM-2089": [ + "AAT-16.11" ], - "Article 16.1": [ - "DCH-03.1" + "ISM-2094": [ + "AAT-17" ], - "Article 16.2": [ - "DCH-03.1" + "ISM-2092": [ + "AAT-29.2", + "IAC-08" ], - "Article 16.3": [ - "DCH-03.1" + "ISM-2090": [ + "AAT-29.24" ], - "Article 16.4": [ - "DCH-03.1" + "ISM-2091": [ + "AAT-29.24" ], - "Article 16.5": [ - "DCH-03.1" + "ISM-0285": [ + "AST-01" ], - "Article 16.6": [ - "DCH-03.1" + "ISM-0286": [ + "AST-01" ], - "Article 16.7": [ - "DCH-03.1" + "ISM-0289": [ + "AST-01" ], - "Article 16.8": [ - "DCH-03.1" + "ISM-0290": [ + "AST-01" ], - "Article 16.9": [ - "DCH-03.1" + "ISM-0591": [ + "AST-01" ], - "Article 11.3": [ - "DCH-18.1", - "PRI-05.4" + "ISM-1457": [ + "AST-01" ], - "Article 17.1": [ - "DCH-22.1", - "PRI-12" + "ISM-1480": [ + "AST-01" ], - "Article 10": [ - "DCH-22.3", - "PRI-04.2", - "PRI-04.4" + "ISM-0336": [ + "AST-02", + "DCH-06.2" ], - "Article 29.1": [ - "DCH-25" + "ISM-1643": [ + "AST-02" ], - "Article 30.2": [ - "HRS-03", - "PRI-01.4" + "ISM-1807": [ + "AST-02", + "AST-02.2" ], - "Article 20.1": [ - "IRO-04.1" + "ISM-1966": [ + "AST-02" ], - "Article 20.2": [ - "IRO-04.1" + "ISM-0520": [ + "AST-02.5" ], - "Article 11.2": [ - "PRI-01", - "PRI-04.7" + "ISM-1182": [ + "AST-02.5" ], - "Article 29.2.b": [ - "PRI-01.5" + "ISM-1493": [ + "AST-02.9", + "VPM-01", + "VPM-05" ], - "Article 19": [ - "PRI-01.6" + "ISM-1071": [ + "AST-03" ], - "Article 23.1": [ - "PRI-01.7" + "ISM-1790": [ + "AST-03.2", + "TDA-11" ], - "Article 23.2": [ - "PRI-01.7" + "ISM-1791": [ + "AST-03.2", + "TDA-11" ], - "Article 29.2.c": [ - "PRI-01.7" + "ISM-1792": [ + "AST-03.2", + "TDA-11" ], - "Article 4.1": [ - "PRI-02" + "ISM-1816": [ + "AST-03.2" ], - "Article 12": [ - "PRI-02" + "ISM-0516": [ + "AST-04" ], - "Article 13.2": [ - "PRI-02", - "PRI-02.1" + "ISM-0518": [ + "AST-04" ], - "Article 13.4": [ - "PRI-02" + "ISM-1645": [ + "AST-04" ], - "Article 13.5": [ - "PRI-02" + "ISM-1646": [ + "AST-04" ], - "Article 13.6": [ - "PRI-02" + "ISM-0161": [ + "AST-05", + "AST-06" ], - "Article 11.1": [ - "PRI-02.1" + "ISM-0293": [ + "AST-05", + "IAO-07" ], - "Article 13.3": [ - "PRI-02.1" + "ISM-1178": [ + "AST-05" ], - "Article 5.1": [ - "PRI-03" + "ISM-1973": [ + "AST-05" ], - "Article 10.1": [ - "PRI-03" + "ISM-1974": [ + "AST-05.2" ], - "Article 15.1": [ - "PRI-03" + "ISM-1975": [ + "AST-05.2" ], - "Article 24.1": [ - "PRI-03" + "ISM-0311": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21" ], - "Article 25.1": [ - "PRI-03" + "ISM-0312": [ + "AST-09", + "DCH-08" ], - "Article 25.2": [ - "PRI-03" + "ISM-0315": [ + "AST-09", + "DCH-08" ], - "Article 25.3": [ - "PRI-03" + "ISM-0318": [ + "AST-09" ], - "Article 26": [ - "PRI-03" + "ISM-0321": [ + "AST-09" ], - "Article 5.2": [ - "PRI-03.4" + "ISM-0330": [ + "AST-09", + "DCH-11" ], - "Article 7": [ - "PRI-03.5" + "ISM-0350": [ + "AST-09" ], - "Article 13.1": [ - "PRI-04.1" + "ISM-0363": [ + "AST-09", + "DCH-08", + "DCH-09.1" ], - "Article 14": [ - "PRI-04.4", - "PRI-04.5", - "PRI-05.2" + "ISM-0370": [ + "AST-09", + "DCH-09.1" ], - "Article 15.2": [ - "PRI-04.4" + "ISM-0372": [ + "AST-09", + "DCH-09.1" ], - "Article 11.4": [ - "PRI-05" + "ISM-0378": [ + "AST-09", + "DCH-08" ], - "Article 18.1": [ - "PRI-05" + "ISM-0839": [ + "AST-09", + "DCH-08" ], - "Article 18.2.a": [ - "PRI-05" + "ISM-1076": [ + "AST-09" ], - "Article 18.2.b": [ - "PRI-05" + "ISM-1217": [ + "AST-09", + "DCH-08", + "PES-16" ], - "Article 4.2": [ - "PRI-06" + "ISM-1218": [ + "AST-09", + "DCH-08" ], - "Article 4.3": [ - "PRI-06" + "ISM-1219": [ + "AST-09" ], - "Article 4.4": [ - "PRI-06" + "ISM-1220": [ + "AST-09" ], - "Article 4.5": [ - "PRI-06" + "ISM-1221": [ + "AST-09" ], - "Article 21": [ - "PRI-06" + "ISM-1222": [ + "AST-09" ], - "Article 8": [ - "PRI-07", - "TPM-05", - "TPM-08" + "ISM-1223": [ + "AST-09" ], - "Article 31": [ - "PRI-14" + "ISM-1534": [ + "AST-09" ], - "Article 31.1": [ - "PRI-14" + "ISM-1550": [ + "AST-09", + "DCH-08" ], - "Article 31.2": [ - "PRI-14" + "ISM-1641": [ + "AST-09" ], - "Article 31.3": [ - "PRI-14" + "ISM-1722": [ + "AST-09", + "DCH-08" ], - "Article 31.4": [ - "PRI-14" + "ISM-1723": [ + "AST-09", + "DCH-08" ], - "Article 31.5": [ - "PRI-14" + "ISM-1724": [ + "AST-09", + "DCH-08" ], - "Article 31.6": [ - "PRI-14" + "ISM-1725": [ + "AST-09", + "DCH-08" ], - "Article 24.2": [ - "PRI-14.2" + "ISM-1726": [ + "AST-09", + "DCH-08" ], - "Article 22": [ - "RSK-10" - ] - }, - "emea-sau-sacs-002-2022": { - "TPC-25": [ - "GOV-01", - "GOV-02", - "IAO-03.2", - "PRI-07.1", - "TPM-05", - "TPM-05.2" + "ISM-1727": [ + "AST-09", + "DCH-08" ], - "TPC-19": [ + "ISM-1728": [ "AST-09", - "DCH-09" + "PES-16" ], - "TPC-66": [ + "ISM-1729": [ "AST-09", - "DCH-09" + "PES-16" ], - "TPC-84": [ - "AST-12", - "AST-13", - "MDM-02", - "MDM-06", - "MDM-11" + "ISM-1741": [ + "AST-09" ], - "TPC-13": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "NET-01", - "NET-10.3" + "ISM-1742": [ + "AST-09" ], - "TPC-14": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "NET-01", - "NET-10.3" + "ISM-0233": [ + "AST-14.1", + "HRS-05.2" ], - "TPC-15": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "NET-01", - "NET-10.3" + "ISM-1199": [ + "AST-14.1", + "HRS-05.2", + "HRS-05.5" ], - "TPC-16": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "END-08", - "NET-01" + "ISM-1200": [ + "AST-14.1", + "HRS-05.2", + "HRS-05.5" ], - "TPC-17": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "NET-01" + "ISM-1297": [ + "AST-16", + "MDM-01", + "MDM-06" ], - "TPC-41": [ - "AST-27", - "NET-06.5", - "NET-08.1", - "WEB-02" + "ISM-0558": [ + "AST-19", + "AST-21" ], - "TPC-67": [ - "BCD-01" + "ISM-0548": [ + "AST-20", + "CRY-01.3" ], - "TPC-68": [ - "BCD-01" + "ISM-0551": [ + "AST-20", + "AST-21" ], - "TPC-69": [ - "BCD-01" + "ISM-0553": [ + "AST-20" ], - "TPC-24": [ - "BCD-02", - "DCH-01", - "DCH-01.2", - "DCH-02", - "DCH-02.1" + "ISM-0554": [ + "AST-20", + "CRY-01.3" ], - "TPC-70": [ - "BCD-04" + "ISM-0555": [ + "AST-20", + "AST-21" ], - "TPC-64": [ - "BCD-11" + "ISM-1014": [ + "AST-20", + "AST-21" ], - "TPC-38": [ - "BCD-11.2", + "ISM-1562": [ + "AST-20", "CFG-02", - "CFG-02.5", - "NET-03.6", - "NET-03.8", - "NET-06", - "NET-06.3", - "PES-18" + "HRS-05.2", + "NET-03.2" ], - "TPC-65": [ - "BCD-11.4" + "ISM-0549": [ + "AST-21" ], - "TPC-50": [ - "BCD-11.9" + "ISM-0556": [ + "AST-21" ], - "TPC-43": [ - "BCD-12.2", - "CLD-01", - "CLD-01.1", - "CPL-01", - "PRM-05", - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-0559": [ + "AST-22" ], - "TPC-73": [ - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "TDA-07", - "TDA-08" + "ISM-1450": [ + "AST-22" ], - "TPC-30": [ - "CLD-09", - "DCH-19", - "DCH-25" + "ISM-0245": [ + "AST-23" ], - "TPC-20": [ - "CPL-01", - "CPL-03.1" + "ISM-0589": [ + "AST-23" ], - "TPC-21": [ - "CPL-01", - "CPL-03.1" + "ISM-0590": [ + "AST-23" ], - "TPC-2": [ - "CFG-01", - "IAC-10.1", - "IAC-24", - "IAC-24.1" + "ISM-1036": [ + "AST-23", + "PES-12.2" ], - "TPC-10": [ - "CFG-02", - "CFG-02.5", - "IAC-01" + "ISM-1854": [ + "AST-23" ], - "TPC-22": [ - "CFG-02", - "CFG-02.5", - "END-01", - "END-02" + "ISM-1855": [ + "AST-23" ], - "TPC-56": [ - "CFG-02", - "CFG-02.5" + "ISM-1088": [ + "AST-24", + "IRO-10" ], - "TPC-63": [ - "CFG-02", - "CFG-02.5" + "ISM-1298": [ + "AST-24" ], - "TPC-87": [ - "CFG-02", - "CFG-02.5", - "MON-01.4" + "ISM-1299": [ + "AST-24" ], - "TPC-40": [ - "MON-01", - "MON-01.3", - "MON-01.8", - "MON-01.16", - "NET-03.8", - "NET-06", - "NET-06.3" + "ISM-1300": [ + "AST-24", + "AST-25", + "DCH-09" ], - "TPC-80": [ - "MON-01", - "MON-01.4", - "MON-01.16", - "MON-16" + "ISM-1554": [ + "AST-24" ], - "TPC-83": [ - "MON-01.15" + "ISM-1555": [ + "AST-24" ], - "TPC-81": [ - "MON-02", - "MON-02.1", - "MON-02.2" + "ISM-1556": [ + "AST-24", + "AST-25" ], - "TPC-75": [ - "MON-10" + "ISM-0042": [ + "AST-26" ], - "TPC-52": [ - "CRY-01", - "CRY-03" + "ISM-1380": [ + "AST-26", + "IAC-16", + "IAC-21" ], - "TPC-54": [ - "CRY-01" + "ISM-1385": [ + "AST-26", + "AST-27", + "CLD-03", + "NET-06.1", + "NET-06.4" ], - "TPC-53": [ - "CRY-03" + "ISM-1387": [ + "AST-27" ], - "TPC-42": [ - "CRY-07" + "ISM-0393": [ + "AST-28", + "DCH-02" ], - "TPC-55": [ - "CRY-09" + "ISM-1243": [ + "AST-28" ], - "TPC-39": [ - "DCH-01", - "DCH-01.1", - "DCH-01.2", - "DCH-03", - "DCH-03.1", - "IAC-08" + "ISM-1255": [ + "AST-28" ], - "TPC-58": [ - "DCH-01", - "DCH-01.1", - "DCH-01.2" + "ISM-1256": [ + "AST-28" ], - "TPC-12": [ - "END-01", - "END-04" + "ISM-1268": [ + "AST-28" ], - "TPC-6": [ - "HRS-01", - "HRS-09", - "HRS-09.2", - "HRS-09.4" + "ISM-1269": [ + "AST-28", + "NET-06", + "NET-06.6" ], - "TPC-71": [ - "HRS-01", - "HRS-04.2", - "HRS-05.7", - "HRS-06", - "HRS-06.1" + "ISM-1270": [ + "AST-28", + "NET-06", + "NET-06.6" ], - "TPC-26": [ - "HRS-02", - "HRS-03", - "HRS-03.2", - "HRS-04.1", - "HRS-04.2", - "HRS-05", - "HRS-05.7" + "ISM-1271": [ + "AST-28", + "NET-06", + "NET-06.6" ], - "TPC-1": [ - "HRS-05.1" + "ISM-1272": [ + "AST-28" ], - "TPC-8": [ - "HRS-05.1", - "HRS-05.3" + "ISM-1273": [ + "AST-28", + "TDA-08" ], - "TPC-9": [ - "HRS-05.1", - "HRS-05.3", - "HRS-06", - "HRS-06.1" + "ISM-1274": [ + "AST-28", + "TDA-08" ], - "TPC-18": [ - "HRS-08", - "HRS-09", - "HRS-09.1", - "HRS-09.2", - "HRS-09.3" + "ISM-1275": [ + "AST-28", + "NET-18" ], - "TPC-32": [ - "IAC-02" + "ISM-1276": [ + "AST-28" ], - "TPC-4": [ - "IAC-06" + "ISM-1277": [ + "AST-28", + "CRY-05.3" ], - "TPC-5": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2" + "ISM-1278": [ + "AST-28" ], - "TPC-37": [ - "IAC-06", - "IAC-06.1", - "IAC-06.3" + "ISM-1245": [ + "AST-28.1" ], - "TPC-44": [ - "IAC-06" + "ISM-1246": [ + "AST-28.1" ], - "TPC-45": [ - "IAC-06", - "IAC-06.2" + "ISM-1247": [ + "AST-28.1" ], - "TPC-3": [ - "IAC-10", - "IAC-10.5", - "IAC-10.11" + "ISM-1249": [ + "AST-28.1" ], - "TPC-62": [ - "IAC-10.6", - "TDA-06" + "ISM-1250": [ + "AST-28.1" ], - "TPC-34": [ - "IAC-16", - "IAC-16.1", - "IAC-17" + "ISM-1260": [ + "AST-28.1" ], - "TPC-33": [ - "IAC-17" + "ISM-1263": [ + "AST-28.1" ], - "TPC-23": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-10", - "IRO-10.2" + "ISM-2053": [ + "AST-30" ], - "TPC-88": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-05" + "ISM-1810": [ + "BCD-01.4", + "BCD-11" ], - "TPC-89": [ - "IRO-01", - "IRO-02", - "IRO-07", - "IRO-08", - "IRO-09", - "IRO-10", - "IRO-10.2", - "IRO-13" + "ISM-1511": [ + "BCD-11" ], - "TPC-90": [ - "IRO-09" + "ISM-1547": [ + "BCD-11" ], - "TPC-51": [ - "IAO-01", - "IAO-07" + "ISM-1548": [ + "BCD-11" ], - "TPC-78": [ - "MNT-01", - "MNT-02", - "NET-01", - "VPM-05", - "VPM-05.4" + "ISM-1811": [ + "BCD-11", + "BCD-11.2" ], - "TPC-35": [ - "MNT-05", - "NET-14", - "NET-14.4", - "NET-14.6" + "ISM-1515": [ + "BCD-11.1" ], - "TPC-59": [ - "MDM-05" + "ISM-1812": [ + "BCD-11.9" ], - "TPC-92": [ - "NET-02.1" + "ISM-1813": [ + "BCD-11.9" ], - "TPC-76": [ - "NET-03" + "ISM-1814": [ + "BCD-11.9", + "BCD-11.10" ], - "TPC-36": [ - "NET-04.1", - "NET-05.1" + "ISM-1789": [ + "BCD-15", + "TPM-03", + "TPM-03.1" ], - "TPC-77": [ - "NET-08", - "NET-08.2" + "ISM-1579": [ + "CAP-01", + "CAP-02", + "CAP-03", + "CAP-05", + "CLD-01" ], - "TPC-57": [ - "NET-18" + "ISM-1580": [ + "CAP-01", + "CAP-02", + "CAP-03", + "CLD-01" ], - "TPC-46": [ - "PES-01", - "PES-03.2", - "PES-03.4", - "PES-04" + "ISM-1581": [ + "CAP-01", + "CAP-02", + "CAP-03", + "CLD-01" ], - "TPC-86": [ - "PES-02", - "PES-02.1", - "PES-03" + "ISM-1211": [ + "CHG-01", + "CHG-02" ], - "TPC-47": [ - "PES-03", - "PES-06", - "PES-06.1", - "PES-06.2", - "PES-06.6" + "ISM-1823": [ + "CHG-04", + "CFG-02" ], - "TPC-82": [ - "PES-03", - "PES-03.1" + "ISM-1796": [ + "CHG-04.2", + "TDA-01.1" ], - "TPC-49": [ - "PES-03.4", - "PES-04.1" + "ISM-0405": [ + "CHG-04.5", + "IAC-17", + "IAC-28.1" ], - "TPC-48": [ - "PES-06.3" + "ISM-1437": [ + "CLD-01" ], - "TPC-74": [ - "PRM-04", - "PRM-07" + "ISM-1529": [ + "CLD-01", + "CLD-06" ], - "TPC-31": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-06.2", - "RSK-07" + "ISM-1750": [ + "CLD-03", + "NET-06", + "NET-06.1" ], - "TPC-7": [ - "SAT-01", - "SAT-02", - "SAT-03" + "ISM-1572": [ + "CLD-09", + "IAO-03.2", + "TPM-04.4", + "TPM-05" ], - "TPC-60": [ - "TDA-06", - "TDA-18" + "ISM-1438": [ + "CLD-12" ], - "TPC-72": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5" + "ISM-1439": [ + "CLD-12" ], - "TPC-61": [ - "TDA-19" + "ISM-0078": [ + "CPL-01" ], - "TPC-11": [ - "VPM-01", - "VPM-02", - "VPM-05" + "ISM-0854": [ + "CPL-01" ], - "TPC-27": [ - "VPM-01.1", - "VPM-07" + "ISM-0100": [ + "CPL-03.1", + "IAO-02", + "IAO-02.2", + "IAO-02.3" ], - "TPC-28": [ - "VPM-01.1", - "VPM-07" + "ISM-0912": [ + "CFG-01", + "IAO-03" ], - "TPC-29": [ - "VPM-01.1", - "VPM-07" + "ISM-0341": [ + "CFG-02", + "DCH-10" ], - "TPC-91": [ - "VPM-02", - "VPM-05.1", - "VPM-05.3" + "ISM-0343": [ + "CFG-02", + "DCH-10", + "DCH-10.1" ], - "TPC-85": [ - "VPM-06" + "ISM-0345": [ + "CFG-02" ], - "TPC-79": [ - "WEB-03" - ] - }, - "emea-sau-sama-csf-1-2017": { - "3.1.1": [ - "GOV-01", - "GOV-01.1" + "ISM-0380": [ + "CFG-02" ], - "3.1.3": [ - "GOV-02" + "ISM-0383": [ + "CFG-02", + "TDA-09.6" ], - "3.1.4": [ - "GOV-04", - "HRS-03" + "ISM-0567": [ + "CFG-02", + "NET-20.7" ], - "3.3.3": [ - "AST-01" + "ISM-1316": [ + "CFG-02", + "NET-15" ], - "3.3.12": [ - "AST-07" + "ISM-1318": [ + "CFG-02", + "NET-15" ], - "3.3.11": [ - "AST-09", - "DCH-08", - "DCH-21", - "PRI-05" + "ISM-1319": [ + "CFG-02", + "NET-15" ], - "3.3.10": [ - "AST-16" + "ISM-1321": [ + "CFG-02", + "NET-15" ], - "3.3.7": [ - "CHG-01" + "ISM-1406": [ + "CFG-02" ], - "3.3.4": [ - "CLD-01", - "CLD-02", - "NET-01", - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-1407": [ + "CFG-02", + "CFG-02.1" ], - "3.3.8": [ - "CLD-01", - "CLD-02", - "NET-01", - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-1408": [ + "CFG-02" ], - "3.4.3": [ - "CLD-01", - "CLD-02" + "ISM-1409": [ + "CFG-02" ], - "3.2.2": [ - "CPL-01" + "ISM-1418": [ + "CFG-02", + "END-07" ], - "3.2.3": [ - "CPL-01" + "ISM-1491": [ + "CFG-02" ], - "3.3.13": [ - "CPL-01", - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-1492": [ + "CFG-02" ], - "3.2.4": [ - "CPL-02", - "CPL-03" + "ISM-1584": [ + "CFG-02" ], - "3.2.5": [ - "CPL-02.1", - "CPL-03" + "ISM-1604": [ + "CFG-02", + "SEA-13.1" ], - "3.3.14": [ - "MON-01", - "MON-01.2", - "MON-01.16", - "MON-02", - "MON-02.1" + "ISM-1608": [ + "CFG-02", + "END-04", + "END-04.4" ], - "3.3.9": [ - "CRY-01" + "ISM-1621": [ + "CFG-02", + "CFG-03" ], - "3.3.1": [ - "HRS-01" + "ISM-1622": [ + "CFG-02" ], - "3.3.5": [ - "IAC-01" + "ISM-1623": [ + "CFG-02" ], - "3.3.15": [ - "IRO-01" + "ISM-1624": [ + "CFG-02" ], - "3.3.2": [ - "PES-01" + "ISM-1654": [ + "CFG-02", + "CFG-04.2" ], - "3.1.2": [ - "PRM-01.1" + "ISM-1655": [ + "CFG-02", + "CFG-04.2", + "CFG-05" ], - "3.1.5": [ - "PRM-04" + "ISM-1710": [ + "CFG-02" ], - "3.2.1": [ - "RSK-01" + "ISM-1745": [ + "CFG-02" ], - "3.2.1.1": [ - "RSK-03" + "ISM-1824": [ + "CFG-02" ], - "3.2.1.2": [ - "RSK-04", - "RSK-05" + "ISM-1825": [ + "CFG-02" ], - "3.2.1.4": [ - "RSK-04.1" + "ISM-1828": [ + "CFG-02" ], - "3.2.1.3": [ - "RSK-06.1" + "ISM-1829": [ + "CFG-02" ], - "3.1.6": [ - "SAT-01", - "SAT-03" + "ISM-1830": [ + "CFG-02" ], - "3.1.7": [ - "SAT-03", - "SAT-03.3" + "ISM-1836": [ + "CFG-02" ], - "3.3.6": [ - "TDA-01" + "ISM-1838": [ + "CFG-02" ], - "3.4.1": [ - "TPM-01", - "TPM-04.1" + "ISM-1839": [ + "CFG-02" ], - "3.4.2": [ - "TPM-01", - "TPM-03", - "TPM-04.1" + "ISM-1840": [ + "CFG-02" ], - "3.3.16": [ - "THR-01" + "ISM-1841": [ + "CFG-02" ], - "3.3.17": [ - "VPM-01" - ] - }, - "emea-srb-act-9-2018": { - "5": [ - "IAO-03.2", - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "TPM-05", - "TPM-05.2" + "ISM-1844": [ + "CFG-02" ], - "7": [ - "PRI-04.1", - "PRI-05.1" + "ISM-1846": [ + "CFG-02" ], - "8": [ - "PRI-05" + "ISM-1858": [ + "CFG-02" ], - "9": [ - "PRI-05.7" + "ISM-1859": [ + "CFG-02" ], - "10": [ - "PRI-05.7" + "ISM-1860": [ + "CFG-02" ], - "11": [ - "IAO-03.2", - "PRI-06.1", - "PRI-07.1", - "PRI-07.2", - "PRI-10", - "TPM-05", - "TPM-05.2" + "ISM-1861": [ + "CFG-02" ], - "13": [ - "CPL-01", - "PRI-05.7" + "ISM-1870": [ + "CFG-02" ], - "14": [ - "PRI-04.1" + "ISM-1871": [ + "CFG-02" ], - "15": [ - "PRI-03", - "PRI-03.4" + "ISM-1886": [ + "CFG-02" ], - "16": [ - "PRI-04" + "ISM-1887": [ + "CFG-02" ], - "17": [ - "PRI-05.4" + "ISM-1888": [ + "CFG-02" ], - "19": [ - "PRI-05.4" + "ISM-1890": [ + "CFG-02" ], - "20": [ - "PRI-04.1", - "PRI-04.4", - "PRI-05.1" + "ISM-1891": [ + "CFG-02" ], - "21": [ - "PRI-06", - "PRI-06.4", - "PRI-06.6", - "PRI-06.7" + "ISM-1896": [ + "CFG-02" ], - "22": [ - "PRI-06.4", - "PRI-06.6", - "PRI-06.7" + "ISM-1897": [ + "CFG-02" ], - "23": [ - "DCH-25", - "PRI-06", - "PRI-06.4" + "ISM-1913": [ + "CFG-02" ], - "24": [ - "PRI-06", - "PRI-06.4" + "ISM-1914": [ + "CFG-02" ], - "25": [ - "PRI-06", - "PRI-06.4" + "ISM-1915": [ + "CFG-02" ], - "26": [ - "PRI-06", - "PRI-06.4" + "ISM-1916": [ + "CFG-02" ], - "29": [ - "PRI-06.1" + "ISM-1928": [ + "CFG-02" ], - "30": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "ISM-1929": [ + "CFG-02" ], - "31": [ - "PRI-03", - "PRI-03.1" + "ISM-1930": [ + "CFG-02" ], - "32": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "ISM-1931": [ + "CFG-02" ], - "33": [ - "PRI-01.7", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "PRI-14.1", - "PRI-14.2" + "ISM-1932": [ + "CFG-02" ], - "34": [ - "PRI-06.2" + "ISM-1933": [ + "CFG-02" ], - "35": [ - "PRI-14.2" + "ISM-1934": [ + "CFG-02" ], - "36": [ - "PRI-06.6" + "ISM-1935": [ + "CFG-02" ], - "37": [ - "PRI-03.3", - "PRI-03.4" + "ISM-1936": [ + "CFG-02" ], - "38": [ - "PRI-02.2" + "ISM-1938": [ + "CFG-02" ], - "39": [ - "PRI-02.2" + "ISM-1943": [ + "CFG-02" + ], + "ISM-1944": [ + "CFG-02" + ], + "ISM-1945": [ + "CFG-02" + ], + "ISM-1946": [ + "CFG-02" + ], + "ISM-1947": [ + "CFG-02" ], - "41": [ - "PRI-01.6" + "ISM-1948": [ + "CFG-02" ], - "42": [ - "PRI-01.6" + "ISM-1949": [ + "CFG-02" ], - "43": [ - "PRI-07.2" + "ISM-1950": [ + "CFG-02" ], - "44": [ - "PRI-01.4" + "ISM-1951": [ + "CFG-02" ], - "45": [ - "PRI-07.1" + "ISM-1952": [ + "CFG-02" ], - "46": [ - "PRI-07.1" + "ISM-1953": [ + "CFG-02" ], - "47": [ - "PRI-14" + "ISM-1954": [ + "CFG-02" ], - "48": [ - "PRI-14" + "ISM-1955": [ + "CFG-02" ], - "49": [ - "CPL-01" + "ISM-1956": [ + "CFG-02" ], - "50": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.5", - "PRI-01.6" + "ISM-1957": [ + "CFG-02" ], - "51": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.5", - "PRI-01.6" + "ISM-1958": [ + "CFG-02" ], - "52": [ - "IRO-10.2", - "PRI-14" + "ISM-1962": [ + "CFG-02" ], - "53": [ - "IRO-04.1" + "ISM-1980": [ + "CFG-02", + "IAC-10.1" ], - "54": [ - "RSK-10" + "ISM-1984": [ + "CFG-02" ], - "56": [ - "PRI-01.4" + "ISM-2010": [ + "CFG-02" ], - "57": [ - "PRI-01.4" + "ISM-2012": [ + "CFG-02" ], - "58": [ - "PRI-01.4" + "ISM-2047": [ + "CFG-02" ], - "59": [ - "CPL-01", - "PRI-01" + "ISM-2049": [ + "CFG-02" ], - "63": [ - "DCH-25" + "ISM-2079": [ + "CFG-02", + "IAC-10.1" ], - "64": [ - "DCH-14.2" + "ISM-2080": [ + "CFG-02", + "IAC-10.1" ], - "65": [ - "DCH-01", - "DCH-25", - "PRI-01.5" + "ISM-2081": [ + "CFG-02", + "IAC-10.1" ], - "66": [ - "PRI-01.5" + "ISM-2096": [ + "CFG-02" ], - "67": [ - "PRI-01.5" + "ISM-2097": [ + "CFG-02" ], - "68": [ - "DCH-25" + "ISM-2098": [ + "CFG-02" ], - "69": [ - "DCH-25" + "ISM-1588": [ + "CFG-02.1" ], - "70": [ - "DCH-25" + "ISM-1510": [ + "CFG-02.3", + "DCH-18" ], - "71": [ - "DCH-25" + "ISM-0534": [ + "CFG-02.5" ], - "5.1": [ - "CPL-01", - "DCH-13.1", - "DCH-18.2", - "PRI-01", - "PRI-02", - "PRI-02.1", - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "ISM-1656": [ + "CFG-02.5" ], - "64.1": [ - "DCH-14.2" + "ISM-1657": [ + "CFG-02.5" ], - "64.2": [ - "DCH-14.2" + "ISM-1658": [ + "CFG-02.5" ], - "64.3": [ - "DCH-14.2" + "ISM-1659": [ + "CFG-02.5" ], - "64.4": [ - "DCH-14.2" + "ISM-1667": [ + "CFG-02.5" ], - "5.5": [ - "DCH-18", - "PRI-05" + "ISM-1668": [ + "CFG-02.5" ], - "50.1": [ - "DCH-23", - "PRI-01.6" + "ISM-1669": [ + "CFG-02.5" ], - "63.1": [ - "DCH-25" + "ISM-1670": [ + "CFG-02.5" ], - "63.2": [ - "DCH-25" + "ISM-1671": [ + "CFG-02.5" ], - "63.3": [ - "DCH-25" + "ISM-1672": [ + "CFG-02.5" ], - "63.4": [ - "DCH-25" + "ISM-1673": [ + "CFG-02.5" ], - "69.x": [ - "DCH-25" + "ISM-1674": [ + "CFG-02.5" ], - "70.1": [ - "DCH-25" + "ISM-1675": [ + "CFG-02.5" ], - "70.2": [ - "DCH-25" + "ISM-1676": [ + "CFG-02.5" ], - "70.3": [ - "DCH-25" + "ISM-1748": [ + "CFG-02.5" ], - "70.4": [ - "DCH-25" + "ISM-1749": [ + "CFG-02.5", + "IAC-10.5" ], - "70.5": [ - "DCH-25" + "ISM-1800": [ + "CFG-02.5" ], - "71.1": [ - "DCH-25" + "ISM-1867": [ + "CFG-02.5" ], - "71.2": [ - "DCH-25" + "ISM-1868": [ + "CFG-02.5" ], - "71.3": [ - "DCH-25" + "ISM-0385": [ + "CFG-03" ], - "71.4": [ - "DCH-25" + "ISM-1006": [ + "CFG-03", + "END-16" ], - "71.5": [ - "DCH-25" + "ISM-1311": [ + "CFG-03" ], - "53.1": [ - "IRO-04.1" + "ISM-1312": [ + "CFG-03" ], - "53.2": [ - "IRO-04.1" + "ISM-1392": [ + "CFG-03", + "CFG-06", + "CFG-06.1", + "IAC-21" ], - "53.3": [ - "IRO-04.1" + "ISM-1479": [ + "CFG-03" ], - "52.1": [ - "IRO-10.2", - "PRI-14" + "ISM-1487": [ + "CFG-03" ], - "52.2": [ - "IRO-10.2", - "PRI-14" + "ISM-1488": [ + "CFG-03" ], - "52.3": [ - "IRO-10.2", - "PRI-14" + "ISM-1489": [ + "CFG-03" ], - "52.4": [ - "IRO-10.2", - "PRI-14" + "ISM-0843": [ + "CFG-03.3", + "CFG-06", + "CFG-06.1" ], - "59.1": [ - "PRI-01" + "ISM-0846": [ + "CFG-03.3", + "CFG-06", + "CFG-06.1" ], - "59.2": [ - "PRI-01" + "ISM-1235": [ + "CFG-03.3", + "CFG-04.2" ], - "59.3": [ - "PRI-01" + "ISM-1544": [ + "CFG-03.3", + "CFG-06", + "CFG-06.1" ], - "59.4": [ - "PRI-01" + "ISM-0705": [ + "CFG-03.4", + "HRS-05.5" ], - "59.5": [ - "PRI-01" + "ISM-0824": [ + "CFG-04.2", + "HRS-03.1", + "HRS-05", + "HRS-05.2", + "SAT-02", + "SAT-03.2" ], - "59.6": [ - "PRI-01" + "ISM-1412": [ + "CFG-04.2" ], - "59.7": [ - "PRI-01" + "ISM-1470": [ + "CFG-04.2" ], - "59.8": [ - "PRI-01" + "ISM-1485": [ + "CFG-04.2" ], - "59.9": [ - "PRI-01" + "ISM-1486": [ + "CFG-04.2" ], - "59.10": [ - "PRI-01" + "ISM-1542": [ + "CFG-04.2" ], - "59.11": [ - "PRI-01" + "ISM-1585": [ + "CFG-04.2" ], - "44.1": [ - "PRI-01.4" + "ISM-1601": [ + "CFG-04.2" ], - "44.2": [ - "PRI-01.4" + "ISM-0382": [ + "CFG-05", + "CFG-05.2" ], - "56.1": [ - "PRI-01.4" + "ISM-1592": [ + "CFG-05", + "CFG-05.2", + "IAC-21.5" ], - "56.2": [ - "PRI-01.4" + "ISM-0955": [ + "CFG-06", + "CFG-06.1" ], - "56.3": [ - "PRI-01.4" + "ISM-1471": [ + "CFG-06", + "CFG-06.1" ], - "58.1": [ - "PRI-01.4" + "ISM-1490": [ + "CFG-06", + "CFG-06.1" ], - "58.2": [ - "PRI-01.4" + "ISM-1582": [ + "CFG-06", + "CFG-06.1" ], - "58.3": [ - "PRI-01.4" + "ISM-2023": [ + "CFG-09" ], - "58.4": [ - "PRI-01.4" + "ISM-2029": [ + "CFG-09.1" ], - "65.x": [ - "PRI-01.5" + "ISM-2026": [ + "CFG-09.2" ], - "67.x": [ - "PRI-01.5" + "ISM-2027": [ + "CFG-09.2" ], - "5.6": [ - "PRI-01.6" + "ISM-2030": [ + "CFG-09.2" ], - "42.1": [ - "PRI-01.6" + "ISM-2024": [ + "CFG-09.3" ], - "42.2": [ - "PRI-01.6" + "ISM-0109": [ + "MON-01", + "MON-01.8", + "MON-01.16", + "MON-02" ], - "50.2": [ - "PRI-01.6" + "ISM-0120": [ + "MON-01", + "MON-01.16", + "MON-11.3" ], - "50.3": [ - "PRI-01.6" + "ISM-0580": [ + "MON-01", + "MON-01.16" ], - "50.4": [ - "PRI-01.6" + "ISM-0660": [ + "MON-01", + "MON-01.16" ], - "51.1": [ - "PRI-01.6" + "ISM-1163": [ + "MON-01", + "MON-01.16", + "VPM-01", + "VPM-03", + "VPM-06", + "VPM-07" ], - "51.2": [ - "PRI-01.6" + "ISM-1294": [ + "MON-01", + "MON-01.16" ], - "51.3": [ - "PRI-01.6" + "ISM-1586": [ + "MON-01", + "MON-01.16" ], - "51.4": [ - "PRI-01.6" + "ISM-1906": [ + "MON-01.3" ], - "51.5": [ - "PRI-01.6" + "ISM-1907": [ + "MON-01.3" ], - "51.6": [ - "PRI-01.6" + "ISM-2015": [ + "MON-01.3" ], - "51.7": [ - "PRI-01.6" + "ISM-1959": [ + "MON-01.4" ], - "51.8": [ - "PRI-01.6" + "ISM-0261": [ + "MON-01.9" ], - "51.9": [ - "PRI-01.6" + "ISM-1228": [ + "MON-02", + "MON-02.1", + "MON-02.2" ], - "51.10": [ - "PRI-01.6" + "ISM-1405": [ + "MON-02" ], - "6.1": [ - "PRI-02", - "PRI-02.1", - "PRI-04", - "PRI-04.1" + "ISM-1536": [ + "MON-02", + "MON-03" ], - "12.2": [ - "PRI-02", - "PRI-02.1" + "ISM-1537": [ + "MON-02", + "MON-03", + "MON-03.3", + "MON-03.7" ], - "12.3": [ - "PRI-02", - "PRI-02.1" + "ISM-1566": [ + "MON-02" ], - "12.4": [ - "PRI-02", - "PRI-02.1" + "ISM-1650": [ + "MON-02", + "MON-16.4", + "IAC-16" ], - "12.5": [ - "PRI-02", - "PRI-02.1" + "ISM-1911": [ + "MON-02" ], - "12.6": [ - "PRI-02", - "PRI-02.1" + "ISM-1960": [ + "MON-02" ], - "38.1": [ - "PRI-02.2" + "ISM-1963": [ + "MON-02" ], - "38.2": [ - "PRI-02.2" + "ISM-1976": [ + "MON-02" ], - "38.3": [ - "PRI-02.2" + "ISM-1977": [ + "MON-02" ], - "12.1": [ - "PRI-03" + "ISM-1978": [ + "MON-02" ], - "31.1": [ - "PRI-03", - "PRI-03.1" + "ISM-1979": [ + "MON-02" ], - "31.2": [ - "PRI-03", - "PRI-03.1" + "ISM-1983": [ + "MON-02" ], - "31.3": [ - "PRI-03", - "PRI-03.1" + "ISM-1986": [ + "MON-02" ], - "31.4": [ - "PRI-03", - "PRI-03.1" + "ISM-1987": [ + "MON-02" ], - "5.2": [ - "PRI-04", - "PRI-04.1" + "ISM-1961": [ + "MON-02.1" ], - "6.2": [ - "PRI-04", - "PRI-04.1" + "ISM-1964": [ + "MON-02.1" ], - "6.3": [ - "PRI-04", - "PRI-04.1" + "ISM-0988": [ + "MON-02.7", + "SEA-20" ], - "6.4": [ - "PRI-04", - "PRI-04.1" + "ISM-0582": [ + "MON-03" ], - "6.5": [ - "PRI-04", - "PRI-04.1" + "ISM-0585": [ + "MON-03" ], - "7.1": [ - "PRI-04.1", - "PRI-05.1" + "ISM-1895": [ + "MON-03" ], - "7.2": [ - "PRI-04.1", - "PRI-05.1" + "ISM-2051": [ + "MON-03" ], - "5.3": [ - "PRI-05.1", - "PRI-05.4" + "ISM-2052": [ + "MON-03.1" ], - "5.4": [ - "PRI-05.2", - "PRI-06.1", - "PRI-10" + "ISM-0407": [ + "MON-03.2", + "IAC-01.1" ], - "17.1": [ - "PRI-05.4" + "ISM-1889": [ + "MON-03.3" ], - "17.2": [ - "PRI-05.4" + "ISM-1660": [ + "MON-06", + "MON-16" ], - "17.3": [ - "PRI-05.4" + "ISM-1815": [ + "MON-08" ], - "17.4": [ - "PRI-05.4" + "ISM-1985": [ + "MON-08.2" ], - "17.5": [ - "PRI-05.4" + "ISM-1213": [ + "MON-10", + "IRO-13" ], - "17.6": [ - "PRI-05.4" + "ISM-1988": [ + "MON-10" ], - "17.7": [ - "PRI-05.4" + "ISM-1989": [ + "MON-10" ], - "17.8": [ - "PRI-05.4" + "ISM-1091": [ + "MON-11.3", + "CRY-01" ], - "17.9": [ - "PRI-05.4" + "ISM-1625": [ + "MON-16.1", + "IRO-02.2", + "THR-04", + "THR-05" ], - "17.10": [ - "PRI-05.4" + "ISM-0142": [ + "CRY-01" ], - "18.1": [ - "PRI-05.4" + "ISM-0457": [ + "CRY-01" ], - "18.2": [ - "PRI-05.4" + "ISM-0460": [ + "CRY-01" ], - "18.3": [ - "PRI-05.4" + "ISM-0471": [ + "CRY-01" ], - "9.1": [ - "PRI-05.7" + "ISM-0472": [ + "CRY-01" ], - "9.2": [ - "PRI-05.7" + "ISM-0474": [ + "CRY-01" ], - "9.3": [ - "PRI-05.7" + "ISM-0475": [ + "CRY-01" ], - "9.4": [ - "PRI-05.7" + "ISM-0476": [ + "CRY-01" ], - "9.5": [ - "PRI-05.7" + "ISM-0477": [ + "CRY-01" ], - "28.1": [ - "PRI-06" + "ISM-0479": [ + "CRY-01" ], - "28.2": [ - "PRI-06" + "ISM-0481": [ + "CRY-01" ], - "28.3": [ - "PRI-06" + "ISM-0499": [ + "CRY-01" ], - "28.4": [ - "PRI-06" + "ISM-0501": [ + "CRY-01" ], - "28.5": [ - "PRI-06" + "ISM-0994": [ + "CRY-01" ], - "34.1": [ - "PRI-06.2" + "ISM-0999": [ + "CRY-01", + "NET-13" ], - "34.2": [ - "PRI-06.2" + "ISM-1080": [ + "CRY-01", + "CRY-05", + "CRY-05.3" ], - "34.3": [ - "PRI-06.2" + "ISM-1146": [ + "CRY-01", + "HRS-05", + "IAC-01", + "SAT-02", + "SAT-03" ], - "34.4": [ - "PRI-06.2" + "ISM-1233": [ + "CRY-01" ], - "34.5": [ - "PRI-06.2" + "ISM-1446": [ + "CRY-01" ], - "21.1": [ - "PRI-06.4" + "ISM-1629": [ + "CRY-01" ], - "21.2": [ - "PRI-06.4", - "PRI-07.4", - "PRI-07.5" + "ISM-1759": [ + "CRY-01" ], - "22.1": [ - "PRI-06.4" + "ISM-1761": [ + "CRY-01" ], - "22.2": [ - "PRI-06.4", - "PRI-07.4", - "PRI-07.5" + "ISM-1762": [ + "CRY-01" ], - "23.x": [ - "PRI-06.4" + "ISM-1763": [ + "CRY-01" ], - "24.x": [ - "PRI-06.4" + "ISM-1764": [ + "CRY-01" ], - "25.x": [ - "PRI-06.4" + "ISM-1765": [ + "CRY-01" ], - "26.1": [ - "PRI-06.4" + "ISM-1766": [ + "CRY-01" ], - "26.2": [ - "PRI-06.4" + "ISM-1767": [ + "CRY-01" ], - "26.3": [ - "PRI-06.4" + "ISM-1768": [ + "CRY-01" ], - "26.4": [ - "PRI-06.4" + "ISM-1769": [ + "CRY-01" ], - "26.5": [ - "PRI-06.4" + "ISM-1770": [ + "CRY-01" ], - "26.6": [ - "PRI-06.4" + "ISM-1771": [ + "CRY-01" ], - "26.7": [ - "PRI-06.4" + "ISM-1772": [ + "CRY-01" ], - "26.8": [ - "PRI-06.4" + "ISM-0231": [ + "CRY-03", + "END-14" ], - "27.1": [ - "PRI-06.4" + "ISM-0232": [ + "CRY-03" ], - "27.2": [ - "PRI-06.4" + "ISM-0465": [ + "CRY-03" ], - "27.3": [ - "PRI-06.4" + "ISM-0467": [ + "CRY-03" ], - "27.4": [ - "PRI-06.4" + "ISM-0469": [ + "CRY-03" ], - "27.5": [ - "PRI-06.4" + "ISM-0484": [ + "CRY-03" ], - "27.6": [ - "PRI-06.4" + "ISM-0547": [ + "CRY-03" ], - "27.7": [ - "PRI-06.4" + "ISM-1139": [ + "CRY-03" ], - "30.x": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "ISM-1369": [ + "CRY-03" ], - "32.1": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "ISM-1370": [ + "CRY-03" ], - "32.2": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "ISM-1372": [ + "CRY-03" ], - "36.1": [ - "PRI-06.6" + "ISM-1373": [ + "CRY-03" ], - "36.2": [ - "PRI-06.6" + "ISM-1374": [ + "CRY-03" ], - "45.x": [ - "PRI-07.1" + "ISM-1375": [ + "CRY-03" ], - "47.x": [ - "PRI-14" + "ISM-1448": [ + "CRY-03" ], - "54.x": [ - "RSK-10" - ] - }, - "emea-zaf-popia-2013": { - "2": [ - "CPL-01", - "PRI-04.1" + "ISM-1453": [ + "CRY-03" ], - "3": [ - "CPL-01", - "PRI-04.1" + "ISM-1506": [ + "CRY-03" ], - "4": [ - "PRI-04.1", - "PRI-05", - "PRI-10", - "RSK-11", - "VPM-04.2" + "ISM-1553": [ + "CRY-03" ], - "5": [ - "PRI-02.2", - "PRI-04" + "ISM-1589": [ + "CRY-03", + "NET-13" ], - "8": [ - "CPL-02", - "CPL-03", - "END-13.1", - "SEA-01.1" + "ISM-1781": [ + "CRY-03" ], - "9": [ - "CPL-01", - "DCH-18", - "END-13.1" + "ISM-0677": [ + "CRY-04" ], - "10": [ - "END-13.3", - "PRI-05.1" + "ISM-0459": [ + "CRY-05" ], - "11": [ - "PRI-03", - "PRI-03.1", - "PRI-04", - "PRI-07.1" + "ISM-1314": [ + "CRY-07", + "NET-03.1", + "NET-15" ], - "13": [ - "PRI-02.1" + "ISM-1332": [ + "CRY-07" ], - "14": [ - "PRI-05", - "PRI-05.2" + "ISM-0485": [ + "CRY-08" ], - "15": [ - "PRI-03.2", - "PRI-05.4" + "ISM-1449": [ + "CRY-08" ], - "16": [ - "PRI-05", - "PRI-05.2", - "PRI-12" + "ISM-2050": [ + "CRY-08" ], - "17": [ - "PRI-01.4", - "PRI-09", - "PRI-14.1" + "ISM-0455": [ + "CRY-09", + "CRY-09.3" ], - "18": [ - "END-13.2", - "PRI-02", - "PRI-02.1", - "PRI-07" + "ISM-0507": [ + "CRY-09" ], - "19": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-18.1", - "DCH-18.2", - "DCH-24", - "DCH-24.1", - "EMB-01", - "EMB-02", - "EMB-03", - "END-01", - "HRS-01", - "HRS-04", - "IAC-01", - "IAO-01", - "MNT-01", - "NET-01", - "PES-01", - "PRI-01", - "PRI-08", - "PRM-01", - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-06.2", - "RSK-07", - "RSK-08", - "RSK-10", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "OPS-01", - "TPM-04", - "TPM-04.1", - "TPM-04.4", - "VPM-01", - "WEB-04" + "ISM-0462": [ + "CRY-09.3" ], - "20": [ - "HRS-01", - "HRS-04", - "IAC-01", - "PRI-01", - "PRI-07.1", - "TPM-01", - "TPM-03", - "TPM-04.3", - "TPM-05" + "ISM-0337": [ + "DCH-01" ], - "21": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", + "ISM-0831": [ "DCH-01", - "DCH-24", - "DCH-24.1", - "PRI-07.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-01", - "TPM-04.3", - "TPM-04.4" - ], - "22": [ - "IRO-01", - "IRO-04.1", - "IRO-10" + "SAT-03.3" ], - "23": [ - "PRI-06" + "ISM-1059": [ + "DCH-01", + "SAT-03.3" ], - "24": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "ISM-1549": [ + "DCH-01" ], - "26": [ - "PRI-05.4" + "ISM-1599": [ + "DCH-01", + "PES-16" ], - "28": [ - "PRI-07" + "ISM-1802": [ + "DCH-01.2" ], - "30": [ - "PRI-07" + "ISM-0270": [ + "DCH-02", + "DCH-04", + "NET-13" ], - "31": [ - "PRI-07" + "ISM-0271": [ + "DCH-02", + "DCH-04.1", + "NET-13" ], - "55": [ - "PRI-01.1", - "PRI-01.4" + "ISM-0272": [ + "DCH-02", + "DCH-04", + "NET-13" ], - "56": [ - "PRI-01.1", - "PRI-01.4" + "ISM-0294": [ + "DCH-02", + "DCH-04" ], - "60": [ - "CPL-03.1", - "IAO-01", - "PRI-01" + "ISM-0296": [ + "DCH-02", + "DCH-04" ], - "63": [ - "PRI-06.3" + "ISM-0323": [ + "DCH-02", + "DCH-02.1" ], - "69": [ - "PRI-04" + "ISM-0325": [ + "DCH-02.1", + "DCH-05.9", + "DCH-11" ], - "71": [ - "PRI-02.2" + "ISM-0201": [ + "DCH-04", + "PES-12.1" ], - "72": [ - "DCH-14", - "DCH-25" + "ISM-0332": [ + "DCH-04" ], - "74": [ - "PRI-06.3" + "ISM-0356": [ + "DCH-04", + "DCH-09" ], - "19.1": [ - "AST-01", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "MON-01", - "MON-01.16", - "CRY-01", - "IRO-01" + "ISM-0358": [ + "DCH-04", + "DCH-09" ], - "19.2": [ - "AST-01", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "MON-01", - "MON-01.16", - "CRY-01" + "ISM-0360": [ + "DCH-04", + "DCH-09" ], - "14.1": [ - "CRY-01", - "CRY-03", - "CRY-04", - "CRY-05", - "DCH-01" + "ISM-0368": [ + "DCH-08" ], - "16.1": [ - "DCH-09.3" + "ISM-0374": [ + "DCH-08" ], - "13.1": [ - "END-13.1" + "ISM-0375": [ + "DCH-08" ], - "6.1.b": [ - "IAC-09.6" + "ISM-0840": [ + "DCH-08" ], - "19.3": [ - "IRO-01" + "ISM-1160": [ + "DCH-08" ], - "21.2": [ - "IRO-11.2" + "ISM-1361": [ + "DCH-08" ], - "4.1.e": [ - "SAT-01" - ] - }, - "emea-esp-boe-a-2022-7191": { - "Article 5": [ - "GOV-01", - "GOV-01.1", - "GOV-15" + "ISM-1517": [ + "DCH-08" ], - "Article 6.1": [ - "GOV-01" + "ISM-0313": [ + "DCH-09" ], - "Article 6.2": [ - "GOV-01", - "SAT-01" + "ISM-0317": [ + "DCH-09" ], - "Article 13.1": [ - "GOV-01", - "HRS-03", - "HRS-03.1" + "ISM-0348": [ + "DCH-09" ], - "Article 35.1": [ - "GOV-01" + "ISM-0351": [ + "DCH-09" ], - "Article 27": [ - "GOV-01.1", - "GOV-03" + "ISM-0352": [ + "DCH-09" ], - "Article 12.1": [ - "GOV-02" + "ISM-0354": [ + "DCH-09" ], - "Article 12.1(a)": [ - "GOV-02" + "ISM-0357": [ + "DCH-09" ], - "Article 12.1(b)": [ - "GOV-02" + "ISM-0359": [ + "DCH-09" ], - "Article 12.1(c)": [ - "GOV-02" + "ISM-0361": [ + "DCH-09" ], - "Article 12.1(d)": [ - "GOV-02" + "ISM-0362": [ + "DCH-09" ], - "Article 12.1(e)": [ - "GOV-02" + "ISM-0835": [ + "DCH-09" ], - "Article 12.1(f)": [ - "GOV-02" + "ISM-0836": [ + "DCH-09" ], - "Article 12.2": [ - "GOV-02" + "ISM-0947": [ + "DCH-09", + "DCH-17" ], - "Article 12.6": [ - "GOV-02" + "ISM-1065": [ + "DCH-09" ], - "Article 12.6(a)": [ - "GOV-02" + "ISM-1067": [ + "DCH-09" ], - "Article 12.6(b)": [ - "GOV-02" + "ISM-1287": [ + "DCH-09", + "NET-02.3", + "NET-03", + "NET-18" ], - "Article 12.6(c)": [ - "GOV-02" + "ISM-1600": [ + "DCH-09", + "DCH-09.4" ], - "Article 12.6(d)": [ - "GOV-02" + "ISM-1735": [ + "DCH-09" ], - "Article 12.6(e)": [ - "GOV-02" + "ISM-0316": [ + "DCH-09.1" ], - "Article 12.6(f)": [ - "GOV-02" + "ISM-0371": [ + "DCH-09.1" ], - "Article 12.6(g)": [ - "GOV-02" + "ISM-0373": [ + "DCH-09.1" ], - "Article 12.6(h)": [ - "GOV-02" + "ISM-1642": [ + "DCH-09.4" ], - "Article 12.6(i)": [ - "GOV-02" + "ISM-1359": [ + "DCH-12" ], - "Article 12.6(j)": [ - "GOV-02" + "ISM-1713": [ + "DCH-12" ], - "Article 12.6(k)": [ - "GOV-02" + "ISM-0657": [ + "DCH-14" ], - "Article 12.6(l)": [ - "GOV-02" + "ISM-0661": [ + "DCH-14" ], - "Article 12.6(m)": [ - "GOV-02" + "ISM-0663": [ + "DCH-14" ], - "Article 12.6(n)": [ - "GOV-02" + "ISM-0664": [ + "DCH-14" ], - "Article 12.6(ñ)": [ - "GOV-02" + "ISM-0665": [ + "DCH-14", + "NET-01.1" ], - "Article 12.7": [ - "GOV-02" + "ISM-0669": [ + "DCH-14" ], - "Article 32.1": [ - "GOV-06" + "ISM-0675": [ + "DCH-14" ], - "Article 32.2": [ - "GOV-06" + "ISM-1187": [ + "DCH-14" ], - "Article 32.3": [ - "GOV-06" + "ISM-1535": [ + "DCH-14" ], - "Article 5(a)": [ - "GOV-15" + "ISM-0347": [ + "DCH-17" ], - "Article 5(b)": [ - "GOV-15" + "ISM-1778": [ + "DCH-17", + "NET-08.4" ], - "Article 5(c)": [ - "GOV-15" + "ISM-1779": [ + "DCH-17", + "NET-08.4" ], - "Article 5(d)": [ - "GOV-15" + "ISM-2021": [ + "DCH-18.1" ], - "Article 5(e)": [ - "GOV-15" + "ISM-1284": [ + "END-04", + "END-04.4", + "NET-03" ], - "Article 5(f)": [ - "GOV-15" + "ISM-1286": [ + "END-04", + "END-04.4", + "NET-03" ], - "Article 5(g)": [ - "GOV-15" + "ISM-1288": [ + "END-04", + "END-04.4", + "NET-03" ], - "Article 8.1": [ - "GOV-15", - "OPS-01" + "ISM-1289": [ + "END-04", + "END-04.4", + "NET-03" ], - "Article 8.2": [ - "GOV-15", - "OPS-01" + "ISM-1290": [ + "END-04" ], - "Article 8.3": [ - "GOV-15", - "OPS-01" + "ISM-1293": [ + "END-04", + "END-04.4", + "NET-03", + "NET-18" ], - "Article 8.4": [ - "GOV-15", - "OPS-01" + "ISM-1417": [ + "END-04", + "END-04.4" ], - "Article 8.5": [ - "GOV-15", - "OPS-01" + "ISM-1969": [ + "END-04" ], - "Article 28.1": [ - "GOV-15" + "ISM-1782": [ + "END-04.4", + "NET-10" ], - "Article 37": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "ISM-1416": [ + "END-05" ], - "Article 3.3": [ - "GOV-15.1", - "GOV-15.2" + "ISM-1034": [ + "END-07" ], - "Article 28.1(a)": [ - "GOV-15.1" + "ISM-1341": [ + "END-07" ], - "Article 28.1(b)": [ - "GOV-15.1" + "ISM-2035": [ + "HRS-03", + "TDA-06" ], - "Article 28.1(c)": [ - "GOV-15.1" + "ISM-2036": [ + "HRS-03" ], - "Article 28.2": [ - "GOV-15.1" + "ISM-0434": [ + "HRS-04" ], - "Article 28.3": [ - "GOV-15.1" + "ISM-0446": [ + "HRS-04.1", + "HRS-04.3", + "IAC-16" ], - "Article 18": [ - "AST-01", - "IAC-01", - "PES-01" + "ISM-0447": [ + "HRS-04.1", + "HRS-04.3", + "IAC-16" ], - "Article 26": [ - "BCD-01", - "BCD-11" + "ISM-0435": [ + "HRS-04.2" ], - "Article 21.1": [ - "CHG-01", - "CHG-02" + "ISM-0409": [ + "HRS-04.3" ], - "Article 3.1": [ - "CPL-01" + "ISM-0411": [ + "HRS-04.3" ], - "Article 39": [ - "CPL-01" + "ISM-0420": [ + "HRS-04.3", + "HRS-04.4" ], - "Article 38.2": [ - "CPL-01.2" + "ISM-1773": [ + "HRS-04.3" ], - "Article 10.1": [ - "CPL-02", - "MON-01", - "MON-16" + "ISM-0258": [ + "HRS-05" ], - "Article 10.2": [ - "CPL-02" + "ISM-1865": [ + "HRS-05" ], - "Article 10.3": [ - "CPL-02" + "ISM-0820": [ + "HRS-05.1" ], - "Article 31.1": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-0821": [ + "HRS-05.1" ], - "Article 31.2": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-1864": [ + "HRS-05.1" ], - "Article 31.3": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-2095": [ + "HRS-05.1", + "HRS-05.3", + "HRS-05.4" ], - "Article 31.4": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-0229": [ + "HRS-05.2", + "HRS-05.5" ], - "Article 31.5": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-0230": [ + "HRS-05.2", + "HRS-05.5" ], - "Article 31.6": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-0235": [ + "HRS-05.2" ], - "Article 31.7": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-0236": [ + "HRS-05.2" ], - "Article 41.1": [ - "CPL-02.1" + "ISM-0240": [ + "HRS-05.2", + "HRS-05.5" ], - "Article 41.2": [ - "CPL-02.1", - "DCH-02" + "ISM-0264": [ + "HRS-05.2", + "NET-13" ], - "Article 38.1": [ - "CPL-03.1", - "CPL-03.2" + "ISM-0267": [ + "HRS-05.2", + "NET-13", + "NET-18" ], - "Article 30.1": [ - "CFG-01" + "ISM-0588": [ + "HRS-05.2" ], - "Article 30.2": [ - "CFG-01" + "ISM-0931": [ + "HRS-05.2" ], - "Article 20(d)": [ - "CFG-02", - "CFG-03" + "ISM-1078": [ + "HRS-05.2" ], - "Article 21.2": [ - "CFG-02.2", - "CFG-03.1", - "MON-01" + "ISM-1196": [ + "HRS-05.2", + "HRS-05.5" ], - "Article 20(a)": [ - "CFG-03" + "ISM-1198": [ + "HRS-05.2", + "HRS-05.5" ], - "Article 20(b)": [ - "CFG-03" + "ISM-1644": [ + "HRS-05.2", + "PES-12" ], - "Article 20(c)": [ - "CFG-03" + "ISM-1866": [ + "HRS-05.3", + "HRS-05.5" ], - "Article 24.1": [ - "MON-01", - "MON-03" + "ISM-2075": [ + "HRS-05.3" ], - "Article 22.1": [ - "DCH-01", - "DCH-01.2" + "ISM-2099": [ + "HRS-05.3" ], - "Article 22.3": [ - "DCH-01", - "DCH-01.2" + "ISM-2100": [ + "HRS-05.3" ], - "Article 40.1": [ - "DCH-02" + "ISM-2101": [ + "HRS-05.3" ], - "Article 40.2": [ - "DCH-02" + "ISM-0701": [ + "HRS-05.5" ], - "Article 24.2": [ - "DCH-18.1" + "ISM-0866": [ + "HRS-05.5" ], - "Article 15.1": [ - "HRS-01", - "HRS-03.1", - "HRS-03.2", - "HRS-04.2" + "ISM-0870": [ + "HRS-05.5" ], - "Article 13.2": [ - "HRS-02", - "HRS-03", - "HRS-04.2", - "TPM-05.4" + "ISM-0871": [ + "HRS-05.5" ], - "Article 11.1": [ - "HRS-03" + "ISM-0874": [ + "HRS-05.5", + "MDM-01" ], - "Article 11.2": [ - "HRS-03", - "HRS-05", - "HRS-05.1" + "ISM-1082": [ + "HRS-05.5" ], - "Article 11.3": [ - "HRS-03", - "HRS-05", - "HRS-05.1" + "ISM-1083": [ + "HRS-05.5" ], - "Article 13.2(a)": [ - "HRS-03" + "ISM-1084": [ + "HRS-05.5" ], - "Article 13.2(b)": [ - "HRS-03" + "ISM-1145": [ + "HRS-05.5" ], - "Article 13.2(c)": [ - "HRS-03" + "ISM-1366": [ + "HRS-05.5", + "MDM-01" ], - "Article 13.2(d)": [ - "HRS-03", - "OPS-01.1" + "ISM-0430": [ + "HRS-08", + "HRS-09", + "IAC-07", + "IAC-07.1", + "IAC-07.2" ], - "Article 13.3": [ - "HRS-03", - "HRS-11" + "ISM-1546": [ + "IAC-01", + "IAC-02" ], - "Article 13.4": [ - "HRS-03", - "OPS-01.1" + "ISM-2076": [ + "IAC-01" ], - "Article 13.5": [ - "HRS-03", - "TPM-04", - "TPM-05.4" + "ISM-2077": [ + "IAC-01" ], - "Article 16.1": [ - "HRS-03.2" + "ISM-2013": [ + "IAC-01.2" ], - "Article 16.2": [ - "HRS-03.2" + "ISM-2014": [ + "IAC-01.2" ], - "Article 16.3": [ - "HRS-03.2" + "ISM-0414": [ + "IAC-02" ], - "Article 24.3": [ + "ISM-0415": [ "IAC-02", - "IAC-03" + "IAC-02.1" ], - "Article 17": [ - "IAC-08", - "IAC-21" + "ISM-1619": [ + "IAC-02.1" ], - "Article 20": [ - "IAC-21" + "ISM-1055": [ + "IAC-02.2" ], - "Article 25.1": [ - "IRO-01", - "IRO-02", - "IRO-04" + "ISM-1603": [ + "IAC-02.2", + "IAC-04" ], - "Article 25.2": [ - "IRO-02", - "IRO-04", - "IRO-09", - "IRO-10" + "ISM-1583": [ + "IAC-03" ], - "Article 33.4": [ - "IRO-02", - "IRO-02.4", - "IRO-10" + "ISM-0974": [ + "IAC-06" ], - "Article 33.3": [ - "IRO-07" + "ISM-1173": [ + "IAC-06" ], - "Article 33.2": [ - "IRO-10" + "ISM-1401": [ + "IAC-06" ], - "Article 33.7": [ - "IRO-10" + "ISM-1504": [ + "IAC-06" ], - "Article 23": [ - "NET-01" + "ISM-1505": [ + "IAC-06" ], - "Article 8 (end)": [ - "PRM-07" + "ISM-1559": [ + "IAC-06" ], - "Article 36": [ - "PRM-07", - "SEA-07.1" + "ISM-1560": [ + "IAC-06" ], - "Article 7.1": [ - "RSK-01" + "ISM-1561": [ + "IAC-06" ], - "Article 7.2": [ - "RSK-01" + "ISM-1679": [ + "IAC-06" ], - "Article 3.2": [ - "RSK-03", - "RSK-04" + "ISM-1680": [ + "IAC-06" ], - "Article 14.1": [ - "RSK-04" + "ISM-1681": [ + "IAC-06" ], - "Article 14.2": [ - "RSK-04", - "RSK-06", - "RSK-06.1" + "ISM-1682": [ + "IAC-06" ], - "Article 14.3": [ - "RSK-06", - "RSK-06.1" + "ISM-1683": [ + "IAC-06" ], - "Article 29": [ - "SEA-01", - "SEA-02" + "ISM-1685": [ + "IAC-06" ], - "Article 4": [ - "SEA-02.1" + "ISM-1872": [ + "IAC-06" ], - "Article 9.1": [ - "SEA-03" + "ISM-1873": [ + "IAC-06" ], - "Article 9.1(a)": [ - "SEA-03" + "ISM-1874": [ + "IAC-06" ], - "Article 9.1(b)": [ - "SEA-03" + "ISM-1892": [ + "IAC-06" ], - "Article 9.2": [ - "SEA-03" + "ISM-1893": [ + "IAC-06" ], - "Article 22.2": [ - "OPS-01.1" + "ISM-1894": [ + "IAC-06" ], - "Article 19.1": [ - "TDA-01" + "ISM-2011": [ + "IAC-06" ], - "Article 19.2": [ - "TDA-01" + "ISM-1746": [ + "IAC-08" ], - "Article 19.2(a)": [ - "TDA-01" + "ISM-1852": [ + "IAC-08" ], - "Article 19.2(b)": [ - "TDA-01" + "ISM-2093": [ + "IAC-08" ], - "Article 19.2(c)": [ - "TDA-01" + "ISM-1227": [ + "IAC-10" ], - "Article 19.3": [ - "TDA-01" - ] - }, - "emea-esp-decree-1720-2007": { - "8": [ - "PRI-02", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.2" + "ISM-1593": [ + "IAC-10" ], - "12": [ - "PRI-03" + "ISM-1594": [ + "IAC-10" ], - "20": [ - "TPM-03", - "TPM-05" + "ISM-1595": [ + "IAC-10" ], - "21": [ - "TPM-03", - "TPM-05" + "ISM-0417": [ + "IAC-10.1" ], - "22": [ - "PRI-05" + "ISM-0421": [ + "IAC-10.1", + "IAC-18" ], - "23": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3" + "ISM-0422": [ + "IAC-10.1", + "IAC-18" ], - "24": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3" + "ISM-1557": [ + "IAC-10.1" ], - "26": [ - "PRI-06.4" + "ISM-1558": [ + "IAC-10.1" ], - "27": [ - "PRI-06" + "ISM-1596": [ + "IAC-10.1" ], - "28": [ - "PRI-06" + "ISM-1795": [ + "IAC-10.1" ], - "29": [ - "PRI-06" + "ISM-2078": [ + "IAC-10.4" ], - "31": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "ISM-0418": [ + "IAC-10.5" ], - "32": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "ISM-1402": [ + "IAC-10.5" ], - "60": [ - "PRI-15" + "ISM-1590": [ + "IAC-10.5" ], - "Inferred": [ - "PRI-01" + "ISM-1597": [ + "IAC-10.5" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-esp-decree-311-2022": { - "4": [ - "SEA-02.1" + "ISM-1686": [ + "IAC-10.5" ], - "5": [ - "GOV-01", - "GOV-01.1", - "GOV-15" + "ISM-1304": [ + "IAC-10.8" ], - "17": [ - "IAC-08", - "IAC-21" + "ISM-1806": [ + "IAC-10.8" ], - "18": [ - "AST-01", - "IAC-01", - "PES-01" + "ISM-2044": [ + "IAC-10.8", + "TDA-09.6" ], - "20": [ + "ISM-0441": [ + "IAC-15", "IAC-21" ], - "23": [ - "NET-01" - ], - "26": [ - "BCD-01", - "BCD-11" + "ISM-0443": [ + "IAC-15" ], - "27": [ - "GOV-01.1", - "GOV-03" + "ISM-1832": [ + "IAC-15" ], - "29": [ - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-1834": [ + "IAC-15" ], - "36": [ - "PRM-07", - "SEA-07.1" + "ISM-1845": [ + "IAC-15" ], - "37": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" + "ISM-1940": [ + "IAC-15" ], - "39": [ - "CPL-01" + "ISM-1941": [ + "IAC-15" ], - "13.1": [ - "GOV-01", - "HRS-03", - "HRS-03.1" + "ISM-1942": [ + "IAC-15" ], - "35.1": [ - "GOV-01" + "ISM-1649": [ + "IAC-15.1", + "IAC-16" ], - "6.1": [ - "GOV-01" + "ISM-1404": [ + "IAC-15.3" ], - "6.2": [ - "GOV-01", - "SAT-01" + "ISM-1648": [ + "IAC-15.3", + "IAC-16", + "IAC-17" ], - "12.1": [ - "GOV-02" + "ISM-1591": [ + "IAC-15.6", + "NET-14.8" ], - "12.1(a)": [ - "GOV-02" + "ISM-1610": [ + "IAC-15.9" ], - "12.1(b)": [ - "GOV-02" + "ISM-1611": [ + "IAC-15.9" ], - "12.1(c)": [ - "GOV-02" + "ISM-1612": [ + "IAC-15.9" ], - "12.1(d)": [ - "GOV-02" + "ISM-1613": [ + "IAC-15.9" ], - "12.1(e)": [ - "GOV-02" + "ISM-1614": [ + "IAC-15.9" ], - "12.1(f)": [ - "GOV-02" + "ISM-1615": [ + "IAC-15.9" ], - "12.2": [ - "GOV-02" + "ISM-0445": [ + "IAC-16", + "IAC-16.4" ], - "12.6": [ - "GOV-02" + "ISM-1175": [ + "IAC-16", + "IAC-21.2" ], - "12.6(a)": [ - "GOV-02" + "ISM-1507": [ + "IAC-16" ], - "12.6(b)": [ - "GOV-02" + "ISM-1508": [ + "IAC-16" ], - "12.6(c)": [ - "GOV-02" + "ISM-1509": [ + "IAC-16" ], - "12.6(d)": [ - "GOV-02" + "ISM-1620": [ + "IAC-16" ], - "12.6(e)": [ - "GOV-02" + "ISM-1687": [ + "IAC-16", + "SEA-22" ], - "12.6(f)": [ - "GOV-02" + "ISM-1688": [ + "IAC-16" ], - "12.6(g)": [ - "GOV-02" + "ISM-1689": [ + "IAC-16" ], - "12.6(h)": [ - "GOV-02" + "ISM-1835": [ + "IAC-16" ], - "12.6(i)": [ - "GOV-02" + "ISM-1939": [ + "IAC-16" ], - "12.6(j)": [ - "GOV-02" + "ISM-1827": [ + "IAC-16.4" ], - "12.6(k)": [ - "GOV-02" + "ISM-1842": [ + "IAC-16.4" ], - "12.6(l)": [ - "GOV-02" + "ISM-1647": [ + "IAC-17" ], - "12.6(m)": [ - "GOV-02" + "ISM-1898": [ + "IAC-20.4" ], - "12.6(n)": [ - "GOV-02" + "ISM-0611": [ + "IAC-21", + "NET-03" ], - "12.6(ñ)": [ - "GOV-02" + "ISM-1705": [ + "IAC-21" ], - "12.7": [ - "GOV-02" + "ISM-1706": [ + "IAC-21" ], - "32.1": [ - "GOV-06" + "ISM-1707": [ + "IAC-21" ], - "32.2": [ - "GOV-06" + "ISM-1708": [ + "IAC-21" ], - "32.3": [ - "GOV-06" + "ISM-1833": [ + "IAC-21" ], - "28.1": [ - "GOV-15" + "ISM-1883": [ + "IAC-21.2" ], - "5(a)": [ - "GOV-15" + "ISM-2048": [ + "IAC-21.5" ], - "5(b)": [ - "GOV-15" + "ISM-1403": [ + "IAC-22" ], - "5(c)": [ - "GOV-15" + "ISM-0428": [ + "IAC-24" ], - "5(d)": [ - "GOV-15" + "ISM-0853": [ + "IAC-25" ], - "5(e)": [ - "GOV-15" + "ISM-0137": [ + "IRO-01", + "IRO-08", + "IRO-09", + "IRO-10" ], - "5(f)": [ - "GOV-15" + "ISM-0576": [ + "IRO-01", + "IRO-04" ], - "5(g)": [ - "GOV-15" + "ISM-1609": [ + "IRO-01", + "IRO-08", + "IRO-09", + "IRO-10" ], - "8.1": [ - "GOV-15", - "OPS-01" + "ISM-1618": [ + "IRO-01", + "IRO-02", + "IRO-07" ], - "8.2": [ - "GOV-15", - "OPS-01" + "ISM-0123": [ + "IRO-02", + "IRO-10" ], - "8.3": [ - "GOV-15", - "OPS-01" + "ISM-0141": [ + "IRO-02" ], - "8.4": [ - "GOV-15", - "OPS-01" + "ISM-0917": [ + "IRO-02", + "IRO-04" ], - "8.5": [ - "GOV-15", - "OPS-01" + "ISM-1803": [ + "IRO-02", + "IRO-09" ], - "28.1(a)": [ - "GOV-15.1" + "ISM-1819": [ + "IRO-02" ], - "28.1(b)": [ - "GOV-15.1" + "ISM-1626": [ + "IRO-02.2", + "THR-04", + "THR-05" ], - "28.1(c)": [ - "GOV-15.1" + "ISM-0043": [ + "IRO-04" ], - "28.2": [ - "GOV-15.1" + "ISM-0133": [ + "IRO-04.1", + "IRO-12", + "IRO-12.3", + "IRO-12.4" ], - "28.3": [ - "GOV-15.1" + "ISM-0138": [ + "IRO-08" ], - "3.3": [ - "GOV-15.1", - "GOV-15.2" + "ISM-1731": [ + "IRO-08" ], - "21.1": [ - "CHG-01", - "CHG-02" + "ISM-1732": [ + "IRO-08" ], - "3.1": [ - "CPL-01" + "ISM-0125": [ + "IRO-09" ], - "38.2": [ - "CPL-01.2" + "ISM-1880": [ + "IRO-10" ], - "10.1": [ - "CPL-02", - "MON-01", - "MON-01.16", - "MON-16" + "ISM-1881": [ + "IRO-10" ], - "10.2": [ - "CPL-02" + "ISM-1569": [ + "IRO-10.4", + "TPM-04", + "TPM-05", + "TPM-06" ], - "10.3": [ - "CPL-02" + "ISM-0140": [ + "IRO-14" ], - "31.1": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-0651": [ + "IRO-15" ], - "31.2": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-0652": [ + "IRO-15" ], - "31.3": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-1389": [ + "IRO-15", + "NET-03" ], - "31.4": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-1970": [ + "IRO-15" ], - "31.5": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-0280": [ + "IAO-01" ], - "31.6": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-1525": [ + "IAO-01", + "IAO-07" ], - "31.7": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "ISM-1967": [ + "IAO-02" ], - "41.1": [ - "CPL-02.1" + "ISM-1971": [ + "IAO-02" ], - "41.2": [ - "CPL-02.1", - "DCH-02" + "ISM-1972": [ + "IAO-02" ], - "38.1": [ - "CPL-03.1", - "CPL-03.2" + "ISM-1137": [ + "IAO-02.2" ], - "30.1": [ - "CFG-01" + "ISM-1570": [ + "IAO-02.2" ], - "30.2": [ - "CFG-01" + "ISM-2019": [ + "IAO-02.2" ], - "20(d)": [ - "CFG-02", - "CFG-03" + "ISM-1563": [ + "IAO-02.4" ], - "21.2": [ - "CFG-02.2", - "CFG-03.1", - "MON-01", - "MON-01.16" + "ISM-0041": [ + "IAO-03" ], - "20(a)": [ - "CFG-03" + "ISM-0432": [ + "IAO-03" ], - "20(b)": [ - "CFG-03" + "ISM-1912": [ + "IAO-03" ], - "20(c)": [ - "CFG-03" + "ISM-0072": [ + "IAO-03.2", + "TPM-05" ], - "24.1": [ - "MON-01", - "MON-01.16", - "MON-03" + "ISM-1451": [ + "IAO-03.2", + "TPM-05" ], - "22.1": [ - "DCH-01", - "DCH-01.2" + "ISM-1571": [ + "IAO-03.2", + "TPM-05" ], - "22.3": [ - "DCH-01", - "DCH-01.2" + "ISM-1573": [ + "IAO-03.2", + "TPM-04.1", + "TPM-05" ], - "40.1": [ - "DCH-02" + "ISM-1574": [ + "IAO-03.2", + "TPM-05" ], - "40.2": [ - "DCH-02" + "ISM-1575": [ + "IAO-03.2", + "TPM-05" ], - "24.2": [ - "DCH-18.1" + "ISM-1564": [ + "IAO-05" ], - "15.1": [ - "HRS-01", - "HRS-03.1", - "HRS-03.2", - "HRS-04.2" + "ISM-1968": [ + "IAO-07" ], - "13.2": [ - "HRS-02", - "HRS-03", - "HRS-04.2", - "TPM-05.4" + "ISM-0305": [ + "MNT-01", + "MNT-06", + "MNT-08" ], - "11.1": [ - "HRS-03" + "ISM-1079": [ + "MNT-02" ], - "11.2": [ - "HRS-03", - "HRS-05", - "HRS-05.1" + "ISM-0307": [ + "MNT-06" ], - "11.3": [ - "HRS-03", - "HRS-05", - "HRS-05.1" + "ISM-0306": [ + "MNT-06.1" ], - "13.2(a)": [ - "HRS-03" + "ISM-0310": [ + "MNT-09" ], - "13.2(b)": [ - "HRS-03" + "ISM-1598": [ + "MNT-10" ], - "13.2(c)": [ - "HRS-03" + "ISM-0682": [ + "MDM-01" ], - "13.2(d)": [ - "HRS-03", - "OPS-01.1" + "ISM-0687": [ + "MDM-01" ], - "13.3": [ - "HRS-03", - "HRS-11" + "ISM-0863": [ + "MDM-01" ], - "13.4": [ - "HRS-03", - "OPS-01.1" + "ISM-0864": [ + "MDM-01" ], - "13.5": [ - "HRS-03", - "TPM-04", - "TPM-05.4" + "ISM-1085": [ + "MDM-01" ], - "16.1": [ - "HRS-03.2" + "ISM-1195": [ + "MDM-01" ], - "16.2": [ - "HRS-03.2" + "ISM-1533": [ + "MDM-01" ], - "16.3": [ - "HRS-03.2" + "ISM-0869": [ + "MDM-03" ], - "24.3": [ - "IAC-02", - "IAC-03" + "ISM-0702": [ + "MDM-05" ], - "25.1": [ - "IRO-01", - "IRO-02", - "IRO-04" + "ISM-0694": [ + "MDM-06" ], - "25.2": [ - "IRO-02", - "IRO-04", - "IRO-09", - "IRO-10" + "ISM-1400": [ + "MDM-06" ], - "33.4": [ - "IRO-02", - "IRO-02.4", - "IRO-10" + "ISM-1482": [ + "MDM-06" ], - "33.3": [ - "IRO-07" + "ISM-0521": [ + "NET-01" ], - "33.2": [ - "IRO-10" + "ISM-0629": [ + "NET-01", + "NET-03" ], - "33.7": [ - "IRO-10" + "ISM-1186": [ + "NET-01" ], - "8 (end)": [ - "PRM-07" + "ISM-1428": [ + "NET-01" ], - "7.1": [ - "RSK-01" + "ISM-1429": [ + "NET-01" ], - "7.2": [ - "RSK-01" + "ISM-1430": [ + "NET-01" ], - "3.2": [ - "RSK-03", - "RSK-04" + "ISM-1711": [ + "NET-01" ], - "14.1": [ - "RSK-04" + "ISM-1712": [ + "NET-01" ], - "14.2": [ - "RSK-04", - "RSK-06", - "RSK-06.1" + "ISM-1774": [ + "NET-01" ], - "14.3": [ - "RSK-06", - "RSK-06.1" + "ISM-1783": [ + "NET-01" ], - "22.2": [ - "OPS-01.1" + "ISM-1019": [ + "NET-02.1" ], - "19.1": [ - "TDA-01" + "ISM-1431": [ + "NET-02.1" ], - "19.2": [ - "TDA-01" + "ISM-1436": [ + "NET-02.1" ], - "19.2(a)": [ - "TDA-01" + "ISM-1805": [ + "NET-02.1" ], - "19.2(b)": [ - "TDA-01" + "ISM-0536": [ + "NET-02.2", + "NET-15" ], - "19.2(c)": [ - "TDA-01" + "ISM-0597": [ + "NET-02.3" ], - "19.3": [ - "TDA-01" - ] - }, - "emea-esp-ccn-stic-825-2023": { - "9": [ - "CPL-02", - "CPL-03.1", - "DCH-18", - "NET-14.5", - "PRM-01" + "ISM-0610": [ + "NET-02.3" ], - "6.1 [ORG.1]": [ - "GOV-01", - "GOV-02" + "ISM-0626": [ + "NET-02.3" ], - "6.2 [ORG.2]": [ - "GOV-02" + "ISM-0635": [ + "NET-02.3" ], - "7.6.2 [OP.MON.2]": [ - "GOV-05" + "ISM-0670": [ + "NET-02.3" ], - "7.3.1 [OP.EXP.1]": [ - "AST-02" + "ISM-1521": [ + "NET-02.3", + "NET-03" ], - "8.3.2 [MP.EQ.2]": [ - "AST-06" + "ISM-1522": [ + "NET-02.3", + "NET-03" ], - "8.5.5 [MP.SI.5]": [ - "AST-09", - "DCH-08" + "ISM-1523": [ + "NET-02.3" ], - "7.5.1 [OP.CONT.1]": [ - "BCD-01" + "ISM-0612": [ + "NET-03" ], - "7.5.2 [OP.CONT.2]": [ - "BCD-01" + "ISM-0613": [ + "NET-03" ], - "7.5.3 [OP.CONT.3]": [ - "BCD-04" + "ISM-0616": [ + "NET-03" ], - "8.1.8 [MP.IF.8]": [ - "BCD-08", - "BCD-09" + "ISM-0619": [ + "NET-03" ], - "8.3.4 [MP.EQ.4]": [ - "BCD-08", - "BCD-09" + "ISM-0622": [ + "NET-03" ], - "8.4.4 [MP.COM.4]": [ - "BCD-08", - "NET-06" + "ISM-0628": [ + "NET-03" ], - "8.8.4 [MP.S.4]": [ - "BCD-08", - "BCD-09" + "ISM-0631": [ + "NET-03" ], - "8.7.7 [MP.INFO.7]": [ - "BCD-11" + "ISM-0634": [ + "NET-03" ], - "7.1.4 [OP.PL.4]": [ - "CAP-01" + "ISM-0637": [ + "NET-03", + "NET-08.1" ], - "7.3.5 [OP.EXP.5]": [ - "CHG-01" + "ISM-0639": [ + "NET-03" ], - "7.1.5 [OP.PL.5]": [ - "CPL-01" + "ISM-1037": [ + "NET-03" ], - "7.3.3 [OP.EXP.3]": [ - "CFG-01" + "ISM-1192": [ + "NET-03" ], - "7.3.2 [OP.EXP.2]": [ - "CFG-02" + "ISM-1427": [ + "NET-03" ], - "7.3.8 [OP.EXP.8]": [ - "MON-01", - "MON-01.4", - "MON-01.16", - "MON-02.2", - "MON-03" + "ISM-1520": [ + "NET-03" ], - "7.6.1 [OP.MON.1]": [ - "MON-01.1", - "END-07", - "NET-08", - "NET-08.2" + "ISM-1528": [ + "NET-03" ], - "8.7.5 [MP.INFO.5]": [ - "MON-07" + "ISM-0546": [ + "NET-03.2" ], - "7.3.10 [OP.EXP.10]": [ - "MON-08" + "ISM-0643": [ + "NET-04" ], - "8.4.2 [MP.COM.2]": [ - "CRY-01", - "NET-01" + "ISM-0645": [ + "NET-04" ], - "8.4.3 [MP.COM.3]": [ - "CRY-01" + "ISM-1157": [ + "NET-04" ], - "8.5.2 [MP.SI.2]": [ - "CRY-01" + "ISM-1158": [ + "NET-04" ], - "8.7.3 [MP.INFO.3]": [ - "CRY-01" + "ISM-1386": [ + "NET-04" ], - "8.7.4 [MP.INFO.4]": [ - "CRY-01" + "ISM-2068": [ + "NET-04.1" ], - "7.3.11 [OP.EXP.11]": [ - "CRY-09" + "ISM-1181": [ + "NET-06" ], - "8.5.3 [MP.SI.3]": [ - "DCH-01", - "DCH-01.1", - "DCH-07.1" + "ISM-1577": [ + "NET-06" ], - "8.7.2 [MP.INFO.2]": [ - "DCH-02" + "ISM-0529": [ + "NET-06.2" ], - "8.5.1 [MP.SI.1]": [ - "DCH-04" + "ISM-0530": [ + "NET-06.2" ], - "8.5.4 [MP.SI.4]": [ - "DCH-07" + "ISM-0535": [ + "NET-06.2" ], - "8.7.6 [MP.INFO.6]": [ - "DCH-09" + "ISM-1364": [ + "NET-06.2" ], - "8.3.1 [MP.EQ.1]": [ - "END-01" + "ISM-1532": [ + "NET-06.2" ], - "7.3.6 [OP.EXP.6]": [ - "END-04" + "ISM-1863": [ + "NET-06.5" ], - "6.4 [ORG.4]": [ - "HRS-03" + "ISM-1028": [ + "NET-08" ], - "8.2.1 [MP.PER.1]": [ - "HRS-03" + "ISM-1030": [ + "NET-08" ], - "8.2.2 [MP.PER.2]": [ - "HRS-03", - "HRS-05" + "ISM-1627": [ + "NET-08" ], - "7.2.3 [OP.ACC.3]": [ - "HRS-11" + "ISM-1628": [ + "NET-08" ], - "8.2.5 [MP.PER.5]": [ - "HRS-13.2", - "HRS-13.3", - "HRS-13.4" + "ISM-0574": [ + "NET-10", + "NET-10.3", + "NET-13" ], - "7.2.2 [OP.ACC.2]": [ - "IAC-01" + "ISM-0861": [ + "NET-10", + "NET-13" ], - "7.2.4 [OP.ACC.4]": [ - "IAC-01", - "IAC-08" + "ISM-1026": [ + "NET-10", + "NET-13" ], - "7.2.1 [OP.ACC.1]": [ - "IAC-07" + "ISM-1027": [ + "NET-10", + "NET-13" ], - "7.2.5 [OP.ACC.5]": [ - "IAC-10", - "IAC-10.1", - "IAC-10.5", - "IAC-10.11" + "ISM-1151": [ + "NET-10", + "NET-10.3", + "NET-13" ], - "7.3.7 [OP.EXP.7]": [ - "IRO-01", - "IRO-02" + "ISM-1183": [ + "NET-10", + "NET-10.3", + "NET-13" ], - "7.3.9 [OP.EXP.9]": [ - "IRO-02" + "ISM-1540": [ + "NET-10", + "NET-13", + "NET-20.4" ], - "7.3.4 [OP.EXP.4]": [ - "MNT-01" + "ISM-1799": [ + "NET-10", + "NET-10.3" ], - "8.3.3 [MP.EQ.3]": [ - "MDM-01" + "ISM-2017": [ + "NET-10" ], - "8.4.1 [MP.COM.1]": [ - "NET-01" + "ISM-1432": [ + "NET-10.4" ], - "8.8.3 [MP.S.3]": [ - "NET-02.1" + "ISM-0269": [ + "NET-13" ], - "8.8.1 [MP.S.1]": [ + "ISM-0490": [ "NET-13" ], - "7.2.7 [OP.ACC.7]": [ - "NET-14", - "NET-14.5" + "ISM-0494": [ + "NET-13" ], - "8.1.1 [MP.IF.1]": [ - "PES-01.1", - "PES-02", - "PES-02.1", - "PES-03" + "ISM-0496": [ + "NET-13" ], - "8.1.2 [MP.IF.2]": [ - "PES-06", - "PES-06.2" + "ISM-0498": [ + "NET-13" ], - "8.1.7 [MP.IF.7]": [ - "PES-06" + "ISM-0565": [ + "NET-13" ], - "8.1.3 [MP.IF.3]": [ - "PES-07", - "PES-12" + "ISM-0569": [ + "NET-13" ], - "8.1.4 [MP.IF.4]": [ - "PES-07", - "PES-07.1" + "ISM-0570": [ + "NET-13", + "NET-18.1" ], - "8.1.6 [MP.IF.6]": [ - "PES-07.6" + "ISM-0571": [ + "NET-13" ], - "8.1.5 [MP.IF.5]": [ - "PES-08" + "ISM-0572": [ + "NET-13" ], - "8.7.1 [MP.INFO.1]": [ - "PRI-01" + "ISM-0998": [ + "NET-13" ], - "7.1.3 [OP.PL.3]": [ - "PRM-05", - "TDA-01" + "ISM-1000": [ + "NET-13" ], - "7.1.1 [OP.PL.1]": [ - "RSK-04" + "ISM-1023": [ + "NET-13" ], - "7.1.2 [OP.PL.2]": [ - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-1024": [ + "NET-13" ], - "7.2.6 [OP.ACC.6]": [ - "SEA-17" + "ISM-1089": [ + "NET-13" ], - "6.3 [ORG.3]": [ - "OPS-01.1" + "ISM-0487": [ + "NET-14" ], - "8.2.3 [MP.PER.3]": [ - "SAT-01", - "SAT-02", - "SAT-03" + "ISM-0488": [ + "NET-14" ], - "8.2.4 [MP.PER.4]": [ - "SAT-01", - "SAT-02", - "SAT-03" + "ISM-0489": [ + "NET-14" ], - "8.6.1 [MP.SW.1]": [ - "TDA-01", - "TDA-02.3", - "TDA-06.3" + "ISM-0225": [ + "NET-15" ], - "8.6.2 [MP.SW.2]": [ - "TDA-06.5", - "TDA-09" + "ISM-1315": [ + "NET-15" ], - "7.4.3 [OP.EXT.3]": [ - "TDA-17.1", - "TPM-03" + "ISM-1317": [ + "NET-15" ], - "7.4.1 [OP.EXT.1]": [ - "TPM-01", - "TPM-03", - "TPM-05" + "ISM-1320": [ + "NET-15" ], - "7.4.2 [OP.EXT.2]": [ - "TPM-10" + "ISM-1322": [ + "NET-15" ], - "8.8.2 [MP.S.2]": [ - "WEB-01" - ] - }, - "emea-che-fadp-2025": { - "4": [ - "PRI-04", - "PRI-04.1", - "PRI-05" + "ISM-1323": [ + "NET-15" ], - "5": [ - "DCH-22.1", - "PRI-06.1" + "ISM-1324": [ + "NET-15" ], - "6": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-1327": [ + "NET-15" ], - "7": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-1330": [ + "NET-15" ], - "8": [ - "PRI-06" + "ISM-1334": [ + "NET-15" ], - "11": [ - "PRI-15" + "ISM-1335": [ + "NET-15" ], - "12": [ - "IRO-04.1" + "ISM-1454": [ + "NET-15" ], - "Inferred": [ - "PRI-01" + "ISM-1543": [ + "NET-15" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-tur-lppd-2016": { - "5": [ - "PRI-05" + "ISM-1013": [ + "NET-15.4" ], - "6": [ - "PRI-05.4" + "ISM-1338": [ + "NET-15.4" ], - "7": [ - "PRI-05" + "ISM-0829": [ + "NET-15.5" ], - "8": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-0649": [ + "NET-18" ], - "10": [ - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1" + "ISM-0659": [ + "NET-18" ], - "11": [ - "PRI-06" + "ISM-0958": [ + "NET-18" ], - "12": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-0961": [ + "NET-18" ], - "16": [ - "PRI-15" + "ISM-0963": [ + "NET-18" ], - "Inferred": [ - "PRI-01" + "ISM-1171": [ + "NET-18" ], - "Expectation": [ - "PRI-01" - ] - }, - "emea-uae-niaf-2023": { - "3.1.1": [ - "AST-02" + "ISM-1234": [ + "NET-18" ], - "3.4": [ - "BCD-01", - "BCD-02" + "ISM-1236": [ + "NET-18" ], - "3.4.1": [ - "BCD-01", - "BCD-04" + "ISM-1237": [ + "NET-18", + "NET-18.1" ], - "3.4.2": [ - "BCD-01", - "BCD-01.5" + "ISM-1502": [ + "NET-18" ], - "3.4.3": [ - "BCD-01", - "BCD-02.1" + "ISM-1524": [ + "NET-18" ], - "3.2.1": [ - "CFG-02", - "SEA-01" + "ISM-1965": [ + "NET-18" ], - "3.2.3": [ - "HRS-01", - "HRS-01.1" + "ISM-0260": [ + "NET-18.1" ], - "3.3": [ - "IRO-01" + "ISM-0263": [ + "NET-18.2" ], - "3.3.2": [ - "IRO-01", - "IRO-02" + "ISM-0810": [ + "PES-01" ], - "3.3.1": [ - "IRO-02", - "IRO-09" + "ISM-1296": [ + "PES-03" ], - "3.3.3": [ - "IRO-10", - "IRO-10.2" + "ISM-0813": [ + "PES-03.4" ], - "3.2": [ - "IAO-05" + "ISM-1053": [ + "PES-03.4" ], - "3.2.2": [ - "PES-01", - "PES-03" + "ISM-1074": [ + "PES-03.4" ], - "3.1.2": [ - "RSK-08" + "ISM-1530": [ + "PES-03.4" ], - "3.1.3": [ - "VPM-06" - ] - }, - "emea-gbr-caf-4-0": { - "A1.a": [ - "GOV-01.1" + "ISM-0164": [ + "PES-04.1", + "PES-06", + "PES-06.3" ], - "A1.c": [ - "GOV-01.1", - "GOV-04" + "ISM-1123": [ + "PES-07.3" ], - "A1": [ - "GOV-02" + "ISM-0181": [ + "PES-12.1" ], - "B1": [ - "GOV-02" + "ISM-0187": [ + "PES-12.1" ], - "B1.b": [ - "GOV-02" + "ISM-0194": [ + "PES-12.1" ], - "B1.a": [ - "GOV-03" + "ISM-0195": [ + "PES-12.1" ], - "A1.b": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "ISM-0198": [ + "PES-12.1" ], - "B4.a": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "SEA-01" + "ISM-0206": [ + "PES-12.1" ], - "A2.c": [ - "GOV-19", - "CPL-01.4" + "ISM-0208": [ + "PES-12.1" ], - "A3": [ - "AST-01", - "AST-01.1" + "ISM-0211": [ + "PES-12.1" ], - "A3.a (point 2)": [ - "AST-01.1" + "ISM-0213": [ + "PES-12.1" ], - "A3.a (point 4)": [ - "AST-01.2", - "AST-03" + "ISM-0216": [ + "PES-12.1" ], - "A3.a (point 1)": [ - "AST-02" + "ISM-0217": [ + "PES-12.1" ], - "B3.a": [ - "AST-04", - "DCH-02", - "DCH-06.2", - "DCH-14.3", - "DCH-19" + "ISM-0218": [ + "PES-12.1" ], - "B5.a": [ - "BCD-01" + "ISM-0926": [ + "PES-12.1" ], - "A3.a (point 3)": [ - "BCD-02" + "ISM-1095": [ + "PES-12.1" ], - "B5.c": [ - "BCD-11" + "ISM-1096": [ + "PES-12.1" ], - "B4": [ - "CFG-01", - "CFG-02" + "ISM-1098": [ + "PES-12.1" ], - "B4.c": [ - "CFG-01" + "ISM-1100": [ + "PES-12.1" ], - "B4.b": [ - "CFG-02" + "ISM-1101": [ + "PES-12.1" ], - "C1": [ - "MON-01" + "ISM-1102": [ + "PES-12.1" ], - "C1.a": [ - "MON-01.4", - "MON-01.8", - "MON-03" + "ISM-1103": [ + "PES-12.1" ], - "C1.c": [ - "MON-01.4" + "ISM-1105": [ + "PES-12.1" ], - "C1.b": [ - "MON-08", - "MON-10" + "ISM-1107": [ + "PES-12.1", + "PES-16" ], - "C1.f": [ - "MON-16", - "IRO-03", - "THR-09" + "ISM-1109": [ + "PES-12.1" ], - "C1.d": [ - "MON-17" + "ISM-1111": [ + "PES-12.1" ], - "B3.b": [ - "CRY-03" + "ISM-1112": [ + "PES-12.1" ], - "B3.c": [ - "CRY-05" + "ISM-1114": [ + "PES-12.1" ], - "B3": [ - "DCH-01" + "ISM-1115": [ + "PES-12.1" ], - "B3.e": [ - "DCH-09" + "ISM-1116": [ + "PES-12.1" ], - "B3.d": [ - "END-01", - "MDM-01" + "ISM-1119": [ + "PES-12.1" ], - "C1.e": [ - "HRS-03.2" + "ISM-1122": [ + "PES-12.1" ], - "B2": [ - "IAC-01" + "ISM-1130": [ + "PES-12.1" ], - "B2.d": [ - "IAC-01" + "ISM-1133": [ + "PES-12.1" ], - "B2.a": [ - "IAC-02", - "IAC-03" + "ISM-1164": [ + "PES-12.1" ], - "B2.b": [ - "IAC-04" + "ISM-1216": [ + "PES-12.1", + "PES-16" ], - "B2.c": [ - "IAC-16" + "ISM-1639": [ + "PES-12.1" ], - "D1": [ - "IRO-01" + "ISM-1640": [ + "PES-12.1" ], - "D1.b": [ - "IRO-02" + "ISM-1718": [ + "PES-12.1", + "PES-16" ], - "D1.a": [ - "IRO-04" + "ISM-1719": [ + "PES-12.1", + "PES-16" ], - "D1.c": [ - "IRO-06" + "ISM-1720": [ + "PES-12.1", + "PES-16" ], - "D2": [ - "IRO-13" + "ISM-1721": [ + "PES-12.1", + "PES-16" ], - "D2.a": [ - "IRO-13" + "ISM-1820": [ + "PES-12.1" ], - "D2.b": [ - "IRO-13" + "ISM-1821": [ + "PES-12.1" ], - "A2": [ - "RSK-01" + "ISM-1822": [ + "PES-12.1" ], - "A2.a": [ - "RSK-01" + "ISM-0246": [ + "PES-13" ], - "A4": [ - "RSK-09", - "TPM-01" + "ISM-0249": [ + "PES-13" ], - "A4.a": [ - "RSK-09" + "ISM-0250": [ + "PES-13" ], - "B5.b": [ - "SEA-01", - "SEA-01.3" + "ISM-0039": [ + "PRM-01.1" ], - "B5": [ - "SEA-01.3" + "ISM-2004": [ + "PRM-02" ], - "A3.a (point 5)": [ - "SEA-07.1" + "ISM-2020": [ + "PRM-02.1", + "PRM-03" ], - "B6.a": [ - "SAT-01" + "ISM-1739": [ + "PRM-04", + "PRM-05", + "PRM-07", + "SEA-01", + "SEA-02", + "SEA-03" ], - "B6": [ - "SAT-02" + "ISM-1917": [ + "QTS-03" ], - "B6.b": [ - "SAT-03" + "ISM-2073": [ + "QTS-03" ], - "A4.b": [ - "TDA-06" + "ISM-2082": [ + "QTS-04.2" ], - "A2.b": [ - "THR-01", - "THR-09" + "ISM-2083": [ + "QTS-04.2" ], - "C2": [ - "THR-07" + "ISM-1990": [ + "QTS-06.3" ], - "C2.a (point 1)": [ - "THR-07" + "ISM-1991": [ + "QTS-06.3" ], - "C2.a (point 2)": [ - "THR-07" + "ISM-1992": [ + "QTS-06.3" ], - "C2.a (point 3)": [ - "THR-07" + "ISM-1993": [ + "QTS-06.3" ], - "C2.a (point 4)": [ - "THR-07" + "ISM-1994": [ + "QTS-06.3" ], - "C2.a (point 5)": [ - "THR-07" + "ISM-1995": [ + "QTS-06.3" ], - "C2.a (point 6)": [ - "THR-07" + "ISM-1996": [ + "QTS-06.9" ], - "C2.a (point 7)": [ - "THR-07" + "ISM-1203": [ + "RSK-04", + "THR-10" ], - "C2.a (point 8)": [ - "THR-07" + "ISM-0009": [ + "RSK-06.2" ], - "B4.d": [ - "VPM-01" - ] - }, - "emea-gbr-cap-1850-2020": { - "A1": [ - "GOV-01", - "GOV-02" + "ISM-1809": [ + "RSK-06.2" ], - "A5": [ - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5" + "ISM-1567": [ + "RSK-09", + "RSK-09.1", + "TPM-03.1", + "TPM-03.2" ], - "A6": [ - "GOV-15.1", - "GOV-15.2", - "GOV-15.3" + "ISM-1452": [ + "RSK-09.1", + "TPM-02", + "TPM-03" ], - "B4": [ - "GOV-15.2", - "GOV-15.3", - "CFG-01", - "CFG-02", - "CFG-02.5", + "ISM-1743": [ "SEA-01", "SEA-02", - "SEA-03" - ], - "A3": [ - "AST-01" + "SEA-03", + "TPM-03.1" ], - "A4": [ - "AST-01.1", - "BCD-02", - "RSK-09", - "RSK-09.1", - "TDA-06.1", - "TPM-01", - "TPM-02", - "TPM-04", - "TPM-04.1", - "TPM-05.4" + "ISM-1926": [ + "SEA-01" ], - "D1": [ - "BCD-01" + "ISM-1927": [ + "SEA-01" ], - "D2": [ - "BCD-05", - "IRO-13" + "ISM-1460": [ + "SEA-13.1", + "VPM-01" ], - "C1": [ - "MON-01", - "MON-01.8", - "MON-01.16", - "MON-02", - "MON-02.2", - "MON-02.3", - "MON-16" + "ISM-1461": [ + "SEA-13.1" ], - "C2": [ - "MON-01.8", - "MON-02", - "MON-02.2", - "MON-02.3", - "MON-16" + "ISM-1605": [ + "SEA-13.1" ], - "B3": [ - "DCH-01", - "DCH-01.2", - "DCH-02" + "ISM-1606": [ + "SEA-13.1" ], - "A2": [ - "RSK-01", - "RSK-03", - "RSK-04" + "ISM-1607": [ + "SEA-13.1" ], - "B5": [ - "SEA-01", - "SEA-02", - "SEA-03" + "ISM-0408": [ + "SEA-18", + "SEA-18.1", + "SEA-18.2" ], - "B6": [ + "ISM-0252": [ "SAT-01", "SAT-02" - ] - }, - "emea-gbr-cyber-essentials-requirements-3-3": { - "1": [ - "END-05", - "NET-01", - "NET-03" ], - "2": [ - "CFG-01", - "CFG-02", - "IAC-01", - "IAC-02", - "IAC-06", - "IAC-10" + "ISM-2022": [ + "SAT-01" ], - "3": [ - "AST-02.7", - "CFG-04", - "CFG-05", - "END-03", - "IAC-07", - "IAC-08", - "IAC-09.5" + "ISM-1740": [ + "SAT-02", + "SAT-03", + "SAT-03.2" ], - "4": [ - "CFG-03.3", - "END-01", - "END-02", - "END-04", - "END-04.1", - "IRO-15", - "NET-03.6" + "ISM-0817": [ + "SAT-02.2", + "SAT-03.2" ], - "5": [ - "VPM-01", - "VPM-02", - "VPM-05" - ] - }, - "emea-gbr-def-stan-05-138-2024": { - "1100": [ - "GOV-02", - "OPS-01.1" + "ISM-2071": [ + "SAT-02.2" ], - "1101": [ - "GOV-01.1", - "GOV-02", - "GOV-04.1" + "ISM-1565": [ + "SAT-03", + "SAT-03.5" ], - "1102": [ - "GOV-04", - "HRS-03" + "ISM-1780": [ + "SAT-03.8", + "TDA-01" ], - "1103": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "ISM-0938": [ + "TDA-01" ], - "1200": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-06" + "ISM-1797": [ + "TDA-01.1" ], - "1201": [ - "RSK-01" + "ISM-1798": [ + "TDA-01.1", + "TDA-02.4", + "TDA-04", + "TDA-04.1" ], - "1202": [ - "GOV-01.1", - "RSK-04" + "ISM-1730": [ + "TDA-04.2" ], - "1203": [ - "AST-04" + "ISM-2054": [ + "TDA-04.2" ], - "1204": [ - "RSK-01", - "RSK-04", - "THR-01", - "THR-03", - "THR-03.1" + "ISM-2056": [ + "TDA-04.2" ], - "1205": [ - "IAO-01", - "IAO-02", - "IAO-06" + "ISM-2033": [ + "TDA-05" ], - "1206": [ - "CPL-02", - "CPL-02.2", - "CPL-03.2" + "ISM-2043": [ + "TDA-05" + ], + "ISM-0401": [ + "TDA-06" ], - "1300": [ - "AST-01", - "HRS-01" + "ISM-1239": [ + "TDA-06", + "WEB-07", + "WEB-08" ], - "1301": [ - "AST-01", - "AST-02", - "AST-02.9" + "ISM-1419": [ + "TDA-06", + "TDA-07" ], - "1400": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-03" + "ISM-1552": [ + "TDA-06", + "WEB-10" ], - "1401": [ - "TPM-05", - "TPM-05.2" + "ISM-1849": [ + "TDA-06" ], - "1500": [ - "PES-01", - "PES-02", - "PES-03", - "PES-03.3", - "PES-05", - "PES-05.1" + "ISM-1922": [ + "TDA-06" ], - "1501": [ - "PES-19" + "ISM-2032": [ + "TDA-06" ], - "1502": [ - "PES-02.1", - "PES-03.4" + "ISM-2041": [ + "TDA-06", + "TDA-06.7" ], - "1503": [ - "IAC-01.1", - "PES-06.1", - "PES-06.2", - "PES-06.6" + "ISM-2045": [ + "TDA-06" ], - "2100": [ - "GOV-02", - "GOV-03", - "OPS-01.1" + "ISM-2063": [ + "TDA-06" ], - "2101": [ - "GOV-02", - "GOV-03", - "OPS-01.1" + "ISM-2064": [ + "TDA-06" ], - "2200": [ - "IAC-01", - "IAC-01.2", - "IAC-08" + "ISM-2065": [ + "TDA-06" ], - "2201": [ - "IAC-06" + "ISM-2066": [ + "TDA-06" ], - "2202": [ - "AST-01", - "AST-02", - "AST-02.4" + "ISM-2067": [ + "TDA-06" ], - "2203": [ - "MON-01", - "MON-01.15" + "ISM-1238": [ + "TDA-06.2" ], - "2204": [ - "CFG-02", - "CFG-03" + "ISM-2039": [ + "TDA-06.2" ], - "2205": [ - "IAC-21" + "ISM-2025": [ + "TDA-06.3" ], - "2206": [ - "IAC-08", - "IAC-21" + "ISM-2034": [ + "TDA-06.3" ], - "2207": [ - "HRS-11" + "ISM-2102": [ + "TDA-06.3" ], - "2208": [ - "IAC-01" + "ISM-2031": [ + "TDA-06.4" ], - "2209": [ - "IAC-01.2", - "IAC-15.1" + "ISM-1909": [ + "TDA-06.6" ], - "2210": [ - "IAC-01", - "IAC-01.2" + "ISM-2040": [ + "TDA-06.7" ], - "2211": [ - "IAC-10.8" + "ISM-0400": [ + "TDA-07", + "TDA-08" ], - "2212": [ - "IAC-10.11" + "ISM-0402": [ + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4", + "TDA-09.5", + "TDA-10.1" ], - "2213": [ - "IAC-10.4" + "ISM-1754": [ + "TDA-09" ], - "2214": [ - "IAC-22" + "ISM-1850": [ + "TDA-09" ], - "2215": [ - "IAC-02.2" + "ISM-1851": [ + "TDA-09" ], - "2216": [ - "MON-03.3", - "IAC-21.5" + "ISM-2057": [ + "TDA-09", + "TDA-09.4" ], - "2217": [ - "IAC-01.3" + "ISM-2060": [ + "TDA-09" ], - "2218": [ - "IAC-02", - "IAC-15.1" + "ISM-2061": [ + "TDA-09" ], - "2300": [ - "DCH-01" + "ISM-2062": [ + "TDA-09" ], - "2301": [ - "AST-04", - "DCH-01.4", - "DCH-02", - "DCH-03", - "IAO-03" + "ISM-2028": [ + "TDA-09.2", + "TDA-09.3" ], - "2302": [ - "CRY-03", - "DCH-07", - "DCH-07.2" + "ISM-2042": [ + "TDA-09.6" ], - "2303": [ - "NET-07" + "ISM-1420": [ + "TDA-10" ], - "2304": [ - "CRY-01", - "IAC-01.2", - "NET-15.1" + "ISM-2038": [ + "TDA-13.1" ], - "2305": [ - "CFG-03.4", - "IAC-06", - "NET-12", - "NET-14", - "NET-14.2", - "NET-14.5" + "ISM-2037": [ + "TDA-13.2" ], - "2306": [ - "CRY-03", - "NET-14.2" + "ISM-0304": [ + "TDA-17" ], - "2307": [ - "NET-14.3" + "ISM-1501": [ + "TDA-17" ], - "2308": [ - "DCH-01", - "DCH-01.2", - "DCH-06" + "ISM-1704": [ + "TDA-17" ], - "2309": [ - "MDM-01", - "MDM-03" + "ISM-1753": [ + "TDA-17" ], - "2310": [ - "AST-02", - "CFG-02", - "CRY-05", - "DCH-10", - "DCH-12" + "ISM-1848": [ + "TDA-17" ], - "2311": [ - "HRS-14", - "HRS-14.1" + "ISM-1981": [ + "TDA-17" ], - "2312": [ - "CFG-02.5", - "PES-11" + "ISM-1982": [ + "TDA-17" ], - "2313": [ - "DCH-09" + "ISM-2059": [ + "TDA-18" ], - "2314": [ - "CPL-01" + "ISM-1422": [ + "TDA-20" ], - "2315": [ - "NET-10", - "NET-10.3", - "NET-20.4" + "ISM-1073": [ + "TPM-01" ], - "2316": [ - "NET-03.4", - "NET-04" + "ISM-1631": [ + "TPM-01.1" ], - "2317": [ - "CRY-01", - "CRY-05", - "END-01" + "ISM-1637": [ + "TPM-01.1" ], - "2318": [ - "CRY-01" + "ISM-1638": [ + "TPM-01.1" ], - "2319": [ - "CRY-09" + "ISM-1736": [ + "TPM-01.1" ], - "2320": [ - "NET-17" + "ISM-1737": [ + "TPM-01.1" ], - "2321": [ - "DCH-15", - "HRS-03", - "SAT-03", - "WEB-14" + "ISM-1786": [ + "TPM-01.1" ], - "2322": [ - "AST-16", - "HRS-05.5", - "MDM-01" + "ISM-1632": [ + "TPM-03", + "TPM-03.1" ], - "2323": [ - "AST-09", - "DCH-09", - "DCH-09.1", - "TPM-05" + "ISM-1568": [ + "TPM-03.1", + "TPM-04.1" ], - "2400": [ - "CFG-02", - "SEA-01" + "ISM-1788": [ + "TPM-03.1" ], - "2401": [ - "CFG-02" + "ISM-1787": [ + "TPM-04.1" ], - "2402": [ - "VPM-01", - "VPM-02", - "VPM-05", - "VPM-06" + "ISM-1882": [ + "TPM-04.1" ], - "2403": [ - "VPM-07" + "ISM-1395": [ + "TPM-05" ], - "2404": [ - "CHG-01" + "ISM-1738": [ + "TPM-05" ], - "2405": [ - "VPM-01", - "VPM-05", - "VPM-05.6", - "VPM-05.7" + "ISM-1576": [ + "TPM-05.1" ], - "2406": [ - "PRI-02", - "SEA-18" + "ISM-1793": [ + "TPM-05.5", + "TPM-08" ], - "2407": [ - "PRI-02", - "SEA-18" + "ISM-1804": [ + "TPM-05.7" ], - "2408": [ - "IAC-24" + "ISM-1794": [ + "TPM-10" ], - "2409": [ - "CFG-03.3" + "ISM-1616": [ + "THR-06" ], - "2410": [ - "AST-01.4" + "ISM-1717": [ + "THR-06" ], - "2411": [ - "END-01", - "END-02", - "END-04", - "IRO-15", - "NET-07", - "NET-08", - "NET-18" + "ISM-1755": [ + "THR-06" ], - "2412": [ - "AST-21" + "ISM-1756": [ + "THR-06" ], - "2413": [ - "END-10" + "ISM-1921": [ + "THR-07" ], - "2414": [ - "NET-09" + "ISM-1143": [ + "VPM-01", + "VPM-05" ], - "2415": [ - "CFG-02.2" + "ISM-1902": [ + "VPM-02" ], - "2416": [ - "SEA-05" + "ISM-1903": [ + "VPM-02" ], - "2417": [ - "NET-14.4" + "ISM-1904": [ + "VPM-02" ], - "2418": [ - "CFG-02", - "CFG-02.1", - "CFG-02.9" + "ISM-1801": [ + "VPM-04" ], - "2419": [ - "IAC-11" + "ISM-1467": [ + "VPM-04.1", + "VPM-05.4" ], - "2420": [ - "IAC-11" + "ISM-1483": [ + "VPM-04.1" ], - "2421": [ - "MON-07.1", - "SEA-20" + "ISM-1690": [ + "VPM-05" ], - "2422": [ - "CHG-04", - "IAC-08", - "PES-02.1" + "ISM-1691": [ + "VPM-05" ], - "2423": [ - "AST-02.9" + "ISM-1692": [ + "VPM-05" ], - "2424": [ - "IAC-15", - "IAC-16", - "IAC-16.1" + "ISM-1693": [ + "VPM-05" ], - "2425": [ - "END-06", - "END-06.1" + "ISM-1694": [ + "VPM-05" ], - "2426": [ - "END-04", - "END-04.1", - "END-04.7" + "ISM-1695": [ + "VPM-05" ], - "2427": [ - "MON-01", - "NET-03" + "ISM-1696": [ + "VPM-05" ], - "2428": [ - "NET-04" + "ISM-1697": [ + "VPM-05" ], - "2430": [ - "CFG-03", - "CFG-03.1" + "ISM-1751": [ + "VPM-05" ], - "2500": [ - "SEA-01.2" + "ISM-1876": [ + "VPM-05" ], - "2501": [ - "BCD-01", - "SEA-01.2" + "ISM-1877": [ + "VPM-05" ], - "2502": [ - "BCD-01" + "ISM-1878": [ + "VPM-05" ], - "2503": [ - "BCD-04" + "ISM-1879": [ + "VPM-05" ], - "2504": [ - "BCD-11", - "BCD-11.1" + "ISM-1901": [ + "VPM-05" ], - "2505": [ - "BCD-11", - "BCD-11.1", - "BCD-11.2", - "BCD-11.5" + "ISM-0298": [ + "VPM-05.1" ], - "2506": [ - "BCD-11.4", - "BCD-11.6", - "DCH-07" + "ISM-0300": [ + "VPM-05.1" ], - "2507": [ - "CFG-03", - "CFG-03.1", - "NET-04.1" + "ISM-1698": [ + "VPM-06" ], - "2508": [ - "NET-06" + "ISM-1699": [ + "VPM-06" ], - "2509": [ - "END-08", - "NET-20.7" + "ISM-1700": [ + "VPM-06" ], - "2510": [ - "MNT-04.2" + "ISM-1701": [ + "VPM-06" ], - "2511": [ - "MNT-02", - "MNT-03" + "ISM-1702": [ + "VPM-06" ], - "2512": [ - "IAC-06", - "MNT-05" + "ISM-1703": [ + "VPM-06" ], - "2513": [ - "MNT-06.1" + "ISM-1752": [ + "VPM-06" ], - "2600": [ - "HRS-03.1", - "SAT-02" + "ISM-1875": [ + "VPM-06" ], - "2601": [ - "RSK-12", - "SAT-03.6" + "ISM-1900": [ + "VPM-06" ], - "2602": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.3", - "SAT-03.6" + "ISM-1808": [ + "VPM-06.1" ], - "2603": [ - "HRS-03.1", - "SAT-02", - "SAT-03.6" + "ISM-1862": [ + "WEB-03" ], - "2604": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "HRS-05.3" + "ISM-0971": [ + "WEB-07" ], - "2605": [ - "SAT-02.1", - "SAT-03.1" + "ISM-1240": [ + "WEB-09" ], - "2700": [ - "HRS-04" + "ISM-1241": [ + "WEB-11" ], - "2701": [ - "HRS-04" + "ISM-1424": [ + "WEB-12" + ] + }, + "apac-aus-cop-sitc-2020": { + "1": [ + "IAC-06", + "IAC-10.1", + "IAC-15" ], - "2702": [ - "HRS-01", - "HRS-01.1", - "IAC-07" + "2": [ + "THR-06", + "THR-06.1" ], - "2703": [ - "HRS-15" + "3": [ + "EMB-07", + "TDA-17", + "VPM-05", + "VPM-05.8" ], - "2704": [ - "PES-07.3", - "PES-08.2", - "PES-09" + "4": [ + "IAC-10.6", + "TDA-02", + "TDA-06", + "TDA-09.6" ], - "3100": [ - "MON-01" + "5": [ + "CPL-01", + "PRI-01.6", + "PRI-01.11", + "PRI-07.1" ], - "3101": [ - "MON-01", + "6": [ + "CFG-02", + "CFG-03", + "IAC-21", + "TDA-06" + ], + "7": [ "MON-01.4", - "MON-01.8", - "MON-17.1", - "HRS-03" + "MON-03", + "CRY-03", + "NET-14.2" ], - "3102": [ - "MON-01", - "MON-01.2", - "MON-01.8", - "MON-17.1", - "HRS-03" + "8": [ + "EMB-05", + "END-06.6" ], - "3103": [ - "MON-08", - "MON-10" + "9": [ + "EMB-08" ], - "3104": [ - "MON-03", - "IRO-08" + "10": [ + "MON-02.1", + "EMB-09" ], - "3105": [ - "IRO-01", - "IRO-02" + "11": [ + "TDA-01.1", + "TDA-04" ], - "3106": [ - "MON-01", - "SAT-03.6" + "12": [ + "TDA-04" ], - "3107": [ - "MON-03.2", - "MON-10" + "13": [ + "EMB-04", + "EMB-06", + "EMB-12", + "EMB-13" + ] + }, + "apac-aus-ps-cps-230-2023": { + "12": [ + "CPL-01" ], - "3108": [ - "MON-06" + "13": [ + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-06" ], - "3109": [ - "MON-17" + "14": [ + "BCD-01" ], - "3110": [ - "THR-03", - "THR-03.1" + "15": [ + "BCD-01", + "BCD-02", + "SEA-02.2", + "TPM-02", + "TPM-03", + "TPM-04.1", + "TPM-05" ], - "3200": [ - "MON-16" + "16": [ + "RSK-01" ], - "3201": [ - "IRO-03" + "17": [ + "GOV-01.1" ], - "3202": [ - "MON-16" + "18": [ + "GOV-01.1" ], - "3203": [ - "MON-16" + "23": [ + "GOV-04" ], - "3204": [ - "AST-02.2" + "24": [ + "GOV-01.1" ], - "4100": [ - "BCD-01" + "25": [ + "PRM-01", + "PRM-02.1", + "PRM-04", + "PRM-05", + "PRM-07", + "SEA-07.1" ], - "4101": [ - "IRO-04" + "26": [ + "RSK-08", + "RSK-10" ], - "4102": [ - "IRO-04" + "27": [ + "RSK-01.1" ], - "4103": [ - "IRO-06" + "28": [ + "CPL-01.4", + "RSK-04" ], - "4104": [ - "IRO-01", - "IRO-02" + "29": [ + "GOV-09" ], - "4105": [ - "IRO-06" + "30": [ + "CPL-03" ], - "4106": [ - "MON-16.3" + "31": [ + "RSK-06", + "RSK-06.4" ], - "4200": [ - "IRO-13" + "32": [ + "BCD-05", + "IRO-13", + "RSK-04.1" ], - "4201": [ - "RSK-04.1", - "RSK-08" + "33": [ + "IRO-10.2" ], - "4202": [ - "BCD-12", - "BCD-12.2" + "35": [ + "BCD-02" ], - "0001": [ - "CPL-01" + "36": [ + "AST-04.1", + "DCH-02" ], - "0002": [ - "CPL-01" - ] - }, - "emea-gbr-def-stan-05-138-l0-2024": { - "2314": [ - "CPL-01" + "37": [ + "AST-04.1" ], - "2500": [ - "SEA-01.2" + "38": [ + "BCD-01.4" ], - "0001": [ - "CPL-01" - ] - }, - "emea-gbr-def-stan-05-138-l1-2024": { - "1100": [ - "GOV-02", - "OPS-01.1" + "40": [ + "BCD-01.7" ], - "1102": [ - "GOV-04", - "HRS-03" + "41": [ + "BCD-01" ], - "1200": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-06" + "42": [ + "IRO-10" ], - "1202": [ - "GOV-01.1", - "RSK-04" + "43": [ + "BCD-04" ], - "1203": [ - "AST-04" + "44": [ + "BCD-04" ], - "1300": [ - "AST-01", - "HRS-01" + "45": [ + "BCD-05", + "BCD-06", + "BCD-06.1" ], - "1400": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-03" + "46": [ + "CPL-02.1" ], - "1401": [ - "TPM-05", - "TPM-05.2" + "47": [ + "GOV-02", + "TPM-01" ], - "1500": [ - "PES-01", - "PES-02", - "PES-03", - "PES-03.3", - "PES-05", - "PES-05.1" + "48": [ + "TPM-01" ], - "1501": [ - "PES-19" + "49": [ + "TPM-01.1", + "TPM-02" ], - "1502": [ - "PES-02.1", - "PES-03.4" + "50": [ + "TPM-02" ], - "1503": [ - "IAC-01.1", - "PES-06.1", - "PES-06.2", - "PES-06.6" + "51": [ + "TPM-01.1", + "TPM-02" ], - "2100": [ - "GOV-02", - "GOV-03", - "OPS-01.1" + "53": [ + "TPM-04.1" ], - "2200": [ - "IAC-01", - "IAC-01.2", - "IAC-08" + "54": [ + "TPM-05" ], - "2204": [ - "CFG-02", - "CFG-03" + "55": [ + "TPM-05" ], - "2205": [ - "IAC-21" + "56": [ + "TPM-05" ], - "2206": [ - "IAC-08", - "IAC-21" + "58": [ + "GOV-01.2", + "CPL-02" ], - "2207": [ - "HRS-11" + "59": [ + "GOV-17" ], - "2210": [ - "IAC-01", - "IAC-01.2" + "12(a)": [ + "GOV-01", + "GOV-02" ], - "2211": [ - "IAC-10.8" + "16(c)": [ + "GOV-01", + "GOV-15" ], - "2213": [ - "IAC-10.4" + "16(a)": [ + "GOV-01.1" ], - "2214": [ - "IAC-22" + "27(a)": [ + "GOV-01.1" ], - "2215": [ - "IAC-02.2" + "59(a)": [ + "GOV-17" ], - "2217": [ - "IAC-01.3" + "59(b)": [ + "GOV-17" ], - "2218": [ - "IAC-02", - "IAC-15.1" + "34(a)": [ + "AST-01.1", + "AST-04", + "BCD-02" ], - "2300": [ - "DCH-01" + "36(a)": [ + "AST-04.1" ], - "2303": [ - "NET-07" + "36(b)": [ + "AST-04.1" ], - "2304": [ - "CRY-01", - "IAC-01.2", - "NET-15.1" + "36(c)": [ + "AST-04.1" ], - "2305": [ - "CFG-03.4", - "IAC-06", - "NET-12", - "NET-14", - "NET-14.2", - "NET-14.5" + "36(d)": [ + "AST-04.1" ], - "2306": [ - "CRY-03", - "NET-14.2" + "34(b)": [ + "BCD-01" ], - "2307": [ - "NET-14.3" + "38(a)": [ + "BCD-01.4" ], - "2310": [ - "AST-02", - "CFG-02", - "CRY-05", - "DCH-10", - "DCH-12" + "38(b)": [ + "BCD-01.4" ], - "2311": [ - "HRS-14", - "HRS-14.1" + "34(d)": [ + "BCD-01.5" ], - "2312": [ - "CFG-02.5", - "PES-11" + "16(e)": [ + "BCD-01.7" ], - "2314": [ - "CPL-01" + "34(c)": [ + "BCD-01.7" ], - "2315": [ - "NET-10", - "NET-10.3", - "NET-20.4" + "40(a)": [ + "BCD-01.7" ], - "2316": [ - "NET-03.4", - "NET-04" + "40(b)": [ + "BCD-01.7" ], - "2317": [ - "CRY-01", - "CRY-05", - "END-01" + "40(c)": [ + "BCD-01.7" ], - "2318": [ - "CRY-01" + "40(d)": [ + "BCD-01.7" ], - "2319": [ - "CRY-09" + "40(e)": [ + "BCD-01.7" ], - "2321": [ - "DCH-15", - "HRS-03", - "SAT-03", - "WEB-14" + "34(e)": [ + "BCD-02.1", + "BCD-02.2", + "BCD-02.3" ], - "2322": [ - "AST-16", - "HRS-05.5", - "MDM-01" + "38(c)": [ + "BCD-02.2", + "BCD-02.3" ], - "2323": [ - "AST-09", - "DCH-09", - "DCH-09.1", - "TPM-05" + "27(c)": [ + "BCD-04", + "IRO-06", + "TDA-06.2" ], - "2400": [ - "CFG-02", - "SEA-01" + "58(a)": [ + "CPL-02" ], - "2401": [ - "CFG-02" + "58(b)": [ + "CPL-02" ], - "2402": [ - "VPM-01", - "VPM-02", - "VPM-05", - "VPM-06" + "58(c)": [ + "CPL-02" ], - "2403": [ - "VPM-07" + "16(d)": [ + "MON-01", + "IRO-01", + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-06.1", + "THR-03", + "THR-10" ], - "2404": [ - "CHG-01" + "27(b)": [ + "PRM-01", + "PRM-01.1", + "PRM-01.2", + "PRM-02", + "PRM-02.1", + "PRM-03", + "PRM-04" ], - "2405": [ - "VPM-01", - "VPM-05", - "VPM-05.6", - "VPM-05.7" + "16(b)": [ + "RSK-01.1", + "RSK-01.3", + "RSK-01.5" ], - "2407": [ - "PRI-02", - "SEA-18" + "12(b)": [ + "OPS-03" ], - "2408": [ - "IAC-24" + "12(c)": [ + "TPM-01" ], - "2409": [ - "CFG-03.3" + "16(f)": [ + "TPM-01", + "TPM-05" ], - "2410": [ - "AST-01.4" + "48(a)": [ + "TPM-01" ], - "2411": [ - "END-01", - "END-02", - "END-04", - "IRO-15", - "NET-07", - "NET-08", - "NET-18" + "48(b)": [ + "TPM-01" ], - "2412": [ - "AST-21" + "48(c)": [ + "TPM-01" ], - "2413": [ - "END-10" + "50(a)": [ + "TPM-02" ], - "2414": [ - "NET-09" + "50(b)": [ + "TPM-02" ], - "2417": [ - "NET-14.4" + "50(c)": [ + "TPM-02" ], - "2418": [ - "CFG-02", - "CFG-02.1", - "CFG-02.9" + "50(d)": [ + "TPM-02" ], - "2419": [ - "IAC-11" + "53(a)": [ + "TPM-04.1" ], - "2420": [ - "IAC-11" + "53(b)": [ + "TPM-04.1" ], - "2421": [ - "MON-07.1", - "SEA-20" + "54(a)": [ + "TPM-05" ], - "2422": [ - "CHG-04", - "IAC-08", - "PES-02.1" + "54(b)": [ + "TPM-05" ], - "2423": [ - "AST-02.9" + "54(c)": [ + "TPM-05" ], - "2426": [ - "END-04", - "END-04.1", - "END-04.7" + "54(d)": [ + "TPM-05" ], - "2427": [ - "MON-01", - "NET-03" + "54(e)": [ + "TPM-05" ], - "2428": [ - "NET-04" + "54(f)": [ + "TPM-05" ], - "2500": [ - "SEA-01.2" + "55(a)": [ + "TPM-05" ], - "2501": [ - "BCD-01", - "SEA-01.2" + "55(b)": [ + "TPM-05" ], - "2502": [ - "BCD-01" + "55(c)": [ + "TPM-05" ], - "2504": [ - "BCD-11", - "BCD-11.1" + "56(a)": [ + "TPM-05" ], - "2507": [ - "CFG-03", - "CFG-03.1", - "NET-04.1" + "56(b)": [ + "TPM-05" ], - "2508": [ - "NET-06" + "56(c)": [ + "TPM-05" ], - "2509": [ - "END-08", - "NET-20.7" + "56(d)": [ + "TPM-05" ], - "2510": [ - "MNT-04.2" + "54(g)": [ + "TPM-05.7" + ] + }, + "apac-aus-ps-cps-234-2019": { + "13": [ + "GOV-01.1" ], - "2511": [ - "MNT-02", - "MNT-03" + "14": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "2512": [ - "IAC-06", - "MNT-05" + "15": [ + "GOV-01" ], - "2513": [ - "MNT-06.1" + "16": [ + "TPM-04.1" ], - "2600": [ - "HRS-03.1", - "SAT-02" + "17": [ + "GOV-01", + "THR-01", + "VPM-01" ], - "2603": [ - "HRS-03.1", - "SAT-02", - "SAT-03.6" + "18": [ + "GOV-02" ], - "2604": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "HRS-05.3" + "19": [ + "HRS-03" ], - "2700": [ - "HRS-04" + "20": [ + "DCH-02" ], - "2701": [ - "HRS-04" + "21": [ + "GOV-15", + "GOV-15.1" ], - "2702": [ - "HRS-01", - "HRS-01.1", - "IAC-07" + "22": [ + "IAO-02" ], - "2703": [ - "HRS-15" + "23": [ + "IRO-01", + "IRO-02" ], - "2704": [ - "PES-07.3", - "PES-08.2", - "PES-09" + "24": [ + "IRO-04" ], - "3100": [ - "MON-01" + "25": [ + "IRO-04" ], - "3101": [ - "MON-01", - "MON-01.4", - "MON-01.8", - "MON-17.1", - "HRS-03" + "26": [ + "IRO-06" ], - "3107": [ - "MON-03.2", - "MON-10" + "27": [ + "IRO-06" ], - "3108": [ - "MON-06" + "28": [ + "IAO-02" ], - "3109": [ - "MON-17" + "29": [ + "CPL-02" ], - "3200": [ - "MON-16" + "30": [ + "CPL-03.1" ], - "3201": [ - "IRO-03" + "31": [ + "CPL-02" ], - "3203": [ - "MON-16" + "32": [ + "CPL-02.1" ], - "3204": [ - "AST-02.2" + "33": [ + "CPL-03.2" ], - "4100": [ - "BCD-01" + "34": [ + "CPL-02.1" ], - "4104": [ - "IRO-01", - "IRO-02" + "35": [ + "IRO-10" ], - "4106": [ - "MON-16.3" + "36": [ + "IRO-10" ], - "4200": [ - "IRO-13" + "21(a)": [ + "GOV-15.1" ], - "0001": [ - "CPL-01" - ] - }, - "emea-gbr-def-stan-05-138-l2-2024": { - "1100": [ - "GOV-02", - "OPS-01.1" + "21(b)": [ + "GOV-15.1" ], - "1101": [ - "GOV-01.1", - "GOV-02", - "GOV-04.1" + "21(c)": [ + "GOV-15.1" ], - "1102": [ - "GOV-04", - "HRS-03" + "21(d)": [ + "GOV-15.1" ], - "1103": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "34(a)": [ + "CPL-02.1" ], - "1200": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-06" + "34(b)": [ + "CPL-02.1" ], - "1201": [ - "RSK-01" + "25(a)": [ + "IRO-04" ], - "1202": [ - "GOV-01.1", - "RSK-04" + "25(b)": [ + "IRO-04" ], - "1203": [ - "AST-04" + "27(a)": [ + "IRO-06" ], - "1205": [ - "IAO-01", - "IAO-02", - "IAO-06" + "27(b)": [ + "IRO-06" ], - "1206": [ - "CPL-02", - "CPL-02.2", - "CPL-03.2" + "27(c)": [ + "IRO-06" ], - "1300": [ - "AST-01", - "HRS-01" + "27(d)": [ + "IRO-06" ], - "1301": [ - "AST-01", - "AST-02", - "AST-02.9" + "27(e)": [ + "IRO-06" + ] + }, + "apac-chn-cybersecurity-law-2017": { + "Article 28": [ + "GOV-12", + "GOV-13", + "CPL-05.2", + "CPL-06" ], - "1400": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-03" + "Article 38": [ + "GOV-17", + "CPL-03.1" ], - "1401": [ - "TPM-05", - "TPM-05.2" + "Article 54(1)": [ + "GOV-17" ], - "1500": [ - "PES-01", - "PES-02", - "PES-03", - "PES-03.3", - "PES-05", - "PES-05.1" + "Article 33": [ + "BCD-01" ], - "1501": [ - "PES-19" + "Article 34(4)": [ + "BCD-01", + "BCD-04" ], - "1502": [ - "PES-02.1", - "PES-03.4" + "Article 34(3)": [ + "BCD-11" ], - "1503": [ - "IAC-01.1", - "PES-06.1", - "PES-06.2", - "PES-06.6" + "Article 9": [ + "CPL-01" ], - "2100": [ - "GOV-02", - "GOV-03", - "OPS-01.1" + "Article 10": [ + "CPL-01" ], - "2101": [ - "GOV-02", - "GOV-03", - "OPS-01.1" + "Article 21": [ + "CPL-01" ], - "2200": [ - "IAC-01", - "IAC-01.2", - "IAC-08" + "Article 23": [ + "CPL-01" ], - "2201": [ - "IAC-06" + "Article 26": [ + "CPL-01" ], - "2202": [ - "AST-01", - "AST-02", - "AST-02.4" + "Article 27": [ + "CPL-01" ], - "2203": [ - "MON-01", - "MON-01.15" + "Article 34": [ + "CPL-01" ], - "2204": [ - "CFG-02", - "CFG-03" + "Article 34(5)": [ + "CPL-01" ], - "2205": [ - "IAC-21" + "Article 41": [ + "CPL-01", + "PRI-05.4" ], - "2206": [ - "IAC-08", - "IAC-21" + "Article 47": [ + "CPL-01" ], - "2207": [ - "HRS-11" + "Article 72": [ + "CPL-05" ], - "2208": [ - "IAC-01" + "Article 55": [ + "CPL-05.2" ], - "2210": [ - "IAC-01", - "IAC-01.2" + "Article 56": [ + "CPL-05.2" ], - "2211": [ - "IAC-10.8" + "Article 29": [ + "CPL-06" ], - "2212": [ - "IAC-10.11" + "Article 40": [ + "DCH-01", + "IAC-01" ], - "2213": [ - "IAC-10.4" + "Article 37": [ + "DCH-26" ], - "2214": [ - "IAC-22" + "Article 34(1)": [ + "HRS-01" ], - "2215": [ - "IAC-02.2" + "Article 25": [ + "IRO-04" ], - "2216": [ - "MON-03.3", - "IAC-21.5" + "Article 35": [ + "IAO-02" ], - "2217": [ - "IAC-01.3" + "Article 42": [ + "PRI-01.6" ], - "2218": [ - "IAC-02", - "IAC-15.1" + "Article 22": [ + "PRI-03", + "TDA-01.1" ], - "2301": [ - "AST-04", - "DCH-01.4", - "DCH-02", - "DCH-03", - "IAO-03" + "Article 44": [ + "PRI-05.4" ], - "2302": [ - "CRY-03", - "DCH-07", - "DCH-07.2" + "Article 43": [ + "PRI-06.1", + "PRI-06.4", + "PRI-06.5" ], - "2303": [ - "NET-07" + "Article 24": [ + "PRI-16" ], - "2304": [ - "CRY-01", - "IAC-01.2", - "NET-15.1" + "Article 34(2)": [ + "SAT-01" ], - "2305": [ - "CFG-03.4", - "IAC-06", - "NET-12", - "NET-14", - "NET-14.2", - "NET-14.5" + "Article 46": [ + "TDA-01.1" ], - "2306": [ - "CRY-03", - "NET-14.2" + "Article 48": [ + "TDA-01.1" ], - "2307": [ - "NET-14.3" + "Article 36": [ + "TPM-05" + ] + }, + "apac-chn-data-security-law-2021": { + "Article 27": [ + "GOV-04", + "GOV-13", + "CPL-01", + "CPL-06", + "PRI-16" ], - "2308": [ - "DCH-01", - "DCH-01.2", - "DCH-06" + "Article 28": [ + "GOV-12" ], - "2309": [ - "MDM-01", - "MDM-03" + "Article 32": [ + "CPL-01" ], - "2310": [ - "AST-02", - "CFG-02", - "CRY-05", - "DCH-10", - "DCH-12" + "Article 31": [ + "CPL-06" ], - "2311": [ - "HRS-14", - "HRS-14.1" + "Article 29": [ + "MON-01", + "IRO-02" ], - "2312": [ - "CFG-02.5", - "PES-11" + "Article 33": [ + "PRI-01.11", + "PRI-16" ], - "2313": [ - "DCH-09" + "Article 30": [ + "RSK-04" + ] + }, + "apac-chn-csnip-2012": { + "III": [ + "HRS-06.1" ], - "2314": [ - "CPL-01" + "IV": [ + "PRI-01.6" ], - "2315": [ - "NET-10", - "NET-10.3", - "NET-20.4" + "I": [ + "PRI-01.11" ], - "2316": [ - "NET-03.4", - "NET-04" + "II": [ + "PRI-01.11" ], - "2317": [ - "CRY-01", - "CRY-05", - "END-01" + "VI": [ + "PRI-01.11", + "PRI-16" ], - "2318": [ - "CRY-01" + "V": [ + "PRI-05.4" ], - "2319": [ - "CRY-09" + "VIII": [ + "PRI-06", + "PRI-06.5" + ] + }, + "apac-chn-pipl-2021": { + "Article 38": [ + "GOV-13", + "CPL-06", + "PRI-01.5", + "PRI-16" ], - "2320": [ - "NET-17" + "Article 53": [ + "CPL-08" ], - "2321": [ - "DCH-15", - "HRS-03", - "SAT-03", - "WEB-14" + "Article 25": [ + "DCH-03.1" ], - "2322": [ - "AST-16", - "HRS-05.5", - "MDM-01" + "Article 40": [ + "DCH-26" ], - "2323": [ - "AST-09", - "DCH-09", - "DCH-09.1", - "TPM-05" + "Article 59": [ + "HRS-06.1" ], - "2400": [ - "CFG-02", - "SEA-01" + "Article 57": [ + "IRO-02", + "IRO-10" ], - "2401": [ - "CFG-02" + "Article 51": [ + "PRI-01" ], - "2402": [ - "VPM-01", - "VPM-02", - "VPM-05", - "VPM-06" + "Article 52": [ + "PRI-01.4" ], - "2403": [ - "VPM-07" + "Article 54": [ + "PRI-01.4" ], - "2404": [ - "CHG-01" + "Article 9": [ + "PRI-01.6" ], - "2405": [ - "VPM-01", - "VPM-05", - "VPM-05.6", - "VPM-05.7" + "Article 5": [ + "PRI-01.11" ], - "2406": [ - "PRI-02", - "SEA-18" + "Article 7": [ + "PRI-01.11" ], - "2407": [ - "PRI-02", - "SEA-18" + "Article 10": [ + "PRI-01.11" ], - "2408": [ - "IAC-24" + "Article 26": [ + "PRI-01.11" ], - "2409": [ - "CFG-03.3" + "Article 27": [ + "PRI-01.11" ], - "2410": [ - "AST-01.4" + "Article 17": [ + "PRI-02" ], - "2411": [ - "END-01", - "END-02", - "END-04", - "IRO-15", - "NET-07", - "NET-08", - "NET-18" + "Article 18": [ + "PRI-02" ], - "2412": [ - "AST-21" + "Article 30": [ + "PRI-02" ], - "2413": [ - "END-10" + "Article 39": [ + "PRI-02" ], - "2414": [ - "NET-09" + "Article 6": [ + "PRI-02.1" ], - "2416": [ - "SEA-05" + "Article 14": [ + "PRI-03" ], - "2417": [ - "NET-14.4" + "Article 29": [ + "PRI-03.1" ], - "2418": [ - "CFG-02", - "CFG-02.1", - "CFG-02.9" + "Article 15": [ + "PRI-03.4" ], - "2419": [ - "IAC-11" + "Article 16": [ + "PRI-03.5" ], - "2420": [ - "IAC-11" + "Article 49": [ + "PRI-03.6" ], - "2421": [ - "MON-07.1", - "SEA-20" + "Article 31": [ + "PRI-03.13" ], - "2422": [ - "CHG-04", - "IAC-08", - "PES-02.1" + "Article 19": [ + "PRI-05" ], - "2423": [ - "AST-02.9" + "Article 47": [ + "PRI-05" ], - "2424": [ - "IAC-15", - "IAC-16", - "IAC-16.1" + "Article 8": [ + "PRI-05.2" ], - "2426": [ - "END-04", - "END-04.1", - "END-04.7" + "Article 13": [ + "PRI-05.4" ], - "2427": [ - "MON-01", - "NET-03" + "Article 28": [ + "PRI-05.4" ], - "2428": [ - "NET-04" + "Article 44": [ + "PRI-06" ], - "2430": [ - "CFG-03", - "CFG-03.1" + "Article 48": [ + "PRI-06" ], - "2500": [ - "SEA-01.2" + "Article 46": [ + "PRI-06.1" ], - "2501": [ - "BCD-01", - "SEA-01.2" + "Article 50": [ + "PRI-06.4", + "PRI-07.4", + "PRI-07.5" ], - "2503": [ - "BCD-04" + "Article 45": [ + "PRI-06.6" ], - "2505": [ - "BCD-11", - "BCD-11.1", - "BCD-11.2", - "BCD-11.5" + "Article 21": [ + "PRI-07.1" ], - "2506": [ - "BCD-11.4", - "BCD-11.6", - "DCH-07" + "Article 20": [ + "PRI-07.2" ], - "2507": [ - "CFG-03", - "CFG-03.1", - "NET-04.1" + "Article 22": [ + "PRI-14.1" ], - "2508": [ - "NET-06" + "Article 23": [ + "PRI-14.1" ], - "2509": [ - "END-08", - "NET-20.7" + "Article 24": [ + "PRI-19", + "PRI-19.3" ], - "2510": [ - "MNT-04.2" + "Article 55": [ + "RSK-10" ], - "2511": [ - "MNT-02", - "MNT-03" + "Article 56": [ + "RSK-10" + ] + }, + "apac-hkg-pdo-2022": { + "4": [ + "CPL-01" ], - "2512": [ - "IAC-06", - "MNT-05" + "29": [ + "PRI-01.11" ], - "2513": [ - "MNT-06.1" + "Schedule 1 - 4(1)": [ + "PRI-01.6" ], - "2600": [ - "HRS-03.1", - "SAT-02" + "Schedule 1 - 4(1)(a)": [ + "PRI-01.6" ], - "2601": [ - "RSK-12", - "SAT-03.6" + "Schedule 1 - 4(1)(b)": [ + "PRI-01.6" ], - "2602": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.3", - "SAT-03.6" + "Schedule 1 - 4(1)(c)": [ + "PRI-01.6" ], - "2603": [ - "HRS-03.1", - "SAT-02", - "SAT-03.6" + "Schedule 1 - 4(1)(d)": [ + "PRI-01.6" ], - "2604": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "HRS-05.3" + "Schedule 1 - 4(1)(e)": [ + "PRI-01.6" ], - "2605": [ - "SAT-02.1", - "SAT-03.1" + "28(1)": [ + "PRI-01.11" ], - "2700": [ - "HRS-04" + "28(2)": [ + "PRI-01.11" ], - "2701": [ - "HRS-04" + "28(3)": [ + "PRI-01.11" ], - "2702": [ - "HRS-01", - "HRS-01.1", - "IAC-07" + "28(4)": [ + "PRI-01.11" ], - "2703": [ - "HRS-15" + "28(4)(II)": [ + "PRI-01.11" ], - "2704": [ - "PES-07.3", - "PES-08.2", - "PES-09" + "28(5)": [ + "PRI-01.11" ], - "3100": [ - "MON-01" + "28(6)": [ + "PRI-01.11" ], - "3101": [ - "MON-01", - "MON-01.4", - "MON-01.8", - "MON-17.1", - "HRS-03" + "28(6)(a)": [ + "PRI-01.11" ], - "3103": [ - "MON-08", - "MON-10" + "28(6)(b)": [ + "PRI-01.11" ], - "3104": [ - "MON-03", - "IRO-08" + "29(a)": [ + "PRI-01.11" ], - "3105": [ - "IRO-01", - "IRO-02" + "29(b)": [ + "PRI-01.11" ], - "3106": [ - "MON-01", - "SAT-03.6" + "Schedule 1 - 1(1)(a)": [ + "PRI-01.11" ], - "3107": [ - "MON-03.2", - "MON-10" + "Schedule 1 - 1(1)(b)": [ + "PRI-01.11" ], - "3108": [ - "MON-06" + "Schedule 1 - 1(1)(c)": [ + "PRI-01.11" ], - "3109": [ - "MON-17" + "Schedule 1 - 1(2)(a)": [ + "PRI-01.11" ], - "3110": [ - "THR-03", - "THR-03.1" + "Schedule 1 - 1(2)(b)": [ + "PRI-01.11" ], - "3200": [ - "MON-16" + "35C(2)": [ + "PRI-02" ], - "3201": [ - "IRO-03" + "35C(2)(a)": [ + "PRI-02" ], - "3202": [ - "MON-16" + "35C(2)(a)(i)": [ + "PRI-02" ], - "3203": [ - "MON-16" + "35C(2)(a)(ii)": [ + "PRI-02" ], - "3204": [ - "AST-02.2" + "35C(2)(b)": [ + "PRI-02" ], - "4100": [ - "BCD-01" + "35C(2)(b)(i)": [ + "PRI-02" ], - "4101": [ - "IRO-04" + "35C(2)(b)(ii)": [ + "PRI-02" ], - "4102": [ - "IRO-04" + "35C(2)(c)": [ + "PRI-02" ], - "4103": [ - "IRO-06" + "35C(3)": [ + "PRI-02" ], - "4104": [ - "IRO-01", - "IRO-02" + "35C(4)": [ + "PRI-02" ], - "4105": [ - "IRO-06" + "35C(5)": [ + "PRI-02" ], - "4106": [ - "MON-16.3" + "35J(2)": [ + "PRI-02" ], - "4200": [ - "IRO-13" + "35J(2)(a)": [ + "PRI-02" ], - "4201": [ - "RSK-04.1", - "RSK-08" + "35J(2)(a)(i)": [ + "PRI-02" ], - "0001": [ - "CPL-01" + "35J(2)(a)(ii)": [ + "PRI-02" ], - "0002": [ - "CPL-01" - ] - }, - "emea-gbr-def-stan-05-138-l3-2024": { - "1100": [ - "GOV-02", - "OPS-01.1" + "35J(2)(b)": [ + "PRI-02" ], - "1101": [ - "GOV-01.1", - "GOV-02", - "GOV-04.1" + "35J(2)(b)(i)": [ + "PRI-02" ], - "1102": [ - "GOV-04", - "HRS-03" + "35J(2)(b)(ii)": [ + "PRI-02" ], - "1103": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "35J(2)(b)(iii)": [ + "PRI-02" ], - "1200": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-06" + "35J(2)(b)(iv)": [ + "PRI-02" ], - "1201": [ - "RSK-01" + "35J(2)(c)": [ + "PRI-02" ], - "1202": [ - "GOV-01.1", - "RSK-04" + "35J(3)": [ + "PRI-02" ], - "1203": [ - "AST-04" + "35J(4)": [ + "PRI-02" ], - "1204": [ - "RSK-01", - "RSK-04", - "THR-01", - "THR-03", - "THR-03.1" + "35J(5)": [ + "PRI-02" ], - "1205": [ - "IAO-01", - "IAO-02", - "IAO-06" + "35J(5)(a)": [ + "PRI-02" ], - "1206": [ - "CPL-02", - "CPL-02.2", - "CPL-03.2" + "35J(5)(b)": [ + "PRI-02" ], - "1300": [ - "AST-01", - "HRS-01" + "Schedule 1 - 1(3)(a)": [ + "PRI-02" ], - "1301": [ - "AST-01", - "AST-02", - "AST-02.9" + "Schedule 1 - 1(3)(b)(ii)(B)": [ + "PRI-02" ], - "1400": [ - "RSK-09", - "RSK-09.1", - "TPM-01", - "TPM-03" + "Schedule 1 - 5": [ + "PRI-02" ], - "1401": [ - "TPM-05", - "TPM-05.2" + "Schedule 1 - 5(a)": [ + "PRI-02" ], - "1500": [ - "PES-01", - "PES-02", - "PES-03", - "PES-03.3", - "PES-05", - "PES-05.1" + "Schedule 1 - 5(b)": [ + "PRI-02" ], - "1501": [ - "PES-19" + "Schedule 1 - 5(c)": [ + "PRI-02" ], - "1502": [ - "PES-02.1", - "PES-03.4" + "35E(1)": [ + "PRI-03" ], - "1503": [ - "IAC-01.1", - "PES-06.1", - "PES-06.2", - "PES-06.6" + "35E(1)(a)": [ + "PRI-03" ], - "2100": [ - "GOV-02", - "GOV-03", - "OPS-01.1" + "35E(1)(b)": [ + "PRI-03" ], - "2101": [ - "GOV-02", - "GOV-03", - "OPS-01.1" + "35E(1)(b)(i)": [ + "PRI-03" ], - "2200": [ - "IAC-01", - "IAC-01.2", - "IAC-08" + "35E(1)(b)(ii)": [ + "PRI-03" ], - "2201": [ - "IAC-06" + "35E(1)(b)(iii)": [ + "PRI-03" ], - "2202": [ - "AST-01", - "AST-02", - "AST-02.4" + "35E(1)(c)": [ + "PRI-03" ], - "2203": [ - "MON-01", - "MON-01.15" + "35E(2)": [ + "PRI-03" ], - "2204": [ - "CFG-02", - "CFG-03" + "35E(2)(a)": [ + "PRI-03" ], - "2205": [ - "IAC-21" + "35E(2)(b)": [ + "PRI-03" ], - "2206": [ - "IAC-08", - "IAC-21" + "35E(3)": [ + "PRI-03" ], - "2207": [ - "HRS-11" + "35E(4)": [ + "PRI-03" ], - "2208": [ - "IAC-01" + "Schedule 1 - 1(3)(a)(i)": [ + "PRI-03" ], - "2209": [ - "IAC-01.2", - "IAC-15.1" + "Schedule 1 - 1(3)(a)(ii)": [ + "PRI-03" ], - "2210": [ - "IAC-01", - "IAC-01.2" + "Schedule 1 - 1(3)(b)": [ + "PRI-03" ], - "2211": [ - "IAC-10.8" + "Schedule 1 - 1(3)(b)(i)": [ + "PRI-03" ], - "2212": [ - "IAC-10.11" + "Schedule 1 - 1(3)(b)(i)(A)": [ + "PRI-03" ], - "2213": [ - "IAC-10.4" + "Schedule 1 - 1(3)(b)(i)(B)": [ + "PRI-03" ], - "2214": [ - "IAC-22" + "Schedule 1 - 1(3)(b)(ii)": [ + "PRI-03" ], - "2215": [ - "IAC-02.2" + "Schedule 1 - 1(3)(b)(ii)(A)": [ + "PRI-03" ], - "2216": [ - "MON-03.3", - "IAC-21.5" + "35G(1)": [ + "PRI-03.4" ], - "2217": [ - "IAC-01.3" + "35L(1)": [ + "PRI-03.4" ], - "2218": [ - "IAC-02", - "IAC-15.1" + "35L(1)(a)": [ + "PRI-03.4" ], - "2301": [ - "AST-04", - "DCH-01.4", - "DCH-02", - "DCH-03", - "IAO-03" + "35L(1)(b)": [ + "PRI-03.4" ], - "2302": [ - "CRY-03", - "DCH-07", - "DCH-07.2" + "35L(2)": [ + "PRI-03.4" ], - "2303": [ - "NET-07" + "35L(3)": [ + "PRI-03.4" ], - "2304": [ - "CRY-01", - "IAC-01.2", - "NET-15.1" + "35L(4)": [ + "PRI-03.4" ], - "2305": [ - "CFG-03.4", - "IAC-06", - "NET-12", - "NET-14", - "NET-14.2", - "NET-14.5" + "Schedule 1 - 2(1)(b)(i)": [ + "PRI-03.9" ], - "2306": [ - "CRY-03", - "NET-14.2" + "Schedule 1 - 2(1)(b)(ii)": [ + "PRI-03.9" ], - "2307": [ - "NET-14.3" + "26(1)": [ + "PRI-05" ], - "2308": [ - "DCH-01", - "DCH-01.2", - "DCH-06" + "26(1)(a)": [ + "PRI-05" ], - "2309": [ - "MDM-01", - "MDM-03" + "26(1)(b)": [ + "PRI-05" ], - "2310": [ - "AST-02", - "CFG-02", - "CRY-05", - "DCH-10", - "DCH-12" + "26(2)": [ + "PRI-05" ], - "2311": [ - "HRS-14", - "HRS-14.1" + "26(2)(a)": [ + "PRI-05" ], - "2312": [ - "CFG-02.5", - "PES-11" + "26(2)(b)": [ + "PRI-05" ], - "2313": [ - "DCH-09" + "Schedule 1 - 2(2)": [ + "PRI-05" ], - "2314": [ - "CPL-01" + "Schedule 1 - 2(3)": [ + "PRI-05" ], - "2315": [ - "NET-10", - "NET-10.3", - "NET-20.4" + "Schedule 1 - 2(1)(a)": [ + "PRI-05.2" ], - "2316": [ - "NET-03.4", - "NET-04" + "Schedule 1 - 2(1)(b)": [ + "PRI-05.2" ], - "2317": [ - "CRY-01", - "CRY-05", - "END-01" + "Schedule 1 - 2(1)(c)(i)": [ + "PRI-05.2" ], - "2318": [ - "CRY-01" + "Schedule 1 - 2(1)(c)(ii)": [ + "PRI-05.2" ], - "2319": [ - "CRY-09" + "Schedule 1 - 2(1)(c)(ii)(A)": [ + "PRI-05.2" ], - "2320": [ - "NET-17" + "Schedule 1 - 2(1)(c)(ii)(B)": [ + "PRI-05.2" ], - "2321": [ - "DCH-15", - "HRS-03", - "SAT-03", - "WEB-14" + "35K(1)": [ + "PRI-05.4" ], - "2322": [ - "AST-16", - "HRS-05.5", - "MDM-01" + "35K(1)(a)": [ + "PRI-05.4" ], - "2323": [ - "AST-09", - "DCH-09", - "DCH-09.1", - "TPM-05" + "35K(1)(b)": [ + "PRI-05.4" ], - "2400": [ - "CFG-02", - "SEA-01" + "35K(1)(c)": [ + "PRI-05.4" ], - "2401": [ - "CFG-02" + "35K(2)": [ + "PRI-05.4" ], - "2402": [ - "VPM-01", - "VPM-02", - "VPM-05", - "VPM-06" + "35K(2)(a)": [ + "PRI-05.4" ], - "2403": [ - "VPM-07" + "35K(2)(b)": [ + "PRI-05.4" ], - "2404": [ - "CHG-01" + "35K(2)(c)": [ + "PRI-05.4" ], - "2405": [ - "VPM-01", - "VPM-05", - "VPM-05.6", - "VPM-05.7" + "35K(3)": [ + "PRI-05.4" ], - "2406": [ - "PRI-02", - "SEA-18" + "Schedule 1 - 3(1)": [ + "PRI-05.4" ], - "2407": [ - "PRI-02", - "SEA-18" + "Schedule 1 - 3(2)": [ + "PRI-05.4" ], - "2408": [ - "IAC-24" + "Schedule 1 - 3(2)(a)": [ + "PRI-05.4" ], - "2409": [ - "CFG-03.3" + "Schedule 1 - 3(2)(a)(i)": [ + "PRI-05.4" ], - "2410": [ - "AST-01.4" + "Schedule 1 - 3(2)(a)(ii)": [ + "PRI-05.4" ], - "2411": [ - "END-01", - "END-02", - "END-04", - "IRO-15", - "NET-07", - "NET-08", - "NET-18" + "Schedule 1 - 3(2)(a)(iii)": [ + "PRI-05.4" ], - "2412": [ - "AST-21" + "Schedule 1 - 3(2)(b)": [ + "PRI-05.4" ], - "2413": [ - "END-10" + "Schedule 1 - 3(2)(c)": [ + "PRI-05.4" ], - "2414": [ - "NET-09" + "Schedule 1 - 3(3)": [ + "PRI-05.4" ], - "2415": [ - "CFG-02.2" + "18(1)": [ + "PRI-06" ], - "2416": [ - "SEA-05" + "18(1)(a)": [ + "PRI-06" ], - "2417": [ - "NET-14.4" + "18(1)(b)": [ + "PRI-06" ], - "2418": [ - "CFG-02", - "CFG-02.1", - "CFG-02.9" + "18(2)": [ + "PRI-06" ], - "2419": [ - "IAC-11" + "18(3)": [ + "PRI-06" ], - "2420": [ - "IAC-11" + "18(4)": [ + "PRI-06" ], - "2421": [ - "MON-07.1", - "SEA-20" + "18(4)(a)": [ + "PRI-06" ], - "2422": [ - "CHG-04", - "IAC-08", - "PES-02.1" + "18(4)(b)": [ + "PRI-06" ], - "2423": [ - "AST-02.9" + "35G(3)": [ + "PRI-06" ], - "2424": [ - "IAC-15", - "IAC-16", - "IAC-16.1" + "Schedule 1 - 6": [ + "PRI-06" ], - "2425": [ - "END-06", - "END-06.1" + "Schedule 1 - 6(a)": [ + "PRI-06" ], - "2426": [ - "END-04", - "END-04.1", - "END-04.7" + "Schedule 1 - 6(b)": [ + "PRI-06" ], - "2427": [ - "MON-01", - "NET-03" + "Schedule 1 - 6(b)(i)": [ + "PRI-06" ], - "2428": [ - "NET-04" + "Schedule 1 - 6(b)(ii)": [ + "PRI-06" ], - "2430": [ - "CFG-03", - "CFG-03.1" + "Schedule 1 - 6(b)(iii)": [ + "PRI-06" ], - "2500": [ - "SEA-01.2" + "Schedule 1 - 6(b)(iv)": [ + "PRI-06" ], - "2501": [ - "BCD-01", - "SEA-01.2" + "Schedule 1 - 6(c)": [ + "PRI-06" ], - "2503": [ - "BCD-04" + "Schedule 1 - 6(d)": [ + "PRI-06" ], - "2505": [ - "BCD-11", - "BCD-11.1", - "BCD-11.2", - "BCD-11.5" + "Schedule 1 - 6(e)": [ + "PRI-06" ], - "2506": [ - "BCD-11.4", - "BCD-11.6", - "DCH-07" + "Schedule 1 - 6(f)": [ + "PRI-06" ], - "2507": [ - "CFG-03", - "CFG-03.1", - "NET-04.1" + "Schedule 1 - 6(g)": [ + "PRI-06" ], - "2508": [ - "NET-06" + "22(1)(a)": [ + "PRI-06.1" ], - "2509": [ - "END-08", - "NET-20.7" + "22(1)(b)": [ + "PRI-06.1" ], - "2510": [ - "MNT-04.2" + "22(1A)": [ + "PRI-06.1" ], - "2511": [ - "MNT-02", - "MNT-03" + "22(2)": [ + "PRI-06.1" ], - "2512": [ - "IAC-06", - "MNT-05" + "22(2)(a)": [ + "PRI-06.1" ], - "2513": [ - "MNT-06.1" + "22(2)(b)": [ + "PRI-06.1" ], - "2600": [ - "HRS-03.1", - "SAT-02" + "22(3)": [ + "PRI-06.1" ], - "2601": [ - "RSK-12", - "SAT-03.6" + "22(4)": [ + "PRI-06.1" ], - "2602": [ - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.3", - "SAT-03.6" + "23(1)": [ + "PRI-06.1" ], - "2603": [ - "HRS-03.1", - "SAT-02", - "SAT-03.6" + "23(1)(a)": [ + "PRI-06.1" ], - "2604": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2", - "HRS-05.3" + "23(1)(c)(i)": [ + "PRI-06.1" ], - "2605": [ - "SAT-02.1", - "SAT-03.1" + "23(1)(c)(ii)": [ + "PRI-06.1" ], - "2700": [ - "HRS-04" + "23(2)": [ + "PRI-06.1" ], - "2701": [ - "HRS-04" + "23(2)(a)": [ + "PRI-06.1" ], - "2702": [ - "HRS-01", - "HRS-01.1", - "IAC-07" + "23(2)(a)(i)": [ + "PRI-06.1" ], - "2703": [ - "HRS-15" + "23(2)(a)(ii)": [ + "PRI-06.1" ], - "2704": [ - "PES-07.3", - "PES-08.2", - "PES-09" + "23(2)(b)": [ + "PRI-06.1" ], - "3100": [ - "MON-01" + "23(3)": [ + "PRI-06.1" ], - "3102": [ - "MON-01", - "MON-01.2", - "MON-01.8", - "MON-17.1", - "HRS-03" + "23(3)(a)": [ + "PRI-06.1" ], - "3103": [ - "MON-08", - "MON-10" + "23(3)(b)": [ + "PRI-06.1" ], - "3104": [ - "MON-03", - "IRO-08" + "19(3)(b)": [ + "PRI-06.2" ], - "3105": [ - "IRO-01", - "IRO-02" + "19(3)(c)": [ + "PRI-06.2" ], - "3106": [ - "MON-01", - "SAT-03.6" + "19(3)(c)(i)": [ + "PRI-06.2" ], - "3107": [ - "MON-03.2", - "MON-10" + "19(3)(c)(i)(A)": [ + "PRI-06.2" ], - "3108": [ - "MON-06" + "19(3)(c)(i)(B)": [ + "PRI-06.2" ], - "3109": [ - "MON-17" + "19(3)(c)(ii)": [ + "PRI-06.2" ], - "3110": [ - "THR-03", - "THR-03.1" + "19(3)(c)(iii)": [ + "PRI-06.2" ], - "3200": [ - "MON-16" + "19(3)(c)(iii)(A)": [ + "PRI-06.2" ], - "3201": [ - "IRO-03" + "19(3)(c)(iii)(B)": [ + "PRI-06.2" ], - "3202": [ - "MON-16" + "19(3)(c)(I)": [ + "PRI-06.2" ], - "3203": [ - "MON-16" + "19(3)(c)(II)": [ + "PRI-06.2" ], - "3204": [ - "AST-02.2" + "19(3)(c)(iv)": [ + "PRI-06.2" ], - "4100": [ - "BCD-01" + "19(3)(c)(v)": [ + "PRI-06.2" ], - "4101": [ - "IRO-04" + "23(1)(b)": [ + "PRI-06.2" ], - "4102": [ - "IRO-04" + "18(5)": [ + "PRI-06.4" ], - "4103": [ - "IRO-06" + "18(5)(a)": [ + "PRI-06.4" ], - "4104": [ - "IRO-01", - "IRO-02" + "18(5)(b)": [ + "PRI-06.4" ], - "4105": [ - "IRO-06" + "19(1)": [ + "PRI-06.4" ], - "4106": [ - "MON-16.3" + "19(1)(a)": [ + "PRI-06.4" ], - "4200": [ - "IRO-13" + "19(1)(a)(i)": [ + "PRI-06.4" ], - "4201": [ - "RSK-04.1", - "RSK-08" + "19(1)(a)(ii)": [ + "PRI-06.4" ], - "4202": [ - "BCD-12", - "BCD-12.2" + "19(1)(b)": [ + "PRI-06.4" ], - "0001": [ - "CPL-01" + "19(3)": [ + "PRI-06.4" ], - "0002": [ - "CPL-01" - ] - }, - "emea-gbr-dpa-1998": { - "Chapter29-Schedule1-Part1-Principle 5": [ - "DCH-08", - "PRI-05" + "19(3)(a)": [ + "PRI-06.4" ], - "Chapter29-Schedule1-Part1-Principle 3 & 5": [ - "DCH-18" + "19(3)(a)(i)": [ + "PRI-06.4" ], - "Chapter29-Schedule1-Part1-Principle 1": [ - "DCH-22" + "19(3)(a)(i)(A)": [ + "PRI-06.4" ], - "Chapter29-Schedule1-Part1-Principles 7": [ - "IRO-04.1" + "19(3)(a)(i)(B)": [ + "PRI-06.4" ], - "Inferred": [ - "PRI-01" + "19(3)(a)(ii)": [ + "PRI-06.4" ], - "Expectation": [ - "PRI-01" + "19(4)": [ + "PRI-06.4" ], - "Chapter29-Schedule1-Part1-Principles 8": [ - "PRI-01.2", - "PRI-02" + "19(4)(a)": [ + "PRI-06.4" ], - "Chapter29-Schedule1-Part1-Principle 3": [ - "PRI-05.1", - "PRI-05.4" - ] - }, - "apac-aus-essential-8-2024": { - "ML1-P1": [ - "AST-02", - "TDA-17", - "VPM-05", - "VPM-06", - "VPM-06.1" + "19(4)(b)": [ + "PRI-06.4" ], - "ML1-P2": [ - "AST-02", - "TDA-17", - "VPM-05", - "VPM-06", - "VPM-06.1" + "19(4)(b)(i)": [ + "PRI-06.4" ], - "ML2-P1": [ - "AST-02", - "TDA-17", - "VPM-05", - "VPM-06", - "VPM-06.1" + "19(4)(b)(ii)": [ + "PRI-06.4" ], - "ML2-P2": [ - "AST-02", - "TDA-17", - "VPM-05", - "VPM-06", - "VPM-06.1" + "19(4)(b)(ii)(A)": [ + "PRI-06.4" ], - "ML3-P1": [ - "AST-02", - "TDA-17", - "VPM-05", - "VPM-06", - "VPM-06.1" + "19(4)(b)(I)": [ + "PRI-06.4" ], - "ML3-P2": [ - "AST-02", - "SEA-07.1", - "TDA-17", - "VPM-05", - "VPM-06", - "VPM-06.1" + "19(4)(b)(II)": [ + "PRI-06.4" ], - "ML2-P4": [ - "AST-27", - "MON-02.2", - "MON-03.3", - "MON-08", - "MON-17", - "IAC-08", - "IAC-15.3", - "IAC-15.9", - "IAC-16", - "IAC-16.4", - "IAC-21", - "IAC-21.2", - "IAC-21.3", - "IRO-02", - "IRO-10", - "SEA-22" + "19(4)(b)(III)": [ + "PRI-06.4" ], - "ML3-P4": [ - "AST-27", - "CFG-02", - "MON-02.2", - "MON-03.3", - "MON-08", - "MON-17", - "IAC-08", - "IAC-15.3", - "IAC-15.9", - "IAC-16", - "IAC-16.4", - "IAC-20.4", - "IAC-21", - "IAC-21.2", - "IAC-21.3", - "IRO-02", - "IRO-10", - "SEA-22" + "19(4)(b)(III)(B)": [ + "PRI-06.4" ], - "ML1-P8": [ - "BCD-01.4", - "BCD-11", - "BCD-11.2", - "BCD-11.5", - "BCD-11.9", - "BCD-11.10" + "21(1)": [ + "PRI-06.4" ], - "ML2-P8": [ - "BCD-01.4", - "BCD-11", - "BCD-11.2", - "BCD-11.5", - "BCD-11.9", - "BCD-11.10" + "21(1)(a)": [ + "PRI-06.4" ], - "ML3-P8": [ - "BCD-01.4", - "BCD-11", - "BCD-11.2", - "BCD-11.5", - "BCD-11.9", - "BCD-11.10" + "21(1)(b)": [ + "PRI-06.4" ], - "ML1-P6": [ - "CFG-02" + "21(1)(c)": [ + "PRI-06.4" ], - "ML1-P7": [ - "CFG-02" + "25(1)": [ + "PRI-06.4" ], - "ML2-P5": [ - "CFG-02", - "CFG-02.1", - "CFG-03.2", - "CFG-03.3", - "MON-02.2", - "MON-03", - "MON-08", - "MON-17", - "IRO-02", - "IRO-10" + "25(1)(b)": [ + "PRI-06.4" ], - "ML2-P6": [ - "CFG-02" + "Schedule 1 - 4(2)": [ + "PRI-07.1" ], - "ML2-P7": [ - "CFG-02", - "MON-02.2", - "MON-08", - "MON-17", - "IRO-02", - "IRO-10" + "24(1)": [ + "PRI-07.4" ], - "ML3-P5": [ - "CFG-02", - "CFG-02.1", - "CFG-03.2", - "CFG-03.3", - "MON-02.2", - "MON-03", - "MON-08", - "MON-17", - "IRO-02", - "IRO-10" + "24(1)(a)": [ + "PRI-07.4" ], - "ML3-P6": [ - "CFG-02", - "CFG-02.1" + "24(1)(b)": [ + "PRI-07.4" ], - "ML3-P7": [ - "CFG-02", - "MON-02.2", - "MON-03.3", - "MON-08", - "MON-17", - "IRO-02", - "IRO-10" + "24(1)(b)(i)": [ + "PRI-07.4" ], - "ML1-P5": [ - "CFG-03.3" + "24(1)(b)(ii)": [ + "PRI-07.4" ], - "ML2-P3": [ - "MON-02.2", - "MON-03", - "MON-08", - "MON-17", - "IAC-06", - "IAC-06.2", - "IAC-06.3", - "IRO-02", - "IRO-10" + "24(2)": [ + "PRI-07.4" ], - "ML3-P3": [ - "MON-02.2", - "MON-03", - "MON-08", - "MON-17", - "IAC-06", - "IAC-06.2", - "IAC-06.3", - "IRO-02", - "IRO-10" + "24(3)": [ + "PRI-07.4" ], - "ML1-P3": [ - "IAC-06" + "24(3)(a)": [ + "PRI-07.4" ], - "ML1-P4": [ - "IAC-08", - "IAC-16", - "IAC-16.4", - "IAC-21", - "IAC-21.2", - "IAC-21.3" - ] - }, - "apac-aus-privacy-act-1998": { - "APP Part 1": [ - "GOV-01" + "24(3)(b)": [ + "PRI-07.4" ], - "APP Part 11": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "24(3)(c)": [ + "PRI-07.4" ], - "APP Part 8": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "24(3)(d)": [ + "PRI-07.4" ], - "APP Part 13": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2", - "PRI-06.4" + "24(3)(e)": [ + "PRI-07.4" ], - "Inferred": [ - "PRI-01" + "24(4)": [ + "PRI-07.4" ], - "Expectation": [ - "PRI-01" + "20(1)": [ + "PRI-07.5" ], - "APP Part 5": [ - "PRI-02" + "20(1)(a)": [ + "PRI-07.5" ], - "APP Part 3": [ - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "20(1)(a)(i)": [ + "PRI-07.5" ], - "APP Part 6": [ - "PRI-05" + "20(1)(a)(ii)": [ + "PRI-07.5" ], - "APP Part 10": [ - "PRI-05.2" + "20(1)(a)(ii)(A)": [ + "PRI-07.5" ], - "APP Part 2": [ - "PRI-05.3" + "20(1)(a)(ii)(B)": [ + "PRI-07.5" ], - "APP Part 12": [ - "PRI-06" - ] - }, - "apac-aus-privacy-principles-2026": { - "APP 1": [ - "GOV-02", - "PRI-01", - "PRI-01.3", - "PRI-02", - "PRI-02.1" + "20(1)(b)": [ + "PRI-07.5" ], - "APP 8": [ - "CLD-09", - "DCH-19", - "PRI-07" + "20(1)(c)": [ + "PRI-07.5" ], - "APP 11": [ - "DCH-01" + "20(2)(a)": [ + "PRI-07.5" ], - "APP 13": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2", - "PRI-06.4" + "20(2)(b)": [ + "PRI-07.5" ], - "APP 2": [ - "IAC-09.6" + "20(3)": [ + "PRI-07.5" ], - "APP 5": [ - "PRI-02", - "PRI-03.2" + "20(3)(a)": [ + "PRI-07.5" ], - "APP 3": [ - "PRI-03", - "PRI-04", - "PRI-04.1" + "20(3)(b)": [ + "PRI-07.5" ], - "APP 7": [ - "PRI-03.3", - "PRI-04.1", - "PRI-05.4", - "PRI-07", - "PRI-07.1" + "20(3)(c)": [ + "PRI-07.5" ], - "APP 4": [ - "PRI-05" + "20(3)(c)(i)": [ + "PRI-07.5" ], - "APP 6": [ - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "20(3)(c)(ii)": [ + "PRI-07.5" ], - "APP 10": [ - "PRI-05.2" + "20(3)(c)(iii)": [ + "PRI-07.5" ], - "APP 9": [ - "PRI-05.4", - "PRI-05.7" + "20(3)(d)": [ + "PRI-07.5" ], - "APP 12": [ - "PRI-06", - "PRI-06.4" - ] - }, - "apac-aus-ism-2024-june": { - "ISM-0888": [ - "GOV-01", - "GOV-02" + "20(3)(e)": [ + "PRI-07.5" ], - "ISM-0725": [ - "GOV-01.1", - "GOV-04", - "HRS-03" + "20(3)(f)": [ + "PRI-07.5" ], - "ISM-0718": [ - "GOV-01.2" + "25(1)(a)": [ + "PRI-07.5" ], - "ISM-0047": [ - "GOV-02" + "27(1)": [ + "PRI-14" ], - "ISM-1478": [ - "GOV-02" + "27(1)(a)": [ + "PRI-14" ], - "ISM-1551": [ - "GOV-02" + "27(1)(b)": [ + "PRI-14" ], - "ISM-1602": [ - "GOV-02" + "27(1)(c)": [ + "PRI-14" ], - "ISM-1784": [ - "GOV-02", - "IRO-04" + "27(1)(c)(i)": [ + "PRI-14" ], - "ISM-1785": [ - "GOV-02", - "RSK-09", - "TPM-01" + "27(1)(c)(ii)": [ + "PRI-14" ], - "ISM-1617": [ - "GOV-03" + "27(2)": [ + "PRI-14" ], - "ISM-0714": [ - "GOV-04" + "27(2)(a)": [ + "PRI-14" ], - "ISM-0717": [ - "GOV-04", - "HRS-03" + "27(2)(b)": [ + "PRI-14" ], - "ISM-0720": [ - "GOV-04", - "HRS-03", - "PRM-01", - "PRM-01.1", - "PRM-05", - "SAT-01" + "27(2)(c)": [ + "PRI-14" ], - "ISM-0724": [ - "GOV-04", - "GOV-05", - "HRS-03" + "27(2)(d)": [ + "PRI-14" ], - "ISM-0726": [ - "GOV-04", - "HRS-03", - "RSK-01" + "27(3)": [ + "PRI-14" ], - "ISM-0731": [ - "GOV-04", - "HRS-03", - "RSK-09", - "TPM-03" + "27(3)(a)": [ + "PRI-14" ], - "ISM-0732": [ - "GOV-04", - "HRS-03", - "PRM-01", - "PRM-02", - "PRM-03" + "27(3)(b)": [ + "PRI-14" ], - "ISM-0733": [ - "GOV-04", - "HRS-03", - "IRO-07", - "IRO-09", - "IRO-10", - "IRO-10.2" + "27(3)(c)": [ + "PRI-14" ], - "ISM-0734": [ - "GOV-04", - "BCD-01", - "HRS-03" + "27(3)(d)": [ + "PRI-14" ], - "ISM-0735": [ - "GOV-04", - "HRS-03", - "SAT-01" + "27(4)": [ + "PRI-14" ], - "ISM-1633": [ - "GOV-15" + "27(4)(a)": [ + "PRI-14" ], - "ISM-1634": [ - "GOV-15", - "GOV-15.1" + "27(4)(b)": [ + "PRI-14" + ] + }, + "apac-ind-dpdpa-2023": { + "8(6)": [ + "GOV-01.1", + "IRO-04.1", + "IRO-09", + "IRO-10" ], - "ISM-1635": [ - "GOV-15", - "GOV-15.2" + "18(2)": [ + "GOV-01.1" ], - "ISM-1636": [ - "GOV-15", - "GOV-15.3" + "23(1)": [ + "GOV-01.1" ], - "ISM-0027": [ - "GOV-15.4", - "IAO-01", - "IAO-07" + "26(a)": [ + "GOV-01.1" ], - "ISM-1526": [ - "GOV-15.5", - "PRM-07", - "RSK-03" + "26(b)": [ + "GOV-01.1" ], - "ISM-1587": [ - "GOV-17" + "26(c)": [ + "GOV-01.1" ], - "ISM-0285": [ - "AST-01" + "27(1)(a)": [ + "GOV-01.1" ], - "ISM-0286": [ - "AST-01" + "27(1)(b)": [ + "GOV-01.1" ], - "ISM-0289": [ - "AST-01" + "27(1)(c)": [ + "GOV-01.1" ], - "ISM-0290": [ - "AST-01" + "27(1)(d)": [ + "GOV-01.1" ], - "ISM-0591": [ - "AST-01" + "27(1)(e)": [ + "GOV-01.1" ], - "ISM-1457": [ - "AST-01" + "27(2)": [ + "GOV-01.1" ], - "ISM-1480": [ - "AST-01" + "27(3)": [ + "GOV-01.1" ], - "ISM-0336": [ - "AST-02", - "DCH-06.2" + "28(1)": [ + "GOV-01.1" ], - "ISM-1643": [ - "AST-02" + "28(2)": [ + "GOV-01.1" ], - "ISM-1807": [ - "AST-02", - "AST-02.2" + "28(3)": [ + "GOV-01.1" ], - "ISM-0520": [ - "AST-02.5" + "28(4)": [ + "GOV-01.1" ], - "ISM-1182": [ - "AST-02.5" + "28(5)": [ + "GOV-01.1" ], - "ISM-1493": [ - "AST-02.9", - "VPM-01", - "VPM-05" + "28(6)": [ + "GOV-01.1" ], - "ISM-1071": [ - "AST-03" + "10(2)(c)(ii)": [ + "GOV-01.2", + "CPL-02.2" ], - "ISM-1790": [ - "AST-03.2", - "TDA-11" + "19(3)": [ + "GOV-04" ], - "ISM-1791": [ - "AST-03.2", - "TDA-11" + "7(c)": [ + "CPL-01" ], - "ISM-1792": [ - "AST-03.2", - "TDA-11" + "7(d)": [ + "CPL-01" ], - "ISM-0516": [ - "AST-04" + "7(e)": [ + "CPL-01" ], - "ISM-0518": [ - "AST-04" + "8(1)": [ + "CPL-01", + "PRI-05.4" ], - "ISM-1645": [ - "AST-04" + "8(4)": [ + "CPL-01", + "PRI-01.6" ], - "ISM-1646": [ - "AST-04" + "10(2)(b)": [ + "CPL-02.1", + "CPL-03.1" ], - "ISM-0161": [ - "AST-05", - "AST-06" + "13(1)": [ + "CPL-07" ], - "ISM-0293": [ - "AST-05", - "IAO-07" + "13(2)": [ + "CPL-07.1" ], - "ISM-1178": [ - "AST-05" + "8(7)(a)": [ + "DCH-09.3", + "DCH-18", + "PRI-03.4", + "PRI-06.5" ], - "ISM-0311": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-21" + "8(8)": [ + "DCH-18" ], - "ISM-0312": [ - "AST-09", - "DCH-08" + "21(1)(a)": [ + "HRS-01" ], - "ISM-0315": [ - "AST-09", - "DCH-08" + "21(1)(b)": [ + "HRS-01" ], - "ISM-0318": [ - "AST-09" + "21(1)(c)": [ + "HRS-01" ], - "ISM-0321": [ - "AST-09" + "21(1)(d)": [ + "HRS-01" ], - "ISM-0330": [ - "AST-09", - "DCH-11" + "21(1)(e)": [ + "HRS-01" ], - "ISM-0350": [ - "AST-09" + "21(2)": [ + "HRS-01" ], - "ISM-0363": [ - "AST-09", - "DCH-08", - "DCH-09.1" + "22(1)": [ + "HRS-01" ], - "ISM-0370": [ - "AST-09", - "DCH-09.1" + "22(2)": [ + "HRS-01" ], - "ISM-0372": [ - "AST-09", - "DCH-09.1" + "22(3)": [ + "HRS-01" ], - "ISM-0378": [ - "AST-09", - "DCH-08" + "6(9)": [ + "HRS-03" ], - "ISM-0839": [ - "AST-09", - "DCH-08" + "10(2)(a)(iv)": [ + "HRS-03", + "PRI-01.4" ], - "ISM-1076": [ - "AST-09" + "10(2)(a)": [ + "PRI-01.4" ], - "ISM-1217": [ - "AST-09", - "DCH-08", - "PES-16" + "8(5)": [ + "PRI-01.6" ], - "ISM-1218": [ - "AST-09", - "DCH-08" + "5(3)": [ + "PRI-01.8" ], - "ISM-1219": [ - "AST-09" + "8(9)": [ + "PRI-01.8" ], - "ISM-1220": [ - "AST-09" + "8(10)": [ + "PRI-01.8" ], - "ISM-1221": [ - "AST-09" + "8(11)": [ + "PRI-01.8" ], - "ISM-1222": [ - "AST-09" + "10(2)": [ + "PRI-01.8" ], - "ISM-1223": [ - "AST-09" + "10(2)(a)(i)": [ + "PRI-01.8" ], - "ISM-1225": [ - "AST-09" + "10(2)(a)(ii)": [ + "PRI-01.8" ], - "ISM-1534": [ - "AST-09" + "10(2)(a)(iii)": [ + "PRI-01.8" ], - "ISM-1550": [ - "AST-09", - "DCH-08" + "6(8)": [ + "PRI-01.9" ], - "ISM-1641": [ - "AST-09" + "5(1)(i)": [ + "PRI-02", + "PRI-02.1" ], - "ISM-1722": [ - "AST-09", - "DCH-08" + "5(1)(ii)": [ + "PRI-02" ], - "ISM-1723": [ - "AST-09", - "DCH-08" + "5(1)(iii)": [ + "PRI-02" ], - "ISM-1724": [ - "AST-09", - "DCH-08" + "5(2)(a)(i)": [ + "PRI-02", + "PRI-02.1" ], - "ISM-1725": [ - "AST-09", - "DCH-08" + "5(2)(a)(ii)": [ + "PRI-02" ], - "ISM-1726": [ - "AST-09", - "DCH-08" + "5(2)(a)(iii)": [ + "PRI-02" ], - "ISM-1727": [ - "AST-09", - "DCH-08" + "6(3)": [ + "PRI-02", + "PRI-03" ], - "ISM-1728": [ - "AST-09", - "PES-16" + "6(10)": [ + "PRI-02", + "PRI-03" ], - "ISM-1729": [ - "AST-09", - "PES-16" + "4(2)": [ + "PRI-02.1" ], - "ISM-1741": [ - "AST-09" + "7(a)": [ + "PRI-02.1", + "PRI-03" ], - "ISM-1742": [ - "AST-09" + "8(8)(a)": [ + "PRI-02.1" ], - "ISM-0233": [ - "AST-14.1", - "HRS-05.2" + "4(1)(a)": [ + "PRI-03" ], - "ISM-1199": [ - "AST-14.1", - "HRS-05.2", - "HRS-05.5" + "6(1)": [ + "PRI-03" ], - "ISM-1200": [ - "AST-14.1", - "HRS-05.2", - "HRS-05.5" + "6(7)": [ + "PRI-03", + "PRI-03.4", + "PRI-03.6" ], - "ISM-1297": [ - "AST-16", - "MDM-01", - "MDM-06" + "7(b)(i)": [ + "PRI-03" ], - "ISM-0558": [ - "AST-19", - "AST-21" + "8(8)(b)": [ + "PRI-03", + "PRI-03.4" ], - "ISM-0548": [ - "AST-20", - "CRY-01.3" + "5(2)(b)": [ + "PRI-03.4", + "PRI-03.9" ], - "ISM-0551": [ - "AST-20", - "AST-21" + "6(4)": [ + "PRI-03.4" ], - "ISM-0553": [ - "AST-20" + "9(1)": [ + "PRI-03.6" ], - "ISM-0554": [ - "AST-20", - "CRY-01.3" + "14(1)": [ + "PRI-03.6" ], - "ISM-0555": [ - "AST-20", - "AST-21" + "9(2)": [ + "PRI-03.9" ], - "ISM-1014": [ - "AST-20", - "AST-21" + "9(3)": [ + "PRI-03.9" ], - "ISM-1562": [ - "AST-20", - "CFG-02", - "HRS-05.2", - "NET-03.2" + "6(6)": [ + "PRI-03.10" ], - "ISM-0549": [ - "AST-21" + "4(1)(b)": [ + "PRI-04.1" ], - "ISM-0556": [ - "AST-21" + "8(3)": [ + "PRI-05.2" ], - "ISM-0559": [ - "AST-22" + "8(3)(a)": [ + "PRI-05.2" ], - "ISM-1450": [ - "AST-22" + "8(3)(b)": [ + "PRI-05.2" ], - "ISM-0245": [ - "AST-23" + "7(f)": [ + "PRI-05.4" ], - "ISM-0589": [ - "AST-23" + "7(g)": [ + "PRI-05.4" ], - "ISM-0590": [ - "AST-23" + "7(h)": [ + "PRI-05.4" ], - "ISM-1036": [ - "AST-23", - "PES-12.2" + "7(i)": [ + "PRI-05.4" ], - "ISM-1088": [ - "AST-24", - "IRO-10" + "11(1)(c)": [ + "PRI-06" ], - "ISM-1298": [ - "AST-24" + "11(2)": [ + "PRI-06" ], - "ISM-1299": [ - "AST-24" + "12(1)": [ + "PRI-06.1", + "PRI-06.5" ], - "ISM-1300": [ - "AST-24", - "AST-25", - "DCH-09" + "12(2)(a)": [ + "PRI-06.1" ], - "ISM-1554": [ - "AST-24" + "12(2)(b)": [ + "PRI-06.1" ], - "ISM-1555": [ - "AST-24" + "12(3)": [ + "PRI-06.5" ], - "ISM-1556": [ - "AST-24", - "AST-25" + "11(1)(a)": [ + "PRI-06.7" ], - "ISM-0042": [ - "AST-26" + "8(2)": [ + "PRI-07", + "PRI-07.1" ], - "ISM-1380": [ - "AST-26", - "IAC-16", - "IAC-21" + "8(7)(b)": [ + "PRI-07.1", + "TPM-05", + "TPM-05.2" ], - "ISM-1385": [ - "AST-26", - "AST-27", - "CLD-03", - "NET-06.1", - "NET-06.4" + "12(2)(c)": [ + "PRI-12.1" ], - "ISM-1387": [ - "AST-27" + "11(1)(b)": [ + "PRI-14.1" ], - "ISM-0393": [ - "AST-28", - "DCH-02" + "10(2)(c)(i)": [ + "RSK-10" + ] + }, + "apac-ind-privacy-rules-2011": { + "4": [ + "PRI-02" ], - "ISM-1243": [ - "AST-28" + "7": [ + "PRI-01.5" ], - "ISM-1255": [ - "AST-28" + "5(9)": [ + "CPL-07", + "PRI-06.4" ], - "ISM-1256": [ - "AST-28" + "6(1)": [ + "DCH-03.1" ], - "ISM-1268": [ - "AST-28" + "6(2)": [ + "DCH-03.1" ], - "ISM-1269": [ - "AST-28", - "NET-06", - "NET-06.6" + "6(3)": [ + "DCH-03.1" ], - "ISM-1270": [ - "AST-28", - "NET-06", - "NET-06.6" + "8(1)": [ + "PRI-01", + "PRI-01.11" ], - "ISM-1271": [ - "AST-28", - "NET-06", - "NET-06.6" + "5(8)": [ + "PRI-01.6" ], - "ISM-1272": [ - "AST-28" + "8(2)": [ + "PRI-01.6" ], - "ISM-1273": [ - "AST-28", - "TDA-08" + "4(v)": [ + "PRI-01.11", + "PRI-02" ], - "ISM-1274": [ - "AST-28", - "TDA-08" + "8(4)": [ + "PRI-01.11" ], - "ISM-1275": [ - "AST-28", - "NET-18" + "4(i)": [ + "PRI-02" ], - "ISM-1276": [ - "AST-28" + "4(ii)": [ + "PRI-02" ], - "ISM-1277": [ - "AST-28", - "CRY-05.3" + "4(iii)": [ + "PRI-02" ], - "ISM-1278": [ - "AST-28" + "4(iv)": [ + "PRI-02" ], - "ISM-1245": [ - "AST-28.1" + "5(3)": [ + "PRI-02" ], - "ISM-1246": [ - "AST-28.1" + "5(3)(a)": [ + "PRI-02" ], - "ISM-1247": [ - "AST-28.1" + "5(3)(b)": [ + "PRI-02" ], - "ISM-1249": [ - "AST-28.1" + "5(3)(c)": [ + "PRI-02" ], - "ISM-1250": [ - "AST-28.1" + "5(3)(d)": [ + "PRI-02" ], - "ISM-1260": [ - "AST-28.1" + "5(3)(d)(i)": [ + "PRI-02" ], - "ISM-1263": [ - "AST-28.1" + "5(3)(d)(ii)": [ + "PRI-02" ], - "ISM-1810": [ - "BCD-01.4", - "BCD-11" + "5(1)": [ + "PRI-03" ], - "ISM-0859": [ - "BCD-11", - "MON-08", - "MON-10", - "DCH-18" + "5(7)": [ + "PRI-03" ], - "ISM-0991": [ - "BCD-11", - "MON-08", - "MON-10", - "DCH-18" + "5(2)": [ + "PRI-04" ], - "ISM-1511": [ - "BCD-11" + "5(2)(a)": [ + "PRI-04" ], - "ISM-1547": [ - "BCD-11" + "5(2)(b)": [ + "PRI-04" ], - "ISM-1548": [ - "BCD-11" + "5(5)": [ + "PRI-04" ], - "ISM-1811": [ - "BCD-11", - "BCD-11.2" + "5(4)": [ + "PRI-05" ], - "ISM-1515": [ - "BCD-11.1" + "5(6)": [ + "PRI-05.2" ], - "ISM-1789": [ - "BCD-15", - "TPM-03", - "TPM-03.1" + "6(4)": [ + "PRI-07.1" + ] + }, + "apac-ind-sebi-2024": { + "GV.OC.S1": [ + "GOV-01", + "GOV-04.2", + "GOV-09" ], - "ISM-1579": [ - "CAP-01", - "CAP-02", - "CAP-03", - "CAP-05", - "CLD-01" + "GV.OC.S2": [ + "GOV-01", + "CPL-01" ], - "ISM-1580": [ - "CAP-01", - "CAP-02", - "CAP-03", - "CLD-01" + "PR.IP.S17": [ + "GOV-01", + "CPL-01.3", + "SEA-01" ], - "ISM-1581": [ - "CAP-01", - "CAP-02", - "CAP-03", - "CLD-01" + "GV.OV.S2": [ + "GOV-01.1" ], - "ISM-1211": [ - "CHG-01", - "CHG-02" + "GV.RR.S1": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1", + "GOV-14" ], - "ISM-1796": [ - "CHG-04.2", - "TDA-01.1" + "GV.RR.S3": [ + "GOV-01.1", + "GOV-04" ], - "ISM-0405": [ - "CHG-04.5", - "IAC-17", - "IAC-28.1" + "GV.RR.S4": [ + "GOV-01.1", + "PRM-01", + "PRM-01.1", + "PRM-03" ], - "ISM-1437": [ - "CLD-01" + "GV.OV.S1": [ + "GOV-01.2" ], - "ISM-1529": [ - "CLD-01", - "CLD-06" + "GV.PO.S1": [ + "GOV-02" ], - "ISM-1750": [ - "CLD-03", - "NET-06", - "NET-06.1" + "GV.PO.S3": [ + "GOV-02.1", + "GOV-03" ], - "ISM-1572": [ - "CLD-09", - "IAO-03.2", - "TPM-04.4", - "TPM-05" + "GV.PO.S2": [ + "GOV-03" ], - "ISM-1438": [ - "CLD-12" + "GV.PO.S4": [ + "GOV-03" ], - "ISM-1439": [ - "CLD-12" + "GV.RR.S2": [ + "GOV-04", + "GOV-04.1", + "HRS-02", + "HRS-03" ], - "ISM-0078": [ - "CPL-01" + "GV.PO.S5": [ + "GOV-04.2", + "AST-01", + "AST-01.2", + "AST-03" ], - "ISM-0854": [ - "CPL-01" + "GV.OV.S3": [ + "GOV-05" ], - "ISM-0100": [ - "CPL-03.1", - "IAO-02", - "IAO-02.2", - "IAO-02.3" + "GV.OV.S4": [ + "GOV-05" ], - "ISM-0341": [ - "CFG-02", - "DCH-10" + "PR.IP.S10": [ + "GOV-05" ], - "ISM-0343": [ - "CFG-02", - "DCH-10", - "DCH-10.1" + "GV.RM.S1": [ + "GOV-09", + "RSK-01" ], - "ISM-0345": [ - "CFG-02" + "GV.RM.S2": [ + "GOV-15" ], - "ISM-0380": [ - "CFG-02" + "ID.AM.S1": [ + "AST-02" ], - "ISM-0383": [ - "CFG-02", - "TDA-09.6" + "ID.AM.S5": [ + "AST-02", + "DCH-06.2" ], - "ISM-0567": [ - "CFG-02", - "NET-20.7" + "ID.AM.S6": [ + "AST-02" ], - "ISM-1316": [ - "CFG-02", - "NET-15" + "ID.AM.S2": [ + "AST-02.8", + "AST-04" ], - "ISM-1318": [ - "CFG-02", - "NET-15" + "PR.AA.S14": [ + "AST-09", + "DCH-01", + "DCH-06", + "OPS-01.1" ], - "ISM-1319": [ - "CFG-02", - "NET-15" + "PR.IP.S11": [ + "BCD-01", + "BCD-04" ], - "ISM-1321": [ - "CFG-02", - "NET-15" + "RC.RP.S1": [ + "BCD-01", + "BCD-01.5" ], - "ISM-1406": [ - "CFG-02" + "RC.RP.S4": [ + "BCD-01", + "BCD-11", + "OPS-01.1" ], - "ISM-1407": [ - "CFG-02", - "CFG-02.1" + "RS.MA.S3": [ + "BCD-01", + "IRO-04" ], - "ISM-1408": [ - "CFG-02" + "GV.SC.S6": [ + "BCD-01.2", + "IRO-02.5" ], - "ISM-1409": [ - "CFG-02" + "RC.RP.S2": [ + "BCD-01.4" ], - "ISM-1418": [ - "CFG-02", - "END-07" + "ID.AM.S4": [ + "BCD-02", + "IAO-01" ], - "ISM-1491": [ - "CFG-02" + "GV.RM.S3": [ + "BCD-04", + "IRO-04", + "IRO-06" ], - "ISM-1492": [ - "CFG-02" + "RC.IM.S2": [ + "BCD-04", + "BCD-05" ], - "ISM-1584": [ - "CFG-02" + "RC.RP.S3": [ + "BCD-04" ], - "ISM-1604": [ - "CFG-02", - "SEA-13.1" + "RC.IM.S1": [ + "BCD-05", + "IRO-13" ], - "ISM-1608": [ - "CFG-02", - "END-04", - "END-04.4" + "RS.AN.S4": [ + "BCD-05", + "IRO-13" ], - "ISM-1621": [ - "CFG-02", - "CFG-03" + "RS.AN.S4a": [ + "BCD-05", + "IRO-13" ], - "ISM-1622": [ - "CFG-02" + "RS.AN.S4b": [ + "BCD-05", + "IRO-13" ], - "ISM-1623": [ - "CFG-02" + "RS.IM.S1": [ + "BCD-05", + "IRO-13" ], - "ISM-1624": [ - "CFG-02" + "PR.IP.S7": [ + "BCD-11", + "BCD-12", + "OPS-01.1" ], - "ISM-1654": [ - "CFG-02", - "CFG-04.2" + "PR.IP.S8": [ + "BCD-11", + "BCD-11.1" ], - "ISM-1655": [ - "CFG-02", - "CFG-04.2", - "CFG-05" + "PR.DS.S3": [ + "CAP-01" ], - "ISM-1710": [ - "CFG-02" + "DE.CM.S4": [ + "CAP-04" ], - "ISM-1745": [ - "CFG-02" + "PR.IP.S3": [ + "CHG-01", + "CHG-02", + "CFG-01" ], - "ISM-1588": [ - "CFG-02.1" + "PR.MA.S1": [ + "CHG-02.2", + "MNT-02" ], - "ISM-1510": [ - "CFG-02.3", - "DCH-18" + "PR.IP.S13": [ + "CLD-01", + "CLD-02", + "CPL-01" ], - "ISM-0534": [ - "CFG-02.5" + "PR.AA.S17": [ + "CLD-04" ], - "ISM-1656": [ - "CFG-02.5" + "PR.DS.S2": [ + "CLD-09", + "DCH-02", + "DCH-26" ], - "ISM-1657": [ - "CFG-02.5" + "RS.MA.S5": [ + "CPL-01", + "IRO-02.5" ], - "ISM-1658": [ - "CFG-02.5" + "EV.ST.S4": [ + "CPL-02", + "RSK-06.2", + "THR-03" ], - "ISM-1659": [ - "CFG-02.5" + "DE.CM.S5": [ + "CPL-02.2", + "CPL-03.2", + "CFG-03.1" ], - "ISM-1667": [ - "CFG-02.5" + "EV.ST.S5": [ + "CPL-03" ], - "ISM-1668": [ - "CFG-02.5" + "PR.IP.S14": [ + "CPL-03.1" ], - "ISM-1669": [ - "CFG-02.5" + "PR.IP.S1": [ + "CFG-02", + "CFG-02.1", + "CFG-03" ], - "ISM-1670": [ - "CFG-02.5" + "PR.DS.S6": [ + "CFG-06", + "CFG-06.1", + "END-06", + "END-06.1" ], - "ISM-1671": [ - "CFG-02.5" + "DE.CM.S2": [ + "MON-01" ], - "ISM-1672": [ - "CFG-02.5" + "PR.AA.S8": [ + "MON-01" ], - "ISM-1673": [ - "CFG-02.5" + "DE.CM.S3": [ + "MON-01.8", + "MON-17" ], - "ISM-1674": [ - "CFG-02.5" + "PR.AA.S9": [ + "MON-03", + "MON-08", + "MON-10" ], - "ISM-1675": [ - "CFG-02.5" + "PR.DS.S1": [ + "CRY-01", + "CRY-03", + "CRY-05" ], - "ISM-1676": [ - "CFG-02.5" + "PR.DS.S4": [ + "DCH-01", + "NET-03.5", + "NET-17" ], - "ISM-1677": [ - "CFG-02.5" + "PR.AA.S13": [ + "DCH-18", + "DCH-21" ], - "ISM-1748": [ - "CFG-02.5" + "PR.IP.S4": [ + "END-04", + "END-04.7" ], - "ISM-1749": [ - "CFG-02.5", - "IAC-10.5" + "GV.RR.S6": [ + "HRS-01", + "HRS-03.1", + "SAT-01" ], - "ISM-1800": [ - "CFG-02.5" + "RS.CO.S1": [ + "HRS-01", + "HRS-02", + "HRS-03" ], - "ISM-0385": [ - "CFG-03" + "DE.DP.S1": [ + "HRS-02", + "HRS-03" ], - "ISM-1006": [ - "CFG-03", - "END-16" + "PR.AT.S4": [ + "HRS-02", + "HRS-03", + "HRS-03.1" ], - "ISM-1311": [ - "CFG-03" + "PR.AT.S5": [ + "HRS-03", + "HRS-03.1" ], - "ISM-1312": [ - "CFG-03" + "GV.RR.S5": [ + "HRS-06", + "HRS-06.1" ], - "ISM-1392": [ - "CFG-03", - "CFG-06", - "CFG-06.1", + "PR.AA.S3": [ + "HRS-11", + "IAC-08", "IAC-21" ], - "ISM-1479": [ - "CFG-03" - ], - "ISM-1487": [ - "CFG-03" + "PR.AA.S1": [ + "IAC-01", + "IAC-15" ], - "ISM-1488": [ - "CFG-03" + "PR.AA.S6": [ + "IAC-01", + "IAC-10" ], - "ISM-1489": [ - "CFG-03" + "PR.AA.S15": [ + "IAC-01", + "IAC-20" ], - "ISM-0843": [ - "CFG-03.3", - "CFG-06", - "CFG-06.1" + "PR.AA.S7": [ + "IAC-06" ], - "ISM-0846": [ - "CFG-03.3", - "CFG-06", - "CFG-06.1" + "PR.AA.S11": [ + "IAC-16", + "IAC-21.4" ], - "ISM-1235": [ - "CFG-03.3", - "CFG-04.2" + "PR.AA.S5": [ + "IAC-17" ], - "ISM-1544": [ - "CFG-03.3", - "CFG-06", - "CFG-06.1" + "RS.MA.S1": [ + "IRO-01", + "IRO-04" ], - "ISM-0705": [ - "CFG-03.4", - "HRS-05.5" + "RS.MA.S2": [ + "IRO-02" ], - "ISM-0824": [ - "CFG-04.2", - "HRS-03.1", - "HRS-05", - "HRS-05.2", - "SAT-02", - "SAT-03.2" + "RS.AN.S2": [ + "IRO-02.4" ], - "ISM-1412": [ - "CFG-04.2" + "RS.CO.S3": [ + "IRO-02.5", + "IRO-09", + "IRO-10", + "IRO-10.4" ], - "ISM-1470": [ - "CFG-04.2" + "DE.DP.S2": [ + "IRO-04", + "IRO-06" ], - "ISM-1485": [ - "CFG-04.2" + "EV.ST.S3": [ + "IRO-04.2", + "IRO-13" ], - "ISM-1486": [ - "CFG-04.2" + "RS.IM.S2": [ + "IRO-04.2", + "IRO-05" ], - "ISM-1542": [ - "CFG-04.2" + "RS.AN.S3": [ + "IRO-08", + "IRO-13" ], - "ISM-1585": [ - "CFG-04.2" + "DE.DP.S3": [ + "IRO-10", + "IRO-10.2" ], - "ISM-1601": [ - "CFG-04.2" + "RC.CO.S2": [ + "IRO-10" ], - "ISM-0382": [ - "CFG-05", - "CFG-05.2" + "RC.CO.S3": [ + "IRO-10" ], - "ISM-1592": [ - "CFG-05", - "CFG-05.2", - "IAC-21.5" + "RS.CO.S2": [ + "IRO-10", + "IRO-10.2" ], - "ISM-0955": [ - "CFG-06", - "CFG-06.1" + "RS.AN.S5": [ + "IRO-13" ], - "ISM-1471": [ - "CFG-06", - "CFG-06.1" + "RC.CO.S1": [ + "IRO-16" ], - "ISM-1490": [ - "CFG-06", - "CFG-06.1" + "PR.AA.S16": [ + "IAO-01", + "IAO-02" ], - "ISM-1582": [ - "CFG-06", - "CFG-06.1" + "PR.MA.S2": [ + "MNT-05", + "MNT-05.5" ], - "ISM-0109": [ - "MON-01", - "MON-01.8", - "MON-01.16", - "MON-02" + "PR.AA.S2": [ + "NET-01", + "NET-06" ], - "ISM-0120": [ - "MON-01", - "MON-01.16", - "MON-11.3" + "PR.AA.S4": [ + "NET-01.1" ], - "ISM-0580": [ - "MON-01", - "MON-01.16" + "ID.AM.S3": [ + "NET-04.11", + "OPS-07" ], - "ISM-0660": [ - "MON-01", - "MON-01.16" + "PR.AA.S12": [ + "NET-14" ], - "ISM-1163": [ - "MON-01", - "MON-01.16", - "VPM-01", - "VPM-03", - "VPM-06", - "VPM-07" + "PR.AA.S10": [ + "PES-01", + "PES-03", + "PES-03.4", + "PES-05" ], - "ISM-1294": [ - "MON-01", - "MON-01.16" + "PR.IP.S9": [ + "PES-01", + "PES-01.1" ], - "ISM-1586": [ - "MON-01", - "MON-01.16" + "PR.IP.S2": [ + "PRM-07" ], - "ISM-0261": [ - "MON-01.9" + "GV.RM.S4": [ + "RSK-01.3", + "RSK-01.5", + "RSK-04.1" ], - "ISM-1228": [ - "MON-02", - "MON-02.1", - "MON-02.2" + "ID.RA.S1": [ + "RSK-04", + "VPM-06" ], - "ISM-1405": [ - "MON-02" + "ID.RA.S2": [ + "RSK-04" ], - "ISM-1536": [ - "MON-02", - "MON-03" + "ID.RA.S5": [ + "RSK-06" ], - "ISM-1537": [ - "MON-02", - "MON-03", - "MON-03.3", - "MON-03.7" + "EV.ST.S1": [ + "RSK-06.2", + "THR-01", + "THR-03" ], - "ISM-1566": [ - "MON-02" + "GV.SC.S7": [ + "RSK-09.1" ], - "ISM-1650": [ - "MON-02", - "MON-16.4", - "IAC-16" + "EV.ST.S2": [ + "SEA-13" ], - "ISM-0988": [ - "MON-02.7", - "SEA-20" + "DE.CM.S1": [ + "OPS-04" ], - "ISM-0582": [ - "MON-03" + "PR.AT.S1": [ + "SAT-01" ], - "ISM-0585": [ - "MON-03" + "PR.AT.S2": [ + "SAT-03", + "SAT-03.5" ], - "ISM-0407": [ - "MON-03.2", - "IAC-01.1" + "GV.SC.S5": [ + "TDA-04.2" ], - "ISM-1660": [ - "MON-06", - "MON-16" + "PR.IP.S5": [ + "TDA-04.2", + "TPM-05.6" ], - "ISM-1213": [ - "MON-10", - "IRO-13" + "PR.DS.S5": [ + "TDA-08" ], - "ISM-1091": [ - "MON-11.3", - "CRY-01" + "PR.IP.S6": [ + "TDA-09" ], - "ISM-1625": [ - "MON-16.1", - "IRO-02.2", - "THR-04", - "THR-05" + "GV.OC.S3": [ + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03", + "TPM-05", + "TPM-05.4" ], - "ISM-0142": [ - "CRY-01" + "GV.SC.S1": [ + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03" ], - "ISM-0457": [ - "CRY-01" + "PR.IP.S15": [ + "TPM-01", + "TPM-05.8" ], - "ISM-0460": [ - "CRY-01" + "GV.SC.S2": [ + "TPM-01.1", + "TPM-02" ], - "ISM-0471": [ - "CRY-01" + "GV.SC.S3": [ + "TPM-05", + "TPM-05.2", + "TPM-05.4", + "TPM-05.7" ], - "ISM-0472": [ - "CRY-01" + "GV.SC.S8": [ + "TPM-05", + "TPM-05.2" ], - "ISM-0474": [ - "CRY-01" + "PR.AT.S3": [ + "TPM-05", + "TPM-05.4", + "TPM-06" ], - "ISM-0475": [ - "CRY-01" + "PR.IP.S16": [ + "TPM-05.8" ], - "ISM-0476": [ - "CRY-01" + "GV.SC.S4": [ + "TPM-08", + "TPM-09", + "TPM-10" ], - "ISM-0477": [ - "CRY-01" + "ID.RA.S3": [ + "THR-03" ], - "ISM-0479": [ - "CRY-01" + "RS.AN.S1": [ + "THR-03", + "THR-03.1" ], - "ISM-0481": [ - "CRY-01" + "DE.DP.S5": [ + "THR-07" ], - "ISM-0499": [ - "CRY-01" + "ID.RA.S4": [ + "THR-10" ], - "ISM-0501": [ - "CRY-01" + "PR.IP.S12": [ + "VPM-01" ], - "ISM-0994": [ - "CRY-01" + "PR.MA.S3": [ + "VPM-02", + "VPM-03", + "VPM-05" ], - "ISM-0999": [ - "CRY-01", - "NET-13" + "DE.DP.S4": [ + "VPM-10" + ] + }, + "apac-jpn-appi-2020": { + "IV.5.53(2)": [ + "GOV-17" ], - "ISM-1080": [ - "CRY-01", - "CRY-05", - "CRY-05.3" + "IV.1.16-2": [ + "CPL-01" ], - "ISM-1146": [ - "CRY-01", - "HRS-05", - "IAC-01", - "SAT-02", - "SAT-03" + "IV.1.26(1)": [ + "CPL-01" ], - "ISM-1446": [ - "CRY-01" + "IV.1.26(1)(i)": [ + "CPL-01" ], - "ISM-1629": [ - "CRY-01" + "IV.1.26(1)(ii)": [ + "CPL-01" ], - "ISM-1759": [ - "CRY-01" + "IV.1.26(2)": [ + "CPL-01" ], - "ISM-1761": [ - "CRY-01" + "IV.5.52(1)": [ + "CPL-07" ], - "ISM-1762": [ - "CRY-01" + "IV.5.52(2)": [ + "CPL-07" ], - "ISM-1763": [ - "CRY-01" + "IV.5.52(3)": [ + "CPL-07" ], - "ISM-1764": [ - "CRY-01" + "IV.1.29(3)": [ + "DCH-22.1" ], - "ISM-1765": [ - "CRY-01" + "IV.1.21": [ + "HRS-01" ], - "ISM-1766": [ - "CRY-01" + "IV.1.22": [ + "HRS-01" ], - "ISM-1767": [ - "CRY-01" + "IV.2.35-2(1)": [ + "IAC-09.6", + "PRI-05.3" ], - "ISM-1768": [ - "CRY-01" + "IV.1.22-2(2)": [ + "IRO-10" ], - "ISM-1769": [ - "CRY-01" + "IV.1.22-2(1)": [ + "IRO-10.2" ], - "ISM-1770": [ - "CRY-01" + "IV.5.53(1)": [ + "PRI-01" ], - "ISM-1771": [ - "CRY-01" + "IV.5.53(3)": [ + "PRI-01.3" ], - "ISM-1772": [ - "CRY-01" + "IV.1.24(1)": [ + "PRI-01.5" ], - "ISM-0231": [ - "CRY-03", - "END-14" + "IV.1.24(2)": [ + "PRI-01.5" ], - "ISM-0232": [ - "CRY-03" + "IV.1.24(3)": [ + "PRI-01.5" ], - "ISM-0241": [ - "CRY-03", - "HRS-05.2" + "IV.1.20": [ + "PRI-01.6" ], - "ISM-0465": [ - "CRY-03" + "IV.1.17(1)": [ + "PRI-01.11" ], - "ISM-0467": [ - "CRY-03" + "IV.1.26-2(1)": [ + "PRI-01.11" ], - "ISM-0469": [ - "CRY-03" + "IV.2.35-2(7)": [ + "PRI-01.11" ], - "ISM-0484": [ - "CRY-03" + "IV.2.35-2(8)": [ + "PRI-01.11" ], - "ISM-0547": [ - "CRY-03" + "IV.2.35-3(1)": [ + "PRI-01.11" ], - "ISM-1139": [ - "CRY-03" + "IV.3.36(1)": [ + "PRI-01.11" ], - "ISM-1369": [ - "CRY-03" + "IV.3.36(2)": [ + "PRI-01.11" ], - "ISM-1370": [ - "CRY-03" + "IV.3.36(3)": [ + "PRI-01.11" ], - "ISM-1372": [ - "CRY-03" + "IV.3.36(4)": [ + "PRI-01.11" ], - "ISM-1373": [ - "CRY-03" + "IV.3.36(5)": [ + "PRI-01.11" ], - "ISM-1374": [ - "CRY-03" + "IV.3.36(6)": [ + "PRI-01.11" ], - "ISM-1375": [ - "CRY-03" + "IV.3.37": [ + "PRI-01.11" ], - "ISM-1448": [ - "CRY-03" + "IV.3.38": [ + "PRI-01.11" ], - "ISM-1453": [ - "CRY-03" + "IV.3.39": [ + "PRI-01.11" ], - "ISM-1506": [ - "CRY-03" + "IV.5.54": [ + "PRI-01.11" ], - "ISM-1553": [ - "CRY-03" + "IV.1.18(1)": [ + "PRI-02" ], - "ISM-1589": [ - "CRY-03", - "NET-13" + "IV.1.18(2)": [ + "PRI-02" ], - "ISM-1781": [ - "CRY-03" + "IV.1.18(3)": [ + "PRI-02" ], - "ISM-0677": [ - "CRY-04" + "IV.1.23(2)": [ + "PRI-02" ], - "ISM-0459": [ - "CRY-05" + "IV.1.23(2)(i)": [ + "PRI-02" ], - "ISM-1314": [ - "CRY-07", - "NET-03.1", - "NET-15" + "IV.1.23(2)(ii)": [ + "PRI-02" ], - "ISM-1332": [ - "CRY-07" + "IV.1.23(2)(iii)": [ + "PRI-02" ], - "ISM-0485": [ - "CRY-08" + "IV.1.23(2)(iv)": [ + "PRI-02" ], - "ISM-1449": [ - "CRY-08" + "IV.1.23(2)(v)": [ + "PRI-02" ], - "ISM-0455": [ - "CRY-09", - "CRY-09.3" + "IV.1.23(2)(vi)": [ + "PRI-02" ], - "ISM-0507": [ - "CRY-09" + "IV.1.23(2)(vii)": [ + "PRI-02" ], - "ISM-0462": [ - "CRY-09.3" + "IV.1.23(2)(viii)": [ + "PRI-02" ], - "ISM-0337": [ - "DCH-01" + "IV.1.27(1)": [ + "PRI-02" ], - "ISM-0831": [ - "DCH-01", - "SAT-03.3" + "IV.1.27(1)(i)": [ + "PRI-02" ], - "ISM-1059": [ - "DCH-01", - "SAT-03.3" + "IV.1.27(1)(ii)": [ + "PRI-02" ], - "ISM-1549": [ - "DCH-01" + "IV.1.27(1)(iii)": [ + "PRI-02" ], - "ISM-1599": [ - "DCH-01", - "PES-16" + "IV.1.27(1)(iv)": [ + "PRI-02" ], - "ISM-1802": [ - "DCH-01.2" + "IV.1.15(1)": [ + "PRI-02.1" ], - "ISM-0270": [ - "DCH-02", - "DCH-04", - "NET-13" + "IV.1.26-2(1)(i)": [ + "PRI-03" ], - "ISM-0271": [ - "DCH-02", - "DCH-04.1", - "NET-13" + "IV.1.26-2(1)(ii)": [ + "PRI-03" ], - "ISM-0272": [ - "DCH-02", - "DCH-04", - "NET-13" + "IV.1.30(5)": [ + "PRI-03.1" ], - "ISM-0294": [ - "DCH-02", - "DCH-04" + "IV.1.16(2)": [ + "PRI-03.2" ], - "ISM-0296": [ - "DCH-02", - "DCH-04" + "IV.1.23(1)": [ + "PRI-03.3" ], - "ISM-0323": [ - "DCH-02", - "DCH-02.1" + "IV.1.30(1)": [ + "PRI-03.4" ], - "ISM-0325": [ - "DCH-02.1", - "DCH-05.9", - "DCH-11" + "IV.1.30(2)": [ + "PRI-03.9" ], - "ISM-0201": [ - "DCH-04", - "PES-12.1" + "IV.1.30(4)": [ + "PRI-03.9" ], - "ISM-0332": [ - "DCH-04" + "IV.1.30(6)": [ + "PRI-03.9" ], - "ISM-0356": [ - "DCH-04", - "DCH-09" + "IV.1.30(7)": [ + "PRI-03.9" ], - "ISM-0358": [ - "DCH-04", - "DCH-09" + "IV.1.31": [ + "PRI-03.9" ], - "ISM-0360": [ - "DCH-04", - "DCH-09" + "IV.1.23(3)": [ + "PRI-03.11" ], - "ISM-0368": [ - "DCH-08" + "IV.1.23(6)": [ + "PRI-03.11" ], - "ISM-0374": [ - "DCH-08" + "IV.1.30(3)": [ + "PRI-03.11" ], - "ISM-0375": [ - "DCH-08" + "IV.1.15(2)": [ + "PRI-04" ], - "ISM-0840": [ - "DCH-08" + "IV.2.35-2(5)": [ + "PRI-05" ], - "ISM-1160": [ - "DCH-08" + "IV.1.19": [ + "PRI-05.2" ], - "ISM-1361": [ - "DCH-08" + "IV.1.16(1)": [ + "PRI-05.4" ], - "ISM-1517": [ - "DCH-08" + "IV.1.17(2)": [ + "PRI-05.4" ], - "ISM-0313": [ - "DCH-09" + "IV.1.17(2)(i)": [ + "PRI-05.4" ], - "ISM-0317": [ - "DCH-09" + "IV.1.17(2)(ii)": [ + "PRI-05.4" ], - "ISM-0348": [ - "DCH-09" + "IV.1.17(2)(iii)": [ + "PRI-05.4" ], - "ISM-0351": [ - "DCH-09" + "IV.1.17(2)(iv)": [ + "PRI-05.4" ], - "ISM-0352": [ - "DCH-09" + "IV.1.17(2)(v)": [ + "PRI-05.4" ], - "ISM-0354": [ - "DCH-09" + "IV.1.17(2)(vi)": [ + "PRI-05.4" ], - "ISM-0357": [ - "DCH-09" + "IV.1.23(1)(i)": [ + "PRI-05.4" ], - "ISM-0359": [ - "DCH-09" + "IV.1.23(1)(ii)": [ + "PRI-05.4" ], - "ISM-0361": [ - "DCH-09" + "IV.1.23(1)(iii)": [ + "PRI-05.4" ], - "ISM-0362": [ - "DCH-09" + "IV.1.23(1)(iv)": [ + "PRI-05.4" ], - "ISM-0835": [ - "DCH-09" + "IV.1.28(1)": [ + "PRI-06" ], - "ISM-0836": [ - "DCH-09" + "IV.1.29(1)": [ + "PRI-06.1" ], - "ISM-0947": [ - "DCH-09", - "DCH-17" + "IV.1.29(2)": [ + "PRI-06.1" ], - "ISM-1065": [ - "DCH-09" + "IV.1.27(2)": [ + "PRI-06.4" ], - "ISM-1067": [ - "DCH-09" + "IV.1.27(2)(i)": [ + "PRI-06.4" ], - "ISM-1287": [ - "DCH-09", - "NET-02.3", - "NET-03", - "NET-18" + "IV.1.27(2)(ii)": [ + "PRI-06.4" ], - "ISM-1600": [ - "DCH-09", - "DCH-09.4" + "IV.1.27(3)": [ + "PRI-06.4" ], - "ISM-1735": [ - "DCH-09" + "IV.1.28(2)": [ + "PRI-06.4" ], - "ISM-0316": [ - "DCH-09.1" + "IV.1.28(3)": [ + "PRI-06.4" ], - "ISM-0371": [ - "DCH-09.1" + "IV.1.35(1)": [ + "PRI-06.4" ], - "ISM-0373": [ - "DCH-09.1" + "IV.1.35(2)": [ + "PRI-06.4" ], - "ISM-1642": [ - "DCH-09.4" + "IV.1.28(2)(i)": [ + "PRI-07.5" ], - "ISM-1359": [ - "DCH-12" + "IV.1.28(2)(ii)": [ + "PRI-07.5" ], - "ISM-1713": [ - "DCH-12" + "IV.1.28(2)(iii)": [ + "PRI-07.5" ], - "ISM-0657": [ - "DCH-14" + "IV.1.25(1)": [ + "PRI-14.1" ], - "ISM-0661": [ - "DCH-14" + "IV.1.25(2)": [ + "PRI-14.1" ], - "ISM-0663": [ - "DCH-14" + "IV.1.26(3)": [ + "PRI-14.1" ], - "ISM-0664": [ - "DCH-14" + "IV.1.26(4)": [ + "PRI-14.1" ], - "ISM-0665": [ - "DCH-14", - "NET-01.1" + "IV.1.32(1)": [ + "PRI-18" ], - "ISM-0669": [ - "DCH-14" + "IV.1.32(2)": [ + "PRI-18" ], - "ISM-0675": [ - "DCH-14" + "IV.1.32(3)": [ + "PRI-18" ], - "ISM-1187": [ - "DCH-14" + "IV.1.32(4)": [ + "PRI-18" ], - "ISM-1535": [ - "DCH-14" + "IV.5.53(4)": [ + "TPM-09" + ] + }, + "apac-jpn-ismap": { + "5": [ + "GOV-02" ], - "ISM-0347": [ - "DCH-17" + "6": [ + "GOV-02" ], - "ISM-1778": [ - "DCH-17", - "NET-08.4" + "7": [ + "HRS-01" ], - "ISM-1779": [ - "DCH-17", - "NET-08.4" + "8": [ + "AST-01" ], - "ISM-1284": [ - "END-04", - "END-04.4", - "NET-03" + "9": [ + "IAC-01" ], - "ISM-1286": [ - "END-04", - "END-04.4", - "NET-03" + "10": [ + "CRY-01" ], - "ISM-1288": [ - "END-04", - "END-04.4", - "NET-03" + "11": [ + "PES-01" ], - "ISM-1289": [ - "END-04", - "END-04.4", - "NET-03" + "12": [ + "OPS-01" ], - "ISM-1290": [ - "END-04" + "13": [ + "NET-01" ], - "ISM-1293": [ - "END-04", - "END-04.4", - "NET-03", - "NET-18" + "14": [ + "TDA-01" ], - "ISM-1417": [ - "END-04", - "END-04.4" + "15": [ + "TPM-01" ], - "ISM-1782": [ - "END-04.4", - "NET-10" + "16": [ + "IRO-01" ], - "ISM-1416": [ - "END-05" + "17": [ + "BCD-01" ], - "ISM-1034": [ - "END-07" + "18": [ + "CPL-01" ], - "ISM-1341": [ - "END-07" + "4.4.1.1": [ + "GOV-01", + "GOV-01.1" ], - "ISM-0434": [ - "HRS-04" + "4.4.1.2": [ + "GOV-01", + "GOV-04" ], - "ISM-0446": [ - "HRS-04.1", - "HRS-04.3", - "IAC-16" + "4.4.2.1": [ + "GOV-01", + "CPL-01" ], - "ISM-0447": [ - "HRS-04.1", - "HRS-04.3", - "IAC-16" + "4.5.4.1": [ + "GOV-01" ], - "ISM-0435": [ - "HRS-04.2" + "4.5.4.2": [ + "GOV-01" ], - "ISM-0409": [ - "HRS-04.3" + "4.8.1.1": [ + "GOV-01", + "RSK-01" ], - "ISM-0411": [ - "HRS-04.3" + "4.8.2.2": [ + "GOV-01" ], - "ISM-0420": [ - "HRS-04.3", - "HRS-04.4" + "5.1": [ + "GOV-01" ], - "ISM-1773": [ - "HRS-04.3" + "5.1.1": [ + "GOV-01", + "GOV-02", + "GOV-03", + "PRI-01", + "PRI-01.3" ], - "ISM-0258": [ - "HRS-05" + "6.1": [ + "GOV-01" ], - "ISM-0820": [ - "HRS-05.1" + "4.4.1.3": [ + "GOV-01.1" ], - "ISM-0821": [ - "HRS-05.1" + "4.4.5.3": [ + "GOV-01.1", + "GOV-02" ], - "ISM-0229": [ - "HRS-05.2", - "HRS-05.5" + "4.5.3.1": [ + "GOV-01.1", + "GOV-03", + "GOV-17", + "SAT-03", + "TPM-01" ], - "ISM-0230": [ - "HRS-05.2", - "HRS-05.5" + "4.6.3.1": [ + "GOV-01.1" ], - "ISM-0235": [ - "HRS-05.2" + "4.6.3.2": [ + "GOV-01.1" ], - "ISM-0236": [ - "HRS-05.2" + "4.6.3.3": [ + "GOV-01.1", + "GOV-01.3" ], - "ISM-0240": [ - "HRS-05.2", - "HRS-05.5" + "4.6.1.1": [ + "GOV-01.2", + "GOV-01.3", + "CPL-01.1", + "CPL-02", + "RSK-04", + "RSK-06" ], - "ISM-0264": [ - "HRS-05.2", - "NET-13" + "4.6.1.2": [ + "GOV-01.3" ], - "ISM-0267": [ - "HRS-05.2", - "NET-13", - "NET-18" + "4.4.5.1": [ + "GOV-02" ], - "ISM-0588": [ - "HRS-05.2" + "4.5.2.1": [ + "GOV-02", + "GOV-14", + "GOV-15" ], - "ISM-0931": [ - "HRS-05.2" + "4.8.2.1": [ + "GOV-02", + "GOV-03" ], - "ISM-1075": [ - "HRS-05.2" + "5.1.1.1": [ + "GOV-02" ], - "ISM-1078": [ - "HRS-05.2" + "5.1.1.8": [ + "GOV-02" ], - "ISM-1092": [ - "HRS-05.2" + "5.1.1.21": [ + "GOV-02" ], - "ISM-1196": [ - "HRS-05.2", - "HRS-05.5" + "6.2.1": [ + "GOV-02", + "END-02" ], - "ISM-1198": [ - "HRS-05.2", - "HRS-05.5" + "5.1.1.7": [ + "GOV-02.1" ], - "ISM-1644": [ - "HRS-05.2", - "PES-12" + "4.7.1.5": [ + "GOV-03" ], - "ISM-0701": [ - "HRS-05.5" + "5.1.2": [ + "GOV-03" ], - "ISM-0866": [ - "HRS-05.5" + "5.1.2.2": [ + "GOV-03" ], - "ISM-0870": [ - "HRS-05.5" + "5.1.2.3": [ + "GOV-03" ], - "ISM-0871": [ - "HRS-05.5" + "5.1.2.4": [ + "GOV-03" ], - "ISM-0874": [ - "HRS-05.5", - "MDM-01" + "5.1.1.6": [ + "GOV-04" ], - "ISM-1082": [ - "HRS-05.5" + "5.1.2.1": [ + "GOV-04" ], - "ISM-1083": [ - "HRS-05.5" + "4.6.2.1": [ + "GOV-05" ], - "ISM-1084": [ - "HRS-05.5" + "6.1.3": [ + "GOV-06" ], - "ISM-1145": [ - "HRS-05.5" + "6.1.3.1": [ + "GOV-06" ], - "ISM-1366": [ - "HRS-05.5", - "MDM-01" + "6.1.3.3.PB": [ + "GOV-06" ], - "ISM-0430": [ - "HRS-08", - "HRS-09", - "IAC-07", - "IAC-07.1", - "IAC-07.2" + "6.1.4": [ + "GOV-07" ], - "ISM-1546": [ - "IAC-01", - "IAC-02" + "6.1.4.1": [ + "GOV-07" ], - "ISM-0414": [ - "IAC-02" + "6.1.4.2": [ + "GOV-07" ], - "ISM-0415": [ - "IAC-02", - "IAC-02.1" + "6.1.4.3": [ + "GOV-07", + "THR-03" ], - "ISM-1619": [ - "IAC-02.1" + "6.1.4.4": [ + "GOV-07" ], - "ISM-1055": [ - "IAC-02.2" + "6.1.4.5": [ + "GOV-07" ], - "ISM-1603": [ - "IAC-02.2", - "IAC-04" + "6.1.4.6": [ + "GOV-07" ], - "ISM-1583": [ - "IAC-03" + "4.4.4.1": [ + "GOV-09", + "GOV-15", + "GOV-15.1", + "AST-04.1", + "CPL-01.2" ], - "ISM-0974": [ - "IAC-06" + "5.1.1.5": [ + "GOV-09" ], - "ISM-1173": [ - "IAC-06" + "7.2.1.8": [ + "GOV-14" ], - "ISM-1401": [ - "IAC-06" + "18.1.2": [ + "AAT-12", + "AST-02.7" ], - "ISM-1504": [ - "IAC-06" + "18.1.2.13.PB": [ + "AAT-12", + "CPL-07" ], - "ISM-1505": [ - "IAC-06" + "8.1": [ + "AST-01" ], - "ISM-1559": [ - "IAC-06" + "8.1.1.1": [ + "AST-01" ], - "ISM-1560": [ - "IAC-06" + "8.1.1.6.PB": [ + "AST-01" ], - "ISM-1561": [ - "IAC-06" + "8.1.1": [ + "AST-02" ], - "ISM-1679": [ - "IAC-06" + "8.1.1.2": [ + "AST-02" ], - "ISM-1680": [ - "IAC-06" + "8.1.1.3": [ + "AST-02" ], - "ISM-1681": [ - "IAC-06" + "8.1.1.4": [ + "AST-02" ], - "ISM-1682": [ - "IAC-06" + "8.1.2.3": [ + "AST-02" ], - "ISM-1683": [ - "IAC-06" + "14.2.7.1": [ + "AST-02.7", + "TPM-05" ], - "ISM-1685": [ - "IAC-06" + "18.1.2.1": [ + "AST-02.7" ], - "ISM-1746": [ - "IAC-08" + "18.1.2.2": [ + "AST-02.7" ], - "ISM-1227": [ - "IAC-10" + "18.1.2.3": [ + "AST-02.7" ], - "ISM-1593": [ - "IAC-10" + "18.1.2.4": [ + "AST-02.7" ], - "ISM-1594": [ - "IAC-10" + "18.1.2.5": [ + "AST-02.7" ], - "ISM-1595": [ - "IAC-10" + "18.1.2.6": [ + "AST-02.7" ], - "ISM-0417": [ - "IAC-10.1" + "18.1.2.7": [ + "AST-02.7" ], - "ISM-0421": [ - "IAC-10.1", - "IAC-18" + "18.1.2.8": [ + "AST-02.7" ], - "ISM-0422": [ - "IAC-10.1", - "IAC-18" + "18.1.2.9": [ + "AST-02.7" ], - "ISM-1557": [ - "IAC-10.1" + "18.1.2.10": [ + "AST-02.7" ], - "ISM-1558": [ - "IAC-10.1" + "18.1.2.11": [ + "AST-02.7" ], - "ISM-1596": [ - "IAC-10.1" + "18.1.2.12": [ + "AST-02.7" ], - "ISM-1795": [ - "IAC-10.1" + "8.1.1.5": [ + "AST-03" ], - "ISM-0418": [ - "IAC-10.5" + "8.1.2": [ + "AST-03" ], - "ISM-1402": [ - "IAC-10.5" + "8.1.2.1": [ + "AST-03" ], - "ISM-1590": [ - "IAC-10.5" + "8.1.2.2": [ + "AST-03" ], - "ISM-1597": [ - "IAC-10.5" + "4.4.4": [ + "AST-04", + "AST-04.1", + "CPL-01.2", + "IAO-03" ], - "ISM-1686": [ - "IAC-10.5" + "8.1.2.4": [ + "AST-04.1" ], - "ISM-1304": [ - "IAC-10.8" + "8.3": [ + "AST-05" + ], + "8.3.1": [ + "AST-05" ], - "ISM-1806": [ - "IAC-10.8" + "8.3.1.2": [ + "AST-05.1" ], - "ISM-0441": [ - "IAC-15", - "IAC-21" + "13.2.2.1": [ + "AST-05.1" ], - "ISM-0443": [ - "IAC-15" + "6.2.1.18": [ + "AST-06" ], - "ISM-1649": [ - "IAC-15.1", - "IAC-16" + "6.2.1.19": [ + "AST-06" ], - "ISM-1404": [ - "IAC-15.3" + "8.2.3.5": [ + "AST-06" ], - "ISM-1648": [ - "IAC-15.3", - "IAC-16", - "IAC-17" + "11.2.8": [ + "AST-06" ], - "ISM-1591": [ - "IAC-15.6", - "NET-14.8" + "11.2.8.1": [ + "AST-06" ], - "ISM-1610": [ - "IAC-15.9" + "11.2.8.2": [ + "AST-06" ], - "ISM-1611": [ - "IAC-15.9" + "11.2.8.3": [ + "AST-06" ], - "ISM-1612": [ - "IAC-15.9" + "11.2.8.4": [ + "AST-06" ], - "ISM-1613": [ - "IAC-15.9" + "8.1.2.6": [ + "AST-09" ], - "ISM-1614": [ - "IAC-15.9" + "8.3.1.1": [ + "AST-09" ], - "ISM-1615": [ - "IAC-15.9" + "8.3.2": [ + "AST-09" ], - "ISM-0445": [ - "IAC-16", - "IAC-16.4" + "8.3.2.1": [ + "AST-09" ], - "ISM-1175": [ - "IAC-16", - "IAC-21.2" + "8.3.2.2": [ + "AST-09" ], - "ISM-1507": [ - "IAC-16" + "8.3.2.3": [ + "AST-09" ], - "ISM-1508": [ - "IAC-16" + "11.2.7": [ + "AST-09" ], - "ISM-1509": [ - "IAC-16" + "11.2.7.1": [ + "AST-09" ], - "ISM-1620": [ - "IAC-16" + "11.2.7.2": [ + "AST-09" ], - "ISM-1687": [ - "IAC-16", - "SEA-22" + "8.1.4": [ + "AST-10" ], - "ISM-1688": [ - "IAC-16" + "5.1.1.13": [ + "BCD-01" ], - "ISM-1689": [ - "IAC-16" + "17.1": [ + "BCD-01" ], - "ISM-1647": [ - "IAC-17" + "17.1.1": [ + "BCD-01" ], - "ISM-1716": [ - "IAC-17" + "17.1.1.1": [ + "BCD-01" ], - "ISM-0611": [ - "IAC-21", - "NET-03" + "17.1.1.2": [ + "BCD-01" ], - "ISM-1705": [ - "IAC-21" + "17.1.1.3": [ + "BCD-01" ], - "ISM-1706": [ - "IAC-21" + "17.1.1.4": [ + "BCD-01" ], - "ISM-1707": [ - "IAC-21" + "17.1.3": [ + "BCD-01" ], - "ISM-1708": [ - "IAC-21" + "17.1.3.1": [ + "BCD-01" ], - "ISM-1403": [ - "IAC-22" + "17.1.3.4": [ + "BCD-01" ], - "ISM-0428": [ - "IAC-24" + "12.2.1.10": [ + "BCD-01.7" ], - "ISM-0853": [ - "IAC-25" + "12.2.1.11": [ + "BCD-01.7" ], - "ISM-0137": [ - "IRO-01", - "IRO-08", - "IRO-09", - "IRO-10" + "17.1.2": [ + "BCD-01.7" ], - "ISM-0576": [ - "IRO-01", - "IRO-04" + "17.1.2.1": [ + "BCD-01.7" ], - "ISM-1609": [ - "IRO-01", - "IRO-08", - "IRO-09", - "IRO-10" + "17.1.2.2": [ + "BCD-01.7" ], - "ISM-1618": [ - "IRO-01", - "IRO-02", - "IRO-07" + "17.1.2.3": [ + "BCD-01.7" ], - "ISM-0123": [ - "IRO-02", - "IRO-10" + "17.1.2.4": [ + "BCD-01.7" ], - "ISM-0141": [ - "IRO-02" + "17.1.2.5": [ + "BCD-01.7" ], - "ISM-0917": [ - "IRO-02", - "IRO-04" + "17.1.2.6": [ + "BCD-01.7" ], - "ISM-1803": [ - "IRO-02", - "IRO-09" + "17.1.3.2": [ + "BCD-04" ], - "ISM-1626": [ - "IRO-02.2", - "THR-04", - "THR-05" + "17.1.3.3": [ + "BCD-04" ], - "ISM-0043": [ - "IRO-04" + "17.2": [ + "BCD-09" ], - "ISM-0133": [ - "IRO-04.1", - "IRO-12", - "IRO-12.3", - "IRO-12.4" + "17.2.1": [ + "BCD-09" ], - "ISM-0138": [ - "IRO-08" + "17.2.1.1": [ + "BCD-09" ], - "ISM-1731": [ - "IRO-08" + "17.2.1.2": [ + "BCD-09" ], - "ISM-1732": [ - "IRO-08" + "17.2.1.3": [ + "BCD-09" ], - "ISM-0125": [ - "IRO-09" + "12.3": [ + "BCD-11" ], - "ISM-1569": [ - "IRO-10.4", - "TPM-04", - "TPM-05", - "TPM-06" + "12.3.1": [ + "BCD-11" ], - "ISM-0140": [ - "IRO-14" + "12.3.1.1": [ + "BCD-11" ], - "ISM-0651": [ - "IRO-15" + "12.3.1.2": [ + "BCD-11" ], - "ISM-0652": [ - "IRO-15" + "12.3.1.3": [ + "BCD-11" ], - "ISM-1389": [ - "IRO-15", - "NET-03" + "12.3.1.4": [ + "BCD-11" ], - "ISM-0280": [ - "IAO-01" + "12.3.1.5": [ + "BCD-11" ], - "ISM-1525": [ - "IAO-01", - "IAO-07" + "12.3.1.11": [ + "BCD-11" ], - "ISM-1137": [ - "IAO-02.2" + "12.3.1.12": [ + "BCD-11" ], - "ISM-1570": [ - "IAO-02.2" + "12.3.1.13": [ + "BCD-11" ], - "ISM-1563": [ - "IAO-02.4" + "12.3.1.14": [ + "BCD-11" ], - "ISM-0041": [ - "IAO-03" + "12.3.1.16.P": [ + "BCD-11" ], - "ISM-0432": [ - "IAO-03" + "12.3.1.17.P": [ + "BCD-11" ], - "ISM-0072": [ - "IAO-03.2", - "TPM-05" + "12.3.1.18.P": [ + "BCD-11" ], - "ISM-1451": [ - "IAO-03.2", - "TPM-05" + "12.3.1.21.P": [ + "BCD-11" ], - "ISM-1571": [ - "IAO-03.2", - "TPM-05" + "12.3.1.24.P": [ + "BCD-11" ], - "ISM-1573": [ - "IAO-03.2", - "TPM-04.1", - "TPM-05" + "8.3.1.7": [ + "BCD-11.2" ], - "ISM-1574": [ - "IAO-03.2", - "TPM-05" + "12.3.1.6": [ + "BCD-11.2" ], - "ISM-1575": [ - "IAO-03.2", - "TPM-05" + "12.3.1.7": [ + "BCD-11.2" ], - "ISM-1564": [ - "IAO-05" + "12.3.1.23.P": [ + "BCD-11.2" ], - "ISM-0305": [ - "MNT-01", - "MNT-06", - "MNT-08" + "12.3.1.8": [ + "BCD-11.5" ], - "ISM-1226": [ - "MNT-01" + "12.3.1.9": [ + "BCD-11.5" ], - "ISM-1079": [ - "MNT-02" + "12.3.1.10": [ + "BCD-11.5" ], - "ISM-0307": [ - "MNT-06" + "12.3.1.20.P": [ + "BCD-11.5" ], - "ISM-0306": [ - "MNT-06.1" + "12.3.1.22.P": [ + "BCD-11.5" ], - "ISM-0310": [ - "MNT-09" + "12.1.3": [ + "CAP-01" ], - "ISM-1598": [ - "MNT-10" + "12.1.3.1": [ + "CAP-01" ], - "ISM-0682": [ - "MDM-01" + "12.1.3.2": [ + "CAP-01" ], - "ISM-0687": [ - "MDM-01" + "12.1.3.3": [ + "CAP-01" ], - "ISM-0863": [ - "MDM-01" + "12.1.3.4": [ + "CAP-01" ], - "ISM-0864": [ - "MDM-01" + "12.1.3.5": [ + "CAP-01" ], - "ISM-1085": [ - "MDM-01" + "12.1.3.6": [ + "CAP-01" ], - "ISM-1195": [ - "MDM-01" + "12.1.3.7": [ + "CAP-01" ], - "ISM-1533": [ - "MDM-01" + "12.1.3.8": [ + "CAP-01" ], - "ISM-0869": [ - "MDM-03" + "4.5.4.4": [ + "CHG-01" ], - "ISM-0702": [ - "MDM-05" + "12.1.2": [ + "CHG-01" ], - "ISM-0694": [ - "MDM-06" + "12.1.2.1": [ + "CHG-01" ], - "ISM-1400": [ - "MDM-06" + "12.1.2.11.PB": [ + "CHG-01" ], - "ISM-1482": [ - "MDM-06" + "12.1.2.2": [ + "CHG-02" ], - "ISM-0521": [ - "NET-01" + "12.1.2.3": [ + "CHG-02" ], - "ISM-0629": [ - "NET-01", - "NET-03" + "12.1.2.4": [ + "CHG-02" ], - "ISM-1186": [ - "NET-01" + "12.1.2.5": [ + "CHG-02" ], - "ISM-1428": [ - "NET-01" + "12.1.2.6": [ + "CHG-02" ], - "ISM-1429": [ - "NET-01" + "12.1.2.7": [ + "CHG-02" ], - "ISM-1430": [ - "NET-01" + "12.1.2.8": [ + "CHG-02" ], - "ISM-1711": [ - "NET-01" + "12.1.2.9": [ + "CHG-02" ], - "ISM-1712": [ - "NET-01" + "12.1.2.13": [ + "CHG-02" ], - "ISM-1774": [ - "NET-01" + "12.1.2.14": [ + "CHG-02" ], - "ISM-1783": [ - "NET-01" + "12.5.1.4": [ + "CHG-02" ], - "ISM-1019": [ - "NET-02.1" + "12.5.1.6": [ + "CHG-02" ], - "ISM-1431": [ - "NET-02.1" + "12.5.1.7": [ + "CHG-02" ], - "ISM-1436": [ - "NET-02.1" + "12.5.1.8": [ + "CHG-02" ], - "ISM-1805": [ - "NET-02.1" + "12.5.1.10": [ + "CHG-02" ], - "ISM-0536": [ - "NET-02.2", - "NET-15" + "12.5.1.11": [ + "CHG-02" ], - "ISM-0597": [ - "NET-02.3" + "12.5.1.12": [ + "CHG-02" ], - "ISM-0610": [ - "NET-02.3" + "12.5.1.13": [ + "CHG-02" ], - "ISM-0626": [ - "NET-02.3" + "12.5.1.14": [ + "CHG-02" ], - "ISM-0635": [ - "NET-02.3" + "12.5.1.15": [ + "CHG-02" ], - "ISM-0670": [ - "NET-02.3" + "12.5.1.16": [ + "CHG-02" ], - "ISM-1521": [ - "NET-02.3", - "NET-03" + "12.5.1.17": [ + "CHG-02" ], - "ISM-1522": [ - "NET-02.3", - "NET-03" + "12.5.1.18": [ + "CHG-02" ], - "ISM-1523": [ - "NET-02.3" + "14.2.2": [ + "CHG-02" ], - "ISM-0612": [ - "NET-03" + "14.2.2.1": [ + "CHG-02" ], - "ISM-0613": [ - "NET-03" + "14.2.2.2": [ + "CHG-02" ], - "ISM-0616": [ - "NET-03" + "14.2.2.3": [ + "CHG-02" ], - "ISM-0619": [ - "NET-03" + "14.2.2.4": [ + "CHG-02" ], - "ISM-0622": [ - "NET-03" + "14.2.2.5": [ + "CHG-02" ], - "ISM-0628": [ - "NET-03" + "14.2.2.6": [ + "CHG-02" ], - "ISM-0631": [ - "NET-03" + "14.2.2.7": [ + "CHG-02" ], - "ISM-0634": [ - "NET-03" + "14.2.2.8": [ + "CHG-02" ], - "ISM-0637": [ - "NET-03", - "NET-08.1" + "14.2.2.9": [ + "CHG-02" ], - "ISM-0639": [ - "NET-03" + "14.2.2.10": [ + "CHG-02" ], - "ISM-1037": [ - "NET-03" + "14.2.2.11": [ + "CHG-02" ], - "ISM-1192": [ - "NET-03" + "14.2.2.12": [ + "CHG-02" ], - "ISM-1427": [ - "NET-03" + "14.2.2.13": [ + "CHG-02" ], - "ISM-1520": [ - "NET-03" + "14.2.2.14": [ + "CHG-02" ], - "ISM-1528": [ - "NET-03" + "14.2.2.15": [ + "CHG-02" ], - "ISM-0546": [ - "NET-03.2" + "14.2.2.16": [ + "CHG-02" ], - "ISM-0643": [ - "NET-04" + "14.2.2.17": [ + "CHG-02" ], - "ISM-0645": [ - "NET-04" + "14.2.4.7": [ + "CHG-02" ], - "ISM-1157": [ - "NET-04" + "14.2.4.8": [ + "CHG-02" ], - "ISM-1158": [ - "NET-04" + "14.2.4.9": [ + "CHG-02" ], - "ISM-1386": [ - "NET-04" + "14.2.4.10": [ + "CHG-02" ], - "ISM-1181": [ - "NET-06" + "14.2.4": [ + "CHG-02.1" ], - "ISM-1577": [ - "NET-06" + "14.2.4.1": [ + "CHG-02.1" ], - "ISM-0529": [ - "NET-06.2" + "14.2.4.2": [ + "CHG-02.1" ], - "ISM-0530": [ - "NET-06.2" + "14.2.4.3": [ + "CHG-02.1" ], - "ISM-0535": [ - "NET-06.2" + "14.2.4.4": [ + "CHG-02.1" ], - "ISM-1364": [ - "NET-06.2" + "14.2.4.5": [ + "CHG-02.1" ], - "ISM-1532": [ - "NET-06.2" + "14.2.4.6": [ + "CHG-02.1" ], - "ISM-1028": [ - "NET-08" + "12.1.2.10": [ + "CHG-02.2" ], - "ISM-1030": [ - "NET-08" + "12.5.1.5": [ + "CHG-02.2" ], - "ISM-1627": [ - "NET-08" + "12.5.1.9": [ + "CHG-02.2" ], - "ISM-1628": [ - "NET-08" + "14.2.3": [ + "CHG-02.2" ], - "ISM-0574": [ - "NET-10", - "NET-10.3", - "NET-13" + "14.2.3.1": [ + "CHG-02.2" ], - "ISM-0861": [ - "NET-10", - "NET-13" + "14.2.3.2": [ + "CHG-02.2" ], - "ISM-1026": [ - "NET-10", - "NET-13" + "14.2.3.3": [ + "CHG-02.2" ], - "ISM-1027": [ - "NET-10", - "NET-13" + "5.1.1.22.P": [ + "CLD-01" ], - "ISM-1151": [ - "NET-10", - "NET-10.3", - "NET-13" + "5.1.1.23.P": [ + "CLD-01" ], - "ISM-1183": [ - "NET-10", - "NET-10.3", - "NET-13" + "5.1.1.24.P": [ + "CLD-01" ], - "ISM-1540": [ - "NET-10", - "NET-13", - "NET-20.4" + "5.1.1.25.P": [ + "CLD-01" ], - "ISM-1799": [ - "NET-10", - "NET-10.3" + "5.1.1.26.P": [ + "CLD-01" ], - "ISM-1432": [ - "NET-10.4" + "5.1.1.27.P": [ + "CLD-01" ], - "ISM-0269": [ - "NET-13" + "5.1.1.28.P": [ + "CLD-01" ], - "ISM-0490": [ - "NET-13" + "5.1.1.29.P": [ + "CLD-01" ], - "ISM-0494": [ - "NET-13" + "5.1.1.30.P": [ + "CLD-01" ], - "ISM-0496": [ - "NET-13" + "8.1.5.P": [ + "CLD-01.2" ], - "ISM-0498": [ - "NET-13" + "8.1.5.1.P": [ + "CLD-01.2" ], - "ISM-0565": [ - "NET-13" + "8.1.5.2.P": [ + "CLD-01.2" ], - "ISM-0569": [ - "NET-13" + "8.1.5.3.P": [ + "CLD-01.2" ], - "ISM-0570": [ - "NET-13", - "NET-18.1" + "8.1.5.4.P": [ + "CLD-01.2" ], - "ISM-0571": [ - "NET-13" + "8.1.2.7.PB": [ + "CLD-02" ], - "ISM-0572": [ - "NET-13" + "9.2.3.11.PB": [ + "CLD-02" ], - "ISM-0998": [ - "NET-13" + "9.5.1.P": [ + "CLD-06" ], - "ISM-1000": [ - "NET-13" + "9.5.1.1.P": [ + "CLD-06" ], - "ISM-1023": [ - "NET-13" + "9.5.1.2.P": [ + "CLD-06" ], - "ISM-1024": [ - "NET-13" + "9.5.1.3.P": [ + "CLD-06" ], - "ISM-1089": [ - "NET-13" + "9.5.1.4.P": [ + "CLD-06" ], - "ISM-0487": [ - "NET-14" + "6.3.1.1.PB": [ + "CLD-06.1" ], - "ISM-0488": [ - "NET-14" + "5.1.1.3": [ + "CPL-01" ], - "ISM-0489": [ - "NET-14" + "18.1": [ + "CPL-01" ], - "ISM-0225": [ - "NET-15" + "18.1.1": [ + "CPL-01" ], - "ISM-0248": [ - "NET-15" + "18.1.1.1": [ + "CPL-01" ], - "ISM-1315": [ - "NET-15" + "18.1.1.2": [ + "CPL-01" ], - "ISM-1317": [ - "NET-15" + "18.1.1.3": [ + "CPL-01" ], - "ISM-1320": [ - "NET-15" + "18.1.1.4.P": [ + "CPL-01" ], - "ISM-1322": [ - "NET-15" + "18.1.1.5.P": [ + "CPL-01" ], - "ISM-1323": [ - "NET-15" + "18.1.1.6.P": [ + "CPL-01" ], - "ISM-1324": [ - "NET-15" + "18.1.1.7.P": [ + "CPL-01" ], - "ISM-1327": [ - "NET-15" + "18.1.5.7.PB": [ + "CPL-01" ], - "ISM-1330": [ - "NET-15" + "4.7.1.1": [ + "CPL-01.1", + "RSK-06", + "RSK-06.4" ], - "ISM-1334": [ - "NET-15" + "4.7.1.2": [ + "CPL-01.1" ], - "ISM-1335": [ - "NET-15" + "4.5.4.3": [ + "CPL-01.3", + "CPL-01.4" ], - "ISM-1454": [ - "NET-15" + "18.2.1.11.P": [ + "CPL-01.3" ], - "ISM-1543": [ - "NET-15" + "18.2.1.12.P": [ + "CPL-01.3" ], - "ISM-1013": [ - "NET-15.4" + "4.6.2.2": [ + "CPL-01.4", + "CPL-02", + "CPL-02.1" ], - "ISM-1338": [ - "NET-15.4" + "4.6.2.6": [ + "CPL-02" ], - "ISM-0829": [ - "NET-15.5" + "12.7": [ + "CPL-02" ], - "ISM-0649": [ - "NET-18" + "12.7.1.8": [ + "CPL-02" ], - "ISM-0659": [ - "NET-18" + "12.7.1.9": [ + "CPL-02" ], - "ISM-0958": [ - "NET-18" + "4.6.2.4": [ + "CPL-02.1" ], - "ISM-0961": [ - "NET-18" + "4.6.2.3": [ + "CPL-03" ], - "ISM-0963": [ - "NET-18" + "4.6.2.5": [ + "CPL-03", + "CPL-03.1" ], - "ISM-1171": [ - "NET-18" + "12.7.1": [ + "CPL-03" ], - "ISM-1234": [ - "NET-18" + "12.7.1.1": [ + "CPL-03" ], - "ISM-1236": [ - "NET-18" + "12.7.1.2": [ + "CPL-03" ], - "ISM-1237": [ - "NET-18", - "NET-18.1" + "12.7.1.3": [ + "CPL-03" ], - "ISM-1502": [ - "NET-18" + "12.7.1.4": [ + "CPL-03" ], - "ISM-1524": [ - "NET-18" + "12.7.1.5": [ + "CPL-03" ], - "ISM-0260": [ - "NET-18.1" + "12.7.1.6": [ + "CPL-03" ], - "ISM-0263": [ - "NET-18.2" + "12.7.1.7": [ + "CPL-03" ], - "ISM-0810": [ - "PES-01" + "18.2": [ + "CPL-03" ], - "ISM-1296": [ - "PES-03" + "18.2.2": [ + "CPL-03" ], - "ISM-0813": [ - "PES-03.4" + "18.2.2.1": [ + "CPL-03" ], - "ISM-1053": [ - "PES-03.4" + "18.2.2.2": [ + "CPL-03" ], - "ISM-1074": [ - "PES-03.4" + "18.2.2.3": [ + "CPL-03" ], - "ISM-1530": [ - "PES-03.4" + "18.2.2.4": [ + "CPL-03" ], - "ISM-0164": [ - "PES-04.1", - "PES-06", - "PES-06.3" + "18.2.2.5": [ + "CPL-03" ], - "ISM-1123": [ - "PES-07.3" + "18.2.2.6": [ + "CPL-03" ], - "ISM-0181": [ - "PES-12.1" + "18.2.2.7": [ + "CPL-03" ], - "ISM-0187": [ - "PES-12.1" + "18.2.2.8": [ + "CPL-03" ], - "ISM-0194": [ - "PES-12.1" + "18.2.1": [ + "CPL-03.1" ], - "ISM-0195": [ - "PES-12.1" + "18.2.1.3": [ + "CPL-03.1" ], - "ISM-0198": [ - "PES-12.1" + "18.2.1.4": [ + "CPL-03.1" ], - "ISM-0206": [ - "PES-12.1" + "18.2.1.5": [ + "CPL-03.1" ], - "ISM-0208": [ - "PES-12.1" + "18.2.1.6": [ + "CPL-03.1" ], - "ISM-0211": [ - "PES-12.1" + "18.2.1.7": [ + "CPL-03.1" ], - "ISM-0213": [ - "PES-12.1" + "18.2.1.8": [ + "CPL-03.1" ], - "ISM-0216": [ - "PES-12.1" + "18.2.1.9.P": [ + "CPL-03.1" ], - "ISM-0217": [ - "PES-12.1" + "18.2.1.10.P": [ + "CPL-03.1" ], - "ISM-0218": [ - "PES-12.1" + "18.2.1.13.P": [ + "CPL-03.1" ], - "ISM-0926": [ - "PES-12.1" + "18.2.3": [ + "CPL-03.2" ], - "ISM-1095": [ - "PES-12.1" + "18.2.3.1": [ + "CPL-03.2" ], - "ISM-1096": [ - "PES-12.1" + "18.2.3.2": [ + "CPL-03.2" ], - "ISM-1098": [ - "PES-12.1" + "18.2.3.3": [ + "CPL-03.2" ], - "ISM-1100": [ - "PES-12.1" + "18.2.3.4": [ + "CPL-03.2" ], - "ISM-1101": [ - "PES-12.1" + "18.2.3.5": [ + "CPL-03.2" ], - "ISM-1102": [ - "PES-12.1" + "4.6.2.7": [ + "CPL-13.1", + "CPL-13.2" ], - "ISM-1103": [ - "PES-12.1" + "8.3.1.9": [ + "CFG-02" ], - "ISM-1105": [ - "PES-12.1" + "9.5.2.P": [ + "CFG-02.9" ], - "ISM-1107": [ - "PES-12.1", - "PES-16" + "9.5.2.1.PB": [ + "CFG-02.9" ], - "ISM-1109": [ - "PES-12.1" + "12.5": [ + "CFG-05.2" ], - "ISM-1111": [ - "PES-12.1" + "12.5.1": [ + "CFG-05.2" ], - "ISM-1112": [ - "PES-12.1" + "12.5.1.1": [ + "CFG-05.2" ], - "ISM-1114": [ - "PES-12.1" + "12.5.1.2": [ + "CFG-05.2" ], - "ISM-1115": [ - "PES-12.1" + "12.5.1.3": [ + "CFG-05.2" ], - "ISM-1116": [ - "PES-12.1" + "12.6.2": [ + "CFG-05.2" ], - "ISM-1119": [ - "PES-12.1" + "12.6.2.1": [ + "CFG-05.2" ], - "ISM-1122": [ - "PES-12.1" + "12.6.2.2": [ + "CFG-05.2" ], - "ISM-1130": [ - "PES-12.1" + "12.6.2.3": [ + "CFG-05.2" ], - "ISM-1133": [ - "PES-12.1" + "12.6.2.4": [ + "CFG-05.2" ], - "ISM-1164": [ - "PES-12.1" + "12.4": [ + "MON-01" ], - "ISM-1216": [ - "PES-12.1", - "PES-16" + "12.4.1": [ + "MON-01" ], - "ISM-1639": [ - "PES-12.1" + "12.4.1.15.PB": [ + "MON-01" ], - "ISM-1640": [ - "PES-12.1" + "12.4.3.3": [ + "MON-01.8" ], - "ISM-1718": [ - "PES-12.1", - "PES-16" + "12.4.5.P": [ + "MON-01.8" ], - "ISM-1719": [ - "PES-12.1", - "PES-16" + "12.4.5.1.P": [ + "MON-01.8" ], - "ISM-1720": [ - "PES-12.1", - "PES-16" + "12.4.5.2.P": [ + "MON-01.8" ], - "ISM-1721": [ - "PES-12.1", - "PES-16" + "12.4.5.3.P": [ + "MON-01.8" ], - "ISM-0246": [ - "PES-13" + "12.4.5.4.P": [ + "MON-01.8" ], - "ISM-0249": [ - "PES-13" + "12.4.5.5.P": [ + "MON-01.8" ], - "ISM-0250": [ - "PES-13" + "6.1.3.5": [ + "MON-02.6" ], - "ISM-0039": [ - "PRM-01.1" + "6.1.4.7": [ + "MON-02.6" ], - "ISM-1739": [ - "PRM-04", - "PRM-05", - "PRM-07", - "SEA-01", - "SEA-02", - "SEA-03" + "12.4.1.1": [ + "MON-03" ], - "ISM-1809": [ - "RSK-06.2" + "12.4.1.2": [ + "MON-03" ], - "ISM-1567": [ - "RSK-09", - "RSK-09.1", - "TPM-03.1", - "TPM-03.2" + "12.4.1.3": [ + "MON-03" ], - "ISM-1452": [ - "RSK-09.1", - "TPM-02", - "TPM-03" + "12.4.1.4": [ + "MON-03" ], - "ISM-1743": [ - "SEA-01", - "SEA-02", - "SEA-03", - "TPM-03.1" + "12.4.1.5": [ + "MON-03" ], - "ISM-1460": [ - "SEA-13.1", - "VPM-01" + "12.4.1.6": [ + "MON-03" ], - "ISM-1461": [ - "SEA-13.1" + "12.4.1.7": [ + "MON-03" ], - "ISM-1605": [ - "SEA-13.1" + "12.4.1.8": [ + "MON-03" ], - "ISM-1606": [ - "SEA-13.1" + "12.4.1.9": [ + "MON-03" ], - "ISM-1607": [ - "SEA-13.1" + "12.4.1.10": [ + "MON-03" ], - "ISM-0408": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "12.4.1.11": [ + "MON-03" ], - "ISM-0252": [ - "SAT-01", - "SAT-02" + "12.4.1.12": [ + "MON-03" ], - "ISM-1740": [ - "SAT-02", - "SAT-03", - "SAT-03.2" + "12.4.1.13": [ + "MON-03" ], - "ISM-0817": [ - "SAT-02.2", - "SAT-03.2" + "12.4.1.14": [ + "MON-03" ], - "ISM-1565": [ - "SAT-03", - "SAT-03.5" + "12.4.1.17": [ + "MON-03" ], - "ISM-1780": [ - "SAT-03.8", - "TDA-01" + "12.4.1.18": [ + "MON-03" ], - "ISM-0938": [ - "TDA-01" + "12.4.3": [ + "MON-03.3" ], - "ISM-1797": [ - "TDA-01.1" + "12.4.3.1": [ + "MON-03.3" ], - "ISM-1798": [ - "TDA-01.1", - "TDA-02.4", - "TDA-04", - "TDA-04.1" + "12.4.2": [ + "MON-08" ], - "ISM-1730": [ - "TDA-04.2" + "12.4.2.1": [ + "MON-08" ], - "ISM-0401": [ - "TDA-06" + "12.4.2.2": [ + "MON-08" ], - "ISM-1239": [ - "TDA-06", - "WEB-07", - "WEB-08" + "12.4.2.3": [ + "MON-08" ], - "ISM-1419": [ - "TDA-06", - "TDA-07" + "12.4.3.2": [ + "MON-08" ], - "ISM-1552": [ - "TDA-06", - "WEB-10" + "5.1.1.17": [ + "CRY-01" ], - "ISM-1238": [ - "TDA-06.2" + "10.1": [ + "CRY-01" ], - "ISM-0400": [ - "TDA-07", - "TDA-08" + "10.1.1": [ + "CRY-01" ], - "ISM-0402": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TDA-10.1" + "10.1.1.1": [ + "CRY-01" ], - "ISM-1754": [ - "TDA-09" + "10.1.1.2": [ + "CRY-01" ], - "ISM-1420": [ - "TDA-10" + "10.1.1.3": [ + "CRY-01" ], - "ISM-0304": [ - "TDA-17" + "10.1.1.4": [ + "CRY-01" ], - "ISM-1501": [ - "TDA-17" + "10.1.1.5": [ + "CRY-01" ], - "ISM-1704": [ - "TDA-17" + "10.1.1.6": [ + "CRY-01" ], - "ISM-1753": [ - "TDA-17" + "10.1.1.7": [ + "CRY-01" ], - "ISM-1422": [ - "TDA-20" + "10.1.1.8": [ + "CRY-01" ], - "ISM-1073": [ - "TPM-01" + "10.1.1.9.PB": [ + "CRY-01" ], - "ISM-1631": [ - "TPM-01.1" + "10.1.1.10.P": [ + "CRY-01" ], - "ISM-1637": [ - "TPM-01.1" + "13.2.1.6": [ + "CRY-01" ], - "ISM-1638": [ - "TPM-01.1" + "14.1.3": [ + "CRY-01" ], - "ISM-1736": [ - "TPM-01.1" + "14.1.3.1": [ + "CRY-01" ], - "ISM-1737": [ - "TPM-01.1" + "14.1.3.2": [ + "CRY-01" ], - "ISM-1786": [ - "TPM-01.1" + "14.1.3.3": [ + "CRY-01" ], - "ISM-1632": [ - "TPM-03", - "TPM-03.1" + "14.1.3.4": [ + "CRY-01" ], - "ISM-1568": [ - "TPM-03.1", - "TPM-04.1" + "14.1.3.5": [ + "CRY-01" ], - "ISM-1788": [ - "TPM-03.1" + "14.1.3.6": [ + "CRY-01" ], - "ISM-1787": [ - "TPM-04.1" + "18.1.5": [ + "CRY-01.2" ], - "ISM-1395": [ - "TPM-05" + "18.1.5.1": [ + "CRY-01.2" ], - "ISM-1738": [ - "TPM-05" + "18.1.5.2": [ + "CRY-01.2" ], - "ISM-1576": [ - "TPM-05.1" + "18.1.5.3": [ + "CRY-01.2" ], - "ISM-1793": [ - "TPM-05.5", - "TPM-08" + "18.1.5.4": [ + "CRY-01.2" ], - "ISM-1804": [ - "TPM-05.7" + "18.1.5.5": [ + "CRY-01.2" ], - "ISM-1794": [ - "TPM-10" + "18.1.5.6": [ + "CRY-01.2" ], - "ISM-1616": [ - "THR-06" + "14.2.5.8": [ + "CRY-04" ], - "ISM-1717": [ - "THR-06" + "8.3.1.5": [ + "CRY-05" ], - "ISM-1755": [ - "THR-06" + "10.1.2": [ + "CRY-09" ], - "ISM-1756": [ - "THR-06" + "10.1.2.1": [ + "CRY-09" ], - "ISM-1143": [ - "VPM-01", - "VPM-05" + "10.1.2.2": [ + "CRY-09" ], - "ISM-1801": [ - "VPM-04" + "10.1.2.3": [ + "CRY-09" ], - "ISM-1467": [ - "VPM-04.1", - "VPM-05.4" + "10.1.2.4": [ + "CRY-09" ], - "ISM-1483": [ - "VPM-04.1" + "10.1.2.5": [ + "CRY-09" ], - "ISM-1690": [ - "VPM-05" + "10.1.2.6": [ + "CRY-09" ], - "ISM-1691": [ - "VPM-05" + "10.1.2.7": [ + "CRY-09" ], - "ISM-1692": [ - "VPM-05" + "10.1.2.8": [ + "CRY-09" ], - "ISM-1693": [ - "VPM-05" + "10.1.2.9": [ + "CRY-09" ], - "ISM-1694": [ - "VPM-05" + "10.1.2.10": [ + "CRY-09" ], - "ISM-1695": [ - "VPM-05" + "10.1.2.11": [ + "CRY-09" ], - "ISM-1696": [ - "VPM-05" + "10.1.2.12": [ + "CRY-09" ], - "ISM-1697": [ - "VPM-05" + "10.1.2.13": [ + "CRY-09" ], - "ISM-1751": [ - "VPM-05" + "10.1.2.14": [ + "CRY-09" ], - "ISM-0298": [ - "VPM-05.1" + "10.1.2.15": [ + "CRY-09" ], - "ISM-0300": [ - "VPM-05.1" + "10.1.2.16": [ + "CRY-09" ], - "ISM-1698": [ - "VPM-06" + "10.1.2.17": [ + "CRY-09" ], - "ISM-1699": [ - "VPM-06" + "10.1.2.18": [ + "CRY-09" ], - "ISM-1700": [ - "VPM-06" + "10.1.2.19": [ + "CRY-09" ], - "ISM-1701": [ - "VPM-06" + "10.1.2.20.PB": [ + "CRY-09" ], - "ISM-1702": [ - "VPM-06" + "5.1.1.10": [ + "DCH-01" ], - "ISM-1703": [ - "VPM-06" + "5.1.1.14": [ + "DCH-01" ], - "ISM-1752": [ - "VPM-06" + "8.2": [ + "DCH-01" ], - "ISM-1808": [ - "VPM-06.1" + "8.2.3": [ + "DCH-01" ], - "ISM-0971": [ - "WEB-07" + "8.2.3.1": [ + "DCH-01" ], - "ISM-1240": [ - "WEB-09" + "13.2": [ + "DCH-01" ], - "ISM-1241": [ - "WEB-11" + "13.2.1": [ + "DCH-01" ], - "ISM-1424": [ - "WEB-12" - ] - }, - "apac-aus-cop-sitc-2020": { - "Principle 4": [ - "AST-18", - "SEA-01", - "SEA-02", - "SEA-03" + "13.2.1.10": [ + "DCH-01" ], - "Principle 7": [ - "AST-18", - "SEA-01", - "SEA-02", - "SEA-03" + "13.2.1.12": [ + "DCH-01" ], - "Principle 11": [ - "EMB-02" + "13.2.1.13": [ + "DCH-01" ], - "Principle 13": [ - "EMB-02", - "EMB-04" + "13.2.1.14": [ + "DCH-01" ], - "Principle 6": [ - "EMB-04", - "EMB-06", - "SEA-01", - "SEA-02", - "SEA-03" + "8.2.3.3": [ + "DCH-01.3" ], - "Principle 8": [ - "EMB-05", - "END-06.5", - "END-06.6" + "8.2.3.4": [ + "DCH-01.3" ], - "Principle 10": [ - "EMB-05" + "8.3.1.3": [ + "DCH-01.3" ], - "Principle 3": [ - "EMB-07" + "8.2.3.2": [ + "DCH-01.4" ], - "Principle 12": [ - "EMB-07" + "8.2.1": [ + "DCH-02" ], - "Principle 9": [ - "EMB-08" + "8.2.1.1": [ + "DCH-02" ], - "Principle 1": [ - "IAC-10.1", - "IAC-10.8" + "8.2.1.2": [ + "DCH-02" ], - "Principle 5": [ - "SEA-01", - "SEA-02", - "SEA-03" + "8.2.1.3": [ + "DCH-02" ], - "Principle 2": [ - "THR-06" - ] - }, - "apac-aus-ps-cps-230-2023": { - "13": [ - "RSK-01" + "8.2.1.4": [ + "DCH-02" ], - "14": [ - "BCD-01" + "8.2.1.5": [ + "DCH-02" ], - "15": [ - "TPM-01", - "TPM-04.1", - "TPM-05" + "8.2.1.6": [ + "DCH-02" ], - "17": [ - "RSK-01" + "8.2.1.7": [ + "DCH-02" ], - "18": [ - "RSK-01" + "8.2.1.8": [ + "DCH-02" ], - "20": [ - "GOV-01.1" + "8.2.1.9": [ + "DCH-02" ], - "21": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "8.2.1.10": [ + "DCH-02" ], - "23": [ - "GOV-01.1" + "8.2.2": [ + "DCH-04" ], - "24": [ - "GOV-01.1", - "GOV-04", - "GOV-14" + "8.2.2.1": [ + "DCH-04" ], - "25": [ - "GOV-01.1", - "PRM-01", - "PRM-02", - "PRM-03" + "8.2.2.2": [ + "DCH-04" ], - "26": [ - "RSK-01.3", - "RSK-01.4", - "RSK-01.5" + "8.2.2.3": [ + "DCH-04" ], - "28": [ - "CPL-01", - "RSK-04" + "8.2.2.4": [ + "DCH-04" ], - "29": [ - "GOV-15", - "GOV-15.1", - "CPL-02" + "8.2.2.5": [ + "DCH-04" ], - "30": [ - "GOV-01.2", - "GOV-15.5", - "CPL-01.1", - "CPL-02" + "8.2.2.6": [ + "DCH-04" ], - "31": [ - "CPL-01.1", - "RSK-06" + "8.2.2.7.PB": [ + "DCH-04" ], - "32": [ - "IRO-01", - "IRO-02" + "8.2.3.6": [ + "DCH-04" ], - "33": [ - "GOV-06", - "IRO-10" + "8.3.1.4": [ + "DCH-06", + "DCH-06.1" ], - "35": [ - "BCD-02" + "8.3.3": [ + "DCH-07" ], - "37": [ - "BCD-02" + "8.3.3.1": [ + "DCH-07" ], - "39": [ - "BCD-01.4" + "8.3.3.2": [ + "DCH-07" ], - "41": [ - "BCD-01" + "8.3.3.3": [ + "DCH-07" ], - "42": [ - "GOV-06", - "IRO-10" + "8.3.3.4": [ + "DCH-07" ], - "43": [ - "BCD-04" + "8.3.3.5": [ + "DCH-07" ], - "44": [ - "BCD-04" + "13.2.2.5": [ + "DCH-07" ], - "45": [ - "BCD-04" + "8.3.1.10": [ + "DCH-07.1" ], - "46": [ - "BCD-04", - "CPL-02.1" + "8.3.2.4": [ + "DCH-08" ], - "47": [ - "TPM-01" + "8.3.2.5": [ + "DCH-08" ], - "49": [ - "TPM-01.1" + "8.3.2.6": [ + "DCH-08" ], - "51": [ - "GOV-06" + "11.2.7.3": [ + "DCH-09" ], - "52": [ - "TPM-02" + "8.3.2.7": [ + "DCH-09.1" ], - "57": [ - "TPM-01" + "13.2.1.5": [ + "DCH-14" ], - "60": [ - "CPL-02.1" + "13.2.1.9": [ + "DCH-14" ], - "22(a)": [ - "GOV-01.1" + "4.4.7.4": [ + "DCH-18", + "RSK-04", + "RSK-04.2", + "RSK-06.1" ], - "22(b)": [ - "GOV-01.1" + "4.6.3.4": [ + "DCH-18" ], - "22(c)": [ - "GOV-01.1" + "12.3.1.15": [ + "DCH-18" ], - "58(a)": [ - "GOV-01.2", - "TPM-08" + "12.3.1.19.P": [ + "DCH-18" ], - "58(b)": [ - "GOV-01.2", - "CPL-02", - "TPM-08" + "13.2.1.7": [ + "DCH-18" ], - "58(c)": [ - "GOV-01.2", - "CPL-02", - "TPM-08" + "18.1.3": [ + "DCH-18" ], - "59(a)": [ - "GOV-06" + "18.1.3.1": [ + "DCH-18" ], - "59(b)": [ - "GOV-06" + "18.1.3.2": [ + "DCH-18" ], - "12(b)": [ - "BCD-01" + "18.1.3.3": [ + "DCH-18" ], - "34(a)": [ - "BCD-01", - "BCD-02" + "18.1.3.4": [ + "DCH-18" ], - "34(b)": [ - "BCD-01" + "18.1.3.5": [ + "DCH-18" ], - "34(c)": [ - "BCD-01" + "18.1.3.6": [ + "DCH-18" ], - "34(d)": [ - "BCD-01" + "18.1.3.7": [ + "DCH-18" ], - "34(e)": [ - "BCD-01", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3" + "18.1.3.8": [ + "DCH-18" ], - "40(a)": [ - "BCD-01" + "18.1.3.9": [ + "DCH-18" ], - "40(b)": [ - "BCD-01" + "18.1.3.10": [ + "DCH-18" ], - "40(c)": [ - "BCD-01" + "18.1.3.11": [ + "DCH-18" ], - "40(d)": [ - "BCD-01" + "18.1.3.12": [ + "DCH-18" ], - "40(e)": [ - "BCD-01" + "18.1.3.13.PB": [ + "DCH-18" ], - "38(a)": [ - "BCD-01.4" + "5.1.1.15": [ + "END-01" ], - "38(b)": [ - "BCD-01.4" + "12.2.1.2": [ + "END-01" ], - "38(c)": [ - "BCD-01.4" + "6.2.1.1": [ + "END-02" ], - "36(a)": [ - "BCD-02" + "6.2.1.2": [ + "END-02" ], - "36(b)": [ - "BCD-02" + "6.2.1.3": [ + "END-02" ], - "36(c)": [ - "BCD-02" + "6.2.1.4": [ + "END-02" ], - "36(d)": [ - "BCD-02" + "6.2.1.5": [ + "END-02" ], - "12(a)": [ - "RSK-01" + "6.2.1.6": [ + "END-02" ], - "12(c)": [ - "RSK-01" + "6.2.1.7": [ + "END-02" ], - "16(a)": [ - "RSK-01" + "6.2.1.8": [ + "END-02" ], - "16(b)": [ - "RSK-01" + "6.2.1.9": [ + "END-02" ], - "16(c)": [ - "RSK-01" + "6.2.1.10": [ + "END-02" ], - "16(d)": [ - "RSK-01" + "6.2.1.11": [ + "END-02" ], - "16(e)": [ - "RSK-01" + "6.2.1.12": [ + "END-02" ], - "16(f)": [ - "RSK-01" + "6.2.1.13": [ + "END-02" ], - "19(a)": [ - "RSK-01" + "6.2.1.14": [ + "END-02" ], - "19(b)": [ - "RSK-01" + "6.2.1.15": [ + "END-02" ], - "19(c)": [ - "RSK-01" + "6.2.1.16": [ + "END-02" ], - "19(d)": [ - "RSK-01" + "6.2.1.17": [ + "END-02" ], - "19(e)": [ - "RSK-01" + "6.2.1.21": [ + "END-02" ], - "27(a)": [ - "RSK-04" + "6.2.1.22": [ + "END-02" ], - "27(b)": [ - "RSK-04" + "12.2": [ + "END-04" ], - "27(c)": [ - "RSK-04" + "12.2.1": [ + "END-04" ], - "48(a)": [ - "TPM-01" + "12.2.1.1": [ + "END-04" ], - "48(b)": [ - "TPM-01" + "12.2.1.3": [ + "END-04" ], - "48(c)": [ - "TPM-01" + "12.2.1.4": [ + "END-04" ], - "50(a)": [ - "TPM-02" + "12.2.1.5": [ + "END-04" ], - "50(b)": [ - "TPM-02" + "12.2.1.6": [ + "END-04" ], - "50(c)": [ - "TPM-02" + "12.2.1.7": [ + "END-04" ], - "50(d)": [ - "TPM-02" + "12.2.1.8": [ + "END-04" ], - "56(a)": [ - "TPM-03.2" + "12.2.1.9": [ + "END-04" ], - "56(b)": [ - "TPM-03.2" + "12.2.1.15": [ + "END-04" ], - "56(c)": [ - "TPM-03.2" + "4.5.2.2": [ + "HRS-01", + "HRS-02", + "HRS-03", + "HRS-03.2", + "HRS-11" ], - "56(d)": [ - "TPM-03.2" + "5.1.1.12": [ + "HRS-01" ], - "53(a)": [ - "TPM-04.1" + "7.1": [ + "HRS-01" ], - "53(b)": [ - "TPM-04.1" + "7.1.1.13": [ + "HRS-01" ], - "54(a)": [ - "TPM-05" + "8.1.4.1": [ + "HRS-01.1" ], - "54(b)": [ - "TPM-05" + "8.1.4.2": [ + "HRS-01.1" ], - "54(c)": [ - "TPM-05" + "8.1.4.3": [ + "HRS-01.1" ], - "54(d)": [ - "TPM-05" + "8.1.4.4": [ + "HRS-01.1" ], - "54(e)": [ - "TPM-05" + "9.2.6.2": [ + "HRS-01.1" ], - "54(f)": [ - "TPM-05" + "9.2.6.4": [ + "HRS-01.1" ], - "54(g)": [ - "TPM-05" + "9.2.6.5": [ + "HRS-01.1" ], - "55(a)": [ - "TPM-05" + "9.2.6.6": [ + "HRS-01.1" ], - "55(b)": [ - "TPM-05" + "6.1.1": [ + "HRS-03" ], - "55(c)": [ - "TPM-05" + "6.1.1.1": [ + "HRS-03" ], - "50(g)": [ - "TPM-05.7" - ] - }, - "apac-aus-ps-cps-234-2019": { - "13": [ - "GOV-01", - "GOV-01.1", - "PRM-01", - "PRM-01.1", - "PRM-02" + "6.1.1.2": [ + "HRS-03" ], - "14": [ - "GOV-04", + "6.1.1.3": [ "HRS-03" ], - "15": [ - "PRM-01", - "PRM-01.1", - "PRM-01.2", - "PRM-02", - "PRM-03", - "SEA-01", - "SEA-02", - "SEA-03" + "6.1.1.4": [ + "HRS-03" ], - "16": [ - "TPM-01", - "TPM-04", - "TPM-05" + "6.1.1.5": [ + "HRS-03" ], - "17": [ - "THR-01", - "VPM-01" + "6.1.1.6": [ + "HRS-03" ], - "18": [ - "GOV-01", - "GOV-02", - "SEA-01", - "SEA-01.1", - "SEA-02", - "SEA-03" + "6.1.1.7": [ + "HRS-03" ], - "19": [ - "GOV-01", - "GOV-01.1", - "GOV-02", - "GOV-03", - "GOV-04" + "6.1.1.13.PB": [ + "HRS-03" ], - "20": [ - "DCH-01", - "DCH-02", - "TPM-01", - "TPM-05" + "4.5.2.6": [ + "HRS-03.1", + "HRS-04.2", + "HRS-05.7" ], - "21": [ - "AST-01", - "VPM-02", - "VPM-04", - "VPM-05" + "4.5.2.7": [ + "HRS-03.1" ], - "22": [ - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-04.1" + "4.5.2.8": [ + "HRS-03.1", + "HRS-05.7" ], - "23": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09" + "7.1.2.7": [ + "HRS-03.1" ], - "24": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09" + "7.2": [ + "HRS-03.1", + "HRS-04.2", + "HRS-05.7" ], - "26": [ - "IRO-06" + "7.2.1.4": [ + "HRS-03.1" ], - "27": [ - "CPL-02" + "8.1.3.1": [ + "HRS-03.1", + "HRS-04.2", + "HRS-05.7" ], - "28": [ - "TPM-01", - "TPM-03", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-08" + "4.5.2.3": [ + "HRS-03.2" ], - "29": [ - "CPL-01.1", - "CPL-02" + "7.1.1.6": [ + "HRS-03.2" ], - "30": [ - "CPL-03", - "CPL-03.1" + "14.2.1.7": [ + "HRS-03.2" ], - "31": [ - "CPL-01", - "CPL-02.1" + "14.2.1.8": [ + "HRS-03.2" ], - "32": [ - "CPL-02.1" + "14.2.1.11": [ + "HRS-03.2" ], - "33": [ - "CPL-02.1" + "7.1.1": [ + "HRS-04" + ], + "7.1.1.1": [ + "HRS-04" ], - "34": [ - "CPL-02.1" + "7.1.1.2": [ + "HRS-04" ], - "35": [ - "GOV-06", - "CPL-01", - "CPL-01.1" + "7.1.1.3": [ + "HRS-04" ], - "36": [ - "GOV-06", - "CPL-01", - "CPL-01.1" + "7.1.1.5": [ + "HRS-04" ], - "35(a)": [ - "GOV-06", - "CPL-01", - "CPL-01.1" + "7.1.1.9": [ + "HRS-04" ], - "35(b)": [ - "GOV-06", - "CPL-01", - "CPL-01.1" + "7.1.1.10": [ + "HRS-04", + "HRS-10" ], - "21(c)": [ - "AST-01", - "PRM-07" + "7.1.1.7": [ + "HRS-04.1" ], - "21(a)": [ - "AST-01.1", - "DCH-01", - "DCH-02" + "7.1.1.8": [ + "HRS-04.1" ], - "21(b)": [ - "BCD-02", - "TDA-06.1", - "TPM-02" + "7.2.1.1": [ + "HRS-04.2" ], - "21(d)": [ - "CHG-03", - "RSK-08", - "RSK-10" + "7.1.2": [ + "HRS-05" ], - "27(a)": [ - "CPL-02" + "7.1.2.1": [ + "HRS-05" ], - "27(b)": [ - "CPL-02" + "7.1.2.2": [ + "HRS-05" ], - "27(c)": [ - "CPL-02" + "7.1.2.3": [ + "HRS-05" ], - "27(d)": [ - "CPL-02" + "7.1.2.4": [ + "HRS-05" ], - "27(e)": [ - "CPL-02" + "7.1.2.5": [ + "HRS-05" ], - "34(a)": [ - "CPL-02.1" + "7.1.2.6": [ + "HRS-05" ], - "34(b)": [ - "CPL-02.1" + "7.1.2.8": [ + "HRS-05" ], - "25(a)": [ - "IRO-04", - "IRO-07", - "IRO-13" + "7.1.2.9": [ + "HRS-05" ], - "25(b)": [ - "IRO-04", - "IRO-07" - ] - }, - "apac-chn-cybersecurity-law-2017": { - "Article 28": [ - "GOV-12", - "GOV-13", - "CPL-05.2", - "CPL-06" + "7.2.1": [ + "HRS-05" ], - "Article 38": [ - "GOV-17", - "CPL-03.1" + "7.2.1.5": [ + "HRS-05" ], - "Article 54(1)": [ - "GOV-17" + "9.2.4.2": [ + "HRS-05" ], - "Article 33": [ - "BCD-01" + "7.2.1.2": [ + "HRS-05.1" ], - "Article 34(4)": [ - "BCD-01", - "BCD-04" + "8.1.3": [ + "HRS-05.1" ], - "Article 34(3)": [ - "BCD-11" + "8.1.3.2": [ + "HRS-05.1" ], - "Article 9": [ - "CPL-01" + "13.2.1.1": [ + "HRS-05.3" ], - "Article 10": [ - "CPL-01" + "13.2.1.2": [ + "HRS-05.3" ], - "Article 21": [ - "CPL-01" + "13.2.1.3": [ + "HRS-05.3" ], - "Article 23": [ - "CPL-01" + "13.2.1.4": [ + "HRS-05.3" ], - "Article 26": [ - "CPL-01" + "13.2.1.8": [ + "HRS-05.3" ], - "Article 27": [ - "CPL-01" + "13.2.1.11": [ + "HRS-05.3" ], - "Article 34": [ - "CPL-01" + "7.2.1.3": [ + "HRS-05.7" ], - "Article 34(5)": [ - "CPL-01" + "13.2.4": [ + "HRS-06.1" ], - "Article 41": [ - "CPL-01", - "PRI-05.4" + "13.2.4.1": [ + "HRS-06.1" ], - "Article 47": [ - "CPL-01" + "13.2.4.2": [ + "HRS-06.1" ], - "Article 72": [ - "CPL-05" + "13.2.4.3": [ + "HRS-06.1" ], - "Article 55": [ - "CPL-05.2" + "13.2.4.4": [ + "HRS-06.1" ], - "Article 56": [ - "CPL-05.2" + "13.2.4.5": [ + "HRS-06.1" ], - "Article 29": [ - "CPL-06" + "13.2.4.6": [ + "HRS-06.1" ], - "Article 40": [ - "DCH-01", - "IAC-01" + "13.2.4.7": [ + "HRS-06.1" ], - "Article 37": [ - "DCH-26" + "13.2.4.8": [ + "HRS-06.1" ], - "Article 34(1)": [ - "HRS-01" + "13.2.4.9": [ + "HRS-06.1" ], - "Article 25": [ - "IRO-04" + "13.2.4.10": [ + "HRS-06.1" ], - "Article 35": [ - "IAO-02" + "13.2.4.11": [ + "HRS-06.1" ], - "Article 42": [ - "PRI-01.6" + "13.2.4.12": [ + "HRS-06.1" ], - "Article 22": [ - "PRI-03", - "TDA-01.1" + "13.2.4.13": [ + "HRS-06.1" ], - "Article 44": [ - "PRI-05.4" + "13.2.4.14": [ + "HRS-06.1" ], - "Article 43": [ - "PRI-06.1", - "PRI-06.4", - "PRI-06.5" + "13.2.4.15": [ + "HRS-06.1" ], - "Article 24": [ - "PRI-16" + "13.2.4.16": [ + "HRS-06.1" ], - "Article 34(2)": [ - "SAT-01" + "7.1.2.10": [ + "HRS-06.2" ], - "Article 46": [ - "TDA-01.1" + "7.2.3": [ + "HRS-07" ], - "Article 48": [ - "TDA-01.1" + "7.2.3.1": [ + "HRS-07" ], - "Article 36": [ - "TPM-05" - ] - }, - "apac-chn-data-security-law-2021": { - "7": [ - "GOV-12", - "GOV-13", - "PRI-16" + "7.2.3.2": [ + "HRS-07" ], - "8": [ - "GOV-12", - "GOV-13", - "PRI-16" + "7.2.3.3": [ + "HRS-07" ], - "9": [ - "GOV-12", - "GOV-13", - "PRI-16" + "7.2.3.4": [ + "HRS-07" ], - "11": [ - "GOV-12", - "GOV-13", - "PRI-16" + "7.3": [ + "HRS-09" ], - "14": [ - "GOV-12", - "GOV-13", - "PRI-16" + "7.3.1": [ + "HRS-09" ], - "15": [ - "GOV-12", - "GOV-13", - "PRI-16" + "7.3.1.1": [ + "HRS-09" ], - "16": [ - "GOV-12", - "GOV-13", - "PRI-16" + "7.3.1.2": [ + "HRS-09" ], - "18": [ - "GOV-12", - "GOV-13", - "PRI-16" + "7.3.1.3": [ + "HRS-09" ], - "19": [ - "GOV-12", - "GOV-13", - "PRI-16" + "6.1.2": [ + "HRS-11" ], - "20": [ - "GOV-12", - "GOV-13", - "PRI-16" + "6.1.2.1": [ + "HRS-11" ], - "24": [ - "CPL-06" + "6.1.2.2": [ + "HRS-11" ], - "27": [ - "CHG-04.4", - "CPL-06", - "HRS-03", - "HRS-04.1", - "HRS-12", - "IAC-07.1", - "IAC-08", - "PES-02.1", - "SAT-03" + "6.1.2.3": [ + "HRS-11" ], - "28": [ - "GOV-12", - "GOV-13", - "PRI-16" + "6.1.2.4": [ + "HRS-11" ], - "31": [ - "GOV-12", - "GOV-13", - "CPL-06", - "PRI-16" + "7.2.1.7": [ + "HRS-15" ], - "32": [ - "GOV-12", - "GOV-13", - "PRI-16" + "5.1.1.9": [ + "IAC-01" ], - "33": [ - "GOV-12", - "GOV-13", - "CPL-06", - "PRI-16" + "9.1": [ + "IAC-01" ], - "36": [ - "GOV-12", - "GOV-13", - "DCH-26", - "PRI-16" + "9.1.1": [ + "IAC-01" ], - "37": [ - "GOV-12", - "GOV-13", - "PRI-16" + "9.1.1.1": [ + "IAC-01" ], - "38": [ - "GOV-12", - "GOV-13", - "PRI-16" + "9.1.1.2": [ + "IAC-01" ], - "44": [ - "CPL-06" + "9.1.1.3": [ + "IAC-01" ], - "45": [ - "GOV-04" + "9.1.1.4": [ + "IAC-01" ], - "46": [ - "GOV-04", - "CPL-01" + "9.1.1.5": [ + "IAC-01" ], - "48": [ - "GOV-12", - "GOV-13", - "PRI-16" + "9.1.1.6": [ + "IAC-01" ], - "53": [ - "GOV-12", - "GOV-13", - "PRI-16" - ] - }, - "apac-chn-csnip-2012": { - "4": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "9.1.1.7": [ + "IAC-01" ], - "8": [ - "DCH-22.1", - "PRI-06.1" + "9.1.1.8": [ + "IAC-01" ], - "Inferred": [ - "PRI-01" + "9.1.1.9": [ + "IAC-01" ], - "Expectation": [ - "PRI-01" - ] - }, - "apac-chn-pipl-2021": { - "5": [ - "PRI-04.1" + "9.1.1.10": [ + "IAC-01" ], - "6": [ - "DCH-18.2", - "PRI-02.1" + "9.1.1.11": [ + "IAC-01" ], - "7": [ - "PRI-01", - "PRI-02" + "9.1.1.12": [ + "IAC-01" ], - "8": [ - "DCH-22", - "PRI-05.2", - "PRI-10" + "9.1.1.13": [ + "IAC-01" ], - "9": [ - "PRI-01.1", - "PRI-01.3", - "PRI-01.4", - "PRI-01.6" + "9.1.1.14": [ + "IAC-01" ], - "10": [ - "PRI-03.3", - "PRI-04.1", - "PRI-04.2", - "PRI-05" + "9.1.1.15": [ + "IAC-01" ], - "11": [ - "GOV-13", - "CPL-06", - "PRI-16" + "9.4.1.8.PB": [ + "IAC-01" ], - "12": [ - "GOV-13", - "CPL-06", - "PRI-16" + "9.4.2": [ + "IAC-01.2" ], - "13": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "9.4.2.1": [ + "IAC-01.2" ], - "14": [ - "PRI-03", - "PRI-03.2" + "9.4.2.2.B": [ + "IAC-01.2" ], - "15": [ - "PRI-03.4" + "9.4.2.3": [ + "IAC-01.2" ], - "16": [ - "PRI-01", - "PRI-03.5" + "9.4.2.4": [ + "IAC-01.2" ], - "17": [ - "PRI-02" + "9.4.2.5": [ + "IAC-01.2" ], - "18": [ - "CPL-05.1", - "PRI-04.1", - "PRI-05.4", - "PRI-16" + "9.4.2.6": [ + "IAC-01.2" ], - "19": [ - "MON-10", - "DCH-18", - "PRI-05" + "9.4.2.7": [ + "IAC-01.2" ], - "20": [ - "PRI-01.7", - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "TPM-01", - "TPM-03.2", - "TPM-04", - "TPM-05" + "9.4.2.8": [ + "IAC-01.2" ], - "21": [ - "PRI-01.7", - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "TPM-01", - "TPM-04", - "TPM-04.4", - "TPM-05" + "9.4.2.9": [ + "IAC-01.2" ], - "22": [ - "PRI-01.7", - "PRI-03.2", - "PRI-06.2", - "PRI-07" + "9.4.2.10": [ + "IAC-01.2" ], - "23": [ - "PRI-03", - "PRI-03.2" + "9.4.2.11": [ + "IAC-01.2" ], - "24": [ - "PRI-02.2" + "9.4.2.12": [ + "IAC-01.2" ], - "25": [ - "PRI-01.6", - "PRI-01.7" + "9.4.2.13": [ + "IAC-01.2" ], - "26": [ - "AST-20", - "CPL-06", - "EMB-02", - "END-14", - "PES-05.1", - "PRI-04", - "PRI-04.1", - "PRI-04.3", - "PRI-16" + "9.4.2.14": [ + "IAC-01.2" ], - "27": [ - "PRI-02", - "PRI-03", - "PRI-03.2", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "9.4.2.15": [ + "IAC-01.2" ], - "28": [ - "PRI-01.6", - "PRI-05.1", - "PRI-05.4" + "9.4.2.16": [ + "IAC-01.2" ], - "29": [ - "PRI-03", - "PRI-04.1", - "PRI-05.4" + "9.2.2": [ + "IAC-07" ], - "30": [ - "PRI-03", - "PRI-04.1", - "PRI-05.4" + "9.2.2.2": [ + "IAC-07" ], - "31": [ - "PRI-04", - "PRI-05.4" + "9.2.2.3": [ + "IAC-07" ], - "32": [ - "CPL-01", - "PRI-05.4" + "9.2.2.4": [ + "IAC-07" ], - "36": [ - "DCH-26" + "9.2.2.6": [ + "IAC-07" ], - "37": [ - "CPL-01" + "9.2.2.8.PB": [ + "IAC-07" ], - "38": [ - "GOV-12", - "CLD-09", - "DCH-19", - "DCH-26", - "TPM-04.4" + "9.2.6": [ + "IAC-07" ], - "39": [ - "CLD-09", - "DCH-19", - "PRI-02" + "9.2.6.3": [ + "IAC-07" ], - "40": [ - "GOV-12", - "GOV-13", - "CLD-09", - "CPL-03", - "CPL-03.1", - "CPL-06", - "DCH-19", - "DCH-26", - "PRI-16", - "TPM-04.4" + "8.1.2.5": [ + "IAC-08" ], - "41": [ - "CPL-05", - "PRI-01.7", - "PRI-07" + "9.4": [ + "IAC-08" ], - "42": [ - "CPL-01", - "PRI-07", - "PRI-07.1", - "TPM-01", - "TPM-05" + "9.4.1": [ + "IAC-08" ], - "44": [ - "PRI-03" + "9.4.1.1": [ + "IAC-08" ], - "45": [ - "PRI-06", - "PRI-06.4", - "PRI-06.7", - "PRI-07.4", - "PRI-07.5" + "9.4.1.2": [ + "IAC-08" ], - "46": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.4", - "PRI-07.3", - "PRI-07.4", - "PRI-07.5" + "9.4.1.3": [ + "IAC-08" ], - "47": [ - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-06.5" + "9.4.1.4": [ + "IAC-08" ], - "48": [ - "PRI-01.3", - "PRI-02", - "PRI-02.1" + "9.4.1.5": [ + "IAC-08" ], - "49": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.5", - "PRI-07", - "PRI-07.4", - "PRI-07.5" + "9.4.1.6": [ + "IAC-08" ], - "50": [ - "PRI-06.4" + "9.4.1.7": [ + "IAC-08" ], - "51": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "OPS-03", - "TPM-01" + "9.2.4": [ + "IAC-10" ], - "52": [ - "GOV-04", - "PRI-01.1", - "PRI-01.4", - "TPM-06" + "9.2.4.1": [ + "IAC-10" ], - "53": [ - "PRI-01.4" + "9.2.4.3": [ + "IAC-10" ], - "54": [ - "CPL-01.1", - "CPL-02", - "CPL-02.1", - "CPL-03.2" + "9.2.4.4": [ + "IAC-10" ], - "55": [ - "RSK-10" + "9.2.4.5": [ + "IAC-10" ], - "56": [ - "RSK-10" + "9.2.4.6": [ + "IAC-10" ], - "57": [ - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-10.2" + "9.2.4.7": [ + "IAC-10" ], - "58": [ - "GOV-01", - "GOV-10", - "PRI-01" + "9.2.4.8": [ + "IAC-10" ], - "59": [ - "PRI-01", - "PRI-01.6" + "9.3.1.4": [ + "IAC-10.1" ], - "60": [ - "GOV-13", - "CPL-06" + "9.4.3": [ + "IAC-10.1" ], - "63": [ - "CPL-05.2" + "9.4.3.1": [ + "IAC-10.1" ], - "64": [ - "GOV-13", - "CPL-05.2", - "CPL-06" + "9.4.3.2": [ + "IAC-10.1" ], - "58(1)": [ - "GOV-01", - "GOV-10", - "PRI-01" + "9.4.3.3": [ + "IAC-10.1" ], - "58(2)": [ - "GOV-01", - "GOV-10", - "PRI-01" + "9.4.3.4": [ + "IAC-10.1" ], - "58(3)": [ - "GOV-01", - "GOV-10", - "PRI-01" + "9.4.3.5": [ + "IAC-10.1" ], - "58(4)": [ - "GOV-01", - "GOV-10", - "PRI-01" + "9.4.3.6": [ + "IAC-10.1" ], - "38(4)": [ - "GOV-12", - "GOV-13", - "CPL-01", - "CPL-06", - "PRI-16" + "9.4.3.7": [ + "IAC-10.1" ], - "47(5)": [ - "GOV-13", - "CPL-06", - "PRI-05", - "PRI-06.5", - "PRI-16" + "9.4.3.8": [ + "IAC-10.1" ], - "63(3)": [ - "GOV-13", - "CPL-05.2", - "CPL-06" + "9.4.3.9": [ + "IAC-10.1" ], - "63(4)": [ - "GOV-13", - "CPL-05.2", - "CPL-06" + "9.3": [ + "IAC-10.5" ], - "38(1)": [ - "CPL-03", - "CPL-03.1" + "9.3.1": [ + "IAC-10.5" ], - "38(2)": [ - "CPL-03", - "CPL-03.1" + "9.3.1.1": [ + "IAC-10.5" ], - "61(4)": [ - "CPL-05.2", - "CPL-06" + "9.3.1.2": [ + "IAC-10.5" ], - "63(1)": [ - "CPL-05.2" + "9.3.1.3": [ + "IAC-10.5" ], - "63(2)": [ - "CPL-05.2" + "9.3.1.5": [ + "IAC-10.5" ], - "57(1)": [ - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-10.2" + "9.3.1.6": [ + "IAC-10.5" ], - "57(2)": [ - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-10.2" + "9.3.1.7": [ + "IAC-10.5" ], - "57(3)": [ - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-10.2" + "9.2": [ + "IAC-15" ], - "51(1)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" + "9.2.1": [ + "IAC-15" ], - "51(2)": [ - "PRI-01", - "PRI-05.7", - "OPS-01", - "OPS-01.1", - "TPM-01" + "9.2.1.1": [ + "IAC-15" ], - "51(3)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" + "9.2.1.2": [ + "IAC-15" ], - "51(4)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" + "9.2.1.3": [ + "IAC-15" ], - "51(5)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" + "9.2.1.4": [ + "IAC-15" ], - "51(6)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" + "9.2.1.5": [ + "IAC-15" ], - "17(1)": [ - "PRI-02" + "9.2.1.6.PB": [ + "IAC-15" ], - "17(2)": [ - "PRI-02" + "9.2.4.9.PB": [ + "IAC-15" ], - "17(3)": [ - "PRI-02" + "9.2.2.5": [ + "IAC-15.1" ], - "17(4)": [ - "PRI-02" + "9.2.3": [ + "IAC-16" ], - "13(1)": [ - "PRI-03", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "9.2.3.1": [ + "IAC-16" ], - "13(2)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "9.2.3.2": [ + "IAC-16" ], - "13(3)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "9.2.3.3": [ + "IAC-16" ], - "13(4)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "9.2.3.4": [ + "IAC-16" ], - "13(5)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "9.2.3.5": [ + "IAC-16" ], - "13(6)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "9.2.3.6": [ + "IAC-16" ], - "13(7)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "9.2.3.7": [ + "IAC-16" ], - "47(1)": [ - "PRI-05", - "PRI-06.5" + "9.2.3.8": [ + "IAC-16" ], - "47(2)": [ - "PRI-05", - "PRI-06.5" + "9.2.3.9": [ + "IAC-16" ], - "47(3)": [ - "PRI-05", - "PRI-06.5" + "9.2.3.10": [ + "IAC-16" ], - "47(4)": [ - "PRI-05", - "PRI-06.5" + "9.2.2.7": [ + "IAC-17" ], - "38(3)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "TPM-01", - "TPM-04", - "TPM-04.4", - "TPM-05" + "9.2.5": [ + "IAC-17" ], - "55(1)": [ - "RSK-10" + "9.2.5.1": [ + "IAC-17" ], - "55(2)": [ - "RSK-10" + "9.2.5.2": [ + "IAC-17" ], - "55(3)": [ - "RSK-10" + "9.2.5.3": [ + "IAC-17" ], - "55(4)": [ - "RSK-10" + "9.2.5.4": [ + "IAC-17" ], - "55(5)": [ - "RSK-10" + "9.2.5.5": [ + "IAC-17" ], - "56(1)": [ - "RSK-10" + "9.2.5.6": [ + "IAC-17" ], - "56(2)": [ - "RSK-10" + "9.4.4": [ + "IAC-20.3" ], - "56(3)": [ - "RSK-10" - ] - }, - "apac-hkg-pdo-2022": { - "Principle 4": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "9.4.4.1": [ + "IAC-20.3" ], - "Sec 33": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "9.4.4.2": [ + "IAC-20.3" ], - "Sec 22": [ - "DCH-22.1", - "PRI-06.1" + "9.4.4.3": [ + "IAC-20.3" ], - "Inferred": [ - "PRI-01" + "9.4.4.4": [ + "IAC-20.3" ], - "Expectation": [ - "PRI-01" + "9.4.4.5": [ + "IAC-20.3" ], - "Principle 1": [ - "PRI-02.1" + "9.4.4.6": [ + "IAC-20.3" ], - "Principle 2": [ - "PRI-05" + "9.4.4.7": [ + "IAC-20.3" ], - "Sec 26": [ - "PRI-05" + "9.4.4.8": [ + "IAC-20.3" ], - "Principle 3": [ - "PRI-05" + "9.4.4.9": [ + "IAC-20.3" ], - "Sec 4": [ - "PRI-05" + "9.4.4.10.P": [ + "IAC-20.3" ], - "Principle 6": [ - "PRI-06" + "9.4.4.11.P": [ + "IAC-20.3" ], - "Sec 17A": [ - "PRI-06" + "9.2.6.1": [ + "IAC-20.6" ], - "Sec 18": [ - "PRI-06" + "9.1.2": [ + "IAC-21" ], - "Sec 15": [ - "PRI-15" - ] - }, - "apac-ind-dpdpa-2023": { - "8(6)": [ - "GOV-01.1", - "IRO-04.1", - "IRO-09", - "IRO-10" + "9.1.2.1": [ + "IAC-21" ], - "18(2)": [ - "GOV-01.1" + "9.1.2.2": [ + "IAC-21" ], - "23(1)": [ - "GOV-01.1" + "9.1.2.3": [ + "IAC-21" ], - "26(a)": [ - "GOV-01.1" + "9.1.2.4": [ + "IAC-21" ], - "26(b)": [ - "GOV-01.1" + "9.1.2.5": [ + "IAC-21" ], - "26(c)": [ - "GOV-01.1" + "9.1.2.6": [ + "IAC-21" ], - "27(1)(a)": [ - "GOV-01.1" + "9.1.2.7": [ + "IAC-21" ], - "27(1)(b)": [ - "GOV-01.1" + "9.1.2.8": [ + "IAC-21" ], - "27(1)(c)": [ - "GOV-01.1" + "7.1.1.4": [ + "IAC-28" ], - "27(1)(d)": [ - "GOV-01.1" + "9.2.2.1": [ + "IAC-28.1" ], - "27(1)(e)": [ - "GOV-01.1" + "16.1": [ + "IRO-01" ], - "27(2)": [ - "GOV-01.1" + "16.1.1.2": [ + "IRO-01" ], - "27(3)": [ - "GOV-01.1" + "16.1.1.4": [ + "IRO-01" ], - "28(1)": [ - "GOV-01.1" + "16.1.1.5": [ + "IRO-01" ], - "28(2)": [ - "GOV-01.1" + "16.1.1.6.P": [ + "IRO-01" ], - "28(3)": [ - "GOV-01.1" + "16.1.1.7.P": [ + "IRO-01" ], - "28(4)": [ - "GOV-01.1" + "16.1.1.8.P": [ + "IRO-01" ], - "28(5)": [ - "GOV-01.1" + "16.1.1.9.P": [ + "IRO-01" ], - "28(6)": [ - "GOV-01.1" + "16.1.1.10.P": [ + "IRO-01" ], - "10(2)(c)(ii)": [ - "GOV-01.2", - "CPL-02.2" + "16.1.1.11.P": [ + "IRO-01" ], - "19(3)": [ - "GOV-04" + "16.1.1.12.P": [ + "IRO-01" ], - "7(c)": [ - "CPL-01" + "16.1.1": [ + "IRO-02" ], - "7(d)": [ - "CPL-01" + "16.1.1.1": [ + "IRO-02" ], - "7(e)": [ - "CPL-01" + "16.1.1.3": [ + "IRO-02" ], - "8(1)": [ - "CPL-01", - "PRI-05.4" + "16.1.2": [ + "IRO-02" ], - "8(4)": [ - "CPL-01", - "PRI-01.6" + "16.1.2.1": [ + "IRO-02" ], - "10(2)(b)": [ - "CPL-02.1", - "CPL-03.1" + "16.1.2.2": [ + "IRO-02" ], - "13(1)": [ - "CPL-07" + "16.1.2.3": [ + "IRO-02" ], - "13(2)": [ - "CPL-07.1" + "16.1.2.4": [ + "IRO-02" ], - "8(7)(a)": [ - "DCH-09.3", - "DCH-18", - "PRI-03.4", - "PRI-06.5" + "16.1.2.5": [ + "IRO-02" ], - "8(8)": [ - "DCH-18" + "16.1.2.6": [ + "IRO-02" ], - "21(1)(a)": [ - "HRS-01" + "16.1.2.7": [ + "IRO-02" ], - "21(1)(b)": [ - "HRS-01" + "16.1.2.8": [ + "IRO-02" ], - "21(1)(c)": [ - "HRS-01" + "16.1.2.9": [ + "IRO-02" ], - "21(1)(d)": [ - "HRS-01" + "16.1.2.10": [ + "IRO-02" ], - "21(1)(e)": [ - "HRS-01" + "16.1.2.11.P": [ + "IRO-02" ], - "21(2)": [ - "HRS-01" + "16.1.2.12.P": [ + "IRO-02" ], - "22(1)": [ - "HRS-01" + "16.1.2.13.P": [ + "IRO-02" ], - "22(2)": [ - "HRS-01" + "16.1.3": [ + "IRO-02" ], - "22(3)": [ - "HRS-01" + "16.1.3.1": [ + "IRO-02" ], - "6(9)": [ - "HRS-03" + "16.1.3.2": [ + "IRO-02" ], - "10(2)(a)(iv)": [ - "HRS-03", - "PRI-01.4" + "16.1.5.9": [ + "IRO-02" ], - "10(2)(a)": [ - "PRI-01.4" + "16.1.4": [ + "IRO-02.4" ], - "8(5)": [ - "PRI-01.6" + "16.1.4.1": [ + "IRO-02.4" ], - "5(3)": [ - "PRI-01.8" + "16.1.4.2": [ + "IRO-02.4" ], - "8(9)": [ - "PRI-01.8" + "16.1.5": [ + "IRO-04" ], - "8(10)": [ - "PRI-01.8" + "16.1.5.1": [ + "IRO-04" ], - "8(11)": [ - "PRI-01.8" + "16.1.5.2": [ + "IRO-04" ], - "10(2)": [ - "PRI-01.8" + "16.1.5.3": [ + "IRO-04" ], - "10(2)(a)(i)": [ - "PRI-01.8" + "16.1.5.4": [ + "IRO-04" ], - "10(2)(a)(ii)": [ - "PRI-01.8" + "16.1.5.5": [ + "IRO-04" ], - "10(2)(a)(iii)": [ - "PRI-01.8" + "16.1.5.6": [ + "IRO-04" ], - "6(8)": [ - "PRI-01.9" + "16.1.5.7": [ + "IRO-04" ], - "5(1)(i)": [ - "PRI-02", - "PRI-02.1" + "16.1.5.8": [ + "IRO-04" ], - "5(1)(ii)": [ - "PRI-02" + "16.1.1.14": [ + "IRO-04.3" ], - "5(1)(iii)": [ - "PRI-02" + "16.1.7": [ + "IRO-08" ], - "5(2)(a)(i)": [ - "PRI-02", - "PRI-02.1" + "16.1.7.1": [ + "IRO-08" ], - "5(2)(a)(ii)": [ - "PRI-02" + "16.1.7.2": [ + "IRO-08" ], - "5(2)(a)(iii)": [ - "PRI-02" + "16.1.7.3": [ + "IRO-08" ], - "6(3)": [ - "PRI-02", - "PRI-03" + "16.1.7.4": [ + "IRO-08" ], - "6(10)": [ - "PRI-02", - "PRI-03" + "16.1.7.5": [ + "IRO-08" ], - "4(2)": [ - "PRI-02.1" + "16.1.7.6": [ + "IRO-08" ], - "7(a)": [ - "PRI-02.1", - "PRI-03" + "16.1.7.7": [ + "IRO-08" ], - "8(8)(a)": [ - "PRI-02.1" + "16.1.7.8": [ + "IRO-08" ], - "4(1)(a)": [ - "PRI-03" + "16.1.7.9": [ + "IRO-08" ], - "6(1)": [ - "PRI-03" + "16.1.7.10": [ + "IRO-08" ], - "6(7)": [ - "PRI-03", - "PRI-03.4", - "PRI-03.6" + "16.1.7.11": [ + "IRO-08" ], - "7(b)(i)": [ - "PRI-03" + "16.1.7.12": [ + "IRO-08" ], - "8(8)(b)": [ - "PRI-03", - "PRI-03.4" + "16.1.7.13.PB": [ + "IRO-08" ], - "5(2)(b)": [ - "PRI-03.4", - "PRI-03.9" + "16.1.5.10": [ + "IRO-09.2" ], - "6(4)": [ - "PRI-03.4" + "6.1.3.2": [ + "IRO-10" ], - "9(1)": [ - "PRI-03.6" + "16.1.1.15.P": [ + "IRO-10.4" ], - "14(1)": [ - "PRI-03.6" + "16.1.6": [ + "IRO-13" ], - "9(2)": [ - "PRI-03.9" + "16.1.6.1": [ + "IRO-13" ], - "9(3)": [ - "PRI-03.9" + "16.1.6.2": [ + "IRO-13" ], - "6(6)": [ - "PRI-03.10" + "12.2.1.14": [ + "IRO-15" ], - "4(1)(b)": [ - "PRI-04.1" + "14.1.1.12": [ + "IAO-02" ], - "8(3)": [ - "PRI-05.2" + "14.1.1.17": [ + "IAO-02" ], - "8(3)(a)": [ - "PRI-05.2" + "14.1.1.18": [ + "IAO-02" ], - "8(3)(b)": [ - "PRI-05.2" + "14.2.7.4": [ + "IAO-02" ], - "7(f)": [ - "PRI-05.4" + "14.2.9": [ + "IAO-02" ], - "7(g)": [ - "PRI-05.4" + "14.2.9.1": [ + "IAO-02" ], - "7(h)": [ - "PRI-05.4" + "14.2.9.2": [ + "IAO-02" ], - "7(i)": [ - "PRI-05.4" + "14.2.9.3": [ + "IAO-02" ], - "11(1)(c)": [ - "PRI-06" + "14.2.9.4": [ + "IAO-02" ], - "11(2)": [ - "PRI-06" + "4.4.5.2": [ + "IAO-03", + "PRM-01.2", + "PRM-05", + "PRM-06" ], - "12(1)": [ - "PRI-06.1", - "PRI-06.5" + "13.2.2": [ + "IAO-03.2" ], - "12(2)(a)": [ - "PRI-06.1" + "13.2.2.2": [ + "IAO-03.2" ], - "12(2)(b)": [ - "PRI-06.1" + "13.2.2.3": [ + "IAO-03.2" ], - "12(3)": [ - "PRI-06.5" + "13.2.2.4": [ + "IAO-03.2" ], - "11(1)(a)": [ - "PRI-06.7" + "13.2.2.6": [ + "IAO-03.2" ], - "8(2)": [ - "PRI-07", - "PRI-07.1" + "13.2.2.7": [ + "IAO-03.2" ], - "8(7)(b)": [ - "PRI-07.1", - "TPM-05", - "TPM-05.2" + "13.2.2.8": [ + "IAO-03.2" ], - "12(2)(c)": [ - "PRI-12.1" + "13.2.2.9": [ + "IAO-03.2" ], - "11(1)(b)": [ - "PRI-14.1" + "13.2.2.10": [ + "IAO-03.2" ], - "10(2)(c)(i)": [ - "RSK-10" - ] - }, - "apac-ind-privacy-rules-2011": { - "5": [ - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05" + "13.2.2.11": [ + "IAO-03.2" ], - "7": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "4.4.6.1": [ + "IAO-05", + "RSK-01", + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-04.2", + "RSK-06.4" ], - "8": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "4.7.1.4": [ + "IAO-05", + "RSK-06.4" ], - "Inferred": [ - "PRI-01" + "4.7.1.7": [ + "IAO-05" ], - "Expectation": [ - "PRI-01" - ] - }, - "apac-ind-sebi-2024": { - "GV.OC.S1": [ - "GOV-01", - "GOV-04.2", - "GOV-09" + "11.2.4": [ + "MNT-01" ], - "GV.OC.S2": [ - "GOV-01", - "CPL-01" + "11.2.4.1": [ + "MNT-01" ], - "PR.IP.S17": [ - "GOV-01", - "CPL-01.3", - "SEA-01" + "11.2.4.3": [ + "MNT-01" ], - "GV.OV.S2": [ - "GOV-01.1" + "11.2.4.5": [ + "MNT-01" ], - "GV.RR.S1": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1", - "GOV-14" + "11.2.4.4": [ + "MNT-02" ], - "GV.RR.S3": [ - "GOV-01.1", - "GOV-04" + "11.2.5": [ + "MNT-04.3" ], - "GV.RR.S4": [ - "GOV-01.1", - "PRM-01", - "PRM-01.1", - "PRM-03" + "11.2.5.1": [ + "MNT-04.3" ], - "GV.OV.S1": [ - "GOV-01.2" + "11.2.5.2": [ + "MNT-04.3" ], - "GV.PO.S1": [ - "GOV-02" + "11.2.5.3": [ + "MNT-04.3" ], - "GV.PO.S3": [ - "GOV-02.1", - "GOV-03" + "11.2.5.4": [ + "MNT-04.3" ], - "GV.PO.S2": [ - "GOV-03" + "11.2.4.8": [ + "MNT-05" ], - "GV.PO.S4": [ - "GOV-03" + "11.2.4.9": [ + "MNT-05" ], - "GV.RR.S2": [ - "GOV-04", - "GOV-04.1", - "HRS-02", - "HRS-03" + "11.2.4.10": [ + "MNT-05" ], - "GV.PO.S5": [ - "GOV-04.2", - "AST-01", - "AST-01.2", - "AST-03" + "11.2.4.7": [ + "MNT-05.1", + "MNT-05.5" ], - "GV.OV.S3": [ - "GOV-05" + "11.2.4.11": [ + "MNT-05.4" ], - "GV.OV.S4": [ - "GOV-05" + "11.2.4.2": [ + "MNT-06" ], - "PR.IP.S10": [ - "GOV-05" + "11.2.6": [ + "MNT-09" ], - "GV.RM.S1": [ - "GOV-09", - "RSK-01" + "11.2.6.1": [ + "MNT-09" ], - "GV.RM.S2": [ - "GOV-15" + "11.2.6.2": [ + "MNT-09" ], - "ID.AM.S1": [ - "AST-02" + "11.2.6.3": [ + "MNT-09" ], - "ID.AM.S5": [ - "AST-02", - "DCH-06.2" + "11.2.6.4": [ + "MNT-09" ], - "ID.AM.S6": [ - "AST-02" + "11.2.6.5": [ + "MNT-09" ], - "ID.AM.S2": [ - "AST-02.8", - "AST-04" + "11.2.6.6": [ + "MNT-09" ], - "PR.AA.S14": [ - "AST-09", - "DCH-01", - "DCH-06", - "OPS-01.1" + "11.2.4.6": [ + "MNT-10" ], - "PR.IP.S11": [ - "BCD-01", - "BCD-04" + "6.2.1.23": [ + "MDM-06" ], - "RC.RP.S1": [ - "BCD-01", - "BCD-01.5" + "5.1.1.18": [ + "NET-01" ], - "RC.RP.S4": [ - "BCD-01", - "BCD-11", - "OPS-01.1" + "13.1": [ + "NET-01" ], - "RS.MA.S3": [ - "BCD-01", - "IRO-04" + "13.1.1": [ + "NET-01" ], - "GV.SC.S6": [ - "BCD-01.2", - "IRO-02.5" + "13.1.1.1": [ + "NET-01" ], - "RC.RP.S2": [ - "BCD-01.4" + "13.1.1.2": [ + "NET-01" ], - "ID.AM.S4": [ - "BCD-02", - "IAO-01" + "13.1.1.3": [ + "NET-01" ], - "GV.RM.S3": [ - "BCD-04", - "IRO-04", - "IRO-06" + "13.1.1.5": [ + "NET-01" ], - "RC.IM.S2": [ - "BCD-04", - "BCD-05" + "13.1.1.6": [ + "NET-01" ], - "RC.RP.S3": [ - "BCD-04" + "13.1.1.7": [ + "NET-01" ], - "RC.IM.S1": [ - "BCD-05", - "IRO-13" + "13.1.1.8": [ + "NET-01" ], - "RS.AN.S4": [ - "BCD-05", - "IRO-13" + "13.1.1.9": [ + "NET-01" ], - "RS.AN.S4a": [ - "BCD-05", - "IRO-13" + "13.1.2": [ + "NET-01", + "PRM-06", + "TPM-05" ], - "RS.AN.S4b": [ - "BCD-05", - "IRO-13" + "9.1.1.16": [ + "NET-01.1" ], - "RS.IM.S1": [ - "BCD-05", - "IRO-13" + "14.1.1.23": [ + "NET-03.3" ], - "PR.IP.S7": [ - "BCD-11", - "BCD-12", - "OPS-01.1" + "13.1.1.10": [ + "NET-05.2" ], - "PR.IP.S8": [ - "BCD-11", - "BCD-11.1" + "13.1.3": [ + "NET-06" ], - "PR.DS.S3": [ - "CAP-01" + "13.1.3.1": [ + "NET-06" ], - "DE.CM.S4": [ - "CAP-04" + "13.1.3.2": [ + "NET-06" ], - "PR.IP.S3": [ - "CHG-01", - "CHG-02", - "CFG-01" + "13.1.3.3": [ + "NET-06" ], - "PR.MA.S1": [ - "CHG-02.2", - "MNT-02" + "13.1.3.4": [ + "NET-06" ], - "PR.IP.S13": [ - "CLD-01", - "CLD-02", - "CPL-01" + "13.1.3.5": [ + "NET-06" ], - "PR.AA.S17": [ - "CLD-04" + "13.1.3.6": [ + "NET-06" ], - "PR.DS.S2": [ - "CLD-09", - "DCH-02", - "DCH-26" + "13.1.3.7": [ + "NET-06" ], - "RS.MA.S5": [ - "CPL-01", - "IRO-02.5" + "13.1.3.8": [ + "NET-06" ], - "EV.ST.S4": [ - "CPL-02", - "RSK-06.2", - "THR-03" + "13.1.3.9": [ + "NET-06" ], - "DE.CM.S5": [ - "CPL-02.2", - "CPL-03.2", - "CFG-03.1" + "13.1.3.10.P": [ + "NET-06" ], - "EV.ST.S5": [ - "CPL-03" + "13.1.3.11.P": [ + "NET-06" ], - "PR.IP.S14": [ - "CPL-03.1" + "13.1.3.12.P": [ + "NET-06" ], - "PR.IP.S1": [ - "CFG-02", - "CFG-02.1", - "CFG-03" + "13.1.4.P": [ + "NET-06", + "NET-06.1", + "NET-06.2", + "NET-06.3" ], - "PR.DS.S6": [ - "CFG-06", - "CFG-06.1", - "END-06", - "END-06.1" + "13.1.1.4": [ + "NET-12" ], - "DE.CM.S2": [ - "MON-01" + "14.1.2": [ + "NET-12" ], - "PR.AA.S8": [ - "MON-01" + "14.1.2.1": [ + "NET-12" ], - "DE.CM.S3": [ - "MON-01.8", - "MON-17" + "14.1.2.2": [ + "NET-12" ], - "PR.AA.S9": [ - "MON-03", - "MON-08", - "MON-10" + "14.1.2.3": [ + "NET-12" ], - "PR.DS.S1": [ - "CRY-01", - "CRY-03", - "CRY-05" + "14.1.2.4": [ + "NET-12" ], - "PR.DS.S4": [ - "DCH-01", - "NET-03.5", - "NET-17" + "14.1.2.5": [ + "NET-12" ], - "PR.AA.S13": [ - "DCH-18", - "DCH-21" + "14.1.2.6": [ + "NET-12" ], - "PR.IP.S4": [ - "END-04", - "END-04.7" + "14.1.2.7": [ + "NET-12" ], - "GV.RR.S6": [ - "HRS-01", - "HRS-03.1", - "SAT-01" + "14.1.2.8": [ + "NET-12" ], - "RS.CO.S1": [ - "HRS-01", - "HRS-02", - "HRS-03" + "14.1.2.9": [ + "NET-12" ], - "DE.DP.S1": [ - "HRS-02", - "HRS-03" + "14.1.2.10": [ + "NET-12" ], - "PR.AT.S4": [ - "HRS-02", - "HRS-03", - "HRS-03.1" + "14.1.2.11": [ + "NET-12" ], - "PR.AT.S5": [ - "HRS-03", - "HRS-03.1" + "14.1.2.12": [ + "NET-12" ], - "GV.RR.S5": [ - "HRS-06", - "HRS-06.1" + "14.1.2.13": [ + "NET-12" ], - "PR.AA.S3": [ - "HRS-11", - "IAC-08", - "IAC-21" + "14.1.2.14": [ + "NET-12" ], - "PR.AA.S1": [ - "IAC-01", - "IAC-15" + "14.1.2.15": [ + "NET-12" ], - "PR.AA.S6": [ - "IAC-01", - "IAC-10" + "13.2.2.12": [ + "NET-13" ], - "PR.AA.S15": [ - "IAC-01", - "IAC-20" + "13.2.2.13": [ + "NET-13" ], - "PR.AA.S7": [ - "IAC-06" + "13.2.3": [ + "NET-13" ], - "PR.AA.S11": [ - "IAC-16", - "IAC-21.4" + "13.2.3.1": [ + "NET-13" ], - "PR.AA.S5": [ - "IAC-17" + "13.2.3.2": [ + "NET-13" ], - "RS.MA.S1": [ - "IRO-01", - "IRO-04" + "13.2.3.3": [ + "NET-13" ], - "RS.MA.S2": [ - "IRO-02" + "13.2.3.4": [ + "NET-13" ], - "RS.AN.S2": [ - "IRO-02.4" + "13.2.3.5": [ + "NET-13" ], - "RS.CO.S3": [ - "IRO-02.5", - "IRO-09", - "IRO-10", - "IRO-10.4" + "13.2.3.6": [ + "NET-13" ], - "DE.DP.S2": [ - "IRO-04", - "IRO-06" + "13.2.3.7.P": [ + "NET-13" ], - "EV.ST.S3": [ - "IRO-04.2", - "IRO-13" + "6.2": [ + "NET-14.5" ], - "RS.IM.S2": [ - "IRO-04.2", - "IRO-05" + "6.2.2": [ + "NET-14.5" ], - "RS.AN.S3": [ - "IRO-08", - "IRO-13" + "6.2.2.1": [ + "NET-14.5" ], - "DE.DP.S3": [ - "IRO-10", - "IRO-10.2" + "6.2.2.2": [ + "NET-14.5" ], - "RC.CO.S2": [ - "IRO-10" + "6.2.2.3": [ + "NET-14.5" ], - "RC.CO.S3": [ - "IRO-10" + "6.2.2.4": [ + "NET-14.5" ], - "RS.CO.S2": [ - "IRO-10", - "IRO-10.2" + "6.2.2.5": [ + "NET-14.5" ], - "RS.AN.S5": [ - "IRO-13" + "6.2.2.6": [ + "NET-14.5" ], - "RC.CO.S1": [ - "IRO-16" + "6.2.2.7": [ + "NET-14.5" ], - "PR.AA.S16": [ - "IAO-01", - "IAO-02" + "6.2.2.8": [ + "NET-14.5" ], - "PR.MA.S2": [ - "MNT-05", - "MNT-05.5" + "6.2.2.9": [ + "NET-14.5" ], - "PR.AA.S2": [ - "NET-01", - "NET-06" + "6.2.2.10": [ + "NET-14.5" ], - "PR.AA.S4": [ - "NET-01.1" + "6.2.2.11": [ + "NET-14.5" ], - "ID.AM.S3": [ - "NET-04.11", - "OPS-07" + "6.2.2.12": [ + "NET-14.5" ], - "PR.AA.S12": [ - "NET-14" + "6.2.2.13": [ + "NET-14.5" ], - "PR.AA.S10": [ - "PES-01", - "PES-03", - "PES-03.4", - "PES-05" + "6.2.2.14": [ + "NET-14.5" ], - "PR.IP.S9": [ - "PES-01", - "PES-01.1" + "6.2.2.15": [ + "NET-14.5" ], - "PR.IP.S2": [ - "PRM-07" + "6.2.2.16": [ + "NET-14.5" ], - "GV.RM.S4": [ - "RSK-01.3", - "RSK-01.5", - "RSK-04.1" + "6.2.2.17": [ + "NET-14.5" ], - "ID.RA.S1": [ - "RSK-04", - "VPM-06" + "6.2.2.18": [ + "NET-14.5" ], - "ID.RA.S2": [ - "RSK-04" + "6.2.2.19": [ + "NET-14.5" ], - "ID.RA.S5": [ - "RSK-06" + "6.2.2.20": [ + "NET-14.5" ], - "EV.ST.S1": [ - "RSK-06.2", - "THR-01", - "THR-03" + "6.2.2.21": [ + "NET-14.5" ], - "GV.SC.S7": [ - "RSK-09.1" + "5.1.1.11": [ + "PES-01" ], - "EV.ST.S2": [ - "SEA-13" + "11.1": [ + "PES-01" ], - "DE.CM.S1": [ - "OPS-04" + "11.1.4": [ + "PES-01" ], - "PR.AT.S1": [ - "SAT-01" + "11.1.4.1": [ + "PES-01" ], - "PR.AT.S2": [ - "SAT-03", - "SAT-03.5" + "11.2.1.3": [ + "PES-01" ], - "GV.SC.S5": [ - "TDA-04.2" + "11.1.2.3": [ + "PES-02" ], - "PR.IP.S5": [ - "TDA-04.2", - "TPM-05.6" + "11.1.2.12": [ + "PES-02" ], - "PR.DS.S5": [ - "TDA-08" + "11.1.1": [ + "PES-03" ], - "PR.IP.S6": [ - "TDA-09" + "11.1.1.1": [ + "PES-03" ], - "GV.OC.S3": [ - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-03", - "TPM-05", - "TPM-05.4" + "11.1.1.2": [ + "PES-03" ], - "GV.SC.S1": [ - "TPM-01", - "TPM-01.1", - "TPM-02", - "TPM-03" + "11.1.1.3": [ + "PES-03" ], - "PR.IP.S15": [ - "TPM-01", - "TPM-05.8" + "11.1.1.4": [ + "PES-03" ], - "GV.SC.S2": [ - "TPM-01.1", - "TPM-02" + "11.1.1.5": [ + "PES-03" ], - "GV.SC.S3": [ - "TPM-05", - "TPM-05.2", - "TPM-05.4", - "TPM-05.7" + "11.1.1.6": [ + "PES-03" ], - "GV.SC.S8": [ - "TPM-05", - "TPM-05.2" + "11.1.1.7": [ + "PES-03" ], - "PR.AT.S3": [ - "TPM-05", - "TPM-05.4", - "TPM-06" + "11.1.2": [ + "PES-03" ], - "PR.IP.S16": [ - "TPM-05.8" + "11.1.2.1": [ + "PES-03" ], - "GV.SC.S4": [ - "TPM-08", - "TPM-09", - "TPM-10" + "11.1.2.2": [ + "PES-03" ], - "ID.RA.S3": [ - "THR-03" + "11.1.2.5": [ + "PES-03" ], - "RS.AN.S1": [ - "THR-03", - "THR-03.1" + "11.1.2.10": [ + "PES-03" ], - "DE.DP.S5": [ - "THR-07" + "11.1.2.7": [ + "PES-03.3" ], - "ID.RA.S4": [ - "THR-10" + "11.1.2.6": [ + "PES-04" ], - "PR.IP.S12": [ - "VPM-01" + "11.1.3": [ + "PES-04" ], - "PR.MA.S3": [ - "VPM-02", - "VPM-03", - "VPM-05" + "11.1.3.1": [ + "PES-04" ], - "DE.DP.S4": [ - "VPM-10" - ] - }, - "apac-jpn-ppi-2020": { - "19": [ - "PRI-05", - "PRI-05.2" + "11.1.3.2": [ + "PES-04" ], - "20": [ - "GOV-01", - "CPL-01", - "DCH-01", - "DCH-24", - "PRI-01.6", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "11.1.3.3": [ + "PES-04" ], - "21": [ - "CPL-01", - "CPL-02", - "DCH-01.1", - "HRS-01", - "HRS-03", - "HRS-05.1", - "HRS-06", - "HRS-06.1", - "PRI-01.1", - "PRI-01.6" + "11.1.3.4": [ + "PES-04" ], - "22": [ - "CPL-01", - "IAO-03.2", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "11.2.9": [ + "PES-04" ], - "31": [ - "PRI-06.3", - "PRI-06.4" + "11.2.9.1": [ + "PES-04" ], - "34": [ - "PRI-06.5" + "11.2.9.2": [ + "PES-04" ], - "36": [ - "CPL-01", - "PRI-01" + "11.2.9.3": [ + "PES-04" ], - "37": [ - "CPL-01", - "DCH-23", - "IAC-09.6", - "PRI-01" + "11.2.9.4": [ + "PES-04" ], - "38": [ - "CPL-01", - "DCH-23", - "IAC-09.6", - "PRI-01" + "11.2.9.5": [ + "PES-04" ], - "39": [ - "CPL-01", - "DCH-23", - "IAC-09.6", - "PRI-01" + "11.2.9.6": [ + "PES-04" ], - "54": [ - "CPL-01", - "PRI-01" + "11.1.2.11": [ + "PES-04.1" ], - "55": [ - "CPL-01", - "PRI-01" + "11.1.5": [ + "PES-04.1" ], - "24(1)": [ - "CLD-09", - "DCH-19", - "DCH-25", - "PRI-03" + "11.1.5.1": [ + "PES-04.1" ], - "26(1)": [ - "CPL-01", - "DCH-22.1", - "PRI-01", - "PRI-06.1", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.5.2": [ + "PES-04.1" ], - "26(1)(i)": [ - "CPL-01", - "DCH-22.1", - "PRI-01", - "PRI-06.1", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.5.3": [ + "PES-04.1" ], - "26(1)(ii)": [ - "CPL-01", - "DCH-22.1", - "PRI-01", - "PRI-06.1", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.5.4": [ + "PES-04.1" ], - "26(2)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.5.5": [ + "PES-04.1" ], - "26(3)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.5.6": [ + "PES-04.1" ], - "26(4)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.2.13": [ + "PES-05" ], - "26-2(1)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.2.4": [ + "PES-06" ], - "26-2(1)(i)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.2.8": [ + "PES-06.1" ], - "26-2(1)(ii)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.1.2.9": [ + "PES-06.3" ], - "26-2(2)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.2.2": [ + "PES-07" ], - "26-2(3)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "11.2.2.1": [ + "PES-07" ], - "51(1)": [ - "CPL-01", - "PRI-01" + "11.2.2.2": [ + "PES-07" ], - "51(2)": [ - "CPL-01", - "PRI-01" + "11.2.2.3": [ + "PES-07" ], - "52(1)": [ - "CPL-01", - "PRI-01" + "11.2.2.4": [ + "PES-07" ], - "53(2)": [ - "CPL-01", - "PRI-01" + "11.2.2.5": [ + "PES-07" ], - "53(3)": [ - "CPL-01", - "PRI-01" + "11.2.2.7": [ + "PES-07.2" ], - "53(1)": [ - "CPL-01", - "PRI-01" + "11.2.2.6": [ + "PES-07.4" ], - "53(4)": [ - "CPL-01", - "PRI-01" + "11.1.6": [ + "PES-10" ], - "40(1)": [ - "CPL-01.1", - "CPL-03" + "11.1.6.1": [ + "PES-10" ], - "40(2)": [ - "CPL-01.1", - "CPL-03" + "11.1.6.2": [ + "PES-10" ], - "40(3)": [ - "CPL-01.1", - "CPL-03" + "11.1.6.3": [ + "PES-10" ], - "29(1)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "11.1.6.4": [ + "PES-10" ], - "29(2)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "11.1.6.5": [ + "PES-10" ], - "29(3)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "11.1.6.6": [ + "PES-10" ], - "17(1)": [ - "DCH-22.3", - "PRI-04", - "PRI-04.1" + "11.1.6.7": [ + "PES-10" ], - "35-2(1)": [ - "DCH-23", - "IAC-09.6" + "11.2": [ + "PES-12" ], - "35-2(2)": [ - "DCH-23", - "IAC-09.6" + "11.2.1": [ + "PES-12" ], - "35-2(3)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.1": [ + "PES-12" ], - "35-2(4)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.2": [ + "PES-12" ], - "35-2(5)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.4": [ + "PES-12" ], - "35-2(6)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.5": [ + "PES-12" ], - "35-2(7)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.6": [ + "PES-12" ], - "35-2(8)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.7": [ + "PES-12" ], - "35-2(9)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.8": [ + "PES-12" ], - "36(1)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.9": [ + "PES-12" ], - "36(2)": [ - "DCH-23", - "IAC-09.6" + "11.2.1.10": [ + "PES-12" ], - "36(3)": [ - "DCH-23", - "IAC-09.6" + "11.2.7.4.PB": [ + "PES-12" ], - "36(4)": [ - "DCH-23", - "IAC-09.6" + "11.2.3": [ + "PES-12.1" ], - "22-2(1)": [ - "IRO-04.1" + "11.2.3.1": [ + "PES-12.1" ], - "22-2(2)": [ - "IRO-04.1" + "11.2.3.2": [ + "PES-12.1" ], - "24(3)": [ - "PRI-01", - "TPM-01", - "TPM-08", - "TPM-10" + "11.2.3.3": [ + "PES-12.1" ], - "15(1)": [ - "PRI-02", - "PRI-02.1" + "5.1.1.19": [ + "PRI-01" ], - "15(2)": [ - "PRI-02", - "PRI-02.1" + "18.1.4": [ + "PRI-01", + "PRI-01.11" ], - "16(1)": [ - "PRI-03" + "7.1.1.12": [ + "PRI-01.11" ], - "16(3)(i)": [ - "PRI-03", - "PRI-03.2", - "PRI-03.6" + "18.1.4.1": [ + "PRI-01.11" ], - "16(3)(ii)": [ - "PRI-03", - "PRI-03.2", - "PRI-03.6" + "18.1.4.2": [ + "PRI-01.11" ], - "16(3)(iii)": [ - "PRI-03", - "PRI-03.2", - "PRI-03.6" + "18.1.4.3": [ + "PRI-01.11" ], - "16(3)(iv)": [ - "PRI-03", - "PRI-03.2", - "PRI-03.6" + "18.1.4.4": [ + "PRI-01.11" ], - "24(2)": [ - "PRI-03" + "18.1.4.5": [ + "PRI-01.11" ], - "16(2)": [ - "PRI-03.2" + "18.1.4.6": [ + "PRI-01.11" ], - "17(2)": [ - "PRI-04.1" + "4.5.1.1": [ + "PRM-01", + "PRM-02", + "PRM-04", + "PRM-05", + "PRM-06" ], - "17(2)(i)": [ - "PRI-04.1" + "5.1.1.2": [ + "PRM-01.1" ], - "17(2)(ii)": [ - "PRI-04.1" + "4.5.5.3": [ + "PRM-02", + "PRM-02.1", + "PRM-03" ], - "17(2)(iii)": [ - "PRI-04.1" + "4.5.1.2": [ + "PRM-03" ], - "17(2)(iv)": [ - "PRI-04.1" + "6.1.5": [ + "PRM-04" ], - "17(2)(v)": [ - "PRI-04.1" + "6.1.5.1": [ + "PRM-04" ], - "17(2)(vi)": [ - "PRI-04.1" + "4.4.3.1": [ + "PRM-05", + "PRM-06" ], - "18(1)": [ - "PRI-04.4" + "6.1.5.2": [ + "PRM-05" ], - "18(2)": [ - "PRI-04.4" + "14.1.1.2": [ + "PRM-05", + "PRM-06", + "TDA-02" ], - "18(4)(i)": [ - "PRI-04.4", - "PRI-06.2" + "6.1.5.5": [ + "PRM-06" ], - "18(4)(ii)": [ - "PRI-04.4", - "PRI-06.2" + "6.1.5.4": [ + "PRM-07" ], - "18(4)(iii)": [ - "PRI-04.4", - "PRI-06.2" + "14.1": [ + "PRM-07" ], - "18(4)(iv)": [ - "PRI-04.4", - "PRI-06.2" + "4.5.5.2": [ + "RSK-01", + "RSK-06.4" ], - "16-2": [ - "PRI-05.1", - "PRI-05.4" + "4.4.7.2": [ + "RSK-01.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-04.1" ], - "27(1)": [ - "PRI-06" + "4.4.7.3": [ + "RSK-01.1", + "RSK-04", + "RSK-04.3", + "RSK-08" ], - "27(1)(i)": [ - "PRI-06" + "4.4.7.1": [ + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-04", + "RSK-04.2", + "RSK-06.3", + "RSK-06.4" ], - "27(1)(ii)": [ - "PRI-06" + "6.1.5.3": [ + "RSK-04" ], - "27(1)(iii)": [ - "PRI-06" + "4.5.5.1": [ + "RSK-04.3" ], - "27(1)(iv)": [ - "PRI-06" + "4.4.8.1": [ + "RSK-06.1", + "RSK-06.2", + "RSK-06.3", + "RSK-06.4" ], - "27(2)(i)": [ - "PRI-06" + "4.4.8.2": [ + "RSK-06.1", + "RSK-06.2", + "RSK-06.3", + "RSK-06.4" ], - "27(2)(ii)": [ - "PRI-06" + "4.4.8.5": [ + "RSK-06.1", + "RSK-06.4" ], - "27(3)": [ - "PRI-06", - "PRI-06.4" + "4.7.1.3": [ + "RSK-06.1" ], - "28(1)": [ - "PRI-06" + "4.7.1.6": [ + "RSK-06.1" ], - "28(2)": [ - "PRI-06", - "PRI-06.4" + "4.4.8.3": [ + "RSK-06.4" ], - "28(2)(i)": [ - "PRI-06", - "PRI-06.4" + "4.4.8.4": [ + "RSK-06.4" ], - "28(2)(ii)": [ - "PRI-06", - "PRI-06.4" + "4.9": [ + "RSK-06.4", + "THR-03", + "THR-03.1" ], - "28(2)(iii)": [ - "PRI-06", - "PRI-06.4" + "14.2.5": [ + "SEA-01" ], - "28(3)": [ - "PRI-06", - "PRI-06.4" + "14.2.5.1": [ + "SEA-01" ], - "28(4)": [ - "PRI-06", - "PRI-06.4" + "14.2.5.2": [ + "SEA-01" ], - "28(5)": [ - "PRI-06", - "PRI-06.4" + "14.2.5.3": [ + "SEA-01" ], - "18(3)": [ - "PRI-06.2" + "14.2.5.4": [ + "SEA-01" ], - "32(1)": [ - "PRI-06.4" + "14.2.5.5": [ + "SEA-01" ], - "32(2)": [ - "PRI-06.4" + "14.2.5.6": [ + "SEA-01" ], - "32(3)": [ - "PRI-06.4" + "14.2.5.7": [ + "SEA-01" ], - "32(4)": [ - "PRI-06.4" + "4.5.4.5": [ + "SEA-02.2" ], - "30(1)": [ - "PRI-06.5" + "9.5.P": [ + "SEA-05" ], - "30(2)": [ - "PRI-06.5" + "12.4.4": [ + "SEA-20" ], - "30(3)": [ - "PRI-06.5" + "12.4.4.1": [ + "SEA-20" ], - "30(4)": [ - "PRI-06.5" + "12.4.4.2": [ + "SEA-20" ], - "30(5)": [ - "PRI-06.5" + "12.4.4.3": [ + "SEA-20" ], - "30(6)": [ - "PRI-06.5" + "12.4.4.4.PB": [ + "SEA-20" ], - "30(7)": [ - "PRI-06.5" + "12.1": [ + "OPS-01" ], - "33(1)": [ - "PRI-06.5" + "12.1.3.9.PB": [ + "OPS-01" ], - "33(2)": [ - "PRI-06.5" + "8.3.1.11": [ + "OPS-01.1" ], - "34(1)": [ - "PRI-06.5" + "12.1.1": [ + "OPS-01.1" ], - "34(2)": [ - "PRI-06.5" + "12.1.1.1": [ + "OPS-01.1" ], - "34(3)": [ - "PRI-06.5" + "12.1.1.2": [ + "OPS-01.1" ], - "35(1)": [ - "PRI-06.5" + "12.1.1.3": [ + "OPS-01.1" ], - "35(2)": [ - "PRI-06.5" + "12.1.1.4": [ + "OPS-01.1" ], - "23(1)(i)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.5": [ + "OPS-01.1" ], - "23(1)(ii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.6": [ + "OPS-01.1" ], - "23(1)(iii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.7": [ + "OPS-01.1" ], - "23(1)(iv)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.8": [ + "OPS-01.1" ], - "23(2)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.9": [ + "OPS-01.1" ], - "23(2)(i)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.10": [ + "OPS-01.1" ], - "23(2)(ii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.11": [ + "OPS-01.1" ], - "23(2)(iii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.12": [ + "OPS-01.1" ], - "23(2)(iv)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.1.13": [ + "OPS-01.1" ], - "23(2)(v)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.5.P": [ + "OPS-01.1" ], - "23(2)(vi)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "12.1.5.1.PB": [ + "OPS-01.1" ], - "23(2)(vii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "13.1.1.11.P": [ + "OPS-03" ], - "23(2)(viii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "13.1.4.1.P": [ + "OPS-03" ], - "23(3)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "13.1.4.2.P": [ + "OPS-03" ], - "23(4)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "14.1.1.19.P": [ + "OPS-03" ], - "23(5)(i)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "14.1.1.20.P": [ + "OPS-03" ], - "23(5)(ii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "7.2.2.1": [ + "SAT-01" ], - "23(5)(iii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "7.2.2.2": [ + "SAT-01" ], - "23(6)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "7.2.2.3": [ + "SAT-01" ], - "23(1)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" + "7.2.2.4": [ + "SAT-01" ], - "25(1)": [ - "PRI-14.1" + "7.2.2.5": [ + "SAT-01" ], - "25(2)": [ - "PRI-14.1" - ] - }, - "apac-jpn-ismap": { - "5": [ - "GOV-02" + "7.2.2.6": [ + "SAT-01" ], - "6": [ - "GOV-02" + "7.2.2.17": [ + "SAT-01" ], - "7": [ - "HRS-01" + "7.2.2.18": [ + "SAT-01" ], - "8": [ - "AST-01" + "4.5.2.4": [ + "SAT-01.1", + "SAT-03", + "SAT-03.7", + "SAT-04" ], - "9": [ - "IAC-01" + "4.5.2.5": [ + "SAT-01.1", + "SAT-04" ], - "10": [ - "CRY-01" + "6.2.1.20": [ + "SAT-02" ], - "11": [ - "PES-01" + "7.2.2": [ + "SAT-02" ], - "12": [ - "OPS-01" + "7.2.2.7": [ + "SAT-02" ], - "13": [ - "NET-01" + "7.2.2.8": [ + "SAT-02" ], - "14": [ - "TDA-01" + "7.2.2.9": [ + "SAT-02" ], - "15": [ - "TPM-01" + "7.2.2.10": [ + "SAT-02" ], - "16": [ - "IRO-01" + "7.2.2.11": [ + "SAT-02" ], - "17": [ - "BCD-01" + "7.2.2.12": [ + "SAT-02" ], - "18": [ - "CPL-01" + "7.2.2.13": [ + "SAT-02" ], - "4.4.1.1": [ - "GOV-01", - "GOV-01.1" + "7.2.2.15": [ + "SAT-02" ], - "4.4.1.2": [ - "GOV-01", - "GOV-04" + "7.2.2.25": [ + "SAT-02" ], - "4.4.2.1": [ - "GOV-01", - "CPL-01" + "7.2.1.6": [ + "SAT-03" ], - "4.5.4.1": [ - "GOV-01" + "7.2.2.14": [ + "SAT-03" ], - "4.5.4.2": [ - "GOV-01" + "7.2.2.19.PB": [ + "SAT-03", + "SAT-03.3" ], - "4.8.1.1": [ - "GOV-01", - "RSK-01" + "7.2.2.16": [ + "SAT-03.3" ], - "4.8.2.2": [ - "GOV-01" + "14.2": [ + "TDA-01" ], - "5.1": [ - "GOV-01" + "14.2.1": [ + "TDA-01" ], - "5.1.1": [ - "GOV-01", - "GOV-02", - "GOV-03", - "PRI-01", - "PRI-01.3" + "14.2.1.13.PB": [ + "TDA-01" ], - "6.1": [ - "GOV-01" + "14.2.7": [ + "TDA-01" ], - "4.4.1.3": [ - "GOV-01.1" + "14.1.1": [ + "TDA-01.1" ], - "4.4.5.3": [ - "GOV-01.1", - "GOV-02" + "14.2.7.11": [ + "TDA-01.1" ], - "4.5.3.1": [ - "GOV-01.1", - "GOV-03", - "GOV-17", - "SAT-03", - "TPM-01" + "14.1.1.3": [ + "TDA-02" ], - "4.6.3.1": [ - "GOV-01.1" + "14.1.1.4": [ + "TDA-02" ], - "4.6.3.2": [ - "GOV-01.1" + "14.1.1.5": [ + "TDA-02" ], - "4.6.3.3": [ - "GOV-01.1", - "GOV-01.3" + "14.1.1.6": [ + "TDA-02" ], - "4.6.1.1": [ - "GOV-01.2", - "GOV-01.3", - "CPL-01.1", - "CPL-02", - "RSK-04", - "RSK-06" + "14.1.1.7": [ + "TDA-02" ], - "4.6.1.2": [ - "GOV-01.3" + "14.1.1.8": [ + "TDA-02" ], - "4.4.5.1": [ - "GOV-02" + "14.1.1.9": [ + "TDA-02" ], - "4.5.2.1": [ - "GOV-02", - "GOV-14", - "GOV-15" + "14.1.1.10": [ + "TDA-02" ], - "4.8.2.1": [ - "GOV-02", - "GOV-03" + "14.1.1.11": [ + "TDA-02" ], - "5.1.1.1": [ - "GOV-02" + "14.1.1.16": [ + "TDA-02" ], - "5.1.1.8": [ - "GOV-02" + "14.2.1.3": [ + "TDA-02" ], - "5.1.1.21": [ - "GOV-02" + "14.1.1.15": [ + "TDA-04" ], - "6.2.1": [ - "GOV-02", - "END-02" + "14.2.7.10": [ + "TDA-04" ], - "5.1.1.7": [ - "GOV-02.1" + "14.1.1.1": [ + "TDA-06" ], - "4.7.1.5": [ - "GOV-03" + "14.2.1.2": [ + "TDA-06" ], - "5.1.2": [ - "GOV-03" + "14.2.1.9": [ + "TDA-06" ], - "5.1.2.2": [ - "GOV-03" + "14.2.1.10": [ + "TDA-06" ], - "5.1.2.3": [ - "GOV-03" + "14.2.7.3": [ + "TDA-06.2" ], - "5.1.2.4": [ - "GOV-03" + "14.2.1.1": [ + "TDA-07" ], - "5.1.1.6": [ - "GOV-04" + "14.2.6": [ + "TDA-07" ], - "5.1.2.1": [ - "GOV-04" + "14.2.6.1": [ + "TDA-07" ], - "4.6.2.1": [ - "GOV-05" + "14.2.6.2": [ + "TDA-07" ], - "6.1.3": [ - "GOV-06" + "14.2.6.3": [ + "TDA-07" ], - "6.1.3.1": [ - "GOV-06" + "14.2.6.4": [ + "TDA-07" ], - "6.1.3.3.PB": [ - "GOV-06" + "14.2.6.5": [ + "TDA-07" ], - "6.1.4": [ - "GOV-07" + "14.2.6.6": [ + "TDA-07" ], - "6.1.4.1": [ - "GOV-07" + "14.2.6.7": [ + "TDA-07" ], - "6.1.4.2": [ - "GOV-07" + "14.2.6.8": [ + "TDA-07" ], - "6.1.4.3": [ - "GOV-07", - "THR-03" + "14.2.6.9": [ + "TDA-07" ], - "6.1.4.4": [ - "GOV-07" + "14.2.6.10": [ + "TDA-07" ], - "6.1.4.5": [ - "GOV-07" + "14.2.6.11": [ + "TDA-07", + "TDA-08.1" ], - "6.1.4.6": [ - "GOV-07" + "14.2.6.12": [ + "TDA-07" ], - "4.4.4.1": [ - "GOV-09", - "GOV-15", - "GOV-15.1", - "AST-04.1", - "CPL-01.2" + "12.1.4": [ + "TDA-08" ], - "5.1.1.5": [ - "GOV-09" + "12.1.4.1": [ + "TDA-08" ], - "7.2.1.8": [ - "GOV-14" + "12.1.4.2": [ + "TDA-08" ], - "18.1.2": [ - "AAT-12", - "AST-02.7" + "12.1.4.3": [ + "TDA-08" ], - "18.1.2.13.PB": [ - "AAT-12", - "CPL-07" + "12.1.4.4": [ + "TDA-08" ], - "8.1": [ - "AST-01" + "12.1.4.5": [ + "TDA-08" ], - "8.1.1.1": [ - "AST-01" + "12.1.4.6": [ + "TDA-08" ], - "8.1.1.6.PB": [ - "AST-01" + "12.1.4.7": [ + "TDA-08" ], - "8.1.1": [ - "AST-02" + "12.1.4.8": [ + "TDA-08" ], - "8.1.1.2": [ - "AST-02" + "12.1.4.9": [ + "TDA-08" ], - "8.1.1.3": [ - "AST-02" + "14.2.1.4": [ + "TDA-09" ], - "8.1.1.4": [ - "AST-02" + "14.2.7.5": [ + "TDA-09" ], - "8.1.2.3": [ - "AST-02" + "14.2.7.6": [ + "TDA-09" ], - "14.2.7.1": [ - "AST-02.7", - "TPM-05" + "14.2.7.7": [ + "TDA-09" ], - "18.1.2.1": [ - "AST-02.7" + "14.2.8": [ + "TDA-09" ], - "18.1.2.2": [ - "AST-02.7" + "14.2.8.1": [ + "TDA-09" ], - "18.1.2.3": [ - "AST-02.7" + "14.2.8.2": [ + "TDA-09" ], - "18.1.2.4": [ - "AST-02.7" + "14.2.8.3": [ + "TDA-09" ], - "18.1.2.5": [ - "AST-02.7" + "14.3": [ + "TDA-10" ], - "18.1.2.6": [ - "AST-02.7" + "14.3.1": [ + "TDA-10" ], - "18.1.2.7": [ - "AST-02.7" + "14.3.1.1": [ + "TDA-10" ], - "18.1.2.8": [ - "AST-02.7" + "14.3.1.2": [ + "TDA-10" ], - "18.1.2.9": [ - "AST-02.7" + "14.3.1.3": [ + "TDA-10" ], - "18.1.2.10": [ - "AST-02.7" + "14.3.1.4": [ + "TDA-10" ], - "18.1.2.11": [ - "AST-02.7" + "14.3.1.5": [ + "TDA-10" ], - "18.1.2.12": [ - "AST-02.7" + "14.3.1.6": [ + "TDA-10" ], - "8.1.1.5": [ - "AST-03" + "14.2.5.9": [ + "TDA-18" ], - "8.1.2": [ - "AST-03" + "9.4.5": [ + "TDA-20" ], - "8.1.2.1": [ - "AST-03" + "9.4.5.1": [ + "TDA-20" ], - "8.1.2.2": [ - "AST-03" + "9.4.5.2": [ + "TDA-20" ], - "4.4.4": [ - "AST-04", - "AST-04.1", - "CPL-01.2", - "IAO-03" + "9.4.5.3": [ + "TDA-20" ], - "8.1.2.4": [ - "AST-04.1" + "9.4.5.4": [ + "TDA-20" ], - "8.3": [ - "AST-05" + "9.4.5.5": [ + "TDA-20" ], - "8.3.1": [ - "AST-05" + "9.4.5.6": [ + "TDA-20" ], - "8.3.1.2": [ - "AST-05.1" + "9.4.5.7": [ + "TDA-20" ], - "13.2.2.1": [ - "AST-05.1" + "9.4.5.8": [ + "TDA-20" ], - "6.2.1.18": [ - "AST-06" + "9.4.5.9": [ + "TDA-20" ], - "6.2.1.19": [ - "AST-06" + "14.2.1.5": [ + "TDA-20" ], - "8.2.3.5": [ - "AST-06" + "14.2.1.6": [ + "TDA-20.1" ], - "11.2.8": [ - "AST-06" + "14.2.7.8": [ + "TDA-20.3" ], - "11.2.8.1": [ - "AST-06" + "5.1.1.20": [ + "TPM-01" ], - "11.2.8.2": [ - "AST-06" + "5.1.1.31.P": [ + "TPM-01" ], - "11.2.8.3": [ - "AST-06" + "15.1": [ + "TPM-01" ], - "11.2.8.4": [ - "AST-06" + "15.1.1": [ + "TPM-01" ], - "8.1.2.6": [ - "AST-09" + "15.1.1.1": [ + "TPM-01" ], - "8.3.1.1": [ - "AST-09" + "15.1.1.2": [ + "TPM-01" ], - "8.3.2": [ - "AST-09" + "15.1.1.3": [ + "TPM-01" ], - "8.3.2.1": [ - "AST-09" + "15.1.1.4": [ + "TPM-01" ], - "8.3.2.2": [ - "AST-09" + "15.1.1.5": [ + "TPM-01" ], - "8.3.2.3": [ - "AST-09" + "15.1.1.6": [ + "TPM-01" ], - "11.2.7": [ - "AST-09" + "15.1.1.7": [ + "TPM-01" ], - "11.2.7.1": [ - "AST-09" + "15.1.1.8": [ + "TPM-01" ], - "11.2.7.2": [ - "AST-09" + "15.1.1.9": [ + "TPM-01" ], - "8.1.4": [ - "AST-10" + "15.1.1.10": [ + "TPM-01" ], - "5.1.1.13": [ - "BCD-01" + "15.1.1.11": [ + "TPM-01" ], - "17.1": [ - "BCD-01" + "15.1.1.12": [ + "TPM-01" ], - "17.1.1": [ - "BCD-01" + "15.1.1.13": [ + "TPM-01" ], - "17.1.1.1": [ - "BCD-01" + "15.1.1.14.B": [ + "TPM-01" ], - "17.1.1.2": [ - "BCD-01" + "14.1.1.14": [ + "TPM-04.1" ], - "17.1.1.3": [ - "BCD-01" + "15.1.1.16.B": [ + "TPM-04.1" ], - "17.1.1.4": [ - "BCD-01" + "6.3.P": [ + "TPM-05" ], - "17.1.3": [ - "BCD-01" + "7.1.1.11": [ + "TPM-05" ], - "17.1.3.1": [ - "BCD-01" + "8.2.3.7": [ + "TPM-05" ], - "17.1.3.4": [ - "BCD-01" + "13.1.2.2": [ + "TPM-05" ], - "12.2.1.10": [ - "BCD-01.7" + "14.1.1.13": [ + "TPM-05" ], - "12.2.1.11": [ - "BCD-01.7" + "14.2.1.12": [ + "TPM-05" ], - "17.1.2": [ - "BCD-01.7" + "14.2.7.2": [ + "TPM-05" ], - "17.1.2.1": [ - "BCD-01.7" + "14.2.7.9": [ + "TPM-05" ], - "17.1.2.2": [ - "BCD-01.7" + "15.1.2": [ + "TPM-05" ], - "17.1.2.3": [ - "BCD-01.7" + "15.1.2.1": [ + "TPM-05" ], - "17.1.2.4": [ - "BCD-01.7" + "15.1.2.2": [ + "TPM-05" ], - "17.1.2.5": [ - "BCD-01.7" + "15.1.2.3": [ + "TPM-05" ], - "17.1.2.6": [ - "BCD-01.7" + "15.1.2.4": [ + "TPM-05" ], - "17.1.3.2": [ - "BCD-04" + "15.1.2.5": [ + "TPM-05" ], - "17.1.3.3": [ - "BCD-04" + "15.1.2.6": [ + "TPM-05" ], - "17.2": [ - "BCD-09" + "15.1.2.7": [ + "TPM-05" ], - "17.2.1": [ - "BCD-09" + "15.1.2.8": [ + "TPM-05" ], - "17.2.1.1": [ - "BCD-09" + "15.1.2.9": [ + "TPM-05" ], - "17.2.1.2": [ - "BCD-09" + "15.1.2.10": [ + "TPM-05" ], - "17.2.1.3": [ - "BCD-09" + "15.1.2.11": [ + "TPM-05" ], - "12.3": [ - "BCD-11" + "15.1.2.12": [ + "TPM-05" ], - "12.3.1": [ - "BCD-11" + "15.1.2.13": [ + "TPM-05" ], - "12.3.1.1": [ - "BCD-11" + "15.1.2.14": [ + "TPM-05" ], - "12.3.1.2": [ - "BCD-11" + "15.1.2.15": [ + "TPM-05" ], - "12.3.1.3": [ - "BCD-11" + "15.1.2.16": [ + "TPM-05" ], - "12.3.1.4": [ - "BCD-11" + "15.1.2.17": [ + "TPM-05" ], - "12.3.1.5": [ - "BCD-11" + "15.1.2.18.PB": [ + "TPM-05" ], - "12.3.1.11": [ - "BCD-11" + "15.1.3": [ + "TPM-05" ], - "12.3.1.12": [ - "BCD-11" + "15.1.3.1": [ + "TPM-05" ], - "12.3.1.13": [ - "BCD-11" + "15.1.3.2": [ + "TPM-05" ], - "12.3.1.14": [ - "BCD-11" + "15.1.3.3": [ + "TPM-05" ], - "12.3.1.16.P": [ - "BCD-11" + "15.1.3.4": [ + "TPM-05" ], - "12.3.1.17.P": [ - "BCD-11" + "15.1.3.5": [ + "TPM-05" ], - "12.3.1.18.P": [ - "BCD-11" + "15.1.3.6": [ + "TPM-05" ], - "12.3.1.21.P": [ - "BCD-11" + "15.1.3.7": [ + "TPM-05" ], - "12.3.1.24.P": [ - "BCD-11" + "15.1.3.8": [ + "TPM-05" ], - "8.3.1.7": [ - "BCD-11.2" + "15.1.3.9": [ + "TPM-05" ], - "12.3.1.6": [ - "BCD-11.2" + "15.1.3.10.P": [ + "TPM-05" ], - "12.3.1.7": [ - "BCD-11.2" + "15.1.3.11.P": [ + "TPM-05" ], - "12.3.1.23.P": [ - "BCD-11.2" + "15.2": [ + "TPM-05" ], - "12.3.1.8": [ - "BCD-11.5" + "6.1.1.8": [ + "TPM-05.4" ], - "12.3.1.9": [ - "BCD-11.5" + "6.1.1.9": [ + "TPM-05.4" ], - "12.3.1.10": [ - "BCD-11.5" + "6.1.1.10": [ + "TPM-05.4" ], - "12.3.1.20.P": [ - "BCD-11.5" + "6.1.1.11": [ + "TPM-05.4" ], - "12.3.1.22.P": [ - "BCD-11.5" + "6.1.1.12": [ + "TPM-05.4" ], - "12.1.3": [ - "CAP-01" + "6.1.5.6": [ + "TPM-05.4" ], - "12.1.3.1": [ - "CAP-01" + "6.3.1.P": [ + "TPM-05.4" ], - "12.1.3.2": [ - "CAP-01" + "13.1.2.1": [ + "TPM-08" ], - "12.1.3.3": [ - "CAP-01" + "15.2.1": [ + "TPM-08" ], - "12.1.3.4": [ - "CAP-01" + "15.2.1.1": [ + "TPM-08" ], - "12.1.3.5": [ - "CAP-01" + "15.2.1.2": [ + "TPM-08" ], - "12.1.3.6": [ - "CAP-01" + "15.2.1.3": [ + "TPM-08" ], - "12.1.3.7": [ - "CAP-01" + "15.2.1.4": [ + "TPM-08" ], - "12.1.3.8": [ - "CAP-01" + "15.2.1.5": [ + "TPM-08" ], - "4.5.4.4": [ - "CHG-01" + "15.2.1.6": [ + "TPM-08" ], - "12.1.2": [ - "CHG-01" + "15.2.1.7": [ + "TPM-08" ], - "12.1.2.1": [ - "CHG-01" + "15.2.1.8": [ + "TPM-08" ], - "12.1.2.11.PB": [ - "CHG-01" + "15.2.1.9": [ + "TPM-08" ], - "12.1.2.2": [ - "CHG-02" + "15.2.1.10": [ + "TPM-08" ], - "12.1.2.3": [ - "CHG-02" + "15.2.1.11": [ + "TPM-08" ], - "12.1.2.4": [ - "CHG-02" + "15.2.1.12": [ + "TPM-08" ], - "12.1.2.5": [ - "CHG-02" + "15.2.1.13": [ + "TPM-08" ], - "12.1.2.6": [ - "CHG-02" + "15.2.1.14": [ + "TPM-10" ], - "12.1.2.7": [ - "CHG-02" + "15.2.1.15": [ + "TPM-10" ], - "12.1.2.8": [ - "CHG-02" + "15.2.2": [ + "TPM-10" ], - "12.1.2.9": [ - "CHG-02" + "15.2.2.1": [ + "TPM-10" ], - "12.1.2.13": [ - "CHG-02" + "15.2.2.2": [ + "TPM-10" ], - "12.1.2.14": [ - "CHG-02" + "15.2.2.3": [ + "TPM-10" ], - "12.5.1.4": [ - "CHG-02" + "5.1.1.4": [ + "THR-01" ], - "12.5.1.6": [ - "CHG-02" + "4.9.2.2": [ + "THR-03", + "THR-03.1" ], - "12.5.1.7": [ - "CHG-02" + "12.2.1.12": [ + "THR-03" ], - "12.5.1.8": [ - "CHG-02" + "12.2.1.13": [ + "THR-03" ], - "12.5.1.10": [ - "CHG-02" + "4.9.1.1": [ + "THR-03.1" ], - "12.5.1.11": [ - "CHG-02" + "4.9.2.1": [ + "THR-03.1" ], - "12.5.1.12": [ - "CHG-02" + "5.1.1.16": [ + "VPM-01" ], - "12.5.1.13": [ - "CHG-02" + "12.6": [ + "VPM-01" ], - "12.5.1.14": [ - "CHG-02" + "12.6.1": [ + "VPM-01" ], - "12.5.1.15": [ - "CHG-02" + "12.6.1.1": [ + "VPM-01" ], - "12.5.1.16": [ - "CHG-02" + "12.6.1.2": [ + "VPM-01" ], - "12.5.1.17": [ - "CHG-02" + "12.6.1.3": [ + "VPM-01" ], - "12.5.1.18": [ - "CHG-02" + "12.6.1.4": [ + "VPM-01" ], - "14.2.2": [ - "CHG-02" + "12.6.1.5": [ + "VPM-01" ], - "14.2.2.1": [ - "CHG-02" + "12.6.1.6": [ + "VPM-01" ], - "14.2.2.2": [ - "CHG-02" + "12.6.1.7": [ + "VPM-01" ], - "14.2.2.3": [ - "CHG-02" + "12.6.1.8": [ + "VPM-01" ], - "14.2.2.4": [ - "CHG-02" + "12.6.1.9": [ + "VPM-01" ], - "14.2.2.5": [ - "CHG-02" + "12.6.1.11": [ + "VPM-01" ], - "14.2.2.6": [ - "CHG-02" + "12.6.1.12": [ + "VPM-01" ], - "14.2.2.7": [ - "CHG-02" + "12.6.1.13": [ + "VPM-01" ], - "14.2.2.8": [ - "CHG-02" + "12.6.1.15": [ + "VPM-01" ], - "14.2.2.9": [ - "CHG-02" + "12.6.1.16": [ + "VPM-01" ], - "14.2.2.10": [ - "CHG-02" + "12.6.1.17": [ + "VPM-01" ], - "14.2.2.11": [ - "CHG-02" + "12.6.1.18.PB": [ + "VPM-01" ], - "14.2.2.12": [ - "CHG-02" + "12.6.1.14": [ + "VPM-02" ], - "14.2.2.13": [ - "CHG-02" + "12.6.1.10": [ + "VPM-05" + ] + }, + "apac-mys-pdpa-2010": { + "8": [ + "PRI-05.4" ], - "14.2.2.14": [ - "CHG-02" + "11": [ + "PRI-05.2" ], - "14.2.2.15": [ - "CHG-02" + "12": [ + "PRI-06" ], - "14.2.2.16": [ - "CHG-02" + "33": [ + "PRI-06.4" ], - "14.2.2.17": [ - "CHG-02" + "39": [ + "PRI-05.4" ], - "14.2.4.7": [ - "CHG-02" + "129(1)": [ + "PRI-01.5" ], - "14.2.4.8": [ - "CHG-02" + "129(2)": [ + "PRI-01.5" ], - "14.2.4.9": [ - "CHG-02" + "129(2)(a)": [ + "PRI-01.5" ], - "14.2.4.10": [ - "CHG-02" + "129(2)(b)": [ + "PRI-01.5" ], - "14.2.4": [ - "CHG-02.1" + "129(3)": [ + "PRI-01.5" ], - "14.2.4.1": [ - "CHG-02.1" + "129(3)(a)": [ + "PRI-01.5" ], - "14.2.4.2": [ - "CHG-02.1" + "129(3)(b)": [ + "PRI-01.5" ], - "14.2.4.3": [ - "CHG-02.1" + "129(3)(c)": [ + "PRI-01.5" ], - "14.2.4.4": [ - "CHG-02.1" + "129(3)(c)(i)": [ + "PRI-01.5" ], - "14.2.4.5": [ - "CHG-02.1" + "129(3)(c)(ii)": [ + "PRI-01.5" ], - "14.2.4.6": [ - "CHG-02.1" + "129(3)(d)": [ + "PRI-01.5" ], - "12.1.2.10": [ - "CHG-02.2" + "129(3)(e)": [ + "PRI-01.5" ], - "12.5.1.5": [ - "CHG-02.2" + "129(3)(e)(i)": [ + "PRI-01.5" ], - "12.5.1.9": [ - "CHG-02.2" + "129(3)(e)(ii)": [ + "PRI-01.5" ], - "14.2.3": [ - "CHG-02.2" + "129(3)(e)(iii)": [ + "PRI-01.5" ], - "14.2.3.1": [ - "CHG-02.2" + "129(3)(f)": [ + "PRI-01.5" ], - "14.2.3.2": [ - "CHG-02.2" + "129(3)(g)": [ + "PRI-01.5" ], - "14.2.3.3": [ - "CHG-02.2" + "129(3)(h)": [ + "PRI-01.5" ], - "5.1.1.22.P": [ - "CLD-01" + "129(4)": [ + "PRI-01.5" ], - "5.1.1.23.P": [ - "CLD-01" + "129(4)(a)": [ + "PRI-01.5" ], - "5.1.1.24.P": [ - "CLD-01" + "129(4)(b)": [ + "PRI-01.5" ], - "5.1.1.25.P": [ - "CLD-01" + "9(1)": [ + "PRI-01.6" ], - "5.1.1.26.P": [ - "CLD-01" + "9(1)(a)": [ + "PRI-01.6" ], - "5.1.1.27.P": [ - "CLD-01" + "9(1)(b)": [ + "PRI-01.6" ], - "5.1.1.28.P": [ - "CLD-01" + "9(1)(c)": [ + "PRI-01.6" ], - "5.1.1.29.P": [ - "CLD-01" + "9(1)(d)": [ + "PRI-01.6" ], - "5.1.1.30.P": [ - "CLD-01" + "9(1)(e)": [ + "PRI-01.6" ], - "8.1.5.P": [ - "CLD-01.2" + "9(2)": [ + "PRI-01.6" ], - "8.1.5.1.P": [ - "CLD-01.2" + "9(2)(a)": [ + "PRI-01.6" ], - "8.1.5.2.P": [ - "CLD-01.2" + "9(2)(b)": [ + "PRI-01.6" ], - "8.1.5.3.P": [ - "CLD-01.2" + "5(1)": [ + "PRI-01.11" ], - "8.1.5.4.P": [ - "CLD-01.2" + "5(1)(a)": [ + "PRI-01.11" ], - "8.1.2.7.PB": [ - "CLD-02" + "5(1)(b)": [ + "PRI-01.11" ], - "9.2.3.11.PB": [ - "CLD-02" + "5(1)(c)": [ + "PRI-01.11" ], - "9.5.1.P": [ - "CLD-06" + "5(1)(d)": [ + "PRI-01.11" ], - "9.5.1.1.P": [ - "CLD-06" + "5(1)(e)": [ + "PRI-01.11" ], - "9.5.1.2.P": [ - "CLD-06" + "5(1)(f)": [ + "PRI-01.11" ], - "9.5.1.3.P": [ - "CLD-06" + "5(1)(g)": [ + "PRI-01.11" ], - "9.5.1.4.P": [ - "CLD-06" + "130(1)": [ + "PRI-01.11" ], - "6.3.1.1.PB": [ - "CLD-06.1" + "130(1)(a)": [ + "PRI-01.11" ], - "5.1.1.3": [ - "CPL-01" + "130(1)(b)": [ + "PRI-01.11" ], - "18.1": [ - "CPL-01" + "130(2)": [ + "PRI-01.11" ], - "18.1.1": [ - "CPL-01" + "130(2)(a)": [ + "PRI-01.11" ], - "18.1.1.1": [ - "CPL-01" + "130(2)(a)(i)": [ + "PRI-01.11" ], - "18.1.1.2": [ - "CPL-01" + "130(2)(a)(ii)": [ + "PRI-01.11" ], - "18.1.1.3": [ - "CPL-01" + "130(2)(b)": [ + "PRI-01.11" ], - "18.1.1.4.P": [ - "CPL-01" + "130(2)(c)": [ + "PRI-01.11" ], - "18.1.1.5.P": [ - "CPL-01" + "130(2)(d)": [ + "PRI-01.11" ], - "18.1.1.6.P": [ - "CPL-01" + "130(3)": [ + "PRI-01.11" ], - "18.1.1.7.P": [ - "CPL-01" + "130(4)": [ + "PRI-01.11" ], - "18.1.5.7.PB": [ - "CPL-01" + "130(5)": [ + "PRI-01.11" ], - "4.7.1.1": [ - "CPL-01.1", - "RSK-06", - "RSK-06.4" + "130(5)(a)": [ + "PRI-01.11" ], - "4.7.1.2": [ - "CPL-01.1" + "130(5)(b)": [ + "PRI-01.11" ], - "4.5.4.3": [ - "CPL-01.3", - "CPL-01.4" + "130(6)": [ + "PRI-01.11" ], - "18.2.1.11.P": [ - "CPL-01.3" + "7(1)": [ + "PRI-02" ], - "18.2.1.12.P": [ - "CPL-01.3" + "7(1)(a)": [ + "PRI-02" ], - "4.6.2.2": [ - "CPL-01.4", - "CPL-02", - "CPL-02.1" + "7(1)(b)": [ + "PRI-02" ], - "4.6.2.6": [ - "CPL-02" + "7(1)(c)": [ + "PRI-02" ], - "12.7": [ - "CPL-02" + "7(1)(d)": [ + "PRI-02" ], - "12.7.1.8": [ - "CPL-02" + "7(1)(e)": [ + "PRI-02" ], - "12.7.1.9": [ - "CPL-02" + "7(1)(f)": [ + "PRI-02" ], - "4.6.2.4": [ - "CPL-02.1" + "7(1)(g)": [ + "PRI-02" ], - "4.6.2.3": [ - "CPL-03" + "7(1)(h)": [ + "PRI-02" ], - "4.6.2.5": [ - "CPL-03", - "CPL-03.1" + "7(2)": [ + "PRI-02" ], - "12.7.1": [ - "CPL-03" + "7(2)(a)": [ + "PRI-02" ], - "12.7.1.1": [ - "CPL-03" + "7(2)(b)": [ + "PRI-02" ], - "12.7.1.2": [ - "CPL-03" + "7(2)(c)": [ + "PRI-02" ], - "12.7.1.3": [ - "CPL-03" + "7(2)(c)(i)": [ + "PRI-02" ], - "12.7.1.4": [ - "CPL-03" + "7(2)(c)(ii)": [ + "PRI-02" ], - "12.7.1.5": [ - "CPL-03" + "7(3)": [ + "PRI-03" ], - "12.7.1.6": [ - "CPL-03" + "38(1)": [ + "PRI-03.4" ], - "12.7.1.7": [ - "CPL-03" + "43(1)": [ + "PRI-03.4" ], - "18.2": [ - "CPL-03" + "38(2)": [ + "PRI-03.10" ], - "18.2.2": [ - "CPL-03" + "42(1)": [ + "PRI-03.10" ], - "18.2.2.1": [ - "CPL-03" + "42(1)(a)": [ + "PRI-03.10" ], - "18.2.2.2": [ - "CPL-03" + "10(1)": [ + "PRI-05" ], - "18.2.2.3": [ - "CPL-03" + "10(2)": [ + "PRI-05" ], - "18.2.2.4": [ - "CPL-03" + "6(1)(a)": [ + "PRI-05.4" ], - "18.2.2.5": [ - "CPL-03" + "6(2)": [ + "PRI-05.4" ], - "18.2.2.6": [ - "CPL-03" + "6(2)(a)": [ + "PRI-05.4" ], - "18.2.2.7": [ - "CPL-03" + "6(2)(b)": [ + "PRI-05.4" ], - "18.2.2.8": [ - "CPL-03" + "6(2)(c)": [ + "PRI-05.4" ], - "18.2.1": [ - "CPL-03.1" + "6(2)(d)": [ + "PRI-05.4" ], - "18.2.1.3": [ - "CPL-03.1" + "6(2)(e)": [ + "PRI-05.4" ], - "18.2.1.4": [ - "CPL-03.1" + "6(2)(f)": [ + "PRI-05.4" ], - "18.2.1.5": [ - "CPL-03.1" + "6(3)": [ + "PRI-05.4" ], - "18.2.1.6": [ - "CPL-03.1" + "6(3)(a)": [ + "PRI-05.4" ], - "18.2.1.7": [ - "CPL-03.1" + "6(3)(b)": [ + "PRI-05.4" ], - "18.2.1.8": [ - "CPL-03.1" + "6(3)(c)": [ + "PRI-05.4" ], - "18.2.1.9.P": [ - "CPL-03.1" + "8(a)": [ + "PRI-05.4" ], - "18.2.1.10.P": [ - "CPL-03.1" + "8(a)(i)": [ + "PRI-05.4" ], - "18.2.1.13.P": [ - "CPL-03.1" + "8(a)(ii)": [ + "PRI-05.4" ], - "18.2.3": [ - "CPL-03.2" + "8(b)": [ + "PRI-05.4" ], - "18.2.3.1": [ - "CPL-03.2" + "39(a)": [ + "PRI-05.4" ], - "18.2.3.2": [ - "CPL-03.2" + "39(b)": [ + "PRI-05.4" ], - "18.2.3.3": [ - "CPL-03.2" + "39(b)(i)": [ + "PRI-05.4" ], - "18.2.3.4": [ - "CPL-03.2" + "39(b)(ii)": [ + "PRI-05.4" ], - "18.2.3.5": [ - "CPL-03.2" + "39(c)": [ + "PRI-05.4" ], - "4.6.2.7": [ - "CPL-13.1", - "CPL-13.2" + "39(d)": [ + "PRI-05.4" + ], + "39(e)": [ + "PRI-05.4" ], - "8.3.1.9": [ - "CFG-02" + "40(1)": [ + "PRI-05.4" ], - "9.5.2.P": [ - "CFG-02.9" + "40(1)(a)": [ + "PRI-05.4" ], - "9.5.2.1.PB": [ - "CFG-02.9" + "40(1)(b)": [ + "PRI-05.4" ], - "12.5": [ - "CFG-05.2" + "40(1)(b)(i)": [ + "PRI-05.4" ], - "12.5.1": [ - "CFG-05.2" + "40(1)(b)(ii)": [ + "PRI-05.4" ], - "12.5.1.1": [ - "CFG-05.2" + "40(1)(b)(ii)(A)": [ + "PRI-05.4" ], - "12.5.1.2": [ - "CFG-05.2" + "40(1)(b)(ii)(B)": [ + "PRI-05.4" ], - "12.5.1.3": [ - "CFG-05.2" + "40(1)(b)(iii)": [ + "PRI-05.4" ], - "12.6.2": [ - "CFG-05.2" + "40(1)(b)(iv)": [ + "PRI-05.4" ], - "12.6.2.1": [ - "CFG-05.2" + "40(1)(b)(iv)(A)": [ + "PRI-05.4" ], - "12.6.2.2": [ - "CFG-05.2" + "40(1)(b)(iv)(B)": [ + "PRI-05.4" ], - "12.6.2.3": [ - "CFG-05.2" + "40(1)(b)(v)": [ + "PRI-05.4" ], - "12.6.2.4": [ - "CFG-05.2" + "40(1)(b)(vi)": [ + "PRI-05.4" ], - "12.4": [ - "MON-01" + "40(1)(b)(vii)": [ + "PRI-05.4" ], - "12.4.1": [ - "MON-01" + "40(1)(b)(viii)": [ + "PRI-05.4" ], - "12.4.1.15.PB": [ - "MON-01" + "40(1)(b)(ix)": [ + "PRI-05.4" ], - "12.4.3.3": [ - "MON-01.8" + "40(1)(b)(x)": [ + "PRI-05.4" ], - "12.4.5.P": [ - "MON-01.8" + "40(1)(c)": [ + "PRI-05.4" ], - "12.4.5.1.P": [ - "MON-01.8" + "42(1)(b)": [ + "PRI-05.4" ], - "12.4.5.2.P": [ - "MON-01.8" + "42(1)(b)(A)": [ + "PRI-05.4" ], - "12.4.5.3.P": [ - "MON-01.8" + "42(1)(b)(B)": [ + "PRI-05.4" ], - "12.4.5.4.P": [ - "MON-01.8" + "42(2)": [ + "PRI-05.4" ], - "12.4.5.5.P": [ - "MON-01.8" + "42(2)(a)": [ + "PRI-05.4" ], - "6.1.3.5": [ - "MON-02.6" + "42(2)(b)": [ + "PRI-05.4" ], - "6.1.4.7": [ - "MON-02.6" + "42(2)(b)(i)": [ + "PRI-05.4" ], - "12.4.1.1": [ - "MON-03" + "42(2)(b)(ii)": [ + "PRI-05.4" ], - "12.4.1.2": [ - "MON-03" + "42(2)(b)(iii)": [ + "PRI-05.4" ], - "12.4.1.3": [ - "MON-03" + "42(2)(b)(iv)": [ + "PRI-05.4" ], - "12.4.1.4": [ - "MON-03" + "42(2)(c)": [ + "PRI-05.4" ], - "12.4.1.5": [ - "MON-03" + "42(3)": [ + "PRI-05.4" ], - "12.4.1.6": [ - "MON-03" + "42(3)(a)": [ + "PRI-05.4" ], - "12.4.1.7": [ - "MON-03" + "42(3)(b)": [ + "PRI-05.4" ], - "12.4.1.8": [ - "MON-03" + "42(4)": [ + "PRI-05.4" ], - "12.4.1.9": [ - "MON-03" + "42(5)": [ + "PRI-05.4" ], - "12.4.1.10": [ - "MON-03" + "30(1)": [ + "PRI-06" ], - "12.4.1.11": [ - "MON-03" + "30(2)(a)": [ + "PRI-06" ], - "12.4.1.12": [ - "MON-03" + "30(2)(b)": [ + "PRI-06" ], - "12.4.1.13": [ - "MON-03" + "34(1)(a)": [ + "PRI-06" ], - "12.4.1.14": [ - "MON-03" + "34(1)(b)": [ + "PRI-06" ], - "12.4.1.17": [ - "MON-03" + "34(2)": [ + "PRI-06" ], - "12.4.1.18": [ - "MON-03" + "35(1)": [ + "PRI-06.1" ], - "12.4.3": [ - "MON-03.3" + "35(1)(a)": [ + "PRI-06.1" ], - "12.4.3.1": [ - "MON-03.3" + "35(1)(b)": [ + "PRI-06.1" ], - "12.4.2": [ - "MON-08" + "35(1)(c)": [ + "PRI-06.1" ], - "12.4.2.1": [ - "MON-08" + "35(1)(c)(i)": [ + "PRI-06.1" ], - "12.4.2.2": [ - "MON-08" + "35(1)(c)(ii)": [ + "PRI-06.1" ], - "12.4.2.3": [ - "MON-08" + "35(2)": [ + "PRI-06.1" ], - "12.4.3.2": [ - "MON-08" + "35(2)(a)": [ + "PRI-06.1" ], - "5.1.1.17": [ - "CRY-01" + "35(2)(b)": [ + "PRI-06.1" ], - "10.1": [ - "CRY-01" + "35(3)": [ + "PRI-06.1" ], - "10.1.1": [ - "CRY-01" + "35(4)": [ + "PRI-06.1" ], - "10.1.1.1": [ - "CRY-01" + "35(4)(a)": [ + "PRI-06.1" ], - "10.1.1.2": [ - "CRY-01" + "35(4)(b)": [ + "PRI-06.1" ], - "10.1.1.3": [ - "CRY-01" + "35(5)": [ + "PRI-06.1" ], - "10.1.1.4": [ - "CRY-01" + "35(5)(a)": [ + "PRI-06.1" ], - "10.1.1.5": [ - "CRY-01" + "35(5)(b)": [ + "PRI-06.1" ], - "10.1.1.6": [ - "CRY-01" + "37(1)": [ + "PRI-06.2" ], - "10.1.1.7": [ - "CRY-01" + "37(1)(a)": [ + "PRI-06.2" ], - "10.1.1.8": [ - "CRY-01" + "37(1)(b)": [ + "PRI-06.2" ], - "10.1.1.9.PB": [ - "CRY-01" + "30(3)": [ + "PRI-06.4" ], - "10.1.1.10.P": [ - "CRY-01" + "30(4)": [ + "PRI-06.4" ], - "13.2.1.6": [ - "CRY-01" + "30(5)": [ + "PRI-06.4" ], - "14.1.3": [ - "CRY-01" + "31(1)": [ + "PRI-06.4" ], - "14.1.3.1": [ - "CRY-01" + "31(2)": [ + "PRI-06.4" ], - "14.1.3.2": [ - "CRY-01" + "31(2)(a)": [ + "PRI-06.4" ], - "14.1.3.3": [ - "CRY-01" + "31(2)(b)": [ + "PRI-06.4" ], - "14.1.3.4": [ - "CRY-01" + "31(3)": [ + "PRI-06.4" ], - "14.1.3.5": [ - "CRY-01" + "32(1)": [ + "PRI-06.4" ], - "14.1.3.6": [ - "CRY-01" + "32(1)(a)": [ + "PRI-06.4" ], - "18.1.5": [ - "CRY-01.2" + "32(1)(b)": [ + "PRI-06.4" ], - "18.1.5.1": [ - "CRY-01.2" + "32(1)(c)": [ + "PRI-06.4" ], - "18.1.5.2": [ - "CRY-01.2" + "32(2)": [ + "PRI-06.4" ], - "18.1.5.3": [ - "CRY-01.2" + "32(2)(a)": [ + "PRI-06.4" ], - "18.1.5.4": [ - "CRY-01.2" + "32(2)(b)": [ + "PRI-06.4" ], - "18.1.5.5": [ - "CRY-01.2" + "32(2)(c)": [ + "PRI-06.4" ], - "18.1.5.6": [ - "CRY-01.2" + "32(2)(d)": [ + "PRI-06.4" ], - "14.2.5.8": [ - "CRY-04" + "32(3)": [ + "PRI-06.4" ], - "8.3.1.5": [ - "CRY-05" + "33(a)": [ + "PRI-06.4" ], - "10.1.2": [ - "CRY-09" + "33(b)": [ + "PRI-06.4" ], - "10.1.2.1": [ - "CRY-09" + "32(1)(a)(i)": [ + "PRI-06.8" ], - "10.1.2.2": [ - "CRY-09" + "32(1)(a)(ii)": [ + "PRI-06.8" ], - "10.1.2.3": [ - "CRY-09" + "32(1)(a)(ii)(A)": [ + "PRI-06.8" ], - "10.1.2.4": [ - "CRY-09" + "32(1)(a)(ii)(B)": [ + "PRI-06.8" ], - "10.1.2.5": [ - "CRY-09" + "36(1)": [ + "PRI-07.4" ], - "10.1.2.6": [ - "CRY-09" + "36(1)(a)": [ + "PRI-07.4" ], - "10.1.2.7": [ - "CRY-09" + "36(1)(a)(i)": [ + "PRI-07.4" ], - "10.1.2.8": [ - "CRY-09" + "36(1)(a)(ii)": [ + "PRI-07.4" ], - "10.1.2.9": [ - "CRY-09" + "36(1)(a)(ii)(A)": [ + "PRI-07.4" ], - "10.1.2.10": [ - "CRY-09" + "36(1)(a)(ii)(B)": [ + "PRI-07.4" ], - "10.1.2.11": [ - "CRY-09" + "36(1)(b)": [ + "PRI-07.4" ], - "10.1.2.12": [ - "CRY-09" + "36(1)(c)": [ + "PRI-07.4" ], - "10.1.2.13": [ - "CRY-09" + "36(1)(d)": [ + "PRI-07.4" ], - "10.1.2.14": [ - "CRY-09" + "36(1)(e)": [ + "PRI-07.4" ], - "10.1.2.15": [ - "CRY-09" + "36(2)": [ + "PRI-07.4" ], - "10.1.2.16": [ - "CRY-09" + "32(1)(d)": [ + "PRI-07.5" ], - "10.1.2.17": [ - "CRY-09" + "32(1)(d)(i)": [ + "PRI-07.5" ], - "10.1.2.18": [ - "CRY-09" + "32(1)(d)(ii)": [ + "PRI-07.5" ], - "10.1.2.19": [ - "CRY-09" + "32(1)(e)": [ + "PRI-07.5" ], - "10.1.2.20.PB": [ - "CRY-09" + "32(1)(f)": [ + "PRI-07.5" ], - "5.1.1.10": [ - "DCH-01" + "32(1)(g)": [ + "PRI-07.5" ], - "5.1.1.14": [ - "DCH-01" + "32(1)(h)": [ + "PRI-07.5" ], - "8.2": [ - "DCH-01" + "44(1)": [ + "PRI-14" ], - "8.2.3": [ - "DCH-01" + "37(2)": [ + "PRI-17.3" ], - "8.2.3.1": [ - "DCH-01" + "37(2)(a)": [ + "PRI-17.3" ], - "13.2": [ - "DCH-01" + "37(2)(a)(i)": [ + "PRI-17.3" ], - "13.2.1": [ - "DCH-01" + "37(2)(a)(ii)": [ + "PRI-17.3" ], - "13.2.1.10": [ - "DCH-01" + "37(2)(b)": [ + "PRI-17.3" ], - "13.2.1.12": [ - "DCH-01" + "37(3)": [ + "PRI-17.3" + ] + }, + "apac-mys-bnm-rmit-2025": { + "10.1": [ + "GOV-01" ], - "13.2.1.13": [ - "DCH-01" + "11.1": [ + "GOV-01" ], - "13.2.1.14": [ - "DCH-01" + "11.2": [ + "GOV-01", + "IRO-01", + "RSK-01.3", + "SEA-01.2", + "SEA-01.3" ], - "8.2.3.3": [ - "DCH-01.3" + "11.5": [ + "GOV-01" ], - "8.2.3.4": [ - "DCH-01.3" + "8.2": [ + "GOV-01.1", + "GOV-01.3", + "BCD-01", + "CPL-01.4", + "CPL-01.5", + "PRM-01", + "PRM-01.1", + "PRM-02.1", + "RSK-01" ], - "8.3.1.3": [ - "DCH-01.3" + "8.3": [ + "GOV-01.1" ], - "8.2.3.2": [ - "DCH-01.4" + "8.4": [ + "GOV-01.1", + "GOV-01.2", + "GOV-01.3", + "PRM-01", + "PRM-01.1", + "PRM-02.1" ], - "8.2.1": [ - "DCH-02" + "8.5": [ + "GOV-01.1" ], - "8.2.1.1": [ - "DCH-02" + "8.7": [ + "GOV-01.1" ], - "8.2.1.2": [ - "DCH-02" + "11.17": [ + "GOV-01.1", + "RSK-06.3" ], - "8.2.1.3": [ - "DCH-02" + "12.3": [ + "GOV-01.1", + "MON-01", + "MDM-01", + "NET-01", + "NET-02", + "THR-03" ], - "8.2.1.4": [ - "DCH-02" + "8.6": [ + "GOV-01.2", + "GOV-02", + "GOV-04", + "GOV-04.1", + "GOV-05", + "BCD-01" ], - "8.2.1.5": [ - "DCH-02" + "9.3": [ + "GOV-01.2", + "PRM-04", + "PRM-05", + "RSK-01" ], - "8.2.1.6": [ - "DCH-02" + "9.5": [ + "GOV-01.2", + "GOV-02", + "GOV-03", + "GOV-14", + "GOV-15" ], - "8.2.1.7": [ - "DCH-02" + "10.16": [ + "GOV-02", + "OPS-07" ], - "8.2.1.8": [ - "DCH-02" + "10.20": [ + "GOV-02", + "CRY-01", + "CRY-01.5", + "CRY-09", + "IRO-04" ], - "8.2.1.9": [ - "DCH-02" + "11.12": [ + "GOV-02", + "IRO-01" ], - "8.2.1.10": [ - "DCH-02" + "9.4": [ + "GOV-04", + "HRS-03.2" ], - "8.2.2": [ - "DCH-04" + "10.35": [ + "GOV-04.1", + "CPL-07", + "IRO-02", + "IRO-10" ], - "8.2.2.1": [ - "DCH-04" + "11.8": [ + "GOV-04.1", + "GOV-04.2" ], - "8.2.2.2": [ - "DCH-04" + "8.1": [ + "GOV-05.2", + "CPL-01.4", + "PRM-01", + "PRM-01.1", + "PRM-01.2", + "PRM-02.1", + "RSK-01.3", + "RSK-01.5", + "RSK-03.2", + "RSK-04" ], - "8.2.2.3": [ - "DCH-04" + "10.2": [ + "GOV-16", + "GOV-16.1", + "CPL-13.1", + "IAO-01", + "IAO-02", + "PRM-04", + "PRM-05", + "PRM-06", + "TDA-01", + "TDA-01.1" ], - "8.2.2.4": [ - "DCH-04" + "16.1": [ + "GOV-17" ], - "8.2.2.5": [ - "DCH-04" + "17.2": [ + "GOV-17" ], - "8.2.2.6": [ - "DCH-04" + "17.5": [ + "GOV-17" ], - "8.2.2.7.PB": [ - "DCH-04" + "10.17": [ + "AST-01", + "TDA-17", + "VPM-01", + "VPM-05" ], - "8.2.3.6": [ - "DCH-04" + "9.2": [ + "AST-01.1", + "BCD-02", + "IRO-01", + "RSK-01", + "RSK-02", + "RSK-02.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-04.1", + "RSK-04.2", + "RSK-06", + "RSK-06.1", + "RSK-06.2", + "RSK-06.4", + "TDA-06.2", + "TPM-02", + "THR-09" ], - "8.3.1.4": [ - "DCH-06", - "DCH-06.1" + "11.3": [ + "AST-01.1", + "AST-02", + "AST-02.9", + "BCD-02", + "IRO-02", + "IRO-04", + "IRO-06.1", + "RSK-01", + "THR-03", + "THR-09", + "THR-10" ], - "8.3.3": [ - "DCH-07" + "10.41": [ + "AST-04" ], - "8.3.3.1": [ - "DCH-07" + "10.13": [ + "AST-30" ], - "8.3.3.2": [ - "DCH-07" + "10.24": [ + "BCD-01", + "BCD-01.5", + "SEA-01.2", + "TPM-01", + "TPM-05" ], - "8.3.3.3": [ - "DCH-07" + "10.44": [ + "BCD-01", + "BCD-11", + "BCD-11.1", + "BCD-11.2", + "DCH-01.2", + "DCH-06", + "DCH-06.1", + "RSK-08" ], - "8.3.3.4": [ - "DCH-07" + "10.32": [ + "BCD-01.4", + "BCD-01.5", + "SEA-01.2", + "SEA-01.3" ], - "8.3.3.5": [ - "DCH-07" + "11.15": [ + "BCD-01.6", + "BCD-10.4" ], - "13.2.2.5": [ - "DCH-07" + "10.26": [ + "BCD-02", + "BCD-02.2", + "BCD-11.7", + "CLD-01", + "MNT-01", + "MNT-02", + "SEA-01", + "TDA-08" ], - "8.3.1.10": [ - "DCH-07.1" + "10.25": [ + "BCD-02.2", + "BCD-11.7", + "TPM-01", + "TPM-05" ], - "8.3.2.4": [ - "DCH-08" + "10.45": [ + "BCD-11.4", + "BCD-12", + "BCD-14" ], - "8.3.2.5": [ - "DCH-08" + "10.29": [ + "CAP-01", + "CAP-02", + "CAP-03", + "CAP-05" ], - "8.3.2.6": [ - "DCH-08" + "10.30": [ + "CAP-04" ], - "11.2.7.3": [ - "DCH-09" + "10.39": [ + "CAP-04" ], - "8.3.2.7": [ - "DCH-09.1" + "10.11": [ + "CHG-01", + "CHG-02", + "CHG-02.3", + "CHG-03" ], - "13.2.1.5": [ - "DCH-14" + "10.18": [ + "CHG-02", + "CHG-02.2", + "CHG-05", + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-03", + "VPM-04", + "VPM-05", + "VPM-05.6" ], - "13.2.1.9": [ - "DCH-14" + "10.27": [ + "CHG-02", + "OPS-01.1" ], - "4.4.7.4": [ - "DCH-18", - "RSK-04", - "RSK-04.2", - "RSK-06.1" + "10.12": [ + "CHG-04.5", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-02.7", + "TDA-20", + "TDA-20.2", + "TDA-20.3", + "TDA-21", + "TPM-01", + "TPM-04", + "TPM-05" ], - "4.6.3.4": [ - "DCH-18" + "10.50": [ + "CLD-01", + "CLD-02", + "CLD-06", + "CLD-06.1", + "CLD-09", + "CLD-10", + "TPM-03.1", + "TPM-04", + "TPM-04.1", + "TPM-04.4", + "TPM-05", + "TPM-05.7" ], - "12.3.1.15": [ - "DCH-18" + "16.6": [ + "CPL-01.3" ], - "12.3.1.19.P": [ - "DCH-18" + "18.1": [ + "CPL-01.4" ], - "13.2.1.7": [ - "DCH-18" + "18.2": [ + "CPL-01.5" ], - "18.1.3": [ - "DCH-18" + "16.5": [ + "CPL-01.6" ], - "18.1.3.1": [ - "DCH-18" + "13.2": [ + "CPL-02" ], - "18.1.3.2": [ - "DCH-18" + "13.3": [ + "CPL-02.1" ], - "18.1.3.3": [ - "DCH-18" + "11.9": [ + "CPL-03", + "MON-01", + "MON-16", + "OPS-04", + "VPM-06", + "VPM-07" ], - "18.1.3.4": [ - "DCH-18" + "13.1": [ + "CPL-03" ], - "18.1.3.5": [ - "DCH-18" + "13.4": [ + "CPL-03.1" ], - "18.1.3.6": [ - "DCH-18" + "14.1": [ + "CPL-03.1" ], - "18.1.3.7": [ - "DCH-18" + "14.2": [ + "CPL-03.1" ], - "18.1.3.8": [ - "DCH-18" + "12.8": [ + "CPL-07" ], - "18.1.3.9": [ - "DCH-18" + "10.21": [ + "CPL-13.1", + "CRY-09" ], - "18.1.3.10": [ - "DCH-18" + "10.54": [ + "CFG-03", + "IAC-01", + "IAC-01.2", + "IAC-21", + "IAC-29" ], - "18.1.3.11": [ - "DCH-18" + "10.15": [ + "CFG-04.1", + "IAO-01", + "IAO-02.2", + "IAO-07", + "RSK-09", + "RSK-09.1", + "TDA-04.2", + "TPM-03" ], - "18.1.3.12": [ - "DCH-18" + "10.57": [ + "MON-01", + "MON-16", + "IAC-01" ], - "18.1.3.13.PB": [ - "DCH-18" + "10.42": [ + "MON-10" ], - "5.1.1.15": [ - "END-01" + "10.31": [ + "MON-16", + "IRO-02", + "SEA-01.2", + "SEA-01.3", + "OPS-03", + "VPM-01" ], - "12.2.1.2": [ - "END-01" + "10.22": [ + "CRY-01", + "CRY-01.5", + "SEA-01" ], - "6.2.1.1": [ - "END-02" + "10.23": [ + "CRY-09" ], - "6.2.1.2": [ - "END-02" + "10.53": [ + "IAC-01" ], - "6.2.1.3": [ - "END-02" + "10.56": [ + "IAC-01", + "IAC-08", + "IAC-15" ], - "6.2.1.4": [ - "END-02" + "10.55": [ + "IAC-06" ], - "6.2.1.5": [ - "END-02" + "11.11": [ + "IRO-02" ], - "6.2.1.6": [ - "END-02" + "11.13": [ + "IRO-04", + "IRO-07" ], - "6.2.1.7": [ - "END-02" + "11.16": [ + "IRO-06" ], - "6.2.1.8": [ - "END-02" + "11.14": [ + "IRO-07" ], - "6.2.1.9": [ - "END-02" + "11.19": [ + "IRO-10" ], - "6.2.1.10": [ - "END-02" + "11.18": [ + "IRO-10.2" ], - "6.2.1.11": [ - "END-02" + "10.6": [ + "IAO-01", + "IAO-02", + "IAO-02.2", + "IAO-04", + "IAO-06", + "IAO-07" ], - "6.2.1.12": [ - "END-02" + "10.8": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-02.4", + "IAO-04", + "IAO-05", + "IAO-06", + "IAO-07" ], - "6.2.1.13": [ - "END-02" + "16.2": [ + "IAO-01", + "PRI-02" ], - "6.2.1.14": [ - "END-02" + "10.9": [ + "IAO-01.1", + "IAO-02", + "IAO-02.2" ], - "6.2.1.15": [ - "END-02" + "16.4": [ + "IAO-02" ], - "6.2.1.16": [ - "END-02" + "10.10": [ + "IAO-04", + "TDA-09" ], - "6.2.1.17": [ - "END-02" + "10.37": [ + "NET-01", + "SEA-01", + "SEA-01.4" ], - "6.2.1.21": [ - "END-02" + "12.5": [ + "NET-01", + "TDA-01", + "TDA-01.1", + "TDA-02" ], - "6.2.1.22": [ - "END-02" + "10.28": [ + "NET-06", + "TDA-08" ], - "12.2": [ - "END-04" + "10.3": [ + "PRM-04" ], - "12.2.1": [ - "END-04" + "10.5": [ + "PRM-04", + "PRM-07", + "SEA-01", + "SEA-01.4" ], - "12.2.1.1": [ - "END-04" + "9.1": [ + "RSK-01" ], - "12.2.1.3": [ - "END-04" + "10.4": [ + "SEA-01", + "SEA-01.4", + "SEA-02" ], - "12.2.1.4": [ - "END-04" + "10.36": [ + "SEA-01", + "SEA-01.4", + "SEA-02" ], - "12.2.1.5": [ - "END-04" + "10.38": [ + "SEA-01", + "SEA-01.4" ], - "12.2.1.6": [ - "END-04" + "10.40": [ + "SEA-01", + "SEA-01.2", + "SEA-01.3", + "SEA-01.4", + "SEA-02" ], - "12.2.1.7": [ - "END-04" + "10.43": [ + "SEA-01" ], - "12.2.1.8": [ - "END-04" + "10.52": [ + "SEA-01" ], - "12.2.1.9": [ - "END-04" + "15.1": [ + "SAT-02" ], - "12.2.1.15": [ - "END-04" + "15.2": [ + "SAT-03", + "SAT-03.7" ], - "4.5.2.2": [ - "HRS-01", - "HRS-02", - "HRS-03", - "HRS-03.2", - "HRS-11" + "15.3": [ + "SAT-03" ], - "5.1.1.12": [ - "HRS-01" + "12.1": [ + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-02.12" ], - "7.1": [ - "HRS-01" + "10.14": [ + "TDA-02.3", + "TDA-09.3" ], - "7.1.1.13": [ - "HRS-01" + "10.7": [ + "TDA-07", + "TDA-08" ], - "8.1.4.1": [ - "HRS-01.1" + "10.46": [ + "TPM-01", + "TPM-02", + "TPM-04.1", + "TPM-05", + "TPM-05.4", + "TPM-05.5" ], - "8.1.4.2": [ - "HRS-01.1" + "10.47": [ + "TPM-04.1" ], - "8.1.4.3": [ - "HRS-01.1" + "10.48": [ + "TPM-05", + "TPM-05.2", + "TPM-05.4" ], - "8.1.4.4": [ - "HRS-01.1" + "10.49": [ + "TPM-05.1", + "TPM-07", + "TPM-08" ], - "9.2.6.2": [ - "HRS-01.1" + "11.10": [ + "THR-01", + "THR-03", + "THR-03.1" ], - "9.2.6.4": [ - "HRS-01.1" + "12.4": [ + "THR-03", + "THR-10" ], - "9.2.6.5": [ - "HRS-01.1" + "11.7": [ + "THR-06" ], - "9.2.6.6": [ - "HRS-01.1" + "10.19": [ + "VPM-01", + "VPM-05.1" ], - "6.1.1": [ - "HRS-03" + "11.6": [ + "VPM-10" + ] + }, + "apac-nzl-hisf-mlhsp-2023": {}, + "apac-nzl-hisf-microsmall-2023": { + "HHSP12": [ + "GOV-01.1" ], - "6.1.1.1": [ - "HRS-03" + "HML12": [ + "GOV-01.1", + "GOV-01.2" ], - "6.1.1.2": [ - "HRS-03" + "HML21": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1" ], - "6.1.1.3": [ - "HRS-03" + "HHSP46": [ + "GOV-01.2", + "GOV-05" ], - "6.1.1.4": [ - "HRS-03" + "HHSP75": [ + "GOV-01.2", + "IRO-10" ], - "6.1.1.5": [ - "HRS-03" + "HML46": [ + "GOV-01.2", + "GOV-05" ], - "6.1.1.6": [ - "HRS-03" + "HML75": [ + "GOV-01.2", + "IRO-10" ], - "6.1.1.7": [ - "HRS-03" + "HML01": [ + "GOV-02" ], - "6.1.1.13.PB": [ - "HRS-03" + "HHSP01": [ + "GOV-02" + ], + "HHSP67": [ + "GOV-03", + "CPL-02", + "CPL-02.1" ], - "4.5.2.6": [ - "HRS-03.1", - "HRS-04.2", - "HRS-05.7" + "HML66": [ + "GOV-03", + "CPL-02", + "CPL-02.1" ], - "4.5.2.7": [ - "HRS-03.1" + "HHSP21": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" ], - "4.5.2.8": [ - "HRS-03.1", - "HRS-05.7" + "HHSP27": [ + "GOV-04", + "GOV-04.1" ], - "7.1.2.7": [ - "HRS-03.1" + "HML27": [ + "GOV-04", + "GOV-04.1" ], - "7.2": [ - "HRS-03.1", - "HRS-04.2", - "HRS-05.7" + "HHSP11": [ + "GOV-15", + "PRM-04", + "PRM-05" ], - "7.2.1.4": [ - "HRS-03.1" + "HHSP16": [ + "GOV-15", + "SEA-01" ], - "8.1.3.1": [ - "HRS-03.1", - "HRS-04.2", - "HRS-05.7" + "HHSP28": [ + "GOV-15", + "PRM-04", + "PRM-05" ], - "4.5.2.3": [ - "HRS-03.2" + "HML11": [ + "GOV-15", + "PRM-04" ], - "7.1.1.6": [ - "HRS-03.2" + "HML16": [ + "GOV-15", + "CFG-02", + "SEA-01" ], - "14.2.1.7": [ - "HRS-03.2" + "HML28": [ + "GOV-15", + "PRM-04" ], - "14.2.1.8": [ - "HRS-03.2" + "HHSP05": [ + "AST-01" ], - "14.2.1.11": [ - "HRS-03.2" + "HHSP54": [ + "AST-01", + "CFG-02", + "NET-01" ], - "7.1.1": [ - "HRS-04" + "HML05": [ + "AST-01" ], - "7.1.1.1": [ - "HRS-04" + "HML54": [ + "AST-01", + "CFG-02", + "NET-01" ], - "7.1.1.2": [ - "HRS-04" + "HHSP06": [ + "AST-09" ], - "7.1.1.3": [ - "HRS-04" + "HHSP45": [ + "AST-09" ], - "7.1.1.5": [ - "HRS-04" + "HML06": [ + "AST-09" ], - "7.1.1.9": [ - "HRS-04" + "HML45": [ + "AST-09" ], - "7.1.1.10": [ - "HRS-04", - "HRS-10" + "HHSP08": [ + "BCD-01" ], - "7.1.1.7": [ - "HRS-04.1" + "HHSP24": [ + "BCD-01", + "BCD-01.4" ], - "7.1.1.8": [ - "HRS-04.1" + "HHSP56": [ + "BCD-01", + "BCD-11", + "BCD-11.10" ], - "7.2.1.1": [ - "HRS-04.2" + "HHSP61": [ + "BCD-01", + "CAP-01" ], - "7.1.2": [ - "HRS-05" + "HML08": [ + "BCD-01" ], - "7.1.2.1": [ - "HRS-05" + "HML24": [ + "BCD-01", + "BCD-01.4" ], - "7.1.2.2": [ - "HRS-05" + "HML61": [ + "BCD-01", + "CAP-01" ], - "7.1.2.3": [ - "HRS-05" + "HHSP35": [ + "BCD-02.1", + "BCD-02.2" ], - "7.1.2.4": [ - "HRS-05" + "HML35": [ + "BCD-02.1", + "BCD-02.2" ], - "7.1.2.5": [ - "HRS-05" + "HHSP64": [ + "BCD-05" ], - "7.1.2.6": [ - "HRS-05" + "HML63": [ + "BCD-05" ], - "7.1.2.8": [ - "HRS-05" + "HHSP17": [ + "BCD-11", + "BCD-12" ], - "7.1.2.9": [ - "HRS-05" + "HHSP69": [ + "BCD-11", + "BCD-11.1", + "MON-01.4", + "MON-01.12" ], - "7.2.1": [ - "HRS-05" + "HML17": [ + "BCD-11", + "BCD-12" ], - "7.2.1.5": [ - "HRS-05" + "HML56": [ + "BCD-11", + "BCD-11.10" ], - "9.2.4.2": [ - "HRS-05" + "HML68": [ + "BCD-11", + "BCD-11.1", + "MON-01.4", + "MON-01.12" ], - "7.2.1.2": [ - "HRS-05.1" + "HHSP57": [ + "BCD-11.1" ], - "8.1.3": [ - "HRS-05.1" + "HML57": [ + "BCD-11.1" ], - "8.1.3.2": [ - "HRS-05.1" + "HHSP18": [ + "CHG-01", + "CHG-02" ], - "13.2.1.1": [ - "HRS-05.3" + "HML18": [ + "CHG-01", + "CHG-02" ], - "13.2.1.2": [ - "HRS-05.3" + "HHSP33": [ + "CHG-03" ], - "13.2.1.3": [ - "HRS-05.3" + "HML33": [ + "CHG-03" ], - "13.2.1.4": [ - "HRS-05.3" + "HHSP51": [ + "CLD-02" ], - "13.2.1.8": [ - "HRS-05.3" + "HML51": [ + "CLD-02" ], - "13.2.1.11": [ - "HRS-05.3" + "HHSP52": [ + "CLD-04" ], - "7.2.1.3": [ - "HRS-05.7" + "HML52": [ + "CLD-04" ], - "13.2.4": [ - "HRS-06.1" + "HHSP53": [ + "CLD-06" ], - "13.2.4.1": [ - "HRS-06.1" + "HML53": [ + "CLD-06" ], - "13.2.4.2": [ - "HRS-06.1" + "HHSP29": [ + "CPL-01" ], - "13.2.4.3": [ - "HRS-06.1" + "HML29": [ + "CPL-01" ], - "13.2.4.4": [ - "HRS-06.1" + "HHSP60": [ + "CFG-02" ], - "13.2.4.5": [ - "HRS-06.1" + "HHSP65": [ + "CFG-02", + "RSK-04.1", + "RSK-06.2" ], - "13.2.4.6": [ - "HRS-06.1" + "HML60": [ + "CFG-02" ], - "13.2.4.7": [ - "HRS-06.1" + "HML64": [ + "CFG-02", + "RSK-04.1", + "RSK-06.2" ], - "13.2.4.8": [ - "HRS-06.1" + "HHSP70": [ + "MON-01", + "MON-03", + "MON-03.2" ], - "13.2.4.9": [ - "HRS-06.1" + "HML70": [ + "MON-01", + "MON-03", + "MON-03.2" ], - "13.2.4.10": [ - "HRS-06.1" + "HHSP71": [ + "MON-07.1" ], - "13.2.4.11": [ - "HRS-06.1" + "HML71": [ + "MON-07.1" ], - "13.2.4.12": [ - "HRS-06.1" + "HHSP63": [ + "MON-11", + "NET-17" ], - "13.2.4.13": [ - "HRS-06.1" + "HML69": [ + "MON-11", + "NET-17" ], - "13.2.4.14": [ - "HRS-06.1" + "HHSP37": [ + "CRY-01" ], - "13.2.4.15": [ - "HRS-06.1" + "HML37": [ + "CRY-01" ], - "13.2.4.16": [ - "HRS-06.1" + "HHSP14": [ + "DCH-01", + "DCH-01.2", + "DCH-12" ], - "7.1.2.10": [ - "HRS-06.2" + "HHSP34": [ + "DCH-01", + "END-01" ], - "7.2.3": [ - "HRS-07" + "HHSP74": [ + "DCH-01", + "DCH-01.2", + "IRO-08" ], - "7.2.3.1": [ - "HRS-07" + "HML14": [ + "DCH-01", + "DCH-01.2", + "DCH-12" ], - "7.2.3.2": [ - "HRS-07" + "HML74": [ + "DCH-01", + "DCH-01.2", + "IRO-08" ], - "7.2.3.3": [ - "HRS-07" + "HML34": [ + "DCH-02" ], - "7.2.3.4": [ - "HRS-07" + "HHSP62": [ + "END-04" ], - "7.3": [ - "HRS-09" + "HML62": [ + "END-04" ], - "7.3.1": [ - "HRS-09" + "HML02": [ + "HRS-01", + "HRS-03" ], - "7.3.1.1": [ - "HRS-09" + "HHSP02": [ + "HRS-03" ], - "7.3.1.2": [ - "HRS-09" + "HHSP23": [ + "HRS-03" ], - "7.3.1.3": [ - "HRS-09" + "HML23": [ + "HRS-03" ], - "6.1.2": [ - "HRS-11" + "HHSP20": [ + "HRS-04" ], - "6.1.2.1": [ - "HRS-11" + "HML20": [ + "HRS-04" ], - "6.1.2.2": [ - "HRS-11" + "HHSP03": [ + "HRS-07", + "HRS-07.1" ], - "6.1.2.3": [ - "HRS-11" + "HHSP72": [ + "HRS-07", + "TPM-05" ], - "6.1.2.4": [ - "HRS-11" + "HHSP73": [ + "HRS-07", + "HRS-07.1", + "TPM-07", + "TPM-08" ], - "7.2.1.7": [ - "HRS-15" + "HML03": [ + "HRS-07", + "HRS-07.1" ], - "5.1.1.9": [ - "IAC-01" + "HML72": [ + "HRS-07", + "TPM-05" ], - "9.1": [ - "IAC-01" + "HML73": [ + "HRS-07", + "HRS-07.1", + "TPM-07", + "TPM-08" ], - "9.1.1": [ - "IAC-01" + "HHSP39": [ + "IAC-01.2" ], - "9.1.1.1": [ - "IAC-01" + "HML39": [ + "IAC-01.2" ], - "9.1.1.2": [ - "IAC-01" + "HHSP49": [ + "IAC-05", + "NET-01" ], - "9.1.1.3": [ - "IAC-01" + "HML49": [ + "IAC-05", + "NET-01" ], - "9.1.1.4": [ - "IAC-01" + "HHSP04": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "PES-02" ], - "9.1.1.5": [ - "IAC-01" + "HML04": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "PES-02" ], - "9.1.1.6": [ - "IAC-01" + "HHSP40": [ + "IAC-08", + "IAC-20" ], - "9.1.1.7": [ - "IAC-01" + "HHSP42": [ + "IAC-08", + "TDA-20" ], - "9.1.1.8": [ - "IAC-01" + "HML40": [ + "IAC-08", + "IAC-20" ], - "9.1.1.9": [ - "IAC-01" + "HML42": [ + "IAC-08", + "TDA-20" ], - "9.1.1.10": [ - "IAC-01" + "HHSP38": [ + "IAC-15" ], - "9.1.1.11": [ - "IAC-01" + "HML38": [ + "IAC-15" ], - "9.1.1.12": [ - "IAC-01" + "HHSP41": [ + "IAC-16" ], - "9.1.1.13": [ - "IAC-01" + "HML41": [ + "IAC-16" ], - "9.1.1.14": [ - "IAC-01" + "HHSP10": [ + "IAC-20", + "PES-03.4" ], - "9.1.1.15": [ - "IAC-01" + "HML10": [ + "IAC-20", + "PES-03.4" ], - "9.4.1.8.PB": [ - "IAC-01" + "HHSP07": [ + "IRO-02", + "IRO-04" ], - "9.4.2": [ - "IAC-01.2" + "HML07": [ + "IRO-02", + "IRO-04" ], - "9.4.2.1": [ - "IAC-01.2" + "HHSP68": [ + "IAO-01", + "IAO-02" ], - "9.4.2.2.B": [ - "IAC-01.2" + "HML67": [ + "IAO-01", + "IAO-02" ], - "9.4.2.3": [ - "IAC-01.2" + "HHSP15": [ + "MNT-01" ], - "9.4.2.4": [ - "IAC-01.2" + "HML15": [ + "MNT-01" ], - "9.4.2.5": [ - "IAC-01.2" + "HHSP43": [ + "NET-03.7", + "RSK-06.2", + "TDA-17" ], - "9.4.2.6": [ - "IAC-01.2" + "HHSP55": [ + "NET-03.7", + "NET-06" ], - "9.4.2.7": [ - "IAC-01.2" + "HML43": [ + "NET-03.7", + "RSK-06.2", + "TDA-17" ], - "9.4.2.8": [ - "IAC-01.2" + "HML55": [ + "NET-03.7", + "NET-06" ], - "9.4.2.9": [ - "IAC-01.2" + "HHSP47": [ + "PES-01" ], - "9.4.2.10": [ - "IAC-01.2" + "HML47": [ + "PES-01" ], - "9.4.2.11": [ - "IAC-01.2" + "HHSP13": [ + "PES-01.1" ], - "9.4.2.12": [ - "IAC-01.2" + "HML13": [ + "PES-01.1" ], - "9.4.2.13": [ - "IAC-01.2" + "HHSP48": [ + "PES-03", + "PES-04" ], - "9.4.2.14": [ - "IAC-01.2" + "HML48": [ + "PES-03", + "PES-04" ], - "9.4.2.15": [ - "IAC-01.2" + "HHSP66": [ + "PES-05" ], - "9.4.2.16": [ - "IAC-01.2" + "HML65": [ + "PES-05" ], - "9.2.2": [ - "IAC-07" + "HHSP31": [ + "PRM-04", + "PRM-05", + "TDA-02" ], - "9.2.2.2": [ - "IAC-07" + "HML31": [ + "PRM-04", + "PRM-05", + "TDA-02" ], - "9.2.2.3": [ - "IAC-07" + "HHSP30": [ + "RSK-01" ], - "9.2.2.4": [ - "IAC-07" + "HML30": [ + "RSK-01" ], - "9.2.2.6": [ - "IAC-07" + "HHSP32": [ + "RSK-04" ], - "9.2.2.8.PB": [ - "IAC-07" + "HML32": [ + "RSK-04" ], - "9.2.6": [ - "IAC-07" + "HHSP26": [ + "RSK-06.2", + "VPM-01", + "VPM-06" ], - "9.2.6.3": [ - "IAC-07" + "HML26": [ + "RSK-06.2", + "VPM-01", + "VPM-06" ], - "8.1.2.5": [ - "IAC-08" + "HHSP22": [ + "SAT-01" ], - "9.4": [ - "IAC-08" + "HML22": [ + "SAT-01" ], - "9.4.1": [ - "IAC-08" + "HHSP50": [ + "TDA-01", + "TDA-01.1", + "TDA-06" ], - "9.4.1.1": [ - "IAC-08" + "HML50": [ + "TDA-01", + "TDA-01.1", + "TDA-06" ], - "9.4.1.2": [ - "IAC-08" + "HHSP58": [ + "TDA-08" ], - "9.4.1.3": [ - "IAC-08" + "HML58": [ + "TDA-08" ], - "9.4.1.4": [ - "IAC-08" + "HHSP25": [ + "TPM-01", + "TPM-04.1", + "TPM-08" ], - "9.4.1.5": [ - "IAC-08" + "HML25": [ + "TPM-01", + "TPM-04.1", + "TPM-08" ], - "9.4.1.6": [ - "IAC-08" + "HHSP09": [ + "TPM-05" ], - "9.4.1.7": [ - "IAC-08" + "HHSP36": [ + "TPM-05" ], - "9.2.4": [ - "IAC-10" + "HML09": [ + "TPM-05" ], - "9.2.4.1": [ - "IAC-10" + "HML36": [ + "TPM-05" ], - "9.2.4.3": [ - "IAC-10" + "HHSP19": [ + "VPM-01", + "VPM-02", + "VPM-05" ], - "9.2.4.4": [ - "IAC-10" + "HML19": [ + "VPM-01", + "VPM-02", + "VPM-05" ], - "9.2.4.5": [ - "IAC-10" + "HHSP59": [ + "VPM-02", + "VPM-06" ], - "9.2.4.6": [ - "IAC-10" + "HML59": [ + "VPM-02", + "VPM-06" ], - "9.2.4.7": [ - "IAC-10" + "HHSP44": [ + "VPM-04.1" ], - "9.2.4.8": [ - "IAC-10" + "HML44": [ + "VPM-04.1" + ] + }, + "apac-nzl-hisf-suppliers-2023": { + "HSUP10": [ + "GOV-01.1", + "GOV-01.2" ], - "9.3.1.4": [ - "IAC-10.1" + "HSUP19": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1" ], - "9.4.3": [ - "IAC-10.1" + "HSUP38": [ + "GOV-01.2", + "GOV-05" ], - "9.4.3.1": [ - "IAC-10.1" + "HSUP65": [ + "GOV-01.2", + "IRO-10" ], - "9.4.3.2": [ - "IAC-10.1" + "HSUP01": [ + "GOV-02", + "HRS-05.1", + "OPS-01.1" ], - "9.4.3.3": [ - "IAC-10.1" + "HSUP58": [ + "GOV-03", + "CPL-02", + "CPL-02.1" ], - "9.4.3.4": [ - "IAC-10.1" + "HSUP23": [ + "GOV-04", + "GOV-04.1" ], - "9.4.3.5": [ - "IAC-10.1" + "HSUP14": [ + "GOV-15", + "CFG-02", + "SEA-01" ], - "9.4.3.6": [ - "IAC-10.1" + "HSUP24": [ + "GOV-15", + "PRM-04" ], - "9.4.3.7": [ - "IAC-10.1" + "HSUP05": [ + "AST-01" ], - "9.4.3.8": [ - "IAC-10.1" + "HSUP46": [ + "AST-01", + "CFG-02", + "NET-01" ], - "9.4.3.9": [ - "IAC-10.1" + "HSUP27": [ + "AST-01.2", + "PRM-05", + "PRM-06" ], - "9.3": [ - "IAC-10.5" + "HSUP06": [ + "AST-09" ], - "9.3.1": [ - "IAC-10.5" + "HSUP08": [ + "BCD-01" ], - "9.3.1.1": [ - "IAC-10.5" + "HSUP22": [ + "BCD-01", + "BCD-01.4" ], - "9.3.1.2": [ - "IAC-10.5" + "HSUP53": [ + "BCD-01", + "CAP-01" ], - "9.3.1.3": [ - "IAC-10.5" + "HSUP31": [ + "BCD-02.1", + "BCD-02.2" ], - "9.3.1.5": [ - "IAC-10.5" + "HSUP56": [ + "BCD-05" ], - "9.3.1.6": [ - "IAC-10.5" + "HSUP15": [ + "BCD-11", + "BCD-12" ], - "9.3.1.7": [ - "IAC-10.5" + "HSUP48": [ + "BCD-11", + "BCD-11.10" ], - "9.2": [ - "IAC-15" + "HSUP60": [ + "BCD-11", + "BCD-11.1", + "MON-01.4", + "MON-01.12" ], - "9.2.1": [ - "IAC-15" + "HSUP49": [ + "BCD-11.1" ], - "9.2.1.1": [ - "IAC-15" + "HSUP16": [ + "CHG-01", + "CHG-02" ], - "9.2.1.2": [ - "IAC-15" + "HSUP29": [ + "CHG-03" ], - "9.2.1.3": [ - "IAC-15" + "HSUP43": [ + "CLD-02" ], - "9.2.1.4": [ - "IAC-15" + "HSUP44": [ + "CLD-04" ], - "9.2.1.5": [ - "IAC-15" + "HSUP45": [ + "CLD-06" ], - "9.2.1.6.PB": [ - "IAC-15" + "HSUP25": [ + "CPL-01" ], - "9.2.4.9.PB": [ - "IAC-15" + "HSUP52": [ + "CFG-02" ], - "9.2.2.5": [ - "IAC-15.1" + "HSUP61": [ + "MON-01", + "MON-03", + "MON-03.2" ], - "9.2.3": [ - "IAC-16" + "HSUP62": [ + "MON-07.1" ], - "9.2.3.2": [ - "IAC-16" + "HSUP55": [ + "MON-11", + "NET-17" ], - "9.2.3.3": [ - "IAC-16" + "HSUP32": [ + "CRY-01" ], - "9.2.3.4": [ - "IAC-16" + "HSUP12": [ + "DCH-01", + "DCH-01.2", + "DCH-12" ], - "9.2.3.5": [ - "IAC-16" + "HSUP30": [ + "DCH-01", + "DCH-02", + "END-01" ], - "9.2.3.6": [ - "IAC-16" + "HSUP66": [ + "DCH-01", + "DCH-01.2", + "IRO-08" ], - "9.2.3.7": [ - "IAC-16" + "HSUP54": [ + "END-04" ], - "9.2.3.8": [ - "IAC-16" + "HSUP02": [ + "HRS-01", + "HRS-03" ], - "9.2.3.9": [ - "IAC-16" + "HSUP21": [ + "HRS-03" ], - "9.2.3.10": [ - "IAC-16" + "HSUP18": [ + "HRS-04" ], - "9.2.2.7": [ - "IAC-17" + "HSUP03": [ + "HRS-07", + "HRS-07.1" ], - "9.2.5": [ - "IAC-17" + "HSUP63": [ + "HRS-07", + "TPM-05" ], - "9.2.5.1": [ - "IAC-17" + "HSUP64": [ + "HRS-07", + "HRS-07.1", + "TPM-07", + "TPM-08" ], - "9.2.5.2": [ - "IAC-17" + "HSUP34": [ + "IAC-01.2" ], - "9.2.5.3": [ - "IAC-17" + "HSUP41": [ + "IAC-05", + "NET-01" ], - "9.2.5.4": [ - "IAC-17" + "HSUP04": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-08", + "PES-02", + "PES-02.1" ], - "9.2.5.5": [ - "IAC-17" + "HSUP35": [ + "IAC-07", + "IAC-15" ], - "9.2.5.6": [ - "IAC-17" + "HSUP37": [ + "IAC-08", + "TDA-20" ], - "9.4.4": [ - "IAC-20.3" + "HSUP33": [ + "IAC-15" ], - "9.4.4.1": [ - "IAC-20.3" + "HSUP36": [ + "IAC-16" ], - "9.4.4.2": [ - "IAC-20.3" + "HSUP09": [ + "IAC-20", + "PES-03.4" ], - "9.4.4.3": [ - "IAC-20.3" + "HSUP07": [ + "IRO-02", + "IRO-04" ], - "9.4.4.4": [ - "IAC-20.3" + "HSUP59": [ + "IAO-01", + "IAO-02" ], - "9.4.4.5": [ - "IAC-20.3" + "HSUP13": [ + "MNT-01" ], - "9.4.4.6": [ - "IAC-20.3" + "HSUP47": [ + "NET-03.7", + "NET-06" ], - "9.4.4.7": [ - "IAC-20.3" + "HSUP11": [ + "PES-01", + "PES-01.1" ], - "9.4.4.8": [ - "IAC-20.3" + "HSUP39": [ + "PES-01" ], - "9.4.4.9": [ - "IAC-20.3" + "HSUP40": [ + "PES-03", + "PES-04" ], - "9.4.4.10.P": [ - "IAC-20.3" + "HSUP57": [ + "PES-05" ], - "9.4.4.11.P": [ - "IAC-20.3" + "HSUP26": [ + "RSK-01" ], - "9.2.6.1": [ - "IAC-20.6" + "HSUP28": [ + "RSK-04" ], - "9.1.2": [ - "IAC-21" + "HSUP20": [ + "SAT-01" ], - "9.1.2.1": [ - "IAC-21" + "HSUP42": [ + "TDA-01", + "TDA-01.1", + "TDA-06" ], - "9.1.2.2": [ - "IAC-21" + "HSUP50": [ + "TDA-08" ], - "9.1.2.3": [ - "IAC-21" + "HSUP67": [ + "TPM-01", + "TPM-04.1", + "TPM-08" ], - "9.1.2.4": [ - "IAC-21" + "HSUP68": [ + "TPM-05" ], - "9.1.2.5": [ - "IAC-21" + "HSUP17": [ + "VPM-01", + "VPM-02", + "VPM-05" ], - "9.1.2.6": [ - "IAC-21" + "HSUP51": [ + "VPM-02", + "VPM-06" + ] + }, + "apac-nzl-ism-3-9": { + "5.1.14.C.01": [ + "GOV-01", + "GOV-02", + "GOV-03", + "HRS-03.2" ], - "9.1.2.7": [ - "IAC-21" + "5.1.16.C.01": [ + "GOV-01", + "GOV-02" ], - "9.1.2.8": [ - "IAC-21" + "16.1.24.C.01": [ + "GOV-01", + "GOV-02", + "OPS-01.1" ], - "7.1.1.4": [ - "IAC-28" + "3.2.9.C.01": [ + "GOV-01.1", + "GOV-04" ], - "9.2.2.1": [ - "IAC-28.1" + "5.1.16.C.02": [ + "GOV-01.4", + "GOV-02" ], - "16.1": [ - "IRO-01" + "5.1.7.C.01": [ + "GOV-02" ], - "16.1.1.2": [ - "IRO-01" + "5.1.17.C.01": [ + "GOV-02" ], - "16.1.1.4": [ - "IRO-01" + "5.1.18.C.01": [ + "GOV-02" ], - "16.1.1.5": [ - "IRO-01" + "5.1.19.C.01": [ + "GOV-02" ], - "16.1.1.6.P": [ - "IRO-01" + "5.1.20.C.01": [ + "GOV-02" ], - "16.1.1.7.P": [ - "IRO-01" + "5.1.20.C.02": [ + "GOV-02" ], - "16.1.1.8.P": [ - "IRO-01" + "5.2.3.C.01": [ + "GOV-02" ], - "16.1.1.9.P": [ - "IRO-01" + "5.2.3.C.02": [ + "GOV-02" ], - "16.1.1.10.P": [ - "IRO-01" + "11.1.15.C.01": [ + "GOV-02", + "HRS-05.3" ], - "16.1.1.11.P": [ - "IRO-01" + "11.1.15.C.02": [ + "GOV-02" ], - "16.1.1.12.P": [ - "IRO-01" + "11.3.5.C.01": [ + "GOV-02", + "AST-19" ], - "16.1.1": [ - "IRO-02" + "11.4.9.C.01": [ + "GOV-02", + "HRS-05.5" ], - "16.1.1.1": [ - "IRO-02" + "11.5.13.C.01": [ + "GOV-02", + "HRS-05.5" ], - "16.1.1.3": [ - "IRO-02" + "11.8.3.C.01": [ + "GOV-02", + "AST-19", + "AST-23" ], - "16.1.2": [ - "IRO-02" + "20.2.15.C.04": [ + "GOV-02", + "AST-01" ], - "16.1.2.1": [ - "IRO-02" + "21.1.6.C.01": [ + "GOV-02", + "SAT-03.3" ], - "16.1.2.2": [ - "IRO-02" + "22.1.10.C.01": [ + "GOV-02", + "MDM-01" ], - "16.1.2.3": [ - "IRO-02" + "22.1.22.C.01": [ + "GOV-02", + "CLD-09" ], - "16.1.2.4": [ - "IRO-02" + "5.1.21.C.01": [ + "GOV-03" ], - "16.1.2.5": [ - "IRO-02" + "5.1.21.C.02": [ + "GOV-03" ], - "16.1.2.6": [ - "IRO-02" + "3.1.8.C.01": [ + "GOV-04" ], - "16.1.2.7": [ - "IRO-02" + "3.1.8.C.02": [ + "GOV-04" ], - "16.1.2.8": [ - "IRO-02" + "3.1.8.C.03": [ + "GOV-04" ], - "16.1.2.9": [ - "IRO-02" + "3.1.9.C.01": [ + "GOV-04" ], - "16.1.2.10": [ - "IRO-02" + "3.2.8.C.01": [ + "GOV-04" ], - "16.1.2.11.P": [ - "IRO-02" + "3.2.8.C.02": [ + "GOV-04" ], - "16.1.2.12.P": [ - "IRO-02" + "3.2.8.C.03": [ + "GOV-04" ], - "16.1.2.13.P": [ - "IRO-02" + "3.2.8.C.04": [ + "GOV-04" ], - "16.1.3": [ - "IRO-02" + "3.2.8.C.05": [ + "GOV-04" ], - "16.1.3.1": [ - "IRO-02" + "3.2.10.C.01": [ + "GOV-04" ], - "16.1.3.2": [ - "IRO-02" + "3.2.10.C.02": [ + "GOV-04" ], - "16.1.5.9": [ - "IRO-02" + "3.2.10.C.03": [ + "GOV-04" ], - "16.1.4": [ - "IRO-02.4" + "3.2.10.C.04": [ + "GOV-04", + "GOV-15", + "GOV-15.1" ], - "16.1.4.1": [ - "IRO-02.4" + "3.2.11.C.01": [ + "GOV-04" ], - "16.1.4.2": [ - "IRO-02.4" + "3.2.11.C.02": [ + "GOV-04" ], - "16.1.5": [ - "IRO-04" + "3.2.11.C.03": [ + "GOV-04" ], - "16.1.5.1": [ - "IRO-04" + "3.2.12.C.01": [ + "GOV-04" ], - "16.1.5.2": [ - "IRO-04" + "3.2.12.C.02": [ + "GOV-04" ], - "16.1.5.3": [ - "IRO-04" + "3.2.12.C.03": [ + "GOV-04" ], - "16.1.5.4": [ - "IRO-04" + "3.2.13.C.01": [ + "GOV-04" ], - "16.1.5.5": [ - "IRO-04" + "3.2.13.C.02": [ + "GOV-04" ], - "16.1.5.6": [ - "IRO-04" + "3.2.14.C.01": [ + "GOV-04" ], - "16.1.5.7": [ - "IRO-04" + "3.2.15.C.01": [ + "GOV-04", + "PRM-01", + "PRM-02" ], - "16.1.5.8": [ - "IRO-04" + "3.2.16.C.01": [ + "GOV-04", + "IRO-09" ], - "16.1.1.14": [ - "IRO-04.3" + "3.2.17.C.01": [ + "GOV-04" ], - "16.1.7": [ - "IRO-08" + "3.2.18.C.01": [ + "GOV-04" ], - "16.1.7.1": [ - "IRO-08" + "3.2.19.C.01": [ + "GOV-04", + "PRM-08" ], - "16.1.7.2": [ - "IRO-08" + "20.2.16.C.03": [ + "GOV-10" ], - "16.1.7.3": [ - "IRO-08" + "3.4.11.C.01": [ + "GOV-15", + "GOV-15.2" ], - "16.1.7.4": [ - "IRO-08" + "23.2.16.C.03": [ + "GOV-15.4", + "IAO-07" ], - "16.1.7.5": [ - "IRO-08" + "23.2.16.C.04": [ + "GOV-15.4", + "IAO-07" ], - "16.1.7.6": [ - "IRO-08" + "23.2.18.C.01": [ + "GOV-15.5", + "CPL-02", + "CPL-03", + "CPL-03.2" ], - "16.1.7.7": [ - "IRO-08" + "8.4.9.C.01": [ + "AST-01", + "AST-02" ], - "16.1.7.8": [ - "IRO-08" + "20.2.15.C.07": [ + "AST-01", + "AST-02.9" ], - "16.1.7.9": [ - "IRO-08" + "8.4.8.C.01": [ + "AST-02" ], - "16.1.7.10": [ - "IRO-08" + "18.1.9.C.02": [ + "AST-04", + "NET-01" ], - "16.1.7.11": [ - "IRO-08" + "18.1.11.C.01": [ + "AST-04" ], - "16.1.7.12": [ - "IRO-08" + "18.1.12.C.01": [ + "AST-04" ], - "16.1.7.13.PB": [ - "IRO-08" + "18.1.12.C.02": [ + "AST-04" ], - "16.1.5.10": [ - "IRO-09.2" + "17.9.36.C.01": [ + "AST-05" ], - "6.1.3.2": [ - "IRO-10" + "8.5.3.C.01": [ + "AST-08" ], - "16.1.1.15.P": [ - "IRO-10.4" + "8.5.3.C.02": [ + "AST-08" ], - "16.1.6": [ - "IRO-13" + "8.5.3.C.03": [ + "AST-08" ], - "16.1.6.1": [ - "IRO-13" + "8.5.3.C.04": [ + "AST-08" ], - "16.1.6.2": [ - "IRO-13" + "8.5.4.C.01": [ + "AST-08" ], - "12.2.1.14": [ - "IRO-15" + "8.5.4.C.02": [ + "AST-08" ], - "14.1.1.12": [ - "IAO-02" + "8.5.4.C.03": [ + "AST-08" ], - "14.1.1.17": [ - "IAO-02" + "8.5.5.C.01": [ + "AST-08" ], - "14.1.1.18": [ - "IAO-02" + "11.2.13.C.01": [ + "AST-09", + "AST-23" ], - "14.2.7.4": [ - "IAO-02" + "11.7.35.C.01": [ + "AST-09", + "DCH-08" ], - "14.2.9": [ - "IAO-02" + "11.8.10.C.03": [ + "AST-09" ], - "14.2.9.1": [ - "IAO-02" + "11.8.10.C.05": [ + "AST-09" ], - "14.2.9.2": [ - "IAO-02" + "11.8.12.C.01": [ + "AST-09" ], - "14.2.9.3": [ - "IAO-02" + "11.8.12.C.02": [ + "AST-09" ], - "14.2.9.4": [ - "IAO-02" + "12.6.4.C.01": [ + "AST-09" ], - "4.4.5.2": [ - "IAO-03", - "PRM-01.2", - "PRM-05", - "PRM-06" + "12.6.4.C.02": [ + "AST-09" ], - "13.2.2": [ - "IAO-03.2" + "12.6.5.C.01": [ + "AST-09" ], - "13.2.2.2": [ - "IAO-03.2" + "12.6.5.C.02": [ + "AST-09" ], - "13.2.2.3": [ - "IAO-03.2" + "12.6.5.C.03": [ + "AST-09" ], - "13.2.2.4": [ - "IAO-03.2" + "12.6.5.C.04": [ + "AST-09" ], - "13.2.2.6": [ - "IAO-03.2" + "12.6.5.C.05": [ + "AST-09", + "DCH-09" ], - "13.2.2.7": [ - "IAO-03.2" + "12.6.8.C.01": [ + "AST-09" ], - "13.2.2.8": [ - "IAO-03.2" + "12.6.9.C.01": [ + "AST-09" ], - "13.2.2.9": [ - "IAO-03.2" + "12.6.10.C.01": [ + "AST-09" ], - "13.2.2.10": [ - "IAO-03.2" + "13.4.10.C.01": [ + "AST-09" ], - "13.2.2.11": [ - "IAO-03.2" + "13.4.19.C.02": [ + "AST-09", + "DCH-09" ], - "4.4.6.1": [ - "IAO-05", - "RSK-01", - "RSK-01.1", - "RSK-03", - "RSK-04", - "RSK-04.2", - "RSK-06.4" + "13.5.24.C.01": [ + "AST-09", + "DCH-08" ], - "4.7.1.4": [ - "IAO-05", - "RSK-06.4" + "13.5.24.C.02": [ + "AST-09", + "DCH-08" ], - "4.7.1.7": [ - "IAO-05" + "13.5.24.C.03": [ + "AST-09", + "DCH-08" ], - "11.2.4": [ - "MNT-01" + "13.5.24.C.04": [ + "AST-09", + "DCH-08" ], - "11.2.4.1": [ - "MNT-01" + "13.5.25.C.01": [ + "AST-09", + "DCH-08" ], - "11.2.4.3": [ - "MNT-01" + "13.5.26.C.01": [ + "AST-09", + "DCH-08" ], - "11.2.4.5": [ - "MNT-01" + "13.5.26.C.02": [ + "AST-09", + "DCH-08" ], - "11.2.4.4": [ - "MNT-02" + "13.5.26.C.03": [ + "AST-09", + "DCH-08" ], - "11.2.5": [ - "MNT-04.3" + "13.5.29.C.01": [ + "AST-09", + "DCH-08" ], - "11.2.5.1": [ - "MNT-04.3" + "13.5.29.C.02": [ + "AST-09", + "DCH-08" ], - "11.2.5.2": [ - "MNT-04.3" + "13.5.30.C.01": [ + "AST-09", + "DCH-08" ], - "11.2.5.3": [ - "MNT-04.3" + "13.6.6.C.01": [ + "AST-09" ], - "11.2.5.4": [ - "MNT-04.3" + "13.6.6.C.02": [ + "AST-09" ], - "11.2.4.8": [ - "MNT-05" + "13.6.7.C.01": [ + "AST-09" ], - "11.2.4.9": [ - "MNT-05" + "13.6.8.C.01": [ + "AST-09" ], - "11.2.4.10": [ - "MNT-05" + "13.6.9.C.01": [ + "AST-09" ], - "11.2.4.7": [ - "MNT-05.1", - "MNT-05.5" + "13.6.10.C.01": [ + "AST-09" ], - "11.2.4.11": [ - "MNT-05.4" + "13.6.10.C.02": [ + "AST-09" ], - "11.2.4.2": [ - "MNT-06" + "13.6.10.C.03": [ + "AST-09" ], - "11.2.6": [ - "MNT-09" + "13.6.11.C.01": [ + "AST-09" ], - "11.2.6.1": [ - "MNT-09" + "13.6.12.C.01": [ + "AST-09" ], - "11.2.6.2": [ - "MNT-09" + "17.6.6.C.01": [ + "AST-09", + "NET-13" ], - "11.2.6.3": [ - "MNT-09" + "11.1.19.C.03": [ + "AST-14.1" ], - "11.2.6.4": [ - "MNT-09" + "11.2.15.C.01": [ + "AST-14.2", + "HRS-05.3" ], - "11.2.6.5": [ - "MNT-09" + "11.2.15.C.02": [ + "AST-14.2", + "HRS-05.3" ], - "11.2.6.6": [ - "MNT-09" + "11.2.15.C.03": [ + "AST-14.2", + "HRS-05.3" ], - "11.2.4.6": [ - "MNT-10" + "8.1.12.C.01": [ + "AST-16", + "HRS-05", + "HRS-05.1", + "HRS-05.5", + "PES-04.2" ], - "6.2.1.23": [ + "21.1.12.C.01": [ + "AST-16", + "MDM-01", "MDM-06" ], - "5.1.1.18": [ - "NET-01" + "22.4.7.C.02": [ + "AST-16" ], - "13.1": [ - "NET-01" + "22.4.8.C.01": [ + "AST-16" ], - "13.1.1": [ - "NET-01" + "22.4.8.C.02": [ + "AST-16" ], - "13.1.1.1": [ - "NET-01" + "22.4.10.C.01": [ + "AST-16" ], - "13.1.1.2": [ - "NET-01" + "22.4.10.C.02": [ + "AST-16" ], - "13.1.1.3": [ - "NET-01" + "22.4.10.C.03": [ + "AST-16" ], - "13.1.1.5": [ - "NET-01" + "22.4.10.C.04": [ + "AST-16" ], - "13.1.1.6": [ - "NET-01" + "22.4.10.C.05": [ + "AST-16" ], - "13.1.1.7": [ - "NET-01" + "22.4.10.C.06": [ + "AST-16" ], - "13.1.1.8": [ - "NET-01" + "22.4.10.C.07": [ + "AST-16" ], - "13.1.1.9": [ - "NET-01" + "22.4.10.C.08": [ + "AST-16" ], - "13.1.2": [ - "NET-01", - "PRM-06", - "TPM-05" + "22.4.10.C.09": [ + "AST-16" ], - "9.1.1.16": [ - "NET-01.1" + "22.4.10.C.10": [ + "AST-16" ], - "14.1.1.23": [ - "NET-03.3" + "22.4.10.C.11": [ + "AST-16" ], - "13.1.1.10": [ - "NET-05.2" + "22.4.10.C.12": [ + "AST-16" ], - "13.1.3": [ - "NET-06" + "22.4.10.C.13": [ + "AST-16" ], - "13.1.3.1": [ - "NET-06" + "22.4.10.C.14": [ + "AST-16" ], - "13.1.3.2": [ - "NET-06" + "22.4.10.C.15": [ + "AST-16" ], - "13.1.3.3": [ - "NET-06" + "22.4.10.C.16": [ + "AST-16" ], - "13.1.3.4": [ - "NET-06" + "22.4.11.C.01": [ + "AST-16" ], - "13.1.3.5": [ - "NET-06" + "22.4.11.C.02": [ + "AST-16" ], - "13.1.3.6": [ - "NET-06" + "22.4.11.C.03": [ + "AST-16" ], - "13.1.3.7": [ - "NET-06" + "22.4.11.C.04": [ + "AST-16" ], - "13.1.3.8": [ - "NET-06" + "22.4.11.C.05": [ + "AST-16" ], - "13.1.3.9": [ - "NET-06" + "22.4.11.C.06": [ + "AST-16" ], - "13.1.3.10.P": [ - "NET-06" + "22.4.11.C.07": [ + "AST-16" ], - "13.1.3.11.P": [ - "NET-06" + "22.4.11.C.08": [ + "AST-16" ], - "13.1.3.12.P": [ - "NET-06" + "22.4.11.C.09": [ + "AST-16" ], - "13.1.4.P": [ - "NET-06", - "NET-06.1", - "NET-06.2", - "NET-06.3" + "22.4.11.C.10": [ + "AST-16" ], - "13.1.1.4": [ - "NET-12" + "22.4.11.C.11": [ + "AST-16" ], - "14.1.2": [ - "NET-12" + "22.4.11.C.12": [ + "AST-16" ], - "14.1.2.1": [ - "NET-12" + "22.4.11.C.13": [ + "AST-16" ], - "14.1.2.2": [ - "NET-12" + "22.4.11.C.14": [ + "AST-16" ], - "14.1.2.3": [ - "NET-12" + "22.4.11.C.15": [ + "AST-16" ], - "14.1.2.4": [ - "NET-12" + "22.4.11.C.16": [ + "AST-16" ], - "14.1.2.5": [ - "NET-12" + "22.4.11.C.17": [ + "AST-16" ], - "14.1.2.6": [ - "NET-12" + "22.4.11.C.18": [ + "AST-16" ], - "14.1.2.7": [ - "NET-12" + "22.4.11.C.19": [ + "AST-16" ], - "14.1.2.8": [ - "NET-12" + "22.4.11.C.20": [ + "AST-16" ], - "14.1.2.9": [ - "NET-12" + "22.4.12.C.01": [ + "AST-16" ], - "14.1.2.10": [ - "NET-12" + "22.4.13.C.01": [ + "AST-16" ], - "14.1.2.11": [ - "NET-12" + "22.4.13.C.02": [ + "AST-16" ], - "14.1.2.12": [ - "NET-12" + "22.4.13.C.03": [ + "AST-16" ], - "14.1.2.13": [ - "NET-12" + "22.4.13.C.04": [ + "AST-16" ], - "14.1.2.14": [ - "NET-12" + "22.4.13.C.05": [ + "AST-16" ], - "14.1.2.15": [ - "NET-12" + "22.4.13.C.06": [ + "AST-16" ], - "13.2.2.12": [ - "NET-13" + "22.4.13.C.07": [ + "AST-16" ], - "13.2.2.13": [ - "NET-13" + "22.4.13.C.08": [ + "AST-16" ], - "13.2.3": [ - "NET-13" + "22.4.13.C.09": [ + "AST-16" ], - "13.2.3.1": [ - "NET-13" + "22.4.13.C.10": [ + "AST-16" ], - "13.2.3.2": [ - "NET-13" + "22.4.13.C.11": [ + "AST-16" ], - "13.2.3.3": [ - "NET-13" + "22.4.14.C.01": [ + "AST-16" ], - "13.2.3.4": [ - "NET-13" + "22.4.14.C.02": [ + "AST-16" ], - "13.2.3.5": [ - "NET-13" + "22.4.14.C.03": [ + "AST-16" ], - "13.2.3.6": [ - "NET-13" + "22.4.14.C.04": [ + "AST-16" ], - "13.2.3.7.P": [ - "NET-13" + "11.3.6.C.01": [ + "AST-19" ], - "6.2": [ - "NET-14.5" + "11.3.6.C.02": [ + "AST-19" ], - "6.2.2": [ - "NET-14.5" + "11.3.7.C.01": [ + "AST-19" ], - "6.2.2.1": [ - "NET-14.5" + "11.3.8.C.01": [ + "AST-19" ], - "6.2.2.2": [ - "NET-14.5" + "11.3.9.C.01": [ + "AST-19" ], - "6.2.2.3": [ - "NET-14.5" + "11.3.9.C.02": [ + "AST-19" ], - "6.2.2.4": [ - "NET-14.5" + "11.3.10.C.01": [ + "AST-19" ], - "6.2.2.5": [ - "NET-14.5" + "11.3.11.C.01": [ + "AST-19" ], - "6.2.2.6": [ - "NET-14.5" + "11.3.12.C.01": [ + "AST-19" ], - "6.2.2.7": [ - "NET-14.5" + "11.3.12.C.02": [ + "AST-19" ], - "6.2.2.8": [ - "NET-14.5" + "11.3.12.C.03": [ + "AST-19" ], - "6.2.2.9": [ - "NET-14.5" + "11.3.13.C.01": [ + "AST-19", + "BCD-12.3" ], - "6.2.2.10": [ - "NET-14.5" + "11.3.13.C.02": [ + "AST-19", + "BCD-12.3" ], - "6.2.2.11": [ - "NET-14.5" + "11.3.13.C.03": [ + "AST-19", + "BCD-12.3" ], - "6.2.2.12": [ - "NET-14.5" + "11.8.4.C.01": [ + "AST-19", + "HRS-05.3" ], - "6.2.2.13": [ - "NET-14.5" + "11.8.5.C.01": [ + "AST-19", + "HRS-05.3" ], - "6.2.2.14": [ - "NET-14.5" + "18.3.14.C.01": [ + "AST-20", + "AST-21" ], - "6.2.2.15": [ - "NET-14.5" + "18.3.14.C.02": [ + "AST-20", + "AST-21" ], - "6.2.2.16": [ - "NET-14.5" + "18.3.8.C.01": [ + "AST-21" ], - "6.2.2.17": [ - "NET-14.5" + "18.3.9.C.01": [ + "AST-21" ], - "6.2.2.18": [ - "NET-14.5" + "18.3.9.C.02": [ + "AST-21" ], - "6.2.2.19": [ - "NET-14.5" + "18.3.10.C.01": [ + "AST-21" ], - "6.2.2.20": [ - "NET-14.5" + "18.3.11.C.01": [ + "AST-21" ], - "6.2.2.21": [ - "NET-14.5" + "18.3.11.C.02": [ + "AST-21" ], - "5.1.1.11": [ - "PES-01" + "18.3.12.C.01": [ + "AST-21" ], - "11.1": [ - "PES-01" + "18.3.12.C.02": [ + "AST-21" ], - "11.1.4": [ - "PES-01" + "18.3.13.C.01": [ + "AST-21" ], - "11.1.4.1": [ - "PES-01" + "18.3.13.C.02": [ + "AST-21" ], - "11.2.1.3": [ - "PES-01" + "18.3.13.C.03": [ + "AST-21" ], - "11.1.2.3": [ - "PES-02" + "18.3.15.C.01": [ + "AST-21" ], - "11.1.2.12": [ - "PES-02" + "18.3.15.C.02": [ + "AST-21" ], - "11.1.1": [ - "PES-03" + "18.3.16.C.01": [ + "AST-21" ], - "11.1.1.1": [ - "PES-03" + "18.3.16.C.02": [ + "AST-21" ], - "11.1.1.2": [ - "PES-03" + "18.3.16.C.03": [ + "AST-21" ], - "11.1.1.3": [ - "PES-03" + "18.3.17.C.01": [ + "AST-21" ], - "11.1.1.4": [ - "PES-03" + "11.2.11.C.01": [ + "AST-23" ], - "11.1.1.5": [ - "PES-03" + "11.2.11.C.02": [ + "AST-23" ], - "11.1.1.6": [ - "PES-03" + "11.2.12.C.01": [ + "AST-23" ], - "11.1.1.7": [ - "PES-03" + "11.8.7.C.01": [ + "AST-23" ], - "11.1.2": [ - "PES-03" + "11.8.8.C.01": [ + "AST-23" ], - "11.1.2.1": [ - "PES-03" + "11.8.13.C.01": [ + "AST-23" ], - "11.1.2.2": [ - "PES-03" + "3.4.10.C.01": [ + "AST-26", + "AST-28", + "HRS-03", + "TDA-04" ], - "11.1.2.5": [ - "PES-03" + "3.4.10.C.02": [ + "AST-26", + "AST-28", + "HRS-03", + "TDA-04" ], - "11.1.2.10": [ - "PES-03" + "5.1.11.C.01": [ + "AST-26", + "AST-28", + "OPS-01.1" ], - "11.1.2.7": [ - "PES-03.3" + "5.1.13.C.01": [ + "AST-26", + "AST-28", + "OPS-01.1" ], - "11.1.2.6": [ - "PES-04" + "5.5.3.C.01": [ + "AST-26", + "AST-28", + "OPS-01.1" ], - "11.1.3": [ - "PES-04" + "5.5.4.C.01": [ + "AST-26", + "AST-28", + "OPS-01.1" ], - "11.1.3.1": [ - "PES-04" + "5.5.5.C.01": [ + "AST-26", + "AST-28", + "OPS-01.1" ], - "11.1.3.2": [ - "PES-04" + "5.5.6.C.01": [ + "AST-26", + "AST-28", + "OPS-01.1" ], - "11.1.3.3": [ - "PES-04" + "18.6.10.C.01": [ + "AST-26" ], - "11.1.3.4": [ - "PES-04" + "11.6.59.C.01": [ + "AST-29" ], - "11.2.9": [ - "PES-04" + "11.6.59.C.02": [ + "AST-29" ], - "11.2.9.1": [ - "PES-04" + "11.6.60.C.01": [ + "AST-29" ], - "11.2.9.2": [ - "PES-04" + "11.6.60.C.02": [ + "AST-29" ], - "11.2.9.3": [ - "PES-04" + "11.6.60.C.03": [ + "AST-29" ], - "11.2.9.4": [ - "PES-04" + "11.6.60.C.04": [ + "AST-29" ], - "11.2.9.5": [ - "PES-04" + "11.6.61.C.01": [ + "AST-29" ], - "11.2.9.6": [ - "PES-04" + "11.6.61.C.02": [ + "AST-29" ], - "11.1.2.11": [ - "PES-04.1" + "11.6.62.C.01": [ + "AST-29" ], - "11.1.5": [ - "PES-04.1" + "11.6.62.C.02": [ + "AST-29" ], - "11.1.5.1": [ - "PES-04.1" + "11.6.62.C.03": [ + "AST-29" ], - "11.1.5.2": [ - "PES-04.1" + "11.6.63.C.01": [ + "AST-29" ], - "11.1.5.3": [ - "PES-04.1" + "11.6.63.C.02": [ + "AST-29" ], - "11.1.5.4": [ - "PES-04.1" + "11.6.64.C.01": [ + "AST-29" ], - "11.1.5.5": [ - "PES-04.1" + "11.6.65.C.01": [ + "AST-29" ], - "11.1.5.6": [ - "PES-04.1" + "11.6.65.C.02": [ + "AST-29" ], - "11.1.2.13": [ - "PES-05" + "11.6.65.C.03": [ + "AST-29" ], - "11.1.2.4": [ - "PES-06" + "11.6.66.C.01": [ + "AST-29" ], - "11.1.2.8": [ - "PES-06.1" + "11.6.67.C.01": [ + "AST-29" ], - "11.1.2.9": [ - "PES-06.3" + "11.6.67.C.02": [ + "AST-29" ], - "11.2.2": [ - "PES-07" + "11.6.68.C.01": [ + "AST-29" ], - "11.2.2.1": [ - "PES-07" + "11.6.69.C.01": [ + "AST-29" ], - "11.2.2.2": [ - "PES-07" + "11.6.70.C.01": [ + "AST-29" ], - "11.2.2.3": [ - "PES-07" + "11.6.71.C.01": [ + "AST-29" ], - "11.2.2.4": [ - "PES-07" + "11.7.29.C.01": [ + "AST-29.1" ], - "11.2.2.5": [ - "PES-07" + "11.7.29.C.02": [ + "AST-29.1" ], - "11.2.2.7": [ - "PES-07.2" + "11.7.30.C.01": [ + "AST-29.1" ], - "11.2.2.6": [ - "PES-07.4" + "11.7.30.C.02": [ + "AST-29.1" + ], + "11.7.30.C.03": [ + "AST-29.1" ], - "11.1.6": [ - "PES-10" + "11.7.31.C.01": [ + "AST-29.1" ], - "11.1.6.1": [ - "PES-10" + "11.7.31.C.02": [ + "AST-29.1" ], - "11.1.6.2": [ - "PES-10" + "11.7.32.C.01": [ + "AST-29.1" ], - "11.1.6.3": [ - "PES-10" + "11.7.32.C.02": [ + "AST-29.1" ], - "11.1.6.4": [ - "PES-10" + "11.7.32.C.03": [ + "AST-29.1" ], - "11.1.6.5": [ - "PES-10" + "11.7.32.C.04": [ + "AST-29.1" ], - "11.1.6.6": [ - "PES-10" + "11.7.33.C.01": [ + "AST-29.1" ], - "11.1.6.7": [ - "PES-10" + "11.7.33.C.02": [ + "AST-29.1" ], - "11.2": [ - "PES-12" + "11.7.33.C.03": [ + "AST-29.1" ], - "11.2.1": [ - "PES-12" + "11.7.34.C.01": [ + "AST-29.1" ], - "11.2.1.1": [ - "PES-12" + "2.3.30.C.01": [ + "AST-30", + "TPM-05" ], - "11.2.1.2": [ - "PES-12" + "13.1.9.C.01": [ + "AST-30" ], - "11.2.1.4": [ - "PES-12" + "13.1.10.C.01": [ + "AST-30" ], - "11.2.1.5": [ - "PES-12" + "13.1.10.C.02": [ + "AST-30" ], - "11.2.1.6": [ - "PES-12" + "13.1.10.C.03": [ + "AST-30" ], - "11.2.1.7": [ - "PES-12" + "13.1.10.C.04": [ + "AST-30" ], - "11.2.1.8": [ - "PES-12" + "13.1.11.C.01": [ + "AST-30" ], - "11.2.1.9": [ - "PES-12" + "13.1.12.C.01": [ + "AST-30" ], - "11.2.1.10": [ - "PES-12" + "13.1.12.C.02": [ + "AST-30" ], - "11.2.7.4.PB": [ - "PES-12" + "13.1.12.C.03": [ + "AST-30" ], - "11.2.3": [ - "PES-12.1" + "13.1.13.C.01": [ + "AST-30" ], - "11.2.3.1": [ - "PES-12.1" + "13.1.13.C.02": [ + "AST-30" ], - "11.2.3.2": [ - "PES-12.1" + "13.1.13.C.03": [ + "AST-30" ], - "11.2.3.3": [ - "PES-12.1" + "13.1.13.C.04": [ + "AST-30" ], - "5.1.1.19": [ - "PRI-01" + "13.1.14.C.01": [ + "AST-30" ], - "18.1.4": [ - "PRI-01", - "PRI-01.11" + "20.2.15.C.03": [ + "AST-30" ], - "7.1.1.12": [ - "PRI-01.11" + "20.2.15.C.06": [ + "AST-30" ], - "18.1.4.1": [ - "PRI-01.11" + "6.4.5.C.01": [ + "BCD-01" ], - "18.1.4.2": [ - "PRI-01.11" + "6.4.7.C.01": [ + "BCD-01" ], - "18.1.4.3": [ - "PRI-01.11" + "6.4.8.C.01": [ + "BCD-01" ], - "18.1.4.4": [ - "PRI-01.11" + "20.1.26.C.01": [ + "BCD-01" ], - "18.1.4.5": [ - "PRI-01.11" + "23.4.12.C.01": [ + "BCD-01" ], - "18.1.4.6": [ - "PRI-01.11" + "23.4.12.C.02": [ + "BCD-01" ], - "4.5.1.1": [ - "PRM-01", - "PRM-02", - "PRM-04", - "PRM-05", - "PRM-06" + "6.4.6.C.01": [ + "BCD-11" ], - "5.1.1.2": [ - "PRM-01.1" + "6.3.6.C.01": [ + "CHG-01" ], - "4.5.5.3": [ - "PRM-02", - "PRM-02.1", - "PRM-03" + "6.3.6.C.02": [ + "CHG-02" ], - "4.5.1.2": [ - "PRM-03" + "6.3.7.C.01": [ + "CHG-02" ], - "6.1.5": [ - "PRM-04" + "6.3.7.C.02": [ + "CHG-02" ], - "6.1.5.1": [ - "PRM-04" + "6.3.7.C.03": [ + "CHG-02" ], - "4.4.3.1": [ - "PRM-05", - "PRM-06" + "20.2.15.C.02": [ + "CHG-02.1" ], - "6.1.5.2": [ - "PRM-05" + "20.2.15.C.05": [ + "CHG-02.1" ], - "14.1.1.2": [ - "PRM-05", - "PRM-06", - "TDA-02" + "6.3.8.C.01": [ + "CHG-02.2", + "IAO-02", + "IAO-02.4", + "IAO-05" ], - "6.1.5.5": [ - "PRM-06" + "2.3.28.C.01": [ + "CLD-01", + "CLD-02", + "SEA-01", + "SEA-01.4", + "SEA-01.5" ], - "6.1.5.4": [ - "PRM-07" + "20.1.20.C.01": [ + "CLD-01" ], - "14.1": [ - "PRM-07" + "20.1.20.C.02": [ + "CLD-01" ], - "4.5.5.2": [ - "RSK-01", - "RSK-06.4" + "20.1.20.C.03": [ + "CLD-01" ], - "4.4.7.2": [ - "RSK-01.1", - "RSK-03", - "RSK-03.1", - "RSK-04", - "RSK-04.1" + "20.1.20.C.04": [ + "CLD-01" ], - "4.4.7.3": [ - "RSK-01.1", - "RSK-04", - "RSK-04.3", - "RSK-08" + "22.1.20.C.01": [ + "CLD-01" ], - "4.4.7.1": [ - "RSK-01.3", - "RSK-01.4", - "RSK-01.5", - "RSK-04", - "RSK-04.2", - "RSK-06.3", - "RSK-06.4" + "22.1.20.C.02": [ + "CLD-01" ], - "6.1.5.3": [ - "RSK-04" + "22.1.20.C.03": [ + "CLD-01" ], - "4.5.5.1": [ - "RSK-04.3" + "22.1.21.C.01": [ + "CLD-01" ], - "4.4.8.1": [ - "RSK-06.1", - "RSK-06.2", - "RSK-06.3", - "RSK-06.4" + "23.1.54.C.01": [ + "CLD-01", + "CLD-02" ], - "4.4.8.2": [ - "RSK-06.1", - "RSK-06.2", - "RSK-06.3", - "RSK-06.4" + "23.1.54.C.02": [ + "CLD-01", + "CLD-02" ], - "4.4.8.5": [ - "RSK-06.1", - "RSK-06.4" + "23.2.19.C.01": [ + "CLD-01", + "TPM-01", + "TPM-05", + "VPM-02", + "VPM-04", + "VPM-05" ], - "4.7.1.3": [ - "RSK-06.1" + "23.4.9.C.01": [ + "CLD-01.1" ], - "4.7.1.6": [ - "RSK-06.1" + "23.4.9.C.02": [ + "CLD-01.1", + "CRY-09", + "CRY-09.7" ], - "4.4.8.3": [ - "RSK-06.4" + "23.4.9.C.03": [ + "CLD-01.1", + "CRY-09", + "CRY-09.7" ], - "4.4.8.4": [ - "RSK-06.4" + "23.4.10.C.01": [ + "CLD-01.1", + "IAC-21" ], - "4.9": [ - "RSK-06.4", - "THR-03", - "THR-03.1" + "23.5.11.C.01": [ + "CLD-01.1", + "CLD-06.2" ], - "14.2.5": [ - "SEA-01" + "23.5.12.C.01": [ + "CLD-01.1", + "CLD-06.2", + "CLD-06.4" ], - "14.2.5.1": [ - "SEA-01" + "23.5.12.C.02": [ + "CLD-01.1", + "CLD-06.2", + "CLD-06.4" ], - "14.2.5.2": [ - "SEA-01" + "20.1.26.C.02": [ + "CLD-01.2" ], - "14.2.5.3": [ - "SEA-01" + "20.1.26.C.03": [ + "CLD-01.2" ], - "14.2.5.4": [ - "SEA-01" + "23.4.13.C.01": [ + "CLD-01.2" ], - "14.2.5.5": [ - "SEA-01" + "23.4.13.C.02": [ + "CLD-01.2" ], - "14.2.5.6": [ - "SEA-01" + "23.4.13.C.03": [ + "CLD-01.2" ], - "14.2.5.7": [ - "SEA-01" + "20.1.24.C.02": [ + "CLD-02" ], - "4.5.4.5": [ - "SEA-02.2" + "20.1.24.C.03": [ + "CLD-02" ], - "9.5.P": [ - "SEA-05" + "20.1.24.C.04": [ + "CLD-02" ], - "12.4.4": [ - "SEA-20" + "20.2.12.C.01": [ + "CLD-02", + "NET-02.3", + "SEA-13.1" ], - "12.4.4.1": [ - "SEA-20" + "20.2.12.C.02": [ + "CLD-02", + "NET-02.3", + "SEA-13.1" ], - "12.4.4.2": [ - "SEA-20" + "23.1.56.C.01": [ + "CLD-02" ], - "12.4.4.3": [ - "SEA-20" + "23.2.20.C.01": [ + "CLD-02", + "CLD-06" ], - "12.4.4.4.PB": [ - "SEA-20" + "23.1.55.C.01": [ + "CLD-06", + "CLD-06.1" ], - "12.1": [ - "OPS-01" + "23.1.55.C.02": [ + "CLD-06", + "CLD-06.1" ], - "12.1.3.9.PB": [ - "OPS-01" + "23.1.55.C.03": [ + "CLD-06", + "CLD-06.1" ], - "8.3.1.11": [ - "OPS-01.1" + "20.1.21.C.03": [ + "CLD-06.1" ], - "12.1.1": [ - "OPS-01.1" + "20.1.22.C.01": [ + "CLD-09", + "IAO-07" ], - "12.1.1.1": [ - "OPS-01.1" + "20.1.22.C.02": [ + "CLD-09" ], - "12.1.1.2": [ - "OPS-01.1" + "20.1.22.C.03": [ + "CLD-09", + "IAO-02", + "IAO-07" ], - "12.1.1.3": [ - "OPS-01.1" + "20.1.22.C.04": [ + "CLD-09" ], - "12.1.1.4": [ - "OPS-01.1" + "20.1.22.C.05": [ + "CLD-09", + "IAO-07" ], - "12.1.1.5": [ - "OPS-01.1" + "20.1.22.C.06": [ + "CLD-09" ], - "12.1.1.6": [ - "OPS-01.1" + "22.1.22.C.02": [ + "CLD-09" ], - "12.1.1.7": [ - "OPS-01.1" + "23.4.11.C.01": [ + "CLD-09" ], - "12.1.1.8": [ - "OPS-01.1" + "23.4.11.C.02": [ + "CLD-09" ], - "12.1.1.9": [ - "OPS-01.1" + "1.1.64.C.01": [ + "CPL-01" ], - "12.1.1.10": [ - "OPS-01.1" + "1.1.65.C.01": [ + "CPL-01" ], - "12.1.1.11": [ - "OPS-01.1" + "1.1.66.C.01": [ + "CPL-01" ], - "12.1.1.12": [ - "OPS-01.1" + "1.1.66.C.02": [ + "CPL-01" ], - "12.1.1.13": [ - "OPS-01.1" + "1.1.67.C.01": [ + "CPL-01" ], - "12.1.5.P": [ - "OPS-01.1" + "1.2.15.C.01": [ + "CPL-01", + "SEA-01.4" ], - "12.1.5.1.PB": [ - "OPS-01.1" + "1.2.15.C.02": [ + "CPL-01" ], - "13.1.1.11.P": [ - "OPS-03" + "17.9.37.C.01": [ + "CPL-01" ], - "13.1.4.1.P": [ - "OPS-03" + "1.1.68.C.01": [ + "CPL-01.1" ], - "13.1.4.2.P": [ - "OPS-03" + "1.1.69.C.01": [ + "CPL-01.1" ], - "14.1.1.19.P": [ - "OPS-03" + "1.1.69.C.02": [ + "CPL-01.1" ], - "14.1.1.20.P": [ - "OPS-03" + "6.1.7.C.01": [ + "CPL-02", + "CPL-03", + "CPL-03.2" ], - "7.2.2.1": [ - "SAT-01" + "17.9.33.C.01": [ + "CPL-02.2" ], - "7.2.2.2": [ - "SAT-01" + "17.9.33.C.02": [ + "CPL-02.2" ], - "7.2.2.3": [ - "SAT-01" + "17.9.33.C.03": [ + "CPL-02.2" ], - "7.2.2.4": [ - "SAT-01" + "4.3.16.C.01": [ + "CPL-03", + "IAO-02.1", + "IAO-02.3" ], - "7.2.2.5": [ - "SAT-01" + "6.1.9.C.01": [ + "CPL-03", + "CPL-03.2" ], - "7.2.2.6": [ - "SAT-01" + "6.1.8.C.01": [ + "CPL-03.1" ], - "7.2.2.17": [ - "SAT-01" + "4.3.19.C.01": [ + "CFG-01", + "CFG-01.1", + "SEA-01.1" ], - "7.2.2.18": [ - "SAT-01" + "12.2.5.C.01": [ + "CFG-01" ], - "4.5.2.4": [ - "SAT-01.1", - "SAT-03", - "SAT-03.7", - "SAT-04" + "12.2.5.C.02": [ + "CFG-01" ], - "4.5.2.5": [ - "SAT-01.1", - "SAT-04" + "12.2.6.C.01": [ + "CFG-01" ], - "6.2.1.20": [ - "SAT-02" + "12.2.6.C.02": [ + "CFG-01" ], - "7.2.2": [ - "SAT-02" + "17.9.38.C.03": [ + "CFG-01" ], - "7.2.2.7": [ - "SAT-02" + "18.1.10.C.01": [ + "CFG-01", + "CFG-02.4", + "CFG-02.5", + "CFG-02.6" ], - "7.2.2.8": [ - "SAT-02" + "18.1.10.C.02": [ + "CFG-01", + "CFG-02.4", + "CFG-02.5", + "CFG-02.6" ], - "7.2.2.9": [ - "SAT-02" + "18.1.10.C.03": [ + "CFG-01", + "CFG-02.4", + "CFG-02.5", + "CFG-02.6" ], - "7.2.2.10": [ - "SAT-02" + "18.1.10.C.04": [ + "CFG-01", + "CFG-02.4", + "CFG-02.5", + "CFG-02.6" ], - "7.2.2.11": [ - "SAT-02" + "20.2.14.C.02": [ + "CFG-01" ], - "7.2.2.12": [ - "SAT-02" + "11.1.16.C.01": [ + "CFG-02" ], - "7.2.2.13": [ - "SAT-02" + "11.1.16.C.02": [ + "CFG-02" ], - "7.2.2.15": [ - "SAT-02" + "11.1.17.C.01": [ + "CFG-02" ], - "7.2.2.25": [ - "SAT-02" + "11.1.17.C.03": [ + "CFG-02" ], - "7.2.1.6": [ - "SAT-03" + "11.8.6.C.01": [ + "CFG-02", + "HRS-05.3" ], - "7.2.2.14": [ - "SAT-03" + "11.8.6.C.02": [ + "CFG-02", + "HRS-05.3" ], - "7.2.2.19.PB": [ - "SAT-03", - "SAT-03.3" + "14.1.8.C.01": [ + "CFG-02" ], - "7.2.2.16": [ - "SAT-03.3" + "14.1.9.C.01": [ + "CFG-02" ], - "14.2": [ - "TDA-01" + "14.1.9.C.02": [ + "CFG-02", + "END-04" ], - "14.2.1": [ - "TDA-01" + "14.1.10.C.01": [ + "CFG-02" ], - "14.2.1.13.PB": [ - "TDA-01" + "14.1.10.C.02": [ + "CFG-02" ], - "14.2.7": [ - "TDA-01" + "14.3.7.C.01": [ + "CFG-02" ], - "14.1.1": [ - "TDA-01.1" + "15.2.41.C.01": [ + "CFG-02" ], - "14.2.7.11": [ - "TDA-01.1" + "15.2.41.C.02": [ + "CFG-02" ], - "14.1.1.3": [ - "TDA-02" + "15.2.42.C.01": [ + "CFG-02" ], - "14.1.1.4": [ - "TDA-02" + "15.2.43.C.01": [ + "CFG-02" ], - "14.1.1.5": [ - "TDA-02" + "15.2.44.C.01": [ + "CFG-02" ], - "14.1.1.6": [ - "TDA-02" + "15.2.46.C.01": [ + "CFG-02" ], - "14.1.1.7": [ - "TDA-02" + "15.2.46.C.03": [ + "CFG-02" ], - "14.1.1.8": [ - "TDA-02" + "15.2.47.C.01": [ + "CFG-02" ], - "14.1.1.9": [ - "TDA-02" + "15.2.47.C.02": [ + "CFG-02" ], - "14.1.1.10": [ - "TDA-02" + "15.2.48.C.01": [ + "CFG-02" ], - "14.1.1.11": [ - "TDA-02" + "15.2.48.C.02": [ + "CFG-02" ], - "14.1.1.16": [ - "TDA-02" + "15.2.48.C.03": [ + "CFG-02" ], - "14.2.1.3": [ - "TDA-02" + "15.2.49.C.01": [ + "CFG-02" ], - "14.1.1.15": [ - "TDA-04" + "15.2.49.C.02": [ + "CFG-02" ], - "14.2.7.10": [ - "TDA-04" + "15.2.49.C.03": [ + "CFG-02" ], - "14.1.1.1": [ - "TDA-06" + "15.2.50.C.01": [ + "CFG-02" ], - "14.2.1.2": [ - "TDA-06" + "15.2.50.C.02": [ + "CFG-02" ], - "14.2.1.9": [ - "TDA-06" + "15.2.50.C.03": [ + "CFG-02" ], - "14.2.1.10": [ - "TDA-06" + "15.2.50.C.04": [ + "CFG-02" ], - "14.2.7.3": [ - "TDA-06.2" + "16.1.31.C.03": [ + "CFG-02" ], - "14.2.1.1": [ - "TDA-07" + "16.1.31.C.04": [ + "CFG-02" ], - "14.2.6": [ - "TDA-07" + "16.1.31.C.05": [ + "CFG-02" ], - "14.2.6.1": [ - "TDA-07" + "16.7.42.C.01": [ + "CFG-02", + "IAC-06" ], - "14.2.6.2": [ - "TDA-07" + "20.2.14.C.05": [ + "CFG-02" ], - "14.2.6.3": [ - "TDA-07" + "20.2.14.C.07": [ + "CFG-02", + "SEA-13.1" ], - "14.2.6.4": [ - "TDA-07" + "22.1.16.C.01": [ + "CFG-02" ], - "14.2.6.5": [ - "TDA-07" + "22.1.16.C.02": [ + "CFG-02" ], - "14.2.6.6": [ - "TDA-07" + "22.1.17.C.01": [ + "CFG-02" ], - "14.2.6.7": [ - "TDA-07" + "22.1.17.C.02": [ + "CFG-02" ], - "14.2.6.8": [ - "TDA-07" + "22.1.17.C.03": [ + "CFG-02" ], - "14.2.6.9": [ - "TDA-07" + "22.1.19.C.01": [ + "CFG-02" ], - "14.2.6.10": [ - "TDA-07" + "22.1.19.C.02": [ + "CFG-02" ], - "14.2.6.11": [ - "TDA-07", - "TDA-08.1" + "23.2.21.C.01": [ + "CFG-02", + "CFG-02.5" ], - "14.2.6.12": [ - "TDA-07" + "15.2.45.C.01": [ + "CFG-02.1" ], - "12.1.4": [ - "TDA-08" + "15.2.38.C.01": [ + "CFG-02.5" ], - "12.1.4.1": [ - "TDA-08" + "18.1.15.C.01": [ + "CFG-03", + "TDA-02.1" ], - "12.1.4.2": [ - "TDA-08" + "18.1.15.C.02": [ + "CFG-03", + "TDA-02.1" ], - "12.1.4.3": [ - "TDA-08" + "18.1.15.C.03": [ + "CFG-03", + "TDA-02.1" ], - "12.1.4.4": [ - "TDA-08" + "18.1.15.C.04": [ + "CFG-03", + "TDA-02.1" ], - "12.1.4.5": [ - "TDA-08" + "14.2.4.C.01": [ + "CFG-03.3" ], - "12.1.4.6": [ - "TDA-08" + "14.2.5.C.01": [ + "CFG-03.3" ], - "12.1.4.7": [ - "TDA-08" + "14.2.5.C.02": [ + "CFG-03.3" ], - "12.1.4.8": [ - "TDA-08" + "14.2.5.C.03": [ + "CFG-03.3" ], - "12.1.4.9": [ - "TDA-08" + "14.2.5.C.04": [ + "CFG-03.3" ], - "14.2.1.4": [ - "TDA-09" + "14.2.6.C.01": [ + "CFG-03.3" ], - "14.2.7.5": [ - "TDA-09" + "14.2.7.C.01": [ + "CFG-03.3" ], - "14.2.7.6": [ - "TDA-09" + "14.2.7.C.02": [ + "CFG-03.3" ], - "14.2.7.7": [ - "TDA-09" + "14.2.7.C.03": [ + "CFG-03.3" ], - "14.2.8": [ - "TDA-09" + "14.2.7.C.04": [ + "CFG-03.3" ], - "14.2.8.1": [ - "TDA-09" + "14.2.7.C.05": [ + "CFG-03.3" ], - "14.2.8.2": [ - "TDA-09" + "14.2.7.C.06": [ + "CFG-03.3" ], - "14.2.8.3": [ - "TDA-09" + "14.2.7.C.07": [ + "CFG-03.3" ], - "14.3": [ - "TDA-10" + "21.3.12.C.02": [ + "CFG-03.3" ], - "14.3.1": [ - "TDA-10" + "18.7.14.C.01": [ + "CFG-03.4" ], - "14.3.1.1": [ - "TDA-10" + "18.7.14.C.02": [ + "CFG-03.4" ], - "14.3.1.2": [ - "TDA-10" + "16.6.6.C.01": [ + "MON-01", + "MON-01.16" ], - "14.3.1.3": [ - "TDA-10" + "16.6.6.C.02": [ + "MON-01", + "MON-01.16" ], - "14.3.1.4": [ - "TDA-10" + "16.6.8.C.01": [ + "MON-01", + "MON-01.16", + "MON-03.2" ], - "14.3.1.5": [ - "TDA-10" + "16.6.10.C.01": [ + "MON-01", + "MON-01.1", + "MON-01.3", + "MON-01.5", + "MON-01.7", + "MON-01.9", + "MON-01.16", + "MON-03", + "MON-03.2", + "MON-03.7" ], - "14.3.1.6": [ - "TDA-10" + "16.6.10.C.02": [ + "MON-01", + "MON-01.1", + "MON-01.3", + "MON-01.5", + "MON-01.7", + "MON-01.9", + "MON-01.16", + "MON-03", + "MON-03.2", + "MON-03.7" ], - "14.2.5.9": [ - "TDA-18" + "18.4.7.C.01": [ + "MON-01.1" ], - "9.4.5": [ - "TDA-20" + "18.4.7.C.02": [ + "MON-01.1" ], - "9.4.5.1": [ - "TDA-20" + "18.4.7.C.03": [ + "MON-01.1" ], - "9.4.5.2": [ - "TDA-20" + "18.4.8.C.01": [ + "MON-01.1", + "MON-01.3", + "MON-01.5" ], - "9.4.5.3": [ - "TDA-20" + "18.4.8.C.02": [ + "MON-01.1", + "MON-01.3", + "MON-01.5" ], - "9.4.5.4": [ - "TDA-20" + "18.4.8.C.03": [ + "MON-01.1", + "MON-01.3", + "MON-01.5" ], - "9.4.5.5": [ - "TDA-20" + "18.4.9.C.01": [ + "MON-01.1" ], - "9.4.5.6": [ - "TDA-20" + "18.4.9.C.02": [ + "MON-01.1" ], - "9.4.5.7": [ - "TDA-20" + "18.4.10.C.01": [ + "MON-01.1" ], - "9.4.5.8": [ - "TDA-20" + "18.4.11.C.01": [ + "MON-01.1" ], - "9.4.5.9": [ - "TDA-20" + "18.4.11.C.02": [ + "MON-01.1" ], - "14.2.1.5": [ - "TDA-20" + "18.4.11.C.03": [ + "MON-01.1" ], - "14.2.1.6": [ - "TDA-20.1" + "18.4.12.C.01": [ + "MON-01.1", + "MON-02.1" ], - "14.2.7.8": [ - "TDA-20.3" + "18.4.14.C.01": [ + "MON-01.1" ], - "5.1.1.20": [ - "TPM-01" + "16.6.15.C.01": [ + "MON-01.2" ], - "5.1.1.31.P": [ - "TPM-01" + "16.6.15.C.02": [ + "MON-01.2" ], - "15.1": [ - "TPM-01" + "15.2.40.C.02": [ + "MON-01.3" ], - "15.1.1": [ - "TPM-01" + "14.3.6.C.02": [ + "MON-01.9", + "NET-18", + "NET-18.1" ], - "15.1.1.1": [ - "TPM-01" + "16.6.11.C.01": [ + "MON-02", + "MON-02.2" ], - "15.1.1.2": [ - "TPM-01" + "16.6.11.C.02": [ + "MON-02", + "MON-02.2", + "MON-02.7" ], - "15.1.1.3": [ - "TPM-01" + "16.6.11.C.03": [ + "MON-02", + "MON-02.2" ], - "15.1.1.4": [ - "TPM-01" + "16.6.12.C.01": [ + "MON-02", + "MON-02.2" ], - "15.1.1.5": [ - "TPM-01" + "16.6.12.C.02": [ + "MON-02", + "MON-02.2" ], - "15.1.1.6": [ - "TPM-01" + "16.6.12.C.03": [ + "MON-02", + "MON-02.2" ], - "15.1.1.7": [ - "TPM-01" + "16.6.14.C.01": [ + "MON-02.1" ], - "15.1.1.8": [ - "TPM-01" + "16.6.7.C.01": [ + "MON-03", + "MON-03.7" ], - "15.1.1.9": [ - "TPM-01" + "16.6.9.C.01": [ + "MON-03", + "MON-03.2", + "MON-03.7" ], - "15.1.1.10": [ - "TPM-01" + "16.4.41.C.01": [ + "MON-03.3" ], - "15.1.1.11": [ - "TPM-01" + "16.4.41.C.02": [ + "MON-03.3" ], - "15.1.1.12": [ - "TPM-01" + "16.6.13.C.01": [ + "MON-04", + "MON-08", + "MON-08.1" ], - "15.1.1.13": [ - "TPM-01" + "16.6.13.C.02": [ + "MON-04", + "MON-08", + "MON-08.1" ], - "15.1.1.14.B": [ - "TPM-01" + "16.6.13.C.03": [ + "MON-04", + "MON-08", + "MON-08.1" ], - "14.1.1.14": [ - "TPM-04.1" + "16.6.13.C.04": [ + "MON-04", + "MON-08", + "MON-08.1" ], - "15.1.1.16.B": [ - "TPM-04.1" + "16.4.41.C.03": [ + "MON-08.2" ], - "6.3.P": [ - "TPM-05" + "16.6.13.C.05": [ + "MON-10" ], - "7.1.1.11": [ - "TPM-05" + "8.4.13.C.01": [ + "CRY-01", + "CRY-05", + "CRY-05.1", + "DCH-06", + "DCH-06.4", + "DCH-07.2" ], - "8.2.3.7": [ - "TPM-05" + "17.1.52.C.01": [ + "CRY-01" ], - "13.1.2.2": [ - "TPM-05" + "17.1.52.C.02": [ + "CRY-01" ], - "14.1.1.13": [ - "TPM-05" + "17.1.53.C.01": [ + "CRY-01" ], - "14.2.1.12": [ - "TPM-05" + "17.1.53.C.02": [ + "CRY-01" ], - "14.2.7.2": [ - "TPM-05" + "17.1.53.C.03": [ + "CRY-01" ], - "14.2.7.9": [ - "TPM-05" + "17.1.53.C.04": [ + "CRY-01" ], - "15.1.2": [ - "TPM-05" + "17.1.54.C.01": [ + "CRY-01" ], - "15.1.2.1": [ - "TPM-05" + "17.1.55.C.01": [ + "CRY-01" ], - "15.1.2.2": [ - "TPM-05" + "17.1.55.C.02": [ + "CRY-01" ], - "15.1.2.3": [ - "TPM-05" + "17.1.55.C.03": [ + "CRY-01" ], - "15.1.2.4": [ - "TPM-05" + "17.1.55.C.04": [ + "CRY-01" ], - "15.1.2.5": [ - "TPM-05" + "17.1.56.C.01": [ + "CRY-01" ], - "15.1.2.6": [ - "TPM-05" + "17.1.56.C.02": [ + "CRY-01" + ], + "17.1.57.C.01": [ + "CRY-01" ], - "15.1.2.7": [ - "TPM-05" + "17.2.17.C.01": [ + "CRY-01" ], - "15.1.2.8": [ - "TPM-05" + "17.2.18.C.01": [ + "CRY-01" ], - "15.1.2.9": [ - "TPM-05" + "17.2.19.C.01": [ + "CRY-01" ], - "15.1.2.10": [ - "TPM-05" + "17.2.20.C.01": [ + "CRY-01" ], - "15.1.2.11": [ - "TPM-05" + "17.2.20.C.02": [ + "CRY-01" ], - "15.1.2.12": [ - "TPM-05" + "17.2.21.C.01": [ + "CRY-01" ], - "15.1.2.13": [ - "TPM-05" + "17.2.22.C.01": [ + "CRY-01" ], - "15.1.2.14": [ - "TPM-05" + "17.2.22.C.02": [ + "CRY-01" ], - "15.1.2.15": [ - "TPM-05" + "17.2.23.C.01": [ + "CRY-01" ], - "15.1.2.16": [ - "TPM-05" + "17.2.24.C.01": [ + "CRY-01" ], - "15.1.2.17": [ - "TPM-05" + "17.2.24.C.02": [ + "CRY-01" ], - "15.1.2.18.PB": [ - "TPM-05" + "17.2.24.C.03": [ + "CRY-01" ], - "15.1.3": [ - "TPM-05" + "17.2.25.C.01": [ + "CRY-01" ], - "15.1.3.1": [ - "TPM-05" + "17.2.26.C.01": [ + "CRY-01" ], - "15.1.3.2": [ - "TPM-05" + "17.2.26.C.02": [ + "CRY-01" ], - "15.1.3.3": [ - "TPM-05" + "17.2.26.C.03": [ + "CRY-01" ], - "15.1.3.4": [ - "TPM-05" + "17.2.27.C.01": [ + "CRY-01" ], - "15.1.3.5": [ - "TPM-05" + "17.2.27.C.02": [ + "CRY-01" ], - "15.1.3.6": [ - "TPM-05" + "17.2.27.C.03": [ + "CRY-01" ], - "15.1.3.7": [ - "TPM-05" + "17.2.28.C.01": [ + "CRY-01" ], - "15.1.3.8": [ - "TPM-05" + "17.3.6.C.01": [ + "CRY-01" ], - "15.1.3.9": [ - "TPM-05" + "17.4.16.C.01": [ + "CRY-01" ], - "15.1.3.10.P": [ - "TPM-05" + "17.4.16.C.02": [ + "CRY-01" ], - "15.1.3.11.P": [ - "TPM-05" + "17.5.6.C.01": [ + "CRY-01", + "NET-14" ], - "15.2": [ - "TPM-05" + "17.6.7.C.01": [ + "CRY-01", + "NET-13" ], - "6.1.1.8": [ - "TPM-05.4" + "17.7.6.C.01": [ + "CRY-01" ], - "6.1.1.9": [ - "TPM-05.4" + "17.8.10.C.01": [ + "CRY-01" ], - "6.1.1.10": [ - "TPM-05.4" + "17.8.10.C.02": [ + "CRY-01" ], - "6.1.1.11": [ - "TPM-05.4" + "17.8.11.C.01": [ + "CRY-01" ], - "6.1.1.12": [ - "TPM-05.4" + "17.8.12.C.01": [ + "CRY-01" ], - "6.1.5.6": [ - "TPM-05.4" + "17.8.13.C.01": [ + "CRY-01" ], - "6.3.1.P": [ - "TPM-05.4" + "17.8.14.C.01": [ + "CRY-01" ], - "13.1.2.1": [ - "TPM-08" + "17.8.15.C.01": [ + "CRY-01" ], - "15.2.1": [ - "TPM-08" + "17.8.16.C.01": [ + "CRY-01" ], - "15.2.1.1": [ - "TPM-08" + "17.8.17.C.01": [ + "CRY-01" ], - "15.2.1.2": [ - "TPM-08" + "17.9.30.C.01": [ + "CRY-01" ], - "15.2.1.3": [ - "TPM-08" + "17.9.30.C.02": [ + "CRY-01" ], - "15.2.1.4": [ - "TPM-08" + "17.9.30.C.03": [ + "CRY-01" ], - "15.2.1.5": [ - "TPM-08" + "17.9.31.C.01": [ + "CRY-01" ], - "15.2.1.6": [ - "TPM-08" + "17.9.32.C.01": [ + "CRY-01" ], - "15.2.1.7": [ - "TPM-08" + "17.9.32.C.02": [ + "CRY-01" ], - "15.2.1.8": [ - "TPM-08" + "17.9.38.C.01": [ + "CRY-01" ], - "15.2.1.9": [ - "TPM-08" + "17.9.38.C.02": [ + "CRY-01" ], - "15.2.1.10": [ - "TPM-08" + "17.9.34.C.01": [ + "CRY-01.5" ], - "15.2.1.11": [ - "TPM-08" + "18.2.9.C.01": [ + "CRY-07" ], - "15.2.1.12": [ - "TPM-08" + "18.2.9.C.02": [ + "CRY-07" ], - "15.2.1.13": [ - "TPM-08" + "18.2.10.C.01": [ + "CRY-07", + "NET-15.1" ], - "15.2.1.14": [ - "TPM-10" + "18.2.10.C.02": [ + "CRY-07", + "NET-15.1" ], - "15.2.1.15": [ - "TPM-10" + "18.2.11.C.01": [ + "CRY-07", + "NET-15.1" ], - "15.2.2": [ - "TPM-10" + "18.2.11.C.02": [ + "CRY-07", + "NET-15.1" ], - "15.2.2.1": [ - "TPM-10" + "18.2.11.C.03": [ + "CRY-07", + "NET-15.1" ], - "15.2.2.2": [ - "TPM-10" + "18.2.11.C.04": [ + "CRY-07", + "NET-15.1" ], - "15.2.2.3": [ - "TPM-10" + "18.2.11.C.05": [ + "CRY-07", + "NET-15.1" ], - "5.1.1.4": [ - "THR-01" + "18.2.12.C.01": [ + "CRY-07", + "NET-15.1" ], - "4.9.2.2": [ - "THR-03", - "THR-03.1" + "18.2.12.C.02": [ + "CRY-07", + "NET-15.1" ], - "12.2.1.12": [ - "THR-03" + "18.2.13.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.2.1.13": [ - "THR-03" + "18.2.14.C.01": [ + "CRY-07", + "NET-15.1" ], - "4.9.1.1": [ - "THR-03.1" + "18.2.15.C.01": [ + "CRY-07", + "NET-15.1" ], - "4.9.2.1": [ - "THR-03.1" + "18.2.16.C.01": [ + "CRY-07", + "NET-15.1" ], - "5.1.1.16": [ - "VPM-01" + "18.2.17.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.6": [ - "VPM-01" + "18.2.18.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.6.1": [ - "VPM-01" + "18.2.19.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.1": [ - "VPM-01" + "18.2.20.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.2": [ - "VPM-01" + "18.2.20.C.02": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.3": [ - "VPM-01" + "18.2.20.C.03": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.4": [ - "VPM-01" + "18.2.21.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.5": [ - "VPM-01" + "18.2.22.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.6": [ - "VPM-01" + "18.2.23.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.7": [ - "VPM-01" + "18.2.23.C.02": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.8": [ - "VPM-01" + "18.2.24.C.01": [ + "CRY-07", + "NET-15.1" ], - "12.6.1.9": [ - "VPM-01" + "18.2.25.C.01": [ + "CRY-07", + "NET-15", + "NET-15.1" ], - "12.6.1.11": [ - "VPM-01" + "17.1.51.C.01": [ + "CRY-08", + "CRY-08.1", + "CRY-09" ], - "12.6.1.12": [ - "VPM-01" + "23.3.21.C.01": [ + "CRY-08", + "CRY-09", + "CRY-11" ], - "12.6.1.13": [ - "VPM-01" + "23.3.22.C.01": [ + "CRY-08", + "CRY-09", + "CRY-11" ], - "12.6.1.15": [ - "VPM-01" + "17.1.58.C.01": [ + "CRY-09" ], - "12.6.1.16": [ - "VPM-01" + "17.1.58.C.02": [ + "CRY-09" ], - "12.6.1.17": [ - "VPM-01" + "17.1.58.C.03": [ + "CRY-09" ], - "12.6.1.18.PB": [ - "VPM-01" + "7.2.24.C.01": [ + "CRY-09.3" ], - "12.6.1.14": [ - "VPM-02" + "4.4.10.C.01": [ + "DCH-01", + "DCH-04", + "IAO-01" ], - "12.6.1.10": [ - "VPM-05" - ] - }, - "apac-mys-pdpa-2010": { - "5": [ - "PRI-05" + "9.2.12.C.01": [ + "DCH-01" ], - "6": [ - "PRI-05" + "9.2.13.C.01": [ + "DCH-01" ], - "7": [ - "PRI-02", - "PRI-03" + "9.2.13.C.02": [ + "DCH-01" ], - "9": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", + "9.2.14.C.01": [ + "DCH-01" + ], + "9.2.15.C.01": [ "DCH-01", - "DCH-24", - "DCH-24.1", - "DCH-25", - "IRO-14", - "PRI-07", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "HRS-04.3", + "HRS-04.4" ], - "10": [ - "PRI-05" + "9.2.15.C.02": [ + "DCH-01", + "HRS-04.3", + "HRS-04.4" ], - "11": [ - "PRI-05.2" + "9.2.17.C.01": [ + "DCH-01" ], - "12": [ - "PRI-06" + "9.2.17.C.02": [ + "DCH-01" ], - "14": [ - "PRI-15" + "9.2.18.C.01": [ + "DCH-01" ], - "15": [ - "PRI-15" + "9.2.19.C.01": [ + "DCH-01" ], - "23": [ - "PRI-01" + "9.2.19.C.02": [ + "DCH-01" ], - "30": [ - "PRI-06" + "9.2.19.C.03": [ + "DCH-01" ], - "34": [ - "DCH-22.1", - "PRI-05.4", - "PRI-06.1" - ] - }, - "apac-nzl-hisf-mlhsp-2023": { - "HHSP12": [ - "GOV-01.1" + "9.2.19.C.04": [ + "DCH-01" ], - "HML12": [ - "GOV-01.1", - "GOV-01.2" + "9.2.20.C.01": [ + "DCH-01" ], - "HML21": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1" + "13.2.6.C.01": [ + "DCH-01" ], - "HHSP46": [ - "GOV-01.2", - "GOV-05" + "13.2.7.C.01": [ + "DCH-01" ], - "HHSP75": [ - "GOV-01.2", - "IRO-10" + "16.2.7.C.01": [ + "DCH-01.2" ], - "HML46": [ - "GOV-01.2", - "GOV-05" + "16.2.7.C.02": [ + "DCH-01.2" ], - "HML75": [ - "GOV-01.2", - "IRO-10" + "18.6.8.C.01": [ + "DCH-01.2", + "DCH-02" ], - "HML01": [ - "GOV-02" + "12.3.4.C.01": [ + "DCH-02", + "DCH-04" ], - "HHSP01": [ - "GOV-02" + "12.3.5.C.01": [ + "DCH-02", + "DCH-04" ], - "HHSP67": [ - "GOV-03", - "CPL-02", - "CPL-02.1" + "12.3.5.C.02": [ + "DCH-02", + "DCH-04" ], - "HML66": [ - "GOV-03", - "CPL-02", - "CPL-02.1" + "12.3.6.C.01": [ + "DCH-02", + "DCH-04" ], - "HHSP21": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "12.3.7.C.01": [ + "DCH-02", + "DCH-04" ], - "HHSP27": [ - "GOV-04", - "GOV-04.1" + "4.4.9.C.01": [ + "DCH-02.1", + "IAO-01" ], - "HML27": [ - "GOV-04", - "GOV-04.1" + "13.2.8.C.01": [ + "DCH-02.1" ], - "HHSP11": [ - "GOV-15", - "PRM-04", - "PRM-05" + "13.2.9.C.01": [ + "DCH-02.1" ], - "HHSP16": [ - "GOV-15", - "SEA-01" + "18.6.9.C.01": [ + "DCH-02.1" ], - "HHSP28": [ - "GOV-15", - "PRM-04", - "PRM-05" + "13.2.12.C.01": [ + "DCH-04" ], - "HML11": [ - "GOV-15", - "PRM-04" + "13.2.12.C.02": [ + "DCH-04" ], - "HML16": [ - "GOV-15", - "CFG-02", - "SEA-01" + "13.2.12.C.03": [ + "DCH-04" ], - "HML28": [ - "GOV-15", - "PRM-04" + "13.2.12.C.04": [ + "DCH-04" ], - "HHSP05": [ - "AST-01" + "13.2.13.C.01": [ + "DCH-04" ], - "HHSP54": [ - "AST-01", - "CFG-02", - "NET-01" + "13.2.14.C.01": [ + "DCH-04" ], - "HML05": [ - "AST-01" + "13.2.14.C.02": [ + "DCH-04" ], - "HML54": [ - "AST-01", - "CFG-02", - "NET-01" + "15.2.39.C.02": [ + "DCH-04.1" ], - "HHSP06": [ - "AST-09" + "15.2.39.C.03": [ + "DCH-04.1" ], - "HHSP45": [ - "AST-09" + "8.4.10.C.01": [ + "DCH-06" ], - "HML06": [ - "AST-09" + "8.4.11.C.01": [ + "DCH-06" ], - "HML45": [ - "AST-09" + "8.4.12.C.01": [ + "DCH-06" ], - "HHSP08": [ - "BCD-01" + "13.3.5.C.01": [ + "DCH-06" ], - "HHSP24": [ - "BCD-01", - "BCD-01.4" + "12.6.6.C.01": [ + "DCH-08" ], - "HHSP56": [ - "BCD-01", - "BCD-11", - "BCD-11.10" + "12.6.6.C.02": [ + "DCH-08" ], - "HHSP61": [ - "BCD-01", - "CAP-01" + "12.6.7.C.01": [ + "DCH-08" ], - "HML08": [ - "BCD-01" + "12.6.7.C.02": [ + "DCH-08" ], - "HML24": [ - "BCD-01", - "BCD-01.4" + "13.5.23.C.01": [ + "DCH-08" ], - "HML61": [ - "BCD-01", - "CAP-01" + "13.4.9.C.01": [ + "DCH-09" ], - "HHSP35": [ - "BCD-02.1", - "BCD-02.2" + "13.4.11.C.01": [ + "DCH-09" ], - "HML35": [ - "BCD-02.1", - "BCD-02.2" + "13.4.12.C.01": [ + "DCH-09" ], - "HHSP64": [ - "BCD-05" + "13.4.13.C.01": [ + "DCH-09" ], - "HML63": [ - "BCD-05" + "13.4.13.C.02": [ + "DCH-09" ], - "HHSP17": [ - "BCD-11", - "BCD-12" + "13.4.13.C.03": [ + "DCH-09" ], - "HHSP69": [ - "BCD-11", - "BCD-11.1", - "MON-01.4", - "MON-01.12" + "13.4.13.C.04": [ + "DCH-09" ], - "HML17": [ - "BCD-11", - "BCD-12" + "13.4.13.C.05": [ + "DCH-09" ], - "HML56": [ - "BCD-11", - "BCD-11.10" + "13.4.14.C.01": [ + "DCH-09" ], - "HML68": [ - "BCD-11", - "BCD-11.1", - "MON-01.4", - "MON-01.12" + "13.4.15.C.01": [ + "DCH-09" ], - "HHSP57": [ - "BCD-11.1" + "13.4.16.C.01": [ + "DCH-09" ], - "HML57": [ - "BCD-11.1" + "13.4.17.C.01": [ + "DCH-09" ], - "HHSP18": [ - "CHG-01", - "CHG-02" + "13.4.18.C.01": [ + "DCH-09" ], - "HML18": [ - "CHG-01", - "CHG-02" + "13.4.19.C.01": [ + "DCH-09" ], - "HHSP33": [ - "CHG-03" + "13.4.20.C.01": [ + "DCH-09" ], - "HML33": [ - "CHG-03" + "13.4.20.C.02": [ + "DCH-09" ], - "HHSP51": [ - "CLD-02" + "13.4.20.C.03": [ + "DCH-09" ], - "HML51": [ - "CLD-02" + "13.4.21.C.01": [ + "DCH-09" ], - "HHSP52": [ - "CLD-04" + "13.4.22.C.01": [ + "DCH-09" ], - "HML52": [ - "CLD-04" + "13.5.22.C.01": [ + "DCH-09.1" ], - "HHSP53": [ - "CLD-06" + "13.5.27.C.01": [ + "DCH-09.1" ], - "HML53": [ - "CLD-06" + "13.5.27.C.02": [ + "DCH-09.1" ], - "HHSP29": [ - "CPL-01" + "13.5.27.C.03": [ + "DCH-09.1" ], - "HML29": [ - "CPL-01" + "13.5.28.C.01": [ + "DCH-09.1" ], - "HHSP60": [ - "CFG-02" + "13.5.28.C.02": [ + "DCH-09.1" ], - "HHSP65": [ - "CFG-02", - "RSK-04.1", - "RSK-06.2" + "13.4.23.C.01": [ + "DCH-09.2" ], - "HML60": [ - "CFG-02" + "13.3.4.C.01": [ + "DCH-10", + "DCH-10.1" ], - "HML64": [ - "CFG-02", - "RSK-04.1", - "RSK-06.2" + "13.2.10.C.01": [ + "DCH-11" ], - "HHSP70": [ - "MON-01", - "MON-03", - "MON-03.2" + "13.2.11.C.01": [ + "DCH-11" ], - "HML70": [ - "MON-01", - "MON-03", - "MON-03.2" + "13.3.6.C.01": [ + "DCH-12" ], - "HHSP71": [ - "MON-07.1" + "13.3.6.C.02": [ + "DCH-12" ], - "HML71": [ - "MON-07.1" + "13.3.6.C.03": [ + "DCH-12" ], - "HHSP63": [ - "MON-11", - "NET-17" + "13.3.10.C.01": [ + "DCH-12", + "DCH-13.2" ], - "HML69": [ - "MON-11", - "NET-17" + "11.8.11.C.01": [ + "DCH-13.2" ], - "HHSP37": [ - "CRY-01" + "11.8.11.C-02": [ + "DCH-13.2" ], - "HML37": [ - "CRY-01" + "13.3.7.C.01": [ + "DCH-13.2" ], - "HHSP14": [ - "DCH-01", - "DCH-01.2", - "DCH-12" + "13.3.7.C.02": [ + "DCH-13.2" ], - "HHSP34": [ - "DCH-01", - "END-01" + "13.3.8.C.01": [ + "DCH-13.2" ], - "HHSP74": [ - "DCH-01", - "DCH-01.2", - "IRO-08" + "13.3.8.C.02": [ + "DCH-13.2" ], - "HML14": [ - "DCH-01", - "DCH-01.2", - "DCH-12" + "13.3.9.C.01": [ + "DCH-13.2" ], - "HML74": [ - "DCH-01", - "DCH-01.2", - "IRO-08" + "13.3.9.C.02": [ + "DCH-13.2" ], - "HML34": [ - "DCH-02" + "16.2.5.C.01": [ + "DCH-14.3", + "IAC-08" ], - "HHSP62": [ - "END-04" + "16.2.6.C.01": [ + "DCH-14.3" ], - "HML62": [ + "21.3.10.C.01": [ "END-04" ], - "HML02": [ - "HRS-01", - "HRS-03" - ], - "HHSP02": [ - "HRS-03" + "14.1.12.C.01": [ + "END-06" ], - "HHSP23": [ - "HRS-03" + "14.1.12.C.02": [ + "END-06" ], - "HML23": [ - "HRS-03" + "14.1.12.C.03": [ + "END-06" ], - "HHSP20": [ - "HRS-04" + "18.4.13.C.01": [ + "END-07" ], - "HML20": [ - "HRS-04" + "15.2.37.C.01": [ + "END-08" ], - "HHSP03": [ - "HRS-07", - "HRS-07.1" + "9.2.10.C.01": [ + "HRS-01", + "HRS-02", + "HRS-04.3" ], - "HHSP72": [ - "HRS-07", - "TPM-05" + "9.2.11.C.01": [ + "HRS-01", + "HRS-02", + "HRS-04.3", + "IAC-08" ], - "HHSP73": [ - "HRS-07", - "HRS-07.1", - "TPM-07", - "TPM-08" + "9.2.11.C.02": [ + "HRS-01", + "HRS-02", + "HRS-04.3", + "IAC-08" ], - "HML03": [ - "HRS-07", - "HRS-07.1" + "14.3.5.C.01": [ + "HRS-01", + "HRS-05.1" ], - "HML72": [ - "HRS-07", - "TPM-05" + "15.1.7.C.01": [ + "HRS-01", + "HRS-05.1", + "HRS-05.3", + "NET-13" ], - "HML73": [ - "HRS-07", - "HRS-07.1", - "TPM-07", - "TPM-08" + "3.3.4.C.01": [ + "HRS-03" ], - "HHSP39": [ - "IAC-01.2" + "3.3.4.C.02": [ + "HRS-03" ], - "HML39": [ - "IAC-01.2" + "3.3.4.C.03": [ + "HRS-03" ], - "HHSP49": [ - "IAC-05", - "NET-01" + "3.3.4.C.04": [ + "HRS-03" ], - "HML49": [ - "IAC-05", - "NET-01" + "3.3.4.C.05": [ + "HRS-03" ], - "HHSP04": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "PES-02" + "3.3.5.C.01": [ + "HRS-03" ], - "HML04": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "PES-02" + "3.3.5.C.02": [ + "HRS-03" ], - "HHSP40": [ - "IAC-08", - "IAC-20" + "3.3.6.C.01": [ + "HRS-03" ], - "HHSP42": [ - "IAC-08", - "TDA-20" + "3.3.6.C.02": [ + "HRS-03" ], - "HML40": [ - "IAC-08", - "IAC-20" + "3.3.6.C.03": [ + "HRS-03" ], - "HML42": [ - "IAC-08", - "TDA-20" + "3.3.6.C.04": [ + "HRS-03" ], - "HHSP38": [ - "IAC-15" + "3.3.6.C.05": [ + "HRS-03" ], - "HML38": [ - "IAC-15" + "3.3.6.C.06": [ + "HRS-03" ], - "HHSP41": [ - "IAC-16" + "3.3.7.C.01": [ + "HRS-03" ], - "HML41": [ - "IAC-16" + "3.3.8.C.01": [ + "HRS-03" ], - "HHSP10": [ - "IAC-20", - "PES-03.4" + "3.3.8.C.02": [ + "HRS-03" ], - "HML10": [ - "IAC-20", - "PES-03.4" + "3.3.8.C.03": [ + "HRS-03" ], - "HHSP07": [ - "IRO-02", - "IRO-04" + "3.3.8.C.04": [ + "HRS-03" ], - "HML07": [ - "IRO-02", - "IRO-04" + "3.3.8.C.05": [ + "HRS-03" ], - "HHSP68": [ - "IAO-01", - "IAO-02" + "3.3.9.C.01": [ + "HRS-03" ], - "HML67": [ - "IAO-01", - "IAO-02" + "3.3.10.C.01": [ + "HRS-03" ], - "HHSP15": [ - "MNT-01" + "3.3.10.C.02": [ + "HRS-03" ], - "HML15": [ - "MNT-01" + "3.3.10.C.03": [ + "HRS-03" ], - "HHSP43": [ - "NET-03.7", - "RSK-06.2", - "TDA-17" + "3.3.10.C.04": [ + "HRS-03" ], - "HHSP55": [ - "NET-03.7", - "NET-06" + "3.3.11.C.01": [ + "HRS-03" ], - "HML43": [ - "NET-03.7", - "RSK-06.2", - "TDA-17" + "3.3.12.C.01": [ + "HRS-03" ], - "HML55": [ - "NET-03.7", - "NET-06" + "3.3.13.C.01": [ + "HRS-03" ], - "HHSP47": [ - "PES-01" + "3.3.13.C.02": [ + "HRS-03" ], - "HML47": [ - "PES-01" + "3.3.14.C.01": [ + "HRS-03" ], - "HHSP13": [ - "PES-01.1" + "3.3.14.C.02": [ + "HRS-03" ], - "HML13": [ - "PES-01.1" + "3.3.14.C.03": [ + "HRS-03" ], - "HHSP48": [ - "PES-03", - "PES-04" + "3.3.15.C.01": [ + "HRS-03" ], - "HML48": [ - "PES-03", - "PES-04" + "17.9.35.C.01": [ + "HRS-03" ], - "HHSP66": [ - "PES-05" + "9.1.7.C.01": [ + "HRS-04.2" ], - "HML65": [ - "PES-05" + "9.2.16.C.01": [ + "HRS-04.3", + "HRS-04.4" ], - "HHSP31": [ - "PRM-04", - "PRM-05", - "TDA-02" + "16.1.39.C.01": [ + "HRS-04.4" ], - "HML31": [ - "PRM-04", - "PRM-05", - "TDA-02" + "16.1.39.C.02": [ + "HRS-04.4" ], - "HHSP30": [ - "RSK-01" + "3.5.4.C.01": [ + "HRS-05", + "HRS-05.1" ], - "HML30": [ - "RSK-01" + "3.5.4.C.02": [ + "HRS-05", + "HRS-05.1" ], - "HHSP32": [ - "RSK-04" + "3.5.4.C.03": [ + "HRS-05", + "HRS-05.1" ], - "HML32": [ - "RSK-04" + "5.5.7.C.01": [ + "HRS-05", + "HRS-05.1" ], - "HHSP26": [ - "RSK-06.2", - "VPM-01", - "VPM-06" + "9.3.7.C.01": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2" ], - "HML26": [ - "RSK-06.2", - "VPM-01", - "VPM-06" + "9.3.7.C.02": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2" ], - "HHSP22": [ - "SAT-01" + "9.3.7.C.03": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2" ], - "HML22": [ - "SAT-01" + "9.3.7.C.04": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2" ], - "HHSP50": [ - "TDA-01", - "TDA-01.1", - "TDA-06" + "9.3.8.C.01": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2" ], - "HML50": [ - "TDA-01", - "TDA-01.1", - "TDA-06" + "9.3.8.C.02": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2" ], - "HHSP58": [ - "TDA-08" + "9.3.8.C.03": [ + "HRS-05", + "HRS-05.1", + "HRS-05.2" ], - "HML58": [ - "TDA-08" + "21.1.6.C.02": [ + "HRS-05" ], - "HHSP25": [ - "TPM-01", - "TPM-04.1", - "TPM-08" + "21.2.3.C.01": [ + "HRS-05" ], - "HML25": [ - "TPM-01", - "TPM-04.1", - "TPM-08" + "9.1.8.C.01": [ + "HRS-05.1", + "HRS-06.1" ], - "HHSP09": [ - "TPM-05" + "16.4.38.C.02": [ + "HRS-05.1", + "IAC-18" ], - "HHSP36": [ - "TPM-05" + "9.3.4.C.01": [ + "HRS-05.3" ], - "HML09": [ - "TPM-05" + "9.3.5.C.01": [ + "HRS-05.3" ], - "HML36": [ - "TPM-05" + "9.3.5.C.02": [ + "HRS-05.3" ], - "HHSP19": [ - "VPM-01", - "VPM-02", - "VPM-05" + "9.3.9.C.01": [ + "HRS-05.3" ], - "HML19": [ - "VPM-01", - "VPM-02", - "VPM-05" + "9.3.10.C.01": [ + "HRS-05.3" ], - "HHSP59": [ - "VPM-02", - "VPM-06" + "11.1.16.C.03": [ + "HRS-05.3" ], - "HML59": [ - "VPM-02", - "VPM-06" + "11.1.16.C.04": [ + "HRS-05.3" ], - "HHSP44": [ - "VPM-04.1" + "11.1.17.C.02": [ + "HRS-05.3" ], - "HML44": [ - "VPM-04.1" - ] - }, - "apac-nzl-hisf-microsmall-2023": { - "HMS02": [ - "GOV-02" + "11.1.18.C.01": [ + "HRS-05.3" ], - "HMS12": [ - "AST-01", - "AST-01.4" + "11.1.18.C.02": [ + "HRS-05.3" ], - "HMS14": [ - "AST-01", - "AST-02.7" + "11.1.19.C.02": [ + "HRS-05.3" ], - "HMS03": [ - "AST-02", - "DCH-06.2" + "11.2.14.C.01": [ + "HRS-05.3" ], - "HMS21": [ - "BCD-01" + "11.8.4.C.02": [ + "HRS-05.3" ], - "HMS11": [ - "BCD-11", - "BCD-11.1", - "BCD-11.4" + "11.4.10.C.01": [ + "HRS-05.5" ], - "HMS09": [ - "CFG-02", - "DCH-12", - "END-02" + "11.4.10.C.02": [ + "HRS-05.5" ], - "HMS18": [ - "MON-01", - "MON-10" + "11.4.11.C.01": [ + "HRS-05.5" ], - "HMS19": [ - "MON-01.2", - "MON-16" + "11.4.12.C.01": [ + "HRS-05.5" ], - "HMS10": [ - "END-04" + "11.4.12.C.02": [ + "HRS-05.5" ], - "HMS01": [ - "HRS-03" + "11.5.14.C.01": [ + "HRS-05.5" ], - "HMS07": [ - "IAC-08", - "IAC-20" + "11.5.14.C.02": [ + "HRS-05.5" ], - "HMS20": [ - "IRO-04" + "11.5.15.C.01": [ + "HRS-05.5" ], - "HMS17": [ - "NET-02.1", - "NET-12" + "11.5.15.C.02": [ + "HRS-05.5" ], - "HMS16": [ - "NET-03.7" + "11.5.16.C.01": [ + "HRS-05.5" ], - "HMS15": [ - "NET-06.3" + "11.5.16.C.02": [ + "HRS-05.5" ], - "HMS13": [ - "NET-14", - "NET-14.5" + "11.5.16.C.03": [ + "HRS-05.5" ], - "HMS05": [ - "RSK-07" + "21.1.11.C.01": [ + "HRS-05.5", + "MDM-01" ], - "HMS06": [ - "TPM-05" + "22.1.10.C.02": [ + "HRS-05.5" ], - "HMS04": [ - "TPM-08" + "22.1.13.C.01": [ + "HRS-05.5" ], - "HMS08": [ - "VPM-04.1" - ] - }, - "apac-nzl-hisf-suppliers-2023": { - "HSUP10": [ - "GOV-01.1", - "GOV-01.2" + "22.1.13.C.02": [ + "HRS-05.5" ], - "HSUP19": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1" + "22.1.13.C.03": [ + "HRS-05.5" ], - "HSUP38": [ - "GOV-01.2", - "GOV-05" + "22.1.13.C.04": [ + "HRS-05.5" ], - "HSUP65": [ - "GOV-01.2", - "IRO-10" + "22.1.13.C.05": [ + "HRS-05.5" ], - "HSUP01": [ - "GOV-02", - "HRS-05.1", - "OPS-01.1" + "22.2.5.C.01": [ + "HRS-05.5" ], - "HSUP58": [ - "GOV-03", - "CPL-02", - "CPL-02.1" + "22.2.6.C.01": [ + "HRS-05.5" ], - "HSUP23": [ - "GOV-04", - "GOV-04.1" + "22.2.7.C.01": [ + "HRS-05.5" ], - "HSUP14": [ - "GOV-15", - "CFG-02", - "SEA-01" + "22.2.7.C.02": [ + "HRS-05.5" ], - "HSUP24": [ - "GOV-15", - "PRM-04" + "22.3.5.C.01": [ + "HRS-05.5" ], - "HSUP05": [ - "AST-01" + "22.3.6.C.01": [ + "HRS-05.5" ], - "HSUP46": [ - "AST-01", - "CFG-02", - "NET-01" + "22.4.9.C.01": [ + "HRS-05.5" ], - "HSUP27": [ - "AST-01.2", - "PRM-05", - "PRM-06" + "16.1.31.C.01": [ + "IAC-01" ], - "HSUP06": [ - "AST-09" + "16.4.39.C.01": [ + "IAC-01" ], - "HSUP08": [ - "BCD-01" + "20.2.16.C.02": [ + "IAC-01" ], - "HSUP22": [ - "BCD-01", - "BCD-01.4" + "16.1.26.C.01": [ + "IAC-01.2" ], - "HSUP53": [ - "BCD-01", - "CAP-01" + "16.1.32.C.01": [ + "IAC-02" ], - "HSUP31": [ - "BCD-02.1", - "BCD-02.2" + "16.1.33.C.01": [ + "IAC-02.1", + "IAC-15.5" ], - "HSUP56": [ - "BCD-05" + "16.1.34.C.01": [ + "IAC-02.1", + "IAC-15.5" ], - "HSUP15": [ - "BCD-11", - "BCD-12" + "16.1.29.C.02": [ + "IAC-06" ], - "HSUP48": [ - "BCD-11", - "BCD-11.10" + "16.4.37.C.02": [ + "IAC-06" ], - "HSUP60": [ - "BCD-11", - "BCD-11.1", - "MON-01.4", - "MON-01.12" + "16.7.42.C.04": [ + "IAC-06" ], - "HSUP49": [ - "BCD-11.1" + "16.7.42.C.05": [ + "IAC-06" ], - "HSUP16": [ - "CHG-01", - "CHG-02" + "16.7.42.C.06": [ + "IAC-06" ], - "HSUP29": [ - "CHG-03" + "16.7.42.C.07": [ + "IAC-06" ], - "HSUP43": [ - "CLD-02" + "16.7.43.C.01": [ + "IAC-06" ], - "HSUP44": [ - "CLD-04" + "16.7.44.C.01": [ + "IAC-06" ], - "HSUP45": [ - "CLD-06" + "23.3.19.C.01": [ + "IAC-06" ], - "HSUP25": [ - "CPL-01" + "23.3.19.C.02": [ + "IAC-06" ], - "HSUP52": [ - "CFG-02" + "16.7.42.C.02": [ + "IAC-06.1" ], - "HSUP61": [ - "MON-01", - "MON-03", - "MON-03.2" + "16.7.42.C.03": [ + "IAC-06.1", + "IAC-06.2" ], - "HSUP62": [ - "MON-07.1" + "23.3.20.C.01": [ + "IAC-07" ], - "HSUP55": [ - "MON-11", - "NET-17" + "16.2.4.C.01": [ + "IAC-08", + "IAC-21" ], - "HSUP32": [ - "CRY-01" + "14.3.13.C.01": [ + "IAC-10", + "IAC-10.11" ], - "HSUP12": [ - "DCH-01", - "DCH-01.2", - "DCH-12" + "14.3.13.C.02": [ + "IAC-10", + "IAC-10.11" ], - "HSUP30": [ - "DCH-01", - "DCH-02", - "END-01" + "14.3.13.C.03": [ + "IAC-10", + "IAC-10.11" ], - "HSUP66": [ - "DCH-01", - "DCH-01.2", - "IRO-08" + "16.1.36.C.02": [ + "IAC-10" ], - "HSUP54": [ - "END-04" + "16.1.36.C.03": [ + "IAC-10" ], - "HSUP02": [ - "HRS-01", - "HRS-03" + "16.1.40.C.01": [ + "IAC-10" ], - "HSUP21": [ - "HRS-03" + "16.1.41.C.01": [ + "IAC-10", + "IAC-10.4" ], - "HSUP18": [ - "HRS-04" + "16.1.41.C.02": [ + "IAC-10", + "IAC-10.4" ], - "HSUP03": [ - "HRS-07", - "HRS-07.1" + "16.1.42.C.01": [ + "IAC-10", + "IAC-10.1" ], - "HSUP63": [ - "HRS-07", - "TPM-05" + "16.1.29.C.01": [ + "IAC-10.1" ], - "HSUP64": [ - "HRS-07", - "HRS-07.1", - "TPM-07", - "TPM-08" + "16.1.31.C.02": [ + "IAC-10.1" ], - "HSUP34": [ - "IAC-01.2" + "16.1.31.C.07": [ + "IAC-10.1" ], - "HSUP41": [ - "IAC-05", - "NET-01" + "16.1.35.C.01": [ + "IAC-10.1" ], - "HSUP04": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "IAC-08", - "PES-02", - "PES-02.1" + "16.1.35.C.02": [ + "IAC-10.1" ], - "HSUP35": [ - "IAC-07", - "IAC-15" + "16.1.43.C.01": [ + "IAC-10.1" ], - "HSUP37": [ - "IAC-08", - "TDA-20" + "16.1.34.C.02": [ + "IAC-10.5" ], - "HSUP33": [ - "IAC-15" + "16.1.36.C.01": [ + "IAC-10.5", + "IAC-10.6" ], - "HSUP36": [ - "IAC-16" + "16.1.37.C.01": [ + "IAC-10.5" ], - "HSUP09": [ - "IAC-20", - "PES-03.4" + "16.1.38.C.01": [ + "IAC-10.5" ], - "HSUP07": [ - "IRO-02", - "IRO-04" + "16.1.37.C.02": [ + "IAC-10.11" ], - "HSUP59": [ - "IAO-01", - "IAO-02" + "17.10.12.C.01": [ + "IAC-12.1" ], - "HSUP13": [ - "MNT-01" + "17.10.12.C.02": [ + "IAC-12.1" ], - "HSUP47": [ - "NET-03.7", - "NET-06" + "17.10.12.C.03": [ + "IAC-12.1" ], - "HSUP11": [ - "PES-01", - "PES-01.1" + "17.10.12.C.04": [ + "IAC-12.1" ], - "HSUP39": [ - "PES-01" + "16.1.27.C.01": [ + "IAC-15.5", + "IAC-19" ], - "HSUP40": [ - "PES-03", - "PES-04" + "16.1.27.C.02": [ + "IAC-15.5", + "IAC-19" ], - "HSUP57": [ - "PES-05" + "16.1.28.C.01": [ + "IAC-15.5" ], - "HSUP26": [ - "RSK-01" + "16.3.5.C.01": [ + "IAC-16" ], - "HSUP28": [ - "RSK-04" + "16.3.6.C.01": [ + "IAC-16" ], - "HSUP20": [ - "SAT-01" + "16.3.6.C.02": [ + "IAC-16" ], - "HSUP42": [ - "TDA-01", - "TDA-01.1", - "TDA-06" + "16.3.7.C.01": [ + "IAC-16" ], - "HSUP50": [ - "TDA-08" + "16.4.36.C.01": [ + "IAC-16" ], - "HSUP67": [ - "TPM-01", - "TPM-04.1", - "TPM-08" + "16.4.36.C.02": [ + "IAC-16" ], - "HSUP68": [ - "TPM-05" + "16.4.36.C.03": [ + "IAC-16" ], - "HSUP17": [ - "VPM-01", - "VPM-02", - "VPM-05" + "16.4.37.C.01": [ + "IAC-16", + "IAC-18" ], - "HSUP51": [ - "VPM-02", - "VPM-06" - ] - }, - "apac-nzl-ism-3-9": { - "5.1.14.C.01": [ - "GOV-01", - "GOV-02", - "GOV-03", - "HRS-03.2" + "16.4.37.C.03": [ + "IAC-16" ], - "3.2.9.C.01": [ - "GOV-01.1", - "GOV-04" + "16.4.38.C.01": [ + "IAC-16" ], - "5.1.7.C.01": [ - "GOV-02" + "16.4.40.C.01": [ + "IAC-16.1" ], - "5.1.16.C.01": [ - "GOV-02" + "23.3.18.C.01": [ + "IAC-16.2" ], - "5.1.16.C.02": [ - "GOV-02" + "16.1.27.C.03": [ + "IAC-19" ], - "5.1.17.C.01": [ - "GOV-02" + "16.1.44.C.01": [ + "IAC-25" ], - "5.1.18.C.01": [ - "GOV-02" + "16.1.31.C.06": [ + "IAC-29" ], - "5.1.19.C.01": [ - "GOV-02" + "7.1.7.C.01": [ + "IRO-01" ], - "5.1.20.C.01": [ - "GOV-02" + "7.1.7.C.02": [ + "IRO-01" ], - "5.1.20.C.02": [ - "GOV-02" + "7.1.7.C.03": [ + "IRO-01" ], - "5.2.3.C.01": [ - "GOV-02" + "7.2.18.C.01": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-07", + "IRO-10", + "IRO-10.2" ], - "5.2.3.C.02": [ - "GOV-02" + "5.7.4.C.01": [ + "IRO-02", + "PES-01" ], - "5.1.21.C.01": [ - "GOV-03" + "7.2.18.C.02": [ + "IRO-02", + "IRO-10" ], - "5.1.21.C.02": [ - "GOV-03" + "7.2.19.C.01": [ + "IRO-02" ], - "3.1.8.C.01": [ - "GOV-04" + "7.3.9.C.01": [ + "IRO-02", + "IRO-04" ], - "3.1.8.C.02": [ - "GOV-04" + "7.3.10.C.01": [ + "IRO-02", + "IRO-02.5", + "IRO-04", + "IRO-11.2" ], - "3.1.8.C.03": [ - "GOV-04" + "20.1.25.C.02": [ + "IRO-02" ], - "3.1.9.C.01": [ - "GOV-04" + "5.1.12.C.01": [ + "IRO-04" ], - "3.2.8.C.01": [ - "GOV-04" + "5.1.12.C.02": [ + "IRO-04" ], - "3.2.8.C.02": [ - "GOV-04" + "5.6.3.C.01": [ + "IRO-04" ], - "3.2.8.C.03": [ - "GOV-04" + "5.6.3.C.02": [ + "IRO-04" ], - "3.2.8.C.04": [ - "GOV-04" + "7.3.5.C.01": [ + "IRO-04" ], - "3.2.8.C.05": [ - "GOV-04" + "16.4.39.C.02": [ + "IRO-04" ], - "3.2.10.C.01": [ - "GOV-04" + "16.4.42.C.01": [ + "IRO-04" ], - "3.2.10.C.02": [ - "GOV-04" + "7.3.11.C.01": [ + "IRO-08", + "IRO-11.2" ], - "3.2.10.C.03": [ - "GOV-04" + "7.3.6.C.01": [ + "IRO-09" ], - "3.2.10.C.04": [ - "GOV-04", - "GOV-15", - "GOV-15.1" + "7.3.6.C.02": [ + "IRO-09" ], - "3.2.11.C.01": [ - "GOV-04" + "7.2.20.C.01": [ + "IRO-10", + "IRO-10.2" ], - "3.2.11.C.02": [ - "GOV-04" + "7.2.20.C.02": [ + "IRO-10" ], - "3.2.11.C.03": [ - "GOV-04" + "7.2.20.C.03": [ + "IRO-10" ], - "3.2.12.C.01": [ - "GOV-04" + "7.2.21.C.01": [ + "IRO-10", + "IRO-10.2" ], - "3.2.12.C.02": [ - "GOV-04" + "7.2.23.C.01": [ + "IRO-10", + "IRO-10.2", + "TPM-05.1" ], - "3.2.12.C.03": [ - "GOV-04" + "7.3.8.C.03": [ + "IRO-10.2", + "IRO-12" ], - "3.2.13.C.01": [ - "GOV-04" + "7.2.22.C.01": [ + "IRO-10.4", + "TPM-05.1" ], - "3.2.13.C.02": [ - "GOV-04" + "7.3.12.C.01": [ + "IRO-11", + "IRO-11.2" ], - "3.2.14.C.01": [ - "GOV-04" + "7.3.7.C.01": [ + "IRO-12" ], - "3.2.15.C.01": [ - "GOV-04", - "PRM-01", - "PRM-02" + "7.3.7.C.02": [ + "IRO-12" ], - "3.2.16.C.01": [ - "GOV-04", - "IRO-09" + "7.3.7.C.03": [ + "IRO-12" ], - "3.2.17.C.01": [ - "GOV-04" + "7.3.7.C.04": [ + "IRO-12" ], - "3.2.18.C.01": [ - "GOV-04" + "7.3.7.C.05": [ + "IRO-12" ], - "3.2.19.C.01": [ - "GOV-04", - "PRM-08" + "7.3.7.C.06": [ + "IRO-12" ], - "3.4.11.C.01": [ - "GOV-15", - "GOV-15.2" + "7.3.8.C.01": [ + "IRO-12", + "IRO-12.4" ], - "23.2.16.C.03": [ - "GOV-15.4", - "IAO-07" + "7.3.8.C.02": [ + "IRO-12", + "IRO-12.4" ], - "23.2.16.C.04": [ - "GOV-15.4", + "2.2.5.C.01": [ + "IAO-01", "IAO-07" ], - "23.2.18.C.01": [ - "GOV-15.5", - "CPL-02", - "CPL-03", - "CPL-03.2" + "4.4.4.C.01": [ + "IAO-01" ], - "8.4.9.C.01": [ - "AST-01", - "AST-02" + "4.4.5.C.01": [ + "IAO-01" ], - "8.4.8.C.01": [ - "AST-02" + "4.4.5.C.02": [ + "IAO-01" ], - "18.1.9.C.02": [ - "AST-04", - "NET-01" + "4.4.5.C.03": [ + "IAO-01" ], - "18.1.11.C.01": [ - "AST-04" + "4.4.5.C.04": [ + "IAO-01" ], - "18.1.12.C.01": [ - "AST-04" + "4.4.6.C.01": [ + "IAO-01" ], - "18.1.12.C.02": [ - "AST-04" + "4.4.7.C.01": [ + "IAO-01" ], - "8.5.3.C.01": [ - "AST-08" + "4.4.7.C.02": [ + "IAO-01" ], - "8.5.3.C.02": [ - "AST-08" + "4.4.8.C.01": [ + "IAO-01" ], - "8.5.3.C.03": [ - "AST-08" + "4.4.8.C.02": [ + "IAO-01" ], - "8.5.3.C.04": [ - "AST-08" + "4.4.8.C.03": [ + "IAO-01" ], - "8.5.4.C.01": [ - "AST-08" + "4.4.8.C.04": [ + "IAO-01" ], - "8.5.4.C.02": [ - "AST-08" + "4.4.11.C.01": [ + "IAO-01" ], - "8.5.4.C.03": [ - "AST-08" + "4.4.12.C.01": [ + "IAO-01" ], - "8.5.5.C.01": [ - "AST-08" + "4.4.12.C.02": [ + "IAO-01" ], - "11.2.13.C.01": [ - "AST-09", - "AST-23" + "4.4.12.C.03": [ + "IAO-01" ], - "11.2.13.C.02": [ - "AST-09", - "AST-23" + "4.4.12.C.04": [ + "IAO-01" ], - "11.7.35.C.01": [ - "AST-09", - "DCH-08" + "4.4.12.C.05": [ + "IAO-01" ], - "12.6.4.C.01": [ - "AST-09" + "5.8.61.C.01": [ + "IAO-01.1" ], - "12.6.4.C.02": [ - "AST-09" + "5.8.61.C.02": [ + "IAO-01.1" ], - "12.6.5.C.01": [ - "AST-09" + "5.8.61.C.03": [ + "IAO-01.1" ], - "12.6.5.C.02": [ - "AST-09" + "20.1.21.C.02": [ + "IAO-01.1" ], - "12.6.5.C.03": [ - "AST-09" + "23.5.10.C.01": [ + "IAO-01.1", + "IAO-02" ], - "12.6.5.C.04": [ - "AST-09" + "4.2.10.C.01": [ + "IAO-02" ], - "12.6.5.C.05": [ - "AST-09", - "DCH-09" + "4.3.20.C.01": [ + "IAO-02", + "IAO-02.2", + "IAO-02.3" ], - "12.6.8.C.01": [ - "AST-09" + "4.3.20.C.02": [ + "IAO-02", + "IAO-02.2", + "IAO-02.3" ], - "12.6.9.C.01": [ - "AST-09" + "4.3.20.C.03": [ + "IAO-02", + "IAO-02.2", + "IAO-02.3" ], - "12.6.10.C.01": [ - "AST-09" + "11.1.19.C.01": [ + "IAO-02" ], - "13.4.19.C.02": [ - "AST-09", - "DCH-09" + "16.1.30.C.01": [ + "IAO-02", + "RSK-08" ], - "13.4.10.C.01": [ - "AST-09" + "16.7.41.C.01": [ + "IAO-02" ], - "13.5.24.C.01": [ - "AST-09", - "DCH-08" + "20.1.21.C.01": [ + "IAO-02" ], - "13.5.24.C.02": [ - "AST-09", - "DCH-08" + "20.1.21.C.07": [ + "IAO-02" ], - "13.5.24.C.03": [ - "AST-09", - "DCH-08" + "20.1.23.C.01": [ + "IAO-02" ], - "13.5.24.C.04": [ - "AST-09", - "DCH-08" + "20.2.13.C.01": [ + "IAO-02.2" ], - "13.5.25.C.01": [ - "AST-09", - "DCH-08" + "20.2.13.C.02": [ + "IAO-02.2" ], - "13.5.26.C.01": [ - "AST-09", - "DCH-08" + "5.8.62.C.01": [ + "IAO-02.3" ], - "13.5.26.C.02": [ - "AST-09", - "DCH-08" + "4.2.11.C.01": [ + "IAO-02.4", + "IAO-07" ], - "13.5.26.C.03": [ - "AST-09", - "DCH-08" + "4.2.12.C.01": [ + "IAO-02.4", + "IAO-05" ], - "13.5.29.C.01": [ - "AST-09", - "DCH-08" + "4.3.21.C.01": [ + "IAO-02.4" ], - "13.5.29.C.02": [ - "AST-09", - "DCH-08" + "4.5.17.C.01": [ + "IAO-02.4" ], - "13.5.30.C.01": [ - "AST-09", - "DCH-08" + "3.4.12.C.01": [ + "IAO-03", + "OPS-01.1" ], - "13.6.6.C.01": [ - "AST-09" + "3.4.12.C.02": [ + "IAO-03", + "OPS-01.1" ], - "13.6.6.C.02": [ - "AST-09" + "4.3.17.C.01": [ + "IAO-03" ], - "13.6.7.C.01": [ - "AST-09" + "4.3.18.C.01": [ + "IAO-03" ], - "13.6.8.C.01": [ - "AST-09" + "4.3.18.C.02": [ + "IAO-03" ], - "13.6.9.C.01": [ - "AST-09" + "4.3.18.C.03": [ + "IAO-03" ], - "13.6.10.C.01": [ - "AST-09" + "4.3.18.C.04": [ + "IAO-03" ], - "13.6.10.C.02": [ - "AST-09" + "4.3.18.C.05": [ + "IAO-03" ], - "13.6.10.C.03": [ - "AST-09" + "5.1.8.C.01": [ + "IAO-03" ], - "13.6.11.C.01": [ - "AST-09" + "5.1.9.C.01": [ + "IAO-03", + "RSK-01" ], - "13.6.12.C.01": [ - "AST-09" + "5.1.10.C.01": [ + "IAO-03" + ], + "5.4.5.C.01": [ + "IAO-03" ], - "16.2.3.C.01": [ - "AST-13" + "5.4.5.C.02": [ + "IAO-03" ], - "16.2.3.C.02": [ - "AST-13" + "5.4.5.C.03": [ + "IAO-03" ], - "11.1.8.C.01": [ - "AST-14.1" + "2.2.5.C.02": [ + "IAO-03.2" ], - "11.1.10.C.01": [ - "AST-14.1" + "6.2.5.C.01": [ + "IAO-04", + "VPM-06" ], - "11.1.10.C.02": [ - "AST-14.1" + "6.2.6.C.01": [ + "IAO-04", + "VPM-02", + "VPM-04" ], - "11.1.10.C.03": [ - "AST-14.1" + "4.5.18.C.01": [ + "IAO-07" ], - "11.1.11.C.01": [ - "AST-14.1" + "4.5.18.C.02": [ + "IAO-07" ], - "11.1.11.C.02": [ - "AST-14.1" + "4.5.18.C.03": [ + "IAO-07" ], - "11.1.12.C.01": [ - "AST-14.1" + "20.1.21.C.04": [ + "IAO-07" ], - "11.1.13.C.01": [ - "AST-14.1" + "12.5.3.C.01": [ + "MNT-01", + "MNT-02" ], - "21.1.16.C.01": [ - "AST-14.1", - "MDM-01", - "NET-15.2" + "12.5.3.C.02": [ + "MNT-01", + "MNT-02" ], - "21.1.16.C.02": [ - "AST-14.1", - "MDM-01", - "NET-15.2" + "12.5.6.C.01": [ + "MNT-01", + "MNT-02" ], - "11.1.9.C.01": [ - "AST-14.2" + "12.5.6.C.02": [ + "MNT-01", + "MNT-02" ], - "11.1.9.C.02": [ - "AST-14.2" + "11.8.10.C.01": [ + "MNT-02" ], - "11.1.9.C.03": [ - "AST-14.2" + "11.8.10.C.04": [ + "MNT-02" ], - "8.1.12.C.01": [ - "AST-16", - "HRS-05", - "HRS-05.1", - "HRS-05.5", - "PES-04.2" + "11.8.10.C.02": [ + "MNT-04.3" + ], + "12.5.4.C.01": [ + "MNT-06.1" + ], + "12.5.4.C.02": [ + "MNT-06.1" ], - "21.1.12.C.01": [ - "AST-16", - "MDM-01", - "MDM-06" + "12.5.4.C.03": [ + "MNT-06.1" ], - "21.4.7.C.01": [ - "AST-16" + "12.5.4.C.04": [ + "MNT-06.1" ], - "21.4.7.C.02": [ - "AST-16" + "12.5.5.C.01": [ + "MNT-08", + "MNT-09" ], - "21.4.8.C.01": [ - "AST-16" + "21.1.10.C.01": [ + "MDM-01" ], - "21.4.8.C.02": [ - "AST-16" + "21.1.10.C.02": [ + "MDM-01" ], - "21.4.9.C.01": [ - "AST-16" + "22.1.10.C.03": [ + "MDM-01" ], - "21.4.10.C.01": [ - "AST-16" + "22.1.12.C.01": [ + "MDM-01" ], - "21.4.10.C.02": [ - "AST-16" + "22.1.15.C.01": [ + "MDM-01" ], - "21.4.10.C.03": [ - "AST-16" + "22.1.18.C.02": [ + "MDM-01" ], - "21.4.10.C.04": [ - "AST-16" + "21.1.13.C.01": [ + "MDM-03" ], - "21.4.10.C.05": [ - "AST-16" + "22.1.14.C.01": [ + "MDM-03" ], - "21.4.10.C.06": [ - "AST-16" + "22.1.14.C.02": [ + "MDM-03" ], - "21.4.10.C.07": [ - "AST-16" + "10.8.34.C.01": [ + "NET-01" ], - "21.4.10.C.08": [ - "AST-16" + "10.8.34.C.02": [ + "NET-01" ], - "21.4.10.C.09": [ - "AST-16" + "10.8.35.C.01": [ + "NET-01" ], - "21.4.10.C.10": [ - "AST-16" + "10.8.36.C.01": [ + "NET-01" ], - "21.4.10.C.11": [ - "AST-16" + "10.8.37.C.01": [ + "NET-01" ], - "21.4.10.C.12": [ - "AST-16" + "10.8.38.C.01": [ + "NET-01" ], - "21.4.10.C.13": [ - "AST-16" + "18.1.9.C.01": [ + "NET-01" ], - "21.4.10.C.14": [ - "AST-16" + "18.1.9.C.03": [ + "NET-01" ], - "21.4.10.C.15": [ - "AST-16" + "18.1.9.C.04": [ + "NET-01" ], - "21.4.10.C.16": [ - "AST-16" + "18.1.9.C.05": [ + "NET-01" ], - "21.4.11.C.01": [ - "AST-16" + "18.5.7.C.01": [ + "NET-01" ], - "21.4.11.C.02": [ - "AST-16" + "18.5.7.C.02": [ + "NET-01" ], - "21.4.11.C.03": [ - "AST-16" + "18.5.8.C.01": [ + "NET-01" ], - "21.4.11.C.04": [ - "AST-16" + "18.5.8.C.02": [ + "NET-01" ], - "21.4.11.C.05": [ - "AST-16" + "18.5.8.C.03": [ + "NET-01" ], - "21.4.11.C.06": [ - "AST-16" + "18.5.8.C.04": [ + "NET-01" ], - "21.4.11.C.07": [ - "AST-16" + "18.5.9.C.01": [ + "NET-01" ], - "21.4.11.C.08": [ - "AST-16" + "18.5.9.C.02": [ + "NET-01" ], - "21.4.11.C.09": [ - "AST-16" + "18.5.9.C.03": [ + "NET-01" ], - "21.4.11.C.10": [ - "AST-16" + "18.5.10.C.01": [ + "NET-01" ], - "21.4.11.C.11": [ - "AST-16" + "18.5.10.C.02": [ + "NET-01" ], - "21.4.11.C.12": [ - "AST-16" + "18.5.11.C.01": [ + "NET-01" ], - "21.4.11.C.13": [ - "AST-16" + "2.3.26.C.01": [ + "NET-01.1" ], - "21.4.11.C.14": [ - "AST-16" + "2.3.26.C.02": [ + "NET-01.1" ], - "21.4.11.C.15": [ - "AST-16" + "16.1.25.C.01": [ + "NET-01.1" ], - "21.4.11.C.16": [ - "AST-16" + "16.5.12.C.02": [ + "NET-01.1" ], - "21.4.11.C.17": [ - "AST-16" + "18.3.18.C.01": [ + "NET-02.1" ], - "21.4.11.C.18": [ - "AST-16" + "18.3.19.C.01": [ + "NET-02.1" ], - "21.4.11.C.19": [ - "AST-16" + "18.2.6.C.01": [ + "NET-02.2", + "NET-15" ], - "21.4.11.C.20": [ - "AST-16" + "19.2.15.C.01": [ + "NET-02.3" ], - "21.4.13.C.01": [ - "AST-16" + "19.2.16.C.01": [ + "NET-02.3" ], - "21.4.13.C.02": [ - "AST-16" + "19.2.16.C.02": [ + "NET-02.3" ], - "21.4.13.C.03": [ - "AST-16" + "19.2.17.C.01": [ + "NET-02.3" ], - "21.4.13.C.04": [ - "AST-16" + "19.2.17.C.02": [ + "NET-02.3" ], - "21.4.13.C.05": [ - "AST-16" + "19.2.18.C.01": [ + "NET-02.3" ], - "21.4.13.C.06": [ - "AST-16" + "19.2.19.C.01": [ + "NET-02.3" ], - "21.4.13.C.07": [ - "AST-16" + "19.2.19.C.02": [ + "NET-02.3" ], - "21.4.13.C.08": [ - "AST-16" + "19.2.20.C.01": [ + "NET-02.3" ], - "21.4.13.C.09": [ - "AST-16" + "20.2.14.C.04": [ + "NET-02.3", + "SEA-13.1" ], - "21.4.13.C.10": [ - "AST-16" + "20.3.9.C.02": [ + "NET-02.3", + "NET-06.2" ], - "21.4.13.C.11": [ - "AST-16" + "20.3.9.C.04": [ + "NET-02.3", + "NET-06.2" ], - "21.4.14.C.01": [ - "AST-16" + "21.1.8.C.01": [ + "NET-02.3" ], - "21.4.14.C.02": [ - "AST-16" + "19.1.10.C.01": [ + "NET-03" ], - "21.4.14.C.03": [ - "AST-16" + "19.1.11.C.01": [ + "NET-03" ], - "21.4.14.C.04": [ - "AST-16" + "19.1.11.C.02": [ + "NET-03" ], - "11.3.5.C.01": [ - "AST-19" + "19.1.12.C.01": [ + "NET-03" ], - "11.3.6.C.01": [ - "AST-19" + "19.1.13.C.01": [ + "NET-03" ], - "11.3.6.C.02": [ - "AST-19" + "19.1.14.C.01": [ + "NET-03", + "NET-08.1" ], - "11.3.7.C.01": [ - "AST-19" + "19.1.14.C.02": [ + "NET-03", + "NET-08.1" ], - "11.3.8.C.01": [ - "AST-19" + "19.1.15.C.01": [ + "NET-03" ], - "11.3.9.C.01": [ - "AST-19" + "19.1.16.C.01": [ + "NET-03" ], - "11.3.9.C.02": [ - "AST-19" + "19.1.16.C.02": [ + "NET-03" ], - "11.3.10.C.01": [ - "AST-19" + "19.1.17.C.01": [ + "NET-03" ], - "11.3.11.C.01": [ - "AST-19" + "19.1.17.C.02": [ + "NET-03" ], - "11.3.12.C.01": [ - "AST-19" + "19.1.18.C.01": [ + "NET-03" ], - "11.3.12.C.02": [ - "AST-19" + "19.1.18.C.02": [ + "NET-03" ], - "11.3.12.C.03": [ - "AST-19" + "19.1.19.C.01": [ + "NET-03" ], - "11.3.13.C.01": [ - "AST-19", - "BCD-12.3" + "19.1.19.C.02": [ + "NET-03" ], - "11.3.13.C.02": [ - "AST-19", - "BCD-12.3" + "19.1.19.C.03": [ + "NET-03" ], - "11.3.13.C.03": [ - "AST-19", - "BCD-12.3" + "19.1.19.C.04": [ + "NET-03" ], - "18.3.14.C.01": [ - "AST-20", - "AST-21" + "19.1.19.C.05": [ + "NET-03" ], - "18.3.14.C.02": [ - "AST-20", - "AST-21" + "19.1.20.C.01": [ + "NET-03" ], - "18.3.8.C.01": [ - "AST-21" + "19.1.20.C.02": [ + "NET-03" ], - "18.3.9.C.01": [ - "AST-21" + "19.1.20.C.03": [ + "NET-03" ], - "18.3.9.C.02": [ - "AST-21" + "19.1.21.C.01": [ + "NET-03" ], - "18.3.10.C.01": [ - "AST-21" + "19.1.22.C.01": [ + "NET-03" ], - "18.3.11.C.01": [ - "AST-21" + "19.1.22.C.02": [ + "NET-03" ], - "18.3.11.C.02": [ - "AST-21" + "19.1.22.C.03": [ + "NET-03" ], - "18.3.12.C.01": [ - "AST-21" + "19.1.23.C.01": [ + "NET-03" ], - "18.3.12.C.02": [ - "AST-21" + "19.3.8.C.01": [ + "NET-03" ], - "18.3.13.C.01": [ - "AST-21" + "19.3.8.C.02": [ + "NET-03" ], - "18.3.13.C.02": [ - "AST-21" + "19.3.8.C.03": [ + "NET-03" ], - "18.3.13.C.03": [ - "AST-21" + "19.3.8.C.04": [ + "NET-03" ], - "18.3.15.C.01": [ - "AST-21" + "19.3.9.C.01": [ + "NET-03" ], - "18.3.15.C.02": [ - "AST-21" + "19.3.9.C.02": [ + "NET-03" ], - "18.3.16.C.01": [ - "AST-21" + "19.3.9.C.03": [ + "NET-03" ], - "18.3.16.C.02": [ - "AST-21" + "19.4.4.C.01": [ + "NET-03" ], - "18.3.16.C.03": [ - "AST-21" + "19.4.5.C.01": [ + "NET-03" ], - "18.3.17.C.01": [ - "AST-21" + "19.4.5.C.02": [ + "NET-03" ], - "11.2.3.C.01": [ - "AST-23" + "19.4.5.C.03": [ + "NET-03" ], - "11.2.4.C.01": [ - "AST-23" + "19.4.6.C.01": [ + "NET-03" ], - "11.2.4.C.02": [ - "AST-23" + "19.5.24.C.01": [ + "NET-03" ], - "11.2.5.C.01": [ - "AST-23" + "19.5.24.C.02": [ + "NET-03" ], - "11.2.6.C.01": [ - "AST-23" + "19.5.24.C.03": [ + "NET-03" ], - "11.2.7.C.01": [ - "AST-23" + "19.5.24.C.04": [ + "NET-03" ], - "11.2.7.C.02": [ - "AST-23" + "19.5.24.C.05": [ + "NET-03" ], - "11.2.8.C.01": [ - "AST-23" + "19.5.24.C.06": [ + "NET-03" ], - "11.2.9.C.01": [ - "AST-23" + "19.5.24.C.07": [ + "NET-03" ], - "11.2.10.C.01": [ - "AST-23" + "19.5.24.C.08": [ + "NET-03" ], - "11.2.11.C.01": [ - "AST-23" + "19.5.25.C.01": [ + "NET-03" ], - "11.2.11.C.02": [ - "AST-23" + "19.5.26.C.01": [ + "NET-03" ], - "11.2.11.C.03": [ - "AST-23" + "19.5.26.C.02": [ + "NET-03" ], - "11.2.11.C.04": [ - "AST-23" + "19.5.26.C.03": [ + "NET-03" ], - "11.2.11.C.05": [ - "AST-23" + "19.5.26.C.04": [ + "NET-03" ], - "11.2.12.C.01": [ - "AST-23" + "19.5.26.C.05": [ + "NET-03" ], - "11.2.12.C.02": [ - "AST-23" + "19.5.26.C.06": [ + "NET-03" ], - "3.4.10.C.01": [ - "AST-26", - "AST-28", - "HRS-03", - "TDA-04" + "19.5.26.C.07": [ + "NET-03" ], - "3.4.10.C.02": [ - "AST-26", - "AST-28", - "HRS-03", - "TDA-04" + "19.5.26.C.08": [ + "NET-03" ], - "5.1.11.C.01": [ - "AST-26", - "AST-28", - "OPS-01.1" + "19.5.26.C.09": [ + "NET-03" ], - "5.1.13.C.01": [ - "AST-26", - "AST-28", - "OPS-01.1" + "19.5.26.C.10": [ + "NET-03" ], - "5.5.3.C.01": [ - "AST-26", - "AST-28", - "OPS-01.1" + "19.5.26.C.11": [ + "NET-03" ], - "5.5.4.C.01": [ - "AST-26", - "AST-28", - "OPS-01.1" + "19.5.26.C.12": [ + "NET-03" ], - "5.5.5.C.01": [ - "AST-26", - "AST-28", - "OPS-01.1" + "19.5.27.C.01": [ + "NET-03" ], - "5.5.6.C.01": [ - "AST-26", - "AST-28", - "OPS-01.1" + "19.5.27.C.02": [ + "NET-03" ], - "18.6.10.C.01": [ - "AST-26" + "19.5.27.C.03": [ + "NET-03" ], - "20.4.3.C.01": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.27.C.04": [ + "NET-03" ], - "20.4.3.C.02": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.27.C.05": [ + "NET-03" ], - "20.4.3.C.03": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.27.C.06": [ + "NET-03" ], - "20.4.3.C.04": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.28.C.01": [ + "NET-03" ], - "20.4.4.C.01": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.28.C.02": [ + "NET-03" ], - "20.4.4.C.02": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.28.C.03": [ + "NET-03" ], - "20.4.5.C.01": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.28.C.04": [ + "NET-03" ], - "20.4.5.C.02": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.28.C.05": [ + "NET-03" ], - "20.4.6.C.01": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.28.C.06": [ + "NET-03" ], - "20.4.6.C.02": [ - "AST-28", - "AST-28.1", - "DCH-16" + "19.5.28.C.07": [ + "NET-03" ], - "11.6.59.C.01": [ - "AST-29" + "19.5.29.C.01": [ + "NET-03" ], - "11.6.59.C.02": [ - "AST-29" + "21.3.5.C.01": [ + "NET-03" ], - "11.6.60.C.01": [ - "AST-29" + "21.3.5.C.02": [ + "NET-03" ], - "11.6.60.C.02": [ - "AST-29" + "21.3.6.C.01": [ + "NET-03" ], - "11.6.60.C.03": [ - "AST-29" + "14.1.11.C.01": [ + "NET-03.8" ], - "11.6.60.C.04": [ - "AST-29" + "18.1.13.C.01": [ + "NET-04", + "NET-04.1" ], - "11.6.61.C.01": [ - "AST-29" + "18.1.13.C.02": [ + "NET-04", + "NET-04.1" ], - "11.6.61.C.02": [ - "AST-29" + "18.1.14.C.01": [ + "NET-04", + "NET-04.1" ], - "11.6.62.C.01": [ - "AST-29" + "14.1.13.C.01": [ + "NET-05.1" ], - "11.6.62.C.02": [ - "AST-29" + "14.1.13.C.02": [ + "NET-05.1" ], - "11.6.62.C.03": [ - "AST-29" + "14.1.13.C.03": [ + "NET-05.1" ], - "11.6.63.C.01": [ - "AST-29" + "20.3.9.C.03": [ + "NET-06.2" ], - "11.6.63.C.02": [ - "AST-29" + "15.1.8.C.01": [ + "NET-13" ], - "11.6.64.C.01": [ - "AST-29" + "15.1.8.C.02": [ + "NET-13" ], - "11.6.65.C.01": [ - "AST-29" + "15.1.9.C.01": [ + "NET-13" ], - "11.6.65.C.02": [ - "AST-29" + "15.1.10.C.01": [ + "NET-13" ], - "11.6.65.C.03": [ - "AST-29" + "15.1.10.C.02": [ + "NET-13" ], - "11.6.66.C.01": [ - "AST-29" + "15.1.10.C.03": [ + "NET-13" ], - "11.6.67.C.01": [ - "AST-29" + "15.1.11.C.01": [ + "NET-13" ], - "11.6.67.C.02": [ - "AST-29" + "15.1.11.C.02": [ + "NET-13" ], - "11.6.68.C.01": [ - "AST-29" + "15.1.11.C.03": [ + "NET-13" ], - "11.6.69.C.01": [ - "AST-29" + "15.1.12.C.01": [ + "NET-13" ], - "11.6.70.C.01": [ - "AST-29" + "15.1.13.C.01": [ + "NET-13" ], - "11.6.71.C.01": [ - "AST-29" + "15.1.14.C.01": [ + "NET-13" ], - "11.6.72.C.01": [ - "AST-29" + "15.1.15.C.01": [ + "NET-13" ], - "11.6.72.C.02": [ - "AST-29" + "15.1.16.C.01": [ + "NET-13" ], - "11.6.72.C.03": [ - "AST-29" + "15.1.17.C.01": [ + "NET-13" ], - "11.7.29.C.01": [ - "AST-29.1" + "15.1.18.C.01": [ + "NET-13" ], - "11.7.29.C.02": [ - "AST-29.1" + "15.1.19.C.01": [ + "NET-13" ], - "11.7.30.C.01": [ - "AST-29.1" + "15.1.19.C.02": [ + "NET-13" ], - "11.7.30.C.02": [ - "AST-29.1" + "15.1.20.C.01": [ + "NET-13" ], - "11.7.30.C.03": [ - "AST-29.1" + "16.5.10.C.01": [ + "NET-14" ], - "11.7.31.C.01": [ - "AST-29.1" + "16.5.10.C.02": [ + "NET-14" ], - "11.7.31.C.02": [ - "AST-29.1" + "16.5.11.C.01": [ + "NET-14", + "NET-14.4" ], - "11.7.32.C.01": [ - "AST-29.1" + "16.5.11.C.02": [ + "NET-14", + "NET-14.4" ], - "11.7.32.C.02": [ - "AST-29.1" + "16.5.12.C.01": [ + "NET-14" ], - "11.7.32.C.03": [ - "AST-29.1" + "17.5.7.C.01": [ + "NET-14" ], - "11.7.32.C.04": [ - "AST-29.1" + "17.5.7.C.02": [ + "NET-14" ], - "11.7.33.C.01": [ - "AST-29.1" + "17.5.8.C.01": [ + "NET-14" ], - "11.7.33.C.02": [ - "AST-29.1" + "17.5.8.C.02": [ + "NET-14" ], - "11.7.33.C.03": [ - "AST-29.1" + "17.5.8.C.03": [ + "NET-14" ], - "11.7.34.C.01": [ - "AST-29.1" + "17.5.9.C.01": [ + "NET-14" ], - "2.3.30.C.01": [ - "AST-30", - "TPM-05" + "17.5.10.C.01": [ + "NET-14" ], - "13.1.9.C.01": [ - "AST-30" + "21.2.4.C.01": [ + "NET-14.5" ], - "13.1.10.C.01": [ - "AST-30" + "21.2.5.C.01": [ + "NET-14.5" ], - "13.1.10.C.02": [ - "AST-30" + "21.2.6.C.01": [ + "NET-14.5" ], - "13.1.10.C.03": [ - "AST-30" + "21.2.7.C.01": [ + "NET-14.5" ], - "13.1.10.C.04": [ - "AST-30" + "22.2.4.C.01": [ + "NET-14.5" ], - "13.1.11.C.01": [ - "AST-30" + "22.2.4.C.02": [ + "NET-14.5" ], - "13.1.12.C.01": [ - "AST-30" + "18.2.5.C.01": [ + "NET-15" ], - "13.1.12.C.02": [ - "AST-30" + "18.2.5.C.02": [ + "NET-15" ], - "13.1.12.C.03": [ - "AST-30" + "18.2.7.C.01": [ + "NET-15" ], - "13.1.13.C.01": [ - "AST-30" + "18.2.8.C.01": [ + "NET-15" ], - "13.1.13.C.02": [ - "AST-30" + "18.2.26.C.01": [ + "NET-15" ], - "13.1.13.C.03": [ - "AST-30" + "18.2.27.C.01": [ + "NET-15" ], - "13.1.13.C.04": [ - "AST-30" + "18.2.28.C.01": [ + "NET-15" ], - "13.1.14.C.01": [ - "AST-30" + "18.2.28.C.02": [ + "NET-15" ], - "6.4.5.C.01": [ - "BCD-01" + "18.2.29.C.01": [ + "NET-15" ], - "6.4.7.C.01": [ - "BCD-01" + "18.2.29.C.02": [ + "NET-15" ], - "6.4.8.C.01": [ - "BCD-01" + "18.2.29.C.03": [ + "NET-15" ], - "23.4.12.C.01": [ - "BCD-01" + "18.2.30.C.01": [ + "NET-15" ], - "23.4.12.C.02": [ - "BCD-01" + "18.2.31.C.01": [ + "NET-15" ], - "6.4.6.C.01": [ - "BCD-11" + "18.2.32.C.01": [ + "NET-15" ], - "6.3.6.C.01": [ - "CHG-01" + "18.2.34.C.01": [ + "NET-15" ], - "6.3.6.C.02": [ - "CHG-02" + "18.2.19.C.02": [ + "NET-15.1" ], - "6.3.7.C.01": [ - "CHG-02" + "18.2.19.C.03": [ + "NET-15.1" ], - "6.3.7.C.02": [ - "CHG-02" + "18.2.33.C.01": [ + "NET-15.4" ], - "6.3.7.C.03": [ - "CHG-02" + "22.4.12.C.02": [ + "NET-15.5" ], - "6.3.8.C.01": [ - "CHG-02.2", - "IAO-02", - "IAO-02.4", - "IAO-05" + "22.4.12.C.03": [ + "NET-15.5" ], - "22.1.20.C.01": [ - "CLD-01" + "15.2.39.C.01": [ + "NET-17" ], - "22.1.20.C.02": [ - "CLD-01" + "15.2.40.C.01": [ + "NET-17" ], - "22.1.20.C.03": [ - "CLD-01" + "9.3.6.C.01": [ + "NET-18" ], - "22.1.20.C.04": [ - "CLD-01" + "14.3.6.C.01": [ + "NET-18", + "NET-18.1" ], - "22.1.20.C.05": [ - "CLD-01" + "14.3.6.C.03": [ + "NET-18", + "NET-18.1" ], - "22.1.21.C.01": [ - "CLD-01" + "14.3.10.C.01": [ + "NET-18" ], - "22.1.21.C.02": [ - "CLD-01" + "14.3.10.C.02": [ + "NET-18" ], - "22.1.21.C.03": [ - "CLD-01" + "14.3.10.C.03": [ + "NET-18" ], - "22.1.21.C.04": [ - "CLD-01" + "14.3.10.C.04": [ + "NET-18" ], - "22.1.21.C.05": [ - "CLD-01" + "14.3.11.C.01": [ + "NET-18" ], - "22.1.21.C.06": [ - "CLD-01" + "14.3.11.C.02": [ + "NET-18" ], - "22.1.21.C.07": [ - "CLD-01" + "14.3.12.C.01": [ + "NET-18" ], - "22.1.24.C.01": [ - "CLD-01", - "CLD-11" + "20.3.9.C.01": [ + "NET-18" ], - "22.1.24.C.02": [ - "CLD-01", - "CLD-03", - "CLD-11" + "20.3.10.C.01": [ + "NET-18" ], - "22.1.24.C.03": [ - "CLD-01", - "CLD-11" + "20.3.11.C.01": [ + "NET-18" ], - "22.1.24.C.04": [ - "CLD-01", - "CLD-11" + "20.3.11.C.02": [ + "NET-18" ], - "22.1.25.C.01": [ - "CLD-01" + "21.3.7.C.01": [ + "NET-18" ], - "22.1.25.C.02": [ - "CLD-01" + "21.3.7.C.02": [ + "NET-18" ], - "22.1.26.C.01": [ - "CLD-01" + "21.3.14.C.01": [ + "NET-18" ], - "22.1.26.C.02": [ - "CLD-01" + "15.2.46.C.02": [ + "NET-18.1" ], - "22.1.26.C.03": [ - "CLD-01" + "14.3.8.C.01": [ + "NET-18.2" ], - "22.1.27.C.01": [ - "CLD-01" + "14.3.9.C.01": [ + "NET-18.2" ], - "23.1.54.C.01": [ - "CLD-01", - "CLD-02" + "15.2.36.C.01": [ + "NET-20.4" ], - "23.1.54.C.02": [ - "CLD-01", - "CLD-02" + "15.2.36.C.02": [ + "NET-20.4" ], - "23.2.19.C.01": [ - "CLD-01", - "TPM-01", - "TPM-05", - "VPM-02", - "VPM-04", - "VPM-05" + "15.2.36.C.03": [ + "NET-20.4" ], - "23.4.9.C.01": [ - "CLD-01.1" + "15.2.36.C.04": [ + "NET-20.4" ], - "23.4.9.C.02": [ - "CLD-01.1", - "CRY-09", - "CRY-09.7" + "15.2.36.C.05": [ + "NET-20.4" ], - "23.4.9.C.03": [ - "CLD-01.1", - "CRY-09", - "CRY-09.7" + "8.1.10.C.01": [ + "PES-01" ], - "23.4.10.C.01": [ - "CLD-01.1", - "IAC-21" + "20.2.16.C.01": [ + "PES-01" ], - "23.5.11.C.01": [ - "CLD-01.1", - "CLD-06.2" + "8.2.7.C.01": [ + "PES-01.1" ], - "23.5.12.C.01": [ - "CLD-01.1", - "CLD-06.2", - "CLD-06.4" + "8.1.11.C.01": [ + "PES-02" ], - "23.5.12.C.02": [ - "CLD-01.1", - "CLD-06.2", - "CLD-06.4" + "8.1.11.C.02": [ + "PES-02" ], - "23.4.13.C.01": [ - "CLD-01.2" + "8.2.8.C.01": [ + "PES-02.2" ], - "23.4.13.C.02": [ - "CLD-01.2" + "8.2.5.C.01": [ + "PES-03.2" ], - "23.4.13.C.03": [ - "CLD-01.2" + "8.3.3.C.01": [ + "PES-03.4", + "PES-07", + "PES-12", + "PES-12.1" ], - "22.1.23.C.01": [ - "CLD-02" + "8.3.4.C.01": [ + "PES-03.4", + "PES-07", + "PES-12", + "PES-12.1" ], - "22.1.23.C.02": [ - "CLD-02" + "8.3.4.C.02": [ + "PES-03.4", + "PES-07", + "PES-12", + "PES-12.1" ], - "22.1.23.C.03": [ - "CLD-02" + "8.3.5.C.01": [ + "PES-03.4", + "PES-07", + "PES-12", + "PES-12.1" ], - "23.1.56.C.01": [ - "CLD-02" + "8.2.6.C.01": [ + "PES-04" ], - "23.2.20.C.01": [ - "CLD-02", - "CLD-06" + "8.2.6.C.02": [ + "PES-04" ], - "23.1.55.C.01": [ - "CLD-06", - "CLD-06.1" + "17.9.36.C.02": [ + "PES-04.1" ], - "23.1.55.C.02": [ - "CLD-06", - "CLD-06.1" + "8.1.13.C.01": [ + "PES-04.2", + "VPM-08" ], - "23.1.55.C.03": [ - "CLD-06", - "CLD-06.1" + "8.1.13.C.02": [ + "PES-04.2", + "VPM-08" ], - "22.1.22.C.01": [ - "CLD-09" + "9.4.4.C.01": [ + "PES-06" ], - "22.1.22.C.02": [ - "CLD-09" + "9.4.5.C.01": [ + "PES-06" ], - "22.1.22.C.03": [ - "CLD-09" + "9.4.5.C.02": [ + "PES-06" ], - "22.1.22.C.04": [ - "CLD-09", - "CLD-10" + "9.4.6.C.01": [ + "PES-06" ], - "22.1.22.C.05": [ - "CLD-09", - "CLD-10" + "9.4.6.C.02": [ + "PES-06" ], - "22.1.22.C.06": [ - "CLD-09" + "9.4.7.C.01": [ + "PES-06", + "PES-06.3" ], - "23.4.11.C.01": [ - "CLD-09" + "9.4.8.C.01": [ + "PES-06" ], - "23.4.11.C.02": [ - "CLD-09" + "9.4.9.C.01": [ + "PES-06", + "PES-06.4", + "PES-06.5" ], - "2.3.23.C.01": [ - "CLD-10" + "9.4.10.C.01": [ + "PES-06" ], - "1.1.64.C.01": [ - "CPL-01" + "8.3.3.C.02": [ + "PES-12.1" ], - "1.1.65.C.01": [ - "CPL-01" + "10.1.42.C.01": [ + "PES-12.1" ], - "1.1.66.C.01": [ - "CPL-01" + "10.1.42.C.02": [ + "PES-12.1" ], - "1.1.66.C.02": [ - "CPL-01" + "10.1.43.C.01": [ + "PES-12.1" ], - "1.1.67.C.01": [ - "CPL-01" + "10.1.43.C.02": [ + "PES-12.1" ], - "1.1.68.C.01": [ - "CPL-01.1" + "10.1.43.C.03": [ + "PES-12.1" ], - "1.1.69.C.01": [ - "CPL-01.1" + "10.1.43.C.04": [ + "PES-12.1" ], - "1.1.69.C.02": [ - "CPL-01.1" + "10.1.44.C.01": [ + "PES-12.1" ], - "6.1.7.C.01": [ - "CPL-02", - "CPL-03", - "CPL-03.2" + "10.1.45.C.01": [ + "PES-12.1" ], - "4.3.16.C.01": [ - "CPL-03", - "IAO-02.1", - "IAO-02.3" + "10.1.45.C.02": [ + "PES-12.1" ], - "6.1.9.C.01": [ - "CPL-03", - "CPL-03.2" + "10.1.46.C.01": [ + "PES-12.1" ], - "6.1.8.C.01": [ - "CPL-03.1" + "10.1.46.C.02": [ + "PES-12.1" ], - "4.3.19.C.01": [ - "CFG-01", - "CFG-01.1", - "SEA-01.1" + "10.1.46.C.03": [ + "PES-12.1" ], - "12.2.5.C.01": [ - "CFG-01" + "10.1.46.C.04": [ + "PES-12.1" + ], + "10.1.47.C.01": [ + "PES-12.1" + ], + "10.1.47.C.02": [ + "PES-12.1" ], - "12.2.5.C.02": [ - "CFG-01" + "10.1.48.C.01": [ + "PES-12.1" ], - "12.2.6.C.01": [ - "CFG-01" + "10.1.48.C.02": [ + "PES-12.1" ], - "12.2.6.C.02": [ - "CFG-01" + "10.1.48.C.03": [ + "PES-12.1" ], - "18.1.10.C.01": [ - "CFG-01", - "CFG-02.4", - "CFG-02.5", - "CFG-02.6" + "10.1.49.C.01": [ + "PES-12.1" ], - "18.1.10.C.02": [ - "CFG-01", - "CFG-02.4", - "CFG-02.5", - "CFG-02.6" + "10.1.50.C.01": [ + "PES-12.1" ], - "18.1.10.C.03": [ - "CFG-01", - "CFG-02.4", - "CFG-02.5", - "CFG-02.6" + "10.1.50.C.02": [ + "PES-12.1" ], - "18.1.10.C.04": [ - "CFG-01", - "CFG-02.4", - "CFG-02.5", - "CFG-02.6" + "10.1.50.C.03": [ + "PES-12.1" ], - "14.1.8.C.01": [ - "CFG-02" + "10.1.50.C.04": [ + "PES-12.1" ], - "14.1.9.C.01": [ - "CFG-02" + "10.1.51.C.01": [ + "PES-12.1" ], - "14.1.9.C.02": [ - "CFG-02", - "END-04" + "10.2.6.C.01": [ + "PES-12.1" ], - "14.1.10.C.01": [ - "CFG-02" + "10.2.6.C.02": [ + "PES-12.1" ], - "14.1.10.C.02": [ - "CFG-02" + "10.2.7.C.01": [ + "PES-12.1" ], - "14.3.7.C.01": [ - "CFG-02" + "10.2.8.C.01": [ + "PES-12.1" ], - "23.2.21.C.01": [ - "CFG-02", - "CFG-02.5" + "10.2.9.C.01": [ + "PES-12.1" ], - "16.1.50.C.01": [ - "CFG-02.9", - "SEA-19" + "10.2.10.C.01": [ + "PES-12.1" ], - "16.1.50.C.02": [ - "CFG-02.9", - "SEA-19" + "10.3.5.C.01": [ + "PES-12.1" ], - "18.1.15.C.01": [ - "CFG-03", - "TDA-02.1" + "10.3.6.C.01": [ + "PES-12.1" ], - "18.1.15.C.02": [ - "CFG-03", - "TDA-02.1" + "10.3.6.C.02": [ + "PES-12.1" ], - "18.1.15.C.03": [ - "CFG-03", - "TDA-02.1" + "10.3.7.C.01": [ + "PES-12.1" ], - "18.1.15.C.04": [ - "CFG-03", - "TDA-02.1" + "10.3.8.C.01": [ + "PES-12.1" ], - "14.2.4.C.01": [ - "CFG-03.3" + "10.3.9.C.01": [ + "PES-12.1" ], - "14.2.5.C.01": [ - "CFG-03.3" + "10.3.10.C.01": [ + "PES-12.1" ], - "14.2.5.C.02": [ - "CFG-03.3" + "10.3.11.C.01": [ + "PES-12.1" ], - "14.2.5.C.03": [ - "CFG-03.3" + "10.3.12.C.01": [ + "PES-12.1" ], - "14.2.5.C.04": [ - "CFG-03.3" + "10.3.13.C.01": [ + "PES-12.1" ], - "14.2.6.C.01": [ - "CFG-03.3" + "10.4.4.C.01": [ + "PES-12.1" ], - "14.2.7.C.01": [ - "CFG-03.3" + "10.4.4.C.02": [ + "PES-12.1" ], - "14.2.7.C.02": [ - "CFG-03.3" + "10.4.5.C.01": [ + "PES-12.1" ], - "14.2.7.C.03": [ - "CFG-03.3" + "10.4.5.C.02": [ + "PES-12.1" ], - "14.2.7.C.04": [ - "CFG-03.3" + "10.4.6.C.01": [ + "PES-12.1" ], - "14.2.7.C.05": [ - "CFG-03.3" + "10.4.6.C.02": [ + "PES-12.1" ], - "14.2.7.C.06": [ - "CFG-03.3" + "10.4.6.C.03": [ + "PES-12.1" ], - "14.2.7.C.07": [ - "CFG-03.3" + "10.4.7.C.01": [ + "PES-12.1" ], - "18.7.14.C.01": [ - "CFG-03.4" + "10.4.7.C.02": [ + "PES-12.1" ], - "18.7.14.C.02": [ - "CFG-03.4" + "10.4.8.C.01": [ + "PES-12.1" ], - "16.6.6.C.01": [ - "MON-01", - "MON-01.16" + "10.4.9.C.01": [ + "PES-12.1" ], - "16.6.6.C.02": [ - "MON-01", - "MON-01.16" + "10.4.9.C.02": [ + "PES-12.1" ], - "16.6.8.C.01": [ - "MON-01", - "MON-01.16", - "MON-03.2" + "10.4.9.C.03": [ + "PES-12.1" ], - "16.6.10.C.01": [ - "MON-01", - "MON-01.1", - "MON-01.3", - "MON-01.5", - "MON-01.7", - "MON-01.9", - "MON-01.16", - "MON-03", - "MON-03.2", - "MON-03.7" + "10.4.9.C.04": [ + "PES-12.1" ], - "16.6.10.C.02": [ - "MON-01", - "MON-01.1", - "MON-01.3", - "MON-01.5", - "MON-01.7", - "MON-01.9", - "MON-01.16", - "MON-03", - "MON-03.2", - "MON-03.7" + "10.4.10.C.01": [ + "PES-12.1" ], - "18.4.7.C.01": [ - "MON-01.1" + "10.4.11.C.01": [ + "PES-12.1" ], - "18.4.7.C.02": [ - "MON-01.1" + "10.4.12.C.01": [ + "PES-12.1" ], - "18.4.7.C.03": [ - "MON-01.1" + "10.4.13.C.01": [ + "PES-12.1" ], - "18.4.8.C.01": [ - "MON-01.1", - "MON-01.3", - "MON-01.5" + "10.4.13.C.02": [ + "PES-12.1" ], - "18.4.8.C.02": [ - "MON-01.1", - "MON-01.3", - "MON-01.5" + "10.5.4.C.01": [ + "PES-12.1" ], - "18.4.8.C.03": [ - "MON-01.1", - "MON-01.3", - "MON-01.5" + "10.5.5.C.01": [ + "PES-12.1" ], - "18.4.9.C.01": [ - "MON-01.1" + "10.5.6.C.01": [ + "PES-12.1" ], - "18.4.9.C.02": [ - "MON-01.1" + "10.5.6.C.02": [ + "PES-12.1" ], - "18.4.10.C.01": [ - "MON-01.1" + "10.5.7.C.01": [ + "PES-12.1" ], - "18.4.11.C.01": [ - "MON-01.1" + "10.5.8.C.01": [ + "PES-12.1" ], - "18.4.11.C.02": [ - "MON-01.1" + "10.5.8.C.02": [ + "PES-12.1" ], - "18.4.11.C.03": [ - "MON-01.1" + "10.5.9.C.01": [ + "PES-12.1" ], - "18.4.12.C.01": [ - "MON-01.1", - "MON-02.1" + "10.5.9.C.02": [ + "PES-12.1" ], - "18.4.14.C.01": [ - "MON-01.1" + "10.5.10.C.01": [ + "PES-12.1" ], - "14.3.6.C.02": [ - "MON-01.9", - "NET-18", - "NET-18.1" + "10.5.10.C.02": [ + "PES-12.1" ], - "16.6.11.C.01": [ - "MON-02", - "MON-02.2" + "10.5.11.C.01": [ + "PES-12.1" ], - "16.6.11.C.02": [ - "MON-02", - "MON-02.2", - "MON-02.7" + "10.6.22.C.01": [ + "PES-12.1" ], - "16.6.11.C.03": [ - "MON-02", - "MON-02.2" + "10.6.22.C.02": [ + "PES-12.1" ], - "16.6.12.C.01": [ - "MON-02", - "MON-02.2" + "10.6.23.C.01": [ + "PES-12.1" ], - "16.6.12.C.02": [ - "MON-02", - "MON-02.2" + "10.6.23.C.02": [ + "PES-12.1" ], - "16.6.12.C.03": [ - "MON-02", - "MON-02.2" + "10.6.23.C.03": [ + "PES-12.1" ], - "16.6.14.C.01": [ - "MON-02.1" + "10.6.23.C.04": [ + "PES-12.1" ], - "16.6.7.C.01": [ - "MON-03", - "MON-03.7" + "10.6.24.C.01": [ + "PES-12.1" ], - "16.6.9.C.01": [ - "MON-03", - "MON-03.2", - "MON-03.7" + "10.6.24.C.02": [ + "PES-12.1" ], - "16.6.13.C.01": [ - "MON-04", - "MON-08", - "MON-08.1" + "10.6.25.C.01": [ + "PES-12.1" ], - "16.6.13.C.02": [ - "MON-04", - "MON-08", - "MON-08.1" + "10.6.26.C.01": [ + "PES-12.1" ], - "16.6.13.C.03": [ - "MON-04", - "MON-08", - "MON-08.1" + "10.6.27.C.01": [ + "PES-12.1" ], - "16.6.13.C.04": [ - "MON-04", - "MON-08", - "MON-08.1" + "10.6.28.C.01": [ + "PES-12.1" ], - "8.4.13.C.01": [ - "CRY-01", - "CRY-05", - "CRY-05.1", - "DCH-06", - "DCH-06.4", - "DCH-07.2" + "10.6.28.C.02": [ + "PES-12.1" ], - "17.1.52.C.01": [ - "CRY-01" + "10.6.29.C.01": [ + "PES-12.1" ], - "17.1.52.C.02": [ - "CRY-01" + "10.6.30.C.01": [ + "PES-12.1" ], - "17.1.53.C.01": [ - "CRY-01" + "10.6.31.C.01": [ + "PES-12.1" ], - "17.1.53.C.02": [ - "CRY-01" + "11.8.9.C.01": [ + "PES-12.2" ], - "17.1.53.C.03": [ - "CRY-01" + "10.7.6.C.01": [ + "PES-13" ], - "17.1.53.C.04": [ - "CRY-01" + "10.7.6.C.02": [ + "PES-13" ], - "17.1.54.C.01": [ - "CRY-01" + "10.7.7.C.01": [ + "PES-13" ], - "17.1.55.C.01": [ - "CRY-01" + "10.7.7.C.02": [ + "PES-13" ], - "17.1.55.C.02": [ - "CRY-01" + "10.7.8.C.01": [ + "PES-13" ], - "17.1.55.C.03": [ - "CRY-01" + "10.7.9.C.01": [ + "PES-13" ], - "17.1.55.C.04": [ - "CRY-01" + "2.3.25.C.01": [ + "PRM-01.1" ], - "17.1.56.C.01": [ - "CRY-01" + "2.3.25.C.02": [ + "PRM-01.1" ], - "17.1.56.C.02": [ - "CRY-01" + "2.3.29.C.01": [ + "PRM-01.1" ], - "17.1.57.C.01": [ - "CRY-01" + "12.1.30.C.01": [ + "PRM-05" ], - "17.2.17.C.01": [ - "CRY-01" + "12.1.30.C.02": [ + "PRM-05" ], - "17.2.18.C.01": [ - "CRY-01" + "12.1.30.C.03": [ + "PRM-05" ], - "17.2.19.C.01": [ - "CRY-01" + "12.1.32.C.01": [ + "PRM-05", + "PRM-06", + "TDA-01.1" ], - "17.2.20.C.01": [ - "CRY-01" + "12.1.32.C.02": [ + "PRM-05", + "PRM-06", + "TDA-01.1" ], - "17.2.20.C.02": [ - "CRY-01" + "12.1.32.C.03": [ + "PRM-05", + "PRM-06", + "TDA-01.1" ], - "17.2.21.C.01": [ - "CRY-01" + "5.3.6.C.01": [ + "RSK-01" ], - "17.2.22.C.01": [ - "CRY-01" + "5.3.7.C.01": [ + "RSK-01" ], - "17.2.22.C.02": [ - "CRY-01" + "5.3.8.C.01": [ + "RSK-01" ], - "17.2.23.C.01": [ - "CRY-01" + "5.3.9.C.01": [ + "RSK-01" ], - "17.2.24.C.01": [ - "CRY-01" + "23.2.16.C.01": [ + "RSK-01.1", + "RSK-02.1" ], - "17.2.24.C.02": [ - "CRY-01" + "23.2.17.C.01": [ + "RSK-01.1", + "RSK-02.1" ], - "17.2.24.C.03": [ - "CRY-01" + "2.4.13.C.01": [ + "RSK-03" ], - "17.2.25.C.01": [ - "CRY-01" + "2.4.13.C.02": [ + "RSK-03" ], - "17.2.26.C.01": [ - "CRY-01" + "2.4.13.C.03": [ + "RSK-03" ], - "17.2.26.C.02": [ - "CRY-01" + "2.4.13.C.04": [ + "RSK-03" ], - "17.2.26.C.03": [ - "CRY-01" + "2.4.13.C.05": [ + "RSK-03" ], - "17.2.27.C.01": [ - "CRY-01" + "2.4.13.C.06": [ + "RSK-03" ], - "17.2.27.C.02": [ - "CRY-01" + "2.4.13.C.07": [ + "RSK-03" ], - "17.2.27.C.03": [ - "CRY-01" + "2.3.27.C.01": [ + "RSK-04" ], - "17.2.28.C.01": [ - "CRY-01" + "2.3.27.C.02": [ + "RSK-04" ], - "17.3.6.C.01": [ - "CRY-01" + "5.9.23.C.01": [ + "RSK-04", + "THR-06" ], - "17.4.16.C.01": [ - "CRY-01" + "22.4.7.C.01": [ + "RSK-04" ], - "17.4.16.C.02": [ - "CRY-01" + "23.2.16.C.02": [ + "RSK-04" ], - "17.5.6.C.01": [ - "CRY-01", - "NET-14" + "11.1.18.C.03": [ + "RSK-06.2" ], - "17.6.6.C.01": [ - "CRY-01", - "NET-13" + "12.4.5.C.01": [ + "RSK-06.2", + "TDA-01.1" ], - "17.6.7.C.01": [ - "CRY-01", - "NET-13" + "2.2.7.C.01": [ + "RSK-09" ], - "17.7.6.C.01": [ - "CRY-01" + "12.7.14.C.01": [ + "RSK-09", + "TPM-03" ], - "17.8.10.C.01": [ - "CRY-01" + "12.7.14.C.02": [ + "RSK-09", + "TPM-03" ], - "17.8.10.C.02": [ - "CRY-01" + "12.7.14.C.03": [ + "RSK-09", + "TPM-03" ], - "17.8.11.C.01": [ - "CRY-01" + "12.7.15.C.01": [ + "RSK-09", + "TPM-03" ], - "17.8.12.C.01": [ - "CRY-01" + "12.7.15.C.02": [ + "RSK-09", + "TPM-03" ], - "17.8.13.C.01": [ - "CRY-01" + "12.7.16.C.01": [ + "RSK-09", + "TPM-03" ], - "17.8.14.C.01": [ - "CRY-01" + "12.7.16.C.02": [ + "RSK-09", + "TPM-03" ], - "17.8.15.C.01": [ - "CRY-01" + "12.7.16.C.03": [ + "RSK-09", + "TPM-03" ], - "17.8.16.C.01": [ - "CRY-01" + "12.7.17.C.01": [ + "RSK-09", + "TPM-02", + "TPM-03" ], - "17.8.17.C.01": [ - "CRY-01" + "12.7.18.C.01": [ + "RSK-09", + "TPM-03" ], - "17.9.24.C.01": [ - "CRY-01" + "12.7.18.C.02": [ + "RSK-09", + "TPM-03" ], - "17.9.24.C.02": [ - "CRY-01" + "12.7.19.C.01": [ + "RSK-09", + "TPM-03" ], - "17.9.24.C.03": [ - "CRY-01" + "12.7.19.C.02": [ + "RSK-09", + "TPM-03" ], - "17.9.25.C.01": [ - "CRY-01" + "12.7.20.C.01": [ + "RSK-09", + "TPM-03" ], - "17.9.26.C.01": [ - "CRY-01" + "12.7.20.C.02": [ + "RSK-09", + "TPM-03" ], - "17.9.26.C.02": [ - "CRY-01" + "12.7.20.C.03": [ + "RSK-09", + "TPM-03" ], - "17.9.27.C.01": [ - "CRY-01" + "12.7.20.C.04": [ + "RSK-09", + "TPM-03" ], - "17.9.27.C.02": [ - "CRY-01" + "12.7.20.C.05": [ + "RSK-09", + "TPM-03" ], - "17.9.27.C.03": [ - "CRY-01" + "12.7.21.C.01": [ + "RSK-09", + "TPM-03" ], - "17.9.28.C.01": [ - "CRY-01" + "20.2.14.C.01": [ + "SEA-01", + "SEA-13.1" ], - "17.9.29.C.01": [ - "CRY-01" + "20.2.14.C.03": [ + "SEA-01", + "SEA-13.1" ], - "17.9.30.C.01": [ - "CRY-01" + "20.2.12.C.03": [ + "SEA-13.1" ], - "17.9.30.C.02": [ - "CRY-01" + "20.2.12.C.04": [ + "SEA-13.1" ], - "17.9.31.C.01": [ - "CRY-01" + "16.1.44.C.02": [ + "SEA-18" ], - "17.9.32.C.01": [ - "CRY-01" + "16.1.44.C.03": [ + "SEA-18" ], - "17.9.32.C.02": [ - "CRY-01" + "20.2.15.C.01": [ + "OPS-01.1" ], - "17.9.32.C.03": [ - "CRY-01" + "21.1.7.C.01": [ + "OPS-01.1" ], - "18.2.9.C.01": [ - "CRY-07" + "21.1.7.C.02": [ + "OPS-01.1" ], - "18.2.10.C.01": [ - "CRY-07", - "NET-15.1" + "5.1.15.C.01": [ + "OPS-02" ], - "18.2.10.C.02": [ - "CRY-07", - "NET-15.1" + "9.1.4.C.01": [ + "SAT-01" ], - "18.2.11.C.01": [ - "CRY-07", - "NET-15.1" + "9.1.5.C.01": [ + "SAT-02" ], - "18.2.11.C.02": [ - "CRY-07", - "NET-15.1" + "9.1.5.C.02": [ + "SAT-02" ], - "18.2.11.C.03": [ - "CRY-07", - "NET-15.1" + "9.1.6.C.01": [ + "SAT-02", + "SAT-03" ], - "18.2.11.C.04": [ - "CRY-07", - "NET-15.1" + "9.1.6.C.02": [ + "SAT-02", + "SAT-03" ], - "18.2.11.C.05": [ - "CRY-07", - "NET-15.1" + "16.4.43.C.01": [ + "SAT-02" ], - "18.2.12.C.01": [ - "CRY-07", - "NET-15.1" + "20.1.27.C.01": [ + "SAT-02" ], - "18.2.12.C.02": [ - "CRY-07", - "NET-15.1" + "2.1.47.C.01": [ + "SAT-03" ], - "18.2.13.C.01": [ - "CRY-07", - "NET-15.1" + "9.1.6.C.03": [ + "SAT-03" ], - "18.2.14.C.01": [ - "CRY-07", - "NET-15.1" + "22.1.11.C.01": [ + "SAT-03.3" ], - "18.2.15.C.01": [ - "CRY-07", - "NET-15.1" + "12.1.31.C.01": [ + "TDA-01.1" ], - "18.2.16.C.01": [ - "CRY-07", - "NET-15.1" + "12.1.33.C.01": [ + "TDA-01.1" ], - "18.2.17.C.01": [ - "CRY-07", - "NET-15.1" + "12.1.34.C.01": [ + "TDA-01.1" ], - "18.2.18.C.01": [ - "CRY-07", - "NET-15.1" + "12.1.34.C.02": [ + "TDA-01.1" ], - "18.2.19.C.01": [ - "CRY-07", - "NET-15.1" + "12.1.35.C.01": [ + "TDA-01.1" ], - "18.2.20.C.01": [ - "CRY-07", - "NET-15.1" + "12.1.36.C.01": [ + "TDA-01.1" ], - "18.2.20.C.02": [ - "CRY-07", - "NET-15.1" + "12.1.37.C.01": [ + "TDA-01.1" ], - "18.2.20.C.03": [ - "CRY-07", - "NET-15.1" + "12.4.3.C.01": [ + "TDA-01.1" ], - "18.2.21.C.01": [ - "CRY-07", - "NET-15.1" + "12.4.4.C.01": [ + "TDA-01.1" ], - "18.2.22.C.01": [ - "CRY-07", - "NET-15.1" + "12.4.4.C.02": [ + "TDA-01.1" ], - "18.2.23.C.01": [ - "CRY-07", - "NET-15.1" + "12.4.4.C.03": [ + "TDA-01.1" ], - "18.2.23.C.02": [ - "CRY-07", - "NET-15.1" + "12.4.4.C.04": [ + "TDA-01.1" ], - "18.2.24.C.01": [ - "CRY-07", - "NET-15.1" + "12.4.4.C.05": [ + "TDA-01.1" ], - "18.2.25.C.01": [ - "CRY-07", - "NET-15", - "NET-15.1" + "12.4.4.C.06": [ + "TDA-01.1" ], - "17.1.51.C.01": [ - "CRY-08", - "CRY-08.1", - "CRY-09" + "12.4.6.C.01": [ + "TDA-01.1" ], - "17.1.51.C.02": [ - "CRY-08", - "CRY-08.1" + "12.4.7.C.01": [ + "TDA-01.1", + "TDA-17" ], - "17.1.51.C.03": [ - "CRY-08", - "CRY-08.1" + "14.4.5.C.01": [ + "TDA-06" ], - "23.3.21.C.01": [ - "CRY-08", - "CRY-09", - "CRY-11" + "14.4.6.C.01": [ + "TDA-06.1", + "TDA-06.2" ], - "23.3.22.C.01": [ - "CRY-08", - "CRY-09", - "CRY-11" + "14.4.6.C.02": [ + "TDA-06.1", + "TDA-06.2" ], - "17.1.58.C.01": [ - "CRY-09" + "14.4.6.C.03": [ + "TDA-06.1", + "TDA-06.2" ], - "17.1.58.C.02": [ - "CRY-09" + "14.4.4.C.01": [ + "TDA-07" ], - "17.1.58.C.03": [ - "CRY-09" + "20.2.14.C.06": [ + "TDA-08" ], - "7.2.24.C.01": [ - "CRY-09.3" + "14.5.6.C.01": [ + "TDA-09.4", + "TDA-09.5", + "WEB-01" ], - "7.2.25.C.01": [ - "CRY-09.3" + "2.2.6.C.01": [ + "TPM-01" ], - "4.4.10.C.01": [ - "DCH-01", - "DCH-04", - "IAO-01" + "2.2.6.C.02": [ + "TPM-01" ], - "9.2.12.C.01": [ - "DCH-01" + "20.1.20.C.05": [ + "TPM-05" ], - "9.2.13.C.01": [ - "DCH-01" + "20.1.23.C.02": [ + "TPM-05" ], - "9.2.13.C.02": [ - "DCH-01" + "20.1.23.C.03": [ + "TPM-05" ], - "9.2.14.C.01": [ - "DCH-01" + "20.1.24.C.01": [ + "TPM-05" ], - "9.2.15.C.01": [ - "DCH-01", - "HRS-04.3", - "HRS-04.4" + "20.1.25.C.01": [ + "TPM-05" ], - "9.2.15.C.02": [ - "DCH-01", - "HRS-04.3", - "HRS-04.4" + "5.9.24.C.01": [ + "THR-06" ], - "9.2.17.C.01": [ - "DCH-01" + "5.9.24.C.02": [ + "THR-06" ], - "9.2.17.C.02": [ - "DCH-01" + "5.9.25.C.01": [ + "THR-06" ], - "9.2.18.C.01": [ - "DCH-01" + "5.9.26.C.01": [ + "THR-06" ], - "9.2.19.C.01": [ - "DCH-01" + "5.9.26.C.02": [ + "THR-06" ], - "9.2.19.C.02": [ - "DCH-01" + "5.9.27.C.01": [ + "THR-06" ], - "9.2.19.C.03": [ - "DCH-01" + "6.2.4.C.01": [ + "VPM-01", + "VPM-01.1" ], - "9.2.19.C.04": [ - "DCH-01" + "22.1.18.C.01": [ + "VPM-05" ], - "9.2.20.C.01": [ - "DCH-01" + "14.1.14.C.01": [ + "VPM-06.8" ], - "13.2.6.C.01": [ - "DCH-01" + "14.5.7.C.01": [ + "WEB-01", + "WEB-07", + "WEB-08" ], - "13.2.7.C.01": [ - "DCH-01" + "14.5.8.C.01": [ + "WEB-01", + "WEB-07", + "WEB-08" + ] + }, + "apac-nzl-privacy-act-2020": { + "6.2.126(1)": [ + "CPL-01" ], - "18.6.8.C.01": [ - "DCH-01.2", - "DCH-02" + "6.2.126(2)": [ + "CPL-01" ], - "12.3.4.C.01": [ - "DCH-02", - "DCH-04" + "6.2.126(2)(a)": [ + "CPL-01" ], - "12.3.5.C.01": [ - "DCH-02", - "DCH-04" + "6.2.126(2)(b)": [ + "CPL-01" ], - "12.3.5.C.02": [ - "DCH-02", - "DCH-04" + "3.1.22.7(4)": [ + "DCH-22.1" ], - "12.3.6.C.01": [ - "DCH-02", - "DCH-04" + "6.1.115(1)": [ + "IRO-10" ], - "12.3.7.C.01": [ - "DCH-02", - "DCH-04" + "6.1.115(2)": [ + "IRO-10" ], - "4.4.9.C.01": [ - "DCH-02.1", - "IAO-01" + "6.1.115(3)": [ + "IRO-10" ], - "13.2.8.C.01": [ - "DCH-02.1" + "6.1.115(3)(a)": [ + "IRO-10" ], - "13.2.9.C.01": [ - "DCH-02.1" + "6.1.115(3)(b)": [ + "IRO-10" ], - "18.6.9.C.01": [ - "DCH-02.1" + "6.1.115(4)": [ + "IRO-10" ], - "13.2.12.C.01": [ - "DCH-04" + "6.1.115(4)(a)": [ + "IRO-10" ], - "13.2.12.C.02": [ - "DCH-04" + "6.1.115(4)(b)": [ + "IRO-10" ], - "13.2.12.C.03": [ - "DCH-04" + "6.1.117(1)": [ + "IRO-10" ], - "13.2.12.C.04": [ - "DCH-04" + "6.1.117(1)(a)": [ + "IRO-10" ], - "13.2.13.C.01": [ - "DCH-04" + "6.1.117(1)(a)(i)": [ + "IRO-10" ], - "13.2.14.C.01": [ - "DCH-04" + "6.1.117(1)(a)(ii)": [ + "IRO-10" ], - "13.2.14.C.02": [ - "DCH-04" + "6.1.117(1)(b)": [ + "IRO-10" ], - "21.1.21.C.01": [ - "DCH-04" + "6.1.117(1)(c)": [ + "IRO-10" ], - "8.4.10.C.01": [ - "DCH-06" + "6.1.117(1)(d)": [ + "IRO-10" ], - "8.4.11.C.01": [ - "DCH-06" + "6.1.117(1)(e)": [ + "IRO-10" ], - "8.4.12.C.01": [ - "DCH-06" + "6.1.117(1)(f)": [ + "IRO-10" ], - "13.3.5.C.01": [ - "DCH-06" + "6.1.117(2)": [ + "IRO-10" ], - "12.6.6.C.01": [ - "DCH-08" + "6.1.117(2)(a)": [ + "IRO-10" ], - "12.6.6.C.02": [ - "DCH-08" + "6.1.117(2)(b)": [ + "IRO-10" ], - "12.6.7.C.01": [ - "DCH-08" + "6.1.117(2)(c)": [ + "IRO-10" ], - "12.6.7.C.02": [ - "DCH-08" + "6.1.117(2)(d)": [ + "IRO-10" ], - "13.5.23.C.01": [ - "DCH-08" + "6.1.117(2)(e)": [ + "IRO-10" ], - "13.4.9.C.01": [ - "DCH-09" + "6.1.117(2)(f)": [ + "IRO-10" ], - "13.4.11.C.01": [ - "DCH-09" + "6.1.117(3)": [ + "IRO-10" ], - "13.4.12.C.01": [ - "DCH-09" + "6.1.117(4)": [ + "IRO-10" ], - "13.4.13.C.01": [ - "DCH-09" + "6.1.117(5)": [ + "IRO-10" ], - "13.4.13.C.02": [ - "DCH-09" + "3.1.22.12(1)": [ + "PRI-01.5" ], - "13.4.13.C.03": [ - "DCH-09" + "3.1.22.12(1)(a)": [ + "PRI-01.5" ], - "13.4.13.C.04": [ - "DCH-09" + "3.1.22.12(1)(b)": [ + "PRI-01.5" ], - "13.4.13.C.05": [ - "DCH-09" + "3.1.22.12(1)(c)": [ + "PRI-01.5" ], - "13.4.14.C.01": [ - "DCH-09" + "3.1.22.12(1)(d)": [ + "PRI-01.5" ], - "13.4.15.C.01": [ - "DCH-09" + "3.1.22.12(1)(e)": [ + "PRI-01.5" ], - "13.4.16.C.01": [ - "DCH-09" + "3.1.22.12(1)(f)": [ + "PRI-01.5" ], - "13.4.17.C.01": [ - "DCH-09" + "3.1.22.12(2)": [ + "PRI-01.5" ], - "13.4.18.C.01": [ - "DCH-09" + "3.1.22.12(3)": [ + "PRI-01.5" ], - "13.4.19.C.01": [ - "DCH-09" + "3.1.22.5(a)": [ + "PRI-01.6" ], - "13.4.20.C.01": [ - "DCH-09" + "3.1.22.5(a)(i)": [ + "PRI-01.6" ], - "13.4.20.C.02": [ - "DCH-09" + "3.1.22.5(a)(ii)": [ + "PRI-01.6" ], - "13.4.20.C.03": [ - "DCH-09" + "3.1.22.5(a)(iii)": [ + "PRI-01.6" ], - "13.4.21.C.01": [ - "DCH-09" + "3.1.22.4": [ + "PRI-01.11" ], - "13.4.22.C.01": [ - "DCH-09" + "3.1.22.4(a)": [ + "PRI-01.11" ], - "13.5.22.C.01": [ - "DCH-09.1" + "3.1.22.4(b)": [ + "PRI-01.11" ], - "13.5.27.C.01": [ - "DCH-09.1" + "3.1.22.4(b)(i)": [ + "PRI-01.11" ], - "13.5.27.C.02": [ - "DCH-09.1" + "3.1.22.4(b)(ii)": [ + "PRI-01.11" ], - "13.5.27.C.03": [ - "DCH-09.1" + "3.1.22.5": [ + "PRI-01.11" ], - "13.5.28.C.01": [ - "DCH-09.1" + "3.1.22.5(b)": [ + "PRI-01.11" ], - "13.5.28.C.02": [ - "DCH-09.1" + "4.1.47(1)": [ + "PRI-01.11" ], - "13.4.23.C.01": [ - "DCH-09.2" + "4.1.47(1)(a)": [ + "PRI-01.11" ], - "13.3.4.C.01": [ - "DCH-10", - "DCH-10.1" + "4.1.47(1)(b)": [ + "PRI-01.11" ], - "13.2.10.C.01": [ - "DCH-11" + "3.1.22.3(1)": [ + "PRI-02" ], - "13.2.11.C.01": [ - "DCH-11" + "3.1.22.3(1)(a)": [ + "PRI-02" ], - "13.3.6.C.01": [ - "DCH-12" + "3.1.22.3(1)(b)": [ + "PRI-02" ], - "13.3.6.C.02": [ - "DCH-12" + "3.1.22.3(1)(c)": [ + "PRI-02" ], - "13.3.6.C.03": [ - "DCH-12" + "3.1.22.3(1)(d)": [ + "PRI-02" ], - "13.3.10.C.01": [ - "DCH-12", - "DCH-13.2" + "3.1.22.3(1)(d)(i)": [ + "PRI-02" ], - "13.3.7.C.01": [ - "DCH-13.2" + "3.1.22.3(1)(d)(ii)": [ + "PRI-02" ], - "13.3.7.C.02": [ - "DCH-13.2" + "3.1.22.3(1)(e)": [ + "PRI-02" ], - "13.3.8.C.01": [ - "DCH-13.2" + "3.1.22.3(1)(e)(i)": [ + "PRI-02" ], - "13.3.8.C.02": [ - "DCH-13.2" + "3.1.22.3(1)(e)(ii)": [ + "PRI-02" ], - "13.3.9.C.01": [ - "DCH-13.2" + "3.1.22.3(1)(f)": [ + "PRI-02" ], - "13.3.9.C.02": [ - "DCH-13.2" + "3.1.22.3(1)(g)": [ + "PRI-02" ], - "20.1.6.C.01": [ - "DCH-14", - "PRI-07" + "4.1.45(1)": [ + "PRI-02" ], - "20.1.6.C.02": [ - "DCH-14", - "PRI-07" + "4.1.45(1)(a)": [ + "PRI-02" ], - "20.1.7.C.01": [ - "DCH-14", - "PRI-07" + "4.1.45(1)(b)": [ + "PRI-02" ], - "20.1.7.C.02": [ - "DCH-14", - "PRI-07" + "4.1.45(1)(c)": [ + "PRI-02" ], - "20.1.8.C.01": [ - "DCH-14", - "DCH-14.2", - "PRI-07" + "4.1.45(2)": [ + "PRI-02" ], - "20.1.9.C.01": [ - "DCH-14", - "PRI-07" + "3.1.22.2(1)": [ + "PRI-04.2" ], - "20.1.10.C.01": [ - "DCH-14", - "PRI-07" + "3.1.22.9": [ + "PRI-05" ], - "20.1.10.C.02": [ - "DCH-14", - "PRI-07" + "3.1.22.8": [ + "PRI-05.2" ], - "20.1.11.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.1(1)": [ + "PRI-05.4" ], - "20.1.12.C.01": [ - "DCH-14", - "PRI-07" + "3.1.22.1(1)(a)": [ + "PRI-05.4" ], - "20.1.13.C.01": [ - "DCH-14", - "PRI-07" + "3.1.22.1(1)(b)": [ + "PRI-05.4" ], - "20.2.3.C.01": [ - "DCH-14", - "PRI-07" + "3.1.22.10(1)": [ + "PRI-05.4" ], - "20.2.4.C.01": [ - "DCH-14", - "DCH-14.2", - "PRI-07" + "3.1.22.10(1)(a)": [ + "PRI-05.4" ], - "20.2.5.C.01": [ - "DCH-14", - "PRI-07" + "3.1.22.10(1)(b)": [ + "PRI-05.4" ], - "20.2.6.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(b)(i)": [ + "PRI-05.4" ], - "20.2.6.C.02": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(b)(ii)": [ + "PRI-05.4" ], - "20.2.6.C.03": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(c)": [ + "PRI-05.4" ], - "20.2.7.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(d)": [ + "PRI-05.4" ], - "20.2.8.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(e)": [ + "PRI-05.4" ], - "20.2.9.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(e)(i)": [ + "PRI-05.4" ], - "20.2.9.C.02": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(e)(ii)": [ + "PRI-05.4" ], - "20.2.9.C.03": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(e)(iii)": [ + "PRI-05.4" ], - "20.2.9.C.04": [ - "DCH-14", - "DCH-17", - "PRI-07" + "3.1.22.10(1)(e)(iv)": [ + "PRI-05.4" ], - "20.2.10.C.01": [ - "DCH-14", - "PRI-07" + "3.1.22.10(1)(f)": [ + "PRI-05.4" ], - "20.2.10.C.02": [ - "DCH-14", - "PRI-07" + "3.1.22.10(1)(f)(i)": [ + "PRI-05.4" ], - "20.2.11.C.01": [ - "DCH-14", - "PRI-07" + "3.1.22.10(1)(f)(ii)": [ + "PRI-05.4" ], - "20.2.11.C.02": [ - "DCH-14", - "PRI-07" + "3.1.22.6(1)": [ + "PRI-06" ], - "20.2.11.C.03": [ - "DCH-14", - "PRI-07" + "3.1.22.6(1)(a)": [ + "PRI-06" ], - "16.2.5.C.01": [ - "DCH-14.3", - "IAC-08" + "3.1.22.6(1)(b)": [ + "PRI-06" ], - "16.2.6.C.01": [ - "DCH-14.3" + "3.1.22.6(2)": [ + "PRI-06" ], - "14.1.12.C.01": [ - "END-06" + "3.1.22.7(1)": [ + "PRI-06" ], - "14.1.12.C.02": [ - "END-06" + "3.1.22.7(3)": [ + "PRI-06" ], - "14.1.12.C.03": [ - "END-06" + "3.1.22.7(3)(a)": [ + "PRI-06" ], - "18.4.13.C.01": [ - "END-07" + "4.2.59": [ + "PRI-06" ], - "15.2.21.C.01": [ - "END-08", - "IRO-15" + "3.1.22.7(3)(b)": [ + "PRI-06.2" ], - "15.2.23.C.01": [ - "END-08" + "3.1.22.7(2)": [ + "PRI-06.4" ], - "15.2.23.C.02": [ - "END-08" + "4.1.44(1)": [ + "PRI-06.4" ], - "15.2.23.C.03": [ - "END-08" + "4.1.44(2)": [ + "PRI-06.4" ], - "15.2.24.C.01": [ - "END-08" + "4.1.44(2)(b)": [ + "PRI-06.4" ], - "15.2.24.C.02": [ - "END-08" + "4.1.44(2)(c)": [ + "PRI-06.4" ], - "9.2.10.C.01": [ - "HRS-01", - "HRS-02", - "HRS-04.3" + "4.1.44(2)(c)(i)": [ + "PRI-06.4" ], - "9.2.11.C.01": [ - "HRS-01", - "HRS-02", - "HRS-04.3", - "IAC-08" + "4.1.44(2)(c)(ii)": [ + "PRI-06.4" ], - "9.2.11.C.02": [ - "HRS-01", - "HRS-02", - "HRS-04.3", - "IAC-08" + "4.1.44(2)(d)": [ + "PRI-06.4" ], - "14.3.5.C.01": [ - "HRS-01", - "HRS-05.1" + "4.2.63(1)": [ + "PRI-06.4" ], - "15.1.7.C.01": [ - "HRS-01", - "HRS-05.1", - "HRS-05.3", - "NET-13" + "4.2.63(1)(a)": [ + "PRI-06.4" ], - "9.2.10.C.02": [ - "HRS-02", - "HRS-04.3" + "4.2.63(1)(b)": [ + "PRI-06.4" ], - "3.3.4.C.01": [ - "HRS-03" + "4.2.63(1)(b)(i)": [ + "PRI-06.4" ], - "3.3.4.C.02": [ - "HRS-03" + "4.2.63(1)(b)(ii)": [ + "PRI-06.4" ], - "3.3.4.C.03": [ - "HRS-03" + "4.2.63(2)": [ + "PRI-06.4" ], - "3.3.4.C.04": [ - "HRS-03" + "4.2.63(3)": [ + "PRI-06.4" ], - "3.3.4.C.05": [ - "HRS-03" + "4.2.63(3)(a)": [ + "PRI-06.4" ], - "3.3.5.C.01": [ - "HRS-03" + "4.2.63(3)(b)": [ + "PRI-06.4" ], - "3.3.5.C.02": [ - "HRS-03" + "4.2.63(3)(c)": [ + "PRI-06.4" ], - "3.3.6.C.01": [ - "HRS-03" + "4.2.64(1)": [ + "PRI-06.4" ], - "3.3.6.C.02": [ - "HRS-03" + "4.2.64(1)(a)": [ + "PRI-06.4" ], - "3.3.6.C.03": [ - "HRS-03" + "4.2.64(1)(b)": [ + "PRI-06.4" ], - "3.3.6.C.04": [ - "HRS-03" + "4.2.64(1)(b)(i)": [ + "PRI-06.4" ], - "3.3.6.C.05": [ - "HRS-03" + "4.2.64(1)(b)(ii)": [ + "PRI-06.4" ], - "3.3.6.C.06": [ - "HRS-03" + "4.2.64(2)": [ + "PRI-06.4" ], - "3.3.7.C.01": [ - "HRS-03" + "4.2.64(3)": [ + "PRI-06.4" ], - "3.3.8.C.01": [ - "HRS-03" + "4.1.58(1)": [ + "PRI-06.7" ], - "3.3.8.C.02": [ - "HRS-03" + "4.1.58(1)(a)": [ + "PRI-06.7" ], - "3.3.8.C.03": [ - "HRS-03" + "4.1.58(1)(b)": [ + "PRI-06.7" ], - "3.3.8.C.04": [ - "HRS-03" + "4.1.58(1)(c)": [ + "PRI-06.7" ], - "3.3.8.C.05": [ - "HRS-03" + "4.1.58(1)(d)": [ + "PRI-06.7" ], - "3.3.9.C.01": [ - "HRS-03" + "4.1.58(1)(e)": [ + "PRI-06.7" ], - "3.3.10.C.01": [ - "HRS-03" + "4.1.58(1)(f)": [ + "PRI-06.7" ], - "3.3.10.C.02": [ - "HRS-03" + "3.1.22.11(1)": [ + "PRI-07" ], - "3.3.10.C.03": [ - "HRS-03" + "3.1.22.11(1)(a)": [ + "PRI-07" ], - "3.3.10.C.04": [ - "HRS-03" + "3.1.22.11(1)(b)": [ + "PRI-07" ], - "3.3.11.C.01": [ - "HRS-03" + "3.1.22.11(1)(c)": [ + "PRI-07" ], - "3.3.12.C.01": [ - "HRS-03" + "3.1.22.11(1)(d)": [ + "PRI-07" ], - "3.3.13.C.01": [ - "HRS-03" + "3.1.22.11(1)(e)": [ + "PRI-07" ], - "3.3.13.C.02": [ - "HRS-03" + "3.1.22.11(1)(e)(i)": [ + "PRI-07" ], - "3.3.14.C.01": [ - "HRS-03" + "3.1.22.11(1)(e)(ii)": [ + "PRI-07" ], - "3.3.14.C.02": [ - "HRS-03" + "3.1.22.11(1)(e)(iii)": [ + "PRI-07" ], - "3.3.14.C.03": [ - "HRS-03" + "3.1.22.11(1)(e)(iv)": [ + "PRI-07" ], - "3.3.15.C.01": [ - "HRS-03" + "3.1.22.11(1)(f)": [ + "PRI-07" ], - "9.1.7.C.01": [ - "HRS-04.2" + "3.1.22.11(1)(f)(i)": [ + "PRI-07" ], - "9.2.16.C.01": [ - "HRS-04.3", - "HRS-04.4" + "3.1.22.11(1)(f)(ii)": [ + "PRI-07" ], - "16.1.39.C.01": [ - "HRS-04.4" + "3.1.22.11(1)(g)": [ + "PRI-07" ], - "16.1.39.C.02": [ - "HRS-04.4" + "3.1.22.11(1)(h)": [ + "PRI-07" ], - "3.5.4.C.01": [ - "HRS-05", - "HRS-05.1" + "3.1.22.11(1)(h)(i)": [ + "PRI-07" ], - "3.5.4.C.02": [ - "HRS-05", - "HRS-05.1" + "3.1.22.11(1)(h)(ii)": [ + "PRI-07" ], - "3.5.4.C.03": [ - "HRS-05", - "HRS-05.1" + "3.1.22.11(1)(i)": [ + "PRI-07" ], - "5.5.7.C.01": [ - "HRS-05", - "HRS-05.1" + "3.1.22.7(5)": [ + "PRI-07.3" ], - "9.3.7.C.01": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2" + "4.1.46(1)": [ + "PRI-07.4" ], - "9.3.7.C.02": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2" + "4.1.46(2)": [ + "PRI-07.5" ], - "9.3.7.C.03": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2" + "4.1.46(3)": [ + "PRI-07.5" ], - "9.3.7.C.04": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2" + "4.1.46(2)(a)": [ + "PRI-17" ], - "9.3.8.C.01": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2" + "4.1.46(2)(b)": [ + "PRI-17" ], - "9.3.8.C.02": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2" + "4.1.46(3)(a)": [ + "PRI-17" ], - "9.3.8.C.03": [ - "HRS-05", - "HRS-05.1", - "HRS-05.2" + "4.1.46(3)(b)": [ + "PRI-17" + ] + }, + "apac-phl-dpa-2012": { + "III.11": [ + "CPL-01", + "PRI-01", + "PRI-01.11" ], - "9.1.8.C.01": [ - "HRS-05.1", - "HRS-06.1" + "V.20(f)": [ + "IRO-10.2" ], - "21.1.22.C.01": [ - "HRS-05.1", - "HRS-05.3", - "HRS-05.5" + "VI.21": [ + "PRI-01.1" ], - "21.1.22.C.02": [ - "HRS-05.1", - "HRS-05.3", - "HRS-05.5" + "VI.21(a)": [ + "PRI-01.1" ], - "9.3.4.C.01": [ - "HRS-05.3" + "VI.21(b)": [ + "PRI-01.1" ], - "9.3.5.C.01": [ - "HRS-05.3" + "V.20(a)": [ + "PRI-01.6" ], - "9.3.5.C.02": [ - "HRS-05.3" + "V.20(b)": [ + "PRI-01.6" ], - "9.3.9.C.01": [ - "HRS-05.3" + "V.20(c)": [ + "PRI-01.6" ], - "9.3.10.C.01": [ - "HRS-05.3" + "V.20(c)(1)": [ + "PRI-01.6" ], - "11.4.9.C.01": [ - "HRS-05.5" + "V.20(c)(2)": [ + "PRI-01.6" ], - "11.4.10.C.01": [ - "HRS-05.5" + "V.20(c)(3)": [ + "PRI-01.6" ], - "11.4.10.C.02": [ - "HRS-05.5" + "V.20(c)(4)": [ + "PRI-01.6" ], - "11.4.11.C.01": [ - "HRS-05.5" + "V.20(d)": [ + "PRI-01.6", + "PRI-07.1" ], - "11.4.12.C.01": [ - "HRS-05.5" + "V.20(e)": [ + "PRI-01.6" ], - "11.4.12.C.02": [ - "HRS-05.5" + "III.11(b)": [ + "PRI-01.11" ], - "11.5.13.C.01": [ - "HRS-05.5" + "III.11(d)": [ + "PRI-01.11" ], - "11.5.14.C.01": [ - "HRS-05.5" + "III.12": [ + "PRI-02.1" ], - "11.5.14.C.02": [ - "HRS-05.5" + "III.12(a)": [ + "PRI-03" ], - "11.5.15.C.01": [ - "HRS-05.5" + "IV.17": [ + "PRI-03.6" ], - "11.5.15.C.02": [ - "HRS-05.5" + "III.11(e)": [ + "PRI-05" ], - "11.5.16.C.01": [ - "HRS-05.5" + "III.11(f)": [ + "PRI-05" ], - "11.5.16.C.02": [ - "HRS-05.5" + "IV.19": [ + "PRI-05.1" ], - "11.5.16.C.03": [ - "HRS-05.5" + "III.11(c)": [ + "PRI-05.2", + "PRI-05.4" ], - "21.1.11.C.01": [ - "HRS-05.5", - "MDM-01" + "III.11(a)": [ + "PRI-05.4" ], - "21.1.11.C.02": [ - "HRS-05.5", - "MDM-01" + "III.12(b)": [ + "PRI-05.4" ], - "16.1.31.C.01": [ - "IAC-01" + "III.12(c)": [ + "PRI-05.4" ], - "16.1.32.C.01": [ - "IAC-02" + "III.12(d)": [ + "PRI-05.4" ], - "16.1.33.C.01": [ - "IAC-02.1", - "IAC-15.5" + "III.12(e)": [ + "PRI-05.4" ], - "16.1.33.C.02": [ - "IAC-02.1", - "IAC-15.5" + "III.12(f)": [ + "PRI-05.4" ], - "16.1.34.C.01": [ - "IAC-02.1", - "IAC-15.5" + "III.13": [ + "PRI-05.4" ], - "16.7.34.C.01": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "III.13(a)": [ + "PRI-05.4" ], - "16.7.34.C.02": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "III.13(b)": [ + "PRI-05.4" ], - "16.7.35.C.01": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "III.13(c)": [ + "PRI-05.4" ], - "16.7.36.C.01": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "III.13(d)": [ + "PRI-05.4" ], - "23.3.19.C.01": [ - "IAC-06" + "III.13(e)": [ + "PRI-05.4" ], - "23.3.19.C.02": [ - "IAC-06" + "III.13(f)": [ + "PRI-05.4" ], - "23.3.20.C.01": [ - "IAC-07" + "IV.16": [ + "PRI-06" ], - "16.2.4.C.01": [ - "IAC-08", - "IAC-21" + "IV.16(a)": [ + "PRI-06" ], - "14.3.13.C.01": [ - "IAC-10", - "IAC-10.11" + "IV.16(b)": [ + "PRI-06" ], - "14.3.13.C.02": [ - "IAC-10", - "IAC-10.11" + "IV.16(b)(1)": [ + "PRI-06" ], - "14.3.13.C.03": [ - "IAC-10", - "IAC-10.11" + "IV.16(b)(2)": [ + "PRI-06" ], - "16.1.40.C.01": [ - "IAC-10" + "IV.16(b)(3)": [ + "PRI-06" ], - "16.1.40.C.02": [ - "IAC-10" + "IV.16(b)(4)": [ + "PRI-06" ], - "16.1.41.C.01": [ - "IAC-10", - "IAC-10.4" + "IV.16(b)(5)": [ + "PRI-06" ], - "16.1.41.C.02": [ - "IAC-10", - "IAC-10.4" + "IV.16(b)(6)": [ + "PRI-06" ], - "16.1.41.C.03": [ - "IAC-10", - "IAC-10.4" + "IV.16(b)(7)": [ + "PRI-06" ], - "16.1.41.C.04": [ - "IAC-10", - "IAC-10.4" + "IV.16(b)(8)": [ + "PRI-06" ], - "16.1.42.C.01": [ - "IAC-10", - "IAC-10.1" + "IV.16(c)": [ + "PRI-06" ], - "16.1.35.C.01": [ - "IAC-10.1" + "IV.16(c)(1)": [ + "PRI-06" ], - "16.1.35.C.02": [ - "IAC-10.1" + "IV.16(c)(2)": [ + "PRI-06" ], - "16.1.43.C.01": [ - "IAC-10.1" + "IV.16(c)(3)": [ + "PRI-06" ], - "16.1.36.C.01": [ - "IAC-10.5", - "IAC-10.6" + "IV.16(c)(4)": [ + "PRI-06" ], - "16.1.37.C.01": [ - "IAC-10.5" + "IV.16(c)(5)": [ + "PRI-06" ], - "16.1.38.C.01": [ - "IAC-10.5" + "IV.16(c)(6)": [ + "PRI-06" ], - "17.10.12.C.01": [ - "IAC-12.1" + "IV.16(c)(7)": [ + "PRI-06" ], - "17.10.12.C.02": [ - "IAC-12.1" + "IV.16(c)(8)": [ + "PRI-06" ], - "17.10.12.C.03": [ - "IAC-12.1" + "IV.16(d)": [ + "PRI-06" ], - "17.10.12.C.04": [ - "IAC-12.1" + "IV.16(e)": [ + "PRI-06" ], - "16.3.5.C.01": [ - "IAC-16" + "IV.16(f)": [ + "PRI-06" ], - "16.3.5.C.02": [ - "IAC-16" + "IV.18": [ + "PRI-06.6" ], - "16.3.6.C.01": [ - "IAC-16" + "III.14": [ + "PRI-07.1" + ] + }, + "apac-sgp-pdpa-2012": { + "3.12(a)": [ + "GOV-02" ], - "16.3.6.C.02": [ - "IAC-16" + "3.12(c)": [ + "GOV-02", + "SAT-02" ], - "16.3.7.C.01": [ - "IAC-16" + "3.11(2)": [ + "CPL-01" ], - "16.4.30.C.01": [ - "IAC-16" + "3.12(d)": [ + "CPL-05" ], - "16.4.30.C.02": [ - "IAC-16" + "3.12(d)(i)": [ + "CPL-05" ], - "16.4.30.C.03": [ - "IAC-16" + "3.12(d)(ii)": [ + "CPL-05" ], - "16.4.31.C.01": [ - "IAC-16", - "IAC-21" + "5.21(4)": [ + "CPL-05.1" ], - "16.4.31.C.02": [ - "IAC-16", - "IAC-21" + "4.1.13": [ + "DCH-02", + "PRI-03", + "PRI-05.4", + "PRI-05.5" ], - "16.4.32.C.01": [ - "IAC-16" + "5.21(6)(b)": [ + "DCH-02", + "PRI-06.4" ], - "16.4.32.C.02": [ - "IAC-16" + "5.22(7)": [ + "DCH-02" ], - "16.4.33.C.01": [ - "IAC-16" + "5.22(2)(a)": [ + "DCH-22.1", + "PRI-06.1" ], - "16.4.34.C.01": [ - "IAC-16", - "IAC-16.1" + "6A.26C(2)": [ + "IRO-02", + "IRO-04" ], - "16.4.35.C.01": [ - "IAC-16", - "IAC-17" + "6A.26C(4)": [ + "IRO-04", + "IRO-10.2" ], - "16.4.35.C.02": [ - "IAC-16", - "IAC-17" + "6A.26D(1)": [ + "IRO-10" ], - "16.4.35.C.03": [ - "IAC-16", - "IAC-17" + "6A.26D(2)": [ + "IRO-10" ], - "16.4.36.C.01": [ - "IAC-16" + "6A.26D(3)": [ + "IRO-10" ], - "16.4.37.C.01": [ - "IAC-16", - "IAC-18" + "6A.26D(4)": [ + "IRO-10" ], - "23.3.18.C.01": [ - "IAC-16.2" + "6A.26D(5)(a)": [ + "IRO-10" ], - "16.1.46.C.01": [ - "IAC-22" + "6A.26D(5)(b)": [ + "IRO-10" ], - "16.1.46.C.02": [ - "IAC-22" + "6A.26D(6)": [ + "IRO-10" ], - "16.1.45.C.01": [ - "IAC-24" + "6A.26D(6)(a)": [ + "IRO-10" ], - "16.1.45.C.02": [ - "IAC-24" + "6A.26D(6)(b)": [ + "IRO-10" ], - "16.1.44.C.01": [ - "IAC-25" + "6A.26D(9)": [ + "IRO-10" ], - "7.1.7.C.01": [ - "IRO-01" + "6A.26E": [ + "IRO-10" ], - "7.1.7.C.02": [ - "IRO-01" + "6A.26E(a)": [ + "IRO-10" ], - "7.1.7.C.03": [ - "IRO-01" + "6A.26E(b)": [ + "IRO-10" ], - "7.2.18.C.01": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-10", + "6A.26C(3)(a)": [ "IRO-10.2" ], - "5.7.4.C.01": [ - "IRO-02", - "PES-01" - ], - "7.2.17.C.01": [ - "IRO-02", - "IRO-03" + "6A.26C(3)(b)": [ + "IRO-10.2" ], - "7.2.17.C.02": [ - "IRO-02", - "IRO-03" + "3.11(3)": [ + "PRI-01.1" ], - "7.2.19.C.01": [ - "IRO-02" + "3.11(4)": [ + "PRI-01.1" ], - "7.3.9.C.01": [ - "IRO-02", - "IRO-04" + "6.26(1)": [ + "PRI-01.5" ], - "7.3.10.C.01": [ - "IRO-02", - "IRO-02.5", - "IRO-04", - "IRO-11.2" + "6.24": [ + "PRI-01.6" ], - "5.1.12.C.01": [ - "IRO-04" + "6.24(a)": [ + "PRI-01.6" ], - "5.1.12.C.02": [ - "IRO-04" + "6.24(b)": [ + "PRI-01.6" ], - "5.6.3.C.01": [ - "IRO-04" + "3.11(1)": [ + "PRI-01.11" ], - "5.6.3.C.02": [ - "IRO-04" + "4.1.14(2)(a)": [ + "PRI-01.11" ], - "7.3.5.C.01": [ - "IRO-04" + "4.1.14(2)(b)": [ + "PRI-01.11" ], - "16.1.47.C.01": [ - "IRO-04" + "4.1.15A(4)(c)": [ + "PRI-01.11" ], - "7.3.11.C.01": [ - "IRO-08", - "IRO-11.2" + "4.1.15A(5)(c)": [ + "PRI-01.11" ], - "7.3.6.C.01": [ - "IRO-09" + "9.3.46(2)(a)": [ + "PRI-01.11" ], - "7.3.6.C.02": [ - "IRO-09" + "9.3.46(2)(b)": [ + "PRI-01.11" ], - "7.2.20.C.01": [ - "IRO-10", - "IRO-10.2" + "9.3.47(2)": [ + "PRI-01.11" ], - "7.2.21.C.01": [ - "IRO-10", - "IRO-10.2" + "3.11(5)": [ + "PRI-02" ], - "7.2.23.C.01": [ - "IRO-10", - "IRO-10.2", - "TPM-05.1" + "3.11(5A)": [ + "PRI-02" ], - "7.3.8.C.03": [ - "IRO-10.2", - "IRO-12" + "4.1.14(1)(a)": [ + "PRI-02" ], - "7.2.22.C.01": [ - "IRO-10.4", - "TPM-05.1" + "4.1.15A(4)(b)": [ + "PRI-02" ], - "7.3.12.C.01": [ - "IRO-11", - "IRO-11.2" + "4.1.15A(4)(b)(i)": [ + "PRI-02" ], - "7.3.7.C.01": [ - "IRO-12" + "4.1.15A(4)(b)(ii)": [ + "PRI-02" ], - "7.3.7.C.02": [ - "IRO-12" + "4.1.15A(4)(b)(iii)": [ + "PRI-02" ], - "7.3.7.C.03": [ - "IRO-12" + "4.2.20(1)(a)": [ + "PRI-02" ], - "7.3.7.C.04": [ - "IRO-12" + "4.2.20(1)(b)": [ + "PRI-02" ], - "7.3.7.C.05": [ - "IRO-12" + "4.2.20(1)(c)": [ + "PRI-02" ], - "7.3.7.C.06": [ - "IRO-12" + "4.2.20(2)": [ + "PRI-02" ], - "7.3.8.C.01": [ - "IRO-12", - "IRO-12.4" + "4.1.14(1)(b)": [ + "PRI-03" ], - "7.3.8.C.02": [ - "IRO-12", - "IRO-12.4" + "4.1.14(3)": [ + "PRI-03" ], - "2.1.10.C.01": [ - "IRO-14" + "4.1.14(4)": [ + "PRI-03" ], - "2.2.5.C.01": [ - "IAO-01", - "IAO-07" + "4.1.15(1)": [ + "PRI-03" ], - "4.4.4.C.01": [ - "IAO-01" + "4.1.15(1)(a)": [ + "PRI-03" ], - "4.4.5.C.01": [ - "IAO-01" + "4.1.15(1)(b)": [ + "PRI-03" ], - "4.4.5.C.02": [ - "IAO-01" + "4.1.15(2)": [ + "PRI-03" ], - "4.4.5.C.03": [ - "IAO-01" + "4.1.15(3)": [ + "PRI-03" ], - "4.4.5.C.04": [ - "IAO-01" + "4.1.15(6)": [ + "PRI-03" ], - "4.4.6.C.01": [ - "IAO-01" + "4.1.15(6)(a)(i)": [ + "PRI-03" ], - "4.4.7.C.01": [ - "IAO-01" + "4.1.15(6)(a)(ii)": [ + "PRI-03" ], - "4.4.7.C.02": [ - "IAO-01" + "4.1.15(6)(b)": [ + "PRI-03" ], - "4.4.8.C.01": [ - "IAO-01" + "4.1.15(6)(c)": [ + "PRI-03" ], - "4.4.8.C.02": [ - "IAO-01" + "4.1.15(7)": [ + "PRI-03" ], - "4.4.8.C.03": [ - "IAO-01" + "4.1.15(9)(a)": [ + "PRI-03" ], - "4.4.8.C.04": [ - "IAO-01" + "4.1.15(9)(b)": [ + "PRI-03" ], - "4.4.11.C.01": [ - "IAO-01" + "9.3.46(1)": [ + "PRI-03" ], - "4.4.12.C.01": [ - "IAO-01" + "4.1.16(1)": [ + "PRI-03.4" ], - "4.4.12.C.02": [ - "IAO-01" + "9.3.47(1)": [ + "PRI-03.4" ], - "4.4.12.C.03": [ - "IAO-01" + "4.2.19(a)": [ + "PRI-03.9" ], - "4.4.12.C.04": [ - "IAO-01" + "9.3.47(3)": [ + "PRI-03.9" ], - "4.4.12.C.05": [ - "IAO-01" + "4.1.16(4)": [ + "PRI-03.10" ], - "5.8.61.C.01": [ - "IAO-01.1" + "9.3.46(2)": [ + "PRI-03.12" ], - "5.8.61.C.02": [ - "IAO-01.1" + "4.1.17(1)(a)": [ + "PRI-04.1" ], - "5.8.61.C.03": [ - "IAO-01.1" + "5.22A(1)": [ + "PRI-05" ], - "4.2.10.C.01": [ - "IAO-02" + "5.22A(2)": [ + "PRI-05" ], - "4.3.20.C.01": [ - "IAO-02", - "IAO-02.2", - "IAO-02.3" + "6.23": [ + "PRI-05.2" ], - "4.3.20.C.02": [ - "IAO-02", - "IAO-02.2", - "IAO-02.3" + "6.23(a)": [ + "PRI-05.2" ], - "4.3.20.C.03": [ - "IAO-02", - "IAO-02.2", - "IAO-02.3" + "6.23(b)": [ + "PRI-05.2" ], - "5.8.62.C.01": [ - "IAO-02.3" + "6.25": [ + "PRI-05.2" ], - "4.2.11.C.01": [ - "IAO-02.4", - "IAO-07" + "6.25(a)": [ + "PRI-05.2" ], - "4.2.12.C.01": [ - "IAO-02.4", - "IAO-05" + "6.25(b)": [ + "PRI-05.2" ], - "4.3.21.C.01": [ - "IAO-02.4" + "4.1.13(a)": [ + "PRI-05.4" ], - "4.5.17.C.01": [ - "IAO-02.4" + "4.1.13(b)": [ + "PRI-05.4" ], - "3.4.12.C.01": [ - "IAO-03", - "OPS-01.1" + "4.1.15(3)(a)": [ + "PRI-05.4" ], - "3.4.12.C.02": [ - "IAO-03", - "OPS-01.1" + "4.1.15(3)(b)": [ + "PRI-05.4" ], - "4.3.17.C.01": [ - "IAO-03" + "4.1.15(3)(c)": [ + "PRI-05.4" ], - "4.3.18.C.01": [ - "IAO-03" + "4.1.17(1)(b)": [ + "PRI-05.4" ], - "4.3.18.C.02": [ - "IAO-03" + "4.1.17(2)(a)": [ + "PRI-05.4" ], - "4.3.18.C.03": [ - "IAO-03" + "4.1.16(3)": [ + "PRI-06" ], - "4.3.18.C.04": [ - "IAO-03" + "5.21(1)": [ + "PRI-06" ], - "4.3.18.C.05": [ - "IAO-03" + "5.21(1)(a)": [ + "PRI-06" ], - "5.1.8.C.01": [ - "IAO-03" + "5.21(1)(b)": [ + "PRI-06" ], - "5.1.9.C.01": [ - "IAO-03", - "RSK-01" + "5.21(2)": [ + "PRI-06" ], - "5.1.10.C.01": [ - "IAO-03" + "5.21(5)": [ + "PRI-06" ], - "5.4.5.C.01": [ - "IAO-03" + "5.22(1)": [ + "PRI-06.1" ], - "5.4.5.C.02": [ - "IAO-03" + "5.22(4)": [ + "PRI-06.1" ], - "5.4.5.C.03": [ - "IAO-03" + "3.12(b)": [ + "PRI-06.4" ], - "2.2.5.C.02": [ - "IAO-03.2" + "4.1.16(2)": [ + "PRI-06.4" ], - "6.2.5.C.01": [ - "IAO-04", - "VPM-06" + "5.21(6)": [ + "PRI-06.4" ], - "6.2.6.C.01": [ - "IAO-04", - "VPM-02", - "VPM-04" + "5.21(7)": [ + "PRI-06.4" ], - "4.5.18.C.01": [ - "IAO-07" + "5.21(7)(b)": [ + "PRI-06.4" ], - "4.5.18.C.02": [ - "IAO-07" + "4.1.17(1)(c)": [ + "PRI-07" ], - "4.5.18.C.03": [ - "IAO-07" + "5.22(2)(b)": [ + "PRI-07" ], - "12.5.3.C.01": [ - "MNT-01", - "MNT-02" + "5.22(3)": [ + "PRI-07" ], - "12.5.3.C.02": [ - "MNT-01", - "MNT-02" + "5.22(5)": [ + "PRI-18" ], - "12.5.6.C.01": [ - "MNT-01", - "MNT-02" + "5.22(6)": [ + "PRI-18" ], - "12.5.6.C.02": [ - "MNT-01", - "MNT-02" + "4.1.15A(5)(b)(i)": [ + "RSK-06" ], - "12.5.4.C.01": [ - "MNT-06.1" + "4.1.15A(5)(b)(ii)": [ + "RSK-06" ], - "12.5.4.C.02": [ - "MNT-06.1" + "4.1.15A(5)(b)(iii)": [ + "RSK-06" ], - "12.5.4.C.03": [ - "MNT-06.1" + "4.1.15A(4)(a)": [ + "RSK-10" ], - "12.5.4.C.04": [ - "MNT-06.1" + "4.1.15A(5)(a)": [ + "RSK-10" + ] + }, + "apac-sgp-cyber-hygiene-practice-2019": { + "4.3(a)": [ + "GOV-02", + "CFG-02", + "IAO-03" ], - "12.5.5.C.01": [ - "MNT-08", - "MNT-09" + "4.3(b)": [ + "CFG-02", + "CFG-06" ], - "21.1.10.C.01": [ - "MDM-01" + "4.5": [ + "END-04" ], - "21.1.10.C.02": [ - "MDM-01" + "4.1": [ + "IAC-01", + "IAC-15", + "IAC-16" ], - "21.1.10.C.03": [ - "MDM-01" + "4.6": [ + "IAC-06" ], - "21.1.14.C.01": [ - "MDM-01" + "4.6(b)": [ + "IAC-06", + "IAC-06.2" ], - "21.1.14.C.02": [ - "MDM-01" + "4.6(a)": [ + "IAC-06.1" ], - "21.1.15.C.01": [ - "MDM-01" + "4.4": [ + "NET-01", + "NET-03", + "NET-04.1" ], - "21.1.17.C.01": [ - "MDM-01" + "4.2(b)": [ + "RSK-06.2" ], - "21.1.17.C.02": [ - "MDM-01" + "4.3(c)": [ + "RSK-06.2" ], - "21.1.17.C.03": [ - "MDM-01" + "4.2(a)": [ + "VPM-02", + "VPM-05" + ] + }, + "apac-sgp-mas-trm-2021": { + "3.1.4": [ + "GOV-01", + "RSK-01" ], - "21.1.18.C.01": [ - "MDM-01" + "3.1.1": [ + "GOV-01.1" ], - "21.1.18.C.02": [ - "MDM-01" + "3.1.2": [ + "GOV-01.1" ], - "21.1.19.C.01": [ - "MDM-01" + "3.1.5": [ + "GOV-01.1", + "RSK-01.5" ], - "21.1.19.C.02": [ - "MDM-01" + "3.1.7": [ + "GOV-01.1" ], - "21.1.13.C.01": [ - "MDM-03" + "3.1.7(a)": [ + "GOV-01.1", + "RSK-01" ], - "21.1.13.C.02": [ - "MDM-03" + "3.1.7(b)": [ + "GOV-01.1" ], - "21.1.13.C.03": [ - "MDM-03" + "3.1.7(c)": [ + "GOV-01.1", + "GOV-04.1", + "GOV-04.2" ], - "21.1.13.C.04": [ - "MDM-03" + "3.1.7(d)": [ + "GOV-01.1", + "RSK-01.3", + "RSK-01.5" ], - "21.1.13.C.05": [ - "MDM-03" + "3.1.7(e)": [ + "GOV-01.1" ], - "21.1.20.C.01": [ - "MDM-05" + "3.1.7(f)": [ + "GOV-01.1" ], - "21.1.20.C.02": [ - "MDM-05" + "3.1.7(g)": [ + "GOV-01.1" ], - "21.1.20.C.03": [ - "MDM-05" + "3.1.3": [ + "GOV-01.2", + "GOV-04" ], - "10.8.34.C.01": [ - "NET-01" + "3.1.8(e)": [ + "GOV-01.2", + "GOV-04.1" ], - "10.8.34.C.02": [ - "NET-01" + "3.1.8(c)": [ + "GOV-02", + "GOV-04.1" ], - "10.8.35.C.01": [ - "NET-01" + "3.2.1": [ + "GOV-02", + "GOV-03" ], - "10.8.36.C.01": [ - "NET-01" + "3.3.1(d)": [ + "GOV-02" ], - "10.8.37.C.01": [ - "NET-01" + "5.3.1": [ + "GOV-02", + "TPM-02", + "TPM-04.1" ], - "10.8.38.C.01": [ - "NET-01" + "6.1.3": [ + "GOV-02", + "CFG-04", + "CFG-04.1" ], - "18.1.9.C.01": [ - "NET-01" + "6.4.4": [ + "GOV-02", + "CLD-04", + "CFG-02" ], - "18.1.9.C.03": [ - "NET-01" + "11.1.1": [ + "GOV-02", + "DCH-01", + "NET-17" ], - "18.1.9.C.04": [ - "NET-01" + "3.2.2": [ + "GOV-02.1", + "AST-02.4" ], - "18.1.9.C.05": [ - "NET-01" + "7.3.3": [ + "GOV-02.1", + "TDA-17" ], - "18.5.7.C.01": [ - "NET-01" + "3.1.8": [ + "GOV-04", + "GOV-04.1" ], - "18.5.7.C.02": [ - "NET-01" + "3.1.8(a)": [ + "GOV-04.1" ], - "18.5.8.C.01": [ - "NET-01" + "3.1.8(b)": [ + "GOV-04.1" ], - "18.5.8.C.02": [ - "NET-01" + "3.1.8(d)": [ + "GOV-04.1" ], - "18.5.8.C.03": [ - "NET-01" + "4.5.3": [ + "GOV-05" ], - "18.5.8.C.04": [ - "NET-01" + "3.1.6": [ + "GOV-14", + "SAT-01" ], - "18.5.9.C.01": [ - "NET-01" + "4.1.2": [ + "GOV-14", + "GOV-15" ], - "18.5.9.C.02": [ - "NET-01" + "5.8.1": [ + "GOV-18", + "PRM-07" ], - "18.5.9.C.03": [ - "NET-01" + "5.8.2": [ + "GOV-18" ], - "18.5.10.C.01": [ - "NET-01" + "3.3.1": [ + "AST-01" ], - "18.5.10.C.02": [ - "NET-01" + "3.3.1(a)": [ + "AST-01.1", + "AST-01.4", + "AST-02" ], - "18.5.11.C.01": [ - "NET-01" + "8.1.2": [ + "AST-01.1", + "AST-04", + "BCD-11.7" ], - "2.3.26.C.01": [ - "NET-01.1" + "3.3.1(c)": [ + "AST-01.2" ], - "2.3.26.C.02": [ - "NET-01.1" + "6.5.1": [ + "AST-01.4", + "OPS-07" ], - "18.3.18.C.01": [ - "NET-02.1" + "3.3.2": [ + "AST-02" ], - "18.3.19.C.01": [ - "NET-02.1" + "11.5.1": [ + "AST-02", + "EMB-01" ], - "18.2.6.C.01": [ - "NET-02.2", - "NET-15" + "11.2.4": [ + "AST-02.5" ], - "19.2.15.C.01": [ - "NET-02.3" + "11.2.5": [ + "AST-02.5" ], - "19.2.16.C.01": [ - "NET-02.3" + "11.5.4": [ + "AST-02.5" ], - "19.2.16.C.02": [ - "NET-02.3" + "11.1.7": [ + "AST-09", + "DCH-09" ], - "19.2.17.C.01": [ - "NET-02.3" + "11.3.7": [ + "AST-16" ], - "19.2.17.C.02": [ - "NET-02.3" + "8.1.1": [ + "BCD-01" ], - "19.2.18.C.01": [ - "NET-02.3" + "8.3.4": [ + "BCD-01.2", + "TPM-01" ], - "19.2.19.C.01": [ - "NET-02.3" + "8.2.1": [ + "BCD-01.4" ], - "19.2.19.C.02": [ - "NET-02.3" + "8.2.2": [ + "BCD-01.7" ], - "19.2.20.C.01": [ - "NET-02.3" + "8.2.3": [ + "BCD-01.7" ], - "19.1.10.C.01": [ - "NET-03" + "13.5.1": [ + "BCD-03.1" ], - "19.1.11.C.01": [ - "NET-03" + "13.5.2": [ + "BCD-03.1", + "BCD-04", + "IRO-06" ], - "19.1.11.C.02": [ - "NET-03" + "8.2.4": [ + "BCD-04" ], - "19.1.12.C.01": [ - "NET-03" + "8.3.1": [ + "BCD-04" ], - "19.1.13.C.01": [ - "NET-03" + "8.3.2": [ + "BCD-04" ], - "19.1.14.C.01": [ - "NET-03", - "NET-08.1" + "8.3.3": [ + "BCD-04" ], - "19.1.14.C.02": [ - "NET-03", - "NET-08.1" + "8.3.3(a)": [ + "BCD-04" ], - "19.1.15.C.01": [ - "NET-03" + "8.3.3(b)": [ + "BCD-04" ], - "19.1.16.C.01": [ - "NET-03" + "8.5.2": [ + "BCD-04.2" ], - "19.1.16.C.02": [ - "NET-03" + "8.5.2(a)": [ + "BCD-04.2" ], - "19.1.17.C.01": [ - "NET-03" + "8.5.2(b)": [ + "BCD-04.2" ], - "19.1.17.C.02": [ - "NET-03" + "8.5.4": [ + "BCD-04.2" ], - "19.1.18.C.01": [ - "NET-03" + "8.4.1": [ + "BCD-11" ], - "19.1.18.C.02": [ - "NET-03" + "8.4.2": [ + "BCD-11" ], - "19.1.19.C.01": [ - "NET-03" + "8.4.4": [ + "BCD-11.2", + "BCD-11.4" ], - "19.1.19.C.02": [ - "NET-03" + "11.4.3": [ + "BCD-11.3", + "BCD-11.9", + "CLD-05" ], - "19.1.19.C.03": [ - "NET-03" + "8.4.3": [ + "BCD-11.5" ], - "19.1.19.C.04": [ - "NET-03" + "8.5.2(c)": [ + "BCD-11.7" ], - "19.1.19.C.05": [ - "NET-03" + "6.4.8": [ + "CAP-01", + "CAP-02" ], - "19.1.20.C.01": [ - "NET-03" + "8.1.3": [ + "CAP-04" ], - "19.1.20.C.02": [ - "NET-03" + "8.1.4": [ + "CAP-05" ], - "19.1.20.C.03": [ - "NET-03" + "7.5.1": [ + "CHG-01" ], - "19.1.21.C.01": [ - "NET-03" + "7.5.2": [ + "CHG-02", + "CHG-02.1", + "CHG-03" ], - "19.1.22.C.01": [ - "NET-03" + "7.5.4": [ + "CHG-02" ], - "19.1.22.C.02": [ - "NET-03" + "7.5.3": [ + "CHG-02.2" ], - "19.1.22.C.03": [ - "NET-03" + "7.5.5": [ + "CHG-02.2" ], - "19.1.23.C.01": [ - "NET-03" + "7.5.7": [ + "CHG-02.2" ], - "19.3.8.C.01": [ - "NET-03" + "9.1.1": [ + "CHG-04.3", + "HRS-11" ], - "19.3.8.C.02": [ - "NET-03" + "7.6.2": [ + "CHG-04.5", + "MON-01.15", + "TDA-20" ], - "19.3.8.C.03": [ - "NET-03" + "7.5.6": [ + "CHG-07" ], - "19.3.8.C.04": [ - "NET-03" + "6.4.1": [ + "CLD-04" ], - "19.3.9.C.01": [ - "NET-03" + "15.1.4": [ + "CPL-01.6" ], - "19.3.9.C.02": [ - "NET-03" + "3.2.3": [ + "CPL-02" ], - "19.3.9.C.03": [ - "NET-03" + "15.1.1": [ + "CPL-02", + "CPL-02.1" ], - "19.4.4.C.01": [ - "NET-03" + "15.1.2": [ + "CPL-02.1" ], - "19.4.5.C.01": [ - "NET-03" + "15.1.3": [ + "CPL-02.2" ], - "19.4.5.C.02": [ - "NET-03" + "4.5.1": [ + "CPL-03", + "CPL-03.2", + "IAO-01", + "IAO-01.1", + "IAO-02" ], - "19.4.5.C.03": [ - "NET-03" + "9.1.6": [ + "CPL-03" ], - "19.4.6.C.01": [ - "NET-03" + "11.2.8": [ + "CPL-03", + "CPL-03.2" ], - "19.5.24.C.01": [ - "NET-03" + "7.2.1": [ + "CFG-01" ], - "19.5.24.C.02": [ - "NET-03" + "7.2.2": [ + "CFG-02", + "CFG-02.2" ], - "19.5.24.C.03": [ - "NET-03" + "11.1.5": [ + "CFG-02", + "END-02", + "HRS-05.3" ], - "19.5.24.C.04": [ - "NET-03" + "11.3.1": [ + "CFG-02" ], - "19.5.24.C.05": [ - "NET-03" + "11.3.2": [ + "CFG-02.2", + "CFG-02.7" ], - "19.5.24.C.06": [ - "NET-03" + "11.2.6": [ + "CFG-03" ], - "19.5.24.C.07": [ - "NET-03" + "11.3.6": [ + "CFG-03.3" ], - "19.5.24.C.08": [ - "NET-03" + "6.4.7": [ + "MON-01", + "MON-01.2" ], - "19.5.25.C.01": [ - "NET-03" + "12.2.1": [ + "MON-01" ], - "19.5.26.C.01": [ - "NET-03" + "7.7.4": [ + "MON-01.2" ], - "19.5.26.C.02": [ - "NET-03" + "12.2.2": [ + "MON-01.2", + "MON-08" ], - "19.5.26.C.03": [ - "NET-03" + "12.2.6": [ + "MON-01.8" ], - "19.5.26.C.04": [ - "NET-03" + "12.2.5": [ + "MON-02.1" ], - "19.5.26.C.05": [ - "NET-03" + "11.3.5": [ + "MON-11.3", + "IRO-03" ], - "19.5.26.C.06": [ - "NET-03" + "11.5.5": [ + "MON-16", + "NET-03.6" ], - "19.5.26.C.07": [ - "NET-03" + "12.2.3": [ + "MON-16", + "THR-11" ], - "19.5.26.C.08": [ - "NET-03" + "12.2.4": [ + "MON-16" ], - "19.5.26.C.09": [ - "NET-03" + "6.4.5": [ + "CRY-01", + "CRY-09" ], - "19.5.26.C.10": [ - "NET-03" + "10.1.1": [ + "CRY-01" ], - "19.5.26.C.11": [ - "NET-03" + "10.1.3": [ + "CRY-01" ], - "19.5.26.C.12": [ - "NET-03" + "10.1.4": [ + "CRY-01" ], - "19.5.27.C.01": [ - "NET-03" + "10.1.2": [ + "CRY-01.5" ], - "19.5.27.C.02": [ - "NET-03" + "10.1.5": [ + "CRY-01.5" ], - "19.5.27.C.03": [ - "NET-03" + "11.1.3": [ + "CRY-05", + "END-02" ], - "19.5.27.C.04": [ - "NET-03" + "10.2.1": [ + "CRY-09" ], - "19.5.27.C.05": [ - "NET-03" + "10.2.2": [ + "CRY-09" ], - "19.5.27.C.06": [ - "NET-03" + "10.2.3": [ + "CRY-09" ], - "19.5.28.C.01": [ - "NET-03" + "10.2.4": [ + "CRY-09" ], - "19.5.28.C.02": [ - "NET-03" + "10.2.5": [ + "CRY-09" ], - "19.5.28.C.03": [ - "NET-03" + "10.2.6": [ + "CRY-09" ], - "19.5.28.C.04": [ - "NET-03" + "10.2.8": [ + "CRY-09" ], - "19.5.28.C.05": [ - "NET-03" + "10.2.10": [ + "CRY-09" ], - "19.5.28.C.06": [ - "NET-03" + "10.2.7": [ + "CRY-09.3" ], - "19.5.28.C.07": [ - "NET-03" + "10.2.9": [ + "CRY-09.3" ], - "19.5.29.C.01": [ - "NET-03" + "11.1.2": [ + "DCH-01" ], - "14.1.11.C.01": [ - "NET-03.8" + "11.1.1(a)": [ + "DCH-01.2" ], - "18.1.13.C.01": [ - "NET-04", - "NET-04.1" + "11.1.1(b)": [ + "DCH-01.2" ], - "18.1.13.C.02": [ - "NET-04", - "NET-04.1" + "11.1.1(c)": [ + "DCH-01.2" ], - "18.1.14.C.01": [ - "NET-04", - "NET-04.1" + "11.1.6": [ + "DCH-01.2", + "DCH-01.4" ], - "14.1.13.C.01": [ - "NET-05.1" + "3.3.1(b)": [ + "DCH-02" ], - "14.1.13.C.02": [ - "NET-05.1" + "11.1.4": [ + "DCH-13.2", + "END-02" ], - "14.1.13.C.03": [ - "NET-05.1" + "11.5.2": [ + "EMB-01" ], - "22.3.9.C.01": [ - "NET-06.2" + "11.5.3": [ + "EMB-01" ], - "22.3.9.C.02": [ - "NET-06.2" + "11.3.3": [ + "END-04" ], - "22.3.9.C.03": [ - "NET-06.2" + "11.3.4": [ + "END-04.1" ], - "22.3.9.C.04": [ - "NET-06.2" + "11.4.2": [ + "END-15" ], - "22.3.10.C.01": [ - "NET-06.2" + "3.5.1": [ + "HRS-01", + "HRS-02", + "HRS-03", + "HRS-03.2" ], - "22.3.11.C.01": [ - "NET-06.2" + "6.1.5": [ + "HRS-03.2", + "SAT-03.8" ], - "22.3.11.C.02": [ - "NET-06.2" + "3.5.2": [ + "HRS-04", + "HRS-04.1" ], - "21.4.12.C.01": [ - "NET-08.2" + "6.3.2": [ + "HRS-11" ], - "21.4.12.C.02": [ - "NET-08.2" + "7.6.1": [ + "HRS-11" ], - "21.4.12.C.03": [ - "NET-08.2" + "9.1.8": [ + "IAC-01", + "IAC-15" ], - "15.2.20.C.01": [ - "NET-10", - "NET-10.3" + "9.2.2": [ + "IAC-01", + "IAC-15.1" ], - "15.2.20.C.02": [ - "NET-10", - "NET-10.3" + "9.1.3": [ + "IAC-01.1" ], - "15.2.20.C.03": [ - "NET-10", - "NET-10.3" + "9.1.5": [ + "IAC-06" ], - "15.2.20.C.04": [ - "NET-10", - "NET-10.3" + "9.1.2": [ + "IAC-07" ], - "15.2.20.C.05": [ - "NET-10", - "NET-10.3" + "9.1.7": [ + "IAC-08", + "IAC-21" ], - "15.2.22.C.01": [ - "NET-10.1" + "9.1.4": [ + "IAC-10.1" ], - "15.1.8.C.01": [ - "NET-13" + "9.2.1": [ + "IAC-16" ], - "15.1.8.C.02": [ - "NET-13" + "7.7.1": [ + "IRO-01" ], - "15.1.9.C.01": [ - "NET-13" + "7.7.2": [ + "IRO-01", + "IRO-02" ], - "15.1.10.C.01": [ - "NET-13" + "7.7.3": [ + "IRO-02" ], - "15.1.10.C.02": [ - "NET-13" + "7.7.3(a)": [ + "IRO-02" ], - "15.1.10.C.03": [ - "NET-13" + "7.7.3(b)": [ + "IRO-02" ], - "15.1.11.C.01": [ - "NET-13" + "7.7.3(c)": [ + "IRO-02" ], - "15.1.11.C.02": [ - "NET-13" + "12.3.1": [ + "IRO-04" ], - "15.1.11.C.03": [ - "NET-13" + "7.8.3": [ + "IRO-04.3" ], - "15.1.12.C.01": [ - "NET-13" + "12.3.3": [ + "IRO-04.3" ], - "15.1.13.C.01": [ - "NET-13" + "13.3.1": [ + "IRO-06" ], - "15.1.14.C.01": [ - "NET-13" + "13.3.2": [ + "IRO-06" ], - "15.1.15.C.01": [ - "NET-13" + "7.7.5": [ + "IRO-07", + "IRO-10" ], - "15.1.16.C.01": [ - "NET-13" + "7.7.6": [ + "IRO-07" ], - "15.1.17.C.01": [ - "NET-13" + "7.7.7": [ + "IRO-10" ], - "15.1.18.C.01": [ - "NET-13" + "7.8.1": [ + "IRO-13" ], - "15.1.19.C.01": [ - "NET-13" + "7.8.2": [ + "IRO-13" ], - "15.1.19.C.02": [ - "NET-13" + "12.3.2": [ + "IRO-13" ], - "15.1.20.C.01": [ - "NET-13" + "5.6.2": [ + "IAO-01", + "IAO-01.1", + "IAO-02" ], - "15.2.25.C.01": [ - "NET-13" + "5.7.1": [ + "IAO-01" ], - "15.2.25.C.02": [ - "NET-13" + "6.1.6": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.2", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4" ], - "15.2.26.C.01": [ - "NET-13" + "6.1.7": [ + "IAO-01", + "TDA-09" ], - "15.2.27.C.01": [ - "NET-13" + "6.4.6": [ + "IAO-01", + "IAO-01.1", + "IAO-02.2" ], - "15.2.28.C.01": [ - "NET-13" + "6.5.3": [ + "IAO-01" ], - "15.2.29.C.01": [ - "NET-13" + "5.3.3": [ + "IAO-02.2" ], - "15.2.30.C.01": [ - "NET-13" + "5.6.3": [ + "IAO-02.2" ], - "15.2.30.C.02": [ - "NET-13" + "5.7.5": [ + "IAO-04", + "TDA-09" ], - "15.2.30.C.03": [ - "NET-13" + "5.7.6": [ + "IAO-06", + "IAO-07" ], - "15.2.31.C.01": [ - "NET-13" + "11.2.1": [ + "NET-01", + "NET-03" ], - "15.2.31.C.02": [ - "NET-13" + "11.2.2": [ + "NET-06" ], - "15.2.32.C.01": [ - "NET-13" + "11.2.3": [ + "NET-08" ], - "15.2.32.C.02": [ - "NET-13" + "9.3.1": [ + "NET-14" ], - "15.2.32.C.03": [ - "NET-13" + "9.3.2": [ + "NET-14" ], - "15.2.33.C.01": [ - "NET-13" + "11.2.7": [ + "NET-18" ], - "15.2.33.C.02": [ - "NET-13" + "8.5.5": [ + "PES-01" ], - "15.2.33.C.03": [ - "NET-13" + "8.5.6": [ + "PES-01" ], - "15.2.33.C.04": [ - "NET-13" + "8.5.6(a)": [ + "PES-02" ], - "16.7.33.C.01": [ - "NET-13" + "8.5.6(e)": [ + "PES-03" ], - "16.5.10.C.01": [ - "NET-14" + "8.5.6(c)": [ + "PES-03.1" ], - "16.5.10.C.02": [ - "NET-14" + "8.5.6(d)": [ + "PES-03.4" ], - "16.5.11.C.01": [ - "NET-14", - "NET-14.4" + "8.5.6(b)": [ + "PES-06" ], - "16.5.11.C.02": [ - "NET-14", - "NET-14.4" + "8.5.3": [ + "PES-08", + "PES-08.1", + "PES-08.2" ], - "16.5.12.C.01": [ - "NET-14" + "8.5.6(f)": [ + "PES-10" ], - "17.5.7.C.01": [ - "NET-14" + "14.4.1": [ + "PRI-02" ], - "17.5.7.C.02": [ - "NET-14" + "5.2.1": [ + "PRM-01" ], - "17.5.8.C.01": [ - "NET-14" + "5.2.2": [ + "PRM-01" ], - "17.5.8.C.02": [ - "NET-14" + "5.1.4": [ + "PRM-02", + "PRM-03" ], - "17.5.8.C.03": [ - "NET-14" + "5.1.1": [ + "PRM-04" ], - "17.5.9.C.01": [ - "NET-14" + "5.1.3": [ + "PRM-04" ], - "17.5.10.C.01": [ - "NET-14" + "5.1.2": [ + "PRM-05", + "PRM-06", + "PRM-07" ], - "21.2.4.C.01": [ - "NET-14.5" + "5.4.2": [ + "PRM-05" ], - "21.2.4.C.02": [ - "NET-14.5" + "5.4.3": [ + "PRM-05", + "TDA-02" ], - "21.2.5.C.01": [ - "NET-14.5" + "5.5.1": [ + "PRM-05", + "PRM-06" ], - "21.2.6.C.01": [ - "NET-14.5" + "5.4.1": [ + "PRM-07" ], - "21.2.7.C.01": [ - "NET-14.5" + "5.4.4": [ + "PRM-07" ], - "21.2.7.C.02": [ - "NET-14.5" + "5.5.2": [ + "PRM-07", + "TDA-01.1", + "TDA-02" ], - "21.3.5.C.01": [ - "NET-14.5" + "4.1.1": [ + "RSK-01" ], - "21.3.6.C.01": [ - "NET-14.5" + "4.1.4": [ + "RSK-01" ], - "18.2.5.C.01": [ - "NET-15" + "4.1.4(d)": [ + "RSK-01", + "RSK-04.2", + "RSK-04.3" ], - "18.2.5.C.02": [ - "NET-15" + "4.1.5": [ + "RSK-01" ], - "18.2.7.C.01": [ - "NET-15" + "4.2.1": [ + "RSK-01.1", + "RSK-03", + "RSK-03.1", + "THR-03", + "THR-09" ], - "18.2.8.C.01": [ - "NET-15" + "4.4.2": [ + "RSK-01.3", + "RSK-01.4", + "RSK-06.3" ], - "18.2.26.C.01": [ - "NET-15" + "4.1.4(a)": [ + "RSK-03" ], - "18.2.27.C.01": [ - "NET-15" + "4.1.3": [ + "RSK-03.2", + "RSK-06.3" ], - "18.2.28.C.01": [ - "NET-15" + "4.1.4(b)": [ + "RSK-04" ], - "18.2.28.C.02": [ - "NET-15" + "4.3.1": [ + "RSK-04" ], - "18.2.29.C.01": [ - "NET-15" + "8.5.1": [ + "RSK-04", + "THR-10", + "VPM-10" ], - "18.2.29.C.02": [ - "NET-15" + "4.5.2": [ + "RSK-04.1" ], - "18.2.29.C.03": [ - "NET-15" + "4.1.4(c)": [ + "RSK-06", + "RSK-06.3" ], - "18.2.30.C.01": [ - "NET-15" + "4.4.1": [ + "RSK-06", + "RSK-06.2" ], - "18.2.31.C.01": [ - "NET-15" + "4.4.3": [ + "RSK-06.3" ], - "18.2.32.C.01": [ - "NET-15" + "14.1.1": [ + "SEA-01", + "WEB-01", + "WEB-04" ], - "18.2.34.C.01": [ - "NET-15" + "14.2.10": [ + "SEA-01" ], - "18.2.33.C.01": [ - "NET-15.4" + "7.3.2": [ + "SEA-07.1" ], - "9.3.6.C.01": [ - "NET-18" + "11.4.1": [ + "SEA-13.1" ], - "14.3.6.C.01": [ - "NET-18", - "NET-18.1" + "7.1.1": [ + "OPS-03" ], - "14.3.6.C.03": [ - "NET-18", - "NET-18.1" + "6.5.2": [ + "OPS-07" ], - "14.3.10.C.01": [ - "NET-18" + "3.6.4": [ + "SAT-01.1" ], - "14.3.10.C.02": [ - "NET-18" + "3.6.1": [ + "SAT-02", + "SAT-03", + "SAT-03.3" ], - "14.3.10.C.03": [ - "NET-18" + "3.6.2": [ + "SAT-03" ], - "14.3.10.C.04": [ - "NET-18" + "3.6.3": [ + "SAT-03" ], - "14.3.11.C.01": [ - "NET-18" + "12.1.3": [ + "SAT-03.6", + "THR-03.1" ], - "14.3.11.C.02": [ - "NET-18" + "5.3.2": [ + "TDA-01", + "TPM-04.1" ], - "14.3.12.C.01": [ - "NET-18" + "14.1.5": [ + "TDA-01.1" ], - "20.3.4.C.01": [ - "NET-18" + "14.1.7": [ + "TDA-01.1" ], - "20.3.4.C.02": [ - "NET-18" + "6.3.1": [ + "TDA-01.4" ], - "20.3.5.C.01": [ - "NET-18" + "5.6.1": [ + "TDA-02.10" ], - "20.3.5.C.02": [ - "NET-18" + "5.7.2": [ + "TDA-02.10" ], - "20.3.6.C.01": [ - "NET-18" + "6.1.1": [ + "TDA-06" ], - "20.3.7.C.01": [ - "NET-18" + "6.1.2": [ + "TDA-06" ], - "20.3.7.C.02": [ - "NET-18" + "6.2.1": [ + "TDA-06" ], - "20.3.8.C.01": [ - "NET-18" + "6.2.2": [ + "TDA-06" ], - "20.3.9.C.01": [ - "NET-18" + "5.7.3": [ + "TDA-07", + "TDA-08" ], - "20.3.10.C.01": [ - "NET-18" + "5.7.4": [ + "TDA-09" ], - "20.3.11.C.01": [ - "NET-18" + "7.3.1": [ + "TDA-17" ], - "20.3.11.C.02": [ - "NET-18" + "5.3.4": [ + "TDA-20.3" ], - "20.3.11.C.03": [ - "NET-18" + "3.4.1": [ + "TPM-01" ], - "20.3.12.C.01": [ - "NET-18" + "3.4.2": [ + "TPM-04.1", + "TPM-05", + "TPM-05.4" ], - "20.3.12.C.02": [ - "NET-18" + "6.4.2": [ + "TPM-04.1" ], - "20.3.13.C.01": [ - "NET-18" + "6.4.3": [ + "TPM-04.1" ], - "20.3.13.C.02": [ - "NET-18" + "3.4.3": [ + "TPM-05.5", + "TPM-08", + "TPM-09" ], - "20.3.14.C.01": [ - "NET-18", - "NET-18.2" + "14.1.6": [ + "THR-01", + "THR-01.1" ], - "20.3.15.C.01": [ - "NET-18" + "12.1.1": [ + "THR-03" ], - "20.3.15.C.02": [ - "NET-18" + "12.1.2": [ + "THR-03" ], - "20.3.16.C.01": [ - "NET-18" + "13.2.2": [ + "THR-06" ], - "14.3.8.C.01": [ - "NET-18.2" + "4.3.2": [ + "THR-10" ], - "14.3.9.C.01": [ - "NET-18.2" + "6.1.4": [ + "VPM-01", + "VPM-01.1", + "VPM-02" ], - "8.1.10.C.01": [ - "PES-01" + "13.1.2": [ + "VPM-01.1" ], - "8.2.7.C.01": [ - "PES-01.1" + "13.6.1": [ + "VPM-02" ], - "8.1.11.C.01": [ - "PES-02" + "13.6.1(a)": [ + "VPM-02" ], - "8.1.11.C.02": [ - "PES-02" + "13.6.1(b)": [ + "VPM-02" ], - "8.2.8.C.01": [ - "PES-02.2" + "13.6.1(c)": [ + "VPM-02" ], - "8.2.5.C.01": [ - "PES-03.2" + "7.4.1": [ + "VPM-05" ], - "8.3.3.C.01": [ - "PES-03.4", - "PES-07", - "PES-12", - "PES-12.1" + "7.4.2": [ + "VPM-05.6" ], - "8.3.4.C.01": [ - "PES-03.4", - "PES-07", - "PES-12", - "PES-12.1" + "13.1.1": [ + "VPM-06" ], - "8.3.4.C.02": [ - "PES-03.4", - "PES-07", - "PES-12", - "PES-12.1" + "13.2.1": [ + "VPM-07" ], - "8.3.5.C.01": [ - "PES-03.4", - "PES-07", - "PES-12", - "PES-12.1" + "13.2.3": [ + "VPM-07" ], - "8.2.6.C.01": [ - "PES-04" + "13.2.4": [ + "VPM-07" ], - "8.2.6.C.02": [ - "PES-04" + "13.4.1": [ + "VPM-10" ], - "8.1.13.C.01": [ - "PES-04.2", - "VPM-08" + "13.4.2": [ + "VPM-10" ], - "8.1.13.C.02": [ - "PES-04.2", - "VPM-08" + "14.1.2": [ + "WEB-04" ], - "9.4.4.C.01": [ - "PES-06" + "14.1.3": [ + "WEB-04" ], - "9.4.5.C.01": [ - "PES-06" + "14.1.4": [ + "WEB-04" ], - "9.4.5.C.02": [ - "PES-06" + "14.2.1": [ + "WEB-04", + "WEB-06" ], - "9.4.6.C.01": [ - "PES-06" + "14.2.3": [ + "WEB-04" ], - "9.4.6.C.02": [ - "PES-06" + "14.2.4": [ + "WEB-04" ], - "9.4.7.C.01": [ - "PES-06", - "PES-06.3" + "14.2.11": [ + "WEB-04" ], - "9.4.8.C.01": [ - "PES-06" + "14.2.5": [ + "WEB-06" ], - "9.4.9.C.01": [ - "PES-06", - "PES-06.4", - "PES-06.5" + "14.2.6": [ + "WEB-06" ], - "9.4.10.C.01": [ - "PES-06" + "14.2.7": [ + "WEB-06" ], - "8.3.3.C.02": [ - "PES-12.1" + "14.2.8": [ + "WEB-06" ], - "10.1.42.C.01": [ - "PES-12.1" + "14.2.9": [ + "WEB-06" ], - "10.1.42.C.02": [ - "PES-12.1" + "14.2.2": [ + "WEB-10" + ] + }, + "apac-kor-pipa-2011": { + "III.1.16(1)": [ + "DCH-18.1" ], - "10.1.43.C.01": [ - "PES-12.1" + "III.2.28(1)": [ + "HRS-01" ], - "10.1.43.C.02": [ - "PES-12.1" + "IV.34(2)": [ + "IRO-04.1" ], - "10.1.43.C.03": [ - "PES-12.1" + "IV.34(1)": [ + "IRO-10" ], - "10.1.43.C.04": [ - "PES-12.1" + "IV.34(1)1": [ + "IRO-10" ], - "10.1.44.C.01": [ - "PES-12.1" + "IV.34(1)2": [ + "IRO-10" ], - "10.1.45.C.01": [ - "PES-12.1" + "IV.34(1)3": [ + "IRO-10" ], - "10.1.45.C.02": [ - "PES-12.1" + "IV.34(1)4": [ + "IRO-10" ], - "10.1.46.C.01": [ - "PES-12.1" + "IV.34(1)5": [ + "IRO-10" ], - "10.1.46.C.02": [ - "PES-12.1" + "IV.34(3)": [ + "IRO-10" ], - "10.1.46.C.03": [ - "PES-12.1" + "IV.31(1)": [ + "PRI-01.1" ], - "10.1.46.C.04": [ - "PES-12.1" + "IV.31(2)": [ + "PRI-01.1" ], - "10.1.47.C.01": [ - "PES-12.1" + "IV.31(2)1": [ + "PRI-01.1" ], - "10.1.47.C.02": [ - "PES-12.1" + "IV.31(2)2": [ + "PRI-01.1" ], - "10.1.48.C.01": [ - "PES-12.1" + "IV.31(2)3": [ + "PRI-01.1" ], - "10.1.48.C.02": [ - "PES-12.1" + "IV.31(2)4": [ + "PRI-01.1" ], - "10.1.48.C.03": [ - "PES-12.1" + "IV.31(2)5": [ + "PRI-01.1" ], - "10.1.49.C.01": [ - "PES-12.1" + "IV.31(2)6": [ + "PRI-01.1" ], - "10.1.50.C.01": [ - "PES-12.1" + "IV.31(2)7": [ + "PRI-01.1" ], - "10.1.50.C.02": [ - "PES-12.1" + "IV.31(3)": [ + "PRI-01.1" ], - "10.1.50.C.03": [ - "PES-12.1" + "IV.31(4)": [ + "PRI-01.1" ], - "10.1.50.C.04": [ - "PES-12.1" + "IV.31(5)": [ + "PRI-01.1" ], - "10.1.51.C.01": [ - "PES-12.1" + "I.3(1)": [ + "PRI-01.11" ], - "10.2.6.C.01": [ - "PES-12.1" + "I.3(2)": [ + "PRI-01.11" ], - "10.2.6.C.02": [ - "PES-12.1" + "I.3(3)": [ + "PRI-01.11" ], - "10.2.7.C.01": [ - "PES-12.1" + "I.3(4)": [ + "PRI-01.11" ], - "10.2.8.C.01": [ - "PES-12.1" + "I.3(5)": [ + "PRI-01.11" ], - "10.2.9.C.01": [ - "PES-12.1" + "I.3(6)": [ + "PRI-01.11" ], - "10.2.10.C.01": [ - "PES-12.1" + "I.3(7)": [ + "PRI-01.11" ], - "10.3.5.C.01": [ - "PES-12.1" + "I.3(8)": [ + "PRI-01.11" ], - "10.3.6.C.01": [ - "PES-12.1" + "I.4": [ + "PRI-01.11" ], - "10.3.6.C.02": [ - "PES-12.1" + "I.4.1": [ + "PRI-01.11" ], - "10.3.7.C.01": [ - "PES-12.1" + "I.4.2": [ + "PRI-01.11" ], - "10.3.8.C.01": [ - "PES-12.1" + "I.4.3": [ + "PRI-01.11" ], - "10.3.9.C.01": [ - "PES-12.1" + "I.4.4": [ + "PRI-01.11" ], - "10.3.10.C.01": [ - "PES-12.1" + "I.4.5": [ + "PRI-01.11" ], - "10.3.11.C.01": [ - "PES-12.1" + "III.2.23": [ + "PRI-01.11", + "PRI-05.7" ], - "10.3.12.C.01": [ - "PES-12.1" + "III.2.24(1)": [ + "PRI-01.11" ], - "10.3.13.C.01": [ - "PES-12.1" + "III.2.24(1)1": [ + "PRI-01.11" ], - "10.4.4.C.01": [ - "PES-12.1" + "III.2.24(1)2": [ + "PRI-01.11" ], - "10.4.4.C.02": [ - "PES-12.1" + "III.2.24(2)": [ + "PRI-01.11" ], - "10.4.5.C.01": [ - "PES-12.1" + "III.2.24(3)": [ + "PRI-01.11" ], - "10.4.5.C.02": [ - "PES-12.1" + "III.2.24(4)": [ + "PRI-01.11" ], - "10.4.6.C.01": [ - "PES-12.1" + "IV.29": [ + "PRI-01.11" ], - "10.4.6.C.02": [ - "PES-12.1" + "V.38(3)": [ + "PRI-01.11" ], - "10.4.6.C.03": [ - "PES-12.1" + "V.38(4)": [ + "PRI-01.11" ], - "10.4.7.C.01": [ - "PES-12.1" + "V.38(5)": [ + "PRI-01.11" ], - "10.4.7.C.02": [ - "PES-12.1" + "VIII.60": [ + "PRI-01.11" ], - "10.4.8.C.01": [ - "PES-12.1" + "III.1.18(3)": [ + "PRI-02" ], - "10.4.9.C.01": [ - "PES-12.1" + "III.1.18(3)1": [ + "PRI-02" ], - "10.4.9.C.02": [ - "PES-12.1" + "III.1.18(3)2": [ + "PRI-02" ], - "10.4.9.C.03": [ - "PES-12.1" + "III.1.18(3)3": [ + "PRI-02" ], - "10.4.9.C.04": [ - "PES-12.1" + "III.1.18(3)4": [ + "PRI-02" ], - "10.4.10.C.01": [ - "PES-12.1" + "III.1.18(3)5": [ + "PRI-02" ], - "10.4.11.C.01": [ - "PES-12.1" + "IV.30(1)": [ + "PRI-02" ], - "10.4.12.C.01": [ - "PES-12.1" + "IV.30(1)1": [ + "PRI-02" ], - "10.4.13.C.01": [ - "PES-12.1" + "IV.30(1)2": [ + "PRI-02" ], - "10.4.13.C.02": [ - "PES-12.1" + "IV.30(1)3": [ + "PRI-02" ], - "10.5.4.C.01": [ - "PES-12.1" + "IV.30(1)4": [ + "PRI-02" ], - "10.5.5.C.01": [ - "PES-12.1" + "IV.30(1)5": [ + "PRI-02" ], - "10.5.6.C.01": [ - "PES-12.1" + "IV.30(1)6": [ + "PRI-02" ], - "10.5.6.C.02": [ - "PES-12.1" + "IV.30(2)": [ + "PRI-02" ], - "10.5.7.C.01": [ - "PES-12.1" + "IV.30(3)": [ + "PRI-02" ], - "10.5.8.C.01": [ - "PES-12.1" + "III.1.15(2)": [ + "PRI-03" ], - "10.5.8.C.02": [ - "PES-12.1" + "III.1.15(2)1": [ + "PRI-03" ], - "10.5.9.C.01": [ - "PES-12.1" + "III.1.15(2)2": [ + "PRI-03" ], - "10.5.9.C.02": [ - "PES-12.1" + "III.1.15(2)3": [ + "PRI-03" ], - "10.5.10.C.01": [ - "PES-12.1" + "III.1.15(2)4": [ + "PRI-03" ], - "10.5.10.C.02": [ - "PES-12.1" + "III.1.17(1)": [ + "PRI-03" ], - "10.5.11.C.01": [ - "PES-12.1" + "III.1.17(1)1": [ + "PRI-03" ], - "10.6.22.C.01": [ - "PES-12.1" + "III.1.17(1)2": [ + "PRI-03" ], - "10.6.22.C.02": [ - "PES-12.1" + "III.1.17(2)": [ + "PRI-03" ], - "10.6.23.C.01": [ - "PES-12.1" + "III.1.17(2)1": [ + "PRI-03" ], - "10.6.23.C.02": [ - "PES-12.1" + "III.1.17(2)2": [ + "PRI-03" ], - "10.6.23.C.03": [ - "PES-12.1" + "III.1.17(2)3": [ + "PRI-03" ], - "10.6.23.C.04": [ - "PES-12.1" + "III.1.17(2)4": [ + "PRI-03" ], - "10.6.24.C.01": [ - "PES-12.1" + "III.1.17(2)5": [ + "PRI-03" ], - "10.6.24.C.02": [ - "PES-12.1" + "III.1.17(3)": [ + "PRI-03" ], - "10.6.25.C.01": [ - "PES-12.1" + "III.1.22(3)": [ + "PRI-03" ], - "10.6.26.C.01": [ - "PES-12.1" + "III.1.22(2)": [ + "PRI-03.1" ], - "10.6.27.C.01": [ - "PES-12.1" + "III.1.20(1)": [ + "PRI-03.2" ], - "10.6.28.C.01": [ - "PES-12.1" + "III.1.20(1)1": [ + "PRI-03.2" ], - "10.6.28.C.02": [ - "PES-12.1" + "III.1.20(1)2": [ + "PRI-03.2" ], - "10.6.29.C.01": [ - "PES-12.1" + "III.1.20(1)3": [ + "PRI-03.2" ], - "10.6.30.C.01": [ - "PES-12.1" + "III.1.22(1)": [ + "PRI-03.2" ], - "10.6.31.C.01": [ - "PES-12.1" + "V.37(1)": [ + "PRI-03.4" ], - "10.7.6.C.01": [ - "PES-13" + "III.1.16(2)": [ + "PRI-03.5" ], - "10.7.6.C.02": [ - "PES-13" + "III.1.22(4)": [ + "PRI-03.5" ], - "10.7.7.C.01": [ - "PES-13" + "V.38(1)": [ + "PRI-03.6" ], - "10.7.7.C.02": [ - "PES-13" + "V.38(2)": [ + "PRI-03.6" ], - "10.7.8.C.01": [ - "PES-13" + "III.1.22(5)": [ + "PRI-03.13" ], - "10.7.9.C.01": [ - "PES-13" + "III.1.15(1)": [ + "PRI-04" ], - "2.3.25.C.01": [ - "PRM-01.1" + "III.1.15(1)1": [ + "PRI-04" ], - "2.3.25.C.02": [ - "PRM-01.1" + "III.1.15(1)2": [ + "PRI-04" ], - "2.3.29.C.01": [ - "PRM-01.1" + "III.1.15(1)3": [ + "PRI-04" ], - "12.1.30.C.01": [ - "PRM-05" + "III.1.15(1)4": [ + "PRI-04" ], - "12.1.30.C.02": [ - "PRM-05" + "III.1.15(1)5": [ + "PRI-04" ], - "12.1.30.C.03": [ - "PRM-05" + "III.1.15(1)6": [ + "PRI-04" ], - "12.1.32.C.01": [ - "PRM-05", - "PRM-06", - "TDA-01.1" + "III.1.21(1)": [ + "PRI-05" ], - "12.1.32.C.02": [ - "PRM-05", - "PRM-06", - "TDA-01.1" + "III.1.21(2)": [ + "PRI-05" ], - "12.1.32.C.03": [ - "PRM-05", - "PRM-06", - "TDA-01.1" + "III.1.21(3)": [ + "PRI-05" ], - "5.3.6.C.01": [ - "RSK-01" + "III.1.21(4)": [ + "PRI-05" ], - "5.3.7.C.01": [ - "RSK-01" + "III.1.18(1)": [ + "PRI-05.4" ], - "5.3.8.C.01": [ - "RSK-01" + "III.1.18(2)": [ + "PRI-05.4" ], - "5.3.9.C.01": [ - "RSK-01" + "III.1.18(2)1": [ + "PRI-05.4" ], - "23.2.16.C.01": [ - "RSK-01.1", - "RSK-02.1" + "III.1.18(2)2": [ + "PRI-05.4" ], - "23.2.17.C.01": [ - "RSK-01.1", - "RSK-02.1" + "III.1.18(2)3": [ + "PRI-05.4" ], - "2.4.13.C.01": [ - "RSK-03" + "III.1.18(2)4": [ + "PRI-05.4" ], - "2.4.13.C.02": [ - "RSK-03" + "III.1.18(2)5": [ + "PRI-05.4" ], - "2.4.13.C.03": [ - "RSK-03" + "III.1.18(2)6": [ + "PRI-05.4" ], - "2.4.13.C.04": [ - "RSK-03" + "III.1.18(2)7": [ + "PRI-05.4" ], - "2.4.13.C.05": [ - "RSK-03" + "III.1.18(2)8": [ + "PRI-05.4" ], - "2.4.13.C.06": [ - "RSK-03" + "III.1.18(2)9": [ + "PRI-05.4" ], - "2.4.13.C.07": [ - "RSK-03" + "III.1.19": [ + "PRI-05.4" ], - "2.3.27.C.01": [ - "RSK-04" + "III.1.19.1": [ + "PRI-05.4" ], - "2.3.27.C.02": [ - "RSK-04" + "III.1.19.2": [ + "PRI-05.4" ], - "5.9.23.C.01": [ - "RSK-04", - "THR-06" + "III.2.23.1": [ + "PRI-05.4" ], - "23.2.16.C.02": [ - "RSK-04" + "III.2.23.2": [ + "PRI-05.4" ], - "12.4.5.C.01": [ - "RSK-06.2", - "TDA-01.1" + "V.35(1)": [ + "PRI-06" ], - "2.2.7.C.01": [ - "RSK-09" + "V.35(2)": [ + "PRI-06" ], - "12.7.14.C.01": [ - "RSK-09", - "TPM-03" + "V.35(3)": [ + "PRI-06" ], - "12.7.14.C.02": [ - "RSK-09", - "TPM-03" + "V.36(1)": [ + "PRI-06" ], - "12.7.14.C.03": [ - "RSK-09", - "TPM-03" + "V.36(2)": [ + "PRI-06.4" ], - "12.7.15.C.01": [ - "RSK-09", - "TPM-03" + "V.36(3)": [ + "PRI-06.4" ], - "12.7.15.C.02": [ - "RSK-09", - "TPM-03" + "V.36(4)": [ + "PRI-06.4" ], - "12.7.16.C.01": [ - "RSK-09", - "TPM-03" + "V.36(5)": [ + "PRI-06.4" ], - "12.7.16.C.02": [ - "RSK-09", - "TPM-03" + "V.37(2)": [ + "PRI-06.4" ], - "12.7.16.C.03": [ - "RSK-09", - "TPM-03" + "V.37(2)1": [ + "PRI-06.4" ], - "12.7.17.C.01": [ - "RSK-09", - "TPM-02", - "TPM-03" + "V.37(2)2": [ + "PRI-06.4" ], - "12.7.18.C.01": [ - "RSK-09", - "TPM-03" + "V.37(2)3": [ + "PRI-06.4" ], - "12.7.18.C.02": [ - "RSK-09", - "TPM-03" + "V.37(2)4": [ + "PRI-06.4" ], - "12.7.19.C.01": [ - "RSK-09", - "TPM-03" + "V.37(3)": [ + "PRI-06.4" ], - "12.7.19.C.02": [ - "RSK-09", - "TPM-03" + "V.37(4)": [ + "PRI-06.4" ], - "12.7.20.C.01": [ - "RSK-09", - "TPM-03" + "III.1.18(5)": [ + "PRI-07.1" ], - "12.7.20.C.02": [ - "RSK-09", - "TPM-03" + "V.35(4)": [ + "PRI-07.4" ], - "12.7.20.C.03": [ - "RSK-09", - "TPM-03" + "V.35(4)1": [ + "PRI-07.4" ], - "12.7.20.C.04": [ - "RSK-09", - "TPM-03" + "V.35(4)2": [ + "PRI-07.4" ], - "12.7.20.C.05": [ - "RSK-09", - "TPM-03" + "V.35(4)3": [ + "PRI-07.4" ], - "12.7.21.C.01": [ - "RSK-09", - "TPM-03" + "V.35(4)3.a": [ + "PRI-07.4" ], - "1.2.13.C.01": [ - "SEA-01", - "SEA-02", - "SEA-03" + "V.35(4)3.b": [ + "PRI-07.4" ], - "1.2.13.C.02": [ - "SEA-01", - "SEA-02", - "SEA-03" + "V.35(4)3.c": [ + "PRI-07.4" ], - "22.2.12.C.01": [ - "SEA-13.1" + "V.35(4)3.d": [ + "PRI-07.4" ], - "22.2.12.C.02": [ - "SEA-13.1" + "V.35(4)3.e": [ + "PRI-07.4" ], - "22.2.12.C.03": [ - "SEA-13.1" + "III.2.27(1)": [ + "PRI-17" ], - "22.2.12.C.04": [ - "SEA-13.1" + "III.2.27(1)1": [ + "PRI-17" ], - "22.2.13.C.01": [ - "SEA-13.1" + "III.2.27(1)2": [ + "PRI-17" ], - "22.2.13.C.02": [ - "SEA-13.1" + "III.2.27(1)3": [ + "PRI-17" ], - "22.2.14.C.01": [ - "SEA-13.1" + "III.2.27(2)": [ + "PRI-17" ], - "22.2.14.C.02": [ - "SEA-13.1" + "III.2.27(3)": [ + "PRI-17" ], - "22.2.14.C.03": [ - "SEA-13.1" + "III.2.28(2)": [ + "SAT-01" + ] + }, + "apac-twn-pdpa-2025": { + "I.12": [ + "IRO-10" ], - "22.2.14.C.04": [ - "SEA-13.1" + "I.12.1": [ + "IRO-10" ], - "22.2.14.C.05": [ - "SEA-13.1" + "I.12.2": [ + "IRO-10" ], - "22.2.14.C.06": [ - "SEA-13.1" + "III.20-1": [ + "PRI-01.6" ], - "22.2.14.C.07": [ - "SEA-13.1" + "I.5": [ + "PRI-01.11" ], - "22.2.15.C.01": [ - "SEA-13.1" + "I.8-1": [ + "PRI-02" ], - "22.2.15.C.02": [ - "SEA-13.1" + "I.8.1-1": [ + "PRI-02" ], - "22.2.15.C.03": [ - "SEA-13.1" + "I.8.2-1": [ + "PRI-02" ], - "22.2.15.C.04": [ - "SEA-13.1" + "I.8.3-1": [ + "PRI-02" ], - "22.2.15.C.05": [ - "SEA-13.1" + "I.8.4-1": [ + "PRI-02" ], - "22.2.15.C.06": [ - "SEA-13.1" + "I.8.5-1": [ + "PRI-02" ], - "22.2.15.C.07": [ - "SEA-13.1" + "I.8.6-1": [ + "PRI-02" ], - "22.2.16.C.01": [ - "SEA-13.1" + "I.8-2": [ + "PRI-02" ], - "22.2.16.C.02": [ - "SEA-13.1" + "I.8.1-2": [ + "PRI-02" ], - "22.2.16.C.03": [ - "SEA-13.1" + "I.8.2-2": [ + "PRI-02" ], - "16.1.48.C.01": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "I.8.3-2": [ + "PRI-02" ], - "16.1.48.C.02": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "I.8.4-2": [ + "PRI-02" ], - "16.1.48.C.03": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "I.8.5-2": [ + "PRI-02" ], - "16.1.49.C.01": [ - "SEA-19" + "I.8.6-2": [ + "PRI-02" ], - "5.1.15.C.01": [ - "OPS-02" + "I.9": [ + "PRI-02" ], - "9.1.4.C.01": [ - "SAT-01" + "I.9.1": [ + "PRI-02" ], - "9.1.5.C.01": [ - "SAT-02" + "I.9.2": [ + "PRI-02" ], - "9.1.5.C.02": [ - "SAT-02" + "I.9.3": [ + "PRI-02" ], - "9.1.6.C.01": [ - "SAT-02", - "SAT-03" + "I.9.4": [ + "PRI-02" ], - "9.1.6.C.02": [ - "SAT-02", - "SAT-03" + "I.9.5": [ + "PRI-02" ], - "9.1.6.C.03": [ - "SAT-03" + "I.7": [ + "PRI-03" ], - "12.1.31.C.01": [ - "TDA-01.1" + "I.11": [ + "PRI-05.2" ], - "12.1.33.C.01": [ - "TDA-01.1" + "I.6": [ + "PRI-05.4" ], - "12.1.34.C.01": [ - "TDA-01.1" + "I.6.1": [ + "PRI-05.4" ], - "12.1.34.C.02": [ - "TDA-01.1" + "I.6.2": [ + "PRI-05.4" ], - "12.1.35.C.01": [ - "TDA-01.1" + "I.6.3": [ + "PRI-05.4" ], - "12.1.36.C.01": [ - "TDA-01.1" + "I.6.4": [ + "PRI-05.4" ], - "12.1.37.C.01": [ - "TDA-01.1" + "I.6.5": [ + "PRI-05.4" ], - "12.4.3.C.01": [ - "TDA-01.1" + "I.6.6": [ + "PRI-05.4" ], - "12.4.4.C.01": [ - "TDA-01.1" + "III.19": [ + "PRI-05.4" ], - "12.4.4.C.02": [ - "TDA-01.1" + "III.19.1": [ + "PRI-05.4" ], - "12.4.4.C.03": [ - "TDA-01.1" + "III.19.2": [ + "PRI-05.4" ], - "12.4.4.C.04": [ - "TDA-01.1" + "III.19.3": [ + "PRI-05.4" ], - "12.4.4.C.05": [ - "TDA-01.1" + "III.19.4": [ + "PRI-05.4" ], - "12.4.4.C.06": [ - "TDA-01.1" + "III.19.5": [ + "PRI-05.4" ], - "12.4.6.C.01": [ - "TDA-01.1" + "III.19.6": [ + "PRI-05.4" ], - "12.4.7.C.01": [ - "TDA-01.1", - "TDA-17" + "III.19.7": [ + "PRI-05.4" ], - "14.4.5.C.01": [ - "TDA-06" + "III.19.8": [ + "PRI-05.4" ], - "14.4.6.C.01": [ - "TDA-06.1", - "TDA-06.2" + "III.20": [ + "PRI-05.4" ], - "14.4.6.C.02": [ - "TDA-06.1", - "TDA-06.2" + "III.20.1": [ + "PRI-05.4" ], - "14.4.6.C.03": [ - "TDA-06.1", - "TDA-06.2" + "III.20.2": [ + "PRI-05.4" ], - "14.4.4.C.01": [ - "TDA-07" + "III.20.3": [ + "PRI-05.4" ], - "14.5.6.C.01": [ - "TDA-09.4", - "TDA-09.5", - "WEB-01" + "III.20.4": [ + "PRI-05.4" ], - "2.2.6.C.01": [ - "TPM-01" + "III.20.5": [ + "PRI-05.4" ], - "2.2.6.C.02": [ - "TPM-01" + "III.20.6": [ + "PRI-05.4" ], - "5.9.24.C.01": [ - "THR-06" + "III.20.7": [ + "PRI-05.4" ], - "5.9.24.C.02": [ - "THR-06" + "I.3": [ + "PRI-06" ], - "5.9.25.C.01": [ - "THR-06" + "I.3.1": [ + "PRI-06" ], - "5.9.26.C.01": [ - "THR-06" + "I.3.2": [ + "PRI-06" ], - "5.9.26.C.02": [ - "THR-06" + "I.3.3": [ + "PRI-06" ], - "5.9.27.C.01": [ - "THR-06" + "I.3.4": [ + "PRI-06" ], - "6.2.4.C.01": [ - "VPM-01", - "VPM-01.1" + "I.3.5": [ + "PRI-06" ], - "14.1.14.C.01": [ - "VPM-06.8" + "I.10": [ + "PRI-06.4" ], - "14.5.7.C.01": [ - "WEB-01", - "WEB-07", - "WEB-08" + "I.10.1": [ + "PRI-06.4" ], - "14.5.8.C.01": [ - "WEB-01", - "WEB-07", - "WEB-08" + "I.10.2": [ + "PRI-06.4" + ], + "I.10.3": [ + "PRI-06.4" ] }, - "apac-nzl-privacy-act-2020": { - "P6-(2)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2" - ], - "Principle 7": [ - "DCH-22.1", - "PRI-06.1" + "americas-arg-ppd-2018": { + "E.1.2-8": [ + "GOV-04" ], - "P7-(1)": [ - "DCH-22.1", - "PRI-06.1" + "B.1.3-3": [ + "AST-01", + "OPS-01.1" ], - "P7-(2)": [ - "DCH-22.1", - "PRI-06.1" + "B.1.1": [ + "AST-01.1", + "AST-02", + "AST-04" ], - "P7-(3)(a)": [ - "DCH-22.1", - "PRI-06.1" + "D.1.1-4": [ + "AST-02" ], - "P7-(3)(b)": [ - "DCH-22.1", - "PRI-06.1" + "B.1.3-1": [ + "AST-02.1", + "OPS-01.1" ], - "P7-(4)": [ - "DCH-22.1", - "PRI-06.1" + "B.1.2-1": [ + "AST-03" ], - "P7-(5)": [ - "DCH-22.1", - "PRI-06.1" + "B.1.2-2": [ + "AST-03" ], - "P7-(6)": [ - "DCH-22.1", - "PRI-06.1" + "E.1.1-2": [ + "AST-04" ], - "Principle 12": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "F": [ + "AST-09" ], - "P12-(1)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "F.1.2-DS-2": [ + "AST-09" ], - "P12-(1)(a)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "D": [ + "BCD-11" ], - "P12-(1)(b)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "D.1.1-1": [ + "BCD-11" ], - "P12-(1)(c)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "D.1.1-2": [ + "BCD-11.1" ], - "P12-(1)(d)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "D.1.1-3": [ + "BCD-11.1" ], - "P12-(1)(e)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "D.1.2-4": [ + "BCD-11.1", + "DCH-09" ], - "P12-(1)(f)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "D.1.2-DS-2": [ + "BCD-11.2" ], - "P12-(2)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "D.1.2-2": [ + "BCD-11.4" ], - "P12-(3)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" + "D.1.2-3": [ + "BCD-12" ], - "Principle 13": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "D.1.2-DS-4": [ + "BCD-12", + "BCD-13", + "BCD-14" ], - "P13-(1)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "C": [ + "CHG-01" ], - "P13-(2)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "C.1.1-2": [ + "CHG-01" ], - "P13-(2)(a)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "C.1.1-DS": [ + "CHG-02" ], - "P13-(2)(b)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "C.1.1-3": [ + "CHG-02.2" ], - "P13-(3)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "C.1.1-1": [ + "CHG-06" ], - "P13-(4)(a)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "E.1.4-DS-2": [ + "CPL-02.2" ], - "P13-(4)(b)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "E.1.4-DS-1": [ + "CPL-03" ], - "P13-(5)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" + "B.2.4-4": [ + "CFG-02", + "PES-03.3" ], - "Principle 5": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" + "E.1.2-5": [ + "CFG-02", + "END-02" ], - "P5-(a)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" + "E.1.2-2": [ + "CFG-02.5" ], - "P5-(a)(i)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" + "E.1.2-DS-1": [ + "CFG-02.5" ], - "P5-(a)(ii)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" + "B.2.3-3": [ + "MON-01.4" ], - "P5-(a)(iii)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" + "B.2.3-4": [ + "MON-01.4" ], - "P5-(b)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" + "B.2.5-DS-3": [ + "MON-01.4", + "MON-01.8" ], - "Principle 11": [ - "PRI-01.7" + "B.2.1-3": [ + "MON-01.15", + "IAC-16" ], - "P11-(1)": [ - "PRI-01.7" + "A.2.1": [ + "CRY-03" ], - "P11-(1)(a)": [ - "PRI-01.7" + "A.2.3-DS": [ + "CRY-03" ], - "P11-(1)(b)": [ - "PRI-01.7" + "A.2.3": [ + "CRY-08", + "CRY-09" ], - "P11-(1)(c)": [ - "PRI-01.7" + "B.1.3-2": [ + "DCH-01.4", + "OPS-01.1" ], - "P11-(1)(d)": [ - "PRI-01.7" + "B.2.1-2": [ + "DCH-01.4", + "IAC-16" ], - "P11-(1)(e)(i)": [ - "PRI-01.7" + "H.1.1": [ + "DCH-03.2", + "DCH-23" ], - "P11-(1)(e)(ii)": [ - "PRI-01.7" + "D.1.2-DS-3": [ + "DCH-07", + "DCH-07.1" ], - "P11-(1)(e)(iii)": [ - "PRI-01.7" + "F.1.2-DS-1": [ + "DCH-08" ], - "P11-(1)(e)(iv)": [ - "PRI-01.7" + "F.1.2": [ + "DCH-09" ], - "P11-(1)(f)(i)": [ - "PRI-01.7" + "F.1.1": [ + "DCH-09.1" ], - "P11-(1)(f)(ii)": [ - "PRI-01.7" + "F.1.4": [ + "DCH-09.1" ], - "P11-(1)(g)": [ - "PRI-01.7" + "E.1.2-6": [ + "END-04" ], - "P11-(1)(h)(i)": [ - "PRI-01.7" + "B.2.2": [ + "HRS-03", + "HRS-03.1", + "HRS-04.2" ], - "P11-(1)(h)(ii)": [ - "PRI-01.7" + "E.1.2-1": [ + "HRS-03", + "PRI-01.6" ], - "P11-(1)(i)": [ - "PRI-01.7" + "F.1.3": [ + "HRS-03" ], - "P11-(2)": [ - "PRI-01.7" + "B": [ + "IAC-01" ], - "Principle 3": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "D.1.2-1": [ + "IAC-01" ], - "P3-(1)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.3-1": [ + "IAC-01.2" ], - "P3-(1)(a)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.1.2-3": [ + "IAC-08" ], - "P3-(1)(b)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.3-7": [ + "IAC-10.1" ], - "P3-(1)(c)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.3-2": [ + "IAC-15.1" ], - "P3-(1)(d)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.5": [ + "IAC-15.3", + "OPS-01.1" ], - "P3-(1)(d)(i)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.3-8": [ + "IAC-15.5" ], - "P3-(1)(d)(ii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.3-6": [ + "IAC-16" ], - "P3-(1)(e)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.5-DS-2": [ + "IAC-16" ], - "P3-(1)(e)(i)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.5-DS-1": [ + "IAC-23" ], - "P3-(1)(e)(ii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.3-5": [ + "IAC-28.1" ], - "P3-(1)(f)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "E.1.2-11": [ + "IRO-01", + "IRO-02" ], - "P3-(1)(g)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "G": [ + "IRO-01" ], - "P3-(2)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "E.1.2-10": [ + "IRO-02" ], - "P3-(3)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "G.1.1-1": [ + "IRO-02", + "IRO-04" ], - "P3-(4)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "G.1.1-2": [ + "IRO-07" ], - "P3-(4)(a)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "G.1.2": [ + "IRO-10" ], - "P3-(4)(b)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "G.1.3": [ + "IRO-10.2" ], - "P3-(4)(b)(i)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.1-1": [ + "IAO-03" ], - "P3-(4)(b)(ii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "E.1.1-3": [ + "IAO-03" ], - "P3-(4)(b)(iii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "E.1.2-3": [ + "NET-06" ], - "P3-(4)(b)(iv)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "E.1.2-DS-2": [ + "NET-08" ], - "P3-(4)(c)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "E.1.2-DS-3": [ + "NET-17" ], - "P3-(4)(d)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.4-1": [ + "PES-03" ], - "P3-(4)(e)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.4-2": [ + "PES-03", + "OPS-01.1" ], - "P3-(4)(e)(i)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "B.2.4-3": [ + "PES-03.1", + "PES-03.3" ], - "P3-(4)(e)(ii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" + "D.1.2-DS-1": [ + "PES-07.5", + "PES-08" ], - "Principle 1": [ - "PRI-04" + "A": [ + "PRI-01.11" ], - "P1-(1)(a)": [ - "PRI-04" + "A.1.1": [ + "PRI-01.11" ], - "P1-(1)(b)": [ - "PRI-04" + "A.1.2": [ + "PRI-01.11" ], - "Principle 4": [ - "PRI-04" + "A.1.3": [ + "PRI-01.11", + "PRI-05.2" ], - "P4-(a)": [ - "PRI-04" + "A.2.2-1": [ + "PRI-01.11" ], - "P4-(b)": [ - "PRI-04" + "A.2.2-2": [ + "PRI-01.11" ], - "P4-(b)(i)": [ - "PRI-04" + "E.1.2-9": [ + "SEA-20" ], - "P4-(b)(ii)": [ - "PRI-04" + "H": [ + "TDA-01" ], - "Principle 2": [ - "PRI-04.2" + "E.1.2-4": [ + "TDA-08" ], - "P2-(1)": [ - "PRI-04.2" + "E.1.1-1": [ + "THR-09", + "THR-10" ], - "P2-(2)": [ - "PRI-04.2" + "E": [ + "VPM-01" ], - "P2-(2)(a)": [ - "PRI-04.2" + "E.1.2-7": [ + "VPM-05" + ] + }, + "americas-bhs-dpa-2003": { + "II.4(1)": [ + "CPL-01" ], - "P2-(2)(b)": [ - "PRI-04.2" + "IV.24(6)": [ + "CPL-01" ], - "P2-(2)(c)": [ - "PRI-04.2" + "IV.24(7)": [ + "CPL-01" ], - "P2-(2)(d)": [ - "PRI-04.2" + "IV.24(7)(a)": [ + "CPL-01" ], - "P2-(2)(e)(i)": [ - "PRI-04.2" + "IV.24(7)(b)": [ + "CPL-01" ], - "P2-(2)(e)(ii)": [ - "PRI-04.2" + "V.45(4)(a)": [ + "CPL-01" ], - "P2-(2)(e)(iii)": [ - "PRI-04.2" + "V.45(4)(b)": [ + "CPL-01" ], - "P2-(2)(e)(iv)": [ - "PRI-04.2" + "V.45(5)": [ + "CPL-01" ], - "P2-(2)(e)(v)": [ - "PRI-04.2" + "V.45(6)": [ + "CPL-01" ], - "P2-(2)(f)": [ - "PRI-04.2" + "V.45(7)": [ + "CPL-01" ], - "P2-(2)(g)(i)": [ - "PRI-04.2" + "VI.55": [ + "CPL-03" ], - "P2-(2)(g)(ii)": [ - "PRI-04.2" + "VI.55(a)": [ + "CPL-03" ], - "Principle 10": [ - "PRI-05.1", - "PRI-05.4" + "VI.55(b)": [ + "CPL-03" ], - "P10-(1)": [ - "PRI-05.1", - "PRI-05.4" + "V.46(1)": [ + "DCH-01.2" ], - "P10-(1)(a)": [ - "PRI-05.1", - "PRI-05.4" + "V.46(2)": [ + "DCH-01.2" ], - "P10-(1)(b)(i)": [ - "PRI-05.1", - "PRI-05.4" + "V.46(2)(a)": [ + "DCH-01.2" ], - "P10-(1)(b)(ii)": [ - "PRI-05.1", - "PRI-05.4" + "V.46(2)(b)": [ + "DCH-01.2" ], - "P10-(1)(c)": [ - "PRI-05.1", - "PRI-05.4" + "II.4(2)": [ + "HRS-05" ], - "P10-(1)(d)": [ - "PRI-05.1", - "PRI-05.4" + "V.48(1)": [ + "IRO-04.1" ], - "P10-(1)(e)(i)": [ - "PRI-05.1", - "PRI-05.4" + "V.48(2)": [ + "IRO-10" ], - "P10-(1)(e)(ii)": [ - "PRI-05.1", - "PRI-05.4" + "V.48(3)": [ + "IRO-10" ], - "P10-(1)(e)(iii)": [ - "PRI-05.1", - "PRI-05.4" + "V.48(3)(a)": [ + "IRO-10" ], - "P10-(1)(e)(iv)": [ - "PRI-05.1", - "PRI-05.4" + "V.48(3)(b)": [ + "IRO-10" ], - "P10-(1)(f)(i)": [ - "PRI-05.1", - "PRI-05.4" + "V.48(3)(c)": [ + "IRO-10" ], - "P10-(1)(f)(ii)": [ - "PRI-05.1", - "PRI-05.4" + "V.47(1)": [ + "IRO-10.2" ], - "P10-(2)": [ - "PRI-05.1", - "PRI-05.4" + "V.47(2)": [ + "IRO-10.2" ], - "Principle 9": [ - "PRI-05.2" + "V.47(3)": [ + "IRO-10.2" ], - "Principle 6": [ - "PRI-06" + "V.47(4)(a)": [ + "IRO-10.2" ], - "P6-(1)": [ - "PRI-06" + "V.47(4)(b)": [ + "IRO-10.2" ], - "P6-(1)(a)": [ - "PRI-06" + "V.47(4)(c)": [ + "IRO-10.2" ], - "P6-(1)(b)": [ - "PRI-06" + "V.47(4)(d)": [ + "IRO-10.2" ], - "P6-(3)": [ - "PRI-06" - ] - }, - "apac-phl-dpa-2012": { - "19": [ - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "V.47(4)(e)": [ + "IRO-10.2" ], - "20": [ - "PRI-14.1" + "V.47(4)(f)": [ + "IRO-10.2" ], - "21": [ - "PRI-05" + "V.47(4)(g)": [ + "IRO-10.2" ], - "22": [ - "PRI-05.4" + "V.47(4)(h)": [ + "IRO-10.2" ], - "25": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-03", - "TPM-04.4", - "TPM-05" + "V.47(5)": [ + "IRO-10.2" ], - "27": [ - "GOV-01" + "V.47(6)": [ + "IRO-10.2" ], - "28": [ - "GOV-01" + "V.47(6)(a)": [ + "IRO-10.2" ], - "29": [ - "CPL-02", - "SEA-01", - "SEA-02", - "SEA-03" + "V.47(6)(b)": [ + "IRO-10.2" ], - "34": [ - "DCH-22.1", - "PRI-05.4", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3" + "V.47(6)(c)": [ + "IRO-10.2" ], - "38": [ - "IRO-04.1" + "IV.28(3)(a)": [ + "IRO-12" ], - "43": [ - "TPM-03", - "TPM-05" + "IV.28(3)(b)": [ + "IRO-12" ], - "46": [ - "PRI-15" + "IV.28(3)(b)(i)": [ + "IRO-12" ], - "47": [ - "PRI-15" + "IV.28(3)(b)(ii)": [ + "IRO-12" ], - "48": [ - "PRI-15" + "IV.28(3)(b)(iii)": [ + "IRO-12" ], - "Inferred": [ - "PRI-01" + "V.51(1)(a)": [ + "IAO-03.2", + "PRI-07.1" ], - "Expectation": [ + "V.45(2)(a)": [ "PRI-01" - ] - }, - "apac-sgp-pdpa-2012": { - "11": [ - "IRO-14", - "PRI-01.1" ], - "12": [ - "GOV-01", + "V.45(2)(b)": [ "PRI-01" ], - "13": [ - "PRI-03" - ], - "14": [ - "PRI-02", - "PRI-02.1", - "PRI-05.4" - ], - "17": [ - "PRI-04", - "PRI-04.1" + "V.45(2)(b)(i)": [ + "PRI-01" ], - "19": [ - "PRI-02.1" + "V.45(2)(b)(ii)": [ + "PRI-01" ], - "20": [ - "PRI-02.1" + "V.45(1)": [ + "PRI-01.4" ], - "21": [ - "PRI-06" + "V.45(1)(a)": [ + "PRI-01.4" ], - "22": [ - "DCH-22.1", - "PRI-06.1" + "V.45(1)(b)": [ + "PRI-01.4" ], - "23": [ - "PRI-05", - "PRI-05.2", - "PRI-06.2" + "V.45(1)(c)": [ + "PRI-01.4" ], - "24": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "DCH-25", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "V.45(3)": [ + "PRI-01.4" ], - "25": [ - "PRI-05" + "V.45(3)(a)": [ + "PRI-01.4" ], - "26": [ - "DCH-01", - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "V.45(3)(b)": [ + "PRI-01.4" ], - "39": [ - "PRI-15" - ] - }, - "apac-sgp-cyber-hygiene-practice-2019": { - "3.1(a)": [ - "CPL-01" + "V.45(3)(c)": [ + "PRI-01.4" ], - "3.1(b)": [ - "CPL-01" + "V.45(3)(d)": [ + "PRI-01.4" ], - "3.1(c)": [ - "CPL-01" + "V.45(3)(e)": [ + "PRI-01.4" ], - "4.3(a)": [ - "CFG-01", - "CFG-02", - "CFG-02.2" + "V.45(3)(f)": [ + "PRI-01.4" ], - "4.3(b)": [ - "CFG-02.2" + "V.45(3)(g)": [ + "PRI-01.4" ], - "4.3(c)": [ - "CFG-02.7", - "RSK-06.2" + "V.45(3)(h)": [ + "PRI-01.4" ], - "4.5": [ - "END-01", - "END-02", - "END-04" + "V.45(3)(i)": [ + "PRI-01.4" ], - "4.1": [ - "IAC-01", - "IAC-16" + "V.45(3)(j)": [ + "PRI-01.4" ], - "4.6(b)": [ - "IAC-06" + "II.5(1)(f)": [ + "PRI-01.6", + "PRI-01.11" ], - "4.6(a)": [ - "IAC-06.1", - "IAC-06.3" + "II.9(2)": [ + "PRI-01.6" ], - "4.4": [ - "NET-01", - "NET-02", - "NET-03" + "II.11(1)": [ + "PRI-01.6" ], - "4.2(b)": [ - "RSK-06.2", - "VPM-01", - "VPM-02", - "VPM-05" + "II.11(1)(a)": [ + "PRI-01.6" ], - "4.2(a)": [ - "VPM-01", - "VPM-02", - "VPM-05", - "VPM-05.4" - ] - }, - "apac-sgp-mas-trm-2021": { - "3.1.1": [ - "GOV-01.1" + "II.11(1)(b)": [ + "PRI-01.6" ], - "3.1.2": [ - "GOV-01.1" + "II.11(2)": [ + "PRI-01.6" ], - "3.1.3": [ - "GOV-01.1" + "V.43(4)(d)": [ + "PRI-01.6", + "PRI-01.11" ], - "3.1.4": [ - "GOV-01.1", - "PRM-01.1" + "V.43(4)(e)": [ + "PRI-01.6", + "PRI-01.11" ], - "3.1.5": [ - "GOV-01.1", - "PRM-01.1" + "V.52(1)": [ + "PRI-01.6" ], - "3.1.6": [ - "GOV-01.1" + "V.52(2)": [ + "PRI-01.6" ], - "3.1.7(a)": [ - "GOV-01.1", - "GOV-04" + "V.52(2)(a)": [ + "PRI-01.6" ], - "3.1.7(b)": [ - "GOV-01.1", - "GOV-04" + "V.52(2)(b)": [ + "PRI-01.6" ], - "3.1.7(c)": [ - "GOV-01.1", - "GOV-04" + "V.52(2)(c)": [ + "PRI-01.6" ], - "3.1.7(d)": [ - "GOV-01.1", - "GOV-04" + "V.52(2)(d)": [ + "PRI-01.6" ], - "3.1.7(e)": [ - "GOV-01.1", - "GOV-04" + "V.52(4)": [ + "PRI-01.6" ], - "3.1.7(f)": [ - "GOV-01.1", - "GOV-04" + "II.5(1)(a)": [ + "PRI-01.11" ], - "3.1.7(g)": [ - "GOV-01.1", - "GOV-04" + "II.5(1)(b)": [ + "PRI-01.11", + "PRI-02.1" ], - "3.1.8(a)": [ - "GOV-01.1", - "GOV-04" + "II.5(1)(c)": [ + "PRI-01.11", + "PRI-04" ], - "3.1.8(b)": [ - "GOV-01.1", - "GOV-04" + "II.5(1)(d)": [ + "PRI-01.11", + "PRI-05.2" ], - "3.1.8(c)": [ - "GOV-01.1", - "GOV-04" + "II.5(1)(e)": [ + "PRI-01.11", + "PRI-05" ], - "3.1.8(d)": [ - "GOV-01.1", - "GOV-04" + "II.5(2)": [ + "PRI-01.11", + "PRI-05.1" ], - "3.1.8(e)": [ - "GOV-01.1", - "GOV-04" + "II.5(3)": [ + "PRI-01.11", + "PRI-05.2" ], - "3.2.1": [ - "GOV-02" + "II.8(4)": [ + "PRI-01.11" ], - "3.2.2": [ - "GOV-03" + "II.8(1)": [ + "PRI-02" ], - "4.5.3": [ - "GOV-05", - "CPL-01.1", - "RSK-04.1", - "RSK-06.1" + "II.8(1)(a)": [ + "PRI-02" ], - "7.8.3": [ - "GOV-05", - "BCD-05", - "IRO-13" + "II.8(1)(b)": [ + "PRI-02" ], - "3.3.1": [ - "AST-01" + "II.8(1)(c)": [ + "PRI-02" ], - "3.3.1(a)": [ - "AST-01", - "AST-02" + "II.8(1)(d)": [ + "PRI-02" ], - "3.3.1(d)": [ - "AST-01" + "II.8(1)(e)": [ + "PRI-02" ], - "7.1.1": [ - "AST-01", - "OPS-01", - "OPS-03" + "II.8(1)(f)": [ + "PRI-02" ], - "11.4.1": [ - "AST-01", - "END-01" + "II.8(1)(g)": [ + "PRI-02" ], - "11.4.2": [ - "AST-01", - "END-01" + "II.8(1)(g)(i)": [ + "PRI-02" ], - "11.4.3": [ - "AST-01", - "END-01" + "II.8(1)(g)(ii)": [ + "PRI-02" ], - "3.3.1(c)": [ - "AST-01.2", - "DCH-01.1" + "II.8(1)(g)(iii)": [ + "PRI-02" ], - "3.3.2": [ - "AST-02" + "II.8(1)(h)": [ + "PRI-02" ], - "11.2.4": [ - "AST-02.5", - "NET-01", - "NET-08" + "II.8(1)(i)": [ + "PRI-02" ], - "11.1.7": [ - "AST-09", - "DCH-01", - "DCH-08", - "DCH-09", - "DCH-21", - "PRI-05" + "II.8(2)": [ + "PRI-02" ], - "11.3.7": [ - "AST-16" + "II.8(2)(a)": [ + "PRI-02" ], - "11.5.1": [ - "AST-23", - "EMB-01", - "EMB-02" + "II.8(2)(b)": [ + "PRI-02" ], - "8.1.1": [ - "BCD-01", - "CAP-01" + "IV.24(1)(a)": [ + "PRI-02" ], - "8.1.2": [ - "BCD-01", - "BCD-02" + "IV.24(1)(b)": [ + "PRI-02" ], - "8.1.3": [ - "BCD-01", - "CAP-03" + "IV.24(1)(b)(i)": [ + "PRI-02" ], - "8.1.4": [ - "BCD-01", - "BCD-01.4" + "IV.24(1)(b)(ii)": [ + "PRI-02" ], - "8.2.1": [ - "BCD-01", - "BCD-01.4" + "IV.24(1)(b)(iii)": [ + "PRI-02" ], - "8.2.2": [ - "BCD-01" + "IV.24(1)(b)(iv)": [ + "PRI-02" ], - "8.2.3": [ - "BCD-01", - "BCD-04" + "IV.24(1)(b)(v)": [ + "PRI-02" ], - "8.2.4": [ - "BCD-01", - "BCD-04.2" + "IV.24(1)(c)": [ + "PRI-02" ], - "8.5.1": [ - "BCD-01", - "PES-01" + "IV.24(1)(c)(i)": [ + "PRI-02" ], - "8.5.2": [ - "BCD-01", - "PES-01", - "PES-07" + "IV.24(1)(c)(ii)": [ + "PRI-02" ], - "8.5.2(a)": [ - "BCD-01", - "PES-07" + "IV.24(1)(c)(iii)": [ + "PRI-02" ], - "8.5.2(b)": [ - "BCD-01", - "PES-07" + "IV.24(1)(d)": [ + "PRI-02" ], - "8.5.2(c)": [ - "BCD-01", - "PES-07" + "IV.24(1)(e)": [ + "PRI-02" ], - "8.3.1": [ - "BCD-04" + "IV.24(1)(f)": [ + "PRI-02" ], - "8.3.2": [ - "BCD-04" + "IV.24(1)(g)": [ + "PRI-02" ], - "8.3.3(a)": [ - "BCD-04" + "V.45(8)": [ + "PRI-02" ], - "8.3.3(b)": [ - "BCD-04" + "V.52(3)": [ + "PRI-02" ], - "8.3.4": [ - "BCD-04", - "BCD-04.1" + "II.7(1)": [ + "PRI-03" ], - "7.8.1": [ - "BCD-05", - "IRO-13" + "IV.32(1)": [ + "PRI-03" ], - "7.8.2": [ - "BCD-05", - "IRO-13" + "IV.32(2)": [ + "PRI-03" ], - "8.4.1": [ - "BCD-11" + "IV.32(2)(a)": [ + "PRI-03" ], - "8.4.2": [ - "BCD-11" + "IV.32(2)(b)": [ + "PRI-03" ], - "8.4.3": [ - "BCD-11.1" + "IV.32(2)(c)": [ + "PRI-03" ], - "8.4.4": [ - "BCD-11.4" + "IV.32(3)": [ + "PRI-03" ], - "7.5.1": [ - "CHG-01" + "IV.32(4)": [ + "PRI-03" ], - "7.5.2": [ - "CHG-01", - "CHG-03" + "IV.32(5)": [ + "PRI-03" ], - "7.5.3": [ - "CHG-01", - "CHG-02.2" + "IV.32(6)": [ + "PRI-03" ], - "7.5.4": [ - "CHG-01", - "CHG-02.1", - "CHG-02.3" + "IV.36(2)": [ + "PRI-03" ], - "7.5.5": [ - "CHG-01", - "CHG-02.2", - "CHG-06" + "IV.35(1)": [ + "PRI-03.9" ], - "7.5.6": [ - "CHG-01" + "IV.35(1)(a)": [ + "PRI-03.9" ], - "7.5.7": [ - "CHG-01", - "CHG-02.2" + "IV.35(1)(b)": [ + "PRI-03.9" ], - "7.4.2": [ - "CHG-02.2", - "VPM-01", - "VPM-04.1", - "VPM-05", - "VPM-05.1", - "VPM-05.4" + "IV.36(1)": [ + "PRI-03.9" ], - "3.2.3": [ - "CPL-01", - "CPL-01.1", - "CPL-02" + "IV.33(1)": [ + "PRI-03.13" ], - "4.5.2": [ - "CPL-01.1", - "IAO-05", - "RSK-04.1" + "IV.33(2)": [ + "PRI-03.13" ], - "15.1.1": [ - "CPL-02.1" + "IV.33(3)": [ + "PRI-03.13" ], - "15.1.2": [ - "CPL-02.1" + "IV.33(4)": [ + "PRI-03.13" ], - "15.1.3": [ - "CPL-02.1" + "IV.33(4)(a)": [ + "PRI-03.13" ], - "15.1.4": [ - "CPL-02.1" + "IV.33(4)(b)": [ + "PRI-03.13" ], - "4.5.1": [ - "CPL-03", - "CPL-03.2", - "SEA-01.1" + "IV.33(4)(c)": [ + "PRI-03.13" ], - "7.2.1": [ - "CFG-01" + "IV.35(2)": [ + "PRI-04.1" ], - "7.2.2": [ - "CFG-01" + "IV.35(2)(a)": [ + "PRI-04.1" ], - "7.3.1": [ - "CFG-01", - "SEA-07.1", - "TDA-17" + "IV.35(2)(b)": [ + "PRI-04.1" ], - "7.3.2": [ - "CFG-01", - "SEA-07.1", - "TDA-17" + "IV.36(3)": [ + "PRI-04.1" ], - "7.3.3": [ - "CFG-01", - "SEA-07.1", - "TDA-17" + "IV.36(3)(a)": [ + "PRI-04.1" ], - "11.2.5": [ - "CFG-02", - "CFG-02.1", - "NET-01", - "NET-03", - "NET-04.6" + "IV.36(3)(b)": [ + "PRI-04.1" ], - "11.3.1": [ - "CFG-02", - "END-01" + "IV.36(3)(c)": [ + "PRI-04.1" ], - "11.3.2": [ - "CFG-02", - "CFG-02.2", - "END-01" + "IV.36(3)(c)(i)": [ + "PRI-04.1" ], - "5.7.3": [ - "CFG-02.4", - "TDA-07", - "TDA-08", - "TDA-09" + "IV.36(3)(c)(ii)": [ + "PRI-04.1" ], - "11.3.6": [ - "CFG-03.3" + "II.9(1)": [ + "PRI-05" ], - "6.1.3": [ - "CFG-04.1", - "TDA-01", - "TDA-03", - "TDA-06.5", - "TDA-09" + "II.9(1)(a)": [ + "PRI-05" ], - "12.2.1": [ - "MON-01", - "MON-01.16", - "OPS-04" + "II.9(1)(b)": [ + "PRI-05" ], - "12.2.2": [ - "MON-01", - "MON-01.8", - "MON-01.16" + "II.9(1)(c)": [ + "PRI-05" ], - "12.2.3": [ - "MON-01", - "MON-01.16" + "II.10(1)": [ + "PRI-05.2" ], - "9.1.3": [ - "MON-02", - "IAC-01" + "II.10(2)": [ + "PRI-05.2" ], - "12.2.5": [ - "MON-02.1" + "II.10(2)(a)": [ + "PRI-05.2" ], - "12.2.6": [ - "MON-02.2", - "MON-06" + "II.10(2)(b)": [ + "PRI-05.2" ], - "9.2.2": [ - "MON-03.2", - "MON-16", - "SAT-03.2" + "IV.29(2)": [ + "PRI-05.4" ], - "14.2.1": [ - "MON-09" + "IV.29(2)(a)": [ + "PRI-05.4" ], - "14.2.2": [ - "MON-09" + "IV.29(2)(b)": [ + "PRI-05.4" ], - "14.2.3": [ - "MON-09" + "IV.29(2)(c)": [ + "PRI-05.4" ], - "14.2.4": [ - "MON-09" + "IV.29(2)(d)": [ + "PRI-05.4" ], - "14.2.5": [ - "MON-09" + "IV.34(1)": [ + "PRI-05.4" ], - "14.2.6": [ - "MON-09" + "IV.34(2)": [ + "PRI-05.4" ], - "14.2.7": [ - "MON-09" + "IV.34(2)(a)": [ + "PRI-05.4" ], - "14.2.8": [ - "MON-09" + "IV.34(2)(b)": [ + "PRI-05.4" ], - "14.2.9": [ - "MON-09" + "IV.34(2)(c)": [ + "PRI-05.4" ], - "14.2.10": [ - "MON-09" + "IV.34(2)(d)": [ + "PRI-05.4" ], - "14.2.11": [ - "MON-09" + "IV.34(2)(e)": [ + "PRI-05.4" ], - "11.3.5": [ - "MON-11.3", - "END-01", - "END-04.3" + "IV.34(2)(e)(i)": [ + "PRI-05.4" ], - "11.5.5": [ - "MON-16", - "EMB-01", - "EMB-02", - "EMB-05", - "SAT-03.2" + "IV.34(2)(e)(ii)": [ + "PRI-05.4" ], - "12.2.4": [ - "MON-16", - "SAT-03.2" + "IV.34(2)(f)": [ + "PRI-05.4" ], - "3.5.2": [ - "MON-16.1", - "HRS-01", - "HRS-02.1", - "HRS-04", - "HRS-04.1" + "IV.34(2)(g)": [ + "PRI-05.4" ], - "10.1.1": [ - "CRY-01" + "IV.34(2)(h)": [ + "PRI-05.4" ], - "10.1.2": [ - "CRY-01" + "IV.34(2)(i)": [ + "PRI-05.4" ], - "10.1.3": [ - "CRY-01" + "IV.34(2)(j)": [ + "PRI-05.4" ], - "10.1.4": [ - "CRY-01" + "IV.34(2)(k)": [ + "PRI-05.4" ], - "10.1.5": [ - "CRY-01" + "IV.34(2)(l)": [ + "PRI-05.4" ], - "10.2.1": [ - "CRY-09" + "IV.34(2)(m)": [ + "PRI-05.4" ], - "10.2.2": [ - "CRY-09" + "IV.34(2)(n)": [ + "PRI-05.4" ], - "10.2.3": [ - "CRY-09" + "IV.34(2)(n)(i)": [ + "PRI-05.4" ], - "10.2.4": [ - "CRY-09" + "IV.34(2)(n)(ii)": [ + "PRI-05.4" ], - "10.2.5": [ - "CRY-09", - "CRY-09.4" + "IV.34(2)(n)(iii)": [ + "PRI-05.4" ], - "10.2.6": [ - "CRY-09" + "IV.34(2)(n)(iv)": [ + "PRI-05.4" ], - "10.2.7": [ - "CRY-09" + "IV.34(2)(o)": [ + "PRI-05.4" ], - "10.2.8": [ - "CRY-09" + "IV.34(2)(o)(a)": [ + "PRI-05.4" ], - "10.2.9": [ - "CRY-09" + "IV.34(2)(o)(b)": [ + "PRI-05.4" ], - "10.2.10": [ - "CRY-09" + "IV.34(2)(p)": [ + "PRI-05.4" ], - "11.1.1": [ - "DCH-01" + "IV.34(2)(p)(i)": [ + "PRI-05.4" ], - "11.1.1(a)": [ - "DCH-01" + "IV.34(2)(p)(ii)": [ + "PRI-05.4" ], - "11.1.1(b)": [ - "DCH-01" + "IV.34(2)(p)(ii)(aa)": [ + "PRI-05.4" ], - "11.1.1(c)": [ - "DCH-01" + "IV.34(2)(p)(ii)(bb)": [ + "PRI-05.4" ], - "11.1.2": [ - "DCH-01" + "IV.34(2)(p)(ii)(cc)": [ + "PRI-05.4" ], - "11.1.3": [ - "DCH-01" + "IV.34(2)(p)(ii)(dd)": [ + "PRI-05.4" ], - "11.1.4": [ - "DCH-01" + "IV.34(2)(p)(ii)(ee)": [ + "PRI-05.4" ], - "11.1.5": [ - "DCH-01" + "IV.34(2)(p)(iii)": [ + "PRI-05.4" ], - "11.1.6": [ - "DCH-01", - "IAC-08", - "TDA-10" + "IV.34(2)(q)": [ + "PRI-05.4" ], - "3.3.1(b)": [ - "DCH-02" + "IV.34(2)(q)(i)": [ + "PRI-05.4" ], - "5.8.1": [ - "DCH-22", - "PRM-04", - "TDA-01.1" + "IV.34(2)(q)(ii)": [ + "PRI-05.4" ], - "5.8.2": [ - "DCH-22", - "PRM-04", - "TDA-01.1" + "IV.34(2)(q)(iii)": [ + "PRI-05.4" ], - "11.5.2": [ - "EMB-01", - "EMB-02" + "IV.34(2)(r)": [ + "PRI-05.4" ], - "11.5.3": [ - "EMB-01", - "EMB-02" + "IV.34(2)(s)": [ + "PRI-05.4" ], - "11.5.4": [ - "EMB-01", - "EMB-02" + "IV.34(4)": [ + "PRI-05.4" ], - "11.3.3": [ - "END-01", - "END-04" + "IV.34(4)(a)": [ + "PRI-05.4" ], - "11.3.4": [ - "END-01", - "END-04.1" + "IV.34(4)(b)": [ + "PRI-05.4" ], - "14.1.6": [ - "END-08", - "PRI-01.6" + "IV.34(5)": [ + "PRI-05.4" ], - "3.5.1": [ - "HRS-01", - "HRS-03.2" + "IV.34(5)(a)": [ + "PRI-05.4" ], - "6.1.5": [ - "HRS-02.1", - "HRS-03.2", - "SAT-01", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "TDA-01", - "TDA-02.3", - "TDA-05", - "TDA-14", - "TDA-16" + "IV.34(5)(b)": [ + "PRI-05.4" ], - "9.1.1": [ - "HRS-11", - "IAC-21" + "IV.34(5)(c)": [ + "PRI-05.4" ], - "9.1.2": [ - "IAC-01" + "IV.34(5)(d)": [ + "PRI-05.4" ], - "9.1.8": [ - "IAC-01", - "IAC-05", - "TPM-01" + "IV.34(6)": [ + "PRI-05.4" ], - "9.1.5": [ - "IAC-06" + "V.43(4)(b)": [ + "PRI-05.7", + "PRI-14" ], - "9.1.7": [ - "IAC-08" + "IV.27(1)": [ + "PRI-06" ], - "9.1.4": [ - "IAC-10.1" + "IV.29(1)": [ + "PRI-06" ], - "9.2.1": [ - "IAC-16" + "IV.29(1)(a)": [ + "PRI-06" ], - "9.1.6": [ - "IAC-17" + "IV.29(1)(b)": [ + "PRI-06" ], - "7.7.1": [ - "IRO-01" + "IV.29(1)(c)": [ + "PRI-06" ], - "7.7.2": [ - "IRO-01" + "IV.29(1)(d)": [ + "PRI-06" ], - "7.7.3(a)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "IV.29(1)(e)": [ + "PRI-06" ], - "7.7.3(b)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "IV.29(1)(f)": [ + "PRI-06" ], - "7.7.3(c)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "IV.30(1)": [ + "PRI-06" ], - "7.7.4": [ - "IRO-01" + "IV.30(1)(a)": [ + "PRI-06" ], - "7.7.5": [ - "IRO-01", - "IRO-07", - "IRO-09", - "IRO-10", - "IRO-16" + "IV.30(1)(b)": [ + "PRI-06" ], - "7.7.6": [ - "IRO-01", - "IRO-10", - "IRO-16" + "IV.30(2)": [ + "PRI-06" ], - "7.7.7": [ - "IRO-01", - "IRO-10", - "IRO-16" + "IV.30(2)(a)": [ + "PRI-06" ], - "12.3.1": [ - "IRO-04" + "IV.30(2)(b)": [ + "PRI-06" ], - "12.3.2": [ - "IRO-04" + "IV.30(3)": [ + "PRI-06" ], - "12.3.3": [ - "IRO-04", - "IRO-13" + "IV.26(1)": [ + "PRI-06.1" ], - "5.1.2": [ - "IAO-01", - "PRM-01", - "PRM-02", - "PRM-04", - "PRM-05", - "PRM-07" + "IV.26(2)": [ + "PRI-06.1" ], - "5.4.1": [ - "IAO-01", - "PRM-04", - "PRM-07" + "IV.26(3)(a)": [ + "PRI-06.2" ], - "5.4.2": [ - "IAO-01", - "PRM-04", - "PRM-07" + "IV.26(3)(b)": [ + "PRI-06.2" ], - "5.4.3": [ - "IAO-01", - "IAO-03.2", - "PRM-04", - "PRM-07" + "IV.24(4)": [ + "PRI-06.4" ], - "5.4.4": [ - "IAO-01", - "PRM-04", - "PRM-07" + "IV.24(4)(a)": [ + "PRI-06.4" ], - "5.6.1": [ - "IAO-01", - "PRM-05", - "SEA-01", - "SEA-02", - "SEA-03" + "IV.24(4)(b)": [ + "PRI-06.4" ], - "5.6.2": [ - "IAO-01", - "PRM-05", - "SEA-01", - "SEA-02", - "SEA-03" + "IV.24(5)": [ + "PRI-06.4" ], - "5.6.3": [ - "IAO-01", - "PRM-05", - "SEA-01", - "SEA-02", - "SEA-03" + "IV.24(5)(a)": [ + "PRI-06.4" ], - "5.7.1": [ - "IAO-01", - "IAO-01.1", - "IAO-02", - "TDA-09" + "IV.24(5)(b)": [ + "PRI-06.4" ], - "5.7.2": [ - "IAO-01", - "IAO-01.1", - "IAO-02", - "TDA-09" + "IV.24(10)": [ + "PRI-06.4" ], - "5.7.4": [ - "IAO-02.2", - "TDA-06.5", - "TDA-09" + "IV.24(10)(a)": [ + "PRI-06.4" ], - "5.7.6": [ - "IAO-02.4", - "TDA-09" + "IV.24(10)(b)": [ + "PRI-06.4" ], - "5.7.5": [ - "IAO-04", - "TDA-09" + "IV.24(10)(c)": [ + "PRI-06.4" ], - "14.1.7": [ - "MDM-04", - "MDM-06", - "MDM-07", - "PRI-01.6" + "IV.24(10)(d)": [ + "PRI-06.4" ], - "11.2.1": [ - "NET-01" + "IV.24(13)(f)": [ + "PRI-06.4" ], - "11.2.2": [ - "NET-01" + "IV.27(3)": [ + "PRI-06.4" ], - "11.2.3": [ - "NET-01", - "NET-08" + "IV.28(5)(a)": [ + "PRI-06.4" ], - "11.2.6": [ - "NET-01", - "NET-03", - "NET-03.7", - "NET-06" + "IV.28(5)(b)": [ + "PRI-06.4" ], - "11.2.7": [ - "NET-01", - "NET-02.1" + "IV.29(3)(a)": [ + "PRI-06.4" ], - "11.2.8": [ - "NET-01", - "SEA-01", - "SEA-02", - "SEA-03" + "IV.29(3)(b)": [ + "PRI-06.4" ], - "9.3.1": [ - "NET-14", - "NET-14.5" + "IV.28(1)": [ + "PRI-06.5" ], - "9.3.2": [ - "NET-14", - "NET-14.5" + "IV.28(2)": [ + "PRI-06.5" ], - "8.5.5": [ - "PES-01", - "PES-05.2" + "IV.28(2)(a)": [ + "PRI-06.5" ], - "8.5.6(a)": [ - "PES-01", - "PES-02" + "IV.28(2)(b)": [ + "PRI-06.5" ], - "8.5.6(b)": [ - "PES-01", - "PES-06" + "IV.28(2)(c)": [ + "PRI-06.5" ], - "8.5.6(c)": [ - "PES-01", - "PES-03" + "IV.28(2)(d)": [ + "PRI-06.5" ], - "8.5.6(d)": [ - "PES-01", - "PES-03.2", - "PES-03.4" + "IV.28(2)(e)": [ + "PRI-06.5" ], - "8.5.6(e)": [ - "PES-01", - "PES-04", - "PES-04.1" + "IV.28(4)": [ + "PRI-06.5" ], - "8.5.6(f)": [ - "PES-01" + "IV.28(4)(a)": [ + "PRI-06.5" ], - "5.5.6(f)": [ - "PES-03", - "PES-03.1", - "PES-04.1", - "PES-06", - "PES-10" + "IV.28(4)(b)": [ + "PRI-06.5" ], - "5.5.5": [ - "PES-05" + "IV.28(4)(c)": [ + "PRI-06.5" ], - "8.5.3": [ - "PES-08", - "PES-08.1" + "IV.28(4)(d)": [ + "PRI-06.5" ], - "8.5.4": [ - "PES-08", - "PES-08.1" + "IV.28(4)(e)": [ + "PRI-06.5" ], - "14.1.1": [ - "PRI-01.6" + "VI.53(1)": [ + "PRI-07" ], - "14.1.2": [ - "PRI-01.6" + "VI.54": [ + "PRI-07" ], - "14.1.3": [ - "PRI-01.6" + "VI.54(a)": [ + "PRI-07" ], - "14.1.4": [ - "PRI-01.6" + "VI.54(b)": [ + "PRI-07" ], - "14.1.5": [ - "PRI-01.6" + "VI.54(b)(i)": [ + "PRI-07" ], - "5.1.1": [ - "PRM-01", - "PRM-02", - "PRM-04", - "PRM-05" + "VI.54(b)(ii)": [ + "PRI-07" ], - "5.1.3": [ - "PRM-01", - "PRM-02", - "PRM-04", - "PRM-05", - "PRM-07", - "RSK-08", - "RSK-10" + "VI.54(b)(iii)": [ + "PRI-07" ], - "5.1.4": [ - "PRM-01", - "PRM-02", - "PRM-04", - "PRM-05", - "PRM-07" + "VI.54(b)(iv)": [ + "PRI-07" ], - "5.2.1": [ - "PRM-02", - "PRM-03", - "PRM-04" + "VI.54(b)(v)": [ + "PRI-07" ], - "5.2.2": [ - "PRM-02", - "PRM-03", - "PRM-04" + "VI.54(b)(vi)": [ + "PRI-07" ], - "5.5.1": [ - "PRM-02", - "PRM-05", - "PRM-06" + "VI.54(c)": [ + "PRI-07" ], - "5.5.2": [ - "PRM-02", - "PRM-05", - "PRM-06" + "V.51(1)(b)": [ + "PRI-07.1" ], - "5.3.3": [ - "PRM-05", - "RSK-08", - "RSK-10", - "TDA-02", - "TDA-03" + "V.51(1)(b)(i)": [ + "PRI-07.1" ], - "4.1.1": [ - "RSK-01" + "V.51(1)(b)(ii)": [ + "PRI-07.1" ], - "4.1.2": [ - "RSK-01" + "V.51(1)(b)(iii)": [ + "PRI-07.1" ], - "4.1.5": [ - "RSK-01", - "RSK-06.1", - "RSK-07" + "V.51(1)(b)(iv)": [ + "PRI-07.1" ], - "4.2.1": [ - "RSK-01.1", - "RSK-02", - "RSK-02.1", - "RSK-05", - "RSK-06.2", - "THR-01", - "VPM-01" + "V.51(2)(a)": [ + "PRI-07.1" ], - "4.3.2": [ - "RSK-01.1", - "RSK-02.1", - "RSK-04" + "V.51(2)(b)": [ + "PRI-07.1" ], - "4.3.1": [ - "RSK-02.1" + "V.51(2)(c)": [ + "PRI-07.1" ], - "4.1.3": [ - "RSK-03", - "RSK-04.1", - "RSK-06" + "V.51(2)(d)": [ + "PRI-07.1" ], - "4.1.4(a)": [ - "RSK-03" + "V.51(2)(e)": [ + "PRI-07.1" ], - "4.1.4(b)": [ - "RSK-04" + "V.51(2)(f)": [ + "PRI-07.1" ], - "4.1.4(d)": [ - "RSK-04.1" + "V.51(2)(g)": [ + "PRI-07.1" ], - "4.1.4(c)": [ - "RSK-06" + "V.51(2)(h)": [ + "PRI-07.1" ], - "4.4.1": [ - "RSK-06" + "V.51(3)": [ + "PRI-07.1" ], - "4.4.2": [ - "RSK-06", - "RSK-06.2" + "V.51(4)": [ + "PRI-07.1" ], - "4.4.3": [ - "RSK-06", - "RSK-06.2" + "V.51(5)": [ + "PRI-07.1" ], - "13.6.1": [ - "RSK-06" + "V.51(5)(a)": [ + "PRI-07.1" ], - "13.6.1(a)": [ - "RSK-06", - "VPM-02", - "VPM-04" + "V.51(5)(b)": [ + "PRI-07.1" ], - "13.6.1(b)": [ - "RSK-06", - "VPM-02", - "VPM-04", - "VPM-05.3" + "V.51(6)": [ + "PRI-07.1" ], - "13.6.1(c)": [ - "RSK-06", - "VPM-02", - "VPM-04" + "V.51(7)": [ + "PRI-07.1" ], - "5.3.1": [ - "RSK-09", - "TDA-01" + "V.51(8)": [ + "PRI-07.1" ], - "3.6.1": [ - "SAT-01", - "SAT-02" + "V.43(1)": [ + "PRI-14" ], - "3.6.4": [ - "SAT-01" + "V.43(2)": [ + "PRI-14" ], - "3.6.2": [ - "SAT-03", - "SAT-03.3" + "V.43(2)(a)": [ + "PRI-14" ], - "3.6.3": [ - "SAT-03", - "SAT-03.3" + "V.43(2)(b)": [ + "PRI-14" ], - "5.3.2": [ - "TDA-01", - "TDA-06" + "V.43(2)(c)": [ + "PRI-14" ], - "6.1.1": [ - "TDA-01", - "TDA-06", - "TDA-06.3", - "TDA-06.5", - "TDA-09" + "V.43(2)(d)": [ + "PRI-14" ], - "6.1.2": [ - "TDA-01", - "TDA-06", - "TDA-06.3", - "TDA-06.5", - "TDA-09" + "V.43(2)(e)": [ + "PRI-14" ], - "6.1.4": [ - "TDA-01", - "TDA-02.3", - "TDA-04", - "TDA-06.5", - "TDA-09", - "TDA-09.1" + "V.43(2)(f)": [ + "PRI-14" ], - "6.1.6": [ - "TDA-01", - "TDA-02.3", - "TDA-06.5", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TDA-15" + "V.43(2)(g)": [ + "PRI-14" ], - "6.1.7": [ - "TDA-01", - "TDA-02.3", - "TDA-06.5", - "TDA-09" + "V.43(2)(h)": [ + "PRI-14" ], - "6.2.1": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.43(2)(i)": [ + "PRI-14" ], - "6.2.2": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.43(2)(j)": [ + "PRI-14" ], - "6.3.1": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.43(3)": [ + "PRI-14" ], - "6.3.2": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.43(4)": [ + "PRI-14" ], - "6.4.1": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.43(4)(a)": [ + "PRI-14" ], - "6.4.2": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.43(4)(c)": [ + "PRI-14", + "PRI-14.1" ], - "6.4.3": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.46(3)": [ + "PRI-14.2" ], - "6.4.4": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.46(3)(a)": [ + "PRI-14.2" ], - "6.4.5": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.46(3)(b)": [ + "PRI-14.2" ], - "6.4.6": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.46(3)(c)": [ + "PRI-14.2" ], - "6.4.7": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.46(3)(d)": [ + "PRI-14.2" ], - "6.4.8": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.41(1)": [ + "PRI-15" ], - "6.5.1": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.41(1)(a)": [ + "PRI-15" ], - "6.5.2": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.41(1)(b)": [ + "PRI-15" ], - "6.5.3": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "V.41(1)(c)": [ + "PRI-15" ], - "7.6.1": [ - "TDA-01.1", - "TDA-06.3" + "V.41(1)(d)": [ + "PRI-15" ], - "7.6.2": [ - "TDA-01.1", - "TDA-06.3" + "V.41(1)(e)": [ + "PRI-15" ], - "14.4.1": [ - "TDA-01.1" + "V.41(1)(f)": [ + "PRI-15" ], - "14.4.2": [ - "TDA-01.1" + "V.41(1)(g)": [ + "PRI-15" ], - "14.4.3": [ - "TDA-01.1" + "V.41(2)": [ + "PRI-15" ], - "5.3.4": [ - "TDA-20.3" + "V.41(3)": [ + "PRI-15" ], - "3.4.1": [ - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-05" + "IV.24(2)": [ + "PRI-17" ], - "3.4.2": [ - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-05" + "IV.24(2)(a)": [ + "PRI-17" ], - "3.4.3": [ - "TPM-01", - "TPM-05", - "TPM-08" + "IV.24(2)(b)": [ + "PRI-17" ], - "13.5.1": [ - "THR-01" + "IV.36(4)": [ + "PRI-17" ], - "13.5.2": [ - "THR-01" + "IV.36(4)(a)": [ + "PRI-17" ], - "14.3.1": [ - "THR-01", - "THR-02" + "IV.36(4)(b)": [ + "PRI-17" ], - "14.3.2": [ - "THR-01", - "THR-02" + "IV.24(3)": [ + "PRI-19" ], - "14.3.3": [ - "THR-01", - "THR-02" + "V.49(1)": [ + "PRI-19" ], - "12.1.1": [ - "THR-03" + "V.49(2)": [ + "PRI-19" ], - "12.1.2": [ - "THR-03" + "V.49(2)(a)": [ + "PRI-19" ], - "12.1.3": [ - "THR-03" + "V.49(2)(b)": [ + "PRI-19" ], - "13.2.2": [ - "THR-06" + "V.49(2)(c)": [ + "PRI-19" ], - "7.4.1": [ - "VPM-01", - "VPM-04.1", - "VPM-05", - "VPM-05.1", - "VPM-05.4" + "V.49(3)": [ + "PRI-19" ], - "13.1.2": [ - "VPM-01.1", - "VPM-06" + "V.49(4)": [ + "PRI-19" ], - "13.1.1": [ - "VPM-06" + "V.49(4)(a)": [ + "PRI-19" ], - "13.2.1": [ - "VPM-07" + "V.49(4)(b)": [ + "PRI-19" ], - "13.2.3": [ - "VPM-07" + "IV.24(3)(a)": [ + "PRI-19.3" ], - "13.2.4": [ - "VPM-07" + "IV.24(3)(b)": [ + "PRI-19.3" ], - "13.3.1": [ - "VPM-10" + "IV.24(3)(c)": [ + "PRI-19.3" ], - "13.3.2": [ - "VPM-10" + "IV.24(3)(d)": [ + "PRI-19.3" ], - "13.4.1": [ - "VPM-10" + "V.50(1)": [ + "RSK-10" ], - "13.4.2": [ - "VPM-10" - ] - }, - "apac-kor-pipa-2011": { - "3": [ - "GOV-01", - "CPL-01", - "PRI-01", - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.2", - "PRI-05.3", - "SEA-01", - "SEA-02", - "SEA-03" + "V.50(1)(a)": [ + "RSK-10" ], - "4": [ - "DCH-22.1", - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-05", - "PRI-06", - "PRI-06.1", - "PRI-06.2" + "V.50(1)(b)": [ + "RSK-10" ], - "15": [ - "PRI-04", - "PRI-04.1", - "PRI-05" + "V.50(2)": [ + "RSK-10" ], - "16": [ - "PRI-05.4" + "V.50(2)(a)": [ + "RSK-10" ], - "17": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "SEA-15", - "TPM-04.4" + "V.50(2)(b)": [ + "RSK-10" ], - "18": [ - "PRI-05.4" + "V.50(2)(c)": [ + "RSK-10" ], - "19": [ - "PRI-05" + "V.50(3)": [ + "RSK-10" ], - "21": [ - "PRI-05" + "V.50(3)(a)": [ + "RSK-10" ], - "22": [ - "PRI-03", - "PRI-03.2", - "PRI-04" + "V.50(3)(b)": [ + "RSK-10" ], - "23": [ - "PRI-05.4" + "V.50(3)(c)": [ + "RSK-10" ], - "26": [ - "DCH-25", - "PRI-07", - "PRI-07.1" + "V.50(3)(d)": [ + "RSK-10" ], - "27": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "PRI-07.1", - "SEA-15", - "TPM-04.4" + "V.50(4)": [ + "RSK-10" ], - "29": [ - "GOV-01", - "CPL-01", - "SEA-01", - "SEA-02", - "SEA-03" + "V.50(5)": [ + "RSK-10" ], - "30": [ - "GOV-01", - "PRI-01" + "V.50(6)": [ + "RSK-10" ], - "31": [ - "PRI-01.1" + "V.50(7)": [ + "RSK-10" ], - "32": [ - "PRI-15" + "V.50(8)": [ + "RSK-10" ], - "33": [ - "PRI-05.5", - "RSK-08", + "V.50(8)(a)": [ "RSK-10" ], - "34": [ - "IRO-04", - "IRO-04.1" + "V.50(8)(b)": [ + "RSK-10" ], - "35": [ - "PRI-06" + "V.50(8)(c)": [ + "RSK-10" ], - "36": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "V.50(8)(d)": [ + "RSK-10" ], - "37": [ - "PRI-05", - "PRI-06.4" + "V.50(8)(e)": [ + "RSK-10" ], - "38": [ - "PRI-06.3" + "V.50(8)(f)": [ + "RSK-10" ] }, - "apac-twn-pdpa-2025": { - "3": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" + "americas-bmu-mba-coc-2020": { + "6.1": [ + "GOV-01" ], - "5": [ - "PRI-02", - "PRI-02.1", - "PRI-02.2", - "PRI-03", - "PRI-03.1", - "PRI-03.2", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.4" + "5.1": [ + "GOV-01.1" ], - "12": [ - "IRO-04.1" + "5.3": [ + "GOV-02", + "RSK-01" ], - "19": [ - "PRI-02.1", - "PRI-04", - "PRI-04.1", - "PRI-05" + "7.1": [ + "GOV-02", + "BCD-01", + "BCD-01.7" ], - "21": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "5.2": [ + "GOV-04" ], - "27": [ - "GOV-01", - "CPL-01", - "CPL-02", - "PRM-05" + "5.3-BP2": [ + "GOV-10", + "GOV-15", + "DCH-02" ], - "Inferred": [ - "PRI-01" + "5.11-BP4": [ + "GOV-15", + "RSK-06.2" ], - "Expectation": [ - "PRI-01" - ] - }, - "americas-arg-ppd-2018": { - "6": [ - "PRI-02.1", - "PRI-04" + "5.9": [ + "AST-02" ], - "8": [ - "PRI-04.1" + "5.9-BP1": [ + "AST-03" ], - "13": [ - "PRI-06" + "5.9-BP2": [ + "AST-03", + "DCH-02" ], - "24": [ - "PRI-15" + "6.3": [ + "BCD-01", + "IRO-01" ], - "12.1": [ - "CLD-09", - "PRI-07" + "7.1-BP2": [ + "BCD-04" ], - "12.2": [ - "CLD-09" + "6.14": [ + "BCD-11", + "BCD-11.5" ], - "10.1": [ - "CPL-01" + "6.1-BP5": [ + "CAP-01" ], - "10.2": [ - "CPL-01" + "6.1-BP2": [ + "CHG-01" ], - "4.7": [ - "DCH-09.3" + "5.11": [ + "CLD-01", + "CLD-06.1", + "RSK-04" ], - "16.7": [ - "DCH-09.3", - "PRI-06.5" + "5.11-BP3": [ + "CPL-01.2", + "CPL-01.4" ], - "25.2": [ - "DCH-09.3" + "5.7-BP3": [ + "CPL-01.4" ], - "16.1": [ - "DCH-22.1", - "PRI-06.1" + "6.10": [ + "CPL-01.4" ], - "16.3": [ - "DCH-22.1", - "PRI-06.1" + "5.4": [ + "CPL-02" ], - "27.1": [ - "PRI-02.1" + "5.6": [ + "CPL-02" ], - "27.2": [ - "PRI-02.1" + "5.7-BP2": [ + "CPL-02" ], - "28.1": [ - "PRI-02.1" + "5.7": [ + "CPL-03" ], - "5.1": [ - "PRI-03", - "PRI-05" + "6.21": [ + "CPL-03", + "MON-01" ], - "5.2": [ - "PRI-03", - "PRI-04.1" + "6.22": [ + "CPL-03", + "CRY-01" ], - "27.3": [ - "PRI-03.2" + "5.7-BP1": [ + "CPL-03.2" ], - "4.1": [ - "PRI-04" + "6.1-BP1": [ + "CFG-01" ], - "4.2": [ - "PRI-04" + "6.15-BP5": [ + "CFG-02" ], - "7.1": [ - "PRI-04.1" + "6.21-BP6": [ + "MON-01.4", + "MON-03" ], - "7.2": [ - "PRI-04.1" + "6.21-BP5": [ + "MON-01.8" ], - "7.4": [ - "PRI-04.1" + "6.21-BP2": [ + "MON-03.1", + "MON-08.3" ], - "4.3": [ - "PRI-05", - "PRI-05.4" + "6.21-BP3": [ + "MON-08" ], - "9.2": [ - "PRI-05", - "PRI-05.1" + "6.21-BP1": [ + "MON-10" ], - "7.3": [ - "PRI-05.1" + "6.21-BP4": [ + "MON-16" ], - "4.5": [ - "PRI-05.2" + "5.3-BP3": [ + "DCH-01", + "IRO-01", + "SEA-01" ], - "4.4": [ - "PRI-05.3" + "6.13": [ + "DCH-01.2" ], - "4.6": [ - "PRI-06" + "6.8": [ + "DCH-02" ], - "14.1": [ - "PRI-06" + "5.9-BP3": [ + "DCH-03.1" ], - "14.2": [ - "PRI-06" + "6.17": [ + "DCH-09", + "DCH-09.1" ], - "14.3": [ - "PRI-06" + "5.5": [ + "DCH-18", + "RSK-04" ], - "14.4": [ - "PRI-06" + "6.12": [ + "END-04" ], - "16.2": [ - "PRI-06.2", - "PRI-06.4" + "5.13": [ + "HRS-04" ], - "16.6": [ - "PRI-06.4" + "6.6": [ + "HRS-11", + "IAC-01", + "IAC-08", + "IAC-15", + "IAC-21.3", + "IAC-28.1" ], - "16.5": [ - "PRI-06.5" + "6.1-BP4": [ + "IRO-01" ], - "15.1": [ - "PRI-06.6" + "6.4": [ + "IRO-01", + "IRO-02", + "IRO-02.4", + "IRO-04", + "IRO-06", + "IRO-07", + "IRO-10", + "IRO-13" ], - "15.2": [ - "PRI-06.6" + "6.5": [ + "IRO-10.5" ], - "15.3": [ - "PRI-06.6" + "6.5(a)": [ + "IRO-10.5" ], - "11.1": [ - "PRI-07" + "6.5(b)": [ + "IRO-10.5" ], - "11.2": [ - "PRI-07" + "6.5(c)": [ + "IRO-10.5" ], - "11.3": [ - "PRI-07" + "6.5(d)": [ + "IRO-10.5" ], - "11.4": [ - "PRI-07", - "PRI-07.1" + "6.5(e)": [ + "IRO-10.5" ], - "16.4": [ - "PRI-07" + "6.15": [ + "IAO-01" ], - "21.1": [ - "PRI-15" + "6.15-BP2": [ + "IAO-02" ], - "21.2": [ - "PRI-15" + "6.11": [ + "MDM-01" ], - "21.3": [ - "PRI-15" + "6.18": [ + "NET-02", + "NET-06", + "NET-08", + "WEB-02" ], - "9.1": [ - "SEA-01.1" + "6.19": [ + "NET-02.1", + "RSK-04" ], - "25.1": [ - "TPM-04" - ] - }, - "americas-bhs-dpa-2003": { - "6": [ - "GOV-01", - "CPL-01", - "PRI-01", - "PRI-02.1", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.2", - "SEA-01", - "SEA-02", - "SEA-03" + "6.9": [ + "NET-17", + "PRM-06" ], - "8": [ - "PRI-06" + "5.14": [ + "PRM-04", + "PRM-05", + "RSK-08" ], - "10": [ - "DCH-22.1", - "PRI-06.1" + "6.20": [ + "PRM-07", + "TDA-06" ], - "11": [ - "PRI-06.2", - "PRI-06.4" + "5.11-BP1": [ + "RSK-01" ], - "12": [ - "PRI-05", - "PRI-05.4", - "SEA-01", - "SEA-02", - "SEA-03" - ] - }, - "americas-bmu-mba-coc-2020": { - "4": [ - "GOV-01", - "SEA-01", - "SEA-02", - "SEA-03" + "5.3-BP1": [ + "RSK-03", + "RSK-04", + "RSK-06" ], - "5.4": [ - "GOV-01", - "CPL-02.1" + "5.5-BP1": [ + "RSK-03" ], - "5.1": [ - "GOV-01.1" + "5.5-BP2": [ + "RSK-04" ], - "5.6": [ - "GOV-01.1", - "CPL-02.1" + "6.19-BP1": [ + "RSK-04" + ], + "6.19-BP2": [ + "RSK-04" + ], + "6.19-BP3": [ + "RSK-04" + ], + "5.5-BP4": [ + "RSK-04.1" + ], + "5.5-BP3": [ + "RSK-06" + ], + "5.8": [ + "RSK-06.3" ], - "5.2": [ - "GOV-04" + "7.1-BP1": [ + "RSK-08" ], - "5.7": [ - "GOV-05", - "CPL-01.1", - "CPL-02", - "CPL-03.2" + "5.9-BP4": [ + "OPS-01.1" ], - "5.9": [ - "AST-01", - "AST-02" + "6.7": [ + "SAT-02" ], - "6.14": [ - "BCD-01", - "BCD-11" + "6.1-BP3": [ + "TDA-01" ], - "7.1": [ - "BCD-01" + "5.12": [ + "TDA-02.10" ], - "6.1": [ - "CAP-01", - "CHG-01", - "CFG-01", - "IRO-01" + "6.20-BP2": [ + "TDA-08" ], - "5.11": [ - "CLD-01" + "6.20-BP3": [ + "TDA-08" ], - "6.21": [ - "MON-01", - "MON-01.16", - "MON-02", - "MON-02.2", - "MON-03", - "MON-08" + "6.20-BP1": [ + "TDA-09" ], - "6.22": [ - "CRY-01" + "6.16": [ + "TDA-17", + "VPM-05" ], - "6.8": [ - "DCH-01", - "DCH-02" + "5.10": [ + "TPM-01", + "TPM-04.1", + "TPM-05", + "TPM-05.4" ], - "6.10": [ - "DCH-01" + "5.11-BP2": [ + "TPM-05" ], - "6.13": [ - "DCH-01" + "6.2": [ + "THR-03" ], - "6.17": [ - "DCH-09" + "6.15-BP3": [ + "VPM-06.7" ], - "5.12": [ - "END-01" + "6.15-BP4": [ + "VPM-06.8" ], - "6.12": [ - "END-04" + "6.15-BP1": [ + "VPM-07" + ] + }, + "americas-bra-lgpd-2018": { + "VII.I.46.2": [ + "CPL-01" ], - "5.13": [ - "HRS-01", - "HRS-04" + "VII.I.48": [ + "IRO-10" ], - "6.6": [ - "IAC-01" + "VII.I.48.1": [ + "IRO-10" ], - "6.3": [ - "IRO-01" + "VII.I.48.1.I": [ + "IRO-10" ], - "6.4": [ - "IRO-01", - "IRO-04", - "IRO-13" + "VII.I.48.1.II": [ + "IRO-10" ], - "6.5": [ + "VII.I.48.1.III": [ "IRO-10" ], - "5.14": [ - "IAO-01", - "IAO-02" + "VII.I.48.1.IV": [ + "IRO-10" ], - "6.11": [ - "MDM-01" + "VII.I.48.1.V": [ + "IRO-10" ], - "6.18": [ - "NET-01" + "VII.I.48.1.VI": [ + "IRO-10" ], - "6.19": [ - "NET-02.1" + "VI.II.41": [ + "PRI-01.4" ], - "5.3": [ - "RSK-01" + "VI.II.41.1": [ + "PRI-01.4" ], - "5.8": [ - "RSK-01", - "RSK-06.2" + "VI.II.41.2": [ + "PRI-01.4" ], - "5.5": [ - "RSK-01.1", - "RSK-02.1", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1" + "VI.II.41.2.I": [ + "PRI-01.4" ], - "6.7": [ - "SAT-01" + "VI.II.41.2.II": [ + "PRI-01.4" ], - "6.20": [ - "TDA-06" + "VI.II.41.2.III": [ + "PRI-01.4" ], - "5.10": [ - "TPM-01" + "VI.II.41.2.IV": [ + "PRI-01.4" ], - "6.2": [ - "THR-01" + "VI.II.41.3": [ + "PRI-01.4" ], - "6.16": [ - "VPM-01", - "VPM-05" + "V.33": [ + "PRI-01.5", + "PRI-07" ], - "6.15": [ - "VPM-06", - "VPM-07" - ] - }, - "americas-bra-lgpd-2018": { - "8": [ - "PRI-02" + "V.33.I": [ + "PRI-01.5" ], - "9": [ - "PRI-06" + "V.33.II": [ + "PRI-01.5" ], - "10": [ - "PRI-04.1" + "V.33.II(a)": [ + "PRI-01.5" ], - "11": [ - "PRI-04.1" + "V.33.II(b)": [ + "PRI-01.5" ], - "12": [ - "DCH-23" + "V.33.II(c)": [ + "PRI-01.5" ], - "13": [ - "PRI-05" + "V.33.II(d)": [ + "PRI-01.5" ], - "14": [ - "PRI-05" + "V.33.III": [ + "PRI-01.5" ], - "15": [ - "PRI-03", - "PRI-05" + "V.33.IV": [ + "PRI-01.5" ], - "16": [ - "DCH-09.3" + "V.33.V": [ + "PRI-01.5" ], - "17": [ - "PRI-06" + "V.33.VI": [ + "PRI-01.5" ], - "18": [ - "PRI-06.4" + "V.33.VII": [ + "PRI-01.5" ], - "19": [ - "PRI-06.4" + "V.33.VIII": [ + "PRI-01.5" ], - "20": [ - "PRI-06" + "V.33.IX": [ + "PRI-01.5" ], - "21": [ - "PRI-05", - "PRI-06.4" + "V.34": [ + "PRI-01.5" ], - "33": [ - "CLD-09" + "V.34.I": [ + "PRI-01.5" ], - "34": [ - "CLD-09" + "V.34.II": [ + "PRI-01.5" ], - "35": [ - "PRI-07.1" + "V.34.III": [ + "PRI-01.5" ], - "37": [ - "PRI-14.1", - "SEA-01", - "SEA-02", - "SEA-03" + "V.34.IV": [ + "PRI-01.5" ], - "38": [ - "PRI-14" + "V.34.V": [ + "PRI-01.5" ], - "39": [ - "PRI-07.1" + "V.34.VI": [ + "PRI-01.5" ], - "40": [ - "PRI-06.6" + "VII.I.46": [ + "PRI-01.6" ], - "41": [ - "PRI-01.4" + "VII.I.46.1": [ + "PRI-01.6" ], - "46": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "VII.I.47": [ + "PRI-01.6" ], - "47": [ - "DCH-01" + "VII.I.49": [ + "PRI-01.6" ], - "48": [ - "IRO-02", - "IRO-04.1", - "IRO-10" + "VII.II.50": [ + "PRI-01.6" ], - "49": [ - "SEA-01", - "SEA-02", - "SEA-03" + "VII.II.50.1": [ + "PRI-01.6" ], - "50": [ - "PRI-01" + "VII.II.50.2": [ + "PRI-01.6" ], - "7.1": [ - "CPL-01", - "PRI-03" + "VII.II.50.2.I": [ + "PRI-01.6" ], - "7.2": [ - "CPL-01" + "VII.II.50.2.I(a)": [ + "PRI-01.6" ], - "7.3": [ - "CPL-01" + "VII.II.50.2.I(b)": [ + "PRI-01.6" ], - "7.4": [ - "CPL-01" + "VII.II.50.2.I(c)": [ + "PRI-01.6" ], - "7.5": [ - "CPL-01" + "VII.II.50.2.I(d)": [ + "PRI-01.6" ], - "7.6": [ - "CPL-01" + "VII.II.50.2.I(e)": [ + "PRI-01.6" ], - "7.7": [ - "CPL-01" + "VII.II.50.2.I(f)": [ + "PRI-01.6" ], - "7.8": [ - "CPL-01" + "VII.II.50.2.I(g)": [ + "PRI-01.6" ], - "7.9": [ - "CPL-01" + "VII.II.50.2.I(h)": [ + "PRI-01.6" ], - "7.10": [ - "CPL-01" + "VII.II.50.2.II": [ + "PRI-01.6" ], - "18.3": [ - "DCH-22.1", - "PRI-06.1" + "II.I.10": [ + "PRI-01.11" ], - "6.8": [ - "PRI-01", - "PRI-01.1", - "PRI-01.4", - "PRM-04" + "II.I.10.I": [ + "PRI-01.11" ], - "6.10": [ - "PRI-01", - "PRI-01.1", - "PRI-01.4" + "II.I.10.II": [ + "PRI-01.11" ], - "6.2": [ - "PRI-02", - "PRI-04", - "PRI-05" + "II.I.10.II.1": [ + "PRI-01.11" ], - "6.6": [ - "PRI-02" + "II.I.10.II.2": [ + "PRI-01.11" ], - "6.1": [ - "PRI-02.1", - "PRI-04.1" + "II.II.11.I": [ + "PRI-01.11" ], - "6.3": [ - "PRI-02.1" + "II.II.11.II": [ + "PRI-01.11" ], - "6.9": [ - "PRI-05" + "II.II.11.II(a)": [ + "PRI-01.11" ], - "6.4": [ - "PRI-06" + "II.II.11.II(b)": [ + "PRI-01.11" ], - "18.1": [ - "PRI-06" + "II.II.11.II(c)": [ + "PRI-01.11" ], - "18.2": [ - "PRI-06" + "II.II.11.II(d)": [ + "PRI-01.11" ], - "18.9": [ - "PRI-06.2", - "PRI-06.3" + "II.II.11.II(e)": [ + "PRI-01.11" ], - "18.4": [ - "PRI-06.5" + "II.II.11.II(f)": [ + "PRI-01.11" ], - "18.6": [ - "PRI-06.5" + "II.II.11.II(g)": [ + "PRI-01.11" ], - "18.5": [ - "PRI-06.6" + "II.II.11.II(g)1": [ + "PRI-01.11" ], - "6.5": [ - "PRI-10" + "II.II.11.II(g)2": [ + "PRI-01.11" ], - "18.7": [ - "PRI-14.1" + "II.II.11.II(g)3": [ + "PRI-01.11" ], - "6.7": [ - "SEA-01", - "SEA-02", - "SEA-03" - ] - }, - "amaericas-can-osfi-self-assessment": { - "6.5": [ - "GOV-01", - "GOV-01.1" + "II.II.11.II(g)4": [ + "PRI-01.11" ], - "6.6": [ - "GOV-01", - "GOV-01.1" + "III.21": [ + "PRI-01.11" ], - "6.7": [ - "GOV-01", - "GOV-01.1", - "PRM-01.1", - "PRM-01.2", - "PRM-04", - "PRM-05" + "II.I.9": [ + "PRI-02" ], - "6.23": [ - "GOV-01", - "GOV-01.1" + "II.I.9.I": [ + "PRI-02" ], - "6.21": [ - "GOV-01.1" + "II.I.9.II": [ + "PRI-02" ], - "6.22": [ - "GOV-01.1", - "PRM-01", - "PRM-02", - "PRM-03" + "II.I.9.III": [ + "PRI-02" ], - "6.24": [ - "GOV-01.1", - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-02.1", - "RSK-03", - "RSK-04.1", - "RSK-06.1", - "RSK-06.2" + "II.I.9.IV": [ + "PRI-02" ], - "6.1": [ - "GOV-02" + "II.I.9.V": [ + "PRI-02" ], - "6.3": [ - "GOV-02" + "II.I.9.VI": [ + "PRI-02" ], - "1.1": [ - "GOV-04", - "PRM-01", - "PRM-01.1", - "PRM-02" + "II.I.9.VII": [ + "PRI-02" ], - "1.2": [ - "GOV-04", - "HRS-03" + "II.I.9.VII.1": [ + "PRI-02" ], - "6.2": [ - "GOV-04" + "II.IV.15.I": [ + "PRI-02.8" ], - "6.9": [ - "GOV-05" + "II.I.7.I": [ + "PRI-03" ], - "3.7": [ - "GOV-07", - "THR-03" + "II.I.8": [ + "PRI-03" ], - "3.1": [ - "AST-02", - "AST-04", - "CAP-04" + "II.I.8.1": [ + "PRI-03" ], - "4.21": [ - "AST-02.5" + "II.I.8.2": [ + "PRI-03" ], - "4.24": [ - "AST-02.5", - "IAC-01", - "IAC-16" + "II.I.8.3": [ + "PRI-03" ], - "2.9": [ - "BCD-01", - "BCD-01.2", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3" + "II.I.8.4": [ + "PRI-03" ], - "2.8": [ - "BCD-03.1", - "BCD-04", - "BCD-04.1", - "IRO-05", - "IRO-05.1", - "IRO-06", - "IRO-06.1" + "II.I.9.VII.3": [ + "PRI-03.1" ], - "5.9": [ - "BCD-05", - "IRO-04.2", - "IRO-13", - "IAO-05" + "II.I.8.6": [ + "PRI-03.2" ], - "4.17": [ - "CHG-01" + "II.I.9.VII.2": [ + "PRI-03.2" ], - "4.20": [ - "CHG-01", - "CHG-02", - "CFG-02", - "CFG-02.8", - "CFG-03.2", - "CFG-03.3", - "CFG-05", - "CFG-05.1", - "CFG-05.2", - "CFG-06", - "CFG-06.1" + "II.I.8.5": [ + "PRI-03.4" ], - "6.11": [ - "CHG-01", - "CHG-02.2", - "CHG-02.3", - "CHG-04.1" + "II.IV.15.III": [ + "PRI-03.4" ], - "4.18": [ - "CHG-02" + "II.IV.15.II": [ + "PRI-03.10" ], - "2.4": [ - "CHG-02.3" + "II.IV.15.IV": [ + "PRI-03.10" ], - "6.10": [ - "CPL-01.1", - "CPL-02", - "CPL-03" + "II.III.14": [ + "PRI-03.13" ], - "6.14": [ - "CPL-01.1" + "II.III.14.1": [ + "PRI-03.13" ], - "6.17": [ - "CPL-02.1" + "II.III.14.2": [ + "PRI-03.13" ], - "6.18": [ - "CPL-02.1" + "II.III.14.3": [ + "PRI-03.13" ], - "6.19": [ - "CPL-02.1" + "II.III.14.4": [ + "PRI-03.13" ], - "6.20": [ - "CPL-02.1" + "II.III.14.5": [ + "PRI-03.13" ], - "6.13": [ - "CPL-03.1" + "II.III.14.6": [ + "PRI-03.13" ], - "6.25": [ - "CPL-03.1" + "II.IV.16": [ + "PRI-05" ], - "4.16": [ - "CFG-02" + "II.IV.16.I": [ + "PRI-05" ], - "4.19": [ - "CFG-02.8", - "CFG-03.2", - "CFG-03.3", - "CFG-05", - "CFG-05.1", - "CFG-05.2", - "CFG-06", - "CFG-06.1" + "II.IV.16.II": [ + "PRI-05" ], - "4.6": [ - "CFG-04.2", - "TDA-17" + "II.IV.16.III": [ + "PRI-05" ], - "4.9": [ - "CFG-04.2", - "TDA-01", - "TDA-06", - "TDA-09", - "TDA-17", - "VPM-05" + "II.IV.16.IV": [ + "PRI-05" ], - "3.5": [ - "MON-01", - "MON-01.8", - "MON-01.16" + "II.I.7.IV": [ + "PRI-05.1" ], - "3.3": [ - "MON-01.1" + "II.II.13": [ + "PRI-05.3" ], - "4.3": [ - "MON-01.1", - "END-01", - "END-02", - "END-04", - "END-05", - "END-07", - "END-08", - "END-08.1", - "NET-02.1", - "NET-08", - "NET-08.2", - "WEB-03" + "II.II.13.1": [ + "PRI-05.3" ], - "4.4": [ - "MON-01.1", - "END-01", - "END-02", - "END-04", - "END-05", - "END-07", - "END-08", - "END-08.1", - "NET-02.1", - "NET-08", - "NET-08.2", - "WEB-03" + "II.II.13.2": [ + "PRI-05.3" ], - "3.4": [ - "MON-01.2" + "II.II.13.3": [ + "PRI-05.3" ], - "3.6": [ - "MON-01.4", - "MON-02.1", - "IRO-02.5" + "II.II.13.4": [ + "PRI-05.3" ], - "3.2": [ - "MON-02" + "II.I.7.II": [ + "PRI-05.4" ], - "1.5": [ - "HRS-01", - "HRS-03.2", - "OPS-01", - "OPS-03" + "II.I.7.III": [ + "PRI-05.4" ], - "1.7": [ - "HRS-03.2", - "SAT-01", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6" + "II.I.7.V": [ + "PRI-05.4" ], - "1.6": [ - "HRS-04", - "HRS-04.1" + "II.I.7.VI": [ + "PRI-05.4" ], - "4.22": [ - "IAC-01" + "II.I.7.VII": [ + "PRI-05.4" ], - "4.23": [ - "IAC-16" + "II.I.7.VIII": [ + "PRI-05.4" ], - "1.3": [ - "IRO-01", - "RSK-01", - "OPS-01", - "OPS-03", - "THR-01" + "II.I.7.IX": [ + "PRI-05.4" ], - "5.1": [ - "IRO-01", - "IRO-04", - "IRO-07" + "II.I.7.X": [ + "PRI-05.4" ], - "5.2": [ - "IRO-01", - "IRO-04", - "IRO-07" + "II.I.7.X.1": [ + "PRI-05.4" ], - "5.3": [ - "IRO-01", - "IRO-04", - "IRO-07" + "II.I.7.X.2": [ + "PRI-05.4" ], - "5.4": [ - "IRO-01", - "IRO-04", - "IRO-07" + "II.I.7.X.3": [ + "PRI-05.4" ], - "5.5": [ - "IRO-01", - "IRO-04", - "IRO-07" + "II.I.7.X.4": [ + "PRI-05.4" ], - "5.6": [ - "IRO-01", - "IRO-04", - "IRO-07" + "II.I.7.X.5": [ + "PRI-05.4" ], - "5.7": [ - "IRO-01", - "IRO-04", - "IRO-07" + "II.I.7.X.6": [ + "PRI-05.4" ], - "5.8": [ - "IRO-01", - "IRO-04", - "IRO-07" + "III.18": [ + "PRI-06" ], - "4.13": [ - "IRO-02.6" + "III.18.I": [ + "PRI-06" ], - "4.15": [ - "IRO-02.6", - "MDM-01", - "NET-01", - "NET-02" + "III.18.II": [ + "PRI-06" ], - "4.26": [ - "IAO-03.2", - "TPM-05" + "III.18.III": [ + "PRI-06" ], - "4.28": [ - "IAO-03.2", - "TPM-05", - "TPM-11" + "III.18.IV": [ + "PRI-06" ], - "2.7": [ - "IAO-04", - "RSK-06", - "TDA-15", - "TPM-09", - "VPM-02", - "VPM-04" + "III.18.V": [ + "PRI-06" ], - "4.14": [ - "MDM-01" + "III.18.VI": [ + "PRI-06" ], - "4.10": [ - "NET-01" + "III.18.VII": [ + "PRI-06" ], - "4.11": [ - "NET-02" + "III.18.VIII": [ + "PRI-06" ], - "4.12": [ - "NET-02" + "III.18.IX": [ + "PRI-06" ], - "4.1": [ - "NET-17" + "III.18.IX.1": [ + "PRI-06" ], - "4.2": [ - "NET-17" + "III.18.IX.2": [ + "PRI-06" ], - "6.4": [ - "RSK-01", - "SEA-02.1" + "III.18.IX.3": [ + "PRI-06" ], - "6.8": [ - "RSK-01", - "RSK-04", - "RSK-06" + "III.18.IX.4": [ + "PRI-06" ], - "6.16": [ - "RSK-01", - "RSK-06.2" + "III.18.IX.4.I": [ + "PRI-06.4" ], - "6.15": [ - "RSK-01.1" + "III.18.IX.4.II": [ + "PRI-06.4" ], - "2.1": [ - "RSK-04" + "III.18.IX.5": [ + "PRI-06.4" ], - "2.2": [ - "RSK-05", - "RSK-06" + "III.18.IX.7": [ + "PRI-06.6" ], - "2.3": [ - "RSK-09", - "TPM-01", - "TPM-02", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-06" + "III.19": [ + "PRI-06.6" ], - "4.25": [ - "RSK-09", - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-04.1" + "III.19.II": [ + "PRI-06.6" ], - "4.30": [ - "OPS-02", - "OPS-05" + "III.19.II.1": [ + "PRI-06.6" ], - "1.4": [ - "OPS-04" + "III.19.II.2": [ + "PRI-06.6" ], - "4.29": [ - "OPS-05" + "III.19.II.2.I": [ + "PRI-06.6" ], - "1.8": [ - "SAT-01", - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.6" + "III.19.II.2.II": [ + "PRI-06.6" ], - "1.9": [ - "SAT-01", - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.6" + "III.19.II.3": [ + "PRI-06.6" ], - "4.8": [ - "TDA-01", - "TDA-06", - "TDA-09" + "III.19.I": [ + "PRI-06.7" ], - "4.27": [ - "TPM-02", - "TPM-04.1", - "TPM-07", - "TPM-08", - "TPM-09", - "TPM-10" + "VI.I.39": [ + "PRI-07.1" ], - "4.5": [ - "VPM-05" + "III.18.IX.6": [ + "PRI-07.3" ], - "4.7": [ - "VPM-05" + "VI.I.37": [ + "PRI-14" ], - "2.5": [ - "VPM-06" + "III.20": [ + "PRI-19", + "PRI-19.3" ], - "2.6": [ - "VPM-07" + "III.20.1": [ + "PRI-19.3" + ], + "II.I.10.II.3": [ + "RSK-10" ] }, + "americas-can-osfi-self-assessment": {}, "americas-can-osfi-b13-2022": { "1": [ "GOV-01", @@ -263868,6 +276481,283 @@ "VPM-05" ] }, + "americas-can-osfi-self-assessment-2": { + "3": [ + "IRO-02" + ], + "1.2.1": [ + "GOV-01", + "GOV-05.2", + "PRM-01.1", + "PRM-05", + "PRM-06" + ], + "1.3.2": [ + "GOV-01.1", + "GOV-02", + "PRM-02.1", + "RSK-01", + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-04.2", + "RSK-06.4" + ], + "2.2.1": [ + "GOV-02" + ], + "1.1.1": [ + "GOV-04" + ], + "1.1.2": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "GOV-14" + ], + "3.1.5": [ + "GOV-07", + "THR-01", + "THR-03", + "THR-03.1" + ], + "3.2.1": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "SEA-01" + ], + "2.9.3": [ + "GOV-16", + "BCD-04" + ], + "2.2.2": [ + "AST-01.1", + "AST-02", + "AST-02.9" + ], + "2.9.1": [ + "AST-01.1", + "BCD-01", + "BCD-01.7", + "BCD-02", + "BCD-11" + ], + "2.2.3": [ + "AST-02.4", + "AST-02.9" + ], + "2.2.4": [ + "AST-09" + ], + "2.8.2": [ + "CAP-01", + "CAP-04" + ], + "2.5.1": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "CHG-07" + ], + "2.5.3": [ + "CHG-02.1", + "CHG-04.1" + ], + "3.2.8": [ + "CFG-02", + "CFG-02.7" + ], + "3.3.1": [ + "MON-01", + "MON-01.2", + "MON-02", + "MON-10" + ], + "3.2.7": [ + "MON-01.4", + "HRS-04", + "IAC-01", + "IAC-01.2", + "IAC-06", + "IAC-16" + ], + "3.3.3": [ + "MON-01.8" + ], + "3.3.2": [ + "MON-02", + "MON-11.3", + "MON-16", + "END-06.8", + "OPS-06" + ], + "3.2.2": [ + "CRY-01", + "CRY-09" + ], + "2.9.2": [ + "CRY-09" + ], + "3.1.4": [ + "DCH-01", + "DCH-02", + "DCH-06.3" + ], + "3.2.5": [ + "DCH-02" + ], + "2.7.2": [ + "HRS-03", + "IRO-02", + "IRO-02.4", + "IRO-03", + "IRO-06", + "IRO-06.1", + "OPS-01.1" + ], + "2.5.2": [ + "HRS-11" + ], + "2.7.1": [ + "IRO-01", + "IRO-02" + ], + "3.4.3": [ + "IRO-01" + ], + "2.7.3": [ + "IRO-02", + "IRO-13" + ], + "3.4.1": [ + "IRO-02" + ], + "3.4.2": [ + "IRO-02.4" + ], + "3.4.4": [ + "IRO-07" + ], + "3.4.5": [ + "IRO-08" + ], + "2.4.4": [ + "IAO-02", + "IAO-04", + "TDA-01" + ], + "3.2.4": [ + "NET-01", + "NET-02", + "NET-04", + "NET-08" + ], + "3.2.10": [ + "PES-01", + "PES-01.1", + "PES-02", + "PES-02.1" + ], + "2.3.1": [ + "PRM-01", + "PRM-04" + ], + "2.4.1": [ + "PRM-07" + ], + "1.3.1": [ + "RSK-01" + ], + "3.1.8": [ + "RSK-01", + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5" + ], + "3.1.3": [ + "RSK-04.2", + "VPM-06" + ], + "3.2.3": [ + "RSK-06", + "RSK-06.2", + "RSK-06.4" + ], + "3.2.6": [ + "RSK-06.2", + "VPM-01", + "VPM-02", + "VPM-05", + "VPM-05.1" + ], + "2.1.1": [ + "SEA-01", + "SEA-02" + ], + "2.1.2": [ + "SEA-01", + "SEA-02" + ], + "2.2.5": [ + "SEA-07.1", + "TDA-17" + ], + "2.8.1": [ + "OPS-03", + "TPM-05" + ], + "3.1.7": [ + "SAT-01", + "SAT-01.1", + "SAT-02", + "SAT-02.1" + ], + "2.4.3": [ + "TDA-01", + "TDA-01.1", + "TDA-01.4", + "TDA-02.3" + ], + "2.4.5": [ + "TDA-02.3", + "TDA-06" + ], + "2.4.2": [ + "TDA-06" + ], + "3.1.6": [ + "TDA-06.2", + "THR-09", + "THR-10" + ], + "3.2.9": [ + "TDA-09", + "TDA-09.3" + ], + "3.1.1": [ + "THR-01", + "THR-03", + "THR-03.1" + ], + "3.1.2": [ + "THR-09", + "THR-10" + ], + "2.6.1": [ + "VPM-01", + "VPM-04", + "VPM-04.1", + "VPM-04.3", + "VPM-05" + ] + }, "americas-can-itsp-10-171-2025": { "03.15.01.A": [ "GOV-01", @@ -263879,7 +276769,8 @@ "GOV-15.4", "GOV-15.5", "OPS-01", - "OPS-01.1" + "OPS-01.1", + "OPS-03" ], "03.12.03": [ "GOV-01.1", @@ -263896,14 +276787,31 @@ ], "03.15.01.B": [ "GOV-03", - "OPS-01", - "OPS-03" + "OPS-01" ], "03.15.03.D": [ "GOV-03", "HRS-01", + "HRS-05.1", "HRS-05.7" ], + "03.16.01": [ + "GOV-15", + "AST-17", + "PRM-01", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-01", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-03", + "TDA-05", + "TDA-06", + "TPM-01", + "TPM-10" + ], "03.17.01.A": [ "GOV-15", "GOV-15.1", @@ -263923,9 +276831,11 @@ "AST-04", "AST-04.3", "AST-31", + "CFG-02", "DCH-01.4", "DCH-03", "DCH-14.3", + "END-01", "IAC-20", "IAC-20.1", "NET-04", @@ -263948,6 +276858,7 @@ "MDM-06", "MDM-07", "NET-01", + "NET-03", "SEA-01", "SEA-02" ], @@ -263962,7 +276873,9 @@ "CPL-01.2", "DCH-02", "DCH-06.2", - "DCH-19" + "DCH-19", + "DCH-24", + "IAO-03" ], "03.07.04.A": [ "AST-01", @@ -263974,6 +276887,12 @@ "MNT-04", "MNT-09" ], + "03.04.08.C": [ + "AST-01.4", + "AST-02", + "CPL-03.2", + "CFG-03.1" + ], "03.04.08.A": [ "AST-02", "AST-02.9", @@ -263981,11 +276900,6 @@ "CFG-03", "CFG-03.3" ], - "03.04.08.C": [ - "AST-02", - "CPL-03.2", - "CFG-03.1" - ], "03.04.10.A": [ "AST-02", "AST-02.1", @@ -263997,8 +276911,7 @@ "AST-02.9" ], "03.04.10.C": [ - "AST-02.1", - "AST-02.9" + "AST-02.1" ], "03.04.02.B": [ "AST-02.4", @@ -264006,7 +276919,8 @@ "CHG-02", "CHG-02.1", "CHG-04", - "CFG-02.1", + "CPL-03.2", + "CFG-02", "CFG-02.2", "CFG-02.7", "CFG-02.9", @@ -264062,6 +276976,7 @@ "RSK-02", "RSK-02.1", "RSK-03", + "RSK-03.1", "RSK-04", "RSK-05", "RSK-09", @@ -264070,22 +276985,6 @@ "TPM-03", "TPM-04.1" ], - "03.16.01": [ - "AST-17", - "PRM-01", - "PRM-05", - "SEA-01", - "SEA-02", - "TDA-01", - "TDA-02", - "TDA-02.3", - "TDA-02.4", - "TDA-03", - "TDA-05", - "TDA-06", - "TPM-01", - "TPM-10" - ], "03.04.12.A": [ "AST-24", "CFG-02.5", @@ -264113,8 +277012,7 @@ "03.01.12.C": [ "AST-27", "NET-14", - "NET-14.3", - "NET-14.5" + "NET-14.3" ], "03.08.09.A": [ "BCD-11", @@ -264127,10 +277025,16 @@ "CHG-01", "CHG-02", "CHG-02.1", + "CFG-01", "CFG-06" ], + "03.04.03.D": [ + "CHG-01", + "CFG-02.2" + ], "03.04.03.B": [ "CHG-02", + "CHG-02.1", "CHG-02.2", "CHG-03" ], @@ -264140,6 +277044,16 @@ "MNT-01", "MNT-02" ], + "03.07.05.A": [ + "CHG-02", + "CHG-02.1", + "IAC-01.2", + "IAC-05.2", + "MNT-02", + "MNT-05", + "MNT-05.1", + "MNT-05.5" + ], "03.04.04.A": [ "CHG-02.2", "CHG-02.3", @@ -264149,7 +277063,10 @@ "CHG-04", "CHG-04.4", "IAC-08", - "IAC-21" + "IAC-21", + "PES-02", + "PES-02.1", + "PES-03" ], "03.04.04.B": [ "CHG-06" @@ -264170,6 +277087,14 @@ "IAO-05", "RSK-04.1" ], + "03.12.02.A.02": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1", + "RSK-06", + "VPM-02", + "VPM-05" + ], "03.04.01.A": [ "CFG-01", "CFG-02", @@ -264180,7 +277105,8 @@ "03.01.01.H": [ "CFG-02", "HRS-05", - "HRS-05.3" + "HRS-05.3", + "IAC-25" ], "03.01.08.A": [ "CFG-02", @@ -264215,6 +277141,7 @@ "03.01.16.A": [ "CFG-02", "CRY-07", + "IAO-03", "NET-01", "NET-02.2", "NET-15", @@ -264223,6 +277150,20 @@ "SEA-01", "SEA-02" ], + "03.01.16.C": [ + "CFG-02", + "NET-15.2", + "NET-15.3", + "SEA-01" + ], + "03.03.08.A": [ + "CFG-02", + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-08.3", + "IAC-21" + ], "03.04.02.A": [ "CFG-02", "CFG-02.5", @@ -264232,7 +277173,6 @@ ], "03.04.06.B": [ "CFG-02", - "CFG-02.5", "CFG-03" ], "03.04.06.D": [ @@ -264240,6 +277180,18 @@ "CFG-02.5", "CFG-03" ], + "03.05.04": [ + "CFG-02", + "IAC-02.2" + ], + "03.05.07.C": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.11", + "IAC-15.1" + ], "03.05.07.D": [ "CFG-02", "IAC-01.2", @@ -264255,6 +277207,7 @@ "IAC-10", "IAC-10.1", "IAC-10.8", + "IAC-15", "IAC-15.1" ], "03.05.07.F": [ @@ -264272,6 +277225,13 @@ "IAC-10.8", "IAC-15.1" ], + "03.07.05.B": [ + "CFG-02", + "IAC-02.2", + "IAC-06", + "MNT-05", + "MNT-05.3" + ], "03.08.07.A": [ "CFG-02", "DCH-10", @@ -264284,8 +277244,21 @@ "03.04.01.B": [ "CFG-02.1" ], - "03.04.03.D": [ - "CFG-02.2" + "03.04.06.C": [ + "CFG-02.1", + "CFG-03.1" + ], + "03.13.13.B": [ + "CFG-02.2", + "CFG-03.3", + "CFG-04", + "CFG-04.1", + "CFG-05", + "END-10" + ], + "03.14.08.C": [ + "CFG-02.5", + "IAC-20.4" ], "03.03.02.B": [ "CFG-02.9", @@ -264294,10 +277267,9 @@ "03.13.11": [ "CFG-02.9", "CRY-01", - "CRY-01.5" - ], - "03.04.06.C": [ - "CFG-03.1" + "CRY-01.5", + "CRY-03", + "CRY-05" ], "03.04.08.B": [ "CFG-03.2", @@ -264307,13 +277279,6 @@ "CFG-03.3", "END-10" ], - "03.13.13.B": [ - "CFG-03.3", - "CFG-04", - "CFG-04.1", - "CFG-05", - "END-10" - ], "03.01.02": [ "CFG-08", "DCH-01.2", @@ -264323,7 +277288,8 @@ "IAC-08", "IAC-15", "IAC-20", - "IAC-20.1" + "IAC-20.1", + "IAC-21" ], "03.03.01.A": [ "MON-01", @@ -264335,6 +277301,12 @@ "03.14.06.A": [ "MON-01" ], + "03.14.06.A.02": [ + "MON-01", + "MON-11.3", + "MON-16", + "END-07" + ], "03.13.01.A": [ "MON-01.1", "MON-01.3", @@ -264368,10 +277340,6 @@ "MON-16", "END-07" ], - "03.03.01.B": [ - "MON-01.8", - "MON-02.2" - ], "03.03.05.A": [ "MON-01.8", "MON-02", @@ -264399,6 +277367,10 @@ "MON-02.2", "MON-02.3" ], + "03.03.01.B": [ + "MON-02.6", + "MON-03.6" + ], "03.03.02.A": [ "MON-03" ], @@ -264441,14 +277413,8 @@ "03.03.06.B": [ "MON-08" ], - "03.03.08.A": [ - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-08.3", - "IAC-21" - ], "03.03.08.B": [ + "MON-08", "MON-08.2", "IAC-08", "IAC-21" @@ -264456,13 +277422,9 @@ "03.01.22.B": [ "MON-11", "DCH-15", + "IRO-12", "WEB-14" ], - "03.14.06.A.02": [ - "MON-11.3", - "MON-16", - "END-07" - ], "03.01.01.E": [ "MON-16", "IAC-15", @@ -264485,7 +277447,9 @@ "DCH-01", "DCH-01.2", "HRS-02", + "IAC-01.2", "IAC-15", + "IAC-15.1", "IAC-20", "IAC-20.1", "IAC-21" @@ -264567,7 +277531,8 @@ "DCH-01.2", "HRS-03", "IAC-08", - "IAC-20.1" + "IAC-20.1", + "IRO-04" ], "03.08.02": [ "DCH-01.2", @@ -264586,7 +277551,8 @@ "DCH-03.1" ], "03.08.05.C": [ - "DCH-01.3" + "DCH-01.3", + "DCH-07" ], "03.01.04.B": [ "DCH-01.4", @@ -264598,7 +277564,9 @@ "DCH-01.4", "IAC-20.1", "PES-01", - "PES-02" + "PES-02", + "PES-06", + "PES-06.1" ], "03.15.02.C": [ "DCH-01.4", @@ -264643,8 +277611,11 @@ "DCH-14.3", "HRS-06", "HRS-06.1", - "NET-05", - "NET-05.2" + "NET-05" + ], + "03.10.07.B": [ + "DCH-18", + "PES-03.3" ], "03.14.08": [ "DCH-18" @@ -264707,8 +277678,25 @@ ], "03.09.01.B": [ "HRS-02", + "HRS-04", "HRS-04.1" ], + "03.15.03.B": [ + "HRS-02", + "HRS-03", + "HRS-03.1", + "HRS-04.2", + "HRS-05" + ], + "03.02.02.A.01": [ + "HRS-03", + "HRS-04.1", + "HRS-04.2", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" + ], "03.06.04.A": [ "HRS-03", "HRS-04.2", @@ -264720,19 +277708,16 @@ "IAC-08", "MNT-01", "MNT-06", - "MNT-06.1", - "MNT-06.2", "TPM-01", "TPM-01.1", "TPM-05", "TPM-05.4" ], - "03.15.03.B": [ + "03.07.06.D": [ "HRS-03", - "HRS-03.1", - "HRS-04.2", - "HRS-05.7", - "HRS-06" + "HRS-03.2", + "MNT-06", + "MNT-06.1" ], "03.16.03.B": [ "HRS-03", @@ -264741,18 +277726,11 @@ "TPM-05.2", "TPM-05.4" ], - "03.07.06.D": [ - "HRS-03.2", - "MNT-06", - "MNT-06.1" - ], - "03.02.02.A.01": [ - "HRS-04.1", - "HRS-04.2", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6" + "03.09.02.B.01": [ + "HRS-04", + "HRS-08", + "HRS-09", + "HRS-09.2" ], "03.06.04.A.01": [ "HRS-04.2", @@ -264779,22 +277757,23 @@ "HRS-08", "HRS-09" ], - "03.09.02.B.01": [ + "03.09.02.B.02": [ "HRS-08", - "HRS-09", - "HRS-09.2" + "IAC-07.1", + "IAC-20" ], "03.01.01.F.03": [ "HRS-09", "IAC-15" ], - "03.09.02.A.01": [ + "03.09.02.A.02": [ + "HRS-09", "HRS-09.2", "HRS-09.4", "IAC-07", "IAC-07.2" ], - "03.09.02.A.02": [ + "03.09.02.A.01": [ "HRS-09.2", "HRS-09.4", "IAC-07", @@ -264835,6 +277814,12 @@ "IAC-10.1", "IAC-15.1" ], + "03.01.16.B": [ + "IAC-01.2", + "NET-02.2", + "NET-15", + "NET-15.1" + ], "03.05.02": [ "IAC-01.2", "IAC-04", @@ -264842,6 +277827,7 @@ ], "03.05.05.D": [ "IAC-01.2", + "IAC-02", "IAC-09", "IAC-09.2", "IAC-09.5", @@ -264859,42 +277845,18 @@ "IAC-10.4", "IAC-10.11" ], - "03.05.07.C": [ - "IAC-01.2", - "IAC-10", - "IAC-10.5", - "IAC-10.11", - "IAC-15.1" - ], - "03.05.12.F": [ - "IAC-01.2", - "IAC-10", - "IAC-10.1", - "IAC-10.5", - "IAC-15.1" - ], - "03.07.05.A": [ - "IAC-01.2", - "IAC-05.2", - "MNT-02", - "MNT-05", - "MNT-05.1", - "MNT-05.5" - ], - "03.05.04": [ - "IAC-02.2" - ], - "03.07.05.B": [ - "IAC-02.2", - "IAC-06", - "MNT-05", - "MNT-05.3" - ], "03.05.03": [ "IAC-06", "IAC-06.1", "IAC-06.2", - "IAC-06.3" + "IAC-06.3", + "IAC-06.4" + ], + "03.01.01.B": [ + "IAC-07", + "IAC-15", + "IAC-15.7", + "IAC-28.1" ], "03.01.01.G.01": [ "IAC-07", @@ -264907,10 +277869,6 @@ "IAC-15", "IAC-17" ], - "03.09.02.B.02": [ - "IAC-07.1", - "IAC-20" - ], "03.01.01.C.03": [ "IAC-08", "IAC-20", @@ -264921,6 +277879,7 @@ "IAC-08", "IAC-15", "IAC-20", + "IAC-20.1", "IAC-21" ], "03.01.06.A": [ @@ -264949,9 +277908,12 @@ "IAC-10.1" ], "03.05.12.C": [ + "IAC-10" + ], + "03.05.12.F": [ "IAC-10", - "IAC-10.1", - "IAC-28" + "IAC-10.5", + "IAC-15.1" ], "03.05.11": [ "IAC-11" @@ -264959,13 +277921,13 @@ "03.05.01.B": [ "IAC-14" ], - "03.01.01.B": [ - "IAC-15", - "IAC-28.1" - ], "03.01.01.F.01": [ "IAC-15" ], + "03.01.01.F.02": [ + "IAC-15", + "IAC-15.3" + ], "03.01.05.C": [ "IAC-15", "IAC-15.7", @@ -264975,9 +277937,6 @@ "IAC-15", "IAC-17" ], - "03.01.01.F.02": [ - "IAC-15.3" - ], "03.01.07.A": [ "IAC-16", "IAC-21", @@ -264998,13 +277957,20 @@ "IAC-20.1", "IAC-21" ], + "03.01.06.C": [ + "IAC-20.4" + ], + "03.14.08.A": [ + "IAC-20.4" + ], "03.01.06.B": [ "IAC-21.2" ], "03.07.05.C": [ "IAC-25", "MNT-05", - "MNT-05.4" + "MNT-05.4", + "NET-07" ], "03.06.01": [ "IRO-01", @@ -265018,6 +277984,7 @@ ], "03.06.02.B": [ "IRO-02", + "IRO-07", "IRO-09", "IRO-10", "IRO-10.2" @@ -265030,8 +277997,14 @@ ], "03.06.02.D": [ "IRO-02", + "IRO-07", + "IRO-10", "IRO-11" ], + "03.06.05.B": [ + "IRO-02", + "IRO-04" + ], "03.06.05.A": [ "IRO-04" ], @@ -265053,22 +278026,18 @@ "03.06.05.A.06": [ "IRO-04" ], - "03.06.05.B": [ - "IRO-04" + "03.06.05.C": [ + "IRO-04.2" ], "03.06.04.B": [ - "IRO-04.2", "IRO-04.3", "IRO-13", - "SAT-03", - "SAT-03.7" - ], - "03.06.05.C": [ - "IRO-04.2" + "SAT-01.1" ], "03.06.04.A.03": [ "IRO-05", - "SAT-02" + "SAT-02", + "SAT-03" ], "03.06.03": [ "IRO-06" @@ -265105,13 +278074,6 @@ "03.12.02.A": [ "IAO-05" ], - "03.12.02.A.02": [ - "IAO-05", - "RSK-04.1", - "RSK-06", - "VPM-02", - "VPM-05" - ], "03.12.02.B": [ "IAO-05" ], @@ -265128,22 +278090,26 @@ "IAO-05", "TDA-01", "TDA-09", + "THR-01", + "THR-06", "VPM-01", "VPM-01.1", "VPM-02", "VPM-04", - "VPM-05" + "VPM-05", + "VPM-06" ], "03.07.04.B": [ "MNT-04.1" ], "03.01.12.D": [ "MNT-05", - "NET-14", "NET-14.4" ], "03.07.06.B": [ - "MNT-06" + "MNT-06", + "TPM-01.1", + "TPM-05.4" ], "03.07.06.C": [ "MNT-06", @@ -265153,12 +278119,9 @@ "03.01.18.C": [ "MDM-03" ], - "03.01.16.B": [ + "03.14.08.B": [ "NET-01", - "NET-02.2", - "NET-15", - "NET-15.1", - "SEA-01" + "NET-14" ], "03.13.01.B": [ "NET-02", @@ -265192,8 +278155,7 @@ ], "03.01.12.B": [ "NET-14", - "NET-14.1", - "NET-14.3" + "NET-14.1" ], "03.10.06.A": [ "NET-14.5", @@ -265206,17 +278168,21 @@ "03.01.16.D": [ "NET-15.1" ], - "03.01.16.C": [ - "NET-15.2", - "NET-15.3", - "SEA-01" - ], "03.10.07.A": [ "PES-01", "PES-02", "PES-03", "PES-03.1" ], + "03.10.07.A.01": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1", + "PES-03.4", + "PES-04", + "PES-04.1" + ], "03.10.01.B": [ "PES-02", "PES-02.1" @@ -265229,15 +278195,10 @@ "PES-05.1", "PES-05.2" ], - "03.10.07.A.01": [ - "PES-03", - "PES-03.4", - "PES-04", - "PES-04.1" - ], "03.10.07.A.02": [ "PES-03", "PES-03.1", + "PES-03.3", "PES-03.4", "PES-04", "PES-04.1" @@ -265247,15 +278208,9 @@ "PES-04", "PES-04.1" ], - "03.10.07.B": [ - "PES-03.3" - ], "03.10.02.B": [ "PES-05", - "PES-05.1", - "PES-05.2", - "PES-06", - "PES-06.1" + "PES-05.2" ], "03.10.07.C": [ "PES-06", @@ -265273,6 +278228,20 @@ "PES-12", "PES-12.2" ], + "03.17.03.B": [ + "RSK-01", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7" + ], "03.14.03.B": [ "RSK-02.1", "THR-03.1", @@ -265308,19 +278277,6 @@ "TPM-04.1", "TPM-05.5" ], - "03.17.03.B": [ - "RSK-09", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-05.2", - "TPM-05.5", - "TPM-05.7" - ], "03.13.04": [ "SEA-05" ], @@ -265336,6 +278292,17 @@ "03.02.01.A": [ "SAT-01" ], + "03.02.01.B": [ + "SAT-01.1" + ], + "03.02.02.A.02": [ + "SAT-01.1", + "SAT-03", + "SAT-03.6" + ], + "03.02.02.B": [ + "SAT-01.1" + ], "03.02.01.A.01": [ "SAT-02", "SAT-03", @@ -265356,29 +278323,16 @@ "THR-03", "THR-05" ], - "03.02.01.B": [ - "SAT-02", - "SAT-03.6", - "THR-03" - ], "03.02.02.A": [ "SAT-03" ], - "03.02.02.A.02": [ - "SAT-03", - "SAT-03.6" - ], - "03.02.02.B": [ - "SAT-03", - "SAT-03.6", - "THR-03" - ], "03.06.04.A.02": [ "SAT-03", "SAT-03.6" ], "03.17.02": [ "TDA-01", + "TPM-01", "TPM-03.1", "TPM-04", "TPM-04.1", @@ -265421,7 +278375,6 @@ "THR-03" ], "03.14.01.B": [ - "VPM-04", "VPM-05" ], "03.11.02.C": [ @@ -265429,298 +278382,692 @@ ] }, "americas-can-pipeda-2000": { - "Principle 7": [ - "GOV-01", + "P1-4.1.4": [ + "GOV-02" + ], + "P1-4.1": [ "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "PRI-01.1" ], - "Principle 10": [ - "DCH-22.1", - "PRI-06.1" + "P1-4.1.3": [ + "CPL-01", + "PRI-07.1" ], - "Sec 20": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "PRI-07.1", - "SEA-15", - "TPM-04.4" + "P1-4.1.2": [ + "CPL-05", + "PRI-01.1" ], - "Principle 1": [ - "PRI-01" + "P7-4.7.3(c)": [ + "CFG-01" ], - "Principle 8": [ - "PRI-01", - "PRI-06" + "P1-4.1.4(d)": [ + "HRS-04.2", + "HRS-05.7" ], - "Sec 6": [ - "PRI-01.4", - "PRI-03", - "PRI-03.2" + "P7-4.7.3(b)": [ + "IAC-01" + ], + "P7-4.7.3(a)": [ + "PES-01" + ], + "P1-4.1.1": [ + "PRI-01.1" ], - "Principle 2": [ + "P1-4.1.4(a)": [ + "PRI-01.6", + "PRI-01.11" + ], + "P7-4.7": [ + "PRI-01.6" + ], + "P7-4.7.1": [ + "PRI-01.6" + ], + "P7-4.7.2": [ + "PRI-01.6" + ], + "P7-4.7.3": [ + "PRI-01.6" + ], + "P3-4.3.3": [ + "PRI-01.11", + "PRI-03" + ], + "P4-4.4.1": [ + "PRI-01.11" + ], + "P4-4.4.2": [ + "PRI-01.11" + ], + "P2-4.2": [ "PRI-02", "PRI-02.1" ], - "Sec 5": [ - "PRI-02.1", - "PRI-04", - "PRI-04.1" + "P2-4.2.1": [ + "PRI-02" ], - "Sec 7": [ - "PRI-03", - "PRI-03.2", - "PRI-05" + "P2-4.2.2": [ + "PRI-02" ], - "Principle 3": [ - "PRI-03", + "P2-4.2.3": [ + "PRI-02" + ], + "P8-4.8": [ + "PRI-02" + ], + "P8-4.8.1": [ + "PRI-02" + ], + "P8-4.8.2": [ + "PRI-02" + ], + "P8-4.8.2(a)": [ + "PRI-02" + ], + "P8-4.8.2(b)": [ + "PRI-02" + ], + "P8-4.8.2(c)": [ + "PRI-02" + ], + "P8-4.8.2(d)": [ + "PRI-02" + ], + "P8-4.8.2(e)": [ + "PRI-02" + ], + "P8-4.8.3": [ + "PRI-02" + ], + "P2-4.2.5": [ + "PRI-03" + ], + "P3-4.3": [ + "PRI-03" + ], + "P3-4.3.1": [ + "PRI-03" + ], + "P3-4.3.2": [ + "PRI-03" + ], + "P3-4.3.4": [ + "PRI-03" + ], + "P3-4.3.5": [ + "PRI-03" + ], + "P3-4.3.6": [ + "PRI-03" + ], + "P3-4.3.7": [ + "PRI-03" + ], + "P3-4.3.7(a)": [ + "PRI-03" + ], + "P3-4.3.7(b)": [ + "PRI-03" + ], + "P3-4.3.7(c)": [ + "PRI-03" + ], + "P3-4.3.7(d)": [ + "PRI-03" + ], + "P2-4.2.4": [ "PRI-03.2" ], - "Principle 4": [ + "P3-4.3.8": [ + "PRI-03.4" + ], + "P4-4.4": [ "PRI-04", "PRI-04.1" ], - "Sec 8": [ - "PRI-05" + "P5-4.5.3": [ + "PRI-05", + "PRI-05.4" ], - "Principle 5": [ + "P7-4.7.5": [ "PRI-05" ], - "Principle 6": [ - "PRI-05", + "P6-4.6": [ + "PRI-05.2" + ], + "P6-4.6.1": [ + "PRI-05.2" + ], + "P6-4.6.2": [ + "PRI-05.2" + ], + "P6-4.6.3": [ "PRI-05.2" ], - "Principle 9": [ + "P5-4.5": [ + "PRI-05.4" + ], + "P9-4.9": [ "PRI-06" ], - "Sec 11": [ - "PRI-06.3" + "P10-4.10": [ + "PRI-06" ], - "Sec 23": [ - "PRI-07", - "PRI-07.1" + "P9-4.9.5": [ + "PRI-06.1" + ], + "P1-4.1.4(b)": [ + "PRI-06.4" + ], + "P9-4.9.1": [ + "PRI-06.4" + ], + "P9-4.9.4": [ + "PRI-06.4", + "PRI-17" + ], + "P10-4.10.2": [ + "PRI-06.4" + ], + "P10-4.10.3": [ + "PRI-06.4" + ], + "P10-4.10.4": [ + "PRI-06.4" + ], + "P9-4.9.2": [ + "PRI-06.8" + ], + "P9-4.9.6": [ + "PRI-07.3", + "PRI-18" + ], + "P5-4.5.1": [ + "PRI-14", + "RSK-10" + ], + "P9-4.9.3": [ + "PRI-14.1" + ], + "P5-4.5.2": [ + "OPS-01.1", + "OPS-03" + ], + "P1-4.1.4(c)": [ + "SAT-02" + ], + "P7-4.7.4": [ + "SAT-02" ] }, "americas-chl-act-19628-1999": { - "4": [ + "I.7": [ + "HRS-06.1", + "PRI-01.6", + "PRI-01.11" + ], + "I.5": [ + "PRI-01.1", + "PRI-15" + ], + "I.11": [ + "PRI-01.6", + "PRI-01.11" + ], + "I.4": [ + "PRI-03", + "PRI-04.1" + ], + "I.8": [ "PRI-03" ], - "5": [ - "PRI-02", - "PRI-02.1" + "I.9": [ + "PRI-03.9", + "PRI-05.2" ], - "7": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "PRI-01.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "I.6": [ + "PRI-05", + "PRI-05.4" ], - "9": [ - "PRI-05" + "I.10": [ + "PRI-05.4" ], - "10": [ + "II.15": [ "PRI-05.4" ], - "11": [ - "PRI-01.1" + "II.12": [ + "PRI-06" ], - "12": [ + "II.13": [ "PRI-06" ], - "13": [ - "DCH-22.1", - "PRI-06.1" + "II.14": [ + "PRI-06" ], - "Inferred": [ - "PRI-01" + "I.5(a)": [ + "PRI-15" ], - "Expectation": [ - "PRI-01" + "I.5(b)": [ + "PRI-15" + ], + "I.5(c)": [ + "PRI-15" ] }, "americas-col-law-1581-2012": { - "4": [ - "GOV-01", - "CPL-01", - "PRI-01", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.2", - "PRI-05.4", - "SEA-01", - "SEA-02", - "SEA-03" + "VI.17(k)": [ + "GOV-02" ], - "5": [ + "VI.17": [ + "CPL-01" + ], + "VI.17(o)": [ + "CPL-01" + ], + "VI.18": [ + "CPL-01" + ], + "III.5": [ + "DCH-02" + ], + "II.4(h)": [ + "HRS-06.1" + ], + "VI.17(n)": [ + "IRO-10.2" + ], + "VI.18(a)": [ + "PRI-01" + ], + "VI.18(b)": [ + "PRI-01" + ], + "VI.18(c)": [ + "PRI-01" + ], + "VI.18(d)": [ + "PRI-01" + ], + "VI.18(e)": [ + "PRI-01" + ], + "VI.18(f)": [ + "PRI-01" + ], + "VI.18(g)": [ + "PRI-01" + ], + "VI.18(h)": [ + "PRI-01" + ], + "VI.18(i)": [ + "PRI-01" + ], + "VI.18(j)": [ + "PRI-01" + ], + "VI.18(k)": [ + "PRI-01" + ], + "VI.18(l)": [ + "PRI-01" + ], + "II.4(g)": [ + "PRI-01.6", + "PRI-01.11" + ], + "VI.17(d)": [ + "PRI-01.6" + ], + "II.4(d)": [ + "PRI-01.11" + ], + "VI.17(a)": [ + "PRI-01.11" + ], + "VI.17(e)": [ + "PRI-01.11" + ], + "VI.17(c)": [ + "PRI-02" + ], + "II.4(c)": [ + "PRI-03" + ], + "VI.17(b)": [ + "PRI-03" + ], + "VI.17(m)": [ + "PRI-03.2" + ], + "IV.8(e)": [ + "PRI-03.4" + ], + "III.7": [ + "PRI-03.13", "PRI-05.4" ], - "6": [ + "VI.17(f)": [ + "PRI-05.2" + ], + "VI.17(g)": [ + "PRI-05.2" + ], + "II.4(f)": [ "PRI-05.4" ], - "7": [ + "III.6": [ "PRI-05.4" ], - "8": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2" + "III.6(a)": [ + "PRI-05.4" ], - "11": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2" + "III.6(b)": [ + "PRI-05.4" ], - "12": [ - "PRI-02", + "III.6(c)": [ + "PRI-05.4" + ], + "III.6(d)": [ + "PRI-05.4" + ], + "III.6(e)": [ + "PRI-05.4" + ], + "II.4(e)": [ + "PRI-06" + ], + "IV.8(a)": [ + "PRI-06" + ], + "IV.8(b)": [ + "PRI-06" + ], + "IV.8(c)": [ + "PRI-06" + ], + "IV.8(f)": [ + "PRI-06" + ], + "IV.11": [ + "PRI-06" + ], + "V.14": [ + "PRI-06" + ], + "V.15": [ + "PRI-06" + ], + "V.15.1": [ + "PRI-06" + ], + "IV.12(a)": [ "PRI-06.4" ], - "15": [ - "PRI-06.3", + "IV.12(b)": [ "PRI-06.4" ], - "17": [ - "PRI-01.1" + "IV.12(c)": [ + "PRI-06.4" ], - "18": [ - "PRI-01.1" + "IV.12(d)": [ + "PRI-06.4" ], - "25": [ - "PRI-15" + "V.15.2": [ + "PRI-06.4" ], - "26": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "V.15.3": [ + "PRI-06.4" + ], + "VI.17(j)": [ + "PRI-06.4" + ], + "IV.9": [ + "PRI-06.8" + ], + "IV.12": [ + "PRI-06.8" + ], + "VI.17(h)": [ + "PRI-07" + ], + "VI.17(i)": [ + "PRI-07.1" + ], + "VI.17(l)": [ + "PRI-07.3" ] }, "americas-mex-fdpa-2010": { - "6": [ + "II.13": [ + "DCH-18.1", + "PRI-05.4" + ], + "III.24": [ + "DCH-22.1", + "PRI-06.1" + ], + "IV.28": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" + ], + "II.20": [ + "IRO-10" + ], + "II.6": [ + "PRI-01", + "PRI-01.11" + ], + "II.14": [ "PRI-01" ], - "7": [ + "IV.30": [ + "PRI-01.4", + "PRI-01.9" + ], + "II.19": [ + "PRI-01.6" + ], + "II.21": [ + "PRI-01.6", + "PRI-07.1" + ], + "II.7": [ + "PRI-01.11", "PRI-02", - "PRI-02.1", - "PRI-02.2", - "PRI-03.2", "PRI-04", "PRI-04.1", - "PRI-05", "PRI-05.4" ], - "8": [ - "PRI-03", - "PRI-05" + "II.9": [ + "PRI-01.11", + "PRI-03" ], - "9": [ - "PRI-05", - "PRI-05.2", - "PRI-05.4" + "II.10": [ + "PRI-01.11" ], - "10": [ - "PRI-03" + "II.10.I": [ + "PRI-01.11" ], - "11": [ - "PRI-05" + "II.10.II": [ + "PRI-01.11" ], - "12": [ - "PRI-05" + "II.10.III": [ + "PRI-01.11" ], - "13": [ - "PRI-05" + "II.10.IV": [ + "PRI-01.11" ], - "14": [ - "PRI-01", - "PRI-05" + "II.10.V": [ + "PRI-01.11" ], - "15": [ - "PRI-06" + "II.10.VI": [ + "PRI-01.11" ], - "16": [ + "II.10.VII": [ + "PRI-01.11" + ], + "III.26": [ + "PRI-01.11" + ], + "III.26.I": [ + "PRI-01.11" + ], + "III.26.II": [ + "PRI-01.11" + ], + "III.26.III": [ + "PRI-01.11" + ], + "III.26.IV": [ + "PRI-01.11" + ], + "III.26.V": [ + "PRI-01.11" + ], + "III.26.VI": [ + "PRI-01.11" + ], + "III.26.VII": [ + "PRI-01.11" + ], + "IV.34": [ + "PRI-01.11", + "PRI-07.5" + ], + "IV.35": [ + "PRI-01.11" + ], + "II.12": [ "PRI-02", - "PRI-02.1" + "PRI-04" ], - "17": [ + "II.15": [ + "PRI-02" + ], + "II.16": [ + "PRI-02" + ], + "II.16.I": [ + "PRI-02" + ], + "II.16.II": [ "PRI-02", "PRI-02.1" ], - "18": [ + "II.16.III": [ "PRI-02", - "PRI-02.1" + "PRI-06" ], - "19": [ - "GOV-01", - "CPL-01", - "SEA-01", - "SEA-02", - "SEA-03" + "II.16.IV": [ + "PRI-02" ], - "20": [ - "IRO-04.1" + "II.16.V": [ + "PRI-02" ], - "21": [ - "TPM-03", - "TPM-05" + "II.16.VI": [ + "PRI-02", + "PRI-03.2" ], - "22": [ + "II.17": [ + "PRI-02" + ], + "II.17.I": [ + "PRI-02" + ], + "II.17.II": [ + "PRI-02" + ], + "II.18": [ + "PRI-02" + ], + "V.36": [ + "PRI-02" + ], + "II.8": [ + "PRI-03", + "PRI-03.4" + ], + "III.25": [ + "PRI-03.4", "PRI-06" ], - "23": [ + "II.11": [ + "PRI-05", + "PRI-05.2" + ], + "V.37": [ + "PRI-05.4" + ], + "V.37.I": [ + "PRI-05.4" + ], + "V.37.II": [ + "PRI-05.4" + ], + "V.37.III": [ + "PRI-05.4" + ], + "V.37.IV": [ + "PRI-05.4" + ], + "V.37.V": [ + "PRI-05.4" + ], + "V.37.VI": [ + "PRI-05.4" + ], + "V.37.VII": [ + "PRI-05.4" + ], + "III.22": [ "PRI-06" ], - "24": [ - "DCH-22.1", - "PRI-06.1" + "III.23": [ + "PRI-06" ], - "25": [ + "III.27": [ "PRI-06" ], - "28": [ - "DCH-22.1", - "PRI-06.1" + "IV.29": [ + "PRI-06" ], - "29": [ - "DCH-22.1", - "PRI-06.1" + "IV.29.I": [ + "PRI-06" ], - "30": [ - "PRI-01", + "IV.29.II": [ + "PRI-06" + ], + "IV.29.III": [ + "PRI-06" + ], + "IV.29.IV": [ + "PRI-06" + ], + "IV.31": [ + "PRI-06" + ], + "IV.32": [ "PRI-06.4" ], - "36": [ - "SEA-01", - "SEA-02", - "SEA-03" + "IV.33": [ + "PRI-06.4" ], - "37": [ - "SEA-01", - "SEA-02", - "SEA-03" + "IV.34.I": [ + "PRI-07.5" + ], + "IV.34.II": [ + "PRI-07.5" + ], + "IV.34.III": [ + "PRI-07.5" + ], + "IV.34.IV": [ + "PRI-07.5" + ], + "IV.34.V": [ + "PRI-07.5" ] } } diff --git a/data/scf-evidence-requests.json b/data/scf-evidence-requests.json index a3b28452..19a1180c 100644 --- a/data/scf-evidence-requests.json +++ b/data/scf-evidence-requests.json @@ -1,5 +1,5 @@ { - "total": 303, + "total": 316, "evidence_requests": [ { "erl_id": "E-GOV-01", @@ -1019,7 +1019,8 @@ "artifact_description": "Documented evidence of applicable statutory, regulatory and/or contractual obligations for cybersecurity & data privacy controls.", "scf_controls": [ "CPL-01", - "MON-03" + "MON-03", + "QTS-03.4" ], "cmmc_mapping": "" }, @@ -1394,6 +1395,7 @@ "artifact_description": "Documented evidence of specialized user training for privileged users, executives, individuals who handle sensitive/regulated data, etc.", "scf_controls": [ "DCH-14", + "QTS-05", "SAT-01", "SAT-03", "SAT-03.4", @@ -3194,6 +3196,7 @@ "artifact_name": "Threat Intelligence Feeds (TIF)", "artifact_description": "Documented evidence of threat intelligence feeds.", "scf_controls": [ + "QTS-05.1", "THR-03" ], "cmmc_mapping": "SI.L2-3.14.3" @@ -3501,6 +3504,143 @@ "MON-01.4" ], "cmmc_mapping": "SI.L1-3.14.4\nSI.L1-3.14.5" + }, + { + "erl_id": "E-QTS-01", + "area": "Quantum Security", + "artifact_name": "Quantum Risk Governance Charter", + "artifact_description": "Documented evidence of a quantum risk governance charter with named lead and steering committee.", + "scf_controls": [ + "QTS-01" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-02", + "area": "Quantum Security", + "artifact_name": "Post-Quantum Cryptography (PQC)-Specific Status Reporting", + "artifact_description": "Documented evidence of a Post-Quantum Cryptography (PQC)-specific board / risk committee reporting pack (e.g., status, metrics/analytics, exceptions, etc.).", + "scf_controls": [ + "QTS-01" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-03", + "area": "Quantum Security", + "artifact_name": "Long-Lived Data Identification", + "artifact_description": "Documented evidence of a data classifications by the usable lifespan of the data that can be used to prioritize Post-Quantum Cryptography (PQC) remediation efforts.", + "scf_controls": [ + "QTS-01.3" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-04", + "area": "Quantum Security", + "artifact_name": "Cryptographic Asset Inventory", + "artifact_description": "Documented evidence of a cryptographic asset inventory.", + "scf_controls": [ + "CRY-01.5", + "QTS-03.3", + "QTS-04", + "QTS-04.1" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-05", + "area": "Quantum Security", + "artifact_name": "Cryptographic Bill of Materials (CBOM)", + "artifact_description": "Documented evidence of a Cryptographic Bill of Materials (CBOM).", + "scf_controls": [ + "QTS-04.2" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-06", + "area": "Quantum Security", + "artifact_name": "Cryptographic Agility Risk Assessment (CARA) Methodology", + "artifact_description": "Documented evidence of a Cryptographic Agility Risk Assessment (CARA) methodology.", + "scf_controls": [ + "QTS-02" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-07", + "area": "Quantum Security", + "artifact_name": "Cryptographic Exception Register", + "artifact_description": "Documented evidence of a formal cryptographic exception register.", + "scf_controls": [ + "QTS-02.1" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-08", + "area": "Quantum Security", + "artifact_name": "Approved / Deprecated Algorithm List", + "artifact_description": "Documented evidence of an approved / deprecated algorithm list.", + "scf_controls": [ + "QTS-06.3", + "QTS-06.5" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-09", + "area": "Quantum Security", + "artifact_name": "Zero Trust Network Architecture (ZTNA)", + "artifact_description": "Documented evidence of Zero Trust Network Architecture (ZTNA) (e.g., architecture diagrams, segmentation matrices, access policies, etc.).", + "scf_controls": [ + "QTS-01.4" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-10", + "area": "Quantum Security", + "artifact_name": "Cryptographic Telemetry", + "artifact_description": "Documented evidence of situational awareness dashboards for cryptographic telemetry (e.g., SIEM/XDR dashboards).", + "scf_controls": [ + "QTS-04.3", + "QTS-05.1" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-11", + "area": "Quantum Security", + "artifact_name": "Interoperability Test Records", + "artifact_description": "Documented evidence of cryptographic algorithm interoperability, performance and rollback tests.", + "scf_controls": [ + "QTS-03.1" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-12", + "area": "Quantum Security", + "artifact_name": "Cryptographic Incident Playbooks", + "artifact_description": "Documented evidence of incident playbooks and exercise records for cryptographic scenarios.", + "scf_controls": [ + "QTS-07" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-13", + "area": "Quantum Security", + "artifact_name": "Post-Quantum Cryptography (PQC)-Specific Vendor Roadmaps", + "artifact_description": "Documented evidence of a vendor-related Post-Quantum Cryptography (PQC) roadmaps, contract clauses, and attestations.", + "scf_controls": [ + "QTS-02.2", + "QTS-03.1", + "QTS-03.3" + ], + "cmmc_mapping": "" } ] } \ No newline at end of file diff --git a/data/scf-threats.json b/data/scf-threats.json index 3947797c..abd5c23a 100644 --- a/data/scf-threats.json +++ b/data/scf-threats.json @@ -1,5 +1,5 @@ { - "total": 41, + "total": 42, "threats": [ { "threat_id": "NT-1", @@ -155,7 +155,7 @@ "threat_id": "MT-12", "grouping": "Man-Made Threat", "name": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) Data", - "description": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data is information an organization utilizes for business processes even though the data is untrustworthy, due to the data's currency, accuracy, integrity and/or applicability." + "description": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data is information an organization utilizes for business processes even though the data is untrustworthy, due to the data's currency, accuracy, integrity and/or applicability. This includes \"poisoned\", or otherwise compromised, Artificial Intelligence (AI) training data." }, { "threat_id": "MT-13", @@ -246,6 +246,12 @@ "grouping": "Man-Made Threat", "name": "Infrastructure", "description": "Infrastructure is a threat category that pertains to the availability and functioning of fundamental facilities and systems necessary to support an industry and its supply chains within a country. This includes buildings, transportation networks, utilities and equipment. Additionally, this includes how well those facilities and systems are protected from both natural and man-made threats." + }, + { + "threat_id": "MT-28", + "grouping": "Man-Made Threat", + "name": "Harvest Now / Decrypt Later (HNDL)", + "description": "Harvest Now / Decrypt Later (HNDL) is a threat category associated with Post-Quantum Cryptography (PQC) that is focused on nation-state threat actors harvesting data streams using legacy encryption protocols, so when a quantum computer exists it can decrypt harvested data for long-living sensitive / regulated data (e.g., secrets, intellectual property, etc.)." } ] } \ No newline at end of file diff --git a/docs/api/assessment-objectives.json b/docs/api/assessment-objectives.json index d37c4fff..98c1105b 100644 --- a/docs/api/assessment-objectives.json +++ b/docs/api/assessment-objectives.json @@ -1,5 +1,5 @@ { - "total": 5776, + "total": 5956, "assessment_objectives": [ { "scf_control_id": "AAT-01", @@ -151,6 +151,76 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A01", + "objective": "mechanisms exist to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A02", + "objective": "the assigned class determines applicable approval requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A03", + "objective": "the assigned class determines applicable security, compliance and/or resilience controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A04", + "objective": "the assigned class determines applicable testing rigor.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A05", + "objective": "the assigned class determines applicable monitoring requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A06", + "objective": "the assigned class determines applicable supporting documentation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A07", + "objective": "the assigned class determines applicable oversight requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AAT-02", "ao_id": "AAT-02_A01", @@ -1311,6 +1381,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AAT-12.5", + "ao_id": "AAT-12.5_A01", + "objective": "the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT) is validated.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-12.6", + "ao_id": "AAT-12.6_A01", + "objective": "Artificial Intelligence and Autonomous Technologies (AAT) is prohibited from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AAT-13", "ao_id": "AAT-13_A01", @@ -3371,6 +3461,46 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A01", + "objective": "automated mechanisms enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A02", + "objective": "enforced resource limits address energy consumption.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A03", + "objective": "enforced resource limits address processing capacity.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A04", + "objective": "enforced resource limits address financial consumption (e.g., allocated budget).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AAT-30", "ao_id": "AAT-30_A01", @@ -3471,6 +3601,46 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A01", + "objective": "a Release Owner Gate (ROG), or similar function, prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A02", + "objective": "the review and approval process validates material facts.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A03", + "objective": "the review and approval process validates citations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A04", + "objective": "the review and approval process validates other relevant content that could discredit the organization.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AST-01", "ao_id": "AST-01_A01", @@ -4461,6 +4631,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A01", + "objective": "reasonable physical security protections for storage are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A02", + "objective": "processes exist to define criteria for Technology Assets, Applications, Services and/or Data (TAASD) storage", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A03", + "objective": "Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "AST-06", "ao_id": "AST-06_A01", @@ -9131,6 +9331,76 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "CFG-09", + "ao_id": "CFG-09_A01", + "objective": "an authoritative repository for production software is established.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.1", + "ao_id": "CFG-09.1_A01", + "objective": "the use and import of third-party libraries and/or software components to trustworthy sources is restricted.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A01", + "objective": "software repositories are protected from importing untrusted and/or malicious software artifacts.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A02", + "objective": "software artifacts are scanned for malicious content.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A03", + "objective": "a digital signature or secure hash provided over a secure channel is verified.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A04", + "objective": "software artifacts are scanned to identify plain text or encoded secrets and keys.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.3", + "ao_id": "CFG-09.3_A01", + "objective": "an authoritative repository for software development activities is maintained that is separate from production software.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "CHG-01", "ao_id": "CHG-01_A01", @@ -11461,6 +11731,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "CPL-03.8", + "ao_id": "CPL-03.8_A01", + "objective": "Continuous Control Monitoring (CCM) scoping is defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CPL-03.8", + "ao_id": "CPL-03.8_A02", + "objective": "automated mechanisms exist to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization's Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "CPL-04", "ao_id": "CPL-04_A01", @@ -18971,6 +19261,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "GOV-01.4", + "ao_id": "GOV-01.4_A01", + "objective": "the organization's Security, Compliance & Resilience Program (SCRP) is aligned with one or more industry-recognized frameworks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-01.4", + "ao_id": "GOV-01.4_A02", + "objective": "the framework alignment provides defensible justification for secure practices.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "GOV-02", "ao_id": "GOV-02_A01", @@ -19521,6 +19831,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "GOV-10.1", + "ao_id": "GOV-10.1_A01", + "objective": "a data catalog exists.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-10.1", + "ao_id": "GOV-10.1_A02", + "objective": "data is cataloged in a structured format to document each significant data asset.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "GOV-11", "ao_id": "GOV-11_A01", @@ -19911,6 +20241,46 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A01", + "objective": "organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A02", + "objective": "the internal oversight capabilities demonstrate governance of internal controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A03", + "objective": "the internal oversight capabilities demonstrate risk management, including analysis and mitigation activities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A04", + "objective": "the internal oversight capabilities demonstrate compliance with applicable laws, regulations and contractual obligations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "GOV-20", "ao_id": "GOV-20_A01", @@ -19931,6 +20301,76 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A01", + "objective": "A High Value Assets (HVAs) catalog is created.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A02", + "objective": "criteria are defined for high-value Intellectual Property (IP) to be categorized as a \"crown jewel.\"", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A03", + "objective": "criteria are defined for Technology Assets, Applications and Services (TAAS) to be categorized as a \"crown jewel,\" based on business process criticality or dependency relationships.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A04", + "objective": "the physical and/or logical location of HVAs are documented.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A05", + "objective": "assigned owners are defined for HVAs", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A06", + "objective": "minimum protection mechanisms for HVAs are defined.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A07", + "objective": "assurance requirements for HVAs are defined.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "HRS-01", "ao_id": "HRS-01_A01", @@ -22301,6 +22741,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A01", + "objective": "identity providers and authorization servers are employed to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A02", + "objective": "authentication and authorization decisions are made in accordance with organization-defined identification and authentication policy.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A03", + "objective": "authentication and authorization decisions use organization-defined mechanisms.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "IAC-02", "ao_id": "IAC-02_A01", @@ -25651,6 +26121,16 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "IAC-15.10", + "ao_id": "IAC-15.10_A01", + "objective": "non-privileged accounts are separated between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "IAC-16", "ao_id": "IAC-16_A01", @@ -34118,7 +34598,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.03.01.a", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "SDP values:\nat a minimum and where applicable:\n(1) Authentication events:\n (a) Logons (Success/Failure)\n (b) Logoffs (Success)\n(2) Security Relevant File and Objects events:\n (a) Create (Success/Failure)\n (b) Access (Success/Failure)\n (c) Delete (Success/Failure)\n (d) Modify (Success/Failure)\n (e) Permission Modification (Success/Failure)\n (f) Ownership Modification (Success/Failure)\n(3) Export/Writes/downloads to devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(4) Import/Uploads from devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(5) User and Group Management events:\n (a) User add, delete, modify, disable, lock (Success/Failure)\n (b) Group/Role add, delete, modify (Success/Failure)\n6) Use of Privileged/Special Rights events:\n (a) Security or audit policy changes (Success/Failure)\n (b) Configuration changes (Success/Failure)\n(7) Admin or root-level access (Success/Failure)\n(8) Privilege/Role escalation (Success/Failure)\n(9) Audit and security relevant log data accesses (Success/Failure)\n(10) System reboot, restart, and shutdown (Success/Failure)\n(11) Print to a device (Success/Failure)\n(12) Print to a file (e.g., pdf format) (Success/Failure)\n(13) Application (e.g., Adobe, Firefox, MS Office Suite) initialization (Success/Failure)\n\nFor additional guidance, see: OMB21-31 ML 1", + "scf_defined_parameters": "SDP values:\nat a minimum and where applicable:\n(1) Authentication events:\n (a) Logons (Success/Failure)\n (b) Logoffs (Success)\n(2) Security Relevant File and Objects events:\n (a) Create (Success/Failure)\n (b) Access (Success/Failure)\n (c) Delete (Success/Failure)\n (d) Modify (Success/Failure)\n (e) Permission Modification (Success/Failure)\n (f) Ownership Modification (Success/Failure)\n(3) Export/Writes/downloads to devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(4) Import/Uploads from devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(5) User and Group Management events:\n (a) User add, delete, modify, disable, lock (Success/Failure)\n (b) Group/Role add, delete, modify (Success/Failure)\n6) Use of Privileged/Special Rights events:\n (a) Security or audit policy changes (Success/Failure)\n (b) Configuration changes (Success/Failure)\n(7) Admin or root-level access (Success/Failure)\n(8) Privilege/Role escalation (Success/Failure)\n(9) Audit and security relevant log data accesses (Success/Failure)\n(10) System reboot, restart, and shutdown (Success/Failure)\n(11) Print to a device (Success/Failure)\n(12) Print to a file (e.g., pdf format) (Success/Failure)\n(13) Application (e.g., Adobe, Firefox, MS Office Suite) initialization (Success/Failure)\n\nFor additional guidance, see: OMB21-31 ML 1", "org_defined_parameters": "" }, { @@ -38221,6 +38701,46 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A01", + "objective": "automated mechanisms separate network appliance functions (e.g., management, control and data planes).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A02", + "objective": "separation prevents ordinary traffic from accessing functions that manage network appliances.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A03", + "objective": "separation prevents ordinary traffic from accessing functions that affect network operations.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "NET-06.9", + "ao_id": "NET-06.9_A01", + "objective": "subnetworks are physically or logically separate to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "NET-07", "ao_id": "NET-07_A01", @@ -42561,6 +43081,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "PRI-01.12", + "ao_id": "PRI-01.12_A01", + "objective": "the organization's data privacy principles are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "PRI-01.12", + "ao_id": "PRI-01.12_A02", + "objective": "the organization's data privacy principles are formally incorporated into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "PRI-02", "ao_id": "PRI-02_A01", @@ -46961,6 +47501,1056 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A01", + "objective": "an executive-sponsored quantum risk governance structure is established that institutionalizes quantum risk in the same manner as other enterprise risks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A02", + "objective": "a named migration lead with defined authority is assigned.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A03", + "objective": "quantum risk is treated as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A01", + "objective": "a formal, documented quantum security policy is established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A02", + "objective": "the quantum security policy conveys executive management's intent.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A03", + "objective": "the quantum security policy provides organizational direction and expected behaviors.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A04", + "objective": "the quantum security policy is reviewed at least annually.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A05", + "objective": "the quantum security policy is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.2", + "ao_id": "QTS-01.2_A01", + "objective": "a classification scheme exists to determine confidentiality shelf-life.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.2", + "ao_id": "QTS-01.2_A02", + "objective": "the shelf-life classification is used as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.3", + "ao_id": "QTS-01.3_A01", + "objective": "Technology Assets, Applications, Services and Data (TAASD) are classified according to confidentiality shelf-life.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A01", + "objective": "Harvest Now, Decrypt Later (HNDL) risk is mitigated through Zero Trust Network Access (ZTNA).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A02", + "objective": "ZTNA enforces continuous authentication.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A03", + "objective": "ZTNA enforces data microsegmentation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A04", + "objective": "ZTNA enforces least privilege.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A05", + "objective": "ZTNA enforces identity-based access control.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A01", + "objective": "a Cryptographic Agility Risk Assessment (CARA) methodology is defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A02", + "objective": "a CARA is performed to map Technology Assets, Applications, Services and Data (TAASD).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A03", + "objective": "the CARA identifies TAASD most vulnerable to quantum-enabled cryptanalytic threats.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A04", + "objective": "the CARA prioritizes TAASD based on potential business impact.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A01", + "objective": "each Post-Quantum Cryptography (PQC) deviation is governed through a formal cryptographic exception register.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A02", + "objective": "the exception register contains the asset and/or process owner(s).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A03", + "objective": "the exception register contains compensating control(s).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A04", + "objective": "the exception register contains the planned remediation date.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A05", + "objective": "the exception register contains the re-evaluation date.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.2", + "ao_id": "QTS-02.2_A01", + "objective": "short-term compensating measures are implemented for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.3", + "ao_id": "QTS-02.3_A01", + "objective": "progress is measured in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A01", + "objective": "a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) is developed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A02", + "objective": "the PQCAP enables cryptographic agility.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A03", + "objective": "the PQCAP aligns with evolving security standards.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A04", + "objective": "the PQCAP defines the approach for selecting and implementing PQC algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.1", + "ao_id": "QTS-03.1_A01", + "objective": "sufficient resources are allocated to transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.1", + "ao_id": "QTS-03.1_A02", + "objective": "hybrid cryptography is supported during a defined transition period, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A01", + "objective": "reportable metrics for Post-Quantum Cryptography (PQC) migration are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A02", + "objective": "the metrics measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A03", + "objective": "the metrics report progress periodically to executive leadership.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A01", + "objective": "vendors are required to disclose Post-Quantum Cryptography (PQC) support roadmaps.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A02", + "objective": "the roadmaps include identification of PQC-related limitations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A03", + "objective": "the roadmaps include supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.4", + "ao_id": "QTS-03.4_A01", + "objective": "vendors are contractually obligated to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04", + "ao_id": "QTS-04_A01", + "objective": "means to gain situational awareness into the organization's current cryptographic landscape through a formal discovery process are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04", + "ao_id": "QTS-04_A02", + "objective": "the discovery process uses available tools to generate situational awareness.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A01", + "objective": "a current inventory of cryptographic assets is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A02", + "objective": "the inventory includes algorithms (asymmetric and symmetric).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A03", + "objective": "the inventory includes key lengths.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A04", + "objective": "the inventory includes libraries.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A05", + "objective": "the inventory includes protocols.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A06", + "objective": "the inventory includes associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A07", + "objective": "the inventory includes Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A01", + "objective": "a Cryptographic Bill of Materials (CBOM) is maintained to analyze the organization's cryptographic architecture.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A02", + "objective": "the CBOM includes hardware.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A03", + "objective": "the CBOM includes firmware.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A04", + "objective": "the CBOM includes software modules.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A05", + "objective": "the CBOM includes communication protocols.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A01", + "objective": "a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A02", + "objective": "the inventory includes public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A03", + "objective": "the inventory includes long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A04", + "objective": "the inventory includes TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A01", + "objective": "differentiated quantum security training content is developed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A02", + "objective": "differentiated quantum security awareness training to the general workforce.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A03", + "objective": "differentiated quantum security awareness training to technical roles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A04", + "objective": "differentiated quantum security awareness training to leadership roles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A01", + "objective": "a quantum threat intelligence function is established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A02", + "objective": "the function monitors cryptanalytic threat developments.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A03", + "objective": "the function monitors quantum computing capability advances.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A04", + "objective": "the function monitors NIST and/or regulatory updates to approved algorithm lists.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.2", + "ao_id": "QTS-05.2_A01", + "objective": "stakeholders participation in sector-appropriate quantum security forums.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06", + "ao_id": "QTS-06_A01", + "objective": "design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) is validated to support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A01", + "objective": "validated entropy sources and random bit generators comply with NIST SP 800-90B.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A02", + "objective": "the entropy sources support Post-Quantum Cryptography (PQC) key generation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A03", + "objective": "the entropy sources support nonce generation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A04", + "objective": "the entropy sources support probabilistic algorithm inputs.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A05", + "objective": "the entropy sources support key validation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A01", + "objective": "stateful hash-based signature schemes conform with NIST SP 800-208.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A02", + "objective": "state-management controls necessary to prevent one-time key reuse are required.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A03", + "objective": "stateful hash-based signatures are enforced for firmware signing.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A04", + "objective": "stateful hash-based signatures are enforced for secure boot signing.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A05", + "objective": "stateful hash-based signatures are enforced for other long-lifetime code-signing use cases.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.3", + "ao_id": "QTS-06.3_A01", + "objective": "Post-Quantum Cryptography (PQC) algorithms are approved.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.3", + "ao_id": "QTS-06.3_A02", + "objective": "required validation levels for approved algorithms (e.g., FIPS 140-3 validated) are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.4", + "ao_id": "QTS-06.4_A01", + "objective": "Technology Assets, Applications and/or Services (TAAS) are configured to use FIPS 140-3 validated cryptographic modules, where applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.5", + "ao_id": "QTS-06.5_A01", + "objective": "quantum-vulnerable and otherwise deprecated cryptographic algorithms are prohibited from being used.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A01", + "objective": "cryptographic keys and certificates are managed in a manner that supports Post-Quantum Cryptography (PQC) transition.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A02", + "objective": "validity periods for quantum-vulnerable certificates are shortened to reduce exposure.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A03", + "objective": "Public Key Infrastructure (PKI) is prepared for PQC roots of trust or dual-root hybrid trust models.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A04", + "objective": "key generation uses quantum-safe entropy sources.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.7", + "ao_id": "QTS-06.7_A01", + "objective": "Public Key Infrastructure (PKI) trust anchors are transitioned to quantum-safe algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A01", + "objective": "Technology Assets, Applications and/or Services (TAAS) are configured to prevent attackers from forcing quantum-vulnerable algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A02", + "objective": "integrity-protected algorithm negotiation is used (e.g., TLS 1.3 handshake transcript).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A03", + "objective": "negotiation of classical-only cipher suites is disallowed once Post-Quantum Cryptography (PQC) is deployed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A04", + "objective": "downgrade attempts are monitored.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A01", + "objective": "hybrid/composite algorithms are leveraged as a transition path to Post-Quantum Cryptography (PQC) solutions, where applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A02", + "objective": "solutions support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A03", + "objective": "certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A04", + "objective": "plans exist for eventual removal of classical algorithms once PQC confidence is sufficient.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.10", + "ao_id": "QTS-06.10_A01", + "objective": "universal interface is used to bridge established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A01", + "objective": "capability exists to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A02", + "objective": "pre-identified algorithm alternates are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A03", + "objective": "tested rollback and roll-forward procedures are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A04", + "objective": "customer and/or counterparty communication templates are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A05", + "objective": "incident response rehearsals against defined scenarios are conducted.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A01", + "objective": "Post-Quantum Cryptography (PQC) implementations are validated for functional and cryptographic requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A02", + "objective": "each PQC implementation is interoperable with counterparties and successors.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A03", + "objective": "each PQC implementation meets performance criteria for its use case.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A04", + "objective": "test results and exceptions are documented.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "RSK-01", "ao_id": "RSK-01_A01", @@ -47078,7 +48668,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.17.03.b", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", + "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", "org_defined_parameters": "" }, { @@ -47441,6 +49031,16 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "RSK-03.2", + "ao_id": "RSK-03.2_A01", + "objective": "a risk owner is identified for each item in the risk register to ensure clear accountability for unremediated risks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "RSK-04", "ao_id": "RSK-04_A01", @@ -48208,7 +49808,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.17.03.b", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", + "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", "org_defined_parameters": "" }, { @@ -49361,6 +50961,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "SAT-04.1", + "ao_id": "SAT-04.1_A01", + "objective": "individual training results are monitored.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SAT-04.1", + "ao_id": "SAT-04.1_A02", + "objective": "training results are reported to applicable stakeholders.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "SAT-05", "ao_id": "SAT-05_A01", @@ -49641,6 +51261,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "SEA-01.4", + "ao_id": "SEA-01.4_A01", + "objective": "security architecture principles are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-01.4", + "ao_id": "SEA-01.4_A02", + "objective": "security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-01.5", + "ao_id": "SEA-01.5_A01", + "objective": "secure architecture principles are incorporated into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "SEA-02", "ao_id": "SEA-02_A01", @@ -50431,6 +52081,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A01", + "objective": "a frequency is defined for information to be regenerated or refreshed.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A02", + "objective": "information is generated or refreshed per an organization-defined frequency.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A03", + "objective": "mechanisms exist to delete information when no longer needed.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "SEA-09", "ao_id": "SEA-09_A01", @@ -52711,6 +54391,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "TDA-06.7", + "ao_id": "TDA-06.7_A01", + "objective": "organization-approved programming language(s) for software development are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-06.7", + "ao_id": "TDA-06.7_A02", + "objective": "the justification for program language alignment selection decisions are documented.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "TDA-07", "ao_id": "TDA-07_A01", @@ -53461,6 +55161,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "TDA-13.1", + "ao_id": "TDA-13.1_A01", + "objective": "a cybersecurity knowledge and skills register for developers is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-13.2", + "ao_id": "TDA-13.2_A01", + "objective": "requisite skillsets for developers for Secure Software Development Practices (SSDP) are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-13.2", + "ao_id": "TDA-13.2_A02", + "objective": "developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP) are trained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "TDA-14", "ao_id": "TDA-14_A01", @@ -54081,6 +55811,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "TDA-19.1", + "ao_id": "TDA-19.1_A01", + "objective": "personnel and/or role(s) authorized to receive security-relevant error messages are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-19.1", + "ao_id": "TDA-19.1_A02", + "objective": "access to error messages are restricted to authorized personnel and/or role(s).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "TDA-20", "ao_id": "TDA-20_A01", @@ -54331,6 +56081,26 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "THR-01.1", + "ao_id": "THR-01.1_A01", + "objective": "ongoing awareness of the current cyber threat environment is maintained as part of the Threat Intelligence Program (TIP).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "THR-01.2", + "ao_id": "THR-01.2_A01", + "objective": "advanced automation and analytics capabilities are implemented to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "THR-02", "ao_id": "THR-02_A01", @@ -55668,7 +57438,7 @@ "pptdf": "Data", "origin": "171A_R3_A.03.16.03.a", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "SDP values: \n(1) For cloud service providers:\n (i) FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or\n (ii) meets security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline.\n(2) All other external service providers must meet NIST SP 800-171 R2.", + "scf_defined_parameters": "SDP values: \n(1) For cloud service providers:\n (i) FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or\n (ii) meets security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline.\n(2) All other external service providers must meet NIST SP 800-171 R2.", "org_defined_parameters": "" }, { @@ -56341,6 +58111,36 @@ "scf_defined_parameters": "", "org_defined_parameters": "" }, + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A01", + "objective": "remediation and mitigation of Known Exploited Vulnerabilities (KEV) is prioritized.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A02", + "objective": "KEV remediation efforts reduce or remove public exposure to exploitation, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A03", + "objective": "KEV remediation efforts expedite patch deployment actions, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, { "scf_control_id": "VPM-03", "ao_id": "VPM-03_A01", diff --git a/docs/api/assessment-objectives/AAT-01.5.json b/docs/api/assessment-objectives/AAT-01.5.json new file mode 100644 index 00000000..8ca662a1 --- /dev/null +++ b/docs/api/assessment-objectives/AAT-01.5.json @@ -0,0 +1,76 @@ +{ + "scf_control_id": "AAT-01.5", + "total": 7, + "assessment_objectives": [ + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A01", + "objective": "mechanisms exist to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A02", + "objective": "the assigned class determines applicable approval requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A03", + "objective": "the assigned class determines applicable security, compliance and/or resilience controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A04", + "objective": "the assigned class determines applicable testing rigor.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A05", + "objective": "the assigned class determines applicable monitoring requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A06", + "objective": "the assigned class determines applicable supporting documentation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-01.5", + "ao_id": "AAT-01.5_A07", + "objective": "the assigned class determines applicable oversight requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/AAT-12.5.json b/docs/api/assessment-objectives/AAT-12.5.json new file mode 100644 index 00000000..943f0474 --- /dev/null +++ b/docs/api/assessment-objectives/AAT-12.5.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "AAT-12.5", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "AAT-12.5", + "ao_id": "AAT-12.5_A01", + "objective": "the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT) is validated.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/AAT-12.6.json b/docs/api/assessment-objectives/AAT-12.6.json new file mode 100644 index 00000000..ea1e7358 --- /dev/null +++ b/docs/api/assessment-objectives/AAT-12.6.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "AAT-12.6", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "AAT-12.6", + "ao_id": "AAT-12.6_A01", + "objective": "Artificial Intelligence and Autonomous Technologies (AAT) is prohibited from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/AAT-29.24.json b/docs/api/assessment-objectives/AAT-29.24.json new file mode 100644 index 00000000..eeb0c9ff --- /dev/null +++ b/docs/api/assessment-objectives/AAT-29.24.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "AAT-29.24", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A01", + "objective": "automated mechanisms enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A02", + "objective": "enforced resource limits address energy consumption.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A03", + "objective": "enforced resource limits address processing capacity.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-29.24", + "ao_id": "AAT-29.24_A04", + "objective": "enforced resource limits address financial consumption (e.g., allocated budget).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/AAT-33.json b/docs/api/assessment-objectives/AAT-33.json new file mode 100644 index 00000000..ce546dce --- /dev/null +++ b/docs/api/assessment-objectives/AAT-33.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "AAT-33", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A01", + "objective": "a Release Owner Gate (ROG), or similar function, prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A02", + "objective": "the review and approval process validates material facts.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A03", + "objective": "the review and approval process validates citations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AAT-33", + "ao_id": "AAT-33_A04", + "objective": "the review and approval process validates other relevant content that could discredit the organization.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/AST-05.2.json b/docs/api/assessment-objectives/AST-05.2.json new file mode 100644 index 00000000..f11548ab --- /dev/null +++ b/docs/api/assessment-objectives/AST-05.2.json @@ -0,0 +1,36 @@ +{ + "scf_control_id": "AST-05.2", + "total": 3, + "assessment_objectives": [ + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A01", + "objective": "reasonable physical security protections for storage are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A02", + "objective": "processes exist to define criteria for Technology Assets, Applications, Services and/or Data (TAASD) storage", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "AST-05.2", + "ao_id": "AST-05.2_A03", + "objective": "Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/CFG-09.1.json b/docs/api/assessment-objectives/CFG-09.1.json new file mode 100644 index 00000000..a1941757 --- /dev/null +++ b/docs/api/assessment-objectives/CFG-09.1.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "CFG-09.1", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "CFG-09.1", + "ao_id": "CFG-09.1_A01", + "objective": "the use and import of third-party libraries and/or software components to trustworthy sources is restricted.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/CFG-09.2.json b/docs/api/assessment-objectives/CFG-09.2.json new file mode 100644 index 00000000..b89773f1 --- /dev/null +++ b/docs/api/assessment-objectives/CFG-09.2.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "CFG-09.2", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A01", + "objective": "software repositories are protected from importing untrusted and/or malicious software artifacts.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A02", + "objective": "software artifacts are scanned for malicious content.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A03", + "objective": "a digital signature or secure hash provided over a secure channel is verified.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CFG-09.2", + "ao_id": "CFG-09.2_A04", + "objective": "software artifacts are scanned to identify plain text or encoded secrets and keys.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/CFG-09.3.json b/docs/api/assessment-objectives/CFG-09.3.json new file mode 100644 index 00000000..bb38670e --- /dev/null +++ b/docs/api/assessment-objectives/CFG-09.3.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "CFG-09.3", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "CFG-09.3", + "ao_id": "CFG-09.3_A01", + "objective": "an authoritative repository for software development activities is maintained that is separate from production software.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/CFG-09.json b/docs/api/assessment-objectives/CFG-09.json new file mode 100644 index 00000000..a14589ca --- /dev/null +++ b/docs/api/assessment-objectives/CFG-09.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "CFG-09", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "CFG-09", + "ao_id": "CFG-09_A01", + "objective": "an authoritative repository for production software is established.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/CPL-03.8.json b/docs/api/assessment-objectives/CPL-03.8.json new file mode 100644 index 00000000..c3ad25a1 --- /dev/null +++ b/docs/api/assessment-objectives/CPL-03.8.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "CPL-03.8", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "CPL-03.8", + "ao_id": "CPL-03.8_A01", + "objective": "Continuous Control Monitoring (CCM) scoping is defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "CPL-03.8", + "ao_id": "CPL-03.8_A02", + "objective": "automated mechanisms exist to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization's Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/GOV-01.4.json b/docs/api/assessment-objectives/GOV-01.4.json new file mode 100644 index 00000000..c7faa43b --- /dev/null +++ b/docs/api/assessment-objectives/GOV-01.4.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "GOV-01.4", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "GOV-01.4", + "ao_id": "GOV-01.4_A01", + "objective": "the organization's Security, Compliance & Resilience Program (SCRP) is aligned with one or more industry-recognized frameworks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-01.4", + "ao_id": "GOV-01.4_A02", + "objective": "the framework alignment provides defensible justification for secure practices.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/GOV-10.1.json b/docs/api/assessment-objectives/GOV-10.1.json new file mode 100644 index 00000000..f3f3307b --- /dev/null +++ b/docs/api/assessment-objectives/GOV-10.1.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "GOV-10.1", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "GOV-10.1", + "ao_id": "GOV-10.1_A01", + "objective": "a data catalog exists.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-10.1", + "ao_id": "GOV-10.1_A02", + "objective": "data is cataloged in a structured format to document each significant data asset.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/GOV-19.3.json b/docs/api/assessment-objectives/GOV-19.3.json new file mode 100644 index 00000000..314e870e --- /dev/null +++ b/docs/api/assessment-objectives/GOV-19.3.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "GOV-19.3", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A01", + "objective": "organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A02", + "objective": "the internal oversight capabilities demonstrate governance of internal controls.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A03", + "objective": "the internal oversight capabilities demonstrate risk management, including analysis and mitigation activities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-19.3", + "ao_id": "GOV-19.3_A04", + "objective": "the internal oversight capabilities demonstrate compliance with applicable laws, regulations and contractual obligations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/GOV-21.json b/docs/api/assessment-objectives/GOV-21.json new file mode 100644 index 00000000..9633354c --- /dev/null +++ b/docs/api/assessment-objectives/GOV-21.json @@ -0,0 +1,76 @@ +{ + "scf_control_id": "GOV-21", + "total": 7, + "assessment_objectives": [ + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A01", + "objective": "A High Value Assets (HVAs) catalog is created.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A02", + "objective": "criteria are defined for high-value Intellectual Property (IP) to be categorized as a \"crown jewel.\"", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A03", + "objective": "criteria are defined for Technology Assets, Applications and Services (TAAS) to be categorized as a \"crown jewel,\" based on business process criticality or dependency relationships.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A04", + "objective": "the physical and/or logical location of HVAs are documented.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A05", + "objective": "assigned owners are defined for HVAs", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A06", + "objective": "minimum protection mechanisms for HVAs are defined.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "GOV-21", + "ao_id": "GOV-21_A07", + "objective": "assurance requirements for HVAs are defined.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/IAC-01.4.json b/docs/api/assessment-objectives/IAC-01.4.json new file mode 100644 index 00000000..45ac074b --- /dev/null +++ b/docs/api/assessment-objectives/IAC-01.4.json @@ -0,0 +1,36 @@ +{ + "scf_control_id": "IAC-01.4", + "total": 3, + "assessment_objectives": [ + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A01", + "objective": "identity providers and authorization servers are employed to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A02", + "objective": "authentication and authorization decisions are made in accordance with organization-defined identification and authentication policy.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "IAC-01.4", + "ao_id": "IAC-01.4_A03", + "objective": "authentication and authorization decisions use organization-defined mechanisms.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/IAC-15.10.json b/docs/api/assessment-objectives/IAC-15.10.json new file mode 100644 index 00000000..530f5051 --- /dev/null +++ b/docs/api/assessment-objectives/IAC-15.10.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "IAC-15.10", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "IAC-15.10", + "ao_id": "IAC-15.10_A01", + "objective": "non-privileged accounts are separated between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/MON-03.json b/docs/api/assessment-objectives/MON-03.json index bf730830..2da42921 100644 --- a/docs/api/assessment-objectives/MON-03.json +++ b/docs/api/assessment-objectives/MON-03.json @@ -129,7 +129,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.03.01.a", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "SDP values:\nat a minimum and where applicable:\n(1) Authentication events:\n (a) Logons (Success/Failure)\n (b) Logoffs (Success)\n(2) Security Relevant File and Objects events:\n (a) Create (Success/Failure)\n (b) Access (Success/Failure)\n (c) Delete (Success/Failure)\n (d) Modify (Success/Failure)\n (e) Permission Modification (Success/Failure)\n (f) Ownership Modification (Success/Failure)\n(3) Export/Writes/downloads to devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(4) Import/Uploads from devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(5) User and Group Management events:\n (a) User add, delete, modify, disable, lock (Success/Failure)\n (b) Group/Role add, delete, modify (Success/Failure)\n6) Use of Privileged/Special Rights events:\n (a) Security or audit policy changes (Success/Failure)\n (b) Configuration changes (Success/Failure)\n(7) Admin or root-level access (Success/Failure)\n(8) Privilege/Role escalation (Success/Failure)\n(9) Audit and security relevant log data accesses (Success/Failure)\n(10) System reboot, restart, and shutdown (Success/Failure)\n(11) Print to a device (Success/Failure)\n(12) Print to a file (e.g., pdf format) (Success/Failure)\n(13) Application (e.g., Adobe, Firefox, MS Office Suite) initialization (Success/Failure)\n\nFor additional guidance, see: OMB21-31 ML 1", + "scf_defined_parameters": "SDP values:\nat a minimum and where applicable:\n(1) Authentication events:\n (a) Logons (Success/Failure)\n (b) Logoffs (Success)\n(2) Security Relevant File and Objects events:\n (a) Create (Success/Failure)\n (b) Access (Success/Failure)\n (c) Delete (Success/Failure)\n (d) Modify (Success/Failure)\n (e) Permission Modification (Success/Failure)\n (f) Ownership Modification (Success/Failure)\n(3) Export/Writes/downloads to devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(4) Import/Uploads from devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)\n(5) User and Group Management events:\n (a) User add, delete, modify, disable, lock (Success/Failure)\n (b) Group/Role add, delete, modify (Success/Failure)\n6) Use of Privileged/Special Rights events:\n (a) Security or audit policy changes (Success/Failure)\n (b) Configuration changes (Success/Failure)\n(7) Admin or root-level access (Success/Failure)\n(8) Privilege/Role escalation (Success/Failure)\n(9) Audit and security relevant log data accesses (Success/Failure)\n(10) System reboot, restart, and shutdown (Success/Failure)\n(11) Print to a device (Success/Failure)\n(12) Print to a file (e.g., pdf format) (Success/Failure)\n(13) Application (e.g., Adobe, Firefox, MS Office Suite) initialization (Success/Failure)\n\nFor additional guidance, see: OMB21-31 ML 1", "org_defined_parameters": "" }, { diff --git a/docs/api/assessment-objectives/NET-06.8.json b/docs/api/assessment-objectives/NET-06.8.json new file mode 100644 index 00000000..f2630eac --- /dev/null +++ b/docs/api/assessment-objectives/NET-06.8.json @@ -0,0 +1,36 @@ +{ + "scf_control_id": "NET-06.8", + "total": 3, + "assessment_objectives": [ + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A01", + "objective": "automated mechanisms separate network appliance functions (e.g., management, control and data planes).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A02", + "objective": "separation prevents ordinary traffic from accessing functions that manage network appliances.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "NET-06.8", + "ao_id": "NET-06.8_A03", + "objective": "separation prevents ordinary traffic from accessing functions that affect network operations.", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/NET-06.9.json b/docs/api/assessment-objectives/NET-06.9.json new file mode 100644 index 00000000..6fd2d96e --- /dev/null +++ b/docs/api/assessment-objectives/NET-06.9.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "NET-06.9", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "NET-06.9", + "ao_id": "NET-06.9_A01", + "objective": "subnetworks are physically or logically separate to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/PRI-01.12.json b/docs/api/assessment-objectives/PRI-01.12.json new file mode 100644 index 00000000..020573cb --- /dev/null +++ b/docs/api/assessment-objectives/PRI-01.12.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "PRI-01.12", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "PRI-01.12", + "ao_id": "PRI-01.12_A01", + "objective": "the organization's data privacy principles are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "PRI-01.12", + "ao_id": "PRI-01.12_A02", + "objective": "the organization's data privacy principles are formally incorporated into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-01.1.json b/docs/api/assessment-objectives/QTS-01.1.json new file mode 100644 index 00000000..63a6f12c --- /dev/null +++ b/docs/api/assessment-objectives/QTS-01.1.json @@ -0,0 +1,56 @@ +{ + "scf_control_id": "QTS-01.1", + "total": 5, + "assessment_objectives": [ + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A01", + "objective": "a formal, documented quantum security policy is established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A02", + "objective": "the quantum security policy conveys executive management's intent.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A03", + "objective": "the quantum security policy provides organizational direction and expected behaviors.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A04", + "objective": "the quantum security policy is reviewed at least annually.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.1", + "ao_id": "QTS-01.1_A05", + "objective": "the quantum security policy is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-01.2.json b/docs/api/assessment-objectives/QTS-01.2.json new file mode 100644 index 00000000..97a4ca7d --- /dev/null +++ b/docs/api/assessment-objectives/QTS-01.2.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "QTS-01.2", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "QTS-01.2", + "ao_id": "QTS-01.2_A01", + "objective": "a classification scheme exists to determine confidentiality shelf-life.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.2", + "ao_id": "QTS-01.2_A02", + "objective": "the shelf-life classification is used as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-01.3.json b/docs/api/assessment-objectives/QTS-01.3.json new file mode 100644 index 00000000..706d1503 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-01.3.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-01.3", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-01.3", + "ao_id": "QTS-01.3_A01", + "objective": "Technology Assets, Applications, Services and Data (TAASD) are classified according to confidentiality shelf-life.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-01.4.json b/docs/api/assessment-objectives/QTS-01.4.json new file mode 100644 index 00000000..c47bc1fb --- /dev/null +++ b/docs/api/assessment-objectives/QTS-01.4.json @@ -0,0 +1,56 @@ +{ + "scf_control_id": "QTS-01.4", + "total": 5, + "assessment_objectives": [ + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A01", + "objective": "Harvest Now, Decrypt Later (HNDL) risk is mitigated through Zero Trust Network Access (ZTNA).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A02", + "objective": "ZTNA enforces continuous authentication.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A03", + "objective": "ZTNA enforces data microsegmentation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A04", + "objective": "ZTNA enforces least privilege.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01.4", + "ao_id": "QTS-01.4_A05", + "objective": "ZTNA enforces identity-based access control.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-01.json b/docs/api/assessment-objectives/QTS-01.json new file mode 100644 index 00000000..fe70549d --- /dev/null +++ b/docs/api/assessment-objectives/QTS-01.json @@ -0,0 +1,36 @@ +{ + "scf_control_id": "QTS-01", + "total": 3, + "assessment_objectives": [ + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A01", + "objective": "an executive-sponsored quantum risk governance structure is established that institutionalizes quantum risk in the same manner as other enterprise risks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A02", + "objective": "a named migration lead with defined authority is assigned.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-01", + "ao_id": "QTS-01_A03", + "objective": "quantum risk is treated as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-02.1.json b/docs/api/assessment-objectives/QTS-02.1.json new file mode 100644 index 00000000..96043fed --- /dev/null +++ b/docs/api/assessment-objectives/QTS-02.1.json @@ -0,0 +1,56 @@ +{ + "scf_control_id": "QTS-02.1", + "total": 5, + "assessment_objectives": [ + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A01", + "objective": "each Post-Quantum Cryptography (PQC) deviation is governed through a formal cryptographic exception register.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A02", + "objective": "the exception register contains the asset and/or process owner(s).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A03", + "objective": "the exception register contains compensating control(s).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A04", + "objective": "the exception register contains the planned remediation date.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02.1", + "ao_id": "QTS-02.1_A05", + "objective": "the exception register contains the re-evaluation date.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-02.2.json b/docs/api/assessment-objectives/QTS-02.2.json new file mode 100644 index 00000000..85d611e1 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-02.2.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-02.2", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-02.2", + "ao_id": "QTS-02.2_A01", + "objective": "short-term compensating measures are implemented for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-02.3.json b/docs/api/assessment-objectives/QTS-02.3.json new file mode 100644 index 00000000..ac8be861 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-02.3.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-02.3", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-02.3", + "ao_id": "QTS-02.3_A01", + "objective": "progress is measured in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-02.json b/docs/api/assessment-objectives/QTS-02.json new file mode 100644 index 00000000..27cf8916 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-02.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-02", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A01", + "objective": "a Cryptographic Agility Risk Assessment (CARA) methodology is defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A02", + "objective": "a CARA is performed to map Technology Assets, Applications, Services and Data (TAASD).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A03", + "objective": "the CARA identifies TAASD most vulnerable to quantum-enabled cryptanalytic threats.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-02", + "ao_id": "QTS-02_A04", + "objective": "the CARA prioritizes TAASD based on potential business impact.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-03.1.json b/docs/api/assessment-objectives/QTS-03.1.json new file mode 100644 index 00000000..8d15abf4 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-03.1.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "QTS-03.1", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "QTS-03.1", + "ao_id": "QTS-03.1_A01", + "objective": "sufficient resources are allocated to transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.1", + "ao_id": "QTS-03.1_A02", + "objective": "hybrid cryptography is supported during a defined transition period, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-03.2.json b/docs/api/assessment-objectives/QTS-03.2.json new file mode 100644 index 00000000..9ef20bc6 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-03.2.json @@ -0,0 +1,36 @@ +{ + "scf_control_id": "QTS-03.2", + "total": 3, + "assessment_objectives": [ + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A01", + "objective": "reportable metrics for Post-Quantum Cryptography (PQC) migration are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A02", + "objective": "the metrics measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.2", + "ao_id": "QTS-03.2_A03", + "objective": "the metrics report progress periodically to executive leadership.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-03.3.json b/docs/api/assessment-objectives/QTS-03.3.json new file mode 100644 index 00000000..d2017da5 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-03.3.json @@ -0,0 +1,36 @@ +{ + "scf_control_id": "QTS-03.3", + "total": 3, + "assessment_objectives": [ + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A01", + "objective": "vendors are required to disclose Post-Quantum Cryptography (PQC) support roadmaps.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A02", + "objective": "the roadmaps include identification of PQC-related limitations.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03.3", + "ao_id": "QTS-03.3_A03", + "objective": "the roadmaps include supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-03.4.json b/docs/api/assessment-objectives/QTS-03.4.json new file mode 100644 index 00000000..fd730411 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-03.4.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-03.4", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-03.4", + "ao_id": "QTS-03.4_A01", + "objective": "vendors are contractually obligated to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-03.json b/docs/api/assessment-objectives/QTS-03.json new file mode 100644 index 00000000..f7576996 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-03.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-03", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A01", + "objective": "a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) is developed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A02", + "objective": "the PQCAP enables cryptographic agility.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A03", + "objective": "the PQCAP aligns with evolving security standards.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-03", + "ao_id": "QTS-03_A04", + "objective": "the PQCAP defines the approach for selecting and implementing PQC algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-04.1.json b/docs/api/assessment-objectives/QTS-04.1.json new file mode 100644 index 00000000..fa259b7d --- /dev/null +++ b/docs/api/assessment-objectives/QTS-04.1.json @@ -0,0 +1,76 @@ +{ + "scf_control_id": "QTS-04.1", + "total": 7, + "assessment_objectives": [ + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A01", + "objective": "a current inventory of cryptographic assets is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A02", + "objective": "the inventory includes algorithms (asymmetric and symmetric).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A03", + "objective": "the inventory includes key lengths.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A04", + "objective": "the inventory includes libraries.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A05", + "objective": "the inventory includes protocols.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A06", + "objective": "the inventory includes associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.1", + "ao_id": "QTS-04.1_A07", + "objective": "the inventory includes Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-04.2.json b/docs/api/assessment-objectives/QTS-04.2.json new file mode 100644 index 00000000..5bf257c4 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-04.2.json @@ -0,0 +1,56 @@ +{ + "scf_control_id": "QTS-04.2", + "total": 5, + "assessment_objectives": [ + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A01", + "objective": "a Cryptographic Bill of Materials (CBOM) is maintained to analyze the organization's cryptographic architecture.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A02", + "objective": "the CBOM includes hardware.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A03", + "objective": "the CBOM includes firmware.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A04", + "objective": "the CBOM includes software modules.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.2", + "ao_id": "QTS-04.2_A05", + "objective": "the CBOM includes communication protocols.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-04.3.json b/docs/api/assessment-objectives/QTS-04.3.json new file mode 100644 index 00000000..c36ab126 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-04.3.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-04.3", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A01", + "objective": "a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A02", + "objective": "the inventory includes public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A03", + "objective": "the inventory includes long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04.3", + "ao_id": "QTS-04.3_A04", + "objective": "the inventory includes TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-04.json b/docs/api/assessment-objectives/QTS-04.json new file mode 100644 index 00000000..9f701d3f --- /dev/null +++ b/docs/api/assessment-objectives/QTS-04.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "QTS-04", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "QTS-04", + "ao_id": "QTS-04_A01", + "objective": "means to gain situational awareness into the organization's current cryptographic landscape through a formal discovery process are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-04", + "ao_id": "QTS-04_A02", + "objective": "the discovery process uses available tools to generate situational awareness.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-05.1.json b/docs/api/assessment-objectives/QTS-05.1.json new file mode 100644 index 00000000..dd385c94 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-05.1.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-05.1", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A01", + "objective": "a quantum threat intelligence function is established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A02", + "objective": "the function monitors cryptanalytic threat developments.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A03", + "objective": "the function monitors quantum computing capability advances.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05.1", + "ao_id": "QTS-05.1_A04", + "objective": "the function monitors NIST and/or regulatory updates to approved algorithm lists.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-05.2.json b/docs/api/assessment-objectives/QTS-05.2.json new file mode 100644 index 00000000..d3555594 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-05.2.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-05.2", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-05.2", + "ao_id": "QTS-05.2_A01", + "objective": "stakeholders participation in sector-appropriate quantum security forums.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-05.json b/docs/api/assessment-objectives/QTS-05.json new file mode 100644 index 00000000..413bf611 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-05.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-05", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A01", + "objective": "differentiated quantum security training content is developed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A02", + "objective": "differentiated quantum security awareness training to the general workforce.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A03", + "objective": "differentiated quantum security awareness training to technical roles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-05", + "ao_id": "QTS-05_A04", + "objective": "differentiated quantum security awareness training to leadership roles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.1.json b/docs/api/assessment-objectives/QTS-06.1.json new file mode 100644 index 00000000..f666c409 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.1.json @@ -0,0 +1,56 @@ +{ + "scf_control_id": "QTS-06.1", + "total": 5, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A01", + "objective": "validated entropy sources and random bit generators comply with NIST SP 800-90B.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A02", + "objective": "the entropy sources support Post-Quantum Cryptography (PQC) key generation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A03", + "objective": "the entropy sources support nonce generation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A04", + "objective": "the entropy sources support probabilistic algorithm inputs.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.1", + "ao_id": "QTS-06.1_A05", + "objective": "the entropy sources support key validation.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.10.json b/docs/api/assessment-objectives/QTS-06.10.json new file mode 100644 index 00000000..e2798c9b --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.10.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-06.10", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.10", + "ao_id": "QTS-06.10_A01", + "objective": "universal interface is used to bridge established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.2.json b/docs/api/assessment-objectives/QTS-06.2.json new file mode 100644 index 00000000..8c9f9c66 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.2.json @@ -0,0 +1,56 @@ +{ + "scf_control_id": "QTS-06.2", + "total": 5, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A01", + "objective": "stateful hash-based signature schemes conform with NIST SP 800-208.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A02", + "objective": "state-management controls necessary to prevent one-time key reuse are required.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A03", + "objective": "stateful hash-based signatures are enforced for firmware signing.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A04", + "objective": "stateful hash-based signatures are enforced for secure boot signing.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.2", + "ao_id": "QTS-06.2_A05", + "objective": "stateful hash-based signatures are enforced for other long-lifetime code-signing use cases.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.3.json b/docs/api/assessment-objectives/QTS-06.3.json new file mode 100644 index 00000000..92d12bb4 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.3.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "QTS-06.3", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.3", + "ao_id": "QTS-06.3_A01", + "objective": "Post-Quantum Cryptography (PQC) algorithms are approved.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.3", + "ao_id": "QTS-06.3_A02", + "objective": "required validation levels for approved algorithms (e.g., FIPS 140-3 validated) are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.4.json b/docs/api/assessment-objectives/QTS-06.4.json new file mode 100644 index 00000000..2461c152 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.4.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-06.4", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.4", + "ao_id": "QTS-06.4_A01", + "objective": "Technology Assets, Applications and/or Services (TAAS) are configured to use FIPS 140-3 validated cryptographic modules, where applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.5.json b/docs/api/assessment-objectives/QTS-06.5.json new file mode 100644 index 00000000..7e70d761 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.5.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-06.5", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.5", + "ao_id": "QTS-06.5_A01", + "objective": "quantum-vulnerable and otherwise deprecated cryptographic algorithms are prohibited from being used.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.6.json b/docs/api/assessment-objectives/QTS-06.6.json new file mode 100644 index 00000000..0d52b6f4 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.6.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-06.6", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A01", + "objective": "cryptographic keys and certificates are managed in a manner that supports Post-Quantum Cryptography (PQC) transition.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A02", + "objective": "validity periods for quantum-vulnerable certificates are shortened to reduce exposure.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A03", + "objective": "Public Key Infrastructure (PKI) is prepared for PQC roots of trust or dual-root hybrid trust models.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.6", + "ao_id": "QTS-06.6_A04", + "objective": "key generation uses quantum-safe entropy sources.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.7.json b/docs/api/assessment-objectives/QTS-06.7.json new file mode 100644 index 00000000..462c2f1d --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.7.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-06.7", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.7", + "ao_id": "QTS-06.7_A01", + "objective": "Public Key Infrastructure (PKI) trust anchors are transitioned to quantum-safe algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.8.json b/docs/api/assessment-objectives/QTS-06.8.json new file mode 100644 index 00000000..653df490 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.8.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-06.8", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A01", + "objective": "Technology Assets, Applications and/or Services (TAAS) are configured to prevent attackers from forcing quantum-vulnerable algorithms.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A02", + "objective": "integrity-protected algorithm negotiation is used (e.g., TLS 1.3 handshake transcript).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A03", + "objective": "negotiation of classical-only cipher suites is disallowed once Post-Quantum Cryptography (PQC) is deployed.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.8", + "ao_id": "QTS-06.8_A04", + "objective": "downgrade attempts are monitored.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.9.json b/docs/api/assessment-objectives/QTS-06.9.json new file mode 100644 index 00000000..ac5bbe72 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.9.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-06.9", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A01", + "objective": "hybrid/composite algorithms are leveraged as a transition path to Post-Quantum Cryptography (PQC) solutions, where applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A02", + "objective": "solutions support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A03", + "objective": "certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-06.9", + "ao_id": "QTS-06.9_A04", + "objective": "plans exist for eventual removal of classical algorithms once PQC confidence is sufficient.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-06.json b/docs/api/assessment-objectives/QTS-06.json new file mode 100644 index 00000000..54a35c3e --- /dev/null +++ b/docs/api/assessment-objectives/QTS-06.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "QTS-06", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "QTS-06", + "ao_id": "QTS-06_A01", + "objective": "design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) is validated to support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-07.json b/docs/api/assessment-objectives/QTS-07.json new file mode 100644 index 00000000..01c27221 --- /dev/null +++ b/docs/api/assessment-objectives/QTS-07.json @@ -0,0 +1,56 @@ +{ + "scf_control_id": "QTS-07", + "total": 5, + "assessment_objectives": [ + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A01", + "objective": "capability exists to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A02", + "objective": "pre-identified algorithm alternates are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A03", + "objective": "tested rollback and roll-forward procedures are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A04", + "objective": "customer and/or counterparty communication templates are established.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-07", + "ao_id": "QTS-07_A05", + "objective": "incident response rehearsals against defined scenarios are conducted.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/QTS-08.json b/docs/api/assessment-objectives/QTS-08.json new file mode 100644 index 00000000..9427483d --- /dev/null +++ b/docs/api/assessment-objectives/QTS-08.json @@ -0,0 +1,46 @@ +{ + "scf_control_id": "QTS-08", + "total": 4, + "assessment_objectives": [ + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A01", + "objective": "Post-Quantum Cryptography (PQC) implementations are validated for functional and cryptographic requirements.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A02", + "objective": "each PQC implementation is interoperable with counterparties and successors.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A03", + "objective": "each PQC implementation meets performance criteria for its use case.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "QTS-08", + "ao_id": "QTS-08_A04", + "objective": "test results and exceptions are documented.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/RSK-01.json b/docs/api/assessment-objectives/RSK-01.json index b4500a04..9ef2213f 100644 --- a/docs/api/assessment-objectives/RSK-01.json +++ b/docs/api/assessment-objectives/RSK-01.json @@ -119,7 +119,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.17.03.b", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", + "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", "org_defined_parameters": "" }, { diff --git a/docs/api/assessment-objectives/RSK-03.2.json b/docs/api/assessment-objectives/RSK-03.2.json new file mode 100644 index 00000000..31fe8a84 --- /dev/null +++ b/docs/api/assessment-objectives/RSK-03.2.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "RSK-03.2", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "RSK-03.2", + "ao_id": "RSK-03.2_A01", + "objective": "a risk owner is identified for each item in the risk register to ensure clear accountability for unremediated risks.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/RSK-09.json b/docs/api/assessment-objectives/RSK-09.json index f96faeab..a08fde59 100644 --- a/docs/api/assessment-objectives/RSK-09.json +++ b/docs/api/assessment-objectives/RSK-09.json @@ -309,7 +309,7 @@ "pptdf": "Process", "origin": "171A_R3_A.03.17.03.b", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", + "scf_defined_parameters": "at a minimum, integrate Supply Chain Risk Management (SCRM) into acquisition/procurement policies, provide adequate SCRM resources, define the SCRM control baseline, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents", "org_defined_parameters": "" } ] diff --git a/docs/api/assessment-objectives/SAT-04.1.json b/docs/api/assessment-objectives/SAT-04.1.json new file mode 100644 index 00000000..ff0625f8 --- /dev/null +++ b/docs/api/assessment-objectives/SAT-04.1.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "SAT-04.1", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "SAT-04.1", + "ao_id": "SAT-04.1_A01", + "objective": "individual training results are monitored.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SAT-04.1", + "ao_id": "SAT-04.1_A02", + "objective": "training results are reported to applicable stakeholders.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/SEA-01.4.json b/docs/api/assessment-objectives/SEA-01.4.json new file mode 100644 index 00000000..0418c043 --- /dev/null +++ b/docs/api/assessment-objectives/SEA-01.4.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "SEA-01.4", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "SEA-01.4", + "ao_id": "SEA-01.4_A01", + "objective": "security architecture principles are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-01.4", + "ao_id": "SEA-01.4_A02", + "objective": "security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/SEA-01.5.json b/docs/api/assessment-objectives/SEA-01.5.json new file mode 100644 index 00000000..91b46eb5 --- /dev/null +++ b/docs/api/assessment-objectives/SEA-01.5.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "SEA-01.5", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "SEA-01.5", + "ao_id": "SEA-01.5_A01", + "objective": "secure architecture principles are incorporated into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/SEA-08.2.json b/docs/api/assessment-objectives/SEA-08.2.json new file mode 100644 index 00000000..ccfb40cf --- /dev/null +++ b/docs/api/assessment-objectives/SEA-08.2.json @@ -0,0 +1,36 @@ +{ + "scf_control_id": "SEA-08.2", + "total": 3, + "assessment_objectives": [ + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A01", + "objective": "a frequency is defined for information to be regenerated or refreshed.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A02", + "objective": "information is generated or refreshed per an organization-defined frequency.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "SEA-08.2", + "ao_id": "SEA-08.2_A03", + "objective": "mechanisms exist to delete information when no longer needed.", + "pptdf": "Data", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/TDA-06.7.json b/docs/api/assessment-objectives/TDA-06.7.json new file mode 100644 index 00000000..321a8548 --- /dev/null +++ b/docs/api/assessment-objectives/TDA-06.7.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "TDA-06.7", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "TDA-06.7", + "ao_id": "TDA-06.7_A01", + "objective": "organization-approved programming language(s) for software development are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-06.7", + "ao_id": "TDA-06.7_A02", + "objective": "the justification for program language alignment selection decisions are documented.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/TDA-13.1.json b/docs/api/assessment-objectives/TDA-13.1.json new file mode 100644 index 00000000..043083e3 --- /dev/null +++ b/docs/api/assessment-objectives/TDA-13.1.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "TDA-13.1", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "TDA-13.1", + "ao_id": "TDA-13.1_A01", + "objective": "a cybersecurity knowledge and skills register for developers is maintained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/TDA-13.2.json b/docs/api/assessment-objectives/TDA-13.2.json new file mode 100644 index 00000000..f6ad2de7 --- /dev/null +++ b/docs/api/assessment-objectives/TDA-13.2.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "TDA-13.2", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "TDA-13.2", + "ao_id": "TDA-13.2_A01", + "objective": "requisite skillsets for developers for Secure Software Development Practices (SSDP) are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-13.2", + "ao_id": "TDA-13.2_A02", + "objective": "developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP) are trained.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/TDA-19.1.json b/docs/api/assessment-objectives/TDA-19.1.json new file mode 100644 index 00000000..efadfd40 --- /dev/null +++ b/docs/api/assessment-objectives/TDA-19.1.json @@ -0,0 +1,26 @@ +{ + "scf_control_id": "TDA-19.1", + "total": 2, + "assessment_objectives": [ + { + "scf_control_id": "TDA-19.1", + "ao_id": "TDA-19.1_A01", + "objective": "personnel and/or role(s) authorized to receive security-relevant error messages are defined.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "TDA-19.1", + "ao_id": "TDA-19.1_A02", + "objective": "access to error messages are restricted to authorized personnel and/or role(s).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/THR-01.1.json b/docs/api/assessment-objectives/THR-01.1.json new file mode 100644 index 00000000..98488579 --- /dev/null +++ b/docs/api/assessment-objectives/THR-01.1.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "THR-01.1", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "THR-01.1", + "ao_id": "THR-01.1_A01", + "objective": "ongoing awareness of the current cyber threat environment is maintained as part of the Threat Intelligence Program (TIP).", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/THR-01.2.json b/docs/api/assessment-objectives/THR-01.2.json new file mode 100644 index 00000000..7ec8338b --- /dev/null +++ b/docs/api/assessment-objectives/THR-01.2.json @@ -0,0 +1,16 @@ +{ + "scf_control_id": "THR-01.2", + "total": 1, + "assessment_objectives": [ + { + "scf_control_id": "THR-01.2", + "ao_id": "THR-01.2_A01", + "objective": "advanced automation and analytics capabilities are implemented to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "pptdf": "Technology", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/assessment-objectives/TPM-05.json b/docs/api/assessment-objectives/TPM-05.json index 1c1fd3ef..fa5cda9a 100644 --- a/docs/api/assessment-objectives/TPM-05.json +++ b/docs/api/assessment-objectives/TPM-05.json @@ -49,7 +49,7 @@ "pptdf": "Data", "origin": "171A_R3_A.03.16.03.a", "assessment_rigor": "NIST 800-171", - "scf_defined_parameters": "SDP values: \n(1) For cloud service providers:\n (i) FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or\n (ii) meets security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline.\n(2) All other external service providers must meet NIST SP 800-171 R2.", + "scf_defined_parameters": "SDP values: \n(1) For cloud service providers:\n (i) FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or\n (ii) meets security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline.\n(2) All other external service providers must meet NIST SP 800-171 R2.", "org_defined_parameters": "" } ] diff --git a/docs/api/assessment-objectives/VPM-02.1.json b/docs/api/assessment-objectives/VPM-02.1.json new file mode 100644 index 00000000..40d7b2a5 --- /dev/null +++ b/docs/api/assessment-objectives/VPM-02.1.json @@ -0,0 +1,36 @@ +{ + "scf_control_id": "VPM-02.1", + "total": 3, + "assessment_objectives": [ + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A01", + "objective": "remediation and mitigation of Known Exploited Vulnerabilities (KEV) is prioritized.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A02", + "objective": "KEV remediation efforts reduce or remove public exposure to exploitation, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + }, + { + "scf_control_id": "VPM-02.1", + "ao_id": "VPM-02.1_A03", + "objective": "KEV remediation efforts expedite patch deployment actions, if applicable.", + "pptdf": "Process", + "origin": "SCF Created", + "assessment_rigor": "1", + "scf_defined_parameters": "", + "org_defined_parameters": "" + } + ] +} \ No newline at end of file diff --git a/docs/api/compensating-controls.json b/docs/api/compensating-controls.json index 0a0887d2..81ed9521 100644 --- a/docs/api/compensating-controls.json +++ b/docs/api/compensating-controls.json @@ -1,5 +1,5 @@ { - "total": 1305, + "total": 1371, "compensating_controls": [ { "control_id": "GOV-01.1", @@ -49,6 +49,22 @@ "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Commitment To Continual Improvements (GOV-01.3) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "GOV-01.4", + "risk_if_not_implemented": "Without Secure Practices Alignment Justification, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides third-party oversight and contractual controls that compensates for the absence of Secure Practices Alignment Justification (GOV-01.4) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-09", + "name": "Define Control Objectives", + "description": "Mechanisms exist to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", + "justification": "Define Control Objectives (GOV-09) provides overlapping security capability that compensates for the absence of Secure Practices Alignment Justification (GOV-01.4) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "GOV-02.1", "risk_if_not_implemented": "Without Exception Management, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -241,6 +257,22 @@ "justification": "Data Privacy Program (PRI-01) provides policy-level governance that compensates for the absence of Data Governance (GOV-10) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "GOV-10.1", + "risk_if_not_implemented": "Without Data Catalog, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "DCH-24", + "name": "Information Location", + "description": "Mechanisms exist to identify and document the location of information and the specific system components on which the information resides.", + "justification": "Information Location (DCH-24) provides overlapping security capability that compensates for the absence of Data Catalog (GOV-10.1) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Data Catalog (GOV-10.1) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "GOV-11", "risk_if_not_implemented": "Without Purpose Validation, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -497,6 +529,22 @@ "justification": "Audit Activities (CPL-04) provides detective monitoring capability that compensates for the absence of Assessment Objectives (AO) (GOV-19.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "GOV-19.3", + "risk_if_not_implemented": "Without Security, Compliance & Resilince Outsourcing Limitations, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "TPM-04", + "name": "Third-Party Services", + "description": "Mechanisms exist to mitigate the risks associated with third-party access to the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Services (TPM-04) provides third-party oversight and contractual controls that compensates for the absence of Security, Compliance & Resilince Outsourcing Limitations (GOV-19.3) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CPL-10", + "name": "Control Inheritance", + "description": "Mechanisms exist to define instances of control inheritance within assessment boundaries.", + "justification": "Control Inheritance (CPL-10) provides overlapping security capability that compensates for the absence of Security, Compliance & Resilince Outsourcing Limitations (GOV-19.3) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "GOV-20", "risk_if_not_implemented": "Without Mergers, Acquisitions & Divestitures (MA&D), residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -529,6 +577,22 @@ "justification": "Risk Assessment (RSK-04) provides periodic assessment and assurance that compensates for the absence of Virtual Data Room (VDR) (GOV-20.1) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "GOV-21", + "risk_if_not_implemented": "Without HVA / crown jewels protections, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Crown Jewels (GOV-21) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-05", + "name": "Risk Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "justification": "Risk Ranking (RSK-05) provides risk identification and prioritization that compensates for the absence of Crown Jewels (GOV-21) by enabling informed decisions about where to focus resources to manage residual exposure. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AAT-01.1", "risk_if_not_implemented": "Without AI & Autonomous Technologies-Related Legal Requirements Definition, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -577,6 +641,22 @@ "justification": "Third-Party Contract Requirements (TPM-05) provides third-party oversight that compensates for the absence of AI Model & Agent Inventory & Lifecycle Management (AAT-01.4) by extending security obligations contractually and monitoring third-party risk in lieu of direct control. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AAT-01.5", + "risk_if_not_implemented": "Without Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "AAT-01", + "name": "Artificial Intelligence (AI) & Autonomous Technologies Governance", + "description": "Mechanisms exist to ensure policies, processes, procedures and practices related to the mapping, measuring and managing of Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related risks are in place, transparent and implemented effectively.", + "justification": "Artificial Intelligence (AI) & Autonomous Technologies Governance (AAT-01) provides detective monitoring capability that compensates for the absence of Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization (AAT-01.5) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-04", + "name": "Risk Assessment", + "description": "Mechanisms exist to conduct recurring assessments of risk that includes the likelihood and magnitude of harm, from unauthorized access, use, disclosure, disruption, modification or destruction of the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Risk Assessment (RSK-04) provides periodic assessment and verification that compensates for the absence of Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization (AAT-01.5) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AAT-02", "risk_if_not_implemented": "Without Situational Awareness of AI & Autonomous Technologies, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -1249,6 +1329,38 @@ "justification": "Third-Party Management (TPM-01) provides third-party oversight that compensates for the absence of Digital Content Modification Logging (AAT-12.4) by extending security obligations contractually and monitoring third-party risk in lieu of direct control. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AAT-12.5", + "risk_if_not_implemented": "Without Training Data Source & Integrity, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "DCH-22", + "name": "Data Quality Operations", + "description": "Mechanisms exist to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", + "justification": "Data Quality Operations (DCH-22) provides overlapping security capability that compensates for the absence of Training Data Source & Integrity (AAT-12.5) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "AAT-10", + "name": "Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV)", + "description": "Mechanisms exist to implement Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices to enable Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related security, resilience and compliance-related conformity testing throughout the lifecycle of the AAT.", + "justification": "Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) (AAT-10) provides periodic assessment and verification that compensates for the absence of Training Data Source & Integrity (AAT-12.5) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "AAT-12.6", + "risk_if_not_implemented": "Without Prohibit Training, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides third-party oversight and contractual controls that compensates for the absence of Prohibit Training (AAT-12.6) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-14", + "name": "Information Sharing", + "description": "Mechanisms exist to utilize a process to assist users in making information sharing decisions to ensure data is appropriately protected.", + "justification": "Information Sharing (DCH-14) provides threat intelligence and situational awareness that compensates for the absence of Prohibit Training (AAT-12.6) by providing early warning of threats and informing proactive security posture adjustments. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AAT-13", "risk_if_not_implemented": "Without AI & Autonomous Technologies Stakeholder Diversity, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -2609,6 +2721,22 @@ "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Agent Output Integrity & Verification (AAT-29.23) by restricting system and data access to authorized users through alternative identity and access mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AAT-29.24", + "risk_if_not_implemented": "Without Resource Limiting, AI and autonomous technology risks may go ungoverned, leading to unintended outcomes, misuse, or data exposure.", + "compensating_control_1": { + "control_id": "CAP-01", + "name": "Capacity & Performance Management", + "description": "Mechanisms exist to facilitate the implementation of capacity management controls to ensure optimal system performance to meet expected and anticipated future capacity requirements.", + "justification": "Capacity & Performance Management (CAP-01) provides overlapping security capability that compensates for the absence of Resource Limiting (AAT-29.24) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Resource Limiting (AAT-29.24) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AAT-30", "risk_if_not_implemented": "Without Agentic Output Traceability & Repudiation, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -2705,6 +2833,22 @@ "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Business Process Task Enumeration (AAT-32.1) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AAT-33", + "risk_if_not_implemented": "Without Release Owner Gate (ROG) For AI-Augmented Content, AI and autonomous technology risks may go ungoverned, leading to unintended outcomes, misuse, or data exposure.", + "compensating_control_1": { + "control_id": "CHG-08", + "name": "Dual Approval For High-Impact Environments", + "description": "Mechanisms exist to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Dual Approval For High-Impact Environments (CHG-08) provides overlapping security capability that compensates for the absence of Release Owner Gate (ROG) For AI-Augmented Content (AAT-33) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-04", + "name": "Assigned Security, Compliance & Resilience Responsibilities", + "description": "Mechanisms exist to assign one or more qualified individuals with the mission and resources to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP).", + "justification": "Assigned Security, Compliance & Resilience Responsibilities (GOV-04) provides resilience and recovery capability that compensates for the absence of Release Owner Gate (ROG) For AI-Augmented Content (AAT-33) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AST-01.1", "risk_if_not_implemented": "Without Asset-Service Dependencies, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -3089,6 +3233,22 @@ "justification": "Media Storage (DCH-06) provides overlapping security capability that compensates for the absence of Management Approval For External Media Transfer (AST-05.1) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "AST-05.2", + "risk_if_not_implemented": "Without Technology Assets, Applications, Services and/or Data (TAASD) Storage, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "PES-03", + "name": "Physical Access Control", + "description": "Physical access control mechanisms exist to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", + "justification": "Physical Access Control (PES-03) provides access control enforcement that compensates for the absence of Technology Assets, Applications, Services and/or Data (TAASD) Storage (AST-05.2) by restricting system and data access through alternative identity and access management mechanisms. Given the facility and physical environment focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "PES-06", + "name": "Visitor Control", + "description": "Physical access control mechanisms exist to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible).", + "justification": "Visitor Control (PES-06) provides physical access control that compensates for the absence of Technology Assets, Applications, Services and/or Data (TAASD) Storage (AST-05.2) by preventing unauthorized physical interaction with systems and infrastructure. Given the facility and physical environment focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "AST-06", "risk_if_not_implemented": "Without Unattended End-User Equipment, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -5521,6 +5681,22 @@ "justification": "Security, Compliance & Resilience Assessments (CPL-03) provides periodic assessment and assurance that compensates for the absence of Evidence Sampling (CPL-03.7) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "CPL-03.8", + "risk_if_not_implemented": "Without Continuous Control Monitoring (CCM), security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "CPL-03", + "name": "Control Conformity Monitoring", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "justification": "Control Conformity Monitoring (CPL-03) provides detective monitoring capability that compensates for the absence of Continuous Control Monitoring (CCM) (CPL-03.8) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Continuous Control Monitoring (CCM) (CPL-03.8) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "CPL-04", "risk_if_not_implemented": "Without Audit Activities, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -6209,6 +6385,70 @@ "justification": "Access Enforcement (IAC-20) provides access control enforcement that compensates for the absence of Sensitive / Regulated Data Actions (CFG-08.1) by restricting system and data access to authorized users through alternative identity and access mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "CFG-09", + "risk_if_not_implemented": "Without Production Software Repository, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "CHG-02", + "name": "Configuration Change Control", + "description": "Mechanisms exist to govern the technical configuration change control processes.", + "justification": "Configuration Change Control (CHG-02) provides configuration and supply-chain hardening that compensates for the absence of Production Software Repository (CFG-09) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-05", + "name": "Software & Firmware Patching", + "description": "Mechanisms exist to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", + "justification": "Software & Firmware Patching (VPM-05) provides vulnerability management that compensates for the absence of Production Software Repository (CFG-09) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "CFG-09.1", + "risk_if_not_implemented": "Without Third-Party Libraries, third-party risks may go unmanaged, creating supply-chain exposure that compromises organizational systems or data.", + "compensating_control_1": { + "control_id": "TPM-03", + "name": "Supply Chain Risk Management (SCRM)", + "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", + "justification": "Supply Chain Risk Management (SCRM) (TPM-03) provides risk identification and prioritization that compensates for the absence of Third-Party Libraries (CFG-09.1) by enabling informed decisions about where to focus resources to manage residual exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Third-Party Libraries (CFG-09.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "CFG-09.2", + "risk_if_not_implemented": "Without Software Repository Protections, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Software Repository Protections (CFG-09.2) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "END-04", + "name": "Malicious Code Protection (Anti-Malware)", + "description": "Mechanisms exist to utilize antimalware technologies to detect and eradicate malicious code.", + "justification": "Malicious Code Protection (Anti-Malware) (END-04) provides overlapping security capability that compensates for the absence of Software Repository Protections (CFG-09.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "CFG-09.3", + "risk_if_not_implemented": "Without Software Development Repository, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "TDA-08", + "name": "Separation of Development, Testing and Operational Environments", + "description": "Mechanisms exist to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).", + "justification": "Separation of Development, Testing and Operational Environments (TDA-08) provides periodic assessment and verification that compensates for the absence of Software Development Repository (CFG-09.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CHG-04", + "name": "Access Restriction For Change", + "description": "Mechanisms exist to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.", + "justification": "Access Restriction For Change (CHG-04) provides access control enforcement that compensates for the absence of Software Development Repository (CFG-09.3) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "MON-01.1", "risk_if_not_implemented": "Without Intrusion Detection & Prevention Systems (IDS & IPS), security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -10321,6 +10561,22 @@ "justification": "Session Audit (MON-12) provides detective monitoring capability that compensates for the absence of Authenticate, Authorize and Audit (AAA) (IAC-01.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "IAC-01.4", + "risk_if_not_implemented": "Without Identity Providers (IdP) & Authorization Servers, unauthorized users may gain access to systems or data, increasing risk of data breaches and privilege escalation.", + "compensating_control_1": { + "control_id": "IAC-02", + "name": "Identification & Authentication for Organizational Users", + "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", + "justification": "Identification & Authentication for Organizational Users (IAC-02) provides access control enforcement that compensates for the absence of Identity Providers (IdP) & Authorization Servers (IAC-01.4) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-08", + "name": "Role-Based Access Control (RBAC)", + "description": "Mechanisms exist to enforce Role-Based Access Control (RBAC) for Technology Assets, Applications, Services and/or Data (TAASD) to restrict access to individuals assigned specific roles with legitimate business needs.", + "justification": "Role-Based Access Control (RBAC) (IAC-08) provides access control enforcement that compensates for the absence of Identity Providers (IdP) & Authorization Servers (IAC-01.4) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "IAC-02", "risk_if_not_implemented": "Without Identification & Authentication for Organizational Users, unauthorized users may gain access to systems or data, increasing risk of data breaches and insider threats.", @@ -11201,6 +11457,22 @@ "justification": "User Provisioning & De-Provisioning (IAC-07) provides access control enforcement that compensates for the absence of Emergency Accounts (IAC-15.9) by restricting system and data access to authorized users through alternative identity and access mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "IAC-15.10", + "risk_if_not_implemented": "Without Account Separation Between Infrastructure Environments, unauthorized users may gain access to systems or data, increasing risk of data breaches and privilege escalation.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Account Separation Between Infrastructure Environments (IAC-15.10) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-16", + "name": "Privileged Account Management (PAM)", + "description": "Mechanisms exist to restrict and control privileged access rights for users and Technology Assets, Applications and/or Services (TAAS).", + "justification": "Privileged Account Management (PAM) (IAC-16) provides access control enforcement that compensates for the absence of Account Separation Between Infrastructure Environments (IAC-15.10) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "IAC-16.2", "risk_if_not_implemented": "Without Privileged Account Separation, unauthorized users may gain access to systems or data, increasing risk of data breaches and insider threats.", @@ -13713,6 +13985,38 @@ "justification": "Boundary Protection (NET-03) provides network-level access restriction that compensates for the absence of Software Defined Networking (SDN) (NET-06.7) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "NET-06.8", + "risk_if_not_implemented": "Without Network Device Plane Segmentation, network defenses may be weakened, enabling lateral movement and exploitation of unprotected communication pathways.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Network Device Plane Segmentation (NET-06.8) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Network Device Plane Segmentation (NET-06.8) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "NET-06.9", + "risk_if_not_implemented": "Without Separate Subnets To Isolate Functions, network defenses may be weakened, enabling lateral movement and exploitation of unprotected communication pathways.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Separate Subnets To Isolate Functions (NET-06.9) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-04", + "name": "Data Flow Enforcement – Access Control Lists (ACLs)", + "description": "Mechanisms exist to implement and govern Access Control Lists (ACLs) to provide data flow enforcement that explicitly restrict network traffic to only what is authorized.", + "justification": "Data Flow Enforcement – Access Control Lists (ACLs) (NET-04) provides access control enforcement that compensates for the absence of Separate Subnets To Isolate Functions (NET-06.9) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "NET-07", "risk_if_not_implemented": "Without Network Connection Termination, network defenses are weakened, enabling lateral movement and exploitation of unprotected pathways.", @@ -15473,6 +15777,22 @@ "justification": "Data Privacy Program (PRI-01) provides policy-level governance that compensates for the absence of Reasonable Data Privacy Practices (PRI-01.11) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "PRI-01.12", + "risk_if_not_implemented": "Without Privacy-Aware Design, personal data may be processed without adequate privacy safeguards, increasing regulatory and reputational risk.", + "compensating_control_1": { + "control_id": "PRI-01", + "name": "Data Privacy Program", + "description": "Mechanisms exist to facilitate the implementation and operation of data protection controls throughout the data lifecycle to ensure all forms of Personal Data (PD) are processed lawfully, fairly and transparently.", + "justification": "Data Privacy Program (PRI-01) provides policy-level governance that compensates for the absence of Privacy-Aware Design (PRI-01.12) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Privacy-Aware Design (PRI-01.12) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "PRI-02", "risk_if_not_implemented": "Without Data Privacy Notice, personal data may be processed without appropriate safeguards, increasing regulatory and reputational risk.", @@ -17026,37 +17346,581 @@ } }, { - "control_id": "RSK-01.1", - "risk_if_not_implemented": "Without Risk Framing, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", + "control_id": "QTS-01", + "risk_if_not_implemented": "Without Quantum Risk Governance, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", "compensating_control_1": { + "control_id": "RSK-01", + "name": "Risk Management Program", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Quantum Risk Governance (QTS-01) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { "control_id": "GOV-01", "name": "Security, Compliance & Resilience Program (SCRP)", "description": "Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.", - "justification": "Security, Compliance & Resilience Program (SCRP) (GOV-01) provides resilience and recovery capability that compensates for the absence of Risk Framing (RSK-01.1) by ensuring the organization can restore operations and data when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." - }, - "compensating_control_2": { - "control_id": "CPL-01", - "name": "Statutory, Regulatory & Contractual Compliance", - "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", - "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides overlapping security capability that compensates for the absence of Risk Framing (RSK-01.1) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + "justification": "Security, Compliance & Resilience Program (SCRP) (GOV-01) provides resilience and recovery capability that compensates for the absence of Quantum Risk Governance (QTS-01) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, { - "control_id": "RSK-01.2", - "risk_if_not_implemented": "Without Risk Management Resourcing, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", + "control_id": "QTS-01.1", + "risk_if_not_implemented": "Without Quantum Security Policy, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", "compensating_control_1": { - "control_id": "CPL-01", - "name": "Statutory, Regulatory & Contractual Compliance", - "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", - "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides overlapping security capability that compensates for the absence of Risk Management Resourcing (RSK-01.2) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + "control_id": "GOV-01", + "name": "Security, Compliance & Resilience Program (SCRP)", + "description": "Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.", + "justification": "Publishing Security, Compliance & Resilience Documentation (GOV-02) provides resilience and recovery capability that compensates for the absence of Quantum Security Policy (QTS-01.1) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." }, "compensating_control_2": { - "control_id": "RSK-01", - "name": "Risk Management Program", - "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls.", - "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Risk Management Resourcing (RSK-01.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." - } - }, + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Quantum Security Policy (QTS-01.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-01.2", + "risk_if_not_implemented": "Without Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization (QTS-01.2) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-05", + "name": "Risk Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "justification": "Risk Ranking (RSK-05) provides risk identification and prioritization that compensates for the absence of Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization (QTS-01.2) by enabling informed decisions about where to focus resources to manage residual exposure. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-01.3", + "risk_if_not_implemented": "Without Long-Lived Data Identification, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Long-Lived Data Identification (QTS-01.3) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-18", + "name": "Media & Data Retention", + "description": "Mechanisms exist to retain media and data in accordance with applicable statutory, regulatory and contractual obligations.", + "justification": "Media & Data Retention (DCH-18) provides overlapping security capability that compensates for the absence of Long-Lived Data Identification (QTS-01.3) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-01.4", + "risk_if_not_implemented": "Without Harvest Now, Decrypt Later (HNDL) Mitigation, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CRY-03", + "name": "Transmission Confidentiality", + "description": "Cryptographic mechanisms exist to protect the confidentiality of data being transmitted.", + "justification": "Transmission Confidentiality (CRY-03) provides overlapping security capability that compensates for the absence of Harvest Now, Decrypt Later (HNDL) Mitigation (QTS-01.4) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-03", + "name": "Boundary Protection", + "description": "Mechanisms exist to monitor and control communications at the external network boundary and at key internal boundaries within the network.", + "justification": "Boundary Protection (NET-03) provides network-level access restriction that compensates for the absence of Harvest Now, Decrypt Later (HNDL) Mitigation (QTS-01.4) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-02", + "risk_if_not_implemented": "Without Cryptographic Agility Risk Assessment (CARA), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "RSK-04", + "name": "Risk Assessment", + "description": "Mechanisms exist to conduct recurring assessments of risk that includes the likelihood and magnitude of harm, from unauthorized access, use, disclosure, disruption, modification or destruction of the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Risk Assessment (RSK-04) provides periodic assessment and verification that compensates for the absence of Cryptographic Agility Risk Assessment (CARA) (QTS-02) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Cryptographic Agility Risk Assessment (CARA) (QTS-02) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-02.1", + "risk_if_not_implemented": "Without Cryptographic Exception Register, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CPL-12", + "name": "Statement of Applicability (SOA)", + "description": "Mechanisms exist to produce a Statement of Applicability (SOA), or similar document, for compliance-related scoping activities.", + "justification": "Statement of Applicability (SOA) (CPL-12) provides overlapping security capability that compensates for the absence of Cryptographic Exception Register (QTS-02.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-06", + "name": "Risk Remediation", + "description": "Mechanisms exist to remediate risks to an acceptable level.", + "justification": "Risk Remediation (RSK-06) provides vulnerability management that compensates for the absence of Cryptographic Exception Register (QTS-02.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-02.2", + "risk_if_not_implemented": "Without Compensating Controls for Quantum-Vulnerable Systems, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Compensating Controls for Quantum-Vulnerable Systems (QTS-02.2) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Compensating Controls for Quantum-Vulnerable Systems (QTS-02.2) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-02.3", + "risk_if_not_implemented": "Without Crypto Agility Maturity Assessment, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CPL-03", + "name": "Control Conformity Monitoring", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "justification": "Control Conformity Monitoring (CPL-03) provides detective monitoring capability that compensates for the absence of Crypto Agility Maturity Assessment (QTS-02.3) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-02", + "name": "Assessments", + "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.", + "justification": "Assessments (IAO-02) provides periodic assessment and verification that compensates for the absence of Crypto Agility Maturity Assessment (QTS-02.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03", + "risk_if_not_implemented": "Without Post-Quantum Cryptography Agility Plan (PSCAP), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "RSK-01", + "name": "Risk Management Program", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Post-Quantum Cryptography Agility Plan (PSCAP) (QTS-03) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography Agility Plan (PSCAP) (QTS-03) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03.1", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support (QTS-03.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CHG-01", + "name": "Change Management Program", + "description": "Mechanisms exist to facilitate the implementation of a change management program.", + "justification": "Change Management Program (CHG-01) provides policy-level governance that compensates for the absence of Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support (QTS-03.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03.2", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Migration Progress Oversight, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "GOV-05", + "name": "Measures of Performance", + "description": "Mechanisms exist to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "justification": "Measures of Performance (GOV-05) provides overlapping security capability that compensates for the absence of Post-Quantum Cryptography (PQC) Migration Progress Oversight (QTS-03.2) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-11", + "name": "Risk Monitoring", + "description": "Mechanisms exist to ensure risk monitoring as an integral part of the continuous monitoring strategy that includes monitoring the effectiveness of security, compliance and resilience controls, compliance and change management.", + "justification": "Risk Monitoring (RSK-11) provides detective monitoring capability that compensates for the absence of Post-Quantum Cryptography (PQC) Migration Progress Oversight (QTS-03.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03.3", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Supply Chain Visibility, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TPM-08", + "name": "Review of Third-Party Services", + "description": "Mechanisms exist to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls.", + "justification": "Review of Third-Party Services (TPM-08) provides periodic assessment and verification that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Visibility (QTS-03.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TPM-05", + "name": "Third-Party Contract Requirements", + "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Contract Requirements (TPM-05) provides third-party oversight and contractual controls that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Visibility (QTS-03.3) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-03.4", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TPM-03", + "name": "Supply Chain Risk Management (SCRM)", + "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", + "justification": "Supply Chain Risk Management (SCRM) (TPM-03) provides risk identification and prioritization that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements (QTS-03.4) by enabling informed decisions about where to focus resources to manage residual exposure. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TPM-05", + "name": "Third-Party Contract Requirements", + "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Contract Requirements (TPM-05) provides third-party oversight and contractual controls that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements (QTS-03.4) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-04", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Discovery & Visibility, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Post-Quantum Cryptography (PQC) Discovery & Visibility (QTS-04) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Post-Quantum Cryptography (PQC) Discovery & Visibility (QTS-04) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-04.1", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Asset Inventory, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Post-Quantum Cryptography (PQC) Asset Inventory (QTS-04.1) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Asset Inventory (QTS-04.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-04.2", + "risk_if_not_implemented": "Without Cryptographic Bill of Materials (CBOM), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Cryptographic Bill of Materials (CBOM) (QTS-04.2) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-01", + "name": "Configuration Management Program", + "description": "Mechanisms exist to facilitate the implementation of configuration management controls.", + "justification": "Configuration Management Program (CFG-01) provides policy-level governance that compensates for the absence of Cryptographic Bill of Materials (CBOM) (QTS-04.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-04.3", + "risk_if_not_implemented": "Without Post-Quantum Cryptography Exposure, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "VPM-03", + "name": "Vulnerability Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information.", + "justification": "Vulnerability Ranking (VPM-03) provides vulnerability management that compensates for the absence of Post-Quantum Cryptography Exposure (QTS-04.3) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-02", + "name": "Risk-Based Security Categorization", + "description": "Mechanisms exist to categorize Technology Assets, Applications, Services and/or Data (TAASD) in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", + "justification": "Risk-Based Security Categorization (RSK-02) provides risk identification and prioritization that compensates for the absence of Post-Quantum Cryptography Exposure (QTS-04.3) by enabling informed decisions about where to focus resources to manage residual exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-05", + "risk_if_not_implemented": "Without Quantum Security Awareness, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "SAT-02", + "name": "Security, Compliance & Resilience Awareness Training", + "description": "Mechanisms exist to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function.", + "justification": "Security, Compliance & Resilience Awareness Training (SAT-02) provides personnel training and awareness that compensates for the absence of Quantum Security Awareness (QTS-05) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Quantum Security Awareness (QTS-05) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-05.1", + "risk_if_not_implemented": "Without Quantum Threat Intelligence Monitoring, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Quantum Threat Intelligence Monitoring (QTS-05.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "THR-03", + "name": "Threat Intelligence Feeds", + "description": "Mechanisms exist to maintain situational awareness of vulnerabilities and evolving threats by leveraging the knowledge of attacker tactics, techniques and procedures to facilitate the implementation of preventative and compensating controls.", + "justification": "Threat Intelligence Feeds (THR-03) provides threat intelligence and situational awareness that compensates for the absence of Quantum Threat Intelligence Monitoring (QTS-05.1) by providing early warning of threats and informing proactive security posture adjustments. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-05.2", + "risk_if_not_implemented": "Without Collaboration & Information Sharing, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "GOV-07", + "name": "Contacts With Groups & Associations", + "description": "Mechanisms exist to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.", + "justification": "Contacts With Groups & Associations (GOV-07) provides overlapping security capability that compensates for the absence of Collaboration & Information Sharing (QTS-05.2) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Collaboration & Information Sharing (QTS-05.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06", + "risk_if_not_implemented": "Without Crypto-Agility Architecture, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Crypto-Agility Architecture (QTS-06) by embedding security requirements into design processes as an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Crypto-Agility Architecture (QTS-06) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.1", + "risk_if_not_implemented": "Without Entropy Source & Random Bit Generation, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Entropy Source & Random Bit Generation (QTS-06.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Entropy Source & Random Bit Generation (QTS-06.1) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.2", + "risk_if_not_implemented": "Without Stateful Hash-Based Signatures for Firmware & Code Signing, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Stateful Hash-Based Signatures for Firmware & Code Signing (QTS-06.2) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-06", + "name": "Configuration Enforcement", + "description": "Automated mechanisms exist to monitor, enforce and report on configurations for endpoint devices.", + "justification": "Configuration Enforcement (CFG-06) provides configuration and supply-chain hardening that compensates for the absence of Stateful Hash-Based Signatures for Firmware & Code Signing (QTS-06.2) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.3", + "risk_if_not_implemented": "Without Approved Post-Quantum Cryptography (PQC) Algorithm Use, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Approved Post-Quantum Cryptography (PQC) Algorithm Use (QTS-06.3) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Approved Post-Quantum Cryptography (PQC) Algorithm Use (QTS-06.3) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.4", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Validation Requirements, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Validation Requirements (QTS-06.4) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-06", + "name": "Technical Verification", + "description": "Mechanisms exist to perform Information Assurance Program (IAP) activities to evaluate the design, implementation and effectiveness of technical security, compliance and resilience controls.", + "justification": "Technical Verification (IAO-06) provides periodic assessment and verification that compensates for the absence of Post-Quantum Cryptography (PQC) Validation Requirements (QTS-06.4) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.5", + "risk_if_not_implemented": "Without Deprecated Cryptographic Algorithms, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Deprecated Cryptographic Algorithms (QTS-06.5) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Deprecated Cryptographic Algorithms (QTS-06.5) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.6", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Key Management, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Key Management (QTS-06.6) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-12", + "name": "Certificate Monitoring", + "description": "Automated mechanisms exist to discover when new certificates are issued for organization-controlled domains.", + "justification": "Certificate Monitoring (CRY-12) provides detective monitoring capability that compensates for the absence of Post-Quantum Cryptography (PQC) Key Management (QTS-06.6) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.7", + "risk_if_not_implemented": "Without Quantum-Safe Public Key Infrastructure (PKI) Transition, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Quantum-Safe Public Key Infrastructure (PKI) Transition (QTS-06.7) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Quantum-Safe Public Key Infrastructure (PKI) Transition (QTS-06.7) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.8", + "risk_if_not_implemented": "Without Algorithm Negotiation Integrity, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "NET-09", + "name": "Session Integrity", + "description": "Mechanisms exist to protect the authenticity and integrity of communications sessions.", + "justification": "Session Integrity (NET-09) provides overlapping security capability that compensates for the absence of Algorithm Negotiation Integrity (QTS-06.8) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-03", + "name": "Transmission Confidentiality", + "description": "Cryptographic mechanisms exist to protect the confidentiality of data being transmitted.", + "justification": "Transmission Confidentiality (CRY-03) provides overlapping security capability that compensates for the absence of Algorithm Negotiation Integrity (QTS-06.8) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.9", + "risk_if_not_implemented": "Without Hybrid / Composite Cryptography, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Hybrid / Composite Cryptography (QTS-06.9) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Hybrid / Composite Cryptography (QTS-06.9) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-06.10", + "risk_if_not_implemented": "Without Cryptographic Application Programming Interface (API) Abstraction, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Cryptographic Application Programming Interface (API) Abstraction (QTS-06.10) by embedding security requirements into design processes as an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Cryptographic Application Programming Interface (API) Abstraction (QTS-06.10) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-07", + "risk_if_not_implemented": "Without Cryptographic Incident Response (Emergency Algorithm Transition), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "IRO-04", + "name": "Incident Response Plan (IRP)", + "description": "Mechanisms exist to maintain and make available a current and viable Incident Response Plan (IRP) to all stakeholders.", + "justification": "Incident Response Plan (IRP) (IRO-04) provides incident response capability that compensates for the absence of Cryptographic Incident Response (Emergency Algorithm Transition) (QTS-07) by enabling timely detection, containment, and recovery from security events. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "BCD-07", + "name": "Alternative Security Measures", + "description": "Mechanisms exist to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised.", + "justification": "Alternative Security Measures (BCD-07) provides overlapping security capability that compensates for the absence of Cryptographic Incident Response (Emergency Algorithm Transition) (QTS-07) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "QTS-08", + "risk_if_not_implemented": "Without PQC Implementation Validation & Interoperability Testing, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TDA-09", + "name": "Security, Compliance & Resilience Testing Throughout Development", + "description": "Mechanisms exist to require system developers/integrators consult with security, compliance and/or resilience personnel to: \n(1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability;\n(2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the control testing and evaluation process; and\n(3) Document the results.", + "justification": "Security, Compliance & Resilience Testing Throughout Development (TDA-09) provides periodic assessment and verification that compensates for the absence of PQC Implementation Validation & Interoperability Testing (QTS-08) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-06", + "name": "Technical Verification", + "description": "Mechanisms exist to perform Information Assurance Program (IAP) activities to evaluate the design, implementation and effectiveness of technical security, compliance and resilience controls.", + "justification": "Technical Verification (IAO-06) provides periodic assessment and verification that compensates for the absence of PQC Implementation Validation & Interoperability Testing (QTS-08) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "RSK-01.1", + "risk_if_not_implemented": "Without Risk Framing, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", + "compensating_control_1": { + "control_id": "GOV-01", + "name": "Security, Compliance & Resilience Program (SCRP)", + "description": "Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.", + "justification": "Security, Compliance & Resilience Program (SCRP) (GOV-01) provides resilience and recovery capability that compensates for the absence of Risk Framing (RSK-01.1) by ensuring the organization can restore operations and data when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides overlapping security capability that compensates for the absence of Risk Framing (RSK-01.1) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "RSK-01.2", + "risk_if_not_implemented": "Without Risk Management Resourcing, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", + "compensating_control_1": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides overlapping security capability that compensates for the absence of Risk Management Resourcing (RSK-01.2) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-01", + "name": "Risk Management Program", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls.", + "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Risk Management Resourcing (RSK-01.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "RSK-01.3", "risk_if_not_implemented": "Without Risk Tolerance, security risks may go unmanaged, resulting in uncontrolled exposures and misaligned security investments.", @@ -17169,6 +18033,22 @@ "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Risk Catalog (RSK-03.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "RSK-03.2", + "risk_if_not_implemented": "Without Risk Owner, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "GOV-04", + "name": "Assigned Security, Compliance & Resilience Responsibilities", + "description": "Mechanisms exist to assign one or more qualified individuals with the mission and resources to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP).", + "justification": "Assigned Security, Compliance & Resilience Responsibilities (GOV-04) provides resilience and recovery capability that compensates for the absence of Risk Owner (RSK-03.2) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-06", + "name": "Risk Remediation", + "description": "Mechanisms exist to remediate risks to an acceptable level.", + "justification": "Risk Remediation (RSK-06) provides vulnerability management that compensates for the absence of Risk Owner (RSK-03.2) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "RSK-04.2", "risk_if_not_implemented": "Without Risk Assessment Methodology, security events may go undetected, allowing threats to persist unnoticed and increasing breach dwell time.", @@ -17505,6 +18385,38 @@ "justification": "Secure Engineering Principles (SEA-01) provides overlapping security capability that compensates for the absence of Resilience Capabilities (SEA-01.3) by addressing related risk objectives through an alternative control mechanism aligned with Technology applicability. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "SEA-01.4", + "risk_if_not_implemented": "Without Secure Architecture Principles, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Secure Architecture Principles (SEA-01.4) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-05", + "name": "Developer Architecture & Design", + "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", + "justification": "Developer Architecture & Design (TDA-05) provides secure engineering and architectural guidance that compensates for the absence of Secure Architecture Principles (SEA-01.4) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "SEA-01.5", + "risk_if_not_implemented": "Without Security-Aware Design, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Security-Aware Design (SEA-01.5) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "PRM-04", + "name": "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.", + "justification": "Security, Compliance & Resilience In Project Management (PRM-04) provides resilience and recovery capability that compensates for the absence of Security-Aware Design (SEA-01.5) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "SEA-02", "risk_if_not_implemented": "Without Alignment With Enterprise Architecture, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -17809,6 +18721,22 @@ "justification": "Least Functionality (CFG-03) provides configuration hardening that compensates for the absence of Refresh from Trusted Sources (SEA-08.1) by eliminating unnecessary services and enforcing secure settings to reduce inherent exposure. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "SEA-08.2", + "risk_if_not_implemented": "Without Non-Persistent Information, sensitive information may be inadvertently exposed through error messages, insecure code, or persistent ephemeral data.", + "compensating_control_1": { + "control_id": "DCH-09", + "name": "System Media Sanitization", + "description": "Mechanisms exist to sanitize system media with the strength and integrity commensurate with the classification or sensitivity of the information prior to disposal, release out of organizational control or release for reuse.", + "justification": "System Media Sanitization (DCH-09) provides overlapping security capability that compensates for the absence of Non-Persistent Information (SEA-08.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-25", + "name": "Session Termination", + "description": "Automated mechanisms exist to log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity.", + "justification": "Session Termination (IAC-25) provides overlapping security capability that compensates for the absence of Non-Persistent Information (SEA-08.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "SEA-09", "risk_if_not_implemented": "Without Information Output Filtering, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -18513,6 +19441,22 @@ "justification": "Security, Compliance & Resilience Awareness Training (SAT-02) provides personnel training and awareness that compensates for the absence of Security, Compliance & Resilience Training Records (SAT-04) by reducing human-factor risk by equipping personnel to recognize and respond to relevant threats. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "SAT-04.1", + "risk_if_not_implemented": "Without Training Feedback, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "SAT-04", + "name": "Security, Compliance & Resilience Training Records", + "description": "Mechanisms exist to document, retain and monitor individual training activities, including:\n(1) Initial security, compliance and resilience awareness training;\n(2) Recurring awareness training; and\n(3) Technology Assets, Applications and/or Services (TAAS)-specific training.", + "justification": "Security, Compliance & Resilience Training Records (SAT-04) provides personnel training and awareness that compensates for the absence of Training Feedback (SAT-04.1) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-05", + "name": "Measures of Performance", + "description": "Mechanisms exist to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "justification": "Measures of Performance (GOV-05) provides overlapping security capability that compensates for the absence of Training Feedback (SAT-04.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "SAT-05", "risk_if_not_implemented": "Without Security, Compliance & Resilience Knowledge Sharing, the organization may be unable to recover from disruptions, resulting in data loss and extended downtime.", @@ -19009,6 +19953,22 @@ "justification": "Secure Engineering Principles (SEA-01) provides overlapping security capability that compensates for the absence of Software Design Root Cause Analysis (TDA-06.6) by addressing related risk objectives through an alternative control mechanism aligned with Process applicability. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "TDA-06.7", + "risk_if_not_implemented": "Without Programming Language Selection, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Programming Language Selection (TDA-06.7) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-04", + "name": "Software Usage Restrictions", + "description": "Mechanisms exist to enforce software usage restrictions to comply with applicable contract agreements and copyright laws.", + "justification": "Software Usage Restrictions (CFG-04) provides overlapping security capability that compensates for the absence of Programming Language Selection (TDA-06.7) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "TDA-07", "risk_if_not_implemented": "Without Secure Development Environments, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -19281,6 +20241,38 @@ "justification": "Third-Party Personnel Security (TPM-06) provides third-party oversight that compensates for the absence of Developer Screening (TDA-13) by extending security obligations contractually and monitoring third-party risk in lieu of direct control. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "TDA-13.1", + "risk_if_not_implemented": "Without Developer Knowledge & Skills Register, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "HRS-13", + "name": "Identify Critical Skills & Gaps", + "description": "Mechanisms exist to evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist.", + "justification": "Identify Critical Skills & Gaps (HRS-13) provides overlapping security capability that compensates for the absence of Developer Knowledge & Skills Register (TDA-13.1) by addressing related risk objectives through an alternative control mechanism. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Developer Knowledge & Skills Register (TDA-13.1) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "TDA-13.2", + "risk_if_not_implemented": "Without Developer Training, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Developer Training (TDA-13.2) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Developer Training (TDA-13.2) by addressing related risk objectives through an alternative control mechanism. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "TDA-14", "risk_if_not_implemented": "Without Developer Configuration Management, systems may operate with insecure settings or unauthorized changes, expanding the attack surface.", @@ -19409,6 +20401,22 @@ "justification": "Secure Baseline Configurations (CFG-02) provides configuration hardening that compensates for the absence of Error Handling (TDA-19) by eliminating unnecessary services and enforcing secure settings to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "TDA-19.1", + "risk_if_not_implemented": "Without Designated Roles To View Error Messages, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Designated Roles To View Error Messages (TDA-19.1) by restricting system and data access through alternative identity and access management mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SEA-09", + "name": "Information Output Filtering", + "description": "Mechanisms exist to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content.", + "justification": "Information Output Filtering (SEA-09) provides overlapping security capability that compensates for the absence of Designated Roles To View Error Messages (TDA-19.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "TDA-20", "risk_if_not_implemented": "Without Access to Program Source Code, unauthorized users may gain access to systems or data, increasing risk of data breaches and insider threats.", @@ -19969,6 +20977,38 @@ "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Threat Intelligence Program (THR-01) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "THR-01.1", + "risk_if_not_implemented": "Without Dynamic Threat Awareness, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Dynamic Threat Awareness (THR-01.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Dynamic Threat Awareness (THR-01.1) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, + { + "control_id": "THR-01.2", + "risk_if_not_implemented": "Without Predictive Cyber Analytics, the organization's threat model may become stale, leaving security controls misaligned with the actual threat landscape.", + "compensating_control_1": { + "control_id": "THR-07", + "name": "Threat Hunting", + "description": "Mechanisms exist to perform cyber threat hunting that uses Indicators of Compromise (IoC) to detect, track and disrupt threats that evade existing security controls.", + "justification": "Threat Hunting (THR-07) provides overlapping security capability that compensates for the absence of Predictive Cyber Analytics (THR-01.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-16", + "name": "Anomalous Behavior", + "description": "Mechanisms exist to utilize User & Entity Behavior Analytics (UEBA) and/or User Activity Monitoring (UAM) solutions to detect and respond to anomalous behavior that could indicate account compromise or other malicious activities.", + "justification": "Anomalous Behavior (MON-16) provides detective monitoring capability that compensates for the absence of Predictive Cyber Analytics (THR-01.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "THR-02", "risk_if_not_implemented": "Without Indicators of Exposure (IOE), residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", @@ -20193,6 +21233,22 @@ "justification": "Vulnerability Remediation Process (VPM-02) provides vulnerability management that compensates for the absence of Attack Surface Scope (VPM-01.1) by reducing the exploitable attack surface by addressing known weaknesses before they are leveraged. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." } }, + { + "control_id": "VPM-02.1", + "risk_if_not_implemented": "Without Known Exploited Vulnerabilities (KEV) Mitigations, unpatched vulnerabilities may remain exploitable, directly increasing the probability of successful attacks against the organization.", + "compensating_control_1": { + "control_id": "VPM-02", + "name": "Vulnerability Remediation Process", + "description": "Mechanisms exist to ensure that vulnerabilities are properly identified, tracked and remediated.", + "justification": "Vulnerability Remediation Process (VPM-02) provides vulnerability management that compensates for the absence of Known Exploited Vulnerabilities (KEV) Mitigations (VPM-02.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-03", + "name": "Boundary Protection", + "description": "Mechanisms exist to monitor and control communications at the external network boundary and at key internal boundaries within the network.", + "justification": "Boundary Protection (NET-03) provides network-level access restriction that compensates for the absence of Known Exploited Vulnerabilities (KEV) Mitigations (VPM-02.1) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } + }, { "control_id": "VPM-03", "risk_if_not_implemented": "Without Vulnerability Ranking, unpatched vulnerabilities accumulate, providing attackers with known and exploitable entry points.", diff --git a/docs/api/compensating-controls/AAT-01.5.json b/docs/api/compensating-controls/AAT-01.5.json new file mode 100644 index 00000000..4b05a738 --- /dev/null +++ b/docs/api/compensating-controls/AAT-01.5.json @@ -0,0 +1,16 @@ +{ + "control_id": "AAT-01.5", + "risk_if_not_implemented": "Without Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "AAT-01", + "name": "Artificial Intelligence (AI) & Autonomous Technologies Governance", + "description": "Mechanisms exist to ensure policies, processes, procedures and practices related to the mapping, measuring and managing of Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related risks are in place, transparent and implemented effectively.", + "justification": "Artificial Intelligence (AI) & Autonomous Technologies Governance (AAT-01) provides detective monitoring capability that compensates for the absence of Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization (AAT-01.5) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-04", + "name": "Risk Assessment", + "description": "Mechanisms exist to conduct recurring assessments of risk that includes the likelihood and magnitude of harm, from unauthorized access, use, disclosure, disruption, modification or destruction of the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Risk Assessment (RSK-04) provides periodic assessment and verification that compensates for the absence of Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization (AAT-01.5) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/AAT-12.5.json b/docs/api/compensating-controls/AAT-12.5.json new file mode 100644 index 00000000..760dcebc --- /dev/null +++ b/docs/api/compensating-controls/AAT-12.5.json @@ -0,0 +1,16 @@ +{ + "control_id": "AAT-12.5", + "risk_if_not_implemented": "Without Training Data Source & Integrity, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "DCH-22", + "name": "Data Quality Operations", + "description": "Mechanisms exist to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", + "justification": "Data Quality Operations (DCH-22) provides overlapping security capability that compensates for the absence of Training Data Source & Integrity (AAT-12.5) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "AAT-10", + "name": "Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV)", + "description": "Mechanisms exist to implement Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices to enable Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related security, resilience and compliance-related conformity testing throughout the lifecycle of the AAT.", + "justification": "Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) (AAT-10) provides periodic assessment and verification that compensates for the absence of Training Data Source & Integrity (AAT-12.5) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/AAT-12.6.json b/docs/api/compensating-controls/AAT-12.6.json new file mode 100644 index 00000000..384260c4 --- /dev/null +++ b/docs/api/compensating-controls/AAT-12.6.json @@ -0,0 +1,16 @@ +{ + "control_id": "AAT-12.6", + "risk_if_not_implemented": "Without Prohibit Training, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides third-party oversight and contractual controls that compensates for the absence of Prohibit Training (AAT-12.6) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-14", + "name": "Information Sharing", + "description": "Mechanisms exist to utilize a process to assist users in making information sharing decisions to ensure data is appropriately protected.", + "justification": "Information Sharing (DCH-14) provides threat intelligence and situational awareness that compensates for the absence of Prohibit Training (AAT-12.6) by providing early warning of threats and informing proactive security posture adjustments. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/AAT-29.24.json b/docs/api/compensating-controls/AAT-29.24.json new file mode 100644 index 00000000..930c3305 --- /dev/null +++ b/docs/api/compensating-controls/AAT-29.24.json @@ -0,0 +1,16 @@ +{ + "control_id": "AAT-29.24", + "risk_if_not_implemented": "Without Resource Limiting, AI and autonomous technology risks may go ungoverned, leading to unintended outcomes, misuse, or data exposure.", + "compensating_control_1": { + "control_id": "CAP-01", + "name": "Capacity & Performance Management", + "description": "Mechanisms exist to facilitate the implementation of capacity management controls to ensure optimal system performance to meet expected and anticipated future capacity requirements.", + "justification": "Capacity & Performance Management (CAP-01) provides overlapping security capability that compensates for the absence of Resource Limiting (AAT-29.24) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Resource Limiting (AAT-29.24) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/AAT-33.json b/docs/api/compensating-controls/AAT-33.json new file mode 100644 index 00000000..c6b77249 --- /dev/null +++ b/docs/api/compensating-controls/AAT-33.json @@ -0,0 +1,16 @@ +{ + "control_id": "AAT-33", + "risk_if_not_implemented": "Without Release Owner Gate (ROG) For AI-Augmented Content, AI and autonomous technology risks may go ungoverned, leading to unintended outcomes, misuse, or data exposure.", + "compensating_control_1": { + "control_id": "CHG-08", + "name": "Dual Approval For High-Impact Environments", + "description": "Mechanisms exist to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Dual Approval For High-Impact Environments (CHG-08) provides overlapping security capability that compensates for the absence of Release Owner Gate (ROG) For AI-Augmented Content (AAT-33) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-04", + "name": "Assigned Security, Compliance & Resilience Responsibilities", + "description": "Mechanisms exist to assign one or more qualified individuals with the mission and resources to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP).", + "justification": "Assigned Security, Compliance & Resilience Responsibilities (GOV-04) provides resilience and recovery capability that compensates for the absence of Release Owner Gate (ROG) For AI-Augmented Content (AAT-33) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/AST-05.2.json b/docs/api/compensating-controls/AST-05.2.json new file mode 100644 index 00000000..551269fd --- /dev/null +++ b/docs/api/compensating-controls/AST-05.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "AST-05.2", + "risk_if_not_implemented": "Without Technology Assets, Applications, Services and/or Data (TAASD) Storage, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "PES-03", + "name": "Physical Access Control", + "description": "Physical access control mechanisms exist to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", + "justification": "Physical Access Control (PES-03) provides access control enforcement that compensates for the absence of Technology Assets, Applications, Services and/or Data (TAASD) Storage (AST-05.2) by restricting system and data access through alternative identity and access management mechanisms. Given the facility and physical environment focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "PES-06", + "name": "Visitor Control", + "description": "Physical access control mechanisms exist to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible).", + "justification": "Visitor Control (PES-06) provides physical access control that compensates for the absence of Technology Assets, Applications, Services and/or Data (TAASD) Storage (AST-05.2) by preventing unauthorized physical interaction with systems and infrastructure. Given the facility and physical environment focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/CFG-09.1.json b/docs/api/compensating-controls/CFG-09.1.json new file mode 100644 index 00000000..0cf8f429 --- /dev/null +++ b/docs/api/compensating-controls/CFG-09.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "CFG-09.1", + "risk_if_not_implemented": "Without Third-Party Libraries, third-party risks may go unmanaged, creating supply-chain exposure that compromises organizational systems or data.", + "compensating_control_1": { + "control_id": "TPM-03", + "name": "Supply Chain Risk Management (SCRM)", + "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", + "justification": "Supply Chain Risk Management (SCRM) (TPM-03) provides risk identification and prioritization that compensates for the absence of Third-Party Libraries (CFG-09.1) by enabling informed decisions about where to focus resources to manage residual exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Third-Party Libraries (CFG-09.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/CFG-09.2.json b/docs/api/compensating-controls/CFG-09.2.json new file mode 100644 index 00000000..0fa3ebe8 --- /dev/null +++ b/docs/api/compensating-controls/CFG-09.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "CFG-09.2", + "risk_if_not_implemented": "Without Software Repository Protections, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Software Repository Protections (CFG-09.2) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "END-04", + "name": "Malicious Code Protection (Anti-Malware)", + "description": "Mechanisms exist to utilize antimalware technologies to detect and eradicate malicious code.", + "justification": "Malicious Code Protection (Anti-Malware) (END-04) provides overlapping security capability that compensates for the absence of Software Repository Protections (CFG-09.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/CFG-09.3.json b/docs/api/compensating-controls/CFG-09.3.json new file mode 100644 index 00000000..10692b9a --- /dev/null +++ b/docs/api/compensating-controls/CFG-09.3.json @@ -0,0 +1,16 @@ +{ + "control_id": "CFG-09.3", + "risk_if_not_implemented": "Without Software Development Repository, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "TDA-08", + "name": "Separation of Development, Testing and Operational Environments", + "description": "Mechanisms exist to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).", + "justification": "Separation of Development, Testing and Operational Environments (TDA-08) provides periodic assessment and verification that compensates for the absence of Software Development Repository (CFG-09.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CHG-04", + "name": "Access Restriction For Change", + "description": "Mechanisms exist to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.", + "justification": "Access Restriction For Change (CHG-04) provides access control enforcement that compensates for the absence of Software Development Repository (CFG-09.3) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/CFG-09.json b/docs/api/compensating-controls/CFG-09.json new file mode 100644 index 00000000..4afacb2e --- /dev/null +++ b/docs/api/compensating-controls/CFG-09.json @@ -0,0 +1,16 @@ +{ + "control_id": "CFG-09", + "risk_if_not_implemented": "Without Production Software Repository, systems or software repositories may operate with insecure settings or untrusted artifacts, expanding the attack surface.", + "compensating_control_1": { + "control_id": "CHG-02", + "name": "Configuration Change Control", + "description": "Mechanisms exist to govern the technical configuration change control processes.", + "justification": "Configuration Change Control (CHG-02) provides configuration and supply-chain hardening that compensates for the absence of Production Software Repository (CFG-09) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-05", + "name": "Software & Firmware Patching", + "description": "Mechanisms exist to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", + "justification": "Software & Firmware Patching (VPM-05) provides vulnerability management that compensates for the absence of Production Software Repository (CFG-09) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/CPL-03.8.json b/docs/api/compensating-controls/CPL-03.8.json new file mode 100644 index 00000000..cdc6866a --- /dev/null +++ b/docs/api/compensating-controls/CPL-03.8.json @@ -0,0 +1,16 @@ +{ + "control_id": "CPL-03.8", + "risk_if_not_implemented": "Without Continuous Control Monitoring (CCM), security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "CPL-03", + "name": "Control Conformity Monitoring", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "justification": "Control Conformity Monitoring (CPL-03) provides detective monitoring capability that compensates for the absence of Continuous Control Monitoring (CCM) (CPL-03.8) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Continuous Control Monitoring (CCM) (CPL-03.8) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/GOV-01.4.json b/docs/api/compensating-controls/GOV-01.4.json new file mode 100644 index 00000000..d610f018 --- /dev/null +++ b/docs/api/compensating-controls/GOV-01.4.json @@ -0,0 +1,16 @@ +{ + "control_id": "GOV-01.4", + "risk_if_not_implemented": "Without Secure Practices Alignment Justification, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CPL-01", + "name": "Statutory, Regulatory & Contractual Compliance", + "description": "Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", + "justification": "Statutory, Regulatory & Contractual Compliance (CPL-01) provides third-party oversight and contractual controls that compensates for the absence of Secure Practices Alignment Justification (GOV-01.4) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-09", + "name": "Define Control Objectives", + "description": "Mechanisms exist to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", + "justification": "Define Control Objectives (GOV-09) provides overlapping security capability that compensates for the absence of Secure Practices Alignment Justification (GOV-01.4) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/GOV-10.1.json b/docs/api/compensating-controls/GOV-10.1.json new file mode 100644 index 00000000..11ded55d --- /dev/null +++ b/docs/api/compensating-controls/GOV-10.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "GOV-10.1", + "risk_if_not_implemented": "Without Data Catalog, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "DCH-24", + "name": "Information Location", + "description": "Mechanisms exist to identify and document the location of information and the specific system components on which the information resides.", + "justification": "Information Location (DCH-24) provides overlapping security capability that compensates for the absence of Data Catalog (GOV-10.1) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Data Catalog (GOV-10.1) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/GOV-19.3.json b/docs/api/compensating-controls/GOV-19.3.json new file mode 100644 index 00000000..64b20d4d --- /dev/null +++ b/docs/api/compensating-controls/GOV-19.3.json @@ -0,0 +1,16 @@ +{ + "control_id": "GOV-19.3", + "risk_if_not_implemented": "Without Security, Compliance & Resilince Outsourcing Limitations, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "TPM-04", + "name": "Third-Party Services", + "description": "Mechanisms exist to mitigate the risks associated with third-party access to the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Services (TPM-04) provides third-party oversight and contractual controls that compensates for the absence of Security, Compliance & Resilince Outsourcing Limitations (GOV-19.3) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CPL-10", + "name": "Control Inheritance", + "description": "Mechanisms exist to define instances of control inheritance within assessment boundaries.", + "justification": "Control Inheritance (CPL-10) provides overlapping security capability that compensates for the absence of Security, Compliance & Resilince Outsourcing Limitations (GOV-19.3) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/GOV-21.json b/docs/api/compensating-controls/GOV-21.json new file mode 100644 index 00000000..ac7fc98d --- /dev/null +++ b/docs/api/compensating-controls/GOV-21.json @@ -0,0 +1,16 @@ +{ + "control_id": "GOV-21", + "risk_if_not_implemented": "Without HVA / crown jewels protections, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Crown Jewels (GOV-21) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-05", + "name": "Risk Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "justification": "Risk Ranking (RSK-05) provides risk identification and prioritization that compensates for the absence of Crown Jewels (GOV-21) by enabling informed decisions about where to focus resources to manage residual exposure. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/IAC-01.4.json b/docs/api/compensating-controls/IAC-01.4.json new file mode 100644 index 00000000..1bb6180a --- /dev/null +++ b/docs/api/compensating-controls/IAC-01.4.json @@ -0,0 +1,16 @@ +{ + "control_id": "IAC-01.4", + "risk_if_not_implemented": "Without Identity Providers (IdP) & Authorization Servers, unauthorized users may gain access to systems or data, increasing risk of data breaches and privilege escalation.", + "compensating_control_1": { + "control_id": "IAC-02", + "name": "Identification & Authentication for Organizational Users", + "description": "Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", + "justification": "Identification & Authentication for Organizational Users (IAC-02) provides access control enforcement that compensates for the absence of Identity Providers (IdP) & Authorization Servers (IAC-01.4) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-08", + "name": "Role-Based Access Control (RBAC)", + "description": "Mechanisms exist to enforce Role-Based Access Control (RBAC) for Technology Assets, Applications, Services and/or Data (TAASD) to restrict access to individuals assigned specific roles with legitimate business needs.", + "justification": "Role-Based Access Control (RBAC) (IAC-08) provides access control enforcement that compensates for the absence of Identity Providers (IdP) & Authorization Servers (IAC-01.4) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/IAC-15.10.json b/docs/api/compensating-controls/IAC-15.10.json new file mode 100644 index 00000000..7dfe4a5e --- /dev/null +++ b/docs/api/compensating-controls/IAC-15.10.json @@ -0,0 +1,16 @@ +{ + "control_id": "IAC-15.10", + "risk_if_not_implemented": "Without Account Separation Between Infrastructure Environments, unauthorized users may gain access to systems or data, increasing risk of data breaches and privilege escalation.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Account Separation Between Infrastructure Environments (IAC-15.10) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-16", + "name": "Privileged Account Management (PAM)", + "description": "Mechanisms exist to restrict and control privileged access rights for users and Technology Assets, Applications and/or Services (TAAS).", + "justification": "Privileged Account Management (PAM) (IAC-16) provides access control enforcement that compensates for the absence of Account Separation Between Infrastructure Environments (IAC-15.10) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/NET-06.8.json b/docs/api/compensating-controls/NET-06.8.json new file mode 100644 index 00000000..ef8f446d --- /dev/null +++ b/docs/api/compensating-controls/NET-06.8.json @@ -0,0 +1,16 @@ +{ + "control_id": "NET-06.8", + "risk_if_not_implemented": "Without Network Device Plane Segmentation, network defenses may be weakened, enabling lateral movement and exploitation of unprotected communication pathways.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Network Device Plane Segmentation (NET-06.8) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Network Device Plane Segmentation (NET-06.8) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/NET-06.9.json b/docs/api/compensating-controls/NET-06.9.json new file mode 100644 index 00000000..ebff10f0 --- /dev/null +++ b/docs/api/compensating-controls/NET-06.9.json @@ -0,0 +1,16 @@ +{ + "control_id": "NET-06.9", + "risk_if_not_implemented": "Without Separate Subnets To Isolate Functions, network defenses may be weakened, enabling lateral movement and exploitation of unprotected communication pathways.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Separate Subnets To Isolate Functions (NET-06.9) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-04", + "name": "Data Flow Enforcement – Access Control Lists (ACLs)", + "description": "Mechanisms exist to implement and govern Access Control Lists (ACLs) to provide data flow enforcement that explicitly restrict network traffic to only what is authorized.", + "justification": "Data Flow Enforcement – Access Control Lists (ACLs) (NET-04) provides access control enforcement that compensates for the absence of Separate Subnets To Isolate Functions (NET-06.9) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/PRI-01.12.json b/docs/api/compensating-controls/PRI-01.12.json new file mode 100644 index 00000000..abb2e3be --- /dev/null +++ b/docs/api/compensating-controls/PRI-01.12.json @@ -0,0 +1,16 @@ +{ + "control_id": "PRI-01.12", + "risk_if_not_implemented": "Without Privacy-Aware Design, personal data may be processed without adequate privacy safeguards, increasing regulatory and reputational risk.", + "compensating_control_1": { + "control_id": "PRI-01", + "name": "Data Privacy Program", + "description": "Mechanisms exist to facilitate the implementation and operation of data protection controls throughout the data lifecycle to ensure all forms of Personal Data (PD) are processed lawfully, fairly and transparently.", + "justification": "Data Privacy Program (PRI-01) provides policy-level governance that compensates for the absence of Privacy-Aware Design (PRI-01.12) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Privacy-Aware Design (PRI-01.12) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-01.1.json b/docs/api/compensating-controls/QTS-01.1.json new file mode 100644 index 00000000..c7d16901 --- /dev/null +++ b/docs/api/compensating-controls/QTS-01.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-01.1", + "risk_if_not_implemented": "Without Quantum Security Policy, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "GOV-01", + "name": "Security, Compliance & Resilience Program (SCRP)", + "description": "Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.", + "justification": "Publishing Security, Compliance & Resilience Documentation (GOV-02) provides resilience and recovery capability that compensates for the absence of Quantum Security Policy (QTS-01.1) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Quantum Security Policy (QTS-01.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-01.2.json b/docs/api/compensating-controls/QTS-01.2.json new file mode 100644 index 00000000..c5d4edb6 --- /dev/null +++ b/docs/api/compensating-controls/QTS-01.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-01.2", + "risk_if_not_implemented": "Without Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization (QTS-01.2) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-05", + "name": "Risk Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "justification": "Risk Ranking (RSK-05) provides risk identification and prioritization that compensates for the absence of Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization (QTS-01.2) by enabling informed decisions about where to focus resources to manage residual exposure. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-01.3.json b/docs/api/compensating-controls/QTS-01.3.json new file mode 100644 index 00000000..ac059420 --- /dev/null +++ b/docs/api/compensating-controls/QTS-01.3.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-01.3", + "risk_if_not_implemented": "Without Long-Lived Data Identification, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "DCH-02", + "name": "Data & Asset Classification", + "description": "Mechanisms exist to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "justification": "Data & Asset Classification (DCH-02) provides asset and inventory visibility that compensates for the absence of Long-Lived Data Identification (QTS-01.3) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "DCH-18", + "name": "Media & Data Retention", + "description": "Mechanisms exist to retain media and data in accordance with applicable statutory, regulatory and contractual obligations.", + "justification": "Media & Data Retention (DCH-18) provides overlapping security capability that compensates for the absence of Long-Lived Data Identification (QTS-01.3) by addressing related risk objectives through an alternative control mechanism. Given the data-handling focus of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-01.4.json b/docs/api/compensating-controls/QTS-01.4.json new file mode 100644 index 00000000..4fd2e34d --- /dev/null +++ b/docs/api/compensating-controls/QTS-01.4.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-01.4", + "risk_if_not_implemented": "Without Harvest Now, Decrypt Later (HNDL) Mitigation, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CRY-03", + "name": "Transmission Confidentiality", + "description": "Cryptographic mechanisms exist to protect the confidentiality of data being transmitted.", + "justification": "Transmission Confidentiality (CRY-03) provides overlapping security capability that compensates for the absence of Harvest Now, Decrypt Later (HNDL) Mitigation (QTS-01.4) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-03", + "name": "Boundary Protection", + "description": "Mechanisms exist to monitor and control communications at the external network boundary and at key internal boundaries within the network.", + "justification": "Boundary Protection (NET-03) provides network-level access restriction that compensates for the absence of Harvest Now, Decrypt Later (HNDL) Mitigation (QTS-01.4) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-01.json b/docs/api/compensating-controls/QTS-01.json new file mode 100644 index 00000000..9dc6939b --- /dev/null +++ b/docs/api/compensating-controls/QTS-01.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-01", + "risk_if_not_implemented": "Without Quantum Risk Governance, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "RSK-01", + "name": "Risk Management Program", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Quantum Risk Governance (QTS-01) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-01", + "name": "Security, Compliance & Resilience Program (SCRP)", + "description": "Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.", + "justification": "Security, Compliance & Resilience Program (SCRP) (GOV-01) provides resilience and recovery capability that compensates for the absence of Quantum Risk Governance (QTS-01) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-02.1.json b/docs/api/compensating-controls/QTS-02.1.json new file mode 100644 index 00000000..06afd61c --- /dev/null +++ b/docs/api/compensating-controls/QTS-02.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-02.1", + "risk_if_not_implemented": "Without Cryptographic Exception Register, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CPL-12", + "name": "Statement of Applicability (SOA)", + "description": "Mechanisms exist to produce a Statement of Applicability (SOA), or similar document, for compliance-related scoping activities.", + "justification": "Statement of Applicability (SOA) (CPL-12) provides overlapping security capability that compensates for the absence of Cryptographic Exception Register (QTS-02.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-06", + "name": "Risk Remediation", + "description": "Mechanisms exist to remediate risks to an acceptable level.", + "justification": "Risk Remediation (RSK-06) provides vulnerability management that compensates for the absence of Cryptographic Exception Register (QTS-02.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-02.2.json b/docs/api/compensating-controls/QTS-02.2.json new file mode 100644 index 00000000..e2fad608 --- /dev/null +++ b/docs/api/compensating-controls/QTS-02.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-02.2", + "risk_if_not_implemented": "Without Compensating Controls for Quantum-Vulnerable Systems, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "NET-06", + "name": "Network Segmentation (macrosegmentation)", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "justification": "Network Segmentation (macrosegmentation) (NET-06) provides network-level access restriction that compensates for the absence of Compensating Controls for Quantum-Vulnerable Systems (QTS-02.2) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Compensating Controls for Quantum-Vulnerable Systems (QTS-02.2) by restricting system and data access through alternative identity and access management mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-02.3.json b/docs/api/compensating-controls/QTS-02.3.json new file mode 100644 index 00000000..9ff6f06e --- /dev/null +++ b/docs/api/compensating-controls/QTS-02.3.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-02.3", + "risk_if_not_implemented": "Without Crypto Agility Maturity Assessment, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CPL-03", + "name": "Control Conformity Monitoring", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "justification": "Control Conformity Monitoring (CPL-03) provides detective monitoring capability that compensates for the absence of Crypto Agility Maturity Assessment (QTS-02.3) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-02", + "name": "Assessments", + "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.", + "justification": "Assessments (IAO-02) provides periodic assessment and verification that compensates for the absence of Crypto Agility Maturity Assessment (QTS-02.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-02.json b/docs/api/compensating-controls/QTS-02.json new file mode 100644 index 00000000..1524a20a --- /dev/null +++ b/docs/api/compensating-controls/QTS-02.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-02", + "risk_if_not_implemented": "Without Cryptographic Agility Risk Assessment (CARA), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "RSK-04", + "name": "Risk Assessment", + "description": "Mechanisms exist to conduct recurring assessments of risk that includes the likelihood and magnitude of harm, from unauthorized access, use, disclosure, disruption, modification or destruction of the organization's Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Risk Assessment (RSK-04) provides periodic assessment and verification that compensates for the absence of Cryptographic Agility Risk Assessment (CARA) (QTS-02) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Cryptographic Agility Risk Assessment (CARA) (QTS-02) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-03.1.json b/docs/api/compensating-controls/QTS-03.1.json new file mode 100644 index 00000000..d8ccce6a --- /dev/null +++ b/docs/api/compensating-controls/QTS-03.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-03.1", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support (QTS-03.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CHG-01", + "name": "Change Management Program", + "description": "Mechanisms exist to facilitate the implementation of a change management program.", + "justification": "Change Management Program (CHG-01) provides policy-level governance that compensates for the absence of Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support (QTS-03.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-03.2.json b/docs/api/compensating-controls/QTS-03.2.json new file mode 100644 index 00000000..fa54da63 --- /dev/null +++ b/docs/api/compensating-controls/QTS-03.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-03.2", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Migration Progress Oversight, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "GOV-05", + "name": "Measures of Performance", + "description": "Mechanisms exist to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "justification": "Measures of Performance (GOV-05) provides overlapping security capability that compensates for the absence of Post-Quantum Cryptography (PQC) Migration Progress Oversight (QTS-03.2) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-11", + "name": "Risk Monitoring", + "description": "Mechanisms exist to ensure risk monitoring as an integral part of the continuous monitoring strategy that includes monitoring the effectiveness of security, compliance and resilience controls, compliance and change management.", + "justification": "Risk Monitoring (RSK-11) provides detective monitoring capability that compensates for the absence of Post-Quantum Cryptography (PQC) Migration Progress Oversight (QTS-03.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-03.3.json b/docs/api/compensating-controls/QTS-03.3.json new file mode 100644 index 00000000..247a5464 --- /dev/null +++ b/docs/api/compensating-controls/QTS-03.3.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-03.3", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Supply Chain Visibility, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TPM-08", + "name": "Review of Third-Party Services", + "description": "Mechanisms exist to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls.", + "justification": "Review of Third-Party Services (TPM-08) provides periodic assessment and verification that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Visibility (QTS-03.3) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TPM-05", + "name": "Third-Party Contract Requirements", + "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Contract Requirements (TPM-05) provides third-party oversight and contractual controls that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Visibility (QTS-03.3) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-03.4.json b/docs/api/compensating-controls/QTS-03.4.json new file mode 100644 index 00000000..9360ca44 --- /dev/null +++ b/docs/api/compensating-controls/QTS-03.4.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-03.4", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TPM-03", + "name": "Supply Chain Risk Management (SCRM)", + "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", + "justification": "Supply Chain Risk Management (SCRM) (TPM-03) provides risk identification and prioritization that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements (QTS-03.4) by enabling informed decisions about where to focus resources to manage residual exposure. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TPM-05", + "name": "Third-Party Contract Requirements", + "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", + "justification": "Third-Party Contract Requirements (TPM-05) provides third-party oversight and contractual controls that compensates for the absence of Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements (QTS-03.4) by extending security obligations and monitoring third-party risk in lieu of direct primary control implementation. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-03.json b/docs/api/compensating-controls/QTS-03.json new file mode 100644 index 00000000..f0beae03 --- /dev/null +++ b/docs/api/compensating-controls/QTS-03.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-03", + "risk_if_not_implemented": "Without Post-Quantum Cryptography Agility Plan (PSCAP), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "RSK-01", + "name": "Risk Management Program", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "justification": "Risk Management Program (RSK-01) provides policy-level governance that compensates for the absence of Post-Quantum Cryptography Agility Plan (PSCAP) (QTS-03) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography Agility Plan (PSCAP) (QTS-03) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-04.1.json b/docs/api/compensating-controls/QTS-04.1.json new file mode 100644 index 00000000..08a99f1e --- /dev/null +++ b/docs/api/compensating-controls/QTS-04.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-04.1", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Asset Inventory, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Post-Quantum Cryptography (PQC) Asset Inventory (QTS-04.1) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Asset Inventory (QTS-04.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-04.2.json b/docs/api/compensating-controls/QTS-04.2.json new file mode 100644 index 00000000..63d77c1c --- /dev/null +++ b/docs/api/compensating-controls/QTS-04.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-04.2", + "risk_if_not_implemented": "Without Cryptographic Bill of Materials (CBOM), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Cryptographic Bill of Materials (CBOM) (QTS-04.2) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-01", + "name": "Configuration Management Program", + "description": "Mechanisms exist to facilitate the implementation of configuration management controls.", + "justification": "Configuration Management Program (CFG-01) provides policy-level governance that compensates for the absence of Cryptographic Bill of Materials (CBOM) (QTS-04.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-04.3.json b/docs/api/compensating-controls/QTS-04.3.json new file mode 100644 index 00000000..036d39c8 --- /dev/null +++ b/docs/api/compensating-controls/QTS-04.3.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-04.3", + "risk_if_not_implemented": "Without Post-Quantum Cryptography Exposure, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "VPM-03", + "name": "Vulnerability Ranking", + "description": "Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information.", + "justification": "Vulnerability Ranking (VPM-03) provides vulnerability management that compensates for the absence of Post-Quantum Cryptography Exposure (QTS-04.3) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-02", + "name": "Risk-Based Security Categorization", + "description": "Mechanisms exist to categorize Technology Assets, Applications, Services and/or Data (TAASD) in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", + "justification": "Risk-Based Security Categorization (RSK-02) provides risk identification and prioritization that compensates for the absence of Post-Quantum Cryptography Exposure (QTS-04.3) by enabling informed decisions about where to focus resources to manage residual exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-04.json b/docs/api/compensating-controls/QTS-04.json new file mode 100644 index 00000000..4691cd65 --- /dev/null +++ b/docs/api/compensating-controls/QTS-04.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-04", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Discovery & Visibility, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "AST-02", + "name": "Asset Inventories", + "description": "Mechanisms exist to perform inventories of Technology Assets, Applications, Services and/or Data (TAASD) that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", + "justification": "Asset Inventories (AST-02) provides asset and inventory visibility that compensates for the absence of Post-Quantum Cryptography (PQC) Discovery & Visibility (QTS-04) by providing the foundational asset knowledge needed to manage risks associated with the primary control. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Post-Quantum Cryptography (PQC) Discovery & Visibility (QTS-04) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-05.1.json b/docs/api/compensating-controls/QTS-05.1.json new file mode 100644 index 00000000..2e6fb4f0 --- /dev/null +++ b/docs/api/compensating-controls/QTS-05.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-05.1", + "risk_if_not_implemented": "Without Quantum Threat Intelligence Monitoring, security events may go undetected, allowing threats to persist and increasing breach dwell time.", + "compensating_control_1": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Quantum Threat Intelligence Monitoring (QTS-05.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "THR-03", + "name": "Threat Intelligence Feeds", + "description": "Mechanisms exist to maintain situational awareness of vulnerabilities and evolving threats by leveraging the knowledge of attacker tactics, techniques and procedures to facilitate the implementation of preventative and compensating controls.", + "justification": "Threat Intelligence Feeds (THR-03) provides threat intelligence and situational awareness that compensates for the absence of Quantum Threat Intelligence Monitoring (QTS-05.1) by providing early warning of threats and informing proactive security posture adjustments. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-05.2.json b/docs/api/compensating-controls/QTS-05.2.json new file mode 100644 index 00000000..8a2f2277 --- /dev/null +++ b/docs/api/compensating-controls/QTS-05.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-05.2", + "risk_if_not_implemented": "Without Collaboration & Information Sharing, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "GOV-07", + "name": "Contacts With Groups & Associations", + "description": "Mechanisms exist to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.", + "justification": "Contacts With Groups & Associations (GOV-07) provides overlapping security capability that compensates for the absence of Collaboration & Information Sharing (QTS-05.2) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Collaboration & Information Sharing (QTS-05.2) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-05.json b/docs/api/compensating-controls/QTS-05.json new file mode 100644 index 00000000..9f590aa3 --- /dev/null +++ b/docs/api/compensating-controls/QTS-05.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-05", + "risk_if_not_implemented": "Without Quantum Security Awareness, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "SAT-02", + "name": "Security, Compliance & Resilience Awareness Training", + "description": "Mechanisms exist to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function.", + "justification": "Security, Compliance & Resilience Awareness Training (SAT-02) provides personnel training and awareness that compensates for the absence of Quantum Security Awareness (QTS-05) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Quantum Security Awareness (QTS-05) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.1.json b/docs/api/compensating-controls/QTS-06.1.json new file mode 100644 index 00000000..22adfac2 --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.1", + "risk_if_not_implemented": "Without Entropy Source & Random Bit Generation, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Entropy Source & Random Bit Generation (QTS-06.1) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Entropy Source & Random Bit Generation (QTS-06.1) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.10.json b/docs/api/compensating-controls/QTS-06.10.json new file mode 100644 index 00000000..12a3b96b --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.10.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.10", + "risk_if_not_implemented": "Without Cryptographic Application Programming Interface (API) Abstraction, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Cryptographic Application Programming Interface (API) Abstraction (QTS-06.10) by embedding security requirements into design processes as an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Cryptographic Application Programming Interface (API) Abstraction (QTS-06.10) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.2.json b/docs/api/compensating-controls/QTS-06.2.json new file mode 100644 index 00000000..abe8c90f --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.2", + "risk_if_not_implemented": "Without Stateful Hash-Based Signatures for Firmware & Code Signing, residual security, compliance, or resilience risk may accumulate, potentially leading to control failures or non-compliance.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Stateful Hash-Based Signatures for Firmware & Code Signing (QTS-06.2) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-06", + "name": "Configuration Enforcement", + "description": "Automated mechanisms exist to monitor, enforce and report on configurations for endpoint devices.", + "justification": "Configuration Enforcement (CFG-06) provides configuration and supply-chain hardening that compensates for the absence of Stateful Hash-Based Signatures for Firmware & Code Signing (QTS-06.2) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.3.json b/docs/api/compensating-controls/QTS-06.3.json new file mode 100644 index 00000000..f81d37c8 --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.3.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.3", + "risk_if_not_implemented": "Without Approved Post-Quantum Cryptography (PQC) Algorithm Use, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Approved Post-Quantum Cryptography (PQC) Algorithm Use (QTS-06.3) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-02", + "name": "Secure Baseline Configurations", + "description": "Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "justification": "Secure Baseline Configurations (CFG-02) provides configuration and supply-chain hardening that compensates for the absence of Approved Post-Quantum Cryptography (PQC) Algorithm Use (QTS-06.3) by enforcing secure settings and trusted software sources to reduce inherent exposure. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.4.json b/docs/api/compensating-controls/QTS-06.4.json new file mode 100644 index 00000000..614431fa --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.4.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.4", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Validation Requirements, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Validation Requirements (QTS-06.4) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-06", + "name": "Technical Verification", + "description": "Mechanisms exist to perform Information Assurance Program (IAP) activities to evaluate the design, implementation and effectiveness of technical security, compliance and resilience controls.", + "justification": "Technical Verification (IAO-06) provides periodic assessment and verification that compensates for the absence of Post-Quantum Cryptography (PQC) Validation Requirements (QTS-06.4) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.5.json b/docs/api/compensating-controls/QTS-06.5.json new file mode 100644 index 00000000..d90f98ac --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.5.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.5", + "risk_if_not_implemented": "Without Deprecated Cryptographic Algorithms, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Deprecated Cryptographic Algorithms (QTS-06.5) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "VPM-06", + "name": "Vulnerability Scanning", + "description": "Mechanisms exist to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", + "justification": "Vulnerability Scanning (VPM-06) provides vulnerability management that compensates for the absence of Deprecated Cryptographic Algorithms (QTS-06.5) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.6.json b/docs/api/compensating-controls/QTS-06.6.json new file mode 100644 index 00000000..0d6b5770 --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.6.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.6", + "risk_if_not_implemented": "Without Post-Quantum Cryptography (PQC) Key Management, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Post-Quantum Cryptography (PQC) Key Management (QTS-06.6) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-12", + "name": "Certificate Monitoring", + "description": "Automated mechanisms exist to discover when new certificates are issued for organization-controlled domains.", + "justification": "Certificate Monitoring (CRY-12) provides detective monitoring capability that compensates for the absence of Post-Quantum Cryptography (PQC) Key Management (QTS-06.6) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.7.json b/docs/api/compensating-controls/QTS-06.7.json new file mode 100644 index 00000000..f848b94b --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.7.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.7", + "risk_if_not_implemented": "Without Quantum-Safe Public Key Infrastructure (PKI) Transition, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-08", + "name": "Public Key Infrastructure (PKI)", + "description": "Mechanisms exist to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "justification": "Public Key Infrastructure (PKI) (CRY-08) provides cryptographic protection and key governance that compensates for the absence of Quantum-Safe Public Key Infrastructure (PKI) Transition (QTS-06.7) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Quantum-Safe Public Key Infrastructure (PKI) Transition (QTS-06.7) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.8.json b/docs/api/compensating-controls/QTS-06.8.json new file mode 100644 index 00000000..f9f8cc33 --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.8.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.8", + "risk_if_not_implemented": "Without Algorithm Negotiation Integrity, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "NET-09", + "name": "Session Integrity", + "description": "Mechanisms exist to protect the authenticity and integrity of communications sessions.", + "justification": "Session Integrity (NET-09) provides overlapping security capability that compensates for the absence of Algorithm Negotiation Integrity (QTS-06.8) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-03", + "name": "Transmission Confidentiality", + "description": "Cryptographic mechanisms exist to protect the confidentiality of data being transmitted.", + "justification": "Transmission Confidentiality (CRY-03) provides overlapping security capability that compensates for the absence of Algorithm Negotiation Integrity (QTS-06.8) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.9.json b/docs/api/compensating-controls/QTS-06.9.json new file mode 100644 index 00000000..ef377abc --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.9.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06.9", + "risk_if_not_implemented": "Without Hybrid / Composite Cryptography, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "CRY-01", + "name": "Use of Cryptographic Controls", + "description": "Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies.", + "justification": "Use of Cryptographic Controls (CRY-01) provides cryptographic protection and key governance that compensates for the absence of Hybrid / Composite Cryptography (QTS-06.9) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Hybrid / Composite Cryptography (QTS-06.9) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-06.json b/docs/api/compensating-controls/QTS-06.json new file mode 100644 index 00000000..38c5457c --- /dev/null +++ b/docs/api/compensating-controls/QTS-06.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-06", + "risk_if_not_implemented": "Without Crypto-Agility Architecture, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Crypto-Agility Architecture (QTS-06) by embedding security requirements into design processes as an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CRY-09", + "name": "Cryptographic Key Management", + "description": "Mechanisms exist to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", + "justification": "Cryptographic Key Management (CRY-09) provides cryptographic protection and key governance that compensates for the absence of Crypto-Agility Architecture (QTS-06) by ensuring data confidentiality and integrity through alternative or complementary cryptographic mechanisms. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-07.json b/docs/api/compensating-controls/QTS-07.json new file mode 100644 index 00000000..0e05cca6 --- /dev/null +++ b/docs/api/compensating-controls/QTS-07.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-07", + "risk_if_not_implemented": "Without Cryptographic Incident Response (Emergency Algorithm Transition), cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "IRO-04", + "name": "Incident Response Plan (IRP)", + "description": "Mechanisms exist to maintain and make available a current and viable Incident Response Plan (IRP) to all stakeholders.", + "justification": "Incident Response Plan (IRP) (IRO-04) provides incident response capability that compensates for the absence of Cryptographic Incident Response (Emergency Algorithm Transition) (QTS-07) by enabling timely detection, containment, and recovery from security events. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "BCD-07", + "name": "Alternative Security Measures", + "description": "Mechanisms exist to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised.", + "justification": "Alternative Security Measures (BCD-07) provides overlapping security capability that compensates for the absence of Cryptographic Incident Response (Emergency Algorithm Transition) (QTS-07) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/QTS-08.json b/docs/api/compensating-controls/QTS-08.json new file mode 100644 index 00000000..f72fe701 --- /dev/null +++ b/docs/api/compensating-controls/QTS-08.json @@ -0,0 +1,16 @@ +{ + "control_id": "QTS-08", + "risk_if_not_implemented": "Without PQC Implementation Validation & Interoperability Testing, cryptographic protections may be inadequate or quantum-vulnerable, risking future decryption of currently protected data.", + "compensating_control_1": { + "control_id": "TDA-09", + "name": "Security, Compliance & Resilience Testing Throughout Development", + "description": "Mechanisms exist to require system developers/integrators consult with security, compliance and/or resilience personnel to: \n(1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability;\n(2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the control testing and evaluation process; and\n(3) Document the results.", + "justification": "Security, Compliance & Resilience Testing Throughout Development (TDA-09) provides periodic assessment and verification that compensates for the absence of PQC Implementation Validation & Interoperability Testing (QTS-08) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAO-06", + "name": "Technical Verification", + "description": "Mechanisms exist to perform Information Assurance Program (IAP) activities to evaluate the design, implementation and effectiveness of technical security, compliance and resilience controls.", + "justification": "Technical Verification (IAO-06) provides periodic assessment and verification that compensates for the absence of PQC Implementation Validation & Interoperability Testing (QTS-08) by providing structured evaluation of the environment to surface gaps and verify residual control effectiveness. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/RSK-03.2.json b/docs/api/compensating-controls/RSK-03.2.json new file mode 100644 index 00000000..0ccddd62 --- /dev/null +++ b/docs/api/compensating-controls/RSK-03.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "RSK-03.2", + "risk_if_not_implemented": "Without Risk Owner, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "GOV-04", + "name": "Assigned Security, Compliance & Resilience Responsibilities", + "description": "Mechanisms exist to assign one or more qualified individuals with the mission and resources to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP).", + "justification": "Assigned Security, Compliance & Resilience Responsibilities (GOV-04) provides resilience and recovery capability that compensates for the absence of Risk Owner (RSK-03.2) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "RSK-06", + "name": "Risk Remediation", + "description": "Mechanisms exist to remediate risks to an acceptable level.", + "justification": "Risk Remediation (RSK-06) provides vulnerability management that compensates for the absence of Risk Owner (RSK-03.2) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/SAT-04.1.json b/docs/api/compensating-controls/SAT-04.1.json new file mode 100644 index 00000000..f5fb216d --- /dev/null +++ b/docs/api/compensating-controls/SAT-04.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "SAT-04.1", + "risk_if_not_implemented": "Without Training Feedback, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "SAT-04", + "name": "Security, Compliance & Resilience Training Records", + "description": "Mechanisms exist to document, retain and monitor individual training activities, including:\n(1) Initial security, compliance and resilience awareness training;\n(2) Recurring awareness training; and\n(3) Technology Assets, Applications and/or Services (TAAS)-specific training.", + "justification": "Security, Compliance & Resilience Training Records (SAT-04) provides personnel training and awareness that compensates for the absence of Training Feedback (SAT-04.1) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "GOV-05", + "name": "Measures of Performance", + "description": "Mechanisms exist to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "justification": "Measures of Performance (GOV-05) provides overlapping security capability that compensates for the absence of Training Feedback (SAT-04.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/SEA-01.4.json b/docs/api/compensating-controls/SEA-01.4.json new file mode 100644 index 00000000..4be23c44 --- /dev/null +++ b/docs/api/compensating-controls/SEA-01.4.json @@ -0,0 +1,16 @@ +{ + "control_id": "SEA-01.4", + "risk_if_not_implemented": "Without Secure Architecture Principles, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Secure Architecture Principles (SEA-01.4) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-05", + "name": "Developer Architecture & Design", + "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", + "justification": "Developer Architecture & Design (TDA-05) provides secure engineering and architectural guidance that compensates for the absence of Secure Architecture Principles (SEA-01.4) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/SEA-01.5.json b/docs/api/compensating-controls/SEA-01.5.json new file mode 100644 index 00000000..c0c8697d --- /dev/null +++ b/docs/api/compensating-controls/SEA-01.5.json @@ -0,0 +1,16 @@ +{ + "control_id": "SEA-01.5", + "risk_if_not_implemented": "Without Security-Aware Design, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "SEA-01", + "name": "Secure Engineering Principles", + "description": "Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).", + "justification": "Secure Engineering Principles (SEA-01) provides secure engineering and architectural guidance that compensates for the absence of Security-Aware Design (SEA-01.5) by embedding security requirements into design processes as an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "PRM-04", + "name": "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.", + "justification": "Security, Compliance & Resilience In Project Management (PRM-04) provides resilience and recovery capability that compensates for the absence of Security-Aware Design (SEA-01.5) by ensuring the organization can restore operations when the primary control is absent. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/SEA-08.2.json b/docs/api/compensating-controls/SEA-08.2.json new file mode 100644 index 00000000..99744a24 --- /dev/null +++ b/docs/api/compensating-controls/SEA-08.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "SEA-08.2", + "risk_if_not_implemented": "Without Non-Persistent Information, sensitive information may be inadvertently exposed through error messages, insecure code, or persistent ephemeral data.", + "compensating_control_1": { + "control_id": "DCH-09", + "name": "System Media Sanitization", + "description": "Mechanisms exist to sanitize system media with the strength and integrity commensurate with the classification or sensitivity of the information prior to disposal, release out of organizational control or release for reuse.", + "justification": "System Media Sanitization (DCH-09) provides overlapping security capability that compensates for the absence of Non-Persistent Information (SEA-08.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "IAC-25", + "name": "Session Termination", + "description": "Automated mechanisms exist to log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity.", + "justification": "Session Termination (IAC-25) provides overlapping security capability that compensates for the absence of Non-Persistent Information (SEA-08.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/TDA-06.7.json b/docs/api/compensating-controls/TDA-06.7.json new file mode 100644 index 00000000..812ff67c --- /dev/null +++ b/docs/api/compensating-controls/TDA-06.7.json @@ -0,0 +1,16 @@ +{ + "control_id": "TDA-06.7", + "risk_if_not_implemented": "Without Programming Language Selection, residual security, compliance, or resilience risk may accumulate without structured oversight, leading to unmanaged exposures.", + "compensating_control_1": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Programming Language Selection (TDA-06.7) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "CFG-04", + "name": "Software Usage Restrictions", + "description": "Mechanisms exist to enforce software usage restrictions to comply with applicable contract agreements and copyright laws.", + "justification": "Software Usage Restrictions (CFG-04) provides overlapping security capability that compensates for the absence of Programming Language Selection (TDA-06.7) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/TDA-13.1.json b/docs/api/compensating-controls/TDA-13.1.json new file mode 100644 index 00000000..a61b3aee --- /dev/null +++ b/docs/api/compensating-controls/TDA-13.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "TDA-13.1", + "risk_if_not_implemented": "Without Developer Knowledge & Skills Register, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "HRS-13", + "name": "Identify Critical Skills & Gaps", + "description": "Mechanisms exist to evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist.", + "justification": "Identify Critical Skills & Gaps (HRS-13) provides overlapping security capability that compensates for the absence of Developer Knowledge & Skills Register (TDA-13.1) by addressing related risk objectives through an alternative control mechanism. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Developer Knowledge & Skills Register (TDA-13.1) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/TDA-13.2.json b/docs/api/compensating-controls/TDA-13.2.json new file mode 100644 index 00000000..4708d088 --- /dev/null +++ b/docs/api/compensating-controls/TDA-13.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "TDA-13.2", + "risk_if_not_implemented": "Without Developer Training, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "SAT-03", + "name": "Role-Based Security, Compliance & Resilience Training", + "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", + "justification": "Role-Based Security, Compliance & Resilience Training (SAT-03) provides personnel training and awareness that compensates for the absence of Developer Training (TDA-13.2) by equipping personnel with the knowledge and skills needed to recognize and respond to relevant threats. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "TDA-06", + "name": "Secure Software Development Practices (SSDP)", + "description": "Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).", + "justification": "Secure Software Development Practices (SSDP) (TDA-06) provides overlapping security capability that compensates for the absence of Developer Training (TDA-13.2) by addressing related risk objectives through an alternative control mechanism. Given the people-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/TDA-19.1.json b/docs/api/compensating-controls/TDA-19.1.json new file mode 100644 index 00000000..9f5313c9 --- /dev/null +++ b/docs/api/compensating-controls/TDA-19.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "TDA-19.1", + "risk_if_not_implemented": "Without Designated Roles To View Error Messages, security design weaknesses may be built into systems, increasing long-term vulnerability and the cost of remediation.", + "compensating_control_1": { + "control_id": "IAC-21", + "name": "Least Privilege", + "description": "Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "justification": "Least Privilege (IAC-21) provides access control enforcement that compensates for the absence of Designated Roles To View Error Messages (TDA-19.1) by restricting system and data access through alternative identity and access management mechanisms. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "SEA-09", + "name": "Information Output Filtering", + "description": "Mechanisms exist to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content.", + "justification": "Information Output Filtering (SEA-09) provides overlapping security capability that compensates for the absence of Designated Roles To View Error Messages (TDA-19.1) by addressing related risk objectives through an alternative control mechanism. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/THR-01.1.json b/docs/api/compensating-controls/THR-01.1.json new file mode 100644 index 00000000..caf78f47 --- /dev/null +++ b/docs/api/compensating-controls/THR-01.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "THR-01.1", + "risk_if_not_implemented": "Without Dynamic Threat Awareness, personnel may lack knowledge or skills to recognize and respond to security threats, increasing organizational risk.", + "compensating_control_1": { + "control_id": "THR-01", + "name": "Threat Intelligence Program", + "description": "Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities.", + "justification": "Threat Intelligence Program (THR-01) provides policy-level governance that compensates for the absence of Dynamic Threat Awareness (THR-01.1) by establishing documented expectations, accountability structures, and organizational guardrails. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-01", + "name": "Continuous Monitoring", + "description": "Mechanisms exist to facilitate the implementation of enterprise-wide monitoring controls.", + "justification": "Continuous Monitoring (MON-01) provides detective monitoring capability that compensates for the absence of Dynamic Threat Awareness (THR-01.1) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the process-oriented nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/THR-01.2.json b/docs/api/compensating-controls/THR-01.2.json new file mode 100644 index 00000000..c2c8c42b --- /dev/null +++ b/docs/api/compensating-controls/THR-01.2.json @@ -0,0 +1,16 @@ +{ + "control_id": "THR-01.2", + "risk_if_not_implemented": "Without Predictive Cyber Analytics, the organization's threat model may become stale, leaving security controls misaligned with the actual threat landscape.", + "compensating_control_1": { + "control_id": "THR-07", + "name": "Threat Hunting", + "description": "Mechanisms exist to perform cyber threat hunting that uses Indicators of Compromise (IoC) to detect, track and disrupt threats that evade existing security controls.", + "justification": "Threat Hunting (THR-07) provides overlapping security capability that compensates for the absence of Predictive Cyber Analytics (THR-01.2) by addressing related risk objectives through an alternative control mechanism. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "MON-16", + "name": "Anomalous Behavior", + "description": "Mechanisms exist to utilize User & Entity Behavior Analytics (UEBA) and/or User Activity Monitoring (UAM) solutions to detect and respond to anomalous behavior that could indicate account compromise or other malicious activities.", + "justification": "Anomalous Behavior (MON-16) provides detective monitoring capability that compensates for the absence of Predictive Cyber Analytics (THR-01.2) by identifying unauthorized, anomalous, or non-compliant activity that the primary control would have prevented. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/compensating-controls/VPM-02.1.json b/docs/api/compensating-controls/VPM-02.1.json new file mode 100644 index 00000000..f1822334 --- /dev/null +++ b/docs/api/compensating-controls/VPM-02.1.json @@ -0,0 +1,16 @@ +{ + "control_id": "VPM-02.1", + "risk_if_not_implemented": "Without Known Exploited Vulnerabilities (KEV) Mitigations, unpatched vulnerabilities may remain exploitable, directly increasing the probability of successful attacks against the organization.", + "compensating_control_1": { + "control_id": "VPM-02", + "name": "Vulnerability Remediation Process", + "description": "Mechanisms exist to ensure that vulnerabilities are properly identified, tracked and remediated.", + "justification": "Vulnerability Remediation Process (VPM-02) provides vulnerability management that compensates for the absence of Known Exploited Vulnerabilities (KEV) Mitigations (VPM-02.1) by reducing the exploitable attack surface by addressing known weaknesses and prioritizing critical remediations. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + }, + "compensating_control_2": { + "control_id": "NET-03", + "name": "Boundary Protection", + "description": "Mechanisms exist to monitor and control communications at the external network boundary and at key internal boundaries within the network.", + "justification": "Boundary Protection (NET-03) provides network-level access restriction that compensates for the absence of Known Exploited Vulnerabilities (KEV) Mitigations (VPM-02.1) by limiting attacker reach and lateral movement opportunities across the environment. Given the technology-focused nature of this control, this compensating control targets the same underlying risk objective through an alternative approach, helping to maintain an acceptable level of residual risk until the primary control can be implemented." + } +} \ No newline at end of file diff --git a/docs/api/controls.json b/docs/api/controls.json index ee262245..4be4b9fe 100644 --- a/docs/api/controls.json +++ b/docs/api/controls.json @@ -1,5 +1,5 @@ { - "total": 1468, + "total": 1534, "controls": [ { "control_id": "GOV-01", @@ -22,9 +22,9 @@ }, "maturity": { "0": "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.", - "1": "Cybersecurity & Data Protection Governance (GOV) capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement and manage the organization's internal control system.\n▪ Legal representation is consulted on an as-needed basis.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105,10 +105,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF6" @@ -266,6 +266,9 @@ "general-nist-800-171-r3": [ "03.15.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[01]" + ], "general-nist-csf-2-0": [ "GV", "GV.RM-01", @@ -283,9 +286,6 @@ "12.4", "A3.1.2" ], - "general-scf-dpmp-2025": [ - "1.0" - ], "general-sparta": [ "CM0005" ], @@ -429,6 +429,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PM-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(1)" + ], "usa-federal-sro-finra": [ "248.30(a)(2)(ii)", "248.201(e)" @@ -449,18 +452,18 @@ "155.260(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)", - "164.530(c)(1)", - "164.530(i)(1)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)", + "§ 164.530(c)(1)", + "§ 164.530(i)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)" ], "usa-federal-irs-1075-2021": [ "PM-1" @@ -534,6 +537,9 @@ "emea-eu-ai-act-2024": [ "Article 17.2" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.1.30" + ], "emea-eu-dora-2023": [ "Article 5.1", "Article 9.4", @@ -566,144 +572,75 @@ "1.1.1(b)", "6.7.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" + "emea-eu-psd2-2015": [ + "95(1)", + "97(3)" ], "emea-deu-bsrit-2017": [ - "4.1" + "3.1", + "4.1", + "4.8" ], "emea-deu-c5-2020": [ - "OIS-01" - ], - "emea-grc-pirppd-1997": [ - "10" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "3.2", - "4.25" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35" - ], - "emea-nor-pda-2018": [ - "13", - "14" + "OIS-01", + "OIS-01-BP1", + "OIS-01-DOAR" ], - "emea-pol-act-29-1997": [ - "1", - "36" + "emea-isr-cmo-2-0": [ + "2.A", + "4.2, Stage 0" ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-1-2" ], "emea-sau-ecc-1-2018": [ "1-2-1", - "1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "1-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "2-1-1" ], "emea-sau-sama-csf-1-2017": [ "3.1.1" ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 6.1", - "Article 6.2", - "Article 13.1", - "Article 35.1" - ], "emea-esp-decree-311-2022": [ - "13.1", - "35.1", - "5", - "6.1", - "6.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "6.1 [ORG.1]" - ], - "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "Article 8(1)", + "Article 8(2)", + "Article 8(5)", + "Article 9(1)", + "Article 9(1)(a)", + "Article 9(1)(b)", + "Article 9(2)", + "Article 10(1)", + "Article 10(2)", + "Article 10(3)", + "Article 12(6)(a)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-cap-1850-2020": [ - "A1" + "A1", + "B1" ], - "apac-aus-privacy-act-1998": [ - "APP Part 1", - "APP Part 11" + "apac-aus-ism-2026-march": [ + "ISM-0047" ], - "apac-aus-ism-2024-june": [ - "ISM-0888" + "apac-aus-ps-cps-230-2023": [ + "12(a)", + "16(c)" ], "apac-aus-ps-cps-234-2019": [ - "13", - "18", - "19" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" - ], - "apac-hkg-pdo-2022": [ - "Principle 4" - ], - "apac-ind-privacy-rules-2011": [ - "8" + "15", + "17" ], "apac-ind-sebi-2024": [ "GV.OC.S1", "GV.OC.S2", "PR.IP.S17" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "4.4.1.1", "4.4.1.2", @@ -716,41 +653,22 @@ "5.1.1", "6.1" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "10.1", + "11.1", + "11.2", + "11.5" ], "apac-nzl-ism-3-9": [ - "5.1.14.C.01" - ], - "apac-phl-dpa-2012": [ - "25", - "27", - "28" - ], - "apac-sgp-pdpa-2012": [ - "12", - "24" - ], - "apac-kor-pipa-2011": [ - "3", - "29", - "30" - ], - "apac-twn-pdpa-2025": [ - "27" + "5.1.14.C.01", + "5.1.16.C.01", + "16.1.24.C.01" ], - "americas-bhs-dpa-2003": [ - "6" + "apac-sgp-mas-trm-2021": [ + "3.1.4" ], "americas-bmu-mba-coc-2020": [ - "4", - "5.4" - ], - "amaericas-can-osfi-self-assessment": [ - "6.5", - "6.6", - "6.7", - "6.23" + "6.1" ], "americas-can-osfi-b13-2022": [ "1", @@ -759,20 +677,11 @@ "2.1.1", "3" ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4" - ], - "americas-mex-fdpa-2010": [ - "19" ] } }, @@ -797,9 +706,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to trends.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align security, compliance and resilience capabilities with business requirements through a steering committee or advisory board, comprised of key cybersecurity, data protection and business executives, which meets formally and on a regular basis.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align security, compliance and resilience capabilities with business requirements through a steering committee or advisory board, comprised of key cybersecurity, data protection and business executives, which meets formally and on a regular basis.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -875,10 +784,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", @@ -1033,6 +942,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-csf-2-0": [ "GV.RM-01", "GV.RM-03", @@ -1135,9 +1047,9 @@ "500.4(d)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(2)", - "3.2.1(3)", - "3.2.1(4)" + "3.2.1.2", + "3.2.1.3", + "3.2.1.4" ], "emea-eu-dora-2023": [ "Article 5.2", @@ -1172,21 +1084,46 @@ "2.2", "2.3", "2.4", - "2.5" + "2.5", + "4.3" + ], + "emea-deu-c5-2020": [ + "OIS-01" + ], + "emea-isr-cmo-2-0": [ + "2.A" ], "emea-sau-cgiot-2024": [ "1-1-4" ], - "emea-sau-sama-csf-1-2017": [ - "3.1.1" + "emea-sau-ecc-1-2018": [ + "1-1-1", + "1-2-3", + "1-4-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 27" + "emea-sau-sama-csf-1-2017": [ + "3.1.1.1", + "3.1.1.2", + "3.1.1.3", + "3.1.1.3.a", + "3.1.1.3.b", + "3.1.1.3.c", + "3.1.1.4", + "3.1.1.4.a", + "3.1.1.4.b", + "3.1.1.4.c", + "3.1.1.4.d", + "3.1.1.5", + "3.1.1.6", + "3.1.1.7", + "3.1.1.8", + "3.1.1.9", + "3.1.1.9.a", + "3.1.1.9.b", + "3.1.1.9.c" ], "emea-esp-decree-311-2022": [ - "27", - "5" + "Article 12(1)(d)" ], "emea-gbr-caf-4-0": [ "A1.a", @@ -1210,22 +1147,24 @@ "1103", "1202" ], - "apac-aus-ism-2024-june": [ - "ISM-0725" + "apac-aus-ism-2026-march": [ + "ISM-0725", + "ISM-1998", + "ISM-1999", + "ISM-2002", + "ISM-2003", + "ISM-2005", + "ISM-2006" ], "apac-aus-ps-cps-230-2023": [ - "20", - "21", - "22(a)", - "22(b)", - "22(c)", - "23", + "16(a)", + "17", + "18", "24", - "25" + "27(a)" ], "apac-aus-ps-cps-234-2019": [ - "13", - "19" + "13" ], "apac-ind-dpdpa-2023": [ "8(6)", @@ -1263,7 +1202,16 @@ "4.6.3.2", "4.6.3.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.3", + "8.4", + "8.5", + "8.7", + "11.17", + "12.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP12", "HML12", "HML21" @@ -1278,41 +1226,27 @@ "apac-sgp-mas-trm-2021": [ "3.1.1", "3.1.2", - "3.1.3", - "3.1.4", "3.1.5", - "3.1.6", + "3.1.7", "3.1.7(a)", "3.1.7(b)", "3.1.7(c)", "3.1.7(d)", "3.1.7(e)", "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", - "3.1.8(e)" + "3.1.7(g)" ], "americas-bmu-mba-coc-2020": [ - "5.1", - "5.6" - ], - "amaericas-can-osfi-self-assessment": [ - "6.5", - "6.6", - "6.7", - "6.21", - "6.22", - "6.23", - "6.24" + "5.1" ], "americas-can-osfi-b13-2022": [ "1", "1.1.2", "1.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] @@ -1323,7 +1257,7 @@ "title": "Status Reporting To Governing Body", "family": "GOV", "description": "Mechanisms exist to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", - "scf_question": "Does the organization provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP)?", + "scf_question": "Does the organization provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to its Security, Compliance & Resilience Program (SCRP)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1345,9 +1279,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to trends.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1404,10 +1338,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF2", @@ -1483,6 +1417,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-csf-2-0": [ "GV.OV", "GV.OV-01", @@ -1491,16 +1428,16 @@ "GV.SC-09", "ID" ], - "general-scf-dpmp-2025": [ - "11.5", - "11.8" - ], "usa-federal-doe-c2m2-2-1": [ "PROGRAM-2g" ], "usa-federal-sro-fca-crm-2023": [ "609.930(e)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(14)", + "101.645(a)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(i)", "314.4(i)(1)", @@ -1521,8 +1458,8 @@ "500.4(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(e)", - "3.3.5(24)" + "3.3.1.13(e)", + "3.3.5.24" ], "emea-eu-dora-2023": [ "Article 5.2(i)", @@ -1537,19 +1474,29 @@ "13.2.2(c)" ], "emea-deu-bsrit-2017": [ - "3.9", "3.11", "4.10", "7.5" ], - "apac-aus-ism-2024-june": [ - "ISM-0718" + "emea-deu-c5-2020": [ + "SPN-01" + ], + "emea-sau-ecc-1-2018": [ + "1-8-3" + ], + "emea-esp-decree-311-2022": [ + "Article 31(6)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" + ], + "apac-aus-ism-2026-march": [ + "ISM-0718", + "ISM-1918", + "ISM-2000" ], "apac-aus-ps-cps-230-2023": [ - "30", - "58(a)", - "58(b)", - "58(c)" + "58" ], "apac-ind-dpdpa-2023": [ "10(2)(c)(ii)" @@ -1560,7 +1507,13 @@ "apac-jpn-ismap": [ "4.6.1.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.4", + "8.6", + "9.3", + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP46", "HHSP75", "HML12", @@ -1572,6 +1525,10 @@ "HSUP38", "HSUP65" ], + "apac-sgp-mas-trm-2021": [ + "3.1.3", + "3.1.8(e)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1.2" @@ -1586,7 +1543,7 @@ "title": "Commitment To Continual Improvements", "family": "GOV", "description": "Mechanisms exist to commit appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", - "scf_question": "Does the organization commit appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies?", + "scf_question": "Does the organization commit appropriate resources needed for continual improvement of its Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -1601,7 +1558,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to observed trends.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ Appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ Appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1643,10 +1600,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.3-POF4" @@ -1689,59 +1646,81 @@ "EF:SG3.SP3", "EF:SG4.SP3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.48" + ], "emea-eu-nis2-annex-2024": [ "1.1.1(d)", "1.1.1(e)" ], + "emea-deu-bsrit-2017": [ + "2.2", + "4.4" + ], + "emea-deu-c5-2020": [ + "OIS-01-BP3", + "SA-02-BP2" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 5", + "Appendix A, 1.1" + ], + "emea-sau-ecc-1-2018": [ + "1-1-3", + "1-3-4", + "2-3-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-69" + ], + "emea-esp-decree-311-2022": [ + "Article 12(6)(ñ)", + "Article 27" + ], "apac-jpn-ismap": [ "4.6.1.1", "4.6.1.2", "4.6.3.3" + ], + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.4" ] } }, { - "control_id": "GOV-02", - "title": "Publishing Security, Compliance & Resilience Documentation", + "control_id": "GOV-01.4", + "title": "Secure Practices Alignment Justification", "family": "GOV", - "description": "Mechanisms exist to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", - "scf_question": "Does the organization establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities?", - "relative_weight": 10, + "description": "Mechanisms exist to align the organization’s Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices.", + "scf_question": "Does the organization align its Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices?", + "relative_weight": 8, "conformity_cadence": "Annual", - "evidence_requests": [ - "E-GOV-08", - "E-GOV-09", - "E-GOV-11" - ], + "evidence_requests": [], "pptdf": "Process", "nist_csf_function": "Govern", "scrm_focus": { "strategic": true, "operational": true, - "tactical": true + "tactical": false }, "maturity": { "0": "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.", - "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ People affected by documentation changes are provided notification of the policy and standard changes.", - "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ The organization's cybersecurity policies and standards are made available to internal personnel.\n▪ Documented procedures exist for requesting a deviation from approved standards.\n▪ The responsibility for enforcing cybersecurity and data protection control implementation is assigned to business / process owners and asset custodians.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", - "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align the organization’s Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "SCRMS", - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Fundamentals", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "Community Derived" ], "possible_solutions": { - "micro_small": "∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)\n∙ SCFConnect (https://scfconnect.com)\n∙ Shared drive or intranet for policy distribution (e.g., Google Drive, SharePoint Online)", - "small": "∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)\n∙ SCFConnect (https://scfconnect.com)\n∙ Document management system (e.g., SharePoint, Confluence, Notion)", - "medium": "∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)\n∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)\n∙ Document management / intranet portal (e.g., SharePoint, Confluence)\n∙ Policy acknowledgement tracking (e.g., KnowBe4, Absorb LMS)", - "large": "∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)\n∙ Policy management platform\n∙ Version-controlled policy repository with access controls\n∙ Automated policy attestation and acknowledgement tracking", - "enterprise": "∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)\n∙ Enterprise policy management platform\n∙ Integrated GRC policy module with automated review workflows\n∙ Enterprise-wide policy acknowledgement and training integration" + "micro_small": "∙ Informal alignment with NIST CSF 2.0, SCF CORE Fundamentals, CIS Controls or another framework that meets the organization's needs.", + "small": "∙ Formal alignment with NIST CSF 2.0, SCF CORE Fundamentals, CIS Controls or another framework that meets the organization's needs.\n∙ Gap analysis documentation\n∙ Written justification for framework choices.", + "medium": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ Documented gap analysis and justification\n∙ GRC platform alignment reports (e.g., SCFConnect)", + "large": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ Regulatory mapping evidence packages\n∙ GRC platform with framework comparison reporting", + "enterprise": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ External auditor validation\n∙ Board-level reporting on framework compliance\n∙ GRC platform with automated framework mapping" }, "risks": [ "R-AC-1", @@ -1797,10 +1776,149 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "emea-eu-psd2-2015": [ + "98(1)", + "98(1)(a)", + "98(1)(b)", + "98(1)(c)", + "98(1)(d)", + "98(2)", + "98(3)", + "98(4)", + "98(5)" + ], + "emea-deu-bsrit-2017": [ + "2.1" + ], + "emea-deu-c5-2020": [ + "OIS-01", + "RB-22-DOAR" + ], + "emea-sau-otcc-1-2022": [ + "1-1-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.3", + "3.2.3.1", + "3.2.3.1.a", + "3.2.3.1.b", + "3.2.3.1.c" + ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(b)" + ], + "apac-nzl-ism-3-9": [ + "5.1.16.C.02" + ] + } + }, + { + "control_id": "GOV-02", + "title": "Publishing Security, Compliance & Resilience Documentation", + "family": "GOV", + "description": "Mechanisms exist to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", + "scf_question": "Does the organization establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities?", + "relative_weight": 10, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-GOV-08", + "E-GOV-09", + "E-GOV-11" + ], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ People affected by documentation changes are provided notification of the policy and standard changes.", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ The organization's cybersecurity policies and standards are made available to internal personnel.\n▪ Documented procedures exist for requesting a deviation from approved standards.\n▪ The responsibility for enforcing cybersecurity and data protection control implementation is assigned to business / process owners and asset custodians.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", + "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "SCRMS", + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Fundamentals", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)\n∙ SCFConnect (https://scfconnect.com)\n∙ Shared drive or intranet for policy distribution (e.g., Google Drive, SharePoint Online)", + "small": "∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)\n∙ SCFConnect (https://scfconnect.com)\n∙ Document management system (e.g., SharePoint, Confluence, Notion)", + "medium": "∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)\n∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)\n∙ Document management / intranet portal (e.g., SharePoint, Confluence)\n∙ Policy acknowledgement tracking (e.g., KnowBe4, Absorb LMS)", + "large": "∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)\n∙ Policy management platform\n∙ Version-controlled policy repository with access controls\n∙ Automated policy attestation and acknowledgement tracking", + "enterprise": "∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)\n∙ Enterprise policy management platform\n∙ Integrated GRC policy module with automated review workflows\n∙ Enterprise-wide policy acknowledgement and training integration" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.0", @@ -2367,6 +2485,19 @@ "A.03.15.01.a[03]", "A.03.15.01.a[04]" ], + "general-nist-800-172-r3": [ + "03.01.17E", + "03.05.07E", + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]", + "A.03.05.07E.ODP[01]", + "DS-A.03.17.03E.a[01]", + "DS-A.03.17.03E.a[02]", + "DS-A.03.17.03E.a[03]", + "DS-A.03.17.03E.a[04]" + ], "general-nist-csf-2-0": [ "GV.PO", "GV.PO-01", @@ -2504,9 +2635,6 @@ "12.1.2", "12.1.3" ], - "general-scf-dpmp-2025": [ - "11.2" - ], "general-sparta": [ "CM0088" ], @@ -2657,6 +2785,9 @@ "SI-01", "SR-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)" + ], "usa-federal-sro-finra": [ "248.30(a)(1)", "248.30(a)(2)" @@ -2672,41 +2803,41 @@ "155.260(d)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)", - "164.530(j)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)", + "§ 164.530(j)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)" ], "usa-federal-irs-1075-2021": [ "2.C.2", @@ -2816,6 +2947,10 @@ "17.03(2)(c)", "17.04" ], + "usa-state-nv-privacy-law-2023": [ + "603A.525.2", + "603A.525.2(a)" + ], "usa-state-nv-regulation-5-2024": [ "5.260.6" ], @@ -2911,9 +3046,9 @@ "SI-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.1(28)", - "3.4.1(29)", - "3.4.5(38)" + "3.4.1.28", + "3.4.5.38", + "3.5.50" ], "emea-eu-dora-2023": [ "Article 6.2", @@ -2947,127 +3082,122 @@ "9.1", "11.1.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.2", - "4.3", "4.8" ], "emea-deu-c5-2020": [ - "OIS-01", "OIS-02", - "SP-01" - ], - "emea-isr-cmo-1-0": [ - "1.1", - "4.1", - "4.25", - "5.2", - "5.3", - "9.1", - "10.1", - "11.2", - "12.1", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "20.1", - "21.1", - "22.1", - "24.1", - "25.1" - ], - "emea-nga-dpr-2019": [ - "4.1(1)" - ], - "emea-qat-pdppl-2020": [ - "8.4" + "OIS-06", + "SA-01", + "SA-01-BP1", + "SA-01-BP2", + "SA-01-BP3", + "SA-01-BP4", + "SA-01-BP5", + "SA-01-BP6", + "MDM-01" ], "emea-sau-cgiot-2024": [ "1-2-1" ], "emea-sau-ecc-1-2018": [ "1-3-1", - "1-3-3" + "1-3-3", + "2-1-1", + "2-1-2", + "2-1-3", + "2-1-4", + "2-2-1", + "2-2-2" ], "emea-sau-otcc-1-2022": [ - "1-1", - "1-1-1" + "1-1-1", + "1-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-25" + "VII.B.TPC-24", + "VII.B.TPC-25" ], "emea-sau-sama-csf-1-2017": [ - "3.1.3" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 12.1", - "Article 12.1(a)", - "Article 12.1(b)", - "Article 12.1(c)", - "Article 12.1(d)", - "Article 12.1(e)", - "Article 12.1(f)", - "Article 12.2", - "Article 12.6", - "Article 12.6(a)", - "Article 12.6(b)", - "Article 12.6(c)", - "Article 12.6(d)", - "Article 12.6(e)", - "Article 12.6(f)", - "Article 12.6(g)", - "Article 12.6(h)", - "Article 12.6(i)", - "Article 12.6(j)", - "Article 12.6(k)", - "Article 12.6(l)", - "Article 12.6(m)", - "Article 12.6(n)", - "Article 12.6(ñ)", - "Article 12.7" + "3.1.3", + "3.1.3.1", + "3.1.3.3", + "3.1.3.3.a", + "3.1.3.3.b", + "3.1.3.3.c", + "3.1.3.3.d", + "3.1.3.4", + "3.1.3.4.a", + "3.1.3.4.b", + "3.1.3.4.c", + "3.1.3.4.d", + "3.1.3.4.e", + "3.1.3.4.f", + "3.1.3.4.f.1", + "3.1.3.4.f.2", + "3.1.3.4.f.3", + "3.1.3.4.f.4", + "3.1.3.4.f.5", + "3.1.3.4.f.6", + "3.1.3.4.f.7", + "3.1.3.4.f.8", + "3.3.5.1", + "3.3.5.4", + "3.3.5.4.a", + "3.3.5.4.b", + "3.3.5.4.b.1", + "3.3.5.4.b.2", + "3.3.5.4.b.3", + "3.3.5.4.b.4", + "3.3.5.4.b.5", + "3.3.5.4.b.6", + "3.3.5.4.b.7", + "3.3.5.4.c", + "3.3.5.4.d", + "3.3.5.4.e", + "3.3.5.4.f", + "3.3.5.4.f.1", + "3.3.5.4.f.1.a", + "3.3.5.4.f.1.b", + "3.3.5.4.f.2", + "3.3.5.4.f.3", + "3.3.5.4.f.4", + "3.3.5.4.f.4.a", + "3.3.5.4.f.4.b", + "3.3.5.4.f.4.c", + "3.3.8", + "3.3.8.1", + "3.3.8.4", + "3.3.8.5", + "3.3.8.6", + "3.3.8.6.a", + "3.3.8.6.b", + "3.3.8.6.c", + "3.3.8.6.d", + "3.3.8.6.e", + "3.3.8.6.f", + "3.3.8.6.g", + "3.3.8.6.h", + "3.3.8.6.h.1", + "3.3.8.6.h.2", + "3.3.8.6.h.3", + "3.3.8.6.h.4", + "3.3.8.6.h.5", + "3.3.8.6.i", + "3.3.8.6.j", + "3.3.10", + "3.3.10.1" ], "emea-esp-decree-311-2022": [ - "12.1", - "12.1(a)", - "12.1(b)", - "12.1(c)", - "12.1(d)", - "12.1(e)", - "12.1(f)", - "12.2", - "12.6", - "12.6(a)", - "12.6(b)", - "12.6(c)", - "12.6(d)", - "12.6(e)", - "12.6(f)", - "12.6(g)", - "12.6(h)", - "12.6(i)", - "12.6(j)", - "12.6(k)", - "12.6(l)", - "12.6(m)", - "12.6(n)", - "12.6(ñ)", - "12.7" + "Article 11(3)", + "Article 12(1)", + "Article 12(6)" ], - "emea-esp-ccn-stic-825-2023": [ - "6.1 [ORG.1]", - "6.2 [ORG.2]" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-caf-4-0": [ "A1", @@ -3075,8 +3205,7 @@ "B1.b" ], "emea-gbr-cap-1850-2020": [ - "A1", - "A5" + "A1" ], "emea-gbr-def-stan-05-138-2024": [ "1100", @@ -3101,20 +3230,23 @@ "2101" ], "apac-aus-privacy-principles-2026": [ - "APP 1" + "1.1.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0047", - "ISM-0888", "ISM-1478", "ISM-1551", "ISM-1602", "ISM-1784", - "ISM-1785" + "ISM-1785", + "ISM-2074" + ], + "apac-aus-ps-cps-230-2023": [ + "12(a)", + "47" ], "apac-aus-ps-cps-234-2019": [ - "18", - "19" + "18" ], "apac-ind-sebi-2024": [ "GV.PO.S1" @@ -3132,12 +3264,16 @@ "6", "6.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HML01", - "HHSP01" + "apac-mys-bnm-rmit-2025": [ + "8.6", + "9.5", + "10.16", + "10.20", + "11.12" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS02" + "HML01", + "HHSP01" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP01" @@ -3153,21 +3289,55 @@ "5.1.20.C.01", "5.1.20.C.02", "5.2.3.C.01", - "5.2.3.C.02" + "5.2.3.C.02", + "11.1.15.C.01", + "11.1.15.C.02", + "11.3.5.C.01", + "11.4.9.C.01", + "11.5.13.C.01", + "11.8.3.C.01", + "16.1.24.C.01", + "20.2.15.C.04", + "21.1.6.C.01", + "22.1.10.C.01", + "22.1.22.C.01" + ], + "apac-sgp-pdpa-2012": [ + "3.12(a)", + "3.12(c)" + ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(a)" ], "apac-sgp-mas-trm-2021": [ - "3.2.1" + "3.1.8(c)", + "3.2.1", + "3.3.1(d)", + "5.3.1", + "6.1.3", + "6.4.4", + "11.1.1" ], - "amaericas-can-osfi-self-assessment": [ - "6.1", - "6.3" + "americas-bmu-mba-coc-2020": [ + "5.3", + "7.1" ], "americas-can-osfi-b13-2022": [ "1", "3" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "2.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4" + ], + "americas-col-law-1581-2012": [ + "VI.17(k)" ] } }, @@ -3193,7 +3363,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to prohibit exceptions to standards, except when the exception has been formally assessed for risk impact, approved and recorded.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to prohibit exceptions to standards, except when the exception has been formally assessed for risk impact, approved and recorded.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3269,9 +3439,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-cobit-2019": [ "DSS06.04" @@ -3290,11 +3461,14 @@ "2.3.7", "2.7.3" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(14)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.1", @@ -3306,11 +3480,18 @@ "500.12(b)", "500.15(b)" ], + "emea-deu-c5-2020": [ + "SA-03" + ], "apac-ind-sebi-2024": [ "GV.PO.S3" ], "apac-jpn-ismap": [ "5.1.1.7" + ], + "apac-sgp-mas-trm-2021": [ + "3.2.2", + "7.3.3" ] } }, @@ -3334,9 +3515,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel perform an annual documentation review process that includes the scope of applicable statutory, regulatory and/or contractual obligations.\n▪ Recommendations for documentation edits are submitted for review and are handled in accordance with documentation change control processes.\n▪ Updated documentation versions are published, based on no less than an annual review cycle.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to review the Security, Compliance & Resilience Program (SCRP), including policies, standards and procedures, at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to review the Security, Compliance & Resilience Program (SCRP), including policies, standards and procedures, at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness. ", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3391,10 +3572,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF5", @@ -3830,7 +4011,8 @@ "general-nist-800-171a-r3": [ "A.03.15.01.ODP[01]", "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.b[02]", + "A.03.15.03.d[01]" ], "general-nist-csf-2-0": [ "GV.PO-02", @@ -3934,9 +4116,6 @@ "12.1.1", "12.1.2" ], - "general-scf-dpmp-2025": [ - "11.3" - ], "general-tisax-6-0-3": [ "1.5.1" ], @@ -4051,6 +4230,9 @@ "SI-01", "SR-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(b)", "314.4(g)" @@ -4059,16 +4241,16 @@ "155.260(a)(5)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)", - "164.530(i)(2)(i)", - "164.530(i)(2)(ii)", - "164.530(i)(2)(iii)", - "164.530(i)(3)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)", + "§ 164.530(i)(2)(i)", + "§ 164.530(i)(2)(ii)", + "§ 164.530(i)(2)(iii)", + "§ 164.530(i)(3)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "AC-1", @@ -4189,7 +4371,7 @@ "2447(b)(9)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(14)" + "3.3.1.14" ], "emea-eu-nis2-annex-2024": [ "1.1.2", @@ -4197,39 +4379,18 @@ "5.1.6", "6.7.3" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.2", - "4.8" + "4.4" ], "emea-deu-c5-2020": [ - "OIS-01", - "SP-02" + "SA-02", + "SA-02-BP1", + "SA-02-BP2", + "SA-02-BP3" ], - "emea-isr-cmo-1-0": [ - "1.1", - "5.2", - "9.1", - "10.1", - "11.2", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "21.1", - "22.1", - "24.1", - "25.1" + "emea-isr-cmo-2-0": [ + "Appendix A, 1.1" ], "emea-sau-cgiot-2024": [ "1-1-4", @@ -4240,11 +4401,8 @@ "emea-sau-ecc-1-2018": [ "1-1-3", "1-3-4", - "1-6-4", - "1-9-6", - "1-10-5", - "2-2-4", - "2-3-4", + "1-4-2", + "2-1-6", "2-4-4", "2-5-4", "2-6-4", @@ -4265,11 +4423,13 @@ "emea-sau-otcc-1-2022": [ "1-1-3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 27" + "emea-sau-sama-csf-1-2017": [ + "3.1.3.2" ], - "emea-esp-decree-311-2022": [ - "27" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-caf-4-0": [ "B1.a" @@ -4289,12 +4449,10 @@ "2100", "2101" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ + "ISM-0888", "ISM-1617" ], - "apac-aus-ps-cps-234-2019": [ - "19" - ], "apac-ind-sebi-2024": [ "GV.PO.S2", "GV.PO.S3", @@ -4310,7 +4468,10 @@ "5.1.2.3", "5.1.2.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -4323,7 +4484,7 @@ "5.1.21.C.02" ], "apac-sgp-mas-trm-2021": [ - "3.2.2" + "3.2.1" ], "americas-can-osfi-b13-2022": [ "1", @@ -4363,9 +4524,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is assigned the role and responsibilities to centrally manage, coordinate, develop, implement and maintain a cybersecurity and data protection program (e.g., cybersecurity director or Chief Information Security Officer (CISO)).\n▪ The individual assigned the role and responsibilities to centrally manage, coordinate, develop, implement and maintain a cybersecurity and data protection program develops plans to implement the organization's security, compliance and resiliency-related objectives.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ A qualified individual is assigned the role and responsibilities to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP) (e.g., cybersecurity director or Chief Information Security Officer (CISO)).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ A qualified individual is assigned the role and responsibilities to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP) (e.g., cybersecurity director or Chief Information Security Officer (CISO)).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4436,10 +4597,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1" @@ -4706,6 +4867,11 @@ "PM-06", "PM-29" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)", + "101.620(b)(3)", + "101.625(c)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(a)", "314.4(a)(1)", @@ -4713,10 +4879,10 @@ "314.4(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "usa-federal-irs-1075-2021": [ "PM-2", @@ -4765,9 +4931,7 @@ "Article 17.1(m)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.3.1(12)", - "3.7.5(91)" + "3.3.1.11" ], "emea-eu-dora-2023": [ "Article 5.2", @@ -4789,33 +4953,54 @@ "1.2.1", "1.2.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ - "4.4", "4.5", "4.6" ], - "emea-deu-c5-2020": [ - "OIS-03" + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B" ], "emea-sau-ecc-1-2018": [ "1-2-2", - "1-4-1", - "1-4-2", - "1-5-2" - ], - "emea-sau-otcc-1-2022": [ - "1-2", - "1-2-1-2" + "1-4-1" ], "emea-sau-sama-csf-1-2017": [ - "3.1.4" + "3.1.4", + "3.1.4.4", + "3.1.4.4.a", + "3.1.4.4.a.1", + "3.1.4.4.a.2", + "3.1.4.4.a.3", + "3.1.4.4.a.4", + "3.1.4.4.b", + "3.1.4.4.c", + "3.1.4.4.d", + "3.1.4.4.e", + "3.1.4.4.e.1", + "3.1.4.4.e.2", + "3.1.4.4.e.3", + "3.1.4.4.e.4", + "3.1.4.4.e.5", + "3.1.4.4.f", + "3.1.4.4.g", + "3.1.4.4.g.1", + "3.1.4.4.g.2", + "3.1.4.4.g.3", + "3.1.4.4.h", + "3.1.4.4.i", + "3.1.4.4.i.1", + "3.1.4.4.i.2", + "3.1.4.4.i.3", + "3.1.4.4.i.4" + ], + "emea-esp-decree-311-2022": [ + "Article 13(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "emea-gbr-caf-4-0": [ "A1.b", @@ -4836,7 +5021,7 @@ "1102", "1103" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0714", "ISM-0717", "ISM-0720", @@ -4847,22 +5032,17 @@ "ISM-0732", "ISM-0733", "ISM-0734", - "ISM-0735" + "ISM-0735", + "ISM-1997" ], "apac-aus-ps-cps-230-2023": [ - "21", - "24" + "23" ], "apac-aus-ps-cps-234-2019": [ - "14", - "19" + "14" ], "apac-chn-data-security-law-2021": [ - "45", - "46" - ], - "apac-chn-pipl-2021": [ - "52" + "Article 27" ], "apac-ind-dpdpa-2023": [ "19(3)" @@ -4877,7 +5057,11 @@ "5.1.1.6", "5.1.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6", + "9.4" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21", "HHSP27", "HML21", @@ -4918,32 +5102,24 @@ "3.2.19.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.1.7(a)", - "3.1.7(b)", - "3.1.7(c)", - "3.1.7(d)", - "3.1.7(e)", - "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", - "3.1.8(e)" + "3.1.3", + "3.1.8" + ], + "americas-arg-ppd-2018": [ + "E.1.2-8" ], "americas-bmu-mba-coc-2020": [ "5.2" ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "1.2", - "6.2" - ], "americas-can-osfi-b13-2022": [ "1", "1.1", "1.1.1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.1", + "1.1.2" ] } }, @@ -4967,9 +5143,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to enforce an accountability structure so that appropriate teams and individuals are empowered, responsible and trained for mapping, measuring and managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to enforce an accountability structure so that appropriate teams and individuals are empowered, responsible and trained for mapping, measuring and managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5054,10 +5230,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1", @@ -5132,6 +5308,9 @@ "general-nist-800-37-r2": [ "TASK P-9" ], + "general-nist-800-172a-r3": [ + "A.03.02.03E.ODP[01]" + ], "general-nist-800-218": [ "PO.2.3" ], @@ -5161,6 +5340,9 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)" + ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(c)(1)" ], @@ -5172,14 +5354,55 @@ "Article 17.1(m)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.7.5(91)" + "3.3.1.11", + "3.3.1.12" ], "emea-deu-bsrit-2017": [ "4.5", "4.6", "4.10" ], + "emea-deu-c5-2020": [ + "SA-01-BP4" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" + ], + "emea-qat-pdppl-2020": [ + "3.11.2" + ], + "emea-sau-ecc-1-2018": [ + "1-4-1" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.4.1", + "3.1.4.1.a", + "3.1.4.1.b", + "3.1.4.1.c", + "3.1.4.1.c.1", + "3.1.4.1.c.2", + "3.1.4.1.c.3", + "3.1.4.2", + "3.1.4.2.a", + "3.1.4.2.b", + "3.1.4.2.c", + "3.1.4.2.c.1", + "3.1.4.2.c.2", + "3.1.4.2.c.3", + "3.1.4.2.c.4", + "3.1.4.2.c.5", + "3.1.4.2.c.6", + "3.1.4.3", + "3.1.4.3.a", + "3.1.4.3.b", + "3.1.4.3.c", + "3.1.4.5", + "3.1.4.5.a" + ], + "emea-esp-decree-311-2022": [ + "Article 11(2)", + "Article 13(3)" + ], "emea-gbr-caf-4-0": [ "A1.b" ], @@ -5195,14 +5418,19 @@ "1101", "1103" ], - "apac-aus-ps-cps-230-2023": [ - "21" + "apac-aus-ps-cps-234-2019": [ + "14" ], "apac-ind-sebi-2024": [ "GV.RR.S1", "GV.RR.S2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6", + "10.35", + "11.8" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21", "HHSP27", "HML21", @@ -5212,11 +5440,23 @@ "HSUP19", "HSUP23" ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(c)", + "3.1.8", + "3.1.8(a)", + "3.1.8(b)", + "3.1.8(c)", + "3.1.8(d)", + "3.1.8(e)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1", "1.1.1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } }, @@ -5242,7 +5482,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish an authoritative chain of command with clear lines of communication to remove ambiguity from individuals and teams related to managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish an authoritative chain of command with clear lines of communication to remove ambiguity from individuals and teams related to managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5322,10 +5562,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1" @@ -5397,13 +5637,11 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.4(b)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" ], - "emea-deu-bsrit-2017": [ - "4.5", - "4.6", - "4.10" + "emea-sau-ecc-1-2018": [ + "1-4-1" ], "emea-gbr-caf-4-0": [ "A1.b" @@ -5417,19 +5655,28 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1103" ], - "apac-aus-ps-cps-230-2023": [ - "21" + "apac-aus-ps-cps-234-2019": [ + "14" ], "apac-ind-sebi-2024": [ "GV.OC.S1", "GV.PO.S5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "11.8" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21" ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(c)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } }, @@ -5453,11 +5700,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Basic metrics are developed to provide operational oversight of a limited scope of cybersecurity and data protection controls.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -5503,10 +5750,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.1-POF3", @@ -5630,6 +5877,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-800-207": [ "NIST Tenet 7" ], @@ -5642,9 +5892,6 @@ "GV.SC-09", "ID.IM-03" ], - "general-scf-dpmp-2025": [ - "11.5" - ], "general-tisax-6-0-3": [ "1.2.1" ], @@ -5695,6 +5942,9 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-06" ], + "emea-eu-eba-ict-srm-2025": [ + "3.5.51" + ], "emea-eu-dora-2023": [ "Article 13.4" ], @@ -5704,19 +5954,28 @@ "emea-eu-nis2-annex-2024": [ "1.1.1(j)" ], - "emea-us-psd2-2015": [ - "3" + "emea-deu-bsrit-2017": [ + "2.5", + "4.9" ], "emea-deu-c5-2020": [ - "COM-04" + "OIS-01-BP2" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 5", + "Appendix D" ], "emea-sau-cgiot-2024": [ "1-1-4" ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.2 [OP.MON.2]" + "emea-sau-otcc-1-2022": [ + "1-4-2", + "1-7-2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0724" ], "apac-ind-sebi-2024": [ @@ -5727,7 +5986,10 @@ "apac-jpn-ismap": [ "4.6.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP46", "HML46" ], @@ -5735,14 +5997,7 @@ "HSUP38" ], "apac-sgp-mas-trm-2021": [ - "4.5.3", - "7.8.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.9" + "4.5.3" ], "americas-can-osfi-b13-2022": [ "1", @@ -5772,11 +6027,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -5819,10 +6074,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", @@ -5879,9 +6134,9 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to observed trends.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -5927,10 +6182,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", @@ -5956,6 +6211,12 @@ ], "general-nist-csf-2-0": [ "GV.RM-01" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } }, @@ -5979,9 +6240,9 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity personnel identify and maintain contact information for local and national law enforcement (e.g., FBI field office) in case of cybersecurity incidents that require law enforcement involvement.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -6030,9 +6291,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF4", @@ -6136,7 +6398,7 @@ "IR-06" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 31.4" @@ -6144,29 +6406,6 @@ "emea-deu-c5-2020": [ "OIS-05" ], - "emea-esp-boe-a-2022-7191": [ - "Article 32.1", - "Article 32.2", - "Article 32.3" - ], - "emea-esp-decree-311-2022": [ - "32.1", - "32.2", - "32.3" - ], - "apac-aus-ps-cps-230-2023": [ - "33", - "42", - "51", - "59(a)", - "59(b)" - ], - "apac-aus-ps-cps-234-2019": [ - "35", - "35(a)", - "35(b)", - "36" - ], "apac-jpn-ismap": [ "6.1.3", "6.1.3.1", @@ -6194,11 +6433,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Cybersecurity and data privacy personnel identify and maintain contact information for local, regional and national cybersecurity / data privacy groups and associations.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.\n", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -6263,10 +6502,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF4", @@ -6384,8 +6623,8 @@ "6.1.4.5", "6.1.4.6" ], - "amaericas-can-osfi-self-assessment": [ - "3.7" + "americas-can-osfi-self-assessment-2": [ + "3.1.5" ] } }, @@ -6394,7 +6633,7 @@ "title": "Defining Business Context & Mission", "family": "GOV", "description": "Mechanisms exist to define the context of its business model and document the organization's mission.", - "scf_question": "Does the organization define the context of its business model and document the mission of the organization?", + "scf_question": "Does the organization define the context of its business model and document its mission?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -6409,9 +6648,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ The context of the entity's business model and its mission are documented.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ The context of the entity's business model and its mission are documented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6482,9 +6721,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2-POF1", @@ -6552,9 +6792,6 @@ "GV.OV-01", "GV.SC-03" ], - "general-scf-dpmp-2025": [ - "11.1" - ], "general-shared-assessments-sig-2025": [ "B.1" ], @@ -6568,20 +6805,27 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(4)" + "3.2.1.4", + "3.2.2.5" ], "emea-eu-nis2-annex-2024": [ "1.1.1(b)" ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], "emea-sau-ecc-1-2018": [ "1-1-1" ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(a)" + ], "americas-can-osfi-b13-2022": [ "1.2", "2.1.1" @@ -6593,7 +6837,7 @@ "title": "Define Control Objectives", "family": "GOV", "description": "Mechanisms exist to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", - "scf_question": "Does the organization establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system?", + "scf_question": "Does the organization establish control objectives as the basis for the selection, implementation and management of its internal security, compliance and resilience control system?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -6610,7 +6854,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6680,10 +6924,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF1", @@ -6761,25 +7005,23 @@ "314.3(b)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.2.1(5)(c)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "emea-eu-nis2-annex-2024": [ "1.1.1(c)" ], "emea-deu-c5-2020": [ "OIS-01", - "OIS-02" + "OIS-02", + "DLL-01-BP1" ], - "emea-sau-cscc-1-2019": [ - "1-1" + "apac-aus-ps-cps-230-2023": [ + "29" ], "apac-ind-sebi-2024": [ "GV.OC.S1", @@ -6799,8 +7041,8 @@ "control_id": "GOV-10", "title": "Data Governance", "family": "GOV", - "description": "Mechanisms exist to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization facilitate data governance to oversee its policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive and/or regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization facilitate data governance to oversee its policies, standards and procedures so that sensitive and/or regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -6815,7 +7057,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Administrative processes require all employees and contractors to apply cybersecurity and data protection principles in their daily work (e.g., policies & standards).\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6888,9 +7130,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2-POF1" @@ -6937,9 +7180,6 @@ "general-pci-dss-4-0-1": [ "A3.2.5" ], - "general-scf-dpmp-2025": [ - "5.9" - ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -6962,15 +7202,117 @@ "PM-23", "PM-24" ], - "apac-chn-pipl-2021": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.2" + ], + "apac-nzl-ism-3-9": [ + "20.2.16.C.03" + ], + "americas-bmu-mba-coc-2020": [ + "5.3-BP2" ] } }, + { + "control_id": "GOV-10.1", + "title": "Data Catalog", + "family": "GOV", + "description": "Mechanisms exist to identify and catalog the organization's data holdings in a structured format to document each significant data asset.", + "scf_question": "Does the organization identify and catalog its data holdings in a structured format to document each significant data asset?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and catalog the organization's data holdings in a structured format to document each significant data asset.", + "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Spreadsheet-based data inventory\n∙ Manual data catalog template", + "small": "∙ Spreadsheet data catalog with sensitivity classifications\n∙ Data classification register for significant data assets", + "medium": "∙ Data catalog platform (e.g., Collibra, Alation)\n∙ Structured data inventory with metadata\n∙ Microsoft Purview basic tier (https://microsoft.com)", + "large": "∙ Enterprise data catalog (e.g., Collibra (https://collibra.com), Alation (https://alation.com))\n∙ Data lineage tracking\n∙ Microsoft Purview (https://microsoft.com)", + "enterprise": "∙ Enterprise data catalog with automated discovery\n∙ Microsoft Purview or equivalent (https://microsoft.com)\n∙ Automated data lineage and classification at scale" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": {} + }, { "control_id": "GOV-11", "title": "Purpose Validation", @@ -6989,9 +7331,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to monitor mission/business-critical Technology Assets, Applications and/or Services (TAAS) to ensure those resources are being used consistent with their intended purpose.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to monitor mission/business-critical Technology Assets, Applications and/or Services (TAAS) to ensure those resources are being used consistent with their intended purpose.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7056,9 +7398,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-42001-2023": [ "6.2" @@ -7096,8 +7439,8 @@ "control_id": "GOV-12", "title": "Forced Technology Transfer (FTT)", "family": "GOV", - "description": "Mechanisms exist to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", - "scf_question": "Does the organization avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices?", + "description": "Mechanisms exist to avoid and/or constrain the forced exfiltration of sensitive and/or regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", + "scf_question": "Does the organization avoid and/or constrain the forced exfiltration of sensitive and/or regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7110,9 +7453,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7176,38 +7519,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "apac-chn-cybersecurity-law-2017": [ "Article 28" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" - ], - "apac-chn-pipl-2021": [ - "38", - "38(4)", - "40" + "Article 28" ] } }, @@ -7229,9 +7550,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to constrain the host government's ability to leverage the organization's Technology Assets, Applications and/or Services (TAAS) for economic or political espionage and/or cyberwarfare activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to constrain the host government's ability to leverage the organization's Technology Assets, Applications and/or Services (TAAS) for economic or political espionage and/or cyberwarfare activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7295,44 +7616,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "apac-chn-cybersecurity-law-2017": [ "Article 28" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "Article 27" ], "apac-chn-pipl-2021": [ - "11", - "12", - "38(4)", - "40", - "47(5)", - "60", - "63(3)", - "63(4)", - "64" + "Article 38" ] } }, @@ -7354,9 +7650,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to incorporate security, compliance and resilience principles into Business As Usual (BAU) practices through executive leadership involvement.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to incorporate security, compliance and resilience principles into Business As Usual (BAU) practices through executive leadership involvement.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7419,10 +7715,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.1-POF1", @@ -7471,8 +7767,17 @@ "usa-federal-law-ftc-act": [ "45(a)(1)" ], - "apac-aus-ps-cps-230-2023": [ - "24" + "emea-deu-c5-2020": [ + "SA-01-BP4" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], + "emea-sau-ecc-1-2018": [ + "1-9-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2001" ], "apac-ind-sebi-2024": [ "GV.RR.S1" @@ -7481,9 +7786,19 @@ "4.5.2.1", "7.2.1.8" ], + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.6", + "4.1.2" + ], "americas-can-osfi-b13-2022": [ "1.1.1", "3.2.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } }, @@ -7491,8 +7806,8 @@ "control_id": "GOV-15", "title": "Operationalizing Security, Compliance & Resilience Capabilities", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -7507,9 +7822,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7601,10 +7916,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "errata": "- wordsmithed", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF1", @@ -7677,14 +7993,13 @@ ], "general-nist-800-171-r3": [ "03.15.01.a", + "03.16.01", "03.17.01.a" ], "general-nist-800-171a-r3": [ - "A.03.16.01" - ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "A.03.15.01.a[03]", + "A.03.16.01", + "A.03.17.01.a[01]" ], "general-swift-cscf-2025": [ "2.4" @@ -7718,6 +8033,11 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.30" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)", + "101.625(d)(5)", + "101.650(c)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -7732,12 +8052,12 @@ "155.260(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.l" @@ -7769,6 +8089,10 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], @@ -7776,14 +8100,14 @@ "Article 17.2" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.4(22)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7", @@ -7811,70 +8135,64 @@ "6.7.1" ], "emea-deu-bsrit-2017": [ + "3.4", + "3.6", "5.1" ], - "emea-qat-pdppl-2020": [ - "8.3" + "emea-deu-c5-2020": [ + "UP-01-BP2" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1", + "2-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 5(a)", - "Article 5(b)", - "Article 5(c)", - "Article 5(d)", - "Article 5(e)", - "Article 5(f)", - "Article 5(g)", - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5", - "Article 28.1", - "Article 37" + "emea-sau-ecc-1-2018": [ + "1-3-2", + "1-9-2", + "1-10-2", + "2-1-2", + "2-1-4", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-2", + "2-14-2", + "2-15-2", + "3-1-2", + "4-2-2", + "5-1-2" ], "emea-esp-decree-311-2022": [ - "28.1", - "37", - "5", - "5(a)", - "5(b)", - "5(c)", - "5(d)", - "5(e)", - "5(f)", - "5(g)", - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" + "Article 13(2)(d)", + "Article 15(1)" ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5" + "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1633", "ISM-1634", "ISM-1635", "ISM-1636" ], "apac-aus-ps-cps-230-2023": [ - "29" + "16(c)" + ], + "apac-aus-ps-cps-234-2019": [ + "21" ], "apac-ind-sebi-2024": [ "GV.RM.S2" @@ -7883,7 +8201,10 @@ "4.4.4.1", "4.5.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP16", "HHSP28", @@ -7899,13 +8220,24 @@ "3.2.10.C.04", "3.4.11.C.01" ], + "apac-sgp-mas-trm-2021": [ + "4.1.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.3-BP2", + "5.11-BP4" + ], "americas-can-osfi-b13-2022": [ "1.1.1", "2.1.1", "3.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", + "03.16.01", "03.17.01.A" ] } @@ -7914,8 +8246,8 @@ "control_id": "GOV-15.1", "title": "Select Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7928,9 +8260,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8006,10 +8338,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" @@ -8041,9 +8374,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "1.2.1", @@ -8073,6 +8406,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -8083,10 +8419,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.l" @@ -8110,19 +8446,22 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.4(22)", - "3.3.4(23)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -8144,53 +8483,37 @@ "Article 21.2(j)" ], "emea-deu-bsrit-2017": [ + "3.4", + "3.6", "5.1" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1" + "emea-deu-c5-2020": [ + "DLL-01-BP1" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.3", - "Article 28.1(a)", - "Article 28.1(b)", - "Article 28.1(c)", - "Article 28.2", - "Article 28.3", - "Article 37" - ], "emea-esp-decree-311-2022": [ - "28.1(a)", - "28.1(b)", - "28.1(c)", - "28.2", - "28.3", - "3.3", - "37" + "Article 28(2)" ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5", - "A6" + "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1634" ], - "apac-aus-ps-cps-230-2023": [ - "29" + "apac-aus-ps-cps-234-2019": [ + "21", + "21(a)", + "21(b)", + "21(c)", + "21(d)" ], "apac-jpn-ismap": [ "4.4.4.1" @@ -8202,6 +8525,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -8212,8 +8538,8 @@ "control_id": "GOV-15.2", "title": "Implement Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8226,9 +8552,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8319,10 +8645,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" @@ -8356,9 +8683,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1", @@ -8373,6 +8700,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -8383,14 +8713,14 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -8408,6 +8738,10 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], @@ -8415,13 +8749,13 @@ "Article 17.1(e)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -8443,42 +8777,22 @@ "Article 21.2(j)" ], "emea-deu-bsrit-2017": [ + "3.4", "5.2" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.3", - "11.5", - "11.6" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.3", - "Article 37" - ], - "emea-esp-decree-311-2022": [ - "3.3", - "37" - ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5", - "A6", "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1635" ], "apac-nzl-ism-3-9": [ @@ -8488,6 +8802,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -8498,8 +8815,8 @@ "control_id": "GOV-15.3", "title": "Assess Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", - "scf_question": "Does the organization compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended?", + "description": "Mechanisms exist to compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", + "scf_question": "Does the organization compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8512,9 +8829,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8604,10 +8921,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC4.2-POF1" @@ -8632,9 +8950,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1" @@ -8651,6 +8969,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -8661,10 +8982,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -8680,52 +9001,28 @@ "899-bb.2(b)(ii)(B)", "899-bb.2(b)(ii)(B)(4)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" - ], "emea-eu-dora-2023": [ "Article 7(a)", "Article 7(b)", "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1", - "11.2" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-gbr-cap-1850-2020": [ - "A5", - "A6", - "B4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1636" ], "americas-can-osfi-b13-2022": [ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -8750,9 +9047,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to obtain authorization for the production use of each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to obtain authorization for the production use of each Technology Asset, Application and/or Service (TAAS) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8842,9 +9139,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-22301-2019": [ "8.1" @@ -8862,9 +9160,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1" @@ -8885,10 +9183,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -8912,21 +9210,13 @@ "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-gbr-cap-1850-2020": [ - "A5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0027" ], "apac-nzl-ism-3-9": [ @@ -8937,6 +9227,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -8961,9 +9254,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to monitor Technology Assets, Applications, Services and/or Data (TAASD) under their control on an ongoing basis for applicable threats and risks, as well as to ensure security, compliance and resilience controls are operating as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to monitor Technology Assets, Applications, Services and/or Data (TAASD) under their control on an ongoing basis for applicable threats and risks, as well as to ensure security, compliance and resilience controls are operating as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9053,10 +9346,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-27001-2022": [ "9.2.2" @@ -9077,9 +9370,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "usa-federal-dow-dfars-252-204-7012": [ "252.204-7012(b)" @@ -9094,10 +9387,10 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -9122,31 +9415,15 @@ "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.7", - "11.8" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-gbr-cap-1850-2020": [ - "A5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1526" ], - "apac-aus-ps-cps-230-2023": [ - "30" - ], "apac-nzl-ism-3-9": [ "23.2.18.C.01" ], @@ -9154,6 +9431,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -9180,9 +9460,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define materiality threshold criteria capable of designating an incident as material.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define materiality threshold criteria capable of designating an incident as material.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9219,9 +9499,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC3.1-POF6" @@ -9252,6 +9533,12 @@ "500.4(b)(5)", "500.9(b)(1)", "500.9(b)(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.3" ] } }, @@ -9275,9 +9562,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a risk as a material risk.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a risk as a material risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9311,9 +9598,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-csa-iot-2": [ "RSM-01" @@ -9345,6 +9633,9 @@ "500.4(b)(5)", "500.9(b)(1)", "500.9(b)(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2" ] } }, @@ -9368,9 +9659,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a threat as a material threat.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a threat as a material threat.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9404,9 +9695,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-csa-iot-2": [ "RSM-01" @@ -9437,7 +9729,7 @@ "title": "Security, Compliance & Resilience Status Reporting", "family": "GOV", "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.", - "scf_question": "Does the organization submit status reporting of the organization's security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required?", + "scf_question": "Does the organization submit status reporting of its security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -9452,9 +9744,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9497,10 +9789,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC3.1-POF10", @@ -9514,6 +9806,17 @@ "52.204-25(d)(2)(ii)", "52.204-25(d)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(12)", + "101.625(d)(13)", + "101.630(d)", + "101.630(e)(2)", + "101.630(e)(2)(ii)", + "101.630(e)(3)", + "101.630(e)(4)", + "101.630(f)(3)", + "101.630(f)(5)" + ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(b)", "17 CFR 229.106(d)" @@ -9577,18 +9880,56 @@ "usa-state-va-cdpa-2023": [ "59.1-580.C" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(23)", + "Article 19(8)", + "Article 20(6)" + ], "emea-eu-nis2-annex-2024": [ "1.2.3" ], - "apac-aus-ism-2024-june": [ + "emea-eu-psd2-2015": [ + "96(6)" + ], + "emea-deu-fdpa-2017": [ + "3.5.79(3)" + ], + "emea-grc-pirppd-1997": [ + "B.7.7", + "B.8.2" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(3)" + ], + "emea-ken-pda-2019": [ + "IV.31(5)" + ], + "emea-nga-dpr-2019": [ + "4.1(6)", + "4.1(7)" + ], + "apac-aus-ism-2026-march": [ "ISM-1587" ], + "apac-aus-ps-cps-230-2023": [ + "59", + "59(a)", + "59(b)" + ], "apac-chn-cybersecurity-law-2017": [ "Article 38", "Article 54(1)" ], + "apac-jpn-appi-2020": [ + "IV.5.53(2)" + ], "apac-jpn-ismap": [ "4.5.3.1" + ], + "apac-mys-bnm-rmit-2025": [ + "16.1", + "17.2", + "17.5" ] } }, @@ -9612,7 +9953,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Unstructured review of the cybersecurity and/or data privacy program is performed on an annual basis.\n▪ Administrative processes require all employees and contractors to apply cybersecurity and data protection principles in their daily work (e.g., policies & standards).", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to govern a Quality Management System (QMS) to ensure security, compliance and resilience processes conform with applicable statutory, regulatory and/or contractual obligations.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to govern a Quality Management System (QMS) to ensure security, compliance and resilience processes conform with applicable statutory, regulatory and/or contractual obligations.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9685,10 +10026,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-cobit-2019": [ "APO11.01", @@ -9705,6 +10046,10 @@ "emea-eu-ai-act-2024": [ "Article 16(c)", "Article 17.1" + ], + "apac-sgp-mas-trm-2021": [ + "5.8.1", + "5.8.2" ] } }, @@ -9728,7 +10073,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define the basis for confidence that implemented practices conform to applicable security, compliance and resilience controls, where the control implementation performs as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define the basis for confidence that implemented practices conform to applicable security, compliance and resilience controls, where the control implementation performs as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9783,10 +10128,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "emea-gbr-caf-4-0": [ "A2.c" @@ -9813,7 +10158,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assurance Levels (AL) for assessment activities to standardize the following assurance attributes:\n(1) Depth that addresses the rigor and level of detail of the assessment; and\n(2) Coverage that addresses the scope and breadth of the assessment.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assurance Levels (AL) for assessment activities to standardize the following assurance attributes:\n(1) Depth that addresses the rigor and level of detail of the assessment; and\n(2) Coverage that addresses the scope and breadth of the assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9867,9 +10212,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} }, { @@ -9892,7 +10238,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assessment Objectives (AO) to assess the implementation of requirements, when available.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assessment Objectives (AO) to assess the implementation of requirements, when available.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9946,9 +10292,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "usa-federal-dow-cert-rmm-1-2": [ "ADM:GG2.GP9", @@ -9981,6 +10328,127 @@ ] } }, + { + "control_id": "GOV-19.3", + "title": "Security, Compliance & Resilince Outsourcing Limitations", + "family": "GOV", + "description": "Mechanisms exist to ensure organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations.", + "scf_question": "Does the organization ensure third-parties involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to ensure organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Vendor due diligence checklist\n∙ Third-party security questionnaire (e.g., CAIQ, SIG)", + "small": "∙ Vendor security questionnaire (CAIQ or SIG)\n∙ Third-party risk assessment prior to outsourcing", + "medium": "∙ Third-party risk management program\n∙ Vendor security assessments with contractual security obligations\n∙ Contract security requirements for outsourced functions", + "large": "∙ Third-party risk management (TPRM) program\n∙ Vendor SOC 2 and ISO 27001 certification requirements\n∙ Contractual security and compliance obligations", + "enterprise": "∙ Enterprise TPRM program with automated vendor risk assessment\n∙ Third-party risk ratings (e.g., BitSight, SecurityScorecard)\n∙ Contractual oversight and audit rights for outsourced functions" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-14", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "emea-sau-sama-csf-1-2017": [ + "3.4.2.3", + "3.4.2.3.a", + "3.4.2.3.b", + "3.4.2.3.c" + ], + "emea-esp-decree-311-2022": [ + "Article 14(1)", + "Article 16(2)" + ] + } + }, { "control_id": "GOV-20", "title": "Mergers, Acquisitions & Divestitures (MA&D)", @@ -10001,7 +10469,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10055,9 +10523,10 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} }, { @@ -10080,7 +10549,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provision a Virtual Data Room (VDR), or similar technology, to securely share documentation among stakeholders to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provision a Virtual Data Room (VDR), or similar technology, to securely share documentation among stakeholders to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10137,11 +10606,112 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} }, + { + "control_id": "GOV-21", + "title": "High Value Assets (HVAs)", + "family": "GOV", + "description": "Mechanisms exist to identify and catalog the organization's High Value Assets (HVAs) (e.g., crown jewels), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA;\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a HVA based on business process criticality or dependency relationships;\n(3) Location of HVA Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements.", + "scf_question": "Does the organization identify and catalog its High Value Assets (HVAs) (e.g., crown jewels), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA;\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a HVA based on business process criticality or dependency relationships;\n(3) Location of HVA Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and catalog the organization's High Value Assets (HVAs), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA (e.g., \"crown jewel\" IP);\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a \"crown jewel,\" based on business process criticality or dependency relationships;\n(3) Location of \"crown jewel\" Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Manual identification of most critical business assets\n∙ HVA asset register (spreadsheet)", + "small": "∙ HVA asset register with basic protection requirements\n∙ Critical asset identification by business process dependency", + "medium": "∙ HVA identification process\n∙ Critical asset register with minimum protection requirements\n∙ Risk-based prioritization of HVA assets", + "large": "∙ Formal HVA identification program\n∙ Critical asset protection requirements matrix\n∙ Regular HVA review cycle", + "enterprise": "∙ Enterprise HVA program with board-level visibility\n∙ Integrated critical asset protection within GRC platform\n∙ Threat modeling centered on HVA assets" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-GV-1" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2005" + ] + } + }, { "control_id": "AAT-01", "title": "Artificial Intelligence (AI) & Autonomous Technologies Governance", @@ -10251,7 +10821,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10326,6 +10897,10 @@ ], "emea-eu-ai-act-2024": [ "Article 17.1(c)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2072", + "ISM-2074" ] } }, @@ -10415,7 +10990,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10543,7 +11119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10580,7 +11157,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to sustain the value of deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10659,7 +11236,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10775,47 +11353,45 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} }, { - "control_id": "AAT-02", - "title": "Situational Awareness of AI & Autonomous Technologies", + "control_id": "AAT-01.5", + "title": "Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization", "family": "AAT", - "description": "Mechanisms exist to develop and maintain an inventory of Artificial Intelligence (AI) and Autonomous Technologies (AAT) (internal and third-party).", - "scf_question": "Does the organization develop and maintain an inventory of Artificial Intelligence (AI) and Autonomous Technologies (AAT) (internal and third-party)?", - "relative_weight": 9, + "description": "Mechanisms exist to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements.", + "scf_question": "Does the organization assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements?", + "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", "nist_csf_function": "Identify", "scrm_focus": { - "strategic": true, + "strategic": false, "operational": true, "tactical": true }, "maturity": { "0": "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.", - "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", - "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to develop and maintain an inventory of AAT (internal and third-party).", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "SCRMS", - "CORE AI-Enabled Operations", - "CORE AI Model Deployment", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "Community Derived" ], "possible_solutions": { - "micro_small": "∙ AI system inventory (spreadsheet listing all AI tools in use)\n∙ AI governance program\n∙ Employee AI usage disclosure process", - "small": "∙ AI system inventory with risk classification\n∙ AI governance program\n∙ AI use monitoring policy and procedure", - "medium": "∙ Formal AI system inventory and registry\n∙ AI governance program\n∙ NIST AI RMF Map function implementation\n∙ AI shadow use detection and disclosure process", - "large": "∙ AI system registry integrated with IT asset management\n∙ AI governance program with situational awareness capability\n∙ AI risk monitoring and anomaly detection\n∙ NIST AI RMF Map and Govern functions", - "enterprise": "∙ Enterprise AI system registry with real-time inventory\n∙ AI governance platform with situational awareness dashboard\n∙ Automated AI discovery and shadow AI detection\n∙ NIST AI RMF full implementation" + "micro_small": "∙ AI system inventory with basic use-case categorization\n∙ NIST AI RMF categorization guidance.\n∙ Designated responsible party for AI tools in use", + "small": "∙ AI system inventory with risk-based categorization\n∙ NIST AI RMF categorization guidance\n∙ EU AI Act risk tier mapping.", + "medium": "∙ Formal AI system categorization process\n∙ EU AI Act risk tier mapping\n∙ NIST AI RMF implementation\n∙ AI risk register with categorization metadata", + "large": "∙ Formal AI governance program with defined categorization criteria\n∙ EU AI Act compliance mapping\n∙ NIST AI RMF full implementation\n∙ AI Risk Management Committee-approved categorization", + "enterprise": "∙ Enterprise AI categorization program with automated registry\n∙ EU AI Act and ISO/IEC 42001 alignment\n∙ Board-level AI risk reporting by category" }, "risks": [ "R-AC-1", @@ -10848,6 +11424,8 @@ "R-IR-2", "R-IR-3", "R-IR-4", + "R-SA-1", + "R-SA-2", "R-SC-1", "R-SC-2", "R-SC-3", @@ -10878,40 +11456,21 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- new control - SCF community", "family_name": "Artificial Intelligence & Autonomous Technologies", - "crosswalks": { - "general-iso-42001-2023": [ - "8.2", - "A.4.4", - "A.4.5" - ], - "general-mpa-csbp-5-3-1": [ - "OR-5.0" - ], - "general-nist-100-1-ai-rmf": [ - "GOVERN 1.6" - ], - "general-nist-600-1-gen-ai-profile": [ - "GOVERN 1.6", - "GV-1.6-001", - "GV-1.6-002", - "MANAGE 3.1" - ], - "general-shared-assessments-sig-2025": [ - "R.5" - ] - } + "crosswalks": {} }, { - "control_id": "AAT-02.1", - "title": "AI & Autonomous Technologies Risk Mapping", + "control_id": "AAT-02", + "title": "Situational Awareness of AI & Autonomous Technologies", "family": "AAT", - "description": "Mechanisms exist to identify Artificial Intelligence (AI) and Autonomous Technologies (AAT) in use and map those components to potential legal risks, including statutory and regulatory compliance requirements.", - "scf_question": "Does the organization identify Artificial Intelligence (AI) and Autonomous Technologies (AAT) in use and map those components to potential legal risks, including statutory and regulatory compliance requirements?", + "description": "Mechanisms exist to develop and maintain an inventory of Artificial Intelligence (AI) and Autonomous Technologies (AAT) (internal and third-party).", + "scf_question": "Does the organization develop and maintain an inventory of Artificial Intelligence (AI) and Autonomous Technologies (AAT) (internal and third-party)?", "relative_weight": 9, - "conformity_cadence": "Quarterly", + "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", "nist_csf_function": "Identify", @@ -10923,21 +11482,23 @@ "maturity": { "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", - "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to identify AAT in use and map those components to potential legal risks, including statutory and regulatory compliance requirements.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to develop and maintain an inventory of AAT (internal and third-party).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ + "SCRMS", + "CORE AI-Enabled Operations", "CORE AI Model Deployment", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Basic AI risk assessment (documented risks per AI tool)\n∙ AI governance program\n∙ NIST AI RMF Map function reference", - "small": "∙ AI risk assessment for each deployed AI system\n∙ AI governance program\n∙ NIST AI RMF Map function implementation", - "medium": "∙ Formal AI risk mapping process aligned to NIST AI RMF\n∙ AI risk register maintained in GRC platform\n∙ MITRE ATLAS framework reference for adversarial AI risks", - "large": "∙ Enterprise AI risk mapping integrated with organizational risk register\n∙ NIST AI RMF Map function with quantified risk scores\n∙ MITRE ATLAS framework integration\n∙ AI risk dashboards for management reporting", - "enterprise": "∙ Enterprise AI risk mapping program integrated with GRC and ERM\n∙ NIST AI RMF Map function at enterprise scale\n∙ Automated AI risk scoring and continuous monitoring\n∙ MITRE ATLAS-based adversarial AI risk scenarios" + "micro_small": "∙ AI system inventory (spreadsheet listing all AI tools in use)\n∙ AI governance program\n∙ Employee AI usage disclosure process", + "small": "∙ AI system inventory with risk classification\n∙ AI governance program\n∙ AI use monitoring policy and procedure", + "medium": "∙ Formal AI system inventory and registry\n∙ AI governance program\n∙ NIST AI RMF Map function implementation\n∙ AI shadow use detection and disclosure process", + "large": "∙ AI system registry integrated with IT asset management\n∙ AI governance program with situational awareness capability\n∙ AI risk monitoring and anomaly detection\n∙ NIST AI RMF Map and Govern functions", + "enterprise": "∙ Enterprise AI system registry with real-time inventory\n∙ AI governance platform with situational awareness dashboard\n∙ Automated AI discovery and shadow AI detection\n∙ NIST AI RMF full implementation" }, "risks": [ "R-AC-1", @@ -11000,7 +11561,131 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ], + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "general-iso-42001-2023": [ + "8.2", + "A.4.4", + "A.4.5" + ], + "general-mpa-csbp-5-3-1": [ + "OR-5.0" + ], + "general-nist-100-1-ai-rmf": [ + "GOVERN 1.6" + ], + "general-nist-600-1-gen-ai-profile": [ + "GOVERN 1.6", + "GV-1.6-001", + "GV-1.6-002", + "MANAGE 3.1" + ], + "general-shared-assessments-sig-2025": [ + "R.5" + ] + } + }, + { + "control_id": "AAT-02.1", + "title": "AI & Autonomous Technologies Risk Mapping", + "family": "AAT", + "description": "Mechanisms exist to identify Artificial Intelligence (AI) and Autonomous Technologies (AAT) in use and map those components to potential legal risks, including statutory and regulatory compliance requirements.", + "scf_question": "Does the organization identify Artificial Intelligence (AI) and Autonomous Technologies (AAT) in use and map those components to potential legal risks, including statutory and regulatory compliance requirements?", + "relative_weight": 9, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to identify AAT in use and map those components to potential legal risks, including statutory and regulatory compliance requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE AI Model Deployment", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Basic AI risk assessment (documented risks per AI tool)\n∙ AI governance program\n∙ NIST AI RMF Map function reference", + "small": "∙ AI risk assessment for each deployed AI system\n∙ AI governance program\n∙ NIST AI RMF Map function implementation", + "medium": "∙ Formal AI risk mapping process aligned to NIST AI RMF\n∙ AI risk register maintained in GRC platform\n∙ MITRE ATLAS framework reference for adversarial AI risks", + "large": "∙ Enterprise AI risk mapping integrated with organizational risk register\n∙ NIST AI RMF Map function with quantified risk scores\n∙ MITRE ATLAS framework integration\n∙ AI risk dashboards for management reporting", + "enterprise": "∙ Enterprise AI risk mapping program integrated with GRC and ERM\n∙ NIST AI RMF Map function at enterprise scale\n∙ Automated AI risk scoring and continuous monitoring\n∙ MITRE ATLAS-based adversarial AI risk scenarios" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11125,9 +11810,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-iso-42001-2023": [ @@ -11161,7 +11846,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT include reasonable security, compliance and resilience protections that are commensurate with assessed risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11240,9 +11925,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-600-1-gen-ai-profile": [ @@ -11352,7 +12037,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11457,7 +12143,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11481,6 +12168,9 @@ ], "emea-eu-ai-act-2024": [ "Article 8.1" + ], + "apac-aus-ism-2026-march": [ + "ISM-2084" ] } }, @@ -11502,7 +12192,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to define and document the organization's mission and defined goals for AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11580,7 +12270,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11698,7 +12389,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -11788,7 +12480,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11912,7 +12605,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12019,7 +12713,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12134,7 +12829,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12231,7 +12927,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12341,7 +13038,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12450,7 +13148,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12566,7 +13265,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12714,7 +13414,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12840,7 +13541,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12973,7 +13675,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13089,7 +13792,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13216,7 +13920,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13251,8 +13956,8 @@ "control_id": "AAT-09.1", "title": "AI & Autonomous Technologies High Risk Designations", "family": "AAT", - "description": "Mechanisms exist to designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", - "scf_question": "Does the organization designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making?", + "description": "Mechanisms exist to designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one (1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", + "scf_question": "Does the organization designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one (1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making?", "relative_weight": 7, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -13265,7 +13970,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to designate AAT \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13345,7 +14050,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13360,6 +14066,9 @@ "Article 51.1", "Article 51.1(a)", "Article 51.2" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(1)" ] } }, @@ -13384,7 +14093,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices to enable AAT-related security, resilience and compliance-related conformity testing throughout the lifecycle of the AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13464,7 +14173,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13553,7 +14263,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate AAT for trustworthy behavior and operation including security, anonymization and disaggregation of captured and stored data for approved purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13632,7 +14342,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13673,7 +14384,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to document test sets, metrics and details about the tools used during Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13751,7 +14462,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13782,7 +14494,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to demonstrate the AAT to be deployed are:\n(1) Valid;\n(2) Reliable; and\n(3) Operate as intended, based on approved designs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13860,7 +14572,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13893,7 +14606,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to demonstrate the AAT to be deployed are safe, residual risk does not exceed the organization's risk tolerance and can fail safely, particularly if made to operate beyond its knowledge limits.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13971,7 +14684,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14007,7 +14721,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the security and resilience of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14085,7 +14799,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14119,7 +14834,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine risks associated with transparency and accountability of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14183,7 +14898,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14214,7 +14930,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine the data privacy risk of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14278,7 +14994,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14308,7 +15025,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine fairness and bias of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14372,7 +15089,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14417,7 +15135,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate the AAT model.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14495,7 +15213,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14526,7 +15245,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the results of Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) to determine the viability of the proposed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14587,7 +15306,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14618,7 +15338,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the effectiveness of the processes utilized to perform Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14696,7 +15416,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14726,7 +15447,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate AAT-related performance or the assurance criteria demonstrated for conditions similar to deployment settings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14804,7 +15525,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14835,7 +15557,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to proactively and continuously monitor deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14914,7 +15636,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -14957,7 +15680,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to integrate continual improvements for deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15018,7 +15741,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -15051,7 +15775,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to report the status and results of Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) to relevant stakeholders, including governing bodies, as required.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15129,7 +15853,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -15161,7 +15886,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate claims of AAT model capabilities using empirically validated methods.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15239,7 +15964,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -15254,7 +15980,7 @@ "title": "AI TEVV Benchmarking Content Provenance", "family": "AAT", "description": "Mechanisms exist to benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry-recognized standards.", - "scf_question": "Does the organization benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry -recognized standards?", + "scf_question": "Does the organization benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry-recognized standards?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -15267,7 +15993,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to benchmark the verifiable lineage and origin of content used by AAT according to industry-recognized standards.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15345,7 +16071,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -15376,7 +16103,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to mitigate concerns of model collapse by:\n(1) Assessing the proportion of synthetic to non-synthetic training data; and\n(2) Verifying training data is not overly homogenous or AAT system-produced.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15454,7 +16181,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -15561,7 +16289,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15664,7 +16393,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -15814,7 +16544,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -15934,7 +16665,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -16057,7 +16789,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -16105,7 +16838,7 @@ "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to communicate AAT-related incidents and/or errors to relevant stakeholders, including affected communities.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to communicate AAT-related incidents and/or errors to relevant stakeholders, including affected communities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -16181,7 +16914,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -16287,7 +17021,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -16413,7 +17148,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -16455,6 +17191,10 @@ ], "emea-eu-ai-act-2024": [ "Article 17.1(f)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2086", + "ISM-2087" ] } }, @@ -16551,7 +17291,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -16673,7 +17414,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -16783,7 +17525,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -16794,149 +17537,36 @@ } }, { - "control_id": "AAT-13", - "title": "AI & Autonomous Technologies Stakeholder Diversity", + "control_id": "AAT-12.5", + "title": "Training Data Source & Integrity", "family": "AAT", - "description": "Mechanisms exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise.", - "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise?", - "relative_weight": 8, + "description": "Mechanisms exist to validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT).", + "scf_question": "Does the organization validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT)?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], - "pptdf": "People", - "nist_csf_function": "Identify", + "pptdf": "Process", + "nist_csf_function": "Protect", "scrm_focus": { "strategic": false, "operational": true, - "tactical": false - }, - "maturity": { - "0": "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.", - "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", - "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "CORE AI Model Deployment" - ], - "possible_solutions": { - "micro_small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "medium": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "large": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "enterprise": "∙ Artificial Intelligence (AI) / autonomous technologies governance program" - }, - "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-BC-5", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-GV-8", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", - "NT-7", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-23", - "MT-24", - "MT-25", - "MT-27" - ], - "family_name": "Artificial Intelligence & Autonomous Technologies", - "crosswalks": { - "general-aicpa-tsc-2017": [ - "CC1.4-POF3" - ], - "general-iso-42001-2023": [ - "A.4.6" - ], - "general-nist-100-1-ai-rmf": [ - "MAP 1.2" - ] - } - }, - { - "control_id": "AAT-13.1", - "title": "AI & Autonomous Technologies Stakeholder Competencies", - "family": "AAT", - "description": "Mechanisms exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related operator and practitioner proficiency requirements for Artificial Intelligence (AI) and Autonomous Technologies (AAT) are defined, assessed and documented.", - "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related operator and practitioner proficiency requirements for Artificial Intelligence (AI) and Autonomous Technologies (AAT) are defined, assessed and documented?", - "relative_weight": 9, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "People", - "nist_csf_function": "Govern", - "scrm_focus": { - "strategic": true, - "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT-related operator and practitioner proficiency requirements for AAT are defined, assessed and documented.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE AI Model Deployment" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "medium": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "large": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "enterprise": "∙ Artificial Intelligence (AI) / autonomous technologies governance program" + "micro_small": "∙ Documented training data provenance\n∙ Basic data quality checks before model training\n∙ Vendor attestations for third-party training data", + "small": "∙ Training data source documentation\n∙ Vendor-supplied training data integrity attestations\n∙ Data quality validation before training", + "medium": "∙ Training data validation pipeline\n∙ Data provenance documentation\n∙ Data integrity checks (hash verification, data quality metrics)", + "large": "∙ Formal training data governance program\n∙ Automated data quality and integrity validation\n∙ Training data lineage tracking", + "enterprise": "∙ Enterprise AI data governance framework\n∙ Automated training data validation pipelines\n∙ Third-party training data audits\n∙ Data integrity monitoring throughout the AI lifecycle" }, "risks": [ "R-AC-1", @@ -17000,51 +17630,143 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- new control - SM-2088", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { - "general-aicpa-tsc-2017": [ - "CC1.4-POF2", - "CC5.3-POF5" - ], - "general-iso-42001-2023": [ - "5.1", - "7.2", - "A.4.6" - ], - "general-nist-100-1-ai-rmf": [ - "MAP 3.4" - ], - "general-shared-assessments-sig-2025": [ - "R.16" - ], - "emea-eu-ai-act-2024": [ - "Article 4" + "apac-aus-ism-2026-march": [ + "ISM-2088" ] } }, { - "control_id": "AAT-14", - "title": "AI & Autonomous Technologies Requirements Definitions", + "control_id": "AAT-12.6", + "title": "Prohibit Training", "family": "AAT", - "description": "Mechanisms exist to take socio-technical implications into account to address risks associated with Artificial Intelligence (AI) and Autonomous Technologies (AAT).", - "scf_question": "Does the organization take socio-technical implications into account to address risks associated with Artificial Intelligence (AI) and Autonomous Technologies (AAT)?", - "relative_weight": 8, + "description": "Mechanisms exist to prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "scf_question": "Does the organization prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s)?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", - "nist_csf_function": "Govern", + "nist_csf_function": "Protect", "scrm_focus": { - "strategic": true, + "strategic": false, "operational": true, "tactical": true }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Acceptable Use Policy (AUP) prohibiting unauthorized AI training\n∙ Contractual review of AI vendor terms of service", + "small": "∙ AI usage policy prohibiting unauthorized training\n∙ Employee acknowledgment of AI data use restrictions", + "medium": "∙ AI usage policy prohibiting unauthorized training on organizational data\n∙ Vendor contract reviews for training restrictions\n∙ Data Handling Agreements (DHA) with AI vendors", + "large": "∙ Formal AI data usage policy\n∙ Technical controls preventing data uploads to unauthorized AI systems\n∙ Data Loss Prevention (DLP) for AI training data", + "enterprise": "∙ Enterprise AI data governance policy\n∙ DLP controls restricting data to authorized AI platforms\n∙ Automated enforcement of training data restrictions\n∙ Regular audits of AI vendor training data handling" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2103", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2103" + ] + } + }, + { + "control_id": "AAT-13", + "title": "AI & Autonomous Technologies Stakeholder Diversity", + "family": "AAT", + "description": "Mechanisms exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise.", + "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "People", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, "maturity": { "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to take socio-technical implications into account to address risks associated with AAT.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT stakeholder competencies, skills and capacities incorporate demographic diversity, broad domain and user experience expertise.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -17120,48 +17842,43 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { + "general-aicpa-tsc-2017": [ + "CC1.4-POF3" + ], "general-iso-42001-2023": [ - "4.1", - "5.1", - "A.5.4", - "A.5.5", - "A.6.2.2", - "A.6.2.3" + "A.4.6" ], "general-nist-100-1-ai-rmf": [ - "MAP 1.6" - ], - "emea-eu-ai-act-2024": [ - "Article 11.1", - "Article 12.2(a)" + "MAP 1.2" ] } }, { - "control_id": "AAT-14.1", - "title": "AI & Autonomous Technologies Implementation Tasks Definition", + "control_id": "AAT-13.1", + "title": "AI & Autonomous Technologies Stakeholder Competencies", "family": "AAT", - "description": "Mechanisms exist to define the tasks that Artificial Intelligence (AI) and Autonomous Technologies (AAT) will support (e.g., classifiers, generative models, recommenders).", - "scf_question": "Does the organization define the tasks that Artificial Intelligence (AI) and Autonomous Technologies (AAT) will support (e.g., classifiers, generative models, recommenders)?", - "relative_weight": 8, + "description": "Mechanisms exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related operator and practitioner proficiency requirements for Artificial Intelligence (AI) and Autonomous Technologies (AAT) are defined, assessed and documented.", + "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT)-related operator and practitioner proficiency requirements for Artificial Intelligence (AI) and Autonomous Technologies (AAT) are defined, assessed and documented?", + "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], - "pptdf": "Process", + "pptdf": "People", "nist_csf_function": "Govern", "scrm_focus": { - "strategic": false, + "strategic": true, "operational": true, - "tactical": true + "tactical": false }, "maturity": { "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to define the tasks that AAT will support (e.g., classifiers, generative models, recommenders).", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT-related operator and practitioner proficiency requirements for AAT are defined, assessed and documented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -17237,34 +17954,42 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { + "general-aicpa-tsc-2017": [ + "CC1.4-POF2", + "CC5.3-POF5" + ], "general-iso-42001-2023": [ - "A.6.1.3", - "A.6.2.3", - "A.6.2.5" + "5.1", + "7.2", + "A.4.6" ], "general-nist-100-1-ai-rmf": [ - "MAP 2.1" + "MAP 3.4" ], - "general-nist-600-1-gen-ai-profile": [ - "MAP 2.1" + "general-shared-assessments-sig-2025": [ + "R.16" + ], + "emea-eu-ai-act-2024": [ + "Article 4" ] } }, { - "control_id": "AAT-14.2", - "title": "AI & Autonomous Technologies Knowledge Limits", + "control_id": "AAT-14", + "title": "AI & Autonomous Technologies Requirements Definitions", "family": "AAT", - "description": "Mechanisms exist to identify and document knowledge limits of Artificial Intelligence (AI) and Autonomous Technologies (AAT) to provide sufficient information to assist relevant stakeholder decision making.", - "scf_question": "Does the organization identify and document knowledge limits of Artificial Intelligence (AI) and Autonomous Technologies (AAT) to provide sufficient information to assist relevant stakeholder decision making?", - "relative_weight": 10, + "description": "Mechanisms exist to take socio-technical implications into account to address risks associated with Artificial Intelligence (AI) and Autonomous Technologies (AAT).", + "scf_question": "Does the organization take socio-technical implications into account to address risks associated with Artificial Intelligence (AI) and Autonomous Technologies (AAT)?", + "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", - "nist_csf_function": "Identify", + "nist_csf_function": "Govern", "scrm_focus": { "strategic": true, "operational": true, @@ -17273,8 +17998,8 @@ "maturity": { "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", - "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to identify and document knowledge limits of AAT to provide sufficient information to assist relevant stakeholder decision making.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to take socio-technical implications into account to address risks associated with AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -17350,56 +18075,61 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-iso-42001-2023": [ - "A.6.1.3", + "4.1", + "5.1", + "A.5.4", + "A.5.5", + "A.6.2.2", "A.6.2.3" ], "general-nist-100-1-ai-rmf": [ - "MAP 2.2" + "MAP 1.6" ], - "general-nist-600-1-gen-ai-profile": [ - "MAP 2.2" + "emea-eu-ai-act-2024": [ + "Article 11.1", + "Article 12.2(a)" ] } }, { - "control_id": "AAT-15", - "title": "AI & Autonomous Technologies Viability Decisions", + "control_id": "AAT-14.1", + "title": "AI & Autonomous Technologies Implementation Tasks Definition", "family": "AAT", - "description": "Mechanisms exist to define the criteria as to whether Artificial Intelligence (AI) and Autonomous Technologies (AAT) achieved intended purposes and stated objectives to determine whether its development or deployment should proceed.", - "scf_question": "Does the organization define the criteria as to whether Artificial Intelligence (AI) and Autonomous Technologies (AAT) achieved intended purposes and stated objectives to determine whether its development or deployment should proceed?", - "relative_weight": 10, + "description": "Mechanisms exist to define the tasks that Artificial Intelligence (AI) and Autonomous Technologies (AAT) will support (e.g., classifiers, generative models, recommenders).", + "scf_question": "Does the organization define the tasks that Artificial Intelligence (AI) and Autonomous Technologies (AAT) will support (e.g., classifiers, generative models, recommenders)?", + "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", - "nist_csf_function": "Protect", + "nist_csf_function": "Govern", "scrm_focus": { - "strategic": true, + "strategic": false, "operational": true, "tactical": true }, "maturity": { "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", - "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to define the criteria as to whether AAT achieved intended purposes and stated objectives to determine whether its development or deployment should proceed.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to define the tasks that AAT will support (e.g., classifiers, generative models, recommenders).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "CORE AI Model Deployment", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "CORE AI Model Deployment" ], "possible_solutions": { - "micro_small": "∙ Project team review\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "small": "∙ Project team review\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "medium": "∙ Project team review\n∙ Legal review\n∙ Steering committee\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "large": "∙ Legal review\n∙ Steering committee\n∙ Board of Directors (BoD)\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "enterprise": "∙ Legal review\n∙ Steering committee\n∙ Board of Directors (BoD)\n∙ Artificial Intelligence (AI) / autonomous technologies governance program" + "micro_small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "medium": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "large": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "enterprise": "∙ Artificial Intelligence (AI) / autonomous technologies governance program" }, "risks": [ "R-AC-1", @@ -17463,55 +18193,57 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-iso-42001-2023": [ - "5.1" + "A.6.1.3", + "A.6.2.3", + "A.6.2.5" ], "general-nist-100-1-ai-rmf": [ - "MANAGE 1.1" + "MAP 2.1" ], "general-nist-600-1-gen-ai-profile": [ - "GV-4.1-002" + "MAP 2.1" ] } }, { - "control_id": "AAT-15.1", - "title": "AI & Autonomous Technologies Negative Residual Risks", + "control_id": "AAT-14.2", + "title": "AI & Autonomous Technologies Knowledge Limits", "family": "AAT", - "description": "Mechanisms exist to identify and document negative, residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers and end users of Artificial Intelligence (AI) and Autonomous Technologies (AAT).", - "scf_question": "Does the organization identify and document negative, residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers and end users of Artificial Intelligence (AI) and Autonomous Technologies (AAT)?", - "relative_weight": 9, + "description": "Mechanisms exist to identify and document knowledge limits of Artificial Intelligence (AI) and Autonomous Technologies (AAT) to provide sufficient information to assist relevant stakeholder decision making.", + "scf_question": "Does the organization identify and document knowledge limits of Artificial Intelligence (AI) and Autonomous Technologies (AAT) to provide sufficient information to assist relevant stakeholder decision making?", + "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", - "nist_csf_function": "Protect", + "nist_csf_function": "Identify", "scrm_focus": { "strategic": true, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to identify and document negative, residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers and end users of AAT.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to identify and document knowledge limits of AAT to provide sufficient information to assist relevant stakeholder decision making.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "CORE AI Model Deployment", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "CORE AI Model Deployment" ], "possible_solutions": { - "micro_small": "∙ Project team review\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "small": "∙ Project team review\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "medium": "∙ Project team review\n∙ Legal review\n∙ Steering committee\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "large": "∙ Legal review\n∙ Steering committee\n∙ Board of Directors (BoD)\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", - "enterprise": "∙ Legal review\n∙ Steering committee\n∙ Board of Directors (BoD)\n∙ Artificial Intelligence (AI) / autonomous technologies governance program" + "micro_small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "small": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "medium": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "large": "∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "enterprise": "∙ Artificial Intelligence (AI) / autonomous technologies governance program" }, "risks": [ "R-AC-1", @@ -17575,7 +18307,235 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ], + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "general-iso-42001-2023": [ + "A.6.1.3", + "A.6.2.3" + ], + "general-nist-100-1-ai-rmf": [ + "MAP 2.2" + ], + "general-nist-600-1-gen-ai-profile": [ + "MAP 2.2" + ] + } + }, + { + "control_id": "AAT-15", + "title": "AI & Autonomous Technologies Viability Decisions", + "family": "AAT", + "description": "Mechanisms exist to define the criteria as to whether Artificial Intelligence (AI) and Autonomous Technologies (AAT) achieved intended purposes and stated objectives to determine whether its development or deployment should proceed.", + "scf_question": "Does the organization define the criteria as to whether Artificial Intelligence (AI) and Autonomous Technologies (AAT) achieved intended purposes and stated objectives to determine whether its development or deployment should proceed?", + "relative_weight": 10, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to define the criteria as to whether AAT achieved intended purposes and stated objectives to determine whether its development or deployment should proceed.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE AI Model Deployment", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Project team review\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "small": "∙ Project team review\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "medium": "∙ Project team review\n∙ Legal review\n∙ Steering committee\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "large": "∙ Legal review\n∙ Steering committee\n∙ Board of Directors (BoD)\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "enterprise": "∙ Legal review\n∙ Steering committee\n∙ Board of Directors (BoD)\n∙ Artificial Intelligence (AI) / autonomous technologies governance program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "general-iso-42001-2023": [ + "5.1" + ], + "general-nist-100-1-ai-rmf": [ + "MANAGE 1.1" + ], + "general-nist-600-1-gen-ai-profile": [ + "GV-4.1-002" + ] + } + }, + { + "control_id": "AAT-15.1", + "title": "AI & Autonomous Technologies Negative Residual Risks", + "family": "AAT", + "description": "Mechanisms exist to identify and document negative, residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers and end users of Artificial Intelligence (AI) and Autonomous Technologies (AAT).", + "scf_question": "Does the organization identify and document negative, residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers and end users of Artificial Intelligence (AI) and Autonomous Technologies (AAT)?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to identify and document negative, residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers and end users of AAT.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE AI Model Deployment", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Project team review\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "small": "∙ Project team review\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "medium": "∙ Project team review\n∙ Legal review\n∙ Steering committee\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "large": "∙ Legal review\n∙ Steering committee\n∙ Board of Directors (BoD)\n∙ Artificial Intelligence (AI) / autonomous technologies governance program", + "enterprise": "∙ Legal review\n∙ Steering committee\n∙ Board of Directors (BoD)\n∙ Artificial Intelligence (AI) / autonomous technologies governance program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -17692,7 +18652,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -17816,7 +18777,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -17943,7 +18905,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18048,9 +19011,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-100-1-ai-rmf": [ @@ -18161,7 +19124,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18275,7 +19239,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18384,7 +19349,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18499,7 +19465,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18605,7 +19572,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18713,7 +19681,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18830,7 +19799,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18867,7 +19837,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to perform an investigation when there is a serious incident involving operational AAT that documents a:\n(1) Root Cause Analysis (RCA);\n(2) Risk assessment of the incident; and \n(3) Description of corrective actions taken, including measures implemented to prevent a recurrence of the incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18946,7 +19916,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -18973,7 +19944,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to analyze anomalous AAT behavior and provide escalation paths for human oversight, including:\n(1) Real-time review; and\n(2) Intervention.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -19053,12 +20024,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-csa-iot-2": [ "SAP-10" + ], + "apac-aus-ism-2026-march": [ + "ISM-2089" ] } }, @@ -19080,7 +20055,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to require human review and clear escalation paths for approval for high-risk or ambiguous AAT actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -19160,7 +20135,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -19183,7 +20159,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and contain emergent or collusive behaviors among multiple AAT, including:\n(1) Automated or human-triggered containment; and \n(2) Formal investigation to determine the root cause of agentic cascades or collusion.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -19263,7 +20239,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -19364,7 +20341,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -19468,7 +20446,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -19482,6 +20461,9 @@ ], "emea-eu-ai-act-2024": [ "Article 14.2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2094" ] } }, @@ -19583,7 +20565,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -19696,7 +20679,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -19812,7 +20796,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -19936,7 +20921,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20041,9 +21027,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-600-1-gen-ai-profile": [ @@ -20149,7 +21135,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20182,7 +21169,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prioritize, respond to and remediate AAT-related risks based on assessments and other analytical output.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20262,7 +21249,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20309,7 +21297,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure deployed AAT conform to applicable statutory and regulatory requirements, based on:\n(1) Defined use cases;\n(2) Geographic markets; and\n(3) Use of Intellectual Property (IP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20389,7 +21377,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20420,7 +21409,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that utilize manipulative or deceptive techniques (including biased data) to impair an individual's ability to make a reasonably informed decision.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20499,7 +21488,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20526,7 +21516,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that exploit a human subject to materially affect a targeted behavior due to their:\n(1) Age;\n(2) Disability; or \n(3) Specific social or economic situation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20605,7 +21595,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20632,7 +21623,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that: \n(1) Evaluate human subjects over a certain period of time based on their social behavior or known, inferred or predicted personal or personality characteristics; and\n(2) Assign a \"social score\" branding or equivalent classification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20711,7 +21702,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20738,7 +21730,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that lead to the detrimental or unfavorable treatment of certain data subjects, or groups of data subjects, in social contexts that is:\n(1) Are unrelated to the contexts in which the data was originally generated or collected; and/or\n(2) Is unjustified or disproportionate to their social behavior or its gravity.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20817,7 +21809,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20845,7 +21838,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that:\n(1) Assess the risk of an individual committing a criminal offence; and\n(2) Predicts risk based solely on the profiling of personality traits and characteristics.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20924,7 +21917,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -20951,7 +21945,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that create, or expand, facial recognition databases through scraping facial images from:\n(1) The Internet; or \n(2) Closed-Circuit Television (CCTV) footage.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -21030,7 +22024,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -21057,7 +22052,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that infer human emotions of an individual based on observed characteristics.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -21136,7 +22131,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -21242,7 +22238,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -21259,7 +22256,7 @@ "title": "AI & Autonomous Technologies Development Practices", "family": "AAT", "description": "Measures exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals.", - "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness, and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals?", + "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -21276,7 +22273,7 @@ "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ Measures exist to ensure AAT are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals.", "4": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -21351,7 +22348,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -21465,7 +22463,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -21581,7 +22580,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -21632,7 +22632,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to document the extent to which human domain knowledge is employed to improve AAT performance including:\n(1) Reinforcement Learning from Human Feedback (RLHF);\n(2) Fine-tuning;\n(3) Retrieval- augmented generation;\n(4) Content moderation; and\n(5) Business rules.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -21710,7 +22710,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -21814,7 +22815,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -21928,7 +22930,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22035,7 +23038,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22142,7 +23146,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22247,7 +23252,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22354,7 +23360,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22459,7 +23466,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22564,7 +23572,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22669,7 +23678,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22777,7 +23787,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22888,7 +23899,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -22998,7 +24010,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23111,7 +24124,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23217,7 +24231,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23323,7 +24338,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23436,7 +24452,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23543,7 +24560,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23648,7 +24666,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23754,7 +24773,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23859,7 +24879,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23889,7 +24910,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to assign personnel to review AAT-generated content for alignment with culturally accepted norms.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23967,7 +24988,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -23994,7 +25016,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI models are designed with resilience capabilities that are sufficient to withstand reasonable threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24073,7 +25095,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -24096,7 +25119,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent \"model pollution\" due to accidental and/or malicious inputs by an AI agent that can negatively alter the AI model.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24175,7 +25198,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -24198,7 +25222,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and prevent the propagation of false data (e.g., hallucinations) within the AI model or between AI agents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24277,7 +25301,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -24300,7 +25325,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to monitor and prevent resource overload or Denial of Service (DoS) conditions through:\n(1) Enforcement of quotas;\n(2) Workload controls; and \n(3) Auto-suspension of runaway AI agent processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24379,7 +25404,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -24402,7 +25428,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agents are designed, developed and deployed to securely operate under human oversight.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24482,7 +25508,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -24505,7 +25532,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to protect, isolate and harden infrastructure resources used by AI agents, including:\n(1) Resource allocation;\n(2) Privilege management;\n(3) Network segmentation; and \n(4) Workload isolation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24585,7 +25612,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -24608,7 +25636,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement limitations for AI agents according to:\n(1) Least privileges, where the AI agent operates with the minimal permissions necessary to perform designated tasks; and\n(2) Least functionality, where the AI agent is restricted to communicate with the minimal Technology Assets, Applications and/or Services (TAAS) and networks necessary to perform designated tasks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24688,10 +25716,15 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", - "crosswalks": {} + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2092" + ] + } }, { "control_id": "AAT-29.3", @@ -24711,7 +25744,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to authenticate, authorize, validate and monitor all tool and Application Programming Interface (API) invocations by AI agents, including;\n(1) Schema validation;\n(2) Rate limiting;\n(3) Access controls; and\n(4) Output validation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24791,7 +25824,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -24814,7 +25848,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate, secure and restrict AI agent orchestration protocols to prevent:\n(1) Unauthorized tool chaining;\n(2) Context manipulation; and/or\n(3) Protocol-based escalation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24894,7 +25928,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -24917,7 +25952,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate, sanitize and monitor all data inputs and retrieval pipelines for AI agents to:\n(1) Ensure data provenance; and \n(2) Prevent unauthorized access risks (e.g., injection, manipulation or exfiltration).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24997,7 +26032,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25020,7 +26056,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent privilege escalation or unauthorized delegation by AI agents by:\n(1) Monitoring and enforcing dynamic roles; and\n(2) Establishing cross-agent delegation boundaries and privileged actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25100,7 +26136,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25109,8 +26146,8 @@ "control_id": "AAT-29.7", "title": "AI Agent Data Access Restrictions", "family": "AAT", - "description": "Mechanisms exist to restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", - "scf_question": "Does the organization restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data?", + "description": "Mechanisms exist to restrict agent access to sensitive and/or regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", + "scf_question": "Does the organization restrict agent access to sensitive and/or regulated data so that AI agents cannot ingest, generate or act on unauthorized data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -25123,7 +26160,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25203,7 +26240,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25212,8 +26250,8 @@ "control_id": "AAT-29.8", "title": "Data Extraction", "family": "AAT", - "description": "Mechanisms exist to prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point.", - "scf_question": "Does the organization prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point?", + "description": "Mechanisms exist to prevent AI agents from extracting sensitive and/or regulated data from volatile memory that can be exploited at a later point.", + "scf_question": "Does the organization prevent AI agents from extracting sensitive and/or regulated data from volatile memory that can be exploited at a later point?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -25226,7 +26264,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25306,7 +26344,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25329,7 +26368,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure user identification and authentication methods are capable of preventing AI agents from \n(1) Spoofing;\n(2) Mimicry; and/or\n(3) Impersonation attacks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25409,7 +26448,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25432,7 +26472,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent AI agent logic from being subverted or manipulated.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25512,7 +26552,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25535,7 +26576,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to utilize a \"sandbox\" capability to restrict AI agents from unrestricted access to both local and remote resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25615,7 +26656,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25638,7 +26680,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and mitigate prompt injection / input attacks that seek to manipulate AI agent instructions, bypass security, compliance and/or resilience controls or result in unauthorized actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25718,9 +26760,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} }, @@ -25742,7 +26784,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to allow authorized users or operators to immediately halt or disable AI agent activity in case of unexpected behavior or harm.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25822,7 +26864,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25845,7 +26888,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to regularly conduct adversarial testing that simulates attacks against AI agents to identify and mitigate vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25925,7 +26968,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -25948,7 +26992,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to control, restrict and log AI agent self-modification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26028,7 +27072,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26051,7 +27096,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict purging of any persistent memory or long-term data used by AI agents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26131,7 +27176,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26154,7 +27200,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict agentic delegation, chaining and multi-agent communication to prevent unauthorized task escalation or emergent risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26234,7 +27280,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26257,7 +27304,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to continuously monitor for behavioral drift or deviation from established AI agent baselines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26337,7 +27384,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26360,7 +27408,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure that all AI agent-initiated actions are properly mapped to authenticated user or system identities, with enforced authorization checks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26440,7 +27488,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26463,7 +27512,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to provide comprehensive audit trails of AI agent actions including:\n(1) Rationales; and \n(2) User/trigger mappings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26543,7 +27592,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26566,7 +27616,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to:\n(1) Provide human-understandable explanations for significant AI agent actions or decisions; and \n(2) Enable users to contest outcomes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26646,7 +27696,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26669,7 +27720,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect unfair, unethical or biased AI agent actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26749,7 +27800,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26772,7 +27824,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate AI agent-generated outputs through the use of:\n(1) Content scanning; and\n(2) Output vetting through human approvals, where appropriate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26852,17 +27904,18 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} }, { - "control_id": "AAT-30", - "title": "Agentic Output Traceability & Repudiation", + "control_id": "AAT-29.24", + "title": "Resource Limiting", "family": "AAT", - "description": "Mechanisms exist to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", - "scf_question": "Does the organization ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability?", + "description": "Automated mechanisms exist to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget).", + "scf_question": "Does the organization use automated mechanisms to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -26875,62 +27928,26 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget).", + "4": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, - "profiles": [ - "Community Derived", - "CORE AI-Enabled Operations", - "CORE AI Model Deployment" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Document relevant policy and procedures", - "small": "∙ Written policy and procedures\n∙ Designated responsible owner\n∙ Annual review", - "medium": "∙ Formal program with documented processes\n∙ Regular review and testing", - "large": "∙ Enterprise program with dedicated resources\n∙ Automated tooling\n∙ Metrics tracking", - "enterprise": "∙ Enterprise platform with dedicated team\n∙ Automated monitoring\n∙ Continuous improvement program" + "micro_small": "∙ Cloud provider resource quotas and budget alerts\n∙ API rate limiting for AI tool usage\n∙ Basic AI tool usage monitoring", + "small": "∙ Cloud provider resource quotas and API rate limiting\n∙ Cost alerting for AI workload spend", + "medium": "∙ Resource quotas and limits in AI deployment platforms\n∙ Cloud cost management tools (e.g., AWS Cost Explorer, Azure Cost Management)\n∙ API rate limiting and throttling", + "large": "∙ Enterprise resource governance for AI workloads\n∙ Cloud FinOps practices\n∙ Automated resource limit enforcement\n∙ AI workload monitoring and alerting", + "enterprise": "∙ Enterprise AI resource governance platform\n∙ Automated resource limit enforcement with alerting\n∙ AI workload orchestration (e.g., Kubernetes resource limits)\n∙ FinOps program for AI infrastructure costs" }, "risks": [ - "R-AC-1", - "R-AC-2", - "R-AC-3", - "R-AC-4", - "R-AM-1", - "R-AM-2", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-BC-5", "R-EX-1", "R-EX-2", "R-EX-3", "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-GV-8", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" + "R-GV-1" ], "threats": [ "NT-2", @@ -26955,7 +27972,118 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2090 & 2091", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2090", + "ISM-2091" + ] + } + }, + { + "control_id": "AAT-30", + "title": "Agentic Output Traceability & Repudiation", + "family": "AAT", + "description": "Mechanisms exist to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", + "scf_question": "Does the organization ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived", + "CORE AI-Enabled Operations", + "CORE AI Model Deployment" + ], + "possible_solutions": { + "micro_small": "∙ Document relevant policy and procedures", + "small": "∙ Written policy and procedures\n∙ Designated responsible owner\n∙ Annual review", + "medium": "∙ Formal program with documented processes\n∙ Regular review and testing", + "large": "∙ Enterprise program with dedicated resources\n∙ Automated tooling\n∙ Metrics tracking", + "enterprise": "∙ Enterprise platform with dedicated team\n∙ Automated monitoring\n∙ Continuous improvement program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -26978,7 +28106,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to generate event logs for AAT actions to ensure transparency and auditability.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -27058,7 +28186,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -27081,7 +28210,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to control AI agent sessions by:\n(1) Embedding session IDs into the requests to the AI model;\n(2) Implementing capabilities to correlate sessions; and\n(3) Terminating sessions after a defined time period.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -27161,10 +28290,15 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", - "crosswalks": {} + "crosswalks": { + "emea-sau-otcc-1-2022": [ + "2-2-1-4" + ] + } }, { "control_id": "AAT-31", @@ -27184,7 +28318,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent cognitive overload or decision fatigue for humans-in-the-loop (HITL) through risk-based prioritization.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -27264,7 +28398,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -27287,7 +28422,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement Robotic Process Automation (RPA) to improve efficiency, accuracy and speed for high-volume, repetitive and rules-based business processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -27365,7 +28500,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -27476,7 +28612,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -27487,6 +28624,109 @@ ] } }, + { + "control_id": "AAT-33", + "title": "Release Owner Gate (ROG) For AI-Augmented Content", + "family": "AAT", + "description": "Mechanisms exist to implement a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization.", + "scf_question": "Does the organization implement a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to govern a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Manual review and approval process before publishing AI-generated content\n∙ Designated content reviewer for AI-assisted materials", + "small": "∙ Documented AI content review workflow\n∙ SME review checklist for AI-augmented content\n∙ Management sign-off before external release", + "medium": "∙ Formal content release workflow with ROG checkpoint\n∙ SME review requirements for AI-augmented content\n∙ CMS approval workflow for externally published content", + "large": "∙ Enterprise ROG program with defined approval authorities\n∙ Automated flagging of AI-augmented content for review\n∙ Cross-functional review panel for sensitive AI content", + "enterprise": "∙ Enterprise AI content governance program\n∙ Automated AI content detection and flagging\n∙ Multi-stage ROG approval workflows in enterprise CMS\n∙ Board-level visibility into high-risk AI content releases" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": {} + }, { "control_id": "AST-01", "title": "Asset Governance", @@ -27507,11 +28747,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to facilitate an IT Asset Management (ITAM) program to implement and manage asset management controls.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -27582,7 +28822,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -27597,8 +28838,8 @@ "CC6.1-POF9" ], "general-cis-csc-8-1": [ - "1.0", - "2.0", + "1", + "2", "2.1", "2.2" ], @@ -27701,6 +28942,13 @@ "03.04.11.a", "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.18.a[01]", + "A.03.04.11.a[02]", + "A.03.07.04.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 1", "NIST Tenet 5" @@ -27803,15 +29051,18 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PM-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "usa-federal-irs-1075-2021": [ "2.B.7.1", @@ -27837,8 +29088,8 @@ "PM-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(53)", - "3.5(54)" + "3.5.53", + "3.5.54" ], "emea-eu-nis2-2022": [ "Article 21.2(i)" @@ -27851,51 +29102,29 @@ "12.2.3", "12.3.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "12.2" - ], "emea-deu-c5-2020": [ "AM-03" ], "emea-sau-cscc-1-2019": [ - "2-1", - "2-5" - ], - "emea-sau-ecc-1-2018": [ - "2-1-1", - "2-1-2", - "2-6-1", - "2-6-2", - "2-6-4" + "1-3-1" ], "emea-sau-otcc-1-2022": [ - "2-1" + "2-1-1", + "2-1-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.3" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" + "3.3.3", + "3.3.3.1", + "3.3.3.3" ], - "emea-esp-decree-311-2022": [ - "18" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-gbr-caf-4-0": [ "A3" ], - "emea-gbr-cap-1850-2020": [ - "A3" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2" ], "emea-gbr-def-stan-05-138-2024": [ "1300", @@ -27915,7 +29144,7 @@ "1301", "2202" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0285", "ISM-0286", "ISM-0289", @@ -27924,10 +29153,6 @@ "ISM-1457", "ISM-1480" ], - "apac-aus-ps-cps-234-2019": [ - "21", - "21(c)" - ], "apac-ind-sebi-2024": [ "GV.PO.S5" ], @@ -27937,34 +29162,29 @@ "8.1.1.1", "8.1.1.6.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP05", "HHSP54", "HML05", "HML54" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS12", - "HMS14" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP05", "HSUP46" ], "apac-nzl-ism-3-9": [ - "8.4.9.C.01" + "8.4.9.C.01", + "20.2.15.C.04", + "20.2.15.C.07" ], "apac-sgp-mas-trm-2021": [ - "3.3.1", - "3.3.1(a)", - "3.3.1(d)", - "7.1.1", - "11.4.1", - "11.4.2", - "11.4.3" + "3.3.1" ], - "americas-bmu-mba-coc-2020": [ - "5.9" + "americas-arg-ppd-2018": [ + "B.1.3-3" ], "americas-can-osfi-b13-2022": [ "2.2", @@ -28002,7 +29222,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ Data / process owners maintain limited network diagrams to document the flow of sensitive/regulated data that is specific to their initiative.\n▪ Inventory of physical technology assets are assigned to individual users or teams and covers common devices (e.g., laptops, workstations and servers).\n▪ No structured process exists to review or share the results of the inventories.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to i identify and assess the security of Technology Assets, Applications and/or Services (TAAS) that support more than one critical business function.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to i identify and assess the security of Technology Assets, Applications and/or Services (TAAS) that support more than one critical business function. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -28065,9 +29285,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -28105,6 +29325,9 @@ "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -28131,10 +29354,10 @@ "THIRD-PARTIES-1a" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-nerc-cip-2024": [ "CIP-011-3 1.2" @@ -28143,19 +29366,27 @@ "III.B.1.a" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "emea-eu-dora-2023": [ "Article 8.5" ], "emea-deu-bsrit-2017": [ - "12.2" + "3.3" + ], + "emea-sau-cscc-1-2019": [ + "3-1-1-2" ], "emea-sau-cgiot-2024": [ "4-1-4" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "op.cont.3" + ], "emea-gbr-caf-4-0": [ "A3", "A3.a (point 2)" @@ -28163,14 +29394,29 @@ "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ps-cps-234-2019": [ - "21(a)" + "apac-aus-ps-cps-230-2023": [ + "34(a)" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.3" + ], + "apac-sgp-mas-trm-2021": [ + "3.3.1(a)", + "8.1.2" + ], + "americas-arg-ppd-2018": [ + "B.1.1" ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.2", "2.9.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2", + "2.9.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.03" ] @@ -28196,7 +29442,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Inventories may be manual (e.g., spreadsheets) or automated.\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to identify and involve pertinent stakeholders of critical TAASD to support the ongoing secure management of those assets.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -28241,7 +29487,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -28333,12 +29580,28 @@ "III.A" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.2(16)", - "3.5(54)" + "3.5.54" + ], + "emea-deu-c5-2020": [ + "AM-02" + ], + "emea-qat-pdppl-2020": [ + "3.11.2" + ], + "emea-sau-cscc-1-2019": [ + "2-1-1-2" ], "emea-sau-otcc-1-2022": [ "2-1-1-4" ], + "emea-esp-decree-311-2022": [ + "Article 11(1)", + "Article 11(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], "emea-gbr-caf-4-0": [ "A3.a (point 4)" ], @@ -28371,7 +29634,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement a scalable, standardized naming convention for TAASD that avoids asset naming conflicts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -28425,7 +29688,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -28457,7 +29721,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ Inventory of physical technology assets are assigned to individual users or teams and covers common devices (e.g., laptops, workstations and servers).\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ No structured process exists to review or share the results of the inventories.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain a current list of approved technologies (hardware and software).", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain a current list of approved technologies (hardware and software). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -28528,13 +29792,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { + "general-nist-800-171-r3": [ + "03.04.08.c" + ], "general-nist-800-171a-r3": [ "A.03.04.08.c" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(1)" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP2-2" + ], "emea-gbr-def-stan-05-138-2024": [ "2410" ], @@ -28547,8 +29821,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2410" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS12" + "apac-sgp-mas-trm-2021": [ + "3.3.1(a)", + "6.5.1" + ], + "americas-can-itsp-10-171-2025": [ + "03.04.08.C" ] } }, @@ -28603,11 +29881,15 @@ "MT-5", "MT-8", "MT-9", - "MT-10" + "MT-10", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Asset Management", - "crosswalks": {} + "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ] + } }, { "control_id": "AST-02", @@ -28632,11 +29914,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Inventories may be manual (e.g., spreadsheets) or automated.\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ No structured process exists to review or share the results of the inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to perform inventories of TAASD that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -28710,7 +29992,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -28723,9 +30006,9 @@ "CC6.1-POF1" ], "general-cis-csc-8-1": [ - "1.0", + "1", "1.1", - "2.0", + "2", "2.1", "2.2", "2.4", @@ -28812,7 +30095,7 @@ "general-iso-27018-2025": [ "5.9" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011.001", "T1020.001", "T1021.001", @@ -29002,13 +30285,13 @@ "3.4.1[f]" ], "general-nist-800-171a-r3": [ + "A.03.04.08.a", + "A.03.04.08.c", "A.03.04.10.ODP[01]", "A.03.04.10.a", "A.03.04.10.b[01]", - "A.03.04.10.b[02]" - ], - "general-nist-800-172": [ - "3.1.2e" + "A.03.04.10.b[02]", + "A.03.04.11.a[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -29057,9 +30340,6 @@ "9.5.1", "9.5.1.1" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG1.SP1" ], @@ -29114,11 +30394,14 @@ "CM-08", "PM-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(3)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "PM-5" @@ -29164,8 +30447,9 @@ "CM-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(53)", - "3.5(54)" + "3.3.2.16", + "3.5.53", + "3.5.54" ], "emea-eu-dora-2023": [ "Article 8.4", @@ -29181,20 +30465,16 @@ "12.4.2(a)", "12.4.2(b)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ - "8.2", - "12.2" + "3.3", + "8.2" ], "emea-deu-c5-2020": [ "AM-01", - "AM-02" + "RB-12" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 1" ], "emea-sau-cscc-1-2019": [ "2-1-1-1" @@ -29203,12 +30483,11 @@ "2-1-1" ], "emea-sau-otcc-1-2022": [ - "2-1", - "2-1-1", - "2-1-1-3" + "2-1-1-1" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.1 [OP.EXP.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "emea-uae-niaf-2023": [ "3.1.1" @@ -29242,10 +30521,11 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0336", "ISM-1643", - "ISM-1807" + "ISM-1807", + "ISM-1966" ], "apac-ind-sebi-2024": [ "ID.AM.S1", @@ -29259,8 +30539,8 @@ "8.1.1.4", "8.1.2.3" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS03" + "apac-mys-bnm-rmit-2025": [ + "11.3" ], "apac-nzl-ism-3-9": [ "8.4.8.C.01", @@ -29268,19 +30548,24 @@ ], "apac-sgp-mas-trm-2021": [ "3.3.1(a)", - "3.3.2" + "3.3.2", + "11.5.1" + ], + "americas-arg-ppd-2018": [ + "B.1.1", + "D.1.1-4" ], "americas-bmu-mba-coc-2020": [ "5.9" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" - ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.2", "2.2.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.08.C", @@ -29308,9 +30593,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to update asset inventories as part of component installations, removals and asset upgrades.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to update asset inventories as part of component installations, removals and asset upgrades. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -29349,7 +30634,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -29404,6 +30690,8 @@ "3.4.1[f]" ], "general-nist-800-171a-r3": [ + "A.03.04.10.a", + "A.03.04.10.b[02]", "A.03.04.10.c[01]", "A.03.04.10.c[02]", "A.03.04.10.c[03]" @@ -29424,10 +30712,10 @@ "CM-08(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "CM-8(CE-1)" @@ -29445,14 +30733,13 @@ "12.4.3" ], "emea-deu-c5-2020": [ - "AM-01", - "AM-02" + "AM-01" ], "emea-sau-cgiot-2024": [ "2-1-2" ], - "emea-sau-otcc-1-2022": [ - "2-1-1-1" + "americas-arg-ppd-2018": [ + "B.1.3-1" ], "americas-can-itsp-10-171-2025": [ "03.04.10.A", @@ -29479,7 +30766,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to automatically detect and alert upon the detection of unauthorized hardware, software and firmware components.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -29518,7 +30805,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -29588,6 +30876,13 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.a", + "A.03.04.02E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 6" @@ -29607,6 +30902,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-08(03)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ], "usa-federal-irs-1075-2021": [ "CM-8(CE-3)", "CM-8(CE-3).a", @@ -29623,12 +30921,6 @@ "CM-8(3)-IS.1", "CM-8(3)-IS.2" ], - "emea-deu-c5-2020": [ - "AM-02" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], "emea-gbr-def-stan-05-138-2024": [ "3204" ], @@ -29641,7 +30933,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3204" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1807" ] } @@ -29715,7 +31007,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -29846,9 +31139,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to document and govern instances of approved deviations from established baseline configurations.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to document and govern instances of approved deviations from established baseline configurations. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -29906,7 +31199,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -29932,11 +31226,9 @@ "03.04.02.b", "03.04.06.a" ], - "emea-deu-c5-2020": [ - "SP-03" - ], - "emea-isr-cmo-1-0": [ - "6.8" + "general-nist-800-171a-r3": [ + "A.03.04.02.a[02]", + "A.03.04.06.a" ], "emea-gbr-def-stan-05-138-2024": [ "2202" @@ -29947,6 +31239,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2202" ], + "apac-sgp-mas-trm-2021": [ + "3.2.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", "03.04.06.A" @@ -29971,7 +31269,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to automatically employ Network Access Control (NAC), or a similar technology, which is capable of detecting unauthorized devices and disable network access to those unauthorized devices.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -29986,7 +31284,7 @@ "small": "∙ VLAN segmentation to isolate unknown devices\n∙ MAC address filtering (basic NAC)\n∙ Wireless access point policies", "medium": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Open-source NAC (e.g., PacketFence)", "large": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ 802.1X certificate-based authentication", - "enterprise": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Zero Trust Network Access (ZTNA) integration\n∙ 802.1X with EAP-TLS and certificate infrastructure" + "enterprise": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Zero Trust Network Architecture (ZTNA) integration\n∙ 802.1X with EAP-TLS and certificate infrastructure" }, "risks": [ "R-AC-1", @@ -30038,7 +31336,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -30065,9 +31364,6 @@ "general-nist-800-161-r1-level-3": [ "SC-7(19)" ], - "general-nist-800-172": [ - "3.5.3e" - ], "general-nist-800-207": [ "NIST Tenet 6" ], @@ -30080,19 +31376,14 @@ "usa-federal-dow-cmmc-2-level-3": [ "IA.L3-3.5.3E" ], - "emea-isr-cmo-1-0": [ - "23.6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0520", "ISM-1182" ], "apac-sgp-mas-trm-2021": [ - "11.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "4.21", - "4.24" + "11.2.4", + "11.2.5", + "11.5.4" ] } }, @@ -30118,7 +31409,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to enable Dynamic Host Configuration Protocol (DHCP) server logging to improve asset inventories and assist in detecting unknown systems.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to enable Dynamic Host Configuration Protocol (DHCP) server logging to improve asset inventories and assist in detecting unknown systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -30175,7 +31466,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -30218,7 +31510,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors are primarily administrative and preventative in nature.", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to protect Intellectual Property (IP) rights with software licensing restrictions.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to protect Intellectual Property (IP) rights with software licensing restrictions.\n", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -30266,7 +31558,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -30333,11 +31626,8 @@ "usa-federal-irs-1075-2021": [ "SC-18(CE-2)" ], - "emea-isr-cmo-1-0": [ - "3.1" - ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "3-BP1" ], "apac-jpn-ismap": [ "14.2.7.1", @@ -30354,9 +31644,6 @@ "18.1.2.10", "18.1.2.11", "18.1.2.12" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS14" ] } }, @@ -30364,8 +31651,8 @@ "control_id": "AST-02.8", "title": "Data Action Mapping", "family": "AST", - "description": "Mechanisms exist to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed.", - "scf_question": "Does the organization create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed?", + "description": "Mechanisms exist to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive and/or regulated data is stored, transmitted or processed.", + "scf_question": "Does the organization create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive and/or regulated data is stored, transmitted or processed?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -30380,7 +31667,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT and/or cybersecurity personnel work with process owners to generate and maintain Data Flow Diagrams (DFDs) and network diagrams to document the flow of data to create and maintain a map of systems where sensitive/regulated data is stored, transmitted or processed.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -30442,7 +31729,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -30491,16 +31779,16 @@ "A.03.04.11.b[01]", "A.03.04.11.b[02]" ], - "general-nist-800-172": [ - "3.1.3e" + "general-nist-800-172-r3": [ + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.14E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 1", "NIST Tenet 7" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DA.DAUTE" ], @@ -30518,8 +31806,9 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(4)(A)" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-16" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "apac-ind-sebi-2024": [ "ID.AM.S2" @@ -30548,7 +31837,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and manage a Configuration Management Database (CMDB), or similar technology, to monitor and govern technology asset-specific information.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -30616,7 +31905,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -30692,12 +31982,28 @@ "general-nist-800-171-r3": [ "03.04.08.a", "03.04.10.a", - "03.04.10.b", - "03.04.10.c" + "03.04.10.b" ], - "general-nist-800-172": [ - "3.4.1e", - "3.4.3e" + "general-nist-800-171a-r3": [ + "A.03.04.08.a", + "A.03.04.10.a", + "A.03.04.10.b[02]" + ], + "general-nist-800-172-r3": [ + "03.04.03E", + "03.04.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.03E[01]", + "A.03.04.03E.ODP[01]", + "DS-A.03.04.03E[02]", + "A.03.04.03E.ODP[02]", + "DS-A.03.04.03E[03]", + "A.03.04.03E.ODP[03]", + "DS-A.03.04.04E[01]", + "DS-A.03.04.04E[02]", + "DS-A.03.04.04E[03]", + "DS-A.03.04.08E" ], "general-nist-800-207": [ "NIST Tenet 1", @@ -30727,18 +32033,36 @@ "CM-08(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.5.54" + ], + "emea-deu-c5-2020": [ + "AM-01", + "AM-01-DOAR", + "RB-12" ], "emea-sau-cgiot-2024": [ "2-1-2" ], "emea-sau-otcc-1-2022": [ - "2-1-1", - "2-1-1-2", - "2-1-1-3" + "2-1-1-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.3.3", + "3.3.3.3.a", + "3.3.3.3.b", + "3.3.3.3.c", + "3.3.3.3.d", + "3.3.3.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-def-stan-05-138-2024": [ "1301", @@ -30755,17 +32079,26 @@ "1301", "2423" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1493" ], + "apac-mys-bnm-rmit-2025": [ + "11.3" + ], + "apac-nzl-ism-3-9": [ + "20.2.15.C.07" + ], "americas-can-osfi-b13-2022": [ "2.2.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2", + "2.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.10.A", - "03.04.10.B", - "03.04.10.C" + "03.04.10.B" ] } }, @@ -30787,11 +32120,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to track the geographic location of system components.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -30820,7 +32153,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -30897,7 +32231,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -30939,11 +32274,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure asset ownership responsibilities are assigned, tracked and managed at a team, individual, or responsible organization level to establish a common understanding of requirements for asset protection.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -31015,7 +32350,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -31060,6 +32396,9 @@ "general-nist-800-171-r3": [ "03.09.02.a.03" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.03" + ], "general-nist-csf-2-0": [ "ID.AM" ], @@ -31104,9 +32443,6 @@ "2.2.5", "6.5.2" ], - "general-scf-dpmp-2025": [ - "5.3" - ], "general-tisax-6-0-3": [ "1.3.1" ], @@ -31126,10 +32462,10 @@ "SA-04(12)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-4(CE-12)", @@ -31138,20 +32474,20 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.A" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-deu-c5-2020": [ + "AM-02" ], "emea-sau-cscc-1-2019": [ "2-1-1-2" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], "emea-gbr-caf-4-0": [ "A3.a (point 4)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1071" ], "apac-ind-sebi-2024": [ @@ -31163,6 +32499,14 @@ "8.1.2.1", "8.1.2.2" ], + "americas-arg-ppd-2018": [ + "B.1.2-1", + "B.1.2-2" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP1", + "5.9-BP2" + ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" ] @@ -31188,7 +32532,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to include capturing the name, position and/or role of individuals responsible/accountable for administering assets as part of the technology asset inventory process.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -31256,7 +32600,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -31311,12 +32656,12 @@ "general-nist-800-171-r3": [ "03.09.02.a.03" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.03" + ], "general-nist-csf-2-0": [ "ID.AM" ], - "general-scf-dpmp-2025": [ - "5.3" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG1.SP3" ], @@ -31324,10 +32669,14 @@ "CM-08(04)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" @@ -31431,7 +32780,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -31456,7 +32806,7 @@ "general-iso-42001-2023": [ "A.7.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -31504,6 +32854,15 @@ "general-nist-800-161-r1-level-3": [ "SR-4" ], + "general-nist-800-172-r3": [ + "03.17.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.04E[01]", + "A.03.17.04E.ODP[01]", + "DS-A.03.17.04E[02]", + "DS-A.03.17.04E[03]" + ], "general-sparta": [ "CM0026", "CM0049" @@ -31511,10 +32870,14 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "4.2" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1790", "ISM-1791", - "ISM-1792" + "ISM-1792", + "ISM-1816" ] } }, @@ -31522,8 +32885,8 @@ "control_id": "AST-04", "title": "Network Diagrams & Data Flow Diagrams (DFDs)", "family": "AST", - "description": "Mechanisms exist to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive/regulated data flows.", - "scf_question": "Does the organization maintain network architecture diagrams that: \n (1) Contain sufficient detail to assess the security of the network's architecture;\n (2) Reflect the current architecture of the network environment; and\n (3) Document all sensitive/regulated data flows?", + "description": "Mechanisms exist to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive and/or regulated data flows.", + "scf_question": "Does the organization maintain network architecture diagrams that: \n (1) Contain sufficient detail to assess the security of the network's architecture;\n (2) Reflect the current architecture of the network environment; and\n (3) Document all sensitive and/or regulated data flows?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -31540,7 +32903,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT and/or cybersecurity personnel work with process owners to generate and maintain Data Flow Diagrams (DFDs) and network diagrams to document the flow of data to create and maintain a map of systems where sensitive/regulated data is stored, transmitted or processed.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive/regulated data flows.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -31613,7 +32976,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -31751,8 +33115,17 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.1.3e" + "general-nist-800-171a-r3": [ + "A.03.01.03[02]", + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.14E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -31779,9 +33152,6 @@ "1.2.3", "1.2.4" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "general-sparta": [ "CM0022" ], @@ -31823,6 +33193,9 @@ "SA-04(01)", "SA-04(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(4)" + ], "usa-federal-irs-1075-2021": [ "PL-2", "SA-4(CE-1)", @@ -31858,19 +33231,21 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(a)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "COS-07" + "KOS-06" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 1" ], "emea-sau-otcc-1-2022": [ "2-4-1-16" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "op.mon.1", + "mp.com.1" + ], "emea-gbr-caf-4-0": [ "B3.a" ], @@ -31889,26 +33264,36 @@ "1203", "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0516", "ISM-0518", "ISM-1645", "ISM-1646" ], + "apac-aus-ps-cps-230-2023": [ + "34(a)" + ], "apac-ind-sebi-2024": [ "ID.AM.S2" ], "apac-jpn-ismap": [ "4.4.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.41" + ], "apac-nzl-ism-3-9": [ "18.1.9.C.02", "18.1.11.C.01", "18.1.12.C.01", "18.1.12.C.02" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" + "apac-sgp-mas-trm-2021": [ + "8.1.2" + ], + "americas-arg-ppd-2018": [ + "B.1.1", + "E.1.1-2" ], "americas-can-itsp-10-171-2025": [ "03.01.03", @@ -31940,7 +33325,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to determine security, compliance and resilience control applicability by identifying, assigning and documenting the appropriate asset scope categorization for all Technology Assets, Applications and/or Services (TAAS) and personnel (internal and third-parties).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -31999,9 +33384,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -32090,8 +33475,16 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.14.3e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.06.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.06.03E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -32161,16 +33554,31 @@ "SA-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)" + "3.3.3.17", + "3.3.3.18" ], "emea-eu-nis2-annex-2024": [ "11.7.2", "12.1.1", "12.1.3" ], - "emea-deu-bsrit-2017": [ - "12.4" + "emea-sau-ecc-1-2018": [ + "2-1-5" + ], + "emea-esp-decree-311-2022": [ + "Article 40(1)", + "Article 40(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.2" + ], + "apac-aus-ps-cps-230-2023": [ + "36", + "36(a)", + "36(b)", + "36(c)", + "36(d)", + "37" ], "apac-jpn-ismap": [ "4.4.4", @@ -32204,7 +33612,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure control applicability is appropriately-determined for Technology Assets, Applications and/or Services (TAAS) and third parties by graphically representing applicable boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -32238,7 +33646,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -32251,6 +33660,11 @@ "03.04.11.b", "03.15.02.a.04" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], "general-nist-csf-2-0": [ "ID.AM-03" ], @@ -32278,9 +33692,6 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.B.1.c" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-16" - ], "americas-can-itsp-10-171-2025": [ "03.04.11.A", "03.04.11.B", @@ -32342,13 +33753,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-pci-dss-4-0-1": [ "6.3.2", "12.5.1", @@ -32380,8 +33795,8 @@ "control_id": "AST-05", "title": "Security of Assets & Media", "family": "AST", - "description": "Mechanisms exist to maintain strict control over the internal or external distribution of any kind of sensitive/regulated media.", - "scf_question": "Does the organization maintain strict control over the internal or external distribution of any kind of sensitive/regulated media?", + "description": "Mechanisms exist to maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity.", + "scf_question": "Does the organization maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -32394,9 +33809,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT personnel collect technology assets and media for destruction when it is no longer needed for business or legal reasons.", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain strict control over the internal or external distribution of any kind of sensitive/regulated media.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -32482,8 +33897,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -32507,6 +33924,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-pci-dss-4-0-1": [ "9.4", "9.4.4" @@ -32538,18 +33958,19 @@ "emea-eu-nis2-annex-2024": [ "12.2.2(c)" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0161", "ISM-0293", - "ISM-1178" + "ISM-1178", + "ISM-1973" ], "apac-jpn-ismap": [ "8.3", "8.3.1" ], + "apac-nzl-ism-3-9": [ + "17.9.36.C.01" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.A" ] @@ -32559,8 +33980,8 @@ "control_id": "AST-05.1", "title": "Management Approval For External Media Transfer", "family": "AST", - "description": "Mechanisms exist to obtain management approval for any sensitive/regulated media that is transferred outside of the organization's facilities.", - "scf_question": "Does the organization obtain management approval for any sensitive/regulated media that is transferred outside of its facilities?", + "description": "Mechanisms exist to obtain management approval for any sensitive and/or regulated media that is transferred outside of the organization's facilities.", + "scf_question": "Does the organization obtain management approval for any sensitive and/or regulated media that is transferred outside of its facilities?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -32648,7 +34069,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -32692,12 +34114,12 @@ } }, { - "control_id": "AST-06", - "title": "Unattended End-User Equipment", + "control_id": "AST-05.2", + "title": "Technology Assets, Applications, Services and/or Data (TAASD) Storage", "family": "AST", - "description": "Mechanisms exist to implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access.", - "scf_question": "Does the organization implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access?", - "relative_weight": 9, + "description": "Mechanisms exist to ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "scf_question": "Does the organization ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections?", + "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", @@ -32705,25 +34127,23 @@ "scrm_focus": { "strategic": false, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", - "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access.", + "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE)", - "small": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE)", - "medium": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)", - "large": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)", - "enterprise": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)" + "micro_small": "∙ Locked cabinet or secure room for equipment\n∙ Basic physical access controls (key or PIN)", + "small": "∙ Locked server room with physical access controls\n∙ Physical access log\n∙ Environmental controls (temperature, humidity)", + "medium": "∙ Dedicated server room with physical access controls and monitoring\n∙ Physical access logging\n∙ Co-location or private cage in certified data center", + "large": "∙ Secure data center facilities (access control, CCTV, environmental monitoring)\n∙ Co-location or private cage in certified data center\n∙ Physical security assessments", + "enterprise": "∙ Co-location or private cage in certified data center\n∙ Multi-layer physical access controls (mantraps, biometrics)\n∙ 24/7 physical security monitoring\n∙ Redundant physical infrastructure" }, "risks": [ "R-AC-1", @@ -32737,6 +34157,7 @@ "R-BC-2", "R-BC-3", "R-BC-4", + "R-BC-5", "R-EX-1", "R-EX-2", "R-EX-3", @@ -32794,7 +34215,123 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ], + "errata": "- new control - AU ISM ISM-1975", + "family_name": "Asset Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1974", + "ISM-1975" + ] + } + }, + { + "control_id": "AST-06", + "title": "Unattended End-User Equipment", + "family": "AST", + "description": "Mechanisms exist to implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access.", + "scf_question": "Does the organization implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", + "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement enhanced protection measures for unattended technology assets to protect against tampering and unauthorized access.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE)", + "small": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE)", + "medium": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)", + "large": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)", + "enterprise": "∙ Lockable casings\n∙ Tamper detection tape\n∙ Full Disk Encryption (FDE) \n∙ File Integrity Monitoring (FIM)\n∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)\n∙ Netwrix Auditor (https://netrix.com)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -32838,10 +34375,13 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.5.1" ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.2 [MP.EQ.2]" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0161" ], "apac-jpn-ismap": [ @@ -32939,21 +34479,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", - "crosswalks": { - "emea-deu-c5-2020": [ - "AM-02" - ] - } + "crosswalks": {} }, { "control_id": "AST-07", "title": "Kiosks & Point of Interaction (PoI) Devices", "family": "AST", - "description": "Mechanisms exist to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution.", - "scf_question": "Does the organization appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution?", + "description": "Mechanisms exist to appropriately protect devices that capture sensitive and/or regulated data via direct physical interaction from tampering and substitution.", + "scf_question": "Does the organization appropriately protect devices that capture sensitive and/or regulated data via direct physical interaction from tampering and substitution?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -32968,7 +34505,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -33049,7 +34586,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -33098,8 +34636,9 @@ "9.5.1.1", "9.5.1.2" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.12" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ] } }, @@ -33204,7 +34743,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -33226,6 +34766,14 @@ "general-iso-27018-2025": [ "7.9" ], + "general-nist-800-172-r3": [ + "03.17.02E", + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.02E.ODP[04]", + "A.03.17.05E.ODP[02]" + ], "general-pci-dss-4-0-1": [ "9.5.1.2", "9.5.1.2.1" @@ -33368,7 +34916,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -33465,6 +35014,10 @@ "03.07.04.c", "03.08.03" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.c", + "A.03.08.03" + ], "general-pci-dss-4-0-1": [ "9.4.7" ], @@ -33512,12 +35065,12 @@ "314.4(c)(6)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.F.3.1" @@ -33539,16 +35092,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-12" ], - "emea-us-psd2-2015": [ - "24" - ], "emea-deu-c5-2020": [ - "AM-04", - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "15.4", - "17.21" + "AM-04" ], "emea-sau-cgiot-2024": [ "2-5-1", @@ -33557,18 +35102,16 @@ "emea-sau-ecc-1-2018": [ "2-14-3-4" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" - ], "emea-sau-sacs-002-2022": [ - "TPC-19", - "TPC-66" + "VII.A.TPC-19", + "VII.B.TPC-66" ], "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.5 [MP.SI.5]" + "3.3.2.3.e", + "3.3.11", + "3.3.11.1", + "3.3.11.4", + "3.3.11.5" ], "emea-gbr-def-stan-05-138-2024": [ "2323" @@ -33582,7 +35125,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0312", "ISM-0315", @@ -33603,7 +35146,6 @@ "ISM-1221", "ISM-1222", "ISM-1223", - "ISM-1225", "ISM-1534", "ISM-1550", "ISM-1641", @@ -33632,7 +35174,7 @@ "11.2.7.1", "11.2.7.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP06", "HHSP45", "HML06", @@ -33643,8 +35185,11 @@ ], "apac-nzl-ism-3-9": [ "11.2.13.C.01", - "11.2.13.C.02", "11.7.35.C.01", + "11.8.10.C.03", + "11.8.10.C.05", + "11.8.12.C.01", + "11.8.12.C.02", "12.6.4.C.01", "12.6.4.C.02", "12.6.5.C.01", @@ -33655,8 +35200,8 @@ "12.6.8.C.01", "12.6.9.C.01", "12.6.10.C.01", - "13.4.19.C.02", "13.4.10.C.01", + "13.4.19.C.02", "13.5.24.C.01", "13.5.24.C.02", "13.5.24.C.03", @@ -33677,15 +35222,23 @@ "13.6.10.C.02", "13.6.10.C.03", "13.6.11.C.01", - "13.6.12.C.01" + "13.6.12.C.01", + "17.6.6.C.01" ], "apac-sgp-mas-trm-2021": [ "11.1.7" ], + "americas-arg-ppd-2018": [ + "F", + "F.1.2-DS-2" + ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.C", "03.08.03" @@ -33780,7 +35333,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -33807,11 +35361,10 @@ "A.03.09.02.a.03" ], "emea-deu-c5-2020": [ - "AM-04", - "AM-05" + "AM-04" ], - "emea-isr-cmo-1-0": [ - "11.12" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e.2" ], "apac-jpn-ismap": [ "8.1.4" @@ -33841,7 +35394,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to authorize, control and track technology assets entering and exiting organizational facilities.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to authorize, control and track technology assets entering and exiting organizational facilities. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -33909,7 +35462,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -33929,10 +35483,15 @@ "164.310(d)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ] } }, @@ -34045,7 +35604,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -34060,11 +35620,15 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], - "emea-isr-cmo-1-0": [ - "12.6" + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4", + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A" @@ -34089,7 +35653,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to reduce the risk associated with third-party assets that are attached to the network from harming organizational assets or exfiltrating organizational data.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -34162,22 +35726,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-nist-800-171-r3": [ "03.01.18.a" ], - "emea-isr-cmo-1-0": [ - "12.6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-84" - ], - "apac-nzl-ism-3-9": [ - "16.2.3.C.01", - "16.2.3.C.02" + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A" @@ -34202,11 +35760,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to monitor and enforce usage parameters that limit the potential damage caused from the unauthorized or unintentional alteration of system parameters.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to monitor and enforce usage parameters that limit the potential damage caused from the unauthorized or unintentional alteration of system parameters. \n", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -34263,11 +35821,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011", "T1078", "T1078.004", @@ -34286,6 +35845,9 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" + ], "general-swift-cscf-2025": [ "2.9" ], @@ -34312,7 +35874,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to prevent the usage of Bluetooth and wireless devices (e.g., Near Field Communications (NFC)) in sensitive areas or unless used in a Radio Frequency (RF)-screened building.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -34383,7 +35945,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -34394,22 +35957,13 @@ "usa-federal-fbi-cjis-6-0": [ "5.20.1.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0233", "ISM-1199", "ISM-1200" ], "apac-nzl-ism-3-9": [ - "11.1.8.C.01", - "11.1.10.C.01", - "11.1.10.C.02", - "11.1.10.C.03", - "11.1.11.C.01", - "11.1.11.C.02", - "11.1.12.C.01", - "11.1.13.C.01", - "21.1.16.C.01", - "21.1.16.C.02" + "11.1.19.C.03" ] } }, @@ -34502,7 +36056,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -34510,9 +36065,9 @@ "O.9" ], "apac-nzl-ism-3-9": [ - "11.1.9.C.01", - "11.1.9.C.02", - "11.1.9.C.03" + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03" ] } }, @@ -34540,7 +36095,7 @@ "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Periodic physical inspections are performed to validate the integrity of unattended technology assets (e.g., kiosks, ATMs, point of sale devices, etc.).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to assess the integrity of critical Technology Assets, Applications and/or Services (TAAS) to detect evidence of tampering, where:\n(1)\tLogical assessments evaluate the integrity of critical components (e.g., configuration settings); and\n(2)\tPhysical assessments evaluate assets for evidence of unauthorized access and/or modifications.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -34595,7 +36150,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -34643,6 +36199,12 @@ "general-nist-800-161-r1-level-3": [ "SR-9" ], + "general-nist-800-172-r3": [ + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.05E.ODP[02]" + ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -34700,9 +36262,9 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Periodic physical inspections are performed to validate the integrity of unattended technology assets (e.g., kiosks, ATMs, point of sale devices, etc.).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to physically and logically inspect critical technology assets to detect evidence of tampering.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to physically and logically inspect critical technology assets to detect evidence of tampering. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -34773,7 +36335,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -34819,6 +36382,12 @@ "general-nist-800-161-r1-level-3": [ "SR-10" ], + "general-nist-800-172-r3": [ + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.02E" + ], "general-pci-dss-4-0-1": [ "9.5.1", "9.5.1.2" @@ -34885,7 +36454,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ The use of personal devices (e.g., Bring Your Own Device (BYOD), as part of acceptable and unacceptable behaviors are primarily administrative and preventative in nature.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and govern a Bring Your Own Device (BYOD) program to reduce risk associated with personally-owned devices in the workplace.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -34957,7 +36526,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -34973,19 +36543,23 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.4", "2.4.2" ], - "emea-sau-cscc-1-2019": [ - "2-5" - ], "emea-sau-ecc-1-2018": [ - "2-6-1", - "2-6-2" + "2-6-1" ], "emea-sau-sama-csf-1-2017": [ - "3.3.10" + "3.3.10.4", + "3.3.10.4.a", + "3.3.10.4.b", + "3.3.10.4.c", + "3.3.10.4.d", + "3.3.10.4.e" ], "emea-gbr-def-stan-05-138-2024": [ "2322" @@ -34999,68 +36573,67 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1297" ], "apac-nzl-ism-3-9": [ "8.1.12.C.01", "21.1.12.C.01", - "21.4.7.C.01", - "21.4.7.C.02", - "21.4.8.C.01", - "21.4.8.C.02", - "21.4.9.C.01", - "21.4.10.C.01", - "21.4.10.C.02", - "21.4.10.C.03", - "21.4.10.C.04", - "21.4.10.C.05", - "21.4.10.C.06", - "21.4.10.C.07", - "21.4.10.C.08", - "21.4.10.C.09", - "21.4.10.C.10", - "21.4.10.C.11", - "21.4.10.C.12", - "21.4.10.C.13", - "21.4.10.C.14", - "21.4.10.C.15", - "21.4.10.C.16", - "21.4.11.C.01", - "21.4.11.C.02", - "21.4.11.C.03", - "21.4.11.C.04", - "21.4.11.C.05", - "21.4.11.C.06", - "21.4.11.C.07", - "21.4.11.C.08", - "21.4.11.C.09", - "21.4.11.C.10", - "21.4.11.C.11", - "21.4.11.C.12", - "21.4.11.C.13", - "21.4.11.C.14", - "21.4.11.C.15", - "21.4.11.C.16", - "21.4.11.C.17", - "21.4.11.C.18", - "21.4.11.C.19", - "21.4.11.C.20", - "21.4.13.C.01", - "21.4.13.C.02", - "21.4.13.C.03", - "21.4.13.C.04", - "21.4.13.C.05", - "21.4.13.C.06", - "21.4.13.C.07", - "21.4.13.C.08", - "21.4.13.C.09", - "21.4.13.C.10", - "21.4.13.C.11", - "21.4.14.C.01", - "21.4.14.C.02", - "21.4.14.C.03", - "21.4.14.C.04" + "22.4.7.C.02", + "22.4.8.C.01", + "22.4.8.C.02", + "22.4.10.C.01", + "22.4.10.C.02", + "22.4.10.C.03", + "22.4.10.C.04", + "22.4.10.C.05", + "22.4.10.C.06", + "22.4.10.C.07", + "22.4.10.C.08", + "22.4.10.C.09", + "22.4.10.C.10", + "22.4.10.C.11", + "22.4.10.C.12", + "22.4.10.C.13", + "22.4.10.C.14", + "22.4.10.C.15", + "22.4.10.C.16", + "22.4.11.C.01", + "22.4.11.C.02", + "22.4.11.C.03", + "22.4.11.C.04", + "22.4.11.C.05", + "22.4.11.C.06", + "22.4.11.C.07", + "22.4.11.C.08", + "22.4.11.C.09", + "22.4.11.C.10", + "22.4.11.C.11", + "22.4.11.C.12", + "22.4.11.C.13", + "22.4.11.C.14", + "22.4.11.C.15", + "22.4.11.C.16", + "22.4.11.C.17", + "22.4.11.C.18", + "22.4.11.C.19", + "22.4.11.C.20", + "22.4.12.C.01", + "22.4.13.C.01", + "22.4.13.C.02", + "22.4.13.C.03", + "22.4.13.C.04", + "22.4.13.C.05", + "22.4.13.C.06", + "22.4.13.C.07", + "22.4.13.C.08", + "22.4.13.C.09", + "22.4.13.C.10", + "22.4.13.C.11", + "22.4.14.C.01", + "22.4.14.C.02", + "22.4.14.C.03", + "22.4.14.C.04" ], "apac-sgp-mas-trm-2021": [ "11.3.7" @@ -35090,7 +36663,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to govern Supply Chain Risk Management (SCRM) sanctions that require the removal and prohibition of certain Technology Assets, Applications and/or Services (TAAS) that are designated as supply chain threats by a statutory or regulatory body.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35164,7 +36737,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -35172,6 +36746,10 @@ "03.11.01.a", "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.16.01" + ], "usa-federal-far-52-204-25": [ "52.204-25(b)(1)", "52.204-25(b)(2)" @@ -35205,7 +36783,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to provision and protect the confidentiality, integrity and authenticity of product supplier keys and data that can be used as a “roots of trust” basis for integrity verification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35270,7 +36848,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -35287,9 +36866,6 @@ "NDR 3.13(a)", "NDR 3.13(b)" ], - "general-nist-800-172": [ - "3.14.1e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -35301,10 +36877,6 @@ ], "emea-sau-cgiot-2024": [ "2-15-1" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 7" ] } }, @@ -35326,7 +36898,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for telecommunication equipment to prevent potential damage or unauthorized modification and to prevent potential eavesdropping.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35390,18 +36962,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0558" ], "apac-nzl-ism-3-9": [ @@ -35419,7 +36985,10 @@ "11.3.12.C.03", "11.3.13.C.01", "11.3.13.C.02", - "11.3.13.C.03" + "11.3.13.C.03", + "11.8.3.C.01", + "11.8.4.C.01", + "11.8.5.C.01" ] } }, @@ -35441,7 +37010,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement secure Video Teleconference (VTC) capabilities on endpoint devices and in designated conference rooms, to prevent potential eavesdropping.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35505,14 +37074,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-shared-assessments-sig-2025": [ "M.1.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0548", "ISM-0551", "ISM-0553", @@ -35521,9 +37091,6 @@ "ISM-1014", "ISM-1562" ], - "apac-chn-pipl-2021": [ - "26" - ], "apac-nzl-ism-3-9": [ "18.3.14.C.01", "18.3.14.C.02" @@ -35548,7 +37115,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement secure Internet Protocol Telephony (IPT) that logically or physically separates Voice Over Internet Protocol (VoIP) traffic from data networks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35612,7 +37179,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -35633,7 +37201,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2412" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0549", "ISM-0551", "ISM-0555", @@ -35668,8 +37236,8 @@ "control_id": "AST-22", "title": "Microphones & Web Cameras", "family": "AST", - "description": "Mechanisms exist to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed.", - "scf_question": "Does the organization configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed?", + "description": "Mechanisms exist to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive and/or regulated information is discussed.", + "scf_question": "Does the organization configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive and/or regulated information is discussed?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -35682,7 +37250,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35746,14 +37314,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-shared-assessments-sig-2025": [ "N.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0559", "ISM-1450" ] @@ -35779,7 +37348,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely configure Multi-Function Devices (MFD) according to industry-recognized secure practices for the type of device.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35843,7 +37412,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -35855,35 +37425,23 @@ "3.3.5.b-2", "3.3.5.c-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0245", "ISM-0589", "ISM-0590", - "ISM-1036" + "ISM-1036", + "ISM-1854", + "ISM-1855" ], "apac-nzl-ism-3-9": [ - "11.2.3.C.01", - "11.2.4.C.01", - "11.2.4.C.02", - "11.2.5.C.01", - "11.2.6.C.01", - "11.2.7.C.01", - "11.2.7.C.02", - "11.2.8.C.01", - "11.2.9.C.01", - "11.2.10.C.01", "11.2.11.C.01", "11.2.11.C.02", - "11.2.11.C.03", - "11.2.11.C.04", - "11.2.11.C.05", "11.2.12.C.01", - "11.2.12.C.02", "11.2.13.C.01", - "11.2.13.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.1" + "11.8.3.C.01", + "11.8.7.C.01", + "11.8.8.C.01", + "11.8.13.C.01" ] } }, @@ -35905,7 +37463,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to issue personnel travelling overseas with temporary, loaner or \"travel-only\" end user technology (e.g., laptops and mobile devices) when travelling to authoritarian countries with a higher-than average risk for Intellectual Property (IP) theft or espionage against individuals and private companies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -35979,7 +37537,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -35988,9 +37547,10 @@ "03.04.12.b" ], "general-nist-800-171a-r3": [ - "A.03.04.12.a" + "A.03.04.12.a", + "A.03.04.12.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1088", "ISM-1298", "ISM-1299", @@ -36023,7 +37583,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to re-image end user technology (e.g., laptops and mobile devices) when returning from overseas travel to an authoritarian country with a higher-than average risk for Intellectual Property (IP) theft or espionage against individuals and private companies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36101,7 +37661,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -36111,7 +37672,7 @@ "general-nist-800-171a-r3": [ "A.03.04.12.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1300", "ISM-1556" ], @@ -36138,7 +37699,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to develop, implement and govern system administration processes, with corresponding Standardized Operating Procedures (SOP), for operating and maintaining Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36214,11 +37775,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0042", "ISM-1380", "ISM-1385" @@ -36254,7 +37816,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to conduct remote system administrative functions via a \"jump box\" or \"jump server\" that is located in a separate network zone to user workstations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36344,7 +37906,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -36352,6 +37915,11 @@ "03.01.12.a", "03.01.12.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.a[01]", + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" + ], "general-swift-cscf-2025": [ "1.5", "2.6" @@ -36362,14 +37930,11 @@ "emea-sau-cscc-1-2019": [ "2-3-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" - ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1387" ], @@ -36397,7 +37962,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to develop, implement and govern database management processes, with corresponding Standardized Operating Procedures (SOP), for operating and maintaining databases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36473,7 +38038,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -36483,7 +38049,7 @@ "emea-sau-cscc-1-2019": [ "2-2-1-8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0393", "ISM-1243", "ISM-1255", @@ -36508,17 +38074,7 @@ "5.5.3.C.01", "5.5.4.C.01", "5.5.5.C.01", - "5.5.6.C.01", - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" + "5.5.6.C.01" ] } }, @@ -36540,7 +38096,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Database administrators implement and maintain Database Management Systems (DBMSs), where applicable.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and maintain Database Management Systems (DBMSs), where applicable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36614,7 +38170,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -36624,7 +38181,7 @@ "usa-federal-dow-zt-roadmap-1-1": [ "4.4.6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1245", "ISM-1246", "ISM-1247", @@ -36632,18 +38189,6 @@ "ISM-1250", "ISM-1260", "ISM-1263" - ], - "apac-nzl-ism-3-9": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" ] } }, @@ -36665,7 +38210,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Enhanced security requirements for Bluetooth and wireless devices in sensitive/regulated areas are primarily administrative and preventative in nature.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely govern Radio Frequency Identification (RFID) deployments to ensure RFID is used safely and securely to protect the confidentiality and integrity of data and prevent the compromise of secure spaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36729,7 +38274,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -36757,10 +38303,7 @@ "11.6.68.C.01", "11.6.69.C.01", "11.6.70.C.01", - "11.6.71.C.01", - "11.6.72.C.01", - "11.6.72.C.02", - "11.6.72.C.03" + "11.6.71.C.01" ] } }, @@ -36782,7 +38325,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely configure contactless access control systems incorporating contactless RFID or smart cards to protect the confidentiality and integrity of data and prevent the compromise of secure spaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36846,7 +38389,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -36887,7 +38431,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT personnel collect technology assets and media for destruction when it is no longer needed for business or legal reasons.\n▪ Asset decommissioning consists of mainly wiping hard drives.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications and/or Services (TAAS) are properly decommissioned so that data is properly transitioned to new systems or archived in accordance with applicable organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -36973,7 +38517,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -36990,8 +38535,11 @@ "11-3.a(5)(a)", "11-3.a(5)(b)" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" + "apac-aus-ism-2026-march": [ + "ISM-2053" + ], + "apac-mys-bnm-rmit-2025": [ + "10.13" ], "apac-nzl-ism-3-9": [ "2.3.30.C.01", @@ -37008,7 +38556,9 @@ "13.1.13.C.02", "13.1.13.C.03", "13.1.13.C.04", - "13.1.14.C.01" + "13.1.14.C.01", + "20.2.15.C.03", + "20.2.15.C.06" ] } }, @@ -37032,7 +38582,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -37122,7 +38672,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -37132,6 +38683,9 @@ "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-sparta": [ "CM0022" ], @@ -37168,7 +38722,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize Artificial Intelligence (AI) and Autonomous Technologies (AAT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -37246,7 +38800,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -37276,7 +38831,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize a system and/or service as \"High Risk\" if it poses a significant risk of harm to an individual's:\n(1) Health;\n(2) Safety; and/or \n(3) Fundamental human rights.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -37325,7 +38880,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -37355,7 +38911,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to dynamically associate asset-specific attributes to enable Attribute-Based Access Control (ABAC).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -37410,7 +38966,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -37504,7 +39061,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -37619,7 +39177,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -37648,7 +39207,7 @@ "CC9.1-POF2" ], "general-cis-csc-8-1": [ - "11.0", + "11", "11.1" ], "general-cis-csc-8-1-ig1": [ @@ -37819,7 +39378,7 @@ "5.30", "8.13(a)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1485", "T1486", "T1490", @@ -37924,6 +39483,16 @@ "CP-1", "CP-2" ], + "general-nist-800-172-r3": [ + "03.04.04E", + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.03E[04]", + "A.03.04.03E.ODP[04]", + "DS-A.03.04.04E[04]", + "DS-A.03.08.04E[01]" + ], "general-nist-csf-2-0": [ "GV.SC-08", "ID.IM-04", @@ -38036,12 +39605,12 @@ "PM-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "CP-1", @@ -38104,18 +39673,14 @@ "CP-10" ], "emea-eu-eba-ict-srm-2025": [ - "3.7(77)", - "3.7.1(78)", - "3.7.1(79)", - "3.7.2(80)", - "3.7.2(81)", - "3.7.2(82)", - "3.7.3(83)", - "3.7.3(84)(a)", - "3.7.3(84)(b)", - "3.7.3(84)(c)", - "3.7.3(85)", - "3.7.3(86)" + "3.7.77", + "3.7.1.78", + "3.7.1.79", + "3.7.2.80", + "3.7.3.83", + "3.7.3.85", + "3.7.3.86", + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 11.1", @@ -38163,33 +39728,42 @@ "12.1.2(c)", "13.2.2(a)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ + "1.2(e)", "10.1", "10.2", "10.3", "10.5" ], "emea-deu-c5-2020": [ + "UP-01-BP4", + "RB-06", "BCM-01", "BCM-02", - "BCM-03" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.1" + "BCM-02-BP1", + "BCM-02-BP2", + "BCM-02-BP3", + "BCM-02-BP4", + "BCM-02-BP5", + "BCM-02-BP6", + "BCM-02-BP7", + "BCM-02-BP8", + "BCM-02-BP9", + "BCM-02-BP10", + "BCM-03", + "BCM-03-BP1", + "BCM-03-BP2", + "BCM-03-BP3", + "BCM-03-BP4", + "BCM-03-BP5", + "BCM-03-BP6", + "BCM-03-BP7", + "BCM-03-BP8" ], "emea-sau-cscc-1-2019": [ - "2-8", - "3-1", - "3-1-1-1", - "3-1-1-2" + "2-8-1", + "3-1-1", + "3-1-1-1" ], "emea-sau-cgiot-2024": [ "2-8-1", @@ -38197,49 +39771,29 @@ "3-1-1" ], "emea-sau-ecc-1-2018": [ - "2-4-4", - "2-9-1", "2-9-2", - "2-9-3", - "2-9-3-1", - "2-9-4", "3-1-1", "3-1-2", - "3-1-3", "3-1-3-1", "3-1-3-2", - "3-1-3-3", - "3-1-4" + "3-1-3-3" ], "emea-sau-otcc-1-2022": [ - "3-1", - "3-1-1", - "3-1-1-1", - "3-1-1-2", - "3-1-1-3", - "3-1-1-4", - "3-1-1-5", - "3-1-1-6", - "3-1-2" + "2-8-1", + "2-8-2", + "3-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-67", - "TPC-68", - "TPC-69" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 26" + "VII.B.TPC-64" ], "emea-esp-decree-311-2022": [ - "26" + "Article 12(6)(n)", + "Article 22(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.5.1 [OP.CONT.1]", - "7.5.2 [OP.CONT.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.4", @@ -38250,9 +39804,6 @@ "emea-gbr-caf-4-0": [ "B5.a" ], - "emea-gbr-cap-1850-2020": [ - "D1" - ], "emea-gbr-def-stan-05-138-2024": [ "2501", "2502", @@ -38271,22 +39822,13 @@ "2501", "4100" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0734" ], "apac-aus-ps-cps-230-2023": [ - "12(b)", "14", - "34(a)", + "15", "34(b)", - "34(c)", - "34(d)", - "34(e)", - "40(a)", - "40(b)", - "40(c)", - "40(d)", - "40(e)", "41" ], "apac-chn-cybersecurity-law-2017": [ @@ -38312,7 +39854,13 @@ "17.1.3.1", "17.1.3.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.6", + "10.24", + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP08", "HHSP24", "HHSP56", @@ -38321,9 +39869,6 @@ "HML24", "HML61" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS21" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP08", "HSUP22", @@ -38333,34 +39878,23 @@ "6.4.5.C.01", "6.4.7.C.01", "6.4.8.C.01", + "20.1.26.C.01", "23.4.12.C.01", "23.4.12.C.02" ], "apac-sgp-mas-trm-2021": [ - "8.1.1", - "8.1.2", - "8.1.3", - "8.1.4", - "8.2.1", - "8.2.2", - "8.2.3", - "8.2.4", - "8.5.1", - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" + "8.1.1" ], "americas-bmu-mba-coc-2020": [ - "6.14", + "6.3", "7.1" ], - "amaericas-can-osfi-self-assessment": [ - "2.9" - ], "americas-can-osfi-b13-2022": [ "2.9", "2.9.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } }, @@ -38386,7 +39920,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan development with internal and external elements responsible for related plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan development with internal and external elements responsible for related plans. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -38442,7 +39976,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -38520,11 +40055,16 @@ "emea-eu-nis2-annex-2024": [ "4.3.3" ], - "emea-isr-cmo-1-0": [ - "25.2" - ], "emea-sau-ecc-1-2018": [ "3-1-3-2" + ], + "emea-sau-otcc-1-2022": [ + "2-12-1-1" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ] } }, @@ -38548,7 +40088,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate internal contingency plans with the contingency plans of external service providers to ensure that contingency requirements can be satisfied.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -38623,7 +40163,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -38666,11 +40207,16 @@ "emea-sau-ecc-1-2018": [ "3-1-3-2" ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" + ], "apac-ind-sebi-2024": [ "GV.SC.S6" ], - "amaericas-can-osfi-self-assessment": [ - "2.9" + "apac-sgp-mas-trm-2021": [ + "8.3.4" ] } }, @@ -38694,7 +40240,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to redeploy personnel to other roles during a disruptive event or in the execution of a continuity plan.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -38764,7 +40310,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -38800,7 +40347,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to facilitate recovery operations in accordance with Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -38877,7 +40424,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -38941,6 +40489,13 @@ "CP-06(02)", "CP-10" ], + "general-nist-800-172-r3": [ + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.08.04E.ODP[01]", + "A.03.08.04E.ODP[02]" + ], "general-nist-csf-2-0": [ "RC.RP", "RC.RP-02", @@ -38983,6 +40538,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "CP-10" ], + "emea-eu-eba-ict-srm-2025": [ + "3.7.2.81" + ], "emea-eu-dora-2023": [ "Article 12.6" ], @@ -38991,31 +40549,36 @@ "4.2.2(a)" ], "emea-deu-c5-2020": [ - "OPS-06", - "OPS-08", - "OPS-09" + "BCM-02-BP6", + "BCM-02-BP8", + "BCM-02-BP9" ], "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "2-9-1" + ], + "emea-sau-otcc-1-2022": [ + "3-1-1-1" ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1810" ], "apac-aus-ps-cps-230-2023": [ + "38", "38(a)", - "38(b)", - "38(c)", - "39" + "38(b)" ], "apac-ind-sebi-2024": [ "RC.RP.S2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.32" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP24", "HML24" ], @@ -39023,7 +40586,6 @@ "HSUP22" ], "apac-sgp-mas-trm-2021": [ - "8.1.4", "8.2.1" ], "americas-can-osfi-b13-2022": [ @@ -39107,7 +40669,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -39130,9 +40693,16 @@ "emea-uae-niaf-2023": [ "3.4.2" ], + "apac-aus-ps-cps-230-2023": [ + "34(d)" + ], "apac-ind-sebi-2024": [ "RC.RP.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.24", + "10.32" + ], "americas-can-osfi-b13-2022": [ "2.9.1" ] @@ -39218,7 +40788,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -39236,6 +40807,9 @@ ], "emea-eu-nis2-annex-2024": [ "4.1.2(c)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.15" ] } }, @@ -39244,7 +40818,7 @@ "title": "Business Continuity & Disaster Recovery (BC/DR) Plans", "family": "BCD", "description": "Mechanisms exist for process owners to establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions.", - "scf_question": "Does the organization process owners to establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions?", + "scf_question": "Does the organization ensure process owners establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -39314,9 +40888,9 @@ "MT-10", "MT-11", "MT-24", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-cr-cmm-2026": [ @@ -39342,6 +40916,42 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "CP-02-SID" ], + "emea-eu-eba-ict-srm-2025": [ + "3.7.2.82", + "3.7.3.83", + "3.7.3.84", + "3.7.3.84(a)", + "3.7.3.84(b)", + "3.7.3.84(c)" + ], + "emea-sau-otcc-1-2022": [ + "3-1-1-3", + "3-1-1-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-67", + "VII.B.TPC-68", + "VII.B.TPC-68(a)", + "VII.B.TPC-68(b)", + "VII.B.TPC-68(c)", + "VII.B.TPC-68(d)", + "VII.B.TPC-68(e)", + "VII.B.TPC-68(f)", + "VII.B.TPC-68(g)", + "VII.B.TPC-68(h)", + "VII.B.TPC-68(i)", + "VII.B.TPC-69" + ], + "apac-aus-ps-cps-230-2023": [ + "16(e)", + "34(c)", + "40", + "40(a)", + "40(b)", + "40(c)", + "40(d)", + "40(e)" + ], "apac-jpn-ismap": [ "12.2.1.10", "12.2.1.11", @@ -39352,6 +40962,16 @@ "17.1.2.4", "17.1.2.5", "17.1.2.6" + ], + "apac-sgp-mas-trm-2021": [ + "8.2.2", + "8.2.3" + ], + "americas-bmu-mba-coc-2020": [ + "7.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } }, @@ -39434,7 +41054,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -39518,6 +41139,12 @@ "general-nist-800-161-r1-level-3": [ "CP-2(8)" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.10E" + ], "general-nist-csf-2-0": [ "GV.OC-04", "GV.OC-05", @@ -39526,9 +41153,6 @@ "RC.RP-02", "RC.RP-04" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -39557,10 +41181,10 @@ "CP-02(08)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-irs-1075-2021": [ "CP-2(CE-8)" @@ -39573,31 +41197,24 @@ "500.16(a)(2)(vi)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(78)", - "3.7.3(83)" + "3.3.2.16", + "3.7.1.78" ], "emea-eu-dora-2023": [ "Article 8.4" ], - "emea-deu-bsrit-2017": [ - "12.2" - ], "emea-deu-c5-2020": [ - "BCM-02" + "RB-12", + "BCM-02-BP4" ], "emea-sau-cscc-1-2019": [ + "2-1-1-1", "2-8-1-1", "3-1-1-2" ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" - ], "emea-sau-otcc-1-2022": [ "2-1-1-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-24" - ], "emea-uae-niaf-2023": [ "3.4" ], @@ -39607,27 +41224,28 @@ "emea-gbr-cap-1850-2020": [ "A4" ], + "apac-aus-ism-2026-march": [ + "ISM-2005" + ], "apac-aus-ps-cps-230-2023": [ + "15", "34(a)", - "35", - "36(a)", - "36(b)", - "36(c)", - "36(d)", - "37" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "35" ], "apac-ind-sebi-2024": [ "ID.AM.S4" ], - "apac-sgp-mas-trm-2021": [ - "8.1.2" + "apac-mys-bnm-rmit-2025": [ + "9.2", + "10.26", + "11.3" ], "americas-can-osfi-b13-2022": [ "2.2.2", "2.9.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } }, @@ -39726,7 +41344,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -39805,28 +41424,18 @@ "emea-eu-nis2-annex-2024": [ "4.1.2(h)" ], - "emea-isr-cmo-1-0": [ - "21.15", - "21.16" - ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" - ], "emea-uae-niaf-2023": [ "3.4.3" ], "apac-aus-ps-cps-230-2023": [ "34(e)" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP35", "HML35" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP31" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" ] } }, @@ -39921,7 +41530,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -39978,33 +41588,31 @@ "CP-02(05)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.16(a)(2)(iv)" ], - "emea-isr-cmo-1-0": [ - "18.15", - "25.23" - ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "emea-sau-otcc-1-2022": [ + "3-1-1-5" ], "apac-aus-ps-cps-230-2023": [ - "34(e)" + "34(e)", + "38(c)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.25", + "10.26" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP35", "HML35" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP31" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" ] } }, @@ -40026,9 +41634,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.\n▪ Business stakeholders and process owners define Recovery Time Objectives (RTOs) for business-critical TAASD.\n▪ Business stakeholders and process owners define Recovery Point Objectives (RPOs) for business-critical TAASD.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to resume essential missions and business functions within an organization-defined time period of contingency plan activation.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to resume essential missions and business functions within an organization-defined time period of contingency plan activation. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -40099,7 +41707,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -40167,18 +41776,15 @@ "emea-eu-nis2-annex-2024": [ "4.1.2(h)" ], - "emea-isr-cmo-1-0": [ - "21.15", - "21.16" + "emea-deu-c5-2020": [ + "BCM-02-BP7" ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "emea-sau-otcc-1-2022": [ + "3-1-1-5" ], "apac-aus-ps-cps-230-2023": [ - "34(e)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" + "34(e)", + "38(c)" ] } }, @@ -40186,8 +41792,8 @@ "control_id": "BCD-02.4", "title": "Data Storage Location Reviews", "family": "BCD", - "description": "Mechanisms exist to perform periodic security reviews of storage locations that contain sensitive/regulated data.", - "scf_question": "Does the organization perform periodic security reviews of storage locations that contain sensitive/regulated data?", + "description": "Mechanisms exist to perform periodic security reviews of storage locations that contain sensitive and/or regulated data.", + "scf_question": "Does the organization perform periodic security reviews of storage locations that contain sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -40202,7 +41808,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to perform periodic security reviews of storage locations that contain sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -40277,16 +41883,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF9" ], - "general-nist-800-172": [ - "3.14.5e" - ], "general-pci-dss-4-0-1": [ "9.4.1.2" ], @@ -40298,6 +41902,9 @@ ], "general-shared-assessments-sig-2025": [ "F.1" + ], + "emea-deu-c5-2020": [ + "BCM-05" ] } }, @@ -40321,9 +41928,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to adequately train contingency personnel and applicable stakeholders in their contingency roles and responsibilities.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to adequately train contingency personnel and applicable stakeholders in their contingency roles and responsibilities. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -40393,7 +42000,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -40486,9 +42094,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CP-03" - ], - "emea-isr-cmo-1-0": [ - "25.3" ] } }, @@ -40512,7 +42117,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to incorporate simulated events into contingency training to facilitate effective response by personnel in crisis situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -40562,7 +42167,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -40608,18 +42214,12 @@ "usa-federal-gsa-fedramp-5-high": [ "CP-03(01)" ], - "emea-isr-cmo-1-0": [ - "25.4", - "25.5" - ], "emea-sau-cscc-1-2019": [ "3-1-1-4" ], - "emea-sau-otcc-1-2022": [ - "3-1-1-6" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-sgp-mas-trm-2021": [ + "13.5.1", + "13.5.2" ] } }, @@ -40688,7 +42288,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -40703,9 +42304,6 @@ ], "general-nist-800-82-r3": [ "CP-03(02)" - ], - "emea-isr-cmo-1-0": [ - "25.8" ] } }, @@ -40732,7 +42330,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to conduct tests and/or exercises to evaluate the contingency plan's effectiveness and the organization's readiness to execute the plan.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to conduct tests and/or exercises to evaluate the contingency plan's effectiveness and the organization's readiness to execute the plan. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -40802,7 +42400,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -40932,10 +42531,10 @@ "CP-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "CP-4" @@ -40967,12 +42566,12 @@ "CP-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(87)", - "3.7.4(89)", - "3.7.4(89)(a)", - "3.7.4(89)(b)", - "3.7.4(89)(c)", - "3.7.4(90)" + "3.7.4.87", + "3.7.4.89", + "3.7.4.89(a)", + "3.7.4.89(b)", + "3.7.4.89(c)", + "3.7.4.90" ], "emea-eu-dora-2023": [ "Article 11.4", @@ -40992,28 +42591,29 @@ "4.3.4" ], "emea-deu-bsrit-2017": [ - "10.4" + "10.4", + "10.5" ], "emea-deu-c5-2020": [ - "PS-02", - "PS-06", - "BCM-04" + "PS-03-BP6", + "BCM-04", + "BCM-04-DOAR", + "BCM-05-DOAR" ], - "emea-isr-cmo-1-0": [ - "25.4", - "25.6", - "25.7", - "25.9", - "25.23" + "emea-sau-cscc-1-2019": [ + "3-1-1-3", + "3-1-1-4" ], "emea-sau-otcc-1-2022": [ "3-1-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-70" + "VII.B.TPC-70" ], - "emea-esp-ccn-stic-825-2023": [ - "7.5.3 [OP.CONT.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.4.1" @@ -41028,10 +42628,9 @@ "2503" ], "apac-aus-ps-cps-230-2023": [ + "27(c)", "43", - "44", - "45", - "46" + "44" ], "apac-chn-cybersecurity-law-2017": [ "Article 34(4)" @@ -41047,18 +42646,22 @@ "17.1.3.3" ], "apac-sgp-mas-trm-2021": [ - "8.2.3", + "8.2.4", "8.3.1", "8.3.2", + "8.3.3", "8.3.3(a)", "8.3.3(b)", - "8.3.4" + "13.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "americas-bmu-mba-coc-2020": [ + "7.1-BP2" ], "americas-can-osfi-b13-2022": [ "2.9.3" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.3" ] } }, @@ -41080,9 +42683,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan testing with internal and external elements responsible for related plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan testing with internal and external elements responsible for related plans. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -41134,7 +42737,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -41182,16 +42786,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-4(1)" - ], - "emea-isr-cmo-1-0": [ - "25.6", - "25.7" - ], - "apac-sgp-mas-trm-2021": [ - "8.3.4" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" ] } }, @@ -41215,7 +42809,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A dedicated alternate site(s) is/are equipped to be compatible with the production network's processing, storage, connectivity and other infrastructure needs.\n▪ Alternate sites are given priority of service to meet applicable RTOs and/or RPOs.\n▪ RTOs are used to identify business-critical TAASD, which are given priority of service in alternate processing and storage sites.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to test contingency plans at alternate storage & processing sites to both familiarize contingency personnel with the facility and evaluate the capabilities of the alternate processing site to support contingency operations.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to test contingency plans at alternate storage & processing sites to both familiarize contingency personnel with the facility and evaluate the capabilities of the alternate processing site to support contingency operations. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -41286,7 +42880,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -41320,11 +42915,11 @@ "emea-eu-nis2-annex-2024": [ "4.2.2(c)" ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], "apac-sgp-mas-trm-2021": [ - "8.2.4" + "8.5.2", + "8.5.2(a)", + "8.5.2(b)", + "8.5.4" ] } }, @@ -41420,7 +43015,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -41512,10 +43108,10 @@ "CP-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "CP-4" @@ -41537,8 +43133,9 @@ "CP-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(88)", - "3.7.4(90)" + "3.7.3.84(c)", + "3.7.4.88", + "3.7.4.90" ], "emea-eu-dora-2023": [ "Article 13.2", @@ -41551,11 +43148,9 @@ "emea-eu-nis2-annex-2024": [ "4.1.4" ], - "emea-deu-c5-2020": [ - "BCM-04" - ], - "emea-gbr-cap-1850-2020": [ - "D2" + "apac-aus-ps-cps-230-2023": [ + "32", + "45" ], "apac-ind-sebi-2024": [ "RC.IM.S1", @@ -41565,20 +43160,12 @@ "RS.AN.S4b", "RS.IM.S1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP64", "HML63" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP56" - ], - "apac-sgp-mas-trm-2021": [ - "7.8.1", - "7.8.2", - "7.8.3" - ], - "amaericas-can-osfi-self-assessment": [ - "5.9" ] } }, @@ -41602,7 +43189,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Production TAASD support business-critical application and services failover.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to develop BC/DR plans to recover business-critical TAASD.\n▪ Data/process owners conduct a Business Impact Analysis (BIA) at least annually, or after any major technology or process change, to identify TAASD that are critical to the business, as well as single points of failure.\n▪ Business stakeholders and process owners designate alternative decision-makers if primary decision-makers are unavailable.\n▪ Within the BC/DR plans, alternate communications channels are defined if primary means of communication are unavailable.\n▪ RTOs are used to identify business-critical TAASD, which are given priority of service in alternate processing and storage sites.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to update contingency plans due to changes affecting:\n(1) People (e.g., personnel changes);\n(2) Processes (e.g., new, altered or decommissioned business practices, including third-party services)\n(3) Technologies (e.g., new, altered or decommissioned technologies);\n(4) Data (e.g., changes to data flows and/or data repositories);\n(5) Facilities (e.g., new, altered or decommissioned physical infrastructure); and/or\n(6) Feedback from contingency plan testing activities.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -41657,7 +43244,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -41781,14 +43369,14 @@ "CP-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(88)", - "3.7.4(90)" + "3.7.4.88", + "3.7.4.90" ], "emea-deu-c5-2020": [ "BCM-04" ], - "emea-sau-ecc-1-2018": [ - "3-1-4" + "apac-aus-ps-cps-230-2023": [ + "45" ] } }, @@ -41797,7 +43385,7 @@ "title": "Contingency Planning Components", "family": "BCD", "description": "Mechanisms exist to identify components that potentially impact the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure.", - "scf_question": "Does the organization identify components that potentially impacts the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure?", + "scf_question": "Does the organization identify components that potentially impact its ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -41812,7 +43400,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify components that potentially impacts the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -41864,7 +43452,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -41877,6 +43466,9 @@ ], "usa-federal-nerc-cip-2024": [ "CIP-009-6 3.2" + ], + "apac-aus-ps-cps-230-2023": [ + "45" ] } }, @@ -41900,7 +43492,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to keep stakeholders informed of changes to contingency plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to keep stakeholders informed of changes to contingency plans.\n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -41948,7 +43540,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -41978,9 +43571,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -42036,7 +43629,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -42078,9 +43672,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate storage site that includes both the assets and necessary agreements to permit the storage and recovery of system backup information.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate storage site that includes both the assets and necessary agreements to permit the storage and recovery of system backup information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -42142,7 +43736,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -42171,7 +43766,7 @@ "general-iso-27018-2025": [ "8.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -42253,22 +43848,8 @@ "emea-deu-bsrit-2017": [ "10.5" ], - "emea-deu-c5-2020": [ - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.7", - "25.10" - ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.4.4 [MP.COM.4]", - "8.8.4 [MP.S.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" ] } }, @@ -42290,7 +43871,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to separate the alternate storage site from the primary storage site to reduce susceptibility to similar threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -42332,9 +43913,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -42387,12 +43968,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-6(1)" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.11" ] } }, @@ -42401,7 +43976,7 @@ "title": "Primary Storage Site Accessibility", "family": "BCD", "description": "Mechanisms exist to identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster.", - "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster?", + "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -42414,7 +43989,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -42476,9 +44051,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -42522,9 +44097,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-6(3)" - ], - "emea-isr-cmo-1-0": [ - "25.13" ] } }, @@ -42546,7 +44118,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate processing site that provides security measures equivalent to that of the primary site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -42610,7 +44182,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -42645,7 +44218,7 @@ "general-iso-27018-2025": [ "8.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -42743,21 +44316,8 @@ "emea-deu-bsrit-2017": [ "10.5" ], - "emea-deu-c5-2020": [ - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.7", - "25.10" - ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.8.4 [MP.S.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" ], "apac-jpn-ismap": [ "17.2", @@ -42786,7 +44346,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to separate the alternate processing site from the primary processing site to reduce susceptibility to similar threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -42828,9 +44388,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -42877,12 +44437,6 @@ ], "emea-eu-dora-2023": [ "Article 12.5(a)" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.11" ] } }, @@ -42891,7 +44445,7 @@ "title": "Alternate Processing Site Accessibility", "family": "BCD", "description": "Mechanisms exist to identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster.", - "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate processing site and possible mitigation actions, in the event of an area-wide disruption or disaster?", + "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -42904,7 +44458,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -42964,9 +44518,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -43012,19 +44566,16 @@ "CP-07(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "CP-7(2)" ], "emea-eu-dora-2023": [ "Article 12.5(c)" - ], - "emea-isr-cmo-1-0": [ - "25.13" ] } }, @@ -43048,9 +44599,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to address priority-of-service provisions in alternate processing and storage sites that support availability requirements, including Recovery Time Objectives (RTOs).", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to address priority-of-service provisions in alternate processing and storage sites that support availability requirements, including Recovery Time Objectives (RTOs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -43104,7 +44655,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -43149,10 +44701,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-7(3)" - ], - "emea-isr-cmo-1-0": [ - "25.12", - "21.14" ] } }, @@ -43230,7 +44778,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -43265,7 +44814,7 @@ "title": "Inability to Return to Primary Site", "family": "BCD", "description": "Mechanisms exist to plan and prepare for both natural and manmade circumstances that preclude returning to the primary site.", - "scf_question": "Does the organization plan and prepare for both natural and manmade circumstances that preclude returning to the primary processing site?", + "scf_question": "Does the organization plan and prepare for both natural and manmade circumstances that preclude returning to the primary site?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -43278,7 +44827,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to plan and prepare for both natural and manmade circumstances that preclude returning to the primary site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -43336,9 +44885,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-nist-800-53-r4": [ @@ -43370,7 +44919,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to reduce the likelihood of a single point of failure with primary telecommunications services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -43426,7 +44975,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -43518,13 +45068,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CP-08" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" - ], - "emea-isr-cmo-1-0": [ - "21.14", - "25.16" ] } }, @@ -43548,9 +45091,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to formalize primary and alternate telecommunications service agreements contain priority-of-service provisions that support availability requirements, including Recovery Time Objectives (RTOs).", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to formalize primary and alternate telecommunications service agreements contain priority-of-service provisions that support availability requirements, including Recovery Time Objectives (RTOs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -43587,7 +45130,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -43637,10 +45181,6 @@ "CP-8(1)", "CP-8(1).a", "CP-8(1).b" - ], - "emea-isr-cmo-1-0": [ - "21.14", - "25.17" ] } }, @@ -43662,9 +45202,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -43718,7 +45258,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -43778,7 +45319,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to contractually-require external service providers to have contingency plans that meet organizational contingency requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -43836,7 +45377,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -43877,7 +45419,7 @@ "CP-08(04)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.3(86)" + "3.7.3.86" ] } }, @@ -43951,7 +45493,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -43989,10 +45532,13 @@ "CM0070" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-nis2-annex-2024": [ "4.3.2(b)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.15" ] } }, @@ -44084,7 +45630,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -44154,7 +45701,7 @@ "general-iso-27018-2025": [ "8.13" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1005", @@ -44227,6 +45774,9 @@ "general-nist-800-171a": [ "3.8.9" ], + "general-nist-800-171a-r3": [ + "A.03.08.09.a" + ], "general-nist-csf-2-0": [ "PR.DS-11" ], @@ -44314,13 +45864,16 @@ "CP-09", "SC-28(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(g)(4)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "CP-9" @@ -44355,7 +45908,7 @@ "CP-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(57)" + "3.5.57" ], "emea-eu-dora-2023": [ "Article 12.1", @@ -44377,12 +45930,14 @@ "8.7" ], "emea-deu-c5-2020": [ - "OPS-06" + "RB-06", + "RB-07" ], - "emea-isr-cmo-1-0": [ - "25.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 14.1" ], "emea-sau-cscc-1-2019": [ + "2-8-1-1", "2-8-1-2", "2-8-1-3" ], @@ -44391,28 +45946,22 @@ "2-8-2" ], "emea-sau-ecc-1-2018": [ - "2-9-3" + "2-4-3-3", + "2-9-3-1", + "2-9-3-2" ], "emea-sau-otcc-1-2022": [ - "2-8", - "2-8-1", "2-8-1-1", - "2-8-1-2", - "2-8-1-3", - "2-8-1-4", - "2-8-2" + "2-8-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-64" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 26" + "VII.B.TPC-64" ], "emea-esp-decree-311-2022": [ - "26" + "Article 26" ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.7 [MP.INFO.7]" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-caf-4-0": [ "B5.c" @@ -44435,9 +45984,7 @@ "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", + "apac-aus-ism-2026-march": [ "ISM-1511", "ISM-1547", "ISM-1548", @@ -44470,7 +46017,10 @@ "12.3.1.21.P", "12.3.1.24.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP17", "HHSP56", "HHSP69", @@ -44478,9 +46028,6 @@ "HML56", "HML68" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP15", "HSUP48", @@ -44493,12 +46040,19 @@ "8.4.1", "8.4.2" ], + "americas-arg-ppd-2018": [ + "D", + "D.1.1-1" + ], "americas-bmu-mba-coc-2020": [ "6.14" ], "americas-can-osfi-b13-2022": [ "2.9.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" + ], "americas-can-itsp-10-171-2025": [ "03.08.09.A" ] @@ -44526,7 +46080,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ A random sampling of backups is tested at least annually to verify integrity and recoverability of backed up data.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel perform a random sampling of backups is tested at least semi-annually to verify integrity and recoverability of backed up data.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to routinely test backups that verify the reliability of the backup process, as well as the integrity and availability of the data.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to routinely test backups that verify the reliability of the backup process, as well as the integrity and availability of the data. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -44571,7 +46125,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -44649,6 +46204,13 @@ "general-nist-800-160-vol-2-r1": [ "CP-09(01)" ], + "general-nist-800-172-r3": [ + "03.08.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.03E[01]", + "DS-A.03.08.03E[02]" + ], "general-nist-csf-2-0": [ "PR.DS-11" ], @@ -44689,13 +46251,7 @@ "4.2.2(b)" ], "emea-deu-c5-2020": [ - "OPS-06", - "OPS-07", - "OPS-08" - ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.19" + "RB-07" ], "emea-sau-cscc-1-2019": [ "2-8-2" @@ -44706,6 +46262,9 @@ "emea-sau-ecc-1-2018": [ "2-9-3-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" + ], "emea-gbr-def-stan-05-138-2024": [ "2504", "2505" @@ -44719,27 +46278,29 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2505" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1515" ], "apac-ind-sebi-2024": [ "PR.IP.S8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP57", "HHSP69", "HML57", "HML68" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP49", "HSUP60" ], - "apac-sgp-mas-trm-2021": [ - "8.4.3" + "americas-arg-ppd-2018": [ + "D.1.1-2", + "D.1.1-3", + "D.1.2-4" ] } }, @@ -44826,7 +46387,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -44919,23 +46481,22 @@ "CP-09(3)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(58)" + "3.5.58" ], "emea-eu-dora-2023": [ "Article 12.3" ], "emea-deu-c5-2020": [ - "OPS-06", - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "25.20" + "RB-09" ], "emea-sau-otcc-1-2022": [ - "2-8-1-4" + "2-8-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-38" + "VII.B.TPC-65" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-def-stan-05-138-2024": [ "2505" @@ -44951,7 +46512,7 @@ "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1811" ], "apac-jpn-ismap": [ @@ -44959,6 +46520,15 @@ "12.3.1.6", "12.3.1.7", "12.3.1.23.P" + ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-sgp-mas-trm-2021": [ + "8.4.4" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-2" ] } }, @@ -45026,7 +46596,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -45036,12 +46607,8 @@ "general-cr-cmm-2026": [ "CR10.2.6" ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.12", - "25.22" + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } }, @@ -45117,7 +46684,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -45239,8 +46807,8 @@ "CP-09 (08)", "SC-28 (01)" ], - "emea-isr-cmo-1-0": [ - "25.18" + "emea-deu-c5-2020": [ + "RB-06-DOAR" ], "emea-sau-cscc-1-2019": [ "2-8-1-3" @@ -45249,7 +46817,11 @@ "2-8-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-65" + "VII.B.TPC-50", + "VII.B.TPC-65" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-def-stan-05-138-2024": [ "2506" @@ -45260,12 +46832,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2506" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" + "apac-mys-bnm-rmit-2025": [ + "10.45" ], "apac-sgp-mas-trm-2021": [ "8.4.4" ], + "americas-arg-ppd-2018": [ + "D.1.2-2" + ], "americas-can-itsp-10-171-2025": [ "03.08.09.A", "03.08.09.B" @@ -45292,9 +46867,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel perform a random sampling of backups is tested at least semi-annually to verify integrity and recoverability of backed up data.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize sampling of available backups to test recovery capabilities as part of business continuity plan testing.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize sampling of available backups to test recovery capabilities as part of business continuity plan testing. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -45345,7 +46920,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -45408,8 +46984,8 @@ "Article 12.2", "Article 12.7" ], - "emea-sau-cscc-1-2019": [ - "3-1-1-3" + "emea-deu-c5-2020": [ + "RB-08" ], "emea-sau-cgiot-2024": [ "2-8-3" @@ -45434,6 +47010,12 @@ "12.3.1.10", "12.3.1.20.P", "12.3.1.22.P" + ], + "apac-sgp-mas-trm-2021": [ + "8.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "6.14" ] } }, @@ -45457,7 +47039,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to transfer backup data to the alternate storage site at a rate that is capable of meeting both Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -45519,7 +47101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -45560,7 +47143,7 @@ "Article 12.3" ], "emea-sau-otcc-1-2022": [ - "2-8-1-4" + "2-8-1-1" ], "emea-gbr-def-stan-05-138-2024": [ "2506" @@ -45591,7 +47174,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to maintain a failover capability, which is not collocated with the primary Technology Asset, Application and/or Service (TAAS), which can be activated with little-to-no loss of information or disruption to operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45651,7 +47234,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -45691,11 +47275,19 @@ "4.2.4(d)", "13.1.2(b)" ], - "emea-deu-c5-2020": [ - "PS-02" - ], "emea-sau-otcc-1-2022": [ "3-1-1-2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" + ], + "apac-mys-bnm-rmit-2025": [ + "10.25", + "10.26" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.2", + "8.5.2(c)" ] } }, @@ -45717,7 +47309,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to enforce dual authorization for the deletion or destruction of sensitive backup media and data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45772,7 +47364,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -45790,6 +47383,12 @@ ], "general-nist-800-160-vol-2-r1": [ "CP-09(07)" + ], + "general-nist-800-172-r3": [ + "03.08.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.02E" ] } }, @@ -45811,7 +47410,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restrict access to backups to privileged users with assigned roles for data backup and recovery operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45863,7 +47462,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -45876,13 +47476,21 @@ "emea-eu-nis2-annex-2024": [ "4.2.2(d)" ], - "emea-sau-sacs-002-2022": [ - "TPC-50" + "emea-sau-cscc-1-2019": [ + "2-8-1-3" ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" + ], + "apac-aus-ism-2026-march": [ + "ISM-1812", + "ISM-1813", + "ISM-1814" + ], + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } }, @@ -45956,16 +47564,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { + "emea-sau-cscc-1-2019": [ + "2-8-1-3" + ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-aus-ism-2026-march": [ + "ISM-1814" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP56", "HML56" ], @@ -45994,7 +47609,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to ensure the secure recovery and reconstitution of Technology Assets, Applications and/or Services (TAAS) to a known state after a disruption, compromise or failure.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -46070,7 +47685,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -46129,7 +47745,7 @@ "general-iec-62443-4-2-2019": [ "CR 7.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1485", "T1485.001", "T1486", @@ -46170,6 +47786,12 @@ "general-nist-800-82-r3-high": [ "CP-10" ], + "general-nist-800-172-r3": [ + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.04E[02]" + ], "general-nist-csf-2-0": [ "RC", "RC.RP-01", @@ -46191,10 +47813,10 @@ "CP-10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "CP-10" @@ -46217,29 +47839,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "CP-10" ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.3(83)" - ], "emea-eu-nis2-2022": [ "Article 21.2(c)" ], "emea-eu-nis2-annex-2024": [ "4.2.2(e)" ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.12", - "25.22" - ], "emea-sau-cscc-1-2019": [ "2-8-2" ], "emea-sau-cgiot-2024": [ "2-12-2" ], - "emea-sau-ecc-1-2018": [ - "2-4-3-3" - ], "emea-gbr-def-stan-05-138-2024": [ "4202" ], @@ -46249,12 +47860,19 @@ "apac-ind-sebi-2024": [ "PR.IP.S7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.45" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP17", "HML17" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP15" + ], + "americas-arg-ppd-2018": [ + "D.1.2-3", + "D.1.2-DS-4" ] } }, @@ -46348,7 +47966,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -46397,12 +48016,8 @@ "usa-federal-irs-1075-2021": [ "CP-10(CE-2)" ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.21" - ], - "emea-sau-ecc-1-2018": [ - "2-4-3-3" + "usa-federal-cms-marse-2-0": [ + "CP-10(2)" ] } }, @@ -46496,7 +48111,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -46548,13 +48164,6 @@ "emea-eu-dora-2023": [ "Article 12.4" ], - "emea-isr-cmo-1-0": [ - "12.26", - "25.12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], "emea-gbr-def-stan-05-138-2024": [ "4202" ], @@ -46581,7 +48190,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize electronic discovery (eDiscovery) that covers current and archived communication transactions.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -46627,7 +48236,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -46661,7 +48271,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ Backups are performed ad-hoc and focus on business-critical Technology Assets, Applications, Services and/or Data (TAASD).\n▪ IT and/or cybersecurity personnel use a backup methodology (e.g., grandfather, father & son rotation) to create backups to support business needs (e.g., Recovery Time Objectives).", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restore TAASD within organization-defined restoration time-periods from configuration-controlled and integrity-protected information; representing a known, operational state for the asset.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restore TAASD within organization-defined restoration time-periods from configuration-controlled and integrity-protected information; representing a known, operational state for the asset. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -46721,7 +48331,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -46853,7 +48464,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -46897,9 +48509,8 @@ "4.2.2(e)", "4.2.3" ], - "emea-isr-cmo-1-0": [ - "25.12", - "25.18" + "americas-arg-ppd-2018": [ + "D.1.2-DS-4" ] } }, @@ -46924,7 +48535,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to verify the integrity of backups and other restoration assets prior to using them for restoration.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46976,7 +48587,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -47009,7 +48621,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize an isolated, non-production environment to perform data backup and recovery operations through offline, cloud or off-site capabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -47061,7 +48673,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -47082,6 +48695,12 @@ ], "general-shared-assessments-sig-2025": [ "K.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.45" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-4" ] } }, @@ -47103,7 +48722,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to purchase and maintain a sufficient reserve of spare hardware to ensure essential missions and business functions can be maintained in the event of a supply chain disruption.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -47185,7 +48804,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -47193,7 +48813,7 @@ "RESPONSE-4c", "RESPONSE-4l" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1789" ] } @@ -47304,7 +48924,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -47340,7 +48961,7 @@ "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to facilitate the implementation of capacity management controls to ensure optimal system performance to meet expected and anticipated future capacity requirements.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -47396,7 +49017,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -47481,6 +49103,12 @@ "general-nist-800-160-vol-2-r1": [ "SC-05(03)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -47511,6 +49139,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(1)" + ], "usa-federal-cms-marse-2-0": [ "SC-5" ], @@ -47527,34 +49158,23 @@ "SC-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(56)" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "3.5.56" ], "emea-deu-bsrit-2017": [ "8.8" ], "emea-deu-c5-2020": [ - "OPS-01", - "OPS-02", - "OPS-03" - ], - "emea-isr-cmo-1-0": [ - "25.2" + "RB-01" ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" + "emea-sau-otcc-1-2022": [ + "3-1-1", + "3-1-2" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.4 [OP.PL.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.4", + "mp.s.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" @@ -47573,7 +49193,10 @@ "12.1.3.7", "12.1.3.8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP61", "HML61" ], @@ -47581,14 +49204,17 @@ "HSUP53" ], "apac-sgp-mas-trm-2021": [ - "8.1.1" + "6.4.8" ], "americas-bmu-mba-coc-2020": [ - "6.1" + "6.1-BP5" ], "americas-can-osfi-b13-2022": [ "2", "2.8.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.8.2" ] } }, @@ -47616,7 +49242,7 @@ "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to control resource utilization of Technology Assets, Applications and/or Services (TAAS) that are susceptible to Denial of Service (DoS) attacks to limit and prioritize the use of resources.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -47662,7 +49288,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -47691,7 +49318,7 @@ "SC-05", "SC-06" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1564.009" ], "general-nist-800-53-r4": [ @@ -47738,6 +49365,12 @@ "general-nist-800-161-r1-level-2": [ "SC-5(2)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -47776,10 +49409,22 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-05" ], - "apac-aus-ism-2024-june": [ + "emea-isr-cmo-2-0": [ + "Appendix A, 7.1" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-92" + ], + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" + ], + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-sgp-mas-trm-2021": [ + "6.4.8" ] } }, @@ -47803,11 +49448,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", - "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support will exist during contingency operations.", + "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support will exist during contingency operations. ", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -47855,7 +49500,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -47945,6 +49591,12 @@ "general-nist-800-161-r1-level-3": [ "CP-2(2)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -47991,20 +49643,20 @@ "8.8" ], "emea-deu-c5-2020": [ - "OPS-01", - "OPS-02", - "OPS-03" + "RB-01", + "RB-01-DOAR" ], - "emea-isr-cmo-1-0": [ - "25.2" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.4", + "mp.s.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" ], - "apac-sgp-mas-trm-2021": [ - "8.1.3" + "apac-mys-bnm-rmit-2025": [ + "10.29" ], "americas-can-osfi-b13-2022": [ "2.8.2" @@ -48031,11 +49683,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to automatically centrally-monitor and alert on the operating state and health status of critical Technology Assets, Applications and/or Services (TAAS).", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -48097,7 +49749,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -48113,14 +49766,24 @@ "emea-deu-bsrit-2017": [ "8.8" ], + "emea-deu-c5-2020": [ + "RB-02" + ], "apac-ind-sebi-2024": [ "DE.CM.S4" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" + "apac-mys-bnm-rmit-2025": [ + "10.30", + "10.39" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.3" ], "americas-can-osfi-b13-2022": [ "2.8.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.8.2" ] } }, @@ -48144,11 +49807,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to automatically scale the resources available for Technology Assets, Applications and/or Services (TAAS), as demand conditions change.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -48205,7 +49868,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -48218,8 +49882,17 @@ "usa-federal-dow-zt-roadmap-1-1": [ "7.1.1" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "RB-02" + ], + "apac-aus-ism-2026-march": [ "ISM-1579" + ], + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.4" ] } }, @@ -48245,7 +49918,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to support operations that are geographically dispersed via regional delivery of technological Technology Assets, Applications and/or Services (TAAS).", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -48300,7 +49973,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -48427,7 +50101,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -48551,15 +50226,15 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.d" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.d[01]", "A.03.04.03.d[02]" ], - "general-nist-800-172": [ - "3.13.2e" - ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -48642,10 +50317,10 @@ "314.4(c)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "CM-3" @@ -48674,9 +50349,8 @@ "CM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "emea-eu-dora-2023": [ "Article 9.4(e)" @@ -48688,51 +50362,35 @@ "6.6.1", "6.10.2(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "8.4" ], "emea-deu-c5-2020": [ - "DEV-03", - "DEV-08" + "BEI-03", + "BEI-03-BP1", + "BEI-03-BP2", + "BEI-05", + "BEI-06", + "BEI-08" ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.6", - "14.7" + "emea-sau-cscc-1-2019": [ + "1-3-1" ], "emea-sau-cgiot-2024": [ "1-5-3" ], - "emea-sau-ecc-1-2018": [ - "1-6-2" - ], "emea-sau-otcc-1-2022": [ - "1-5", "1-5-1", - "1-5-2" + "1-5-2", + "1-5-3" ], "emea-sau-sama-csf-1-2017": [ - "3.3.7" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.1" - ], - "emea-esp-decree-311-2022": [ - "21.1" + "3.3.7", + "3.3.7.1", + "3.3.7.4" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.5 [OP.EXP.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], "emea-gbr-def-stan-05-138-2024": [ "2404" @@ -48746,7 +50404,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2404" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1211" ], "apac-ind-sebi-2024": [ @@ -48758,7 +50416,10 @@ "12.1.2.1", "12.1.2.11.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.11" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP18", "HML18" ], @@ -48769,29 +50430,26 @@ "6.3.6.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.5.1", - "7.5.2", - "7.5.3", - "7.5.4", - "7.5.5", - "7.5.6", - "7.5.7" + "7.5.1" ], - "americas-bmu-mba-coc-2020": [ - "6.1" + "americas-arg-ppd-2018": [ + "C", + "C.1.1-2" ], - "amaericas-can-osfi-self-assessment": [ - "4.17", - "4.20", - "6.11" + "americas-bmu-mba-coc-2020": [ + "6.1-BP2" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.A" + "03.04.03.A", + "03.04.03.D" ] } }, @@ -48891,7 +50549,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -48970,7 +50629,7 @@ "general-iso-42001-2023": [ "6.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.005", "T1059.006", "T1176", @@ -49056,7 +50715,8 @@ "03.04.02.b", "03.04.03.a", "03.04.03.b", - "03.04.03.c" + "03.04.03.c", + "03.07.05.a" ], "general-nist-800-171a": [ "3.4.3[a]", @@ -49065,8 +50725,11 @@ "3.4.3[d]" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", "A.03.04.03.a", - "A.03.04.03.c[01]" + "A.03.04.03.b[02]", + "A.03.04.03.c[01]", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -49099,9 +50762,6 @@ "6.5.6", "12.4.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-tisax-6-0-3": [ "5.2.1" ], @@ -49170,9 +50830,8 @@ "CM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "emea-eu-dora-2023": [ "Article 9.4(e)" @@ -49185,32 +50844,23 @@ "8.5" ], "emea-deu-c5-2020": [ - "DEV-08" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.7" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3-5" + "BEI-08", + "BEI-09-DOAR" ], "emea-sau-otcc-1-2022": [ - "1-5", - "1-5-1", - "1-5-2", - "1-5-3", - "1-5-3-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "1-5-3-1", + "1-5-3-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.1" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.c", + "3.3.7.4.d", + "3.3.7.4.e", + "3.3.7.4.i" ], - "emea-esp-decree-311-2022": [ - "21.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1211" ], "apac-ind-sebi-2024": [ @@ -49263,7 +50913,12 @@ "14.2.4.9", "14.2.4.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.11", + "10.18", + "10.27" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP18", "HML18" ], @@ -49276,20 +50931,27 @@ "6.3.7.C.02", "6.3.7.C.03" ], - "amaericas-can-osfi-self-assessment": [ - "4.18", - "4.20" + "apac-sgp-mas-trm-2021": [ + "7.5.2", + "7.5.4" + ], + "americas-arg-ppd-2018": [ + "C.1.1-DS" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1", "2.5.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", "03.04.03.A", "03.04.03.B", - "03.04.03.C" + "03.04.03.C", + "03.07.05.A" ] } }, @@ -49387,7 +51049,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -49440,11 +51103,16 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.b", + "03.07.05.a" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.b[02]", - "A.03.04.05[05]" + "A.03.04.05[05]", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -49484,21 +51152,10 @@ "7123(c)(5)(E)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "emea-deu-c5-2020": [ - "IDM-02" - ], - "emea-isr-cmo-1-0": [ - "14.7" - ], - "emea-sau-otcc-1-2022": [ - "1-5-3-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "BEI-12" ], "apac-jpn-ismap": [ "14.2.4", @@ -49509,16 +51166,26 @@ "14.2.4.5", "14.2.4.6" ], + "apac-nzl-ism-3-9": [ + "20.2.15.C.02", + "20.2.15.C.05" + ], "apac-sgp-mas-trm-2021": [ - "7.5.4" + "7.5.2" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1", + "2.5.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.A" + "03.04.03.A", + "03.04.03.B", + "03.07.05.A" ] } }, @@ -49616,7 +51283,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -49718,7 +51386,18 @@ "03.04.11.b" ], "general-nist-800-171a-r3": [ - "A.03.04.03.c[02]" + "A.03.04.03.b[02]", + "A.03.04.03.c[02]", + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.04.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.07E[01]", + "DS-A.03.04.07E[03]" ], "general-nist-csf-2-0": [ "ID.RA-07" @@ -49792,39 +51471,25 @@ "CM-03 (02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "emea-deu-c5-2020": [ - "DEV-06", - "DEV-08", - "DEV-09" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "12.21", - "12.30", - "14.6", - "14.8", - "14.9", - "14.10" - ], - "emea-sau-cscc-1-2019": [ - "1-3-1-2" + "BEI-03-BP3", + "BEI-03-BP4", + "BEI-07", + "BEI-09" ], "emea-sau-cgiot-2024": [ "1-5-3" ], - "emea-sau-ecc-1-2018": [ - "1-6-2-1", - "1-6-3-5" - ], "emea-sau-otcc-1-2022": [ "1-5-3-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], "apac-ind-sebi-2024": [ "PR.MA.S1" @@ -49838,21 +51503,26 @@ "14.2.3.2", "14.2.3.3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "apac-nzl-ism-3-9": [ "6.3.8.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.4.2", "7.5.3", "7.5.5", "7.5.7" ], - "amaericas-can-osfi-self-assessment": [ - "6.11" + "americas-arg-ppd-2018": [ + "C.1.1-3" ], "americas-can-osfi-b13-2022": [ "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.03.B", "03.04.03.C", @@ -49881,7 +51551,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to include a cybersecurity and/or data protection representative in the configuration change control review process.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -49953,9 +51623,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Change Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -50004,6 +51674,9 @@ "general-nist-800-171-r3": [ "03.04.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.04.04.a" + ], "general-tisax-6-0-3": [ "5.2.2" ], @@ -50031,29 +51704,13 @@ "CM-03 (04)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" - ], - "emea-deu-c5-2020": [ - "DEV-05", - "DEV-09" - ], - "emea-isr-cmo-1-0": [ - "14.8" - ], - "emea-sau-ecc-1-2018": [ - "1-6-2-2" + "3.4.4.37" ], "emea-sau-otcc-1-2022": [ - "1-5-2" - ], - "apac-sgp-mas-trm-2021": [ - "7.5.4" + "1-5-4" ], - "amaericas-can-osfi-self-assessment": [ - "2.4", - "6.11" + "apac-mys-bnm-rmit-2025": [ + "10.11" ], "americas-can-itsp-10-171-2025": [ "03.04.04.A" @@ -50078,7 +51735,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions upon the detection of unauthorized baseline configurations change(s).", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50133,7 +51790,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -50159,9 +51817,6 @@ ], "general-pci-dss-4-0-1": [ "10.7" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" ] } }, @@ -50185,7 +51840,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern assets involved in providing cryptographic protections according to the organization's configuration management processes.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern assets involved in providing cryptographic protections according to the organization's configuration management processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -50217,7 +51872,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -50330,7 +51986,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -50418,7 +52075,9 @@ ], "general-nist-800-171a-r3": [ "A.03.04.03.b[01]", - "A.03.04.04.a" + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" ], "general-nist-csf-2-0": [ "ID.RA-07" @@ -50443,9 +52102,6 @@ "6.5.2", "6.5.6" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-tisax-6-0-3": [ "5.2.2", "5.3.1" @@ -50493,29 +52149,23 @@ "CM-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.76" ], "emea-deu-c5-2020": [ - "DEV-05", - "BCM-02" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.8" - ], - "emea-sau-cscc-1-2019": [ - "1-3-1-2" + "BEI-04", + "BEI-06" ], "emea-sau-otcc-1-2022": [ - "1-5-2", "1-5-4" ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.a" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.11" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP33", "HML33" ], @@ -50553,7 +52203,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50594,7 +52244,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -50620,7 +52271,7 @@ "general-govramp-high": [ "CM-05" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -50837,6 +52488,10 @@ "3.4.5[g]", "3.4.5[h]" ], + "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.05[06]" + ], "general-nist-800-218": [ "PS.1" ], @@ -50896,9 +52551,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-05" ], - "emea-deu-c5-2020": [ - "DEV-09" - ], "emea-sau-otcc-1-2022": [ "1-5-3-4" ], @@ -50914,6 +52566,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2422" ], + "apac-aus-ism-2026-march": [ + "ISM-1823" + ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.2" @@ -50942,7 +52597,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to perform after-the-fact reviews of configuration change logs to discover any unauthorized changes.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -51000,7 +52655,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -51061,10 +52717,10 @@ "CM-5(1)" ], "emea-sau-otcc-1-2022": [ - "1-5-4" + "1-5-3-5" ], - "amaericas-can-osfi-self-assessment": [ - "6.11" + "americas-can-osfi-self-assessment-2": [ + "2.5.3" ] } }, @@ -51086,7 +52742,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to prevent the installation of software and firmware components without verification that the component has been digitally signed using an organization-approved certificate authority.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -51122,7 +52778,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -51171,7 +52828,7 @@ "usa-federal-irs-1075-2021": [ "CM-14" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1796" ] } @@ -51194,7 +52851,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to enforce a two-person rule for implementing changes to critical Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -51249,7 +52906,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -51307,6 +52965,15 @@ "general-nist-800-161-r1-level-3": [ "AC-5" ], + "general-nist-800-172-r3": [ + "03.04.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.05E[01]", + "A.03.04.05E.ODP[01]", + "DS-A.03.04.05E[02]", + "A.03.04.05E.ODP[02]" + ], "usa-federal-fbi-cjis-6-0": [ "AC-5" ], @@ -51334,8 +53001,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-05" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-6" + "apac-sgp-mas-trm-2021": [ + "9.1.1" ] } }, @@ -51415,7 +53082,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -51480,16 +53148,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-05 (05)" ], - "emea-deu-c5-2020": [ - "DEV-09", - "PSS-08" - ], - "emea-isr-cmo-1-0": [ - "10.4" - ], - "apac-chn-data-security-law-2021": [ - "27" - ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.2" @@ -51519,7 +53177,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to restrict software library privileges to those individuals with a pertinent business need for access.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to restrict software library privileges to those individuals with a pertinent business need for access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -51574,7 +53232,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -51602,15 +53261,17 @@ "general-ul-2900-1-2017": [ "4.1(e)" ], - "emea-deu-c5-2020": [ - "DEV-07", - "DEV-08" - ], "emea-sau-cscc-1-2019": [ "1-3-2-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0405" + ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" ] } }, @@ -51636,7 +53297,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited information is provided to stakeholders about proposed changes.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to ensure stakeholders are made aware of and understand the impact of proposed changes.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to ensure stakeholders are made aware of and understand the impact of proposed changes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -51693,7 +53354,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -51801,9 +53463,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-09" ], + "emea-deu-c5-2020": [ + "BEI-03-BP2" + ], "emea-sau-cgiot-2024": [ "1-5-3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "americas-can-itsp-10-171-2025": [ "03.04.11.B" ] @@ -51814,7 +53482,7 @@ "title": "Control Functionality Verification", "family": "CHG", "description": "Mechanisms exist to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed.", - "scf_question": "Does the organization verify the functionality of cybersecurity and/or data protection controls following implemented changes to ensure applicable controls operate as designed?", + "scf_question": "Does the organization verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -51827,9 +53495,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -51894,9 +53562,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Change Management", "crosswalks": { "general-cis-csc-8-1": [ @@ -51980,6 +53648,12 @@ "general-nist-800-171a-r3": [ "A.03.04.04.b" ], + "general-nist-800-172-r3": [ + "03.04.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.07E[02]" + ], "general-pci-dss-4-0-1": [ "6.5.2", "10.7.3", @@ -52038,13 +53712,14 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-03 (02)" ], - "emea-isr-cmo-1-0": [ - "10.6", - "12.30", - "14.10" + "emea-sau-otcc-1-2022": [ + "1-5-4" ], - "apac-sgp-mas-trm-2021": [ - "7.5.5" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.f" + ], + "americas-arg-ppd-2018": [ + "C.1.1-1" ], "americas-can-itsp-10-171-2025": [ "03.04.04.B" @@ -52056,7 +53731,7 @@ "title": "Report Verification Results", "family": "CHG", "description": "Mechanisms exist to report the results of security, compliance and resilience capability verification to appropriate organizational management.", - "scf_question": "Does the organization report the results of cybersecurity and data protection function verification to appropriate organizational management?", + "scf_question": "Does the organization report the results of security, compliance and resilience capability verification to appropriate organizational management?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -52069,7 +53744,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to report the results of security, compliance and resilience capability verification to appropriate organizational management.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52113,9 +53788,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Change Management", "crosswalks": { "general-nist-800-53-r5-2": [ @@ -52159,7 +53834,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern change management procedures for \"emergency\" changes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52168,269 +53843,301 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, - "risks": [ - "R-AC-1", - "R-AC-2", - "R-AM-1", - "R-AM-3", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-BC-5", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ], - "family_name": "Change Management", - "crosswalks": { - "general-cobit-2019": [ - "BAI06.02" - ], - "usa-federal-doe-c2m2-2-1": [ - "ASSET-4f" - ], - "emea-eu-nis2-annex-2024": [ - "6.4.3" - ] - } - }, - { - "control_id": "CHG-07.1", - "title": "Documenting Emergency Changes", - "family": "CHG", - "description": "Mechanisms exist to document the results of \"emergency\" changes, including an explanation for why standard change management procedures could not be followed.", - "scf_question": "Does the organization document the results of \"emergency\" changes, including an explanation for why standard change management procedures could not be followed?", - "relative_weight": 7, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Process", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", - "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to document the results of \"emergency\" changes, including an explanation for why standard change management procedures could not be followed.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], - "possible_solutions": {}, - "risks": [ - "R-AC-1", - "R-AC-2", - "R-AM-1", - "R-AM-3", - "R-BC-1", - "R-BC-2", - "R-BC-3", - "R-BC-4", - "R-BC-5", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-EX-6", - "R-EX-7", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5", - "R-GV-6", - "R-GV-7", - "R-IR-1", - "R-IR-2", - "R-IR-3", - "R-IR-4", - "R-SA-1", - "R-SC-1", - "R-SC-2", - "R-SC-3", - "R-SC-4", - "R-SC-5", - "R-SC-6" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" - ], - "family_name": "Change Management", - "crosswalks": { - "emea-eu-nis2-annex-2024": [ - "6.4.3" - ] - } - }, - { - "control_id": "CHG-08", - "title": "Dual Approval For High-Impact Environments", - "family": "CHG", - "description": "Mechanisms exist to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization require dual approval for any changes that might result in a serious, but adverse impact to:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD)?", - "relative_weight": 9, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Process", - "nist_csf_function": "Protect", - "scrm_focus": { - "strategic": false, - "operational": false, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [], - "possible_solutions": { - "micro_small": "∙ Inventory embedded devices and document security settings", - "small": "∙ Embedded device inventory\n∙ Default credential change policy", - "medium": "∙ Embedded/IoT device security program\n∙ Network segmentation for IoT", - "large": "∙ IoT/OT security program\n∙ Network segmentation\n∙ IoT security platform (e.g., Claroty, Armis)", - "enterprise": "∙ Enterprise IoT/OT security platform (e.g., Claroty, Armis, Dragos)\n∙ Zero-trust IoT architecture" - }, - "risks": [ - "R-AC-1", - "R-AC-3", - "R-AM-1", - "R-AM-2", - "R-BC-1", - "R-BC-4", - "R-EX-7", - "R-GV-4", - "R-GV-6", - "R-IR-1" - ], - "threats": [ - "NT-7", - "MT-2", - "MT-8", - "MT-9", - "MT-10", - "MT-11" - ], - "errata": "- new control (IEC 62443-4-2)", - "family_name": "Change Management", - "crosswalks": { - "general-iec-62443-4-2-2019": [ - "CR 2.1(4)" - ] - } - }, - { - "control_id": "CLD-01", - "title": "Cloud Services", - "family": "CLD", - "description": "Mechanisms exist to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices.", - "scf_question": "Does the organization facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices?", - "relative_weight": 10, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-AST-06" - ], - "pptdf": "Process", - "nist_csf_function": "Govern", - "scrm_focus": { - "strategic": true, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", - "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify cybersecurity and data protection requirements for CSP environments, including dedicated and multi-client environments.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "SCRMS", - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Fundamentals", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], "possible_solutions": { - "micro_small": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)", - "small": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)", - "medium": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)", - "large": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)", - "enterprise": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)" + "micro_small": "∙ Documented emergency change procedure\n∙ Post-implementation documentation requirement", + "small": "∙ Emergency change request process\n∙ Designated emergency change approver\n∙ Post-implementation review", + "medium": "∙ Formal emergency change management process\n∙ ITSM tool emergency change workflow (e.g., ServiceNow, Jira)\n∙ Emergency Change Advisory Board (CAB) approval", + "large": "∙ Enterprise emergency change management process in ITSM platform\n∙ Emergency CAB with on-call members\n∙ Integration with incident response", + "enterprise": "∙ Enterprise ITSM emergency change workflow\n∙ 24/7 emergency CAB availability\n∙ Automated emergency change tracking and audit trail\n∙ Integration with incident response processes" }, "risks": [ "R-AC-1", "R-AC-2", - "R-AC-3", - "R-AC-4", "R-AM-1", - "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Change Management", + "crosswalks": { + "general-cobit-2019": [ + "BAI06.02" + ], + "usa-federal-doe-c2m2-2-1": [ + "ASSET-4f" + ], + "emea-eu-nis2-annex-2024": [ + "6.4.3" + ], + "emea-deu-c5-2020": [ + "BEI-10" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.h" + ], + "apac-sgp-mas-trm-2021": [ + "7.5.6" + ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ] + } + }, + { + "control_id": "CHG-07.1", + "title": "Documenting Emergency Changes", + "family": "CHG", + "description": "Mechanisms exist to document the results of \"emergency\" changes, including an explanation for why standard change management procedures could not be followed.", + "scf_question": "Does the organization document the results of \"emergency\" changes, including an explanation for why standard change management procedures could not be followed?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to document the results of \"emergency\" changes, including an explanation for why standard change management procedures could not be followed.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Emergency change log (spreadsheet)\n∙ Post-hoc documentation template for emergency changes", + "small": "∙ Emergency change documentation register\n∙ Mandatory post-implementation review requirement", + "medium": "∙ ITSM-based post-implementation emergency change documentation\n∙ Mandatory post-implementation review within defined timeframe", + "large": "∙ ITSM platform mandatory documentation workflow\n∙ Post-implementation review with management sign-off\n∙ Integration with audit trail", + "enterprise": "∙ Automated ITSM documentation requirements for emergency changes\n∙ Mandatory post-implementation review with sign-off\n∙ Integration with GRC and audit reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AM-1", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Change Management", + "crosswalks": { + "emea-eu-nis2-annex-2024": [ + "6.4.3" + ], + "emea-deu-c5-2020": [ + "BEI-10" + ] + } + }, + { + "control_id": "CHG-08", + "title": "Dual Approval For High-Impact Environments", + "family": "CHG", + "description": "Mechanisms exist to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": false, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Inventory embedded devices and document security settings", + "small": "∙ Embedded device inventory\n∙ Default credential change policy", + "medium": "∙ Embedded/IoT device security program\n∙ Network segmentation for IoT", + "large": "∙ IoT/OT security program\n∙ Network segmentation\n∙ IoT security platform (e.g., Claroty, Armis)", + "enterprise": "∙ Enterprise IoT/OT security platform (e.g., Claroty, Armis, Dragos)\n∙ Zero-trust IoT architecture" + }, + "risks": [ + "R-AC-1", + "R-AC-3", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-4", + "R-EX-7", + "R-GV-4", + "R-GV-6", + "R-IR-1" + ], + "threats": [ + "NT-7", + "MT-2", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-28" + ], + "family_name": "Change Management", + "crosswalks": { + "general-iec-62443-4-2-2019": [ + "CR 2.1(4)" + ], + "emea-sau-otcc-1-2022": [ + "2-2-1-6" + ] + } + }, + { + "control_id": "CLD-01", + "title": "Cloud Services", + "family": "CLD", + "description": "Mechanisms exist to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices.", + "scf_question": "Does the organization facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices?", + "relative_weight": 10, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-AST-06" + ], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", + "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify cybersecurity and data protection requirements for CSP environments, including dedicated and multi-client environments.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices. ", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "SCRMS", + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Fundamentals", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)", + "small": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)", + "medium": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)", + "large": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)", + "enterprise": "∙ SCF Security, Compliance & Resilience Management System (SCRMS)\n∙ Data Protection Impact Assessment (DPIA)\n∙ Secure Baseline Configurations (SBC)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", "R-AM-3", "R-BC-1", "R-BC-2", @@ -52502,7 +54209,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -52569,9 +54277,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-shared-assessments-sig-2025": [ "J.1" ], @@ -52590,22 +54295,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "COS-01", - "COS-02" - ], - "emea-isr-cmo-1-0": [ - "11.2" + "UP-01", + "UP-01-BP1", + "UP-01-BP2", + "RB-05" ], "emea-sau-cscc-1-2019": [ - "4-2" + "4-2-1" ], "emea-sau-cgiot-2024": [ "4-2-1" @@ -52613,23 +54310,38 @@ "emea-sau-ecc-1-2018": [ "4-2-1", "4-2-2", - "4-2-3", + "4-2-3-1", "4-2-3-2", - "4-2-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" + "4-2-3-3" ], "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.4.3" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "apac-aus-ism-2024-june": [ + "3.4.3", + "3.4.3.1", + "3.4.3.3", + "3.4.3.4", + "3.4.3.4.a", + "3.4.3.4.a.1", + "3.4.3.4.a.2", + "3.4.3.4.a.3", + "3.4.3.4.b", + "3.4.3.4.b.1", + "3.4.3.4.c", + "3.4.3.4.c.1", + "3.4.3.4.d", + "3.4.3.4.d.1", + "3.4.3.4.e", + "3.4.3.4.e.1", + "3.4.3.4.f", + "3.4.3.4.f.1", + "3.4.3.4.g", + "3.4.3.4.g.1", + "3.4.3.4.g.2", + "3.4.3.4.g.3" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.nub.1" + ], + "apac-aus-ism-2026-march": [ "ISM-1437", "ISM-1529", "ISM-1579", @@ -52650,29 +54362,20 @@ "5.1.1.29.P", "5.1.1.30.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.26", + "10.50" + ], "apac-nzl-ism-3-9": [ + "2.3.28.C.01", + "20.1.20.C.01", + "20.1.20.C.02", + "20.1.20.C.03", + "20.1.20.C.04", "22.1.20.C.01", "22.1.20.C.02", "22.1.20.C.03", - "22.1.20.C.04", - "22.1.20.C.05", "22.1.21.C.01", - "22.1.21.C.02", - "22.1.21.C.03", - "22.1.21.C.04", - "22.1.21.C.05", - "22.1.21.C.06", - "22.1.21.C.07", - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04", - "22.1.25.C.01", - "22.1.25.C.02", - "22.1.26.C.01", - "22.1.26.C.02", - "22.1.26.C.03", - "22.1.27.C.01", "23.1.54.C.01", "23.1.54.C.02", "23.2.19.C.01" @@ -52700,7 +54403,7 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud services are designed and configured so Technology Assets, Applications and/or Services (TAAS) are secured in accordance with applicable organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52774,12 +54477,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { - "emea-sau-sacs-002-2022": [ - "TPC-43" + "emea-sau-ecc-1-2018": [ + "4-2-3-1" ], "apac-nzl-ism-3-9": [ "23.4.9.C.01", @@ -52879,10 +54583,24 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { + "emea-deu-c5-2020": [ + "PI-02", + "PI-05" + ], + "emea-sau-ecc-1-2018": [ + "4-2-3-1" + ], + "emea-sau-sama-csf-1-2017": [ + "3.4.3.4.h", + "3.4.3.4.h.1", + "3.4.3.4.h.2", + "3.4.3.4.h.3" + ], "apac-jpn-ismap": [ "8.1.5.P", "8.1.5.1.P", @@ -52891,6 +54609,8 @@ "8.1.5.4.P" ], "apac-nzl-ism-3-9": [ + "20.1.26.C.02", + "20.1.26.C.03", "23.4.13.C.01", "23.4.13.C.02", "23.4.13.C.03" @@ -52917,9 +54637,9 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -52990,7 +54710,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -53018,8 +54739,8 @@ "3.1.22", "NFO–PL-8" ], - "general-scf-dpmp-2025": [ - "7.1" + "general-nist-cswp-39": [ + "6.4" ], "general-shared-assessments-sig-2025": [ "N.2" @@ -53043,9 +54764,8 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-01", - "COS-02" + "emea-isr-cmo-2-0": [ + "Appendix A, 6.1" ], "emea-sau-cgiot-2024": [ "4-2-1", @@ -53054,11 +54774,6 @@ "emea-sau-ecc-1-2018": [ "4-2-3-2" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.4.3" - ], "apac-ind-sebi-2024": [ "PR.IP.S13" ], @@ -53066,7 +54781,10 @@ "8.1.2.7.PB", "9.2.3.11.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP51", "HML51" ], @@ -53074,9 +54792,12 @@ "HSUP43" ], "apac-nzl-ism-3-9": [ - "22.1.23.C.01", - "22.1.23.C.02", - "22.1.23.C.03", + "2.3.28.C.01", + "20.1.24.C.02", + "20.1.24.C.03", + "20.1.24.C.04", + "20.2.12.C.01", + "20.2.12.C.02", "23.1.54.C.01", "23.1.54.C.02", "23.1.56.C.01", @@ -53102,7 +54823,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ The cloud infrastructure incorporates a managed security zone to house cybersecurity and data protection tools.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to host security-specific technologies in a dedicated subnet.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -53142,7 +54863,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -53190,20 +54912,9 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-01", - "COS-02", - "COS-05" - ], - "emea-isr-cmo-1-0": [ - "9.2" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1750" - ], - "apac-nzl-ism-3-9": [ - "22.1.24.C.02" ] } }, @@ -53225,7 +54936,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure support for secure interoperability between components with Application Programming Interfaces (APIs).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53273,7 +54984,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -53304,20 +55016,29 @@ "155.260(a)(6)" ], "emea-deu-c5-2020": [ - "PI-01" + "PI-01", + "PI-04" ], "emea-sau-cscc-1-2019": [ "1-3-2-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.4", + "mp.s.2" + ], "apac-ind-sebi-2024": [ "PR.AA.S17" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP52", "HML52" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP44" + ], + "apac-sgp-mas-trm-2021": [ + "6.4.1", + "6.4.4" ] } }, @@ -53404,11 +55125,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { "usa-federal-dow-zt-roadmap-1-1": [ + "3.4", "3.4.1" ] } @@ -53433,7 +55156,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the integrity of virtual machine images at all times.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the integrity of virtual machine images at all times. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -53475,12 +55198,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { - "emea-deu-c5-2020": [ - "PSS-11" + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } }, @@ -53502,7 +55226,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure multi-tenant owned or managed assets (physical and virtual) are designed and governed such that provider and customer (tenant) user access is appropriately segmented from other tenant users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53590,7 +55314,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -53639,13 +55364,9 @@ "52.204-21(b)(1)(iv)" ], "emea-deu-c5-2020": [ - "OPS-24" + "RB-23" ], - "emea-isr-cmo-1-0": [ - "10.1", - "11.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1529" ], "apac-jpn-ismap": [ @@ -53655,7 +55376,10 @@ "9.5.1.3.P", "9.5.1.4.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP53", "HML53" ], @@ -53738,9 +55462,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": { "general-iso-27001-2022": [ @@ -53761,13 +55485,28 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.1" ], + "emea-deu-c5-2020": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 5.1" + ], "apac-jpn-ismap": [ "6.3.1.1.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "apac-nzl-ism-3-9": [ + "20.1.21.C.03", "23.1.55.C.01", "23.1.55.C.02", "23.1.55.C.03" + ], + "americas-bmu-mba-coc-2020": [ + "5.11" ] } }, @@ -53789,7 +55528,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure Multi-Tenant Service Providers (MTSP) facilitate security event logging capabilities for its customers that are consistent with applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53834,7 +55573,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -53845,6 +55585,9 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "A1.2.1" ], + "emea-deu-c5-2020": [ + "RB-10" + ], "apac-nzl-ism-3-9": [ "23.5.11.C.01", "23.5.12.C.01", @@ -53870,7 +55613,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure Multi-Tenant Service Providers (MTSP) facilitate prompt forensic investigations in the event of a suspected or confirmed security incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53915,7 +55658,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -53991,7 +55735,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -54028,7 +55773,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud providers use secure protocols for the import, export and management of data in cloud-based Technology Assets, Applications and/or Services (TAAS).", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud providers use secure protocols for the import, export and management of data in cloud-based Technology Assets, Applications and/or Services (TAAS). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -54061,7 +55806,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -54070,7 +55816,8 @@ ], "emea-deu-c5-2020": [ "PI-01", - "PI-02" + "PI-02", + "PI-03" ] } }, @@ -54132,14 +55879,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", - "crosswalks": { - "emea-deu-c5-2020": [ - "PSS-11" - ] - } + "crosswalks": {} }, { "control_id": "CLD-09", @@ -54165,9 +55909,9 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Geolocation requirements for sensitive/regulated data types identify restrictions on transfer of data to third-countries or international organizations.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to govern geolocation requirements for sensitive/regulated data types, including the transfer of data to third-countries or international organizations.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to control the location of cloud processing/storage based on business requirements that includes statutory, regulatory and contractual obligations.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to control the location of cloud processing/storage based on business requirements that includes statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cloud Security (CLD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cloud Security (CLD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -54215,7 +55959,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -54291,14 +56036,8 @@ "SA-09 (05)" ], "emea-deu-c5-2020": [ - "PI-02", - "PSS-12" - ], - "emea-ken-pda-2019": [ - "25(h)" - ], - "emea-qat-pdppl-2020": [ - "15" + "UP-02", + "RB-03" ], "emea-sau-cscc-1-2019": [ "4-2-1-1" @@ -54307,43 +56046,26 @@ "4-1-3-2", "4-2-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-30" - ], - "apac-aus-privacy-principles-2026": [ - "APP 8" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1572" ], - "apac-chn-pipl-2021": [ - "38", - "39", - "40" - ], "apac-ind-sebi-2024": [ "PR.DS.S2" ], - "apac-jpn-ppi-2020": [ - "24(1)" + "apac-mys-bnm-rmit-2025": [ + "10.50" ], "apac-nzl-ism-3-9": [ + "20.1.22.C.01", + "20.1.22.C.02", + "20.1.22.C.03", + "20.1.22.C.04", + "20.1.22.C.05", + "20.1.22.C.06", "22.1.22.C.01", "22.1.22.C.02", - "22.1.22.C.03", - "22.1.22.C.04", - "22.1.22.C.05", - "22.1.22.C.06", "23.4.11.C.01", "23.4.11.C.02" - ], - "americas-arg-ppd-2018": [ - "12.1", - "12.2" - ], - "americas-bra-lgpd-2018": [ - "33", - "34" ] } }, @@ -54351,8 +56073,8 @@ "control_id": "CLD-10", "title": "Sensitive Data In Public Cloud Providers", "family": "CLD", - "description": "Mechanisms exist to limit and manage the storage of sensitive/regulated data in public cloud providers.", - "scf_question": "Does the organization limit and manage the storage of sensitive/regulated data in public cloud providers?", + "description": "Mechanisms exist to limit and manage the storage of sensitive and/or regulated data in public cloud providers.", + "scf_question": "Does the organization limit and manage the storage of sensitive and/or regulated data in public cloud providers?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -54369,7 +56091,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to limit and manage the storage of sensitive/regulated data in public cloud providers.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to limit and manage the storage of sensitive/regulated data in public cloud providers. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -54415,7 +56137,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -54441,13 +56164,11 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(iv)" ], - "emea-isr-cmo-1-0": [ - "11.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 6.1" ], - "apac-nzl-ism-3-9": [ - "2.3.23.C.01", - "22.1.22.C.04", - "22.1.22.C.05" + "apac-mys-bnm-rmit-2025": [ + "10.50" ] } }, @@ -54469,7 +56190,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to utilize a Cloud Access Security Broker (CASB), or similar technology, to provide boundary protection and monitoring functions that both provide access to the cloud and protect the organization from misuse of cloud resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54505,7 +56226,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -54517,20 +56239,6 @@ ], "general-shared-assessments-sig-2025": [ "P.8" - ], - "emea-deu-c5-2020": [ - "COS-04" - ], - "emea-isr-cmo-1-0": [ - "9.10", - "11.8", - "16.4" - ], - "apac-nzl-ism-3-9": [ - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04" ] } }, @@ -54552,7 +56260,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to prevent \"side channel attacks\" when using a Content Delivery Network (CDN) by restricting access to the origin server's IP address to the CDN and an authorized management network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54592,7 +56300,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -54609,7 +56318,7 @@ "general-shared-assessments-sig-2025": [ "N.11" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1438", "ISM-1439" ] @@ -54633,7 +56342,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to specify applicable security, compliance and resilience that must be implemented on external Technology Assets, Applications and/or Services (TAAS), consistent with the contractual obligations established with the External Service Providers (ESP) owning, operating and/or maintaining external TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54703,9 +56412,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": { "general-nist-800-207": [ @@ -54731,7 +56440,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to authorize specified individuals to access External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54801,7 +56510,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": {} @@ -54810,8 +56520,8 @@ "control_id": "CLD-13.2", "title": "Sensitive / Regulated Data On Hosted Assets, Applications & Services", "family": "CLD", - "description": "Mechanisms exist to define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", - "scf_question": "Does the organization define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations?", + "description": "Mechanisms exist to define formal processes to store, process and/or transmit sensitive and/or regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", + "scf_question": "Does the organization define formal processes to store, process and/or transmit sensitive and/or regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -54824,7 +56534,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54894,7 +56604,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": {} @@ -54917,7 +56628,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to prohibit access to, or usage of, hosted Technology Assets, Applications and/or Services (TAAS) until applicable security, compliance and/or resilience control implementation is verified.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54987,9 +56698,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": {} }, @@ -54998,7 +56709,7 @@ "title": "Software Defined Storage (SDS)", "family": "CLD", "description": "Automated mechanisms exist to utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization use automated mechanisms to utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 3, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -55079,7 +56790,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -55116,7 +56828,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -55219,7 +56931,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -55382,6 +57095,10 @@ "03.04.11.a", "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]", + "A.03.12.01" + ], "general-nist-800-218": [ "PO.1", "PO.1.2" @@ -55392,6 +57109,11 @@ "GV.SC-05", "PR" ], + "general-nist-cswp-39": [ + "3.1.1", + "3.1.2", + "5.1" + ], "general-pci-dss-4-0-1": [ "12.4", "12.4.2", @@ -55401,10 +57123,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.2" ], - "general-scf-dpmp-2025": [ - "2.4", - "11.6" - ], "general-shared-assessments-sig-2025": [ "L.1" ], @@ -55488,6 +57206,18 @@ "PL-01", "PM-08" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(a)", + "101.620(b)(4)", + "101.620(b)(5)", + "101.650(b)", + "101.650(e)", + "101.650(e)(3)", + "101.650(f)", + "101.650(g)", + "101.650(h)", + "101.650(i)" + ], "usa-federal-law-ferpa-2010": [ "1232h(c)(1)(C)(i)" ], @@ -55508,20 +57238,20 @@ "155.260(e)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)", - "164.504(g)(1)", - "164.530(i)(1)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)", + "§ 164.504(g)(1)", + "§ 164.530(i)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.E.6.1", @@ -55575,6 +57305,10 @@ "35(a)(1)", "37(a)(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.2(c)", + "603A.525.2(b)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(b)(6)", "500.2(d)", @@ -55648,15 +57382,30 @@ "Article 21.3", "Article 40.1" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 6", + "Article 6(a)", + "Article 6(b)", + "Article 12(1)(a)", + "Article 12(1)(b)", + "Article 19(7)", + "Article 23(1)", + "Article 23(1)(a)", + "Article 23(1)(b)", + "Article 24(2)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II" + ], "emea-eu-eba-ict-srm-2025": [ - "3.1(1)", - "3.8(92)", - "3.8(93)", - "3.8(94)", - "3.8(95)", - "3.8(96)", - "3.8(97)", - "3.8(98)" + "3.1.1", + "3.8.92", + "3.8.93", + "3.8.94", + "3.8.95", + "3.8.96", + "3.8.97", + "3.8.98" ], "emea-eu-dora-2023": [ "Article 4.1", @@ -55667,96 +57416,51 @@ "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3", - "29" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-eu-psd2-2015": [ + "97(3)" ], "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" + "3.4.76(5)", + "3.4.77" ], "emea-deu-bsrit-2017": [ - "12.5" + "2.1" ], "emea-deu-c5-2020": [ - "SP-01", + "SA-01-BP6", "PI-02", + "DLL-01-BP2", "COM-01" ], "emea-grc-pirppd-1997": [ - "10" + "B.5.3" ], - "emea-hun-isdfi-2011": [ - "7" + "emea-hun-act-cxii-2011": [ + "II.5.5(2)(b)", + "II.5.6(1)(a)", + "II.5.6(5)(a)" ], - "emea-irl-dpa-2003": [ - "2" + "emea-irl-dpa-2018": [ + "s.83" ], - "emea-isr-cmo-1-0": [ - "1.3" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "26", - "31", - "33", - "34", - "35" + "emea-ita-pdpc-2018": [ + "Article 1(1)" ], "emea-ken-pda-2019": [ - "4(a)", - "4(b)(i)", - "4(b)(ii)", - "51(1)", - "51(2)(a)", - "51(2)(b)", - "51(2)(c)", - "52(1)(a)", - "52(1)(b)", - "52(1)(c)", - "52(2)", - "52(3)", - "54", - "55(1)(a)", - "55(1)(b)", - "55(2)" + "IV.37(1)", + "IV.37(1)(a)", + "IV.37(1)(b)", + "IV.37(2)", + "IV.37(3)" ], "emea-nga-dpr-2019": [ "2.1(2)", "2.1(3)", "3.1(16)", - "4.1(1)", - "4.1(6)", - "4.1(7)" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" + "4.1(1)" ], "emea-qat-pdppl-2020": [ - "2" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" - ], - "emea-sau-cscc-1-2019": [ - "1-4" + "3.8" ], "emea-sau-cgiot-2024": [ "1-2-3", @@ -55772,45 +57476,26 @@ "Article 2.1", "Article 30.3" ], - "emea-sau-sacs-002-2022": [ - "TPC-20", - "TPC-21", - "TPC-43" - ], "emea-sau-sama-csf-1-2017": [ "3.2.2", - "3.2.3", - "3.3.13" + "3.2.2.1", + "3.2.2.1.a", + "3.2.2.1.b", + "3.2.2.1.c" ], "emea-srb-act-9-2018": [ - "5.1", - "13", - "49", - "59" - ], - "emea-zaf-popia-2013": [ - "2", - "3", - "9", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.1", - "Article 39" + "IV.1.49" ], "emea-esp-decree-311-2022": [ - "3.1", - "39" + "Article 37" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.5 [OP.PL.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "2.2.14.1.b", + "2.2.14.1.c", + "2.2.14.1.d" ], "emea-gbr-def-stan-05-138-2024": [ "0001", @@ -55835,22 +57520,18 @@ "0002", "2314" ], - "apac-aus-privacy-act-1998": [ - "APP Part 11" + "apac-aus-privacy-principles-2026": [ + "1.1.2.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0078", "ISM-0854" ], - "apac-aus-ps-cps-230-2023": [ - "28" + "apac-aus-cop-sitc-2020": [ + "5" ], - "apac-aus-ps-cps-234-2019": [ - "31", - "35", - "35(a)", - "35(b)", - "36" + "apac-aus-ps-cps-230-2023": [ + "12" ], "apac-chn-cybersecurity-law-2017": [ "Article 9", @@ -55865,19 +57546,11 @@ "Article 47" ], "apac-chn-data-security-law-2021": [ - "46" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "32", - "37", - "38(4)", - "42" + "Article 27", + "Article 32" ], "apac-hkg-pdo-2022": [ - "Principle 4" + "4" ], "apac-ind-dpdpa-2023": [ "7(c)", @@ -55886,42 +57559,17 @@ "8(1)", "8(4)" ], - "apac-ind-privacy-rules-2011": [ - "8" - ], "apac-ind-sebi-2024": [ "GV.OC.S2", "PR.IP.S13", "RS.MA.S5" ], - "apac-jpn-ppi-2020": [ - "20", - "21", - "22", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" + "apac-jpn-appi-2020": [ + "IV.1.16-2", + "IV.1.26(1)", + "IV.1.26(1)(i)", + "IV.1.26(1)(ii)", + "IV.1.26(2)" ], "apac-jpn-ismap": [ "4.4.2.1", @@ -55938,10 +57586,7 @@ "18.1.1.7.P", "18.1.5.7.PB" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP29", "HML29" ], @@ -55953,47 +57598,37 @@ "1.1.65.C.01", "1.1.66.C.01", "1.1.66.C.02", - "1.1.67.C.01" + "1.1.67.C.01", + "1.2.15.C.01", + "1.2.15.C.02", + "17.9.37.C.01" + ], + "apac-nzl-privacy-act-2020": [ + "6.2.126(1)", + "6.2.126(2)", + "6.2.126(2)(a)", + "6.2.126(2)(b)" ], "apac-phl-dpa-2012": [ - "25" + "III.11" ], "apac-sgp-pdpa-2012": [ - "24" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "3.1(a)", - "3.1(b)", - "3.1(c)" - ], - "apac-sgp-mas-trm-2021": [ - "3.2.3" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "27" - ], - "americas-arg-ppd-2018": [ - "10.1", - "10.2" + "3.11(2)" ], "americas-bhs-dpa-2003": [ - "6" + "II.4(1)", + "IV.24(6)", + "IV.24(7)", + "IV.24(7)(a)", + "IV.24(7)(b)", + "V.45(4)(a)", + "V.45(4)(b)", + "V.45(5)", + "V.45(6)", + "V.45(7)" ], "americas-bra-lgpd-2018": [ - "7.1", - "7.2", - "7.3", - "7.4", - "7.5", - "7.6", - "7.7", - "7.8", - "7.9", - "7.10" + "VII.I.46.2" ], "americas-can-osfi-b13-2022": [ "1.3.1" @@ -56003,16 +57638,13 @@ "03.12.01" ], "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" + "P1-4.1", + "P1-4.1.3" ], "americas-col-law-1581-2012": [ - "4" - ], - "americas-mex-fdpa-2010": [ - "19" + "VI.17", + "VI.17(o)", + "VI.18" ] } }, @@ -56036,7 +57668,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to document and review instances of non-compliance with statutory, regulatory and/or contractual obligations to develop appropriate risk mitigation actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56129,7 +57761,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -56223,7 +57856,12 @@ "4.E(2)(b)" ], "general-nist-800-171-r3": [ - "03.12.02.a.01" + "03.12.02.a.01", + "03.12.02.a.02" + ], + "general-nist-800-171a-r3": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" ], "general-pci-dss-4-0-1": [ "12.4.2" @@ -56231,9 +57869,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.2" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-tisax-6-0-3": [ "1.5.1" ], @@ -56265,34 +57900,20 @@ "Article 20.1", "Article 41.5" ], + "emea-eu-eba-ict-srm-2025": [ + "3.3.6.27" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], + "emea-deu-c5-2020": [ + "SPN-02" + ], "emea-sau-cgiot-2024": [ "1-7-3" ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1" - ], - "apac-aus-ps-cps-230-2023": [ - "30", - "31" - ], - "apac-aus-ps-cps-234-2019": [ - "29", - "35", - "35(a)", - "35(b)", - "36" - ], - "apac-chn-pipl-2021": [ - "54" - ], - "apac-jpn-ppi-2020": [ - "40(1)", - "40(2)", - "40(3)" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], "apac-jpn-ismap": [ "4.6.1.1", @@ -56304,23 +57925,12 @@ "1.1.69.C.01", "1.1.69.C.02" ], - "apac-sgp-mas-trm-2021": [ - "3.2.3", - "4.5.2", - "4.5.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.10", - "6.14" - ], "americas-can-osfi-b13-2022": [ "1.3.1" ], "americas-can-itsp-10-171-2025": [ - "03.12.02.A.01" + "03.12.02.A.01", + "03.12.02.A.02" ] } }, @@ -56346,7 +57956,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to perform compliance scoping of control applicability for statutory, regulatory and/or contractual compliance obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to document and validate the scope of security, compliance and resilience controls that are determined to meet statutory, regulatory and/or contractual compliance obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56397,9 +58007,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -56455,9 +58065,8 @@ "03.04.11.a", "03.15.02.a.04" ], - "general-nist-800-172": [ - "3.11.5e", - "3.14.3e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]" ], "general-nist-800-218": [ "PO.1" @@ -56481,9 +58090,6 @@ "12.5.1", "12.5.2" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-tisax-6-0-3": [ "1.2.1" ], @@ -56491,6 +58097,12 @@ "RA.L3-3.11.5E", "SI.L3-3.14.3E" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.605(a)", + "101.605(b)", + "101.625(d)", + "101.630(d)(2)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7123(b)(2)", "7123(b)(3)" @@ -56513,16 +58125,19 @@ "emea-sau-pdpl-2023": [ "Article 2.2" ], - "emea-esp-boe-a-2022-7191": [ - "Article 38.2" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], - "emea-esp-decree-311-2022": [ - "38.2" + "emea-che-fadp-2025": [ + "2.2.14.1.a" ], "apac-jpn-ismap": [ "4.4.4", "4.4.4.1" ], + "americas-bmu-mba-coc-2020": [ + "5.11-BP3" + ], "americas-can-osfi-b13-2022": [ "1.3.1" ], @@ -56550,7 +58165,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -56624,9 +58239,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -56642,9 +58257,6 @@ "general-iso-29100-2024": [ "6.12" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-dow-cert-rmm-1-2": [ "COMP:SG3.SP1", "COMP:SG3.SP2" @@ -56659,6 +58271,10 @@ "usa-federal-eo-14028": [ "4e(ii)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(6)", + "101.660" + ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "IV.C.1" ], @@ -56690,8 +58306,9 @@ "Article 22.3", "Article 22.3(a)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.13" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(1)", + "Article 32(5)" ], "emea-eu-gdpr-2016": [ "Article 5.2", @@ -56699,9 +58316,30 @@ "Article 30.4", "Article 31" ], + "emea-aut-dpa-2018": [ + "§ 37(3)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 29(5)" + ], + "emea-deu-c5-2020": [ + "UP-04", + "SPN-03-DOAR", + "COM-02-DOAR", + "COM-03-DOAR" + ], + "emea-ken-pda-2019": [ + "IV.32(1)" + ], + "emea-nga-dpr-2019": [ + "3.1(4)" + ], "emea-sau-pdpl-2023": [ "Article 30.4.a" ], + "emea-esp-decree-311-2022": [ + "Article 38(1)" + ], "apac-ind-sebi-2024": [ "PR.IP.S17" ], @@ -56709,6 +58347,9 @@ "4.5.4.3", "18.2.1.11.P", "18.2.1.12.P" + ], + "apac-mys-bnm-rmit-2025": [ + "16.6" ] } }, @@ -56730,7 +58371,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56829,9 +58470,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -56850,9 +58491,6 @@ "general-nist-600-1-gen-ai-profile": [ "MP-3.4-003" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-un-155-2021": [ "7.2.2.1", "7.2.2.2" @@ -56869,6 +58507,9 @@ "609.930(c)(6)(iii)", "609.935(c)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(g)(3)" + ], "usa-federal-law-sox-2002": [ "404(a)", "404(a)(2)", @@ -56900,28 +58541,67 @@ "Article 43.3", "Article 43.4" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.2", - "Article 10.7", - "Article 13.2(a)", - "Article 24.1", - "Article 24.1(a)", - "Article 24.1(b)", - "Article 24.1(c)" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.1" + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(3)", + "Article 13(12)", + "Article 19(2)(a)", + "Article 32(1)", + "Article 32(1)(a)", + "Article 32(1)(b)", + "Article 32(1)(c)", + "Article 32(1)(d)", + "Article 32(3)", + "Article 32(3)(a)", + "Article 32(3)(b)", + "Article 32(6)" ], "emea-eu-nis2-annex-2024": [ "2.2.1", "2.2.3" ], + "emea-nga-dpr-2019": [ + "4.1(5)", + "4.1(5)a", + "4.1(5)b", + "4.1(5)c", + "4.1(5)d", + "4.1(5)e", + "4.1(5)f", + "4.1(5)g", + "4.1(5)h", + "4.1(5)i", + "4.1(5)j" + ], + "emea-qat-pdppl-2020": [ + "3.11.7" + ], + "emea-esp-decree-311-2022": [ + "Article 31(1)", + "Article 31(2)", + "Article 31(3)", + "Article 31(4)", + "Article 31(5)", + "Article 31(7)" + ], "emea-gbr-caf-4-0": [ "A2.c" ], + "apac-aus-ps-cps-230-2023": [ + "28" + ], "apac-jpn-ismap": [ "4.5.4.3", "4.6.2.2" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "18.1" + ], + "americas-bmu-mba-coc-2020": [ + "5.7-BP3", + "5.11-BP3", + "6.10" ] } }, @@ -56943,7 +58623,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ A formal report is generated for each security assessment/audit with sufficient details to understand the organization's ability to demonstrate conformity with its requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to generate a declaration of conformity for each conformity assessment, where the document:\n(1) Is concise;\n(2) Unambiguously reflects the current status;\n(3) Is physically or electronically signed; and\n(4) Where possible, is machine readable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57015,7 +58695,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -57060,19 +58741,16 @@ "Article 47.3", "Article 47.4" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 4", - "Annex 4.1", - "Annex 4.2", - "Annex 4.3", - "Annex 4.4", - "Annex 4.5", - "Annex 4.6", - "Annex 4.7", - "Annex 4.8", - "Annex 6 Module A.4", - "Annex 6 Module A.4.2", - "Annex 6 Module C.3.2" + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(1)(c)", + "Article 20(5)" + ], + "emea-esp-decree-311-2022": [ + "Article 38(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "8.2", + "18.2" ] } }, @@ -57094,7 +58772,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure individuals performing audits and/or assessments have reasonable:\n(1) Professional qualifications to perform the audit and/or assessment; and\n(2) Subject matter expertise to perform review, interview and test activities for in-scope People, Processes, Technologies, Data and/or Facilities (PPTDF).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57154,13 +58832,24 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Compliance", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(4)", + "101.630(f)(4)(i)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7122(a)(1)", "7122(d)" + ], + "apac-mys-bnm-rmit-2025": [ + "16.5" + ], + "apac-sgp-mas-trm-2021": [ + "15.1.4" ] } }, @@ -57182,10 +58871,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to designate an individual the authority to make statements of conformity on behalf of the organization.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define." + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to designate an individual the authority to make statements of conformity on behalf of the organization. ", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { @@ -57206,9 +58896,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (SOX)", "family_name": "Compliance", "crosswalks": { "usa-federal-law-sox-2002": [ @@ -57218,6 +58908,9 @@ "302(a)(4)(B)", "302(a)(4)(C)", "302(a)(4)(D)" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 18(1)" ] } }, @@ -57226,7 +58919,7 @@ "title": "Conformity Attestations", "family": "CPL", "description": "Mechanisms exist for the certifying official to attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria.", - "scf_question": "Does the organization's certifying official attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria", + "scf_question": "Does the organization have a certifying official attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -57239,10 +58932,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists for the certifying official to attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define." + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { @@ -57263,9 +58957,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (SOX)", "family_name": "Compliance", "crosswalks": { "usa-federal-law-sox-2002": [ @@ -57284,7 +58978,7 @@ "title": "Security, Compliance & Resilience Controls Oversight", "family": "CPL", "description": "Mechanisms exist to provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership.", - "scf_question": "Does the organization provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership?", + "scf_question": "Does the organization provide a security, compliance and resilience controls oversight function that reports to its executive leadership?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -57305,7 +58999,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.\n▪ A formal report is generated for each security assessment/audit with sufficient details to understand the organization's ability to demonstrate conformity with its requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57397,9 +59091,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -57494,7 +59188,7 @@ "general-iso-31000-2018": [ "6.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -57787,10 +59481,19 @@ "3.12.3" ], "general-nist-800-171a-r3": [ + "A.03.12.01", "A.03.12.03[01]", "A.03.12.03[03]", "A.03.12.03[04]" ], + "general-nist-800-172-r3": [ + "03.12.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.03E[02]", + "DS-A.03.12.03E[03]", + "DS-A.03.12.03E[04]" + ], "general-nist-csf-2-0": [ "GV.OC-03" ], @@ -57809,9 +59512,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "11.4" - ], "general-tisax-6-0-3": [ "1.5.1", "5.2.6" @@ -57892,6 +59592,9 @@ "CA-07(01)", "PM-14" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(7)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(1)" ], @@ -57899,12 +59602,12 @@ "155.260(a)(3)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.D.3", @@ -57957,122 +59660,42 @@ "2447(b)(8)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.1.11", + "3.3.3.19", + "3.3.6.25", + "3.4.6.41", + "3.4.6.46", + "3.4.6.48" ], "emea-eu-gdpr-2016": [ "Article 32.1(d)" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" - ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "SP-03" - ], - "emea-grc-pirppd-1997": [ - "10" - ], - "emea-hun-isdfi-2011": [ - "7" + "RB-05-DOAR", + "SPN-02", + "COM-02" ], - "emea-irl-dpa-2003": [ - "2" + "emea-isr-cmo-2-0": [ + "4.1, Stage 5" ], - "emea-isr-cmo-1-0": [ - "1.3", - "3.1" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35" - ], - "emea-nga-dpr-2019": [ - "4.1(5)(a)", - "4.1(5)(b)", - "4.1(5)(c)", - "4.1(5)(d)", - "4.1(5)(e)", - "4.1(5)(f)", - "4.1(5)(g)", - "4.1(5)(h)", - "4.1(5)(i)", - "4.1(5)(j)", - "4.1(6)", - "4.1(7)" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" + "emea-qat-pdppl-2020": [ + "3.11.7" ], "emea-sau-cscc-1-2019": [ - "1-4" + "1-4-1" ], "emea-sau-cgiot-2024": [ "1-7-3" ], "emea-sau-ecc-1-2018": [ - "1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1" + "1-8-1", + "1-8-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.4" - ], - "emea-zaf-popia-2013": [ - "8", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1", - "Article 10.2", - "Article 10.3" + "3.2.5" ], "emea-esp-decree-311-2022": [ - "10.1", - "10.2", - "10.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "Article 16(1)" ], "emea-gbr-def-stan-05-138-2024": [ "1206" @@ -58083,42 +59706,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1206" ], - "apac-aus-privacy-act-1998": [ - "APP Part 11" - ], "apac-aus-ps-cps-230-2023": [ - "29", - "30", + "58", + "58(a)", "58(b)", "58(c)" ], "apac-aus-ps-cps-234-2019": [ - "27", - "27(a)", - "27(b)", - "27(c)", - "27(d)", - "27(e)", - "29" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "54" - ], - "apac-hkg-pdo-2022": [ - "Principle 4" - ], - "apac-ind-privacy-rules-2011": [ - "8" + "29", + "31" ], "apac-ind-sebi-2024": [ "EV.ST.S4" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "4.6.1.1", "4.6.2.2", @@ -58127,10 +59727,10 @@ "12.7.1.8", "12.7.1.9" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "13.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -58141,34 +59741,18 @@ "6.1.7.C.01", "23.2.18.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24" - ], "apac-sgp-mas-trm-2021": [ - "3.2.3" - ], - "apac-twn-pdpa-2025": [ - "27" + "3.2.3", + "15.1.1" ], "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.10" + "5.4", + "5.6", + "5.7-BP2" ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" ] } }, @@ -58193,7 +59777,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to implement an internal audit function that is capable of providing senior organization management with insights into the appropriateness of the organization's technology and information governance processes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -58284,7 +59868,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -58377,7 +59962,8 @@ "03.12.01" ], "general-nist-800-171a-r3": [ - "A.03.12.01.ODP[01]" + "A.03.12.01.ODP[01]", + "A.03.12.01" ], "general-tisax-6-0-3": [ "1.5.1", @@ -58396,60 +59982,36 @@ "5.260.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.3.6(25)" + "3.3.1.11", + "3.3.6.25" ], "emea-eu-nis2-annex-2024": [ "2.3.2" ], + "emea-deu-c5-2020": [ + "SPN-03" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 5" + ], "emea-sau-cscc-1-2019": [ - "1-4-2", - "2-13-4" + "1-4-2" ], "emea-sau-ecc-1-2018": [ - "1-8-1", "1-8-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.5" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 41.1", - "Article 41.2" - ], - "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "41.1", - "41.2" + "3.2.5.1" ], "apac-aus-ps-cps-230-2023": [ - "46", - "60" + "46" ], "apac-aus-ps-cps-234-2019": [ - "31", "32", - "33", "34", "34(a)", "34(b)" ], - "apac-chn-pipl-2021": [ - "54" - ], "apac-ind-dpdpa-2023": [ "10(2)(b)" ], @@ -58457,7 +60019,10 @@ "4.6.2.2", "4.6.2.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "13.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -58466,19 +60031,7 @@ ], "apac-sgp-mas-trm-2021": [ "15.1.1", - "15.1.2", - "15.1.3", - "15.1.4" - ], - "americas-bmu-mba-coc-2020": [ - "5.4", - "5.6" - ], - "amaericas-can-osfi-self-assessment": [ - "6.17", - "6.18", - "6.19", - "6.20" + "15.1.2" ], "americas-can-itsp-10-171-2025": [ "03.12.01" @@ -58490,7 +60043,7 @@ "title": "Periodic Audits", "family": "CPL", "description": "Mechanisms exist to conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures.", - "scf_question": "Does the organization conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures?", + "scf_question": "Does the organization conduct periodic audits of security, compliance and resilience controls to evaluate conformity with its documented policies, standards and procedures?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -58503,17 +60056,23 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.\n▪ Specialized assessments are conducted for specific statutory, regulatory and/or contractual compliance obligations, as well as business-critical TAASD.\n▪ IT and/or cybersecurity use an impartial member of its team or a third-party assessor to perform an independent assessment of cybersecurity and data protection controls.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Annual self-assessment against applicable compliance requirements\n∙ External compliance review if contractually required", + "small": "∙ Annual internal review of key security controls\n∙ External audit for compliance requirements", + "medium": "∙ Internal audit program\n∙ Annual external compliance audits\n∙ GRC platform for audit tracking.", + "large": "∙ Enterprise internal audit function\n∙ Annual external audits.\n∙ GRC platform with audit management", + "enterprise": "∙ Enterprise internal audit program with dedicated resources\n∙ Multiple external compliance audits\n∙ Continuous control monitoring and automated audit reporting" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -58587,9 +60146,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-cobit-2019": [ @@ -58610,6 +60169,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(6)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(3)" + ], "usa-state-nv-regulation-5-2024": [ "5.260.5(b)" ], @@ -58620,9 +60182,22 @@ "2.3.2", "2.3.4" ], + "emea-deu-c5-2020": [ + "RB-05-DOAR", + "SPN-02", + "SPN-02-DOAR", + "COM-02", + "COM-02-BP1", + "COM-02-BP2", + "COM-02-BP3", + "COM-03" + ], "emea-sau-cgiot-2024": [ "1-7-1" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.5.2" + ], "emea-gbr-def-stan-05-138-2024": [ "1206" ], @@ -58637,6 +60212,17 @@ ], "apac-ind-sebi-2024": [ "DE.CM.S5" + ], + "apac-nzl-ism-3-9": [ + "17.9.33.C.01", + "17.9.33.C.02", + "17.9.33.C.03" + ], + "apac-sgp-mas-trm-2021": [ + "15.1.3" + ], + "americas-arg-ppd-2018": [ + "E.1.4-DS-2" ] } }, @@ -58658,7 +60244,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to take corrective action to remediate instances of non-conformity with applicable statutory, regulatory, and/or contractual compliance obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -58668,7 +60254,13 @@ "CORE AI Model Deployment", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Corrective action log (spreadsheet)\n∙ Documented remediation plans for audit findings", + "small": "∙ Corrective action register with remediation tracking\n∙ Management review of open findings", + "medium": "∙ Formal corrective action plan process\n∙ GRC platform for finding tracking and remediation\n∙ Management review of open findings", + "large": "∙ Enterprise corrective action management program\n∙ GRC platform with workflow-driven remediation tracking\n∙ Executive reporting on open findings", + "enterprise": "∙ Enterprise GRC platform for corrective action management\n∙ Automated finding tracking and escalation workflows\n∙ Board-level reporting on material findings" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -58742,13 +60334,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { "general-iso-29100-2024": [ "6.12" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(7)" + ], "emea-eu-ai-act-2024": [ "Article 79.4", "Article 80.4", @@ -58757,20 +60353,15 @@ "Article 93.1(a)", "Article 93.1(b)", "Article 93.1(c)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.12", - "Article 13.6", - "Article 14.4" ] } }, { "control_id": "CPL-03", - "title": "Security, Compliance & Resilience Assessments", + "title": "Control Conformity Monitoring", "family": "CPL", - "description": "Mechanisms exist to regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", - "scf_question": "Does the organization regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements?", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "scf_question": "Does the organization validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to its security, compliance and/or resilience policies, standards and other applicable requirements?", "relative_weight": 10, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -58788,7 +60379,7 @@ "0": "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.", "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments. \n▪ For specific statutory, regulatory and/or contractual obligations, stakeholders may contract with a third-party auditor/assessor to perform an independent assessment of cybersecurity and data protection controls.", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -58799,8 +60390,8 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", - "small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", + "micro_small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, SimpleRisk, etc.)", + "small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, SimpleRisk, etc.)", "medium": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", "large": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", "enterprise": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)" @@ -58876,9 +60467,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", + "errata": "- renamed control\n- wordsmithed control", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -59009,10 +60601,8 @@ "03.12.03" ], "general-nist-800-171a-r3": [ - "A.03.12.01" - ], - "general-nist-800-172": [ - "3.11.5e" + "A.03.12.01", + "A.03.12.03[01]" ], "general-nist-csf-2-0": [ "ID.IM-01", @@ -59036,9 +60626,6 @@ "10.7.3", "12.4.2" ], - "general-scf-dpmp-2025": [ - "11.3" - ], "general-tisax-6-0-3": [ "1.5.2", "5.2.6" @@ -59073,16 +60660,20 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(1)", + "101.630(f)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "usa-federal-irs-1075-2021": [ "CA-2" @@ -59111,119 +60702,106 @@ "CA-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41", + "3.4.6.44" ], "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3", - "29" - ], "emea-deu-bsrit-2017": [ + "3.7", "5.6" ], "emea-deu-c5-2020": [ - "COM-03" + "OIS-01-BP2", + "OIS-01-BP3" ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "3.1" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-qat-pdppl-2020": [ - "11.7", - "11.8" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-sau-cscc-1-2019": [ - "1-4-1", - "2-13-4" + "emea-isr-cmo-2-0": [ + "4.2, Stage 5" ], "emea-sau-ecc-1-2018": [ "1-3-2", - "1-8-1" + "1-8-1", + "1-8-2", + "2-2-4" ], "emea-sau-otcc-1-2022": [ - "1-6", + "1-4-2", + "1-5-4", "1-6-1", - "1-6-2" + "1-7-2", + "2-1-2", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-7-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-1-9", + "2-13-2", + "3-1-2", + "4-1-2" ], "emea-sau-sama-csf-1-2017": [ "3.2.4", - "3.2.5" - ], - "emea-zaf-popia-2013": [ - "8", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7" + "3.2.4.1", + "3.2.4.2", + "3.2.4.3", + "3.2.4.4", + "3.2.4.5", + "3.2.4.5.a", + "3.2.4.5.b", + "3.2.4.5.c", + "3.3.1.2", + "3.3.2.2", + "3.3.3.2", + "3.3.4.2", + "3.3.5.2", + "3.3.5.3", + "3.3.6.2", + "3.3.6.3", + "3.3.7.2", + "3.3.7.3", + "3.3.8.2", + "3.3.8.3", + "3.3.9.2", + "3.3.9.3", + "3.3.10.2", + "3.3.10.3", + "3.3.11.2", + "3.3.11.3", + "3.3.14.2", + "3.3.14.4.i", + "3.3.14.4.l", + "3.3.15", + "3.3.15.2", + "3.3.16", + "3.3.16.2", + "3.3.17.2", + "3.4.1.2", + "3.4.1.3", + "3.4.2", + "3.4.2.2", + "3.4.3.2" ], "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7" + "Article 15(1)" ], - "apac-aus-ps-cps-234-2019": [ - "30" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], - "apac-chn-pipl-2021": [ - "38(1)", - "38(2)", - "40" + "apac-aus-ps-cps-230-2023": [ + "30" ], "apac-ind-sebi-2024": [ "EV.ST.S5" ], - "apac-jpn-ppi-2020": [ - "40(1)", - "40(2)", - "40(3)" - ], "apac-jpn-ismap": [ "4.6.2.3", "4.6.2.5", @@ -59246,8 +60824,9 @@ "18.2.2.7", "18.2.2.8" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "11.9", + "13.1" ], "apac-nzl-ism-3-9": [ "4.3.16.C.01", @@ -59255,24 +60834,27 @@ "6.1.9.C.01", "23.2.18.C.01" ], - "apac-phl-dpa-2012": [ - "25" + "apac-sgp-mas-trm-2021": [ + "4.5.1", + "9.1.6", + "11.2.8" ], - "apac-sgp-pdpa-2012": [ - "24" + "americas-arg-ppd-2018": [ + "E.1.4-DS-1" ], - "apac-sgp-mas-trm-2021": [ - "4.5.1" + "americas-bhs-dpa-2003": [ + "VI.55", + "VI.55(a)", + "VI.55(b)" ], - "amaericas-can-osfi-self-assessment": [ - "6.10" + "americas-bmu-mba-coc-2020": [ + "5.7", + "6.21", + "6.22" ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03" - ], - "americas-chl-act-19628-1999": [ - "7" ] } }, @@ -59382,9 +60964,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-cobit-2019": [ @@ -59464,6 +61046,10 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-07(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(4)(ii)", + "101.630(f)(4)(iii)" + ], "usa-federal-irs-1075-2021": [ "CA-7(CE-1)" ], @@ -59479,26 +61065,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(c)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module H.3.1", - "Annex 6 Module H.3.5" - ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(25)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)(a)", - "3.4.6(43)(b)" + "3.3.6.25", + "3.4.6.41" ], "emea-eu-nis2-annex-2024": [ "2.3.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-c5-2020": [ - "COM-03" - ], "emea-sau-cscc-1-2019": [ "1-4-2" ], @@ -59509,26 +61082,9 @@ "1-8-2" ], "emea-sau-otcc-1-2022": [ - "1-6-1", "1-6-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-20", - "TPC-21" - ], - "emea-zaf-popia-2013": [ - "60" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 38.1" - ], - "emea-esp-decree-311-2022": [ - "38.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0100" ], "apac-aus-ps-cps-234-2019": [ @@ -59537,11 +61093,6 @@ "apac-chn-cybersecurity-law-2017": [ "Article 38" ], - "apac-chn-pipl-2021": [ - "38(1)", - "38(2)", - "40" - ], "apac-ind-dpdpa-2023": [ "10(2)(b)" ], @@ -59561,12 +61112,13 @@ "18.2.1.10.P", "18.2.1.13.P" ], + "apac-mys-bnm-rmit-2025": [ + "13.4", + "14.1", + "14.2" + ], "apac-nzl-ism-3-9": [ "6.1.8.C.01" - ], - "amaericas-can-osfi-self-assessment": [ - "6.13", - "6.25" ] } }, @@ -59575,7 +61127,7 @@ "title": "Functional Review Of Security, Compliance & Resilience Controls", "family": "CPL", "description": "Mechanisms exist to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards.", - "scf_question": "Does the organization regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards?", + "scf_question": "Does the organization regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to its security, compliance and/or resilience policies and standards?", "relative_weight": 8, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -59590,9 +61142,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -59683,9 +61235,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -59809,10 +61361,13 @@ "RA-3" ], "general-nist-800-171-r3": [ + "03.04.02.b", "03.04.08.c", "03.12.03" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.08.c", "A.03.12.03[02]" ], "general-nist-csf-2-0": [ @@ -59883,14 +61438,14 @@ "RA-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "usa-federal-irs-1075-2021": [ "CA-2", @@ -59917,69 +61472,18 @@ "RA-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41" ], "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3" - ], "emea-deu-bsrit-2017": [ "5.6" ], - "emea-deu-c5-2020": [ - "COM-01" - ], - "emea-isr-cmo-1-0": [ - "3.1", - "3.3", - "12.30" - ], - "emea-qat-pdppl-2020": [ - "11.7", - "11.8" - ], - "emea-sau-cscc-1-2019": [ - "1-4-1" - ], "emea-sau-cgiot-2024": [ "1-7-1" ], - "emea-sau-ecc-1-2018": [ - "1-8-1" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 38.1" - ], - "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "38.1" - ], "emea-gbr-def-stan-05-138-2024": [ "1206" ], @@ -59989,8 +61493,8 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1206" ], - "apac-chn-pipl-2021": [ - "54" + "apac-aus-ps-cps-234-2019": [ + "33" ], "apac-ind-sebi-2024": [ "DE.CM.S5" @@ -60009,12 +61513,14 @@ "23.2.18.C.01" ], "apac-sgp-mas-trm-2021": [ - "4.5.1" + "4.5.1", + "11.2.8" ], "americas-bmu-mba-coc-2020": [ - "5.7" + "5.7-BP1" ], "americas-can-itsp-10-171-2025": [ + "03.04.02.B", "03.04.08.C", "03.12.03" ] @@ -60038,7 +61544,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to grant assessors minimum necessary access to conduct conformity assessments, including:\n(1) Logical access to design, development, production, inspection and testing artifacts; and \n(2) Physical access to facilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60125,7 +61631,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -60141,13 +61648,6 @@ "IV.C.2.e.iii", "IV.C.2.e.iv", "IV.C.2.f" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 13.8", - "Article 14.5" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module H.4.2" ] } }, @@ -60169,7 +61669,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define acceptable methods to conduct a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60258,7 +61758,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -60281,7 +61782,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define the level of assessment rigor necessary to conduct a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60370,7 +61871,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -60393,7 +61895,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define an Evidence Request List (ERL) prior to the start of a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60482,7 +61984,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -60505,7 +62008,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define evidence sampling criteria for cybersecurity and/or data protection assessments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60594,8 +62097,123 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ], + "family_name": "Compliance", + "crosswalks": {} + }, + { + "control_id": "CPL-03.8", + "title": "Continuous Control Monitoring (CCM)", + "family": "CPL", + "description": "Automated mechanisms exist to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "scf_question": "Does the organization use automated mechanisms to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Periodic manual control reviews", + "small": "∙ GRC solution with control tracking\n∙ Regular control status reviews", + "medium": "∙ GRC platform with control monitoring\n∙ Regular automated control status reporting", + "large": "∙ GRC platform with continuous control monitoring\n∙ Integration with SIEM and vulnerability management\n∙ Automated control evidence collection", + "enterprise": "∙ Enterprise continuous control monitoring platform\n∙ Automated evidence collection and control testing\n∙ Real-time control dashboards\n∙ Integration with GRC, SIEM, and asset management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-1", + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ], + "errata": "- new control - SCF community", "family_name": "Compliance", "crosswalks": {} }, @@ -60617,7 +62235,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to thoughtfully plan audits by including input from operational risk and compliance partners to minimize the impact of audit-related activities on business operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60682,7 +62300,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -60709,13 +62328,6 @@ ], "general-nist-100-1-ai-rmf": [ "GOVERN 1.5" - ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-c5-2020": [ - "COM-02", - "COM-03" ] } }, @@ -60737,7 +62349,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with the organization's legal counsel for guidance on how to respond to legal orders (e.g., court orders, investigations, etc.).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to determine whether a government agency has an applicable and valid legal basis to request data from the organization and what further steps need to be taken, if necessary.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60824,7 +62436,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -60849,14 +62462,16 @@ "Article 92.4", "Article 92.5" ], - "emea-deu-c5-2020": [ - "INQ-01" - ], "apac-chn-cybersecurity-law-2017": [ "Article 72" ], - "apac-chn-pipl-2021": [ - "41" + "apac-sgp-pdpa-2012": [ + "3.12(d)", + "3.12(d)(i)", + "3.12(d)(ii)" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.2" ] } }, @@ -60878,7 +62493,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to notify customers about investigation request notifications, unless the applicable legal basis for a government agency's action prohibits notification (e.g., potential criminal prosecution).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60962,18 +62577,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { "general-csa-cmm-4-1-0": [ "DSP-18" ], - "emea-deu-c5-2020": [ - "INQ-02" - ], - "apac-chn-pipl-2021": [ - "18" + "apac-sgp-pdpa-2012": [ + "5.21(4)" ] } }, @@ -60995,7 +62608,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to support official investigations by provisioning government investigators with \"least privileges\" and \"least functionality\" to ensure that government investigators only have access to the TAASD needed to perform the investigation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61081,7 +62694,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -61091,6 +62705,9 @@ "usa-federal-doc-data-privacy-framework-2023": [ "III.5.b.ii" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(6)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(e)", "500.17(a)(2)" @@ -61104,23 +62721,21 @@ "emea-eu-ai-act-2024": [ "Article 21.2" ], - "emea-deu-c5-2020": [ - "INQ-03", - "INQ-04" + "emea-eu-cyber-resilience-act-2024": [ + "Article 53" + ], + "emea-aut-dpa-2018": [ + "§ 51", + "§ 52", + "§ 53" + ], + "emea-che-fadp-2025": [ + "2.2.15.2" ], "apac-chn-cybersecurity-law-2017": [ "Article 28", "Article 55", "Article 56" - ], - "apac-chn-pipl-2021": [ - "61(4)", - "63", - "63(1)", - "63(2)", - "63(3)", - "63(4)", - "64" ] } }, @@ -61142,7 +62757,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to constrain the host government from having unrestricted and non-monitored access to the organization's TAASD that could potentially violate other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61208,7 +62823,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -61217,24 +62833,11 @@ "Article 29" ], "apac-chn-data-security-law-2021": [ - "24", - "27", - "31", - "33", - "44" + "Article 27", + "Article 31" ], "apac-chn-pipl-2021": [ - "11", - "12", - "26", - "38(4)", - "40", - "47(5)", - "60", - "61(4)", - "63(3)", - "63(4)", - "64" + "Article 38" ] } }, @@ -61243,7 +62846,7 @@ "title": "Grievances", "family": "CPL", "description": "Mechanisms exist to govern the intake and analysis of grievances related to the organization's cybersecurity and/or data protection practices.", - "scf_question": "Does the organization govern the intake, analysis, assignment and remediation of grievances related to its cybersecurity and/or data protection practices?", + "scf_question": "Does the organization govern the intake and analysis of grievances related to its cybersecurity and/or data protection practices?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -61256,7 +62859,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61328,15 +62931,34 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(17)" + ], + "apac-aus-privacy-principles-2026": [ + "1.1.2.b" + ], "apac-ind-dpdpa-2023": [ "13(1)" ], + "apac-ind-privacy-rules-2011": [ + "5(9)" + ], + "apac-jpn-appi-2020": [ + "IV.5.52(1)", + "IV.5.52(2)", + "IV.5.52(3)" + ], "apac-jpn-ismap": [ "18.1.2.13.PB" + ], + "apac-mys-bnm-rmit-2025": [ + "10.35", + "12.8" ] } }, @@ -61358,7 +62980,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to respond to legitimate grievances related to the organization's cybersecurity and/or data protection practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61430,7 +63052,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -61457,7 +63080,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to appoint localized representation with a physical presence in localities, as required by applicable laws and/or regulations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61555,7 +63178,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -61566,12 +63190,19 @@ "Article 23.1(d)", "Article 54.1" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 12.1" + "emea-sau-ecc-1-2018": [ + "4-1-3-2" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" + "emea-srb-act-9-2018": [ + "IV.1.44" + ], + "emea-che-fadp-2025": [ + "2.2.14.1", + "2.2.14.2", + "2.2.14.3" + ], + "apac-chn-pipl-2021": [ + "Article 53" ] } }, @@ -61593,7 +63224,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to contract localized representation to perform specified functions in regard to representing statutory and/or regulatory compliance matters.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61691,7 +63322,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -61704,16 +63336,6 @@ "Article 54.3(d)", "Article 54.4", "Article 54.5" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 12.3", - "Article 12.3(a)", - "Article 12.3(b)", - "Article 12.3(c)" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" ] } }, @@ -61735,7 +63357,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define instances of control reciprocity within assessment boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61768,7 +63390,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -61791,7 +63414,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define instances of control inheritance within assessment boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61824,7 +63447,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -61847,7 +63471,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern technologies and/or data that have potential:\n(1) \"Dual-use” capabilities for civil and military;\n(2) Use by terrorists; and/or \n(3) Weapons of Mass Destruction (WMD) applications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61923,7 +63547,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -61946,7 +63571,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify if the organization handles United States Munitions List (USML) or Commerce Control List (CCL):\n(1) Items;\n(2) Technical data; and/or\n(3) Provides defense services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62022,7 +63647,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -62045,7 +63671,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict logical and physical access to United States (US) export-controlled data to US: \n(1) Citizens; and/or\n(2) Green Card holders.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62121,7 +63747,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -62144,7 +63771,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to generate detailed logs of export-controlled data including:\n(1) Logical and physical access; and\n(2) Export activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62220,7 +63847,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -62245,7 +63873,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce a Statement of Applicability (SOA), or similar document, for compliance-related scoping activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62271,7 +63899,8 @@ "MT-8", "MT-9", "MT-14", - "MT-15" + "MT-15", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -62298,7 +63927,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce work products (e.g., process artifacts) that demonstrate the ability to comply with applicable requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62323,9 +63952,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (CERT-RMM 1.2)", "family_name": "Compliance", "crosswalks": { "general-iso-21434-2021": [ @@ -62390,6 +64019,9 @@ "VAR:GG3.GP2", "GG1.GP1", "GG3.GP2" + ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.640" ] } }, @@ -62411,7 +64043,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce evidence of due diligence activities performed, capable of withstanding external audit or regulatory scrutiny.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62440,13 +64072,17 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control", "family_name": "Compliance", "crosswalks": { "apac-jpn-ismap": [ "4.6.2.7" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.21" ] } }, @@ -62468,7 +64104,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce evidence of due care activities performed, capable of withstanding external audit or regulatory scrutiny.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62497,9 +64133,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control", "family_name": "Compliance", "crosswalks": { "apac-jpn-ismap": [ @@ -62532,7 +64168,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to facilitate the implementation of configuration management controls.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -62611,7 +64247,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -62625,8 +64262,8 @@ "CC8.1-POF12" ], "general-cis-csc-8-1": [ - "2.0", - "4.0", + "2", + "4", "4.1", "4.2" ], @@ -62756,9 +64393,11 @@ "NFO - CM-9" ], "general-nist-800-171-r3": [ - "03.04.01.a" + "03.04.01.a", + "03.04.03.a" ], "general-nist-800-171a-r3": [ + "A.03.04.01.a[02]", "A.03.04.03.a" ], "general-nist-800-207": [ @@ -62777,9 +64416,6 @@ "2.2", "8.5" ], - "general-scf-dpmp-2025": [ - "7.12" - ], "general-sparta": [ "CM0023" ], @@ -62819,10 +64455,10 @@ "CM-09" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "CM-1", @@ -62870,56 +64506,19 @@ "6.3.1", "6.3.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "6.8" - ], - "emea-deu-c5-2020": [ - "AM-03" - ], - "emea-isr-cmo-1-0": [ - "3.3", - "9.22", - "9.23", - "14.1" - ], "emea-sau-cscc-1-2019": [ "2-3-1-6" ], - "emea-sau-ecc-1-2018": [ - "1-6-2-2", - "2-4-4", - "2-5-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 30.1", - "Article 30.2" - ], - "emea-esp-decree-311-2022": [ - "30.1", - "30.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.3 [OP.EXP.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-caf-4-0": [ "B4", "B4.c" ], - "emea-gbr-cap-1850-2020": [ - "B4" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "apac-aus-ism-2026-march": [ + "ISM-0912" ], "apac-ind-sebi-2024": [ "PR.IP.S3" @@ -62930,29 +64529,28 @@ "12.2.5.C.02", "12.2.6.C.01", "12.2.6.C.02", + "17.9.38.C.03", "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", - "18.1.10.C.04" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)" + "18.1.10.C.04", + "20.2.14.C.02" ], "apac-sgp-mas-trm-2021": [ - "7.2.1", - "7.2.2", - "7.3.1", - "7.3.2", - "7.3.3" + "7.2.1" ], "americas-bmu-mba-coc-2020": [ - "6.1" + "6.1-BP1" ], "americas-can-osfi-b13-2022": [ "3.2.8" ], "americas-can-itsp-10-171-2025": [ - "03.04.01.A" + "03.04.01.A", + "03.04.03.A" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(c)" ] } }, @@ -63042,7 +64640,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -63073,6 +64672,10 @@ "general-pci-dss-4-0-1": [ "2.1" ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" + ], "apac-nzl-ism-3-9": [ "4.3.19.C.01" ] @@ -63109,9 +64712,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -63184,7 +64787,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -63206,6 +64810,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -63230,6 +64835,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -63244,6 +64850,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -63342,7 +64949,7 @@ "8.25", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -63825,6 +65432,7 @@ ], "general-nist-800-171-r3": [ "03.01.01.h", + "03.01.03", "03.01.08.a", "03.01.08.b", "03.01.09", @@ -63834,16 +65442,22 @@ "03.01.11", "03.01.12.a", "03.01.16.a", + "03.01.16.c", "03.01.18.a", + "03.03.08.a", "03.04.01.a", "03.04.02.a", + "03.04.02.b", "03.04.06.a", "03.04.06.b", "03.04.06.d", + "03.05.04", + "03.05.07.c", "03.05.07.d", "03.05.07.e", "03.05.07.f", "03.05.12.d", + "03.07.05.b", "03.08.07.a", "03.13.12.b" ], @@ -63855,7 +65469,17 @@ "3.4.2[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.08.a", + "A.03.01.08.b", + "A.03.01.09", + "A.03.01.10.a", + "A.03.01.10.b", + "A.03.01.10.c", + "A.03.01.11", + "A.03.01.12.a[03]", "A.03.01.16.a[03]", "A.03.01.16.c", "A.03.01.18.a[02]", @@ -63869,18 +65493,48 @@ "A.03.04.06.ODP[03]", "A.03.04.06.ODP[04]", "A.03.04.06.ODP[05]", + "A.03.04.06.a", "A.03.04.06.b[01]", "A.03.04.06.b[02]", "A.03.04.06.b[03]", "A.03.04.06.b[04]", "A.03.04.06.b[05]", + "A.03.04.06.d", "A.03.05.04[01]", "A.03.05.04[02]", "A.03.05.07.c", "A.03.05.07.d", "A.03.05.07.e", "A.03.05.07.f", - "A.03.07.05.b[02]" + "A.03.05.12.d", + "A.03.07.05.b[01]", + "A.03.08.07.a", + "A.03.13.12.b" + ], + "general-nist-800-172-r3": [ + "03.01.04E", + "03.01.14E", + "03.01.16E", + "03.05.01E", + "03.05.05E", + "03.12.04E", + "03.13.06E", + "03.13.11E", + "03.13.13E", + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.04E.ODP[01]", + "A.03.01.14E.ODP[03]", + "A.03.01.14E.ODP[04]", + "DS-A.03.01.16E", + "A.03.05.01E.ODP[01]", + "DS-A.03.05.05E", + "DS-A.03.12.04E.c", + "A.03.13.06E.ODP[01]", + "DS-A.03.13.11E[02]", + "A.03.13.13E.ODP[01]", + "A.03.14.11E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -63995,9 +65649,6 @@ "10.6.2", "10.6.3" ], - "general-scf-dpmp-2025": [ - "7.12" - ], "general-shared-assessments-sig-2025": [ "N.11" ], @@ -64100,20 +65751,24 @@ "SA-08", "SA-15(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(2)", + "101.650(c)(2)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "3.3.8.b", @@ -64249,7 +65904,7 @@ "Article 17.1(e)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(b)" + "3.4.4.36(b)" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -64270,28 +65925,37 @@ "6.8" ], "emea-deu-c5-2020": [ - "AM-02", - "AM-03", - "OPS-23" - ], - "emea-isr-cmo-1-0": [ - "3.3", - "4.9", - "4.12", - "4.15", - "6.1", - "9.21", - "12.13", - "12.24", - "12.29", - "13.5", - "13.6", - "14.2", - "15.6" + "RB-05", + "RB-22", + "RB-22-DOAR", + "IDM-11", + "IDM-11-BP1", + "IDM-11-BP2", + "IDM-11-BP3", + "IDM-11-BP4", + "IDM-11-BP5", + "IDM-11-DOAR", + "IDM-11-DOAR-BP1", + "IDM-11-DOAR-BP2", + "IDM-11-DOAR-BP3", + "IDM-11-DOAR-BP4", + "IDM-11-DOAR-BP5", + "IDM-11-DOAR-BP6", + "IDM-11-DOAR-BP7" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 3.1", + "Appendix A, 4.1", + "Appendix A, 4.2" ], "emea-sau-cscc-1-2019": [ "1-3-2-3", - "2-3-1-7" + "2-2-1-5", + "2-2-1-6", + "2-3-1-6", + "2-3-1-7", + "2-4-1-3", + "2-12-1" ], "emea-sau-cgiot-2024": [ "1-2-2", @@ -64302,36 +65966,47 @@ ], "emea-sau-ecc-1-2018": [ "1-3-3", - "2-4-1", - "2-4-2", - "5-1-3-7" + "2-4-1" ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-1", - "2-3-1-7" + "2-2-1-8", + "2-4-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 20(d)" + "VII.A.TPC-2", + "VII.A.TPC-2-BP1", + "VII.A.TPC-2-BP2", + "VII.A.TPC-2-BP3", + "VII.A.TPC-2-BP4", + "VII.A.TPC-2-BP5", + "VII.A.TPC-10", + "VII.B.TPC-56", + "VII.B.TPC-62", + "VII.B.TPC-63", + "VII.B.TPC-63-BP1", + "VII.B.TPC-63-BP2", + "VII.B.TPC-63-BP3", + "VII.B.TPC-63-BP4" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.6", + "3.3.6.1", + "3.3.13.4.c.2" ], "emea-esp-decree-311-2022": [ - "20(d)" + "Article 12(7)", + "Article 20(a)", + "Article 20(c)", + "Article 20(d)", + "Single Transitional Provision(3)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.2 [OP.EXP.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "op.exp.2", + "op.exp.3", + "mp.sw.1", + "mp.info.4", + "mp.s.2" ], "emea-uae-niaf-2023": [ "3.2.1" @@ -64340,11 +66015,9 @@ "B4", "B4.b" ], - "emea-gbr-cap-1850-2020": [ - "B4" - ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "2-BP3", + "2-BP4" ], "emea-gbr-def-stan-05-138-2024": [ "2204", @@ -64385,7 +66058,7 @@ "ML3-P6", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0341", "ISM-0343", "ISM-0345", @@ -64414,7 +66087,79 @@ "ISM-1654", "ISM-1655", "ISM-1710", - "ISM-1745" + "ISM-1745", + "ISM-1823", + "ISM-1824", + "ISM-1825", + "ISM-1828", + "ISM-1829", + "ISM-1830", + "ISM-1836", + "ISM-1838", + "ISM-1839", + "ISM-1840", + "ISM-1841", + "ISM-1844", + "ISM-1846", + "ISM-1858", + "ISM-1859", + "ISM-1860", + "ISM-1861", + "ISM-1870", + "ISM-1871", + "ISM-1886", + "ISM-1887", + "ISM-1888", + "ISM-1890", + "ISM-1891", + "ISM-1896", + "ISM-1897", + "ISM-1913", + "ISM-1914", + "ISM-1915", + "ISM-1916", + "ISM-1928", + "ISM-1929", + "ISM-1930", + "ISM-1931", + "ISM-1932", + "ISM-1933", + "ISM-1934", + "ISM-1935", + "ISM-1936", + "ISM-1938", + "ISM-1943", + "ISM-1944", + "ISM-1945", + "ISM-1946", + "ISM-1947", + "ISM-1948", + "ISM-1949", + "ISM-1950", + "ISM-1951", + "ISM-1952", + "ISM-1953", + "ISM-1954", + "ISM-1955", + "ISM-1956", + "ISM-1957", + "ISM-1958", + "ISM-1962", + "ISM-1980", + "ISM-1984", + "ISM-2010", + "ISM-2012", + "ISM-2047", + "ISM-2049", + "ISM-2079", + "ISM-2080", + "ISM-2081", + "ISM-2096", + "ISM-2097", + "ISM-2098" + ], + "apac-aus-cop-sitc-2020": [ + "6" ], "apac-ind-sebi-2024": [ "PR.IP.S1" @@ -64422,7 +66167,7 @@ "apac-jpn-ismap": [ "8.3.1.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP54", "HHSP60", "HHSP65", @@ -64431,40 +66176,84 @@ "HML60", "HML64" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP14", "HSUP46", "HSUP52" ], "apac-nzl-ism-3-9": [ + "11.1.16.C.01", + "11.1.16.C.02", + "11.1.17.C.01", + "11.1.17.C.03", + "11.8.6.C.01", + "11.8.6.C.02", "14.1.8.C.01", "14.1.9.C.01", "14.1.9.C.02", "14.1.10.C.01", "14.1.10.C.02", "14.3.7.C.01", + "15.2.41.C.01", + "15.2.41.C.02", + "15.2.42.C.01", + "15.2.43.C.01", + "15.2.44.C.01", + "15.2.46.C.01", + "15.2.46.C.03", + "15.2.47.C.01", + "15.2.47.C.02", + "15.2.48.C.01", + "15.2.48.C.02", + "15.2.48.C.03", + "15.2.49.C.01", + "15.2.49.C.02", + "15.2.49.C.03", + "15.2.50.C.01", + "15.2.50.C.02", + "15.2.50.C.03", + "15.2.50.C.04", + "16.1.31.C.03", + "16.1.31.C.04", + "16.1.31.C.05", + "16.7.42.C.01", + "20.2.14.C.05", + "20.2.14.C.07", + "22.1.16.C.01", + "22.1.16.C.02", + "22.1.17.C.01", + "22.1.17.C.02", + "22.1.17.C.03", + "22.1.19.C.01", + "22.1.19.C.02", "23.2.21.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)" + "4.3(a)", + "4.3(b)" ], "apac-sgp-mas-trm-2021": [ - "11.2.5", - "11.3.1", - "11.3.2" + "6.4.4", + "7.2.2", + "11.1.5", + "11.3.1" ], - "amaericas-can-osfi-self-assessment": [ - "4.16", - "4.20" + "americas-arg-ppd-2018": [ + "B.2.4-4", + "E.1.2-5" + ], + "americas-bmu-mba-coc-2020": [ + "6.15-BP5" ], "americas-can-osfi-b13-2022": [ "3.2.8" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.8" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", + "03.01.03", "03.01.08.A", "03.01.08.B", "03.01.09", @@ -64474,16 +66263,22 @@ "03.01.11", "03.01.12.A", "03.01.16.A", + "03.01.16.C", "03.01.18.A", + "03.03.08.A", "03.04.01.A", "03.04.02.A", + "03.04.02.B", "03.04.06.A", "03.04.06.B", "03.04.06.D", + "03.05.04", + "03.05.07.C", "03.05.07.D", "03.05.07.E", "03.05.07.F", "03.05.12.D", + "03.07.05.B", "03.08.07.A", "03.13.12.B" ] @@ -64509,11 +66304,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to review and update baseline configurations:\n(1) At least annually;\n(2) When required due to so; or\n(3) As part of system component installations and upgrades.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -64583,7 +66378,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -64681,7 +66477,7 @@ ], "general-nist-800-171-r3": [ "03.04.01.b", - "03.04.02.b" + "03.04.06.c" ], "general-nist-800-171a-r3": [ "A.03.04.01.ODP[01]", @@ -64760,24 +66556,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-02" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.46" + ], "emea-eu-nis2-annex-2024": [ "6.3.3" ], - "emea-isr-cmo-1-0": [ - "3.3", - "14.3" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-6" + "2-3-1-6", + "2-4-1-2" ], "emea-sau-cgiot-2024": [ "2-14-4" ], "emea-sau-ecc-1-2018": [ - "1-6-2-2" + "5-1-3-7" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-def-stan-05-138-2024": [ "2418" @@ -64796,19 +66593,19 @@ "ML3-P5", "ML3-P6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1407", "ISM-1588" ], "apac-ind-sebi-2024": [ "PR.IP.S1" ], - "apac-sgp-mas-trm-2021": [ - "11.2.5" + "apac-nzl-ism-3-9": [ + "15.2.45.C.01" ], "americas-can-itsp-10-171-2025": [ "03.04.01.B", - "03.04.02.B" + "03.04.06.C" ] } }, @@ -64834,7 +66631,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically govern and report on baseline configurations of Technology Assets, Applications and/or Services (TAAS) through Continuous Diagnostics and Mitigation (CDM), or similar technologies.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -64876,7 +66673,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -64967,14 +66765,23 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.d" + "03.04.03.d", + "03.13.13.b" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", "A.03.04.03.d[01]", - "A.03.04.03.d[02]" + "A.03.04.03.d[02]", + "A.03.13.13.b[02]" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-172-r3": [ + "03.04.02E", + "03.04.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.04.02E.ODP[03]", + "DS-A.03.04.03E[01]", + "A.03.04.04E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -65023,20 +66830,17 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.c" ], - "emea-isr-cmo-1-0": [ - "3.3", - "6.2", - "6.4", - "9.22", - "9.23", - "14.3", - "14.4" + "emea-sau-cscc-1-2019": [ + "2-3-1-6" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.2" + "emea-sau-ecc-1-2018": [ + "5-1-3-7" + ], + "emea-sau-otcc-1-2022": [ + "2-3-1-11" ], "emea-esp-decree-311-2022": [ - "21.2" + "Article 21(2)" ], "emea-gbr-def-stan-05-138-2024": [ "2415" @@ -65044,16 +66848,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2415" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)", - "4.3(b)" - ], "apac-sgp-mas-trm-2021": [ + "7.2.2", "11.3.2" ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.D" + "03.04.03.D", + "03.13.13.B" ] } }, @@ -65077,7 +66879,7 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Historical versions of configurations are maintained for troubleshooting and forensics purposes.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -65143,7 +66945,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -65177,6 +66980,13 @@ "general-nist-800-82-r3-high": [ "CM-02(03)" ], + "general-nist-800-172-r3": [ + "03.04.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.06E", + "A.03.04.06E.ODP[01]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.UNI.BRECO" ], @@ -65198,10 +67008,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-02 (03)" ], - "emea-isr-cmo-1-0": [ - "14.5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1510" ] } @@ -65228,7 +67035,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to manage baseline configurations for development and test environments separately from operational baseline configurations to minimize the risk of unintentional changes.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -65293,7 +67100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -65349,18 +67157,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-isr-cmo-1-0": [ - "10.1", - "10.2" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], "apac-nzl-ism-3-9": [ "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", "18.1.10.C.04" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.3" ] } }, @@ -65394,11 +67198,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) utilized in high-risk areas with more restrictive baseline configurations.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -65469,7 +67273,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -65562,13 +67367,17 @@ "03.04.01.a", "03.04.02.a", "03.04.06.a", - "03.04.06.b", "03.04.06.d", "03.04.12.a" ], "general-nist-800-171a-r3": [ + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.d", "A.03.04.12.ODP[01]", - "A.03.04.12.ODP[02]" + "A.03.04.12.ODP[02]", + "A.03.04.12.a" ], "general-nist-800-218": [ "PO.5.2" @@ -65686,6 +67495,9 @@ "usa-federal-gsa-fedramp-5-high": [ "CM-02(07)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(2)" + ], "usa-federal-irs-1075-2021": [ "CM-2(CE-7)", "CM-2(CE-7).a", @@ -65701,37 +67513,16 @@ "emea-eu-ai-act-2024": [ "Article 14.3(a)" ], - "emea-isr-cmo-1-0": [ - "4.12", - "9.21", - "10.7" - ], "emea-sau-cscc-1-2019": [ - "1-3-2-3", - "2-3-1-7" + "2-6-1-3" ], "emea-sau-ecc-1-2018": [ + "5-1-3-5", + "5-1-3-6", "5-1-3-7" ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" - ], - "emea-gbr-cap-1850-2020": [ - "B4" + "2-2-1-5" ], "emea-gbr-def-stan-05-138-2024": [ "2312" @@ -65745,7 +67536,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2312" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0534", "ISM-1656", "ISM-1657", @@ -65761,18 +67552,24 @@ "ISM-1674", "ISM-1675", "ISM-1676", - "ISM-1677", "ISM-1748", "ISM-1749", - "ISM-1800" + "ISM-1800", + "ISM-1867", + "ISM-1868" ], "apac-nzl-ism-3-9": [ + "15.2.38.C.01", "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", "18.1.10.C.04", "23.2.21.C.01" ], + "americas-arg-ppd-2018": [ + "E.1.2-2", + "E.1.2-DS-1" + ], "americas-can-osfi-b13-2022": [ "3.2.3" ], @@ -65780,9 +67577,9 @@ "03.04.01.A", "03.04.02.A", "03.04.06.A", - "03.04.06.B", "03.04.06.D", - "03.04.12.A" + "03.04.12.A", + "03.14.08.C" ] } }, @@ -65806,7 +67603,7 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -65866,7 +67663,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -65882,9 +67680,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.2.8" ], - "emea-isr-cmo-1-0": [ - "9.22" - ], "apac-nzl-ism-3-9": [ "18.1.10.C.01", "18.1.10.C.02", @@ -65913,11 +67708,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Any deviations from approved baseline configurations are reviewed, approved and documented on a case-by-case basis by IT and/or cybersecurity personnel.\n▪ Deviations to baseline configurations are required to have a risk assessment and the business process owner's acceptance of the risk(s) associated with the deviation.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to document, assess risk and approve or deny deviations to standardized configurations.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -65987,7 +67782,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -66057,12 +67853,9 @@ "03.04.02.b" ], "general-nist-800-171a-r3": [ - "A.03.04.02.b[01]", + "A.03.04.01.a[01]", "A.03.04.02.b[02]" ], - "general-nist-800-172": [ - "3.5.2e" - ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -66111,8 +67904,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-06" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(c)" + "apac-sgp-mas-trm-2021": [ + "11.3.2" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.8" ], "americas-can-itsp-10-171-2025": [ "03.04.01.A", @@ -66140,9 +67936,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to verify the functionality of security controls when anomalies or misconfigurations are discovered.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 3 Advanced Threats", @@ -66208,7 +68004,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -66254,8 +68051,12 @@ "general-nist-800-161-r1-level-3": [ "CM-6(2)" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.b", + "A.03.04.02E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -66289,10 +68090,6 @@ ], "emea-sau-otcc-1-2022": [ "2-3-1-11" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } }, @@ -66317,11 +68114,11 @@ }, "maturity": { "0": "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.", - "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment.\n▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices.", + "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment.\n▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.\n▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to allow baseline controls to be specialized or customized by applying a defined set of tailoring actions that are specific to:\n(1) Mission / business functions;\n(2) Operational environment;\n(3) Specific threats or vulnerabilities; or\n(4) Other conditions or situations that could affect mission / business success.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -66389,7 +68186,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -66436,7 +68234,14 @@ "03.13.11" ], "general-nist-800-171a-r3": [ - "A.03.03.02.b" + "A.03.03.02.b", + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.06.a", + "A.03.04.08.a", + "A.03.04.12.a", + "A.03.13.11" ], "general-shared-assessments-sig-2025": [ "N.11" @@ -66493,12 +68298,6 @@ "PL-11-SID.1", "PL-11-SID.2" ], - "emea-isr-cmo-1-0": [ - "10.7" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-7" - ], "emea-gbr-def-stan-05-138-2024": [ "2418" ], @@ -66515,10 +68314,6 @@ "9.5.2.P", "9.5.2.1.PB" ], - "apac-nzl-ism-3-9": [ - "16.1.50.C.01", - "16.1.50.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.03.02.B", "03.04.01.A", @@ -66562,9 +68357,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to provide only essential capabilities by specifically prohibiting or restricting the use of ports, protocols, and/or services.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to provide only essential capabilities by specifically prohibiting or restricting the use of ports, protocols, and/or services. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -66635,7 +68430,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -66645,7 +68441,7 @@ "CC6.7-POF1" ], "general-cis-csc-8-1": [ - "4.0", + "4", "4.6", "4.8" ], @@ -66700,7 +68496,7 @@ "8.9", "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -66983,7 +68779,15 @@ ], "general-nist-800-171a-r3": [ "A.03.04.02.ODP[01]", - "A.03.04.06.d" + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.b[01]", + "A.03.04.06.b[02]", + "A.03.04.06.b[03]", + "A.03.04.06.b[04]", + "A.03.04.06.b[05]", + "A.03.04.06.d", + "A.03.04.08.a" ], "general-nist-csf-2-0": [ "PR.PS-05" @@ -67090,30 +68894,18 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(f)" ], - "emea-isr-cmo-1-0": [ - "4.8", - "4.9", - "12.9", - "12.13" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-5" - ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-4" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 20(a)", - "Article 20(b)", - "Article 20(c)", - "Article 20(d)" + "2-4-1-14" ], "emea-esp-decree-311-2022": [ - "20(a)", - "20(b)", - "20(c)", - "20(d)" + "Article 20(c)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2204", @@ -67134,7 +68926,7 @@ "2430", "2507" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0385", "ISM-1006", "ISM-1311", @@ -67146,15 +68938,24 @@ "ISM-1489", "ISM-1621" ], + "apac-aus-cop-sitc-2020": [ + "6" + ], "apac-ind-sebi-2024": [ "PR.IP.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], "apac-nzl-ism-3-9": [ "18.1.15.C.01", "18.1.15.C.02", "18.1.15.C.03", "18.1.15.C.04" ], + "apac-sgp-mas-trm-2021": [ + "11.2.6" + ], "americas-can-osfi-b13-2022": [ "3.2.8" ], @@ -67189,7 +68990,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to periodically review system configurations to identify and disable unnecessary and/or non-secure functions, ports, protocols and services.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -67257,7 +69058,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -67338,7 +69140,9 @@ "3.4.7[o]" ], "general-nist-800-171a-r3": [ - "A.03.04.06.ODP[06]" + "A.03.04.06.ODP[06]", + "A.03.04.06.c", + "A.03.04.08.c" ], "general-pci-dss-4-0-1": [ "1.2.7", @@ -67407,11 +69211,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (01)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.2" - ], - "emea-esp-decree-311-2022": [ - "21.2" + "emea-sau-otcc-1-2022": [ + "2-3-1-2" ], "emea-gbr-def-stan-05-138-2024": [ "2430", @@ -67460,9 +69261,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the execution of unauthorized software programs.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the execution of unauthorized software programs. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -67531,7 +69332,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -67577,6 +69379,9 @@ "general-nist-800-171-r3": [ "03.04.08.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.08.b" + ], "general-nist-csf-2-0": [ "PR.PS-05" ], @@ -67607,17 +69412,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (02)" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], "apac-aus-essential-8-2024": [ "ML2-P5", "ML3-P5" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.04.08.B" ] @@ -67647,7 +69445,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to explicitly allow (allowlist / whitelist) and/or block (denylist / blacklist) applications that are authorized to execute on systems.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -67717,7 +69515,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -67816,8 +69615,17 @@ "A.03.04.08.ODP[01]", "A.03.04.08.a", "A.03.04.08.b", + "A.03.13.13.a[01]", + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", "A.03.13.13.b[03]" ], + "general-nist-800-172-r3": [ + "03.13.06E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.06E.ODP[01]" + ], "general-sparta": [ "CM0047", "CM0069" @@ -67866,12 +69674,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (05)" ], - "emea-deu-c5-2020": [ - "AM-02" - ], - "emea-isr-cmo-1-0": [ - "6.7" - ], "emea-sau-cscc-1-2019": [ "2-3-1-1" ], @@ -67882,7 +69684,9 @@ "2-3-1-6" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5-BP2", + "5-BP2-1", + "5-BP2-2" ], "emea-gbr-def-stan-05-138-2024": [ "2409" @@ -67901,7 +69705,7 @@ "ML2-P5", "ML3-P5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-1235", @@ -67920,15 +69724,12 @@ "14.2.7.C.04", "14.2.7.C.05", "14.2.7.C.06", - "14.2.7.C.07" + "14.2.7.C.07", + "21.3.12.C.02" ], "apac-sgp-mas-trm-2021": [ "11.3.6" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.08.B", @@ -67942,7 +69743,7 @@ "title": "Split Tunneling", "family": "CFG", "description": "Mechanisms exist to prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards.", - "scf_question": "Does the organization prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?\n\nPrevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?", + "scf_question": "Does the organization prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -67959,7 +69760,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -68008,7 +69809,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -68091,10 +69893,6 @@ "usa-federal-cms-marse-2-0": [ "SC-7(7)" ], - "emea-isr-cmo-1-0": [ - "4.15", - "9.13" - ], "emea-gbr-def-stan-05-138-2024": [ "2305" ], @@ -68107,7 +69905,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2305" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0705" ], "apac-nzl-ism-3-9": [ @@ -68138,7 +69936,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to enforce software usage restrictions to comply with applicable contract agreements and copyright laws.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -68209,7 +70007,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -68225,7 +70024,7 @@ "general-govramp-high": [ "CM-10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1546.008", "T1546.013", "T1550.001", @@ -68272,6 +70071,11 @@ "general-nist-800-171-r3": [ "03.13.13.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", + "A.03.13.13.b[03]" + ], "general-tisax-6-0-3": [ "1.3.4" ], @@ -68308,8 +70112,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-10" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "apac-sgp-mas-trm-2021": [ + "6.1.3" ], "americas-can-itsp-10-171-2025": [ "03.13.13.B" @@ -68336,9 +70140,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to establish parameters for the secure use of open source software.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to establish parameters for the secure use of open source software. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -68408,7 +70212,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -68447,12 +70252,19 @@ "general-nist-800-171-r3": [ "03.13.13.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], "usa-federal-cms-marse-2-0": [ "CM-10(1)", "CM-10(1).a", "CM-10(1).b", "CM-10(1).c" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-sgp-mas-trm-2021": [ "6.1.3" ], @@ -68483,7 +70295,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to allow only approved Internet browsers and email clients to run on systems.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -68551,7 +70363,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -68559,7 +70372,7 @@ "CC6.7" ], "general-cis-csc-8-1": [ - "9.0", + "9", "9.1", "9.4" ], @@ -68574,11 +70387,7 @@ "9.1", "9.4" ], - "emea-sau-ecc-1-2018": [ - "2-4-1", - "2-5-3-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0824", "ISM-1235", "ISM-1412", @@ -68590,10 +70399,6 @@ "ISM-1601", "ISM-1654", "ISM-1655" - ], - "amaericas-can-osfi-self-assessment": [ - "4.6", - "4.9" ] } }, @@ -68623,7 +70428,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to restrict the ability of non-privileged users to install unauthorized software.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -68694,7 +70499,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -68716,7 +70522,7 @@ "general-govramp-high": [ "CM-11" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.005", "T1059", "T1059.006", @@ -68800,6 +70606,10 @@ "3.4.9[b]", "3.4.9[c]" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], "general-nist-csf-2-0": [ "PR.PS-05" ], @@ -68849,21 +70659,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-11" ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0382", "ISM-1592", "ISM-1655" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.13.13.B" ] @@ -68889,9 +70689,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Secure baseline configurations generate logs that contain sufficient information to establish necessary details of activity and allow for forensics analysis.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to generate an alert when the unauthorized installation of software is detected.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to generate an alert when the unauthorized installation of software is detected. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -68940,7 +70740,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -68995,6 +70796,12 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.b" + ], "usa-federal-fbi-cjis-6-0": [ "CM-8(3)" ], @@ -69019,13 +70826,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.c" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } }, @@ -69047,11 +70847,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the installation of software, unless the action is performed by a privileged user or service.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -69119,7 +70919,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -69171,10 +70972,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(02)" ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0382", "ISM-1592" ], @@ -69189,10 +70987,6 @@ "12.6.2.2", "12.6.2.3", "12.6.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } }, @@ -69214,11 +71008,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically monitor, enforce and report on configurations for endpoint devices.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -69287,7 +71081,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -69319,8 +71114,10 @@ "03.04.02.b", "03.04.03.a" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-171a-r3": [ + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.03.a" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -69340,7 +71137,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-0955", @@ -69353,9 +71150,8 @@ "apac-ind-sebi-2024": [ "PR.DS.S6" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(b)" ], "americas-can-itsp-10-171-2025": [ "03.04.02.A", @@ -69382,7 +71178,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically identify unauthorized deviations from an approved baseline and implement automated resiliency actions to remediate the unauthorized change.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -69453,7 +71249,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -69487,9 +71284,11 @@ "CM-03(08)", "CM-11(03)" ], - "general-nist-800-172": [ - "3.4.2e", - "3.14.7e" + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -69509,7 +71308,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-0955", @@ -69521,10 +71320,6 @@ ], "apac-ind-sebi-2024": [ "PR.DS.S6" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } }, @@ -69546,7 +71341,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to implement Zero-Touch Provisioning (ZTP), or similar technology, to automatically and securely configure devices upon being added to a network.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -69594,7 +71389,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -69610,8 +71406,8 @@ "control_id": "CFG-08", "title": "Sensitive / Regulated Data Access Enforcement", "family": "CFG", - "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data.", - "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data?", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive and/or regulated data.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive and/or regulated data?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -69626,7 +71422,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -69714,7 +71510,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -69738,7 +71535,8 @@ "03.01.02" ], "general-nist-800-171a-r3": [ - "A.03.01.02[01]" + "A.03.01.02[01]", + "A.03.01.02[02]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -69750,12 +71548,12 @@ "248.30(a)(2)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "AC-3(CE-11)" @@ -69769,8 +71567,8 @@ "control_id": "CFG-08.1", "title": "Sensitive / Regulated Data Actions", "family": "CFG", - "description": "Automated mechanisms exist to generate event logs whenever sensitive/regulated data is collected, created, updated, deleted and/or archived.", - "scf_question": "Does the organization use automated mechanisms to generate event logs whenever sensitive/regulated data is collected, created, updated, deleted and/or archived?", + "description": "Automated mechanisms exist to generate event logs whenever sensitive and/or regulated data is collected, created, updated, deleted and/or archived.", + "scf_question": "Does the organization use automated mechanisms to generate event logs whenever sensitive and/or regulated data is collected, created, updated, deleted and/or archived?", "relative_weight": 7, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -69866,7 +71664,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -69876,14 +71675,320 @@ "general-nist-800-66-r2": [ "164.312(c)" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" + ] + } + }, + { + "control_id": "CFG-09", + "title": "Production Software Repository", + "family": "CFG", + "description": "Mechanisms exist to maintain an authoritative repository for production software.", + "scf_question": "Does the organization maintain an authoritative repository for production software?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to maintain an authoritative repository for production software.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Version control system with protected production branch (e.g., GitHub, GitLab).\n∙ Designated production branch with access controls", + "small": "∙ Version control with protected production branches.\n∙ Access restrictions on production branch", + "medium": "∙ Artifact repository manager (e.g., JFrog Artifactory, Nexus)\n∙ Version-controlled production software with access restrictions", + "large": "∙ Enterprise artifact repository (e.g., JFrog Artifactory, Nexus)\n∙ Access controls on production repository\n∙ Immutable artifact storage", + "enterprise": "∙ Enterprise artifact repository (e.g., JFrog Artifactory)\n∙ Software Bill of Materials (SBOM) generation\n∙ Immutable artifact storage with digital signing\n∙ Integration with CI/CD pipeline" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2023", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2023" + ] + } + }, + { + "control_id": "CFG-09.1", + "title": "Third-Party Libraries", + "family": "CFG", + "description": "Mechanisms exist to restrict the use and import of third-party libraries and/or software components to trustworthy sources.", + "scf_question": "Does the organization restrict the use and import of third-party libraries and/or software components to trustworthy sources?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to restrict the use and import of third-party libraries and/or software components to trustworthy sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Manual review of third-party libraries before use\n∙ OWASP Dependency-Check\n∙ Approved library list", + "small": "∙ OWASP Dependency-Check for vulnerability scanning\n∙ Approved third-party library register", + "medium": "∙ Software Composition Analysis (SCA) tool\n∙ Approved vendor/library register\n∙ Dependency vulnerability scanning in CI/CD", + "large": "∙ Enterprise SCA tool (e.g., Snyk, Mend, Black Duck)\n∙ Approved library registry\n∙ Automated dependency scanning in CI/CD pipeline", + "enterprise": "∙ Enterprise SCA platform (e.g., Snyk, Black Duck\n∙ Automated library approval workflows\n∙ SBOM generation for all dependencies\n∙ Real-time vulnerability alerting for in-use libraries" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2029", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2029" + ] + } + }, + { + "control_id": "CFG-09.2", + "title": "Software Repository Protections", + "family": "CFG", + "description": "Mechanisms exist to protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys.", + "scf_question": "Does the organization protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Checksum verification of downloaded packages\n∙ Use of reputable package registries only", + "small": "∙ Package signature verification\n∙ Private package mirror or proxy", + "medium": "∙ Artifact repository with malware scanning\n∙ Package signature and hash verification\n∙ Private package registry to proxy public registries", + "large": "∙ Enterprise artifact repository with integrated security scanning\n∙ Signed artifact enforcement\n∙ Private package proxy with allowlist", + "enterprise": "∙ Enterprise artifact repository with automated malware scanning and secret detection\n∙ Code signing enforcement\n∙ Supply chain security tools.\n∙ Private package proxy with security scanning" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2026 & ISM-2027", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2026", + "ISM-2027", + "ISM-2030" + ] + } + }, + { + "control_id": "CFG-09.3", + "title": "Software Development Repository", + "family": "CFG", + "description": "Mechanisms exist to maintain an authoritative repository for software development activities that is separate from production software.", + "scf_question": "Does the organization maintain an authoritative repository for software development activities that is separate from production software?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to maintain an authoritative repository for software development activities that is separate from production software.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Separate development branch in version control\n∙ GitHub or GitLab for development repository.", + "small": "∙ Separate development environment and repository\n∙ Branch-based development workflow separate from production", + "medium": "∙ Separate development, staging and production repositories\n∙ Access controls separating development from production code", + "large": "∙ Enterprise repository management with environment separation\n∙ Strict access controls between dev and production repositories\n∙ Code review requirements before production promotion", + "enterprise": "∙ Enterprise DevSecOps platform with environment-separated repositories\n∙ Automated promotion gates between environments\n∙ Immutable production code repository\n∙ Integration with ITSM change management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2024", + "family_name": "Configuration Management", + "crosswalks": { + "emea-sau-ecc-1-2018": [ + "1-6-3-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2024" ] } }, @@ -69988,7 +72093,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -70000,9 +72106,9 @@ "CC7.2-POF1" ], "general-cis-csc-8-1": [ - "8.0", + "8", "8.2", - "13.0", + "13", "13.6" ], "general-cis-csc-8-1-ig1": [ @@ -70071,7 +72177,7 @@ "8.15", "8.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -70544,16 +72650,16 @@ "general-nist-800-171-r3": [ "03.03.01.a", "03.12.03", - "03.14.06.a" + "03.14.06.a", + "03.14.06.a.02" ], "general-nist-800-171a-r3": [ + "A.03.03.01.a", + "A.03.12.03[01]", "A.03.14.06.a.01[01]", "A.03.14.06.a.01[02]", "A.03.14.06.a.02" ], - "general-nist-800-172": [ - "3.14.2e" - ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 6", @@ -70598,9 +72704,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-sparta": [ "CM0090" ], @@ -70692,18 +72795,22 @@ "AU-01", "SI-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)", + "101.650(f)(3)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(3)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-1", @@ -70757,9 +72864,8 @@ "SI-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" + "3.4.5.39", + "3.5.52" ], "emea-eu-dora-2023": [ "Article 10.3" @@ -70771,72 +72877,46 @@ "3.2.6", "13.1.2(f)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "5.5", - "6.3", - "6.7" - ], "emea-deu-c5-2020": [ - "OPS-10" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" + "RB-10" ], "emea-sau-cscc-1-2019": [ - "2-11" + "2-11-1" ], "emea-sau-cgiot-2024": [ "2-11-1" ], "emea-sau-ecc-1-2018": [ - "2-3-4", "2-12-1", "2-12-2", - "2-12-3", - "2-12-4", "5-1-3-3" ], "emea-sau-otcc-1-2022": [ - "2-11", "2-11-1", + "2-11-1-10", "2-11-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-40", - "TPC-80" - ], "emea-sau-sama-csf-1-2017": [ - "3.3.14" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1", - "Article 21.2", - "Article 24.1" + "3.3.14", + "3.3.14.1", + "3.3.14.3", + "3.3.14.4", + "3.3.14.4.a", + "3.3.14.4.b", + "3.3.14.4.c", + "3.3.14.4.d", + "3.3.14.4.e", + "3.3.14.4.f", + "3.3.14.4.g" ], "emea-esp-decree-311-2022": [ - "10.1", - "21.2", - "24.1" + "Article 8(3)", + "Article 12(6)(l)", + "Article 24(1)", + "Article 24(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1" @@ -70871,7 +72951,7 @@ "3102", "3106" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-0120", "ISM-0580", @@ -70880,6 +72960,12 @@ "ISM-1294", "ISM-1586" ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], + "apac-chn-data-security-law-2021": [ + "Article 29" + ], "apac-ind-sebi-2024": [ "DE.CM.S2", "PR.AA.S8" @@ -70889,12 +72975,14 @@ "12.4.1", "12.4.1.15.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HHSP70", - "HML70" + "apac-mys-bnm-rmit-2025": [ + "10.57", + "11.9", + "12.3" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS18" + "HHSP70", + "HML70" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP61" @@ -70907,25 +72995,25 @@ "16.6.10.C.02" ], "apac-sgp-mas-trm-2021": [ - "12.2.1", - "12.2.2", - "12.2.3" + "6.4.7", + "12.2.1" ], "americas-bmu-mba-coc-2020": [ "6.21" ], - "amaericas-can-osfi-self-assessment": [ - "3.5" - ], "americas-can-osfi-b13-2022": [ "3.3", "3.3.1", "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" + ], "americas-can-itsp-10-171-2025": [ "03.03.01.A", "03.12.03", - "03.14.06.A" + "03.14.06.A", + "03.14.06.A.02" ] } }, @@ -70951,7 +73039,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement Intrusion Detection / Prevention Systems (IDS / IPS) technologies on critical systems, key network segments and network choke points.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71021,7 +73109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -71075,8 +73164,8 @@ "general-nist-800-171-r3": [ "03.13.01.a" ], - "general-nist-800-172": [ - "3.14.6e" + "general-nist-800-171a-r3": [ + "A.03.13.01.a[01]" ], "general-nist-csf-2-0": [ "DE.CM-01" @@ -71155,18 +73244,6 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(8)(A)" ], - "emea-isr-cmo-1-0": [ - "7.4", - "11.11", - "12.18", - "23.6" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-6" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", "16.6.10.C.02", @@ -71185,11 +73262,6 @@ "18.4.12.C.01", "18.4.14.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "3.3", - "4.3", - "4.4" - ], "americas-can-osfi-b13-2022": [ "3.3.2" ], @@ -71219,9 +73291,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support near real-time analysis and incident escalation.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support near real-time analysis and incident escalation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -71288,7 +73360,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -71427,19 +73500,12 @@ "500.14(b)(2)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)" + "3.4.5.38", + "3.4.5.39" ], "emea-eu-nis2-annex-2024": [ "3.2.2" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "11.11", - "12.31" - ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" @@ -71449,10 +73515,15 @@ ], "emea-sau-ecc-1-2018": [ "2-12-3-3", + "2-12-3-4", "5-1-3-3" ], + "emea-sau-otcc-1-2022": [ + "2-11-1-3" + ], "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "3.3.14.4.j", + "3.3.14.4.k" ], "emea-gbr-def-stan-05-138-2024": [ "3102" @@ -71460,14 +73531,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3102" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS19" + "apac-nzl-ism-3-9": [ + "16.6.15.C.01", + "16.6.15.C.02" ], - "amaericas-can-osfi-self-assessment": [ - "3.4" + "apac-sgp-mas-trm-2021": [ + "6.4.7", + "7.7.4", + "12.2.2" ], "americas-can-osfi-b13-2022": [ "3.3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" ] } }, @@ -71563,7 +73640,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -71636,8 +73714,8 @@ "general-nist-800-171a-r3": [ "A.03.13.01.a[01]", "A.03.13.01.a[03]", - "A.03.14.06.c[01]", - "A.03.14.06.c[02]" + "A.03.14.06.b", + "A.03.14.06.c[01]" ], "general-nist-csf-2-0": [ "DE.CM-01" @@ -71673,6 +73751,10 @@ "usa-federal-gsa-fedramp-5-high": [ "SI-04(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(3)", + "101.650(h)(2)" + ], "usa-federal-irs-1075-2021": [ "SI-4(CE-4)", "SI-4(CE-4).a", @@ -71694,15 +73776,13 @@ "emea-eu-nis2-annex-2024": [ "3.2.3(a)" ], - "emea-isr-cmo-1-0": [ - "9.9", - "9.10", - "10.9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-40" + "apac-aus-ism-2026-march": [ + "ISM-1906", + "ISM-1907", + "ISM-2015" ], "apac-nzl-ism-3-9": [ + "15.2.40.C.02", "16.6.10.C.01", "16.6.10.C.02", "18.4.8.C.01", @@ -71738,9 +73818,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to generate, monitor, correlate and respond to alerts from physical, cybersecurity, data protection and supply chain activities to achieve integrated situational awareness.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to generate, monitor, correlate and respond to alerts from physical, cybersecurity, data protection and supply chain activities to achieve integrated situational awareness. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -71810,7 +73890,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -71906,8 +73987,17 @@ "03.14.06.c" ], "general-nist-800-171a-r3": [ - "A.03.03.02.a.01", - "A.03.03.03.a" + "A.03.03.01.a", + "A.03.03.03.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" + ], + "general-nist-800-172-r3": [ + "03.14.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.17E" ], "general-nist-800-207": [ "NIST Tenet 7" @@ -71994,11 +74084,15 @@ "usa-federal-gsa-fedramp-5-high": [ "SI-04(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)", + "101.650(h)(2)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "SI-4(CE-5)" @@ -72023,25 +74117,18 @@ "emea-eu-ai-act-2024": [ "Article 12.1" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "21.2", - "21.4" - ], "emea-sau-cscc-1-2019": [ "2-11-1-1" ], "emea-sau-ecc-1-2018": [ - "2-12-3-1" + "2-12-3-1", + "2-12-3-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-80", - "TPC-87" + "emea-sau-otcc-1-2022": [ + "2-11-1-1" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.a", @@ -72056,15 +74143,29 @@ "emea-gbr-def-stan-05-138-l2-2024": [ "3101" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-aus-ism-2026-march": [ + "ISM-1959" + ], + "apac-aus-cop-sitc-2020": [ + "7" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP69", "HML68" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP60" ], - "amaericas-can-osfi-self-assessment": [ - "3.6" + "americas-arg-ppd-2018": [ + "B.2.3-3", + "B.2.3-4", + "B.2.5-DS-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP6" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" ], "americas-can-itsp-10-171-2025": [ "03.03.01.A", @@ -72176,9 +74277,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Continuous Monitoring", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -72215,6 +74316,14 @@ "general-nist-800-82-r3-high": [ "SI-04(14)" ], + "general-nist-800-172-r3": [ + "03.14.19E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.19E[01]", + "DS-A.03.14.19E[02]", + "DS-A.03.14.19E[03]" + ], "general-pci-dss-4-0-1": [ "11.2" ], @@ -72227,9 +74336,6 @@ "usa-federal-cms-marse-2-0": [ "SI-4(14)" ], - "emea-isr-cmo-1-0": [ - "7.6" - ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", "16.6.10.C.02", @@ -72321,7 +74427,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -72376,7 +74483,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a File Integrity Monitor (FIM), or similar change-detection technology, on critical Technology Assets, Applications and/or Services (TAAS) to generate alerts for unauthorized modifications.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a File Integrity Monitor (FIM), or similar change-detection technology, on critical Technology Assets, Applications and/or Services (TAAS) to generate alerts for unauthorized modifications. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72444,7 +74551,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -72492,6 +74600,13 @@ "general-nist-800-160-vol-2-r1": [ "SI-04(24)" ], + "general-nist-800-172-r3": [ + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.01E.a[03]", + "A.03.14.01E.ODP[03]" + ], "general-nist-csf-2-0": [ "DE.CM-09" ], @@ -72553,23 +74668,16 @@ "SI-04(24)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "SI-4(CE-24)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(e)" - ], - "emea-isr-cmo-1-0": [ - "6.4", - "12.19" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "3.4.4.36(e)" ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", @@ -72671,7 +74779,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -72788,7 +74897,6 @@ "3.14.3" ], "general-nist-800-171-r3": [ - "03.03.01.b", "03.03.05.a" ], "general-nist-800-171a": [ @@ -72801,10 +74909,24 @@ ], "general-nist-800-171a-r3": [ "A.03.03.01.ODP[02]", - "A.03.03.01.b[01]", "A.03.03.05.ODP[01]", "A.03.03.05.a" ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.11.09E", + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.b", + "DS-A.03.11.09E[03]", + "DS-A.03.14.01E.b[01]", + "A.03.14.01E.ODP[04]", + "DS-A.03.14.01E.b[02]", + "A.03.14.01E.ODP[05]", + "DS-A.03.14.01E.b[03]", + "A.03.14.01E.ODP[06]" + ], "general-nist-csf-2-0": [ "DE.CM-01", "DE.AE", @@ -72883,13 +75005,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-2" @@ -72944,21 +75069,12 @@ "2447(b)(2)(C)", "2447(c)(4)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)" - ], "emea-eu-nis2-annex-2024": [ "3.2.3", "3.2.4" ], "emea-deu-bsrit-2017": [ - "5.5" - ], - "emea-isr-cmo-1-0": [ - "12.31", - "21.3", - "21.11" + "6.7" ], "emea-sau-cscc-1-2019": [ "2-11-1-2" @@ -72966,19 +75082,12 @@ "emea-sau-cgiot-2024": [ "2-11-1" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-40" + "emea-sau-otcc-1-2022": [ + "2-11-1-4" ], "emea-gbr-caf-4-0": [ "C1.a" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "emea-gbr-def-stan-05-138-2024": [ "3101", "3102" @@ -72992,7 +75101,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109" ], "apac-ind-sebi-2024": [ @@ -73008,16 +75117,21 @@ "12.4.5.5.P" ], "apac-sgp-mas-trm-2021": [ - "12.2.2" + "12.2.6" ], - "amaericas-can-osfi-self-assessment": [ - "3.5" + "americas-arg-ppd-2018": [ + "B.2.5-DS-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP5" ], "americas-can-osfi-b13-2022": [ "3.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.3" + ], "americas-can-itsp-10-171-2025": [ - "03.03.01.B", "03.03.05.A" ] } @@ -73042,7 +75156,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.\n▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to log all Internet-bound requests, in order to identify prohibited activities and assist incident handlers with identifying potentially compromised systems.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to log all Internet-bound requests, in order to identify prohibited activities and assist incident handlers with identifying potentially compromised systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -73108,15 +75222,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { - "emea-isr-cmo-1-0": [ - "9.14", - "21.20" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0261" ], "apac-nzl-ism-3-9": [ @@ -73144,7 +75255,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor deactivated accounts for attempted usage.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73214,7 +75325,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -73231,7 +75343,7 @@ "title": "Automated Response to Suspicious Events", "family": "MON", "description": "Automated mechanisms exist to implement pre-determined corrective actions in response to detected events that have security incident implications.", - "scf_question": "Does the organization automatically implement pre-determined corrective actions in response to detected events that have security incident implications?", + "scf_question": "Does the organization use automated mechanisms to implement pre-determined corrective actions in response to detected events that have security incident implications?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -73244,11 +75356,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically implement pre-determined corrective actions in response to detected events that have security incident implications.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -73308,7 +75420,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -73372,7 +75485,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically alert incident response personnel to inappropriate or anomalous activities that have potential security incident implications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73441,7 +75554,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -73476,6 +75590,15 @@ "general-nist-800-171a-r3": [ "A.03.03.05.b" ], + "general-nist-800-172-r3": [ + "03.14.17E", + "03.14.18E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.17E", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.AE", "DE.AE-06" @@ -73501,10 +75624,7 @@ "usa-federal-irs-1075-2021": [ "SI-4(CE-12)" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-1" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP69", "HML68" ], @@ -73535,11 +75655,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to \"tune\" event monitoring technologies through analyzing communications traffic/event patterns and developing profiles representing common traffic patterns and/or events.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -73604,7 +75724,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -73659,11 +75780,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for individuals who have been identified as posing an increased level of risk.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for individuals who have been identified as posing an increased level of risk. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -73728,7 +75849,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -73758,12 +75880,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SI-04(19)" - ], - "emea-deu-bsrit-2017": [ - "6.7" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" ] } }, @@ -73787,11 +75903,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for privileged users.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -73861,7 +75977,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -73903,26 +76020,23 @@ "general-nist-800-171-r3": [ "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b" + ], "usa-federal-gsa-fedramp-5-high": [ "SI-04(20)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(c)" ], - "emea-deu-bsrit-2017": [ - "6.7" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" - ], "emea-sau-sacs-002-2022": [ - "TPC-83" + "VII.B.TPC-83" ], "emea-gbr-def-stan-05-138-2024": [ "2203" @@ -73933,6 +76047,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2203" ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" + ], + "americas-arg-ppd-2018": [ + "B.2.1-3" + ], "americas-can-itsp-10-171-2025": [ "03.01.07.B" ] @@ -73943,7 +76063,7 @@ "title": "Analyze and Prioritize Monitoring Requirements", "family": "MON", "description": "Mechanisms exist to assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes.", - "scf_question": "Does the organization assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes?", + "scf_question": "Does the organization assess its needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -73958,7 +76078,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74036,9 +76156,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed\n- NIST 800-171A", "family_name": "Continuous Monitoring", "crosswalks": { "general-csa-iot-2": [ @@ -74075,83 +76195,23 @@ "11.10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.3.a", "III.D.3.b" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "5.5", - "6.3", "6.7" ], - "emea-deu-c5-2020": [ - "OPS-10" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" - ], - "emea-sau-cscc-1-2019": [ - "2-11" - ], - "emea-sau-ecc-1-2018": [ - "2-3-4", - "2-12-1", - "2-12-2", - "2-12-3", - "2-12-4", - "5-1-3-3" - ], "emea-sau-otcc-1-2022": [ - "2-11", - "2-11-1", - "2-11-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-40", - "TPC-80" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-decree-311-2022": [ - "10.1", - "21.2", - "24.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" - ], - "emea-gbr-cap-1850-2020": [ - "C1" + "2-11-1-9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-0120", "ISM-0580", @@ -74166,17 +76226,6 @@ "16.6.8.C.01", "16.6.10.C.01", "16.6.10.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "12.2.1", - "12.2.2", - "12.2.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], - "amaericas-can-osfi-self-assessment": [ - "3.5" ] } }, @@ -74198,7 +76247,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to enable authorized personnel the ability to remotely view and hear content related to an established user session in real time, in accordance with organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74264,7 +76313,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -74281,7 +76331,7 @@ "title": "Centralized Collection of Security Event Logs", "family": "MON", "description": "Mechanisms exist to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs.", - "scf_question": "Does the organization utilize a Security Incident Event Manager (SIEM) or similar automated tool, to support the centralized collection of security-related event logs?", + "scf_question": "Does the organization utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -74297,7 +76347,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -74382,7 +76432,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -74614,10 +76665,6 @@ "10.4.1", "10.4.1.1" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.13" - ], "general-swift-cscf-2025": [ "6.1", "6.2", @@ -74723,48 +76770,50 @@ "SI-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" + "3.4.5.38", + "3.4.5.39", + "3.5.52" ], "emea-eu-nis2-annex-2024": [ "3.2.6" ], "emea-deu-c5-2020": [ - "OPS-14" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.3", - "21.4", - "21.6", - "21.12" + "RB-10", + "RB-13", + "RB-16-DOAR", + "SIM-05" ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" ], "emea-sau-otcc-1-2022": [ - "2-11-1-3", - "2-11-1-9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-81" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "2-11-1-5", + "2-11-1-6", + "2-11-1-7", + "2-11-1-8" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-1228", "ISM-1405", "ISM-1536", "ISM-1537", "ISM-1566", - "ISM-1650" + "ISM-1650", + "ISM-1911", + "ISM-1960", + "ISM-1963", + "ISM-1976", + "ISM-1977", + "ISM-1978", + "ISM-1979", + "ISM-1983", + "ISM-1986", + "ISM-1987" ], "apac-nzl-ism-3-9": [ "16.6.11.C.01", @@ -74774,18 +76823,13 @@ "16.6.12.C.02", "16.6.12.C.03" ], - "apac-sgp-mas-trm-2021": [ - "9.1.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], - "amaericas-can-osfi-self-assessment": [ - "3.2" - ], "americas-can-osfi-b13-2022": [ "3.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1", + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.03.05.A", "03.03.05.C" @@ -74813,7 +76857,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of vulnerability scanning activities and associated administrator accounts are reviewed to ensure that those activities are limited to the timeframes of legitimate scans.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate both technical and non-technical information from across the enterprise by a Security Incident Event Manager (SIEM) or similar automated tool, to enhance organization-wide situational awareness.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74898,7 +76942,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -75003,6 +77048,7 @@ "3.14.7[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.05.a", "A.03.03.05.c[02]" ], "general-nist-800-207": [ @@ -75034,9 +77080,6 @@ "10.4.1.1", "12.10.5" ], - "general-scf-dpmp-2025": [ - "7.13" - ], "general-tisax-6-0-3": [ "5.2.4" ], @@ -75091,37 +77134,30 @@ "usa-federal-cms-marse-2-0": [ "AU-6(3)" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.6", - "21.12", - "21.13", - "21.19" + "emea-eu-eba-ict-srm-2025": [ + "3.4.5.38(a)", + "3.4.5.38(b)", + "3.4.5.38(c)", + "3.4.5.39", + "3.4.5.40" ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" - ], "emea-sau-sacs-002-2022": [ - "TPC-81" + "VII.B.TPC-81" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], - "apac-aus-ism-2024-june": [ - "ISM-1228" + "apac-aus-ism-2026-march": [ + "ISM-1228", + "ISM-1961", + "ISM-1964" + ], + "apac-aus-cop-sitc-2020": [ + "10" ], "apac-nzl-ism-3-9": [ "16.6.14.C.01", @@ -75130,9 +77166,6 @@ "apac-sgp-mas-trm-2021": [ "12.2.5" ], - "amaericas-can-osfi-self-assessment": [ - "3.6" - ], "americas-can-osfi-b13-2022": [ "3.3.1" ], @@ -75164,11 +77197,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically centrally collect, review and analyze audit records from multiple sources.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -75248,7 +77281,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -75299,10 +77333,13 @@ "AU-06(04)" ], "general-nist-800-171-r3": [ - "03.03.01.b", "03.03.05.a", "03.03.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.03.05.a", + "A.03.03.05.c[01]" + ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 7" @@ -75360,30 +77397,17 @@ "7123(c)(7)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" + "3.5.52" ], "emea-deu-c5-2020": [ - "OPS-13" + "RB-10", + "SIM-05" ], "emea-sau-cscc-1-2019": [ "2-11-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-4" - ], - "emea-sau-otcc-1-2022": [ - "2-11-1-9", - "2-11-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-81" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" - ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "apac-aus-essential-8-2024": [ "ML2-P3", @@ -75395,7 +77419,7 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1228" ], "apac-nzl-ism-3-9": [ @@ -75406,18 +77430,11 @@ "16.6.12.C.02", "16.6.12.C.03" ], - "apac-sgp-mas-trm-2021": [ - "12.2.6" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], "americas-can-osfi-b13-2022": [ "3.3.1", "3.3.2" ], "americas-can-itsp-10-171-2025": [ - "03.03.01.B", "03.03.05.A", "03.03.05.C" ] @@ -75441,11 +77458,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically integrate the analysis of audit records with analysis of vulnerability scanners, network performance, system monitoring and other sources to further enhance the ability to identify inappropriate or unusual activity.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -75525,7 +77542,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -75587,6 +77605,17 @@ "general-nist-800-171-r3": [ "03.03.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.03.05.c[02]" + ], + "general-nist-800-172-r3": [ + "03.03.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.04E", + "A.03.03.04E.ODP[01]", + "A.03.03.04E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 4", "NIST Tenet 5", @@ -75611,18 +77640,6 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-06(05)" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" - ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "americas-can-itsp-10-171-2025": [ "03.03.05.C" ] @@ -75646,11 +77663,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual or malevolent activity.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual or malevolent activity. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -75728,7 +77745,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -75788,9 +77806,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to specify the permitted actions for both users and Technology Assets, Applications and/or Services (TAAS) associated with the review, analysis and reporting of audit information.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to specify the permitted actions for both users and Technology Assets, Applications and/or Services (TAAS) associated with the review, analysis and reporting of audit information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75853,7 +77871,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -75877,9 +77896,6 @@ ], "usa-federal-irs-1075-2021": [ "AU-6(CE-7)" - ], - "emea-sau-cscc-1-2019": [ - "2-3-1-8" ] } }, @@ -75901,9 +77917,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to adjust the level of audit review, analysis and reporting based on evolving threat information from law enforcement, industry associations or other credible sources of threat intelligence.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to adjust the level of audit review, analysis and reporting based on evolving threat information from law enforcement, industry associations or other credible sources of threat intelligence. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75970,7 +77986,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -76028,6 +78045,12 @@ "general-nist-800-161-r1-level-3": [ "AU-6" ], + "general-nist-800-171-r3": [ + "03.03.01.b" + ], + "general-nist-800-171a-r3": [ + "A.03.03.01.b[01]" + ], "usa-federal-fbi-cjis-6-0": [ "AU-6" ], @@ -76059,12 +78082,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-06" ], - "emea-deu-c5-2020": [ - "OIS-05" + "emea-sau-otcc-1-2022": [ + "2-11-1-9" ], "apac-jpn-ismap": [ "6.1.3.5", "6.1.4.7" + ], + "americas-can-itsp-10-171-2025": [ + "03.03.01.B" ] } }, @@ -76086,11 +78112,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically compile audit records into an organization-wide audit trail that is time-correlated.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -76174,7 +78200,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -76217,6 +78244,9 @@ "general-nist-800-171-r3": [ "03.03.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.01.a" + ], "general-pci-dss-4-0-1": [ "10.6", "10.6.1", @@ -76271,12 +78301,10 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "AU-02-SID" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-1", - "2-11-1-2", - "2-11-1-3" + "emea-deu-c5-2020": [ + "RB-14" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0988" ], "apac-nzl-ism-3-9": [ @@ -76308,9 +78336,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide privileged users or roles the capability to change the auditing to be performed on specified system components, based on specific event criteria within specified time thresholds.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide privileged users or roles the capability to change the auditing to be performed on specified system components, based on specific event criteria within specified time thresholds. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76377,7 +78405,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -76404,6 +78433,9 @@ ], "usa-federal-gsa-fedramp-5-high": [ "AU-12(03)" + ], + "emea-deu-c5-2020": [ + "RB-15" ] } }, @@ -76511,7 +78543,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -76544,7 +78577,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.\n▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum:\n(1) Establish what type of event occurred;\n(2) When (date and time) the event occurred;\n(3) Where the event occurred;\n(4) The source of the event;\n(5) The outcome (success or failure) of the event; and \n(6) The identity of any user/subject associated with the event.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum:\n(1) Establish what type of event occurred;\n(2) When (date and time) the event occurred;\n(3) Where the event occurred;\n(4) The source of the event;\n(5) The outcome (success or failure) of the event; and \n(6) The identity of any user/subject associated with the event. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76618,7 +78651,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -76756,7 +78790,7 @@ "general-nist-800-171a-r3": [ "A.03.03.01.ODP[01]", "A.03.03.01.a", - "A.03.03.01.b[02]", + "A.03.03.02.a.01", "A.03.03.02.a.02", "A.03.03.02.a.03", "A.03.03.02.a.04", @@ -76862,10 +78896,10 @@ "AU-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-3" @@ -76908,9 +78942,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-03" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" - ], "emea-eu-nis2-annex-2024": [ "3.2.3", "3.2.3(c)", @@ -76928,27 +78959,28 @@ "6.3" ], "emea-deu-c5-2020": [ - "OPS-15" + "RB-10" ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.2", - "21.5", - "21.7", - "21.10" + "emea-isr-cmo-2-0": [ + "Appendix A, 12.2" ], "emea-sau-cscc-1-2019": [ "2-11-1-5" ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.1" + "emea-sau-otcc-1-2022": [ + "2-11-1-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-87" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.14.3.a" ], "emea-esp-decree-311-2022": [ - "24.1" + "Article 20(b)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.a" @@ -76968,11 +79000,16 @@ "ML3-P3", "ML3-P5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0582", "ISM-0585", "ISM-1536", - "ISM-1537" + "ISM-1537", + "ISM-1895", + "ISM-2051" + ], + "apac-aus-cop-sitc-2020": [ + "7" ], "apac-ind-sebi-2024": [ "PR.AA.S9" @@ -76995,7 +79032,7 @@ "12.4.1.17", "12.4.1.18" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP70", "HML70" ], @@ -77009,7 +79046,7 @@ "16.6.10.C.02" ], "americas-bmu-mba-coc-2020": [ - "6.21" + "6.21-BP6" ], "americas-can-osfi-b13-2022": [ "3.2.7", @@ -77032,8 +79069,8 @@ "control_id": "MON-03.1", "title": "Sensitive Event Log Information", "family": "MON", - "description": "Mechanisms exist to protect sensitive/regulated data contained in log files.", - "scf_question": "Does the organization protect sensitive/regulated data contained in log files?", + "description": "Mechanisms exist to protect sensitive and/or regulated data contained in log files.", + "scf_question": "Does the organization protect sensitive and/or regulated data contained in log files?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -77048,7 +79085,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect sensitive/regulated data contained in log files.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect sensitive/regulated data contained in log files. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77094,9 +79131,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Continuous Monitoring", "crosswalks": { "general-cis-csc-8-1": [ @@ -77173,8 +79210,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-03 (01)" ], - "emea-isr-cmo-1-0": [ - "21.4" + "apac-aus-ism-2026-march": [ + "ISM-2052" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP2" ] } }, @@ -77271,7 +79311,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -77288,6 +79329,9 @@ "3.3.1[c]", "3.3.2[a]" ], + "general-nist-800-171a-r3": [ + "A.03.03.01.a" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -77358,10 +79402,10 @@ "11.10(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.3.b" @@ -77372,8 +79416,9 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(b)" ], - "emea-isr-cmo-1-0": [ - "12.17" + "emea-deu-c5-2020": [ + "RB-14", + "RB-16" ], "emea-sau-cscc-1-2019": [ "2-11-1-3" @@ -77390,10 +79435,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3107" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0407" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP70", "HML70" ], @@ -77406,9 +79451,6 @@ "16.6.10.C.01", "16.6.10.C.02" ], - "apac-sgp-mas-trm-2021": [ - "9.2.2" - ], "americas-can-itsp-10-171-2025": [ "03.03.01.A" ] @@ -77505,7 +79547,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -77601,15 +79644,8 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(d)" ], - "emea-deu-c5-2020": [ - "OPS-16" - ], - "emea-isr-cmo-1-0": [ - "21.10", - "21.21" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-def-stan-05-138-2024": [ "2216" @@ -77625,13 +79661,18 @@ "ML3-P4", "ML3-P7" ], - "apac-aus-ism-2024-june": [ - "ISM-1537" + "apac-aus-ism-2026-march": [ + "ISM-1537", + "ISM-1889" ], "apac-jpn-ismap": [ "12.4.3", "12.4.3.1" ], + "apac-nzl-ism-3-9": [ + "16.4.41.C.01", + "16.4.41.C.02" + ], "americas-can-itsp-10-171-2025": [ "03.01.07.B" ] @@ -77691,16 +79732,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-owasp-top-10-2025": [ "A09:2025" - ], - "emea-isr-cmo-1-0": [ - "21.5", - "21.21" ] } }, @@ -77722,7 +79760,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to limit Personal Data (PD) contained in audit records to the elements identified in the Data Privacy Risk Assessment (DPRA).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77768,7 +79806,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -77810,9 +79849,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to centrally manage and update the criteria to be captured in event logs generated by organization-defined system components.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to centrally manage and update the criteria to be captured in event logs generated by organization-defined system components. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77865,9 +79904,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Continuous Monitoring", "crosswalks": { "general-nist-800-53-r4": [ @@ -77891,6 +79930,13 @@ "general-nist-800-161-r1-level-2": [ "PL-9" ], + "general-nist-800-171-r3": [ + "03.03.01.b" + ], + "general-nist-800-171a-r3": [ + "A.03.03.01.b[01]", + "A.03.03.01.b[02]" + ], "usa-federal-fbi-cjis-6-0": [ "PL-9" ], @@ -77910,8 +79956,8 @@ "AU-2(3)", "AU-2(3)-IS.1" ], - "emea-sau-ecc-1-2018": [ - "2-12-4" + "americas-can-itsp-10-171-2025": [ + "03.03.01.B" ] } }, @@ -77933,7 +79979,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to ensure databases produce audit records that contain sufficient information to monitor database activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77998,7 +80044,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -78014,7 +80061,10 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "7.2.6" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "2-2-1-8" + ], + "apac-aus-ism-2026-march": [ "ISM-1537" ], "apac-nzl-ism-3-9": [ @@ -78045,7 +80095,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to allocate and proactively manage sufficient event log storage capacity to reduce the likelihood of such capacity being exceeded.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to allocate and proactively manage sufficient event log storage capacity to reduce the likelihood of such capacity being exceeded. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78100,24 +80150,25 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-cis-csc-8-1": [ "8.3", - "8.1" + "8.10" ], "general-cis-csc-8-1-ig1": [ "8.3" ], "general-cis-csc-8-1-ig2": [ "8.3", - "8.1" + "8.10" ], "general-cis-csc-8-1-ig3": [ "8.3", - "8.1" + "8.10" ], "general-govramp": [ "AU-04" @@ -78192,12 +80243,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-04" ], - "emea-isr-cmo-1-0": [ - "21.8" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-5" - ], "apac-nzl-ism-3-9": [ "16.6.13.C.01", "16.6.13.C.02", @@ -78226,7 +80271,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to alert appropriate personnel in the event of a log processing failure and take actions to remedy the disruption.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -78287,7 +80332,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -78347,6 +80393,14 @@ "A.03.03.04.a", "A.03.03.04.b" ], + "general-nist-800-172-r3": [ + "03.03.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.02E", + "A.03.03.02E.ODP[03]", + "A.03.03.02E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -78392,15 +80446,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-05" ], - "emea-deu-c5-2020": [ - "OPS-17" - ], - "emea-isr-cmo-1-0": [ - "21.9" - ], - "emea-sau-otcc-1-2022": [ - "2-11-1-2" - ], "americas-can-itsp-10-171-2025": [ "03.03.04.B" ] @@ -78424,9 +80469,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide 24x7x365 near real-time alerting capability when an event log processing failure occurs.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide 24x7x365 near real-time alerting capability when an event log processing failure occurs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78481,7 +80526,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -78516,6 +80562,12 @@ "general-nist-800-82-r3-high": [ "AU-05(02)" ], + "general-nist-800-172-r3": [ + "03.03.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.03.02E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-low": [ "SI-04(12)" ], @@ -78533,10 +80585,7 @@ "SI-4(CE-12)" ], "emea-deu-c5-2020": [ - "OPS-17" - ], - "emea-isr-cmo-1-0": [ - "21.9" + "RB-16-DOAR" ] } }, @@ -78558,7 +80607,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically alert appropriate personnel when the allocated volume reaches an organization-defined percentage of maximum event log storage capacity.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -78615,7 +80664,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -78675,9 +80725,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide an event log report generation capability to aid in detecting and assessing anomalous activities.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide an event log report generation capability to aid in detecting and assessing anomalous activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78749,7 +80799,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -78920,11 +80971,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-12" ], - "emea-isr-cmo-1-0": [ - "21.3", - "21.11", - "21.19", - "21.20" + "emea-deu-c5-2020": [ + "RB-16" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-def-stan-05-138-2024": [ "3108" @@ -78938,12 +80989,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3108" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1660" ], - "apac-sgp-mas-trm-2021": [ - "12.2.6" - ], "americas-can-itsp-10-171-2025": [ "03.03.05.B", "03.03.06.A" @@ -78968,7 +81016,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide and implement the capability for auditing the parameters of user query events for data sets containing Personal Data (PD).", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -79010,7 +81058,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -79100,7 +81149,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -79158,7 +81208,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use an authoritative time source to generate time stamps for event logs.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use an authoritative time source to generate time stamps for event logs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -79210,7 +81260,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -79268,6 +81319,7 @@ "3.3.7[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.02.a.02", "A.03.03.07.ODP[01]", "A.03.03.07.a", "A.03.03.07.b[01]" @@ -79339,12 +81391,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-09" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-4" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.5 [MP.INFO.5]" - ], "americas-can-itsp-10-171-2025": [ "03.03.02.A.02", "03.03.07.A" @@ -79371,7 +81417,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to synchronize internal system clocks with an authoritative time source.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to synchronize internal system clocks with an authoritative time source. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -79423,7 +81469,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -79530,9 +81577,6 @@ "emea-eu-nis2-annex-2024": [ "3.2.6" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-4" - ], "emea-gbr-def-stan-05-138-2024": [ "2421" ], @@ -79545,7 +81589,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2421" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP71", "HML71" ], @@ -79575,7 +81619,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel retain security event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and/or contractual retention requirements.\n▪ IT and/or cybersecurity personnel restrict access to the management of event logs for privileged users to protect event logs and audit tools from unauthorized access, modification and deletion.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect event logs and audit tools from unauthorized access, modification and deletion.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79648,7 +81692,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -79730,7 +81775,8 @@ "general-nist-800-171-r3": [ "03.03.03.b", "03.03.06.b", - "03.03.08.a" + "03.03.08.a", + "03.03.08.b" ], "general-nist-800-171a": [ "3.3.8[a]", @@ -79802,6 +81848,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-09" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-9" ], @@ -79821,12 +81870,7 @@ "AU-09" ], "emea-deu-c5-2020": [ - "OPS-16" - ], - "emea-isr-cmo-1-0": [ - "21.4", - "21.14", - "21.16" + "RB-16" ], "emea-sau-cscc-1-2019": [ "2-3-1-8", @@ -79834,14 +81878,16 @@ "2-11-2" ], "emea-sau-ecc-1-2018": [ - "2-12-3-5", "2-14-3-3" ], "emea-sau-otcc-1-2022": [ "2-3-1-10" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.10 [OP.EXP.10]" + "emea-sau-sama-csf-1-2017": [ + "3.3.14.4.h" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.b" @@ -79865,9 +81911,8 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991" + "apac-aus-ism-2026-march": [ + "ISM-1815" ], "apac-ind-sebi-2024": [ "PR.AA.S9" @@ -79885,13 +81930,17 @@ "16.6.13.C.03", "16.6.13.C.04" ], + "apac-sgp-mas-trm-2021": [ + "12.2.2" + ], "americas-bmu-mba-coc-2020": [ - "6.21" + "6.21-BP3" ], "americas-can-itsp-10-171-2025": [ "03.03.03.B", "03.03.06.B", - "03.03.08.A" + "03.03.08.A", + "03.03.08.B" ] } }, @@ -79965,7 +82014,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -80013,6 +82063,15 @@ "general-nist-800-171-r3": [ "03.03.08.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]" + ], + "general-nist-800-172-r3": [ + "03.03.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.01E" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -80037,11 +82096,6 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-09(02)" ], - "emea-isr-cmo-1-0": [ - "21.14", - "21.15", - "21.17" - ], "emea-sau-cscc-1-2019": [ "2-11-1-5", "2-11-2" @@ -80075,7 +82129,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict access to the management of event logs for privileged users to protect event logs and audit tools from unauthorized access, modification and deletion.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to restrict access to the management of event logs to privileged users with a specific business need.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80134,7 +82188,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -80190,6 +82245,7 @@ "3.3.9[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]", "A.03.03.08.b" ], "general-owasp-top-10-2025": [ @@ -80231,17 +82287,20 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-09(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-9(CE-4)" ], "usa-federal-cms-marse-2-0": [ "AU-9(4)" ], - "emea-deu-c5-2020": [ - "OPS-16" + "apac-aus-ism-2026-march": [ + "ISM-1985" ], - "emea-isr-cmo-1-0": [ - "21.14" + "apac-nzl-ism-3-9": [ + "16.4.41.C.03" ], "americas-can-itsp-10-171-2025": [ "03.03.08.A", @@ -80267,9 +82326,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational cryptographic capability exists to protect the integrity of event logs and audit tools.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational cryptographic capability exists to protect the integrity of event logs and audit tools. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80325,7 +82384,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -80359,9 +82419,15 @@ "general-nist-800-171-r3": [ "03.03.08.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]" + ], "usa-federal-gsa-fedramp-5-high": [ "AU-09(03)" ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP2" + ], "americas-can-itsp-10-171-2025": [ "03.03.08.A" ] @@ -80455,7 +82521,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -80470,6 +82537,14 @@ ], "general-nist-800-160-vol-2-r1": [ "AU-09(05)" + ], + "general-nist-800-172-r3": [ + "03.03.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.03E", + "A.03.03.03E.ODP[01]", + "A.03.03.03E.ODP[02]" ] } }, @@ -80491,9 +82566,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a non-repudiation capability to protect against an individual falsely denying having performed a particular action.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a non-repudiation capability to protect against an individual falsely denying having performed a particular action. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80534,7 +82609,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -80578,25 +82654,6 @@ ], "usa-federal-cms-marse-2-0": [ "AU-10" - ], - "emea-us-psd2-2015": [ - "26" - ], - "emea-isr-cmo-1-0": [ - "21.14" - ], - "apac-sgp-mas-trm-2021": [ - "14.2.1", - "14.2.2", - "14.2.3", - "14.2.4", - "14.2.5", - "14.2.6", - "14.2.7", - "14.2.8", - "14.2.9", - "14.2.10", - "14.2.11" ] } }, @@ -80650,7 +82707,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -80700,7 +82758,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80760,7 +82818,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -80768,13 +82827,13 @@ "C1.2" ], "general-cis-csc-8-1": [ - "8.1" + "8.10" ], "general-cis-csc-8-1-ig2": [ - "8.1" + "8.10" ], "general-cis-csc-8-1-ig3": [ - "8.1" + "8.10" ], "general-csa-cmm-4-1-0": [ "LOG-04" @@ -80856,9 +82915,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "10.5.1" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-shared-assessments-sig-2025": [ "D.3" ], @@ -80886,6 +82942,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-11" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-11" ], @@ -80923,12 +82982,7 @@ "3.2.5" ], "emea-deu-c5-2020": [ - "OPS-14" - ], - "emea-isr-cmo-1-0": [ - "21.4", - "21.15", - "21.17" + "RB-13" ], "emea-sau-cscc-1-2019": [ "2-11-2" @@ -80941,7 +82995,7 @@ "2-14-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-75" + "VII.B.TPC-75" ], "emea-gbr-caf-4-0": [ "C1.b" @@ -80961,19 +83015,25 @@ "3103", "3107" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", - "ISM-1213" - ], - "apac-chn-pipl-2021": [ - "19" + "apac-aus-ism-2026-march": [ + "ISM-1213", + "ISM-1988", + "ISM-1989" ], "apac-ind-sebi-2024": [ "PR.AA.S9" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS18" + "apac-mys-bnm-rmit-2025": [ + "10.42" + ], + "apac-nzl-ism-3-9": [ + "16.6.13.C.05" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" ], "americas-can-itsp-10-171-2025": [ "03.03.03.B" @@ -80998,9 +83058,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of non-public information.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of non-public information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81070,7 +83130,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -81107,7 +83168,13 @@ "general-nist-800-171-r3": [ "03.01.22.b" ], - "apac-nzl-hisf-mlhsp-2023": [ + "general-nist-800-171a-r3": [ + "A.03.01.22.b[01]" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP63", "HML69" ], @@ -81137,11 +83204,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically analyze network traffic to detect covert data exfiltration.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -81178,7 +83245,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -81247,11 +83315,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically detect unauthorized network services and alert incident response personnel.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically detect unauthorized network services and alert incident response personnel. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -81306,7 +83374,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -81363,11 +83432,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically identify and alert on Indicators of Compromise (IoC).", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically identify and alert on Indicators of Compromise (IoC). ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -81451,7 +83520,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -81500,8 +83570,26 @@ "03.14.06.b", "03.14.06.c" ], - "general-nist-800-172": [ - "3.11.2e" + "general-nist-800-171a-r3": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", + "A.03.14.06.b" + ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.11.02E", + "03.11.09E", + "03.14.17E", + "03.14.18E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.a", + "DS-A.03.11.02E.a.01[01]", + "DS-A.03.11.09E[01]", + "DS-A.03.11.09E[02]", + "DS-A.03.14.17E", + "A.03.14.18E.ODP[03]" ], "general-nist-csf-2-0": [ "DE.CM" @@ -81545,15 +83633,18 @@ "7123(c)(8)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" ], "emea-deu-bsrit-2017": [ "5.4" ], - "apac-aus-ism-2024-june": [ + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-80" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], + "apac-aus-ism-2026-march": [ "ISM-0120", "ISM-1091" ], @@ -81563,6 +83654,9 @@ "americas-can-osfi-b13-2022": [ "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.14.06.A.01", "03.14.06.A.02", @@ -81660,7 +83754,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -81684,10 +83779,6 @@ ], "general-nist-800-161-r1-level-3": [ "AU-14" - ], - "emea-isr-cmo-1-0": [ - "21.10", - "21.18" ] } }, @@ -81759,7 +83850,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -81771,9 +83863,6 @@ ], "general-nist-800-82-r3": [ "AU-05(05)" - ], - "emea-isr-cmo-1-0": [ - "21.15" ] } }, @@ -81795,7 +83884,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to coordinate sanitized event logs among external organizations to identify anomalous events when event logs are shared across organizational boundaries, without giving away sensitive or critical business data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -81852,7 +83941,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -81904,7 +83994,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to share event logs with third-party organizations based on specific cross-organizational sharing agreements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -81961,7 +84051,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -82055,11 +84146,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -82086,9 +84178,6 @@ ], "general-pci-dss-4-0-1-saq-d-service-provider": [ "11.5.1.1" - ], - "emea-isr-cmo-1-0": [ - "21.10" ] } }, @@ -82205,7 +84294,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -82284,10 +84374,20 @@ "03.14.06.c" ], "general-nist-800-171a-r3": [ + "A.03.01.01.e", + "A.03.03.05.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", "A.03.14.06.b" ], - "general-nist-800-172": [ - "3.14.2e" + "general-nist-800-172-r3": [ + "03.01.08E", + "03.06.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.a", + "DS-A.03.06.03E" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -82359,12 +84459,12 @@ "IR-04(13)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "AC-2(CE-12)", @@ -82382,10 +84482,7 @@ "AC-02 (12)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" ], "emea-eu-dora-2023": [ "Article 10.1" @@ -82396,30 +84493,15 @@ "emea-deu-bsrit-2017": [ "5.5" ], - "emea-isr-cmo-1-0": [ - "4.7", - "21.10", - "21.20" - ], "emea-sau-otcc-1-2022": [ "2-3-1-12" ], "emea-sau-sacs-002-2022": [ - "TPC-80" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1" - ], - "emea-esp-decree-311-2022": [ - "10.1" + "VII.B.TPC-80" ], "emea-gbr-caf-4-0": [ "C1.f" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "emea-gbr-def-stan-05-138-2024": [ "3200", "3202", @@ -82439,20 +84521,28 @@ "3202", "3203" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1660" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS19" + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.57", + "11.9" ], "apac-sgp-mas-trm-2021": [ - "9.2.2", "11.5.5", + "12.2.3", "12.2.4" ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP4" + ], "americas-can-osfi-b13-2022": [ "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.E", "03.03.05.A", @@ -82574,7 +84664,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -82590,14 +84681,8 @@ "general-sparta": [ "CM0052" ], - "emea-isr-cmo-1-0": [ - "21.10" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625" - ], - "apac-sgp-mas-trm-2021": [ - "3.5.2" ] } }, @@ -82712,7 +84797,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -82724,9 +84810,6 @@ ], "general-shared-assessments-sig-2025": [ "J.5" - ], - "emea-isr-cmo-1-0": [ - "21.10" ] } }, @@ -82751,7 +84834,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for unauthorized activities, accounts, connections, devices and software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82841,7 +84924,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -82866,13 +84950,6 @@ "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.4" ], - "emea-isr-cmo-1-0": [ - "21.10" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11", - "2-3-1-12" - ], "emea-gbr-def-stan-05-138-2024": [ "4106" ], @@ -82996,18 +85073,23 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-nist-csf-2-0": [ "DE.CM-06" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(c)", + "3.4.2.31(d)" + ], "emea-eu-nis2-annex-2024": [ "3.2.3(b)", "11.2.2(f)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1650" ] } @@ -83030,7 +85112,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to ensure event log reviews include analysis and triage practices that integrate with the organization's established incident response processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83118,7 +85200,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -83180,7 +85263,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to make event log review processes more efficient and effective by developing and maintaining an incident response escalation matrix.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83268,7 +85351,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -83291,8 +85375,8 @@ "control_id": "MON-18", "title": "File Activity Monitoring (FAM)", "family": "MON", - "description": "Automated mechanisms exist to monitor sensitive/regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories.", - "scf_question": "Does the organization use automated tools to monitor sensitive/regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories?", + "description": "Automated mechanisms exist to monitor sensitive and/or regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories.", + "scf_question": "Does the organization use automated mechanisms to monitor sensitive and/or regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -83391,7 +85475,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -83420,7 +85505,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to produce event logs on hardware-enforced, write-once media (e.g., Write Once Read Many (WORM) technologies).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83448,9 +85533,9 @@ "NT-7", "MT-2", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (IEC 62443-4-2)", "family_name": "Continuous Monitoring", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -83547,7 +85632,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -83565,7 +85651,7 @@ "general-cis-csc-8-1": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-cis-csc-8-1-ig1": [ @@ -83574,13 +85660,13 @@ "general-cis-csc-8-1-ig2": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-cis-csc-8-1-ig3": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-csa-cmm-4-1-0": [ @@ -83646,7 +85732,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -83725,6 +85811,14 @@ "A.03.13.11.ODP[01]", "A.03.13.11" ], + "general-nist-800-172-r3": [ + "03.14.09E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.09E[01]", + "DS-A.03.14.09E[02]", + "DS-A.03.14.09E[03]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -83769,9 +85863,6 @@ "8.3.2", "12.3.3" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-sparta": [ "CM0050" ], @@ -83834,16 +85925,19 @@ "SC-08(02)", "SC-13" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.E.2", @@ -83889,7 +85983,7 @@ "SC-13" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "emea-eu-gdpr-2016": [ "Article 32.1(a)" @@ -83902,61 +85996,57 @@ "9.2(a)", "9.2(b)" ], - "emea-us-psd2-2015": [ - "20", - "30" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-deu-fdpa-2017": [ + "3.2.48(2)7" ], "emea-deu-c5-2020": [ - "CRY-01" + "KRY-01", + "KRY-01-BP1", + "KRY-01-BP2", + "KRY-01-BP3", + "KRY-01-BP4", + "KRY-02" ], - "emea-isr-cmo-1-0": [ - "8.1", - "8.8", - "15.7", - "21.16" + "emea-isr-cmo-2-0": [ + "Appendix A, 3.1" ], "emea-sau-cscc-1-2019": [ - "2-7", + "2-7-1", "2-7-1-3" ], "emea-sau-ecc-1-2018": [ "2-8-1", "2-8-2", - "2-8-3", - "2-8-3-1", - "2-8-4" + "2-8-3-1" ], "emea-sau-otcc-1-2022": [ - "2-2-1-4", - "2-7", + "2-6-1", "2-7-1", "2-7-2" ], "emea-sau-sacs-002-2022": [ - "TPC-52", - "TPC-54" + "VII.B.TPC-54" ], "emea-sau-sama-csf-1-2017": [ - "3.3.9" + "3.3.9", + "3.3.9.1", + "3.3.9.4", + "3.3.9.4.a", + "3.3.9.4.b", + "3.3.9.4.c" ], - "emea-zaf-popia-2013": [ - "14.1", - "19.1", - "19.2" + "emea-esp-decree-311-2022": [ + "Article 12(6)(j)" ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.2 [MP.COM.2]", - "8.4.3 [MP.COM.3]", - "8.5.2 [MP.SI.2]", - "8.7.3 [MP.INFO.3]", - "8.7.4 [MP.INFO.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" + ], + "emea-gbr-cap-1850-2020": [ + "B3" ], "emea-gbr-def-stan-05-138-2024": [ "2304", @@ -83978,7 +86068,7 @@ "2317", "2318" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0142", "ISM-0457", "ISM-0460", @@ -83997,6 +86087,7 @@ "ISM-1080", "ISM-1091", "ISM-1146", + "ISM-1233", "ISM-1446", "ISM-1629", "ISM-1759", @@ -84040,7 +86131,11 @@ "14.1.3.5", "14.1.3.6" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.22" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP37", "HML37" ], @@ -84087,7 +86182,6 @@ "17.4.16.C.01", "17.4.16.C.02", "17.5.6.C.01", - "17.6.6.C.01", "17.6.7.C.01", "17.7.6.C.01", "17.8.10.C.01", @@ -84099,30 +86193,20 @@ "17.8.15.C.01", "17.8.16.C.01", "17.8.17.C.01", - "17.9.24.C.01", - "17.9.24.C.02", - "17.9.24.C.03", - "17.9.25.C.01", - "17.9.26.C.01", - "17.9.26.C.02", - "17.9.27.C.01", - "17.9.27.C.02", - "17.9.27.C.03", - "17.9.28.C.01", - "17.9.29.C.01", "17.9.30.C.01", "17.9.30.C.02", + "17.9.30.C.03", "17.9.31.C.01", "17.9.32.C.01", "17.9.32.C.02", - "17.9.32.C.03" + "17.9.38.C.01", + "17.9.38.C.02" ], "apac-sgp-mas-trm-2021": [ + "6.4.5", "10.1.1", - "10.1.2", "10.1.3", - "10.1.4", - "10.1.5" + "10.1.4" ], "americas-bmu-mba-coc-2020": [ "6.22" @@ -84130,6 +86214,9 @@ "americas-can-osfi-b13-2022": [ "3.2.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.13.08", "03.13.11" @@ -84156,9 +86243,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of information as an alternative to physical safeguards.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of information as an alternative to physical safeguards. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84227,7 +86314,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -84278,6 +86366,9 @@ "3.13.8[b]", "3.13.8[c]" ], + "general-nist-800-171a-r3": [ + "A.03.13.08[02]" + ], "general-nist-csf-2-0": [ "PR.DS-01" ], @@ -84312,9 +86403,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-08 (01)" ], - "emea-isr-cmo-1-0": [ - "15.7" - ], "americas-can-itsp-10-171-2025": [ "03.13.08" ] @@ -84338,7 +86426,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to address the exporting of cryptographic technologies in compliance with relevant statutory and regulatory requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84372,7 +86460,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -84483,7 +86572,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to ensure the confidentiality and integrity of information during preparation for transmission and during reception.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84522,7 +86611,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -84553,7 +86643,7 @@ "usa-federal-cms-marse-2-0": [ "SC-8(2)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0548", "ISM-0554" ] @@ -84577,7 +86667,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to conceal or randomize communication patterns.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84613,7 +86703,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -84639,7 +86730,9 @@ "scf_question": "Does the organization identify, document and review deployed cryptographic cipher suites and protocols to proactively respond to industry trends regarding the continued viability of utilized cryptographic cipher suites and protocols?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", - "evidence_requests": [], + "evidence_requests": [ + "E-QTS-04" + ], "pptdf": "Process", "nist_csf_function": "Protect", "scrm_focus": { @@ -84649,7 +86742,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to identify, document and review deployed cryptographic cipher suites and protocols to proactively respond to industry trends regarding the continued viability of utilized cryptographic cipher suites and protocols.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84685,13 +86778,20 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { "general-nist-800-171-r3": [ "03.13.11" ], + "general-nist-800-171a-r3": [ + "A.03.13.11" + ], + "general-nist-cswp-39": [ + "3.1" + ], "general-pci-dss-4-0-1": [ "12.3.3" ], @@ -84704,6 +86804,17 @@ "emea-sau-cscc-1-2019": [ "2-7-1-3" ], + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.22" + ], + "apac-nzl-ism-3-9": [ + "17.9.34.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "10.1.2", + "10.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.13.11" ] @@ -84779,9 +86890,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Cryptographic Protections", "crosswalks": { "general-govramp": [ @@ -84878,13 +86989,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-07" - ], - "emea-isr-cmo-1-0": [ - "4.37", - "12.10" - ], - "emea-sau-ecc-1-2018": [ - "2-8-3-1" ] } }, @@ -84910,7 +87014,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Sensitive/regulated data is encrypted in transit according to standardized processes.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ Sensitive/regulated data is encrypted at rest using cryptographic protections that are commensurate with the sensitivity of the data.\n▪ Sensitive/regulated data is encrypted during transmission using cryptographic protections that are commensurate with the sensitivity of the data.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality of data being transmitted.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality of data being transmitted. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84966,7 +87070,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -84980,13 +87085,13 @@ "CC6.7-POF2" ], "general-cis-csc-8-1": [ - "3.1" + "3.10" ], "general-cis-csc-8-1-ig2": [ - "3.1" + "3.10" ], "general-cis-csc-8-1-ig3": [ - "3.1" + "3.10" ], "general-csa-cmm-4-1-0": [ "CEK-03", @@ -85038,7 +87143,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1090", @@ -85120,7 +87225,8 @@ "3.13.8" ], "general-nist-800-171-r3": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "general-nist-800-171a": [ "3.13.8[a]", @@ -85178,9 +87284,6 @@ "A2.1.1", "A2.1.2" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-swift-cscf-2025": [ "2.1", "2.5A", @@ -85230,14 +87333,17 @@ "SC-08", "SC-08(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.d", @@ -85255,6 +87361,9 @@ "usa-state-ma-201-cmr-17-2008": [ "17.04(3)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(a)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.15(a)" ], @@ -85271,24 +87380,11 @@ "2447(c)(5)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" - ], - "emea-us-psd2-2015": [ - "20", - "30" + "3.4.4.36(f)" ], "emea-deu-c5-2020": [ - "CRY-02" - ], - "emea-isr-cmo-1-0": [ - "4.22", - "8.4", - "8.5", - "8.6", - "9.8", - "9.20", - "12.10", - "13.6" + "KRY-02", + "KRY-02-DOAR" ], "emea-sau-cscc-1-2019": [ "2-3-1-5", @@ -85304,18 +87400,26 @@ "2-8-3-3" ], "emea-sau-otcc-1-2022": [ - "2-2-1-4" + "2-6-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-52", - "TPC-53" + "VII.B.TPC-52", + "VII.B.TPC-53" ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.1", + "mp.s.2" ], "emea-gbr-caf-4-0": [ "B3.b" ], + "emea-gbr-cap-1850-2020": [ + "B3" + ], "emea-gbr-def-stan-05-138-2024": [ "2302", "2306" @@ -85331,10 +87435,9 @@ "2302", "2306" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0231", "ISM-0232", - "ISM-0241", "ISM-0465", "ISM-0467", "ISM-0469", @@ -85354,11 +87457,19 @@ "ISM-1589", "ISM-1781" ], + "apac-aus-cop-sitc-2020": [ + "7" + ], "apac-ind-sebi-2024": [ "PR.DS.S1" ], + "americas-arg-ppd-2018": [ + "A.2.1", + "A.2.3-DS" + ], "americas-can-itsp-10-171-2025": [ - "03.13.08" + "03.13.08", + "03.13.11" ] } }, @@ -85384,7 +87495,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ Sensitive/regulated data is encrypted at rest using cryptographic protections that are commensurate with the sensitivity of the data.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity of data being transmitted.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity of data being transmitted. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85438,7 +87549,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -85486,7 +87598,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1090", @@ -85617,10 +87729,10 @@ "SC-28(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "usa-federal-irs-1075-2021": [ "SC-8", @@ -85638,32 +87750,23 @@ "SC-08", "SC-28 (01)" ], - "emea-us-psd2-2015": [ - "20", - "30" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "4.22", - "9.8", - "9.20", - "12.10", - "13.6" + "emea-sau-cscc-1-2019": [ + "2-3-1-5", + "2-7-1-1" ], "emea-sau-cgiot-2024": [ "2-4-1", "2-4-2", "2-4-3" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0677" ], "apac-jpn-ismap": [ @@ -85693,7 +87796,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of data at rest.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of data at rest. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85749,7 +87852,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -85825,7 +87929,7 @@ "general-iso-27018-2025": [ "8.24" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -85939,7 +88043,8 @@ "3.13.16" ], "general-nist-800-171-r3": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "general-nist-800-171a": [ "3.8.6" @@ -85981,9 +88086,6 @@ "3.5.1.3", "8.3.2" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-swift-cscf-2025": [ "2.5A" ], @@ -86038,6 +88140,9 @@ "SC-28", "SC-28(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-irs-1075-2021": [ "2.B.6-1", "3.3.1.e", @@ -86068,14 +88173,11 @@ "SC-28 (01)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "emea-deu-c5-2020": [ - "CRY-03" - ], - "emea-isr-cmo-1-0": [ - "8.7", - "15.7" + "KRY-02", + "KRY-03" ], "emea-sau-cscc-1-2019": [ "2-7-1-2" @@ -86086,12 +88188,20 @@ "emea-sau-ecc-1-2018": [ "2-8-3-3" ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-sau-otcc-1-2022": [ + "2-6-1-1" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "emea-gbr-caf-4-0": [ "B3.c" ], + "emea-gbr-cap-1850-2020": [ + "B3" + ], "emea-gbr-def-stan-05-138-2024": [ "2310", "2317" @@ -86108,7 +88218,7 @@ "2310", "2317" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0459", "ISM-1080" ], @@ -86121,8 +88231,12 @@ "apac-nzl-ism-3-9": [ "8.4.13.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.3" + ], "americas-can-itsp-10-171-2025": [ - "03.13.08" + "03.13.08", + "03.13.11" ] } }, @@ -86130,8 +88244,8 @@ "control_id": "CRY-05.1", "title": "Storage Media", "family": "CRY", - "description": "Cryptographic mechanisms exist to protect the confidentiality and integrity of sensitive/regulated data residing on storage media.", - "scf_question": "Are cryptographic mechanisms utilized to protect the confidentiality and integrity of sensitive/regulated data residing on storage media?", + "description": "Cryptographic mechanisms exist to protect the confidentiality and integrity of sensitive and/or regulated data residing on storage media.", + "scf_question": "Are cryptographic mechanisms utilized to protect the confidentiality and integrity of sensitive and/or regulated data residing on storage media?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -86144,7 +88258,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of sensitive/regulated data residing on storage media.", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86199,7 +88313,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -86221,22 +88336,15 @@ "general-nist-800-171-r3": [ "03.13.08" ], + "general-nist-800-171a-r3": [ + "A.03.13.08[02]" + ], "general-pci-dss-4-0-1": [ "9.4" ], "general-swift-cscf-2025": [ "2.5A" ], - "emea-deu-c5-2020": [ - "CRY-03" - ], - "emea-isr-cmo-1-0": [ - "15.7" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8", - "2-3-1-9" - ], "apac-nzl-ism-3-9": [ "8.4.13.C.01" ], @@ -86330,7 +88438,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -86378,7 +88487,7 @@ }, "maturity": { "0": "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.", - "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.).", + "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.). ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure that database servers utilize encryption to protect the confidentiality of the data within the databases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86445,11 +88554,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1080", "ISM-1277" ] @@ -86524,7 +88634,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -86639,7 +88750,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -86716,6 +88828,9 @@ "general-nist-800-171-r3": [ "03.01.16.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -86782,21 +88897,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-18" ], - "emea-isr-cmo-1-0": [ - "4.22" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-4" - ], "emea-sau-sacs-002-2022": [ - "TPC-42" + "VII.B.TPC-42" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1314", "ISM-1332" ], "apac-nzl-ism-3-9": [ "18.2.9.C.01", + "18.2.9.C.02", "18.2.10.C.01", "18.2.10.C.02", "18.2.11.C.01", @@ -86846,9 +88956,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ The IT department implements Public Key Infrastructure (PKI) key management controls to protect the confidentiality, integrity and availability of keys.\n▪ The IT department implements and maintains an internal PKI infrastructure or obtains PKI services from a reputable PKI service provider.\n▪ The PKI infrastructure enables the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes.\n▪ The PKI infrastructure ensures the availability of information in the event of the loss of cryptographic keys by individual users.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86907,7 +89017,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -86947,7 +89058,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1072", "T1098.004", "T1521.003", @@ -87002,6 +89113,9 @@ "3.13.10[a]", "3.13.10[b]" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[01]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -87055,21 +89169,19 @@ "SC-12", "SC-17" ], - "emea-isr-cmo-1-0": [ - "8.2", - "8.9" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0485", - "ISM-1449" + "ISM-1449", + "ISM-2050" ], "apac-nzl-ism-3-9": [ "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03", "23.3.21.C.01", "23.3.22.C.01" ], + "americas-arg-ppd-2018": [ + "A.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.13.10" ] @@ -87093,7 +89205,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of data in the event of the loss of cryptographic keys.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87159,7 +89271,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -87173,9 +89286,7 @@ "3.6.1" ], "apac-nzl-ism-3-9": [ - "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03" + "17.1.51.C.01" ] } }, @@ -87200,7 +89311,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -87288,7 +89399,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -87371,6 +89483,9 @@ "A.03.13.10[01]", "A.03.13.10[02]" ], + "general-nist-cswp-39": [ + "3.3" + ], "general-owasp-top-10-2025": [ "A04:2025" ], @@ -87450,21 +89565,26 @@ "9.3" ], "emea-deu-c5-2020": [ - "CRY-04" - ], - "emea-isr-cmo-1-0": [ - "8.2", - "8.9", - "8.10" + "KRY-03", + "KRY-04", + "KRY-04-BP1", + "KRY-04-BP3", + "KRY-04-BP4", + "KRY-04-BP5", + "KRY-04-BP6", + "KRY-04-BP7", + "KRY-04-BP8" ], "emea-sau-ecc-1-2018": [ "2-8-3-2" ], "emea-sau-sacs-002-2022": [ - "TPC-55" + "VII.B.TPC-55" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.11 [OP.EXP.11]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "emea-gbr-def-stan-05-138-2024": [ "2319" @@ -87478,7 +89598,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2319" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0455", "ISM-0507" ], @@ -87505,6 +89625,11 @@ "10.1.2.19", "10.1.2.20.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.21", + "10.23" + ], "apac-nzl-ism-3-9": [ "17.1.51.C.01", "17.1.58.C.01", @@ -87516,20 +89641,26 @@ "23.4.9.C.03" ], "apac-sgp-mas-trm-2021": [ + "6.4.5", "10.2.1", "10.2.2", "10.2.3", "10.2.4", "10.2.5", "10.2.6", - "10.2.7", "10.2.8", - "10.2.9", "10.2.10" ], + "americas-arg-ppd-2018": [ + "A.2.3" + ], "americas-can-osfi-b13-2022": [ "3.2.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.9.2", + "3.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.13.10" ] @@ -87555,9 +89686,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of symmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of symmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87620,7 +89751,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -87679,9 +89811,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of asymmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes that protect the user’s private key.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of asymmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes that protect the user’s private key. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87744,7 +89876,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -87791,9 +89924,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of information in the event of the loss of cryptographic keys by individual users.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of information in the event of the loss of cryptographic keys by individual users. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87875,7 +90008,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -87929,6 +90063,9 @@ "general-nist-800-171-r3": [ "03.13.10" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[02]" + ], "general-pci-dss-4-0-1": [ "2.3.2", "3.6.1", @@ -87959,17 +90096,21 @@ "emea-eu-nis2-annex-2024": [ "9.2(c)(v)" ], - "emea-isr-cmo-1-0": [ - "8.3", - "8.11" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0455", "ISM-0462" ], "apac-nzl-ism-3-9": [ - "7.2.24.C.01", - "7.2.25.C.01" + "7.2.24.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "10.2.7", + "10.2.9" ], "americas-can-itsp-10-171-2025": [ "03.13.10" @@ -87994,9 +90135,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88078,7 +90219,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -88103,6 +90245,9 @@ "general-nist-800-171-r3": [ "03.13.10" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[02]" + ], "general-pci-dss-4-0-1": [ "3.6.1" ], @@ -88119,12 +90264,10 @@ "9.2(c)(iv)", "9.2(c)(v)" ], - "emea-isr-cmo-1-0": [ - "8.9", - "8.11" - ], - "apac-sgp-mas-trm-2021": [ - "10.2.5" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "americas-can-itsp-10-171-2025": [ "03.13.10" @@ -88149,9 +90292,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure cryptographic keys are bound to individual identities.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure cryptographic keys are bound to individual identities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88213,7 +90356,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": {} @@ -88236,7 +90380,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure customers are provided with appropriate key management guidance whenever cryptographic keys are shared.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88271,7 +90415,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -88304,7 +90449,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to maintain control of cryptographic keys for encrypted material stored or transmitted through an external system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88374,7 +90519,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -88411,9 +90557,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to associate Technology Assets, Applications and/or Services (TAAS) security attributes with information exchanged between TAAS.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to associate Technology Assets, Applications and/or Services (TAAS) security attributes with information exchanged between TAAS. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88466,11 +90612,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1505", "T1505.002", "T1573", @@ -88527,7 +90674,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to automatically enable the use of organization-defined Certificate Authorities (CAs) to facilitate the establishment of protected sessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88596,7 +90743,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -88710,7 +90858,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -88784,13 +90933,11 @@ "MT-16", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "general-nist-800-172": [ - "3.14.1e" - ], "usa-federal-dow-cmmc-2-level-3": [ "SI.L3-3.14.1E" ] @@ -88818,7 +90965,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ A basic data classification process exists to identify categories of sensitive/regulated data for compliance-related protection requirements.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of data protection controls.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of data protection controls. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88917,7 +91064,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -88946,10 +91094,10 @@ "PI1.5-POF4" ], "general-cis-csc-8-1": [ - "3.0", + "3", "3.1", "3.3", - "11.0", + "11", "11.3" ], "general-cis-csc-8-1-ig1": [ @@ -89110,6 +91258,18 @@ "3.8.1[c]", "3.8.1[d]" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.08.01[01]", + "A.03.08.01[02]" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -89151,9 +91311,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.4.1" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "general-shared-assessments-sig-2025": [ "P.3" ], @@ -89232,6 +91389,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "MP-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(b)" + ], "usa-federal-sro-finra": [ "248.30(a)(2)(i)", "248.30(a)(2)(iii)" @@ -89245,16 +91405,16 @@ "155.260(a)(4)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.2", @@ -89278,6 +91438,9 @@ "usa-federal-dow-safeguarding-nnpi-2010": [ "9-2" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.3(b)", "500.18" @@ -89297,128 +91460,35 @@ "emea-eu-ai-act-2024": [ "Article 17.1(f)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-c5-2020": [ - "COS-08" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "5.2", - "5.3", - "5.5", - "11.6", - "15.1", - "15.6", - "15.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "AM-07", + "RB-23" ], "emea-sau-cscc-1-2019": [ - "2-6", + "2-6-1", "2-6-1-3" ], "emea-sau-ecc-1-2018": [ - "2-1-6", - "2-3-3", - "2-3-3-2", - "2-3-4", - "2-7-1", - "2-7-2", - "2-7-3", - "2-7-4", - "2-7-3-3" + "2-7-1" ], "emea-sau-otcc-1-2022": [ - "2-6", "2-6-1", - "2-6-1-1", "2-6-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-24", - "TPC-39", - "TPC-58" - ], - "emea-srb-act-9-2018": [ - "65" - ], - "emea-zaf-popia-2013": [ - "14.1", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 22.1", - "Article 22.3" - ], "emea-esp-decree-311-2022": [ - "22.1", - "22.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" + "Article 22(3)" ], - "emea-che-fadp-2025": [ - "6", - "7" - ], - "emea-tur-lppd-2016": [ - "8", - "12" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.info.2" ], "emea-gbr-caf-4-0": [ "B3" ], - "emea-gbr-cap-1850-2020": [ - "B3" - ], "emea-gbr-def-stan-05-138-2024": [ "2300", "2308" @@ -89432,45 +91502,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2308" ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-privacy-principles-2026": [ - "APP 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0337", "ISM-0831", "ISM-1059", "ISM-1549", "ISM-1599" ], - "apac-aus-ps-cps-234-2019": [ - "20", - "21(a)" - ], "apac-chn-cybersecurity-law-2017": [ "Article 40" ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], "apac-ind-sebi-2024": [ "PR.AA.S14", "PR.DS.S4" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "5.1.1.10", "5.1.1.14", @@ -89484,10 +91529,7 @@ "13.2.1.13", "13.2.1.14" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HHSP34", "HHSP74", @@ -89518,51 +91560,24 @@ "13.2.6.C.01", "13.2.7.C.01" ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], "apac-sgp-mas-trm-2021": [ "11.1.1", - "11.1.1(a)", - "11.1.1(b)", - "11.1.1(c)", - "11.1.2", - "11.1.3", - "11.1.4", - "11.1.5", - "11.1.6", - "11.1.7" - ], - "apac-twn-pdpa-2025": [ - "21" + "11.1.2" ], "americas-bmu-mba-coc-2020": [ - "6.8", - "6.10", - "6.13" - ], - "americas-bra-lgpd-2018": [ - "46", - "47" + "5.3-BP3" ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.D.01", "03.01.01.D.02", "03.08.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" ] } }, @@ -89589,7 +91604,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data stewardship is assigned, documented and communicated.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data stewardship is assigned, documented and communicated. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89661,7 +91676,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -89711,6 +91727,11 @@ "03.08.01", "03.08.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.05.a[01]" + ], "general-nist-csf-2-0": [ "ID.AM-08", "PR.DS" @@ -89769,28 +91790,16 @@ "usa-federal-irs-1075-2021": [ "SA-4(CE-12)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(b)" + ], "emea-deu-c5-2020": [ "AM-06" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], "emea-sau-ecc-1-2018": [ + "2-7-1", "2-7-3-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-39", - "TPC-58" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" - ], - "apac-jpn-ppi-2020": [ - "21" - ], - "apac-sgp-mas-trm-2021": [ - "3.3.1(c)" - ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.05.A" @@ -89801,8 +91810,8 @@ "control_id": "DCH-01.2", "title": "Sensitive / Regulated Data Protection", "family": "DCH", - "description": "Mechanisms exist to protect sensitive/regulated data wherever it is processed and/or stored.", - "scf_question": "Does the organization protect sensitive/regulated data wherever it is processed and/or stored?", + "description": "Mechanisms exist to protect sensitive and/or regulated data wherever it is processed and/or stored.", + "scf_question": "Does the organization protect sensitive and/or regulated data wherever it is processed and/or stored?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -89819,7 +91828,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data wherever it is processed and/or stored.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89860,7 +91869,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -89928,8 +91938,27 @@ "03.08.05.a", "03.17.01.c" ], - "general-nist-800-172": [ - "3.14.5e" + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.d", + "A.03.06.05.d", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.08.05.a[02]", + "A.03.17.01.c" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -89981,12 +92010,12 @@ "52.204-21(b)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(1)" + "§ 164.312(c)(1)" ], "usa-federal-irs-1075-2021": [ "2.C.5", @@ -90040,6 +92069,9 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(g)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(b)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.18" ], @@ -90054,27 +92086,29 @@ "usa-state-vt-act-171-2018": [ "2447(b)(3)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-deu-c5-2020": [ + "AM-07", + "RB-11" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" + ], + "emea-sau-cscc-1-2019": [ + "2-6-1-1", + "2-6-1-3" + ], + "emea-sau-ecc-1-2018": [ + "2-7-1" ], "emea-sau-otcc-1-2022": [ - "2-6-1-1" + "2-1-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-24", - "TPC-39", - "TPC-58" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 22.1", - "Article 22.3" + "VII.B.TPC-39", + "VII.B.TPC-58" ], "emea-esp-decree-311-2022": [ - "22.1", - "22.3" - ], - "emea-gbr-cap-1850-2020": [ - "B3" + "Article 22(3)" ], "emea-gbr-def-stan-05-138-2024": [ "2308" @@ -90085,10 +92119,13 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2308" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1802" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HHSP74", "HML14", @@ -90099,8 +92136,25 @@ "HSUP66" ], "apac-nzl-ism-3-9": [ + "16.2.7.C.01", + "16.2.7.C.02", "18.6.8.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.1(a)", + "11.1.1(b)", + "11.1.1(c)", + "11.1.6" + ], + "americas-bhs-dpa-2003": [ + "V.46(1)", + "V.46(2)", + "V.46(2)(a)", + "V.46(2)(b)" + ], + "americas-bmu-mba-coc-2020": [ + "6.13" + ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" @@ -90125,8 +92179,8 @@ "control_id": "DCH-01.3", "title": "Sensitive / Regulated Media Records", "family": "DCH", - "description": "Mechanisms exist to ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", - "scf_question": "Does the organization ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident?", + "description": "Mechanisms exist to ensure media records for sensitive and/or regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", + "scf_question": "Does the organization ensure media records for sensitive and/or regulated data contain sufficient information to determine the potential impact in the event of a data loss incident?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -90141,7 +92195,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90230,7 +92284,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -90240,12 +92295,12 @@ "general-nist-800-171-r3": [ "03.08.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.c" + ], "general-nist-csf-2-0": [ "PR.DS" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "apac-jpn-ismap": [ "8.2.3.3", "8.2.3.4", @@ -90260,8 +92315,8 @@ "control_id": "DCH-01.4", "title": "Defining Access Authorizations for Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data.", - "scf_question": "Does the organization explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data?", + "description": "Mechanisms exist to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive and/or regulated data.", + "scf_question": "Does the organization explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive and/or regulated data?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -90277,7 +92332,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90352,7 +92407,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -90401,9 +92457,27 @@ "03.17.01.c" ], "general-nist-800-171a-r3": [ + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", "A.03.15.02.c", "A.03.17.01.c" ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.b", + "A.03.01.17E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -90420,14 +92494,24 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "5.0" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(b)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(4)(ii)" ], "usa-federal-dow-safeguarding-nnpi-2010": [ "9-2.a" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-sau-cscc-1-2019": [ + "2-6-1-1", + "2-6-1-3" + ], + "emea-sau-ecc-1-2018": [ + "2-7-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-39" ], "emea-gbr-def-stan-05-138-2024": [ "2301" @@ -90441,6 +92525,13 @@ "apac-jpn-ismap": [ "8.2.3.2" ], + "apac-sgp-mas-trm-2021": [ + "11.1.6" + ], + "americas-arg-ppd-2018": [ + "B.1.3-2", + "B.2.1-2" + ], "americas-can-itsp-10-171-2025": [ "03.01.02", "03.01.03", @@ -90474,9 +92565,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to categorize data in accordance with organizational policies and standards.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -90551,7 +92642,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -90624,6 +92716,18 @@ "03.08.01", "03.08.04" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.04[01]" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -90658,9 +92762,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.4.2" ], - "general-scf-dpmp-2025": [ - "1.2" - ], "general-sparta": [ "CM0001" ], @@ -90704,10 +92805,9 @@ "Article 17.1(f)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)", - "3.3.3(19)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "emea-eu-nis2-annex-2024": [ "2.1.3", @@ -90716,20 +92816,23 @@ ], "emea-deu-bsrit-2017": [ "7.13", - "7.14", - "12.4" + "7.14" ], "emea-deu-c5-2020": [ "AM-02", + "AM-05", "AM-06", - "COS-08", - "PI-01" + "PI-01", + "SIM-02" ], - "emea-isr-cmo-1-0": [ - "5.3", - "15.2" + "emea-hun-act-cxii-2011": [ + "II.4.4(3)" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" ], "emea-sau-cscc-1-2019": [ + "2-6-1-1", "2-6-1-2" ], "emea-sau-cgiot-2024": [ @@ -90738,33 +92841,23 @@ "emea-sau-ecc-1-2018": [ "2-1-5", "2-7-3-2", + "2-7-3-3", "4-2-3-1" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-1" - ], "emea-sau-sacs-002-2022": [ - "TPC-24" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 40.1", - "Article 40.2", - "Article 41.2" + "VII.B.TPC-24" ], "emea-esp-decree-311-2022": [ - "40.1", - "40.2", - "41.2" + "Article 40(1)" ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.2 [MP.INFO.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "mp.info.2" ], "emea-gbr-caf-4-0": [ "B3.a" ], - "emea-gbr-cap-1850-2020": [ - "B3" - ], "emea-gbr-def-stan-05-138-2024": [ "2301" ], @@ -90774,7 +92867,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0270", "ISM-0271", "ISM-0272", @@ -90783,9 +92876,11 @@ "ISM-0323", "ISM-0393" ], + "apac-aus-ps-cps-230-2023": [ + "36" + ], "apac-aus-ps-cps-234-2019": [ - "20", - "21(a)" + "20" ], "apac-ind-sebi-2024": [ "PR.DS.S2" @@ -90803,7 +92898,7 @@ "8.2.1.9", "8.2.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HML34" ], "apac-nzl-hisf-suppliers-2023": [ @@ -90817,20 +92912,34 @@ "12.3.7.C.01", "18.6.8.C.01" ], + "apac-sgp-pdpa-2012": [ + "4.1.13", + "5.21(6)(b)", + "5.22(7)" + ], "apac-sgp-mas-trm-2021": [ "3.3.1(b)" ], "americas-bmu-mba-coc-2020": [ + "5.3-BP2", + "5.9-BP2", "6.8" ], "americas-can-osfi-b13-2022": [ "2.2.2", "3.1.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4", + "3.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.04.11.A", "03.08.01", "03.08.04" + ], + "americas-col-law-1581-2012": [ + "III.5" ] } }, @@ -90852,7 +92961,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to categorize data in accordance with organizational policies and standards.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that Technology Assets, Applications and/or Services (TAAS) are classified according to the highest level of data sensitivity that is stored, transmitted and/or processed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90921,7 +93030,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -90949,13 +93059,7 @@ "emea-sau-cscc-1-2019": [ "2-6-1-1" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-24" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0323", "ISM-0325" ], @@ -90987,9 +93091,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to control and restrict access to digital and non-digital media to authorized individuals.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to control and restrict access to digital and non-digital media to authorized individuals. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91077,7 +93181,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -91162,6 +93267,10 @@ "3.8.2" ], "general-nist-800-171a-r3": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", "A.03.08.02" ], "general-nist-csf-2-0": [ @@ -91190,10 +93299,10 @@ "MP-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MP-2" @@ -91210,8 +93319,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-02" ], - "emea-sau-sacs-002-2022": [ - "TPC-39" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2301" @@ -91233,8 +93344,8 @@ "control_id": "DCH-03.1", "title": "Disclosure of Information", "family": "DCH", - "description": "Mechanisms exist to restrict the disclosure of sensitive/regulated data to authorized parties with a need to know.", - "scf_question": "Does the organization restrict the disclosure of sensitive/regulated data to authorized parties with a need to know?", + "description": "Mechanisms exist to restrict the disclosure of sensitive and/or regulated data to authorized parties with a need to know.", + "scf_question": "Does the organization restrict the disclosure of sensitive and/or regulated data to authorized parties with a need to know?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -91247,7 +93358,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the disclosure of sensitive/regulated data to authorized parties with a need to know.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -91329,7 +93440,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -91388,6 +93500,7 @@ "03.17.01.c" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", "A.03.15.02.c", "A.03.17.01.c" ], @@ -91423,130 +93536,130 @@ "1232h(c)(1)(B)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.510(b)(1)(i)", - "164.510(b)(1)(ii)", - "164.510(b)(2)", - "164.510(b)(4)", - "164.510(b)(5)", - "164.512", - "164.512(a)(1)", - "164.512(c)(1)", - "164.512(c)(1)(i)", - "164.512(c)(1)(ii)", - "164.512(c)(1)(iii)(A)", - "164.512(c)(1)(iii)(B)", - "164.512(c)(2)", - "164.512(c)(2)(i)", - "164.512(c)(2)(ii)", - "164.512(d)(1)", - "164.512(d)(1)(i)", - "164.512(d)(1)(ii)", - "164.512(d)(1)(iii)", - "164.512(d)(1)(iv)", - "164.512(e)(1)", - "164.512(e)(1)(i)", - "164.512(e)(1)(ii)", - "164.512(e)(1)(ii)(A)", - "164.512(e)(1)(ii)(B)", - "164.512(e)(1)(iii)", - "164.512(e)(1)(iii)(A)", - "164.512(e)(1)(iii)(B)", - "164.512(e)(1)(iii)(C)", - "164.512(e)(1)(iii)(C)(1)", - "164.512(e)(1)(iii)(C)(2)", - "164.512(e)(1)(iv)", - "164.512(e)(1)(iv)(A)", - "164.512(e)(1)(iv)(B)", - "164.512(e)(1)(v)", - "164.512(e)(1)(v)(A)", - "164.512(e)(1)(v)(B)", - "164.512(e)(1)(vi)", - "164.512(f)", - "164.512(f)(1)", - "164.512(f)(1)(i)", - "164.512(f)(1)(ii)(A)", - "164.512(f)(1)(ii)(B)", - "164.512(f)(1)(ii)(C)", - "164.512(f)(1)(ii)(C)(1)", - "164.512(f)(1)(ii)(C)(2)", - "164.512(f)(1)(ii)(C)(3)", - "164.512(f)(2)", - "164.512(f)(2)(i)(A)", - "164.512(f)(2)(i)(B)", - "164.512(f)(2)(i)(C)", - "164.512(f)(2)(i)(D)", - "164.512(f)(2)(i)(E)", - "164.512(f)(2)(i)(F)", - "164.512(f)(2)(i)(G)", - "164.512(f)(2)(i)(H)", - "164.512(f)(2)(ii)", - "164.512(f)(3)", - "164.512(f)(3)(i)", - "164.512(f)(3)(ii)", - "164.512(f)(3)(ii)(A)", - "164.512(f)(3)(ii)(B)", - "164.512(f)(3)(ii)(C)", - "164.512(f)(4)", - "164.512(f)(5)", - "164.512(f)(6)(i)", - "164.512(f)(6)(i)(A)", - "164.512(f)(6)(i)(B)", - "164.512(f)(6)(i)(C)", - "164.512(f)(6)(ii)", - "164.512(g)(1)", - "164.512(g)(2)", - "164.512(h)", - "164.512(i)(1)", - "164.512(j)(1)", - "164.514(d)(3)(i)", - "164.514(d)(3)(ii)(A)", - "164.514(d)(3)(ii)(B)", - "164.514(d)(3)(iii)", - "164.514(d)(3)(iii)(A)", - "164.514(d)(3)(iii)(B)", - "164.514(d)(3)(iii)(C)", - "164.514(d)(3)(iii)(D)", - "164.514(d)(4)", - "164.514(d)(4)(i)", - "164.514(d)(4)(ii)", - "164.514(d)(4)(iii)(A)", - "164.514(d)(4)(iii)(B)", - "164.514(d)(5)", - "164.514(e)(1)", - "164.514(e)(2)", - "164.514(e)(2)(i)", - "164.514(e)(2)(ii)", - "164.514(e)(2)(iii)", - "164.514(e)(2)(iv)", - "164.514(e)(2)(v)", - "164.514(e)(2)(vi)", - "164.514(e)(2)(vii)", - "164.514(e)(2)(viii)", - "164.514(e)(2)(ix)", - "164.514(e)(2)(x)", - "164.514(e)(2)(xi)", - "164.514(e)(2)(xii)", - "164.514(e)(2)(xiii)", - "164.514(e)(2)(xiv)", - "164.514(e)(2)(xv)", - "164.514(e)(2)(xvi)", - "164.514(e)(3)(i)", - "164.514(e)(3)(ii)", - "164.514(e)(4)(i)", - "164.514(e)(4)(ii)", - "164.514(e)(4)(ii)(A)", - "164.514(e)(4)(ii)(B)", - "164.514(e)(4)(ii)(C)", - "164.514(e)(4)(ii)(C)(1)", - "164.514(e)(4)(ii)(C)(2)", - "164.514(e)(4)(ii)(C)(3)", - "164.514(e)(4)(ii)(C)(4)", - "164.514(e)(4)(ii)(C)(5)", - "164.532(a)", - "164.532(b)", - "164.532(c)", - "164.532(c)(1)", - "164.532(d)" + "§ 164.510(b)(1)(i)", + "§ 164.510(b)(1)(ii)", + "§ 164.510(b)(2)", + "§ 164.510(b)(4)", + "§ 164.510(b)(5)", + "§ 164.512", + "§ 164.512(a)(1)", + "§ 164.512(c)(1)", + "§ 164.512(c)(1)(i)", + "§ 164.512(c)(1)(ii)", + "§ 164.512(c)(1)(iii)(A)", + "§ 164.512(c)(1)(iii)(B)", + "§ 164.512(c)(2)", + "§ 164.512(c)(2)(i)", + "§ 164.512(c)(2)(ii)", + "§ 164.512(d)(1)", + "§ 164.512(d)(1)(i)", + "§ 164.512(d)(1)(ii)", + "§ 164.512(d)(1)(iii)", + "§ 164.512(d)(1)(iv)", + "§ 164.512(e)(1)", + "§ 164.512(e)(1)(i)", + "§ 164.512(e)(1)(ii)", + "§ 164.512(e)(1)(ii)(A)", + "§ 164.512(e)(1)(ii)(B)", + "§ 164.512(e)(1)(iii)", + "§ 164.512(e)(1)(iii)(A)", + "§ 164.512(e)(1)(iii)(B)", + "§ 164.512(e)(1)(iii)(C)", + "§ 164.512(e)(1)(iii)(C)(1)", + "§ 164.512(e)(1)(iii)(C)(2)", + "§ 164.512(e)(1)(iv)", + "§ 164.512(e)(1)(iv)(A)", + "§ 164.512(e)(1)(iv)(B)", + "§ 164.512(e)(1)(v)", + "§ 164.512(e)(1)(v)(A)", + "§ 164.512(e)(1)(v)(B)", + "§ 164.512(e)(1)(vi)", + "§ 164.512(f)", + "§ 164.512(f)(1)", + "§ 164.512(f)(1)(i)", + "§ 164.512(f)(1)(ii)(A)", + "§ 164.512(f)(1)(ii)(B)", + "§ 164.512(f)(1)(ii)(C)", + "§ 164.512(f)(1)(ii)(C)(1)", + "§ 164.512(f)(1)(ii)(C)(2)", + "§ 164.512(f)(1)(ii)(C)(3)", + "§ 164.512(f)(2)", + "§ 164.512(f)(2)(i)(A)", + "§ 164.512(f)(2)(i)(B)", + "§ 164.512(f)(2)(i)(C)", + "§ 164.512(f)(2)(i)(D)", + "§ 164.512(f)(2)(i)(E)", + "§ 164.512(f)(2)(i)(F)", + "§ 164.512(f)(2)(i)(G)", + "§ 164.512(f)(2)(i)(H)", + "§ 164.512(f)(2)(ii)", + "§ 164.512(f)(3)", + "§ 164.512(f)(3)(i)", + "§ 164.512(f)(3)(ii)", + "§ 164.512(f)(3)(ii)(A)", + "§ 164.512(f)(3)(ii)(B)", + "§ 164.512(f)(3)(ii)(C)", + "§ 164.512(f)(4)", + "§ 164.512(f)(5)", + "§ 164.512(f)(6)(i)", + "§ 164.512(f)(6)(i)(A)", + "§ 164.512(f)(6)(i)(B)", + "§ 164.512(f)(6)(i)(C)", + "§ 164.512(f)(6)(ii)", + "§ 164.512(g)(1)", + "§ 164.512(g)(2)", + "§ 164.512(h)", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.514(d)(3)(ii)(A)", + "§ 164.514(d)(3)(ii)(B)", + "§ 164.514(d)(3)(iii)", + "§ 164.514(d)(3)(iii)(A)", + "§ 164.514(d)(3)(iii)(B)", + "§ 164.514(d)(3)(iii)(C)", + "§ 164.514(d)(3)(iii)(D)", + "§ 164.514(d)(4)", + "§ 164.514(d)(4)(i)", + "§ 164.514(d)(4)(ii)", + "§ 164.514(d)(4)(iii)(A)", + "§ 164.514(d)(4)(iii)(B)", + "§ 164.514(d)(5)", + "§ 164.514(e)(1)", + "§ 164.514(e)(2)", + "§ 164.514(e)(2)(i)", + "§ 164.514(e)(2)(ii)", + "§ 164.514(e)(2)(iii)", + "§ 164.514(e)(2)(iv)", + "§ 164.514(e)(2)(v)", + "§ 164.514(e)(2)(vi)", + "§ 164.514(e)(2)(vii)", + "§ 164.514(e)(2)(viii)", + "§ 164.514(e)(2)(ix)", + "§ 164.514(e)(2)(x)", + "§ 164.514(e)(2)(xi)", + "§ 164.514(e)(2)(xii)", + "§ 164.514(e)(2)(xiii)", + "§ 164.514(e)(2)(xiv)", + "§ 164.514(e)(2)(xv)", + "§ 164.514(e)(2)(xvi)", + "§ 164.514(e)(3)(i)", + "§ 164.514(e)(3)(ii)", + "§ 164.514(e)(4)(i)", + "§ 164.514(e)(4)(ii)", + "§ 164.514(e)(4)(ii)(A)", + "§ 164.514(e)(4)(ii)(B)", + "§ 164.514(e)(4)(ii)(C)", + "§ 164.514(e)(4)(ii)(C)(1)", + "§ 164.514(e)(4)(ii)(C)(2)", + "§ 164.514(e)(4)(ii)(C)(3)", + "§ 164.514(e)(4)(ii)(C)(4)", + "§ 164.514(e)(4)(ii)(C)(5)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)", + "§ 164.532(c)(1)", + "§ 164.532(d)" ], "usa-federal-nispom-2020": [ "§117.15(h)", @@ -91572,15 +93685,13 @@ "45.48.430.5", "45.48.430.6" ], - "emea-isr-cmo-1-0": [ - "10.5" + "usa-state-nv-privacy-law-2023": [ + "603A.495.3(b)", + "603A.500.2" ], "emea-sau-cscc-1-2019": [ "2-6-1-3" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], "emea-sau-pdpl-2023": [ "Article 15.3", "Article 15.4", @@ -91596,8 +93707,29 @@ "Article 16.8", "Article 16.9" ], - "emea-sau-sacs-002-2022": [ - "TPC-39" + "apac-aus-privacy-principles-2026": [ + "3.9.2", + "3.9.2.a", + "3.9.2.b", + "3.9.2.c", + "3.9.2.d", + "3.9.2.e", + "3.9.2.f", + "3.9.3", + "3.9.3.a", + "3.9.3.b", + "3.9.3.c" + ], + "apac-chn-pipl-2021": [ + "Article 25" + ], + "apac-ind-privacy-rules-2011": [ + "6(1)", + "6(2)", + "6(3)" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP3" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", @@ -91610,8 +93742,8 @@ "control_id": "DCH-03.2", "title": "Masking Displayed Data", "family": "DCH", - "description": "Mechanisms exist to apply data masking to sensitive/regulated information that is displayed or printed.", - "scf_question": "Does the organization apply data masking to sensitive/regulated information that is displayed or printed?", + "description": "Mechanisms exist to apply data masking to sensitive and/or regulated information that is displayed or printed.", + "scf_question": "Does the organization apply data masking to sensitive and/or regulated information that is displayed or printed?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -91624,9 +93756,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply data masking to sensitive/regulated information that is displayed or printed.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply data masking to sensitive/regulated information that is displayed or printed. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91670,7 +93802,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -91710,6 +93843,9 @@ "usa-state-il-ipa-2009": [ "35(a)(4)", "37(a)(4)" + ], + "americas-arg-ppd-2018": [ + "H.1.1" ] } }, @@ -91731,7 +93867,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically validate cybersecurity and data protection attributes prior to releasing information to external Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -91761,7 +93897,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -91816,9 +93953,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to mark media in accordance with data protection requirements so that personnel are alerted to distribution limitations, handling caveats and applicable security requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to mark media in accordance with data protection requirements so that personnel are alerted to distribution limitations, handling caveats and applicable security requirements. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91867,7 +94004,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92042,13 +94180,13 @@ "emea-deu-c5-2020": [ "AM-06" ], - "emea-isr-cmo-1-0": [ - "15.2" + "emea-sau-ecc-1-2018": [ + "2-1-5" ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.1 [MP.SI.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0201", "ISM-0270", "ISM-0272", @@ -92083,8 +94221,7 @@ "13.2.12.C.04", "13.2.13.C.01", "13.2.14.C.01", - "13.2.14.C.02", - "21.1.21.C.01" + "13.2.14.C.02" ], "americas-can-itsp-10-171-2025": [ "03.08.04" @@ -92109,9 +94246,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically mark physical media and digital files to indicate the distribution limitations, handling requirements and applicable security markings (if any) of the information to aid Data Loss Prevention (DLP) technologies.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically mark physical media and digital files to indicate the distribution limitations, handling requirements and applicable security markings (if any) of the information to aid Data Loss Prevention (DLP) technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92171,7 +94308,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92238,8 +94376,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-03" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0271" + ], + "apac-nzl-ism-3-9": [ + "15.2.39.C.02", + "15.2.39.C.03" ] } }, @@ -92261,7 +94403,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to bind cybersecurity and data protection attributes to information as it is stored, transmitted and processed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92308,14 +94450,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { "general-csa-iot-2": [ "DAT-01" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1005", @@ -92411,7 +94554,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to dynamically associate cybersecurity and data protection attributes with individuals and objects as information is created, combined, or transformed, in accordance with organization-defined cybersecurity and data protection policies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92458,7 +94601,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92491,7 +94635,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide authorized individuals (or processes acting on behalf of individuals) the capability to define or change the value of associated cybersecurity and data protection attributes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92538,7 +94682,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92568,7 +94713,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain the association and integrity of cybersecurity and data protection attributes to individuals and objects.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92615,7 +94760,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92645,7 +94791,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide the capability to associate cybersecurity and data protection attributes with individuals and objects by authorized individuals (or processes acting on behalf of individuals).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92692,7 +94838,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92722,7 +94869,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to display cybersecurity and data protection attributes in human-readable form on each object that the system transmits to output devices to identify special dissemination, handling or distribution instructions using human-readable, standard naming conventions.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92769,7 +94916,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92799,7 +94947,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to require personnel to associate and maintain the association of cybersecurity and data protection attributes with individuals and objects in accordance with cybersecurity and data protection policies.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92846,7 +94994,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92876,7 +95025,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide a consistent, organizationally agreed upon interpretation of cybersecurity and data protection attributes employed in access enforcement and flow enforcement decisions between distributed system components.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92923,7 +95072,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -92953,7 +95103,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to associate cybersecurity and data protection attributes to information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -93000,7 +95150,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -93030,7 +95181,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to reclassify data as required, due to changing business/technical requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -93077,7 +95228,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -93087,7 +95239,7 @@ "general-nist-800-82-r3": [ "AC-16(09)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0325" ] } @@ -93110,7 +95262,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide authorized individuals the capability to define or change the type and value of cybersecurity and data protection attributes available for association with subjects and objects.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -93157,7 +95309,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -93191,7 +95344,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to audit changes to cybersecurity and data protection attributes and responds to events in accordance with incident response procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -93239,7 +95392,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} @@ -93249,7 +95403,7 @@ "title": "Media Storage", "family": "DCH", "description": "Mechanisms exist to: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures.", - "scf_question": "Does the organization: \n (1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n (2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures?", + "scf_question": "Does the organization: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -93269,7 +95423,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -93343,7 +95497,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -93478,11 +95633,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-04" ], - "emea-isr-cmo-1-0": [ - "15.3" - ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2308" @@ -93499,6 +95653,9 @@ "apac-jpn-ismap": [ "8.3.1.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], "apac-nzl-ism-3-9": [ "8.4.10.C.01", "8.4.11.C.01", @@ -93529,7 +95686,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to physically secure all media that contains sensitive information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -93605,7 +95762,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -93615,6 +95773,10 @@ "general-nist-800-171-r3": [ "03.08.01" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], "general-pci-dss-4-0-1": [ "9.1", "9.4", @@ -93658,6 +95820,9 @@ "apac-jpn-ismap": [ "8.3.1.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], "americas-can-itsp-10-171-2025": [ "03.08.01" ] @@ -93683,9 +95848,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain inventory logs of all sensitive media and conduct sensitive media inventories at least annually.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain inventory logs of all sensitive media and conduct sensitive media inventories at least annually. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93762,7 +95927,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -93798,8 +95964,10 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.1.2e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -93834,15 +96002,12 @@ "emea-gbr-caf-4-0": [ "B3.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0336" ], "apac-ind-sebi-2024": [ "ID.AM.S5" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS03" - ], "americas-can-osfi-b13-2022": [ "2.2.2", "3.1.4" @@ -93857,8 +96022,8 @@ "control_id": "DCH-06.3", "title": "Periodic Scans for Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", - "scf_question": "Does the organization periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations?", + "description": "Mechanisms exist to periodically scan unstructured data sources for sensitive and/or regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", + "scf_question": "Does the organization periodically scan unstructured data sources for sensitive and/or regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations?", "relative_weight": 7, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -93873,9 +96038,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93935,7 +96100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -93957,6 +96123,9 @@ "general-pci-dss-4-0-1": [ "A3.2.5", "A3.2.5.1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4" ] } }, @@ -93964,8 +96133,8 @@ "control_id": "DCH-06.4", "title": "Making Sensitive Data Unreadable In Storage", "family": "DCH", - "description": "Mechanisms exist to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored.", - "scf_question": "Does the organization ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored?", + "description": "Mechanisms exist to ensure sensitive and/or regulated data is rendered human unreadable anywhere sensitive and/or regulated data is stored.", + "scf_question": "Does the organization ensure sensitive and/or regulated data is rendered human unreadable anywhere sensitive and/or regulated data is stored?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -93978,9 +96147,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -94038,7 +96207,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -94048,6 +96218,10 @@ "general-nist-800-171-r3": [ "03.08.01" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], "general-pci-dss-4-0-1": [ "9.4" ], @@ -94077,9 +96251,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the storage of sensitive transaction authentication data after authorization.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the storage of sensitive transaction authentication data after authorization. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -94134,7 +96308,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -94208,7 +96383,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ Data classification and handling criteria govern user behavior for media handling.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect and control digital and non-digital media during transport outside of controlled areas using appropriate security measures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -94294,7 +96469,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -94366,7 +96542,8 @@ ], "general-nist-800-171-r3": [ "03.08.05.a", - "03.08.05.b" + "03.08.05.b", + "03.08.05.c" ], "general-nist-800-171a": [ "3.8.5[a]", @@ -94419,10 +96596,10 @@ "MP-05" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.4", @@ -94459,14 +96636,14 @@ "emea-eu-nis2-annex-2024": [ "12.3.2(c)" ], - "emea-isr-cmo-1-0": [ - "15.7" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" + "emea-deu-c5-2020": [ + "AM-08" ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.4 [MP.SI.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2302", @@ -94489,9 +96666,13 @@ "8.3.3.5", "13.2.2.5" ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-3" + ], "americas-can-itsp-10-171-2025": [ "03.08.05.A", - "03.08.05.B" + "03.08.05.B", + "03.08.05.C" ] } }, @@ -94515,7 +96696,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ Data classification and handling criteria govern user behavior for media handling.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify custodians throughout the transport of digital or non-digital media.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify custodians throughout the transport of digital or non-digital media. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -94599,7 +96780,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -94640,6 +96822,10 @@ "03.08.05.a", "03.08.05.b" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.a[02]", + "A.03.08.05.b" + ], "general-pci-dss-4-0-1": [ "9.4.3" ], @@ -94671,10 +96857,10 @@ "8.2.7" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.4", @@ -94687,18 +96873,15 @@ "§117.15(f)(4)(iii)", "§117.15(f)(4)(iv)" ], - "emea-isr-cmo-1-0": [ - "15.7" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "apac-jpn-ismap": [ "8.3.1.10" ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-3" + ], "americas-can-itsp-10-171-2025": [ "03.08.05.A", "03.08.05.B" @@ -94723,7 +96906,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94783,7 +96966,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -94832,6 +97016,9 @@ "general-nist-800-171-r3": [ "03.08.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.a[02]" + ], "usa-federal-fbi-cjis-6-0": [ "SC-28(1)" ], @@ -94859,6 +97046,11 @@ "emea-eu-nis2-annex-2024": [ "12.3.2(c)" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], "emea-gbr-def-stan-05-138-2024": [ "2302" ], @@ -94896,9 +97088,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of media when it is no longer required, using formal procedures.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of media when it is no longer required, using formal procedures. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -94974,7 +97166,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -95078,6 +97271,9 @@ "general-nist-800-171-r3": [ "03.08.03" ], + "general-nist-800-171a-r3": [ + "A.03.08.03" + ], "general-pci-dss-4-0-1": [ "9.4", "9.4.6" @@ -95158,6 +97354,9 @@ "usa-state-il-pipa-2006": [ "40(b)(2)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(C)(1)" ], @@ -95170,28 +97369,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-deu-c5-2020": [ - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.5 [MP.SI.5]" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0312", "ISM-0315", @@ -95239,8 +97422,8 @@ "13.5.29.C.02", "13.5.30.C.01" ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" + "americas-arg-ppd-2018": [ + "F.1.2-DS-1" ], "americas-can-itsp-10-171-2025": [ "03.08.03" @@ -95268,7 +97451,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to sanitize system media with the strength and integrity commensurate with the classification or sensitivity of the information prior to disposal, release out of organizational control or release for reuse.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -95345,7 +97528,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -95472,8 +97656,15 @@ "3.8.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.07.04.c", "A.03.08.03" ], + "general-nist-800-172-r3": [ + "03.08.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.08.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "9.4.7" ], @@ -95523,10 +97714,10 @@ "155.260(a)(4)(vi)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.F.3.1-1", @@ -95557,18 +97748,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" + "emea-deu-c5-2020": [ + "PI-05" ], "emea-sau-sacs-002-2022": [ - "TPC-19", - "TPC-66" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.6 [MP.INFO.6]" + "VII.A.TPC-19", + "VII.B.TPC-66" ], "emea-gbr-caf-4-0": [ "B3.e" @@ -95588,7 +97773,7 @@ "2313", "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0313", "ISM-0317", @@ -95617,6 +97802,7 @@ "11.2.7.3" ], "apac-nzl-ism-3-9": [ + "12.6.5.C.05", "13.4.9.C.01", "13.4.11.C.01", "13.4.12.C.01", @@ -95627,12 +97813,11 @@ "13.4.13.C.05", "13.4.14.C.01", "13.4.15.C.01", - "12.6.5.C.05", - "13.4.19.C.02", "13.4.16.C.01", "13.4.17.C.01", "13.4.18.C.01", "13.4.19.C.01", + "13.4.19.C.02", "13.4.20.C.01", "13.4.20.C.02", "13.4.20.C.03", @@ -95642,6 +97827,10 @@ "apac-sgp-mas-trm-2021": [ "11.1.7" ], + "americas-arg-ppd-2018": [ + "D.1.2-4", + "F.1.2" + ], "americas-bmu-mba-coc-2020": [ "6.17" ], @@ -95672,9 +97861,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to supervise, track, document and verify system media sanitization and disposal actions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to supervise, track, document and verify system media sanitization and disposal actions. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95745,7 +97934,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -95812,9 +98002,6 @@ "MP-06(1)", "MP-06(1)-SID" ], - "emea-isr-cmo-1-0": [ - "15.8" - ], "emea-gbr-def-stan-05-138-2024": [ "2323" ], @@ -95827,7 +98014,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0316", "ISM-0363", "ISM-0370", @@ -95845,6 +98032,13 @@ "13.5.27.C.03", "13.5.28.C.01", "13.5.28.C.02" + ], + "americas-arg-ppd-2018": [ + "F.1.1", + "F.1.4" + ], + "americas-bmu-mba-coc-2020": [ + "6.17" ] } }, @@ -95866,9 +98060,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to test sanitization equipment and procedures to verify that the intended result is achieved.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to test sanitization equipment and procedures to verify that the intended result is achieved. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95939,7 +98133,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -95973,9 +98168,6 @@ "usa-federal-cms-marse-2-0": [ "MP-6(2)" ], - "emea-isr-cmo-1-0": [ - "15.8" - ], "apac-nzl-ism-3-9": [ "13.4.23.C.01" ] @@ -95999,7 +98191,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the sanitization of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96077,7 +98269,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -96150,9 +98343,6 @@ "general-nist-800-161-r1-level-3": [ "MP-6" ], - "general-scf-dpmp-2025": [ - "5.5" - ], "general-tisax-6-0-3": [ "8.2.6" ], @@ -96201,25 +98391,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-zaf-popia-2013": [ - "16.1" - ], "apac-ind-dpdpa-2023": [ "8(7)(a)" - ], - "americas-arg-ppd-2018": [ - "4.7", - "16.7", - "25.2" - ], - "americas-bra-lgpd-2018": [ - "16" ] } }, @@ -96241,7 +98414,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply nondestructive sanitization techniques to portable storage devices prior to first use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96300,7 +98473,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -96340,7 +98514,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "MP-06(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1600", "ISM-1642" ] @@ -96350,8 +98524,8 @@ "control_id": "DCH-09.5", "title": "Dual Authorization for Sensitive Data Destruction", "family": "DCH", - "description": "Mechanisms exist to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data.", - "scf_question": "Does the organization enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data?", + "description": "Mechanisms exist to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive and/or regulated data.", + "scf_question": "Does the organization enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive and/or regulated data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -96364,7 +98538,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96445,7 +98619,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -96457,6 +98632,14 @@ ], "general-nist-800-82-r3": [ "MP-06(07)" + ], + "general-nist-800-172-r3": [ + "03.08.01E", + "03.08.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.01E", + "A.03.08.02E.ODP[01]" ] } }, @@ -96478,9 +98661,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of types of digital media on systems or system components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of types of digital media on systems or system components. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96539,7 +98722,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -96561,7 +98745,7 @@ "general-iso-27018-2025": [ "7.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1025", "T1052", "T1052.001", @@ -96652,7 +98836,12 @@ "MP-07" ], "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "5-1-3-5" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2310" @@ -96666,7 +98855,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2310" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0341", "ISM-0343" ], @@ -96682,8 +98871,8 @@ "control_id": "DCH-10.1", "title": "Limitations on Use", "family": "DCH", - "description": "Mechanisms exist to restrict the use and distribution of sensitive/regulated data.", - "scf_question": "Does the organization restrict the use and distribution of sensitive/regulated data?", + "description": "Mechanisms exist to restrict the use and distribution of sensitive and/or regulated data.", + "scf_question": "Does the organization restrict the use and distribution of sensitive and/or regulated data?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -96698,9 +98887,9 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ Limited media handling guidance exists for users.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use and distribution of sensitive/regulated data.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use and distribution of sensitive/regulated data. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -96753,7 +98942,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -96766,7 +98956,12 @@ "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(2)" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "apac-aus-ism-2026-march": [ "ISM-0343" ], "apac-nzl-ism-3-9": [ @@ -96792,7 +98987,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the use of portable storage devices in organizational systems when such devices have no identifiable owner.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96852,7 +99047,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -96955,11 +99151,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to reclassify data, including associated Technology Assets, Applications and/or Services (TAAS), commensurate with the security category and/or classification level of the information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -97020,7 +99216,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -97038,7 +99235,10 @@ "MP-08", "MP-08(03)" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "SIM-02" + ], + "apac-aus-ism-2026-march": [ "ISM-0325", "ISM-0330" ], @@ -97066,7 +99266,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict removable media in accordance with data handling and acceptable usage parameters.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -97135,7 +99335,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -97168,6 +99369,9 @@ "general-nist-800-171-r3": [ "03.08.07.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.07.a" + ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.V" ], @@ -97179,11 +99383,13 @@ "12.3.2(a)", "12.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "12.24" + "emea-sau-otcc-1-2022": [ + "2-3-1-9" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2310" @@ -97197,17 +99403,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2310" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1359", "ISM-1713" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HML14" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP12" ], @@ -97240,11 +99443,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern how external parties, including Technology Assets, Applications and/or Services (TAAS), are used to securely store, process and transmit data.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern how external parties, including Technology Assets, Applications and/or Services (TAAS), are used to securely store, process and transmit data. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -97328,7 +99531,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -97350,7 +99554,7 @@ "general-govramp-high": [ "AC-20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1021", "T1021.001", @@ -97478,7 +99682,8 @@ "A.03.01.20.a", "A.03.01.20.b", "A.03.01.20.c.01", - "A.03.01.20.c.02" + "A.03.01.20.c.02", + "A.03.01.20.d" ], "usa-federal-fbi-cjis-6-0": [ "AC-20" @@ -97534,11 +99739,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-20" ], - "emea-isr-cmo-1-0": [ - "11.6" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-36" ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" + "emea-esp-decree-311-2022": [ + "Article 22(1)" ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", @@ -97567,7 +99772,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit external parties, including Technology Assets, Applications and/or Services (TAAS), from storing, processing and transmitting data unless authorized individuals first: \n(1) Verifying the implementation of required security, compliance and/or resilience controls; or\n(2) Retaining a processing agreement with the entity hosting the external TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -97635,9 +99840,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Classification & Handling", "crosswalks": { "general-cis-csc-8-1": [ @@ -97701,6 +99906,13 @@ "03.01.20.c.02", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.01.20.d" + ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -97745,9 +99957,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-20 (01)" ], - "emea-srb-act-9-2018": [ - "5.1" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.B", @@ -97775,9 +99984,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict or prohibit the use of portable storage devices by users on external systems.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict or prohibit the use of portable storage devices by users on external systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -97860,7 +100069,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -97920,6 +100130,7 @@ "3.1.21[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", "A.03.01.20.d" ], "usa-federal-fbi-cjis-6-0": [ @@ -97935,10 +100146,10 @@ "AC-20(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "AC-20(CE-2)", @@ -97949,13 +100160,15 @@ "AC-20(2)-IS.a" ], "emea-sau-ecc-1-2018": [ + "2-3-3-2", "5-1-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8", - "2-3-1-9" + "emea-esp-decree-311-2022": [ + "Article 22(1)" ], "apac-nzl-ism-3-9": [ + "11.8.11.C.01", + "11.8.11.C-02", "13.3.7.C.01", "13.3.7.C.02", "13.3.8.C.01", @@ -97964,6 +100177,9 @@ "13.3.9.C.02", "13.3.10.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.D" @@ -97974,8 +100190,8 @@ "control_id": "DCH-13.3", "title": "Protecting Sensitive / Regulated Data on External Technology Assets, Applications and/or Services (TAAS)", "family": "DCH", - "description": "Mechanisms exist to ensure that the requirements for the protection of sensitive/regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization ensure that the requirements for the protection of sensitive/regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to ensure that the requirements for the protection of sensitive and/or regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization ensure that the requirements for the protection of sensitive and/or regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations?", "relative_weight": 10, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -98073,7 +100289,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -98108,13 +100325,14 @@ "03.01.20.b", "03.01.20.c.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.01" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", "03.01.20.C.01" @@ -98139,7 +100357,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of non-organizationally owned Technology Assets, Applications and/or Services (TAAS) to process, store or transmit organizational information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -98223,7 +100441,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -98250,6 +100469,18 @@ "03.01.20.c.01", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.c.01", + "A.03.01.20.d" + ], + "general-nist-800-172-r3": [ + "03.01.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.02E", + "A.03.01.02E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -98284,11 +100515,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a process to assist users in making information sharing decisions to ensure data is appropriately protected.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -98353,7 +100584,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -98397,7 +100629,7 @@ "general-iso-27018-2025": [ "5.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1213", "T1213.001", "T1213.002", @@ -98431,6 +100663,9 @@ "general-nist-800-171-r3": [ "03.01.20.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b" + ], "general-swift-cscf-2025": [ "2.1", "2.4", @@ -98464,14 +100699,13 @@ "usa-state-ca-ccpa-cpra-2026": [ "7153(a)" ], - "emea-isr-cmo-1-0": [ - "5.4", - "10.5" + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" ], - "emea-zaf-popia-2013": [ - "72" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0657", "ISM-0661", "ISM-0663", @@ -98486,36 +100720,6 @@ "13.2.1.5", "13.2.1.9" ], - "apac-nzl-ism-3-9": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B" ] @@ -98539,7 +100743,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications and/or Services (TAAS) implement data search and retrieval functions that properly enforce data protection / sharing restrictions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -98612,7 +100816,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -98645,7 +100850,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to verify that individuals or Technology Assets, Applications and/or Services (TAAS) transferring data between interconnecting TAAS have the requisite authorizations (e.g., write permissions or privileges) prior to transferring said data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -98713,7 +100918,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -98749,6 +100955,11 @@ "03.01.20.c.02", "03.12.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -98763,23 +100974,12 @@ "usa-federal-irs-1075-2021": [ "2.E.6.2" ], - "emea-ken-pda-2019": [ - "25(h)" + "emea-deu-c5-2020": [ + "AM-08" ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], - "emea-srb-act-9-2018": [ - "64", - "64.1", - "64.2", - "64.3", - "64.4" - ], - "apac-nzl-ism-3-9": [ - "20.1.8.C.01", - "20.2.4.C.01" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", "03.01.20.C.02", @@ -98791,8 +100991,8 @@ "control_id": "DCH-14.3", "title": "Data Access Mapping", "family": "DCH", - "description": "Mechanisms exist to leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive/regulated data is shared.", - "scf_question": "Does the organization leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive/regulated data is shared?", + "description": "Mechanisms exist to leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive and/or regulated data is shared.", + "scf_question": "Does the organization leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive and/or regulated data is shared?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -98874,7 +101074,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -98898,6 +101099,11 @@ "03.01.20.c.02", "03.12.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DA.DAUTE" ], @@ -99004,7 +101210,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -99066,8 +101273,7 @@ ], "general-nist-800-171a-r3": [ "A.03.01.22.a", - "A.03.01.22.b[01]", - "A.03.01.22.b[02]" + "A.03.01.22.b[01]" ], "general-pci-dss-4-0-1": [ "1.4.4" @@ -99166,7 +101372,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect data storage objects against unauthorized data mining and data harvesting techniques.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect data storage objects against unauthorized data mining and data harvesting techniques. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99223,11 +101429,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -99303,18 +101510,6 @@ ], "usa-federal-irs-1075-2021": [ "AC-23" - ], - "apac-nzl-ism-3-9": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" ] } }, @@ -99340,7 +101535,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to secure ad-hoc exchanges of large digital files with internal or external parties.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -99408,7 +101603,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -99440,6 +101636,9 @@ "general-nist-800-171-r3": [ "03.01.20.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a" + ], "usa-federal-dow-cmmc-2-level-1": [ "AC.L1-B.1.III" ], @@ -99452,32 +101651,21 @@ "usa-federal-irs-1075-2021": [ "2.E.2" ], - "emea-isr-cmo-1-0": [ - "5.1", - "5.4", - "10.5" - ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], - "apac-aus-ism-2024-june": [ + "emea-sau-otcc-1-2022": [ + "2-6-1-4" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" + ], + "apac-aus-ism-2026-march": [ "ISM-0347", "ISM-0947", "ISM-1778", "ISM-1779" ], - "apac-nzl-ism-3-9": [ - "20.1.11.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A" ] @@ -99505,7 +101693,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ A manual data retention process exists.\n▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99591,7 +101779,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -99656,7 +101845,7 @@ "5.33", "8.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1020.001", @@ -99752,14 +101941,25 @@ ], "general-nist-800-171-r3": [ "03.01.20.c.02", + "03.10.07.b", "03.14.08" ], "general-nist-800-171a-r3": [ + "A.03.01.20.c.02", + "A.03.10.07.b", "A.03.14.08[01]", "A.03.14.08[02]", "A.03.14.08[03]", "A.03.14.08[04]" ], + "general-nist-800-172-r3": [ + "03.04.06E", + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.06E", + "A.03.10.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "3.2", "3.2.1", @@ -99810,9 +102010,6 @@ "3.2.1", "9.4.6" ], - "general-scf-dpmp-2025": [ - "5.4" - ], "general-swift-cscf-2025": [ "6.4" ], @@ -99843,15 +102040,19 @@ "MP-07", "SI-12" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(11)", + "101.640" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(6)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.316(b)(2)(i)", - "164.530(j)(2)" + "§ 164.316(b)(2)(i)", + "§ 164.530(j)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.316(b)(2)(i)" + "§ 164.316(b)(2)(i)" ], "usa-federal-irs-1075-2021": [ "MP-7", @@ -99874,6 +102075,9 @@ "usa-state-il-pipa-2006": [ "30" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-nv-regulation-5-2024": [ "5.260.5(b)", "5.260.5(c)" @@ -99910,42 +102114,28 @@ "Article 18.1(e)", "Article 18.3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.8", - "Article 13.7" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module B.9", - "Annex 6 Module C.3.2" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(13)", + "Article 19(6)", + "Article 23(2)" ], "emea-eu-nis2-annex-2024": [ "1.1.1(h)", "4.2.2(f)" ], + "emea-deu-c5-2020": [ + "RB-06" + ], "emea-sau-cscc-1-2019": [ "2-6-1-4", "2-11-2" ], - "emea-srb-act-9-2018": [ - "5.5" - ], - "emea-zaf-popia-2013": [ - "9" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3 & 5" + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-19" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", + "apac-aus-ism-2026-march": [ "ISM-1510" ], - "apac-chn-pipl-2021": [ - "19" - ], "apac-ind-dpdpa-2023": [ "8(7)(a)", "8(8)" @@ -99974,8 +102164,12 @@ "18.1.3.12", "18.1.3.13.PB" ], + "americas-bmu-mba-coc-2020": [ + "5.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.20.C.02", + "03.10.07.B", "03.14.08" ] } @@ -99984,8 +102178,8 @@ "control_id": "DCH-18.1", "title": "Minimize Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", - "scf_question": "Does the organization minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes?", + "description": "Mechanisms exist to minimize sensitive and/or regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", + "scf_question": "Does the organization minimize sensitive and/or regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -100002,7 +102196,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -100065,7 +102259,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -100087,10 +102282,6 @@ "general-nist-800-82-r3": [ "SI-12(01)" ], - "general-scf-dpmp-2025": [ - "3.3", - "5.4" - ], "general-shared-assessments-sig-2025": [ "P.6" ], @@ -100110,19 +102301,22 @@ "SI-12(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(b)(1)" + "§ 164.502(b)(1)" ], "emea-sau-pdpl-2023": [ "Article 11.3" ], - "emea-zaf-popia-2013": [ - "19" + "emea-che-fadp-2025": [ + "2.1.7.3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.2" + "apac-aus-ism-2026-march": [ + "ISM-2021" ], - "emea-esp-decree-311-2022": [ - "24.2" + "apac-kor-pipa-2011": [ + "III.1.16(1)" + ], + "americas-mex-fdpa-2010": [ + "II.13" ] } }, @@ -100130,8 +102324,8 @@ "control_id": "DCH-18.2", "title": "Limit Sensitive / Regulated Data In Testing, Training & Research", "family": "DCH", - "description": "Mechanisms exist to minimize the use of sensitive/regulated data for research, testing, or training, in accordance with authorized, legitimate business practices.", - "scf_question": "Does the organization minimize the use of Personal Data (PD) for research, testing, or training, in accordance with the Data Protection Impact Assessment (DPIA)?", + "description": "Mechanisms exist to minimize the use of sensitive and/or regulated data for research, testing, or training, in accordance with authorized, legitimate business practices.", + "scf_question": "Does the organization minimize the use of sensitive and/or regulated data for research, testing, or training, in accordance with authorized, legitimate business practices?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -100212,7 +102406,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -100248,9 +102443,6 @@ "general-nist-800-161-r1-level-2": [ "PM-25" ], - "general-scf-dpmp-2025": [ - "3.2" - ], "usa-federal-fbi-cjis-6-0": [ "SI-12(2)" ], @@ -100289,15 +102481,6 @@ ], "emea-eu-nis2-annex-2024": [ "6.2.2(f)" - ], - "emea-srb-act-9-2018": [ - "5.1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-chn-pipl-2021": [ - "6" ] } }, @@ -100323,7 +102506,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform periodic checks of temporary files for the existence of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -100384,7 +102567,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} @@ -100409,11 +102593,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to inventory, document and maintain data flows for data that is resident (permanently or temporarily) within a service's geographically distributed applications (physical and virtual), infrastructure, systems components and/or shared with other third-parties.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -100496,7 +102680,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -100545,6 +102730,11 @@ "03.04.11.a", "03.04.11.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], "general-nist-csf-2-0": [ "ID.AM-03" ], @@ -100574,32 +102764,13 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-09 (05)" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], - "emea-ken-pda-2019": [ - "25(h)" - ], - "emea-qat-pdppl-2020": [ - "15" - ], - "emea-sau-sacs-002-2022": [ - "TPC-30" + "emea-deu-c5-2020": [ + "UP-02", + "RB-03" ], "emea-gbr-caf-4-0": [ "B3.a" ], - "apac-aus-privacy-principles-2026": [ - "APP 8" - ], - "apac-chn-pipl-2021": [ - "38", - "39", - "40" - ], - "apac-jpn-ppi-2020": [ - "24(1)" - ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" @@ -100628,9 +102799,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect archived data in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect archived data in accordance with applicable statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100687,7 +102858,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} @@ -100710,7 +102882,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of, destroy or erase information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100796,7 +102968,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -100849,8 +103022,8 @@ "general-nist-800-171-r3": [ "03.08.03" ], - "general-scf-dpmp-2025": [ - "5.5" + "general-nist-800-171a-r3": [ + "A.03.08.03" ], "usa-federal-fbi-cjis-6-0": [ "SI-12(3)" @@ -100898,31 +103071,18 @@ "40(b)(1)", "40(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(C)(1)" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-deu-c5-2020": [ - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "11.12", - "15.4" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311" ], "apac-ind-sebi-2024": [ "PR.AA.S13" ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" - ], "americas-can-itsp-10-171-2025": [ "03.08.03" ] @@ -100933,7 +103093,7 @@ "title": "Data Quality Operations", "family": "DCH", "description": "Mechanisms exist to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", - "scf_question": "Does the organization check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", + "scf_question": "Does the organization check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -100946,11 +103106,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -101004,7 +103164,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -101103,16 +103264,6 @@ "emea-eu-ai-act-2024": [ "Article 10.3", "Article 17.1(f)" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 1" - ], - "apac-chn-pipl-2021": [ - "8" - ], - "apac-sgp-mas-trm-2021": [ - "5.8.1", - "5.8.2" ] } }, @@ -101134,7 +103285,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize technical controls to correct Personal Data (PD) that is inaccurate or outdated, incorrectly determined regarding impact, or incorrectly de-identified.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101204,7 +103355,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -101230,11 +103382,6 @@ "SI-18(04)", "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "5.15", - "6.1", - "6.2" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-18(04)", "SI-18(05)" @@ -101255,8 +103402,8 @@ "155.260(a)(3)(vi)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)" ], "usa-federal-cms-marse-2-0": [ "IP-3" @@ -101267,132 +103414,21 @@ "usa-state-va-cdpa-2023": [ "59.1-577.A.2" ], - "emea-aut-fappd-2000": [ - "Sec 27" - ], - "emea-bel-act-8-1992": [ - "10", - "12" - ], - "emea-deu-fdpa-2017": [ - "Sec 20" - ], - "emea-grc-pirppd-1997": [ - "13" - ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "14" - ], - "emea-ita-pdpc-2003": [ - "7" - ], - "emea-nor-pda-2018": [ - "27" - ], - "emea-pol-act-29-1997": [ - "32" - ], - "emea-rus-federal-law-27-2006": [ - "17" - ], "emea-sau-pdpl-2023": [ "Article 17.1" ], - "emea-zaf-popia-2013": [ - "24" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" - ], - "emea-che-fadp-2025": [ - "5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" - ], - "apac-aus-privacy-principles-2026": [ - "APP 13" - ], - "apac-chn-csnip-2012": [ - "8" - ], - "apac-chn-pipl-2021": [ - "46", - "49" - ], - "apac-hkg-pdo-2022": [ - "Sec 22" - ], - "apac-jpn-ppi-2020": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" - ], - "apac-mys-pdpa-2010": [ - "34" + "apac-jpn-appi-2020": [ + "IV.1.29(3)" ], "apac-nzl-privacy-act-2020": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" - ], - "apac-phl-dpa-2012": [ - "34" + "3.1.22.7(4)" ], "apac-sgp-pdpa-2012": [ - "22" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "16.1", - "16.3" - ], - "americas-bhs-dpa-2003": [ - "10" - ], - "americas-bra-lgpd-2018": [ - "18.3" - ], - "americas-can-pipeda-2000": [ - "Principle 10" - ], - "americas-chl-act-19628-1999": [ - "13" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "5.22(2)(a)" ], "americas-mex-fdpa-2010": [ - "24", - "28", - "29" + "III.24", + "IV.28" ] } }, @@ -101400,8 +103436,8 @@ "control_id": "DCH-22.2", "title": "Data Tags", "family": "DCH", - "description": "Mechanisms exist to utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle.", - "scf_question": "Does the organization utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle?", + "description": "Mechanisms exist to utilize data tags to automate tracking of sensitive and/or regulated data across the information lifecycle.", + "scf_question": "Does the organization utilize data tags to automate tracking of sensitive and/or regulated data across the information lifecycle?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -101414,11 +103450,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -101473,7 +103509,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -101528,9 +103565,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to collect Personal Data (PD) directly from the individual.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to collect Personal Data (PD) directly from the individual. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -101576,7 +103613,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -101608,9 +103646,6 @@ ], "emea-sau-pdpl-2023": [ "Article 10" - ], - "apac-jpn-ppi-2020": [ - "17(1)" ] } }, @@ -101632,7 +103667,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to anonymize data by removing Personal Data (PD) from datasets.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101683,7 +103718,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -101720,9 +103756,6 @@ "general-nist-800-82-r3": [ "SI-19" ], - "general-scf-dpmp-2025": [ - "5.1" - ], "usa-federal-doc-data-privacy-framework-2023": [ "III.14.a.i", "III.14.g.i" @@ -101748,32 +103781,29 @@ "emea-eu-ai-act-2024": [ "Article 10.5(b)" ], + "emea-bel-act-30-2018": [ + "Title 4, Chapter III, Section 3, Art. 198", + "Title 4, Chapter III, Section 3, Art. 199", + "Title 4, Chapter III, Section 3, Art. 200", + "Title 4, Chapter III, Section 3, Art. 201" + ], + "emea-deu-fdpa-2017": [ + "3.4.64(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.11.12(2)" + ], "emea-ken-pda-2019": [ - "39(2)" + "IV.39(2)" + ], + "emea-rus-152-fz-2025": [ + "Art. 13.1" ], "emea-srb-act-9-2018": [ - "50.1" - ], - "apac-jpn-ppi-2020": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" + "IV.2.50(1)" ], - "americas-bra-lgpd-2018": [ - "12" + "americas-arg-ppd-2018": [ + "H.1.1" ] } }, @@ -101795,7 +103825,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to de-identify the dataset upon collection by not collecting Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101844,7 +103874,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -101889,7 +103920,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to refrain from archiving Personal Data (PD) elements if those elements in a dataset will not be needed after the dataset is archived.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101938,7 +103969,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -101968,7 +104000,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to remove Personal Data (PD) elements from a dataset prior to its release if those elements in the dataset do not need to be part of the data release.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102019,7 +104051,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102049,7 +104082,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to remove, mask, encrypt, hash or replace direct identifiers in a dataset.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102099,7 +104132,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102156,7 +104190,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to manipulate numerical data, contingency tables and statistical findings so that no person or organization is identifiable in the results of the analysis.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102195,7 +104229,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102225,7 +104260,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prevent disclosure of Personal Data (PD) by adding non-deterministic noise to the results of mathematical operations before the results are reported.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102264,7 +104299,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102283,8 +104319,8 @@ "control_id": "DCH-23.7", "title": "Automated De-Identification of Sensitive Data", "family": "DCH", - "description": "Mechanisms exist to perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms.", - "scf_question": "Does the organization perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms?", + "description": "Mechanisms exist to perform de-identification of sensitive and/or regulated data, using validated algorithms and software to implement the algorithms.", + "scf_question": "Does the organization perform de-identification of sensitive and/or regulated data, using validated algorithms and software to implement the algorithms?", "relative_weight": 1, "conformity_cadence": "Annual", "evidence_requests": [], @@ -102297,7 +104333,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102335,7 +104371,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102365,7 +104402,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform a motivated intruder test on the de-identified dataset to determine if the identified data remains or if the de-identified data can be re-identified.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102404,7 +104441,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102423,8 +104461,8 @@ "control_id": "DCH-23.9", "title": "Code Names", "family": "DCH", - "description": "Mechanisms exist to use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data.", - "scf_question": "Does the organization use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data?", + "description": "Mechanisms exist to use aliases to name assets, which are mission-critical and/or contain highly-sensitive and/or regulated data, are unique and not readily associated with a product, project or type of data.", + "scf_question": "Does the organization use aliases to name assets, which are mission-critical and/or contain highly-sensitive and/or regulated data, are unique and not readily associated with a product, project or type of data?", "relative_weight": 1, "conformity_cadence": "Annual", "evidence_requests": [], @@ -102437,7 +104475,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102476,7 +104514,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102505,11 +104544,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify and document the location of information and the specific system components on which the information resides.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -102572,14 +104611,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF9" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025" ], @@ -102607,15 +104647,15 @@ "general-nist-800-161-r1-level-3": [ "CM-12" ], + "general-nist-800-171-r3": [ + "03.04.11.a" + ], "general-nist-800-171a-r3": [ "A.03.04.11.a[01]" ], "general-nist-800-207": [ "NIST Tenet 1" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "usa-federal-fbi-cjis-6-0": [ "CM-12" ], @@ -102632,68 +104672,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-12" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" + "americas-can-itsp-10-171-2025": [ + "03.04.11.A" ] } }, @@ -102702,7 +104682,7 @@ "title": "Automated Tools to Support Information Location", "family": "DCH", "description": "Automated mechanisms exist to identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection.", - "scf_question": "Does the organization identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection?", + "scf_question": "Does the organization use automated mechanisms to identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection?", "relative_weight": 6, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -102719,7 +104699,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -102776,9 +104756,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Classification & Handling", "crosswalks": { "general-nist-800-53-r5-2": [ @@ -102817,63 +104797,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "CM-12(01)" - ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } }, @@ -102895,11 +104818,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict and govern the transfer of sensitive and/or regulated data to third-countries or international organizations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -102962,7 +104885,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102979,9 +104903,6 @@ "general-nist-800-207": [ "NIST Tenet 4" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-swift-cscf-2025": [ "2.4", "2.5A", @@ -103006,113 +104927,17 @@ "Article 49.4", "Article 49.6" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-isr-cmo-1-0": [ - "10.5" - ], "emea-ken-pda-2019": [ - "25(h)", - "48(a)", - "48(b)", - "48(c)(i)", - "48(c)(ii)", - "48(c)(iii)", - "48(c)(iv)", - "48(c)(v)", - "48(c)(vi)", - "49(1)", - "49(2)", - "49(3)", - "50" + "IV.25(h)" ], "emea-nga-dpr-2019": [ - "2.11", - "2.11(a)", - "2.11(b)", - "2.11(c)", - "2.11(d)", - "2.11(e)", - "2.12", - "2.12(a)", - "2.12(b)", - "2.12(c)", - "2.12(d)", - "2.12(e)", - "2.12(f)" - ], - "emea-qat-pdppl-2020": [ - "15" + "2.11" ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], "emea-sau-pdpl-2023": [ "Article 29.1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-30" - ], - "emea-srb-act-9-2018": [ - "23", - "63", - "63.1", - "63.2", - "63.3", - "63.4", - "65", - "68", - "69", - "69.x", - "70", - "70.1", - "70.2", - "70.3", - "70.4", - "70.5", - "71", - "71.1", - "71.2", - "71.3", - "71.4", - "71.5" - ], - "emea-zaf-popia-2013": [ - "72" - ], - "apac-jpn-ppi-2020": [ - "24(1)" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "26", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-col-law-1581-2012": [ - "26" ] } }, @@ -103134,7 +104959,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to establish organization-defined \"normal business activities\" to identify anomalous transaction activities that can reduce the opportunity for sending (outbound) and/or receiving (inbound) fraudulent actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103180,7 +105005,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -103213,7 +105039,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to constrain the impact of \"digital sovereignty laws,\" that require localized data within the host country, where data and processes may be subjected to arbitrary enforcement actions that potentially violate other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103280,23 +105106,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { - "emea-ken-pda-2019": [ - "50" + "emea-sau-cscc-1-2019": [ + "4-2-1-1" + ], + "emea-sau-ecc-1-2018": [ + "4-1-3-2", + "4-2-3-3" ], "apac-chn-cybersecurity-law-2017": [ "Article 37" ], - "apac-chn-data-security-law-2021": [ - "36" - ], "apac-chn-pipl-2021": [ - "36", - "38", - "40" + "Article 40" ], "apac-ind-sebi-2024": [ "PR.DS.S2" @@ -103408,7 +105234,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -103453,7 +105280,7 @@ "0": "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.", "1": "Embedded Technology (EMB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with EMB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Embedded technology management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Embedded technologies (e.g., Operational Technology (OT) and Internet of Things (IoT) are managed in the same manner as any other technology asset.", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.", - "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to facilitate the implementation of embedded technology controls.", + "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to facilitate the implementation of embedded technology controls. ", "4": "Embedded Technology (EMB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -103547,7 +105374,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -103567,9 +105395,6 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-shared-assessments-sig-2025": [ "M.1.1" ], @@ -103582,18 +105407,6 @@ "usa-federal-dow-zt-roadmap-1-1": [ "2.4.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "12.1", - "12.2", - "12.3" - ], "emea-sau-cgiot-2024": [ "1-1-1", "1-1-2", @@ -103603,24 +105416,17 @@ "emea-sau-ecc-1-2018": [ "5-1-1", "5-1-2", - "5-1-3", + "5-1-3-1", + "5-1-3-2", "5-1-4" ], "emea-sau-otcc-1-2022": [ - "1-1-2", - "1-6", - "2-1-2", - "2-3-2" - ], - "emea-zaf-popia-2013": [ - "19" + "1-4-1" ], "apac-sgp-mas-trm-2021": [ "11.5.1", "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" + "11.5.3" ] } }, @@ -103729,30 +105535,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Embedded Technology", "crosswalks": { "emea-sau-cgiot-2024": [ "2-5-1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 11", - "Principle 13" - ], - "apac-chn-pipl-2021": [ - "26" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.1", - "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" ] } }, @@ -103861,13 +105650,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Embedded Technology", "crosswalks": { - "emea-zaf-popia-2013": [ - "19" + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(v)" ] } }, @@ -103889,7 +105678,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Special baselines for embedded technologies configurations are created for higher-risk environments.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to protect embedded devices against unauthorized use of the physical factory diagnostic and test interface(s).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103974,7 +105763,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -103992,8 +105782,7 @@ "2-14-1" ], "apac-aus-cop-sitc-2020": [ - "Principle 6", - "Principle 13" + "13" ] } }, @@ -104015,7 +105804,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to generate log entries on embedded devices when configuration changes or attempts to access interfaces are detected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104100,7 +105889,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -104119,15 +105909,11 @@ "emea-sau-cgiot-2024": [ "2-11-2" ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "emea-sau-ecc-1-2018": [ + "5-1-3-3" ], "apac-aus-cop-sitc-2020": [ - "Principle 8", - "Principle 10" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.5" + "8" ] } }, @@ -104149,7 +105935,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to protect embedded devices by preventing the unauthorized installation and execution of software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104236,7 +106022,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -104255,15 +106042,8 @@ "emea-sau-cgiot-2024": [ "2-6-2" ], - "emea-sau-otcc-1-2022": [ - "1-5-2", - "1-5-3", - "1-5-4", - "2-3-1-5", - "2-3-1-6" - ], "apac-aus-cop-sitc-2020": [ - "Principle 6" + "13" ] } }, @@ -104285,7 +106065,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to securely update software and upgrade functionality on embedded devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104372,20 +106152,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "emea-sau-cgiot-2024": [ "2-4-6" ], - "emea-sau-otcc-1-2022": [ - "1-5-4", - "2-2-1-4" - ], "apac-aus-cop-sitc-2020": [ - "Principle 3", - "Principle 12" + "3" ] } }, @@ -104407,7 +106183,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to configure embedded technology to be resilient to data network and power outages.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104492,7 +106268,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -104504,7 +106281,7 @@ "3-1-2" ], "apac-aus-cop-sitc-2020": [ - "Principle 9" + "9" ] } }, @@ -104526,7 +106303,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to automatically monitor the power levels of embedded technologies for decreased or excessive power usage, including battery drainage, to investigate for device tampering.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104588,7 +106365,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -104597,6 +106375,12 @@ ], "emea-sau-cgiot-2024": [ "2-11-2" + ], + "emea-sau-ecc-1-2018": [ + "5-1-3-3" + ], + "apac-aus-cop-sitc-2020": [ + "10" ] } }, @@ -104618,7 +106402,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to perform evaluations of deployed embedded technologies as needed, or at least on an annual basis, to ensure that necessary updates to mitigate the risks associated with legacy embedded technologies are identified and implemented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104673,7 +106457,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -104683,15 +106468,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.5" - ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1", - "1-6-2", - "2-1-2", - "2-3-2", - "2-7-2", - "2-9-2" ] } }, @@ -104713,7 +106489,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to enforce the security of Message Queuing Telemetry Transport (MQTT) traffic.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104760,7 +106536,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -104791,7 +106568,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to require embedded technologies to initiate all communications and drop new, incoming communications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104838,13 +106615,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "general-csa-iot-2": [ "CLS-08", "COM-10" + ], + "apac-aus-cop-sitc-2020": [ + "13" ] } }, @@ -104866,7 +106647,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to restrict embedded technologies to communicate only with authorized peers and service endpoints.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104913,7 +106694,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -104925,26 +106707,8 @@ "general-shared-assessments-sig-2025": [ "M.1.1" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4", - "2-2-1-7", - "2-4-1", - "2-4-1-1", - "2-4-1-2", - "2-4-1-3", - "2-4-1-4", - "2-4-1-5", - "2-4-1-6", - "2-4-1-7", - "2-4-1-8", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13", - "2-4-1-14", - "2-4-1-15", - "2-4-1-16" + "apac-aus-cop-sitc-2020": [ + "13" ] } }, @@ -104966,7 +106730,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to determine if embedded technologies are certified for secure use in the proposed operating environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105024,7 +106788,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -105038,10 +106803,6 @@ "general-ul-2900-2-2-2016": [ "8.3", "9.2" - ], - "emea-sau-otcc-1-2022": [ - "1-5-3-3", - "2-4-1-15" ] } }, @@ -105063,7 +106824,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to evaluate the safety aspects of embedded technologies via a fault tree analysis, or similar method, to determine possible consequences of misuse, misconfiguration and/or failure.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105142,7 +106903,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -105181,7 +106943,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to enforce certificate-based authentication for embedded technologies (e.g., IoT, OT, etc.) and their supporting services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105228,7 +106990,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -105260,7 +107023,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to implement embedded technologies that utilize pre-provisioned cloud trust anchors to support secure bootstrap and Zero Touch Provisioning (ZTP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105307,7 +107070,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -105335,7 +107099,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to ensure embedded technologies utilize a securely configured Real-Time Operating System (RTOS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105382,7 +107146,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -105390,6 +107155,9 @@ "IOT-06", "IOT-07", "IOT-09" + ], + "general-nist-cswp-39": [ + "4.4" ] } }, @@ -105411,7 +107179,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to continuously validate autonomous systems that trigger an automatic state change when safe operation is no longer assured.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105473,16 +107241,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "general-csa-iot-2": [ "SAP-02", "SAP-09" - ], - "emea-sau-otcc-1-2022": [ - "3-1-1-5" ] } }, @@ -105606,7 +107372,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -105617,7 +107384,7 @@ "CC6.7-POF4" ], "general-cis-csc-8-1": [ - "10.0" + "10" ], "general-cobit-2019": [ "DSS05.03", @@ -105698,6 +107465,7 @@ "3.14.2" ], "general-nist-800-171-r3": [ + "03.01.03", "03.14.02.a" ], "general-nist-800-171a": [ @@ -105708,7 +107476,9 @@ "3.4.2[b]" ], "general-nist-800-171a-r3": [ - "A.03.01.03[01]" + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.14.02.a[01]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -105775,10 +107545,10 @@ "MP-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "MP-2" @@ -105799,57 +107569,24 @@ "MP-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(d)" + "3.4.4.36(d)" ], "emea-eu-nis2-annex-2024": [ "6.9.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "15.5" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-2", - "2-5" - ], - "emea-sau-ecc-1-2018": [ - "2-3-4", - "2-4-4" - ], - "emea-sau-otcc-1-2022": [ - "2-5", - "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", - "2-5-1-4", - "2-5-1-5", - "2-5-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-12", - "TPC-22" - ], - "emea-zaf-popia-2013": [ - "19" + "2-3-1-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.1 [MP.EQ.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-caf-4-0": [ "B3.d" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" - ], "emea-gbr-def-stan-05-138-2024": [ "2317", "2411" @@ -105870,33 +107607,14 @@ "5.1.1.15", "12.2.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP34" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP30" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.5" - ], - "apac-sgp-mas-trm-2021": [ - "11.3.1", - "11.3.2", - "11.3.3", - "11.3.4", - "11.3.5", - "11.4.1", - "11.4.2", - "11.4.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.12" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ + "03.01.03", "03.14.02.A" ] } @@ -106012,7 +107730,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -106059,7 +107778,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to protect the confidentiality, integrity, availability and safety of endpoint devices.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -106143,16 +107862,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { "general-cis-csc-8-1": [ - "10.0", + "10", "10.3", "10.4", "10.5", - "11.0" + "11" ], "general-cis-csc-8-1-ig1": [ "10.3" @@ -106285,10 +108005,10 @@ "SC-28" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ "SC-28" @@ -106309,19 +108029,16 @@ "usa-state-vt-act-171-2018": [ "2447(c)(6)" ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "15.5" - ], "emea-sau-cscc-1-2019": [ "2-3-1-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-22" + "emea-esp-decree-311-2022": [ + "Article 23" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -106357,15 +108074,13 @@ "6.2.1.21", "6.2.1.22" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.5" + "apac-sgp-mas-trm-2021": [ + "11.1.3", + "11.1.4", + "11.1.5" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "americas-arg-ppd-2018": [ + "E.1.2-5" ] } }, @@ -106391,7 +108106,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically prohibit software installations without explicitly assigned privileged status.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically prohibit software installations without explicitly assigned privileged status. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -106463,7 +108178,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -106571,12 +108287,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CM-11" - ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" ] } }, @@ -106600,7 +108310,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to generate an alert when new software is detected.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to generate an alert when new software is detected. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -106669,7 +108379,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -106724,6 +108435,9 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], "usa-federal-fbi-cjis-6-0": [ "CM-8(3)" ], @@ -106745,9 +108459,6 @@ ], "usa-federal-cms-marse-2-0": [ "CM-8(3)" - ], - "emea-isr-cmo-1-0": [ - "6.3" ] } }, @@ -106843,7 +108554,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -106967,7 +108679,7 @@ }, "maturity": { "0": "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.", - "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-malware technologies are decentralized but are deployed on all technology assets that can run anti-malware software.", + "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-malware technologies are decentralized but are deployed on all technology assets that can run anti-malware software. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).\n▪ Anti-malware detection tools are configured to automatically update.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize antimalware technologies to detect and eradicate malicious code.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -107043,7 +108755,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -107055,7 +108768,7 @@ "CC6.8-POF4" ], "general-cis-csc-8-1": [ - "10.0", + "10", "10.1", "10.4" ], @@ -107118,7 +108831,7 @@ "general-iso-27018-2025": [ "8.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -107409,6 +109122,7 @@ "A.03.14.02.ODP[01]", "A.03.14.02.a[01]", "A.03.14.02.a[02]", + "A.03.14.02.c.01[01]", "A.03.14.02.c.02" ], "general-nist-csf-2-0": [ @@ -107559,31 +109273,31 @@ "6.9.2" ], "emea-deu-c5-2020": [ - "OPS-04", - "OPS-05" + "RB-05" ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "12.20", - "15.5" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.1" ], "emea-sau-ecc-1-2018": [ "2-3-3-1", - "2-4-3-4", "5-1-3-10" ], "emea-sau-otcc-1-2022": [ + "2-3-1-1", "2-3-1-8" ], "emea-sau-sacs-002-2022": [ - "TPC-12" + "VII.A.TPC-12" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.6 [OP.EXP.6]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.6" + ], + "emea-gbr-cap-1850-2020": [ + "C2" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5", + "5-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "2411", @@ -107601,7 +109315,7 @@ "2411", "2426" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1284", "ISM-1286", "ISM-1288", @@ -107609,7 +109323,8 @@ "ISM-1290", "ISM-1293", "ISM-1417", - "ISM-1608" + "ISM-1608", + "ISM-1969" ], "apac-ind-sebi-2024": [ "PR.IP.S4" @@ -107627,18 +109342,16 @@ "12.2.1.9", "12.2.1.15" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP62", "HML62" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS10" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP54" ], "apac-nzl-ism-3-9": [ - "14.1.9.C.02" + "14.1.9.C.02", + "21.3.10.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.5" @@ -107646,13 +109359,12 @@ "apac-sgp-mas-trm-2021": [ "11.3.3" ], + "americas-arg-ppd-2018": [ + "E.1.2-6" + ], "americas-bmu-mba-coc-2020": [ "6.12" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ "03.14.02.C", "03.14.02.C.01", @@ -107665,7 +109377,7 @@ "title": "Automatic Antimalware Signature Updates", "family": "END", "description": "Automated mechanisms exist to update antimalware technologies, including signature definitions.", - "scf_question": "Does the organization automatically update antimalware technologies, including signature definitions?", + "scf_question": "Does the organization use automated mechanisms to update antimalware technologies, including signature definitions?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -107682,7 +109394,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware detection tools are configured to automatically update.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically update antimalware technologies, including signature definitions.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically update antimalware technologies, including signature definitions. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -107754,7 +109466,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -107959,11 +109672,14 @@ "emea-eu-nis2-annex-2024": [ "6.9.2" ], - "emea-isr-cmo-1-0": [ - "7.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.6" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5-BP1-1" ], "emea-gbr-def-stan-05-138-2024": [ "2426" @@ -108051,7 +109767,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -108180,7 +109897,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -108223,6 +109941,9 @@ "general-nist-800-171-r3": [ "03.14.02.a" ], + "general-nist-800-171a-r3": [ + "A.03.14.02.a[01]" + ], "general-pci-dss-4-0-1": [ "5.3.4" ], @@ -108259,13 +109980,6 @@ "usa-federal-cms-marse-2-0": [ "SI-3(1)" ], - "emea-isr-cmo-1-0": [ - "7.7", - "12.20" - ], - "apac-sgp-mas-trm-2021": [ - "11.3.5" - ], "americas-can-itsp-10-171-2025": [ "03.14.02.A" ] @@ -108363,7 +110077,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -108469,13 +110184,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "SI-03" ], - "emea-isr-cmo-1-0": [ - "7.8" - ], - "emea-sau-ecc-1-2018": [ - "2-4-3-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1284", "ISM-1286", "ISM-1288", @@ -108507,7 +110216,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to test antimalware technologies by introducing a known benign, non-spreading test case into the system and subsequently verifying that both detection of the test case and associated incident reporting occurs.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to test antimalware technologies by introducing a known benign, non-spreading test case into the system and subsequently verifying that both detection of the test case and associated incident reporting occurs. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108574,7 +110283,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -108612,7 +110322,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to perform periodic evaluations evolving malware threats to assess systems that are generally not considered to be commonly affected by malicious software.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to perform periodic evaluations evolving malware threats to assess systems that are generally not considered to be commonly affected by malicious software. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108679,7 +110389,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -108705,9 +110416,6 @@ ], "general-shared-assessments-sig-2025": [ "J.5.1" - ], - "emea-isr-cmo-1-0": [ - "12.20" ] } }, @@ -108731,7 +110439,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure that anti-malware technologies are continuously running in real-time and cannot be disabled or altered by non-privileged users, unless specifically authorized by management on a case-by-case basis for a limited time period.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure that anti-malware technologies are continuously running in real-time and cannot be disabled or altered by non-privileged users, unless specifically authorized by management on a case-by-case basis for a limited time period. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108803,7 +110511,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -108844,6 +110553,7 @@ "3.14.5[c]" ], "general-nist-800-171a-r3": [ + "A.03.14.02.a[01]", "A.03.14.02.c.01[01]", "A.03.14.02.c.01[02]" ], @@ -108899,12 +110609,12 @@ "SI-3(IRS-Defined)-1", "SI-3(IRS-Defined)-2" ], - "emea-isr-cmo-1-0": [ - "7.5", - "12.25" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.1" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP1-2", + "5-BP1-3" ], "emea-gbr-def-stan-05-138-2024": [ "2426" @@ -109015,7 +110725,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -109053,15 +110764,14 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.5.1" ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-22" + ], "emea-gbr-cyber-essentials-requirements-3-3": [ "1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1416" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } }, @@ -109089,7 +110799,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize File Integrity Monitor (FIM), or similar technologies, to detect and report on unauthorized changes to selected files and configuration settings.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -109159,7 +110869,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -109193,7 +110904,7 @@ "general-iec-62443-4-2-2019": [ "CR 3.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1020.001", @@ -109446,6 +111157,15 @@ "general-nist-800-161-r1-level-3": [ "SI-7" ], + "general-nist-800-172-r3": [ + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.01E.a[01]", + "A.03.14.01E.ODP[01]", + "DS-A.03.14.01E.a[02]", + "A.03.14.01E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.CM-09" ], @@ -109505,14 +111225,7 @@ "SI-07" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(e)" - ], - "emea-isr-cmo-1-0": [ - "6.4", - "12.19" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "3.4.4.36(e)" ], "emea-gbr-def-stan-05-138-2024": [ "2425" @@ -109552,7 +111265,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to validate configurations through integrity checking of software and firmware.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -109617,7 +111330,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -109664,6 +111378,18 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(01)" ], + "general-nist-800-172-r3": [ + "03.14.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.08E[01]", + "A.03.14.08E.ODP[02]", + "A.03.14.08E.ODP[04]", + "DS-A.03.14.08E[02]", + "A.03.14.08E.ODP[06]", + "DS-A.03.14.08E[03]", + "A.03.14.08E.ODP[10]" + ], "general-swift-cscf-2025": [ "6.2" ], @@ -109714,7 +111440,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to detect and respond to unauthorized configuration changes as cybersecurity incidents.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -109785,7 +111511,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -109842,6 +111569,12 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(07)" ], + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" + ], "general-pci-dss-4-0-1": [ "10.7", "10.7.1", @@ -109888,9 +111621,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SI-07 (07)" - ], - "emea-isr-cmo-1-0": [ - "7.2" ] } }, @@ -109912,11 +111642,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically alert incident response personnel upon discovering discrepancies during integrity verification.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically alert incident response personnel upon discovering discrepancies during integrity verification. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -109980,7 +111710,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -110031,11 +111762,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions when integrity violations are discovered.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions when integrity violations are discovered. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -110099,7 +111830,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -110150,11 +111882,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically verify the integrity of the boot process of systems.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -110218,7 +111950,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -110242,9 +111975,6 @@ ], "general-sparta": [ "CM0014" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 8" ] } }, @@ -110270,7 +112000,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically protect the integrity of boot firmware in systems.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -110336,7 +112066,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -110357,6 +112088,13 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(10)" ], + "general-nist-800-172-r3": [ + "03.14.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.10E", + "A.03.14.10E.ODP[01]" + ], "general-sparta": [ "CM0014" ], @@ -110364,7 +112102,7 @@ "SI-7(CE-10)" ], "apac-aus-cop-sitc-2020": [ - "Principle 8" + "8" ] } }, @@ -110386,7 +112124,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to prohibit the use of binary or machine-executable code from sources with limited or no warranty and without access to source code.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -110455,7 +112193,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -110569,13 +112308,30 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.7.2", "2.7.3" + ], + "emea-sau-ecc-1-2018": [ + "2-4-3-4" + ], + "emea-sau-otcc-1-2022": [ + "2-3-1-1", + "2-3-1-12" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" ] } }, @@ -110670,7 +112426,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -110701,6 +112458,11 @@ "03.14.06.b", "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" + ], "general-shared-assessments-sig-2025": [ "N.7" ], @@ -110715,17 +112477,7 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.14(b)(1)" ], - "emea-isr-cmo-1-0": [ - "7.4", - "7.5", - "12.18", - "12.24", - "23.6" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1034", "ISM-1341", "ISM-1418" @@ -110733,10 +112485,6 @@ "apac-nzl-ism-3-9": [ "18.4.13.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ "03.14.06.A.01", "03.14.06.A.02", @@ -110839,12 +112587,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.6", "9.7" ], @@ -110867,7 +112616,7 @@ "general-govramp-high": [ "SI-08" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.001", "T1137.002", @@ -110965,7 +112714,7 @@ "2-4-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-16" + "VII.A.TPC-16" ], "emea-gbr-def-stan-05-138-2024": [ "2509" @@ -110980,28 +112729,16 @@ "2509" ], "apac-nzl-ism-3-9": [ - "15.2.21.C.01", - "15.2.23.C.01", - "15.2.23.C.02", - "15.2.23.C.03", - "15.2.24.C.01", - "15.2.24.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.6" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "15.2.37.C.01" ] } }, { "control_id": "END-08.1", - "title": "Central Management", + "title": "Phishing & Spam Protection Centralized Management", "family": "END", - "description": "Mechanisms exist to centrally-manage anti-phishing and spam protection technologies.", - "scf_question": "Does the organization centrally-manage anti-phishing and spam protection technologies?", + "description": "Mechanisms exist to centrally manage anti-phishing and spam protection technologies.", + "scf_question": "Does the organization centrally manage anti-phishing and spam protection technologies?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -111016,7 +112753,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-spam/phishing technologies are centralized and built into existing email capabilities.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-spam/phishing technologies are centralized and built into existing email capabilities.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to centrally-manage anti-phishing and spam protection technologies.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to centrally manage anti-phishing and spam protection technologies.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -111101,8 +112838,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control\n- wordsmithed", "family_name": "Endpoint Security", "crosswalks": { "general-nist-800-53-r4": [ @@ -111140,10 +112879,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "PL-09" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } }, @@ -111234,7 +112969,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -111363,7 +113099,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -111391,8 +113128,8 @@ "general-ul-2900-2-2-2016": [ "8.10(b)" ], - "emea-isr-cmo-1-0": [ - "4.37" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6" ] } }, @@ -111418,7 +113155,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to address mobile code / operating system-independent applications.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to address mobile code / operating system-independent applications. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -111489,7 +113226,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -111529,7 +113267,7 @@ "NDR 2.4(c)", "NDR 2.4(1)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.003", "T1055", "T1055.001", @@ -111639,9 +113377,14 @@ "A.03.13.13.a[01]", "A.03.13.13.a[02]", "A.03.13.13.b[01]", - "A.03.13.13.b[02]", "A.03.13.13.b[03]" ], + "general-nist-800-172-r3": [ + "03.13.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.06E" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.SE.ACMIT", "3.PEP.WE.ACMIT" @@ -111736,7 +113479,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to configure thin nodes to have minimal functionality and information storage.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to configure thin nodes to have minimal functionality and information storage. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -111803,7 +113546,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -111818,6 +113562,12 @@ ], "general-nist-800-160-vol-2-r1": [ "SC-25" + ], + "general-nist-800-172-r3": [ + "03.13.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.11E[01]" ] } }, @@ -111908,11 +113658,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1025", "T1052", "T1052.001", @@ -111937,6 +113688,14 @@ "general-nist-800-82-r3-high": [ "SC-41" ], + "general-nist-800-172-r3": [ + "03.13.13E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.13E", + "A.03.13.13E.ODP[02]", + "A.03.13.13E.ODP[03]" + ], "usa-federal-nerc-cip-2024": [ "CIP-007-6 1.2" ] @@ -112031,7 +113790,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112135,7 +113895,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112148,16 +113909,8 @@ "general-nist-800-82-r3": [ "SC-42(02)" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-shared-assessments-sig-2025": [ "P.2.2.1" - ], - "emea-zaf-popia-2013": [ - "8", - "9", - "13.1" ] } }, @@ -112234,7 +113987,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112244,14 +113998,11 @@ "general-nist-800-82-r3": [ "SC-42(04)" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-tisax-6-0-3": [ "8.2.6" ], - "emea-zaf-popia-2013": [ - "18" + "emea-aut-dpa-2018": [ + "§ 12(2)" ] } }, @@ -112273,7 +114024,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize sensors that are configured to minimize the collection of information about individuals.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -112328,7 +114079,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112364,9 +114116,6 @@ "general-nist-800-161-r1-level-2": [ "PM-25" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-25", "SA-08(33)" @@ -112386,8 +114135,8 @@ "emea-sau-cgiot-2024": [ "2-6-3" ], - "emea-zaf-popia-2013": [ - "10" + "emea-che-fadp-2025": [ + "2.1.7.3" ] } }, @@ -112478,7 +114227,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112581,7 +114331,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112665,15 +114416,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-15" ], - "emea-isr-cmo-1-0": [ - "5.6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0231" ], - "apac-chn-pipl-2021": [ - "26" - ], "americas-can-itsp-10-171-2025": [ "03.13.12.A" ] @@ -112697,11 +114442,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to disable or remove collaborative computing devices from critical systems and secure work areas.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -112769,7 +114514,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112875,7 +114621,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112964,7 +114711,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -112991,7 +114739,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure the meeting host can positively control an individual's participation in virtual meetings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -113040,7 +114788,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -113103,7 +114852,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -113184,7 +114934,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -113293,10 +115044,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", - "crosswalks": {} + "crosswalks": { + "apac-sgp-mas-trm-2021": [ + "11.4.2" + ] + } }, { "control_id": "END-16", @@ -113386,7 +115142,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -113471,7 +115228,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-03" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1006" ] } @@ -113496,7 +115253,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to implement underlying software separation mechanisms to facilitate security function isolation.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to implement underlying software separation mechanisms to facilitate security function isolation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113562,7 +115319,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -113735,7 +115493,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -113890,7 +115649,18 @@ "A.03.01.01.ODP[01]", "A.03.01.01.ODP[02]", "A.03.01.01.ODP[03]", - "A.03.01.01.ODP[04]" + "A.03.01.01.ODP[04]", + "A.03.01.01.g.02", + "A.03.15.03.a", + "A.03.15.03.d[01]" + ], + "general-nist-800-172-r3": [ + "03.09.03E", + "03.09.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.03E.a", + "A.03.09.04E.ODP[01]" ], "general-nist-800-218": [ "PO.2.1" @@ -113916,9 +115686,6 @@ "12.2.1", "12.7.1" ], - "general-scf-dpmp-2025": [ - "7.9" - ], "general-swift-cscf-2025": [ "5.1", "5.3A" @@ -113998,13 +115765,13 @@ "314.4(e)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)", - "164.530(e)(2)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)", + "§ 164.530(e)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "2.C.3-1", @@ -114035,7 +115802,7 @@ "PS-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.2(15)" + "3.2.1.3" ], "emea-eu-nis2-2022": [ "Article 21.2(i)" @@ -114045,50 +115812,42 @@ "10.1.3", "10.2.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-deu-c5-2020": [ + "HR-02", + "KOS-08-DOAR" ], - "emea-isr-cmo-1-0": [ - "19.1" + "emea-grc-pirppd-1997": [ + "B.10.2" ], "emea-sau-cscc-1-2019": [ - "1-5", - "2-5" + "1-5-1" ], "emea-sau-cgiot-2024": [ "1-3-2", "1-8-1" ], "emea-sau-ecc-1-2018": [ + "1-4-2", "1-9-1", - "1-9-6", - "2-6-4" + "1-9-2", + "1-9-3", + "1-9-4", + "1-9-6" ], "emea-sau-otcc-1-2022": [ - "1-7", - "1-7-2", - "1-8" + "1-7-1", + "1-7-2" ], "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-71" + "VII.B.TPC-26" ], "emea-sau-sama-csf-1-2017": [ - "3.3.1" - ], - "emea-zaf-popia-2013": [ - "19", - "20" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 15.1" + "3.3.1", + "3.3.1.1", + "3.3.1.3" ], "emea-esp-decree-311-2022": [ - "15.1" + "Article 12(6)(c)" ], "emea-uae-niaf-2023": [ "3.2.3" @@ -114127,8 +115886,9 @@ "GV.RR.S6", "RS.CO.S1" ], - "apac-jpn-ppi-2020": [ - "21" + "apac-jpn-appi-2020": [ + "IV.1.21", + "IV.1.22" ], "apac-jpn-ismap": [ "4.5.2.2", @@ -114137,7 +115897,7 @@ "7.1", "7.1.1.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HML02" ], "apac-nzl-hisf-suppliers-2023": [ @@ -114151,14 +115911,10 @@ "15.1.7.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.5.1", - "3.5.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.13" + "3.5.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.5" + "apac-kor-pipa-2011": [ + "III.2.28(1)" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", @@ -114256,7 +116012,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -114288,6 +116045,9 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10(j)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(7)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -114320,6 +116080,14 @@ "1-8-1", "1-8-2" ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-18", + "VII.B.TPC-71" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e.1", + "3.3.1.3.e.2" + ], "emea-uae-niaf-2023": [ "3.2.3" ], @@ -114442,7 +116210,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -114515,10 +116284,19 @@ "03.01.01.d.02", "03.01.02", "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.15.03.b" ], - "general-nist-800-172": [ - "3.9.1e" + "general-nist-800-171a-r3": [ + "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.09.01.a", + "A.03.09.01.b", + "A.03.15.03.b" ], "general-nist-csf-2-0": [ "GV.RR-02", @@ -114569,17 +116347,20 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PS-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(a)" + ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "PS-2" @@ -114605,9 +116386,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PS-02" ], - "emea-eu-eba-ict-srm-2025": [ - "3.3.2(15)" - ], "emea-eu-gdpr-2016": [ "Article 32.4" ], @@ -114615,8 +116393,8 @@ "10.1.2(b)", "10.1.3" ], - "emea-isr-cmo-1-0": [ - "19.1" + "emea-deu-c5-2020": [ + "HR-01-DOAR" ], "emea-sau-cscc-1-2019": [ "1-5-1-2" @@ -114624,17 +116402,11 @@ "emea-sau-cgiot-2024": [ "1-8-1" ], - "emea-sau-ecc-1-2018": [ - "1-9-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2" + "emea-sau-otcc-1-2022": [ + "1-2-1-2" ], "emea-esp-decree-311-2022": [ - "13.2" + "Article 16(3)" ], "apac-ind-sebi-2024": [ "DE.DP.S1", @@ -114647,10 +116419,12 @@ ], "apac-nzl-ism-3-9": [ "9.2.10.C.01", - "9.2.10.C.02", "9.2.11.C.01", "9.2.11.C.02" ], + "apac-sgp-mas-trm-2021": [ + "3.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01", "03.01.01.C.02", @@ -114658,7 +116432,8 @@ "03.01.01.D.02", "03.01.02", "03.09.01.A", - "03.09.01.B" + "03.09.01.B", + "03.15.03.B" ] } }, @@ -114666,8 +116441,8 @@ "control_id": "HRS-02.1", "title": "Users With Elevated Privileges", "family": "HRS", - "description": "Mechanisms exist to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question.", - "scf_question": "Does the organization ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question?", + "description": "Mechanisms exist to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive and/or regulated data is cleared and regularly trained to handle the information in question.", + "scf_question": "Does the organization ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive and/or regulated data is cleared and regularly trained to handle the information in question?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -114686,7 +116461,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates risk for individuals requiring elevated privileges or access to sensitive/regulated data.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -114759,7 +116534,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -114772,8 +116548,9 @@ "general-nist-800-171-r3": [ "03.01.02" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.02[01]", + "A.03.01.02[02]" ], "general-pci-dss-4-0-1": [ "12.7", @@ -114806,10 +116583,6 @@ "emea-eu-nis2-annex-2024": [ "10.1.2(b)" ], - "apac-sgp-mas-trm-2021": [ - "3.5.2", - "6.1.5" - ], "americas-can-itsp-10-171-2025": [ "03.01.02" ] @@ -114901,7 +116674,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -114947,7 +116721,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Formal roles and responsibilities for cybersecurity and/or data protection are not consistent and/or standardized.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define cybersecurity roles & responsibilities for all personnel.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define cybersecurity roles & responsibilities for all personnel. ", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -115016,7 +116790,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -115171,18 +116946,40 @@ ], "general-nist-800-171-r3": [ "03.01.22.a", + "03.02.02.a.01", "03.06.04.a", "03.06.05.d", "03.07.06.a", + "03.07.06.d", "03.08.02", "03.15.03.b", "03.16.03.b" ], "general-nist-800-171a-r3": [ - "A.03.06.05.d" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.05.d", + "A.03.07.06.a", + "A.03.07.06.d[02]", + "A.03.08.02", + "A.03.15.03.b", + "A.03.16.03.b" ], - "general-nist-800-172": [ - "3.9.1e" + "general-nist-800-172-r3": [ + "03.01.08E", + "03.01.11E", + "03.14.17E", + "03.14.18E", + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.08E.ODP[02]", + "A.03.01.11E.ODP[01]", + "A.03.14.17E.ODP[01]", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[01]", + "A.03.17.03E.ODP[03]" ], "general-nist-800-218": [ "PO.2", @@ -115368,19 +117165,23 @@ "PM-13", "PS-09" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)", + "101.625(a)" + ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "PS-9" @@ -115440,8 +117241,9 @@ "PS-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(12)", - "3.3.2(15)" + "3.2.1.2", + "3.3.1.12", + "3.4.1.29" ], "emea-eu-dora-2023": [ "Article 5.2(c)" @@ -115462,63 +117264,53 @@ "10.1.1" ], "emea-deu-c5-2020": [ - "PSS-08" + "UP-01-BP5", + "OIS-03-BP1", + "OIS-03-BP2", + "OIS-03-BP3", + "SA-01-BP3" + ], + "emea-hun-act-cxii-2011": [ + "II.18.24(2)" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B2" ], - "emea-isr-cmo-1-0": [ - "4.13", - "18.10" + "emea-ita-pdpc-2018": [ + "Article 2-o(1)", + "Article 2-o(2)" ], "emea-sau-cgiot-2024": [ "1-3-1", "1-3-2", "1-8-1" ], + "emea-sau-ecc-1-2018": [ + "1-4-1", + "1-4-2", + "1-9-1" + ], "emea-sau-otcc-1-2022": [ - "1-2", "1-2-1", - "1-2-1-1" + "1-2-1-2" ], "emea-sau-pdpl-2023": [ "Article 30.2" ], "emea-sau-sacs-002-2022": [ - "TPC-26" + "VII.B.TPC-26" ], "emea-sau-sama-csf-1-2017": [ - "3.1.4" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.1", - "Article 11.2", - "Article 11.3", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.2(d)", - "Article 13.3", - "Article 13.4", - "Article 13.5" + "3.1.4.6", + "3.1.4.6.a", + "3.3.1.3.a" ], "emea-esp-decree-311-2022": [ - "11.1", - "11.2", - "11.3", - "13.1", - "13.2", - "13.2(a)", - "13.2(b)", - "13.2(c)", - "13.2(d)", - "13.3", - "13.4", - "13.5" + "Article 12(1)(c)", + "Article 13(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "6.4 [ORG.4]", - "8.2.1 [MP.PER.1]", - "8.2.2 [MP.PER.2]" + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "emea-gbr-def-stan-05-138-2024": [ "1102", @@ -115541,7 +117333,7 @@ "2321", "3102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0717", "ISM-0720", "ISM-0724", @@ -115551,13 +117343,12 @@ "ISM-0732", "ISM-0733", "ISM-0734", - "ISM-0735" + "ISM-0735", + "ISM-2035", + "ISM-2036" ], "apac-aus-ps-cps-234-2019": [ - "14" - ], - "apac-chn-data-security-law-2021": [ - "27" + "19" ], "apac-ind-dpdpa-2023": [ "6(9)", @@ -115570,9 +117361,6 @@ "PR.AT.S5", "RS.CO.S1" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "4.5.2.2", "6.1.1", @@ -115585,15 +117373,12 @@ "6.1.1.7", "6.1.1.13.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP02", "HHSP23", "HML02", "HML23" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS01" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP02", "HSUP21" @@ -115632,16 +117417,27 @@ "3.3.14.C.03", "3.3.15.C.01", "3.4.10.C.01", - "3.4.10.C.02" + "3.4.10.C.02", + "17.9.35.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "1.2" + "apac-sgp-mas-trm-2021": [ + "3.5.1" + ], + "americas-arg-ppd-2018": [ + "B.2.2", + "E.1.2-1", + "F.1.3" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", + "03.02.02.A.01", "03.06.04.A", "03.06.05.D", "03.07.06.A", + "03.07.06.D", "03.08.02", "03.15.03.B", "03.16.03.B" @@ -115671,7 +117467,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to communicate with users about their roles and responsibilities to maintain a safe and secure working environment.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115757,7 +117553,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -115800,6 +117597,10 @@ "03.01.22.a", "03.15.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.15.03.b" + ], "general-nist-csf-2-0": [ "GV.RR-04" ], @@ -115878,6 +117679,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(4)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 R2", "CIP-004-7 2.2" @@ -115893,13 +117697,8 @@ "10.1.2(a)", "10.1.2(c)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.1", - "Article 15.1" - ], - "emea-esp-decree-311-2022": [ - "13.1", - "15.1" + "emea-sau-ecc-1-2018": [ + "1-9-4-1" ], "emea-gbr-def-stan-05-138-2024": [ "2600", @@ -115917,7 +117716,7 @@ "2600", "2603" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0824" ], "apac-ind-sebi-2024": [ @@ -115934,6 +117733,9 @@ "7.2.1.4", "8.1.3.1" ], + "americas-arg-ppd-2018": [ + "B.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.15.03.B" @@ -115963,7 +117765,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Formal roles and responsibilities for cybersecurity and/or data protection are not consistent and/or standardized.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that all security-related positions are staffed by qualified individuals who have the necessary skill set.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that all security-related positions are staffed by qualified individuals who have the necessary skill set. ", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -116047,7 +117849,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -116150,6 +117953,9 @@ "general-nist-800-171-r3": [ "03.07.06.d" ], + "general-nist-800-171a-r3": [ + "A.03.07.06.d[01]" + ], "general-nist-800-218": [ "PO.2" ], @@ -116206,6 +118012,21 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PS-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(e)", + "101.625(e)(1)", + "101.625(e)(2)", + "101.625(e)(3)", + "101.625(e)(4)", + "101.625(e)(5)", + "101.625(e)(6)", + "101.625(e)(7)", + "101.625(e)(8)", + "101.625(e)(9)", + "101.625(e)(10)", + "101.625(e)(11)", + "101.625(e)(12)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(2)" ], @@ -116230,23 +118051,14 @@ "usa-state-tx-txramp-2-0-level-2": [ "PS-02" ], - "emea-sau-ecc-1-2018": [ - "1-9-2" + "emea-isr-ppl-5741-2025": [ + "s.17B3" ], "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 15.1", - "Article 16.1", - "Article 16.2", - "Article 16.3" + "VII.B.TPC-26" ], "emea-esp-decree-311-2022": [ - "15.1", - "16.1", - "16.2", - "16.3" + "Article 16(2)" ], "emea-gbr-caf-4-0": [ "C1.e" @@ -116259,6 +118071,9 @@ "14.2.1.8", "14.2.1.11" ], + "apac-mys-bnm-rmit-2025": [ + "9.4" + ], "apac-nzl-ism-3-9": [ "5.1.14.C.01" ], @@ -116266,10 +118081,6 @@ "3.5.1", "6.1.5" ], - "amaericas-can-osfi-self-assessment": [ - "1.5", - "1.7" - ], "americas-can-itsp-10-171-2025": [ "03.07.06.D" ] @@ -116384,7 +118195,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -116478,7 +118290,8 @@ ], "general-nist-800-171-r3": [ "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.09.02.b.01" ], "general-nist-800-171a": [ "3.9.1" @@ -116489,9 +118302,6 @@ "A.03.09.01.b", "A.03.09.02.b.01[01]" ], - "general-nist-800-172": [ - "3.9.1e" - ], "general-pci-dss-4-0-1": [ "12.7", "12.7.1" @@ -116502,9 +118312,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.7.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "5.3A" ], @@ -116536,10 +118343,10 @@ "PS-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "2.C.3", @@ -116583,24 +118390,27 @@ "10.2.2(b)" ], "emea-deu-c5-2020": [ - "HR-01" - ], - "emea-isr-cmo-1-0": [ - "19.2" + "HR-01", + "HR-01-BP1", + "HR-01-BP2", + "HR-01-BP3", + "HR-01-BP4" ], "emea-sau-cscc-1-2019": [ "1-5-1-1" ], "emea-sau-ecc-1-2018": [ - "1-9-3", "1-9-3-2" ], "emea-sau-otcc-1-2022": [ "1-7-1" ], - "emea-zaf-popia-2013": [ - "19", - "20" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.d" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.1", + "mp.per.1" ], "emea-gbr-def-stan-05-138-2024": [ "2700", @@ -116618,7 +118428,7 @@ "2700", "2701" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0434" ], "apac-jpn-ismap": [ @@ -116630,7 +118440,7 @@ "7.1.1.9", "7.1.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP20", "HML20" ], @@ -116643,11 +118453,13 @@ "americas-bmu-mba-coc-2020": [ "5.13" ], - "amaericas-can-osfi-self-assessment": [ - "1.6" + "americas-can-osfi-self-assessment-2": [ + "3.2.7" ], "americas-can-itsp-10-171-2025": [ - "03.09.01.A" + "03.09.01.A", + "03.09.01.B", + "03.09.02.B.01" ] } }, @@ -116672,7 +118484,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that individuals accessing a system that stores, transmits or processes information requiring special protection satisfy organization-defined personnel screening criteria.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -116745,7 +118557,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -116812,10 +118625,11 @@ "03.09.01.b" ], "general-nist-800-171a-r3": [ - "A.03.09.01.ODP[01]" - ], - "general-nist-800-172": [ - "3.9.1e" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.09.01.ODP[01]", + "A.03.09.01.a", + "A.03.09.01.b" ], "general-pci-dss-4-0-1": [ "12.7", @@ -116864,27 +118678,23 @@ ], "emea-deu-c5-2020": [ "HR-01", - "PSS-08" - ], - "emea-isr-cmo-1-0": [ - "19.2" + "HR-01-DOAR" ], "emea-sau-ecc-1-2018": [ "1-9-3-2" ], - "emea-sau-otcc-1-2022": [ - "1-7-1" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.d" ], - "emea-sau-sacs-002-2022": [ - "TPC-26" + "emea-esp-ccn-stic-825-2026": [ + "org.4", + "op.pl.1", + "mp.per.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0446", "ISM-0447" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-jpn-ismap": [ "7.1.1.7", "7.1.1.8" @@ -116892,9 +118702,6 @@ "apac-sgp-mas-trm-2021": [ "3.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "1.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.02.A.01", @@ -116923,7 +118730,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department governs personnel management operations and notifies IT and/or cybersecurity personnel of role changes for logical access provisioning and deprovisioning actions.\n▪ Personnel managers ensure personnel are responsible for educating new hires on the organization's cybersecurity and data protection policies.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to formally educate authorized users on proper data handling practices for all the relevant types of data to which they have access.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -117007,7 +118814,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -117069,6 +118877,13 @@ "03.06.04.a.01", "03.15.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.04.a.01", + "A.03.15.03.b" + ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e", "WORKFORCE-2a" @@ -117081,6 +118896,9 @@ "11.10(i)", "11.10(j)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -117088,25 +118906,13 @@ "500.10(a)(2)" ], "emea-sau-ecc-1-2018": [ - "1-9-4", - "1-9-4-1" - ], - "emea-sau-otcc-1-2022": [ - "1-8" - ], - "emea-sau-sacs-002-2022": [ - "TPC-26", - "TPC-71" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2", - "Article 15.1" + "1-9-4-1", + "1-9-4-2" ], - "emea-esp-decree-311-2022": [ - "13.2", - "15.1" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0435" ], "apac-jpn-ismap": [ @@ -117118,12 +118924,18 @@ "apac-nzl-ism-3-9": [ "9.1.7.C.01" ], + "americas-arg-ppd-2018": [ + "B.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.02.A.01", "03.06.04.A", "03.06.04.A.01", "03.15.03.B" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(d)" ] } }, @@ -117145,7 +118957,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to verify that individuals accessing a system processing, storing, or transmitting sensitive information meet applicable statutory, regulatory and/or contractual requirements for citizenship.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -117213,7 +119025,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -117223,10 +119036,16 @@ "general-nist-800-82-r3": [ "PS-03(04)" ], + "general-nist-800-172-r3": [ + "03.09.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.04E" + ], "emea-sau-cscc-1-2019": [ "1-5-1-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0409", "ISM-0411", "ISM-0420", @@ -117236,7 +119055,6 @@ ], "apac-nzl-ism-3-9": [ "9.2.10.C.01", - "9.2.10.C.02", "9.2.11.C.01", "9.2.11.C.02", "9.2.15.C.01", @@ -117263,7 +119081,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to identify foreign nationals, including by their specific citizenship.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -117331,11 +119149,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0420" ], "apac-nzl-ism-3-9": [ @@ -117456,9 +119275,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -117563,9 +119382,13 @@ "general-nist-800-171-r3": [ "03.01.01.h", "03.01.22.a", - "03.15.03.a" + "03.15.03.a", + "03.15.03.b" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", + "A.03.01.22.a", + "A.03.15.03.a", "A.03.15.03.b" ], "general-nist-csf-2-0": [ @@ -117641,10 +119464,10 @@ "155.260(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "PL-4" @@ -117668,37 +119491,35 @@ "1.2.2", "10.3.2" ], + "emea-deu-fdpa-2017": [ + "3.2.48(2)8" + ], "emea-deu-c5-2020": [ "HR-02", - "HR-03", - "AM-05" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "19.3", - "19.4" - ], - "emea-sau-cscc-1-2019": [ - "2-5" + "HR-05", + "AM-04" ], "emea-sau-ecc-1-2018": [ - "1-9-3-1", - "1-9-3-2", - "1-9-4-2" + "1-9-1", + "1-9-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.2", - "Article 11.3" + "VII.A.TPC-1" ], "emea-esp-decree-311-2022": [ - "11.2", - "11.3" + "Article 12(6)(d)", + "Article 13(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.2 [MP.PER.2]" + "emea-che-fadp-2025": [ + "5.30.1", + "5.30.2", + "5.30.2.a", + "5.30.2.b", + "5.30.2.c", + "5.30.3" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -117712,10 +119533,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0258", "ISM-0824", - "ISM-1146" + "ISM-1146", + "ISM-1865" ], "apac-jpn-ismap": [ "7.1.2", @@ -117743,12 +119565,18 @@ "9.3.7.C.04", "9.3.8.C.01", "9.3.8.C.02", - "9.3.8.C.03" + "9.3.8.C.03", + "21.1.6.C.02", + "21.2.3.C.01" + ], + "americas-bhs-dpa-2003": [ + "II.4(2)" ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", "03.01.22.A", - "03.15.03.A" + "03.15.03.A", + "03.15.03.B" ] } }, @@ -117860,7 +119688,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -117989,6 +119818,8 @@ "03.15.03.d" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.22.a", "A.03.15.03.ODP[01]", "A.03.15.03.a", "A.03.15.03.d[01]", @@ -118026,9 +119857,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.1.3" ], - "general-scf-dpmp-2025": [ - "7.7" - ], "general-tisax-6-0-3": [ "8.2.5", "8.2.7" @@ -118071,10 +119899,10 @@ "PL-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "PL-4" @@ -118102,37 +119930,23 @@ "emea-eu-nis2-annex-2024": [ "12.2.2(b)" ], - "emea-deu-c5-2020": [ - "HR-03" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "15.6", - "19.3", - "19.6" - ], - "emea-sau-cscc-1-2019": [ - "2-5" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.1" ], "emea-sau-ecc-1-2018": [ "1-9-3-1", - "1-9-4-2", "2-1-3", "2-1-4", "2-15-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-1", - "TPC-8", - "TPC-9" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.2", - "Article 11.3" + "VII.A.TPC-1" ], "emea-esp-decree-311-2022": [ - "11.2", - "11.3" + "Article 15(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -118146,12 +119960,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0820", - "ISM-0821" - ], - "apac-jpn-ppi-2020": [ - "21" + "ISM-0821", + "ISM-1864", + "ISM-2095" ], "apac-jpn-ismap": [ "7.2.1.2", @@ -118177,14 +119990,14 @@ "9.3.8.C.03", "14.3.5.C.01", "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "16.4.38.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.18.A", "03.01.22.A", - "03.15.03.A" + "03.15.03.A", + "03.15.03.D" ] } }, @@ -118211,7 +120024,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define rules of behavior that contain explicit restrictions on the use of social media and networking sites, posting information on commercial websites and sharing account information.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define rules of behavior that contain explicit restrictions on the use of social media and networking sites, posting information on commercial websites and sharing account information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -118279,12 +120092,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0" + "9" ], "general-govramp": [ "PL-04(01)" @@ -118354,9 +120168,6 @@ "general-nist-800-171a-r3": [ "A.03.15.03.a" ], - "general-scf-dpmp-2025": [ - "7.7" - ], "usa-federal-fbi-cjis-6-0": [ "PL-4(1)" ], @@ -118399,11 +120210,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PL-04 (01)" ], - "emea-isr-cmo-1-0": [ - "4.13", - "19.6", - "19.7" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2" ], @@ -118419,22 +120225,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0229", "ISM-0230", "ISM-0233", "ISM-0235", "ISM-0236", "ISM-0240", - "ISM-0241", "ISM-0264", "ISM-0267", "ISM-0588", "ISM-0824", "ISM-0931", - "ISM-1075", "ISM-1078", - "ISM-1092", "ISM-1196", "ISM-1198", "ISM-1199", @@ -118461,7 +120264,7 @@ "title": "Technology Use Restrictions", "family": "HRS", "description": "Mechanisms exist to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously.", - "scf_question": "Does the organization establish usage restrictions and implementation guidance for communications technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously?", + "scf_question": "Does the organization establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -118478,7 +120281,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -118563,7 +120366,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -118662,6 +120466,8 @@ "03.15.03.a" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", + "A.03.01.18.a[01]", "A.03.15.03.a" ], "general-pci-dss-4-0-1": [ @@ -118699,10 +120505,10 @@ "PL-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "3.3.2", @@ -118743,24 +120549,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PL-04" ], - "emea-isr-cmo-1-0": [ - "5.4", - "9.5", - "15.6", - "19.6" - ], - "emea-sau-cscc-1-2019": [ - "2-5" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2", - "2-1-3", - "2-6-4", "2-15-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-8", - "TPC-9" + "VII.A.TPC-8" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -118774,6 +120568,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], + "apac-aus-ism-2026-march": [ + "ISM-1866", + "ISM-2075", + "ISM-2095", + "ISM-2099", + "ISM-2100", + "ISM-2101" + ], "apac-jpn-ismap": [ "13.2.1.1", "13.2.1.2", @@ -118788,9 +120590,26 @@ "9.3.5.C.02", "9.3.9.C.01", "9.3.10.C.01", - "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "11.1.15.C.01", + "11.1.16.C.03", + "11.1.16.C.04", + "11.1.17.C.02", + "11.1.18.C.01", + "11.1.18.C.02", + "11.1.19.C.02", + "11.2.14.C.01", + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03", + "11.8.4.C.01", + "11.8.4.C.02", + "11.8.5.C.01", + "11.8.6.C.01", + "11.8.6.C.02", + "15.1.7.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.1.5" ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", @@ -118822,7 +120641,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern usage policies for critical technologies.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern usage policies for critical technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -118906,7 +120725,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -118944,16 +120764,17 @@ "general-nist-800-171-r3": [ "03.15.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.15.03.a" + ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e" ], - "emea-isr-cmo-1-0": [ - "15.6", - "19.6" - ], "emea-sau-ecc-1-2018": [ - "1-9-4-2", - "2-1-3" + "1-9-4-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2095" ], "americas-can-itsp-10-171-2025": [ "03.15.03.A" @@ -118980,7 +120801,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to manage business risks associated with permitting mobile device access to organizational resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119066,7 +120887,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -119096,6 +120918,7 @@ "03.15.03.a" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", "A.03.15.03.a" ], "general-shared-assessments-sig-2025": [ @@ -119104,20 +120927,16 @@ "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e" ], - "emea-deu-c5-2020": [ - "AM-05" - ], - "emea-isr-cmo-1-0": [ - "13.2", - "13.3", - "13.7", - "13.10", - "15.6", - "19.6" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-1", + "2-5-1-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-84" + ], "emea-gbr-def-stan-05-138-2024": [ "2322" ], @@ -119130,7 +120949,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0229", "ISM-0230", "ISM-0240", @@ -119148,7 +120967,8 @@ "ISM-1198", "ISM-1199", "ISM-1200", - "ISM-1366" + "ISM-1366", + "ISM-1866" ], "apac-nzl-ism-3-9": [ "8.1.12.C.01", @@ -119167,9 +120987,19 @@ "11.5.16.C.02", "11.5.16.C.03", "21.1.11.C.01", - "21.1.11.C.02", - "21.1.22.C.01", - "21.1.22.C.02" + "22.1.10.C.02", + "22.1.13.C.01", + "22.1.13.C.02", + "22.1.13.C.03", + "22.1.13.C.04", + "22.1.13.C.05", + "22.2.5.C.01", + "22.2.6.C.01", + "22.2.7.C.01", + "22.2.7.C.02", + "22.3.5.C.01", + "22.3.6.C.01", + "22.4.9.C.01" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", @@ -119195,7 +121025,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to prohibit the use of oversized clothing (e.g., baggy pants, oversized hooded sweatshirts, etc.) to prevent the unauthorized exfiltration of data and technology assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119232,7 +121062,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": {} @@ -119242,7 +121073,7 @@ "title": "Policy Familiarization & Acknowledgement", "family": "HRS", "description": "Mechanisms exist to ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement.", - "scf_question": "Does the organization ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement?", + "scf_question": "Does the organization ensure personnel receive recurring familiarization with its security, compliance and resilience policies and provide acknowledgement?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -119259,7 +121090,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -119342,9 +121173,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-iso-27001-2022": [ @@ -119358,12 +121189,12 @@ "OR-3.1" ], "general-nist-800-171-r3": [ - "03.15.03.b", "03.15.03.c", "03.15.03.d" ], "general-nist-800-171a-r3": [ - "A.03.15.03.c" + "A.03.15.03.c", + "A.03.15.03.d[02]" ], "general-nist-csf-2-0": [ "GV.PO", @@ -119386,7 +121217,7 @@ "609.930(c)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(b)(1)" + "§ 164.530(b)(1)" ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PL-04-SID" @@ -119394,9 +121225,21 @@ "emea-eu-nis2-annex-2024": [ "1.1.1(f)" ], - "emea-sau-sacs-002-2022": [ - "TPC-26", - "TPC-71" + "emea-aut-dpa-2018": [ + "§ 6(3)" + ], + "emea-deu-c5-2020": [ + "HR-02" + ], + "emea-sau-ecc-1-2018": [ + "1-9-4-1", + "1-9-4-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.b" + ], + "emea-esp-decree-311-2022": [ + "Article 13(2)" ], "apac-jpn-ismap": [ "4.5.2.6", @@ -119406,9 +121249,11 @@ "8.1.3.1" ], "americas-can-itsp-10-171-2025": [ - "03.15.03.B", "03.15.03.C", "03.15.03.D" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(d)" ] } }, @@ -119432,9 +121277,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to require internal and third-party users to sign appropriate access agreements prior to being granted access.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to require internal and third-party users to sign appropriate access agreements prior to being granted access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -119502,7 +121347,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -119595,9 +121441,19 @@ "general-nist-800-171-r3": [ "03.01.18.a", "03.12.05.a", - "03.15.03.b", "03.15.03.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.12.05.a[01]", + "A.03.15.03.c" + ], + "general-nist-800-172-r3": [ + "03.09.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.03E.c.01" + ], "general-tisax-6-0-3": [ "2.1.2" ], @@ -119649,26 +121505,18 @@ "emea-deu-c5-2020": [ "HR-02" ], - "emea-isr-cmo-1-0": [ - "19.6" - ], "emea-sau-ecc-1-2018": [ - "1-9-3" + "1-9-3-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-9", - "TPC-71" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "apac-ind-sebi-2024": [ "GV.RR.S5" ], - "apac-jpn-ppi-2020": [ - "21" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.12.05.A", - "03.15.03.B", "03.15.03.C" ] } @@ -119763,7 +121611,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -119857,6 +121706,10 @@ "03.12.05.a", "03.15.03.c" ], + "general-nist-800-171a-r3": [ + "A.03.12.05.a[01]", + "A.03.15.03.c" + ], "general-tisax-6-0-3": [ "2.1.2", "6.1.2" @@ -119884,7 +121737,7 @@ "PS-06(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)" + "§ 164.502(a)" ], "usa-federal-irs-1075-2021": [ "PS-6" @@ -119907,27 +121760,41 @@ "emea-eu-nis2-annex-2024": [ "10.3.2" ], + "emea-eu-psd2-2015": [ + "24(1)" + ], + "emea-aut-dpa-2018": [ + "§ 5(1)" + ], "emea-deu-c5-2020": [ - "HR-06", - "IDM-08", - "PSS-07" + "IDM-07-DOAR", + "KOS-08" ], - "emea-isr-cmo-1-0": [ - "19.4" + "emea-isr-ppl-5741-2025": [ + "s.16" ], "emea-sau-ecc-1-2018": [ - "1-9-3-1" + "1-9-3-1", + "4-1-2-1" ], "emea-sau-sacs-002-2022": [ - "TPC-9", - "TPC-71" + "VII.A.TPC-9" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.a" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" + ], + "apac-chn-csnip-2012": [ + "III" + ], + "apac-chn-pipl-2021": [ + "Article 59" ], "apac-ind-sebi-2024": [ "GV.RR.S5" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "13.2.4", "13.2.4.1", @@ -119953,6 +121820,12 @@ "americas-can-itsp-10-171-2025": [ "03.12.05.A", "03.15.03.C" + ], + "americas-chl-act-19628-1999": [ + "I.7" + ], + "americas-col-law-1581-2012": [ + "II.4(h)" ] } }, @@ -119960,8 +121833,8 @@ "control_id": "HRS-06.2", "title": "Post-Employment Requirements Awareness", "family": "HRS", - "description": "Mechanisms exist to notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive/regulated data.", - "scf_question": "Does the organization notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive/regulated data?", + "description": "Mechanisms exist to notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive and/or regulated data.", + "scf_question": "Does the organization notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive and/or regulated data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -120057,7 +121930,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -120075,6 +121949,9 @@ "PS-6(CE-3).a", "PS-6(CE-3).b" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e" + ], "apac-jpn-ismap": [ "7.1.2.10" ] @@ -120103,7 +121980,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Requests for investigations are handled through a formal, management-approved process.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to sanction personnel failing to comply with established security policies, standards and procedures.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to sanction personnel failing to comply with established security policies, standards and procedures. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -120188,7 +122065,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -120262,17 +122140,15 @@ "3.9.2[b]", "3.9.2[c]" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" ], "general-nist-csf-2-0": [ "GV.PO", "GV.PO-01", "GV.PO-02" ], - "general-scf-dpmp-2025": [ - "7.8" - ], "usa-federal-dow-cert-rmm-1-2": [ "HRM:SG3.SP4" ], @@ -120298,11 +122174,11 @@ "PS-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(C)", - "164.530(e)(1)" + "§ 164.308(a)(1)(ii)(C)", + "§ 164.530(e)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(C)" + "§ 164.308(a)(1)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.2", @@ -120334,8 +122210,8 @@ "emea-deu-c5-2020": [ "HR-04" ], - "emea-isr-cmo-1-0": [ - "19.8" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.c" ], "apac-jpn-ismap": [ "7.2.3", @@ -120344,7 +122220,7 @@ "7.2.3.3", "7.2.3.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP03", "HHSP72", "HHSP73", @@ -120381,9 +122257,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Requests for investigations are handled through a formal, management-approved process.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to conduct employee misconduct investigations when there is reasonable assurance that a policy has been violated.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to conduct employee misconduct investigations when there is reasonable assurance that a policy has been violated. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -120469,7 +122345,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -120493,8 +122370,9 @@ "03.01.01.f.04", "03.01.01.f.05" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1g" @@ -120508,7 +122386,7 @@ "emea-eu-nis2-annex-2024": [ "10.4.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP03", "HHSP73", "HML03", @@ -120627,7 +122505,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -120640,8 +122519,8 @@ "control_id": "HRS-07.3", "title": "Preventative Access Restriction", "family": "HRS", - "description": "Mechanisms exist to proactively restrict logical and physical access when an individual with access to sensitive/regulated data is under investigation for personnel sanctions that may lead to employment termination.", - "scf_question": "Does the organization proactively restrict logical and physical access when an individual with access to sensitive/regulated data is under investigation for personnel sanctions that may lead to employment termination?", + "description": "Mechanisms exist to proactively restrict logical and physical access when an individual with access to sensitive and/or regulated data is under investigation for personnel sanctions that may lead to employment termination.", + "scf_question": "Does the organization proactively restrict logical and physical access when an individual with access to sensitive and/or regulated data is under investigation for personnel sanctions that may lead to employment termination?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -120737,13 +122616,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { - "general-nist-800-172": [ - "3.9.2e" - ], "usa-federal-dow-cmmc-2-level-3": [ "PS.L3-3.9.2E" ] @@ -120856,7 +122733,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -120924,7 +122802,8 @@ "general-nist-800-171-r3": [ "03.01.01.g.02", "03.09.02.a", - "03.09.02.b.01" + "03.09.02.b.01", + "03.09.02.b.02" ], "general-nist-800-171a": [ "3.9.2[a]", @@ -120932,7 +122811,9 @@ "3.9.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", + "A.03.09.02.a.01", "A.03.09.02.b.01[01]", "A.03.09.02.b.01[02]", "A.03.09.02.b.02" @@ -120962,10 +122843,10 @@ "PS-05" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.1", @@ -120998,19 +122879,17 @@ "HR-05", "IDM-04" ], - "emea-isr-cmo-1-0": [ - "19.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], - "emea-sau-sacs-002-2022": [ - "TPC-18" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", "03.09.02.A", - "03.09.02.B.01" + "03.09.02.B.01", + "03.09.02.B.02" ] } }, @@ -121122,7 +123001,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -121191,6 +123071,7 @@ "03.01.01.f.03", "03.01.01.g.02", "03.09.02.a", + "03.09.02.a.02", "03.09.02.a.03", "03.09.02.b.01" ], @@ -121200,11 +123081,14 @@ "3.9.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.f.03", + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", "A.03.09.02.a.01", "A.03.09.02.a.02[01]", "A.03.09.02.a.02[02]", - "A.03.09.02.a.03" + "A.03.09.02.a.03", + "A.03.09.02.b.01[01]" ], "general-pci-dss-4-0-1": [ "8.2.5" @@ -121253,10 +123137,10 @@ "PS-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.3", @@ -121296,15 +123180,10 @@ "emea-deu-c5-2020": [ "HR-05" ], - "emea-isr-cmo-1-0": [ - "19.9", - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-18" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "apac-jpn-ismap": [ @@ -121318,6 +123197,7 @@ "03.01.01.F.03", "03.01.01.G.02", "03.09.02.A", + "03.09.02.A.02", "03.09.02.A.03", "03.09.02.B.01" ] @@ -121343,7 +123223,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to retrieve organization-owned assets upon termination of an individual's employment.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -121428,7 +123308,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -121448,12 +123329,6 @@ "emea-eu-nis2-annex-2024": [ "12.5" ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-18" - ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" ] @@ -121479,7 +123354,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to expedite the process of removing \"high risk\" individual’s access to TAASD upon termination, as determined by management.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -121566,7 +123441,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -121605,6 +123481,12 @@ "03.09.02.a.02", "03.09.02.b.01" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]", + "A.03.09.02.b.01[01]" + ], "general-pci-dss-4-0-1": [ "8.2.5" ], @@ -121644,13 +123526,6 @@ "usa-federal-irs-1075-2021": [ "AC-2(CE-13)" ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-18" - ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.01", "03.09.02.A.02", @@ -121662,8 +123537,8 @@ "control_id": "HRS-09.3", "title": "Post-Employment Requirements Notification", "family": "HRS", - "description": "Mechanisms exist to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data.", - "scf_question": "Does the organization govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data?", + "description": "Mechanisms exist to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive and/or regulated data.", + "scf_question": "Does the organization govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -121678,7 +123553,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -121760,7 +123635,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -121784,12 +123660,6 @@ ], "general-nist-800-82-r3": [ "PS-04(01)" - ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-18" ] } }, @@ -121811,11 +123681,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to automatically notify Identity and Access Management (IAM) personnel or roles upon termination of an individual employment or contract.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -121880,7 +123750,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -121913,11 +123784,17 @@ "03.09.02.a.01", "03.09.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.g.02", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], "usa-federal-gsa-fedramp-5-high": [ "PS-04(02)" ], "emea-sau-sacs-002-2022": [ - "TPC-6" + "VII.A.TPC-6" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", @@ -121948,7 +123825,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern third-party personnel by reviewing and monitoring third-party security, compliance and/or resilience roles and responsibilities.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -122039,9 +123916,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -122101,6 +123978,9 @@ "general-nist-800-171-r3": [ "03.16.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.b" + ], "general-swift-cscf-2025": [ "5.3A" ], @@ -122143,11 +124023,8 @@ "emea-eu-nis2-annex-2024": [ "10.2.1" ], - "emea-isr-cmo-1-0": [ - "19.5" - ], - "emea-sau-ecc-1-2018": [ - "1-9-1" + "emea-sau-otcc-1-2022": [ + "1-7-1" ], "apac-jpn-ismap": [ "7.1.1.10" @@ -122264,7 +124141,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -122301,7 +124179,7 @@ "5.3", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -122565,6 +124443,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ], "usa-federal-irs-1075-2021": [ "AC-5" ], @@ -122588,23 +124469,21 @@ ], "emea-deu-c5-2020": [ "OIS-04", - "IDM-01" - ], - "emea-isr-cmo-1-0": [ - "4.11", - "10.4" + "OIS-04-BP1", + "OIS-04-BP2", + "OIS-04-BP3", + "OIS-04-DOAR", + "IDM-01-BP2", + "IDM-01-BP3", + "BEI-12" ], "emea-sau-cgiot-2024": [ "2-2-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.3" - ], - "emea-esp-decree-311-2022": [ - "13.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.3 [OP.ACC.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.3", + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2207" @@ -122630,11 +124509,19 @@ "6.1.2.4" ], "apac-sgp-mas-trm-2021": [ + "6.3.2", + "7.6.1", "9.1.1" ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-osfi-b13-2022": [ "2.5.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.04.A" ] @@ -122660,7 +124547,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates risk for individuals requiring elevated privileges or access to sensitive/regulated data.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to avoid incompatible development-specific roles through limiting and reviewing developer privileges to change hardware, software and firmware components within a production/operational environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -122733,7 +124620,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -122755,11 +124643,11 @@ "general-nist-800-171-r3": [ "03.01.04.a" ], - "emea-deu-c5-2020": [ - "PSS-08" + "general-nist-800-171a-r3": [ + "A.03.01.04.a" ], - "apac-chn-data-security-law-2021": [ - "27" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.3" ], "americas-can-itsp-10-171-2025": [ "03.01.04.A" @@ -122870,7 +124758,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -122889,6 +124778,13 @@ "general-nist-800-160-vol-2-r1": [ "AC-03(02)" ], + "general-nist-800-172-r3": [ + "03.01.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" + ], "general-sparta": [ "CM0054" ], @@ -122911,7 +124807,7 @@ "title": "Identify Critical Skills & Gaps", "family": "HRS", "description": "Mechanisms exist to evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist.", - "scf_question": "Does the organization evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist?", + "scf_question": "Does the organization evaluate the critical security, compliance and resilience skills needed to support its mission and identify gaps that exist?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -122995,9 +124891,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -123015,6 +124911,9 @@ "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-4b", "WORKFORCE-4c" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" ] } }, @@ -123105,7 +125004,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -123115,6 +125015,9 @@ ], "usa-federal-dow-cert-rmm-1-2": [ "HRM:SG2" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" ] } }, @@ -123205,9 +125108,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-cobit-2019": [ @@ -123218,9 +125121,6 @@ "PM:SG1.SP1", "PM:SG2", "PM:SG2.SP1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } }, @@ -123309,19 +125209,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-cobit-2019": [ "APO07.03" ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" + ], "emea-eu-nis2-annex-2024": [ "4.2.4(c)" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } }, @@ -123343,7 +125243,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates the business-critical cybersecurity and data protection skills needed to support the organization's mission and identify gaps that exist.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to perform succession planning for vital security, compliance and resilience roles.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -123411,9 +125311,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -123424,9 +125324,6 @@ ], "general-shared-assessments-sig-2025": [ "K.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } }, @@ -123435,7 +125332,7 @@ "title": "Identifying Authorized Work Locations", "family": "HRS", "description": "Mechanisms exist to identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home).", - "scf_question": "Does the organization identity and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home)?", + "scf_question": "Does the organization identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -123448,7 +125345,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -123516,7 +125413,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -123552,7 +125450,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to communicate authorized work locations to organizational personnel.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -123618,7 +125516,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -123725,7 +125624,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -123873,7 +125773,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -123897,9 +125798,9 @@ ], "general-cis-csc-8-1": [ "4.7", - "5.0", + "5", "5.6", - "6.0", + "6", "6.6" ], "general-cis-csc-8-1-ig1": [ @@ -124051,6 +125952,20 @@ "03.05.05.a", "03.05.12.e" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.a[01]", + "A.03.01.01.a[02]", + "A.03.01.18.b", + "A.03.05.01.a[01]", + "A.03.05.05.a", + "A.03.05.12.e" + ], + "general-nist-800-172-r3": [ + "03.05.07E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.07E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 6" ], @@ -124110,9 +126025,6 @@ "8.5.1", "8.6.1" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-swift-cscf-2025": [ "4.1", "5.2" @@ -124203,25 +126115,28 @@ "AC-01", "IA-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(1)", "314.4(c)(1)(i)", "314.4(c)(1)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)", + "§ 164.530(c)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "AC-1", @@ -124276,6 +126191,9 @@ "usa-state-vt-act-171-2018": [ "2447(c)(1)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(g)" + ], "emea-eu-dora-2023": [ "Article 9.4(d)" ], @@ -124294,73 +126212,49 @@ "11.5.2(c)", "11.6.4" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "6.1", "6.2" ], "emea-deu-c5-2020": [ "IDM-01", - "PSS-05", - "PSS-09" + "IDM-03" ], - "emea-isr-cmo-1-0": [ - "4.1", - "4.8", - "4.34", - "4.37", - "12.15", - "12.28", - "12.29" + "emea-isr-cmo-2-0": [ + "Appendix A, 8.2" ], "emea-sau-cscc-1-2019": [ - "2-2", - "2-2-1-5" + "2-2-1" ], "emea-sau-ecc-1-2018": [ "2-2-1", - "2-2-2", - "2-2-4" + "2-2-3" ], "emea-sau-otcc-1-2022": [ - "2-2", - "2-2-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-10" + "2-2-1", + "2-2-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.5" - ], - "emea-zaf-popia-2013": [ - "19", - "20" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" + "3.3.5.1" ], "emea-esp-decree-311-2022": [ - "18" + "Article 12(6)(e)", + "Article 24(3)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.2 [OP.ACC.2]", - "7.2.4 [OP.ACC.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-caf-4-0": [ "B2", "B2.d" ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "4" ], "emea-gbr-def-stan-05-138-2024": [ "2200", @@ -124381,9 +126275,11 @@ "2208", "2210" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1146", - "ISM-1546" + "ISM-1546", + "ISM-2076", + "ISM-2077" ], "apac-chn-cybersecurity-law-2017": [ "Article 40" @@ -124415,33 +126311,46 @@ "9.1.1.15", "9.4.1.8.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.53", + "10.54", + "10.56", + "10.57" + ], "apac-nzl-ism-3-9": [ - "16.1.31.C.01" + "16.1.31.C.01", + "16.4.39.C.01", + "20.2.16.C.02" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.1" ], "apac-sgp-mas-trm-2021": [ - "9.1.2", - "9.1.3", - "9.1.8" + "9.1.8", + "9.2.2" + ], + "americas-arg-ppd-2018": [ + "B", + "D.1.2-1" ], "americas-bmu-mba-coc-2020": [ "6.6" ], - "amaericas-can-osfi-self-assessment": [ - "4.22", - "4.24" - ], "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.A", "03.01.18.B", "03.05.01.A", "03.05.05.A", "03.05.12.E" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(b)" ] } }, @@ -124463,7 +126372,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to retain a record of personnel accountability to ensure there is a record of all access granted to an individual (system and application-wise), who provided the authorization, when the authorization was granted and when the access was last reviewed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -124549,7 +126458,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -124571,8 +126481,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1503" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0407" + ], + "apac-sgp-mas-trm-2021": [ + "9.1.3" ] } }, @@ -124596,7 +126509,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).\n▪ LAC and RBAC enforcements limit the ability of non-administrators from making unauthorized configuration changes to TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to strictly govern the use of Authenticate, Authorize and Audit (AAA) solutions, both on-premises and those hosted by an External Service Provider (ESP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -124675,7 +126588,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -124791,6 +126705,8 @@ "IA-4" ], "general-nist-800-171-r3": [ + "03.01.01.d.01", + "03.01.16.b", "03.05.01.a", "03.05.02", "03.05.05.d", @@ -124800,18 +126716,23 @@ "03.05.07.d", "03.05.07.e", "03.05.12.d", - "03.05.12.f", "03.07.05.a" ], "general-nist-800-171a-r3": [ "A.03.01.01.d.01", - "A.03.01.01.d.02", "A.03.01.16.b", "A.03.05.01.a[01]", - "A.03.05.01.a[02]" - ], - "general-nist-800-172": [ - "3.5.2e" + "A.03.05.01.a[02]", + "A.03.05.02[01]", + "A.03.05.02[02]", + "A.03.05.05.d", + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.12.d", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 2", @@ -124825,9 +126746,6 @@ "PR.AA-04", "PR.AA-05" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0031" ], @@ -124903,12 +126821,31 @@ "2447(c)(1)(B)", "2447(c)(2)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(g)" + ], "emea-eu-nis2-annex-2024": [ "11.3.2(a)", "11.4.2(c)", "11.6.1", "11.6.3" ], + "emea-deu-c5-2020": [ + "IDM-02", + "IDM-03-BP2", + "IDM-08-BP2" + ], + "emea-sau-ecc-1-2018": [ + "2-2-3-1" + ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP5", + "4", + "4-BP2" + ], "emea-gbr-def-stan-05-138-2024": [ "2200", "2209", @@ -124931,6 +126868,10 @@ "2210", "2304" ], + "apac-aus-ism-2026-march": [ + "ISM-2013", + "ISM-2014" + ], "apac-jpn-ismap": [ "9.4.2", "9.4.2.1", @@ -124950,14 +126891,28 @@ "9.4.2.15", "9.4.2.16" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP39", "HML39" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP34" ], + "apac-nzl-ism-3-9": [ + "16.1.26.C.01" + ], + "americas-arg-ppd-2018": [ + "B.2.3-1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.D.01", + "03.01.16.B", "03.05.01.A", "03.05.02", "03.05.05.D", @@ -124967,7 +126922,6 @@ "03.05.07.D", "03.05.07.E", "03.05.12.D", - "03.05.12.F", "03.07.05.A" ] } @@ -125093,7 +127047,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -125123,6 +127078,113 @@ ] } }, + { + "control_id": "IAC-01.4", + "title": "Identity Providers (IdP) & Authorization Servers", + "family": "IAC", + "description": "Mechanisms exist to employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms.", + "scf_question": "Does the organization employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms.", + "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "small": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "medium": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "large": "∙ Microsoft Entra ID with conditional access\n∙ Okta Workforce Identity\n∙ SailPoint for identity governance", + "enterprise": "∙ Enterprise IdP with federation (SAML/OIDC/OAuth 2.0)\n∙ Microsoft Entra ID with Privileged Identity Management\n∙ Okta or Ping Identity enterprise tier\n∙ SailPoint or Saviynt for identity governance" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Identification & Authentication", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.05.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.07E[01]", + "A.03.05.07E.ODP[02]", + "DS-A.03.05.07E[02]", + "DS-A.03.05.07E[03]" + ] + } + }, { "control_id": "IAC-02", "title": "Identification & Authentication for Organizational Users", @@ -125147,7 +127209,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -125234,7 +127296,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -125302,7 +127365,7 @@ "general-iso-27018-2025": [ "5.15" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -125644,10 +127707,10 @@ "IA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "IA-2", @@ -125670,34 +127733,18 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(a)" ], - "emea-deu-c5-2020": [ - "IDM-01", - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.31", - "4.34" - ], - "emea-sau-ecc-1-2018": [ - "2-2-3" + "emea-sau-otcc-1-2022": [ + "2-2-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-32" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.3" + "VII.B.TPC-32" ], - "emea-esp-decree-311-2022": [ - "24.3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2" ], "emea-gbr-caf-4-0": [ "B2.a" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" - ], "emea-gbr-def-stan-05-138-2024": [ "2218" ], @@ -125710,7 +127757,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2218" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0414", "ISM-0415", "ISM-1546" @@ -125718,19 +127765,9 @@ "apac-nzl-ism-3-9": [ "16.1.32.C.01" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ - "03.05.01.A" + "03.05.01.A", + "03.05.05.D" ] } }, @@ -125752,9 +127789,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -125822,7 +127859,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -125883,19 +127921,12 @@ "usa-federal-gsa-fedramp-5-high": [ "IA-02(05)" ], - "emea-isr-cmo-1-0": [ - "4.34" - ], - "emea-sau-cscc-1-2019": [ - "2-2-1-7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0415", "ISM-1619" ], "apac-nzl-ism-3-9": [ "16.1.33.C.01", - "16.1.33.C.02", "16.1.34.C.01" ] } @@ -125994,7 +128025,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -126044,9 +128076,6 @@ "A.03.05.04[02]", "A.03.07.05.b[02]" ], - "general-nist-800-172": [ - "3.5.1e" - ], "general-nist-csf-2-0": [ "PR.AA-04" ], @@ -126098,9 +128127,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (08)" ], - "emea-isr-cmo-1-0": [ - "4.31" - ], "emea-gbr-def-stan-05-138-2024": [ "2215" ], @@ -126113,7 +128139,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2215" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1055", "ISM-1603" ], @@ -126141,9 +128167,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify organizational Personal Identity Verification (PIV) credentials.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify organizational Personal Identity Verification (PIV) credentials. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -126225,7 +128251,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -126303,9 +128330,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Out-of-Band Authentication (OOBA) under specific conditions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Out-of-Band Authentication (OOBA) under specific conditions. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -126387,7 +128414,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -126426,7 +128454,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -126515,7 +128543,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -126566,7 +128595,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1053", "T1053.007", "T1059", @@ -126629,6 +128658,9 @@ "general-nist-800-171-r3": [ "03.05.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.05.01.a[03]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -126686,43 +128718,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-08" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.21" - ], - "emea-sau-ecc-1-2018": [ - "2-2-3" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.3" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-32" ], - "emea-esp-decree-311-2022": [ - "24.3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "emea-gbr-caf-4-0": [ "B2.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1583" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ "03.05.01.A" ] @@ -126746,7 +128753,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -126830,7 +128837,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -126899,9 +128907,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -126982,7 +128990,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127041,10 +129050,6 @@ "IA-8(CE-2)", "IA-8(CE-2).a", "IA-8(CE-2).b" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" ] } }, @@ -127066,9 +129071,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -127134,7 +129139,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127203,7 +129209,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -127242,7 +129248,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127275,7 +129282,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -127307,7 +129314,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127340,7 +129348,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -127429,7 +129437,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127481,7 +129490,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1530", "T1537", "T1552", @@ -127548,12 +129557,18 @@ "03.05.02" ], "general-nist-800-171a-r3": [ + "A.03.01.18.b", "A.03.05.02.ODP[01]", "A.03.05.02[01]", "A.03.05.02[02]" ], - "general-nist-800-172": [ - "3.5.1e" + "general-nist-800-172-r3": [ + "03.05.01E", + "03.05.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.01E", + "DS-A.03.05.03E" ], "general-nist-800-207": [ "NIST Tenet 2", @@ -127625,20 +129640,13 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(a)" ], - "emea-us-psd2-2015": [ - "25" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.33" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "emea-gbr-caf-4-0": [ "B2.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1603" ], "americas-can-itsp-10-171-2025": [ @@ -127665,11 +129673,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure device identification and authentication is accurate by centrally-managing the joining of systems to the domain as part of the initial asset configuration management process.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -127733,7 +129741,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127749,6 +129758,12 @@ "general-nist-800-82-r3": [ "IA-03(04)" ], + "general-nist-800-172-r3": [ + "03.05.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.03E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-low": [ "IA-03(04)" ], @@ -127781,7 +129796,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce cryptographic communications keys to prevent one key from being used to access multiple devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -127842,7 +129857,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127872,7 +129888,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify and authenticate third-party Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -127961,7 +129977,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127995,7 +130012,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1036", "T1036.001", "T1036.005", @@ -128044,6 +130061,11 @@ "03.05.01.a", "03.05.02" ], + "general-nist-800-171a-r3": [ + "A.03.05.01.a[03]", + "A.03.05.02[01]", + "A.03.05.02[02]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -128065,29 +130087,19 @@ "usa-federal-irs-1075-2021": [ "IA-9" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.2" + "emea-sau-cscc-1-2019": [ + "2-2-1-7" ], - "emea-sau-ecc-1-2018": [ - "2-2-3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP49", "HML49" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP41" ], - "apac-sgp-mas-trm-2021": [ - "9.1.8" - ], "americas-can-itsp-10-171-2025": [ "03.05.01.A", "03.05.02" @@ -128112,11 +130124,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure external service providers provide current and accurate information for any third-party user with access to the organization's data or assets.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -128196,7 +130208,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -128322,7 +130335,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -128347,6 +130361,9 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 4" ], @@ -128362,8 +130379,8 @@ "control_id": "IAC-06", "title": "Multi-Factor Authentication (MFA)", "family": "IAC", - "description": "Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:\n(1) Remote network access; \n(2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n(3) Non-console access to critical TAAS that store, transmit and/or process sensitive/regulated data.", - "scf_question": "Does the organization use automated mechanisms to enforce Multi-Factor Authentication (MFA) for:\n (1) Remote network access; \n (2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n (3) Non-console access to critical TAAS that store, transmit and/or process sensitive/regulated data?", + "description": "Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:\n(1) Remote network access; \n(2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n(3) Non-console access to critical TAAS that store, transmit and/or process sensitive and/or regulated data.", + "scf_question": "Does the organization use automated mechanisms to enforce Multi-Factor Authentication (MFA) for:\n (1) Remote network access; \n (2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n (3) Non-console access to critical TAAS that store, transmit and/or process sensitive and/or regulated data?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -128466,7 +130483,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -128615,9 +130633,6 @@ "8.4.3", "8.5.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "4.2" ], @@ -128670,6 +130685,9 @@ "IA-02(01)", "IA-02(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(4)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(5)" ], @@ -128715,12 +130733,9 @@ "11.3.2(a)", "11.7.1" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-isr-cmo-1-0": [ - "4.21", - "4.32" + "emea-deu-c5-2020": [ + "RB-15-DOAR", + "IDM-08-BP3" ], "emea-sau-cscc-1-2019": [ "2-2-1-3", @@ -128732,14 +130747,14 @@ "2-15-3-5" ], "emea-sau-sacs-002-2022": [ - "TPC-4", - "TPC-5", - "TPC-37", - "TPC-44", - "TPC-45" + "VII.A.TPC-4", + "VII.A.TPC-5", + "VII.B.TPC-37", + "VII.B.TPC-44", + "VII.B.TPC-45" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "4-BP4" ], "emea-gbr-def-stan-05-138-2024": [ "2201", @@ -128765,7 +130780,7 @@ "ML2-P3", "ML3-P3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0974", "ISM-1173", "ISM-1401", @@ -128779,20 +130794,39 @@ "ISM-1681", "ISM-1682", "ISM-1683", - "ISM-1685" + "ISM-1685", + "ISM-1872", + "ISM-1873", + "ISM-1874", + "ISM-1892", + "ISM-1893", + "ISM-1894", + "ISM-2011" + ], + "apac-aus-cop-sitc-2020": [ + "1" ], "apac-ind-sebi-2024": [ "PR.AA.S7" ], + "apac-mys-bnm-rmit-2025": [ + "10.55" + ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01", + "16.1.29.C.02", + "16.4.37.C.02", + "16.7.42.C.01", + "16.7.42.C.04", + "16.7.42.C.05", + "16.7.42.C.06", + "16.7.42.C.07", + "16.7.43.C.01", + "16.7.44.C.01", "23.3.19.C.01", "23.3.19.C.02" ], "apac-sgp-cyber-hygiene-practice-2019": [ + "4.6", "4.6(b)" ], "apac-sgp-mas-trm-2021": [ @@ -128801,6 +130835,9 @@ "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.05.03", "03.07.05.B" @@ -128827,7 +130864,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -128913,7 +130950,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -128992,6 +131030,9 @@ "3.5.3[a]", "3.5.3[c]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -129073,21 +131114,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" ], - "emea-isr-cmo-1-0": [ - "4.29" - ], "emea-sau-cscc-1-2019": [ "2-2-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-5", - "TPC-37" - ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "16.7.42.C.02", + "16.7.42.C.03" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.6(a)" @@ -129117,7 +131149,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -129203,7 +131235,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -129269,6 +131302,9 @@ "general-nist-800-171a": [ "3.5.3[d]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[02]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -129339,19 +131375,15 @@ "emea-sau-cscc-1-2019": [ "2-2-1-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-5", - "TPC-45" - ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML3-P3" ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "16.7.42.C.03" + ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.6(b)" ], "americas-can-itsp-10-171-2025": [ "03.05.03" @@ -129376,9 +131408,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -129464,7 +131496,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -129530,6 +131563,9 @@ "3.5.3[a]", "3.5.3[b]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -129596,28 +131632,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" ], - "emea-isr-cmo-1-0": [ - "4.30" + "emea-deu-c5-2020": [ + "RB-15-DOAR" ], "emea-sau-cscc-1-2019": [ "2-2-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-37" - ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML3-P3" ], - "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.6(a)" - ], "americas-can-itsp-10-171-2025": [ "03.05.03" ] @@ -129628,7 +131652,7 @@ "title": "Out-of-Band Multi-Factor Authentication", "family": "IAC", "description": "Mechanisms exist to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed.", - "scf_question": "Does the organization implements Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is securely provided by a device separate from the system gaining access?", + "scf_question": "Does the organization implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -129641,9 +131665,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -129725,7 +131749,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -129787,6 +131812,9 @@ "general-nist-800-160-vol-2-r1": [ "IA-02(06)" ], + "general-nist-800-171-r3": [ + "03.05.03" + ], "general-nist-800-171a-r3": [ "A.03.05.03[01]", "A.03.05.03[02]" @@ -129851,6 +131879,9 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" + ], + "americas-can-itsp-10-171-2025": [ + "03.05.03" ] } }, @@ -129956,7 +131987,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -129989,7 +132021,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize a formal user registration and de-registration process that governs the assignment of access rights.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize a formal user registration and de-registration process that governs the assignment of access rights. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -130078,7 +132110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -130149,6 +132182,7 @@ "IA-12(04)" ], "general-nist-800-171-r3": [ + "03.01.01.b", "03.01.01.g.01", "03.01.01.g.02", "03.01.01.g.03", @@ -130162,7 +132196,13 @@ "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.05.05.a" + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -130225,17 +132265,23 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-12(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(7)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 6.1.1", "CIP-004-7 6.1.2", "CIP-004-7 6.3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(e)" + ], "emea-eu-nis2-annex-2024": [ "11.2.1", "11.2.2(a)", @@ -130248,15 +132294,33 @@ "6.6" ], "emea-deu-c5-2020": [ - "IDM-01", - "IDM-02", - "PSS-09" + "IDM-01-BP1", + "IDM-01-BP5", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-04", + "IDM-05" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" + ], + "emea-sau-ecc-1-2018": [ + "1-9-5" + ], + "emea-sau-otcc-1-2022": [ + "2-2-1-10", + "2-2-1-11" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-6" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.1 [OP.ACC.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1", + "op.acc.4", + "op.acc.5" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "4-BP6" ], "emea-gbr-def-stan-05-138-2024": [ "2702" @@ -130270,7 +132334,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2702" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "apac-jpn-ismap": [ @@ -130283,7 +132347,7 @@ "9.2.6", "9.2.6.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -130294,7 +132358,11 @@ "apac-nzl-ism-3-9": [ "23.3.20.C.01" ], + "apac-sgp-mas-trm-2021": [ + "9.1.2" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.B", "03.01.01.G.01", "03.01.01.G.02", "03.01.01.G.03", @@ -130327,7 +132395,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -130397,7 +132465,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -130433,6 +132502,14 @@ "03.05.05.a", "03.09.02.b.02" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -130477,10 +132554,10 @@ "ACCESS-2h" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "emea-eu-nis2-annex-2024": [ "1.2.6" @@ -130490,20 +132567,20 @@ "6.5", "6.6" ], - "emea-deu-c5-2020": [ - "PS-04", - "PSS-08" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], "emea-sau-otcc-1-2022": [ - "2-2-1-10" + "2-2-1-11" ], - "apac-aus-ism-2024-june": [ - "ISM-0430" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], - "apac-chn-data-security-law-2021": [ - "27" + "apac-aus-ism-2026-march": [ + "ISM-0430" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -130628,7 +132705,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -130708,6 +132786,11 @@ "03.09.02.a.01", "03.09.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -130757,10 +132840,10 @@ "AC-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "AC-2" @@ -130785,14 +132868,20 @@ "6.5", "6.6" ], + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" + ], "emea-sau-otcc-1-2022": [ - "2-2-1-10", "2-2-1-11" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "apac-aus-ism-2026-march": [ "ISM-0430" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -130830,7 +132919,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Role-Based Access Control (RBAC) for TAASD to restrict access to individuals assigned specific roles with legitimate business needs.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -130901,7 +132990,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -130915,7 +133005,7 @@ ], "general-cis-csc-8-1": [ "3.3", - "6.0", + "6", "6.8" ], "general-cis-csc-8-1-ig1": [ @@ -131018,17 +133108,28 @@ "3.1.3[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.01", "A.03.01.01.c.02", "A.03.01.01.c.03", + "A.03.01.02[01]", + "A.03.01.02[02]", "A.03.01.05.ODP[01]", "A.03.01.05.ODP[02]", "A.03.01.05.b[01]", "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.12.a[02]", + "A.03.03.08.b", "A.03.04.05[04]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.07.06.a" ], - "general-nist-800-172": [ - "3.1.2e" + "general-nist-800-172-r3": [ + "03.01.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.11E.a", + "DS-A.03.01.11E.b" ], "general-nist-800-207": [ "NIST Tenet 3", @@ -131085,9 +133186,6 @@ "7.3.2", "7.3.3" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.2", "5.1" @@ -131143,20 +133241,20 @@ "155.260(a)(4)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)", - "164.514(d)(2)(i)(A)", - "164.514(d)(2)(i)(B)", - "164.514(d)(2)(ii)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)", + "§ 164.514(d)(2)(i)(A)", + "§ 164.514(d)(2)(i)(B)", + "§ 164.514(d)(2)(ii)", + "§ 164.530(c)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "2.D.6" @@ -131192,7 +133290,7 @@ "2447(c)(2)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.2.(32)" + "3.4.2.32" ], "emea-eu-gdpr-2016": [ "Article 32.4" @@ -131202,43 +133300,31 @@ "11.2.2(d)", "11.4.1" ], - "emea-deu-bsrit-2017": [ - "6.2" + "emea-deu-fdpa-2017": [ + "2.1.2.27(1)", + "3.2.48(2)4" ], "emea-deu-c5-2020": [ - "PSS-08", - "PSS-11" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.8", - "4.9", - "4.10", - "4.11", - "4.20", - "12.28", - "12.29" + "RB-15", + "IDM-01", + "IDM-01-BP3", + "BEI-12" ], "emea-sau-cgiot-2024": [ "2-2-1" ], "emea-sau-ecc-1-2018": [ - "2-2-3-3" + "2-2-3-3", + "2-6-3-2" ], "emea-sau-sacs-002-2022": [ - "TPC-39" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 17" + "VII.B.TPC-34" ], "emea-esp-decree-311-2022": [ - "17" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.4 [OP.ACC.4]" + "Article 17" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2" ], "emea-gbr-def-stan-05-138-2024": [ "2200", @@ -131265,11 +133351,11 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-1746" - ], - "apac-chn-data-security-law-2021": [ - "27" + "apac-aus-ism-2026-march": [ + "ISM-1746", + "ISM-1852", + "ISM-2092", + "ISM-2093" ], "apac-ind-sebi-2024": [ "PR.AA.S3" @@ -131286,15 +133372,15 @@ "9.4.1.6", "9.4.1.7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.56" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP40", "HHSP42", "HML40", "HML42" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS07" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP04", "HSUP37" @@ -131306,8 +133392,13 @@ "16.2.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "9.1.7", - "11.1.6" + "9.1.7" + ], + "americas-arg-ppd-2018": [ + "B.1.2-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01", @@ -131415,7 +133506,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -131464,7 +133556,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.005", "T1003.006", @@ -131563,7 +133655,8 @@ "A.03.05.05.ODP[01]", "A.03.05.05.b[01]", "A.03.05.05.b[02]", - "A.03.05.05.c" + "A.03.05.05.c", + "A.03.05.05.d" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -131613,10 +133706,10 @@ "IA-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-irs-1075-2021": [ "IA-4", @@ -131641,11 +133734,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-04" ], - "emea-deu-c5-2020": [ - "IDM-01" - ], - "emea-isr-cmo-1-0": [ - "12.15" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "americas-can-itsp-10-171-2025": [ "03.05.05.B", @@ -131674,7 +133764,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure proper user identification management for non-consumer users and administrators.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure proper user identification management for non-consumer users and administrators. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -131744,7 +133834,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -131802,6 +133893,10 @@ "general-nist-800-171-r3": [ "03.05.05.b" ], + "general-nist-800-171a-r3": [ + "A.03.05.05.b[01]", + "A.03.05.05.b[02]" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -131851,11 +133946,8 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(b)" ], - "emea-isr-cmo-1-0": [ - "12.15" - ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "americas-can-itsp-10-171-2025": [ "03.05.05.B" @@ -131880,9 +133972,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify contractors and other third-party users through unique username characteristics.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify contractors and other third-party users through unique username characteristics. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -131952,7 +134044,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -132020,17 +134113,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-04 (04)" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ "03.05.05.D" ] @@ -132054,9 +134136,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to dynamically manage usernames and system identifiers.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to dynamically manage usernames and system identifiers. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -132124,7 +134206,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -132166,7 +134249,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to coordinate username identifiers with external organizations for cross-organization management of identifiers.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to coordinate username identifiers with external organizations for cross-organization management of identifiers. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -132232,7 +134315,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -132262,6 +134346,9 @@ ], "general-nist-800-161-r1-level-3": [ "IA-4(6)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ] } }, @@ -132283,7 +134370,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely manage privileged accounts to identify the account as a privileged user or service.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -132355,7 +134442,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -132389,6 +134477,10 @@ "general-nist-800-171a": [ "3.1.5[a]" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b", + "A.03.05.05.d" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -132404,12 +134496,6 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05(08)" ], - "emea-deu-c5-2020": [ - "IDM-02" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" - ], "americas-can-itsp-10-171-2025": [ "03.01.07.B", "03.05.05.D" @@ -132471,7 +134557,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -132491,29 +134578,8 @@ "general-owasp-top-10-2025": [ "A01:2025" ], - "emea-zaf-popia-2013": [ - "6.1.b" - ], - "apac-aus-privacy-principles-2026": [ - "APP 2" - ], - "apac-jpn-ppi-2020": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" + "apac-jpn-appi-2020": [ + "IV.2.35-2(1)" ] } }, @@ -132539,7 +134605,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to:\n(1) Securely manage authenticators for users and devices; and\n(2) Ensure the strength of authentication is appropriate to the classification of the data being accessed.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -132610,7 +134676,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -132678,7 +134745,7 @@ "5.17", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -132826,6 +134893,12 @@ "3.5.9" ], "general-nist-800-171a-r3": [ + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", "A.03.05.12.ODP[01]", "A.03.05.12.ODP[02]", "A.03.05.12.a", @@ -132998,39 +135071,17 @@ "11.6.2(a)", "11.7.2" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "IDM-08" - ], - "emea-isr-cmo-1-0": [ - "4.35", - "12.15", - "12.16" - ], - "emea-sau-cscc-1-2019": [ - "2-2-1-6" - ], "emea-sau-cgiot-2024": [ "2-2-2" ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-8" - ], "emea-sau-sacs-002-2022": [ - "TPC-3" + "VII.B.TPC-62" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1227", "ISM-1593", "ISM-1594", @@ -133053,12 +135104,11 @@ "14.3.13.C.01", "14.3.13.C.02", "14.3.13.C.03", + "16.1.36.C.02", + "16.1.36.C.03", "16.1.40.C.01", - "16.1.40.C.02", "16.1.41.C.01", "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04", "16.1.42.C.01" ], "americas-can-itsp-10-171-2025": [ @@ -133167,7 +135217,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -133272,10 +135323,8 @@ "03.05.07.e", "03.05.07.f", "03.05.12.b", - "03.05.12.c", "03.05.12.d", - "03.05.12.e", - "03.05.12.f" + "03.05.12.e" ], "general-nist-800-171a": [ "3.5.7[a]", @@ -133285,7 +135334,17 @@ ], "general-nist-800-171a-r3": [ "A.03.05.07.ODP[02]", - "A.03.05.07.f" + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.b", + "A.03.05.12.d", + "A.03.05.12.e" + ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.02E.ODP[02]" ], "general-owasp-top-10-2025": [ "A07:2025" @@ -133381,6 +135440,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(3)" + ], "usa-federal-irs-1075-2021": [ "IA-5(CE-1)", "IA-5(CE-1).f", @@ -133431,47 +135493,33 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (01)" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "IDM-09", - "PSS-07" - ], - "emea-isr-cmo-1-0": [ - "4.35", - "12.15", - "12.16" - ], "emea-sau-cscc-1-2019": [ "2-2-1-5" ], "emea-sau-cgiot-2024": [ "2-2-2" ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" - ], "emea-sau-otcc-1-2022": [ "2-2-1-8" ], "emea-sau-sacs-002-2022": [ - "TPC-2" + "VII.A.TPC-2" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0417", "ISM-0421", "ISM-0422", "ISM-1557", "ISM-1558", "ISM-1596", - "ISM-1795" + "ISM-1795", + "ISM-1980", + "ISM-2079", + "ISM-2080", + "ISM-2081" ], "apac-aus-cop-sitc-2020": [ - "Principle 1" + "1" ], "apac-jpn-ismap": [ "9.3.1.4", @@ -133487,6 +135535,9 @@ "9.4.3.9" ], "apac-nzl-ism-3-9": [ + "16.1.29.C.01", + "16.1.31.C.02", + "16.1.31.C.07", "16.1.35.C.01", "16.1.35.C.02", "16.1.42.C.01", @@ -133495,14 +135546,15 @@ "apac-sgp-mas-trm-2021": [ "9.1.4" ], + "americas-arg-ppd-2018": [ + "B.2.3-7" + ], "americas-can-itsp-10-171-2025": [ "03.05.07.E", "03.05.07.F", "03.05.12.B", - "03.05.12.C", "03.05.12.D", - "03.05.12.E", - "03.05.12.F" + "03.05.12.E" ] } }, @@ -133524,7 +135576,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically validate certificates by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information for PKI-based authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -133607,7 +135659,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -133730,13 +135783,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (02)" - ], - "emea-deu-c5-2020": [ - "IDM-09" - ], - "emea-isr-cmo-1-0": [ - "12.15", - "12.16" ] } }, @@ -133845,7 +135891,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -133870,6 +135917,9 @@ "general-nist-800-171-r3": [ "03.05.12.a" ], + "general-nist-800-171a-r3": [ + "A.03.05.12.a" + ], "usa-federal-gsa-fedramp-5-low": [ "IA-12(04)" ], @@ -133910,9 +135960,9 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Password managers are not governed.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -133979,7 +136029,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -134039,6 +136090,12 @@ "A.03.05.07.a[03]", "A.03.05.07.b" ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.02E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -134077,12 +136134,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (01)" ], - "emea-us-psd2-2015": [ - "19" - ], - "emea-deu-c5-2020": [ - "PSS-07" - ], "emea-gbr-def-stan-05-138-2024": [ "2213" ], @@ -134095,11 +136146,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2213" ], + "apac-aus-ism-2026-march": [ + "ISM-2078" + ], "apac-nzl-ism-3-9": [ "16.1.41.C.01", - "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04" + "16.1.41.C.02" ], "americas-can-itsp-10-171-2025": [ "03.05.07.A", @@ -134127,7 +136179,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Password managers are not governed.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -134196,7 +136248,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -134264,6 +136317,12 @@ "A.03.05.12.f[01]", "A.03.05.12.f[02]" ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.02E.b" + ], "general-pci-dss-4-0-1": [ "8.3.11" ], @@ -134328,27 +136387,17 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(b)" ], - "emea-us-psd2-2015": [ - "19", - "22" - ], "emea-deu-c5-2020": [ - "IDM-08", - "PSS-07" - ], - "emea-isr-cmo-1-0": [ - "4.37" + "IDM-07", + "IDM-08" ], "emea-sau-cscc-1-2019": [ "2-2-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-3" + "VII.A.TPC-3" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0418", "ISM-1402", "ISM-1590", @@ -134367,6 +136416,7 @@ "9.3.1.7" ], "apac-nzl-ism-3-9": [ + "16.1.34.C.02", "16.1.36.C.01", "16.1.37.C.01", "16.1.38.C.01" @@ -134398,7 +136448,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -134468,7 +136518,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -134496,6 +136547,15 @@ "general-nist-800-171-r3": [ "03.05.07.d" ], + "general-nist-800-171a-r3": [ + "A.03.05.07.d" + ], + "general-nist-800-172-r3": [ + "03.05.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.04E" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -134532,8 +136592,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (07)" ], - "emea-sau-sacs-002-2022": [ - "TPC-62" + "apac-aus-cop-sitc-2020": [ + "4" ], "apac-nzl-ism-3-9": [ "16.1.36.C.01" @@ -134628,7 +136688,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -134833,7 +136894,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -134943,6 +137005,10 @@ "03.05.07.e", "03.05.12.d" ], + "general-nist-800-171a-r3": [ + "A.03.05.07.e", + "A.03.05.12.d" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -135005,6 +137071,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(2)" + ], "usa-federal-irs-1075-2021": [ "IA-5", "IA-5(CE-5)" @@ -135030,12 +137099,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05" ], + "emea-sau-cscc-1-2019": [ + "2-3-1-7" + ], "emea-sau-cgiot-2024": [ "2-2-2" ], "emea-sau-otcc-1-2022": [ "2-2-1-3" ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP2" + ], "emea-gbr-def-stan-05-138-2024": [ "2211" ], @@ -135048,12 +137123,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2211" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1304", - "ISM-1806" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 1" + "ISM-1806", + "ISM-2044" ], "americas-can-itsp-10-171-2025": [ "03.05.07.E", @@ -135079,7 +137152,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement security safeguards to manage the risk of compromise due to individuals having accounts on multiple Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -135147,7 +137220,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -135265,7 +137339,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -135284,6 +137359,12 @@ "general-nist-800-82-r3": [ "IA-05(13)" ], + "general-nist-800-172-r3": [ + "03.05.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.05E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-high": [ "IA-05(13)" ] @@ -135307,7 +137388,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ Password managers are provided, but decentralized and not actively governed.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect and store passwords via a password manager tool.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -135380,7 +137461,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -135417,10 +137499,16 @@ "A.03.05.07.a[01]", "A.03.05.07.a[02]", "A.03.05.07.a[03]", - "A.03.05.07.b" + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.f" + ], + "general-nist-800-172-r3": [ + "03.05.02E" ], - "general-nist-800-172": [ - "3.5.2e" + "general-nist-800-172a-r3": [ + "DS-A.03.05.02E.a" ], "general-swift-cscf-2025": [ "5.4" @@ -135437,11 +137525,9 @@ "emea-sau-otcc-1-2022": [ "2-2-1-9" ], - "emea-sau-sacs-002-2022": [ - "TPC-3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2212" @@ -135455,7 +137541,8 @@ "apac-nzl-ism-3-9": [ "14.3.13.C.01", "14.3.13.C.02", - "14.3.13.C.03" + "14.3.13.C.03", + "16.1.37.C.02" ], "americas-can-itsp-10-171-2025": [ "03.05.07.A", @@ -135568,7 +137655,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -135693,7 +137781,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -135791,7 +137880,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -135820,7 +137910,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to obscure the feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to obscure the feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -135890,7 +137980,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -135918,7 +138009,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1021.005", "T1530", @@ -135994,9 +138085,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-06" ], - "emea-isr-cmo-1-0": [ - "4.36" - ], "emea-gbr-def-stan-05-138-2024": [ "2419", "2420" @@ -136036,7 +138124,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure cryptographic modules adhere to applicable statutory, regulatory and contractual requirements for security strength.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -136106,7 +138194,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -136128,7 +138217,7 @@ "general-govramp-high": [ "IA-07" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1495", "T1542", @@ -136206,9 +138295,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-07" - ], - "emea-isr-cmo-1-0": [ - "4.37" ] } }, @@ -136230,9 +138316,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Hardware Security Modules (HSM) to protect authenticators on which the component relies.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Hardware Security Modules (HSM) to protect authenticators on which the component relies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -136295,7 +138381,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -136334,7 +138421,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to allow individuals to utilize alternative methods of authentication under specific circumstances or situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -136406,7 +138493,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -136436,7 +138524,7 @@ "title": "Single Sign-On (SSO) Transparent Authentication", "family": "IAC", "description": "Mechanisms exist to provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to the organization's Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization provide a Single Sign-On (SSO) capability to its Technology Assets, Applications and/or Services (TAAS)?", + "scf_question": "Does the organization provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to its Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -136449,7 +138537,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to the organization's Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -136517,7 +138605,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -136556,7 +138645,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to federate credentials to allow cross-organization authentication of individuals and devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -136624,7 +138713,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -136747,7 +138837,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -136786,7 +138877,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -136856,11 +138947,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1110", "T1110.001", "T1110.002", @@ -136954,8 +139046,8 @@ "control_id": "IAC-15", "title": "Account Management", "family": "IAC", - "description": "Mechanisms exist to proactively govern account management of individual, group, system, service, application, guest and temporary accounts.", - "scf_question": "Does the organization proactively govern account management of individual, group, system, service, application, guest and temporary accounts?", + "description": "Mechanisms exist to:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts.", + "scf_question": "Does the organization:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -136971,9 +139063,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to proactively govern account management of individual, group, system, service, application, guest and temporary accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -136986,11 +139078,11 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" + "micro_small": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "small": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "medium": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "large": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "enterprise": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM" }, "risks": [ "R-AC-1", @@ -137046,8 +139138,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed", "family_name": "Identification & Authentication", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -137096,7 +139190,7 @@ "5.16", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -137381,6 +139475,7 @@ "03.01.01.d.02", "03.01.01.e", "03.01.01.f.01", + "03.01.01.f.02", "03.01.01.f.03", "03.01.01.f.04", "03.01.01.f.05", @@ -137390,7 +139485,8 @@ "03.01.02", "03.01.05.b", "03.01.05.c", - "03.01.05.d" + "03.01.05.d", + "03.05.07.e" ], "general-nist-800-171a": [ "3.1.2[a]", @@ -137400,7 +139496,13 @@ "A.03.01.01.ODP[01]", "A.03.01.01.a[01]", "A.03.01.01.a[02]", + "A.03.01.01.b[01]", + "A.03.01.01.b[02]", + "A.03.01.01.b[03]", "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", "A.03.01.01.e", "A.03.01.01.f.01", "A.03.01.01.f.02", @@ -137410,6 +139512,12 @@ "A.03.01.01.g.01", "A.03.01.01.g.02", "A.03.01.01.g.03", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.05.c", + "A.03.01.05.d", "A.03.05.07.e" ], "general-pci-dss-4-0-1": [ @@ -137470,10 +139578,10 @@ "AC-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "AC-2" @@ -137523,23 +139631,35 @@ "2447(c)(1)(A)(i)", "2447(c)(1)(A)(iv)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(c)" + ], "emea-eu-nis2-annex-2024": [ "11.2.2(c)", "11.5.2(c)" ], - "emea-deu-bsrit-2017": [ - "6.2" + "emea-deu-c5-2020": [ + "IDM-02" ], - "emea-isr-cmo-1-0": [ - "4.3", - "4.4", - "4.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 8.1" ], "emea-sau-cscc-1-2019": [ "2-2-1-7" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-10" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-32" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1", + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1", + "4-BP1", + "4-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2424" @@ -137550,9 +139670,18 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2424" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0441", - "ISM-0443" + "ISM-0443", + "ISM-1832", + "ISM-1834", + "ISM-1845", + "ISM-1940", + "ISM-1941", + "ISM-1942" + ], + "apac-aus-cop-sitc-2020": [ + "1" ], "apac-ind-sebi-2024": [ "PR.AA.S1" @@ -137568,7 +139697,10 @@ "9.2.1.6.PB", "9.2.4.9.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.56" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP38", "HML38" ], @@ -137576,6 +139708,15 @@ "HSUP33", "HSUP35" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.1" + ], + "apac-sgp-mas-trm-2021": [ + "9.1.8" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.A", "03.01.01.B", @@ -137585,6 +139726,7 @@ "03.01.01.D.02", "03.01.01.E", "03.01.01.F.01", + "03.01.01.F.02", "03.01.01.F.03", "03.01.01.F.04", "03.01.01.F.05", @@ -137594,7 +139736,8 @@ "03.01.02", "03.01.05.B", "03.01.05.C", - "03.01.05.D" + "03.01.05.D", + "03.05.07.E" ] } }, @@ -137603,7 +139746,7 @@ "title": "Automated System Account Management (Directory Services)", "family": "IAC", "description": "Automated mechanisms exist to support the management of system accounts (e.g., directory services).", - "scf_question": "Does the organization use automated mechanisms to support the management of system accounts?", + "scf_question": "Does the organization use automated mechanisms to support the management of system accounts (e.g., directory services)?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -137616,9 +139759,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically support the management of system accounts (e.g., directory services).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically support the management of system accounts (e.g., directory services). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -137687,14 +139830,15 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { "general-cis-csc-8-1": [ - "5.0", + "5", "5.6", - "6.0" + "6" ], "general-cis-csc-8-1-ig2": [ "5.6" @@ -137760,6 +139904,7 @@ "3.5.2" ], "general-nist-800-171-r3": [ + "03.01.01.d.01", "03.05.05.b", "03.05.05.c", "03.05.05.d", @@ -137771,6 +139916,33 @@ "03.05.12.e", "03.05.12.f" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.05.05.b[01]", + "A.03.05.05.b[02]", + "A.03.05.05.c", + "A.03.05.05.d", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.d", + "A.03.05.12.e", + "A.03.05.12.f[01]", + "A.03.05.12.f[02]" + ], + "general-nist-800-172-r3": [ + "03.01.07E", + "03.01.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]", + "DS-A.03.01.11E.a" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -137809,6 +139981,20 @@ "AC-2-IS.3", "AC-2(1)" ], + "emea-deu-c5-2020": [ + "IDM-03-BP2", + "IDM-08-BP2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP6" + ], "emea-gbr-def-stan-05-138-2024": [ "2209", "2218" @@ -137823,13 +140009,20 @@ "2209", "2218" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1649" ], "apac-jpn-ismap": [ "9.2.2.5" ], + "apac-sgp-mas-trm-2021": [ + "9.2.2" + ], + "americas-arg-ppd-2018": [ + "B.2.3-2" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.D.01", "03.05.05.B", "03.05.05.C", "03.05.05.D", @@ -137861,9 +140054,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable or remove temporary and emergency accounts after an organization-defined time period for each type of account.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable or remove temporary and emergency accounts after an organization-defined time period for each type of account. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -137930,7 +140123,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -137980,10 +140174,10 @@ "AC-02(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "AC-2(CE-2)" @@ -137991,12 +140185,9 @@ "usa-federal-cms-marse-2-0": [ "AC-2(2)" ], - "emea-deu-c5-2020": [ - "IDM-04", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.4" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ] } }, @@ -138018,9 +140209,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable inactive accounts after an organization-defined time period.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable inactive accounts after an organization-defined time period. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -138089,7 +140280,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -138205,20 +140397,23 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-02 (03)" ], - "emea-deu-c5-2020": [ - "IDM-03" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], - "emea-isr-cmo-1-0": [ - "4.5" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP3" ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1404", "ISM-1648" ], + "americas-arg-ppd-2018": [ + "B.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.F.02" ] @@ -138244,9 +140439,9 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically audit account creation, modification, enabling, disabling and removal actions and notify organization-defined personnel or roles.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically audit account creation, modification, enabling, disabling and removal actions and notify organization-defined personnel or roles. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -138309,7 +140504,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -138340,6 +140536,16 @@ "general-nist-800-82-r3-high": [ "AC-02(04)" ], + "general-nist-800-172-r3": [ + "03.01.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]" + ], "usa-federal-fbi-cjis-6-0": [ "AC-2(4)" ], @@ -138381,7 +140587,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to authorize the use of shared/group accounts only under certain organization-defined conditions.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -138449,7 +140655,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -138483,6 +140690,9 @@ "general-nist-800-171-r3": [ "03.01.01.c.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.c.01" + ], "general-pci-dss-4-0-1": [ "8.2.2" ], @@ -138530,14 +140740,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-02 (09)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(b)" + ], "emea-eu-nis2-annex-2024": [ "11.5.3" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" + ], "apac-nzl-ism-3-9": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.28.C.01", "16.1.33.C.01", - "16.1.33.C.02", "16.1.34.C.01" ], + "americas-arg-ppd-2018": [ + "B.2.3-8" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01" ] @@ -138561,7 +140782,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disable accounts immediately upon notification for users posing a significant risk to the organization.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -138633,7 +140854,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -138671,6 +140893,10 @@ "03.01.01.f.04", "03.01.01.f.05" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -138692,7 +140918,7 @@ "usa-federal-irs-1075-2021": [ "AC-2(CE-13)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1591" ], "americas-can-itsp-10-171-2025": [ @@ -138706,7 +140932,7 @@ "title": "System Account Reviews", "family": "IAC", "description": "Mechanisms exist to review all system accounts and disable any account that cannot be associated with a business process and owner.", - "scf_question": "Does the organization review all system accounts and disables any account that cannot be associated with a business process and owner?", + "scf_question": "Does the organization review all system accounts and disable any account that cannot be associated with a business process and owner?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -138721,11 +140947,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.\n▪ IAM inventories all privileged accounts and validates that each person with elevated privileges is authorized by the appropriate level of organizational management.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to review all system accounts and disable any account that cannot be associated with a business process and owner.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to review all system accounts and disable any account that cannot be associated with a business process and owner. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -138794,7 +141020,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -138803,18 +141030,15 @@ "CC6.2-POF3" ], "general-nist-800-171-r3": [ + "03.01.01.b", "03.01.01.e", "03.01.05.c" ], "general-nist-800-171a-r3": [ - "A.03.01.01.a[01]", - "A.03.01.01.a[02]", - "A.03.01.01.b[01]", - "A.03.01.01.b[02]", - "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.01.01.c.01" + "A.03.01.01.e", + "A.03.01.05.c" ], "general-pci-dss-4-0-1": [ "8.6", @@ -138838,16 +141062,11 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(a)(4)" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-sau-cgiot-2024": [ "1-8-2" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-2" - ], "americas-can-itsp-10-171-2025": [ + "03.01.01.B", "03.01.01.E", "03.01.05.C" ] @@ -138871,11 +141090,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically enforce usage conditions for users and/or roles.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -138956,7 +141175,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -139007,7 +141227,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to establish and control \"emergency access only\" accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -139093,7 +141313,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -139104,16 +141325,19 @@ "164.312(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" + ], + "emea-deu-c5-2020": [ + "IDM-09" ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1610", "ISM-1611", "ISM-1612", @@ -139123,6 +141347,103 @@ ] } }, + { + "control_id": "IAC-15.10", + "title": "Account Separation Between Infrastructure Environments", + "family": "IAC", + "description": "Mechanisms exist to separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "scf_question": "Does the organization separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Separate user accounts for production vs development environments\n∙ Role-based access restricting cross-environment access", + "small": "∙ Separate accounts per environment (dev, staging, prod)\n∙ Access restrictions preventing cross-environment access", + "medium": "∙ Separate cloud accounts or tenants per environment\n∙ AWS Organizations or Azure Management Groups for account separation\n∙ Privileged Access Management (PAM)", + "large": "∙ AWS Organizations, Azure Landing Zones, or GCP Organization policies for environment separation\n∙ PAM solution for privileged environment access\n∙ Zero Trust access between environments", + "enterprise": "∙ Enterprise cloud account separation via AWS Organizations or Azure Entra Tenants\n∙ Enterprise PAM (e.g., CyberArk, BeyondTrust)\n∙ Zero Trust architecture for cross-environment access\n∙ Automated account lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - (33 CFR Part 101 Subpart F)", + "family_name": "Identification & Authentication", + "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ] + } + }, { "control_id": "IAC-16", "title": "Privileged Account Management (PAM)", @@ -139147,7 +141468,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).\n▪ LAC and RBAC enforcements limit the ability of non-administrators from making unauthorized configuration changes to TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict and control privileged access rights for users and Technology Assets, Applications and/or Services (TAAS).", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -139235,7 +141556,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -139289,6 +141611,11 @@ "03.01.07.a", "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.01.07.b" + ], "general-pci-dss-4-0-1": [ "7.2.3", "7.2.5" @@ -139309,9 +141636,6 @@ "7.2.3", "7.2.5" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.2" ], @@ -139347,14 +141671,17 @@ "500.7(a)(3)", "500.7(c)(1)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(d)" + ], "emea-eu-nis2-annex-2024": [ "11.6.2(f)" ], "emea-deu-c5-2020": [ "IDM-06" ], - "emea-isr-cmo-1-0": [ - "4.2" + "emea-sau-cscc-1-2019": [ + "2-2-1-7" ], "emea-sau-cgiot-2024": [ "2-2-1" @@ -139362,12 +141689,17 @@ "emea-sau-ecc-1-2018": [ "2-2-3-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-34" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-caf-4-0": [ "B2.c" ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP6" + ], "emea-gbr-def-stan-05-138-2024": [ "2424" ], @@ -139382,7 +141714,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0445", "ISM-0446", "ISM-0447", @@ -139397,13 +141729,16 @@ "ISM-1650", "ISM-1687", "ISM-1688", - "ISM-1689" + "ISM-1689", + "ISM-1835", + "ISM-1939" ], "apac-ind-sebi-2024": [ "PR.AA.S11" ], "apac-jpn-ismap": [ "9.2.3", + "9.2.3.1", "9.2.3.2", "9.2.3.3", "9.2.3.4", @@ -139414,7 +141749,7 @@ "9.2.3.9", "9.2.3.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP41", "HML41" ], @@ -139423,24 +141758,15 @@ ], "apac-nzl-ism-3-9": [ "16.3.5.C.01", - "16.3.5.C.02", "16.3.6.C.01", "16.3.6.C.02", "16.3.7.C.01", - "16.4.30.C.01", - "16.4.30.C.02", - "16.4.30.C.03", - "16.4.31.C.01", - "16.4.31.C.02", - "16.4.32.C.01", - "16.4.32.C.02", - "16.4.33.C.01", - "16.4.34.C.01", - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03", "16.4.36.C.01", - "16.4.37.C.01" + "16.4.36.C.02", + "16.4.36.C.03", + "16.4.37.C.01", + "16.4.37.C.03", + "16.4.38.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.1" @@ -139448,13 +141774,18 @@ "apac-sgp-mas-trm-2021": [ "9.2.1" ], - "amaericas-can-osfi-self-assessment": [ - "4.23", - "4.24" + "americas-arg-ppd-2018": [ + "B.2.1-2", + "B.2.1-3", + "B.2.3-6", + "B.2.5-DS-2" ], "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.06.A", "03.01.07.A", @@ -139482,11 +141813,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -139555,7 +141886,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -139620,8 +141952,9 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(a)(4)" ], - "emea-sau-sacs-002-2022": [ - "TPC-34" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2424" @@ -139633,7 +141966,7 @@ "2424" ], "apac-nzl-ism-3-9": [ - "16.4.34.C.01" + "16.4.40.C.01" ] } }, @@ -139724,10 +142057,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ], "apac-nzl-ism-3-9": [ "23.3.18.C.01" ] @@ -139751,7 +142088,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure privilege change requests require additional levels of authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -139818,7 +142155,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -139849,7 +142187,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to assign dedicated privileged user accounts to be used solely for duties requiring privileged access.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -139912,17 +142250,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP5" + ], "apac-aus-essential-8-2024": [ "ML1-P4", "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-0445" + "apac-aus-ism-2026-march": [ + "ISM-0445", + "ISM-1827", + "ISM-1842" ] } }, @@ -139944,7 +142288,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enable a manual override of the current account privileges to enable the timely response to unusual conditions without terminating the current session and establishing a new session as a higher-privileged user.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -139974,9 +142318,9 @@ "MT-2", "MT-8", "MT-9", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (IEC 62443-4-2)", "family_name": "Identification & Authentication", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -140084,7 +142428,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -140160,9 +142505,12 @@ "03.10.01.d" ], "general-nist-800-171a-r3": [ + "A.03.01.01.g.03", "A.03.01.05.ODP[03]", "A.03.01.05.c", - "A.03.01.05.d" + "A.03.01.05.d", + "A.03.10.01.c", + "A.03.10.01.d" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -140214,10 +142562,10 @@ "AC-06(07)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "AC-6(CE-7)", @@ -140236,40 +142584,49 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-06 (07)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(e)", + "3.4.2.31(f)" + ], "emea-eu-nis2-annex-2024": [ "11.2.3", "11.3.3", "11.5.4" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-deu-c5-2020": [ - "IDM-05" + "IDM-01-BP4", + "IDM-05", + "IDM-05-DOAR", + "IDM-09-DOAR" ], - "emea-isr-cmo-1-0": [ - "4.3" + "emea-sau-cscc-1-2019": [ + "2-2-2" ], "emea-sau-cgiot-2024": [ "1-8-2", "2-2-3" ], "emea-sau-ecc-1-2018": [ - "1-9-5", "2-2-3-5" ], "emea-sau-otcc-1-2022": [ "2-2-1-10" ], "emea-sau-sacs-002-2022": [ - "TPC-33", - "TPC-34" + "VII.B.TPC-33" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0405", "ISM-1647", - "ISM-1648", - "ISM-1716" + "ISM-1648" ], "apac-ind-sebi-2024": [ "PR.AA.S5" @@ -140284,14 +142641,6 @@ "9.2.5.5", "9.2.5.6" ], - "apac-nzl-ism-3-9": [ - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03" - ], - "apac-sgp-mas-trm-2021": [ - "9.1.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.03", "03.01.05.C", @@ -140321,7 +142670,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -140390,7 +142739,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -140458,15 +142808,13 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (06)" ], - "emea-sau-cscc-1-2019": [ - "2-2-2" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0421", "ISM-0422" ], "apac-nzl-ism-3-9": [ - "16.4.37.C.01" + "16.4.37.C.01", + "16.4.38.C.02" ] } }, @@ -140557,7 +142905,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -140600,6 +142949,15 @@ "III.C.4", "III.C.4.a", "III.C.4.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "apac-nzl-ism-3-9": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.27.C.03" ] } }, @@ -140608,7 +142966,7 @@ "title": "Access Enforcement", "family": "IAC", "description": "Mechanisms exist to enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"", - "scf_question": "Does the organization enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege?\"", + "scf_question": "Does the organization enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -140621,7 +142979,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -140695,7 +143053,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -140746,7 +143105,7 @@ "general-iso-27018-2025": [ "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -141107,6 +143466,22 @@ "3.1.1[e]", "3.1.1[f]" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -141218,18 +143593,19 @@ "AC-03", "AC-06" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "apac-ind-sebi-2024": [ "PR.AA.S15" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP10", "HHSP40", "HML10", "HML40" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS07" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP09" ], @@ -141251,8 +143627,8 @@ "control_id": "IAC-20.1", "title": "Access To Sensitive / Regulated Data", "family": "IAC", - "description": "Mechanisms exist to limit access to sensitive/regulated data to only those individuals whose job requires such access.", - "scf_question": "Does the organization limit access to sensitive/regulated data to only those individuals whose job requires such access?", + "description": "Mechanisms exist to limit access to sensitive and/or regulated data to only those individuals whose job requires such access.", + "scf_question": "Does the organization limit access to sensitive and/or regulated data to only those individuals whose job requires such access?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -141265,11 +143641,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit access to sensitive/regulated data to only those individuals whose job requires such access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit access to sensitive/regulated data to only those individuals whose job requires such access. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -141353,7 +143729,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -141378,13 +143755,26 @@ "03.01.03", "03.01.04.b", "03.01.05.a", + "03.01.05.b", "03.06.05.d", "03.10.01.a" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", "A.03.01.05.b[01]", "A.03.01.05.b[02]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]" ], "general-nist-800-207": [ "NIST Tenet 3" @@ -141427,6 +143817,10 @@ "7.2.5", "7.2.6" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.03", "03.01.01.D.01", @@ -141435,6 +143829,7 @@ "03.01.03", "03.01.04.B", "03.01.05.A", + "03.01.05.B", "03.06.05.D", "03.10.01.A" ] @@ -141444,8 +143839,8 @@ "control_id": "IAC-20.2", "title": "Database Access", "family": "IAC", - "description": "Mechanisms exist to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", - "scf_question": "Does the organization restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access?", + "description": "Mechanisms exist to restrict access to databases containing sensitive and/or regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", + "scf_question": "Does the organization restrict access to databases containing sensitive and/or regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -141458,11 +143853,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -141544,7 +143939,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -141568,6 +143964,10 @@ ], "emea-sau-cscc-1-2019": [ "2-2-1-8" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ] } }, @@ -141589,7 +143989,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict and tightly control utility programs that are capable of overriding system and application controls.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -141659,7 +144059,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -141700,7 +144101,11 @@ "500.7(a)(5)" ], "emea-deu-c5-2020": [ - "IDM-06" + "IDM-12" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "apac-jpn-ismap": [ "9.4.4", @@ -141736,7 +144141,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict executing administrative tasks or tasks requiring elevated access to a dedicated machine.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -141822,7 +144227,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -141852,6 +144258,14 @@ ], "apac-aus-essential-8-2024": [ "ML3-P4" + ], + "apac-aus-ism-2026-march": [ + "ISM-1898" + ], + "americas-can-itsp-10-171-2025": [ + "03.01.06.C", + "03.14.08.A", + "03.14.08.C" ] } }, @@ -141873,7 +144287,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically enforce dual authorization for privileged commands.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -141958,7 +144372,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -141984,8 +144399,12 @@ "general-nist-800-160-vol-2-r1": [ "AC-03(02)" ], - "general-nist-800-172": [ - "3.1.1e" + "general-nist-800-172-r3": [ + "03.01.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" ], "usa-federal-gsa-fedramp-5-low": [ "AC-03(02)" @@ -142019,7 +144438,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM revokes user access rights in a timely manner, up on termination of employment or contract.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke logical and physical access authorizations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -142092,7 +144511,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -142239,7 +144659,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": {} @@ -142266,9 +144687,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -142341,7 +144762,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -142407,7 +144829,7 @@ "8.3", "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -142725,6 +145147,7 @@ "03.01.01.c.03", "03.01.01.d.01", "03.01.01.d.02", + "03.01.02", "03.01.04.b", "03.01.05.a", "03.01.05.b", @@ -142740,8 +145163,20 @@ "3.1.5[d]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", "A.03.01.02[02]", - "A.03.01.05.a" + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.03.08.a[02]", + "A.03.03.08.b", + "A.03.04.05[04]" ], "general-nist-800-207": [ "NIST Tenet 3" @@ -142806,9 +145241,6 @@ "7.3.3", "8.6.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0039" ], @@ -142855,16 +145287,19 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(5)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(1)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "AC-6" @@ -142895,8 +145330,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-06" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(a)" ], "emea-eu-dora-2023": [ "Article 9.4(c)" @@ -142908,15 +145343,13 @@ "11.3.2(c)", "11.3.2(d)" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-deu-c5-2020": [ - "IDM-07" - ], - "emea-isr-cmo-1-0": [ - "4.10", - "12.29" + "IDM-03-BP1", + "IDM-03-BP2", + "IDM-03-BP4", + "IDM-10", + "IDM-12", + "IDM-13" ], "emea-sau-cgiot-2024": [ "2-2-1" @@ -142924,13 +145357,23 @@ "emea-sau-otcc-1-2022": [ "2-3-1-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 17", - "Article 20" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-34" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.5" ], "emea-esp-decree-311-2022": [ - "17", - "20" + "Article 12(6)(h)", + "Article 20" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "2205", @@ -142953,7 +145396,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0441", "ISM-0611", "ISM-1380", @@ -142961,7 +145404,11 @@ "ISM-1705", "ISM-1706", "ISM-1707", - "ISM-1708" + "ISM-1708", + "ISM-1833" + ], + "apac-aus-cop-sitc-2020": [ + "6" ], "apac-ind-sebi-2024": [ "PR.AA.S3" @@ -142977,14 +145424,15 @@ "9.1.2.7", "9.1.2.8" ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], "apac-nzl-ism-3-9": [ "16.2.4.C.01", - "16.4.31.C.01", - "16.4.31.C.02", "23.4.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "9.1.1" + "9.1.7" ], "americas-can-osfi-b13-2022": [ "3.2.7" @@ -142993,6 +145441,7 @@ "03.01.01.C.03", "03.01.01.D.01", "03.01.01.D.02", + "03.01.02", "03.01.04.B", "03.01.05.A", "03.01.05.B", @@ -143092,7 +145541,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -143184,9 +145634,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prohibit privileged users from using privileged accounts, while performing non-security functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prohibit privileged users from using privileged accounts, while performing non-security functions. \n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -143256,7 +145706,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -143364,8 +145815,9 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-1175" + "apac-aus-ism-2026-march": [ + "ISM-1175", + "ISM-1883" ], "americas-can-itsp-10-171-2025": [ "03.01.06.B" @@ -143464,7 +145916,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -143521,7 +145974,8 @@ ], "general-nist-800-171a-r3": [ "A.03.01.06.ODP[01]", - "A.03.01.06.a" + "A.03.01.06.a", + "A.03.01.07.a" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -143573,11 +146027,18 @@ "emea-eu-nis2-annex-2024": [ "11.3.2(b)" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "apac-aus-essential-8-2024": [ "ML1-P4", "ML2-P4", "ML3-P4" ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.06.A", "03.01.07.A" @@ -143604,7 +146065,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM revokes user access rights following changes in personnel roles and duties, if no longer necessary or permitted.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to audit the execution of privileged functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to audit the execution of privileged functions. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -143674,7 +146135,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -143714,6 +146176,9 @@ "general-nist-800-171-r3": [ "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -143781,7 +146246,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -143851,7 +146316,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -143939,8 +146405,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2216" ], - "apac-aus-ism-2024-june": [ - "ISM-1592" + "apac-aus-ism-2026-march": [ + "ISM-1592", + "ISM-2048" ], "americas-can-itsp-10-171-2025": [ "03.01.07.A" @@ -143951,8 +146418,8 @@ "control_id": "IAC-21.6", "title": "Network Access to Privileged Commands", "family": "IAC", - "description": "Mechanisms exist to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs.", - "scf_question": "Does the organization authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs?", + "description": "Mechanisms exist to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive and/or regulated data is stored, transmitted and/or processed only for compelling operational needs.", + "scf_question": "Does the organization authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive and/or regulated data is stored, transmitted and/or processed only for compelling operational needs?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -143965,7 +146432,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -144033,7 +146500,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -144083,7 +146551,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically prevent applications from executing at higher privilege levels than the user's privileges.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically prevent applications from executing at higher privilege levels than the user's privileges. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -144148,7 +146616,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -144268,18 +146737,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { "general-cis-csc-8-1": [ - "4.1" + "4.10" ], "general-cis-csc-8-1-ig2": [ - "4.1" + "4.10" ], "general-cis-csc-8-1-ig3": [ - "4.1" + "4.10" ], "general-govramp": [ "AC-07" @@ -144316,7 +146786,7 @@ "general-iso-27018-2025": [ "8.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021", "T1021.001", "T1021.004", @@ -144407,6 +146877,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-07" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(1)" + ], "usa-federal-irs-1075-2021": [ "AC-7" ], @@ -144439,12 +146912,13 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(d)" ], - "emea-isr-cmo-1-0": [ - "4.14" - ], "emea-sau-cgiot-2024": [ "2-2-2" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" + ], "emea-gbr-def-stan-05-138-2024": [ "2214" ], @@ -144457,13 +146931,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2214" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1403" ], - "apac-nzl-ism-3-9": [ - "16.1.46.C.01", - "16.1.46.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.08.A", "03.01.08.B" @@ -144490,7 +146960,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit the number of concurrent sessions for each system account.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit the number of concurrent sessions for each system account. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -144558,7 +147028,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -144580,7 +147051,7 @@ "general-iec-62443-4-2-2019": [ "CR 2.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.002", "T1185", @@ -144601,17 +147072,22 @@ "general-nist-800-82-r3-high": [ "AC-10" ], + "general-nist-800-172-r3": [ + "03.01.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.04E", + "A.03.01.04E.ODP[01]", + "A.03.01.04E.ODP[02]" + ], "usa-federal-gsa-fedramp-5-high": [ "AC-10" ], "usa-federal-cms-marse-2-0": [ "AC-10" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "4.15" + "americas-arg-ppd-2018": [ + "B.2.5-DS-1" ] } }, @@ -144705,7 +147181,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -144750,7 +147227,7 @@ "CR 2.5(a)", "CR 2.5(b)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1563.002" ], @@ -144841,18 +147318,6 @@ "AC-02 (05)", "AC-11" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "4.16" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], "emea-gbr-def-stan-05-138-2024": [ "2408" ], @@ -144865,13 +147330,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2408" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0428" ], - "apac-nzl-ism-3-9": [ - "16.1.45.C.01", - "16.1.45.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.10.A", "03.01.10.B" @@ -144898,7 +147359,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement pattern-hiding displays to conceal information previously visible on the display during the session lock.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement pattern-hiding displays to conceal information previously visible on the display during the session lock. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -144968,7 +147429,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -145032,9 +147494,6 @@ "usa-federal-cms-marse-2-0": [ "AC-11(1)" ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], "americas-can-itsp-10-171-2025": [ "03.01.10.C" ] @@ -145060,7 +147519,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -145129,7 +147588,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -145148,7 +147608,7 @@ "general-iec-62443-3-3-2013": [ "SR 2.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1072", "T1185", @@ -145237,10 +147697,10 @@ "AC-12" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "AC-12" @@ -145258,19 +147718,14 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(e)" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0853" ], "apac-nzl-ism-3-9": [ "16.1.44.C.01" ], "americas-can-itsp-10-171-2025": [ + "03.01.01.H", "03.01.11", "03.07.05.C" ] @@ -145294,9 +147749,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a logout capability and display an explicit logout message to users indicating the reliable termination of the session.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a logout capability and display an explicit logout message to users indicating the reliable termination of the session. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -145362,7 +147817,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -145404,7 +147860,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify and document the supporting rationale for specific user actions that can be performed on a system without identification or authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -145472,7 +147928,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -145491,7 +147948,7 @@ "general-govramp-high": [ "AC-14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137.002" ], "general-nist-800-53-r4": [ @@ -145570,7 +148027,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement a reference monitor that is tamperproof, always-invoked, small enough to be subject to analysis / testing and the completeness of which can be assured.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -145638,7 +148095,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -145676,7 +148134,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to verify the identity of a user before issuing authenticators or modifying access permissions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -145750,11 +148208,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.002", "T1078.003", @@ -145779,8 +148238,20 @@ "IA-12" ], "general-nist-800-171-r3": [ - "03.05.12.a", - "03.05.12.c" + "03.05.12.a" + ], + "general-nist-800-171a-r3": [ + "A.03.05.12.a" + ], + "general-nist-800-172-r3": [ + "03.05.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.06E.a", + "DS-A.03.05.06E.b", + "DS-A.03.05.06E.c[01]", + "DS-A.03.05.06E.c[02]", + "DS-A.03.05.06E.c[03]" ], "general-nist-csf-2-0": [ "PR.AA-02" @@ -145819,20 +148290,22 @@ "IA-12" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12" ], + "emea-deu-c5-2020": [ + "IDM-08-BP1" + ], "apac-jpn-ismap": [ "7.1.1.4" ], "americas-can-itsp-10-171-2025": [ - "03.05.12.A", - "03.05.12.C" + "03.05.12.A" ] } }, @@ -145856,7 +148329,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure management approvals are required for new accounts or changes in permissions to existing accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -145945,7 +148418,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -145990,8 +148464,9 @@ "03.01.01.b", "03.05.05.a" ], - "general-scf-dpmp-2025": [ - "7.1" + "general-nist-800-171a-r3": [ + "A.03.01.01.b[02]", + "A.03.05.05.a" ], "general-tisax-6-0-3": [ "4.2.1" @@ -146001,10 +148476,10 @@ "ACCESS-2g" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-1)" @@ -146019,15 +148494,26 @@ "11.2.2(c)" ], "emea-deu-c5-2020": [ - "IDM-01", - "IDM-02" + "IDM-01-BP1", + "IDM-01-BP6", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-06", + "IDM-09", + "BEI-09" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0405" ], "apac-jpn-ismap": [ "9.2.2.1" ], + "americas-arg-ppd-2018": [ + "B.2.3-5" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.B", "03.05.05.A" @@ -146052,8 +148538,8 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM collects, validates and verifies identity evidence of a user.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require evidence of individual identification to be presented to the registration authority.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." @@ -146137,7 +148623,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -146169,10 +148656,10 @@ "IA-12(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-2)" @@ -146197,7 +148684,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that the presented identity evidence be validated and verified through organizational-defined methods of validation and verification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -146282,7 +148769,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -146314,10 +148802,10 @@ "IA-12(03)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-3)" @@ -146342,7 +148830,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that the validation and verification of identity evidence be conducted in person before a designated registration authority.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -146427,7 +148915,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -146481,7 +148970,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that a notice of proofing be delivered through an out-of-band channel to verify the user's address (physical or digital).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -146566,7 +149055,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -146617,7 +149107,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Attribute-Based Access Control (ABAC) for policy-driven, dynamic authorizations that supports the secure sharing of information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -146664,7 +149154,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -146674,6 +149165,15 @@ "general-mpa-csbp-5-3-1": [ "TS-1.8" ], + "general-nist-800-172-r3": [ + "03.01.09E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.09E.a[01]", + "DS-A.03.01.09E.a[02]", + "DS-A.03.01.09E.b", + "A.03.01.09E.ODP[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "1.2", "1.2.1", @@ -146692,6 +149192,12 @@ "2.3.3", "2.3.5", "2.4.2" + ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], + "apac-nzl-ism-3-9": [ + "16.1.31.C.06" ] } }, @@ -146700,7 +149206,7 @@ "title": "Real-Time Access Decisions", "family": "IAC", "description": "Automated mechanisms exist to utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources.", - "scf_question": "Does the organization utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources?", + "scf_question": "Does the organization use automated mechanisms to utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources?", "relative_weight": 3, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -146713,7 +149219,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -146758,7 +149264,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -146772,8 +149279,8 @@ "control_id": "IAC-29.2", "title": "Access Profile Rules", "family": "IAC", - "description": "Mechanisms exist to develop access profile rules for sensitive/regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes.", - "scf_question": "Does the organization develop access profile rules for sensitive/regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes?", + "description": "Mechanisms exist to develop access profile rules for sensitive and/or regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes.", + "scf_question": "Does the organization develop access profile rules for sensitive and/or regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -146833,7 +149340,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -146862,7 +149370,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Mutual Authentication (MA) where both sides of a communications channel verify the identity of the other party through certificate exchange.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -146888,9 +149396,9 @@ "MT-2", "MT-8", "MT-9", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (IEC 62443-2-1)", "family_name": "Identification & Authentication", "crosswalks": { "general-iec-62443-2-1-2024": [ @@ -147017,7 +149525,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -147049,7 +149558,7 @@ "4.1.3" ], "general-cis-csc-8-1": [ - "17.0", + "17", "17.5" ], "general-cis-csc-8-1-ig2": [ @@ -147182,6 +149691,12 @@ "general-nist-800-171a-r3": [ "A.03.06.01[01]" ], + "general-nist-800-172-r3": [ + "03.11.09E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.09E.ODP[02]" + ], "general-nist-csf-2-0": [ "GV.SC-08", "DE.AE", @@ -147205,9 +149720,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-shared-assessments-sig-2025": [ "J.4" ], @@ -147274,14 +149786,14 @@ "314.4(h)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "usa-federal-irs-1075-2021": [ "1.8.4", @@ -147335,18 +149847,8 @@ "IR-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60" ], "emea-eu-dora-2023": [ "Article 9.4(b)", @@ -147373,55 +149875,42 @@ "3.5.1", "4.3.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-eu-psd2-2015": [ + "95(1)" ], "emea-deu-bsrit-2017": [ "4.7" ], "emea-deu-c5-2020": [ - "SIM-01" + "UP-01-BP4", + "SIM-01", + "SIM-07" ], - "emea-isr-cmo-1-0": [ - "24.1" + "emea-qat-pdppl-2020": [ + "3.11.5" ], "emea-sau-ecc-1-2018": [ "2-13-1", "2-13-2", - "2-13-3", - "2-13-3-2", - "2-13-4" + "2-13-3-1" ], "emea-sau-otcc-1-2022": [ - "2-12", "2-12-1", "2-12-2" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88", - "TPC-89" + "VII.A.TPC-23" ], "emea-sau-sama-csf-1-2017": [ - "3.3.15" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.3", - "22" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1" + "3.3.15.1" ], "emea-esp-decree-311-2022": [ - "25.1" + "Article 8(4)", + "Article 12(6)(m)", + "Article 25(1)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.7 [OP.EXP.7]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7" ], "emea-uae-niaf-2023": [ "3.3", @@ -147430,6 +149919,9 @@ "emea-gbr-caf-4-0": [ "D1" ], + "emea-gbr-cap-1850-2020": [ + "D1" + ], "emea-gbr-def-stan-05-138-2024": [ "3105", "4104" @@ -147445,18 +149937,17 @@ "3105", "4104" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0137", "ISM-0576", "ISM-1609", "ISM-1618" ], "apac-aus-ps-cps-230-2023": [ - "32" + "16(d)" ], "apac-aus-ps-cps-234-2019": [ - "23", - "24" + "23" ], "apac-ind-sebi-2024": [ "RS.MA.S1" @@ -147475,6 +149966,11 @@ "16.1.1.11.P", "16.1.1.12.P" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.2", + "11.12" + ], "apac-nzl-ism-3-9": [ "7.1.7.C.01", "7.1.7.C.02", @@ -147483,37 +149979,28 @@ ], "apac-sgp-mas-trm-2021": [ "7.7.1", - "7.7.2", - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "7.7.4", - "7.7.5", - "7.7.6", - "7.7.7" + "7.7.2" + ], + "americas-arg-ppd-2018": [ + "E.1.2-11", + "G" ], "americas-bmu-mba-coc-2020": [ - "6.1", + "5.3-BP3", + "6.1-BP4", "6.3", "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], "americas-can-osfi-b13-2022": [ "2.7", "2.7.2", "3.3", "3.4.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.1", + "3.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.01" ] @@ -147539,7 +150026,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.\n▪ IT and/or cybersecurity personnel operate facilitate basic forensic investigations in the event of a suspected or confirmed security incident.\n▪ The IRP contains eDiscovery processes to support Federal Rules of Civil Procedure (FRCP) requirements for eDiscovery practices.\n▪ IT personnel support incident response operations by provisioning and deprovisioning incident responders with temporary emergency accounts.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to cover:\n(1) Preparation;\n(2) Automated event detection or manual incident report intake;\n(3) Analysis;\n(4) Containment;\n(5) Eradication; and\n(6) Recovery.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -147630,7 +150117,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -147667,7 +150155,7 @@ ], "general-cis-csc-8-1": [ "2.3", - "17.0", + "17", "17.1", "17.3", "17.4", @@ -147824,7 +150312,8 @@ "03.06.02.a", "03.06.02.b", "03.06.02.c", - "03.06.02.d" + "03.06.02.d", + "03.06.05.b" ], "general-nist-800-171a": [ "3.6.1[a]", @@ -147842,12 +150331,24 @@ "3.6.2[f]" ], "general-nist-800-171a-r3": [ + "A.03.03.04.b", "A.03.06.01[02]", "A.03.06.01[03]", "A.03.06.01[04]", "A.03.06.01[05]", "A.03.06.01[06]", - "A.03.06.02.b" + "A.03.06.02.a[01]", + "A.03.06.02.a[02]", + "A.03.06.02.b", + "A.03.06.02.c", + "A.03.06.02.d", + "A.03.06.05.b[01]" + ], + "general-nist-800-172-r3": [ + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.03E.ODP[02]" ], "general-nist-csf-2-0": [ "GV.SC-08", @@ -147883,10 +150384,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.5" ], - "general-scf-dpmp-2025": [ - "8.0", - "8.1" - ], "general-swift-cscf-2025": [ "6.1", "6.2", @@ -147959,6 +150456,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(4)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)", "248.30(a)(3)(i)", @@ -147975,14 +150475,14 @@ "314.4(h)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(6)(ii)", - "164.412", - "164.412(a)", - "164.412(b)", - "164.530(f)" + "§ 164.308(a)(6)(ii)", + "§ 164.412", + "§ 164.412(a)", + "§ 164.412(b)", + "§ 164.530(f)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(6)(ii)" + "§ 164.308(a)(6)(ii)" ], "usa-federal-irs-1075-2021": [ "IR-4" @@ -148034,18 +150534,18 @@ "IR-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60", + "3.5.1.60(a)", + "3.5.1.60(b)", + "3.5.1.60(c)", + "3.5.1.60(d)", + "3.5.1.60(d)(i)", + "3.5.1.60(d)(ii)", + "3.5.1.60(e)", + "3.5.1.60(f)", + "3.5.1.60(f)(i)", + "3.5.1.60(f)(ii)" ], "emea-eu-dora-2023": [ "Article 9.4(b)", @@ -148077,47 +150577,40 @@ "emea-deu-bsrit-2017": [ "4.7" ], - "emea-deu-c5-2020": [ - "SIM-02" - ], - "emea-isr-cmo-1-0": [ - "7.2", - "24.2" + "emea-isr-cmo-2-0": [ + "Appendix A, 12.1" ], "emea-sau-cgiot-2024": [ "2-12-2" ], - "emea-sau-ecc-1-2018": [ - "2-13-3-2" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-1", - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5", - "2-12-2-6", - "2-12-2-7", - "2-12-2-8" + "2-12-1-3", + "2-12-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88", - "TPC-89" + "VII.B.TPC-89" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1", - "Article 25.2", - "Article 33.4" + "emea-sau-sama-csf-1-2017": [ + "3.3.15.3", + "3.3.15.4", + "3.3.15.4.a", + "3.3.15.4.b", + "3.3.15.4.c", + "3.3.15.4.d", + "3.3.15.4.e", + "3.3.15.4.f", + "3.3.15.4.g", + "3.3.15.4.h", + "3.3.15.4.i", + "3.3.15.4.j" ], "emea-esp-decree-311-2022": [ - "25.1", - "25.2", - "33.4" + "Article 25(2)", + "Article 34(1)(a)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.7 [OP.EXP.7]", - "7.3.9 [OP.EXP.9]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7", + "op.exp.9" ], "emea-uae-niaf-2023": [ "3.3.1", @@ -148126,6 +150619,9 @@ "emea-gbr-caf-4-0": [ "D1.b" ], + "emea-gbr-cap-1850-2020": [ + "D1" + ], "emea-gbr-def-stan-05-138-2024": [ "3105", "4104" @@ -148151,25 +150647,22 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0123", "ISM-0141", "ISM-0917", "ISM-1618", - "ISM-1803" - ], - "apac-aus-ps-cps-230-2023": [ - "32" + "ISM-1803", + "ISM-1819" ], "apac-aus-ps-cps-234-2019": [ - "23", - "24" + "23" + ], + "apac-chn-data-security-law-2021": [ + "Article 29" ], "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "Article 57" ], "apac-ind-sebi-2024": [ "RS.MA.S2" @@ -148197,7 +150690,13 @@ "16.1.3.2", "16.1.5.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.35", + "11.3", + "11.11" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP07", "HML07" ], @@ -148206,20 +150705,30 @@ ], "apac-nzl-ism-3-9": [ "5.7.4.C.01", - "7.2.17.C.01", - "7.2.17.C.02", "7.2.18.C.01", + "7.2.18.C.02", "7.2.19.C.01", "7.3.9.C.01", - "7.3.10.C.01" + "7.3.10.C.01", + "20.1.25.C.02" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(2)" ], "apac-sgp-mas-trm-2021": [ + "7.7.2", + "7.7.3", "7.7.3(a)", "7.7.3(b)", "7.7.3(c)" ], - "americas-bra-lgpd-2018": [ - "48" + "americas-arg-ppd-2018": [ + "E.1.2-10", + "E.1.2-11", + "G.1.1-1" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7", @@ -148231,13 +150740,21 @@ "3.4.3", "3.4.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.1", + "2.7.2", + "2.7.3", + "3", + "3.4.1" + ], "americas-can-itsp-10-171-2025": [ "03.03.04.B", "03.06.01", "03.06.02.A", "03.06.02.B", "03.06.02.C", - "03.06.02.D" + "03.06.02.D", + "03.06.05.B" ] } }, @@ -148259,9 +150776,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically support the incident handling process.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically support the incident handling process. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -148342,7 +150859,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -148413,9 +150931,6 @@ ], "emea-eu-dora-2023": [ "Article 9.4(b)" - ], - "emea-isr-cmo-1-0": [ - "24.4" ] } }, @@ -148437,9 +150952,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to implement and govern an insider threat program.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to implement and govern an insider threat program. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -148519,7 +151034,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -148573,7 +151089,7 @@ "usa-federal-irs-1075-2021": [ "IR-4(CE-6)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ] @@ -148599,7 +151115,7 @@ "0": "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.", "1": "Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically dynamically reconfigure system components as part of the incident response capability.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically dynamically reconfigure system components as part of the incident response capability. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -148639,7 +151155,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -148689,7 +151206,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -148775,7 +151292,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -148869,6 +151387,11 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "IR-08-SID" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(5)", + "Article 14(5)(a)", + "Article 14(5)(b)" + ], "emea-eu-nis2-2022": [ "Article 23.3", "Article 23.3(a)", @@ -148879,11 +151402,18 @@ "3.4.1", "3.4.2(a)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 33.4" + "emea-deu-bsrit-2017": [ + "4.7" ], - "emea-esp-decree-311-2022": [ - "33.4" + "emea-deu-c5-2020": [ + "SIM-03", + "SIM-07" + ], + "emea-isr-cmo-2-0": [ + "Appendix B" + ], + "emea-sau-ecc-1-2018": [ + "2-13-3-2" ], "apac-ind-sebi-2024": [ "RS.AN.S2" @@ -148893,9 +151423,16 @@ "16.1.4.1", "16.1.4.2" ], + "americas-bmu-mba-coc-2020": [ + "6.4" + ], "americas-can-osfi-b13-2022": [ "2.7", "3.4.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2", + "3.4.2" ] } }, @@ -148919,9 +151456,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate with approved third-parties to achieve a cross-organization perspective on incident awareness and more effective incident responses.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate with approved third-parties to achieve a cross-organization perspective on incident awareness and more effective incident responses. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -149005,7 +151542,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -149036,9 +151574,6 @@ "usa-federal-irs-1075-2021": [ "IR-4(CE-8)" ], - "emea-deu-c5-2020": [ - "OPS-21" - ], "apac-ind-sebi-2024": [ "GV.SC.S6", "RS.CO.S3", @@ -149046,9 +151581,6 @@ ], "apac-nzl-ism-3-9": [ "7.3.10.C.01" - ], - "amaericas-can-osfi-self-assessment": [ - "3.6" ] } }, @@ -149113,7 +151645,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -149143,10 +151676,6 @@ ], "emea-eu-dora-2023": [ "Article 9.4(b)" - ], - "amaericas-can-osfi-self-assessment": [ - "4.13", - "4.15" ] } }, @@ -149170,7 +151699,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to define specific Indicators of Compromise (IOC) to identify the signs of potential cybersecurity events.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -149235,7 +151764,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -149254,6 +151784,20 @@ "general-nist-800-171-r2": [ "3.14.7" ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.02.01E", + "03.11.02E", + "03.11.09E", + "03.14.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.08E.ODP[01]", + "A.03.02.01E.ODP[01]", + "DS-A.03.11.02E.a.01[01]", + "A.03.11.09E.ODP[01]", + "A.03.14.17E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.CM" ], @@ -149290,8 +151834,8 @@ "emea-deu-bsrit-2017": [ "5.4" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-12" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-80" ], "emea-gbr-caf-4-0": [ "C1.f" @@ -149308,13 +151852,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3201" ], - "apac-nzl-ism-3-9": [ - "7.2.17.C.01", - "7.2.17.C.02" + "apac-sgp-mas-trm-2021": [ + "11.3.5" ], "americas-can-osfi-b13-2022": [ "2.7.2", "3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ] } }, @@ -149338,7 +151884,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain and make available a current and viable Incident Response Plan (IRP) to all stakeholders.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -149429,7 +151975,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -149603,9 +152150,11 @@ "03.06.05.a.04", "03.06.05.a.05", "03.06.05.a.06", - "03.06.05.b" + "03.06.05.b", + "03.06.05.d" ], "general-nist-800-171a-r3": [ + "A.03.06.01[01]", "A.03.06.02.ODP[01]", "A.03.06.02.ODP[02]", "A.03.06.05.a.01", @@ -149665,9 +152214,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.10.1" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-swift-cscf-2025": [ "7.1" ], @@ -149710,6 +152256,10 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-08" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(6)", + "101.650(g)(2)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)" ], @@ -149791,18 +152341,8 @@ "IR-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60" ], "emea-eu-dora-2023": [ "Article 17.1", @@ -149821,38 +152361,28 @@ "3.5.1", "6.10.2(d)" ], - "emea-isr-cmo-1-0": [ - "7.2", - "24.2", - "24.3", - "24.8", - "24.9" + "emea-deu-c5-2020": [ + "SIM-03" ], "emea-sau-cgiot-2024": [ "2-12-1", "2-12-2" ], "emea-sau-ecc-1-2018": [ - "2-13-3-1", - "2-13-3-2" + "2-13-3-1" ], "emea-sau-otcc-1-2022": [ - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5" + "2-12-1-1", + "2-12-1-3", + "2-12-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1", - "Article 25.2" + "VII.A.TPC-23-BP2", + "VII.B.TPC-88" ], - "emea-esp-decree-311-2022": [ - "25.1", - "25.2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7", + "op.exp.9" ], "emea-gbr-caf-4-0": [ "D1.a" @@ -149869,27 +152399,21 @@ "4101", "4102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0043", "ISM-0576", "ISM-0917", "ISM-1784" ], "apac-aus-ps-cps-234-2019": [ - "23", "24", + "25", "25(a)", "25(b)" ], "apac-chn-cybersecurity-law-2017": [ "Article 25" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], "apac-ind-sebi-2024": [ "DE.DP.S2", "GV.RM.S3", @@ -149907,12 +152431,14 @@ "16.1.5.7", "16.1.5.8" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HHSP07", - "HML07" + "apac-mys-bnm-rmit-2025": [ + "10.20", + "11.3", + "11.13" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS20" + "HHSP07", + "HML07" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP07" @@ -149926,32 +152452,22 @@ "7.3.5.C.01", "7.3.9.C.01", "7.3.10.C.01", - "16.1.47.C.01" + "16.4.39.C.02", + "16.4.42.C.01" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(2)", + "6A.26C(4)" ], "apac-sgp-mas-trm-2021": [ - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "12.3.1", - "12.3.2", - "12.3.3" + "12.3.1" ], - "apac-kor-pipa-2011": [ - "34" + "americas-arg-ppd-2018": [ + "G.1.1-1" ], "americas-bmu-mba-coc-2020": [ "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], "americas-can-osfi-b13-2022": [ "2.7.1", "2.7.2", @@ -149966,7 +152482,8 @@ "03.06.05.A.04", "03.06.05.A.05", "03.06.05.A.06", - "03.06.05.B" + "03.06.05.B", + "03.06.05.D" ] } }, @@ -149988,9 +152505,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address data breaches, or other incidents involving the unauthorized disclosure of sensitive or regulated data, according to applicable laws, regulations and contractual obligations.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address data breaches, or other incidents involving the unauthorized disclosure of sensitive or regulated data, according to applicable laws, regulations and contractual obligations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -150056,7 +152573,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -150104,32 +152622,29 @@ "general-nist-800-82-r3": [ "IR-08(01)" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "usa-federal-fbi-cjis-6-0": [ "IR-8(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.404(a)(1)", - "164.404(a)(2)", - "164.404(c)(1)(A)", - "164.404(c)(1)(B)", - "164.404(c)(1)(C)", - "164.404(c)(1)(D)", - "164.404(c)(1)(E)", - "164.404(c)(2)", - "164.404(d)(1)(i)", - "164.404(d)(1)(ii)", - "164.404(d)(2)", - "164.404(d)(2)(i)", - "164.404(d)(2)(ii)(A)", - "164.404(d)(2)(ii)(B)", - "164.404(d)(3)", - "164.406(a)", - "164.406(b)", - "164.406(c)", - "164.410(c)(1)" + "§ 164.404(a)(1)", + "§ 164.404(a)(2)", + "§ 164.404(c)(1)(A)", + "§ 164.404(c)(1)(B)", + "§ 164.404(c)(1)(C)", + "§ 164.404(c)(1)(D)", + "§ 164.404(c)(1)(E)", + "§ 164.404(c)(2)", + "§ 164.404(d)(1)(i)", + "§ 164.404(d)(1)(ii)", + "§ 164.404(d)(2)", + "§ 164.404(d)(2)(i)", + "§ 164.404(d)(2)(ii)(A)", + "§ 164.404(d)(2)(ii)(B)", + "§ 164.404(d)(3)", + "§ 164.406(a)", + "§ 164.406(b)", + "§ 164.406(c)", + "§ 164.410(c)(1)" ], "usa-federal-irs-1075-2021": [ "IR-8(CE-1)", @@ -150140,78 +152655,25 @@ "emea-eu-gdpr-2016": [ "Article 33.1" ], - "emea-deu-c5-2020": [ - "SIM-02" - ], - "emea-ken-pda-2019": [ - "43(1)(b)", - "43(2)", - "43(3)", - "43(4)", - "43(5)", - "43(5)(a)", - "43(5)(b)", - "43(5)(c)", - "43(5)(d)", - "43(5)(e)", - "43(6)", - "43(7)", - "43(8)(a)", - "43(8)(b)", - "43(8)(c)" - ], - "emea-qat-pdppl-2020": [ - "14" + "emea-deu-fdpa-2017": [ + "3.4.65(1)", + "3.4.65(2)" ], "emea-sau-pdpl-2023": [ "Article 20.1", "Article 20.2" ], - "emea-srb-act-9-2018": [ - "53", - "53.1", - "53.2", - "53.3" - ], - "emea-zaf-popia-2013": [ - "22" - ], - "emea-che-fadp-2025": [ - "12" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], "apac-ind-dpdpa-2023": [ "8(6)" ], - "apac-jpn-ppi-2020": [ - "22-2(1)", - "22-2(2)" - ], - "apac-phl-dpa-2012": [ - "38" - ], "apac-kor-pipa-2011": [ - "34" - ], - "apac-twn-pdpa-2025": [ - "12" - ], - "americas-bra-lgpd-2018": [ - "48" + "IV.34(2)" ], - "americas-mex-fdpa-2010": [ - "20" + "americas-bhs-dpa-2003": [ + "V.48(1)" ] } }, @@ -150235,7 +152697,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ On at least an annual basis, IT and/or cybersecurity personnel update incident response strategies to keep current with business needs, technology changes and regulatory requirements.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to regularly review and modify incident response practices to incorporate lessons learned, business process changes and industry developments, as necessary.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -150308,7 +152770,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -150379,7 +152842,6 @@ "NFO - IR-1" ], "general-nist-800-171-r3": [ - "03.06.04.b", "03.06.05.c" ], "general-nist-800-171a-r3": [ @@ -150453,14 +152915,10 @@ "EV.ST.S3", "RS.IM.S2" ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-osfi-b13-2022": [ "2.7.3" ], "americas-can-itsp-10-171-2025": [ - "03.06.04.B", "03.06.05.C" ] } @@ -150470,7 +152928,7 @@ "title": "Continuous Incident Response Improvements", "family": "IRO", "description": "Mechanisms exist to use qualitative and quantitative data from incident response testing to: \n(1) Determine the effectiveness of incident response processes;\n(2) Continuously improve incident response processes; and\n(3) Provide incident response measures and metrics that are accurate, consistent and in a reproducible format.", - "scf_question": "Does the organization use qualitative and quantitative data from incident response testing to: \n (1) Determine the effectiveness of incident response processes;\n (2) Continuously improve incident response processes; and\n (3) Provide incident response measures and metrics that are accurate, consistent, and in a reproducible format?", + "scf_question": "Does the organization use qualitative and quantitative data from incident response testing to: \n(1) Determine the effectiveness of incident response processes;\n(2) Continuously improve incident response processes; and\n(3) Provide incident response measures and metrics that are accurate, consistent and in a reproducible format?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -150554,7 +153012,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -150571,6 +153030,9 @@ "general-nist-800-171-r3": [ "03.06.04.b" ], + "general-nist-800-171a-r3": [ + "A.03.06.04.b[03]" + ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.S" ], @@ -150580,9 +153042,16 @@ "IR-3(CE-3).b", "IR-3(CE-3).c" ], + "emea-gbr-cap-1850-2020": [ + "D2" + ], "apac-jpn-ismap": [ "16.1.1.14" ], + "apac-sgp-mas-trm-2021": [ + "7.8.3", + "12.3.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.04.B" ] @@ -150609,7 +153078,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders are proficient on their specific IRP role(s) and responsibilities through recurring training events (e.g., annual rock drill).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to train personnel in their incident response roles and responsibilities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -150681,7 +153150,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -150756,15 +153226,8 @@ "03.06.04.a.03" ], "general-nist-800-171a-r3": [ - "A.03.06.04.ODP[01]", - "A.03.06.04.ODP[02]", - "A.03.06.04.ODP[03]", - "A.03.06.04.ODP[04]", "A.03.06.04.a.01", - "A.03.06.04.b[01]", - "A.03.06.04.b[02]", - "A.03.06.04.b[03]", - "A.03.06.04.b[04]" + "A.03.06.04.a.03" ], "general-pci-dss-4-0-1": [ "12.10.4", @@ -150827,22 +153290,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-02" ], - "emea-isr-cmo-1-0": [ - "24.10", - "24.11" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-6" + "2-12-1-6" ], - "emea-sau-sacs-002-2022": [ - "TPC-88" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], "apac-ind-sebi-2024": [ "RS.IM.S2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" - ], "americas-can-itsp-10-171-2025": [ "03.06.04.A", "03.06.04.A.03" @@ -150867,7 +153324,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate simulated events into incident response training to facilitate effective response by personnel in crisis situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -150939,7 +153396,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -150975,9 +153433,6 @@ ], "usa-federal-irs-1075-2021": [ "IR-2(CE-1)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" ] } }, @@ -151066,7 +153521,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -151116,7 +153572,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders are proficient on their specific IRP role(s) and responsibilities through recurring training events (e.g., annual rock drill).\n▪ On at least an annual basis, IT and/or cybersecurity personnel conduct tabletop exercises to validate disaster recovery and contingency plans, in conjunction with stakeholders and any required vendors.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to formally test incident response capabilities through realistic exercises to determine the operational effectiveness of those capabilities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -151188,7 +153644,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -151295,9 +153752,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.2" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-swift-cscf-2025": [ "7.1" ], @@ -151322,6 +153776,21 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(a)(1)", + "101.635(b)(1)", + "101.635(b)(2)", + "101.635(b)(3)", + "101.635(c)(1)", + "101.635(c)(2)", + "101.635(c)(2)(i)", + "101.635(c)(2)(ii)", + "101.635(c)(2)(iii)", + "101.635(c)(2)(iv)", + "101.635(c)(3)", + "101.635(c)(4)", + "101.635(c)(5)" + ], "usa-federal-irs-1075-2021": [ "IR-3" ], @@ -151351,13 +153820,11 @@ "emea-eu-nis2-annex-2024": [ "3.5.5" ], - "emea-isr-cmo-1-0": [ - "24.10", - "24.11", - "24.12" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-7" + "2-12-1-7" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-gbr-caf-4-0": [ "D1.c" @@ -151374,19 +153841,42 @@ "4103", "4105" ], + "apac-aus-ism-2026-march": [ + "ISM-2006" + ], + "apac-aus-ps-cps-230-2023": [ + "27(c)" + ], "apac-aus-ps-cps-234-2019": [ - "26" + "26", + "27", + "27(a)", + "27(b)", + "27(c)", + "27(d)", + "27(e)" ], "apac-ind-sebi-2024": [ "DE.DP.S2", "GV.RM.S3" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-mys-bnm-rmit-2025": [ + "11.16" + ], + "apac-sgp-mas-trm-2021": [ + "13.3.1", + "13.3.2", + "13.5.2" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" + ], "americas-can-itsp-10-171-2025": [ "03.06.03" ] @@ -151412,9 +153902,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ On at least an annual basis, IT and/or cybersecurity personnel conduct tabletop exercises to validate disaster recovery and contingency plans, in conjunction with stakeholders and any required vendors.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate incident response testing with organizational elements responsible for related plans.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate incident response testing with organizational elements responsible for related plans. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -151500,7 +153990,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -151552,20 +154043,27 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-03(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(a)(1)" + ], "usa-federal-irs-1075-2021": [ "IR-3(CE-2)" ], "usa-state-tx-txramp-2-0-level-2": [ "IR-03 (02)" ], - "emea-sau-otcc-1-2022": [ - "2-12-2-8" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-mys-bnm-rmit-2025": [ + "11.3" ], "americas-can-osfi-b13-2022": [ "3.4.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ] } }, @@ -151590,7 +154088,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to establish an integrated team of cybersecurity, IT and business function representatives that are capable of addressing cybersecurity and data protection incident response operations.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -151679,7 +154177,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -151749,12 +154248,22 @@ "general-nist-800-161-r1-level-3": [ "IR-4(11)" ], + "general-nist-800-171-r3": [ + "03.06.02.b", + "03.06.02.d" + ], "general-nist-800-171a-r3": [ "A.03.06.02.b", "A.03.06.02.d" ], - "general-nist-800-172": [ - "3.6.2e" + "general-nist-800-172-r3": [ + "03.06.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.02E[01]", + "A.03.06.02E.ODP[01]", + "DS-A.03.06.02E[02]", + "DS-A.03.06.02E[03]" ], "general-nist-csf-2-0": [ "DE.AE-06", @@ -151778,9 +154287,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.3" ], - "general-scf-dpmp-2025": [ - "8.1" - ], "general-tisax-6-0-3": [ "1.6.3" ], @@ -151802,10 +154308,6 @@ "usa-federal-sec-cybersecurity-rule-2023": [ "Form 8-K Item 1.05(a)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)" - ], "emea-eu-dora-2023": [ "Article 14.1", "Article 14.2", @@ -151817,49 +154319,44 @@ "3.5.3(a)", "4.3.3" ], - "emea-isr-cmo-1-0": [ - "24.7", - "24.9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-89" + "emea-sau-otcc-1-2022": [ + "2-12-1-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 33.3" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.9" ], - "emea-esp-decree-311-2022": [ - "33.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0733", "ISM-1618" ], - "apac-aus-ps-cps-234-2019": [ - "23", - "24", - "25(a)", - "25(b)" + "apac-mys-bnm-rmit-2025": [ + "11.13", + "11.14" ], "apac-nzl-ism-3-9": [ "7.2.18.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.7.5" + "7.7.5", + "7.7.6" ], - "amaericas-can-osfi-self-assessment": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" + "americas-arg-ppd-2018": [ + "G.1.1-2" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7.2", "3.3.3", "3.4.4" + ], + "americas-can-osfi-self-assessment-2": [ + "3.4.4" + ], + "americas-can-itsp-10-171-2025": [ + "03.06.02.B", + "03.06.02.D" ] } }, @@ -151884,7 +154381,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to perform digital forensics and maintain the integrity of the chain of custody, in accordance with applicable laws, regulations and industry-recognized secure practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -151975,7 +154472,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -152053,10 +154551,10 @@ "CIP-009-6 1.5" ], "emea-deu-c5-2020": [ - "SIM-03" + "SIM-01-DOAR" ], - "emea-sau-sacs-002-2022": [ - "TPC-89" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.9" ], "emea-gbr-def-stan-05-138-2024": [ "3104" @@ -152067,7 +154565,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3104" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0137", "ISM-0138", "ISM-1609", @@ -152093,7 +154591,7 @@ "16.1.7.12", "16.1.7.13.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP74", "HML74" ], @@ -152105,6 +154603,9 @@ ], "americas-can-osfi-b13-2022": [ "3.4.5" + ], + "americas-can-osfi-self-assessment-2": [ + "3.4.5" ] } }, @@ -152163,9 +154664,9 @@ "MT-6", "MT-8", "MT-9", - "MT-11" + "MT-11", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Incident Response", "crosswalks": {} }, @@ -152189,7 +154690,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to document, monitor and report the status of cybersecurity and data protection incidents to internal stakeholders all the way through the resolution of the incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -152279,7 +154780,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -152386,7 +154888,8 @@ ], "general-nist-800-171a-r3": [ "A.03.06.02.a[01]", - "A.03.06.02.a[02]" + "A.03.06.02.a[02]", + "A.03.06.02.b" ], "general-nist-csf-2-0": [ "DE.AE-06", @@ -152430,10 +154933,10 @@ "314.4(h)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "IR-5" @@ -152453,10 +154956,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-05" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(ii)" - ], "emea-eu-gdpr-2016": [ "Article 33.5" ], @@ -152465,33 +154964,25 @@ "3.5.4", "6.10.2(a)" ], - "emea-isr-cmo-1-0": [ - "24.5" - ], - "emea-sau-sacs-002-2022": [ - "TPC-89", - "TPC-90" + "emea-deu-c5-2020": [ + "SIM-07" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.2" + "emea-isr-cmo-2-0": [ + "Appendix A, 13.1" ], - "emea-esp-decree-311-2022": [ - "25.2" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-90" ], "emea-uae-niaf-2023": [ "3.3.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0125", "ISM-0137", "ISM-0733", "ISM-1609", "ISM-1803" ], - "apac-aus-ps-cps-234-2019": [ - "23", - "24" - ], "apac-ind-dpdpa-2023": [ "8(6)" ], @@ -152503,9 +154994,6 @@ "7.3.6.C.01", "7.3.6.C.02" ], - "apac-sgp-mas-trm-2021": [ - "7.7.5" - ], "americas-can-osfi-b13-2022": [ "2.7" ], @@ -152533,11 +155021,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically assist in the tracking, collection and analysis of information from actual and potential cybersecurity and data protection incidents.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -152617,7 +155105,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -152642,11 +155131,19 @@ "general-nist-800-82-r3-high": [ "IR-05(01)" ], + "general-nist-800-172-r3": [ + "03.06.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.04E[01]", + "A.03.06.04E.ODP[01]", + "DS-A.03.06.04E[02]", + "A.03.06.04E.ODP[02]", + "DS-A.03.06.04E[03]", + "A.03.06.04E.ODP[03]" + ], "usa-federal-gsa-fedramp-5-high": [ "IR-05(01)" - ], - "emea-isr-cmo-1-0": [ - "24.5" ] } }, @@ -152753,7 +155250,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -152783,7 +155281,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain a repository of cybersecurity events and incidents that documents:\n(1) Details of the incident (e.g., category, severity, affected parties, etc.);\n(2) Remediation actions taken through incident closure; and\n(3) A summary from the Root Cause Analysis (RCA), if applicable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -152817,9 +155315,9 @@ "MT-5", "MT-6", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Incident Response", "crosswalks": { "usa-federal-doe-c2m2-2-1": [ @@ -152851,7 +155349,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to analyze historical incidents in aggregate to identify:\n(1) Patterns;\n(2) Trends; and \n(3) Other common root causes in order to address the vulnerability and risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -152883,9 +155381,9 @@ "MT-5", "MT-6", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Incident Response", "crosswalks": { "usa-federal-doe-c2m2-2-1": [ @@ -152915,7 +155413,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to timely-report incidents to applicable:\n(1) Internal stakeholders; \n(2) Affected clients & third-parties; and\n(3) Regulatory authorities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -152995,7 +155493,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -153069,7 +155568,7 @@ "6.8" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-iso-42001-2023": [ "A.8.3", @@ -153120,7 +155619,8 @@ ], "general-nist-800-171-r3": [ "03.06.02.b", - "03.06.02.c" + "03.06.02.c", + "03.06.02.d" ], "general-nist-800-171a-r3": [ "A.03.06.02.ODP[01]", @@ -153172,9 +155672,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.10.1" ], - "general-scf-dpmp-2025": [ - "8.2" - ], "general-tisax-6-0-3": [ "1.6.2" ], @@ -153204,6 +155701,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(10)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)(iii)", "248.30(a)(4)(i)", @@ -153226,10 +155726,10 @@ "314.4(h)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.404(b)", - "164.408(a)", - "164.408(b)", - "164.408(c)" + "§ 164.404(b)", + "§ 164.408(a)", + "§ 164.408(b)", + "§ 164.408(c)" ], "usa-federal-irs-1075-2021": [ "IR-6" @@ -153293,6 +155793,19 @@ "12(e)(C)", "12(e)(D)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.220.1", + "603A.220.2", + "603A.220.3", + "603A.220.4", + "603A.220.4(a)", + "603A.220.4(b)", + "603A.220.4(c)", + "603A.220.4(c)(1)", + "603A.220.4(c)(2)", + "603A.220.4(c)(3)", + "603A.220.6" + ], "usa-state-nv-regulation-5-2024": [ "5.260.4(a)", "5.260.4(c)" @@ -153369,8 +155882,13 @@ "emea-eu-ai-act-2024": [ "Article 17.1(j)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(8)", + "Article 15(1)", + "Article 15(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 14.1", @@ -153408,16 +155926,57 @@ "3.1.2(b)", "13.2.2(c)" ], + "emea-eu-psd2-2015": [ + "96(1)" + ], + "emea-aut-dpa-2018": [ + "§ 55(1)", + "§ 55(2)", + "§ 56(1)", + "§ 56(2)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 4, Art. 61(1)", + "Title 2, Chapter IV, Section 4, Art. 61(2)", + "Title 2, Chapter IV, Section 4, Art. 61(3)", + "Title 2, Chapter IV, Section 4, Art. 61(4)", + "Title 2, Chapter IV, Section 4, Art. 61(5)", + "Title 2, Chapter IV, Section 4, Art. 61(6)", + "Title 2, Chapter IV, Section 4, Art. 62(1)", + "Title 2, Chapter IV, Section 4, Art. 62(2)", + "Title 2, Chapter IV, Section 4, Art. 62(3)", + "Title 2, Chapter IV, Section 4, Art. 62(4)", + "Title 2, Chapter IV, Section 4, Art. 62(5)" + ], + "emea-deu-fdpa-2017": [ + "3.4.66(1)", + "3.4.66(2)" + ], "emea-deu-c5-2020": [ - "SIM-03", + "RB-20", "SIM-04" ], - "emea-isr-cmo-1-0": [ - "24.6", - "24.8" + "emea-irl-dpa-2018": [ + "s.85", + "s.86" ], - "emea-qat-pdppl-2020": [ - "14" + "emea-ken-pda-2019": [ + "IV.43(1)(b)", + "IV.43(2)", + "IV.43(3)", + "IV.43(4)", + "IV.43(5)", + "IV.43(5)(a)", + "IV.43(5)(b)", + "IV.43(5)(c)", + "IV.43(5)(d)", + "IV.43(5)(e)", + "IV.43(6)", + "IV.43(7)", + "IV.43(8)", + "IV.43(8)(a)", + "IV.43(8)(b)", + "IV.43(8)(c)" ], "emea-sau-cgiot-2024": [ "2-12-2" @@ -153427,27 +155986,91 @@ "2-13-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-89" + "VII.A.TPC-23-BP1" ], - "emea-zaf-popia-2013": [ - "22" + "emea-srb-act-9-2018": [ + "IV.2.52", + "IV.2.52(1)", + "IV.2.52(2)", + "IV.2.52(3)", + "IV.2.52(4)", + "IV.2.53" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.2", - "Article 33.2", - "Article 33.4", - "Article 33.7" + "emea-zaf-popia-2013": [ + "3.A.7.22(1)", + "3.A.7.22(1)(a)", + "3.A.7.22(1)(b)", + "3.A.7.22(2)", + "3.A.7.22(3)", + "3.A.7.22(4)", + "3.A.7.22(4)(a)", + "3.A.7.22(4)(b)", + "3.A.7.22(4)(c)", + "3.A.7.22(4)(d)", + "3.A.7.22(4)(e)", + "3.A.7.22(5)", + "3.A.7.22(5)(a)", + "3.A.7.22(5)(b)", + "3.A.7.22(5)(c)", + "3.A.7.22(5)(d)", + "3.A.7.22(6)" ], - "emea-esp-decree-311-2022": [ - "25.2", - "33.2", - "33.4", - "33.7" + "emea-che-fadp-2025": [ + "3.24.1", + "3.24.2", + "3.24.3", + "3.24.4", + "3.24.5", + "3.24.5.a", + "3.24.5.b", + "3.24.5.c", + "3.24.5bis", + "3.24.6" ], "emea-uae-niaf-2023": [ "3.3.3" ], + "emea-gbr-dpa-2018": [ + "Section 67(1)", + "Section 67(1)(a)", + "Section 67(1)(b)", + "Section 67(2)", + "Section 67(3)", + "Section 67(4)", + "Section 67(4)(a)", + "Section 67(4)(b)", + "Section 67(4)(c)", + "Section 67(4)(d)", + "Section 67(5)", + "Section 67(6)", + "Section 67(6)(a)", + "Section 67(6)(b)", + "Section 67(6)(c)", + "Section 67(7)", + "Section 67(9)", + "Section 68(1)", + "Section 68(2)", + "Section 68(2)(a)", + "Section 68(2)(b)", + "Section 68(2)(c)", + "Section 68(2)(d)", + "Section 68(3)", + "Section 68(3)(a)", + "Section 68(3)(b)", + "Section 68(3)(c)", + "Section 68(4)", + "Section 68(5)", + "Section 68(6)", + "Section 68(6)(a)", + "Section 68(6)(b)", + "Section 68(7)", + "Section 68(7)(a)", + "Section 68(7)(b)", + "Section 68(7)(c)", + "Section 68(7)(e)", + "Section 68(8)", + "Section 68(9)" + ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML2-P4", @@ -153458,17 +156081,25 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0123", "ISM-0137", "ISM-0733", "ISM-1088", - "ISM-1609" + "ISM-1609", + "ISM-1880", + "ISM-1881" ], "apac-aus-ps-cps-230-2023": [ - "33", "42" ], + "apac-aus-ps-cps-234-2019": [ + "35", + "36" + ], + "apac-chn-pipl-2021": [ + "Article 57" + ], "apac-ind-dpdpa-2023": [ "8(6)" ], @@ -153479,10 +156110,17 @@ "RS.CO.S2", "RS.CO.S3" ], + "apac-jpn-appi-2020": [ + "IV.1.22-2(2)" + ], "apac-jpn-ismap": [ "6.1.3.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.35", + "11.19" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP75", "HML75" ], @@ -153491,27 +156129,108 @@ ], "apac-nzl-ism-3-9": [ "7.2.18.C.01", + "7.2.18.C.02", "7.2.20.C.01", + "7.2.20.C.02", + "7.2.20.C.03", "7.2.21.C.01", "7.2.23.C.01" ], + "apac-nzl-privacy-act-2020": [ + "6.1.115(1)", + "6.1.115(2)", + "6.1.115(3)", + "6.1.115(3)(a)", + "6.1.115(3)(b)", + "6.1.115(4)", + "6.1.115(4)(a)", + "6.1.115(4)(b)", + "6.1.117(1)", + "6.1.117(1)(a)", + "6.1.117(1)(a)(i)", + "6.1.117(1)(a)(ii)", + "6.1.117(1)(b)", + "6.1.117(1)(c)", + "6.1.117(1)(d)", + "6.1.117(1)(e)", + "6.1.117(1)(f)", + "6.1.117(2)", + "6.1.117(2)(a)", + "6.1.117(2)(b)", + "6.1.117(2)(c)", + "6.1.117(2)(d)", + "6.1.117(2)(e)", + "6.1.117(2)(f)", + "6.1.117(3)", + "6.1.117(4)", + "6.1.117(5)" + ], + "apac-sgp-pdpa-2012": [ + "6A.26D(1)", + "6A.26D(2)", + "6A.26D(3)", + "6A.26D(4)", + "6A.26D(5)(a)", + "6A.26D(5)(b)", + "6A.26D(6)", + "6A.26D(6)(a)", + "6A.26D(6)(b)", + "6A.26D(9)", + "6A.26E", + "6A.26E(a)", + "6A.26E(b)" + ], "apac-sgp-mas-trm-2021": [ "7.7.5", - "7.7.6", "7.7.7" ], + "apac-kor-pipa-2011": [ + "IV.34(1)", + "IV.34(1)1", + "IV.34(1)2", + "IV.34(1)3", + "IV.34(1)4", + "IV.34(1)5", + "IV.34(3)" + ], + "apac-twn-pdpa-2025": [ + "I.12", + "I.12.1", + "I.12.2" + ], + "americas-arg-ppd-2018": [ + "G.1.2" + ], + "americas-bhs-dpa-2003": [ + "V.48(2)", + "V.48(3)", + "V.48(3)(a)", + "V.48(3)(b)", + "V.48(3)(c)" + ], "americas-bmu-mba-coc-2020": [ - "6.5" + "6.4" ], "americas-bra-lgpd-2018": [ - "48" + "VII.I.48", + "VII.I.48.1", + "VII.I.48.1.I", + "VII.I.48.1.II", + "VII.I.48.1.III", + "VII.I.48.1.IV", + "VII.I.48.1.V", + "VII.I.48.1.VI" ], "americas-can-osfi-b13-2022": [ "3.4.1" ], "americas-can-itsp-10-171-2025": [ "03.06.02.B", - "03.06.02.C" + "03.06.02.C", + "03.06.02.D" + ], + "americas-mex-fdpa-2010": [ + "II.20" ] } }, @@ -153533,7 +156252,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically assist in the reporting of cybersecurity and data protection incidents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -153606,7 +156325,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -153661,8 +156381,8 @@ "control_id": "IRO-10.2", "title": "Cyber Incident Reporting for Sensitive / Regulated Data", "family": "IRO", - "description": "Mechanisms exist to report sensitive/regulated data incidents in a timely manner.", - "scf_question": "Does the organization report sensitive/regulated data incidents in a timely manner?", + "description": "Mechanisms exist to report sensitive and/or regulated data incidents in a timely manner.", + "scf_question": "Does the organization report sensitive and/or regulated data incidents in a timely manner?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -153756,7 +156476,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -153830,7 +156551,8 @@ "03.06.02.c" ], "general-nist-800-171a-r3": [ - "A.03.06.02.ODP[02]" + "A.03.06.02.ODP[02]", + "A.03.06.02.b" ], "general-nist-csf-2-0": [ "RS.CO", @@ -153853,8 +156575,13 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(3)(v)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(7)", + "101.625(d)(10)", + "101.650(g)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.410(a)(1)" + "§ 164.410(a)(1)" ], "usa-federal-nerc-cip-2024": [ "CIP-008-6 4.2" @@ -153869,8 +156596,18 @@ "emea-eu-ai-act-2024": [ "Article 17.1(j)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(1)", + "Article 14(3)", + "Article 14(4)(a)", + "Article 14(4)(b)", + "Article 14(4)(c)", + "Article 14(4)(i)", + "Article 14(4)(i)(ii)", + "Article 14(4)(i)(iii)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-gdpr-2016": [ "Article 33.1", @@ -153884,40 +156621,50 @@ "emea-eu-nis2-annex-2024": [ "3.1.2(b)" ], + "emea-deu-fdpa-2017": [ + "3.4.65(1)", + "3.4.65(2)", + "3.4.65(3)", + "3.4.65(3)1", + "3.4.65(3)2", + "3.4.65(3)3", + "3.4.65(3)4", + "3.4.65(4)", + "3.4.65(5)", + "3.4.65(6)" + ], + "emea-irl-dpa-2018": [ + "s.87" + ], + "emea-ken-pda-2019": [ + "IV.43(1)(a)" + ], "emea-qat-pdppl-2020": [ - "14" + "3.14" ], "emea-sau-ecc-1-2018": [ "2-13-3-3", "2-13-3-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-89" - ], - "emea-srb-act-9-2018": [ - "52", - "52.1", - "52.2", - "52.3", - "52.4" - ], "emea-uae-niaf-2023": [ "3.3.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0733" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "apac-aus-ps-cps-230-2023": [ + "33" ], "apac-ind-sebi-2024": [ "DE.DP.S3", "RS.CO.S2" ], + "apac-jpn-appi-2020": [ + "IV.1.22-2(1)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.18" + ], "apac-nzl-ism-3-9": [ "7.2.18.C.01", "7.2.20.C.01", @@ -153925,9 +156672,41 @@ "7.2.23.C.01", "7.3.8.C.03" ], + "apac-phl-dpa-2012": [ + "V.20(f)" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(3)(a)", + "6A.26C(3)(b)", + "6A.26C(4)" + ], + "americas-arg-ppd-2018": [ + "G.1.3" + ], + "americas-bhs-dpa-2003": [ + "V.47(1)", + "V.47(2)", + "V.47(3)", + "V.47(4)(a)", + "V.47(4)(b)", + "V.47(4)(c)", + "V.47(4)(d)", + "V.47(4)(e)", + "V.47(4)(f)", + "V.47(4)(g)", + "V.47(4)(h)", + "V.47(5)", + "V.47(6)", + "V.47(6)(a)", + "V.47(6)(b)", + "V.47(6)(c)" + ], "americas-can-itsp-10-171-2025": [ "03.06.02.B", "03.06.02.C" + ], + "americas-col-law-1581-2012": [ + "VI.17(n)" ] } }, @@ -153949,7 +156728,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to report system vulnerabilities associated with reported cybersecurity and data protection incidents to organization-defined personnel or roles.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -154032,7 +156811,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -154080,9 +156860,6 @@ ], "usa-federal-irs-1075-2021": [ "IR-6(CE-3)" - ], - "emea-deu-c5-2020": [ - "PSS-02" ] } }, @@ -154106,7 +156883,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide cybersecurity and data protection incident information to the provider of the Technology Assets, Applications and/or Services (TAAS) and other organizations involved in the supply chain for TAAS related to the incident.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -154195,7 +156972,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -154293,10 +157071,7 @@ "emea-eu-nis2-2022": [ "Article 23.2" ], - "emea-isr-cmo-1-0": [ - "17.11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1569" ], "apac-ind-sebi-2024": [ @@ -154315,7 +157090,7 @@ "title": "Serious Incident Reporting", "family": "IRO", "description": "Mechanisms exist to report any serious incident involving the organization's Technology Assets, Applications, Services and/or Data (TAASD) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines.", - "scf_question": "Does the organization report any serious incident involving the organization's Technology Assets, Applications and/or Services (TAAS) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines?", + "scf_question": "Does the organization report any serious incident involving its Technology Assets, Applications, Services and/or Data (TAASD) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -154328,7 +157103,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to report any serious incident involving the organization's TAASD to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -154413,10 +157188,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(10)" + ], "usa-federal-nerc-cip-2024": [ "CIP-008-6 R4", "CIP-008-6 4.1", @@ -154425,9 +157204,33 @@ "CIP-008-6 4.1.3", "CIP-008-6 4.2" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.2", - "Article 11.4" + "emea-eu-psd2-2015": [ + "96(1)" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.15.7", + "3.3.15.7.a", + "3.3.15.7.b", + "3.3.15.7.c", + "3.3.15.7.d", + "3.3.15.7.e", + "3.3.15.7.f", + "3.3.15.7.g", + "3.3.15.7.h", + "3.3.15.7.i", + "3.3.15.7.j", + "3.3.15.7.k" + ], + "emea-esp-decree-311-2022": [ + "Article 33(7)" + ], + "americas-bmu-mba-coc-2020": [ + "6.5", + "6.5(a)", + "6.5(b)", + "6.5(c)", + "6.5(d)", + "6.5(e)" ] } }, @@ -154449,9 +157252,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide incident response advice and assistance to users of Technology Assets, Applications and/or Services (TAAS) for the handling and reporting of actual and potential cybersecurity and data protection incidents.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide incident response advice and assistance to users of Technology Assets, Applications and/or Services (TAAS) for the handling and reporting of actual and potential cybersecurity and data protection incidents. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -154535,7 +157338,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -154587,9 +157391,6 @@ "general-nist-800-171a-r3": [ "A.03.06.02.d" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "usa-federal-fbi-cjis-6-0": [ "IR-7" ], @@ -154653,7 +157454,7 @@ "0": "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.", "1": "Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically increase the availability of incident response-related information and support.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically increase the availability of incident response-related information and support. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -154719,7 +157520,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -154782,7 +157584,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to establish a direct, cooperative relationship between the organization's incident response capability and external service providers.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -154866,7 +157668,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -154912,9 +157715,6 @@ "general-nist-800-161-r1-level-3": [ "IR-7(2)" ], - "general-scf-dpmp-2025": [ - "8.2" - ], "usa-federal-doe-c2m2-2-1": [ "RESPONSE-3j", "RESPONSE-3k" @@ -154928,8 +157728,9 @@ "IR-7(CE-2).a", "IR-7(CE-2).b" ], - "emea-zaf-popia-2013": [ - "21.2" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], "apac-nzl-ism-3-9": [ "7.3.10.C.01", @@ -154942,8 +157743,8 @@ "control_id": "IRO-12", "title": "Sensitive / Regulated Data Spill Response", "family": "IRO", - "description": "Mechanisms exist to respond to sensitive/regulated data spills.", - "scf_question": "Does the organization respond to sensitive/regulated data spills?", + "description": "Mechanisms exist to respond to sensitive and/or regulated data spills.", + "scf_question": "Does the organization respond to sensitive and/or regulated data spills?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -154958,7 +157759,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to respond to sensitive/regulated data spills.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -155045,7 +157846,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -155089,10 +157891,12 @@ "IR-9" ], "general-nist-800-171-r3": [ + "03.01.22.b", "03.06.01" ], "general-nist-800-171a-r3": [ - "A.03.01.22.b[02]" + "A.03.01.22.b[02]", + "A.03.06.01[01]" ], "general-pci-dss-4-0-1": [ "12.10.7", @@ -155137,7 +157941,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-09" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], "apac-nzl-ism-3-9": [ @@ -155151,7 +157955,15 @@ "7.3.8.C.02", "7.3.8.C.03" ], + "americas-bhs-dpa-2003": [ + "IV.28(3)(a)", + "IV.28(3)(b)", + "IV.28(3)(b)(i)", + "IV.28(3)(b)(ii)", + "IV.28(3)(b)(iii)" + ], "americas-can-itsp-10-171-2025": [ + "03.01.22.B", "03.06.01" ] } @@ -155160,8 +157972,8 @@ "control_id": "IRO-12.1", "title": "Sensitive / Regulated Data Spill Responsible Personnel", "family": "IRO", - "description": "Mechanisms exist to formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills.", - "scf_question": "Does the organization formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills?", + "description": "Mechanisms exist to formally assign personnel or roles with responsibility for responding to sensitive and/or regulated data spills.", + "scf_question": "Does the organization formally assign personnel or roles with responsibility for responding to sensitive and/or regulated data spills?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -155174,7 +157986,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -155258,7 +158070,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -155322,8 +158135,8 @@ "control_id": "IRO-12.2", "title": "Sensitive / Regulated Data Spill Training", "family": "IRO", - "description": "Mechanisms exist to ensure incident response training material provides coverage for sensitive/regulated data spillage response.", - "scf_question": "Does the organization ensure incident response training material provides coverage for sensitive/regulated data spillage response?", + "description": "Mechanisms exist to ensure incident response training material provides coverage for sensitive and/or regulated data spillage response.", + "scf_question": "Does the organization ensure incident response training material provides coverage for sensitive and/or regulated data spillage response?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -155336,7 +158149,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to ensure incident response training material provides coverage for sensitive/regulated data spillage response.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -155404,7 +158217,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -155438,8 +158252,8 @@ "control_id": "IRO-12.3", "title": "Post-Sensitive / Regulated Data Spill Operations", "family": "IRO", - "description": "Mechanisms exist to ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", - "scf_question": "Does the organization ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions?", + "description": "Mechanisms exist to ensure that organizational personnel impacted by sensitive and/or regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", + "scf_question": "Does the organization ensure that organizational personnel impacted by sensitive and/or regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -155452,7 +158266,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -155536,7 +158350,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -155577,10 +158392,7 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-09(03)" ], - "emea-deu-c5-2020": [ - "OPS-21" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ] } @@ -155589,8 +158401,8 @@ "control_id": "IRO-12.4", "title": "Sensitive / Regulated Data Exposure to Unauthorized Personnel", "family": "IRO", - "description": "Mechanisms exist to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations.", - "scf_question": "Does the organization address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations?", + "description": "Mechanisms exist to address security safeguards for personnel exposed to sensitive and/or regulated data that is not within their assigned access authorizations.", + "scf_question": "Does the organization address security safeguards for personnel exposed to sensitive and/or regulated data that is not within their assigned access authorizations?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -155603,9 +158415,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -155688,7 +158500,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -155716,7 +158529,7 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-09(04)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], "apac-nzl-ism-3-9": [ @@ -155745,9 +158558,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders provide After Action Review (AAR) feedback on what worked, what did not work and ways to improve future responses to similar incidents.\n▪ A formal Root Cause Analysis (RCA) is performed that documents the findings in a report for both technical and business leadership management.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -155835,7 +158648,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -155952,7 +158766,8 @@ "03.06.04.b" ], "general-nist-800-171a-r3": [ - "A.03.06.04.ODP[04]" + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" ], "general-nist-800-218": [ "RV.3" @@ -156010,6 +158825,9 @@ "IR-04(12)", "IR-06(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(c)(6)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(h)(7)" ], @@ -156059,14 +158877,20 @@ "3.6.3" ], "emea-deu-c5-2020": [ - "SIM-05" + "SIM-04" ], "emea-sau-cgiot-2024": [ "2-12-2", "2-12-3" ], + "emea-sau-otcc-1-2022": [ + "2-12-1-2" + ], "emea-sau-sacs-002-2022": [ - "TPC-89" + "VII.B.TPC-89" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7" ], "emea-gbr-caf-4-0": [ "D2", @@ -156088,11 +158912,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4200" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1213" ], - "apac-aus-ps-cps-234-2019": [ - "25(a)" + "apac-aus-ps-cps-230-2023": [ + "32" ], "apac-ind-sebi-2024": [ "EV.ST.S3", @@ -156112,20 +158936,19 @@ "apac-sgp-mas-trm-2021": [ "7.8.1", "7.8.2", - "7.8.3", - "12.3.3" + "12.3.2" ], "americas-bmu-mba-coc-2020": [ "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-osfi-b13-2022": [ "2.7.3", "3.4", "3.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.04.B" ] @@ -156149,9 +158972,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain incident response contacts with applicable regulatory and law enforcement agencies.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain incident response contacts with applicable regulatory and law enforcement agencies. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -156220,7 +159043,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -156300,6 +159124,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(3)" + ], "usa-federal-irs-1075-2021": [ "IR-6" ], @@ -156319,23 +159146,11 @@ "IR-06" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0140" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "2.1.10.C.01" - ], - "apac-sgp-pdpa-2012": [ - "11" - ], "americas-can-itsp-10-171-2025": [ "03.06.02.C" ] @@ -156359,7 +159174,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to utilize a detonation chamber capability to detect and/or block potentially-malicious files and email attachments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -156447,12 +159262,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.6", "9.7" ], @@ -156466,7 +159282,7 @@ "general-iso-21434-2021": [ "RC-05-15" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.001", "T1137.002", @@ -156502,15 +159318,18 @@ "general-nist-800-160-vol-2-r1": [ "SC-44" ], + "general-nist-800-172-r3": [ + "03.13.14E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.14E" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EM.E3AEP", "3.PEP.EM.MFPRO", "3.PEP.EM.PDPRO", "3.PEP.FI.DCHAM" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" - ], "emea-gbr-def-stan-05-138-2024": [ "2411" ], @@ -156523,16 +159342,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0651", "ISM-0652", - "ISM-1389" + "ISM-1389", + "ISM-1970" ], "apac-jpn-ismap": [ "12.2.1.14" - ], - "apac-nzl-ism-3-9": [ - "15.2.21.C.01" ] } }, @@ -156630,7 +159447,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -156650,18 +159468,13 @@ "248.30(a)(4)(i)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-nis2-2022": [ "Article 23.2" ], "apac-ind-sebi-2024": [ "RC.CO.S1" - ], - "apac-sgp-mas-trm-2021": [ - "7.7.5", - "7.7.6", - "7.7.7" ] } }, @@ -156687,7 +159500,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel coordinate IAP activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience assessment and authorization controls.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience assessment and authorization controls. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -156783,9 +159596,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -156909,12 +159722,12 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-nist-csf-2-0": [ "ID.RA-01" ], - "general-scf-dpmp-2025": [ - "7.11" - ], "general-sparta": [ "CM0089" ], @@ -156993,50 +159806,34 @@ "emea-eu-ai-act-2024": [ "Article 9.8" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)" + "3.4.6.42", + "3.4.6.43", + "3.4.6.43(a)", + "3.4.6.43(b)", + "3.4.6.45", + "3.6.2.69", + "3.6.2.70" ], "emea-eu-nis2-annex-2024": [ "6.5.1", "6.5.2(a)", "6.5.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5", - "17.1", - "17.16", - "17.18" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" + "emea-sau-cscc-1-2019": [ + "1-3-1", + "1-3-2", + "2-13-4" ], "emea-sau-cgiot-2024": [ "1-5-2", @@ -157044,15 +159841,21 @@ "4-1-5", "4-2-3" ], + "emea-sau-ecc-1-2018": [ + "1-6-2" + ], "emea-sau-otcc-1-2022": [ - "1-4-1-2" + "1-5-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-51" + "emea-esp-decree-311-2022": [ + "Article 13(2)(c)", + "Article 21(1)" ], - "emea-zaf-popia-2013": [ - "19", - "60" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" + ], + "emea-gbr-cap-1850-2020": [ + "A2" ], "emea-gbr-def-stan-05-138-2024": [ "1205" @@ -157063,7 +159866,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1205" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0027", "ISM-0280", "ISM-1525" @@ -157072,7 +159875,14 @@ "ID.AM.S4", "PR.AA.S16" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.6", + "10.8", + "10.15", + "16.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP68", "HML67" ], @@ -157103,19 +159913,16 @@ "4.4.12.C.05" ], "apac-sgp-mas-trm-2021": [ - "5.1.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.6.1", + "4.5.1", "5.6.2", - "5.6.3", "5.7.1", - "5.7.2" + "6.1.6", + "6.1.7", + "6.4.6", + "6.5.3" ], "americas-bmu-mba-coc-2020": [ - "5.14" + "6.15" ], "americas-can-osfi-b13-2022": [ "2.4.4" @@ -157232,7 +160039,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -157261,6 +160069,9 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-swift-cscf-2025": [ "7.3A" ], @@ -157280,25 +160091,54 @@ "11.10(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.F.2.b" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-annex-2024": [ "6.5.2(c)" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.3" + ], + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "2-11-3-1" + ], + "emea-gbr-cap-1850-2020": [ + "A2" + ], + "apac-mys-bnm-rmit-2025": [ + "10.8", + "10.9" + ], "apac-nzl-ism-3-9": [ "5.8.61.C.01", "5.8.61.C.02", - "5.8.61.C.03" + "5.8.61.C.03", + "20.1.21.C.02", + "23.5.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2" + "4.5.1", + "5.6.2", + "6.1.6", + "6.4.6" ], "americas-can-osfi-b13-2022": [ "2.4.4" @@ -157420,9 +160260,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -157510,7 +160350,7 @@ "general-iso-42001-2023": [ "A.6.2.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1190", "T1195", "T1195.001", @@ -157571,6 +160411,9 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-nist-csf-2-0": [ "ID.RA-01", "ID.IM-01", @@ -157613,11 +160456,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)", + "101.650(e)(1)(i)", + "101.650(e)(1)(ii)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-irs-1075-2021": [ "CA-2" @@ -157657,19 +160505,15 @@ "emea-eu-ai-act-2024": [ "Article 9.8" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 32(1)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" ], "emea-eu-nis2-annex-2024": [ "6.5.2(a)", @@ -157678,16 +160522,10 @@ "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5", - "17.2", - "17.16", - "17.18" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2" + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "1-3-1-2", + "2-13-4" ], "emea-sau-cgiot-2024": [ "2-15-2", @@ -157695,6 +160533,20 @@ "4-2-3", "4-2-4" ], + "emea-sau-ecc-1-2018": [ + "1-6-2-1", + "1-6-2-2" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3", + "mp.sw.2" + ], + "emea-gbr-cap-1850-2020": [ + "A2" + ], "emea-gbr-def-stan-05-138-2024": [ "1205" ], @@ -157704,8 +160556,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1205" ], - "apac-aus-ism-2024-june": [ - "ISM-0100" + "apac-aus-ism-2026-march": [ + "ISM-0100", + "ISM-1967", + "ISM-1971", + "ISM-1972" + ], + "apac-aus-ps-cps-234-2019": [ + "22", + "28" ], "apac-chn-cybersecurity-law-2017": [ "Article 35" @@ -157724,7 +160583,14 @@ "14.2.9.3", "14.2.9.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.6", + "10.8", + "10.9", + "16.4" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP68", "HML67" ], @@ -157736,18 +160602,30 @@ "4.3.20.C.01", "4.3.20.C.02", "4.3.20.C.03", - "6.3.8.C.01" + "6.3.8.C.01", + "11.1.19.C.01", + "16.1.30.C.01", + "16.7.41.C.01", + "20.1.21.C.01", + "20.1.21.C.07", + "20.1.22.C.03", + "20.1.23.C.01", + "23.5.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2" + "4.5.1", + "5.6.2", + "6.1.6" ], "americas-bmu-mba-coc-2020": [ - "5.14" + "6.15-BP2" ], "americas-can-osfi-b13-2022": [ "2.4.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.4" + ], "americas-can-itsp-10-171-2025": [ "03.12.01" ] @@ -157773,7 +160651,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -157856,9 +160734,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -157903,6 +160781,12 @@ "general-nist-800-171-r2": [ "NFO - CA-2(1)" ], + "general-nist-800-172-r3": [ + "03.12.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.02E" + ], "usa-federal-fbi-cjis-6-0": [ "CA-2(1)" ], @@ -157925,9 +160809,16 @@ "CA-2(1)", "CA-2(1)-IS" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "apac-mys-bnm-rmit-2025": [ + "10.8" ], "apac-nzl-ism-3-9": [ "4.3.16.C.01" @@ -157938,8 +160829,8 @@ "control_id": "IAO-02.2", "title": "Specialized Assessments", "family": "IAO", - "description": "Mechanisms exist to conduct specialized assessments for: \n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities; \n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management; \n(8) Malicious code; \n(9) Insider threats;\n(10) Performance/load testing; and/or\n(11) Artificial Intelligence and Autonomous Technologies (AAT).", - "scf_question": "Does the organization conduct specialized assessments for: \n (1) Statutory, regulatory and contractual compliance obligations;\n (2) Monitoring capabilities; \n (3) Mobile devices;\n (4) Databases;\n (5) Application security;\n (6) Embedded technologies (e.g., IoT, OT, etc.);\n (7) Vulnerability management; \n (8) Malicious code; \n (9) Insider threats;\n (10) Performance/load testing; and/or\n (11) Artificial Intelligence and Autonomous Technologies (AAT) testing?", + "description": "Mechanisms exist to conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.", + "scf_question": "Does the organization conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -157954,7 +160845,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct specialized assessments for: \n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities; \n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management; \n(8) Malicious code; \n(9) Insider threats;\n(10) Performance/load testing; and/or\n(11) Artificial Intelligence and Autonomous Technologies (AAT).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -158038,8 +160929,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -158146,29 +161039,75 @@ "usa-federal-irs-1075-2021": [ "SA-11(CE-5)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 13(3)", + "Article 32(1)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.4.6.47", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" ], "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-2-1", + "1-6-2-2" ], - "apac-aus-ism-2024-june": [ + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3", + "2-10-1-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.b.1", + "3.3.7.4.b.2", + "3.3.7.4.b.3", + "3.3.7.4.b.4" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3", + "mp.sw.2" + ], + "apac-aus-ism-2026-march": [ "ISM-0100", "ISM-1137", - "ISM-1570" + "ISM-1570", + "ISM-2019" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.9", + "10.15" ], "apac-nzl-ism-3-9": [ "4.3.20.C.01", "4.3.20.C.02", - "4.3.20.C.03" + "4.3.20.C.03", + "20.2.13.C.01", + "20.2.13.C.02" ], "apac-sgp-mas-trm-2021": [ - "5.7.4" + "5.3.3", + "5.6.3", + "6.1.6", + "6.4.6" ] } }, @@ -158190,9 +161129,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to accept and respond to the results of external assessments that are performed by impartial, external organizations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to accept and respond to the results of external assessments that are performed by impartial, external organizations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -158275,9 +161214,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Information Assurance", "crosswalks": { "general-govramp": [ @@ -158310,11 +161249,7 @@ "usa-federal-gsa-fedramp-5-high": [ "CA-02(03)" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0100" ], "apac-nzl-ism-3-9": [ @@ -158348,7 +161283,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -158436,7 +161371,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -158459,21 +161395,35 @@ "ID.IM-01", "ID.IM-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)(iii)" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-annex-2024": [ "6.5.2(c)" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "apac-aus-ism-2026-march": [ "ISM-1563" ], + "apac-mys-bnm-rmit-2025": [ + "10.8" + ], "apac-nzl-ism-3-9": [ "4.2.11.C.01", "4.2.12.C.01", "4.3.21.C.01", "4.5.17.C.01", "6.3.8.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.6" ] } }, @@ -158497,7 +161447,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ 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).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate authoritative documentation (e.g., System Security Plan (SSP)) that:\n(1) Identifies key architectural and implementation information on in-scope Technology Assets, Applications and/or Services (TAAS);\n(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\n(3) Provides a historical record of applied security controls, including changes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -158570,9 +161520,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -158680,6 +161630,8 @@ "3.12.4" ], "general-nist-800-171-r3": [ + "03.01.16.a", + "03.04.11.a", "03.04.11.b", "03.15.02.a", "03.15.02.a.01", @@ -158703,6 +161655,7 @@ "3.12.4[h]" ], "general-nist-800-171a-r3": [ + "A.03.01.16.a[01]", "A.03.04.11.a[02]", "A.03.04.11.a[03]", "A.03.04.11.b[01]", @@ -158717,14 +161670,50 @@ "A.03.15.02.a.07", "A.03.15.02.a.08", "A.03.15.02.b[01]", - "A.03.15.02.b[02]", - "A.03.15.02.c" - ], - "general-nist-800-172": [ - "3.11.4e" - ], - "general-scf-dpmp-2025": [ - "5.13" + "A.03.15.02.b[02]" + ], + "general-nist-800-172-r3": [ + "03.01.04E", + "03.01.06E", + "03.13.11E", + "03.13.14E", + "03.13.16E", + "03.14.08E", + "03.14.10E", + "03.14.14E", + "03.14.15E", + "03.14.16E", + "03.15.01E", + "03.15.02E", + "03.15.03E", + "03.16.01E", + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.04E.ODP[02]", + "DS-A.03.01.06E", + "A.03.13.11E.ODP[01]", + "A.03.13.14E.ODP[01]", + "A.03.13.16E.ODP[03]", + "A.03.14.08E.ODP[01]", + "A.03.14.08E.ODP[03]", + "A.03.14.08E.ODP[05]", + "A.03.14.08E.ODP[07]", + "A.03.14.08E.ODP[11]", + "A.03.14.10E.ODP[02]", + "A.03.14.14E.ODP[01]", + "A.03.14.15E.ODP[01]", + "A.03.14.16E.ODP[01]", + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.03", + "DS-A.03.15.01E.b", + "DS-A.03.15.01E.c", + "DS-A.03.15.02E.b", + "A.03.15.02E.ODP[01]", + "A.03.15.03E.ODP[01]", + "A.03.15.03E.ODP[02]", + "A.03.16.01E.ODP[02]", + "A.03.17.02E.ODP[01]" ], "usa-federal-fbi-cjis-6-0": [ "PL-2" @@ -158750,6 +161739,27 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PL-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)", + "101.630(a)", + "101.630(c)", + "101.630(c)(1)", + "101.630(c)(2)", + "101.630(c)(3)", + "101.630(c)(4)", + "101.630(c)(5)", + "101.630(c)(6)", + "101.630(c)(7)", + "101.630(c)(8)", + "101.630(c)(9)", + "101.630(c)(10)", + "101.630(c)(11)", + "101.630(c)(12)", + "101.630(c)(13)", + "101.630(c)(14)", + "101.650(c)", + "101.650(e)(1)(v)" + ], "usa-federal-irs-1075-2021": [ "2.E.4.3", "2.E.4.3-1.1", @@ -158813,8 +161823,40 @@ "emea-eu-ai-act-2024": [ "Article 11.1" ], - "emea-qat-pdppl-2020": [ - "11.1" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 13(3)", + "Article 13(7)", + "Article 19(2)(b)", + "Article 31(1)", + "Article 31(2)", + "Article 31(3)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "emea-deu-bsrit-2017": [ + "3.6" + ], + "emea-deu-c5-2020": [ + "UP-01-BP2", + "UP-01-BP3", + "UP-01-BP5" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(e)", + "Article 15(2)" + ], + "emea-gbr-cap-1850-2020": [ + "A2", + "A3", + "B1", + "B4" ], "emea-gbr-def-stan-05-138-2024": [ "2301" @@ -158825,9 +161867,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0041", - "ISM-0432" + "ISM-0432", + "ISM-0912", + "ISM-1912", + "ISM-2005" ], "apac-jpn-ismap": [ "4.4.4", @@ -158849,7 +161894,16 @@ "5.4.5.C.02", "5.4.5.C.03" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(a)" + ], + "americas-arg-ppd-2018": [ + "B.2.1-1", + "E.1.1-3" + ], "americas-can-itsp-10-171-2025": [ + "03.01.16.A", + "03.04.11.A", "03.04.11.B", "03.15.02.A", "03.15.02.A.01", @@ -158882,9 +161936,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to plan and coordinate Information Assurance Program (IAP) activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to plan and coordinate Information Assurance Program (IAP) activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -158968,7 +162022,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -159068,8 +162123,8 @@ "control_id": "IAO-03.2", "title": "Adequate Security for Sensitive / Regulated Data In Support of Contracts", "family": "IAO", - "description": "Mechanisms exist to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", - "scf_question": "Does the organization protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract?", + "description": "Mechanisms exist to protect sensitive and/or regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", + "scf_question": "Does the organization protect sensitive and/or regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -159084,9 +162139,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -159170,7 +162225,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -159206,10 +162262,10 @@ "CAL2.-3.12.4" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "usa-state-co-privacy-act-2021": [ "6-1-1305(3)(b)" @@ -159222,21 +162278,26 @@ "SA-04-SID", "SA-09-SID" ], - "emea-deu-c5-2020": [ - "HR-06", - "PI-02" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" ], - "emea-isr-cmo-1-0": [ - "16.5" + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "emea-deu-c5-2020": [ + "BEI-02", + "BEI-02-BP1", + "BEI-02-BP2", + "BEI-02-BP3", + "BEI-02-BP4" ], - "emea-srb-act-9-2018": [ - "5", - "11" + "emea-gbr-cap-1850-2020": [ + "A2", + "B1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0072", "ISM-1451", "ISM-1571", @@ -159245,9 +162306,6 @@ "ISM-1574", "ISM-1575" ], - "apac-jpn-ppi-2020": [ - "22" - ], "apac-jpn-ismap": [ "13.2.2", "13.2.2.2", @@ -159263,20 +162321,8 @@ "apac-nzl-ism-3-9": [ "2.2.5.C.02" ], - "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" - ], - "apac-sgp-mas-trm-2021": [ - "5.4.3" - ], - "amaericas-can-osfi-self-assessment": [ - "4.26", - "4.28" + "americas-bhs-dpa-2003": [ + "V.51(1)(a)" ] } }, @@ -159285,7 +162331,7 @@ "title": "Threat Analysis & Flaw Remediation During Development", "family": "IAO", "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.", - "scf_question": "Does the organization require system developers and integrators to create and execute a Security Testing and Evaluation (ST&E) plan to identify and remediate flaws during development?", + "scf_question": "Does the organization 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?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -159298,7 +162344,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -159383,7 +162429,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -159537,9 +162584,39 @@ "SA-11(CE-5).a", "SA-11(CE-5).b" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(6)", + "Article 13(21)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(2)", + "Annex I, Part II(3)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], + "emea-sau-cscc-1-2019": [ + "1-3-2-1" + ], + "emea-sau-ecc-1-2018": [ + "1-5-3" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.10" + ], "apac-nzl-ism-3-9": [ "6.2.5.C.01", "6.2.6.C.01" @@ -159547,8 +162624,8 @@ "apac-sgp-mas-trm-2021": [ "5.7.5" ], - "amaericas-can-osfi-self-assessment": [ - "2.7" + "americas-can-osfi-self-assessment-2": [ + "2.4.4" ] } }, @@ -159572,7 +162649,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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:\n(1) Deficiency tracking number;\n(2) Applicable security, compliance and/or resilience control;\n(3) Description of the deficiency(ies);\n(4) Risk associated with the deficiency(ies);\n(5) Source deficiency identification/detection;\n(6) Temporary compensating controls, if applicable;\n(7) Point of Contact (POC) (e.g., asset/process owner);\n(8) Resources required to conduct remediation actions;\n(9) Planned remedial actions to the deficiency(ies);\n(10) Proposed remediation timeline; and\n(11) Disposition statement (e.g., closeout summary).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -159644,9 +162721,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -159798,20 +162875,20 @@ "3.12.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.04.11.b[01]", + "A.03.04.11.b[02]", "A.03.12.02.a.01", "A.03.12.02.a.02", "A.03.12.02.b.01", "A.03.12.02.b.02", - "A.03.12.02.b.03" + "A.03.12.02.b.03", + "A.03.14.01.a[01]" ], "general-nist-csf-2-0": [ "ID.RA-01", "ID.IM-01", "ID.IM-02" ], - "general-scf-dpmp-2025": [ - "9.3" - ], "general-tisax-6-0-3": [ "1.5.2" ], @@ -159854,6 +162931,9 @@ "CA-05", "PM-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)(iv)" + ], "usa-federal-irs-1075-2021": [ "2.E.5", "2.E.5-1", @@ -159895,8 +162975,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-05" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(d)" + "3.3.1.13(d)", + "3.3.6.27", + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "emea-eu-nis2-2022": [ "Article 21.4" @@ -159904,13 +162991,25 @@ "emea-eu-nis2-annex-2024": [ "6.5.2(d)" ], + "emea-deu-bsrit-2017": [ + "3.8" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 4" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], "emea-sau-otcc-1-2022": [ - "1-3-1-6" + "1-3-1-7" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.4-2.2" ], "emea-uae-niaf-2023": [ "3.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1564" ], "apac-jpn-ismap": [ @@ -159918,16 +163017,13 @@ "4.7.1.4", "4.7.1.7" ], + "apac-mys-bnm-rmit-2025": [ + "10.8" + ], "apac-nzl-ism-3-9": [ "4.2.12.C.01", "6.3.8.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.5.2" - ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-itsp-10-171-2025": [ "03.04.11.B", "03.12.02.A", @@ -160004,9 +163100,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-nist-800-53-r4": [ @@ -160041,7 +163137,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -160130,9 +163226,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -160257,13 +163353,34 @@ "CA-02", "CM-04 (02)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5" + "emea-deu-bsrit-2017": [ + "7.11" + ], + "emea-sau-cscc-1-2019": [ + "1-3-1-2", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-3-5" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72", + "VII.B.TPC-73" + ], + "emea-gbr-cap-1850-2020": [ + "A2" ], "emea-gbr-def-stan-05-138-2024": [ "1205" @@ -160273,6 +163390,13 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "1205" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8" + ], + "apac-sgp-mas-trm-2021": [ + "5.7.6" ] } }, @@ -160382,7 +163506,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -160464,9 +163589,6 @@ "general-nist-800-161-r1-level-3": [ "CA-6" ], - "general-scf-dpmp-2025": [ - "7.11" - ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.Q" ], @@ -160522,21 +163644,44 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-06" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5" + "emea-deu-bsrit-2017": [ + "7.11" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-51" + "VII.B.TPC-72", + "VII.B.TPC-73" + ], + "emea-esp-decree-311-2022": [ + "Article 21(1)" + ], + "emea-gbr-cap-1850-2020": [ + "A2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0027", "ISM-0293", - "ISM-1525" + "ISM-1525", + "ISM-1968" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.15" ], "apac-nzl-ism-3-9": [ "2.2.5.C.01", @@ -160544,8 +163689,15 @@ "4.5.18.C.01", "4.5.18.C.02", "4.5.18.C.03", + "20.1.21.C.04", + "20.1.22.C.01", + "20.1.22.C.03", + "20.1.22.C.05", "23.2.16.C.03", "23.2.16.C.04" + ], + "apac-sgp-mas-trm-2021": [ + "5.7.6" ] } }, @@ -160668,7 +163820,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -160757,6 +163910,12 @@ "03.07.04.a", "03.07.06.a" ], + "general-nist-800-171a-r3": [ + "A.03.04.03.c[01]", + "A.03.07.04.a[01]", + "A.03.07.04.a[02]", + "A.03.07.06.a" + ], "general-nist-csf-2-0": [ "PR.PS", "PR.PS-02", @@ -160787,12 +163946,12 @@ "MA-01" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MA-1" @@ -160815,28 +163974,14 @@ "emea-eu-nis2-annex-2024": [ "4.3.2(c)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-78" - ], - "emea-zaf-popia-2013": [ - "19" + "emea-deu-c5-2020": [ + "PS-05" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.4 [OP.EXP.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" ], - "apac-aus-ism-2024-june": [ - "ISM-0305", - "ISM-1226" + "apac-aus-ism-2026-march": [ + "ISM-0305" ], "apac-jpn-ismap": [ "11.2.4", @@ -160844,7 +163989,10 @@ "11.2.4.3", "11.2.4.5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.26" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP15", "HML15" ], @@ -160869,7 +164017,7 @@ "title": "Controlled Maintenance", "family": "MNT", "description": "Mechanisms exist to conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).", - "scf_question": "Does the organization conduct controlled maintenance activities throughout the lifecycle of theTechnology Asset, Application and/or Service (TAAS)?", + "scf_question": "Does the organization conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -160884,7 +164032,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset custodians track maintenance activities and component failure rates.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -160975,7 +164123,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -161045,7 +164194,9 @@ "3.7.1" ], "general-nist-800-171a-r3": [ - "A.03.04.03.c[01]" + "A.03.04.03.c[01]", + "A.03.07.04.a[02]", + "A.03.07.05.a[01]" ], "general-nist-csf-2-0": [ "PR.PS", @@ -161071,10 +164222,10 @@ "MA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "MA-2" @@ -161098,8 +164249,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-02" ], - "emea-sau-sacs-002-2022": [ - "TPC-78" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" ], "emea-gbr-def-stan-05-138-2024": [ "2511" @@ -161113,7 +164264,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2511" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1079" ], "apac-ind-sebi-2024": [ @@ -161122,7 +164273,12 @@ "apac-jpn-ismap": [ "11.2.4.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.26" + ], "apac-nzl-ism-3-9": [ + "11.8.10.C.01", + "11.8.10.C.04", "12.5.3.C.01", "12.5.3.C.02", "12.5.6.C.01", @@ -161237,7 +164393,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -161293,7 +164450,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to obtain maintenance support and/or spare parts for Technology Assets, Applications and/or Services (TAAS) within a defined Recovery Time Objective (RTO).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -161382,7 +164539,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -161437,6 +164595,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-nist-csf-2-0": [ "PR.PS-02", "PR.PS-03" @@ -161463,6 +164624,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-06" ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" + ], "emea-gbr-def-stan-05-138-2024": [ "2511" ], @@ -161500,11 +164664,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset custodians track maintenance activities and component failure rates.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to perform preventive maintenance on critical Technology Assets, Applications and/or Services (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -161588,7 +164752,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -161607,6 +164772,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-nist-csf-2-0": [ "PR.PS-02", "PR.PS-03" @@ -161634,11 +164802,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to perform predictive maintenance on critical Technology Assets, Applications and/or Services (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -161708,7 +164876,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -161741,7 +164910,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to automatically transfer predictive maintenance data to a computerized maintenance management system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -161814,7 +164983,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -161850,9 +165020,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to control and monitor the use of system maintenance tools.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to control and monitor the use of system maintenance tools. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -161936,7 +165106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -162012,6 +165183,12 @@ "A.03.07.04.a[02]", "A.03.07.04.a[03]" ], + "general-nist-800-172-r3": [ + "03.07.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.07.01E" + ], "usa-federal-fbi-cjis-6-0": [ "MA-3" ], @@ -162057,9 +165234,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.\n▪ IT and/or cybersecurity personnel inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -162142,7 +165319,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -162185,6 +165363,9 @@ "general-nist-800-171-r3": [ "03.07.04.b" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.b" + ], "usa-federal-fbi-cjis-6-0": [ "MA-3(1)" ], @@ -162228,9 +165409,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.\n▪ IT and/or cybersecurity personnel inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to check media containing diagnostic and test programs for malicious code before the media are used.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to check media containing diagnostic and test programs for malicious code before the media are used. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -162310,7 +165491,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -162409,7 +165591,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners prevent or control the removal of equipment undergoing maintenance that contains organizational information.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to prevent or control the removal of equipment undergoing maintenance that contains organizational information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -162488,7 +165670,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -162547,10 +165730,10 @@ "MA-03(03)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MA-3(CE-3)", @@ -162576,6 +165759,9 @@ "11.2.5.3", "11.2.5.4" ], + "apac-nzl-ism-3-9": [ + "11.8.10.C.02" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.C" ] @@ -162603,7 +165789,7 @@ "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to automatically restrict the use of maintenance tools to authorized maintenance personnel and/or roles.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -162679,7 +165865,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -162724,11 +165911,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Instances of non-console administrative access use cryptographic mechanisms to protect the confidentiality and integrity of the data being transmitted.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to authorize, monitor and control remote, non-local maintenance and diagnostic activities.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -162812,7 +165999,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -162899,8 +166087,11 @@ "3.7.5[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.12.d[1]", "A.03.07.05.a[01]", - "A.03.07.05.a[02]" + "A.03.07.05.a[02]", + "A.03.07.05.b[01]", + "A.03.07.05.c[01]" ], "general-pci-dss-4-0-1": [ "8.2.7" @@ -162961,16 +166152,6 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(h)" ], - "emea-isr-cmo-1-0": [ - "4.18", - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" - ], "emea-gbr-def-stan-05-138-2024": [ "2512" ], @@ -163017,9 +166198,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to audit remote, non-local maintenance and diagnostic sessions, as well as review the maintenance action performed during remote maintenance sessions.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to audit remote, non-local maintenance and diagnostic sessions, as well as review the maintenance action performed during remote maintenance sessions. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -163089,7 +166270,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -163174,6 +166356,9 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[02]" + ], "general-pci-dss-4-0-1": [ "8.2.7" ], @@ -163238,9 +166423,6 @@ "MA-01", "MA-04" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], "apac-jpn-ismap": [ "11.2.4.7" ], @@ -163267,7 +166449,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners require maintenance personnel to notify entity-defined personnel when non-local maintenance is planned (e.g., date/time).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require maintenance personnel to notify affected stakeholders when remote, non-local maintenance is planned (e.g., date/time).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -163338,7 +166520,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -163458,9 +166641,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-01", "MA-04" - ], - "emea-isr-cmo-1-0": [ - "12.7" ] } }, @@ -163482,9 +166662,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity and confidentiality of remote, non-local maintenance and diagnostic communications.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity and confidentiality of remote, non-local maintenance and diagnostic communications. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -163539,7 +166719,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -163571,7 +166752,7 @@ "03.07.05.b" ], "general-nist-800-171a-r3": [ - "A.03.07.05.b[02]" + "A.03.07.05.b[01]" ], "general-pci-dss-4-0-1": [ "2.2.7" @@ -163600,10 +166781,6 @@ "usa-federal-irs-1075-2021": [ "MA-4(CE-6)" ], - "emea-isr-cmo-1-0": [ - "4.20", - "12.7" - ], "americas-can-itsp-10-171-2025": [ "03.07.05.B" ] @@ -163627,7 +166804,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel provide remote disconnect verification to ensure non-local maintenance and diagnostic sessions are properly terminated.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to provide remote disconnect verification to ensure remote, non-local maintenance and diagnostic sessions are properly terminated.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -163695,7 +166872,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -163741,11 +166919,6 @@ "usa-federal-irs-1075-2021": [ "MA-4(CE-7)" ], - "emea-isr-cmo-1-0": [ - "4.18", - "4.20", - "12.7" - ], "apac-jpn-ismap": [ "11.2.4.11" ], @@ -163772,7 +166945,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require maintenance personnel to obtain pre-approval and scheduling for remote, non-local maintenance sessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -163841,7 +167014,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -163857,12 +167031,12 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[01]" + ], "usa-federal-nerc-cip-2024": [ "CIP-005-7 3.1" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], "apac-ind-sebi-2024": [ "PR.MA.S2" ], @@ -163892,7 +167066,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require Technology Assets, Applications and/or Services (TAAS) performing remote, non-local maintenance and/or diagnostic services implement a security capability comparable to the capability implemented on the system being serviced.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -163959,7 +167133,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -164086,7 +167261,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -164129,7 +167305,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT personnel, in conjunction with asset custodians, maintain a current list of authorized maintenance organizations or personnel.\n▪ Asset / process owners require maintenance personnel to obtain pre-approval and scheduling for non-local maintenance sessions.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to maintain a current list of authorized maintenance organizations or personnel.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -164218,7 +167394,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -164286,8 +167463,7 @@ "A.03.07.06.a", "A.03.07.06.b", "A.03.07.06.c", - "A.03.07.06.d[01]", - "A.03.07.06.d[02]" + "A.03.07.06.d[01]" ], "usa-federal-fbi-cjis-6-0": [ "MA-5" @@ -164325,13 +167501,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-05" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0305", "ISM-0307" ], @@ -164454,7 +167624,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -164507,12 +167678,13 @@ "3.7.6" ], "general-nist-800-171-r3": [ - "03.07.06.a", "03.07.06.c", "03.07.06.d" ], "general-nist-800-171a-r3": [ - "A.03.07.06.c" + "A.03.07.06.c", + "A.03.07.06.d[01]", + "A.03.07.06.d[02]" ], "usa-federal-dow-cmmc-2-level-2": [ "MAL2.-3.7.6" @@ -164523,11 +167695,8 @@ "usa-federal-gsa-fedramp-5-high": [ "MA-05(01)" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" ], "emea-gbr-def-stan-05-138-2024": [ "2513" @@ -164541,7 +167710,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2513" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0306" ], "apac-nzl-ism-3-9": [ @@ -164551,7 +167720,6 @@ "12.5.4.C.04" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A", "03.07.06.C", "03.07.06.D" ] @@ -164575,7 +167743,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners require maintenance personnel to obtain pre-approval and scheduling for non-local maintenance sessions.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to ensure that non-escorted personnel performing non-IT maintenance activities in the physical proximity of systems have required access authorizations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -164648,7 +167816,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -164665,7 +167834,6 @@ "3.7.6" ], "general-nist-800-171-r3": [ - "03.07.06.a", "03.07.06.c" ], "general-nist-800-171a-r3": [ @@ -164674,11 +167842,13 @@ "usa-federal-dow-cmmc-2-level-2": [ "MAL2.-3.7.6" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" + ], "usa-federal-irs-1075-2021": [ "MA-5(CE-5)" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A", "03.07.06.C" ] } @@ -164701,7 +167871,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to maintain proper physical security and configuration control over technology assets awaiting service or repair.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -164787,7 +167957,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -164856,7 +168027,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to securely conduct field maintenance on geographically deployed assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -164938,7 +168109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -164963,7 +168135,7 @@ "general-nist-800-161-r1-level-3": [ "MA-7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0305" ], "apac-nzl-ism-3-9": [ @@ -164989,7 +168161,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to ensure off-site maintenance activities are conducted securely and the asset(s) undergoing maintenance actions are secured during physical transfer and storage while off-site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -165075,14 +168247,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { "general-nist-800-171-r3": [ "03.07.04.a" ], - "apac-aus-ism-2024-june": [ + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], + "apac-aus-ism-2026-march": [ "ISM-0310" ], "apac-jpn-ismap": [ @@ -165120,7 +168296,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to validate:\n(1) Maintenance activities were appropriately performed according to the work order; and \n(2) Applicable security, compliance and resilience controls are operational.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -165203,12 +168379,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Maintenance", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1598" ], "apac-jpn-ismap": [ @@ -165299,7 +168475,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -165329,7 +168506,7 @@ }, "maturity": { "0": "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.", - "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage.", + "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to implement and govern Mobile Device Management (MDM) controls.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -165424,7 +168601,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -165468,7 +168646,8 @@ "03.01.20.d" ], "general-nist-800-171a-r3": [ - "A.03.01.18.a[01]" + "A.03.01.18.a[01]", + "A.03.01.20.d" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -165499,47 +168678,34 @@ "usa-federal-irs-1075-2021": [ "3.3.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "4.25", - "4.28", - "13.1", - "13.3", - "13.5", - "13.8", - "13.9", - "13.10" + "emea-deu-c5-2020": [ + "MDM-01", + "MDM-01-BP2", + "MDM-01-BP3", + "MDM-01-BP5", + "MDM-01-DOAR" ], "emea-sau-cscc-1-2019": [ - "2-5" + "2-5-1" ], "emea-sau-ecc-1-2018": [ - "2-6-3", - "2-6-3-1", - "2-6-3-2", - "2-6-3-3", - "2-6-3-4", - "2-6-4", - "5-1-3-6" + "2-6-1", + "2-6-2" ], "emea-sau-otcc-1-2022": [ - "2-5", "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", "2-5-1-4", - "2-5-1-5", "2-5-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.3 [MP.EQ.3]" + "emea-sau-sama-csf-1-2017": [ + "3.3.10" + ], + "emea-esp-decree-311-2022": [ + "Article 22(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-caf-4-0": [ "B3.d" @@ -165559,7 +168725,7 @@ "2309", "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0682", "ISM-0687", "ISM-0863", @@ -165571,33 +168737,23 @@ "ISM-1366", "ISM-1533" ], + "apac-mys-bnm-rmit-2025": [ + "12.3" + ], "apac-nzl-ism-3-9": [ "21.1.10.C.01", "21.1.10.C.02", - "21.1.10.C.03", "21.1.11.C.01", - "21.1.11.C.02", "21.1.12.C.01", - "21.1.14.C.01", - "21.1.14.C.02", - "21.1.15.C.01", - "21.1.16.C.01", - "21.1.16.C.02", - "21.1.17.C.01", - "21.1.17.C.02", - "21.1.17.C.03", - "21.1.18.C.01", - "21.1.18.C.02", - "21.1.19.C.01", - "21.1.19.C.02" + "22.1.10.C.01", + "22.1.10.C.03", + "22.1.12.C.01", + "22.1.15.C.01", + "22.1.18.C.02" ], "americas-bmu-mba-coc-2020": [ "6.11" ], - "amaericas-can-osfi-self-assessment": [ - "4.14", - "4.15" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.01.20.D" @@ -165622,9 +168778,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict the connection of personally-owned, mobile devices to organizational TAASD.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce access control requirements for the connection of mobile devices to organizational Technology Assets, Applications and/or Services (TAAS).", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce access control requirements for the connection of mobile devices to organizational Technology Assets, Applications and/or Services (TAAS). ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -165709,7 +168865,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -165737,7 +168894,7 @@ "general-iso-27018-2025": [ "8.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1070.001", @@ -165812,6 +168969,7 @@ "3.1.18[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[02]", "A.03.01.18.b" ], "general-nist-800-207": [ @@ -165860,23 +169018,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-19" ], - "emea-isr-cmo-1-0": [ - "4.27", - "13.2", - "13.3", - "13.5", - "13.7", - "13.9" - ], "emea-sau-cscc-1-2019": [ "2-5-1-1" ], - "emea-sau-ecc-1-2018": [ - "2-6-3-2", - "5-1-3-6" + "emea-sau-otcc-1-2022": [ + "2-5-1-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", @@ -165902,7 +169052,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of information on mobile devices through full-device or container encryption.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -165955,7 +169105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -166026,10 +169177,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-19 (05)" ], - "emea-isr-cmo-1-0": [ - "4.26", - "8.7", - "13.4" + "emea-deu-c5-2020": [ + "MDM-01-BP1" ], "emea-sau-cscc-1-2019": [ "2-5-1-2" @@ -166037,6 +169186,9 @@ "emea-sau-ecc-1-2018": [ "2-6-3-1" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-5" + ], "emea-gbr-def-stan-05-138-2024": [ "2309" ], @@ -166046,15 +169198,13 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2309" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0869" ], "apac-nzl-ism-3-9": [ "21.1.13.C.01", - "21.1.13.C.02", - "21.1.13.C.03", - "21.1.13.C.04", - "21.1.13.C.05" + "22.1.14.C.01", + "22.1.14.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.18.C" @@ -166079,7 +169229,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel protect mobile devices from tampering through inspecting devices returning from locations that the organization deems to be of significant risk, prior to the device being connected to the organization's network.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to protect mobile devices from tampering through inspecting devices returning from locations that the organization deems to be of significant risk, prior to the device being connected to the organization's network.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -166150,7 +169300,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -166178,14 +169329,14 @@ "general-nist-800-171-r3": [ "03.04.12.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.12.b" + ], "general-shared-assessments-sig-2025": [ "M.1.3" ], - "emea-isr-cmo-1-0": [ - "13.9" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" + "emea-deu-c5-2020": [ + "MDM-01-BP4" ], "americas-can-itsp-10-171-2025": [ "03.04.12.B" @@ -166210,11 +169361,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ MDM software can remotely purge selected information from mobile devices.", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to remotely purge selected information from mobile devices.", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to remotely purge selected information from mobile devices. ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -166279,7 +169430,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -166328,22 +169480,21 @@ "usa-federal-irs-1075-2021": [ "AC-7(CE-2)" ], - "emea-isr-cmo-1-0": [ - "13.8" - ], "emea-sau-ecc-1-2018": [ "2-6-3-3" ], + "emea-sau-otcc-1-2022": [ + "2-6-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-59" + "VII.B.TPC-59" ], - "apac-aus-ism-2024-june": [ - "ISM-0702" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], - "apac-nzl-ism-3-9": [ - "21.1.20.C.01", - "21.1.20.C.02", - "21.1.20.C.03" + "apac-aus-ism-2026-march": [ + "ISM-0702" ] } }, @@ -166365,9 +169516,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict the connection of personally-owned, mobile devices to organizational TAASD.\n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connection of personally-owned, mobile devices to organizational Technology Assets, Applications and/or Services (TAAS).", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connection of personally-owned, mobile devices to organizational Technology Assets, Applications and/or Services (TAAS). ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -166454,7 +169605,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -166468,6 +169620,10 @@ "03.01.18.a", "03.01.18.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.18.b" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -166477,20 +169633,19 @@ "usa-federal-dow-safeguarding-nnpi-2010": [ "9-3.d" ], - "emea-isr-cmo-1-0": [ - "13.3", - "13.5" - ], - "emea-sau-cscc-1-2019": [ - "2-5-1-1" + "emea-deu-c5-2020": [ + "MDM-01-BP6" ], "emea-sau-ecc-1-2018": [ "5-1-3-6" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-84" + "VII.B.TPC-84" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0694", "ISM-1297", "ISM-1400", @@ -166502,9 +169657,6 @@ "apac-nzl-ism-3-9": [ "21.1.12.C.01" ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.01.18.B" @@ -166529,7 +169681,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).\n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to prohibit the installation of non-approved applications or approved applications not obtained through the organization-approved application store.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -166618,7 +169770,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -166633,24 +169786,23 @@ "03.01.18.b", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.18.b", + "A.03.01.20.d" + ], "general-nist-800-207": [ "NIST Tenet 1" ], "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.18" ], - "emea-isr-cmo-1-0": [ - "13.3", - "13.5" - ], "emea-sau-ecc-1-2018": [ "5-1-3-6" ], "emea-sau-otcc-1-2022": [ - "2-5-1-4" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" + "2-5-1-1", + "2-5-1-3" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", @@ -166677,7 +169829,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to limit data retention on mobile devices to the smallest usable dataset and timeframe.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -166718,7 +169870,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": {} @@ -166741,7 +169894,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the functionality of mobile devices based on geographic location.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -166785,7 +169938,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -166818,9 +169972,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce a separate device workspace on applicable mobile devices to separate work-related and personal-related applications and data.", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce a separate device workspace on applicable mobile devices to separate work-related and personal-related applications and data. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -166886,7 +170040,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -166918,7 +170073,7 @@ }, "maturity": { "0": "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.", - "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. \n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).\n▪ MDM software is used to prevent the unauthorized disclosure of sensitive/regulated data (e.g., cryptographic containerization).", + "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. \n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).\n▪ MDM software is used to prevent the unauthorized disclosure of sensitive/regulated data (e.g., cryptographic containerization). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connectivity of unauthorized mobile devices from communicating with organizational Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -166985,7 +170140,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -166997,15 +170153,15 @@ "general-nist-800-171-r3": [ "03.01.18.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.b" + ], "general-shared-assessments-sig-2025": [ "M.1.2" ], "emea-sau-cscc-1-2019": [ "2-5-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.B" ] @@ -167130,7 +170286,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -167147,7 +170304,7 @@ "CC6.6-POF4" ], "general-cis-csc-8-1": [ - "12.0", + "12", "12.1", "12.2", "12.3", @@ -167284,10 +170441,14 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.18.a", "03.13.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[03]", + "A.03.13.01.a[02]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -167363,12 +170524,12 @@ "SC-01" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "usa-federal-irs-1075-2021": [ "3.3.6", @@ -167417,23 +170578,9 @@ "6.8.3", "6.9.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-c5-2020": [ - "PSS-10" - ], - "emea-isr-cmo-1-0": [ - "9.1" - ], "emea-sau-cscc-1-2019": [ "2-3-1-5", - "2-4", - "2-4-1-5" + "2-4-1" ], "emea-sau-cgiot-2024": [ "2-3-1", @@ -167442,49 +170589,25 @@ "2-4-5" ], "emea-sau-ecc-1-2018": [ - "2-4-4", "2-5-1", - "2-5-2", - "2-5-4" + "2-5-2" ], "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-1", - "2-3-1-1", - "2-4", "2-4-1", - "2-4-2", - "2-5-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-78" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 23" + "2-4-2" ], "emea-esp-decree-311-2022": [ - "23" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.1 [MP.COM.1]", - "8.4.2 [MP.COM.2]" + "Article 12(6)(k)", + "Article 18" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "1" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3", + "mp.s.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0521", "ISM-0629", "ISM-1186", @@ -167514,7 +170637,12 @@ "13.1.1.9", "13.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.37", + "12.3", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP49", "HHSP54", "HML49", @@ -167553,28 +170681,17 @@ "4.4" ], "apac-sgp-mas-trm-2021": [ - "11.2.1", - "11.2.2", - "11.2.3", - "11.2.4", - "11.2.5", - "11.2.6", - "11.2.7", - "11.2.8" - ], - "americas-bmu-mba-coc-2020": [ - "6.18" + "11.2.1" ], - "amaericas-can-osfi-self-assessment": [ - "4.10", - "4.15" + "americas-can-osfi-self-assessment-2": [ + "3.2.4" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", - "03.01.16.B", "03.01.18.A", - "03.13.01.A" + "03.13.01.A", + "03.14.08.B" ] } }, @@ -167598,7 +170715,7 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to treat all users and devices as potential threats and prevent access to data and resources until the users can be properly authenticated and their access authorized.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -167664,7 +170781,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -167706,7 +170824,7 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "3.0" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0665" ], "apac-ind-sebi-2024": [ @@ -167717,7 +170835,9 @@ ], "apac-nzl-ism-3-9": [ "2.3.26.C.01", - "2.3.26.C.02" + "2.3.26.C.02", + "16.1.25.C.01", + "16.5.12.C.02" ] } }, @@ -167743,9 +170863,9 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity architects maintain a segmented development network to ensure a secure development environment.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security functions as a layered structure that minimizes interactions between layers of the design and avoids any dependence by lower layers on the functionality or correctness of higher layers.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security functions as a layered structure that minimizes interactions between layers of the design and avoids any dependence by lower layers on the functionality or correctness of higher layers. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -167823,7 +170943,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -167865,8 +170986,8 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.13.01.b" ], "general-nist-csf-2-0": [ "PR.IR-01" @@ -167903,31 +171024,31 @@ "7123(c)(10)" ], "emea-deu-c5-2020": [ - "PSS-10" - ], - "emea-isr-cmo-1-0": [ - "9.17" + "KOS-01", + "KOS-03-DOAR" ], "emea-sau-cscc-1-2019": [ "2-4-1-5" ], "emea-sau-ecc-1-2018": [ - "2-5-3-1" + "2-5-3-8" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-1" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.4" + "apac-mys-bnm-rmit-2025": [ + "12.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.11", - "4.12", - "4.15" + "americas-bmu-mba-coc-2020": [ + "6.18" ], "americas-can-osfi-b13-2022": [ "3.2.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.13.01.B" ] @@ -167951,9 +171072,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Boundary protection technologies minimize the effect of Denial of Service (DoS) attacks against business-critical services.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically protect against or limit the effects of denial of service attacks.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically protect against or limit the effects of denial of service attacks. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -167992,7 +171113,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -168024,7 +171146,7 @@ "CR 7.1", "CR 7.1(1)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1496.003" ], "general-nist-800-53-r4": [ @@ -168051,6 +171173,16 @@ "general-nist-800-82-r3-high": [ "SC-05" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.a", + "A.03.13.12E.ODP[01]", + "A.03.13.12E.ODP[02]", + "DS-A.03.13.12E.b", + "A.03.13.12E.ODP[03]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.RE.DDSPR" ], @@ -168085,40 +171217,24 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-05" ], - "emea-isr-cmo-1-0": [ - "9.3" + "emea-deu-c5-2020": [ + "KOS-01" ], "emea-sau-cscc-1-2019": [ "2-4-1-8" ], - "emea-sau-sacs-002-2022": [ - "TPC-92" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.3 [MP.S.3]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1019", "ISM-1431", "ISM-1436", "ISM-1805" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS17" - ], "apac-nzl-ism-3-9": [ "18.3.18.C.01", "18.3.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "11.2.7" - ], "americas-bmu-mba-coc-2020": [ "6.19" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } }, @@ -168140,9 +171256,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel implement and manage a secure guest network.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and manage a secure guest network.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and manage a secure guest network. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -168226,7 +171342,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -168295,10 +171412,7 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(x)" ], - "emea-isr-cmo-1-0": [ - "9.18" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0536" ], "apac-nzl-ism-3-9": [ @@ -168413,11 +171527,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1021.003", "T1021.006", @@ -168455,9 +171570,6 @@ "general-nist-800-160-vol-2-r1": [ "SC-46" ], - "general-nist-800-172": [ - "3.1.3e" - ], "general-nist-800-207": [ "NIST Tenet 4" ], @@ -168470,10 +171582,13 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.5" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-2" + "emea-deu-c5-2020": [ + "KOS-03" + ], + "emea-sau-cscc-1-2019": [ + "2-6-1-5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0597", "ISM-0610", "ISM-0626", @@ -168493,7 +171608,13 @@ "19.2.18.C.01", "19.2.19.C.01", "19.2.19.C.02", - "19.2.20.C.01" + "19.2.20.C.01", + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.14.C.04", + "20.3.9.C.02", + "20.3.9.C.04", + "21.1.8.C.01" ] } }, @@ -168518,7 +171639,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network activity monitoring and control communications at the external network boundary and at key internal boundaries within the network.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor and control communications at the external network boundary and at key internal boundaries within the network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -168610,7 +171731,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -168678,7 +171800,7 @@ "8.20", "8.21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -168891,6 +172013,7 @@ ], "general-nist-800-171-r3": [ "03.01.12.a", + "03.01.18.a", "03.13.01.a", "03.13.01.b", "03.13.01.c" @@ -168909,8 +172032,17 @@ "A.03.01.18.a[03]", "A.03.13.01.a[02]", "A.03.13.01.a[04]", + "A.03.13.01.b", "A.03.13.01.c" ], + "general-nist-800-172-r3": [ + "03.01.12E", + "03.13.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.12E.ODP[01]", + "DS-A.03.13.04E" + ], "general-pci-dss-4-0-1": [ "1.3.3", "1.4", @@ -169028,27 +172160,31 @@ "SC-07" ], "emea-deu-c5-2020": [ - "COS-04", - "PSS-10" + "KOS-01", + "KOS-02", + "KOS-03" ], - "emea-isr-cmo-1-0": [ - "9.3", - "9.18", - "9.23", - "10.9", - "11.8", - "16.4" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.3" + ], + "emea-sau-cscc-1-2019": [ + "2-4-1-5" ], "emea-sau-cgiot-2024": [ "2-4-5" ], "emea-sau-otcc-1-2022": [ - "2-3-1-1", - "2-4-1-2", - "2-4-1-6" + "2-3-1-13", + "2-4-1-12" ], "emea-sau-sacs-002-2022": [ - "TPC-76" + "VII.B.TPC-76" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3" ], "emea-gbr-cyber-essentials-requirements-3-3": [ "1" @@ -169065,7 +172201,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2427" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0611", "ISM-0612", "ISM-0613", @@ -169167,17 +172303,20 @@ "19.5.28.C.05", "19.5.28.C.06", "19.5.28.C.07", - "19.5.29.C.01" + "19.5.29.C.01", + "21.3.5.C.01", + "21.3.5.C.02", + "21.3.6.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.4" ], "apac-sgp-mas-trm-2021": [ - "11.2.5", - "11.2.6" + "11.2.1" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", + "03.01.18.A", "03.13.01.A", "03.13.01.B", "03.13.01.C" @@ -169204,7 +172343,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to limit the number of concurrent external network connections to its Technology Assets, Applications and/or Services (TAAS).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to limit the number of concurrent external network connections to its Technology Assets, Applications and/or Services (TAAS). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -169289,7 +172428,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -169388,15 +172528,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (03)" ], - "emea-deu-c5-2020": [ - "COS-04" - ], - "emea-isr-cmo-1-0": [ - "9.10", - "9.11", - "16.4" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1314" ] } @@ -169489,7 +172624,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -169575,13 +172711,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (04)" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0546", "ISM-1562" ] @@ -169605,9 +172735,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent the public disclosure of internal network information.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent the public disclosure of internal network information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -169645,7 +172775,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -169655,7 +172786,7 @@ "general-iso-27018-2025": [ "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1590.001", "T1590.003", "T1590.004", @@ -169691,9 +172822,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.4.5" ], - "emea-isr-cmo-1-0": [ - "9.19" - ], "apac-jpn-ismap": [ "14.1.1.23" ] @@ -169717,7 +172845,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to apply network-based processing rules to data elements of Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -169765,7 +172893,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -169796,8 +172925,8 @@ "control_id": "NET-03.5", "title": "Prevent Unauthorized Exfiltration", "family": "NET", - "description": "Automated mechanisms exist to prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces.", - "scf_question": "Does the organization use automated mechanisms to prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces?", + "description": "Automated mechanisms exist to prevent the unauthorized exfiltration of sensitive and/or regulated data across managed interfaces.", + "scf_question": "Does the organization use automated mechanisms to prevent the unauthorized exfiltration of sensitive and/or regulated data across managed interfaces?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -169810,9 +172939,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -169860,7 +172989,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -169958,9 +173088,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically dynamically isolate (e.g., sandbox) untrusted components during runtime, where the component is isolated in a fault-contained environment but it can still collaborate with the application.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically dynamically isolate (e.g., sandbox) untrusted components during runtime, where the component is isolated in a fault-contained environment but it can still collaborate with the application. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -170005,7 +173135,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -170033,11 +173164,8 @@ "usa-federal-gsa-fedramp-5-high": [ "SC-07(20)" ], - "emea-sau-sacs-002-2022": [ - "TPC-38" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "apac-sgp-mas-trm-2021": [ + "11.5.5" ] } }, @@ -170059,9 +173187,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ boundary protections to isolate Technology Assets, Applications and/or Services (TAAS) that support critical missions and/or business functions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ boundary protections to isolate Technology Assets, Applications and/or Services (TAAS) that support critical missions and/or business functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -170130,7 +173258,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -170162,8 +173291,11 @@ "general-nist-800-160-vol-2-r1": [ "SC-07(21)" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-172-r3": [ + "03.13.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.04E.ODP[01]" ], "general-pci-dss-4-0-1": [ "1.3.3" @@ -170195,20 +173327,14 @@ "emea-sau-ecc-1-2018": [ "5-1-3-4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP43", "HHSP55", "HML43", "HML55" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS16" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP47" - ], - "apac-sgp-mas-trm-2021": [ - "11.2.6" ] } }, @@ -170302,7 +173428,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -170330,6 +173457,17 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], + "general-nist-800-172-r3": [ + "03.13.10E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.10E", + "DS-A.03.13.15E" + ], "general-pci-dss-4-0-1": [ "1.4", "1.4.1" @@ -170355,12 +173493,8 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-07(29)" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "emea-deu-c5-2020": [ + "KOS-02" ], "apac-nzl-ism-3-9": [ "14.1.11.C.01" @@ -170394,11 +173528,11 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and govern Access Control Lists (ACLs) to provide data flow enforcement that explicitly restrict network traffic to only what is authorized.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -170470,7 +173604,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -170547,7 +173682,7 @@ "8.3", "8.20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -170758,10 +173893,9 @@ "3.1.3[e]" ], "general-nist-800-171a-r3": [ - "A.03.01.03[02]" - ], - "general-nist-800-172": [ - "3.1.3e" + "A.03.01.03[02]", + "A.03.13.01.a[02]", + "A.03.13.01.c" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -170856,15 +173990,6 @@ "6.7.2(f)", "6.7.2(g)" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.12", - "9.16", - "10.9", - "12.11" - ], "emea-sau-cscc-1-2019": [ "2-4-1-4", "2-4-1-6", @@ -170876,11 +174001,14 @@ ], "emea-sau-otcc-1-2022": [ "2-4-1-6", - "2-4-1-7", "2-4-1-8", - "2-4-1-10", - "2-4-1-14", - "2-4-1-16" + "2-4-1-9", + "2-4-1-10" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2316", @@ -170898,7 +174026,7 @@ "2316", "2428" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0643", "ISM-0645", "ISM-1157", @@ -170910,6 +174038,9 @@ "18.1.13.C.02", "18.1.14.C.01" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.03", "03.13.01.A", @@ -170940,11 +174071,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure firewall and router configurations to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure firewall and router configurations to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -171014,7 +174145,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171119,6 +174251,7 @@ "3.13.6[b]" ], "general-nist-800-171a-r3": [ + "A.03.13.01.a[02]", "A.03.13.06[01]", "A.03.13.06[02]" ], @@ -171210,9 +174343,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (05)" ], - "emea-isr-cmo-1-0": [ - "9.12", - "12.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.4" ], "emea-sau-cscc-1-2019": [ "2-4-1-4", @@ -171220,13 +174352,10 @@ "2-4-1-7", "2-4-1-9" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-6", - "2-4-1-8", - "2-4-1-14" - ], - "emea-sau-sacs-002-2022": [ - "TPC-36" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2507" @@ -171240,11 +174369,17 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2507" ], + "apac-aus-ism-2026-march": [ + "ISM-2068" + ], "apac-nzl-ism-3-9": [ "18.1.13.C.01", "18.1.13.C.02", "18.1.14.C.01" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.4" + ], "americas-can-itsp-10-171-2025": [ "03.13.01.A", "03.13.06" @@ -171271,7 +174406,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to associate security attributes with information, source and destination objects to enforce defined information flow control configurations as a basis for flow control decisions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to associate security attributes with information, source and destination objects to enforce defined information flow control configurations as a basis for flow control decisions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -171316,7 +174451,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171328,6 +174464,16 @@ ], "general-nist-800-82-r3": [ "AC-04(01)" + ], + "general-nist-800-172-r3": [ + "03.01.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.10E", + "A.03.01.10E.ODP[01]", + "A.03.01.10E.ODP[02]", + "A.03.01.10E.ODP[03]", + "A.03.01.10E.ODP[04]" ] } }, @@ -171349,9 +174495,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent encrypted data from bypassing content-checking mechanisms.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent encrypted data from bypassing content-checking mechanisms. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -171396,7 +174542,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171417,9 +174564,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "AC-04(04)" - ], - "emea-isr-cmo-1-0": [ - "9.16" ] } }, @@ -171441,9 +174585,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce limitations on embedding data within other data types.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce limitations on embedding data within other data types. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -171488,7 +174632,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171500,9 +174645,6 @@ ], "general-nist-800-82-r3": [ "AC-04(05)" - ], - "emea-isr-cmo-1-0": [ - "9.16" ] } }, @@ -171526,7 +174668,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce information flow controls based on metadata.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce information flow controls based on metadata. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -171571,7 +174713,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171597,6 +174740,12 @@ "general-nist-800-161-r1-level-3": [ "AC-4(6)" ], + "general-nist-800-172-r3": [ + "03.01.13E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.13E.ODP[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "4.4" ], @@ -171625,9 +174774,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -171707,7 +174856,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171735,18 +174885,8 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.2.7" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.24" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-6", "2-4-1-2" - ], - "apac-sgp-mas-trm-2021": [ - "11.2.5" ] } }, @@ -171755,7 +174895,7 @@ "title": "Policy Decision Point (PDP)", "family": "NET", "description": "Automated mechanisms exist to evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions.", - "scf_question": "Does the organization evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions?", + "scf_question": "Does the organization use automated mechanisms to evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -171768,7 +174908,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -171818,7 +174958,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171840,6 +174981,18 @@ "general-nist-800-160-vol-2-r1": [ "AC-04(08)" ], + "general-nist-800-172-r3": [ + "03.01.10E", + "03.01.13E", + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.10E.ODP[05]", + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "A.03.01.14E.ODP[01]", + "DS-A.03.01.14E.b" + ], "general-nist-800-207": [ "NIST Tenet 4" ], @@ -171891,7 +175044,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically utilize data type identifiers to validate data essential for information flow decisions when transferring information between different security domains.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -171937,7 +175090,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171952,6 +175106,17 @@ ], "general-nist-800-160-vol-2-r1": [ "AC-04(12)" + ], + "general-nist-800-172-r3": [ + "03.01.13E", + "03.01.14E", + "03.01.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "DS-A.03.01.15E", + "A.03.01.15E.ODP[01]" ] } }, @@ -171973,7 +175138,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms, when transferring information between different security domains.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -172017,7 +175182,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -172029,6 +175195,12 @@ ], "general-nist-800-82-r3": [ "AC-04(13)" + ], + "general-nist-800-172-r3": [ + "03.01.16E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.16E.ODP[01]" ] } }, @@ -172050,7 +175222,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically implement security policy filters requiring fully enumerated formats that restrict data structure and content, when transferring information between different security domains.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -172102,7 +175274,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -172114,6 +175287,12 @@ ], "general-nist-800-82-r3": [ "AC-04(15)" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.a" ] } }, @@ -172135,11 +175314,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically examine information for the presence of unsanctioned information and prohibits the transfer of such information, when transferring information between different security domains.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -172188,7 +175367,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -172224,7 +175404,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically uniquely identify and authenticate source and destination points for information transfer.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -172261,7 +175441,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -172306,7 +175487,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically apply cybersecurity and/or data protection filters on metadata.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -172343,7 +175524,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -172369,7 +175551,7 @@ "title": "Application Proxy", "family": "NET", "description": "Mechanisms exist to terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network.", - "scf_question": "Does the organization maintain visibility and control over application traffic, regardless of the user’s location or the security posture of the surrounding network?", + "scf_question": "Does the organization terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -172382,7 +175564,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -172433,7 +175615,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": {} @@ -172536,9 +175719,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Network Security", "crosswalks": { "general-govramp": [ @@ -172559,7 +175742,7 @@ "general-iec-62443-2-1-2024": [ "NET 1.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1041", "T1048", @@ -172618,6 +175801,7 @@ ], "general-nist-800-171a-r3": [ "A.03.01.03[02]", + "A.03.01.20.c.02", "A.03.12.05.ODP[01]", "A.03.12.05.ODP[02]", "A.03.12.05.a[01]", @@ -172628,6 +175812,18 @@ "A.03.12.05.c[01]", "A.03.12.05.c[02]" ], + "general-nist-800-172-r3": [ + "03.12.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.04E.a", + "A.03.12.04E.ODP[01]", + "DS-A.03.12.04E.b[01]", + "DS-A.03.12.04E.b[02]", + "DS-A.03.12.04E.b[03]", + "A.03.12.04E.ODP[02]", + "DS-A.03.12.04E.d" + ], "general-swift-cscf-2025": [ "2.4" ], @@ -172673,11 +175869,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-03" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "16.4" + "emea-esp-decree-311-2022": [ + "Article 23" ], "americas-can-itsp-10-171-2025": [ "03.01.03", @@ -172710,7 +175903,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the direct connection of a sensitive system to an external network without the use of an organization-defined boundary protection device.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the direct connection of a sensitive system to an external network without the use of an organization-defined boundary protection device. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -172785,7 +175978,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -172822,19 +176016,8 @@ "usa-federal-cms-marse-2-0": [ "CA-3(5)" ], - "emea-isr-cmo-1-0": [ - "9.11", - "12.8", - "16.4" - ], - "emea-sau-ecc-1-2018": [ - "5-1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-13" - ], "emea-sau-sacs-002-2022": [ - "TPC-36" + "VII.B.TPC-36" ], "apac-nzl-ism-3-9": [ "14.1.13.C.01", @@ -172939,7 +176122,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -172988,10 +176172,18 @@ ], "general-nist-800-171-r3": [ "03.01.03", - "03.12.05.a", "03.12.05.b", "03.12.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], + "general-nist-800-172-r3": [ + "03.12.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.04E.c" + ], "general-shared-assessments-sig-2025": [ "G.3" ], @@ -173030,18 +176222,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-09" ], - "emea-sau-ecc-1-2018": [ - "5-1-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-13" - ], "apac-jpn-ismap": [ "13.1.1.10" ], "americas-can-itsp-10-171-2025": [ "03.01.03", - "03.12.05.A", "03.12.05.B", "03.12.05.C" ] @@ -173049,10 +176234,10 @@ }, { "control_id": "NET-06", - "title": "Network Segmentation (macrosegementation)", + "title": "Network Segmentation (macrosegmentation)", "family": "NET", - "description": "Mechanisms exist to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.", - "scf_question": "Does the organization ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources?", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "scf_question": "Does the organization implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -173065,9 +176250,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network segmentation exists to implement separate network addresses (e.g., different subnets) to connect TAASD in different security domains (e.g., sensitive/regulated data environments).\n▪ IT and/or cybersecurity architects maintain a segmented development network to ensure a secure development environment.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.\nMechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -173154,8 +176339,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control (typo)\n- wordsmithed control", "family_name": "Network Security", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -173248,8 +176435,12 @@ "general-nist-800-171a-r3": [ "A.03.13.01.b" ], - "general-nist-800-172": [ - "3.14.3e" + "general-nist-800-172-r3": [ + "03.01.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.12E", + "A.03.01.12E.ODP[01]" ], "general-pci-dss-4-0-1": [ "1.2.1", @@ -173393,12 +176584,15 @@ "usa-federal-gsa-fedramp-5-high": [ "AC-04(21)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(h)(1)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)", "7123(c)(10)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(c)" + "3.4.4.36(c)" ], "emea-eu-nis2-annex-2024": [ "6.8.1", @@ -173412,16 +176606,8 @@ "6.8.2(h)" ], "emea-deu-c5-2020": [ - "COS-06" - ], - "emea-isr-cmo-1-0": [ - "9.2", - "9.18", - "9.19", - "10.8", - "12.4", - "12.5", - "12.11" + "RB-23-DOAR", + "KOS-05" ], "emea-sau-cscc-1-2019": [ "2-3-1-4", @@ -173431,22 +176617,24 @@ "2-4-4" ], "emea-sau-ecc-1-2018": [ + "2-5-3-1", + "2-5-3-2", "5-1-3-1", "5-1-3-2" ], "emea-sau-otcc-1-2022": [ "2-4-1-1", "2-4-1-2", - "2-4-1-3", - "2-4-1-5", - "2-4-1-10" + "2-4-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "VII.B.TPC-40" ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.4 [MP.COM.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "op.mon.1", + "mp.com.1", + "mp.com.4" ], "emea-gbr-def-stan-05-138-2024": [ "2508" @@ -173460,7 +176648,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2508" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1181", "ISM-1269", "ISM-1270", @@ -173487,7 +176675,10 @@ "13.1.3.12.P", "13.1.4.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.28" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP55", "HML55" ], @@ -173495,7 +176686,13 @@ "HSUP47" ], "apac-sgp-mas-trm-2021": [ - "11.2.6" + "11.2.2" + ], + "americas-arg-ppd-2018": [ + "E.1.2-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" ], "americas-can-osfi-b13-2022": [ "3.2.5" @@ -173525,7 +176722,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Processing and storage of service location, including a managed security zone to house cybersecurity and data protection tools.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security management subnets to isolate security tools and support components from other internal system components by implementing separate subnetworks with managed interfaces to other components of the system.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security management subnets to isolate security tools and support components from other internal system components by implementing separate subnetworks with managed interfaces to other components of the system. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -173608,7 +176805,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -173669,6 +176867,14 @@ "general-nist-800-161-r1-level-3": [ "SC-7(13)" ], + "general-nist-800-172-r3": [ + "03.13.09E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.09E", + "DS-A.03.13.15E" + ], "general-swift-cscf-2025": [ "1.1" ], @@ -173691,15 +176897,11 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-04" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "mp.com.4" ], - "emea-isr-cmo-1-0": [ - "9.2", - "12.4", - "12.5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1750" ], @@ -173726,9 +176928,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -173797,11 +176999,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "KOS-05-DOAR" + ], + "apac-aus-ism-2026-march": [ "ISM-0529", "ISM-0530", "ISM-0535", @@ -173812,13 +177018,9 @@ "13.1.4.P" ], "apac-nzl-ism-3-9": [ - "22.3.9.C.01", - "22.3.9.C.02", - "22.3.9.C.03", - "22.3.9.C.04", - "22.3.10.C.01", - "22.3.11.C.01", - "22.3.11.C.02" + "20.3.9.C.02", + "20.3.9.C.03", + "20.3.9.C.04" ] } }, @@ -173826,8 +177028,8 @@ "control_id": "NET-06.3", "title": "Sensitive / Regulated Data Enclave (Secure Zone)", "family": "NET", - "description": "Mechanisms exist to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones).", - "scf_question": "Does the organization implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones)?", + "description": "Mechanisms exist to implement segmentation controls to restrict inbound and outbound connectivity for sensitive and/or regulated data enclaves (secure zones).", + "scf_question": "Does the organization implement segmentation controls to restrict inbound and outbound connectivity for sensitive and/or regulated data enclaves (secure zones)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -173840,9 +177042,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -173852,7 +177054,7 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "medium": "∙ Dedicated network segment for sensitive/regulated data systems", + "medium": "∙ Dedicated network segment for sensitive and/or regulated data systems", "large": "∙ Secure enclave/zone for sensitive data\n∙ Enhanced controls within the zone", "enterprise": "∙ Enterprise secure data enclave with enhanced controls\n∙ Data loss prevention at enclave boundary\n∙ Microsegmentation" }, @@ -173905,7 +177107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -173919,6 +177122,9 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], "general-swift-cscf-2025": [ "1.1", "1.4", @@ -173929,22 +177135,24 @@ "III.B.1.c" ], "emea-sau-cscc-1-2019": [ + "2-3-1-4", "2-4-1-6", "2-4-1-7" ], + "emea-sau-ecc-1-2018": [ + "5-1-3-1", + "5-1-3-2" + ], "emea-sau-otcc-1-2022": [ - "2-4-1-1" + "2-4-1-2", + "2-4-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "VII.B.TPC-38" ], "apac-jpn-ismap": [ "13.1.4.P" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS15" - ], "americas-can-itsp-10-171-2025": [ "03.13.01.B" ] @@ -173954,8 +177162,8 @@ "control_id": "NET-06.4", "title": "Segregation From Enterprise Services", "family": "NET", - "description": "Mechanisms exist to isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", - "scf_question": "Does the organization isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments?", + "description": "Mechanisms exist to isolate sensitive and/or regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", + "scf_question": "Does the organization isolate sensitive and/or regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments?", "relative_weight": 4, "conformity_cadence": "Annual", "evidence_requests": [], @@ -173968,7 +177176,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -174031,7 +177239,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -174042,9 +177251,6 @@ "general-mpa-csbp-5-3-1": [ "TS-1.0" ], - "general-nist-800-172": [ - "3.14.3e" - ], "general-swift-cscf-2025": [ "1.1" ], @@ -174055,16 +177261,10 @@ "usa-federal-dow-cmmc-2-level-3": [ "SI.L3-3.14.3E" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-1", - "2-4-1-3", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13" + "emea-deu-c5-2020": [ + "KOS-05" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385" ] } @@ -174073,8 +177273,8 @@ "control_id": "NET-06.5", "title": "Direct Internet Access Restrictions", "family": "NET", - "description": "Mechanisms exist to prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones).", - "scf_question": "Does the organization prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones)?", + "description": "Mechanisms exist to prohibit, or strictly-control, Internet access from sensitive and/or regulated data enclaves (secure zones).", + "scf_question": "Does the organization prohibit, or strictly-control, Internet access from sensitive and/or regulated data enclaves (secure zones)?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -174087,7 +177287,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -174150,7 +177350,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -174178,16 +177379,19 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "2.X" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(iv)", + "101.650(e)(3)(v)" + ], "emea-sau-cscc-1-2019": [ "2-4-1-3", "2-4-1-6" ], "emea-sau-otcc-1-2022": [ - "2-3-1-13", "2-4-1-7" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" + "apac-aus-ism-2026-march": [ + "ISM-1863" ] } }, @@ -174209,7 +177413,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -174277,7 +177481,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -174295,7 +177500,7 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "3.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1269", "ISM-1270", "ISM-1271" @@ -174307,7 +177512,7 @@ "title": "Software Defined Networking (SDN)", "family": "NET", "description": "Automated mechanisms exist to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", - "scf_question": "Does the organization enable dynamic, policy-driven network segmentation, access controls and traffic management?", + "scf_question": "Does the organization use automated mechanisms to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -174324,7 +177529,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -174402,7 +177607,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -174414,6 +177620,222 @@ ] } }, + { + "control_id": "NET-06.8", + "title": "Network Device Plane Segmentation", + "family": "NET", + "description": "Automated mechanisms exist to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations.", + "scf_question": "Does the organization use automated mechanisms to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Automated mechanisms exist to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Management VLAN for network device administration\n∙ Out-of-band management interface for network devices", + "small": "∙ Management VLAN for network device administration\n∙ Restrict management access to jump server", + "medium": "∙ Dedicated out-of-band management network\n∙ Separate control plane and data plane configuration\n∙ Management VLAN with strict ACLs", + "large": "∙ Dedicated out-of-band management network (OOB)\n∙ Software-defined networking (SDN) with plane separation\n∙ Management plane protection with strict ACLs", + "enterprise": "∙ Dedicated OOB management network infrastructure\n∙ SDN platform with automated plane segmentation\n∙ Management plane micro-segmentation\n∙ Automated configuration enforcement" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Network Security", + "crosswalks": { + "emea-deu-c5-2020": [ + "KOS-04" + ] + } + }, + { + "control_id": "NET-06.9", + "title": "Separate Subnets To Isolate Functions", + "family": "NET", + "description": "Mechanisms exist to implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 7, + "conformity_cadence": "", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subnetting for basic functional isolation\n∙ VLAN segmentation", + "small": "∙ VLAN-based subnet isolation\n∙ Separate subnets for servers, workstations and IoT/OT", + "medium": "∙ Subnet-based micro-segmentation\n∙ Firewall rules between functional subnets\n∙ Network ACLs for inter-subnet traffic", + "large": "∙ Network micro-segmentation\n∙ Host-based firewall enforcement between subnets\n∙ Zero Trust Network Architecture (ZTNA) between segments", + "enterprise": "∙ Enterprise micro-segmentation platform (e.g., Illumio, Guardicore)\n∙ Software-Defined Networking (SDN) for subnet isolation\n∙ ZTNA platform for workload-to-workload access control\n∙ Automated subnet policy enforcement" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Network Security", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.13.09E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.09E.ODP[01]", + "DS-A.03.13.15E", + "A.03.13.15E.ODP[01]", + "A.03.13.15E.ODP[02]" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 7.5" + ], + "emea-sau-otcc-1-2022": [ + "2-4-1-1", + "2-4-1-5", + "2-4-1-6", + "2-4-1-9", + "2-4-1-10", + "2-4-1-12", + "2-4-1-13" + ] + } + }, { "control_id": "NET-07", "title": "Network Connection Termination", @@ -174434,9 +177856,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network connection terminations at the end of a session or after an entity-defined time period of inactivity.\n▪ SBC terminate remote sessions at the end of the session or after an entity-defined time period of inactivity.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate network connections at the end of a session or after an organization-defined time period of inactivity.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate network connections at the end of a session or after an organization-defined time period of inactivity. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -174488,7 +177910,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -174510,7 +177933,7 @@ "general-iec-62443-4-2-2019": [ "CR 2.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -174536,6 +177959,7 @@ "3.13.9" ], "general-nist-800-171-r3": [ + "03.07.05.c", "03.13.09" ], "general-nist-800-171a": [ @@ -174586,10 +178010,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-10" ], - "emea-isr-cmo-1-0": [ - "4.16", - "9.4" - ], "emea-gbr-def-stan-05-138-2024": [ "2303", "2411" @@ -174607,6 +178027,7 @@ "2411" ], "americas-can-itsp-10-171-2025": [ + "03.07.05.C", "03.13.09" ] } @@ -174629,9 +178050,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -174701,7 +178122,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -174741,6 +178163,10 @@ "03.13.01.a", "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.a[02]", + "A.03.14.06.c[01]" + ], "general-pci-dss-4-0-1": [ "1.4.3", "11.5", @@ -174788,20 +178214,23 @@ "emea-eu-dora-2023": [ "Article 10.2" ], - "emea-isr-cmo-1-0": [ - "7.4", - "7.6", - "12.18", - "23.6" + "emea-deu-c5-2020": [ + "KOS-01", + "KOS-01-DOAR" ], "emea-sau-ecc-1-2018": [ "2-5-3-6" ], + "emea-sau-otcc-1-2022": [ + "2-3-1-12", + "2-3-1-13" + ], "emea-sau-sacs-002-2022": [ - "TPC-77" + "VII.B.TPC-77" ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.com.2", + "mp.com.3" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -174815,19 +178244,23 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1028", "ISM-1030", "ISM-1627", "ISM-1628" ], "apac-sgp-mas-trm-2021": [ - "11.2.3", - "11.2.4" + "11.2.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "americas-arg-ppd-2018": [ + "E.1.2-DS-2" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" ], "americas-can-itsp-10-171-2025": [ "03.13.01.A", @@ -174926,7 +178359,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -174948,6 +178382,9 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], "general-pci-dss-4-0-1": [ "1.2.1", "1.2.3", @@ -175042,10 +178479,11 @@ "emea-eu-nis2-annex-2024": [ "6.8.2(d)" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0637" ], "apac-nzl-ism-3-9": [ @@ -175075,7 +178513,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel receive feeds from Wireless Intrusion Detection / Protection Systems (WIDS / WIPS) to identify rogue wireless devices and to detect attack attempts via wireless networks.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize Wireless Intrusion Detection / Protection Systems (WIDS / WIPS) on wireless network segments.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -175146,9 +178584,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Network Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -175185,26 +178623,6 @@ ], "general-shared-assessments-sig-2025": [ "N.7" - ], - "emea-isr-cmo-1-0": [ - "4.24", - "12.18", - "23.6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-77" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], - "apac-nzl-ism-3-9": [ - "21.4.12.C.01", - "21.4.12.C.02", - "21.4.12.C.03" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } }, @@ -175226,7 +178644,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enforce host containment protections that revoke or quarantine a host’s access to the network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -175296,7 +178714,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -175409,7 +178828,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -175420,7 +178840,7 @@ "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.NE.RCONT" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1778", "ISM-1779" ] @@ -175444,9 +178864,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the authenticity and integrity of communications sessions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the authenticity and integrity of communications sessions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -175504,7 +178924,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -175529,7 +178950,7 @@ "CR 3.8(b)", "CR 3.8(c)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -175617,12 +179038,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-23" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "17.25" - ], "emea-gbr-def-stan-05-138-2024": [ "2414" ], @@ -175658,9 +179073,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically invalidate session identifiers upon user logout or other session termination.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically invalidate session identifiers upon user logout or other session termination. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -175714,7 +179129,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -175738,9 +179154,6 @@ ], "usa-federal-irs-1075-2021": [ "SC-23(CE-1)" - ], - "emea-deu-c5-2020": [ - "PSS-06" ] } }, @@ -175796,7 +179209,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -175842,7 +179256,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel ensure Domain Name Service (DNS) resolution is designed, implemented and managed to protect the security of name / address resolution.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure Domain Name Service (DNS) resolution is designed, implemented and managed to protect the security of name / address resolution.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -175920,7 +179334,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -175948,7 +179363,7 @@ "general-govramp-high": [ "SC-20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -176031,11 +179446,10 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(l)" ], - "emea-isr-cmo-1-0": [ - "9.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.2" ], "emea-sau-ecc-1-2018": [ - "2-4-3-5", "2-5-3-7" ], "emea-gbr-def-stan-05-138-2024": [ @@ -176050,7 +179464,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0574", "ISM-0861", "ISM-1026", @@ -176059,14 +179473,8 @@ "ISM-1183", "ISM-1540", "ISM-1782", - "ISM-1799" - ], - "apac-nzl-ism-3-9": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" + "ISM-1799", + "ISM-2017" ] } }, @@ -176088,9 +179496,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel ensure systems that collectively provide Domain Name Service (DNS) resolution service for are fault-tolerant and implement internal/external role separation.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure systems that collectively provide Domain Name Service (DNS) resolution service are fault-tolerant and implement internal/external role separation.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure systems that collectively provide Domain Name Service (DNS) resolution service are fault-tolerant and implement internal/external role separation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -176163,7 +179571,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -176182,7 +179591,7 @@ "general-govramp-high": [ "SC-22" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -176253,12 +179662,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SC-22" - ], - "emea-isr-cmo-1-0": [ - "9.7" - ], - "apac-nzl-ism-3-9": [ - "15.2.22.C.01" ] } }, @@ -176280,9 +179683,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to perform data origin authentication and data integrity verification on the Domain Name Service (DNS) resolution responses received from authoritative sources when requested by client systems.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to perform data origin authentication and data integrity verification on the Domain Name Service (DNS) resolution responses received from authoritative sources when requested by client systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -176359,7 +179762,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -176381,7 +179785,7 @@ "general-govramp-high": [ "SC-21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -176450,9 +179854,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SC-21" - ], - "emea-isr-cmo-1-0": [ - "9.7" ] } }, @@ -176474,7 +179875,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to validate the legitimacy of email communications through configuring a Domain Naming Service (DNS) Sender Policy Framework (SPF) record to specify the IP addresses and/or hostnames that are authorized to send email from the specified domain.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -176551,7 +179952,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -176567,10 +179969,13 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "2.M" ], + "emea-sau-ecc-1-2018": [ + "2-4-3-5" + ], "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15" + "VII.A.TPC-13", + "VII.A.TPC-14", + "VII.A.TPC-15" ], "emea-gbr-def-stan-05-138-2024": [ "2315" @@ -176584,18 +179989,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0574", "ISM-1151", "ISM-1183", "ISM-1799" - ], - "apac-nzl-ism-3-9": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" ] } }, @@ -176695,17 +180093,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1596.002" ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DO.DNMON" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1432" ] } @@ -176730,7 +180129,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize out-of-band channels for the electronic transmission of information and/or the physical shipment of system components or devices to authorized individuals.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize out-of-band channels for the electronic transmission of information and/or the physical shipment of system components or devices to authorized individuals. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -176789,14 +180188,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-csa-iot-2": [ "SWS-09" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -176834,9 +180234,6 @@ ], "general-nist-800-161-r1-level-3": [ "SC-37(1)" - ], - "emea-us-psd2-2015": [ - "22" ] } }, @@ -176844,8 +180241,8 @@ "control_id": "NET-12", "title": "Safeguarding Data Over Open Networks", "family": "NET", - "description": "Cryptographic mechanisms exist to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks.", - "scf_question": "Are cryptographic mechanisms utilized to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks?", + "description": "Cryptographic mechanisms exist to implement strong cryptography and security protocols to safeguard sensitive and/or regulated data during transmission over open, public networks.", + "scf_question": "Are cryptographic mechanisms utilized to implement strong cryptography and security protocols to safeguard sensitive and/or regulated data during transmission over open, public networks?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -176860,7 +180257,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). \n▪ Wireless access is protected via secure authentication and encryption.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network communications containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -176937,7 +180334,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -177230,11 +180628,8 @@ "SI-07", "SI-10" ], - "emea-isr-cmo-1-0": [ - "8.4", - "8.6", - "9.20", - "13.6" + "emea-deu-c5-2020": [ + "PI-04" ], "emea-gbr-def-stan-05-138-2024": [ "2305" @@ -177266,9 +180661,6 @@ "14.1.2.13", "14.1.2.14", "14.1.2.15" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS17" ] } }, @@ -177365,7 +180757,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -177375,7 +180768,7 @@ "general-csa-iot-2": [ "SWS-07" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1557.004" ], "general-nist-800-53-r4": [ @@ -177480,8 +180873,8 @@ "control_id": "NET-12.2", "title": "End-User Messaging Technologies", "family": "NET", - "description": "Mechanisms exist to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies.", - "scf_question": "Does the organization prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies?", + "description": "Mechanisms exist to prohibit the transmission of unprotected sensitive and/or regulated data by end-user messaging technologies.", + "scf_question": "Does the organization prohibit the transmission of unprotected sensitive and/or regulated data by end-user messaging technologies?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -177494,9 +180887,9 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -177580,7 +180973,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -177625,7 +181019,7 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the confidentiality, integrity and availability of electronic messaging communications.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -177710,7 +181104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -177766,10 +181161,10 @@ "2-3-1", "2-3-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.1 [MP.S.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0264", "ISM-0267", "ISM-0269", @@ -177833,25 +181228,6 @@ "15.1.19.C.01", "15.1.19.C.02", "15.1.20.C.01", - "15.2.25.C.01", - "15.2.25.C.02", - "15.2.26.C.01", - "15.2.27.C.01", - "15.2.28.C.01", - "15.2.29.C.01", - "15.2.30.C.01", - "15.2.30.C.02", - "15.2.30.C.03", - "15.2.31.C.01", - "15.2.31.C.02", - "15.2.32.C.01", - "15.2.32.C.02", - "15.2.32.C.03", - "15.2.33.C.01", - "15.2.33.C.02", - "15.2.33.C.03", - "15.2.33.C.04", - "16.7.33.C.01", "17.6.6.C.01", "17.6.7.C.01" ] @@ -177878,7 +181254,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define, control and review organization-approved, secure remote access methods.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -177959,7 +181335,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -178012,7 +181389,7 @@ "general-iso-27018-2025": [ "6.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1021", "T1021.001", @@ -178151,19 +181528,21 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.12.b", - "03.01.12.c", - "03.01.12.d" + "03.01.12.c" ], "general-nist-800-171a-r3": [ "A.03.01.12.a[01]", "A.03.01.12.a[02]", - "A.03.01.12.a[03]", "A.03.01.12.a[04]", "A.03.01.12.b", "A.03.01.12.c[01]", - "A.03.01.12.c[02]", - "A.03.01.12.d[1]", - "A.03.01.12.d[2]" + "A.03.01.12.c[02]" + ], + "general-nist-800-172-r3": [ + "03.01.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.06E" ], "general-pci-dss-4-0-1": [ "3.4.2", @@ -178279,21 +181658,13 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(d)" ], - "emea-isr-cmo-1-0": [ - "4.17" - ], "emea-sau-cscc-1-2019": [ "2-2-1-1", "2-2-1-2" ], "emea-sau-otcc-1-2022": [ - "2-2-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.7 [OP.ACC.7]" + "2-2-1-7", + "2-4-1-10" ], "emea-gbr-def-stan-05-138-2024": [ "2305" @@ -178307,7 +181678,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2305" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0487", "ISM-0488", "ISM-0489" @@ -178315,9 +181686,6 @@ "apac-ind-sebi-2024": [ "PR.AA.S12" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS13" - ], "apac-nzl-ism-3-9": [ "16.5.10.C.01", "16.5.10.C.02", @@ -178341,7 +181709,7 @@ "03.01.12.A", "03.01.12.B", "03.01.12.C", - "03.01.12.D" + "03.14.08.B" ] } }, @@ -178365,9 +181733,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically monitor and control remote access sessions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically monitor and control remote access sessions. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -178422,7 +181790,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -178477,6 +181846,16 @@ "3.1.12[c]", "3.1.12[d]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.b" + ], + "general-nist-800-172-r3": [ + "03.01.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.05E[01]", + "DS-A.03.01.05E[02]" + ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -178501,8 +181880,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (01)" ], - "emea-isr-cmo-1-0": [ - "4.18" + "emea-sau-cscc-1-2019": [ + "2-2-1-2" + ], + "emea-sau-otcc-1-2022": [ + "2-2-1-7" ], "americas-can-itsp-10-171-2025": [ "03.01.12.B" @@ -178527,9 +181909,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of remote access sessions (e.g., VPN).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of remote access sessions (e.g., VPN). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -178588,7 +181970,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -178644,6 +182027,9 @@ "3.1.13[a]", "3.1.13[b]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.a[04]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -178671,8 +182057,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (02)" ], - "emea-isr-cmo-1-0": [ - "9.8" + "emea-sau-otcc-1-2022": [ + "2-2-1-7" ], "emea-gbr-def-stan-05-138-2024": [ "2305", @@ -178690,6 +182076,9 @@ "2305", "2306" ], + "apac-aus-cop-sitc-2020": [ + "7" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A" ] @@ -178792,7 +182181,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -178841,13 +182231,16 @@ "3.1.14" ], "general-nist-800-171-r3": [ - "03.01.12.b", "03.01.12.c" ], "general-nist-800-171a": [ "3.1.14[a]", "3.1.14[b]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EN.VPNET" ], @@ -178876,8 +182269,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (03)" ], - "emea-isr-cmo-1-0": [ - "4.19" + "emea-sau-otcc-1-2022": [ + "2-4-1-7" ], "emea-gbr-def-stan-05-138-2024": [ "2307" @@ -178892,7 +182285,6 @@ "2307" ], "americas-can-itsp-10-171-2025": [ - "03.01.12.B", "03.01.12.C" ] } @@ -178917,7 +182309,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network communications containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to restrict the execution of privileged commands and access to security-relevant information via remote access only for compelling operational needs.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to restrict the execution of privileged commands and access to security-relevant information via remote access only for compelling operational needs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -178975,7 +182367,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -179047,12 +182440,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (04)" ], - "emea-isr-cmo-1-0": [ - "4.17", - "4.20" - ], "emea-sau-sacs-002-2022": [ - "TPC-35" + "VII.B.TPC-35" ], "emea-gbr-def-stan-05-138-2024": [ "2417" @@ -179096,9 +182485,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define secure telecommuting practices and govern remote access to TAASD for remote workers.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define secure telecommuting practices and govern remote access to TAASD for remote workers. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -179190,7 +182579,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -179221,11 +182611,11 @@ ], "general-nist-800-171-r3": [ "03.01.12.a", - "03.01.12.c", "03.10.06.a", "03.10.06.b" ], "general-nist-800-171a-r3": [ + "A.03.01.12.a[01]", "A.03.10.06.ODP[01]", "A.03.10.06.a", "A.03.10.06.b" @@ -179253,10 +182643,6 @@ "2-2-1-1", "2-2-1-2" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.7 [OP.ACC.7]", - "9" - ], "emea-gbr-def-stan-05-138-2024": [ "2305" ], @@ -179294,26 +182680,16 @@ "6.2.2.20", "6.2.2.21" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS13" - ], "apac-nzl-ism-3-9": [ "21.2.4.C.01", - "21.2.4.C.02", "21.2.5.C.01", "21.2.6.C.01", "21.2.7.C.01", - "21.2.7.C.02", - "21.3.5.C.01", - "21.3.6.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "9.3.1", - "9.3.2" + "22.2.4.C.01", + "22.2.4.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", - "03.01.12.C", "03.10.06.A", "03.10.06.B" ] @@ -179339,7 +182715,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to proactively control and monitor third-party accounts used to access, support, or maintain system components via remote access.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -179428,7 +182804,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -179458,9 +182835,6 @@ "CIP-005-7 2.5", "CIP-005-7 3.1", "CIP-005-7 3.2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" ] } }, @@ -179469,7 +182843,7 @@ "title": "Endpoint Security Validation", "family": "NET", "description": "Automated mechanisms exist to validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS)?", + "scf_question": "Does the organization use automated mechanisms to validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 6, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -179553,7 +182927,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -179621,7 +182996,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel provide the capability to expeditiously disconnect or disable a user's remote access session.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to provide the capability to expeditiously disconnect or disable a user's remote access session.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -179699,7 +183074,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -179743,7 +183119,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (09)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1591" ] } @@ -179852,7 +183228,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -179890,7 +183267,7 @@ "general-iso-27018-2025": [ "8.21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011", "T1011.001", "T1020.001", @@ -179973,7 +183350,8 @@ "general-nist-800-171a-r3": [ "A.03.01.16.a[01]", "A.03.01.16.a[02]", - "A.03.01.16.a[04]" + "A.03.01.16.a[04]", + "A.03.01.16.b" ], "general-nist-800-207": [ "NIST Tenet 2" @@ -180037,22 +183415,22 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-18" ], - "emea-isr-cmo-1-0": [ - "4.24", - "12.12", - "12.14" - ], "emea-sau-cscc-1-2019": [ "2-3-1-5", "2-4-1-4" ], + "emea-sau-ecc-1-2018": [ + "2-5-3-4" + ], "emea-sau-otcc-1-2022": [ - "2-4-1-4", - "2-4-1-5" + "2-4-1-4" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.com.2", + "mp.com.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0225", - "ISM-0248", "ISM-0536", "ISM-1314", "ISM-1315", @@ -180170,7 +183548,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -180217,6 +183596,8 @@ "3.1.17[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.16.a[04]", + "A.03.01.16.b", "A.03.01.16.d[01]", "A.03.01.16.d[02]" ], @@ -180276,8 +183657,11 @@ "emea-eu-nis2-annex-2024": [ "11.4.2(c)" ], - "emea-isr-cmo-1-0": [ - "12.14" + "emea-sau-ecc-1-2018": [ + "2-5-3-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-42" ], "emea-gbr-def-stan-05-138-2024": [ "2304" @@ -180308,6 +183692,8 @@ "18.2.17.C.01", "18.2.18.C.01", "18.2.19.C.01", + "18.2.19.C.02", + "18.2.19.C.03", "18.2.20.C.01", "18.2.20.C.02", "18.2.20.C.03", @@ -180345,7 +183731,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to disable unnecessary wireless networking capabilities that are internally embedded within system components prior to issuance to end users.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to disable unnecessary wireless networking capabilities that are internally embedded within system components prior to issuance to end users. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -180398,7 +183784,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -180429,6 +183816,9 @@ "general-nist-800-171-r3": [ "03.01.16.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.c" + ], "general-shared-assessments-sig-2025": [ "U.1.2" ], @@ -180444,16 +183834,9 @@ "usa-federal-irs-1075-2021": [ "AC-18(CE-3)" ], - "emea-isr-cmo-1-0": [ - "4.24" - ], "emea-sau-cscc-1-2019": [ "2-4-1-4" ], - "apac-nzl-ism-3-9": [ - "21.1.16.C.01", - "21.1.16.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.16.C" ] @@ -180479,7 +183862,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to identify and explicitly authorize users who are allowed to independently configure wireless networking capabilities.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to identify and explicitly authorize users who are allowed to independently configure wireless networking capabilities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -180541,7 +183924,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -180570,12 +183954,13 @@ "03.01.16.a", "03.01.16.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[03]", + "A.03.01.16.c" + ], "usa-federal-gsa-fedramp-5-high": [ "AC-18(04)" ], - "emea-isr-cmo-1-0": [ - "12.13" - ], "americas-can-itsp-10-171-2025": [ "03.01.16.A", "03.01.16.C" @@ -180602,7 +183987,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to confine wireless communications to organization-controlled boundaries.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to confine wireless communications to organization-controlled boundaries. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -180674,7 +184059,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -180702,10 +184088,7 @@ "usa-federal-gsa-fedramp-5-high": [ "AC-18(05)" ], - "emea-isr-cmo-1-0": [ - "4.23" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1013", "ISM-1338" ], @@ -180736,9 +184119,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to test for the presence of Wireless Access Points (WAPs) and identify all authorized and unauthorized WAPs within the facility(ies).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to test for the presence of Wireless Access Points (WAPs) and identify all authorized and unauthorized WAPs within the facility(ies). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -180810,7 +184193,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -180833,8 +184217,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "AC-18-SID.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0829" + ], + "apac-nzl-ism-3-9": [ + "22.4.12.C.02", + "22.4.12.C.03" ] } }, @@ -180843,7 +184231,7 @@ "title": "Intranets", "family": "NET", "description": "Mechanisms exist to establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS.", - "scf_question": "Does the organization establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n (1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n (2) Process, store, and/or transmit organization-controlled information using the external systems?", + "scf_question": "Does the organization establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -180856,7 +184244,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -180941,7 +184329,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": {} @@ -180968,7 +184357,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Data Loss Prevention (DLP), or similar technologies, prevent unauthorized devices from connecting to endpoint devices to control the distribution of sensitive/regulated data.\n▪ DLP prevents unauthorized devices from connecting to endpoint devices to control the distribution of sensitive/regulated data.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically implement Data Loss Prevention (DLP) to protect sensitive information as it is stored, transmitted and processed.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -181006,7 +184395,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -181058,6 +184448,12 @@ "SC-07(10)", "SI-04(18)" ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.a" + ], "general-pci-dss-4-0-1": [ "A3.2.6" ], @@ -181124,16 +184520,25 @@ "apac-ind-sebi-2024": [ "PR.DS.S4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP63", "HML69" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP55" ], - "amaericas-can-osfi-self-assessment": [ - "4.1", - "4.2" + "apac-nzl-ism-3-9": [ + "15.2.39.C.01", + "15.2.40.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.1.1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-DS-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.9" ], "americas-can-osfi-b13-2022": [ "3.2.5" @@ -181164,7 +184569,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce Internet-bound network traffic routing through a proxy device for URL content filtering to limit a user's ability to connect to prohibited content.\n▪ Content filtering blocks users from performing ad hoc file transfers through unapproved file transfer services (e.g., Box, Dropbox, Google Drive, etc.).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to force Internet-bound network traffic through a proxy device (e.g., Policy Enforcement Point (PEP)) for URL content filtering and DNS filtering to limit a user's ability to connect to dangerous or prohibited Internet sites.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -181240,15 +184645,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.2", "9.3", - "13.1" + "13.10" ], "general-cis-csc-8-1-ig1": [ "9.2" @@ -181260,7 +184666,7 @@ "general-cis-csc-8-1-ig3": [ "9.2", "9.3", - "13.1" + "13.10" ], "general-govramp": [ "SC-07(08)" @@ -181317,6 +184723,9 @@ "general-nist-800-171-r3": [ "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.14.06.c[02]" + ], "general-nist-csf-2-0": [ "DE.CM-03" ], @@ -181383,15 +184792,21 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(l)" ], - "emea-isr-cmo-1-0": [ - "9.14" - ], "emea-sau-ecc-1-2018": [ - "2-5-3-3", - "2-5-3-8" + "2-5-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-57" + "VII.B.TPC-57", + "VII.B.TPC-57-BP1", + "VII.B.TPC-57-BP2", + "VII.B.TPC-57-BP3" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1", + "mp.s.3" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP1-4" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -181405,7 +184820,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0267", "ISM-0649", "ISM-0659", @@ -181420,7 +184835,8 @@ "ISM-1287", "ISM-1293", "ISM-1502", - "ISM-1524" + "ISM-1524", + "ISM-1965" ], "apac-nzl-ism-3-9": [ "9.3.6.C.01", @@ -181434,27 +184850,16 @@ "14.3.11.C.01", "14.3.11.C.02", "14.3.12.C.01", - "20.3.4.C.01", - "20.3.4.C.02", - "20.3.5.C.01", - "20.3.5.C.02", - "20.3.6.C.01", - "20.3.7.C.01", - "20.3.7.C.02", - "20.3.8.C.01", "20.3.9.C.01", "20.3.10.C.01", "20.3.11.C.01", "20.3.11.C.02", - "20.3.11.C.03", - "20.3.12.C.01", - "20.3.12.C.02", - "20.3.13.C.01", - "20.3.13.C.02", - "20.3.14.C.01", - "20.3.15.C.01", - "20.3.15.C.02", - "20.3.16.C.01" + "21.3.7.C.01", + "21.3.7.C.02", + "21.3.14.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.2.7" ], "americas-can-itsp-10-171-2025": [ "03.14.06.C" @@ -181481,9 +184886,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce Internet-bound network traffic routing through a proxy device for URL content filtering to limit a user's ability to connect to prohibited content.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to route internal communications traffic to external networks through organization-approved proxy servers at managed interfaces.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to route internal communications traffic to external networks through organization-approved proxy servers at managed interfaces. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -181556,15 +184961,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-cis-csc-8-1": [ - "13.1" + "13.10" ], "general-cis-csc-8-1-ig3": [ - "13.1" + "13.10" ], "general-govramp": [ "SC-07(08)" @@ -181624,16 +185030,13 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.1.b" ], - "emea-isr-cmo-1-0": [ - "9.14" - ], "emea-sau-cscc-1-2019": [ "2-4-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-5-3-8" + "emea-sau-otcc-1-2022": [ + "2-4-1-11" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0260", "ISM-0570", "ISM-1237" @@ -181641,7 +185044,8 @@ "apac-nzl-ism-3-9": [ "14.3.6.C.01", "14.3.6.C.02", - "14.3.6.C.03" + "14.3.6.C.03", + "15.2.46.C.02" ] } }, @@ -181663,7 +185067,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure the proxy to make encrypted communications traffic visible to monitoring tools and mechanisms.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -181739,7 +185143,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -181767,13 +185172,12 @@ "usa-federal-irs-1075-2021": [ "SI-4(CE-10)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0263" ], "apac-nzl-ism-3-9": [ "14.3.8.C.01", - "14.3.9.C.01", - "20.3.14.C.01" + "14.3.9.C.01" ] } }, @@ -181795,7 +185199,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically route networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -181851,7 +185255,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -181887,7 +185292,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically ensure network traffic complies with Internet Engineering Task Force (IETF) protocol specifications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -181954,7 +185359,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -181982,7 +185388,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure that domain name lookups, whether for internal or external domains, are validated according to Domain Name System Security Extensions (DNSSEC).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182048,7 +185454,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182075,7 +185482,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement Internet address denylisting protections that blocks traffic received from or destined to a denylisted Internet address.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182141,7 +185548,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182168,7 +185576,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement bandwidth control technologies to limit the amount of bandwidth used by categories of domains that are bandwidth-intensive.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182233,7 +185641,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182260,7 +185669,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to force systems and processes to authenticate Internet-bound traffic with a proxy to enable user, group and/or location-aware security controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182325,7 +185734,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182352,7 +185762,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent communication with Technology Assets, Applications and/or Services (TAAS) that use a set of known bad certificates.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182418,7 +185828,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182432,7 +185843,7 @@ "title": "Content Disarm and Reconstruction (CDR)", "family": "NET", "description": "Automated Content Disarm and Reconstruction (CDR) mechanisms exist to detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements.", - "scf_question": "Automated Content Disarm and Reconstruction (CDR) Does the organization detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements?", + "scf_question": "Does the organization use automated Content Disarm and Reconstruction (CDR) mechanisms exist to detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -182445,7 +185856,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational Content Disarm and Reconstruction (CDR) capability detects the presence of unapproved active content and facilitates its removal, resulting in content with only known safe elements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182511,7 +185922,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182538,7 +185950,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement an email filtering security service to detect malicious attachments in emails and prevent users from accessing them.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182604,7 +186016,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182631,7 +186044,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor the organization's email domain’s reputation and protect the email domain’s reputation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182697,7 +186110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182724,7 +186138,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement sender denylisting protections that prevent the reception of email from denylisted senders, domains and/or email servers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182790,7 +186204,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182817,7 +186232,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize an authenticated received chain that allows for an intermediary to sign its own authentication of the original email, allowing downstream entities to accept the intermediary’s authentication even if the email was changed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -182881,7 +186296,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -182908,9 +186324,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement domain signature verification protections that authenticate incoming email according to the Domain-based Message Authentication Reporting and Conformance (DMARC).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement domain signature verification protections that authenticate incoming email according to the Domain-based Message Authentication Reporting and Conformance (DMARC).\n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -182974,7 +186390,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -183002,8 +186419,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1540" + ], + "apac-nzl-ism-3-9": [ + "15.2.36.C.01", + "15.2.36.C.02", + "15.2.36.C.03", + "15.2.36.C.04", + "15.2.36.C.05" ] } }, @@ -183025,7 +186449,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable users to digitally sign their emails, allowing external parties to authenticate the email’s sender and its contents according to the Domain-based Message Authentication Reporting and Conformance (DMARC) email authentication protocol.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -183089,7 +186513,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -183117,7 +186542,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable the encryption of outgoing emails using organization-approved cryptographic means.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -183183,7 +186608,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -183210,7 +186636,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize adaptive email protections that involve employing risk-based analysis in the application and enforcement of email protections.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -183276,7 +186702,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -183295,7 +186722,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2509" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0567" ] } @@ -183384,7 +186811,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -183477,7 +186905,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -183509,7 +186938,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ The Human Resources (HR) department maintains a current list of personnel with authorized access to organizational facilities and facilitates the implementation of physical access management controls.\n▪ Physical security controls and technologies ensure that only authorized personnel are allowed access to secure areas.\n▪ A facilities maintenance team, or similar function, manages the operation of automated physical and environmental protection controls.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to facilitate the operation of physical and environmental protection controls.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to facilitate the operation of physical and environmental protection controls. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -183606,7 +187035,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -183748,7 +187178,8 @@ "03.08.01", "03.08.02", "03.10.01.a", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "general-nist-800-171a": [ "3.10.2[a]", @@ -183756,6 +187187,15 @@ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", + "A.03.10.07.a.01" + ], "general-nist-csf-2-0": [ "ID.AM", "PR.AA", @@ -183786,9 +187226,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-sparta": [ "CM0053" ], @@ -183834,14 +187271,14 @@ "PE-23" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "2.B.2", @@ -183879,7 +187316,7 @@ "PE-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(33)" + "3.4.3.33" ], "emea-eu-nis2-annex-2024": [ "13.1.1", @@ -183890,56 +187327,45 @@ "13.3.2(a)", "13.3.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "PS-01" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "12.27", - "18.1", - "18.2", - "18.10" - ], - "emea-sau-cscc-1-2019": [ - "2-3" + "PS-01", + "PS-02", + "PS-03" ], "emea-sau-ecc-1-2018": [ "2-3-1", "2-3-2", - "2-3-4", "2-14-1", "2-14-2", - "2-14-3", + "2-14-3-1", + "2-14-3-2", + "2-14-3-3", + "2-14-3-5", "2-14-4" ], "emea-sau-otcc-1-2022": [ - "2-13", + "2-3-1", + "2-3-2", "2-13-1", - "2-13-1-8", - "2-13-1-9", "2-13-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-46" - ], "emea-sau-sama-csf-1-2017": [ - "3.3.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" + "3.3.2", + "3.3.2.1", + "3.3.2.3" ], "emea-esp-decree-311-2022": [ - "18" + "Article 12(6)(f)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.s.1" ], "emea-uae-niaf-2023": [ "3.2.2" @@ -183956,7 +187382,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0810" ], "apac-ind-sebi-2024": [ @@ -183971,7 +187397,7 @@ "11.1.4.1", "11.2.1.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP47", "HML47" ], @@ -183981,27 +187407,28 @@ ], "apac-nzl-ism-3-9": [ "5.7.4.C.01", - "8.1.10.C.01" + "8.1.10.C.01", + "20.2.16.C.01" ], "apac-sgp-mas-trm-2021": [ - "8.5.1", - "8.5.2", "8.5.5", - "8.5.6(a)", - "8.5.6(b)", - "8.5.6(c)", - "8.5.6(d)", - "8.5.6(e)", - "8.5.6(f)" + "8.5.6" ], "americas-can-osfi-b13-2022": [ "3.2.10" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.02", "03.10.01.A", - "03.10.07.A" + "03.10.07.A", + "03.10.07.A.01" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(a)" ] } }, @@ -184010,7 +187437,7 @@ "title": "Physical Security Plan (PSP)", "family": "PES", "description": "Mechanisms exist to document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats.", - "scf_question": "Does the organization document a Site Security Plan (SitePlan) for each server and communications room to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats?", + "scf_question": "Does the organization document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats?", "relative_weight": 4, "conformity_cadence": "Annual", "evidence_requests": [ @@ -184025,7 +187452,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -184094,7 +187521,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -184105,13 +187533,14 @@ "CIP-006-6 R1", "CIP-006-6 1.1" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-deu-c5-2020": [ + "PS-02", + "PS-03" ], "apac-ind-sebi-2024": [ "PR.IP.S9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP13", "HML13" ], @@ -184120,6 +187549,9 @@ ], "apac-nzl-ism-3-9": [ "8.2.7.C.01" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" ] } }, @@ -184212,7 +187644,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -184221,6 +187654,10 @@ ], "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.2" + ], + "emea-deu-c5-2020": [ + "PS-01-DOAR", + "PS-03-BP1" ] } }, @@ -184320,7 +187757,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -184415,13 +187853,15 @@ "3.10.1" ], "general-nist-800-171-r3": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.a", "03.10.01.b", "03.10.01.c", "03.10.01.d", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "general-nist-800-171a": [ "3.10.1[a]", @@ -184431,10 +187871,14 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", "A.03.10.01.a[01]", "A.03.10.01.a[02]", "A.03.10.01.a[03]", + "A.03.10.01.b", "A.03.10.01.c", "A.03.10.01.d", "A.03.10.07.a.01" @@ -184471,9 +187915,6 @@ "9.2.1", "9.3.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -184514,13 +187955,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PE-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.B.3.2", @@ -184557,24 +188001,23 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-02" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.3.34" + ], "emea-eu-nis2-annex-2024": [ "13.3.1" ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.3" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" - ], "emea-sau-otcc-1-2022": [ "2-13-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-86" + "VII.B.TPC-86" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" ], "emea-gbr-def-stan-05-138-2024": [ "1500" @@ -184592,7 +188035,7 @@ "11.1.2.3", "11.1.2.12" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -184606,14 +188049,19 @@ "apac-sgp-mas-trm-2021": [ "8.5.6(a)" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.A", "03.10.01.B", "03.10.01.C", "03.10.01.D", - "03.10.07.A" + "03.10.07.A", + "03.10.07.A.01" ] } }, @@ -184639,11 +188087,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ The Human Resources (HR) department maintains a current list of personnel with authorized access to organizational facilities and facilitates the implementation of physical access management controls.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to authorize physical access to facilities based on the position or role of the individual.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -184712,7 +188160,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -184764,6 +188213,7 @@ "3.10.1" ], "general-nist-800-171-r3": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.b", @@ -184771,8 +188221,12 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[01]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", - "A.03.10.01.b" + "A.03.10.01.b", + "A.03.10.01.d" ], "general-nist-csf-2-0": [ "PR.AA-06" @@ -184808,9 +188262,6 @@ "9.3.1", "9.3.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -184827,11 +188278,14 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(viii)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "PE-2(1)" @@ -184843,17 +188297,15 @@ "7123(c)(3)(D)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(34)" - ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.4" + "3.4.3.34" ], "emea-sau-sacs-002-2022": [ - "TPC-86" + "VII.B.TPC-86" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "1502", @@ -184871,13 +188323,14 @@ "1502", "2422" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP04" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.B", @@ -184903,7 +188356,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to enforce a \"two-person rule\" for physical access by requiring two authorized individuals with separate access cards, keys or PINs, to access highly-sensitive areas (e.g., safe, high-security cage, etc.).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -184969,7 +188422,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -185005,7 +188459,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls and technologies ensure that only authorized personnel are allowed access to secure areas.\n▪ A facilities maintenance team, or similar function, manages the operation of automated physical and environmental protection controls.\n▪ Physical security controls and technologies are configured to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -185095,7 +188549,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -185208,6 +188663,7 @@ "3.10.5" ], "general-nist-800-171-r3": [ + "03.04.05", "03.10.02.a", "03.10.07.a", "03.10.07.a.01", @@ -185221,12 +188677,11 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[03]", + "A.03.10.02.a[01]", + "A.03.10.07.a.01", "A.03.10.07.a.02", "A.03.10.07.d" ], - "general-nist-800-172": [ - "3.1.2e" - ], "general-nist-csf-2-0": [ "PR.AA", "PR.AA-06", @@ -185255,9 +188710,6 @@ "9.1.2", "9.2.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -185306,15 +188758,18 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PE-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ "2.B.3.4", @@ -185368,27 +188823,22 @@ "13.3.2(b)" ], "emea-deu-c5-2020": [ - "PS-03", - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "12.27", - "18.4" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" + "PS-02-DOAR" ], "emea-sau-otcc-1-2022": [ "2-13-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-47", - "TPC-82", - "TPC-86" + "VII.B.TPC-82" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.a" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" ], "emea-uae-niaf-2023": [ "3.2.2" @@ -185405,7 +188855,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1296" ], "apac-ind-sebi-2024": [ @@ -185426,7 +188876,7 @@ "11.1.2.5", "11.1.2.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP48", "HML48" ], @@ -185434,13 +188884,17 @@ "HSUP40" ], "apac-sgp-mas-trm-2021": [ - "8.5.6(c)", - "5.5.6(f)" + "8.5.6(e)" + ], + "americas-arg-ppd-2018": [ + "B.2.4-1", + "B.2.4-2" ], "americas-can-osfi-b13-2022": [ "3.2.10" ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.10.02.A", "03.10.07.A", "03.10.07.A.01", @@ -185555,7 +189009,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -185581,8 +189036,14 @@ "general-nist-800-171-r3": [ "03.10.02.a", "03.10.07.a", + "03.10.07.a.01", "03.10.07.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], "general-pci-dss-4-0-1": [ "9.2", "9.2.1", @@ -185612,29 +189073,21 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(b)" ], - "emea-deu-c5-2020": [ - "PS-03" - ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.6", - "18.8" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-82" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.1", + "mp.if.2", + "mp.if.7" ], "apac-sgp-mas-trm-2021": [ - "5.5.6(f)" + "8.5.6(c)" + ], + "americas-arg-ppd-2018": [ + "B.2.4-3" ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", "03.10.07.A", + "03.10.07.A.01", "03.10.07.A.02" ] } @@ -185659,7 +189112,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect system components from unauthorized physical access (e.g., lockable physical casings).", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect system components from unauthorized physical access (e.g., lockable physical casings). ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -185719,7 +189172,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -185771,21 +189225,11 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-07(14)" ], - "emea-isr-cmo-1-0": [ - "18.6", - "18.11" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-4" - ], "emea-sau-sacs-002-2022": [ - "TPC-46" + "VII.B.TPC-46" ], "apac-nzl-ism-3-9": [ "8.2.5.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(d)" ] } }, @@ -185794,7 +189238,7 @@ "title": "Physical Access Logs", "family": "PES", "description": "Physical access control mechanisms generate a log entry for each access attempt through controlled ingress and egress points.", - "scf_question": "Does the organization generate a log entry for each access attempt through controlled ingress and egress points?", + "scf_question": "Physical access control mechanisms generate a log entry for each access attempt through controlled ingress and egress points?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -185809,7 +189253,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Where applicable, physical security controls and technologies are configured to generate a log entry for each access attempt through controlled ingress and egress points.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to generate a log entry for each access attempt through controlled ingress and egress points.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -185892,7 +189336,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -185958,12 +189403,15 @@ ], "general-nist-800-171-r3": [ "03.10.02.a", + "03.10.07.a.02", "03.10.07.b" ], "general-nist-800-171a": [ "3.10.4" ], "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.02", "A.03.10.07.b" ], "general-nist-csf-2-0": [ @@ -186043,12 +189491,13 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "18.5" - ], "emea-sau-ecc-1-2018": [ "2-14-3-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -186064,8 +189513,13 @@ "apac-jpn-ismap": [ "11.1.2.7" ], + "americas-arg-ppd-2018": [ + "B.2.4-3", + "B.2.4-4" + ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", + "03.10.07.A.02", "03.10.07.B" ] } @@ -186074,8 +189528,8 @@ "control_id": "PES-03.4", "title": "Access To Critical Systems", "family": "PES", - "description": "Physical access control mechanisms exist to enforce physical access to critical systems or sensitive/regulated data, in addition to the physical access controls for the facility.", - "scf_question": "Does the organization enforce physical access to critical systems or sensitive/regulated data, in addition to the physical access controls for the facility?", + "description": "Physical access control mechanisms exist to enforce physical access to critical systems or sensitive and/or regulated data, in addition to the physical access controls for the facility.", + "scf_question": "Does the organization enforce physical access to critical systems or sensitive and/or regulated data, in addition to the physical access controls for the facility?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -186174,7 +189628,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -186231,6 +189686,10 @@ "03.10.07.a.01", "03.10.07.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], "general-tisax-6-0-3": [ "5.3.4" ], @@ -186247,28 +189706,21 @@ "PE-03(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-cms-marse-2-0": [ "PE-3-IS.2" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" - ], "emea-sau-otcc-1-2022": [ "2-13-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-46", - "TPC-49" + "VII.B.TPC-46" ], "emea-gbr-def-stan-05-138-2024": [ "1502" @@ -186282,7 +189734,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1502" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0813", "ISM-1053", "ISM-1074", @@ -186291,7 +189743,7 @@ "apac-ind-sebi-2024": [ "PR.AA.S10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP10", "HML10" ], @@ -186333,7 +189785,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls and technologies are primarily designed and implemented for offices, rooms and facilities that focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to identify systems, equipment and respective operating environments that require limited physical access so that appropriate physical access controls are designed and implemented for offices, rooms and facilities.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to identify systems, equipment and respective operating environments that require limited physical access so that appropriate physical access controls are designed and implemented for offices, rooms and facilities. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -186418,7 +189870,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -186475,6 +189928,14 @@ "03.10.07.a.02", "03.10.07.d" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" + ], "general-pci-dss-4-0-1": [ "9.3.1.1" ], @@ -186484,9 +189945,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.3.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -186505,14 +189963,15 @@ "52.204-21(b)(1)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ + "2.B.3", "2.B.3.3" ], "usa-state-ca-ccpa-cpra-2026": [ @@ -186521,21 +189980,23 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(c)" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "18.6" - ], "emea-sau-ecc-1-2018": [ "2-14-3-5" ], "emea-sau-otcc-1-2022": [ "2-13-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-46" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.c" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.eq.1", + "mp.eq.2" ], "apac-jpn-ismap": [ "11.1.2.6", @@ -186552,7 +190013,7 @@ "11.2.9.5", "11.2.9.6" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP48", "HML48" ], @@ -186563,9 +190024,6 @@ "8.2.6.C.01", "8.2.6.C.02" ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(e)" - ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.02", @@ -186593,9 +190051,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to allow only authorized personnel access to secure areas.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to allow only authorized personnel access to secure areas. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -186679,7 +190137,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -186722,8 +190181,13 @@ "03.10.07.a.02", "03.10.07.d" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" ], "general-pci-dss-4-0-1": [ "9.3.1.1" @@ -186741,10 +190205,13 @@ "SC.L3-3.13.4E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(c)" + "§ 164.310(c)" + ], + "usa-federal-irs-1075-2021": [ + "2.B.3" ], "usa-federal-dow-safeguarding-nnpi-2010": [ "8-3.a(2)" @@ -186752,19 +190219,18 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(3)(D)" ], - "emea-isr-cmo-1-0": [ - "18.6" - ], "emea-sau-ecc-1-2018": [ "2-14-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-5" - ], "emea-sau-sacs-002-2022": [ - "TPC-49" + "VII.B.TPC-49" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "mp.if.2", + "mp.if.7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ @@ -186777,9 +190243,8 @@ "11.1.5.5", "11.1.5.6" ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(e)", - "5.5.6(f)" + "apac-nzl-ism-3-9": [ + "17.9.36.C.02" ], "americas-can-itsp-10-171-2025": [ "03.08.01", @@ -186808,7 +190273,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to inspect personnel and their personal effects (e.g., personal property ordinarily worn or carried by the individual, including vehicles) to prevent the unauthorized exfiltration of data and technology assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -186890,7 +190355,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -187004,7 +190470,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": {} @@ -187118,7 +190585,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -187214,6 +190682,14 @@ "A.03.10.02.b[01]", "A.03.10.02.b[02]" ], + "general-nist-800-172-r3": [ + "03.10.01E", + "03.10.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[02]", + "DS-A.03.10.02E.b" + ], "general-nist-csf-2-0": [ "DE.CM-02" ], @@ -187229,9 +190705,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.2.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -187290,17 +190763,15 @@ "13.1.2(f)", "13.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "18.8", - "18.10", - "18.11" - ], "emea-sau-cgiot-2024": [ "2-13-1" ], "emea-sau-ecc-1-2018": [ "2-14-3-2" ], + "emea-sau-otcc-1-2022": [ + "2-13-1-2" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -187319,16 +190790,13 @@ "apac-jpn-ismap": [ "11.1.2.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP66", "HML65" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP57" ], - "apac-sgp-mas-trm-2021": [ - "5.5.5" - ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", "03.10.02.B" @@ -187355,9 +190823,9 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Where applicable, physical security controls and technologies are configured to monitor for, detect and respond to physical security incidents.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to monitor physical intrusion alarms and surveillance equipment.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to monitor physical intrusion alarms and surveillance equipment. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -187425,7 +190893,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -187477,13 +190946,21 @@ "NFO - PE-6(1)" ], "general-nist-800-171-r3": [ - "03.10.02.a", - "03.10.02.b" + "03.10.02.a" ], "general-nist-800-171a": [ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]" + ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[02]" + ], "general-pci-dss-4-0-1": [ "9.2.1.1" ], @@ -187524,10 +191001,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-06 (01)" ], - "emea-isr-cmo-1-0": [ - "18.9", - "18.11" - ], "emea-sau-cgiot-2024": [ "2-13-1" ], @@ -187537,6 +191010,9 @@ "emea-sau-otcc-1-2022": [ "2-13-1-2" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.b" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -187549,12 +191025,8 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-chn-pipl-2021": [ - "26" - ], "americas-can-itsp-10-171-2025": [ - "03.10.02.A", - "03.10.02.B" + "03.10.02.A" ] } }, @@ -187562,8 +191034,8 @@ "control_id": "PES-05.2", "title": "Monitoring Physical Access To Critical Systems", "family": "PES", - "description": "Facility security mechanisms exist to monitor physical access to critical systems or sensitive/regulated data, in addition to the physical access monitoring of the facility.", - "scf_question": "Does the organization monitor physical access to critical systems or sensitive/regulated data, in addition to the physical access monitoring of the facility?", + "description": "Facility security mechanisms exist to monitor physical access to critical systems or sensitive and/or regulated data, in addition to the physical access monitoring of the facility.", + "scf_question": "Does the organization monitor physical access to critical systems or sensitive and/or regulated data, in addition to the physical access monitoring of the facility?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -187647,7 +191119,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -187701,6 +191174,17 @@ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.02.b[01]", + "A.03.10.02.b[02]" + ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[01]" + ], "general-pci-dss-4-0-1": [ "9.2.1.1" ], @@ -187719,8 +191203,8 @@ "usa-federal-gsa-fedramp-5-high": [ "PE-06(04)" ], - "apac-sgp-mas-trm-2021": [ - "8.5.5" + "emea-sau-otcc-1-2022": [ + "2-13-1-7" ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", @@ -187750,9 +191234,9 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.\n▪ Users are trained and encouraged to stop and question anyone attempting to install or remove IT assets from facilities.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible).", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible). ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -187838,7 +191322,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -187862,7 +191347,7 @@ "3.10.3" ], "general-nist-800-171-r3": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "general-nist-800-171a": [ @@ -187870,9 +191355,16 @@ "3.10.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.10.01.a[02]", "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.10.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "9.3.2", "9.3.3", @@ -187888,9 +191380,6 @@ "9.3.3", "9.3.4" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -187907,10 +191396,10 @@ "52.204-21(b)(1)(ix)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.B.3.1", @@ -187939,24 +191428,19 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(3)(D)" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "18.3", - "18.12" - ], "emea-sau-otcc-1-2022": [ "2-13-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-47" + "VII.B.TPC-47", + "VII.B.TPC-47-BP2", + "VII.B.TPC-47-BP3" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.2 [MP.IF.2]", - "8.1.7 [MP.IF.7]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ @@ -187974,11 +191458,10 @@ "9.4.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "8.5.6(b)", - "5.5.6(f)" + "8.5.6(b)" ], "americas-can-itsp-10-171-2025": [ - "03.10.02.B", + "03.10.01.A", "03.10.07.C" ] } @@ -187987,8 +191470,8 @@ "control_id": "PES-06.1", "title": "Distinguish Visitors from On-Site Personnel", "family": "PES", - "description": "Physical access control mechanisms exist to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", - "scf_question": "Does the organization easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible?", + "description": "Physical access control mechanisms exist to easily distinguish between onsite personnel and visitors, especially in areas where sensitive and/or regulated data is accessible.", + "scf_question": "Does the organization easily distinguish between onsite personnel and visitors, especially in areas where sensitive and/or regulated data is accessible?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -188003,7 +191486,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -188087,7 +191570,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -188095,7 +191579,7 @@ "3.10.3" ], "general-nist-800-171-r3": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "general-nist-800-171a": [ @@ -188103,6 +191587,7 @@ "3.10.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.10.01.a[02]", "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], @@ -188124,9 +191609,6 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(ix)" ], - "emea-sau-sacs-002-2022": [ - "TPC-47" - ], "emea-gbr-def-stan-05-138-2024": [ "1503" ], @@ -188143,7 +191625,7 @@ "11.1.2.8" ], "americas-can-itsp-10-171-2025": [ - "03.10.02.B", + "03.10.01.A", "03.10.07.C" ] } @@ -188153,7 +191635,7 @@ "title": "Identification Requirement", "family": "PES", "description": "Physical access control mechanisms exist to requires at least one(1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility.", - "scf_question": "Does the organization require at least one (1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility?", + "scf_question": "Does the organization requires at least one(1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -188240,7 +191722,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -188259,6 +191742,10 @@ "general-nist-800-171-r3": [ "03.10.07.c" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], "general-pci-dss-4-0-1": [ "9.3.2" ], @@ -188275,10 +191762,7 @@ "CIP-006-6 2.2" ], "emea-sau-sacs-002-2022": [ - "TPC-47" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.2 [MP.IF.2]" + "VII.B.TPC-47-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "1503" @@ -188315,9 +191799,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Users are trained and encouraged to stop and question anyone attempting to install or remove IT assets from facilities.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict unescorted access to facilities to personnel with required security clearances, formal access authorizations and validate the need for access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict unescorted access to facilities to personnel with required security clearances, formal access authorizations and validate the need for access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -188399,7 +191883,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -188450,19 +191935,19 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(ix)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" + ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 4.1.2", "CIP-006-6 1.2", "CIP-006-6 1.3", "CIP-006-6 2.1" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" - ], "emea-sau-sacs-002-2022": [ - "TPC-48" + "VII.B.TPC-48" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ @@ -188496,7 +191981,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to automatically facilitate the maintenance and review of visitor access records.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -188538,7 +192023,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -188598,7 +192084,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to minimize the collection of Personal Data (PD) contained in visitor access records.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -188678,7 +192164,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -188841,7 +192328,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -188851,6 +192339,10 @@ "general-nist-800-171-r3": [ "03.10.07.c" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], "general-pci-dss-4-0-1": [ "9.3.3" ], @@ -188860,9 +192352,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.3.3" ], - "emea-sau-sacs-002-2022": [ - "TPC-47" - ], "emea-gbr-def-stan-05-138-2024": [ "1503" ], @@ -188902,7 +192391,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power equipment and power cabling for the system from damage and destruction.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power equipment and power cabling for the system from damage and destruction. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -188971,7 +192460,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -189036,6 +192526,9 @@ "general-nist-800-171-r3": [ "03.10.08" ], + "general-nist-800-171a-r3": [ + "A.03.10.08" + ], "general-nist-csf-2-0": [ "PR.IR-02" ], @@ -189056,18 +192549,19 @@ "PE-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-eu-nis2-annex-2024": [ "13.1.2(d)" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-06" + "PS-04" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.d" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.3 [MP.IF.3]", - "8.1.4 [MP.IF.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "apac-jpn-ismap": [ "11.2.2", @@ -189083,12 +192577,6 @@ "8.3.4.C.02", "8.3.5.C.01" ], - "apac-sgp-mas-trm-2021": [ - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" - ], "americas-can-itsp-10-171-2025": [ "03.10.08" ] @@ -189114,7 +192602,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize automatic voltage controls for critical system components.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize automatic voltage controls for critical system components. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -189177,7 +192665,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -189215,10 +192704,10 @@ "PE-09(02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.4 [MP.IF.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ] } }, @@ -189307,7 +192796,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -189380,6 +192870,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-10" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" + ], "apac-jpn-ismap": [ "11.2.2.7" ] @@ -189470,7 +192963,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -189564,12 +193058,10 @@ "13.1.2(a)" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-06" + "PS-04" ], - "emea-isr-cmo-1-0": [ - "18.14", - "18.15" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "emea-gbr-def-stan-05-138-2024": [ "2704" @@ -189583,7 +193075,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2704" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1123" ] } @@ -189608,7 +193100,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -189673,7 +193165,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -189758,8 +193251,11 @@ "emea-eu-nis2-annex-2024": [ "13.1.2(a)" ], - "emea-isr-cmo-1-0": [ - "18.16" + "emea-isr-cmo-2-0": [ + "Appendix A, 11.1" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "apac-jpn-ismap": [ "11.2.2.6" @@ -189786,9 +193282,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect systems from damage resulting from water leakage by providing master shutoff valves that are accessible, working properly and known to key personnel.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect systems from damage resulting from water leakage by providing master shutoff valves that are accessible, working properly and known to key personnel. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -189857,7 +193353,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -189946,13 +193443,10 @@ "PE-15" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], - "emea-deu-c5-2020": [ - "PS-01" - ], - "emea-isr-cmo-1-0": [ - "18.19" + "americas-arg-ppd-2018": [ + "D.1.2-DS-1" ] } }, @@ -189974,9 +193468,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to detect the presence of water in the vicinity of critical systems and alert facility maintenance and IT personnel.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to detect the presence of water in the vicinity of critical systems and alert facility maintenance and IT personnel. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -190040,7 +193534,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -190070,9 +193565,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "PE-15(01)" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.6 [MP.IF.6]" ] } }, @@ -190148,7 +193640,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -190163,6 +193656,9 @@ ], "general-nist-800-160-vol-2-r1": [ "PE-09(01)" + ], + "emea-deu-c5-2020": [ + "PS-04" ] } }, @@ -190188,7 +193684,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire suppression and detection devices/systems for the system that are supported by an independent energy source.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire suppression and detection devices/systems for the system that are supported by an independent energy source. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -190257,7 +193753,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -190340,21 +193837,22 @@ "PE-13" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-05" + "PS-03-BP1", + "PS-03-BP2", + "PS-03-BP4", + "PS-03-BP6" ], - "emea-isr-cmo-1-0": [ - "18.17" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.5 [MP.IF.5]" + "emea-isr-cmo-2-0": [ + "Appendix A, 11.2" ], "apac-sgp-mas-trm-2021": [ - "8.5.3", - "8.5.4" + "8.5.3" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-1" ] } }, @@ -190378,7 +193876,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire detection devices/systems that activate automatically and notify organizational personnel and emergency responders in the event of a fire.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire detection devices/systems that activate automatically and notify organizational personnel and emergency responders in the event of a fire. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -190444,7 +193942,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -190494,14 +193993,10 @@ "PE-13(1)" ], "emea-deu-c5-2020": [ - "PS-05" - ], - "emea-isr-cmo-1-0": [ - "18.17" + "PS-03-BP5" ], "apac-sgp-mas-trm-2021": [ - "8.5.3", - "8.5.4" + "8.5.3" ] } }, @@ -190523,9 +194018,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize fire suppression devices/systems that provide automatic notification of any activation to organizational personnel and emergency responders.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize fire suppression devices/systems that provide automatic notification of any activation to organizational personnel and emergency responders. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -190589,7 +194084,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -190639,10 +194135,7 @@ "PE-13(3)" ], "emea-deu-c5-2020": [ - "PS-05" - ], - "emea-isr-cmo-1-0": [ - "18.17" + "PS-03-BP5" ], "emea-gbr-def-stan-05-138-2024": [ "2704" @@ -190655,6 +194148,9 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2704" + ], + "apac-sgp-mas-trm-2021": [ + "8.5.3" ] } }, @@ -190742,7 +194238,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -190790,9 +194287,6 @@ ], "usa-federal-cms-marse-2-0": [ "PE-13(2)" - ], - "emea-deu-c5-2020": [ - "PS-05" ] } }, @@ -190886,7 +194380,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -190973,17 +194468,14 @@ "PE-14" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-eu-nis2-annex-2024": [ "13.1.2(f)" ], "emea-deu-c5-2020": [ - "PS-06", - "PS-07" - ], - "emea-isr-cmo-1-0": [ - "18.18" + "PS-03-BP3", + "PS-03-DOAR" ], "emea-gbr-def-stan-05-138-2024": [ "2704" @@ -191019,7 +194511,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to trigger an alarm or notification of temperature and humidity changes that be potentially harmful to personnel or equipment.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to trigger an alarm or notification of temperature and humidity changes that be potentially harmful to personnel or equipment. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -191084,7 +194576,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -191119,13 +194612,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "PE-14(02)" - ], - "emea-deu-c5-2020": [ - "PS-06", - "PS-07" - ], - "emea-isr-cmo-1-0": [ - "18.18" ] } }, @@ -191149,7 +194635,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -191229,7 +194715,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -191296,6 +194783,17 @@ "general-nist-800-171-r2": [ "NFO - PE-16" ], + "general-nist-800-172-r3": [ + "03.10.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.02E.a[01]", + "A.03.10.02E.ODP[01]", + "DS-A.03.10.02E.a[02]", + "DS-A.03.10.02E.a[03]", + "A.03.10.02E.ODP[02]", + "DS-A.03.10.02E.a[04]" + ], "general-tisax-6-0-3": [ "3.1.3", "5.3.3" @@ -191331,8 +194829,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-16" ], - "emea-isr-cmo-1-0": [ - "18.20" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" ], "apac-jpn-ismap": [ "11.1.6", @@ -191345,7 +194847,7 @@ "11.1.6.7" ], "apac-sgp-mas-trm-2021": [ - "5.5.6(f)" + "8.5.6(f)" ] } }, @@ -191455,7 +194957,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -191548,12 +195051,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-17" ], - "emea-deu-c5-2020": [ - "PS-02" - ], - "emea-isr-cmo-1-0": [ - "18.21" - ], "emea-gbr-def-stan-05-138-2024": [ "2312" ], @@ -191592,7 +195089,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to locate system components within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to locate system components within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -191679,7 +195176,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -191699,10 +195197,10 @@ "PE-18" ], "general-iso-27002-2022": [ - "7.12", "7.3", "7.5", - "7.8" + "7.8", + "7.12" ], "general-iso-27017-2015": [ "11.1.4", @@ -191771,8 +195269,9 @@ "03.10.07.e", "03.10.08" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.10.07.e", + "A.03.10.08" ], "general-pci-dss-4-0-1": [ "9.2.2", @@ -191840,15 +195339,15 @@ "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.10" ], - "emea-isr-cmo-1-0": [ - "18.7", - "18.13", - "18.22" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.e" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.3 [MP.IF.3]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1644" ], "apac-jpn-ismap": [ @@ -191895,9 +195394,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power and telecommunications cabling carrying data or supporting information services from interception, interference or damage.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power and telecommunications cabling carrying data or supporting information services from interception, interference or damage. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -191983,7 +195482,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -192109,11 +195609,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-04" ], - "emea-isr-cmo-1-0": [ - "9.15", - "18.13" + "emea-deu-c5-2020": [ + "PS-04" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0181", "ISM-0187", "ISM-0194", @@ -192154,7 +195653,10 @@ "ISM-1718", "ISM-1719", "ISM-1720", - "ISM-1721" + "ISM-1721", + "ISM-1820", + "ISM-1821", + "ISM-1822" ], "apac-jpn-ismap": [ "11.2.3", @@ -192281,7 +195783,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict access to printers and other system output devices to prevent unauthorized individuals from obtaining the output.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict access to printers and other system output devices to prevent unauthorized individuals from obtaining the output. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -192345,7 +195847,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -192439,12 +195942,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-05" ], - "emea-isr-cmo-1-0": [ - "18.7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1036" ], + "apac-nzl-ism-3-9": [ + "11.8.9.C.01" + ], "americas-can-itsp-10-171-2025": [ "03.10.07.E" ] @@ -192468,9 +195971,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect the system from information leakage due to electromagnetic signals emanations.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect the system from information leakage due to electromagnetic signals emanations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -192522,7 +196025,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -192544,7 +196048,7 @@ "general-nist-800-82-r3": [ "PE-19" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0246", "ISM-0249", "ISM-0250" @@ -192577,11 +196081,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to employ asset location technologies that track and monitor the location and movement of organization-defined assets within organization-defined controlled areas.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -192639,7 +196143,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -192717,7 +196222,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -192750,7 +196256,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to mark system hardware components indicating the impact or classification level of the information permitted to be processed, stored or transmitted by the hardware component.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -192810,7 +196316,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -192844,7 +196351,7 @@ "emea-sau-cgiot-2024": [ "2-6-1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1107", "ISM-1216", "ISM-1217", @@ -192876,7 +196383,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to automatically monitor physical proximity to robotic or autonomous platforms to reduce applied force or stop the operation when sensors indicate a potentially dangerous scenario.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -192927,7 +196434,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": {} @@ -192936,8 +196444,8 @@ "control_id": "PES-18", "title": "On-Site Client Segregation", "family": "PES", - "description": "Mechanisms exist to ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces.", - "scf_question": "Does the organization ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces?", + "description": "Mechanisms exist to ensure client-specific sensitive and/or regulated data is isolated from other data when client-specific sensitive and/or regulated data is processed or stored within multi-client workspaces.", + "scf_question": "Does the organization ensure client-specific sensitive and/or regulated data is isolated from other data when client-specific sensitive and/or regulated data is processed or stored within multi-client workspaces?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -192950,7 +196458,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -193026,13 +196534,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { - "general-nist-800-172": [ - "3.13.4e" - ], "general-tisax-6-0-3": [ "5.3.4", "8.1.8" @@ -193041,7 +196547,8 @@ "SC.L3-3.13.4E" ], "emea-sau-sacs-002-2022": [ - "TPC-38" + "VII.B.TPC-38", + "VII.B.TPC-49" ] } }, @@ -193067,7 +196574,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to maintain an accurate inventory of all physical access devices (e.g., RFID cards, access fobs, door keys, etc.).", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -193139,7 +196646,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -193178,7 +196686,7 @@ }, "maturity": { "0": "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.", - "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.\n▪ Data/process owners are expected to take the initiative to work with Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ No formal data privacy principles are identified for the organization.\n▪ Data/process owners perform their own Data Protection Impact Assessment (DPIA).", + "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.\n▪ Data/process owners are expected to take the initiative to work with Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ No formal data privacy principles are identified for the organization.\n▪ Data/process owners perform their own Data Protection Impact Assessment (DPIA). ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is formally assigned as the Chief Privacy Officer (CPO), or similar role, to lead the organization's data privacy program. This individual may be assigned to multiple data privacy-related roles.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to facilitate the implementation and operation of data protection controls throughout the data lifecycle to ensure all forms of Personal Data (PD) are processed lawfully, fairly and transparently.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -193255,7 +196763,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -193322,7 +196831,7 @@ "7.5.3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-100-1-ai-rmf": [ "MAP 1.6" @@ -193386,10 +196895,6 @@ "general-oecd-privacy-principles-2010": [ "8" ], - "general-scf-dpmp-2025": [ - "1.0", - "1.1" - ], "general-shared-assessments-sig-2025": [ "P.3" ], @@ -193421,14 +196926,14 @@ "155.260(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)", - "164.530(a)(1)(i)", - "164.530(i)(1)", - "164.530(i)(4)(i)(A)", - "164.530(i)(4)(i)(B)", - "164.530(i)(5)", - "164.530(i)(5)(i)", - "164.530(i)(5)(ii)" + "§ 164.502(a)", + "§ 164.530(a)(1)(i)", + "§ 164.530(i)(1)", + "§ 164.530(i)(4)(i)(A)", + "§ 164.530(i)(4)(i)(B)", + "§ 164.530(i)(5)", + "§ 164.530(i)(5)(i)", + "§ 164.530(i)(5)(ii)" ], "usa-federal-irs-1075-2021": [ "PM-18", @@ -193467,221 +196972,73 @@ "Article 9.1", "Article 12.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "4" - ], "emea-deu-fdpa-2017": [ - "Inferred", - "Expectation" - ], - "emea-grc-pirppd-1997": [ - "Inferred", - "Expectation" - ], - "emea-hun-isdfi-2011": [ - "Inferred", - "Expectation" - ], - "emea-irl-dpa-2003": [ - "Inferred", - "Expectation" + "2.1.2.26(5)" ], - "emea-isr-ppl-5741-1981": [ - "Inferred", - "Expectation" + "emea-hun-act-cxii-2011": [ + "II.6.7(1)" ], - "emea-ita-pdpc-2003": [ - "Inferred", - "Expectation" + "emea-isr-cmo-2-0": [ + "Appendix F" ], "emea-ken-pda-2019": [ - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)" + "IV.25" ], "emea-nga-dpr-2019": [ "4.1(3)" ], - "emea-nor-pda-2018": [ - "Inferred", - "Expectation" - ], - "emea-pol-act-29-1997": [ - "Inferred", - "Expectation" - ], "emea-qat-pdppl-2020": [ - "2", - "3", - "8.1" - ], - "emea-rus-federal-law-27-2006": [ - "Inferred", - "Expectation" + "3.11", + "3.11.5" ], "emea-sau-pdpl-2023": [ "Article 11.2" ], - "emea-srb-act-9-2018": [ - "5.1", - "59", - "59.1", - "59.2", - "59.3", - "59.4", - "59.5", - "59.6", - "59.7", - "59.8", - "59.9", - "59.10", - "59.11" - ], - "emea-zaf-popia-2013": [ - "19", - "20", - "60" - ], - "emea-esp-decree-1720-2007": [ - "Inferred", - "Expectation" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.1 [MP.INFO.1]" - ], - "emea-che-fadp-2025": [ - "Inferred", - "Expectation" - ], - "emea-tur-lppd-2016": [ - "Inferred", - "Expectation" - ], - "emea-gbr-dpa-1998": [ - "Inferred", - "Expectation" - ], - "apac-aus-privacy-act-1998": [ - "Inferred", - "Expectation" - ], - "apac-aus-privacy-principles-2026": [ - "APP 1" - ], - "apac-chn-csnip-2012": [ - "Inferred", - "Expectation" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "mp.info.1" ], "apac-chn-pipl-2021": [ - "7", - "16", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)", - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)", - "59" - ], - "apac-hkg-pdo-2022": [ - "Inferred", - "Expectation" + "Article 51" ], "apac-ind-privacy-rules-2011": [ - "Inferred", - "Expectation" + "8(1)" ], - "apac-jpn-ppi-2020": [ - "24(3)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" + "apac-jpn-appi-2020": [ + "IV.5.53(1)" ], "apac-jpn-ismap": [ "5.1.1", "5.1.1.19", "18.1.4" ], - "apac-mys-pdpa-2010": [ - "23" - ], "apac-phl-dpa-2012": [ - "Inferred", - "Expectation" - ], - "apac-sgp-pdpa-2012": [ - "12" - ], - "apac-kor-pipa-2011": [ - "3", - "30" - ], - "apac-twn-pdpa-2025": [ - "Inferred", - "Expectation" + "III.11" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.8", - "6.10", - "50" - ], - "americas-can-pipeda-2000": [ - "Principle 1", - "Principle 8" - ], - "americas-chl-act-19628-1999": [ - "Inferred", - "Expectation" + "V.45(2)(a)", + "V.45(2)(b)", + "V.45(2)(b)(i)", + "V.45(2)(b)(ii)" ], "americas-col-law-1581-2012": [ - "4" + "VI.18(a)", + "VI.18(b)", + "VI.18(c)", + "VI.18(d)", + "VI.18(e)", + "VI.18(f)", + "VI.18(g)", + "VI.18(h)", + "VI.18(i)", + "VI.18(j)", + "VI.18(k)", + "VI.18(l)" ], "americas-mex-fdpa-2010": [ - "6", - "14", - "30" + "II.6", + "II.14" ] } }, @@ -193690,7 +197047,7 @@ "title": "Chief Privacy Officer (CPO)", "family": "PRI", "description": "Mechanisms exist to appoints a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program.", - "scf_question": "Does the organization have a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program?", + "scf_question": "Does the organization appoints a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [ @@ -193705,7 +197062,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is formally assigned as the Chief Privacy Officer (CPO), or similar role, to lead the organization's data privacy program. This individual may be assigned to multiple data privacy-related roles.\n▪ The CPO, or similar role, identifies appropriate data privacy controls that Technology Assets, Applications and/or Services (TAAS) and third-parties must adhere to, in addition to applicable statutory, regulatory and/or contractual obligations.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ A Chief Privacy Officer (CPO) or similar role, has the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -193753,7 +197110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -193776,7 +197134,7 @@ "5.3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.PO-P3" @@ -193811,14 +197169,11 @@ "general-oecd-privacy-principles-2010": [ "8" ], - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(a)(1)(i)" + "§ 164.530(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "PM-19" @@ -193826,61 +197181,36 @@ "usa-federal-cms-marse-2-0": [ "AR-1.a" ], - "emea-deu-fdpa-2017": [ - "Sec 4d", - "Sec 4f", - "Sec 4g" - ], - "emea-hun-isdfi-2011": [ - "24" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "30" - ], - "emea-pol-act-29-1997": [ - "46" - ], - "emea-qat-pdppl-2020": [ - "8.1" - ], - "emea-rus-federal-law-27-2006": [ - "23" - ], - "emea-zaf-popia-2013": [ - "55", - "56" - ], - "apac-chn-pipl-2021": [ - "9", - "52" - ], - "apac-jpn-ppi-2020": [ - "21" + "apac-phl-dpa-2012": [ + "VI.21", + "VI.21(a)", + "VI.21(b)" ], "apac-sgp-pdpa-2012": [ - "11" + "3.11(3)", + "3.11(4)" ], "apac-kor-pipa-2011": [ - "31" + "IV.31(1)", + "IV.31(2)", + "IV.31(2)1", + "IV.31(2)2", + "IV.31(2)3", + "IV.31(2)4", + "IV.31(2)5", + "IV.31(2)6", + "IV.31(2)7", + "IV.31(3)", + "IV.31(4)", + "IV.31(5)" ], - "americas-bra-lgpd-2018": [ - "6.8", - "6.10" + "americas-can-pipeda-2000": [ + "P1-4.1", + "P1-4.1.1", + "P1-4.1.2" ], "americas-chl-act-19628-1999": [ - "7", - "11" - ], - "americas-col-law-1581-2012": [ - "17", - "18" + "I.5" ] } }, @@ -193949,7 +197279,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -193971,15 +197302,9 @@ "general-nist-800-82-r3": [ "PT-05(02)" ], - "general-scf-dpmp-2025": [ - "4.0" - ], "usa-federal-cms-marse-2-0": [ "TR-2", "TR-2.c" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 8" ] } }, @@ -193988,7 +197313,7 @@ "title": "Dissemination of Data Privacy Program Information", "family": "PRI", "description": "Mechanisms exist to: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes.", - "scf_question": "Does the organization: \n (1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n (2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n (3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n (4) Inform data subjects when changes are made to the privacy notice and the nature of such changes?", + "scf_question": "Does the organization: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -194001,11 +197326,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -194058,7 +197383,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -194124,10 +197450,6 @@ "general-oecd-privacy-principles-2010": [ "6" ], - "general-scf-dpmp-2025": [ - "1.0", - "11.2" - ], "usa-federal-omb-fipps-1973": [ "8" ], @@ -194142,12 +197464,12 @@ "usa-state-va-cdpa-2023": [ "59.1-581.A.2" ], - "apac-aus-privacy-principles-2026": [ - "APP 1" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2" ], - "apac-chn-pipl-2021": [ - "9", - "48" + "apac-jpn-appi-2020": [ + "IV.5.53(3)" ], "apac-jpn-ismap": [ "5.1.1" @@ -194174,7 +197496,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Data/process owners work with IT and/or cybersecurity personnel and Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ A Data Protection Officer (DPO) is appointed:\n(1) Based on professional qualifications; and\n(2) To be involved in all issues related to how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -194232,23 +197554,21 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.PO-P3", "CT.PO-P2", "CM.PO-P2" ], - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(a)(1)(ii)" + "§ 164.530(a)(1)(ii)" ], "emea-eu-gdpr-2016": [ "Article 27.1", @@ -194280,69 +197600,171 @@ "Article 39.1(e)", "Article 39.2" ], + "emea-aut-dpa-2018": [ + "§ 5(1)", + "§ 57(1)", + "§ 57(2)", + "§ 57(3)", + "§ 57(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 5, Art. 63", + "Title 2, Chapter IV, Section 5, Art. 64", + "Title 2, Chapter IV, Section 5, Art. 65", + "Title 4, Chapter II, Art. 190", + "Title 4, Chapter II, Art. 191", + "Title 4, Chapter II, Art. 192" + ], + "emea-deu-fdpa-2017": [ + "2.1.1.22(2)4", + "2.3.38(1)", + "2.3.38(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.18.24(1)(a)", + "II.18.24(1)(b)", + "II.18.24(1)(c)", + "II.18.24(2)", + "II.18.24(2)(a)", + "II.18.24(2)(b)", + "II.18.24(2)(c)", + "II.18.24(2)(d)", + "II.18.24(2)(e)", + "II.18.24(2)(f)" + ], + "emea-irl-dpa-2018": [ + "s.88" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B1", + "s.17B2" + ], + "emea-ita-pdpc-2018": [ + "Article 2-q(1)" + ], "emea-ken-pda-2019": [ - "24(1)", - "24(1)(a)", - "24(1)(b)", - "24(1)(c)", - "24(2)", - "24(3)", - "24(4)", - "24(5)", - "24(6)", - "24(7)(a)", - "24(7)(b)", - "24(7)(c)", - "24(7)(d)", - "24(7)(e)" + "III.24(1)", + "III.24(1)(a)", + "III.24(1)(b)", + "III.24(1)(c)", + "III.24(2)", + "III.24(3)", + "III.24(4)", + "III.24(5)", + "III.24(6)", + "III.24(7)", + "III.24(7)(a)", + "III.24(7)(b)", + "III.24(7)(c)", + "III.24(7)(d)", + "III.24(7)(e)" ], "emea-nga-dpr-2019": [ - "4.1(2)", - "4.1(3)" + "4.1(2)" ], - "emea-qat-pdppl-2020": [ - "8.2", - "10" + "emea-nor-pda-2018": [ + "18", + "18(a)", + "18(b)", + "18(c)", + "18(d)" + ], + "emea-pol-act-10-2018": [ + "Art. 8", + "Art. 11a" + ], + "emea-rus-152-fz-2025": [ + "Art. 22.1" ], "emea-sau-pdpl-2023": [ "Article 30.2" ], "emea-srb-act-9-2018": [ - "44", - "44.1", - "44.2", - "56", - "56.1", - "56.2", - "56.3", - "57", - "58", - "58.1", - "58.2", - "58.3", - "58.4" + "IV.4.56", + "IV.4.56(1)", + "IV.4.56(2)", + "IV.4.56(3)", + "IV.4.57", + "IV.4.58", + "IV.4.58(1)", + "IV.4.58(2)", + "IV.4.58(3)", + "IV.4.58(4)" ], - "emea-zaf-popia-2013": [ - "17", - "55", - "56" + "emea-che-fadp-2025": [ + "2.1.10.1", + "2.1.10.2", + "2.1.10.2.b" + ], + "emea-gbr-dpa-2018": [ + "Section 69(1)", + "Section 69(2)", + "Section 69(2)(a)", + "Section 69(2)(b)", + "Section 69(3)", + "Section 70(1)", + "Section 70(2)", + "Section 70(2)(a)", + "Section 70(2)(b)", + "Section 70(3)", + "Section 70(3)(a)", + "Section 70(3)(b)", + "Section 70(3)(c)", + "Section 70(4)", + "Section 70(4)(a)", + "Section 70(4)(b)", + "Section 70(5)", + "Section 71(1)", + "Section 71(1)(a)", + "Section 71(1)(b)", + "Section 71(1)(c)", + "Section 71(1)(d)", + "Section 71(1)(e)", + "Section 71(1)(f)", + "Section 71(2)", + "Section 71(2)(a)", + "Section 71(2)(b)", + "Section 71(2)(c)", + "Section 71(2)(d)", + "Section 71(3)" ], "apac-chn-pipl-2021": [ - "9", - "52", - "53" + "Article 52", + "Article 54" ], "apac-ind-dpdpa-2023": [ "10(2)(a)", "10(2)(a)(iv)" ], + "americas-bhs-dpa-2003": [ + "V.45(1)", + "V.45(1)(a)", + "V.45(1)(b)", + "V.45(1)(c)", + "V.45(3)", + "V.45(3)(a)", + "V.45(3)(b)", + "V.45(3)(c)", + "V.45(3)(d)", + "V.45(3)(e)", + "V.45(3)(f)", + "V.45(3)(g)", + "V.45(3)(h)", + "V.45(3)(i)", + "V.45(3)(j)" + ], "americas-bra-lgpd-2018": [ - "6.8", - "6.10", - "41" + "VI.II.41", + "VI.II.41.1", + "VI.II.41.2", + "VI.II.41.2.I", + "VI.II.41.2.II", + "VI.II.41.2.III", + "VI.II.41.2.IV", + "VI.II.41.3" ], - "americas-can-pipeda-2000": [ - "Sec 6" + "americas-mex-fdpa-2010": [ + "IV.30" ] } }, @@ -194366,7 +197788,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to implement and manage Binding Corporate Rules (BCR) (e.g., data sharing agreement) to legally-bind all parties engaged in a joint economic activity that contractually states enforceable rights on data subjects with regard to the processing of their personal data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -194417,7 +197839,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -194452,30 +197875,337 @@ "Article 46.1", "Article 46.2(b)" ], + "emea-aut-dpa-2018": [ + "§ 58(1)", + "§ 58(2)", + "§ 58(3)", + "§ 59(1)", + "§ 59(2)", + "§ 59(3)", + "§ 59(5)", + "§ 59(6)", + "§ 59(7)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter V, Art. 66(1)", + "Title 2, Chapter V, Art. 66(2)", + "Title 2, Chapter V, Art. 67", + "Title 2, Chapter V, Art. 68(1)", + "Title 2, Chapter V, Art. 68(2)", + "Title 2, Chapter V, Art. 68(3)", + "Title 2, Chapter V, Art. 69(1)", + "Title 2, Chapter V, Art. 69(2)", + "Title 2, Chapter V, Art. 69(3)", + "Title 2, Chapter V, Art. 70(1)", + "Title 2, Chapter V, Art. 70(2)", + "Title 2, Chapter V, Art. 70(3)" + ], + "emea-deu-fdpa-2017": [ + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)8", + "3.4.62(5)9", + "3.4.62(6)", + "3.4.62(7)", + "3.4.63", + "3.5.78(1)", + "3.5.78(1)1", + "3.5.78(1)2", + "3.5.78(2)", + "3.5.78(3)", + "3.5.78(4)", + "3.5.79(1)", + "3.5.79(1)1" + ], + "emea-grc-pirppd-1997": [ + "B.9.1.b", + "B.9.2" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" + ], + "emea-irl-dpa-2018": [ + "s.96", + "s.97", + "s.98", + "s.99", + "s.100" + ], + "emea-ken-pda-2019": [ + "IV.25(h)", + "VI.49(1)", + "VI.49(2)", + "VI.49(3)", + "VI.50" + ], + "emea-nga-dpr-2019": [ + "2.11", + "2.11(a)", + "2.11(b)", + "2.11(c)", + "2.11(d)", + "2.11(e)", + "2.12" + ], "emea-qat-pdppl-2020": [ - "15" + "3.15" + ], + "emea-rus-152-fz-2025": [ + "Art. 12" ], "emea-sau-pdpl-2023": [ "Article 29.2.b" ], "emea-srb-act-9-2018": [ - "65", - "65.x", - "66", - "67", - "67.x" + "V.63", + "V.63(1)", + "V.63(2)", + "V.63(3)", + "V.63(4)", + "V.64", + "V.64(1)", + "V.64(2)", + "V.64(3)", + "V.65-1", + "V.65-1(1)", + "V.65-1(2)", + "V.65-1(3)", + "V.65-1(4)", + "V.65-1(5)", + "V.65-2", + "V.65-2(1)", + "V.65-2(2)", + "V.66", + "V.66(1)", + "V.66(2)", + "V.67-1", + "V.67-1(1)", + "V.67-1(2)", + "V.67-1(3)", + "V.67-2", + "V.67-2(1)", + "V.67-2(2)", + "V.67-2(3)", + "V.67-2(4)", + "V.67-2(5)", + "V.67-2(6)", + "V.67-2(7)", + "V.67-2(8)", + "V.67-2(9)", + "V.67-2(10)", + "V.67-2(11)", + "V.67-2(12)", + "V.67-2(13)", + "V.67-2(14)", + "V.68", + "V.69-1", + "V.69-1(1)", + "V.69-1(2)", + "V.69-1(3)", + "V.69-1(4)", + "V.69-1(5)", + "V.69-1(6)", + "V.69-1(7)", + "V.69-2", + "V.69-2(1)", + "V.69-2(2)", + "V.69-2(3)", + "V.69-2(4)", + "V.70", + "V.70(1)", + "V.70(2)", + "V.70(3)", + "V.70(4)", + "V.70(5)", + "V.71", + "V.71(1)", + "V.71(2)", + "V.71(3)", + "V.71(4)", + "V.71(5)", + "V.72", + "V.72(1)", + "V.72(2)", + "V.72(3)", + "V.72(4)" + ], + "emea-zaf-popia-2013": [ + "9.72(1)", + "9.72(1)(a)", + "9.72(1)(a)(i)", + "9.72(1)(a)(ii)", + "9.72(1)(b)", + "9.72(1)(c)", + "9.72(1)(d)", + "9.72(1)(e)", + "9.72(1)(e)(i)", + "9.72(1)(e)(ii)", + "9.72(2)", + "9.72(2)(a)", + "9.72(2)(b)" + ], + "emea-che-fadp-2025": [ + "2.3.16.1", + "2.3.16.2", + "2.3.16.2.a", + "2.3.16.2.b", + "2.3.16.2.c", + "2.3.16.2.d", + "2.3.16.2.e", + "2.3.16.3" + ], + "emea-tur-lppd-2016": [ + "9(1)", + "9(2)", + "9(3)", + "9(3)(a)", + "9(3)(b)", + "9(3)(c)", + "9(3)(ç)", + "9(3)(d)", + "9(3)(e)", + "9(4)", + "9(4)(a)", + "9(4)(b)", + "9(4)(c)", + "9(4)(ç)", + "9(5)", + "9(6)", + "9(6)(a)", + "9(6)(b)", + "9(6)(c)", + "9(6)(ç)", + "9(6)(d)", + "9(6)(e)", + "9(6)(f)", + "9(7)", + "9(8)", + "9(9)", + "9(10)", + "9(11)" + ], + "emea-gbr-dpa-2018": [ + "Section 78", + "Section 78(1)", + "Section 78(1)(a)", + "Section 78(1)(b)", + "Section 78(1)(b)(i)", + "Section 78(1)(b)(ii)", + "Section 78(1A)", + "Section 78(1A)(a)", + "Section 78(1A)(b)", + "Section 78(2)", + "Section 78(3)", + "Section 78(3)(a)", + "Section 78(3)(b)", + "Section 78(3)(c)", + "Section 78(4)", + "Section 78(5)", + "Section 78(5)(a)", + "Section 78(5)(b)", + "Section 78(6)", + "Section 78(7)", + "Section 78(7)(a)", + "Section 78(7)(b)" + ], + "apac-aus-privacy-principles-2026": [ + "3.8.1", + "3.8.1.a", + "3.8.1.b", + "3.8.2", + "3.8.2.a", + "3.8.2.a.i", + "3.8.2.a.ii", + "3.8.2.b", + "3.8.2.b.i", + "3.8.2.b.ii", + "3.8.2.c", + "3.8.2.d", + "3.8.2.e", + "3.8.2.f", + "3.8.2.f.i", + "3.8.2.f.ii" + ], + "apac-chn-pipl-2021": [ + "Article 38" + ], + "apac-ind-privacy-rules-2011": [ + "7" + ], + "apac-jpn-appi-2020": [ + "IV.1.24(1)", + "IV.1.24(2)", + "IV.1.24(3)" + ], + "apac-mys-pdpa-2010": [ + "129(1)", + "129(2)", + "129(2)(a)", + "129(2)(b)", + "129(3)", + "129(3)(a)", + "129(3)(b)", + "129(3)(c)", + "129(3)(c)(i)", + "129(3)(c)(ii)", + "129(3)(d)", + "129(3)(e)", + "129(3)(e)(i)", + "129(3)(e)(ii)", + "129(3)(e)(iii)", + "129(3)(f)", + "129(3)(g)", + "129(3)(h)", + "129(4)", + "129(4)(a)", + "129(4)(b)" ], "apac-nzl-privacy-act-2020": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "3.1.22.12(1)", + "3.1.22.12(1)(a)", + "3.1.22.12(1)(b)", + "3.1.22.12(1)(c)", + "3.1.22.12(1)(d)", + "3.1.22.12(1)(e)", + "3.1.22.12(1)(f)", + "3.1.22.12(2)", + "3.1.22.12(3)" + ], + "apac-sgp-pdpa-2012": [ + "6.26(1)" + ], + "americas-bra-lgpd-2018": [ + "V.33", + "V.33.I", + "V.33.II", + "V.33.II(a)", + "V.33.II(b)", + "V.33.II(c)", + "V.33.II(d)", + "V.33.III", + "V.33.IV", + "V.33.V", + "V.33.VI", + "V.33.VII", + "V.33.VIII", + "V.33.IX", + "V.34", + "V.34.I", + "V.34.II", + "V.34.III", + "V.34.IV", + "V.34.V", + "V.34.VI" ] } }, @@ -194497,7 +198227,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure Personal Data (PD) is protected by logical and physical security safeguards that are sufficient and appropriately scoped to protect the confidentiality and integrity of the PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -194546,7 +198276,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -194582,10 +198313,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.9.1" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" - ], "general-tisax-6-0-3": [ "7.1.2" ], @@ -194617,6 +198344,9 @@ "usa-state-il-pipa-2006": [ "45(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.1" + ], "usa-state-nv-regulation-5-2024": [ "5.260.1" ], @@ -194657,99 +198387,341 @@ "Article 32.1(a)", "Article 32.1(b)" ], + "emea-aut-dpa-2018": [ + "§ 6(1)", + "§ 13(1)", + "§ 54(1)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 34(2)", + "Title 2, Chapter III, Art. 45(4)", + "Title 2, Chapter IV, Section 1, Art. 50", + "Title 2, Chapter IV, Section 1, Art. 51(1)", + "Title 2, Chapter IV, Section 1, Art. 51(2)", + "Title 2, Chapter IV, Section 4, Art. 60(1)", + "Title 2, Chapter IV, Section 4, Art. 60(2)" + ], + "emea-deu-fdpa-2017": [ + "2.1.1.22(2)5", + "2.1.1.22(2)6", + "2.1.1.22(2)7", + "2.1.2.28(1)", + "3.2.53", + "3.4.62(5)2", + "3.4.64(1)", + "3.4.64(2)1", + "3.4.64(2)2", + "3.4.64(3)", + "3.4.64(3)1", + "3.4.64(3)2", + "3.4.64(3)3", + "3.4.64(3)4", + "3.4.64(3)5", + "3.4.64(3)6", + "3.4.64(3)7", + "3.4.64(3)8", + "3.4.64(3)9", + "3.4.64(3)10", + "3.4.64(3)11", + "3.4.64(3)12", + "3.4.64(3)13", + "3.4.64(3)14", + "3.4.71(2)" + ], + "emea-grc-pirppd-1997": [ + "B.9.2.f", + "B.10.1", + "B.10.2", + "B.10.3" + ], + "emea-hun-act-cxii-2011": [ + "II.6.7(2)", + "II.6.7(3)", + "II.6.7(4)", + "II.6.7(5)(a)", + "II.6.7(5)(b)", + "II.6.7(5)(c)", + "II.6.7(5)(d)", + "II.6.7(5)(e)", + "II.6.7(5)(f)", + "II.6.7(6)" + ], + "emea-irl-dpa-2018": [ + "s.72", + "s.75", + "s.76", + "s.77", + "s.78" + ], + "emea-isr-ppl-5741-2025": [ + "s.17" + ], + "emea-ita-pdpc-2018": [ + "Article 115(1)", + "Article 115(2)" + ], "emea-ken-pda-2019": [ - "29(f)", - "41(1)", - "41(1)(a)", - "41(1)(b)", - "41(2)", - "41(3)(a)", - "41(3)(b)", - "41(3)(c)", - "41(3)(d)", - "41(3)(e)", - "41(4)(a)", - "41(4)(b)", - "41(4)(c)", - "41(4)(d)", - "41(4)(e)", - "41(4)(f)", - "42(1)(a)", - "42(1)(b)", - "42(1)(c)", - "42(1)(d)", - "42(2)(a)", - "42(2)(b)", - "42(3)", - "42(4)" + "IV.41(1)", + "IV.41(1)(a)", + "IV.41(1)(b)", + "IV.41(2)", + "IV.41(3)", + "IV.41(3)(a)", + "IV.41(3)(b)", + "IV.41(3)(c)", + "IV.41(3)(d)", + "IV.41(3)(e)", + "IV.41(4)", + "IV.41(4)(a)", + "IV.41(4)(b)", + "IV.41(4)(c)", + "IV.41(4)(d)", + "IV.41(4)(e)", + "IV.41(4)(f)", + "IV.42(1)", + "IV.42(1)(a)", + "IV.42(1)(b)", + "IV.42(1)(c)", + "IV.42(1)(d)", + "IV.42(2)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], "emea-nga-dpr-2019": [ "2.1(1)(d)", "2.6" ], "emea-qat-pdppl-2020": [ - "8.3", - "13" + "3.13" + ], + "emea-rus-152-fz-2025": [ + "Art. 7", + "Art. 18.1", + "Art. 19" ], "emea-sau-pdpl-2023": [ "Article 19" ], "emea-srb-act-9-2018": [ - "5.6", - "41", - "42", - "42.1", - "42.2", - "50", - "50.1", - "50.2", - "50.3", - "50.4", - "51", - "51.1", - "51.2", - "51.3", - "51.4", - "51.5", - "51.6", - "51.7", - "51.8", - "51.9", - "51.10" + "II.6(5)", + "II.8", + "IV.1.41", + "IV.1.42", + "IV.1.42(1)", + "IV.1.42(2)", + "IV.2.50", + "IV.2.50(2)", + "IV.2.50(3)", + "IV.2.50(4)", + "IV.2.51", + "IV.2.51(1)", + "IV.2.51(2)", + "IV.2.51(3)", + "IV.2.51(4)", + "IV.2.51(5)", + "IV.2.51(6)", + "IV.2.51(7)", + "IV.2.51(8)", + "IV.2.51(9)", + "IV.2.51(10)" + ], + "emea-zaf-popia-2013": [ + "3.A.7.19(1)", + "3.A.7.19(1)(a)", + "3.A.7.19(1)(b)", + "3.A.7.19(2)", + "3.A.7.19(2)(a)", + "3.A.7.19(2)(b)", + "3.A.7.19(2)(c)", + "3.A.7.19(2)(d)", + "3.A.7.19(3)" + ], + "emea-esp-decree-311-2022": [ + "Article 5(a)", + "Article 5(b)", + "Article 5(c)", + "Article 5(d)", + "Article 5(e)", + "Article 5(f)", + "Article 5(g)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" + ], + "emea-che-fadp-2025": [ + "2.1.7.2", + "2.1.8.1", + "2.1.8.2" + ], + "emea-tur-lppd-2016": [ + "12(1)", + "12(1)(a)", + "12(1)(b)", + "12(1)(c)", + "12(2)", + "12(3)", + "12(4)", + "12(5)" + ], + "emea-gbr-dpa-2018": [ + "Section 55(3)", + "Section 55(3)(a)", + "Section 55(3)(b)", + "Section 55(3)(c)", + "Section 55(3)(d)", + "Section 56(1)", + "Section 56(2)", + "Section 56(3)", + "Section 57(1)", + "Section 57(1)(a)", + "Section 57(1)(b)", + "Section 57(2)", + "Section 57(3)", + "Section 57(4)", + "Section 57(4)(a)", + "Section 57(4)(b)", + "Section 57(4)(c)", + "Section 57(4)(d)", + "Section 57(5)", + "Section 66(1)", + "Section 66(2)", + "Section 66(2)(a)", + "Section 66(2)(b)", + "Section 66(2)(c)", + "Section 66(2)(d)", + "Section 66(3)" + ], + "apac-aus-privacy-principles-2026": [ + "4.11.1", + "4.11.1.a", + "4.11.1.b" + ], + "apac-aus-cop-sitc-2020": [ + "5" ], "apac-chn-cybersecurity-law-2017": [ "Article 42" ], + "apac-chn-csnip-2012": [ + "IV" + ], "apac-chn-pipl-2021": [ - "9", - "25", - "28", - "59" + "Article 9" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 4(1)", + "Schedule 1 - 4(1)(a)", + "Schedule 1 - 4(1)(b)", + "Schedule 1 - 4(1)(c)", + "Schedule 1 - 4(1)(d)", + "Schedule 1 - 4(1)(e)" ], "apac-ind-dpdpa-2023": [ "8(4)", "8(5)" ], - "apac-jpn-ppi-2020": [ - "20", - "21" + "apac-ind-privacy-rules-2011": [ + "5(8)", + "8(2)" + ], + "apac-jpn-appi-2020": [ + "IV.1.20" + ], + "apac-mys-pdpa-2010": [ + "9(1)", + "9(1)(a)", + "9(1)(b)", + "9(1)(c)", + "9(1)(d)", + "9(1)(e)", + "9(2)", + "9(2)(a)", + "9(2)(b)" ], "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "3.1.22.5(a)", + "3.1.22.5(a)(i)", + "3.1.22.5(a)(ii)", + "3.1.22.5(a)(iii)" ], - "apac-sgp-mas-trm-2021": [ - "14.1.1", - "14.1.2", - "14.1.3", - "14.1.4", - "14.1.5", - "14.1.6", - "14.1.7" + "apac-phl-dpa-2012": [ + "V.20(a)", + "V.20(b)", + "V.20(c)", + "V.20(c)(1)", + "V.20(c)(2)", + "V.20(c)(3)", + "V.20(c)(4)", + "V.20(d)", + "V.20(e)" + ], + "apac-sgp-pdpa-2012": [ + "6.24", + "6.24(a)", + "6.24(b)" + ], + "apac-twn-pdpa-2025": [ + "III.20-1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-1" + ], + "americas-bhs-dpa-2003": [ + "II.5(1)(f)", + "II.9(2)", + "II.11(1)", + "II.11(1)(a)", + "II.11(1)(b)", + "II.11(2)", + "V.43(4)(d)", + "V.43(4)(e)", + "V.52(1)", + "V.52(2)", + "V.52(2)(a)", + "V.52(2)(b)", + "V.52(2)(c)", + "V.52(2)(d)", + "V.52(4)" + ], + "americas-bra-lgpd-2018": [ + "VII.I.46", + "VII.I.46.1", + "VII.I.47", + "VII.I.49", + "VII.II.50", + "VII.II.50.1", + "VII.II.50.2", + "VII.II.50.2.I", + "VII.II.50.2.I(a)", + "VII.II.50.2.I(b)", + "VII.II.50.2.I(c)", + "VII.II.50.2.I(d)", + "VII.II.50.2.I(e)", + "VII.II.50.2.I(f)", + "VII.II.50.2.I(g)", + "VII.II.50.2.I(h)", + "VII.II.50.2.II" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(a)", + "P7-4.7", + "P7-4.7.1", + "P7-4.7.2", + "P7-4.7.3" + ], + "americas-chl-act-19628-1999": [ + "I.7", + "I.11" + ], + "americas-col-law-1581-2012": [ + "II.4(g)", + "VI.17(d)" + ], + "americas-mex-fdpa-2010": [ + "II.19", + "II.21" ] } }, @@ -194771,7 +198743,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to limit the disclosure of Personal Data (PD) to authorized parties for the sole purpose for which the PD was obtained.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -194819,7 +198791,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -194866,49 +198839,16 @@ "10(c)(2)", "10(c)(5)" ], + "emea-grc-pirppd-1997": [ + "C.11.3" + ], "emea-sau-pdpl-2023": [ "Article 23.1", "Article 23.2", "Article 29.2.c" ], - "emea-srb-act-9-2018": [ - "33" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "22", - "25", - "41" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 11", - "P11-(1)", - "P11-(1)(a)", - "P11-(1)(b)", - "P11-(1)(c)", - "P11-(1)(d)", - "P11-(1)(e)(i)", - "P11-(1)(e)(ii)", - "P11-(1)(e)(iii)", - "P11-(1)(e)(iv)", - "P11-(1)(f)(i)", - "P11-(1)(f)(ii)", - "P11-(1)(g)", - "P11-(1)(h)(i)", - "P11-(1)(h)(ii)", - "P11-(1)(i)", - "P11-(2)", - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "apac-aus-privacy-principles-2026": [ + "3.6.1" ] } }, @@ -194930,7 +198870,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to appoint an individual to determine the following criteria about Personal Data (PD):\n(1) The purpose why PD is necessary; \n(2) Authorized methods to collect, receive, process, store, transmit, share, update and/or dispose PD; and\n(3) Authorized parties PD may be shared with.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -194980,7 +198920,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -195004,7 +198945,7 @@ "title": "Personal Data (PD) Process Manager", "family": "PRI", "description": "Mechanisms exist to assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent.", - "scf_question": "Does the organization assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD)is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent?", + "scf_question": "Does the organization assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -195017,7 +198958,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ Accountability is assigned to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -195068,12 +199009,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "apac-ind-dpdpa-2023": [ "6(8)" + ], + "americas-mex-fdpa-2010": [ + "IV.30" ] } }, @@ -195095,7 +199040,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to strictly govern financial incentives offered to data subjects for Personal Data (PD) to ensure compliance with applicable legal and regulatory requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -195131,7 +199076,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -195217,7 +199163,8 @@ "MT-12", "MT-13", "MT-14", - "MT-15" + "MT-15", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -195237,7 +199184,7 @@ "general-iso-29100-2024": [ "6.5", "6.8", - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "TS-1.14" @@ -195253,9 +199200,6 @@ "general-nist-800-37-r2": [ "TASK P-16" ], - "general-scf-dpmp-2025": [ - "1.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(D)" ], @@ -195319,6 +199263,14 @@ "usa-state-il-pipa-2006": [ "45(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.1", + "603A.510.3(b)", + "603A.525.1", + "603A.525.1(a)", + "603A.525.1(b)", + "603A.525.2(c)" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(a)", "899-bb.2(b)(ii)(A)" @@ -195357,6 +199309,428 @@ "2433(a)(2)(C)", "2447(a)(2)" ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(g)" + ], + "emea-eu-psd2-2015": [ + "94(1)", + "94(2)" + ], + "emea-aut-dpa-2018": [ + "§ 1(1)", + "§ 1(2)", + "§ 1(3)", + "§ 1(4)", + "§ 6(2)", + "§ 8(1)", + "§ 8(2)", + "§ 8(3)", + "§ 37(1)", + "§ 37(5)", + "§ 37(8)", + "§ 45(3)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(2)", + "Title 2, Chapter II, Art. 28", + "Title 2, Chapter II, Art. 32(1)", + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter II, Art. 34(1)", + "Title 2, Chapter III, Art. 39(3)", + "Title 2, Chapter III, Art. 45(3)", + "Title 4, Chapter III, Section 2, Art. 194", + "Title 4, Chapter III, Section 2, Art. 195", + "Title 4, Chapter III, Section 2, Art. 196", + "Title 4, Chapter III, Section 2, Art. 197", + "Title 4, Chapter III, Section 3, Art. 202(1)", + "Title 4, Chapter III, Section 3, Art. 202(2)" + ], + "emea-deu-fdpa-2017": [ + "2.2.32(1)1", + "2.2.32(1)2", + "2.2.32(1)3", + "2.2.32(1)4", + "2.2.32(1)5", + "2.2.32(2)", + "2.2.32(3)", + "2.2.33(1)1(a)", + "2.2.33(1)1(b)", + "2.2.33(1)2", + "2.2.33(2)", + "2.2.35(3)", + "2.2.36", + "3.1.47.1", + "3.2.48(2)", + "3.2.48(2)1", + "3.2.48(2)5", + "3.3.57(4)", + "3.3.58(3)", + "3.3.58(3)1", + "3.3.58(3)2", + "3.3.58(3)3", + "3.3.58(4)", + "3.3.59(3)", + "3.4.71(1)", + "3.4.74(1)", + "3.4.74(2)", + "3.5.80(1)", + "3.5.80(1)1", + "3.5.80(1)2", + "3.5.80(1)3", + "3.5.80(1)4", + "3.5.80(1)5", + "3.5.80(2)", + "3.5.80(3)", + "3.7.83(2)", + "3.7.83(3)", + "3.7.83(4)", + "3.7.83(5)" + ], + "emea-grc-pirppd-1997": [ + "B.4.1.a", + "B.4.1.b", + "B.7.2.b", + "B.7.2.c", + "B.7.2.d", + "B.7.2.e", + "B.7.2.f", + "B.7.2.g", + "B.9.2.f", + "C.11.4", + "C.11.5", + "C.12.3" + ], + "emea-hun-act-cxii-2011": [ + "II.5.6(1)(a)", + "II.5.6(5)(b)", + "II.6.7(1)", + "II.8.9(1)(c)", + "II.8.9(1)(d)", + "II.10.11(1)(a)", + "II.13.16(1)", + "II.13.17(3)", + "II.13.17(4)", + "II.13.17(5)", + "II.14.20(4)(e)", + "II.14.20(4)(f)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)", + "II.15.21(3)", + "II.15.21(7)", + "II.18.24(3)" + ], + "emea-irl-dpa-2018": [ + "s.71", + "s.94" + ], + "emea-isr-ppl-5741-2025": [ + "s.1", + "s.2", + "s.2A", + "s.3", + "s.16" + ], + "emea-ita-pdpc-2018": [ + "Article 75(1)", + "Article 102(1)", + "Article 102(2)(a)", + "Article 102(2)(b)", + "Article 102(2)(c)", + "Article 106(1)", + "Article 106(2)(a)", + "Article 106(2)(b)", + "Article 106(2)(c)", + "Article 106(2)(d)", + "Article 106(2)(g)", + "Article 106(2)(h)", + "Article 106(2)(i)", + "Article 126(1)", + "Article 126(2)", + "Article 126(3)", + "Article 126(4)" + ], + "emea-ken-pda-2019": [ + "IV.25(b)", + "IV.25(d)", + "IV.26", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(e)", + "IV.28(2)(f)", + "IV.28(2)(f)(i)", + "IV.28(2)(f)(ii)", + "IV.28(2)(f)(iii)", + "IV.28(3)", + "IV.33(2)", + "IV.33(3)", + "IV.33(3)(a)", + "IV.33(3)(b)", + "IV.33(3)(c)", + "IV.33(3)(d)", + "IV.33(3)(e)", + "IV.34(1)(c)", + "IV.34(1)(d)", + "IV.34(2)(a)", + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.35(2)(c)" + ], + "emea-nga-dpr-2019": [ + "2.4(a)", + "2.4(b)", + "2.6", + "2.8", + "2.9", + "2.12(b)", + "2.12(c)", + "2.12(d)", + "2.12(e)", + "2.12(f)", + "3.1(3)", + "3.1(3)(a)" + ], + "emea-qat-pdppl-2020": [ + "2.4", + "2.6.3", + "3.8.1", + "3.8.2", + "3.8.3", + "3.8.4", + "3.10", + "3.11.1", + "3.11.6", + "3.13", + "4.17.3", + "4.17.4", + "4.17.5" + ], + "emea-rus-152-fz-2025": [ + "Art. 5", + "Art. 6", + "Art. 11", + "Art. 18.1" + ], + "emea-srb-act-9-2018": [ + "II.5", + "II.5(1)", + "II.5(2)", + "II.5(3)", + "II.5(4)", + "II.5(5)", + "II.5(6)", + "II.6", + "II.12", + "III.1.21(1)", + "III.1.22(1)", + "III.2.24-4", + "III.2.24-4(1)", + "III.2.24-4(2)", + "III.2.24-4(3)", + "III.2.24-4(4)", + "III.2.25-1", + "III.2.25-1(1)", + "III.2.25-1(2)", + "III.2.25-1(3)", + "III.2.25-1(4)", + "III.2.25-1(5)", + "III.2.25-2", + "III.2.25-2(1)", + "III.2.25-2(2)", + "III.2.25-2(3)", + "III.2.25-2(4)", + "III.2.25-3", + "III.2.25-3(1)", + "III.2.25-3(2)", + "III.2.25-3(3)", + "III.2.25-3(4)", + "III.2.25-3(5)", + "III.2.28", + "III.2.28(1)", + "III.2.28(2)", + "III.2.28(3)", + "III.2.28(4)", + "III.2.28(5)", + "III.3.31(1)", + "III.3.31(2)", + "III.3.31(3)", + "III.3.31(4)", + "III.3.32(1)", + "III.3.32(2)", + "III.3.34(1)", + "III.3.34(2)", + "III.3.34(3)", + "III.3.34(4)", + "III.3.34(5)", + "III.4.38(1)", + "III.4.38(2)", + "III.4.38(3)" + ], + "emea-zaf-popia-2013": [ + "2.5(1)", + "2.5(1)(a)", + "2.5(1)(a)(i)", + "2.5(1)(a)(ii)", + "2.5(1)(b)", + "2.5(1)(c)", + "2.5(1)(d)", + "2.5(1)(e)", + "2.5(1)(e)(i)", + "2.5(1)(e)(ii)", + "2.5(1)(f)", + "2.5(1)(g)", + "2.5(1)(h)", + "2.5(1)(i)", + "3.A.2.9(1)", + "3.A.2.9(1)(a)", + "3.A.2.9(1)(b)", + "3.A.2.10", + "3.A.2.11(2)(a)", + "3.A.2.12(2)", + "3.A.2.12(2)(a)", + "3.A.2.12(2)(b)", + "3.A.2.12(2)(c)", + "3.A.2.12(2)(d)", + "3.A.2.12(2)(d)(i)", + "3.A.2.12(2)(d)(ii)", + "3.A.2.12(2)(d)(iii)", + "3.A.2.12(2)(d)(iv)", + "3.A.2.12(2)(d)(v)", + "3.A.2.12(2)(e)", + "3.A.2.12(2)(f)", + "3.A.6.17", + "3.A.6.18(1)", + "3.A.6.18(1)(a)", + "3.A.6.18(1)(b)", + "3.A.6.18(1)(c)", + "3.A.6.18(1)(d)", + "3.A.6.18(1)(e)", + "3.A.6.18(1)(f)", + "3.A.6.18(1)(g)", + "3.A.6.18(1)(h)", + "3.A.6.18(1)(h)(i)", + "3.A.6.18(1)(h)(ii)", + "3.A.6.18(1)(h)(iii)", + "3.A.6.18(1)(h)(iv)", + "3.A.6.18(1)(h)(v)", + "3.A.6.18(2)", + "3.A.6.18(2)(a)", + "3.A.6.18(2)(b)", + "3.A.6.18(3)", + "3.A.6.18(4)", + "3.A.6.18(4)(a)", + "3.A.6.18(4)(b)", + "3.A.6.18(4)(c)", + "3.A.6.18(4)(c)(i)", + "3.A.6.18(4)(c)(ii)", + "3.A.6.18(4)(c)(iii)", + "3.A.6.18(4)(c)(iv)", + "3.A.6.18(4)(d)", + "3.A.6.18(4)(e)", + "3.A.6.18(4)(f)", + "3.A.6.18(4)(f)(i)", + "3.A.6.18(4)(f)(ii)", + "3.A.7.20(1)", + "3.A.7.20(1)(a)", + "3.A.7.20(1)(b)" + ], + "emea-che-fadp-2025": [ + "2.1.6.1", + "2.1.6.2", + "2.1.7.1", + "4.25.6" + ], + "emea-gbr-dpa-2018": [ + "Section 45(4)", + "Section 45(4)(a)", + "Section 45(4)(b)", + "Section 45(4)(c)", + "Section 45(4)(e)", + "Section 47(2)" + ], + "apac-aus-privacy-principles-2026": [ + "1.1.2", + "2.3.1", + "2.3.2", + "2.3.5", + "2.3.7", + "2.4.1", + "2.4.1.a", + "2.4.1.b", + "2.4.2", + "2.4.3", + "2.4.3.a", + "2.4.3.b", + "2.4.4", + "3.9.1", + "3.9.1.a", + "3.9.1.b", + "5.12.7", + "5.12.8", + "5.12.8.a", + "5.12.8.b" + ], + "apac-aus-cop-sitc-2020": [ + "5" + ], + "apac-chn-data-security-law-2021": [ + "Article 33" + ], + "apac-chn-csnip-2012": [ + "I", + "II", + "VI" + ], + "apac-chn-pipl-2021": [ + "Article 5", + "Article 7", + "Article 10", + "Article 26", + "Article 27" + ], + "apac-hkg-pdo-2022": [ + "28(1)", + "28(2)", + "28(3)", + "28(4)", + "28(4)(II)", + "28(5)", + "28(6)", + "28(6)(a)", + "28(6)(b)", + "29", + "29(a)", + "29(b)", + "Schedule 1 - 1(1)(a)", + "Schedule 1 - 1(1)(b)", + "Schedule 1 - 1(1)(c)", + "Schedule 1 - 1(2)(a)", + "Schedule 1 - 1(2)(b)" + ], + "apac-ind-privacy-rules-2011": [ + "4(v)", + "8(1)", + "8(4)" + ], + "apac-jpn-appi-2020": [ + "IV.1.17(1)", + "IV.1.26-2(1)", + "IV.2.35-2(7)", + "IV.2.35-2(8)", + "IV.2.35-3(1)", + "IV.3.36(1)", + "IV.3.36(2)", + "IV.3.36(3)", + "IV.3.36(4)", + "IV.3.36(5)", + "IV.3.36(6)", + "IV.3.37", + "IV.3.38", + "IV.3.39", + "IV.5.54" + ], "apac-jpn-ismap": [ "7.1.1.12", "18.1.4", @@ -195366,6 +199740,269 @@ "18.1.4.4", "18.1.4.5", "18.1.4.6" + ], + "apac-mys-pdpa-2010": [ + "5(1)", + "5(1)(a)", + "5(1)(b)", + "5(1)(c)", + "5(1)(d)", + "5(1)(e)", + "5(1)(f)", + "5(1)(g)", + "130(1)", + "130(1)(a)", + "130(1)(b)", + "130(2)", + "130(2)(a)", + "130(2)(a)(i)", + "130(2)(a)(ii)", + "130(2)(b)", + "130(2)(c)", + "130(2)(d)", + "130(3)", + "130(4)", + "130(5)", + "130(5)(a)", + "130(5)(b)", + "130(6)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.4", + "3.1.22.4(a)", + "3.1.22.4(b)", + "3.1.22.4(b)(i)", + "3.1.22.4(b)(ii)", + "3.1.22.5", + "3.1.22.5(b)", + "4.1.47(1)", + "4.1.47(1)(a)", + "4.1.47(1)(b)" + ], + "apac-phl-dpa-2012": [ + "III.11", + "III.11(b)", + "III.11(d)" + ], + "apac-sgp-pdpa-2012": [ + "3.11(1)", + "4.1.14(2)(a)", + "4.1.14(2)(b)", + "4.1.15A(4)(c)", + "4.1.15A(5)(c)", + "9.3.46(2)(a)", + "9.3.46(2)(b)", + "9.3.47(2)" + ], + "apac-kor-pipa-2011": [ + "I.3(1)", + "I.3(2)", + "I.3(3)", + "I.3(4)", + "I.3(5)", + "I.3(6)", + "I.3(7)", + "I.3(8)", + "I.4", + "I.4.1", + "I.4.2", + "I.4.3", + "I.4.4", + "I.4.5", + "III.2.23", + "III.2.24(1)", + "III.2.24(1)1", + "III.2.24(1)2", + "III.2.24(2)", + "III.2.24(3)", + "III.2.24(4)", + "IV.29", + "V.38(3)", + "V.38(4)", + "V.38(5)", + "VIII.60" + ], + "apac-twn-pdpa-2025": [ + "I.5" + ], + "americas-arg-ppd-2018": [ + "A", + "A.1.1", + "A.1.2", + "A.1.3", + "A.2.2-1", + "A.2.2-2" + ], + "americas-bhs-dpa-2003": [ + "II.5(1)(a)", + "II.5(1)(b)", + "II.5(1)(c)", + "II.5(1)(d)", + "II.5(1)(e)", + "II.5(1)(f)", + "II.5(2)", + "II.5(3)", + "II.8(4)", + "V.43(4)(d)", + "V.43(4)(e)" + ], + "americas-bra-lgpd-2018": [ + "II.I.10", + "II.I.10.I", + "II.I.10.II", + "II.I.10.II.1", + "II.I.10.II.2", + "II.II.11.I", + "II.II.11.II", + "II.II.11.II(a)", + "II.II.11.II(b)", + "II.II.11.II(c)", + "II.II.11.II(d)", + "II.II.11.II(e)", + "II.II.11.II(f)", + "II.II.11.II(g)", + "II.II.11.II(g)1", + "II.II.11.II(g)2", + "II.II.11.II(g)3", + "II.II.11.II(g)4", + "III.21" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(a)", + "P3-4.3.3", + "P4-4.4.1", + "P4-4.4.2" + ], + "americas-chl-act-19628-1999": [ + "I.7", + "I.11" + ], + "americas-col-law-1581-2012": [ + "II.4(d)", + "II.4(g)", + "VI.17(a)", + "VI.17(e)" + ], + "americas-mex-fdpa-2010": [ + "II.6", + "II.7", + "II.9", + "II.10", + "II.10.I", + "II.10.II", + "II.10.III", + "II.10.IV", + "II.10.V", + "II.10.VI", + "II.10.VII", + "III.26", + "III.26.I", + "III.26.II", + "III.26.III", + "III.26.IV", + "III.26.V", + "III.26.VI", + "III.26.VII", + "IV.34", + "IV.35" + ] + } + }, + { + "control_id": "PRI-01.12", + "title": "Privacy-Aware Design", + "family": "PRI", + "description": "Mechanisms exist to formally incorporate the organization's data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "scf_question": "Does the organization formally incorporate its data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to formally incorporate the organization's data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Privacy by design principles (basic data minimization practices)\n∙ NIST Privacy Framework reference", + "small": "∙ Privacy by design checklist for new systems\n∙ NIST Privacy Framework or GDPR Art. 25 alignment", + "medium": "∙ Privacy by design and by default program\n∙ DPIA for new systems\n∙ Privacy engineering practices in SDLC", + "large": "∙ Enterprise privacy engineering program\n∙ Privacy by design requirements in system development lifecycle\n∙ DPIA for new data processing", + "enterprise": "∙ Enterprise privacy engineering framework\n∙ Automated privacy design reviews in SDLC\n∙ DPIA for all new data processing\n∙ Privacy technology stack (e.g., OneTrust)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-4", + "R-AM-2", + "R-AM-3", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-28" + ], + "errata": "- new control - NIST Privacy Framework", + "family_name": "Data Privacy", + "crosswalks": { + "general-nist-privacy-framework-1-0": [ + "CT.DM-P10" ] } }, @@ -195389,11 +200026,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ The CPO, or similar role, develops and ensures data privacy notices are published that include relevant purpose, notice and data privacy program information.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -195443,7 +200080,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -195516,9 +200154,6 @@ "general-nist-800-82-r3-high": [ "PM-20(01)" ], - "general-scf-dpmp-2025": [ - "4.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(A)(i)" ], @@ -195549,50 +200184,50 @@ "155.260(a)(3)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.520(a)(1)", - "164.520(a)(2)(i)", - "164.520(a)(2)(i)(A)", - "164.520(a)(2)(i)(B)", - "164.520(a)(2)(ii)", - "164.520(a)(2)(ii)(A)", - "164.520(a)(2)(ii)(B)", - "164.520(a)(2)(iii)", - "164.520(b)(1)", - "164.520(b)(1)(i)", - "164.520(b)(1)(ii)", - "164.520(b)(1)(ii)(A)", - "164.520(b)(1)(ii)(B)", - "164.520(b)(1)(ii)(C)", - "164.520(b)(1)(ii)(D)", - "164.520(b)(1)(ii)(E)", - "164.520(b)(1)(iv)", - "164.520(b)(1)(iv)(A)", - "164.520(b)(1)(iv)(B)", - "164.520(b)(1)(iv)(C)", - "164.520(b)(1)(iv)(D)", - "164.520(b)(1)(iv)(E)", - "164.520(b)(1)(iv)(F)", - "164.520(b)(1)(v)", - "164.520(b)(1)(v)(A)", - "164.520(b)(1)(v)(B)", - "164.520(b)(1)(v)(C)", - "164.520(b)(1)(vi)", - "164.520(b)(1)(vii)", - "164.520(b)(1)(viii)", - "164.520(b)(2)(i)", - "164.520(b)(2)(ii)", - "164.520(b)(3)", - "164.520(c)", - "164.520(c)(1)(i)", - "164.520(c)(1)(i)(A)", - "164.520(c)(1)(i)(B)", - "164.520(c)(1)(ii)", - "164.520(c)(1)(iii)", - "164.520(c)(1)(iv)", - "164.520(c)(1)(v)", - "164.520(c)(1)(v)(A)", - "164.520(c)(1)(v)(B)", - "164.530(i)(4)(i)(C)" + "§ 164.520(a)(1)", + "§ 164.520(a)(2)(i)", + "§ 164.520(a)(2)(i)(A)", + "§ 164.520(a)(2)(i)(B)", + "§ 164.520(a)(2)(ii)", + "§ 164.520(a)(2)(ii)(A)", + "§ 164.520(a)(2)(ii)(B)", + "§ 164.520(a)(2)(iii)", + "§ 164.520(b)(1)", + "§ 164.520(b)(1)(i)", + "§ 164.520(b)(1)(ii)", + "§ 164.520(b)(1)(ii)(A)", + "§ 164.520(b)(1)(ii)(B)", + "§ 164.520(b)(1)(ii)(C)", + "§ 164.520(b)(1)(ii)(D)", + "§ 164.520(b)(1)(ii)(E)", + "§ 164.520(b)(1)(iv)", + "§ 164.520(b)(1)(iv)(A)", + "§ 164.520(b)(1)(iv)(B)", + "§ 164.520(b)(1)(iv)(C)", + "§ 164.520(b)(1)(iv)(D)", + "§ 164.520(b)(1)(iv)(E)", + "§ 164.520(b)(1)(iv)(F)", + "§ 164.520(b)(1)(v)", + "§ 164.520(b)(1)(v)(A)", + "§ 164.520(b)(1)(v)(B)", + "§ 164.520(b)(1)(v)(C)", + "§ 164.520(b)(1)(vi)", + "§ 164.520(b)(1)(vii)", + "§ 164.520(b)(1)(viii)", + "§ 164.520(b)(2)(i)", + "§ 164.520(b)(2)(ii)", + "§ 164.520(b)(3)", + "§ 164.520(c)", + "§ 164.520(c)(1)(i)", + "§ 164.520(c)(1)(i)(A)", + "§ 164.520(c)(1)(i)(B)", + "§ 164.520(c)(1)(ii)", + "§ 164.520(c)(1)(iii)", + "§ 164.520(c)(1)(iv)", + "§ 164.520(c)(1)(v)", + "§ 164.520(c)(1)(v)(A)", + "§ 164.520(c)(1)(v)(B)", + "§ 164.530(i)(4)(i)(C)" ], "usa-federal-cms-marse-2-0": [ "TR-1", @@ -195694,6 +200329,28 @@ "35(a)(5)", "37(a)(5)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.340.1", + "603A.340.1(b)", + "603A.340.1(c)", + "603A.340.1(d)", + "603A.340.1(e)", + "603A.345.1", + "603A.346.1", + "603A.495.1", + "603A.495.1(a)", + "603A.495.1(b)", + "603A.495.1(c)", + "603A.495.1(d)", + "603A.495.1(e)", + "603A.495.1(f)", + "603A.495.1(g)", + "603A.495.1(h)", + "603A.495.1(i)", + "603A.495.1(j)", + "603A.495.1(k)", + "603A.495.2" + ], "usa-state-or-ors-646a-2025": [ "646A.578(1)(a)", "646A.578(4)", @@ -195792,31 +200449,84 @@ "Article 14.4", "Article 14.5(a)" ], - "emea-bel-act-8-1992": [ - "9" + "emea-aut-dpa-2018": [ + "§ 43(1)", + "§ 43(2)", + "§ 43(3)", + "§ 43(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 37(1)", + "Title 2, Chapter III, Art. 37(2)", + "Title 4, Chapter III, Section 1, Art. 193" ], "emea-deu-fdpa-2017": [ - "Sec 4", - "Sec 19" + "3.2.51(4)", + "3.3.55", + "3.3.55.1", + "3.3.55.2", + "3.3.55.3", + "3.3.55.4", + "3.3.55.5", + "3.3.56(1)", + "3.3.56(1)1", + "3.3.56(1)2", + "3.3.56(1)3", + "3.3.56(1)4", + "3.3.56(1)5", + "3.3.56(2)1", + "3.3.56(2)2", + "3.3.56(2)3", + "3.3.56(3)" ], - "emea-ita-pdpc-2003": [ - "11", - "13", - "37" + "emea-grc-pirppd-1997": [ + "C.11.1", + "C.11.1.a", + "C.11.1.b", + "C.11.1.c", + "C.11.1.d", + "C.11.2", + "C.11.3" + ], + "emea-hun-act-cxii-2011": [ + "II.5.6(4)", + "II.7.8(1)(a)", + "II.14.20(1)", + "II.14.20(2)", + "II.14.20(4)(a)", + "II.14.20(4)(b)", + "II.14.20(4)(d)" + ], + "emea-irl-dpa-2018": [ + "s.90" + ], + "emea-isr-ppl-5741-2025": [ + "s.11" + ], + "emea-ita-pdpc-2018": [ + "Article 2-d(2)", + "Article 77(1)(a)", + "Article 77(1)(b)", + "Article 78(1)", + "Article 78(2)", + "Article 78(3)", + "Article 132-c(1)" ], "emea-ken-pda-2019": [ - "25(e)", - "26(a)", - "29(a)", - "29(b)", - "29(c)", - "29(d)", - "29(e)", - "29(f)", - "29(g)", - "29(h)" + "IV.25(e)", + "IV.26(a)", + "IV.29", + "IV.29(a)", + "IV.29(b)", + "IV.29(c)", + "IV.29(d)", + "IV.29(e)", + "IV.29(f)", + "IV.29(g)", + "IV.29(h)" ], "emea-nga-dpr-2019": [ + "2.3(1)", "2.5", "2.5(a)", "2.5(b)", @@ -195828,6 +200538,7 @@ "2.5(h)", "2.5(i)", "3.1(1)", + "3.1(7)", "3.1(7)(a)", "3.1(7)(b)", "3.1(7)(c)", @@ -195842,34 +200553,21 @@ "3.1(7)(l)", "3.1(7)(m)", "3.1(7)(n)", - "3.1(9)", - "3.1(9)(a)", - "3.1(9)(b)", - "3.1(9)(c)", - "3.1(9)(d)", - "3.1(9)(e)" - ], - "emea-nor-pda-2018": [ - "31" + "3.1(8)" ], - "emea-pol-act-29-1997": [ - "23" + "emea-pol-act-10-2018": [ + "Art. 11" ], "emea-qat-pdppl-2020": [ - "6.1", - "8.1", - "9.1", - "9.3", - "9.4", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "3.9", + "3.9.1", + "3.9.2", + "3.9.3", + "3.9.4", + "4.17.1" ], - "emea-rus-federal-law-27-2006": [ - "22" + "emea-rus-152-fz-2025": [ + "Art. 18" ], "emea-sau-pdpl-2023": [ "Article 4.1", @@ -195880,22 +200578,77 @@ "Article 13.6" ], "emea-srb-act-9-2018": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" + "III.1.21", + "III.2.23-1", + "III.2.23-1(1)", + "III.2.23-1(2)", + "III.2.23-1(3)", + "III.2.23-1(4)", + "III.2.23-1(5)", + "III.2.23-1(6)", + "III.2.23-2", + "III.2.23-2(1)", + "III.2.23-2(2)", + "III.2.23-2(3)", + "III.2.23-2(4)", + "III.2.23-2(5)", + "III.2.23-2(6)", + "III.2.24-1", + "III.2.24-1(1)", + "III.2.24-1(2)", + "III.2.24-1(3)", + "III.2.24-1(4)", + "III.2.24-1(5)", + "III.2.24-1(6)", + "III.2.24-2", + "III.2.24-2(1)", + "III.2.24-2(2)", + "III.2.24-2(3)", + "III.2.24-2(4)", + "III.2.24-2(5)", + "III.2.24-2(6)", + "III.2.24-2(7)", + "III.2.24-3", + "III.2.24-3(1)", + "III.2.24-3(2)", + "III.2.24-3(3)" ], "emea-zaf-popia-2013": [ - "18" + "3.A.3.13(1)", + "3.A.3.13(2)" ], - "emea-esp-decree-1720-2007": [ - "8" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" + ], + "emea-che-fadp-2025": [ + "2.2.15.3", + "3.19.1", + "3.19.2", + "3.19.2.a", + "3.19.2.b", + "3.19.2.c", + "3.19.3", + "3.19.4", + "3.19.5", + "3.21.1" ], "emea-tur-lppd-2016": [ - "10" + "10(1)", + "10(1)(a)", + "10(1)(b)", + "10(1)(c)", + "10(1)(ç)", + "10(1)(d)", + "11(1)", + "11(1)(a)", + "11(1)(b)", + "11(1)(c)", + "11(1)(ç)", + "11(1)(d)", + "11(1)(e)", + "11(1)(f)", + "11(1)(g)", + "11(1)(ğ)" ], "emea-gbr-def-stan-05-138-2024": [ "2406", @@ -195912,26 +200665,93 @@ "2406", "2407" ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 8" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 5" + "emea-gbr-dpa-2018": [ + "Section 44(1)", + "Section 44(1)(a)", + "Section 44(1)(b)", + "Section 44(1)(c)", + "Section 44(1)(d)", + "Section 44(1)(d)(i)", + "Section 44(1)(d)(ii)", + "Section 44(1)(d)(iii)", + "Section 44(1)(e)", + "Section 44(2)", + "Section 44(2)(b)", + "Section 44(2)(c)", + "Section 44(2)(d)", + "Section 44(3)", + "Section 69(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 1", - "APP 5" + "1.1.3", + "1.1.4", + "1.1.4.a", + "1.1.4.b", + "1.1.4.c", + "1.1.4.d", + "1.1.4.e", + "1.1.4.f", + "1.1.4.g", + "1.1.5", + "1.1.5.a", + "1.1.5.b", + "1.1.6", + "2.5.1", + "2.5.1.a", + "2.5.1.b", + "2.5.2", + "2.5.2.a", + "2.5.2.b", + "2.5.2.b.i", + "2.5.2.b.ii", + "2.5.2.c", + "2.5.2.d", + "2.5.2.e", + "2.5.2.f", + "2.5.2.g", + "2.5.2.h", + "2.5.2.i", + "2.5.2.j" ], "apac-chn-pipl-2021": [ - "7", - "17", - "17(1)", - "17(2)", - "17(3)", - "17(4)", - "27", - "39", - "48" + "Article 17", + "Article 18", + "Article 30", + "Article 39" + ], + "apac-hkg-pdo-2022": [ + "35C(2)", + "35C(2)(a)", + "35C(2)(a)(i)", + "35C(2)(a)(ii)", + "35C(2)(b)", + "35C(2)(b)(i)", + "35C(2)(b)(ii)", + "35C(2)(c)", + "35C(3)", + "35C(4)", + "35C(5)", + "35J(2)", + "35J(2)(a)", + "35J(2)(a)(i)", + "35J(2)(a)(ii)", + "35J(2)(b)", + "35J(2)(b)(i)", + "35J(2)(b)(ii)", + "35J(2)(b)(iii)", + "35J(2)(b)(iv)", + "35J(2)(c)", + "35J(3)", + "35J(4)", + "35J(5)", + "35J(5)(a)", + "35J(5)(b)", + "Schedule 1 - 1(3)(a)", + "Schedule 1 - 1(3)(b)(ii)(B)", + "Schedule 1 - 5", + "Schedule 1 - 5(a)", + "Schedule 1 - 5(b)", + "Schedule 1 - 5(c)" ], "apac-ind-dpdpa-2023": [ "5(1)(i)", @@ -195943,71 +200763,214 @@ "6(3)", "6(10)" ], - "apac-jpn-ppi-2020": [ - "15(1)", - "15(2)" + "apac-ind-privacy-rules-2011": [ + "4", + "4(i)", + "4(ii)", + "4(iii)", + "4(iv)", + "4(v)", + "5(3)", + "5(3)(a)", + "5(3)(b)", + "5(3)(c)", + "5(3)(d)", + "5(3)(d)(i)", + "5(3)(d)(ii)" + ], + "apac-jpn-appi-2020": [ + "IV.1.18(1)", + "IV.1.18(2)", + "IV.1.18(3)", + "IV.1.23(2)", + "IV.1.23(2)(i)", + "IV.1.23(2)(ii)", + "IV.1.23(2)(iii)", + "IV.1.23(2)(iv)", + "IV.1.23(2)(v)", + "IV.1.23(2)(vi)", + "IV.1.23(2)(vii)", + "IV.1.23(2)(viii)", + "IV.1.27(1)", + "IV.1.27(1)(i)", + "IV.1.27(1)(ii)", + "IV.1.27(1)(iii)", + "IV.1.27(1)(iv)" ], "apac-mys-pdpa-2010": [ - "7" + "7(1)", + "7(1)(a)", + "7(1)(b)", + "7(1)(c)", + "7(1)(d)", + "7(1)(e)", + "7(1)(f)", + "7(1)(g)", + "7(1)(h)", + "7(2)", + "7(2)(a)", + "7(2)(b)", + "7(2)(c)", + "7(2)(c)(i)", + "7(2)(c)(ii)" + ], + "apac-mys-bnm-rmit-2025": [ + "16.2" ], "apac-nzl-privacy-act-2020": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" + "3.1.22.3(1)", + "3.1.22.3(1)(a)", + "3.1.22.3(1)(b)", + "3.1.22.3(1)(c)", + "3.1.22.3(1)(d)", + "3.1.22.3(1)(d)(i)", + "3.1.22.3(1)(d)(ii)", + "3.1.22.3(1)(e)", + "3.1.22.3(1)(e)(i)", + "3.1.22.3(1)(e)(ii)", + "3.1.22.3(1)(f)", + "3.1.22.3(1)(g)", + "4.1.45(1)", + "4.1.45(1)(a)", + "4.1.45(1)(b)", + "4.1.45(1)(c)", + "4.1.45(2)" ], "apac-sgp-pdpa-2012": [ - "14" + "3.11(5)", + "3.11(5A)", + "4.1.14(1)(a)", + "4.1.15A(4)(b)", + "4.1.15A(4)(b)(i)", + "4.1.15A(4)(b)(ii)", + "4.1.15A(4)(b)(iii)", + "4.2.20(1)(a)", + "4.2.20(1)(b)", + "4.2.20(1)(c)", + "4.2.20(2)" + ], + "apac-sgp-mas-trm-2021": [ + "14.4.1" ], "apac-kor-pipa-2011": [ - "3", - "4" + "III.1.18(3)", + "III.1.18(3)1", + "III.1.18(3)2", + "III.1.18(3)3", + "III.1.18(3)4", + "III.1.18(3)5", + "IV.30(1)", + "IV.30(1)1", + "IV.30(1)2", + "IV.30(1)3", + "IV.30(1)4", + "IV.30(1)5", + "IV.30(1)6", + "IV.30(2)", + "IV.30(3)" ], "apac-twn-pdpa-2025": [ - "5" + "I.8-1", + "I.8.1-1", + "I.8.2-1", + "I.8.3-1", + "I.8.4-1", + "I.8.5-1", + "I.8.6-1", + "I.8-2", + "I.8.1-2", + "I.8.2-2", + "I.8.3-2", + "I.8.4-2", + "I.8.5-2", + "I.8.6-2", + "I.9", + "I.9.1", + "I.9.2", + "I.9.3", + "I.9.4", + "I.9.5" + ], + "americas-bhs-dpa-2003": [ + "II.8(1)", + "II.8(1)(a)", + "II.8(1)(b)", + "II.8(1)(c)", + "II.8(1)(d)", + "II.8(1)(e)", + "II.8(1)(f)", + "II.8(1)(g)", + "II.8(1)(g)(i)", + "II.8(1)(g)(ii)", + "II.8(1)(g)(iii)", + "II.8(1)(h)", + "II.8(1)(i)", + "II.8(2)", + "II.8(2)(a)", + "II.8(2)(b)", + "IV.24(1)(a)", + "IV.24(1)(b)", + "IV.24(1)(b)(i)", + "IV.24(1)(b)(ii)", + "IV.24(1)(b)(iii)", + "IV.24(1)(b)(iv)", + "IV.24(1)(b)(v)", + "IV.24(1)(c)", + "IV.24(1)(c)(i)", + "IV.24(1)(c)(ii)", + "IV.24(1)(c)(iii)", + "IV.24(1)(d)", + "IV.24(1)(e)", + "IV.24(1)(f)", + "IV.24(1)(g)", + "V.45(8)", + "V.52(3)" ], "americas-bra-lgpd-2018": [ - "6.2", - "6.6", - "8" + "II.I.9", + "II.I.9.I", + "II.I.9.II", + "II.I.9.III", + "II.I.9.IV", + "II.I.9.V", + "II.I.9.VI", + "II.I.9.VII", + "II.I.9.VII.1" ], "americas-can-pipeda-2000": [ - "Principle 2" - ], - "americas-chl-act-19628-1999": [ - "5" + "P2-4.2", + "P2-4.2.1", + "P2-4.2.2", + "P2-4.2.3", + "P8-4.8", + "P8-4.8.1", + "P8-4.8.2", + "P8-4.8.2(a)", + "P8-4.8.2(b)", + "P8-4.8.2(c)", + "P8-4.8.2(d)", + "P8-4.8.2(e)", + "P8-4.8.3" ], "americas-col-law-1581-2012": [ - "12" + "VI.17(c)" ], "americas-mex-fdpa-2010": [ - "7", - "16", - "17", - "18" + "II.7", + "II.12", + "II.15", + "II.16", + "II.16.I", + "II.16.II", + "II.16.III", + "II.16.IV", + "II.16.V", + "II.16.VI", + "II.17", + "II.17.I", + "II.17.II", + "II.18", + "V.36" ] } }, @@ -196029,7 +200992,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data privacy notices identify the purpose(s) for which Personal Data (PD) is collected, received, processed, stored, transmitted and/or shared.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -196082,7 +201045,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -196129,9 +201093,6 @@ "general-oecd-privacy-principles-2010": [ "3" ], - "general-scf-dpmp-2025": [ - "4.1" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.1.a.iv", "II.5.a" @@ -196153,13 +201114,13 @@ "7" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(3)", - "164.508(c)(1)(i)", - "164.508(c)(1)(ii)", - "164.508(c)(1)(iii)", - "164.508(c)(1)(iv)", - "164.508(c)(2)(i)(A)", - "164.508(c)(2)(i)(B)" + "§ 164.502(a)(3)", + "§ 164.508(c)(1)(i)", + "§ 164.508(c)(1)(ii)", + "§ 164.508(c)(1)(iii)", + "§ 164.508(c)(1)(iv)", + "§ 164.508(c)(2)(i)(A)", + "§ 164.508(c)(2)(i)(B)" ], "usa-federal-cms-marse-2-0": [ "AP-2" @@ -196192,74 +201153,27 @@ "Article 13.1(c)", "Article 14.1(c)" ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "8" - ], - "emea-ita-pdpc-2003": [ - "13" + "emea-deu-fdpa-2017": [ + "3.3.56(1)2" ], - "emea-ken-pda-2019": [ - "29(c)" + "emea-hun-act-cxii-2011": [ + "II.8.9(1)(a)", + "II.14.20(2)", + "II.14.20(4)(c)" ], "emea-nga-dpr-2019": [ "2.3(1)" ], - "emea-nor-pda-2018": [ - "32" - ], - "emea-pol-act-29-1997": [ - "23" - ], - "emea-qat-pdppl-2020": [ - "6.1", - "8.1", - "10" - ], - "emea-rus-federal-law-27-2006": [ - "5" - ], "emea-sau-pdpl-2023": [ "Article 11.1", "Article 13.2", "Article 13.3" ], - "emea-srb-act-9-2018": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" - ], - "emea-zaf-popia-2013": [ - "13", - "18" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 1" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" ], "apac-chn-pipl-2021": [ - "6", - "48" - ], - "apac-hkg-pdo-2022": [ - "Principle 1" + "Article 6" ], "apac-ind-dpdpa-2023": [ "4(2)", @@ -196268,83 +201182,20 @@ "7(a)", "8(8)(a)" ], - "apac-jpn-ppi-2020": [ - "15(1)", - "15(2)" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" + "apac-jpn-appi-2020": [ + "IV.1.15(1)" ], "apac-phl-dpa-2012": [ - "19" - ], - "apac-sgp-pdpa-2012": [ - "14", - "19", - "20" - ], - "apac-kor-pipa-2011": [ - "3", - "4" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "6", - "27.1", - "27.2", - "28.1" + "III.12" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.1", - "6.3" + "II.5(1)(b)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 2" - ], - "americas-chl-act-19628-1999": [ - "5" - ], - "americas-col-law-1581-2012": [ - "4" + "P2-4.2" ], "americas-mex-fdpa-2010": [ - "7", - "16", - "17", - "18" + "II.16.II" ] } }, @@ -196353,7 +201204,7 @@ "title": "Automated Data Management Processes", "family": "PRI", "description": "Automated mechanisms exist to adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s).", - "scf_question": "Does the organization use automated mechanisms to adjust data that is able tobe collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s)?", + "scf_question": "Does the organization use automated mechanisms to adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s)?", "relative_weight": 1, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -196366,7 +201217,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -196418,7 +201269,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -196445,9 +201297,6 @@ "general-nist-800-82-r3-high": [ "PM-24" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-24", "PT-03(02)" @@ -196465,39 +201314,7 @@ "PT-03(02)" ], "emea-ken-pda-2019": [ - "35(1)", - "35(2)", - "35(2)(a)", - "35(2)(b)", - "35(2)(c)", - "35(3)", - "35(3)(a)", - "35(3)(b)(i)", - "35(3)(b)(ii)", - "35(4)(a)", - "35(4)(b)", - "35(4)(c)(i)", - "35(4)(c)(ii)" - ], - "emea-srb-act-9-2018": [ - "38", - "38.1", - "38.2", - "38.3", - "39" - ], - "emea-zaf-popia-2013": [ - "5", - "71" - ], - "apac-chn-pipl-2021": [ - "24" - ], - "apac-twn-pdpa-2025": [ - "5" - ], - "americas-mex-fdpa-2010": [ - "7" + "IV.35(1)" ] } }, @@ -196519,7 +201336,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish Computer Matching Agreements (CMA) on the organization's public website(s).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -196570,7 +201387,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -196598,9 +201416,6 @@ "general-nist-800-82-r3-high": [ "PM-24" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-24" ], @@ -196636,7 +201451,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to draft, publish and keep System of Records Notices (SORN) updated in accordance with regulatory guidance.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -196687,7 +201502,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -196703,9 +201519,6 @@ "general-nist-800-82-r3": [ "PT-06" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-cms-marse-2-0": [ "TR-2", "TR-2.a", @@ -196732,7 +201545,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to review all routine uses of data published in the System of Records Notices (SORN) to ensure continued accuracy and to ensure that routine uses continue to be compatible with the purpose for which the information was collected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -196783,7 +201596,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -196795,9 +201609,6 @@ ], "general-nist-800-82-r3": [ "PT-06(01)" - ], - "general-scf-dpmp-2025": [ - "11.6" ] } }, @@ -196819,7 +201630,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to review all Privacy Act exemptions claimed for the System of Records Notices (SORN) to ensure they remain appropriate and accurate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -196870,7 +201681,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -196882,9 +201694,6 @@ ], "general-nist-800-82-r3": [ "PT-06(02)" - ], - "general-scf-dpmp-2025": [ - "11.6" ] } }, @@ -196906,7 +201715,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide real-time and/or layered notice when Personal Data (PD) is collected that provides data subjects with a summary of key points or more detailed information that is specific to the organization's data privacy notice.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -196957,7 +201766,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -196987,7 +201797,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to periodically assess disclosed purposes for which Personal Data (PD) is collected, received, processed, stored, transmitted and/or shared to ensure compatibility with reasonable consumer expectations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -197038,7 +201848,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -197050,6 +201861,9 @@ "7002(c)(1)", "7002(c)(2)", "7002(c)(3)" + ], + "americas-bra-lgpd-2018": [ + "II.IV.15.I" ] } }, @@ -197071,7 +201885,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reasonably accommodate data privacy notice formatting for consumers requiring alternative formatting due to accessibility needs through:\n(1) Screen resolution / screen sizes;\n(2) Multilingual support; and/or\n(3) Disability-specific concessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -197122,7 +201936,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -197151,7 +201966,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure symmetry in choice, where options presented to consumers for more protective options are not longer, more difficult, nor more time-consuming than less protective options.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -197202,7 +202017,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -197229,7 +202045,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to avoid choice architecture that impairs, interferes with or subverts a consumer’s ability to make well-informed choices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -197280,7 +202096,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -197309,9 +202126,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to perform testing of choice architecture to ensure it does not undermine a consumer’s ability to submit choice selections.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to perform testing of choice architecture to ensure it does not undermine a consumer’s ability to submit choice selections. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -197360,7 +202177,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -197387,9 +202205,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include within the data privacy notice a notification to data subjects of:\n(1) Their right to limit the use and disclosure of their sensitive Personal Data (sPD); and\n(2) The methods available to exercise that right.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include within the data privacy notice a notification to data subjects of:\n(1) Their right to limit the use and disclosure of their sensitive Personal Data (sPD); and\n(2) The methods available to exercise that right. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -197438,7 +202256,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -197448,6 +202267,12 @@ "7014(f)", "7014(f)(1)", "7014(f)(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.14.20(4)(f)" + ], + "apac-aus-privacy-principles-2026": [ + "1.2.1" ] } }, @@ -197469,7 +202294,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with a data privacy notice through alternative means for interactions that do not utilize an interface on a website or application.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -197520,7 +202345,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -197534,10 +202360,10 @@ }, { "control_id": "PRI-03", - "title": "Choice & Consent", + "title": "Data Subject Consent", "family": "PRI", - "description": "Mechanisms exist to enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations?", "relative_weight": 7, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -197550,9 +202376,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to Mechanisms exist to enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -197604,8 +202430,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -197666,11 +202494,6 @@ "1", "4(a)" ], - "general-scf-dpmp-2025": [ - "2.0", - "2.1", - "2.2" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.2.a", "II.2.c" @@ -197690,17 +202513,17 @@ "155.260(a)(3)(iv)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.506(b)(1)", - "164.508(a)(2)", - "164.508(c)(1)(v)", - "164.508(c)(3)", - "164.510(b)(2)(i)", - "164.510(b)(2)(ii)", - "164.510(b)(2)(iii)", - "164.510(b)(3)", - "164.514(f)(2)(ii)", - "164.514(f)(2)(iv)", - "164.514(f)(2)(v)" + "§ 164.506(b)(1)", + "§ 164.508(a)(2)", + "§ 164.508(c)(1)(v)", + "§ 164.508(c)(3)", + "§ 164.510(b)(2)(i)", + "§ 164.510(b)(2)(ii)", + "§ 164.510(b)(2)(iii)", + "§ 164.510(b)(3)", + "§ 164.514(f)(2)(ii)", + "§ 164.514(f)(2)(iv)", + "§ 164.514(f)(2)(v)" ], "usa-federal-cms-marse-2-0": [ "IP-1", @@ -197735,6 +202558,22 @@ "15(d)(3)", "15(d)(4)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.2(a)", + "603A.500.2(b)", + "603A.500.3", + "603A.500.3(a)", + "603A.500.3(b)", + "603A.500.3(c)", + "603A.500.3(d)", + "603A.535.5", + "603A.535.6", + "603A.535.6(a)", + "603A.535.6(b)", + "603A.535.6(c)", + "603A.535.6(d)", + "603A.535.7" + ], "usa-state-or-ors-646a-2025": [ "646A.578(6)", "646A.583(1)(a)(C)" @@ -197767,53 +202606,66 @@ "Article 21.5", "Article 21.6" ], - "emea-aut-fappd-2000": [ - "Sec 8" - ], - "emea-bel-act-8-1992": [ - "45754" + "emea-aut-dpa-2018": [ + "§ 8(1)", + "§ 12(1)", + "§ 12(2)", + "§ 12(3)", + "§ 12(4)" ], "emea-deu-fdpa-2017": [ - "Sec 4a", - "Sec 11" + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.27(4)", + "3.2.51(1)", + "3.2.51(2)", + "3.2.51(5)" ], "emea-grc-pirppd-1997": [ - "5" - ], - "emea-hun-isdfi-2011": [ - "6" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "23", - "24" + "B.5.1", + "B.7.2.a" + ], + "emea-hun-act-cxii-2011": [ + "II.5.5(1)(a)", + "II.5.5(2)(a)", + "II.5.6(3)", + "II.5.6(4)", + "II.7.8(1)(a)", + "II.8.9(4)", + "II.11.12(3)(a)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)" + ], + "emea-isr-ppl-5741-2025": [ + "s.1" ], "emea-ken-pda-2019": [ - "32(1)", - "32(4)" + "IV.26(c)", + "IV.28(2)(c)", + "IV.32(4)" ], "emea-nga-dpr-2019": [ - "2.2(a)", "2.3(2)", "2.3(2)(a)", "2.3(2)(b)", "2.3(2)(c)", "2.3(2)(d)", - "2.3(2)(e)" - ], - "emea-pol-act-29-1997": [ - "23" + "2.3(2)(e)", + "2.8(b)", + "2.12(a)", + "3.1(14)(a)", + "3.1(14)(b)", + "3.1(14)(c)" ], "emea-qat-pdppl-2020": [ - "4", - "5.2", - "10" + "2.4", + "2.5.2" ], - "emea-rus-federal-law-27-2006": [ - "6", - "9" + "emea-rus-152-fz-2025": [ + "Art. 6", + "Art. 9", + "Art. 10.1" ], "emea-sau-pdpl-2023": [ "Article 5.1", @@ -197826,41 +202678,55 @@ "Article 26" ], "emea-srb-act-9-2018": [ - "12.1", - "15", - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "II.15", + "III.3.31" ], "emea-zaf-popia-2013": [ - "11" + "6.57(1)", + "6.57(1)(a)", + "6.57(1)(a)(i)", + "6.57(1)(a)(ii)", + "6.57(1)(b)", + "6.57(1)(c)", + "6.57(1)(d)", + "6.57(2)", + "6.57(3)", + "6.57(4)" ], - "emea-esp-decree-1720-2007": [ - "8", - "12" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 3" + "emea-che-fadp-2025": [ + "2.1.6.6", + "2.1.6.7", + "2.1.6.7.a", + "2.1.6.7.b", + "2.1.6.7.c" ], "apac-chn-cybersecurity-law-2017": [ "Article 22" ], "apac-chn-pipl-2021": [ - "13(1)", - "14", - "23", - "27", - "29", - "30", - "44" + "Article 14" + ], + "apac-hkg-pdo-2022": [ + "35E(1)", + "35E(1)(a)", + "35E(1)(b)", + "35E(1)(b)(i)", + "35E(1)(b)(ii)", + "35E(1)(b)(iii)", + "35E(1)(c)", + "35E(2)", + "35E(2)(a)", + "35E(2)(b)", + "35E(3)", + "35E(4)", + "Schedule 1 - 1(3)(a)(i)", + "Schedule 1 - 1(3)(a)(ii)", + "Schedule 1 - 1(3)(b)", + "Schedule 1 - 1(3)(b)(i)", + "Schedule 1 - 1(3)(b)(i)(A)", + "Schedule 1 - 1(3)(b)(i)(B)", + "Schedule 1 - 1(3)(b)(ii)", + "Schedule 1 - 1(3)(b)(ii)(A)" ], "apac-ind-dpdpa-2023": [ "4(1)(a)", @@ -197873,56 +202739,107 @@ "8(8)(b)" ], "apac-ind-privacy-rules-2011": [ - "5" + "5(1)", + "5(7)" ], - "apac-jpn-ppi-2020": [ - "16(1)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)", - "24(1)", - "24(2)" + "apac-jpn-appi-2020": [ + "IV.1.26-2(1)(i)", + "IV.1.26-2(1)(ii)" ], "apac-mys-pdpa-2010": [ - "7" + "7(3)" ], "apac-phl-dpa-2012": [ - "19" + "III.12(a)" ], "apac-sgp-pdpa-2012": [ - "13" + "4.1.13", + "4.1.14(1)(b)", + "4.1.14(3)", + "4.1.14(4)", + "4.1.15(1)", + "4.1.15(1)(a)", + "4.1.15(1)(b)", + "4.1.15(2)", + "4.1.15(3)", + "4.1.15(6)", + "4.1.15(6)(a)(i)", + "4.1.15(6)(a)(ii)", + "4.1.15(6)(b)", + "4.1.15(6)(c)", + "4.1.15(7)", + "4.1.15(9)(a)", + "4.1.15(9)(b)", + "9.3.46(1)" ], "apac-kor-pipa-2011": [ - "3", - "4", - "22" + "III.1.15(2)", + "III.1.15(2)1", + "III.1.15(2)2", + "III.1.15(2)3", + "III.1.15(2)4", + "III.1.17(1)", + "III.1.17(1)1", + "III.1.17(1)2", + "III.1.17(2)", + "III.1.17(2)1", + "III.1.17(2)2", + "III.1.17(2)3", + "III.1.17(2)4", + "III.1.17(2)5", + "III.1.17(3)", + "III.1.22(3)" ], "apac-twn-pdpa-2025": [ - "5" + "I.7" ], - "americas-arg-ppd-2018": [ - "5.1", - "5.2" + "americas-bhs-dpa-2003": [ + "II.7(1)", + "IV.32(1)", + "IV.32(2)", + "IV.32(2)(a)", + "IV.32(2)(b)", + "IV.32(2)(c)", + "IV.32(3)", + "IV.32(4)", + "IV.32(5)", + "IV.32(6)", + "IV.36(2)" ], "americas-bra-lgpd-2018": [ - "7.1", - "15" + "II.I.7.I", + "II.I.8", + "II.I.8.1", + "II.I.8.2", + "II.I.8.3", + "II.I.8.4" ], "americas-can-pipeda-2000": [ - "Sec 6", - "Sec 7", - "Principle 3" + "P2-4.2.5", + "P3-4.3", + "P3-4.3.1", + "P3-4.3.2", + "P3-4.3.3", + "P3-4.3.4", + "P3-4.3.5", + "P3-4.3.6", + "P3-4.3.7", + "P3-4.3.7(a)", + "P3-4.3.7(b)", + "P3-4.3.7(c)", + "P3-4.3.7(d)" ], "americas-chl-act-19628-1999": [ - "4" + "I.4", + "I.8" ], "americas-col-law-1581-2012": [ - "4" + "II.4(c)", + "VI.17(b)" ], "americas-mex-fdpa-2010": [ - "8", - "10" + "II.8", + "II.9" ] } }, @@ -197944,7 +202861,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to modify permission to collect, receive, process, store, transmit, share, update and/or dispose selected attributes of their Personal Data (PD).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -197997,7 +202914,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -198016,27 +202934,23 @@ "general-nist-800-82-r3": [ "PT-04(01)" ], - "general-scf-dpmp-2025": [ - "2.5" - ], "usa-state-tn-tipa-2025": [ "47-18-3203(a)(2)(E)(i)", "47-18-3203(a)(2)(E)(ii)", "47-18-3203(a)(2)(E)(iii)", "47-18-3203(b)" ], - "emea-srb-act-9-2018": [ - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "apac-chn-pipl-2021": [ + "Article 29" ], - "emea-zaf-popia-2013": [ - "11" + "apac-jpn-appi-2020": [ + "IV.1.30(5)" ], - "apac-twn-pdpa-2025": [ - "5" + "apac-kor-pipa-2011": [ + "III.1.22(2)" + ], + "americas-bra-lgpd-2018": [ + "II.I.9.VII.3" ] } }, @@ -198058,7 +202972,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to present data subjects with a new or updated consent request to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD) in conjunction with the data action, when:\n(1) The original circumstances under which an individual gave consent have changed; or\n(2) A significant amount of time has passed since an individual gave consent.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -198111,7 +203025,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -198138,10 +203053,6 @@ "PT-04(02)", "PT-05(01)" ], - "general-scf-dpmp-2025": [ - "2.3", - "5.14" - ], "usa-federal-doc-data-privacy-framework-2023": [ "III.14.b.i", "III.14.b.ii" @@ -198157,48 +203068,28 @@ "7221(i)", "7221(k)" ], - "emea-aut-fappd-2000": [ - "Sec 8" - ], - "emea-ken-pda-2019": [ - "32(2)", - "32(3)" - ], - "emea-zaf-popia-2013": [ - "15" - ], - "apac-aus-privacy-principles-2026": [ - "APP 5" - ], - "apac-chn-pipl-2021": [ - "14", - "22", - "23", - "27" - ], - "apac-jpn-ppi-2020": [ - "16(2)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" + "apac-jpn-appi-2020": [ + "IV.1.16(2)" ], "apac-kor-pipa-2011": [ - "22" - ], - "apac-twn-pdpa-2025": [ - "5" + "III.1.20(1)", + "III.1.20(1)1", + "III.1.20(1)2", + "III.1.20(1)3", + "III.1.22(1)" ], - "americas-arg-ppd-2018": [ - "27.3" + "americas-bra-lgpd-2018": [ + "II.I.8.6", + "II.I.9.VII.2" ], "americas-can-pipeda-2000": [ - "Sec 6", - "Sec 7", - "Principle 3" + "P2-4.2.4" + ], + "americas-col-law-1581-2012": [ + "VI.17(m)" ], "americas-mex-fdpa-2010": [ - "7" + "II.16.VI" ] } }, @@ -198220,7 +203111,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Asset / process owners collect, store, processes, transmit share or use PD only for the purposes identified in the data privacy notice.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to prevent the sale, processing and/or sharing of Personal Data (PD) when:\n(1) Instructed by the data subject; or\n(2) The data subject is a minor, where selling and/or sharing PD is legally prohibited.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -198273,15 +203164,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.5" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(5)(ii)(A)" + "§ 164.502(a)(5)(ii)(A)" ], "usa-state-co-privacy-act-2021": [ "6-1-1308(1)(b)" @@ -198303,14 +203192,54 @@ "59.1-578.F.1", "59.1-578.F.1.a" ], - "emea-srb-act-9-2018": [ - "37" + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 7" ], - "apac-aus-privacy-principles-2026": [ - "APP 7" + "emea-grc-pirppd-1997": [ + "B.7.1", + "B.9.1", + "B.9.1.a" ], - "apac-chn-pipl-2021": [ - "10" + "emea-hun-act-cxii-2011": [ + "II.5.6(3)" + ], + "emea-ita-pdpc-2018": [ + "Article 2-d(1)" + ], + "emea-ken-pda-2019": [ + "IV.36" + ], + "emea-qat-pdppl-2020": [ + "3.12" + ], + "emea-srb-act-9-2018": [ + "II.16" + ], + "emea-zaf-popia-2013": [ + "3.C.34", + "3.C.35(1)", + "3.C.35(1)(a)", + "3.C.35(1)(b)", + "3.C.35(1)(c)", + "3.C.35(1)(d)", + "3.C.35(1)(d)(i)", + "3.C.35(1)(d)(ii)", + "3.C.35(1)(d)(iii)", + "3.C.35(1)(e)", + "3.C.35(2)", + "3.C.35(3)", + "3.C.35(3)(a)", + "3.C.35(3)(a)(i)", + "3.C.35(3)(a)(ii)", + "3.C.35(3)(b)", + "3.C.35(3)(b)(i)", + "3.C.35(3)(b)(ii)", + "3.C.35(3)(b)(iii)", + "3.C.35(3)(c)", + "3.C.35(3)(d)" + ], + "apac-jpn-appi-2020": [ + "IV.1.23(1)" ] } }, @@ -198332,7 +203261,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to revoke consent to collect, receive, process, store, transmit, share and/or update their Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -198385,7 +203314,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -198401,12 +203331,14 @@ "general-nist-800-82-r3": [ "PT-04(03)" ], - "general-scf-dpmp-2025": [ - "2.3" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)(ii)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.3(d)", + "603A.505.1(c)", + "603A.535.4" + ], "usa-state-or-ors-646a-2025": [ "646A.576(7)", "646A.578(1)(d)" @@ -198417,28 +203349,53 @@ "emea-eu-gdpr-2016": [ "Article 7.3" ], + "emea-deu-fdpa-2017": [ + "3.2.51(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.15.21(1)(a)", + "II.15.21(1)(b)" + ], "emea-ken-pda-2019": [ - "26(c)", - "32(2)", - "32(3)" + "IV.26(c)", + "IV.32(2)", + "IV.32(3)" ], "emea-nga-dpr-2019": [ - "2.8", "2.8(a)", - "2.8(b)" + "3.1(9)(b)" ], "emea-qat-pdppl-2020": [ - "5.1" + "2.5.1" ], "emea-sau-pdpl-2023": [ "Article 5.2" ], "emea-srb-act-9-2018": [ - "15", - "37" + "III.3.30-1(2)", + "III.4.37" + ], + "emea-zaf-popia-2013": [ + "3.A.2.11(2)(b)", + "3.A.2.11(3)", + "3.A.2.11(3)(a)", + "3.A.2.11(3)(b)", + "3.A.2.11(4)" + ], + "emea-gbr-dpa-2018": [ + "Section 47(4)" ], "apac-chn-pipl-2021": [ - "15" + "Article 15" + ], + "apac-hkg-pdo-2022": [ + "35G(1)", + "35L(1)", + "35L(1)(a)", + "35L(1)(b)", + "35L(2)", + "35L(3)", + "35L(4)" ], "apac-ind-dpdpa-2023": [ "5(2)(b)", @@ -198446,6 +203403,34 @@ "6(7)", "8(7)(a)", "8(8)(b)" + ], + "apac-jpn-appi-2020": [ + "IV.1.30(1)" + ], + "apac-mys-pdpa-2010": [ + "38(1)", + "43(1)" + ], + "apac-sgp-pdpa-2012": [ + "4.1.16(1)", + "9.3.47(1)" + ], + "apac-kor-pipa-2011": [ + "V.37(1)" + ], + "americas-bra-lgpd-2018": [ + "II.I.8.5", + "II.IV.15.III" + ], + "americas-can-pipeda-2000": [ + "P3-4.3.8" + ], + "americas-col-law-1581-2012": [ + "IV.8(e)" + ], + "americas-mex-fdpa-2010": [ + "II.8", + "III.25" ] } }, @@ -198467,7 +203452,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to prevent discrimination against a data subject for exercising their legal rights pertaining to modifying or revoking consent, including prohibiting:\n(1) Refusing products and/or services;\n(2) Charging different rates for goods and/or services; and\n(3) Providing different levels of quality.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -198517,7 +203502,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -198525,13 +203511,10 @@ "C3.1-POF2", "C3.1-POF3" ], - "general-scf-dpmp-2025": [ - "2.4" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.508(c)(2)(ii)(A)", - "164.508(c)(2)(ii)(B)", - "164.514(f)(2)(iii)" + "§ 164.508(c)(2)(ii)(A)", + "§ 164.508(c)(2)(ii)(B)", + "§ 164.514(f)(2)(iii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7080(a)", @@ -198542,6 +203525,9 @@ "6-1-1308(1)(c)(I)", "6-1-1308(1)(c)(II)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.535.2" + ], "usa-state-or-cpa-2023": [ "Section 5(2)(d)" ], @@ -198553,14 +203539,21 @@ "59.1-577.1.E", "59.1-578.A.4" ], + "emea-deu-fdpa-2017": [ + "3.3.59(3)" + ], "emea-ken-pda-2019": [ - "32(4)" + "IV.32(4)" ], "emea-sau-pdpl-2023": [ "Article 7" ], "apac-chn-pipl-2021": [ - "16" + "Article 16" + ], + "apac-kor-pipa-2011": [ + "III.1.16(2)", + "III.1.22(4)" ] } }, @@ -198582,7 +203575,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to authorize another person or entity (e.g., authorized agent, proxy, etc.), acting on the data subject's behalf, to make Personal Data (PD) processing decisions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -198612,14 +203605,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.6" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)", "Sec. 6502.(b)(1)(B)(ii)" @@ -198628,10 +203618,10 @@ "II.2.b" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(g)(1)", - "164.502(g)(2)", - "164.502(g)(3)(i)", - "164.502(g)(3)(i)(A)" + "§ 164.502(g)(1)", + "§ 164.502(g)(2)", + "§ 164.502(g)(3)(i)", + "§ 164.502(g)(3)(i)(A)" ], "usa-state-ca-ccpa-cpra-2026": [ "7026(j)", @@ -198674,28 +203664,32 @@ "Article 8.1", "Article 8.2" ], + "emea-hun-act-cxii-2011": [ + "II.5.6(2)" + ], + "emea-ita-pdpc-2018": [ + "Article 82(2)(a)" + ], "emea-ken-pda-2019": [ - "27(a)", - "27(b)", - "27(c)" + "IV.27(a)", + "IV.27(b)", + "IV.27(c)", + "IV.28(2)(d)" ], - "emea-qat-pdppl-2020": [ - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "apac-chn-pipl-2021": [ + "Article 49" ], "apac-ind-dpdpa-2023": [ "6(7)", "9(1)", "14(1)" ], - "apac-jpn-ppi-2020": [ - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" + "apac-phl-dpa-2012": [ + "IV.17" + ], + "apac-kor-pipa-2011": [ + "V.38(1)", + "V.38(2)" ] } }, @@ -198717,7 +203711,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to compel data subjects to select the level of consent deemed appropriate by the data subject for the relevant business purpose (e.g., opt-in, opt-out, accept all cookies, etc.).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -198768,7 +203762,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -198778,9 +203773,6 @@ "general-oecd-privacy-principles-2010": [ "1" ], - "general-scf-dpmp-2025": [ - "6.0" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.2.c", "III.12.a", @@ -198812,9 +203804,14 @@ "59.1-577.A", "59.1-577.A.5" ], + "emea-hun-act-cxii-2011": [ + "II.14.20(1)" + ], "emea-ken-pda-2019": [ - "26(a)", - "26(c)" + "IV.28(1)" + ], + "emea-zaf-popia-2013": [ + "3.A.2.12(1)" ] } }, @@ -198836,7 +203833,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically provide data subjects with functionality to exercise pre-selected opt-out preferences (e.g., opt-out signal).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -198887,13 +203884,11 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.7" - ], "usa-state-ca-ccpa-cpra-2026": [ "7025(a)", "7025(b)", @@ -198951,7 +203946,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to govern the continued use of Personal Data (PD) as it is collected, received, processed, stored, transmitted, shared and/or updated until:\n(1) Disposal of PD occurs when there is no longer a legitimate business purpose;\n(2) Disposal of PD occurs when the data retention timeline for the use case is met; and/or\n(3) Continued use of PD is prohibited upon withdrawal of data subject consent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -198989,7 +203984,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -199021,10 +204017,37 @@ "emea-eu-gdpr-2016": [ "Article 18.2" ], + "emea-ita-pdpc-2018": [ + "Article 99(1)" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 2(1)(b)(i)", + "Schedule 1 - 2(1)(b)(ii)" + ], "apac-ind-dpdpa-2023": [ "5(2)(b)", "9(2)", "9(3)" + ], + "apac-jpn-appi-2020": [ + "IV.1.30(2)", + "IV.1.30(4)", + "IV.1.30(6)", + "IV.1.30(7)", + "IV.1.31" + ], + "apac-sgp-pdpa-2012": [ + "4.2.19(a)", + "9.3.47(3)" + ], + "americas-bhs-dpa-2003": [ + "IV.35(1)", + "IV.35(1)(a)", + "IV.35(1)(b)", + "IV.36(1)" + ], + "americas-chl-act-19628-1999": [ + "I.9" ] } }, @@ -199033,7 +204056,7 @@ "title": "Cease Processing, Storing and/or Sharing Personal Data (PD)", "family": "PRI", "description": "Mechanisms exist to ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation.", - "scf_question": "Does the organization ensure it ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation?", + "scf_question": "Does the organization ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -199046,7 +204069,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Asset / process owners collect, store, processes, transmit share or use PD only for the purposes identified in the data privacy notice.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -199084,7 +204107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -199100,6 +204124,18 @@ ], "apac-ind-dpdpa-2023": [ "6(6)" + ], + "apac-mys-pdpa-2010": [ + "38(2)", + "42(1)", + "42(1)(a)" + ], + "apac-sgp-pdpa-2012": [ + "4.1.16(4)" + ], + "americas-bra-lgpd-2018": [ + "II.IV.15.II", + "II.IV.15.IV" ] } }, @@ -199121,7 +204157,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of processing changes affecting their Personal Data (PD), including:\n(1) Erasure of PD;\n(2) Remediation of incorrect PD; and/or\n(3) Processing restrictions affecting their PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -199157,13 +204193,25 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "emea-eu-gdpr-2016": [ "Article 18.3", "Article 19" + ], + "emea-deu-fdpa-2017": [ + "3.4.75(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.18(1)" + ], + "apac-jpn-appi-2020": [ + "IV.1.23(3)", + "IV.1.23(6)", + "IV.1.30(3)" ] } }, @@ -199185,7 +204233,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to obtain consent from data subjects to opt-in for the following Personal Data (PD) actions:\n(1) Collecting;\n(2) Receiving; \n(3) Processing;\n(4) Storing;\n(5) Transmitting:\n(6) Sharing; and/or\n(7) Updating.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -199221,7 +204269,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -199237,6 +204286,9 @@ "usa-state-va-cdpa-2023": [ "59.1-578.F.1", "59.1-578.F.1.b" + ], + "apac-sgp-pdpa-2012": [ + "9.3.46(2)" ] } }, @@ -199258,7 +204310,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to obtain parental or guardian consent for Personal Data (PD) processing actions through reasonable consumer expectations, when the data subject is a minor.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -199294,7 +204346,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -199319,15 +204372,51 @@ "usa-state-va-cdpa-2023": [ "59.1-578.F.1", "59.1-578.F.1.b" + ], + "emea-ken-pda-2019": [ + "IV.27(a)", + "IV.28(2)(d)", + "IV.33(2)", + "IV.33(4)" + ], + "emea-qat-pdppl-2020": [ + "4.17.2" + ], + "apac-chn-pipl-2021": [ + "Article 31" + ], + "apac-kor-pipa-2011": [ + "III.1.22(5)" + ], + "americas-bhs-dpa-2003": [ + "IV.33(1)", + "IV.33(2)", + "IV.33(3)", + "IV.33(4)", + "IV.33(4)(a)", + "IV.33(4)(b)", + "IV.33(4)(c)" + ], + "americas-bra-lgpd-2018": [ + "II.III.14", + "II.III.14.1", + "II.III.14.2", + "II.III.14.3", + "II.III.14.4", + "II.III.14.5", + "II.III.14.6" + ], + "americas-col-law-1581-2012": [ + "III.7" ] } }, { "control_id": "PRI-04", - "title": "Restrict Collection To Identified Purpose", + "title": "Restrict Collection, Processing & Sharing To Identified Purpose", "family": "PRI", - "description": "Mechanisms exist to minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", - "scf_question": "Does the organization minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent?", + "description": "Mechanisms exist to minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", + "scf_question": "Does the organization minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -199342,9 +204431,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -199396,8 +204485,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -199441,9 +204532,6 @@ "general-nist-800-82-r3": [ "PT-02" ], - "general-scf-dpmp-2025": [ - "3.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(a)(1)" ], @@ -199474,6 +204562,15 @@ "usa-state-il-ipa-2009": [ "10(b)(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.495.3(a)", + "603A.495.3(c)", + "603A.500.1(a)", + "603A.500.1(b)", + "603A.535.1", + "603A.535.1(a)", + "603A.535.1(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.578(1)(b)" ], @@ -199503,170 +204600,62 @@ "Article 5.1(c)", "Article 8.1" ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 29(1)", + "Title 2, Chapter II, Art. 29(2)" ], "emea-deu-fdpa-2017": [ - "Sec 4" + "3.1.47.2", + "3.1.47.3", + "3.1.47.6" ], "emea-grc-pirppd-1997": [ - "4" - ], - "emea-hun-isdfi-2011": [ - "4", - "5" - ], - "emea-irl-dpa-2003": [ - "2" + "B.4.1.a", + "B.4.1.b" ], - "emea-ita-pdpc-2003": [ - "11" + "emea-hun-act-cxii-2011": [ + "II.4.4(1)", + "II.4.4(2)", + "II.11.12(1)", + "II.12.13(2)" ], "emea-ken-pda-2019": [ - "25(c)", - "25(d)", - "27(a)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)" - ], - "emea-pol-act-29-1997": [ - "23" + "IV.25(c)", + "IV.27(a)" ], "emea-qat-pdppl-2020": [ - "9.1", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" - ], - "emea-rus-federal-law-27-2006": [ - "5" - ], - "emea-srb-act-9-2018": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "16" - ], - "emea-zaf-popia-2013": [ - "5", - "11", - "69" - ], - "emea-esp-decree-1720-2007": [ - "8" + "3.12" ], "emea-che-fadp-2025": [ - "4" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 3" - ], - "apac-chn-pipl-2021": [ - "26", - "31" + "2.1.6.3" ], "apac-ind-privacy-rules-2011": [ - "5" - ], - "apac-jpn-ppi-2020": [ - "17(1)" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 1", - "P1-(1)(a)", - "P1-(1)(b)", - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)", - "Principle 4", - "P4-(a)", - "P4-(b)", - "P4-(b)(i)", - "P4-(b)(ii)" - ], - "apac-phl-dpa-2012": [ - "19" + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(5)" ], - "apac-sgp-pdpa-2012": [ - "17" + "apac-jpn-appi-2020": [ + "IV.1.15(2)" ], "apac-kor-pipa-2011": [ - "3", - "15", - "22" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "4.1", - "4.2", - "6" + "III.1.15(1)", + "III.1.15(1)1", + "III.1.15(1)2", + "III.1.15(1)3", + "III.1.15(1)4", + "III.1.15(1)5", + "III.1.15(1)6" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.2" + "II.5(1)(c)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 4" - ], - "americas-col-law-1581-2012": [ - "4" + "P4-4.4" ], "americas-mex-fdpa-2010": [ - "7" + "II.7", + "II.12" ] } }, @@ -199690,7 +204679,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -199743,7 +204732,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -199780,9 +204770,6 @@ "1", "4(b)" ], - "general-scf-dpmp-2025": [ - "3.1" - ], "general-shared-assessments-sig-2025": [ "P.6" ], @@ -199805,11 +204792,11 @@ "3" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(1)(i)", - "164.502(a)(1)(ii)", - "164.502(a)(1)(iii)", - "164.502(a)(5)(i)", - "164.502(i)" + "§ 164.502(a)(1)(i)", + "§ 164.502(a)(1)(ii)", + "§ 164.502(a)(1)(iii)", + "§ 164.502(a)(5)(i)", + "§ 164.502(i)" ], "usa-federal-irs-1075-2021": [ "PT-2" @@ -199861,198 +204848,106 @@ "Article 9.3", "Article 10" ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(4)", + "Title 2, Chapter II, Art. 33(1)", + "Title 2, Chapter II, Art. 33(2)" ], "emea-deu-fdpa-2017": [ - "Sec 4" + "2.1.2.26(1)", + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.26(4)", + "3.2.49", + "3.2.50" ], "emea-grc-pirppd-1997": [ - "4" - ], - "emea-hun-isdfi-2011": [ - "4", - "5" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "11" + "B.4.1.a", + "B.4.1.b", + "B.5.2", + "B.5.2.a", + "B.5.2.b", + "B.5.2.c", + "B.5.2.d", + "B.5.2.e", + "B.8.3" + ], + "emea-hun-act-cxii-2011": [ + "II.4.4(1)", + "II.4.4(2)", + "II.4.4(3)", + "II.4.4(5)", + "II.5.5(1)(b)", + "II.5.5(2)(b)", + "II.5.5(2)(c)", + "II.5.5(3)", + "II.5.5(4)", + "II.5.6(1)(b)", + "II.5.6(5)(a)", + "II.10.11(1)(b)", + "II.11.12(1)" ], "emea-ken-pda-2019": [ - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)" + "IV.25(a)", + "IV.28(3)" ], "emea-nga-dpr-2019": [ - "2.1(1)(a)", - "2.1(1)(a)(i)", - "2.1(1)(a)(ii)", - "2.2(a)", - "2.2(b)", - "2.2(c)", - "2.2(d)", - "2.2(e)", - "2.4(a)" + "2.3(1)" ], - "emea-pol-act-29-1997": [ - "23" + "emea-nor-pda-2018": [ + "8" ], "emea-qat-pdppl-2020": [ - "9.2", - "18.1", - "18.2", - "18.3", - "18.4" - ], - "emea-rus-federal-law-27-2006": [ - "5" + "2.4", + "3.11.1" ], "emea-sau-pdpl-2023": [ "Article 13.1" ], "emea-srb-act-9-2018": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "7", - "7.1", - "7.2", - "14", - "20" + "II.14" ], "emea-zaf-popia-2013": [ - "2", - "3", - "4" - ], - "emea-esp-decree-1720-2007": [ - "8" + "3.A.2.11(1)", + "3.A.2.11(1)(a)", + "3.A.2.11(1)(b)", + "3.A.2.11(1)(c)", + "3.A.2.11(1)(d)", + "3.A.2.11(1)(e)", + "3.A.2.11(1)(f)" ], - "emea-che-fadp-2025": [ - "4" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "emea-gbr-dpa-2018": [ + "Section 44(2)(a)" ], "apac-aus-privacy-principles-2026": [ - "APP 3", - "APP 7" - ], - "apac-chn-pipl-2021": [ - "5", - "10", - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "26", - "29", - "30", - "47" + "2.3.1", + "2.3.2" ], "apac-ind-dpdpa-2023": [ "4(1)(b)" ], - "apac-ind-privacy-rules-2011": [ - "5" - ], - "apac-jpn-ppi-2020": [ - "17(1)", - "17(2)", - "17(2)(i)", - "17(2)(ii)", - "17(2)(iii)", - "17(2)(iv)", - "17(2)(v)", - "17(2)(vi)" - ], - "apac-phl-dpa-2012": [ - "19" - ], "apac-sgp-pdpa-2012": [ - "17" - ], - "apac-kor-pipa-2011": [ - "3", - "15" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "5.2", - "7.1", - "7.2", - "7.4", - "8" + "4.1.17(1)(a)" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.1", - "10", - "11" + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.36(3)", + "IV.36(3)(a)", + "IV.36(3)(b)", + "IV.36(3)(c)", + "IV.36(3)(c)(i)", + "IV.36(3)(c)(ii)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 4" + "P4-4.4" ], - "americas-col-law-1581-2012": [ - "4" + "americas-chl-act-19628-1999": [ + "I.4" ], "americas-mex-fdpa-2010": [ - "7" + "II.7" ] } }, @@ -200074,7 +204969,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure information is directly collected from the data subject, whenever possible.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -200120,7 +205015,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -200131,39 +205027,19 @@ "P.5.3" ], "emea-ken-pda-2019": [ - "28(1)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)" + "IV.28(1)" ], "emea-sau-pdpl-2023": [ "Article 10" ], - "apac-chn-pipl-2021": [ - "10" + "apac-aus-privacy-principles-2026": [ + "2.3.6", + "2.3.6.a", + "2.3.6.a.ii", + "2.3.6.b" ], "apac-nzl-privacy-act-2020": [ - "Principle 2", - "P2-(1)", - "P2-(2)", - "P2-(2)(a)", - "P2-(2)(b)", - "P2-(2)(c)", - "P2-(2)(d)", - "P2-(2)(e)(i)", - "P2-(2)(e)(ii)", - "P2-(2)(e)(iii)", - "P2-(2)(e)(iv)", - "P2-(2)(e)(v)", - "P2-(2)(f)", - "P2-(2)(g)(i)", - "P2-(2)(g)(ii)" + "3.1.22.2(1)" ] } }, @@ -200185,7 +205061,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -200233,14 +205109,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": { - "apac-chn-pipl-2021": [ - "26" - ] - } + "crosswalks": {} }, { "control_id": "PRI-04.4", @@ -200260,7 +205133,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -200290,7 +205163,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -200298,17 +205172,6 @@ "Article 10", "Article 14", "Article 15.2" - ], - "emea-srb-act-9-2018": [ - "20" - ], - "apac-jpn-ppi-2020": [ - "18(1)", - "18(2)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)" ] } }, @@ -200330,7 +205193,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -200381,7 +205244,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -200417,7 +205281,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -200468,7 +205332,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -200534,7 +205399,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -200544,6 +205410,9 @@ "general-iso-29100-2024": [ "6.7" ], + "emea-deu-fdpa-2017": [ + "3.3.56(2)" + ], "emea-sau-pdpl-2023": [ "Article 11.2" ] @@ -200554,7 +205423,7 @@ "title": "Personal Data (PD) Retention & Disposal", "family": "PRI", "description": "Mechanisms exist to: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records).", - "scf_question": "Does the organization: \n (1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n (2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n (3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records)?", + "scf_question": "Does the organization: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -200570,11 +205439,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -200657,7 +205526,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -200807,9 +205677,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.4.6" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "usa-federal-fbi-cjis-6-0": [ "4.2.2", "4.2.3.1", @@ -200885,73 +205752,52 @@ "emea-eu-gdpr-2016": [ "Article 5.1(e)" ], - "emea-us-psd2-2015": [ - "24" + "emea-aut-dpa-2018": [ + "§ 13(3)", + "§ 37(2)" ], - "emea-aut-fappd-2000": [ - "Sec 7" - ], - "emea-bel-act-8-1992": [ - "4-7", - "21" + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 30" ], "emea-deu-fdpa-2017": [ - "Sec 3a", - "Sec 5", - "Sec 13", - "Sec 14", - "Sec 20" - ], - "emea-deu-c5-2020": [ - "OPS-11", - "OPS-12", - "PI-03" + "3.1.47.5", + "3.2.48(2)2", + "3.3.58(2)", + "3.4.62(5)4", + "3.4.75(2)", + "3.4.75(4)" ], "emea-grc-pirppd-1997": [ - "4", - "7" - ], - "emea-hun-isdfi-2011": [ - "5" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-isr-ppl-5741-1981": [ - "8" - ], - "emea-ita-pdpc-2003": [ - "11" + "B.4.1.d", + "B.4.2" + ], + "emea-hun-act-cxii-2011": [ + "II.8.9(1)(b)", + "II.13.15(3)", + "II.13.17(2)(a)", + "II.13.17(2)(b)", + "II.13.17(2)(c)", + "II.13.17(2)(d)", + "II.13.17(2)(e)", + "II.14.20(4)(d)", + "II.15.21(7)" + ], + "emea-ita-pdpc-2018": [ + "Article 99(3)" ], "emea-ken-pda-2019": [ - "25(g)", - "34(3)", - "39(1)", - "39(1)(a)", - "39(1)(b)", - "39(1)(c)", - "39(1)(d)", - "39(2)" + "IV.25(g)", + "IV.34(1)(b)", + "IV.34(3)", + "IV.39(1)", + "IV.39(1)(a)", + "IV.39(1)(b)", + "IV.39(1)(c)", + "IV.39(1)(d)", + "IV.39(2)" ], "emea-nga-dpr-2019": [ - "2.1(1)(c)" - ], - "emea-nor-pda-2018": [ - "8", - "11", - "15", - "27", - "28" - ], - "emea-pol-act-29-1997": [ - "23", - "26" - ], - "emea-rus-federal-law-27-2006": [ - "5" + "3.1(9)(a)" ], "emea-sau-pdpl-2023": [ "Article 11.4", @@ -200959,127 +205805,103 @@ "Article 18.2.a", "Article 18.2.b" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], "emea-srb-act-9-2018": [ - "5.5", - "8" + "II.8", + "III.3.30-1(1)" ], "emea-zaf-popia-2013": [ - "4", - "14", - "16" - ], - "emea-esp-decree-1720-2007": [ - "8", - "22" + "3.A.3.14(1)", + "3.A.3.14(1)(a)", + "3.A.3.14(1)(b)", + "3.A.3.14(1)(c)", + "3.A.3.14(1)(d)", + "3.A.3.14(2)", + "3.A.3.14(3)", + "3.A.3.14(3)(a)", + "3.A.3.14(3)(b)", + "3.A.3.14(4)", + "3.A.3.14(5)", + "3.A.3.14(6)", + "3.A.3.14(6)(a)", + "3.A.3.14(6)(b)", + "3.A.3.14(6)(c)", + "3.A.3.14(6)(d)", + "3.A.3.14(7)" ], "emea-che-fadp-2025": [ - "4" - ], - "emea-tur-lppd-2016": [ - "5", - "7" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3", - "APP Part 6" + "2.1.6.4" ], "apac-aus-privacy-principles-2026": [ - "APP 4", - "APP 6" + "4.11.2", + "4.11.2.a", + "4.11.2.b", + "4.11.2.c", + "4.11.2.d" ], "apac-chn-pipl-2021": [ - "10", - "19", - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)" + "Article 19", + "Article 47" ], "apac-hkg-pdo-2022": [ - "Principle 2", - "Sec 26", - "Principle 3", - "Sec 4" + "26(1)", + "26(1)(a)", + "26(1)(b)", + "26(2)", + "26(2)(a)", + "26(2)(b)", + "Schedule 1 - 2(2)", + "Schedule 1 - 2(3)" ], "apac-ind-privacy-rules-2011": [ - "5" + "5(4)" ], - "apac-jpn-ppi-2020": [ - "19" + "apac-jpn-appi-2020": [ + "IV.2.35-2(5)" ], "apac-mys-pdpa-2010": [ - "5", - "6", - "10" + "10(1)", + "10(2)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.9" ], "apac-phl-dpa-2012": [ - "19", - "21" + "III.11(e)", + "III.11(f)" ], "apac-sgp-pdpa-2012": [ - "23", - "25" - ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" + "5.22A(1)", + "5.22A(2)" ], "apac-kor-pipa-2011": [ - "3", - "4", - "15", - "19", - "21", - "37" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "5.1", - "4.3", - "9.2" + "III.1.21(1)", + "III.1.21(2)", + "III.1.21(3)", + "III.1.21(4)" ], "americas-bhs-dpa-2003": [ - "6", - "12" + "II.5(1)(e)", + "II.9(1)", + "II.9(1)(a)", + "II.9(1)(b)", + "II.9(1)(c)" ], "americas-bra-lgpd-2018": [ - "6.2", - "6.9", - "13", - "14", - "15", - "21" + "II.IV.16", + "II.IV.16.I", + "II.IV.16.II", + "II.IV.16.III", + "II.IV.16.IV" ], "americas-can-pipeda-2000": [ - "Sec 7", - "Sec 8", - "Principle 5", - "Principle 6" + "P5-4.5.3", + "P7-4.7.5" ], "americas-chl-act-19628-1999": [ - "9" - ], - "americas-col-law-1581-2012": [ - "4" + "I.6" ], "americas-mex-fdpa-2010": [ - "7", - "8", - "9", - "11", - "12", - "13", - "14" + "II.11" ] } }, @@ -201103,7 +205925,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to address the use of Personal Data (PD) for internal testing, training and research that:\n(1) Takes measures to limit or minimize the amount of PD used for internal testing, training and research purposes; and\n(2) Authorizes the use of PD when such information is required for internal testing, training and research.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -201170,7 +205992,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -201241,9 +206064,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.5.5" ], - "general-scf-dpmp-2025": [ - "3.3" - ], "usa-federal-fbi-cjis-6-0": [ "4.2.2", "4.2.3.1", @@ -201281,7 +206101,7 @@ "SI-12(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.508(a)(2)(i)(B)" + "§ 164.508(a)(2)(i)(B)" ], "usa-federal-irs-1075-2021": [ "PT-2", @@ -201312,168 +206132,286 @@ "47-18-3207(b)(3)(B)", "47-18-3207(b)(3)(C)" ], - "emea-aut-fappd-2000": [ - "Sec 12" - ], - "emea-bel-act-8-1992": [ - "4-7", - "21" + "emea-aut-dpa-2018": [ + "§ 7(2)" ], - "emea-hun-isdfi-2011": [ - "9" + "emea-deu-fdpa-2017": [ + "2.1.2.27(3)" ], - "emea-isr-ppl-5741-1981": [ - "8" + "emea-grc-pirppd-1997": [ + "B.7.2.f" ], - "emea-ita-pdpc-2003": [ - "13", - "20" + "emea-ita-pdpc-2018": [ + "Article 99(3)", + "Article 105(1)", + "Article 105(2)", + "Article 105(3)", + "Article 105(4)" ], "emea-ken-pda-2019": [ - "25(a)", - "25(b)", - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "34(1)(a)", - "34(1)(b)", - "34(1)(c)", - "34(1)(d)", - "34(2)(a)", - "34(2)(b)", - "34(3)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)", - "53(1)", - "53(2)", - "53(3)(a)", - "53(3)(b)", - "53(4)" + "IV.30(1)(b)(viii)" ], - "emea-nga-dpr-2019": [ - "2.1(1)(b)", - "3.1(12)" + "apac-phl-dpa-2012": [ + "IV.19" ], - "emea-nor-pda-2018": [ - "11", - "27" + "americas-bhs-dpa-2003": [ + "II.5(2)" ], - "emea-pol-act-29-1997": [ - "26" + "americas-bra-lgpd-2018": [ + "II.I.7.IV" + ] + } + }, + { + "control_id": "PRI-05.2", + "title": "Personal Data (PD) Accuracy & Integrity", + "family": "PRI", + "description": "Mechanisms exist to ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n(1) Keeping PD up-to-date; and \n(2) Remediating identified inaccuracies, as necessary.", + "scf_question": "Does the organization ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n (1) Keeping PD up-to-date; and \n (2) Remediating identified inaccuracies, as necessary?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Data", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n(1) Keeping PD up-to-date; and \n(2) Remediating identified inaccuracies, as necessary.", + "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", + "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" + }, + "risks": [ + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Data Privacy", + "crosswalks": { + "general-aicpa-pmf-2020": [ + "M1.0-POF7", + "Q8.1", + "Q8.1-POF2" ], - "emea-qat-pdppl-2020": [ - "8.2", - "9.4" + "general-apec-privacy-framework-2015": [ + "6" + ], + "general-iso-29100-2024": [ + "6.7" + ], + "general-nist-800-53-r4": [ + "DI-2" + ], + "general-nist-800-53-r5-2": [ + "PM-24" + ], + "general-nist-800-53-r5-2-privacy": [ + "PM-24" + ], + "general-nist-800-82-r3": [ + "PM-24" + ], + "general-nist-800-82-r3-low": [ + "PM-24" + ], + "general-nist-800-82-r3-mod": [ + "PM-24" + ], + "general-nist-800-82-r3-high": [ + "PM-24" + ], + "general-shared-assessments-sig-2025": [ + "P.5.1" + ], + "usa-federal-doc-data-privacy-framework-2023": [ + "II.5.a" + ], + "usa-federal-gsa-fedramp-5-low": [ + "PM-24" + ], + "usa-federal-gsa-fedramp-5-mod": [ + "PM-24" + ], + "usa-federal-gsa-fedramp-5-high": [ + "PM-24" + ], + "usa-federal-gsa-fedramp-5-li-saas": [ + "PM-24" + ], + "usa-federal-hhs-45-cfr-155-260-2016": [ + "155.260(a)(3)(vi)" + ], + "usa-federal-cms-marse-2-0": [ + "DI-2", + "DI-2.a", + "DI-2.b" + ], + "emea-eu-gdpr-2016": [ + "Article 5.1(d)" + ], + "emea-aut-dpa-2018": [ + "§ 37(6)", + "§ 37(7)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 32(2)" + ], + "emea-deu-fdpa-2017": [ + "3.1.47.4", + "3.4.74(1)" + ], + "emea-hun-act-cxii-2011": [ + "II.4.4(4)", + "II.13.17(1)" + ], + "emea-irl-dpa-2018": [ + "s.74" + ], + "emea-ken-pda-2019": [ + "IV.25(f)" + ], + "emea-sau-pdpl-2023": [ + "Article 14" ], "emea-srb-act-9-2018": [ - "5.1", - "5.3", - "7", - "7.1", - "7.2", - "20" + "II.11" ], "emea-zaf-popia-2013": [ - "10" - ], - "emea-esp-decree-1720-2007": [ - "8" + "3.A.5.16(1)", + "3.A.5.16(2)" ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3" + "emea-che-fadp-2025": [ + "2.1.6.5" ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "emea-gbr-dpa-2018": [ + "Section 46(1)", + "Section 47(3)" ], "apac-aus-privacy-principles-2026": [ - "APP 6" + "4.10.1", + "4.10.2" ], "apac-chn-pipl-2021": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "28", - "47" + "Article 8" ], - "apac-jpn-ppi-2020": [ - "16-2" + "apac-hkg-pdo-2022": [ + "Schedule 1 - 2(1)(a)", + "Schedule 1 - 2(1)(b)", + "Schedule 1 - 2(1)(c)(i)", + "Schedule 1 - 2(1)(c)(ii)", + "Schedule 1 - 2(1)(c)(ii)(A)", + "Schedule 1 - 2(1)(c)(ii)(B)" + ], + "apac-ind-dpdpa-2023": [ + "8(3)", + "8(3)(a)", + "8(3)(b)" + ], + "apac-ind-privacy-rules-2011": [ + "5(6)" + ], + "apac-jpn-appi-2020": [ + "IV.1.19" + ], + "apac-mys-pdpa-2010": [ + "11" ], "apac-nzl-privacy-act-2020": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "3.1.22.8" ], "apac-phl-dpa-2012": [ - "19" + "III.11(c)" ], - "apac-kor-pipa-2011": [ - "3" + "apac-sgp-pdpa-2012": [ + "6.23", + "6.23(a)", + "6.23(b)", + "6.25", + "6.25(a)", + "6.25(b)" + ], + "apac-twn-pdpa-2025": [ + "I.11" ], "americas-arg-ppd-2018": [ - "7.3", - "9.2" + "A.1.3" ], "americas-bhs-dpa-2003": [ - "6" + "II.5(1)(d)", + "II.5(3)", + "II.10(1)", + "II.10(2)", + "II.10(2)(a)", + "II.10(2)(b)" + ], + "americas-can-pipeda-2000": [ + "P6-4.6", + "P6-4.6.1", + "P6-4.6.2", + "P6-4.6.3" + ], + "americas-chl-act-19628-1999": [ + "I.9" ], "americas-col-law-1581-2012": [ - "4" + "VI.17(f)", + "VI.17(g)" + ], + "americas-mex-fdpa-2010": [ + "II.11" ] } }, { - "control_id": "PRI-05.2", - "title": "Personal Data (PD) Accuracy & Integrity", + "control_id": "PRI-05.3", + "title": "Data Anonymization", "family": "PRI", - "description": "Mechanisms exist to ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n(1) Keeping PD up-to-date; and \n(2) Remediating identified inaccuracies, as necessary.", - "scf_question": "Does the organization ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n (1) Keeping PD up-to-date; and \n (2) Remediating identified inaccuracies, as necessary?", - "relative_weight": 5, + "description": "Mechanisms exist to mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification.", + "scf_question": "Does the organization mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification?", + "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Data", @@ -201481,13 +206419,13 @@ "scrm_focus": { "strategic": false, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n(1) Keeping PD up-to-date; and \n(2) Remediating identified inaccuracies, as necessary.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -201531,205 +206469,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" - ], - "family_name": "Data Privacy", - "crosswalks": { - "general-aicpa-pmf-2020": [ - "M1.0-POF7", - "Q8.1", - "Q8.1-POF2" - ], - "general-apec-privacy-framework-2015": [ - "6" - ], - "general-iso-29100-2024": [ - "6.7" - ], - "general-nist-800-53-r4": [ - "DI-2" - ], - "general-nist-800-53-r5-2": [ - "PM-24" - ], - "general-nist-800-53-r5-2-privacy": [ - "PM-24" - ], - "general-nist-800-82-r3": [ - "PM-24" - ], - "general-nist-800-82-r3-low": [ - "PM-24" - ], - "general-nist-800-82-r3-mod": [ - "PM-24" - ], - "general-nist-800-82-r3-high": [ - "PM-24" - ], - "general-scf-dpmp-2025": [ - "5.9" - ], - "general-shared-assessments-sig-2025": [ - "P.5.1" - ], - "usa-federal-doc-data-privacy-framework-2023": [ - "II.5.a" - ], - "usa-federal-gsa-fedramp-5-low": [ - "PM-24" - ], - "usa-federal-gsa-fedramp-5-mod": [ - "PM-24" - ], - "usa-federal-gsa-fedramp-5-high": [ - "PM-24" - ], - "usa-federal-gsa-fedramp-5-li-saas": [ - "PM-24" - ], - "usa-federal-hhs-45-cfr-155-260-2016": [ - "155.260(a)(3)(vi)" - ], - "usa-federal-cms-marse-2-0": [ - "DI-2", - "DI-2.a", - "DI-2.b" - ], - "emea-eu-gdpr-2016": [ - "Article 5.1(d)" - ], - "emea-ken-pda-2019": [ - "25(f)" - ], - "emea-nor-pda-2018": [ - "11" - ], - "emea-sau-pdpl-2023": [ - "Article 14" - ], - "emea-srb-act-9-2018": [ - "5.4" - ], - "emea-zaf-popia-2013": [ - "14", - "16" - ], - "emea-esp-decree-1720-2007": [ - "8" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 10" - ], - "apac-aus-privacy-principles-2026": [ - "APP 10" - ], - "apac-chn-pipl-2021": [ - "8" - ], - "apac-ind-dpdpa-2023": [ - "8(3)", - "8(3)(a)", - "8(3)(b)" - ], - "apac-jpn-ppi-2020": [ - "19" - ], - "apac-mys-pdpa-2010": [ - "11" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 9" - ], - "apac-sgp-pdpa-2012": [ - "23" - ], - "apac-kor-pipa-2011": [ - "3" - ], - "americas-arg-ppd-2018": [ - "4.5" - ], - "americas-bhs-dpa-2003": [ - "6" - ], - "americas-can-pipeda-2000": [ - "Principle 6" - ], - "americas-col-law-1581-2012": [ - "4" - ], - "americas-mex-fdpa-2010": [ - "9" - ] - } - }, - { - "control_id": "PRI-05.3", - "title": "Data Masking", - "family": "PRI", - "description": "Mechanisms exist to mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification.", - "scf_question": "Does the organization mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification?", - "relative_weight": 8, - "conformity_cadence": "Annual", - "evidence_requests": [], - "pptdf": "Data", - "nist_csf_function": "Identify", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": true - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification.", - "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." - }, - "profiles": [ - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], - "possible_solutions": { - "micro_small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "small": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "medium": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "large": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management", - "enterprise": "∙ Data classification program\n∙ Data privacy program\n∙ Data Protection Impact Assessment (DPIA)\n∙ Product / project management" - }, - "risks": [ - "R-AM-3", - "R-BC-1", - "R-BC-2", - "R-EX-1", - "R-EX-2", - "R-EX-3", - "R-EX-4", - "R-EX-5", - "R-GV-1", - "R-GV-2", - "R-GV-3", - "R-GV-4", - "R-GV-5" - ], - "threats": [ - "NT-7", - "MT-1", - "MT-2", - "MT-7", - "MT-8", - "MT-9", - "MT-10", - "MT-11", - "MT-12", - "MT-13", - "MT-14", - "MT-15", - "MT-24", - "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-iso-27002-2022": [ @@ -201771,9 +206514,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "3.4.1" ], - "general-scf-dpmp-2025": [ - "5.1" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-19(04)" ], @@ -201792,14 +206532,25 @@ "usa-state-va-cdpa-2023": [ "59.1-581.A.1" ], - "apac-aus-privacy-act-1998": [ - "APP Part 2" + "emea-deu-fdpa-2017": [ + "3.2.48(2)6", + "3.2.50" ], - "apac-kor-pipa-2011": [ - "3" + "emea-rus-152-fz-2025": [ + "Art. 13.1" ], - "americas-arg-ppd-2018": [ - "4.4" + "emea-sau-cscc-1-2019": [ + "2-6-1-1" + ], + "apac-jpn-appi-2020": [ + "IV.2.35-2(1)" + ], + "americas-bra-lgpd-2018": [ + "II.II.13", + "II.II.13.1", + "II.II.13.2", + "II.II.13.3", + "II.II.13.4" ] } }, @@ -201821,7 +206572,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) to:\n(1) The purpose(s) originally collected, consistent with the data privacy notice(s);\n(2) What is authorized by the data subject, or authorized agent; and\n(3) What is consistent with applicable laws, regulations and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -201878,7 +206629,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -201976,9 +206728,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.5.5" ], - "general-scf-dpmp-2025": [ - "3.3" - ], "general-shared-assessments-sig-2025": [ "P.2.3" ], @@ -202022,64 +206771,64 @@ "155.260(a)(3)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(c)", - "164.502(d)(1)", - "164.504(g)(2)", - "164.506(a)", - "164.506(c)(1)", - "164.506(c)(5)", - "164.508(a)(1)", - "164.508(a)(2)(i)(C)", - "164.510(a)(1)(i)(A)", - "164.510(a)(1)(i)(B)", - "164.510(a)(1)(i)(C)", - "164.510(a)(1)(i)(D)", - "164.510(a)(1)(ii)(A)", - "164.510(a)(1)(ii)(B)", - "164.510(b)(4)", - "164.512", - "164.512(i)(1)", - "164.512(j)(1)", - "164.512(j)(1)(i)(A)", - "164.512(j)(1)(i)(B)", - "164.512(j)(1)(ii)", - "164.512(j)(1)(ii)(A)", - "164.512(j)(1)(ii)(B)", - "164.512(j)(2)(i)", - "164.512(j)(2)(ii)", - "164.512(j)(3)", - "164.512(j)(4)", - "164.512(k)(1)(i)", - "164.512(k)(1)(i)(A)", - "164.512(k)(1)(i)(B)", - "164.512(k)(1)(ii)", - "164.512(k)(1)(iii)", - "164.512(k)(1)(iv)", - "164.512(k)(2)", - "164.512(k)(3)", - "164.512(k)(4)", - "164.512(k)(4)(i)", - "164.512(k)(4)(ii)", - "164.512(k)(4)(iii)", - "164.512(k)(5)(i)", - "164.512(k)(5)(i)(A)", - "164.512(k)(5)(i)(B)", - "164.512(k)(5)(i)(C)", - "164.512(k)(5)(i)(D)", - "164.512(k)(5)(i)(E)", - "164.512(k)(5)(i)(F)", - "164.512(k)(5)(ii)", - "164.512(k)(5)(iii)", - "164.512(k)(6)(i)", - "164.512(k)(6)(ii)", - "164.512(k)(6)(ii)(1)", - "164.514(f)(2)(i)", - "164.514(g)", - "164.530(i)(4)(ii)", - "164.530(i)(4)(ii)(B)", - "164.532(a)", - "164.532(b)", - "164.532(c)" + "§ 164.502(c)", + "§ 164.502(d)(1)", + "§ 164.504(g)(2)", + "§ 164.506(a)", + "§ 164.506(c)(1)", + "§ 164.506(c)(5)", + "§ 164.508(a)(1)", + "§ 164.508(a)(2)(i)(C)", + "§ 164.510(a)(1)(i)(A)", + "§ 164.510(a)(1)(i)(B)", + "§ 164.510(a)(1)(i)(C)", + "§ 164.510(a)(1)(i)(D)", + "§ 164.510(a)(1)(ii)(A)", + "§ 164.510(a)(1)(ii)(B)", + "§ 164.510(b)(4)", + "§ 164.512", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.512(j)(1)(i)(A)", + "§ 164.512(j)(1)(i)(B)", + "§ 164.512(j)(1)(ii)", + "§ 164.512(j)(1)(ii)(A)", + "§ 164.512(j)(1)(ii)(B)", + "§ 164.512(j)(2)(i)", + "§ 164.512(j)(2)(ii)", + "§ 164.512(j)(3)", + "§ 164.512(j)(4)", + "§ 164.512(k)(1)(i)", + "§ 164.512(k)(1)(i)(A)", + "§ 164.512(k)(1)(i)(B)", + "§ 164.512(k)(1)(ii)", + "§ 164.512(k)(1)(iii)", + "§ 164.512(k)(1)(iv)", + "§ 164.512(k)(2)", + "§ 164.512(k)(3)", + "§ 164.512(k)(4)", + "§ 164.512(k)(4)(i)", + "§ 164.512(k)(4)(ii)", + "§ 164.512(k)(4)(iii)", + "§ 164.512(k)(5)(i)", + "§ 164.512(k)(5)(i)(A)", + "§ 164.512(k)(5)(i)(B)", + "§ 164.512(k)(5)(i)(C)", + "§ 164.512(k)(5)(i)(D)", + "§ 164.512(k)(5)(i)(E)", + "§ 164.512(k)(5)(i)(F)", + "§ 164.512(k)(5)(ii)", + "§ 164.512(k)(5)(iii)", + "§ 164.512(k)(6)(i)", + "§ 164.512(k)(6)(ii)", + "§ 164.512(k)(6)(ii)(1)", + "§ 164.514(f)(2)(i)", + "§ 164.514(g)", + "§ 164.530(i)(4)(ii)", + "§ 164.530(i)(4)(ii)(B)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)" ], "usa-federal-irs-1075-2021": [ "PT-2" @@ -202128,125 +206877,349 @@ "Article 10.5(c)", "Article 10.5(d)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" - ], - "emea-aut-fappd-2000": [ - "Sec 12" - ], - "emea-bel-act-8-1992": [ - "4-7", - "21" - ], - "emea-hun-isdfi-2011": [ - "9" + "emea-aut-dpa-2018": [ + "§ 7(1)", + "§ 7(6)", + "§ 38", + "§ 39", + "§ 40(1)", + "§ 40(2)", + "§ 40(3)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 8(3)", + "Title 1, Chapter II, Art. 9", + "Title 1, Chapter II, Art. 10(1)", + "Title 2, Chapter III, Art. 45(2)" ], - "emea-isr-ppl-5741-1981": [ - "8" + "emea-deu-fdpa-2017": [ + "2.1.1.22(1)", + "2.1.1.22(1)1", + "2.1.1.22(1)1(a)", + "2.1.1.22(1)1(b)", + "2.1.1.22(1)1(c)", + "2.1.1.22(1)1(d)", + "2.1.1.22(1)2(a)", + "2.1.1.22(1)2(b)", + "2.1.1.22(2)", + "2.1.1.22(2)1", + "2.1.1.22(2)2", + "2.1.1.22(2)3", + "2.1.1.22(2)8", + "2.1.1.22(2)9", + "2.1.1.22(2)10", + "2.1.1.24(1)", + "2.1.1.24(1)1", + "2.1.1.24(1)2", + "2.1.1.24(2)", + "2.2.33(1)2(a)", + "2.2.33(1)3(b)", + "3.2.52" ], - "emea-ita-pdpc-2003": [ - "13", - "20" + "emea-grc-pirppd-1997": [ + "B.7.1", + "B.7.2", + "B.8.3" + ], + "emea-hun-act-cxii-2011": [ + "II.11.12(3)(a)", + "II.11.12(3)(b)", + "II.12.13(2)" + ], + "emea-irl-dpa-2018": [ + "s.45", + "s.46", + "s.47", + "s.48", + "s.49", + "s.50", + "s.51", + "s.52", + "s.53", + "s.54", + "s.55", + "s.73" + ], + "emea-ita-pdpc-2018": [ + "Article 2-f(1)", + "Article 2-g(1)", + "Article 101(1)", + "Article 101(2)", + "Article 101(3)", + "Article 122(1)" ], "emea-ken-pda-2019": [ - "44", - "45(a)", - "45(a)(i)", - "45(a)(ii)", - "45(b)", - "45(c)(i)", - "45(c)(ii)", - "45(c)(iii)", - "46(1)(a)", - "46(1)(b)", - "46(2)(a)", - "46(2)(b)", - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" + "IV.25(a)", + "IV.25(b)", + "IV.28(3)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(1)(b)(i)", + "IV.30(1)(b)(ii)", + "IV.30(1)(b)(iii)", + "IV.30(1)(b)(iv)", + "IV.30(1)(b)(v)", + "IV.30(1)(b)(vi)", + "IV.30(1)(b)(vii)", + "IV.30(2)", + "IV.33(1)", + "IV.33(1)(a)", + "IV.33(1)(b)", + "IV.36", + "V.45", + "V.45(a)", + "V.45(a)(i)", + "V.45(a)(ii)", + "V.45(b)", + "V.45(c)", + "V.45(c)(i)", + "V.45(c)(ii)", + "V.45(c)(iii)", + "V.46(1)", + "V.46(1)(a)", + "V.46(1)(b)", + "V.46(2)(a)", + "V.46(2)(b)" ], "emea-nga-dpr-2019": [ + "2.1(1)(a)", + "2.1(1)(a)(i)", + "2.1(1)(a)(ii)", + "2.1(1)(b)", + "2.1(1)(c)", + "2.2(a)", + "2.2(c)", + "2.2(d)", + "2.2(e)", "3.1(12)" ], "emea-nor-pda-2018": [ - "9" - ], - "emea-pol-act-29-1997": [ - "27" + "9", + "12" ], "emea-qat-pdppl-2020": [ - "8.2", - "9.4", - "10", - "16", - "22" + "3.10", + "4.16", + "4.17", + "4.17.4" ], - "emea-rus-federal-law-27-2006": [ - "6", - "10" + "emea-rus-152-fz-2025": [ + "Art. 10", + "Art. 11", + "Art. 13" ], "emea-sau-pdpl-2023": [ "Article 11.3" ], "emea-srb-act-9-2018": [ - "5.1", - "5.3", - "17", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5", - "17.6", - "17.7", - "17.8", - "17.9", - "17.10", - "18.1", - "18.2", - "18.3", - "19" + "II.6(1)", + "II.6(2)", + "II.6(3)", + "II.6(4)", + "II.6(5)", + "II.7", + "II.7(1)", + "II.7(2)", + "II.12", + "II.12(1)", + "II.12(2)", + "II.12(3)", + "II.12(4)", + "II.12(5)", + "II.12(6)", + "II.13", + "II.17", + "II.17(1)", + "II.17(2)", + "II.17(3)", + "II.17(4)", + "II.17(5)", + "II.17(6)", + "II.17(7)", + "II.17(8)", + "II.17(9)", + "II.17(10)", + "II.18", + "II.18(1)", + "II.18(2)", + "II.18(3)", + "II.19", + "II.20", + "IV.1.46", + "IV.1.47-1", + "IV.1.47-1(1)", + "IV.1.47-1(2)", + "IV.1.47-1(3)", + "IV.1.47-1(4)", + "IV.1.47-1(5)", + "IV.1.47-1(6)", + "IV.1.47-1(7)" ], "emea-zaf-popia-2013": [ - "15", - "26" + "3.A.4.15(1)", + "3.A.4.15(2)", + "3.A.4.15(2)(a)", + "3.A.4.15(2)(b)", + "3.A.4.15(2)(c)", + "3.A.4.15(2)(d)", + "3.A.4.15(2)(e)", + "3.A.4.15(3)", + "3.A.4.15(3)(a)", + "3.A.4.15(3)(b)", + "3.A.4.15(3)(c)", + "3.A.4.15(3)(c)(i)", + "3.A.4.15(3)(c)(ii)", + "3.A.4.15(3)(c)(iii)", + "3.A.4.15(3)(c)(iv)", + "3.A.4.15(3)(d)", + "3.A.4.15(3)(d)(i)", + "3.A.4.15(3)(d)(ii)", + "3.A.4.15(3)(e)", + "3.A.4.15(3)(f)", + "3.B.26(1)", + "3.B.26(1)(a)", + "3.B.26(1)(b)", + "3.B.26(1)(b)(i)", + "3.B.26(1)(b)(ii)", + "3.B.27(1)", + "3.B.27(1)(a)", + "3.B.27(1)(b)", + "3.B.27(1)(c)", + "3.B.27(1)(d)", + "3.B.27(1)(d)(i)", + "3.B.27(1)(d)(ii)", + "3.B.27(1)(e)", + "3.B.27(1)(f)", + "3.B.27(2)", + "3.B.27(3)" ], "emea-tur-lppd-2016": [ - "6" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "4(1)", + "4(2)", + "4(2)(a)", + "4(2)(b)", + "4(2)(c)", + "4(2)(ç)", + "4(2)(d)", + "5(1)", + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(2)(c)", + "5(2)(ç)", + "5(2)(d)", + "5(2)(e)", + "5(2)(f)", + "6(1)", + "6(2)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "6(3)(ç)", + "6(3)(d)", + "6(3)(e)", + "6(3)(f)", + "6(3)(g)", + "6(4)", + "7(1)", + "7(2)", + "7(3)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(4)", + "Section 44(4)(a)", + "Section 44(4)(b)", + "Section 44(4)(c)", + "Section 44(4)(e)", + "Section 47(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 6", - "APP 7", - "APP 9" + "2.3.3", + "2.3.3.a", + "2.3.3.a.i", + "2.3.3.a.ii", + "2.3.3.b", + "2.3.4", + "2.3.4.a", + "2.3.4.b", + "2.3.4.c", + "2.3.4.d", + "2.3.4.d.i", + "2.3.4.d.ii", + "2.3.4.e", + "2.3.4.e.i", + "2.3.4.e.ii", + "3.6.1", + "3.6.1.a", + "3.6.1.b", + "3.6.2", + "3.6.2.a", + "3.6.2.a.i", + "3.6.2.a.ii", + "3.6.2.b", + "3.6.2.c", + "3.6.2.d", + "3.6.2.e", + "3.6.3", + "3.6.4", + "3.6.4.a", + "3.6.4.b", + "3.7.1", + "3.7.2", + "3.7.2.a", + "3.7.2.b", + "3.7.2.c", + "3.7.2.d", + "3.7.3", + "3.7.3.a", + "3.7.3.a.i", + "3.7.3.a.ii", + "3.7.3.b", + "3.7.3.b.i", + "3.7.3.b.ii", + "3.7.3.c", + "3.7.3.d", + "3.7.3.d.i", + "3.7.3.d.ii", + "3.7.3.e", + "3.7.4", + "3.7.5", + "3.7.5.a", + "3.7.5.b", + "3.7.5.c" ], "apac-chn-cybersecurity-law-2017": [ "Article 41", "Article 44" ], + "apac-chn-csnip-2012": [ + "V" + ], "apac-chn-pipl-2021": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "28", - "29", - "30", - "31", - "32" + "Article 13", + "Article 28" + ], + "apac-hkg-pdo-2022": [ + "35K(1)", + "35K(1)(a)", + "35K(1)(b)", + "35K(1)(c)", + "35K(2)", + "35K(2)(a)", + "35K(2)(b)", + "35K(2)(c)", + "35K(3)", + "Schedule 1 - 3(1)", + "Schedule 1 - 3(2)", + "Schedule 1 - 3(2)(a)", + "Schedule 1 - 3(2)(a)(i)", + "Schedule 1 - 3(2)(a)(ii)", + "Schedule 1 - 3(2)(a)(iii)", + "Schedule 1 - 3(2)(b)", + "Schedule 1 - 3(2)(c)", + "Schedule 1 - 3(3)" ], "apac-ind-dpdpa-2023": [ "7(f)", @@ -202255,62 +207228,273 @@ "7(i)", "8(1)" ], - "apac-jpn-ppi-2020": [ - "16-2" + "apac-jpn-appi-2020": [ + "IV.1.16(1)", + "IV.1.17(2)", + "IV.1.17(2)(i)", + "IV.1.17(2)(ii)", + "IV.1.17(2)(iii)", + "IV.1.17(2)(iv)", + "IV.1.17(2)(v)", + "IV.1.17(2)(vi)", + "IV.1.23(1)(i)", + "IV.1.23(1)(ii)", + "IV.1.23(1)(iii)", + "IV.1.23(1)(iv)" ], "apac-mys-pdpa-2010": [ - "34" + "6(1)(a)", + "6(2)", + "6(2)(a)", + "6(2)(b)", + "6(2)(c)", + "6(2)(d)", + "6(2)(e)", + "6(2)(f)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "8", + "8(a)", + "8(a)(i)", + "8(a)(ii)", + "8(b)", + "39", + "39(a)", + "39(b)", + "39(b)(i)", + "39(b)(ii)", + "39(c)", + "39(d)", + "39(e)", + "40(1)", + "40(1)(a)", + "40(1)(b)", + "40(1)(b)(i)", + "40(1)(b)(ii)", + "40(1)(b)(ii)(A)", + "40(1)(b)(ii)(B)", + "40(1)(b)(iii)", + "40(1)(b)(iv)", + "40(1)(b)(iv)(A)", + "40(1)(b)(iv)(B)", + "40(1)(b)(v)", + "40(1)(b)(vi)", + "40(1)(b)(vii)", + "40(1)(b)(viii)", + "40(1)(b)(ix)", + "40(1)(b)(x)", + "40(1)(c)", + "42(1)(b)", + "42(1)(b)(A)", + "42(1)(b)(B)", + "42(2)", + "42(2)(a)", + "42(2)(b)", + "42(2)(b)(i)", + "42(2)(b)(ii)", + "42(2)(b)(iii)", + "42(2)(b)(iv)", + "42(2)(c)", + "42(3)", + "42(3)(a)", + "42(3)(b)", + "42(4)", + "42(5)" ], "apac-nzl-privacy-act-2020": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "3.1.22.1(1)", + "3.1.22.1(1)(a)", + "3.1.22.1(1)(b)", + "3.1.22.10(1)", + "3.1.22.10(1)(a)", + "3.1.22.10(1)(b)", + "3.1.22.10(1)(b)(i)", + "3.1.22.10(1)(b)(ii)", + "3.1.22.10(1)(c)", + "3.1.22.10(1)(d)", + "3.1.22.10(1)(e)", + "3.1.22.10(1)(e)(i)", + "3.1.22.10(1)(e)(ii)", + "3.1.22.10(1)(e)(iii)", + "3.1.22.10(1)(e)(iv)", + "3.1.22.10(1)(f)", + "3.1.22.10(1)(f)(i)", + "3.1.22.10(1)(f)(ii)" ], "apac-phl-dpa-2012": [ - "19", - "22", - "34" + "III.11(a)", + "III.11(c)", + "III.12(b)", + "III.12(c)", + "III.12(d)", + "III.12(e)", + "III.12(f)", + "III.13", + "III.13(a)", + "III.13(b)", + "III.13(c)", + "III.13(d)", + "III.13(e)", + "III.13(f)" ], "apac-sgp-pdpa-2012": [ - "14" + "4.1.13", + "4.1.13(a)", + "4.1.13(b)", + "4.1.15(3)(a)", + "4.1.15(3)(b)", + "4.1.15(3)(c)", + "4.1.17(1)(b)", + "4.1.17(2)(a)" ], "apac-kor-pipa-2011": [ - "16", - "18", - "23" + "III.1.18(1)", + "III.1.18(2)", + "III.1.18(2)1", + "III.1.18(2)2", + "III.1.18(2)3", + "III.1.18(2)4", + "III.1.18(2)5", + "III.1.18(2)6", + "III.1.18(2)7", + "III.1.18(2)8", + "III.1.18(2)9", + "III.1.19", + "III.1.19.1", + "III.1.19.2", + "III.2.23.1", + "III.2.23.2" ], "apac-twn-pdpa-2025": [ - "5" - ], - "americas-arg-ppd-2018": [ - "4.3" + "I.6", + "I.6.1", + "I.6.2", + "I.6.3", + "I.6.4", + "I.6.5", + "I.6.6", + "III.19", + "III.19.1", + "III.19.2", + "III.19.3", + "III.19.4", + "III.19.5", + "III.19.6", + "III.19.7", + "III.19.8", + "III.20", + "III.20.1", + "III.20.2", + "III.20.3", + "III.20.4", + "III.20.5", + "III.20.6", + "III.20.7" ], "americas-bhs-dpa-2003": [ - "12" + "IV.29(2)", + "IV.29(2)(a)", + "IV.29(2)(b)", + "IV.29(2)(c)", + "IV.29(2)(d)", + "IV.34(1)", + "IV.34(2)", + "IV.34(2)(a)", + "IV.34(2)(b)", + "IV.34(2)(c)", + "IV.34(2)(d)", + "IV.34(2)(e)", + "IV.34(2)(e)(i)", + "IV.34(2)(e)(ii)", + "IV.34(2)(f)", + "IV.34(2)(g)", + "IV.34(2)(h)", + "IV.34(2)(i)", + "IV.34(2)(j)", + "IV.34(2)(k)", + "IV.34(2)(l)", + "IV.34(2)(m)", + "IV.34(2)(n)", + "IV.34(2)(n)(i)", + "IV.34(2)(n)(ii)", + "IV.34(2)(n)(iii)", + "IV.34(2)(n)(iv)", + "IV.34(2)(o)", + "IV.34(2)(o)(a)", + "IV.34(2)(o)(b)", + "IV.34(2)(p)", + "IV.34(2)(p)(i)", + "IV.34(2)(p)(ii)", + "IV.34(2)(p)(ii)(aa)", + "IV.34(2)(p)(ii)(bb)", + "IV.34(2)(p)(ii)(cc)", + "IV.34(2)(p)(ii)(dd)", + "IV.34(2)(p)(ii)(ee)", + "IV.34(2)(p)(iii)", + "IV.34(2)(q)", + "IV.34(2)(q)(i)", + "IV.34(2)(q)(ii)", + "IV.34(2)(q)(iii)", + "IV.34(2)(r)", + "IV.34(2)(s)", + "IV.34(4)", + "IV.34(4)(a)", + "IV.34(4)(b)", + "IV.34(5)", + "IV.34(5)(a)", + "IV.34(5)(b)", + "IV.34(5)(c)", + "IV.34(5)(d)", + "IV.34(6)" + ], + "americas-bra-lgpd-2018": [ + "II.I.7.II", + "II.I.7.III", + "II.I.7.V", + "II.I.7.VI", + "II.I.7.VII", + "II.I.7.VIII", + "II.I.7.IX", + "II.I.7.X", + "II.I.7.X.1", + "II.I.7.X.2", + "II.I.7.X.3", + "II.I.7.X.4", + "II.I.7.X.5", + "II.I.7.X.6" + ], + "americas-can-pipeda-2000": [ + "P5-4.5", + "P5-4.5.3" ], "americas-chl-act-19628-1999": [ - "10" + "I.6", + "I.10", + "II.15" ], "americas-col-law-1581-2012": [ - "4", - "5", - "6", - "7" + "II.4(f)", + "III.6", + "III.6(a)", + "III.6(b)", + "III.6(c)", + "III.6(d)", + "III.6(e)", + "III.7" ], "americas-mex-fdpa-2010": [ - "7", - "9" + "II.7", + "II.13", + "V.37", + "V.37.I", + "V.37.II", + "V.37.III", + "V.37.IV", + "V.37.V", + "V.37.VI", + "V.37.VII" ] } }, @@ -202319,7 +207503,7 @@ "title": "Inventory of Personal Data (PD)", "family": "PRI", "description": "Mechanisms exist to establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD).", - "scf_question": "Does the organization establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS)that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD)?", + "scf_question": "Does the organization establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -202334,7 +207518,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -202400,7 +207584,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -202447,9 +207632,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.5.1" ], - "general-scf-dpmp-2025": [ - "1.5" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG2.SP1" ], @@ -202479,8 +207661,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-05(1)" ], - "apac-kor-pipa-2011": [ - "33" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], + "apac-sgp-pdpa-2012": [ + "4.1.13" ] } }, @@ -202502,7 +207688,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically determine if Personal Data (PD) is maintained in electronic form.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -202553,7 +207739,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -202570,9 +207757,6 @@ "general-nist-800-82-r3": [ "PM-05(01)" ], - "general-scf-dpmp-2025": [ - "1.5" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-05(01)" ], @@ -202590,9 +207774,6 @@ ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-05(1)" - ], - "emea-rus-federal-law-27-2006": [ - "16" ] } }, @@ -202616,7 +207797,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to define and implement data handling and protection requirements for specific categories of sensitive Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -202663,7 +207844,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -202690,10 +207872,6 @@ "PT-07(01)", "PT-07(02)" ], - "general-scf-dpmp-2025": [ - "1.2", - "1.7" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)(i)" ], @@ -202716,6 +207894,9 @@ "usa-state-co-privacy-act-2021": [ "6-1-1308(1)(a)(I)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.340.1(a)" + ], "usa-state-or-cpa-2023": [ "Section 5(4)(a)", "Section 5(4)(e)" @@ -202733,29 +207914,37 @@ "Article 13.1(e)", "Article 14.1(d)" ], - "emea-ken-pda-2019": [ - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" + "emea-aut-dpa-2018": [ + "§ 37(4)" ], - "emea-srb-act-9-2018": [ - "9", - "9.1", - "9.2", - "9.3", - "9.4", - "9.5", - "10", - "13" + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 8(2)", + "Title 1, Chapter II, Art. 10(2)", + "Title 2, Chapter II, Art. 31" ], - "apac-aus-privacy-principles-2026": [ - "APP 9" + "emea-deu-fdpa-2017": [ + "2.1.2.26(3)", + "2.1.2.26(4)", + "2.1.2.26(7)", + "3.2.48(1)", + "3.2.51(5)", + "3.4.70(2)", + "3.4.72", + "3.4.72.1", + "3.4.72.2", + "3.4.72.3", + "3.4.72.4", + "3.4.72.5", + "3.4.73" + ], + "emea-rus-152-fz-2025": [ + "Art. 10" ], - "apac-chn-pipl-2021": [ - "51(2)" + "apac-kor-pipa-2011": [ + "III.2.23" + ], + "americas-bhs-dpa-2003": [ + "V.43(4)(b)" ] } }, @@ -202777,7 +207966,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to retain Personal Data (PD) in a format permitting data subject identification for no longer than is necessary for legitimate business purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -202813,7 +208002,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -202842,7 +208032,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide authenticated data subjects the ability to:\n(1) Access their Personal Data (PD) that is being processed, stored and shared, except where the burden, risk or expense of providing access would be disproportionate to the benefit offered to the data subject through granting access;\n(2) Obtain answers on the specifics of how their PD is collected, received, processed, stored, transmitted, shared, updated and/or disposed; \n(3) Obtain the source(s) of their PD; \n(4) Obtain the categories of their PD being collected, received, processed, stored and shared; \n(5) Request correction to their PD due to inaccuracies;\n(6) Request erasure of their PD; and\n(7) Restrict the further collecting, receiving, processing, storing, transmitting, updated and/or sharing of their PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -202903,7 +208093,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -202929,7 +208120,7 @@ ], "general-iso-29100-2024": [ "6.9", - "6.1" + "6.10" ], "general-nist-800-53-r4": [ "IP-2" @@ -202949,9 +208140,6 @@ "general-oecd-privacy-principles-2010": [ "7(a)" ], - "general-scf-dpmp-2025": [ - "6.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)", "Sec. 6502.(b)(1)(B)(iii)" @@ -202996,46 +208184,46 @@ "155.260(a)(3)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(2)(i)", - "164.502(a)(2)(ii)", - "164.514(h)(1)(i)", - "164.514(h)(1)(ii)", - "164.524(a)(1)", - "164.524(a)(1)(i)", - "164.524(a)(1)(ii)", - "164.524(a)(1)(iii)", - "164.524(a)(1)(iii)(A)", - "164.524(a)(1)(iii)(B)", - "164.524(a)(2)", - "164.524(a)(2)(i)", - "164.524(a)(2)(ii)", - "164.524(a)(2)(iii)", - "164.524(a)(2)(iv)", - "164.524(a)(2)(v)", - "164.524(a)(3)", - "164.524(a)(3)(i)", - "164.524(a)(3)(ii)", - "164.524(a)(3)(iii)", - "164.524(a)(4)", - "164.524(b)(1)", - "164.524(b)(2)(i)", - "164.524(b)(2)(i)(A)", - "164.524(b)(2)(i)(B)", - "164.524(b)(2)(ii)", - "164.524(b)(2)(ii)(A)", - "164.524(b)(2)(ii)(B)", - "164.524(c)", - "164.524(c)(1)", - "164.524(c)(3)(i)", - "164.524(c)(3)(ii)", - "164.524(c)(4)", - "164.524(c)(4)(i)", - "164.524(c)(4)(ii)", - "164.524(c)(4)(iii)", - "164.524(c)(4)(iv)", - "164.524(d)", - "164.524(d)(1)", - "164.524(d)(2)" + "§ 164.502(a)(2)(i)", + "§ 164.502(a)(2)(ii)", + "§ 164.514(h)(1)(i)", + "§ 164.514(h)(1)(ii)", + "§ 164.524(a)(1)", + "§ 164.524(a)(1)(i)", + "§ 164.524(a)(1)(ii)", + "§ 164.524(a)(1)(iii)", + "§ 164.524(a)(1)(iii)(A)", + "§ 164.524(a)(1)(iii)(B)", + "§ 164.524(a)(2)", + "§ 164.524(a)(2)(i)", + "§ 164.524(a)(2)(ii)", + "§ 164.524(a)(2)(iii)", + "§ 164.524(a)(2)(iv)", + "§ 164.524(a)(2)(v)", + "§ 164.524(a)(3)", + "§ 164.524(a)(3)(i)", + "§ 164.524(a)(3)(ii)", + "§ 164.524(a)(3)(iii)", + "§ 164.524(a)(4)", + "§ 164.524(b)(1)", + "§ 164.524(b)(2)(i)", + "§ 164.524(b)(2)(i)(A)", + "§ 164.524(b)(2)(i)(B)", + "§ 164.524(b)(2)(ii)", + "§ 164.524(b)(2)(ii)(A)", + "§ 164.524(b)(2)(ii)(B)", + "§ 164.524(c)", + "§ 164.524(c)(1)", + "§ 164.524(c)(3)(i)", + "§ 164.524(c)(3)(ii)", + "§ 164.524(c)(4)", + "§ 164.524(c)(4)(i)", + "§ 164.524(c)(4)(ii)", + "§ 164.524(c)(4)(iii)", + "§ 164.524(c)(4)(iv)", + "§ 164.524(d)", + "§ 164.524(d)(1)", + "§ 164.524(d)(2)" ], "usa-federal-cms-marse-2-0": [ "IP-2", @@ -203068,6 +208256,16 @@ "6-1-1306(1)(b)", "6-1-1306(2)(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.345.2", + "603A.346.2", + "603A.505.1(a)", + "603A.505.1(b)", + "603A.505.2", + "603A.505.2(a)", + "603A.510.3(a)(1)", + "603A.510.3(a)(2)" + ], "usa-state-nv-sb220-2019": [ "2.1", "2.2" @@ -203126,59 +208324,104 @@ "Article 18.1(c)", "Article 18.1(d)" ], - "emea-aut-fappd-2000": [ - "Sec 26" + "emea-aut-dpa-2018": [ + "§ 42(1)", + "§ 42(2)", + "§ 44(1)", + "§ 44(5)" ], - "emea-bel-act-8-1992": [ - "10", - "12" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(2)", + "Title 2, Chapter III, Art. 38(1)", + "Title 2, Chapter III, Art. 38(2)", + "Title 2, Chapter III, Art. 39(1)" ], "emea-deu-fdpa-2017": [ - "Sec 19" + "3.3.57(1)", + "3.3.57(1)2", + "3.3.57(1)3", + "3.3.57(1)4", + "3.3.57(1)5", + "3.3.57(1)6", + "3.3.57(1)7", + "3.3.57(1)8", + "3.3.58(1)", + "3.3.58(2)" ], "emea-grc-pirppd-1997": [ - "11", - "12" - ], - "emea-hun-isdfi-2011": [ - "14", - "15" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "13" - ], - "emea-ita-pdpc-2003": [ - "7" + "C.12.1", + "C.12.2", + "C.12.2.a", + "C.12.2.b", + "C.12.2.c", + "C.12.2.d", + "C.12.2.e", + "C.12.2.f" + ], + "emea-hun-act-cxii-2011": [ + "II.13.14(a)", + "II.13.14(b)", + "II.13.14(c)", + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)" + ], + "emea-irl-dpa-2018": [ + "s.56", + "s.57", + "s.58", + "s.59", + "s.60", + "s.61", + "s.91", + "s.92" + ], + "emea-isr-ppl-5741-2025": [ + "s.13", + "s.14" ], "emea-ken-pda-2019": [ - "26(a)", - "26(b)", - "26(c)", - "26(d)", - "26(e)" + "IV.26(b)", + "IV.27", + "IV.34(1)", + "IV.35(3)(b)(i)", + "IV.35(3)(b)(ii)", + "IV.38(1)", + "IV.38(2)", + "IV.38(3)", + "IV.40(1)", + "IV.40(1)(a)", + "IV.40(1)(b)" ], "emea-nga-dpr-2019": [ - "3.1(1)", - "3.1(3)", - "3.1(3)(a)", - "3.1(3)(b)" - ], - "emea-nor-pda-2018": [ - "18" - ], - "emea-pol-act-29-1997": [ - "32" + "2.8(a)", + "3.1(9)", + "3.1(9)(a)", + "3.1(9)(b)", + "3.1(9)(c)", + "3.1(9)(d)", + "3.1(9)(e)", + "3.1(11)", + "3.1(11)(a)", + "3.1(11)(b)", + "3.1(11)(c)", + "3.1(11)(d)", + "3.1(15)" ], "emea-qat-pdppl-2020": [ - "6", - "21.1", - "21.2" + "2.5.1", + "2.5.2", + "2.5.3", + "2.5.4", + "2.6", + "2.6.1", + "2.6.2", + "3.11.6" ], - "emea-rus-federal-law-27-2006": [ - "14" + "emea-rus-152-fz-2025": [ + "Art. 14", + "Art. 15", + "Art. 20" ], "emea-sau-pdpl-2023": [ "Article 4.2", @@ -203188,131 +208431,258 @@ "Article 21" ], "emea-srb-act-9-2018": [ - "21", - "23", - "24", - "25", - "26", - "28.1", - "28.2", - "28.3", - "28.4", - "28.5" + "III.2.26", + "III.2.26(1)", + "III.2.26(2)", + "III.2.26(3)", + "III.2.26(4)", + "III.2.26(5)", + "III.2.26(6)", + "III.2.26(7)", + "III.2.26(8)", + "III.2.27", + "III.2.27(1)", + "III.2.27(2)", + "III.2.27(3)", + "III.2.27(4)", + "III.2.27(5)", + "III.2.27(6)", + "III.2.27(7)" ], "emea-zaf-popia-2013": [ - "23" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "27", - "28", - "29" + "3.A.8.23(1)", + "3.A.8.23(1)(a)", + "3.A.8.23(1)(b)", + "3.A.8.23(1)(b)(i)", + "3.A.8.23(1)(b)(ii)", + "3.A.8.23(1)(b)(iii)", + "3.A.8.23(1)(b)(iv)", + "3.A.8.23(2)", + "3.A.8.23(3)", + "3.A.8.23(3)(a)", + "3.A.8.23(3)(b)" ], "emea-che-fadp-2025": [ - "8" + "3.21.2", + "4.25.1", + "4.25.2", + "4.25.2.a", + "4.25.2.b", + "4.25.2.c", + "4.25.2.d", + "4.25.2.e", + "4.25.2.f", + "4.25.2.g", + "4.25.3", + "4.25.4", + "4.25.5", + "4.28.1", + "4.28.1.a", + "4.28.1.b", + "4.28.2" ], "emea-tur-lppd-2016": [ - "11" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 12" + "13(1)", + "13(2)", + "13(3)" + ], + "emea-gbr-dpa-2018": [ + "Section 45(1)", + "Section 45(1)(a)", + "Section 45(1)(b)", + "Section 45(2)", + "Section 45(2)(a)", + "Section 45(2)(b)", + "Section 45(2)(c)", + "Section 45(2)(d)", + "Section 45(2)(e)", + "Section 45(2)(e)(i)", + "Section 45(2)(e)(ii)", + "Section 45(2)(f)", + "Section 45(2)(g)", + "Section 45(2A)" ], "apac-aus-privacy-principles-2026": [ - "APP 12" + "3.7.6", + "3.7.6.a", + "3.7.6.b", + "3.7.6.c", + "3.7.6.d", + "3.7.6.e", + "3.7.7", + "3.7.7.a", + "3.7.7.b", + "5.12.1" + ], + "apac-chn-csnip-2012": [ + "VIII" ], "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "Article 44", + "Article 48" ], "apac-hkg-pdo-2022": [ - "Principle 6", - "Sec 17A", - "Sec 18" + "18(1)", + "18(1)(a)", + "18(1)(b)", + "18(2)", + "18(3)", + "18(4)", + "18(4)(a)", + "18(4)(b)", + "35G(3)", + "Schedule 1 - 6", + "Schedule 1 - 6(a)", + "Schedule 1 - 6(b)", + "Schedule 1 - 6(b)(i)", + "Schedule 1 - 6(b)(ii)", + "Schedule 1 - 6(b)(iii)", + "Schedule 1 - 6(b)(iv)", + "Schedule 1 - 6(c)", + "Schedule 1 - 6(d)", + "Schedule 1 - 6(e)", + "Schedule 1 - 6(f)", + "Schedule 1 - 6(g)" ], "apac-ind-dpdpa-2023": [ "11(1)(c)", "11(2)" ], - "apac-jpn-ppi-2020": [ - "27(1)", - "27(1)(i)", - "27(1)(ii)", - "27(1)(iii)", - "27(1)(iv)", - "27(2)(i)", - "27(2)(ii)", - "27(3)", - "28(1)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)" + "apac-jpn-appi-2020": [ + "IV.1.28(1)" ], "apac-mys-pdpa-2010": [ "12", - "30" + "30(1)", + "30(2)(a)", + "30(2)(b)", + "34(1)(a)", + "34(1)(b)", + "34(2)" ], "apac-nzl-privacy-act-2020": [ - "Principle 6", - "P6-(1)", - "P6-(1)(a)", - "P6-(1)(b)", - "P6-(2)", - "P6-(3)" + "3.1.22.6(1)", + "3.1.22.6(1)(a)", + "3.1.22.6(1)(b)", + "3.1.22.6(2)", + "3.1.22.7(1)", + "3.1.22.7(3)", + "3.1.22.7(3)(a)", + "4.2.59" ], "apac-phl-dpa-2012": [ - "34" + "IV.16", + "IV.16(a)", + "IV.16(b)", + "IV.16(b)(1)", + "IV.16(b)(2)", + "IV.16(b)(3)", + "IV.16(b)(4)", + "IV.16(b)(5)", + "IV.16(b)(6)", + "IV.16(b)(7)", + "IV.16(b)(8)", + "IV.16(c)", + "IV.16(c)(1)", + "IV.16(c)(2)", + "IV.16(c)(3)", + "IV.16(c)(4)", + "IV.16(c)(5)", + "IV.16(c)(6)", + "IV.16(c)(7)", + "IV.16(c)(8)", + "IV.16(d)", + "IV.16(e)", + "IV.16(f)" ], "apac-sgp-pdpa-2012": [ - "21" + "4.1.16(3)", + "5.21(1)", + "5.21(1)(a)", + "5.21(1)(b)", + "5.21(2)", + "5.21(5)" ], "apac-kor-pipa-2011": [ - "4", - "35" + "V.35(1)", + "V.35(2)", + "V.35(3)", + "V.36(1)" ], "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "4.6", - "13", - "14.1", - "14.2", - "14.3", - "14.4" + "I.3", + "I.3.1", + "I.3.2", + "I.3.3", + "I.3.4", + "I.3.5" ], "americas-bhs-dpa-2003": [ - "8" + "IV.27(1)", + "IV.29(1)", + "IV.29(1)(a)", + "IV.29(1)(b)", + "IV.29(1)(c)", + "IV.29(1)(d)", + "IV.29(1)(e)", + "IV.29(1)(f)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(2)", + "IV.30(2)(a)", + "IV.30(2)(b)", + "IV.30(3)" ], "americas-bra-lgpd-2018": [ - "6.4", - "9", - "17", - "18.1", - "18.2", - "20" + "III.18", + "III.18.I", + "III.18.II", + "III.18.III", + "III.18.IV", + "III.18.V", + "III.18.VI", + "III.18.VII", + "III.18.VIII", + "III.18.IX", + "III.18.IX.1", + "III.18.IX.2", + "III.18.IX.3", + "III.18.IX.4" ], "americas-can-pipeda-2000": [ - "Principle 8", - "Principle 9" + "P9-4.9", + "P10-4.10" ], "americas-chl-act-19628-1999": [ - "12" + "II.12", + "II.13", + "II.14" ], "americas-col-law-1581-2012": [ - "8", - "11" + "II.4(e)", + "IV.8(a)", + "IV.8(b)", + "IV.8(c)", + "IV.8(f)", + "IV.11", + "V.14", + "V.15", + "V.15.1" ], "americas-mex-fdpa-2010": [ - "15", - "22", - "23", - "25" + "II.16.III", + "III.22", + "III.23", + "III.25", + "III.27", + "IV.28", + "IV.29", + "IV.29.I", + "IV.29.II", + "IV.29.III", + "IV.29.IV", + "IV.31" ] } }, @@ -203334,7 +208704,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process for:\n(1) Data subjects to have inaccurate Personal Data (PD) maintained by the organization corrected or amended; and\n(2) Disseminating corrections or amendments of PD to other authorized users of the PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -203406,7 +208776,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -203439,9 +208810,6 @@ "SI-18(04)", "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "6.3" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.6.a" ], @@ -203465,13 +208833,13 @@ "1" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(a)(2)", - "164.526(a)(2)(i)", - "164.526(a)(2)(ii)", - "164.526(a)(2)(iii)", - "164.526(a)(2)(iv)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(a)(2)", + "§ 164.526(a)(2)(i)", + "§ 164.526(a)(2)(ii)", + "§ 164.526(a)(2)(iii)", + "§ 164.526(a)(2)(iv)", + "§ 164.526(b)(1)" ], "usa-federal-cms-marse-2-0": [ "IP-3", @@ -203501,152 +208869,123 @@ "usa-state-va-cdpa-2023": [ "59.1-577.A.2" ], - "emea-aut-fappd-2000": [ - "Sec 27" - ], - "emea-bel-act-8-1992": [ - "10", - "12" + "emea-aut-dpa-2018": [ + "§ 45(1)" ], "emea-deu-fdpa-2017": [ - "Sec 20" + "3.3.57(1)6", + "3.3.58(1)", + "3.4.75(1)" ], "emea-grc-pirppd-1997": [ - "13" + "B.4.1.c", + "C.12.2.e" ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" + "emea-hun-act-cxii-2011": [ + "II.13.17(1)" ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "14" - ], - "emea-ita-pdpc-2003": [ - "7" + "emea-isr-ppl-5741-2025": [ + "s.14" ], "emea-ken-pda-2019": [ - "25(f)", - "26(d)", - "40(1)(a)", - "40(2)(a)" - ], - "emea-nor-pda-2018": [ - "27" - ], - "emea-pol-act-29-1997": [ - "32" + "IV.25(f)", + "IV.26(d)", + "IV.34(1)(a)", + "IV.40(1)(a)" ], "emea-qat-pdppl-2020": [ - "5.4", - "6.2" - ], - "emea-rus-federal-law-27-2006": [ - "17" + "2.5.4" ], "emea-srb-act-9-2018": [ - "5.4", - "11", - "29" + "III.3.29" ], "emea-zaf-popia-2013": [ - "24" + "3.A.8.24(1)", + "3.A.8.24(1)(a)", + "3.A.8.24(1)(b)" ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" - ], - "emea-che-fadp-2025": [ - "5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "emea-gbr-dpa-2018": [ + "Section 46(1)", + "Section 46(2)", + "Section 46(3)", + "Section 46(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 13" + "5.13.1", + "5.13.1.a", + "5.13.1.b", + "5.13.1.b.i" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], - "apac-chn-csnip-2012": [ - "8" - ], "apac-chn-pipl-2021": [ - "46", - "49" + "Article 46" ], "apac-hkg-pdo-2022": [ - "Sec 22" + "22(1)(a)", + "22(1)(b)", + "22(1A)", + "22(2)", + "22(2)(a)", + "22(2)(b)", + "22(3)", + "22(4)", + "23(1)", + "23(1)(a)", + "23(1)(c)(i)", + "23(1)(c)(ii)", + "23(2)", + "23(2)(a)", + "23(2)(a)(i)", + "23(2)(a)(ii)", + "23(2)(b)", + "23(3)", + "23(3)(a)", + "23(3)(b)" ], "apac-ind-dpdpa-2023": [ "12(1)", "12(2)(a)", "12(2)(b)" ], - "apac-jpn-ppi-2020": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" + "apac-jpn-appi-2020": [ + "IV.1.29(1)", + "IV.1.29(2)" ], "apac-mys-pdpa-2010": [ - "34" - ], - "apac-nzl-privacy-act-2020": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" - ], - "apac-phl-dpa-2012": [ - "34" + "35(1)", + "35(1)(a)", + "35(1)(b)", + "35(1)(c)", + "35(1)(c)(i)", + "35(1)(c)(ii)", + "35(2)", + "35(2)(a)", + "35(2)(b)", + "35(3)", + "35(4)", + "35(4)(a)", + "35(4)(b)", + "35(5)", + "35(5)(a)", + "35(5)(b)" ], "apac-sgp-pdpa-2012": [ - "22" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "16.1", - "16.3" + "5.22(1)", + "5.22(2)(a)", + "5.22(4)" ], "americas-bhs-dpa-2003": [ - "10" - ], - "americas-bra-lgpd-2018": [ - "18.3" + "IV.26(1)", + "IV.26(2)" ], "americas-can-pipeda-2000": [ - "Principle 10" - ], - "americas-chl-act-19628-1999": [ - "13" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "P9-4.9.5" ], "americas-mex-fdpa-2010": [ - "24", - "28", - "29" + "III.24", + "IV.28" ] } }, @@ -203668,7 +209007,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify affected data subjects if their Personal Data (PD) has been corrected, amended or deleted.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -203727,7 +209066,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -203750,9 +209090,6 @@ "general-nist-800-82-r3": [ "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "6.4" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-18(05)" ], @@ -203766,12 +209103,12 @@ "SI-18(05)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(c)", - "164.526(c)(1)", - "164.526(c)(2)", - "164.526(c)(3)", - "164.526(c)(3)(i)", - "164.526(c)(3)(ii)" + "§ 164.526(c)", + "§ 164.526(c)(1)", + "§ 164.526(c)(2)", + "§ 164.526(c)(3)", + "§ 164.526(c)(3)(i)", + "§ 164.526(c)(3)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7022(e)", @@ -203780,93 +209117,89 @@ "usa-state-tn-tipa-2025": [ "47-18-3203(b)(1)" ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17", - "18" - ], - "emea-irl-dpa-2003": [ - "2" + "emea-aut-dpa-2018": [ + "§ 45(5)" ], - "emea-ita-pdpc-2003": [ - "10" - ], - "emea-nga-dpr-2019": [ - "3.1(13)" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 39(5)", + "Title 2, Chapter III, Art. 39(6)" ], - "emea-pol-act-29-1997": [ - "32" - ], - "emea-qat-pdppl-2020": [ - "6.2" - ], - "emea-rus-federal-law-27-2006": [ - "18" - ], - "emea-srb-act-9-2018": [ - "34", - "34.1", - "34.2", - "34.3", - "34.4", - "34.5" + "emea-deu-fdpa-2017": [ + "3.3.58(1)", + "3.3.58(5)", + "3.4.75(3)" ], "emea-zaf-popia-2013": [ - "24" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "3.A.8.24(3)", + "3.A.8.24(4)" + ], + "emea-gbr-dpa-2018": [ + "Section 48(1)", + "Section 48(1)(a)", + "Section 48(1)(b)", + "Section 48(1)(b)(i)", + "Section 48(1)(b)(ii)", + "Section 48(1)(b)(iii)", + "Section 48(1)(b)(iv)", + "Section 48(2)", + "Section 48(2)(a)", + "Section 48(2)(b)", + "Section 48(3)", + "Section 48(3)(a)", + "Section 48(3)(b)", + "Section 48(3)(c)", + "Section 48(3)(e)", + "Section 48(4)", + "Section 48(4)(a)", + "Section 48(4)(b)", + "Section 48(4)(c)", + "Section 48(4)(d)", + "Section 48(5)", + "Section 48(6)", + "Section 48(6)(a)", + "Section 48(6)(b)", + "Section 48(7)", + "Section 48(9)", + "Section 48(9)(a)", + "Section 48(9)(b)", + "Section 48(10)" ], "apac-aus-privacy-principles-2026": [ - "APP 13" + "5.13.2", + "5.13.2.a", + "5.13.2.b", + "5.13.3", + "5.13.3.a", + "5.13.3.b", + "5.13.3.c" ], - "apac-chn-pipl-2021": [ - "22", - "46", - "49" + "apac-hkg-pdo-2022": [ + "19(3)(b)", + "19(3)(c)", + "19(3)(c)(i)", + "19(3)(c)(i)(A)", + "19(3)(c)(i)(B)", + "19(3)(c)(ii)", + "19(3)(c)(iii)", + "19(3)(c)(iii)(A)", + "19(3)(c)(iii)(B)", + "19(3)(c)(I)", + "19(3)(c)(II)", + "19(3)(c)(iv)", + "19(3)(c)(v)", + "23(1)(b)" ], - "apac-jpn-ppi-2020": [ - "18(3)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)", - "29(1)", - "29(2)", - "29(3)" + "apac-mys-pdpa-2010": [ + "37(1)", + "37(1)(a)", + "37(1)(b)" ], "apac-nzl-privacy-act-2020": [ - "P6-(2)" - ], - "apac-phl-dpa-2012": [ - "34" - ], - "apac-sgp-pdpa-2012": [ - "23" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "americas-arg-ppd-2018": [ - "16.2" + "3.1.22.7(3)(b)" ], "americas-bhs-dpa-2003": [ - "11" - ], - "americas-bra-lgpd-2018": [ - "18.9" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "IV.26(3)(a)", + "IV.26(3)(b)" ] } }, @@ -203888,7 +209221,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process for data subjects to appeal an adverse decision.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -203950,7 +209283,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -203984,9 +209318,6 @@ "general-nist-800-161-r1-level-3": [ "PM-26" ], - "general-scf-dpmp-2025": [ - "6.5" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-26" ], @@ -204003,7 +209334,7 @@ "155.260(a)(3)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(d)(4)" + "§ 164.524(d)(4)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(d)(1)", @@ -204012,6 +209343,15 @@ "usa-state-co-privacy-act-2021": [ "6-1-1306(3)(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.520.1", + "603A.520.1(a)", + "603A.520.1(b)", + "603A.520.2", + "603A.520.2(a)", + "603A.520.2(b)", + "603A.520.2(c)" + ], "usa-state-or-ors-646a-2025": [ "646A.576(6)", "646A.576(6)(a)", @@ -204031,58 +209371,17 @@ "usa-state-va-cdpa-2023": [ "59.1-577.C" ], - "emea-aut-fappd-2000": [ - "Sec 28" - ], - "emea-grc-pirppd-1997": [ - "13" - ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17", - "18" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-rus-federal-law-27-2006": [ - "17" - ], - "emea-zaf-popia-2013": [ - "63", - "74" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24" - ], - "apac-jpn-ppi-2020": [ - "31" - ], - "apac-phl-dpa-2012": [ - "34" - ], - "apac-kor-pipa-2011": [ - "38" - ], - "americas-bra-lgpd-2018": [ - "18.9" - ], - "americas-can-pipeda-2000": [ - "Sec 11" - ], - "americas-col-law-1581-2012": [ - "15" + "emea-rus-152-fz-2025": [ + "Art. 17" ] } }, { "control_id": "PRI-06.4", - "title": "User Feedback Management", + "title": "Data Subject Feedback Management", "family": "PRI", - "description": "Mechanisms exist to maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", - "scf_question": "Does the organization maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes?", + "description": "Mechanisms exist to maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", + "scf_question": "Does the organization maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes?", "relative_weight": 5, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -204095,9 +209394,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -204154,8 +209453,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -204182,7 +209483,7 @@ "P8.1-POF3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.MT-P7", @@ -204227,9 +209528,6 @@ "7(c)", "7(d)" ], - "general-scf-dpmp-2025": [ - "6.1" - ], "general-tisax-6-0-3": [ "9.6.1" ], @@ -204254,28 +209552,28 @@ "6" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(b)(2)(i)", - "164.526(b)(2)(i)(A)", - "164.526(b)(2)(i)(B)", - "164.526(b)(2)(ii)", - "164.526(b)(2)(ii)(A)", - "164.526(b)(2)(ii)(B)", - "164.526(d)", - "164.526(d)(1)", - "164.526(d)(1)(i)", - "164.526(d)(1)(ii)", - "164.526(d)(1)(iii)", - "164.526(d)(1)(iv)", - "164.526(d)(2)", - "164.526(d)(3)", - "164.526(d)(4)", - "164.526(d)(5)(i)", - "164.526(d)(5)(ii)", - "164.526(d)(5)(iii)", - "164.526(e)", - "164.526(f)", - "164.530(d)(1)", - "164.530(d)(2)" + "§ 164.526(b)(2)(i)", + "§ 164.526(b)(2)(i)(A)", + "§ 164.526(b)(2)(i)(B)", + "§ 164.526(b)(2)(ii)", + "§ 164.526(b)(2)(ii)(A)", + "§ 164.526(b)(2)(ii)(B)", + "§ 164.526(d)", + "§ 164.526(d)(1)", + "§ 164.526(d)(1)(i)", + "§ 164.526(d)(1)(ii)", + "§ 164.526(d)(1)(iii)", + "§ 164.526(d)(1)(iv)", + "§ 164.526(d)(2)", + "§ 164.526(d)(3)", + "§ 164.526(d)(4)", + "§ 164.526(d)(5)(i)", + "§ 164.526(d)(5)(ii)", + "§ 164.526(d)(5)(iii)", + "§ 164.526(e)", + "§ 164.526(f)", + "§ 164.530(d)(1)", + "§ 164.530(d)(2)" ], "usa-federal-cms-marse-2-0": [ "IP-4", @@ -204327,6 +209625,16 @@ "6-1-1306(3)(b)", "6-1-1306(3)(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.345.3", + "603A.345.4", + "603A.346.3", + "603A.346.4", + "603A.510.1", + "603A.510.2", + "603A.510.2(a)", + "603A.510.2(b)" + ], "usa-state-nv-sb220-2019": [ "2.4" ], @@ -204391,119 +209699,299 @@ "emea-eu-gdpr-2016": [ "Article 12.4" ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" + "emea-aut-dpa-2018": [ + "§ 42(3)", + "§ 42(4)", + "§ 42(5)", + "§ 42(6)", + "§ 45(8)", + "§ 45(9)", + "§ 44(3)", + "§ 44(4)", + "§ 45(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(3)", + "Title 2, Chapter III, Art. 38(3)", + "Title 2, Chapter III, Art. 39(4)", + "Title 2, Chapter III, Art. 40" ], - "emea-ita-pdpc-2003": [ - "9" + "emea-deu-fdpa-2017": [ + "2.2.34(2)", + "2.2.35(2)", + "3.3.57(6)", + "3.3.59(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)", + "II.13.16(2)", + "II.13.18(2)", + "II.15.21(2)", + "II.15.21(3)" + ], + "emea-irl-dpa-2018": [ + "s.93" ], "emea-ken-pda-2019": [ - "40(1)(b)" + "IV.35(4)(a)", + "IV.35(4)(b)", + "IV.35(4)(c)", + "IV.35(4)(c)(i)", + "IV.35(4)(c)(ii)", + "IV.38(4)" ], "emea-nga-dpr-2019": [ - "2.8", - "2.8(a)", - "2.8(b)", "3.1(2)", - "3.1(4)", + "3.1(3)(b)", "3.1(5)", - "3.1(11)(a)", - "3.1(11)(b)", - "3.1(11)(c)", - "3.1(11)(d)", "3.1(13)" ], "emea-qat-pdppl-2020": [ - "5.3", - "5.4", - "6.3" + "3.11.4" + ], + "emea-rus-152-fz-2025": [ + "Art. 21" ], "emea-srb-act-9-2018": [ - "21", - "21.1", - "21.2", - "22", - "22.1", - "22.2", - "23", - "23.x", - "24", - "24.x", - "25", - "25.x", - "26", - "26.1", - "26.2", - "26.3", - "26.4", - "26.5", - "26.6", - "26.7", - "26.8", - "27.1", - "27.2", - "27.3", - "27.4", - "27.5", - "27.6", - "27.7" - ], - "emea-esp-decree-1720-2007": [ - "26" + "III.1.22", + "III.3.34" ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "emea-zaf-popia-2013": [ + "3.A.8.23(4)(a)", + "3.A.8.23(4)(b)", + "3.A.8.23(5)", + "3.A.8.24(2)", + "3.A.8.24(2)(a)", + "3.A.8.24(2)(b)", + "3.A.8.24(2)(c)", + "3.A.8.24(2)(d)" + ], + "emea-che-fadp-2025": [ + "4.25.7", + "4.28.3" + ], + "emea-gbr-dpa-2018": [ + "Section 45(3)", + "Section 45(3)(a)", + "Section 45(3)(b)", + "Section 45(5)", + "Section 45(5)(a)", + "Section 45(5)(b)", + "Section 45(5)(c)", + "Section 45(5)(d)", + "Section 45(5)(e)", + "Section 52(6)", + "Section 53(6)", + "Section 53(6)(a)", + "Section 53(6)(b)", + "Section 53(7)", + "Section 53(7)(a)", + "Section 53(7)(b)" ], "apac-aus-privacy-principles-2026": [ - "APP 12", - "APP 13" + "5.12.3", + "5.12.3.a", + "5.12.3.b", + "5.12.3.c", + "5.12.3.d", + "5.12.3.e", + "5.12.3.f", + "5.12.3.g", + "5.12.3.h", + "5.12.3.h.ii", + "5.12.3.i", + "5.12.3.j", + "5.12.4", + "5.12.4.a", + "5.12.4.a.i", + "5.12.4.a.ii", + "5.12.4.b", + "5.12.5", + "5.12.5.a", + "5.12.5.b", + "5.12.6", + "5.13.4", + "5.13.4.a", + "5.13.5", + "5.13.5.a", + "5.13.5.a.i", + "5.13.5.a.ii", + "5.13.5.b" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], "apac-chn-pipl-2021": [ - "45", - "46", - "50" + "Article 50" ], - "apac-jpn-ppi-2020": [ - "27(3)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)", - "31", + "apac-hkg-pdo-2022": [ + "18(5)", + "18(5)(a)", + "18(5)(b)", + "19(1)", + "19(1)(a)", + "19(1)(a)(i)", + "19(1)(a)(ii)", + "19(1)(b)", + "19(3)", + "19(3)(a)", + "19(3)(a)(i)", + "19(3)(a)(i)(A)", + "19(3)(a)(i)(B)", + "19(3)(a)(ii)", + "19(4)", + "19(4)(a)", + "19(4)(b)", + "19(4)(b)(i)", + "19(4)(b)(ii)", + "19(4)(b)(ii)(A)", + "19(4)(b)(I)", + "19(4)(b)(II)", + "19(4)(b)(III)", + "19(4)(b)(III)(B)", + "21(1)", + "21(1)(a)", + "21(1)(b)", + "21(1)(c)", + "25(1)", + "25(1)(b)" + ], + "apac-ind-privacy-rules-2011": [ + "5(9)" + ], + "apac-jpn-appi-2020": [ + "IV.1.27(2)", + "IV.1.27(2)(i)", + "IV.1.27(2)(ii)", + "IV.1.27(3)", + "IV.1.28(2)", + "IV.1.28(3)", + "IV.1.35(1)", + "IV.1.35(2)" + ], + "apac-mys-pdpa-2010": [ + "30(3)", + "30(4)", + "30(5)", + "31(1)", + "31(2)", + "31(2)(a)", + "31(2)(b)", + "31(3)", "32(1)", + "32(1)(a)", + "32(1)(b)", + "32(1)(c)", "32(2)", + "32(2)(a)", + "32(2)(b)", + "32(2)(c)", + "32(2)(d)", "32(3)", - "32(4)" + "33", + "33(a)", + "33(b)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.7(2)", + "4.1.44(1)", + "4.1.44(2)", + "4.1.44(2)(b)", + "4.1.44(2)(c)", + "4.1.44(2)(c)(i)", + "4.1.44(2)(c)(ii)", + "4.1.44(2)(d)", + "4.2.63(1)", + "4.2.63(1)(a)", + "4.2.63(1)(b)", + "4.2.63(1)(b)(i)", + "4.2.63(1)(b)(ii)", + "4.2.63(2)", + "4.2.63(3)", + "4.2.63(3)(a)", + "4.2.63(3)(b)", + "4.2.63(3)(c)", + "4.2.64(1)", + "4.2.64(1)(a)", + "4.2.64(1)(b)", + "4.2.64(1)(b)(i)", + "4.2.64(1)(b)(ii)", + "4.2.64(2)", + "4.2.64(3)" + ], + "apac-sgp-pdpa-2012": [ + "3.12(b)", + "4.1.16(2)", + "5.21(6)", + "5.21(6)(b)", + "5.21(7)", + "5.21(7)(b)" ], "apac-kor-pipa-2011": [ - "37" + "V.36(2)", + "V.36(3)", + "V.36(4)", + "V.36(5)", + "V.37(2)", + "V.37(2)1", + "V.37(2)2", + "V.37(2)3", + "V.37(2)4", + "V.37(3)", + "V.37(4)" ], - "americas-arg-ppd-2018": [ - "16.2", - "16.6" + "apac-twn-pdpa-2025": [ + "I.10", + "I.10.1", + "I.10.2", + "I.10.3" ], "americas-bhs-dpa-2003": [ - "11" + "IV.24(4)", + "IV.24(4)(a)", + "IV.24(4)(b)", + "IV.24(5)", + "IV.24(5)(a)", + "IV.24(5)(b)", + "IV.24(10)", + "IV.24(10)(a)", + "IV.24(10)(b)", + "IV.24(10)(c)", + "IV.24(10)(d)", + "IV.24(13)(f)", + "IV.27(3)", + "IV.28(5)(a)", + "IV.28(5)(b)", + "IV.29(3)(a)", + "IV.29(3)(b)" ], "americas-bra-lgpd-2018": [ - "18", - "19", - "21" + "III.18.IX.4.I", + "III.18.IX.4.II", + "III.18.IX.5" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(b)", + "P9-4.9.1", + "P9-4.9.4", + "P10-4.10.2", + "P10-4.10.3", + "P10-4.10.4" ], "americas-col-law-1581-2012": [ - "12", - "15" + "IV.12(a)", + "IV.12(b)", + "IV.12(c)", + "IV.12(d)", + "V.15.2", + "V.15.3", + "VI.17(j)" ], "americas-mex-fdpa-2010": [ - "30" + "IV.32", + "IV.33" ] } }, @@ -204525,7 +210013,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to erase a data subject's Personal Data (PD), in accordance with applicable laws, regulations and contractual obligations pertaining to the retention of their PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -204584,16 +210072,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ "P4.3-POF1" ], - "general-scf-dpmp-2025": [ - "6.6" - ], "usa-state-ca-ccpa-cpra-2026": [ "7022(b)(1)", "7022(f)(2)" @@ -204601,6 +210087,14 @@ "usa-state-co-privacy-act-2021": [ "6-1-1306(1)(d)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.505.1(d)", + "603A.515.1", + "603A.515.1(a)", + "603A.515.1(b)", + "603A.515.2", + "603A.515.3" + ], "usa-state-or-ors-646a-2025": [ "646A.574(1)(c)" ], @@ -204634,66 +210128,64 @@ "Article 17.3(d)", "Article 17.3(e)" ], + "emea-aut-dpa-2018": [ + "§ 45(2)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 39(2)" + ], + "emea-deu-fdpa-2017": [ + "2.2.35(1)", + "3.3.58(2)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.e" + ], "emea-ken-pda-2019": [ - "26(e)", - "40(1)(b)", - "40(2)(b)", - "40(3)" + "IV.26(e)", + "IV.40(1)(b)", + "IV.40(3)" ], "emea-nga-dpr-2019": [ - "3.1(13)" + "3.1(9)(e)" ], "emea-qat-pdppl-2020": [ - "5.3" + "2.5.3" ], "emea-srb-act-9-2018": [ - "30", - "30.x", - "32", - "32.1", - "32.2" + "III.3.30-1", + "III.3.32" + ], + "emea-gbr-dpa-2018": [ + "Section 47(1)", + "Section 47(1)(a)", + "Section 47(1)(b)" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], - "apac-chn-pipl-2021": [ - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)", - "49" + "apac-chn-csnip-2012": [ + "VIII" ], "apac-ind-dpdpa-2023": [ "8(7)(a)", "12(1)", "12(3)" ], - "apac-jpn-ppi-2020": [ - "30(1)", - "30(2)", - "30(3)", - "30(4)", - "30(5)", - "30(6)", - "30(7)", - "33(1)", - "33(2)", - "34", - "34(1)", - "34(2)", - "34(3)", - "35(1)", - "35(2)" - ], - "americas-arg-ppd-2018": [ - "16.5", - "16.7" - ], - "americas-bra-lgpd-2018": [ - "18.4", - "18.6" + "americas-bhs-dpa-2003": [ + "IV.28(1)", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(c)", + "IV.28(2)(d)", + "IV.28(2)(e)", + "IV.28(4)", + "IV.28(4)(a)", + "IV.28(4)(b)", + "IV.28(4)(c)", + "IV.28(4)(d)", + "IV.28(4)(e)" ] } }, @@ -204715,7 +210207,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to format exports of Personal Data (PD) in a structured, machine-readable format that allows data subjects to transfer their PD to another controller without hindrance.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -204758,7 +210250,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -204769,12 +210262,9 @@ "ID.DE-P4", "CT.DM-P6" ], - "general-scf-dpmp-2025": [ - "5.7" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(c)(2)(i)", - "164.524(c)(2)(ii)" + "§ 164.524(c)(2)(i)", + "§ 164.524(c)(2)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7024(g)" @@ -204798,44 +210288,32 @@ "Article 20.1" ], "emea-ken-pda-2019": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IV.38(1)", + "IV.38(2)", + "IV.38(3)" ], "emea-nga-dpr-2019": [ - "3.1(6)", "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)", "3.1(15)" ], - "emea-qat-pdppl-2020": [ - "6.3" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], "emea-srb-act-9-2018": [ - "21", - "22", - "36", - "36.1", - "36.2" + "III.3.36" ], - "americas-arg-ppd-2018": [ - "15.1", - "15.2", - "15.3" + "apac-chn-pipl-2021": [ + "Article 45" + ], + "apac-phl-dpa-2012": [ + "IV.18" ], "americas-bra-lgpd-2018": [ - "18.5", - "40" + "III.18.IX.7", + "III.19", + "III.19.II", + "III.19.II.1", + "III.19.II.2", + "III.19.II.2.I", + "III.19.II.2.II", + "III.19.II.3" ] } }, @@ -204844,7 +210322,7 @@ "title": "Personal Data (PD) Exports", "family": "PRI", "description": "Mechanisms exist to export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request.", - "scf_question": "Does the organization process an export of a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request?", + "scf_question": "Does the organization export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -204857,7 +210335,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -204898,7 +210376,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -204924,9 +210403,6 @@ "7(b)", "7(b)(iv)" ], - "general-scf-dpmp-2025": [ - "5.7" - ], "usa-state-ca-ccpa-cpra-2026": [ "7024(g)" ], @@ -204954,34 +210430,32 @@ "Article 20.1(b)" ], "emea-ken-pda-2019": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IV.38(1)", + "IV.38(2)" ], "emea-nga-dpr-2019": [ - "3.1(6)", - "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)" + "3.1(14)" ], - "emea-qat-pdppl-2020": [ - "6.3" - ], - "emea-srb-act-9-2018": [ - "21", - "22" - ], - "apac-chn-pipl-2021": [ - "45" + "emea-gbr-dpa-2018": [ + "Section 52(1)", + "Section 52(2)", + "Section 52(3)", + "Section 52(5)" ], "apac-ind-dpdpa-2023": [ "11(1)(a)" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.58(1)", + "4.1.58(1)(a)", + "4.1.58(1)(b)", + "4.1.58(1)(c)", + "4.1.58(1)(d)", + "4.1.58(1)(e)", + "4.1.58(1)(f)" + ], + "americas-bra-lgpd-2018": [ + "III.19.I" ] } }, @@ -205003,7 +210477,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to utilize reasonable consumer expectations to verify a data subject's identity, prior to taking action to disclose, share, correct, amend and/or delete Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -205044,16 +210518,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ "A5.1-POF1" ], - "general-scf-dpmp-2025": [ - "6.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7060(a)", "7060(b)", @@ -205085,8 +210557,43 @@ "6-1-1306(1)", "6-1-1306(2)(d)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.505.2(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.576(2)" + ], + "emea-deu-fdpa-2017": [ + "3.3.57(3)", + "3.3.59(4)" + ], + "emea-nga-dpr-2019": [ + "3.1(5)" + ], + "emea-qat-pdppl-2020": [ + "4.17.3" + ], + "emea-gbr-dpa-2018": [ + "Section 52(4)", + "Section 52(4)(a)", + "Section 52(4)(b)" + ], + "apac-aus-privacy-principles-2026": [ + "1.2.2.a", + "1.2.2.b" + ], + "apac-mys-pdpa-2010": [ + "32(1)(a)(i)", + "32(1)(a)(ii)", + "32(1)(a)(ii)(A)", + "32(1)(a)(ii)(B)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.2" + ], + "americas-col-law-1581-2012": [ + "IV.9", + "IV.12" ] } }, @@ -205111,9 +210618,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to disclose Personal Data (PD) to third-parties only for the purposes identified in the data privacy notice and with the implicit or explicit consent of the data subject.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to disclose Personal Data (PD) to third-parties only for the purposes identified in the data privacy notice and with the implicit or explicit consent of the data subject. ", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -205170,7 +210677,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -205206,7 +210714,7 @@ "5.33" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "CT.PO-P2" @@ -205241,9 +210749,6 @@ "general-nist-800-161-r1-level-2": [ "AC-21" ], - "general-scf-dpmp-2025": [ - "10.2" - ], "general-tisax-6-0-3": [ "9.5.2" ], @@ -205266,12 +210771,12 @@ "155.260(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.506(c)(1)", - "164.506(c)(2)", - "164.506(c)(3)", - "164.506(c)(4)", - "164.508(a)(1)", - "164.508(a)(4)(i)" + "§ 164.506(c)(1)", + "§ 164.506(c)(2)", + "§ 164.506(c)(3)", + "§ 164.506(c)(4)", + "§ 164.508(a)(1)", + "§ 164.508(a)(4)(i)" ], "usa-federal-irs-1075-2021": [ "AC-21" @@ -205288,138 +210793,97 @@ "Section 6(1)(a)", "Section 6(1)(c)" ], - "emea-aut-fappd-2000": [ - "Sec 10" + "emea-deu-fdpa-2017": [ + "3.5.79(1)2", + "3.5.81(1)", + "3.5.81(1)1", + "3.5.81(1)2", + "3.5.81(1)3", + "3.5.81(2)", + "3.5.81(3)", + "3.5.81(4)" ], - "emea-isr-cmo-1-0": [ - "10.5" + "emea-grc-pirppd-1997": [ + "B.9.1", + "B.9.2.a", + "B.9.2.b", + "B.9.2.b.i", + "B.9.2.b.ii", + "B.9.2.b.iii", + "B.9.2.c", + "B.9.2.d", + "B.9.2.e" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" ], "emea-ken-pda-2019": [ - "25(h)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "IV.25(h)" ], "emea-nga-dpr-2019": [ - "2.4(b)" + "2.12(a)" + ], + "emea-qat-pdppl-2020": [ + "3.12" ], "emea-sau-pdpl-2023": [ "Article 8" ], - "emea-srb-act-9-2018": [ - "5" - ], - "emea-zaf-popia-2013": [ - "18", - "28", - "30", - "31" - ], - "apac-aus-privacy-principles-2026": [ - "APP 7", - "APP 8" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "22", - "27", - "38(3)", - "41", - "42", - "49" + "emea-tur-lppd-2016": [ + "8(1)", + "8(2)", + "8(2)(a)", + "8(2)(b)", + "8(3)" ], "apac-ind-dpdpa-2023": [ "8(2)" ], - "apac-jpn-ppi-2020": [ - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" + "apac-nzl-privacy-act-2020": [ + "3.1.22.11(1)", + "3.1.22.11(1)(a)", + "3.1.22.11(1)(b)", + "3.1.22.11(1)(c)", + "3.1.22.11(1)(d)", + "3.1.22.11(1)(e)", + "3.1.22.11(1)(e)(i)", + "3.1.22.11(1)(e)(ii)", + "3.1.22.11(1)(e)(iii)", + "3.1.22.11(1)(e)(iv)", + "3.1.22.11(1)(f)", + "3.1.22.11(1)(f)(i)", + "3.1.22.11(1)(f)(ii)", + "3.1.22.11(1)(g)", + "3.1.22.11(1)(h)", + "3.1.22.11(1)(h)(i)", + "3.1.22.11(1)(h)(ii)", + "3.1.22.11(1)(i)" ], "apac-sgp-pdpa-2012": [ - "26" + "4.1.17(1)(c)", + "5.22(2)(b)", + "5.22(3)" ], - "apac-kor-pipa-2011": [ - "17", - "26", - "27" - ], - "americas-arg-ppd-2018": [ - "11.1", - "11.2", - "11.3", - "11.4", - "12.1", - "16.4" + "americas-bhs-dpa-2003": [ + "VI.53(1)", + "VI.54", + "VI.54(a)", + "VI.54(b)", + "VI.54(b)(i)", + "VI.54(b)(ii)", + "VI.54(b)(iii)", + "VI.54(b)(iv)", + "VI.54(b)(v)", + "VI.54(b)(vi)", + "VI.54(c)" ], - "americas-can-pipeda-2000": [ - "Sec 20", - "Sec 23" + "americas-bra-lgpd-2018": [ + "V.33" ], "americas-col-law-1581-2012": [ - "26" + "VI.17(h)" ] } }, @@ -205444,9 +210908,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include data privacy requirements in contracts and other acquisition-related documents that establish data privacy roles and responsibilities for contractors and service providers.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include data privacy requirements in contracts and other acquisition-related documents that establish data privacy roles and responsibilities for contractors and service providers. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -205510,7 +210974,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -205551,7 +211016,7 @@ "5.33" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "ID.DE-P3" @@ -205573,22 +211038,19 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-tisax-6-0-3": [ "9.5.2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.504(e)(2)(i)", - "164.504(e)(2)(ii)(A)", - "164.504(e)(2)(ii)(B)", - "164.504(e)(2)(ii)(C)", - "164.504(e)(4)(i)", - "164.504(e)(4)(i)(A)", - "164.504(e)(4)(i)(B)", - "164.504(e)(4)(i)(B)(ii)", - "164.504(e)(4)(i)(B)(ii)(A)" + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(ii)(A)", + "§ 164.504(e)(2)(ii)(B)", + "§ 164.504(e)(2)(ii)(C)", + "§ 164.504(e)(4)(i)", + "§ 164.504(e)(4)(i)(A)", + "§ 164.504(e)(4)(i)(B)", + "§ 164.504(e)(4)(i)(B)(ii)", + "§ 164.504(e)(4)(i)(B)(ii)(A)" ], "usa-federal-cms-marse-2-0": [ "AR-3", @@ -205637,6 +211099,15 @@ "usa-state-il-pipa-2006": [ "45(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.3", + "603A.495.3(d)", + "603A.530.1", + "603A.530.2", + "603A.530.3", + "603A.530.3(a)", + "603A.530.3(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.581(2)" ], @@ -205712,124 +211183,167 @@ "Article 29", "Article 46.3(a)" ], - "emea-aut-fappd-2000": [ - "Sec 10" + "emea-aut-dpa-2018": [ + "§ 48(1)", + "§ 48(2)", + "§ 48(3)", + "§ 48(4)", + "§ 48(5)", + "§ 48(6)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 3, Art. 53(1)", + "Title 2, Chapter IV, Section 3, Art. 53(2)", + "Title 2, Chapter IV, Section 3, Art. 53(3)", + "Title 2, Chapter IV, Section 3, Art. 53(4)", + "Title 2, Chapter IV, Section 3, Art. 53(5)", + "Title 2, Chapter IV, Section 3, Art. 54" ], - "emea-deu-c5-2020": [ - "HR-06", - "PI-02" - ], - "emea-isr-cmo-1-0": [ - "11.1" + "emea-grc-pirppd-1997": [ + "B.10.4" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(1)", + "II.8.9(1)(c)", + "II.8.9(1)(e)", + "II.8.9(2)", + "II.8.9(3)", + "II.8.9(5)", + "II.9.10(1)", + "II.9.10(2)", + "II.9.10(3)", + "II.9.10(4)", + "II.10.11(1)(a)" + ], + "emea-irl-dpa-2018": [ + "s.80" + ], + "emea-isr-ppl-5741-2025": [ + "s.13A" ], "emea-ken-pda-2019": [ - "25(h)", - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "IV.25(h)", + "IV.40(2)(a)", + "IV.40(2)(b)", + "IV.40(3)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], "emea-nga-dpr-2019": [ - "2.4(b)", "2.7" ], - "emea-qat-pdppl-2020": [ - "12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-25" - ], "emea-srb-act-9-2018": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "45", - "45.x", - "46" + "IV.1.45-1", + "IV.1.45-1(1)", + "IV.1.45-1(2)", + "IV.1.45-1(3)", + "IV.1.45-1(4)", + "IV.1.45-1(5)", + "IV.1.45-1(6)", + "IV.1.45-1(7)", + "IV.1.45-1(8)", + "IV.1.45-2", + "IV.1.45-2(1)", + "IV.1.45-2(2)", + "IV.1.45-2(3)", + "IV.1.45-2(4)", + "IV.1.45-2(5)", + "IV.1.45-2(6)" ], "emea-zaf-popia-2013": [ - "11", - "20", - "21" + "3.A.7.21(1)", + "3.A.7.21(2)" + ], + "emea-gbr-dpa-2018": [ + "Section 59(1)", + "Section 59(2)", + "Section 59(2)(a)", + "Section 59(2)(b)", + "Section 59(3)", + "Section 59(4)", + "Section 59(5)", + "Section 59(5)(a)", + "Section 59(5)(b)", + "Section 59(5)(c)", + "Section 59(5)(d)", + "Section 59(6)", + "Section 59(6)(a)", + "Section 59(6)(b)", + "Section 59(6)(c)", + "Section 59(6)(d)", + "Section 59(6)(d)(i)", + "Section 59(6)(d)(ii)", + "Section 59(6)(e)", + "Section 59(6)(f)", + "Section 59(7)", + "Section 59(7A)", + "Section 59(8)", + "Section 60", + "Section 60(a)", + "Section 60(b)", + "Section 63" ], - "apac-aus-privacy-principles-2026": [ - "APP 7" + "apac-aus-cop-sitc-2020": [ + "5" ], "apac-chn-pipl-2021": [ - "20", - "21", - "27", - "38(3)", - "42" + "Article 21" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 4(2)" ], "apac-ind-dpdpa-2023": [ "8(2)", "8(7)(b)" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" + "apac-ind-privacy-rules-2011": [ + "6(4)" ], - "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "apac-phl-dpa-2012": [ + "III.14", + "V.20(d)" ], "apac-kor-pipa-2011": [ - "26", - "27" + "III.1.18(5)" ], - "americas-arg-ppd-2018": [ - "11.4" + "americas-bhs-dpa-2003": [ + "V.51(1)(a)", + "V.51(1)(b)", + "V.51(1)(b)(i)", + "V.51(1)(b)(ii)", + "V.51(1)(b)(iii)", + "V.51(1)(b)(iv)", + "V.51(2)(a)", + "V.51(2)(b)", + "V.51(2)(c)", + "V.51(2)(d)", + "V.51(2)(e)", + "V.51(2)(f)", + "V.51(2)(g)", + "V.51(2)(h)", + "V.51(3)", + "V.51(4)", + "V.51(5)", + "V.51(5)(a)", + "V.51(5)(b)", + "V.51(6)", + "V.51(7)", + "V.51(8)" ], "americas-bra-lgpd-2018": [ - "35", - "39" + "VI.I.39" ], "americas-can-pipeda-2000": [ - "Sec 20", - "Sec 23" + "P1-4.1.3" + ], + "americas-col-law-1581-2012": [ + "VI.17(i)" + ], + "americas-mex-fdpa-2010": [ + "II.21" ] } }, @@ -205854,9 +211368,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to clearly define and communicate the organization's role in processing Personal Data (PD) in the data processing ecosystem.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to clearly define and communicate the organization's role in processing Personal Data (PD) in the data processing ecosystem. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -205915,7 +211429,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -205925,70 +211440,50 @@ "general-nist-privacy-framework-1-0": [ "ID.BE-P1" ], - "general-scf-dpmp-2025": [ - "11.1" - ], "usa-state-or-cpa-2023": [ "Section 6(1)(a)" ], "usa-state-tn-tipa-2025": [ "47-18-3205(d)" ], - "emea-ken-pda-2019": [ - "42(2)(a)", - "42(2)(b)", - "42(3)" + "emea-aut-dpa-2018": [ + "§ 47" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 2, Art. 52" + ], + "emea-deu-fdpa-2017": [ + "3.4.62(1)", + "3.4.62(2)", + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)9", + "3.4.63" + ], + "emea-grc-pirppd-1997": [ + "B.8.1" + ], + "emea-irl-dpa-2018": [ + "s.79" ], "emea-srb-act-9-2018": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "43" + "IV.1.43" ], - "apac-chn-pipl-2021": [ - "20", - "21", - "27", - "38(3)" + "emea-gbr-dpa-2018": [ + "Section 58(1)", + "Section 58(2)", + "Section 58(3)" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" + "apac-chn-pipl-2021": [ + "Article 20" ] } }, @@ -206010,7 +211505,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to inform applicable third-parties of any modification, deletion or other change that affects shared Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -206068,7 +211563,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -206078,9 +211574,6 @@ "general-nist-privacy-framework-1-0": [ "CM.AW-P5" ], - "general-scf-dpmp-2025": [ - "6.4" - ], "usa-state-ca-ccpa-cpra-2026": [ "7022(b)(2)", "7022(b)(3)", @@ -206093,57 +211586,45 @@ "usa-state-va-cdpa-2023": [ "59.1-579.B.2" ], + "emea-deu-fdpa-2017": [ + "3.3.58(5)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.f" + ], + "emea-hun-act-cxii-2011": [ + "II.13.18(1)" + ], "emea-ken-pda-2019": [ - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)" + "IV.40(2)", + "IV.40(3)" ], "emea-nga-dpr-2019": [ "3.1(10)" ], "emea-srb-act-9-2018": [ - "30", - "30.x", - "32", - "32.1", - "32.2", - "33" + "II.11" ], - "apac-chn-pipl-2021": [ - "46" + "apac-nzl-privacy-act-2020": [ + "3.1.22.7(5)" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" + "americas-bra-lgpd-2018": [ + "III.18.IX.6" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.6" + ], + "americas-col-law-1581-2012": [ + "VI.17(l)" ] } }, { "control_id": "PRI-07.4", - "title": "Reject Unauthenticated or Untrustworthy Disclosure Requests", + "title": "Disclosure Request Rejections", "family": "PRI", - "description": "Mechanisms exist to reject unauthenticated, or untrustworthy, disclosure requests.", - "scf_question": "Does the organization reject unauthenticated, or untrustworthy, disclosure requests?", + "description": "Mechanisms exist to reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful.", + "scf_question": "Does the organization reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -206156,9 +211637,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject unauthenticated, or untrustworthy, disclosure requests.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -206201,8 +211682,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -206213,15 +211696,11 @@ "general-csa-cmm-4-1-0": [ "DSP-18" ], - "general-scf-dpmp-2025": [ - "6.0", - "6.1" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(d)(2)(i)", - "164.524(d)(2)(ii)", - "164.524(d)(2)(iii)", - "164.524(d)(3)" + "§ 164.524(d)(2)(i)", + "§ 164.524(d)(2)(ii)", + "§ 164.524(d)(2)(iii)", + "§ 164.524(d)(3)" ], "usa-state-ca-ccpa-cpra-2026": [ "7022(a)", @@ -206239,14 +211718,71 @@ "usa-state-tx-cdpa-2025": [ "541.052(e)" ], - "emea-srb-act-9-2018": [ - "21.2", - "22.2" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(4)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(1)" + ], + "emea-gbr-dpa-2018": [ + "Section 53(1)", + "Section 53(1)(a)", + "Section 53(1)(b)", + "Section 53(2)", + "Section 53(3)", + "Section 53(4)", + "Section 53(4A)", + "Section 53(4A)(a)", + "Section 53(4A)(b)", + "Section 53(5)" + ], + "apac-aus-privacy-principles-2026": [ + "5.12.3.h.i" ], "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "Article 50" + ], + "apac-hkg-pdo-2022": [ + "24(1)", + "24(1)(a)", + "24(1)(b)", + "24(1)(b)(i)", + "24(1)(b)(ii)", + "24(2)", + "24(3)", + "24(3)(a)", + "24(3)(b)", + "24(3)(c)", + "24(3)(d)", + "24(3)(e)", + "24(4)" + ], + "apac-mys-pdpa-2010": [ + "36(1)", + "36(1)(a)", + "36(1)(a)(i)", + "36(1)(a)(ii)", + "36(1)(a)(ii)(A)", + "36(1)(a)(ii)(B)", + "36(1)(b)", + "36(1)(c)", + "36(1)(d)", + "36(1)(e)", + "36(2)" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.46(1)" + ], + "apac-kor-pipa-2011": [ + "V.35(4)", + "V.35(4)1", + "V.35(4)2", + "V.35(4)3", + "V.35(4)3.a", + "V.35(4)3.b", + "V.35(4)3.c", + "V.35(4)3.d", + "V.35(4)3.e" ] } }, @@ -206254,8 +211790,8 @@ "control_id": "PRI-07.5", "title": "Justification To Reject Disclosure Requests", "family": "PRI", - "description": "Mechanisms exist to reject data subject access requests that are categorized as:\n(1) Harassing; \n(2) Repetitive; or\n(3) Fraudulent.", - "scf_question": "Does the organization reject data subject access requests that are categorized as:\n (1) Harassing; \n (2) Repetitive; or\n (3) Fraudulent?", + "description": "Mechanisms exist to document justifiable reasons for rejecting a data subject's access request for disclosure when the request is:\n(1) Harassing;\n(2) Repetitive;\n(3) Fraudulent;\n(4) Unjustified; and/or\n(5) Unlawful.", + "scf_question": "Does the organization document justifiable reasons for rejecting a data subject's access request for disclosure when the request is:\n(1) Harassing;\n(2) Repetitive;\n(3) Fraudulent;\n(4) Unjustified; and/or\n(5) Unlawful?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -206268,7 +211804,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject data subject access requests that are categorized as:\n(1) Harassing; \n(2) Repetitive; or\n(3) Fraudulent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -206313,8 +211849,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Data Privacy", "crosswalks": { "general-csa-cmm-4-1-0": [ @@ -206330,14 +211868,77 @@ "7027(f)", "7027(j)" ], + "emea-aut-dpa-2018": [ + "§ 44(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(5)" + ], + "emea-deu-fdpa-2017": [ + "2.2.34(2)", + "3.3.59(4)" + ], + "emea-nga-dpr-2019": [ + "3.1(4)" + ], + "emea-nor-pda-2018": [ + "16" + ], "emea-srb-act-9-2018": [ - "21.2", - "22.2" + "III.1.21(2)", + "III.1.22(2)" ], "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "Article 50" + ], + "apac-hkg-pdo-2022": [ + "20(1)", + "20(1)(a)", + "20(1)(a)(i)", + "20(1)(a)(ii)", + "20(1)(a)(ii)(A)", + "20(1)(a)(ii)(B)", + "20(1)(b)", + "20(1)(c)", + "20(2)(a)", + "20(2)(b)", + "20(3)", + "20(3)(a)", + "20(3)(b)", + "20(3)(c)", + "20(3)(c)(i)", + "20(3)(c)(ii)", + "20(3)(c)(iii)", + "20(3)(d)", + "20(3)(e)", + "20(3)(f)", + "25(1)(a)" + ], + "apac-jpn-appi-2020": [ + "IV.1.28(2)(i)", + "IV.1.28(2)(ii)", + "IV.1.28(2)(iii)" + ], + "apac-mys-pdpa-2010": [ + "32(1)(d)", + "32(1)(d)(i)", + "32(1)(d)(ii)", + "32(1)(e)", + "32(1)(f)", + "32(1)(g)", + "32(1)(h)" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.46(2)", + "4.1.46(3)" + ], + "americas-mex-fdpa-2010": [ + "IV.34", + "IV.34.I", + "IV.34.II", + "IV.34.III", + "IV.34.IV", + "IV.34.V" ] } }, @@ -206359,9 +211960,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to conduct testing, training and monitoring activities for Personal Data (PD) controls.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to conduct testing, training and monitoring activities for Personal Data (PD) controls.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -206426,9 +212027,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -206479,9 +212080,6 @@ "general-pci-dss-4-0-1": [ "A3.1.4" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-14" ], @@ -206509,9 +212107,6 @@ ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-14" - ], - "emea-zaf-popia-2013": [ - "19" ] } }, @@ -206520,7 +212115,7 @@ "title": "Personal Data (PD) Lineage", "family": "PRI", "description": "Mechanisms exist to maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD.", - "scf_question": "Does the organization document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD?", + "scf_question": "Does the organization maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -206533,7 +212128,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -206576,7 +212171,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -206602,10 +212198,6 @@ "general-nist-800-82-r3-high": [ "SA-04(12)" ], - "general-scf-dpmp-2025": [ - "5.1", - "5.13" - ], "usa-federal-gsa-fedramp-5-low": [ "SA-04(12)" ], @@ -206620,9 +212212,6 @@ ], "usa-federal-irs-1075-2021": [ "SA-4(CE-12)" - ], - "emea-zaf-popia-2013": [ - "17" ] } }, @@ -206630,8 +212219,8 @@ "control_id": "PRI-10", "title": "Data Quality Management", "family": "PRI", - "description": "Mechanisms exist to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle.", - "scf_question": "Does the organization manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle?", + "description": "Mechanisms exist to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive and/or regulated data across the information lifecycle.", + "scf_question": "Does the organization manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive and/or regulated data across the information lifecycle?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -206644,7 +212233,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -206706,7 +212295,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -206763,9 +212353,6 @@ "general-oecd-privacy-principles-2010": [ "2" ], - "general-scf-dpmp-2025": [ - "5.11" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-22", "PM-23", @@ -206790,10 +212377,10 @@ "5" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.512(i)(1)(i)(B)", - "164.512(i)(1)(i)(B)(1)", - "164.512(i)(1)(i)(B)(2)", - "164.512(i)(1)(i)(B)(3)" + "§ 164.512(i)(1)(i)(B)", + "§ 164.512(i)(1)(i)(B)(1)", + "§ 164.512(i)(1)(i)(B)(2)", + "§ 164.512(i)(1)(i)(B)(3)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(c)" @@ -206801,18 +212388,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-22" ], - "emea-srb-act-9-2018": [ - "5.4", - "11" - ], - "emea-zaf-popia-2013": [ - "4" - ], - "apac-chn-pipl-2021": [ - "8" - ], - "americas-bra-lgpd-2018": [ - "6.5" + "emea-grc-pirppd-1997": [ + "B.4.1.c" ] } }, @@ -206834,7 +212411,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically support the evaluation of data quality across the information lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -206879,7 +212456,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -206892,9 +212470,6 @@ "general-nist-800-82-r3": [ "PT-03(02)" ], - "general-scf-dpmp-2025": [ - "5.11" - ], "usa-federal-gsa-fedramp-5-low": [ "PT-03(02)" ], @@ -206927,7 +212502,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to evaluate its analytical processes for potential bias.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -206971,21 +212546,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": { - "general-scf-dpmp-2025": [ - "5.16" - ] - } + "crosswalks": {} }, { "control_id": "PRI-11", "title": "Data Tagging", "family": "PRI", - "description": "Mechanisms exist to issue data modeling guidelines to support tagging of sensitive/regulated data.", - "scf_question": "Does the organization issue data modeling guidelines to support tagging of sensitive/regulated data?", + "description": "Mechanisms exist to issue data modeling guidelines to support tagging of sensitive and/or regulated data.", + "scf_question": "Does the organization issue data modeling guidelines to support tagging of sensitive and/or regulated data?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -206998,7 +212570,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to issue data modeling guidelines to support tagging of sensitive/regulated data.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -207042,7 +212614,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -207055,10 +212628,6 @@ "general-nist-800-82-r3": [ "PT-03(01)" ], - "general-scf-dpmp-2025": [ - "5.0", - "5.2" - ], "usa-federal-dow-zt-roadmap-1-1": [ "4.2", "4.3", @@ -207143,7 +212712,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -207151,14 +212721,11 @@ "P5.2", "P5.2-POF2" ], - "general-scf-dpmp-2025": [ - "6.2" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(b)(1)", - "164.526(e)", - "164.526(f)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)", + "§ 164.526(e)", + "§ 164.526(f)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(b)", @@ -207170,9 +212737,6 @@ ], "emea-sau-pdpl-2023": [ "Article 17.1" - ], - "emea-zaf-popia-2013": [ - "16" ] } }, @@ -207194,7 +212758,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to enable data subjects to update their Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -207232,7 +212796,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -207240,6 +212805,9 @@ "7023(a)", "7023(b)" ], + "apac-aus-privacy-principles-2026": [ + "5.13.1.b.ii" + ], "apac-ind-dpdpa-2023": [ "12(2)(c)" ] @@ -207263,7 +212831,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to establish a written charter for a Data Management Board (DMB) and assigned organization-defined roles to the DMB.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -207325,7 +212893,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -207359,9 +212928,6 @@ "general-nist-800-161-r1-level-1": [ "PM-23" ], - "general-scf-dpmp-2025": [ - "11.4" - ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -207401,7 +212967,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to document Personal Data (PD) processing activities that covers collection, receiving, processing, storage, transmission, sharing, updating and/or disposal actions with sufficient detail to demonstrate conformity with applicable statutory, regulatory and contractual requirements.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -207486,7 +213052,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -207536,10 +213103,6 @@ "general-nist-800-161-r1-level-3": [ "PM-27" ], - "general-scf-dpmp-2025": [ - "5.8", - "11.5" - ], "general-shared-assessments-sig-2025": [ "L.1" ], @@ -207547,6 +213110,19 @@ "AR-6", "DM-2(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.535.3", + "603A.535.3(a)", + "603A.535.3(b)", + "603A.535.3(c)", + "603A.535.3(d)", + "603A.535.3(e)", + "603A.535.3(f)", + "603A.535.3(g)", + "603A.535.3(h)", + "603A.535.3(i)", + "603A.535.8" + ], "usa-state-tx-cdpa-2025": [ "541.052(f)(1)" ], @@ -207569,8 +213145,67 @@ "Article 30.2(d)", "Article 30.3" ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-aut-dpa-2018": [ + "§ 13(2)", + "§ 49(1)", + "§ 49(2)", + "§ 49(3)", + "§ 50(1)", + "§ 50(2)", + "§ 50(3)", + "§ 50(5)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(3)", + "Title 2, Chapter III, Art. 45(5)", + "Title 2, Chapter IV, Section 4, Art. 55(1)", + "Title 2, Chapter IV, Section 4, Art. 55(2)", + "Title 2, Chapter IV, Section 4, Art. 55(3)", + "Title 2, Chapter IV, Section 4, Art. 56(1)", + "Title 2, Chapter IV, Section 4, Art. 56(2)", + "Title 2, Chapter IV, Section 4, Art. 56(3)", + "Title 2, Chapter IV, Section 4, Art. 57", + "Title 2, Chapter IV, Section 4, Art. 58" + ], + "emea-deu-fdpa-2017": [ + "3.4.70(1)", + "3.4.70(1)1", + "3.4.70(1)2", + "3.4.70(1)3", + "3.4.70(1)4", + "3.4.70(1)5", + "3.4.70(1)6", + "3.4.70(1)7", + "3.4.70(1)8", + "3.4.70(1)9", + "3.4.70(2)1", + "3.4.70(2)2", + "3.4.70(2)3", + "3.4.70(4)", + "3.4.76(1)", + "3.4.76(1)1", + "3.4.76(1)2", + "3.4.76(1)3", + "3.4.76(1)4", + "3.4.76(1)5", + "3.4.76(1)6", + "3.4.76(2)", + "3.4.76(3)", + "3.4.76(4)", + "3.5.79(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.15(2)" + ], + "emea-irl-dpa-2018": [ + "s.81", + "s.82" + ], + "emea-ita-pdpc-2018": [ + "Article 110(2)" + ], + "emea-nga-dpr-2019": [ + "3.1(8)" ], "emea-sau-pdpl-2023": [ "Article 31", @@ -207582,17 +213217,136 @@ "Article 31.6" ], "emea-srb-act-9-2018": [ - "47", - "47.x", - "48", - "52", - "52.1", - "52.2", - "52.3", - "52.4" + "II.15", + "IV.1.47-2", + "IV.1.47-2(1)", + "IV.1.47-2(2)", + "IV.1.47-2(3)", + "IV.1.47-2(4)", + "IV.1.47-2(5)", + "IV.1.47-2(6)", + "IV.1.47-2(7)", + "IV.1.47-2(8)", + "IV.1.47-2(9)", + "IV.1.47-3", + "IV.1.47-3(1)", + "IV.1.47-3(2)", + "IV.1.47-3(3)", + "IV.1.47-3(4)", + "IV.1.47-4", + "IV.1.47-4(1)", + "IV.1.47-4(2)", + "IV.1.47-4(3)", + "IV.1.47-4(4)" + ], + "emea-che-fadp-2025": [ + "2.1.12.1", + "2.1.12.2", + "2.1.12.2.a", + "2.1.12.2.b", + "2.1.12.2.c", + "2.1.12.2.d", + "2.1.12.2.e", + "2.1.12.2.f", + "2.1.12.2.g", + "2.1.12.3", + "2.2.15.1" + ], + "emea-gbr-dpa-2018": [ + "Section 61(1)", + "Section 61(2)", + "Section 61(2)(a)", + "Section 61(2)(b)", + "Section 61(2)(c)", + "Section 61(2)(d)", + "Section 61(2)(e)", + "Section 61(2)(f)", + "Section 61(2)(f)(i)", + "Section 61(2)(f)(ii)", + "Section 61(2)(g)", + "Section 61(2)(h)", + "Section 61(2)(h)(i)", + "Section 61(2)(j)", + "Section 61(2)(k)", + "Section 61(3)", + "Section 61(4)", + "Section 61(4)(a)", + "Section 61(4)(b)", + "Section 61(4)(c)", + "Section 61(4)(d)", + "Section 61(4)(e)", + "Section 61(4)(f)", + "Section 61(5)", + "Section 62(1)", + "Section 62(1)(a)", + "Section 62(1)(b)", + "Section 62(1)(c)", + "Section 62(1)(d)", + "Section 62(1)(e)", + "Section 62(1)(f)", + "Section 62(2)", + "Section 62(2)(a)", + "Section 62(2)(b)", + "Section 62(3)", + "Section 62(3)(a)", + "Section 62(3)(b)", + "Section 62(3)(b)(i)", + "Section 62(3)(b)(ii)", + "Section 62(4)", + "Section 62(4)(a)", + "Section 62(4)(b)", + "Section 62(4)(c)", + "Section 62(4)(d)", + "Section 62(5)" + ], + "apac-hkg-pdo-2022": [ + "27(1)", + "27(1)(a)", + "27(1)(b)", + "27(1)(c)", + "27(1)(c)(i)", + "27(1)(c)(ii)", + "27(2)", + "27(2)(a)", + "27(2)(b)", + "27(2)(c)", + "27(2)(d)", + "27(3)", + "27(3)(a)", + "27(3)(b)", + "27(3)(c)", + "27(3)(d)", + "27(4)", + "27(4)(a)", + "27(4)(b)" + ], + "apac-mys-pdpa-2010": [ + "44(1)" + ], + "americas-bhs-dpa-2003": [ + "V.43(1)", + "V.43(2)", + "V.43(2)(a)", + "V.43(2)(b)", + "V.43(2)(c)", + "V.43(2)(d)", + "V.43(2)(e)", + "V.43(2)(f)", + "V.43(2)(g)", + "V.43(2)(h)", + "V.43(2)(i)", + "V.43(2)(j)", + "V.43(3)", + "V.43(4)", + "V.43(4)(a)", + "V.43(4)(b)", + "V.43(4)(c)" ], "americas-bra-lgpd-2018": [ - "38" + "VI.I.37" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.1" ] } }, @@ -207616,7 +213370,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with an accounting of disclosures of their Personal Data (PD) controlled by:\n(1) The organization; and/or\n(2) Relevant third-parties that their PD was shared with.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -207678,7 +213432,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -207730,49 +213485,46 @@ "general-nist-800-161-r1-level-2": [ "PM-21" ], - "general-scf-dpmp-2025": [ - "5.8" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.528(a)(1)", - "164.528(a)(1)(i)", - "164.528(a)(1)(ii)", - "164.528(a)(1)(iii)", - "164.528(a)(1)(iv)", - "164.528(a)(1)(v)", - "164.528(a)(1)(vi)", - "164.528(a)(1)(vii)", - "164.528(a)(1)(viii)", - "164.528(a)(1)(ix)", - "164.528(b)", - "164.528(b)(1)", - "164.528(b)(2)", - "164.528(b)(2)(i)", - "164.528(b)(2)(ii)", - "164.528(b)(2)(iii)", - "164.528(b)(2)(iv)", - "164.528(b)(3)", - "164.528(b)(3)(i)", - "164.528(b)(3)(ii)", - "164.528(b)(3)(iii)", - "164.528(b)(4)(i)", - "164.528(b)(4)(i)(A)", - "164.528(b)(4)(i)(B)", - "164.528(b)(4)(i)(C)", - "164.528(b)(4)(i)(D)", - "164.528(b)(4)(i)(E)", - "164.528(b)(4)(i)(F)", - "164.528(b)(4)(ii)", - "164.528(c)(1)", - "164.528(c)(1)(i)", - "164.528(c)(1)(ii)", - "164.528(c)(1)(ii)(A)", - "164.528(c)(1)(ii)(B)", - "164.528(c)(2)", - "164.528(d)", - "164.528(d)(1)", - "164.528(d)(2)", - "164.528(d)(3)" + "§ 164.528(a)(1)", + "§ 164.528(a)(1)(i)", + "§ 164.528(a)(1)(ii)", + "§ 164.528(a)(1)(iii)", + "§ 164.528(a)(1)(iv)", + "§ 164.528(a)(1)(v)", + "§ 164.528(a)(1)(vi)", + "§ 164.528(a)(1)(vii)", + "§ 164.528(a)(1)(viii)", + "§ 164.528(a)(1)(ix)", + "§ 164.528(b)", + "§ 164.528(b)(1)", + "§ 164.528(b)(2)", + "§ 164.528(b)(2)(i)", + "§ 164.528(b)(2)(ii)", + "§ 164.528(b)(2)(iii)", + "§ 164.528(b)(2)(iv)", + "§ 164.528(b)(3)", + "§ 164.528(b)(3)(i)", + "§ 164.528(b)(3)(ii)", + "§ 164.528(b)(3)(iii)", + "§ 164.528(b)(4)(i)", + "§ 164.528(b)(4)(i)(A)", + "§ 164.528(b)(4)(i)(B)", + "§ 164.528(b)(4)(i)(C)", + "§ 164.528(b)(4)(i)(D)", + "§ 164.528(b)(4)(i)(E)", + "§ 164.528(b)(4)(i)(F)", + "§ 164.528(b)(4)(ii)", + "§ 164.528(c)(1)", + "§ 164.528(c)(1)(i)", + "§ 164.528(c)(1)(ii)", + "§ 164.528(c)(1)(ii)(A)", + "§ 164.528(c)(1)(ii)(B)", + "§ 164.528(c)(2)", + "§ 164.528(d)", + "§ 164.528(d)(1)", + "§ 164.528(d)(2)", + "§ 164.528(d)(3)" ], "usa-federal-irs-1075-2021": [ "PM-21" @@ -207790,28 +213542,34 @@ "Section 3(1)(a)(B)(i)", "Section 3(1)(a)(B)(ii)" ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-deu-fdpa-2017": [ + "3.3.57(1)4", + "3.5.79(2)" ], - "emea-srb-act-9-2018": [ - "33" + "emea-hun-act-cxii-2011": [ + "II.13.15(2)" ], - "emea-zaf-popia-2013": [ - "17" + "emea-nga-dpr-2019": [ + "3.1(8)" + ], + "apac-chn-pipl-2021": [ + "Article 22", + "Article 23" ], "apac-ind-dpdpa-2023": [ "11(1)(b)" ], - "apac-jpn-ppi-2020": [ - "25(1)", - "25(2)" + "apac-jpn-appi-2020": [ + "IV.1.25(1)", + "IV.1.25(2)", + "IV.1.26(3)", + "IV.1.26(4)" ], - "apac-phl-dpa-2012": [ - "20" + "americas-bhs-dpa-2003": [ + "V.43(4)(c)" ], - "americas-bra-lgpd-2018": [ - "18.7", - "37" + "americas-can-pipeda-2000": [ + "P9-4.9.3" ] } }, @@ -207833,7 +213591,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of applicable legal requests to disclose Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -207877,26 +213635,32 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-csa-cmm-4-1-0": [ "DSP-18" ], - "general-scf-dpmp-2025": [ - "4.0", - "4.1" - ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-nga-dpr-2019": [ + "3.1(8)" ], "emea-sau-pdpl-2023": [ "Article 24.2" ], "emea-srb-act-9-2018": [ - "33", - "35" + "III.3.33" + ], + "apac-aus-privacy-principles-2026": [ + "3.6.5" + ], + "americas-bhs-dpa-2003": [ + "V.46(3)", + "V.46(3)(a)", + "V.46(3)(b)", + "V.46(3)(c)", + "V.46(3)(d)" ] } }, @@ -207920,7 +213684,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to register as a data controller and/or data processor, including registering databases containing Personal Data (PD) with the appropriate Data Authority, when necessary.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -207966,115 +213730,74 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.3" - ], "general-tisax-6-0-3": [ "9.3.1" ], "usa-state-vt-act-171-2018": [ "2446(a)(1)" ], - "emea-aut-fappd-2000": [ - "Sec 16", - "Sec 17" - ], - "emea-bel-act-8-1992": [ - "17" - ], - "emea-deu-fdpa-2017": [ - "Sec 4d", - "Sec 4e" - ], "emea-grc-pirppd-1997": [ - "6" + "B.6.1", + "B.6.2", + "B.6.2.a", + "B.6.2.b", + "B.6.2.c", + "B.6.2.d", + "B.6.2.e", + "B.6.2.f", + "B.6.2.g", + "B.6.2.h", + "B.6.3", + "B.6.4" + ], + "emea-isr-ppl-5741-2025": [ + "s.8", + "s.8A", + "s.9", + "s.10" ], - "emea-hun-isdfi-2011": [ - "65", - "66" - ], - "emea-irl-dpa-2003": [ - "17" - ], - "emea-isr-ppl-5741-1981": [ - "8", - "9" - ], - "emea-ita-pdpc-2003": [ - "26", - "37" - ], - "emea-ken-pda-2019": [ - "18(1)", - "18(2)", - "18(2)(a)", - "18(2)(b)", - "18(2)(c)", - "18(2)(d)", - "19(1)", - "19(2)", - "19(2)(a)", - "19(2)(b)", - "19(2)(c)", - "19(2)(d)", - "19(2)(e)", - "19(2)(f)", - "19(2)(g)", - "19(3)", - "19(4)", - "19(5)", - "19(6)", - "19(7)", - "20" - ], - "emea-nor-pda-2018": [ - "33" - ], - "emea-pol-act-29-1997": [ - "40" - ], - "emea-rus-federal-law-27-2006": [ - "23" - ], - "emea-esp-decree-1720-2007": [ - "60" + "emea-nga-dpr-2019": [ + "4.1(4)" ], - "emea-che-fadp-2025": [ - "11" + "emea-rus-152-fz-2025": [ + "Art. 22" ], "emea-tur-lppd-2016": [ - "16" - ], - "apac-hkg-pdo-2022": [ - "Sec 15" - ], - "apac-mys-pdpa-2010": [ - "14", - "15" - ], - "apac-phl-dpa-2012": [ - "46", - "47", - "48" - ], - "apac-sgp-pdpa-2012": [ - "39" - ], - "apac-kor-pipa-2011": [ - "32" + "16(1)", + "16(2)", + "16(3)", + "16(3)(a)", + "16(3)(b)", + "16(3)(c)", + "16(3)(ç)", + "16(3)(d)", + "16(3)(e)", + "16(3)(f)", + "16(4)", + "16(5)" ], - "americas-arg-ppd-2018": [ - "21.1", - "21.2", - "21.3", - "24" + "americas-bhs-dpa-2003": [ + "V.41(1)", + "V.41(1)(a)", + "V.41(1)(b)", + "V.41(1)(c)", + "V.41(1)(d)", + "V.41(1)(e)", + "V.41(1)(f)", + "V.41(1)(g)", + "V.41(2)", + "V.41(3)" ], - "americas-col-law-1581-2012": [ - "25" + "americas-chl-act-19628-1999": [ + "I.5", + "I.5(a)", + "I.5(b)", + "I.5(c)" ] } }, @@ -208096,7 +213819,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to constrain the supply of physical and/or digital activity logs to the host government that can directly lead to contravention of the Universal Declaration of Human Rights (UDHR), as well as other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208141,7 +213864,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -208152,34 +213876,14 @@ "Article 24" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "Article 27", + "Article 33" + ], + "apac-chn-csnip-2012": [ + "VI" ], "apac-chn-pipl-2021": [ - "11", - "12", - "18", - "26", - "38(4)", - "40", - "47(5)" + "Article 38" ] } }, @@ -208201,7 +213905,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Communications with data subjects is designed to be readily accessible and written in a manner that is concise, unambiguous and understandable by a reasonable person.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to craft disclosures and communications to data subjects in a manner that is concise, unambiguous and understandable by a reasonable person.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208245,16 +213949,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ "P6.7-POF3" ], - "general-scf-dpmp-2025": [ - "1.8" - ], "usa-state-ca-ccpa-cpra-2026": [ "7003(a)", "7004(a)(3)", @@ -208285,6 +213987,86 @@ ], "usa-state-va-cdpa-2023": [ "59.1-577.B.2" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter III, Art. 36(1)" + ], + "emea-deu-fdpa-2017": [ + "2.2.33(2)", + "2.2.34(2)", + "3.3.57(6)", + "3.3.57(8)", + "3.3.58(6)", + "3.3.59(1)", + "3.3.59(2)", + "3.4.74(2)" + ], + "emea-grc-pirppd-1997": [ + "C.11.3" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(2)", + "II.13.18(2)" + ], + "emea-ken-pda-2019": [ + "IV.34(2)(b)", + "IV.35(3)(a)" + ], + "emea-nga-dpr-2019": [ + "3.1(2)", + "3.1(6)" + ], + "emea-qat-pdppl-2020": [ + "2.6.2", + "3.11.4" + ], + "emea-srb-act-9-2018": [ + "III.3.34" + ], + "emea-zaf-popia-2013": [ + "3.A.3.14(8)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(5)", + "Section 44(5)(a)", + "Section 44(5)(b)", + "Section 44(5)(c)", + "Section 44(5)(d)", + "Section 44(5)(e)", + "Section 44(6)" + ], + "apac-aus-privacy-principles-2026": [ + "5.12.9", + "5.12.9.a", + "5.12.9.b", + "5.12.9.c", + "5.12.10" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.46(2)(a)", + "4.1.46(2)(b)", + "4.1.46(3)(a)", + "4.1.46(3)(b)" + ], + "apac-kor-pipa-2011": [ + "III.2.27(1)", + "III.2.27(1)1", + "III.2.27(1)2", + "III.2.27(1)3", + "III.2.27(2)", + "III.2.27(3)" + ], + "americas-bhs-dpa-2003": [ + "IV.24(2)", + "IV.24(2)(a)", + "IV.24(2)(b)", + "IV.36(4)", + "IV.36(4)(a)", + "IV.36(4)(b)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.4" ] } }, @@ -208306,7 +214088,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a conspicuous link to the organization's data privacy notice on all consumer-facing websites and mobile applications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208363,13 +214145,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.9" - ], "usa-state-ca-ccpa-cpra-2026": [ "7003(c)", "7003(d)" @@ -208394,7 +214174,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with a Notice of Financial Incentive that explains the material terms of a financial incentive, price or service difference so the data subject can make an informed decision about whether to participate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208451,13 +214231,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7010(g)", "7080(e)" @@ -208482,7 +214260,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain records of data subject requests and responses in accordance with an established documentation retention schedule that adheres to applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208539,7 +214317,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -208552,6 +214331,23 @@ ], "usa-state-va-cdpa-2023": [ "59.1-577.B.5" + ], + "emea-deu-fdpa-2017": [ + "3.3.57(8)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(7)(a)", + "Section 44(7)(b)", + "Section 45(7)(a)", + "Section 45(7)(b)" + ], + "apac-mys-pdpa-2010": [ + "37(2)", + "37(2)(a)", + "37(2)(a)(i)", + "37(2)(a)(ii)", + "37(2)(b)", + "37(3)" ] } }, @@ -208573,7 +214369,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to collect metrics associated with data subject requests and responses.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208630,7 +214426,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -208665,7 +214462,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publicly disclose applicable data subject communications metrics, as required by statutory and/or regulatory obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208724,7 +214521,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -208752,7 +214550,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to receive and process data controller communications pertaining to:\n(1) Receiving and responding to data subject requests;\n(2) Updating/correcting Personal Data (PD); \n(3) Accounting for disclosures of PD; and\n(4) Accounting for PD that is stored, processed and/or transmitted on behalf of the data controller.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208824,7 +214622,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -208834,6 +214633,25 @@ "usa-state-tx-cdpa-2025": [ "541.053(a)", "541.055(a)(1)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 38(4)" + ], + "emea-zaf-popia-2013": [ + "3.A.3.14(8)" + ], + "apac-jpn-appi-2020": [ + "IV.1.32(1)", + "IV.1.32(2)", + "IV.1.32(3)", + "IV.1.32(4)" + ], + "apac-sgp-pdpa-2012": [ + "5.22(5)", + "5.22(6)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.6" ] } }, @@ -208855,7 +214673,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data subject actions utilizing Automated Decision-Making Technology (ADMT) where computation replaces, or substantially replaces, human decisionmaking, conforms with all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208915,10 +214733,100 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": {} + "crosswalks": { + "emea-aut-dpa-2018": [ + "§ 41(1)", + "§ 41(2)", + "§ 41(3)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 35" + ], + "emea-deu-fdpa-2017": [ + "2.2.37(1)1", + "2.2.37(1)2", + "2.2.37(2)", + "3.2.54(1)", + "3.2.54(2)", + "3.2.54(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.10.11(2)" + ], + "emea-irl-dpa-2018": [ + "s.89" + ], + "emea-ken-pda-2019": [ + "IV.35(1)" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-srb-act-9-2018": [ + "III.4.39" + ], + "emea-zaf-popia-2013": [ + "8.71(1)", + "8.71(2)", + "8.71(2)(a)", + "8.71(2)(a)(i)", + "8.71(2)(a)(ii)", + "8.71(2)(b)", + "8.71(3)" + ], + "emea-che-fadp-2025": [ + "3.21.3.a" + ], + "emea-gbr-dpa-2018": [ + "Section 50(1)", + "Section 50(1)(a)", + "Section 50(1)(b)", + "Section 50(1)(b)(i)", + "Section 50(1)(b)(ii)", + "Section 50(2)", + "Section 50C(1)", + "Section 50C(1)(a)", + "Section 50C(1)(b)", + "Section 50C(2)", + "Section 50C(2)(a)", + "Section 50C(2)(b)", + "Section 50C(2)(c)", + "Section 50C(2)(d)", + "Section 50C(3)", + "Section 50C(3)(a)", + "Section 50C(3)(b)", + "Section 50C(3)(c)", + "Section 50C(4)", + "Section 50C(4)(a)", + "Section 50C(4)(b)", + "Section 50C(4)(c)", + "Section 50C(4)(d)", + "Section 50C(4)(e)", + "Section 50C(5)" + ], + "apac-chn-pipl-2021": [ + "Article 24" + ], + "americas-bhs-dpa-2003": [ + "IV.24(3)", + "V.49(1)", + "V.49(2)", + "V.49(2)(a)", + "V.49(2)(b)", + "V.49(2)(c)", + "V.49(3)", + "V.49(4)", + "V.49(4)(a)", + "V.49(4)(b)" + ], + "americas-bra-lgpd-2018": [ + "III.20" + ] + } }, { "control_id": "PRI-19.1", @@ -208938,7 +214846,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of their rights through a pre-use notice when their Personal Data (PD) will be processed by an Automated Decision-Making Technology (ADMT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -208998,7 +214906,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -209025,6 +214934,12 @@ "7220(e)(2)", "7220(e)(3)", "7220(e)(4)" + ], + "emea-ken-pda-2019": [ + "IV.35(3)(a)" + ], + "emea-zaf-popia-2013": [ + "8.71(3)(b)" ] } }, @@ -209046,7 +214961,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide concise, unambiguous and understandable instructions on how data subjects can opt-out of Automated Decision-Making Technology (ADMT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -209106,7 +215021,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -209133,6 +215049,21 @@ "7221(n)", "7221(n)(1)", "7221(n)(2)" + ], + "emea-ken-pda-2019": [ + "IV.35(1)" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-srb-act-9-2018": [ + "III.4.38" + ], + "emea-zaf-popia-2013": [ + "8.71(3)(a)" + ], + "emea-che-fadp-2025": [ + "3.21.3.b" ] } }, @@ -209154,7 +215085,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with sufficient details of the logic and parameters used by Automated Decision-Making Technology (ADMT) to process the Personal Data (PD) to generate an output with respect to the data subject.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -209214,12 +215145,35 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ "7222(a)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.d" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-che-fadp-2025": [ + "3.21.3.a" + ], + "apac-chn-pipl-2021": [ + "Article 24" + ], + "americas-bhs-dpa-2003": [ + "IV.24(3)(a)", + "IV.24(3)(b)", + "IV.24(3)(c)", + "IV.24(3)(d)" + ], + "americas-bra-lgpd-2018": [ + "III.20", + "III.20.1" ] } }, @@ -209241,7 +215195,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data brokers that collect Personal Data (PD) from a source other than directly from the data subject adhere to all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -209300,7 +215254,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -209327,9 +215282,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a notification to data subjects within the data privacy notice of:\n(1) Their right to direct an organization that sells or shares their Personal Data (PD) to stop selling or sharing their PD; and\n(2) The methods available to exercise that right.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a notification to data subjects within the data privacy notice of:\n(1) Their right to direct an organization that sells or shares their Personal Data (PD) to stop selling or sharing their PD; and\n(2) The methods available to exercise that right. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -209386,7 +215341,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -209441,7 +215397,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish conspicuous links for data subjects to exercise their rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -209500,7 +215456,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -209521,10 +215478,10 @@ }, { "control_id": "PRI-21.2", - "title": "Alternative Out-Out Link", + "title": "Alternative Opt-Out Link", "family": "PRI", - "description": "Mechanisms exist to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", - "scf_question": "Does the organization publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD?", + "description": "Mechanisms exist to publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD.", + "scf_question": "Does the organization publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -209539,7 +215496,7 @@ "0": "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.", "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.\nMechanisms exist to publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -209596,8 +215553,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ @@ -209713,9 +215672,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -209841,12 +215800,15 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-csf-2-0": [ "GV.RM", "GV.RR-03" ], - "general-scf-dpmp-2025": [ - "1.4" + "general-nist-cswp-39": [ + "6.1" ], "usa-federal-dow-cert-rmm-1-2": [ "EF:SG1.SP3", @@ -209917,12 +215879,10 @@ "PL-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(6)", - "3.6.1(61)", - "3.6.1(62)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -209930,45 +215890,39 @@ "Article 7(c)", "Article 7(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "2.3", "7.4", "7.5", "8.3" ], - "emea-isr-cmo-1-0": [ - "17.5" + "emea-isr-cmo-2-0": [ + "4.1, Stage 4" ], "emea-sau-cscc-1-2019": [ - "1-1" + "1-3-1", + "2-13-1" ], "emea-sau-ecc-1-2018": [ "1-1-3", "1-2-3" ], - "emea-zaf-popia-2013": [ - "19" + "emea-sau-otcc-1-2022": [ + "1-4-2" ], - "emea-esp-ccn-stic-825-2023": [ - "9" + "emea-sau-sama-csf-1-2017": [ + "3.1.5.1" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" + ], + "apac-aus-ism-2026-march": [ "ISM-0720", "ISM-0732" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "25", + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -209976,22 +215930,24 @@ "apac-jpn-ismap": [ "4.5.1.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], "apac-nzl-ism-3-9": [ "3.2.15.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.22" + "5.2.1", + "5.2.2" ], "americas-can-osfi-b13-2022": [ "1.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.3.1" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -210017,7 +215973,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to establish a:\n(1) Strategic security, compliance and resilience-specific business plan; and \n(2) Set of objectives to achieve that plan.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -210081,9 +216037,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -210146,10 +216102,12 @@ "7102(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(4)", - "3.2.1(5)(a)", - "3.2.1(5)(b)", - "3.2.1(5)(c)" + "3.2.1.4", + "3.2.2.5", + "3.2.2.5(a)", + "3.2.2.5(b)", + "3.2.2.5(c)", + "3.2.2.6" ], "emea-eu-dora-2023": [ "Article 6.8", @@ -210172,24 +216130,40 @@ "1.2(e)", "1.2(f)" ], + "emea-deu-c5-2020": [ + "SA-02-DOAR" + ], + "emea-isr-cmo-2-0": [ + "2.A", + "4.1, Stage 4", + "4.2, Stage 1.2" + ], "emea-sau-cscc-1-2019": [ - "1-1", "1-1-1" ], "emea-sau-ecc-1-2018": [ "1-1-1", - "1-1-2" + "1-1-2", + "1-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.1.2" - ], - "apac-aus-ism-2024-june": [ + "3.1.2", + "3.1.2.1", + "3.1.2.2", + "3.1.2.2.a", + "3.1.2.2.b", + "3.1.2.2.c", + "3.1.2.3", + "3.1.2.3.a", + "3.1.2.3.b", + "3.1.2.3.c" + ], + "apac-aus-ism-2026-march": [ "ISM-0039", "ISM-0720" ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "apac-aus-ps-cps-230-2023": [ + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -210197,21 +216171,21 @@ "apac-jpn-ismap": [ "5.1.1.2" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], "apac-nzl-ism-3-9": [ "2.3.25.C.01", "2.3.25.C.02", "2.3.29.C.01" ], - "apac-sgp-mas-trm-2021": [ - "3.1.4", - "3.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.7" - ], "americas-can-osfi-b13-2022": [ "1.2.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } }, @@ -210296,7 +216270,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -210313,14 +216288,20 @@ "general-iso-31000-2018": [ "5.4.4" ], - "apac-aus-ps-cps-234-2019": [ - "15" + "general-nist-cswp-39": [ + "6.5" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stages 2-3" + ], + "apac-aus-ps-cps-230-2023": [ + "27(b)" ], "apac-jpn-ismap": [ "4.4.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "apac-mys-bnm-rmit-2025": [ + "8.1" ], "americas-can-osfi-b13-2022": [ "1.2.1" @@ -210349,7 +216330,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.\n▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to address all capital planning and investment requests, including the resources needed to implement the Security, Compliance & Resilience Program (SCRP) and document all exceptions to this requirement.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to address all capital planning and investment requests, including the resources needed to implement the Security, Compliance & Resilience Program (SCRP) and document all exceptions to this requirement. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -210411,9 +216392,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -210513,8 +216494,8 @@ "general-nist-csf-2-0": [ "GV.RR-03" ], - "general-scf-dpmp-2025": [ - "11.0" + "general-nist-cswp-39": [ + "6.1" ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:GG2.GP3", @@ -210566,8 +216547,9 @@ "PM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.1(61)", - "3.6.1(62)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -210578,31 +216560,18 @@ "emea-deu-bsrit-2017": [ "2.3" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.8", - "17.9" - ], - "emea-sau-cscc-1-2019": [ - "1-1" - ], "emea-sau-ecc-1-2018": [ "1-1-3" ], "emea-sau-otcc-1-2022": [ - "1-4", - "1-4-1", - "1-4-1-1" + "1-4-2" ], - "apac-aus-ism-2024-june": [ - "ISM-0732" + "apac-aus-ism-2026-march": [ + "ISM-0732", + "ISM-2004" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "27(b)" ], "apac-jpn-ismap": [ "4.5.1.1", @@ -210612,18 +216581,7 @@ "3.2.15.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.5.1", - "5.5.2" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.22" + "5.1.4" ], "americas-can-osfi-b13-2022": [ "1.2.1" @@ -210635,7 +216593,7 @@ "title": "Prioritization To Address Evolving Risks & Threats", "family": "PRM", "description": "Mechanisms exist to integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize the organization's exposure to evolving risks and threats.", - "scf_question": "Does the organization integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize the organization's exposure to evolving risks and threats?", + "scf_question": "Does the organization integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize its exposure to evolving risks and threats?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -210707,7 +216665,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -210730,11 +216689,46 @@ "4.3.2", "6.3" ], + "general-nist-cswp-39": [ + "6.1" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.6.1.62", + "3.6.1.66" + ], + "emea-deu-c5-2020": [ + "SA-02-BP3" + ], + "emea-isr-cmo-2-0": [ + "2.D", + "4.1, Stage 4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-4" + ], + "emea-sau-otcc-1-2022": [ + "1-4-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2020" + ], + "apac-aus-ps-cps-230-2023": [ + "25", + "27(b)" + ], "apac-jpn-ismap": [ "4.5.5.3" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2" ] } }, @@ -210825,7 +216819,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -210961,10 +216956,10 @@ "SA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-2" @@ -210986,7 +216981,7 @@ "Article 17.1(l)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)" + "3.2.1.3" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -210997,23 +216992,21 @@ "emea-deu-bsrit-2017": [ "2.3" ], - "emea-isr-cmo-1-0": [ - "17.5" + "emea-isr-cmo-2-0": [ + "4.1, Stage 4" ], - "emea-sau-cscc-1-2019": [ - "1-1" + "emea-sau-otcc-1-2022": [ + "1-4-2" ], - "emea-sau-ecc-1-2018": [ - "1-6-4" + "emea-sau-sama-csf-1-2017": [ + "3.1.1.10" ], - "apac-aus-ism-2024-june": [ - "ISM-0732" + "apac-aus-ism-2026-march": [ + "ISM-0732", + "ISM-2020" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "15" + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -211023,11 +217016,7 @@ "4.5.5.3" ], "apac-sgp-mas-trm-2021": [ - "5.2.1", - "5.2.2" - ], - "amaericas-can-osfi-self-assessment": [ - "6.22" + "5.1.4" ], "americas-can-osfi-b13-2022": [ "1.2.1" @@ -211038,8 +217027,8 @@ "control_id": "PRM-04", "title": "Security, Compliance & Resilience In Project Management", "family": "PRM", - "description": "Mechanisms exist 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.", - "scf_question": "Does the organization 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?", + "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.", + "scf_question": "Does the organization 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?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -211148,9 +217137,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", + "errata": "- wordsmithed control", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -211273,15 +217263,18 @@ "general-nist-800-161-r1-level-3": [ "CA-2" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A06:2025" ], "general-pci-dss-4-0-1": [ "1.1" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-tisax-6-0-3": [ "1.2.3", "5.3.1" @@ -211325,20 +217318,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-02" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(14)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(f)", - "3.6.1(62)", - "3.6.1(61)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.3.1.10", + "3.3.1.13(f)", + "3.6.1.61", + "3.6.1.62", + "3.6.1.63", + "3.6.1.63(a)", + "3.6.1.63(b)", + "3.6.1.63(c)", + "3.6.1.63(d)", + "3.6.1.63(e)", + "3.6.1.63(f)", + "3.6.1.64", + "3.6.1.65", + "3.6.1.66", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -211354,42 +217352,53 @@ "7.2", "7.3" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.8", - "17.9" - ], "emea-sau-cscc-1-2019": [ - "1-3", - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-ecc-1-2018": [ - "1-6-1", - "1-6-4" + "1-5-2", + "1-6-1" ], "emea-sau-otcc-1-2022": [ - "1-4-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-74" + "1-4-1-1", + "1-4-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.1.5" + "3.1.5", + "3.1.5.1", + "3.1.5.2", + "3.1.5.2.a", + "3.1.5.2.b", + "3.1.5.2.c", + "3.1.5.2.d", + "3.1.5.2.e", + "3.1.5.2.f" + ], + "emea-esp-decree-311-2022": [ + "Article 16(1)" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1739" ], + "apac-aus-ps-cps-230-2023": [ + "25", + "27(b)" + ], "apac-jpn-ismap": [ "4.5.1.1", "6.1.5", "6.1.5.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.3", + "10.2", + "10.3", + "10.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP28", "HHSP31", @@ -211402,29 +217411,19 @@ ], "apac-sgp-mas-trm-2021": [ "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.8.1", - "5.8.2" - ], - "americas-bra-lgpd-2018": [ - "6.8" + "5.1.3" ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "americas-bmu-mba-coc-2020": [ + "5.14" ], "americas-can-osfi-b13-2022": [ "1.2.1", "2.3", "2.3.1", "2.4.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.3.1" ] } }, @@ -211432,8 +217431,8 @@ "control_id": "PRM-05", "title": "Security, Compliance & Resilience Requirements Definition", "family": "PRM", - "description": "Mechanisms exist to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC).", - "scf_question": "Does the organization identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC)?", + "description": "Mechanisms exist to proactively govern Technology Assets, Applications and/or Services (TAAS) by:\n(1) Defining technical security, compliance and resilience requirements; and\n(2) Performing a criticality analysis at predefined decision points in the Secure Development Life Cycle (SDLC).", + "scf_question": "Does the organization proactively govern Technology Assets, Applications and/or Services (TAAS) by:\n(1) Defining technical security, compliance and resilience requirements; and\n(2) Performing a criticality analysis at predefined decision points in the Secure Development Life Cycle (SDLC)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -211451,7 +217450,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC). ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -211525,9 +217524,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", + "errata": "- wordsmithed control", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -211662,6 +217662,21 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], + "general-nist-800-172-r3": [ + "03.11.10E", + "03.13.01E", + "03.13.02E", + "03.13.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.10E", + "A.03.13.01E.ODP[01]", + "A.03.13.02E.ODP[01]", + "A.03.13.03E.ODP[01]" + ], "general-nist-800-218": [ "PO.1", "PO.1.1" @@ -211672,9 +217687,6 @@ "general-pci-dss-4-0-1": [ "1.1" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-swift-cscf-2025": [ "2.8", "2.11A" @@ -211712,10 +217724,10 @@ "RA-09" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7100(b)" @@ -211724,10 +217736,8 @@ "Article 14.3(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.6.1.64", + "3.6.2.68" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -211741,47 +217751,38 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(a)" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.6" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" + "emea-deu-bsrit-2017": [ + "7.6" ], "emea-sau-cscc-1-2019": [ - "1-3-1-2", "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-ecc-1-2018": [ - "1-6-1" + "1-6-1", + "2-9-1" ], "emea-sau-otcc-1-2022": [ - "1-4-1", - "1-4-1-1", - "1-4-2" + "1-4-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-43" + "emea-esp-decree-311-2022": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.3 [OP.PL.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.pl.3", + "op.exp.1", + "mp.info.4", + "mp.s.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0720", "ISM-1739" ], + "apac-aus-ps-cps-230-2023": [ + "25" + ], "apac-jpn-ismap": [ "4.4.3.1", "4.4.5.2", @@ -211789,7 +217790,11 @@ "6.1.5.2", "14.1.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.3", + "10.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP28", "HHSP31", @@ -211807,22 +217812,13 @@ "12.1.32.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", "5.1.2", - "5.1.3", - "5.1.4", - "5.3.3", - "5.5.1", - "5.5.2", - "5.6.1", - "5.6.2", - "5.6.3" - ], - "apac-twn-pdpa-2025": [ - "27" + "5.4.2", + "5.4.3", + "5.5.1" ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "americas-bmu-mba-coc-2020": [ + "5.14" ], "americas-can-osfi-b13-2022": [ "1.2.1", @@ -211832,6 +217828,9 @@ "2.4.3", "2.8" ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -211919,9 +217918,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -212060,12 +218059,15 @@ "general-nist-800-161-r1-level-3": [ "PM-11" ], + "general-nist-800-172-r3": [ + "03.13.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.01E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-swift-cscf-2025": [ "2.8", "2.11A" @@ -212114,10 +218116,10 @@ "609.935(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "PM-11", @@ -212128,10 +218130,9 @@ "PM-11" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.3.2.15", + "3.6.1.64", + "3.6.2.68" ], "emea-eu-dora-2023": [ "Article 8.1" @@ -212139,14 +218140,15 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(a)" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.6" + "emea-deu-bsrit-2017": [ + "7.6" ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" + "emea-sau-ecc-1-2018": [ + "2-9-1" + ], + "emea-esp-decree-311-2022": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], "apac-jpn-ismap": [ "4.4.3.1", @@ -212156,6 +218158,9 @@ "13.1.2", "14.1.1.2" ], + "apac-mys-bnm-rmit-2025": [ + "10.2" + ], "apac-nzl-hisf-suppliers-2023": [ "HSUP27" ], @@ -212165,8 +218170,11 @@ "12.1.32.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.5.1", - "5.5.2" + "5.1.2", + "5.5.1" + ], + "americas-bmu-mba-coc-2020": [ + "6.9" ], "americas-can-osfi-b13-2022": [ "1.2.1", @@ -212175,6 +218183,9 @@ "2.4.1", "2.4.3", "2.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } }, @@ -212198,9 +218209,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -212295,7 +218306,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -212383,7 +218395,7 @@ "A.6.2.7", "A.6.2.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -212464,9 +218476,6 @@ "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-tisax-6-0-3": [ "5.3.1" ], @@ -212539,15 +218548,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-03" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(14)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(f)", - "3.5(55)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)" + "3.3.1.13(f)", + "3.5.55" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -212563,39 +218569,35 @@ "7.2", "7.3" ], - "emea-isr-cmo-1-0": [ - "17.4", - "17.5", - "17.8" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" - ], "emea-sau-cscc-1-2019": [ - "2-13-4" + "2-13-1" ], "emea-sau-cgiot-2024": [ "1-5-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-74" + "emea-sau-ecc-1-2018": [ + "1-5-3-1", + "1-5-3-2", + "1-5-3-3", + "1-5-3-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 8 (end)", - "Article 36" + "emea-sau-otcc-1-2022": [ + "1-4-1-1" ], - "emea-esp-decree-311-2022": [ - "36", - "8 (end)" + "emea-sau-sama-csf-1-2017": [ + "3.1.5" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "op.exp.5", + "mp.sw.1" + ], + "apac-aus-ism-2026-march": [ "ISM-1526", "ISM-1739" ], - "apac-aus-ps-cps-234-2019": [ - "21(c)" + "apac-aus-ps-cps-230-2023": [ + "25" ], "apac-ind-sebi-2024": [ "PR.IP.S2" @@ -212604,19 +218606,26 @@ "6.1.5.4", "14.1" ], + "apac-mys-bnm-rmit-2025": [ + "10.5" + ], "apac-sgp-mas-trm-2021": [ "5.1.2", - "5.1.3", - "5.1.4", "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4" + "5.4.4", + "5.5.2", + "5.8.1" + ], + "americas-bmu-mba-coc-2020": [ + "6.20" ], "americas-can-osfi-b13-2022": [ "2.4", "2.4.1", "2.4.3" + ], + "americas-can-osfi-self-assessment-2": [ + "2.4.1" ] } }, @@ -212640,7 +218649,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to manage the organizational knowledge of the security, compliance and resilience staff.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to manage the organizational knowledge of the security, compliance and resilience staff.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -212714,17 +218723,14 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-cobit-2019": [ "APO01.08" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "usa-federal-dhs-cisa-cpg-2-0": [ "1.D" ], @@ -212737,45 +218743,136 @@ } }, { - "control_id": "RSK-01", - "title": "Risk Management Program", - "family": "RSK", - "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls.", - "scf_question": "Does the organization facilitate the implementation of strategic, operational and tactical risk management controls?", - "relative_weight": 10, + "control_id": "QTS-01", + "title": "Quantum Risk Governance", + "family": "QTS", + "description": "Mechanisms exist to establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "scf_question": "Does the organization establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ - "E-RSK-01" + "E-QTS-01", + "E-QTS-02" ], "pptdf": "Process", - "nist_csf_function": "Govern", + "nist_csf_function": "Protect", "scrm_focus": { "strategic": true, "operational": true, - "tactical": true + "tactical": false }, "maturity": { "0": "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.", - "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", - "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to facilitate the implementation of strategic, operational and tactical risk management controls.", - "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "SCRMS", - "CORE AI Model Deployment", - "CORE ESP Level 1 Foundational", - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Awareness of NIST PQC standards (https://csrc.nist.gov/pqc)\n∙ Note: Formal quantum risk governance may not be cost-effective at this size; monitor NIST guidance", + "small": "∙ Designate a named lead responsible for tracking PQC developments\n∙ NIST Post-Quantum Cryptography standards awareness (https://csrc.nist.gov/pqc)", + "medium": "∙ Designated quantum migration lead within CISO function\n∙ NIST PQC standards alignment\n∙ Include quantum risk in enterprise risk register", + "large": "∙ Executive-sponsored quantum risk governance structure\n∙ Named migration lead with defined authority\n∙ NIST PQC and NSA CNSA 2.0 alignment\n∙ Quantum risk as standing agenda item in executive meetings", + "enterprise": "∙ Board-level quantum risk governance structure\n∙ NIST PQC standards and NSA CNSA 2.0 alignment\n∙ Dedicated PQC migration program team\n∙ Quantum risk integrated into enterprise risk management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-01.1", + "title": "Quantum Security Policy", + "family": "QTS", + "description": "Mechanisms exist to establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "scf_question": "Does the organization establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-GOV-08" ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], "possible_solutions": { - "micro_small": "∙ Risk Management Program (RMP)", - "small": "∙ Risk Management Program (RMP)", - "medium": "∙ Risk Management Program (RMP)", - "large": "∙ Risk Management Program (RMP)", - "enterprise": "∙ Risk Management Program (RMP)" + "micro_small": "∙ Reference NIST PQC standards in cryptography policy\n∙ Note: Standalone quantum security policy may not be required at this size", + "small": "∙ Addendum to existing cryptography policy covering quantum risks\n∙ NIST PQC reference (https://csrc.nist.gov/pqc)", + "medium": "∙ Formal quantum security policy\n∙ Annual review cycle aligned to NIST PQC updates\n∙ Integration with cryptography standard", + "large": "∙ Standalone quantum security policy with executive approval\n∙ Annual review and update cycle\n∙ Alignment to NIST PQC, NSA CNSA 2.0 and CISA PQC guidance", + "enterprise": "∙ Enterprise quantum security policy with board endorsement\n∙ Alignment to NIST, NSA, CISA, and applicable regulatory guidance\n∙ Integration with security policy framework" }, "risks": [ "R-AC-1", @@ -212803,13 +218900,10 @@ "R-GV-5", "R-GV-6", "R-GV-7", - "R-GV-8", "R-IR-1", "R-IR-2", "R-IR-3", "R-IR-4", - "R-SA-1", - "R-SA-2", "R-SC-1", "R-SC-2", "R-SC-3", @@ -212818,20 +218912,7 @@ "R-SC-6" ], "threats": [ - "NT-1", - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", "MT-1", "MT-2", "MT-3", @@ -212841,6 +218922,7 @@ "MT-7", "MT-8", "MT-9", + "MT-10", "MT-11", "MT-12", "MT-13", @@ -212849,125 +218931,3361 @@ "MT-16", "MT-17", "MT-18", - "MT-19", - "MT-20", - "MT-21", - "MT-22", - "MT-23", - "MT-24", - "MT-25", - "MT-27" + "MT-28" ], - "family_name": "Risk Management", + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-01.2", + "title": "Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization", + "family": "QTS", + "description": "Mechanisms exist to classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "scf_question": "Does the organization classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-03" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Identify data with long-term confidentiality requirements (e.g., legal, financial, health records)\n∙ Flag for priority PQC protection", + "medium": "∙ Data classification extended to include confidentiality shelf-life dimension\n∙ Prioritize PQC migration for long-lived sensitive data", + "large": "∙ Formal data shelf-life classification taxonomy\n∙ Integration with data catalog and PQC migration prioritization\n∙ Policy-driven PQC protection for long-lived data", + "enterprise": "∙ Automated data shelf-life classification\n∙ Integration with enterprise data catalog and PQC migration roadmap\n∙ Continuous monitoring of long-lived data for PQC readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-01.3", + "title": "Long-Lived Data Identification", + "family": "QTS", + "description": "Mechanisms exist to identify data with long-lived confidentiality protection requirements.", + "scf_question": "Does the organization identify data with long-lived confidentiality protection requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-03" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to identify data with long-lived confidentiality protection requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Review data retention schedules to identify long-lived sensitive records", + "medium": "∙ Data discovery tools to identify long-lived sensitive data\n∙ Data retention policy integration\n∙ Tag long-lived data in data catalog", + "large": "∙ Automated long-lived data identification via data discovery tools\n∙ Integration with DLP and data catalog\n∙ PQC priority mapping for identified data", + "enterprise": "∙ Enterprise data discovery and classification platform\n∙ Automated long-lived data tagging and PQC risk mapping\n∙ Continuous monitoring of data with long confidentiality requirements" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-01.4", + "title": "Harvest Now, Decrypt Later (HNDL) Mitigation", + "family": "QTS", + "description": "Mechanisms exist to mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control.", + "scf_question": "Does the organization mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-09" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Ensure TLS 1.3 is enforced for sensitive data in transit\n∙ Note: Full HNDL mitigation via ZTNA is typically not feasible at this size", + "small": "∙ Enforce TLS 1.3 for all sensitive communications\n∙ Minimize external exposure of long-lived sensitive data", + "medium": "∙ TLS 1.3 enforcement across all external-facing services\n∙ Data access minimization practices\n∙ Zero Trust Network Architecture (ZTNA) planning", + "large": "∙ Zero Trust Network Architecture (ZTNA) implementation\n∙ TLS 1.3 enforcement with forward secrecy\n∙ Identity-based access controls for sensitive data\n∙ Data microsegmentation", + "enterprise": "∙ Enterprise ZTNA platform (e.g., Zscaler, Netskope, Palo Alto Prisma Access)\n∙ Continuous authentication enforcement\n∙ Data microsegmentation with identity-aware access\n∙ HNDL risk monitoring and response program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-02", + "title": "Cryptographic Agility Risk Assessment (CARA)", + "family": "QTS", + "description": "Mechanisms exist to perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact.", + "scf_question": "Does the organization perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-06" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Inventory of cryptographic algorithms in use\n∙ Identification of quantum-vulnerable algorithms (RSA, ECDSA, DH)", + "medium": "∙ Structured CARA aligned to NIST guidance\n∙ Asset-level mapping of cryptographic algorithm use\n∙ Prioritization by business impact", + "large": "∙ Formal CARA process aligned to NIST IR 8547 or equivalent methodology\n∙ Integration with risk register and PQC migration planning", + "enterprise": "∙ Enterprise CARA program with automated cryptographic discovery\n∙ NIST IR 8547 methodology implementation\n∙ Integration with GRC platform and PQC migration roadmap" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", "crosswalks": { - "general-aicpa-tsc-2017": [ - "A1.2-POF1", - "CC3.1", - "CC3.2-POF1", - "CC3.2-POF3", - "CC3.2-POF5", - "CC3.4-POF1", - "CC3.4-POF2", - "CC3.4-POF3", - "CC3.4-POF4", - "CC3.4-POF5", - "CC4.1", - "CC5.1", - "CC9.1" - ], - "general-cis-csc-8-1": [ - "16.6" - ], - "general-cis-csc-8-1-ig2": [ - "16.6" - ], - "general-cis-csc-8-1-ig3": [ - "16.6" - ], - "general-cobit-2019": [ - "EDM03.01", - "EDM03.02", - "EDM03.03", - "APO12.01", - "APO12.02", - "APO12.03", - "APO12.04", - "APO12.05", - "APO12.06" - ], - "general-coso-2013": [ - "7", - "8", - "16" - ], - "general-csa-cmm-4-1-0": [ - "CEK-07", - "GRC-02" - ], - "general-csa-iot-2": [ - "RSM-01", - "RSM-02" - ], - "general-govramp": [ - "RA-01" - ], - "general-govramp-low": [ - "RA-01" - ], - "general-govramp-low-plus": [ - "RA-01" - ], - "general-govramp-mod": [ - "RA-01" - ], - "general-govramp-high": [ - "RA-01" - ], - "general-iec-tr-60601-4-5-2021": [ - "4.1" - ], - "general-iec-62443-2-1-2024": [ - "ORG 2.1" - ], - "general-imo-maritime-cyber-risk-management-2025": [ - "3.5", - "3.5.1" - ], - "general-iso-27001-2022": [ - "6.1.1", - "6.1.1(a)", - "6.1.1(b)", - "6.1.1(c)", - "6.1.1(d)", - "6.1.1(e)(1)", - "6.1.1(e)(2)", - "6.1.2", - "6.1.2(a)", - "6.1.2(a)(1)", - "6.1.2(a)(2)", - "6.1.2(b)", - "6.1.2(c)", - "6.1.2(c)(1)", - "6.1.2(c)(2)", - "6.1.2(d)", - "6.1.2(d)(1)", - "6.1.2(d)(2)", - "6.1.2(d)(3)", - "6.1.2(e)", - "6.1.2(e)(1)", - "6.1.2(e)(2)", - "8.2" - ], - "general-iso-27002-2022": [ - "7.5" - ], - "general-iso-27017-2015": [ - "11.1.4" - ], - "general-iso-27018-2025": [ - "7.5" + "general-nist-cswp-39": [ + "5" + ] + } + }, + { + "control_id": "QTS-02.1", + "title": "Cryptographic Exception Register", + "family": "QTS", + "description": "Mechanisms exist to govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date.", + "scf_question": "Does the organization govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-07" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Simple exception register for known quantum-vulnerable algorithm uses", + "medium": "∙ Cryptographic exception register with owner, compensating controls, and remediation dates\n∙ Integration with risk register", + "large": "∙ Formal cryptographic exception register\n∙ GRC platform integration\n∙ Regular review and escalation process for aged exceptions", + "enterprise": "∙ Enterprise cryptographic exception register within GRC platform\n∙ Automated exception tracking and escalation\n∙ Integration with PQC migration roadmap and compliance reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-02.2", + "title": "Compensating Controls for Quantum-Vulnerable Systems", + "family": "QTS", + "description": "Mechanisms exist to implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "scf_question": "Does the organization implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Network isolation of legacy systems using quantum-vulnerable algorithms\n∙ Shorten certificate validity periods", + "small": "∙ Network segmentation of quantum-vulnerable systems\n∙ Reduce key lifetimes for quantum-vulnerable certificates", + "medium": "∙ Network segmentation and additional authentication for quantum-vulnerable systems\n∙ Shortened key validity periods\n∙ Out-of-band key transport where applicable", + "large": "∙ Network micro-segmentation of quantum-vulnerable systems\n∙ Shortened key lifetimes and certificate validity periods\n∙ Pre-shared key (PSK) layers on quantum-vulnerable links\n∙ Data minimization on quantum-vulnerable paths", + "enterprise": "∙ Automated micro-segmentation of quantum-vulnerable systems\n∙ Enterprise PSK and data minimization controls\n∙ Continuous monitoring of quantum-vulnerable system exposure\n∙ Integration with PQC migration prioritization" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-02.3", + "title": "Crypto Agility Maturity Assessment", + "family": "QTS", + "description": "Mechanisms exist to measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "scf_question": "Does the organization measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Self-assessment against basic cryptographic agility criteria\n∙ NIST PQC readiness checklist", + "medium": "∙ Crypto agility maturity assessment against defined criteria\n∙ NIST or CISA PQC maturity model\n∙ Integration with annual security assessments", + "large": "∙ Formal crypto agility maturity assessment using NIST or CISA PQC maturity framework\n∙ Annual assessment with improvement roadmap", + "enterprise": "∙ Enterprise crypto agility maturity program\n∙ Third-party validated maturity assessments\n∙ Continuous maturity monitoring via GRC platform\n∙ Board-level reporting on crypto agility progress" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "6.5" + ] + } + }, + { + "control_id": "QTS-03", + "title": "Post-Quantum Cryptography Agility Plan (PSCAP)", + "family": "QTS", + "description": "Mechanisms exist to develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms.", + "scf_question": "Does the organization develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Basic PQC transition roadmap aligned to NIST PQC standards\n∙ NIST PQCAP guidance (https://csrc.nist.gov/pqc)", + "medium": "∙ Documented PQCAP aligned to NIST standards\n∙ Risk-prioritized migration roadmap\n∙ Integration with enterprise risk management", + "large": "∙ Formal PQCAP with executive sponsorship\n∙ Risk-prioritized migration with milestones\n∙ NIST PQC and NSA CNSA 2.0 alignment\n∙ Annual plan refresh", + "enterprise": "∙ Enterprise PQCAP with board visibility\n∙ Dedicated PQC program office\n∙ NIST, NSA CNSA 2.0, and CISA PQC guidance alignment\n∙ Integration with enterprise architecture and GRC" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "3", + "5", + "5.3", + "6" ], - "general-iso-27701-2025": [ + "apac-aus-ism-2026-march": [ + "ISM-1917", + "ISM-2073" + ] + } + }, + { + "control_id": "QTS-03.1", + "title": "Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support", + "family": "QTS", + "description": "Mechanisms exist to allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period.", + "scf_question": "Does the organization allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-11", + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor TLS library vendor support for PQC/hybrid modes\n∙ Plan transition for highest-risk systems first", + "medium": "∙ PQC algorithm support assessment for key systems\n∙ Hybrid cryptography pilot for critical services\n∙ Vendor roadmap review for PQC support", + "large": "∙ Hybrid cryptography deployment for critical services\n∙ TLS 1.3 with hybrid PQC key exchange pilot\n∙ Legacy system migration planning and resource allocation", + "enterprise": "∙ Enterprise hybrid cryptography deployment program\n∙ FIPS 140-3 validated PQC module adoption\n∙ Hybrid mode support across all external-facing services\n∙ Automated legacy system discovery and migration tracking" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-03.2", + "title": "Post-Quantum Cryptography (PQC) Migration Progress Oversight", + "family": "QTS", + "description": "Mechanisms exist to establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership.", + "scf_question": "Does the organization establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Note: Typically not required at this size; document any PQC migration progress informally", + "medium": "∙ PQC migration progress metrics\n∙ Inclusion in security program status reports", + "large": "∙ Executive dashboard for PQC migration progress\n∙ Milestone-based reporting aligned to PQCAP\n∙ Regular reporting to security leadership", + "enterprise": "∙ Board-level PQC migration progress reporting\n∙ Automated migration tracking in GRC platform\n∙ KPIs aligned to PQCAP milestones\n∙ Regulatory compliance reporting on PQC readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-03.3", + "title": "Post-Quantum Cryptography (PQC) Supply Chain Visibility", + "family": "QTS", + "description": "Mechanisms exist to require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "scf_question": "Does the organization require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04", + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Request PQC support roadmaps from key technology vendors\n∙ Include PQC readiness in vendor RFPs", + "medium": "∙ Vendor PQC readiness assessments as part of TPRM\n∙ Contractual requirements for PQC roadmap disclosure\n∙ Vendor questionnaires on quantum readiness", + "large": "∙ Formal vendor PQC disclosure requirements\n∙ PQC readiness as part of third-party risk assessments\n∙ Vendor roadmap tracking for critical suppliers", + "enterprise": "∙ Enterprise vendor PQC supply chain program\n∙ Automated vendor PQC tracking in TPRM platform\n∙ Contractual PQC disclosure requirements for all critical vendors\n∙ Regular supply chain quantum risk reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-03.4", + "title": "Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements", + "family": "QTS", + "description": "Mechanisms exist to require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "scf_question": "Does the organization require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-CPL-01" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "medium": "∙ Include PQC flow-down requirements in new vendor contracts\n∙ Reference NIST PQC standards in contract language", + "large": "∙ Formal PQC flow-down contract requirements\n∙ Supplier compliance verification\n∙ Integration with third-party risk management", + "enterprise": "∙ Enterprise PQC flow-down program\n∙ Automated contract requirement tracking\n∙ Subcontractor PQC compliance monitoring\n∙ Integration with supply chain risk management platform" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-04", + "title": "Post-Quantum Cryptography (PQC) Discovery & Visibility", + "family": "QTS", + "description": "Mechanisms exist to gain situational awareness into the organization’s current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques.", + "scf_question": "Does the organization gain situational awareness into its current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to gain situational awareness into the organization’s current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Manual cryptographic algorithm inventory\n∙ Free scanning tools for common quantum-vulnerable implementations", + "medium": "∙ Automated cryptographic discovery tools\n∙ Cryptographic inventory as part of vulnerability management\n∙ NIST guidance on cryptographic discovery (https://csrc.nist.gov/pqc)", + "large": "∙ Automated cryptographic discovery and inventory platform\n∙ Integration with asset management and vulnerability scanning\n∙ Regular cryptographic posture reporting", + "enterprise": "∙ Enterprise cryptographic discovery platform\n∙ Continuous cryptographic inventory maintenance\n∙ Integration with GRC, asset management, and SIEM\n∙ Automated quantum exposure reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "5" + ] + } + }, + { + "control_id": "QTS-04.1", + "title": "Post-Quantum Cryptography (PQC) Asset Inventory", + "family": "QTS", + "description": "Mechanisms exist to maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "scf_question": "Does the organization maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Spreadsheet-based cryptographic asset inventory\n∙ Document algorithms, key lengths, and associated systems", + "medium": "∙ Structured cryptographic asset inventory\n∙ FIPS validation status tracking\n∙ Integration with overall asset inventory", + "large": "∙ Formal cryptographic asset inventory with automated updates\n∙ FIPS 140-3 validation tracking\n∙ Integration with vulnerability management and asset management", + "enterprise": "∙ Enterprise cryptographic asset inventory platform\n∙ Automated discovery and inventory maintenance\n∙ FIPS 140-3 validation status integration\n∙ Continuous inventory accuracy monitoring" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-04.2", + "title": "Cryptographic Bill of Materials (CBOM)", + "family": "QTS", + "description": "Mechanisms exist to develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing the organization's cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols.", + "scf_question": "Does the organization develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing its cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-05" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing the organization's cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "medium": "∙ Software Composition Analysis (SCA) tools to identify cryptographic library usage\n∙ Manual CBOM for critical applications", + "large": "∙ SCA platform with cryptographic library identification\n∙ CBOM generation for critical systems\n∙ Integration with SBOM processes", + "enterprise": "∙ Enterprise CBOM generation platform\n∙ Integration with SCA and SBOM tooling\n∙ Automated cryptographic dependency tracking\n∙ CBOM as input to PQC migration prioritization" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2082", + "ISM-2083" + ] + } + }, + { + "control_id": "QTS-04.3", + "title": "Post-Quantum Cryptography Exposure", + "family": "QTS", + "description": "Mechanisms exist to maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "scf_question": "Does the organization maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-10" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Identify systems using quantum-vulnerable public key algorithms (RSA, ECDSA, DH)\n∙ Prioritize based on data sensitivity", + "medium": "∙ Inventory of systems with PQC exposure\n∙ Risk-based prioritization of exposed systems\n∙ Integration with vulnerability management", + "large": "∙ Formal PQC exposure inventory\n∙ Automated scanning for quantum-vulnerable algorithm use\n∙ Risk-prioritized remediation planning", + "enterprise": "∙ Continuous PQC exposure monitoring\n∙ Enterprise scanning for quantum-vulnerable implementations\n∙ Automated risk prioritization and remediation tracking\n∙ Board-level PQC exposure reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-05", + "title": "Quantum Security Awareness", + "family": "QTS", + "description": "Mechanisms exist to deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles.", + "scf_question": "Does the organization deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-SAT-05" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Include quantum threat awareness in annual security training\n∙ NIST PQC awareness resources (https://csrc.nist.gov/pqc)", + "medium": "∙ Differentiated quantum security awareness content by role\n∙ General workforce awareness module\n∙ Technical team PQC training", + "large": "∙ Role-specific quantum security awareness program (workforce, technical, leadership)\n∙ Integration with annual security awareness platform", + "enterprise": "∙ Enterprise quantum security awareness program\n∙ Differentiated content for workforce, technical, and leadership roles\n∙ Annual training refresh aligned to NIST and regulatory updates\n∙ Integration with Learning Management System (LMS)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-05.1", + "title": "Quantum Threat Intelligence Monitoring", + "family": "QTS", + "description": "Mechanisms exist to maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists.", + "scf_question": "Does the organization maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-10", + "E-THR-03" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subscribe to NIST and CISA PQC update notifications (https://csrc.nist.gov/pqc)", + "small": "∙ NIST and CISA PQC update subscriptions\n∙ Relevant industry group newsletters or alerts", + "medium": "∙ Dedicated quantum threat intelligence monitoring\n∙ NIST, CISA, and NSA PQC guidance tracking\n∙ Industry-specific quantum security working groups", + "large": "∙ Quantum threat intelligence function within threat intelligence program\n∙ Monitoring of cryptanalytic advances and quantum computing milestones\n∙ NIST algorithm update tracking", + "enterprise": "∙ Dedicated quantum threat intelligence capability\n∙ Monitoring of academic, regulatory, and vendor quantum developments\n∙ Integration with enterprise threat intelligence platform\n∙ Regular quantum threat briefings to leadership" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-05.2", + "title": "Collaboration & Information Sharing", + "family": "QTS", + "description": "Mechanisms exist to ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk.", + "scf_question": "Does the organization ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor outputs from sector-specific quantum security working groups\n∙ CISA and NIST information-sharing resources", + "medium": "∙ Participation in sector-appropriate quantum security working groups\n∙ ISAC membership where relevant\n∙ CISA PQC working group engagement", + "large": "∙ Active participation in quantum security forums and ISACs\n∙ NIST PQC working group engagement\n∙ Cross-sector information sharing on quantum threats", + "enterprise": "∙ Enterprise participation in quantum security forums\n∙ ISAC and government information sharing partnerships\n∙ Active contribution to quantum security standards development\n∙ Public-private partnership engagement on quantum readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06", + "title": "Crypto-Agility Architecture", + "family": "QTS", + "description": "Mechanisms exist to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "scf_question": "Does the organization validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Use cloud-native cryptographic services with configurable algorithm support\n∙ Avoid hardcoded cryptographic algorithm dependencies", + "medium": "∙ Design systems for cryptographic algorithm replaceability\n∙ Crypto-agility requirements in architecture reviews\n∙ Abstraction of cryptographic operations from application logic", + "large": "∙ Crypto-agility architecture validation in design reviews\n∙ Cryptographic abstraction layer requirements\n∙ Support for PQC key and signature sizes in protocols and libraries", + "enterprise": "∙ Enterprise crypto-agility architecture program\n∙ Formal agility validation across protocols, libraries and hardware\n∙ Cryptographic abstraction APIs enforced organization-wide\n∙ Automated architecture compliance checking" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "4", + "5.4", + "6.2", + "6.3", + "6.4" + ] + } + }, + { + "control_id": "QTS-06.1", + "title": "Entropy Source & Random Bit Generation", + "family": "QTS", + "description": "Mechanisms exist to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation.", + "scf_question": "Does the organization use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use OS and cloud provider cryptographically secure random number generators\n∙ Avoid custom entropy implementations", + "small": "∙ Cryptographically secure PRNG from OS or validated cryptographic libraries\n∙ NIST SP 800-90B guidance (https://csrc.nist.gov)", + "medium": "∙ FIPS 140-3 validated entropy sources\n∙ Hardware Security Module (HSM) with validated RNG\n∙ NIST SP 800-90B compliance", + "large": "∙ FIPS 140-3 validated HSMs for key generation\n∙ Validated entropy sources aligned to NIST SP 800-90B\n∙ Enterprise key management platform", + "enterprise": "∙ Enterprise HSM infrastructure with FIPS 140-3 validated entropy\n∙ Quantum random number generators (QRNG) for enhanced entropy\n∙ Centralized key management platform\n∙ Continuous entropy source validation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.2", + "title": "Stateful Hash-Based Signatures for Firmware & Code Signing", + "family": "QTS", + "description": "Mechanisms exist to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases.", + "scf_question": "Does the organization enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use vendor-managed firmware signing", + "small": "∙ Use vendor-managed firmware signing", + "medium": "∙ Review code signing infrastructure for quantum vulnerability\n∙ Plan migration to hash-based signatures for critical firmware\n∙ NIST SP 800-208 guidance (https://csrc.nist.gov)", + "large": "∙ Hash-based signature scheme deployment for firmware signing\n∙ NIST SP 800-208 compliance for firmware and code signing\n∙ State-management controls to prevent key reuse", + "enterprise": "∙ Enterprise hash-based signature infrastructure for firmware and code signing\n∙ NIST SP 800-208 compliant implementation\n∙ Automated state management to prevent one-time key reuse\n∙ HSM-backed hash-based key management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.3", + "title": "Approved Post-Quantum Cryptography (PQC) Algorithm Use", + "family": "QTS", + "description": "Mechanisms exist to define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).", + "scf_question": "Does the organization define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Monitor NIST PQC algorithm approvals (https://csrc.nist.gov/pqc)\n∙ Adopt approved PQC algorithms as available in consumed services", + "small": "∙ Reference NIST PQC approved algorithms in cryptography policy\n∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)", + "medium": "∙ Define approved PQC algorithm list\n∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) adoption\n∙ FIPS 140-3 validated module requirements", + "large": "∙ Formal approved PQC algorithm standard\n∙ NIST FIPS 203/204/205 compliant implementations\n∙ Required validation levels in cryptography policy\n∙ Algorithm approval workflow for exceptions", + "enterprise": "∙ Enterprise approved PQC algorithm governance\n∙ NIST FIPS 203/204/205 and CNSA 2.0 alignment\n∙ Automated algorithm compliance enforcement\n∙ Integration with cryptographic exception register" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1990", + "ISM-1991", + "ISM-1992", + "ISM-1993", + "ISM-1994", + "ISM-1995" + ] + } + }, + { + "control_id": "QTS-06.4", + "title": "Post-Quantum Cryptography (PQC) Validation Requirements", + "family": "QTS", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use cloud provider services with FIPS 140-3 validated cryptographic modules\n∙ Prefer managed services over self-hosted cryptography", + "small": "∙ Use FIPS 140-3 validated cryptographic libraries and services\n∙ NIST CMVP validation list (https://csrc.nist.gov/projects/cryptographic-module-validation-program)", + "medium": "∙ FIPS 140-3 validated module requirements for cryptographic operations\n∙ Track NIST CMVP PQC validation certificates\n∙ Policy mandate for validated modules where applicable", + "large": "∙ Enterprise policy requiring FIPS 140-3 validated modules\n∙ Validation tracking in cryptographic asset inventory\n∙ HSM with FIPS 140-3 validation for key management", + "enterprise": "∙ Enterprise FIPS 140-3 validation requirement enforcement\n∙ Automated validation status tracking in cryptographic inventory\n∙ HSM infrastructure with FIPS 140-3 Level 3 validation\n∙ Continuous compliance monitoring for cryptographic module validation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.5", + "title": "Deprecated Cryptographic Algorithms", + "family": "QTS", + "description": "Mechanisms exist to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.", + "scf_question": "Does the organization identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Disable RC4, DES, 3DES and MD5 in systems and services\n∙ Enforce TLS 1.2 minimum (disable TLS 1.0/1.1)\n∙ Reference NIST SP 800-131A for deprecated algorithm guidance", + "small": "∙ Deprecated algorithm disablement per NIST SP 800-131A\n∙ TLS 1.2 minimum enforcement\n∙ Retire RSA-1024 and similar weak key sizes", + "medium": "∙ Deprecated algorithm disablement across all systems\n∙ NIST SP 800-131A and SP 800-57 compliance\n∙ Vulnerability scanning for deprecated algorithm detection", + "large": "∙ Formal deprecated algorithm disablement program\n∙ Automated scanning for deprecated cryptographic use\n∙ NIST SP 800-131A compliance tracking", + "enterprise": "∙ Enterprise deprecated algorithm removal program\n∙ Automated detection and alerting for deprecated algorithm use\n∙ NIST SP 800-131A and CNSA 2.0 compliance enforcement\n∙ Continuous monitoring for deprecated algorithm introduction" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "5.2" + ] + } + }, + { + "control_id": "QTS-06.6", + "title": "Post-Quantum Cryptography (PQC) Key Management", + "family": "QTS", + "description": "Mechanisms exist to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources.", + "scf_question": "Does the organization manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Shorten TLS certificate validity periods (e.g., 90-day certificates)\n∙ Let's Encrypt for automated short-lived certificate management (https://letsencrypt.org)", + "small": "∙ 90-day certificate validity enforcement\n∙ Automated certificate lifecycle management\n∙ Let's Encrypt or ACME protocol (https://letsencrypt.org)", + "medium": "∙ Shortened certificate validity periods per PQC guidance\n∙ Certificate lifecycle management platform\n∙ PKI preparation for PQC roots of trust", + "large": "∙ Enterprise certificate lifecycle management with shortened validity periods\n∙ PKI infrastructure preparation for PQC transition\n∙ HSM-backed key generation with quantum-safe entropy", + "enterprise": "∙ Enterprise PKI with PQC-ready architecture\n∙ Automated certificate lifecycle management (e.g., Venafi, Keyfactor)\n∙ HSM infrastructure with quantum-safe entropy sources\n∙ Dual-root hybrid trust model support" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.7", + "title": "Quantum-Safe Public Key Infrastructure (PKI) Transition", + "family": "QTS", + "description": "Mechanisms exist to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.", + "scf_question": "Does the organization transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Rely on cloud provider and CA/Browser Forum quantum-safe transitions", + "small": "∙ Monitor CA/Browser Forum and browser vendor PQC adoption timelines\n∙ Plan reliance on public CA quantum-safe transition", + "medium": "∙ Assess internal PKI for PQC transition readiness\n∙ Evaluate hybrid certificate support in PKI platforms\n∙ Certificate authority PQC roadmap review", + "large": "∙ Internal PKI PQC transition plan\n∙ Hybrid certificate deployment for critical services\n∙ Trust anchor migration planning to quantum-safe algorithms", + "enterprise": "∙ Enterprise quantum-safe PKI transition program\n∙ Hybrid certificate infrastructure deployment\n∙ Trust anchor migration to NIST FIPS 203/204/205 algorithms\n∙ Integration with enterprise certificate lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.8", + "title": "Algorithm Negotiation Integrity", + "family": "QTS", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Enforce TLS 1.3 (includes transcript integrity protection)\n∙ Disable TLS 1.0/1.1 and weak cipher suites", + "small": "∙ TLS 1.3 enforcement\n∙ Disable deprecated cipher suites\n∙ Monitor for TLS downgrade attempts via web application firewall", + "medium": "∙ TLS 1.3 with strong cipher suite enforcement\n∙ Monitoring for algorithm downgrade attempts\n∙ Disallow classical-only cipher suite negotiation where PQC is deployed", + "large": "∙ TLS 1.3 enforcement with integrity-protected handshake\n∙ Algorithm downgrade monitoring and alerting\n∙ Cipher suite allowlisting across enterprise TLS infrastructure", + "enterprise": "∙ Enterprise TLS cipher suite governance with automated enforcement\n∙ Algorithm negotiation integrity monitoring at scale\n∙ Automated detection of downgrade attempts\n∙ Integration with network security monitoring and SIEM" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.9", + "title": "Hybrid / Composite Cryptography", + "family": "QTS", + "description": "Mechanisms exist to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.", + "scf_question": "Does the organization leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor TLS library and browser vendor hybrid PQC support\n∙ Plan adoption of hybrid modes when widely available", + "medium": "∙ Pilot hybrid cryptography for highest-risk external-facing services\n∙ IETF hybrid draft standards monitoring\n∙ Vendor hybrid mode support assessment", + "large": "∙ Hybrid cryptography deployment for critical services\n∙ ECDH + ML-KEM hybrid KEM support\n∙ Hybrid certificate testing and deployment", + "enterprise": "∙ Enterprise hybrid cryptography deployment program\n∙ Hybrid KEM (ECDH + ML-KEM) and hybrid signatures (ECDSA + ML-DSA)\n∙ PKI infrastructure supporting dual-key/dual-certificate models\n∙ Plan for classical algorithm sunset post-PQC confidence" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1996" + ] + } + }, + { + "control_id": "QTS-06.10", + "title": "Cryptographic Application Programming Interface (API) Abstraction", + "family": "QTS", + "description": "Mechanisms exist to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "scf_question": "Does the organization use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Use established cryptographic libraries with abstraction (e.g., OpenSSL, BouncyCastle)\n∙ Avoid direct algorithm calls; use library-level interfaces", + "medium": "∙ Cryptographic abstraction requirements in development standards\n∙ Use of crypto-agility compatible libraries\n∙ Abstract cryptographic operations from application code", + "large": "∙ Enterprise cryptographic API abstraction standard\n∙ Use of PKCS#11 or equivalent for hardware abstraction\n∙ Crypto abstraction layer in enterprise development frameworks", + "enterprise": "∙ Enterprise cryptographic API abstraction framework\n∙ Universal cryptographic interface standard across all applications\n∙ PKCS#11 and provider-based abstraction architecture\n∙ Automated compliance checking for cryptographic abstraction" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-07", + "title": "Cryptographic Incident Response (Emergency Algorithm Transition)", + "family": "QTS", + "description": "Mechanisms exist to establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios.", + "scf_question": "Does the organization establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-12" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Maintain vendor and CA contacts for certificate revocation emergencies\n∙ Basic plan for replacing compromised certificates", + "medium": "∙ Emergency certificate replacement procedures\n∙ Pre-identified algorithm alternates in security runbook\n∙ Integration with incident response plan", + "large": "∙ Formal cryptographic incident response plan\n∙ Pre-identified algorithm alternates with tested rollback procedures\n∙ Customer/counterparty communication templates\n∙ Integration with enterprise incident response", + "enterprise": "∙ Enterprise cryptographic incident response program\n∙ Tested emergency algorithm transition procedures\n∙ 24/7 incident response capability for cryptographic emergencies\n∙ Regular cryptographic incident response exercises" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-08", + "title": "PQC Implementation Validation & Interoperability Testing", + "family": "QTS", + "description": "Mechanisms exist to validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions.", + "scf_question": "Does the organization validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Verify PQC implementations using NIST test vectors (https://csrc.nist.gov/pqc)\n∙ Use FIPS 140-3 validated modules where available", + "medium": "∙ PQC implementation testing using NIST test vectors\n∙ Interoperability testing with key counterparties\n∙ FIPS 140-3 validated module requirement", + "large": "∙ Formal PQC implementation validation program\n∙ Interoperability testing with counterparties and successors\n∙ Performance testing for PQC use cases\n∙ Test result documentation", + "enterprise": "∙ Enterprise PQC implementation validation framework\n∙ Automated test vector validation\n∙ Continuous interoperability testing with ecosystem partners\n∙ Third-party validation for critical implementations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "RSK-01", + "title": "Risk Management Program", + "family": "RSK", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "scf_question": "Does the organization facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) its Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices?", + "relative_weight": 10, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-RSK-01" + ], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to facilitate the implementation of strategic, operational and tactical risk management controls.", + "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "SCRMS", + "CORE AI Model Deployment", + "CORE ESP Level 1 Foundational", + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Risk Management Program (RMP)", + "small": "∙ Risk Management Program (RMP)", + "medium": "∙ Risk Management Program (RMP)", + "large": "∙ Risk Management Program (RMP)", + "enterprise": "∙ Risk Management Program (RMP)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-1", + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- wordsmithed control", + "family_name": "Risk Management", + "crosswalks": { + "general-aicpa-tsc-2017": [ + "A1.2-POF1", + "CC3.1", + "CC3.2-POF1", + "CC3.2-POF3", + "CC3.2-POF5", + "CC3.4-POF1", + "CC3.4-POF2", + "CC3.4-POF3", + "CC3.4-POF4", + "CC3.4-POF5", + "CC4.1", + "CC5.1", + "CC9.1" + ], + "general-cis-csc-8-1": [ + "16.6" + ], + "general-cis-csc-8-1-ig2": [ + "16.6" + ], + "general-cis-csc-8-1-ig3": [ + "16.6" + ], + "general-cobit-2019": [ + "EDM03.01", + "EDM03.02", + "EDM03.03", + "APO12.01", + "APO12.02", + "APO12.03", + "APO12.04", + "APO12.05", + "APO12.06" + ], + "general-coso-2013": [ + "7", + "8", + "16" + ], + "general-csa-cmm-4-1-0": [ + "CEK-07", + "GRC-02" + ], + "general-csa-iot-2": [ + "RSM-01", + "RSM-02" + ], + "general-govramp": [ + "RA-01" + ], + "general-govramp-low": [ + "RA-01" + ], + "general-govramp-low-plus": [ + "RA-01" + ], + "general-govramp-mod": [ + "RA-01" + ], + "general-govramp-high": [ + "RA-01" + ], + "general-iec-tr-60601-4-5-2021": [ + "4.1" + ], + "general-iec-62443-2-1-2024": [ + "ORG 2.1" + ], + "general-imo-maritime-cyber-risk-management-2025": [ + "3.5", + "3.5.1" + ], + "general-iso-27001-2022": [ + "6.1.1", + "6.1.1(a)", + "6.1.1(b)", + "6.1.1(c)", + "6.1.1(d)", + "6.1.1(e)(1)", + "6.1.1(e)(2)", + "6.1.2", + "6.1.2(a)", + "6.1.2(a)(1)", + "6.1.2(a)(2)", + "6.1.2(b)", + "6.1.2(c)", + "6.1.2(c)(1)", + "6.1.2(c)(2)", + "6.1.2(d)", + "6.1.2(d)(1)", + "6.1.2(d)(2)", + "6.1.2(d)(3)", + "6.1.2(e)", + "6.1.2(e)(1)", + "6.1.2(e)(2)", + "8.2" + ], + "general-iso-27002-2022": [ + "7.5" + ], + "general-iso-27017-2015": [ + "11.1.4" + ], + "general-iso-27018-2025": [ + "7.5" + ], + "general-iso-27701-2025": [ "6.1.2" ], "general-iso-31000-2018": [ @@ -213104,9 +222422,12 @@ ], "general-nist-800-171-r3": [ "03.11.01.a", - "03.17.01.a" + "03.17.01.a", + "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", "A.03.17.03.b" ], "general-nist-csf-2-0": [ @@ -213133,9 +222454,6 @@ "general-pci-dss-4-0-1": [ "12.3" ], - "general-scf-dpmp-2025": [ - "9.0" - ], "general-tisax-6-0-3": [ "1.4.1" ], @@ -213198,12 +222516,12 @@ "314.4(b)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "PM-9", @@ -213259,15 +222577,14 @@ "Article 17.1(g)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(7)", - "3.3.1(10)", - "3.3.1(13)(a)", - "3.3.1(13)(b)", - "3.3.1(13)(c)", - "3.3.1(13)(d)", - "3.3.1(13)(e)", - "3.3.1(13)(f)", - "3.3.1(14)" + "3.2.3.7", + "3.3.1.10", + "3.3.1.13", + "3.3.1.13(d)", + "3.3.1.13(e)", + "3.3.1.13(f)", + "3.3.1.14", + "3.3.4.23" ], "emea-eu-dora-2023": [ "Article 6.1", @@ -213311,37 +222628,20 @@ "7.1", "7.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "3.1", "3.2", - "3.3", - "3.4", - "3.5", - "3.6", - "3.7", - "3.8", - "3.9", - "3.10", - "3.11", - "12.3" + "3.5" ], "emea-deu-c5-2020": [ - "OIS-06" + "OIS-06", + "OIS-07" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.1", - "2.2" + "emea-isr-cmo-2-0": [ + "3" ], "emea-sau-cscc-1-2019": [ - "1-2" + "1-2-1" ], "emea-sau-cgiot-2024": [ "1-4-1" @@ -213352,26 +222652,38 @@ "1-5-4" ], "emea-sau-otcc-1-2022": [ - "1-3", - "1-3-1", - "1-3-1-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "1-3-1" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 7.1", - "Article 7.2" + "3.2.1", + "3.2.1.1-1", + "3.2.1.2-1", + "3.2.1.3-1", + "3.2.1.4-1", + "3.2.1.5", + "3.2.1.5.a", + "3.2.1.5.b", + "3.2.1.5.c", + "3.2.1.6", + "3.2.1.6.a", + "3.2.1.6.b", + "3.2.1.6.c", + "3.2.1.6.d", + "3.2.1.7", + "3.2.1.8", + "3.2.1.8.a", + "3.2.1.8.b", + "3.2.1.8.c", + "3.2.1.8.d" ], "emea-esp-decree-311-2022": [ - "7.1", - "7.2" + "Article 7(2)", + "Article 12(6)(b)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" ], "emea-gbr-caf-4-0": [ "A2", @@ -213397,26 +222709,12 @@ "1201", "1204" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0726" ], "apac-aus-ps-cps-230-2023": [ - "12(a)", - "12(c)", - "13", - "16(a)", - "16(b)", - "16(c)", - "16(d)", - "16(e)", - "16(f)", - "17", - "18", - "19(a)", - "19(b)", - "19(c)", - "19(d)", - "19(e)" + "16", + "16(d)" ], "apac-ind-sebi-2024": [ "GV.RM.S1" @@ -213426,7 +222724,14 @@ "4.5.5.2", "4.8.1.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "9.1", + "9.2", + "9.3", + "11.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP30", "HML30" ], @@ -213441,20 +222746,16 @@ "5.3.9.C.01" ], "apac-sgp-mas-trm-2021": [ + "3.1.4", + "3.1.7(a)", "4.1.1", - "4.1.2", + "4.1.4", + "4.1.4(d)", "4.1.5" ], "americas-bmu-mba-coc-2020": [ "5.3", - "5.8" - ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "6.4", - "6.8", - "6.16", - "6.24" + "5.11-BP1" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -213462,9 +222763,15 @@ "1.3.2", "3.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.1", + "1.3.2", + "3.1.8" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", - "03.17.01.A" + "03.17.01.A", + "03.17.03.B" ] } }, @@ -213491,7 +222798,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify:\n(1) Assumptions affecting risk assessments, risk response and risk monitoring;\n(2) Constraints affecting risk assessments, risk response and risk monitoring;\n(3) The organizational risk tolerance; and\n(4) Priorities, benefits and trade-offs considered by the organization for managing risk.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -213566,7 +222873,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -213755,10 +223063,10 @@ "609.930(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(a)", @@ -213772,9 +223080,7 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.6.1(66)", - "3.7.2(82)" + "3.3.1.10" ], "emea-eu-dora-2023": [ "Article 8.2" @@ -213782,12 +223088,18 @@ "emea-eu-nis2-annex-2024": [ "2.1.2(c)" ], - "emea-isr-cmo-1-0": [ - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.1" ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" + "emea-esp-decree-311-2022": [ + "Article 14(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" + ], + "apac-aus-ps-cps-230-2023": [ + "16(b)", + "27" ], "apac-jpn-ismap": [ "4.4.6.1", @@ -213799,20 +223111,16 @@ "23.2.17.C.01" ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.3.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.15", - "6.24" + "4.2.1" ], "americas-can-osfi-b13-2022": [ "1.3", "3.1.8" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" ] @@ -213836,7 +223144,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -213920,7 +223228,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -213968,7 +223277,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk tolerance, the specified range of acceptable results.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -214058,7 +223367,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -214115,13 +223425,19 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "2.1.2(b)" ], + "emea-deu-c5-2020": [ + "OIS-07-DOAR" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.11" + ], "apac-aus-ps-cps-230-2023": [ - "26" + "16(b)" ], "apac-ind-sebi-2024": [ "GV.RM.S4" @@ -214129,8 +223445,20 @@ "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "11.2" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(d)", + "4.4.2" + ], "americas-can-osfi-b13-2022": [ "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } }, @@ -214154,7 +223482,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -214244,7 +223572,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -214284,19 +223613,23 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "13.2.2(b)" ], - "apac-aus-ps-cps-230-2023": [ - "26" - ], "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-sgp-mas-trm-2021": [ + "4.4.2" + ], "americas-can-osfi-b13-2022": [ "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } }, @@ -214410,7 +223743,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -214459,17 +223793,23 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(a)" + "3.3.1.10", + "3.3.1.13(a)" ], "emea-eu-nis2-annex-2024": [ "2.1.2(b)" ], + "emea-deu-c5-2020": [ + "OIS-07-DOAR" + ], "emea-sau-cgiot-2024": [ "1-4-5" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.11" + ], "apac-aus-ps-cps-230-2023": [ - "26" + "16(b)" ], "apac-ind-sebi-2024": [ "GV.RM.S4" @@ -214477,9 +223817,20 @@ "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.5", + "3.1.7(d)" + ], "americas-can-osfi-b13-2022": [ "1.3", "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } }, @@ -214506,7 +223857,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to categorize TAASD in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -214580,7 +223931,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -214669,6 +224021,9 @@ "general-nist-800-171-r3": [ "03.11.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a" + ], "general-nist-csf-2-0": [ "ID.AM" ], @@ -214730,10 +224085,10 @@ "RA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-cms-marse-2-0": [ "RA-2", @@ -214760,18 +224115,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "RA-02" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" - ], - "apac-sgp-mas-trm-2021": [ - "4.2.1" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" @@ -214873,7 +224218,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -214918,6 +224264,10 @@ "03.11.01.a", "03.14.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.14.03.a" + ], "general-nist-csf-2-0": [ "ID.RA-05", "ID.RA-06" @@ -214939,25 +224289,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.9(b)(3)" ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "apac-nzl-ism-3-9": [ "23.2.16.C.01", "23.2.17.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.3.1", - "4.3.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.14.03.B" @@ -214986,7 +224324,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and document risks, both internal and external.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and document risks, both internal and external. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -215061,7 +224399,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -215199,10 +224538,10 @@ "314.4(c)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(b)(1)" @@ -215218,9 +224557,9 @@ "Article 9.2(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "emea-eu-dora-2023": [ "Article 8.2" @@ -215230,31 +224569,25 @@ "2.1.2(d)" ], "emea-deu-c5-2020": [ - "SP-03" + "OIS-03-DOAR", + "OIS-07" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.1" ], "emea-sau-cgiot-2024": [ "1-1-2", "1-4-1", "1-4-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.1" + "3.2.1.4-1.a", + "3.2.1.1-2", + "3.2.1.1-2.1", + "3.2.1.1-2.3" ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.2" - ], - "emea-esp-decree-311-2022": [ - "3.2" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], "emea-gbr-cap-1850-2020": [ "A2" @@ -215271,13 +224604,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1200" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1526" ], + "apac-aus-ps-cps-230-2023": [ + "13", + "16(d)" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], "apac-nzl-ism-3-9": [ "2.4.13.C.01", "2.4.13.C.02", @@ -215288,14 +224628,12 @@ "2.4.13.C.07" ], "apac-sgp-mas-trm-2021": [ - "4.1.3", - "4.1.4(a)" + "4.1.4(a)", + "4.2.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "5.3-BP1", + "5.5-BP1" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -215381,7 +224719,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -215403,14 +224742,12 @@ "TASK 2-1" ], "general-nist-800-171-r3": [ + "03.11.01.a", "03.15.02.a.03" ], "general-nist-800-171a-r3": [ "A.03.11.01.a" ], - "general-nist-800-172": [ - "3.11.5e" - ], "general-nist-csf-2-0": [ "ID" ], @@ -215437,10 +224774,10 @@ "609.930(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(a)", @@ -215458,21 +224795,138 @@ "emea-deu-bsrit-2017": [ "3.3" ], + "emea-deu-c5-2020": [ + "OIS-03-DOAR" + ], "emea-sau-cgiot-2024": [ "1-4-2", "1-4-4" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.1-2.2" + ], "apac-jpn-ismap": [ "4.4.7.2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-mas-trm-2021": [ + "4.2.1" + ], "americas-can-osfi-b13-2022": [ "3.1.1" ], "americas-can-itsp-10-171-2025": [ + "03.11.01.A", "03.15.02.A.03" ] } }, + { + "control_id": "RSK-03.2", + "title": "Risk Owner", + "family": "RSK", + "description": "Mechanisms exist to identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks.", + "scf_question": "Does the organization identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks?", + "relative_weight": 9, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Risk register with assigned owner column\n∙ Designated security lead responsible for risk follow-up", + "small": "∙ Risk register with mandatory owner assignment\n∙ Regular risk owner check-ins on remediation progress", + "medium": "∙ Formal risk ownership assignment in risk register\n∙ GRC platform with risk owner workflow\n∙ Management accountability for open risk items", + "large": "∙ GRC platform with risk ownership and accountability workflow\n∙ Executive reporting on risk owner compliance\n∙ Risk owner training and awareness", + "enterprise": "∙ Enterprise GRC platform with risk ownership management\n∙ Automated risk owner escalation and reminders\n∙ Board-level reporting on material risk accountability\n∙ Risk ownership integrated into performance management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-17", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - RMiT", + "family_name": "Risk Management", + "crosswalks": { + "emea-deu-bsrit-2017": [ + "3.4" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.3" + ] + } + }, { "control_id": "RSK-04", "title": "Risk Assessment", @@ -215570,7 +225024,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -215761,12 +225216,7 @@ "3.11.1[b]" ], "general-nist-800-171a-r3": [ - "A.03.11.01.a", - "A.03.11.01.b" - ], - "general-nist-800-172": [ - "3.11.1e", - "3.11.5e" + "A.03.11.01.a" ], "general-nist-csf-2-0": [ "GV.RM-06", @@ -215792,9 +225242,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.1" - ], "general-swift-cscf-2025": [ "7.4A" ], @@ -215844,6 +225291,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "RA-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(1)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(b)", "314.4(b)(1)", @@ -215852,12 +225302,12 @@ "314.4(b)(1)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "usa-federal-irs-1075-2021": [ "RA-3" @@ -215914,10 +225364,9 @@ "Article 9.2(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.3.3(20)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "emea-eu-dora-2023": [ "Article 8.3", @@ -215934,16 +225383,19 @@ "2.1.3", "6.1.1" ], + "emea-eu-psd2-2015": [ + "95(2)" + ], "emea-deu-bsrit-2017": [ - "3.10" + "3.9" ], "emea-deu-c5-2020": [ "OIS-07", - "SP-03" + "BEI-06" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.2", + "4.2, Stage 2.3" ], "emea-sau-cscc-1-2019": [ "1-2-1-1" @@ -215956,29 +225408,27 @@ "1-5-3" ], "emea-sau-otcc-1-2022": [ - "1-3-1-2" + "1-3-1-2", + "1-3-1-4", + "1-3-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-31" + "VII.B.TPC-31" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.2", - "Article 14.1", - "Article 14.2" + "3.2.1.4-1.b", + "3.2.1.2-2", + "3.2.1.2-2.1", + "3.2.1.2-2.2" ], "emea-esp-decree-311-2022": [ - "14.1", - "14.2", - "3.2" + "Article 14(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.1 [OP.PL.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "mp.if.3", + "mp.if.5", + "mp.if.6" ], "emea-gbr-cap-1850-2020": [ "A2" @@ -216001,12 +225451,17 @@ "1202", "1204" ], + "apac-aus-ism-2026-march": [ + "ISM-1203" + ], "apac-aus-ps-cps-230-2023": [ - "27(a)", - "27(b)", - "27(c)", + "13", + "16(d)", "28" ], + "apac-chn-data-security-law-2021": [ + "Article 30" + ], "apac-ind-sebi-2024": [ "ID.RA.S1", "ID.RA.S2" @@ -216020,7 +225475,11 @@ "4.6.1.1", "6.1.5.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.1", + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP32", "HML32" ], @@ -216031,18 +225490,23 @@ "2.3.27.C.01", "2.3.27.C.02", "5.9.23.C.01", + "22.4.7.C.01", "23.2.16.C.02" ], "apac-sgp-mas-trm-2021": [ "4.1.4(b)", - "4.3.2" + "4.3.1", + "8.5.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "2.1", - "6.8" + "5.3-BP1", + "5.5", + "5.5-BP2", + "5.11", + "6.19", + "6.19-BP1", + "6.19-BP2", + "6.19-BP3" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -216073,11 +225537,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to maintain a risk register that facilitates monitoring and reporting of risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -216149,7 +225613,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -216187,6 +225652,10 @@ "03.12.02.a.01", "03.12.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" + ], "general-nist-csf-2-0": [ "GV.RM-06", "ID", @@ -216209,9 +225678,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.3" - ], "general-tisax-6-0-3": [ "1.4.1" ], @@ -216240,15 +225706,14 @@ "500.9(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(d)" + "3.3.1.10", + "3.3.1.13(d)" ], "emea-deu-c5-2020": [ - "SP-03" + "OIS-03-DOAR" ], - "emea-isr-cmo-1-0": [ - "2.2", - "6.8" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.2" ], "emea-sau-cscc-1-2019": [ "1-2-1-2" @@ -216257,17 +225722,11 @@ "1-4-3" ], "emea-sau-otcc-1-2022": [ - "1-3-1-3", - "1-3-1-6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "1-3-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.4" - ], - "emea-zaf-popia-2013": [ - "19" + "3.2.1.4-1.c", + "3.2.1.1-2.2" ], "emea-gbr-def-stan-05-138-2024": [ "4201" @@ -216278,27 +225737,28 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4201" ], + "apac-aus-ps-cps-230-2023": [ + "13", + "32" + ], "apac-ind-sebi-2024": [ "GV.RM.S4" ], "apac-jpn-ismap": [ "4.4.7.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP65", "HML64" ], "apac-sgp-mas-trm-2021": [ - "4.1.3", - "4.1.4(d)", - "4.5.2", - "4.5.3" + "4.5.2" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "5.5-BP4" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -216328,7 +225788,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to implement a risk assessment methodology to ensure coverage for organizational components relevant for secure, compliant and resilient operations.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -216401,7 +225861,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -216420,9 +225881,6 @@ "6.2", "6.7" ], - "general-nist-800-172": [ - "3.11.1e" - ], "general-swift-cscf-2025": [ "7.4A" ], @@ -216468,10 +225926,33 @@ "7.2(e)", "7.2(f)" ], + "emea-deu-c5-2020": [ + "OIS-07" + ], + "emea-sau-cscc-1-2019": [ + "1-2-1" + ], + "emea-sau-ecc-1-2018": [ + "1-5-1", + "1-5-2" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-1" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.1", "4.4.7.4" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.4(d)" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.3" ] } }, @@ -216495,7 +225976,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define instances that require a risk assessment to be performed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -216563,16 +226044,14 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { "general-mpa-csbp-5-3-1": [ "OR-2.0" ], - "general-scf-dpmp-2025": [ - "9.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7150(a)", "7150(b)", @@ -216591,6 +226070,9 @@ "apac-jpn-ismap": [ "4.4.7.3", "4.5.5.1" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.4(d)" ] } }, @@ -216680,16 +226162,17 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { - "general-scf-dpmp-2025": [ - "9.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7151(a)", "7151(b)" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.9" ] } }, @@ -216715,7 +226198,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -216788,7 +226271,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -216825,6 +226309,9 @@ "general-nist-800-171-r3": [ "03.11.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a" + ], "general-nist-csf-2-0": [ "ID", "ID.RA-05", @@ -216862,32 +226349,11 @@ "500.9(b)(3)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "2.1.2(e)" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-sau-sama-csf-1-2017": [ - "3.2.1.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-sgp-mas-trm-2021": [ - "4.2.1" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "2.2" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" ] @@ -216915,7 +226381,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to remediate risks to an acceptable level.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to remediate risks to an acceptable level. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -217007,7 +226473,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -217120,8 +226587,9 @@ "03.11.02.b", "03.12.02.a.02" ], - "general-nist-800-172": [ - "3.11.7e" + "general-nist-800-171a-r3": [ + "A.03.11.02.b", + "A.03.12.02.a.02" ], "general-nist-csf-2-0": [ "GV.RM-04", @@ -217203,7 +226671,8 @@ "Article 9.2(d)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "emea-eu-nis2-2022": [ "Article 21.4" @@ -217214,24 +226683,26 @@ "2.1.2(g)", "2.1.2(j)" ], + "emea-deu-bsrit-2017": [ + "11.1" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.3" + ], "emea-sau-cgiot-2024": [ "1-1-2", "1-4-1", "1-4-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 14.2", - "Article 14.3" + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2", + "3.2.1.3-2.1" ], "emea-esp-decree-311-2022": [ - "14.2", - "14.3" + "Article 3(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], "emea-gbr-def-stan-05-138-2024": [ "1200" @@ -217246,6 +226717,7 @@ "1200" ], "apac-aus-ps-cps-230-2023": [ + "13", "31" ], "apac-ind-sebi-2024": [ @@ -217255,24 +226727,24 @@ "4.6.1.1", "4.7.1.1" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-pdpa-2012": [ + "4.1.15A(5)(b)(i)", + "4.1.15A(5)(b)(ii)", + "4.1.15A(5)(b)(iii)" + ], "apac-sgp-mas-trm-2021": [ - "4.1.3", "4.1.4(c)", - "4.4.1", - "4.4.2", - "4.4.3", - "13.6.1", - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" + "4.4.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" + "5.3-BP1", + "5.5-BP3" ], - "amaericas-can-osfi-self-assessment": [ - "2.2", - "2.7", - "6.8" + "americas-can-osfi-self-assessment-2": [ + "3.2.3" ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", @@ -217300,7 +226772,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure proper risk response actions were performed to remediate findings from security, compliance and/or resilience-related:\n(1) Assessments;\n(2) Audits; and/or\n(3) Incidents.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -217393,9 +226865,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -217501,13 +226973,11 @@ "03.11.04" ], "general-nist-800-171a-r3": [ + "A.03.11.02.b", "A.03.11.04[01]", "A.03.11.04[02]", "A.03.11.04[03]" ], - "general-nist-800-172": [ - "3.11.6e" - ], "general-nist-csf-2-0": [ "GV.RM-04", "ID.RA-05", @@ -217528,9 +226998,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "9.4" - ], "general-un-155-2021": [ "7.2.2.3" ], @@ -217589,24 +227056,16 @@ "Article 9.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "3.3.1.13(c)" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.3" - ], - "emea-zaf-popia-2013": [ - "19" + "3.2.1.4-1.d" ], - "emea-esp-boe-a-2022-7191": [ - "Article 14.2", - "Article 14.3" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], - "emea-esp-decree-311-2022": [ - "14.2", - "14.3" + "apac-aus-ps-cps-230-2023": [ + "16(d)" ], "apac-jpn-ismap": [ "4.4.7.4", @@ -217616,15 +227075,8 @@ "4.7.1.3", "4.7.1.6" ], - "apac-sgp-mas-trm-2021": [ - "4.1.5", - "4.5.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", @@ -217653,7 +227105,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and implement compensating countermeasures to reduce risk and exposure to threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -217746,7 +227198,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -217804,6 +227257,9 @@ "general-nist-800-171-r3": [ "03.11.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.b" + ], "general-nist-csf-2-0": [ "GV.RM-04", "ID.RA-06" @@ -217840,9 +227296,6 @@ "2.2.4", "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.0" - ], "general-un-155-2021": [ "7.2.2.3" ], @@ -217866,10 +227319,10 @@ "314.4(c)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.1.b", @@ -217891,22 +227344,35 @@ "Article 9.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "emea-eu-nis2-annex-2024": [ "6.6.1(d)" ], + "emea-deu-c5-2020": [ + "OIS-04-DOAR", + "SA-03-DOAR" + ], "emea-sau-otcc-1-2022": [ "1-3-1-6", "1-3-1-7" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2.6", + "3.2.1.3-2.6.a", + "3.2.1.3-2.6.b", + "3.2.1.3-2.6.b.1", + "3.2.1.3-2.6.b.2", + "3.2.1.3-2.6.b.3", + "3.2.1.3-2.6.c", + "3.2.1.3-2.6.d" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-decree-311-2022": [ + "Article 28(3)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ + "ISM-0009", "ISM-1809" ], "apac-ind-sebi-2024": [ @@ -217917,7 +227383,10 @@ "4.4.8.1", "4.4.8.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP26", "HHSP43", "HHSP65", @@ -217926,6 +227395,7 @@ "HML64" ], "apac-nzl-ism-3-9": [ + "11.1.18.C.03", "12.4.5.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ @@ -217933,20 +227403,18 @@ "4.3(c)" ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.4.2", - "4.4.3" + "4.4.1" ], "americas-bmu-mba-coc-2020": [ - "5.8" - ], - "amaericas-can-osfi-self-assessment": [ - "6.16", - "6.24" + "5.11-BP4" ], "americas-can-osfi-b13-2022": [ "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.3", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B" ] @@ -217956,8 +227424,8 @@ "control_id": "RSK-06.3", "title": "Risk Treatment Options", "family": "RSK", - "description": "Mechanisms exist to select appropriate risk treatment options, based on applicable risk assessment findings.", - "scf_question": "Does the organization select appropriate risk treatment options, based on applicable risk assessment findings?", + "description": "Mechanisms exist to select appropriate risk treatment options, based on applicable risk assessment findings, including:\n(1) Mitigating the risk to an acceptable level;\n(2) Avoiding the risk (e.g., terminating the project);\n(3) Transferring the risk to a third party (e.g., insurance, service provider, etc.); or\n(4) Accepting the risk.", + "scf_question": "Does the organization select appropriate risk treatment options, based on applicable risk assessment findings, including:\n(1) Mitigating the risk to an acceptable level;\n(2) Avoiding the risk (e.g., terminating the project);\n(3) Transferring the risk to a third party (e.g., insurance, service provider, etc.); or\n(4) Accepting the risk?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -217972,7 +227440,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to select appropriate risk treatment options, based on applicable risk assessment findings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -218057,8 +227525,10 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Risk Management", "crosswalks": { "general-iso-21434-2021": [ @@ -218093,10 +227563,44 @@ "RISK-4a", "RISK-4b" ], + "emea-deu-bsrit-2017": [ + "3.9" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 3.1" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-6" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.10", + "3.2.1.3-2.3", + "3.2.1.3-2.3.a", + "3.2.1.3-2.3.b", + "3.2.1.3-2.3.b.1", + "3.2.1.3-2.3.b.2", + "3.2.1.3-2.4", + "3.2.1.3-2.5", + "3.2.1.3-2.5.a", + "3.2.1.3-2.5.b", + "3.2.1.3-2.5.c" + ], "apac-jpn-ismap": [ "4.4.7.1", "4.4.8.1", "4.4.8.2" + ], + "apac-mys-bnm-rmit-2025": [ + "11.17" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.3", + "4.1.4(c)", + "4.4.2", + "4.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "5.8" ] } }, @@ -218120,7 +227624,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to formalize a Risk Treatment Plan (RTP) that applicable stakeholders will utilize to remediate identified risks according to a defined timeline.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -218207,9 +227711,9 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], - "errata": "- renamed", "family_name": "Risk Management", "crosswalks": { "general-cobit-2019": [ @@ -218263,6 +227767,27 @@ "RISK:SG5.SP2", "TM:SG3.SP2" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 4" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-6" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2.2", + "3.2.1.3-2.7", + "3.2.1.4-2", + "3.2.1.4-2.1", + "3.2.1.4-2.1.a", + "3.2.1.4-2.1.b", + "3.2.1.4-2.2" + ], + "emea-esp-decree-311-2022": [ + "Article 14(3)" + ], + "apac-aus-ps-cps-230-2023": [ + "31" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.1", @@ -218275,6 +227800,13 @@ "4.7.1.1", "4.7.1.4", "4.9" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.2.3" ] } }, @@ -218298,7 +227830,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -218386,7 +227918,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -218440,30 +227973,11 @@ "500.9(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(f)" + "3.3.1.13(f)" ], "emea-eu-nis2-annex-2024": [ "2.1.4" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS05" - ], - "apac-sgp-mas-trm-2021": [ - "4.1.5" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.B" ] @@ -218489,7 +228003,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to conduct a Business Impact Analysis (BIA) to identify and assess security, compliance and resilience risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -218577,9 +228091,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -218640,11 +228154,9 @@ "general-pci-dss-4-0-1": [ "A3.2.2" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(78)" + "3.3.3.20", + "3.7.1.78" ], "emea-eu-dora-2023": [ "Article 11.5" @@ -218653,21 +228165,12 @@ "2.1.3", "4.1.3" ], - "emea-bel-act-8-1992": [ - "21" - ], "emea-deu-c5-2020": [ - "BCM-02" - ], - "emea-isr-cmo-1-0": [ - "6.8", - "16.6" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-4" + "BCM-02-BP5", + "BCM-04" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.1.2" @@ -218681,18 +228184,21 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4201" ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "apac-aus-ps-cps-230-2023": [ + "26" ], "apac-jpn-ismap": [ "4.4.7.3" ], - "apac-sgp-mas-trm-2021": [ - "5.1.3", - "5.3.3" + "apac-mys-bnm-rmit-2025": [ + "10.44" ], - "apac-kor-pipa-2011": [ - "33" + "apac-nzl-ism-3-9": [ + "16.1.30.C.01" + ], + "americas-bmu-mba-coc-2020": [ + "5.14", + "7.1-BP1" ] } }, @@ -218817,7 +228323,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -218978,16 +228485,11 @@ "A.03.17.01.a[10]", "A.03.17.01.b[01]", "A.03.17.01.b[02]", - "A.03.17.01.c", "A.03.17.03.ODP[01]", "A.03.17.03.a[01]", "A.03.17.03.a[02]", "A.03.17.03.b" ], - "general-nist-800-172": [ - "3.11.6e", - "3.11.7e" - ], "general-nist-csf-2-0": [ "GV.SC", "GV.SC-01", @@ -219003,9 +228505,6 @@ "general-owasp-top-10-2025": [ "A03:2025" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "general-sparta": [ "CM0026" ], @@ -219105,23 +228604,16 @@ "5.1.6" ], "emea-deu-c5-2020": [ - "OIS-07" + "OIS-07", + "PS-04-DOAR" ], - "emea-isr-cmo-1-0": [ - "16.3", - "17.3", - "17.11" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-3" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" ], "emea-gbr-caf-4-0": [ "A4", "A4.a" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -219134,11 +228626,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0731", "ISM-1567", "ISM-1785" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-nzl-ism-3-9": [ "2.2.7.C.01", "12.7.14.C.01", @@ -219161,13 +228656,6 @@ "12.7.20.C.05", "12.7.21.C.01" ], - "apac-sgp-mas-trm-2021": [ - "5.3.1" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.17.01.A", @@ -219197,7 +228685,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to periodically assess supply chain risks associated with Technology Assets, Applications and/or Services (TAAS).", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -219296,7 +228784,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -219379,8 +228868,10 @@ "03.11.01.b", "03.17.03.a" ], - "general-nist-800-172": [ - "3.11.6e" + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.11.01.b", + "A.03.17.03.a[01]" ], "general-nist-csf-2-0": [ "GV.SC", @@ -219389,9 +228880,6 @@ "general-owasp-top-10-2025": [ "A03:2025" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "general-un-155-2021": [ "7.2.2.5" ], @@ -219434,17 +228922,6 @@ "emea-eu-nis2-annex-2024": [ "5.1.3" ], - "emea-isr-cmo-1-0": [ - "16.6", - "17.3", - "17.11" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-3" - ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -219457,13 +228934,16 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1452", "ISM-1567" ], "apac-ind-sebi-2024": [ "GV.SC.S7" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.11.01.B", @@ -219576,7 +229056,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -219607,7 +229088,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to conduct a Data Protection Impact Assessment (DPIA) on Technology Assets, Applications and/or Services (TAAS) that store, process and/or transmit Personal Data (PD) to identify and remediate reasonably-expected risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -219661,7 +229142,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -219757,9 +229239,6 @@ "general-pci-dss-4-0-1": [ "A3.2.2" ], - "general-scf-dpmp-2025": [ - "9.5" - ], "general-shared-assessments-sig-2025": [ "P.5" ], @@ -219904,64 +229383,126 @@ "Article 35.11", "Article 36.1" ], - "emea-deu-c5-2020": [ - "BCM-02" - ], - "emea-isr-cmo-1-0": [ - "16.6", - "17.3" + "emea-deu-fdpa-2017": [ + "3.4.67(1)", + "3.4.67(2)", + "3.4.67(3)", + "3.4.67(4)", + "3.4.67(4)1", + "3.4.67(4)2", + "3.4.67(4)3", + "3.4.67(4)4", + "3.4.67(5)" + ], + "emea-irl-dpa-2018": [ + "s.84" ], "emea-ken-pda-2019": [ - "31(1)", - "31(2)(a)", - "31(2)(b)", - "31(2)(c)", - "31(2)(d)", - "31(3)", - "31(4)", - "31(5)", - "31(6)" + "IV.31(1)", + "IV.31(2)", + "IV.31(2)(a)", + "IV.31(2)(b)", + "IV.31(2)(c)", + "IV.31(2)(d)", + "IV.31(3)" ], "emea-qat-pdppl-2020": [ - "8.2" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-4" + "3.11.1" ], "emea-sau-pdpl-2023": [ "Article 22" ], "emea-srb-act-9-2018": [ - "54", - "54.x" + "IV.3.54-1", + "IV.3.54-1(1)", + "IV.3.54-1(2)", + "IV.3.54-1(3)", + "IV.3.54-2", + "IV.3.54-2(1)", + "IV.3.54-2(2)", + "IV.3.54-2(3)", + "IV.3.54-2(4)", + "IV.3.55-1", + "IV.3.55-1(1)", + "IV.3.55-1(2)", + "IV.3.55-2", + "IV.3.55-2(1)", + "IV.3.55-2(2)", + "IV.3.55-2(3)", + "IV.3.55-2(4)", + "IV.3.55-2(5)", + "IV.3.55-2(6)" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-decree-311-2022": [ + "Article 3(2)", + "Article 12(1)(f)" ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "emea-che-fadp-2025": [ + "3.22.1", + "3.22.2", + "3.22.2.a", + "3.22.2.b", + "3.22.3", + "3.22.4", + "3.22.5", + "3.22.5.a", + "3.22.5.b", + "3.22.5.c" + ], + "emea-gbr-dpa-2018": [ + "Section 64(1)", + "Section 64(2)", + "Section 64(3)", + "Section 64(3)(a)", + "Section 64(3)(b)", + "Section 64(3)(c)", + "Section 64(3)(d)", + "Section 64(4)" + ], + "apac-aus-ps-cps-230-2023": [ + "26" ], "apac-chn-pipl-2021": [ - "55", - "55(1)", - "55(2)", - "55(3)", - "55(4)", - "55(5)", - "56", - "56(1)", - "56(2)", - "56(3)" + "Article 55", + "Article 56" ], "apac-ind-dpdpa-2023": [ "10(2)(c)(i)" ], - "apac-sgp-mas-trm-2021": [ - "5.1.3", - "5.3.3" + "apac-sgp-pdpa-2012": [ + "4.1.15A(4)(a)", + "4.1.15A(5)(a)" ], - "apac-kor-pipa-2011": [ - "33" + "americas-bhs-dpa-2003": [ + "V.50(1)", + "V.50(1)(a)", + "V.50(1)(b)", + "V.50(2)", + "V.50(2)(a)", + "V.50(2)(b)", + "V.50(2)(c)", + "V.50(3)", + "V.50(3)(a)", + "V.50(3)(b)", + "V.50(3)(c)", + "V.50(3)(d)", + "V.50(4)", + "V.50(5)", + "V.50(6)", + "V.50(7)", + "V.50(8)", + "V.50(8)(a)", + "V.50(8)(b)", + "V.50(8)(c)", + "V.50(8)(d)", + "V.50(8)(e)", + "V.50(8)(f)" + ], + "americas-bra-lgpd-2018": [ + "II.I.10.II.3" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.1" ] } }, @@ -219983,7 +229524,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure risk monitoring as an integral part of the continuous monitoring strategy that includes monitoring the effectiveness of security, compliance and resilience controls, compliance and change management.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -220069,9 +229610,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-nist-800-53-r5-2": [ @@ -220095,10 +229636,11 @@ "general-nist-800-82-r3-high": [ "CA-07(04)" ], - "general-scf-dpmp-2025": [ - "7.11", - "9.0", - "9.3" + "general-nist-800-172-r3": [ + "03.12.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.03E[01]" ], "usa-federal-fbi-cjis-6-0": [ "CA-7(4)" @@ -220133,8 +229675,11 @@ "emea-eu-nis2-annex-2024": [ "2.1.2(h)" ], - "emea-zaf-popia-2013": [ - "4" + "emea-sau-sama-csf-1-2017": [ + "3.2.1.4-1.d" + ], + "emea-esp-decree-311-2022": [ + "Article 14(1)" ] } }, @@ -220158,7 +229703,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure teams are committed to a culture that considers and communicates technology-related risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -220225,7 +229770,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -220267,9 +229813,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to obtain executive leadership approval for risk management decisions involving material risk.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to obtain executive leadership approval for risk management decisions involving material risk. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -220296,10 +229842,18 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", - "crosswalks": {} + "crosswalks": { + "emea-deu-bsrit-2017": [ + "3.4" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.10" + ] + } }, { "control_id": "RSK-13.1", @@ -220321,7 +229875,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to document alternative courses of action to ensure executive leadership is reasonably informed of options to manage material risks, including potential:\n(1) Benefits;\n(2) Drawbacks (including technical limitations);\n(3) Costs; and\n(4) Timelines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -220350,7 +229904,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", "crosswalks": {} @@ -220406,7 +229961,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", "crosswalks": {} @@ -220435,7 +229991,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).\n▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of TAAS.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -220517,9 +230073,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -220534,18 +230090,18 @@ "general-cis-csc-8-1": [ "12.2", "12.6", - "16.0", - "16.1" + "16", + "16.10" ], "general-cis-csc-8-1-ig2": [ "12.2", "12.6", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ "12.2", "12.6", - "16.1" + "16.10" ], "general-cobit-2019": [ "APO03.01", @@ -220621,7 +230177,7 @@ "8.26", "8.27" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -220759,7 +230315,6 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.16.c", "03.01.18.a", "03.13.01.c", @@ -220772,7 +230327,13 @@ "3.13.2[f]" ], "general-nist-800-171a-r3": [ - "A.03.16.01.ODP[01]" + "A.03.01.12.a[04]", + "A.03.01.16.a[02]", + "A.03.01.16.c", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01.ODP[01]", + "A.03.16.01" ], "general-nist-csf-2-0": [ "PR.IR", @@ -220807,10 +230368,6 @@ "6.2.1", "8.5.1" ], - "general-scf-dpmp-2025": [ - "5.12", - "7.1" - ], "general-swift-cscf-2025": [ "1.3" ], @@ -220898,10 +230455,10 @@ "314.4(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "PT-1", @@ -220941,7 +230498,7 @@ "SI-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -220959,107 +230516,28 @@ "6.2.2(b)", "6.2.2(c)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-bsrit-2017": [ - "12.1" + "1.2(d)" ], "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "UP-01-BP2", + "DLL-01-BP1" ], "emea-sau-cgiot-2024": [ "1-5-1", "2-5-1" ], "emea-sau-ecc-1-2018": [ + "1-6-3-1", "1-6-3-4", - "2-4-3", "2-15-3-3" ], "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 29" - ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" - ], - "emea-che-fadp-2025": [ - "6", - "7" + "1-4-1-3" ], - "emea-tur-lppd-2016": [ - "8", - "12" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.4", + "mp.s.2" ], "emea-uae-niaf-2023": [ "3.2.1" @@ -221068,10 +230546,6 @@ "B4.a", "B5.b" ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" - ], "emea-gbr-def-stan-05-138-2024": [ "2400" ], @@ -221084,41 +230558,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2400" ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", - "ISM-1743" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" + "ISM-1743", + "ISM-1926", + "ISM-1927" ], "apac-ind-sebi-2024": [ "PR.IP.S17" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "14.2.5", "14.2.5.1", @@ -221129,10 +230577,19 @@ "14.2.5.6", "14.2.5.7" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.5", + "10.22", + "10.26", + "10.36", + "10.37", + "10.38", + "10.40", + "10.43", + "10.52" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP16", "HML16" ], @@ -221140,42 +230597,16 @@ "HSUP14" ], "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" + "2.3.28.C.01", + "20.2.14.C.01", + "20.2.14.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" + "14.1.1", + "14.2.10" ], "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" + "5.3-BP3" ], "americas-can-osfi-b13-2022": [ "1.3.1", @@ -221185,29 +230616,18 @@ "3.2", "3.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.1.1", + "2.1.2", + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", - "03.01.16.B", "03.01.16.C", "03.01.18.A", "03.13.01.C", "03.16.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } }, @@ -221232,7 +230652,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to centrally-manage the organization-wide management and implementation of security, compliance and resilience controls and related processes.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -221322,22 +230742,22 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" ], "general-cis-csc-8-1": [ - "16.1" + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.10" ], "general-cobit-2019": [ "APO03.01", @@ -221407,9 +230827,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-tisax-6-0-3": [ "5.3.1" ], @@ -221438,21 +230855,12 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-zaf-popia-2013": [ - "8" - ], - "apac-aus-ps-cps-234-2019": [ - "18" + "emea-isr-cmo-2-0": [ + "Appendix C" ], "apac-nzl-ism-3-9": [ "4.3.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.5.1" - ], - "americas-arg-ppd-2018": [ - "9.1" - ], "americas-can-osfi-b13-2022": [ "1.3.1" ] @@ -221480,7 +230888,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to achieve resilience requirements in normal and adverse situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -221535,7 +230943,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -221574,6 +230983,12 @@ "emea-eu-nis2-annex-2024": [ "4.2.4" ], + "emea-sau-otcc-1-2022": [ + "3-1-1-1" + ], + "emea-gbr-cap-1850-2020": [ + "B5" + ], "emea-gbr-def-stan-05-138-2024": [ "2500", "2501" @@ -221593,6 +231008,13 @@ "2500", "2501" ], + "apac-mys-bnm-rmit-2025": [ + "10.24", + "10.31", + "10.32", + "10.40", + "11.2" + ], "americas-can-osfi-b13-2022": [ "2", "2.1.2", @@ -221618,7 +231040,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -221669,9 +231091,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-csa-cmm-4-1-0": [ @@ -221712,6 +231134,253 @@ "emea-gbr-caf-4-0": [ "B5", "B5.b" + ], + "emea-gbr-cap-1850-2020": [ + "B5" + ], + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.32", + "10.40", + "11.2" + ] + } + }, + { + "control_id": "SEA-01.4", + "title": "Secure Architecture Principles", + "family": "SEA", + "description": "Mechanisms exist to ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture.", + "scf_question": "Does the organization ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Reference NIST CSF for architecture guidance\n∙ Apply basic secure design principles (least privilege, defense-in-depth)", + "small": "∙ NIST CSF and OWASP design principles\n∙ Documented secure design checklist", + "medium": "∙ TOGAF or SABSA-aligned secure architecture principles\n∙ Documented architecture principles standard\n∙ Security architecture review in project lifecycle", + "large": "∙ Enterprise secure architecture principles aligned to TOGAF or SABSA\n∙ Security Architecture Review Board (SARB)\n∙ Architecture principles enforced in project governance", + "enterprise": "∙ Enterprise architecture framework with embedded security principles (TOGAF or SABSA)\n∙ Dedicated security architecture function\n∙ Automated architecture compliance checking\n∙ Board-approved enterprise architecture standards" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "emea-deu-bsrit-2017": [ + "1.2(d)" + ], + "emea-deu-c5-2020": [ + "UP-01-BP2", + "SA-01-BP5" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.4", + "3.3.4.1", + "3.3.4.3", + "3.3.4.3.a", + "3.3.4.3.b", + "3.3.4.3.c", + "3.3.4.3.d", + "3.3.4.3.e" + ], + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.5", + "10.36", + "10.37", + "10.38", + "10.40" + ], + "apac-nzl-ism-3-9": [ + "1.2.15.C.01", + "2.3.28.C.01" + ] + } + }, + { + "control_id": "SEA-01.5", + "title": "Security-Aware Design", + "family": "SEA", + "description": "Mechanisms exist to formally incorporate the organization's secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "scf_question": "Does the organization formally incorporate its secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to formally incorporate the organization's secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Security design checklist for new systems or applications\n∙ OWASP Top 10 design guidance", + "small": "∙ OWASP secure design principles\n∙ Security requirements in development projects", + "medium": "∙ Security-by-design requirements integrated into SDLC\n∙ Threat modeling for new systems\n∙ OWASP Threat Dragon or similar", + "large": "∙ Enterprise secure-by-design program\n∙ Threat modeling requirements in SDLC\n∙ Security architecture approval for new projects\n∙ Privacy and security design reviews", + "enterprise": "∙ Enterprise security-aware design program\n∙ Automated threat modeling integration in SDLC\n∙ Security and privacy design reviews for all new systems\n∙ Board-approved security-by-design policy" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "apac-nzl-ism-3-9": [ + "2.3.28.C.01" ] } }, @@ -221736,9 +231405,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -221809,9 +231478,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -221822,15 +231491,15 @@ ], "general-cis-csc-8-1": [ "12.2", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig2": [ "12.2", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ "12.2", - "16.1" + "16.10" ], "general-cobit-2019": [ "APO02.01", @@ -221938,6 +231607,18 @@ "03.13.01.c", "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01" + ], + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.02" + ], "general-nist-csf-2-0": [ "PR.IR", "PR.IR-01", @@ -221946,9 +231627,6 @@ "general-pci-dss-4-0-1": [ "1.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.3" ], @@ -221988,12 +231666,12 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "PL-8", @@ -222023,7 +231701,7 @@ "PL-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -222031,207 +231709,44 @@ "Article 9.3(c)", "Article 9.3(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-bsrit-2017": [ - "12.1" - ], - "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" + "1.2(d)" ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "emea-sau-cscc-1-2019": [ + "2-12-2" ], "emea-sau-ecc-1-2018": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 29" - ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" - ], - "emea-che-fadp-2025": [ - "6", - "7" - ], - "emea-tur-lppd-2016": [ - "8", - "12" - ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" + "1-6-3-4" ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "mp.info.4", + "mp.s.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", "ISM-1743" ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" - ], - "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.36", + "10.40" ], "americas-can-osfi-b13-2022": [ "2", "2.1", "2.1.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.1.1", + "2.1.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", "03.01.18.A", "03.13.01.C", "03.16.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } }, @@ -222253,9 +231768,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -222292,7 +231807,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -222337,15 +231853,18 @@ "usa-federal-far-52-204-21": [ "52.204-21(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.615" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.103", - "164.304", - "164.402", - "164.501", - "164.504(a)" + "§ 164.103", + "§ 164.304", + "§ 164.402", + "§ 164.501", + "§ 164.504(a)" ], "usa-state-ca-ccpa-cpra-2026": [ "7001" @@ -222373,30 +231892,9 @@ "emea-eu-ai-act-2024": [ "Article 3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 3" - ], "emea-eu-gdpr-2016": [ "Article 4" ], - "emea-ken-pda-2019": [ - "2" - ], - "emea-nga-dpr-2019": [ - "1.3" - ], - "emea-qat-pdppl-2020": [ - "1" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 4" - ], - "emea-esp-decree-311-2022": [ - "4" - ], - "amaericas-can-osfi-self-assessment": [ - "6.4" - ], "americas-can-osfi-b13-2022": [ "A.1" ] @@ -222420,7 +231918,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to identify non-essential functions or services that are capable of being outsourced to external service providers and align with the organization's enterprise architecture and security standards.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -222487,7 +231985,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -222503,6 +232002,12 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(d)" ], + "emea-esp-decree-311-2022": [ + "Article 14(1)" + ], + "apac-aus-ps-cps-230-2023": [ + "15" + ], "apac-jpn-ismap": [ "4.5.4.5" ] @@ -222526,7 +232031,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to conduct ongoing “technical debt” reviews of hardware and software technologies to remediate outdated and/or unsupported technologies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -222604,7 +232109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -222650,9 +232156,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).\n▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -222723,7 +232229,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -222759,6 +232266,14 @@ "general-nist-800-171-r2": [ "3.13.2" ], + "general-nist-800-172-r3": [ + "03.15.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.02E.a", + "A.03.15.02E.ODP[02]", + "DS-A.03.15.02E.c" + ], "general-owasp-top-10-2025": [ "A01:2025", "A05:2025" @@ -222794,14 +232309,17 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(iv)" + ], "usa-federal-law-ftc-act": [ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "PL-8(CE-1)", @@ -222812,7 +232330,7 @@ "500.2(b)(2)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -222820,202 +232338,19 @@ "Article 9.3(c)", "Article 9.3(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], - "emea-deu-bsrit-2017": [ - "12.1" - ], - "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "emea-isr-cmo-2-0": [ + "2.E" ], "emea-sau-ecc-1-2018": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 9.1", - "Article 9.1(a)", - "Article 9.1(b)", - "Article 9.2" - ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" + "2-15-3-2" ], - "emea-che-fadp-2025": [ - "6", - "7" - ], - "emea-tur-lppd-2016": [ - "8", - "12" - ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", "ISM-1743" ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" - ], - "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" - ], "americas-can-osfi-b13-2022": [ "3.2", "3.2.4" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } }, @@ -223037,9 +232372,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to partition systems so that partitions reside in separate physical domains or environments.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to partition systems so that partitions reside in separate physical domains or environments. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -223086,7 +232421,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -223099,7 +232435,7 @@ "general-cis-csc-8-1-ig3": [ "3.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1590.002" ], "general-nist-800-53-r4": [ @@ -223114,6 +232450,14 @@ "general-nist-800-160-vol-2-r1": [ "SC-32" ], + "general-nist-800-172-r3": [ + "03.13.16E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.16E", + "A.03.13.16E.ODP[01]", + "A.03.13.16E.ODP[02]" + ], "usa-federal-cms-marse-2-0": [ "SC-32", "SC-32-iS" @@ -223138,9 +232482,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to separate user functionality from system management functionality.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to separate user functionality from system management functionality. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -223187,7 +232531,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -223209,7 +232554,7 @@ "general-iec-62443-3-3-2013": [ "SR 5.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1189", "T1190", @@ -223298,9 +232643,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement a separate execution domain for each executing process.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement a separate execution domain for each executing process. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -223346,7 +232691,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -223368,7 +232714,7 @@ "general-iec-tr-60601-4-5-2021": [ "5.2 - CR 2.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -223473,9 +232819,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate security functions from non-security functions.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate security functions from non-security functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -223541,7 +232887,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -223551,7 +232898,7 @@ "general-govramp-high": [ "SC-03" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003.001", "T1021.003", "T1047", @@ -223655,9 +233002,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement underlying hardware separation mechanisms to facilitate process separation.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement underlying hardware separation mechanisms to facilitate process separation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -223701,7 +233048,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -223741,9 +233089,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to maintain a separate execution domain for each thread in multi-threaded processing.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to maintain a separate execution domain for each thread in multi-threaded processing. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -223787,7 +233135,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -223827,7 +233176,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate, or logically separate, any application, service and/or process running with system privileges.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -223890,7 +233239,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -223917,9 +233267,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent unauthorized and unintended information transfer via shared system resources.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent unauthorized and unintended information transfer via shared system resources. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -223990,7 +233340,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -224009,7 +233360,7 @@ "general-govramp-high": [ "SC-04" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1070", @@ -224113,17 +233464,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-04" ], - "emea-deu-c5-2020": [ - "OPS-24", - "COS-06" - ], - "emea-isr-cmo-1-0": [ - "10.5", - "10.8" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], "emea-gbr-def-stan-05-138-2024": [ "2416" ], @@ -224159,9 +233499,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically prevent the execution of unauthorized software programs.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically prevent the execution of unauthorized software programs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -224210,7 +233550,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -224294,7 +233635,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to determine the Mean Time to Failure (MTTF) for system components in specific environments of operation.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -224347,7 +233688,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -224378,6 +233720,9 @@ "general-nist-800-171-r3": [ "03.16.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.02.b" + ], "general-nist-csf-2-0": [ "ID.AM-08" ], @@ -224418,9 +233763,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -224482,7 +233827,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -224566,6 +233912,10 @@ "03.16.02.a", "03.16.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.02.a", + "A.03.16.02.b" + ], "general-nist-csf-2-0": [ "GV.SC-09", "ID.AM-08", @@ -224633,7 +233983,7 @@ "SA-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(55)" + "3.5.55" ], "emea-eu-nis2-annex-2024": [ "6.7.2(j)", @@ -224646,11 +233996,8 @@ "emea-sau-cgiot-2024": [ "2-15-3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 36" - ], - "emea-esp-decree-311-2022": [ - "36" + "emea-sau-otcc-1-2022": [ + "2-2-1-1" ], "emea-gbr-caf-4-0": [ "A3.a (point 5)" @@ -224658,16 +234005,20 @@ "apac-aus-essential-8-2024": [ "ML3-P2" ], + "apac-aus-ps-cps-230-2023": [ + "25" + ], "apac-sgp-mas-trm-2021": [ - "7.3.1", - "7.3.2", - "7.3.3" + "7.3.2" ], "americas-can-osfi-b13-2022": [ "1.3.1", "2.2", "2.2.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.02.A", "03.16.02.B" @@ -224692,11 +234043,11 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -224760,7 +234111,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -224816,9 +234168,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SC-24" - ], - "emea-isr-cmo-1-0": [ - "9.17" ] } }, @@ -224840,11 +234189,11 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement fail-safe procedures when failure conditions occur.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement fail-safe procedures when failure conditions occur. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -224906,7 +234255,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -224957,9 +234307,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -225008,7 +234358,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -225019,7 +234370,7 @@ "general-iec-62443-4-2-2019": [ "CR 4.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1505", "T1505.001", "T1505.002", @@ -225040,6 +234391,15 @@ "general-nist-800-160-vol-2-r1": [ "SI-14" ], + "general-nist-800-172-r3": [ + "03.14.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.15E.a", + "DS-A.03.14.15E.b", + "DS-A.03.14.15E.c", + "A.03.14.15E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A01:2025", "A05:2025" @@ -225064,7 +234424,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure that software and data needed for system component and service refreshes are obtained from trusted sources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -225130,7 +234490,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -225159,8 +234520,12 @@ "general-nist-800-160-vol-2-r1": [ "SI-14(01)" ], - "general-nist-800-172": [ - "3.14.4e" + "general-nist-800-172-r3": [ + "03.14.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.04E", + "A.03.14.04E.ODP[01]" ], "general-shared-assessments-sig-2025": [ "T.3" @@ -225176,9 +234541,89 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "SA-03(03)" + ] + } + }, + { + "control_id": "SEA-08.2", + "title": "Non-Persistent Information", + "family": "SEA", + "description": "Mechanisms exist to:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed.", + "scf_question": "Does the organization:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Session timeout configurations\n∙ Ephemeral file deletion after use", + "small": "∙ Session termination and ephemeral data deletion\n∙ Temporary file cleanup policies", + "medium": "∙ Automated ephemeral data lifecycle management\n∙ Session management with defined timeout and cleanup\n∙ Secure deletion of temporary data stores", + "large": "∙ Automated non-persistent information management\n∙ Defined data refresh cycles for non-persistent stores\n∙ Secure deletion enforcement", + "enterprise": "∙ Enterprise non-persistent information governance\n∙ Automated data lifecycle enforcement for ephemeral data\n∙ Integration with data classification and DLP\n∙ Continuous monitoring for data persistence policy compliance" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-IR-1", + "R-IR-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.14.05E" ], - "emea-sau-ecc-1-2018": [ - "1-6-3-2" + "general-nist-800-172a-r3": [ + "DS-A.03.14.05E.a", + "A.03.14.05E.ODP[01]", + "DS-A.03.14.05E.b" ] } }, @@ -225200,9 +234645,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -225249,11 +234694,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.002", "T1021.005", "T1048", @@ -225332,7 +234778,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to limit the dissemination of Personal Data (PD) to organization-defined elements identified in the Data Protection Impact Assessment (DPIA) and consistent with authorized purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -225389,7 +234835,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -225416,9 +234863,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security safeguards to protect system memory from unauthorized code execution.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security safeguards to protect system memory from unauthorized code execution. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -225465,7 +234912,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -225484,7 +234932,7 @@ "general-govramp-high": [ "SI-16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003.001", "T1047", "T1055.009", @@ -225546,6 +234994,12 @@ "general-nist-800-171-r2": [ "NFO - SI-16" ], + "general-nist-800-172-r3": [ + "03.14.14E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.14E" + ], "usa-federal-fbi-cjis-6-0": [ "SI-16" ], @@ -225584,9 +235038,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeypots that are specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting and analyzing such attacks.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeypots that are specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting and analyzing such attacks. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -225629,11 +235083,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1210", "T1211", "T1212" @@ -225656,6 +235111,14 @@ "IR-04(13)", "SC-26" ], + "general-nist-800-172-r3": [ + "03.13.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.08E[01]", + "DS-A.03.13.08E[02]", + "DS-A.03.13.08E[03]" + ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -225673,9 +235136,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "IR-04(13)" - ], - "emea-isr-cmo-1-0": [ - "23.5" ] } }, @@ -225697,9 +235157,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeyclients that proactively seek to identify malicious websites and/or web-based malicious code.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeyclients that proactively seek to identify malicious websites and/or web-based malicious code. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -225739,11 +235199,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1210", "T1211", "T1212" @@ -225780,9 +235241,6 @@ ], "usa-federal-irs-1075-2021": [ "SC-35" - ], - "emea-isr-cmo-1-0": [ - "23.5" ] } }, @@ -225804,9 +235262,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a diverse set of technologies for system components to reduce the impact of technical vulnerabilities from the same Original Equipment Manufacturer (OEM).", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a diverse set of technologies for system components to reduce the impact of technical vulnerabilities from the same Original Equipment Manufacturer (OEM). ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -225852,11 +235310,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1189", "T1190", "T1203", @@ -225884,8 +235343,11 @@ "general-nist-800-161-r1-level-3": [ "SC-29" ], - "general-nist-800-172": [ - "3.13.1e" + "general-nist-800-172-r3": [ + "03.13.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.01E" ], "apac-ind-sebi-2024": [ "EV.ST.S2" @@ -225910,7 +235372,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize virtualization techniques to support the employment of a diversity of operating systems and applications.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -225956,7 +235418,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -225975,6 +235438,12 @@ "general-nist-800-160-vol-2-r1": [ "SC-29(01)" ], + "general-nist-800-172-r3": [ + "03.13.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.07E" + ], "general-swift-cscf-2025": [ "1.3" ], @@ -225984,10 +235453,7 @@ "usa-federal-irs-1075-2021": [ "3.3.7" ], - "emea-deu-c5-2020": [ - "PSS-11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1460", "ISM-1461", "ISM-1604", @@ -225996,29 +235462,17 @@ "ISM-1607" ], "apac-nzl-ism-3-9": [ - "22.2.12.C.01", - "22.2.12.C.02", - "22.2.12.C.03", - "22.2.12.C.04", - "22.2.13.C.01", - "22.2.13.C.02", - "22.2.14.C.01", - "22.2.14.C.02", - "22.2.14.C.03", - "22.2.14.C.04", - "22.2.14.C.05", - "22.2.14.C.06", - "22.2.14.C.07", - "22.2.15.C.01", - "22.2.15.C.02", - "22.2.15.C.03", - "22.2.15.C.04", - "22.2.15.C.05", - "22.2.15.C.06", - "22.2.15.C.07", - "22.2.16.C.01", - "22.2.16.C.02", - "22.2.16.C.03" + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.12.C.03", + "20.2.12.C.04", + "20.2.14.C.01", + "20.2.14.C.03", + "20.2.14.C.04", + "20.2.14.C.07" + ], + "apac-sgp-mas-trm-2021": [ + "11.4.1" ] } }, @@ -226040,9 +235494,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize concealment and misdirection techniques for TAAS to confuse and mislead adversaries.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize concealment and misdirection techniques for TAAS to confuse and mislead adversaries. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -226074,14 +235528,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-cr-cmm-2026": [ "CR4.1.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1189", "T1190", @@ -226123,8 +235578,11 @@ "SC-30(4)", "SC-30(5)" ], - "general-nist-800-172": [ - "3.13.3e" + "general-nist-800-172-r3": [ + "03.13.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.03E" ] } }, @@ -226146,7 +235604,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically introduce randomness into organizational operations and assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -226194,7 +235652,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -226218,6 +235677,12 @@ ], "general-nist-800-161-r1-level-3": [ "SC-30(2)" + ], + "general-nist-800-172-r3": [ + "03.13.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.02E" ] } }, @@ -226239,7 +235704,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically change the location of processing and/or storage at random time intervals.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -226287,7 +235752,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -226314,6 +235780,13 @@ ], "general-nist-800-161-r1-level-3": [ "SC-30(3)" + ], + "general-nist-800-172-r3": [ + "03.13.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.05E", + "A.03.13.05E.ODP[01]" ] } }, @@ -226335,9 +235808,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to distribute processing and storage across multiple physical locations.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to distribute processing and storage across multiple physical locations. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -226399,11 +235872,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -226445,12 +235919,6 @@ "PE-23", "SC-36" ], - "general-nist-800-172": [ - "3.13.5e" - ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-sparta": [ "CM0074" ], @@ -226465,66 +235933,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "PE-23" - ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } }, @@ -226546,7 +235954,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize non-modifiable executable programs that load and execute the operating environment and applications from hardware-enforced, read-only media.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -226578,11 +235986,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1218.015", "T1542", @@ -226634,7 +236043,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a trusted communications path between the user and the security functions of the system.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -226685,7 +236094,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -226698,8 +236108,8 @@ "general-iso-27018-2025": [ "8.5" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.6 [OP.ACC.6]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6" ] } }, @@ -226723,7 +236133,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize system use notification / logon banners that display an approved system use notification message or banner before granting access to Technology Assets, Applications and/or Services (TAAS).", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -226775,9 +236185,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-govramp": [ @@ -226801,7 +236211,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1199" ], "general-nist-800-53-r4": [ @@ -226889,13 +236299,12 @@ "2406", "2407" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" + "16.1.44.C.02", + "16.1.44.C.03" ], "americas-can-itsp-10-171-2025": [ "03.01.09" @@ -226922,7 +236331,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to configure Microsoft Windows-based systems to display an approved logon banner before granting access to the system.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -226974,9 +236383,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -227001,14 +236410,9 @@ "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], - "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.09" ] @@ -227034,7 +236438,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a truncated system use notification / logon banner on systems not capable of displaying a logon banner from a centralized directory services technology (e.g., Active Directory, Entra ID, etc.).", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -227086,9 +236490,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -227113,14 +236517,9 @@ "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], - "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.09" ] @@ -227130,8 +236529,8 @@ "control_id": "SEA-19", "title": "Previous Logon Notification", "family": "SEA", - "description": "Mechanisms exist to configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", - "scf_question": "Does the organization configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon?", + "description": "Mechanisms exist to configure systems that process, store or transmit sensitive and/or regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", + "scf_question": "Does the organization configure systems that process, store or transmit sensitive and/or regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -227144,7 +236543,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -227178,7 +236577,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -227193,11 +236593,6 @@ ], "general-nist-800-82-r3": [ "AC-09" - ], - "apac-nzl-ism-3-9": [ - "16.1.49.C.01", - "16.1.50.C.01", - "16.1.50.C.02" ] } }, @@ -227219,9 +236614,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize time-synchronization technology to synchronize all critical system clocks.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize time-synchronization technology to synchronize all critical system clocks. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -227273,7 +236668,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -227408,6 +236804,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-08" ], + "emea-sau-ecc-1-2018": [ + "2-3-3-4" + ], "emea-gbr-def-stan-05-138-2024": [ "2421" ], @@ -227420,7 +236819,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2421" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0988" ], "apac-jpn-ismap": [ @@ -227429,6 +236828,9 @@ "12.4.4.2", "12.4.4.3", "12.4.4.4.PB" + ], + "americas-arg-ppd-2018": [ + "E.1.2-9" ] } }, @@ -227450,7 +236852,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize an application container (virtualization approach) to isolate to a known set of dependencies, access methods and interfaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -227481,7 +236883,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -227495,7 +236898,7 @@ "title": "Privileged Environments", "family": "SEA", "description": "Mechanisms exist to prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS).", + "scf_question": "Does the organization prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -227508,7 +236911,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -227583,7 +236986,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -227591,7 +236995,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1687" ] } @@ -227705,7 +237109,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -227732,7 +237137,7 @@ "7.5.3(a)", "7.5.3(b)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025" ], @@ -227781,6 +237186,9 @@ "03.15.01.a", "03.15.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]" + ], "general-nist-csf-2-0": [ "ID.IM" ], @@ -227895,54 +237303,14 @@ "Article 9.1", "Article 9.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-c5-2020": [ - "SP-01" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5" - ], - "emea-esp-decree-311-2022": [ - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" - ], - "apac-chn-pipl-2021": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "emea-esp-ccn-stic-825-2026": [ + "org.3" ], "apac-jpn-ismap": [ "12", "12.1", "12.1.3.9.PB" ], - "apac-sgp-mas-trm-2021": [ - "7.1.1" - ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "1.5" - ], "americas-can-osfi-b13-2022": [ "3" ], @@ -227972,7 +237340,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to identify and document Standardized Operating Procedures (SOP), or similar documentation, to enable the proper execution of day-to-day / assigned tasks.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -228043,7 +237411,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -228127,9 +237496,46 @@ ], "general-nist-800-171a-r3": [ "A.03.15.01.a[03]", - "A.03.15.01.a[04]", - "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.a[04]" + ], + "general-nist-800-172-r3": [ + "03.02.01E", + "03.08.03E", + "03.09.03E", + "03.11.02E", + "03.12.01E", + "03.13.05E", + "03.13.07E", + "03.14.08E", + "03.14.15E", + "03.15.01E", + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.02.01E.ODP[02]", + "A.03.08.03E.ODP[01]", + "A.03.08.03E.ODP[02]", + "DS-A.03.09.03E.b[01]", + "A.03.09.03E.ODP[01]", + "DS-A.03.09.03E.b[02]", + "DS-A.03.09.03E.c.02", + "A.03.09.03E.ODP[02]", + "A.03.11.02E.ODP[01]", + "A.03.12.01E.ODP[01]", + "A.03.12.04E.ODP[03]", + "A.03.13.05E.ODP[02]", + "A.03.13.05E.ODP[03]", + "A.03.13.07E.ODP[01]", + "A.03.14.05E.ODP[02]", + "A.03.14.05E.ODP[03]", + "A.03.14.05E.ODP[04]", + "A.03.14.08E.ODP[08]", + "A.03.14.08E.ODP[09]", + "A.03.14.08E.ODP[12]", + "A.03.14.15E.ODP[03]", + "A.03.15.01E.ODP[01]", + "A.03.17.02E.ODP[02]", + "A.03.17.02E.ODP[03]" ], "general-nist-800-218": [ "PO.3.2", @@ -228339,12 +237745,12 @@ "314.4(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-cms-marse-2-0": [ "AC-1.b", @@ -228381,16 +237787,9 @@ "500.8(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.2.(31)", - "3.4.2(31)(a)", - "3.4.2(31)(b)", - "3.4.2(31)(c)", - "3.4.2(31)(d)", - "3.4.2(31)(e)", - "3.4.2(31)(f)", - "3.4.2(31)(g)", - "3.4.5(38)", - "3.5(50)" + "3.4.2.31", + "3.4.4.36", + "3.5.50" ], "emea-eu-dora-2023": [ "Article 6.2", @@ -228401,31 +237800,14 @@ "7.1", "9.1" ], - "emea-deu-c5-2020": [ - "SP-01", - "IDM-02" - ], - "emea-isr-cmo-1-0": [ - "12.2", - "12.3", - "18.2", - "22.2" - ], "emea-sau-cgiot-2024": [ "1-2-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2(d)", - "Article 13.4", - "Article 22.2" - ], - "emea-esp-decree-311-2022": [ - "13.2(d)", - "13.4", - "22.2" + "emea-sau-ecc-1-2018": [ + "1-3-4" ], - "emea-esp-ccn-stic-825-2023": [ - "6.3 [ORG.3]" + "emea-esp-ccn-stic-825-2026": [ + "org.3" ], "emea-gbr-def-stan-05-138-2024": [ "1100", @@ -228446,15 +237828,6 @@ "2100", "2101" ], - "apac-chn-pipl-2021": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" - ], "apac-ind-sebi-2024": [ "PR.AA.S14", "PR.IP.S7", @@ -228479,6 +237852,9 @@ "12.1.5.P", "12.1.5.1.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.27" + ], "apac-nzl-hisf-suppliers-2023": [ "HSUP01" ], @@ -228490,15 +237866,35 @@ "5.5.3.C.01", "5.5.4.C.01", "5.5.5.C.01", - "5.5.6.C.01" + "5.5.6.C.01", + "16.1.24.C.01", + "20.2.15.C.01", + "21.1.7.C.01", + "21.1.7.C.02" + ], + "americas-arg-ppd-2018": [ + "B.1.3-1", + "B.1.3-2", + "B.1.3-3", + "B.2.4-2", + "B.2.5" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP4" ], "americas-can-osfi-b13-2022": [ "2.2.1", "2.8", "3" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.2" ] } }, @@ -228522,7 +237918,7 @@ "0": "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.", "1": "Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cybersecurity operations are primarily viewed as additional duties for IT staff.\n▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage.", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", - "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to develop a security Concept of Operations (CONOPS), or a similarly-defined plan for achieving cybersecurity objectives, that documents management, operational and technical measures implemented to apply defense-in-depth techniques that is communicated to all appropriate stakeholders.", + "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to develop a security Concept of Operations (CONOPS), or a similarly-defined plan for achieving cybersecurity objectives, that documents management, operational and technical measures implemented to apply defense-in-depth techniques that is communicated to all appropriate stakeholders. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -228586,7 +237982,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -228622,18 +238019,21 @@ "8.1.1" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(6)" + "3.2.2.6" ], "emea-eu-dora-2023": [ "Article 9.1", "Article 9.2" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.2" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], "apac-nzl-ism-3-9": [ "5.1.15.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "4.30" - ], "americas-can-osfi-b13-2022": [ "1.3.2" ] @@ -228659,7 +238059,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to define supporting business processes and implement appropriate governance and service management to ensure appropriate planning, delivery and support of the organization's technology capabilities supporting business functions, workforce, and/or customers based on industry-recognized standards to achieve the specific goals of the process area.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -228730,7 +238130,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -228825,7 +238226,10 @@ "164.316(b)" ], "general-nist-800-171-r3": [ - "03.15.01.b" + "03.15.01.a" + ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[04]" ], "general-nist-800-218": [ "PO.3.2" @@ -228840,14 +238244,14 @@ "11.10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-cms-marse-2-0": [ "IP-4", @@ -228859,7 +238263,6 @@ ], "emea-deu-bsrit-2017": [ "8.1", - "8.2", "11.1", "11.2", "11.3", @@ -228869,8 +238272,11 @@ "11.7", "11.8" ], - "apac-chn-pipl-2021": [ - "51" + "emea-esp-ccn-stic-825-2026": [ + "org.3" + ], + "apac-aus-ps-cps-230-2023": [ + "12(b)" ], "apac-jpn-ismap": [ "13.1.1.11.P", @@ -228879,19 +238285,24 @@ "14.1.1.19.P", "14.1.1.20.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.31" + ], "apac-sgp-mas-trm-2021": [ "7.1.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "1.5" - ], "americas-can-osfi-b13-2022": [ "2.2.1", "2.8" ], + "americas-can-osfi-self-assessment-2": [ + "2.8.1" + ], "americas-can-itsp-10-171-2025": [ - "03.15.01.B" + "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.2" ] } }, @@ -228915,7 +238326,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to establish and maintain a Security Operations Center (SOC) that facilitates a 24x7 response capability.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -228989,7 +238400,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -229016,8 +238428,12 @@ "general-nist-800-161-r1-level-3": [ "SC-38" ], - "general-nist-800-172": [ - "3.6.1e" + "general-nist-800-172-r3": [ + "03.06.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.01E[01]", + "DS-A.03.06.01E[02]" ], "usa-federal-dow-cmmc-2-level-3": [ "IR.L3-3.6.1E" @@ -229042,11 +238458,8 @@ "apac-ind-sebi-2024": [ "DE.CM.S1" ], - "apac-sgp-mas-trm-2021": [ - "12.2.1" - ], - "amaericas-can-osfi-self-assessment": [ - "1.4" + "apac-mys-bnm-rmit-2025": [ + "11.9" ] } }, @@ -229068,7 +238481,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to provide guidelines and recommendations for the secure use of Technology Assets, Applications and/or Services (TAAS) to assist in the configuration, installation and use of the product and/or service.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -229140,7 +238553,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -229153,13 +238567,6 @@ ], "usa-federal-dow-zt-roadmap-1-1": [ "6.5.3" - ], - "emea-deu-c5-2020": [ - "PSS-01" - ], - "amaericas-can-osfi-self-assessment": [ - "4.29", - "4.30" ] } }, @@ -229232,13 +238639,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { - "general-nist-800-172": [ - "3.11.3e" - ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EN.SOARE" ], @@ -229252,6 +238657,9 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.d" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" ] } }, @@ -229275,7 +238683,7 @@ "0": "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.", "1": "Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cybersecurity operations are primarily viewed as additional duties for IT staff.\n▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage.", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ An implemented and operational capability exists to detect the presence of unauthorized Technology Assets, Applications and/or Services (TAAS) in use.", + "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to detect the presence of unauthorized Technology Assets, Applications and/or Services (TAAS) in use.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -229371,7 +238779,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -229380,6 +238789,13 @@ ], "apac-ind-sebi-2024": [ "ID.AM.S3" + ], + "apac-mys-bnm-rmit-2025": [ + "10.16" + ], + "apac-sgp-mas-trm-2021": [ + "6.5.1", + "6.5.2" ] } }, @@ -229407,7 +238823,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security workforce development and awareness controls.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security workforce development and awareness controls. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -229505,9 +238921,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -229520,7 +238936,7 @@ "6" ], "general-cis-csc-8-1": [ - "14.0", + "14", "14.1" ], "general-cis-csc-8-1-ig1": [ @@ -229651,8 +239067,7 @@ "general-nist-800-171a-r3": [ "A.03.02.01.ODP[01]", "A.03.02.01.ODP[02]", - "A.03.02.01.a.01[01]", - "A.03.02.01.a.01[02]" + "A.03.02.01.a.01[01]" ], "general-nist-csf-2-0": [ "PR.AT" @@ -229711,10 +239126,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6", - "7.6" - ], "general-swift-cscf-2025": [ "7.2" ], @@ -229779,14 +239190,18 @@ "AT-01", "PM-13" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)", + "101.650(d)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-irs-1075-2021": [ "2.D.2", @@ -229819,8 +239234,7 @@ "AT-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -229832,65 +239246,48 @@ "8.1.3", "8.2.5" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.9" ], "emea-deu-c5-2020": [ - "HR-03", - "DEV-04" - ], - "emea-isr-cmo-1-0": [ - "20.1" - ], - "emea-qat-pdppl-2020": [ - "11.3" + "HR-03" ], "emea-sau-cgiot-2024": [ "1-9-1" ], "emea-sau-ecc-1-2018": [ "1-10-1", - "1-10-5" + "1-10-2" ], "emea-sau-otcc-1-2022": [ - "1-8" - ], - "emea-sau-sacs-002-2022": [ - "TPC-7" + "1-8-1" ], "emea-sau-sama-csf-1-2017": [ - "3.1.6" - ], - "emea-zaf-popia-2013": [ - "4.1.e" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 6.2" - ], - "emea-esp-decree-311-2022": [ - "6.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "3.1.6", + "3.1.6.1", + "3.1.6.2", + "3.1.6.2.a", + "3.1.6.2.b", + "3.1.6.2.c", + "3.1.6.3", + "3.1.6.4", + "3.1.6.5", + "3.1.6.5.a", + "3.1.6.5.b", + "3.1.6.5.c" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" ], "emea-gbr-caf-4-0": [ "B6.a" ], - "emea-gbr-cap-1850-2020": [ - "B6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0252", "ISM-0720", - "ISM-0735" + "ISM-0735", + "ISM-2022" ], "apac-chn-cybersecurity-law-2017": [ "Article 34(2)" @@ -229909,7 +239306,7 @@ "7.2.2.17", "7.2.2.18" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP22", "HML22" ], @@ -229920,21 +239317,17 @@ "9.1.4.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.6.1", - "3.6.4", - "6.1.5" - ], - "americas-bmu-mba-coc-2020": [ - "6.7" + "3.1.6" ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "apac-kor-pipa-2011": [ + "III.2.28(2)" ], "americas-can-osfi-b13-2022": [ "3.1.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], "americas-can-itsp-10-171-2025": [ "03.02.01.A" ] @@ -230054,7 +239447,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -230067,6 +239461,32 @@ "general-nist-600-1-gen-ai-profile": [ "MP-3.4-002" ], + "general-nist-800-171-r3": [ + "03.02.01.b", + "03.02.02.a.02", + "03.02.02.b", + "03.06.04.b" + ], + "general-nist-800-171a-r3": [ + "A.03.02.01.b[01]", + "A.03.02.01.b[02]", + "A.03.02.02.b[01]", + "A.03.02.02.b[02]", + "A.03.06.04.ODP[03]", + "A.03.06.04.ODP[04]", + "A.03.06.04.b[01]", + "A.03.06.04.b[02]", + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" + ], + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.b[01]", + "DS-A.03.02.01E.b[02]", + "A.03.02.01E.ODP[03]" + ], "general-swift-cscf-2025": [ "7.2" ], @@ -230074,12 +239494,35 @@ "WORKFORCE-2g", "WORKFORCE-4e" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "emea-eu-nis2-annex-2024": [ "8.1.2(a)" ], + "emea-deu-bsrit-2017": [ + "4.9" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.6.6", + "3.1.6.6.a", + "3.1.6.6.b" + ], "apac-jpn-ismap": [ "4.5.2.4", "4.5.2.5" + ], + "apac-sgp-mas-trm-2021": [ + "3.6.4" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], + "americas-can-itsp-10-171-2025": [ + "03.02.01.B", + "03.02.02.A.02", + "03.02.02.B", + "03.06.04.B" ] } }, @@ -230105,7 +239548,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -230195,9 +239638,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -230324,7 +239767,6 @@ "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.06.04.a.03" ], "general-nist-800-171a": [ @@ -230334,12 +239776,13 @@ "3.2.1[d]" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", "A.03.02.01.ODP[03]", "A.03.02.01.ODP[04]", + "A.03.02.01.a.01[01]", "A.03.02.01.a.03[03]", "A.03.02.01.a.03[04]", - "A.03.02.01.a.03[05]", - "A.03.02.01.a.03[06]" + "A.03.06.04.a.03" ], "general-nist-csf-2-0": [ "PR.AT", @@ -230401,9 +239844,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-swift-cscf-2025": [ "7.2" ], @@ -230445,19 +239885,27 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(9)", + "101.650(d)(1)", + "101.650(d)(1)(i)", + "101.650(d)(1)(ii)", + "101.650(d)(1)(iii)", + "101.650(d)(1)(iv)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(i)", - "164.530(b)(2)(i)", - "164.530(b)(2)(i)(A)", - "164.530(b)(2)(i)(B)", - "164.530(b)(2)(i)(C)", - "164.530(b)(2)(ii)" + "§ 164.308(a)(5)(i)", + "§ 164.530(b)(2)(i)", + "§ 164.530(b)(2)(i)(A)", + "§ 164.530(b)(2)(i)(B)", + "§ 164.530(b)(2)(i)(C)", + "§ 164.530(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-irs-1075-2021": [ "2.D.2.1", @@ -230519,7 +239967,7 @@ "2447(b)(2)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -230528,34 +239976,40 @@ "8.1.1", "8.1.2" ], - "emea-deu-c5-2020": [ - "HR-03", - "DEV-04" + "emea-deu-fdpa-2017": [ + "3.2.48(2)3" ], - "emea-isr-cmo-1-0": [ - "20.2" + "emea-deu-c5-2020": [ + "HR-03" ], "emea-sau-cgiot-2024": [ "1-9-1", "1-9-2" ], "emea-sau-ecc-1-2018": [ - "1-10-2", - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4" + "1-10-1", + "2-6-3-4" ], "emea-sau-otcc-1-2022": [ - "1-8" + "1-8-2" ], "emea-sau-sacs-002-2022": [ - "TPC-7" + "VII.A.TPC-7", + "VII.A.TPC-7.1", + "VII.A.TPC-7.2", + "VII.A.TPC-7.4", + "VII.A.TPC-7.5", + "VII.A.TPC-8", + "VII.A.TPC-9" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.6.7", + "3.1.7", + "3.3.1.3.b" ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" ], "emea-gbr-caf-4-0": [ "B6" @@ -230582,7 +240036,7 @@ "2602", "2603" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0252", "ISM-0824", "ISM-1146", @@ -230601,29 +240055,42 @@ "7.2.2.15", "7.2.2.25" ], + "apac-mys-bnm-rmit-2025": [ + "15.1" + ], "apac-nzl-ism-3-9": [ "9.1.5.C.01", "9.1.5.C.02", "9.1.6.C.01", - "9.1.6.C.02" + "9.1.6.C.02", + "16.4.43.C.01", + "20.1.27.C.01" + ], + "apac-sgp-pdpa-2012": [ + "3.12(c)" ], "apac-sgp-mas-trm-2021": [ "3.6.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" + "americas-bmu-mba-coc-2020": [ + "6.7" ], "americas-can-osfi-b13-2022": [ "3.1.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.01.A.01", "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", "03.06.04.A.03" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(c)", + "P7-4.7.4" ] } }, @@ -230734,7 +240201,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -230761,8 +240229,11 @@ "general-nist-800-161-r1-level-2": [ "AT-2(1)" ], - "general-scf-dpmp-2025": [ - "1.6" + "general-nist-800-172-r3": [ + "03.02.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.02E" ], "usa-federal-irs-1075-2021": [ "AT-2(CE-1)", @@ -230776,6 +240247,9 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2605" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" ] } }, @@ -230855,12 +240329,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "14.2" ], "general-cis-csc-8-1-ig1": [ @@ -230902,8 +240377,10 @@ "general-nist-800-171-r3": [ "03.02.01.a.03" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-171a-r3": [ + "A.03.02.01.a.03[03]", + "A.03.02.01.a.03[05]", + "A.03.02.01.a.03[06]" ], "general-pci-dss-4-0-1": [ "12.6.3.1" @@ -230941,11 +240418,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AT-02 (03)" ], - "emea-isr-cmo-1-0": [ - "20.4" - ], "emea-sau-ecc-1-2018": [ - "1-10-3" + "1-10-3-1" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-7.3" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -230956,12 +240433,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ - "ISM-0817" - ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" + "apac-aus-ism-2026-march": [ + "ISM-0817", + "ISM-2071" ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.03" @@ -230973,7 +240447,7 @@ "title": "Role-Based Security, Compliance & Resilience Training", "family": "SAT", "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", - "scf_question": "Does the organization provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafterystem changes; and \n (3) Annually thereafter?", + "scf_question": "Does the organization provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -231063,9 +240537,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -231153,7 +240627,7 @@ "7.2" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "OR-3.1", @@ -231226,11 +240700,10 @@ "03.02.02.a", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a", "03.06.04.a.01", "03.06.04.a.02", - "03.06.04.b" + "03.06.04.a.03" ], "general-nist-800-171a": [ "3.2.2[a]", @@ -231238,6 +240711,10 @@ "3.2.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.01.a.01[02]", + "A.03.02.01.a.02", "A.03.02.02.ODP[01]", "A.03.02.02.ODP[02]", "A.03.02.02.ODP[03]", @@ -231246,14 +240723,19 @@ "A.03.02.02.a.01[02]", "A.03.02.02.a.01[03]", "A.03.02.02.a.02", - "A.03.02.02.b[01]", - "A.03.02.02.b[02]", + "A.03.06.04.ODP[01]", + "A.03.06.04.ODP[02]", "A.03.06.04.a.01", "A.03.06.04.a.02", "A.03.06.04.a.03" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-172-r3": [ + "03.02.01E", + "03.02.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.02", + "A.03.02.04E.ODP[01]" ], "general-nist-800-218": [ "PO.2.2" @@ -231330,9 +240812,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -231411,6 +240890,14 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(9)", + "101.650(d)(1)(v)", + "101.650(d)(2)", + "101.650(d)(2)(i)", + "101.650(d)(2)(ii)", + "101.650(d)(4)" + ], "usa-federal-sro-finra": [ "248.201(e)(3)" ], @@ -231421,13 +240908,13 @@ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)", - "164.530(b)(1)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)", + "§ 164.530(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "2.D.2.1", @@ -231470,8 +240957,7 @@ "Article 9.5(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -231485,48 +240971,53 @@ "8.2.4" ], "emea-deu-c5-2020": [ - "DEV-04" - ], - "emea-isr-cmo-1-0": [ - "20.2", - "25.3" + "HR-03", + "HR-03-BP1", + "HR-03-BP4", + "HR-03-DOAR" ], "emea-qat-pdppl-2020": [ - "11.3" + "3.11.3" ], "emea-sau-cgiot-2024": [ "1-9-1" ], "emea-sau-ecc-1-2018": [ - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4", - "1-10-4", "1-10-4-1", "1-10-4-2", - "1-10-4-3" + "1-10-4-3", + "1-10-5" ], "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-7" + "1-8-2-1", + "2-13-1-8" ], "emea-sau-sama-csf-1-2017": [ - "3.1.6", - "3.1.7" + "3.1.7.1", + "3.1.7.1.a", + "3.1.7.1.b", + "3.1.7.1.c", + "3.1.7.1.d", + "3.1.7.2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "emea-esp-decree-311-2022": [ + "Article 6(2)", + "Article 15(1)", + "Article 16(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" + ], + "emea-che-fadp-2025": [ + "2.1.10.2.a" ], "emea-gbr-caf-4-0": [ "B6.b" ], + "emea-gbr-cap-1850-2020": [ + "B6" + ], "emea-gbr-def-stan-05-138-2024": [ "2321", "2602" @@ -231542,14 +241033,11 @@ "2321", "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1146", "ISM-1565", "ISM-1740" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-ind-sebi-2024": [ "PR.AT.S2" ], @@ -231560,20 +241048,20 @@ "7.2.2.14", "7.2.2.19.PB" ], + "apac-mys-bnm-rmit-2025": [ + "15.2", + "15.3" + ], "apac-nzl-ism-3-9": [ + "2.1.47.C.01", "9.1.6.C.01", "9.1.6.C.02", "9.1.6.C.03" ], "apac-sgp-mas-trm-2021": [ + "3.6.1", "3.6.2", - "3.6.3", - "6.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "3.6.3" ], "americas-can-osfi-b13-2022": [ "3.1.7" @@ -231585,17 +241073,16 @@ "03.02.02.A", "03.02.02.A.01", "03.02.02.A.02", - "03.02.02.B", "03.06.04.A", "03.06.04.A.01", "03.06.04.A.02", - "03.06.04.B" + "03.06.04.A.03" ] } }, { "control_id": "SAT-03.1", - "title": "Practical Exercises", + "title": "Practical Security Training Exercises", "family": "SAT", "description": "Mechanisms exist to include practical exercises in security, compliance and resilience training that reinforce training objectives.", "scf_question": "Does the organization include practical exercises in security, compliance and resilience training that reinforce training objectives?", @@ -231615,7 +241102,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to include practical exercises in security, compliance and resilience training that reinforce training objectives.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to include practical exercises in security, compliance and resilience training that reinforce training objectives.\nMechanisms exist to include practical exercises in security, compliance and resilience training that reinforce training objectives.", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -231669,9 +241156,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", + "errata": "- renamed control", "family_name": "Security Awareness & Training", "crosswalks": { "general-cis-csc-8-1": [ @@ -231704,12 +241192,6 @@ "general-nist-800-160-vol-2-r1": [ "AT-03(03)" ], - "general-nist-800-172": [ - "3.2.2e" - ], - "general-scf-dpmp-2025": [ - "1.6" - ], "usa-federal-dow-cmmc-2-level-3": [ "AT.L3-3.2.2E" ], @@ -231805,8 +241287,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "update mappings to NIST 800-53", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -231862,8 +241346,11 @@ "AT-2(4)", "AT-2(5)" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.02" ], "general-pci-dss-4-0-1": [ "11.5", @@ -231880,9 +241367,6 @@ "11.5.1", "11.5.1.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -231897,10 +241381,10 @@ "AT.L3-3.2.1E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "AT-2(CE-4)" @@ -231912,11 +241396,8 @@ "3.3.1", "3.3.2" ], - "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3", - "2-3-1-12" + "emea-sau-ecc-1-2018": [ + "1-10-3-1" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -231927,20 +241408,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0817", "ISM-0824", "ISM-1740" ], - "apac-sgp-mas-trm-2021": [ - "9.2.2", - "11.5.5", - "12.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" - ], "americas-can-osfi-b13-2022": [ "3.1.7" ] @@ -231950,8 +241422,8 @@ "control_id": "SAT-03.3", "title": "Sensitive / Regulated Data Storage, Handling & Processing", "family": "SAT", - "description": "Mechanisms exist to ensure that every user accessing a system processing, storing or transmitting sensitive/regulated data is formally trained in data handling requirements.", - "scf_question": "Does the organization ensure that every user accessing a system processing, storing or transmitting sensitive/regulated data is formally trained in data handling requirements?", + "description": "Mechanisms exist to ensure that every user accessing a system processing, storing or transmitting sensitive and/or regulated data is formally trained in data handling requirements.", + "scf_question": "Does the organization ensure that every user accessing a system processing, storing or transmitting sensitive and/or regulated data is formally trained in data handling requirements?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -232052,7 +241524,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -232084,7 +241557,7 @@ "6.3(a)" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "OR-3.3" @@ -232106,6 +241579,11 @@ "03.02.01.a.01", "03.02.02.a.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], "general-nist-800-218": [ "PO.2.2" ], @@ -232150,9 +241628,6 @@ "9.5.1", "9.5.1.3" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -232229,17 +241704,17 @@ "usa-state-vt-act-171-2018": [ "2447(c)(8)" ], - "emea-isr-cmo-1-0": [ - "20.3" + "emea-aut-dpa-2018": [ + "§ 6(3)" + ], + "emea-deu-c5-2020": [ + "HR-03-BP2" ], "emea-qat-pdppl-2020": [ - "11.3" + "3.11.3" ], "emea-sau-ecc-1-2018": [ - "1-10-4-2" - ], - "emea-sau-sama-csf-1-2017": [ - "3.1.7" + "1-10-3-2" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -232250,7 +241725,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0831", "ISM-1059" ], @@ -232258,13 +241733,12 @@ "7.2.2.16", "7.2.2.19.PB" ], - "apac-sgp-mas-trm-2021": [ - "3.6.2", - "3.6.3", - "6.1.5" + "apac-nzl-ism-3-9": [ + "21.1.6.C.01", + "22.1.11.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "1.7" + "apac-sgp-mas-trm-2021": [ + "3.6.1" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", @@ -232296,7 +241770,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to incorporate vendor-specific security, compliance and resilience training in support of new technology initiatives.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to incorporate vendor-specific security, compliance and resilience training in support of new technology initiatives. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -232362,16 +241836,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "usa-federal-dhs-cisa-cpg-2-0": [ "2.J" - ], - "emea-deu-c5-2020": [ - "DEV-04" ] } }, @@ -232380,7 +241851,7 @@ "title": "Privileged Users", "family": "SAT", "description": "Mechanisms exist to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", - "scf_question": "Does the organization provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", + "scf_question": "Does the organization provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -232395,9 +241866,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.\n▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data).", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -232485,7 +241956,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -232502,6 +241974,10 @@ "03.02.01.a.01", "03.02.02.a.01" ], + "general-nist-800-171a-r3": [ + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], "general-nist-800-218": [ "PO.2.2" ], @@ -232532,26 +242008,12 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.10(a)(2)" ], - "emea-sau-ecc-1-2018": [ - "1-10-4-1" - ], - "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1565" ], "apac-ind-sebi-2024": [ "PR.AT.S2" ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.7" - ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.01", "03.02.02.A.01" @@ -232578,7 +242040,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.\n▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data).\n▪ Business process owners are required to incorporate vendor-specific security training in support of new technology initiatives.\n▪ Security awareness training covers recommended practices for securing laptops and mobile devices while traveling.\n▪ Security awareness training covers reporting of unauthorized alterations and evidence of tampering of equipment", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide role-based security, compliance and resilience awareness training that is current and relevant to the cyber threats that users might encounter in day-to-day business operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -232651,9 +242113,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", + "errata": "update mappings to NIST 800-53", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -232698,20 +242161,24 @@ "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a.02" ], "general-nist-800-171a-r3": [ + "A.03.02.01.a.01[01]", "A.03.02.01.a.02", - "A.03.02.01.b[01]", - "A.03.02.01.b[02]" + "A.03.02.01.b[02]", + "A.03.02.02.a.01[01]", + "A.03.02.02.a.02", + "A.03.06.04.a.02" ], - "general-nist-800-172": [ - "3.2.1e", - "3.2.2e" + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.01", + "DS-A.03.02.01E.a.03" ], "general-nist-800-218": [ "PO.2.2" @@ -232764,9 +242231,6 @@ "9.5.1", "9.5.1.3" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-shared-assessments-sig-2025": [ "P.4" ], @@ -232792,14 +242256,17 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(4)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "usa-federal-nispom-2020": [ "§117.12(e)(1)", @@ -232820,13 +242287,19 @@ "8.1.2(c)", "8.2.3(b)" ], + "emea-deu-c5-2020": [ + "HR-03-BP3" + ], "emea-sau-cgiot-2024": [ "1-9-2" ], + "emea-sau-ecc-1-2018": [ + "1-10-3-3", + "1-10-3-4" + ], "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" + "1-8-2-2", + "2-13-1-8" ], "emea-gbr-def-stan-05-138-2024": [ "2601", @@ -232849,19 +242322,15 @@ "2603", "3106" ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "apac-sgp-mas-trm-2021": [ + "12.1.3" ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.01", "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", "03.02.02.A.01", "03.02.02.A.02", - "03.02.02.B", "03.06.04.A.02" ] } @@ -232887,7 +242356,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience personnel receive Continuing Professional Education (CPE) training to maintain currency and proficiency with industry-recognized secure practices that are pertinent to their assigned roles and responsibilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -232936,9 +242405,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -232958,9 +242427,6 @@ "general-iso-27701-2025": [ "7.2" ], - "general-nist-800-171-r3": [ - "03.06.04.b" - ], "general-nist-csf-2-0": [ "PR.AT-02" ], @@ -232970,11 +242436,14 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.10(a)(3)" ], + "emea-sau-otcc-1-2022": [ + "1-8-2-1" + ], "apac-jpn-ismap": [ "4.5.2.4" ], - "americas-can-itsp-10-171-2025": [ - "03.06.04.B" + "apac-mys-bnm-rmit-2025": [ + "15.2" ] } }, @@ -232996,7 +242465,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to ensure application development and operations (DevOps) personnel receive Continuing Professional Education (CPE) training on Secure Software Development Practices (SSDP) to appropriately address evolving threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -233041,7 +242510,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -233072,8 +242542,11 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1780" + ], + "apac-sgp-mas-trm-2021": [ + "6.1.5" ] } }, @@ -233163,7 +242636,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": {} @@ -233260,9 +242734,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-govramp": [ @@ -233350,9 +242824,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-tisax-6-0-3": [ "8.2.3" ], @@ -233371,6 +242842,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(4)" + ], "usa-federal-irs-1075-2021": [ "AT-4" ], @@ -233402,6 +242876,84 @@ ] } }, + { + "control_id": "SAT-04.1", + "title": "Training Feedback", + "family": "SAT", + "description": "Mechanisms exist to:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders.", + "scf_question": "Does the organization:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders.", + "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Track training completion rates\n∙ Simple feedback survey after training", + "small": "∙ Training completion tracking\n∙ Post-training feedback forms\n∙ Report findings to management", + "medium": "∙ Learning Management System (LMS) with completion and assessment tracking\n∙ Training effectiveness metrics\n∙ Regular reporting to management on training outcomes", + "large": "∙ LMS with detailed completion and assessment analytics\n∙ Training effectiveness measurement\n∙ Reporting to security leadership and HR", + "enterprise": "∙ Enterprise LMS with advanced analytics\n∙ Training effectiveness measurement and outcome reporting\n∙ Behavioral change metrics linked to awareness program\n∙ Board-level workforce security readiness reporting" + }, + "risks": [ + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Security Awareness & Training", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.02.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.03E" + ] + } + }, { "control_id": "SAT-05", "title": "Security, Compliance & Resilience Knowledge Sharing", @@ -233427,7 +242979,13 @@ "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Informal security knowledge sharing (e.g., team meetings, email updates)\n∙ Subscribe to CISA and NIST security alerts", + "small": "∙ Regular security briefings or newsletter\n∙ CISA and NIST alert subscriptions for the security team", + "medium": "∙ Internal security knowledge sharing program\n∙ Cross-functional security briefings\n∙ Lessons learned from incidents and assessments", + "large": "∙ Formal knowledge sharing program (security communities of practice)\n∙ Internal security portal or wiki\n∙ Cross-functional security training and briefings", + "enterprise": "∙ Enterprise security knowledge management platform\n∙ Communities of practice for security specializations\n∙ Cross-organizational knowledge sharing and lessons learned\n∙ Integration with LMS and professional development programs" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -233498,9 +243056,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "usa-federal-dhs-cisa-cpg-2-0": [ @@ -233531,7 +243089,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -233633,7 +243191,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -233646,7 +243205,7 @@ ], "general-cis-csc-8-1": [ "15.7", - "16.0" + "16" ], "general-cis-csc-8-1-ig3": [ "15.7" @@ -233716,7 +243275,7 @@ "A.6.1.3", "A.6.2.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -233813,11 +243372,21 @@ "03.17.02" ], "general-nist-800-171a-r3": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", "A.03.16.01.ODP[01]", + "A.03.16.01", "A.03.17.02[04]", "A.03.17.02[05]", "A.03.17.02[06]" ], + "general-nist-800-172-r3": [ + "03.16.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.16.01E" + ], "general-nist-800-218": [ "PO.1", "PO.3", @@ -233856,9 +243425,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.1" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "1.d", "4.b" @@ -233965,8 +243531,8 @@ "Article 14.4" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(67)", - "3.6.2(74)" + "3.6.2.67", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 13.7" @@ -233981,73 +243547,28 @@ "6.2.2(c)", "6.2.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ + "1.2(f)", "7.7", "7.8", "7.9", - "7.10", - "7.11", - "7.12", - "7.13", - "7.14" + "7.10" ], "emea-deu-c5-2020": [ - "DEV-01" - ], - "emea-isr-cmo-1-0": [ - "17.1", - "17.9" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" + "BEI-01" ], "emea-sau-cscc-1-2019": [ - "2-13", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3", - "2-5-4" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" + "1-3-2", + "2-13-1" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.6" + "emea-esp-decree-311-2022": [ + "Article 12(6)(g)", + "Article 19(1)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 19.1", - "Article 19.2", - "Article 19.2(a)", - "Article 19.2(b)", - "Article 19.2(c)", - "Article 19.3" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], - "emea-esp-decree-311-2022": [ - "19.1", - "19.2", - "19.2(a)", - "19.2(b)", - "19.2(c)", - "19.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.3 [OP.PL.3]", - "8.6.1 [MP.SW.1]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0938", "ISM-1780" ], @@ -234058,7 +243579,13 @@ "14.2.1.13.PB", "14.2.7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -234066,38 +243593,21 @@ "HSUP42" ], "apac-sgp-mas-trm-2021": [ - "5.3.1", - "5.3.2", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "5.3.2" ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" + "americas-arg-ppd-2018": [ + "H" + ], + "americas-bmu-mba-coc-2020": [ + "6.1-BP3" ], "americas-can-osfi-b13-2022": [ "2.4.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3", + "2.4.4" + ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03", @@ -234216,7 +243726,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -234342,6 +243853,16 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], + "general-nist-800-172-r3": [ + "03.16.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.16.01E", + "A.03.16.01E.ODP[01]" + ], "general-nist-800-218": [ "PO.1", "PO.1.1", @@ -234375,9 +243896,6 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-ul-2900-1-2017": [ "7.1", "7.1.1", @@ -234570,61 +244088,53 @@ "emea-eu-ai-act-2024": [ "Article 14.3(b)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 5", - "Article 5.1", - "Article 5.2", - "Article 10.1", - "Article 10.5", - "Article 10.6", - "Article 10.9", - "Article 10.10", - "Article 10.11", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.3", - "Article 13.4", - "Article 13.5", - "Article 13.6", - "Article 14.1", - "Article 14.2", - "Article 14.2(a)", - "Article 14.2(b)", - "Article 14.3", - "Article 14.4" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(j)", - "Annex 1.2(2)", - "Annex 2.1", - "Annex 2.2", - "Annex 2.3", - "Annex 2.4", - "Annex 2.5", - "Annex 2.6", - "Annex 2.7", - "Annex 2.8", - "Annex 2.9", - "Annex 2.9(a)", - "Annex 2.9(b)", - "Annex 2.9(c)", - "Annex 2.9(d)", - "Annex 6 Module A.3", - "Annex 6 Module A.4.1", - "Annex 6 Module C.2.1", - "Annex 6 Module C.3.1", - "Annex 6 Module H.2", - "Annex 6 Module H.3.2", - "Annex 6 Module H.3.4", - "Annex 6 Module H.5.1", - "Annex 6 Module H.5.2", - "Annex 6 Module H.6" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(1)", + "Article 13(5)", + "Article 13(8)", + "Article 13(10)", + "Article 13(11)", + "Article 13(13)", + "Article 13(14)", + "Article 13(15)", + "Article 13(16)", + "Article 13(17)", + "Article 13(18)", + "Article 13(19)", + "Article 13(20)", + "Article 13(21)", + "Article 13(22)", + "Article 13(23)", + "Article 19(1)", + "Article 19(2)", + "Article 19(2)(c)", + "Article 19(2)(d)", + "Article 19(3)", + "Article 19(4)", + "Article 19(5)", + "Article 19(6)", + "Article 20(1)", + "Article 20(2)", + "Article 20(2)(a)", + "Article 20(2)(b)", + "Article 20(3)", + "Article 20(4)", + "Article 24(1)", + "Article 30(1)", + "Article 30(2)", + "Article 30(3)", + "Article 30(4)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(1)", + "Annex I, Part I(2)(g)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)", + "Annex I, Part I(2)(m)", + "Annex I, Part II(1)", + "Annex I, Part II(2)" ], "emea-eu-dora-2023": [ "Article 13.7" @@ -234634,36 +244144,25 @@ "7.8", "7.9", "7.10", - "7.11", "7.12", "7.13", "7.14" ], - "emea-isr-cmo-1-0": [ - "17.9" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" - ], "emea-sau-cscc-1-2019": [ "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], - "emea-sau-otcc-1-2022": [ - "1-1-2", - "4-1-1-1" + "emea-sau-ecc-1-2018": [ + "1-6-3-4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1796", "ISM-1797", "ISM-1798" ], + "apac-aus-cop-sitc-2020": [ + "11" + ], "apac-chn-cybersecurity-law-2017": [ "Article 22", "Article 46", @@ -234673,7 +244172,13 @@ "14.1.1", "14.2.7.11" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -234703,17 +244208,16 @@ "12.4.7.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.8.1", - "5.8.2", - "7.6.1", - "7.6.2", - "14.4.1", - "14.4.2", - "14.4.3" + "5.5.2", + "14.1.5", + "14.1.7" ], "americas-can-osfi-b13-2022": [ "2.4.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] @@ -234739,11 +244243,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize integrity validation mechanisms for security updates.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -234797,14 +244301,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-nist-800-172": [ - "3.14.1e", - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -234821,7 +244322,7 @@ "title": "Malware Testing Prior to Release", "family": "TDA", "description": "Mechanisms exist to utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update.", - "scf_question": "Does the organization utilize at least one (1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update?", + "scf_question": "Does the organization utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -234834,11 +244335,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -234889,7 +244390,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -234902,6 +244404,9 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)" ] } }, @@ -235011,9 +244516,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "usa-federal-dow-zt-roadmap-1-1": [ @@ -235022,6 +244527,12 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-sgp-mas-trm-2021": [ + "6.3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3" ] } }, @@ -235045,7 +244556,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to design, develop and produce Technology Assets, Applications and/or Services (TAAS) in such a way that risk-based technical and functional specifications ensure Minimum Viable Product (MVP) criteria establish an appropriate level of security and resiliency based on applicable risks and threats.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -235136,7 +244647,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -235247,6 +244759,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PO.1", "PO.1.1", @@ -235323,33 +244838,33 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-04" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(1)", - "Annex 1.1(3)(b)", - "Annex 1.1(3)(c)", - "Annex 1.1(3)(d)", - "Annex 1.1(3)(f)", - "Annex 1.1(3)(g)", - "Annex 1.1(3)(i)", - "Annex 6 Module A.3" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" ], "emea-deu-bsrit-2017": [ "7.7" ], - "emea-deu-c5-2020": [ - "DEV-02" - ], "emea-sau-cscc-1-2019": [ "2-13-1", "2-13-2", + "2-13-3", "2-13-3-1", "2-13-3-2", "2-13-3-3", "2-13-3-4" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" + ], + "apac-aus-cop-sitc-2020": [ + "4" + ], "apac-jpn-ismap": [ "14.1.1.2", "14.1.1.3", @@ -235364,12 +244879,18 @@ "14.1.1.16", "14.2.1.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP31", "HML31" ], "apac-sgp-mas-trm-2021": [ - "5.3.3" + "5.4.3", + "5.5.2" ], "americas-can-itsp-10-171-2025": [ "03.16.01" @@ -235397,9 +244918,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to identify early in the Secure Development Life Cycle (SDLC), the functions, ports, protocols and services intended for use.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to identify early in the Secure Development Life Cycle (SDLC), the functions, ports, protocols and services intended for use. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -235467,7 +244988,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -235549,14 +245071,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-04 (09)" ], - "emea-isr-cmo-1-0": [ - "12.9", - "12.29" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-5", - "2-15-3-3" - ], "apac-nzl-ism-3-9": [ "18.1.15.C.01", "18.1.15.C.02", @@ -235583,7 +245097,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit the use of commercially-provided Information Assurance (IA) and IA-enabled IT products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile or the cryptographic module is FIPS-validated or NSA-approved.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -235619,7 +245133,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -235763,7 +245278,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -235836,7 +245351,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -235943,9 +245459,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "2" ], @@ -235974,23 +245487,25 @@ "emea-eu-ai-act-2024": [ "Article 14.1" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(74)" + "emea-sau-ecc-1-2018": [ + "1-6-3-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.1 [MP.SW.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" ], - "apac-sgp-mas-trm-2021": [ - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7" + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.14" ], "americas-can-osfi-b13-2022": [ "2.4.3", "2.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3", + "2.4.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -236014,7 +245529,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure vendors / manufacturers:\n(1) Deliver the Technology Asset, Application and/or Service (TAAS) with a pre-established, secure configuration implemented; and\n(2) Use the pre-established, secure configuration as the default for any subsequent TAAS reinstallation or upgrade.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -236086,7 +245601,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -236111,15 +245627,15 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4", "PW.5.1", "PW.9.1", "PW.9.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "1.e" ], @@ -236135,15 +245651,17 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(a)" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(b)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -236170,9 +245688,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require process owners to identify, document and justify the business need for the ports, protocols and other services necessary to operate their technology solutions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require process owners to identify, document and justify the business need for the ports, protocols and other services necessary to operate their technology solutions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -236232,7 +245750,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -236287,9 +245806,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to mitigate the risk associated with the use of insecure ports, protocols and services necessary to operate technology solutions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to mitigate the risk associated with the use of insecure ports, protocols and services necessary to operate technology solutions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -236351,7 +245870,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -236396,9 +245916,6 @@ "1.2.6", "2.2.5" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ] @@ -236422,7 +245939,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to include appropriate security, compliance and resilience representatives in the product feature and/or functionality change control review process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -236509,9 +246026,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-iec-62443-4-1-2018": [ @@ -236532,17 +246049,14 @@ "RV.1", "RV.3.4" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-irs-1075-2021": [ "SA-10(CE-7)" ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } }, @@ -236564,7 +246078,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to minimize the attack surface of Technology Assets, Applications and/or Services (TAAS) by reasonably mitigating known exploitable vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -236651,19 +246165,17 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(2)", - "Annex 1.1(3)(h)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(d)" ] } }, @@ -236685,7 +246197,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to deliver security updates to Technology Assets, Applications and/or Services (TAAS), where applicable, through:\n(1) Automatic updates; and\n(2) Notification of available updates to affected users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -236771,7 +246283,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -236790,20 +246303,27 @@ "SUM-5(d)", "SUM-5(e)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.6" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(8)", + "Article 13(9)", + "Article 13(11)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(c)", + "Annex I, Part I(2)(l)", + "Annex I, Part II(2)", + "Annex I, Part II(3)", + "Annex I, Part II(4)", + "Annex I, Part II(5)", + "Annex I, Part II(6)", + "Annex I, Part II(7)", + "Annex I, Part II(8)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(k)", - "Annex 1.2(2)", - "Annex 1.2(7)", - "Annex 1.2(8)" + "emea-deu-bsrit-2017": [ + "7.12" ] } }, @@ -236825,7 +246345,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for an appropriate level of security and resiliency based on applicable risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -236912,7 +246432,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -236933,14 +246454,15 @@ "SUM-1(2)(b)", "SUM-1(2)(c)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(3)" + "apac-sgp-mas-trm-2021": [ + "5.6.1", + "5.7.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.12" ] } }, @@ -236962,7 +246484,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to disclose information about vulnerabilities to relevant stakeholders, including:\n(1) A description of the vulnerability(ies);\n(2) Affected product(s) and/or service(s);\n(3) Potential impact of the vulnerability(ies);\n(4) Severity of the vulnerability(ies); and\n(5) Guidance to remediate the vulnerability(ies).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -237048,7 +246570,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -237057,9 +246580,6 @@ "DM-5(a)", "DM-5(b)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-nerc-cip-2024": [ "CIP-013-2 1.2.4" ], @@ -237067,15 +246587,26 @@ "7123(c)(6)", "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.7" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(4)", - "Annex 1.2(6)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(1)", + "Article 14(2)(a)", + "Article 14(2)(b)", + "Article 14(2)(c)", + "Article 14(2)(i)", + "Article 14(2)(i)(ii)", + "Article 14(2)(i)(iii)", + "Article 20(3)", + "Article 20(4)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(5)", + "Annex I, Part II(6)" ], "emea-eu-nis2-annex-2024": [ "6.10.2(e)" + ], + "emea-deu-c5-2020": [ + "RB-21-DOAR" ] } }, @@ -237097,7 +246628,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to categorize applicable security and resiliency requirements for products and/or services with digital elements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -237180,49 +246711,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 3 Class 1.1", - "Annex 3 Class 1.2", - "Annex 3 Class 1.3", - "Annex 3 Class 1.4", - "Annex 3 Class 1.5", - "Annex 3 Class 1.6", - "Annex 3 Class 1.7", - "Annex 3 Class 1.8", - "Annex 3 Class 1.9", - "Annex 3 Class 1.10", - "Annex 3 Class 1.11", - "Annex 3 Class 1.12", - "Annex 3 Class 1.13", - "Annex 3 Class 1.14", - "Annex 3 Class 1.15", - "Annex 3 Class 1.16", - "Annex 3 Class 1.17", - "Annex 3 Class 1.18", - "Annex 3 Class 1.19", - "Annex 3 Class 1.20", - "Annex 3 Class 1.21", - "Annex 3 Class 1.22", - "Annex 3 Class 1.23", - "Annex 3 Class 2.1", - "Annex 3 Class 2.2", - "Annex 3 Class 2.3", - "Annex 3 Class 2.4", - "Annex 3 Class 2.5", - "Annex 3 Class 2.6", - "Annex 3 Class 2.7", - "Annex 3 Class 2.8", - "Annex 3 Class 2.9", - "Annex 3 Class 2.10", - "Annex 3 Class 2.11", - "Annex 3 Class 2.12", - "Annex 3 Class 2.13", - "Annex 3 Class 2.14", - "Annex 3 Class 2.15" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(1)" + ], + "apac-mys-bnm-rmit-2025": [ + "12.1" ] } }, @@ -237244,7 +246742,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to notify applicable stakeholders about potentially exploitable vulnerabilities in organization-developed Technology Assets, Applications and/or Services (TAAS), as required by statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -237327,16 +246825,14 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)", "7123(c)(14)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.1" ] } }, @@ -237358,7 +246854,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers to use an industry-defined secure logging format to generate event logs for specified event types at organization-defined level of detail.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -237421,7 +246917,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -237451,9 +246948,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, custom-develops business-critical TAAS, when Commercial Off The Shelf (COTS) solutions are unavailable.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize only Commercial Off-the-Shelf (COTS) security products.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize only Commercial Off-the-Shelf (COTS) security products. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -237490,7 +246987,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -237511,6 +247009,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4", "PW.4.1" @@ -237518,10 +247019,6 @@ "general-sparta": [ "CM0007" ], - "apac-sgp-mas-trm-2021": [ - "5.3.3", - "6.1.3" - ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -237545,7 +247042,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to obtain security, compliance and resilience technologies from different suppliers to minimize supply chain risk.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -237607,9 +247104,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-nist-800-53-r4": [ @@ -237642,6 +247139,12 @@ "PL-8(2)", "SR-3(1)" ], + "general-nist-800-172-r3": [ + "03.15.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.03E" + ], "usa-federal-gsa-fedramp-5-low": [ "SR-03(01)" ], @@ -237678,7 +247181,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to obtain, protect and distribute administrator documentation for Technology Assets, Applications and/or Services (TAAS) that describe:\n(1) Secure configuration, installation and operation of the TAAS;\n(2) Effective use and maintenance of security features/functions; and\n(3) Known vulnerabilities regarding configuration and use of administrative (e.g., privileged) functions.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -237726,7 +247229,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -237926,22 +247430,25 @@ "emea-eu-ai-act-2024": [ "Article 11.1" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(4)", + "Article 13(7)", + "Article 31(1)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(73)" + "3.6.2.73" ], "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6", - "17.10" + "UP-01", + "KOS-07" ], - "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ], + "apac-aus-cop-sitc-2020": [ + "11", + "12" + ], "apac-jpn-ismap": [ "14.1.1.15", "14.2.7.10" @@ -237949,9 +247456,6 @@ "apac-nzl-ism-3-9": [ "3.4.10.C.01", "3.4.10.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.4" ] } }, @@ -237978,9 +247482,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -238035,9 +247539,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-govramp": [ @@ -238153,17 +247657,11 @@ "SA-04 (01)", "SA-04 (02)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6", - "17.10" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(7)", + "Article 31(1)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ] } @@ -238188,7 +247686,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate, or obtain, a Software Bill of Materials (SBOM) for Technology Assets, Applications and/or Services (TAAS) that lists software packages in use, including versions and applicable licenses.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -238238,7 +247736,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -238315,22 +247814,23 @@ "4e(iii)", "4e(vii)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.7" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(1)", - "Annex 1.2(6)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(1)" ], "emea-sau-cgiot-2024": [ "4-1-3" ], - "apac-aus-ism-2024-june": [ - "ISM-1730" + "apac-aus-ism-2026-march": [ + "ISM-1730", + "ISM-2054", + "ISM-2056" ], "apac-ind-sebi-2024": [ "GV.SC.S5", "PR.IP.S5" + ], + "apac-mys-bnm-rmit-2025": [ + "10.15" ] } }, @@ -238339,7 +247839,7 @@ "title": "Developer Architecture & Design", "family": "TDA", "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", - "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection?", + "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of its security architecture which is established within and is an integrated part of its enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -238354,7 +247854,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -238453,19 +247953,22 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.1", + "16.10" ], "general-govramp": [ "SA-17" @@ -238497,7 +248000,7 @@ "8.27", "8.30" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -238538,6 +248041,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4.2", "RV.1.1" @@ -238576,35 +248082,9 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3-4" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "apac-aus-ism-2026-march": [ + "ISM-2033", + "ISM-2043" ], "americas-can-itsp-10-171-2025": [ "03.16.01" @@ -238629,7 +248109,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to secure physical diagnostic and test interfaces to prevent misuse.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -238683,7 +248163,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -238730,7 +248211,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to enable endpoint devices to log events and generate alerts for attempts to access diagnostic and test interfaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -238784,7 +248265,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -238819,11 +248301,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to develop applications based on Secure Software Development Practices (SSDP).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -238893,7 +248375,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -238921,19 +248404,22 @@ "PI1.5-POF4" ], "general-cis-csc-8-1": [ - "16.0", + "16", "16.1", "16.5", + "16.10", "16.11" ], "general-cis-csc-8-1-ig2": [ "16.1", "16.5", + "16.10", "16.11" ], "general-cis-csc-8-1-ig3": [ "16.1", "16.5", + "16.10", "16.11" ], "general-cobit-2019": [ @@ -239008,7 +248494,7 @@ "A.6.1.3", "A.6.2.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -239097,6 +248583,9 @@ "3.13.2[b]", "3.13.2[e]" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PO.1", "PW.1", @@ -239144,10 +248633,6 @@ "6.2.1", "6.2.4" ], - "general-scf-dpmp-2025": [ - "5.12", - "7.1" - ], "general-sparta": [ "CM0017", "CM0043" @@ -239231,8 +248716,16 @@ "SA-03", "SA-15" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)" ], "emea-eu-nis2-2022": [ "Article 21.3" @@ -239245,25 +248738,16 @@ "7.10" ], "emea-deu-c5-2020": [ - "DEV-02", - "DEV-07", - "DEV-08" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.6", - "17.9", - "17.20", - "17.25" + "UP-01-BP2", + "BEI-01-BP1", + "BEI-01-BP4", + "BEI-01-DOAR", + "BEI-02" ], "emea-sau-cscc-1-2019": [ "1-3-2-3", "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-cgiot-2024": [ "2-14-3" @@ -239272,17 +248756,47 @@ "1-6-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-60", - "TPC-62" + "VII.B.TPC-74" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.6.4", + "3.3.6.5", + "3.3.6.5.a", + "3.3.6.5.b", + "3.3.6.5.c", + "3.3.6.5.d", + "3.3.6.5.e", + "3.3.6.5.f", + "3.3.6.5.g" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.info.4", + "mp.s.2" ], "emea-gbr-caf-4-0": [ "A4.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0401", "ISM-1239", "ISM-1419", - "ISM-1552" + "ISM-1552", + "ISM-1849", + "ISM-1922", + "ISM-2032", + "ISM-2035", + "ISM-2041", + "ISM-2045", + "ISM-2063", + "ISM-2064", + "ISM-2065", + "ISM-2066", + "ISM-2067" + ], + "apac-aus-cop-sitc-2020": [ + "4", + "6" ], "apac-jpn-ismap": [ "14.1.1.1", @@ -239290,7 +248804,7 @@ "14.2.1.9", "14.2.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -239301,35 +248815,21 @@ "14.4.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.3.2", "6.1.1", "6.1.2", "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "6.2.2" ], "americas-bmu-mba-coc-2020": [ "6.20" ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" - ], "americas-can-osfi-b13-2022": [ "2.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.2", + "2.4.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -239357,7 +248857,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developer of the Technology Asset, Application and/or Service (TAAS) to perform a criticality analysis at organization-defined decision points in the Secure Development Life Cycle (SDLC).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -239409,9 +248909,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -239426,7 +248926,7 @@ "general-iso-27018-2025": [ "8.29" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1495", "T1542", @@ -239494,15 +248994,18 @@ "RA-9", "SA-15(3)" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[01]" + ], "general-nist-800-218": [ "PW.1" ], "general-nist-csf-2-0": [ "PR.PS-06" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-sparta": [ "CM0022" ], @@ -239547,11 +249050,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.2" ], "apac-nzl-ism-3-9": [ "14.4.6.C.01", @@ -239585,7 +249085,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform threat modelling and other secure design techniques, to ensure that threats to software and solutions are identified and accounted for.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -239637,7 +249137,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -239787,18 +249288,22 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], "emea-sau-cgiot-2024": [ "2-12-1" ], - "apac-aus-ism-2024-june": [ - "ISM-1238" + "apac-aus-ism-2026-march": [ + "ISM-1238", + "ISM-2039" + ], + "apac-aus-ps-cps-230-2023": [ + "27(c)" ], "apac-jpn-ismap": [ "14.2.7.3" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], "apac-nzl-ism-3-9": [ "14.4.6.C.01", "14.4.6.C.02", @@ -239807,6 +249312,9 @@ "americas-can-osfi-b13-2022": [ "2.4.4", "3.1.6" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.6" ] } }, @@ -239831,7 +249339,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a Software Assurance Maturity Model (SAMM) to govern a secure development lifecycle for the development of Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -239880,7 +249388,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -239953,29 +249462,10 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.1 [MP.SW.1]" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.1", - "6.1.2", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3", - "7.6.1", - "7.6.2" + "apac-aus-ism-2026-march": [ + "ISM-2025", + "ISM-2034", + "ISM-2102" ] } }, @@ -239997,7 +249487,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically improve the accuracy, consistency and comprehensiveness of secure practices throughout the asset's lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -240038,7 +249528,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -240057,6 +249548,9 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2031" ] } }, @@ -240080,7 +249574,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -240125,9 +249619,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ @@ -240163,9 +249657,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.3" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0043" ], @@ -240178,24 +249669,9 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.8(a)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], "emea-sau-cgiot-2024": [ "2-14-3" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.2 [MP.SW.2]" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.4", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.6", - "6.1.7" - ], "americas-can-osfi-b13-2022": [ "2.4.1", "2.4.2" @@ -240220,7 +249696,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -240261,7 +249737,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -240289,6 +249766,110 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-aus-ism-2026-march": [ + "ISM-1909" + ] + } + }, + { + "control_id": "TDA-06.7", + "title": "Programming Language Selection", + "family": "TDA", + "description": "Mechanisms exist to:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions.", + "scf_question": "Does the organization:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Document approved programming languages for internal development\n∙ Prefer memory-safe languages for security-sensitive code (e.g., Rust, Go, Python)", + "small": "∙ Approved programming language list\n∙ Memory-safe language preference for new development\n∙ Documented justification for language choices", + "medium": "∙ Formal programming language governance standard\n∙ Memory-safe language requirements for security-critical code\n∙ Language selection approval process", + "large": "∙ Enterprise programming language governance program\n∙ Enforcement of approved languages in CI/CD\n∙ Security-focused language selection criteria (e.g., CISA memory safety guidance)", + "enterprise": "∙ Enterprise programming language governance with automated enforcement\n∙ CISA Memory Safe Roadmap alignment\n∙ Automated language compliance checking in CI/CD pipeline\n∙ Developer training on approved languages" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2040", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "emea-deu-c5-2020": [ + "BEI-01-BP3" + ], + "apac-aus-ism-2026-march": [ + "ISM-2040", + "ISM-2041" ] } }, @@ -240310,11 +249891,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a segmented development network to ensure a secure development environment.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a segmented development network to ensure a secure development environment. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -240382,7 +249963,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -240482,30 +250064,22 @@ "7123(c)(14)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(72)" + "3.6.2.72" ], "emea-eu-nis2-annex-2024": [ "6.2.2(c)", "6.8.2(h)" ], - "emea-deu-c5-2020": [ - "DEV-02", - "DEV-10" - ], - "emea-isr-cmo-1-0": [ - "10.1" - ], "emea-sau-cscc-1-2019": [ "1-3-2-4" ], "emea-sau-otcc-1-2022": [ "1-4-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0400", "ISM-1419" ], @@ -240525,6 +250099,9 @@ "14.2.6.11", "14.2.6.12" ], + "apac-mys-bnm-rmit-2025": [ + "10.7" + ], "apac-nzl-ism-3-9": [ "14.4.4.C.01" ], @@ -240551,7 +250128,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -240647,7 +250224,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -240757,14 +250335,11 @@ "7123(c)(14)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(72)" + "3.6.2.72" ], "emea-deu-c5-2020": [ - "DEV-10" - ], - "emea-isr-cmo-1-0": [ - "10.1" + "BEI-01-BP2", + "BEI-11" ], "emea-sau-cscc-1-2019": [ "1-3-2-4" @@ -240772,13 +250347,13 @@ "emea-sau-ecc-1-2018": [ "2-5-3-2" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-4" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.g" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0400", "ISM-1273", "ISM-1274" @@ -240798,15 +250373,30 @@ "12.1.4.8", "12.1.4.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.7", + "10.26", + "10.28" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP58", "HML58" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP50" ], + "apac-nzl-ism-3-9": [ + "20.2.14.C.06" + ], "apac-sgp-mas-trm-2021": [ "5.7.3" + ], + "americas-arg-ppd-2018": [ + "E.1.2-4" + ], + "americas-bmu-mba-coc-2020": [ + "6.20-BP2", + "6.20-BP3" ] } }, @@ -240828,7 +250418,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure secure migration practices purge Technology Assets, Applications and/or Services (TAAS) of test/development/staging data and accounts before it is migrated into a production environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -240891,7 +250481,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -240952,7 +250543,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers/integrators consult with security, compliance and/or resilience personnel to: \n(1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability;\n(2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the control testing and evaluation process; and\n(3) Document the results.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -241029,9 +250620,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -241144,7 +250735,7 @@ "8.29", "8.30" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -241239,6 +250830,12 @@ "03.12.03", "03.14.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], "general-nist-800-218": [ "PO.4", "PO.4.1", @@ -241299,11 +250896,6 @@ "6.2.4", "6.5.6" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.11", - "7.12" - ], "general-ul-2900-1-2017": [ "12.3", "12.3(a)", @@ -241407,11 +250999,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-11" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(70)", - "3.6.2(71)" - ], "emea-eu-nis2-annex-2024": [ "6.2.2(d)", "6.5.1" @@ -241421,42 +251008,27 @@ "7.8", "7.9", "7.10", - "7.11", - "7.12", - "7.13", - "7.14" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.3", - "17.4", - "17.12", - "17.15" + "7.12" ], "emea-sau-cscc-1-2019": [ - "1-3-1-1", "1-3-2-1" ], "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-3-4", "1-6-3-3" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.2 [MP.SW.2]" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402", - "ISM-1754" + "ISM-1754", + "ISM-1850", + "ISM-1851", + "ISM-2057", + "ISM-2060", + "ISM-2061", + "ISM-2062" ], "apac-ind-sebi-2024": [ "PR.IP.S6" @@ -241471,27 +251043,24 @@ "14.2.8.2", "14.2.8.3" ], + "apac-mys-bnm-rmit-2025": [ + "10.10" + ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2", - "5.7.3", "5.7.4", "5.7.5", - "5.7.6", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", "6.1.6", "6.1.7" ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" + "americas-bmu-mba-coc-2020": [ + "6.20-BP1" ], "americas-can-osfi-b13-2022": [ "3.2.9" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.9" + ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03", @@ -241519,9 +251088,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a plan for the continuous monitoring of security, compliance and/or resilience control effectiveness.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a plan for the continuous monitoring of security, compliance and/or resilience control effectiveness. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -241603,9 +251172,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ @@ -241647,6 +251216,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-800-218": [ "RV.1" ], @@ -241669,14 +251241,6 @@ "usa-federal-irs-1075-2021": [ "SA-4(CE-8)" ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.4", - "17.12" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.4" - ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] @@ -241702,9 +251266,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Developers of TAAS are required to employ static code analysis tools to identify and remediate common flaws, documenting the results of the analysis before the application is cleared for production usage.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ static code analysis tools to identify and remediate common flaws and document the results of the analysis.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ static code analysis tools to identify and remediate common flaws and document the results of the analysis. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -241760,7 +251324,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -241871,24 +251436,15 @@ "SA-11(1)-IS.1", "SA-11(1)-IS.2" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.14" - ], "emea-sau-cscc-1-2019": [ "1-3-2-1" ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2028" ], "apac-sgp-mas-trm-2021": [ "6.1.6" @@ -241918,9 +251474,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Developers of TAAS are to employ dynamic code analysis tools to identify and remediate common flaws, documenting the results of the analysis before the application is cleared for production usage.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ dynamic code analysis tools to identify and remediate common flaws and document the results of the analysis.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ dynamic code analysis tools to identify and remediate common flaws and document the results of the analysis. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -241975,7 +251531,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -242058,30 +251615,27 @@ "usa-federal-eo-14028": [ "4e(iv)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.19" - ], "emea-sau-cscc-1-2019": [ "1-3-2-1" ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2028" ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-mys-bnm-rmit-2025": [ + "10.14" ], "apac-sgp-mas-trm-2021": [ "6.1.6" ], "americas-can-osfi-b13-2022": [ "3.2.9" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.9" ] } }, @@ -242105,7 +251659,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, implements a process to check the validity of information inputs.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize testing methods to ensure Technology Assets, Applications and/or Services (TAAS) continue to operate as intended when subject to invalid or unexpected inputs on its interfaces.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -242162,7 +251716,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -242228,21 +251783,12 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.24" - ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2057" ], "apac-nzl-ism-3-9": [ "14.5.6.C.01" @@ -242272,7 +251818,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform application-level penetration testing of custom-made Technology Assets, Applications and/or Services (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -242331,7 +251877,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -242439,29 +251986,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.3", - "17.15", - "17.17" - ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402" ], "apac-nzl-ism-3-9": [ "14.5.6.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.6" ] } }, @@ -242485,7 +252017,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement secure configuration settings by default to reduce the likelihood of Technology Assets, Applications and/or Services (TAAS) being deployed with weak security settings that would put the TAAS at a greater risk of compromise.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -242548,7 +252080,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -242591,11 +252124,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.8(a)" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-3" + "apac-aus-ism-2026-march": [ + "ISM-0383", + "ISM-2042", + "ISM-2044" ], - "apac-aus-ism-2024-june": [ - "ISM-0383" + "apac-aus-cop-sitc-2020": [ + "4" ] } }, @@ -242617,7 +252152,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ a manual code review process to identify and remediate unique flaws that require knowledge of the application’s requirements and design.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -242671,7 +252206,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -242707,7 +252243,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to approve, document and control the use of live data in development and test environments.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -242760,7 +252296,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -242808,10 +252345,7 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(f)" ], - "emea-isr-cmo-1-0": [ - "10.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1420" ], "apac-jpn-ismap": [ @@ -242823,9 +252357,6 @@ "14.3.1.4", "14.3.1.5", "14.3.1.6" - ], - "apac-sgp-mas-trm-2021": [ - "11.1.6" ] } }, @@ -242847,11 +252378,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure the integrity of test data through existing security, compliance and resilience controls.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -242897,15 +252428,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "emea-eu-nis2-annex-2024": [ "6.2.2(e)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402" ] } @@ -242928,7 +252459,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain awareness of component authenticity by developing and implementing Product Tampering and Counterfeiting (PTC) practices that include the means to detect and prevent counterfeit components.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -243000,7 +252531,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -243013,7 +252545,7 @@ "general-cis-csc-8-1-ig3": [ "16.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1059.002", "T1195", "T1195.001", @@ -243099,6 +252631,19 @@ "SR-11", "SR-11(3)" ], + "general-nist-800-172-r3": [ + "03.17.02E", + "03.17.03E", + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.02E.ODP[04]", + "DS-A.03.17.03E.b", + "A.03.17.03E.ODP[01]", + "DS-A.03.17.05E[01]", + "A.03.17.05E.ODP[01]", + "DS-A.03.17.05E[02]" + ], "general-sparta": [ "CM0024", "CM0028" @@ -243126,10 +252671,7 @@ "SR-10", "SR-11" ], - "emea-isr-cmo-1-0": [ - "17.21" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1790", "ISM-1791", "ISM-1792" @@ -243154,9 +252696,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to train personnel to detect counterfeit system components, including hardware, software and firmware.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to train personnel to detect counterfeit system components, including hardware, software and firmware. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -243224,7 +252766,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -243261,6 +252804,12 @@ "general-nist-800-161-r1-level-3": [ "SR-11(1)" ], + "general-nist-800-172-r3": [ + "03.02.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.04E" + ], "general-sparta": [ "CM0024" ], @@ -243278,9 +252827,6 @@ ], "usa-federal-irs-1075-2021": [ "SR-11(CE-1)" - ], - "emea-isr-cmo-1-0": [ - "17.21" ] } }, @@ -243294,7 +252840,7 @@ "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "N/A", - "nist_csf_function": "Protect", + "nist_csf_function": "N/A", "scrm_focus": { "strategic": false, "operational": false, @@ -243304,7 +252850,7 @@ "0": "N/A", "1": "N/A", "2": "N/A", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ [deprecated - incorporated into AST-09]\nAn implemented and operational capability exists to dispose of system components using organization-defined techniques and methods to prevent such components from entering the gray market.", + "3": "N/A", "4": "N/A", "5": "N/A" }, @@ -243349,7 +252895,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -243416,91 +252962,331 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" + ], + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "general-cis-csc-8-1": [ + "16.7", + "16.11" + ], + "general-cis-csc-8-1-ig2": [ + "16.7", + "16.11" + ], + "general-cis-csc-8-1-ig3": [ + "16.7", + "16.11" + ], + "general-csa-iot-2": [ + "SDV-03", + "SDV-05" + ], + "general-nist-800-53-r4": [ + "SA-20" + ], + "general-nist-800-53-r5-2": [ + "PM-30(01)", + "SA-20", + "SA-23" + ], + "general-nist-800-53-r5-2-privacy": [ + "PM-30(01)", + "SA-23" + ], + "general-nist-800-82-r3": [ + "PM-30(01)", + "SA-20", + "SA-23" + ], + "general-nist-800-82-r3-low": [ + "PM-30(01)" + ], + "general-nist-800-82-r3-mod": [ + "PM-30(01)" + ], + "general-nist-800-82-r3-high": [ + "PM-30(01)" + ], + "general-nist-800-160-vol-2-r1": [ + "PM-30(01)", + "SA-20", + "SA-23" + ], + "general-nist-800-161-r1": [ + "SA-20" + ], + "general-nist-800-161-r1-level-2": [ + "SA-20" + ], + "general-nist-800-161-r1-level-3": [ + "SA-20" + ], + "usa-federal-gsa-fedramp-5-low": [ + "PM-30(01)", + "SA-23" + ], + "usa-federal-gsa-fedramp-5-mod": [ + "PM-30(01)", + "SA-23" + ], + "usa-federal-gsa-fedramp-5-high": [ + "PM-30(01)", + "SA-23" + ], + "usa-federal-gsa-fedramp-5-li-saas": [ + "PM-30(01)", + "SA-23" + ] + } + }, + { + "control_id": "TDA-13", + "title": "Developer Screening", + "family": "TDA", + "description": "Mechanisms exist to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", + "scf_question": "Does the organization ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "People", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Document and communicate security vulnerabilities in released software", + "small": "∙ Document and communicate security vulnerabilities in released software", + "medium": "∙ Formal coordinated vulnerability disclosure (CVD) policy and process", + "large": "∙ Enterprise vulnerability disclosure program (VDP)\n∙ CNA enrollment if applicable", + "enterprise": "∙ Enterprise vulnerability disclosure program (VDP)\n∙ Bug bounty integration (e.g., HackerOne, Bugcrowd)\n∙ CVE/CNA participation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "general-nist-800-53-r4": [ + "SA-21" + ], + "general-nist-800-53-r5-2": [ + "SA-21" + ], + "general-nist-800-53-r5-2-high": [ + "SA-21" + ], + "general-nist-800-82-r3": [ + "SA-21" + ], + "general-nist-800-82-r3-high": [ + "SA-21" + ], + "general-nist-800-161-r1": [ + "SA-21", + "SA-21(1)" + ], + "general-nist-800-161-r1-flowdown": [ + "SA-21" + ], + "general-nist-800-161-r1-level-2": [ + "SA-21", + "SA-21(1)" + ], + "general-nist-800-161-r1-level-3": [ + "SA-21", + "SA-21(1)" + ], + "general-pci-dss-4-0-1": [ + "6.2.2" + ], + "general-pci-dss-4-0-1-saq-a-ep": [ + "6.2.2" + ], + "general-pci-dss-4-0-1-saq-c": [ + "6.2.2" + ], + "general-pci-dss-4-0-1-saq-d-merchant": [ + "6.2.2" + ], + "general-pci-dss-4-0-1-saq-d-service-provider": [ + "6.2.2" + ], + "usa-federal-gsa-fedramp-5-high": [ + "SA-21" + ], + "emea-eu-nis2-annex-2024": [ + "10.2.1" + ] + } + }, + { + "control_id": "TDA-13.1", + "title": "Developer Knowledge & Skills Register", + "family": "TDA", + "description": "Mechanisms exist to maintain a cybersecurity knowledge and skills register for developers.", + "scf_question": "Does the organization maintain a cybersecurity knowledge and skills register for developers?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a cybersecurity knowledge and skills register for developers.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Note: Formal developer skills register typically not required at this size\n∙ Track relevant security certifications for development staff", + "small": "∙ Simple skills inventory for development team security knowledge\n∙ Track SSDP training completion", + "medium": "∙ Developer cybersecurity skills register\n∙ Skills gap analysis against SSDP requirements\n∙ Integration with HR and training records", + "large": "∙ Formal developer security knowledge and skills register\n∙ Annual skills assessment and gap analysis\n∙ Integration with training and professional development program", + "enterprise": "∙ Enterprise developer security skills management program\n∙ Automated skills tracking in HR platform\n∙ Skills gap analysis tied to learning pathways\n∙ Integration with workforce planning" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" ], + "errata": "- new control - ISM 2039", "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-cis-csc-8-1": [ - "16.7", - "16.11" - ], - "general-cis-csc-8-1-ig2": [ - "16.7", - "16.11" - ], - "general-cis-csc-8-1-ig3": [ - "16.7", - "16.11" - ], - "general-csa-iot-2": [ - "SDV-03", - "SDV-05" - ], - "general-nist-800-53-r4": [ - "SA-20" - ], - "general-nist-800-53-r5-2": [ - "PM-30(01)", - "SA-20", - "SA-23" - ], - "general-nist-800-53-r5-2-privacy": [ - "PM-30(01)", - "SA-23" - ], - "general-nist-800-82-r3": [ - "PM-30(01)", - "SA-20", - "SA-23" - ], - "general-nist-800-82-r3-low": [ - "PM-30(01)" - ], - "general-nist-800-82-r3-mod": [ - "PM-30(01)" - ], - "general-nist-800-82-r3-high": [ - "PM-30(01)" - ], - "general-nist-800-160-vol-2-r1": [ - "PM-30(01)", - "SA-20", - "SA-23" - ], - "general-nist-800-161-r1": [ - "SA-20" - ], - "general-nist-800-161-r1-level-2": [ - "SA-20" - ], - "general-nist-800-161-r1-level-3": [ - "SA-20" - ], - "usa-federal-gsa-fedramp-5-low": [ - "PM-30(01)", - "SA-23" - ], - "usa-federal-gsa-fedramp-5-mod": [ - "PM-30(01)", - "SA-23" - ], - "usa-federal-gsa-fedramp-5-high": [ - "PM-30(01)", - "SA-23" - ], - "usa-federal-gsa-fedramp-5-li-saas": [ - "PM-30(01)", - "SA-23" + "apac-aus-ism-2026-march": [ + "ISM-2038" ] } }, { - "control_id": "TDA-13", - "title": "Developer Screening", + "control_id": "TDA-13.2", + "title": "Developer Training", "family": "TDA", - "description": "Mechanisms exist to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", - "scf_question": "Does the organization ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations?", - "relative_weight": 9, + "description": "Mechanisms exist to ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP).", + "scf_question": "Does the organization ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP)?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "People", @@ -243512,19 +253298,19 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { - "micro_small": "∙ Document and communicate security vulnerabilities in released software", - "small": "∙ Document and communicate security vulnerabilities in released software", - "medium": "∙ Formal coordinated vulnerability disclosure (CVD) policy and process", - "large": "∙ Enterprise vulnerability disclosure program (VDP)\n∙ CNA enrollment if applicable", - "enterprise": "∙ Enterprise vulnerability disclosure program (VDP)\n∙ Bug bounty integration (e.g., HackerOne, Bugcrowd)\n∙ CVE/CNA participation" + "micro_small": "∙ Free OWASP and SANS resources for developer security training.\n∙ Online SSDP training (e.g., Secure Code Warrior free tier)", + "small": "∙ OWASP resources and Secure Code Warrior free tier (https://securecodewarrior.com)\n∙ Annual developer security training requirement", + "medium": "∙ Secure coding training platform (e.g., Secure Code Warrior, Snyk Learn)\n∙ Role-based training for developers on SSDP\n∙ Annual required training completion", + "large": "∙ Enterprise secure coding training platform (e.g., Secure Code Warrior)\n∙ Mandatory annual training tied to developer roles\n∙ Training effectiveness measurement", + "enterprise": "∙ Enterprise developer security training program\n∙ Role-based SSDP training with LMS integration\n∙ Secure Code Warrior or equivalent at scale\n∙ Skills-gap based personalized learning paths" }, "risks": [ "R-AC-1", @@ -243579,63 +253365,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- new control - ISM 2038", "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-nist-800-53-r4": [ - "SA-21" - ], - "general-nist-800-53-r5-2": [ - "SA-21" - ], - "general-nist-800-53-r5-2-high": [ - "SA-21" - ], - "general-nist-800-82-r3": [ - "SA-21" - ], - "general-nist-800-82-r3-high": [ - "SA-21" - ], - "general-nist-800-161-r1": [ - "SA-21", - "SA-21(1)" - ], - "general-nist-800-161-r1-flowdown": [ - "SA-21" - ], - "general-nist-800-161-r1-level-2": [ - "SA-21", - "SA-21(1)" - ], - "general-nist-800-161-r1-level-3": [ - "SA-21", - "SA-21(1)" - ], - "general-pci-dss-4-0-1": [ - "6.2.2" - ], - "general-pci-dss-4-0-1-saq-a-ep": [ - "6.2.2" - ], - "general-pci-dss-4-0-1-saq-c": [ - "6.2.2" - ], - "general-pci-dss-4-0-1-saq-d-merchant": [ - "6.2.2" - ], - "general-pci-dss-4-0-1-saq-d-service-provider": [ - "6.2.2" - ], - "usa-federal-gsa-fedramp-5-high": [ - "SA-21" - ], - "emea-eu-nis2-annex-2024": [ - "10.2.1" - ], - "emea-deu-c5-2020": [ - "DEV-02" + "apac-aus-ism-2026-march": [ + "ISM-2037" ] } }, @@ -243662,7 +253399,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to perform configuration management during system design, development, implementation and operation.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -243739,7 +253476,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -243773,7 +253511,7 @@ "8.30", "8.32" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1072", "T1078", "T1078.001", @@ -243864,11 +253602,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-10" ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ] } }, @@ -243895,11 +253630,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of software and firmware components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of software and firmware components. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -243962,7 +253697,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -243999,9 +253735,6 @@ "general-nist-800-82-r3": [ "SA-10(01)" ], - "general-nist-800-172": [ - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -244022,9 +253755,6 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.1(c)" - ], - "emea-isr-cmo-1-0": [ - "17.20" ] } }, @@ -244051,7 +253781,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -244118,7 +253848,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -244131,9 +253862,6 @@ "general-nist-800-82-r3": [ "SA-10(03)" ], - "general-nist-800-172": [ - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -244147,7 +253875,7 @@ "title": "Developer Threat Analysis & Flaw Remediation", "family": "TDA", "description": "Mechanisms exist to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", - "scf_question": "Does the organization require system developers and integrators to create a Security Testing and Evaluation (ST&E) plan and implement the plan under the witness of an independent party?", + "scf_question": "Does the organization require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -244160,7 +253888,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -244227,7 +253955,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -244398,32 +254127,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)", - "3.6.2(69)", - "3.6.2(70)" - ], "emea-eu-nis2-2022": [ "Article 21.4" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.13" - ], - "emea-sau-cscc-1-2019": [ - "1-3-2-1" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-3-4" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.6" - ], - "amaericas-can-osfi-self-assessment": [ - "2.7" ] } }, @@ -244445,7 +254150,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -244509,7 +254214,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -244528,7 +254234,7 @@ "general-govramp-high": [ "SA-16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078.001", "T1078.003", "T1574.002" @@ -244559,9 +254265,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SA-16" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" ] } }, @@ -244585,7 +254288,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, provides in-house support or contract external providers for support with unsupported system components.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -244665,7 +254368,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -244681,7 +254385,7 @@ "general-cis-csc-8-1-ig3": [ "2.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1189", "T1195", "T1195.001", @@ -244744,9 +254448,6 @@ "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "7.5" - ], "usa-federal-fbi-cjis-6-0": [ "SA-22" ], @@ -244782,8 +254483,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-22" ], - "emea-isr-cmo-1-0": [ - "12.23" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-51" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "3-BP2" ], "apac-aus-essential-8-2024": [ "ML1-P1", @@ -244793,13 +254497,22 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0304", "ISM-1501", "ISM-1704", - "ISM-1753" + "ISM-1753", + "ISM-1848", + "ISM-1981", + "ISM-1982" + ], + "apac-aus-cop-sitc-2020": [ + "3" + ], + "apac-mys-bnm-rmit-2025": [ + "10.17" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP43", "HML43" ], @@ -244808,16 +254521,17 @@ ], "apac-sgp-mas-trm-2021": [ "7.3.1", - "7.3.2", "7.3.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.6", - "4.9" + "americas-bmu-mba-coc-2020": [ + "6.16" ], "americas-can-osfi-b13-2022": [ "2.2.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.02.A" ] @@ -244841,9 +254555,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS). ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -244920,7 +254634,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -245005,9 +254720,6 @@ "emea-eu-dora-2023": [ "Article 28.8 (end)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.3 [OP.EXT.3]" - ], "americas-can-itsp-10-171-2025": [ "03.16.02.B" ] @@ -245031,11 +254743,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to check the validity of information inputs.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to check the validity of information inputs. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -245090,7 +254802,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -245158,7 +254871,7 @@ "general-iec-62443-4-2-2019": [ "CR 3.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.002", "T1021.005", "T1027.010", @@ -245384,6 +255097,13 @@ "SI-5", "SI-7" ], + "general-nist-800-172-r3": [ + "03.14.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.12E", + "A.03.14.12E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A08:2025" ], @@ -245485,11 +255205,11 @@ "SI-07", "SI-10" ], - "emea-isr-cmo-1-0": [ - "17.22" - ], "emea-sau-sacs-002-2022": [ - "TPC-60" + "VII.B.TPC-60" + ], + "apac-aus-ism-2026-march": [ + "ISM-2059" ], "apac-jpn-ismap": [ "14.2.5.9" @@ -245514,7 +255234,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to handle error conditions by: \n(1) Identifying potentially security-relevant error conditions;\n(2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n(3) Revealing error messages only to authorized personnel.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -245568,7 +255288,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -245611,6 +255332,13 @@ "general-nist-800-82-r3-high": [ "SI-11" ], + "general-nist-800-172-r3": [ + "03.14.13E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.13E.a", + "DS-A.03.14.13E.b" + ], "general-owasp-top-10-2025": [ "A08:2025", "A10:2025" @@ -245635,14 +255363,98 @@ "usa-state-tx-txramp-2-0-level-2": [ "SI-11" ], - "emea-deu-c5-2020": [ - "PSS-04" - ], - "emea-isr-cmo-1-0": [ - "17.23" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-61" + ] + } + }, + { + "control_id": "TDA-19.1", + "title": "Designated Roles To View Error Messages", + "family": "TDA", + "description": "Mechanisms exist to:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s).", + "scf_question": "Does the organization:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s)?", + "relative_weight": 6, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Configure error messages to suppress technical details from end users\n∙ Role-based access to application error logs", + "small": "∙ Application configuration to display generic errors to end users\n∙ Technical error details restricted to authorized administrators", + "medium": "∙ Error message configuration standards\n∙ Role-based access to error logs and detailed messages\n∙ Centralized log management with access controls", + "large": "∙ Enterprise error message governance standard\n∙ Role-based log access controls\n∙ Automated testing for information disclosure via error messages", + "enterprise": "∙ Enterprise error handling standard with automated enforcement\n∙ Centralized SIEM with role-based log access\n∙ Automated security testing for error message information disclosure\n∙ Integration with code review and CI/CD security gates" + }, + "risks": [ + "R-AC-3", + "R-AC-4", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "general-nist-800-172a-r3": [ + "A.03.14.13E.ODP[01]" ], "emea-sau-sacs-002-2022": [ - "TPC-61" + "VII.B.TPC-61" ] } }, @@ -245664,9 +255476,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, uses a Source Code Manager (SCM) solution to govern modifying, copying, deleting, moving and renaming items in the software library.\n▪ SCM supports integrity checking on the source code repository.\n▪ SCM uses Role-Based Access Controls (RBAC) to limit the logical access and permissions for users in the software library.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit privileges to change software resident within software libraries.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit privileges to change software resident within software libraries. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -245731,7 +255543,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -245819,15 +255632,18 @@ "SA-04 (02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(73)" + "3.6.2.73" ], "emea-deu-bsrit-2017": [ "7.9" ], "emea-deu-c5-2020": [ - "DEV-07" + "IDM-13" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "1-3-2-2" + ], + "apac-aus-ism-2026-march": [ "ISM-1422" ], "apac-jpn-ismap": [ @@ -245843,12 +255659,18 @@ "9.4.5.9", "14.2.1.5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP42", "HML42" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP37" + ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" ] } }, @@ -245870,7 +255692,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to publish integrity verification information for software releases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -245924,7 +255746,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -245964,7 +255787,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to archive software releases and all of their components (e.g., code, package files, third-party libraries, documentation) to maintain integrity verification information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -246018,7 +255841,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -246028,6 +255852,9 @@ "general-nist-800-218": [ "PS.3", "PS.3.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } }, @@ -246051,9 +255878,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to escrow source code and supporting documentation to ensure software availability in the event the software provider goes out of business or is unable to provide support.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to escrow source code and supporting documentation to ensure software availability in the event the software provider goes out of business or is unable to provide support. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -246091,7 +255918,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -246110,6 +255938,9 @@ "apac-jpn-ismap": [ "14.2.7.8" ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], "apac-sgp-mas-trm-2021": [ "5.3.4" ] @@ -246133,7 +255964,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to govern the approval of binaries and code for production use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -246194,7 +256025,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -246230,7 +256062,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure developed Technology Assets, Applications and/or Services (TAAS) conform to applicable statutory and regulatory requirements, based on the product's and/or service's:\n(1) Use case(s); and\n(2) Geographic markets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -246296,7 +256128,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -246337,8 +256170,8 @@ "Article 53.1(c)", "Article 111.3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.12" + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } }, @@ -246360,7 +256193,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate appropriate technical documentation artifacts for Technology Assets, Applications and/or Services (TAAS) in sufficient detail to demonstrate conformity with applicable statutory, regulatory and contractual compliance requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -246426,7 +256259,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -246435,9 +256269,6 @@ "MP-4.1-010", "MS-2.9-001" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], @@ -246447,32 +256278,6 @@ "Article 17.1(k)", "Article 23.1(b)", "Article 53.1(a)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.7", - "Article 13.2(b)", - "Article 23.1", - "Article 23.2", - "Article 23.3", - "Article 23.4" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 5", - "Annex 5.1", - "Annex 5.1(a)", - "Annex 5.1(b)", - "Annex 5.1(c)", - "Annex 5.1(d)", - "Annex 5.2", - "Annex 5.2(a)", - "Annex 5.2(b)", - "Annex 5.2(c)", - "Annex 5.3", - "Annex 5.4", - "Annex 5.5", - "Annex 5.6", - "Annex 5.7", - "Annex 6 Module A.2" ] } }, @@ -246494,7 +256299,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to include a detailed cybersecurity risk assessment in the technical documentation for Technology Assets, Applications and/or Services (TAAS) to demonstrate applicable risks in approved use cases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -246557,15 +256362,13 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { "general-shared-assessments-sig-2025": [ "C.4" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.3" ] } }, @@ -246690,7 +256493,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -246719,7 +256523,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0", + "15", "15.2" ], "general-cis-csc-8-1-ig2": [ @@ -246871,9 +256675,19 @@ "03.01.20.c.01", "03.07.06.a", "03.16.01", - "03.16.03.a" + "03.16.03.a", + "03.17.02" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.07.06.a", + "A.03.16.01", + "A.03.16.03.a", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.02[06]", "A.03.17.03.ODP[01]" ], "general-nist-csf-2-0": [ @@ -246929,10 +256743,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "10.0", - "11.0" - ], "general-sparta": [ "CM0025" ], @@ -247006,12 +256816,12 @@ "314.4(f)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "1.9.3", @@ -247055,8 +256865,7 @@ "2447(b)(6)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(7)", - "3.6.2(74)" + "3.2.3.7" ], "emea-eu-dora-2023": [ "Article 30.3 (end)", @@ -247070,62 +256879,43 @@ "emea-eu-nis2-annex-2024": [ "6.2.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "9.1" ], "emea-deu-c5-2020": [ - "SSO-01", - "SSO-03" + "UP-01", + "DLL-01", + "DLL-02" ], - "emea-isr-cmo-1-0": [ - "11.3", - "11.10", - "16.1", - "17.3" + "emea-isr-cmo-2-0": [ + "Appendix A, 10.1" ], "emea-sau-cscc-1-2019": [ - "4-1" + "4-1-1" ], "emea-sau-ecc-1-2018": [ - "1-5-3-3", "4-1-1", - "4-1-2", - "4-1-3", - "4-1-4" + "4-1-3-2" ], "emea-sau-otcc-1-2022": [ - "4-1", "4-1-1", - "4-1-1-1", - "4-1-1-2", - "4-1-1-3", - "4-1-1-4", "4-1-2" ], "emea-sau-sama-csf-1-2017": [ "3.4.1", - "3.4.2" - ], - "emea-zaf-popia-2013": [ - "20", - "21" + "3.4.1.1", + "3.4.1.4", + "3.4.1.4.a", + "3.4.1.6", + "3.4.1.6.a", + "3.4.2.1" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-caf-4-0": [ "A4" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -247138,66 +256928,24 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1073", "ISM-1785" ], "apac-aus-ps-cps-230-2023": [ - "15", + "12(c)", + "16(f)", "47", + "48", "48(a)", "48(b)", - "48(c)", - "57" - ], - "apac-aus-ps-cps-234-2019": [ - "16", - "20", - "22", - "28" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)", - "42", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "48(c)" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1", "PR.IP.S15" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "24(3)" - ], "apac-jpn-ismap": [ "4.5.3.1", "5.1.1.20", @@ -247220,7 +256968,13 @@ "15.1.1.13", "15.1.1.14.B" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.24", + "10.25", + "10.46" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HML25" ], @@ -247234,24 +256988,19 @@ ], "apac-sgp-mas-trm-2021": [ "3.4.1", - "3.4.2", - "3.4.3", - "9.1.8" + "8.3.4" ], "americas-bmu-mba-coc-2020": [ "5.10" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.B", "03.01.20.C.01", "03.07.06.A", "03.16.01", - "03.16.03.A" + "03.16.03.A", + "03.17.02" ] } }, @@ -247276,7 +257025,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A procurement function maintains a list of all active External Service Providers (ESPs), including pertinent contract information that will assist in a risk assessment.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to maintain a current, accurate and complete list of External Service Providers (ESPs) that can potentially impact the Confidentiality, Integrity, Availability and/or Safety (CIAS) of the organization's TAASD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -247346,7 +257095,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -247396,7 +257146,11 @@ "SR-13" ], "general-nist-800-171-r3": [ - "03.07.06.a" + "03.07.06.a", + "03.07.06.b" + ], + "general-nist-800-171a-r3": [ + "A.03.07.06.b" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -247502,7 +257256,10 @@ "5.2", "5.2(a)" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" + ], + "apac-aus-ism-2026-march": [ "ISM-1631", "ISM-1637", "ISM-1638", @@ -247511,7 +257268,8 @@ "ISM-1786" ], "apac-aus-ps-cps-230-2023": [ - "49" + "49", + "51" ], "apac-ind-sebi-2024": [ "GV.OC.S3", @@ -247519,7 +257277,8 @@ "GV.SC.S2" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A" + "03.07.06.A", + "03.07.06.B" ] } }, @@ -247543,7 +257302,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to identify, prioritize and assess suppliers and partners of critical Technology Assets, Applications and/or Services (TAAS) using a supply chain risk assessment process relative to their importance in supporting the delivery of high-value services.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -247641,7 +257400,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -247738,6 +257498,16 @@ "03.11.01.a", "03.17.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.03.a[01]" + ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[01]" + ], "general-nist-csf-2-0": [ "GV.OC-04", "GV.OC-05", @@ -247748,9 +257518,6 @@ "ID.AM-05", "ID.RA-10" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-sparta": [ "CM0022" ], @@ -247801,10 +257568,10 @@ "314.4(f)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -247819,53 +257586,51 @@ "500.11(a)(1)", "500.11(a)(4)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.3.2.16" + ], "emea-eu-dora-2023": [ "Article 8.4" ], "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-deu-c5-2020": [ - "SSO-02", - "SSO-03" - ], - "emea-isr-cmo-1-0": [ - "16.1", - "16.6" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1" ], - "emea-sau-otcc-1-2022": [ - "4-1-1-2" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1452" ], "apac-aus-ps-cps-230-2023": [ + "15", + "49", + "50", "50(a)", "50(b)", "50(c)", "50(d)", - "52" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "51" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1", "GV.SC.S2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "10.46" + ], "apac-nzl-ism-3-9": [ "12.7.17.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.27" + "apac-sgp-mas-trm-2021": [ + "5.3.1" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", @@ -247878,7 +257643,7 @@ "title": "Supply Chain Risk Management (SCRM)", "family": "TPM", "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", - "scf_question": "Does the organization:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary?", + "scf_question": "Does the organization:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize its exposure to those risks and threats, as necessary?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -247893,11 +257658,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -247993,7 +257758,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -248101,6 +257867,12 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC", "GV.SC-06", @@ -248111,9 +257883,6 @@ "A03:2025", "A05:2025" ], - "general-scf-dpmp-2025": [ - "10.1" - ], "general-sparta": [ "CM0026", "CM0027" @@ -248180,11 +257949,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-02" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.4" - ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" + "3.7.3.86" ], "emea-eu-dora-2023": [ "Article 30.3(f)" @@ -248197,37 +257963,22 @@ "5.1.6" ], "emea-deu-c5-2020": [ - "SSO-02", - "SSO-03" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.1", - "16.3", - "16.5", - "17.3", - "17.11" - ], - "emea-pol-act-29-1997": [ - "31" + "PS-04-DOAR" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "emea-sau-sama-csf-1-2017": [ - "3.4.2" - ], - "emea-zaf-popia-2013": [ - "20" + "emea-sau-ecc-1-2018": [ + "4-1-3-1" ], - "emea-esp-decree-1720-2007": [ - "20", - "21" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2", + "op.ext.3" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]", - "7.4.3 [OP.EXT.3]" + "emea-gbr-cap-1850-2020": [ + "A4" ], "emea-gbr-def-stan-05-138-2024": [ "1400" @@ -248241,20 +257992,22 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0731", "ISM-1452", "ISM-1632", "ISM-1789" ], - "apac-aus-ps-cps-234-2019": [ - "22", - "28" + "apac-aus-ps-cps-230-2023": [ + "15" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-nzl-ism-3-9": [ "12.7.14.C.01", "12.7.14.C.02", @@ -248276,26 +258029,11 @@ "12.7.20.C.05", "12.7.21.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "43" - ], - "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.17.01.A", "03.17.03.A", "03.17.03.B" - ], - "americas-mex-fdpa-2010": [ - "21" ] } }, @@ -248317,7 +258055,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize tailored acquisition strategies, contract tools and procurement methods for the purchase of unique Technology Assets, Applications and/or Services (TAAS).", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -248386,7 +258124,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -248408,7 +258147,7 @@ "5.21", "5.22" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1059.002", "T1195", "T1195.001", @@ -248480,9 +258219,14 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.17.01.a[01]", "A.03.17.02[01]", "A.03.17.02[02]", - "A.03.17.02[03]" + "A.03.17.02[03]", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], "general-owasp-top-10-2025": [ "A03:2025" @@ -248533,9 +258277,6 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-05" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" - ], "emea-eu-dora-2023": [ "Article 29.1 (end)" ], @@ -248545,17 +258286,15 @@ "emea-deu-bsrit-2017": [ "9.3" ], - "emea-deu-c5-2020": [ - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "16.1" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.2", + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1567", "ISM-1568", "ISM-1632", @@ -248563,6 +258302,9 @@ "ISM-1788", "ISM-1789" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "americas-can-itsp-10-171-2025": [ "03.17.01.A", "03.17.02", @@ -248594,9 +258336,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize security safeguards to limit harm from potential adversaries who identify and target the organization's supply chain.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize security safeguards to limit harm from potential adversaries who identify and target the organization's supply chain. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -248692,7 +258434,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -248717,7 +258460,7 @@ ], "general-iso-27002-2022": [ "5.19", - "5.2" + "5.20" ], "general-iso-27018-2025": [ "5.19", @@ -248739,6 +258482,10 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -248771,38 +258518,17 @@ "Article 21.3" ], "emea-deu-c5-2020": [ - "SSO-02" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.2" + "UP-01-BP1" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "apac-aus-ism-2024-june": [ - "ISM-1567" - ], - "apac-aus-ps-cps-230-2023": [ - "56(a)", - "56(b)", - "56(c)", - "56(d)" - ], - "apac-aus-ps-cps-234-2019": [ - "22" - ], - "apac-chn-pipl-2021": [ - "20" - ], - "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" + "apac-aus-ism-2026-march": [ + "ISM-1567" ], "americas-can-itsp-10-171-2025": [ "03.17.03.A", @@ -248815,7 +258541,7 @@ "title": "Processes To Address Weaknesses or Deficiencies", "family": "TPM", "description": "Mechanisms exist to address identified weaknesses or deficiencies in the security of the supply chain", - "scf_question": "Does the organization address identified weaknesses or deficiencies in the security of the supply chain", + "scf_question": "Does the organization address identified weaknesses or deficiencies in the security of the supply chain?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -248835,7 +258561,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No centralized inventory of External Service Providers (ESP) is maintained.\n▪ ESP are not formally managed according to criticality.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address identified weaknesses or deficiencies in the security of the supply chain", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address identified weaknesses or deficiencies in the security of the supply chain ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -248931,7 +258657,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -248989,6 +258716,10 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -249029,8 +258760,9 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-deu-c5-2020": [ - "SSO-02" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2" ], "americas-can-itsp-10-171-2025": [ "03.17.03.A", @@ -249056,11 +258788,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to develop and implement a spare parts strategy to ensure that an adequate supply of critical components is available to meet operational needs.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to develop and implement a spare parts strategy to ensure that an adequate supply of critical components is available to meet operational needs. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -249137,7 +258869,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -249178,7 +258911,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel proactively control and monitor third-party accounts used to access, support, or maintain system components via remote access.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to mitigate the risks associated with third-party access to the organization's TAASD.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -249276,7 +259009,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -249336,7 +259070,7 @@ "A.10.2", "A.10.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -249387,6 +259121,16 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.a", + "A.03.16.03.c", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -249433,11 +259177,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.2" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.1", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -249481,10 +259220,10 @@ "314.4(f)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-irs-1075-2021": [ "2.C.9", @@ -249540,74 +259279,24 @@ "9.2" ], "emea-deu-c5-2020": [ - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.1", - "22.4" + "PS-04-DOAR" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "emea-sau-otcc-1-2022": [ - "4-1-1-3" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.5" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-36" ], - "emea-esp-decree-311-2022": [ - "13.5" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1569" ], - "apac-aus-ps-cps-234-2019": [ - "16", - "22", - "28" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)" - ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], - "americas-arg-ppd-2018": [ - "25.1" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.50" ], "americas-can-itsp-10-171-2025": [ "03.16.03.A", @@ -249640,7 +259329,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to conduct a risk assessment prior to the acquisition or outsourcing of technology-related Technology Assets, Applications and/or Services (TAAS).", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -249739,7 +259428,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -249828,7 +259518,13 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.17.03.a[01]" + "A.03.11.01.a", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.SC-06", @@ -249936,9 +259632,6 @@ "usa-state-vt-act-171-2018": [ "2447(b)(6)(A)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" - ], "emea-eu-dora-2023": [ "Article 28.4(a)", "Article 28.4(b)", @@ -249958,66 +259651,62 @@ "9.2", "9.5" ], - "emea-deu-c5-2020": [ - "SSO-02", - "SSO-04" - ], - "emea-isr-cmo-1-0": [ - "16.3", - "16.5", - "17.3" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], "emea-sau-ecc-1-2018": [ - "1-5-3-4", "4-1-3-1" ], "emea-sau-otcc-1-2022": [ - "4-1-1-2", - "4-1-1-4" - ], - "emea-sau-sama-csf-1-2017": [ - "3.4.1", - "3.4.2" + "4-1-1-2" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1568", "ISM-1573", - "ISM-1787" + "ISM-1787", + "ISM-1882" ], "apac-aus-ps-cps-230-2023": [ "15", + "53", "53(a)", "53(b)" ], "apac-aus-ps-cps-234-2019": [ - "22", - "28" + "16" ], "apac-jpn-ismap": [ "14.1.1.14", "15.1.1.16.B" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.46", + "10.47", + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HML25" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP67" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25", - "4.27" + "apac-sgp-mas-trm-2021": [ + "3.4.2", + "5.3.1", + "5.3.2", + "6.4.2", + "6.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "5.10" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", @@ -250118,7 +259807,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -250201,9 +259891,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SA-09 (02)" - ], - "emea-isr-cmo-1-0": [ - "16.3" ] } }, @@ -250227,7 +259914,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure that the interests of external service providers are consistent with and reflect organizational interests.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -250307,7 +259994,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -250362,12 +260050,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" ], - "emea-isr-cmo-1-0": [ - "16.3" - ], - "emea-zaf-popia-2013": [ - "20", - "21" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ] } }, @@ -250393,7 +260077,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to restrict the location of information processing/storage based on business requirements.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to restrict the location of information processing/storage based on business requirements. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -250489,7 +260173,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -250547,6 +260232,9 @@ "general-nist-800-171-r3": [ "03.16.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.a" + ], "general-nist-csf-2-0": [ "GV.SC-06" ], @@ -250576,9 +260264,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "3.2.1" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -250616,84 +260301,17 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-aut-fappd-2000": [ - "Sec 10" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-deu-c5-2020": [ - "PI-02", - "PSS-12" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "16.3" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1572" ], - "apac-chn-pipl-2021": [ - "21", - "38", - "38(3)", - "40" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" + "apac-mys-bnm-rmit-2025": [ + "10.50" ], "americas-can-itsp-10-171-2025": [ "03.16.03.A" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } }, @@ -250702,7 +260320,7 @@ "title": "Third-Party Contract Requirements", "family": "TPM", "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting its needs to protect its Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -250721,7 +260339,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.\n▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its TAASD.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -250820,9 +260438,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -250989,8 +260607,22 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.07.06.a", "A.03.16.03.ODP[01]", - "A.03.16.03.a" + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" + ], + "general-nist-800-172-r3": [ + "03.17.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.01E.ODP[02]" ], "general-nist-800-218": [ "PO.1" @@ -251056,9 +260688,6 @@ "12.8.2", "12.8.5" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -251132,6 +260761,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SR-03(03)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(2)" + ], "usa-federal-sro-finra": [ "248.30(a)(5)(ii)" ], @@ -251149,54 +260781,54 @@ "155.260(b)(2)(iv)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)", - "164.502(a)(4)(i)", - "164.502(a)(4)(ii)", - "164.502(e)(1)(i)", - "164.502(e)(2)", - "164.504(e)(2)(i)", - "164.504(e)(2)(i)(A)", - "164.504(e)(2)(i)(B)", - "164.504(e)(2)(ii)(J)", - "164.504(e)(4)(i)(B)(ii)(B)(1)", - "164.504(e)(4)(i)(B)(ii)(B)(2)", - "164.504(f)(1)(i)", - "164.504(f)(2)(i)", - "164.504(f)(2)(ii)", - "164.504(f)(2)(ii)(A)", - "164.504(f)(2)(ii)(B)", - "164.504(f)(2)(ii)(C)", - "164.504(f)(2)(ii)(D)", - "164.504(f)(2)(ii)(E)", - "164.504(f)(2)(ii)(F)", - "164.504(f)(2)(ii)(G)", - "164.504(f)(2)(ii)(H)", - "164.504(f)(2)(ii)(I)", - "164.504(f)(2)(ii)(J)", - "164.504(f)(2)(iii)(A)", - "164.504(f)(2)(iii)(B)", - "164.504(f)(2)(iii)(C)", - "164.504(f)(3)(i)", - "164.504(f)(3)(ii)", - "164.504(f)(3)(iii)", - "164.504(f)(3)(iv)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)", + "§ 164.502(a)(4)(i)", + "§ 164.502(a)(4)(ii)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(2)", + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(i)(A)", + "§ 164.504(e)(2)(i)(B)", + "§ 164.504(e)(2)(ii)(J)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(1)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(2)", + "§ 164.504(f)(1)(i)", + "§ 164.504(f)(2)(i)", + "§ 164.504(f)(2)(ii)", + "§ 164.504(f)(2)(ii)(A)", + "§ 164.504(f)(2)(ii)(B)", + "§ 164.504(f)(2)(ii)(C)", + "§ 164.504(f)(2)(ii)(D)", + "§ 164.504(f)(2)(ii)(E)", + "§ 164.504(f)(2)(ii)(F)", + "§ 164.504(f)(2)(ii)(G)", + "§ 164.504(f)(2)(ii)(H)", + "§ 164.504(f)(2)(ii)(I)", + "§ 164.504(f)(2)(ii)(J)", + "§ 164.504(f)(2)(iii)(A)", + "§ 164.504(f)(2)(iii)(B)", + "§ 164.504(f)(2)(iii)(C)", + "§ 164.504(f)(3)(i)", + "§ 164.504(f)(3)(ii)", + "§ 164.504(f)(3)(iii)", + "§ 164.504(f)(3)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "3.3.1.g", @@ -251283,9 +260915,9 @@ "2447(b)(6)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8", + "3.2.3.8(a)", + "3.2.3.8(b)" ], "emea-eu-dora-2023": [ "Article 28.1(a)", @@ -251343,28 +260975,21 @@ "9.4" ], "emea-deu-c5-2020": [ - "HR-06", - "PI-02", - "SSO-02", - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "11.1", - "11.3", - "11.10", - "16.2", - "19.5", - "22.4", - "25.17" - ], - "emea-pol-act-29-1997": [ - "31" + "UP-01-BP1", + "UP-01-BP6", + "UP-03", + "OIS-03", + "DLL-01", + "DLL-01-BP1", + "DLL-01-BP2", + "DLL-01-BP3", + "DLL-01-BP4", + "BCM-05" ], "emea-qat-pdppl-2020": [ - "12" + "3.11.8" ], "emea-sau-cscc-1-2019": [ - "4-1-1", "4-1-1-1", "4-1-1-2" ], @@ -251373,7 +260998,6 @@ "4-2-5" ], "emea-sau-ecc-1-2018": [ - "4-1-2", "4-1-2-1", "4-1-2-2", "4-1-2-3" @@ -251386,21 +261010,26 @@ "Article 8" ], "emea-sau-sacs-002-2022": [ - "TPC-25" - ], - "emea-srb-act-9-2018": [ - "5", - "11" + "VII.A.TPC-17", + "VII.A.TPC-23-BP2" ], - "emea-zaf-popia-2013": [ - "20" - ], - "emea-esp-decree-1720-2007": [ - "20", - "21" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]" + "emea-sau-sama-csf-1-2017": [ + "3.4.1.4.b", + "3.4.1.4.c", + "3.4.1.5", + "3.4.1.5.a", + "3.4.1.5.b", + "3.4.1.5.c", + "3.4.1.5.d", + "3.4.1.5.e", + "3.4.1.5.f", + "3.4.1.5.g" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.3", + "mp.com.2", + "mp.com.3" ], "emea-gbr-def-stan-05-138-2024": [ "1401", @@ -251418,7 +261047,7 @@ "1401", "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0072", "ISM-1395", "ISM-1451", @@ -251432,31 +261061,27 @@ ], "apac-aus-ps-cps-230-2023": [ "15", + "16(f)", + "54", "54(a)", "54(b)", "54(c)", "54(d)", "54(e)", "54(f)", - "54(g)", + "55", "55(a)", "55(b)", - "55(c)" - ], - "apac-aus-ps-cps-234-2019": [ - "16", - "20", - "28" + "55(c)", + "56", + "56(a)", + "56(b)", + "56(c)", + "56(d)" ], "apac-chn-cybersecurity-law-2017": [ "Article 36" ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)", - "42" - ], "apac-ind-dpdpa-2023": [ "8(7)(b)" ], @@ -251466,29 +261091,6 @@ "GV.SC.S8", "PR.AT.S3" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], "apac-jpn-ismap": [ "6.3.P", "7.1.1.11", @@ -251533,7 +261135,15 @@ "15.1.3.11.P", "15.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.24", + "10.25", + "10.46", + "10.48", + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP09", "HHSP36", "HHSP72", @@ -251541,30 +261151,28 @@ "HML36", "HML72" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS06" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP63", "HSUP68" ], "apac-nzl-ism-3-9": [ "2.3.30.C.01", + "20.1.20.C.05", + "20.1.23.C.02", + "20.1.23.C.03", + "20.1.24.C.01", + "20.1.25.C.01", "23.2.19.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "43" - ], "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2", - "3.4.3" + "3.4.2" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.26", - "4.28" + "americas-bmu-mba-coc-2020": [ + "5.10", + "5.11-BP2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.8.1" ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", @@ -251576,9 +261184,6 @@ "03.16.03.C", "03.17.02", "03.17.03.B" - ], - "americas-mex-fdpa-2010": [ - "21" ] } }, @@ -251600,7 +261205,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to compel External Service Providers (ESPs) to provide notification of actual or potential compromises in the supply chain that can potentially affect or have adversely affected Technology Assets, Applications and/or Services (TAAS) that the organization utilizes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -251697,7 +261302,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -251751,6 +261357,16 @@ "general-nist-800-171-r3": [ "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.17.02[05]" + ], + "general-nist-800-172-r3": [ + "03.17.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.01E", + "A.03.17.01E.ODP[01]" + ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -251776,16 +261392,16 @@ "SR-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)", - "164.410(a)(1)", - "164.410(a)(2)", - "164.410(b)", - "164.410(c)(2)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)", + "§ 164.410(a)(1)", + "§ 164.410(a)(2)", + "§ 164.410(b)", + "§ 164.410(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)" ], "usa-federal-nerc-cip-2024": [ "CIP-013-2 1.2.1" @@ -251802,9 +261418,18 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-08" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "RB-20" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1576" ], + "apac-mys-bnm-rmit-2025": [ + "10.49" + ], "apac-nzl-ism-3-9": [ "7.2.22.C.01", "7.2.23.C.01" @@ -251834,7 +261459,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.\n▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure applicable security, compliance and resilience requirements are included in contracts that flow-down to applicable sub-contractors and suppliers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -251910,9 +261535,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -251967,7 +261592,12 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.16.03.ODP[01]" + "A.03.16.03.ODP[01]", + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.OC-03", @@ -251976,9 +261606,6 @@ "GV.SC-06", "GV.SC-10" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -252030,18 +261657,18 @@ "155.260(b)(2)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)", - "164.502(e)(1)(ii)", - "164.504(e)(2)(ii)(D)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)", + "§ 164.502(e)(1)(ii)", + "§ 164.504(e)(2)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SR-3(CE-3)" @@ -252071,9 +261698,7 @@ "59.1-579.B.5" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8" ], "emea-eu-dora-2023": [ "Article 29.2" @@ -252084,15 +261709,17 @@ "emea-eu-nis2-annex-2024": [ "5.1.4(g)" ], - "emea-qat-pdppl-2020": [ - "12" + "emea-deu-bsrit-2017": [ + "9.4" ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "emea-deu-c5-2020": [ + "UP-01-BP6", + "DLL-01-BP2", + "DLL-01-BP4", + "DLL-01-DOAR" ], - "emea-srb-act-9-2018": [ - "5", - "11" + "emea-sau-ecc-1-2018": [ + "4-1-2-3" ], "emea-gbr-def-stan-05-138-2024": [ "1401" @@ -252113,6 +261740,9 @@ "GV.SC.S3", "GV.SC.S8" ], + "apac-mys-bnm-rmit-2025": [ + "10.48" + ], "americas-can-itsp-10-171-2025": [ "03.16.03.A", "03.16.03.B", @@ -252142,7 +261772,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure External Service Providers (ESPs) use unique authentication factors for each of its customers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -252208,7 +261838,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -252247,9 +261878,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel govern third-party cybersecurity and data protection roles and responsibilities through a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar shared responsibilities tracking tool.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to document and maintain a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to delineate assignment for security, compliance and resilience controls between internal stakeholders and External Service Providers (ESPs).", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to document and maintain a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to delineate assignment for security, compliance and resilience controls between internal stakeholders and External Service Providers (ESPs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -252325,9 +261956,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -252344,7 +261975,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0" + "15" ], "general-coso-2013": [ "12" @@ -252419,9 +262050,11 @@ ], "general-nist-800-171-r3": [ "03.07.06.a", + "03.07.06.b", "03.16.03.b" ], "general-nist-800-171a-r3": [ + "A.03.07.06.b", "A.03.16.03.b" ], "general-nist-csf-2-0": [ @@ -252481,9 +262114,6 @@ "12.8.2", "12.8.5" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -252502,10 +262132,10 @@ "THIRD-PARTIES-1a" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -252527,11 +262157,8 @@ "500.10(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)", - "3.3.2(16)", - "3.5(55)" + "3.2.3.8", + "3.5.55" ], "emea-eu-nis2-2022": [ "Article 21.3" @@ -252541,19 +262168,25 @@ "8.1.1", "10.1.2(a)" ], + "emea-deu-c5-2020": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03", + "SIM-06" + ], + "emea-sau-ecc-1-2018": [ + "4-1-2-2" + ], "emea-sau-otcc-1-2022": [ "1-2-1-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2", - "Article 13.5" - ], "emea-esp-decree-311-2022": [ - "13.2", - "13.5" + "Article 11(2)", + "Article 13(3)", + "Article 13(5)" ], - "emea-gbr-cap-1850-2020": [ - "A4" + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "apac-ind-sebi-2024": [ "GV.OC.S3", @@ -252569,8 +262202,19 @@ "6.1.5.6", "6.3.1.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.46", + "10.48" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.10" + ], "americas-can-itsp-10-171-2025": [ "03.07.06.A", + "03.07.06.B", "03.16.03.B" ] } @@ -252595,7 +262239,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to perform recurring validation of the Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to ensure security, compliance and resilience control assignments accurately reflect current:\n(1) Contractual obligations for the External Service Provider (ESP);\n(2) Business practices;\n(3) Applicable stakeholders; and\n(4) Deployed Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -252657,9 +262301,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -252669,7 +262313,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0" + "15" ], "general-iso-42001-2023": [ "4.3" @@ -252681,7 +262325,11 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.16.03.c" + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[02]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.SC-06" @@ -252723,9 +262371,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -252740,14 +262385,23 @@ "500.11(a)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(55)" + "3.5.55" ], "emea-eu-nis2-2022": [ "Article 21.3" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "UP-01-BP1" + ], + "apac-aus-ism-2026-march": [ "ISM-1793" ], + "apac-mys-bnm-rmit-2025": [ + "10.46" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.16.03.C", "03.17.02", @@ -252776,9 +262430,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to obtain a First-Party Declaration(1PD) from applicable External Service Providers (ESPs) that provides assurance of compliance with specified statutory, regulatory and contractual obligations for security, compliance and resilience controls, including any flow-down requirements to subcontractors.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to obtain a First-Party Declaration(1PD) from applicable External Service Providers (ESPs) that provides assurance of compliance with specified statutory, regulatory and contractual obligations for security, compliance and resilience controls, including any flow-down requirements to subcontractors. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -252851,9 +262505,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -252875,6 +262529,7 @@ "03.16.03.c" ], "general-nist-800-171a-r3": [ + "A.03.01.20.c.01", "A.03.16.03.c" ], "general-nist-csf-2-0": [ @@ -252893,12 +262548,12 @@ "7.2.2.5" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(2)", - "164.502(e)(1)(i)", - "164.502(e)(1)(ii)" + "§ 164.308(b)(2)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(1)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(2)" + "§ 164.308(b)(2)" ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" @@ -252913,11 +262568,14 @@ "500.11(b)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(9)" + "3.2.3.9" ], "emea-eu-nis2-2022": [ "Article 21.3" ], + "emea-qat-pdppl-2020": [ + "3.11.8" + ], "emea-sau-cgiot-2024": [ "4-1-2" ], @@ -252950,7 +262608,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Contracts with ESP contain break clauses to enable penalty-free, early termination of a contract for cause, based on ESP cybersecurity and/or data protection practices deficiency(ies).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to include \"break clauses\" within contracts for failure to meet contract criteria for security, compliance and/or resilience controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -253023,9 +262681,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -253063,6 +262721,12 @@ "03.17.02", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.01.a[01]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06" ], @@ -253079,7 +262743,7 @@ "1.H" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.504(e)(2)(iii)" + "§ 164.504(e)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -253102,15 +262766,18 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1804" ], "apac-aus-ps-cps-230-2023": [ - "50(g)" + "54(g)" ], "apac-ind-sebi-2024": [ "GV.SC.S3" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "americas-can-itsp-10-171-2025": [ "03.17.01.A", "03.17.02", @@ -253210,9 +262877,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-iso-21434-2021": [ @@ -253230,6 +262897,10 @@ "03.16.03.c" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.16.03.a", "A.03.16.03.c" ], "general-tisax-6-0-3": [ @@ -253238,6 +262909,16 @@ "usa-state-nv-regulation-5-2024": [ "5.260.5(c)" ], + "emea-deu-c5-2020": [ + "UP-04" + ], + "emea-qat-pdppl-2020": [ + "3.11.8" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-20", + "VII.A.TPC-21" + ], "apac-ind-sebi-2024": [ "PR.IP.S15", "PR.IP.S16" @@ -253271,7 +262952,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to control personnel security requirements including security roles and responsibilities for third-party providers.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -253368,7 +263049,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -253430,23 +263112,18 @@ "5.1.4(c)", "10.2.1" ], - "emea-isr-cmo-1-0": [ - "11.1", - "11.3", - "18.10", - "19.5" + "emea-esp-decree-311-2022": [ + "Article 13(5)" ], - "apac-aus-ism-2024-june": [ - "ISM-1569" + "emea-esp-ccn-stic-825-2026": [ + "org.4", + "op.ext.1" ], - "apac-chn-pipl-2021": [ - "52" + "apac-aus-ism-2026-march": [ + "ISM-1569" ], "apac-ind-sebi-2024": [ "PR.AT.S3" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3" ] } }, @@ -253468,9 +263145,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of organizational information.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of organizational information. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -253529,7 +263206,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -253543,22 +263221,15 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" ], - "emea-deu-c5-2020": [ - "SSO-04" - ], - "emea-isr-cmo-1-0": [ - "11.5", - "11.11" + "apac-mys-bnm-rmit-2025": [ + "10.49" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP73", "HML73" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP64" - ], - "amaericas-can-osfi-self-assessment": [ - "4.27" ] } }, @@ -253582,9 +263253,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -253664,9 +263335,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -253682,7 +263353,7 @@ "CC9.2-POF13" ], "general-cis-csc-8-1": [ - "15.0", + "15", "15.6" ], "general-cis-csc-8-1-ig3": [ @@ -253773,7 +263444,9 @@ "03.17.02" ], "general-nist-800-171a-r3": [ - "A.03.16.03.c" + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]" ], "general-nist-csf-2-0": [ "GV.SC-07", @@ -253818,10 +263491,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.4" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -253879,7 +263548,7 @@ "500.11(a)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(9)" + "3.2.3.9" ], "emea-eu-dora-2023": [ "Article 28.6", @@ -253893,13 +263562,17 @@ "5.1.7(b)", "5.1.7(c)" ], + "emea-deu-bsrit-2017": [ + "9.3" + ], "emea-deu-c5-2020": [ - "SSO-04", - "SSO-05" + "DLL-02", + "DLL-02-BP1", + "DLL-02-BP2", + "DLL-02-BP3" ], - "emea-isr-cmo-1-0": [ - "11.4", - "11.5" + "emea-qat-pdppl-2020": [ + "3.11.8" ], "emea-sau-cgiot-2024": [ "4-1-6" @@ -253910,23 +263583,21 @@ "emea-sau-pdpl-2023": [ "Article 8" ], - "apac-aus-ism-2024-june": [ - "ISM-1793" + "emea-sau-sama-csf-1-2017": [ + "3.3.11.6" ], - "apac-aus-ps-cps-230-2023": [ - "58(a)", - "58(b)", - "58(c)" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2", + "mp.com.2", + "mp.com.3" ], - "apac-aus-ps-cps-234-2019": [ - "28" + "apac-aus-ism-2026-march": [ + "ISM-1793" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "apac-jpn-ppi-2020": [ - "24(3)" - ], "apac-jpn-ismap": [ "13.1.2.1", "15.2.1", @@ -253944,15 +263615,15 @@ "15.2.1.12", "15.2.1.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.49" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HHSP73", "HML25", "HML73" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS04" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP64", "HSUP67" @@ -253960,9 +263631,6 @@ "apac-sgp-mas-trm-2021": [ "3.4.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.27" - ], "americas-can-itsp-10-171-2025": [ "03.16.03.C", "03.17.02" @@ -253989,9 +263657,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -254086,7 +263754,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -254121,6 +263790,9 @@ "general-nist-800-171-r3": [ "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.17.02[06]" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07", @@ -254133,10 +263805,6 @@ "general-pci-dss-4-0-1": [ "A3.3.1.2" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -254160,21 +263828,20 @@ "Article 21.3", "Article 21.4" ], - "emea-deu-c5-2020": [ - "SSO-04" - ], "emea-sau-cgiot-2024": [ "4-1-6" ], - "emea-sau-ecc-1-2018": [ - "4-1-2-3" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "amaericas-can-osfi-self-assessment": [ - "2.7", - "4.27" + "apac-jpn-appi-2020": [ + "IV.5.53(4)" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.3" ], "americas-can-itsp-10-171-2025": [ "03.17.02" @@ -254201,7 +263868,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to control changes to services by suppliers, taking into account the criticality of business TAASD that are in scope by the third-party.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -254299,7 +263966,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -254387,13 +264055,13 @@ "03.16.01", "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.16.01", + "A.03.17.02[06]" + ], "general-nist-csf-2-0": [ "GV.SC-08" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-shared-assessments-sig-2025": [ "K.6" ], @@ -254443,21 +264111,17 @@ "5.1.7(d)" ], "emea-deu-c5-2020": [ - "SSO-04", - "SSO-05" + "OIS-03" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.2 [OP.EXT.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1794" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "apac-jpn-ppi-2020": [ - "24(3)" - ], "apac-jpn-ismap": [ "15.2.1.14", "15.2.1.15", @@ -254466,9 +264130,6 @@ "15.2.2.2", "15.2.2.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.27" - ], "americas-can-itsp-10-171-2025": [ "03.16.01", "03.17.02" @@ -254497,7 +264158,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure response/recovery planning and testing are conducted with critical suppliers/providers.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure response/recovery planning and testing are conducted with critical suppliers/providers. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -254592,7 +264253,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -254674,16 +264336,13 @@ "CIP-013-2 1.2.2" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)(b)" - ], - "emea-isr-cmo-1-0": [ - "25.17" + "3.2.3.8(b)" ], "emea-sau-ecc-1-2018": [ "4-1-2-2" ], - "amaericas-can-osfi-self-assessment": [ - "4.28" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ] } }, @@ -254692,7 +264351,7 @@ "title": "Foreign Ownership, Control or Influence (FOCI)", "family": "TPM", "description": "Mechanisms exist to minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices.", - "scf_question": "Does the organization minimize risk associate with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices?", + "scf_question": "Does the organization minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -254705,7 +264364,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -254746,9 +264405,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} }, @@ -254770,7 +264429,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to periodically review External Service Providers (ESP) for changes that affect Foreign Ownership, Control or Influence (FOCI).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -254809,9 +264468,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} }, @@ -254833,7 +264492,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to contractually impose safeguards (e.g., additional controls, access modification, contract termination, etc.) from Foreign Ownership, Control or Influence (FOCI) concerns to ensure that:\n(1) Unauthorized access to sensitive and/or regulated data is prevented; and \n(2) Performance of contracts is not adversely affected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -254878,9 +264537,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} }, @@ -255003,7 +264662,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -255088,8 +264748,20 @@ ], "general-nist-800-171-r3": [ "03.11.02.a", + "03.14.01.a", "03.14.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.a[01]", + "A.03.14.01.a[01]", + "A.03.14.03.a" + ], + "general-nist-800-172-r3": [ + "03.11.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.01E" + ], "general-nist-800-207": [ "NIST Tenet 7" ], @@ -255166,33 +264838,37 @@ "Article 45.2", "Article 45.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "3.10", "5.3" ], - "emea-isr-cmo-1-0": [ - "23.1", - "23.4" + "emea-deu-c5-2020": [ + "OIS-05-DOAR" + ], + "emea-isr-cmo-2-0": [ + "2.B" ], "emea-sau-cgiot-2024": [ "2-12-4" ], "emea-sau-ecc-1-2018": [ - "2-10-4", "2-13-1", "2-13-2", - "2-13-3", - "2-13-4" + "2-13-3-5" + ], + "emea-sau-otcc-1-2022": [ + "2-12-1-8" ], "emea-sau-sama-csf-1-2017": [ - "3.3.16" + "3.3.16.1", + "3.3.16.3", + "3.3.16.3.a", + "3.3.16.3.c", + "3.3.16.3.d", + "3.3.16.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "emea-gbr-caf-4-0": [ "A2.b" @@ -255212,19 +264888,11 @@ "apac-jpn-ismap": [ "5.1.1.4" ], - "apac-sgp-mas-trm-2021": [ - "4.2.1", - "13.5.1", - "13.5.2", - "14.3.1", - "14.3.2", - "14.3.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.2" + "apac-mys-bnm-rmit-2025": [ + "11.10" ], - "amaericas-can-osfi-self-assessment": [ - "1.3" + "apac-sgp-mas-trm-2021": [ + "14.1.6" ], "americas-can-osfi-b13-2022": [ "3.0", @@ -255232,12 +264900,231 @@ "3.1.1", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.A", + "03.14.01.A", "03.14.03.A" ] } }, + { + "control_id": "THR-01.1", + "title": "Dynamic Threat Awareness", + "family": "THR", + "description": "Mechanisms exist to determine and maintain ongoing awareness of the current cyber threat environment.", + "scf_question": "Does the organization determine and maintain ongoing awareness of the current cyber threat environment?", + "relative_weight": 3, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to determine and maintain ongoing awareness of the current cyber threat environment.", + "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subscribe to CISA alerts\n∙ MS-ISAC free membership", + "small": "∙ CISA and MS-ISAC alerts\n∙ Industry-specific threat intelligence feeds\n∙ Basic threat awareness program", + "medium": "∙ Threat intelligence feeds (CISA, industry ISACs)\n∙ Regular threat landscape reviews\n∙ Integration with security awareness program", + "large": "∙ Threat intelligence program with dedicated analyst\n∙ ISAC membership and information sharing\n∙ Regular executive threat briefings", + "enterprise": "∙ Enterprise threat intelligence program\n∙ Automated threat intelligence feeds and analysis\n∙ ISAC and government information sharing partnerships\n∙ Threat intelligence integrated with SIEM and SOC operations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Threat Management", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.11.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.08E", + "A.03.11.08E.ODP[01]" + ], + "apac-sgp-mas-trm-2021": [ + "14.1.6" + ] + } + }, + { + "control_id": "THR-01.2", + "title": "Predictive Cyber Analytics", + "family": "THR", + "description": "Mechanisms exist to employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 3, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use free threat indicators from CISA and MS-ISAC", + "small": "∙ Use free threat indicators from CISA and MS-ISAC\n∙ Basic anomaly detection via endpoint protection tools", + "medium": "∙ SIEM with anomaly detection capabilities\n∙ User and Entity Behavior Analytics (UEBA) basic functionality", + "large": "∙ SIEM/UEBA platform with predictive analytics\n∙ Machine learning-based anomaly detection\n∙ Threat hunting based on behavioral analytics", + "enterprise": "∙ Enterprise SIEM/SOAR with advanced predictive analytics\n∙ AI/ML-based threat detection (e.g., Darktrace, Vectra AI, Microsoft Sentinel ML)\n∙ Dedicated threat analytics team\n∙ Predictive analytics integrated with SOC operations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Threat Management", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.11.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.03E[01]", + "A.03.11.03E.ODP[01]", + "A.03.11.03E.ODP[02]", + "DS-A.03.11.03E[02]", + "A.03.11.03E.ODP[03]" + ] + } + }, { "control_id": "THR-02", "title": "Indicators of Exposure (IOE)", @@ -255260,9 +265147,9 @@ "0": "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.", "1": "Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Threat management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop Indicators of Exposure (IOE) to understand the potential attack vectors that attackers could use to attack the organization.", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop Indicators of Exposure (IOE) to understand the potential attack vectors that attackers could use to attack the organization. ", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -255321,7 +265208,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -255356,16 +265244,8 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "3.A" ], - "emea-isr-cmo-1-0": [ - "23.3" - ], - "emea-sau-otcc-1-2022": [ - "2-12-2-8" - ], - "apac-sgp-mas-trm-2021": [ - "14.3.1", - "14.3.2", - "14.3.3" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "americas-can-osfi-b13-2022": [ "3.1" @@ -255462,7 +265342,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -255511,7 +265392,7 @@ "general-iso-27018-2025": [ "5.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1210", "T1211", @@ -255582,17 +265463,20 @@ "general-nist-800-171-r3": [ "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", - "03.02.02.b", "03.11.02.a", "03.14.03.a" ], "general-nist-800-171a-r3": [ + "A.03.02.01.a.02", + "A.03.02.01.b[02]", + "A.03.11.02.a[01]", "A.03.14.03.a" ], - "general-nist-800-172": [ - "3.11.1e", - "3.14.6e" + "general-nist-800-172-r3": [ + "03.11.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.12E" ], "general-nist-800-207": [ "NIST Tenet 7" @@ -255687,6 +265571,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SI-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(ii)" + ], "usa-federal-irs-1075-2021": [ "SI-5" ], @@ -255713,7 +265600,7 @@ "SI-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(21)" + "3.3.3.21" ], "emea-eu-dora-2023": [ "Article 13.1" @@ -255722,21 +265609,26 @@ "6.10.2(a)" ], "emea-deu-bsrit-2017": [ + "3.10", "5.3" ], - "emea-isr-cmo-1-0": [ - "23.2" + "emea-deu-c5-2020": [ + "OIS-05" ], "emea-sau-cgiot-2024": [ "2-12-4" ], "emea-sau-ecc-1-2018": [ - "2-10-3-5", "2-13-3-5" ], "emea-sau-otcc-1-2022": [ - "1-8-3", - "2-12-2-8" + "2-12-1-8" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.16.3.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "emea-gbr-def-stan-05-138-2024": [ "1204", @@ -255749,6 +265641,9 @@ "1204", "3110" ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], "apac-ind-sebi-2024": [ "EV.ST.S1", "EV.ST.S4", @@ -255762,13 +265657,19 @@ "12.2.1.12", "12.2.1.13" ], + "apac-mys-bnm-rmit-2025": [ + "11.3", + "11.10", + "12.3", + "12.4" + ], "apac-sgp-mas-trm-2021": [ + "4.2.1", "12.1.1", - "12.1.2", - "12.1.3" + "12.1.2" ], - "amaericas-can-osfi-self-assessment": [ - "3.7" + "americas-bmu-mba-coc-2020": [ + "6.2" ], "americas-can-osfi-b13-2022": [ "3.0", @@ -255776,11 +265677,13 @@ "3.1.1", "3.1.5" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", - "03.02.02.B", "03.11.02.A", "03.14.03.A" ] @@ -255872,7 +265775,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -255889,6 +265793,7 @@ "03.14.03.b" ], "general-nist-800-171a-r3": [ + "A.03.14.03.a", "A.03.14.03.b[01]", "A.03.14.03.b[02]" ], @@ -255903,9 +265808,23 @@ "7.5.1", "7.5.2" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)", + "101.625(d)(14)", + "101.650(e)(3)(iii)" + ], + "emea-deu-c5-2020": [ + "OIS-05-DOAR" + ], "emea-sau-cgiot-2024": [ "2-12-4" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.16.3.f" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], "emea-gbr-def-stan-05-138-2024": [ "1204", "3110" @@ -255926,6 +265845,16 @@ "4.9.2.1", "4.9.2.2" ], + "apac-mys-bnm-rmit-2025": [ + "11.10" + ], + "apac-sgp-mas-trm-2021": [ + "12.1.3" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.14.03.B" ] @@ -255953,7 +265882,7 @@ "0": "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.", "1": "Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Threat management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to implement an insider threat program that includes a cross-discipline insider threat incident handling team.", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to implement an insider threat program that includes a cross-discipline insider threat incident handling team. ", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -256026,7 +265955,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -256090,7 +266020,7 @@ "§117.18(b)(4)(iii)", "§117.18(b)(4)(iv)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ], @@ -256121,7 +266051,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to utilize security awareness training on recognizing and reporting potential indicators of insider threat.", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -256196,7 +266126,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -256308,7 +266239,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "AT-02 (02)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ], @@ -256337,7 +266268,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to establish a Vulnerability Disclosure Program (VDP) to assist with the secure development and maintenance of Technology Assets, Applications and/or Services (TAAS) that receives unsolicited input from the public about vulnerabilities in organizational TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -256384,7 +266315,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -256419,6 +266351,13 @@ "general-nist-800-82-r3-high": [ "RA-05(11)" ], + "general-nist-800-171-r3": [ + "03.14.01.a" + ], + "general-nist-800-171a-r3": [ + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], "general-nist-800-218": [ "RV.1.3" ], @@ -256446,9 +266385,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "T.2" ], @@ -256486,17 +266422,17 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "RA-05(11)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(5)" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1616", "ISM-1717", "ISM-1755", "ISM-1756" ], "apac-aus-cop-sitc-2020": [ - "Principle 2" + "2" + ], + "apac-mys-bnm-rmit-2025": [ + "11.7" ], "apac-nzl-ism-3-9": [ "5.9.23.C.01", @@ -256509,6 +266445,9 @@ ], "apac-sgp-mas-trm-2021": [ "13.2.2" + ], + "americas-can-itsp-10-171-2025": [ + "03.14.01.A" ] } }, @@ -256530,7 +266469,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to enable public submissions of discovered or potential security vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -256575,7 +266514,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -256586,8 +266526,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 2.2" + "apac-aus-cop-sitc-2020": [ + "2" ] } }, @@ -256611,7 +266551,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to perform cyber threat hunting that uses Indicators of Compromise (IoC) to detect, track and disrupt threats that evade existing security controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -256686,14 +266626,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { "general-cr-cmm-2026": [ "CR2.2.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1190", "T1195", @@ -256730,10 +266671,14 @@ "general-nist-800-161-r1-level-3": [ "RA-10" ], - "general-nist-800-172": [ - "3.11.1e", - "3.11.2e", - "3.14.6e" + "general-nist-800-172-r3": [ + "03.11.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.02E.a.01[02]", + "DS-A.03.11.02E.a.02[01]", + "DS-A.03.11.02E.a.02[02]", + "DS-A.03.11.02E.b" ], "general-nist-csf-2-0": [ "ID.RA-03", @@ -256767,6 +266712,9 @@ "C2.a (point 7)", "C2.a (point 8)" ], + "apac-aus-ism-2026-march": [ + "ISM-1921" + ], "apac-ind-sebi-2024": [ "DE.DP.S5" ], @@ -256793,7 +266741,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to embed false data or steganographic data in files to enable the organization to determine if data has been exfiltrated and provide a means to identify the individual(s) involved.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -256836,7 +266784,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -256860,6 +266809,12 @@ ], "general-nist-800-161-r1-level-3": [ "SI-20" + ], + "general-nist-800-172-r3": [ + "03.14.16E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.16E" ] } }, @@ -256883,7 +266838,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop and keep current a catalog of applicable internal and external threats to the organization, both natural and manmade.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -256937,7 +266892,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -256971,9 +266927,6 @@ "general-nist-800-171-r3": [ "03.15.02.a.03" ], - "general-nist-800-172": [ - "3.11.5e" - ], "general-nist-csf-2-0": [ "ID.RA-03", "ID.RA-04", @@ -257003,10 +266956,10 @@ "RA.L3-3.11.5E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" @@ -257019,6 +266972,7 @@ ], "emea-deu-bsrit-2017": [ "3.3", + "3.10", "5.3" ], "emea-sau-cgiot-2024": [ @@ -257028,10 +266982,24 @@ "A2.b", "C1.f" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.3" + ], + "apac-sgp-mas-trm-2021": [ + "4.2.1" + ], + "americas-arg-ppd-2018": [ + "E.1.1-1" + ], "americas-can-osfi-b13-2022": [ "3.0", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.2", + "3.1.6" + ], "americas-can-itsp-10-171-2025": [ "03.15.02.A.03" ] @@ -257111,7 +267079,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -257147,6 +267116,9 @@ "general-nist-800-171-r3": [ "03.14.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.14.03.a" + ], "general-nist-csf-2-0": [ "ID.RA-04", "ID.RA-05", @@ -257174,10 +267146,10 @@ "THREAT-2i" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(a)" @@ -257192,18 +267164,42 @@ "3.10", "5.3" ], + "emea-isr-cmo-2-0": [ + "Appendix B" + ], "emea-sau-cgiot-2024": [ "1-4-4" ], + "apac-aus-ism-2026-march": [ + "ISM-1203" + ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], "apac-ind-sebi-2024": [ "ID.RA.S4" ], + "apac-mys-bnm-rmit-2025": [ + "11.3", + "12.4" + ], + "apac-sgp-mas-trm-2021": [ + "4.3.2", + "8.5.1" + ], + "americas-arg-ppd-2018": [ + "E.1.1-1" + ], "americas-can-osfi-b13-2022": [ "3.1", "3.1.1", "3.1.2", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.2", + "3.1.6" + ], "americas-can-itsp-10-171-2025": [ "03.14.03.B" ] @@ -257233,7 +267229,7 @@ "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to automatically establish behavioral baselines that capture information about user and entity behavior to enable dynamic threat discovery.", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -257301,7 +267297,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -257325,6 +267322,9 @@ ], "usa-federal-dow-zta-reference-architecture-2-0": [ "1.2" + ], + "apac-sgp-mas-trm-2021": [ + "12.2.3" ] } }, @@ -257449,7 +267449,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -257462,9 +267463,9 @@ "CC9.2-POF13" ], "general-cis-csc-8-1": [ - "7.0", + "7", "7.1", - "18.0" + "18" ], "general-cis-csc-8-1-ig1": [ "7.1" @@ -257599,7 +267600,9 @@ "3.14.1[f]" ], "general-nist-800-171a-r3": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" ], "general-nist-csf-2-0": [ "ID.RA-01", @@ -257643,9 +267646,6 @@ "6.3.1", "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "T.2" ], @@ -257785,8 +267785,8 @@ "SI-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(21)", - "3.4.4(36)(a)" + "3.3.3.21", + "3.4.4.36(a)" ], "emea-eu-dora-2023": [ "Article 9.4(f)", @@ -257803,64 +267803,46 @@ "6.10.2(a)", "6.10.2(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.1", - "22.2" + "RB-17", + "RB-17-BP2" ], "emea-sau-cscc-1-2019": [ "2-3-1-3", - "2-9", + "2-9-1", "2-9-2" ], "emea-sau-cgiot-2024": [ "2-9-1" ], "emea-sau-ecc-1-2018": [ - "2-3-4", "2-10-1", "2-10-2", - "2-10-3", - "2-10-4", - "2-11-1", - "2-11-2", - "2-11-3", - "2-11-4", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ - "2-9", "2-9-1", - "2-9-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-11" + "2-9-2", + "2-10-1", + "2-10-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.17" + "3.3.17", + "3.3.17.1", + "3.3.17.3", + "3.3.17.3.a", + "3.3.17.3.b", + "3.3.17.3.c", + "3.3.17.3.d", + "3.3.17.3.e", + "3.3.17.3.f" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-decree-311-2022": [ + "Article 12(6)(i)" ], "emea-gbr-caf-4-0": [ "B4.d" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" - ], "emea-gbr-def-stan-05-138-2024": [ "2402", "2405" @@ -257877,7 +267859,7 @@ "2402", "2405" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1143", "ISM-1163", "ISM-1460", @@ -257910,7 +267892,13 @@ "12.6.1.17", "12.6.1.18.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17", + "10.18", + "10.19", + "10.31" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HHSP26", "HML19", @@ -257922,22 +267910,20 @@ "apac-nzl-ism-3-9": [ "6.2.4.C.01" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" - ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "7.4.1", - "7.4.2" + "6.1.4" ], - "americas-bmu-mba-coc-2020": [ - "6.16" + "americas-arg-ppd-2018": [ + "E" ], "americas-can-osfi-b13-2022": [ "2.6", "3.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.A", "03.14.01.A" @@ -257964,7 +267950,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to define and manage the scope for its attack surface management activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -258054,7 +268040,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -258104,7 +268091,14 @@ "03.14.01.a" ], "general-nist-800-171a-r3": [ - "A.03.11.02.a[01]" + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" + ], + "general-nist-800-172-r3": [ + "03.12.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.12.01E.ODP[02]" ], "general-nist-csf-2-0": [ "PR.PS-02" @@ -258164,9 +268158,6 @@ "11.3.2", "11.3.2.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -258200,6 +268191,9 @@ "SA-11(06)", "SA-11(07)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-irs-1075-2021": [ "SA-11(CE-6)" ], @@ -258209,28 +268203,24 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.5(a)(1)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], "emea-sau-cscc-1-2019": [ "2-10-1-1" ], "emea-sau-ecc-1-2018": [ - "2-11-3-1", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ - "2-9-1-1" + "2-9-1-1", + "2-10-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-27", - "TPC-28", - "TPC-29" + "apac-mys-bnm-rmit-2025": [ + "10.18" ], "apac-nzl-ism-3-9": [ "6.2.4.C.01" ], "apac-sgp-mas-trm-2021": [ + "6.1.4", "13.1.2" ], "americas-can-itsp-10-171-2025": [ @@ -258262,11 +268252,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that vulnerabilities are properly identified, tracked and remediated.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -258354,7 +268344,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -258463,7 +268454,16 @@ "3.11.3[b]" ], "general-nist-800-171a-r3": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.b", + "A.03.12.02.a.02" + ], + "general-nist-800-172-r3": [ + "03.11.11E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.11E.ODP[01]", + "DS-A.03.11.11E[02]" ], "general-nist-800-218": [ "RV.2.2" @@ -258518,9 +268518,6 @@ "11.3.2", "11.3.2.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -258564,6 +268561,9 @@ "PM-04", "SC-18(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-irs-1075-2021": [ "PM-4", "SC-18(CE-1)" @@ -258590,6 +268590,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-04" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(6)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(2)" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], @@ -258598,15 +268604,6 @@ "6.10.2(c)", "6.10.3" ], - "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.8", - "22.11", - "22.13" - ], "emea-sau-cscc-1-2019": [ "2-9-1-2" ], @@ -258614,18 +268611,16 @@ "2-9-1" ], "emea-sau-ecc-1-2018": [ - "2-10-3-3", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ "2-9-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-11", - "TPC-91" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" + "VII.B.TPC-91", + "VII.B.TPC-91-BP1", + "VII.B.TPC-91-BP2", + "VII.B.TPC-91-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2402" @@ -258639,8 +268634,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2402" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-aus-ism-2026-march": [ + "ISM-1902", + "ISM-1903", + "ISM-1904" ], "apac-ind-sebi-2024": [ "PR.MA.S3" @@ -258648,7 +268645,10 @@ "apac-jpn-ismap": [ "12.6.1.14" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HHSP59", "HML19", @@ -258663,20 +268663,21 @@ "23.2.19.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" + "4.2(a)" ], "apac-sgp-mas-trm-2021": [ + "6.1.4", + "13.6.1", "13.6.1(a)", "13.6.1(b)", "13.6.1(c)" ], - "amaericas-can-osfi-self-assessment": [ - "2.7" - ], "americas-can-osfi-b13-2022": [ "2.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", "03.12.02.A.02", @@ -258684,6 +268685,117 @@ ] } }, + { + "control_id": "VPM-02.1", + "title": "Known Exploited Vulnerabilities (KEV) Mitigations", + "family": "VPM", + "description": "Mechanisms exist to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions.", + "scf_question": "Does the organization prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions?", + "relative_weight": 7, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ IT and/or cybersecurity personnel apply software patches through an informal process.", + "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.\n▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Subscribe to CISA KEV catalog alerts (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)\n∙ Prioritize patching KEV-listed vulnerabilities within CISA timeframes", + "small": "∙ CISA KEV catalog subscription and monitoring\n∙ Priority patching for KEV-listed vulnerabilities within CISA-defined windows", + "medium": "∙ KEV-integrated vulnerability management program\n∙ CISA KEV catalog integration with vulnerability scanner\n∙ Accelerated remediation SLAs for KEV items", + "large": "∙ Enterprise vulnerability management with KEV prioritization\n∙ Automated KEV alerting and remediation tracking\n∙ Defined KEV remediation SLAs", + "enterprise": "∙ Enterprise KEV management program\n∙ Automated CISA KEV catalog integration\n∙ Real-time KEV exposure tracking and alerting\n∙ Risk-based KEV remediation with board-level visibility for material exposures" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Vulnerability & Patch Management", + "crosswalks": {} + }, { "control_id": "VPM-03", "title": "Vulnerability Ranking", @@ -258707,9 +268819,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -258781,7 +268893,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -258807,6 +268920,9 @@ "general-nist-800-171-r3": [ "03.11.02.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.a[01]" + ], "general-nist-csf-2-0": [ "ID.RA-08" ], @@ -258838,9 +268954,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-sparta": [ "CM0016" ], @@ -258860,6 +268973,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(2)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.E.2.b" ], @@ -258870,29 +268986,25 @@ "500.5(c)" ], "emea-deu-c5-2020": [ - "OPS-18", - "OPS-22", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.8" + "RB-17-BP1", + "RB-19" ], "emea-sau-cscc-1-2019": [ "2-9-1-2" ], "emea-sau-ecc-1-2018": [ - "2-10-3-2" - ], - "emea-sau-otcc-1-2022": [ - "2-9-1-2", - "2-9-1-3" + "2-10-3-2", + "2-10-3-3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163" ], "apac-ind-sebi-2024": [ "PR.MA.S3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "americas-can-osfi-b13-2022": [ "3.1.3" ], @@ -258919,7 +269031,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify, assess, prioritize and document the potential impact(s) and likelihood(s) of applicable internal and external threats exploiting known vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -258967,7 +269079,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -258993,6 +269106,10 @@ ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.5(c)" + ], + "emea-deu-c5-2020": [ + "RB-17-BP1", + "RB-19" ] } }, @@ -259017,11 +269134,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -259106,7 +269223,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -259114,7 +269232,7 @@ "CC4.2" ], "general-cis-csc-8-1": [ - "7.0", + "7", "7.7", "12.1", "18.3" @@ -259169,11 +269287,11 @@ ], "general-nist-800-171-r3": [ "03.11.02.b", - "03.14.01.a", - "03.14.01.b" + "03.14.01.a" ], "general-nist-800-171a-r3": [ - "A.03.11.02.b" + "A.03.11.02.b", + "A.03.14.01.a[03]" ], "general-owasp-top-10-2025": [ "A05:2025" @@ -259203,9 +269321,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -259258,48 +269373,32 @@ "Article 21.4" ], "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.6", - "22.11" + "RB-17-BP2", + "RB-19", + "RB-21" ], "emea-sau-cscc-1-2019": [ "2-9-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-10-3-3" - ], - "emea-sau-otcc-1-2022": [ - "2-9-1-2", - "2-9-1-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1801" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-mys-bnm-rmit-2025": [ + "10.18" ], "apac-nzl-ism-3-9": [ "6.2.6.C.01", "23.2.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.7" - ], "americas-can-osfi-b13-2022": [ "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", - "03.14.01.A", - "03.14.01.B" + "03.14.01.A" ] } }, @@ -259321,7 +269420,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to install the latest stable version of any software and/or security-related updates on all applicable systems.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -259391,7 +269490,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -259422,23 +269522,16 @@ "usa-state-vt-act-171-2018": [ "2447(c)(6)" ], - "emea-isr-cmo-1-0": [ - "12.22" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1467", "ISM-1483" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP44", "HML44" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS08" - ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "americas-can-osfi-self-assessment-2": [ + "2.6.1" ] } }, @@ -259460,11 +269553,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and correct flaws related to the collection, usage, processing or dissemination of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -259518,17 +269611,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", - "crosswalks": { - "general-scf-dpmp-2025": [ - "5.15" - ], - "emea-zaf-popia-2013": [ - "4" - ] - } + "crosswalks": {} }, { "control_id": "VPM-04.3", @@ -259557,7 +269644,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Documented deferred patch register (spreadsheet)\n∙ Management sign-off for deferred patches with interim mitigations documented", + "small": "∙ Formal deferred patch register\n∙ Risk-based justification and management approval\n∙ Compensating control documentation", + "medium": "∙ Deferred patching exception process within vulnerability management program\n∙ Compensating control requirements for deferred patches\n∙ GRC platform for exception tracking", + "large": "∙ Enterprise deferred patch management process\n∙ Formal exception approval with compensating controls\n∙ GRC platform for tracking and reporting\n∙ Regular review of aged deferred patches", + "enterprise": "∙ Enterprise patch exception management program\n∙ Automated deferred patch tracking and escalation\n∙ Compensating control validation for all exceptions\n∙ Board-level reporting on material deferred patches" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -259612,7 +269705,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -259627,6 +269721,9 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1" ] } }, @@ -259635,7 +269732,7 @@ "title": "Software & Firmware Patching", "family": "VPM", "description": "Mechanisms exist to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", - "scf_question": "Does the organization conduct software patching for all deployed systems, applications and firmware?", + "scf_question": "Does the organization conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -259651,11 +269748,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -259742,7 +269839,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -259811,7 +269909,7 @@ "general-iso-27018-2025": [ "8.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1027", @@ -259967,10 +270065,9 @@ ], "general-nist-800-171a-r3": [ "A.03.11.02.b", + "A.03.12.02.a.02", "A.03.14.01.ODP[01]", "A.03.14.01.ODP[02]", - "A.03.14.01.a[01]", - "A.03.14.01.a[02]", "A.03.14.01.a[03]", "A.03.14.01.b[01]", "A.03.14.01.b[02]" @@ -260002,9 +270099,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "N.4" ], @@ -260058,6 +270152,10 @@ "SI-02(04)", "SI-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)", + "101.650(e)(3)(i)" + ], "usa-federal-irs-1075-2021": [ "SI-2", "SI-2(CE-4)", @@ -260101,10 +270199,7 @@ "6.6.1(a)" ], "emea-deu-c5-2020": [ - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "12.21" + "RB-17-BP2" ], "emea-sau-cscc-1-2019": [ "2-3-1-3" @@ -260123,11 +270218,14 @@ "2-4-1-15" ], "emea-sau-sacs-002-2022": [ - "TPC-11", - "TPC-78" + "VII.A.TPC-11" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" + "3", + "3-BP4", + "3-BP4-1", + "3-BP4-2", + "3-BP4-3" ], "emea-gbr-def-stan-05-138-2024": [ "2402", @@ -260153,7 +270251,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1143", "ISM-1493", "ISM-1690", @@ -260164,10 +270262,15 @@ "ISM-1695", "ISM-1696", "ISM-1697", - "ISM-1751" + "ISM-1751", + "ISM-1876", + "ISM-1877", + "ISM-1878", + "ISM-1879", + "ISM-1901" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-aus-cop-sitc-2020": [ + "3" ], "apac-ind-sebi-2024": [ "PR.MA.S3" @@ -260175,7 +270278,11 @@ "apac-jpn-ismap": [ "12.6.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17", + "10.18" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HML19" ], @@ -260183,29 +270290,30 @@ "HSUP17" ], "apac-nzl-ism-3-9": [ + "22.1.18.C.01", "23.2.19.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" + "4.2(a)" ], "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "7.4.1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-7" ], "americas-bmu-mba-coc-2020": [ "6.16" ], - "amaericas-can-osfi-self-assessment": [ - "4.5", - "4.7", - "4.9" - ], "americas-can-osfi-b13-2022": [ "2.6", "2.6.1", "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", "03.12.02.A.02", @@ -260232,9 +270340,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to centrally-manage the flaw remediation process.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to centrally-manage the flaw remediation process. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -260319,7 +270427,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -260468,23 +270577,17 @@ "Article 21.4" ], "emea-deu-c5-2020": [ - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "12.21", - "22.11", - "22.12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-91" + "RB-17-BP2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0298", "ISM-0300" ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "apac-mys-bnm-rmit-2025": [ + "10.19" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.6" ] } }, @@ -260506,9 +270609,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically determine the state of system components with regard to flaw remediation.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically determine the state of system components with regard to flaw remediation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -260554,7 +270657,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -260631,10 +270735,6 @@ ], "usa-federal-cms-marse-2-0": [ "SI-2(2)" - ], - "emea-isr-cmo-1-0": [ - "22.11", - "22.12" ] } }, @@ -260656,11 +270756,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to track the effectiveness of remediation operations through metrics reporting.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -260710,7 +270810,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -260752,18 +270853,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.E.2.a" - ], - "emea-deu-c5-2020": [ - "OPS-19" - ], - "emea-isr-cmo-1-0": [ - "12.22" - ], - "emea-sau-sacs-002-2022": [ - "TPC-91" - ], - "apac-sgp-mas-trm-2021": [ - "13.6.1(b)" ] } }, @@ -260853,7 +270942,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -260906,6 +270996,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SI-02(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(ii)" + ], "usa-federal-irs-1075-2021": [ "SI-2(CE-4)", "SI-2(CE-5)" @@ -260916,21 +271009,11 @@ "emea-sau-ecc-1-2018": [ "2-10-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-78" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "3-BP3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1467" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)" - ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" ] } }, @@ -260954,9 +271037,9 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -260999,7 +271082,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -261039,7 +271123,7 @@ "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform due diligence on software and/or firmware update stability by conducting pre-production testing in a non-production environment.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -261103,7 +271187,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -261128,6 +271213,12 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2405" + ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], + "apac-sgp-mas-trm-2021": [ + "7.4.2" ] } }, @@ -261149,11 +271240,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform out-of-cycle software and/or firmware updates to address time-sensitive remediations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -261217,7 +271308,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -261321,7 +271413,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -261336,6 +271429,12 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.1(c)" + ], + "emea-sau-otcc-1-2022": [ + "2-4-1-15" + ], + "apac-aus-cop-sitc-2020": [ + "3" ] } }, @@ -261364,7 +271463,7 @@ "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel configure technologies to update vulnerability scanning tools.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -261430,7 +271529,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -261489,7 +271589,7 @@ "general-iso-27018-2025": [ "8.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011.001", "T1021.001", "T1021.003", @@ -261647,7 +271747,8 @@ "3.11.2" ], "general-nist-800-171-r3": [ - "03.11.02.a" + "03.11.02.a", + "03.14.01.a" ], "general-nist-800-171a": [ "3.11.2[a]", @@ -261664,8 +271765,8 @@ "A.03.11.02.a[02]", "A.03.11.02.a[03]", "A.03.11.02.a[04]", - "A.03.11.02.c[01]", - "A.03.11.02.c[02]" + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" ], "general-nist-csf-2-0": [ "ID.RA-01" @@ -261752,6 +271853,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "RA-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(vi)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(2)", "314.4(d)(2)(ii)" @@ -261805,20 +271909,9 @@ "emea-eu-nis2-annex-2024": [ "6.10.2(b)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-22", - "PSS-02", - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "3.4", - "9.25", - "12.30", - "22.3", - "22.6" + "RB-17-BP1", + "RB-21" ], "emea-sau-cscc-1-2019": [ "2-9-1-1", @@ -261830,8 +271923,11 @@ "emea-sau-ecc-1-2018": [ "2-10-3-1" ], + "emea-sau-otcc-1-2022": [ + "2-9-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-85" + "VII.B.TPC-85" ], "emea-uae-niaf-2023": [ "3.1.3" @@ -261856,7 +271952,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163", "ISM-1698", "ISM-1699", @@ -261864,12 +271960,17 @@ "ISM-1701", "ISM-1702", "ISM-1703", - "ISM-1752" + "ISM-1752", + "ISM-1875", + "ISM-1900" ], "apac-ind-sebi-2024": [ "ID.RA.S1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "11.9" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP26", "HHSP59", "HML26", @@ -261882,21 +271983,18 @@ "6.2.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "13.1.1", - "13.1.2" - ], - "americas-bmu-mba-coc-2020": [ - "6.15" - ], - "amaericas-can-osfi-self-assessment": [ - "2.5" + "13.1.1" ], "americas-can-osfi-b13-2022": [ "3.1.2", "3.1.3" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.3" + ], "americas-can-itsp-10-171-2025": [ - "03.11.02.A" + "03.11.02.A", + "03.14.01.A" ] } }, @@ -261985,7 +272083,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -262136,11 +272235,8 @@ "emea-eu-nis2-annex-2024": [ "6.10.4" ], - "emea-deu-c5-2020": [ - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "22.7" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-78" ], "apac-aus-essential-8-2024": [ "ML1-P1", @@ -262150,7 +272246,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1808" ], "americas-can-itsp-10-171-2025": [ @@ -262178,7 +272274,7 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify the breadth and depth of coverage for vulnerability scanning that define the system components scanned and types of vulnerabilities that are checked for.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify the breadth and depth of coverage for vulnerability scanning that define the system components scanned and types of vulnerabilities that are checked for. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -262241,7 +272337,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -262315,14 +272412,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "RA-05 (03)" ], - "emea-isr-cmo-1-0": [ - "22.6" - ], "emea-sau-cscc-1-2019": [ - "2-9-2-1" - ], - "emea-sau-ecc-1-2018": [ - "2-11-3-1" + "2-9-2" ] } }, @@ -262344,9 +272435,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement privileged access authorization for selected vulnerability scanning activities.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement privileged access authorization for selected vulnerability scanning activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -262409,7 +272500,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -262475,9 +272567,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "RA-05 (05)" - ], - "emea-isr-cmo-1-0": [ - "22.9" ] } }, @@ -262499,9 +272588,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically compare the results of vulnerability scans over time to determine trends in system vulnerabilities.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically compare the results of vulnerability scans over time to determine trends in system vulnerabilities. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -262563,7 +272652,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -262599,12 +272689,6 @@ ], "general-swift-cscf-2025": [ "2.7" - ], - "emea-deu-c5-2020": [ - "OPS-20" - ], - "emea-isr-cmo-1-0": [ - "22.10" ] } }, @@ -262628,9 +272712,9 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to review historical event logs to determine if identified vulnerabilities have been previously exploited.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to review historical event logs to determine if identified vulnerabilities have been previously exploited. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -262691,7 +272775,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -262718,12 +272803,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "RA-05(08)" - ], - "emea-deu-c5-2020": [ - "OPS-20" - ], - "emea-isr-cmo-1-0": [ - "22.10" ] } }, @@ -262827,7 +272906,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -262871,11 +272951,8 @@ "11.3.2", "11.3.2.1" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.3" + "emea-sau-cscc-1-2019": [ + "2-9-1-1" ] } }, @@ -262979,7 +273056,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -263011,11 +273089,11 @@ "11.3.1.2", "11.3.1.3" ], - "emea-deu-c5-2020": [ - "PSS-02" + "emea-sau-cscc-1-2019": [ + "2-9-1-1" ], - "emea-isr-cmo-1-0": [ - "22.3" + "americas-bmu-mba-coc-2020": [ + "6.15-BP3" ] } }, @@ -263037,7 +273115,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to define what information is allowed to be discoverable by adversaries and take corrective actions to remediate non-compliant Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -263075,7 +273153,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -263103,6 +273182,12 @@ "general-nist-800-160-vol-2-r1": [ "RA-05(04)" ], + "general-nist-800-172-r3": [ + "03.11.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.11E[01]" + ], "general-pci-dss-4-0-1": [ "1.4.5" ], @@ -263123,6 +273208,9 @@ ], "apac-nzl-ism-3-9": [ "14.1.14.C.01" + ], + "americas-bmu-mba-coc-2020": [ + "6.15-BP4" ] } }, @@ -263179,7 +273267,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -263224,7 +273313,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, conduct annual penetration testing on network segments hosting High Value Assets (HVAs).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct penetration testing on Technology Assets, Applications and/or Services (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -263308,12 +273397,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { "general-cis-csc-8-1": [ - "18.0", + "18", "18.1", "18.2", "18.5" @@ -263376,8 +273466,11 @@ "CA-08", "SA-11(05)" ], - "general-nist-800-172": [ - "3.12.1e" + "general-nist-800-172-r3": [ + "03.12.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.01E" ], "general-pci-dss-4-0-1": [ "11.4", @@ -263452,6 +273545,9 @@ "CA-08", "SA-11(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(2)", "314.4(d)(2)(i)" @@ -263486,22 +273582,12 @@ "Article 26.8(b)", "Article 26.8(c)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-19", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "3.4", - "12.30", - "17.17", - "22.4", - "22.5" + "RB-18", + "RB-18-DOAR" ], "emea-sau-cscc-1-2019": [ - "2-10", + "2-10-1", "2-10-1-1", "2-10-1-2", "2-10-2" @@ -263510,21 +273596,19 @@ "2-10-1" ], "emea-sau-ecc-1-2018": [ - "2-11-3-1" + "2-11-1", + "2-11-2", + "2-11-3-1", + "2-11-3-2" ], "emea-sau-otcc-1-2022": [ - "2-10", - "2-10-1", - "2-10-1-1", "2-10-1-2", - "2-10-1-3", - "2-10-1-4", - "2-10-2" + "2-10-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-27", - "TPC-28", - "TPC-29" + "VII.B.TPC-27", + "VII.B.TPC-28", + "VII.B.TPC-29" ], "emea-gbr-def-stan-05-138-2024": [ "2403" @@ -263538,19 +273622,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2403" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163" ], + "apac-mys-bnm-rmit-2025": [ + "11.9" + ], "apac-sgp-mas-trm-2021": [ "13.2.1", "13.2.3", "13.2.4" ], "americas-bmu-mba-coc-2020": [ - "6.15" - ], - "amaericas-can-osfi-self-assessment": [ - "2.6" + "6.15-BP1" ], "americas-can-osfi-b13-2022": [ "3.1.2" @@ -263577,7 +273661,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, use red team exercises to simulate attempts by adversaries to compromise TAASD in accordance with entity-defined rules of engagement.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize an independent assessor or penetration team to perform penetration testing.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -263655,7 +273739,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -263741,16 +273826,6 @@ "Article 27.2(c)", "Article 27.3" ], - "emea-deu-c5-2020": [ - "OPS-19", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.16", - "17.17", - "22.4", - "22.5" - ], "emea-sau-cscc-1-2019": [ "2-10-1-2" ] @@ -263774,7 +273849,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a technical surveillance countermeasures survey.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -263826,7 +273901,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -263866,11 +273942,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to monitor logs associated with scanning activities and associated administrator accounts to ensure that those activities are limited to the timeframes of legitimate scans.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to monitor logs associated with scanning activities and associated administrator accounts to ensure that those activities are limited to the timeframes of legitimate scans. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -263913,7 +273989,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": {} @@ -263938,7 +274015,7 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, use red team exercises to simulate attempts by adversaries to compromise TAASD in accordance with entity-defined rules of engagement.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize \"red team\" exercises to simulate attempts by adversaries to compromise Technology Assets, Applications and/or Services (TAAS) in accordance with organization-defined rules of engagement.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize \"red team\" exercises to simulate attempts by adversaries to compromise Technology Assets, Applications and/or Services (TAAS) in accordance with organization-defined rules of engagement. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -264026,7 +274103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -264065,21 +274143,17 @@ "usa-federal-gsa-fedramp-5-high": [ "CA-08(02)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-sau-cgiot-2024": [ "2-10-2" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-9" - ], "apac-ind-sebi-2024": [ "DE.DP.S4" ], + "apac-mys-bnm-rmit-2025": [ + "11.6" + ], "apac-sgp-mas-trm-2021": [ - "13.3.1", - "13.3.2", + "8.5.1", "13.4.1", "13.4.2" ] @@ -264184,7 +274258,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -264198,6 +274273,9 @@ "general-nist-800-171-r3": [ "03.01.22.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a" + ], "general-pci-dss-4-0-1": [ "6.4", "6.4.1", @@ -264228,15 +274306,8 @@ "3.3.8", "3.3.8.c" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-sau-cscc-1-2019": [ - "2-12", + "2-12-1", "2-12-1-1", "2-12-1-2" ], @@ -264244,16 +274315,19 @@ "2-15-1", "2-15-2", "2-15-3", + "2-15-3-2", + "2-15-3-4", + "2-15-3-5", "2-15-4" ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.2 [MP.S.2]" - ], "apac-nzl-ism-3-9": [ "14.5.6.C.01", "14.5.7.C.01", "14.5.8.C.01" ], + "apac-sgp-mas-trm-2021": [ + "14.1.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A" ] @@ -264277,7 +274351,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to prevent unauthorized code from being present in a secure page as it is rendered in a client’s browser.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -264339,7 +274413,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -264378,7 +274453,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to utilize a Demilitarized Zone (DMZ) to restrict inbound traffic to authorized Technology Assets, Applications and/or Services (TAAS) on certain services, protocols and ports.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -264443,7 +274518,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -264489,19 +274565,18 @@ "usa-federal-irs-1075-2021": [ "3.3.8.a" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-sau-otcc-1-2022": [ - "2-4-1-10", "2-4-1-13" ], "emea-sau-sacs-002-2022": [ - "TPC-41" + "VII.B.TPC-41" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "mp.com.4" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" ] } }, @@ -264523,9 +274598,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy Web Application Firewalls (WAFs) to provide defense-in-depth protection for application-specific threats.", + "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy Web Application Firewalls (WAFs) to provide defense-in-depth protection for application-specific threats. ", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -264569,13 +274644,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ "4.4", - "13.1" + "13.10" ], "general-cis-csc-8-1-ig1": [ "4.4" @@ -264585,7 +274661,7 @@ ], "general-cis-csc-8-1-ig3": [ "4.4", - "13.1" + "13.10" ], "general-nist-800-53-r4": [ "SC-7(17)" @@ -264620,11 +274696,10 @@ "2-15-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-79" + "VII.B.TPC-79" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "apac-aus-ism-2026-march": [ + "ISM-1862" ] } }, @@ -264646,7 +274721,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy reasonably-expected security, compliance and resilience controls to protect the confidentiality and availability of client data that is stored, transmitted or processed by the Internet-based service.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -264703,9 +274778,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Web Security", "crosswalks": { "general-nist-800-171-r2": [ @@ -264728,12 +274803,17 @@ "52.204-21(b)(1)(iv)" ], "emea-sau-cscc-1-2019": [ - "2-12", - "2-12-1-1", - "2-12-1-2" + "2-12-1-1" ], - "emea-zaf-popia-2013": [ - "19" + "apac-sgp-mas-trm-2021": [ + "14.1.1", + "14.1.2", + "14.1.3", + "14.1.4", + "14.2.1", + "14.2.3", + "14.2.4", + "14.2.11" ] } }, @@ -264755,7 +274835,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to provide individuals with clear and precise information about cookies, in accordance with applicable legal requirements for cookie management.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -264803,7 +274883,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": {} @@ -264826,11 +274907,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to implement Strong Customer Authentication (SCA) for consumers to reasonably prove their identity.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. " }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -264885,7 +274966,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -264910,14 +274992,23 @@ "usa-state-tx-cdpa-2025": [ "541.055(a)(3)" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05" + "emea-eu-psd2-2015": [ + "97(1)", + "97(1)(a)", + "97(1)(b)", + "97(1)(c)", + "97(2)" ], "emea-sau-cscc-1-2019": [ "2-12-1-1" + ], + "apac-sgp-mas-trm-2021": [ + "14.2.1", + "14.2.5", + "14.2.6", + "14.2.7", + "14.2.8", + "14.2.9" ] } }, @@ -264939,7 +275030,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure the Open Web Application Security Project (OWASP) Application Security Verification Standard is incorporated into the organization's Secure Systems Development Lifecycle (SSDLC) process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -264994,27 +275085,32 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ - "16.0", + "16", "16.1", - "16.7" + "16.7", + "16.10" ], "general-cis-csc-8-1-ig2": [ "16.1", - "16.7" + "16.7", + "16.10" ], "general-cis-csc-8-1-ig3": [ "16.1", - "16.7" + "16.7", + "16.10" ], "emea-sau-cscc-1-2019": [ - "2-12-1-2" + "2-12-1-2", + "2-12-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0971", "ISM-1239" ], @@ -265028,8 +275124,8 @@ "control_id": "WEB-08", "title": "Web Application Framework", "family": "WEB", - "description": "Mechanisms exist to ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs.", - "scf_question": "Does the organization ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs?", + "description": "Mechanisms exist to use a robust Web Application Framework to support the development of secure web applications, including web services, web resources and web Application Programming Interfaces (APIs).", + "scf_question": "Does the organization use a robust Web Application Framework to support the development of secure web applications, including web services, web resources and web Application Programming Interfaces (APIs)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -265042,7 +275138,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -265050,7 +275146,6 @@ }, "profiles": [], "possible_solutions": { - "micro_small": "∙ Use a security-tested web framework", "small": "∙ Approved secure web framework policy\n∙ Use maintained frameworks only", "medium": "∙ Formal web application framework security requirements\n∙ Approved framework list", "large": "∙ Enterprise web framework governance program\n∙ Security-approved frameworks\n∙ Framework lifecycle management", @@ -265097,24 +275192,29 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ - "16.0", - "16.1" + "16", + "16.1", + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.1", + "16.10" ], "emea-sau-cscc-1-2019": [ "2-12-1-1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1239" ], "apac-nzl-ism-3-9": [ @@ -265141,7 +275241,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure all input handled by a web application is validated and/or sanitized.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -265196,11 +275296,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1240" ] } @@ -265223,7 +275324,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure all web application content is delivered using cryptographic mechanisms (e.g., TLS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -265280,7 +275381,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -265305,8 +275407,14 @@ "emea-sau-cscc-1-2019": [ "2-12-1-1" ], - "apac-aus-ism-2024-june": [ + "emea-sau-ecc-1-2018": [ + "2-15-3-3" + ], + "apac-aus-ism-2026-march": [ "ISM-1552" + ], + "apac-sgp-mas-trm-2021": [ + "14.2.2" ] } }, @@ -265328,7 +275436,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure output encoding is performed on all content produced by a web application to reduce the likelihood of cross-site scripting and other injection attacks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -265383,11 +275491,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1241" ] } @@ -265410,7 +275519,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure web applications implement Content-Security-Policy, HSTS and X-Frame-Options response headers to protect both the web application and its users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -265465,14 +275574,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "emea-sau-cscc-1-2019": [ - "2-12-1-1" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1424" ] } @@ -265481,8 +275588,8 @@ "control_id": "WEB-13", "title": "Website Change Detection", "family": "WEB", - "description": "Mechanisms exist to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data.", - "scf_question": "Does the organization detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data?", + "description": "Mechanisms exist to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive and/or regulated data.", + "scf_question": "Does the organization detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -265495,9 +275602,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data.", + "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -265557,7 +275664,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -265583,8 +275691,8 @@ "control_id": "WEB-14", "title": "Publicly Accessible Content Reviews", "family": "WEB", - "description": "Mechanisms exist to routinely review the content on publicly accessible systems for sensitive/regulated data and remove such information, if discovered.", - "scf_question": "Does the organization routinely review the content on publicly accessible systems for sensitive/regulated data and remove such information, if discovered?", + "description": "Mechanisms exist to routinely review the content on publicly accessible systems for sensitive and/or regulated data and remove such information, if discovered.", + "scf_question": "Does the organization routinely review the content on publicly accessible systems for sensitive and/or regulated data and remove such information, if discovered?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -265647,13 +275755,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-nist-800-171-r3": [ "03.01.22.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.b[02]" + ], "emea-gbr-def-stan-05-138-2024": [ "2321" ], diff --git a/docs/api/controls/AAT-01.1.json b/docs/api/controls/AAT-01.1.json index b96ed36f..f4c92c2a 100644 --- a/docs/api/controls/AAT-01.1.json +++ b/docs/api/controls/AAT-01.1.json @@ -84,7 +84,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-01.2.json b/docs/api/controls/AAT-01.2.json index 9cf4ed3d..31d521c1 100644 --- a/docs/api/controls/AAT-01.2.json +++ b/docs/api/controls/AAT-01.2.json @@ -98,7 +98,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-01.3.json b/docs/api/controls/AAT-01.3.json index 04a11646..37f0c6fd 100644 --- a/docs/api/controls/AAT-01.3.json +++ b/docs/api/controls/AAT-01.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to sustain the value of deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-01.4.json b/docs/api/controls/AAT-01.4.json index 6372f932..2ddd4542 100644 --- a/docs/api/controls/AAT-01.4.json +++ b/docs/api/controls/AAT-01.4.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-01.5.json b/docs/api/controls/AAT-01.5.json new file mode 100644 index 00000000..b170b206 --- /dev/null +++ b/docs/api/controls/AAT-01.5.json @@ -0,0 +1,104 @@ +{ + "control_id": "AAT-01.5", + "title": "Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization", + "family": "AAT", + "description": "Mechanisms exist to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements.", + "scf_question": "Does the organization assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ AI system inventory with basic use-case categorization\n∙ NIST AI RMF categorization guidance.\n∙ Designated responsible party for AI tools in use", + "small": "∙ AI system inventory with risk-based categorization\n∙ NIST AI RMF categorization guidance\n∙ EU AI Act risk tier mapping.", + "medium": "∙ Formal AI system categorization process\n∙ EU AI Act risk tier mapping\n∙ NIST AI RMF implementation\n∙ AI risk register with categorization metadata", + "large": "∙ Formal AI governance program with defined categorization criteria\n∙ EU AI Act compliance mapping\n∙ NIST AI RMF full implementation\n∙ AI Risk Management Committee-approved categorization", + "enterprise": "∙ Enterprise AI categorization program with automated registry\n∙ EU AI Act and ISO/IEC 42001 alignment\n∙ Board-level AI risk reporting by category" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/AAT-01.json b/docs/api/controls/AAT-01.json index 025524b6..d8412832 100644 --- a/docs/api/controls/AAT-01.json +++ b/docs/api/controls/AAT-01.json @@ -107,7 +107,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -182,6 +183,10 @@ ], "emea-eu-ai-act-2024": [ "Article 17.1(c)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2072", + "ISM-2074" ] } } \ No newline at end of file diff --git a/docs/api/controls/AAT-02.1.json b/docs/api/controls/AAT-02.1.json index edebaf3f..197415cb 100644 --- a/docs/api/controls/AAT-02.1.json +++ b/docs/api/controls/AAT-02.1.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-02.2.json b/docs/api/controls/AAT-02.2.json index 52a1de72..ceeff397 100644 --- a/docs/api/controls/AAT-02.2.json +++ b/docs/api/controls/AAT-02.2.json @@ -94,9 +94,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-iso-42001-2023": [ diff --git a/docs/api/controls/AAT-02.3.json b/docs/api/controls/AAT-02.3.json index 1f0e8f05..265f22cc 100644 --- a/docs/api/controls/AAT-02.3.json +++ b/docs/api/controls/AAT-02.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT include reasonable security, compliance and resilience protections that are commensurate with assessed risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,9 +95,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-600-1-gen-ai-profile": [ diff --git a/docs/api/controls/AAT-02.4.json b/docs/api/controls/AAT-02.4.json index 8ca36450..2a18cd27 100644 --- a/docs/api/controls/AAT-02.4.json +++ b/docs/api/controls/AAT-02.4.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-02.json b/docs/api/controls/AAT-02.json index 78478dcd..55257b69 100644 --- a/docs/api/controls/AAT-02.json +++ b/docs/api/controls/AAT-02.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-03.1.json b/docs/api/controls/AAT-03.1.json index 038b718d..b87a595a 100644 --- a/docs/api/controls/AAT-03.1.json +++ b/docs/api/controls/AAT-03.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to define and document the organization's mission and defined goals for AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-03.2.json b/docs/api/controls/AAT-03.2.json index edb870e5..ee899115 100644 --- a/docs/api/controls/AAT-03.2.json +++ b/docs/api/controls/AAT-03.2.json @@ -97,7 +97,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-03.json b/docs/api/controls/AAT-03.json index f0b35041..4f4d1cfa 100644 --- a/docs/api/controls/AAT-03.json +++ b/docs/api/controls/AAT-03.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -118,6 +119,9 @@ ], "emea-eu-ai-act-2024": [ "Article 8.1" + ], + "apac-aus-ism-2026-march": [ + "ISM-2084" ] } } \ No newline at end of file diff --git a/docs/api/controls/AAT-04.1.json b/docs/api/controls/AAT-04.1.json index e4a61e6d..84ca096a 100644 --- a/docs/api/controls/AAT-04.1.json +++ b/docs/api/controls/AAT-04.1.json @@ -93,7 +93,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-04.2.json b/docs/api/controls/AAT-04.2.json index 24406ae8..b3033efa 100644 --- a/docs/api/controls/AAT-04.2.json +++ b/docs/api/controls/AAT-04.2.json @@ -93,7 +93,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-04.3.json b/docs/api/controls/AAT-04.3.json index 634170e3..865149b6 100644 --- a/docs/api/controls/AAT-04.3.json +++ b/docs/api/controls/AAT-04.3.json @@ -93,7 +93,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-04.4.json b/docs/api/controls/AAT-04.4.json index 7a4d6f06..c564a31b 100644 --- a/docs/api/controls/AAT-04.4.json +++ b/docs/api/controls/AAT-04.4.json @@ -80,7 +80,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-04.json b/docs/api/controls/AAT-04.json index 460023cf..4dec0985 100644 --- a/docs/api/controls/AAT-04.json +++ b/docs/api/controls/AAT-04.json @@ -83,7 +83,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-05.json b/docs/api/controls/AAT-05.json index 60d96195..16748925 100644 --- a/docs/api/controls/AAT-05.json +++ b/docs/api/controls/AAT-05.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-06.json b/docs/api/controls/AAT-06.json index 536331eb..16501a99 100644 --- a/docs/api/controls/AAT-06.json +++ b/docs/api/controls/AAT-06.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-07.1.json b/docs/api/controls/AAT-07.1.json index c4a406b2..5ad651bc 100644 --- a/docs/api/controls/AAT-07.1.json +++ b/docs/api/controls/AAT-07.1.json @@ -97,7 +97,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-07.2.json b/docs/api/controls/AAT-07.2.json index c8c68d6e..c5983684 100644 --- a/docs/api/controls/AAT-07.2.json +++ b/docs/api/controls/AAT-07.2.json @@ -97,7 +97,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-07.3.json b/docs/api/controls/AAT-07.3.json index 8615a5bf..3c84e37b 100644 --- a/docs/api/controls/AAT-07.3.json +++ b/docs/api/controls/AAT-07.3.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-07.json b/docs/api/controls/AAT-07.json index 40d521e3..7474661b 100644 --- a/docs/api/controls/AAT-07.json +++ b/docs/api/controls/AAT-07.json @@ -97,7 +97,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-08.json b/docs/api/controls/AAT-08.json index 42e7f313..bebdc211 100644 --- a/docs/api/controls/AAT-08.json +++ b/docs/api/controls/AAT-08.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-09.1.json b/docs/api/controls/AAT-09.1.json index 7242f804..964ef98c 100644 --- a/docs/api/controls/AAT-09.1.json +++ b/docs/api/controls/AAT-09.1.json @@ -2,8 +2,8 @@ "control_id": "AAT-09.1", "title": "AI & Autonomous Technologies High Risk Designations", "family": "AAT", - "description": "Mechanisms exist to designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", - "scf_question": "Does the organization designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making?", + "description": "Mechanisms exist to designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one (1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", + "scf_question": "Does the organization designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one (1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making?", "relative_weight": 7, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to designate AAT \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -111,6 +112,9 @@ "Article 51.1", "Article 51.1(a)", "Article 51.2" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/AAT-09.json b/docs/api/controls/AAT-09.json index 55a8ac2e..61139823 100644 --- a/docs/api/controls/AAT-09.json +++ b/docs/api/controls/AAT-09.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.1.json b/docs/api/controls/AAT-10.1.json index 523cc5f4..de87f948 100644 --- a/docs/api/controls/AAT-10.1.json +++ b/docs/api/controls/AAT-10.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate AAT for trustworthy behavior and operation including security, anonymization and disaggregation of captured and stored data for approved purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.10.json b/docs/api/controls/AAT-10.10.json index 9673f030..f36ff16c 100644 --- a/docs/api/controls/AAT-10.10.json +++ b/docs/api/controls/AAT-10.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the results of Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) to determine the viability of the proposed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77,7 +77,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.11.json b/docs/api/controls/AAT-10.11.json index 344186ed..5462bfbf 100644 --- a/docs/api/controls/AAT-10.11.json +++ b/docs/api/controls/AAT-10.11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the effectiveness of the processes utilized to perform Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.12.json b/docs/api/controls/AAT-10.12.json index e2ad1401..aa749a58 100644 --- a/docs/api/controls/AAT-10.12.json +++ b/docs/api/controls/AAT-10.12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate AAT-related performance or the assurance criteria demonstrated for conditions similar to deployment settings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.13.json b/docs/api/controls/AAT-10.13.json index c30a0a4f..7fd0db1a 100644 --- a/docs/api/controls/AAT-10.13.json +++ b/docs/api/controls/AAT-10.13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to proactively and continuously monitor deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.14.json b/docs/api/controls/AAT-10.14.json index 18963693..ead2827d 100644 --- a/docs/api/controls/AAT-10.14.json +++ b/docs/api/controls/AAT-10.14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to integrate continual improvements for deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77,7 +77,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.15.json b/docs/api/controls/AAT-10.15.json index 00cbb56e..6b473bbd 100644 --- a/docs/api/controls/AAT-10.15.json +++ b/docs/api/controls/AAT-10.15.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to report the status and results of Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) to relevant stakeholders, including governing bodies, as required.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.16.json b/docs/api/controls/AAT-10.16.json index 65fbced0..0c28d07a 100644 --- a/docs/api/controls/AAT-10.16.json +++ b/docs/api/controls/AAT-10.16.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate claims of AAT model capabilities using empirically validated methods.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.17.json b/docs/api/controls/AAT-10.17.json index ac140fce..233d2808 100644 --- a/docs/api/controls/AAT-10.17.json +++ b/docs/api/controls/AAT-10.17.json @@ -3,7 +3,7 @@ "title": "AI TEVV Benchmarking Content Provenance", "family": "AAT", "description": "Mechanisms exist to benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry-recognized standards.", - "scf_question": "Does the organization benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry -recognized standards?", + "scf_question": "Does the organization benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry-recognized standards?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to benchmark the verifiable lineage and origin of content used by AAT according to industry-recognized standards.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.18.json b/docs/api/controls/AAT-10.18.json index 77609372..d3a65b4e 100644 --- a/docs/api/controls/AAT-10.18.json +++ b/docs/api/controls/AAT-10.18.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to mitigate concerns of model collapse by:\n(1) Assessing the proportion of synthetic to non-synthetic training data; and\n(2) Verifying training data is not overly homogenous or AAT system-produced.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.19.json b/docs/api/controls/AAT-10.19.json index 8329cd40..69b2c5d6 100644 --- a/docs/api/controls/AAT-10.19.json +++ b/docs/api/controls/AAT-10.19.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-10.2.json b/docs/api/controls/AAT-10.2.json index 7a130117..3a8f2475 100644 --- a/docs/api/controls/AAT-10.2.json +++ b/docs/api/controls/AAT-10.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to document test sets, metrics and details about the tools used during Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.3.json b/docs/api/controls/AAT-10.3.json index 3d63abfa..8f7de520 100644 --- a/docs/api/controls/AAT-10.3.json +++ b/docs/api/controls/AAT-10.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to demonstrate the AAT to be deployed are:\n(1) Valid;\n(2) Reliable; and\n(3) Operate as intended, based on approved designs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.4.json b/docs/api/controls/AAT-10.4.json index a443fc7b..d78dd4e3 100644 --- a/docs/api/controls/AAT-10.4.json +++ b/docs/api/controls/AAT-10.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to demonstrate the AAT to be deployed are safe, residual risk does not exceed the organization's risk tolerance and can fail safely, particularly if made to operate beyond its knowledge limits.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.5.json b/docs/api/controls/AAT-10.5.json index 8cf1cb18..067ca6d8 100644 --- a/docs/api/controls/AAT-10.5.json +++ b/docs/api/controls/AAT-10.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the security and resilience of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.6.json b/docs/api/controls/AAT-10.6.json index d2841d33..457dc479 100644 --- a/docs/api/controls/AAT-10.6.json +++ b/docs/api/controls/AAT-10.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine risks associated with transparency and accountability of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.7.json b/docs/api/controls/AAT-10.7.json index 02fed0c4..db1fbdc6 100644 --- a/docs/api/controls/AAT-10.7.json +++ b/docs/api/controls/AAT-10.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine the data privacy risk of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.8.json b/docs/api/controls/AAT-10.8.json index 980492f7..d79696a3 100644 --- a/docs/api/controls/AAT-10.8.json +++ b/docs/api/controls/AAT-10.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine fairness and bias of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.9.json b/docs/api/controls/AAT-10.9.json index dccf5050..9c1e3284 100644 --- a/docs/api/controls/AAT-10.9.json +++ b/docs/api/controls/AAT-10.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate the AAT model.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-10.json b/docs/api/controls/AAT-10.json index db718c19..d14e81b4 100644 --- a/docs/api/controls/AAT-10.json +++ b/docs/api/controls/AAT-10.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices to enable AAT-related security, resilience and compliance-related conformity testing throughout the lifecycle of the AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -99,7 +99,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-11.1.json b/docs/api/controls/AAT-11.1.json index d5aae056..5a896cf4 100644 --- a/docs/api/controls/AAT-11.1.json +++ b/docs/api/controls/AAT-11.1.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-11.2.json b/docs/api/controls/AAT-11.2.json index 987de947..f70d41ab 100644 --- a/docs/api/controls/AAT-11.2.json +++ b/docs/api/controls/AAT-11.2.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-11.3.json b/docs/api/controls/AAT-11.3.json index fb9b5c29..99abff77 100644 --- a/docs/api/controls/AAT-11.3.json +++ b/docs/api/controls/AAT-11.3.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-11.4.json b/docs/api/controls/AAT-11.4.json index 49795dc1..ee1e7540 100644 --- a/docs/api/controls/AAT-11.4.json +++ b/docs/api/controls/AAT-11.4.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to communicate AAT-related incidents and/or errors to relevant stakeholders, including affected communities.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to communicate AAT-related incidents and/or errors to relevant stakeholders, including affected communities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-11.json b/docs/api/controls/AAT-11.json index f8a12cb5..96740ec4 100644 --- a/docs/api/controls/AAT-11.json +++ b/docs/api/controls/AAT-11.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-12.1.json b/docs/api/controls/AAT-12.1.json index 97722a53..9437cdec 100644 --- a/docs/api/controls/AAT-12.1.json +++ b/docs/api/controls/AAT-12.1.json @@ -93,7 +93,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -135,6 +136,10 @@ ], "emea-eu-ai-act-2024": [ "Article 17.1(f)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2086", + "ISM-2087" ] } } \ No newline at end of file diff --git a/docs/api/controls/AAT-12.2.json b/docs/api/controls/AAT-12.2.json index cf733d26..5f0f7ced 100644 --- a/docs/api/controls/AAT-12.2.json +++ b/docs/api/controls/AAT-12.2.json @@ -91,7 +91,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-12.3.json b/docs/api/controls/AAT-12.3.json index 1788df01..dd4efcd1 100644 --- a/docs/api/controls/AAT-12.3.json +++ b/docs/api/controls/AAT-12.3.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-12.4.json b/docs/api/controls/AAT-12.4.json index 5cfb8c96..f30da310 100644 --- a/docs/api/controls/AAT-12.4.json +++ b/docs/api/controls/AAT-12.4.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-12.5.json b/docs/api/controls/AAT-12.5.json new file mode 100644 index 00000000..1227464b --- /dev/null +++ b/docs/api/controls/AAT-12.5.json @@ -0,0 +1,105 @@ +{ + "control_id": "AAT-12.5", + "title": "Training Data Source & Integrity", + "family": "AAT", + "description": "Mechanisms exist to validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT).", + "scf_question": "Does the organization validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Documented training data provenance\n∙ Basic data quality checks before model training\n∙ Vendor attestations for third-party training data", + "small": "∙ Training data source documentation\n∙ Vendor-supplied training data integrity attestations\n∙ Data quality validation before training", + "medium": "∙ Training data validation pipeline\n∙ Data provenance documentation\n∙ Data integrity checks (hash verification, data quality metrics)", + "large": "∙ Formal training data governance program\n∙ Automated data quality and integrity validation\n∙ Training data lineage tracking", + "enterprise": "∙ Enterprise AI data governance framework\n∙ Automated training data validation pipelines\n∙ Third-party training data audits\n∙ Data integrity monitoring throughout the AI lifecycle" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SM-2088", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2088" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/AAT-12.6.json b/docs/api/controls/AAT-12.6.json new file mode 100644 index 00000000..e7325c99 --- /dev/null +++ b/docs/api/controls/AAT-12.6.json @@ -0,0 +1,105 @@ +{ + "control_id": "AAT-12.6", + "title": "Prohibit Training", + "family": "AAT", + "description": "Mechanisms exist to prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "scf_question": "Does the organization prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Acceptable Use Policy (AUP) prohibiting unauthorized AI training\n∙ Contractual review of AI vendor terms of service", + "small": "∙ AI usage policy prohibiting unauthorized training\n∙ Employee acknowledgment of AI data use restrictions", + "medium": "∙ AI usage policy prohibiting unauthorized training on organizational data\n∙ Vendor contract reviews for training restrictions\n∙ Data Handling Agreements (DHA) with AI vendors", + "large": "∙ Formal AI data usage policy\n∙ Technical controls preventing data uploads to unauthorized AI systems\n∙ Data Loss Prevention (DLP) for AI training data", + "enterprise": "∙ Enterprise AI data governance policy\n∙ DLP controls restricting data to authorized AI platforms\n∙ Automated enforcement of training data restrictions\n∙ Regular audits of AI vendor training data handling" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2103", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2103" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/AAT-12.json b/docs/api/controls/AAT-12.json index 7d685d89..4adbe959 100644 --- a/docs/api/controls/AAT-12.json +++ b/docs/api/controls/AAT-12.json @@ -84,7 +84,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-13.1.json b/docs/api/controls/AAT-13.1.json index 96e96ea2..bb0cd250 100644 --- a/docs/api/controls/AAT-13.1.json +++ b/docs/api/controls/AAT-13.1.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-13.json b/docs/api/controls/AAT-13.json index 4ae6f00a..aca014ce 100644 --- a/docs/api/controls/AAT-13.json +++ b/docs/api/controls/AAT-13.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-14.1.json b/docs/api/controls/AAT-14.1.json index d60773d5..aec089ac 100644 --- a/docs/api/controls/AAT-14.1.json +++ b/docs/api/controls/AAT-14.1.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-14.2.json b/docs/api/controls/AAT-14.2.json index 6a6fb88d..e800f1e8 100644 --- a/docs/api/controls/AAT-14.2.json +++ b/docs/api/controls/AAT-14.2.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-14.json b/docs/api/controls/AAT-14.json index 89e36026..2d9836e6 100644 --- a/docs/api/controls/AAT-14.json +++ b/docs/api/controls/AAT-14.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-15.1.json b/docs/api/controls/AAT-15.1.json index a9d3d8fb..54d60321 100644 --- a/docs/api/controls/AAT-15.1.json +++ b/docs/api/controls/AAT-15.1.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-15.2.json b/docs/api/controls/AAT-15.2.json index 4179bf3b..5a36a534 100644 --- a/docs/api/controls/AAT-15.2.json +++ b/docs/api/controls/AAT-15.2.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-15.json b/docs/api/controls/AAT-15.json index 5491ab7a..be7ff9d4 100644 --- a/docs/api/controls/AAT-15.json +++ b/docs/api/controls/AAT-15.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.1.json b/docs/api/controls/AAT-16.1.json index 0d4985f7..8597d408 100644 --- a/docs/api/controls/AAT-16.1.json +++ b/docs/api/controls/AAT-16.1.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.10.json b/docs/api/controls/AAT-16.10.json index 5dbec473..dabb8cbe 100644 --- a/docs/api/controls/AAT-16.10.json +++ b/docs/api/controls/AAT-16.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to perform an investigation when there is a serious incident involving operational AAT that documents a:\n(1) Root Cause Analysis (RCA);\n(2) Risk assessment of the incident; and \n(3) Description of corrective actions taken, including measures implemented to prevent a recurrence of the incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.11.json b/docs/api/controls/AAT-16.11.json index 5d5777cc..5d180a53 100644 --- a/docs/api/controls/AAT-16.11.json +++ b/docs/api/controls/AAT-16.11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to analyze anomalous AAT behavior and provide escalation paths for human oversight, including:\n(1) Real-time review; and\n(2) Intervention.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,12 +96,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-csa-iot-2": [ "SAP-10" + ], + "apac-aus-ism-2026-march": [ + "ISM-2089" ] } } \ No newline at end of file diff --git a/docs/api/controls/AAT-16.12.json b/docs/api/controls/AAT-16.12.json index 0f828c0a..dbca0b54 100644 --- a/docs/api/controls/AAT-16.12.json +++ b/docs/api/controls/AAT-16.12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to require human review and clear escalation paths for approval for high-risk or ambiguous AAT actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-16.13.json b/docs/api/controls/AAT-16.13.json index 9cc370c6..6b61f3b6 100644 --- a/docs/api/controls/AAT-16.13.json +++ b/docs/api/controls/AAT-16.13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and contain emergent or collusive behaviors among multiple AAT, including:\n(1) Automated or human-triggered containment; and \n(2) Formal investigation to determine the root cause of agentic cascades or collusion.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-16.14.json b/docs/api/controls/AAT-16.14.json index 9f87fde3..465d4144 100644 --- a/docs/api/controls/AAT-16.14.json +++ b/docs/api/controls/AAT-16.14.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-16.2.json b/docs/api/controls/AAT-16.2.json index fb275683..3a7737fe 100644 --- a/docs/api/controls/AAT-16.2.json +++ b/docs/api/controls/AAT-16.2.json @@ -94,9 +94,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-100-1-ai-rmf": [ diff --git a/docs/api/controls/AAT-16.3.json b/docs/api/controls/AAT-16.3.json index 97003679..27f28933 100644 --- a/docs/api/controls/AAT-16.3.json +++ b/docs/api/controls/AAT-16.3.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.4.json b/docs/api/controls/AAT-16.4.json index f9ff4609..8062d466 100644 --- a/docs/api/controls/AAT-16.4.json +++ b/docs/api/controls/AAT-16.4.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.5.json b/docs/api/controls/AAT-16.5.json index 68f4339c..0bb6a925 100644 --- a/docs/api/controls/AAT-16.5.json +++ b/docs/api/controls/AAT-16.5.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.6.json b/docs/api/controls/AAT-16.6.json index 839630bf..35bd4fac 100644 --- a/docs/api/controls/AAT-16.6.json +++ b/docs/api/controls/AAT-16.6.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.7.json b/docs/api/controls/AAT-16.7.json index c50d6886..0edaa3cf 100644 --- a/docs/api/controls/AAT-16.7.json +++ b/docs/api/controls/AAT-16.7.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.8.json b/docs/api/controls/AAT-16.8.json index 54eadb47..d53c3457 100644 --- a/docs/api/controls/AAT-16.8.json +++ b/docs/api/controls/AAT-16.8.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.9.json b/docs/api/controls/AAT-16.9.json index 1dc3b8a0..b9ce991f 100644 --- a/docs/api/controls/AAT-16.9.json +++ b/docs/api/controls/AAT-16.9.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-16.json b/docs/api/controls/AAT-16.json index 1c608442..91ff6911 100644 --- a/docs/api/controls/AAT-16.json +++ b/docs/api/controls/AAT-16.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-17.1.json b/docs/api/controls/AAT-17.1.json index dfcb3843..aff357c8 100644 --- a/docs/api/controls/AAT-17.1.json +++ b/docs/api/controls/AAT-17.1.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-17.2.json b/docs/api/controls/AAT-17.2.json index bf8c7ac0..3a2ed4be 100644 --- a/docs/api/controls/AAT-17.2.json +++ b/docs/api/controls/AAT-17.2.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-17.3.json b/docs/api/controls/AAT-17.3.json index 3acbeb85..a8744bb8 100644 --- a/docs/api/controls/AAT-17.3.json +++ b/docs/api/controls/AAT-17.3.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-17.4.json b/docs/api/controls/AAT-17.4.json index 97e44d3a..73b5f4bd 100644 --- a/docs/api/controls/AAT-17.4.json +++ b/docs/api/controls/AAT-17.4.json @@ -93,7 +93,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-17.5.json b/docs/api/controls/AAT-17.5.json index 53292612..906dd7b4 100644 --- a/docs/api/controls/AAT-17.5.json +++ b/docs/api/controls/AAT-17.5.json @@ -94,9 +94,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-600-1-gen-ai-profile": [ diff --git a/docs/api/controls/AAT-17.json b/docs/api/controls/AAT-17.json index e6cb84bd..cc97c93d 100644 --- a/docs/api/controls/AAT-17.json +++ b/docs/api/controls/AAT-17.json @@ -97,7 +97,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -111,6 +112,9 @@ ], "emea-eu-ai-act-2024": [ "Article 14.2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2094" ] } } \ No newline at end of file diff --git a/docs/api/controls/AAT-18.1.json b/docs/api/controls/AAT-18.1.json index cc524728..955bb279 100644 --- a/docs/api/controls/AAT-18.1.json +++ b/docs/api/controls/AAT-18.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prioritize, respond to and remediate AAT-related risks based on assessments and other analytical output.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-18.json b/docs/api/controls/AAT-18.json index ff47459e..d0714ccb 100644 --- a/docs/api/controls/AAT-18.json +++ b/docs/api/controls/AAT-18.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.1.json b/docs/api/controls/AAT-19.1.json index 48153ca4..ebb6e1cb 100644 --- a/docs/api/controls/AAT-19.1.json +++ b/docs/api/controls/AAT-19.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that utilize manipulative or deceptive techniques (including biased data) to impair an individual's ability to make a reasonably informed decision.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.2.json b/docs/api/controls/AAT-19.2.json index 154aa9f9..33c2ac2b 100644 --- a/docs/api/controls/AAT-19.2.json +++ b/docs/api/controls/AAT-19.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that exploit a human subject to materially affect a targeted behavior due to their:\n(1) Age;\n(2) Disability; or \n(3) Specific social or economic situation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.3.json b/docs/api/controls/AAT-19.3.json index c3f31515..e035c3b1 100644 --- a/docs/api/controls/AAT-19.3.json +++ b/docs/api/controls/AAT-19.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that: \n(1) Evaluate human subjects over a certain period of time based on their social behavior or known, inferred or predicted personal or personality characteristics; and\n(2) Assign a \"social score\" branding or equivalent classification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.4.json b/docs/api/controls/AAT-19.4.json index b68115d5..d03a0f75 100644 --- a/docs/api/controls/AAT-19.4.json +++ b/docs/api/controls/AAT-19.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that lead to the detrimental or unfavorable treatment of certain data subjects, or groups of data subjects, in social contexts that is:\n(1) Are unrelated to the contexts in which the data was originally generated or collected; and/or\n(2) Is unjustified or disproportionate to their social behavior or its gravity.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.5.json b/docs/api/controls/AAT-19.5.json index 8d54f0ce..c7d308ec 100644 --- a/docs/api/controls/AAT-19.5.json +++ b/docs/api/controls/AAT-19.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that:\n(1) Assess the risk of an individual committing a criminal offence; and\n(2) Predicts risk based solely on the profiling of personality traits and characteristics.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.6.json b/docs/api/controls/AAT-19.6.json index a2407389..1e45c5fd 100644 --- a/docs/api/controls/AAT-19.6.json +++ b/docs/api/controls/AAT-19.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that create, or expand, facial recognition databases through scraping facial images from:\n(1) The Internet; or \n(2) Closed-Circuit Television (CCTV) footage.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.7.json b/docs/api/controls/AAT-19.7.json index ba68815b..d11e5d98 100644 --- a/docs/api/controls/AAT-19.7.json +++ b/docs/api/controls/AAT-19.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that infer human emotions of an individual based on observed characteristics.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.8.json b/docs/api/controls/AAT-19.8.json index dcfe32e4..9f655c06 100644 --- a/docs/api/controls/AAT-19.8.json +++ b/docs/api/controls/AAT-19.8.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-19.json b/docs/api/controls/AAT-19.json index 35d2834b..5519f524 100644 --- a/docs/api/controls/AAT-19.json +++ b/docs/api/controls/AAT-19.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure deployed AAT conform to applicable statutory and regulatory requirements, based on:\n(1) Defined use cases;\n(2) Geographic markets; and\n(3) Use of Intellectual Property (IP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-20.1.json b/docs/api/controls/AAT-20.1.json index 7752d579..057af5b4 100644 --- a/docs/api/controls/AAT-20.1.json +++ b/docs/api/controls/AAT-20.1.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-20.2.json b/docs/api/controls/AAT-20.2.json index 5edeac8e..6d3bc248 100644 --- a/docs/api/controls/AAT-20.2.json +++ b/docs/api/controls/AAT-20.2.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-20.3.json b/docs/api/controls/AAT-20.3.json index 88e4b0e6..240b3318 100644 --- a/docs/api/controls/AAT-20.3.json +++ b/docs/api/controls/AAT-20.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to document the extent to which human domain knowledge is employed to improve AAT performance including:\n(1) Reinforcement Learning from Human Feedback (RLHF);\n(2) Fine-tuning;\n(3) Retrieval- augmented generation;\n(4) Content moderation; and\n(5) Business rules.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-20.json b/docs/api/controls/AAT-20.json index f8e64702..c0220441 100644 --- a/docs/api/controls/AAT-20.json +++ b/docs/api/controls/AAT-20.json @@ -3,7 +3,7 @@ "title": "AI & Autonomous Technologies Development Practices", "family": "AAT", "description": "Measures exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals.", - "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness, and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals?", + "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -20,7 +20,7 @@ "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ Measures exist to ensure AAT are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals.", "4": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-21.json b/docs/api/controls/AAT-21.json index 997b5608..898ec326 100644 --- a/docs/api/controls/AAT-21.json +++ b/docs/api/controls/AAT-21.json @@ -93,7 +93,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.1.json b/docs/api/controls/AAT-22.1.json index ab16566e..398fb091 100644 --- a/docs/api/controls/AAT-22.1.json +++ b/docs/api/controls/AAT-22.1.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.2.json b/docs/api/controls/AAT-22.2.json index 1b4378c7..3a65a3cb 100644 --- a/docs/api/controls/AAT-22.2.json +++ b/docs/api/controls/AAT-22.2.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.3.json b/docs/api/controls/AAT-22.3.json index 6eb2680b..c2d2b444 100644 --- a/docs/api/controls/AAT-22.3.json +++ b/docs/api/controls/AAT-22.3.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.4.json b/docs/api/controls/AAT-22.4.json index 748a8ae3..dadde556 100644 --- a/docs/api/controls/AAT-22.4.json +++ b/docs/api/controls/AAT-22.4.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.5.json b/docs/api/controls/AAT-22.5.json index 6449898e..33b8c5f5 100644 --- a/docs/api/controls/AAT-22.5.json +++ b/docs/api/controls/AAT-22.5.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.6.json b/docs/api/controls/AAT-22.6.json index 37b7b4ed..8a1e593a 100644 --- a/docs/api/controls/AAT-22.6.json +++ b/docs/api/controls/AAT-22.6.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.7.json b/docs/api/controls/AAT-22.7.json index 19d5762b..c784e1a5 100644 --- a/docs/api/controls/AAT-22.7.json +++ b/docs/api/controls/AAT-22.7.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.8.json b/docs/api/controls/AAT-22.8.json index 80fc3519..2d5f61c4 100644 --- a/docs/api/controls/AAT-22.8.json +++ b/docs/api/controls/AAT-22.8.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-22.json b/docs/api/controls/AAT-22.json index efac25b0..d6dcc11e 100644 --- a/docs/api/controls/AAT-22.json +++ b/docs/api/controls/AAT-22.json @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-23.json b/docs/api/controls/AAT-23.json index e4573376..f7c234f4 100644 --- a/docs/api/controls/AAT-23.json +++ b/docs/api/controls/AAT-23.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-24.json b/docs/api/controls/AAT-24.json index e356fff0..dbe8d4af 100644 --- a/docs/api/controls/AAT-24.json +++ b/docs/api/controls/AAT-24.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-25.1.json b/docs/api/controls/AAT-25.1.json index 9d745630..6d2729a0 100644 --- a/docs/api/controls/AAT-25.1.json +++ b/docs/api/controls/AAT-25.1.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-25.json b/docs/api/controls/AAT-25.json index f53fb780..a7b6d68e 100644 --- a/docs/api/controls/AAT-25.json +++ b/docs/api/controls/AAT-25.json @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-26.1.json b/docs/api/controls/AAT-26.1.json index 9347668b..7f923b64 100644 --- a/docs/api/controls/AAT-26.1.json +++ b/docs/api/controls/AAT-26.1.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-26.2.json b/docs/api/controls/AAT-26.2.json index ae428ea2..67644240 100644 --- a/docs/api/controls/AAT-26.2.json +++ b/docs/api/controls/AAT-26.2.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-26.3.json b/docs/api/controls/AAT-26.3.json index 16e73695..5890936f 100644 --- a/docs/api/controls/AAT-26.3.json +++ b/docs/api/controls/AAT-26.3.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-26.4.json b/docs/api/controls/AAT-26.4.json index 3055fe2d..5a8c6dad 100644 --- a/docs/api/controls/AAT-26.4.json +++ b/docs/api/controls/AAT-26.4.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-26.json b/docs/api/controls/AAT-26.json index 9a189cbd..63a8f0f5 100644 --- a/docs/api/controls/AAT-26.json +++ b/docs/api/controls/AAT-26.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-27.1.json b/docs/api/controls/AAT-27.1.json index 9eb259f8..8e1d0076 100644 --- a/docs/api/controls/AAT-27.1.json +++ b/docs/api/controls/AAT-27.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to assign personnel to review AAT-generated content for alignment with culturally accepted norms.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-27.json b/docs/api/controls/AAT-27.json index 5090d40e..f5a1d5ae 100644 --- a/docs/api/controls/AAT-27.json +++ b/docs/api/controls/AAT-27.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-28.1.json b/docs/api/controls/AAT-28.1.json index 360578ee..8a23655c 100644 --- a/docs/api/controls/AAT-28.1.json +++ b/docs/api/controls/AAT-28.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent \"model pollution\" due to accidental and/or malicious inputs by an AI agent that can negatively alter the AI model.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-28.2.json b/docs/api/controls/AAT-28.2.json index 17a836c4..2ead6865 100644 --- a/docs/api/controls/AAT-28.2.json +++ b/docs/api/controls/AAT-28.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and prevent the propagation of false data (e.g., hallucinations) within the AI model or between AI agents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-28.3.json b/docs/api/controls/AAT-28.3.json index eff6c166..1c853196 100644 --- a/docs/api/controls/AAT-28.3.json +++ b/docs/api/controls/AAT-28.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to monitor and prevent resource overload or Denial of Service (DoS) conditions through:\n(1) Enforcement of quotas;\n(2) Workload controls; and \n(3) Auto-suspension of runaway AI agent processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-28.json b/docs/api/controls/AAT-28.json index 4574c11a..49606d9d 100644 --- a/docs/api/controls/AAT-28.json +++ b/docs/api/controls/AAT-28.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI models are designed with resilience capabilities that are sufficient to withstand reasonable threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.1.json b/docs/api/controls/AAT-29.1.json index b2340430..bb30f6d8 100644 --- a/docs/api/controls/AAT-29.1.json +++ b/docs/api/controls/AAT-29.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to protect, isolate and harden infrastructure resources used by AI agents, including:\n(1) Resource allocation;\n(2) Privilege management;\n(3) Network segmentation; and \n(4) Workload isolation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.10.json b/docs/api/controls/AAT-29.10.json index ab84bcfd..30623911 100644 --- a/docs/api/controls/AAT-29.10.json +++ b/docs/api/controls/AAT-29.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent AI agent logic from being subverted or manipulated.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.11.json b/docs/api/controls/AAT-29.11.json index d0a00f8a..a7f75154 100644 --- a/docs/api/controls/AAT-29.11.json +++ b/docs/api/controls/AAT-29.11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to utilize a \"sandbox\" capability to restrict AI agents from unrestricted access to both local and remote resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.12.json b/docs/api/controls/AAT-29.12.json index ab4ad270..3434350f 100644 --- a/docs/api/controls/AAT-29.12.json +++ b/docs/api/controls/AAT-29.12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and mitigate prompt injection / input attacks that seek to manipulate AI agent instructions, bypass security, compliance and/or resilience controls or result in unauthorized actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,9 +96,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/AAT-29.13.json b/docs/api/controls/AAT-29.13.json index 07bfe00a..98c8fafe 100644 --- a/docs/api/controls/AAT-29.13.json +++ b/docs/api/controls/AAT-29.13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to allow authorized users or operators to immediately halt or disable AI agent activity in case of unexpected behavior or harm.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.14.json b/docs/api/controls/AAT-29.14.json index 3305e996..8a0037bf 100644 --- a/docs/api/controls/AAT-29.14.json +++ b/docs/api/controls/AAT-29.14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to regularly conduct adversarial testing that simulates attacks against AI agents to identify and mitigate vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.15.json b/docs/api/controls/AAT-29.15.json index 480280cc..132d4cb2 100644 --- a/docs/api/controls/AAT-29.15.json +++ b/docs/api/controls/AAT-29.15.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to control, restrict and log AI agent self-modification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.16.json b/docs/api/controls/AAT-29.16.json index 2bd2b8ea..64d072af 100644 --- a/docs/api/controls/AAT-29.16.json +++ b/docs/api/controls/AAT-29.16.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict purging of any persistent memory or long-term data used by AI agents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.17.json b/docs/api/controls/AAT-29.17.json index 237e3be0..c77b051c 100644 --- a/docs/api/controls/AAT-29.17.json +++ b/docs/api/controls/AAT-29.17.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict agentic delegation, chaining and multi-agent communication to prevent unauthorized task escalation or emergent risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.18.json b/docs/api/controls/AAT-29.18.json index 890f1bb1..f5a48c47 100644 --- a/docs/api/controls/AAT-29.18.json +++ b/docs/api/controls/AAT-29.18.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to continuously monitor for behavioral drift or deviation from established AI agent baselines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.19.json b/docs/api/controls/AAT-29.19.json index c8d20b6d..7ed590ff 100644 --- a/docs/api/controls/AAT-29.19.json +++ b/docs/api/controls/AAT-29.19.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure that all AI agent-initiated actions are properly mapped to authenticated user or system identities, with enforced authorization checks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.2.json b/docs/api/controls/AAT-29.2.json index fbb9c489..9a85e227 100644 --- a/docs/api/controls/AAT-29.2.json +++ b/docs/api/controls/AAT-29.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement limitations for AI agents according to:\n(1) Least privileges, where the AI agent operates with the minimal permissions necessary to perform designated tasks; and\n(2) Least functionality, where the AI agent is restricted to communicate with the minimal Technology Assets, Applications and/or Services (TAAS) and networks necessary to perform designated tasks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,8 +96,13 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", - "crosswalks": {} + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2092" + ] + } } \ No newline at end of file diff --git a/docs/api/controls/AAT-29.20.json b/docs/api/controls/AAT-29.20.json index 5c799ab6..ad339e2c 100644 --- a/docs/api/controls/AAT-29.20.json +++ b/docs/api/controls/AAT-29.20.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to provide comprehensive audit trails of AI agent actions including:\n(1) Rationales; and \n(2) User/trigger mappings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.21.json b/docs/api/controls/AAT-29.21.json index 7449f893..7d65a3fa 100644 --- a/docs/api/controls/AAT-29.21.json +++ b/docs/api/controls/AAT-29.21.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to:\n(1) Provide human-understandable explanations for significant AI agent actions or decisions; and \n(2) Enable users to contest outcomes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.22.json b/docs/api/controls/AAT-29.22.json index da386a07..d23d821a 100644 --- a/docs/api/controls/AAT-29.22.json +++ b/docs/api/controls/AAT-29.22.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect unfair, unethical or biased AI agent actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.23.json b/docs/api/controls/AAT-29.23.json index 92b521c2..1cd143c2 100644 --- a/docs/api/controls/AAT-29.23.json +++ b/docs/api/controls/AAT-29.23.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate AI agent-generated outputs through the use of:\n(1) Content scanning; and\n(2) Output vetting through human approvals, where appropriate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.24.json b/docs/api/controls/AAT-29.24.json new file mode 100644 index 00000000..33624cb1 --- /dev/null +++ b/docs/api/controls/AAT-29.24.json @@ -0,0 +1,74 @@ +{ + "control_id": "AAT-29.24", + "title": "Resource Limiting", + "family": "AAT", + "description": "Automated mechanisms exist to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget).", + "scf_question": "Does the organization use automated mechanisms to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget)?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget).", + "4": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Cloud provider resource quotas and budget alerts\n∙ API rate limiting for AI tool usage\n∙ Basic AI tool usage monitoring", + "small": "∙ Cloud provider resource quotas and API rate limiting\n∙ Cost alerting for AI workload spend", + "medium": "∙ Resource quotas and limits in AI deployment platforms\n∙ Cloud cost management tools (e.g., AWS Cost Explorer, Azure Cost Management)\n∙ API rate limiting and throttling", + "large": "∙ Enterprise resource governance for AI workloads\n∙ Cloud FinOps practices\n∙ Automated resource limit enforcement\n∙ AI workload monitoring and alerting", + "enterprise": "∙ Enterprise AI resource governance platform\n∙ Automated resource limit enforcement with alerting\n∙ AI workload orchestration (e.g., Kubernetes resource limits)\n∙ FinOps program for AI infrastructure costs" + }, + "risks": [ + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-GV-1" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2090 & 2091", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2090", + "ISM-2091" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/AAT-29.3.json b/docs/api/controls/AAT-29.3.json index b91f1764..b2e93cc3 100644 --- a/docs/api/controls/AAT-29.3.json +++ b/docs/api/controls/AAT-29.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to authenticate, authorize, validate and monitor all tool and Application Programming Interface (API) invocations by AI agents, including;\n(1) Schema validation;\n(2) Rate limiting;\n(3) Access controls; and\n(4) Output validation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.4.json b/docs/api/controls/AAT-29.4.json index 020b8f4c..af6287ae 100644 --- a/docs/api/controls/AAT-29.4.json +++ b/docs/api/controls/AAT-29.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate, secure and restrict AI agent orchestration protocols to prevent:\n(1) Unauthorized tool chaining;\n(2) Context manipulation; and/or\n(3) Protocol-based escalation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.5.json b/docs/api/controls/AAT-29.5.json index d6dc0d6c..a252945d 100644 --- a/docs/api/controls/AAT-29.5.json +++ b/docs/api/controls/AAT-29.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate, sanitize and monitor all data inputs and retrieval pipelines for AI agents to:\n(1) Ensure data provenance; and \n(2) Prevent unauthorized access risks (e.g., injection, manipulation or exfiltration).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.6.json b/docs/api/controls/AAT-29.6.json index 8074dfe5..590aeb43 100644 --- a/docs/api/controls/AAT-29.6.json +++ b/docs/api/controls/AAT-29.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent privilege escalation or unauthorized delegation by AI agents by:\n(1) Monitoring and enforcing dynamic roles; and\n(2) Establishing cross-agent delegation boundaries and privileged actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.7.json b/docs/api/controls/AAT-29.7.json index 6144057f..350a1695 100644 --- a/docs/api/controls/AAT-29.7.json +++ b/docs/api/controls/AAT-29.7.json @@ -2,8 +2,8 @@ "control_id": "AAT-29.7", "title": "AI Agent Data Access Restrictions", "family": "AAT", - "description": "Mechanisms exist to restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", - "scf_question": "Does the organization restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data?", + "description": "Mechanisms exist to restrict agent access to sensitive and/or regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", + "scf_question": "Does the organization restrict agent access to sensitive and/or regulated data so that AI agents cannot ingest, generate or act on unauthorized data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.8.json b/docs/api/controls/AAT-29.8.json index b30ef41f..51dcbf4b 100644 --- a/docs/api/controls/AAT-29.8.json +++ b/docs/api/controls/AAT-29.8.json @@ -2,8 +2,8 @@ "control_id": "AAT-29.8", "title": "Data Extraction", "family": "AAT", - "description": "Mechanisms exist to prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point.", - "scf_question": "Does the organization prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point?", + "description": "Mechanisms exist to prevent AI agents from extracting sensitive and/or regulated data from volatile memory that can be exploited at a later point.", + "scf_question": "Does the organization prevent AI agents from extracting sensitive and/or regulated data from volatile memory that can be exploited at a later point?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.9.json b/docs/api/controls/AAT-29.9.json index 086f9805..ff8dbb68 100644 --- a/docs/api/controls/AAT-29.9.json +++ b/docs/api/controls/AAT-29.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure user identification and authentication methods are capable of preventing AI agents from \n(1) Spoofing;\n(2) Mimicry; and/or\n(3) Impersonation attacks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-29.json b/docs/api/controls/AAT-29.json index f6d5dc50..a310baf9 100644 --- a/docs/api/controls/AAT-29.json +++ b/docs/api/controls/AAT-29.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agents are designed, developed and deployed to securely operate under human oversight.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-30.1.json b/docs/api/controls/AAT-30.1.json index f3a7c3e0..86ce40eb 100644 --- a/docs/api/controls/AAT-30.1.json +++ b/docs/api/controls/AAT-30.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to generate event logs for AAT actions to ensure transparency and auditability.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-30.2.json b/docs/api/controls/AAT-30.2.json index 952d180d..96176adf 100644 --- a/docs/api/controls/AAT-30.2.json +++ b/docs/api/controls/AAT-30.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to control AI agent sessions by:\n(1) Embedding session IDs into the requests to the AI model;\n(2) Implementing capabilities to correlate sessions; and\n(3) Terminating sessions after a defined time period.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,8 +96,13 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", - "crosswalks": {} + "crosswalks": { + "emea-sau-otcc-1-2022": [ + "2-2-1-4" + ] + } } \ No newline at end of file diff --git a/docs/api/controls/AAT-30.json b/docs/api/controls/AAT-30.json index 54174f99..f40dcf72 100644 --- a/docs/api/controls/AAT-30.json +++ b/docs/api/controls/AAT-30.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-31.json b/docs/api/controls/AAT-31.json index 709592ed..b86452e6 100644 --- a/docs/api/controls/AAT-31.json +++ b/docs/api/controls/AAT-31.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent cognitive overload or decision fatigue for humans-in-the-loop (HITL) through risk-based prioritization.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} diff --git a/docs/api/controls/AAT-32.1.json b/docs/api/controls/AAT-32.1.json index 6f6410b4..c852fc72 100644 --- a/docs/api/controls/AAT-32.1.json +++ b/docs/api/controls/AAT-32.1.json @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-32.json b/docs/api/controls/AAT-32.json index dc7737f4..7bee88e4 100644 --- a/docs/api/controls/AAT-32.json +++ b/docs/api/controls/AAT-32.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement Robotic Process Automation (RPA) to improve efficiency, accuracy and speed for high-volume, repetitive and rules-based business processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { diff --git a/docs/api/controls/AAT-33.json b/docs/api/controls/AAT-33.json new file mode 100644 index 00000000..2bc068cb --- /dev/null +++ b/docs/api/controls/AAT-33.json @@ -0,0 +1,103 @@ +{ + "control_id": "AAT-33", + "title": "Release Owner Gate (ROG) For AI-Augmented Content", + "family": "AAT", + "description": "Mechanisms exist to implement a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization.", + "scf_question": "Does the organization implement a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to govern a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Manual review and approval process before publishing AI-generated content\n∙ Designated content reviewer for AI-assisted materials", + "small": "∙ Documented AI content review workflow\n∙ SME review checklist for AI-augmented content\n∙ Management sign-off before external release", + "medium": "∙ Formal content release workflow with ROG checkpoint\n∙ SME review requirements for AI-augmented content\n∙ CMS approval workflow for externally published content", + "large": "∙ Enterprise ROG program with defined approval authorities\n∙ Automated flagging of AI-augmented content for review\n∙ Cross-functional review panel for sensitive AI content", + "enterprise": "∙ Enterprise AI content governance program\n∙ Automated AI content detection and flagging\n∙ Multi-stage ROG approval workflows in enterprise CMS\n∙ Board-level visibility into high-risk AI content releases" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/AST-01.1.json b/docs/api/controls/AST-01.1.json index 4bc105d8..7fde9aa1 100644 --- a/docs/api/controls/AST-01.1.json +++ b/docs/api/controls/AST-01.1.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ Data / process owners maintain limited network diagrams to document the flow of sensitive/regulated data that is specific to their initiative.\n▪ Inventory of physical technology assets are assigned to individual users or teams and covers common devices (e.g., laptops, workstations and servers).\n▪ No structured process exists to review or share the results of the inventories.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to i identify and assess the security of Technology Assets, Applications and/or Services (TAAS) that support more than one critical business function.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to i identify and assess the security of Technology Assets, Applications and/or Services (TAAS) that support more than one critical business function. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,9 +83,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -123,6 +123,9 @@ "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -149,10 +152,10 @@ "THIRD-PARTIES-1a" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-nerc-cip-2024": [ "CIP-011-3 1.2" @@ -161,19 +164,27 @@ "III.B.1.a" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "emea-eu-dora-2023": [ "Article 8.5" ], "emea-deu-bsrit-2017": [ - "12.2" + "3.3" + ], + "emea-sau-cscc-1-2019": [ + "3-1-1-2" ], "emea-sau-cgiot-2024": [ "4-1-4" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "op.cont.3" + ], "emea-gbr-caf-4-0": [ "A3", "A3.a (point 2)" @@ -181,14 +192,29 @@ "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ps-cps-234-2019": [ - "21(a)" + "apac-aus-ps-cps-230-2023": [ + "34(a)" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.3" + ], + "apac-sgp-mas-trm-2021": [ + "3.3.1(a)", + "8.1.2" + ], + "americas-arg-ppd-2018": [ + "B.1.1" ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.2", "2.9.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2", + "2.9.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.03" ] diff --git a/docs/api/controls/AST-01.2.json b/docs/api/controls/AST-01.2.json index a13fd3e7..36a526db 100644 --- a/docs/api/controls/AST-01.2.json +++ b/docs/api/controls/AST-01.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Inventories may be manual (e.g., spreadsheets) or automated.\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to identify and involve pertinent stakeholders of critical TAASD to support the ongoing secure management of those assets.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -155,12 +156,28 @@ "III.A" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.2(16)", - "3.5(54)" + "3.5.54" + ], + "emea-deu-c5-2020": [ + "AM-02" + ], + "emea-qat-pdppl-2020": [ + "3.11.2" + ], + "emea-sau-cscc-1-2019": [ + "2-1-1-2" ], "emea-sau-otcc-1-2022": [ "2-1-1-4" ], + "emea-esp-decree-311-2022": [ + "Article 11(1)", + "Article 11(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], "emea-gbr-caf-4-0": [ "A3.a (point 4)" ], diff --git a/docs/api/controls/AST-01.3.json b/docs/api/controls/AST-01.3.json index 310c244f..9eb179e8 100644 --- a/docs/api/controls/AST-01.3.json +++ b/docs/api/controls/AST-01.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement a scalable, standardized naming convention for TAASD that avoids asset naming conflicts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-01.4.json b/docs/api/controls/AST-01.4.json index ec4a636e..495bb4fd 100644 --- a/docs/api/controls/AST-01.4.json +++ b/docs/api/controls/AST-01.4.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ Inventory of physical technology assets are assigned to individual users or teams and covers common devices (e.g., laptops, workstations and servers).\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ No structured process exists to review or share the results of the inventories.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain a current list of approved technologies (hardware and software).", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain a current list of approved technologies (hardware and software). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,13 +89,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { + "general-nist-800-171-r3": [ + "03.04.08.c" + ], "general-nist-800-171a-r3": [ "A.03.04.08.c" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(1)" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP2-2" + ], "emea-gbr-def-stan-05-138-2024": [ "2410" ], @@ -108,8 +118,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2410" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS12" + "apac-sgp-mas-trm-2021": [ + "3.3.1(a)", + "6.5.1" + ], + "americas-can-itsp-10-171-2025": [ + "03.04.08.C" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-01.5.json b/docs/api/controls/AST-01.5.json index 1a20196c..38825fce 100644 --- a/docs/api/controls/AST-01.5.json +++ b/docs/api/controls/AST-01.5.json @@ -49,9 +49,13 @@ "MT-5", "MT-8", "MT-9", - "MT-10" + "MT-10", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Asset Management", - "crosswalks": {} + "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ] + } } \ No newline at end of file diff --git a/docs/api/controls/AST-01.json b/docs/api/controls/AST-01.json index 02225b74..059990ee 100644 --- a/docs/api/controls/AST-01.json +++ b/docs/api/controls/AST-01.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to facilitate an IT Asset Management (ITAM) program to implement and manage asset management controls.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -93,7 +93,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -108,8 +109,8 @@ "CC6.1-POF9" ], "general-cis-csc-8-1": [ - "1.0", - "2.0", + "1", + "2", "2.1", "2.2" ], @@ -212,6 +213,13 @@ "03.04.11.a", "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.18.a[01]", + "A.03.04.11.a[02]", + "A.03.07.04.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 1", "NIST Tenet 5" @@ -314,15 +322,18 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PM-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "usa-federal-irs-1075-2021": [ "2.B.7.1", @@ -348,8 +359,8 @@ "PM-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(53)", - "3.5(54)" + "3.5.53", + "3.5.54" ], "emea-eu-nis2-2022": [ "Article 21.2(i)" @@ -362,51 +373,29 @@ "12.2.3", "12.3.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "12.2" - ], "emea-deu-c5-2020": [ "AM-03" ], "emea-sau-cscc-1-2019": [ - "2-1", - "2-5" - ], - "emea-sau-ecc-1-2018": [ - "2-1-1", - "2-1-2", - "2-6-1", - "2-6-2", - "2-6-4" + "1-3-1" ], "emea-sau-otcc-1-2022": [ - "2-1" + "2-1-1", + "2-1-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.3" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" + "3.3.3", + "3.3.3.1", + "3.3.3.3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" - ], - "emea-esp-decree-311-2022": [ - "18" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-gbr-caf-4-0": [ "A3" ], - "emea-gbr-cap-1850-2020": [ - "A3" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2" ], "emea-gbr-def-stan-05-138-2024": [ "1300", @@ -426,7 +415,7 @@ "1301", "2202" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0285", "ISM-0286", "ISM-0289", @@ -435,10 +424,6 @@ "ISM-1457", "ISM-1480" ], - "apac-aus-ps-cps-234-2019": [ - "21", - "21(c)" - ], "apac-ind-sebi-2024": [ "GV.PO.S5" ], @@ -448,34 +433,29 @@ "8.1.1.1", "8.1.1.6.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP05", "HHSP54", "HML05", "HML54" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS12", - "HMS14" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP05", "HSUP46" ], "apac-nzl-ism-3-9": [ - "8.4.9.C.01" + "8.4.9.C.01", + "20.2.15.C.04", + "20.2.15.C.07" ], "apac-sgp-mas-trm-2021": [ - "3.3.1", - "3.3.1(a)", - "3.3.1(d)", - "7.1.1", - "11.4.1", - "11.4.2", - "11.4.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.9" + "3.3.1" + ], + "americas-arg-ppd-2018": [ + "B.1.3-3" ], "americas-can-osfi-b13-2022": [ "2.2", diff --git a/docs/api/controls/AST-02.1.json b/docs/api/controls/AST-02.1.json index a3a30ab5..90699679 100644 --- a/docs/api/controls/AST-02.1.json +++ b/docs/api/controls/AST-02.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to update asset inventories as part of component installations, removals and asset upgrades.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to update asset inventories as part of component installations, removals and asset upgrades. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -57,7 +57,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -112,6 +113,8 @@ "3.4.1[f]" ], "general-nist-800-171a-r3": [ + "A.03.04.10.a", + "A.03.04.10.b[02]", "A.03.04.10.c[01]", "A.03.04.10.c[02]", "A.03.04.10.c[03]" @@ -132,10 +135,10 @@ "CM-08(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "CM-8(CE-1)" @@ -153,14 +156,13 @@ "12.4.3" ], "emea-deu-c5-2020": [ - "AM-01", - "AM-02" + "AM-01" ], "emea-sau-cgiot-2024": [ "2-1-2" ], - "emea-sau-otcc-1-2022": [ - "2-1-1-1" + "americas-arg-ppd-2018": [ + "B.1.3-1" ], "americas-can-itsp-10-171-2025": [ "03.04.10.A", diff --git a/docs/api/controls/AST-02.10.json b/docs/api/controls/AST-02.10.json index c0c0c3d4..ae5e8d1a 100644 --- a/docs/api/controls/AST-02.10.json +++ b/docs/api/controls/AST-02.10.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to track the geographic location of system components.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -49,7 +49,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-02.11.json b/docs/api/controls/AST-02.11.json index 06a024c2..a210114d 100644 --- a/docs/api/controls/AST-02.11.json +++ b/docs/api/controls/AST-02.11.json @@ -50,7 +50,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-02.2.json b/docs/api/controls/AST-02.2.json index 4b3902e9..ec3d2609 100644 --- a/docs/api/controls/AST-02.2.json +++ b/docs/api/controls/AST-02.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to automatically detect and alert upon the detection of unauthorized hardware, software and firmware components.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -55,7 +55,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -125,6 +126,13 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.a", + "A.03.04.02E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 6" @@ -144,6 +152,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-08(03)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ], "usa-federal-irs-1075-2021": [ "CM-8(CE-3)", "CM-8(CE-3).a", @@ -160,12 +171,6 @@ "CM-8(3)-IS.1", "CM-8(3)-IS.2" ], - "emea-deu-c5-2020": [ - "AM-02" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], "emea-gbr-def-stan-05-138-2024": [ "3204" ], @@ -178,7 +183,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3204" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1807" ] } diff --git a/docs/api/controls/AST-02.3.json b/docs/api/controls/AST-02.3.json index 6fca14e7..1ba71260 100644 --- a/docs/api/controls/AST-02.3.json +++ b/docs/api/controls/AST-02.3.json @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-02.4.json b/docs/api/controls/AST-02.4.json index 51d011eb..3490aef4 100644 --- a/docs/api/controls/AST-02.4.json +++ b/docs/api/controls/AST-02.4.json @@ -20,9 +20,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to document and govern instances of approved deviations from established baseline configurations.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to document and govern instances of approved deviations from established baseline configurations. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -106,11 +107,9 @@ "03.04.02.b", "03.04.06.a" ], - "emea-deu-c5-2020": [ - "SP-03" - ], - "emea-isr-cmo-1-0": [ - "6.8" + "general-nist-800-171a-r3": [ + "A.03.04.02.a[02]", + "A.03.04.06.a" ], "emea-gbr-def-stan-05-138-2024": [ "2202" @@ -121,6 +120,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2202" ], + "apac-sgp-mas-trm-2021": [ + "3.2.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", "03.04.06.A" diff --git a/docs/api/controls/AST-02.5.json b/docs/api/controls/AST-02.5.json index f30f8373..05506ded 100644 --- a/docs/api/controls/AST-02.5.json +++ b/docs/api/controls/AST-02.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to automatically employ Network Access Control (NAC), or a similar technology, which is capable of detecting unauthorized devices and disable network access to those unauthorized devices.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -31,7 +31,7 @@ "small": "∙ VLAN segmentation to isolate unknown devices\n∙ MAC address filtering (basic NAC)\n∙ Wireless access point policies", "medium": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Open-source NAC (e.g., PacketFence)", "large": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ 802.1X certificate-based authentication", - "enterprise": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Zero Trust Network Access (ZTNA) integration\n∙ 802.1X with EAP-TLS and certificate infrastructure" + "enterprise": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Zero Trust Network Architecture (ZTNA) integration\n∙ 802.1X with EAP-TLS and certificate infrastructure" }, "risks": [ "R-AC-1", @@ -83,7 +83,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -110,9 +111,6 @@ "general-nist-800-161-r1-level-3": [ "SC-7(19)" ], - "general-nist-800-172": [ - "3.5.3e" - ], "general-nist-800-207": [ "NIST Tenet 6" ], @@ -125,19 +123,14 @@ "usa-federal-dow-cmmc-2-level-3": [ "IA.L3-3.5.3E" ], - "emea-isr-cmo-1-0": [ - "23.6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0520", "ISM-1182" ], "apac-sgp-mas-trm-2021": [ - "11.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "4.21", - "4.24" + "11.2.4", + "11.2.5", + "11.5.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-02.6.json b/docs/api/controls/AST-02.6.json index a2055f8b..2b38afa7 100644 --- a/docs/api/controls/AST-02.6.json +++ b/docs/api/controls/AST-02.6.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to enable Dynamic Host Configuration Protocol (DHCP) server logging to improve asset inventories and assist in detecting unknown systems.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to enable Dynamic Host Configuration Protocol (DHCP) server logging to improve asset inventories and assist in detecting unknown systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-02.7.json b/docs/api/controls/AST-02.7.json index 4d4aa000..f33f2807 100644 --- a/docs/api/controls/AST-02.7.json +++ b/docs/api/controls/AST-02.7.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors are primarily administrative and preventative in nature.", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to protect Intellectual Property (IP) rights with software licensing restrictions.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to protect Intellectual Property (IP) rights with software licensing restrictions.\n", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -133,11 +134,8 @@ "usa-federal-irs-1075-2021": [ "SC-18(CE-2)" ], - "emea-isr-cmo-1-0": [ - "3.1" - ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "3-BP1" ], "apac-jpn-ismap": [ "14.2.7.1", @@ -154,9 +152,6 @@ "18.1.2.10", "18.1.2.11", "18.1.2.12" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS14" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-02.8.json b/docs/api/controls/AST-02.8.json index 17c44e27..aaa55215 100644 --- a/docs/api/controls/AST-02.8.json +++ b/docs/api/controls/AST-02.8.json @@ -2,8 +2,8 @@ "control_id": "AST-02.8", "title": "Data Action Mapping", "family": "AST", - "description": "Mechanisms exist to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed.", - "scf_question": "Does the organization create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed?", + "description": "Mechanisms exist to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive and/or regulated data is stored, transmitted or processed.", + "scf_question": "Does the organization create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive and/or regulated data is stored, transmitted or processed?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT and/or cybersecurity personnel work with process owners to generate and maintain Data Flow Diagrams (DFDs) and network diagrams to document the flow of data to create and maintain a map of systems where sensitive/regulated data is stored, transmitted or processed.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -129,16 +130,16 @@ "A.03.04.11.b[01]", "A.03.04.11.b[02]" ], - "general-nist-800-172": [ - "3.1.3e" + "general-nist-800-172-r3": [ + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.14E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 1", "NIST Tenet 7" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DA.DAUTE" ], @@ -156,8 +157,9 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(4)(A)" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-16" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "apac-ind-sebi-2024": [ "ID.AM.S2" diff --git a/docs/api/controls/AST-02.9.json b/docs/api/controls/AST-02.9.json index 22771e94..dbdcc355 100644 --- a/docs/api/controls/AST-02.9.json +++ b/docs/api/controls/AST-02.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and manage a Configuration Management Database (CMDB), or similar technology, to monitor and govern technology asset-specific information.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -160,12 +161,28 @@ "general-nist-800-171-r3": [ "03.04.08.a", "03.04.10.a", - "03.04.10.b", - "03.04.10.c" - ], - "general-nist-800-172": [ - "3.4.1e", - "3.4.3e" + "03.04.10.b" + ], + "general-nist-800-171a-r3": [ + "A.03.04.08.a", + "A.03.04.10.a", + "A.03.04.10.b[02]" + ], + "general-nist-800-172-r3": [ + "03.04.03E", + "03.04.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.03E[01]", + "A.03.04.03E.ODP[01]", + "DS-A.03.04.03E[02]", + "A.03.04.03E.ODP[02]", + "DS-A.03.04.03E[03]", + "A.03.04.03E.ODP[03]", + "DS-A.03.04.04E[01]", + "DS-A.03.04.04E[02]", + "DS-A.03.04.04E[03]", + "DS-A.03.04.08E" ], "general-nist-800-207": [ "NIST Tenet 1", @@ -195,18 +212,36 @@ "CM-08(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.5.54" + ], + "emea-deu-c5-2020": [ + "AM-01", + "AM-01-DOAR", + "RB-12" ], "emea-sau-cgiot-2024": [ "2-1-2" ], "emea-sau-otcc-1-2022": [ - "2-1-1", - "2-1-1-2", - "2-1-1-3" + "2-1-1-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.3.3", + "3.3.3.3.a", + "3.3.3.3.b", + "3.3.3.3.c", + "3.3.3.3.d", + "3.3.3.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-def-stan-05-138-2024": [ "1301", @@ -223,17 +258,26 @@ "1301", "2423" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1493" ], + "apac-mys-bnm-rmit-2025": [ + "11.3" + ], + "apac-nzl-ism-3-9": [ + "20.2.15.C.07" + ], "americas-can-osfi-b13-2022": [ "2.2.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2", + "2.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.10.A", - "03.04.10.B", - "03.04.10.C" + "03.04.10.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-02.json b/docs/api/controls/AST-02.json index 8fa37253..649d4560 100644 --- a/docs/api/controls/AST-02.json +++ b/docs/api/controls/AST-02.json @@ -21,11 +21,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Inventories may be manual (e.g., spreadsheets) or automated.\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ No structured process exists to review or share the results of the inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to perform inventories of TAASD that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -99,7 +99,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -112,9 +113,9 @@ "CC6.1-POF1" ], "general-cis-csc-8-1": [ - "1.0", + "1", "1.1", - "2.0", + "2", "2.1", "2.2", "2.4", @@ -201,7 +202,7 @@ "general-iso-27018-2025": [ "5.9" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011.001", "T1020.001", "T1021.001", @@ -391,13 +392,13 @@ "3.4.1[f]" ], "general-nist-800-171a-r3": [ + "A.03.04.08.a", + "A.03.04.08.c", "A.03.04.10.ODP[01]", "A.03.04.10.a", "A.03.04.10.b[01]", - "A.03.04.10.b[02]" - ], - "general-nist-800-172": [ - "3.1.2e" + "A.03.04.10.b[02]", + "A.03.04.11.a[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -446,9 +447,6 @@ "9.5.1", "9.5.1.1" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG1.SP1" ], @@ -503,11 +501,14 @@ "CM-08", "PM-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(3)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "PM-5" @@ -553,8 +554,9 @@ "CM-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(53)", - "3.5(54)" + "3.3.2.16", + "3.5.53", + "3.5.54" ], "emea-eu-dora-2023": [ "Article 8.4", @@ -570,20 +572,16 @@ "12.4.2(a)", "12.4.2(b)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ - "8.2", - "12.2" + "3.3", + "8.2" ], "emea-deu-c5-2020": [ "AM-01", - "AM-02" + "RB-12" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 1" ], "emea-sau-cscc-1-2019": [ "2-1-1-1" @@ -592,12 +590,11 @@ "2-1-1" ], "emea-sau-otcc-1-2022": [ - "2-1", - "2-1-1", - "2-1-1-3" + "2-1-1-1" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.1 [OP.EXP.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "emea-uae-niaf-2023": [ "3.1.1" @@ -631,10 +628,11 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0336", "ISM-1643", - "ISM-1807" + "ISM-1807", + "ISM-1966" ], "apac-ind-sebi-2024": [ "ID.AM.S1", @@ -648,8 +646,8 @@ "8.1.1.4", "8.1.2.3" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS03" + "apac-mys-bnm-rmit-2025": [ + "11.3" ], "apac-nzl-ism-3-9": [ "8.4.8.C.01", @@ -657,19 +655,24 @@ ], "apac-sgp-mas-trm-2021": [ "3.3.1(a)", - "3.3.2" + "3.3.2", + "11.5.1" + ], + "americas-arg-ppd-2018": [ + "B.1.1", + "D.1.1-4" ], "americas-bmu-mba-coc-2020": [ "5.9" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" - ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.2", "2.2.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.08.C", diff --git a/docs/api/controls/AST-03.1.json b/docs/api/controls/AST-03.1.json index 748231f1..f0b722d6 100644 --- a/docs/api/controls/AST-03.1.json +++ b/docs/api/controls/AST-03.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to include capturing the name, position and/or role of individuals responsible/accountable for administering assets as part of the technology asset inventory process.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -141,12 +142,12 @@ "general-nist-800-171-r3": [ "03.09.02.a.03" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.03" + ], "general-nist-csf-2-0": [ "ID.AM" ], - "general-scf-dpmp-2025": [ - "5.3" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG1.SP3" ], @@ -154,10 +155,14 @@ "CM-08(04)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" diff --git a/docs/api/controls/AST-03.2.json b/docs/api/controls/AST-03.2.json index b5d39622..86612105 100644 --- a/docs/api/controls/AST-03.2.json +++ b/docs/api/controls/AST-03.2.json @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -120,7 +121,7 @@ "general-iso-42001-2023": [ "A.7.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -168,6 +169,15 @@ "general-nist-800-161-r1-level-3": [ "SR-4" ], + "general-nist-800-172-r3": [ + "03.17.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.04E[01]", + "A.03.17.04E.ODP[01]", + "DS-A.03.17.04E[02]", + "DS-A.03.17.04E[03]" + ], "general-sparta": [ "CM0026", "CM0049" @@ -175,10 +185,14 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "4.2" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1790", "ISM-1791", - "ISM-1792" + "ISM-1792", + "ISM-1816" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-03.json b/docs/api/controls/AST-03.json index 959036b4..6a6e351b 100644 --- a/docs/api/controls/AST-03.json +++ b/docs/api/controls/AST-03.json @@ -19,11 +19,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure asset ownership responsibilities are assigned, tracked and managed at a team, individual, or responsible organization level to establish a common understanding of requirements for asset protection.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -140,6 +141,9 @@ "general-nist-800-171-r3": [ "03.09.02.a.03" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.03" + ], "general-nist-csf-2-0": [ "ID.AM" ], @@ -184,9 +188,6 @@ "2.2.5", "6.5.2" ], - "general-scf-dpmp-2025": [ - "5.3" - ], "general-tisax-6-0-3": [ "1.3.1" ], @@ -206,10 +207,10 @@ "SA-04(12)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-4(CE-12)", @@ -218,20 +219,20 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.A" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-deu-c5-2020": [ + "AM-02" ], "emea-sau-cscc-1-2019": [ "2-1-1-2" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], "emea-gbr-caf-4-0": [ "A3.a (point 4)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1071" ], "apac-ind-sebi-2024": [ @@ -243,6 +244,14 @@ "8.1.2.1", "8.1.2.2" ], + "americas-arg-ppd-2018": [ + "B.1.2-1", + "B.1.2-2" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP1", + "5.9-BP2" + ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" ] diff --git a/docs/api/controls/AST-04.1.json b/docs/api/controls/AST-04.1.json index 0b4ff32e..612b3860 100644 --- a/docs/api/controls/AST-04.1.json +++ b/docs/api/controls/AST-04.1.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to determine security, compliance and resilience control applicability by identifying, assigning and documenting the appropriate asset scope categorization for all Technology Assets, Applications and/or Services (TAAS) and personnel (internal and third-parties).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,9 +80,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -171,8 +171,16 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.14.3e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.06.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.06.03E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -242,16 +250,31 @@ "SA-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)" + "3.3.3.17", + "3.3.3.18" ], "emea-eu-nis2-annex-2024": [ "11.7.2", "12.1.1", "12.1.3" ], - "emea-deu-bsrit-2017": [ - "12.4" + "emea-sau-ecc-1-2018": [ + "2-1-5" + ], + "emea-esp-decree-311-2022": [ + "Article 40(1)", + "Article 40(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.2" + ], + "apac-aus-ps-cps-230-2023": [ + "36", + "36(a)", + "36(b)", + "36(c)", + "36(d)", + "37" ], "apac-jpn-ismap": [ "4.4.4", diff --git a/docs/api/controls/AST-04.2.json b/docs/api/controls/AST-04.2.json index 6322c455..0d1edcf1 100644 --- a/docs/api/controls/AST-04.2.json +++ b/docs/api/controls/AST-04.2.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure control applicability is appropriately-determined for Technology Assets, Applications and/or Services (TAAS) and third parties by graphically representing applicable boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53,7 +53,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -66,6 +67,11 @@ "03.04.11.b", "03.15.02.a.04" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], "general-nist-csf-2-0": [ "ID.AM-03" ], @@ -93,9 +99,6 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.B.1.c" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-16" - ], "americas-can-itsp-10-171-2025": [ "03.04.11.A", "03.04.11.B", diff --git a/docs/api/controls/AST-04.3.json b/docs/api/controls/AST-04.3.json index 5c27397c..d2781456 100644 --- a/docs/api/controls/AST-04.3.json +++ b/docs/api/controls/AST-04.3.json @@ -52,13 +52,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-pci-dss-4-0-1": [ "6.3.2", "12.5.1", diff --git a/docs/api/controls/AST-04.json b/docs/api/controls/AST-04.json index 6bfd03a8..ab6ff91a 100644 --- a/docs/api/controls/AST-04.json +++ b/docs/api/controls/AST-04.json @@ -2,8 +2,8 @@ "control_id": "AST-04", "title": "Network Diagrams & Data Flow Diagrams (DFDs)", "family": "AST", - "description": "Mechanisms exist to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive/regulated data flows.", - "scf_question": "Does the organization maintain network architecture diagrams that: \n (1) Contain sufficient detail to assess the security of the network's architecture;\n (2) Reflect the current architecture of the network environment; and\n (3) Document all sensitive/regulated data flows?", + "description": "Mechanisms exist to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive and/or regulated data flows.", + "scf_question": "Does the organization maintain network architecture diagrams that: \n (1) Contain sufficient detail to assess the security of the network's architecture;\n (2) Reflect the current architecture of the network environment; and\n (3) Document all sensitive and/or regulated data flows?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT and/or cybersecurity personnel work with process owners to generate and maintain Data Flow Diagrams (DFDs) and network diagrams to document the flow of data to create and maintain a map of systems where sensitive/regulated data is stored, transmitted or processed.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive/regulated data flows.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -231,8 +232,17 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.1.3e" + "general-nist-800-171a-r3": [ + "A.03.01.03[02]", + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.14E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -259,9 +269,6 @@ "1.2.3", "1.2.4" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "general-sparta": [ "CM0022" ], @@ -303,6 +310,9 @@ "SA-04(01)", "SA-04(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(4)" + ], "usa-federal-irs-1075-2021": [ "PL-2", "SA-4(CE-1)", @@ -338,19 +348,21 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(a)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "COS-07" + "KOS-06" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 1" ], "emea-sau-otcc-1-2022": [ "2-4-1-16" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "op.mon.1", + "mp.com.1" + ], "emea-gbr-caf-4-0": [ "B3.a" ], @@ -369,26 +381,36 @@ "1203", "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0516", "ISM-0518", "ISM-1645", "ISM-1646" ], + "apac-aus-ps-cps-230-2023": [ + "34(a)" + ], "apac-ind-sebi-2024": [ "ID.AM.S2" ], "apac-jpn-ismap": [ "4.4.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.41" + ], "apac-nzl-ism-3-9": [ "18.1.9.C.02", "18.1.11.C.01", "18.1.12.C.01", "18.1.12.C.02" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" + "apac-sgp-mas-trm-2021": [ + "8.1.2" + ], + "americas-arg-ppd-2018": [ + "B.1.1", + "E.1.1-2" ], "americas-can-itsp-10-171-2025": [ "03.01.03", diff --git a/docs/api/controls/AST-05.1.json b/docs/api/controls/AST-05.1.json index cca97140..eb84cb03 100644 --- a/docs/api/controls/AST-05.1.json +++ b/docs/api/controls/AST-05.1.json @@ -2,8 +2,8 @@ "control_id": "AST-05.1", "title": "Management Approval For External Media Transfer", "family": "AST", - "description": "Mechanisms exist to obtain management approval for any sensitive/regulated media that is transferred outside of the organization's facilities.", - "scf_question": "Does the organization obtain management approval for any sensitive/regulated media that is transferred outside of its facilities?", + "description": "Mechanisms exist to obtain management approval for any sensitive and/or regulated media that is transferred outside of the organization's facilities.", + "scf_question": "Does the organization obtain management approval for any sensitive and/or regulated media that is transferred outside of its facilities?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-05.2.json b/docs/api/controls/AST-05.2.json new file mode 100644 index 00000000..8962d4cb --- /dev/null +++ b/docs/api/controls/AST-05.2.json @@ -0,0 +1,114 @@ +{ + "control_id": "AST-05.2", + "title": "Technology Assets, Applications, Services and/or Data (TAASD) Storage", + "family": "AST", + "description": "Mechanisms exist to ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "scf_question": "Does the organization ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", + "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Locked cabinet or secure room for equipment\n∙ Basic physical access controls (key or PIN)", + "small": "∙ Locked server room with physical access controls\n∙ Physical access log\n∙ Environmental controls (temperature, humidity)", + "medium": "∙ Dedicated server room with physical access controls and monitoring\n∙ Physical access logging\n∙ Co-location or private cage in certified data center", + "large": "∙ Secure data center facilities (access control, CCTV, environmental monitoring)\n∙ Co-location or private cage in certified data center\n∙ Physical security assessments", + "enterprise": "∙ Co-location or private cage in certified data center\n∙ Multi-layer physical access controls (mantraps, biometrics)\n∙ 24/7 physical security monitoring\n∙ Redundant physical infrastructure" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - AU ISM ISM-1975", + "family_name": "Asset Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1974", + "ISM-1975" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/AST-05.json b/docs/api/controls/AST-05.json index 52f9e3ce..16045248 100644 --- a/docs/api/controls/AST-05.json +++ b/docs/api/controls/AST-05.json @@ -2,8 +2,8 @@ "control_id": "AST-05", "title": "Security of Assets & Media", "family": "AST", - "description": "Mechanisms exist to maintain strict control over the internal or external distribution of any kind of sensitive/regulated media.", - "scf_question": "Does the organization maintain strict control over the internal or external distribution of any kind of sensitive/regulated media?", + "description": "Mechanisms exist to maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity.", + "scf_question": "Does the organization maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT personnel collect technology assets and media for destruction when it is no longer needed for business or legal reasons.", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain strict control over the internal or external distribution of any kind of sensitive/regulated media.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,8 +104,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -129,6 +131,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-pci-dss-4-0-1": [ "9.4", "9.4.4" @@ -160,18 +165,19 @@ "emea-eu-nis2-annex-2024": [ "12.2.2(c)" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0161", "ISM-0293", - "ISM-1178" + "ISM-1178", + "ISM-1973" ], "apac-jpn-ismap": [ "8.3", "8.3.1" ], + "apac-nzl-ism-3-9": [ + "17.9.36.C.01" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.A" ] diff --git a/docs/api/controls/AST-06.1.json b/docs/api/controls/AST-06.1.json index 371983a5..b4e33a5d 100644 --- a/docs/api/controls/AST-06.1.json +++ b/docs/api/controls/AST-06.1.json @@ -81,12 +81,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", - "crosswalks": { - "emea-deu-c5-2020": [ - "AM-02" - ] - } + "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/AST-06.json b/docs/api/controls/AST-06.json index 31d34172..01091e6a 100644 --- a/docs/api/controls/AST-06.json +++ b/docs/api/controls/AST-06.json @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -145,10 +146,13 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.5.1" ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.2 [MP.EQ.2]" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0161" ], "apac-jpn-ismap": [ diff --git a/docs/api/controls/AST-07.json b/docs/api/controls/AST-07.json index 5d6b3c71..a214f36d 100644 --- a/docs/api/controls/AST-07.json +++ b/docs/api/controls/AST-07.json @@ -2,8 +2,8 @@ "control_id": "AST-07", "title": "Kiosks & Point of Interaction (PoI) Devices", "family": "AST", - "description": "Mechanisms exist to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution.", - "scf_question": "Does the organization appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution?", + "description": "Mechanisms exist to appropriately protect devices that capture sensitive and/or regulated data via direct physical interaction from tampering and substitution.", + "scf_question": "Does the organization appropriately protect devices that capture sensitive and/or regulated data via direct physical interaction from tampering and substitution?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99,7 +99,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -148,8 +149,9 @@ "9.5.1.1", "9.5.1.2" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.12" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-08.json b/docs/api/controls/AST-08.json index 17f36334..fa8743e0 100644 --- a/docs/api/controls/AST-08.json +++ b/docs/api/controls/AST-08.json @@ -99,7 +99,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -121,6 +122,14 @@ "general-iso-27018-2025": [ "7.9" ], + "general-nist-800-172-r3": [ + "03.17.02E", + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.02E.ODP[04]", + "A.03.17.05E.ODP[02]" + ], "general-pci-dss-4-0-1": [ "9.5.1.2", "9.5.1.2.1" diff --git a/docs/api/controls/AST-09.json b/docs/api/controls/AST-09.json index dc27f15b..4929d1b6 100644 --- a/docs/api/controls/AST-09.json +++ b/docs/api/controls/AST-09.json @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -197,6 +198,10 @@ "03.07.04.c", "03.08.03" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.c", + "A.03.08.03" + ], "general-pci-dss-4-0-1": [ "9.4.7" ], @@ -244,12 +249,12 @@ "314.4(c)(6)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.F.3.1" @@ -271,16 +276,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-12" ], - "emea-us-psd2-2015": [ - "24" - ], "emea-deu-c5-2020": [ - "AM-04", - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "15.4", - "17.21" + "AM-04" ], "emea-sau-cgiot-2024": [ "2-5-1", @@ -289,18 +286,16 @@ "emea-sau-ecc-1-2018": [ "2-14-3-4" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" - ], "emea-sau-sacs-002-2022": [ - "TPC-19", - "TPC-66" + "VII.A.TPC-19", + "VII.B.TPC-66" ], "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.5 [MP.SI.5]" + "3.3.2.3.e", + "3.3.11", + "3.3.11.1", + "3.3.11.4", + "3.3.11.5" ], "emea-gbr-def-stan-05-138-2024": [ "2323" @@ -314,7 +309,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0312", "ISM-0315", @@ -335,7 +330,6 @@ "ISM-1221", "ISM-1222", "ISM-1223", - "ISM-1225", "ISM-1534", "ISM-1550", "ISM-1641", @@ -364,7 +358,7 @@ "11.2.7.1", "11.2.7.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP06", "HHSP45", "HML06", @@ -375,8 +369,11 @@ ], "apac-nzl-ism-3-9": [ "11.2.13.C.01", - "11.2.13.C.02", "11.7.35.C.01", + "11.8.10.C.03", + "11.8.10.C.05", + "11.8.12.C.01", + "11.8.12.C.02", "12.6.4.C.01", "12.6.4.C.02", "12.6.5.C.01", @@ -387,8 +384,8 @@ "12.6.8.C.01", "12.6.9.C.01", "12.6.10.C.01", - "13.4.19.C.02", "13.4.10.C.01", + "13.4.19.C.02", "13.5.24.C.01", "13.5.24.C.02", "13.5.24.C.03", @@ -409,15 +406,23 @@ "13.6.10.C.02", "13.6.10.C.03", "13.6.11.C.01", - "13.6.12.C.01" + "13.6.12.C.01", + "17.6.6.C.01" ], "apac-sgp-mas-trm-2021": [ "11.1.7" ], + "americas-arg-ppd-2018": [ + "F", + "F.1.2-DS-2" + ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.C", "03.08.03" diff --git a/docs/api/controls/AST-10.json b/docs/api/controls/AST-10.json index 57250d3b..d789f019 100644 --- a/docs/api/controls/AST-10.json +++ b/docs/api/controls/AST-10.json @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -113,11 +114,10 @@ "A.03.09.02.a.03" ], "emea-deu-c5-2020": [ - "AM-04", - "AM-05" + "AM-04" ], - "emea-isr-cmo-1-0": [ - "11.12" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e.2" ], "apac-jpn-ismap": [ "8.1.4" diff --git a/docs/api/controls/AST-11.json b/docs/api/controls/AST-11.json index 51672ec3..7548ec7c 100644 --- a/docs/api/controls/AST-11.json +++ b/docs/api/controls/AST-11.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to authorize, control and track technology assets entering and exiting organizational facilities.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to authorize, control and track technology assets entering and exiting organizational facilities. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -106,10 +107,15 @@ "164.310(d)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-12.json b/docs/api/controls/AST-12.json index edcfed72..7524f3aa 100644 --- a/docs/api/controls/AST-12.json +++ b/docs/api/controls/AST-12.json @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -122,11 +123,15 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], - "emea-isr-cmo-1-0": [ - "12.6" + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4", + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A" diff --git a/docs/api/controls/AST-13.json b/docs/api/controls/AST-13.json index 2a01a401..337a84b0 100644 --- a/docs/api/controls/AST-13.json +++ b/docs/api/controls/AST-13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to reduce the risk associated with third-party assets that are attached to the network from harming organizational assets or exfiltrating organizational data.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -89,22 +89,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-nist-800-171-r3": [ "03.01.18.a" ], - "emea-isr-cmo-1-0": [ - "12.6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-84" - ], - "apac-nzl-ism-3-9": [ - "16.2.3.C.01", - "16.2.3.C.02" + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A" diff --git a/docs/api/controls/AST-14.1.json b/docs/api/controls/AST-14.1.json index 7a1e92da..94b837bd 100644 --- a/docs/api/controls/AST-14.1.json +++ b/docs/api/controls/AST-14.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to prevent the usage of Bluetooth and wireless devices (e.g., Near Field Communications (NFC)) in sensitive areas or unless used in a Radio Frequency (RF)-screened building.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -98,22 +99,13 @@ "usa-federal-fbi-cjis-6-0": [ "5.20.1.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0233", "ISM-1199", "ISM-1200" ], "apac-nzl-ism-3-9": [ - "11.1.8.C.01", - "11.1.10.C.01", - "11.1.10.C.02", - "11.1.10.C.03", - "11.1.11.C.01", - "11.1.11.C.02", - "11.1.12.C.01", - "11.1.13.C.01", - "21.1.16.C.01", - "21.1.16.C.02" + "11.1.19.C.03" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-14.2.json b/docs/api/controls/AST-14.2.json index 3e3b6d70..f11b18e7 100644 --- a/docs/api/controls/AST-14.2.json +++ b/docs/api/controls/AST-14.2.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -95,9 +96,9 @@ "O.9" ], "apac-nzl-ism-3-9": [ - "11.1.9.C.01", - "11.1.9.C.02", - "11.1.9.C.03" + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-14.json b/docs/api/controls/AST-14.json index ea321ffa..da113f2a 100644 --- a/docs/api/controls/AST-14.json +++ b/docs/api/controls/AST-14.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to monitor and enforce usage parameters that limit the potential damage caused from the unauthorized or unintentional alteration of system parameters.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to monitor and enforce usage parameters that limit the potential damage caused from the unauthorized or unintentional alteration of system parameters. \n", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -77,11 +77,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011", "T1078", "T1078.004", @@ -100,6 +101,9 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" + ], "general-swift-cscf-2025": [ "2.9" ], diff --git a/docs/api/controls/AST-15.1.json b/docs/api/controls/AST-15.1.json index 64c50de9..40ea8fef 100644 --- a/docs/api/controls/AST-15.1.json +++ b/docs/api/controls/AST-15.1.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Periodic physical inspections are performed to validate the integrity of unattended technology assets (e.g., kiosks, ATMs, point of sale devices, etc.).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to physically and logically inspect critical technology assets to detect evidence of tampering.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to physically and logically inspect critical technology assets to detect evidence of tampering. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -137,6 +138,12 @@ "general-nist-800-161-r1-level-3": [ "SR-10" ], + "general-nist-800-172-r3": [ + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.02E" + ], "general-pci-dss-4-0-1": [ "9.5.1", "9.5.1.2" diff --git a/docs/api/controls/AST-15.json b/docs/api/controls/AST-15.json index ac87319f..06d0fe93 100644 --- a/docs/api/controls/AST-15.json +++ b/docs/api/controls/AST-15.json @@ -22,7 +22,7 @@ "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Periodic physical inspections are performed to validate the integrity of unattended technology assets (e.g., kiosks, ATMs, point of sale devices, etc.).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to assess the integrity of critical Technology Assets, Applications and/or Services (TAAS) to detect evidence of tampering, where:\n(1)\tLogical assessments evaluate the integrity of critical components (e.g., configuration settings); and\n(2)\tPhysical assessments evaluate assets for evidence of unauthorized access and/or modifications.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -125,6 +126,12 @@ "general-nist-800-161-r1-level-3": [ "SR-9" ], + "general-nist-800-172-r3": [ + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.05E.ODP[02]" + ], "general-nist-csf-2-0": [ "ID.RA-09" ], diff --git a/docs/api/controls/AST-16.json b/docs/api/controls/AST-16.json index 9ece97a3..0c87cb49 100644 --- a/docs/api/controls/AST-16.json +++ b/docs/api/controls/AST-16.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ The use of personal devices (e.g., Bring Your Own Device (BYOD), as part of acceptable and unacceptable behaviors are primarily administrative and preventative in nature.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and govern a Bring Your Own Device (BYOD) program to reduce risk associated with personally-owned devices in the workplace.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -104,19 +105,23 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.4", "2.4.2" ], - "emea-sau-cscc-1-2019": [ - "2-5" - ], "emea-sau-ecc-1-2018": [ - "2-6-1", - "2-6-2" + "2-6-1" ], "emea-sau-sama-csf-1-2017": [ - "3.3.10" + "3.3.10.4", + "3.3.10.4.a", + "3.3.10.4.b", + "3.3.10.4.c", + "3.3.10.4.d", + "3.3.10.4.e" ], "emea-gbr-def-stan-05-138-2024": [ "2322" @@ -130,68 +135,67 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1297" ], "apac-nzl-ism-3-9": [ "8.1.12.C.01", "21.1.12.C.01", - "21.4.7.C.01", - "21.4.7.C.02", - "21.4.8.C.01", - "21.4.8.C.02", - "21.4.9.C.01", - "21.4.10.C.01", - "21.4.10.C.02", - "21.4.10.C.03", - "21.4.10.C.04", - "21.4.10.C.05", - "21.4.10.C.06", - "21.4.10.C.07", - "21.4.10.C.08", - "21.4.10.C.09", - "21.4.10.C.10", - "21.4.10.C.11", - "21.4.10.C.12", - "21.4.10.C.13", - "21.4.10.C.14", - "21.4.10.C.15", - "21.4.10.C.16", - "21.4.11.C.01", - "21.4.11.C.02", - "21.4.11.C.03", - "21.4.11.C.04", - "21.4.11.C.05", - "21.4.11.C.06", - "21.4.11.C.07", - "21.4.11.C.08", - "21.4.11.C.09", - "21.4.11.C.10", - "21.4.11.C.11", - "21.4.11.C.12", - "21.4.11.C.13", - "21.4.11.C.14", - "21.4.11.C.15", - "21.4.11.C.16", - "21.4.11.C.17", - "21.4.11.C.18", - "21.4.11.C.19", - "21.4.11.C.20", - "21.4.13.C.01", - "21.4.13.C.02", - "21.4.13.C.03", - "21.4.13.C.04", - "21.4.13.C.05", - "21.4.13.C.06", - "21.4.13.C.07", - "21.4.13.C.08", - "21.4.13.C.09", - "21.4.13.C.10", - "21.4.13.C.11", - "21.4.14.C.01", - "21.4.14.C.02", - "21.4.14.C.03", - "21.4.14.C.04" + "22.4.7.C.02", + "22.4.8.C.01", + "22.4.8.C.02", + "22.4.10.C.01", + "22.4.10.C.02", + "22.4.10.C.03", + "22.4.10.C.04", + "22.4.10.C.05", + "22.4.10.C.06", + "22.4.10.C.07", + "22.4.10.C.08", + "22.4.10.C.09", + "22.4.10.C.10", + "22.4.10.C.11", + "22.4.10.C.12", + "22.4.10.C.13", + "22.4.10.C.14", + "22.4.10.C.15", + "22.4.10.C.16", + "22.4.11.C.01", + "22.4.11.C.02", + "22.4.11.C.03", + "22.4.11.C.04", + "22.4.11.C.05", + "22.4.11.C.06", + "22.4.11.C.07", + "22.4.11.C.08", + "22.4.11.C.09", + "22.4.11.C.10", + "22.4.11.C.11", + "22.4.11.C.12", + "22.4.11.C.13", + "22.4.11.C.14", + "22.4.11.C.15", + "22.4.11.C.16", + "22.4.11.C.17", + "22.4.11.C.18", + "22.4.11.C.19", + "22.4.11.C.20", + "22.4.12.C.01", + "22.4.13.C.01", + "22.4.13.C.02", + "22.4.13.C.03", + "22.4.13.C.04", + "22.4.13.C.05", + "22.4.13.C.06", + "22.4.13.C.07", + "22.4.13.C.08", + "22.4.13.C.09", + "22.4.13.C.10", + "22.4.13.C.11", + "22.4.14.C.01", + "22.4.14.C.02", + "22.4.14.C.03", + "22.4.14.C.04" ], "apac-sgp-mas-trm-2021": [ "11.3.7" diff --git a/docs/api/controls/AST-17.json b/docs/api/controls/AST-17.json index 92125326..e6cc4395 100644 --- a/docs/api/controls/AST-17.json +++ b/docs/api/controls/AST-17.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to govern Supply Chain Risk Management (SCRM) sanctions that require the removal and prohibition of certain Technology Assets, Applications and/or Services (TAAS) that are designated as supply chain threats by a statutory or regulatory body.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -100,6 +101,10 @@ "03.11.01.a", "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.16.01" + ], "usa-federal-far-52-204-25": [ "52.204-25(b)(1)", "52.204-25(b)(2)" diff --git a/docs/api/controls/AST-18.json b/docs/api/controls/AST-18.json index f989c69b..a90b1b40 100644 --- a/docs/api/controls/AST-18.json +++ b/docs/api/controls/AST-18.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to provision and protect the confidentiality, integrity and authenticity of product supplier keys and data that can be used as a “roots of trust” basis for integrity verification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -100,9 +101,6 @@ "NDR 3.13(a)", "NDR 3.13(b)" ], - "general-nist-800-172": [ - "3.14.1e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -114,10 +112,6 @@ ], "emea-sau-cgiot-2024": [ "2-15-1" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 7" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-19.json b/docs/api/controls/AST-19.json index cca4c677..0e23dd44 100644 --- a/docs/api/controls/AST-19.json +++ b/docs/api/controls/AST-19.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for telecommunication equipment to prevent potential damage or unauthorized modification and to prevent potential eavesdropping.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,18 +80,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0558" ], "apac-nzl-ism-3-9": [ @@ -109,7 +103,10 @@ "11.3.12.C.03", "11.3.13.C.01", "11.3.13.C.02", - "11.3.13.C.03" + "11.3.13.C.03", + "11.8.3.C.01", + "11.8.4.C.01", + "11.8.5.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-20.json b/docs/api/controls/AST-20.json index 474b9132..011f58ad 100644 --- a/docs/api/controls/AST-20.json +++ b/docs/api/controls/AST-20.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement secure Video Teleconference (VTC) capabilities on endpoint devices and in designated conference rooms, to prevent potential eavesdropping.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,14 +80,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-shared-assessments-sig-2025": [ "M.1.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0548", "ISM-0551", "ISM-0553", @@ -96,9 +97,6 @@ "ISM-1014", "ISM-1562" ], - "apac-chn-pipl-2021": [ - "26" - ], "apac-nzl-ism-3-9": [ "18.3.14.C.01", "18.3.14.C.02" diff --git a/docs/api/controls/AST-21.json b/docs/api/controls/AST-21.json index a73b48a8..fcf8cf83 100644 --- a/docs/api/controls/AST-21.json +++ b/docs/api/controls/AST-21.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement secure Internet Protocol Telephony (IPT) that logically or physically separates Voice Over Internet Protocol (VoIP) traffic from data networks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -101,7 +102,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2412" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0549", "ISM-0551", "ISM-0555", diff --git a/docs/api/controls/AST-22.json b/docs/api/controls/AST-22.json index f85f5e19..fe252af2 100644 --- a/docs/api/controls/AST-22.json +++ b/docs/api/controls/AST-22.json @@ -2,8 +2,8 @@ "control_id": "AST-22", "title": "Microphones & Web Cameras", "family": "AST", - "description": "Mechanisms exist to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed.", - "scf_question": "Does the organization configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed?", + "description": "Mechanisms exist to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive and/or regulated information is discussed.", + "scf_question": "Does the organization configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive and/or regulated information is discussed?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,14 +80,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-shared-assessments-sig-2025": [ "N.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0559", "ISM-1450" ] diff --git a/docs/api/controls/AST-23.json b/docs/api/controls/AST-23.json index d8749425..c1c634e4 100644 --- a/docs/api/controls/AST-23.json +++ b/docs/api/controls/AST-23.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely configure Multi-Function Devices (MFD) according to industry-recognized secure practices for the type of device.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -94,35 +95,23 @@ "3.3.5.b-2", "3.3.5.c-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0245", "ISM-0589", "ISM-0590", - "ISM-1036" + "ISM-1036", + "ISM-1854", + "ISM-1855" ], "apac-nzl-ism-3-9": [ - "11.2.3.C.01", - "11.2.4.C.01", - "11.2.4.C.02", - "11.2.5.C.01", - "11.2.6.C.01", - "11.2.7.C.01", - "11.2.7.C.02", - "11.2.8.C.01", - "11.2.9.C.01", - "11.2.10.C.01", "11.2.11.C.01", "11.2.11.C.02", - "11.2.11.C.03", - "11.2.11.C.04", - "11.2.11.C.05", "11.2.12.C.01", - "11.2.12.C.02", "11.2.13.C.01", - "11.2.13.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.1" + "11.8.3.C.01", + "11.8.7.C.01", + "11.8.8.C.01", + "11.8.13.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-24.json b/docs/api/controls/AST-24.json index adacb0c9..d143a035 100644 --- a/docs/api/controls/AST-24.json +++ b/docs/api/controls/AST-24.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to issue personnel travelling overseas with temporary, loaner or \"travel-only\" end user technology (e.g., laptops and mobile devices) when travelling to authoritarian countries with a higher-than average risk for Intellectual Property (IP) theft or espionage against individuals and private companies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -99,9 +100,10 @@ "03.04.12.b" ], "general-nist-800-171a-r3": [ - "A.03.04.12.a" + "A.03.04.12.a", + "A.03.04.12.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1088", "ISM-1298", "ISM-1299", diff --git a/docs/api/controls/AST-25.json b/docs/api/controls/AST-25.json index 3b16097a..3a5df7b5 100644 --- a/docs/api/controls/AST-25.json +++ b/docs/api/controls/AST-25.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to re-image end user technology (e.g., laptops and mobile devices) when returning from overseas travel to an authoritarian country with a higher-than average risk for Intellectual Property (IP) theft or espionage against individuals and private companies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -104,7 +105,7 @@ "general-nist-800-171a-r3": [ "A.03.04.12.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1300", "ISM-1556" ], diff --git a/docs/api/controls/AST-26.json b/docs/api/controls/AST-26.json index 24fe3951..a60d33e3 100644 --- a/docs/api/controls/AST-26.json +++ b/docs/api/controls/AST-26.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to develop, implement and govern system administration processes, with corresponding Standardized Operating Procedures (SOP), for operating and maintaining Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,11 +92,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0042", "ISM-1380", "ISM-1385" diff --git a/docs/api/controls/AST-27.json b/docs/api/controls/AST-27.json index 528354e6..08ca75e9 100644 --- a/docs/api/controls/AST-27.json +++ b/docs/api/controls/AST-27.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to conduct remote system administrative functions via a \"jump box\" or \"jump server\" that is located in a separate network zone to user workstations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -114,6 +115,11 @@ "03.01.12.a", "03.01.12.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.a[01]", + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" + ], "general-swift-cscf-2025": [ "1.5", "2.6" @@ -124,14 +130,11 @@ "emea-sau-cscc-1-2019": [ "2-3-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" - ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1387" ], diff --git a/docs/api/controls/AST-28.1.json b/docs/api/controls/AST-28.1.json index e9148fc3..6880055e 100644 --- a/docs/api/controls/AST-28.1.json +++ b/docs/api/controls/AST-28.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Database administrators implement and maintain Database Management Systems (DBMSs), where applicable.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and maintain Database Management Systems (DBMSs), where applicable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -100,7 +101,7 @@ "usa-federal-dow-zt-roadmap-1-1": [ "4.4.6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1245", "ISM-1246", "ISM-1247", @@ -108,18 +109,6 @@ "ISM-1250", "ISM-1260", "ISM-1263" - ], - "apac-nzl-ism-3-9": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-28.json b/docs/api/controls/AST-28.json index ba6c5122..66689419 100644 --- a/docs/api/controls/AST-28.json +++ b/docs/api/controls/AST-28.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to develop, implement and govern database management processes, with corresponding Standardized Operating Procedures (SOP), for operating and maintaining databases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -102,7 +103,7 @@ "emea-sau-cscc-1-2019": [ "2-2-1-8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0393", "ISM-1243", "ISM-1255", @@ -127,17 +128,7 @@ "5.5.3.C.01", "5.5.4.C.01", "5.5.5.C.01", - "5.5.6.C.01", - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" + "5.5.6.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-29.1.json b/docs/api/controls/AST-29.1.json index 7e204fa1..ea3d223f 100644 --- a/docs/api/controls/AST-29.1.json +++ b/docs/api/controls/AST-29.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely configure contactless access control systems incorporating contactless RFID or smart cards to protect the confidentiality and integrity of data and prevent the compromise of secure spaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-29.json b/docs/api/controls/AST-29.json index bff4c4d9..949911f3 100644 --- a/docs/api/controls/AST-29.json +++ b/docs/api/controls/AST-29.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Enhanced security requirements for Bluetooth and wireless devices in sensitive/regulated areas are primarily administrative and preventative in nature.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely govern Radio Frequency Identification (RFID) deployments to ensure RFID is used safely and securely to protect the confidentiality and integrity of data and prevent the compromise of secure spaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -108,10 +109,7 @@ "11.6.68.C.01", "11.6.69.C.01", "11.6.70.C.01", - "11.6.71.C.01", - "11.6.72.C.01", - "11.6.72.C.02", - "11.6.72.C.03" + "11.6.71.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-30.json b/docs/api/controls/AST-30.json index 8e67c9f4..6843408c 100644 --- a/docs/api/controls/AST-30.json +++ b/docs/api/controls/AST-30.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT personnel collect technology assets and media for destruction when it is no longer needed for business or legal reasons.\n▪ Asset decommissioning consists of mainly wiping hard drives.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications and/or Services (TAAS) are properly decommissioned so that data is properly transitioned to new systems or archived in accordance with applicable organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -119,8 +120,11 @@ "11-3.a(5)(a)", "11-3.a(5)(b)" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" + "apac-aus-ism-2026-march": [ + "ISM-2053" + ], + "apac-mys-bnm-rmit-2025": [ + "10.13" ], "apac-nzl-ism-3-9": [ "2.3.30.C.01", @@ -137,7 +141,9 @@ "13.1.13.C.02", "13.1.13.C.03", "13.1.13.C.04", - "13.1.14.C.01" + "13.1.14.C.01", + "20.2.15.C.03", + "20.2.15.C.06" ] } } \ No newline at end of file diff --git a/docs/api/controls/AST-31.1.json b/docs/api/controls/AST-31.1.json index 95f8700d..0a468e49 100644 --- a/docs/api/controls/AST-31.1.json +++ b/docs/api/controls/AST-31.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize Artificial Intelligence (AI) and Autonomous Technologies (AAT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-31.2.json b/docs/api/controls/AST-31.2.json index dfbd65ef..b6393c7f 100644 --- a/docs/api/controls/AST-31.2.json +++ b/docs/api/controls/AST-31.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize a system and/or service as \"High Risk\" if it poses a significant risk of harm to an individual's:\n(1) Health;\n(2) Safety; and/or \n(3) Fundamental human rights.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-31.3.json b/docs/api/controls/AST-31.3.json index 9f3e81a7..4ff003c9 100644 --- a/docs/api/controls/AST-31.3.json +++ b/docs/api/controls/AST-31.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to dynamically associate asset-specific attributes to enable Attribute-Based Access Control (ABAC).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/AST-31.json b/docs/api/controls/AST-31.json index 4dacf4f0..504ab4e1 100644 --- a/docs/api/controls/AST-31.json +++ b/docs/api/controls/AST-31.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -118,6 +119,9 @@ "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-sparta": [ "CM0022" ], diff --git a/docs/api/controls/AST-32.json b/docs/api/controls/AST-32.json index c6027703..86633f5a 100644 --- a/docs/api/controls/AST-32.json +++ b/docs/api/controls/AST-32.json @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/controls/BCD-01.1.json b/docs/api/controls/BCD-01.1.json index 999d571f..acc9c231 100644 --- a/docs/api/controls/BCD-01.1.json +++ b/docs/api/controls/BCD-01.1.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan development with internal and external elements responsible for related plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan development with internal and external elements responsible for related plans. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -154,11 +155,16 @@ "emea-eu-nis2-annex-2024": [ "4.3.3" ], - "emea-isr-cmo-1-0": [ - "25.2" - ], "emea-sau-ecc-1-2018": [ "3-1-3-2" + ], + "emea-sau-otcc-1-2022": [ + "2-12-1-1" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-01.2.json b/docs/api/controls/BCD-01.2.json index 8078cfb5..cf583643 100644 --- a/docs/api/controls/BCD-01.2.json +++ b/docs/api/controls/BCD-01.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate internal contingency plans with the contingency plans of external service providers to ensure that contingency requirements can be satisfied.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -136,11 +137,16 @@ "emea-sau-ecc-1-2018": [ "3-1-3-2" ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" + ], "apac-ind-sebi-2024": [ "GV.SC.S6" ], - "amaericas-can-osfi-self-assessment": [ - "2.9" + "apac-sgp-mas-trm-2021": [ + "8.3.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-01.3.json b/docs/api/controls/BCD-01.3.json index 79da7166..ec64fb87 100644 --- a/docs/api/controls/BCD-01.3.json +++ b/docs/api/controls/BCD-01.3.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to redeploy personnel to other roles during a disruptive event or in the execution of a continuity plan.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/BCD-01.4.json b/docs/api/controls/BCD-01.4.json index dd1c48f2..aa74d1b2 100644 --- a/docs/api/controls/BCD-01.4.json +++ b/docs/api/controls/BCD-01.4.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to facilitate recovery operations in accordance with Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96,7 +96,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -160,6 +161,13 @@ "CP-06(02)", "CP-10" ], + "general-nist-800-172-r3": [ + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.08.04E.ODP[01]", + "A.03.08.04E.ODP[02]" + ], "general-nist-csf-2-0": [ "RC.RP", "RC.RP-02", @@ -202,6 +210,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "CP-10" ], + "emea-eu-eba-ict-srm-2025": [ + "3.7.2.81" + ], "emea-eu-dora-2023": [ "Article 12.6" ], @@ -210,31 +221,36 @@ "4.2.2(a)" ], "emea-deu-c5-2020": [ - "OPS-06", - "OPS-08", - "OPS-09" + "BCM-02-BP6", + "BCM-02-BP8", + "BCM-02-BP9" ], "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "2-9-1" + ], + "emea-sau-otcc-1-2022": [ + "3-1-1-1" ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1810" ], "apac-aus-ps-cps-230-2023": [ + "38", "38(a)", - "38(b)", - "38(c)", - "39" + "38(b)" ], "apac-ind-sebi-2024": [ "RC.RP.S2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.32" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP24", "HML24" ], @@ -242,7 +258,6 @@ "HSUP22" ], "apac-sgp-mas-trm-2021": [ - "8.1.4", "8.2.1" ], "americas-can-osfi-b13-2022": [ diff --git a/docs/api/controls/BCD-01.5.json b/docs/api/controls/BCD-01.5.json index a72914d5..343a7970 100644 --- a/docs/api/controls/BCD-01.5.json +++ b/docs/api/controls/BCD-01.5.json @@ -73,7 +73,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -96,9 +97,16 @@ "emea-uae-niaf-2023": [ "3.4.2" ], + "apac-aus-ps-cps-230-2023": [ + "34(d)" + ], "apac-ind-sebi-2024": [ "RC.RP.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.24", + "10.32" + ], "americas-can-osfi-b13-2022": [ "2.9.1" ] diff --git a/docs/api/controls/BCD-01.6.json b/docs/api/controls/BCD-01.6.json index fa8ab63f..37873304 100644 --- a/docs/api/controls/BCD-01.6.json +++ b/docs/api/controls/BCD-01.6.json @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -96,6 +97,9 @@ ], "emea-eu-nis2-annex-2024": [ "4.1.2(c)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.15" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-01.7.json b/docs/api/controls/BCD-01.7.json index a280089f..baf57040 100644 --- a/docs/api/controls/BCD-01.7.json +++ b/docs/api/controls/BCD-01.7.json @@ -3,7 +3,7 @@ "title": "Business Continuity & Disaster Recovery (BC/DR) Plans", "family": "BCD", "description": "Mechanisms exist for process owners to establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions.", - "scf_question": "Does the organization process owners to establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions?", + "scf_question": "Does the organization ensure process owners establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -73,9 +73,9 @@ "MT-10", "MT-11", "MT-24", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-cr-cmm-2026": [ @@ -101,6 +101,42 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "CP-02-SID" ], + "emea-eu-eba-ict-srm-2025": [ + "3.7.2.82", + "3.7.3.83", + "3.7.3.84", + "3.7.3.84(a)", + "3.7.3.84(b)", + "3.7.3.84(c)" + ], + "emea-sau-otcc-1-2022": [ + "3-1-1-3", + "3-1-1-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-67", + "VII.B.TPC-68", + "VII.B.TPC-68(a)", + "VII.B.TPC-68(b)", + "VII.B.TPC-68(c)", + "VII.B.TPC-68(d)", + "VII.B.TPC-68(e)", + "VII.B.TPC-68(f)", + "VII.B.TPC-68(g)", + "VII.B.TPC-68(h)", + "VII.B.TPC-68(i)", + "VII.B.TPC-69" + ], + "apac-aus-ps-cps-230-2023": [ + "16(e)", + "34(c)", + "40", + "40(a)", + "40(b)", + "40(c)", + "40(d)", + "40(e)" + ], "apac-jpn-ismap": [ "12.2.1.10", "12.2.1.11", @@ -111,6 +147,16 @@ "17.1.2.4", "17.1.2.5", "17.1.2.6" + ], + "apac-sgp-mas-trm-2021": [ + "8.2.2", + "8.2.3" + ], + "americas-bmu-mba-coc-2020": [ + "7.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-01.json b/docs/api/controls/BCD-01.json index 782602d7..cd6c98eb 100644 --- a/docs/api/controls/BCD-01.json +++ b/docs/api/controls/BCD-01.json @@ -103,7 +103,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -132,7 +133,7 @@ "CC9.1-POF2" ], "general-cis-csc-8-1": [ - "11.0", + "11", "11.1" ], "general-cis-csc-8-1-ig1": [ @@ -303,7 +304,7 @@ "5.30", "8.13(a)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1485", "T1486", "T1490", @@ -408,6 +409,16 @@ "CP-1", "CP-2" ], + "general-nist-800-172-r3": [ + "03.04.04E", + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.03E[04]", + "A.03.04.03E.ODP[04]", + "DS-A.03.04.04E[04]", + "DS-A.03.08.04E[01]" + ], "general-nist-csf-2-0": [ "GV.SC-08", "ID.IM-04", @@ -520,12 +531,12 @@ "PM-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "CP-1", @@ -588,18 +599,14 @@ "CP-10" ], "emea-eu-eba-ict-srm-2025": [ - "3.7(77)", - "3.7.1(78)", - "3.7.1(79)", - "3.7.2(80)", - "3.7.2(81)", - "3.7.2(82)", - "3.7.3(83)", - "3.7.3(84)(a)", - "3.7.3(84)(b)", - "3.7.3(84)(c)", - "3.7.3(85)", - "3.7.3(86)" + "3.7.77", + "3.7.1.78", + "3.7.1.79", + "3.7.2.80", + "3.7.3.83", + "3.7.3.85", + "3.7.3.86", + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 11.1", @@ -647,33 +654,42 @@ "12.1.2(c)", "13.2.2(a)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ + "1.2(e)", "10.1", "10.2", "10.3", "10.5" ], "emea-deu-c5-2020": [ + "UP-01-BP4", + "RB-06", "BCM-01", "BCM-02", - "BCM-03" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.1" + "BCM-02-BP1", + "BCM-02-BP2", + "BCM-02-BP3", + "BCM-02-BP4", + "BCM-02-BP5", + "BCM-02-BP6", + "BCM-02-BP7", + "BCM-02-BP8", + "BCM-02-BP9", + "BCM-02-BP10", + "BCM-03", + "BCM-03-BP1", + "BCM-03-BP2", + "BCM-03-BP3", + "BCM-03-BP4", + "BCM-03-BP5", + "BCM-03-BP6", + "BCM-03-BP7", + "BCM-03-BP8" ], "emea-sau-cscc-1-2019": [ - "2-8", - "3-1", - "3-1-1-1", - "3-1-1-2" + "2-8-1", + "3-1-1", + "3-1-1-1" ], "emea-sau-cgiot-2024": [ "2-8-1", @@ -681,49 +697,29 @@ "3-1-1" ], "emea-sau-ecc-1-2018": [ - "2-4-4", - "2-9-1", "2-9-2", - "2-9-3", - "2-9-3-1", - "2-9-4", "3-1-1", "3-1-2", - "3-1-3", "3-1-3-1", "3-1-3-2", - "3-1-3-3", - "3-1-4" + "3-1-3-3" ], "emea-sau-otcc-1-2022": [ - "3-1", - "3-1-1", - "3-1-1-1", - "3-1-1-2", - "3-1-1-3", - "3-1-1-4", - "3-1-1-5", - "3-1-1-6", - "3-1-2" + "2-8-1", + "2-8-2", + "3-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-67", - "TPC-68", - "TPC-69" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 26" + "VII.B.TPC-64" ], "emea-esp-decree-311-2022": [ - "26" + "Article 12(6)(n)", + "Article 22(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.5.1 [OP.CONT.1]", - "7.5.2 [OP.CONT.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.4", @@ -734,9 +730,6 @@ "emea-gbr-caf-4-0": [ "B5.a" ], - "emea-gbr-cap-1850-2020": [ - "D1" - ], "emea-gbr-def-stan-05-138-2024": [ "2501", "2502", @@ -755,22 +748,13 @@ "2501", "4100" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0734" ], "apac-aus-ps-cps-230-2023": [ - "12(b)", "14", - "34(a)", + "15", "34(b)", - "34(c)", - "34(d)", - "34(e)", - "40(a)", - "40(b)", - "40(c)", - "40(d)", - "40(e)", "41" ], "apac-chn-cybersecurity-law-2017": [ @@ -796,7 +780,13 @@ "17.1.3.1", "17.1.3.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.6", + "10.24", + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP08", "HHSP24", "HHSP56", @@ -805,9 +795,6 @@ "HML24", "HML61" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS21" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP08", "HSUP22", @@ -817,34 +804,23 @@ "6.4.5.C.01", "6.4.7.C.01", "6.4.8.C.01", + "20.1.26.C.01", "23.4.12.C.01", "23.4.12.C.02" ], "apac-sgp-mas-trm-2021": [ - "8.1.1", - "8.1.2", - "8.1.3", - "8.1.4", - "8.2.1", - "8.2.2", - "8.2.3", - "8.2.4", - "8.5.1", - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" + "8.1.1" ], "americas-bmu-mba-coc-2020": [ - "6.14", + "6.3", "7.1" ], - "amaericas-can-osfi-self-assessment": [ - "2.9" - ], "americas-can-osfi-b13-2022": [ "2.9", "2.9.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-02.1.json b/docs/api/controls/BCD-02.1.json index 9e346100..33406e60 100644 --- a/docs/api/controls/BCD-02.1.json +++ b/docs/api/controls/BCD-02.1.json @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -172,28 +173,18 @@ "emea-eu-nis2-annex-2024": [ "4.1.2(h)" ], - "emea-isr-cmo-1-0": [ - "21.15", - "21.16" - ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" - ], "emea-uae-niaf-2023": [ "3.4.3" ], "apac-aus-ps-cps-230-2023": [ "34(e)" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP35", "HML35" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP31" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-02.2.json b/docs/api/controls/BCD-02.2.json index 7505aee4..a8ac4b04 100644 --- a/docs/api/controls/BCD-02.2.json +++ b/docs/api/controls/BCD-02.2.json @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -146,33 +147,31 @@ "CP-02(05)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.16(a)(2)(iv)" ], - "emea-isr-cmo-1-0": [ - "18.15", - "25.23" - ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "emea-sau-otcc-1-2022": [ + "3-1-1-5" ], "apac-aus-ps-cps-230-2023": [ - "34(e)" + "34(e)", + "38(c)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.25", + "10.26" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP35", "HML35" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP31" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-02.3.json b/docs/api/controls/BCD-02.3.json index 84dcc64c..9dffde31 100644 --- a/docs/api/controls/BCD-02.3.json +++ b/docs/api/controls/BCD-02.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.\n▪ Business stakeholders and process owners define Recovery Time Objectives (RTOs) for business-critical TAASD.\n▪ Business stakeholders and process owners define Recovery Point Objectives (RPOs) for business-critical TAASD.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to resume essential missions and business functions within an organization-defined time period of contingency plan activation.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to resume essential missions and business functions within an organization-defined time period of contingency plan activation. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -157,18 +158,15 @@ "emea-eu-nis2-annex-2024": [ "4.1.2(h)" ], - "emea-isr-cmo-1-0": [ - "21.15", - "21.16" + "emea-deu-c5-2020": [ + "BCM-02-BP7" ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "emea-sau-otcc-1-2022": [ + "3-1-1-5" ], "apac-aus-ps-cps-230-2023": [ - "34(e)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" + "34(e)", + "38(c)" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-02.4.json b/docs/api/controls/BCD-02.4.json index e50d457a..d683584f 100644 --- a/docs/api/controls/BCD-02.4.json +++ b/docs/api/controls/BCD-02.4.json @@ -2,8 +2,8 @@ "control_id": "BCD-02.4", "title": "Data Storage Location Reviews", "family": "BCD", - "description": "Mechanisms exist to perform periodic security reviews of storage locations that contain sensitive/regulated data.", - "scf_question": "Does the organization perform periodic security reviews of storage locations that contain sensitive/regulated data?", + "description": "Mechanisms exist to perform periodic security reviews of storage locations that contain sensitive and/or regulated data.", + "scf_question": "Does the organization perform periodic security reviews of storage locations that contain sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to perform periodic security reviews of storage locations that contain sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -93,16 +93,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF9" ], - "general-nist-800-172": [ - "3.14.5e" - ], "general-pci-dss-4-0-1": [ "9.4.1.2" ], @@ -114,6 +112,9 @@ ], "general-shared-assessments-sig-2025": [ "F.1" + ], + "emea-deu-c5-2020": [ + "BCM-05" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-02.json b/docs/api/controls/BCD-02.json index a6d80acd..eb686f86 100644 --- a/docs/api/controls/BCD-02.json +++ b/docs/api/controls/BCD-02.json @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -161,6 +162,12 @@ "general-nist-800-161-r1-level-3": [ "CP-2(8)" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.10E" + ], "general-nist-csf-2-0": [ "GV.OC-04", "GV.OC-05", @@ -169,9 +176,6 @@ "RC.RP-02", "RC.RP-04" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -200,10 +204,10 @@ "CP-02(08)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-irs-1075-2021": [ "CP-2(CE-8)" @@ -216,31 +220,24 @@ "500.16(a)(2)(vi)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(78)", - "3.7.3(83)" + "3.3.2.16", + "3.7.1.78" ], "emea-eu-dora-2023": [ "Article 8.4" ], - "emea-deu-bsrit-2017": [ - "12.2" - ], "emea-deu-c5-2020": [ - "BCM-02" + "RB-12", + "BCM-02-BP4" ], "emea-sau-cscc-1-2019": [ + "2-1-1-1", "2-8-1-1", "3-1-1-2" ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" - ], "emea-sau-otcc-1-2022": [ "2-1-1-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-24" - ], "emea-uae-niaf-2023": [ "3.4" ], @@ -250,27 +247,28 @@ "emea-gbr-cap-1850-2020": [ "A4" ], + "apac-aus-ism-2026-march": [ + "ISM-2005" + ], "apac-aus-ps-cps-230-2023": [ + "15", "34(a)", - "35", - "36(a)", - "36(b)", - "36(c)", - "36(d)", - "37" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "35" ], "apac-ind-sebi-2024": [ "ID.AM.S4" ], - "apac-sgp-mas-trm-2021": [ - "8.1.2" + "apac-mys-bnm-rmit-2025": [ + "9.2", + "10.26", + "11.3" ], "americas-can-osfi-b13-2022": [ "2.2.2", "2.9.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-03.1.json b/docs/api/controls/BCD-03.1.json index 0ab098ad..264403aa 100644 --- a/docs/api/controls/BCD-03.1.json +++ b/docs/api/controls/BCD-03.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to incorporate simulated events into contingency training to facilitate effective response by personnel in crisis situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -114,18 +115,12 @@ "usa-federal-gsa-fedramp-5-high": [ "CP-03(01)" ], - "emea-isr-cmo-1-0": [ - "25.4", - "25.5" - ], "emea-sau-cscc-1-2019": [ "3-1-1-4" ], - "emea-sau-otcc-1-2022": [ - "3-1-1-6" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-sgp-mas-trm-2021": [ + "13.5.1", + "13.5.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-03.2.json b/docs/api/controls/BCD-03.2.json index 42ff7f6b..dac15e1c 100644 --- a/docs/api/controls/BCD-03.2.json +++ b/docs/api/controls/BCD-03.2.json @@ -63,7 +63,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -78,9 +79,6 @@ ], "general-nist-800-82-r3": [ "CP-03(02)" - ], - "emea-isr-cmo-1-0": [ - "25.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-03.json b/docs/api/controls/BCD-03.json index 19ab0296..f98c2b78 100644 --- a/docs/api/controls/BCD-03.json +++ b/docs/api/controls/BCD-03.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to adequately train contingency personnel and applicable stakeholders in their contingency roles and responsibilities.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to adequately train contingency personnel and applicable stakeholders in their contingency roles and responsibilities. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -183,9 +184,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CP-03" - ], - "emea-isr-cmo-1-0": [ - "25.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-04.1.json b/docs/api/controls/BCD-04.1.json index 949324f4..8db4ef54 100644 --- a/docs/api/controls/BCD-04.1.json +++ b/docs/api/controls/BCD-04.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan testing with internal and external elements responsible for related plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan testing with internal and external elements responsible for related plans. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -118,16 +119,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-4(1)" - ], - "emea-isr-cmo-1-0": [ - "25.6", - "25.7" - ], - "apac-sgp-mas-trm-2021": [ - "8.3.4" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-04.2.json b/docs/api/controls/BCD-04.2.json index 7dd42e08..821fefcf 100644 --- a/docs/api/controls/BCD-04.2.json +++ b/docs/api/controls/BCD-04.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A dedicated alternate site(s) is/are equipped to be compatible with the production network's processing, storage, connectivity and other infrastructure needs.\n▪ Alternate sites are given priority of service to meet applicable RTOs and/or RPOs.\n▪ RTOs are used to identify business-critical TAASD, which are given priority of service in alternate processing and storage sites.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to test contingency plans at alternate storage & processing sites to both familiarize contingency personnel with the facility and evaluate the capabilities of the alternate processing site to support contingency operations.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to test contingency plans at alternate storage & processing sites to both familiarize contingency personnel with the facility and evaluate the capabilities of the alternate processing site to support contingency operations. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -123,11 +124,11 @@ "emea-eu-nis2-annex-2024": [ "4.2.2(c)" ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], "apac-sgp-mas-trm-2021": [ - "8.2.4" + "8.5.2", + "8.5.2(a)", + "8.5.2(b)", + "8.5.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-04.json b/docs/api/controls/BCD-04.json index 9612fbd7..538d207f 100644 --- a/docs/api/controls/BCD-04.json +++ b/docs/api/controls/BCD-04.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to conduct tests and/or exercises to evaluate the contingency plan's effectiveness and the organization's readiness to execute the plan.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to conduct tests and/or exercises to evaluate the contingency plan's effectiveness and the organization's readiness to execute the plan. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -221,10 +222,10 @@ "CP-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "CP-4" @@ -256,12 +257,12 @@ "CP-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(87)", - "3.7.4(89)", - "3.7.4(89)(a)", - "3.7.4(89)(b)", - "3.7.4(89)(c)", - "3.7.4(90)" + "3.7.4.87", + "3.7.4.89", + "3.7.4.89(a)", + "3.7.4.89(b)", + "3.7.4.89(c)", + "3.7.4.90" ], "emea-eu-dora-2023": [ "Article 11.4", @@ -281,28 +282,29 @@ "4.3.4" ], "emea-deu-bsrit-2017": [ - "10.4" + "10.4", + "10.5" ], "emea-deu-c5-2020": [ - "PS-02", - "PS-06", - "BCM-04" + "PS-03-BP6", + "BCM-04", + "BCM-04-DOAR", + "BCM-05-DOAR" ], - "emea-isr-cmo-1-0": [ - "25.4", - "25.6", - "25.7", - "25.9", - "25.23" + "emea-sau-cscc-1-2019": [ + "3-1-1-3", + "3-1-1-4" ], "emea-sau-otcc-1-2022": [ "3-1-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-70" + "VII.B.TPC-70" ], - "emea-esp-ccn-stic-825-2023": [ - "7.5.3 [OP.CONT.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.4.1" @@ -317,10 +319,9 @@ "2503" ], "apac-aus-ps-cps-230-2023": [ + "27(c)", "43", - "44", - "45", - "46" + "44" ], "apac-chn-cybersecurity-law-2017": [ "Article 34(4)" @@ -336,18 +337,22 @@ "17.1.3.3" ], "apac-sgp-mas-trm-2021": [ - "8.2.3", + "8.2.4", "8.3.1", "8.3.2", + "8.3.3", "8.3.3(a)", "8.3.3(b)", - "8.3.4" + "13.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "americas-bmu-mba-coc-2020": [ + "7.1-BP2" ], "americas-can-osfi-b13-2022": [ "2.9.3" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-05.json b/docs/api/controls/BCD-05.json index fd2b0197..9f87765a 100644 --- a/docs/api/controls/BCD-05.json +++ b/docs/api/controls/BCD-05.json @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -182,10 +183,10 @@ "CP-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "CP-4" @@ -207,8 +208,9 @@ "CP-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(88)", - "3.7.4(90)" + "3.7.3.84(c)", + "3.7.4.88", + "3.7.4.90" ], "emea-eu-dora-2023": [ "Article 13.2", @@ -221,11 +223,9 @@ "emea-eu-nis2-annex-2024": [ "4.1.4" ], - "emea-deu-c5-2020": [ - "BCM-04" - ], - "emea-gbr-cap-1850-2020": [ - "D2" + "apac-aus-ps-cps-230-2023": [ + "32", + "45" ], "apac-ind-sebi-2024": [ "RC.IM.S1", @@ -235,20 +235,12 @@ "RS.AN.S4b", "RS.IM.S1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP64", "HML63" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP56" - ], - "apac-sgp-mas-trm-2021": [ - "7.8.1", - "7.8.2", - "7.8.3" - ], - "amaericas-can-osfi-self-assessment": [ - "5.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-06.1.json b/docs/api/controls/BCD-06.1.json index 88b8fb62..9e31679d 100644 --- a/docs/api/controls/BCD-06.1.json +++ b/docs/api/controls/BCD-06.1.json @@ -3,7 +3,7 @@ "title": "Contingency Planning Components", "family": "BCD", "description": "Mechanisms exist to identify components that potentially impact the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure.", - "scf_question": "Does the organization identify components that potentially impacts the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure?", + "scf_question": "Does the organization identify components that potentially impact its ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify components that potentially impacts the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -83,6 +84,9 @@ ], "usa-federal-nerc-cip-2024": [ "CIP-009-6 3.2" + ], + "apac-aus-ps-cps-230-2023": [ + "45" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-06.2.json b/docs/api/controls/BCD-06.2.json index b110e84d..1100e22f 100644 --- a/docs/api/controls/BCD-06.2.json +++ b/docs/api/controls/BCD-06.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to keep stakeholders informed of changes to contingency plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to keep stakeholders informed of changes to contingency plans.\n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/BCD-06.json b/docs/api/controls/BCD-06.json index d7da5660..2dd90c60 100644 --- a/docs/api/controls/BCD-06.json +++ b/docs/api/controls/BCD-06.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Production TAASD support business-critical application and services failover.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to develop BC/DR plans to recover business-critical TAASD.\n▪ Data/process owners conduct a Business Impact Analysis (BIA) at least annually, or after any major technology or process change, to identify TAASD that are critical to the business, as well as single points of failure.\n▪ Business stakeholders and process owners designate alternative decision-makers if primary decision-makers are unavailable.\n▪ Within the BC/DR plans, alternate communications channels are defined if primary means of communication are unavailable.\n▪ RTOs are used to identify business-critical TAASD, which are given priority of service in alternate processing and storage sites.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to update contingency plans due to changes affecting:\n(1) People (e.g., personnel changes);\n(2) Processes (e.g., new, altered or decommissioned business practices, including third-party services)\n(3) Technologies (e.g., new, altered or decommissioned technologies);\n(4) Data (e.g., changes to data flows and/or data repositories);\n(5) Facilities (e.g., new, altered or decommissioned physical infrastructure); and/or\n(6) Feedback from contingency plan testing activities.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -197,14 +198,14 @@ "CP-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(88)", - "3.7.4(90)" + "3.7.4.88", + "3.7.4.90" ], "emea-deu-c5-2020": [ "BCM-04" ], - "emea-sau-ecc-1-2018": [ - "3-1-4" + "apac-aus-ps-cps-230-2023": [ + "45" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-07.json b/docs/api/controls/BCD-07.json index 90a7e54b..20d6c314 100644 --- a/docs/api/controls/BCD-07.json +++ b/docs/api/controls/BCD-07.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/BCD-08.1.json b/docs/api/controls/BCD-08.1.json index c9f99aa5..29bdb5ab 100644 --- a/docs/api/controls/BCD-08.1.json +++ b/docs/api/controls/BCD-08.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to separate the alternate storage site from the primary storage site to reduce susceptibility to similar threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -58,9 +58,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -113,12 +113,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-6(1)" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-08.2.json b/docs/api/controls/BCD-08.2.json index 838bc698..59aa68a0 100644 --- a/docs/api/controls/BCD-08.2.json +++ b/docs/api/controls/BCD-08.2.json @@ -3,7 +3,7 @@ "title": "Primary Storage Site Accessibility", "family": "BCD", "description": "Mechanisms exist to identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster.", - "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster?", + "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -78,9 +78,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -124,9 +124,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-6(3)" - ], - "emea-isr-cmo-1-0": [ - "25.13" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-08.json b/docs/api/controls/BCD-08.json index 0f0d4466..b86cd933 100644 --- a/docs/api/controls/BCD-08.json +++ b/docs/api/controls/BCD-08.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate storage site that includes both the assets and necessary agreements to permit the storage and recovery of system backup information.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate storage site that includes both the assets and necessary agreements to permit the storage and recovery of system backup information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -109,7 +110,7 @@ "general-iso-27018-2025": [ "8.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -191,22 +192,8 @@ "emea-deu-bsrit-2017": [ "10.5" ], - "emea-deu-c5-2020": [ - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.7", - "25.10" - ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.4.4 [MP.COM.4]", - "8.8.4 [MP.S.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-09.1.json b/docs/api/controls/BCD-09.1.json index 37b3d7b4..b12f3333 100644 --- a/docs/api/controls/BCD-09.1.json +++ b/docs/api/controls/BCD-09.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to separate the alternate processing site from the primary processing site to reduce susceptibility to similar threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -58,9 +58,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -107,12 +107,6 @@ ], "emea-eu-dora-2023": [ "Article 12.5(a)" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-09.2.json b/docs/api/controls/BCD-09.2.json index bd36865e..c987755c 100644 --- a/docs/api/controls/BCD-09.2.json +++ b/docs/api/controls/BCD-09.2.json @@ -3,7 +3,7 @@ "title": "Alternate Processing Site Accessibility", "family": "BCD", "description": "Mechanisms exist to identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster.", - "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate processing site and possible mitigation actions, in the event of an area-wide disruption or disaster?", + "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,9 +76,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -124,19 +124,16 @@ "CP-07(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "CP-7(2)" ], "emea-eu-dora-2023": [ "Article 12.5(c)" - ], - "emea-isr-cmo-1-0": [ - "25.13" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-09.3.json b/docs/api/controls/BCD-09.3.json index c632ca22..eb8cc952 100644 --- a/docs/api/controls/BCD-09.3.json +++ b/docs/api/controls/BCD-09.3.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to address priority-of-service provisions in alternate processing and storage sites that support availability requirements, including Recovery Time Objectives (RTOs).", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to address priority-of-service provisions in alternate processing and storage sites that support availability requirements, including Recovery Time Objectives (RTOs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -119,10 +120,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-7(3)" - ], - "emea-isr-cmo-1-0": [ - "25.12", - "21.14" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-09.4.json b/docs/api/controls/BCD-09.4.json index b8b4cd73..60839b19 100644 --- a/docs/api/controls/BCD-09.4.json +++ b/docs/api/controls/BCD-09.4.json @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/BCD-09.5.json b/docs/api/controls/BCD-09.5.json index df8cbb62..0c135583 100644 --- a/docs/api/controls/BCD-09.5.json +++ b/docs/api/controls/BCD-09.5.json @@ -3,7 +3,7 @@ "title": "Inability to Return to Primary Site", "family": "BCD", "description": "Mechanisms exist to plan and prepare for both natural and manmade circumstances that preclude returning to the primary site.", - "scf_question": "Does the organization plan and prepare for both natural and manmade circumstances that preclude returning to the primary processing site?", + "scf_question": "Does the organization plan and prepare for both natural and manmade circumstances that preclude returning to the primary site?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to plan and prepare for both natural and manmade circumstances that preclude returning to the primary site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74,9 +74,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-nist-800-53-r4": [ diff --git a/docs/api/controls/BCD-09.json b/docs/api/controls/BCD-09.json index db91a646..fe17a8b4 100644 --- a/docs/api/controls/BCD-09.json +++ b/docs/api/controls/BCD-09.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate processing site that provides security measures equivalent to that of the primary site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -115,7 +116,7 @@ "general-iso-27018-2025": [ "8.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -213,21 +214,8 @@ "emea-deu-bsrit-2017": [ "10.5" ], - "emea-deu-c5-2020": [ - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.7", - "25.10" - ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.8.4 [MP.S.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" ], "apac-jpn-ismap": [ "17.2", diff --git a/docs/api/controls/BCD-10.1.json b/docs/api/controls/BCD-10.1.json index c3bb9a70..6947b418 100644 --- a/docs/api/controls/BCD-10.1.json +++ b/docs/api/controls/BCD-10.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to formalize primary and alternate telecommunications service agreements contain priority-of-service provisions that support availability requirements, including Recovery Time Objectives (RTOs).", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to formalize primary and alternate telecommunications service agreements contain priority-of-service provisions that support availability requirements, including Recovery Time Objectives (RTOs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -57,7 +57,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -107,10 +108,6 @@ "CP-8(1)", "CP-8(1).a", "CP-8(1).b" - ], - "emea-isr-cmo-1-0": [ - "21.14", - "25.17" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-10.2.json b/docs/api/controls/BCD-10.2.json index 3bc943cd..77252c86 100644 --- a/docs/api/controls/BCD-10.2.json +++ b/docs/api/controls/BCD-10.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/BCD-10.3.json b/docs/api/controls/BCD-10.3.json index 60ea2d6e..53bc5b57 100644 --- a/docs/api/controls/BCD-10.3.json +++ b/docs/api/controls/BCD-10.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to contractually-require external service providers to have contingency plans that meet organizational contingency requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -115,7 +116,7 @@ "CP-08(04)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.3(86)" + "3.7.3.86" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-10.4.json b/docs/api/controls/BCD-10.4.json index 248a6165..fbebf157 100644 --- a/docs/api/controls/BCD-10.4.json +++ b/docs/api/controls/BCD-10.4.json @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -106,10 +107,13 @@ "CM0070" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-nis2-annex-2024": [ "4.3.2(b)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.15" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-10.json b/docs/api/controls/BCD-10.json index fd970d71..c480f329 100644 --- a/docs/api/controls/BCD-10.json +++ b/docs/api/controls/BCD-10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to reduce the likelihood of a single point of failure with primary telecommunications services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -164,13 +165,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CP-08" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" - ], - "emea-isr-cmo-1-0": [ - "21.14", - "25.16" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-11.1.json b/docs/api/controls/BCD-11.1.json index b98b4f93..a905e94b 100644 --- a/docs/api/controls/BCD-11.1.json +++ b/docs/api/controls/BCD-11.1.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ A random sampling of backups is tested at least annually to verify integrity and recoverability of backed up data.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel perform a random sampling of backups is tested at least semi-annually to verify integrity and recoverability of backed up data.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to routinely test backups that verify the reliability of the backup process, as well as the integrity and availability of the data.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to routinely test backups that verify the reliability of the backup process, as well as the integrity and availability of the data. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -143,6 +144,13 @@ "general-nist-800-160-vol-2-r1": [ "CP-09(01)" ], + "general-nist-800-172-r3": [ + "03.08.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.03E[01]", + "DS-A.03.08.03E[02]" + ], "general-nist-csf-2-0": [ "PR.DS-11" ], @@ -183,13 +191,7 @@ "4.2.2(b)" ], "emea-deu-c5-2020": [ - "OPS-06", - "OPS-07", - "OPS-08" - ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.19" + "RB-07" ], "emea-sau-cscc-1-2019": [ "2-8-2" @@ -200,6 +202,9 @@ "emea-sau-ecc-1-2018": [ "2-9-3-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" + ], "emea-gbr-def-stan-05-138-2024": [ "2504", "2505" @@ -213,27 +218,29 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2505" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1515" ], "apac-ind-sebi-2024": [ "PR.IP.S8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP57", "HHSP69", "HML57", "HML68" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP49", "HSUP60" ], - "apac-sgp-mas-trm-2021": [ - "8.4.3" + "americas-arg-ppd-2018": [ + "D.1.1-2", + "D.1.1-3", + "D.1.2-4" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-11.10.json b/docs/api/controls/BCD-11.10.json index 91a6c772..fe3fba5c 100644 --- a/docs/api/controls/BCD-11.10.json +++ b/docs/api/controls/BCD-11.10.json @@ -68,16 +68,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { + "emea-sau-cscc-1-2019": [ + "2-8-1-3" + ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-aus-ism-2026-march": [ + "ISM-1814" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP56", "HML56" ], diff --git a/docs/api/controls/BCD-11.2.json b/docs/api/controls/BCD-11.2.json index d0eaa7b6..a455ed4b 100644 --- a/docs/api/controls/BCD-11.2.json +++ b/docs/api/controls/BCD-11.2.json @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -174,23 +175,22 @@ "CP-09(3)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(58)" + "3.5.58" ], "emea-eu-dora-2023": [ "Article 12.3" ], "emea-deu-c5-2020": [ - "OPS-06", - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "25.20" + "RB-09" ], "emea-sau-otcc-1-2022": [ - "2-8-1-4" + "2-8-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-38" + "VII.B.TPC-65" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-def-stan-05-138-2024": [ "2505" @@ -206,7 +206,7 @@ "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1811" ], "apac-jpn-ismap": [ @@ -214,6 +214,15 @@ "12.3.1.6", "12.3.1.7", "12.3.1.23.P" + ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-sgp-mas-trm-2021": [ + "8.4.4" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-2" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-11.3.json b/docs/api/controls/BCD-11.3.json index 11dfdb27..e68c96b3 100644 --- a/docs/api/controls/BCD-11.3.json +++ b/docs/api/controls/BCD-11.3.json @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -72,12 +73,8 @@ "general-cr-cmm-2026": [ "CR10.2.6" ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.12", - "25.22" + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-11.4.json b/docs/api/controls/BCD-11.4.json index 40c2cd4c..7f07dd3c 100644 --- a/docs/api/controls/BCD-11.4.json +++ b/docs/api/controls/BCD-11.4.json @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -192,8 +193,8 @@ "CP-09 (08)", "SC-28 (01)" ], - "emea-isr-cmo-1-0": [ - "25.18" + "emea-deu-c5-2020": [ + "RB-06-DOAR" ], "emea-sau-cscc-1-2019": [ "2-8-1-3" @@ -202,7 +203,11 @@ "2-8-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-65" + "VII.B.TPC-50", + "VII.B.TPC-65" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-def-stan-05-138-2024": [ "2506" @@ -213,12 +218,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2506" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" + "apac-mys-bnm-rmit-2025": [ + "10.45" ], "apac-sgp-mas-trm-2021": [ "8.4.4" ], + "americas-arg-ppd-2018": [ + "D.1.2-2" + ], "americas-can-itsp-10-171-2025": [ "03.08.09.A", "03.08.09.B" diff --git a/docs/api/controls/BCD-11.5.json b/docs/api/controls/BCD-11.5.json index 05da5e71..b23359c6 100644 --- a/docs/api/controls/BCD-11.5.json +++ b/docs/api/controls/BCD-11.5.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel perform a random sampling of backups is tested at least semi-annually to verify integrity and recoverability of backed up data.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize sampling of available backups to test recovery capabilities as part of business continuity plan testing.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize sampling of available backups to test recovery capabilities as part of business continuity plan testing. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -134,8 +135,8 @@ "Article 12.2", "Article 12.7" ], - "emea-sau-cscc-1-2019": [ - "3-1-1-3" + "emea-deu-c5-2020": [ + "RB-08" ], "emea-sau-cgiot-2024": [ "2-8-3" @@ -160,6 +161,12 @@ "12.3.1.10", "12.3.1.20.P", "12.3.1.22.P" + ], + "apac-sgp-mas-trm-2021": [ + "8.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "6.14" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-11.6.json b/docs/api/controls/BCD-11.6.json index bcafa686..cf1c77dc 100644 --- a/docs/api/controls/BCD-11.6.json +++ b/docs/api/controls/BCD-11.6.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to transfer backup data to the alternate storage site at a rate that is capable of meeting both Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -121,7 +122,7 @@ "Article 12.3" ], "emea-sau-otcc-1-2022": [ - "2-8-1-4" + "2-8-1-1" ], "emea-gbr-def-stan-05-138-2024": [ "2506" diff --git a/docs/api/controls/BCD-11.7.json b/docs/api/controls/BCD-11.7.json index f7efa152..94b06064 100644 --- a/docs/api/controls/BCD-11.7.json +++ b/docs/api/controls/BCD-11.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to maintain a failover capability, which is not collocated with the primary Technology Asset, Application and/or Service (TAAS), which can be activated with little-to-no loss of information or disruption to operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -116,11 +117,19 @@ "4.2.4(d)", "13.1.2(b)" ], - "emea-deu-c5-2020": [ - "PS-02" - ], "emea-sau-otcc-1-2022": [ "3-1-1-2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" + ], + "apac-mys-bnm-rmit-2025": [ + "10.25", + "10.26" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.2", + "8.5.2(c)" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-11.8.json b/docs/api/controls/BCD-11.8.json index 856c2dd8..ff3a0753 100644 --- a/docs/api/controls/BCD-11.8.json +++ b/docs/api/controls/BCD-11.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to enforce dual authorization for the deletion or destruction of sensitive backup media and data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -89,6 +90,12 @@ ], "general-nist-800-160-vol-2-r1": [ "CP-09(07)" + ], + "general-nist-800-172-r3": [ + "03.08.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.02E" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-11.9.json b/docs/api/controls/BCD-11.9.json index efc1b18c..8fd17c40 100644 --- a/docs/api/controls/BCD-11.9.json +++ b/docs/api/controls/BCD-11.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restrict access to backups to privileged users with assigned roles for data backup and recovery operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -81,13 +82,21 @@ "emea-eu-nis2-annex-2024": [ "4.2.2(d)" ], - "emea-sau-sacs-002-2022": [ - "TPC-50" + "emea-sau-cscc-1-2019": [ + "2-8-1-3" ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" + ], + "apac-aus-ism-2026-march": [ + "ISM-1812", + "ISM-1813", + "ISM-1814" + ], + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-11.json b/docs/api/controls/BCD-11.json index e9c54142..f51cf4da 100644 --- a/docs/api/controls/BCD-11.json +++ b/docs/api/controls/BCD-11.json @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -156,7 +157,7 @@ "general-iso-27018-2025": [ "8.13" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1005", @@ -229,6 +230,9 @@ "general-nist-800-171a": [ "3.8.9" ], + "general-nist-800-171a-r3": [ + "A.03.08.09.a" + ], "general-nist-csf-2-0": [ "PR.DS-11" ], @@ -316,13 +320,16 @@ "CP-09", "SC-28(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(g)(4)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "CP-9" @@ -357,7 +364,7 @@ "CP-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(57)" + "3.5.57" ], "emea-eu-dora-2023": [ "Article 12.1", @@ -379,12 +386,14 @@ "8.7" ], "emea-deu-c5-2020": [ - "OPS-06" + "RB-06", + "RB-07" ], - "emea-isr-cmo-1-0": [ - "25.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 14.1" ], "emea-sau-cscc-1-2019": [ + "2-8-1-1", "2-8-1-2", "2-8-1-3" ], @@ -393,28 +402,22 @@ "2-8-2" ], "emea-sau-ecc-1-2018": [ - "2-9-3" + "2-4-3-3", + "2-9-3-1", + "2-9-3-2" ], "emea-sau-otcc-1-2022": [ - "2-8", - "2-8-1", "2-8-1-1", - "2-8-1-2", - "2-8-1-3", - "2-8-1-4", - "2-8-2" + "2-8-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-64" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 26" + "VII.B.TPC-64" ], "emea-esp-decree-311-2022": [ - "26" + "Article 26" ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.7 [MP.INFO.7]" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-caf-4-0": [ "B5.c" @@ -437,9 +440,7 @@ "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", + "apac-aus-ism-2026-march": [ "ISM-1511", "ISM-1547", "ISM-1548", @@ -472,7 +473,10 @@ "12.3.1.21.P", "12.3.1.24.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP17", "HHSP56", "HHSP69", @@ -480,9 +484,6 @@ "HML56", "HML68" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP15", "HSUP48", @@ -495,12 +496,19 @@ "8.4.1", "8.4.2" ], + "americas-arg-ppd-2018": [ + "D", + "D.1.1-1" + ], "americas-bmu-mba-coc-2020": [ "6.14" ], "americas-can-osfi-b13-2022": [ "2.9.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" + ], "americas-can-itsp-10-171-2025": [ "03.08.09.A" ] diff --git a/docs/api/controls/BCD-12.1.json b/docs/api/controls/BCD-12.1.json index 17c51177..cb3cd260 100644 --- a/docs/api/controls/BCD-12.1.json +++ b/docs/api/controls/BCD-12.1.json @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -137,12 +138,8 @@ "usa-federal-irs-1075-2021": [ "CP-10(CE-2)" ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.21" - ], - "emea-sau-ecc-1-2018": [ - "2-4-3-3" + "usa-federal-cms-marse-2-0": [ + "CP-10(2)" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-12.2.json b/docs/api/controls/BCD-12.2.json index a6c3c53f..e6edf80c 100644 --- a/docs/api/controls/BCD-12.2.json +++ b/docs/api/controls/BCD-12.2.json @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -140,13 +141,6 @@ "emea-eu-dora-2023": [ "Article 12.4" ], - "emea-isr-cmo-1-0": [ - "12.26", - "25.12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], "emea-gbr-def-stan-05-138-2024": [ "4202" ], diff --git a/docs/api/controls/BCD-12.3.json b/docs/api/controls/BCD-12.3.json index 0bdd2867..f33179d5 100644 --- a/docs/api/controls/BCD-12.3.json +++ b/docs/api/controls/BCD-12.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize electronic discovery (eDiscovery) that covers current and archived communication transactions.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/BCD-12.4.json b/docs/api/controls/BCD-12.4.json index 0f2f8187..47ef3bef 100644 --- a/docs/api/controls/BCD-12.4.json +++ b/docs/api/controls/BCD-12.4.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ Backups are performed ad-hoc and focus on business-critical Technology Assets, Applications, Services and/or Data (TAASD).\n▪ IT and/or cybersecurity personnel use a backup methodology (e.g., grandfather, father & son rotation) to create backups to support business needs (e.g., Recovery Time Objectives).", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restore TAASD within organization-defined restoration time-periods from configuration-controlled and integrity-protected information; representing a known, operational state for the asset.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restore TAASD within organization-defined restoration time-periods from configuration-controlled and integrity-protected information; representing a known, operational state for the asset. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/BCD-12.json b/docs/api/controls/BCD-12.json index bc99b281..55fa86c8 100644 --- a/docs/api/controls/BCD-12.json +++ b/docs/api/controls/BCD-12.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to ensure the secure recovery and reconstitution of Technology Assets, Applications and/or Services (TAAS) to a known state after a disruption, compromise or failure.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -153,7 +154,7 @@ "general-iec-62443-4-2-2019": [ "CR 7.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1485", "T1485.001", "T1486", @@ -194,6 +195,12 @@ "general-nist-800-82-r3-high": [ "CP-10" ], + "general-nist-800-172-r3": [ + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.04E[02]" + ], "general-nist-csf-2-0": [ "RC", "RC.RP-01", @@ -215,10 +222,10 @@ "CP-10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "CP-10" @@ -241,29 +248,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "CP-10" ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.3(83)" - ], "emea-eu-nis2-2022": [ "Article 21.2(c)" ], "emea-eu-nis2-annex-2024": [ "4.2.2(e)" ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.12", - "25.22" - ], "emea-sau-cscc-1-2019": [ "2-8-2" ], "emea-sau-cgiot-2024": [ "2-12-2" ], - "emea-sau-ecc-1-2018": [ - "2-4-3-3" - ], "emea-gbr-def-stan-05-138-2024": [ "4202" ], @@ -273,12 +269,19 @@ "apac-ind-sebi-2024": [ "PR.IP.S7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.45" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP17", "HML17" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP15" + ], + "americas-arg-ppd-2018": [ + "D.1.2-3", + "D.1.2-DS-4" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-13.1.json b/docs/api/controls/BCD-13.1.json index 087235e5..ffe59026 100644 --- a/docs/api/controls/BCD-13.1.json +++ b/docs/api/controls/BCD-13.1.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to verify the integrity of backups and other restoration assets prior to using them for restoration.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/BCD-13.json b/docs/api/controls/BCD-13.json index de144b30..bcd51717 100644 --- a/docs/api/controls/BCD-13.json +++ b/docs/api/controls/BCD-13.json @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -138,9 +139,8 @@ "4.2.2(e)", "4.2.3" ], - "emea-isr-cmo-1-0": [ - "25.12", - "25.18" + "americas-arg-ppd-2018": [ + "D.1.2-DS-4" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-14.json b/docs/api/controls/BCD-14.json index 70d855f9..c56b7e63 100644 --- a/docs/api/controls/BCD-14.json +++ b/docs/api/controls/BCD-14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize an isolated, non-production environment to perform data backup and recovery operations through offline, cloud or off-site capabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -89,6 +90,12 @@ ], "general-shared-assessments-sig-2025": [ "K.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.45" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-4" ] } } \ No newline at end of file diff --git a/docs/api/controls/BCD-15.json b/docs/api/controls/BCD-15.json index 190302b2..6055c0af 100644 --- a/docs/api/controls/BCD-15.json +++ b/docs/api/controls/BCD-15.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to purchase and maintain a sufficient reserve of spare hardware to ensure essential missions and business functions can be maintained in the event of a supply chain disruption.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -106,7 +107,7 @@ "RESPONSE-4c", "RESPONSE-4l" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1789" ] } diff --git a/docs/api/controls/BCD-16.json b/docs/api/controls/BCD-16.json index 3ee55b26..39bad371 100644 --- a/docs/api/controls/BCD-16.json +++ b/docs/api/controls/BCD-16.json @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/controls/CAP-01.json b/docs/api/controls/CAP-01.json index f195fbf6..42708fa4 100644 --- a/docs/api/controls/CAP-01.json +++ b/docs/api/controls/CAP-01.json @@ -22,7 +22,7 @@ "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to facilitate the implementation of capacity management controls to ensure optimal system performance to meet expected and anticipated future capacity requirements.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -78,7 +78,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -163,6 +164,12 @@ "general-nist-800-160-vol-2-r1": [ "SC-05(03)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -193,6 +200,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(1)" + ], "usa-federal-cms-marse-2-0": [ "SC-5" ], @@ -209,34 +219,23 @@ "SC-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(56)" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "3.5.56" ], "emea-deu-bsrit-2017": [ "8.8" ], "emea-deu-c5-2020": [ - "OPS-01", - "OPS-02", - "OPS-03" + "RB-01" ], - "emea-isr-cmo-1-0": [ - "25.2" + "emea-sau-otcc-1-2022": [ + "3-1-1", + "3-1-2" ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.4", + "mp.s.4" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.4 [OP.PL.4]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" @@ -255,7 +254,10 @@ "12.1.3.7", "12.1.3.8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP61", "HML61" ], @@ -263,14 +265,17 @@ "HSUP53" ], "apac-sgp-mas-trm-2021": [ - "8.1.1" + "6.4.8" ], "americas-bmu-mba-coc-2020": [ - "6.1" + "6.1-BP5" ], "americas-can-osfi-b13-2022": [ "2", "2.8.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.8.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/CAP-02.json b/docs/api/controls/CAP-02.json index 98e4bf2e..801cbd6a 100644 --- a/docs/api/controls/CAP-02.json +++ b/docs/api/controls/CAP-02.json @@ -22,7 +22,7 @@ "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to control resource utilization of Technology Assets, Applications and/or Services (TAAS) that are susceptible to Denial of Service (DoS) attacks to limit and prioritize the use of resources.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -97,7 +98,7 @@ "SC-05", "SC-06" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1564.009" ], "general-nist-800-53-r4": [ @@ -144,6 +145,12 @@ "general-nist-800-161-r1-level-2": [ "SC-5(2)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -182,10 +189,22 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-05" ], - "apac-aus-ism-2024-june": [ + "emea-isr-cmo-2-0": [ + "Appendix A, 7.1" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-92" + ], + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" + ], + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-sgp-mas-trm-2021": [ + "6.4.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/CAP-03.json b/docs/api/controls/CAP-03.json index 9444bab6..6c2b720e 100644 --- a/docs/api/controls/CAP-03.json +++ b/docs/api/controls/CAP-03.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", - "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support will exist during contingency operations.", + "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support will exist during contingency operations. ", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -160,6 +161,12 @@ "general-nist-800-161-r1-level-3": [ "CP-2(2)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -206,20 +213,20 @@ "8.8" ], "emea-deu-c5-2020": [ - "OPS-01", - "OPS-02", - "OPS-03" + "RB-01", + "RB-01-DOAR" ], - "emea-isr-cmo-1-0": [ - "25.2" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.4", + "mp.s.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" ], - "apac-sgp-mas-trm-2021": [ - "8.1.3" + "apac-mys-bnm-rmit-2025": [ + "10.29" ], "americas-can-osfi-b13-2022": [ "2.8.2" diff --git a/docs/api/controls/CAP-04.json b/docs/api/controls/CAP-04.json index d47e5f9b..2fdf8ea2 100644 --- a/docs/api/controls/CAP-04.json +++ b/docs/api/controls/CAP-04.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to automatically centrally-monitor and alert on the operating state and health status of critical Technology Assets, Applications and/or Services (TAAS).", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -84,7 +84,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -100,14 +101,24 @@ "emea-deu-bsrit-2017": [ "8.8" ], + "emea-deu-c5-2020": [ + "RB-02" + ], "apac-ind-sebi-2024": [ "DE.CM.S4" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" + "apac-mys-bnm-rmit-2025": [ + "10.30", + "10.39" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.3" ], "americas-can-osfi-b13-2022": [ "2.8.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.8.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/CAP-05.json b/docs/api/controls/CAP-05.json index cd21d2f0..08dddc3c 100644 --- a/docs/api/controls/CAP-05.json +++ b/docs/api/controls/CAP-05.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to automatically scale the resources available for Technology Assets, Applications and/or Services (TAAS), as demand conditions change.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -79,7 +79,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -92,8 +93,17 @@ "usa-federal-dow-zt-roadmap-1-1": [ "7.1.1" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "RB-02" + ], + "apac-aus-ism-2026-march": [ "ISM-1579" + ], + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/CAP-06.json b/docs/api/controls/CAP-06.json index ba21d445..261599e8 100644 --- a/docs/api/controls/CAP-06.json +++ b/docs/api/controls/CAP-06.json @@ -20,7 +20,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to support operations that are geographically dispersed via regional delivery of technological Technology Assets, Applications and/or Services (TAAS).", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -75,7 +75,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { diff --git a/docs/api/controls/CFG-01.1.json b/docs/api/controls/CFG-01.1.json index 3831b4da..2dc7feb8 100644 --- a/docs/api/controls/CFG-01.1.json +++ b/docs/api/controls/CFG-01.1.json @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -115,6 +116,10 @@ "general-pci-dss-4-0-1": [ "2.1" ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" + ], "apac-nzl-ism-3-9": [ "4.3.19.C.01" ] diff --git a/docs/api/controls/CFG-01.json b/docs/api/controls/CFG-01.json index 1d6da749..a43deeec 100644 --- a/docs/api/controls/CFG-01.json +++ b/docs/api/controls/CFG-01.json @@ -23,7 +23,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to facilitate the implementation of configuration management controls.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -102,7 +102,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -116,8 +117,8 @@ "CC8.1-POF12" ], "general-cis-csc-8-1": [ - "2.0", - "4.0", + "2", + "4", "4.1", "4.2" ], @@ -247,9 +248,11 @@ "NFO - CM-9" ], "general-nist-800-171-r3": [ - "03.04.01.a" + "03.04.01.a", + "03.04.03.a" ], "general-nist-800-171a-r3": [ + "A.03.04.01.a[02]", "A.03.04.03.a" ], "general-nist-800-207": [ @@ -268,9 +271,6 @@ "2.2", "8.5" ], - "general-scf-dpmp-2025": [ - "7.12" - ], "general-sparta": [ "CM0023" ], @@ -310,10 +310,10 @@ "CM-09" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "CM-1", @@ -361,56 +361,19 @@ "6.3.1", "6.3.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "6.8" - ], - "emea-deu-c5-2020": [ - "AM-03" - ], - "emea-isr-cmo-1-0": [ - "3.3", - "9.22", - "9.23", - "14.1" - ], "emea-sau-cscc-1-2019": [ "2-3-1-6" ], - "emea-sau-ecc-1-2018": [ - "1-6-2-2", - "2-4-4", - "2-5-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 30.1", - "Article 30.2" - ], - "emea-esp-decree-311-2022": [ - "30.1", - "30.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.3 [OP.EXP.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-caf-4-0": [ "B4", "B4.c" ], - "emea-gbr-cap-1850-2020": [ - "B4" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "apac-aus-ism-2026-march": [ + "ISM-0912" ], "apac-ind-sebi-2024": [ "PR.IP.S3" @@ -421,29 +384,28 @@ "12.2.5.C.02", "12.2.6.C.01", "12.2.6.C.02", + "17.9.38.C.03", "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", - "18.1.10.C.04" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)" + "18.1.10.C.04", + "20.2.14.C.02" ], "apac-sgp-mas-trm-2021": [ - "7.2.1", - "7.2.2", - "7.3.1", - "7.3.2", - "7.3.3" + "7.2.1" ], "americas-bmu-mba-coc-2020": [ - "6.1" + "6.1-BP1" ], "americas-can-osfi-b13-2022": [ "3.2.8" ], "americas-can-itsp-10-171-2025": [ - "03.04.01.A" + "03.04.01.A", + "03.04.03.A" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(c)" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-02.1.json b/docs/api/controls/CFG-02.1.json index 104bfe4c..fcd0259a 100644 --- a/docs/api/controls/CFG-02.1.json +++ b/docs/api/controls/CFG-02.1.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to review and update baseline configurations:\n(1) At least annually;\n(2) When required due to so; or\n(3) As part of system component installations and upgrades.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -190,7 +191,7 @@ ], "general-nist-800-171-r3": [ "03.04.01.b", - "03.04.02.b" + "03.04.06.c" ], "general-nist-800-171a-r3": [ "A.03.04.01.ODP[01]", @@ -269,24 +270,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-02" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.46" + ], "emea-eu-nis2-annex-2024": [ "6.3.3" ], - "emea-isr-cmo-1-0": [ - "3.3", - "14.3" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-6" + "2-3-1-6", + "2-4-1-2" ], "emea-sau-cgiot-2024": [ "2-14-4" ], "emea-sau-ecc-1-2018": [ - "1-6-2-2" + "5-1-3-7" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-def-stan-05-138-2024": [ "2418" @@ -305,19 +307,19 @@ "ML3-P5", "ML3-P6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1407", "ISM-1588" ], "apac-ind-sebi-2024": [ "PR.IP.S1" ], - "apac-sgp-mas-trm-2021": [ - "11.2.5" + "apac-nzl-ism-3-9": [ + "15.2.45.C.01" ], "americas-can-itsp-10-171-2025": [ "03.04.01.B", - "03.04.02.B" + "03.04.06.C" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-02.2.json b/docs/api/controls/CFG-02.2.json index 4ecee7ed..b681c823 100644 --- a/docs/api/controls/CFG-02.2.json +++ b/docs/api/controls/CFG-02.2.json @@ -20,7 +20,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically govern and report on baseline configurations of Technology Assets, Applications and/or Services (TAAS) through Continuous Diagnostics and Mitigation (CDM), or similar technologies.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -62,7 +62,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -153,14 +154,23 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.d" + "03.04.03.d", + "03.13.13.b" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", "A.03.04.03.d[01]", - "A.03.04.03.d[02]" + "A.03.04.03.d[02]", + "A.03.13.13.b[02]" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-172-r3": [ + "03.04.02E", + "03.04.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.04.02E.ODP[03]", + "DS-A.03.04.03E[01]", + "A.03.04.04E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -209,20 +219,17 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.c" ], - "emea-isr-cmo-1-0": [ - "3.3", - "6.2", - "6.4", - "9.22", - "9.23", - "14.3", - "14.4" + "emea-sau-cscc-1-2019": [ + "2-3-1-6" + ], + "emea-sau-ecc-1-2018": [ + "5-1-3-7" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.2" + "emea-sau-otcc-1-2022": [ + "2-3-1-11" ], "emea-esp-decree-311-2022": [ - "21.2" + "Article 21(2)" ], "emea-gbr-def-stan-05-138-2024": [ "2415" @@ -230,16 +237,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2415" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)", - "4.3(b)" - ], "apac-sgp-mas-trm-2021": [ + "7.2.2", "11.3.2" ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.D" + "03.04.03.D", + "03.13.13.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-02.3.json b/docs/api/controls/CFG-02.3.json index 3c376e33..c2ba5f8b 100644 --- a/docs/api/controls/CFG-02.3.json +++ b/docs/api/controls/CFG-02.3.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Historical versions of configurations are maintained for troubleshooting and forensics purposes.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -118,6 +119,13 @@ "general-nist-800-82-r3-high": [ "CM-02(03)" ], + "general-nist-800-172-r3": [ + "03.04.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.06E", + "A.03.04.06E.ODP[01]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.UNI.BRECO" ], @@ -139,10 +147,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-02 (03)" ], - "emea-isr-cmo-1-0": [ - "14.5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1510" ] } diff --git a/docs/api/controls/CFG-02.4.json b/docs/api/controls/CFG-02.4.json index 8e02f940..1f159e68 100644 --- a/docs/api/controls/CFG-02.4.json +++ b/docs/api/controls/CFG-02.4.json @@ -20,7 +20,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to manage baseline configurations for development and test environments separately from operational baseline configurations to minimize the risk of unintentional changes.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -141,18 +142,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-isr-cmo-1-0": [ - "10.1", - "10.2" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], "apac-nzl-ism-3-9": [ "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", "18.1.10.C.04" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-02.5.json b/docs/api/controls/CFG-02.5.json index 57428ab0..0fecce43 100644 --- a/docs/api/controls/CFG-02.5.json +++ b/docs/api/controls/CFG-02.5.json @@ -28,11 +28,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) utilized in high-risk areas with more restrictive baseline configurations.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -196,13 +197,17 @@ "03.04.01.a", "03.04.02.a", "03.04.06.a", - "03.04.06.b", "03.04.06.d", "03.04.12.a" ], "general-nist-800-171a-r3": [ + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.d", "A.03.04.12.ODP[01]", - "A.03.04.12.ODP[02]" + "A.03.04.12.ODP[02]", + "A.03.04.12.a" ], "general-nist-800-218": [ "PO.5.2" @@ -320,6 +325,9 @@ "usa-federal-gsa-fedramp-5-high": [ "CM-02(07)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(2)" + ], "usa-federal-irs-1075-2021": [ "CM-2(CE-7)", "CM-2(CE-7).a", @@ -335,37 +343,16 @@ "emea-eu-ai-act-2024": [ "Article 14.3(a)" ], - "emea-isr-cmo-1-0": [ - "4.12", - "9.21", - "10.7" - ], "emea-sau-cscc-1-2019": [ - "1-3-2-3", - "2-3-1-7" + "2-6-1-3" ], "emea-sau-ecc-1-2018": [ + "5-1-3-5", + "5-1-3-6", "5-1-3-7" ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" - ], - "emea-gbr-cap-1850-2020": [ - "B4" + "2-2-1-5" ], "emea-gbr-def-stan-05-138-2024": [ "2312" @@ -379,7 +366,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2312" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0534", "ISM-1656", "ISM-1657", @@ -395,18 +382,24 @@ "ISM-1674", "ISM-1675", "ISM-1676", - "ISM-1677", "ISM-1748", "ISM-1749", - "ISM-1800" + "ISM-1800", + "ISM-1867", + "ISM-1868" ], "apac-nzl-ism-3-9": [ + "15.2.38.C.01", "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", "18.1.10.C.04", "23.2.21.C.01" ], + "americas-arg-ppd-2018": [ + "E.1.2-2", + "E.1.2-DS-1" + ], "americas-can-osfi-b13-2022": [ "3.2.3" ], @@ -414,9 +407,9 @@ "03.04.01.A", "03.04.02.A", "03.04.06.A", - "03.04.06.B", "03.04.06.D", - "03.04.12.A" + "03.04.12.A", + "03.14.08.C" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-02.6.json b/docs/api/controls/CFG-02.6.json index 2a759337..6e2e4a8c 100644 --- a/docs/api/controls/CFG-02.6.json +++ b/docs/api/controls/CFG-02.6.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -94,9 +95,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.2.8" ], - "emea-isr-cmo-1-0": [ - "9.22" - ], "apac-nzl-ism-3-9": [ "18.1.10.C.01", "18.1.10.C.02", diff --git a/docs/api/controls/CFG-02.7.json b/docs/api/controls/CFG-02.7.json index eb9ea29b..7333706c 100644 --- a/docs/api/controls/CFG-02.7.json +++ b/docs/api/controls/CFG-02.7.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Any deviations from approved baseline configurations are reviewed, approved and documented on a case-by-case basis by IT and/or cybersecurity personnel.\n▪ Deviations to baseline configurations are required to have a risk assessment and the business process owner's acceptance of the risk(s) associated with the deviation.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to document, assess risk and approve or deny deviations to standardized configurations.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -162,12 +163,9 @@ "03.04.02.b" ], "general-nist-800-171a-r3": [ - "A.03.04.02.b[01]", + "A.03.04.01.a[01]", "A.03.04.02.b[02]" ], - "general-nist-800-172": [ - "3.5.2e" - ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -216,8 +214,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-06" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(c)" + "apac-sgp-mas-trm-2021": [ + "11.3.2" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.8" ], "americas-can-itsp-10-171-2025": [ "03.04.01.A", diff --git a/docs/api/controls/CFG-02.8.json b/docs/api/controls/CFG-02.8.json index be4609b4..d95ced7b 100644 --- a/docs/api/controls/CFG-02.8.json +++ b/docs/api/controls/CFG-02.8.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to verify the functionality of security controls when anomalies or misconfigurations are discovered.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 3 Advanced Threats", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -132,8 +133,12 @@ "general-nist-800-161-r1-level-3": [ "CM-6(2)" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.b", + "A.03.04.02E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -167,10 +172,6 @@ ], "emea-sau-otcc-1-2022": [ "2-3-1-11" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-02.9.json b/docs/api/controls/CFG-02.9.json index e7118247..a0aafaf4 100644 --- a/docs/api/controls/CFG-02.9.json +++ b/docs/api/controls/CFG-02.9.json @@ -19,11 +19,11 @@ }, "maturity": { "0": "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.", - "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment.\n▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices.", + "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment.\n▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.\n▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to allow baseline controls to be specialized or customized by applying a defined set of tailoring actions that are specific to:\n(1) Mission / business functions;\n(2) Operational environment;\n(3) Specific threats or vulnerabilities; or\n(4) Other conditions or situations that could affect mission / business success.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -138,7 +139,14 @@ "03.13.11" ], "general-nist-800-171a-r3": [ - "A.03.03.02.b" + "A.03.03.02.b", + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.06.a", + "A.03.04.08.a", + "A.03.04.12.a", + "A.03.13.11" ], "general-shared-assessments-sig-2025": [ "N.11" @@ -195,12 +203,6 @@ "PL-11-SID.1", "PL-11-SID.2" ], - "emea-isr-cmo-1-0": [ - "10.7" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-7" - ], "emea-gbr-def-stan-05-138-2024": [ "2418" ], @@ -217,10 +219,6 @@ "9.5.2.P", "9.5.2.1.PB" ], - "apac-nzl-ism-3-9": [ - "16.1.50.C.01", - "16.1.50.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.03.02.B", "03.04.01.A", diff --git a/docs/api/controls/CFG-02.json b/docs/api/controls/CFG-02.json index ab012179..b09f6296 100644 --- a/docs/api/controls/CFG-02.json +++ b/docs/api/controls/CFG-02.json @@ -29,9 +29,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -126,6 +127,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -150,6 +152,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -164,6 +167,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -262,7 +266,7 @@ "8.25", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -745,6 +749,7 @@ ], "general-nist-800-171-r3": [ "03.01.01.h", + "03.01.03", "03.01.08.a", "03.01.08.b", "03.01.09", @@ -754,16 +759,22 @@ "03.01.11", "03.01.12.a", "03.01.16.a", + "03.01.16.c", "03.01.18.a", + "03.03.08.a", "03.04.01.a", "03.04.02.a", + "03.04.02.b", "03.04.06.a", "03.04.06.b", "03.04.06.d", + "03.05.04", + "03.05.07.c", "03.05.07.d", "03.05.07.e", "03.05.07.f", "03.05.12.d", + "03.07.05.b", "03.08.07.a", "03.13.12.b" ], @@ -775,7 +786,17 @@ "3.4.2[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.08.a", + "A.03.01.08.b", + "A.03.01.09", + "A.03.01.10.a", + "A.03.01.10.b", + "A.03.01.10.c", + "A.03.01.11", + "A.03.01.12.a[03]", "A.03.01.16.a[03]", "A.03.01.16.c", "A.03.01.18.a[02]", @@ -789,18 +810,48 @@ "A.03.04.06.ODP[03]", "A.03.04.06.ODP[04]", "A.03.04.06.ODP[05]", + "A.03.04.06.a", "A.03.04.06.b[01]", "A.03.04.06.b[02]", "A.03.04.06.b[03]", "A.03.04.06.b[04]", "A.03.04.06.b[05]", + "A.03.04.06.d", "A.03.05.04[01]", "A.03.05.04[02]", "A.03.05.07.c", "A.03.05.07.d", "A.03.05.07.e", "A.03.05.07.f", - "A.03.07.05.b[02]" + "A.03.05.12.d", + "A.03.07.05.b[01]", + "A.03.08.07.a", + "A.03.13.12.b" + ], + "general-nist-800-172-r3": [ + "03.01.04E", + "03.01.14E", + "03.01.16E", + "03.05.01E", + "03.05.05E", + "03.12.04E", + "03.13.06E", + "03.13.11E", + "03.13.13E", + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.04E.ODP[01]", + "A.03.01.14E.ODP[03]", + "A.03.01.14E.ODP[04]", + "DS-A.03.01.16E", + "A.03.05.01E.ODP[01]", + "DS-A.03.05.05E", + "DS-A.03.12.04E.c", + "A.03.13.06E.ODP[01]", + "DS-A.03.13.11E[02]", + "A.03.13.13E.ODP[01]", + "A.03.14.11E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -915,9 +966,6 @@ "10.6.2", "10.6.3" ], - "general-scf-dpmp-2025": [ - "7.12" - ], "general-shared-assessments-sig-2025": [ "N.11" ], @@ -1020,20 +1068,24 @@ "SA-08", "SA-15(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(2)", + "101.650(c)(2)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "3.3.8.b", @@ -1169,7 +1221,7 @@ "Article 17.1(e)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(b)" + "3.4.4.36(b)" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -1190,28 +1242,37 @@ "6.8" ], "emea-deu-c5-2020": [ - "AM-02", - "AM-03", - "OPS-23" - ], - "emea-isr-cmo-1-0": [ - "3.3", - "4.9", - "4.12", - "4.15", - "6.1", - "9.21", - "12.13", - "12.24", - "12.29", - "13.5", - "13.6", - "14.2", - "15.6" + "RB-05", + "RB-22", + "RB-22-DOAR", + "IDM-11", + "IDM-11-BP1", + "IDM-11-BP2", + "IDM-11-BP3", + "IDM-11-BP4", + "IDM-11-BP5", + "IDM-11-DOAR", + "IDM-11-DOAR-BP1", + "IDM-11-DOAR-BP2", + "IDM-11-DOAR-BP3", + "IDM-11-DOAR-BP4", + "IDM-11-DOAR-BP5", + "IDM-11-DOAR-BP6", + "IDM-11-DOAR-BP7" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 3.1", + "Appendix A, 4.1", + "Appendix A, 4.2" ], "emea-sau-cscc-1-2019": [ "1-3-2-3", - "2-3-1-7" + "2-2-1-5", + "2-2-1-6", + "2-3-1-6", + "2-3-1-7", + "2-4-1-3", + "2-12-1" ], "emea-sau-cgiot-2024": [ "1-2-2", @@ -1222,36 +1283,47 @@ ], "emea-sau-ecc-1-2018": [ "1-3-3", - "2-4-1", - "2-4-2", - "5-1-3-7" + "2-4-1" ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-1", - "2-3-1-7" + "2-2-1-8", + "2-4-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 20(d)" + "VII.A.TPC-2", + "VII.A.TPC-2-BP1", + "VII.A.TPC-2-BP2", + "VII.A.TPC-2-BP3", + "VII.A.TPC-2-BP4", + "VII.A.TPC-2-BP5", + "VII.A.TPC-10", + "VII.B.TPC-56", + "VII.B.TPC-62", + "VII.B.TPC-63", + "VII.B.TPC-63-BP1", + "VII.B.TPC-63-BP2", + "VII.B.TPC-63-BP3", + "VII.B.TPC-63-BP4" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.6", + "3.3.6.1", + "3.3.13.4.c.2" ], "emea-esp-decree-311-2022": [ - "20(d)" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.2 [OP.EXP.2]" + "Article 12(7)", + "Article 20(a)", + "Article 20(c)", + "Article 20(d)", + "Single Transitional Provision(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "op.exp.2", + "op.exp.3", + "mp.sw.1", + "mp.info.4", + "mp.s.2" ], "emea-uae-niaf-2023": [ "3.2.1" @@ -1260,11 +1332,9 @@ "B4", "B4.b" ], - "emea-gbr-cap-1850-2020": [ - "B4" - ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "2-BP3", + "2-BP4" ], "emea-gbr-def-stan-05-138-2024": [ "2204", @@ -1305,7 +1375,7 @@ "ML3-P6", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0341", "ISM-0343", "ISM-0345", @@ -1334,7 +1404,79 @@ "ISM-1654", "ISM-1655", "ISM-1710", - "ISM-1745" + "ISM-1745", + "ISM-1823", + "ISM-1824", + "ISM-1825", + "ISM-1828", + "ISM-1829", + "ISM-1830", + "ISM-1836", + "ISM-1838", + "ISM-1839", + "ISM-1840", + "ISM-1841", + "ISM-1844", + "ISM-1846", + "ISM-1858", + "ISM-1859", + "ISM-1860", + "ISM-1861", + "ISM-1870", + "ISM-1871", + "ISM-1886", + "ISM-1887", + "ISM-1888", + "ISM-1890", + "ISM-1891", + "ISM-1896", + "ISM-1897", + "ISM-1913", + "ISM-1914", + "ISM-1915", + "ISM-1916", + "ISM-1928", + "ISM-1929", + "ISM-1930", + "ISM-1931", + "ISM-1932", + "ISM-1933", + "ISM-1934", + "ISM-1935", + "ISM-1936", + "ISM-1938", + "ISM-1943", + "ISM-1944", + "ISM-1945", + "ISM-1946", + "ISM-1947", + "ISM-1948", + "ISM-1949", + "ISM-1950", + "ISM-1951", + "ISM-1952", + "ISM-1953", + "ISM-1954", + "ISM-1955", + "ISM-1956", + "ISM-1957", + "ISM-1958", + "ISM-1962", + "ISM-1980", + "ISM-1984", + "ISM-2010", + "ISM-2012", + "ISM-2047", + "ISM-2049", + "ISM-2079", + "ISM-2080", + "ISM-2081", + "ISM-2096", + "ISM-2097", + "ISM-2098" + ], + "apac-aus-cop-sitc-2020": [ + "6" ], "apac-ind-sebi-2024": [ "PR.IP.S1" @@ -1342,7 +1484,7 @@ "apac-jpn-ismap": [ "8.3.1.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP54", "HHSP60", "HHSP65", @@ -1351,40 +1493,84 @@ "HML60", "HML64" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP14", "HSUP46", "HSUP52" ], "apac-nzl-ism-3-9": [ + "11.1.16.C.01", + "11.1.16.C.02", + "11.1.17.C.01", + "11.1.17.C.03", + "11.8.6.C.01", + "11.8.6.C.02", "14.1.8.C.01", "14.1.9.C.01", "14.1.9.C.02", "14.1.10.C.01", "14.1.10.C.02", "14.3.7.C.01", + "15.2.41.C.01", + "15.2.41.C.02", + "15.2.42.C.01", + "15.2.43.C.01", + "15.2.44.C.01", + "15.2.46.C.01", + "15.2.46.C.03", + "15.2.47.C.01", + "15.2.47.C.02", + "15.2.48.C.01", + "15.2.48.C.02", + "15.2.48.C.03", + "15.2.49.C.01", + "15.2.49.C.02", + "15.2.49.C.03", + "15.2.50.C.01", + "15.2.50.C.02", + "15.2.50.C.03", + "15.2.50.C.04", + "16.1.31.C.03", + "16.1.31.C.04", + "16.1.31.C.05", + "16.7.42.C.01", + "20.2.14.C.05", + "20.2.14.C.07", + "22.1.16.C.01", + "22.1.16.C.02", + "22.1.17.C.01", + "22.1.17.C.02", + "22.1.17.C.03", + "22.1.19.C.01", + "22.1.19.C.02", "23.2.21.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)" + "4.3(a)", + "4.3(b)" ], "apac-sgp-mas-trm-2021": [ - "11.2.5", - "11.3.1", - "11.3.2" + "6.4.4", + "7.2.2", + "11.1.5", + "11.3.1" ], - "amaericas-can-osfi-self-assessment": [ - "4.16", - "4.20" + "americas-arg-ppd-2018": [ + "B.2.4-4", + "E.1.2-5" + ], + "americas-bmu-mba-coc-2020": [ + "6.15-BP5" ], "americas-can-osfi-b13-2022": [ "3.2.8" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.8" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", + "03.01.03", "03.01.08.A", "03.01.08.B", "03.01.09", @@ -1394,16 +1580,22 @@ "03.01.11", "03.01.12.A", "03.01.16.A", + "03.01.16.C", "03.01.18.A", + "03.03.08.A", "03.04.01.A", "03.04.02.A", + "03.04.02.B", "03.04.06.A", "03.04.06.B", "03.04.06.D", + "03.05.04", + "03.05.07.C", "03.05.07.D", "03.05.07.E", "03.05.07.F", "03.05.12.D", + "03.07.05.B", "03.08.07.A", "03.13.12.B" ] diff --git a/docs/api/controls/CFG-03.1.json b/docs/api/controls/CFG-03.1.json index 9155d009..90c0d3bc 100644 --- a/docs/api/controls/CFG-03.1.json +++ b/docs/api/controls/CFG-03.1.json @@ -20,7 +20,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to periodically review system configurations to identify and disable unnecessary and/or non-secure functions, ports, protocols and services.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -169,7 +170,9 @@ "3.4.7[o]" ], "general-nist-800-171a-r3": [ - "A.03.04.06.ODP[06]" + "A.03.04.06.ODP[06]", + "A.03.04.06.c", + "A.03.04.08.c" ], "general-pci-dss-4-0-1": [ "1.2.7", @@ -238,11 +241,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (01)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.2" - ], - "emea-esp-decree-311-2022": [ - "21.2" + "emea-sau-otcc-1-2022": [ + "2-3-1-2" ], "emea-gbr-def-stan-05-138-2024": [ "2430", diff --git a/docs/api/controls/CFG-03.2.json b/docs/api/controls/CFG-03.2.json index eee52eb3..731b90fe 100644 --- a/docs/api/controls/CFG-03.2.json +++ b/docs/api/controls/CFG-03.2.json @@ -21,9 +21,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the execution of unauthorized software programs.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the execution of unauthorized software programs. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -138,6 +139,9 @@ "general-nist-800-171-r3": [ "03.04.08.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.08.b" + ], "general-nist-csf-2-0": [ "PR.PS-05" ], @@ -168,17 +172,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (02)" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], "apac-aus-essential-8-2024": [ "ML2-P5", "ML3-P5" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.04.08.B" ] diff --git a/docs/api/controls/CFG-03.3.json b/docs/api/controls/CFG-03.3.json index 70a6f2b8..904262a8 100644 --- a/docs/api/controls/CFG-03.3.json +++ b/docs/api/controls/CFG-03.3.json @@ -22,7 +22,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to explicitly allow (allowlist / whitelist) and/or block (denylist / blacklist) applications that are authorized to execute on systems.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -191,8 +192,17 @@ "A.03.04.08.ODP[01]", "A.03.04.08.a", "A.03.04.08.b", + "A.03.13.13.a[01]", + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", "A.03.13.13.b[03]" ], + "general-nist-800-172-r3": [ + "03.13.06E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.06E.ODP[01]" + ], "general-sparta": [ "CM0047", "CM0069" @@ -241,12 +251,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (05)" ], - "emea-deu-c5-2020": [ - "AM-02" - ], - "emea-isr-cmo-1-0": [ - "6.7" - ], "emea-sau-cscc-1-2019": [ "2-3-1-1" ], @@ -257,7 +261,9 @@ "2-3-1-6" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5-BP2", + "5-BP2-1", + "5-BP2-2" ], "emea-gbr-def-stan-05-138-2024": [ "2409" @@ -276,7 +282,7 @@ "ML2-P5", "ML3-P5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-1235", @@ -295,15 +301,12 @@ "14.2.7.C.04", "14.2.7.C.05", "14.2.7.C.06", - "14.2.7.C.07" + "14.2.7.C.07", + "21.3.12.C.02" ], "apac-sgp-mas-trm-2021": [ "11.3.6" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.08.B", diff --git a/docs/api/controls/CFG-03.4.json b/docs/api/controls/CFG-03.4.json index e91f9eae..0a81ec91 100644 --- a/docs/api/controls/CFG-03.4.json +++ b/docs/api/controls/CFG-03.4.json @@ -3,7 +3,7 @@ "title": "Split Tunneling", "family": "CFG", "description": "Mechanisms exist to prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards.", - "scf_question": "Does the organization prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?\n\nPrevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?", + "scf_question": "Does the organization prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -20,7 +20,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -152,10 +153,6 @@ "usa-federal-cms-marse-2-0": [ "SC-7(7)" ], - "emea-isr-cmo-1-0": [ - "4.15", - "9.13" - ], "emea-gbr-def-stan-05-138-2024": [ "2305" ], @@ -168,7 +165,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2305" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0705" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/CFG-03.json b/docs/api/controls/CFG-03.json index f0c7d2b4..d20e36f4 100644 --- a/docs/api/controls/CFG-03.json +++ b/docs/api/controls/CFG-03.json @@ -29,9 +29,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to provide only essential capabilities by specifically prohibiting or restricting the use of ports, protocols, and/or services.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to provide only essential capabilities by specifically prohibiting or restricting the use of ports, protocols, and/or services. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -112,7 +113,7 @@ "CC6.7-POF1" ], "general-cis-csc-8-1": [ - "4.0", + "4", "4.6", "4.8" ], @@ -167,7 +168,7 @@ "8.9", "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -450,7 +451,15 @@ ], "general-nist-800-171a-r3": [ "A.03.04.02.ODP[01]", - "A.03.04.06.d" + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.b[01]", + "A.03.04.06.b[02]", + "A.03.04.06.b[03]", + "A.03.04.06.b[04]", + "A.03.04.06.b[05]", + "A.03.04.06.d", + "A.03.04.08.a" ], "general-nist-csf-2-0": [ "PR.PS-05" @@ -557,30 +566,18 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(f)" ], - "emea-isr-cmo-1-0": [ - "4.8", - "4.9", - "12.9", - "12.13" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-5" - ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-4" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 20(a)", - "Article 20(b)", - "Article 20(c)", - "Article 20(d)" + "2-4-1-14" ], "emea-esp-decree-311-2022": [ - "20(a)", - "20(b)", - "20(c)", - "20(d)" + "Article 20(c)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2204", @@ -601,7 +598,7 @@ "2430", "2507" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0385", "ISM-1006", "ISM-1311", @@ -613,15 +610,24 @@ "ISM-1489", "ISM-1621" ], + "apac-aus-cop-sitc-2020": [ + "6" + ], "apac-ind-sebi-2024": [ "PR.IP.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], "apac-nzl-ism-3-9": [ "18.1.15.C.01", "18.1.15.C.02", "18.1.15.C.03", "18.1.15.C.04" ], + "apac-sgp-mas-trm-2021": [ + "11.2.6" + ], "americas-can-osfi-b13-2022": [ "3.2.8" ], diff --git a/docs/api/controls/CFG-04.1.json b/docs/api/controls/CFG-04.1.json index 42ac672d..82de03ab 100644 --- a/docs/api/controls/CFG-04.1.json +++ b/docs/api/controls/CFG-04.1.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to establish parameters for the secure use of open source software.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to establish parameters for the secure use of open source software. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -129,12 +130,19 @@ "general-nist-800-171-r3": [ "03.13.13.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], "usa-federal-cms-marse-2-0": [ "CM-10(1)", "CM-10(1).a", "CM-10(1).b", "CM-10(1).c" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-sgp-mas-trm-2021": [ "6.1.3" ], diff --git a/docs/api/controls/CFG-04.2.json b/docs/api/controls/CFG-04.2.json index e9aab7e1..c90bd17b 100644 --- a/docs/api/controls/CFG-04.2.json +++ b/docs/api/controls/CFG-04.2.json @@ -20,7 +20,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to allow only approved Internet browsers and email clients to run on systems.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -96,7 +97,7 @@ "CC6.7" ], "general-cis-csc-8-1": [ - "9.0", + "9", "9.1", "9.4" ], @@ -111,11 +112,7 @@ "9.1", "9.4" ], - "emea-sau-ecc-1-2018": [ - "2-4-1", - "2-5-3-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0824", "ISM-1235", "ISM-1412", @@ -127,10 +124,6 @@ "ISM-1601", "ISM-1654", "ISM-1655" - ], - "amaericas-can-osfi-self-assessment": [ - "4.6", - "4.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-04.json b/docs/api/controls/CFG-04.json index 0b08cf5c..679728a2 100644 --- a/docs/api/controls/CFG-04.json +++ b/docs/api/controls/CFG-04.json @@ -20,7 +20,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to enforce software usage restrictions to comply with applicable contract agreements and copyright laws.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -107,7 +108,7 @@ "general-govramp-high": [ "CM-10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1546.008", "T1546.013", "T1550.001", @@ -154,6 +155,11 @@ "general-nist-800-171-r3": [ "03.13.13.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", + "A.03.13.13.b[03]" + ], "general-tisax-6-0-3": [ "1.3.4" ], @@ -190,8 +196,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-10" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "apac-sgp-mas-trm-2021": [ + "6.1.3" ], "americas-can-itsp-10-171-2025": [ "03.13.13.B" diff --git a/docs/api/controls/CFG-05.1.json b/docs/api/controls/CFG-05.1.json index 33b82117..ebc27994 100644 --- a/docs/api/controls/CFG-05.1.json +++ b/docs/api/controls/CFG-05.1.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Secure baseline configurations generate logs that contain sufficient information to establish necessary details of activity and allow for forensics analysis.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to generate an alert when the unauthorized installation of software is detected.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to generate an alert when the unauthorized installation of software is detected. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -124,6 +125,12 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.b" + ], "usa-federal-fbi-cjis-6-0": [ "CM-8(3)" ], @@ -148,13 +155,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.c" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-05.2.json b/docs/api/controls/CFG-05.2.json index 4ee73111..7e8128df 100644 --- a/docs/api/controls/CFG-05.2.json +++ b/docs/api/controls/CFG-05.2.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the installation of software, unless the action is performed by a privileged user or service.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -140,10 +141,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(02)" ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0382", "ISM-1592" ], @@ -158,10 +156,6 @@ "12.6.2.2", "12.6.2.3", "12.6.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-05.json b/docs/api/controls/CFG-05.json index 3baabdc0..6d64d1e3 100644 --- a/docs/api/controls/CFG-05.json +++ b/docs/api/controls/CFG-05.json @@ -24,7 +24,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to restrict the ability of non-privileged users to install unauthorized software.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -117,7 +118,7 @@ "general-govramp-high": [ "CM-11" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.005", "T1059", "T1059.006", @@ -201,6 +202,10 @@ "3.4.9[b]", "3.4.9[c]" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], "general-nist-csf-2-0": [ "PR.PS-05" ], @@ -250,21 +255,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-11" ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0382", "ISM-1592", "ISM-1655" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.13.13.B" ] diff --git a/docs/api/controls/CFG-06.1.json b/docs/api/controls/CFG-06.1.json index a41f3971..eb0404a1 100644 --- a/docs/api/controls/CFG-06.1.json +++ b/docs/api/controls/CFG-06.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically identify unauthorized deviations from an approved baseline and implement automated resiliency actions to remediate the unauthorized change.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87,7 +87,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -121,9 +122,11 @@ "CM-03(08)", "CM-11(03)" ], - "general-nist-800-172": [ - "3.4.2e", - "3.14.7e" + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -143,7 +146,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-0955", @@ -155,10 +158,6 @@ ], "apac-ind-sebi-2024": [ "PR.DS.S6" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-06.json b/docs/api/controls/CFG-06.json index 1ab168b9..eddd3363 100644 --- a/docs/api/controls/CFG-06.json +++ b/docs/api/controls/CFG-06.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically monitor, enforce and report on configurations for endpoint devices.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -89,7 +89,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -121,8 +122,10 @@ "03.04.02.b", "03.04.03.a" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-171a-r3": [ + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.03.a" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -142,7 +145,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-0955", @@ -155,9 +158,8 @@ "apac-ind-sebi-2024": [ "PR.DS.S6" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(b)" ], "americas-can-itsp-10-171-2025": [ "03.04.02.A", diff --git a/docs/api/controls/CFG-07.json b/docs/api/controls/CFG-07.json index a5d490f2..8c5a6336 100644 --- a/docs/api/controls/CFG-07.json +++ b/docs/api/controls/CFG-07.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to implement Zero-Touch Provisioning (ZTP), or similar technology, to automatically and securely configure devices upon being added to a network.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { diff --git a/docs/api/controls/CFG-08.1.json b/docs/api/controls/CFG-08.1.json index 5df129b1..cef93870 100644 --- a/docs/api/controls/CFG-08.1.json +++ b/docs/api/controls/CFG-08.1.json @@ -2,8 +2,8 @@ "control_id": "CFG-08.1", "title": "Sensitive / Regulated Data Actions", "family": "CFG", - "description": "Automated mechanisms exist to generate event logs whenever sensitive/regulated data is collected, created, updated, deleted and/or archived.", - "scf_question": "Does the organization use automated mechanisms to generate event logs whenever sensitive/regulated data is collected, created, updated, deleted and/or archived?", + "description": "Automated mechanisms exist to generate event logs whenever sensitive and/or regulated data is collected, created, updated, deleted and/or archived.", + "scf_question": "Does the organization use automated mechanisms to generate event logs whenever sensitive and/or regulated data is collected, created, updated, deleted and/or archived?", "relative_weight": 7, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -99,7 +99,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -109,14 +110,11 @@ "general-nist-800-66-r2": [ "164.312(c)" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ] } } \ No newline at end of file diff --git a/docs/api/controls/CFG-08.json b/docs/api/controls/CFG-08.json index e508a554..f0be515d 100644 --- a/docs/api/controls/CFG-08.json +++ b/docs/api/controls/CFG-08.json @@ -2,8 +2,8 @@ "control_id": "CFG-08", "title": "Sensitive / Regulated Data Access Enforcement", "family": "CFG", - "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data.", - "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data?", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive and/or regulated data.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive and/or regulated data?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -130,7 +131,8 @@ "03.01.02" ], "general-nist-800-171a-r3": [ - "A.03.01.02[01]" + "A.03.01.02[01]", + "A.03.01.02[02]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -142,12 +144,12 @@ "248.30(a)(2)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "AC-3(CE-11)" diff --git a/docs/api/controls/CFG-09.1.json b/docs/api/controls/CFG-09.1.json new file mode 100644 index 00000000..9a235079 --- /dev/null +++ b/docs/api/controls/CFG-09.1.json @@ -0,0 +1,76 @@ +{ + "control_id": "CFG-09.1", + "title": "Third-Party Libraries", + "family": "CFG", + "description": "Mechanisms exist to restrict the use and import of third-party libraries and/or software components to trustworthy sources.", + "scf_question": "Does the organization restrict the use and import of third-party libraries and/or software components to trustworthy sources?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to restrict the use and import of third-party libraries and/or software components to trustworthy sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Manual review of third-party libraries before use\n∙ OWASP Dependency-Check\n∙ Approved library list", + "small": "∙ OWASP Dependency-Check for vulnerability scanning\n∙ Approved third-party library register", + "medium": "∙ Software Composition Analysis (SCA) tool\n∙ Approved vendor/library register\n∙ Dependency vulnerability scanning in CI/CD", + "large": "∙ Enterprise SCA tool (e.g., Snyk, Mend, Black Duck)\n∙ Approved library registry\n∙ Automated dependency scanning in CI/CD pipeline", + "enterprise": "∙ Enterprise SCA platform (e.g., Snyk, Black Duck\n∙ Automated library approval workflows\n∙ SBOM generation for all dependencies\n∙ Real-time vulnerability alerting for in-use libraries" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2029", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2029" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/CFG-09.2.json b/docs/api/controls/CFG-09.2.json new file mode 100644 index 00000000..1049ce6f --- /dev/null +++ b/docs/api/controls/CFG-09.2.json @@ -0,0 +1,78 @@ +{ + "control_id": "CFG-09.2", + "title": "Software Repository Protections", + "family": "CFG", + "description": "Mechanisms exist to protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys.", + "scf_question": "Does the organization protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Checksum verification of downloaded packages\n∙ Use of reputable package registries only", + "small": "∙ Package signature verification\n∙ Private package mirror or proxy", + "medium": "∙ Artifact repository with malware scanning\n∙ Package signature and hash verification\n∙ Private package registry to proxy public registries", + "large": "∙ Enterprise artifact repository with integrated security scanning\n∙ Signed artifact enforcement\n∙ Private package proxy with allowlist", + "enterprise": "∙ Enterprise artifact repository with automated malware scanning and secret detection\n∙ Code signing enforcement\n∙ Supply chain security tools.\n∙ Private package proxy with security scanning" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2026 & ISM-2027", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2026", + "ISM-2027", + "ISM-2030" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/CFG-09.3.json b/docs/api/controls/CFG-09.3.json new file mode 100644 index 00000000..ec5dca65 --- /dev/null +++ b/docs/api/controls/CFG-09.3.json @@ -0,0 +1,79 @@ +{ + "control_id": "CFG-09.3", + "title": "Software Development Repository", + "family": "CFG", + "description": "Mechanisms exist to maintain an authoritative repository for software development activities that is separate from production software.", + "scf_question": "Does the organization maintain an authoritative repository for software development activities that is separate from production software?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to maintain an authoritative repository for software development activities that is separate from production software.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Separate development branch in version control\n∙ GitHub or GitLab for development repository.", + "small": "∙ Separate development environment and repository\n∙ Branch-based development workflow separate from production", + "medium": "∙ Separate development, staging and production repositories\n∙ Access controls separating development from production code", + "large": "∙ Enterprise repository management with environment separation\n∙ Strict access controls between dev and production repositories\n∙ Code review requirements before production promotion", + "enterprise": "∙ Enterprise DevSecOps platform with environment-separated repositories\n∙ Automated promotion gates between environments\n∙ Immutable production code repository\n∙ Integration with ITSM change management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2024", + "family_name": "Configuration Management", + "crosswalks": { + "emea-sau-ecc-1-2018": [ + "1-6-3-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2024" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/CFG-09.json b/docs/api/controls/CFG-09.json new file mode 100644 index 00000000..50da9545 --- /dev/null +++ b/docs/api/controls/CFG-09.json @@ -0,0 +1,76 @@ +{ + "control_id": "CFG-09", + "title": "Production Software Repository", + "family": "CFG", + "description": "Mechanisms exist to maintain an authoritative repository for production software.", + "scf_question": "Does the organization maintain an authoritative repository for production software?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to maintain an authoritative repository for production software.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Version control system with protected production branch (e.g., GitHub, GitLab).\n∙ Designated production branch with access controls", + "small": "∙ Version control with protected production branches.\n∙ Access restrictions on production branch", + "medium": "∙ Artifact repository manager (e.g., JFrog Artifactory, Nexus)\n∙ Version-controlled production software with access restrictions", + "large": "∙ Enterprise artifact repository (e.g., JFrog Artifactory, Nexus)\n∙ Access controls on production repository\n∙ Immutable artifact storage", + "enterprise": "∙ Enterprise artifact repository (e.g., JFrog Artifactory)\n∙ Software Bill of Materials (SBOM) generation\n∙ Immutable artifact storage with digital signing\n∙ Integration with CI/CD pipeline" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2023", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2023" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/CHG-01.json b/docs/api/controls/CHG-01.json index 81bab9e2..724a1577 100644 --- a/docs/api/controls/CHG-01.json +++ b/docs/api/controls/CHG-01.json @@ -113,7 +113,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -237,15 +238,15 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.d" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.d[01]", "A.03.04.03.d[02]" ], - "general-nist-800-172": [ - "3.13.2e" - ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -328,10 +329,10 @@ "314.4(c)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "CM-3" @@ -360,9 +361,8 @@ "CM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "emea-eu-dora-2023": [ "Article 9.4(e)" @@ -374,51 +374,35 @@ "6.6.1", "6.10.2(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "8.4" ], "emea-deu-c5-2020": [ - "DEV-03", - "DEV-08" + "BEI-03", + "BEI-03-BP1", + "BEI-03-BP2", + "BEI-05", + "BEI-06", + "BEI-08" ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.6", - "14.7" + "emea-sau-cscc-1-2019": [ + "1-3-1" ], "emea-sau-cgiot-2024": [ "1-5-3" ], - "emea-sau-ecc-1-2018": [ - "1-6-2" - ], "emea-sau-otcc-1-2022": [ - "1-5", "1-5-1", - "1-5-2" + "1-5-2", + "1-5-3" ], "emea-sau-sama-csf-1-2017": [ - "3.3.7" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.1" + "3.3.7", + "3.3.7.1", + "3.3.7.4" ], - "emea-esp-decree-311-2022": [ - "21.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.5 [OP.EXP.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], "emea-gbr-def-stan-05-138-2024": [ "2404" @@ -432,7 +416,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2404" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1211" ], "apac-ind-sebi-2024": [ @@ -444,7 +428,10 @@ "12.1.2.1", "12.1.2.11.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.11" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP18", "HML18" ], @@ -455,29 +442,26 @@ "6.3.6.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.5.1", - "7.5.2", - "7.5.3", - "7.5.4", - "7.5.5", - "7.5.6", - "7.5.7" + "7.5.1" ], - "americas-bmu-mba-coc-2020": [ - "6.1" + "americas-arg-ppd-2018": [ + "C", + "C.1.1-2" ], - "amaericas-can-osfi-self-assessment": [ - "4.17", - "4.20", - "6.11" + "americas-bmu-mba-coc-2020": [ + "6.1-BP2" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.A" + "03.04.03.A", + "03.04.03.D" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-02.1.json b/docs/api/controls/CHG-02.1.json index b41439a3..426965d2 100644 --- a/docs/api/controls/CHG-02.1.json +++ b/docs/api/controls/CHG-02.1.json @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -145,11 +146,16 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.b", + "03.07.05.a" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.b[02]", - "A.03.04.05[05]" + "A.03.04.05[05]", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -189,21 +195,10 @@ "7123(c)(5)(E)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "emea-deu-c5-2020": [ - "IDM-02" - ], - "emea-isr-cmo-1-0": [ - "14.7" - ], - "emea-sau-otcc-1-2022": [ - "1-5-3-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "BEI-12" ], "apac-jpn-ismap": [ "14.2.4", @@ -214,16 +209,26 @@ "14.2.4.5", "14.2.4.6" ], + "apac-nzl-ism-3-9": [ + "20.2.15.C.02", + "20.2.15.C.05" + ], "apac-sgp-mas-trm-2021": [ - "7.5.4" + "7.5.2" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1", + "2.5.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.A" + "03.04.03.A", + "03.04.03.B", + "03.07.05.A" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-02.2.json b/docs/api/controls/CHG-02.2.json index 18f09d20..92982bb1 100644 --- a/docs/api/controls/CHG-02.2.json +++ b/docs/api/controls/CHG-02.2.json @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -194,7 +195,18 @@ "03.04.11.b" ], "general-nist-800-171a-r3": [ - "A.03.04.03.c[02]" + "A.03.04.03.b[02]", + "A.03.04.03.c[02]", + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.04.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.07E[01]", + "DS-A.03.04.07E[03]" ], "general-nist-csf-2-0": [ "ID.RA-07" @@ -268,39 +280,25 @@ "CM-03 (02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "emea-deu-c5-2020": [ - "DEV-06", - "DEV-08", - "DEV-09" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "12.21", - "12.30", - "14.6", - "14.8", - "14.9", - "14.10" - ], - "emea-sau-cscc-1-2019": [ - "1-3-1-2" + "BEI-03-BP3", + "BEI-03-BP4", + "BEI-07", + "BEI-09" ], "emea-sau-cgiot-2024": [ "1-5-3" ], - "emea-sau-ecc-1-2018": [ - "1-6-2-1", - "1-6-3-5" - ], "emea-sau-otcc-1-2022": [ "1-5-3-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], "apac-ind-sebi-2024": [ "PR.MA.S1" @@ -314,21 +312,26 @@ "14.2.3.2", "14.2.3.3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "apac-nzl-ism-3-9": [ "6.3.8.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.4.2", "7.5.3", "7.5.5", "7.5.7" ], - "amaericas-can-osfi-self-assessment": [ - "6.11" + "americas-arg-ppd-2018": [ + "C.1.1-3" ], "americas-can-osfi-b13-2022": [ "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.03.B", "03.04.03.C", diff --git a/docs/api/controls/CHG-02.3.json b/docs/api/controls/CHG-02.3.json index 5e7f5622..93012d63 100644 --- a/docs/api/controls/CHG-02.3.json +++ b/docs/api/controls/CHG-02.3.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to include a cybersecurity and/or data protection representative in the configuration change control review process.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -90,9 +90,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Change Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -141,6 +141,9 @@ "general-nist-800-171-r3": [ "03.04.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.04.04.a" + ], "general-tisax-6-0-3": [ "5.2.2" ], @@ -168,29 +171,13 @@ "CM-03 (04)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" - ], - "emea-deu-c5-2020": [ - "DEV-05", - "DEV-09" - ], - "emea-isr-cmo-1-0": [ - "14.8" - ], - "emea-sau-ecc-1-2018": [ - "1-6-2-2" + "3.4.4.37" ], "emea-sau-otcc-1-2022": [ - "1-5-2" - ], - "apac-sgp-mas-trm-2021": [ - "7.5.4" + "1-5-4" ], - "amaericas-can-osfi-self-assessment": [ - "2.4", - "6.11" + "apac-mys-bnm-rmit-2025": [ + "10.11" ], "americas-can-itsp-10-171-2025": [ "03.04.04.A" diff --git a/docs/api/controls/CHG-02.4.json b/docs/api/controls/CHG-02.4.json index 301d201a..b88c91b4 100644 --- a/docs/api/controls/CHG-02.4.json +++ b/docs/api/controls/CHG-02.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions upon the detection of unauthorized baseline configurations change(s).", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -71,7 +71,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -97,9 +98,6 @@ ], "general-pci-dss-4-0-1": [ "10.7" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-02.5.json b/docs/api/controls/CHG-02.5.json index ae2e5e7c..61c2ce38 100644 --- a/docs/api/controls/CHG-02.5.json +++ b/docs/api/controls/CHG-02.5.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern assets involved in providing cryptographic protections according to the organization's configuration management processes.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern assets involved in providing cryptographic protections according to the organization's configuration management processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -50,7 +50,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { diff --git a/docs/api/controls/CHG-02.json b/docs/api/controls/CHG-02.json index 19d5dc37..2e40ffb8 100644 --- a/docs/api/controls/CHG-02.json +++ b/docs/api/controls/CHG-02.json @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -173,7 +174,7 @@ "general-iso-42001-2023": [ "6.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.005", "T1059.006", "T1176", @@ -259,7 +260,8 @@ "03.04.02.b", "03.04.03.a", "03.04.03.b", - "03.04.03.c" + "03.04.03.c", + "03.07.05.a" ], "general-nist-800-171a": [ "3.4.3[a]", @@ -268,8 +270,11 @@ "3.4.3[d]" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", "A.03.04.03.a", - "A.03.04.03.c[01]" + "A.03.04.03.b[02]", + "A.03.04.03.c[01]", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -302,9 +307,6 @@ "6.5.6", "12.4.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-tisax-6-0-3": [ "5.2.1" ], @@ -373,9 +375,8 @@ "CM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "emea-eu-dora-2023": [ "Article 9.4(e)" @@ -388,32 +389,23 @@ "8.5" ], "emea-deu-c5-2020": [ - "DEV-08" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.7" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3-5" + "BEI-08", + "BEI-09-DOAR" ], "emea-sau-otcc-1-2022": [ - "1-5", - "1-5-1", - "1-5-2", - "1-5-3", - "1-5-3-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "1-5-3-1", + "1-5-3-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.1" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.c", + "3.3.7.4.d", + "3.3.7.4.e", + "3.3.7.4.i" ], - "emea-esp-decree-311-2022": [ - "21.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1211" ], "apac-ind-sebi-2024": [ @@ -466,7 +458,12 @@ "14.2.4.9", "14.2.4.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.11", + "10.18", + "10.27" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP18", "HML18" ], @@ -479,20 +476,27 @@ "6.3.7.C.02", "6.3.7.C.03" ], - "amaericas-can-osfi-self-assessment": [ - "4.18", - "4.20" + "apac-sgp-mas-trm-2021": [ + "7.5.2", + "7.5.4" + ], + "americas-arg-ppd-2018": [ + "C.1.1-DS" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1", "2.5.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", "03.04.03.A", "03.04.03.B", - "03.04.03.C" + "03.04.03.C", + "03.07.05.A" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-03.json b/docs/api/controls/CHG-03.json index 460950e4..4b8ef956 100644 --- a/docs/api/controls/CHG-03.json +++ b/docs/api/controls/CHG-03.json @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -169,7 +170,9 @@ ], "general-nist-800-171a-r3": [ "A.03.04.03.b[01]", - "A.03.04.04.a" + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" ], "general-nist-csf-2-0": [ "ID.RA-07" @@ -194,9 +197,6 @@ "6.5.2", "6.5.6" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-tisax-6-0-3": [ "5.2.2", "5.3.1" @@ -244,29 +244,23 @@ "CM-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.76" ], "emea-deu-c5-2020": [ - "DEV-05", - "BCM-02" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.8" - ], - "emea-sau-cscc-1-2019": [ - "1-3-1-2" + "BEI-04", + "BEI-06" ], "emea-sau-otcc-1-2022": [ - "1-5-2", "1-5-4" ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.a" + ], + "apac-mys-bnm-rmit-2025": [ + "10.11" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP33", "HML33" ], diff --git a/docs/api/controls/CHG-04.1.json b/docs/api/controls/CHG-04.1.json index 4950e49c..1f5abf8d 100644 --- a/docs/api/controls/CHG-04.1.json +++ b/docs/api/controls/CHG-04.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to perform after-the-fact reviews of configuration change logs to discover any unauthorized changes.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -74,7 +74,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -135,10 +136,10 @@ "CM-5(1)" ], "emea-sau-otcc-1-2022": [ - "1-5-4" + "1-5-3-5" ], - "amaericas-can-osfi-self-assessment": [ - "6.11" + "americas-can-osfi-self-assessment-2": [ + "2.5.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-04.2.json b/docs/api/controls/CHG-04.2.json index 9d5e7f67..4a7caa9a 100644 --- a/docs/api/controls/CHG-04.2.json +++ b/docs/api/controls/CHG-04.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to prevent the installation of software and firmware components without verification that the component has been digitally signed using an organization-approved certificate authority.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -101,7 +102,7 @@ "usa-federal-irs-1075-2021": [ "CM-14" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1796" ] } diff --git a/docs/api/controls/CHG-04.3.json b/docs/api/controls/CHG-04.3.json index 2f728ffd..ad15c47c 100644 --- a/docs/api/controls/CHG-04.3.json +++ b/docs/api/controls/CHG-04.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to enforce a two-person rule for implementing changes to critical Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -129,6 +130,15 @@ "general-nist-800-161-r1-level-3": [ "AC-5" ], + "general-nist-800-172-r3": [ + "03.04.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.05E[01]", + "A.03.04.05E.ODP[01]", + "DS-A.03.04.05E[02]", + "A.03.04.05E.ODP[02]" + ], "usa-federal-fbi-cjis-6-0": [ "AC-5" ], @@ -156,8 +166,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-05" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-6" + "apac-sgp-mas-trm-2021": [ + "9.1.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-04.4.json b/docs/api/controls/CHG-04.4.json index 6a9acf69..d7bf9b03 100644 --- a/docs/api/controls/CHG-04.4.json +++ b/docs/api/controls/CHG-04.4.json @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -139,16 +140,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-05 (05)" ], - "emea-deu-c5-2020": [ - "DEV-09", - "PSS-08" - ], - "emea-isr-cmo-1-0": [ - "10.4" - ], - "apac-chn-data-security-law-2021": [ - "27" - ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.2" diff --git a/docs/api/controls/CHG-04.5.json b/docs/api/controls/CHG-04.5.json index f48484c9..49678538 100644 --- a/docs/api/controls/CHG-04.5.json +++ b/docs/api/controls/CHG-04.5.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to restrict software library privileges to those individuals with a pertinent business need for access.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to restrict software library privileges to those individuals with a pertinent business need for access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -101,15 +102,17 @@ "general-ul-2900-1-2017": [ "4.1(e)" ], - "emea-deu-c5-2020": [ - "DEV-07", - "DEV-08" - ], "emea-sau-cscc-1-2019": [ "1-3-2-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0405" + ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-04.json b/docs/api/controls/CHG-04.json index fa4007ce..dc2bde17 100644 --- a/docs/api/controls/CHG-04.json +++ b/docs/api/controls/CHG-04.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -60,7 +60,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -86,7 +87,7 @@ "general-govramp-high": [ "CM-05" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -303,6 +304,10 @@ "3.4.5[g]", "3.4.5[h]" ], + "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.05[06]" + ], "general-nist-800-218": [ "PS.1" ], @@ -362,9 +367,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-05" ], - "emea-deu-c5-2020": [ - "DEV-09" - ], "emea-sau-otcc-1-2022": [ "1-5-3-4" ], @@ -380,6 +382,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2422" ], + "apac-aus-ism-2026-march": [ + "ISM-1823" + ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.2" diff --git a/docs/api/controls/CHG-05.json b/docs/api/controls/CHG-05.json index 285bed3a..ea6a1c6c 100644 --- a/docs/api/controls/CHG-05.json +++ b/docs/api/controls/CHG-05.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited information is provided to stakeholders about proposed changes.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to ensure stakeholders are made aware of and understand the impact of proposed changes.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to ensure stakeholders are made aware of and understand the impact of proposed changes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -185,9 +186,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-09" ], + "emea-deu-c5-2020": [ + "BEI-03-BP2" + ], "emea-sau-cgiot-2024": [ "1-5-3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "americas-can-itsp-10-171-2025": [ "03.04.11.B" ] diff --git a/docs/api/controls/CHG-06.1.json b/docs/api/controls/CHG-06.1.json index 9c0cf4a3..b1caf39e 100644 --- a/docs/api/controls/CHG-06.1.json +++ b/docs/api/controls/CHG-06.1.json @@ -3,7 +3,7 @@ "title": "Report Verification Results", "family": "CHG", "description": "Mechanisms exist to report the results of security, compliance and resilience capability verification to appropriate organizational management.", - "scf_question": "Does the organization report the results of cybersecurity and data protection function verification to appropriate organizational management?", + "scf_question": "Does the organization report the results of security, compliance and resilience capability verification to appropriate organizational management?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to report the results of security, compliance and resilience capability verification to appropriate organizational management.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60,9 +60,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Change Management", "crosswalks": { "general-nist-800-53-r5-2": [ diff --git a/docs/api/controls/CHG-06.json b/docs/api/controls/CHG-06.json index c663b5e5..d316bfa1 100644 --- a/docs/api/controls/CHG-06.json +++ b/docs/api/controls/CHG-06.json @@ -3,7 +3,7 @@ "title": "Control Functionality Verification", "family": "CHG", "description": "Mechanisms exist to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed.", - "scf_question": "Does the organization verify the functionality of cybersecurity and/or data protection controls following implemented changes to ensure applicable controls operate as designed?", + "scf_question": "Does the organization verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,9 +83,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Change Management", "crosswalks": { "general-cis-csc-8-1": [ @@ -169,6 +169,12 @@ "general-nist-800-171a-r3": [ "A.03.04.04.b" ], + "general-nist-800-172-r3": [ + "03.04.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.07E[02]" + ], "general-pci-dss-4-0-1": [ "6.5.2", "10.7.3", @@ -227,13 +233,14 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-03 (02)" ], - "emea-isr-cmo-1-0": [ - "10.6", - "12.30", - "14.10" + "emea-sau-otcc-1-2022": [ + "1-5-4" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.f" ], - "apac-sgp-mas-trm-2021": [ - "7.5.5" + "americas-arg-ppd-2018": [ + "C.1.1-1" ], "americas-can-itsp-10-171-2025": [ "03.04.04.B" diff --git a/docs/api/controls/CHG-07.1.json b/docs/api/controls/CHG-07.1.json index 9cba4698..d2ac7179 100644 --- a/docs/api/controls/CHG-07.1.json +++ b/docs/api/controls/CHG-07.1.json @@ -25,7 +25,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Emergency change log (spreadsheet)\n∙ Post-hoc documentation template for emergency changes", + "small": "∙ Emergency change documentation register\n∙ Mandatory post-implementation review requirement", + "medium": "∙ ITSM-based post-implementation emergency change documentation\n∙ Mandatory post-implementation review within defined timeframe", + "large": "∙ ITSM platform mandatory documentation workflow\n∙ Post-implementation review with management sign-off\n∙ Integration with audit trail", + "enterprise": "∙ Automated ITSM documentation requirements for emergency changes\n∙ Mandatory post-implementation review with sign-off\n∙ Integration with GRC and audit reporting" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -77,12 +83,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { "emea-eu-nis2-annex-2024": [ "6.4.3" + ], + "emea-deu-c5-2020": [ + "BEI-10" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-07.json b/docs/api/controls/CHG-07.json index 3e7764b6..78e50bf5 100644 --- a/docs/api/controls/CHG-07.json +++ b/docs/api/controls/CHG-07.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern change management procedures for \"emergency\" changes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -25,7 +25,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Documented emergency change procedure\n∙ Post-implementation documentation requirement", + "small": "∙ Emergency change request process\n∙ Designated emergency change approver\n∙ Post-implementation review", + "medium": "∙ Formal emergency change management process\n∙ ITSM tool emergency change workflow (e.g., ServiceNow, Jira)\n∙ Emergency Change Advisory Board (CAB) approval", + "large": "∙ Enterprise emergency change management process in ITSM platform\n∙ Emergency CAB with on-call members\n∙ Integration with incident response", + "enterprise": "∙ Enterprise ITSM emergency change workflow\n∙ 24/7 emergency CAB availability\n∙ Automated emergency change tracking and audit trail\n∙ Integration with incident response processes" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -77,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -89,6 +96,18 @@ ], "emea-eu-nis2-annex-2024": [ "6.4.3" + ], + "emea-deu-c5-2020": [ + "BEI-10" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.h" + ], + "apac-sgp-mas-trm-2021": [ + "7.5.6" + ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/CHG-08.json b/docs/api/controls/CHG-08.json index 6ac89c43..27d269d9 100644 --- a/docs/api/controls/CHG-08.json +++ b/docs/api/controls/CHG-08.json @@ -3,7 +3,7 @@ "title": "Dual Approval For High-Impact Environments", "family": "CHG", "description": "Mechanisms exist to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization require dual approval for any changes that might result in a serious, but adverse impact to:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -48,13 +48,16 @@ "MT-8", "MT-9", "MT-10", - "MT-11" + "MT-11", + "MT-28" ], - "errata": "- new control (IEC 62443-4-2)", "family_name": "Change Management", "crosswalks": { "general-iec-62443-4-2-2019": [ "CR 2.1(4)" + ], + "emea-sau-otcc-1-2022": [ + "2-2-1-6" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-01.1.json b/docs/api/controls/CLD-01.1.json index 1b76cecc..cf070939 100644 --- a/docs/api/controls/CLD-01.1.json +++ b/docs/api/controls/CLD-01.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud services are designed and configured so Technology Assets, Applications and/or Services (TAAS) are secured in accordance with applicable organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90,12 +90,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { - "emea-sau-sacs-002-2022": [ - "TPC-43" + "emea-sau-ecc-1-2018": [ + "4-2-3-1" ], "apac-nzl-ism-3-9": [ "23.4.9.C.01", diff --git a/docs/api/controls/CLD-01.2.json b/docs/api/controls/CLD-01.2.json index d3924173..0fb3c7da 100644 --- a/docs/api/controls/CLD-01.2.json +++ b/docs/api/controls/CLD-01.2.json @@ -85,10 +85,24 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { + "emea-deu-c5-2020": [ + "PI-02", + "PI-05" + ], + "emea-sau-ecc-1-2018": [ + "4-2-3-1" + ], + "emea-sau-sama-csf-1-2017": [ + "3.4.3.4.h", + "3.4.3.4.h.1", + "3.4.3.4.h.2", + "3.4.3.4.h.3" + ], "apac-jpn-ismap": [ "8.1.5.P", "8.1.5.1.P", @@ -97,6 +111,8 @@ "8.1.5.4.P" ], "apac-nzl-ism-3-9": [ + "20.1.26.C.02", + "20.1.26.C.03", "23.4.13.C.01", "23.4.13.C.02", "23.4.13.C.03" diff --git a/docs/api/controls/CLD-01.json b/docs/api/controls/CLD-01.json index d19214bd..192e2e7c 100644 --- a/docs/api/controls/CLD-01.json +++ b/docs/api/controls/CLD-01.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify cybersecurity and data protection requirements for CSP environments, including dedicated and multi-client environments.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -117,7 +117,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -184,9 +185,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-shared-assessments-sig-2025": [ "J.1" ], @@ -205,22 +203,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "COS-01", - "COS-02" - ], - "emea-isr-cmo-1-0": [ - "11.2" + "UP-01", + "UP-01-BP1", + "UP-01-BP2", + "RB-05" ], "emea-sau-cscc-1-2019": [ - "4-2" + "4-2-1" ], "emea-sau-cgiot-2024": [ "4-2-1" @@ -228,23 +218,38 @@ "emea-sau-ecc-1-2018": [ "4-2-1", "4-2-2", - "4-2-3", + "4-2-3-1", "4-2-3-2", - "4-2-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" + "4-2-3-3" ], "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.4.3" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "apac-aus-ism-2024-june": [ + "3.4.3", + "3.4.3.1", + "3.4.3.3", + "3.4.3.4", + "3.4.3.4.a", + "3.4.3.4.a.1", + "3.4.3.4.a.2", + "3.4.3.4.a.3", + "3.4.3.4.b", + "3.4.3.4.b.1", + "3.4.3.4.c", + "3.4.3.4.c.1", + "3.4.3.4.d", + "3.4.3.4.d.1", + "3.4.3.4.e", + "3.4.3.4.e.1", + "3.4.3.4.f", + "3.4.3.4.f.1", + "3.4.3.4.g", + "3.4.3.4.g.1", + "3.4.3.4.g.2", + "3.4.3.4.g.3" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.nub.1" + ], + "apac-aus-ism-2026-march": [ "ISM-1437", "ISM-1529", "ISM-1579", @@ -265,29 +270,20 @@ "5.1.1.29.P", "5.1.1.30.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.26", + "10.50" + ], "apac-nzl-ism-3-9": [ + "2.3.28.C.01", + "20.1.20.C.01", + "20.1.20.C.02", + "20.1.20.C.03", + "20.1.20.C.04", "22.1.20.C.01", "22.1.20.C.02", "22.1.20.C.03", - "22.1.20.C.04", - "22.1.20.C.05", "22.1.21.C.01", - "22.1.21.C.02", - "22.1.21.C.03", - "22.1.21.C.04", - "22.1.21.C.05", - "22.1.21.C.06", - "22.1.21.C.07", - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04", - "22.1.25.C.01", - "22.1.25.C.02", - "22.1.26.C.01", - "22.1.26.C.02", - "22.1.26.C.03", - "22.1.27.C.01", "23.1.54.C.01", "23.1.54.C.02", "23.2.19.C.01" diff --git a/docs/api/controls/CLD-02.json b/docs/api/controls/CLD-02.json index 7e1a6ee8..a3edb2cf 100644 --- a/docs/api/controls/CLD-02.json +++ b/docs/api/controls/CLD-02.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -119,8 +120,8 @@ "3.1.22", "NFO–PL-8" ], - "general-scf-dpmp-2025": [ - "7.1" + "general-nist-cswp-39": [ + "6.4" ], "general-shared-assessments-sig-2025": [ "N.2" @@ -144,9 +145,8 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-01", - "COS-02" + "emea-isr-cmo-2-0": [ + "Appendix A, 6.1" ], "emea-sau-cgiot-2024": [ "4-2-1", @@ -155,11 +155,6 @@ "emea-sau-ecc-1-2018": [ "4-2-3-2" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.4.3" - ], "apac-ind-sebi-2024": [ "PR.IP.S13" ], @@ -167,7 +162,10 @@ "8.1.2.7.PB", "9.2.3.11.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP51", "HML51" ], @@ -175,9 +173,12 @@ "HSUP43" ], "apac-nzl-ism-3-9": [ - "22.1.23.C.01", - "22.1.23.C.02", - "22.1.23.C.03", + "2.3.28.C.01", + "20.1.24.C.02", + "20.1.24.C.03", + "20.1.24.C.04", + "20.2.12.C.01", + "20.2.12.C.02", "23.1.54.C.01", "23.1.54.C.02", "23.1.56.C.01", diff --git a/docs/api/controls/CLD-03.json b/docs/api/controls/CLD-03.json index d59ad207..14b3350a 100644 --- a/docs/api/controls/CLD-03.json +++ b/docs/api/controls/CLD-03.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ The cloud infrastructure incorporates a managed security zone to house cybersecurity and data protection tools.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to host security-specific technologies in a dedicated subnet.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -56,7 +56,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -104,20 +105,9 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-01", - "COS-02", - "COS-05" - ], - "emea-isr-cmo-1-0": [ - "9.2" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1750" - ], - "apac-nzl-ism-3-9": [ - "22.1.24.C.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-04.1.json b/docs/api/controls/CLD-04.1.json index 8d95630c..4aa209d6 100644 --- a/docs/api/controls/CLD-04.1.json +++ b/docs/api/controls/CLD-04.1.json @@ -81,11 +81,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { "usa-federal-dow-zt-roadmap-1-1": [ + "3.4", "3.4.1" ] } diff --git a/docs/api/controls/CLD-04.json b/docs/api/controls/CLD-04.json index ff8df11a..08473d2d 100644 --- a/docs/api/controls/CLD-04.json +++ b/docs/api/controls/CLD-04.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure support for secure interoperability between components with Application Programming Interfaces (APIs).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -95,20 +96,29 @@ "155.260(a)(6)" ], "emea-deu-c5-2020": [ - "PI-01" + "PI-01", + "PI-04" ], "emea-sau-cscc-1-2019": [ "1-3-2-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.4", + "mp.s.2" + ], "apac-ind-sebi-2024": [ "PR.AA.S17" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP52", "HML52" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP44" + ], + "apac-sgp-mas-trm-2021": [ + "6.4.1", + "6.4.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-05.json b/docs/api/controls/CLD-05.json index b3026a70..e73ed013 100644 --- a/docs/api/controls/CLD-05.json +++ b/docs/api/controls/CLD-05.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the integrity of virtual machine images at all times.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the integrity of virtual machine images at all times. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -60,12 +60,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { - "emea-deu-c5-2020": [ - "PSS-11" + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-06.1.json b/docs/api/controls/CLD-06.1.json index 64dc46b6..bbe8bbd5 100644 --- a/docs/api/controls/CLD-06.1.json +++ b/docs/api/controls/CLD-06.1.json @@ -66,9 +66,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": { "general-iso-27001-2022": [ @@ -89,13 +89,28 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.1" ], + "emea-deu-c5-2020": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 5.1" + ], "apac-jpn-ismap": [ "6.3.1.1.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "apac-nzl-ism-3-9": [ + "20.1.21.C.03", "23.1.55.C.01", "23.1.55.C.02", "23.1.55.C.03" + ], + "americas-bmu-mba-coc-2020": [ + "5.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-06.2.json b/docs/api/controls/CLD-06.2.json index afee2f01..586c745e 100644 --- a/docs/api/controls/CLD-06.2.json +++ b/docs/api/controls/CLD-06.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure Multi-Tenant Service Providers (MTSP) facilitate security event logging capabilities for its customers that are consistent with applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,7 +61,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -72,6 +73,9 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "A1.2.1" ], + "emea-deu-c5-2020": [ + "RB-10" + ], "apac-nzl-ism-3-9": [ "23.5.11.C.01", "23.5.12.C.01", diff --git a/docs/api/controls/CLD-06.3.json b/docs/api/controls/CLD-06.3.json index cfc2d7b3..711e171c 100644 --- a/docs/api/controls/CLD-06.3.json +++ b/docs/api/controls/CLD-06.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure Multi-Tenant Service Providers (MTSP) facilitate prompt forensic investigations in the event of a suspected or confirmed security incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,7 +61,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { diff --git a/docs/api/controls/CLD-06.4.json b/docs/api/controls/CLD-06.4.json index 74baaceb..f8e72e00 100644 --- a/docs/api/controls/CLD-06.4.json +++ b/docs/api/controls/CLD-06.4.json @@ -61,7 +61,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { diff --git a/docs/api/controls/CLD-06.json b/docs/api/controls/CLD-06.json index 841463ea..fabdec3c 100644 --- a/docs/api/controls/CLD-06.json +++ b/docs/api/controls/CLD-06.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure multi-tenant owned or managed assets (physical and virtual) are designed and governed such that provider and customer (tenant) user access is appropriately segmented from other tenant users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -153,13 +154,9 @@ "52.204-21(b)(1)(iv)" ], "emea-deu-c5-2020": [ - "OPS-24" + "RB-23" ], - "emea-isr-cmo-1-0": [ - "10.1", - "11.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1529" ], "apac-jpn-ismap": [ @@ -169,7 +166,10 @@ "9.5.1.3.P", "9.5.1.4.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP53", "HML53" ], diff --git a/docs/api/controls/CLD-07.json b/docs/api/controls/CLD-07.json index cf4803a5..9a7b9cf9 100644 --- a/docs/api/controls/CLD-07.json +++ b/docs/api/controls/CLD-07.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud providers use secure protocols for the import, export and management of data in cloud-based Technology Assets, Applications and/or Services (TAAS).", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud providers use secure protocols for the import, export and management of data in cloud-based Technology Assets, Applications and/or Services (TAAS). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -51,7 +51,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -60,7 +61,8 @@ ], "emea-deu-c5-2020": [ "PI-01", - "PI-02" + "PI-02", + "PI-03" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-08.json b/docs/api/controls/CLD-08.json index d3c4acab..b8db86fd 100644 --- a/docs/api/controls/CLD-08.json +++ b/docs/api/controls/CLD-08.json @@ -56,12 +56,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", - "crosswalks": { - "emea-deu-c5-2020": [ - "PSS-11" - ] - } + "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/CLD-09.json b/docs/api/controls/CLD-09.json index b0389d49..80520253 100644 --- a/docs/api/controls/CLD-09.json +++ b/docs/api/controls/CLD-09.json @@ -22,9 +22,9 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Geolocation requirements for sensitive/regulated data types identify restrictions on transfer of data to third-countries or international organizations.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to govern geolocation requirements for sensitive/regulated data types, including the transfer of data to third-countries or international organizations.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to control the location of cloud processing/storage based on business requirements that includes statutory, regulatory and contractual obligations.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to control the location of cloud processing/storage based on business requirements that includes statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cloud Security (CLD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cloud Security (CLD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -148,14 +149,8 @@ "SA-09 (05)" ], "emea-deu-c5-2020": [ - "PI-02", - "PSS-12" - ], - "emea-ken-pda-2019": [ - "25(h)" - ], - "emea-qat-pdppl-2020": [ - "15" + "UP-02", + "RB-03" ], "emea-sau-cscc-1-2019": [ "4-2-1-1" @@ -164,43 +159,26 @@ "4-1-3-2", "4-2-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-30" - ], - "apac-aus-privacy-principles-2026": [ - "APP 8" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1572" ], - "apac-chn-pipl-2021": [ - "38", - "39", - "40" - ], "apac-ind-sebi-2024": [ "PR.DS.S2" ], - "apac-jpn-ppi-2020": [ - "24(1)" + "apac-mys-bnm-rmit-2025": [ + "10.50" ], "apac-nzl-ism-3-9": [ + "20.1.22.C.01", + "20.1.22.C.02", + "20.1.22.C.03", + "20.1.22.C.04", + "20.1.22.C.05", + "20.1.22.C.06", "22.1.22.C.01", "22.1.22.C.02", - "22.1.22.C.03", - "22.1.22.C.04", - "22.1.22.C.05", - "22.1.22.C.06", "23.4.11.C.01", "23.4.11.C.02" - ], - "americas-arg-ppd-2018": [ - "12.1", - "12.2" - ], - "americas-bra-lgpd-2018": [ - "33", - "34" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-10.json b/docs/api/controls/CLD-10.json index 402515ef..042a5ef3 100644 --- a/docs/api/controls/CLD-10.json +++ b/docs/api/controls/CLD-10.json @@ -2,8 +2,8 @@ "control_id": "CLD-10", "title": "Sensitive Data In Public Cloud Providers", "family": "CLD", - "description": "Mechanisms exist to limit and manage the storage of sensitive/regulated data in public cloud providers.", - "scf_question": "Does the organization limit and manage the storage of sensitive/regulated data in public cloud providers?", + "description": "Mechanisms exist to limit and manage the storage of sensitive and/or regulated data in public cloud providers.", + "scf_question": "Does the organization limit and manage the storage of sensitive and/or regulated data in public cloud providers?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -20,7 +20,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to limit and manage the storage of sensitive/regulated data in public cloud providers.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to limit and manage the storage of sensitive/regulated data in public cloud providers. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -92,13 +93,11 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(iv)" ], - "emea-isr-cmo-1-0": [ - "11.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 6.1" ], - "apac-nzl-ism-3-9": [ - "2.3.23.C.01", - "22.1.22.C.04", - "22.1.22.C.05" + "apac-mys-bnm-rmit-2025": [ + "10.50" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-11.json b/docs/api/controls/CLD-11.json index 853d4528..c853f316 100644 --- a/docs/api/controls/CLD-11.json +++ b/docs/api/controls/CLD-11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to utilize a Cloud Access Security Broker (CASB), or similar technology, to provide boundary protection and monitoring functions that both provide access to the cloud and protect the organization from misuse of cloud resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -64,20 +65,6 @@ ], "general-shared-assessments-sig-2025": [ "P.8" - ], - "emea-deu-c5-2020": [ - "COS-04" - ], - "emea-isr-cmo-1-0": [ - "9.10", - "11.8", - "16.4" - ], - "apac-nzl-ism-3-9": [ - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04" ] } } \ No newline at end of file diff --git a/docs/api/controls/CLD-12.json b/docs/api/controls/CLD-12.json index 72641bc0..8b96a8b2 100644 --- a/docs/api/controls/CLD-12.json +++ b/docs/api/controls/CLD-12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to prevent \"side channel attacks\" when using a Content Delivery Network (CDN) by restricting access to the origin server's IP address to the CDN and an authorized management network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -56,7 +56,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -73,7 +74,7 @@ "general-shared-assessments-sig-2025": [ "N.11" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1438", "ISM-1439" ] diff --git a/docs/api/controls/CLD-13.1.json b/docs/api/controls/CLD-13.1.json index 7f837aee..e786c842 100644 --- a/docs/api/controls/CLD-13.1.json +++ b/docs/api/controls/CLD-13.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to authorize specified individuals to access External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": {} diff --git a/docs/api/controls/CLD-13.2.json b/docs/api/controls/CLD-13.2.json index 323ac344..ea0eb69a 100644 --- a/docs/api/controls/CLD-13.2.json +++ b/docs/api/controls/CLD-13.2.json @@ -2,8 +2,8 @@ "control_id": "CLD-13.2", "title": "Sensitive / Regulated Data On Hosted Assets, Applications & Services", "family": "CLD", - "description": "Mechanisms exist to define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", - "scf_question": "Does the organization define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations?", + "description": "Mechanisms exist to define formal processes to store, process and/or transmit sensitive and/or regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", + "scf_question": "Does the organization define formal processes to store, process and/or transmit sensitive and/or regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": {} diff --git a/docs/api/controls/CLD-13.json b/docs/api/controls/CLD-13.json index 925e4836..e0b78574 100644 --- a/docs/api/controls/CLD-13.json +++ b/docs/api/controls/CLD-13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to specify applicable security, compliance and resilience that must be implemented on external Technology Assets, Applications and/or Services (TAAS), consistent with the contractual obligations established with the External Service Providers (ESP) owning, operating and/or maintaining external TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,9 +86,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": { "general-nist-800-207": [ diff --git a/docs/api/controls/CLD-14.json b/docs/api/controls/CLD-14.json index ccc0569c..09cb465a 100644 --- a/docs/api/controls/CLD-14.json +++ b/docs/api/controls/CLD-14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to prohibit access to, or usage of, hosted Technology Assets, Applications and/or Services (TAAS) until applicable security, compliance and/or resilience control implementation is verified.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,9 +86,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/CLD-15.json b/docs/api/controls/CLD-15.json index 2a145c79..f5fd7089 100644 --- a/docs/api/controls/CLD-15.json +++ b/docs/api/controls/CLD-15.json @@ -3,7 +3,7 @@ "title": "Software Defined Storage (SDS)", "family": "CLD", "description": "Automated mechanisms exist to utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization use automated mechanisms to utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 3, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { diff --git a/docs/api/controls/CPL-01.1.json b/docs/api/controls/CPL-01.1.json index 95d05208..31c68321 100644 --- a/docs/api/controls/CPL-01.1.json +++ b/docs/api/controls/CPL-01.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to document and review instances of non-compliance with statutory, regulatory and/or contractual obligations to develop appropriate risk mitigation actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -111,7 +111,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -205,7 +206,12 @@ "4.E(2)(b)" ], "general-nist-800-171-r3": [ - "03.12.02.a.01" + "03.12.02.a.01", + "03.12.02.a.02" + ], + "general-nist-800-171a-r3": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" ], "general-pci-dss-4-0-1": [ "12.4.2" @@ -213,9 +219,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.2" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-tisax-6-0-3": [ "1.5.1" ], @@ -247,34 +250,20 @@ "Article 20.1", "Article 41.5" ], + "emea-eu-eba-ict-srm-2025": [ + "3.3.6.27" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], + "emea-deu-c5-2020": [ + "SPN-02" + ], "emea-sau-cgiot-2024": [ "1-7-3" ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1" - ], - "apac-aus-ps-cps-230-2023": [ - "30", - "31" - ], - "apac-aus-ps-cps-234-2019": [ - "29", - "35", - "35(a)", - "35(b)", - "36" - ], - "apac-chn-pipl-2021": [ - "54" - ], - "apac-jpn-ppi-2020": [ - "40(1)", - "40(2)", - "40(3)" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], "apac-jpn-ismap": [ "4.6.1.1", @@ -286,23 +275,12 @@ "1.1.69.C.01", "1.1.69.C.02" ], - "apac-sgp-mas-trm-2021": [ - "3.2.3", - "4.5.2", - "4.5.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.10", - "6.14" - ], "americas-can-osfi-b13-2022": [ "1.3.1" ], "americas-can-itsp-10-171-2025": [ - "03.12.02.A.01" + "03.12.02.A.01", + "03.12.02.A.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-01.2.json b/docs/api/controls/CPL-01.2.json index 44e8dd16..af8fed13 100644 --- a/docs/api/controls/CPL-01.2.json +++ b/docs/api/controls/CPL-01.2.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to perform compliance scoping of control applicability for statutory, regulatory and/or contractual compliance obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to document and validate the scope of security, compliance and resilience controls that are determined to meet statutory, regulatory and/or contractual compliance obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,9 +71,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -129,9 +129,8 @@ "03.04.11.a", "03.15.02.a.04" ], - "general-nist-800-172": [ - "3.11.5e", - "3.14.3e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]" ], "general-nist-800-218": [ "PO.1" @@ -155,9 +154,6 @@ "12.5.1", "12.5.2" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-tisax-6-0-3": [ "1.2.1" ], @@ -165,6 +161,12 @@ "RA.L3-3.11.5E", "SI.L3-3.14.3E" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.605(a)", + "101.605(b)", + "101.625(d)", + "101.630(d)(2)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7123(b)(2)", "7123(b)(3)" @@ -187,16 +189,19 @@ "emea-sau-pdpl-2023": [ "Article 2.2" ], - "emea-esp-boe-a-2022-7191": [ - "Article 38.2" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], - "emea-esp-decree-311-2022": [ - "38.2" + "emea-che-fadp-2025": [ + "2.2.14.1.a" ], "apac-jpn-ismap": [ "4.4.4", "4.4.4.1" ], + "americas-bmu-mba-coc-2020": [ + "5.11-BP3" + ], "americas-can-osfi-b13-2022": [ "1.3.1" ], diff --git a/docs/api/controls/CPL-01.3.json b/docs/api/controls/CPL-01.3.json index 56918f1c..5a699c0b 100644 --- a/docs/api/controls/CPL-01.3.json +++ b/docs/api/controls/CPL-01.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -90,9 +90,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -108,9 +108,6 @@ "general-iso-29100-2024": [ "6.12" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-dow-cert-rmm-1-2": [ "COMP:SG3.SP1", "COMP:SG3.SP2" @@ -125,6 +122,10 @@ "usa-federal-eo-14028": [ "4e(ii)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(6)", + "101.660" + ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "IV.C.1" ], @@ -156,8 +157,9 @@ "Article 22.3", "Article 22.3(a)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.13" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(1)", + "Article 32(5)" ], "emea-eu-gdpr-2016": [ "Article 5.2", @@ -165,9 +167,30 @@ "Article 30.4", "Article 31" ], + "emea-aut-dpa-2018": [ + "§ 37(3)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 29(5)" + ], + "emea-deu-c5-2020": [ + "UP-04", + "SPN-03-DOAR", + "COM-02-DOAR", + "COM-03-DOAR" + ], + "emea-ken-pda-2019": [ + "IV.32(1)" + ], + "emea-nga-dpr-2019": [ + "3.1(4)" + ], "emea-sau-pdpl-2023": [ "Article 30.4.a" ], + "emea-esp-decree-311-2022": [ + "Article 38(1)" + ], "apac-ind-sebi-2024": [ "PR.IP.S17" ], @@ -175,6 +198,9 @@ "4.5.4.3", "18.2.1.11.P", "18.2.1.12.P" + ], + "apac-mys-bnm-rmit-2025": [ + "16.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-01.4.json b/docs/api/controls/CPL-01.4.json index 0eed6298..5a7678b3 100644 --- a/docs/api/controls/CPL-01.4.json +++ b/docs/api/controls/CPL-01.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -115,9 +115,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -136,9 +136,6 @@ "general-nist-600-1-gen-ai-profile": [ "MP-3.4-003" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-un-155-2021": [ "7.2.2.1", "7.2.2.2" @@ -155,6 +152,9 @@ "609.930(c)(6)(iii)", "609.935(c)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(g)(3)" + ], "usa-federal-law-sox-2002": [ "404(a)", "404(a)(2)", @@ -186,28 +186,67 @@ "Article 43.3", "Article 43.4" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.2", - "Article 10.7", - "Article 13.2(a)", - "Article 24.1", - "Article 24.1(a)", - "Article 24.1(b)", - "Article 24.1(c)" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.1" + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(3)", + "Article 13(12)", + "Article 19(2)(a)", + "Article 32(1)", + "Article 32(1)(a)", + "Article 32(1)(b)", + "Article 32(1)(c)", + "Article 32(1)(d)", + "Article 32(3)", + "Article 32(3)(a)", + "Article 32(3)(b)", + "Article 32(6)" ], "emea-eu-nis2-annex-2024": [ "2.2.1", "2.2.3" ], + "emea-nga-dpr-2019": [ + "4.1(5)", + "4.1(5)a", + "4.1(5)b", + "4.1(5)c", + "4.1(5)d", + "4.1(5)e", + "4.1(5)f", + "4.1(5)g", + "4.1(5)h", + "4.1(5)i", + "4.1(5)j" + ], + "emea-qat-pdppl-2020": [ + "3.11.7" + ], + "emea-esp-decree-311-2022": [ + "Article 31(1)", + "Article 31(2)", + "Article 31(3)", + "Article 31(4)", + "Article 31(5)", + "Article 31(7)" + ], "emea-gbr-caf-4-0": [ "A2.c" ], + "apac-aus-ps-cps-230-2023": [ + "28" + ], "apac-jpn-ismap": [ "4.5.4.3", "4.6.2.2" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "18.1" + ], + "americas-bmu-mba-coc-2020": [ + "5.7-BP3", + "5.11-BP3", + "6.10" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-01.5.json b/docs/api/controls/CPL-01.5.json index acde65b2..1e45d5e2 100644 --- a/docs/api/controls/CPL-01.5.json +++ b/docs/api/controls/CPL-01.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ A formal report is generated for each security assessment/audit with sufficient details to understand the organization's ability to demonstrate conformity with its requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to generate a declaration of conformity for each conformity assessment, where the document:\n(1) Is concise;\n(2) Unambiguously reflects the current status;\n(3) Is physically or electronically signed; and\n(4) Where possible, is machine readable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -133,19 +134,16 @@ "Article 47.3", "Article 47.4" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 4", - "Annex 4.1", - "Annex 4.2", - "Annex 4.3", - "Annex 4.4", - "Annex 4.5", - "Annex 4.6", - "Annex 4.7", - "Annex 4.8", - "Annex 6 Module A.4", - "Annex 6 Module A.4.2", - "Annex 6 Module C.3.2" + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(1)(c)", + "Article 20(5)" + ], + "emea-esp-decree-311-2022": [ + "Article 38(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "8.2", + "18.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-01.6.json b/docs/api/controls/CPL-01.6.json index 157bad0e..c831a822 100644 --- a/docs/api/controls/CPL-01.6.json +++ b/docs/api/controls/CPL-01.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure individuals performing audits and/or assessments have reasonable:\n(1) Professional qualifications to perform the audit and/or assessment; and\n(2) Subject matter expertise to perform review, interview and test activities for in-scope People, Processes, Technologies, Data and/or Facilities (PPTDF).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,13 +76,24 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Compliance", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(4)", + "101.630(f)(4)(i)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7122(a)(1)", "7122(d)" + ], + "apac-mys-bnm-rmit-2025": [ + "16.5" + ], + "apac-sgp-mas-trm-2021": [ + "15.1.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-01.7.json b/docs/api/controls/CPL-01.7.json index cbc7841d..b4775cdb 100644 --- a/docs/api/controls/CPL-01.7.json +++ b/docs/api/controls/CPL-01.7.json @@ -16,10 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to designate an individual the authority to make statements of conformity on behalf of the organization.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define." + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to designate an individual the authority to make statements of conformity on behalf of the organization. ", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { @@ -40,9 +41,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (SOX)", "family_name": "Compliance", "crosswalks": { "usa-federal-law-sox-2002": [ @@ -52,6 +53,9 @@ "302(a)(4)(B)", "302(a)(4)(C)", "302(a)(4)(D)" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 18(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-01.8.json b/docs/api/controls/CPL-01.8.json index 974ee782..bb68ffc3 100644 --- a/docs/api/controls/CPL-01.8.json +++ b/docs/api/controls/CPL-01.8.json @@ -3,7 +3,7 @@ "title": "Conformity Attestations", "family": "CPL", "description": "Mechanisms exist for the certifying official to attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria.", - "scf_question": "Does the organization's certifying official attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria", + "scf_question": "Does the organization have a certifying official attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,10 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists for the certifying official to attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define." + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { @@ -40,9 +41,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (SOX)", "family_name": "Compliance", "crosswalks": { "usa-federal-law-sox-2002": [ diff --git a/docs/api/controls/CPL-01.json b/docs/api/controls/CPL-01.json index cff629bb..58da986a 100644 --- a/docs/api/controls/CPL-01.json +++ b/docs/api/controls/CPL-01.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -122,7 +122,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -285,6 +286,10 @@ "03.04.11.a", "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]", + "A.03.12.01" + ], "general-nist-800-218": [ "PO.1", "PO.1.2" @@ -295,6 +300,11 @@ "GV.SC-05", "PR" ], + "general-nist-cswp-39": [ + "3.1.1", + "3.1.2", + "5.1" + ], "general-pci-dss-4-0-1": [ "12.4", "12.4.2", @@ -304,10 +314,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.2" ], - "general-scf-dpmp-2025": [ - "2.4", - "11.6" - ], "general-shared-assessments-sig-2025": [ "L.1" ], @@ -391,6 +397,18 @@ "PL-01", "PM-08" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(a)", + "101.620(b)(4)", + "101.620(b)(5)", + "101.650(b)", + "101.650(e)", + "101.650(e)(3)", + "101.650(f)", + "101.650(g)", + "101.650(h)", + "101.650(i)" + ], "usa-federal-law-ferpa-2010": [ "1232h(c)(1)(C)(i)" ], @@ -411,20 +429,20 @@ "155.260(e)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)", - "164.504(g)(1)", - "164.530(i)(1)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)", + "§ 164.504(g)(1)", + "§ 164.530(i)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.E.6.1", @@ -478,6 +496,10 @@ "35(a)(1)", "37(a)(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.2(c)", + "603A.525.2(b)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(b)(6)", "500.2(d)", @@ -551,15 +573,30 @@ "Article 21.3", "Article 40.1" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 6", + "Article 6(a)", + "Article 6(b)", + "Article 12(1)(a)", + "Article 12(1)(b)", + "Article 19(7)", + "Article 23(1)", + "Article 23(1)(a)", + "Article 23(1)(b)", + "Article 24(2)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II" + ], "emea-eu-eba-ict-srm-2025": [ - "3.1(1)", - "3.8(92)", - "3.8(93)", - "3.8(94)", - "3.8(95)", - "3.8(96)", - "3.8(97)", - "3.8(98)" + "3.1.1", + "3.8.92", + "3.8.93", + "3.8.94", + "3.8.95", + "3.8.96", + "3.8.97", + "3.8.98" ], "emea-eu-dora-2023": [ "Article 4.1", @@ -570,96 +607,51 @@ "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3", - "29" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-eu-psd2-2015": [ + "97(3)" ], "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" + "3.4.76(5)", + "3.4.77" ], "emea-deu-bsrit-2017": [ - "12.5" + "2.1" ], "emea-deu-c5-2020": [ - "SP-01", + "SA-01-BP6", "PI-02", + "DLL-01-BP2", "COM-01" ], "emea-grc-pirppd-1997": [ - "10" - ], - "emea-hun-isdfi-2011": [ - "7" + "B.5.3" ], - "emea-irl-dpa-2003": [ - "2" + "emea-hun-act-cxii-2011": [ + "II.5.5(2)(b)", + "II.5.6(1)(a)", + "II.5.6(5)(a)" ], - "emea-isr-cmo-1-0": [ - "1.3" + "emea-irl-dpa-2018": [ + "s.83" ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "26", - "31", - "33", - "34", - "35" + "emea-ita-pdpc-2018": [ + "Article 1(1)" ], "emea-ken-pda-2019": [ - "4(a)", - "4(b)(i)", - "4(b)(ii)", - "51(1)", - "51(2)(a)", - "51(2)(b)", - "51(2)(c)", - "52(1)(a)", - "52(1)(b)", - "52(1)(c)", - "52(2)", - "52(3)", - "54", - "55(1)(a)", - "55(1)(b)", - "55(2)" + "IV.37(1)", + "IV.37(1)(a)", + "IV.37(1)(b)", + "IV.37(2)", + "IV.37(3)" ], "emea-nga-dpr-2019": [ "2.1(2)", "2.1(3)", "3.1(16)", - "4.1(1)", - "4.1(6)", - "4.1(7)" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" + "4.1(1)" ], "emea-qat-pdppl-2020": [ - "2" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" - ], - "emea-sau-cscc-1-2019": [ - "1-4" + "3.8" ], "emea-sau-cgiot-2024": [ "1-2-3", @@ -675,45 +667,26 @@ "Article 2.1", "Article 30.3" ], - "emea-sau-sacs-002-2022": [ - "TPC-20", - "TPC-21", - "TPC-43" - ], "emea-sau-sama-csf-1-2017": [ "3.2.2", - "3.2.3", - "3.3.13" + "3.2.2.1", + "3.2.2.1.a", + "3.2.2.1.b", + "3.2.2.1.c" ], "emea-srb-act-9-2018": [ - "5.1", - "13", - "49", - "59" - ], - "emea-zaf-popia-2013": [ - "2", - "3", - "9", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.1", - "Article 39" + "IV.1.49" ], "emea-esp-decree-311-2022": [ - "3.1", - "39" + "Article 37" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.5 [OP.PL.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "2.2.14.1.b", + "2.2.14.1.c", + "2.2.14.1.d" ], "emea-gbr-def-stan-05-138-2024": [ "0001", @@ -738,22 +711,18 @@ "0002", "2314" ], - "apac-aus-privacy-act-1998": [ - "APP Part 11" + "apac-aus-privacy-principles-2026": [ + "1.1.2.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0078", "ISM-0854" ], - "apac-aus-ps-cps-230-2023": [ - "28" + "apac-aus-cop-sitc-2020": [ + "5" ], - "apac-aus-ps-cps-234-2019": [ - "31", - "35", - "35(a)", - "35(b)", - "36" + "apac-aus-ps-cps-230-2023": [ + "12" ], "apac-chn-cybersecurity-law-2017": [ "Article 9", @@ -768,19 +737,11 @@ "Article 47" ], "apac-chn-data-security-law-2021": [ - "46" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "32", - "37", - "38(4)", - "42" + "Article 27", + "Article 32" ], "apac-hkg-pdo-2022": [ - "Principle 4" + "4" ], "apac-ind-dpdpa-2023": [ "7(c)", @@ -789,42 +750,17 @@ "8(1)", "8(4)" ], - "apac-ind-privacy-rules-2011": [ - "8" - ], "apac-ind-sebi-2024": [ "GV.OC.S2", "PR.IP.S13", "RS.MA.S5" ], - "apac-jpn-ppi-2020": [ - "20", - "21", - "22", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" + "apac-jpn-appi-2020": [ + "IV.1.16-2", + "IV.1.26(1)", + "IV.1.26(1)(i)", + "IV.1.26(1)(ii)", + "IV.1.26(2)" ], "apac-jpn-ismap": [ "4.4.2.1", @@ -841,10 +777,7 @@ "18.1.1.7.P", "18.1.5.7.PB" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP29", "HML29" ], @@ -856,47 +789,37 @@ "1.1.65.C.01", "1.1.66.C.01", "1.1.66.C.02", - "1.1.67.C.01" + "1.1.67.C.01", + "1.2.15.C.01", + "1.2.15.C.02", + "17.9.37.C.01" + ], + "apac-nzl-privacy-act-2020": [ + "6.2.126(1)", + "6.2.126(2)", + "6.2.126(2)(a)", + "6.2.126(2)(b)" ], "apac-phl-dpa-2012": [ - "25" + "III.11" ], "apac-sgp-pdpa-2012": [ - "24" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "3.1(a)", - "3.1(b)", - "3.1(c)" - ], - "apac-sgp-mas-trm-2021": [ - "3.2.3" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "27" - ], - "americas-arg-ppd-2018": [ - "10.1", - "10.2" + "3.11(2)" ], "americas-bhs-dpa-2003": [ - "6" + "II.4(1)", + "IV.24(6)", + "IV.24(7)", + "IV.24(7)(a)", + "IV.24(7)(b)", + "V.45(4)(a)", + "V.45(4)(b)", + "V.45(5)", + "V.45(6)", + "V.45(7)" ], "americas-bra-lgpd-2018": [ - "7.1", - "7.2", - "7.3", - "7.4", - "7.5", - "7.6", - "7.7", - "7.8", - "7.9", - "7.10" + "VII.I.46.2" ], "americas-can-osfi-b13-2022": [ "1.3.1" @@ -906,16 +829,13 @@ "03.12.01" ], "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" + "P1-4.1", + "P1-4.1.3" ], "americas-col-law-1581-2012": [ - "4" - ], - "americas-mex-fdpa-2010": [ - "19" + "VI.17", + "VI.17(o)", + "VI.18" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-02.1.json b/docs/api/controls/CPL-02.1.json index 43040c67..65ea1bb0 100644 --- a/docs/api/controls/CPL-02.1.json +++ b/docs/api/controls/CPL-02.1.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to implement an internal audit function that is capable of providing senior organization management with insights into the appropriateness of the organization's technology and information governance processes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -110,7 +110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -203,7 +204,8 @@ "03.12.01" ], "general-nist-800-171a-r3": [ - "A.03.12.01.ODP[01]" + "A.03.12.01.ODP[01]", + "A.03.12.01" ], "general-tisax-6-0-3": [ "1.5.1", @@ -222,60 +224,36 @@ "5.260.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.3.6(25)" + "3.3.1.11", + "3.3.6.25" ], "emea-eu-nis2-annex-2024": [ "2.3.2" ], + "emea-deu-c5-2020": [ + "SPN-03" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 5" + ], "emea-sau-cscc-1-2019": [ - "1-4-2", - "2-13-4" + "1-4-2" ], "emea-sau-ecc-1-2018": [ - "1-8-1", "1-8-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.5" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 41.1", - "Article 41.2" - ], - "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "41.1", - "41.2" + "3.2.5.1" ], "apac-aus-ps-cps-230-2023": [ - "46", - "60" + "46" ], "apac-aus-ps-cps-234-2019": [ - "31", "32", - "33", "34", "34(a)", "34(b)" ], - "apac-chn-pipl-2021": [ - "54" - ], "apac-ind-dpdpa-2023": [ "10(2)(b)" ], @@ -283,7 +261,10 @@ "4.6.2.2", "4.6.2.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "13.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -292,19 +273,7 @@ ], "apac-sgp-mas-trm-2021": [ "15.1.1", - "15.1.2", - "15.1.3", - "15.1.4" - ], - "americas-bmu-mba-coc-2020": [ - "5.4", - "5.6" - ], - "amaericas-can-osfi-self-assessment": [ - "6.17", - "6.18", - "6.19", - "6.20" + "15.1.2" ], "americas-can-itsp-10-171-2025": [ "03.12.01" diff --git a/docs/api/controls/CPL-02.2.json b/docs/api/controls/CPL-02.2.json index 891fbc46..84f9c26f 100644 --- a/docs/api/controls/CPL-02.2.json +++ b/docs/api/controls/CPL-02.2.json @@ -3,7 +3,7 @@ "title": "Periodic Audits", "family": "CPL", "description": "Mechanisms exist to conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures.", - "scf_question": "Does the organization conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures?", + "scf_question": "Does the organization conduct periodic audits of security, compliance and resilience controls to evaluate conformity with its documented policies, standards and procedures?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,17 +16,23 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.\n▪ Specialized assessments are conducted for specific statutory, regulatory and/or contractual compliance obligations, as well as business-critical TAASD.\n▪ IT and/or cybersecurity use an impartial member of its team or a third-party assessor to perform an independent assessment of cybersecurity and data protection controls.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Annual self-assessment against applicable compliance requirements\n∙ External compliance review if contractually required", + "small": "∙ Annual internal review of key security controls\n∙ External audit for compliance requirements", + "medium": "∙ Internal audit program\n∙ Annual external compliance audits\n∙ GRC platform for audit tracking.", + "large": "∙ Enterprise internal audit function\n∙ Annual external audits.\n∙ GRC platform with audit management", + "enterprise": "∙ Enterprise internal audit program with dedicated resources\n∙ Multiple external compliance audits\n∙ Continuous control monitoring and automated audit reporting" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -100,9 +106,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-cobit-2019": [ @@ -123,6 +129,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(6)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(3)" + ], "usa-state-nv-regulation-5-2024": [ "5.260.5(b)" ], @@ -133,9 +142,22 @@ "2.3.2", "2.3.4" ], + "emea-deu-c5-2020": [ + "RB-05-DOAR", + "SPN-02", + "SPN-02-DOAR", + "COM-02", + "COM-02-BP1", + "COM-02-BP2", + "COM-02-BP3", + "COM-03" + ], "emea-sau-cgiot-2024": [ "1-7-1" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.5.2" + ], "emea-gbr-def-stan-05-138-2024": [ "1206" ], @@ -150,6 +172,17 @@ ], "apac-ind-sebi-2024": [ "DE.CM.S5" + ], + "apac-nzl-ism-3-9": [ + "17.9.33.C.01", + "17.9.33.C.02", + "17.9.33.C.03" + ], + "apac-sgp-mas-trm-2021": [ + "15.1.3" + ], + "americas-arg-ppd-2018": [ + "E.1.4-DS-2" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-02.3.json b/docs/api/controls/CPL-02.3.json index 48678829..b2c58bdf 100644 --- a/docs/api/controls/CPL-02.3.json +++ b/docs/api/controls/CPL-02.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to take corrective action to remediate instances of non-conformity with applicable statutory, regulatory, and/or contractual compliance obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -26,7 +26,13 @@ "CORE AI Model Deployment", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Corrective action log (spreadsheet)\n∙ Documented remediation plans for audit findings", + "small": "∙ Corrective action register with remediation tracking\n∙ Management review of open findings", + "medium": "∙ Formal corrective action plan process\n∙ GRC platform for finding tracking and remediation\n∙ Management review of open findings", + "large": "∙ Enterprise corrective action management program\n∙ GRC platform with workflow-driven remediation tracking\n∙ Executive reporting on open findings", + "enterprise": "∙ Enterprise GRC platform for corrective action management\n∙ Automated finding tracking and escalation workflows\n∙ Board-level reporting on material findings" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -100,13 +106,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { "general-iso-29100-2024": [ "6.12" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(7)" + ], "emea-eu-ai-act-2024": [ "Article 79.4", "Article 80.4", @@ -115,11 +125,6 @@ "Article 93.1(a)", "Article 93.1(b)", "Article 93.1(c)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.12", - "Article 13.6", - "Article 14.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-02.json b/docs/api/controls/CPL-02.json index 70be4f0a..da2beb18 100644 --- a/docs/api/controls/CPL-02.json +++ b/docs/api/controls/CPL-02.json @@ -3,7 +3,7 @@ "title": "Security, Compliance & Resilience Controls Oversight", "family": "CPL", "description": "Mechanisms exist to provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership.", - "scf_question": "Does the organization provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership?", + "scf_question": "Does the organization provide a security, compliance and resilience controls oversight function that reports to its executive leadership?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -24,7 +24,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.\n▪ A formal report is generated for each security assessment/audit with sufficient details to understand the organization's ability to demonstrate conformity with its requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -116,9 +116,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -213,7 +213,7 @@ "general-iso-31000-2018": [ "6.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -506,10 +506,19 @@ "3.12.3" ], "general-nist-800-171a-r3": [ + "A.03.12.01", "A.03.12.03[01]", "A.03.12.03[03]", "A.03.12.03[04]" ], + "general-nist-800-172-r3": [ + "03.12.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.03E[02]", + "DS-A.03.12.03E[03]", + "DS-A.03.12.03E[04]" + ], "general-nist-csf-2-0": [ "GV.OC-03" ], @@ -528,9 +537,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "11.4" - ], "general-tisax-6-0-3": [ "1.5.1", "5.2.6" @@ -611,6 +617,9 @@ "CA-07(01)", "PM-14" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(7)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(1)" ], @@ -618,12 +627,12 @@ "155.260(a)(3)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.D.3", @@ -676,122 +685,42 @@ "2447(b)(8)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.1.11", + "3.3.3.19", + "3.3.6.25", + "3.4.6.41", + "3.4.6.46", + "3.4.6.48" ], "emea-eu-gdpr-2016": [ "Article 32.1(d)" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" - ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "SP-03" - ], - "emea-grc-pirppd-1997": [ - "10" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "1.3", - "3.1" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35" - ], - "emea-nga-dpr-2019": [ - "4.1(5)(a)", - "4.1(5)(b)", - "4.1(5)(c)", - "4.1(5)(d)", - "4.1(5)(e)", - "4.1(5)(f)", - "4.1(5)(g)", - "4.1(5)(h)", - "4.1(5)(i)", - "4.1(5)(j)", - "4.1(6)", - "4.1(7)" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" + "RB-05-DOAR", + "SPN-02", + "COM-02" ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" + "emea-isr-cmo-2-0": [ + "4.1, Stage 5" + ], + "emea-qat-pdppl-2020": [ + "3.11.7" ], "emea-sau-cscc-1-2019": [ - "1-4" + "1-4-1" ], "emea-sau-cgiot-2024": [ "1-7-3" ], "emea-sau-ecc-1-2018": [ - "1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1" + "1-8-1", + "1-8-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.4" - ], - "emea-zaf-popia-2013": [ - "8", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1", - "Article 10.2", - "Article 10.3" + "3.2.5" ], "emea-esp-decree-311-2022": [ - "10.1", - "10.2", - "10.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "Article 16(1)" ], "emea-gbr-def-stan-05-138-2024": [ "1206" @@ -802,42 +731,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1206" ], - "apac-aus-privacy-act-1998": [ - "APP Part 11" - ], "apac-aus-ps-cps-230-2023": [ - "29", - "30", + "58", + "58(a)", "58(b)", "58(c)" ], "apac-aus-ps-cps-234-2019": [ - "27", - "27(a)", - "27(b)", - "27(c)", - "27(d)", - "27(e)", - "29" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "54" - ], - "apac-hkg-pdo-2022": [ - "Principle 4" - ], - "apac-ind-privacy-rules-2011": [ - "8" + "29", + "31" ], "apac-ind-sebi-2024": [ "EV.ST.S4" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "4.6.1.1", "4.6.2.2", @@ -846,10 +752,10 @@ "12.7.1.8", "12.7.1.9" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "13.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -860,34 +766,18 @@ "6.1.7.C.01", "23.2.18.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24" - ], "apac-sgp-mas-trm-2021": [ - "3.2.3" - ], - "apac-twn-pdpa-2025": [ - "27" + "3.2.3", + "15.1.1" ], "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.10" + "5.4", + "5.6", + "5.7-BP2" ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-03.1.json b/docs/api/controls/CPL-03.1.json index b9f6ca6b..5bdce284 100644 --- a/docs/api/controls/CPL-03.1.json +++ b/docs/api/controls/CPL-03.1.json @@ -104,9 +104,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-cobit-2019": [ @@ -186,6 +186,10 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-07(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(4)(ii)", + "101.630(f)(4)(iii)" + ], "usa-federal-irs-1075-2021": [ "CA-7(CE-1)" ], @@ -201,26 +205,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(c)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module H.3.1", - "Annex 6 Module H.3.5" - ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(25)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)(a)", - "3.4.6(43)(b)" + "3.3.6.25", + "3.4.6.41" ], "emea-eu-nis2-annex-2024": [ "2.3.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-c5-2020": [ - "COM-03" - ], "emea-sau-cscc-1-2019": [ "1-4-2" ], @@ -231,26 +222,9 @@ "1-8-2" ], "emea-sau-otcc-1-2022": [ - "1-6-1", "1-6-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-20", - "TPC-21" - ], - "emea-zaf-popia-2013": [ - "60" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 38.1" - ], - "emea-esp-decree-311-2022": [ - "38.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0100" ], "apac-aus-ps-cps-234-2019": [ @@ -259,11 +233,6 @@ "apac-chn-cybersecurity-law-2017": [ "Article 38" ], - "apac-chn-pipl-2021": [ - "38(1)", - "38(2)", - "40" - ], "apac-ind-dpdpa-2023": [ "10(2)(b)" ], @@ -283,12 +252,13 @@ "18.2.1.10.P", "18.2.1.13.P" ], + "apac-mys-bnm-rmit-2025": [ + "13.4", + "14.1", + "14.2" + ], "apac-nzl-ism-3-9": [ "6.1.8.C.01" - ], - "amaericas-can-osfi-self-assessment": [ - "6.13", - "6.25" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-03.2.json b/docs/api/controls/CPL-03.2.json index ebc0fa4f..e957658f 100644 --- a/docs/api/controls/CPL-03.2.json +++ b/docs/api/controls/CPL-03.2.json @@ -3,7 +3,7 @@ "title": "Functional Review Of Security, Compliance & Resilience Controls", "family": "CPL", "description": "Mechanisms exist to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards.", - "scf_question": "Does the organization regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards?", + "scf_question": "Does the organization regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to its security, compliance and/or resilience policies and standards?", "relative_weight": 8, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -111,9 +111,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -237,10 +237,13 @@ "RA-3" ], "general-nist-800-171-r3": [ + "03.04.02.b", "03.04.08.c", "03.12.03" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.08.c", "A.03.12.03[02]" ], "general-nist-csf-2-0": [ @@ -311,14 +314,14 @@ "RA-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "usa-federal-irs-1075-2021": [ "CA-2", @@ -345,69 +348,18 @@ "RA-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41" ], "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3" - ], "emea-deu-bsrit-2017": [ "5.6" ], - "emea-deu-c5-2020": [ - "COM-01" - ], - "emea-isr-cmo-1-0": [ - "3.1", - "3.3", - "12.30" - ], - "emea-qat-pdppl-2020": [ - "11.7", - "11.8" - ], - "emea-sau-cscc-1-2019": [ - "1-4-1" - ], "emea-sau-cgiot-2024": [ "1-7-1" ], - "emea-sau-ecc-1-2018": [ - "1-8-1" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 38.1" - ], - "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "38.1" - ], "emea-gbr-def-stan-05-138-2024": [ "1206" ], @@ -417,8 +369,8 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1206" ], - "apac-chn-pipl-2021": [ - "54" + "apac-aus-ps-cps-234-2019": [ + "33" ], "apac-ind-sebi-2024": [ "DE.CM.S5" @@ -437,12 +389,14 @@ "23.2.18.C.01" ], "apac-sgp-mas-trm-2021": [ - "4.5.1" + "4.5.1", + "11.2.8" ], "americas-bmu-mba-coc-2020": [ - "5.7" + "5.7-BP1" ], "americas-can-itsp-10-171-2025": [ + "03.04.02.B", "03.04.08.C", "03.12.03" ] diff --git a/docs/api/controls/CPL-03.3.json b/docs/api/controls/CPL-03.3.json index 03e936c6..3aa9e3d3 100644 --- a/docs/api/controls/CPL-03.3.json +++ b/docs/api/controls/CPL-03.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to grant assessors minimum necessary access to conduct conformity assessments, including:\n(1) Logical access to design, development, production, inspection and testing artifacts; and \n(2) Physical access to facilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -119,13 +120,6 @@ "IV.C.2.e.iii", "IV.C.2.e.iv", "IV.C.2.f" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 13.8", - "Article 14.5" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module H.4.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-03.4.json b/docs/api/controls/CPL-03.4.json index 190edbe8..817541ff 100644 --- a/docs/api/controls/CPL-03.4.json +++ b/docs/api/controls/CPL-03.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define acceptable methods to conduct a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-03.5.json b/docs/api/controls/CPL-03.5.json index bdf709a9..d4c1d210 100644 --- a/docs/api/controls/CPL-03.5.json +++ b/docs/api/controls/CPL-03.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define the level of assessment rigor necessary to conduct a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-03.6.json b/docs/api/controls/CPL-03.6.json index c091abe9..30faa3df 100644 --- a/docs/api/controls/CPL-03.6.json +++ b/docs/api/controls/CPL-03.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define an Evidence Request List (ERL) prior to the start of a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-03.7.json b/docs/api/controls/CPL-03.7.json index ceef54bd..cdf55cf4 100644 --- a/docs/api/controls/CPL-03.7.json +++ b/docs/api/controls/CPL-03.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define evidence sampling criteria for cybersecurity and/or data protection assessments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-03.8.json b/docs/api/controls/CPL-03.8.json new file mode 100644 index 00000000..e5780894 --- /dev/null +++ b/docs/api/controls/CPL-03.8.json @@ -0,0 +1,114 @@ +{ + "control_id": "CPL-03.8", + "title": "Continuous Control Monitoring (CCM)", + "family": "CPL", + "description": "Automated mechanisms exist to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "scf_question": "Does the organization use automated mechanisms to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Periodic manual control reviews", + "small": "∙ GRC solution with control tracking\n∙ Regular control status reviews", + "medium": "∙ GRC platform with control monitoring\n∙ Regular automated control status reporting", + "large": "∙ GRC platform with continuous control monitoring\n∙ Integration with SIEM and vulnerability management\n∙ Automated control evidence collection", + "enterprise": "∙ Enterprise continuous control monitoring platform\n∙ Automated evidence collection and control testing\n∙ Real-time control dashboards\n∙ Integration with GRC, SIEM, and asset management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-1", + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Compliance", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/CPL-03.json b/docs/api/controls/CPL-03.json index d116b26d..6bf16797 100644 --- a/docs/api/controls/CPL-03.json +++ b/docs/api/controls/CPL-03.json @@ -1,9 +1,9 @@ { "control_id": "CPL-03", - "title": "Security, Compliance & Resilience Assessments", + "title": "Control Conformity Monitoring", "family": "CPL", - "description": "Mechanisms exist to regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", - "scf_question": "Does the organization regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements?", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "scf_question": "Does the organization validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to its security, compliance and/or resilience policies, standards and other applicable requirements?", "relative_weight": 10, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -21,7 +21,7 @@ "0": "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.", "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments. \n▪ For specific statutory, regulatory and/or contractual obligations, stakeholders may contract with a third-party auditor/assessor to perform an independent assessment of cybersecurity and data protection controls.", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -32,8 +32,8 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", - "small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", + "micro_small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, SimpleRisk, etc.)", + "small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, SimpleRisk, etc.)", "medium": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", "large": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", "enterprise": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)" @@ -109,9 +109,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", + "errata": "- renamed control\n- wordsmithed control", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -242,10 +243,8 @@ "03.12.03" ], "general-nist-800-171a-r3": [ - "A.03.12.01" - ], - "general-nist-800-172": [ - "3.11.5e" + "A.03.12.01", + "A.03.12.03[01]" ], "general-nist-csf-2-0": [ "ID.IM-01", @@ -269,9 +268,6 @@ "10.7.3", "12.4.2" ], - "general-scf-dpmp-2025": [ - "11.3" - ], "general-tisax-6-0-3": [ "1.5.2", "5.2.6" @@ -306,16 +302,20 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(1)", + "101.630(f)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "usa-federal-irs-1075-2021": [ "CA-2" @@ -344,119 +344,106 @@ "CA-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41", + "3.4.6.44" ], "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3", - "29" - ], "emea-deu-bsrit-2017": [ + "3.7", "5.6" ], "emea-deu-c5-2020": [ - "COM-03" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "3.1" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" + "OIS-01-BP2", + "OIS-01-BP3" ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-qat-pdppl-2020": [ - "11.7", - "11.8" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-sau-cscc-1-2019": [ - "1-4-1", - "2-13-4" + "emea-isr-cmo-2-0": [ + "4.2, Stage 5" ], "emea-sau-ecc-1-2018": [ "1-3-2", - "1-8-1" + "1-8-1", + "1-8-2", + "2-2-4" ], "emea-sau-otcc-1-2022": [ - "1-6", + "1-4-2", + "1-5-4", "1-6-1", - "1-6-2" + "1-7-2", + "2-1-2", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-7-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-1-9", + "2-13-2", + "3-1-2", + "4-1-2" ], "emea-sau-sama-csf-1-2017": [ "3.2.4", - "3.2.5" - ], - "emea-zaf-popia-2013": [ - "8", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7" + "3.2.4.1", + "3.2.4.2", + "3.2.4.3", + "3.2.4.4", + "3.2.4.5", + "3.2.4.5.a", + "3.2.4.5.b", + "3.2.4.5.c", + "3.3.1.2", + "3.3.2.2", + "3.3.3.2", + "3.3.4.2", + "3.3.5.2", + "3.3.5.3", + "3.3.6.2", + "3.3.6.3", + "3.3.7.2", + "3.3.7.3", + "3.3.8.2", + "3.3.8.3", + "3.3.9.2", + "3.3.9.3", + "3.3.10.2", + "3.3.10.3", + "3.3.11.2", + "3.3.11.3", + "3.3.14.2", + "3.3.14.4.i", + "3.3.14.4.l", + "3.3.15", + "3.3.15.2", + "3.3.16", + "3.3.16.2", + "3.3.17.2", + "3.4.1.2", + "3.4.1.3", + "3.4.2", + "3.4.2.2", + "3.4.3.2" ], "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7" - ], - "apac-aus-ps-cps-234-2019": [ - "30" + "Article 15(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], - "apac-chn-pipl-2021": [ - "38(1)", - "38(2)", - "40" + "apac-aus-ps-cps-230-2023": [ + "30" ], "apac-ind-sebi-2024": [ "EV.ST.S5" ], - "apac-jpn-ppi-2020": [ - "40(1)", - "40(2)", - "40(3)" - ], "apac-jpn-ismap": [ "4.6.2.3", "4.6.2.5", @@ -479,8 +466,9 @@ "18.2.2.7", "18.2.2.8" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "11.9", + "13.1" ], "apac-nzl-ism-3-9": [ "4.3.16.C.01", @@ -488,24 +476,27 @@ "6.1.9.C.01", "23.2.18.C.01" ], - "apac-phl-dpa-2012": [ - "25" + "apac-sgp-mas-trm-2021": [ + "4.5.1", + "9.1.6", + "11.2.8" ], - "apac-sgp-pdpa-2012": [ - "24" + "americas-arg-ppd-2018": [ + "E.1.4-DS-1" ], - "apac-sgp-mas-trm-2021": [ - "4.5.1" + "americas-bhs-dpa-2003": [ + "VI.55", + "VI.55(a)", + "VI.55(b)" ], - "amaericas-can-osfi-self-assessment": [ - "6.10" + "americas-bmu-mba-coc-2020": [ + "5.7", + "6.21", + "6.22" ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03" - ], - "americas-chl-act-19628-1999": [ - "7" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-04.json b/docs/api/controls/CPL-04.json index 38363040..10788008 100644 --- a/docs/api/controls/CPL-04.json +++ b/docs/api/controls/CPL-04.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to thoughtfully plan audits by including input from operational risk and compliance partners to minimize the impact of audit-related activities on business operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -108,13 +109,6 @@ ], "general-nist-100-1-ai-rmf": [ "GOVERN 1.5" - ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-c5-2020": [ - "COM-02", - "COM-03" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-05.1.json b/docs/api/controls/CPL-05.1.json index eb16de08..f0036449 100644 --- a/docs/api/controls/CPL-05.1.json +++ b/docs/api/controls/CPL-05.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to notify customers about investigation request notifications, unless the applicable legal basis for a government agency's action prohibits notification (e.g., potential criminal prosecution).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -100,18 +100,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { "general-csa-cmm-4-1-0": [ "DSP-18" ], - "emea-deu-c5-2020": [ - "INQ-02" - ], - "apac-chn-pipl-2021": [ - "18" + "apac-sgp-pdpa-2012": [ + "5.21(4)" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-05.2.json b/docs/api/controls/CPL-05.2.json index 8a3dfea0..f0c68cf0 100644 --- a/docs/api/controls/CPL-05.2.json +++ b/docs/api/controls/CPL-05.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to support official investigations by provisioning government investigators with \"least privileges\" and \"least functionality\" to ensure that government investigators only have access to the TAASD needed to perform the investigation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -112,6 +113,9 @@ "usa-federal-doc-data-privacy-framework-2023": [ "III.5.b.ii" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(6)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(e)", "500.17(a)(2)" @@ -125,23 +129,21 @@ "emea-eu-ai-act-2024": [ "Article 21.2" ], - "emea-deu-c5-2020": [ - "INQ-03", - "INQ-04" + "emea-eu-cyber-resilience-act-2024": [ + "Article 53" + ], + "emea-aut-dpa-2018": [ + "§ 51", + "§ 52", + "§ 53" + ], + "emea-che-fadp-2025": [ + "2.2.15.2" ], "apac-chn-cybersecurity-law-2017": [ "Article 28", "Article 55", "Article 56" - ], - "apac-chn-pipl-2021": [ - "61(4)", - "63", - "63(1)", - "63(2)", - "63(3)", - "63(4)", - "64" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-05.json b/docs/api/controls/CPL-05.json index 93218bdb..4310002e 100644 --- a/docs/api/controls/CPL-05.json +++ b/docs/api/controls/CPL-05.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with the organization's legal counsel for guidance on how to respond to legal orders (e.g., court orders, investigations, etc.).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to determine whether a government agency has an applicable and valid legal basis to request data from the organization and what further steps need to be taken, if necessary.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -128,14 +129,16 @@ "Article 92.4", "Article 92.5" ], - "emea-deu-c5-2020": [ - "INQ-01" - ], "apac-chn-cybersecurity-law-2017": [ "Article 72" ], - "apac-chn-pipl-2021": [ - "41" + "apac-sgp-pdpa-2012": [ + "3.12(d)", + "3.12(d)(i)", + "3.12(d)(ii)" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-06.json b/docs/api/controls/CPL-06.json index 4cd6f8f7..0da3f229 100644 --- a/docs/api/controls/CPL-06.json +++ b/docs/api/controls/CPL-06.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to constrain the host government from having unrestricted and non-monitored access to the organization's TAASD that could potentially violate other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -91,24 +92,11 @@ "Article 29" ], "apac-chn-data-security-law-2021": [ - "24", - "27", - "31", - "33", - "44" + "Article 27", + "Article 31" ], "apac-chn-pipl-2021": [ - "11", - "12", - "26", - "38(4)", - "40", - "47(5)", - "60", - "61(4)", - "63(3)", - "63(4)", - "64" + "Article 38" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-07.1.json b/docs/api/controls/CPL-07.1.json index 73164fd5..dd8838a4 100644 --- a/docs/api/controls/CPL-07.1.json +++ b/docs/api/controls/CPL-07.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to respond to legitimate grievances related to the organization's cybersecurity and/or data protection practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { diff --git a/docs/api/controls/CPL-07.json b/docs/api/controls/CPL-07.json index cd636876..5ba8f4ac 100644 --- a/docs/api/controls/CPL-07.json +++ b/docs/api/controls/CPL-07.json @@ -3,7 +3,7 @@ "title": "Grievances", "family": "CPL", "description": "Mechanisms exist to govern the intake and analysis of grievances related to the organization's cybersecurity and/or data protection practices.", - "scf_question": "Does the organization govern the intake, analysis, assignment and remediation of grievances related to its cybersecurity and/or data protection practices?", + "scf_question": "Does the organization govern the intake and analysis of grievances related to its cybersecurity and/or data protection practices?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,15 +88,34 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(17)" + ], + "apac-aus-privacy-principles-2026": [ + "1.1.2.b" + ], "apac-ind-dpdpa-2023": [ "13(1)" ], + "apac-ind-privacy-rules-2011": [ + "5(9)" + ], + "apac-jpn-appi-2020": [ + "IV.5.52(1)", + "IV.5.52(2)", + "IV.5.52(3)" + ], "apac-jpn-ismap": [ "18.1.2.13.PB" + ], + "apac-mys-bnm-rmit-2025": [ + "10.35", + "12.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-08.1.json b/docs/api/controls/CPL-08.1.json index 70b3dae5..a67bdc49 100644 --- a/docs/api/controls/CPL-08.1.json +++ b/docs/api/controls/CPL-08.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to contract localized representation to perform specified functions in regard to representing statutory and/or regulatory compliance matters.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -114,7 +114,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -127,16 +128,6 @@ "Article 54.3(d)", "Article 54.4", "Article 54.5" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 12.3", - "Article 12.3(a)", - "Article 12.3(b)", - "Article 12.3(c)" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-08.json b/docs/api/controls/CPL-08.json index 4ce8746c..45273849 100644 --- a/docs/api/controls/CPL-08.json +++ b/docs/api/controls/CPL-08.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to appoint localized representation with a physical presence in localities, as required by applicable laws and/or regulations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -114,7 +114,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -125,12 +126,19 @@ "Article 23.1(d)", "Article 54.1" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 12.1" + "emea-sau-ecc-1-2018": [ + "4-1-3-2" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" + "emea-srb-act-9-2018": [ + "IV.1.44" + ], + "emea-che-fadp-2025": [ + "2.2.14.1", + "2.2.14.2", + "2.2.14.3" + ], + "apac-chn-pipl-2021": [ + "Article 53" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-09.json b/docs/api/controls/CPL-09.json index 91321bb0..be6b4b6c 100644 --- a/docs/api/controls/CPL-09.json +++ b/docs/api/controls/CPL-09.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define instances of control reciprocity within assessment boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -49,7 +49,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-10.json b/docs/api/controls/CPL-10.json index 98f0a379..c94a6c3d 100644 --- a/docs/api/controls/CPL-10.json +++ b/docs/api/controls/CPL-10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define instances of control inheritance within assessment boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -49,7 +49,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-11.1.json b/docs/api/controls/CPL-11.1.json index 4111f2e7..160f8350 100644 --- a/docs/api/controls/CPL-11.1.json +++ b/docs/api/controls/CPL-11.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify if the organization handles United States Munitions List (USML) or Commerce Control List (CCL):\n(1) Items;\n(2) Technical data; and/or\n(3) Provides defense services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,7 +92,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-11.2.json b/docs/api/controls/CPL-11.2.json index ff260d31..49ba09ea 100644 --- a/docs/api/controls/CPL-11.2.json +++ b/docs/api/controls/CPL-11.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict logical and physical access to United States (US) export-controlled data to US: \n(1) Citizens; and/or\n(2) Green Card holders.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,7 +92,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-11.3.json b/docs/api/controls/CPL-11.3.json index 6b376046..c0af5d32 100644 --- a/docs/api/controls/CPL-11.3.json +++ b/docs/api/controls/CPL-11.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to generate detailed logs of export-controlled data including:\n(1) Logical and physical access; and\n(2) Export activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,7 +92,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-11.json b/docs/api/controls/CPL-11.json index cfa36272..66f7e120 100644 --- a/docs/api/controls/CPL-11.json +++ b/docs/api/controls/CPL-11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern technologies and/or data that have potential:\n(1) \"Dual-use” capabilities for civil and military;\n(2) Use by terrorists; and/or \n(3) Weapons of Mass Destruction (WMD) applications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,7 +92,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} diff --git a/docs/api/controls/CPL-12.json b/docs/api/controls/CPL-12.json index dc8a2be7..8b834cd3 100644 --- a/docs/api/controls/CPL-12.json +++ b/docs/api/controls/CPL-12.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce a Statement of Applicability (SOA), or similar document, for compliance-related scoping activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -44,7 +44,8 @@ "MT-8", "MT-9", "MT-14", - "MT-15" + "MT-15", + "MT-28" ], "family_name": "Compliance", "crosswalks": { diff --git a/docs/api/controls/CPL-13.1.json b/docs/api/controls/CPL-13.1.json index d8e64657..95c16fc2 100644 --- a/docs/api/controls/CPL-13.1.json +++ b/docs/api/controls/CPL-13.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce evidence of due diligence activities performed, capable of withstanding external audit or regulatory scrutiny.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45,13 +45,17 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control", "family_name": "Compliance", "crosswalks": { "apac-jpn-ismap": [ "4.6.2.7" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.21" ] } } \ No newline at end of file diff --git a/docs/api/controls/CPL-13.2.json b/docs/api/controls/CPL-13.2.json index 44146fd1..9e719d0f 100644 --- a/docs/api/controls/CPL-13.2.json +++ b/docs/api/controls/CPL-13.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce evidence of due care activities performed, capable of withstanding external audit or regulatory scrutiny.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -45,9 +45,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control", "family_name": "Compliance", "crosswalks": { "apac-jpn-ismap": [ diff --git a/docs/api/controls/CPL-13.json b/docs/api/controls/CPL-13.json index c90a6eac..f581651b 100644 --- a/docs/api/controls/CPL-13.json +++ b/docs/api/controls/CPL-13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce work products (e.g., process artifacts) that demonstrate the ability to comply with applicable requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -41,9 +41,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (CERT-RMM 1.2)", "family_name": "Compliance", "crosswalks": { "general-iso-21434-2021": [ @@ -108,6 +108,9 @@ "VAR:GG3.GP2", "GG1.GP1", "GG3.GP2" + ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.640" ] } } \ No newline at end of file diff --git a/docs/api/controls/CRY-01.1.json b/docs/api/controls/CRY-01.1.json index 78644d54..d01f1cdc 100644 --- a/docs/api/controls/CRY-01.1.json +++ b/docs/api/controls/CRY-01.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of information as an alternative to physical safeguards.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of information as an alternative to physical safeguards. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -140,6 +141,9 @@ "3.13.8[b]", "3.13.8[c]" ], + "general-nist-800-171a-r3": [ + "A.03.13.08[02]" + ], "general-nist-csf-2-0": [ "PR.DS-01" ], @@ -174,9 +178,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-08 (01)" ], - "emea-isr-cmo-1-0": [ - "15.7" - ], "americas-can-itsp-10-171-2025": [ "03.13.08" ] diff --git a/docs/api/controls/CRY-01.2.json b/docs/api/controls/CRY-01.2.json index 3827d179..80067640 100644 --- a/docs/api/controls/CRY-01.2.json +++ b/docs/api/controls/CRY-01.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to address the exporting of cryptographic technologies in compliance with relevant statutory and regulatory requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -50,7 +50,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-01.3.json b/docs/api/controls/CRY-01.3.json index 57b31859..e05caf0d 100644 --- a/docs/api/controls/CRY-01.3.json +++ b/docs/api/controls/CRY-01.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to ensure the confidentiality and integrity of information during preparation for transmission and during reception.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -55,7 +55,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -86,7 +87,7 @@ "usa-federal-cms-marse-2-0": [ "SC-8(2)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0548", "ISM-0554" ] diff --git a/docs/api/controls/CRY-01.4.json b/docs/api/controls/CRY-01.4.json index 81572f59..0f3fecc7 100644 --- a/docs/api/controls/CRY-01.4.json +++ b/docs/api/controls/CRY-01.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to conceal or randomize communication patterns.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-01.5.json b/docs/api/controls/CRY-01.5.json index d5bb0057..245ec336 100644 --- a/docs/api/controls/CRY-01.5.json +++ b/docs/api/controls/CRY-01.5.json @@ -6,7 +6,9 @@ "scf_question": "Does the organization identify, document and review deployed cryptographic cipher suites and protocols to proactively respond to industry trends regarding the continued viability of utilized cryptographic cipher suites and protocols?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", - "evidence_requests": [], + "evidence_requests": [ + "E-QTS-04" + ], "pptdf": "Process", "nist_csf_function": "Protect", "scrm_focus": { @@ -16,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to identify, document and review deployed cryptographic cipher suites and protocols to proactively respond to industry trends regarding the continued viability of utilized cryptographic cipher suites and protocols.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52,13 +54,20 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { "general-nist-800-171-r3": [ "03.13.11" ], + "general-nist-800-171a-r3": [ + "A.03.13.11" + ], + "general-nist-cswp-39": [ + "3.1" + ], "general-pci-dss-4-0-1": [ "12.3.3" ], @@ -71,6 +80,17 @@ "emea-sau-cscc-1-2019": [ "2-7-1-3" ], + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.22" + ], + "apac-nzl-ism-3-9": [ + "17.9.34.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "10.1.2", + "10.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.13.11" ] diff --git a/docs/api/controls/CRY-01.json b/docs/api/controls/CRY-01.json index 46cd6d82..e546b42b 100644 --- a/docs/api/controls/CRY-01.json +++ b/docs/api/controls/CRY-01.json @@ -84,7 +84,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -102,7 +103,7 @@ "general-cis-csc-8-1": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-cis-csc-8-1-ig1": [ @@ -111,13 +112,13 @@ "general-cis-csc-8-1-ig2": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-cis-csc-8-1-ig3": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-csa-cmm-4-1-0": [ @@ -183,7 +184,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -262,6 +263,14 @@ "A.03.13.11.ODP[01]", "A.03.13.11" ], + "general-nist-800-172-r3": [ + "03.14.09E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.09E[01]", + "DS-A.03.14.09E[02]", + "DS-A.03.14.09E[03]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -306,9 +315,6 @@ "8.3.2", "12.3.3" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-sparta": [ "CM0050" ], @@ -371,16 +377,19 @@ "SC-08(02)", "SC-13" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.E.2", @@ -426,7 +435,7 @@ "SC-13" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "emea-eu-gdpr-2016": [ "Article 32.1(a)" @@ -439,61 +448,57 @@ "9.2(a)", "9.2(b)" ], - "emea-us-psd2-2015": [ - "20", - "30" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-deu-fdpa-2017": [ + "3.2.48(2)7" ], "emea-deu-c5-2020": [ - "CRY-01" + "KRY-01", + "KRY-01-BP1", + "KRY-01-BP2", + "KRY-01-BP3", + "KRY-01-BP4", + "KRY-02" ], - "emea-isr-cmo-1-0": [ - "8.1", - "8.8", - "15.7", - "21.16" + "emea-isr-cmo-2-0": [ + "Appendix A, 3.1" ], "emea-sau-cscc-1-2019": [ - "2-7", + "2-7-1", "2-7-1-3" ], "emea-sau-ecc-1-2018": [ "2-8-1", "2-8-2", - "2-8-3", - "2-8-3-1", - "2-8-4" + "2-8-3-1" ], "emea-sau-otcc-1-2022": [ - "2-2-1-4", - "2-7", + "2-6-1", "2-7-1", "2-7-2" ], "emea-sau-sacs-002-2022": [ - "TPC-52", - "TPC-54" + "VII.B.TPC-54" ], "emea-sau-sama-csf-1-2017": [ - "3.3.9" - ], - "emea-zaf-popia-2013": [ - "14.1", - "19.1", - "19.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.2 [MP.COM.2]", - "8.4.3 [MP.COM.3]", - "8.5.2 [MP.SI.2]", - "8.7.3 [MP.INFO.3]", - "8.7.4 [MP.INFO.4]" + "3.3.9", + "3.3.9.1", + "3.3.9.4", + "3.3.9.4.a", + "3.3.9.4.b", + "3.3.9.4.c" + ], + "emea-esp-decree-311-2022": [ + "Article 12(6)(j)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" + ], + "emea-gbr-cap-1850-2020": [ + "B3" ], "emea-gbr-def-stan-05-138-2024": [ "2304", @@ -515,7 +520,7 @@ "2317", "2318" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0142", "ISM-0457", "ISM-0460", @@ -534,6 +539,7 @@ "ISM-1080", "ISM-1091", "ISM-1146", + "ISM-1233", "ISM-1446", "ISM-1629", "ISM-1759", @@ -577,7 +583,11 @@ "14.1.3.5", "14.1.3.6" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.22" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP37", "HML37" ], @@ -624,7 +634,6 @@ "17.4.16.C.01", "17.4.16.C.02", "17.5.6.C.01", - "17.6.6.C.01", "17.6.7.C.01", "17.7.6.C.01", "17.8.10.C.01", @@ -636,30 +645,20 @@ "17.8.15.C.01", "17.8.16.C.01", "17.8.17.C.01", - "17.9.24.C.01", - "17.9.24.C.02", - "17.9.24.C.03", - "17.9.25.C.01", - "17.9.26.C.01", - "17.9.26.C.02", - "17.9.27.C.01", - "17.9.27.C.02", - "17.9.27.C.03", - "17.9.28.C.01", - "17.9.29.C.01", "17.9.30.C.01", "17.9.30.C.02", + "17.9.30.C.03", "17.9.31.C.01", "17.9.32.C.01", "17.9.32.C.02", - "17.9.32.C.03" + "17.9.38.C.01", + "17.9.38.C.02" ], "apac-sgp-mas-trm-2021": [ + "6.4.5", "10.1.1", - "10.1.2", "10.1.3", - "10.1.4", - "10.1.5" + "10.1.4" ], "americas-bmu-mba-coc-2020": [ "6.22" @@ -667,6 +666,9 @@ "americas-can-osfi-b13-2022": [ "3.2.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.13.08", "03.13.11" diff --git a/docs/api/controls/CRY-02.json b/docs/api/controls/CRY-02.json index e7e911ac..dd837efd 100644 --- a/docs/api/controls/CRY-02.json +++ b/docs/api/controls/CRY-02.json @@ -68,9 +68,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Cryptographic Protections", "crosswalks": { "general-govramp": [ @@ -167,13 +167,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-07" - ], - "emea-isr-cmo-1-0": [ - "4.37", - "12.10" - ], - "emea-sau-ecc-1-2018": [ - "2-8-3-1" ] } } \ No newline at end of file diff --git a/docs/api/controls/CRY-03.json b/docs/api/controls/CRY-03.json index ced07578..00ab2bd7 100644 --- a/docs/api/controls/CRY-03.json +++ b/docs/api/controls/CRY-03.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Sensitive/regulated data is encrypted in transit according to standardized processes.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ Sensitive/regulated data is encrypted at rest using cryptographic protections that are commensurate with the sensitivity of the data.\n▪ Sensitive/regulated data is encrypted during transmission using cryptographic protections that are commensurate with the sensitivity of the data.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality of data being transmitted.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality of data being transmitted. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -90,13 +91,13 @@ "CC6.7-POF2" ], "general-cis-csc-8-1": [ - "3.1" + "3.10" ], "general-cis-csc-8-1-ig2": [ - "3.1" + "3.10" ], "general-cis-csc-8-1-ig3": [ - "3.1" + "3.10" ], "general-csa-cmm-4-1-0": [ "CEK-03", @@ -148,7 +149,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1090", @@ -230,7 +231,8 @@ "3.13.8" ], "general-nist-800-171-r3": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "general-nist-800-171a": [ "3.13.8[a]", @@ -288,9 +290,6 @@ "A2.1.1", "A2.1.2" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-swift-cscf-2025": [ "2.1", "2.5A", @@ -340,14 +339,17 @@ "SC-08", "SC-08(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.d", @@ -365,6 +367,9 @@ "usa-state-ma-201-cmr-17-2008": [ "17.04(3)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(a)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.15(a)" ], @@ -381,24 +386,11 @@ "2447(c)(5)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" - ], - "emea-us-psd2-2015": [ - "20", - "30" + "3.4.4.36(f)" ], "emea-deu-c5-2020": [ - "CRY-02" - ], - "emea-isr-cmo-1-0": [ - "4.22", - "8.4", - "8.5", - "8.6", - "9.8", - "9.20", - "12.10", - "13.6" + "KRY-02", + "KRY-02-DOAR" ], "emea-sau-cscc-1-2019": [ "2-3-1-5", @@ -414,18 +406,26 @@ "2-8-3-3" ], "emea-sau-otcc-1-2022": [ - "2-2-1-4" + "2-6-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-52", - "TPC-53" + "VII.B.TPC-52", + "VII.B.TPC-53" ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.1", + "mp.s.2" ], "emea-gbr-caf-4-0": [ "B3.b" ], + "emea-gbr-cap-1850-2020": [ + "B3" + ], "emea-gbr-def-stan-05-138-2024": [ "2302", "2306" @@ -441,10 +441,9 @@ "2302", "2306" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0231", "ISM-0232", - "ISM-0241", "ISM-0465", "ISM-0467", "ISM-0469", @@ -464,11 +463,19 @@ "ISM-1589", "ISM-1781" ], + "apac-aus-cop-sitc-2020": [ + "7" + ], "apac-ind-sebi-2024": [ "PR.DS.S1" ], + "americas-arg-ppd-2018": [ + "A.2.1", + "A.2.3-DS" + ], "americas-can-itsp-10-171-2025": [ - "03.13.08" + "03.13.08", + "03.13.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/CRY-04.json b/docs/api/controls/CRY-04.json index 99cc5c3d..6f148d72 100644 --- a/docs/api/controls/CRY-04.json +++ b/docs/api/controls/CRY-04.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ Sensitive/regulated data is encrypted at rest using cryptographic protections that are commensurate with the sensitivity of the data.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity of data being transmitted.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity of data being transmitted. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -122,7 +123,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1090", @@ -253,10 +254,10 @@ "SC-28(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "usa-federal-irs-1075-2021": [ "SC-8", @@ -274,32 +275,23 @@ "SC-08", "SC-28 (01)" ], - "emea-us-psd2-2015": [ - "20", - "30" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "4.22", - "9.8", - "9.20", - "12.10", - "13.6" + "emea-sau-cscc-1-2019": [ + "2-3-1-5", + "2-7-1-1" ], "emea-sau-cgiot-2024": [ "2-4-1", "2-4-2", "2-4-3" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0677" ], "apac-jpn-ismap": [ diff --git a/docs/api/controls/CRY-05.1.json b/docs/api/controls/CRY-05.1.json index 4f2517e7..b6c9fb9e 100644 --- a/docs/api/controls/CRY-05.1.json +++ b/docs/api/controls/CRY-05.1.json @@ -2,8 +2,8 @@ "control_id": "CRY-05.1", "title": "Storage Media", "family": "CRY", - "description": "Cryptographic mechanisms exist to protect the confidentiality and integrity of sensitive/regulated data residing on storage media.", - "scf_question": "Are cryptographic mechanisms utilized to protect the confidentiality and integrity of sensitive/regulated data residing on storage media?", + "description": "Cryptographic mechanisms exist to protect the confidentiality and integrity of sensitive and/or regulated data residing on storage media.", + "scf_question": "Are cryptographic mechanisms utilized to protect the confidentiality and integrity of sensitive and/or regulated data residing on storage media?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of sensitive/regulated data residing on storage media.", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -93,22 +94,15 @@ "general-nist-800-171-r3": [ "03.13.08" ], + "general-nist-800-171a-r3": [ + "A.03.13.08[02]" + ], "general-pci-dss-4-0-1": [ "9.4" ], "general-swift-cscf-2025": [ "2.5A" ], - "emea-deu-c5-2020": [ - "CRY-03" - ], - "emea-isr-cmo-1-0": [ - "15.7" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8", - "2-3-1-9" - ], "apac-nzl-ism-3-9": [ "8.4.13.C.01" ], diff --git a/docs/api/controls/CRY-05.2.json b/docs/api/controls/CRY-05.2.json index ecbf7785..e820e74c 100644 --- a/docs/api/controls/CRY-05.2.json +++ b/docs/api/controls/CRY-05.2.json @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-05.3.json b/docs/api/controls/CRY-05.3.json index 3e86a7f3..54f5f5e9 100644 --- a/docs/api/controls/CRY-05.3.json +++ b/docs/api/controls/CRY-05.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.).", + "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.). ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure that database servers utilize encryption to protect the confidentiality of the data within the databases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83,11 +83,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1080", "ISM-1277" ] diff --git a/docs/api/controls/CRY-05.json b/docs/api/controls/CRY-05.json index 9196a7e9..ff737e3c 100644 --- a/docs/api/controls/CRY-05.json +++ b/docs/api/controls/CRY-05.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of data at rest.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of data at rest. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -152,7 +153,7 @@ "general-iso-27018-2025": [ "8.24" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -266,7 +267,8 @@ "3.13.16" ], "general-nist-800-171-r3": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "general-nist-800-171a": [ "3.8.6" @@ -308,9 +310,6 @@ "3.5.1.3", "8.3.2" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-swift-cscf-2025": [ "2.5A" ], @@ -365,6 +364,9 @@ "SC-28", "SC-28(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-irs-1075-2021": [ "2.B.6-1", "3.3.1.e", @@ -395,14 +397,11 @@ "SC-28 (01)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "emea-deu-c5-2020": [ - "CRY-03" - ], - "emea-isr-cmo-1-0": [ - "8.7", - "15.7" + "KRY-02", + "KRY-03" ], "emea-sau-cscc-1-2019": [ "2-7-1-2" @@ -413,12 +412,20 @@ "emea-sau-ecc-1-2018": [ "2-8-3-3" ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-sau-otcc-1-2022": [ + "2-6-1-1" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "emea-gbr-caf-4-0": [ "B3.c" ], + "emea-gbr-cap-1850-2020": [ + "B3" + ], "emea-gbr-def-stan-05-138-2024": [ "2310", "2317" @@ -435,7 +442,7 @@ "2310", "2317" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0459", "ISM-1080" ], @@ -448,8 +455,12 @@ "apac-nzl-ism-3-9": [ "8.4.13.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.3" + ], "americas-can-itsp-10-171-2025": [ - "03.13.08" + "03.13.08", + "03.13.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/CRY-06.json b/docs/api/controls/CRY-06.json index 4e5b3ac2..410f15b8 100644 --- a/docs/api/controls/CRY-06.json +++ b/docs/api/controls/CRY-06.json @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-07.json b/docs/api/controls/CRY-07.json index 5f9b4258..baab8dea 100644 --- a/docs/api/controls/CRY-07.json +++ b/docs/api/controls/CRY-07.json @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -148,6 +149,9 @@ "general-nist-800-171-r3": [ "03.01.16.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -214,21 +218,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-18" ], - "emea-isr-cmo-1-0": [ - "4.22" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-4" - ], "emea-sau-sacs-002-2022": [ - "TPC-42" + "VII.B.TPC-42" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1314", "ISM-1332" ], "apac-nzl-ism-3-9": [ "18.2.9.C.01", + "18.2.9.C.02", "18.2.10.C.01", "18.2.10.C.02", "18.2.11.C.01", diff --git a/docs/api/controls/CRY-08.1.json b/docs/api/controls/CRY-08.1.json index 715eeeea..10eb6033 100644 --- a/docs/api/controls/CRY-08.1.json +++ b/docs/api/controls/CRY-08.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of data in the event of the loss of cryptographic keys.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -96,9 +97,7 @@ "3.6.1" ], "apac-nzl-ism-3-9": [ - "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03" + "17.1.51.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/CRY-08.json b/docs/api/controls/CRY-08.json index bd3cb2cc..fed90dbe 100644 --- a/docs/api/controls/CRY-08.json +++ b/docs/api/controls/CRY-08.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ The IT department implements Public Key Infrastructure (PKI) key management controls to protect the confidentiality, integrity and availability of keys.\n▪ The IT department implements and maintains an internal PKI infrastructure or obtains PKI services from a reputable PKI service provider.\n▪ The PKI infrastructure enables the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes.\n▪ The PKI infrastructure ensures the availability of information in the event of the loss of cryptographic keys by individual users.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -117,7 +118,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1072", "T1098.004", "T1521.003", @@ -172,6 +173,9 @@ "3.13.10[a]", "3.13.10[b]" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[01]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -225,21 +229,19 @@ "SC-12", "SC-17" ], - "emea-isr-cmo-1-0": [ - "8.2", - "8.9" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0485", - "ISM-1449" + "ISM-1449", + "ISM-2050" ], "apac-nzl-ism-3-9": [ "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03", "23.3.21.C.01", "23.3.22.C.01" ], + "americas-arg-ppd-2018": [ + "A.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.13.10" ] diff --git a/docs/api/controls/CRY-09.1.json b/docs/api/controls/CRY-09.1.json index 27353c37..5931d6c3 100644 --- a/docs/api/controls/CRY-09.1.json +++ b/docs/api/controls/CRY-09.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of symmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of symmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-09.2.json b/docs/api/controls/CRY-09.2.json index 79d9ba95..49fbb40d 100644 --- a/docs/api/controls/CRY-09.2.json +++ b/docs/api/controls/CRY-09.2.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of asymmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes that protect the user’s private key.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of asymmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes that protect the user’s private key. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-09.3.json b/docs/api/controls/CRY-09.3.json index 7f221da0..065ad75d 100644 --- a/docs/api/controls/CRY-09.3.json +++ b/docs/api/controls/CRY-09.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of information in the event of the loss of cryptographic keys by individual users.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of information in the event of the loss of cryptographic keys by individual users. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -154,6 +155,9 @@ "general-nist-800-171-r3": [ "03.13.10" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[02]" + ], "general-pci-dss-4-0-1": [ "2.3.2", "3.6.1", @@ -184,17 +188,21 @@ "emea-eu-nis2-annex-2024": [ "9.2(c)(v)" ], - "emea-isr-cmo-1-0": [ - "8.3", - "8.11" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0455", "ISM-0462" ], "apac-nzl-ism-3-9": [ - "7.2.24.C.01", - "7.2.25.C.01" + "7.2.24.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "10.2.7", + "10.2.9" ], "americas-can-itsp-10-171-2025": [ "03.13.10" diff --git a/docs/api/controls/CRY-09.4.json b/docs/api/controls/CRY-09.4.json index 3652661a..d71731a8 100644 --- a/docs/api/controls/CRY-09.4.json +++ b/docs/api/controls/CRY-09.4.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -125,6 +126,9 @@ "general-nist-800-171-r3": [ "03.13.10" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[02]" + ], "general-pci-dss-4-0-1": [ "3.6.1" ], @@ -141,12 +145,10 @@ "9.2(c)(iv)", "9.2(c)(v)" ], - "emea-isr-cmo-1-0": [ - "8.9", - "8.11" - ], - "apac-sgp-mas-trm-2021": [ - "10.2.5" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "americas-can-itsp-10-171-2025": [ "03.13.10" diff --git a/docs/api/controls/CRY-09.5.json b/docs/api/controls/CRY-09.5.json index 04325971..1482a57b 100644 --- a/docs/api/controls/CRY-09.5.json +++ b/docs/api/controls/CRY-09.5.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure cryptographic keys are bound to individual identities.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure cryptographic keys are bound to individual identities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": {} diff --git a/docs/api/controls/CRY-09.6.json b/docs/api/controls/CRY-09.6.json index 8a4b0d0e..24f2989c 100644 --- a/docs/api/controls/CRY-09.6.json +++ b/docs/api/controls/CRY-09.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure customers are provided with appropriate key management guidance whenever cryptographic keys are shared.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -51,7 +51,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-09.7.json b/docs/api/controls/CRY-09.7.json index e9eb6605..b94e807b 100644 --- a/docs/api/controls/CRY-09.7.json +++ b/docs/api/controls/CRY-09.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to maintain control of cryptographic keys for encrypted material stored or transmitted through an external system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-09.json b/docs/api/controls/CRY-09.json index d254331b..96e44bc9 100644 --- a/docs/api/controls/CRY-09.json +++ b/docs/api/controls/CRY-09.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -190,6 +191,9 @@ "A.03.13.10[01]", "A.03.13.10[02]" ], + "general-nist-cswp-39": [ + "3.3" + ], "general-owasp-top-10-2025": [ "A04:2025" ], @@ -269,21 +273,26 @@ "9.3" ], "emea-deu-c5-2020": [ - "CRY-04" - ], - "emea-isr-cmo-1-0": [ - "8.2", - "8.9", - "8.10" + "KRY-03", + "KRY-04", + "KRY-04-BP1", + "KRY-04-BP3", + "KRY-04-BP4", + "KRY-04-BP5", + "KRY-04-BP6", + "KRY-04-BP7", + "KRY-04-BP8" ], "emea-sau-ecc-1-2018": [ "2-8-3-2" ], "emea-sau-sacs-002-2022": [ - "TPC-55" + "VII.B.TPC-55" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.11 [OP.EXP.11]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "emea-gbr-def-stan-05-138-2024": [ "2319" @@ -297,7 +306,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2319" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0455", "ISM-0507" ], @@ -324,6 +333,11 @@ "10.1.2.19", "10.1.2.20.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.21", + "10.23" + ], "apac-nzl-ism-3-9": [ "17.1.51.C.01", "17.1.58.C.01", @@ -335,20 +349,26 @@ "23.4.9.C.03" ], "apac-sgp-mas-trm-2021": [ + "6.4.5", "10.2.1", "10.2.2", "10.2.3", "10.2.4", "10.2.5", "10.2.6", - "10.2.7", "10.2.8", - "10.2.9", "10.2.10" ], + "americas-arg-ppd-2018": [ + "A.2.3" + ], "americas-can-osfi-b13-2022": [ "3.2.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.9.2", + "3.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.13.10" ] diff --git a/docs/api/controls/CRY-10.json b/docs/api/controls/CRY-10.json index 0f3077ee..dfd3c518 100644 --- a/docs/api/controls/CRY-10.json +++ b/docs/api/controls/CRY-10.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to associate Technology Assets, Applications and/or Services (TAAS) security attributes with information exchanged between TAAS.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to associate Technology Assets, Applications and/or Services (TAAS) security attributes with information exchanged between TAAS. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -71,11 +71,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1505", "T1505.002", "T1573", diff --git a/docs/api/controls/CRY-11.json b/docs/api/controls/CRY-11.json index f49fe7e3..d6d19cbb 100644 --- a/docs/api/controls/CRY-11.json +++ b/docs/api/controls/CRY-11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to automatically enable the use of organization-defined Certificate Authorities (CAs) to facilitate the establishment of protected sessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85,7 +85,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-12.json b/docs/api/controls/CRY-12.json index cddcd9a7..f4a933b5 100644 --- a/docs/api/controls/CRY-12.json +++ b/docs/api/controls/CRY-12.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { diff --git a/docs/api/controls/CRY-13.json b/docs/api/controls/CRY-13.json index a6fa7f6e..323e2dfb 100644 --- a/docs/api/controls/CRY-13.json +++ b/docs/api/controls/CRY-13.json @@ -63,13 +63,11 @@ "MT-16", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "general-nist-800-172": [ - "3.14.1e" - ], "usa-federal-dow-cmmc-2-level-3": [ "SI.L3-3.14.1E" ] diff --git a/docs/api/controls/DCH-01.1.json b/docs/api/controls/DCH-01.1.json index 823a1011..d26a6872 100644 --- a/docs/api/controls/DCH-01.1.json +++ b/docs/api/controls/DCH-01.1.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data stewardship is assigned, documented and communicated.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data stewardship is assigned, documented and communicated. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -143,6 +144,11 @@ "03.08.01", "03.08.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.05.a[01]" + ], "general-nist-csf-2-0": [ "ID.AM-08", "PR.DS" @@ -201,28 +207,16 @@ "usa-federal-irs-1075-2021": [ "SA-4(CE-12)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(b)" + ], "emea-deu-c5-2020": [ "AM-06" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], "emea-sau-ecc-1-2018": [ + "2-7-1", "2-7-3-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-39", - "TPC-58" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" - ], - "apac-jpn-ppi-2020": [ - "21" - ], - "apac-sgp-mas-trm-2021": [ - "3.3.1(c)" - ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.05.A" diff --git a/docs/api/controls/DCH-01.2.json b/docs/api/controls/DCH-01.2.json index 76dc143b..97232eae 100644 --- a/docs/api/controls/DCH-01.2.json +++ b/docs/api/controls/DCH-01.2.json @@ -2,8 +2,8 @@ "control_id": "DCH-01.2", "title": "Sensitive / Regulated Data Protection", "family": "DCH", - "description": "Mechanisms exist to protect sensitive/regulated data wherever it is processed and/or stored.", - "scf_question": "Does the organization protect sensitive/regulated data wherever it is processed and/or stored?", + "description": "Mechanisms exist to protect sensitive and/or regulated data wherever it is processed and/or stored.", + "scf_question": "Does the organization protect sensitive and/or regulated data wherever it is processed and/or stored?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data wherever it is processed and/or stored.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,7 +61,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -129,8 +130,27 @@ "03.08.05.a", "03.17.01.c" ], - "general-nist-800-172": [ - "3.14.5e" + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.d", + "A.03.06.05.d", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.08.05.a[02]", + "A.03.17.01.c" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -182,12 +202,12 @@ "52.204-21(b)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(1)" + "§ 164.312(c)(1)" ], "usa-federal-irs-1075-2021": [ "2.C.5", @@ -241,6 +261,9 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(g)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(b)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.18" ], @@ -255,27 +278,29 @@ "usa-state-vt-act-171-2018": [ "2447(b)(3)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-deu-c5-2020": [ + "AM-07", + "RB-11" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" + ], + "emea-sau-cscc-1-2019": [ + "2-6-1-1", + "2-6-1-3" + ], + "emea-sau-ecc-1-2018": [ + "2-7-1" ], "emea-sau-otcc-1-2022": [ - "2-6-1-1" + "2-1-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-24", - "TPC-39", - "TPC-58" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 22.1", - "Article 22.3" + "VII.B.TPC-39", + "VII.B.TPC-58" ], "emea-esp-decree-311-2022": [ - "22.1", - "22.3" - ], - "emea-gbr-cap-1850-2020": [ - "B3" + "Article 22(3)" ], "emea-gbr-def-stan-05-138-2024": [ "2308" @@ -286,10 +311,13 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2308" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1802" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HHSP74", "HML14", @@ -300,8 +328,25 @@ "HSUP66" ], "apac-nzl-ism-3-9": [ + "16.2.7.C.01", + "16.2.7.C.02", "18.6.8.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.1(a)", + "11.1.1(b)", + "11.1.1(c)", + "11.1.6" + ], + "americas-bhs-dpa-2003": [ + "V.46(1)", + "V.46(2)", + "V.46(2)(a)", + "V.46(2)(b)" + ], + "americas-bmu-mba-coc-2020": [ + "6.13" + ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" diff --git a/docs/api/controls/DCH-01.3.json b/docs/api/controls/DCH-01.3.json index 2ab4ae16..35f5f68d 100644 --- a/docs/api/controls/DCH-01.3.json +++ b/docs/api/controls/DCH-01.3.json @@ -2,8 +2,8 @@ "control_id": "DCH-01.3", "title": "Sensitive / Regulated Media Records", "family": "DCH", - "description": "Mechanisms exist to ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", - "scf_question": "Does the organization ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident?", + "description": "Mechanisms exist to ensure media records for sensitive and/or regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", + "scf_question": "Does the organization ensure media records for sensitive and/or regulated data contain sufficient information to determine the potential impact in the event of a data loss incident?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -117,12 +118,12 @@ "general-nist-800-171-r3": [ "03.08.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.c" + ], "general-nist-csf-2-0": [ "PR.DS" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "apac-jpn-ismap": [ "8.2.3.3", "8.2.3.4", diff --git a/docs/api/controls/DCH-01.4.json b/docs/api/controls/DCH-01.4.json index 05955229..5c4c0a3c 100644 --- a/docs/api/controls/DCH-01.4.json +++ b/docs/api/controls/DCH-01.4.json @@ -2,8 +2,8 @@ "control_id": "DCH-01.4", "title": "Defining Access Authorizations for Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data.", - "scf_question": "Does the organization explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data?", + "description": "Mechanisms exist to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive and/or regulated data.", + "scf_question": "Does the organization explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive and/or regulated data?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -143,9 +144,27 @@ "03.17.01.c" ], "general-nist-800-171a-r3": [ + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", "A.03.15.02.c", "A.03.17.01.c" ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.b", + "A.03.01.17E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -162,14 +181,24 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "5.0" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(b)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(4)(ii)" ], "usa-federal-dow-safeguarding-nnpi-2010": [ "9-2.a" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-sau-cscc-1-2019": [ + "2-6-1-1", + "2-6-1-3" + ], + "emea-sau-ecc-1-2018": [ + "2-7-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-39" ], "emea-gbr-def-stan-05-138-2024": [ "2301" @@ -183,6 +212,13 @@ "apac-jpn-ismap": [ "8.2.3.2" ], + "apac-sgp-mas-trm-2021": [ + "11.1.6" + ], + "americas-arg-ppd-2018": [ + "B.1.3-2", + "B.2.1-2" + ], "americas-can-itsp-10-171-2025": [ "03.01.02", "03.01.03", diff --git a/docs/api/controls/DCH-01.json b/docs/api/controls/DCH-01.json index 40ee081b..33dfd036 100644 --- a/docs/api/controls/DCH-01.json +++ b/docs/api/controls/DCH-01.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ A basic data classification process exists to identify categories of sensitive/regulated data for compliance-related protection requirements.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of data protection controls.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of data protection controls. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -148,10 +149,10 @@ "PI1.5-POF4" ], "general-cis-csc-8-1": [ - "3.0", + "3", "3.1", "3.3", - "11.0", + "11", "11.3" ], "general-cis-csc-8-1-ig1": [ @@ -312,6 +313,18 @@ "3.8.1[c]", "3.8.1[d]" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.08.01[01]", + "A.03.08.01[02]" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -353,9 +366,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.4.1" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "general-shared-assessments-sig-2025": [ "P.3" ], @@ -434,6 +444,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "MP-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(b)" + ], "usa-federal-sro-finra": [ "248.30(a)(2)(i)", "248.30(a)(2)(iii)" @@ -447,16 +460,16 @@ "155.260(a)(4)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.2", @@ -480,6 +493,9 @@ "usa-federal-dow-safeguarding-nnpi-2010": [ "9-2" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.3(b)", "500.18" @@ -499,128 +515,35 @@ "emea-eu-ai-act-2024": [ "Article 17.1(f)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-c5-2020": [ - "COS-08" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "5.2", - "5.3", - "5.5", - "11.6", - "15.1", - "15.6", - "15.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "AM-07", + "RB-23" ], "emea-sau-cscc-1-2019": [ - "2-6", + "2-6-1", "2-6-1-3" ], "emea-sau-ecc-1-2018": [ - "2-1-6", - "2-3-3", - "2-3-3-2", - "2-3-4", - "2-7-1", - "2-7-2", - "2-7-3", - "2-7-4", - "2-7-3-3" + "2-7-1" ], "emea-sau-otcc-1-2022": [ - "2-6", "2-6-1", - "2-6-1-1", "2-6-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-24", - "TPC-39", - "TPC-58" - ], - "emea-srb-act-9-2018": [ - "65" - ], - "emea-zaf-popia-2013": [ - "14.1", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 22.1", - "Article 22.3" - ], "emea-esp-decree-311-2022": [ - "22.1", - "22.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" - ], - "emea-che-fadp-2025": [ - "6", - "7" + "Article 22(3)" ], - "emea-tur-lppd-2016": [ - "8", - "12" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.info.2" ], "emea-gbr-caf-4-0": [ "B3" ], - "emea-gbr-cap-1850-2020": [ - "B3" - ], "emea-gbr-def-stan-05-138-2024": [ "2300", "2308" @@ -634,45 +557,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2308" ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-privacy-principles-2026": [ - "APP 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0337", "ISM-0831", "ISM-1059", "ISM-1549", "ISM-1599" ], - "apac-aus-ps-cps-234-2019": [ - "20", - "21(a)" - ], "apac-chn-cybersecurity-law-2017": [ "Article 40" ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], "apac-ind-sebi-2024": [ "PR.AA.S14", "PR.DS.S4" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "5.1.1.10", "5.1.1.14", @@ -686,10 +584,7 @@ "13.2.1.13", "13.2.1.14" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HHSP34", "HHSP74", @@ -720,51 +615,24 @@ "13.2.6.C.01", "13.2.7.C.01" ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], "apac-sgp-mas-trm-2021": [ "11.1.1", - "11.1.1(a)", - "11.1.1(b)", - "11.1.1(c)", - "11.1.2", - "11.1.3", - "11.1.4", - "11.1.5", - "11.1.6", - "11.1.7" - ], - "apac-twn-pdpa-2025": [ - "21" + "11.1.2" ], "americas-bmu-mba-coc-2020": [ - "6.8", - "6.10", - "6.13" - ], - "americas-bra-lgpd-2018": [ - "46", - "47" + "5.3-BP3" ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.D.01", "03.01.01.D.02", "03.08.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-02.1.json b/docs/api/controls/DCH-02.1.json index 67d0c6b8..6f1175bf 100644 --- a/docs/api/controls/DCH-02.1.json +++ b/docs/api/controls/DCH-02.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to categorize data in accordance with organizational policies and standards.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that Technology Assets, Applications and/or Services (TAAS) are classified according to the highest level of data sensitivity that is stored, transmitted and/or processed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -113,13 +114,7 @@ "emea-sau-cscc-1-2019": [ "2-6-1-1" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-24" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0323", "ISM-0325" ], diff --git a/docs/api/controls/DCH-02.json b/docs/api/controls/DCH-02.json index f3f86fac..ffd84f77 100644 --- a/docs/api/controls/DCH-02.json +++ b/docs/api/controls/DCH-02.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to categorize data in accordance with organizational policies and standards.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96,7 +96,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -169,6 +170,18 @@ "03.08.01", "03.08.04" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.04[01]" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -203,9 +216,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.4.2" ], - "general-scf-dpmp-2025": [ - "1.2" - ], "general-sparta": [ "CM0001" ], @@ -249,10 +259,9 @@ "Article 17.1(f)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)", - "3.3.3(19)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "emea-eu-nis2-annex-2024": [ "2.1.3", @@ -261,20 +270,23 @@ ], "emea-deu-bsrit-2017": [ "7.13", - "7.14", - "12.4" + "7.14" ], "emea-deu-c5-2020": [ "AM-02", + "AM-05", "AM-06", - "COS-08", - "PI-01" + "PI-01", + "SIM-02" + ], + "emea-hun-act-cxii-2011": [ + "II.4.4(3)" ], - "emea-isr-cmo-1-0": [ - "5.3", - "15.2" + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" ], "emea-sau-cscc-1-2019": [ + "2-6-1-1", "2-6-1-2" ], "emea-sau-cgiot-2024": [ @@ -283,33 +295,23 @@ "emea-sau-ecc-1-2018": [ "2-1-5", "2-7-3-2", + "2-7-3-3", "4-2-3-1" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-1" - ], "emea-sau-sacs-002-2022": [ - "TPC-24" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 40.1", - "Article 40.2", - "Article 41.2" + "VII.B.TPC-24" ], "emea-esp-decree-311-2022": [ - "40.1", - "40.2", - "41.2" + "Article 40(1)" ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.2 [MP.INFO.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "mp.info.2" ], "emea-gbr-caf-4-0": [ "B3.a" ], - "emea-gbr-cap-1850-2020": [ - "B3" - ], "emea-gbr-def-stan-05-138-2024": [ "2301" ], @@ -319,7 +321,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0270", "ISM-0271", "ISM-0272", @@ -328,9 +330,11 @@ "ISM-0323", "ISM-0393" ], + "apac-aus-ps-cps-230-2023": [ + "36" + ], "apac-aus-ps-cps-234-2019": [ - "20", - "21(a)" + "20" ], "apac-ind-sebi-2024": [ "PR.DS.S2" @@ -348,7 +352,7 @@ "8.2.1.9", "8.2.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HML34" ], "apac-nzl-hisf-suppliers-2023": [ @@ -362,20 +366,34 @@ "12.3.7.C.01", "18.6.8.C.01" ], + "apac-sgp-pdpa-2012": [ + "4.1.13", + "5.21(6)(b)", + "5.22(7)" + ], "apac-sgp-mas-trm-2021": [ "3.3.1(b)" ], "americas-bmu-mba-coc-2020": [ + "5.3-BP2", + "5.9-BP2", "6.8" ], "americas-can-osfi-b13-2022": [ "2.2.2", "3.1.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4", + "3.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.04.11.A", "03.08.01", "03.08.04" + ], + "americas-col-law-1581-2012": [ + "III.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-03.1.json b/docs/api/controls/DCH-03.1.json index aaffd7d2..a9df3c17 100644 --- a/docs/api/controls/DCH-03.1.json +++ b/docs/api/controls/DCH-03.1.json @@ -2,8 +2,8 @@ "control_id": "DCH-03.1", "title": "Disclosure of Information", "family": "DCH", - "description": "Mechanisms exist to restrict the disclosure of sensitive/regulated data to authorized parties with a need to know.", - "scf_question": "Does the organization restrict the disclosure of sensitive/regulated data to authorized parties with a need to know?", + "description": "Mechanisms exist to restrict the disclosure of sensitive and/or regulated data to authorized parties with a need to know.", + "scf_question": "Does the organization restrict the disclosure of sensitive and/or regulated data to authorized parties with a need to know?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the disclosure of sensitive/regulated data to authorized parties with a need to know.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -157,6 +158,7 @@ "03.17.01.c" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", "A.03.15.02.c", "A.03.17.01.c" ], @@ -192,130 +194,130 @@ "1232h(c)(1)(B)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.510(b)(1)(i)", - "164.510(b)(1)(ii)", - "164.510(b)(2)", - "164.510(b)(4)", - "164.510(b)(5)", - "164.512", - "164.512(a)(1)", - "164.512(c)(1)", - "164.512(c)(1)(i)", - "164.512(c)(1)(ii)", - "164.512(c)(1)(iii)(A)", - "164.512(c)(1)(iii)(B)", - "164.512(c)(2)", - "164.512(c)(2)(i)", - "164.512(c)(2)(ii)", - "164.512(d)(1)", - "164.512(d)(1)(i)", - "164.512(d)(1)(ii)", - "164.512(d)(1)(iii)", - "164.512(d)(1)(iv)", - "164.512(e)(1)", - "164.512(e)(1)(i)", - "164.512(e)(1)(ii)", - "164.512(e)(1)(ii)(A)", - "164.512(e)(1)(ii)(B)", - "164.512(e)(1)(iii)", - "164.512(e)(1)(iii)(A)", - "164.512(e)(1)(iii)(B)", - "164.512(e)(1)(iii)(C)", - "164.512(e)(1)(iii)(C)(1)", - "164.512(e)(1)(iii)(C)(2)", - "164.512(e)(1)(iv)", - "164.512(e)(1)(iv)(A)", - "164.512(e)(1)(iv)(B)", - "164.512(e)(1)(v)", - "164.512(e)(1)(v)(A)", - "164.512(e)(1)(v)(B)", - "164.512(e)(1)(vi)", - "164.512(f)", - "164.512(f)(1)", - "164.512(f)(1)(i)", - "164.512(f)(1)(ii)(A)", - "164.512(f)(1)(ii)(B)", - "164.512(f)(1)(ii)(C)", - "164.512(f)(1)(ii)(C)(1)", - "164.512(f)(1)(ii)(C)(2)", - "164.512(f)(1)(ii)(C)(3)", - "164.512(f)(2)", - "164.512(f)(2)(i)(A)", - "164.512(f)(2)(i)(B)", - "164.512(f)(2)(i)(C)", - "164.512(f)(2)(i)(D)", - "164.512(f)(2)(i)(E)", - "164.512(f)(2)(i)(F)", - "164.512(f)(2)(i)(G)", - "164.512(f)(2)(i)(H)", - "164.512(f)(2)(ii)", - "164.512(f)(3)", - "164.512(f)(3)(i)", - "164.512(f)(3)(ii)", - "164.512(f)(3)(ii)(A)", - "164.512(f)(3)(ii)(B)", - "164.512(f)(3)(ii)(C)", - "164.512(f)(4)", - "164.512(f)(5)", - "164.512(f)(6)(i)", - "164.512(f)(6)(i)(A)", - "164.512(f)(6)(i)(B)", - "164.512(f)(6)(i)(C)", - "164.512(f)(6)(ii)", - "164.512(g)(1)", - "164.512(g)(2)", - "164.512(h)", - "164.512(i)(1)", - "164.512(j)(1)", - "164.514(d)(3)(i)", - "164.514(d)(3)(ii)(A)", - "164.514(d)(3)(ii)(B)", - "164.514(d)(3)(iii)", - "164.514(d)(3)(iii)(A)", - "164.514(d)(3)(iii)(B)", - "164.514(d)(3)(iii)(C)", - "164.514(d)(3)(iii)(D)", - "164.514(d)(4)", - "164.514(d)(4)(i)", - "164.514(d)(4)(ii)", - "164.514(d)(4)(iii)(A)", - "164.514(d)(4)(iii)(B)", - "164.514(d)(5)", - "164.514(e)(1)", - "164.514(e)(2)", - "164.514(e)(2)(i)", - "164.514(e)(2)(ii)", - "164.514(e)(2)(iii)", - "164.514(e)(2)(iv)", - "164.514(e)(2)(v)", - "164.514(e)(2)(vi)", - "164.514(e)(2)(vii)", - "164.514(e)(2)(viii)", - "164.514(e)(2)(ix)", - "164.514(e)(2)(x)", - "164.514(e)(2)(xi)", - "164.514(e)(2)(xii)", - "164.514(e)(2)(xiii)", - "164.514(e)(2)(xiv)", - "164.514(e)(2)(xv)", - "164.514(e)(2)(xvi)", - "164.514(e)(3)(i)", - "164.514(e)(3)(ii)", - "164.514(e)(4)(i)", - "164.514(e)(4)(ii)", - "164.514(e)(4)(ii)(A)", - "164.514(e)(4)(ii)(B)", - "164.514(e)(4)(ii)(C)", - "164.514(e)(4)(ii)(C)(1)", - "164.514(e)(4)(ii)(C)(2)", - "164.514(e)(4)(ii)(C)(3)", - "164.514(e)(4)(ii)(C)(4)", - "164.514(e)(4)(ii)(C)(5)", - "164.532(a)", - "164.532(b)", - "164.532(c)", - "164.532(c)(1)", - "164.532(d)" + "§ 164.510(b)(1)(i)", + "§ 164.510(b)(1)(ii)", + "§ 164.510(b)(2)", + "§ 164.510(b)(4)", + "§ 164.510(b)(5)", + "§ 164.512", + "§ 164.512(a)(1)", + "§ 164.512(c)(1)", + "§ 164.512(c)(1)(i)", + "§ 164.512(c)(1)(ii)", + "§ 164.512(c)(1)(iii)(A)", + "§ 164.512(c)(1)(iii)(B)", + "§ 164.512(c)(2)", + "§ 164.512(c)(2)(i)", + "§ 164.512(c)(2)(ii)", + "§ 164.512(d)(1)", + "§ 164.512(d)(1)(i)", + "§ 164.512(d)(1)(ii)", + "§ 164.512(d)(1)(iii)", + "§ 164.512(d)(1)(iv)", + "§ 164.512(e)(1)", + "§ 164.512(e)(1)(i)", + "§ 164.512(e)(1)(ii)", + "§ 164.512(e)(1)(ii)(A)", + "§ 164.512(e)(1)(ii)(B)", + "§ 164.512(e)(1)(iii)", + "§ 164.512(e)(1)(iii)(A)", + "§ 164.512(e)(1)(iii)(B)", + "§ 164.512(e)(1)(iii)(C)", + "§ 164.512(e)(1)(iii)(C)(1)", + "§ 164.512(e)(1)(iii)(C)(2)", + "§ 164.512(e)(1)(iv)", + "§ 164.512(e)(1)(iv)(A)", + "§ 164.512(e)(1)(iv)(B)", + "§ 164.512(e)(1)(v)", + "§ 164.512(e)(1)(v)(A)", + "§ 164.512(e)(1)(v)(B)", + "§ 164.512(e)(1)(vi)", + "§ 164.512(f)", + "§ 164.512(f)(1)", + "§ 164.512(f)(1)(i)", + "§ 164.512(f)(1)(ii)(A)", + "§ 164.512(f)(1)(ii)(B)", + "§ 164.512(f)(1)(ii)(C)", + "§ 164.512(f)(1)(ii)(C)(1)", + "§ 164.512(f)(1)(ii)(C)(2)", + "§ 164.512(f)(1)(ii)(C)(3)", + "§ 164.512(f)(2)", + "§ 164.512(f)(2)(i)(A)", + "§ 164.512(f)(2)(i)(B)", + "§ 164.512(f)(2)(i)(C)", + "§ 164.512(f)(2)(i)(D)", + "§ 164.512(f)(2)(i)(E)", + "§ 164.512(f)(2)(i)(F)", + "§ 164.512(f)(2)(i)(G)", + "§ 164.512(f)(2)(i)(H)", + "§ 164.512(f)(2)(ii)", + "§ 164.512(f)(3)", + "§ 164.512(f)(3)(i)", + "§ 164.512(f)(3)(ii)", + "§ 164.512(f)(3)(ii)(A)", + "§ 164.512(f)(3)(ii)(B)", + "§ 164.512(f)(3)(ii)(C)", + "§ 164.512(f)(4)", + "§ 164.512(f)(5)", + "§ 164.512(f)(6)(i)", + "§ 164.512(f)(6)(i)(A)", + "§ 164.512(f)(6)(i)(B)", + "§ 164.512(f)(6)(i)(C)", + "§ 164.512(f)(6)(ii)", + "§ 164.512(g)(1)", + "§ 164.512(g)(2)", + "§ 164.512(h)", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.514(d)(3)(ii)(A)", + "§ 164.514(d)(3)(ii)(B)", + "§ 164.514(d)(3)(iii)", + "§ 164.514(d)(3)(iii)(A)", + "§ 164.514(d)(3)(iii)(B)", + "§ 164.514(d)(3)(iii)(C)", + "§ 164.514(d)(3)(iii)(D)", + "§ 164.514(d)(4)", + "§ 164.514(d)(4)(i)", + "§ 164.514(d)(4)(ii)", + "§ 164.514(d)(4)(iii)(A)", + "§ 164.514(d)(4)(iii)(B)", + "§ 164.514(d)(5)", + "§ 164.514(e)(1)", + "§ 164.514(e)(2)", + "§ 164.514(e)(2)(i)", + "§ 164.514(e)(2)(ii)", + "§ 164.514(e)(2)(iii)", + "§ 164.514(e)(2)(iv)", + "§ 164.514(e)(2)(v)", + "§ 164.514(e)(2)(vi)", + "§ 164.514(e)(2)(vii)", + "§ 164.514(e)(2)(viii)", + "§ 164.514(e)(2)(ix)", + "§ 164.514(e)(2)(x)", + "§ 164.514(e)(2)(xi)", + "§ 164.514(e)(2)(xii)", + "§ 164.514(e)(2)(xiii)", + "§ 164.514(e)(2)(xiv)", + "§ 164.514(e)(2)(xv)", + "§ 164.514(e)(2)(xvi)", + "§ 164.514(e)(3)(i)", + "§ 164.514(e)(3)(ii)", + "§ 164.514(e)(4)(i)", + "§ 164.514(e)(4)(ii)", + "§ 164.514(e)(4)(ii)(A)", + "§ 164.514(e)(4)(ii)(B)", + "§ 164.514(e)(4)(ii)(C)", + "§ 164.514(e)(4)(ii)(C)(1)", + "§ 164.514(e)(4)(ii)(C)(2)", + "§ 164.514(e)(4)(ii)(C)(3)", + "§ 164.514(e)(4)(ii)(C)(4)", + "§ 164.514(e)(4)(ii)(C)(5)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)", + "§ 164.532(c)(1)", + "§ 164.532(d)" ], "usa-federal-nispom-2020": [ "§117.15(h)", @@ -341,15 +343,13 @@ "45.48.430.5", "45.48.430.6" ], - "emea-isr-cmo-1-0": [ - "10.5" + "usa-state-nv-privacy-law-2023": [ + "603A.495.3(b)", + "603A.500.2" ], "emea-sau-cscc-1-2019": [ "2-6-1-3" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], "emea-sau-pdpl-2023": [ "Article 15.3", "Article 15.4", @@ -365,8 +365,29 @@ "Article 16.8", "Article 16.9" ], - "emea-sau-sacs-002-2022": [ - "TPC-39" + "apac-aus-privacy-principles-2026": [ + "3.9.2", + "3.9.2.a", + "3.9.2.b", + "3.9.2.c", + "3.9.2.d", + "3.9.2.e", + "3.9.2.f", + "3.9.3", + "3.9.3.a", + "3.9.3.b", + "3.9.3.c" + ], + "apac-chn-pipl-2021": [ + "Article 25" + ], + "apac-ind-privacy-rules-2011": [ + "6(1)", + "6(2)", + "6(3)" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP3" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", diff --git a/docs/api/controls/DCH-03.2.json b/docs/api/controls/DCH-03.2.json index 1dbc0e21..71168071 100644 --- a/docs/api/controls/DCH-03.2.json +++ b/docs/api/controls/DCH-03.2.json @@ -2,8 +2,8 @@ "control_id": "DCH-03.2", "title": "Masking Displayed Data", "family": "DCH", - "description": "Mechanisms exist to apply data masking to sensitive/regulated information that is displayed or printed.", - "scf_question": "Does the organization apply data masking to sensitive/regulated information that is displayed or printed?", + "description": "Mechanisms exist to apply data masking to sensitive and/or regulated information that is displayed or printed.", + "scf_question": "Does the organization apply data masking to sensitive and/or regulated information that is displayed or printed?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply data masking to sensitive/regulated information that is displayed or printed.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply data masking to sensitive/regulated information that is displayed or printed. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102,6 +103,9 @@ "usa-state-il-ipa-2009": [ "35(a)(4)", "37(a)(4)" + ], + "americas-arg-ppd-2018": [ + "H.1.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-03.3.json b/docs/api/controls/DCH-03.3.json index 021575b2..effc1a01 100644 --- a/docs/api/controls/DCH-03.3.json +++ b/docs/api/controls/DCH-03.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically validate cybersecurity and data protection attributes prior to releasing information to external Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46,7 +46,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-03.json b/docs/api/controls/DCH-03.json index 7b390272..58ce22d0 100644 --- a/docs/api/controls/DCH-03.json +++ b/docs/api/controls/DCH-03.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to control and restrict access to digital and non-digital media to authorized individuals.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to control and restrict access to digital and non-digital media to authorized individuals. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -193,6 +194,10 @@ "3.8.2" ], "general-nist-800-171a-r3": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", "A.03.08.02" ], "general-nist-csf-2-0": [ @@ -221,10 +226,10 @@ "MP-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MP-2" @@ -241,8 +246,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-02" ], - "emea-sau-sacs-002-2022": [ - "TPC-39" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2301" diff --git a/docs/api/controls/DCH-04.1.json b/docs/api/controls/DCH-04.1.json index dc73c096..8cc62c4e 100644 --- a/docs/api/controls/DCH-04.1.json +++ b/docs/api/controls/DCH-04.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically mark physical media and digital files to indicate the distribution limitations, handling requirements and applicable security markings (if any) of the information to aid Data Loss Prevention (DLP) technologies.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically mark physical media and digital files to indicate the distribution limitations, handling requirements and applicable security markings (if any) of the information to aid Data Loss Prevention (DLP) technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78,7 +78,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -145,8 +146,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-03" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0271" + ], + "apac-nzl-ism-3-9": [ + "15.2.39.C.02", + "15.2.39.C.03" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-04.json b/docs/api/controls/DCH-04.json index dd6b469a..42f53517 100644 --- a/docs/api/controls/DCH-04.json +++ b/docs/api/controls/DCH-04.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to mark media in accordance with data protection requirements so that personnel are alerted to distribution limitations, handling caveats and applicable security requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to mark media in accordance with data protection requirements so that personnel are alerted to distribution limitations, handling caveats and applicable security requirements. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -242,13 +243,13 @@ "emea-deu-c5-2020": [ "AM-06" ], - "emea-isr-cmo-1-0": [ - "15.2" + "emea-sau-ecc-1-2018": [ + "2-1-5" ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.1 [MP.SI.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0201", "ISM-0270", "ISM-0272", @@ -283,8 +284,7 @@ "13.2.12.C.04", "13.2.13.C.01", "13.2.14.C.01", - "13.2.14.C.02", - "21.1.21.C.01" + "13.2.14.C.02" ], "americas-can-itsp-10-171-2025": [ "03.08.04" diff --git a/docs/api/controls/DCH-05.1.json b/docs/api/controls/DCH-05.1.json index d9804912..7a42dcd4 100644 --- a/docs/api/controls/DCH-05.1.json +++ b/docs/api/controls/DCH-05.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to dynamically associate cybersecurity and data protection attributes with individuals and objects as information is created, combined, or transformed, in accordance with organization-defined cybersecurity and data protection policies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.10.json b/docs/api/controls/DCH-05.10.json index 071ceb2f..3e9d7476 100644 --- a/docs/api/controls/DCH-05.10.json +++ b/docs/api/controls/DCH-05.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide authorized individuals the capability to define or change the type and value of cybersecurity and data protection attributes available for association with subjects and objects.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.11.json b/docs/api/controls/DCH-05.11.json index 4529fa98..e4a35608 100644 --- a/docs/api/controls/DCH-05.11.json +++ b/docs/api/controls/DCH-05.11.json @@ -20,7 +20,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to audit changes to cybersecurity and data protection attributes and responds to events in accordance with incident response procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} diff --git a/docs/api/controls/DCH-05.2.json b/docs/api/controls/DCH-05.2.json index 7ba2eda4..52564d48 100644 --- a/docs/api/controls/DCH-05.2.json +++ b/docs/api/controls/DCH-05.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide authorized individuals (or processes acting on behalf of individuals) the capability to define or change the value of associated cybersecurity and data protection attributes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.3.json b/docs/api/controls/DCH-05.3.json index 0fce49e7..33570d3c 100644 --- a/docs/api/controls/DCH-05.3.json +++ b/docs/api/controls/DCH-05.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain the association and integrity of cybersecurity and data protection attributes to individuals and objects.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.4.json b/docs/api/controls/DCH-05.4.json index 5a84c005..dc5e5047 100644 --- a/docs/api/controls/DCH-05.4.json +++ b/docs/api/controls/DCH-05.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide the capability to associate cybersecurity and data protection attributes with individuals and objects by authorized individuals (or processes acting on behalf of individuals).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.5.json b/docs/api/controls/DCH-05.5.json index ab86cae5..38068df7 100644 --- a/docs/api/controls/DCH-05.5.json +++ b/docs/api/controls/DCH-05.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to display cybersecurity and data protection attributes in human-readable form on each object that the system transmits to output devices to identify special dissemination, handling or distribution instructions using human-readable, standard naming conventions.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.6.json b/docs/api/controls/DCH-05.6.json index 87c6a066..08966131 100644 --- a/docs/api/controls/DCH-05.6.json +++ b/docs/api/controls/DCH-05.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to require personnel to associate and maintain the association of cybersecurity and data protection attributes with individuals and objects in accordance with cybersecurity and data protection policies.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.7.json b/docs/api/controls/DCH-05.7.json index 847cb686..2545a0c0 100644 --- a/docs/api/controls/DCH-05.7.json +++ b/docs/api/controls/DCH-05.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide a consistent, organizationally agreed upon interpretation of cybersecurity and data protection attributes employed in access enforcement and flow enforcement decisions between distributed system components.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.8.json b/docs/api/controls/DCH-05.8.json index 4f6475b0..0360a145 100644 --- a/docs/api/controls/DCH-05.8.json +++ b/docs/api/controls/DCH-05.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to associate cybersecurity and data protection attributes to information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-05.9.json b/docs/api/controls/DCH-05.9.json index d55cfba9..75790592 100644 --- a/docs/api/controls/DCH-05.9.json +++ b/docs/api/controls/DCH-05.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to reclassify data as required, due to changing business/technical requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -73,7 +74,7 @@ "general-nist-800-82-r3": [ "AC-16(09)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0325" ] } diff --git a/docs/api/controls/DCH-05.json b/docs/api/controls/DCH-05.json index 93b62a63..8eca4e2e 100644 --- a/docs/api/controls/DCH-05.json +++ b/docs/api/controls/DCH-05.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to bind cybersecurity and data protection attributes to information as it is stored, transmitted and processed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,14 +63,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { "general-csa-iot-2": [ "DAT-01" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1005", diff --git a/docs/api/controls/DCH-06.1.json b/docs/api/controls/DCH-06.1.json index b234ca2b..073f226c 100644 --- a/docs/api/controls/DCH-06.1.json +++ b/docs/api/controls/DCH-06.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to physically secure all media that contains sensitive information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102,6 +103,10 @@ "general-nist-800-171-r3": [ "03.08.01" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], "general-pci-dss-4-0-1": [ "9.1", "9.4", @@ -145,6 +150,9 @@ "apac-jpn-ismap": [ "8.3.1.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], "americas-can-itsp-10-171-2025": [ "03.08.01" ] diff --git a/docs/api/controls/DCH-06.2.json b/docs/api/controls/DCH-06.2.json index 82b47c82..daf3dd76 100644 --- a/docs/api/controls/DCH-06.2.json +++ b/docs/api/controls/DCH-06.2.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain inventory logs of all sensitive media and conduct sensitive media inventories at least annually.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain inventory logs of all sensitive media and conduct sensitive media inventories at least annually. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -97,7 +97,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -133,8 +134,10 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.1.2e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -169,15 +172,12 @@ "emea-gbr-caf-4-0": [ "B3.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0336" ], "apac-ind-sebi-2024": [ "ID.AM.S5" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS03" - ], "americas-can-osfi-b13-2022": [ "2.2.2", "3.1.4" diff --git a/docs/api/controls/DCH-06.3.json b/docs/api/controls/DCH-06.3.json index 252399e2..dcc8bb82 100644 --- a/docs/api/controls/DCH-06.3.json +++ b/docs/api/controls/DCH-06.3.json @@ -2,8 +2,8 @@ "control_id": "DCH-06.3", "title": "Periodic Scans for Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", - "scf_question": "Does the organization periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations?", + "description": "Mechanisms exist to periodically scan unstructured data sources for sensitive and/or regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", + "scf_question": "Does the organization periodically scan unstructured data sources for sensitive and/or regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations?", "relative_weight": 7, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -102,6 +103,9 @@ "general-pci-dss-4-0-1": [ "A3.2.5", "A3.2.5.1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-06.4.json b/docs/api/controls/DCH-06.4.json index 5340e739..30429209 100644 --- a/docs/api/controls/DCH-06.4.json +++ b/docs/api/controls/DCH-06.4.json @@ -2,8 +2,8 @@ "control_id": "DCH-06.4", "title": "Making Sensitive Data Unreadable In Storage", "family": "DCH", - "description": "Mechanisms exist to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored.", - "scf_question": "Does the organization ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored?", + "description": "Mechanisms exist to ensure sensitive and/or regulated data is rendered human unreadable anywhere sensitive and/or regulated data is stored.", + "scf_question": "Does the organization ensure sensitive and/or regulated data is rendered human unreadable anywhere sensitive and/or regulated data is stored?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -86,6 +87,10 @@ "general-nist-800-171-r3": [ "03.08.01" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], "general-pci-dss-4-0-1": [ "9.4" ], diff --git a/docs/api/controls/DCH-06.5.json b/docs/api/controls/DCH-06.5.json index 2f6c97e1..c07936c3 100644 --- a/docs/api/controls/DCH-06.5.json +++ b/docs/api/controls/DCH-06.5.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the storage of sensitive transaction authentication data after authorization.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the storage of sensitive transaction authentication data after authorization. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-06.json b/docs/api/controls/DCH-06.json index a63cd5eb..cce72574 100644 --- a/docs/api/controls/DCH-06.json +++ b/docs/api/controls/DCH-06.json @@ -3,7 +3,7 @@ "title": "Media Storage", "family": "DCH", "description": "Mechanisms exist to: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures.", - "scf_question": "Does the organization: \n (1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n (2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures?", + "scf_question": "Does the organization: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -23,7 +23,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -97,7 +97,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -232,11 +233,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-04" ], - "emea-isr-cmo-1-0": [ - "15.3" - ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2308" @@ -253,6 +253,9 @@ "apac-jpn-ismap": [ "8.3.1.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], "apac-nzl-ism-3-9": [ "8.4.10.C.01", "8.4.11.C.01", diff --git a/docs/api/controls/DCH-07.1.json b/docs/api/controls/DCH-07.1.json index 98f1224d..6294f9e0 100644 --- a/docs/api/controls/DCH-07.1.json +++ b/docs/api/controls/DCH-07.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ Data classification and handling criteria govern user behavior for media handling.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify custodians throughout the transport of digital or non-digital media.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify custodians throughout the transport of digital or non-digital media. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -143,6 +144,10 @@ "03.08.05.a", "03.08.05.b" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.a[02]", + "A.03.08.05.b" + ], "general-pci-dss-4-0-1": [ "9.4.3" ], @@ -174,10 +179,10 @@ "8.2.7" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.4", @@ -190,18 +195,15 @@ "§117.15(f)(4)(iii)", "§117.15(f)(4)(iv)" ], - "emea-isr-cmo-1-0": [ - "15.7" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "apac-jpn-ismap": [ "8.3.1.10" ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-3" + ], "americas-can-itsp-10-171-2025": [ "03.08.05.A", "03.08.05.B" diff --git a/docs/api/controls/DCH-07.2.json b/docs/api/controls/DCH-07.2.json index af36909d..da255f57 100644 --- a/docs/api/controls/DCH-07.2.json +++ b/docs/api/controls/DCH-07.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -125,6 +126,9 @@ "general-nist-800-171-r3": [ "03.08.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.a[02]" + ], "usa-federal-fbi-cjis-6-0": [ "SC-28(1)" ], @@ -152,6 +156,11 @@ "emea-eu-nis2-annex-2024": [ "12.3.2(c)" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], "emea-gbr-def-stan-05-138-2024": [ "2302" ], diff --git a/docs/api/controls/DCH-07.json b/docs/api/controls/DCH-07.json index ac15f030..65f21352 100644 --- a/docs/api/controls/DCH-07.json +++ b/docs/api/controls/DCH-07.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ Data classification and handling criteria govern user behavior for media handling.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect and control digital and non-digital media during transport outside of controlled areas using appropriate security measures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -176,7 +177,8 @@ ], "general-nist-800-171-r3": [ "03.08.05.a", - "03.08.05.b" + "03.08.05.b", + "03.08.05.c" ], "general-nist-800-171a": [ "3.8.5[a]", @@ -229,10 +231,10 @@ "MP-05" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.4", @@ -269,14 +271,14 @@ "emea-eu-nis2-annex-2024": [ "12.3.2(c)" ], - "emea-isr-cmo-1-0": [ - "15.7" + "emea-deu-c5-2020": [ + "AM-08" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.4 [MP.SI.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2302", @@ -299,9 +301,13 @@ "8.3.3.5", "13.2.2.5" ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-3" + ], "americas-can-itsp-10-171-2025": [ "03.08.05.A", - "03.08.05.B" + "03.08.05.B", + "03.08.05.C" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-08.json b/docs/api/controls/DCH-08.json index 73e16efa..c7e2588b 100644 --- a/docs/api/controls/DCH-08.json +++ b/docs/api/controls/DCH-08.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of media when it is no longer required, using formal procedures.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of media when it is no longer required, using formal procedures. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96,7 +96,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -200,6 +201,9 @@ "general-nist-800-171-r3": [ "03.08.03" ], + "general-nist-800-171a-r3": [ + "A.03.08.03" + ], "general-pci-dss-4-0-1": [ "9.4", "9.4.6" @@ -280,6 +284,9 @@ "usa-state-il-pipa-2006": [ "40(b)(2)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(C)(1)" ], @@ -292,28 +299,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-deu-c5-2020": [ - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.5 [MP.SI.5]" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 5" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0312", "ISM-0315", @@ -361,8 +352,8 @@ "13.5.29.C.02", "13.5.30.C.01" ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" + "americas-arg-ppd-2018": [ + "F.1.2-DS-1" ], "americas-can-itsp-10-171-2025": [ "03.08.03" diff --git a/docs/api/controls/DCH-09.1.json b/docs/api/controls/DCH-09.1.json index 3b42e482..eec77df1 100644 --- a/docs/api/controls/DCH-09.1.json +++ b/docs/api/controls/DCH-09.1.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to supervise, track, document and verify system media sanitization and disposal actions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to supervise, track, document and verify system media sanitization and disposal actions. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -159,9 +160,6 @@ "MP-06(1)", "MP-06(1)-SID" ], - "emea-isr-cmo-1-0": [ - "15.8" - ], "emea-gbr-def-stan-05-138-2024": [ "2323" ], @@ -174,7 +172,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0316", "ISM-0363", "ISM-0370", @@ -192,6 +190,13 @@ "13.5.27.C.03", "13.5.28.C.01", "13.5.28.C.02" + ], + "americas-arg-ppd-2018": [ + "F.1.1", + "F.1.4" + ], + "americas-bmu-mba-coc-2020": [ + "6.17" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-09.2.json b/docs/api/controls/DCH-09.2.json index 1bace883..d9241814 100644 --- a/docs/api/controls/DCH-09.2.json +++ b/docs/api/controls/DCH-09.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to test sanitization equipment and procedures to verify that the intended result is achieved.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to test sanitization equipment and procedures to verify that the intended result is achieved. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -123,9 +124,6 @@ "usa-federal-cms-marse-2-0": [ "MP-6(2)" ], - "emea-isr-cmo-1-0": [ - "15.8" - ], "apac-nzl-ism-3-9": [ "13.4.23.C.01" ] diff --git a/docs/api/controls/DCH-09.3.json b/docs/api/controls/DCH-09.3.json index 09d603fb..581b15fb 100644 --- a/docs/api/controls/DCH-09.3.json +++ b/docs/api/controls/DCH-09.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the sanitization of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -167,9 +168,6 @@ "general-nist-800-161-r1-level-3": [ "MP-6" ], - "general-scf-dpmp-2025": [ - "5.5" - ], "general-tisax-6-0-3": [ "8.2.6" ], @@ -218,25 +216,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-zaf-popia-2013": [ - "16.1" - ], "apac-ind-dpdpa-2023": [ "8(7)(a)" - ], - "americas-arg-ppd-2018": [ - "4.7", - "16.7", - "25.2" - ], - "americas-bra-lgpd-2018": [ - "16" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-09.4.json b/docs/api/controls/DCH-09.4.json index b9f58b1e..417ef7ca 100644 --- a/docs/api/controls/DCH-09.4.json +++ b/docs/api/controls/DCH-09.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply nondestructive sanitization techniques to portable storage devices prior to first use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -115,7 +116,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "MP-06(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1600", "ISM-1642" ] diff --git a/docs/api/controls/DCH-09.5.json b/docs/api/controls/DCH-09.5.json index 6c9454f5..793d0ee2 100644 --- a/docs/api/controls/DCH-09.5.json +++ b/docs/api/controls/DCH-09.5.json @@ -2,8 +2,8 @@ "control_id": "DCH-09.5", "title": "Dual Authorization for Sensitive Data Destruction", "family": "DCH", - "description": "Mechanisms exist to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data.", - "scf_question": "Does the organization enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data?", + "description": "Mechanisms exist to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive and/or regulated data.", + "scf_question": "Does the organization enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive and/or regulated data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -97,7 +97,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -109,6 +110,14 @@ ], "general-nist-800-82-r3": [ "MP-06(07)" + ], + "general-nist-800-172-r3": [ + "03.08.01E", + "03.08.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.01E", + "A.03.08.02E.ODP[01]" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-09.json b/docs/api/controls/DCH-09.json index 881fd13d..376b9985 100644 --- a/docs/api/controls/DCH-09.json +++ b/docs/api/controls/DCH-09.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to sanitize system media with the strength and integrity commensurate with the classification or sensitivity of the information prior to disposal, release out of organizational control or release for reuse.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96,7 +96,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -223,8 +224,15 @@ "3.8.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.07.04.c", "A.03.08.03" ], + "general-nist-800-172-r3": [ + "03.08.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.08.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "9.4.7" ], @@ -274,10 +282,10 @@ "155.260(a)(4)(vi)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.F.3.1-1", @@ -308,18 +316,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" + "emea-deu-c5-2020": [ + "PI-05" ], "emea-sau-sacs-002-2022": [ - "TPC-19", - "TPC-66" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.6 [MP.INFO.6]" + "VII.A.TPC-19", + "VII.B.TPC-66" ], "emea-gbr-caf-4-0": [ "B3.e" @@ -339,7 +341,7 @@ "2313", "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0313", "ISM-0317", @@ -368,6 +370,7 @@ "11.2.7.3" ], "apac-nzl-ism-3-9": [ + "12.6.5.C.05", "13.4.9.C.01", "13.4.11.C.01", "13.4.12.C.01", @@ -378,12 +381,11 @@ "13.4.13.C.05", "13.4.14.C.01", "13.4.15.C.01", - "12.6.5.C.05", - "13.4.19.C.02", "13.4.16.C.01", "13.4.17.C.01", "13.4.18.C.01", "13.4.19.C.01", + "13.4.19.C.02", "13.4.20.C.01", "13.4.20.C.02", "13.4.20.C.03", @@ -393,6 +395,10 @@ "apac-sgp-mas-trm-2021": [ "11.1.7" ], + "americas-arg-ppd-2018": [ + "D.1.2-4", + "F.1.2" + ], "americas-bmu-mba-coc-2020": [ "6.17" ], diff --git a/docs/api/controls/DCH-10.1.json b/docs/api/controls/DCH-10.1.json index 93339e1c..74ad65aa 100644 --- a/docs/api/controls/DCH-10.1.json +++ b/docs/api/controls/DCH-10.1.json @@ -2,8 +2,8 @@ "control_id": "DCH-10.1", "title": "Limitations on Use", "family": "DCH", - "description": "Mechanisms exist to restrict the use and distribution of sensitive/regulated data.", - "scf_question": "Does the organization restrict the use and distribution of sensitive/regulated data?", + "description": "Mechanisms exist to restrict the use and distribution of sensitive and/or regulated data.", + "scf_question": "Does the organization restrict the use and distribution of sensitive and/or regulated data?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,9 +18,9 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ Limited media handling guidance exists for users.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use and distribution of sensitive/regulated data.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use and distribution of sensitive/regulated data. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -86,7 +87,12 @@ "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(2)" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "apac-aus-ism-2026-march": [ "ISM-0343" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/DCH-10.2.json b/docs/api/controls/DCH-10.2.json index 15391a0b..2af11054 100644 --- a/docs/api/controls/DCH-10.2.json +++ b/docs/api/controls/DCH-10.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the use of portable storage devices in organizational systems when such devices have no identifiable owner.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-10.json b/docs/api/controls/DCH-10.json index c3806d19..52424dd4 100644 --- a/docs/api/controls/DCH-10.json +++ b/docs/api/controls/DCH-10.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of types of digital media on systems or system components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of types of digital media on systems or system components. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -99,7 +100,7 @@ "general-iso-27018-2025": [ "7.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1025", "T1052", "T1052.001", @@ -190,7 +191,12 @@ "MP-07" ], "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "5-1-3-5" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2310" @@ -204,7 +210,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2310" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0341", "ISM-0343" ], diff --git a/docs/api/controls/DCH-11.json b/docs/api/controls/DCH-11.json index 83ef0a03..81b54350 100644 --- a/docs/api/controls/DCH-11.json +++ b/docs/api/controls/DCH-11.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to reclassify data, including associated Technology Assets, Applications and/or Services (TAAS), commensurate with the security category and/or classification level of the information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -99,7 +100,10 @@ "MP-08", "MP-08(03)" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "SIM-02" + ], + "apac-aus-ism-2026-march": [ "ISM-0325", "ISM-0330" ], diff --git a/docs/api/controls/DCH-12.json b/docs/api/controls/DCH-12.json index f9c00d3c..441aa31b 100644 --- a/docs/api/controls/DCH-12.json +++ b/docs/api/controls/DCH-12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict removable media in accordance with data handling and acceptable usage parameters.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -118,6 +119,9 @@ "general-nist-800-171-r3": [ "03.08.07.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.07.a" + ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.V" ], @@ -129,11 +133,13 @@ "12.3.2(a)", "12.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "12.24" + "emea-sau-otcc-1-2022": [ + "2-3-1-9" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2310" @@ -147,17 +153,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2310" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1359", "ISM-1713" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HML14" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP12" ], diff --git a/docs/api/controls/DCH-13.1.json b/docs/api/controls/DCH-13.1.json index baeae703..f4eb6b19 100644 --- a/docs/api/controls/DCH-13.1.json +++ b/docs/api/controls/DCH-13.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit external parties, including Technology Assets, Applications and/or Services (TAAS), from storing, processing and transmitting data unless authorized individuals first: \n(1) Verifying the implementation of required security, compliance and/or resilience controls; or\n(2) Retaining a processing agreement with the entity hosting the external TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,9 +84,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Classification & Handling", "crosswalks": { "general-cis-csc-8-1": [ @@ -150,6 +150,13 @@ "03.01.20.c.02", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.01.20.d" + ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -194,9 +201,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-20 (01)" ], - "emea-srb-act-9-2018": [ - "5.1" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.B", diff --git a/docs/api/controls/DCH-13.2.json b/docs/api/controls/DCH-13.2.json index 09113718..ecb3e3b0 100644 --- a/docs/api/controls/DCH-13.2.json +++ b/docs/api/controls/DCH-13.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict or prohibit the use of portable storage devices by users on external systems.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict or prohibit the use of portable storage devices by users on external systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -161,6 +162,7 @@ "3.1.21[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", "A.03.01.20.d" ], "usa-federal-fbi-cjis-6-0": [ @@ -176,10 +178,10 @@ "AC-20(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "AC-20(CE-2)", @@ -190,13 +192,15 @@ "AC-20(2)-IS.a" ], "emea-sau-ecc-1-2018": [ + "2-3-3-2", "5-1-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8", - "2-3-1-9" + "emea-esp-decree-311-2022": [ + "Article 22(1)" ], "apac-nzl-ism-3-9": [ + "11.8.11.C.01", + "11.8.11.C-02", "13.3.7.C.01", "13.3.7.C.02", "13.3.8.C.01", @@ -205,6 +209,9 @@ "13.3.9.C.02", "13.3.10.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.D" diff --git a/docs/api/controls/DCH-13.3.json b/docs/api/controls/DCH-13.3.json index e4fb67d7..db651e66 100644 --- a/docs/api/controls/DCH-13.3.json +++ b/docs/api/controls/DCH-13.3.json @@ -2,8 +2,8 @@ "control_id": "DCH-13.3", "title": "Protecting Sensitive / Regulated Data on External Technology Assets, Applications and/or Services (TAAS)", "family": "DCH", - "description": "Mechanisms exist to ensure that the requirements for the protection of sensitive/regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization ensure that the requirements for the protection of sensitive/regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to ensure that the requirements for the protection of sensitive and/or regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization ensure that the requirements for the protection of sensitive and/or regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations?", "relative_weight": 10, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -136,13 +137,14 @@ "03.01.20.b", "03.01.20.c.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.01" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", "03.01.20.C.01" diff --git a/docs/api/controls/DCH-13.4.json b/docs/api/controls/DCH-13.4.json index 6f9d1b19..30d15f7f 100644 --- a/docs/api/controls/DCH-13.4.json +++ b/docs/api/controls/DCH-13.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of non-organizationally owned Technology Assets, Applications and/or Services (TAAS) to process, store or transmit organizational information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -127,6 +128,18 @@ "03.01.20.c.01", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.c.01", + "A.03.01.20.d" + ], + "general-nist-800-172-r3": [ + "03.01.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.02E", + "A.03.01.02E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], diff --git a/docs/api/controls/DCH-13.json b/docs/api/controls/DCH-13.json index b630733d..6842ccbb 100644 --- a/docs/api/controls/DCH-13.json +++ b/docs/api/controls/DCH-13.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern how external parties, including Technology Assets, Applications and/or Services (TAAS), are used to securely store, process and transmit data.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern how external parties, including Technology Assets, Applications and/or Services (TAAS), are used to securely store, process and transmit data. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -126,7 +127,7 @@ "general-govramp-high": [ "AC-20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1021", "T1021.001", @@ -254,7 +255,8 @@ "A.03.01.20.a", "A.03.01.20.b", "A.03.01.20.c.01", - "A.03.01.20.c.02" + "A.03.01.20.c.02", + "A.03.01.20.d" ], "usa-federal-fbi-cjis-6-0": [ "AC-20" @@ -310,11 +312,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-20" ], - "emea-isr-cmo-1-0": [ - "11.6" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-36" ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" + "emea-esp-decree-311-2022": [ + "Article 22(1)" ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", diff --git a/docs/api/controls/DCH-14.1.json b/docs/api/controls/DCH-14.1.json index 828f7fec..ab9be5f9 100644 --- a/docs/api/controls/DCH-14.1.json +++ b/docs/api/controls/DCH-14.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications and/or Services (TAAS) implement data search and retrieval functions that properly enforce data protection / sharing restrictions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-14.2.json b/docs/api/controls/DCH-14.2.json index f4e5ec28..cab75af5 100644 --- a/docs/api/controls/DCH-14.2.json +++ b/docs/api/controls/DCH-14.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to verify that individuals or Technology Assets, Applications and/or Services (TAAS) transferring data between interconnecting TAAS have the requisite authorizations (e.g., write permissions or privileges) prior to transferring said data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -120,6 +121,11 @@ "03.01.20.c.02", "03.12.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -134,23 +140,12 @@ "usa-federal-irs-1075-2021": [ "2.E.6.2" ], - "emea-ken-pda-2019": [ - "25(h)" + "emea-deu-c5-2020": [ + "AM-08" ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], - "emea-srb-act-9-2018": [ - "64", - "64.1", - "64.2", - "64.3", - "64.4" - ], - "apac-nzl-ism-3-9": [ - "20.1.8.C.01", - "20.2.4.C.01" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", "03.01.20.C.02", diff --git a/docs/api/controls/DCH-14.3.json b/docs/api/controls/DCH-14.3.json index 9c20a42c..409b1a1d 100644 --- a/docs/api/controls/DCH-14.3.json +++ b/docs/api/controls/DCH-14.3.json @@ -2,8 +2,8 @@ "control_id": "DCH-14.3", "title": "Data Access Mapping", "family": "DCH", - "description": "Mechanisms exist to leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive/regulated data is shared.", - "scf_question": "Does the organization leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive/regulated data is shared?", + "description": "Mechanisms exist to leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive and/or regulated data is shared.", + "scf_question": "Does the organization leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive and/or regulated data is shared?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -109,6 +110,11 @@ "03.01.20.c.02", "03.12.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DA.DAUTE" ], diff --git a/docs/api/controls/DCH-14.json b/docs/api/controls/DCH-14.json index 033f101d..e0209f96 100644 --- a/docs/api/controls/DCH-14.json +++ b/docs/api/controls/DCH-14.json @@ -19,11 +19,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a process to assist users in making information sharing decisions to ensure data is appropriately protected.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -132,7 +133,7 @@ "general-iso-27018-2025": [ "5.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1213", "T1213.001", "T1213.002", @@ -166,6 +167,9 @@ "general-nist-800-171-r3": [ "03.01.20.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b" + ], "general-swift-cscf-2025": [ "2.1", "2.4", @@ -199,14 +203,13 @@ "usa-state-ca-ccpa-cpra-2026": [ "7153(a)" ], - "emea-isr-cmo-1-0": [ - "5.4", - "10.5" + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" ], - "emea-zaf-popia-2013": [ - "72" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0657", "ISM-0661", "ISM-0663", @@ -221,36 +224,6 @@ "13.2.1.5", "13.2.1.9" ], - "apac-nzl-ism-3-9": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B" ] diff --git a/docs/api/controls/DCH-15.json b/docs/api/controls/DCH-15.json index 5d24c39c..9b166c9c 100644 --- a/docs/api/controls/DCH-15.json +++ b/docs/api/controls/DCH-15.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -149,8 +150,7 @@ ], "general-nist-800-171a-r3": [ "A.03.01.22.a", - "A.03.01.22.b[01]", - "A.03.01.22.b[02]" + "A.03.01.22.b[01]" ], "general-pci-dss-4-0-1": [ "1.4.4" diff --git a/docs/api/controls/DCH-16.json b/docs/api/controls/DCH-16.json index e7542eaf..370460b0 100644 --- a/docs/api/controls/DCH-16.json +++ b/docs/api/controls/DCH-16.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect data storage objects against unauthorized data mining and data harvesting techniques.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect data storage objects against unauthorized data mining and data harvesting techniques. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75,11 +75,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -155,18 +156,6 @@ ], "usa-federal-irs-1075-2021": [ "AC-23" - ], - "apac-nzl-ism-3-9": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-17.json b/docs/api/controls/DCH-17.json index cabf895f..7c4353ff 100644 --- a/docs/api/controls/DCH-17.json +++ b/docs/api/controls/DCH-17.json @@ -20,7 +20,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to secure ad-hoc exchanges of large digital files with internal or external parties.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -120,6 +121,9 @@ "general-nist-800-171-r3": [ "03.01.20.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a" + ], "usa-federal-dow-cmmc-2-level-1": [ "AC.L1-B.1.III" ], @@ -132,32 +136,21 @@ "usa-federal-irs-1075-2021": [ "2.E.2" ], - "emea-isr-cmo-1-0": [ - "5.1", - "5.4", - "10.5" - ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], - "apac-aus-ism-2024-june": [ + "emea-sau-otcc-1-2022": [ + "2-6-1-4" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" + ], + "apac-aus-ism-2026-march": [ "ISM-0347", "ISM-0947", "ISM-1778", "ISM-1779" ], - "apac-nzl-ism-3-9": [ - "20.1.11.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A" ] diff --git a/docs/api/controls/DCH-18.1.json b/docs/api/controls/DCH-18.1.json index 8fef1b0a..9798bb3b 100644 --- a/docs/api/controls/DCH-18.1.json +++ b/docs/api/controls/DCH-18.1.json @@ -2,8 +2,8 @@ "control_id": "DCH-18.1", "title": "Minimize Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", - "scf_question": "Does the organization minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes?", + "description": "Mechanisms exist to minimize sensitive and/or regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", + "scf_question": "Does the organization minimize sensitive and/or regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -20,7 +20,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -105,10 +106,6 @@ "general-nist-800-82-r3": [ "SI-12(01)" ], - "general-scf-dpmp-2025": [ - "3.3", - "5.4" - ], "general-shared-assessments-sig-2025": [ "P.6" ], @@ -128,19 +125,22 @@ "SI-12(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(b)(1)" + "§ 164.502(b)(1)" ], "emea-sau-pdpl-2023": [ "Article 11.3" ], - "emea-zaf-popia-2013": [ - "19" + "emea-che-fadp-2025": [ + "2.1.7.3" + ], + "apac-aus-ism-2026-march": [ + "ISM-2021" ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.2" + "apac-kor-pipa-2011": [ + "III.1.16(1)" ], - "emea-esp-decree-311-2022": [ - "24.2" + "americas-mex-fdpa-2010": [ + "II.13" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-18.2.json b/docs/api/controls/DCH-18.2.json index dedab4ef..b372628b 100644 --- a/docs/api/controls/DCH-18.2.json +++ b/docs/api/controls/DCH-18.2.json @@ -2,8 +2,8 @@ "control_id": "DCH-18.2", "title": "Limit Sensitive / Regulated Data In Testing, Training & Research", "family": "DCH", - "description": "Mechanisms exist to minimize the use of sensitive/regulated data for research, testing, or training, in accordance with authorized, legitimate business practices.", - "scf_question": "Does the organization minimize the use of Personal Data (PD) for research, testing, or training, in accordance with the Data Protection Impact Assessment (DPIA)?", + "description": "Mechanisms exist to minimize the use of sensitive and/or regulated data for research, testing, or training, in accordance with authorized, legitimate business practices.", + "scf_question": "Does the organization minimize the use of sensitive and/or regulated data for research, testing, or training, in accordance with authorized, legitimate business practices?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -120,9 +121,6 @@ "general-nist-800-161-r1-level-2": [ "PM-25" ], - "general-scf-dpmp-2025": [ - "3.2" - ], "usa-federal-fbi-cjis-6-0": [ "SI-12(2)" ], @@ -161,15 +159,6 @@ ], "emea-eu-nis2-annex-2024": [ "6.2.2(f)" - ], - "emea-srb-act-9-2018": [ - "5.1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-chn-pipl-2021": [ - "6" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-18.3.json b/docs/api/controls/DCH-18.3.json index 8470a9d2..0869b62a 100644 --- a/docs/api/controls/DCH-18.3.json +++ b/docs/api/controls/DCH-18.3.json @@ -20,7 +20,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform periodic checks of temporary files for the existence of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} diff --git a/docs/api/controls/DCH-18.json b/docs/api/controls/DCH-18.json index 6dc4377c..b6b4ccc1 100644 --- a/docs/api/controls/DCH-18.json +++ b/docs/api/controls/DCH-18.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ A manual data retention process exists.\n▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -171,7 +172,7 @@ "5.33", "8.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1020.001", @@ -267,14 +268,25 @@ ], "general-nist-800-171-r3": [ "03.01.20.c.02", + "03.10.07.b", "03.14.08" ], "general-nist-800-171a-r3": [ + "A.03.01.20.c.02", + "A.03.10.07.b", "A.03.14.08[01]", "A.03.14.08[02]", "A.03.14.08[03]", "A.03.14.08[04]" ], + "general-nist-800-172-r3": [ + "03.04.06E", + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.06E", + "A.03.10.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "3.2", "3.2.1", @@ -325,9 +337,6 @@ "3.2.1", "9.4.6" ], - "general-scf-dpmp-2025": [ - "5.4" - ], "general-swift-cscf-2025": [ "6.4" ], @@ -358,15 +367,19 @@ "MP-07", "SI-12" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(11)", + "101.640" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(6)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.316(b)(2)(i)", - "164.530(j)(2)" + "§ 164.316(b)(2)(i)", + "§ 164.530(j)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.316(b)(2)(i)" + "§ 164.316(b)(2)(i)" ], "usa-federal-irs-1075-2021": [ "MP-7", @@ -389,6 +402,9 @@ "usa-state-il-pipa-2006": [ "30" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-nv-regulation-5-2024": [ "5.260.5(b)", "5.260.5(c)" @@ -425,42 +441,28 @@ "Article 18.1(e)", "Article 18.3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.8", - "Article 13.7" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module B.9", - "Annex 6 Module C.3.2" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(13)", + "Article 19(6)", + "Article 23(2)" ], "emea-eu-nis2-annex-2024": [ "1.1.1(h)", "4.2.2(f)" ], + "emea-deu-c5-2020": [ + "RB-06" + ], "emea-sau-cscc-1-2019": [ "2-6-1-4", "2-11-2" ], - "emea-srb-act-9-2018": [ - "5.5" - ], - "emea-zaf-popia-2013": [ - "9" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3 & 5" + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-19" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", + "apac-aus-ism-2026-march": [ "ISM-1510" ], - "apac-chn-pipl-2021": [ - "19" - ], "apac-ind-dpdpa-2023": [ "8(7)(a)", "8(8)" @@ -489,8 +491,12 @@ "18.1.3.12", "18.1.3.13.PB" ], + "americas-bmu-mba-coc-2020": [ + "5.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.20.C.02", + "03.10.07.B", "03.14.08" ] } diff --git a/docs/api/controls/DCH-19.json b/docs/api/controls/DCH-19.json index ca4e3b15..b181dd81 100644 --- a/docs/api/controls/DCH-19.json +++ b/docs/api/controls/DCH-19.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to inventory, document and maintain data flows for data that is resident (permanently or temporarily) within a service's geographically distributed applications (physical and virtual), infrastructure, systems components and/or shared with other third-parties.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -154,6 +155,11 @@ "03.04.11.a", "03.04.11.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], "general-nist-csf-2-0": [ "ID.AM-03" ], @@ -183,32 +189,13 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-09 (05)" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], - "emea-ken-pda-2019": [ - "25(h)" - ], - "emea-qat-pdppl-2020": [ - "15" - ], - "emea-sau-sacs-002-2022": [ - "TPC-30" + "emea-deu-c5-2020": [ + "UP-02", + "RB-03" ], "emea-gbr-caf-4-0": [ "B3.a" ], - "apac-aus-privacy-principles-2026": [ - "APP 8" - ], - "apac-chn-pipl-2021": [ - "38", - "39", - "40" - ], - "apac-jpn-ppi-2020": [ - "24(1)" - ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" diff --git a/docs/api/controls/DCH-20.json b/docs/api/controls/DCH-20.json index 56a56ff8..4dc3aa0b 100644 --- a/docs/api/controls/DCH-20.json +++ b/docs/api/controls/DCH-20.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect archived data in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect archived data in accordance with applicable statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} diff --git a/docs/api/controls/DCH-21.json b/docs/api/controls/DCH-21.json index 94d12911..f47d65cf 100644 --- a/docs/api/controls/DCH-21.json +++ b/docs/api/controls/DCH-21.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of, destroy or erase information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -155,8 +156,8 @@ "general-nist-800-171-r3": [ "03.08.03" ], - "general-scf-dpmp-2025": [ - "5.5" + "general-nist-800-171a-r3": [ + "A.03.08.03" ], "usa-federal-fbi-cjis-6-0": [ "SI-12(3)" @@ -204,31 +205,18 @@ "40(b)(1)", "40(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(C)(1)" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-deu-c5-2020": [ - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "11.12", - "15.4" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311" ], "apac-ind-sebi-2024": [ "PR.AA.S13" ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" - ], "americas-can-itsp-10-171-2025": [ "03.08.03" ] diff --git a/docs/api/controls/DCH-22.1.json b/docs/api/controls/DCH-22.1.json index 52692218..0f1ba0a6 100644 --- a/docs/api/controls/DCH-22.1.json +++ b/docs/api/controls/DCH-22.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize technical controls to correct Personal Data (PD) that is inaccurate or outdated, incorrectly determined regarding impact, or incorrectly de-identified.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -112,11 +113,6 @@ "SI-18(04)", "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "5.15", - "6.1", - "6.2" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-18(04)", "SI-18(05)" @@ -137,8 +133,8 @@ "155.260(a)(3)(vi)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)" ], "usa-federal-cms-marse-2-0": [ "IP-3" @@ -149,132 +145,21 @@ "usa-state-va-cdpa-2023": [ "59.1-577.A.2" ], - "emea-aut-fappd-2000": [ - "Sec 27" - ], - "emea-bel-act-8-1992": [ - "10", - "12" - ], - "emea-deu-fdpa-2017": [ - "Sec 20" - ], - "emea-grc-pirppd-1997": [ - "13" - ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "14" - ], - "emea-ita-pdpc-2003": [ - "7" - ], - "emea-nor-pda-2018": [ - "27" - ], - "emea-pol-act-29-1997": [ - "32" - ], - "emea-rus-federal-law-27-2006": [ - "17" - ], "emea-sau-pdpl-2023": [ "Article 17.1" ], - "emea-zaf-popia-2013": [ - "24" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" - ], - "emea-che-fadp-2025": [ - "5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" - ], - "apac-aus-privacy-principles-2026": [ - "APP 13" - ], - "apac-chn-csnip-2012": [ - "8" - ], - "apac-chn-pipl-2021": [ - "46", - "49" - ], - "apac-hkg-pdo-2022": [ - "Sec 22" - ], - "apac-jpn-ppi-2020": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" - ], - "apac-mys-pdpa-2010": [ - "34" + "apac-jpn-appi-2020": [ + "IV.1.29(3)" ], "apac-nzl-privacy-act-2020": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" - ], - "apac-phl-dpa-2012": [ - "34" + "3.1.22.7(4)" ], "apac-sgp-pdpa-2012": [ - "22" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "16.1", - "16.3" - ], - "americas-bhs-dpa-2003": [ - "10" - ], - "americas-bra-lgpd-2018": [ - "18.3" - ], - "americas-can-pipeda-2000": [ - "Principle 10" - ], - "americas-chl-act-19628-1999": [ - "13" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "5.22(2)(a)" ], "americas-mex-fdpa-2010": [ - "24", - "28", - "29" + "III.24", + "IV.28" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-22.2.json b/docs/api/controls/DCH-22.2.json index b9429b13..500d0b99 100644 --- a/docs/api/controls/DCH-22.2.json +++ b/docs/api/controls/DCH-22.2.json @@ -2,8 +2,8 @@ "control_id": "DCH-22.2", "title": "Data Tags", "family": "DCH", - "description": "Mechanisms exist to utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle.", - "scf_question": "Does the organization utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle?", + "description": "Mechanisms exist to utilize data tags to automate tracking of sensitive and/or regulated data across the information lifecycle.", + "scf_question": "Does the organization utilize data tags to automate tracking of sensitive and/or regulated data across the information lifecycle?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-22.3.json b/docs/api/controls/DCH-22.3.json index e892f7a9..108295eb 100644 --- a/docs/api/controls/DCH-22.3.json +++ b/docs/api/controls/DCH-22.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to collect Personal Data (PD) directly from the individual.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to collect Personal Data (PD) directly from the individual. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -96,9 +97,6 @@ ], "emea-sau-pdpl-2023": [ "Article 10" - ], - "apac-jpn-ppi-2020": [ - "17(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-22.json b/docs/api/controls/DCH-22.json index 7b861017..a57100c6 100644 --- a/docs/api/controls/DCH-22.json +++ b/docs/api/controls/DCH-22.json @@ -3,7 +3,7 @@ "title": "Data Quality Operations", "family": "DCH", "description": "Mechanisms exist to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", - "scf_question": "Does the organization check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", + "scf_question": "Does the organization check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -173,16 +174,6 @@ "emea-eu-ai-act-2024": [ "Article 10.3", "Article 17.1(f)" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 1" - ], - "apac-chn-pipl-2021": [ - "8" - ], - "apac-sgp-mas-trm-2021": [ - "5.8.1", - "5.8.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-23.1.json b/docs/api/controls/DCH-23.1.json index d4671e17..6798f7ba 100644 --- a/docs/api/controls/DCH-23.1.json +++ b/docs/api/controls/DCH-23.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to de-identify the dataset upon collection by not collecting Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.2.json b/docs/api/controls/DCH-23.2.json index 5b307e30..a0ed8ed7 100644 --- a/docs/api/controls/DCH-23.2.json +++ b/docs/api/controls/DCH-23.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to refrain from archiving Personal Data (PD) elements if those elements in a dataset will not be needed after the dataset is archived.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.3.json b/docs/api/controls/DCH-23.3.json index 4b36226d..e93e97ec 100644 --- a/docs/api/controls/DCH-23.3.json +++ b/docs/api/controls/DCH-23.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to remove Personal Data (PD) elements from a dataset prior to its release if those elements in the dataset do not need to be part of the data release.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.4.json b/docs/api/controls/DCH-23.4.json index 85897a63..a8567b68 100644 --- a/docs/api/controls/DCH-23.4.json +++ b/docs/api/controls/DCH-23.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to remove, mask, encrypt, hash or replace direct identifiers in a dataset.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.5.json b/docs/api/controls/DCH-23.5.json index 12b887f6..41f43a15 100644 --- a/docs/api/controls/DCH-23.5.json +++ b/docs/api/controls/DCH-23.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to manipulate numerical data, contingency tables and statistical findings so that no person or organization is identifiable in the results of the analysis.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -55,7 +55,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.6.json b/docs/api/controls/DCH-23.6.json index 91fff516..a5db680b 100644 --- a/docs/api/controls/DCH-23.6.json +++ b/docs/api/controls/DCH-23.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prevent disclosure of Personal Data (PD) by adding non-deterministic noise to the results of mathematical operations before the results are reported.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -55,7 +55,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.7.json b/docs/api/controls/DCH-23.7.json index c92bc43e..a723e045 100644 --- a/docs/api/controls/DCH-23.7.json +++ b/docs/api/controls/DCH-23.7.json @@ -2,8 +2,8 @@ "control_id": "DCH-23.7", "title": "Automated De-Identification of Sensitive Data", "family": "DCH", - "description": "Mechanisms exist to perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms.", - "scf_question": "Does the organization perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms?", + "description": "Mechanisms exist to perform de-identification of sensitive and/or regulated data, using validated algorithms and software to implement the algorithms.", + "scf_question": "Does the organization perform de-identification of sensitive and/or regulated data, using validated algorithms and software to implement the algorithms?", "relative_weight": 1, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -54,7 +54,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.8.json b/docs/api/controls/DCH-23.8.json index 37002e89..4ea54b7f 100644 --- a/docs/api/controls/DCH-23.8.json +++ b/docs/api/controls/DCH-23.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform a motivated intruder test on the de-identified dataset to determine if the identified data remains or if the de-identified data can be re-identified.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -55,7 +55,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.9.json b/docs/api/controls/DCH-23.9.json index 042a2e47..82a62036 100644 --- a/docs/api/controls/DCH-23.9.json +++ b/docs/api/controls/DCH-23.9.json @@ -2,8 +2,8 @@ "control_id": "DCH-23.9", "title": "Code Names", "family": "DCH", - "description": "Mechanisms exist to use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data.", - "scf_question": "Does the organization use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data?", + "description": "Mechanisms exist to use aliases to name assets, which are mission-critical and/or contain highly-sensitive and/or regulated data, are unique and not readily associated with a product, project or type of data.", + "scf_question": "Does the organization use aliases to name assets, which are mission-critical and/or contain highly-sensitive and/or regulated data, are unique and not readily associated with a product, project or type of data?", "relative_weight": 1, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -55,7 +55,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-23.json b/docs/api/controls/DCH-23.json index f0d296ca..f03346c2 100644 --- a/docs/api/controls/DCH-23.json +++ b/docs/api/controls/DCH-23.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to anonymize data by removing Personal Data (PD) from datasets.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -104,9 +105,6 @@ "general-nist-800-82-r3": [ "SI-19" ], - "general-scf-dpmp-2025": [ - "5.1" - ], "usa-federal-doc-data-privacy-framework-2023": [ "III.14.a.i", "III.14.g.i" @@ -132,32 +130,29 @@ "emea-eu-ai-act-2024": [ "Article 10.5(b)" ], + "emea-bel-act-30-2018": [ + "Title 4, Chapter III, Section 3, Art. 198", + "Title 4, Chapter III, Section 3, Art. 199", + "Title 4, Chapter III, Section 3, Art. 200", + "Title 4, Chapter III, Section 3, Art. 201" + ], + "emea-deu-fdpa-2017": [ + "3.4.64(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.11.12(2)" + ], "emea-ken-pda-2019": [ - "39(2)" + "IV.39(2)" + ], + "emea-rus-152-fz-2025": [ + "Art. 13.1" ], "emea-srb-act-9-2018": [ - "50.1" - ], - "apac-jpn-ppi-2020": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" - ], - "americas-bra-lgpd-2018": [ - "12" + "IV.2.50(1)" + ], + "americas-arg-ppd-2018": [ + "H.1.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-24.1.json b/docs/api/controls/DCH-24.1.json index a9f2a904..ffac5257 100644 --- a/docs/api/controls/DCH-24.1.json +++ b/docs/api/controls/DCH-24.1.json @@ -3,7 +3,7 @@ "title": "Automated Tools to Support Information Location", "family": "DCH", "description": "Automated mechanisms exist to identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection.", - "scf_question": "Does the organization identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection?", + "scf_question": "Does the organization use automated mechanisms to identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection?", "relative_weight": 6, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -20,7 +20,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -77,9 +77,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Classification & Handling", "crosswalks": { "general-nist-800-53-r5-2": [ @@ -118,63 +118,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "CM-12(01)" - ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-24.json b/docs/api/controls/DCH-24.json index baae718e..33b296b8 100644 --- a/docs/api/controls/DCH-24.json +++ b/docs/api/controls/DCH-24.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify and document the location of information and the specific system components on which the information resides.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -85,14 +85,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF9" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025" ], @@ -120,15 +121,15 @@ "general-nist-800-161-r1-level-3": [ "CM-12" ], + "general-nist-800-171-r3": [ + "03.04.11.a" + ], "general-nist-800-171a-r3": [ "A.03.04.11.a[01]" ], "general-nist-800-207": [ "NIST Tenet 1" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "usa-federal-fbi-cjis-6-0": [ "CM-12" ], @@ -145,68 +146,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-12" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" + "americas-can-itsp-10-171-2025": [ + "03.04.11.A" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-25.1.json b/docs/api/controls/DCH-25.1.json index 043915d1..41e757df 100644 --- a/docs/api/controls/DCH-25.1.json +++ b/docs/api/controls/DCH-25.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to establish organization-defined \"normal business activities\" to identify anomalous transaction activities that can reduce the opportunity for sending (outbound) and/or receiving (inbound) fraudulent actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/DCH-25.json b/docs/api/controls/DCH-25.json index c6189298..08ef4601 100644 --- a/docs/api/controls/DCH-25.json +++ b/docs/api/controls/DCH-25.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict and govern the transfer of sensitive and/or regulated data to third-countries or international organizations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -100,9 +101,6 @@ "general-nist-800-207": [ "NIST Tenet 4" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-swift-cscf-2025": [ "2.4", "2.5A", @@ -127,113 +125,17 @@ "Article 49.4", "Article 49.6" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-isr-cmo-1-0": [ - "10.5" - ], "emea-ken-pda-2019": [ - "25(h)", - "48(a)", - "48(b)", - "48(c)(i)", - "48(c)(ii)", - "48(c)(iii)", - "48(c)(iv)", - "48(c)(v)", - "48(c)(vi)", - "49(1)", - "49(2)", - "49(3)", - "50" + "IV.25(h)" ], "emea-nga-dpr-2019": [ - "2.11", - "2.11(a)", - "2.11(b)", - "2.11(c)", - "2.11(d)", - "2.11(e)", - "2.12", - "2.12(a)", - "2.12(b)", - "2.12(c)", - "2.12(d)", - "2.12(e)", - "2.12(f)" - ], - "emea-qat-pdppl-2020": [ - "15" + "2.11" ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], "emea-sau-pdpl-2023": [ "Article 29.1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-30" - ], - "emea-srb-act-9-2018": [ - "23", - "63", - "63.1", - "63.2", - "63.3", - "63.4", - "65", - "68", - "69", - "69.x", - "70", - "70.1", - "70.2", - "70.3", - "70.4", - "70.5", - "71", - "71.1", - "71.2", - "71.3", - "71.4", - "71.5" - ], - "emea-zaf-popia-2013": [ - "72" - ], - "apac-jpn-ppi-2020": [ - "24(1)" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "26", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-col-law-1581-2012": [ - "26" ] } } \ No newline at end of file diff --git a/docs/api/controls/DCH-26.json b/docs/api/controls/DCH-26.json index 9b3521e2..97dbaa00 100644 --- a/docs/api/controls/DCH-26.json +++ b/docs/api/controls/DCH-26.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to constrain the impact of \"digital sovereignty laws,\" that require localized data within the host country, where data and processes may be subjected to arbitrary enforcement actions that potentially violate other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83,23 +83,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { - "emea-ken-pda-2019": [ - "50" + "emea-sau-cscc-1-2019": [ + "4-2-1-1" + ], + "emea-sau-ecc-1-2018": [ + "4-1-3-2", + "4-2-3-3" ], "apac-chn-cybersecurity-law-2017": [ "Article 37" ], - "apac-chn-data-security-law-2021": [ - "36" - ], "apac-chn-pipl-2021": [ - "36", - "38", - "40" + "Article 40" ], "apac-ind-sebi-2024": [ "PR.DS.S2" diff --git a/docs/api/controls/DCH-27.json b/docs/api/controls/DCH-27.json index 58268872..faaffbe3 100644 --- a/docs/api/controls/DCH-27.json +++ b/docs/api/controls/DCH-27.json @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/controls/EMB-01.json b/docs/api/controls/EMB-01.json index 93b3d80c..46f59d81 100644 --- a/docs/api/controls/EMB-01.json +++ b/docs/api/controls/EMB-01.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Embedded Technology (EMB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with EMB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Embedded technology management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Embedded technologies (e.g., Operational Technology (OT) and Internet of Things (IoT) are managed in the same manner as any other technology asset.", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.", - "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to facilitate the implementation of embedded technology controls.", + "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to facilitate the implementation of embedded technology controls. ", "4": "Embedded Technology (EMB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114,7 +114,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -134,9 +135,6 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-shared-assessments-sig-2025": [ "M.1.1" ], @@ -149,18 +147,6 @@ "usa-federal-dow-zt-roadmap-1-1": [ "2.4.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "12.1", - "12.2", - "12.3" - ], "emea-sau-cgiot-2024": [ "1-1-1", "1-1-2", @@ -170,24 +156,17 @@ "emea-sau-ecc-1-2018": [ "5-1-1", "5-1-2", - "5-1-3", + "5-1-3-1", + "5-1-3-2", "5-1-4" ], "emea-sau-otcc-1-2022": [ - "1-1-2", - "1-6", - "2-1-2", - "2-3-2" - ], - "emea-zaf-popia-2013": [ - "19" + "1-4-1" ], "apac-sgp-mas-trm-2021": [ "11.5.1", "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" + "11.5.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-02.json b/docs/api/controls/EMB-02.json index 5df49023..04cbf973 100644 --- a/docs/api/controls/EMB-02.json +++ b/docs/api/controls/EMB-02.json @@ -103,30 +103,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Embedded Technology", "crosswalks": { "emea-sau-cgiot-2024": [ "2-5-1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 11", - "Principle 13" - ], - "apac-chn-pipl-2021": [ - "26" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.1", - "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-03.json b/docs/api/controls/EMB-03.json index cda7255e..6f2bf810 100644 --- a/docs/api/controls/EMB-03.json +++ b/docs/api/controls/EMB-03.json @@ -103,13 +103,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Embedded Technology", "crosswalks": { - "emea-zaf-popia-2013": [ - "19" + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(v)" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-04.json b/docs/api/controls/EMB-04.json index 8e6056bf..44f4e702 100644 --- a/docs/api/controls/EMB-04.json +++ b/docs/api/controls/EMB-04.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Special baselines for embedded technologies configurations are created for higher-risk environments.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to protect embedded devices against unauthorized use of the physical factory diagnostic and test interface(s).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -119,8 +120,7 @@ "2-14-1" ], "apac-aus-cop-sitc-2020": [ - "Principle 6", - "Principle 13" + "13" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-05.json b/docs/api/controls/EMB-05.json index f5a02145..4e0bf732 100644 --- a/docs/api/controls/EMB-05.json +++ b/docs/api/controls/EMB-05.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to generate log entries on embedded devices when configuration changes or attempts to access interfaces are detected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -120,15 +121,11 @@ "emea-sau-cgiot-2024": [ "2-11-2" ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "emea-sau-ecc-1-2018": [ + "5-1-3-3" ], "apac-aus-cop-sitc-2020": [ - "Principle 8", - "Principle 10" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.5" + "8" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-06.json b/docs/api/controls/EMB-06.json index f49c2d54..2903cfc0 100644 --- a/docs/api/controls/EMB-06.json +++ b/docs/api/controls/EMB-06.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to protect embedded devices by preventing the unauthorized installation and execution of software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -122,15 +123,8 @@ "emea-sau-cgiot-2024": [ "2-6-2" ], - "emea-sau-otcc-1-2022": [ - "1-5-2", - "1-5-3", - "1-5-4", - "2-3-1-5", - "2-3-1-6" - ], "apac-aus-cop-sitc-2020": [ - "Principle 6" + "13" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-07.json b/docs/api/controls/EMB-07.json index 1a7a3ee1..1bca8078 100644 --- a/docs/api/controls/EMB-07.json +++ b/docs/api/controls/EMB-07.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to securely update software and upgrade functionality on embedded devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,20 +103,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "emea-sau-cgiot-2024": [ "2-4-6" ], - "emea-sau-otcc-1-2022": [ - "1-5-4", - "2-2-1-4" - ], "apac-aus-cop-sitc-2020": [ - "Principle 3", - "Principle 12" + "3" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-08.json b/docs/api/controls/EMB-08.json index 7f439bb0..a3416659 100644 --- a/docs/api/controls/EMB-08.json +++ b/docs/api/controls/EMB-08.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to configure embedded technology to be resilient to data network and power outages.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -113,7 +114,7 @@ "3-1-2" ], "apac-aus-cop-sitc-2020": [ - "Principle 9" + "9" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-09.json b/docs/api/controls/EMB-09.json index 46f0e512..d24d026f 100644 --- a/docs/api/controls/EMB-09.json +++ b/docs/api/controls/EMB-09.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to automatically monitor the power levels of embedded technologies for decreased or excessive power usage, including battery drainage, to investigate for device tampering.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -78,7 +78,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -87,6 +88,12 @@ ], "emea-sau-cgiot-2024": [ "2-11-2" + ], + "emea-sau-ecc-1-2018": [ + "5-1-3-3" + ], + "apac-aus-cop-sitc-2020": [ + "10" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-10.json b/docs/api/controls/EMB-10.json index 20dd7e17..a8703e62 100644 --- a/docs/api/controls/EMB-10.json +++ b/docs/api/controls/EMB-10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to perform evaluations of deployed embedded technologies as needed, or at least on an annual basis, to ensure that necessary updates to mitigate the risks associated with legacy embedded technologies are identified and implemented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -81,15 +82,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.5" - ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1", - "1-6-2", - "2-1-2", - "2-3-2", - "2-7-2", - "2-9-2" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-11.json b/docs/api/controls/EMB-11.json index 53d856e5..703546e3 100644 --- a/docs/api/controls/EMB-11.json +++ b/docs/api/controls/EMB-11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to enforce the security of Message Queuing Telemetry Transport (MQTT) traffic.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { diff --git a/docs/api/controls/EMB-12.json b/docs/api/controls/EMB-12.json index b45eae19..cde60495 100644 --- a/docs/api/controls/EMB-12.json +++ b/docs/api/controls/EMB-12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to require embedded technologies to initiate all communications and drop new, incoming communications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,13 +63,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "general-csa-iot-2": [ "CLS-08", "COM-10" + ], + "apac-aus-cop-sitc-2020": [ + "13" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-13.json b/docs/api/controls/EMB-13.json index 1b524946..c2558ece 100644 --- a/docs/api/controls/EMB-13.json +++ b/docs/api/controls/EMB-13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to restrict embedded technologies to communicate only with authorized peers and service endpoints.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -75,26 +76,8 @@ "general-shared-assessments-sig-2025": [ "M.1.1" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4", - "2-2-1-7", - "2-4-1", - "2-4-1-1", - "2-4-1-2", - "2-4-1-3", - "2-4-1-4", - "2-4-1-5", - "2-4-1-6", - "2-4-1-7", - "2-4-1-8", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13", - "2-4-1-14", - "2-4-1-15", - "2-4-1-16" + "apac-aus-cop-sitc-2020": [ + "13" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-14.json b/docs/api/controls/EMB-14.json index 2f146e2b..edadb006 100644 --- a/docs/api/controls/EMB-14.json +++ b/docs/api/controls/EMB-14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to determine if embedded technologies are certified for secure use in the proposed operating environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -88,10 +89,6 @@ "general-ul-2900-2-2-2016": [ "8.3", "9.2" - ], - "emea-sau-otcc-1-2022": [ - "1-5-3-3", - "2-4-1-15" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-15.json b/docs/api/controls/EMB-15.json index 09da727d..0b1581d6 100644 --- a/docs/api/controls/EMB-15.json +++ b/docs/api/controls/EMB-15.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to evaluate the safety aspects of embedded technologies via a fault tree analysis, or similar method, to determine possible consequences of misuse, misconfiguration and/or failure.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { diff --git a/docs/api/controls/EMB-16.json b/docs/api/controls/EMB-16.json index 9c0e691f..c0a49544 100644 --- a/docs/api/controls/EMB-16.json +++ b/docs/api/controls/EMB-16.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to enforce certificate-based authentication for embedded technologies (e.g., IoT, OT, etc.) and their supporting services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { diff --git a/docs/api/controls/EMB-17.json b/docs/api/controls/EMB-17.json index c1e66905..938410da 100644 --- a/docs/api/controls/EMB-17.json +++ b/docs/api/controls/EMB-17.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to implement embedded technologies that utilize pre-provisioned cloud trust anchors to support secure bootstrap and Zero Touch Provisioning (ZTP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { diff --git a/docs/api/controls/EMB-18.json b/docs/api/controls/EMB-18.json index 7f7aab7b..3830ee10 100644 --- a/docs/api/controls/EMB-18.json +++ b/docs/api/controls/EMB-18.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to ensure embedded technologies utilize a securely configured Real-Time Operating System (RTOS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -71,6 +72,9 @@ "IOT-06", "IOT-07", "IOT-09" + ], + "general-nist-cswp-39": [ + "4.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/EMB-19.json b/docs/api/controls/EMB-19.json index a83ee241..bc33d31e 100644 --- a/docs/api/controls/EMB-19.json +++ b/docs/api/controls/EMB-19.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to continuously validate autonomous systems that trigger an automatic state change when safe operation is no longer assured.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -78,16 +78,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "general-csa-iot-2": [ "SAP-02", "SAP-09" - ], - "emea-sau-otcc-1-2022": [ - "3-1-1-5" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-01.1.json b/docs/api/controls/END-01.1.json index fb104e99..a8e12a54 100644 --- a/docs/api/controls/END-01.1.json +++ b/docs/api/controls/END-01.1.json @@ -109,7 +109,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-01.json b/docs/api/controls/END-01.json index 18714623..32e04dd5 100644 --- a/docs/api/controls/END-01.json +++ b/docs/api/controls/END-01.json @@ -118,7 +118,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -129,7 +130,7 @@ "CC6.7-POF4" ], "general-cis-csc-8-1": [ - "10.0" + "10" ], "general-cobit-2019": [ "DSS05.03", @@ -210,6 +211,7 @@ "3.14.2" ], "general-nist-800-171-r3": [ + "03.01.03", "03.14.02.a" ], "general-nist-800-171a": [ @@ -220,7 +222,9 @@ "3.4.2[b]" ], "general-nist-800-171a-r3": [ - "A.03.01.03[01]" + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.14.02.a[01]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -287,10 +291,10 @@ "MP-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "MP-2" @@ -311,57 +315,24 @@ "MP-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(d)" + "3.4.4.36(d)" ], "emea-eu-nis2-annex-2024": [ "6.9.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "15.5" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-2", - "2-5" - ], - "emea-sau-ecc-1-2018": [ - "2-3-4", - "2-4-4" - ], - "emea-sau-otcc-1-2022": [ - "2-5", - "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", - "2-5-1-4", - "2-5-1-5", - "2-5-2" + "2-3-1-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-12", - "TPC-22" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.1 [MP.EQ.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-caf-4-0": [ "B3.d" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" - ], "emea-gbr-def-stan-05-138-2024": [ "2317", "2411" @@ -382,33 +353,14 @@ "5.1.1.15", "12.2.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP34" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP30" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.5" - ], - "apac-sgp-mas-trm-2021": [ - "11.3.1", - "11.3.2", - "11.3.3", - "11.3.4", - "11.3.5", - "11.4.1", - "11.4.2", - "11.4.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.12" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ + "03.01.03", "03.14.02.A" ] } diff --git a/docs/api/controls/END-02.json b/docs/api/controls/END-02.json index 8831c79c..e6bd1373 100644 --- a/docs/api/controls/END-02.json +++ b/docs/api/controls/END-02.json @@ -20,7 +20,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to protect the confidentiality, integrity, availability and safety of endpoint devices.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -104,16 +104,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { "general-cis-csc-8-1": [ - "10.0", + "10", "10.3", "10.4", "10.5", - "11.0" + "11" ], "general-cis-csc-8-1-ig1": [ "10.3" @@ -246,10 +247,10 @@ "SC-28" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ "SC-28" @@ -270,19 +271,16 @@ "usa-state-vt-act-171-2018": [ "2447(c)(6)" ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "15.5" - ], "emea-sau-cscc-1-2019": [ "2-3-1-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-22" + "emea-esp-decree-311-2022": [ + "Article 23" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -318,15 +316,13 @@ "6.2.1.21", "6.2.1.22" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.5" + "apac-sgp-mas-trm-2021": [ + "11.1.3", + "11.1.4", + "11.1.5" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "americas-arg-ppd-2018": [ + "E.1.2-5" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-03.1.json b/docs/api/controls/END-03.1.json index 8eb0df22..f4f630fa 100644 --- a/docs/api/controls/END-03.1.json +++ b/docs/api/controls/END-03.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to generate an alert when new software is detected.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to generate an alert when new software is detected. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -142,6 +143,9 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], "usa-federal-fbi-cjis-6-0": [ "CM-8(3)" ], @@ -163,9 +167,6 @@ ], "usa-federal-cms-marse-2-0": [ "CM-8(3)" - ], - "emea-isr-cmo-1-0": [ - "6.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-03.2.json b/docs/api/controls/END-03.2.json index b5a47de6..ce0d2f1f 100644 --- a/docs/api/controls/END-03.2.json +++ b/docs/api/controls/END-03.2.json @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-03.json b/docs/api/controls/END-03.json index 329c8891..0881cf7a 100644 --- a/docs/api/controls/END-03.json +++ b/docs/api/controls/END-03.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically prohibit software installations without explicitly assigned privileged status.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically prohibit software installations without explicitly assigned privileged status. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92,7 +92,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -200,12 +201,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CM-11" - ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-04.1.json b/docs/api/controls/END-04.1.json index 6d27e25b..b778b63f 100644 --- a/docs/api/controls/END-04.1.json +++ b/docs/api/controls/END-04.1.json @@ -3,7 +3,7 @@ "title": "Automatic Antimalware Signature Updates", "family": "END", "description": "Automated mechanisms exist to update antimalware technologies, including signature definitions.", - "scf_question": "Does the organization automatically update antimalware technologies, including signature definitions?", + "scf_question": "Does the organization use automated mechanisms to update antimalware technologies, including signature definitions?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -20,7 +20,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware detection tools are configured to automatically update.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically update antimalware technologies, including signature definitions.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically update antimalware technologies, including signature definitions. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -297,11 +298,14 @@ "emea-eu-nis2-annex-2024": [ "6.9.2" ], - "emea-isr-cmo-1-0": [ - "7.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.6" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5-BP1-1" ], "emea-gbr-def-stan-05-138-2024": [ "2426" diff --git a/docs/api/controls/END-04.2.json b/docs/api/controls/END-04.2.json index 0e5da75c..d02c47d3 100644 --- a/docs/api/controls/END-04.2.json +++ b/docs/api/controls/END-04.2.json @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-04.3.json b/docs/api/controls/END-04.3.json index ca53a924..7483b768 100644 --- a/docs/api/controls/END-04.3.json +++ b/docs/api/controls/END-04.3.json @@ -109,7 +109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -152,6 +153,9 @@ "general-nist-800-171-r3": [ "03.14.02.a" ], + "general-nist-800-171a-r3": [ + "A.03.14.02.a[01]" + ], "general-pci-dss-4-0-1": [ "5.3.4" ], @@ -188,13 +192,6 @@ "usa-federal-cms-marse-2-0": [ "SI-3(1)" ], - "emea-isr-cmo-1-0": [ - "7.7", - "12.20" - ], - "apac-sgp-mas-trm-2021": [ - "11.3.5" - ], "americas-can-itsp-10-171-2025": [ "03.14.02.A" ] diff --git a/docs/api/controls/END-04.4.json b/docs/api/controls/END-04.4.json index 9f628d0a..4c651562 100644 --- a/docs/api/controls/END-04.4.json +++ b/docs/api/controls/END-04.4.json @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -196,13 +197,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "SI-03" ], - "emea-isr-cmo-1-0": [ - "7.8" - ], - "emea-sau-ecc-1-2018": [ - "2-4-3-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1284", "ISM-1286", "ISM-1288", diff --git a/docs/api/controls/END-04.5.json b/docs/api/controls/END-04.5.json index 75025fce..9db01aa0 100644 --- a/docs/api/controls/END-04.5.json +++ b/docs/api/controls/END-04.5.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to test antimalware technologies by introducing a known benign, non-spreading test case into the system and subsequently verifying that both detection of the test case and associated incident reporting occurs.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to test antimalware technologies by introducing a known benign, non-spreading test case into the system and subsequently verifying that both detection of the test case and associated incident reporting occurs. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-04.6.json b/docs/api/controls/END-04.6.json index a089de97..2f9df679 100644 --- a/docs/api/controls/END-04.6.json +++ b/docs/api/controls/END-04.6.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to perform periodic evaluations evolving malware threats to assess systems that are generally not considered to be commonly affected by malicious software.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to perform periodic evaluations evolving malware threats to assess systems that are generally not considered to be commonly affected by malicious software. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -111,9 +112,6 @@ ], "general-shared-assessments-sig-2025": [ "J.5.1" - ], - "emea-isr-cmo-1-0": [ - "12.20" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-04.7.json b/docs/api/controls/END-04.7.json index c0a6323c..296a63ae 100644 --- a/docs/api/controls/END-04.7.json +++ b/docs/api/controls/END-04.7.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure that anti-malware technologies are continuously running in real-time and cannot be disabled or altered by non-privileged users, unless specifically authorized by management on a case-by-case basis for a limited time period.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure that anti-malware technologies are continuously running in real-time and cannot be disabled or altered by non-privileged users, unless specifically authorized by management on a case-by-case basis for a limited time period. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -131,6 +132,7 @@ "3.14.5[c]" ], "general-nist-800-171a-r3": [ + "A.03.14.02.a[01]", "A.03.14.02.c.01[01]", "A.03.14.02.c.01[02]" ], @@ -186,12 +188,12 @@ "SI-3(IRS-Defined)-1", "SI-3(IRS-Defined)-2" ], - "emea-isr-cmo-1-0": [ - "7.5", - "12.25" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.1" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP1-2", + "5-BP1-3" ], "emea-gbr-def-stan-05-138-2024": [ "2426" diff --git a/docs/api/controls/END-04.json b/docs/api/controls/END-04.json index 652fe502..df0963e4 100644 --- a/docs/api/controls/END-04.json +++ b/docs/api/controls/END-04.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-malware technologies are decentralized but are deployed on all technology assets that can run anti-malware software.", + "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-malware technologies are decentralized but are deployed on all technology assets that can run anti-malware software. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).\n▪ Anti-malware detection tools are configured to automatically update.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize antimalware technologies to detect and eradicate malicious code.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -107,7 +108,7 @@ "CC6.8-POF4" ], "general-cis-csc-8-1": [ - "10.0", + "10", "10.1", "10.4" ], @@ -170,7 +171,7 @@ "general-iso-27018-2025": [ "8.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -461,6 +462,7 @@ "A.03.14.02.ODP[01]", "A.03.14.02.a[01]", "A.03.14.02.a[02]", + "A.03.14.02.c.01[01]", "A.03.14.02.c.02" ], "general-nist-csf-2-0": [ @@ -611,31 +613,31 @@ "6.9.2" ], "emea-deu-c5-2020": [ - "OPS-04", - "OPS-05" + "RB-05" ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "12.20", - "15.5" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.1" ], "emea-sau-ecc-1-2018": [ "2-3-3-1", - "2-4-3-4", "5-1-3-10" ], "emea-sau-otcc-1-2022": [ + "2-3-1-1", "2-3-1-8" ], "emea-sau-sacs-002-2022": [ - "TPC-12" + "VII.A.TPC-12" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.6 [OP.EXP.6]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.6" + ], + "emea-gbr-cap-1850-2020": [ + "C2" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5", + "5-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "2411", @@ -653,7 +655,7 @@ "2411", "2426" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1284", "ISM-1286", "ISM-1288", @@ -661,7 +663,8 @@ "ISM-1290", "ISM-1293", "ISM-1417", - "ISM-1608" + "ISM-1608", + "ISM-1969" ], "apac-ind-sebi-2024": [ "PR.IP.S4" @@ -679,18 +682,16 @@ "12.2.1.9", "12.2.1.15" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP62", "HML62" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS10" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP54" ], "apac-nzl-ism-3-9": [ - "14.1.9.C.02" + "14.1.9.C.02", + "21.3.10.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.5" @@ -698,13 +699,12 @@ "apac-sgp-mas-trm-2021": [ "11.3.3" ], + "americas-arg-ppd-2018": [ + "E.1.2-6" + ], "americas-bmu-mba-coc-2020": [ "6.12" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ "03.14.02.C", "03.14.02.C.01", diff --git a/docs/api/controls/END-05.json b/docs/api/controls/END-05.json index 22b61f98..6ef681fb 100644 --- a/docs/api/controls/END-05.json +++ b/docs/api/controls/END-05.json @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -123,15 +124,14 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.5.1" ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-22" + ], "emea-gbr-cyber-essentials-requirements-3-3": [ "1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1416" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-06.1.json b/docs/api/controls/END-06.1.json index 886a3582..f713044c 100644 --- a/docs/api/controls/END-06.1.json +++ b/docs/api/controls/END-06.1.json @@ -20,7 +20,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to validate configurations through integrity checking of software and firmware.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -132,6 +133,18 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(01)" ], + "general-nist-800-172-r3": [ + "03.14.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.08E[01]", + "A.03.14.08E.ODP[02]", + "A.03.14.08E.ODP[04]", + "DS-A.03.14.08E[02]", + "A.03.14.08E.ODP[06]", + "DS-A.03.14.08E[03]", + "A.03.14.08E.ODP[10]" + ], "general-swift-cscf-2025": [ "6.2" ], diff --git a/docs/api/controls/END-06.2.json b/docs/api/controls/END-06.2.json index 4fb9dba2..def87ec0 100644 --- a/docs/api/controls/END-06.2.json +++ b/docs/api/controls/END-06.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to detect and respond to unauthorized configuration changes as cybersecurity incidents.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -144,6 +145,12 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(07)" ], + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" + ], "general-pci-dss-4-0-1": [ "10.7", "10.7.1", @@ -190,9 +197,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SI-07 (07)" - ], - "emea-isr-cmo-1-0": [ - "7.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-06.3.json b/docs/api/controls/END-06.3.json index 711e57e4..810e5c52 100644 --- a/docs/api/controls/END-06.3.json +++ b/docs/api/controls/END-06.3.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically alert incident response personnel upon discovering discrepancies during integrity verification.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically alert incident response personnel upon discovering discrepancies during integrity verification. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -84,7 +84,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-06.4.json b/docs/api/controls/END-06.4.json index c0f4ea56..0cdace22 100644 --- a/docs/api/controls/END-06.4.json +++ b/docs/api/controls/END-06.4.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions when integrity violations are discovered.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions when integrity violations are discovered. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -84,7 +84,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-06.5.json b/docs/api/controls/END-06.5.json index ae0c3441..b74d11ad 100644 --- a/docs/api/controls/END-06.5.json +++ b/docs/api/controls/END-06.5.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically verify the integrity of the boot process of systems.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -84,7 +84,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -108,9 +109,6 @@ ], "general-sparta": [ "CM0014" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 8" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-06.6.json b/docs/api/controls/END-06.6.json index cf68603a..05516efb 100644 --- a/docs/api/controls/END-06.6.json +++ b/docs/api/controls/END-06.6.json @@ -20,7 +20,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically protect the integrity of boot firmware in systems.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -86,7 +86,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -107,6 +108,13 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(10)" ], + "general-nist-800-172-r3": [ + "03.14.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.10E", + "A.03.14.10E.ODP[01]" + ], "general-sparta": [ "CM0014" ], @@ -114,7 +122,7 @@ "SI-7(CE-10)" ], "apac-aus-cop-sitc-2020": [ - "Principle 8" + "8" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-06.7.json b/docs/api/controls/END-06.7.json index 8b6e261c..b03d6dd9 100644 --- a/docs/api/controls/END-06.7.json +++ b/docs/api/controls/END-06.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to prohibit the use of binary or machine-executable code from sources with limited or no warranty and without access to source code.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-06.8.json b/docs/api/controls/END-06.8.json index e5b6ed3c..6a913692 100644 --- a/docs/api/controls/END-06.8.json +++ b/docs/api/controls/END-06.8.json @@ -85,13 +85,30 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.7.2", "2.7.3" + ], + "emea-sau-ecc-1-2018": [ + "2-4-3-4" + ], + "emea-sau-otcc-1-2022": [ + "2-3-1-1", + "2-3-1-12" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-06.json b/docs/api/controls/END-06.json index 0ae5b325..377634d4 100644 --- a/docs/api/controls/END-06.json +++ b/docs/api/controls/END-06.json @@ -22,7 +22,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize File Integrity Monitor (FIM), or similar technologies, to detect and report on unauthorized changes to selected files and configuration settings.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -126,7 +127,7 @@ "general-iec-62443-4-2-2019": [ "CR 3.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1020.001", @@ -379,6 +380,15 @@ "general-nist-800-161-r1-level-3": [ "SI-7" ], + "general-nist-800-172-r3": [ + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.01E.a[01]", + "A.03.14.01E.ODP[01]", + "DS-A.03.14.01E.a[02]", + "A.03.14.01E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.CM-09" ], @@ -438,14 +448,7 @@ "SI-07" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(e)" - ], - "emea-isr-cmo-1-0": [ - "6.4", - "12.19" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "3.4.4.36(e)" ], "emea-gbr-def-stan-05-138-2024": [ "2425" diff --git a/docs/api/controls/END-07.json b/docs/api/controls/END-07.json index 39869849..3b180bb1 100644 --- a/docs/api/controls/END-07.json +++ b/docs/api/controls/END-07.json @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -120,6 +121,11 @@ "03.14.06.b", "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" + ], "general-shared-assessments-sig-2025": [ "N.7" ], @@ -134,17 +140,7 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.14(b)(1)" ], - "emea-isr-cmo-1-0": [ - "7.4", - "7.5", - "12.18", - "12.24", - "23.6" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1034", "ISM-1341", "ISM-1418" @@ -152,10 +148,6 @@ "apac-nzl-ism-3-9": [ "18.4.13.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ "03.14.06.A.01", "03.14.06.A.02", diff --git a/docs/api/controls/END-08.1.json b/docs/api/controls/END-08.1.json index eac25815..5f95af65 100644 --- a/docs/api/controls/END-08.1.json +++ b/docs/api/controls/END-08.1.json @@ -1,9 +1,9 @@ { "control_id": "END-08.1", - "title": "Central Management", + "title": "Phishing & Spam Protection Centralized Management", "family": "END", - "description": "Mechanisms exist to centrally-manage anti-phishing and spam protection technologies.", - "scf_question": "Does the organization centrally-manage anti-phishing and spam protection technologies?", + "description": "Mechanisms exist to centrally manage anti-phishing and spam protection technologies.", + "scf_question": "Does the organization centrally manage anti-phishing and spam protection technologies?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-spam/phishing technologies are centralized and built into existing email capabilities.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-spam/phishing technologies are centralized and built into existing email capabilities.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to centrally-manage anti-phishing and spam protection technologies.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to centrally manage anti-phishing and spam protection technologies.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -103,8 +103,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control\n- wordsmithed", "family_name": "Endpoint Security", "crosswalks": { "general-nist-800-53-r4": [ @@ -142,10 +144,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "PL-09" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-08.2.json b/docs/api/controls/END-08.2.json index 782d2661..2bcfd3be 100644 --- a/docs/api/controls/END-08.2.json +++ b/docs/api/controls/END-08.2.json @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-08.json b/docs/api/controls/END-08.json index f3f80a68..388b5a12 100644 --- a/docs/api/controls/END-08.json +++ b/docs/api/controls/END-08.json @@ -92,12 +92,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.6", "9.7" ], @@ -120,7 +121,7 @@ "general-govramp-high": [ "SI-08" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.001", "T1137.002", @@ -218,7 +219,7 @@ "2-4-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-16" + "VII.A.TPC-16" ], "emea-gbr-def-stan-05-138-2024": [ "2509" @@ -233,19 +234,7 @@ "2509" ], "apac-nzl-ism-3-9": [ - "15.2.21.C.01", - "15.2.23.C.01", - "15.2.23.C.02", - "15.2.23.C.03", - "15.2.24.C.01", - "15.2.24.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.6" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "15.2.37.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-09.json b/docs/api/controls/END-09.json index bf9b300a..54329ffc 100644 --- a/docs/api/controls/END-09.json +++ b/docs/api/controls/END-09.json @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -113,8 +114,8 @@ "general-ul-2900-2-2-2016": [ "8.10(b)" ], - "emea-isr-cmo-1-0": [ - "4.37" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-10.json b/docs/api/controls/END-10.json index a60ef2a2..c4efdaa3 100644 --- a/docs/api/controls/END-10.json +++ b/docs/api/controls/END-10.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to address mobile code / operating system-independent applications.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to address mobile code / operating system-independent applications. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -131,7 +132,7 @@ "NDR 2.4(c)", "NDR 2.4(1)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.003", "T1055", "T1055.001", @@ -241,9 +242,14 @@ "A.03.13.13.a[01]", "A.03.13.13.a[02]", "A.03.13.13.b[01]", - "A.03.13.13.b[02]", "A.03.13.13.b[03]" ], + "general-nist-800-172-r3": [ + "03.13.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.06E" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.SE.ACMIT", "3.PEP.WE.ACMIT" diff --git a/docs/api/controls/END-11.json b/docs/api/controls/END-11.json index 1deb65db..14e66af9 100644 --- a/docs/api/controls/END-11.json +++ b/docs/api/controls/END-11.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to configure thin nodes to have minimal functionality and information storage.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to configure thin nodes to have minimal functionality and information storage. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -100,6 +101,12 @@ ], "general-nist-800-160-vol-2-r1": [ "SC-25" + ], + "general-nist-800-172-r3": [ + "03.13.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.11E[01]" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-12.json b/docs/api/controls/END-12.json index be44a684..2527c8a9 100644 --- a/docs/api/controls/END-12.json +++ b/docs/api/controls/END-12.json @@ -85,11 +85,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1025", "T1052", "T1052.001", @@ -114,6 +115,14 @@ "general-nist-800-82-r3-high": [ "SC-41" ], + "general-nist-800-172-r3": [ + "03.13.13E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.13E", + "A.03.13.13E.ODP[02]", + "A.03.13.13E.ODP[03]" + ], "usa-federal-nerc-cip-2024": [ "CIP-007-6 1.2" ] diff --git a/docs/api/controls/END-13.1.json b/docs/api/controls/END-13.1.json index 2070008a..59bf2627 100644 --- a/docs/api/controls/END-13.1.json +++ b/docs/api/controls/END-13.1.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -100,16 +101,8 @@ "general-nist-800-82-r3": [ "SC-42(02)" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-shared-assessments-sig-2025": [ "P.2.2.1" - ], - "emea-zaf-popia-2013": [ - "8", - "9", - "13.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-13.2.json b/docs/api/controls/END-13.2.json index 5eb313e2..a68813c0 100644 --- a/docs/api/controls/END-13.2.json +++ b/docs/api/controls/END-13.2.json @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -81,14 +82,11 @@ "general-nist-800-82-r3": [ "SC-42(04)" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-tisax-6-0-3": [ "8.2.6" ], - "emea-zaf-popia-2013": [ - "18" + "emea-aut-dpa-2018": [ + "§ 12(2)" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-13.3.json b/docs/api/controls/END-13.3.json index 2e253a6b..ac53cb7f 100644 --- a/docs/api/controls/END-13.3.json +++ b/docs/api/controls/END-13.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize sensors that are configured to minimize the collection of information about individuals.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -107,9 +108,6 @@ "general-nist-800-161-r1-level-2": [ "PM-25" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-25", "SA-08(33)" @@ -129,8 +127,8 @@ "emea-sau-cgiot-2024": [ "2-6-3" ], - "emea-zaf-popia-2013": [ - "10" + "emea-che-fadp-2025": [ + "2.1.7.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/END-13.4.json b/docs/api/controls/END-13.4.json index 7797fa8a..cc0a2343 100644 --- a/docs/api/controls/END-13.4.json +++ b/docs/api/controls/END-13.4.json @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-13.json b/docs/api/controls/END-13.json index 4ae444ae..a400f819 100644 --- a/docs/api/controls/END-13.json +++ b/docs/api/controls/END-13.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-14.1.json b/docs/api/controls/END-14.1.json index 478a4635..1a293765 100644 --- a/docs/api/controls/END-14.1.json +++ b/docs/api/controls/END-14.1.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to disable or remove collaborative computing devices from critical systems and secure work areas.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-14.2.json b/docs/api/controls/END-14.2.json index 2f3e5848..e34fb2b4 100644 --- a/docs/api/controls/END-14.2.json +++ b/docs/api/controls/END-14.2.json @@ -86,7 +86,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-14.3.json b/docs/api/controls/END-14.3.json index 264d135c..993acf8b 100644 --- a/docs/api/controls/END-14.3.json +++ b/docs/api/controls/END-14.3.json @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-14.4.json b/docs/api/controls/END-14.4.json index 690f74a9..8fb627fd 100644 --- a/docs/api/controls/END-14.4.json +++ b/docs/api/controls/END-14.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure the meeting host can positively control an individual's participation in virtual meetings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-14.5.json b/docs/api/controls/END-14.5.json index 3d5dbc28..131e1002 100644 --- a/docs/api/controls/END-14.5.json +++ b/docs/api/controls/END-14.5.json @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-14.6.json b/docs/api/controls/END-14.6.json index 47d88203..49f95b24 100644 --- a/docs/api/controls/END-14.6.json +++ b/docs/api/controls/END-14.6.json @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-14.json b/docs/api/controls/END-14.json index 82003feb..e2cb23d9 100644 --- a/docs/api/controls/END-14.json +++ b/docs/api/controls/END-14.json @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -173,15 +174,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-15" ], - "emea-isr-cmo-1-0": [ - "5.6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0231" ], - "apac-chn-pipl-2021": [ - "26" - ], "americas-can-itsp-10-171-2025": [ "03.13.12.A" ] diff --git a/docs/api/controls/END-15.json b/docs/api/controls/END-15.json index bb8eb903..39e70bd6 100644 --- a/docs/api/controls/END-15.json +++ b/docs/api/controls/END-15.json @@ -86,8 +86,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", - "crosswalks": {} + "crosswalks": { + "apac-sgp-mas-trm-2021": [ + "11.4.2" + ] + } } \ No newline at end of file diff --git a/docs/api/controls/END-16.1.json b/docs/api/controls/END-16.1.json index 44926472..417e73de 100644 --- a/docs/api/controls/END-16.1.json +++ b/docs/api/controls/END-16.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to implement underlying software separation mechanisms to facilitate security function isolation.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to implement underlying software separation mechanisms to facilitate security function isolation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/controls/END-16.json b/docs/api/controls/END-16.json index 372a5e18..bed7c404 100644 --- a/docs/api/controls/END-16.json +++ b/docs/api/controls/END-16.json @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -171,7 +172,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-03" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1006" ] } diff --git a/docs/api/controls/GOV-01.1.json b/docs/api/controls/GOV-01.1.json index 474e3ccc..ac08eb47 100644 --- a/docs/api/controls/GOV-01.1.json +++ b/docs/api/controls/GOV-01.1.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to trends.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align security, compliance and resilience capabilities with business requirements through a steering committee or advisory board, comprised of key cybersecurity, data protection and business executives, which meets formally and on a regular basis.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align security, compliance and resilience capabilities with business requirements through a steering committee or advisory board, comprised of key cybersecurity, data protection and business executives, which meets formally and on a regular basis.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -97,10 +97,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", @@ -255,6 +255,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-csf-2-0": [ "GV.RM-01", "GV.RM-03", @@ -357,9 +360,9 @@ "500.4(d)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(2)", - "3.2.1(3)", - "3.2.1(4)" + "3.2.1.2", + "3.2.1.3", + "3.2.1.4" ], "emea-eu-dora-2023": [ "Article 5.2", @@ -394,21 +397,46 @@ "2.2", "2.3", "2.4", - "2.5" + "2.5", + "4.3" + ], + "emea-deu-c5-2020": [ + "OIS-01" + ], + "emea-isr-cmo-2-0": [ + "2.A" ], "emea-sau-cgiot-2024": [ "1-1-4" ], - "emea-sau-sama-csf-1-2017": [ - "3.1.1" + "emea-sau-ecc-1-2018": [ + "1-1-1", + "1-2-3", + "1-4-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 27" + "emea-sau-sama-csf-1-2017": [ + "3.1.1.1", + "3.1.1.2", + "3.1.1.3", + "3.1.1.3.a", + "3.1.1.3.b", + "3.1.1.3.c", + "3.1.1.4", + "3.1.1.4.a", + "3.1.1.4.b", + "3.1.1.4.c", + "3.1.1.4.d", + "3.1.1.5", + "3.1.1.6", + "3.1.1.7", + "3.1.1.8", + "3.1.1.9", + "3.1.1.9.a", + "3.1.1.9.b", + "3.1.1.9.c" ], "emea-esp-decree-311-2022": [ - "27", - "5" + "Article 12(1)(d)" ], "emea-gbr-caf-4-0": [ "A1.a", @@ -432,22 +460,24 @@ "1103", "1202" ], - "apac-aus-ism-2024-june": [ - "ISM-0725" + "apac-aus-ism-2026-march": [ + "ISM-0725", + "ISM-1998", + "ISM-1999", + "ISM-2002", + "ISM-2003", + "ISM-2005", + "ISM-2006" ], "apac-aus-ps-cps-230-2023": [ - "20", - "21", - "22(a)", - "22(b)", - "22(c)", - "23", + "16(a)", + "17", + "18", "24", - "25" + "27(a)" ], "apac-aus-ps-cps-234-2019": [ - "13", - "19" + "13" ], "apac-ind-dpdpa-2023": [ "8(6)", @@ -485,7 +515,16 @@ "4.6.3.2", "4.6.3.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.3", + "8.4", + "8.5", + "8.7", + "11.17", + "12.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP12", "HML12", "HML21" @@ -500,41 +539,27 @@ "apac-sgp-mas-trm-2021": [ "3.1.1", "3.1.2", - "3.1.3", - "3.1.4", "3.1.5", - "3.1.6", + "3.1.7", "3.1.7(a)", "3.1.7(b)", "3.1.7(c)", "3.1.7(d)", "3.1.7(e)", "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", - "3.1.8(e)" + "3.1.7(g)" ], "americas-bmu-mba-coc-2020": [ - "5.1", - "5.6" - ], - "amaericas-can-osfi-self-assessment": [ - "6.5", - "6.6", - "6.7", - "6.21", - "6.22", - "6.23", - "6.24" + "5.1" ], "americas-can-osfi-b13-2022": [ "1", "1.1.2", "1.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] diff --git a/docs/api/controls/GOV-01.2.json b/docs/api/controls/GOV-01.2.json index 1b039f1e..b4f0b50a 100644 --- a/docs/api/controls/GOV-01.2.json +++ b/docs/api/controls/GOV-01.2.json @@ -3,7 +3,7 @@ "title": "Status Reporting To Governing Body", "family": "GOV", "description": "Mechanisms exist to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", - "scf_question": "Does the organization provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP)?", + "scf_question": "Does the organization provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to its Security, Compliance & Resilience Program (SCRP)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -25,9 +25,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to trends.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,10 +84,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF2", @@ -163,6 +163,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-csf-2-0": [ "GV.OV", "GV.OV-01", @@ -171,16 +174,16 @@ "GV.SC-09", "ID" ], - "general-scf-dpmp-2025": [ - "11.5", - "11.8" - ], "usa-federal-doe-c2m2-2-1": [ "PROGRAM-2g" ], "usa-federal-sro-fca-crm-2023": [ "609.930(e)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(14)", + "101.645(a)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(i)", "314.4(i)(1)", @@ -201,8 +204,8 @@ "500.4(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(e)", - "3.3.5(24)" + "3.3.1.13(e)", + "3.3.5.24" ], "emea-eu-dora-2023": [ "Article 5.2(i)", @@ -217,19 +220,29 @@ "13.2.2(c)" ], "emea-deu-bsrit-2017": [ - "3.9", "3.11", "4.10", "7.5" ], - "apac-aus-ism-2024-june": [ - "ISM-0718" + "emea-deu-c5-2020": [ + "SPN-01" + ], + "emea-sau-ecc-1-2018": [ + "1-8-3" + ], + "emea-esp-decree-311-2022": [ + "Article 31(6)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" + ], + "apac-aus-ism-2026-march": [ + "ISM-0718", + "ISM-1918", + "ISM-2000" ], "apac-aus-ps-cps-230-2023": [ - "30", - "58(a)", - "58(b)", - "58(c)" + "58" ], "apac-ind-dpdpa-2023": [ "10(2)(c)(ii)" @@ -240,7 +253,13 @@ "apac-jpn-ismap": [ "4.6.1.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.4", + "8.6", + "9.3", + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP46", "HHSP75", "HML12", @@ -252,6 +271,10 @@ "HSUP38", "HSUP65" ], + "apac-sgp-mas-trm-2021": [ + "3.1.3", + "3.1.8(e)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1.2" diff --git a/docs/api/controls/GOV-01.3.json b/docs/api/controls/GOV-01.3.json index eee236e5..f7cba36a 100644 --- a/docs/api/controls/GOV-01.3.json +++ b/docs/api/controls/GOV-01.3.json @@ -3,7 +3,7 @@ "title": "Commitment To Continual Improvements", "family": "GOV", "description": "Mechanisms exist to commit appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", - "scf_question": "Does the organization commit appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies?", + "scf_question": "Does the organization commit appropriate resources needed for continual improvement of its Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to observed trends.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ Appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ Appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -60,10 +60,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.3-POF4" @@ -106,14 +106,45 @@ "EF:SG3.SP3", "EF:SG4.SP3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.48" + ], "emea-eu-nis2-annex-2024": [ "1.1.1(d)", "1.1.1(e)" ], + "emea-deu-bsrit-2017": [ + "2.2", + "4.4" + ], + "emea-deu-c5-2020": [ + "OIS-01-BP3", + "SA-02-BP2" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 5", + "Appendix A, 1.1" + ], + "emea-sau-ecc-1-2018": [ + "1-1-3", + "1-3-4", + "2-3-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-69" + ], + "emea-esp-decree-311-2022": [ + "Article 12(6)(ñ)", + "Article 27" + ], "apac-jpn-ismap": [ "4.6.1.1", "4.6.1.2", "4.6.3.3" + ], + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-01.4.json b/docs/api/controls/GOV-01.4.json new file mode 100644 index 00000000..d6f688cc --- /dev/null +++ b/docs/api/controls/GOV-01.4.json @@ -0,0 +1,130 @@ +{ + "control_id": "GOV-01.4", + "title": "Secure Practices Alignment Justification", + "family": "GOV", + "description": "Mechanisms exist to align the organization’s Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices.", + "scf_question": "Does the organization align its Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align the organization’s Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Informal alignment with NIST CSF 2.0, SCF CORE Fundamentals, CIS Controls or another framework that meets the organization's needs.", + "small": "∙ Formal alignment with NIST CSF 2.0, SCF CORE Fundamentals, CIS Controls or another framework that meets the organization's needs.\n∙ Gap analysis documentation\n∙ Written justification for framework choices.", + "medium": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ Documented gap analysis and justification\n∙ GRC platform alignment reports (e.g., SCFConnect)", + "large": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ Regulatory mapping evidence packages\n∙ GRC platform with framework comparison reporting", + "enterprise": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ External auditor validation\n∙ Board-level reporting on framework compliance\n∙ GRC platform with automated framework mapping" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "emea-eu-psd2-2015": [ + "98(1)", + "98(1)(a)", + "98(1)(b)", + "98(1)(c)", + "98(1)(d)", + "98(2)", + "98(3)", + "98(4)", + "98(5)" + ], + "emea-deu-bsrit-2017": [ + "2.1" + ], + "emea-deu-c5-2020": [ + "OIS-01", + "RB-22-DOAR" + ], + "emea-sau-otcc-1-2022": [ + "1-1-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.3", + "3.2.3.1", + "3.2.3.1.a", + "3.2.3.1.b", + "3.2.3.1.c" + ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(b)" + ], + "apac-nzl-ism-3-9": [ + "5.1.16.C.02" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/GOV-01.json b/docs/api/controls/GOV-01.json index 20318b37..5c836c39 100644 --- a/docs/api/controls/GOV-01.json +++ b/docs/api/controls/GOV-01.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "Cybersecurity & Data Protection Governance (GOV) capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement and manage the organization's internal control system.\n▪ Legal representation is consulted on an as-needed basis.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,10 +102,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF6" @@ -263,6 +263,9 @@ "general-nist-800-171-r3": [ "03.15.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[01]" + ], "general-nist-csf-2-0": [ "GV", "GV.RM-01", @@ -280,9 +283,6 @@ "12.4", "A3.1.2" ], - "general-scf-dpmp-2025": [ - "1.0" - ], "general-sparta": [ "CM0005" ], @@ -426,6 +426,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PM-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(1)" + ], "usa-federal-sro-finra": [ "248.30(a)(2)(ii)", "248.201(e)" @@ -446,18 +449,18 @@ "155.260(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)", - "164.530(c)(1)", - "164.530(i)(1)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)", + "§ 164.530(c)(1)", + "§ 164.530(i)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)" ], "usa-federal-irs-1075-2021": [ "PM-1" @@ -531,6 +534,9 @@ "emea-eu-ai-act-2024": [ "Article 17.2" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.1.30" + ], "emea-eu-dora-2023": [ "Article 5.1", "Article 9.4", @@ -563,144 +569,75 @@ "1.1.1(b)", "6.7.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" + "emea-eu-psd2-2015": [ + "95(1)", + "97(3)" ], "emea-deu-bsrit-2017": [ - "4.1" + "3.1", + "4.1", + "4.8" ], "emea-deu-c5-2020": [ - "OIS-01" - ], - "emea-grc-pirppd-1997": [ - "10" - ], - "emea-hun-isdfi-2011": [ - "7" + "OIS-01", + "OIS-01-BP1", + "OIS-01-DOAR" ], - "emea-irl-dpa-2003": [ - "2" + "emea-isr-cmo-2-0": [ + "2.A", + "4.2, Stage 0" ], - "emea-isr-cmo-1-0": [ - "3.2", - "4.25" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-1-2" ], "emea-sau-ecc-1-2018": [ "1-2-1", - "1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "1-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "2-1-1" ], "emea-sau-sama-csf-1-2017": [ "3.1.1" ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 6.1", - "Article 6.2", - "Article 13.1", - "Article 35.1" - ], "emea-esp-decree-311-2022": [ - "13.1", - "35.1", - "5", - "6.1", - "6.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "6.1 [ORG.1]" - ], - "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "Article 8(1)", + "Article 8(2)", + "Article 8(5)", + "Article 9(1)", + "Article 9(1)(a)", + "Article 9(1)(b)", + "Article 9(2)", + "Article 10(1)", + "Article 10(2)", + "Article 10(3)", + "Article 12(6)(a)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-cap-1850-2020": [ - "A1" + "A1", + "B1" ], - "apac-aus-privacy-act-1998": [ - "APP Part 1", - "APP Part 11" + "apac-aus-ism-2026-march": [ + "ISM-0047" ], - "apac-aus-ism-2024-june": [ - "ISM-0888" + "apac-aus-ps-cps-230-2023": [ + "12(a)", + "16(c)" ], "apac-aus-ps-cps-234-2019": [ - "13", - "18", - "19" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" - ], - "apac-hkg-pdo-2022": [ - "Principle 4" - ], - "apac-ind-privacy-rules-2011": [ - "8" + "15", + "17" ], "apac-ind-sebi-2024": [ "GV.OC.S1", "GV.OC.S2", "PR.IP.S17" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "4.4.1.1", "4.4.1.2", @@ -713,41 +650,22 @@ "5.1.1", "6.1" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "10.1", + "11.1", + "11.2", + "11.5" ], "apac-nzl-ism-3-9": [ - "5.1.14.C.01" - ], - "apac-phl-dpa-2012": [ - "25", - "27", - "28" + "5.1.14.C.01", + "5.1.16.C.01", + "16.1.24.C.01" ], - "apac-sgp-pdpa-2012": [ - "12", - "24" - ], - "apac-kor-pipa-2011": [ - "3", - "29", - "30" - ], - "apac-twn-pdpa-2025": [ - "27" - ], - "americas-bhs-dpa-2003": [ - "6" + "apac-sgp-mas-trm-2021": [ + "3.1.4" ], "americas-bmu-mba-coc-2020": [ - "4", - "5.4" - ], - "amaericas-can-osfi-self-assessment": [ - "6.5", - "6.6", - "6.7", - "6.23" + "6.1" ], "americas-can-osfi-b13-2022": [ "1", @@ -756,20 +674,11 @@ "2.1.1", "3" ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4" - ], - "americas-mex-fdpa-2010": [ - "19" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-02.1.json b/docs/api/controls/GOV-02.1.json index 8caa7d31..0268ffb7 100644 --- a/docs/api/controls/GOV-02.1.json +++ b/docs/api/controls/GOV-02.1.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to prohibit exceptions to standards, except when the exception has been formally assessed for risk impact, approved and recorded.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to prohibit exceptions to standards, except when the exception has been formally assessed for risk impact, approved and recorded.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96,9 +96,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-cobit-2019": [ "DSS06.04" @@ -117,11 +118,14 @@ "2.3.7", "2.7.3" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(14)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.1", @@ -133,11 +137,18 @@ "500.12(b)", "500.15(b)" ], + "emea-deu-c5-2020": [ + "SA-03" + ], "apac-ind-sebi-2024": [ "GV.PO.S3" ], "apac-jpn-ismap": [ "5.1.1.7" + ], + "apac-sgp-mas-trm-2021": [ + "3.2.2", + "7.3.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-02.json b/docs/api/controls/GOV-02.json index 9fe6a8ab..035cbd48 100644 --- a/docs/api/controls/GOV-02.json +++ b/docs/api/controls/GOV-02.json @@ -22,7 +22,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ People affected by documentation changes are provided notification of the policy and standard changes.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ The organization's cybersecurity policies and standards are made available to internal personnel.\n▪ Documented procedures exist for requesting a deviation from approved standards.\n▪ The responsibility for enforcing cybersecurity and data protection control implementation is assigned to business / process owners and asset custodians.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,10 +95,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.0", @@ -665,6 +665,19 @@ "A.03.15.01.a[03]", "A.03.15.01.a[04]" ], + "general-nist-800-172-r3": [ + "03.01.17E", + "03.05.07E", + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]", + "A.03.05.07E.ODP[01]", + "DS-A.03.17.03E.a[01]", + "DS-A.03.17.03E.a[02]", + "DS-A.03.17.03E.a[03]", + "DS-A.03.17.03E.a[04]" + ], "general-nist-csf-2-0": [ "GV.PO", "GV.PO-01", @@ -802,9 +815,6 @@ "12.1.2", "12.1.3" ], - "general-scf-dpmp-2025": [ - "11.2" - ], "general-sparta": [ "CM0088" ], @@ -955,6 +965,9 @@ "SI-01", "SR-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)" + ], "usa-federal-sro-finra": [ "248.30(a)(1)", "248.30(a)(2)" @@ -970,41 +983,41 @@ "155.260(d)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)", - "164.530(j)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)", + "§ 164.530(j)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)" ], "usa-federal-irs-1075-2021": [ "2.C.2", @@ -1114,6 +1127,10 @@ "17.03(2)(c)", "17.04" ], + "usa-state-nv-privacy-law-2023": [ + "603A.525.2", + "603A.525.2(a)" + ], "usa-state-nv-regulation-5-2024": [ "5.260.6" ], @@ -1209,9 +1226,9 @@ "SI-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.1(28)", - "3.4.1(29)", - "3.4.5(38)" + "3.4.1.28", + "3.4.5.38", + "3.5.50" ], "emea-eu-dora-2023": [ "Article 6.2", @@ -1245,127 +1262,122 @@ "9.1", "11.1.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.2", - "4.3", "4.8" ], "emea-deu-c5-2020": [ - "OIS-01", "OIS-02", - "SP-01" - ], - "emea-isr-cmo-1-0": [ - "1.1", - "4.1", - "4.25", - "5.2", - "5.3", - "9.1", - "10.1", - "11.2", - "12.1", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "20.1", - "21.1", - "22.1", - "24.1", - "25.1" - ], - "emea-nga-dpr-2019": [ - "4.1(1)" - ], - "emea-qat-pdppl-2020": [ - "8.4" + "OIS-06", + "SA-01", + "SA-01-BP1", + "SA-01-BP2", + "SA-01-BP3", + "SA-01-BP4", + "SA-01-BP5", + "SA-01-BP6", + "MDM-01" ], "emea-sau-cgiot-2024": [ "1-2-1" ], "emea-sau-ecc-1-2018": [ "1-3-1", - "1-3-3" + "1-3-3", + "2-1-1", + "2-1-2", + "2-1-3", + "2-1-4", + "2-2-1", + "2-2-2" ], "emea-sau-otcc-1-2022": [ - "1-1", - "1-1-1" + "1-1-1", + "1-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-25" + "VII.B.TPC-24", + "VII.B.TPC-25" ], "emea-sau-sama-csf-1-2017": [ - "3.1.3" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 12.1", - "Article 12.1(a)", - "Article 12.1(b)", - "Article 12.1(c)", - "Article 12.1(d)", - "Article 12.1(e)", - "Article 12.1(f)", - "Article 12.2", - "Article 12.6", - "Article 12.6(a)", - "Article 12.6(b)", - "Article 12.6(c)", - "Article 12.6(d)", - "Article 12.6(e)", - "Article 12.6(f)", - "Article 12.6(g)", - "Article 12.6(h)", - "Article 12.6(i)", - "Article 12.6(j)", - "Article 12.6(k)", - "Article 12.6(l)", - "Article 12.6(m)", - "Article 12.6(n)", - "Article 12.6(ñ)", - "Article 12.7" + "3.1.3", + "3.1.3.1", + "3.1.3.3", + "3.1.3.3.a", + "3.1.3.3.b", + "3.1.3.3.c", + "3.1.3.3.d", + "3.1.3.4", + "3.1.3.4.a", + "3.1.3.4.b", + "3.1.3.4.c", + "3.1.3.4.d", + "3.1.3.4.e", + "3.1.3.4.f", + "3.1.3.4.f.1", + "3.1.3.4.f.2", + "3.1.3.4.f.3", + "3.1.3.4.f.4", + "3.1.3.4.f.5", + "3.1.3.4.f.6", + "3.1.3.4.f.7", + "3.1.3.4.f.8", + "3.3.5.1", + "3.3.5.4", + "3.3.5.4.a", + "3.3.5.4.b", + "3.3.5.4.b.1", + "3.3.5.4.b.2", + "3.3.5.4.b.3", + "3.3.5.4.b.4", + "3.3.5.4.b.5", + "3.3.5.4.b.6", + "3.3.5.4.b.7", + "3.3.5.4.c", + "3.3.5.4.d", + "3.3.5.4.e", + "3.3.5.4.f", + "3.3.5.4.f.1", + "3.3.5.4.f.1.a", + "3.3.5.4.f.1.b", + "3.3.5.4.f.2", + "3.3.5.4.f.3", + "3.3.5.4.f.4", + "3.3.5.4.f.4.a", + "3.3.5.4.f.4.b", + "3.3.5.4.f.4.c", + "3.3.8", + "3.3.8.1", + "3.3.8.4", + "3.3.8.5", + "3.3.8.6", + "3.3.8.6.a", + "3.3.8.6.b", + "3.3.8.6.c", + "3.3.8.6.d", + "3.3.8.6.e", + "3.3.8.6.f", + "3.3.8.6.g", + "3.3.8.6.h", + "3.3.8.6.h.1", + "3.3.8.6.h.2", + "3.3.8.6.h.3", + "3.3.8.6.h.4", + "3.3.8.6.h.5", + "3.3.8.6.i", + "3.3.8.6.j", + "3.3.10", + "3.3.10.1" ], "emea-esp-decree-311-2022": [ - "12.1", - "12.1(a)", - "12.1(b)", - "12.1(c)", - "12.1(d)", - "12.1(e)", - "12.1(f)", - "12.2", - "12.6", - "12.6(a)", - "12.6(b)", - "12.6(c)", - "12.6(d)", - "12.6(e)", - "12.6(f)", - "12.6(g)", - "12.6(h)", - "12.6(i)", - "12.6(j)", - "12.6(k)", - "12.6(l)", - "12.6(m)", - "12.6(n)", - "12.6(ñ)", - "12.7" - ], - "emea-esp-ccn-stic-825-2023": [ - "6.1 [ORG.1]", - "6.2 [ORG.2]" + "Article 11(3)", + "Article 12(1)", + "Article 12(6)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-caf-4-0": [ "A1", @@ -1373,8 +1385,7 @@ "B1.b" ], "emea-gbr-cap-1850-2020": [ - "A1", - "A5" + "A1" ], "emea-gbr-def-stan-05-138-2024": [ "1100", @@ -1399,20 +1410,23 @@ "2101" ], "apac-aus-privacy-principles-2026": [ - "APP 1" + "1.1.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0047", - "ISM-0888", "ISM-1478", "ISM-1551", "ISM-1602", "ISM-1784", - "ISM-1785" + "ISM-1785", + "ISM-2074" + ], + "apac-aus-ps-cps-230-2023": [ + "12(a)", + "47" ], "apac-aus-ps-cps-234-2019": [ - "18", - "19" + "18" ], "apac-ind-sebi-2024": [ "GV.PO.S1" @@ -1430,12 +1444,16 @@ "6", "6.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HML01", - "HHSP01" + "apac-mys-bnm-rmit-2025": [ + "8.6", + "9.5", + "10.16", + "10.20", + "11.12" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS02" + "HML01", + "HHSP01" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP01" @@ -1451,21 +1469,55 @@ "5.1.20.C.01", "5.1.20.C.02", "5.2.3.C.01", - "5.2.3.C.02" + "5.2.3.C.02", + "11.1.15.C.01", + "11.1.15.C.02", + "11.3.5.C.01", + "11.4.9.C.01", + "11.5.13.C.01", + "11.8.3.C.01", + "16.1.24.C.01", + "20.2.15.C.04", + "21.1.6.C.01", + "22.1.10.C.01", + "22.1.22.C.01" + ], + "apac-sgp-pdpa-2012": [ + "3.12(a)", + "3.12(c)" + ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(a)" ], "apac-sgp-mas-trm-2021": [ - "3.2.1" + "3.1.8(c)", + "3.2.1", + "3.3.1(d)", + "5.3.1", + "6.1.3", + "6.4.4", + "11.1.1" ], - "amaericas-can-osfi-self-assessment": [ - "6.1", - "6.3" + "americas-bmu-mba-coc-2020": [ + "5.3", + "7.1" ], "americas-can-osfi-b13-2022": [ "1", "3" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "2.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4" + ], + "americas-col-law-1581-2012": [ + "VI.17(k)" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-03.json b/docs/api/controls/GOV-03.json index d0267c32..b6542d35 100644 --- a/docs/api/controls/GOV-03.json +++ b/docs/api/controls/GOV-03.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel perform an annual documentation review process that includes the scope of applicable statutory, regulatory and/or contractual obligations.\n▪ Recommendations for documentation edits are submitted for review and are handled in accordance with documentation change control processes.\n▪ Updated documentation versions are published, based on no less than an annual review cycle.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to review the Security, Compliance & Resilience Program (SCRP), including policies, standards and procedures, at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to review the Security, Compliance & Resilience Program (SCRP), including policies, standards and procedures, at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness. ", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75,10 +75,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF5", @@ -514,7 +514,8 @@ "general-nist-800-171a-r3": [ "A.03.15.01.ODP[01]", "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.b[02]", + "A.03.15.03.d[01]" ], "general-nist-csf-2-0": [ "GV.PO-02", @@ -618,9 +619,6 @@ "12.1.1", "12.1.2" ], - "general-scf-dpmp-2025": [ - "11.3" - ], "general-tisax-6-0-3": [ "1.5.1" ], @@ -735,6 +733,9 @@ "SI-01", "SR-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(b)", "314.4(g)" @@ -743,16 +744,16 @@ "155.260(a)(5)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)", - "164.530(i)(2)(i)", - "164.530(i)(2)(ii)", - "164.530(i)(2)(iii)", - "164.530(i)(3)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)", + "§ 164.530(i)(2)(i)", + "§ 164.530(i)(2)(ii)", + "§ 164.530(i)(2)(iii)", + "§ 164.530(i)(3)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "AC-1", @@ -873,7 +874,7 @@ "2447(b)(9)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(14)" + "3.3.1.14" ], "emea-eu-nis2-annex-2024": [ "1.1.2", @@ -881,39 +882,18 @@ "5.1.6", "6.7.3" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.2", - "4.8" + "4.4" ], "emea-deu-c5-2020": [ - "OIS-01", - "SP-02" - ], - "emea-isr-cmo-1-0": [ - "1.1", - "5.2", - "9.1", - "10.1", - "11.2", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "21.1", - "22.1", - "24.1", - "25.1" + "SA-02", + "SA-02-BP1", + "SA-02-BP2", + "SA-02-BP3" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 1.1" ], "emea-sau-cgiot-2024": [ "1-1-4", @@ -924,11 +904,8 @@ "emea-sau-ecc-1-2018": [ "1-1-3", "1-3-4", - "1-6-4", - "1-9-6", - "1-10-5", - "2-2-4", - "2-3-4", + "1-4-2", + "2-1-6", "2-4-4", "2-5-4", "2-6-4", @@ -949,11 +926,13 @@ "emea-sau-otcc-1-2022": [ "1-1-3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 27" + "emea-sau-sama-csf-1-2017": [ + "3.1.3.2" ], - "emea-esp-decree-311-2022": [ - "27" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-caf-4-0": [ "B1.a" @@ -973,12 +952,10 @@ "2100", "2101" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ + "ISM-0888", "ISM-1617" ], - "apac-aus-ps-cps-234-2019": [ - "19" - ], "apac-ind-sebi-2024": [ "GV.PO.S2", "GV.PO.S3", @@ -994,7 +971,10 @@ "5.1.2.3", "5.1.2.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -1007,7 +987,7 @@ "5.1.21.C.02" ], "apac-sgp-mas-trm-2021": [ - "3.2.2" + "3.2.1" ], "americas-can-osfi-b13-2022": [ "1", diff --git a/docs/api/controls/GOV-04.1.json b/docs/api/controls/GOV-04.1.json index c6e767f8..d412a803 100644 --- a/docs/api/controls/GOV-04.1.json +++ b/docs/api/controls/GOV-04.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to enforce an accountability structure so that appropriate teams and individuals are empowered, responsible and trained for mapping, measuring and managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to enforce an accountability structure so that appropriate teams and individuals are empowered, responsible and trained for mapping, measuring and managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105,10 +105,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1", @@ -183,6 +183,9 @@ "general-nist-800-37-r2": [ "TASK P-9" ], + "general-nist-800-172a-r3": [ + "A.03.02.03E.ODP[01]" + ], "general-nist-800-218": [ "PO.2.3" ], @@ -212,6 +215,9 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)" + ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(c)(1)" ], @@ -223,14 +229,55 @@ "Article 17.1(m)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.7.5(91)" + "3.3.1.11", + "3.3.1.12" ], "emea-deu-bsrit-2017": [ "4.5", "4.6", "4.10" ], + "emea-deu-c5-2020": [ + "SA-01-BP4" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" + ], + "emea-qat-pdppl-2020": [ + "3.11.2" + ], + "emea-sau-ecc-1-2018": [ + "1-4-1" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.4.1", + "3.1.4.1.a", + "3.1.4.1.b", + "3.1.4.1.c", + "3.1.4.1.c.1", + "3.1.4.1.c.2", + "3.1.4.1.c.3", + "3.1.4.2", + "3.1.4.2.a", + "3.1.4.2.b", + "3.1.4.2.c", + "3.1.4.2.c.1", + "3.1.4.2.c.2", + "3.1.4.2.c.3", + "3.1.4.2.c.4", + "3.1.4.2.c.5", + "3.1.4.2.c.6", + "3.1.4.3", + "3.1.4.3.a", + "3.1.4.3.b", + "3.1.4.3.c", + "3.1.4.5", + "3.1.4.5.a" + ], + "emea-esp-decree-311-2022": [ + "Article 11(2)", + "Article 13(3)" + ], "emea-gbr-caf-4-0": [ "A1.b" ], @@ -246,14 +293,19 @@ "1101", "1103" ], - "apac-aus-ps-cps-230-2023": [ - "21" + "apac-aus-ps-cps-234-2019": [ + "14" ], "apac-ind-sebi-2024": [ "GV.RR.S1", "GV.RR.S2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6", + "10.35", + "11.8" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21", "HHSP27", "HML21", @@ -263,11 +315,23 @@ "HSUP19", "HSUP23" ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(c)", + "3.1.8", + "3.1.8(a)", + "3.1.8(b)", + "3.1.8(c)", + "3.1.8(d)", + "3.1.8(e)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1", "1.1.1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-04.2.json b/docs/api/controls/GOV-04.2.json index aab0b360..8512442a 100644 --- a/docs/api/controls/GOV-04.2.json +++ b/docs/api/controls/GOV-04.2.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish an authoritative chain of command with clear lines of communication to remove ambiguity from individuals and teams related to managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish an authoritative chain of command with clear lines of communication to remove ambiguity from individuals and teams related to managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,10 +100,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1" @@ -175,13 +175,11 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.4(b)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" ], - "emea-deu-bsrit-2017": [ - "4.5", - "4.6", - "4.10" + "emea-sau-ecc-1-2018": [ + "1-4-1" ], "emea-gbr-caf-4-0": [ "A1.b" @@ -195,19 +193,28 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1103" ], - "apac-aus-ps-cps-230-2023": [ - "21" + "apac-aus-ps-cps-234-2019": [ + "14" ], "apac-ind-sebi-2024": [ "GV.OC.S1", "GV.PO.S5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "11.8" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21" ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(c)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-04.json b/docs/api/controls/GOV-04.json index 7cdd2b00..5daa65c2 100644 --- a/docs/api/controls/GOV-04.json +++ b/docs/api/controls/GOV-04.json @@ -26,9 +26,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is assigned the role and responsibilities to centrally manage, coordinate, develop, implement and maintain a cybersecurity and data protection program (e.g., cybersecurity director or Chief Information Security Officer (CISO)).\n▪ The individual assigned the role and responsibilities to centrally manage, coordinate, develop, implement and maintain a cybersecurity and data protection program develops plans to implement the organization's security, compliance and resiliency-related objectives.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ A qualified individual is assigned the role and responsibilities to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP) (e.g., cybersecurity director or Chief Information Security Officer (CISO)).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ A qualified individual is assigned the role and responsibilities to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP) (e.g., cybersecurity director or Chief Information Security Officer (CISO)).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99,10 +99,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1" @@ -369,6 +369,11 @@ "PM-06", "PM-29" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)", + "101.620(b)(3)", + "101.625(c)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(a)", "314.4(a)(1)", @@ -376,10 +381,10 @@ "314.4(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "usa-federal-irs-1075-2021": [ "PM-2", @@ -428,9 +433,7 @@ "Article 17.1(m)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.3.1(12)", - "3.7.5(91)" + "3.3.1.11" ], "emea-eu-dora-2023": [ "Article 5.2", @@ -452,33 +455,54 @@ "1.2.1", "1.2.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ - "4.4", "4.5", "4.6" ], - "emea-deu-c5-2020": [ - "OIS-03" + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B" ], "emea-sau-ecc-1-2018": [ "1-2-2", - "1-4-1", - "1-4-2", - "1-5-2" - ], - "emea-sau-otcc-1-2022": [ - "1-2", - "1-2-1-2" + "1-4-1" ], "emea-sau-sama-csf-1-2017": [ - "3.1.4" + "3.1.4", + "3.1.4.4", + "3.1.4.4.a", + "3.1.4.4.a.1", + "3.1.4.4.a.2", + "3.1.4.4.a.3", + "3.1.4.4.a.4", + "3.1.4.4.b", + "3.1.4.4.c", + "3.1.4.4.d", + "3.1.4.4.e", + "3.1.4.4.e.1", + "3.1.4.4.e.2", + "3.1.4.4.e.3", + "3.1.4.4.e.4", + "3.1.4.4.e.5", + "3.1.4.4.f", + "3.1.4.4.g", + "3.1.4.4.g.1", + "3.1.4.4.g.2", + "3.1.4.4.g.3", + "3.1.4.4.h", + "3.1.4.4.i", + "3.1.4.4.i.1", + "3.1.4.4.i.2", + "3.1.4.4.i.3", + "3.1.4.4.i.4" + ], + "emea-esp-decree-311-2022": [ + "Article 13(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "emea-gbr-caf-4-0": [ "A1.b", @@ -499,7 +523,7 @@ "1102", "1103" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0714", "ISM-0717", "ISM-0720", @@ -510,22 +534,17 @@ "ISM-0732", "ISM-0733", "ISM-0734", - "ISM-0735" + "ISM-0735", + "ISM-1997" ], "apac-aus-ps-cps-230-2023": [ - "21", - "24" + "23" ], "apac-aus-ps-cps-234-2019": [ - "14", - "19" + "14" ], "apac-chn-data-security-law-2021": [ - "45", - "46" - ], - "apac-chn-pipl-2021": [ - "52" + "Article 27" ], "apac-ind-dpdpa-2023": [ "19(3)" @@ -540,7 +559,11 @@ "5.1.1.6", "5.1.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6", + "9.4" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21", "HHSP27", "HML21", @@ -581,32 +604,24 @@ "3.2.19.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.1.7(a)", - "3.1.7(b)", - "3.1.7(c)", - "3.1.7(d)", - "3.1.7(e)", - "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", - "3.1.8(e)" + "3.1.3", + "3.1.8" + ], + "americas-arg-ppd-2018": [ + "E.1.2-8" ], "americas-bmu-mba-coc-2020": [ "5.2" ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "1.2", - "6.2" - ], "americas-can-osfi-b13-2022": [ "1", "1.1", "1.1.1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.1", + "1.1.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-05.1.json b/docs/api/controls/GOV-05.1.json index 96e26e4e..e0c31402 100644 --- a/docs/api/controls/GOV-05.1.json +++ b/docs/api/controls/GOV-05.1.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -63,10 +63,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", diff --git a/docs/api/controls/GOV-05.2.json b/docs/api/controls/GOV-05.2.json index 8da6b8ba..85f77bbc 100644 --- a/docs/api/controls/GOV-05.2.json +++ b/docs/api/controls/GOV-05.2.json @@ -20,9 +20,9 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to observed trends.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -68,10 +68,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", @@ -97,6 +97,12 @@ ], "general-nist-csf-2-0": [ "GV.RM-01" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-05.json b/docs/api/controls/GOV-05.json index 8de18904..aeec0c5c 100644 --- a/docs/api/controls/GOV-05.json +++ b/docs/api/controls/GOV-05.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Basic metrics are developed to provide operational oversight of a limited scope of cybersecurity and data protection controls.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -68,10 +68,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.1-POF3", @@ -195,6 +195,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-800-207": [ "NIST Tenet 7" ], @@ -207,9 +210,6 @@ "GV.SC-09", "ID.IM-03" ], - "general-scf-dpmp-2025": [ - "11.5" - ], "general-tisax-6-0-3": [ "1.2.1" ], @@ -260,6 +260,9 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-06" ], + "emea-eu-eba-ict-srm-2025": [ + "3.5.51" + ], "emea-eu-dora-2023": [ "Article 13.4" ], @@ -269,19 +272,28 @@ "emea-eu-nis2-annex-2024": [ "1.1.1(j)" ], - "emea-us-psd2-2015": [ - "3" + "emea-deu-bsrit-2017": [ + "2.5", + "4.9" ], "emea-deu-c5-2020": [ - "COM-04" + "OIS-01-BP2" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 5", + "Appendix D" ], "emea-sau-cgiot-2024": [ "1-1-4" ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.2 [OP.MON.2]" + "emea-sau-otcc-1-2022": [ + "1-4-2", + "1-7-2" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" + ], + "apac-aus-ism-2026-march": [ "ISM-0724" ], "apac-ind-sebi-2024": [ @@ -292,7 +304,10 @@ "apac-jpn-ismap": [ "4.6.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP46", "HML46" ], @@ -300,14 +315,7 @@ "HSUP38" ], "apac-sgp-mas-trm-2021": [ - "4.5.3", - "7.8.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.9" + "4.5.3" ], "americas-can-osfi-b13-2022": [ "1", diff --git a/docs/api/controls/GOV-06.json b/docs/api/controls/GOV-06.json index 29014a3f..dc781cb9 100644 --- a/docs/api/controls/GOV-06.json +++ b/docs/api/controls/GOV-06.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity personnel identify and maintain contact information for local and national law enforcement (e.g., FBI field office) in case of cybersecurity incidents that require law enforcement involvement.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -69,9 +69,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF4", @@ -175,7 +176,7 @@ "IR-06" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 31.4" @@ -183,29 +184,6 @@ "emea-deu-c5-2020": [ "OIS-05" ], - "emea-esp-boe-a-2022-7191": [ - "Article 32.1", - "Article 32.2", - "Article 32.3" - ], - "emea-esp-decree-311-2022": [ - "32.1", - "32.2", - "32.3" - ], - "apac-aus-ps-cps-230-2023": [ - "33", - "42", - "51", - "59(a)", - "59(b)" - ], - "apac-aus-ps-cps-234-2019": [ - "35", - "35(a)", - "35(b)", - "36" - ], "apac-jpn-ismap": [ "6.1.3", "6.1.3.1", diff --git a/docs/api/controls/GOV-07.json b/docs/api/controls/GOV-07.json index 298e2499..3d689e85 100644 --- a/docs/api/controls/GOV-07.json +++ b/docs/api/controls/GOV-07.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Cybersecurity and data privacy personnel identify and maintain contact information for local, regional and national cybersecurity / data privacy groups and associations.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.\n", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -87,10 +87,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF4", @@ -208,8 +208,8 @@ "6.1.4.5", "6.1.4.6" ], - "amaericas-can-osfi-self-assessment": [ - "3.7" + "americas-can-osfi-self-assessment-2": [ + "3.1.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-08.json b/docs/api/controls/GOV-08.json index a81b4ef6..1277b001 100644 --- a/docs/api/controls/GOV-08.json +++ b/docs/api/controls/GOV-08.json @@ -3,7 +3,7 @@ "title": "Defining Business Context & Mission", "family": "GOV", "description": "Mechanisms exist to define the context of its business model and document the organization's mission.", - "scf_question": "Does the organization define the context of its business model and document the mission of the organization?", + "scf_question": "Does the organization define the context of its business model and document its mission?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ The context of the entity's business model and its mission are documented.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ The context of the entity's business model and its mission are documented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91,9 +91,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2-POF1", @@ -161,9 +162,6 @@ "GV.OV-01", "GV.SC-03" ], - "general-scf-dpmp-2025": [ - "11.1" - ], "general-shared-assessments-sig-2025": [ "B.1" ], @@ -177,20 +175,27 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(4)" + "3.2.1.4", + "3.2.2.5" ], "emea-eu-nis2-annex-2024": [ "1.1.1(b)" ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], "emea-sau-ecc-1-2018": [ "1-1-1" ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(a)" + ], "americas-can-osfi-b13-2022": [ "1.2", "2.1.1" diff --git a/docs/api/controls/GOV-09.json b/docs/api/controls/GOV-09.json index 61fe2d31..63fb66bb 100644 --- a/docs/api/controls/GOV-09.json +++ b/docs/api/controls/GOV-09.json @@ -3,7 +3,7 @@ "title": "Define Control Objectives", "family": "GOV", "description": "Mechanisms exist to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", - "scf_question": "Does the organization establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system?", + "scf_question": "Does the organization establish control objectives as the basis for the selection, implementation and management of its internal security, compliance and resilience control system?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -20,7 +20,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -90,10 +90,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF1", @@ -171,25 +171,23 @@ "314.3(b)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.2.1(5)(c)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "emea-eu-nis2-annex-2024": [ "1.1.1(c)" ], "emea-deu-c5-2020": [ "OIS-01", - "OIS-02" + "OIS-02", + "DLL-01-BP1" ], - "emea-sau-cscc-1-2019": [ - "1-1" + "apac-aus-ps-cps-230-2023": [ + "29" ], "apac-ind-sebi-2024": [ "GV.OC.S1", diff --git a/docs/api/controls/GOV-10.1.json b/docs/api/controls/GOV-10.1.json new file mode 100644 index 00000000..980670c4 --- /dev/null +++ b/docs/api/controls/GOV-10.1.json @@ -0,0 +1,100 @@ +{ + "control_id": "GOV-10.1", + "title": "Data Catalog", + "family": "GOV", + "description": "Mechanisms exist to identify and catalog the organization's data holdings in a structured format to document each significant data asset.", + "scf_question": "Does the organization identify and catalog its data holdings in a structured format to document each significant data asset?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and catalog the organization's data holdings in a structured format to document each significant data asset.", + "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Spreadsheet-based data inventory\n∙ Manual data catalog template", + "small": "∙ Spreadsheet data catalog with sensitivity classifications\n∙ Data classification register for significant data assets", + "medium": "∙ Data catalog platform (e.g., Collibra, Alation)\n∙ Structured data inventory with metadata\n∙ Microsoft Purview basic tier (https://microsoft.com)", + "large": "∙ Enterprise data catalog (e.g., Collibra (https://collibra.com), Alation (https://alation.com))\n∙ Data lineage tracking\n∙ Microsoft Purview (https://microsoft.com)", + "enterprise": "∙ Enterprise data catalog with automated discovery\n∙ Microsoft Purview or equivalent (https://microsoft.com)\n∙ Automated data lineage and classification at scale" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/GOV-10.json b/docs/api/controls/GOV-10.json index 0d23afb9..45af846d 100644 --- a/docs/api/controls/GOV-10.json +++ b/docs/api/controls/GOV-10.json @@ -2,8 +2,8 @@ "control_id": "GOV-10", "title": "Data Governance", "family": "GOV", - "description": "Mechanisms exist to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization facilitate data governance to oversee its policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive and/or regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization facilitate data governance to oversee its policies, standards and procedures so that sensitive and/or regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Administrative processes require all employees and contractors to apply cybersecurity and data protection principles in their daily work (e.g., policies & standards).\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91,9 +91,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2-POF1" @@ -140,9 +141,6 @@ "general-pci-dss-4-0-1": [ "A3.2.5" ], - "general-scf-dpmp-2025": [ - "5.9" - ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -165,12 +163,14 @@ "PM-23", "PM-24" ], - "apac-chn-pipl-2021": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.2" + ], + "apac-nzl-ism-3-9": [ + "20.2.16.C.03" + ], + "americas-bmu-mba-coc-2020": [ + "5.3-BP2" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-11.json b/docs/api/controls/GOV-11.json index 45584eb9..1f656361 100644 --- a/docs/api/controls/GOV-11.json +++ b/docs/api/controls/GOV-11.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to monitor mission/business-critical Technology Assets, Applications and/or Services (TAAS) to ensure those resources are being used consistent with their intended purpose.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to monitor mission/business-critical Technology Assets, Applications and/or Services (TAAS) to ensure those resources are being used consistent with their intended purpose.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,9 +83,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-42001-2023": [ "6.2" diff --git a/docs/api/controls/GOV-12.json b/docs/api/controls/GOV-12.json index a1f55d67..91aeda67 100644 --- a/docs/api/controls/GOV-12.json +++ b/docs/api/controls/GOV-12.json @@ -2,8 +2,8 @@ "control_id": "GOV-12", "title": "Forced Technology Transfer (FTT)", "family": "GOV", - "description": "Mechanisms exist to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", - "scf_question": "Does the organization avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices?", + "description": "Mechanisms exist to avoid and/or constrain the forced exfiltration of sensitive and/or regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", + "scf_question": "Does the organization avoid and/or constrain the forced exfiltration of sensitive and/or regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,38 +82,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "apac-chn-cybersecurity-law-2017": [ "Article 28" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" - ], - "apac-chn-pipl-2021": [ - "38", - "38(4)", - "40" + "Article 28" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-13.json b/docs/api/controls/GOV-13.json index 4c6e0754..ffe988a1 100644 --- a/docs/api/controls/GOV-13.json +++ b/docs/api/controls/GOV-13.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to constrain the host government's ability to leverage the organization's Technology Assets, Applications and/or Services (TAAS) for economic or political espionage and/or cyberwarfare activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to constrain the host government's ability to leverage the organization's Technology Assets, Applications and/or Services (TAAS) for economic or political espionage and/or cyberwarfare activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,44 +82,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "apac-chn-cybersecurity-law-2017": [ "Article 28" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "Article 27" ], "apac-chn-pipl-2021": [ - "11", - "12", - "38(4)", - "40", - "47(5)", - "60", - "63(3)", - "63(4)", - "64" + "Article 38" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-14.json b/docs/api/controls/GOV-14.json index 129e6097..efeefbbd 100644 --- a/docs/api/controls/GOV-14.json +++ b/docs/api/controls/GOV-14.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to incorporate security, compliance and resilience principles into Business As Usual (BAU) practices through executive leadership involvement.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to incorporate security, compliance and resilience principles into Business As Usual (BAU) practices through executive leadership involvement.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81,10 +81,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.1-POF1", @@ -133,8 +133,17 @@ "usa-federal-law-ftc-act": [ "45(a)(1)" ], - "apac-aus-ps-cps-230-2023": [ - "24" + "emea-deu-c5-2020": [ + "SA-01-BP4" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], + "emea-sau-ecc-1-2018": [ + "1-9-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2001" ], "apac-ind-sebi-2024": [ "GV.RR.S1" @@ -143,9 +152,19 @@ "4.5.2.1", "7.2.1.8" ], + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.6", + "4.1.2" + ], "americas-can-osfi-b13-2022": [ "1.1.1", "3.2.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-15.1.json b/docs/api/controls/GOV-15.1.json index 339393e7..09b162f3 100644 --- a/docs/api/controls/GOV-15.1.json +++ b/docs/api/controls/GOV-15.1.json @@ -2,8 +2,8 @@ "control_id": "GOV-15.1", "title": "Select Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -94,10 +94,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" @@ -129,9 +130,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "1.2.1", @@ -161,6 +162,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -171,10 +175,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.l" @@ -198,19 +202,22 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.4(22)", - "3.3.4(23)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -232,53 +239,37 @@ "Article 21.2(j)" ], "emea-deu-bsrit-2017": [ + "3.4", + "3.6", "5.1" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1" + "emea-deu-c5-2020": [ + "DLL-01-BP1" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.3", - "Article 28.1(a)", - "Article 28.1(b)", - "Article 28.1(c)", - "Article 28.2", - "Article 28.3", - "Article 37" - ], "emea-esp-decree-311-2022": [ - "28.1(a)", - "28.1(b)", - "28.1(c)", - "28.2", - "28.3", - "3.3", - "37" + "Article 28(2)" ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5", - "A6" + "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1634" ], - "apac-aus-ps-cps-230-2023": [ - "29" + "apac-aus-ps-cps-234-2019": [ + "21", + "21(a)", + "21(b)", + "21(c)", + "21(d)" ], "apac-jpn-ismap": [ "4.4.4.1" @@ -290,6 +281,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" diff --git a/docs/api/controls/GOV-15.2.json b/docs/api/controls/GOV-15.2.json index 90b26b3a..ea7bea55 100644 --- a/docs/api/controls/GOV-15.2.json +++ b/docs/api/controls/GOV-15.2.json @@ -2,8 +2,8 @@ "control_id": "GOV-15.2", "title": "Implement Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -109,10 +109,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" @@ -146,9 +147,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1", @@ -163,6 +164,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -173,14 +177,14 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -198,6 +202,10 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], @@ -205,13 +213,13 @@ "Article 17.1(e)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -233,42 +241,22 @@ "Article 21.2(j)" ], "emea-deu-bsrit-2017": [ + "3.4", "5.2" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.3", - "11.5", - "11.6" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.3", - "Article 37" - ], - "emea-esp-decree-311-2022": [ - "3.3", - "37" - ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5", - "A6", "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1635" ], "apac-nzl-ism-3-9": [ @@ -278,6 +266,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" diff --git a/docs/api/controls/GOV-15.3.json b/docs/api/controls/GOV-15.3.json index 8db793c8..245fa046 100644 --- a/docs/api/controls/GOV-15.3.json +++ b/docs/api/controls/GOV-15.3.json @@ -2,8 +2,8 @@ "control_id": "GOV-15.3", "title": "Assess Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", - "scf_question": "Does the organization compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended?", + "description": "Mechanisms exist to compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", + "scf_question": "Does the organization compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108,10 +108,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC4.2-POF1" @@ -136,9 +137,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1" @@ -155,6 +156,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -165,10 +169,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -184,52 +188,28 @@ "899-bb.2(b)(ii)(B)", "899-bb.2(b)(ii)(B)(4)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" - ], "emea-eu-dora-2023": [ "Article 7(a)", "Article 7(b)", "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1", - "11.2" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-gbr-cap-1850-2020": [ - "A5", - "A6", - "B4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1636" ], "americas-can-osfi-b13-2022": [ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" diff --git a/docs/api/controls/GOV-15.4.json b/docs/api/controls/GOV-15.4.json index 9b0d8097..91574704 100644 --- a/docs/api/controls/GOV-15.4.json +++ b/docs/api/controls/GOV-15.4.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to obtain authorization for the production use of each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to obtain authorization for the production use of each Technology Asset, Application and/or Service (TAAS) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108,9 +108,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-22301-2019": [ "8.1" @@ -128,9 +129,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1" @@ -151,10 +152,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -178,21 +179,13 @@ "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-gbr-cap-1850-2020": [ - "A5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0027" ], "apac-nzl-ism-3-9": [ @@ -203,6 +196,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" diff --git a/docs/api/controls/GOV-15.5.json b/docs/api/controls/GOV-15.5.json index a69a9866..f41bc00c 100644 --- a/docs/api/controls/GOV-15.5.json +++ b/docs/api/controls/GOV-15.5.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to monitor Technology Assets, Applications, Services and/or Data (TAASD) under their control on an ongoing basis for applicable threats and risks, as well as to ensure security, compliance and resilience controls are operating as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to monitor Technology Assets, Applications, Services and/or Data (TAASD) under their control on an ongoing basis for applicable threats and risks, as well as to ensure security, compliance and resilience controls are operating as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108,10 +108,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-27001-2022": [ "9.2.2" @@ -132,9 +132,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "usa-federal-dow-dfars-252-204-7012": [ "252.204-7012(b)" @@ -149,10 +149,10 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -177,31 +177,15 @@ "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.7", - "11.8" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-gbr-cap-1850-2020": [ - "A5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1526" ], - "apac-aus-ps-cps-230-2023": [ - "30" - ], "apac-nzl-ism-3-9": [ "23.2.18.C.01" ], @@ -209,6 +193,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" diff --git a/docs/api/controls/GOV-15.json b/docs/api/controls/GOV-15.json index 7fa9caff..516697ea 100644 --- a/docs/api/controls/GOV-15.json +++ b/docs/api/controls/GOV-15.json @@ -2,8 +2,8 @@ "control_id": "GOV-15", "title": "Operationalizing Security, Compliance & Resilience Capabilities", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -112,10 +112,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "errata": "- wordsmithed", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF1", @@ -188,14 +189,13 @@ ], "general-nist-800-171-r3": [ "03.15.01.a", + "03.16.01", "03.17.01.a" ], "general-nist-800-171a-r3": [ - "A.03.16.01" - ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "A.03.15.01.a[03]", + "A.03.16.01", + "A.03.17.01.a[01]" ], "general-swift-cscf-2025": [ "2.4" @@ -229,6 +229,11 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.30" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)", + "101.625(d)(5)", + "101.650(c)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -243,12 +248,12 @@ "155.260(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.l" @@ -280,6 +285,10 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], @@ -287,14 +296,14 @@ "Article 17.2" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.4(22)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7", @@ -322,70 +331,64 @@ "6.7.1" ], "emea-deu-bsrit-2017": [ + "3.4", + "3.6", "5.1" ], - "emea-qat-pdppl-2020": [ - "8.3" + "emea-deu-c5-2020": [ + "UP-01-BP2" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1", + "2-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 5(a)", - "Article 5(b)", - "Article 5(c)", - "Article 5(d)", - "Article 5(e)", - "Article 5(f)", - "Article 5(g)", - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5", - "Article 28.1", - "Article 37" + "emea-sau-ecc-1-2018": [ + "1-3-2", + "1-9-2", + "1-10-2", + "2-1-2", + "2-1-4", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-2", + "2-14-2", + "2-15-2", + "3-1-2", + "4-2-2", + "5-1-2" ], "emea-esp-decree-311-2022": [ - "28.1", - "37", - "5", - "5(a)", - "5(b)", - "5(c)", - "5(d)", - "5(e)", - "5(f)", - "5(g)", - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" + "Article 13(2)(d)", + "Article 15(1)" ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5" + "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1633", "ISM-1634", "ISM-1635", "ISM-1636" ], "apac-aus-ps-cps-230-2023": [ - "29" + "16(c)" + ], + "apac-aus-ps-cps-234-2019": [ + "21" ], "apac-ind-sebi-2024": [ "GV.RM.S2" @@ -394,7 +397,10 @@ "4.4.4.1", "4.5.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP16", "HHSP28", @@ -410,13 +416,24 @@ "3.2.10.C.04", "3.4.11.C.01" ], + "apac-sgp-mas-trm-2021": [ + "4.1.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.3-BP2", + "5.11-BP4" + ], "americas-can-osfi-b13-2022": [ "1.1.1", "2.1.1", "3.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", + "03.16.01", "03.17.01.A" ] } diff --git a/docs/api/controls/GOV-16.1.json b/docs/api/controls/GOV-16.1.json index acdb335c..039e88e7 100644 --- a/docs/api/controls/GOV-16.1.json +++ b/docs/api/controls/GOV-16.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a risk as a material risk.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a risk as a material risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -54,9 +54,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-csa-iot-2": [ "RSM-01" @@ -88,6 +89,9 @@ "500.4(b)(5)", "500.9(b)(1)", "500.9(b)(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-16.2.json b/docs/api/controls/GOV-16.2.json index f26a56fc..0f89321e 100644 --- a/docs/api/controls/GOV-16.2.json +++ b/docs/api/controls/GOV-16.2.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a threat as a material threat.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a threat as a material threat.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -54,9 +54,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-csa-iot-2": [ "RSM-01" diff --git a/docs/api/controls/GOV-16.json b/docs/api/controls/GOV-16.json index ba5febad..5550c9cb 100644 --- a/docs/api/controls/GOV-16.json +++ b/docs/api/controls/GOV-16.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define materiality threshold criteria capable of designating an incident as material.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define materiality threshold criteria capable of designating an incident as material.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -57,9 +57,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC3.1-POF6" @@ -90,6 +91,12 @@ "500.4(b)(5)", "500.9(b)(1)", "500.9(b)(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-17.json b/docs/api/controls/GOV-17.json index 98a699ec..06c72de5 100644 --- a/docs/api/controls/GOV-17.json +++ b/docs/api/controls/GOV-17.json @@ -3,7 +3,7 @@ "title": "Security, Compliance & Resilience Status Reporting", "family": "GOV", "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.", - "scf_question": "Does the organization submit status reporting of the organization's security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required?", + "scf_question": "Does the organization submit status reporting of its security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63,10 +63,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC3.1-POF10", @@ -80,6 +80,17 @@ "52.204-25(d)(2)(ii)", "52.204-25(d)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(12)", + "101.625(d)(13)", + "101.630(d)", + "101.630(e)(2)", + "101.630(e)(2)(ii)", + "101.630(e)(3)", + "101.630(e)(4)", + "101.630(f)(3)", + "101.630(f)(5)" + ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(b)", "17 CFR 229.106(d)" @@ -143,18 +154,56 @@ "usa-state-va-cdpa-2023": [ "59.1-580.C" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(23)", + "Article 19(8)", + "Article 20(6)" + ], "emea-eu-nis2-annex-2024": [ "1.2.3" ], - "apac-aus-ism-2024-june": [ + "emea-eu-psd2-2015": [ + "96(6)" + ], + "emea-deu-fdpa-2017": [ + "3.5.79(3)" + ], + "emea-grc-pirppd-1997": [ + "B.7.7", + "B.8.2" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(3)" + ], + "emea-ken-pda-2019": [ + "IV.31(5)" + ], + "emea-nga-dpr-2019": [ + "4.1(6)", + "4.1(7)" + ], + "apac-aus-ism-2026-march": [ "ISM-1587" ], + "apac-aus-ps-cps-230-2023": [ + "59", + "59(a)", + "59(b)" + ], "apac-chn-cybersecurity-law-2017": [ "Article 38", "Article 54(1)" ], + "apac-jpn-appi-2020": [ + "IV.5.53(2)" + ], "apac-jpn-ismap": [ "4.5.3.1" + ], + "apac-mys-bnm-rmit-2025": [ + "16.1", + "17.2", + "17.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-18.json b/docs/api/controls/GOV-18.json index 1370f7e3..d10d7171 100644 --- a/docs/api/controls/GOV-18.json +++ b/docs/api/controls/GOV-18.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Unstructured review of the cybersecurity and/or data privacy program is performed on an annual basis.\n▪ Administrative processes require all employees and contractors to apply cybersecurity and data protection principles in their daily work (e.g., policies & standards).", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to govern a Quality Management System (QMS) to ensure security, compliance and resilience processes conform with applicable statutory, regulatory and/or contractual obligations.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to govern a Quality Management System (QMS) to ensure security, compliance and resilience processes conform with applicable statutory, regulatory and/or contractual obligations.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91,10 +91,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-cobit-2019": [ "APO11.01", @@ -111,6 +111,10 @@ "emea-eu-ai-act-2024": [ "Article 16(c)", "Article 17.1" + ], + "apac-sgp-mas-trm-2021": [ + "5.8.1", + "5.8.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/GOV-19.1.json b/docs/api/controls/GOV-19.1.json index fa1f69e8..3542a59f 100644 --- a/docs/api/controls/GOV-19.1.json +++ b/docs/api/controls/GOV-19.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assurance Levels (AL) for assessment activities to standardize the following assurance attributes:\n(1) Depth that addresses the rigor and level of detail of the assessment; and\n(2) Coverage that addresses the scope and breadth of the assessment.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assurance Levels (AL) for assessment activities to standardize the following assurance attributes:\n(1) Depth that addresses the rigor and level of detail of the assessment; and\n(2) Coverage that addresses the scope and breadth of the assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72,8 +72,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/GOV-19.2.json b/docs/api/controls/GOV-19.2.json index 8c92db75..8af4a19f 100644 --- a/docs/api/controls/GOV-19.2.json +++ b/docs/api/controls/GOV-19.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assessment Objectives (AO) to assess the implementation of requirements, when available.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assessment Objectives (AO) to assess the implementation of requirements, when available.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72,9 +72,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "usa-federal-dow-cert-rmm-1-2": [ "ADM:GG2.GP9", diff --git a/docs/api/controls/GOV-19.3.json b/docs/api/controls/GOV-19.3.json new file mode 100644 index 00000000..4faae825 --- /dev/null +++ b/docs/api/controls/GOV-19.3.json @@ -0,0 +1,121 @@ +{ + "control_id": "GOV-19.3", + "title": "Security, Compliance & Resilince Outsourcing Limitations", + "family": "GOV", + "description": "Mechanisms exist to ensure organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations.", + "scf_question": "Does the organization ensure third-parties involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to ensure organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Vendor due diligence checklist\n∙ Third-party security questionnaire (e.g., CAIQ, SIG)", + "small": "∙ Vendor security questionnaire (CAIQ or SIG)\n∙ Third-party risk assessment prior to outsourcing", + "medium": "∙ Third-party risk management program\n∙ Vendor security assessments with contractual security obligations\n∙ Contract security requirements for outsourced functions", + "large": "∙ Third-party risk management (TPRM) program\n∙ Vendor SOC 2 and ISO 27001 certification requirements\n∙ Contractual security and compliance obligations", + "enterprise": "∙ Enterprise TPRM program with automated vendor risk assessment\n∙ Third-party risk ratings (e.g., BitSight, SecurityScorecard)\n∙ Contractual oversight and audit rights for outsourced functions" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-14", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "emea-sau-sama-csf-1-2017": [ + "3.4.2.3", + "3.4.2.3.a", + "3.4.2.3.b", + "3.4.2.3.c" + ], + "emea-esp-decree-311-2022": [ + "Article 14(1)", + "Article 16(2)" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/GOV-19.json b/docs/api/controls/GOV-19.json index 919e5371..f4ea2024 100644 --- a/docs/api/controls/GOV-19.json +++ b/docs/api/controls/GOV-19.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define the basis for confidence that implemented practices conform to applicable security, compliance and resilience controls, where the control implementation performs as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define the basis for confidence that implemented practices conform to applicable security, compliance and resilience controls, where the control implementation performs as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -73,10 +73,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "emea-gbr-caf-4-0": [ "A2.c" diff --git a/docs/api/controls/GOV-20.1.json b/docs/api/controls/GOV-20.1.json index d78a6b76..d334f64a 100644 --- a/docs/api/controls/GOV-20.1.json +++ b/docs/api/controls/GOV-20.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provision a Virtual Data Room (VDR), or similar technology, to securely share documentation among stakeholders to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provision a Virtual Data Room (VDR), or similar technology, to securely share documentation among stakeholders to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75,8 +75,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/GOV-20.json b/docs/api/controls/GOV-20.json index e3ec9ef9..909a241b 100644 --- a/docs/api/controls/GOV-20.json +++ b/docs/api/controls/GOV-20.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72,8 +72,9 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/GOV-21.json b/docs/api/controls/GOV-21.json new file mode 100644 index 00000000..51463e8f --- /dev/null +++ b/docs/api/controls/GOV-21.json @@ -0,0 +1,100 @@ +{ + "control_id": "GOV-21", + "title": "High Value Assets (HVAs)", + "family": "GOV", + "description": "Mechanisms exist to identify and catalog the organization's High Value Assets (HVAs) (e.g., crown jewels), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA;\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a HVA based on business process criticality or dependency relationships;\n(3) Location of HVA Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements.", + "scf_question": "Does the organization identify and catalog its High Value Assets (HVAs) (e.g., crown jewels), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA;\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a HVA based on business process criticality or dependency relationships;\n(3) Location of HVA Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and catalog the organization's High Value Assets (HVAs), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA (e.g., \"crown jewel\" IP);\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a \"crown jewel,\" based on business process criticality or dependency relationships;\n(3) Location of \"crown jewel\" Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Manual identification of most critical business assets\n∙ HVA asset register (spreadsheet)", + "small": "∙ HVA asset register with basic protection requirements\n∙ Critical asset identification by business process dependency", + "medium": "∙ HVA identification process\n∙ Critical asset register with minimum protection requirements\n∙ Risk-based prioritization of HVA assets", + "large": "∙ Formal HVA identification program\n∙ Critical asset protection requirements matrix\n∙ Regular HVA review cycle", + "enterprise": "∙ Enterprise HVA program with board-level visibility\n∙ Integrated critical asset protection within GRC platform\n∙ Threat modeling centered on HVA assets" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-GV-1" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2005" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/HRS-01.1.json b/docs/api/controls/HRS-01.1.json index 83c47497..6592bd27 100644 --- a/docs/api/controls/HRS-01.1.json +++ b/docs/api/controls/HRS-01.1.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -119,6 +120,9 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10(j)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(7)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -151,6 +155,14 @@ "1-8-1", "1-8-2" ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-18", + "VII.B.TPC-71" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e.1", + "3.3.1.3.e.2" + ], "emea-uae-niaf-2023": [ "3.2.3" ], diff --git a/docs/api/controls/HRS-01.json b/docs/api/controls/HRS-01.json index 6b22f25f..e8ee36a4 100644 --- a/docs/api/controls/HRS-01.json +++ b/docs/api/controls/HRS-01.json @@ -117,7 +117,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -272,7 +273,18 @@ "A.03.01.01.ODP[01]", "A.03.01.01.ODP[02]", "A.03.01.01.ODP[03]", - "A.03.01.01.ODP[04]" + "A.03.01.01.ODP[04]", + "A.03.01.01.g.02", + "A.03.15.03.a", + "A.03.15.03.d[01]" + ], + "general-nist-800-172-r3": [ + "03.09.03E", + "03.09.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.03E.a", + "A.03.09.04E.ODP[01]" ], "general-nist-800-218": [ "PO.2.1" @@ -298,9 +310,6 @@ "12.2.1", "12.7.1" ], - "general-scf-dpmp-2025": [ - "7.9" - ], "general-swift-cscf-2025": [ "5.1", "5.3A" @@ -380,13 +389,13 @@ "314.4(e)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)", - "164.530(e)(2)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)", + "§ 164.530(e)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "2.C.3-1", @@ -417,7 +426,7 @@ "PS-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.2(15)" + "3.2.1.3" ], "emea-eu-nis2-2022": [ "Article 21.2(i)" @@ -427,50 +436,42 @@ "10.1.3", "10.2.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" + "emea-deu-c5-2020": [ + "HR-02", + "KOS-08-DOAR" ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "19.1" + "emea-grc-pirppd-1997": [ + "B.10.2" ], "emea-sau-cscc-1-2019": [ - "1-5", - "2-5" + "1-5-1" ], "emea-sau-cgiot-2024": [ "1-3-2", "1-8-1" ], "emea-sau-ecc-1-2018": [ + "1-4-2", "1-9-1", - "1-9-6", - "2-6-4" + "1-9-2", + "1-9-3", + "1-9-4", + "1-9-6" ], "emea-sau-otcc-1-2022": [ - "1-7", - "1-7-2", - "1-8" + "1-7-1", + "1-7-2" ], "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-71" + "VII.B.TPC-26" ], "emea-sau-sama-csf-1-2017": [ - "3.3.1" - ], - "emea-zaf-popia-2013": [ - "19", - "20" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 15.1" + "3.3.1", + "3.3.1.1", + "3.3.1.3" ], "emea-esp-decree-311-2022": [ - "15.1" + "Article 12(6)(c)" ], "emea-uae-niaf-2023": [ "3.2.3" @@ -509,8 +510,9 @@ "GV.RR.S6", "RS.CO.S1" ], - "apac-jpn-ppi-2020": [ - "21" + "apac-jpn-appi-2020": [ + "IV.1.21", + "IV.1.22" ], "apac-jpn-ismap": [ "4.5.2.2", @@ -519,7 +521,7 @@ "7.1", "7.1.1.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HML02" ], "apac-nzl-hisf-suppliers-2023": [ @@ -533,14 +535,10 @@ "15.1.7.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.5.1", - "3.5.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.13" + "3.5.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.5" + "apac-kor-pipa-2011": [ + "III.2.28(1)" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", diff --git a/docs/api/controls/HRS-02.1.json b/docs/api/controls/HRS-02.1.json index 12d13092..c7a68adb 100644 --- a/docs/api/controls/HRS-02.1.json +++ b/docs/api/controls/HRS-02.1.json @@ -2,8 +2,8 @@ "control_id": "HRS-02.1", "title": "Users With Elevated Privileges", "family": "HRS", - "description": "Mechanisms exist to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question.", - "scf_question": "Does the organization ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question?", + "description": "Mechanisms exist to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive and/or regulated data is cleared and regularly trained to handle the information in question.", + "scf_question": "Does the organization ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive and/or regulated data is cleared and regularly trained to handle the information in question?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -22,7 +22,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates risk for individuals requiring elevated privileges or access to sensitive/regulated data.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -108,8 +109,9 @@ "general-nist-800-171-r3": [ "03.01.02" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.02[01]", + "A.03.01.02[02]" ], "general-pci-dss-4-0-1": [ "12.7", @@ -142,10 +144,6 @@ "emea-eu-nis2-annex-2024": [ "10.1.2(b)" ], - "apac-sgp-mas-trm-2021": [ - "3.5.2", - "6.1.5" - ], "americas-can-itsp-10-171-2025": [ "03.01.02" ] diff --git a/docs/api/controls/HRS-02.2.json b/docs/api/controls/HRS-02.2.json index 271c6a7f..e8951a95 100644 --- a/docs/api/controls/HRS-02.2.json +++ b/docs/api/controls/HRS-02.2.json @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { diff --git a/docs/api/controls/HRS-02.json b/docs/api/controls/HRS-02.json index d2a98f01..7b98538c 100644 --- a/docs/api/controls/HRS-02.json +++ b/docs/api/controls/HRS-02.json @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -166,10 +167,19 @@ "03.01.01.d.02", "03.01.02", "03.09.01.a", - "03.09.01.b" - ], - "general-nist-800-172": [ - "3.9.1e" + "03.09.01.b", + "03.15.03.b" + ], + "general-nist-800-171a-r3": [ + "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.09.01.a", + "A.03.09.01.b", + "A.03.15.03.b" ], "general-nist-csf-2-0": [ "GV.RR-02", @@ -220,17 +230,20 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PS-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(a)" + ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "PS-2" @@ -256,9 +269,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PS-02" ], - "emea-eu-eba-ict-srm-2025": [ - "3.3.2(15)" - ], "emea-eu-gdpr-2016": [ "Article 32.4" ], @@ -266,8 +276,8 @@ "10.1.2(b)", "10.1.3" ], - "emea-isr-cmo-1-0": [ - "19.1" + "emea-deu-c5-2020": [ + "HR-01-DOAR" ], "emea-sau-cscc-1-2019": [ "1-5-1-2" @@ -275,17 +285,11 @@ "emea-sau-cgiot-2024": [ "1-8-1" ], - "emea-sau-ecc-1-2018": [ - "1-9-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2" + "emea-sau-otcc-1-2022": [ + "1-2-1-2" ], "emea-esp-decree-311-2022": [ - "13.2" + "Article 16(3)" ], "apac-ind-sebi-2024": [ "DE.DP.S1", @@ -298,10 +302,12 @@ ], "apac-nzl-ism-3-9": [ "9.2.10.C.01", - "9.2.10.C.02", "9.2.11.C.01", "9.2.11.C.02" ], + "apac-sgp-mas-trm-2021": [ + "3.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01", "03.01.01.C.02", @@ -309,7 +315,8 @@ "03.01.01.D.02", "03.01.02", "03.09.01.A", - "03.09.01.B" + "03.09.01.B", + "03.15.03.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-03.1.json b/docs/api/controls/HRS-03.1.json index 32265f2b..9ec9382f 100644 --- a/docs/api/controls/HRS-03.1.json +++ b/docs/api/controls/HRS-03.1.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to communicate with users about their roles and responsibilities to maintain a safe and secure working environment.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -150,6 +151,10 @@ "03.01.22.a", "03.15.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.15.03.b" + ], "general-nist-csf-2-0": [ "GV.RR-04" ], @@ -228,6 +233,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(4)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 R2", "CIP-004-7 2.2" @@ -243,13 +251,8 @@ "10.1.2(a)", "10.1.2(c)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.1", - "Article 15.1" - ], - "emea-esp-decree-311-2022": [ - "13.1", - "15.1" + "emea-sau-ecc-1-2018": [ + "1-9-4-1" ], "emea-gbr-def-stan-05-138-2024": [ "2600", @@ -267,7 +270,7 @@ "2600", "2603" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0824" ], "apac-ind-sebi-2024": [ @@ -284,6 +287,9 @@ "7.2.1.4", "8.1.3.1" ], + "americas-arg-ppd-2018": [ + "B.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.15.03.B" diff --git a/docs/api/controls/HRS-03.2.json b/docs/api/controls/HRS-03.2.json index d48e8c7c..9d93e5c7 100644 --- a/docs/api/controls/HRS-03.2.json +++ b/docs/api/controls/HRS-03.2.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Formal roles and responsibilities for cybersecurity and/or data protection are not consistent and/or standardized.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that all security-related positions are staffed by qualified individuals who have the necessary skill set.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that all security-related positions are staffed by qualified individuals who have the necessary skill set. ", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -208,6 +209,9 @@ "general-nist-800-171-r3": [ "03.07.06.d" ], + "general-nist-800-171a-r3": [ + "A.03.07.06.d[01]" + ], "general-nist-800-218": [ "PO.2" ], @@ -264,6 +268,21 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PS-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(e)", + "101.625(e)(1)", + "101.625(e)(2)", + "101.625(e)(3)", + "101.625(e)(4)", + "101.625(e)(5)", + "101.625(e)(6)", + "101.625(e)(7)", + "101.625(e)(8)", + "101.625(e)(9)", + "101.625(e)(10)", + "101.625(e)(11)", + "101.625(e)(12)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(2)" ], @@ -288,23 +307,14 @@ "usa-state-tx-txramp-2-0-level-2": [ "PS-02" ], - "emea-sau-ecc-1-2018": [ - "1-9-2" + "emea-isr-ppl-5741-2025": [ + "s.17B3" ], "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 15.1", - "Article 16.1", - "Article 16.2", - "Article 16.3" + "VII.B.TPC-26" ], "emea-esp-decree-311-2022": [ - "15.1", - "16.1", - "16.2", - "16.3" + "Article 16(2)" ], "emea-gbr-caf-4-0": [ "C1.e" @@ -317,6 +327,9 @@ "14.2.1.8", "14.2.1.11" ], + "apac-mys-bnm-rmit-2025": [ + "9.4" + ], "apac-nzl-ism-3-9": [ "5.1.14.C.01" ], @@ -324,10 +337,6 @@ "3.5.1", "6.1.5" ], - "amaericas-can-osfi-self-assessment": [ - "1.5", - "1.7" - ], "americas-can-itsp-10-171-2025": [ "03.07.06.D" ] diff --git a/docs/api/controls/HRS-03.json b/docs/api/controls/HRS-03.json index 30ac3e50..5f57cbdd 100644 --- a/docs/api/controls/HRS-03.json +++ b/docs/api/controls/HRS-03.json @@ -28,7 +28,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Formal roles and responsibilities for cybersecurity and/or data protection are not consistent and/or standardized.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define cybersecurity roles & responsibilities for all personnel.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define cybersecurity roles & responsibilities for all personnel. ", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -97,7 +97,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -252,18 +253,40 @@ ], "general-nist-800-171-r3": [ "03.01.22.a", + "03.02.02.a.01", "03.06.04.a", "03.06.05.d", "03.07.06.a", + "03.07.06.d", "03.08.02", "03.15.03.b", "03.16.03.b" ], "general-nist-800-171a-r3": [ - "A.03.06.05.d" - ], - "general-nist-800-172": [ - "3.9.1e" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.05.d", + "A.03.07.06.a", + "A.03.07.06.d[02]", + "A.03.08.02", + "A.03.15.03.b", + "A.03.16.03.b" + ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.01.11E", + "03.14.17E", + "03.14.18E", + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.08E.ODP[02]", + "A.03.01.11E.ODP[01]", + "A.03.14.17E.ODP[01]", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[01]", + "A.03.17.03E.ODP[03]" ], "general-nist-800-218": [ "PO.2", @@ -449,19 +472,23 @@ "PM-13", "PS-09" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)", + "101.625(a)" + ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "PS-9" @@ -521,8 +548,9 @@ "PS-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(12)", - "3.3.2(15)" + "3.2.1.2", + "3.3.1.12", + "3.4.1.29" ], "emea-eu-dora-2023": [ "Article 5.2(c)" @@ -543,63 +571,53 @@ "10.1.1" ], "emea-deu-c5-2020": [ - "PSS-08" + "UP-01-BP5", + "OIS-03-BP1", + "OIS-03-BP2", + "OIS-03-BP3", + "SA-01-BP3" + ], + "emea-hun-act-cxii-2011": [ + "II.18.24(2)" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B2" ], - "emea-isr-cmo-1-0": [ - "4.13", - "18.10" + "emea-ita-pdpc-2018": [ + "Article 2-o(1)", + "Article 2-o(2)" ], "emea-sau-cgiot-2024": [ "1-3-1", "1-3-2", "1-8-1" ], + "emea-sau-ecc-1-2018": [ + "1-4-1", + "1-4-2", + "1-9-1" + ], "emea-sau-otcc-1-2022": [ - "1-2", "1-2-1", - "1-2-1-1" + "1-2-1-2" ], "emea-sau-pdpl-2023": [ "Article 30.2" ], "emea-sau-sacs-002-2022": [ - "TPC-26" + "VII.B.TPC-26" ], "emea-sau-sama-csf-1-2017": [ - "3.1.4" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.1", - "Article 11.2", - "Article 11.3", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.2(d)", - "Article 13.3", - "Article 13.4", - "Article 13.5" + "3.1.4.6", + "3.1.4.6.a", + "3.3.1.3.a" ], "emea-esp-decree-311-2022": [ - "11.1", - "11.2", - "11.3", - "13.1", - "13.2", - "13.2(a)", - "13.2(b)", - "13.2(c)", - "13.2(d)", - "13.3", - "13.4", - "13.5" - ], - "emea-esp-ccn-stic-825-2023": [ - "6.4 [ORG.4]", - "8.2.1 [MP.PER.1]", - "8.2.2 [MP.PER.2]" + "Article 12(1)(c)", + "Article 13(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "emea-gbr-def-stan-05-138-2024": [ "1102", @@ -622,7 +640,7 @@ "2321", "3102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0717", "ISM-0720", "ISM-0724", @@ -632,13 +650,12 @@ "ISM-0732", "ISM-0733", "ISM-0734", - "ISM-0735" + "ISM-0735", + "ISM-2035", + "ISM-2036" ], "apac-aus-ps-cps-234-2019": [ - "14" - ], - "apac-chn-data-security-law-2021": [ - "27" + "19" ], "apac-ind-dpdpa-2023": [ "6(9)", @@ -651,9 +668,6 @@ "PR.AT.S5", "RS.CO.S1" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "4.5.2.2", "6.1.1", @@ -666,15 +680,12 @@ "6.1.1.7", "6.1.1.13.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP02", "HHSP23", "HML02", "HML23" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS01" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP02", "HSUP21" @@ -713,16 +724,27 @@ "3.3.14.C.03", "3.3.15.C.01", "3.4.10.C.01", - "3.4.10.C.02" + "3.4.10.C.02", + "17.9.35.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "3.5.1" + ], + "americas-arg-ppd-2018": [ + "B.2.2", + "E.1.2-1", + "F.1.3" ], - "amaericas-can-osfi-self-assessment": [ - "1.2" + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", + "03.02.02.A.01", "03.06.04.A", "03.06.05.D", "03.07.06.A", + "03.07.06.D", "03.08.02", "03.15.03.B", "03.16.03.B" diff --git a/docs/api/controls/HRS-04.1.json b/docs/api/controls/HRS-04.1.json index 35dd32a7..594b6c4f 100644 --- a/docs/api/controls/HRS-04.1.json +++ b/docs/api/controls/HRS-04.1.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that individuals accessing a system that stores, transmits or processes information requiring special protection satisfy organization-defined personnel screening criteria.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -159,10 +160,11 @@ "03.09.01.b" ], "general-nist-800-171a-r3": [ - "A.03.09.01.ODP[01]" - ], - "general-nist-800-172": [ - "3.9.1e" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.09.01.ODP[01]", + "A.03.09.01.a", + "A.03.09.01.b" ], "general-pci-dss-4-0-1": [ "12.7", @@ -211,27 +213,23 @@ ], "emea-deu-c5-2020": [ "HR-01", - "PSS-08" - ], - "emea-isr-cmo-1-0": [ - "19.2" + "HR-01-DOAR" ], "emea-sau-ecc-1-2018": [ "1-9-3-2" ], - "emea-sau-otcc-1-2022": [ - "1-7-1" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.d" ], - "emea-sau-sacs-002-2022": [ - "TPC-26" + "emea-esp-ccn-stic-825-2026": [ + "org.4", + "op.pl.1", + "mp.per.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0446", "ISM-0447" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-jpn-ismap": [ "7.1.1.7", "7.1.1.8" @@ -239,9 +237,6 @@ "apac-sgp-mas-trm-2021": [ "3.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "1.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.02.A.01", diff --git a/docs/api/controls/HRS-04.2.json b/docs/api/controls/HRS-04.2.json index 74dddfa0..4bc57428 100644 --- a/docs/api/controls/HRS-04.2.json +++ b/docs/api/controls/HRS-04.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department governs personnel management operations and notifies IT and/or cybersecurity personnel of role changes for logical access provisioning and deprovisioning actions.\n▪ Personnel managers ensure personnel are responsible for educating new hires on the organization's cybersecurity and data protection policies.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to formally educate authorized users on proper data handling practices for all the relevant types of data to which they have access.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -164,6 +165,13 @@ "03.06.04.a.01", "03.15.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.04.a.01", + "A.03.15.03.b" + ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e", "WORKFORCE-2a" @@ -176,6 +184,9 @@ "11.10(i)", "11.10(j)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -183,25 +194,13 @@ "500.10(a)(2)" ], "emea-sau-ecc-1-2018": [ - "1-9-4", - "1-9-4-1" - ], - "emea-sau-otcc-1-2022": [ - "1-8" - ], - "emea-sau-sacs-002-2022": [ - "TPC-26", - "TPC-71" + "1-9-4-1", + "1-9-4-2" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2", - "Article 15.1" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.b" ], - "emea-esp-decree-311-2022": [ - "13.2", - "15.1" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0435" ], "apac-jpn-ismap": [ @@ -213,12 +212,18 @@ "apac-nzl-ism-3-9": [ "9.1.7.C.01" ], + "americas-arg-ppd-2018": [ + "B.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.02.A.01", "03.06.04.A", "03.06.04.A.01", "03.15.03.B" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(d)" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-04.3.json b/docs/api/controls/HRS-04.3.json index fa42f07b..861eef40 100644 --- a/docs/api/controls/HRS-04.3.json +++ b/docs/api/controls/HRS-04.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to verify that individuals accessing a system processing, storing, or transmitting sensitive information meet applicable statutory, regulatory and/or contractual requirements for citizenship.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -94,10 +95,16 @@ "general-nist-800-82-r3": [ "PS-03(04)" ], + "general-nist-800-172-r3": [ + "03.09.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.04E" + ], "emea-sau-cscc-1-2019": [ "1-5-1-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0409", "ISM-0411", "ISM-0420", @@ -107,7 +114,6 @@ ], "apac-nzl-ism-3-9": [ "9.2.10.C.01", - "9.2.10.C.02", "9.2.11.C.01", "9.2.11.C.02", "9.2.15.C.01", diff --git a/docs/api/controls/HRS-04.4.json b/docs/api/controls/HRS-04.4.json index a841c43d..0180b455 100644 --- a/docs/api/controls/HRS-04.4.json +++ b/docs/api/controls/HRS-04.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to identify foreign nationals, including by their specific citizenship.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,11 +84,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0420" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/HRS-04.json b/docs/api/controls/HRS-04.json index d02b8487..bdea810f 100644 --- a/docs/api/controls/HRS-04.json +++ b/docs/api/controls/HRS-04.json @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -201,7 +202,8 @@ ], "general-nist-800-171-r3": [ "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.09.02.b.01" ], "general-nist-800-171a": [ "3.9.1" @@ -212,9 +214,6 @@ "A.03.09.01.b", "A.03.09.02.b.01[01]" ], - "general-nist-800-172": [ - "3.9.1e" - ], "general-pci-dss-4-0-1": [ "12.7", "12.7.1" @@ -225,9 +224,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.7.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "5.3A" ], @@ -259,10 +255,10 @@ "PS-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "2.C.3", @@ -306,24 +302,27 @@ "10.2.2(b)" ], "emea-deu-c5-2020": [ - "HR-01" - ], - "emea-isr-cmo-1-0": [ - "19.2" + "HR-01", + "HR-01-BP1", + "HR-01-BP2", + "HR-01-BP3", + "HR-01-BP4" ], "emea-sau-cscc-1-2019": [ "1-5-1-1" ], "emea-sau-ecc-1-2018": [ - "1-9-3", "1-9-3-2" ], "emea-sau-otcc-1-2022": [ "1-7-1" ], - "emea-zaf-popia-2013": [ - "19", - "20" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.d" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.1", + "mp.per.1" ], "emea-gbr-def-stan-05-138-2024": [ "2700", @@ -341,7 +340,7 @@ "2700", "2701" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0434" ], "apac-jpn-ismap": [ @@ -353,7 +352,7 @@ "7.1.1.9", "7.1.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP20", "HML20" ], @@ -366,11 +365,13 @@ "americas-bmu-mba-coc-2020": [ "5.13" ], - "amaericas-can-osfi-self-assessment": [ - "1.6" + "americas-can-osfi-self-assessment-2": [ + "3.2.7" ], "americas-can-itsp-10-171-2025": [ - "03.09.01.A" + "03.09.01.A", + "03.09.01.B", + "03.09.02.B.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-05.1.json b/docs/api/controls/HRS-05.1.json index dcb4b49c..ab9f5ae3 100644 --- a/docs/api/controls/HRS-05.1.json +++ b/docs/api/controls/HRS-05.1.json @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -235,6 +236,8 @@ "03.15.03.d" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.22.a", "A.03.15.03.ODP[01]", "A.03.15.03.a", "A.03.15.03.d[01]", @@ -272,9 +275,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.1.3" ], - "general-scf-dpmp-2025": [ - "7.7" - ], "general-tisax-6-0-3": [ "8.2.5", "8.2.7" @@ -317,10 +317,10 @@ "PL-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "PL-4" @@ -348,37 +348,23 @@ "emea-eu-nis2-annex-2024": [ "12.2.2(b)" ], - "emea-deu-c5-2020": [ - "HR-03" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "15.6", - "19.3", - "19.6" - ], - "emea-sau-cscc-1-2019": [ - "2-5" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.1" ], "emea-sau-ecc-1-2018": [ "1-9-3-1", - "1-9-4-2", "2-1-3", "2-1-4", "2-15-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-1", - "TPC-8", - "TPC-9" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.2", - "Article 11.3" + "VII.A.TPC-1" ], "emea-esp-decree-311-2022": [ - "11.2", - "11.3" + "Article 15(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -392,12 +378,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0820", - "ISM-0821" - ], - "apac-jpn-ppi-2020": [ - "21" + "ISM-0821", + "ISM-1864", + "ISM-2095" ], "apac-jpn-ismap": [ "7.2.1.2", @@ -423,14 +408,14 @@ "9.3.8.C.03", "14.3.5.C.01", "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "16.4.38.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.18.A", "03.01.22.A", - "03.15.03.A" + "03.15.03.A", + "03.15.03.D" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-05.2.json b/docs/api/controls/HRS-05.2.json index 32ca2cf0..37aab1f3 100644 --- a/docs/api/controls/HRS-05.2.json +++ b/docs/api/controls/HRS-05.2.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define rules of behavior that contain explicit restrictions on the use of social media and networking sites, posting information on commercial websites and sharing account information.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define rules of behavior that contain explicit restrictions on the use of social media and networking sites, posting information on commercial websites and sharing account information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,12 +89,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0" + "9" ], "general-govramp": [ "PL-04(01)" @@ -164,9 +165,6 @@ "general-nist-800-171a-r3": [ "A.03.15.03.a" ], - "general-scf-dpmp-2025": [ - "7.7" - ], "usa-federal-fbi-cjis-6-0": [ "PL-4(1)" ], @@ -209,11 +207,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PL-04 (01)" ], - "emea-isr-cmo-1-0": [ - "4.13", - "19.6", - "19.7" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2" ], @@ -229,22 +222,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0229", "ISM-0230", "ISM-0233", "ISM-0235", "ISM-0236", "ISM-0240", - "ISM-0241", "ISM-0264", "ISM-0267", "ISM-0588", "ISM-0824", "ISM-0931", - "ISM-1075", "ISM-1078", - "ISM-1092", "ISM-1196", "ISM-1198", "ISM-1199", diff --git a/docs/api/controls/HRS-05.3.json b/docs/api/controls/HRS-05.3.json index bb185101..2d554a7c 100644 --- a/docs/api/controls/HRS-05.3.json +++ b/docs/api/controls/HRS-05.3.json @@ -3,7 +3,7 @@ "title": "Technology Use Restrictions", "family": "HRS", "description": "Mechanisms exist to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously.", - "scf_question": "Does the organization establish usage restrictions and implementation guidance for communications technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously?", + "scf_question": "Does the organization establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -20,7 +20,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -204,6 +205,8 @@ "03.15.03.a" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", + "A.03.01.18.a[01]", "A.03.15.03.a" ], "general-pci-dss-4-0-1": [ @@ -241,10 +244,10 @@ "PL-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "3.3.2", @@ -285,24 +288,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PL-04" ], - "emea-isr-cmo-1-0": [ - "5.4", - "9.5", - "15.6", - "19.6" - ], - "emea-sau-cscc-1-2019": [ - "2-5" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2", - "2-1-3", - "2-6-4", "2-15-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-8", - "TPC-9" + "VII.A.TPC-8" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -316,6 +307,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], + "apac-aus-ism-2026-march": [ + "ISM-1866", + "ISM-2075", + "ISM-2095", + "ISM-2099", + "ISM-2100", + "ISM-2101" + ], "apac-jpn-ismap": [ "13.2.1.1", "13.2.1.2", @@ -330,9 +329,26 @@ "9.3.5.C.02", "9.3.9.C.01", "9.3.10.C.01", - "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "11.1.15.C.01", + "11.1.16.C.03", + "11.1.16.C.04", + "11.1.17.C.02", + "11.1.18.C.01", + "11.1.18.C.02", + "11.1.19.C.02", + "11.2.14.C.01", + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03", + "11.8.4.C.01", + "11.8.4.C.02", + "11.8.5.C.01", + "11.8.6.C.01", + "11.8.6.C.02", + "15.1.7.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.1.5" ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", diff --git a/docs/api/controls/HRS-05.4.json b/docs/api/controls/HRS-05.4.json index e249a50e..6a81a690 100644 --- a/docs/api/controls/HRS-05.4.json +++ b/docs/api/controls/HRS-05.4.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern usage policies for critical technologies.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern usage policies for critical technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -142,16 +143,17 @@ "general-nist-800-171-r3": [ "03.15.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.15.03.a" + ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e" ], - "emea-isr-cmo-1-0": [ - "15.6", - "19.6" - ], "emea-sau-ecc-1-2018": [ - "1-9-4-2", - "2-1-3" + "1-9-4-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2095" ], "americas-can-itsp-10-171-2025": [ "03.15.03.A" diff --git a/docs/api/controls/HRS-05.5.json b/docs/api/controls/HRS-05.5.json index 3d8f92f5..9dfc0f82 100644 --- a/docs/api/controls/HRS-05.5.json +++ b/docs/api/controls/HRS-05.5.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to manage business risks associated with permitting mobile device access to organizational resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -134,6 +135,7 @@ "03.15.03.a" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", "A.03.15.03.a" ], "general-shared-assessments-sig-2025": [ @@ -142,20 +144,16 @@ "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e" ], - "emea-deu-c5-2020": [ - "AM-05" - ], - "emea-isr-cmo-1-0": [ - "13.2", - "13.3", - "13.7", - "13.10", - "15.6", - "19.6" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-1", + "2-5-1-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-84" + ], "emea-gbr-def-stan-05-138-2024": [ "2322" ], @@ -168,7 +166,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0229", "ISM-0230", "ISM-0240", @@ -186,7 +184,8 @@ "ISM-1198", "ISM-1199", "ISM-1200", - "ISM-1366" + "ISM-1366", + "ISM-1866" ], "apac-nzl-ism-3-9": [ "8.1.12.C.01", @@ -205,9 +204,19 @@ "11.5.16.C.02", "11.5.16.C.03", "21.1.11.C.01", - "21.1.11.C.02", - "21.1.22.C.01", - "21.1.22.C.02" + "22.1.10.C.02", + "22.1.13.C.01", + "22.1.13.C.02", + "22.1.13.C.03", + "22.1.13.C.04", + "22.1.13.C.05", + "22.2.5.C.01", + "22.2.6.C.01", + "22.2.7.C.01", + "22.2.7.C.02", + "22.3.5.C.01", + "22.3.6.C.01", + "22.4.9.C.01" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", diff --git a/docs/api/controls/HRS-05.6.json b/docs/api/controls/HRS-05.6.json index 7683f8f7..9160746a 100644 --- a/docs/api/controls/HRS-05.6.json +++ b/docs/api/controls/HRS-05.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to prohibit the use of oversized clothing (e.g., baggy pants, oversized hooded sweatshirts, etc.) to prevent the unauthorized exfiltration of data and technology assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53,7 +53,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": {} diff --git a/docs/api/controls/HRS-05.7.json b/docs/api/controls/HRS-05.7.json index dea55223..64a219cd 100644 --- a/docs/api/controls/HRS-05.7.json +++ b/docs/api/controls/HRS-05.7.json @@ -3,7 +3,7 @@ "title": "Policy Familiarization & Acknowledgement", "family": "HRS", "description": "Mechanisms exist to ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement.", - "scf_question": "Does the organization ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement?", + "scf_question": "Does the organization ensure personnel receive recurring familiarization with its security, compliance and resilience policies and provide acknowledgement?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,9 +103,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-iso-27001-2022": [ @@ -119,12 +119,12 @@ "OR-3.1" ], "general-nist-800-171-r3": [ - "03.15.03.b", "03.15.03.c", "03.15.03.d" ], "general-nist-800-171a-r3": [ - "A.03.15.03.c" + "A.03.15.03.c", + "A.03.15.03.d[02]" ], "general-nist-csf-2-0": [ "GV.PO", @@ -147,7 +147,7 @@ "609.930(c)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(b)(1)" + "§ 164.530(b)(1)" ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PL-04-SID" @@ -155,9 +155,21 @@ "emea-eu-nis2-annex-2024": [ "1.1.1(f)" ], - "emea-sau-sacs-002-2022": [ - "TPC-26", - "TPC-71" + "emea-aut-dpa-2018": [ + "§ 6(3)" + ], + "emea-deu-c5-2020": [ + "HR-02" + ], + "emea-sau-ecc-1-2018": [ + "1-9-4-1", + "1-9-4-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.b" + ], + "emea-esp-decree-311-2022": [ + "Article 13(2)" ], "apac-jpn-ismap": [ "4.5.2.6", @@ -167,9 +179,11 @@ "8.1.3.1" ], "americas-can-itsp-10-171-2025": [ - "03.15.03.B", "03.15.03.C", "03.15.03.D" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(d)" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-05.json b/docs/api/controls/HRS-05.json index d4077a58..0e2e5ab3 100644 --- a/docs/api/controls/HRS-05.json +++ b/docs/api/controls/HRS-05.json @@ -107,9 +107,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -214,9 +214,13 @@ "general-nist-800-171-r3": [ "03.01.01.h", "03.01.22.a", - "03.15.03.a" + "03.15.03.a", + "03.15.03.b" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", + "A.03.01.22.a", + "A.03.15.03.a", "A.03.15.03.b" ], "general-nist-csf-2-0": [ @@ -292,10 +296,10 @@ "155.260(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "PL-4" @@ -319,37 +323,35 @@ "1.2.2", "10.3.2" ], + "emea-deu-fdpa-2017": [ + "3.2.48(2)8" + ], "emea-deu-c5-2020": [ "HR-02", - "HR-03", - "AM-05" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "19.3", - "19.4" - ], - "emea-sau-cscc-1-2019": [ - "2-5" + "HR-05", + "AM-04" ], "emea-sau-ecc-1-2018": [ - "1-9-3-1", - "1-9-3-2", - "1-9-4-2" + "1-9-1", + "1-9-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.2", - "Article 11.3" + "VII.A.TPC-1" ], "emea-esp-decree-311-2022": [ - "11.2", - "11.3" + "Article 12(6)(d)", + "Article 13(1)" ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.2 [MP.PER.2]" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" + ], + "emea-che-fadp-2025": [ + "5.30.1", + "5.30.2", + "5.30.2.a", + "5.30.2.b", + "5.30.2.c", + "5.30.3" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -363,10 +365,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0258", "ISM-0824", - "ISM-1146" + "ISM-1146", + "ISM-1865" ], "apac-jpn-ismap": [ "7.1.2", @@ -394,12 +397,18 @@ "9.3.7.C.04", "9.3.8.C.01", "9.3.8.C.02", - "9.3.8.C.03" + "9.3.8.C.03", + "21.1.6.C.02", + "21.2.3.C.01" + ], + "americas-bhs-dpa-2003": [ + "II.4(2)" ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", "03.01.22.A", - "03.15.03.A" + "03.15.03.A", + "03.15.03.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-06.1.json b/docs/api/controls/HRS-06.1.json index ffc76af6..036e3791 100644 --- a/docs/api/controls/HRS-06.1.json +++ b/docs/api/controls/HRS-06.1.json @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -182,6 +183,10 @@ "03.12.05.a", "03.15.03.c" ], + "general-nist-800-171a-r3": [ + "A.03.12.05.a[01]", + "A.03.15.03.c" + ], "general-tisax-6-0-3": [ "2.1.2", "6.1.2" @@ -209,7 +214,7 @@ "PS-06(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)" + "§ 164.502(a)" ], "usa-federal-irs-1075-2021": [ "PS-6" @@ -232,27 +237,41 @@ "emea-eu-nis2-annex-2024": [ "10.3.2" ], + "emea-eu-psd2-2015": [ + "24(1)" + ], + "emea-aut-dpa-2018": [ + "§ 5(1)" + ], "emea-deu-c5-2020": [ - "HR-06", - "IDM-08", - "PSS-07" + "IDM-07-DOAR", + "KOS-08" ], - "emea-isr-cmo-1-0": [ - "19.4" + "emea-isr-ppl-5741-2025": [ + "s.16" ], "emea-sau-ecc-1-2018": [ - "1-9-3-1" + "1-9-3-1", + "4-1-2-1" ], "emea-sau-sacs-002-2022": [ - "TPC-9", - "TPC-71" + "VII.A.TPC-9" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.a" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" + ], + "apac-chn-csnip-2012": [ + "III" + ], + "apac-chn-pipl-2021": [ + "Article 59" ], "apac-ind-sebi-2024": [ "GV.RR.S5" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "13.2.4", "13.2.4.1", @@ -278,6 +297,12 @@ "americas-can-itsp-10-171-2025": [ "03.12.05.A", "03.15.03.C" + ], + "americas-chl-act-19628-1999": [ + "I.7" + ], + "americas-col-law-1581-2012": [ + "II.4(h)" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-06.2.json b/docs/api/controls/HRS-06.2.json index f0030c2f..20c2c680 100644 --- a/docs/api/controls/HRS-06.2.json +++ b/docs/api/controls/HRS-06.2.json @@ -2,8 +2,8 @@ "control_id": "HRS-06.2", "title": "Post-Employment Requirements Awareness", "family": "HRS", - "description": "Mechanisms exist to notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive/regulated data.", - "scf_question": "Does the organization notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive/regulated data?", + "description": "Mechanisms exist to notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive and/or regulated data.", + "scf_question": "Does the organization notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive and/or regulated data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -99,7 +99,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -117,6 +118,9 @@ "PS-6(CE-3).a", "PS-6(CE-3).b" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e" + ], "apac-jpn-ismap": [ "7.1.2.10" ] diff --git a/docs/api/controls/HRS-06.json b/docs/api/controls/HRS-06.json index a5f05d9a..0bb8f317 100644 --- a/docs/api/controls/HRS-06.json +++ b/docs/api/controls/HRS-06.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to require internal and third-party users to sign appropriate access agreements prior to being granted access.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to require internal and third-party users to sign appropriate access agreements prior to being granted access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -181,9 +182,19 @@ "general-nist-800-171-r3": [ "03.01.18.a", "03.12.05.a", - "03.15.03.b", "03.15.03.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.12.05.a[01]", + "A.03.15.03.c" + ], + "general-nist-800-172-r3": [ + "03.09.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.03E.c.01" + ], "general-tisax-6-0-3": [ "2.1.2" ], @@ -235,26 +246,18 @@ "emea-deu-c5-2020": [ "HR-02" ], - "emea-isr-cmo-1-0": [ - "19.6" - ], "emea-sau-ecc-1-2018": [ - "1-9-3" + "1-9-3-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-9", - "TPC-71" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "apac-ind-sebi-2024": [ "GV.RR.S5" ], - "apac-jpn-ppi-2020": [ - "21" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.12.05.A", - "03.15.03.B", "03.15.03.C" ] } diff --git a/docs/api/controls/HRS-07.1.json b/docs/api/controls/HRS-07.1.json index 89a9ebd5..58f97975 100644 --- a/docs/api/controls/HRS-07.1.json +++ b/docs/api/controls/HRS-07.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Requests for investigations are handled through a formal, management-approved process.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to conduct employee misconduct investigations when there is reasonable assurance that a policy has been violated.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to conduct employee misconduct investigations when there is reasonable assurance that a policy has been violated. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -128,8 +129,9 @@ "03.01.01.f.04", "03.01.01.f.05" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1g" @@ -143,7 +145,7 @@ "emea-eu-nis2-annex-2024": [ "10.4.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP03", "HHSP73", "HML03", diff --git a/docs/api/controls/HRS-07.2.json b/docs/api/controls/HRS-07.2.json index 251f7608..ec4a33c6 100644 --- a/docs/api/controls/HRS-07.2.json +++ b/docs/api/controls/HRS-07.2.json @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { diff --git a/docs/api/controls/HRS-07.3.json b/docs/api/controls/HRS-07.3.json index 7a75b60c..a1c7ae82 100644 --- a/docs/api/controls/HRS-07.3.json +++ b/docs/api/controls/HRS-07.3.json @@ -2,8 +2,8 @@ "control_id": "HRS-07.3", "title": "Preventative Access Restriction", "family": "HRS", - "description": "Mechanisms exist to proactively restrict logical and physical access when an individual with access to sensitive/regulated data is under investigation for personnel sanctions that may lead to employment termination.", - "scf_question": "Does the organization proactively restrict logical and physical access when an individual with access to sensitive/regulated data is under investigation for personnel sanctions that may lead to employment termination?", + "description": "Mechanisms exist to proactively restrict logical and physical access when an individual with access to sensitive and/or regulated data is under investigation for personnel sanctions that may lead to employment termination.", + "scf_question": "Does the organization proactively restrict logical and physical access when an individual with access to sensitive and/or regulated data is under investigation for personnel sanctions that may lead to employment termination?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -99,13 +99,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { - "general-nist-800-172": [ - "3.9.2e" - ], "usa-federal-dow-cmmc-2-level-3": [ "PS.L3-3.9.2E" ] diff --git a/docs/api/controls/HRS-07.json b/docs/api/controls/HRS-07.json index d9baebe6..fe643e75 100644 --- a/docs/api/controls/HRS-07.json +++ b/docs/api/controls/HRS-07.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Requests for investigations are handled through a formal, management-approved process.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to sanction personnel failing to comply with established security policies, standards and procedures.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to sanction personnel failing to comply with established security policies, standards and procedures. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -180,17 +181,15 @@ "3.9.2[b]", "3.9.2[c]" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" ], "general-nist-csf-2-0": [ "GV.PO", "GV.PO-01", "GV.PO-02" ], - "general-scf-dpmp-2025": [ - "7.8" - ], "usa-federal-dow-cert-rmm-1-2": [ "HRM:SG3.SP4" ], @@ -216,11 +215,11 @@ "PS-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(C)", - "164.530(e)(1)" + "§ 164.308(a)(1)(ii)(C)", + "§ 164.530(e)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(C)" + "§ 164.308(a)(1)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.2", @@ -252,8 +251,8 @@ "emea-deu-c5-2020": [ "HR-04" ], - "emea-isr-cmo-1-0": [ - "19.8" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.c" ], "apac-jpn-ismap": [ "7.2.3", @@ -262,7 +261,7 @@ "7.2.3.3", "7.2.3.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP03", "HHSP72", "HHSP73", diff --git a/docs/api/controls/HRS-08.json b/docs/api/controls/HRS-08.json index 359da2c7..70c694a1 100644 --- a/docs/api/controls/HRS-08.json +++ b/docs/api/controls/HRS-08.json @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -173,7 +174,8 @@ "general-nist-800-171-r3": [ "03.01.01.g.02", "03.09.02.a", - "03.09.02.b.01" + "03.09.02.b.01", + "03.09.02.b.02" ], "general-nist-800-171a": [ "3.9.2[a]", @@ -181,7 +183,9 @@ "3.9.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", + "A.03.09.02.a.01", "A.03.09.02.b.01[01]", "A.03.09.02.b.01[02]", "A.03.09.02.b.02" @@ -211,10 +215,10 @@ "PS-05" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.1", @@ -247,19 +251,17 @@ "HR-05", "IDM-04" ], - "emea-isr-cmo-1-0": [ - "19.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], - "emea-sau-sacs-002-2022": [ - "TPC-18" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", "03.09.02.A", - "03.09.02.B.01" + "03.09.02.B.01", + "03.09.02.B.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-09.1.json b/docs/api/controls/HRS-09.1.json index f763a996..d19a103c 100644 --- a/docs/api/controls/HRS-09.1.json +++ b/docs/api/controls/HRS-09.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to retrieve organization-owned assets upon termination of an individual's employment.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -123,12 +124,6 @@ "emea-eu-nis2-annex-2024": [ "12.5" ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-18" - ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" ] diff --git a/docs/api/controls/HRS-09.2.json b/docs/api/controls/HRS-09.2.json index e7ada1da..2f56cece 100644 --- a/docs/api/controls/HRS-09.2.json +++ b/docs/api/controls/HRS-09.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to expedite the process of removing \"high risk\" individual’s access to TAASD upon termination, as determined by management.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -144,6 +145,12 @@ "03.09.02.a.02", "03.09.02.b.01" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]", + "A.03.09.02.b.01[01]" + ], "general-pci-dss-4-0-1": [ "8.2.5" ], @@ -183,13 +190,6 @@ "usa-federal-irs-1075-2021": [ "AC-2(CE-13)" ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-18" - ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.01", "03.09.02.A.02", diff --git a/docs/api/controls/HRS-09.3.json b/docs/api/controls/HRS-09.3.json index bcbbca9e..93f46816 100644 --- a/docs/api/controls/HRS-09.3.json +++ b/docs/api/controls/HRS-09.3.json @@ -2,8 +2,8 @@ "control_id": "HRS-09.3", "title": "Post-Employment Requirements Notification", "family": "HRS", - "description": "Mechanisms exist to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data.", - "scf_question": "Does the organization govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data?", + "description": "Mechanisms exist to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive and/or regulated data.", + "scf_question": "Does the organization govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -124,12 +125,6 @@ ], "general-nist-800-82-r3": [ "PS-04(01)" - ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-18" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-09.4.json b/docs/api/controls/HRS-09.4.json index 248ba7c9..39fd036c 100644 --- a/docs/api/controls/HRS-09.4.json +++ b/docs/api/controls/HRS-09.4.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to automatically notify Identity and Access Management (IAM) personnel or roles upon termination of an individual employment or contract.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -85,7 +85,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -118,11 +119,17 @@ "03.09.02.a.01", "03.09.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.g.02", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], "usa-federal-gsa-fedramp-5-high": [ "PS-04(02)" ], "emea-sau-sacs-002-2022": [ - "TPC-6" + "VII.A.TPC-6" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", diff --git a/docs/api/controls/HRS-09.json b/docs/api/controls/HRS-09.json index 121e47bf..74552827 100644 --- a/docs/api/controls/HRS-09.json +++ b/docs/api/controls/HRS-09.json @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -175,6 +176,7 @@ "03.01.01.f.03", "03.01.01.g.02", "03.09.02.a", + "03.09.02.a.02", "03.09.02.a.03", "03.09.02.b.01" ], @@ -184,11 +186,14 @@ "3.9.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.f.03", + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", "A.03.09.02.a.01", "A.03.09.02.a.02[01]", "A.03.09.02.a.02[02]", - "A.03.09.02.a.03" + "A.03.09.02.a.03", + "A.03.09.02.b.01[01]" ], "general-pci-dss-4-0-1": [ "8.2.5" @@ -237,10 +242,10 @@ "PS-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.3", @@ -280,15 +285,10 @@ "emea-deu-c5-2020": [ "HR-05" ], - "emea-isr-cmo-1-0": [ - "19.9", - "19.10" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], - "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-18" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "apac-jpn-ismap": [ @@ -302,6 +302,7 @@ "03.01.01.F.03", "03.01.01.G.02", "03.09.02.A", + "03.09.02.A.02", "03.09.02.A.03", "03.09.02.B.01" ] diff --git a/docs/api/controls/HRS-10.json b/docs/api/controls/HRS-10.json index bdd711b0..3956100f 100644 --- a/docs/api/controls/HRS-10.json +++ b/docs/api/controls/HRS-10.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern third-party personnel by reviewing and monitoring third-party security, compliance and/or resilience roles and responsibilities.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -111,9 +111,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -173,6 +173,9 @@ "general-nist-800-171-r3": [ "03.16.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.b" + ], "general-swift-cscf-2025": [ "5.3A" ], @@ -215,11 +218,8 @@ "emea-eu-nis2-annex-2024": [ "10.2.1" ], - "emea-isr-cmo-1-0": [ - "19.5" - ], - "emea-sau-ecc-1-2018": [ - "1-9-1" + "emea-sau-otcc-1-2022": [ + "1-7-1" ], "apac-jpn-ismap": [ "7.1.1.10" diff --git a/docs/api/controls/HRS-11.json b/docs/api/controls/HRS-11.json index 1b391ff8..d020d56e 100644 --- a/docs/api/controls/HRS-11.json +++ b/docs/api/controls/HRS-11.json @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -142,7 +143,7 @@ "5.3", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -406,6 +407,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ], "usa-federal-irs-1075-2021": [ "AC-5" ], @@ -429,23 +433,21 @@ ], "emea-deu-c5-2020": [ "OIS-04", - "IDM-01" - ], - "emea-isr-cmo-1-0": [ - "4.11", - "10.4" + "OIS-04-BP1", + "OIS-04-BP2", + "OIS-04-BP3", + "OIS-04-DOAR", + "IDM-01-BP2", + "IDM-01-BP3", + "BEI-12" ], "emea-sau-cgiot-2024": [ "2-2-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.3" - ], - "emea-esp-decree-311-2022": [ - "13.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.3 [OP.ACC.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.3", + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2207" @@ -471,11 +473,19 @@ "6.1.2.4" ], "apac-sgp-mas-trm-2021": [ + "6.3.2", + "7.6.1", "9.1.1" ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-osfi-b13-2022": [ "2.5.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.04.A" ] diff --git a/docs/api/controls/HRS-12.1.json b/docs/api/controls/HRS-12.1.json index 4dc473b3..537b0daa 100644 --- a/docs/api/controls/HRS-12.1.json +++ b/docs/api/controls/HRS-12.1.json @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -121,6 +122,13 @@ "general-nist-800-160-vol-2-r1": [ "AC-03(02)" ], + "general-nist-800-172-r3": [ + "03.01.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" + ], "general-sparta": [ "CM0054" ], diff --git a/docs/api/controls/HRS-12.json b/docs/api/controls/HRS-12.json index a5edaa35..a908d72b 100644 --- a/docs/api/controls/HRS-12.json +++ b/docs/api/controls/HRS-12.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates risk for individuals requiring elevated privileges or access to sensitive/regulated data.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to avoid incompatible development-specific roles through limiting and reviewing developer privileges to change hardware, software and firmware components within a production/operational environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -113,11 +114,11 @@ "general-nist-800-171-r3": [ "03.01.04.a" ], - "emea-deu-c5-2020": [ - "PSS-08" + "general-nist-800-171a-r3": [ + "A.03.01.04.a" ], - "apac-chn-data-security-law-2021": [ - "27" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.3" ], "americas-can-itsp-10-171-2025": [ "03.01.04.A" diff --git a/docs/api/controls/HRS-13.1.json b/docs/api/controls/HRS-13.1.json index 75709b18..11709a70 100644 --- a/docs/api/controls/HRS-13.1.json +++ b/docs/api/controls/HRS-13.1.json @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -95,6 +96,9 @@ ], "usa-federal-dow-cert-rmm-1-2": [ "HRM:SG2" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-13.2.json b/docs/api/controls/HRS-13.2.json index 2ad6ec1a..c74358f0 100644 --- a/docs/api/controls/HRS-13.2.json +++ b/docs/api/controls/HRS-13.2.json @@ -85,9 +85,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-cobit-2019": [ @@ -98,9 +98,6 @@ "PM:SG1.SP1", "PM:SG2", "PM:SG2.SP1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-13.3.json b/docs/api/controls/HRS-13.3.json index ff7f954e..57f27912 100644 --- a/docs/api/controls/HRS-13.3.json +++ b/docs/api/controls/HRS-13.3.json @@ -83,19 +83,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-cobit-2019": [ "APO07.03" ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" + ], "emea-eu-nis2-annex-2024": [ "4.2.4(c)" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-13.4.json b/docs/api/controls/HRS-13.4.json index 939cd833..6d23fb52 100644 --- a/docs/api/controls/HRS-13.4.json +++ b/docs/api/controls/HRS-13.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates the business-critical cybersecurity and data protection skills needed to support the organization's mission and identify gaps that exist.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to perform succession planning for vital security, compliance and resilience roles.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -84,9 +84,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -97,9 +97,6 @@ ], "general-shared-assessments-sig-2025": [ "K.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-13.json b/docs/api/controls/HRS-13.json index 980795d9..c600baf3 100644 --- a/docs/api/controls/HRS-13.json +++ b/docs/api/controls/HRS-13.json @@ -3,7 +3,7 @@ "title": "Identify Critical Skills & Gaps", "family": "HRS", "description": "Mechanisms exist to evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist.", - "scf_question": "Does the organization evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist?", + "scf_question": "Does the organization evaluate the critical security, compliance and resilience skills needed to support its mission and identify gaps that exist?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -87,9 +87,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -107,6 +107,9 @@ "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-4b", "WORKFORCE-4c" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/HRS-14.1.json b/docs/api/controls/HRS-14.1.json index a5afc44d..8a425ca3 100644 --- a/docs/api/controls/HRS-14.1.json +++ b/docs/api/controls/HRS-14.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to communicate authorized work locations to organizational personnel.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { diff --git a/docs/api/controls/HRS-14.json b/docs/api/controls/HRS-14.json index a8070ac5..bced7f49 100644 --- a/docs/api/controls/HRS-14.json +++ b/docs/api/controls/HRS-14.json @@ -3,7 +3,7 @@ "title": "Identifying Authorized Work Locations", "family": "HRS", "description": "Mechanisms exist to identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home).", - "scf_question": "Does the organization identity and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home)?", + "scf_question": "Does the organization identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { diff --git a/docs/api/controls/HRS-15.json b/docs/api/controls/HRS-15.json index 8fca02b5..cbc5d3ff 100644 --- a/docs/api/controls/HRS-15.json +++ b/docs/api/controls/HRS-15.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { diff --git a/docs/api/controls/IAC-01.1.json b/docs/api/controls/IAC-01.1.json index 978024f0..f25f7904 100644 --- a/docs/api/controls/IAC-01.1.json +++ b/docs/api/controls/IAC-01.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to retain a record of personnel accountability to ensure there is a record of all access granted to an individual (system and application-wise), who provided the authorization, when the authorization was granted and when the access was last reviewed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -124,8 +125,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1503" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0407" + ], + "apac-sgp-mas-trm-2021": [ + "9.1.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-01.2.json b/docs/api/controls/IAC-01.2.json index bf8b8b96..942262c8 100644 --- a/docs/api/controls/IAC-01.2.json +++ b/docs/api/controls/IAC-01.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).\n▪ LAC and RBAC enforcements limit the ability of non-administrators from making unauthorized configuration changes to TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to strictly govern the use of Authenticate, Authorize and Audit (AAA) solutions, both on-premises and those hosted by an External Service Provider (ESP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -97,7 +97,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -213,6 +214,8 @@ "IA-4" ], "general-nist-800-171-r3": [ + "03.01.01.d.01", + "03.01.16.b", "03.05.01.a", "03.05.02", "03.05.05.d", @@ -222,18 +225,23 @@ "03.05.07.d", "03.05.07.e", "03.05.12.d", - "03.05.12.f", "03.07.05.a" ], "general-nist-800-171a-r3": [ "A.03.01.01.d.01", - "A.03.01.01.d.02", "A.03.01.16.b", "A.03.05.01.a[01]", - "A.03.05.01.a[02]" - ], - "general-nist-800-172": [ - "3.5.2e" + "A.03.05.01.a[02]", + "A.03.05.02[01]", + "A.03.05.02[02]", + "A.03.05.05.d", + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.12.d", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 2", @@ -247,9 +255,6 @@ "PR.AA-04", "PR.AA-05" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0031" ], @@ -325,12 +330,31 @@ "2447(c)(1)(B)", "2447(c)(2)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(g)" + ], "emea-eu-nis2-annex-2024": [ "11.3.2(a)", "11.4.2(c)", "11.6.1", "11.6.3" ], + "emea-deu-c5-2020": [ + "IDM-02", + "IDM-03-BP2", + "IDM-08-BP2" + ], + "emea-sau-ecc-1-2018": [ + "2-2-3-1" + ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP5", + "4", + "4-BP2" + ], "emea-gbr-def-stan-05-138-2024": [ "2200", "2209", @@ -353,6 +377,10 @@ "2210", "2304" ], + "apac-aus-ism-2026-march": [ + "ISM-2013", + "ISM-2014" + ], "apac-jpn-ismap": [ "9.4.2", "9.4.2.1", @@ -372,14 +400,28 @@ "9.4.2.15", "9.4.2.16" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP39", "HML39" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP34" ], + "apac-nzl-ism-3-9": [ + "16.1.26.C.01" + ], + "americas-arg-ppd-2018": [ + "B.2.3-1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.D.01", + "03.01.16.B", "03.05.01.A", "03.05.02", "03.05.05.D", @@ -389,7 +431,6 @@ "03.05.07.D", "03.05.07.E", "03.05.12.D", - "03.05.12.F", "03.07.05.A" ] } diff --git a/docs/api/controls/IAC-01.3.json b/docs/api/controls/IAC-01.3.json index 6dd5f3cf..07e4835e 100644 --- a/docs/api/controls/IAC-01.3.json +++ b/docs/api/controls/IAC-01.3.json @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-01.4.json b/docs/api/controls/IAC-01.4.json new file mode 100644 index 00000000..113cfe50 --- /dev/null +++ b/docs/api/controls/IAC-01.4.json @@ -0,0 +1,107 @@ +{ + "control_id": "IAC-01.4", + "title": "Identity Providers (IdP) & Authorization Servers", + "family": "IAC", + "description": "Mechanisms exist to employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms.", + "scf_question": "Does the organization employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms.", + "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "small": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "medium": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "large": "∙ Microsoft Entra ID with conditional access\n∙ Okta Workforce Identity\n∙ SailPoint for identity governance", + "enterprise": "∙ Enterprise IdP with federation (SAML/OIDC/OAuth 2.0)\n∙ Microsoft Entra ID with Privileged Identity Management\n∙ Okta or Ping Identity enterprise tier\n∙ SailPoint or Saviynt for identity governance" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Identification & Authentication", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.05.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.07E[01]", + "A.03.05.07E.ODP[02]", + "DS-A.03.05.07E[02]", + "DS-A.03.05.07E[03]" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/IAC-01.json b/docs/api/controls/IAC-01.json index fcab7888..35be95e2 100644 --- a/docs/api/controls/IAC-01.json +++ b/docs/api/controls/IAC-01.json @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -143,9 +144,9 @@ ], "general-cis-csc-8-1": [ "4.7", - "5.0", + "5", "5.6", - "6.0", + "6", "6.6" ], "general-cis-csc-8-1-ig1": [ @@ -297,6 +298,20 @@ "03.05.05.a", "03.05.12.e" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.a[01]", + "A.03.01.01.a[02]", + "A.03.01.18.b", + "A.03.05.01.a[01]", + "A.03.05.05.a", + "A.03.05.12.e" + ], + "general-nist-800-172-r3": [ + "03.05.07E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.07E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 6" ], @@ -356,9 +371,6 @@ "8.5.1", "8.6.1" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-swift-cscf-2025": [ "4.1", "5.2" @@ -449,25 +461,28 @@ "AC-01", "IA-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(1)", "314.4(c)(1)(i)", "314.4(c)(1)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)", + "§ 164.530(c)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "AC-1", @@ -522,6 +537,9 @@ "usa-state-vt-act-171-2018": [ "2447(c)(1)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(g)" + ], "emea-eu-dora-2023": [ "Article 9.4(d)" ], @@ -540,73 +558,49 @@ "11.5.2(c)", "11.6.4" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "6.1", "6.2" ], "emea-deu-c5-2020": [ "IDM-01", - "PSS-05", - "PSS-09" + "IDM-03" ], - "emea-isr-cmo-1-0": [ - "4.1", - "4.8", - "4.34", - "4.37", - "12.15", - "12.28", - "12.29" + "emea-isr-cmo-2-0": [ + "Appendix A, 8.2" ], "emea-sau-cscc-1-2019": [ - "2-2", - "2-2-1-5" + "2-2-1" ], "emea-sau-ecc-1-2018": [ "2-2-1", - "2-2-2", - "2-2-4" + "2-2-3" ], "emea-sau-otcc-1-2022": [ - "2-2", - "2-2-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-10" + "2-2-1", + "2-2-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.5" - ], - "emea-zaf-popia-2013": [ - "19", - "20" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" + "3.3.5.1" ], "emea-esp-decree-311-2022": [ - "18" + "Article 12(6)(e)", + "Article 24(3)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.2 [OP.ACC.2]", - "7.2.4 [OP.ACC.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-caf-4-0": [ "B2", "B2.d" ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "4" ], "emea-gbr-def-stan-05-138-2024": [ "2200", @@ -627,9 +621,11 @@ "2208", "2210" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1146", - "ISM-1546" + "ISM-1546", + "ISM-2076", + "ISM-2077" ], "apac-chn-cybersecurity-law-2017": [ "Article 40" @@ -661,33 +657,46 @@ "9.1.1.15", "9.4.1.8.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.53", + "10.54", + "10.56", + "10.57" + ], "apac-nzl-ism-3-9": [ - "16.1.31.C.01" + "16.1.31.C.01", + "16.4.39.C.01", + "20.2.16.C.02" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.1" ], "apac-sgp-mas-trm-2021": [ - "9.1.2", - "9.1.3", - "9.1.8" + "9.1.8", + "9.2.2" + ], + "americas-arg-ppd-2018": [ + "B", + "D.1.2-1" ], "americas-bmu-mba-coc-2020": [ "6.6" ], - "amaericas-can-osfi-self-assessment": [ - "4.22", - "4.24" - ], "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.A", "03.01.18.B", "03.05.01.A", "03.05.05.A", "03.05.12.E" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(b)" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-02.1.json b/docs/api/controls/IAC-02.1.json index ea2cc132..593e8193 100644 --- a/docs/api/controls/IAC-02.1.json +++ b/docs/api/controls/IAC-02.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -147,19 +148,12 @@ "usa-federal-gsa-fedramp-5-high": [ "IA-02(05)" ], - "emea-isr-cmo-1-0": [ - "4.34" - ], - "emea-sau-cscc-1-2019": [ - "2-2-1-7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0415", "ISM-1619" ], "apac-nzl-ism-3-9": [ "16.1.33.C.01", - "16.1.33.C.02", "16.1.34.C.01" ] } diff --git a/docs/api/controls/IAC-02.2.json b/docs/api/controls/IAC-02.2.json index a3af4272..c4cdf25a 100644 --- a/docs/api/controls/IAC-02.2.json +++ b/docs/api/controls/IAC-02.2.json @@ -92,7 +92,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -142,9 +143,6 @@ "A.03.05.04[02]", "A.03.07.05.b[02]" ], - "general-nist-800-172": [ - "3.5.1e" - ], "general-nist-csf-2-0": [ "PR.AA-04" ], @@ -196,9 +194,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (08)" ], - "emea-isr-cmo-1-0": [ - "4.31" - ], "emea-gbr-def-stan-05-138-2024": [ "2215" ], @@ -211,7 +206,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2215" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1055", "ISM-1603" ], diff --git a/docs/api/controls/IAC-02.3.json b/docs/api/controls/IAC-02.3.json index 8baaca5e..ebdaf255 100644 --- a/docs/api/controls/IAC-02.3.json +++ b/docs/api/controls/IAC-02.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify organizational Personal Identity Verification (PIV) credentials.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify organizational Personal Identity Verification (PIV) credentials. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-02.4.json b/docs/api/controls/IAC-02.4.json index 62b6b1ab..3cdca601 100644 --- a/docs/api/controls/IAC-02.4.json +++ b/docs/api/controls/IAC-02.4.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Out-of-Band Authentication (OOBA) under specific conditions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Out-of-Band Authentication (OOBA) under specific conditions. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-02.json b/docs/api/controls/IAC-02.json index be13875e..eddbe0a6 100644 --- a/docs/api/controls/IAC-02.json +++ b/docs/api/controls/IAC-02.json @@ -22,7 +22,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -109,7 +109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -177,7 +178,7 @@ "general-iso-27018-2025": [ "5.15" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -519,10 +520,10 @@ "IA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "IA-2", @@ -545,34 +546,18 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(a)" ], - "emea-deu-c5-2020": [ - "IDM-01", - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.31", - "4.34" - ], - "emea-sau-ecc-1-2018": [ - "2-2-3" + "emea-sau-otcc-1-2022": [ + "2-2-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-32" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.3" + "VII.B.TPC-32" ], - "emea-esp-decree-311-2022": [ - "24.3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2" ], "emea-gbr-caf-4-0": [ "B2.a" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" - ], "emea-gbr-def-stan-05-138-2024": [ "2218" ], @@ -585,7 +570,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2218" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0414", "ISM-0415", "ISM-1546" @@ -593,19 +578,9 @@ "apac-nzl-ism-3-9": [ "16.1.32.C.01" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ - "03.05.01.A" + "03.05.01.A", + "03.05.05.D" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-03.1.json b/docs/api/controls/IAC-03.1.json index 3905ec42..6a25deec 100644 --- a/docs/api/controls/IAC-03.1.json +++ b/docs/api/controls/IAC-03.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-03.2.json b/docs/api/controls/IAC-03.2.json index e54462ac..bc66c060 100644 --- a/docs/api/controls/IAC-03.2.json +++ b/docs/api/controls/IAC-03.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99,7 +99,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -158,10 +159,6 @@ "IA-8(CE-2)", "IA-8(CE-2).a", "IA-8(CE-2).b" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-03.3.json b/docs/api/controls/IAC-03.3.json index a68d8a80..aaf3f410 100644 --- a/docs/api/controls/IAC-03.3.json +++ b/docs/api/controls/IAC-03.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-03.4.json b/docs/api/controls/IAC-03.4.json index 65413d0f..d6621817 100644 --- a/docs/api/controls/IAC-03.4.json +++ b/docs/api/controls/IAC-03.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -55,7 +55,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-03.5.json b/docs/api/controls/IAC-03.5.json index 44b688f3..5c8006db 100644 --- a/docs/api/controls/IAC-03.5.json +++ b/docs/api/controls/IAC-03.5.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -51,7 +51,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-03.json b/docs/api/controls/IAC-03.json index 41c2480d..b435b849 100644 --- a/docs/api/controls/IAC-03.json +++ b/docs/api/controls/IAC-03.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -159,7 +160,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1053", "T1053.007", "T1059", @@ -222,6 +223,9 @@ "general-nist-800-171-r3": [ "03.05.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.05.01.a[03]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -279,43 +283,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-08" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.21" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-32" ], - "emea-sau-ecc-1-2018": [ - "2-2-3" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.3" - ], - "emea-esp-decree-311-2022": [ - "24.3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "emea-gbr-caf-4-0": [ "B2.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1583" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ "03.05.01.A" ] diff --git a/docs/api/controls/IAC-04.1.json b/docs/api/controls/IAC-04.1.json index 7f27f22d..43aa6510 100644 --- a/docs/api/controls/IAC-04.1.json +++ b/docs/api/controls/IAC-04.1.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure device identification and authentication is accurate by centrally-managing the joining of systems to the domain as part of the initial asset configuration management process.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -100,6 +101,12 @@ "general-nist-800-82-r3": [ "IA-03(04)" ], + "general-nist-800-172-r3": [ + "03.05.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.03E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-low": [ "IA-03(04)" ], diff --git a/docs/api/controls/IAC-04.2.json b/docs/api/controls/IAC-04.2.json index bb7027a6..96ed91e6 100644 --- a/docs/api/controls/IAC-04.2.json +++ b/docs/api/controls/IAC-04.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce cryptographic communications keys to prevent one key from being used to access multiple devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-04.json b/docs/api/controls/IAC-04.json index c38cb457..136af4df 100644 --- a/docs/api/controls/IAC-04.json +++ b/docs/api/controls/IAC-04.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -160,7 +161,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1530", "T1537", "T1552", @@ -227,12 +228,18 @@ "03.05.02" ], "general-nist-800-171a-r3": [ + "A.03.01.18.b", "A.03.05.02.ODP[01]", "A.03.05.02[01]", "A.03.05.02[02]" ], - "general-nist-800-172": [ - "3.5.1e" + "general-nist-800-172-r3": [ + "03.05.01E", + "03.05.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.01E", + "DS-A.03.05.03E" ], "general-nist-800-207": [ "NIST Tenet 2", @@ -304,20 +311,13 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(a)" ], - "emea-us-psd2-2015": [ - "25" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.33" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "emea-gbr-caf-4-0": [ "B2.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1603" ], "americas-can-itsp-10-171-2025": [ diff --git a/docs/api/controls/IAC-05.1.json b/docs/api/controls/IAC-05.1.json index 725769c4..ed934c5b 100644 --- a/docs/api/controls/IAC-05.1.json +++ b/docs/api/controls/IAC-05.1.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure external service providers provide current and accurate information for any third-party user with access to the organization's data or assets.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-05.2.json b/docs/api/controls/IAC-05.2.json index 5119f06d..618a4baa 100644 --- a/docs/api/controls/IAC-05.2.json +++ b/docs/api/controls/IAC-05.2.json @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -123,6 +124,9 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 4" ], diff --git a/docs/api/controls/IAC-05.json b/docs/api/controls/IAC-05.json index 7b34d129..b1ebc866 100644 --- a/docs/api/controls/IAC-05.json +++ b/docs/api/controls/IAC-05.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify and authenticate third-party Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -142,7 +143,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1036", "T1036.001", "T1036.005", @@ -191,6 +192,11 @@ "03.05.01.a", "03.05.02" ], + "general-nist-800-171a-r3": [ + "A.03.05.01.a[03]", + "A.03.05.02[01]", + "A.03.05.02[02]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -212,29 +218,19 @@ "usa-federal-irs-1075-2021": [ "IA-9" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" + "emea-sau-cscc-1-2019": [ + "2-2-1-7" ], - "emea-isr-cmo-1-0": [ - "4.2" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], - "emea-sau-ecc-1-2018": [ - "2-2-3" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP49", "HML49" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP41" ], - "apac-sgp-mas-trm-2021": [ - "9.1.8" - ], "americas-can-itsp-10-171-2025": [ "03.05.01.A", "03.05.02" diff --git a/docs/api/controls/IAC-06.1.json b/docs/api/controls/IAC-06.1.json index a73222cd..3d521d83 100644 --- a/docs/api/controls/IAC-06.1.json +++ b/docs/api/controls/IAC-06.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -183,6 +184,9 @@ "3.5.3[a]", "3.5.3[c]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -264,21 +268,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" ], - "emea-isr-cmo-1-0": [ - "4.29" - ], "emea-sau-cscc-1-2019": [ "2-2-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-5", - "TPC-37" - ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "16.7.42.C.02", + "16.7.42.C.03" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.6(a)" diff --git a/docs/api/controls/IAC-06.2.json b/docs/api/controls/IAC-06.2.json index 7c3e9222..f5c7eb5e 100644 --- a/docs/api/controls/IAC-06.2.json +++ b/docs/api/controls/IAC-06.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -170,6 +171,9 @@ "general-nist-800-171a": [ "3.5.3[d]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[02]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -240,19 +244,15 @@ "emea-sau-cscc-1-2019": [ "2-2-1-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-5", - "TPC-45" - ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML3-P3" ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "16.7.42.C.03" + ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.6(b)" ], "americas-can-itsp-10-171-2025": [ "03.05.03" diff --git a/docs/api/controls/IAC-06.3.json b/docs/api/controls/IAC-06.3.json index b7e3e8b7..7258fe05 100644 --- a/docs/api/controls/IAC-06.3.json +++ b/docs/api/controls/IAC-06.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -170,6 +171,9 @@ "3.5.3[a]", "3.5.3[b]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -236,28 +240,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" ], - "emea-isr-cmo-1-0": [ - "4.30" + "emea-deu-c5-2020": [ + "RB-15-DOAR" ], "emea-sau-cscc-1-2019": [ "2-2-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-37" - ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML3-P3" ], - "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.6(a)" - ], "americas-can-itsp-10-171-2025": [ "03.05.03" ] diff --git a/docs/api/controls/IAC-06.4.json b/docs/api/controls/IAC-06.4.json index bc70b1b3..976923dd 100644 --- a/docs/api/controls/IAC-06.4.json +++ b/docs/api/controls/IAC-06.4.json @@ -3,7 +3,7 @@ "title": "Out-of-Band Multi-Factor Authentication", "family": "IAC", "description": "Mechanisms exist to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed.", - "scf_question": "Does the organization implements Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is securely provided by a device separate from the system gaining access?", + "scf_question": "Does the organization implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -162,6 +163,9 @@ "general-nist-800-160-vol-2-r1": [ "IA-02(06)" ], + "general-nist-800-171-r3": [ + "03.05.03" + ], "general-nist-800-171a-r3": [ "A.03.05.03[01]", "A.03.05.03[02]" @@ -226,6 +230,9 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" + ], + "americas-can-itsp-10-171-2025": [ + "03.05.03" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-06.5.json b/docs/api/controls/IAC-06.5.json index c2b595ec..28161d06 100644 --- a/docs/api/controls/IAC-06.5.json +++ b/docs/api/controls/IAC-06.5.json @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-06.json b/docs/api/controls/IAC-06.json index f4669d27..b74bfcec 100644 --- a/docs/api/controls/IAC-06.json +++ b/docs/api/controls/IAC-06.json @@ -2,8 +2,8 @@ "control_id": "IAC-06", "title": "Multi-Factor Authentication (MFA)", "family": "IAC", - "description": "Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:\n(1) Remote network access; \n(2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n(3) Non-console access to critical TAAS that store, transmit and/or process sensitive/regulated data.", - "scf_question": "Does the organization use automated mechanisms to enforce Multi-Factor Authentication (MFA) for:\n (1) Remote network access; \n (2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n (3) Non-console access to critical TAAS that store, transmit and/or process sensitive/regulated data?", + "description": "Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:\n(1) Remote network access; \n(2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n(3) Non-console access to critical TAAS that store, transmit and/or process sensitive and/or regulated data.", + "scf_question": "Does the organization use automated mechanisms to enforce Multi-Factor Authentication (MFA) for:\n (1) Remote network access; \n (2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n (3) Non-console access to critical TAAS that store, transmit and/or process sensitive and/or regulated data?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -106,7 +106,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -255,9 +256,6 @@ "8.4.3", "8.5.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "4.2" ], @@ -310,6 +308,9 @@ "IA-02(01)", "IA-02(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(4)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(5)" ], @@ -355,12 +356,9 @@ "11.3.2(a)", "11.7.1" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-isr-cmo-1-0": [ - "4.21", - "4.32" + "emea-deu-c5-2020": [ + "RB-15-DOAR", + "IDM-08-BP3" ], "emea-sau-cscc-1-2019": [ "2-2-1-3", @@ -372,14 +370,14 @@ "2-15-3-5" ], "emea-sau-sacs-002-2022": [ - "TPC-4", - "TPC-5", - "TPC-37", - "TPC-44", - "TPC-45" + "VII.A.TPC-4", + "VII.A.TPC-5", + "VII.B.TPC-37", + "VII.B.TPC-44", + "VII.B.TPC-45" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "4-BP4" ], "emea-gbr-def-stan-05-138-2024": [ "2201", @@ -405,7 +403,7 @@ "ML2-P3", "ML3-P3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0974", "ISM-1173", "ISM-1401", @@ -419,20 +417,39 @@ "ISM-1681", "ISM-1682", "ISM-1683", - "ISM-1685" + "ISM-1685", + "ISM-1872", + "ISM-1873", + "ISM-1874", + "ISM-1892", + "ISM-1893", + "ISM-1894", + "ISM-2011" + ], + "apac-aus-cop-sitc-2020": [ + "1" ], "apac-ind-sebi-2024": [ "PR.AA.S7" ], + "apac-mys-bnm-rmit-2025": [ + "10.55" + ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01", + "16.1.29.C.02", + "16.4.37.C.02", + "16.7.42.C.01", + "16.7.42.C.04", + "16.7.42.C.05", + "16.7.42.C.06", + "16.7.42.C.07", + "16.7.43.C.01", + "16.7.44.C.01", "23.3.19.C.01", "23.3.19.C.02" ], "apac-sgp-cyber-hygiene-practice-2019": [ + "4.6", "4.6(b)" ], "apac-sgp-mas-trm-2021": [ @@ -441,6 +458,9 @@ "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.05.03", "03.07.05.B" diff --git a/docs/api/controls/IAC-07.1.json b/docs/api/controls/IAC-07.1.json index cbf05ab5..60d89214 100644 --- a/docs/api/controls/IAC-07.1.json +++ b/docs/api/controls/IAC-07.1.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127,6 +128,14 @@ "03.05.05.a", "03.09.02.b.02" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -171,10 +180,10 @@ "ACCESS-2h" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "emea-eu-nis2-annex-2024": [ "1.2.6" @@ -184,20 +193,20 @@ "6.5", "6.6" ], - "emea-deu-c5-2020": [ - "PS-04", - "PSS-08" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], "emea-sau-otcc-1-2022": [ - "2-2-1-10" + "2-2-1-11" ], - "apac-aus-ism-2024-june": [ - "ISM-0430" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], - "apac-chn-data-security-law-2021": [ - "27" + "apac-aus-ism-2026-march": [ + "ISM-0430" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], diff --git a/docs/api/controls/IAC-07.2.json b/docs/api/controls/IAC-07.2.json index bd9a6a5d..4f187427 100644 --- a/docs/api/controls/IAC-07.2.json +++ b/docs/api/controls/IAC-07.2.json @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -187,6 +188,11 @@ "03.09.02.a.01", "03.09.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -236,10 +242,10 @@ "AC-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "AC-2" @@ -264,14 +270,20 @@ "6.5", "6.6" ], + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" + ], "emea-sau-otcc-1-2022": [ - "2-2-1-10", "2-2-1-11" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "apac-aus-ism-2026-march": [ "ISM-0430" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], diff --git a/docs/api/controls/IAC-07.json b/docs/api/controls/IAC-07.json index a1bcf9c6..b05dd5bf 100644 --- a/docs/api/controls/IAC-07.json +++ b/docs/api/controls/IAC-07.json @@ -22,7 +22,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize a formal user registration and de-registration process that governs the assignment of access rights.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize a formal user registration and de-registration process that governs the assignment of access rights. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -111,7 +111,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -182,6 +183,7 @@ "IA-12(04)" ], "general-nist-800-171-r3": [ + "03.01.01.b", "03.01.01.g.01", "03.01.01.g.02", "03.01.01.g.03", @@ -195,7 +197,13 @@ "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.05.05.a" + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -258,17 +266,23 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-12(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(7)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 6.1.1", "CIP-004-7 6.1.2", "CIP-004-7 6.3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(e)" + ], "emea-eu-nis2-annex-2024": [ "11.2.1", "11.2.2(a)", @@ -281,15 +295,33 @@ "6.6" ], "emea-deu-c5-2020": [ - "IDM-01", - "IDM-02", - "PSS-09" + "IDM-01-BP1", + "IDM-01-BP5", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-04", + "IDM-05" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" + ], + "emea-sau-ecc-1-2018": [ + "1-9-5" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.1 [OP.ACC.1]" + "emea-sau-otcc-1-2022": [ + "2-2-1-10", + "2-2-1-11" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-6" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1", + "op.acc.4", + "op.acc.5" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "4-BP6" ], "emea-gbr-def-stan-05-138-2024": [ "2702" @@ -303,7 +335,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2702" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "apac-jpn-ismap": [ @@ -316,7 +348,7 @@ "9.2.6", "9.2.6.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -327,7 +359,11 @@ "apac-nzl-ism-3-9": [ "23.3.20.C.01" ], + "apac-sgp-mas-trm-2021": [ + "9.1.2" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.B", "03.01.01.G.01", "03.01.01.G.02", "03.01.01.G.03", diff --git a/docs/api/controls/IAC-08.json b/docs/api/controls/IAC-08.json index c42b399c..ac59267e 100644 --- a/docs/api/controls/IAC-08.json +++ b/docs/api/controls/IAC-08.json @@ -23,7 +23,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Role-Based Access Control (RBAC) for TAASD to restrict access to individuals assigned specific roles with legitimate business needs.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -108,7 +109,7 @@ ], "general-cis-csc-8-1": [ "3.3", - "6.0", + "6", "6.8" ], "general-cis-csc-8-1-ig1": [ @@ -211,17 +212,28 @@ "3.1.3[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.01", "A.03.01.01.c.02", "A.03.01.01.c.03", + "A.03.01.02[01]", + "A.03.01.02[02]", "A.03.01.05.ODP[01]", "A.03.01.05.ODP[02]", "A.03.01.05.b[01]", "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.12.a[02]", + "A.03.03.08.b", "A.03.04.05[04]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.07.06.a" ], - "general-nist-800-172": [ - "3.1.2e" + "general-nist-800-172-r3": [ + "03.01.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.11E.a", + "DS-A.03.01.11E.b" ], "general-nist-800-207": [ "NIST Tenet 3", @@ -278,9 +290,6 @@ "7.3.2", "7.3.3" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.2", "5.1" @@ -336,20 +345,20 @@ "155.260(a)(4)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)", - "164.514(d)(2)(i)(A)", - "164.514(d)(2)(i)(B)", - "164.514(d)(2)(ii)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)", + "§ 164.514(d)(2)(i)(A)", + "§ 164.514(d)(2)(i)(B)", + "§ 164.514(d)(2)(ii)", + "§ 164.530(c)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "2.D.6" @@ -385,7 +394,7 @@ "2447(c)(2)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.2.(32)" + "3.4.2.32" ], "emea-eu-gdpr-2016": [ "Article 32.4" @@ -395,43 +404,31 @@ "11.2.2(d)", "11.4.1" ], - "emea-deu-bsrit-2017": [ - "6.2" + "emea-deu-fdpa-2017": [ + "2.1.2.27(1)", + "3.2.48(2)4" ], "emea-deu-c5-2020": [ - "PSS-08", - "PSS-11" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.8", - "4.9", - "4.10", - "4.11", - "4.20", - "12.28", - "12.29" + "RB-15", + "IDM-01", + "IDM-01-BP3", + "BEI-12" ], "emea-sau-cgiot-2024": [ "2-2-1" ], "emea-sau-ecc-1-2018": [ - "2-2-3-3" + "2-2-3-3", + "2-6-3-2" ], "emea-sau-sacs-002-2022": [ - "TPC-39" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 17" + "VII.B.TPC-34" ], "emea-esp-decree-311-2022": [ - "17" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.4 [OP.ACC.4]" + "Article 17" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2" ], "emea-gbr-def-stan-05-138-2024": [ "2200", @@ -458,11 +455,11 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-1746" - ], - "apac-chn-data-security-law-2021": [ - "27" + "apac-aus-ism-2026-march": [ + "ISM-1746", + "ISM-1852", + "ISM-2092", + "ISM-2093" ], "apac-ind-sebi-2024": [ "PR.AA.S3" @@ -479,15 +476,15 @@ "9.4.1.6", "9.4.1.7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.56" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP40", "HHSP42", "HML40", "HML42" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS07" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP04", "HSUP37" @@ -499,8 +496,13 @@ "16.2.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "9.1.7", - "11.1.6" + "9.1.7" + ], + "americas-arg-ppd-2018": [ + "B.1.2-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01", diff --git a/docs/api/controls/IAC-09.1.json b/docs/api/controls/IAC-09.1.json index 2dcf9abf..78769249 100644 --- a/docs/api/controls/IAC-09.1.json +++ b/docs/api/controls/IAC-09.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure proper user identification management for non-consumer users and administrators.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure proper user identification management for non-consumer users and administrators. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -146,6 +147,10 @@ "general-nist-800-171-r3": [ "03.05.05.b" ], + "general-nist-800-171a-r3": [ + "A.03.05.05.b[01]", + "A.03.05.05.b[02]" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -195,11 +200,8 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(b)" ], - "emea-isr-cmo-1-0": [ - "12.15" - ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "americas-can-itsp-10-171-2025": [ "03.05.05.B" diff --git a/docs/api/controls/IAC-09.2.json b/docs/api/controls/IAC-09.2.json index 737c9d05..131988d4 100644 --- a/docs/api/controls/IAC-09.2.json +++ b/docs/api/controls/IAC-09.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify contractors and other third-party users through unique username characteristics.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify contractors and other third-party users through unique username characteristics. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -156,17 +157,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-04 (04)" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ "03.05.05.D" ] diff --git a/docs/api/controls/IAC-09.3.json b/docs/api/controls/IAC-09.3.json index 9549d64c..4721cebf 100644 --- a/docs/api/controls/IAC-09.3.json +++ b/docs/api/controls/IAC-09.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to dynamically manage usernames and system identifiers.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to dynamically manage usernames and system identifiers. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-09.4.json b/docs/api/controls/IAC-09.4.json index 04ac8534..6c395364 100644 --- a/docs/api/controls/IAC-09.4.json +++ b/docs/api/controls/IAC-09.4.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to coordinate username identifiers with external organizations for cross-organization management of identifiers.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to coordinate username identifiers with external organizations for cross-organization management of identifiers. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -114,6 +115,9 @@ ], "general-nist-800-161-r1-level-3": [ "IA-4(6)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-09.5.json b/docs/api/controls/IAC-09.5.json index cfd55088..131f38ba 100644 --- a/docs/api/controls/IAC-09.5.json +++ b/docs/api/controls/IAC-09.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely manage privileged accounts to identify the account as a privileged user or service.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -122,6 +123,10 @@ "general-nist-800-171a": [ "3.1.5[a]" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b", + "A.03.05.05.d" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -137,12 +142,6 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05(08)" ], - "emea-deu-c5-2020": [ - "IDM-02" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" - ], "americas-can-itsp-10-171-2025": [ "03.01.07.B", "03.05.05.D" diff --git a/docs/api/controls/IAC-09.6.json b/docs/api/controls/IAC-09.6.json index 362bee2c..308fc50d 100644 --- a/docs/api/controls/IAC-09.6.json +++ b/docs/api/controls/IAC-09.6.json @@ -53,7 +53,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -73,29 +74,8 @@ "general-owasp-top-10-2025": [ "A01:2025" ], - "emea-zaf-popia-2013": [ - "6.1.b" - ], - "apac-aus-privacy-principles-2026": [ - "APP 2" - ], - "apac-jpn-ppi-2020": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" + "apac-jpn-appi-2020": [ + "IV.2.35-2(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-09.json b/docs/api/controls/IAC-09.json index 4f6b9153..e0a85374 100644 --- a/docs/api/controls/IAC-09.json +++ b/docs/api/controls/IAC-09.json @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -138,7 +139,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.005", "T1003.006", @@ -237,7 +238,8 @@ "A.03.05.05.ODP[01]", "A.03.05.05.b[01]", "A.03.05.05.b[02]", - "A.03.05.05.c" + "A.03.05.05.c", + "A.03.05.05.d" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -287,10 +289,10 @@ "IA-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-irs-1075-2021": [ "IA-4", @@ -315,11 +317,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-04" ], - "emea-deu-c5-2020": [ - "IDM-01" - ], - "emea-isr-cmo-1-0": [ - "12.15" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "americas-can-itsp-10-171-2025": [ "03.05.05.B", diff --git a/docs/api/controls/IAC-10.1.json b/docs/api/controls/IAC-10.1.json index 570aa278..7155b1bf 100644 --- a/docs/api/controls/IAC-10.1.json +++ b/docs/api/controls/IAC-10.1.json @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -193,10 +194,8 @@ "03.05.07.e", "03.05.07.f", "03.05.12.b", - "03.05.12.c", "03.05.12.d", - "03.05.12.e", - "03.05.12.f" + "03.05.12.e" ], "general-nist-800-171a": [ "3.5.7[a]", @@ -206,7 +205,17 @@ ], "general-nist-800-171a-r3": [ "A.03.05.07.ODP[02]", - "A.03.05.07.f" + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.b", + "A.03.05.12.d", + "A.03.05.12.e" + ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.02E.ODP[02]" ], "general-owasp-top-10-2025": [ "A07:2025" @@ -302,6 +311,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(3)" + ], "usa-federal-irs-1075-2021": [ "IA-5(CE-1)", "IA-5(CE-1).f", @@ -352,47 +364,33 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (01)" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "IDM-09", - "PSS-07" - ], - "emea-isr-cmo-1-0": [ - "4.35", - "12.15", - "12.16" - ], "emea-sau-cscc-1-2019": [ "2-2-1-5" ], "emea-sau-cgiot-2024": [ "2-2-2" ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" - ], "emea-sau-otcc-1-2022": [ "2-2-1-8" ], "emea-sau-sacs-002-2022": [ - "TPC-2" + "VII.A.TPC-2" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0417", "ISM-0421", "ISM-0422", "ISM-1557", "ISM-1558", "ISM-1596", - "ISM-1795" + "ISM-1795", + "ISM-1980", + "ISM-2079", + "ISM-2080", + "ISM-2081" ], "apac-aus-cop-sitc-2020": [ - "Principle 1" + "1" ], "apac-jpn-ismap": [ "9.3.1.4", @@ -408,6 +406,9 @@ "9.4.3.9" ], "apac-nzl-ism-3-9": [ + "16.1.29.C.01", + "16.1.31.C.02", + "16.1.31.C.07", "16.1.35.C.01", "16.1.35.C.02", "16.1.42.C.01", @@ -416,14 +417,15 @@ "apac-sgp-mas-trm-2021": [ "9.1.4" ], + "americas-arg-ppd-2018": [ + "B.2.3-7" + ], "americas-can-itsp-10-171-2025": [ "03.05.07.E", "03.05.07.F", "03.05.12.B", - "03.05.12.C", "03.05.12.D", - "03.05.12.E", - "03.05.12.F" + "03.05.12.E" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-10.10.json b/docs/api/controls/IAC-10.10.json index 58ce9401..50f6edd6 100644 --- a/docs/api/controls/IAC-10.10.json +++ b/docs/api/controls/IAC-10.10.json @@ -83,7 +83,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -102,6 +103,12 @@ "general-nist-800-82-r3": [ "IA-05(13)" ], + "general-nist-800-172-r3": [ + "03.05.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.05E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-high": [ "IA-05(13)" ] diff --git a/docs/api/controls/IAC-10.11.json b/docs/api/controls/IAC-10.11.json index 74556779..b6a22907 100644 --- a/docs/api/controls/IAC-10.11.json +++ b/docs/api/controls/IAC-10.11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ Password managers are provided, but decentralized and not actively governed.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect and store passwords via a password manager tool.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -126,10 +127,16 @@ "A.03.05.07.a[01]", "A.03.05.07.a[02]", "A.03.05.07.a[03]", - "A.03.05.07.b" + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.f" ], - "general-nist-800-172": [ - "3.5.2e" + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.02E.a" ], "general-swift-cscf-2025": [ "5.4" @@ -146,11 +153,9 @@ "emea-sau-otcc-1-2022": [ "2-2-1-9" ], - "emea-sau-sacs-002-2022": [ - "TPC-3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2212" @@ -164,7 +169,8 @@ "apac-nzl-ism-3-9": [ "14.3.13.C.01", "14.3.13.C.02", - "14.3.13.C.03" + "14.3.13.C.03", + "16.1.37.C.02" ], "americas-can-itsp-10-171-2025": [ "03.05.07.A", diff --git a/docs/api/controls/IAC-10.12.json b/docs/api/controls/IAC-10.12.json index 5005facb..179a1245 100644 --- a/docs/api/controls/IAC-10.12.json +++ b/docs/api/controls/IAC-10.12.json @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-10.13.json b/docs/api/controls/IAC-10.13.json index e107e6a5..52381903 100644 --- a/docs/api/controls/IAC-10.13.json +++ b/docs/api/controls/IAC-10.13.json @@ -101,7 +101,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-10.14.json b/docs/api/controls/IAC-10.14.json index 71193590..e0f9a16f 100644 --- a/docs/api/controls/IAC-10.14.json +++ b/docs/api/controls/IAC-10.14.json @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-10.2.json b/docs/api/controls/IAC-10.2.json index dcc4a36d..13069461 100644 --- a/docs/api/controls/IAC-10.2.json +++ b/docs/api/controls/IAC-10.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically validate certificates by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information for PKI-based authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -99,7 +99,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -222,13 +223,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (02)" - ], - "emea-deu-c5-2020": [ - "IDM-09" - ], - "emea-isr-cmo-1-0": [ - "12.15", - "12.16" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-10.3.json b/docs/api/controls/IAC-10.3.json index 6122ee55..731b6d96 100644 --- a/docs/api/controls/IAC-10.3.json +++ b/docs/api/controls/IAC-10.3.json @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -128,6 +129,9 @@ "general-nist-800-171-r3": [ "03.05.12.a" ], + "general-nist-800-171a-r3": [ + "A.03.05.12.a" + ], "usa-federal-gsa-fedramp-5-low": [ "IA-12(04)" ], diff --git a/docs/api/controls/IAC-10.4.json b/docs/api/controls/IAC-10.4.json index cbf2301d..b63bfa4e 100644 --- a/docs/api/controls/IAC-10.4.json +++ b/docs/api/controls/IAC-10.4.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Password managers are not governed.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -87,7 +87,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -147,6 +148,12 @@ "A.03.05.07.a[03]", "A.03.05.07.b" ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.02E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -185,12 +192,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (01)" ], - "emea-us-psd2-2015": [ - "19" - ], - "emea-deu-c5-2020": [ - "PSS-07" - ], "emea-gbr-def-stan-05-138-2024": [ "2213" ], @@ -203,11 +204,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2213" ], + "apac-aus-ism-2026-march": [ + "ISM-2078" + ], "apac-nzl-ism-3-9": [ "16.1.41.C.01", - "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04" + "16.1.41.C.02" ], "americas-can-itsp-10-171-2025": [ "03.05.07.A", diff --git a/docs/api/controls/IAC-10.5.json b/docs/api/controls/IAC-10.5.json index 8627a87f..8ab2441d 100644 --- a/docs/api/controls/IAC-10.5.json +++ b/docs/api/controls/IAC-10.5.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Password managers are not governed.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -155,6 +156,12 @@ "A.03.05.12.f[01]", "A.03.05.12.f[02]" ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.02E.b" + ], "general-pci-dss-4-0-1": [ "8.3.11" ], @@ -219,27 +226,17 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(b)" ], - "emea-us-psd2-2015": [ - "19", - "22" - ], "emea-deu-c5-2020": [ - "IDM-08", - "PSS-07" - ], - "emea-isr-cmo-1-0": [ - "4.37" + "IDM-07", + "IDM-08" ], "emea-sau-cscc-1-2019": [ "2-2-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" + "VII.A.TPC-3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0418", "ISM-1402", "ISM-1590", @@ -258,6 +255,7 @@ "9.3.1.7" ], "apac-nzl-ism-3-9": [ + "16.1.34.C.02", "16.1.36.C.01", "16.1.37.C.01", "16.1.38.C.01" diff --git a/docs/api/controls/IAC-10.6.json b/docs/api/controls/IAC-10.6.json index 5e2cc2dc..a7438f72 100644 --- a/docs/api/controls/IAC-10.6.json +++ b/docs/api/controls/IAC-10.6.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -116,6 +117,15 @@ "general-nist-800-171-r3": [ "03.05.07.d" ], + "general-nist-800-171a-r3": [ + "A.03.05.07.d" + ], + "general-nist-800-172-r3": [ + "03.05.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.04E" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -152,8 +162,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (07)" ], - "emea-sau-sacs-002-2022": [ - "TPC-62" + "apac-aus-cop-sitc-2020": [ + "4" ], "apac-nzl-ism-3-9": [ "16.1.36.C.01" diff --git a/docs/api/controls/IAC-10.7.json b/docs/api/controls/IAC-10.7.json index 134a75f4..3621144d 100644 --- a/docs/api/controls/IAC-10.7.json +++ b/docs/api/controls/IAC-10.7.json @@ -83,7 +83,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-10.8.json b/docs/api/controls/IAC-10.8.json index 2d38198c..c6c10d28 100644 --- a/docs/api/controls/IAC-10.8.json +++ b/docs/api/controls/IAC-10.8.json @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -201,6 +202,10 @@ "03.05.07.e", "03.05.12.d" ], + "general-nist-800-171a-r3": [ + "A.03.05.07.e", + "A.03.05.12.d" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -263,6 +268,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(2)" + ], "usa-federal-irs-1075-2021": [ "IA-5", "IA-5(CE-5)" @@ -288,12 +296,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05" ], + "emea-sau-cscc-1-2019": [ + "2-3-1-7" + ], "emea-sau-cgiot-2024": [ "2-2-2" ], "emea-sau-otcc-1-2022": [ "2-2-1-3" ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP2" + ], "emea-gbr-def-stan-05-138-2024": [ "2211" ], @@ -306,12 +320,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2211" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1304", - "ISM-1806" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 1" + "ISM-1806", + "ISM-2044" ], "americas-can-itsp-10-171-2025": [ "03.05.07.E", diff --git a/docs/api/controls/IAC-10.9.json b/docs/api/controls/IAC-10.9.json index 427c3533..4694d6d2 100644 --- a/docs/api/controls/IAC-10.9.json +++ b/docs/api/controls/IAC-10.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement security safeguards to manage the risk of compromise due to individuals having accounts on multiple Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-10.json b/docs/api/controls/IAC-10.json index 7922a66a..ef117c72 100644 --- a/docs/api/controls/IAC-10.json +++ b/docs/api/controls/IAC-10.json @@ -20,7 +20,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to:\n(1) Securely manage authenticators for users and devices; and\n(2) Ensure the strength of authentication is appropriate to the classification of the data being accessed.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -159,7 +160,7 @@ "5.17", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -307,6 +308,12 @@ "3.5.9" ], "general-nist-800-171a-r3": [ + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", "A.03.05.12.ODP[01]", "A.03.05.12.ODP[02]", "A.03.05.12.a", @@ -479,39 +486,17 @@ "11.6.2(a)", "11.7.2" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "IDM-08" - ], - "emea-isr-cmo-1-0": [ - "4.35", - "12.15", - "12.16" - ], - "emea-sau-cscc-1-2019": [ - "2-2-1-6" - ], "emea-sau-cgiot-2024": [ "2-2-2" ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-8" - ], "emea-sau-sacs-002-2022": [ - "TPC-3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" + "VII.B.TPC-62" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1227", "ISM-1593", "ISM-1594", @@ -534,12 +519,11 @@ "14.3.13.C.01", "14.3.13.C.02", "14.3.13.C.03", + "16.1.36.C.02", + "16.1.36.C.03", "16.1.40.C.01", - "16.1.40.C.02", "16.1.41.C.01", "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04", "16.1.42.C.01" ], "americas-can-itsp-10-171-2025": [ diff --git a/docs/api/controls/IAC-11.json b/docs/api/controls/IAC-11.json index 41a3d5f9..df3b8975 100644 --- a/docs/api/controls/IAC-11.json +++ b/docs/api/controls/IAC-11.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to obscure the feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to obscure the feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -116,7 +117,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1021.005", "T1530", @@ -192,9 +193,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-06" ], - "emea-isr-cmo-1-0": [ - "4.36" - ], "emea-gbr-def-stan-05-138-2024": [ "2419", "2420" diff --git a/docs/api/controls/IAC-12.1.json b/docs/api/controls/IAC-12.1.json index 3c2105e3..ee52b276 100644 --- a/docs/api/controls/IAC-12.1.json +++ b/docs/api/controls/IAC-12.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Hardware Security Modules (HSM) to protect authenticators on which the component relies.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Hardware Security Modules (HSM) to protect authenticators on which the component relies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81,7 +81,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-12.json b/docs/api/controls/IAC-12.json index d12bf243..9d432201 100644 --- a/docs/api/controls/IAC-12.json +++ b/docs/api/controls/IAC-12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure cryptographic modules adhere to applicable statutory, regulatory and contractual requirements for security strength.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -108,7 +109,7 @@ "general-govramp-high": [ "IA-07" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1495", "T1542", @@ -186,9 +187,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-07" - ], - "emea-isr-cmo-1-0": [ - "4.37" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-13.1.json b/docs/api/controls/IAC-13.1.json index 1979ebe4..dea35151 100644 --- a/docs/api/controls/IAC-13.1.json +++ b/docs/api/controls/IAC-13.1.json @@ -3,7 +3,7 @@ "title": "Single Sign-On (SSO) Transparent Authentication", "family": "IAC", "description": "Mechanisms exist to provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to the organization's Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization provide a Single Sign-On (SSO) capability to its Technology Assets, Applications and/or Services (TAAS)?", + "scf_question": "Does the organization provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to its Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to the organization's Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-13.2.json b/docs/api/controls/IAC-13.2.json index 5cd3767a..a5ec6c29 100644 --- a/docs/api/controls/IAC-13.2.json +++ b/docs/api/controls/IAC-13.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to federate credentials to allow cross-organization authentication of individuals and devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-13.3.json b/docs/api/controls/IAC-13.3.json index 332e1505..861aafc8 100644 --- a/docs/api/controls/IAC-13.3.json +++ b/docs/api/controls/IAC-13.3.json @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-13.json b/docs/api/controls/IAC-13.json index 1c4728f4..36d1c67c 100644 --- a/docs/api/controls/IAC-13.json +++ b/docs/api/controls/IAC-13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to allow individuals to utilize alternative methods of authentication under specific circumstances or situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-14.json b/docs/api/controls/IAC-14.json index 64a8a836..ede8ff23 100644 --- a/docs/api/controls/IAC-14.json +++ b/docs/api/controls/IAC-14.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,11 +88,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1110", "T1110.001", "T1110.002", diff --git a/docs/api/controls/IAC-15.1.json b/docs/api/controls/IAC-15.1.json index 5fd4b170..c45869e2 100644 --- a/docs/api/controls/IAC-15.1.json +++ b/docs/api/controls/IAC-15.1.json @@ -3,7 +3,7 @@ "title": "Automated System Account Management (Directory Services)", "family": "IAC", "description": "Automated mechanisms exist to support the management of system accounts (e.g., directory services).", - "scf_question": "Does the organization use automated mechanisms to support the management of system accounts?", + "scf_question": "Does the organization use automated mechanisms to support the management of system accounts (e.g., directory services)?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically support the management of system accounts (e.g., directory services).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically support the management of system accounts (e.g., directory services). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,14 +87,15 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { "general-cis-csc-8-1": [ - "5.0", + "5", "5.6", - "6.0" + "6" ], "general-cis-csc-8-1-ig2": [ "5.6" @@ -160,6 +161,7 @@ "3.5.2" ], "general-nist-800-171-r3": [ + "03.01.01.d.01", "03.05.05.b", "03.05.05.c", "03.05.05.d", @@ -171,6 +173,33 @@ "03.05.12.e", "03.05.12.f" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.05.05.b[01]", + "A.03.05.05.b[02]", + "A.03.05.05.c", + "A.03.05.05.d", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.d", + "A.03.05.12.e", + "A.03.05.12.f[01]", + "A.03.05.12.f[02]" + ], + "general-nist-800-172-r3": [ + "03.01.07E", + "03.01.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]", + "DS-A.03.01.11E.a" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -209,6 +238,20 @@ "AC-2-IS.3", "AC-2(1)" ], + "emea-deu-c5-2020": [ + "IDM-03-BP2", + "IDM-08-BP2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP6" + ], "emea-gbr-def-stan-05-138-2024": [ "2209", "2218" @@ -223,13 +266,20 @@ "2209", "2218" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1649" ], "apac-jpn-ismap": [ "9.2.2.5" ], + "apac-sgp-mas-trm-2021": [ + "9.2.2" + ], + "americas-arg-ppd-2018": [ + "B.2.3-2" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.D.01", "03.05.05.B", "03.05.05.C", "03.05.05.D", diff --git a/docs/api/controls/IAC-15.10.json b/docs/api/controls/IAC-15.10.json new file mode 100644 index 00000000..7b949463 --- /dev/null +++ b/docs/api/controls/IAC-15.10.json @@ -0,0 +1,97 @@ +{ + "control_id": "IAC-15.10", + "title": "Account Separation Between Infrastructure Environments", + "family": "IAC", + "description": "Mechanisms exist to separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "scf_question": "Does the organization separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Separate user accounts for production vs development environments\n∙ Role-based access restricting cross-environment access", + "small": "∙ Separate accounts per environment (dev, staging, prod)\n∙ Access restrictions preventing cross-environment access", + "medium": "∙ Separate cloud accounts or tenants per environment\n∙ AWS Organizations or Azure Management Groups for account separation\n∙ Privileged Access Management (PAM)", + "large": "∙ AWS Organizations, Azure Landing Zones, or GCP Organization policies for environment separation\n∙ PAM solution for privileged environment access\n∙ Zero Trust access between environments", + "enterprise": "∙ Enterprise cloud account separation via AWS Organizations or Azure Entra Tenants\n∙ Enterprise PAM (e.g., CyberArk, BeyondTrust)\n∙ Zero Trust architecture for cross-environment access\n∙ Automated account lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - (33 CFR Part 101 Subpart F)", + "family_name": "Identification & Authentication", + "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/IAC-15.2.json b/docs/api/controls/IAC-15.2.json index cfbedec0..237edde5 100644 --- a/docs/api/controls/IAC-15.2.json +++ b/docs/api/controls/IAC-15.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable or remove temporary and emergency accounts after an organization-defined time period for each type of account.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable or remove temporary and emergency accounts after an organization-defined time period for each type of account. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85,7 +85,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -135,10 +136,10 @@ "AC-02(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "AC-2(CE-2)" @@ -146,12 +147,9 @@ "usa-federal-cms-marse-2-0": [ "AC-2(2)" ], - "emea-deu-c5-2020": [ - "IDM-04", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.4" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-15.3.json b/docs/api/controls/IAC-15.3.json index 6f7a290f..b23f2c7e 100644 --- a/docs/api/controls/IAC-15.3.json +++ b/docs/api/controls/IAC-15.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable inactive accounts after an organization-defined time period.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable inactive accounts after an organization-defined time period. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,7 +87,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -203,20 +204,23 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-02 (03)" ], - "emea-deu-c5-2020": [ - "IDM-03" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], - "emea-isr-cmo-1-0": [ - "4.5" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP3" ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1404", "ISM-1648" ], + "americas-arg-ppd-2018": [ + "B.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.F.02" ] diff --git a/docs/api/controls/IAC-15.4.json b/docs/api/controls/IAC-15.4.json index c2d36aa0..4f6fd825 100644 --- a/docs/api/controls/IAC-15.4.json +++ b/docs/api/controls/IAC-15.4.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically audit account creation, modification, enabling, disabling and removal actions and notify organization-defined personnel or roles.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically audit account creation, modification, enabling, disabling and removal actions and notify organization-defined personnel or roles. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -83,7 +83,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -114,6 +115,16 @@ "general-nist-800-82-r3-high": [ "AC-02(04)" ], + "general-nist-800-172-r3": [ + "03.01.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]" + ], "usa-federal-fbi-cjis-6-0": [ "AC-2(4)" ], diff --git a/docs/api/controls/IAC-15.5.json b/docs/api/controls/IAC-15.5.json index 14d041b8..65912980 100644 --- a/docs/api/controls/IAC-15.5.json +++ b/docs/api/controls/IAC-15.5.json @@ -22,7 +22,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to authorize the use of shared/group accounts only under certain organization-defined conditions.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -124,6 +125,9 @@ "general-nist-800-171-r3": [ "03.01.01.c.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.c.01" + ], "general-pci-dss-4-0-1": [ "8.2.2" ], @@ -171,14 +175,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-02 (09)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(b)" + ], "emea-eu-nis2-annex-2024": [ "11.5.3" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" + ], "apac-nzl-ism-3-9": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.28.C.01", "16.1.33.C.01", - "16.1.33.C.02", "16.1.34.C.01" ], + "americas-arg-ppd-2018": [ + "B.2.3-8" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01" ] diff --git a/docs/api/controls/IAC-15.6.json b/docs/api/controls/IAC-15.6.json index 954308f4..d06e8f87 100644 --- a/docs/api/controls/IAC-15.6.json +++ b/docs/api/controls/IAC-15.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disable accounts immediately upon notification for users posing a significant risk to the organization.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -126,6 +127,10 @@ "03.01.01.f.04", "03.01.01.f.05" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -147,7 +152,7 @@ "usa-federal-irs-1075-2021": [ "AC-2(CE-13)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1591" ], "americas-can-itsp-10-171-2025": [ diff --git a/docs/api/controls/IAC-15.7.json b/docs/api/controls/IAC-15.7.json index 527c1728..7d09fbbc 100644 --- a/docs/api/controls/IAC-15.7.json +++ b/docs/api/controls/IAC-15.7.json @@ -3,7 +3,7 @@ "title": "System Account Reviews", "family": "IAC", "description": "Mechanisms exist to review all system accounts and disable any account that cannot be associated with a business process and owner.", - "scf_question": "Does the organization review all system accounts and disables any account that cannot be associated with a business process and owner?", + "scf_question": "Does the organization review all system accounts and disable any account that cannot be associated with a business process and owner?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.\n▪ IAM inventories all privileged accounts and validates that each person with elevated privileges is authorized by the appropriate level of organizational management.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to review all system accounts and disable any account that cannot be associated with a business process and owner.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to review all system accounts and disable any account that cannot be associated with a business process and owner. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -100,18 +101,15 @@ "CC6.2-POF3" ], "general-nist-800-171-r3": [ + "03.01.01.b", "03.01.01.e", "03.01.05.c" ], "general-nist-800-171a-r3": [ - "A.03.01.01.a[01]", - "A.03.01.01.a[02]", - "A.03.01.01.b[01]", - "A.03.01.01.b[02]", - "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.01.01.c.01" + "A.03.01.01.e", + "A.03.01.05.c" ], "general-pci-dss-4-0-1": [ "8.6", @@ -135,16 +133,11 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(a)(4)" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-sau-cgiot-2024": [ "1-8-2" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-2" - ], "americas-can-itsp-10-171-2025": [ + "03.01.01.B", "03.01.01.E", "03.01.05.C" ] diff --git a/docs/api/controls/IAC-15.8.json b/docs/api/controls/IAC-15.8.json index 0bbcf5b2..c20069ee 100644 --- a/docs/api/controls/IAC-15.8.json +++ b/docs/api/controls/IAC-15.8.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically enforce usage conditions for users and/or roles.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -101,7 +101,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-15.9.json b/docs/api/controls/IAC-15.9.json index e3998e56..13229e61 100644 --- a/docs/api/controls/IAC-15.9.json +++ b/docs/api/controls/IAC-15.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to establish and control \"emergency access only\" accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -113,16 +114,19 @@ "164.312(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" + ], + "emea-deu-c5-2020": [ + "IDM-09" ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1610", "ISM-1611", "ISM-1612", diff --git a/docs/api/controls/IAC-15.json b/docs/api/controls/IAC-15.json index 002b9da0..5f99423b 100644 --- a/docs/api/controls/IAC-15.json +++ b/docs/api/controls/IAC-15.json @@ -2,8 +2,8 @@ "control_id": "IAC-15", "title": "Account Management", "family": "IAC", - "description": "Mechanisms exist to proactively govern account management of individual, group, system, service, application, guest and temporary accounts.", - "scf_question": "Does the organization proactively govern account management of individual, group, system, service, application, guest and temporary accounts?", + "description": "Mechanisms exist to:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts.", + "scf_question": "Does the organization:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to proactively govern account management of individual, group, system, service, application, guest and temporary accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -34,11 +34,11 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" + "micro_small": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "small": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "medium": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "large": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "enterprise": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM" }, "risks": [ "R-AC-1", @@ -94,8 +94,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed", "family_name": "Identification & Authentication", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -144,7 +146,7 @@ "5.16", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -429,6 +431,7 @@ "03.01.01.d.02", "03.01.01.e", "03.01.01.f.01", + "03.01.01.f.02", "03.01.01.f.03", "03.01.01.f.04", "03.01.01.f.05", @@ -438,7 +441,8 @@ "03.01.02", "03.01.05.b", "03.01.05.c", - "03.01.05.d" + "03.01.05.d", + "03.05.07.e" ], "general-nist-800-171a": [ "3.1.2[a]", @@ -448,7 +452,13 @@ "A.03.01.01.ODP[01]", "A.03.01.01.a[01]", "A.03.01.01.a[02]", + "A.03.01.01.b[01]", + "A.03.01.01.b[02]", + "A.03.01.01.b[03]", "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", "A.03.01.01.e", "A.03.01.01.f.01", "A.03.01.01.f.02", @@ -458,6 +468,12 @@ "A.03.01.01.g.01", "A.03.01.01.g.02", "A.03.01.01.g.03", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.05.c", + "A.03.01.05.d", "A.03.05.07.e" ], "general-pci-dss-4-0-1": [ @@ -518,10 +534,10 @@ "AC-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "AC-2" @@ -571,23 +587,35 @@ "2447(c)(1)(A)(i)", "2447(c)(1)(A)(iv)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(c)" + ], "emea-eu-nis2-annex-2024": [ "11.2.2(c)", "11.5.2(c)" ], - "emea-deu-bsrit-2017": [ - "6.2" + "emea-deu-c5-2020": [ + "IDM-02" ], - "emea-isr-cmo-1-0": [ - "4.3", - "4.4", - "4.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 8.1" ], "emea-sau-cscc-1-2019": [ "2-2-1-7" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-10" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-32" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1", + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1", + "4-BP1", + "4-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2424" @@ -598,9 +626,18 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2424" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0441", - "ISM-0443" + "ISM-0443", + "ISM-1832", + "ISM-1834", + "ISM-1845", + "ISM-1940", + "ISM-1941", + "ISM-1942" + ], + "apac-aus-cop-sitc-2020": [ + "1" ], "apac-ind-sebi-2024": [ "PR.AA.S1" @@ -616,7 +653,10 @@ "9.2.1.6.PB", "9.2.4.9.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.56" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP38", "HML38" ], @@ -624,6 +664,15 @@ "HSUP33", "HSUP35" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.1" + ], + "apac-sgp-mas-trm-2021": [ + "9.1.8" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.A", "03.01.01.B", @@ -633,6 +682,7 @@ "03.01.01.D.02", "03.01.01.E", "03.01.01.F.01", + "03.01.01.F.02", "03.01.01.F.03", "03.01.01.F.04", "03.01.01.F.05", @@ -642,7 +692,8 @@ "03.01.02", "03.01.05.B", "03.01.05.C", - "03.01.05.D" + "03.01.05.D", + "03.05.07.E" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-16.1.json b/docs/api/controls/IAC-16.1.json index 2c372bc2..633c7efc 100644 --- a/docs/api/controls/IAC-16.1.json +++ b/docs/api/controls/IAC-16.1.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -156,8 +157,9 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(a)(4)" ], - "emea-sau-sacs-002-2022": [ - "TPC-34" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2424" @@ -169,7 +171,7 @@ "2424" ], "apac-nzl-ism-3-9": [ - "16.4.34.C.01" + "16.4.40.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-16.2.json b/docs/api/controls/IAC-16.2.json index 2f742a55..037eb885 100644 --- a/docs/api/controls/IAC-16.2.json +++ b/docs/api/controls/IAC-16.2.json @@ -85,10 +85,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ], "apac-nzl-ism-3-9": [ "23.3.18.C.01" ] diff --git a/docs/api/controls/IAC-16.3.json b/docs/api/controls/IAC-16.3.json index 3651bde5..252702a6 100644 --- a/docs/api/controls/IAC-16.3.json +++ b/docs/api/controls/IAC-16.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure privilege change requests require additional levels of authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-16.4.json b/docs/api/controls/IAC-16.4.json index ec8b244b..696a460f 100644 --- a/docs/api/controls/IAC-16.4.json +++ b/docs/api/controls/IAC-16.4.json @@ -20,7 +20,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to assign dedicated privileged user accounts to be used solely for duties requiring privileged access.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -83,17 +83,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP5" + ], "apac-aus-essential-8-2024": [ "ML1-P4", "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-0445" + "apac-aus-ism-2026-march": [ + "ISM-0445", + "ISM-1827", + "ISM-1842" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-16.5.json b/docs/api/controls/IAC-16.5.json index c94bbceb..deda677a 100644 --- a/docs/api/controls/IAC-16.5.json +++ b/docs/api/controls/IAC-16.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enable a manual override of the current account privileges to enable the timely response to unusual conditions without terminating the current session and establishing a new session as a higher-privileged user.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46,9 +46,9 @@ "MT-2", "MT-8", "MT-9", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (IEC 62443-4-2)", "family_name": "Identification & Authentication", "crosswalks": { "general-iec-62443-3-3-2013": [ diff --git a/docs/api/controls/IAC-16.json b/docs/api/controls/IAC-16.json index 92a6700e..4e0864b9 100644 --- a/docs/api/controls/IAC-16.json +++ b/docs/api/controls/IAC-16.json @@ -22,7 +22,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).\n▪ LAC and RBAC enforcements limit the ability of non-administrators from making unauthorized configuration changes to TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict and control privileged access rights for users and Technology Assets, Applications and/or Services (TAAS).", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -110,7 +110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -164,6 +165,11 @@ "03.01.07.a", "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.01.07.b" + ], "general-pci-dss-4-0-1": [ "7.2.3", "7.2.5" @@ -184,9 +190,6 @@ "7.2.3", "7.2.5" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.2" ], @@ -222,14 +225,17 @@ "500.7(a)(3)", "500.7(c)(1)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(d)" + ], "emea-eu-nis2-annex-2024": [ "11.6.2(f)" ], "emea-deu-c5-2020": [ "IDM-06" ], - "emea-isr-cmo-1-0": [ - "4.2" + "emea-sau-cscc-1-2019": [ + "2-2-1-7" ], "emea-sau-cgiot-2024": [ "2-2-1" @@ -237,12 +243,17 @@ "emea-sau-ecc-1-2018": [ "2-2-3-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-34" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-caf-4-0": [ "B2.c" ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP6" + ], "emea-gbr-def-stan-05-138-2024": [ "2424" ], @@ -257,7 +268,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0445", "ISM-0446", "ISM-0447", @@ -272,13 +283,16 @@ "ISM-1650", "ISM-1687", "ISM-1688", - "ISM-1689" + "ISM-1689", + "ISM-1835", + "ISM-1939" ], "apac-ind-sebi-2024": [ "PR.AA.S11" ], "apac-jpn-ismap": [ "9.2.3", + "9.2.3.1", "9.2.3.2", "9.2.3.3", "9.2.3.4", @@ -289,7 +303,7 @@ "9.2.3.9", "9.2.3.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP41", "HML41" ], @@ -298,24 +312,15 @@ ], "apac-nzl-ism-3-9": [ "16.3.5.C.01", - "16.3.5.C.02", "16.3.6.C.01", "16.3.6.C.02", "16.3.7.C.01", - "16.4.30.C.01", - "16.4.30.C.02", - "16.4.30.C.03", - "16.4.31.C.01", - "16.4.31.C.02", - "16.4.32.C.01", - "16.4.32.C.02", - "16.4.33.C.01", - "16.4.34.C.01", - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03", "16.4.36.C.01", - "16.4.37.C.01" + "16.4.36.C.02", + "16.4.36.C.03", + "16.4.37.C.01", + "16.4.37.C.03", + "16.4.38.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.1" @@ -323,13 +328,18 @@ "apac-sgp-mas-trm-2021": [ "9.2.1" ], - "amaericas-can-osfi-self-assessment": [ - "4.23", - "4.24" + "americas-arg-ppd-2018": [ + "B.2.1-2", + "B.2.1-3", + "B.2.3-6", + "B.2.5-DS-2" ], "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.06.A", "03.01.07.A", diff --git a/docs/api/controls/IAC-17.json b/docs/api/controls/IAC-17.json index 977f6d3a..090814eb 100644 --- a/docs/api/controls/IAC-17.json +++ b/docs/api/controls/IAC-17.json @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -171,9 +172,12 @@ "03.10.01.d" ], "general-nist-800-171a-r3": [ + "A.03.01.01.g.03", "A.03.01.05.ODP[03]", "A.03.01.05.c", - "A.03.01.05.d" + "A.03.01.05.d", + "A.03.10.01.c", + "A.03.10.01.d" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -225,10 +229,10 @@ "AC-06(07)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "AC-6(CE-7)", @@ -247,40 +251,49 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-06 (07)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(e)", + "3.4.2.31(f)" + ], "emea-eu-nis2-annex-2024": [ "11.2.3", "11.3.3", "11.5.4" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-deu-c5-2020": [ - "IDM-05" + "IDM-01-BP4", + "IDM-05", + "IDM-05-DOAR", + "IDM-09-DOAR" ], - "emea-isr-cmo-1-0": [ - "4.3" + "emea-sau-cscc-1-2019": [ + "2-2-2" ], "emea-sau-cgiot-2024": [ "1-8-2", "2-2-3" ], "emea-sau-ecc-1-2018": [ - "1-9-5", "2-2-3-5" ], "emea-sau-otcc-1-2022": [ "2-2-1-10" ], "emea-sau-sacs-002-2022": [ - "TPC-33", - "TPC-34" + "VII.B.TPC-33" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], - "apac-aus-ism-2024-june": [ + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1" + ], + "apac-aus-ism-2026-march": [ "ISM-0405", "ISM-1647", - "ISM-1648", - "ISM-1716" + "ISM-1648" ], "apac-ind-sebi-2024": [ "PR.AA.S5" @@ -295,14 +308,6 @@ "9.2.5.5", "9.2.5.6" ], - "apac-nzl-ism-3-9": [ - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03" - ], - "apac-sgp-mas-trm-2021": [ - "9.1.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.03", "03.01.05.C", diff --git a/docs/api/controls/IAC-18.json b/docs/api/controls/IAC-18.json index 44051433..bc3c2dda 100644 --- a/docs/api/controls/IAC-18.json +++ b/docs/api/controls/IAC-18.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -155,15 +156,13 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (06)" ], - "emea-sau-cscc-1-2019": [ - "2-2-2" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0421", "ISM-0422" ], "apac-nzl-ism-3-9": [ - "16.4.37.C.01" + "16.4.37.C.01", + "16.4.38.C.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-19.json b/docs/api/controls/IAC-19.json index 19d30f4e..198123f5 100644 --- a/docs/api/controls/IAC-19.json +++ b/docs/api/controls/IAC-19.json @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -128,6 +129,15 @@ "III.C.4", "III.C.4.a", "III.C.4.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "apac-nzl-ism-3-9": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.27.C.03" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-20.1.json b/docs/api/controls/IAC-20.1.json index 517bff0a..49c95e43 100644 --- a/docs/api/controls/IAC-20.1.json +++ b/docs/api/controls/IAC-20.1.json @@ -2,8 +2,8 @@ "control_id": "IAC-20.1", "title": "Access To Sensitive / Regulated Data", "family": "IAC", - "description": "Mechanisms exist to limit access to sensitive/regulated data to only those individuals whose job requires such access.", - "scf_question": "Does the organization limit access to sensitive/regulated data to only those individuals whose job requires such access?", + "description": "Mechanisms exist to limit access to sensitive and/or regulated data to only those individuals whose job requires such access.", + "scf_question": "Does the organization limit access to sensitive and/or regulated data to only those individuals whose job requires such access?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit access to sensitive/regulated data to only those individuals whose job requires such access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit access to sensitive/regulated data to only those individuals whose job requires such access. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -129,13 +130,26 @@ "03.01.03", "03.01.04.b", "03.01.05.a", + "03.01.05.b", "03.06.05.d", "03.10.01.a" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", "A.03.01.05.b[01]", "A.03.01.05.b[02]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]" ], "general-nist-800-207": [ "NIST Tenet 3" @@ -178,6 +192,10 @@ "7.2.5", "7.2.6" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.03", "03.01.01.D.01", @@ -186,6 +204,7 @@ "03.01.03", "03.01.04.B", "03.01.05.A", + "03.01.05.B", "03.06.05.D", "03.10.01.A" ] diff --git a/docs/api/controls/IAC-20.2.json b/docs/api/controls/IAC-20.2.json index 4ec9483f..bd9e9133 100644 --- a/docs/api/controls/IAC-20.2.json +++ b/docs/api/controls/IAC-20.2.json @@ -2,8 +2,8 @@ "control_id": "IAC-20.2", "title": "Database Access", "family": "IAC", - "description": "Mechanisms exist to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", - "scf_question": "Does the organization restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access?", + "description": "Mechanisms exist to restrict access to databases containing sensitive and/or regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", + "scf_question": "Does the organization restrict access to databases containing sensitive and/or regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -126,6 +127,10 @@ ], "emea-sau-cscc-1-2019": [ "2-2-1-8" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-20.3.json b/docs/api/controls/IAC-20.3.json index 1452c3fb..fb2930de 100644 --- a/docs/api/controls/IAC-20.3.json +++ b/docs/api/controls/IAC-20.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict and tightly control utility programs that are capable of overriding system and application controls.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127,7 +128,11 @@ "500.7(a)(5)" ], "emea-deu-c5-2020": [ - "IDM-06" + "IDM-12" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "apac-jpn-ismap": [ "9.4.4", diff --git a/docs/api/controls/IAC-20.4.json b/docs/api/controls/IAC-20.4.json index 452bbc05..afc5b08e 100644 --- a/docs/api/controls/IAC-20.4.json +++ b/docs/api/controls/IAC-20.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict executing administrative tasks or tasks requiring elevated access to a dedicated machine.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -132,6 +133,14 @@ ], "apac-aus-essential-8-2024": [ "ML3-P4" + ], + "apac-aus-ism-2026-march": [ + "ISM-1898" + ], + "americas-can-itsp-10-171-2025": [ + "03.01.06.C", + "03.14.08.A", + "03.14.08.C" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-20.5.json b/docs/api/controls/IAC-20.5.json index 1612b0bb..1d214393 100644 --- a/docs/api/controls/IAC-20.5.json +++ b/docs/api/controls/IAC-20.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically enforce dual authorization for privileged commands.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101,7 +101,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -127,8 +128,12 @@ "general-nist-800-160-vol-2-r1": [ "AC-03(02)" ], - "general-nist-800-172": [ - "3.1.1e" + "general-nist-800-172-r3": [ + "03.01.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" ], "usa-federal-gsa-fedramp-5-low": [ "AC-03(02)" diff --git a/docs/api/controls/IAC-20.6.json b/docs/api/controls/IAC-20.6.json index b0550682..6c257e86 100644 --- a/docs/api/controls/IAC-20.6.json +++ b/docs/api/controls/IAC-20.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM revokes user access rights in a timely manner, up on termination of employment or contract.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke logical and physical access authorizations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-20.7.json b/docs/api/controls/IAC-20.7.json index 328a51c2..5c19e9da 100644 --- a/docs/api/controls/IAC-20.7.json +++ b/docs/api/controls/IAC-20.7.json @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": {} diff --git a/docs/api/controls/IAC-20.json b/docs/api/controls/IAC-20.json index 7b47d1f2..e513c6ba 100644 --- a/docs/api/controls/IAC-20.json +++ b/docs/api/controls/IAC-20.json @@ -3,7 +3,7 @@ "title": "Access Enforcement", "family": "IAC", "description": "Mechanisms exist to enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"", - "scf_question": "Does the organization enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege?\"", + "scf_question": "Does the organization enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -141,7 +142,7 @@ "general-iso-27018-2025": [ "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -502,6 +503,22 @@ "3.1.1[e]", "3.1.1[f]" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -613,18 +630,19 @@ "AC-03", "AC-06" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "apac-ind-sebi-2024": [ "PR.AA.S15" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP10", "HHSP40", "HML10", "HML40" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS07" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP09" ], diff --git a/docs/api/controls/IAC-21.1.json b/docs/api/controls/IAC-21.1.json index d25a7701..10e09d6f 100644 --- a/docs/api/controls/IAC-21.1.json +++ b/docs/api/controls/IAC-21.1.json @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-21.2.json b/docs/api/controls/IAC-21.2.json index 565b0fe4..0c15b67f 100644 --- a/docs/api/controls/IAC-21.2.json +++ b/docs/api/controls/IAC-21.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prohibit privileged users from using privileged accounts, while performing non-security functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prohibit privileged users from using privileged accounts, while performing non-security functions. \n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -196,8 +197,9 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-1175" + "apac-aus-ism-2026-march": [ + "ISM-1175", + "ISM-1883" ], "americas-can-itsp-10-171-2025": [ "03.01.06.B" diff --git a/docs/api/controls/IAC-21.3.json b/docs/api/controls/IAC-21.3.json index 89041ed4..1109ad75 100644 --- a/docs/api/controls/IAC-21.3.json +++ b/docs/api/controls/IAC-21.3.json @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -147,7 +148,8 @@ ], "general-nist-800-171a-r3": [ "A.03.01.06.ODP[01]", - "A.03.01.06.a" + "A.03.01.06.a", + "A.03.01.07.a" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -199,11 +201,18 @@ "emea-eu-nis2-annex-2024": [ "11.3.2(b)" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "apac-aus-essential-8-2024": [ "ML1-P4", "ML2-P4", "ML3-P4" ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.06.A", "03.01.07.A" diff --git a/docs/api/controls/IAC-21.4.json b/docs/api/controls/IAC-21.4.json index a3e122f2..fe512bbd 100644 --- a/docs/api/controls/IAC-21.4.json +++ b/docs/api/controls/IAC-21.4.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM revokes user access rights following changes in personnel roles and duties, if no longer necessary or permitted.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to audit the execution of privileged functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to audit the execution of privileged functions. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -128,6 +129,9 @@ "general-nist-800-171-r3": [ "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b" + ], "general-owasp-top-10-2025": [ "A01:2025" ], diff --git a/docs/api/controls/IAC-21.5.json b/docs/api/controls/IAC-21.5.json index 52c6c8bc..14219f71 100644 --- a/docs/api/controls/IAC-21.5.json +++ b/docs/api/controls/IAC-21.5.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -176,8 +177,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2216" ], - "apac-aus-ism-2024-june": [ - "ISM-1592" + "apac-aus-ism-2026-march": [ + "ISM-1592", + "ISM-2048" ], "americas-can-itsp-10-171-2025": [ "03.01.07.A" diff --git a/docs/api/controls/IAC-21.6.json b/docs/api/controls/IAC-21.6.json index aef1292c..fa520eec 100644 --- a/docs/api/controls/IAC-21.6.json +++ b/docs/api/controls/IAC-21.6.json @@ -2,8 +2,8 @@ "control_id": "IAC-21.6", "title": "Network Access to Privileged Commands", "family": "IAC", - "description": "Mechanisms exist to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs.", - "scf_question": "Does the organization authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs?", + "description": "Mechanisms exist to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive and/or regulated data is stored, transmitted and/or processed only for compelling operational needs.", + "scf_question": "Does the organization authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive and/or regulated data is stored, transmitted and/or processed only for compelling operational needs?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-21.7.json b/docs/api/controls/IAC-21.7.json index 8d7e7a1b..67e893e6 100644 --- a/docs/api/controls/IAC-21.7.json +++ b/docs/api/controls/IAC-21.7.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically prevent applications from executing at higher privilege levels than the user's privileges.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically prevent applications from executing at higher privilege levels than the user's privileges. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,7 +83,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-21.json b/docs/api/controls/IAC-21.json index 1b4bbc53..f7274b2c 100644 --- a/docs/api/controls/IAC-21.json +++ b/docs/api/controls/IAC-21.json @@ -20,9 +20,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -161,7 +162,7 @@ "8.3", "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -479,6 +480,7 @@ "03.01.01.c.03", "03.01.01.d.01", "03.01.01.d.02", + "03.01.02", "03.01.04.b", "03.01.05.a", "03.01.05.b", @@ -494,8 +496,20 @@ "3.1.5[d]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", "A.03.01.02[02]", - "A.03.01.05.a" + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.03.08.a[02]", + "A.03.03.08.b", + "A.03.04.05[04]" ], "general-nist-800-207": [ "NIST Tenet 3" @@ -560,9 +574,6 @@ "7.3.3", "8.6.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0039" ], @@ -609,16 +620,19 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(5)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(1)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "AC-6" @@ -649,8 +663,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-06" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(a)" ], "emea-eu-dora-2023": [ "Article 9.4(c)" @@ -662,15 +676,13 @@ "11.3.2(c)", "11.3.2(d)" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-deu-c5-2020": [ - "IDM-07" - ], - "emea-isr-cmo-1-0": [ - "4.10", - "12.29" + "IDM-03-BP1", + "IDM-03-BP2", + "IDM-03-BP4", + "IDM-10", + "IDM-12", + "IDM-13" ], "emea-sau-cgiot-2024": [ "2-2-1" @@ -678,13 +690,23 @@ "emea-sau-otcc-1-2022": [ "2-3-1-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 17", - "Article 20" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-34" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.5" ], "emea-esp-decree-311-2022": [ - "17", - "20" + "Article 12(6)(h)", + "Article 20" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "2205", @@ -707,7 +729,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0441", "ISM-0611", "ISM-1380", @@ -715,7 +737,11 @@ "ISM-1705", "ISM-1706", "ISM-1707", - "ISM-1708" + "ISM-1708", + "ISM-1833" + ], + "apac-aus-cop-sitc-2020": [ + "6" ], "apac-ind-sebi-2024": [ "PR.AA.S3" @@ -731,14 +757,15 @@ "9.1.2.7", "9.1.2.8" ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], "apac-nzl-ism-3-9": [ "16.2.4.C.01", - "16.4.31.C.01", - "16.4.31.C.02", "23.4.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "9.1.1" + "9.1.7" ], "americas-can-osfi-b13-2022": [ "3.2.7" @@ -747,6 +774,7 @@ "03.01.01.C.03", "03.01.01.D.01", "03.01.01.D.02", + "03.01.02", "03.01.04.B", "03.01.05.A", "03.01.05.B", diff --git a/docs/api/controls/IAC-22.json b/docs/api/controls/IAC-22.json index e82f2c94..b29cbb75 100644 --- a/docs/api/controls/IAC-22.json +++ b/docs/api/controls/IAC-22.json @@ -88,18 +88,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { "general-cis-csc-8-1": [ - "4.1" + "4.10" ], "general-cis-csc-8-1-ig2": [ - "4.1" + "4.10" ], "general-cis-csc-8-1-ig3": [ - "4.1" + "4.10" ], "general-govramp": [ "AC-07" @@ -136,7 +137,7 @@ "general-iso-27018-2025": [ "8.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021", "T1021.001", "T1021.004", @@ -227,6 +228,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-07" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(1)" + ], "usa-federal-irs-1075-2021": [ "AC-7" ], @@ -259,12 +263,13 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(d)" ], - "emea-isr-cmo-1-0": [ - "4.14" - ], "emea-sau-cgiot-2024": [ "2-2-2" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" + ], "emea-gbr-def-stan-05-138-2024": [ "2214" ], @@ -277,13 +282,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2214" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1403" ], - "apac-nzl-ism-3-9": [ - "16.1.46.C.01", - "16.1.46.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.08.A", "03.01.08.B" diff --git a/docs/api/controls/IAC-23.json b/docs/api/controls/IAC-23.json index 5e245084..8323365f 100644 --- a/docs/api/controls/IAC-23.json +++ b/docs/api/controls/IAC-23.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit the number of concurrent sessions for each system account.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit the number of concurrent sessions for each system account. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -108,7 +109,7 @@ "general-iec-62443-4-2-2019": [ "CR 2.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.002", "T1185", @@ -129,17 +130,22 @@ "general-nist-800-82-r3-high": [ "AC-10" ], + "general-nist-800-172-r3": [ + "03.01.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.04E", + "A.03.01.04E.ODP[01]", + "A.03.01.04E.ODP[02]" + ], "usa-federal-gsa-fedramp-5-high": [ "AC-10" ], "usa-federal-cms-marse-2-0": [ "AC-10" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "4.15" + "americas-arg-ppd-2018": [ + "B.2.5-DS-1" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-24.1.json b/docs/api/controls/IAC-24.1.json index c5774c72..f83f58ab 100644 --- a/docs/api/controls/IAC-24.1.json +++ b/docs/api/controls/IAC-24.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement pattern-hiding displays to conceal information previously visible on the display during the session lock.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement pattern-hiding displays to conceal information previously visible on the display during the session lock. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -152,9 +153,6 @@ "usa-federal-cms-marse-2-0": [ "AC-11(1)" ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], "americas-can-itsp-10-171-2025": [ "03.01.10.C" ] diff --git a/docs/api/controls/IAC-24.json b/docs/api/controls/IAC-24.json index 8e1bd58d..065b7fef 100644 --- a/docs/api/controls/IAC-24.json +++ b/docs/api/controls/IAC-24.json @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -133,7 +134,7 @@ "CR 2.5(a)", "CR 2.5(b)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1563.002" ], @@ -224,18 +225,6 @@ "AC-02 (05)", "AC-11" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "4.16" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], "emea-gbr-def-stan-05-138-2024": [ "2408" ], @@ -248,13 +237,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2408" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0428" ], - "apac-nzl-ism-3-9": [ - "16.1.45.C.01", - "16.1.45.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.10.A", "03.01.10.B" diff --git a/docs/api/controls/IAC-25.1.json b/docs/api/controls/IAC-25.1.json index e2c21459..6aa68915 100644 --- a/docs/api/controls/IAC-25.1.json +++ b/docs/api/controls/IAC-25.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a logout capability and display an explicit logout message to users indicating the reliable termination of the session.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a logout capability and display an explicit logout message to users indicating the reliable termination of the session. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-25.json b/docs/api/controls/IAC-25.json index 9c274e93..0d6cf044 100644 --- a/docs/api/controls/IAC-25.json +++ b/docs/api/controls/IAC-25.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,7 +87,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -106,7 +107,7 @@ "general-iec-62443-3-3-2013": [ "SR 2.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1072", "T1185", @@ -195,10 +196,10 @@ "AC-12" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "AC-12" @@ -216,19 +217,14 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(e)" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0853" ], "apac-nzl-ism-3-9": [ "16.1.44.C.01" ], "americas-can-itsp-10-171-2025": [ + "03.01.01.H", "03.01.11", "03.07.05.C" ] diff --git a/docs/api/controls/IAC-26.json b/docs/api/controls/IAC-26.json index 1551c7da..3afa786e 100644 --- a/docs/api/controls/IAC-26.json +++ b/docs/api/controls/IAC-26.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify and document the supporting rationale for specific user actions that can be performed on a system without identification or authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -103,7 +104,7 @@ "general-govramp-high": [ "AC-14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137.002" ], "general-nist-800-53-r4": [ diff --git a/docs/api/controls/IAC-27.json b/docs/api/controls/IAC-27.json index b8df0718..9996698c 100644 --- a/docs/api/controls/IAC-27.json +++ b/docs/api/controls/IAC-27.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement a reference monitor that is tamperproof, always-invoked, small enough to be subject to analysis / testing and the completeness of which can be assured.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-28.1.json b/docs/api/controls/IAC-28.1.json index 235cbb74..b1b0fe67 100644 --- a/docs/api/controls/IAC-28.1.json +++ b/docs/api/controls/IAC-28.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure management approvals are required for new accounts or changes in permissions to existing accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -152,8 +153,9 @@ "03.01.01.b", "03.05.05.a" ], - "general-scf-dpmp-2025": [ - "7.1" + "general-nist-800-171a-r3": [ + "A.03.01.01.b[02]", + "A.03.05.05.a" ], "general-tisax-6-0-3": [ "4.2.1" @@ -163,10 +165,10 @@ "ACCESS-2g" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-1)" @@ -181,15 +183,26 @@ "11.2.2(c)" ], "emea-deu-c5-2020": [ - "IDM-01", - "IDM-02" - ], - "apac-aus-ism-2024-june": [ + "IDM-01-BP1", + "IDM-01-BP6", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-06", + "IDM-09", + "BEI-09" + ], + "apac-aus-ism-2026-march": [ "ISM-0405" ], "apac-jpn-ismap": [ "9.2.2.1" ], + "americas-arg-ppd-2018": [ + "B.2.3-5" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.B", "03.05.05.A" diff --git a/docs/api/controls/IAC-28.2.json b/docs/api/controls/IAC-28.2.json index 576e12f5..d3b8bf3e 100644 --- a/docs/api/controls/IAC-28.2.json +++ b/docs/api/controls/IAC-28.2.json @@ -16,8 +16,8 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM collects, validates and verifies identity evidence of a user.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require evidence of individual identification to be presented to the registration authority.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -133,10 +134,10 @@ "IA-12(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-2)" diff --git a/docs/api/controls/IAC-28.3.json b/docs/api/controls/IAC-28.3.json index 864fbf3c..c10e09b6 100644 --- a/docs/api/controls/IAC-28.3.json +++ b/docs/api/controls/IAC-28.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that the presented identity evidence be validated and verified through organizational-defined methods of validation and verification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -133,10 +134,10 @@ "IA-12(03)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-3)" diff --git a/docs/api/controls/IAC-28.4.json b/docs/api/controls/IAC-28.4.json index 3c1e32ae..148ad82f 100644 --- a/docs/api/controls/IAC-28.4.json +++ b/docs/api/controls/IAC-28.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that the validation and verification of identity evidence be conducted in person before a designated registration authority.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-28.5.json b/docs/api/controls/IAC-28.5.json index 50b83966..f00cccc7 100644 --- a/docs/api/controls/IAC-28.5.json +++ b/docs/api/controls/IAC-28.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that a notice of proofing be delivered through an out-of-band channel to verify the user's address (physical or digital).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-28.json b/docs/api/controls/IAC-28.json index 03bf4ab4..9d09e9dc 100644 --- a/docs/api/controls/IAC-28.json +++ b/docs/api/controls/IAC-28.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to verify the identity of a user before issuing authenticators or modifying access permissions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,11 +95,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.002", "T1078.003", @@ -124,8 +125,20 @@ "IA-12" ], "general-nist-800-171-r3": [ - "03.05.12.a", - "03.05.12.c" + "03.05.12.a" + ], + "general-nist-800-171a-r3": [ + "A.03.05.12.a" + ], + "general-nist-800-172-r3": [ + "03.05.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.06E.a", + "DS-A.03.05.06E.b", + "DS-A.03.05.06E.c[01]", + "DS-A.03.05.06E.c[02]", + "DS-A.03.05.06E.c[03]" ], "general-nist-csf-2-0": [ "PR.AA-02" @@ -164,20 +177,22 @@ "IA-12" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12" ], + "emea-deu-c5-2020": [ + "IDM-08-BP1" + ], "apac-jpn-ismap": [ "7.1.1.4" ], "americas-can-itsp-10-171-2025": [ - "03.05.12.A", - "03.05.12.C" + "03.05.12.A" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-29.1.json b/docs/api/controls/IAC-29.1.json index a863abc1..f209eadb 100644 --- a/docs/api/controls/IAC-29.1.json +++ b/docs/api/controls/IAC-29.1.json @@ -3,7 +3,7 @@ "title": "Real-Time Access Decisions", "family": "IAC", "description": "Automated mechanisms exist to utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources.", - "scf_question": "Does the organization utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources?", + "scf_question": "Does the organization use automated mechanisms to utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources?", "relative_weight": 3, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,7 +61,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-29.2.json b/docs/api/controls/IAC-29.2.json index 133db2ea..29ff6199 100644 --- a/docs/api/controls/IAC-29.2.json +++ b/docs/api/controls/IAC-29.2.json @@ -2,8 +2,8 @@ "control_id": "IAC-29.2", "title": "Access Profile Rules", "family": "IAC", - "description": "Mechanisms exist to develop access profile rules for sensitive/regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes.", - "scf_question": "Does the organization develop access profile rules for sensitive/regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes?", + "description": "Mechanisms exist to develop access profile rules for sensitive and/or regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes.", + "scf_question": "Does the organization develop access profile rules for sensitive and/or regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { diff --git a/docs/api/controls/IAC-29.json b/docs/api/controls/IAC-29.json index f0be989d..a198c15d 100644 --- a/docs/api/controls/IAC-29.json +++ b/docs/api/controls/IAC-29.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Attribute-Based Access Control (ABAC) for policy-driven, dynamic authorizations that supports the secure sharing of information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -73,6 +74,15 @@ "general-mpa-csbp-5-3-1": [ "TS-1.8" ], + "general-nist-800-172-r3": [ + "03.01.09E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.09E.a[01]", + "DS-A.03.01.09E.a[02]", + "DS-A.03.01.09E.b", + "A.03.01.09E.ODP[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "1.2", "1.2.1", @@ -91,6 +101,12 @@ "2.3.3", "2.3.5", "2.4.2" + ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], + "apac-nzl-ism-3-9": [ + "16.1.31.C.06" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAC-30.json b/docs/api/controls/IAC-30.json index a074ace6..13934ab0 100644 --- a/docs/api/controls/IAC-30.json +++ b/docs/api/controls/IAC-30.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Mutual Authentication (MA) where both sides of a communications channel verify the identity of the other party through certificate exchange.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -42,9 +42,9 @@ "MT-2", "MT-8", "MT-9", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (IEC 62443-2-1)", "family_name": "Identification & Authentication", "crosswalks": { "general-iec-62443-2-1-2024": [ diff --git a/docs/api/controls/IAO-01.1.json b/docs/api/controls/IAO-01.1.json index 578dc157..1bf145c9 100644 --- a/docs/api/controls/IAO-01.1.json +++ b/docs/api/controls/IAO-01.1.json @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -134,6 +135,9 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-swift-cscf-2025": [ "7.3A" ], @@ -153,25 +157,54 @@ "11.10(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.F.2.b" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-annex-2024": [ "6.5.2(c)" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.3" + ], + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "2-11-3-1" + ], + "emea-gbr-cap-1850-2020": [ + "A2" + ], + "apac-mys-bnm-rmit-2025": [ + "10.8", + "10.9" + ], "apac-nzl-ism-3-9": [ "5.8.61.C.01", "5.8.61.C.02", - "5.8.61.C.03" + "5.8.61.C.03", + "20.1.21.C.02", + "23.5.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2" + "4.5.1", + "5.6.2", + "6.1.6", + "6.4.6" ], "americas-can-osfi-b13-2022": [ "2.4.4" diff --git a/docs/api/controls/IAO-01.json b/docs/api/controls/IAO-01.json index f626be92..faf4894c 100644 --- a/docs/api/controls/IAO-01.json +++ b/docs/api/controls/IAO-01.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel coordinate IAP activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience assessment and authorization controls.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience assessment and authorization controls. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -116,9 +116,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -242,12 +242,12 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-nist-csf-2-0": [ "ID.RA-01" ], - "general-scf-dpmp-2025": [ - "7.11" - ], "general-sparta": [ "CM0089" ], @@ -326,50 +326,34 @@ "emea-eu-ai-act-2024": [ "Article 9.8" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)" + "3.4.6.42", + "3.4.6.43", + "3.4.6.43(a)", + "3.4.6.43(b)", + "3.4.6.45", + "3.6.2.69", + "3.6.2.70" ], "emea-eu-nis2-annex-2024": [ "6.5.1", "6.5.2(a)", "6.5.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5", - "17.1", - "17.16", - "17.18" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" + "emea-sau-cscc-1-2019": [ + "1-3-1", + "1-3-2", + "2-13-4" ], "emea-sau-cgiot-2024": [ "1-5-2", @@ -377,15 +361,21 @@ "4-1-5", "4-2-3" ], + "emea-sau-ecc-1-2018": [ + "1-6-2" + ], "emea-sau-otcc-1-2022": [ - "1-4-1-2" + "1-5-3-3" + ], + "emea-esp-decree-311-2022": [ + "Article 13(2)(c)", + "Article 21(1)" ], - "emea-sau-sacs-002-2022": [ - "TPC-51" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" ], - "emea-zaf-popia-2013": [ - "19", - "60" + "emea-gbr-cap-1850-2020": [ + "A2" ], "emea-gbr-def-stan-05-138-2024": [ "1205" @@ -396,7 +386,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1205" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0027", "ISM-0280", "ISM-1525" @@ -405,7 +395,14 @@ "ID.AM.S4", "PR.AA.S16" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.6", + "10.8", + "10.15", + "16.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP68", "HML67" ], @@ -436,19 +433,16 @@ "4.4.12.C.05" ], "apac-sgp-mas-trm-2021": [ - "5.1.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.6.1", + "4.5.1", "5.6.2", - "5.6.3", "5.7.1", - "5.7.2" + "6.1.6", + "6.1.7", + "6.4.6", + "6.5.3" ], "americas-bmu-mba-coc-2020": [ - "5.14" + "6.15" ], "americas-can-osfi-b13-2022": [ "2.4.4" diff --git a/docs/api/controls/IAO-02.1.json b/docs/api/controls/IAO-02.1.json index 6869ed4a..0c39bc84 100644 --- a/docs/api/controls/IAO-02.1.json +++ b/docs/api/controls/IAO-02.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -101,9 +101,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -148,6 +148,12 @@ "general-nist-800-171-r2": [ "NFO - CA-2(1)" ], + "general-nist-800-172-r3": [ + "03.12.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.02E" + ], "usa-federal-fbi-cjis-6-0": [ "CA-2(1)" ], @@ -170,9 +176,16 @@ "CA-2(1)", "CA-2(1)-IS" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "apac-mys-bnm-rmit-2025": [ + "10.8" ], "apac-nzl-ism-3-9": [ "4.3.16.C.01" diff --git a/docs/api/controls/IAO-02.2.json b/docs/api/controls/IAO-02.2.json index dcdf6593..d2f6bcd4 100644 --- a/docs/api/controls/IAO-02.2.json +++ b/docs/api/controls/IAO-02.2.json @@ -2,8 +2,8 @@ "control_id": "IAO-02.2", "title": "Specialized Assessments", "family": "IAO", - "description": "Mechanisms exist to conduct specialized assessments for: \n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities; \n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management; \n(8) Malicious code; \n(9) Insider threats;\n(10) Performance/load testing; and/or\n(11) Artificial Intelligence and Autonomous Technologies (AAT).", - "scf_question": "Does the organization conduct specialized assessments for: \n (1) Statutory, regulatory and contractual compliance obligations;\n (2) Monitoring capabilities; \n (3) Mobile devices;\n (4) Databases;\n (5) Application security;\n (6) Embedded technologies (e.g., IoT, OT, etc.);\n (7) Vulnerability management; \n (8) Malicious code; \n (9) Insider threats;\n (10) Performance/load testing; and/or\n (11) Artificial Intelligence and Autonomous Technologies (AAT) testing?", + "description": "Mechanisms exist to conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.", + "scf_question": "Does the organization conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct specialized assessments for: \n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities; \n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management; \n(8) Malicious code; \n(9) Insider threats;\n(10) Performance/load testing; and/or\n(11) Artificial Intelligence and Autonomous Technologies (AAT).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,8 +102,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -210,29 +212,75 @@ "usa-federal-irs-1075-2021": [ "SA-11(CE-5)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 13(3)", + "Article 32(1)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.4.6.47", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" ], "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-2-1", + "1-6-2-2" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3", + "2-10-1-4" ], - "apac-aus-ism-2024-june": [ + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.b.1", + "3.3.7.4.b.2", + "3.3.7.4.b.3", + "3.3.7.4.b.4" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3", + "mp.sw.2" + ], + "apac-aus-ism-2026-march": [ "ISM-0100", "ISM-1137", - "ISM-1570" + "ISM-1570", + "ISM-2019" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.9", + "10.15" ], "apac-nzl-ism-3-9": [ "4.3.20.C.01", "4.3.20.C.02", - "4.3.20.C.03" + "4.3.20.C.03", + "20.2.13.C.01", + "20.2.13.C.02" ], "apac-sgp-mas-trm-2021": [ - "5.7.4" + "5.3.3", + "5.6.3", + "6.1.6", + "6.4.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAO-02.3.json b/docs/api/controls/IAO-02.3.json index 9c533896..ae7ebf8d 100644 --- a/docs/api/controls/IAO-02.3.json +++ b/docs/api/controls/IAO-02.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to accept and respond to the results of external assessments that are performed by impartial, external organizations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to accept and respond to the results of external assessments that are performed by impartial, external organizations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -101,9 +101,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Information Assurance", "crosswalks": { "general-govramp": [ @@ -136,11 +136,7 @@ "usa-federal-gsa-fedramp-5-high": [ "CA-02(03)" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0100" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/IAO-02.4.json b/docs/api/controls/IAO-02.4.json index ad3b3745..e74ac701 100644 --- a/docs/api/controls/IAO-02.4.json +++ b/docs/api/controls/IAO-02.4.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -131,21 +132,35 @@ "ID.IM-01", "ID.IM-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)(iii)" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-annex-2024": [ "6.5.2(c)" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "apac-aus-ism-2026-march": [ "ISM-1563" ], + "apac-mys-bnm-rmit-2025": [ + "10.8" + ], "apac-nzl-ism-3-9": [ "4.2.11.C.01", "4.2.12.C.01", "4.3.21.C.01", "4.5.17.C.01", "6.3.8.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAO-02.json b/docs/api/controls/IAO-02.json index f9ba6110..695d3901 100644 --- a/docs/api/controls/IAO-02.json +++ b/docs/api/controls/IAO-02.json @@ -110,9 +110,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -200,7 +200,7 @@ "general-iso-42001-2023": [ "A.6.2.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1190", "T1195", "T1195.001", @@ -261,6 +261,9 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-nist-csf-2-0": [ "ID.RA-01", "ID.IM-01", @@ -303,11 +306,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)", + "101.650(e)(1)(i)", + "101.650(e)(1)(ii)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-irs-1075-2021": [ "CA-2" @@ -347,19 +355,15 @@ "emea-eu-ai-act-2024": [ "Article 9.8" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 32(1)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" ], "emea-eu-nis2-annex-2024": [ "6.5.2(a)", @@ -368,16 +372,10 @@ "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5", - "17.2", - "17.16", - "17.18" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2" + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "1-3-1-2", + "2-13-4" ], "emea-sau-cgiot-2024": [ "2-15-2", @@ -385,6 +383,20 @@ "4-2-3", "4-2-4" ], + "emea-sau-ecc-1-2018": [ + "1-6-2-1", + "1-6-2-2" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3", + "mp.sw.2" + ], + "emea-gbr-cap-1850-2020": [ + "A2" + ], "emea-gbr-def-stan-05-138-2024": [ "1205" ], @@ -394,8 +406,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1205" ], - "apac-aus-ism-2024-june": [ - "ISM-0100" + "apac-aus-ism-2026-march": [ + "ISM-0100", + "ISM-1967", + "ISM-1971", + "ISM-1972" + ], + "apac-aus-ps-cps-234-2019": [ + "22", + "28" ], "apac-chn-cybersecurity-law-2017": [ "Article 35" @@ -414,7 +433,14 @@ "14.2.9.3", "14.2.9.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.6", + "10.8", + "10.9", + "16.4" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP68", "HML67" ], @@ -426,18 +452,30 @@ "4.3.20.C.01", "4.3.20.C.02", "4.3.20.C.03", - "6.3.8.C.01" + "6.3.8.C.01", + "11.1.19.C.01", + "16.1.30.C.01", + "16.7.41.C.01", + "20.1.21.C.01", + "20.1.21.C.07", + "20.1.22.C.03", + "20.1.23.C.01", + "23.5.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2" + "4.5.1", + "5.6.2", + "6.1.6" ], "americas-bmu-mba-coc-2020": [ - "5.14" + "6.15-BP2" ], "americas-can-osfi-b13-2022": [ "2.4.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.4" + ], "americas-can-itsp-10-171-2025": [ "03.12.01" ] diff --git a/docs/api/controls/IAO-03.1.json b/docs/api/controls/IAO-03.1.json index 9eca1abf..7254638d 100644 --- a/docs/api/controls/IAO-03.1.json +++ b/docs/api/controls/IAO-03.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to plan and coordinate Information Assurance Program (IAP) activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to plan and coordinate Information Assurance Program (IAP) activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { diff --git a/docs/api/controls/IAO-03.2.json b/docs/api/controls/IAO-03.2.json index dc8de912..526246b0 100644 --- a/docs/api/controls/IAO-03.2.json +++ b/docs/api/controls/IAO-03.2.json @@ -2,8 +2,8 @@ "control_id": "IAO-03.2", "title": "Adequate Security for Sensitive / Regulated Data In Support of Contracts", "family": "IAO", - "description": "Mechanisms exist to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", - "scf_question": "Does the organization protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract?", + "description": "Mechanisms exist to protect sensitive and/or regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", + "scf_question": "Does the organization protect sensitive and/or regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -140,10 +141,10 @@ "CAL2.-3.12.4" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "usa-state-co-privacy-act-2021": [ "6-1-1305(3)(b)" @@ -156,21 +157,26 @@ "SA-04-SID", "SA-09-SID" ], - "emea-deu-c5-2020": [ - "HR-06", - "PI-02" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" ], - "emea-isr-cmo-1-0": [ - "16.5" + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "emea-deu-c5-2020": [ + "BEI-02", + "BEI-02-BP1", + "BEI-02-BP2", + "BEI-02-BP3", + "BEI-02-BP4" ], - "emea-srb-act-9-2018": [ - "5", - "11" + "emea-gbr-cap-1850-2020": [ + "A2", + "B1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0072", "ISM-1451", "ISM-1571", @@ -179,9 +185,6 @@ "ISM-1574", "ISM-1575" ], - "apac-jpn-ppi-2020": [ - "22" - ], "apac-jpn-ismap": [ "13.2.2", "13.2.2.2", @@ -197,20 +200,8 @@ "apac-nzl-ism-3-9": [ "2.2.5.C.02" ], - "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" - ], - "apac-sgp-mas-trm-2021": [ - "5.4.3" - ], - "amaericas-can-osfi-self-assessment": [ - "4.26", - "4.28" + "americas-bhs-dpa-2003": [ + "V.51(1)(a)" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAO-03.json b/docs/api/controls/IAO-03.json index 2d21eb1d..48fba364 100644 --- a/docs/api/controls/IAO-03.json +++ b/docs/api/controls/IAO-03.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ 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).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate authoritative documentation (e.g., System Security Plan (SSP)) that:\n(1) Identifies key architectural and implementation information on in-scope Technology Assets, Applications and/or Services (TAAS);\n(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\n(3) Provides a historical record of applied security controls, including changes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -91,9 +91,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -201,6 +201,8 @@ "3.12.4" ], "general-nist-800-171-r3": [ + "03.01.16.a", + "03.04.11.a", "03.04.11.b", "03.15.02.a", "03.15.02.a.01", @@ -224,6 +226,7 @@ "3.12.4[h]" ], "general-nist-800-171a-r3": [ + "A.03.01.16.a[01]", "A.03.04.11.a[02]", "A.03.04.11.a[03]", "A.03.04.11.b[01]", @@ -238,14 +241,50 @@ "A.03.15.02.a.07", "A.03.15.02.a.08", "A.03.15.02.b[01]", - "A.03.15.02.b[02]", - "A.03.15.02.c" - ], - "general-nist-800-172": [ - "3.11.4e" - ], - "general-scf-dpmp-2025": [ - "5.13" + "A.03.15.02.b[02]" + ], + "general-nist-800-172-r3": [ + "03.01.04E", + "03.01.06E", + "03.13.11E", + "03.13.14E", + "03.13.16E", + "03.14.08E", + "03.14.10E", + "03.14.14E", + "03.14.15E", + "03.14.16E", + "03.15.01E", + "03.15.02E", + "03.15.03E", + "03.16.01E", + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.04E.ODP[02]", + "DS-A.03.01.06E", + "A.03.13.11E.ODP[01]", + "A.03.13.14E.ODP[01]", + "A.03.13.16E.ODP[03]", + "A.03.14.08E.ODP[01]", + "A.03.14.08E.ODP[03]", + "A.03.14.08E.ODP[05]", + "A.03.14.08E.ODP[07]", + "A.03.14.08E.ODP[11]", + "A.03.14.10E.ODP[02]", + "A.03.14.14E.ODP[01]", + "A.03.14.15E.ODP[01]", + "A.03.14.16E.ODP[01]", + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.03", + "DS-A.03.15.01E.b", + "DS-A.03.15.01E.c", + "DS-A.03.15.02E.b", + "A.03.15.02E.ODP[01]", + "A.03.15.03E.ODP[01]", + "A.03.15.03E.ODP[02]", + "A.03.16.01E.ODP[02]", + "A.03.17.02E.ODP[01]" ], "usa-federal-fbi-cjis-6-0": [ "PL-2" @@ -271,6 +310,27 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PL-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)", + "101.630(a)", + "101.630(c)", + "101.630(c)(1)", + "101.630(c)(2)", + "101.630(c)(3)", + "101.630(c)(4)", + "101.630(c)(5)", + "101.630(c)(6)", + "101.630(c)(7)", + "101.630(c)(8)", + "101.630(c)(9)", + "101.630(c)(10)", + "101.630(c)(11)", + "101.630(c)(12)", + "101.630(c)(13)", + "101.630(c)(14)", + "101.650(c)", + "101.650(e)(1)(v)" + ], "usa-federal-irs-1075-2021": [ "2.E.4.3", "2.E.4.3-1.1", @@ -334,8 +394,40 @@ "emea-eu-ai-act-2024": [ "Article 11.1" ], - "emea-qat-pdppl-2020": [ - "11.1" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 13(3)", + "Article 13(7)", + "Article 19(2)(b)", + "Article 31(1)", + "Article 31(2)", + "Article 31(3)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "emea-deu-bsrit-2017": [ + "3.6" + ], + "emea-deu-c5-2020": [ + "UP-01-BP2", + "UP-01-BP3", + "UP-01-BP5" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(e)", + "Article 15(2)" + ], + "emea-gbr-cap-1850-2020": [ + "A2", + "A3", + "B1", + "B4" ], "emea-gbr-def-stan-05-138-2024": [ "2301" @@ -346,9 +438,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0041", - "ISM-0432" + "ISM-0432", + "ISM-0912", + "ISM-1912", + "ISM-2005" ], "apac-jpn-ismap": [ "4.4.4", @@ -370,7 +465,16 @@ "5.4.5.C.02", "5.4.5.C.03" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(a)" + ], + "americas-arg-ppd-2018": [ + "B.2.1-1", + "E.1.1-3" + ], "americas-can-itsp-10-171-2025": [ + "03.01.16.A", + "03.04.11.A", "03.04.11.B", "03.15.02.A", "03.15.02.A.01", diff --git a/docs/api/controls/IAO-04.json b/docs/api/controls/IAO-04.json index aaa330b0..0893e0be 100644 --- a/docs/api/controls/IAO-04.json +++ b/docs/api/controls/IAO-04.json @@ -3,7 +3,7 @@ "title": "Threat Analysis & Flaw Remediation During Development", "family": "IAO", "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.", - "scf_question": "Does the organization require system developers and integrators to create and execute a Security Testing and Evaluation (ST&E) plan to identify and remediate flaws during development?", + "scf_question": "Does the organization 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?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -255,9 +256,39 @@ "SA-11(CE-5).a", "SA-11(CE-5).b" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(6)", + "Article 13(21)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(2)", + "Annex I, Part II(3)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], + "emea-sau-cscc-1-2019": [ + "1-3-2-1" + ], + "emea-sau-ecc-1-2018": [ + "1-5-3" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.10" + ], "apac-nzl-ism-3-9": [ "6.2.5.C.01", "6.2.6.C.01" @@ -265,8 +296,8 @@ "apac-sgp-mas-trm-2021": [ "5.7.5" ], - "amaericas-can-osfi-self-assessment": [ - "2.7" + "americas-can-osfi-self-assessment-2": [ + "2.4.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAO-05.1.json b/docs/api/controls/IAO-05.1.json index ea663c15..408fbd73 100644 --- a/docs/api/controls/IAO-05.1.json +++ b/docs/api/controls/IAO-05.1.json @@ -61,9 +61,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-nist-800-53-r4": [ diff --git a/docs/api/controls/IAO-05.json b/docs/api/controls/IAO-05.json index 5ce7d9ac..64d9e713 100644 --- a/docs/api/controls/IAO-05.json +++ b/docs/api/controls/IAO-05.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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:\n(1) Deficiency tracking number;\n(2) Applicable security, compliance and/or resilience control;\n(3) Description of the deficiency(ies);\n(4) Risk associated with the deficiency(ies);\n(5) Source deficiency identification/detection;\n(6) Temporary compensating controls, if applicable;\n(7) Point of Contact (POC) (e.g., asset/process owner);\n(8) Resources required to conduct remediation actions;\n(9) Planned remedial actions to the deficiency(ies);\n(10) Proposed remediation timeline; and\n(11) Disposition statement (e.g., closeout summary).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -90,9 +90,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -244,20 +244,20 @@ "3.12.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.04.11.b[01]", + "A.03.04.11.b[02]", "A.03.12.02.a.01", "A.03.12.02.a.02", "A.03.12.02.b.01", "A.03.12.02.b.02", - "A.03.12.02.b.03" + "A.03.12.02.b.03", + "A.03.14.01.a[01]" ], "general-nist-csf-2-0": [ "ID.RA-01", "ID.IM-01", "ID.IM-02" ], - "general-scf-dpmp-2025": [ - "9.3" - ], "general-tisax-6-0-3": [ "1.5.2" ], @@ -300,6 +300,9 @@ "CA-05", "PM-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)(iv)" + ], "usa-federal-irs-1075-2021": [ "2.E.5", "2.E.5-1", @@ -341,8 +344,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-05" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(d)" + "3.3.1.13(d)", + "3.3.6.27", + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "emea-eu-nis2-2022": [ "Article 21.4" @@ -350,13 +360,25 @@ "emea-eu-nis2-annex-2024": [ "6.5.2(d)" ], + "emea-deu-bsrit-2017": [ + "3.8" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 4" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], "emea-sau-otcc-1-2022": [ - "1-3-1-6" + "1-3-1-7" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.4-2.2" ], "emea-uae-niaf-2023": [ "3.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1564" ], "apac-jpn-ismap": [ @@ -364,16 +386,13 @@ "4.7.1.4", "4.7.1.7" ], + "apac-mys-bnm-rmit-2025": [ + "10.8" + ], "apac-nzl-ism-3-9": [ "4.2.12.C.01", "6.3.8.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.5.2" - ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-itsp-10-171-2025": [ "03.04.11.B", "03.12.02.A", diff --git a/docs/api/controls/IAO-06.json b/docs/api/controls/IAO-06.json index c24f570e..b70529e7 100644 --- a/docs/api/controls/IAO-06.json +++ b/docs/api/controls/IAO-06.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -105,9 +105,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -232,13 +232,34 @@ "CA-02", "CM-04 (02)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5" + "emea-deu-bsrit-2017": [ + "7.11" + ], + "emea-sau-cscc-1-2019": [ + "1-3-1-2", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-3-5" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72", + "VII.B.TPC-73" + ], + "emea-gbr-cap-1850-2020": [ + "A2" ], "emea-gbr-def-stan-05-138-2024": [ "1205" @@ -248,6 +269,13 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "1205" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8" + ], + "apac-sgp-mas-trm-2021": [ + "5.7.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/IAO-07.json b/docs/api/controls/IAO-07.json index 3472739e..5b3491f5 100644 --- a/docs/api/controls/IAO-07.json +++ b/docs/api/controls/IAO-07.json @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -186,9 +187,6 @@ "general-nist-800-161-r1-level-3": [ "CA-6" ], - "general-scf-dpmp-2025": [ - "7.11" - ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.Q" ], @@ -244,21 +242,44 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-06" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5" + "emea-deu-bsrit-2017": [ + "7.11" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-51" + "VII.B.TPC-72", + "VII.B.TPC-73" + ], + "emea-esp-decree-311-2022": [ + "Article 21(1)" + ], + "emea-gbr-cap-1850-2020": [ + "A2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0027", "ISM-0293", - "ISM-1525" + "ISM-1525", + "ISM-1968" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.15" ], "apac-nzl-ism-3-9": [ "2.2.5.C.01", @@ -266,8 +287,15 @@ "4.5.18.C.01", "4.5.18.C.02", "4.5.18.C.03", + "20.1.21.C.04", + "20.1.22.C.01", + "20.1.22.C.03", + "20.1.22.C.05", "23.2.16.C.03", "23.2.16.C.04" + ], + "apac-sgp-mas-trm-2021": [ + "5.7.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-01.json b/docs/api/controls/IRO-01.json index 99cf8a7b..ab1b5c3c 100644 --- a/docs/api/controls/IRO-01.json +++ b/docs/api/controls/IRO-01.json @@ -117,7 +117,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -149,7 +150,7 @@ "4.1.3" ], "general-cis-csc-8-1": [ - "17.0", + "17", "17.5" ], "general-cis-csc-8-1-ig2": [ @@ -282,6 +283,12 @@ "general-nist-800-171a-r3": [ "A.03.06.01[01]" ], + "general-nist-800-172-r3": [ + "03.11.09E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.09E.ODP[02]" + ], "general-nist-csf-2-0": [ "GV.SC-08", "DE.AE", @@ -305,9 +312,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-shared-assessments-sig-2025": [ "J.4" ], @@ -374,14 +378,14 @@ "314.4(h)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "usa-federal-irs-1075-2021": [ "1.8.4", @@ -435,18 +439,8 @@ "IR-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60" ], "emea-eu-dora-2023": [ "Article 9.4(b)", @@ -473,55 +467,42 @@ "3.5.1", "4.3.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-eu-psd2-2015": [ + "95(1)" ], "emea-deu-bsrit-2017": [ "4.7" ], "emea-deu-c5-2020": [ - "SIM-01" + "UP-01-BP4", + "SIM-01", + "SIM-07" ], - "emea-isr-cmo-1-0": [ - "24.1" + "emea-qat-pdppl-2020": [ + "3.11.5" ], "emea-sau-ecc-1-2018": [ "2-13-1", "2-13-2", - "2-13-3", - "2-13-3-2", - "2-13-4" + "2-13-3-1" ], "emea-sau-otcc-1-2022": [ - "2-12", "2-12-1", "2-12-2" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88", - "TPC-89" + "VII.A.TPC-23" ], "emea-sau-sama-csf-1-2017": [ - "3.3.15" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.3", - "22" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1" + "3.3.15.1" ], "emea-esp-decree-311-2022": [ - "25.1" + "Article 8(4)", + "Article 12(6)(m)", + "Article 25(1)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.7 [OP.EXP.7]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7" ], "emea-uae-niaf-2023": [ "3.3", @@ -530,6 +511,9 @@ "emea-gbr-caf-4-0": [ "D1" ], + "emea-gbr-cap-1850-2020": [ + "D1" + ], "emea-gbr-def-stan-05-138-2024": [ "3105", "4104" @@ -545,18 +529,17 @@ "3105", "4104" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0137", "ISM-0576", "ISM-1609", "ISM-1618" ], "apac-aus-ps-cps-230-2023": [ - "32" + "16(d)" ], "apac-aus-ps-cps-234-2019": [ - "23", - "24" + "23" ], "apac-ind-sebi-2024": [ "RS.MA.S1" @@ -575,6 +558,11 @@ "16.1.1.11.P", "16.1.1.12.P" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.2", + "11.12" + ], "apac-nzl-ism-3-9": [ "7.1.7.C.01", "7.1.7.C.02", @@ -583,37 +571,28 @@ ], "apac-sgp-mas-trm-2021": [ "7.7.1", - "7.7.2", - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "7.7.4", - "7.7.5", - "7.7.6", - "7.7.7" + "7.7.2" + ], + "americas-arg-ppd-2018": [ + "E.1.2-11", + "G" ], "americas-bmu-mba-coc-2020": [ - "6.1", + "5.3-BP3", + "6.1-BP4", "6.3", "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], "americas-can-osfi-b13-2022": [ "2.7", "2.7.2", "3.3", "3.4.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.1", + "3.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.01" ] diff --git a/docs/api/controls/IRO-02.1.json b/docs/api/controls/IRO-02.1.json index 19d166e0..887ab433 100644 --- a/docs/api/controls/IRO-02.1.json +++ b/docs/api/controls/IRO-02.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically support the incident handling process.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically support the incident handling process. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -99,7 +99,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -170,9 +171,6 @@ ], "emea-eu-dora-2023": [ "Article 9.4(b)" - ], - "emea-isr-cmo-1-0": [ - "24.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-02.2.json b/docs/api/controls/IRO-02.2.json index 91e373fe..2c3cd1e7 100644 --- a/docs/api/controls/IRO-02.2.json +++ b/docs/api/controls/IRO-02.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to implement and govern an insider threat program.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to implement and govern an insider threat program. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -152,7 +153,7 @@ "usa-federal-irs-1075-2021": [ "IR-4(CE-6)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ] diff --git a/docs/api/controls/IRO-02.3.json b/docs/api/controls/IRO-02.3.json index 7de33612..2272324b 100644 --- a/docs/api/controls/IRO-02.3.json +++ b/docs/api/controls/IRO-02.3.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically dynamically reconfigure system components as part of the incident response capability.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically dynamically reconfigure system components as part of the incident response capability. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -58,7 +58,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { diff --git a/docs/api/controls/IRO-02.4.json b/docs/api/controls/IRO-02.4.json index 17f7f277..997165a0 100644 --- a/docs/api/controls/IRO-02.4.json +++ b/docs/api/controls/IRO-02.4.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -198,6 +199,11 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "IR-08-SID" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(5)", + "Article 14(5)(a)", + "Article 14(5)(b)" + ], "emea-eu-nis2-2022": [ "Article 23.3", "Article 23.3(a)", @@ -208,11 +214,18 @@ "3.4.1", "3.4.2(a)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 33.4" + "emea-deu-bsrit-2017": [ + "4.7" + ], + "emea-deu-c5-2020": [ + "SIM-03", + "SIM-07" + ], + "emea-isr-cmo-2-0": [ + "Appendix B" ], - "emea-esp-decree-311-2022": [ - "33.4" + "emea-sau-ecc-1-2018": [ + "2-13-3-2" ], "apac-ind-sebi-2024": [ "RS.AN.S2" @@ -222,9 +235,16 @@ "16.1.4.1", "16.1.4.2" ], + "americas-bmu-mba-coc-2020": [ + "6.4" + ], "americas-can-osfi-b13-2022": [ "2.7", "3.4.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2", + "3.4.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-02.5.json b/docs/api/controls/IRO-02.5.json index f2192dc0..c820f4d7 100644 --- a/docs/api/controls/IRO-02.5.json +++ b/docs/api/controls/IRO-02.5.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate with approved third-parties to achieve a cross-organization perspective on incident awareness and more effective incident responses.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate with approved third-parties to achieve a cross-organization perspective on incident awareness and more effective incident responses. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -135,9 +136,6 @@ "usa-federal-irs-1075-2021": [ "IR-4(CE-8)" ], - "emea-deu-c5-2020": [ - "OPS-21" - ], "apac-ind-sebi-2024": [ "GV.SC.S6", "RS.CO.S3", @@ -145,9 +143,6 @@ ], "apac-nzl-ism-3-9": [ "7.3.10.C.01" - ], - "amaericas-can-osfi-self-assessment": [ - "3.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-02.6.json b/docs/api/controls/IRO-02.6.json index d6fc4753..5235ae06 100644 --- a/docs/api/controls/IRO-02.6.json +++ b/docs/api/controls/IRO-02.6.json @@ -59,7 +59,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -89,10 +90,6 @@ ], "emea-eu-dora-2023": [ "Article 9.4(b)" - ], - "amaericas-can-osfi-self-assessment": [ - "4.13", - "4.15" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-02.json b/docs/api/controls/IRO-02.json index 0201e329..ed4da004 100644 --- a/docs/api/controls/IRO-02.json +++ b/docs/api/controls/IRO-02.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.\n▪ IT and/or cybersecurity personnel operate facilitate basic forensic investigations in the event of a suspected or confirmed security incident.\n▪ The IRP contains eDiscovery processes to support Federal Rules of Civil Procedure (FRCP) requirements for eDiscovery practices.\n▪ IT personnel support incident response operations by provisioning and deprovisioning incident responders with temporary emergency accounts.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to cover:\n(1) Preparation;\n(2) Automated event detection or manual incident report intake;\n(3) Analysis;\n(4) Containment;\n(5) Eradication; and\n(6) Recovery.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -109,7 +109,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -146,7 +147,7 @@ ], "general-cis-csc-8-1": [ "2.3", - "17.0", + "17", "17.1", "17.3", "17.4", @@ -303,7 +304,8 @@ "03.06.02.a", "03.06.02.b", "03.06.02.c", - "03.06.02.d" + "03.06.02.d", + "03.06.05.b" ], "general-nist-800-171a": [ "3.6.1[a]", @@ -321,12 +323,24 @@ "3.6.2[f]" ], "general-nist-800-171a-r3": [ + "A.03.03.04.b", "A.03.06.01[02]", "A.03.06.01[03]", "A.03.06.01[04]", "A.03.06.01[05]", "A.03.06.01[06]", - "A.03.06.02.b" + "A.03.06.02.a[01]", + "A.03.06.02.a[02]", + "A.03.06.02.b", + "A.03.06.02.c", + "A.03.06.02.d", + "A.03.06.05.b[01]" + ], + "general-nist-800-172-r3": [ + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.03E.ODP[02]" ], "general-nist-csf-2-0": [ "GV.SC-08", @@ -362,10 +376,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.5" ], - "general-scf-dpmp-2025": [ - "8.0", - "8.1" - ], "general-swift-cscf-2025": [ "6.1", "6.2", @@ -438,6 +448,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(4)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)", "248.30(a)(3)(i)", @@ -454,14 +467,14 @@ "314.4(h)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(6)(ii)", - "164.412", - "164.412(a)", - "164.412(b)", - "164.530(f)" + "§ 164.308(a)(6)(ii)", + "§ 164.412", + "§ 164.412(a)", + "§ 164.412(b)", + "§ 164.530(f)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(6)(ii)" + "§ 164.308(a)(6)(ii)" ], "usa-federal-irs-1075-2021": [ "IR-4" @@ -513,18 +526,18 @@ "IR-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60", + "3.5.1.60(a)", + "3.5.1.60(b)", + "3.5.1.60(c)", + "3.5.1.60(d)", + "3.5.1.60(d)(i)", + "3.5.1.60(d)(ii)", + "3.5.1.60(e)", + "3.5.1.60(f)", + "3.5.1.60(f)(i)", + "3.5.1.60(f)(ii)" ], "emea-eu-dora-2023": [ "Article 9.4(b)", @@ -556,47 +569,40 @@ "emea-deu-bsrit-2017": [ "4.7" ], - "emea-deu-c5-2020": [ - "SIM-02" - ], - "emea-isr-cmo-1-0": [ - "7.2", - "24.2" + "emea-isr-cmo-2-0": [ + "Appendix A, 12.1" ], "emea-sau-cgiot-2024": [ "2-12-2" ], - "emea-sau-ecc-1-2018": [ - "2-13-3-2" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-1", - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5", - "2-12-2-6", - "2-12-2-7", - "2-12-2-8" + "2-12-1-3", + "2-12-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88", - "TPC-89" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1", - "Article 25.2", - "Article 33.4" + "VII.B.TPC-89" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.15.3", + "3.3.15.4", + "3.3.15.4.a", + "3.3.15.4.b", + "3.3.15.4.c", + "3.3.15.4.d", + "3.3.15.4.e", + "3.3.15.4.f", + "3.3.15.4.g", + "3.3.15.4.h", + "3.3.15.4.i", + "3.3.15.4.j" ], "emea-esp-decree-311-2022": [ - "25.1", - "25.2", - "33.4" + "Article 25(2)", + "Article 34(1)(a)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.7 [OP.EXP.7]", - "7.3.9 [OP.EXP.9]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7", + "op.exp.9" ], "emea-uae-niaf-2023": [ "3.3.1", @@ -605,6 +611,9 @@ "emea-gbr-caf-4-0": [ "D1.b" ], + "emea-gbr-cap-1850-2020": [ + "D1" + ], "emea-gbr-def-stan-05-138-2024": [ "3105", "4104" @@ -630,25 +639,22 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0123", "ISM-0141", "ISM-0917", "ISM-1618", - "ISM-1803" - ], - "apac-aus-ps-cps-230-2023": [ - "32" + "ISM-1803", + "ISM-1819" ], "apac-aus-ps-cps-234-2019": [ - "23", - "24" + "23" + ], + "apac-chn-data-security-law-2021": [ + "Article 29" ], "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "Article 57" ], "apac-ind-sebi-2024": [ "RS.MA.S2" @@ -676,7 +682,13 @@ "16.1.3.2", "16.1.5.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.35", + "11.3", + "11.11" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP07", "HML07" ], @@ -685,20 +697,30 @@ ], "apac-nzl-ism-3-9": [ "5.7.4.C.01", - "7.2.17.C.01", - "7.2.17.C.02", "7.2.18.C.01", + "7.2.18.C.02", "7.2.19.C.01", "7.3.9.C.01", - "7.3.10.C.01" + "7.3.10.C.01", + "20.1.25.C.02" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(2)" ], "apac-sgp-mas-trm-2021": [ + "7.7.2", + "7.7.3", "7.7.3(a)", "7.7.3(b)", "7.7.3(c)" ], - "americas-bra-lgpd-2018": [ - "48" + "americas-arg-ppd-2018": [ + "E.1.2-10", + "E.1.2-11", + "G.1.1-1" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7", @@ -710,13 +732,21 @@ "3.4.3", "3.4.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.1", + "2.7.2", + "2.7.3", + "3", + "3.4.1" + ], "americas-can-itsp-10-171-2025": [ "03.03.04.B", "03.06.01", "03.06.02.A", "03.06.02.B", "03.06.02.C", - "03.06.02.D" + "03.06.02.D", + "03.06.05.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-03.json b/docs/api/controls/IRO-03.json index b725649e..f8261017 100644 --- a/docs/api/controls/IRO-03.json +++ b/docs/api/controls/IRO-03.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to define specific Indicators of Compromise (IOC) to identify the signs of potential cybersecurity events.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -102,6 +103,20 @@ "general-nist-800-171-r2": [ "3.14.7" ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.02.01E", + "03.11.02E", + "03.11.09E", + "03.14.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.08E.ODP[01]", + "A.03.02.01E.ODP[01]", + "DS-A.03.11.02E.a.01[01]", + "A.03.11.09E.ODP[01]", + "A.03.14.17E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.CM" ], @@ -138,8 +153,8 @@ "emea-deu-bsrit-2017": [ "5.4" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-12" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-80" ], "emea-gbr-caf-4-0": [ "C1.f" @@ -156,13 +171,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3201" ], - "apac-nzl-ism-3-9": [ - "7.2.17.C.01", - "7.2.17.C.02" + "apac-sgp-mas-trm-2021": [ + "11.3.5" ], "americas-can-osfi-b13-2022": [ "2.7.2", "3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-04.1.json b/docs/api/controls/IRO-04.1.json index 0743237e..791654ac 100644 --- a/docs/api/controls/IRO-04.1.json +++ b/docs/api/controls/IRO-04.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address data breaches, or other incidents involving the unauthorized disclosure of sensitive or regulated data, according to applicable laws, regulations and contractual obligations.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address data breaches, or other incidents involving the unauthorized disclosure of sensitive or regulated data, according to applicable laws, regulations and contractual obligations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -132,32 +133,29 @@ "general-nist-800-82-r3": [ "IR-08(01)" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "usa-federal-fbi-cjis-6-0": [ "IR-8(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.404(a)(1)", - "164.404(a)(2)", - "164.404(c)(1)(A)", - "164.404(c)(1)(B)", - "164.404(c)(1)(C)", - "164.404(c)(1)(D)", - "164.404(c)(1)(E)", - "164.404(c)(2)", - "164.404(d)(1)(i)", - "164.404(d)(1)(ii)", - "164.404(d)(2)", - "164.404(d)(2)(i)", - "164.404(d)(2)(ii)(A)", - "164.404(d)(2)(ii)(B)", - "164.404(d)(3)", - "164.406(a)", - "164.406(b)", - "164.406(c)", - "164.410(c)(1)" + "§ 164.404(a)(1)", + "§ 164.404(a)(2)", + "§ 164.404(c)(1)(A)", + "§ 164.404(c)(1)(B)", + "§ 164.404(c)(1)(C)", + "§ 164.404(c)(1)(D)", + "§ 164.404(c)(1)(E)", + "§ 164.404(c)(2)", + "§ 164.404(d)(1)(i)", + "§ 164.404(d)(1)(ii)", + "§ 164.404(d)(2)", + "§ 164.404(d)(2)(i)", + "§ 164.404(d)(2)(ii)(A)", + "§ 164.404(d)(2)(ii)(B)", + "§ 164.404(d)(3)", + "§ 164.406(a)", + "§ 164.406(b)", + "§ 164.406(c)", + "§ 164.410(c)(1)" ], "usa-federal-irs-1075-2021": [ "IR-8(CE-1)", @@ -168,78 +166,25 @@ "emea-eu-gdpr-2016": [ "Article 33.1" ], - "emea-deu-c5-2020": [ - "SIM-02" - ], - "emea-ken-pda-2019": [ - "43(1)(b)", - "43(2)", - "43(3)", - "43(4)", - "43(5)", - "43(5)(a)", - "43(5)(b)", - "43(5)(c)", - "43(5)(d)", - "43(5)(e)", - "43(6)", - "43(7)", - "43(8)(a)", - "43(8)(b)", - "43(8)(c)" - ], - "emea-qat-pdppl-2020": [ - "14" + "emea-deu-fdpa-2017": [ + "3.4.65(1)", + "3.4.65(2)" ], "emea-sau-pdpl-2023": [ "Article 20.1", "Article 20.2" ], - "emea-srb-act-9-2018": [ - "53", - "53.1", - "53.2", - "53.3" - ], - "emea-zaf-popia-2013": [ - "22" - ], - "emea-che-fadp-2025": [ - "12" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], "apac-ind-dpdpa-2023": [ "8(6)" ], - "apac-jpn-ppi-2020": [ - "22-2(1)", - "22-2(2)" - ], - "apac-phl-dpa-2012": [ - "38" - ], "apac-kor-pipa-2011": [ - "34" - ], - "apac-twn-pdpa-2025": [ - "12" - ], - "americas-bra-lgpd-2018": [ - "48" + "IV.34(2)" ], - "americas-mex-fdpa-2010": [ - "20" + "americas-bhs-dpa-2003": [ + "V.48(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-04.2.json b/docs/api/controls/IRO-04.2.json index 2563ab98..4533d860 100644 --- a/docs/api/controls/IRO-04.2.json +++ b/docs/api/controls/IRO-04.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ On at least an annual basis, IT and/or cybersecurity personnel update incident response strategies to keep current with business needs, technology changes and regulatory requirements.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to regularly review and modify incident response practices to incorporate lessons learned, business process changes and industry developments, as necessary.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -162,7 +163,6 @@ "NFO - IR-1" ], "general-nist-800-171-r3": [ - "03.06.04.b", "03.06.05.c" ], "general-nist-800-171a-r3": [ @@ -236,14 +236,10 @@ "EV.ST.S3", "RS.IM.S2" ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-osfi-b13-2022": [ "2.7.3" ], "americas-can-itsp-10-171-2025": [ - "03.06.04.B", "03.06.05.C" ] } diff --git a/docs/api/controls/IRO-04.3.json b/docs/api/controls/IRO-04.3.json index 1a6e5053..0b53d7c8 100644 --- a/docs/api/controls/IRO-04.3.json +++ b/docs/api/controls/IRO-04.3.json @@ -3,7 +3,7 @@ "title": "Continuous Incident Response Improvements", "family": "IRO", "description": "Mechanisms exist to use qualitative and quantitative data from incident response testing to: \n(1) Determine the effectiveness of incident response processes;\n(2) Continuously improve incident response processes; and\n(3) Provide incident response measures and metrics that are accurate, consistent and in a reproducible format.", - "scf_question": "Does the organization use qualitative and quantitative data from incident response testing to: \n (1) Determine the effectiveness of incident response processes;\n (2) Continuously improve incident response processes; and\n (3) Provide incident response measures and metrics that are accurate, consistent, and in a reproducible format?", + "scf_question": "Does the organization use qualitative and quantitative data from incident response testing to: \n(1) Determine the effectiveness of incident response processes;\n(2) Continuously improve incident response processes; and\n(3) Provide incident response measures and metrics that are accurate, consistent and in a reproducible format?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -104,6 +105,9 @@ "general-nist-800-171-r3": [ "03.06.04.b" ], + "general-nist-800-171a-r3": [ + "A.03.06.04.b[03]" + ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.S" ], @@ -113,9 +117,16 @@ "IR-3(CE-3).b", "IR-3(CE-3).c" ], + "emea-gbr-cap-1850-2020": [ + "D2" + ], "apac-jpn-ismap": [ "16.1.1.14" ], + "apac-sgp-mas-trm-2021": [ + "7.8.3", + "12.3.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.04.B" ] diff --git a/docs/api/controls/IRO-04.json b/docs/api/controls/IRO-04.json index b25cf038..aede1c58 100644 --- a/docs/api/controls/IRO-04.json +++ b/docs/api/controls/IRO-04.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain and make available a current and viable Incident Response Plan (IRP) to all stakeholders.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -109,7 +109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -283,9 +284,11 @@ "03.06.05.a.04", "03.06.05.a.05", "03.06.05.a.06", - "03.06.05.b" + "03.06.05.b", + "03.06.05.d" ], "general-nist-800-171a-r3": [ + "A.03.06.01[01]", "A.03.06.02.ODP[01]", "A.03.06.02.ODP[02]", "A.03.06.05.a.01", @@ -345,9 +348,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.10.1" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-swift-cscf-2025": [ "7.1" ], @@ -390,6 +390,10 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-08" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(6)", + "101.650(g)(2)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)" ], @@ -471,18 +475,8 @@ "IR-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60" ], "emea-eu-dora-2023": [ "Article 17.1", @@ -501,38 +495,28 @@ "3.5.1", "6.10.2(d)" ], - "emea-isr-cmo-1-0": [ - "7.2", - "24.2", - "24.3", - "24.8", - "24.9" + "emea-deu-c5-2020": [ + "SIM-03" ], "emea-sau-cgiot-2024": [ "2-12-1", "2-12-2" ], "emea-sau-ecc-1-2018": [ - "2-13-3-1", - "2-13-3-2" + "2-13-3-1" ], "emea-sau-otcc-1-2022": [ - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5" + "2-12-1-1", + "2-12-1-3", + "2-12-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1", - "Article 25.2" + "VII.A.TPC-23-BP2", + "VII.B.TPC-88" ], - "emea-esp-decree-311-2022": [ - "25.1", - "25.2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7", + "op.exp.9" ], "emea-gbr-caf-4-0": [ "D1.a" @@ -549,27 +533,21 @@ "4101", "4102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0043", "ISM-0576", "ISM-0917", "ISM-1784" ], "apac-aus-ps-cps-234-2019": [ - "23", "24", + "25", "25(a)", "25(b)" ], "apac-chn-cybersecurity-law-2017": [ "Article 25" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], "apac-ind-sebi-2024": [ "DE.DP.S2", "GV.RM.S3", @@ -587,12 +565,14 @@ "16.1.5.7", "16.1.5.8" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HHSP07", - "HML07" + "apac-mys-bnm-rmit-2025": [ + "10.20", + "11.3", + "11.13" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS20" + "HHSP07", + "HML07" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP07" @@ -606,32 +586,22 @@ "7.3.5.C.01", "7.3.9.C.01", "7.3.10.C.01", - "16.1.47.C.01" + "16.4.39.C.02", + "16.4.42.C.01" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(2)", + "6A.26C(4)" ], "apac-sgp-mas-trm-2021": [ - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "12.3.1", - "12.3.2", - "12.3.3" + "12.3.1" ], - "apac-kor-pipa-2011": [ - "34" + "americas-arg-ppd-2018": [ + "G.1.1-1" ], "americas-bmu-mba-coc-2020": [ "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], "americas-can-osfi-b13-2022": [ "2.7.1", "2.7.2", @@ -646,7 +616,8 @@ "03.06.05.A.04", "03.06.05.A.05", "03.06.05.A.06", - "03.06.05.B" + "03.06.05.B", + "03.06.05.D" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-05.1.json b/docs/api/controls/IRO-05.1.json index d23ec962..9862fb8a 100644 --- a/docs/api/controls/IRO-05.1.json +++ b/docs/api/controls/IRO-05.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate simulated events into incident response training to facilitate effective response by personnel in crisis situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -124,9 +125,6 @@ ], "usa-federal-irs-1075-2021": [ "IR-2(CE-1)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-05.2.json b/docs/api/controls/IRO-05.2.json index c438deee..5563c885 100644 --- a/docs/api/controls/IRO-05.2.json +++ b/docs/api/controls/IRO-05.2.json @@ -83,7 +83,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { diff --git a/docs/api/controls/IRO-05.json b/docs/api/controls/IRO-05.json index d1d7379c..dd956610 100644 --- a/docs/api/controls/IRO-05.json +++ b/docs/api/controls/IRO-05.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders are proficient on their specific IRP role(s) and responsibilities through recurring training events (e.g., annual rock drill).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to train personnel in their incident response roles and responsibilities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -166,15 +167,8 @@ "03.06.04.a.03" ], "general-nist-800-171a-r3": [ - "A.03.06.04.ODP[01]", - "A.03.06.04.ODP[02]", - "A.03.06.04.ODP[03]", - "A.03.06.04.ODP[04]", "A.03.06.04.a.01", - "A.03.06.04.b[01]", - "A.03.06.04.b[02]", - "A.03.06.04.b[03]", - "A.03.06.04.b[04]" + "A.03.06.04.a.03" ], "general-pci-dss-4-0-1": [ "12.10.4", @@ -237,22 +231,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-02" ], - "emea-isr-cmo-1-0": [ - "24.10", - "24.11" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-6" + "2-12-1-6" ], - "emea-sau-sacs-002-2022": [ - "TPC-88" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], "apac-ind-sebi-2024": [ "RS.IM.S2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" - ], "americas-can-itsp-10-171-2025": [ "03.06.04.A", "03.06.04.A.03" diff --git a/docs/api/controls/IRO-06.1.json b/docs/api/controls/IRO-06.1.json index 155e440e..12d9986b 100644 --- a/docs/api/controls/IRO-06.1.json +++ b/docs/api/controls/IRO-06.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ On at least an annual basis, IT and/or cybersecurity personnel conduct tabletop exercises to validate disaster recovery and contingency plans, in conjunction with stakeholders and any required vendors.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate incident response testing with organizational elements responsible for related plans.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate incident response testing with organizational elements responsible for related plans. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -158,20 +159,27 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-03(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(a)(1)" + ], "usa-federal-irs-1075-2021": [ "IR-3(CE-2)" ], "usa-state-tx-txramp-2-0-level-2": [ "IR-03 (02)" ], - "emea-sau-otcc-1-2022": [ - "2-12-2-8" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-mys-bnm-rmit-2025": [ + "11.3" ], "americas-can-osfi-b13-2022": [ "3.4.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-06.json b/docs/api/controls/IRO-06.json index e7fa09c6..a2374d63 100644 --- a/docs/api/controls/IRO-06.json +++ b/docs/api/controls/IRO-06.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders are proficient on their specific IRP role(s) and responsibilities through recurring training events (e.g., annual rock drill).\n▪ On at least an annual basis, IT and/or cybersecurity personnel conduct tabletop exercises to validate disaster recovery and contingency plans, in conjunction with stakeholders and any required vendors.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to formally test incident response capabilities through realistic exercises to determine the operational effectiveness of those capabilities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -197,9 +198,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.2" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-swift-cscf-2025": [ "7.1" ], @@ -224,6 +222,21 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(a)(1)", + "101.635(b)(1)", + "101.635(b)(2)", + "101.635(b)(3)", + "101.635(c)(1)", + "101.635(c)(2)", + "101.635(c)(2)(i)", + "101.635(c)(2)(ii)", + "101.635(c)(2)(iii)", + "101.635(c)(2)(iv)", + "101.635(c)(3)", + "101.635(c)(4)", + "101.635(c)(5)" + ], "usa-federal-irs-1075-2021": [ "IR-3" ], @@ -253,13 +266,11 @@ "emea-eu-nis2-annex-2024": [ "3.5.5" ], - "emea-isr-cmo-1-0": [ - "24.10", - "24.11", - "24.12" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-7" + "2-12-1-7" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-gbr-caf-4-0": [ "D1.c" @@ -276,19 +287,42 @@ "4103", "4105" ], + "apac-aus-ism-2026-march": [ + "ISM-2006" + ], + "apac-aus-ps-cps-230-2023": [ + "27(c)" + ], "apac-aus-ps-cps-234-2019": [ - "26" + "26", + "27", + "27(a)", + "27(b)", + "27(c)", + "27(d)", + "27(e)" ], "apac-ind-sebi-2024": [ "DE.DP.S2", "GV.RM.S3" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-mys-bnm-rmit-2025": [ + "11.16" + ], + "apac-sgp-mas-trm-2021": [ + "13.3.1", + "13.3.2", + "13.5.2" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" + ], "americas-can-itsp-10-171-2025": [ "03.06.03" ] diff --git a/docs/api/controls/IRO-07.json b/docs/api/controls/IRO-07.json index 4eb37660..4121f529 100644 --- a/docs/api/controls/IRO-07.json +++ b/docs/api/controls/IRO-07.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to establish an integrated team of cybersecurity, IT and business function representatives that are capable of addressing cybersecurity and data protection incident response operations.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -178,12 +179,22 @@ "general-nist-800-161-r1-level-3": [ "IR-4(11)" ], + "general-nist-800-171-r3": [ + "03.06.02.b", + "03.06.02.d" + ], "general-nist-800-171a-r3": [ "A.03.06.02.b", "A.03.06.02.d" ], - "general-nist-800-172": [ - "3.6.2e" + "general-nist-800-172-r3": [ + "03.06.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.02E[01]", + "A.03.06.02E.ODP[01]", + "DS-A.03.06.02E[02]", + "DS-A.03.06.02E[03]" ], "general-nist-csf-2-0": [ "DE.AE-06", @@ -207,9 +218,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.3" ], - "general-scf-dpmp-2025": [ - "8.1" - ], "general-tisax-6-0-3": [ "1.6.3" ], @@ -231,10 +239,6 @@ "usa-federal-sec-cybersecurity-rule-2023": [ "Form 8-K Item 1.05(a)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)" - ], "emea-eu-dora-2023": [ "Article 14.1", "Article 14.2", @@ -246,49 +250,44 @@ "3.5.3(a)", "4.3.3" ], - "emea-isr-cmo-1-0": [ - "24.7", - "24.9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-89" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 33.3" + "emea-sau-otcc-1-2022": [ + "2-12-1-4" ], - "emea-esp-decree-311-2022": [ - "33.3" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0733", "ISM-1618" ], - "apac-aus-ps-cps-234-2019": [ - "23", - "24", - "25(a)", - "25(b)" + "apac-mys-bnm-rmit-2025": [ + "11.13", + "11.14" ], "apac-nzl-ism-3-9": [ "7.2.18.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.7.5" - ], - "amaericas-can-osfi-self-assessment": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" + "7.7.5", + "7.7.6" + ], + "americas-arg-ppd-2018": [ + "G.1.1-2" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7.2", "3.3.3", "3.4.4" + ], + "americas-can-osfi-self-assessment-2": [ + "3.4.4" + ], + "americas-can-itsp-10-171-2025": [ + "03.06.02.B", + "03.06.02.D" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-08.1.json b/docs/api/controls/IRO-08.1.json index 982da16d..d162edd8 100644 --- a/docs/api/controls/IRO-08.1.json +++ b/docs/api/controls/IRO-08.1.json @@ -53,9 +53,9 @@ "MT-6", "MT-8", "MT-9", - "MT-11" + "MT-11", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Incident Response", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/IRO-08.json b/docs/api/controls/IRO-08.json index ee7b056c..37652522 100644 --- a/docs/api/controls/IRO-08.json +++ b/docs/api/controls/IRO-08.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to perform digital forensics and maintain the integrity of the chain of custody, in accordance with applicable laws, regulations and industry-recognized secure practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -110,7 +110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -188,10 +189,10 @@ "CIP-009-6 1.5" ], "emea-deu-c5-2020": [ - "SIM-03" + "SIM-01-DOAR" ], - "emea-sau-sacs-002-2022": [ - "TPC-89" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.9" ], "emea-gbr-def-stan-05-138-2024": [ "3104" @@ -202,7 +203,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3104" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0137", "ISM-0138", "ISM-1609", @@ -228,7 +229,7 @@ "16.1.7.12", "16.1.7.13.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP74", "HML74" ], @@ -240,6 +241,9 @@ ], "americas-can-osfi-b13-2022": [ "3.4.5" + ], + "americas-can-osfi-self-assessment-2": [ + "3.4.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-09.1.json b/docs/api/controls/IRO-09.1.json index d9a41413..4b4e7083 100644 --- a/docs/api/controls/IRO-09.1.json +++ b/docs/api/controls/IRO-09.1.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically assist in the tracking, collection and analysis of information from actual and potential cybersecurity and data protection incidents.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -100,7 +100,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -125,11 +126,19 @@ "general-nist-800-82-r3-high": [ "IR-05(01)" ], + "general-nist-800-172-r3": [ + "03.06.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.04E[01]", + "A.03.06.04E.ODP[01]", + "DS-A.03.06.04E[02]", + "A.03.06.04E.ODP[02]", + "DS-A.03.06.04E[03]", + "A.03.06.04E.ODP[03]" + ], "usa-federal-gsa-fedramp-5-high": [ "IR-05(01)" - ], - "emea-isr-cmo-1-0": [ - "24.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-09.2.json b/docs/api/controls/IRO-09.2.json index b42a95f2..05fac8c4 100644 --- a/docs/api/controls/IRO-09.2.json +++ b/docs/api/controls/IRO-09.2.json @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { diff --git a/docs/api/controls/IRO-09.3.json b/docs/api/controls/IRO-09.3.json index 10e36114..024eda7d 100644 --- a/docs/api/controls/IRO-09.3.json +++ b/docs/api/controls/IRO-09.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain a repository of cybersecurity events and incidents that documents:\n(1) Details of the incident (e.g., category, severity, affected parties, etc.);\n(2) Remediation actions taken through incident closure; and\n(3) A summary from the Root Cause Analysis (RCA), if applicable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -50,9 +50,9 @@ "MT-5", "MT-6", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Incident Response", "crosswalks": { "usa-federal-doe-c2m2-2-1": [ diff --git a/docs/api/controls/IRO-09.4.json b/docs/api/controls/IRO-09.4.json index 5ac395cd..b273fe9a 100644 --- a/docs/api/controls/IRO-09.4.json +++ b/docs/api/controls/IRO-09.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to analyze historical incidents in aggregate to identify:\n(1) Patterns;\n(2) Trends; and \n(3) Other common root causes in order to address the vulnerability and risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -48,9 +48,9 @@ "MT-5", "MT-6", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Incident Response", "crosswalks": { "usa-federal-doe-c2m2-2-1": [ diff --git a/docs/api/controls/IRO-09.json b/docs/api/controls/IRO-09.json index e2bc3bf2..e57ec80d 100644 --- a/docs/api/controls/IRO-09.json +++ b/docs/api/controls/IRO-09.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to document, monitor and report the status of cybersecurity and data protection incidents to internal stakeholders all the way through the resolution of the incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -215,7 +216,8 @@ ], "general-nist-800-171a-r3": [ "A.03.06.02.a[01]", - "A.03.06.02.a[02]" + "A.03.06.02.a[02]", + "A.03.06.02.b" ], "general-nist-csf-2-0": [ "DE.AE-06", @@ -259,10 +261,10 @@ "314.4(h)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "IR-5" @@ -282,10 +284,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-05" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(ii)" - ], "emea-eu-gdpr-2016": [ "Article 33.5" ], @@ -294,33 +292,25 @@ "3.5.4", "6.10.2(a)" ], - "emea-isr-cmo-1-0": [ - "24.5" - ], - "emea-sau-sacs-002-2022": [ - "TPC-89", - "TPC-90" + "emea-deu-c5-2020": [ + "SIM-07" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.2" + "emea-isr-cmo-2-0": [ + "Appendix A, 13.1" ], - "emea-esp-decree-311-2022": [ - "25.2" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-90" ], "emea-uae-niaf-2023": [ "3.3.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0125", "ISM-0137", "ISM-0733", "ISM-1609", "ISM-1803" ], - "apac-aus-ps-cps-234-2019": [ - "23", - "24" - ], "apac-ind-dpdpa-2023": [ "8(6)" ], @@ -332,9 +322,6 @@ "7.3.6.C.01", "7.3.6.C.02" ], - "apac-sgp-mas-trm-2021": [ - "7.7.5" - ], "americas-can-osfi-b13-2022": [ "2.7" ], diff --git a/docs/api/controls/IRO-10.1.json b/docs/api/controls/IRO-10.1.json index 3ef6f907..a4dc1aa6 100644 --- a/docs/api/controls/IRO-10.1.json +++ b/docs/api/controls/IRO-10.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically assist in the reporting of cybersecurity and data protection incidents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89,7 +89,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { diff --git a/docs/api/controls/IRO-10.2.json b/docs/api/controls/IRO-10.2.json index a612b394..3d805539 100644 --- a/docs/api/controls/IRO-10.2.json +++ b/docs/api/controls/IRO-10.2.json @@ -2,8 +2,8 @@ "control_id": "IRO-10.2", "title": "Cyber Incident Reporting for Sensitive / Regulated Data", "family": "IRO", - "description": "Mechanisms exist to report sensitive/regulated data incidents in a timely manner.", - "scf_question": "Does the organization report sensitive/regulated data incidents in a timely manner?", + "description": "Mechanisms exist to report sensitive and/or regulated data incidents in a timely manner.", + "scf_question": "Does the organization report sensitive and/or regulated data incidents in a timely manner?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -97,7 +97,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -171,7 +172,8 @@ "03.06.02.c" ], "general-nist-800-171a-r3": [ - "A.03.06.02.ODP[02]" + "A.03.06.02.ODP[02]", + "A.03.06.02.b" ], "general-nist-csf-2-0": [ "RS.CO", @@ -194,8 +196,13 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(3)(v)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(7)", + "101.625(d)(10)", + "101.650(g)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.410(a)(1)" + "§ 164.410(a)(1)" ], "usa-federal-nerc-cip-2024": [ "CIP-008-6 4.2" @@ -210,8 +217,18 @@ "emea-eu-ai-act-2024": [ "Article 17.1(j)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(1)", + "Article 14(3)", + "Article 14(4)(a)", + "Article 14(4)(b)", + "Article 14(4)(c)", + "Article 14(4)(i)", + "Article 14(4)(i)(ii)", + "Article 14(4)(i)(iii)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-gdpr-2016": [ "Article 33.1", @@ -225,40 +242,50 @@ "emea-eu-nis2-annex-2024": [ "3.1.2(b)" ], + "emea-deu-fdpa-2017": [ + "3.4.65(1)", + "3.4.65(2)", + "3.4.65(3)", + "3.4.65(3)1", + "3.4.65(3)2", + "3.4.65(3)3", + "3.4.65(3)4", + "3.4.65(4)", + "3.4.65(5)", + "3.4.65(6)" + ], + "emea-irl-dpa-2018": [ + "s.87" + ], + "emea-ken-pda-2019": [ + "IV.43(1)(a)" + ], "emea-qat-pdppl-2020": [ - "14" + "3.14" ], "emea-sau-ecc-1-2018": [ "2-13-3-3", "2-13-3-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-89" - ], - "emea-srb-act-9-2018": [ - "52", - "52.1", - "52.2", - "52.3", - "52.4" - ], "emea-uae-niaf-2023": [ "3.3.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0733" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "apac-aus-ps-cps-230-2023": [ + "33" ], "apac-ind-sebi-2024": [ "DE.DP.S3", "RS.CO.S2" ], + "apac-jpn-appi-2020": [ + "IV.1.22-2(1)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.18" + ], "apac-nzl-ism-3-9": [ "7.2.18.C.01", "7.2.20.C.01", @@ -266,9 +293,41 @@ "7.2.23.C.01", "7.3.8.C.03" ], + "apac-phl-dpa-2012": [ + "V.20(f)" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(3)(a)", + "6A.26C(3)(b)", + "6A.26C(4)" + ], + "americas-arg-ppd-2018": [ + "G.1.3" + ], + "americas-bhs-dpa-2003": [ + "V.47(1)", + "V.47(2)", + "V.47(3)", + "V.47(4)(a)", + "V.47(4)(b)", + "V.47(4)(c)", + "V.47(4)(d)", + "V.47(4)(e)", + "V.47(4)(f)", + "V.47(4)(g)", + "V.47(4)(h)", + "V.47(5)", + "V.47(6)", + "V.47(6)(a)", + "V.47(6)(b)", + "V.47(6)(c)" + ], "americas-can-itsp-10-171-2025": [ "03.06.02.B", "03.06.02.C" + ], + "americas-col-law-1581-2012": [ + "VI.17(n)" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-10.3.json b/docs/api/controls/IRO-10.3.json index bbdea5d0..85cec0a3 100644 --- a/docs/api/controls/IRO-10.3.json +++ b/docs/api/controls/IRO-10.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to report system vulnerabilities associated with reported cybersecurity and data protection incidents to organization-defined personnel or roles.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -99,7 +99,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -147,9 +148,6 @@ ], "usa-federal-irs-1075-2021": [ "IR-6(CE-3)" - ], - "emea-deu-c5-2020": [ - "PSS-02" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-10.4.json b/docs/api/controls/IRO-10.4.json index 8c9702e7..5a611eba 100644 --- a/docs/api/controls/IRO-10.4.json +++ b/docs/api/controls/IRO-10.4.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide cybersecurity and data protection incident information to the provider of the Technology Assets, Applications and/or Services (TAAS) and other organizations involved in the supply chain for TAAS related to the incident.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -205,10 +206,7 @@ "emea-eu-nis2-2022": [ "Article 23.2" ], - "emea-isr-cmo-1-0": [ - "17.11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1569" ], "apac-ind-sebi-2024": [ diff --git a/docs/api/controls/IRO-10.5.json b/docs/api/controls/IRO-10.5.json index 2ffaf221..cb196991 100644 --- a/docs/api/controls/IRO-10.5.json +++ b/docs/api/controls/IRO-10.5.json @@ -3,7 +3,7 @@ "title": "Serious Incident Reporting", "family": "IRO", "description": "Mechanisms exist to report any serious incident involving the organization's Technology Assets, Applications, Services and/or Data (TAASD) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines.", - "scf_question": "Does the organization report any serious incident involving the organization's Technology Assets, Applications and/or Services (TAAS) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines?", + "scf_question": "Does the organization report any serious incident involving its Technology Assets, Applications, Services and/or Data (TAASD) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to report any serious incident involving the organization's TAASD to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -101,10 +101,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(10)" + ], "usa-federal-nerc-cip-2024": [ "CIP-008-6 R4", "CIP-008-6 4.1", @@ -113,9 +117,33 @@ "CIP-008-6 4.1.3", "CIP-008-6 4.2" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.2", - "Article 11.4" + "emea-eu-psd2-2015": [ + "96(1)" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.15.7", + "3.3.15.7.a", + "3.3.15.7.b", + "3.3.15.7.c", + "3.3.15.7.d", + "3.3.15.7.e", + "3.3.15.7.f", + "3.3.15.7.g", + "3.3.15.7.h", + "3.3.15.7.i", + "3.3.15.7.j", + "3.3.15.7.k" + ], + "emea-esp-decree-311-2022": [ + "Article 33(7)" + ], + "americas-bmu-mba-coc-2020": [ + "6.5", + "6.5(a)", + "6.5(b)", + "6.5(c)", + "6.5(d)", + "6.5(e)" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-10.json b/docs/api/controls/IRO-10.json index 7e3dc385..67e14248 100644 --- a/docs/api/controls/IRO-10.json +++ b/docs/api/controls/IRO-10.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to timely-report incidents to applicable:\n(1) Internal stakeholders; \n(2) Affected clients & third-parties; and\n(3) Regulatory authorities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -174,7 +175,7 @@ "6.8" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-iso-42001-2023": [ "A.8.3", @@ -225,7 +226,8 @@ ], "general-nist-800-171-r3": [ "03.06.02.b", - "03.06.02.c" + "03.06.02.c", + "03.06.02.d" ], "general-nist-800-171a-r3": [ "A.03.06.02.ODP[01]", @@ -277,9 +279,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.10.1" ], - "general-scf-dpmp-2025": [ - "8.2" - ], "general-tisax-6-0-3": [ "1.6.2" ], @@ -309,6 +308,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(10)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)(iii)", "248.30(a)(4)(i)", @@ -331,10 +333,10 @@ "314.4(h)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.404(b)", - "164.408(a)", - "164.408(b)", - "164.408(c)" + "§ 164.404(b)", + "§ 164.408(a)", + "§ 164.408(b)", + "§ 164.408(c)" ], "usa-federal-irs-1075-2021": [ "IR-6" @@ -398,6 +400,19 @@ "12(e)(C)", "12(e)(D)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.220.1", + "603A.220.2", + "603A.220.3", + "603A.220.4", + "603A.220.4(a)", + "603A.220.4(b)", + "603A.220.4(c)", + "603A.220.4(c)(1)", + "603A.220.4(c)(2)", + "603A.220.4(c)(3)", + "603A.220.6" + ], "usa-state-nv-regulation-5-2024": [ "5.260.4(a)", "5.260.4(c)" @@ -474,8 +489,13 @@ "emea-eu-ai-act-2024": [ "Article 17.1(j)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(8)", + "Article 15(1)", + "Article 15(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 14.1", @@ -513,16 +533,57 @@ "3.1.2(b)", "13.2.2(c)" ], + "emea-eu-psd2-2015": [ + "96(1)" + ], + "emea-aut-dpa-2018": [ + "§ 55(1)", + "§ 55(2)", + "§ 56(1)", + "§ 56(2)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 4, Art. 61(1)", + "Title 2, Chapter IV, Section 4, Art. 61(2)", + "Title 2, Chapter IV, Section 4, Art. 61(3)", + "Title 2, Chapter IV, Section 4, Art. 61(4)", + "Title 2, Chapter IV, Section 4, Art. 61(5)", + "Title 2, Chapter IV, Section 4, Art. 61(6)", + "Title 2, Chapter IV, Section 4, Art. 62(1)", + "Title 2, Chapter IV, Section 4, Art. 62(2)", + "Title 2, Chapter IV, Section 4, Art. 62(3)", + "Title 2, Chapter IV, Section 4, Art. 62(4)", + "Title 2, Chapter IV, Section 4, Art. 62(5)" + ], + "emea-deu-fdpa-2017": [ + "3.4.66(1)", + "3.4.66(2)" + ], "emea-deu-c5-2020": [ - "SIM-03", + "RB-20", "SIM-04" ], - "emea-isr-cmo-1-0": [ - "24.6", - "24.8" - ], - "emea-qat-pdppl-2020": [ - "14" + "emea-irl-dpa-2018": [ + "s.85", + "s.86" + ], + "emea-ken-pda-2019": [ + "IV.43(1)(b)", + "IV.43(2)", + "IV.43(3)", + "IV.43(4)", + "IV.43(5)", + "IV.43(5)(a)", + "IV.43(5)(b)", + "IV.43(5)(c)", + "IV.43(5)(d)", + "IV.43(5)(e)", + "IV.43(6)", + "IV.43(7)", + "IV.43(8)", + "IV.43(8)(a)", + "IV.43(8)(b)", + "IV.43(8)(c)" ], "emea-sau-cgiot-2024": [ "2-12-2" @@ -532,27 +593,91 @@ "2-13-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-89" - ], - "emea-zaf-popia-2013": [ - "22" + "VII.A.TPC-23-BP1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.2", - "Article 33.2", - "Article 33.4", - "Article 33.7" + "emea-srb-act-9-2018": [ + "IV.2.52", + "IV.2.52(1)", + "IV.2.52(2)", + "IV.2.52(3)", + "IV.2.52(4)", + "IV.2.53" ], - "emea-esp-decree-311-2022": [ - "25.2", - "33.2", - "33.4", - "33.7" + "emea-zaf-popia-2013": [ + "3.A.7.22(1)", + "3.A.7.22(1)(a)", + "3.A.7.22(1)(b)", + "3.A.7.22(2)", + "3.A.7.22(3)", + "3.A.7.22(4)", + "3.A.7.22(4)(a)", + "3.A.7.22(4)(b)", + "3.A.7.22(4)(c)", + "3.A.7.22(4)(d)", + "3.A.7.22(4)(e)", + "3.A.7.22(5)", + "3.A.7.22(5)(a)", + "3.A.7.22(5)(b)", + "3.A.7.22(5)(c)", + "3.A.7.22(5)(d)", + "3.A.7.22(6)" + ], + "emea-che-fadp-2025": [ + "3.24.1", + "3.24.2", + "3.24.3", + "3.24.4", + "3.24.5", + "3.24.5.a", + "3.24.5.b", + "3.24.5.c", + "3.24.5bis", + "3.24.6" ], "emea-uae-niaf-2023": [ "3.3.3" ], + "emea-gbr-dpa-2018": [ + "Section 67(1)", + "Section 67(1)(a)", + "Section 67(1)(b)", + "Section 67(2)", + "Section 67(3)", + "Section 67(4)", + "Section 67(4)(a)", + "Section 67(4)(b)", + "Section 67(4)(c)", + "Section 67(4)(d)", + "Section 67(5)", + "Section 67(6)", + "Section 67(6)(a)", + "Section 67(6)(b)", + "Section 67(6)(c)", + "Section 67(7)", + "Section 67(9)", + "Section 68(1)", + "Section 68(2)", + "Section 68(2)(a)", + "Section 68(2)(b)", + "Section 68(2)(c)", + "Section 68(2)(d)", + "Section 68(3)", + "Section 68(3)(a)", + "Section 68(3)(b)", + "Section 68(3)(c)", + "Section 68(4)", + "Section 68(5)", + "Section 68(6)", + "Section 68(6)(a)", + "Section 68(6)(b)", + "Section 68(7)", + "Section 68(7)(a)", + "Section 68(7)(b)", + "Section 68(7)(c)", + "Section 68(7)(e)", + "Section 68(8)", + "Section 68(9)" + ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML2-P4", @@ -563,17 +688,25 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0123", "ISM-0137", "ISM-0733", "ISM-1088", - "ISM-1609" + "ISM-1609", + "ISM-1880", + "ISM-1881" ], "apac-aus-ps-cps-230-2023": [ - "33", "42" ], + "apac-aus-ps-cps-234-2019": [ + "35", + "36" + ], + "apac-chn-pipl-2021": [ + "Article 57" + ], "apac-ind-dpdpa-2023": [ "8(6)" ], @@ -584,10 +717,17 @@ "RS.CO.S2", "RS.CO.S3" ], + "apac-jpn-appi-2020": [ + "IV.1.22-2(2)" + ], "apac-jpn-ismap": [ "6.1.3.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.35", + "11.19" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP75", "HML75" ], @@ -596,27 +736,108 @@ ], "apac-nzl-ism-3-9": [ "7.2.18.C.01", + "7.2.18.C.02", "7.2.20.C.01", + "7.2.20.C.02", + "7.2.20.C.03", "7.2.21.C.01", "7.2.23.C.01" ], + "apac-nzl-privacy-act-2020": [ + "6.1.115(1)", + "6.1.115(2)", + "6.1.115(3)", + "6.1.115(3)(a)", + "6.1.115(3)(b)", + "6.1.115(4)", + "6.1.115(4)(a)", + "6.1.115(4)(b)", + "6.1.117(1)", + "6.1.117(1)(a)", + "6.1.117(1)(a)(i)", + "6.1.117(1)(a)(ii)", + "6.1.117(1)(b)", + "6.1.117(1)(c)", + "6.1.117(1)(d)", + "6.1.117(1)(e)", + "6.1.117(1)(f)", + "6.1.117(2)", + "6.1.117(2)(a)", + "6.1.117(2)(b)", + "6.1.117(2)(c)", + "6.1.117(2)(d)", + "6.1.117(2)(e)", + "6.1.117(2)(f)", + "6.1.117(3)", + "6.1.117(4)", + "6.1.117(5)" + ], + "apac-sgp-pdpa-2012": [ + "6A.26D(1)", + "6A.26D(2)", + "6A.26D(3)", + "6A.26D(4)", + "6A.26D(5)(a)", + "6A.26D(5)(b)", + "6A.26D(6)", + "6A.26D(6)(a)", + "6A.26D(6)(b)", + "6A.26D(9)", + "6A.26E", + "6A.26E(a)", + "6A.26E(b)" + ], "apac-sgp-mas-trm-2021": [ "7.7.5", - "7.7.6", "7.7.7" ], + "apac-kor-pipa-2011": [ + "IV.34(1)", + "IV.34(1)1", + "IV.34(1)2", + "IV.34(1)3", + "IV.34(1)4", + "IV.34(1)5", + "IV.34(3)" + ], + "apac-twn-pdpa-2025": [ + "I.12", + "I.12.1", + "I.12.2" + ], + "americas-arg-ppd-2018": [ + "G.1.2" + ], + "americas-bhs-dpa-2003": [ + "V.48(2)", + "V.48(3)", + "V.48(3)(a)", + "V.48(3)(b)", + "V.48(3)(c)" + ], "americas-bmu-mba-coc-2020": [ - "6.5" + "6.4" ], "americas-bra-lgpd-2018": [ - "48" + "VII.I.48", + "VII.I.48.1", + "VII.I.48.1.I", + "VII.I.48.1.II", + "VII.I.48.1.III", + "VII.I.48.1.IV", + "VII.I.48.1.V", + "VII.I.48.1.VI" ], "americas-can-osfi-b13-2022": [ "3.4.1" ], "americas-can-itsp-10-171-2025": [ "03.06.02.B", - "03.06.02.C" + "03.06.02.C", + "03.06.02.D" + ], + "americas-mex-fdpa-2010": [ + "II.20" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-11.1.json b/docs/api/controls/IRO-11.1.json index 6ec3ef3d..e089b4d1 100644 --- a/docs/api/controls/IRO-11.1.json +++ b/docs/api/controls/IRO-11.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically increase the availability of incident response-related information and support.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically increase the availability of incident response-related information and support. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { diff --git a/docs/api/controls/IRO-11.2.json b/docs/api/controls/IRO-11.2.json index 9e76d56c..b6855f59 100644 --- a/docs/api/controls/IRO-11.2.json +++ b/docs/api/controls/IRO-11.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to establish a direct, cooperative relationship between the organization's incident response capability and external service providers.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -146,9 +147,6 @@ "general-nist-800-161-r1-level-3": [ "IR-7(2)" ], - "general-scf-dpmp-2025": [ - "8.2" - ], "usa-federal-doe-c2m2-2-1": [ "RESPONSE-3j", "RESPONSE-3k" @@ -162,8 +160,9 @@ "IR-7(CE-2).a", "IR-7(CE-2).b" ], - "emea-zaf-popia-2013": [ - "21.2" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], "apac-nzl-ism-3-9": [ "7.3.10.C.01", diff --git a/docs/api/controls/IRO-11.json b/docs/api/controls/IRO-11.json index 0207e45f..94620f77 100644 --- a/docs/api/controls/IRO-11.json +++ b/docs/api/controls/IRO-11.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide incident response advice and assistance to users of Technology Assets, Applications and/or Services (TAAS) for the handling and reporting of actual and potential cybersecurity and data protection incidents.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide incident response advice and assistance to users of Technology Assets, Applications and/or Services (TAAS) for the handling and reporting of actual and potential cybersecurity and data protection incidents. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -154,9 +155,6 @@ "general-nist-800-171a-r3": [ "A.03.06.02.d" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "usa-federal-fbi-cjis-6-0": [ "IR-7" ], diff --git a/docs/api/controls/IRO-12.1.json b/docs/api/controls/IRO-12.1.json index 9434e2fd..613edf48 100644 --- a/docs/api/controls/IRO-12.1.json +++ b/docs/api/controls/IRO-12.1.json @@ -2,8 +2,8 @@ "control_id": "IRO-12.1", "title": "Sensitive / Regulated Data Spill Responsible Personnel", "family": "IRO", - "description": "Mechanisms exist to formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills.", - "scf_question": "Does the organization formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills?", + "description": "Mechanisms exist to formally assign personnel or roles with responsibility for responding to sensitive and/or regulated data spills.", + "scf_question": "Does the organization formally assign personnel or roles with responsibility for responding to sensitive and/or regulated data spills?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { diff --git a/docs/api/controls/IRO-12.2.json b/docs/api/controls/IRO-12.2.json index 09dc9c7d..179ac375 100644 --- a/docs/api/controls/IRO-12.2.json +++ b/docs/api/controls/IRO-12.2.json @@ -2,8 +2,8 @@ "control_id": "IRO-12.2", "title": "Sensitive / Regulated Data Spill Training", "family": "IRO", - "description": "Mechanisms exist to ensure incident response training material provides coverage for sensitive/regulated data spillage response.", - "scf_question": "Does the organization ensure incident response training material provides coverage for sensitive/regulated data spillage response?", + "description": "Mechanisms exist to ensure incident response training material provides coverage for sensitive and/or regulated data spillage response.", + "scf_question": "Does the organization ensure incident response training material provides coverage for sensitive and/or regulated data spillage response?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to ensure incident response training material provides coverage for sensitive/regulated data spillage response.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { diff --git a/docs/api/controls/IRO-12.3.json b/docs/api/controls/IRO-12.3.json index e84956fc..7e10596c 100644 --- a/docs/api/controls/IRO-12.3.json +++ b/docs/api/controls/IRO-12.3.json @@ -2,8 +2,8 @@ "control_id": "IRO-12.3", "title": "Post-Sensitive / Regulated Data Spill Operations", "family": "IRO", - "description": "Mechanisms exist to ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", - "scf_question": "Does the organization ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions?", + "description": "Mechanisms exist to ensure that organizational personnel impacted by sensitive and/or regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", + "scf_question": "Does the organization ensure that organizational personnel impacted by sensitive and/or regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -141,10 +142,7 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-09(03)" ], - "emea-deu-c5-2020": [ - "OPS-21" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ] } diff --git a/docs/api/controls/IRO-12.4.json b/docs/api/controls/IRO-12.4.json index 8e7c9f43..de73a2e8 100644 --- a/docs/api/controls/IRO-12.4.json +++ b/docs/api/controls/IRO-12.4.json @@ -2,8 +2,8 @@ "control_id": "IRO-12.4", "title": "Sensitive / Regulated Data Exposure to Unauthorized Personnel", "family": "IRO", - "description": "Mechanisms exist to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations.", - "scf_question": "Does the organization address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations?", + "description": "Mechanisms exist to address security safeguards for personnel exposed to sensitive and/or regulated data that is not within their assigned access authorizations.", + "scf_question": "Does the organization address security safeguards for personnel exposed to sensitive and/or regulated data that is not within their assigned access authorizations?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -129,7 +130,7 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-09(04)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/IRO-12.json b/docs/api/controls/IRO-12.json index 9d8434ea..afe23ea7 100644 --- a/docs/api/controls/IRO-12.json +++ b/docs/api/controls/IRO-12.json @@ -2,8 +2,8 @@ "control_id": "IRO-12", "title": "Sensitive / Regulated Data Spill Response", "family": "IRO", - "description": "Mechanisms exist to respond to sensitive/regulated data spills.", - "scf_question": "Does the organization respond to sensitive/regulated data spills?", + "description": "Mechanisms exist to respond to sensitive and/or regulated data spills.", + "scf_question": "Does the organization respond to sensitive and/or regulated data spills?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to respond to sensitive/regulated data spills.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -149,10 +150,12 @@ "IR-9" ], "general-nist-800-171-r3": [ + "03.01.22.b", "03.06.01" ], "general-nist-800-171a-r3": [ - "A.03.01.22.b[02]" + "A.03.01.22.b[02]", + "A.03.06.01[01]" ], "general-pci-dss-4-0-1": [ "12.10.7", @@ -197,7 +200,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-09" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], "apac-nzl-ism-3-9": [ @@ -211,7 +214,15 @@ "7.3.8.C.02", "7.3.8.C.03" ], + "americas-bhs-dpa-2003": [ + "IV.28(3)(a)", + "IV.28(3)(b)", + "IV.28(3)(b)(i)", + "IV.28(3)(b)(ii)", + "IV.28(3)(b)(iii)" + ], "americas-can-itsp-10-171-2025": [ + "03.01.22.B", "03.06.01" ] } diff --git a/docs/api/controls/IRO-13.json b/docs/api/controls/IRO-13.json index 785e2107..d86b7e4e 100644 --- a/docs/api/controls/IRO-13.json +++ b/docs/api/controls/IRO-13.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders provide After Action Review (AAR) feedback on what worked, what did not work and ways to improve future responses to similar incidents.\n▪ A formal Root Cause Analysis (RCA) is performed that documents the findings in a report for both technical and business leadership management.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -225,7 +226,8 @@ "03.06.04.b" ], "general-nist-800-171a-r3": [ - "A.03.06.04.ODP[04]" + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" ], "general-nist-800-218": [ "RV.3" @@ -283,6 +285,9 @@ "IR-04(12)", "IR-06(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(c)(6)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(h)(7)" ], @@ -332,14 +337,20 @@ "3.6.3" ], "emea-deu-c5-2020": [ - "SIM-05" + "SIM-04" ], "emea-sau-cgiot-2024": [ "2-12-2", "2-12-3" ], + "emea-sau-otcc-1-2022": [ + "2-12-1-2" + ], "emea-sau-sacs-002-2022": [ - "TPC-89" + "VII.B.TPC-89" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7" ], "emea-gbr-caf-4-0": [ "D2", @@ -361,11 +372,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4200" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1213" ], - "apac-aus-ps-cps-234-2019": [ - "25(a)" + "apac-aus-ps-cps-230-2023": [ + "32" ], "apac-ind-sebi-2024": [ "EV.ST.S3", @@ -385,20 +396,19 @@ "apac-sgp-mas-trm-2021": [ "7.8.1", "7.8.2", - "7.8.3", - "12.3.3" + "12.3.2" ], "americas-bmu-mba-coc-2020": [ "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-osfi-b13-2022": [ "2.7.3", "3.4", "3.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.04.B" ] diff --git a/docs/api/controls/IRO-14.json b/docs/api/controls/IRO-14.json index f3d04395..2bacf8db 100644 --- a/docs/api/controls/IRO-14.json +++ b/docs/api/controls/IRO-14.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain incident response contacts with applicable regulatory and law enforcement agencies.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain incident response contacts with applicable regulatory and law enforcement agencies. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -167,6 +168,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(3)" + ], "usa-federal-irs-1075-2021": [ "IR-6" ], @@ -186,23 +190,11 @@ "IR-06" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" - ], - "emea-aut-fappd-2000": [ - "Sec 10" + "3.7.5.91" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0140" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "2.1.10.C.01" - ], - "apac-sgp-pdpa-2012": [ - "11" - ], "americas-can-itsp-10-171-2025": [ "03.06.02.C" ] diff --git a/docs/api/controls/IRO-15.json b/docs/api/controls/IRO-15.json index 0fb72157..ee56d695 100644 --- a/docs/api/controls/IRO-15.json +++ b/docs/api/controls/IRO-15.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to utilize a detonation chamber capability to detect and/or block potentially-malicious files and email attachments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104,12 +104,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.6", "9.7" ], @@ -123,7 +124,7 @@ "general-iso-21434-2021": [ "RC-05-15" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.001", "T1137.002", @@ -159,15 +160,18 @@ "general-nist-800-160-vol-2-r1": [ "SC-44" ], + "general-nist-800-172-r3": [ + "03.13.14E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.14E" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EM.E3AEP", "3.PEP.EM.MFPRO", "3.PEP.EM.PDPRO", "3.PEP.FI.DCHAM" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" - ], "emea-gbr-def-stan-05-138-2024": [ "2411" ], @@ -180,16 +184,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0651", "ISM-0652", - "ISM-1389" + "ISM-1389", + "ISM-1970" ], "apac-jpn-ismap": [ "12.2.1.14" - ], - "apac-nzl-ism-3-9": [ - "15.2.21.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/IRO-16.json b/docs/api/controls/IRO-16.json index 4318cec7..96aa6195 100644 --- a/docs/api/controls/IRO-16.json +++ b/docs/api/controls/IRO-16.json @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -112,18 +113,13 @@ "248.30(a)(4)(i)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-nis2-2022": [ "Article 23.2" ], "apac-ind-sebi-2024": [ "RC.CO.S1" - ], - "apac-sgp-mas-trm-2021": [ - "7.7.5", - "7.7.6", - "7.7.7" ] } } \ No newline at end of file diff --git a/docs/api/controls/MDM-01.json b/docs/api/controls/MDM-01.json index 6d3650d6..1487f0e7 100644 --- a/docs/api/controls/MDM-01.json +++ b/docs/api/controls/MDM-01.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage.", + "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to implement and govern Mobile Device Management (MDM) controls.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -111,7 +111,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -155,7 +156,8 @@ "03.01.20.d" ], "general-nist-800-171a-r3": [ - "A.03.01.18.a[01]" + "A.03.01.18.a[01]", + "A.03.01.20.d" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -186,47 +188,34 @@ "usa-federal-irs-1075-2021": [ "3.3.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "4.25", - "4.28", - "13.1", - "13.3", - "13.5", - "13.8", - "13.9", - "13.10" + "emea-deu-c5-2020": [ + "MDM-01", + "MDM-01-BP2", + "MDM-01-BP3", + "MDM-01-BP5", + "MDM-01-DOAR" ], "emea-sau-cscc-1-2019": [ - "2-5" + "2-5-1" ], "emea-sau-ecc-1-2018": [ - "2-6-3", - "2-6-3-1", - "2-6-3-2", - "2-6-3-3", - "2-6-3-4", - "2-6-4", - "5-1-3-6" + "2-6-1", + "2-6-2" ], "emea-sau-otcc-1-2022": [ - "2-5", "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", "2-5-1-4", - "2-5-1-5", "2-5-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.3 [MP.EQ.3]" + "emea-sau-sama-csf-1-2017": [ + "3.3.10" + ], + "emea-esp-decree-311-2022": [ + "Article 22(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-caf-4-0": [ "B3.d" @@ -246,7 +235,7 @@ "2309", "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0682", "ISM-0687", "ISM-0863", @@ -258,33 +247,23 @@ "ISM-1366", "ISM-1533" ], + "apac-mys-bnm-rmit-2025": [ + "12.3" + ], "apac-nzl-ism-3-9": [ "21.1.10.C.01", "21.1.10.C.02", - "21.1.10.C.03", "21.1.11.C.01", - "21.1.11.C.02", "21.1.12.C.01", - "21.1.14.C.01", - "21.1.14.C.02", - "21.1.15.C.01", - "21.1.16.C.01", - "21.1.16.C.02", - "21.1.17.C.01", - "21.1.17.C.02", - "21.1.17.C.03", - "21.1.18.C.01", - "21.1.18.C.02", - "21.1.19.C.01", - "21.1.19.C.02" + "22.1.10.C.01", + "22.1.10.C.03", + "22.1.12.C.01", + "22.1.15.C.01", + "22.1.18.C.02" ], "americas-bmu-mba-coc-2020": [ "6.11" ], - "amaericas-can-osfi-self-assessment": [ - "4.14", - "4.15" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.01.20.D" diff --git a/docs/api/controls/MDM-02.json b/docs/api/controls/MDM-02.json index f66f2b4a..1d4229cc 100644 --- a/docs/api/controls/MDM-02.json +++ b/docs/api/controls/MDM-02.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict the connection of personally-owned, mobile devices to organizational TAASD.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce access control requirements for the connection of mobile devices to organizational Technology Assets, Applications and/or Services (TAAS).", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce access control requirements for the connection of mobile devices to organizational Technology Assets, Applications and/or Services (TAAS). ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -131,7 +132,7 @@ "general-iso-27018-2025": [ "8.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1070.001", @@ -206,6 +207,7 @@ "3.1.18[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[02]", "A.03.01.18.b" ], "general-nist-800-207": [ @@ -254,23 +256,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-19" ], - "emea-isr-cmo-1-0": [ - "4.27", - "13.2", - "13.3", - "13.5", - "13.7", - "13.9" - ], "emea-sau-cscc-1-2019": [ "2-5-1-1" ], - "emea-sau-ecc-1-2018": [ - "2-6-3-2", - "5-1-3-6" + "emea-sau-otcc-1-2022": [ + "2-5-1-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", diff --git a/docs/api/controls/MDM-03.json b/docs/api/controls/MDM-03.json index c34d90eb..5a58848b 100644 --- a/docs/api/controls/MDM-03.json +++ b/docs/api/controls/MDM-03.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of information on mobile devices through full-device or container encryption.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -140,10 +141,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-19 (05)" ], - "emea-isr-cmo-1-0": [ - "4.26", - "8.7", - "13.4" + "emea-deu-c5-2020": [ + "MDM-01-BP1" ], "emea-sau-cscc-1-2019": [ "2-5-1-2" @@ -151,6 +150,9 @@ "emea-sau-ecc-1-2018": [ "2-6-3-1" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-5" + ], "emea-gbr-def-stan-05-138-2024": [ "2309" ], @@ -160,15 +162,13 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2309" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0869" ], "apac-nzl-ism-3-9": [ "21.1.13.C.01", - "21.1.13.C.02", - "21.1.13.C.03", - "21.1.13.C.04", - "21.1.13.C.05" + "22.1.14.C.01", + "22.1.14.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.18.C" diff --git a/docs/api/controls/MDM-04.json b/docs/api/controls/MDM-04.json index 37eb431d..4828aedf 100644 --- a/docs/api/controls/MDM-04.json +++ b/docs/api/controls/MDM-04.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel protect mobile devices from tampering through inspecting devices returning from locations that the organization deems to be of significant risk, prior to the device being connected to the organization's network.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to protect mobile devices from tampering through inspecting devices returning from locations that the organization deems to be of significant risk, prior to the device being connected to the organization's network.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -115,14 +116,14 @@ "general-nist-800-171-r3": [ "03.04.12.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.12.b" + ], "general-shared-assessments-sig-2025": [ "M.1.3" ], - "emea-isr-cmo-1-0": [ - "13.9" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" + "emea-deu-c5-2020": [ + "MDM-01-BP4" ], "americas-can-itsp-10-171-2025": [ "03.04.12.B" diff --git a/docs/api/controls/MDM-05.json b/docs/api/controls/MDM-05.json index dcac6d23..840f230a 100644 --- a/docs/api/controls/MDM-05.json +++ b/docs/api/controls/MDM-05.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ MDM software can remotely purge selected information from mobile devices.", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to remotely purge selected information from mobile devices.", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to remotely purge selected information from mobile devices. ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -134,22 +135,21 @@ "usa-federal-irs-1075-2021": [ "AC-7(CE-2)" ], - "emea-isr-cmo-1-0": [ - "13.8" - ], "emea-sau-ecc-1-2018": [ "2-6-3-3" ], + "emea-sau-otcc-1-2022": [ + "2-6-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-59" + "VII.B.TPC-59" ], - "apac-aus-ism-2024-june": [ - "ISM-0702" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], - "apac-nzl-ism-3-9": [ - "21.1.20.C.01", - "21.1.20.C.02", - "21.1.20.C.03" + "apac-aus-ism-2026-march": [ + "ISM-0702" ] } } \ No newline at end of file diff --git a/docs/api/controls/MDM-06.json b/docs/api/controls/MDM-06.json index f4b709c3..0d5d2eb1 100644 --- a/docs/api/controls/MDM-06.json +++ b/docs/api/controls/MDM-06.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict the connection of personally-owned, mobile devices to organizational TAASD.\n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connection of personally-owned, mobile devices to organizational Technology Assets, Applications and/or Services (TAAS).", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connection of personally-owned, mobile devices to organizational Technology Assets, Applications and/or Services (TAAS). ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -119,6 +120,10 @@ "03.01.18.a", "03.01.18.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.18.b" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -128,20 +133,19 @@ "usa-federal-dow-safeguarding-nnpi-2010": [ "9-3.d" ], - "emea-isr-cmo-1-0": [ - "13.3", - "13.5" - ], - "emea-sau-cscc-1-2019": [ - "2-5-1-1" + "emea-deu-c5-2020": [ + "MDM-01-BP6" ], "emea-sau-ecc-1-2018": [ "5-1-3-6" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-84" + "VII.B.TPC-84" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0694", "ISM-1297", "ISM-1400", @@ -153,9 +157,6 @@ "apac-nzl-ism-3-9": [ "21.1.12.C.01" ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.01.18.B" diff --git a/docs/api/controls/MDM-07.json b/docs/api/controls/MDM-07.json index bc7ad8c9..b1c1bf59 100644 --- a/docs/api/controls/MDM-07.json +++ b/docs/api/controls/MDM-07.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).\n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to prohibit the installation of non-approved applications or approved applications not obtained through the organization-approved application store.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -120,24 +121,23 @@ "03.01.18.b", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.18.b", + "A.03.01.20.d" + ], "general-nist-800-207": [ "NIST Tenet 1" ], "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.18" ], - "emea-isr-cmo-1-0": [ - "13.3", - "13.5" - ], "emea-sau-ecc-1-2018": [ "5-1-3-6" ], "emea-sau-otcc-1-2022": [ - "2-5-1-4" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" + "2-5-1-1", + "2-5-1-3" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", diff --git a/docs/api/controls/MDM-08.json b/docs/api/controls/MDM-08.json index cfe7c62d..ef8da06d 100644 --- a/docs/api/controls/MDM-08.json +++ b/docs/api/controls/MDM-08.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to limit data retention on mobile devices to the smallest usable dataset and timeframe.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -57,7 +57,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": {} diff --git a/docs/api/controls/MDM-09.json b/docs/api/controls/MDM-09.json index c5513338..86dcc8d9 100644 --- a/docs/api/controls/MDM-09.json +++ b/docs/api/controls/MDM-09.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the functionality of mobile devices based on geographic location.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60,7 +60,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { diff --git a/docs/api/controls/MDM-10.json b/docs/api/controls/MDM-10.json index 7989a9d8..5236f5ca 100644 --- a/docs/api/controls/MDM-10.json +++ b/docs/api/controls/MDM-10.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce a separate device workspace on applicable mobile devices to separate work-related and personal-related applications and data.", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce a separate device workspace on applicable mobile devices to separate work-related and personal-related applications and data. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { diff --git a/docs/api/controls/MDM-11.json b/docs/api/controls/MDM-11.json index c207bf9f..02838ed7 100644 --- a/docs/api/controls/MDM-11.json +++ b/docs/api/controls/MDM-11.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. \n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).\n▪ MDM software is used to prevent the unauthorized disclosure of sensitive/regulated data (e.g., cryptographic containerization).", + "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. \n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).\n▪ MDM software is used to prevent the unauthorized disclosure of sensitive/regulated data (e.g., cryptographic containerization). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connectivity of unauthorized mobile devices from communicating with organizational Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -97,15 +98,15 @@ "general-nist-800-171-r3": [ "03.01.18.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.b" + ], "general-shared-assessments-sig-2025": [ "M.1.2" ], "emea-sau-cscc-1-2019": [ "2-5-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.B" ] diff --git a/docs/api/controls/MNT-01.json b/docs/api/controls/MNT-01.json index 35184214..e467e4c0 100644 --- a/docs/api/controls/MNT-01.json +++ b/docs/api/controls/MNT-01.json @@ -117,7 +117,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -206,6 +207,12 @@ "03.07.04.a", "03.07.06.a" ], + "general-nist-800-171a-r3": [ + "A.03.04.03.c[01]", + "A.03.07.04.a[01]", + "A.03.07.04.a[02]", + "A.03.07.06.a" + ], "general-nist-csf-2-0": [ "PR.PS", "PR.PS-02", @@ -236,12 +243,12 @@ "MA-01" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MA-1" @@ -264,28 +271,14 @@ "emea-eu-nis2-annex-2024": [ "4.3.2(c)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" + "emea-deu-c5-2020": [ + "PS-05" ], - "emea-sau-sacs-002-2022": [ - "TPC-78" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.4 [OP.EXP.4]" - ], - "apac-aus-ism-2024-june": [ - "ISM-0305", - "ISM-1226" + "apac-aus-ism-2026-march": [ + "ISM-0305" ], "apac-jpn-ismap": [ "11.2.4", @@ -293,7 +286,10 @@ "11.2.4.3", "11.2.4.5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.26" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP15", "HML15" ], diff --git a/docs/api/controls/MNT-02.1.json b/docs/api/controls/MNT-02.1.json index 0202ae74..3e52cfe1 100644 --- a/docs/api/controls/MNT-02.1.json +++ b/docs/api/controls/MNT-02.1.json @@ -100,7 +100,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MNT-02.json b/docs/api/controls/MNT-02.json index 21ea934e..56eeb215 100644 --- a/docs/api/controls/MNT-02.json +++ b/docs/api/controls/MNT-02.json @@ -3,7 +3,7 @@ "title": "Controlled Maintenance", "family": "MNT", "description": "Mechanisms exist to conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).", - "scf_question": "Does the organization conduct controlled maintenance activities throughout the lifecycle of theTechnology Asset, Application and/or Service (TAAS)?", + "scf_question": "Does the organization conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset custodians track maintenance activities and component failure rates.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -109,7 +109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -179,7 +180,9 @@ "3.7.1" ], "general-nist-800-171a-r3": [ - "A.03.04.03.c[01]" + "A.03.04.03.c[01]", + "A.03.07.04.a[02]", + "A.03.07.05.a[01]" ], "general-nist-csf-2-0": [ "PR.PS", @@ -205,10 +208,10 @@ "MA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "MA-2" @@ -232,8 +235,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-02" ], - "emea-sau-sacs-002-2022": [ - "TPC-78" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" ], "emea-gbr-def-stan-05-138-2024": [ "2511" @@ -247,7 +250,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2511" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1079" ], "apac-ind-sebi-2024": [ @@ -256,7 +259,12 @@ "apac-jpn-ismap": [ "11.2.4.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.26" + ], "apac-nzl-ism-3-9": [ + "11.8.10.C.01", + "11.8.10.C.04", "12.5.3.C.01", "12.5.3.C.02", "12.5.6.C.01", diff --git a/docs/api/controls/MNT-03.1.json b/docs/api/controls/MNT-03.1.json index 324685fb..195e076d 100644 --- a/docs/api/controls/MNT-03.1.json +++ b/docs/api/controls/MNT-03.1.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset custodians track maintenance activities and component failure rates.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to perform preventive maintenance on critical Technology Assets, Applications and/or Services (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -125,6 +126,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-nist-csf-2-0": [ "PR.PS-02", "PR.PS-03" diff --git a/docs/api/controls/MNT-03.2.json b/docs/api/controls/MNT-03.2.json index b3e3aa86..b0c05684 100644 --- a/docs/api/controls/MNT-03.2.json +++ b/docs/api/controls/MNT-03.2.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to perform predictive maintenance on critical Technology Assets, Applications and/or Services (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MNT-03.3.json b/docs/api/controls/MNT-03.3.json index 873d33e8..81402743 100644 --- a/docs/api/controls/MNT-03.3.json +++ b/docs/api/controls/MNT-03.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to automatically transfer predictive maintenance data to a computerized maintenance management system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89,7 +89,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MNT-03.json b/docs/api/controls/MNT-03.json index 5ce1b5ed..19016f87 100644 --- a/docs/api/controls/MNT-03.json +++ b/docs/api/controls/MNT-03.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to obtain maintenance support and/or spare parts for Technology Assets, Applications and/or Services (TAAS) within a defined Recovery Time Objective (RTO).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -162,6 +163,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-nist-csf-2-0": [ "PR.PS-02", "PR.PS-03" @@ -188,6 +192,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-06" ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" + ], "emea-gbr-def-stan-05-138-2024": [ "2511" ], diff --git a/docs/api/controls/MNT-04.1.json b/docs/api/controls/MNT-04.1.json index a3a4b116..087c0215 100644 --- a/docs/api/controls/MNT-04.1.json +++ b/docs/api/controls/MNT-04.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.\n▪ IT and/or cybersecurity personnel inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -144,6 +145,9 @@ "general-nist-800-171-r3": [ "03.07.04.b" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.b" + ], "usa-federal-fbi-cjis-6-0": [ "MA-3(1)" ], diff --git a/docs/api/controls/MNT-04.2.json b/docs/api/controls/MNT-04.2.json index fcba076d..44e4600e 100644 --- a/docs/api/controls/MNT-04.2.json +++ b/docs/api/controls/MNT-04.2.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.\n▪ IT and/or cybersecurity personnel inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to check media containing diagnostic and test programs for malicious code before the media are used.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to check media containing diagnostic and test programs for malicious code before the media are used. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MNT-04.3.json b/docs/api/controls/MNT-04.3.json index 5311b032..48a81c6d 100644 --- a/docs/api/controls/MNT-04.3.json +++ b/docs/api/controls/MNT-04.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners prevent or control the removal of equipment undergoing maintenance that contains organizational information.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to prevent or control the removal of equipment undergoing maintenance that contains organizational information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -154,10 +155,10 @@ "MA-03(03)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MA-3(CE-3)", @@ -183,6 +184,9 @@ "11.2.5.3", "11.2.5.4" ], + "apac-nzl-ism-3-9": [ + "11.8.10.C.02" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.C" ] diff --git a/docs/api/controls/MNT-04.4.json b/docs/api/controls/MNT-04.4.json index 5afcb10f..731eec9b 100644 --- a/docs/api/controls/MNT-04.4.json +++ b/docs/api/controls/MNT-04.4.json @@ -20,7 +20,7 @@ "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to automatically restrict the use of maintenance tools to authorized maintenance personnel and/or roles.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -96,7 +96,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MNT-04.json b/docs/api/controls/MNT-04.json index dd71ec24..ca702dac 100644 --- a/docs/api/controls/MNT-04.json +++ b/docs/api/controls/MNT-04.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to control and monitor the use of system maintenance tools.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to control and monitor the use of system maintenance tools. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -178,6 +179,12 @@ "A.03.07.04.a[02]", "A.03.07.04.a[03]" ], + "general-nist-800-172-r3": [ + "03.07.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.07.01E" + ], "usa-federal-fbi-cjis-6-0": [ "MA-3" ], diff --git a/docs/api/controls/MNT-05.1.json b/docs/api/controls/MNT-05.1.json index f4b474d1..58b211fb 100644 --- a/docs/api/controls/MNT-05.1.json +++ b/docs/api/controls/MNT-05.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to audit remote, non-local maintenance and diagnostic sessions, as well as review the maintenance action performed during remote maintenance sessions.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to audit remote, non-local maintenance and diagnostic sessions, as well as review the maintenance action performed during remote maintenance sessions. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -173,6 +174,9 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[02]" + ], "general-pci-dss-4-0-1": [ "8.2.7" ], @@ -237,9 +241,6 @@ "MA-01", "MA-04" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], "apac-jpn-ismap": [ "11.2.4.7" ], diff --git a/docs/api/controls/MNT-05.2.json b/docs/api/controls/MNT-05.2.json index deab5855..b03ceafd 100644 --- a/docs/api/controls/MNT-05.2.json +++ b/docs/api/controls/MNT-05.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners require maintenance personnel to notify entity-defined personnel when non-local maintenance is planned (e.g., date/time).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require maintenance personnel to notify affected stakeholders when remote, non-local maintenance is planned (e.g., date/time).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -207,9 +208,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-01", "MA-04" - ], - "emea-isr-cmo-1-0": [ - "12.7" ] } } \ No newline at end of file diff --git a/docs/api/controls/MNT-05.3.json b/docs/api/controls/MNT-05.3.json index 8ca2b6ce..b266ec17 100644 --- a/docs/api/controls/MNT-05.3.json +++ b/docs/api/controls/MNT-05.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity and confidentiality of remote, non-local maintenance and diagnostic communications.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity and confidentiality of remote, non-local maintenance and diagnostic communications. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -105,7 +106,7 @@ "03.07.05.b" ], "general-nist-800-171a-r3": [ - "A.03.07.05.b[02]" + "A.03.07.05.b[01]" ], "general-pci-dss-4-0-1": [ "2.2.7" @@ -134,10 +135,6 @@ "usa-federal-irs-1075-2021": [ "MA-4(CE-6)" ], - "emea-isr-cmo-1-0": [ - "4.20", - "12.7" - ], "americas-can-itsp-10-171-2025": [ "03.07.05.B" ] diff --git a/docs/api/controls/MNT-05.4.json b/docs/api/controls/MNT-05.4.json index 05a632ed..ab2067bc 100644 --- a/docs/api/controls/MNT-05.4.json +++ b/docs/api/controls/MNT-05.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel provide remote disconnect verification to ensure non-local maintenance and diagnostic sessions are properly terminated.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to provide remote disconnect verification to ensure remote, non-local maintenance and diagnostic sessions are properly terminated.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -130,11 +131,6 @@ "usa-federal-irs-1075-2021": [ "MA-4(CE-7)" ], - "emea-isr-cmo-1-0": [ - "4.18", - "4.20", - "12.7" - ], "apac-jpn-ismap": [ "11.2.4.11" ], diff --git a/docs/api/controls/MNT-05.5.json b/docs/api/controls/MNT-05.5.json index f1222a45..a7e97f4f 100644 --- a/docs/api/controls/MNT-05.5.json +++ b/docs/api/controls/MNT-05.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require maintenance personnel to obtain pre-approval and scheduling for remote, non-local maintenance sessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -101,12 +102,12 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[01]" + ], "usa-federal-nerc-cip-2024": [ "CIP-005-7 3.1" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], "apac-ind-sebi-2024": [ "PR.MA.S2" ], diff --git a/docs/api/controls/MNT-05.6.json b/docs/api/controls/MNT-05.6.json index 53038fcb..248b64f9 100644 --- a/docs/api/controls/MNT-05.6.json +++ b/docs/api/controls/MNT-05.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require Technology Assets, Applications and/or Services (TAAS) performing remote, non-local maintenance and/or diagnostic services implement a security capability comparable to the capability implemented on the system being serviced.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MNT-05.7.json b/docs/api/controls/MNT-05.7.json index 387a4978..55070987 100644 --- a/docs/api/controls/MNT-05.7.json +++ b/docs/api/controls/MNT-05.7.json @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MNT-05.json b/docs/api/controls/MNT-05.json index a59d8932..193602f2 100644 --- a/docs/api/controls/MNT-05.json +++ b/docs/api/controls/MNT-05.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Instances of non-console administrative access use cryptographic mechanisms to protect the confidentiality and integrity of the data being transmitted.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to authorize, monitor and control remote, non-local maintenance and diagnostic activities.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -191,8 +192,11 @@ "3.7.5[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.12.d[1]", "A.03.07.05.a[01]", - "A.03.07.05.a[02]" + "A.03.07.05.a[02]", + "A.03.07.05.b[01]", + "A.03.07.05.c[01]" ], "general-pci-dss-4-0-1": [ "8.2.7" @@ -253,16 +257,6 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(h)" ], - "emea-isr-cmo-1-0": [ - "4.18", - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" - ], "emea-gbr-def-stan-05-138-2024": [ "2512" ], diff --git a/docs/api/controls/MNT-06.1.json b/docs/api/controls/MNT-06.1.json index c54bd6a5..72d14c18 100644 --- a/docs/api/controls/MNT-06.1.json +++ b/docs/api/controls/MNT-06.1.json @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -159,12 +160,13 @@ "3.7.6" ], "general-nist-800-171-r3": [ - "03.07.06.a", "03.07.06.c", "03.07.06.d" ], "general-nist-800-171a-r3": [ - "A.03.07.06.c" + "A.03.07.06.c", + "A.03.07.06.d[01]", + "A.03.07.06.d[02]" ], "usa-federal-dow-cmmc-2-level-2": [ "MAL2.-3.7.6" @@ -175,11 +177,8 @@ "usa-federal-gsa-fedramp-5-high": [ "MA-05(01)" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" ], "emea-gbr-def-stan-05-138-2024": [ "2513" @@ -193,7 +192,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2513" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0306" ], "apac-nzl-ism-3-9": [ @@ -203,7 +202,6 @@ "12.5.4.C.04" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A", "03.07.06.C", "03.07.06.D" ] diff --git a/docs/api/controls/MNT-06.2.json b/docs/api/controls/MNT-06.2.json index ef8bec14..b5407138 100644 --- a/docs/api/controls/MNT-06.2.json +++ b/docs/api/controls/MNT-06.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners require maintenance personnel to obtain pre-approval and scheduling for non-local maintenance sessions.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to ensure that non-escorted personnel performing non-IT maintenance activities in the physical proximity of systems have required access authorizations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -106,7 +107,6 @@ "3.7.6" ], "general-nist-800-171-r3": [ - "03.07.06.a", "03.07.06.c" ], "general-nist-800-171a-r3": [ @@ -115,11 +115,13 @@ "usa-federal-dow-cmmc-2-level-2": [ "MAL2.-3.7.6" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" + ], "usa-federal-irs-1075-2021": [ "MA-5(CE-5)" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A", "03.07.06.C" ] } diff --git a/docs/api/controls/MNT-06.json b/docs/api/controls/MNT-06.json index eda34dfa..c66c3100 100644 --- a/docs/api/controls/MNT-06.json +++ b/docs/api/controls/MNT-06.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT personnel, in conjunction with asset custodians, maintain a current list of authorized maintenance organizations or personnel.\n▪ Asset / process owners require maintenance personnel to obtain pre-approval and scheduling for non-local maintenance sessions.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to maintain a current list of authorized maintenance organizations or personnel.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -173,8 +174,7 @@ "A.03.07.06.a", "A.03.07.06.b", "A.03.07.06.c", - "A.03.07.06.d[01]", - "A.03.07.06.d[02]" + "A.03.07.06.d[01]" ], "usa-federal-fbi-cjis-6-0": [ "MA-5" @@ -212,13 +212,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-05" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0305", "ISM-0307" ], diff --git a/docs/api/controls/MNT-07.json b/docs/api/controls/MNT-07.json index 35c98b02..9f0d2348 100644 --- a/docs/api/controls/MNT-07.json +++ b/docs/api/controls/MNT-07.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to maintain proper physical security and configuration control over technology assets awaiting service or repair.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MNT-08.json b/docs/api/controls/MNT-08.json index 86d36324..3ca3003d 100644 --- a/docs/api/controls/MNT-08.json +++ b/docs/api/controls/MNT-08.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to securely conduct field maintenance on geographically deployed assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -123,7 +124,7 @@ "general-nist-800-161-r1-level-3": [ "MA-7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0305" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/MNT-09.json b/docs/api/controls/MNT-09.json index 91dc0224..8a16d909 100644 --- a/docs/api/controls/MNT-09.json +++ b/docs/api/controls/MNT-09.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to ensure off-site maintenance activities are conducted securely and the asset(s) undergoing maintenance actions are secured during physical transfer and storage while off-site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,14 +102,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { "general-nist-800-171-r3": [ "03.07.04.a" ], - "apac-aus-ism-2024-june": [ + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], + "apac-aus-ism-2026-march": [ "ISM-0310" ], "apac-jpn-ismap": [ diff --git a/docs/api/controls/MNT-10.json b/docs/api/controls/MNT-10.json index 14b35620..ebe0f47b 100644 --- a/docs/api/controls/MNT-10.json +++ b/docs/api/controls/MNT-10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to validate:\n(1) Maintenance activities were appropriately performed according to the work order; and \n(2) Applicable security, compliance and resilience controls are operational.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -99,12 +99,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Maintenance", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1598" ], "apac-jpn-ismap": [ diff --git a/docs/api/controls/MNT-11.json b/docs/api/controls/MNT-11.json index 151a429f..7510bba0 100644 --- a/docs/api/controls/MNT-11.json +++ b/docs/api/controls/MNT-11.json @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/controls/MON-01.1.json b/docs/api/controls/MON-01.1.json index f168f00b..5f8d0c7e 100644 --- a/docs/api/controls/MON-01.1.json +++ b/docs/api/controls/MON-01.1.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement Intrusion Detection / Prevention Systems (IDS / IPS) technologies on critical systems, key network segments and network choke points.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -144,8 +145,8 @@ "general-nist-800-171-r3": [ "03.13.01.a" ], - "general-nist-800-172": [ - "3.14.6e" + "general-nist-800-171a-r3": [ + "A.03.13.01.a[01]" ], "general-nist-csf-2-0": [ "DE.CM-01" @@ -224,18 +225,6 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(8)(A)" ], - "emea-isr-cmo-1-0": [ - "7.4", - "11.11", - "12.18", - "23.6" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-6" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", "16.6.10.C.02", @@ -254,11 +243,6 @@ "18.4.12.C.01", "18.4.14.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "3.3", - "4.3", - "4.4" - ], "americas-can-osfi-b13-2022": [ "3.3.2" ], diff --git a/docs/api/controls/MON-01.10.json b/docs/api/controls/MON-01.10.json index f4032ed0..60668e10 100644 --- a/docs/api/controls/MON-01.10.json +++ b/docs/api/controls/MON-01.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor deactivated accounts for attempted usage.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-01.11.json b/docs/api/controls/MON-01.11.json index e5a70558..70b942a8 100644 --- a/docs/api/controls/MON-01.11.json +++ b/docs/api/controls/MON-01.11.json @@ -3,7 +3,7 @@ "title": "Automated Response to Suspicious Events", "family": "MON", "description": "Automated mechanisms exist to implement pre-determined corrective actions in response to detected events that have security incident implications.", - "scf_question": "Does the organization automatically implement pre-determined corrective actions in response to detected events that have security incident implications?", + "scf_question": "Does the organization use automated mechanisms to implement pre-determined corrective actions in response to detected events that have security incident implications?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically implement pre-determined corrective actions in response to detected events that have security incident implications.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -80,7 +80,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-01.12.json b/docs/api/controls/MON-01.12.json index be0f8d7c..245dcca3 100644 --- a/docs/api/controls/MON-01.12.json +++ b/docs/api/controls/MON-01.12.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically alert incident response personnel to inappropriate or anomalous activities that have potential security incident implications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87,7 +87,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -122,6 +123,15 @@ "general-nist-800-171a-r3": [ "A.03.03.05.b" ], + "general-nist-800-172-r3": [ + "03.14.17E", + "03.14.18E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.17E", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.AE", "DE.AE-06" @@ -147,10 +157,7 @@ "usa-federal-irs-1075-2021": [ "SI-4(CE-12)" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-1" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP69", "HML68" ], diff --git a/docs/api/controls/MON-01.13.json b/docs/api/controls/MON-01.13.json index 0914d4b0..b103af71 100644 --- a/docs/api/controls/MON-01.13.json +++ b/docs/api/controls/MON-01.13.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to \"tune\" event monitoring technologies through analyzing communications traffic/event patterns and developing profiles representing common traffic patterns and/or events.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-01.14.json b/docs/api/controls/MON-01.14.json index 3f1c3cec..f854a948 100644 --- a/docs/api/controls/MON-01.14.json +++ b/docs/api/controls/MON-01.14.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for individuals who have been identified as posing an increased level of risk.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for individuals who have been identified as posing an increased level of risk. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -117,12 +118,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SI-04(19)" - ], - "emea-deu-bsrit-2017": [ - "6.7" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-01.15.json b/docs/api/controls/MON-01.15.json index f0188108..7f8b7d76 100644 --- a/docs/api/controls/MON-01.15.json +++ b/docs/api/controls/MON-01.15.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for privileged users.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -134,26 +135,23 @@ "general-nist-800-171-r3": [ "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b" + ], "usa-federal-gsa-fedramp-5-high": [ "SI-04(20)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(c)" ], - "emea-deu-bsrit-2017": [ - "6.7" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" - ], "emea-sau-sacs-002-2022": [ - "TPC-83" + "VII.B.TPC-83" ], "emea-gbr-def-stan-05-138-2024": [ "2203" @@ -164,6 +162,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2203" ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" + ], + "americas-arg-ppd-2018": [ + "B.2.1-3" + ], "americas-can-itsp-10-171-2025": [ "03.01.07.B" ] diff --git a/docs/api/controls/MON-01.16.json b/docs/api/controls/MON-01.16.json index f8500433..0c63ff3d 100644 --- a/docs/api/controls/MON-01.16.json +++ b/docs/api/controls/MON-01.16.json @@ -3,7 +3,7 @@ "title": "Analyze and Prioritize Monitoring Requirements", "family": "MON", "description": "Mechanisms exist to assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes.", - "scf_question": "Does the organization assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes?", + "scf_question": "Does the organization assess its needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,9 +96,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed\n- NIST 800-171A", "family_name": "Continuous Monitoring", "crosswalks": { "general-csa-iot-2": [ @@ -135,83 +135,23 @@ "11.10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.3.a", "III.D.3.b" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "5.5", - "6.3", "6.7" ], - "emea-deu-c5-2020": [ - "OPS-10" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" - ], - "emea-sau-cscc-1-2019": [ - "2-11" - ], - "emea-sau-ecc-1-2018": [ - "2-3-4", - "2-12-1", - "2-12-2", - "2-12-3", - "2-12-4", - "5-1-3-3" - ], "emea-sau-otcc-1-2022": [ - "2-11", - "2-11-1", - "2-11-2" + "2-11-1-9" ], - "emea-sau-sacs-002-2022": [ - "TPC-40", - "TPC-80" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-decree-311-2022": [ - "10.1", - "21.2", - "24.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" - ], - "emea-gbr-cap-1850-2020": [ - "C1" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-0120", "ISM-0580", @@ -226,17 +166,6 @@ "16.6.8.C.01", "16.6.10.C.01", "16.6.10.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "12.2.1", - "12.2.2", - "12.2.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], - "amaericas-can-osfi-self-assessment": [ - "3.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-01.17.json b/docs/api/controls/MON-01.17.json index 90a63b14..84afb106 100644 --- a/docs/api/controls/MON-01.17.json +++ b/docs/api/controls/MON-01.17.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to enable authorized personnel the ability to remotely view and hear content related to an established user session in real time, in accordance with organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-01.2.json b/docs/api/controls/MON-01.2.json index 62628871..f4ccd3ce 100644 --- a/docs/api/controls/MON-01.2.json +++ b/docs/api/controls/MON-01.2.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support near real-time analysis and incident escalation.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support near real-time analysis and incident escalation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -227,19 +228,12 @@ "500.14(b)(2)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)" + "3.4.5.38", + "3.4.5.39" ], "emea-eu-nis2-annex-2024": [ "3.2.2" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "11.11", - "12.31" - ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" @@ -249,10 +243,15 @@ ], "emea-sau-ecc-1-2018": [ "2-12-3-3", + "2-12-3-4", "5-1-3-3" ], + "emea-sau-otcc-1-2022": [ + "2-11-1-3" + ], "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "3.3.14.4.j", + "3.3.14.4.k" ], "emea-gbr-def-stan-05-138-2024": [ "3102" @@ -260,14 +259,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3102" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS19" + "apac-nzl-ism-3-9": [ + "16.6.15.C.01", + "16.6.15.C.02" ], - "amaericas-can-osfi-self-assessment": [ - "3.4" + "apac-sgp-mas-trm-2021": [ + "6.4.7", + "7.7.4", + "12.2.2" ], "americas-can-osfi-b13-2022": [ "3.3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-01.3.json b/docs/api/controls/MON-01.3.json index 23b9ae54..9953609b 100644 --- a/docs/api/controls/MON-01.3.json +++ b/docs/api/controls/MON-01.3.json @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -163,8 +164,8 @@ "general-nist-800-171a-r3": [ "A.03.13.01.a[01]", "A.03.13.01.a[03]", - "A.03.14.06.c[01]", - "A.03.14.06.c[02]" + "A.03.14.06.b", + "A.03.14.06.c[01]" ], "general-nist-csf-2-0": [ "DE.CM-01" @@ -200,6 +201,10 @@ "usa-federal-gsa-fedramp-5-high": [ "SI-04(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(3)", + "101.650(h)(2)" + ], "usa-federal-irs-1075-2021": [ "SI-4(CE-4)", "SI-4(CE-4).a", @@ -221,15 +226,13 @@ "emea-eu-nis2-annex-2024": [ "3.2.3(a)" ], - "emea-isr-cmo-1-0": [ - "9.9", - "9.10", - "10.9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-40" + "apac-aus-ism-2026-march": [ + "ISM-1906", + "ISM-1907", + "ISM-2015" ], "apac-nzl-ism-3-9": [ + "15.2.40.C.02", "16.6.10.C.01", "16.6.10.C.02", "18.4.8.C.01", diff --git a/docs/api/controls/MON-01.4.json b/docs/api/controls/MON-01.4.json index 62de5a72..05a2ed12 100644 --- a/docs/api/controls/MON-01.4.json +++ b/docs/api/controls/MON-01.4.json @@ -21,9 +21,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to generate, monitor, correlate and respond to alerts from physical, cybersecurity, data protection and supply chain activities to achieve integrated situational awareness.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to generate, monitor, correlate and respond to alerts from physical, cybersecurity, data protection and supply chain activities to achieve integrated situational awareness. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -189,8 +190,17 @@ "03.14.06.c" ], "general-nist-800-171a-r3": [ - "A.03.03.02.a.01", - "A.03.03.03.a" + "A.03.03.01.a", + "A.03.03.03.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" + ], + "general-nist-800-172-r3": [ + "03.14.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.17E" ], "general-nist-800-207": [ "NIST Tenet 7" @@ -277,11 +287,15 @@ "usa-federal-gsa-fedramp-5-high": [ "SI-04(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)", + "101.650(h)(2)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "SI-4(CE-5)" @@ -306,25 +320,18 @@ "emea-eu-ai-act-2024": [ "Article 12.1" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "21.2", - "21.4" - ], "emea-sau-cscc-1-2019": [ "2-11-1-1" ], "emea-sau-ecc-1-2018": [ - "2-12-3-1" + "2-12-3-1", + "2-12-3-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-80", - "TPC-87" + "emea-sau-otcc-1-2022": [ + "2-11-1-1" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.a", @@ -339,15 +346,29 @@ "emea-gbr-def-stan-05-138-l2-2024": [ "3101" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-aus-ism-2026-march": [ + "ISM-1959" + ], + "apac-aus-cop-sitc-2020": [ + "7" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP69", "HML68" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP60" ], - "amaericas-can-osfi-self-assessment": [ - "3.6" + "americas-arg-ppd-2018": [ + "B.2.3-3", + "B.2.3-4", + "B.2.5-DS-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP6" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" ], "americas-can-itsp-10-171-2025": [ "03.03.01.A", diff --git a/docs/api/controls/MON-01.5.json b/docs/api/controls/MON-01.5.json index 850769ec..afc08d7d 100644 --- a/docs/api/controls/MON-01.5.json +++ b/docs/api/controls/MON-01.5.json @@ -99,9 +99,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Continuous Monitoring", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -138,6 +138,14 @@ "general-nist-800-82-r3-high": [ "SI-04(14)" ], + "general-nist-800-172-r3": [ + "03.14.19E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.19E[01]", + "DS-A.03.14.19E[02]", + "DS-A.03.14.19E[03]" + ], "general-pci-dss-4-0-1": [ "11.2" ], @@ -150,9 +158,6 @@ "usa-federal-cms-marse-2-0": [ "SI-4(14)" ], - "emea-isr-cmo-1-0": [ - "7.6" - ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", "16.6.10.C.02", diff --git a/docs/api/controls/MON-01.6.json b/docs/api/controls/MON-01.6.json index b54ab0f2..1de93cc2 100644 --- a/docs/api/controls/MON-01.6.json +++ b/docs/api/controls/MON-01.6.json @@ -80,7 +80,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-01.7.json b/docs/api/controls/MON-01.7.json index e6207d93..445636e8 100644 --- a/docs/api/controls/MON-01.7.json +++ b/docs/api/controls/MON-01.7.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a File Integrity Monitor (FIM), or similar change-detection technology, on critical Technology Assets, Applications and/or Services (TAAS) to generate alerts for unauthorized modifications.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a File Integrity Monitor (FIM), or similar change-detection technology, on critical Technology Assets, Applications and/or Services (TAAS) to generate alerts for unauthorized modifications. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -136,6 +137,13 @@ "general-nist-800-160-vol-2-r1": [ "SI-04(24)" ], + "general-nist-800-172-r3": [ + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.01E.a[03]", + "A.03.14.01E.ODP[03]" + ], "general-nist-csf-2-0": [ "DE.CM-09" ], @@ -197,23 +205,16 @@ "SI-04(24)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "SI-4(CE-24)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(e)" - ], - "emea-isr-cmo-1-0": [ - "6.4", - "12.19" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "3.4.4.36(e)" ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", diff --git a/docs/api/controls/MON-01.8.json b/docs/api/controls/MON-01.8.json index 796224a5..4760dd22 100644 --- a/docs/api/controls/MON-01.8.json +++ b/docs/api/controls/MON-01.8.json @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -209,7 +210,6 @@ "3.14.3" ], "general-nist-800-171-r3": [ - "03.03.01.b", "03.03.05.a" ], "general-nist-800-171a": [ @@ -222,10 +222,24 @@ ], "general-nist-800-171a-r3": [ "A.03.03.01.ODP[02]", - "A.03.03.01.b[01]", "A.03.03.05.ODP[01]", "A.03.03.05.a" ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.11.09E", + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.b", + "DS-A.03.11.09E[03]", + "DS-A.03.14.01E.b[01]", + "A.03.14.01E.ODP[04]", + "DS-A.03.14.01E.b[02]", + "A.03.14.01E.ODP[05]", + "DS-A.03.14.01E.b[03]", + "A.03.14.01E.ODP[06]" + ], "general-nist-csf-2-0": [ "DE.CM-01", "DE.AE", @@ -304,13 +318,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-2" @@ -365,21 +382,12 @@ "2447(b)(2)(C)", "2447(c)(4)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)" - ], "emea-eu-nis2-annex-2024": [ "3.2.3", "3.2.4" ], "emea-deu-bsrit-2017": [ - "5.5" - ], - "emea-isr-cmo-1-0": [ - "12.31", - "21.3", - "21.11" + "6.7" ], "emea-sau-cscc-1-2019": [ "2-11-1-2" @@ -387,19 +395,12 @@ "emea-sau-cgiot-2024": [ "2-11-1" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-40" + "emea-sau-otcc-1-2022": [ + "2-11-1-4" ], "emea-gbr-caf-4-0": [ "C1.a" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "emea-gbr-def-stan-05-138-2024": [ "3101", "3102" @@ -413,7 +414,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109" ], "apac-ind-sebi-2024": [ @@ -429,16 +430,21 @@ "12.4.5.5.P" ], "apac-sgp-mas-trm-2021": [ - "12.2.2" + "12.2.6" ], - "amaericas-can-osfi-self-assessment": [ - "3.5" + "americas-arg-ppd-2018": [ + "B.2.5-DS-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP5" ], "americas-can-osfi-b13-2022": [ "3.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.3" + ], "americas-can-itsp-10-171-2025": [ - "03.03.01.B", "03.03.05.A" ] } diff --git a/docs/api/controls/MON-01.9.json b/docs/api/controls/MON-01.9.json index 0c763f4d..035fe1d1 100644 --- a/docs/api/controls/MON-01.9.json +++ b/docs/api/controls/MON-01.9.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.\n▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to log all Internet-bound requests, in order to identify prohibited activities and assist incident handlers with identifying potentially compromised systems.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to log all Internet-bound requests, in order to identify prohibited activities and assist incident handlers with identifying potentially compromised systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,15 +84,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { - "emea-isr-cmo-1-0": [ - "9.14", - "21.20" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0261" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/MON-01.json b/docs/api/controls/MON-01.json index fa2d0148..c76a8008 100644 --- a/docs/api/controls/MON-01.json +++ b/docs/api/controls/MON-01.json @@ -99,7 +99,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -111,9 +112,9 @@ "CC7.2-POF1" ], "general-cis-csc-8-1": [ - "8.0", + "8", "8.2", - "13.0", + "13", "13.6" ], "general-cis-csc-8-1-ig1": [ @@ -182,7 +183,7 @@ "8.15", "8.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -655,16 +656,16 @@ "general-nist-800-171-r3": [ "03.03.01.a", "03.12.03", - "03.14.06.a" + "03.14.06.a", + "03.14.06.a.02" ], "general-nist-800-171a-r3": [ + "A.03.03.01.a", + "A.03.12.03[01]", "A.03.14.06.a.01[01]", "A.03.14.06.a.01[02]", "A.03.14.06.a.02" ], - "general-nist-800-172": [ - "3.14.2e" - ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 6", @@ -709,9 +710,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-sparta": [ "CM0090" ], @@ -803,18 +801,22 @@ "AU-01", "SI-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)", + "101.650(f)(3)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(3)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-1", @@ -868,9 +870,8 @@ "SI-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" + "3.4.5.39", + "3.5.52" ], "emea-eu-dora-2023": [ "Article 10.3" @@ -882,72 +883,46 @@ "3.2.6", "13.1.2(f)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "5.5", - "6.3", - "6.7" - ], "emea-deu-c5-2020": [ - "OPS-10" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" + "RB-10" ], "emea-sau-cscc-1-2019": [ - "2-11" + "2-11-1" ], "emea-sau-cgiot-2024": [ "2-11-1" ], "emea-sau-ecc-1-2018": [ - "2-3-4", "2-12-1", "2-12-2", - "2-12-3", - "2-12-4", "5-1-3-3" ], "emea-sau-otcc-1-2022": [ - "2-11", "2-11-1", + "2-11-1-10", "2-11-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-40", - "TPC-80" - ], "emea-sau-sama-csf-1-2017": [ - "3.3.14" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1", - "Article 21.2", - "Article 24.1" + "3.3.14", + "3.3.14.1", + "3.3.14.3", + "3.3.14.4", + "3.3.14.4.a", + "3.3.14.4.b", + "3.3.14.4.c", + "3.3.14.4.d", + "3.3.14.4.e", + "3.3.14.4.f", + "3.3.14.4.g" ], "emea-esp-decree-311-2022": [ - "10.1", - "21.2", - "24.1" + "Article 8(3)", + "Article 12(6)(l)", + "Article 24(1)", + "Article 24(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1" @@ -982,7 +957,7 @@ "3102", "3106" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-0120", "ISM-0580", @@ -991,6 +966,12 @@ "ISM-1294", "ISM-1586" ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], + "apac-chn-data-security-law-2021": [ + "Article 29" + ], "apac-ind-sebi-2024": [ "DE.CM.S2", "PR.AA.S8" @@ -1000,12 +981,14 @@ "12.4.1", "12.4.1.15.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HHSP70", - "HML70" + "apac-mys-bnm-rmit-2025": [ + "10.57", + "11.9", + "12.3" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS18" + "HHSP70", + "HML70" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP61" @@ -1018,25 +1001,25 @@ "16.6.10.C.02" ], "apac-sgp-mas-trm-2021": [ - "12.2.1", - "12.2.2", - "12.2.3" + "6.4.7", + "12.2.1" ], "americas-bmu-mba-coc-2020": [ "6.21" ], - "amaericas-can-osfi-self-assessment": [ - "3.5" - ], "americas-can-osfi-b13-2022": [ "3.3", "3.3.1", "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" + ], "americas-can-itsp-10-171-2025": [ "03.03.01.A", "03.12.03", - "03.14.06.A" + "03.14.06.A", + "03.14.06.A.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-02.1.json b/docs/api/controls/MON-02.1.json index 2b4aa083..6a1c9396 100644 --- a/docs/api/controls/MON-02.1.json +++ b/docs/api/controls/MON-02.1.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of vulnerability scanning activities and associated administrator accounts are reviewed to ensure that those activities are limited to the timeframes of legitimate scans.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate both technical and non-technical information from across the enterprise by a Security Incident Event Manager (SIEM) or similar automated tool, to enhance organization-wide situational awareness.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104,7 +104,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -209,6 +210,7 @@ "3.14.7[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.05.a", "A.03.03.05.c[02]" ], "general-nist-800-207": [ @@ -240,9 +242,6 @@ "10.4.1.1", "12.10.5" ], - "general-scf-dpmp-2025": [ - "7.13" - ], "general-tisax-6-0-3": [ "5.2.4" ], @@ -297,37 +296,30 @@ "usa-federal-cms-marse-2-0": [ "AU-6(3)" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.6", - "21.12", - "21.13", - "21.19" + "emea-eu-eba-ict-srm-2025": [ + "3.4.5.38(a)", + "3.4.5.38(b)", + "3.4.5.38(c)", + "3.4.5.39", + "3.4.5.40" ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" - ], "emea-sau-sacs-002-2022": [ - "TPC-81" + "VII.B.TPC-81" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], - "apac-aus-ism-2024-june": [ - "ISM-1228" + "apac-aus-ism-2026-march": [ + "ISM-1228", + "ISM-1961", + "ISM-1964" + ], + "apac-aus-cop-sitc-2020": [ + "10" ], "apac-nzl-ism-3-9": [ "16.6.14.C.01", @@ -336,9 +328,6 @@ "apac-sgp-mas-trm-2021": [ "12.2.5" ], - "amaericas-can-osfi-self-assessment": [ - "3.6" - ], "americas-can-osfi-b13-2022": [ "3.3.1" ], diff --git a/docs/api/controls/MON-02.2.json b/docs/api/controls/MON-02.2.json index a1f55b11..b75f6cd5 100644 --- a/docs/api/controls/MON-02.2.json +++ b/docs/api/controls/MON-02.2.json @@ -20,11 +20,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically centrally collect, review and analyze audit records from multiple sources.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -104,7 +104,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -155,10 +156,13 @@ "AU-06(04)" ], "general-nist-800-171-r3": [ - "03.03.01.b", "03.03.05.a", "03.03.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.03.05.a", + "A.03.03.05.c[01]" + ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 7" @@ -216,30 +220,17 @@ "7123(c)(7)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" + "3.5.52" ], "emea-deu-c5-2020": [ - "OPS-13" + "RB-10", + "SIM-05" ], "emea-sau-cscc-1-2019": [ "2-11-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-4" - ], - "emea-sau-otcc-1-2022": [ - "2-11-1-9", - "2-11-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-81" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" - ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "apac-aus-essential-8-2024": [ "ML2-P3", @@ -251,7 +242,7 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1228" ], "apac-nzl-ism-3-9": [ @@ -262,18 +253,11 @@ "16.6.12.C.02", "16.6.12.C.03" ], - "apac-sgp-mas-trm-2021": [ - "12.2.6" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], "americas-can-osfi-b13-2022": [ "3.3.1", "3.3.2" ], "americas-can-itsp-10-171-2025": [ - "03.03.01.B", "03.03.05.A", "03.03.05.C" ] diff --git a/docs/api/controls/MON-02.3.json b/docs/api/controls/MON-02.3.json index 07349e4d..041369d2 100644 --- a/docs/api/controls/MON-02.3.json +++ b/docs/api/controls/MON-02.3.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically integrate the analysis of audit records with analysis of vulnerability scanners, network performance, system monitoring and other sources to further enhance the ability to identify inappropriate or unusual activity.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -100,7 +100,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -162,6 +163,17 @@ "general-nist-800-171-r3": [ "03.03.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.03.05.c[02]" + ], + "general-nist-800-172-r3": [ + "03.03.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.04E", + "A.03.03.04E.ODP[01]", + "A.03.03.04E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 4", "NIST Tenet 5", @@ -186,18 +198,6 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-06(05)" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" - ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "americas-can-itsp-10-171-2025": [ "03.03.05.C" ] diff --git a/docs/api/controls/MON-02.4.json b/docs/api/controls/MON-02.4.json index 1a6d0f4a..df72294a 100644 --- a/docs/api/controls/MON-02.4.json +++ b/docs/api/controls/MON-02.4.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual or malevolent activity.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual or malevolent activity. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -98,7 +98,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-02.5.json b/docs/api/controls/MON-02.5.json index d010778e..256058b7 100644 --- a/docs/api/controls/MON-02.5.json +++ b/docs/api/controls/MON-02.5.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to specify the permitted actions for both users and Technology Assets, Applications and/or Services (TAAS) associated with the review, analysis and reporting of audit information.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to specify the permitted actions for both users and Technology Assets, Applications and/or Services (TAAS) associated with the review, analysis and reporting of audit information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -105,9 +106,6 @@ ], "usa-federal-irs-1075-2021": [ "AU-6(CE-7)" - ], - "emea-sau-cscc-1-2019": [ - "2-3-1-8" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-02.6.json b/docs/api/controls/MON-02.6.json index 3f501e9b..ba68cd06 100644 --- a/docs/api/controls/MON-02.6.json +++ b/docs/api/controls/MON-02.6.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to adjust the level of audit review, analysis and reporting based on evolving threat information from law enforcement, industry associations or other credible sources of threat intelligence.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to adjust the level of audit review, analysis and reporting based on evolving threat information from law enforcement, industry associations or other credible sources of threat intelligence. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -143,6 +144,12 @@ "general-nist-800-161-r1-level-3": [ "AU-6" ], + "general-nist-800-171-r3": [ + "03.03.01.b" + ], + "general-nist-800-171a-r3": [ + "A.03.03.01.b[01]" + ], "usa-federal-fbi-cjis-6-0": [ "AU-6" ], @@ -174,12 +181,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-06" ], - "emea-deu-c5-2020": [ - "OIS-05" + "emea-sau-otcc-1-2022": [ + "2-11-1-9" ], "apac-jpn-ismap": [ "6.1.3.5", "6.1.4.7" + ], + "americas-can-itsp-10-171-2025": [ + "03.03.01.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-02.7.json b/docs/api/controls/MON-02.7.json index b87f293d..411b60c4 100644 --- a/docs/api/controls/MON-02.7.json +++ b/docs/api/controls/MON-02.7.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically compile audit records into an organization-wide audit trail that is time-correlated.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -104,7 +104,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -147,6 +148,9 @@ "general-nist-800-171-r3": [ "03.03.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.01.a" + ], "general-pci-dss-4-0-1": [ "10.6", "10.6.1", @@ -201,12 +205,10 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "AU-02-SID" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-1", - "2-11-1-2", - "2-11-1-3" + "emea-deu-c5-2020": [ + "RB-14" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0988" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/MON-02.8.json b/docs/api/controls/MON-02.8.json index 5959fd83..ec65545c 100644 --- a/docs/api/controls/MON-02.8.json +++ b/docs/api/controls/MON-02.8.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide privileged users or roles the capability to change the auditing to be performed on specified system components, based on specific event criteria within specified time thresholds.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide privileged users or roles the capability to change the auditing to be performed on specified system components, based on specific event criteria within specified time thresholds. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -112,6 +113,9 @@ ], "usa-federal-gsa-fedramp-5-high": [ "AU-12(03)" + ], + "emea-deu-c5-2020": [ + "RB-15" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-02.9.json b/docs/api/controls/MON-02.9.json index 474cc7fd..2e3cb9e2 100644 --- a/docs/api/controls/MON-02.9.json +++ b/docs/api/controls/MON-02.9.json @@ -102,7 +102,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-02.json b/docs/api/controls/MON-02.json index 8f3be026..cb1cf68d 100644 --- a/docs/api/controls/MON-02.json +++ b/docs/api/controls/MON-02.json @@ -3,7 +3,7 @@ "title": "Centralized Collection of Security Event Logs", "family": "MON", "description": "Mechanisms exist to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs.", - "scf_question": "Does the organization utilize a Security Incident Event Manager (SIEM) or similar automated tool, to support the centralized collection of security-related event logs?", + "scf_question": "Does the organization utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104,7 +104,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -336,10 +337,6 @@ "10.4.1", "10.4.1.1" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.13" - ], "general-swift-cscf-2025": [ "6.1", "6.2", @@ -445,48 +442,50 @@ "SI-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" + "3.4.5.38", + "3.4.5.39", + "3.5.52" ], "emea-eu-nis2-annex-2024": [ "3.2.6" ], "emea-deu-c5-2020": [ - "OPS-14" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.3", - "21.4", - "21.6", - "21.12" + "RB-10", + "RB-13", + "RB-16-DOAR", + "SIM-05" ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" ], "emea-sau-otcc-1-2022": [ - "2-11-1-3", - "2-11-1-9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-81" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "2-11-1-5", + "2-11-1-6", + "2-11-1-7", + "2-11-1-8" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-1228", "ISM-1405", "ISM-1536", "ISM-1537", "ISM-1566", - "ISM-1650" + "ISM-1650", + "ISM-1911", + "ISM-1960", + "ISM-1963", + "ISM-1976", + "ISM-1977", + "ISM-1978", + "ISM-1979", + "ISM-1983", + "ISM-1986", + "ISM-1987" ], "apac-nzl-ism-3-9": [ "16.6.11.C.01", @@ -496,18 +495,13 @@ "16.6.12.C.02", "16.6.12.C.03" ], - "apac-sgp-mas-trm-2021": [ - "9.1.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], - "amaericas-can-osfi-self-assessment": [ - "3.2" - ], "americas-can-osfi-b13-2022": [ "3.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1", + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.03.05.A", "03.03.05.C" diff --git a/docs/api/controls/MON-03.1.json b/docs/api/controls/MON-03.1.json index 835c6c39..edb9295f 100644 --- a/docs/api/controls/MON-03.1.json +++ b/docs/api/controls/MON-03.1.json @@ -2,8 +2,8 @@ "control_id": "MON-03.1", "title": "Sensitive Event Log Information", "family": "MON", - "description": "Mechanisms exist to protect sensitive/regulated data contained in log files.", - "scf_question": "Does the organization protect sensitive/regulated data contained in log files?", + "description": "Mechanisms exist to protect sensitive and/or regulated data contained in log files.", + "scf_question": "Does the organization protect sensitive and/or regulated data contained in log files?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect sensitive/regulated data contained in log files.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect sensitive/regulated data contained in log files. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -64,9 +64,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Continuous Monitoring", "crosswalks": { "general-cis-csc-8-1": [ @@ -143,8 +143,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-03 (01)" ], - "emea-isr-cmo-1-0": [ - "21.4" + "apac-aus-ism-2026-march": [ + "ISM-2052" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP2" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-03.2.json b/docs/api/controls/MON-03.2.json index a1d26ec2..f2f06ed3 100644 --- a/docs/api/controls/MON-03.2.json +++ b/docs/api/controls/MON-03.2.json @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -108,6 +109,9 @@ "3.3.1[c]", "3.3.2[a]" ], + "general-nist-800-171a-r3": [ + "A.03.03.01.a" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -178,10 +182,10 @@ "11.10(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.3.b" @@ -192,8 +196,9 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(b)" ], - "emea-isr-cmo-1-0": [ - "12.17" + "emea-deu-c5-2020": [ + "RB-14", + "RB-16" ], "emea-sau-cscc-1-2019": [ "2-11-1-3" @@ -210,10 +215,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3107" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0407" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP70", "HML70" ], @@ -226,9 +231,6 @@ "16.6.10.C.01", "16.6.10.C.02" ], - "apac-sgp-mas-trm-2021": [ - "9.2.2" - ], "americas-can-itsp-10-171-2025": [ "03.03.01.A" ] diff --git a/docs/api/controls/MON-03.3.json b/docs/api/controls/MON-03.3.json index 4a98b67a..a38b8ff6 100644 --- a/docs/api/controls/MON-03.3.json +++ b/docs/api/controls/MON-03.3.json @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -185,15 +186,8 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(d)" ], - "emea-deu-c5-2020": [ - "OPS-16" - ], - "emea-isr-cmo-1-0": [ - "21.10", - "21.21" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-def-stan-05-138-2024": [ "2216" @@ -209,13 +203,18 @@ "ML3-P4", "ML3-P7" ], - "apac-aus-ism-2024-june": [ - "ISM-1537" + "apac-aus-ism-2026-march": [ + "ISM-1537", + "ISM-1889" ], "apac-jpn-ismap": [ "12.4.3", "12.4.3.1" ], + "apac-nzl-ism-3-9": [ + "16.4.41.C.01", + "16.4.41.C.02" + ], "americas-can-itsp-10-171-2025": [ "03.01.07.B" ] diff --git a/docs/api/controls/MON-03.4.json b/docs/api/controls/MON-03.4.json index 6836716c..e375baa8 100644 --- a/docs/api/controls/MON-03.4.json +++ b/docs/api/controls/MON-03.4.json @@ -52,16 +52,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-owasp-top-10-2025": [ "A09:2025" - ], - "emea-isr-cmo-1-0": [ - "21.5", - "21.21" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-03.5.json b/docs/api/controls/MON-03.5.json index 927f7cb3..cb3f4879 100644 --- a/docs/api/controls/MON-03.5.json +++ b/docs/api/controls/MON-03.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to limit Personal Data (PD) contained in audit records to the elements identified in the Data Privacy Risk Assessment (DPRA).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-03.6.json b/docs/api/controls/MON-03.6.json index 207a6941..6b30d7b5 100644 --- a/docs/api/controls/MON-03.6.json +++ b/docs/api/controls/MON-03.6.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to centrally manage and update the criteria to be captured in event logs generated by organization-defined system components.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to centrally manage and update the criteria to be captured in event logs generated by organization-defined system components. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -71,9 +71,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Continuous Monitoring", "crosswalks": { "general-nist-800-53-r4": [ @@ -97,6 +97,13 @@ "general-nist-800-161-r1-level-2": [ "PL-9" ], + "general-nist-800-171-r3": [ + "03.03.01.b" + ], + "general-nist-800-171a-r3": [ + "A.03.03.01.b[01]", + "A.03.03.01.b[02]" + ], "usa-federal-fbi-cjis-6-0": [ "PL-9" ], @@ -116,8 +123,8 @@ "AU-2(3)", "AU-2(3)-IS.1" ], - "emea-sau-ecc-1-2018": [ - "2-12-4" + "americas-can-itsp-10-171-2025": [ + "03.03.01.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-03.7.json b/docs/api/controls/MON-03.7.json index 13faf912..aa0edd1c 100644 --- a/docs/api/controls/MON-03.7.json +++ b/docs/api/controls/MON-03.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to ensure databases produce audit records that contain sufficient information to monitor database activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -97,7 +98,10 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "7.2.6" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "2-2-1-8" + ], + "apac-aus-ism-2026-march": [ "ISM-1537" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/MON-03.json b/docs/api/controls/MON-03.json index 4fef35e1..0c46b768 100644 --- a/docs/api/controls/MON-03.json +++ b/docs/api/controls/MON-03.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.\n▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum:\n(1) Establish what type of event occurred;\n(2) When (date and time) the event occurred;\n(3) Where the event occurred;\n(4) The source of the event;\n(5) The outcome (success or failure) of the event; and \n(6) The identity of any user/subject associated with the event.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum:\n(1) Establish what type of event occurred;\n(2) When (date and time) the event occurred;\n(3) Where the event occurred;\n(4) The source of the event;\n(5) The outcome (success or failure) of the event; and \n(6) The identity of any user/subject associated with the event. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -233,7 +234,7 @@ "general-nist-800-171a-r3": [ "A.03.03.01.ODP[01]", "A.03.03.01.a", - "A.03.03.01.b[02]", + "A.03.03.02.a.01", "A.03.03.02.a.02", "A.03.03.02.a.03", "A.03.03.02.a.04", @@ -339,10 +340,10 @@ "AU-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-3" @@ -385,9 +386,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-03" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" - ], "emea-eu-nis2-annex-2024": [ "3.2.3", "3.2.3(c)", @@ -405,27 +403,28 @@ "6.3" ], "emea-deu-c5-2020": [ - "OPS-15" + "RB-10" ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.2", - "21.5", - "21.7", - "21.10" + "emea-isr-cmo-2-0": [ + "Appendix A, 12.2" ], "emea-sau-cscc-1-2019": [ "2-11-1-5" ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.1" + "emea-sau-otcc-1-2022": [ + "2-11-1-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-87" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.14.3.a" ], "emea-esp-decree-311-2022": [ - "24.1" + "Article 20(b)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.a" @@ -445,11 +444,16 @@ "ML3-P3", "ML3-P5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0582", "ISM-0585", "ISM-1536", - "ISM-1537" + "ISM-1537", + "ISM-1895", + "ISM-2051" + ], + "apac-aus-cop-sitc-2020": [ + "7" ], "apac-ind-sebi-2024": [ "PR.AA.S9" @@ -472,7 +476,7 @@ "12.4.1.17", "12.4.1.18" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP70", "HML70" ], @@ -486,7 +490,7 @@ "16.6.10.C.02" ], "americas-bmu-mba-coc-2020": [ - "6.21" + "6.21-BP6" ], "americas-can-osfi-b13-2022": [ "3.2.7", diff --git a/docs/api/controls/MON-04.json b/docs/api/controls/MON-04.json index b54d672c..127e6296 100644 --- a/docs/api/controls/MON-04.json +++ b/docs/api/controls/MON-04.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to allocate and proactively manage sufficient event log storage capacity to reduce the likelihood of such capacity being exceeded.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to allocate and proactively manage sufficient event log storage capacity to reduce the likelihood of such capacity being exceeded. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -73,24 +73,25 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-cis-csc-8-1": [ "8.3", - "8.1" + "8.10" ], "general-cis-csc-8-1-ig1": [ "8.3" ], "general-cis-csc-8-1-ig2": [ "8.3", - "8.1" + "8.10" ], "general-cis-csc-8-1-ig3": [ "8.3", - "8.1" + "8.10" ], "general-govramp": [ "AU-04" @@ -165,12 +166,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-04" ], - "emea-isr-cmo-1-0": [ - "21.8" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-5" - ], "apac-nzl-ism-3-9": [ "16.6.13.C.01", "16.6.13.C.02", diff --git a/docs/api/controls/MON-05.1.json b/docs/api/controls/MON-05.1.json index 1ea54cf5..a31f7721 100644 --- a/docs/api/controls/MON-05.1.json +++ b/docs/api/controls/MON-05.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide 24x7x365 near real-time alerting capability when an event log processing failure occurs.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide 24x7x365 near real-time alerting capability when an event log processing failure occurs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -108,6 +109,12 @@ "general-nist-800-82-r3-high": [ "AU-05(02)" ], + "general-nist-800-172-r3": [ + "03.03.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.03.02E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-low": [ "SI-04(12)" ], @@ -125,10 +132,7 @@ "SI-4(CE-12)" ], "emea-deu-c5-2020": [ - "OPS-17" - ], - "emea-isr-cmo-1-0": [ - "21.9" + "RB-16-DOAR" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-05.2.json b/docs/api/controls/MON-05.2.json index d9637436..adfc1a47 100644 --- a/docs/api/controls/MON-05.2.json +++ b/docs/api/controls/MON-05.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically alert appropriate personnel when the allocated volume reaches an organization-defined percentage of maximum event log storage capacity.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -73,7 +73,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-05.json b/docs/api/controls/MON-05.json index c9d740c1..3ab2c69f 100644 --- a/docs/api/controls/MON-05.json +++ b/docs/api/controls/MON-05.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to alert appropriate personnel in the event of a log processing failure and take actions to remedy the disruption.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -79,7 +79,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -139,6 +140,14 @@ "A.03.03.04.a", "A.03.03.04.b" ], + "general-nist-800-172-r3": [ + "03.03.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.02E", + "A.03.03.02E.ODP[03]", + "A.03.03.02E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -184,15 +193,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-05" ], - "emea-deu-c5-2020": [ - "OPS-17" - ], - "emea-isr-cmo-1-0": [ - "21.9" - ], - "emea-sau-otcc-1-2022": [ - "2-11-1-2" - ], "americas-can-itsp-10-171-2025": [ "03.03.04.B" ] diff --git a/docs/api/controls/MON-06.1.json b/docs/api/controls/MON-06.1.json index ca31d326..050ec4fb 100644 --- a/docs/api/controls/MON-06.1.json +++ b/docs/api/controls/MON-06.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide and implement the capability for auditing the parameters of user query events for data sets containing Personal Data (PD).", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -58,7 +58,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-06.2.json b/docs/api/controls/MON-06.2.json index d1e04eda..788dc083 100644 --- a/docs/api/controls/MON-06.2.json +++ b/docs/api/controls/MON-06.2.json @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-06.json b/docs/api/controls/MON-06.json index bbb1f99e..4051c3b9 100644 --- a/docs/api/controls/MON-06.json +++ b/docs/api/controls/MON-06.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide an event log report generation capability to aid in detecting and assessing anomalous activities.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide an event log report generation capability to aid in detecting and assessing anomalous activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -261,11 +262,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-12" ], - "emea-isr-cmo-1-0": [ - "21.3", - "21.11", - "21.19", - "21.20" + "emea-deu-c5-2020": [ + "RB-16" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-def-stan-05-138-2024": [ "3108" @@ -279,12 +280,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3108" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1660" ], - "apac-sgp-mas-trm-2021": [ - "12.2.6" - ], "americas-can-itsp-10-171-2025": [ "03.03.05.B", "03.03.06.A" diff --git a/docs/api/controls/MON-07.1.json b/docs/api/controls/MON-07.1.json index 02aac9f5..516ec15f 100644 --- a/docs/api/controls/MON-07.1.json +++ b/docs/api/controls/MON-07.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to synchronize internal system clocks with an authoritative time source.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to synchronize internal system clocks with an authoritative time source. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -177,9 +178,6 @@ "emea-eu-nis2-annex-2024": [ "3.2.6" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-4" - ], "emea-gbr-def-stan-05-138-2024": [ "2421" ], @@ -192,7 +190,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2421" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP71", "HML71" ], diff --git a/docs/api/controls/MON-07.json b/docs/api/controls/MON-07.json index 3a8c8988..934bddba 100644 --- a/docs/api/controls/MON-07.json +++ b/docs/api/controls/MON-07.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use an authoritative time source to generate time stamps for event logs.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use an authoritative time source to generate time stamps for event logs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -128,6 +129,7 @@ "3.3.7[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.02.a.02", "A.03.03.07.ODP[01]", "A.03.03.07.a", "A.03.03.07.b[01]" @@ -199,12 +201,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-09" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-4" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.5 [MP.INFO.5]" - ], "americas-can-itsp-10-171-2025": [ "03.03.02.A.02", "03.03.07.A" diff --git a/docs/api/controls/MON-08.1.json b/docs/api/controls/MON-08.1.json index 6ce6c053..0e4ed2e4 100644 --- a/docs/api/controls/MON-08.1.json +++ b/docs/api/controls/MON-08.1.json @@ -68,7 +68,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -116,6 +117,15 @@ "general-nist-800-171-r3": [ "03.03.08.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]" + ], + "general-nist-800-172-r3": [ + "03.03.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.01E" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -140,11 +150,6 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-09(02)" ], - "emea-isr-cmo-1-0": [ - "21.14", - "21.15", - "21.17" - ], "emea-sau-cscc-1-2019": [ "2-11-1-5", "2-11-2" diff --git a/docs/api/controls/MON-08.2.json b/docs/api/controls/MON-08.2.json index fdbe37d1..3aa2e420 100644 --- a/docs/api/controls/MON-08.2.json +++ b/docs/api/controls/MON-08.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict access to the management of event logs for privileged users to protect event logs and audit tools from unauthorized access, modification and deletion.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to restrict access to the management of event logs to privileged users with a specific business need.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -131,6 +132,7 @@ "3.3.9[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]", "A.03.03.08.b" ], "general-owasp-top-10-2025": [ @@ -172,17 +174,20 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-09(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-9(CE-4)" ], "usa-federal-cms-marse-2-0": [ "AU-9(4)" ], - "emea-deu-c5-2020": [ - "OPS-16" + "apac-aus-ism-2026-march": [ + "ISM-1985" ], - "emea-isr-cmo-1-0": [ - "21.14" + "apac-nzl-ism-3-9": [ + "16.4.41.C.03" ], "americas-can-itsp-10-171-2025": [ "03.03.08.A", diff --git a/docs/api/controls/MON-08.3.json b/docs/api/controls/MON-08.3.json index 10eea3c3..a8a8b7b9 100644 --- a/docs/api/controls/MON-08.3.json +++ b/docs/api/controls/MON-08.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational cryptographic capability exists to protect the integrity of event logs and audit tools.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational cryptographic capability exists to protect the integrity of event logs and audit tools. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -108,9 +109,15 @@ "general-nist-800-171-r3": [ "03.03.08.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]" + ], "usa-federal-gsa-fedramp-5-high": [ "AU-09(03)" ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP2" + ], "americas-can-itsp-10-171-2025": [ "03.03.08.A" ] diff --git a/docs/api/controls/MON-08.4.json b/docs/api/controls/MON-08.4.json index f2589448..b7605081 100644 --- a/docs/api/controls/MON-08.4.json +++ b/docs/api/controls/MON-08.4.json @@ -86,7 +86,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -101,6 +102,14 @@ ], "general-nist-800-160-vol-2-r1": [ "AU-09(05)" + ], + "general-nist-800-172-r3": [ + "03.03.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.03E", + "A.03.03.03E.ODP[01]", + "A.03.03.03E.ODP[02]" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-08.json b/docs/api/controls/MON-08.json index 1866afa6..396f775b 100644 --- a/docs/api/controls/MON-08.json +++ b/docs/api/controls/MON-08.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel retain security event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and/or contractual retention requirements.\n▪ IT and/or cybersecurity personnel restrict access to the management of event logs for privileged users to protect event logs and audit tools from unauthorized access, modification and deletion.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect event logs and audit tools from unauthorized access, modification and deletion.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -171,7 +172,8 @@ "general-nist-800-171-r3": [ "03.03.03.b", "03.03.06.b", - "03.03.08.a" + "03.03.08.a", + "03.03.08.b" ], "general-nist-800-171a": [ "3.3.8[a]", @@ -243,6 +245,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-09" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-9" ], @@ -262,12 +267,7 @@ "AU-09" ], "emea-deu-c5-2020": [ - "OPS-16" - ], - "emea-isr-cmo-1-0": [ - "21.4", - "21.14", - "21.16" + "RB-16" ], "emea-sau-cscc-1-2019": [ "2-3-1-8", @@ -275,14 +275,16 @@ "2-11-2" ], "emea-sau-ecc-1-2018": [ - "2-12-3-5", "2-14-3-3" ], "emea-sau-otcc-1-2022": [ "2-3-1-10" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.10 [OP.EXP.10]" + "emea-sau-sama-csf-1-2017": [ + "3.3.14.4.h" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.b" @@ -306,9 +308,8 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991" + "apac-aus-ism-2026-march": [ + "ISM-1815" ], "apac-ind-sebi-2024": [ "PR.AA.S9" @@ -326,13 +327,17 @@ "16.6.13.C.03", "16.6.13.C.04" ], + "apac-sgp-mas-trm-2021": [ + "12.2.2" + ], "americas-bmu-mba-coc-2020": [ - "6.21" + "6.21-BP3" ], "americas-can-itsp-10-171-2025": [ "03.03.03.B", "03.03.06.B", - "03.03.08.A" + "03.03.08.A", + "03.03.08.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-09.1.json b/docs/api/controls/MON-09.1.json index 28dc9bcd..a772469e 100644 --- a/docs/api/controls/MON-09.1.json +++ b/docs/api/controls/MON-09.1.json @@ -48,7 +48,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-09.json b/docs/api/controls/MON-09.json index 68e2eee9..2081912e 100644 --- a/docs/api/controls/MON-09.json +++ b/docs/api/controls/MON-09.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a non-repudiation capability to protect against an individual falsely denying having performed a particular action.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a non-repudiation capability to protect against an individual falsely denying having performed a particular action. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -59,7 +59,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -103,25 +104,6 @@ ], "usa-federal-cms-marse-2-0": [ "AU-10" - ], - "emea-us-psd2-2015": [ - "26" - ], - "emea-isr-cmo-1-0": [ - "21.14" - ], - "apac-sgp-mas-trm-2021": [ - "14.2.1", - "14.2.2", - "14.2.3", - "14.2.4", - "14.2.5", - "14.2.6", - "14.2.7", - "14.2.8", - "14.2.9", - "14.2.10", - "14.2.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-10.json b/docs/api/controls/MON-10.json index a35ca90b..6e535c95 100644 --- a/docs/api/controls/MON-10.json +++ b/docs/api/controls/MON-10.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -88,13 +89,13 @@ "C1.2" ], "general-cis-csc-8-1": [ - "8.1" + "8.10" ], "general-cis-csc-8-1-ig2": [ - "8.1" + "8.10" ], "general-cis-csc-8-1-ig3": [ - "8.1" + "8.10" ], "general-csa-cmm-4-1-0": [ "LOG-04" @@ -176,9 +177,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "10.5.1" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-shared-assessments-sig-2025": [ "D.3" ], @@ -206,6 +204,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-11" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-11" ], @@ -243,12 +244,7 @@ "3.2.5" ], "emea-deu-c5-2020": [ - "OPS-14" - ], - "emea-isr-cmo-1-0": [ - "21.4", - "21.15", - "21.17" + "RB-13" ], "emea-sau-cscc-1-2019": [ "2-11-2" @@ -261,7 +257,7 @@ "2-14-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-75" + "VII.B.TPC-75" ], "emea-gbr-caf-4-0": [ "C1.b" @@ -281,19 +277,25 @@ "3103", "3107" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", - "ISM-1213" - ], - "apac-chn-pipl-2021": [ - "19" + "apac-aus-ism-2026-march": [ + "ISM-1213", + "ISM-1988", + "ISM-1989" ], "apac-ind-sebi-2024": [ "PR.AA.S9" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS18" + "apac-mys-bnm-rmit-2025": [ + "10.42" + ], + "apac-nzl-ism-3-9": [ + "16.6.13.C.05" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" ], "americas-can-itsp-10-171-2025": [ "03.03.03.B" diff --git a/docs/api/controls/MON-11.1.json b/docs/api/controls/MON-11.1.json index 3345af62..04f1b2e4 100644 --- a/docs/api/controls/MON-11.1.json +++ b/docs/api/controls/MON-11.1.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically analyze network traffic to detect covert data exfiltration.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -57,7 +57,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-11.2.json b/docs/api/controls/MON-11.2.json index 758f84c7..eb0df578 100644 --- a/docs/api/controls/MON-11.2.json +++ b/docs/api/controls/MON-11.2.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically detect unauthorized network services and alert incident response personnel.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically detect unauthorized network services and alert incident response personnel. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -75,7 +75,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-11.3.json b/docs/api/controls/MON-11.3.json index 1afac8a6..7bb9a60c 100644 --- a/docs/api/controls/MON-11.3.json +++ b/docs/api/controls/MON-11.3.json @@ -19,11 +19,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically identify and alert on Indicators of Compromise (IoC).", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically identify and alert on Indicators of Compromise (IoC). ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -107,7 +107,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -156,8 +157,26 @@ "03.14.06.b", "03.14.06.c" ], - "general-nist-800-172": [ - "3.11.2e" + "general-nist-800-171a-r3": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", + "A.03.14.06.b" + ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.11.02E", + "03.11.09E", + "03.14.17E", + "03.14.18E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.a", + "DS-A.03.11.02E.a.01[01]", + "DS-A.03.11.09E[01]", + "DS-A.03.11.09E[02]", + "DS-A.03.14.17E", + "A.03.14.18E.ODP[03]" ], "general-nist-csf-2-0": [ "DE.CM" @@ -201,15 +220,18 @@ "7123(c)(8)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" ], "emea-deu-bsrit-2017": [ "5.4" ], - "apac-aus-ism-2024-june": [ + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-80" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], + "apac-aus-ism-2026-march": [ "ISM-0120", "ISM-1091" ], @@ -219,6 +241,9 @@ "americas-can-osfi-b13-2022": [ "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.14.06.A.01", "03.14.06.A.02", diff --git a/docs/api/controls/MON-11.json b/docs/api/controls/MON-11.json index a34ccf65..5233cb25 100644 --- a/docs/api/controls/MON-11.json +++ b/docs/api/controls/MON-11.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of non-public information.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of non-public information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -125,7 +126,13 @@ "general-nist-800-171-r3": [ "03.01.22.b" ], - "apac-nzl-hisf-mlhsp-2023": [ + "general-nist-800-171a-r3": [ + "A.03.01.22.b[01]" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP63", "HML69" ], diff --git a/docs/api/controls/MON-12.json b/docs/api/controls/MON-12.json index 3c3278e5..c0fcb5b3 100644 --- a/docs/api/controls/MON-12.json +++ b/docs/api/controls/MON-12.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -111,10 +112,6 @@ ], "general-nist-800-161-r1-level-3": [ "AU-14" - ], - "emea-isr-cmo-1-0": [ - "21.10", - "21.18" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-13.json b/docs/api/controls/MON-13.json index fdcc47d8..fdf13047 100644 --- a/docs/api/controls/MON-13.json +++ b/docs/api/controls/MON-13.json @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -78,9 +79,6 @@ ], "general-nist-800-82-r3": [ "AU-05(05)" - ], - "emea-isr-cmo-1-0": [ - "21.15" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-14.1.json b/docs/api/controls/MON-14.1.json index ffd6c913..4194f9e8 100644 --- a/docs/api/controls/MON-14.1.json +++ b/docs/api/controls/MON-14.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to share event logs with third-party organizations based on specific cross-organizational sharing agreements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-14.json b/docs/api/controls/MON-14.json index 3489e585..4d186c48 100644 --- a/docs/api/controls/MON-14.json +++ b/docs/api/controls/MON-14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to coordinate sanitized event logs among external organizations to identify anomalous events when event logs are shared across organizational boundaries, without giving away sensitive or critical business data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-15.json b/docs/api/controls/MON-15.json index 31b0c180..969d256d 100644 --- a/docs/api/controls/MON-15.json +++ b/docs/api/controls/MON-15.json @@ -62,11 +62,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -93,9 +94,6 @@ ], "general-pci-dss-4-0-1-saq-d-service-provider": [ "11.5.1.1" - ], - "emea-isr-cmo-1-0": [ - "21.10" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-16.1.json b/docs/api/controls/MON-16.1.json index 11f95682..6ecb2001 100644 --- a/docs/api/controls/MON-16.1.json +++ b/docs/api/controls/MON-16.1.json @@ -109,7 +109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -125,14 +126,8 @@ "general-sparta": [ "CM0052" ], - "emea-isr-cmo-1-0": [ - "21.10" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625" - ], - "apac-sgp-mas-trm-2021": [ - "3.5.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-16.2.json b/docs/api/controls/MON-16.2.json index 09d9c758..387cff67 100644 --- a/docs/api/controls/MON-16.2.json +++ b/docs/api/controls/MON-16.2.json @@ -109,7 +109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -121,9 +122,6 @@ ], "general-shared-assessments-sig-2025": [ "J.5" - ], - "emea-isr-cmo-1-0": [ - "21.10" ] } } \ No newline at end of file diff --git a/docs/api/controls/MON-16.3.json b/docs/api/controls/MON-16.3.json index 2d58d0d4..27463579 100644 --- a/docs/api/controls/MON-16.3.json +++ b/docs/api/controls/MON-16.3.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for unauthorized activities, accounts, connections, devices and software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -109,7 +109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -134,13 +135,6 @@ "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.4" ], - "emea-isr-cmo-1-0": [ - "21.10" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11", - "2-3-1-12" - ], "emea-gbr-def-stan-05-138-2024": [ "4106" ], diff --git a/docs/api/controls/MON-16.4.json b/docs/api/controls/MON-16.4.json index 88336c1e..4ee3ae1b 100644 --- a/docs/api/controls/MON-16.4.json +++ b/docs/api/controls/MON-16.4.json @@ -107,18 +107,23 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-nist-csf-2-0": [ "DE.CM-06" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(c)", + "3.4.2.31(d)" + ], "emea-eu-nis2-annex-2024": [ "3.2.3(b)", "11.2.2(f)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1650" ] } diff --git a/docs/api/controls/MON-16.json b/docs/api/controls/MON-16.json index 7f590d7e..38c5961f 100644 --- a/docs/api/controls/MON-16.json +++ b/docs/api/controls/MON-16.json @@ -111,7 +111,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -190,10 +191,20 @@ "03.14.06.c" ], "general-nist-800-171a-r3": [ + "A.03.01.01.e", + "A.03.03.05.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", "A.03.14.06.b" ], - "general-nist-800-172": [ - "3.14.2e" + "general-nist-800-172-r3": [ + "03.01.08E", + "03.06.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.a", + "DS-A.03.06.03E" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -265,12 +276,12 @@ "IR-04(13)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "AC-2(CE-12)", @@ -288,10 +299,7 @@ "AC-02 (12)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" ], "emea-eu-dora-2023": [ "Article 10.1" @@ -302,30 +310,15 @@ "emea-deu-bsrit-2017": [ "5.5" ], - "emea-isr-cmo-1-0": [ - "4.7", - "21.10", - "21.20" - ], "emea-sau-otcc-1-2022": [ "2-3-1-12" ], "emea-sau-sacs-002-2022": [ - "TPC-80" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1" - ], - "emea-esp-decree-311-2022": [ - "10.1" + "VII.B.TPC-80" ], "emea-gbr-caf-4-0": [ "C1.f" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "emea-gbr-def-stan-05-138-2024": [ "3200", "3202", @@ -345,20 +338,28 @@ "3202", "3203" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1660" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS19" + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.57", + "11.9" ], "apac-sgp-mas-trm-2021": [ - "9.2.2", "11.5.5", + "12.2.3", "12.2.4" ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP4" + ], "americas-can-osfi-b13-2022": [ "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.E", "03.03.05.A", diff --git a/docs/api/controls/MON-17.1.json b/docs/api/controls/MON-17.1.json index 3342c3ce..ac879c54 100644 --- a/docs/api/controls/MON-17.1.json +++ b/docs/api/controls/MON-17.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to make event log review processes more efficient and effective by developing and maintaining an incident response escalation matrix.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-17.json b/docs/api/controls/MON-17.json index c470cb2e..d4396725 100644 --- a/docs/api/controls/MON-17.json +++ b/docs/api/controls/MON-17.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to ensure event log reviews include analysis and triage practices that integrate with the organization's established incident response processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-18.json b/docs/api/controls/MON-18.json index 43076469..73fabd7c 100644 --- a/docs/api/controls/MON-18.json +++ b/docs/api/controls/MON-18.json @@ -2,8 +2,8 @@ "control_id": "MON-18", "title": "File Activity Monitoring (FAM)", "family": "MON", - "description": "Automated mechanisms exist to monitor sensitive/regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories.", - "scf_question": "Does the organization use automated tools to monitor sensitive/regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories?", + "description": "Automated mechanisms exist to monitor sensitive and/or regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories.", + "scf_question": "Does the organization use automated mechanisms to monitor sensitive and/or regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { diff --git a/docs/api/controls/MON-19.json b/docs/api/controls/MON-19.json index cf39a3e7..aff214e1 100644 --- a/docs/api/controls/MON-19.json +++ b/docs/api/controls/MON-19.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to produce event logs on hardware-enforced, write-once media (e.g., Write Once Read Many (WORM) technologies).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -44,9 +44,9 @@ "NT-7", "MT-2", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (IEC 62443-4-2)", "family_name": "Continuous Monitoring", "crosswalks": { "general-iec-62443-3-3-2013": [ diff --git a/docs/api/controls/NET-01.1.json b/docs/api/controls/NET-01.1.json index e56a135c..1ec4da7d 100644 --- a/docs/api/controls/NET-01.1.json +++ b/docs/api/controls/NET-01.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to treat all users and devices as potential threats and prevent access to data and resources until the users can be properly authenticated and their access authorized.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -126,7 +127,7 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "3.0" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0665" ], "apac-ind-sebi-2024": [ @@ -137,7 +138,9 @@ ], "apac-nzl-ism-3-9": [ "2.3.26.C.01", - "2.3.26.C.02" + "2.3.26.C.02", + "16.1.25.C.01", + "16.5.12.C.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-01.json b/docs/api/controls/NET-01.json index dccd04fe..c3448994 100644 --- a/docs/api/controls/NET-01.json +++ b/docs/api/controls/NET-01.json @@ -117,7 +117,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -134,7 +135,7 @@ "CC6.6-POF4" ], "general-cis-csc-8-1": [ - "12.0", + "12", "12.1", "12.2", "12.3", @@ -271,10 +272,14 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.18.a", "03.13.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[03]", + "A.03.13.01.a[02]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -350,12 +355,12 @@ "SC-01" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "usa-federal-irs-1075-2021": [ "3.3.6", @@ -404,23 +409,9 @@ "6.8.3", "6.9.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-c5-2020": [ - "PSS-10" - ], - "emea-isr-cmo-1-0": [ - "9.1" - ], "emea-sau-cscc-1-2019": [ "2-3-1-5", - "2-4", - "2-4-1-5" + "2-4-1" ], "emea-sau-cgiot-2024": [ "2-3-1", @@ -429,49 +420,25 @@ "2-4-5" ], "emea-sau-ecc-1-2018": [ - "2-4-4", "2-5-1", - "2-5-2", - "2-5-4" + "2-5-2" ], "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-1", - "2-3-1-1", - "2-4", "2-4-1", - "2-4-2", - "2-5-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-78" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 23" + "2-4-2" ], "emea-esp-decree-311-2022": [ - "23" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.1 [MP.COM.1]", - "8.4.2 [MP.COM.2]" + "Article 12(6)(k)", + "Article 18" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "1" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3", + "mp.s.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0521", "ISM-0629", "ISM-1186", @@ -501,7 +468,12 @@ "13.1.1.9", "13.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.37", + "12.3", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP49", "HHSP54", "HML49", @@ -540,28 +512,17 @@ "4.4" ], "apac-sgp-mas-trm-2021": [ - "11.2.1", - "11.2.2", - "11.2.3", - "11.2.4", - "11.2.5", - "11.2.6", - "11.2.7", - "11.2.8" - ], - "americas-bmu-mba-coc-2020": [ - "6.18" - ], - "amaericas-can-osfi-self-assessment": [ - "4.10", - "4.15" + "11.2.1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", - "03.01.16.B", "03.01.18.A", - "03.13.01.A" + "03.13.01.A", + "03.14.08.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-02.1.json b/docs/api/controls/NET-02.1.json index 1877ccd7..f9ca738b 100644 --- a/docs/api/controls/NET-02.1.json +++ b/docs/api/controls/NET-02.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Boundary protection technologies minimize the effect of Denial of Service (DoS) attacks against business-critical services.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically protect against or limit the effects of denial of service attacks.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically protect against or limit the effects of denial of service attacks. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -57,7 +57,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -89,7 +90,7 @@ "CR 7.1", "CR 7.1(1)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1496.003" ], "general-nist-800-53-r4": [ @@ -116,6 +117,16 @@ "general-nist-800-82-r3-high": [ "SC-05" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.a", + "A.03.13.12E.ODP[01]", + "A.03.13.12E.ODP[02]", + "DS-A.03.13.12E.b", + "A.03.13.12E.ODP[03]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.RE.DDSPR" ], @@ -150,40 +161,24 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-05" ], - "emea-isr-cmo-1-0": [ - "9.3" + "emea-deu-c5-2020": [ + "KOS-01" ], "emea-sau-cscc-1-2019": [ "2-4-1-8" ], - "emea-sau-sacs-002-2022": [ - "TPC-92" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.3 [MP.S.3]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1019", "ISM-1431", "ISM-1436", "ISM-1805" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS17" - ], "apac-nzl-ism-3-9": [ "18.3.18.C.01", "18.3.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "11.2.7" - ], "americas-bmu-mba-coc-2020": [ "6.19" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-02.2.json b/docs/api/controls/NET-02.2.json index ad3d17c4..9671c122 100644 --- a/docs/api/controls/NET-02.2.json +++ b/docs/api/controls/NET-02.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel implement and manage a secure guest network.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and manage a secure guest network.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and manage a secure guest network. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -171,10 +172,7 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(x)" ], - "emea-isr-cmo-1-0": [ - "9.18" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0536" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/NET-02.3.json b/docs/api/controls/NET-02.3.json index 3090abb6..56b2c7e0 100644 --- a/docs/api/controls/NET-02.3.json +++ b/docs/api/controls/NET-02.3.json @@ -101,11 +101,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1021.003", "T1021.006", @@ -143,9 +144,6 @@ "general-nist-800-160-vol-2-r1": [ "SC-46" ], - "general-nist-800-172": [ - "3.1.3e" - ], "general-nist-800-207": [ "NIST Tenet 4" ], @@ -158,10 +156,13 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.5" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-2" + "emea-deu-c5-2020": [ + "KOS-03" + ], + "emea-sau-cscc-1-2019": [ + "2-6-1-5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0597", "ISM-0610", "ISM-0626", @@ -181,7 +182,13 @@ "19.2.18.C.01", "19.2.19.C.01", "19.2.19.C.02", - "19.2.20.C.01" + "19.2.20.C.01", + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.14.C.04", + "20.3.9.C.02", + "20.3.9.C.04", + "21.1.8.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-02.json b/docs/api/controls/NET-02.json index b23614a0..af453c50 100644 --- a/docs/api/controls/NET-02.json +++ b/docs/api/controls/NET-02.json @@ -20,9 +20,9 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity architects maintain a segmented development network to ensure a secure development environment.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security functions as a layered structure that minimizes interactions between layers of the design and avoids any dependence by lower layers on the functionality or correctness of higher layers.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security functions as a layered structure that minimizes interactions between layers of the design and avoids any dependence by lower layers on the functionality or correctness of higher layers. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -142,8 +143,8 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.13.01.b" ], "general-nist-csf-2-0": [ "PR.IR-01" @@ -180,31 +181,31 @@ "7123(c)(10)" ], "emea-deu-c5-2020": [ - "PSS-10" - ], - "emea-isr-cmo-1-0": [ - "9.17" + "KOS-01", + "KOS-03-DOAR" ], "emea-sau-cscc-1-2019": [ "2-4-1-5" ], "emea-sau-ecc-1-2018": [ - "2-5-3-1" + "2-5-3-8" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-1" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.4" + "apac-mys-bnm-rmit-2025": [ + "12.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.11", - "4.12", - "4.15" + "americas-bmu-mba-coc-2020": [ + "6.18" ], "americas-can-osfi-b13-2022": [ "3.2.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.13.01.B" ] diff --git a/docs/api/controls/NET-03.1.json b/docs/api/controls/NET-03.1.json index 36e82cd0..f0a7d3c6 100644 --- a/docs/api/controls/NET-03.1.json +++ b/docs/api/controls/NET-03.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to limit the number of concurrent external network connections to its Technology Assets, Applications and/or Services (TAAS).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to limit the number of concurrent external network connections to its Technology Assets, Applications and/or Services (TAAS). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -202,15 +203,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (03)" ], - "emea-deu-c5-2020": [ - "COS-04" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.4" ], - "emea-isr-cmo-1-0": [ - "9.10", - "9.11", - "16.4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1314" ] } diff --git a/docs/api/controls/NET-03.2.json b/docs/api/controls/NET-03.2.json index 25107a47..6c1558c3 100644 --- a/docs/api/controls/NET-03.2.json +++ b/docs/api/controls/NET-03.2.json @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -172,13 +173,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (04)" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0546", "ISM-1562" ] diff --git a/docs/api/controls/NET-03.3.json b/docs/api/controls/NET-03.3.json index 9fee977a..b36ec5f2 100644 --- a/docs/api/controls/NET-03.3.json +++ b/docs/api/controls/NET-03.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent the public disclosure of internal network information.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent the public disclosure of internal network information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -56,7 +56,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -66,7 +67,7 @@ "general-iso-27018-2025": [ "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1590.001", "T1590.003", "T1590.004", @@ -102,9 +103,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.4.5" ], - "emea-isr-cmo-1-0": [ - "9.19" - ], "apac-jpn-ismap": [ "14.1.1.23" ] diff --git a/docs/api/controls/NET-03.4.json b/docs/api/controls/NET-03.4.json index ba8b5d21..1bb261a5 100644 --- a/docs/api/controls/NET-03.4.json +++ b/docs/api/controls/NET-03.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to apply network-based processing rules to data elements of Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-03.5.json b/docs/api/controls/NET-03.5.json index 5accf80d..11f46b1a 100644 --- a/docs/api/controls/NET-03.5.json +++ b/docs/api/controls/NET-03.5.json @@ -2,8 +2,8 @@ "control_id": "NET-03.5", "title": "Prevent Unauthorized Exfiltration", "family": "NET", - "description": "Automated mechanisms exist to prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces.", - "scf_question": "Does the organization use automated mechanisms to prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces?", + "description": "Automated mechanisms exist to prevent the unauthorized exfiltration of sensitive and/or regulated data across managed interfaces.", + "scf_question": "Does the organization use automated mechanisms to prevent the unauthorized exfiltration of sensitive and/or regulated data across managed interfaces?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -66,7 +66,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-03.6.json b/docs/api/controls/NET-03.6.json index 0e2e6317..1b0e898f 100644 --- a/docs/api/controls/NET-03.6.json +++ b/docs/api/controls/NET-03.6.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically dynamically isolate (e.g., sandbox) untrusted components during runtime, where the component is isolated in a fault-contained environment but it can still collaborate with the application.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically dynamically isolate (e.g., sandbox) untrusted components during runtime, where the component is isolated in a fault-contained environment but it can still collaborate with the application. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63,7 +63,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -91,11 +92,8 @@ "usa-federal-gsa-fedramp-5-high": [ "SC-07(20)" ], - "emea-sau-sacs-002-2022": [ - "TPC-38" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "apac-sgp-mas-trm-2021": [ + "11.5.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-03.7.json b/docs/api/controls/NET-03.7.json index 3184b9e1..64980c55 100644 --- a/docs/api/controls/NET-03.7.json +++ b/docs/api/controls/NET-03.7.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ boundary protections to isolate Technology Assets, Applications and/or Services (TAAS) that support critical missions and/or business functions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ boundary protections to isolate Technology Assets, Applications and/or Services (TAAS) that support critical missions and/or business functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -119,8 +120,11 @@ "general-nist-800-160-vol-2-r1": [ "SC-07(21)" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-172-r3": [ + "03.13.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.04E.ODP[01]" ], "general-pci-dss-4-0-1": [ "1.3.3" @@ -152,20 +156,14 @@ "emea-sau-ecc-1-2018": [ "5-1-3-4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP43", "HHSP55", "HML43", "HML55" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS16" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP47" - ], - "apac-sgp-mas-trm-2021": [ - "11.2.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-03.8.json b/docs/api/controls/NET-03.8.json index 5b07c42c..56d1b948 100644 --- a/docs/api/controls/NET-03.8.json +++ b/docs/api/controls/NET-03.8.json @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -116,6 +117,17 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], + "general-nist-800-172-r3": [ + "03.13.10E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.10E", + "DS-A.03.13.15E" + ], "general-pci-dss-4-0-1": [ "1.4", "1.4.1" @@ -141,12 +153,8 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-07(29)" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "emea-deu-c5-2020": [ + "KOS-02" ], "apac-nzl-ism-3-9": [ "14.1.11.C.01" diff --git a/docs/api/controls/NET-03.json b/docs/api/controls/NET-03.json index 28ddd44e..f2c2cafd 100644 --- a/docs/api/controls/NET-03.json +++ b/docs/api/controls/NET-03.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network activity monitoring and control communications at the external network boundary and at key internal boundaries within the network.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor and control communications at the external network boundary and at key internal boundaries within the network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -111,7 +111,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -179,7 +180,7 @@ "8.20", "8.21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -392,6 +393,7 @@ ], "general-nist-800-171-r3": [ "03.01.12.a", + "03.01.18.a", "03.13.01.a", "03.13.01.b", "03.13.01.c" @@ -410,8 +412,17 @@ "A.03.01.18.a[03]", "A.03.13.01.a[02]", "A.03.13.01.a[04]", + "A.03.13.01.b", "A.03.13.01.c" ], + "general-nist-800-172-r3": [ + "03.01.12E", + "03.13.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.12E.ODP[01]", + "DS-A.03.13.04E" + ], "general-pci-dss-4-0-1": [ "1.3.3", "1.4", @@ -529,27 +540,31 @@ "SC-07" ], "emea-deu-c5-2020": [ - "COS-04", - "PSS-10" + "KOS-01", + "KOS-02", + "KOS-03" ], - "emea-isr-cmo-1-0": [ - "9.3", - "9.18", - "9.23", - "10.9", - "11.8", - "16.4" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.3" + ], + "emea-sau-cscc-1-2019": [ + "2-4-1-5" ], "emea-sau-cgiot-2024": [ "2-4-5" ], "emea-sau-otcc-1-2022": [ - "2-3-1-1", - "2-4-1-2", - "2-4-1-6" + "2-3-1-13", + "2-4-1-12" ], "emea-sau-sacs-002-2022": [ - "TPC-76" + "VII.B.TPC-76" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3" ], "emea-gbr-cyber-essentials-requirements-3-3": [ "1" @@ -566,7 +581,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2427" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0611", "ISM-0612", "ISM-0613", @@ -668,17 +683,20 @@ "19.5.28.C.05", "19.5.28.C.06", "19.5.28.C.07", - "19.5.29.C.01" + "19.5.29.C.01", + "21.3.5.C.01", + "21.3.5.C.02", + "21.3.6.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.4" ], "apac-sgp-mas-trm-2021": [ - "11.2.5", - "11.2.6" + "11.2.1" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", + "03.01.18.A", "03.13.01.A", "03.13.01.B", "03.13.01.C" diff --git a/docs/api/controls/NET-04.1.json b/docs/api/controls/NET-04.1.json index 1e1a47b5..f30947d2 100644 --- a/docs/api/controls/NET-04.1.json +++ b/docs/api/controls/NET-04.1.json @@ -21,11 +21,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure firewall and router configurations to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure firewall and router configurations to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -200,6 +201,7 @@ "3.13.6[b]" ], "general-nist-800-171a-r3": [ + "A.03.13.01.a[02]", "A.03.13.06[01]", "A.03.13.06[02]" ], @@ -291,9 +293,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (05)" ], - "emea-isr-cmo-1-0": [ - "9.12", - "12.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.4" ], "emea-sau-cscc-1-2019": [ "2-4-1-4", @@ -301,13 +302,10 @@ "2-4-1-7", "2-4-1-9" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-6", - "2-4-1-8", - "2-4-1-14" - ], - "emea-sau-sacs-002-2022": [ - "TPC-36" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2507" @@ -321,11 +319,17 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2507" ], + "apac-aus-ism-2026-march": [ + "ISM-2068" + ], "apac-nzl-ism-3-9": [ "18.1.13.C.01", "18.1.13.C.02", "18.1.14.C.01" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.4" + ], "americas-can-itsp-10-171-2025": [ "03.13.01.A", "03.13.06" diff --git a/docs/api/controls/NET-04.10.json b/docs/api/controls/NET-04.10.json index 8d9b04c3..3812b607 100644 --- a/docs/api/controls/NET-04.10.json +++ b/docs/api/controls/NET-04.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically implement security policy filters requiring fully enumerated formats that restrict data structure and content, when transferring information between different security domains.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -68,7 +68,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -80,6 +81,12 @@ ], "general-nist-800-82-r3": [ "AC-04(15)" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.a" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-04.11.json b/docs/api/controls/NET-04.11.json index e7140228..8491d0b8 100644 --- a/docs/api/controls/NET-04.11.json +++ b/docs/api/controls/NET-04.11.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically examine information for the presence of unsanctioned information and prohibits the transfer of such information, when transferring information between different security domains.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -69,7 +69,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-04.12.json b/docs/api/controls/NET-04.12.json index 7667ae5b..dbb36c18 100644 --- a/docs/api/controls/NET-04.12.json +++ b/docs/api/controls/NET-04.12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically uniquely identify and authenticate source and destination points for information transfer.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53,7 +53,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-04.13.json b/docs/api/controls/NET-04.13.json index faa26146..9bea3d95 100644 --- a/docs/api/controls/NET-04.13.json +++ b/docs/api/controls/NET-04.13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically apply cybersecurity and/or data protection filters on metadata.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -53,7 +53,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-04.14.json b/docs/api/controls/NET-04.14.json index 3a8ac683..38af782f 100644 --- a/docs/api/controls/NET-04.14.json +++ b/docs/api/controls/NET-04.14.json @@ -3,7 +3,7 @@ "title": "Application Proxy", "family": "NET", "description": "Mechanisms exist to terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network.", - "scf_question": "Does the organization maintain visibility and control over application traffic, regardless of the user’s location or the security posture of the surrounding network?", + "scf_question": "Does the organization terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": {} diff --git a/docs/api/controls/NET-04.2.json b/docs/api/controls/NET-04.2.json index 732261c9..c0f83a67 100644 --- a/docs/api/controls/NET-04.2.json +++ b/docs/api/controls/NET-04.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to associate security attributes with information, source and destination objects to enforce defined information flow control configurations as a basis for flow control decisions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to associate security attributes with information, source and destination objects to enforce defined information flow control configurations as a basis for flow control decisions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -75,6 +76,16 @@ ], "general-nist-800-82-r3": [ "AC-04(01)" + ], + "general-nist-800-172-r3": [ + "03.01.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.10E", + "A.03.01.10E.ODP[01]", + "A.03.01.10E.ODP[02]", + "A.03.01.10E.ODP[03]", + "A.03.01.10E.ODP[04]" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-04.3.json b/docs/api/controls/NET-04.3.json index 71ed80d7..59d63670 100644 --- a/docs/api/controls/NET-04.3.json +++ b/docs/api/controls/NET-04.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent encrypted data from bypassing content-checking mechanisms.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent encrypted data from bypassing content-checking mechanisms. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -84,9 +85,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "AC-04(04)" - ], - "emea-isr-cmo-1-0": [ - "9.16" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-04.4.json b/docs/api/controls/NET-04.4.json index b5be5517..e3c036c4 100644 --- a/docs/api/controls/NET-04.4.json +++ b/docs/api/controls/NET-04.4.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce limitations on embedding data within other data types.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce limitations on embedding data within other data types. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -75,9 +76,6 @@ ], "general-nist-800-82-r3": [ "AC-04(05)" - ], - "emea-isr-cmo-1-0": [ - "9.16" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-04.5.json b/docs/api/controls/NET-04.5.json index d7d0d8ed..b63f942e 100644 --- a/docs/api/controls/NET-04.5.json +++ b/docs/api/controls/NET-04.5.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce information flow controls based on metadata.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce information flow controls based on metadata. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -89,6 +90,12 @@ "general-nist-800-161-r1-level-3": [ "AC-4(6)" ], + "general-nist-800-172-r3": [ + "03.01.13E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.13E.ODP[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "4.4" ], diff --git a/docs/api/controls/NET-04.6.json b/docs/api/controls/NET-04.6.json index c512e320..4b8fe47e 100644 --- a/docs/api/controls/NET-04.6.json +++ b/docs/api/controls/NET-04.6.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -128,18 +129,8 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.2.7" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.24" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-6", "2-4-1-2" - ], - "apac-sgp-mas-trm-2021": [ - "11.2.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-04.7.json b/docs/api/controls/NET-04.7.json index 6910d3db..ae98b84e 100644 --- a/docs/api/controls/NET-04.7.json +++ b/docs/api/controls/NET-04.7.json @@ -3,7 +3,7 @@ "title": "Policy Decision Point (PDP)", "family": "NET", "description": "Automated mechanisms exist to evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions.", - "scf_question": "Does the organization evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions?", + "scf_question": "Does the organization use automated mechanisms to evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -66,7 +66,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -88,6 +89,18 @@ "general-nist-800-160-vol-2-r1": [ "AC-04(08)" ], + "general-nist-800-172-r3": [ + "03.01.10E", + "03.01.13E", + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.10E.ODP[05]", + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "A.03.01.14E.ODP[01]", + "DS-A.03.01.14E.b" + ], "general-nist-800-207": [ "NIST Tenet 4" ], diff --git a/docs/api/controls/NET-04.8.json b/docs/api/controls/NET-04.8.json index 81cde583..20a6300e 100644 --- a/docs/api/controls/NET-04.8.json +++ b/docs/api/controls/NET-04.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically utilize data type identifiers to validate data essential for information flow decisions when transferring information between different security domains.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62,7 +62,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -77,6 +78,17 @@ ], "general-nist-800-160-vol-2-r1": [ "AC-04(12)" + ], + "general-nist-800-172-r3": [ + "03.01.13E", + "03.01.14E", + "03.01.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "DS-A.03.01.15E", + "A.03.01.15E.ODP[01]" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-04.9.json b/docs/api/controls/NET-04.9.json index ec702d80..cc0fec89 100644 --- a/docs/api/controls/NET-04.9.json +++ b/docs/api/controls/NET-04.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms, when transferring information between different security domains.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60,7 +60,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -72,6 +73,12 @@ ], "general-nist-800-82-r3": [ "AC-04(13)" + ], + "general-nist-800-172-r3": [ + "03.01.16E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.16E.ODP[01]" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-04.json b/docs/api/controls/NET-04.json index 468ead5e..21016950 100644 --- a/docs/api/controls/NET-04.json +++ b/docs/api/controls/NET-04.json @@ -22,11 +22,11 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and govern Access Control Lists (ACLs) to provide data flow enforcement that explicitly restrict network traffic to only what is authorized.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -175,7 +176,7 @@ "8.3", "8.20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -386,10 +387,9 @@ "3.1.3[e]" ], "general-nist-800-171a-r3": [ - "A.03.01.03[02]" - ], - "general-nist-800-172": [ - "3.1.3e" + "A.03.01.03[02]", + "A.03.13.01.a[02]", + "A.03.13.01.c" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -484,15 +484,6 @@ "6.7.2(f)", "6.7.2(g)" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.12", - "9.16", - "10.9", - "12.11" - ], "emea-sau-cscc-1-2019": [ "2-4-1-4", "2-4-1-6", @@ -504,11 +495,14 @@ ], "emea-sau-otcc-1-2022": [ "2-4-1-6", - "2-4-1-7", "2-4-1-8", - "2-4-1-10", - "2-4-1-14", - "2-4-1-16" + "2-4-1-9", + "2-4-1-10" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2316", @@ -526,7 +520,7 @@ "2316", "2428" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0643", "ISM-0645", "ISM-1157", @@ -538,6 +532,9 @@ "18.1.13.C.02", "18.1.14.C.01" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.03", "03.13.01.A", diff --git a/docs/api/controls/NET-05.1.json b/docs/api/controls/NET-05.1.json index 24d3db3d..d7989868 100644 --- a/docs/api/controls/NET-05.1.json +++ b/docs/api/controls/NET-05.1.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the direct connection of a sensitive system to an external network without the use of an organization-defined boundary protection device.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the direct connection of a sensitive system to an external network without the use of an organization-defined boundary protection device. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96,7 +96,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -133,19 +134,8 @@ "usa-federal-cms-marse-2-0": [ "CA-3(5)" ], - "emea-isr-cmo-1-0": [ - "9.11", - "12.8", - "16.4" - ], - "emea-sau-ecc-1-2018": [ - "5-1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-13" - ], "emea-sau-sacs-002-2022": [ - "TPC-36" + "VII.B.TPC-36" ], "apac-nzl-ism-3-9": [ "14.1.13.C.01", diff --git a/docs/api/controls/NET-05.2.json b/docs/api/controls/NET-05.2.json index 98911b3a..198b444c 100644 --- a/docs/api/controls/NET-05.2.json +++ b/docs/api/controls/NET-05.2.json @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -143,10 +144,18 @@ ], "general-nist-800-171-r3": [ "03.01.03", - "03.12.05.a", "03.12.05.b", "03.12.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], + "general-nist-800-172-r3": [ + "03.12.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.04E.c" + ], "general-shared-assessments-sig-2025": [ "G.3" ], @@ -185,18 +194,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-09" ], - "emea-sau-ecc-1-2018": [ - "5-1-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-13" - ], "apac-jpn-ismap": [ "13.1.1.10" ], "americas-can-itsp-10-171-2025": [ "03.01.03", - "03.12.05.A", "03.12.05.B", "03.12.05.C" ] diff --git a/docs/api/controls/NET-05.json b/docs/api/controls/NET-05.json index 11586afe..88581bcb 100644 --- a/docs/api/controls/NET-05.json +++ b/docs/api/controls/NET-05.json @@ -96,9 +96,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Network Security", "crosswalks": { "general-govramp": [ @@ -119,7 +119,7 @@ "general-iec-62443-2-1-2024": [ "NET 1.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1041", "T1048", @@ -178,6 +178,7 @@ ], "general-nist-800-171a-r3": [ "A.03.01.03[02]", + "A.03.01.20.c.02", "A.03.12.05.ODP[01]", "A.03.12.05.ODP[02]", "A.03.12.05.a[01]", @@ -188,6 +189,18 @@ "A.03.12.05.c[01]", "A.03.12.05.c[02]" ], + "general-nist-800-172-r3": [ + "03.12.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.04E.a", + "A.03.12.04E.ODP[01]", + "DS-A.03.12.04E.b[01]", + "DS-A.03.12.04E.b[02]", + "DS-A.03.12.04E.b[03]", + "A.03.12.04E.ODP[02]", + "DS-A.03.12.04E.d" + ], "general-swift-cscf-2025": [ "2.4" ], @@ -233,11 +246,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-03" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "16.4" + "emea-esp-decree-311-2022": [ + "Article 23" ], "americas-can-itsp-10-171-2025": [ "03.01.03", diff --git a/docs/api/controls/NET-06.1.json b/docs/api/controls/NET-06.1.json index 75779980..491626ab 100644 --- a/docs/api/controls/NET-06.1.json +++ b/docs/api/controls/NET-06.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Processing and storage of service location, including a managed security zone to house cybersecurity and data protection tools.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security management subnets to isolate security tools and support components from other internal system components by implementing separate subnetworks with managed interfaces to other components of the system.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security management subnets to isolate security tools and support components from other internal system components by implementing separate subnetworks with managed interfaces to other components of the system. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -162,6 +163,14 @@ "general-nist-800-161-r1-level-3": [ "SC-7(13)" ], + "general-nist-800-172-r3": [ + "03.13.09E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.09E", + "DS-A.03.13.15E" + ], "general-swift-cscf-2025": [ "1.1" ], @@ -184,15 +193,11 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-04" - ], - "emea-isr-cmo-1-0": [ - "9.2", - "12.4", - "12.5" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "mp.com.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1750" ], diff --git a/docs/api/controls/NET-06.2.json b/docs/api/controls/NET-06.2.json index 73582053..bf723fd7 100644 --- a/docs/api/controls/NET-06.2.json +++ b/docs/api/controls/NET-06.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,11 +87,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "KOS-05-DOAR" + ], + "apac-aus-ism-2026-march": [ "ISM-0529", "ISM-0530", "ISM-0535", @@ -102,13 +106,9 @@ "13.1.4.P" ], "apac-nzl-ism-3-9": [ - "22.3.9.C.01", - "22.3.9.C.02", - "22.3.9.C.03", - "22.3.9.C.04", - "22.3.10.C.01", - "22.3.11.C.01", - "22.3.11.C.02" + "20.3.9.C.02", + "20.3.9.C.03", + "20.3.9.C.04" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-06.3.json b/docs/api/controls/NET-06.3.json index b3bfb4d9..865e5031 100644 --- a/docs/api/controls/NET-06.3.json +++ b/docs/api/controls/NET-06.3.json @@ -2,8 +2,8 @@ "control_id": "NET-06.3", "title": "Sensitive / Regulated Data Enclave (Secure Zone)", "family": "NET", - "description": "Mechanisms exist to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones).", - "scf_question": "Does the organization implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones)?", + "description": "Mechanisms exist to implement segmentation controls to restrict inbound and outbound connectivity for sensitive and/or regulated data enclaves (secure zones).", + "scf_question": "Does the organization implement segmentation controls to restrict inbound and outbound connectivity for sensitive and/or regulated data enclaves (secure zones)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -28,7 +28,7 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "medium": "∙ Dedicated network segment for sensitive/regulated data systems", + "medium": "∙ Dedicated network segment for sensitive and/or regulated data systems", "large": "∙ Secure enclave/zone for sensitive data\n∙ Enhanced controls within the zone", "enterprise": "∙ Enterprise secure data enclave with enhanced controls\n∙ Data loss prevention at enclave boundary\n∙ Microsegmentation" }, @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -95,6 +96,9 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], "general-swift-cscf-2025": [ "1.1", "1.4", @@ -105,22 +109,24 @@ "III.B.1.c" ], "emea-sau-cscc-1-2019": [ + "2-3-1-4", "2-4-1-6", "2-4-1-7" ], + "emea-sau-ecc-1-2018": [ + "5-1-3-1", + "5-1-3-2" + ], "emea-sau-otcc-1-2022": [ - "2-4-1-1" + "2-4-1-2", + "2-4-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "VII.B.TPC-38" ], "apac-jpn-ismap": [ "13.1.4.P" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS15" - ], "americas-can-itsp-10-171-2025": [ "03.13.01.B" ] diff --git a/docs/api/controls/NET-06.4.json b/docs/api/controls/NET-06.4.json index 3dc393cb..17efab7f 100644 --- a/docs/api/controls/NET-06.4.json +++ b/docs/api/controls/NET-06.4.json @@ -2,8 +2,8 @@ "control_id": "NET-06.4", "title": "Segregation From Enterprise Services", "family": "NET", - "description": "Mechanisms exist to isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", - "scf_question": "Does the organization isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments?", + "description": "Mechanisms exist to isolate sensitive and/or regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", + "scf_question": "Does the organization isolate sensitive and/or regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments?", "relative_weight": 4, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79,7 +79,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -90,9 +91,6 @@ "general-mpa-csbp-5-3-1": [ "TS-1.0" ], - "general-nist-800-172": [ - "3.14.3e" - ], "general-swift-cscf-2025": [ "1.1" ], @@ -103,16 +101,10 @@ "usa-federal-dow-cmmc-2-level-3": [ "SI.L3-3.14.3E" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-1", - "2-4-1-3", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13" + "emea-deu-c5-2020": [ + "KOS-05" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385" ] } diff --git a/docs/api/controls/NET-06.5.json b/docs/api/controls/NET-06.5.json index 8707d079..f99a7120 100644 --- a/docs/api/controls/NET-06.5.json +++ b/docs/api/controls/NET-06.5.json @@ -2,8 +2,8 @@ "control_id": "NET-06.5", "title": "Direct Internet Access Restrictions", "family": "NET", - "description": "Mechanisms exist to prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones).", - "scf_question": "Does the organization prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones)?", + "description": "Mechanisms exist to prohibit, or strictly-control, Internet access from sensitive and/or regulated data enclaves (secure zones).", + "scf_question": "Does the organization prohibit, or strictly-control, Internet access from sensitive and/or regulated data enclaves (secure zones)?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79,7 +79,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -107,16 +108,19 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "2.X" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(iv)", + "101.650(e)(3)(v)" + ], "emea-sau-cscc-1-2019": [ "2-4-1-3", "2-4-1-6" ], "emea-sau-otcc-1-2022": [ - "2-3-1-13", "2-4-1-7" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" + "apac-aus-ism-2026-march": [ + "ISM-1863" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-06.6.json b/docs/api/controls/NET-06.6.json index b0b0dbaa..3fa89f2d 100644 --- a/docs/api/controls/NET-06.6.json +++ b/docs/api/controls/NET-06.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -102,7 +103,7 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "3.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1269", "ISM-1270", "ISM-1271" diff --git a/docs/api/controls/NET-06.7.json b/docs/api/controls/NET-06.7.json index e7906572..ceabcea5 100644 --- a/docs/api/controls/NET-06.7.json +++ b/docs/api/controls/NET-06.7.json @@ -3,7 +3,7 @@ "title": "Software Defined Networking (SDN)", "family": "NET", "description": "Automated mechanisms exist to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", - "scf_question": "Does the organization enable dynamic, policy-driven network segmentation, access controls and traffic management?", + "scf_question": "Does the organization use automated mechanisms to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -20,7 +20,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-06.8.json b/docs/api/controls/NET-06.8.json new file mode 100644 index 00000000..803fc15f --- /dev/null +++ b/docs/api/controls/NET-06.8.json @@ -0,0 +1,100 @@ +{ + "control_id": "NET-06.8", + "title": "Network Device Plane Segmentation", + "family": "NET", + "description": "Automated mechanisms exist to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations.", + "scf_question": "Does the organization use automated mechanisms to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Automated mechanisms exist to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Management VLAN for network device administration\n∙ Out-of-band management interface for network devices", + "small": "∙ Management VLAN for network device administration\n∙ Restrict management access to jump server", + "medium": "∙ Dedicated out-of-band management network\n∙ Separate control plane and data plane configuration\n∙ Management VLAN with strict ACLs", + "large": "∙ Dedicated out-of-band management network (OOB)\n∙ Software-defined networking (SDN) with plane separation\n∙ Management plane protection with strict ACLs", + "enterprise": "∙ Dedicated OOB management network infrastructure\n∙ SDN platform with automated plane segmentation\n∙ Management plane micro-segmentation\n∙ Automated configuration enforcement" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Network Security", + "crosswalks": { + "emea-deu-c5-2020": [ + "KOS-04" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/NET-06.9.json b/docs/api/controls/NET-06.9.json new file mode 100644 index 00000000..7f074adf --- /dev/null +++ b/docs/api/controls/NET-06.9.json @@ -0,0 +1,116 @@ +{ + "control_id": "NET-06.9", + "title": "Separate Subnets To Isolate Functions", + "family": "NET", + "description": "Mechanisms exist to implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 7, + "conformity_cadence": "", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subnetting for basic functional isolation\n∙ VLAN segmentation", + "small": "∙ VLAN-based subnet isolation\n∙ Separate subnets for servers, workstations and IoT/OT", + "medium": "∙ Subnet-based micro-segmentation\n∙ Firewall rules between functional subnets\n∙ Network ACLs for inter-subnet traffic", + "large": "∙ Network micro-segmentation\n∙ Host-based firewall enforcement between subnets\n∙ Zero Trust Network Architecture (ZTNA) between segments", + "enterprise": "∙ Enterprise micro-segmentation platform (e.g., Illumio, Guardicore)\n∙ Software-Defined Networking (SDN) for subnet isolation\n∙ ZTNA platform for workload-to-workload access control\n∙ Automated subnet policy enforcement" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Network Security", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.13.09E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.09E.ODP[01]", + "DS-A.03.13.15E", + "A.03.13.15E.ODP[01]", + "A.03.13.15E.ODP[02]" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 7.5" + ], + "emea-sau-otcc-1-2022": [ + "2-4-1-1", + "2-4-1-5", + "2-4-1-6", + "2-4-1-9", + "2-4-1-10", + "2-4-1-12", + "2-4-1-13" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/NET-06.json b/docs/api/controls/NET-06.json index 4e9139e5..b9cc06f7 100644 --- a/docs/api/controls/NET-06.json +++ b/docs/api/controls/NET-06.json @@ -1,9 +1,9 @@ { "control_id": "NET-06", - "title": "Network Segmentation (macrosegementation)", + "title": "Network Segmentation (macrosegmentation)", "family": "NET", - "description": "Mechanisms exist to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.", - "scf_question": "Does the organization ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources?", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "scf_question": "Does the organization implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network segmentation exists to implement separate network addresses (e.g., different subnets) to connect TAASD in different security domains (e.g., sensitive/regulated data environments).\n▪ IT and/or cybersecurity architects maintain a segmented development network to ensure a secure development environment.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.\nMechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105,8 +105,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control (typo)\n- wordsmithed control", "family_name": "Network Security", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -199,8 +201,12 @@ "general-nist-800-171a-r3": [ "A.03.13.01.b" ], - "general-nist-800-172": [ - "3.14.3e" + "general-nist-800-172-r3": [ + "03.01.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.12E", + "A.03.01.12E.ODP[01]" ], "general-pci-dss-4-0-1": [ "1.2.1", @@ -344,12 +350,15 @@ "usa-federal-gsa-fedramp-5-high": [ "AC-04(21)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(h)(1)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)", "7123(c)(10)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(c)" + "3.4.4.36(c)" ], "emea-eu-nis2-annex-2024": [ "6.8.1", @@ -363,16 +372,8 @@ "6.8.2(h)" ], "emea-deu-c5-2020": [ - "COS-06" - ], - "emea-isr-cmo-1-0": [ - "9.2", - "9.18", - "9.19", - "10.8", - "12.4", - "12.5", - "12.11" + "RB-23-DOAR", + "KOS-05" ], "emea-sau-cscc-1-2019": [ "2-3-1-4", @@ -382,22 +383,24 @@ "2-4-4" ], "emea-sau-ecc-1-2018": [ + "2-5-3-1", + "2-5-3-2", "5-1-3-1", "5-1-3-2" ], "emea-sau-otcc-1-2022": [ "2-4-1-1", "2-4-1-2", - "2-4-1-3", - "2-4-1-5", - "2-4-1-10" + "2-4-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "VII.B.TPC-40" ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.4 [MP.COM.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "op.mon.1", + "mp.com.1", + "mp.com.4" ], "emea-gbr-def-stan-05-138-2024": [ "2508" @@ -411,7 +414,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2508" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1181", "ISM-1269", "ISM-1270", @@ -438,7 +441,10 @@ "13.1.3.12.P", "13.1.4.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.28" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP55", "HML55" ], @@ -446,7 +452,13 @@ "HSUP47" ], "apac-sgp-mas-trm-2021": [ - "11.2.6" + "11.2.2" + ], + "americas-arg-ppd-2018": [ + "E.1.2-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" ], "americas-can-osfi-b13-2022": [ "3.2.5" diff --git a/docs/api/controls/NET-07.json b/docs/api/controls/NET-07.json index 7ff1c8c4..6454e345 100644 --- a/docs/api/controls/NET-07.json +++ b/docs/api/controls/NET-07.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network connection terminations at the end of a session or after an entity-defined time period of inactivity.\n▪ SBC terminate remote sessions at the end of the session or after an entity-defined time period of inactivity.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate network connections at the end of a session or after an organization-defined time period of inactivity.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate network connections at the end of a session or after an organization-defined time period of inactivity. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -94,7 +95,7 @@ "general-iec-62443-4-2-2019": [ "CR 2.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -120,6 +121,7 @@ "3.13.9" ], "general-nist-800-171-r3": [ + "03.07.05.c", "03.13.09" ], "general-nist-800-171a": [ @@ -170,10 +172,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-10" ], - "emea-isr-cmo-1-0": [ - "4.16", - "9.4" - ], "emea-gbr-def-stan-05-138-2024": [ "2303", "2411" @@ -191,6 +189,7 @@ "2411" ], "americas-can-itsp-10-171-2025": [ + "03.07.05.C", "03.13.09" ] } diff --git a/docs/api/controls/NET-08.1.json b/docs/api/controls/NET-08.1.json index 83a5ab1f..f6216ada 100644 --- a/docs/api/controls/NET-08.1.json +++ b/docs/api/controls/NET-08.1.json @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -111,6 +112,9 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], "general-pci-dss-4-0-1": [ "1.2.1", "1.2.3", @@ -205,10 +209,11 @@ "emea-eu-nis2-annex-2024": [ "6.8.2(d)" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0637" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/NET-08.2.json b/docs/api/controls/NET-08.2.json index 0a49f091..976d96c4 100644 --- a/docs/api/controls/NET-08.2.json +++ b/docs/api/controls/NET-08.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel receive feeds from Wireless Intrusion Detection / Protection Systems (WIDS / WIPS) to identify rogue wireless devices and to detect attack attempts via wireless networks.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize Wireless Intrusion Detection / Protection Systems (WIDS / WIPS) on wireless network segments.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -87,9 +87,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Network Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -126,26 +126,6 @@ ], "general-shared-assessments-sig-2025": [ "N.7" - ], - "emea-isr-cmo-1-0": [ - "4.24", - "12.18", - "23.6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-77" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], - "apac-nzl-ism-3-9": [ - "21.4.12.C.01", - "21.4.12.C.02", - "21.4.12.C.03" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-08.3.json b/docs/api/controls/NET-08.3.json index d6babcbf..4115f262 100644 --- a/docs/api/controls/NET-08.3.json +++ b/docs/api/controls/NET-08.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enforce host containment protections that revoke or quarantine a host’s access to the network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-08.4.json b/docs/api/controls/NET-08.4.json index 71d52d62..8fb17a1f 100644 --- a/docs/api/controls/NET-08.4.json +++ b/docs/api/controls/NET-08.4.json @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -97,7 +98,7 @@ "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.NE.RCONT" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1778", "ISM-1779" ] diff --git a/docs/api/controls/NET-08.json b/docs/api/controls/NET-08.json index c87664cd..d86194cc 100644 --- a/docs/api/controls/NET-08.json +++ b/docs/api/controls/NET-08.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -128,6 +129,10 @@ "03.13.01.a", "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.a[02]", + "A.03.14.06.c[01]" + ], "general-pci-dss-4-0-1": [ "1.4.3", "11.5", @@ -175,20 +180,23 @@ "emea-eu-dora-2023": [ "Article 10.2" ], - "emea-isr-cmo-1-0": [ - "7.4", - "7.6", - "12.18", - "23.6" + "emea-deu-c5-2020": [ + "KOS-01", + "KOS-01-DOAR" ], "emea-sau-ecc-1-2018": [ "2-5-3-6" ], + "emea-sau-otcc-1-2022": [ + "2-3-1-12", + "2-3-1-13" + ], "emea-sau-sacs-002-2022": [ - "TPC-77" + "VII.B.TPC-77" ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.com.2", + "mp.com.3" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -202,19 +210,23 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1028", "ISM-1030", "ISM-1627", "ISM-1628" ], "apac-sgp-mas-trm-2021": [ - "11.2.3", - "11.2.4" + "11.2.3" + ], + "americas-arg-ppd-2018": [ + "E.1.2-DS-2" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "americas-can-osfi-self-assessment-2": [ + "3.2.4" ], "americas-can-itsp-10-171-2025": [ "03.13.01.A", diff --git a/docs/api/controls/NET-09.1.json b/docs/api/controls/NET-09.1.json index 6887d0c9..a8f4f380 100644 --- a/docs/api/controls/NET-09.1.json +++ b/docs/api/controls/NET-09.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically invalidate session identifiers upon user logout or other session termination.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically invalidate session identifiers upon user logout or other session termination. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72,7 +72,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -96,9 +97,6 @@ ], "usa-federal-irs-1075-2021": [ "SC-23(CE-1)" - ], - "emea-deu-c5-2020": [ - "PSS-06" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-09.2.json b/docs/api/controls/NET-09.2.json index 1c20cf31..17735a24 100644 --- a/docs/api/controls/NET-09.2.json +++ b/docs/api/controls/NET-09.2.json @@ -50,7 +50,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-09.json b/docs/api/controls/NET-09.json index 893791b9..2e6b2f84 100644 --- a/docs/api/controls/NET-09.json +++ b/docs/api/controls/NET-09.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the authenticity and integrity of communications sessions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the authenticity and integrity of communications sessions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -101,7 +102,7 @@ "CR 3.8(b)", "CR 3.8(c)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -189,12 +190,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-23" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "17.25" - ], "emea-gbr-def-stan-05-138-2024": [ "2414" ], diff --git a/docs/api/controls/NET-10.1.json b/docs/api/controls/NET-10.1.json index 9d4de53d..50522346 100644 --- a/docs/api/controls/NET-10.1.json +++ b/docs/api/controls/NET-10.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel ensure systems that collectively provide Domain Name Service (DNS) resolution service for are fault-tolerant and implement internal/external role separation.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure systems that collectively provide Domain Name Service (DNS) resolution service are fault-tolerant and implement internal/external role separation.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure systems that collectively provide Domain Name Service (DNS) resolution service are fault-tolerant and implement internal/external role separation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -110,7 +111,7 @@ "general-govramp-high": [ "SC-22" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -181,12 +182,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SC-22" - ], - "emea-isr-cmo-1-0": [ - "9.7" - ], - "apac-nzl-ism-3-9": [ - "15.2.22.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-10.2.json b/docs/api/controls/NET-10.2.json index 07e66151..6283656d 100644 --- a/docs/api/controls/NET-10.2.json +++ b/docs/api/controls/NET-10.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to perform data origin authentication and data integrity verification on the Domain Name Service (DNS) resolution responses received from authoritative sources when requested by client systems.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to perform data origin authentication and data integrity verification on the Domain Name Service (DNS) resolution responses received from authoritative sources when requested by client systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -117,7 +118,7 @@ "general-govramp-high": [ "SC-21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -186,9 +187,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SC-21" - ], - "emea-isr-cmo-1-0": [ - "9.7" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-10.3.json b/docs/api/controls/NET-10.3.json index 6a3d9102..a9084dcb 100644 --- a/docs/api/controls/NET-10.3.json +++ b/docs/api/controls/NET-10.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to validate the legitimacy of email communications through configuring a Domain Naming Service (DNS) Sender Policy Framework (SPF) record to specify the IP addresses and/or hostnames that are authorized to send email from the specified domain.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -109,10 +110,13 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "2.M" ], + "emea-sau-ecc-1-2018": [ + "2-4-3-5" + ], "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15" + "VII.A.TPC-13", + "VII.A.TPC-14", + "VII.A.TPC-15" ], "emea-gbr-def-stan-05-138-2024": [ "2315" @@ -126,18 +130,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0574", "ISM-1151", "ISM-1183", "ISM-1799" - ], - "apac-nzl-ism-3-9": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-10.4.json b/docs/api/controls/NET-10.4.json index 716a89a3..44193bc9 100644 --- a/docs/api/controls/NET-10.4.json +++ b/docs/api/controls/NET-10.4.json @@ -94,17 +94,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1596.002" ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DO.DNMON" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1432" ] } diff --git a/docs/api/controls/NET-10.json b/docs/api/controls/NET-10.json index b3444507..3ea3e094 100644 --- a/docs/api/controls/NET-10.json +++ b/docs/api/controls/NET-10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel ensure Domain Name Service (DNS) resolution is designed, implemented and managed to protect the security of name / address resolution.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure Domain Name Service (DNS) resolution is designed, implemented and managed to protect the security of name / address resolution.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -122,7 +123,7 @@ "general-govramp-high": [ "SC-20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -205,11 +206,10 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(l)" ], - "emea-isr-cmo-1-0": [ - "9.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.2" ], "emea-sau-ecc-1-2018": [ - "2-4-3-5", "2-5-3-7" ], "emea-gbr-def-stan-05-138-2024": [ @@ -224,7 +224,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0574", "ISM-0861", "ISM-1026", @@ -233,14 +233,8 @@ "ISM-1183", "ISM-1540", "ISM-1782", - "ISM-1799" - ], - "apac-nzl-ism-3-9": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" + "ISM-1799", + "ISM-2017" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-11.json b/docs/api/controls/NET-11.json index 25f97a4b..be3f9283 100644 --- a/docs/api/controls/NET-11.json +++ b/docs/api/controls/NET-11.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize out-of-band channels for the electronic transmission of information and/or the physical shipment of system components or devices to authorized individuals.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize out-of-band channels for the electronic transmission of information and/or the physical shipment of system components or devices to authorized individuals. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77,14 +77,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-csa-iot-2": [ "SWS-09" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -122,9 +123,6 @@ ], "general-nist-800-161-r1-level-3": [ "SC-37(1)" - ], - "emea-us-psd2-2015": [ - "22" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-12.1.json b/docs/api/controls/NET-12.1.json index 1ce4a9d3..dd6dd38e 100644 --- a/docs/api/controls/NET-12.1.json +++ b/docs/api/controls/NET-12.1.json @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -101,7 +102,7 @@ "general-csa-iot-2": [ "SWS-07" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1557.004" ], "general-nist-800-53-r4": [ diff --git a/docs/api/controls/NET-12.2.json b/docs/api/controls/NET-12.2.json index 4c36894d..7e14edb0 100644 --- a/docs/api/controls/NET-12.2.json +++ b/docs/api/controls/NET-12.2.json @@ -2,8 +2,8 @@ "control_id": "NET-12.2", "title": "End-User Messaging Technologies", "family": "NET", - "description": "Mechanisms exist to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies.", - "scf_question": "Does the organization prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies?", + "description": "Mechanisms exist to prohibit the transmission of unprotected sensitive and/or regulated data by end-user messaging technologies.", + "scf_question": "Does the organization prohibit the transmission of unprotected sensitive and/or regulated data by end-user messaging technologies?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-12.json b/docs/api/controls/NET-12.json index b32c4ebf..e5ad0cc7 100644 --- a/docs/api/controls/NET-12.json +++ b/docs/api/controls/NET-12.json @@ -2,8 +2,8 @@ "control_id": "NET-12", "title": "Safeguarding Data Over Open Networks", "family": "NET", - "description": "Cryptographic mechanisms exist to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks.", - "scf_question": "Are cryptographic mechanisms utilized to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks?", + "description": "Cryptographic mechanisms exist to implement strong cryptography and security protocols to safeguard sensitive and/or regulated data during transmission over open, public networks.", + "scf_question": "Are cryptographic mechanisms utilized to implement strong cryptography and security protocols to safeguard sensitive and/or regulated data during transmission over open, public networks?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). \n▪ Wireless access is protected via secure authentication and encryption.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network communications containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -388,11 +389,8 @@ "SI-07", "SI-10" ], - "emea-isr-cmo-1-0": [ - "8.4", - "8.6", - "9.20", - "13.6" + "emea-deu-c5-2020": [ + "PI-04" ], "emea-gbr-def-stan-05-138-2024": [ "2305" @@ -424,9 +422,6 @@ "14.1.2.13", "14.1.2.14", "14.1.2.15" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS17" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-13.json b/docs/api/controls/NET-13.json index c1bf3077..0e91fa90 100644 --- a/docs/api/controls/NET-13.json +++ b/docs/api/controls/NET-13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the confidentiality, integrity and availability of electronic messaging communications.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -157,10 +158,10 @@ "2-3-1", "2-3-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.1 [MP.S.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0264", "ISM-0267", "ISM-0269", @@ -224,25 +225,6 @@ "15.1.19.C.01", "15.1.19.C.02", "15.1.20.C.01", - "15.2.25.C.01", - "15.2.25.C.02", - "15.2.26.C.01", - "15.2.27.C.01", - "15.2.28.C.01", - "15.2.29.C.01", - "15.2.30.C.01", - "15.2.30.C.02", - "15.2.30.C.03", - "15.2.31.C.01", - "15.2.31.C.02", - "15.2.32.C.01", - "15.2.32.C.02", - "15.2.32.C.03", - "15.2.33.C.01", - "15.2.33.C.02", - "15.2.33.C.03", - "15.2.33.C.04", - "16.7.33.C.01", "17.6.6.C.01", "17.6.7.C.01" ] diff --git a/docs/api/controls/NET-14.1.json b/docs/api/controls/NET-14.1.json index c20dd37c..dfe01857 100644 --- a/docs/api/controls/NET-14.1.json +++ b/docs/api/controls/NET-14.1.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically monitor and control remote access sessions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically monitor and control remote access sessions. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -75,7 +75,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -130,6 +131,16 @@ "3.1.12[c]", "3.1.12[d]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.b" + ], + "general-nist-800-172-r3": [ + "03.01.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.05E[01]", + "DS-A.03.01.05E[02]" + ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -154,8 +165,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (01)" ], - "emea-isr-cmo-1-0": [ - "4.18" + "emea-sau-cscc-1-2019": [ + "2-2-1-2" + ], + "emea-sau-otcc-1-2022": [ + "2-2-1-7" ], "americas-can-itsp-10-171-2025": [ "03.01.12.B" diff --git a/docs/api/controls/NET-14.2.json b/docs/api/controls/NET-14.2.json index f27b0dd7..77e28d7c 100644 --- a/docs/api/controls/NET-14.2.json +++ b/docs/api/controls/NET-14.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of remote access sessions (e.g., VPN).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of remote access sessions (e.g., VPN). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -133,6 +134,9 @@ "3.1.13[a]", "3.1.13[b]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.a[04]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -160,8 +164,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (02)" ], - "emea-isr-cmo-1-0": [ - "9.8" + "emea-sau-otcc-1-2022": [ + "2-2-1-7" ], "emea-gbr-def-stan-05-138-2024": [ "2305", @@ -179,6 +183,9 @@ "2305", "2306" ], + "apac-aus-cop-sitc-2020": [ + "7" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A" ] diff --git a/docs/api/controls/NET-14.3.json b/docs/api/controls/NET-14.3.json index 0445494d..97f441fd 100644 --- a/docs/api/controls/NET-14.3.json +++ b/docs/api/controls/NET-14.3.json @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -144,13 +145,16 @@ "3.1.14" ], "general-nist-800-171-r3": [ - "03.01.12.b", "03.01.12.c" ], "general-nist-800-171a": [ "3.1.14[a]", "3.1.14[b]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EN.VPNET" ], @@ -179,8 +183,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (03)" ], - "emea-isr-cmo-1-0": [ - "4.19" + "emea-sau-otcc-1-2022": [ + "2-4-1-7" ], "emea-gbr-def-stan-05-138-2024": [ "2307" @@ -195,7 +199,6 @@ "2307" ], "americas-can-itsp-10-171-2025": [ - "03.01.12.B", "03.01.12.C" ] } diff --git a/docs/api/controls/NET-14.4.json b/docs/api/controls/NET-14.4.json index b7eb0363..710dcf19 100644 --- a/docs/api/controls/NET-14.4.json +++ b/docs/api/controls/NET-14.4.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network communications containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to restrict the execution of privileged commands and access to security-relevant information via remote access only for compelling operational needs.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to restrict the execution of privileged commands and access to security-relevant information via remote access only for compelling operational needs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -148,12 +149,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (04)" ], - "emea-isr-cmo-1-0": [ - "4.17", - "4.20" - ], "emea-sau-sacs-002-2022": [ - "TPC-35" + "VII.B.TPC-35" ], "emea-gbr-def-stan-05-138-2024": [ "2417" diff --git a/docs/api/controls/NET-14.5.json b/docs/api/controls/NET-14.5.json index 26dffed5..0b6e14ba 100644 --- a/docs/api/controls/NET-14.5.json +++ b/docs/api/controls/NET-14.5.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define secure telecommuting practices and govern remote access to TAASD for remote workers.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define secure telecommuting practices and govern remote access to TAASD for remote workers. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -113,7 +113,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -144,11 +145,11 @@ ], "general-nist-800-171-r3": [ "03.01.12.a", - "03.01.12.c", "03.10.06.a", "03.10.06.b" ], "general-nist-800-171a-r3": [ + "A.03.01.12.a[01]", "A.03.10.06.ODP[01]", "A.03.10.06.a", "A.03.10.06.b" @@ -176,10 +177,6 @@ "2-2-1-1", "2-2-1-2" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.7 [OP.ACC.7]", - "9" - ], "emea-gbr-def-stan-05-138-2024": [ "2305" ], @@ -217,26 +214,16 @@ "6.2.2.20", "6.2.2.21" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS13" - ], "apac-nzl-ism-3-9": [ "21.2.4.C.01", - "21.2.4.C.02", "21.2.5.C.01", "21.2.6.C.01", "21.2.7.C.01", - "21.2.7.C.02", - "21.3.5.C.01", - "21.3.6.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "9.3.1", - "9.3.2" + "22.2.4.C.01", + "22.2.4.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", - "03.01.12.C", "03.10.06.A", "03.10.06.B" ] diff --git a/docs/api/controls/NET-14.6.json b/docs/api/controls/NET-14.6.json index 37fe069a..3eabc149 100644 --- a/docs/api/controls/NET-14.6.json +++ b/docs/api/controls/NET-14.6.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to proactively control and monitor third-party accounts used to access, support, or maintain system components via remote access.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -137,9 +138,6 @@ "CIP-005-7 2.5", "CIP-005-7 3.1", "CIP-005-7 3.2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-14.7.json b/docs/api/controls/NET-14.7.json index 1ca167d0..f854c0ce 100644 --- a/docs/api/controls/NET-14.7.json +++ b/docs/api/controls/NET-14.7.json @@ -3,7 +3,7 @@ "title": "Endpoint Security Validation", "family": "NET", "description": "Automated mechanisms exist to validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS)?", + "scf_question": "Does the organization use automated mechanisms to validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 6, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-14.8.json b/docs/api/controls/NET-14.8.json index e0ae71df..2838fd47 100644 --- a/docs/api/controls/NET-14.8.json +++ b/docs/api/controls/NET-14.8.json @@ -20,7 +20,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel provide the capability to expeditiously disconnect or disable a user's remote access session.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to provide the capability to expeditiously disconnect or disable a user's remote access session.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -142,7 +143,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (09)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1591" ] } diff --git a/docs/api/controls/NET-14.json b/docs/api/controls/NET-14.json index 0462b5e4..704f9c1b 100644 --- a/docs/api/controls/NET-14.json +++ b/docs/api/controls/NET-14.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define, control and review organization-approved, secure remote access methods.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -153,7 +154,7 @@ "general-iso-27018-2025": [ "6.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1021", "T1021.001", @@ -292,19 +293,21 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.12.b", - "03.01.12.c", - "03.01.12.d" + "03.01.12.c" ], "general-nist-800-171a-r3": [ "A.03.01.12.a[01]", "A.03.01.12.a[02]", - "A.03.01.12.a[03]", "A.03.01.12.a[04]", "A.03.01.12.b", "A.03.01.12.c[01]", - "A.03.01.12.c[02]", - "A.03.01.12.d[1]", - "A.03.01.12.d[2]" + "A.03.01.12.c[02]" + ], + "general-nist-800-172-r3": [ + "03.01.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.06E" ], "general-pci-dss-4-0-1": [ "3.4.2", @@ -420,21 +423,13 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(d)" ], - "emea-isr-cmo-1-0": [ - "4.17" - ], "emea-sau-cscc-1-2019": [ "2-2-1-1", "2-2-1-2" ], "emea-sau-otcc-1-2022": [ - "2-2-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.7 [OP.ACC.7]" + "2-2-1-7", + "2-4-1-10" ], "emea-gbr-def-stan-05-138-2024": [ "2305" @@ -448,7 +443,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2305" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0487", "ISM-0488", "ISM-0489" @@ -456,9 +451,6 @@ "apac-ind-sebi-2024": [ "PR.AA.S12" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS13" - ], "apac-nzl-ism-3-9": [ "16.5.10.C.01", "16.5.10.C.02", @@ -482,7 +474,7 @@ "03.01.12.A", "03.01.12.B", "03.01.12.C", - "03.01.12.D" + "03.14.08.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-15.1.json b/docs/api/controls/NET-15.1.json index 597ca0fc..ba43c632 100644 --- a/docs/api/controls/NET-15.1.json +++ b/docs/api/controls/NET-15.1.json @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -118,6 +119,8 @@ "3.1.17[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.16.a[04]", + "A.03.01.16.b", "A.03.01.16.d[01]", "A.03.01.16.d[02]" ], @@ -177,8 +180,11 @@ "emea-eu-nis2-annex-2024": [ "11.4.2(c)" ], - "emea-isr-cmo-1-0": [ - "12.14" + "emea-sau-ecc-1-2018": [ + "2-5-3-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-42" ], "emea-gbr-def-stan-05-138-2024": [ "2304" @@ -209,6 +215,8 @@ "18.2.17.C.01", "18.2.18.C.01", "18.2.19.C.01", + "18.2.19.C.02", + "18.2.19.C.03", "18.2.20.C.01", "18.2.20.C.02", "18.2.20.C.03", diff --git a/docs/api/controls/NET-15.2.json b/docs/api/controls/NET-15.2.json index afbdc9ef..b6ccecf9 100644 --- a/docs/api/controls/NET-15.2.json +++ b/docs/api/controls/NET-15.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to disable unnecessary wireless networking capabilities that are internally embedded within system components prior to issuance to end users.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to disable unnecessary wireless networking capabilities that are internally embedded within system components prior to issuance to end users. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -102,6 +103,9 @@ "general-nist-800-171-r3": [ "03.01.16.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.c" + ], "general-shared-assessments-sig-2025": [ "U.1.2" ], @@ -117,16 +121,9 @@ "usa-federal-irs-1075-2021": [ "AC-18(CE-3)" ], - "emea-isr-cmo-1-0": [ - "4.24" - ], "emea-sau-cscc-1-2019": [ "2-4-1-4" ], - "apac-nzl-ism-3-9": [ - "21.1.16.C.01", - "21.1.16.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.16.C" ] diff --git a/docs/api/controls/NET-15.3.json b/docs/api/controls/NET-15.3.json index 88f40639..1a478259 100644 --- a/docs/api/controls/NET-15.3.json +++ b/docs/api/controls/NET-15.3.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to identify and explicitly authorize users who are allowed to independently configure wireless networking capabilities.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to identify and explicitly authorize users who are allowed to independently configure wireless networking capabilities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -109,12 +110,13 @@ "03.01.16.a", "03.01.16.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[03]", + "A.03.01.16.c" + ], "usa-federal-gsa-fedramp-5-high": [ "AC-18(04)" ], - "emea-isr-cmo-1-0": [ - "12.13" - ], "americas-can-itsp-10-171-2025": [ "03.01.16.A", "03.01.16.C" diff --git a/docs/api/controls/NET-15.4.json b/docs/api/controls/NET-15.4.json index ee4aada1..30cc9e9e 100644 --- a/docs/api/controls/NET-15.4.json +++ b/docs/api/controls/NET-15.4.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to confine wireless communications to organization-controlled boundaries.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to confine wireless communications to organization-controlled boundaries. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -118,10 +119,7 @@ "usa-federal-gsa-fedramp-5-high": [ "AC-18(05)" ], - "emea-isr-cmo-1-0": [ - "4.23" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1013", "ISM-1338" ], diff --git a/docs/api/controls/NET-15.5.json b/docs/api/controls/NET-15.5.json index b86dbab3..fadd6c4d 100644 --- a/docs/api/controls/NET-15.5.json +++ b/docs/api/controls/NET-15.5.json @@ -20,9 +20,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to test for the presence of Wireless Access Points (WAPs) and identify all authorized and unauthorized WAPs within the facility(ies).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to test for the presence of Wireless Access Points (WAPs) and identify all authorized and unauthorized WAPs within the facility(ies). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -117,8 +118,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "AC-18-SID.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0829" + ], + "apac-nzl-ism-3-9": [ + "22.4.12.C.02", + "22.4.12.C.03" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-15.json b/docs/api/controls/NET-15.json index 35d711b8..88ad6896 100644 --- a/docs/api/controls/NET-15.json +++ b/docs/api/controls/NET-15.json @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -140,7 +141,7 @@ "general-iso-27018-2025": [ "8.21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011", "T1011.001", "T1020.001", @@ -223,7 +224,8 @@ "general-nist-800-171a-r3": [ "A.03.01.16.a[01]", "A.03.01.16.a[02]", - "A.03.01.16.a[04]" + "A.03.01.16.a[04]", + "A.03.01.16.b" ], "general-nist-800-207": [ "NIST Tenet 2" @@ -287,22 +289,22 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-18" ], - "emea-isr-cmo-1-0": [ - "4.24", - "12.12", - "12.14" - ], "emea-sau-cscc-1-2019": [ "2-3-1-5", "2-4-1-4" ], + "emea-sau-ecc-1-2018": [ + "2-5-3-4" + ], "emea-sau-otcc-1-2022": [ - "2-4-1-4", - "2-4-1-5" + "2-4-1-4" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.com.2", + "mp.com.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0225", - "ISM-0248", "ISM-0536", "ISM-1314", "ISM-1315", diff --git a/docs/api/controls/NET-16.json b/docs/api/controls/NET-16.json index b8cc93bc..8977c114 100644 --- a/docs/api/controls/NET-16.json +++ b/docs/api/controls/NET-16.json @@ -3,7 +3,7 @@ "title": "Intranets", "family": "NET", "description": "Mechanisms exist to establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS.", - "scf_question": "Does the organization establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n (1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n (2) Process, store, and/or transmit organization-controlled information using the external systems?", + "scf_question": "Does the organization establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": {} diff --git a/docs/api/controls/NET-17.json b/docs/api/controls/NET-17.json index ea73adab..b1b7fbca 100644 --- a/docs/api/controls/NET-17.json +++ b/docs/api/controls/NET-17.json @@ -20,7 +20,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Data Loss Prevention (DLP), or similar technologies, prevent unauthorized devices from connecting to endpoint devices to control the distribution of sensitive/regulated data.\n▪ DLP prevents unauthorized devices from connecting to endpoint devices to control the distribution of sensitive/regulated data.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically implement Data Loss Prevention (DLP) to protect sensitive information as it is stored, transmitted and processed.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -58,7 +58,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -110,6 +111,12 @@ "SC-07(10)", "SI-04(18)" ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.a" + ], "general-pci-dss-4-0-1": [ "A3.2.6" ], @@ -176,16 +183,25 @@ "apac-ind-sebi-2024": [ "PR.DS.S4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP63", "HML69" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP55" ], - "amaericas-can-osfi-self-assessment": [ - "4.1", - "4.2" + "apac-nzl-ism-3-9": [ + "15.2.39.C.01", + "15.2.40.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.1.1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-DS-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.9" ], "americas-can-osfi-b13-2022": [ "3.2.5" diff --git a/docs/api/controls/NET-18.1.json b/docs/api/controls/NET-18.1.json index 348c8ea5..feda8702 100644 --- a/docs/api/controls/NET-18.1.json +++ b/docs/api/controls/NET-18.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce Internet-bound network traffic routing through a proxy device for URL content filtering to limit a user's ability to connect to prohibited content.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to route internal communications traffic to external networks through organization-approved proxy servers at managed interfaces.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to route internal communications traffic to external networks through organization-approved proxy servers at managed interfaces. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93,15 +93,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-cis-csc-8-1": [ - "13.1" + "13.10" ], "general-cis-csc-8-1-ig3": [ - "13.1" + "13.10" ], "general-govramp": [ "SC-07(08)" @@ -161,16 +162,13 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.1.b" ], - "emea-isr-cmo-1-0": [ - "9.14" - ], "emea-sau-cscc-1-2019": [ "2-4-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-5-3-8" + "emea-sau-otcc-1-2022": [ + "2-4-1-11" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0260", "ISM-0570", "ISM-1237" @@ -178,7 +176,8 @@ "apac-nzl-ism-3-9": [ "14.3.6.C.01", "14.3.6.C.02", - "14.3.6.C.03" + "14.3.6.C.03", + "15.2.46.C.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-18.2.json b/docs/api/controls/NET-18.2.json index 1bc43403..4a8822ae 100644 --- a/docs/api/controls/NET-18.2.json +++ b/docs/api/controls/NET-18.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure the proxy to make encrypted communications traffic visible to monitoring tools and mechanisms.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -120,13 +121,12 @@ "usa-federal-irs-1075-2021": [ "SI-4(CE-10)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0263" ], "apac-nzl-ism-3-9": [ "14.3.8.C.01", - "14.3.9.C.01", - "20.3.14.C.01" + "14.3.9.C.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-18.3.json b/docs/api/controls/NET-18.3.json index 7e3b816e..42460738 100644 --- a/docs/api/controls/NET-18.3.json +++ b/docs/api/controls/NET-18.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically route networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -72,7 +72,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-18.4.json b/docs/api/controls/NET-18.4.json index 7df8c11d..c5afb726 100644 --- a/docs/api/controls/NET-18.4.json +++ b/docs/api/controls/NET-18.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically ensure network traffic complies with Internet Engineering Task Force (IETF) protocol specifications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-18.5.json b/docs/api/controls/NET-18.5.json index 618aae65..6d8e858b 100644 --- a/docs/api/controls/NET-18.5.json +++ b/docs/api/controls/NET-18.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure that domain name lookups, whether for internal or external domains, are validated according to Domain Name System Security Extensions (DNSSEC).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-18.6.json b/docs/api/controls/NET-18.6.json index 1e464fbf..9e967b6a 100644 --- a/docs/api/controls/NET-18.6.json +++ b/docs/api/controls/NET-18.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement Internet address denylisting protections that blocks traffic received from or destined to a denylisted Internet address.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-18.7.json b/docs/api/controls/NET-18.7.json index 45266d27..25ca9939 100644 --- a/docs/api/controls/NET-18.7.json +++ b/docs/api/controls/NET-18.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement bandwidth control technologies to limit the amount of bandwidth used by categories of domains that are bandwidth-intensive.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-18.8.json b/docs/api/controls/NET-18.8.json index 82e44410..28aea008 100644 --- a/docs/api/controls/NET-18.8.json +++ b/docs/api/controls/NET-18.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to force systems and processes to authenticate Internet-bound traffic with a proxy to enable user, group and/or location-aware security controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-18.9.json b/docs/api/controls/NET-18.9.json index 99834567..38a97a6a 100644 --- a/docs/api/controls/NET-18.9.json +++ b/docs/api/controls/NET-18.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent communication with Technology Assets, Applications and/or Services (TAAS) that use a set of known bad certificates.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-18.json b/docs/api/controls/NET-18.json index f311be23..8e9c76a8 100644 --- a/docs/api/controls/NET-18.json +++ b/docs/api/controls/NET-18.json @@ -22,7 +22,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce Internet-bound network traffic routing through a proxy device for URL content filtering to limit a user's ability to connect to prohibited content.\n▪ Content filtering blocks users from performing ad hoc file transfers through unapproved file transfer services (e.g., Box, Dropbox, Google Drive, etc.).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to force Internet-bound network traffic through a proxy device (e.g., Policy Enforcement Point (PEP)) for URL content filtering and DNS filtering to limit a user's ability to connect to dangerous or prohibited Internet sites.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -98,15 +98,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.2", "9.3", - "13.1" + "13.10" ], "general-cis-csc-8-1-ig1": [ "9.2" @@ -118,7 +119,7 @@ "general-cis-csc-8-1-ig3": [ "9.2", "9.3", - "13.1" + "13.10" ], "general-govramp": [ "SC-07(08)" @@ -175,6 +176,9 @@ "general-nist-800-171-r3": [ "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.14.06.c[02]" + ], "general-nist-csf-2-0": [ "DE.CM-03" ], @@ -241,15 +245,21 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(l)" ], - "emea-isr-cmo-1-0": [ - "9.14" - ], "emea-sau-ecc-1-2018": [ - "2-5-3-3", - "2-5-3-8" + "2-5-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-57" + "VII.B.TPC-57", + "VII.B.TPC-57-BP1", + "VII.B.TPC-57-BP2", + "VII.B.TPC-57-BP3" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1", + "mp.s.3" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP1-4" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -263,7 +273,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0267", "ISM-0649", "ISM-0659", @@ -278,7 +288,8 @@ "ISM-1287", "ISM-1293", "ISM-1502", - "ISM-1524" + "ISM-1524", + "ISM-1965" ], "apac-nzl-ism-3-9": [ "9.3.6.C.01", @@ -292,27 +303,16 @@ "14.3.11.C.01", "14.3.11.C.02", "14.3.12.C.01", - "20.3.4.C.01", - "20.3.4.C.02", - "20.3.5.C.01", - "20.3.5.C.02", - "20.3.6.C.01", - "20.3.7.C.01", - "20.3.7.C.02", - "20.3.8.C.01", "20.3.9.C.01", "20.3.10.C.01", "20.3.11.C.01", "20.3.11.C.02", - "20.3.11.C.03", - "20.3.12.C.01", - "20.3.12.C.02", - "20.3.13.C.01", - "20.3.13.C.02", - "20.3.14.C.01", - "20.3.15.C.01", - "20.3.15.C.02", - "20.3.16.C.01" + "21.3.7.C.01", + "21.3.7.C.02", + "21.3.14.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.2.7" ], "americas-can-itsp-10-171-2025": [ "03.14.06.C" diff --git a/docs/api/controls/NET-19.json b/docs/api/controls/NET-19.json index 4f830f85..bc5ddac4 100644 --- a/docs/api/controls/NET-19.json +++ b/docs/api/controls/NET-19.json @@ -3,7 +3,7 @@ "title": "Content Disarm and Reconstruction (CDR)", "family": "NET", "description": "Automated Content Disarm and Reconstruction (CDR) mechanisms exist to detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements.", - "scf_question": "Automated Content Disarm and Reconstruction (CDR) Does the organization detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements?", + "scf_question": "Does the organization use automated Content Disarm and Reconstruction (CDR) mechanisms exist to detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational Content Disarm and Reconstruction (CDR) capability detects the presence of unapproved active content and facilitates its removal, resulting in content with only known safe elements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-20.1.json b/docs/api/controls/NET-20.1.json index 401477ac..8537a30d 100644 --- a/docs/api/controls/NET-20.1.json +++ b/docs/api/controls/NET-20.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor the organization's email domain’s reputation and protect the email domain’s reputation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-20.2.json b/docs/api/controls/NET-20.2.json index be5bb6e8..0169ad70 100644 --- a/docs/api/controls/NET-20.2.json +++ b/docs/api/controls/NET-20.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement sender denylisting protections that prevent the reception of email from denylisted senders, domains and/or email servers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-20.3.json b/docs/api/controls/NET-20.3.json index f6c2e6ea..93b09ab9 100644 --- a/docs/api/controls/NET-20.3.json +++ b/docs/api/controls/NET-20.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize an authenticated received chain that allows for an intermediary to sign its own authentication of the original email, allowing downstream entities to accept the intermediary’s authentication even if the email was changed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-20.4.json b/docs/api/controls/NET-20.4.json index c8585b9f..e6da44fb 100644 --- a/docs/api/controls/NET-20.4.json +++ b/docs/api/controls/NET-20.4.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement domain signature verification protections that authenticate incoming email according to the Domain-based Message Authentication Reporting and Conformance (DMARC).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement domain signature verification protections that authenticate incoming email according to the Domain-based Message Authentication Reporting and Conformance (DMARC).\n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -110,8 +111,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1540" + ], + "apac-nzl-ism-3-9": [ + "15.2.36.C.01", + "15.2.36.C.02", + "15.2.36.C.03", + "15.2.36.C.04", + "15.2.36.C.05" ] } } \ No newline at end of file diff --git a/docs/api/controls/NET-20.5.json b/docs/api/controls/NET-20.5.json index 5d156dab..492f33b8 100644 --- a/docs/api/controls/NET-20.5.json +++ b/docs/api/controls/NET-20.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable users to digitally sign their emails, allowing external parties to authenticate the email’s sender and its contents according to the Domain-based Message Authentication Reporting and Conformance (DMARC) email authentication protocol.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-20.6.json b/docs/api/controls/NET-20.6.json index c291301f..1a06af7e 100644 --- a/docs/api/controls/NET-20.6.json +++ b/docs/api/controls/NET-20.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable the encryption of outgoing emails using organization-approved cryptographic means.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-20.7.json b/docs/api/controls/NET-20.7.json index 6c4c43f6..04327bc3 100644 --- a/docs/api/controls/NET-20.7.json +++ b/docs/api/controls/NET-20.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize adaptive email protections that involve employing risk-based analysis in the application and enforcement of email protections.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -101,7 +102,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2509" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0567" ] } diff --git a/docs/api/controls/NET-20.8.json b/docs/api/controls/NET-20.8.json index 14f422bb..b44ae89f 100644 --- a/docs/api/controls/NET-20.8.json +++ b/docs/api/controls/NET-20.8.json @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-20.9.json b/docs/api/controls/NET-20.9.json index ea2970f5..5f0c2370 100644 --- a/docs/api/controls/NET-20.9.json +++ b/docs/api/controls/NET-20.9.json @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/NET-20.json b/docs/api/controls/NET-20.json index fc943983..371c012b 100644 --- a/docs/api/controls/NET-20.json +++ b/docs/api/controls/NET-20.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement an email filtering security service to detect malicious attachments in emails and prevent users from accessing them.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/controls/OPS-01.1.json b/docs/api/controls/OPS-01.1.json index 8da7dfb0..c7509a8b 100644 --- a/docs/api/controls/OPS-01.1.json +++ b/docs/api/controls/OPS-01.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to identify and document Standardized Operating Procedures (SOP), or similar documentation, to enable the proper execution of day-to-day / assigned tasks.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -173,9 +174,46 @@ ], "general-nist-800-171a-r3": [ "A.03.15.01.a[03]", - "A.03.15.01.a[04]", - "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.a[04]" + ], + "general-nist-800-172-r3": [ + "03.02.01E", + "03.08.03E", + "03.09.03E", + "03.11.02E", + "03.12.01E", + "03.13.05E", + "03.13.07E", + "03.14.08E", + "03.14.15E", + "03.15.01E", + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.02.01E.ODP[02]", + "A.03.08.03E.ODP[01]", + "A.03.08.03E.ODP[02]", + "DS-A.03.09.03E.b[01]", + "A.03.09.03E.ODP[01]", + "DS-A.03.09.03E.b[02]", + "DS-A.03.09.03E.c.02", + "A.03.09.03E.ODP[02]", + "A.03.11.02E.ODP[01]", + "A.03.12.01E.ODP[01]", + "A.03.12.04E.ODP[03]", + "A.03.13.05E.ODP[02]", + "A.03.13.05E.ODP[03]", + "A.03.13.07E.ODP[01]", + "A.03.14.05E.ODP[02]", + "A.03.14.05E.ODP[03]", + "A.03.14.05E.ODP[04]", + "A.03.14.08E.ODP[08]", + "A.03.14.08E.ODP[09]", + "A.03.14.08E.ODP[12]", + "A.03.14.15E.ODP[03]", + "A.03.15.01E.ODP[01]", + "A.03.17.02E.ODP[02]", + "A.03.17.02E.ODP[03]" ], "general-nist-800-218": [ "PO.3.2", @@ -385,12 +423,12 @@ "314.4(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-cms-marse-2-0": [ "AC-1.b", @@ -427,16 +465,9 @@ "500.8(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.2.(31)", - "3.4.2(31)(a)", - "3.4.2(31)(b)", - "3.4.2(31)(c)", - "3.4.2(31)(d)", - "3.4.2(31)(e)", - "3.4.2(31)(f)", - "3.4.2(31)(g)", - "3.4.5(38)", - "3.5(50)" + "3.4.2.31", + "3.4.4.36", + "3.5.50" ], "emea-eu-dora-2023": [ "Article 6.2", @@ -447,31 +478,14 @@ "7.1", "9.1" ], - "emea-deu-c5-2020": [ - "SP-01", - "IDM-02" - ], - "emea-isr-cmo-1-0": [ - "12.2", - "12.3", - "18.2", - "22.2" - ], "emea-sau-cgiot-2024": [ "1-2-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2(d)", - "Article 13.4", - "Article 22.2" - ], - "emea-esp-decree-311-2022": [ - "13.2(d)", - "13.4", - "22.2" + "emea-sau-ecc-1-2018": [ + "1-3-4" ], - "emea-esp-ccn-stic-825-2023": [ - "6.3 [ORG.3]" + "emea-esp-ccn-stic-825-2026": [ + "org.3" ], "emea-gbr-def-stan-05-138-2024": [ "1100", @@ -492,15 +506,6 @@ "2100", "2101" ], - "apac-chn-pipl-2021": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" - ], "apac-ind-sebi-2024": [ "PR.AA.S14", "PR.IP.S7", @@ -525,6 +530,9 @@ "12.1.5.P", "12.1.5.1.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.27" + ], "apac-nzl-hisf-suppliers-2023": [ "HSUP01" ], @@ -536,15 +544,35 @@ "5.5.3.C.01", "5.5.4.C.01", "5.5.5.C.01", - "5.5.6.C.01" + "5.5.6.C.01", + "16.1.24.C.01", + "20.2.15.C.01", + "21.1.7.C.01", + "21.1.7.C.02" + ], + "americas-arg-ppd-2018": [ + "B.1.3-1", + "B.1.3-2", + "B.1.3-3", + "B.2.4-2", + "B.2.5" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP4" ], "americas-can-osfi-b13-2022": [ "2.2.1", "2.8", "3" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/OPS-01.json b/docs/api/controls/OPS-01.json index 52d7eb43..35a822bf 100644 --- a/docs/api/controls/OPS-01.json +++ b/docs/api/controls/OPS-01.json @@ -107,7 +107,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -134,7 +135,7 @@ "7.5.3(a)", "7.5.3(b)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025" ], @@ -183,6 +184,9 @@ "03.15.01.a", "03.15.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]" + ], "general-nist-csf-2-0": [ "ID.IM" ], @@ -297,54 +301,14 @@ "Article 9.1", "Article 9.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-c5-2020": [ - "SP-01" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5" - ], - "emea-esp-decree-311-2022": [ - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" - ], - "apac-chn-pipl-2021": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "emea-esp-ccn-stic-825-2026": [ + "org.3" ], "apac-jpn-ismap": [ "12", "12.1", "12.1.3.9.PB" ], - "apac-sgp-mas-trm-2021": [ - "7.1.1" - ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "1.5" - ], "americas-can-osfi-b13-2022": [ "3" ], diff --git a/docs/api/controls/OPS-02.json b/docs/api/controls/OPS-02.json index c566ee65..e08476e0 100644 --- a/docs/api/controls/OPS-02.json +++ b/docs/api/controls/OPS-02.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cybersecurity operations are primarily viewed as additional duties for IT staff.\n▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage.", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", - "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to develop a security Concept of Operations (CONOPS), or a similarly-defined plan for achieving cybersecurity objectives, that documents management, operational and technical measures implemented to apply defense-in-depth techniques that is communicated to all appropriate stakeholders.", + "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to develop a security Concept of Operations (CONOPS), or a similarly-defined plan for achieving cybersecurity objectives, that documents management, operational and technical measures implemented to apply defense-in-depth techniques that is communicated to all appropriate stakeholders. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -118,18 +119,21 @@ "8.1.1" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(6)" + "3.2.2.6" ], "emea-eu-dora-2023": [ "Article 9.1", "Article 9.2" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.2" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], "apac-nzl-ism-3-9": [ "5.1.15.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "4.30" - ], "americas-can-osfi-b13-2022": [ "1.3.2" ] diff --git a/docs/api/controls/OPS-03.json b/docs/api/controls/OPS-03.json index f386e9d2..8ce6b465 100644 --- a/docs/api/controls/OPS-03.json +++ b/docs/api/controls/OPS-03.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to define supporting business processes and implement appropriate governance and service management to ensure appropriate planning, delivery and support of the organization's technology capabilities supporting business functions, workforce, and/or customers based on industry-recognized standards to achieve the specific goals of the process area.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -184,7 +185,10 @@ "164.316(b)" ], "general-nist-800-171-r3": [ - "03.15.01.b" + "03.15.01.a" + ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[04]" ], "general-nist-800-218": [ "PO.3.2" @@ -199,14 +203,14 @@ "11.10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-cms-marse-2-0": [ "IP-4", @@ -218,7 +222,6 @@ ], "emea-deu-bsrit-2017": [ "8.1", - "8.2", "11.1", "11.2", "11.3", @@ -228,8 +231,11 @@ "11.7", "11.8" ], - "apac-chn-pipl-2021": [ - "51" + "emea-esp-ccn-stic-825-2026": [ + "org.3" + ], + "apac-aus-ps-cps-230-2023": [ + "12(b)" ], "apac-jpn-ismap": [ "13.1.1.11.P", @@ -238,19 +244,24 @@ "14.1.1.19.P", "14.1.1.20.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.31" + ], "apac-sgp-mas-trm-2021": [ "7.1.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "1.5" - ], "americas-can-osfi-b13-2022": [ "2.2.1", "2.8" ], + "americas-can-osfi-self-assessment-2": [ + "2.8.1" + ], "americas-can-itsp-10-171-2025": [ - "03.15.01.B" + "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/OPS-04.json b/docs/api/controls/OPS-04.json index 4cdb1533..c43ee452 100644 --- a/docs/api/controls/OPS-04.json +++ b/docs/api/controls/OPS-04.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to establish and maintain a Security Operations Center (SOC) that facilitates a 24x7 response capability.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -119,8 +120,12 @@ "general-nist-800-161-r1-level-3": [ "SC-38" ], - "general-nist-800-172": [ - "3.6.1e" + "general-nist-800-172-r3": [ + "03.06.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.01E[01]", + "DS-A.03.06.01E[02]" ], "usa-federal-dow-cmmc-2-level-3": [ "IR.L3-3.6.1E" @@ -145,11 +150,8 @@ "apac-ind-sebi-2024": [ "DE.CM.S1" ], - "apac-sgp-mas-trm-2021": [ - "12.2.1" - ], - "amaericas-can-osfi-self-assessment": [ - "1.4" + "apac-mys-bnm-rmit-2025": [ + "11.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/OPS-05.json b/docs/api/controls/OPS-05.json index d1500a78..47027c0c 100644 --- a/docs/api/controls/OPS-05.json +++ b/docs/api/controls/OPS-05.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to provide guidelines and recommendations for the secure use of Technology Assets, Applications and/or Services (TAAS) to assist in the configuration, installation and use of the product and/or service.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -101,13 +102,6 @@ ], "usa-federal-dow-zt-roadmap-1-1": [ "6.5.3" - ], - "emea-deu-c5-2020": [ - "PSS-01" - ], - "amaericas-can-osfi-self-assessment": [ - "4.29", - "4.30" ] } } \ No newline at end of file diff --git a/docs/api/controls/OPS-06.json b/docs/api/controls/OPS-06.json index 531c1fe8..87d3c7a6 100644 --- a/docs/api/controls/OPS-06.json +++ b/docs/api/controls/OPS-06.json @@ -67,13 +67,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { - "general-nist-800-172": [ - "3.11.3e" - ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EN.SOARE" ], @@ -87,6 +85,9 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.d" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/OPS-07.json b/docs/api/controls/OPS-07.json index 9171fa7a..2ee62ab3 100644 --- a/docs/api/controls/OPS-07.json +++ b/docs/api/controls/OPS-07.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cybersecurity operations are primarily viewed as additional duties for IT staff.\n▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage.", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ An implemented and operational capability exists to detect the presence of unauthorized Technology Assets, Applications and/or Services (TAAS) in use.", + "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to detect the presence of unauthorized Technology Assets, Applications and/or Services (TAAS) in use.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -114,7 +114,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -123,6 +124,13 @@ ], "apac-ind-sebi-2024": [ "ID.AM.S3" + ], + "apac-mys-bnm-rmit-2025": [ + "10.16" + ], + "apac-sgp-mas-trm-2021": [ + "6.5.1", + "6.5.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-01.1.json b/docs/api/controls/PES-01.1.json index c3706213..889c2aba 100644 --- a/docs/api/controls/PES-01.1.json +++ b/docs/api/controls/PES-01.1.json @@ -3,7 +3,7 @@ "title": "Physical Security Plan (PSP)", "family": "PES", "description": "Mechanisms exist to document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats.", - "scf_question": "Does the organization document a Site Security Plan (SitePlan) for each server and communications room to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats?", + "scf_question": "Does the organization document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats?", "relative_weight": 4, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -98,13 +99,14 @@ "CIP-006-6 R1", "CIP-006-6 1.1" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-deu-c5-2020": [ + "PS-02", + "PS-03" ], "apac-ind-sebi-2024": [ "PR.IP.S9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP13", "HML13" ], @@ -113,6 +115,9 @@ ], "apac-nzl-ism-3-9": [ "8.2.7.C.01" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-01.2.json b/docs/api/controls/PES-01.2.json index c1e7c5b6..3166abbd 100644 --- a/docs/api/controls/PES-01.2.json +++ b/docs/api/controls/PES-01.2.json @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -96,6 +97,10 @@ ], "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.2" + ], + "emea-deu-c5-2020": [ + "PS-01-DOAR", + "PS-03-BP1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-01.json b/docs/api/controls/PES-01.json index d358ba11..27c3bb22 100644 --- a/docs/api/controls/PES-01.json +++ b/docs/api/controls/PES-01.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ The Human Resources (HR) department maintains a current list of personnel with authorized access to organizational facilities and facilitates the implementation of physical access management controls.\n▪ Physical security controls and technologies ensure that only authorized personnel are allowed access to secure areas.\n▪ A facilities maintenance team, or similar function, manages the operation of automated physical and environmental protection controls.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to facilitate the operation of physical and environmental protection controls.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to facilitate the operation of physical and environmental protection controls. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -118,7 +118,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -260,7 +261,8 @@ "03.08.01", "03.08.02", "03.10.01.a", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "general-nist-800-171a": [ "3.10.2[a]", @@ -268,6 +270,15 @@ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", + "A.03.10.07.a.01" + ], "general-nist-csf-2-0": [ "ID.AM", "PR.AA", @@ -298,9 +309,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-sparta": [ "CM0053" ], @@ -346,14 +354,14 @@ "PE-23" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "2.B.2", @@ -391,7 +399,7 @@ "PE-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(33)" + "3.4.3.33" ], "emea-eu-nis2-annex-2024": [ "13.1.1", @@ -402,56 +410,45 @@ "13.3.2(a)", "13.3.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "PS-01" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "12.27", - "18.1", - "18.2", - "18.10" - ], - "emea-sau-cscc-1-2019": [ - "2-3" + "PS-01", + "PS-02", + "PS-03" ], "emea-sau-ecc-1-2018": [ "2-3-1", "2-3-2", - "2-3-4", "2-14-1", "2-14-2", - "2-14-3", + "2-14-3-1", + "2-14-3-2", + "2-14-3-3", + "2-14-3-5", "2-14-4" ], "emea-sau-otcc-1-2022": [ - "2-13", + "2-3-1", + "2-3-2", "2-13-1", - "2-13-1-8", - "2-13-1-9", "2-13-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-46" - ], "emea-sau-sama-csf-1-2017": [ - "3.3.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" + "3.3.2", + "3.3.2.1", + "3.3.2.3" ], "emea-esp-decree-311-2022": [ - "18" + "Article 12(6)(f)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.s.1" ], "emea-uae-niaf-2023": [ "3.2.2" @@ -468,7 +465,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0810" ], "apac-ind-sebi-2024": [ @@ -483,7 +480,7 @@ "11.1.4.1", "11.2.1.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP47", "HML47" ], @@ -493,27 +490,28 @@ ], "apac-nzl-ism-3-9": [ "5.7.4.C.01", - "8.1.10.C.01" + "8.1.10.C.01", + "20.2.16.C.01" ], "apac-sgp-mas-trm-2021": [ - "8.5.1", - "8.5.2", "8.5.5", - "8.5.6(a)", - "8.5.6(b)", - "8.5.6(c)", - "8.5.6(d)", - "8.5.6(e)", - "8.5.6(f)" + "8.5.6" ], "americas-can-osfi-b13-2022": [ "3.2.10" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.02", "03.10.01.A", - "03.10.07.A" + "03.10.07.A", + "03.10.07.A.01" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(a)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-02.1.json b/docs/api/controls/PES-02.1.json index 9b386046..1610f47f 100644 --- a/docs/api/controls/PES-02.1.json +++ b/docs/api/controls/PES-02.1.json @@ -20,11 +20,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ The Human Resources (HR) department maintains a current list of personnel with authorized access to organizational facilities and facilitates the implementation of physical access management controls.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to authorize physical access to facilities based on the position or role of the individual.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -145,6 +146,7 @@ "3.10.1" ], "general-nist-800-171-r3": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.b", @@ -152,8 +154,12 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[01]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", - "A.03.10.01.b" + "A.03.10.01.b", + "A.03.10.01.d" ], "general-nist-csf-2-0": [ "PR.AA-06" @@ -189,9 +195,6 @@ "9.3.1", "9.3.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -208,11 +211,14 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(viii)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "PE-2(1)" @@ -224,17 +230,15 @@ "7123(c)(3)(D)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(34)" - ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.4" + "3.4.3.34" ], "emea-sau-sacs-002-2022": [ - "TPC-86" + "VII.B.TPC-86" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "1502", @@ -252,13 +256,14 @@ "1502", "2422" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP04" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.B", diff --git a/docs/api/controls/PES-02.2.json b/docs/api/controls/PES-02.2.json index 438663e9..99bdcc31 100644 --- a/docs/api/controls/PES-02.2.json +++ b/docs/api/controls/PES-02.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to enforce a \"two-person rule\" for physical access by requiring two authorized individuals with separate access cards, keys or PINs, to access highly-sensitive areas (e.g., safe, high-security cage, etc.).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { diff --git a/docs/api/controls/PES-02.json b/docs/api/controls/PES-02.json index 2e33640d..a280d63e 100644 --- a/docs/api/controls/PES-02.json +++ b/docs/api/controls/PES-02.json @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -189,13 +190,15 @@ "3.10.1" ], "general-nist-800-171-r3": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.a", "03.10.01.b", "03.10.01.c", "03.10.01.d", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "general-nist-800-171a": [ "3.10.1[a]", @@ -205,10 +208,14 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", "A.03.10.01.a[01]", "A.03.10.01.a[02]", "A.03.10.01.a[03]", + "A.03.10.01.b", "A.03.10.01.c", "A.03.10.01.d", "A.03.10.07.a.01" @@ -245,9 +252,6 @@ "9.2.1", "9.3.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -288,13 +292,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PE-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.B.3.2", @@ -331,24 +338,23 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-02" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.3.34" + ], "emea-eu-nis2-annex-2024": [ "13.3.1" ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.3" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" - ], "emea-sau-otcc-1-2022": [ "2-13-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-86" + "VII.B.TPC-86" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" ], "emea-gbr-def-stan-05-138-2024": [ "1500" @@ -366,7 +372,7 @@ "11.1.2.3", "11.1.2.12" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -380,14 +386,19 @@ "apac-sgp-mas-trm-2021": [ "8.5.6(a)" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.A", "03.10.01.B", "03.10.01.C", "03.10.01.D", - "03.10.07.A" + "03.10.07.A", + "03.10.07.A.01" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-03.1.json b/docs/api/controls/PES-03.1.json index f6db4b75..a5d31713 100644 --- a/docs/api/controls/PES-03.1.json +++ b/docs/api/controls/PES-03.1.json @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -130,8 +131,14 @@ "general-nist-800-171-r3": [ "03.10.02.a", "03.10.07.a", + "03.10.07.a.01", "03.10.07.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], "general-pci-dss-4-0-1": [ "9.2", "9.2.1", @@ -161,29 +168,21 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(b)" ], - "emea-deu-c5-2020": [ - "PS-03" - ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.6", - "18.8" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-82" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.1", + "mp.if.2", + "mp.if.7" ], "apac-sgp-mas-trm-2021": [ - "5.5.6(f)" + "8.5.6(c)" + ], + "americas-arg-ppd-2018": [ + "B.2.4-3" ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", "03.10.07.A", + "03.10.07.A.01", "03.10.07.A.02" ] } diff --git a/docs/api/controls/PES-03.2.json b/docs/api/controls/PES-03.2.json index 885e3e8d..9f9ede63 100644 --- a/docs/api/controls/PES-03.2.json +++ b/docs/api/controls/PES-03.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect system components from unauthorized physical access (e.g., lockable physical casings).", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect system components from unauthorized physical access (e.g., lockable physical casings). ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -130,21 +131,11 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-07(14)" ], - "emea-isr-cmo-1-0": [ - "18.6", - "18.11" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-4" - ], "emea-sau-sacs-002-2022": [ - "TPC-46" + "VII.B.TPC-46" ], "apac-nzl-ism-3-9": [ "8.2.5.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(d)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-03.3.json b/docs/api/controls/PES-03.3.json index d2084c04..7ed5ded2 100644 --- a/docs/api/controls/PES-03.3.json +++ b/docs/api/controls/PES-03.3.json @@ -3,7 +3,7 @@ "title": "Physical Access Logs", "family": "PES", "description": "Physical access control mechanisms generate a log entry for each access attempt through controlled ingress and egress points.", - "scf_question": "Does the organization generate a log entry for each access attempt through controlled ingress and egress points?", + "scf_question": "Physical access control mechanisms generate a log entry for each access attempt through controlled ingress and egress points?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Where applicable, physical security controls and technologies are configured to generate a log entry for each access attempt through controlled ingress and egress points.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to generate a log entry for each access attempt through controlled ingress and egress points.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -167,12 +168,15 @@ ], "general-nist-800-171-r3": [ "03.10.02.a", + "03.10.07.a.02", "03.10.07.b" ], "general-nist-800-171a": [ "3.10.4" ], "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.02", "A.03.10.07.b" ], "general-nist-csf-2-0": [ @@ -252,12 +256,13 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "18.5" - ], "emea-sau-ecc-1-2018": [ "2-14-3-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -273,8 +278,13 @@ "apac-jpn-ismap": [ "11.1.2.7" ], + "americas-arg-ppd-2018": [ + "B.2.4-3", + "B.2.4-4" + ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", + "03.10.07.A.02", "03.10.07.B" ] } diff --git a/docs/api/controls/PES-03.4.json b/docs/api/controls/PES-03.4.json index c9a7c743..b1fea583 100644 --- a/docs/api/controls/PES-03.4.json +++ b/docs/api/controls/PES-03.4.json @@ -2,8 +2,8 @@ "control_id": "PES-03.4", "title": "Access To Critical Systems", "family": "PES", - "description": "Physical access control mechanisms exist to enforce physical access to critical systems or sensitive/regulated data, in addition to the physical access controls for the facility.", - "scf_question": "Does the organization enforce physical access to critical systems or sensitive/regulated data, in addition to the physical access controls for the facility?", + "description": "Physical access control mechanisms exist to enforce physical access to critical systems or sensitive and/or regulated data, in addition to the physical access controls for the facility.", + "scf_question": "Does the organization enforce physical access to critical systems or sensitive and/or regulated data, in addition to the physical access controls for the facility?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -159,6 +160,10 @@ "03.10.07.a.01", "03.10.07.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], "general-tisax-6-0-3": [ "5.3.4" ], @@ -175,28 +180,21 @@ "PE-03(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-cms-marse-2-0": [ "PE-3-IS.2" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" - ], "emea-sau-otcc-1-2022": [ "2-13-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-46", - "TPC-49" + "VII.B.TPC-46" ], "emea-gbr-def-stan-05-138-2024": [ "1502" @@ -210,7 +208,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1502" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0813", "ISM-1053", "ISM-1074", @@ -219,7 +217,7 @@ "apac-ind-sebi-2024": [ "PR.AA.S10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP10", "HML10" ], diff --git a/docs/api/controls/PES-03.json b/docs/api/controls/PES-03.json index 19f82978..b0ad0fc1 100644 --- a/docs/api/controls/PES-03.json +++ b/docs/api/controls/PES-03.json @@ -22,7 +22,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls and technologies ensure that only authorized personnel are allowed access to secure areas.\n▪ A facilities maintenance team, or similar function, manages the operation of automated physical and environmental protection controls.\n▪ Physical security controls and technologies are configured to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -112,7 +112,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -225,6 +226,7 @@ "3.10.5" ], "general-nist-800-171-r3": [ + "03.04.05", "03.10.02.a", "03.10.07.a", "03.10.07.a.01", @@ -238,12 +240,11 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[03]", + "A.03.10.02.a[01]", + "A.03.10.07.a.01", "A.03.10.07.a.02", "A.03.10.07.d" ], - "general-nist-800-172": [ - "3.1.2e" - ], "general-nist-csf-2-0": [ "PR.AA", "PR.AA-06", @@ -272,9 +273,6 @@ "9.1.2", "9.2.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -323,15 +321,18 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PE-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ "2.B.3.4", @@ -385,27 +386,22 @@ "13.3.2(b)" ], "emea-deu-c5-2020": [ - "PS-03", - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "12.27", - "18.4" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" + "PS-02-DOAR" ], "emea-sau-otcc-1-2022": [ "2-13-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-47", - "TPC-82", - "TPC-86" + "VII.B.TPC-82" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.a" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" ], "emea-uae-niaf-2023": [ "3.2.2" @@ -422,7 +418,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1296" ], "apac-ind-sebi-2024": [ @@ -443,7 +439,7 @@ "11.1.2.5", "11.1.2.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP48", "HML48" ], @@ -451,13 +447,17 @@ "HSUP40" ], "apac-sgp-mas-trm-2021": [ - "8.5.6(c)", - "5.5.6(f)" + "8.5.6(e)" + ], + "americas-arg-ppd-2018": [ + "B.2.4-1", + "B.2.4-2" ], "americas-can-osfi-b13-2022": [ "3.2.10" ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.10.02.A", "03.10.07.A", "03.10.07.A.01", diff --git a/docs/api/controls/PES-04.1.json b/docs/api/controls/PES-04.1.json index f095fdf5..54dd2493 100644 --- a/docs/api/controls/PES-04.1.json +++ b/docs/api/controls/PES-04.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to allow only authorized personnel access to secure areas.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to allow only authorized personnel access to secure areas. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -145,8 +146,13 @@ "03.10.07.a.02", "03.10.07.d" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" ], "general-pci-dss-4-0-1": [ "9.3.1.1" @@ -164,10 +170,13 @@ "SC.L3-3.13.4E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(c)" + "§ 164.310(c)" + ], + "usa-federal-irs-1075-2021": [ + "2.B.3" ], "usa-federal-dow-safeguarding-nnpi-2010": [ "8-3.a(2)" @@ -175,19 +184,18 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(3)(D)" ], - "emea-isr-cmo-1-0": [ - "18.6" - ], "emea-sau-ecc-1-2018": [ "2-14-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-5" - ], "emea-sau-sacs-002-2022": [ - "TPC-49" + "VII.B.TPC-49" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "mp.if.2", + "mp.if.7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ @@ -200,9 +208,8 @@ "11.1.5.5", "11.1.5.6" ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(e)", - "5.5.6(f)" + "apac-nzl-ism-3-9": [ + "17.9.36.C.02" ], "americas-can-itsp-10-171-2025": [ "03.08.01", diff --git a/docs/api/controls/PES-04.2.json b/docs/api/controls/PES-04.2.json index 9835df87..e35b07a7 100644 --- a/docs/api/controls/PES-04.2.json +++ b/docs/api/controls/PES-04.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to inspect personnel and their personal effects (e.g., personal property ordinarily worn or carried by the individual, including vehicles) to prevent the unauthorized exfiltration of data and technology assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { diff --git a/docs/api/controls/PES-04.3.json b/docs/api/controls/PES-04.3.json index 2272a82d..5a302e9e 100644 --- a/docs/api/controls/PES-04.3.json +++ b/docs/api/controls/PES-04.3.json @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": {} diff --git a/docs/api/controls/PES-04.json b/docs/api/controls/PES-04.json index 529c5150..5ce65261 100644 --- a/docs/api/controls/PES-04.json +++ b/docs/api/controls/PES-04.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls and technologies are primarily designed and implemented for offices, rooms and facilities that focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to identify systems, equipment and respective operating environments that require limited physical access so that appropriate physical access controls are designed and implemented for offices, rooms and facilities.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to identify systems, equipment and respective operating environments that require limited physical access so that appropriate physical access controls are designed and implemented for offices, rooms and facilities. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -160,6 +161,14 @@ "03.10.07.a.02", "03.10.07.d" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" + ], "general-pci-dss-4-0-1": [ "9.3.1.1" ], @@ -169,9 +178,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.3.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -190,14 +196,15 @@ "52.204-21(b)(1)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ + "2.B.3", "2.B.3.3" ], "usa-state-ca-ccpa-cpra-2026": [ @@ -206,21 +213,23 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(c)" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "18.6" - ], "emea-sau-ecc-1-2018": [ "2-14-3-5" ], "emea-sau-otcc-1-2022": [ "2-13-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-46" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.c" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.eq.1", + "mp.eq.2" ], "apac-jpn-ismap": [ "11.1.2.6", @@ -237,7 +246,7 @@ "11.2.9.5", "11.2.9.6" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP48", "HML48" ], @@ -248,9 +257,6 @@ "8.2.6.C.01", "8.2.6.C.02" ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(e)" - ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.02", diff --git a/docs/api/controls/PES-05.1.json b/docs/api/controls/PES-05.1.json index 31687f50..6ecc2f0f 100644 --- a/docs/api/controls/PES-05.1.json +++ b/docs/api/controls/PES-05.1.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Where applicable, physical security controls and technologies are configured to monitor for, detect and respond to physical security incidents.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to monitor physical intrusion alarms and surveillance equipment.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to monitor physical intrusion alarms and surveillance equipment. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -140,13 +141,21 @@ "NFO - PE-6(1)" ], "general-nist-800-171-r3": [ - "03.10.02.a", - "03.10.02.b" + "03.10.02.a" ], "general-nist-800-171a": [ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]" + ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[02]" + ], "general-pci-dss-4-0-1": [ "9.2.1.1" ], @@ -187,10 +196,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-06 (01)" ], - "emea-isr-cmo-1-0": [ - "18.9", - "18.11" - ], "emea-sau-cgiot-2024": [ "2-13-1" ], @@ -200,6 +205,9 @@ "emea-sau-otcc-1-2022": [ "2-13-1-2" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.b" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -212,12 +220,8 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-chn-pipl-2021": [ - "26" - ], "americas-can-itsp-10-171-2025": [ - "03.10.02.A", - "03.10.02.B" + "03.10.02.A" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-05.2.json b/docs/api/controls/PES-05.2.json index 9b9e9b15..c0ad67c1 100644 --- a/docs/api/controls/PES-05.2.json +++ b/docs/api/controls/PES-05.2.json @@ -2,8 +2,8 @@ "control_id": "PES-05.2", "title": "Monitoring Physical Access To Critical Systems", "family": "PES", - "description": "Facility security mechanisms exist to monitor physical access to critical systems or sensitive/regulated data, in addition to the physical access monitoring of the facility.", - "scf_question": "Does the organization monitor physical access to critical systems or sensitive/regulated data, in addition to the physical access monitoring of the facility?", + "description": "Facility security mechanisms exist to monitor physical access to critical systems or sensitive and/or regulated data, in addition to the physical access monitoring of the facility.", + "scf_question": "Does the organization monitor physical access to critical systems or sensitive and/or regulated data, in addition to the physical access monitoring of the facility?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -87,7 +87,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -141,6 +142,17 @@ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.02.b[01]", + "A.03.10.02.b[02]" + ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[01]" + ], "general-pci-dss-4-0-1": [ "9.2.1.1" ], @@ -159,8 +171,8 @@ "usa-federal-gsa-fedramp-5-high": [ "PE-06(04)" ], - "apac-sgp-mas-trm-2021": [ - "8.5.5" + "emea-sau-otcc-1-2022": [ + "2-13-1-7" ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", diff --git a/docs/api/controls/PES-05.json b/docs/api/controls/PES-05.json index ba9437ac..299cc78a 100644 --- a/docs/api/controls/PES-05.json +++ b/docs/api/controls/PES-05.json @@ -107,7 +107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -203,6 +204,14 @@ "A.03.10.02.b[01]", "A.03.10.02.b[02]" ], + "general-nist-800-172-r3": [ + "03.10.01E", + "03.10.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[02]", + "DS-A.03.10.02E.b" + ], "general-nist-csf-2-0": [ "DE.CM-02" ], @@ -218,9 +227,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.2.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -279,17 +285,15 @@ "13.1.2(f)", "13.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "18.8", - "18.10", - "18.11" - ], "emea-sau-cgiot-2024": [ "2-13-1" ], "emea-sau-ecc-1-2018": [ "2-14-3-2" ], + "emea-sau-otcc-1-2022": [ + "2-13-1-2" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -308,16 +312,13 @@ "apac-jpn-ismap": [ "11.1.2.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP66", "HML65" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP57" ], - "apac-sgp-mas-trm-2021": [ - "5.5.5" - ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", "03.10.02.B" diff --git a/docs/api/controls/PES-06.1.json b/docs/api/controls/PES-06.1.json index 779daf6a..8aa0a5d0 100644 --- a/docs/api/controls/PES-06.1.json +++ b/docs/api/controls/PES-06.1.json @@ -2,8 +2,8 @@ "control_id": "PES-06.1", "title": "Distinguish Visitors from On-Site Personnel", "family": "PES", - "description": "Physical access control mechanisms exist to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", - "scf_question": "Does the organization easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible?", + "description": "Physical access control mechanisms exist to easily distinguish between onsite personnel and visitors, especially in areas where sensitive and/or regulated data is accessible.", + "scf_question": "Does the organization easily distinguish between onsite personnel and visitors, especially in areas where sensitive and/or regulated data is accessible?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,7 +102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -110,7 +111,7 @@ "3.10.3" ], "general-nist-800-171-r3": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "general-nist-800-171a": [ @@ -118,6 +119,7 @@ "3.10.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.10.01.a[02]", "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], @@ -139,9 +141,6 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(ix)" ], - "emea-sau-sacs-002-2022": [ - "TPC-47" - ], "emea-gbr-def-stan-05-138-2024": [ "1503" ], @@ -158,7 +157,7 @@ "11.1.2.8" ], "americas-can-itsp-10-171-2025": [ - "03.10.02.B", + "03.10.01.A", "03.10.07.C" ] } diff --git a/docs/api/controls/PES-06.2.json b/docs/api/controls/PES-06.2.json index 9865e20e..202ddc58 100644 --- a/docs/api/controls/PES-06.2.json +++ b/docs/api/controls/PES-06.2.json @@ -3,7 +3,7 @@ "title": "Identification Requirement", "family": "PES", "description": "Physical access control mechanisms exist to requires at least one(1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility.", - "scf_question": "Does the organization require at least one (1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility?", + "scf_question": "Does the organization requires at least one(1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -109,6 +110,10 @@ "general-nist-800-171-r3": [ "03.10.07.c" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], "general-pci-dss-4-0-1": [ "9.3.2" ], @@ -125,10 +130,7 @@ "CIP-006-6 2.2" ], "emea-sau-sacs-002-2022": [ - "TPC-47" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.2 [MP.IF.2]" + "VII.B.TPC-47-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "1503" diff --git a/docs/api/controls/PES-06.3.json b/docs/api/controls/PES-06.3.json index e149779a..9cc7d173 100644 --- a/docs/api/controls/PES-06.3.json +++ b/docs/api/controls/PES-06.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Users are trained and encouraged to stop and question anyone attempting to install or remove IT assets from facilities.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict unescorted access to facilities to personnel with required security clearances, formal access authorizations and validate the need for access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict unescorted access to facilities to personnel with required security clearances, formal access authorizations and validate the need for access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,7 +100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -151,19 +152,19 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(ix)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" + ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 4.1.2", "CIP-006-6 1.2", "CIP-006-6 1.3", "CIP-006-6 2.1" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" - ], "emea-sau-sacs-002-2022": [ - "TPC-48" + "VII.B.TPC-48" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ diff --git a/docs/api/controls/PES-06.4.json b/docs/api/controls/PES-06.4.json index 5bda8ffd..82f7a86d 100644 --- a/docs/api/controls/PES-06.4.json +++ b/docs/api/controls/PES-06.4.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to automatically facilitate the maintenance and review of visitor access records.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60,7 +60,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { diff --git a/docs/api/controls/PES-06.5.json b/docs/api/controls/PES-06.5.json index 7c7d1ad7..ca3f70c1 100644 --- a/docs/api/controls/PES-06.5.json +++ b/docs/api/controls/PES-06.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to minimize the collection of Personal Data (PD) contained in visitor access records.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -96,7 +96,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { diff --git a/docs/api/controls/PES-06.6.json b/docs/api/controls/PES-06.6.json index 186a5e24..a8d71430 100644 --- a/docs/api/controls/PES-06.6.json +++ b/docs/api/controls/PES-06.6.json @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -101,6 +102,10 @@ "general-nist-800-171-r3": [ "03.10.07.c" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], "general-pci-dss-4-0-1": [ "9.3.3" ], @@ -110,9 +115,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.3.3" ], - "emea-sau-sacs-002-2022": [ - "TPC-47" - ], "emea-gbr-def-stan-05-138-2024": [ "1503" ], diff --git a/docs/api/controls/PES-06.json b/docs/api/controls/PES-06.json index 9c0a2631..77668b49 100644 --- a/docs/api/controls/PES-06.json +++ b/docs/api/controls/PES-06.json @@ -20,9 +20,9 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.\n▪ Users are trained and encouraged to stop and question anyone attempting to install or remove IT assets from facilities.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible).", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible). ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -132,7 +133,7 @@ "3.10.3" ], "general-nist-800-171-r3": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "general-nist-800-171a": [ @@ -140,9 +141,16 @@ "3.10.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.10.01.a[02]", "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.10.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "9.3.2", "9.3.3", @@ -158,9 +166,6 @@ "9.3.3", "9.3.4" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -177,10 +182,10 @@ "52.204-21(b)(1)(ix)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.B.3.1", @@ -209,24 +214,19 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(3)(D)" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "18.3", - "18.12" - ], "emea-sau-otcc-1-2022": [ "2-13-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-47" + "VII.B.TPC-47", + "VII.B.TPC-47-BP2", + "VII.B.TPC-47-BP3" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.2 [MP.IF.2]", - "8.1.7 [MP.IF.7]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ @@ -244,11 +244,10 @@ "9.4.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "8.5.6(b)", - "5.5.6(f)" + "8.5.6(b)" ], "americas-can-itsp-10-171-2025": [ - "03.10.02.B", + "03.10.01.A", "03.10.07.C" ] } diff --git a/docs/api/controls/PES-07.1.json b/docs/api/controls/PES-07.1.json index 88e1263a..72b89f21 100644 --- a/docs/api/controls/PES-07.1.json +++ b/docs/api/controls/PES-07.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize automatic voltage controls for critical system components.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize automatic voltage controls for critical system components. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -119,10 +120,10 @@ "PE-09(02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.4 [MP.IF.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-07.2.json b/docs/api/controls/PES-07.2.json index 9b0b2f4a..1ec26d02 100644 --- a/docs/api/controls/PES-07.2.json +++ b/docs/api/controls/PES-07.2.json @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -156,6 +157,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-10" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" + ], "apac-jpn-ismap": [ "11.2.2.7" ] diff --git a/docs/api/controls/PES-07.3.json b/docs/api/controls/PES-07.3.json index bb3df76d..1174a17a 100644 --- a/docs/api/controls/PES-07.3.json +++ b/docs/api/controls/PES-07.3.json @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -177,12 +178,10 @@ "13.1.2(a)" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-06" + "PS-04" ], - "emea-isr-cmo-1-0": [ - "18.14", - "18.15" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "emea-gbr-def-stan-05-138-2024": [ "2704" @@ -196,7 +195,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2704" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1123" ] } diff --git a/docs/api/controls/PES-07.4.json b/docs/api/controls/PES-07.4.json index 3033280a..2e623eb6 100644 --- a/docs/api/controls/PES-07.4.json +++ b/docs/api/controls/PES-07.4.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -168,8 +169,11 @@ "emea-eu-nis2-annex-2024": [ "13.1.2(a)" ], - "emea-isr-cmo-1-0": [ - "18.16" + "emea-isr-cmo-2-0": [ + "Appendix A, 11.1" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "apac-jpn-ismap": [ "11.2.2.6" diff --git a/docs/api/controls/PES-07.5.json b/docs/api/controls/PES-07.5.json index 3ebb7b81..e66af210 100644 --- a/docs/api/controls/PES-07.5.json +++ b/docs/api/controls/PES-07.5.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect systems from damage resulting from water leakage by providing master shutoff valves that are accessible, working properly and known to key personnel.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect systems from damage resulting from water leakage by providing master shutoff valves that are accessible, working properly and known to key personnel. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -178,13 +179,10 @@ "PE-15" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], - "emea-deu-c5-2020": [ - "PS-01" - ], - "emea-isr-cmo-1-0": [ - "18.19" + "americas-arg-ppd-2018": [ + "D.1.2-DS-1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-07.6.json b/docs/api/controls/PES-07.6.json index d81bb8ab..d4037e71 100644 --- a/docs/api/controls/PES-07.6.json +++ b/docs/api/controls/PES-07.6.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to detect the presence of water in the vicinity of critical systems and alert facility maintenance and IT personnel.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to detect the presence of water in the vicinity of critical systems and alert facility maintenance and IT personnel. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -112,9 +113,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "PE-15(01)" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.6 [MP.IF.6]" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-07.7.json b/docs/api/controls/PES-07.7.json index 8e8fece2..39ac8ba6 100644 --- a/docs/api/controls/PES-07.7.json +++ b/docs/api/controls/PES-07.7.json @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -85,6 +86,9 @@ ], "general-nist-800-160-vol-2-r1": [ "PE-09(01)" + ], + "emea-deu-c5-2020": [ + "PS-04" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-07.json b/docs/api/controls/PES-07.json index 882fdc2c..d51ae81b 100644 --- a/docs/api/controls/PES-07.json +++ b/docs/api/controls/PES-07.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power equipment and power cabling for the system from damage and destruction.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power equipment and power cabling for the system from damage and destruction. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -154,6 +155,9 @@ "general-nist-800-171-r3": [ "03.10.08" ], + "general-nist-800-171a-r3": [ + "A.03.10.08" + ], "general-nist-csf-2-0": [ "PR.IR-02" ], @@ -174,18 +178,19 @@ "PE-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-eu-nis2-annex-2024": [ "13.1.2(d)" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-06" + "PS-04" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.d" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.3 [MP.IF.3]", - "8.1.4 [MP.IF.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "apac-jpn-ismap": [ "11.2.2", @@ -201,12 +206,6 @@ "8.3.4.C.02", "8.3.5.C.01" ], - "apac-sgp-mas-trm-2021": [ - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" - ], "americas-can-itsp-10-171-2025": [ "03.10.08" ] diff --git a/docs/api/controls/PES-08.1.json b/docs/api/controls/PES-08.1.json index 3a96765c..6fb891cd 100644 --- a/docs/api/controls/PES-08.1.json +++ b/docs/api/controls/PES-08.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire detection devices/systems that activate automatically and notify organizational personnel and emergency responders in the event of a fire.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire detection devices/systems that activate automatically and notify organizational personnel and emergency responders in the event of a fire. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -134,14 +135,10 @@ "PE-13(1)" ], "emea-deu-c5-2020": [ - "PS-05" - ], - "emea-isr-cmo-1-0": [ - "18.17" + "PS-03-BP5" ], "apac-sgp-mas-trm-2021": [ - "8.5.3", - "8.5.4" + "8.5.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-08.2.json b/docs/api/controls/PES-08.2.json index 6d119f83..86e4278f 100644 --- a/docs/api/controls/PES-08.2.json +++ b/docs/api/controls/PES-08.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize fire suppression devices/systems that provide automatic notification of any activation to organizational personnel and emergency responders.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize fire suppression devices/systems that provide automatic notification of any activation to organizational personnel and emergency responders. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -132,10 +133,7 @@ "PE-13(3)" ], "emea-deu-c5-2020": [ - "PS-05" - ], - "emea-isr-cmo-1-0": [ - "18.17" + "PS-03-BP5" ], "emea-gbr-def-stan-05-138-2024": [ "2704" @@ -148,6 +146,9 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2704" + ], + "apac-sgp-mas-trm-2021": [ + "8.5.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-08.3.json b/docs/api/controls/PES-08.3.json index 6a12bbb7..5c62940a 100644 --- a/docs/api/controls/PES-08.3.json +++ b/docs/api/controls/PES-08.3.json @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -130,9 +131,6 @@ ], "usa-federal-cms-marse-2-0": [ "PE-13(2)" - ], - "emea-deu-c5-2020": [ - "PS-05" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-08.json b/docs/api/controls/PES-08.json index 3c51aa37..bc7811f1 100644 --- a/docs/api/controls/PES-08.json +++ b/docs/api/controls/PES-08.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire suppression and detection devices/systems for the system that are supported by an independent energy source.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire suppression and detection devices/systems for the system that are supported by an independent energy source. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -172,21 +173,22 @@ "PE-13" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-05" + "PS-03-BP1", + "PS-03-BP2", + "PS-03-BP4", + "PS-03-BP6" ], - "emea-isr-cmo-1-0": [ - "18.17" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.5 [MP.IF.5]" + "emea-isr-cmo-2-0": [ + "Appendix A, 11.2" ], "apac-sgp-mas-trm-2021": [ - "8.5.3", - "8.5.4" + "8.5.3" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-09.1.json b/docs/api/controls/PES-09.1.json index 38bfef88..78975488 100644 --- a/docs/api/controls/PES-09.1.json +++ b/docs/api/controls/PES-09.1.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to trigger an alarm or notification of temperature and humidity changes that be potentially harmful to personnel or equipment.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to trigger an alarm or notification of temperature and humidity changes that be potentially harmful to personnel or equipment. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -118,13 +119,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "PE-14(02)" - ], - "emea-deu-c5-2020": [ - "PS-06", - "PS-07" - ], - "emea-isr-cmo-1-0": [ - "18.18" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-09.json b/docs/api/controls/PES-09.json index 9f5eaf2f..ea8ccec5 100644 --- a/docs/api/controls/PES-09.json +++ b/docs/api/controls/PES-09.json @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -175,17 +176,14 @@ "PE-14" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-eu-nis2-annex-2024": [ "13.1.2(f)" ], "emea-deu-c5-2020": [ - "PS-06", - "PS-07" - ], - "emea-isr-cmo-1-0": [ - "18.18" + "PS-03-BP3", + "PS-03-DOAR" ], "emea-gbr-def-stan-05-138-2024": [ "2704" diff --git a/docs/api/controls/PES-10.json b/docs/api/controls/PES-10.json index 75fc9f27..52ab6da3 100644 --- a/docs/api/controls/PES-10.json +++ b/docs/api/controls/PES-10.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -165,6 +166,17 @@ "general-nist-800-171-r2": [ "NFO - PE-16" ], + "general-nist-800-172-r3": [ + "03.10.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.02E.a[01]", + "A.03.10.02E.ODP[01]", + "DS-A.03.10.02E.a[02]", + "DS-A.03.10.02E.a[03]", + "A.03.10.02E.ODP[02]", + "DS-A.03.10.02E.a[04]" + ], "general-tisax-6-0-3": [ "3.1.3", "5.3.3" @@ -200,8 +212,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-16" ], - "emea-isr-cmo-1-0": [ - "18.20" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" ], "apac-jpn-ismap": [ "11.1.6", @@ -214,7 +230,7 @@ "11.1.6.7" ], "apac-sgp-mas-trm-2021": [ - "5.5.6(f)" + "8.5.6(f)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-11.json b/docs/api/controls/PES-11.json index 95057350..9df745bb 100644 --- a/docs/api/controls/PES-11.json +++ b/docs/api/controls/PES-11.json @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -197,12 +198,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-17" ], - "emea-deu-c5-2020": [ - "PS-02" - ], - "emea-isr-cmo-1-0": [ - "18.21" - ], "emea-gbr-def-stan-05-138-2024": [ "2312" ], diff --git a/docs/api/controls/PES-12.1.json b/docs/api/controls/PES-12.1.json index 80683bab..ae7064e6 100644 --- a/docs/api/controls/PES-12.1.json +++ b/docs/api/controls/PES-12.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power and telecommunications cabling carrying data or supporting information services from interception, interference or damage.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power and telecommunications cabling carrying data or supporting information services from interception, interference or damage. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -230,11 +231,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-04" ], - "emea-isr-cmo-1-0": [ - "9.15", - "18.13" + "emea-deu-c5-2020": [ + "PS-04" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0181", "ISM-0187", "ISM-0194", @@ -275,7 +275,10 @@ "ISM-1718", "ISM-1719", "ISM-1720", - "ISM-1721" + "ISM-1721", + "ISM-1820", + "ISM-1821", + "ISM-1822" ], "apac-jpn-ismap": [ "11.2.3", diff --git a/docs/api/controls/PES-12.2.json b/docs/api/controls/PES-12.2.json index 8b4cb7a3..28e935d4 100644 --- a/docs/api/controls/PES-12.2.json +++ b/docs/api/controls/PES-12.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict access to printers and other system output devices to prevent unauthorized individuals from obtaining the output.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict access to printers and other system output devices to prevent unauthorized individuals from obtaining the output. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -176,12 +177,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-05" ], - "emea-isr-cmo-1-0": [ - "18.7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1036" ], + "apac-nzl-ism-3-9": [ + "11.8.9.C.01" + ], "americas-can-itsp-10-171-2025": [ "03.10.07.E" ] diff --git a/docs/api/controls/PES-12.json b/docs/api/controls/PES-12.json index 3cde2aec..c67507f5 100644 --- a/docs/api/controls/PES-12.json +++ b/docs/api/controls/PES-12.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to locate system components within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to locate system components within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -125,10 +126,10 @@ "PE-18" ], "general-iso-27002-2022": [ - "7.12", "7.3", "7.5", - "7.8" + "7.8", + "7.12" ], "general-iso-27017-2015": [ "11.1.4", @@ -197,8 +198,9 @@ "03.10.07.e", "03.10.08" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.10.07.e", + "A.03.10.08" ], "general-pci-dss-4-0-1": [ "9.2.2", @@ -266,15 +268,15 @@ "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.10" ], - "emea-isr-cmo-1-0": [ - "18.7", - "18.13", - "18.22" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.e" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.3 [MP.IF.3]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1644" ], "apac-jpn-ismap": [ diff --git a/docs/api/controls/PES-13.json b/docs/api/controls/PES-13.json index e1cb1898..1856fe42 100644 --- a/docs/api/controls/PES-13.json +++ b/docs/api/controls/PES-13.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect the system from information leakage due to electromagnetic signals emanations.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect the system from information leakage due to electromagnetic signals emanations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -92,7 +93,7 @@ "general-nist-800-82-r3": [ "PE-19" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0246", "ISM-0249", "ISM-0250" diff --git a/docs/api/controls/PES-14.json b/docs/api/controls/PES-14.json index ff2951c8..f682af3c 100644 --- a/docs/api/controls/PES-14.json +++ b/docs/api/controls/PES-14.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to employ asset location technologies that track and monitor the location and movement of organization-defined assets within organization-defined controlled areas.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { diff --git a/docs/api/controls/PES-15.json b/docs/api/controls/PES-15.json index 4778fc6b..50efca9e 100644 --- a/docs/api/controls/PES-15.json +++ b/docs/api/controls/PES-15.json @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { diff --git a/docs/api/controls/PES-16.json b/docs/api/controls/PES-16.json index 288b379b..9908efef 100644 --- a/docs/api/controls/PES-16.json +++ b/docs/api/controls/PES-16.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to mark system hardware components indicating the impact or classification level of the information permitted to be processed, stored or transmitted by the hardware component.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -110,7 +111,7 @@ "emea-sau-cgiot-2024": [ "2-6-1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1107", "ISM-1216", "ISM-1217", diff --git a/docs/api/controls/PES-17.json b/docs/api/controls/PES-17.json index 68f4893a..cec94bea 100644 --- a/docs/api/controls/PES-17.json +++ b/docs/api/controls/PES-17.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to automatically monitor physical proximity to robotic or autonomous platforms to reduce applied force or stop the operation when sensors indicate a potentially dangerous scenario.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": {} diff --git a/docs/api/controls/PES-18.json b/docs/api/controls/PES-18.json index 8deb5825..978c2b40 100644 --- a/docs/api/controls/PES-18.json +++ b/docs/api/controls/PES-18.json @@ -2,8 +2,8 @@ "control_id": "PES-18", "title": "On-Site Client Segregation", "family": "PES", - "description": "Mechanisms exist to ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces.", - "scf_question": "Does the organization ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces?", + "description": "Mechanisms exist to ensure client-specific sensitive and/or regulated data is isolated from other data when client-specific sensitive and/or regulated data is processed or stored within multi-client workspaces.", + "scf_question": "Does the organization ensure client-specific sensitive and/or regulated data is isolated from other data when client-specific sensitive and/or regulated data is processed or stored within multi-client workspaces?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -92,13 +92,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { - "general-nist-800-172": [ - "3.13.4e" - ], "general-tisax-6-0-3": [ "5.3.4", "8.1.8" @@ -107,7 +105,8 @@ "SC.L3-3.13.4E" ], "emea-sau-sacs-002-2022": [ - "TPC-38" + "VII.B.TPC-38", + "VII.B.TPC-49" ] } } \ No newline at end of file diff --git a/docs/api/controls/PES-19.json b/docs/api/controls/PES-19.json index 0e44b1c1..80b87ed5 100644 --- a/docs/api/controls/PES-19.json +++ b/docs/api/controls/PES-19.json @@ -20,7 +20,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to maintain an accurate inventory of all physical access devices (e.g., RFID cards, access fobs, door keys, etc.).", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { diff --git a/docs/api/controls/PRI-01.1.json b/docs/api/controls/PRI-01.1.json index fac9297a..b0147128 100644 --- a/docs/api/controls/PRI-01.1.json +++ b/docs/api/controls/PRI-01.1.json @@ -3,7 +3,7 @@ "title": "Chief Privacy Officer (CPO)", "family": "PRI", "description": "Mechanisms exist to appoints a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program.", - "scf_question": "Does the organization have a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program?", + "scf_question": "Does the organization appoints a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is formally assigned as the Chief Privacy Officer (CPO), or similar role, to lead the organization's data privacy program. This individual may be assigned to multiple data privacy-related roles.\n▪ The CPO, or similar role, identifies appropriate data privacy controls that Technology Assets, Applications and/or Services (TAAS) and third-parties must adhere to, in addition to applicable statutory, regulatory and/or contractual obligations.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ A Chief Privacy Officer (CPO) or similar role, has the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -89,7 +90,7 @@ "5.3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.PO-P3" @@ -124,14 +125,11 @@ "general-oecd-privacy-principles-2010": [ "8" ], - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(a)(1)(i)" + "§ 164.530(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "PM-19" @@ -139,61 +137,36 @@ "usa-federal-cms-marse-2-0": [ "AR-1.a" ], - "emea-deu-fdpa-2017": [ - "Sec 4d", - "Sec 4f", - "Sec 4g" - ], - "emea-hun-isdfi-2011": [ - "24" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "30" - ], - "emea-pol-act-29-1997": [ - "46" - ], - "emea-qat-pdppl-2020": [ - "8.1" - ], - "emea-rus-federal-law-27-2006": [ - "23" - ], - "emea-zaf-popia-2013": [ - "55", - "56" - ], - "apac-chn-pipl-2021": [ - "9", - "52" - ], - "apac-jpn-ppi-2020": [ - "21" + "apac-phl-dpa-2012": [ + "VI.21", + "VI.21(a)", + "VI.21(b)" ], "apac-sgp-pdpa-2012": [ - "11" + "3.11(3)", + "3.11(4)" ], "apac-kor-pipa-2011": [ - "31" - ], - "americas-bra-lgpd-2018": [ - "6.8", - "6.10" + "IV.31(1)", + "IV.31(2)", + "IV.31(2)1", + "IV.31(2)2", + "IV.31(2)3", + "IV.31(2)4", + "IV.31(2)5", + "IV.31(2)6", + "IV.31(2)7", + "IV.31(3)", + "IV.31(4)", + "IV.31(5)" + ], + "americas-can-pipeda-2000": [ + "P1-4.1", + "P1-4.1.1", + "P1-4.1.2" ], "americas-chl-act-19628-1999": [ - "7", - "11" - ], - "americas-col-law-1581-2012": [ - "17", - "18" + "I.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-01.10.json b/docs/api/controls/PRI-01.10.json index e8b16e4b..281b5cdf 100644 --- a/docs/api/controls/PRI-01.10.json +++ b/docs/api/controls/PRI-01.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to strictly govern financial incentives offered to data subjects for Personal Data (PD) to ensure compliance with applicable legal and regulatory requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-01.11.json b/docs/api/controls/PRI-01.11.json index 9718f6cd..d8861999 100644 --- a/docs/api/controls/PRI-01.11.json +++ b/docs/api/controls/PRI-01.11.json @@ -54,7 +54,8 @@ "MT-12", "MT-13", "MT-14", - "MT-15" + "MT-15", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -74,7 +75,7 @@ "general-iso-29100-2024": [ "6.5", "6.8", - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "TS-1.14" @@ -90,9 +91,6 @@ "general-nist-800-37-r2": [ "TASK P-16" ], - "general-scf-dpmp-2025": [ - "1.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(D)" ], @@ -156,6 +154,14 @@ "usa-state-il-pipa-2006": [ "45(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.1", + "603A.510.3(b)", + "603A.525.1", + "603A.525.1(a)", + "603A.525.1(b)", + "603A.525.2(c)" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(a)", "899-bb.2(b)(ii)(A)" @@ -194,6 +200,428 @@ "2433(a)(2)(C)", "2447(a)(2)" ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(g)" + ], + "emea-eu-psd2-2015": [ + "94(1)", + "94(2)" + ], + "emea-aut-dpa-2018": [ + "§ 1(1)", + "§ 1(2)", + "§ 1(3)", + "§ 1(4)", + "§ 6(2)", + "§ 8(1)", + "§ 8(2)", + "§ 8(3)", + "§ 37(1)", + "§ 37(5)", + "§ 37(8)", + "§ 45(3)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(2)", + "Title 2, Chapter II, Art. 28", + "Title 2, Chapter II, Art. 32(1)", + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter II, Art. 34(1)", + "Title 2, Chapter III, Art. 39(3)", + "Title 2, Chapter III, Art. 45(3)", + "Title 4, Chapter III, Section 2, Art. 194", + "Title 4, Chapter III, Section 2, Art. 195", + "Title 4, Chapter III, Section 2, Art. 196", + "Title 4, Chapter III, Section 2, Art. 197", + "Title 4, Chapter III, Section 3, Art. 202(1)", + "Title 4, Chapter III, Section 3, Art. 202(2)" + ], + "emea-deu-fdpa-2017": [ + "2.2.32(1)1", + "2.2.32(1)2", + "2.2.32(1)3", + "2.2.32(1)4", + "2.2.32(1)5", + "2.2.32(2)", + "2.2.32(3)", + "2.2.33(1)1(a)", + "2.2.33(1)1(b)", + "2.2.33(1)2", + "2.2.33(2)", + "2.2.35(3)", + "2.2.36", + "3.1.47.1", + "3.2.48(2)", + "3.2.48(2)1", + "3.2.48(2)5", + "3.3.57(4)", + "3.3.58(3)", + "3.3.58(3)1", + "3.3.58(3)2", + "3.3.58(3)3", + "3.3.58(4)", + "3.3.59(3)", + "3.4.71(1)", + "3.4.74(1)", + "3.4.74(2)", + "3.5.80(1)", + "3.5.80(1)1", + "3.5.80(1)2", + "3.5.80(1)3", + "3.5.80(1)4", + "3.5.80(1)5", + "3.5.80(2)", + "3.5.80(3)", + "3.7.83(2)", + "3.7.83(3)", + "3.7.83(4)", + "3.7.83(5)" + ], + "emea-grc-pirppd-1997": [ + "B.4.1.a", + "B.4.1.b", + "B.7.2.b", + "B.7.2.c", + "B.7.2.d", + "B.7.2.e", + "B.7.2.f", + "B.7.2.g", + "B.9.2.f", + "C.11.4", + "C.11.5", + "C.12.3" + ], + "emea-hun-act-cxii-2011": [ + "II.5.6(1)(a)", + "II.5.6(5)(b)", + "II.6.7(1)", + "II.8.9(1)(c)", + "II.8.9(1)(d)", + "II.10.11(1)(a)", + "II.13.16(1)", + "II.13.17(3)", + "II.13.17(4)", + "II.13.17(5)", + "II.14.20(4)(e)", + "II.14.20(4)(f)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)", + "II.15.21(3)", + "II.15.21(7)", + "II.18.24(3)" + ], + "emea-irl-dpa-2018": [ + "s.71", + "s.94" + ], + "emea-isr-ppl-5741-2025": [ + "s.1", + "s.2", + "s.2A", + "s.3", + "s.16" + ], + "emea-ita-pdpc-2018": [ + "Article 75(1)", + "Article 102(1)", + "Article 102(2)(a)", + "Article 102(2)(b)", + "Article 102(2)(c)", + "Article 106(1)", + "Article 106(2)(a)", + "Article 106(2)(b)", + "Article 106(2)(c)", + "Article 106(2)(d)", + "Article 106(2)(g)", + "Article 106(2)(h)", + "Article 106(2)(i)", + "Article 126(1)", + "Article 126(2)", + "Article 126(3)", + "Article 126(4)" + ], + "emea-ken-pda-2019": [ + "IV.25(b)", + "IV.25(d)", + "IV.26", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(e)", + "IV.28(2)(f)", + "IV.28(2)(f)(i)", + "IV.28(2)(f)(ii)", + "IV.28(2)(f)(iii)", + "IV.28(3)", + "IV.33(2)", + "IV.33(3)", + "IV.33(3)(a)", + "IV.33(3)(b)", + "IV.33(3)(c)", + "IV.33(3)(d)", + "IV.33(3)(e)", + "IV.34(1)(c)", + "IV.34(1)(d)", + "IV.34(2)(a)", + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.35(2)(c)" + ], + "emea-nga-dpr-2019": [ + "2.4(a)", + "2.4(b)", + "2.6", + "2.8", + "2.9", + "2.12(b)", + "2.12(c)", + "2.12(d)", + "2.12(e)", + "2.12(f)", + "3.1(3)", + "3.1(3)(a)" + ], + "emea-qat-pdppl-2020": [ + "2.4", + "2.6.3", + "3.8.1", + "3.8.2", + "3.8.3", + "3.8.4", + "3.10", + "3.11.1", + "3.11.6", + "3.13", + "4.17.3", + "4.17.4", + "4.17.5" + ], + "emea-rus-152-fz-2025": [ + "Art. 5", + "Art. 6", + "Art. 11", + "Art. 18.1" + ], + "emea-srb-act-9-2018": [ + "II.5", + "II.5(1)", + "II.5(2)", + "II.5(3)", + "II.5(4)", + "II.5(5)", + "II.5(6)", + "II.6", + "II.12", + "III.1.21(1)", + "III.1.22(1)", + "III.2.24-4", + "III.2.24-4(1)", + "III.2.24-4(2)", + "III.2.24-4(3)", + "III.2.24-4(4)", + "III.2.25-1", + "III.2.25-1(1)", + "III.2.25-1(2)", + "III.2.25-1(3)", + "III.2.25-1(4)", + "III.2.25-1(5)", + "III.2.25-2", + "III.2.25-2(1)", + "III.2.25-2(2)", + "III.2.25-2(3)", + "III.2.25-2(4)", + "III.2.25-3", + "III.2.25-3(1)", + "III.2.25-3(2)", + "III.2.25-3(3)", + "III.2.25-3(4)", + "III.2.25-3(5)", + "III.2.28", + "III.2.28(1)", + "III.2.28(2)", + "III.2.28(3)", + "III.2.28(4)", + "III.2.28(5)", + "III.3.31(1)", + "III.3.31(2)", + "III.3.31(3)", + "III.3.31(4)", + "III.3.32(1)", + "III.3.32(2)", + "III.3.34(1)", + "III.3.34(2)", + "III.3.34(3)", + "III.3.34(4)", + "III.3.34(5)", + "III.4.38(1)", + "III.4.38(2)", + "III.4.38(3)" + ], + "emea-zaf-popia-2013": [ + "2.5(1)", + "2.5(1)(a)", + "2.5(1)(a)(i)", + "2.5(1)(a)(ii)", + "2.5(1)(b)", + "2.5(1)(c)", + "2.5(1)(d)", + "2.5(1)(e)", + "2.5(1)(e)(i)", + "2.5(1)(e)(ii)", + "2.5(1)(f)", + "2.5(1)(g)", + "2.5(1)(h)", + "2.5(1)(i)", + "3.A.2.9(1)", + "3.A.2.9(1)(a)", + "3.A.2.9(1)(b)", + "3.A.2.10", + "3.A.2.11(2)(a)", + "3.A.2.12(2)", + "3.A.2.12(2)(a)", + "3.A.2.12(2)(b)", + "3.A.2.12(2)(c)", + "3.A.2.12(2)(d)", + "3.A.2.12(2)(d)(i)", + "3.A.2.12(2)(d)(ii)", + "3.A.2.12(2)(d)(iii)", + "3.A.2.12(2)(d)(iv)", + "3.A.2.12(2)(d)(v)", + "3.A.2.12(2)(e)", + "3.A.2.12(2)(f)", + "3.A.6.17", + "3.A.6.18(1)", + "3.A.6.18(1)(a)", + "3.A.6.18(1)(b)", + "3.A.6.18(1)(c)", + "3.A.6.18(1)(d)", + "3.A.6.18(1)(e)", + "3.A.6.18(1)(f)", + "3.A.6.18(1)(g)", + "3.A.6.18(1)(h)", + "3.A.6.18(1)(h)(i)", + "3.A.6.18(1)(h)(ii)", + "3.A.6.18(1)(h)(iii)", + "3.A.6.18(1)(h)(iv)", + "3.A.6.18(1)(h)(v)", + "3.A.6.18(2)", + "3.A.6.18(2)(a)", + "3.A.6.18(2)(b)", + "3.A.6.18(3)", + "3.A.6.18(4)", + "3.A.6.18(4)(a)", + "3.A.6.18(4)(b)", + "3.A.6.18(4)(c)", + "3.A.6.18(4)(c)(i)", + "3.A.6.18(4)(c)(ii)", + "3.A.6.18(4)(c)(iii)", + "3.A.6.18(4)(c)(iv)", + "3.A.6.18(4)(d)", + "3.A.6.18(4)(e)", + "3.A.6.18(4)(f)", + "3.A.6.18(4)(f)(i)", + "3.A.6.18(4)(f)(ii)", + "3.A.7.20(1)", + "3.A.7.20(1)(a)", + "3.A.7.20(1)(b)" + ], + "emea-che-fadp-2025": [ + "2.1.6.1", + "2.1.6.2", + "2.1.7.1", + "4.25.6" + ], + "emea-gbr-dpa-2018": [ + "Section 45(4)", + "Section 45(4)(a)", + "Section 45(4)(b)", + "Section 45(4)(c)", + "Section 45(4)(e)", + "Section 47(2)" + ], + "apac-aus-privacy-principles-2026": [ + "1.1.2", + "2.3.1", + "2.3.2", + "2.3.5", + "2.3.7", + "2.4.1", + "2.4.1.a", + "2.4.1.b", + "2.4.2", + "2.4.3", + "2.4.3.a", + "2.4.3.b", + "2.4.4", + "3.9.1", + "3.9.1.a", + "3.9.1.b", + "5.12.7", + "5.12.8", + "5.12.8.a", + "5.12.8.b" + ], + "apac-aus-cop-sitc-2020": [ + "5" + ], + "apac-chn-data-security-law-2021": [ + "Article 33" + ], + "apac-chn-csnip-2012": [ + "I", + "II", + "VI" + ], + "apac-chn-pipl-2021": [ + "Article 5", + "Article 7", + "Article 10", + "Article 26", + "Article 27" + ], + "apac-hkg-pdo-2022": [ + "28(1)", + "28(2)", + "28(3)", + "28(4)", + "28(4)(II)", + "28(5)", + "28(6)", + "28(6)(a)", + "28(6)(b)", + "29", + "29(a)", + "29(b)", + "Schedule 1 - 1(1)(a)", + "Schedule 1 - 1(1)(b)", + "Schedule 1 - 1(1)(c)", + "Schedule 1 - 1(2)(a)", + "Schedule 1 - 1(2)(b)" + ], + "apac-ind-privacy-rules-2011": [ + "4(v)", + "8(1)", + "8(4)" + ], + "apac-jpn-appi-2020": [ + "IV.1.17(1)", + "IV.1.26-2(1)", + "IV.2.35-2(7)", + "IV.2.35-2(8)", + "IV.2.35-3(1)", + "IV.3.36(1)", + "IV.3.36(2)", + "IV.3.36(3)", + "IV.3.36(4)", + "IV.3.36(5)", + "IV.3.36(6)", + "IV.3.37", + "IV.3.38", + "IV.3.39", + "IV.5.54" + ], "apac-jpn-ismap": [ "7.1.1.12", "18.1.4", @@ -203,6 +631,171 @@ "18.1.4.4", "18.1.4.5", "18.1.4.6" + ], + "apac-mys-pdpa-2010": [ + "5(1)", + "5(1)(a)", + "5(1)(b)", + "5(1)(c)", + "5(1)(d)", + "5(1)(e)", + "5(1)(f)", + "5(1)(g)", + "130(1)", + "130(1)(a)", + "130(1)(b)", + "130(2)", + "130(2)(a)", + "130(2)(a)(i)", + "130(2)(a)(ii)", + "130(2)(b)", + "130(2)(c)", + "130(2)(d)", + "130(3)", + "130(4)", + "130(5)", + "130(5)(a)", + "130(5)(b)", + "130(6)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.4", + "3.1.22.4(a)", + "3.1.22.4(b)", + "3.1.22.4(b)(i)", + "3.1.22.4(b)(ii)", + "3.1.22.5", + "3.1.22.5(b)", + "4.1.47(1)", + "4.1.47(1)(a)", + "4.1.47(1)(b)" + ], + "apac-phl-dpa-2012": [ + "III.11", + "III.11(b)", + "III.11(d)" + ], + "apac-sgp-pdpa-2012": [ + "3.11(1)", + "4.1.14(2)(a)", + "4.1.14(2)(b)", + "4.1.15A(4)(c)", + "4.1.15A(5)(c)", + "9.3.46(2)(a)", + "9.3.46(2)(b)", + "9.3.47(2)" + ], + "apac-kor-pipa-2011": [ + "I.3(1)", + "I.3(2)", + "I.3(3)", + "I.3(4)", + "I.3(5)", + "I.3(6)", + "I.3(7)", + "I.3(8)", + "I.4", + "I.4.1", + "I.4.2", + "I.4.3", + "I.4.4", + "I.4.5", + "III.2.23", + "III.2.24(1)", + "III.2.24(1)1", + "III.2.24(1)2", + "III.2.24(2)", + "III.2.24(3)", + "III.2.24(4)", + "IV.29", + "V.38(3)", + "V.38(4)", + "V.38(5)", + "VIII.60" + ], + "apac-twn-pdpa-2025": [ + "I.5" + ], + "americas-arg-ppd-2018": [ + "A", + "A.1.1", + "A.1.2", + "A.1.3", + "A.2.2-1", + "A.2.2-2" + ], + "americas-bhs-dpa-2003": [ + "II.5(1)(a)", + "II.5(1)(b)", + "II.5(1)(c)", + "II.5(1)(d)", + "II.5(1)(e)", + "II.5(1)(f)", + "II.5(2)", + "II.5(3)", + "II.8(4)", + "V.43(4)(d)", + "V.43(4)(e)" + ], + "americas-bra-lgpd-2018": [ + "II.I.10", + "II.I.10.I", + "II.I.10.II", + "II.I.10.II.1", + "II.I.10.II.2", + "II.II.11.I", + "II.II.11.II", + "II.II.11.II(a)", + "II.II.11.II(b)", + "II.II.11.II(c)", + "II.II.11.II(d)", + "II.II.11.II(e)", + "II.II.11.II(f)", + "II.II.11.II(g)", + "II.II.11.II(g)1", + "II.II.11.II(g)2", + "II.II.11.II(g)3", + "II.II.11.II(g)4", + "III.21" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(a)", + "P3-4.3.3", + "P4-4.4.1", + "P4-4.4.2" + ], + "americas-chl-act-19628-1999": [ + "I.7", + "I.11" + ], + "americas-col-law-1581-2012": [ + "II.4(d)", + "II.4(g)", + "VI.17(a)", + "VI.17(e)" + ], + "americas-mex-fdpa-2010": [ + "II.6", + "II.7", + "II.9", + "II.10", + "II.10.I", + "II.10.II", + "II.10.III", + "II.10.IV", + "II.10.V", + "II.10.VI", + "II.10.VII", + "III.26", + "III.26.I", + "III.26.II", + "III.26.III", + "III.26.IV", + "III.26.V", + "III.26.VI", + "III.26.VII", + "IV.34", + "IV.35" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-01.12.json b/docs/api/controls/PRI-01.12.json new file mode 100644 index 00000000..2bd2262c --- /dev/null +++ b/docs/api/controls/PRI-01.12.json @@ -0,0 +1,98 @@ +{ + "control_id": "PRI-01.12", + "title": "Privacy-Aware Design", + "family": "PRI", + "description": "Mechanisms exist to formally incorporate the organization's data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "scf_question": "Does the organization formally incorporate its data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to formally incorporate the organization's data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Privacy by design principles (basic data minimization practices)\n∙ NIST Privacy Framework reference", + "small": "∙ Privacy by design checklist for new systems\n∙ NIST Privacy Framework or GDPR Art. 25 alignment", + "medium": "∙ Privacy by design and by default program\n∙ DPIA for new systems\n∙ Privacy engineering practices in SDLC", + "large": "∙ Enterprise privacy engineering program\n∙ Privacy by design requirements in system development lifecycle\n∙ DPIA for new data processing", + "enterprise": "∙ Enterprise privacy engineering framework\n∙ Automated privacy design reviews in SDLC\n∙ DPIA for all new data processing\n∙ Privacy technology stack (e.g., OneTrust)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-4", + "R-AM-2", + "R-AM-3", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-28" + ], + "errata": "- new control - NIST Privacy Framework", + "family_name": "Data Privacy", + "crosswalks": { + "general-nist-privacy-framework-1-0": [ + "CT.DM-P10" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/PRI-01.2.json b/docs/api/controls/PRI-01.2.json index 8b855321..a0d5aba0 100644 --- a/docs/api/controls/PRI-01.2.json +++ b/docs/api/controls/PRI-01.2.json @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -85,15 +86,9 @@ "general-nist-800-82-r3": [ "PT-05(02)" ], - "general-scf-dpmp-2025": [ - "4.0" - ], "usa-federal-cms-marse-2-0": [ "TR-2", "TR-2.c" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 8" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-01.3.json b/docs/api/controls/PRI-01.3.json index 1e9a199b..006bd0dc 100644 --- a/docs/api/controls/PRI-01.3.json +++ b/docs/api/controls/PRI-01.3.json @@ -3,7 +3,7 @@ "title": "Dissemination of Data Privacy Program Information", "family": "PRI", "description": "Mechanisms exist to: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes.", - "scf_question": "Does the organization: \n (1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n (2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n (3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n (4) Inform data subjects when changes are made to the privacy notice and the nature of such changes?", + "scf_question": "Does the organization: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -139,10 +140,6 @@ "general-oecd-privacy-principles-2010": [ "6" ], - "general-scf-dpmp-2025": [ - "1.0", - "11.2" - ], "usa-federal-omb-fipps-1973": [ "8" ], @@ -157,12 +154,12 @@ "usa-state-va-cdpa-2023": [ "59.1-581.A.2" ], - "apac-aus-privacy-principles-2026": [ - "APP 1" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2" ], - "apac-chn-pipl-2021": [ - "9", - "48" + "apac-jpn-appi-2020": [ + "IV.5.53(3)" ], "apac-jpn-ismap": [ "5.1.1" diff --git a/docs/api/controls/PRI-01.4.json b/docs/api/controls/PRI-01.4.json index 9edea0ab..56f489ca 100644 --- a/docs/api/controls/PRI-01.4.json +++ b/docs/api/controls/PRI-01.4.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Data/process owners work with IT and/or cybersecurity personnel and Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ A Data Protection Officer (DPO) is appointed:\n(1) Based on professional qualifications; and\n(2) To be involved in all issues related to how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -76,23 +76,21 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.PO-P3", "CT.PO-P2", "CM.PO-P2" ], - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(a)(1)(ii)" + "§ 164.530(a)(1)(ii)" ], "emea-eu-gdpr-2016": [ "Article 27.1", @@ -124,69 +122,171 @@ "Article 39.1(e)", "Article 39.2" ], + "emea-aut-dpa-2018": [ + "§ 5(1)", + "§ 57(1)", + "§ 57(2)", + "§ 57(3)", + "§ 57(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 5, Art. 63", + "Title 2, Chapter IV, Section 5, Art. 64", + "Title 2, Chapter IV, Section 5, Art. 65", + "Title 4, Chapter II, Art. 190", + "Title 4, Chapter II, Art. 191", + "Title 4, Chapter II, Art. 192" + ], + "emea-deu-fdpa-2017": [ + "2.1.1.22(2)4", + "2.3.38(1)", + "2.3.38(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.18.24(1)(a)", + "II.18.24(1)(b)", + "II.18.24(1)(c)", + "II.18.24(2)", + "II.18.24(2)(a)", + "II.18.24(2)(b)", + "II.18.24(2)(c)", + "II.18.24(2)(d)", + "II.18.24(2)(e)", + "II.18.24(2)(f)" + ], + "emea-irl-dpa-2018": [ + "s.88" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B1", + "s.17B2" + ], + "emea-ita-pdpc-2018": [ + "Article 2-q(1)" + ], "emea-ken-pda-2019": [ - "24(1)", - "24(1)(a)", - "24(1)(b)", - "24(1)(c)", - "24(2)", - "24(3)", - "24(4)", - "24(5)", - "24(6)", - "24(7)(a)", - "24(7)(b)", - "24(7)(c)", - "24(7)(d)", - "24(7)(e)" + "III.24(1)", + "III.24(1)(a)", + "III.24(1)(b)", + "III.24(1)(c)", + "III.24(2)", + "III.24(3)", + "III.24(4)", + "III.24(5)", + "III.24(6)", + "III.24(7)", + "III.24(7)(a)", + "III.24(7)(b)", + "III.24(7)(c)", + "III.24(7)(d)", + "III.24(7)(e)" ], "emea-nga-dpr-2019": [ - "4.1(2)", - "4.1(3)" + "4.1(2)" + ], + "emea-nor-pda-2018": [ + "18", + "18(a)", + "18(b)", + "18(c)", + "18(d)" + ], + "emea-pol-act-10-2018": [ + "Art. 8", + "Art. 11a" ], - "emea-qat-pdppl-2020": [ - "8.2", - "10" + "emea-rus-152-fz-2025": [ + "Art. 22.1" ], "emea-sau-pdpl-2023": [ "Article 30.2" ], "emea-srb-act-9-2018": [ - "44", - "44.1", - "44.2", - "56", - "56.1", - "56.2", - "56.3", - "57", - "58", - "58.1", - "58.2", - "58.3", - "58.4" - ], - "emea-zaf-popia-2013": [ - "17", - "55", - "56" + "IV.4.56", + "IV.4.56(1)", + "IV.4.56(2)", + "IV.4.56(3)", + "IV.4.57", + "IV.4.58", + "IV.4.58(1)", + "IV.4.58(2)", + "IV.4.58(3)", + "IV.4.58(4)" + ], + "emea-che-fadp-2025": [ + "2.1.10.1", + "2.1.10.2", + "2.1.10.2.b" + ], + "emea-gbr-dpa-2018": [ + "Section 69(1)", + "Section 69(2)", + "Section 69(2)(a)", + "Section 69(2)(b)", + "Section 69(3)", + "Section 70(1)", + "Section 70(2)", + "Section 70(2)(a)", + "Section 70(2)(b)", + "Section 70(3)", + "Section 70(3)(a)", + "Section 70(3)(b)", + "Section 70(3)(c)", + "Section 70(4)", + "Section 70(4)(a)", + "Section 70(4)(b)", + "Section 70(5)", + "Section 71(1)", + "Section 71(1)(a)", + "Section 71(1)(b)", + "Section 71(1)(c)", + "Section 71(1)(d)", + "Section 71(1)(e)", + "Section 71(1)(f)", + "Section 71(2)", + "Section 71(2)(a)", + "Section 71(2)(b)", + "Section 71(2)(c)", + "Section 71(2)(d)", + "Section 71(3)" ], "apac-chn-pipl-2021": [ - "9", - "52", - "53" + "Article 52", + "Article 54" ], "apac-ind-dpdpa-2023": [ "10(2)(a)", "10(2)(a)(iv)" ], + "americas-bhs-dpa-2003": [ + "V.45(1)", + "V.45(1)(a)", + "V.45(1)(b)", + "V.45(1)(c)", + "V.45(3)", + "V.45(3)(a)", + "V.45(3)(b)", + "V.45(3)(c)", + "V.45(3)(d)", + "V.45(3)(e)", + "V.45(3)(f)", + "V.45(3)(g)", + "V.45(3)(h)", + "V.45(3)(i)", + "V.45(3)(j)" + ], "americas-bra-lgpd-2018": [ - "6.8", - "6.10", - "41" + "VI.II.41", + "VI.II.41.1", + "VI.II.41.2", + "VI.II.41.2.I", + "VI.II.41.2.II", + "VI.II.41.2.III", + "VI.II.41.2.IV", + "VI.II.41.3" ], - "americas-can-pipeda-2000": [ - "Sec 6" + "americas-mex-fdpa-2010": [ + "IV.30" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-01.5.json b/docs/api/controls/PRI-01.5.json index 441d0297..5adf98b5 100644 --- a/docs/api/controls/PRI-01.5.json +++ b/docs/api/controls/PRI-01.5.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to implement and manage Binding Corporate Rules (BCR) (e.g., data sharing agreement) to legally-bind all parties engaged in a joint economic activity that contractually states enforceable rights on data subjects with regard to the processing of their personal data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -104,30 +105,337 @@ "Article 46.1", "Article 46.2(b)" ], + "emea-aut-dpa-2018": [ + "§ 58(1)", + "§ 58(2)", + "§ 58(3)", + "§ 59(1)", + "§ 59(2)", + "§ 59(3)", + "§ 59(5)", + "§ 59(6)", + "§ 59(7)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter V, Art. 66(1)", + "Title 2, Chapter V, Art. 66(2)", + "Title 2, Chapter V, Art. 67", + "Title 2, Chapter V, Art. 68(1)", + "Title 2, Chapter V, Art. 68(2)", + "Title 2, Chapter V, Art. 68(3)", + "Title 2, Chapter V, Art. 69(1)", + "Title 2, Chapter V, Art. 69(2)", + "Title 2, Chapter V, Art. 69(3)", + "Title 2, Chapter V, Art. 70(1)", + "Title 2, Chapter V, Art. 70(2)", + "Title 2, Chapter V, Art. 70(3)" + ], + "emea-deu-fdpa-2017": [ + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)8", + "3.4.62(5)9", + "3.4.62(6)", + "3.4.62(7)", + "3.4.63", + "3.5.78(1)", + "3.5.78(1)1", + "3.5.78(1)2", + "3.5.78(2)", + "3.5.78(3)", + "3.5.78(4)", + "3.5.79(1)", + "3.5.79(1)1" + ], + "emea-grc-pirppd-1997": [ + "B.9.1.b", + "B.9.2" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" + ], + "emea-irl-dpa-2018": [ + "s.96", + "s.97", + "s.98", + "s.99", + "s.100" + ], + "emea-ken-pda-2019": [ + "IV.25(h)", + "VI.49(1)", + "VI.49(2)", + "VI.49(3)", + "VI.50" + ], + "emea-nga-dpr-2019": [ + "2.11", + "2.11(a)", + "2.11(b)", + "2.11(c)", + "2.11(d)", + "2.11(e)", + "2.12" + ], "emea-qat-pdppl-2020": [ - "15" + "3.15" + ], + "emea-rus-152-fz-2025": [ + "Art. 12" ], "emea-sau-pdpl-2023": [ "Article 29.2.b" ], "emea-srb-act-9-2018": [ - "65", - "65.x", - "66", - "67", - "67.x" + "V.63", + "V.63(1)", + "V.63(2)", + "V.63(3)", + "V.63(4)", + "V.64", + "V.64(1)", + "V.64(2)", + "V.64(3)", + "V.65-1", + "V.65-1(1)", + "V.65-1(2)", + "V.65-1(3)", + "V.65-1(4)", + "V.65-1(5)", + "V.65-2", + "V.65-2(1)", + "V.65-2(2)", + "V.66", + "V.66(1)", + "V.66(2)", + "V.67-1", + "V.67-1(1)", + "V.67-1(2)", + "V.67-1(3)", + "V.67-2", + "V.67-2(1)", + "V.67-2(2)", + "V.67-2(3)", + "V.67-2(4)", + "V.67-2(5)", + "V.67-2(6)", + "V.67-2(7)", + "V.67-2(8)", + "V.67-2(9)", + "V.67-2(10)", + "V.67-2(11)", + "V.67-2(12)", + "V.67-2(13)", + "V.67-2(14)", + "V.68", + "V.69-1", + "V.69-1(1)", + "V.69-1(2)", + "V.69-1(3)", + "V.69-1(4)", + "V.69-1(5)", + "V.69-1(6)", + "V.69-1(7)", + "V.69-2", + "V.69-2(1)", + "V.69-2(2)", + "V.69-2(3)", + "V.69-2(4)", + "V.70", + "V.70(1)", + "V.70(2)", + "V.70(3)", + "V.70(4)", + "V.70(5)", + "V.71", + "V.71(1)", + "V.71(2)", + "V.71(3)", + "V.71(4)", + "V.71(5)", + "V.72", + "V.72(1)", + "V.72(2)", + "V.72(3)", + "V.72(4)" + ], + "emea-zaf-popia-2013": [ + "9.72(1)", + "9.72(1)(a)", + "9.72(1)(a)(i)", + "9.72(1)(a)(ii)", + "9.72(1)(b)", + "9.72(1)(c)", + "9.72(1)(d)", + "9.72(1)(e)", + "9.72(1)(e)(i)", + "9.72(1)(e)(ii)", + "9.72(2)", + "9.72(2)(a)", + "9.72(2)(b)" + ], + "emea-che-fadp-2025": [ + "2.3.16.1", + "2.3.16.2", + "2.3.16.2.a", + "2.3.16.2.b", + "2.3.16.2.c", + "2.3.16.2.d", + "2.3.16.2.e", + "2.3.16.3" + ], + "emea-tur-lppd-2016": [ + "9(1)", + "9(2)", + "9(3)", + "9(3)(a)", + "9(3)(b)", + "9(3)(c)", + "9(3)(ç)", + "9(3)(d)", + "9(3)(e)", + "9(4)", + "9(4)(a)", + "9(4)(b)", + "9(4)(c)", + "9(4)(ç)", + "9(5)", + "9(6)", + "9(6)(a)", + "9(6)(b)", + "9(6)(c)", + "9(6)(ç)", + "9(6)(d)", + "9(6)(e)", + "9(6)(f)", + "9(7)", + "9(8)", + "9(9)", + "9(10)", + "9(11)" + ], + "emea-gbr-dpa-2018": [ + "Section 78", + "Section 78(1)", + "Section 78(1)(a)", + "Section 78(1)(b)", + "Section 78(1)(b)(i)", + "Section 78(1)(b)(ii)", + "Section 78(1A)", + "Section 78(1A)(a)", + "Section 78(1A)(b)", + "Section 78(2)", + "Section 78(3)", + "Section 78(3)(a)", + "Section 78(3)(b)", + "Section 78(3)(c)", + "Section 78(4)", + "Section 78(5)", + "Section 78(5)(a)", + "Section 78(5)(b)", + "Section 78(6)", + "Section 78(7)", + "Section 78(7)(a)", + "Section 78(7)(b)" + ], + "apac-aus-privacy-principles-2026": [ + "3.8.1", + "3.8.1.a", + "3.8.1.b", + "3.8.2", + "3.8.2.a", + "3.8.2.a.i", + "3.8.2.a.ii", + "3.8.2.b", + "3.8.2.b.i", + "3.8.2.b.ii", + "3.8.2.c", + "3.8.2.d", + "3.8.2.e", + "3.8.2.f", + "3.8.2.f.i", + "3.8.2.f.ii" + ], + "apac-chn-pipl-2021": [ + "Article 38" + ], + "apac-ind-privacy-rules-2011": [ + "7" + ], + "apac-jpn-appi-2020": [ + "IV.1.24(1)", + "IV.1.24(2)", + "IV.1.24(3)" + ], + "apac-mys-pdpa-2010": [ + "129(1)", + "129(2)", + "129(2)(a)", + "129(2)(b)", + "129(3)", + "129(3)(a)", + "129(3)(b)", + "129(3)(c)", + "129(3)(c)(i)", + "129(3)(c)(ii)", + "129(3)(d)", + "129(3)(e)", + "129(3)(e)(i)", + "129(3)(e)(ii)", + "129(3)(e)(iii)", + "129(3)(f)", + "129(3)(g)", + "129(3)(h)", + "129(4)", + "129(4)(a)", + "129(4)(b)" ], "apac-nzl-privacy-act-2020": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "3.1.22.12(1)", + "3.1.22.12(1)(a)", + "3.1.22.12(1)(b)", + "3.1.22.12(1)(c)", + "3.1.22.12(1)(d)", + "3.1.22.12(1)(e)", + "3.1.22.12(1)(f)", + "3.1.22.12(2)", + "3.1.22.12(3)" + ], + "apac-sgp-pdpa-2012": [ + "6.26(1)" + ], + "americas-bra-lgpd-2018": [ + "V.33", + "V.33.I", + "V.33.II", + "V.33.II(a)", + "V.33.II(b)", + "V.33.II(c)", + "V.33.II(d)", + "V.33.III", + "V.33.IV", + "V.33.V", + "V.33.VI", + "V.33.VII", + "V.33.VIII", + "V.33.IX", + "V.34", + "V.34.I", + "V.34.II", + "V.34.III", + "V.34.IV", + "V.34.V", + "V.34.VI" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-01.6.json b/docs/api/controls/PRI-01.6.json index 8b16968b..16229973 100644 --- a/docs/api/controls/PRI-01.6.json +++ b/docs/api/controls/PRI-01.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure Personal Data (PD) is protected by logical and physical security safeguards that are sufficient and appropriately scoped to protect the confidentiality and integrity of the PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -101,10 +102,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.9.1" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" - ], "general-tisax-6-0-3": [ "7.1.2" ], @@ -136,6 +133,9 @@ "usa-state-il-pipa-2006": [ "45(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.1" + ], "usa-state-nv-regulation-5-2024": [ "5.260.1" ], @@ -176,99 +176,341 @@ "Article 32.1(a)", "Article 32.1(b)" ], + "emea-aut-dpa-2018": [ + "§ 6(1)", + "§ 13(1)", + "§ 54(1)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 34(2)", + "Title 2, Chapter III, Art. 45(4)", + "Title 2, Chapter IV, Section 1, Art. 50", + "Title 2, Chapter IV, Section 1, Art. 51(1)", + "Title 2, Chapter IV, Section 1, Art. 51(2)", + "Title 2, Chapter IV, Section 4, Art. 60(1)", + "Title 2, Chapter IV, Section 4, Art. 60(2)" + ], + "emea-deu-fdpa-2017": [ + "2.1.1.22(2)5", + "2.1.1.22(2)6", + "2.1.1.22(2)7", + "2.1.2.28(1)", + "3.2.53", + "3.4.62(5)2", + "3.4.64(1)", + "3.4.64(2)1", + "3.4.64(2)2", + "3.4.64(3)", + "3.4.64(3)1", + "3.4.64(3)2", + "3.4.64(3)3", + "3.4.64(3)4", + "3.4.64(3)5", + "3.4.64(3)6", + "3.4.64(3)7", + "3.4.64(3)8", + "3.4.64(3)9", + "3.4.64(3)10", + "3.4.64(3)11", + "3.4.64(3)12", + "3.4.64(3)13", + "3.4.64(3)14", + "3.4.71(2)" + ], + "emea-grc-pirppd-1997": [ + "B.9.2.f", + "B.10.1", + "B.10.2", + "B.10.3" + ], + "emea-hun-act-cxii-2011": [ + "II.6.7(2)", + "II.6.7(3)", + "II.6.7(4)", + "II.6.7(5)(a)", + "II.6.7(5)(b)", + "II.6.7(5)(c)", + "II.6.7(5)(d)", + "II.6.7(5)(e)", + "II.6.7(5)(f)", + "II.6.7(6)" + ], + "emea-irl-dpa-2018": [ + "s.72", + "s.75", + "s.76", + "s.77", + "s.78" + ], + "emea-isr-ppl-5741-2025": [ + "s.17" + ], + "emea-ita-pdpc-2018": [ + "Article 115(1)", + "Article 115(2)" + ], "emea-ken-pda-2019": [ - "29(f)", - "41(1)", - "41(1)(a)", - "41(1)(b)", - "41(2)", - "41(3)(a)", - "41(3)(b)", - "41(3)(c)", - "41(3)(d)", - "41(3)(e)", - "41(4)(a)", - "41(4)(b)", - "41(4)(c)", - "41(4)(d)", - "41(4)(e)", - "41(4)(f)", - "42(1)(a)", - "42(1)(b)", - "42(1)(c)", - "42(1)(d)", - "42(2)(a)", - "42(2)(b)", - "42(3)", - "42(4)" + "IV.41(1)", + "IV.41(1)(a)", + "IV.41(1)(b)", + "IV.41(2)", + "IV.41(3)", + "IV.41(3)(a)", + "IV.41(3)(b)", + "IV.41(3)(c)", + "IV.41(3)(d)", + "IV.41(3)(e)", + "IV.41(4)", + "IV.41(4)(a)", + "IV.41(4)(b)", + "IV.41(4)(c)", + "IV.41(4)(d)", + "IV.41(4)(e)", + "IV.41(4)(f)", + "IV.42(1)", + "IV.42(1)(a)", + "IV.42(1)(b)", + "IV.42(1)(c)", + "IV.42(1)(d)", + "IV.42(2)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], "emea-nga-dpr-2019": [ "2.1(1)(d)", "2.6" ], "emea-qat-pdppl-2020": [ - "8.3", - "13" + "3.13" + ], + "emea-rus-152-fz-2025": [ + "Art. 7", + "Art. 18.1", + "Art. 19" ], "emea-sau-pdpl-2023": [ "Article 19" ], "emea-srb-act-9-2018": [ - "5.6", - "41", - "42", - "42.1", - "42.2", - "50", - "50.1", - "50.2", - "50.3", - "50.4", - "51", - "51.1", - "51.2", - "51.3", - "51.4", - "51.5", - "51.6", - "51.7", - "51.8", - "51.9", - "51.10" + "II.6(5)", + "II.8", + "IV.1.41", + "IV.1.42", + "IV.1.42(1)", + "IV.1.42(2)", + "IV.2.50", + "IV.2.50(2)", + "IV.2.50(3)", + "IV.2.50(4)", + "IV.2.51", + "IV.2.51(1)", + "IV.2.51(2)", + "IV.2.51(3)", + "IV.2.51(4)", + "IV.2.51(5)", + "IV.2.51(6)", + "IV.2.51(7)", + "IV.2.51(8)", + "IV.2.51(9)", + "IV.2.51(10)" + ], + "emea-zaf-popia-2013": [ + "3.A.7.19(1)", + "3.A.7.19(1)(a)", + "3.A.7.19(1)(b)", + "3.A.7.19(2)", + "3.A.7.19(2)(a)", + "3.A.7.19(2)(b)", + "3.A.7.19(2)(c)", + "3.A.7.19(2)(d)", + "3.A.7.19(3)" + ], + "emea-esp-decree-311-2022": [ + "Article 5(a)", + "Article 5(b)", + "Article 5(c)", + "Article 5(d)", + "Article 5(e)", + "Article 5(f)", + "Article 5(g)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" + ], + "emea-che-fadp-2025": [ + "2.1.7.2", + "2.1.8.1", + "2.1.8.2" + ], + "emea-tur-lppd-2016": [ + "12(1)", + "12(1)(a)", + "12(1)(b)", + "12(1)(c)", + "12(2)", + "12(3)", + "12(4)", + "12(5)" + ], + "emea-gbr-dpa-2018": [ + "Section 55(3)", + "Section 55(3)(a)", + "Section 55(3)(b)", + "Section 55(3)(c)", + "Section 55(3)(d)", + "Section 56(1)", + "Section 56(2)", + "Section 56(3)", + "Section 57(1)", + "Section 57(1)(a)", + "Section 57(1)(b)", + "Section 57(2)", + "Section 57(3)", + "Section 57(4)", + "Section 57(4)(a)", + "Section 57(4)(b)", + "Section 57(4)(c)", + "Section 57(4)(d)", + "Section 57(5)", + "Section 66(1)", + "Section 66(2)", + "Section 66(2)(a)", + "Section 66(2)(b)", + "Section 66(2)(c)", + "Section 66(2)(d)", + "Section 66(3)" + ], + "apac-aus-privacy-principles-2026": [ + "4.11.1", + "4.11.1.a", + "4.11.1.b" + ], + "apac-aus-cop-sitc-2020": [ + "5" ], "apac-chn-cybersecurity-law-2017": [ "Article 42" ], + "apac-chn-csnip-2012": [ + "IV" + ], "apac-chn-pipl-2021": [ - "9", - "25", - "28", - "59" + "Article 9" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 4(1)", + "Schedule 1 - 4(1)(a)", + "Schedule 1 - 4(1)(b)", + "Schedule 1 - 4(1)(c)", + "Schedule 1 - 4(1)(d)", + "Schedule 1 - 4(1)(e)" ], "apac-ind-dpdpa-2023": [ "8(4)", "8(5)" ], - "apac-jpn-ppi-2020": [ - "20", - "21" + "apac-ind-privacy-rules-2011": [ + "5(8)", + "8(2)" + ], + "apac-jpn-appi-2020": [ + "IV.1.20" + ], + "apac-mys-pdpa-2010": [ + "9(1)", + "9(1)(a)", + "9(1)(b)", + "9(1)(c)", + "9(1)(d)", + "9(1)(e)", + "9(2)", + "9(2)(a)", + "9(2)(b)" ], "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.1", - "14.1.2", - "14.1.3", - "14.1.4", - "14.1.5", - "14.1.6", - "14.1.7" + "3.1.22.5(a)", + "3.1.22.5(a)(i)", + "3.1.22.5(a)(ii)", + "3.1.22.5(a)(iii)" + ], + "apac-phl-dpa-2012": [ + "V.20(a)", + "V.20(b)", + "V.20(c)", + "V.20(c)(1)", + "V.20(c)(2)", + "V.20(c)(3)", + "V.20(c)(4)", + "V.20(d)", + "V.20(e)" + ], + "apac-sgp-pdpa-2012": [ + "6.24", + "6.24(a)", + "6.24(b)" + ], + "apac-twn-pdpa-2025": [ + "III.20-1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-1" + ], + "americas-bhs-dpa-2003": [ + "II.5(1)(f)", + "II.9(2)", + "II.11(1)", + "II.11(1)(a)", + "II.11(1)(b)", + "II.11(2)", + "V.43(4)(d)", + "V.43(4)(e)", + "V.52(1)", + "V.52(2)", + "V.52(2)(a)", + "V.52(2)(b)", + "V.52(2)(c)", + "V.52(2)(d)", + "V.52(4)" + ], + "americas-bra-lgpd-2018": [ + "VII.I.46", + "VII.I.46.1", + "VII.I.47", + "VII.I.49", + "VII.II.50", + "VII.II.50.1", + "VII.II.50.2", + "VII.II.50.2.I", + "VII.II.50.2.I(a)", + "VII.II.50.2.I(b)", + "VII.II.50.2.I(c)", + "VII.II.50.2.I(d)", + "VII.II.50.2.I(e)", + "VII.II.50.2.I(f)", + "VII.II.50.2.I(g)", + "VII.II.50.2.I(h)", + "VII.II.50.2.II" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(a)", + "P7-4.7", + "P7-4.7.1", + "P7-4.7.2", + "P7-4.7.3" + ], + "americas-chl-act-19628-1999": [ + "I.7", + "I.11" + ], + "americas-col-law-1581-2012": [ + "II.4(g)", + "VI.17(d)" + ], + "americas-mex-fdpa-2010": [ + "II.19", + "II.21" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-01.7.json b/docs/api/controls/PRI-01.7.json index 5c4cddce..23139cc7 100644 --- a/docs/api/controls/PRI-01.7.json +++ b/docs/api/controls/PRI-01.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to limit the disclosure of Personal Data (PD) to authorized parties for the sole purpose for which the PD was obtained.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -111,49 +112,16 @@ "10(c)(2)", "10(c)(5)" ], + "emea-grc-pirppd-1997": [ + "C.11.3" + ], "emea-sau-pdpl-2023": [ "Article 23.1", "Article 23.2", "Article 29.2.c" ], - "emea-srb-act-9-2018": [ - "33" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "22", - "25", - "41" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 11", - "P11-(1)", - "P11-(1)(a)", - "P11-(1)(b)", - "P11-(1)(c)", - "P11-(1)(d)", - "P11-(1)(e)(i)", - "P11-(1)(e)(ii)", - "P11-(1)(e)(iii)", - "P11-(1)(e)(iv)", - "P11-(1)(f)(i)", - "P11-(1)(f)(ii)", - "P11-(1)(g)", - "P11-(1)(h)(i)", - "P11-(1)(h)(ii)", - "P11-(1)(i)", - "P11-(2)", - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "apac-aus-privacy-principles-2026": [ + "3.6.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-01.8.json b/docs/api/controls/PRI-01.8.json index 47c30a80..552baa5e 100644 --- a/docs/api/controls/PRI-01.8.json +++ b/docs/api/controls/PRI-01.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to appoint an individual to determine the following criteria about Personal Data (PD):\n(1) The purpose why PD is necessary; \n(2) Authorized methods to collect, receive, process, store, transmit, share, update and/or dispose PD; and\n(3) Authorized parties PD may be shared with.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-01.9.json b/docs/api/controls/PRI-01.9.json index d869108d..7c7e9e8f 100644 --- a/docs/api/controls/PRI-01.9.json +++ b/docs/api/controls/PRI-01.9.json @@ -3,7 +3,7 @@ "title": "Personal Data (PD) Process Manager", "family": "PRI", "description": "Mechanisms exist to assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent.", - "scf_question": "Does the organization assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD)is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent?", + "scf_question": "Does the organization assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ Accountability is assigned to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,12 +67,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "apac-ind-dpdpa-2023": [ "6(8)" + ], + "americas-mex-fdpa-2010": [ + "IV.30" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-01.json b/docs/api/controls/PRI-01.json index 7bc5db04..b24fa752 100644 --- a/docs/api/controls/PRI-01.json +++ b/docs/api/controls/PRI-01.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.\n▪ Data/process owners are expected to take the initiative to work with Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ No formal data privacy principles are identified for the organization.\n▪ Data/process owners perform their own Data Protection Impact Assessment (DPIA).", + "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.\n▪ Data/process owners are expected to take the initiative to work with Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ No formal data privacy principles are identified for the organization.\n▪ Data/process owners perform their own Data Protection Impact Assessment (DPIA). ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is formally assigned as the Chief Privacy Officer (CPO), or similar role, to lead the organization's data privacy program. This individual may be assigned to multiple data privacy-related roles.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to facilitate the implementation and operation of data protection controls throughout the data lifecycle to ensure all forms of Personal Data (PD) are processed lawfully, fairly and transparently.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96,7 +96,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -163,7 +164,7 @@ "7.5.3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-100-1-ai-rmf": [ "MAP 1.6" @@ -227,10 +228,6 @@ "general-oecd-privacy-principles-2010": [ "8" ], - "general-scf-dpmp-2025": [ - "1.0", - "1.1" - ], "general-shared-assessments-sig-2025": [ "P.3" ], @@ -262,14 +259,14 @@ "155.260(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)", - "164.530(a)(1)(i)", - "164.530(i)(1)", - "164.530(i)(4)(i)(A)", - "164.530(i)(4)(i)(B)", - "164.530(i)(5)", - "164.530(i)(5)(i)", - "164.530(i)(5)(ii)" + "§ 164.502(a)", + "§ 164.530(a)(1)(i)", + "§ 164.530(i)(1)", + "§ 164.530(i)(4)(i)(A)", + "§ 164.530(i)(4)(i)(B)", + "§ 164.530(i)(5)", + "§ 164.530(i)(5)(i)", + "§ 164.530(i)(5)(ii)" ], "usa-federal-irs-1075-2021": [ "PM-18", @@ -308,221 +305,73 @@ "Article 9.1", "Article 12.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "4" - ], "emea-deu-fdpa-2017": [ - "Inferred", - "Expectation" - ], - "emea-grc-pirppd-1997": [ - "Inferred", - "Expectation" - ], - "emea-hun-isdfi-2011": [ - "Inferred", - "Expectation" + "2.1.2.26(5)" ], - "emea-irl-dpa-2003": [ - "Inferred", - "Expectation" + "emea-hun-act-cxii-2011": [ + "II.6.7(1)" ], - "emea-isr-ppl-5741-1981": [ - "Inferred", - "Expectation" - ], - "emea-ita-pdpc-2003": [ - "Inferred", - "Expectation" + "emea-isr-cmo-2-0": [ + "Appendix F" ], "emea-ken-pda-2019": [ - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)" + "IV.25" ], "emea-nga-dpr-2019": [ "4.1(3)" ], - "emea-nor-pda-2018": [ - "Inferred", - "Expectation" - ], - "emea-pol-act-29-1997": [ - "Inferred", - "Expectation" - ], "emea-qat-pdppl-2020": [ - "2", - "3", - "8.1" - ], - "emea-rus-federal-law-27-2006": [ - "Inferred", - "Expectation" + "3.11", + "3.11.5" ], "emea-sau-pdpl-2023": [ "Article 11.2" ], - "emea-srb-act-9-2018": [ - "5.1", - "59", - "59.1", - "59.2", - "59.3", - "59.4", - "59.5", - "59.6", - "59.7", - "59.8", - "59.9", - "59.10", - "59.11" - ], - "emea-zaf-popia-2013": [ - "19", - "20", - "60" - ], - "emea-esp-decree-1720-2007": [ - "Inferred", - "Expectation" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.1 [MP.INFO.1]" - ], - "emea-che-fadp-2025": [ - "Inferred", - "Expectation" - ], - "emea-tur-lppd-2016": [ - "Inferred", - "Expectation" - ], - "emea-gbr-dpa-1998": [ - "Inferred", - "Expectation" - ], - "apac-aus-privacy-act-1998": [ - "Inferred", - "Expectation" - ], - "apac-aus-privacy-principles-2026": [ - "APP 1" - ], - "apac-chn-csnip-2012": [ - "Inferred", - "Expectation" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "mp.info.1" ], "apac-chn-pipl-2021": [ - "7", - "16", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)", - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)", - "59" - ], - "apac-hkg-pdo-2022": [ - "Inferred", - "Expectation" + "Article 51" ], "apac-ind-privacy-rules-2011": [ - "Inferred", - "Expectation" - ], - "apac-jpn-ppi-2020": [ - "24(3)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" + "8(1)" + ], + "apac-jpn-appi-2020": [ + "IV.5.53(1)" ], "apac-jpn-ismap": [ "5.1.1", "5.1.1.19", "18.1.4" ], - "apac-mys-pdpa-2010": [ - "23" - ], "apac-phl-dpa-2012": [ - "Inferred", - "Expectation" - ], - "apac-sgp-pdpa-2012": [ - "12" - ], - "apac-kor-pipa-2011": [ - "3", - "30" - ], - "apac-twn-pdpa-2025": [ - "Inferred", - "Expectation" + "III.11" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.8", - "6.10", - "50" - ], - "americas-can-pipeda-2000": [ - "Principle 1", - "Principle 8" - ], - "americas-chl-act-19628-1999": [ - "Inferred", - "Expectation" + "V.45(2)(a)", + "V.45(2)(b)", + "V.45(2)(b)(i)", + "V.45(2)(b)(ii)" ], "americas-col-law-1581-2012": [ - "4" + "VI.18(a)", + "VI.18(b)", + "VI.18(c)", + "VI.18(d)", + "VI.18(e)", + "VI.18(f)", + "VI.18(g)", + "VI.18(h)", + "VI.18(i)", + "VI.18(j)", + "VI.18(k)", + "VI.18(l)" ], "americas-mex-fdpa-2010": [ - "6", - "14", - "30" + "II.6", + "II.14" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-02.1.json b/docs/api/controls/PRI-02.1.json index ddd9d751..d34e427a 100644 --- a/docs/api/controls/PRI-02.1.json +++ b/docs/api/controls/PRI-02.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data privacy notices identify the purpose(s) for which Personal Data (PD) is collected, received, processed, stored, transmitted and/or shared.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -116,9 +117,6 @@ "general-oecd-privacy-principles-2010": [ "3" ], - "general-scf-dpmp-2025": [ - "4.1" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.1.a.iv", "II.5.a" @@ -140,13 +138,13 @@ "7" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(3)", - "164.508(c)(1)(i)", - "164.508(c)(1)(ii)", - "164.508(c)(1)(iii)", - "164.508(c)(1)(iv)", - "164.508(c)(2)(i)(A)", - "164.508(c)(2)(i)(B)" + "§ 164.502(a)(3)", + "§ 164.508(c)(1)(i)", + "§ 164.508(c)(1)(ii)", + "§ 164.508(c)(1)(iii)", + "§ 164.508(c)(1)(iv)", + "§ 164.508(c)(2)(i)(A)", + "§ 164.508(c)(2)(i)(B)" ], "usa-federal-cms-marse-2-0": [ "AP-2" @@ -179,74 +177,27 @@ "Article 13.1(c)", "Article 14.1(c)" ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" - ], - "emea-irl-dpa-2003": [ - "2" + "emea-deu-fdpa-2017": [ + "3.3.56(1)2" ], - "emea-isr-ppl-5741-1981": [ - "8" - ], - "emea-ita-pdpc-2003": [ - "13" - ], - "emea-ken-pda-2019": [ - "29(c)" + "emea-hun-act-cxii-2011": [ + "II.8.9(1)(a)", + "II.14.20(2)", + "II.14.20(4)(c)" ], "emea-nga-dpr-2019": [ "2.3(1)" ], - "emea-nor-pda-2018": [ - "32" - ], - "emea-pol-act-29-1997": [ - "23" - ], - "emea-qat-pdppl-2020": [ - "6.1", - "8.1", - "10" - ], - "emea-rus-federal-law-27-2006": [ - "5" - ], "emea-sau-pdpl-2023": [ "Article 11.1", "Article 13.2", "Article 13.3" ], - "emea-srb-act-9-2018": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" - ], - "emea-zaf-popia-2013": [ - "13", - "18" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 1" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" ], "apac-chn-pipl-2021": [ - "6", - "48" - ], - "apac-hkg-pdo-2022": [ - "Principle 1" + "Article 6" ], "apac-ind-dpdpa-2023": [ "4(2)", @@ -255,83 +206,20 @@ "7(a)", "8(8)(a)" ], - "apac-jpn-ppi-2020": [ - "15(1)", - "15(2)" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" + "apac-jpn-appi-2020": [ + "IV.1.15(1)" ], "apac-phl-dpa-2012": [ - "19" - ], - "apac-sgp-pdpa-2012": [ - "14", - "19", - "20" - ], - "apac-kor-pipa-2011": [ - "3", - "4" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "6", - "27.1", - "27.2", - "28.1" + "III.12" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.1", - "6.3" + "II.5(1)(b)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 2" - ], - "americas-chl-act-19628-1999": [ - "5" - ], - "americas-col-law-1581-2012": [ - "4" + "P2-4.2" ], "americas-mex-fdpa-2010": [ - "7", - "16", - "17", - "18" + "II.16.II" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-02.10.json b/docs/api/controls/PRI-02.10.json index 586570f7..c17b98ba 100644 --- a/docs/api/controls/PRI-02.10.json +++ b/docs/api/controls/PRI-02.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure symmetry in choice, where options presented to consumers for more protective options are not longer, more difficult, nor more time-consuming than less protective options.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-02.11.json b/docs/api/controls/PRI-02.11.json index 19c4c7ce..60227696 100644 --- a/docs/api/controls/PRI-02.11.json +++ b/docs/api/controls/PRI-02.11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to avoid choice architecture that impairs, interferes with or subverts a consumer’s ability to make well-informed choices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-02.12.json b/docs/api/controls/PRI-02.12.json index 8c003b43..9f837de2 100644 --- a/docs/api/controls/PRI-02.12.json +++ b/docs/api/controls/PRI-02.12.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to perform testing of choice architecture to ensure it does not undermine a consumer’s ability to submit choice selections.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to perform testing of choice architecture to ensure it does not undermine a consumer’s ability to submit choice selections. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-02.13.json b/docs/api/controls/PRI-02.13.json index 762cb4d9..267cd93f 100644 --- a/docs/api/controls/PRI-02.13.json +++ b/docs/api/controls/PRI-02.13.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include within the data privacy notice a notification to data subjects of:\n(1) Their right to limit the use and disclosure of their sensitive Personal Data (sPD); and\n(2) The methods available to exercise that right.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include within the data privacy notice a notification to data subjects of:\n(1) Their right to limit the use and disclosure of their sensitive Personal Data (sPD); and\n(2) The methods available to exercise that right. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -77,6 +78,12 @@ "7014(f)", "7014(f)(1)", "7014(f)(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.14.20(4)(f)" + ], + "apac-aus-privacy-principles-2026": [ + "1.2.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-02.14.json b/docs/api/controls/PRI-02.14.json index b23692a7..702fb3fa 100644 --- a/docs/api/controls/PRI-02.14.json +++ b/docs/api/controls/PRI-02.14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with a data privacy notice through alternative means for interactions that do not utilize an interface on a website or application.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-02.2.json b/docs/api/controls/PRI-02.2.json index 14b51b5d..cde48c97 100644 --- a/docs/api/controls/PRI-02.2.json +++ b/docs/api/controls/PRI-02.2.json @@ -3,7 +3,7 @@ "title": "Automated Data Management Processes", "family": "PRI", "description": "Automated mechanisms exist to adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s).", - "scf_question": "Does the organization use automated mechanisms to adjust data that is able tobe collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s)?", + "scf_question": "Does the organization use automated mechanisms to adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s)?", "relative_weight": 1, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -68,7 +68,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -95,9 +96,6 @@ "general-nist-800-82-r3-high": [ "PM-24" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-24", "PT-03(02)" @@ -115,39 +113,7 @@ "PT-03(02)" ], "emea-ken-pda-2019": [ - "35(1)", - "35(2)", - "35(2)(a)", - "35(2)(b)", - "35(2)(c)", - "35(3)", - "35(3)(a)", - "35(3)(b)(i)", - "35(3)(b)(ii)", - "35(4)(a)", - "35(4)(b)", - "35(4)(c)(i)", - "35(4)(c)(ii)" - ], - "emea-srb-act-9-2018": [ - "38", - "38.1", - "38.2", - "38.3", - "39" - ], - "emea-zaf-popia-2013": [ - "5", - "71" - ], - "apac-chn-pipl-2021": [ - "24" - ], - "apac-twn-pdpa-2025": [ - "5" - ], - "americas-mex-fdpa-2010": [ - "7" + "IV.35(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-02.3.json b/docs/api/controls/PRI-02.3.json index 0aa2e303..b8d6f709 100644 --- a/docs/api/controls/PRI-02.3.json +++ b/docs/api/controls/PRI-02.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish Computer Matching Agreements (CMA) on the organization's public website(s).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -95,9 +96,6 @@ "general-nist-800-82-r3-high": [ "PM-24" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-24" ], diff --git a/docs/api/controls/PRI-02.4.json b/docs/api/controls/PRI-02.4.json index fdf8d682..d79cb2c8 100644 --- a/docs/api/controls/PRI-02.4.json +++ b/docs/api/controls/PRI-02.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to draft, publish and keep System of Records Notices (SORN) updated in accordance with regulatory guidance.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -83,9 +84,6 @@ "general-nist-800-82-r3": [ "PT-06" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-cms-marse-2-0": [ "TR-2", "TR-2.a", diff --git a/docs/api/controls/PRI-02.5.json b/docs/api/controls/PRI-02.5.json index af27bc67..ba356d30 100644 --- a/docs/api/controls/PRI-02.5.json +++ b/docs/api/controls/PRI-02.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to review all routine uses of data published in the System of Records Notices (SORN) to ensure continued accuracy and to ensure that routine uses continue to be compatible with the purpose for which the information was collected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -79,9 +80,6 @@ ], "general-nist-800-82-r3": [ "PT-06(01)" - ], - "general-scf-dpmp-2025": [ - "11.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-02.6.json b/docs/api/controls/PRI-02.6.json index 36e5bfdf..3bc99978 100644 --- a/docs/api/controls/PRI-02.6.json +++ b/docs/api/controls/PRI-02.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to review all Privacy Act exemptions claimed for the System of Records Notices (SORN) to ensure they remain appropriate and accurate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -79,9 +80,6 @@ ], "general-nist-800-82-r3": [ "PT-06(02)" - ], - "general-scf-dpmp-2025": [ - "11.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-02.7.json b/docs/api/controls/PRI-02.7.json index 8e5342f9..43be78eb 100644 --- a/docs/api/controls/PRI-02.7.json +++ b/docs/api/controls/PRI-02.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide real-time and/or layered notice when Personal Data (PD) is collected that provides data subjects with a summary of key points or more detailed information that is specific to the organization's data privacy notice.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-02.8.json b/docs/api/controls/PRI-02.8.json index 9478b085..7b1727a3 100644 --- a/docs/api/controls/PRI-02.8.json +++ b/docs/api/controls/PRI-02.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to periodically assess disclosed purposes for which Personal Data (PD) is collected, received, processed, stored, transmitted and/or shared to ensure compatibility with reasonable consumer expectations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -79,6 +80,9 @@ "7002(c)(1)", "7002(c)(2)", "7002(c)(3)" + ], + "americas-bra-lgpd-2018": [ + "II.IV.15.I" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-02.9.json b/docs/api/controls/PRI-02.9.json index f1f142ee..50e2b9ae 100644 --- a/docs/api/controls/PRI-02.9.json +++ b/docs/api/controls/PRI-02.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reasonably accommodate data privacy notice formatting for consumers requiring alternative formatting due to accessibility needs through:\n(1) Screen resolution / screen sizes;\n(2) Multilingual support; and/or\n(3) Disability-specific concessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-02.json b/docs/api/controls/PRI-02.json index c56f61cc..558961ba 100644 --- a/docs/api/controls/PRI-02.json +++ b/docs/api/controls/PRI-02.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ The CPO, or similar role, develops and ensures data privacy notices are published that include relevant purpose, notice and data privacy program information.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -145,9 +146,6 @@ "general-nist-800-82-r3-high": [ "PM-20(01)" ], - "general-scf-dpmp-2025": [ - "4.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(A)(i)" ], @@ -178,50 +176,50 @@ "155.260(a)(3)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.520(a)(1)", - "164.520(a)(2)(i)", - "164.520(a)(2)(i)(A)", - "164.520(a)(2)(i)(B)", - "164.520(a)(2)(ii)", - "164.520(a)(2)(ii)(A)", - "164.520(a)(2)(ii)(B)", - "164.520(a)(2)(iii)", - "164.520(b)(1)", - "164.520(b)(1)(i)", - "164.520(b)(1)(ii)", - "164.520(b)(1)(ii)(A)", - "164.520(b)(1)(ii)(B)", - "164.520(b)(1)(ii)(C)", - "164.520(b)(1)(ii)(D)", - "164.520(b)(1)(ii)(E)", - "164.520(b)(1)(iv)", - "164.520(b)(1)(iv)(A)", - "164.520(b)(1)(iv)(B)", - "164.520(b)(1)(iv)(C)", - "164.520(b)(1)(iv)(D)", - "164.520(b)(1)(iv)(E)", - "164.520(b)(1)(iv)(F)", - "164.520(b)(1)(v)", - "164.520(b)(1)(v)(A)", - "164.520(b)(1)(v)(B)", - "164.520(b)(1)(v)(C)", - "164.520(b)(1)(vi)", - "164.520(b)(1)(vii)", - "164.520(b)(1)(viii)", - "164.520(b)(2)(i)", - "164.520(b)(2)(ii)", - "164.520(b)(3)", - "164.520(c)", - "164.520(c)(1)(i)", - "164.520(c)(1)(i)(A)", - "164.520(c)(1)(i)(B)", - "164.520(c)(1)(ii)", - "164.520(c)(1)(iii)", - "164.520(c)(1)(iv)", - "164.520(c)(1)(v)", - "164.520(c)(1)(v)(A)", - "164.520(c)(1)(v)(B)", - "164.530(i)(4)(i)(C)" + "§ 164.520(a)(1)", + "§ 164.520(a)(2)(i)", + "§ 164.520(a)(2)(i)(A)", + "§ 164.520(a)(2)(i)(B)", + "§ 164.520(a)(2)(ii)", + "§ 164.520(a)(2)(ii)(A)", + "§ 164.520(a)(2)(ii)(B)", + "§ 164.520(a)(2)(iii)", + "§ 164.520(b)(1)", + "§ 164.520(b)(1)(i)", + "§ 164.520(b)(1)(ii)", + "§ 164.520(b)(1)(ii)(A)", + "§ 164.520(b)(1)(ii)(B)", + "§ 164.520(b)(1)(ii)(C)", + "§ 164.520(b)(1)(ii)(D)", + "§ 164.520(b)(1)(ii)(E)", + "§ 164.520(b)(1)(iv)", + "§ 164.520(b)(1)(iv)(A)", + "§ 164.520(b)(1)(iv)(B)", + "§ 164.520(b)(1)(iv)(C)", + "§ 164.520(b)(1)(iv)(D)", + "§ 164.520(b)(1)(iv)(E)", + "§ 164.520(b)(1)(iv)(F)", + "§ 164.520(b)(1)(v)", + "§ 164.520(b)(1)(v)(A)", + "§ 164.520(b)(1)(v)(B)", + "§ 164.520(b)(1)(v)(C)", + "§ 164.520(b)(1)(vi)", + "§ 164.520(b)(1)(vii)", + "§ 164.520(b)(1)(viii)", + "§ 164.520(b)(2)(i)", + "§ 164.520(b)(2)(ii)", + "§ 164.520(b)(3)", + "§ 164.520(c)", + "§ 164.520(c)(1)(i)", + "§ 164.520(c)(1)(i)(A)", + "§ 164.520(c)(1)(i)(B)", + "§ 164.520(c)(1)(ii)", + "§ 164.520(c)(1)(iii)", + "§ 164.520(c)(1)(iv)", + "§ 164.520(c)(1)(v)", + "§ 164.520(c)(1)(v)(A)", + "§ 164.520(c)(1)(v)(B)", + "§ 164.530(i)(4)(i)(C)" ], "usa-federal-cms-marse-2-0": [ "TR-1", @@ -323,6 +321,28 @@ "35(a)(5)", "37(a)(5)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.340.1", + "603A.340.1(b)", + "603A.340.1(c)", + "603A.340.1(d)", + "603A.340.1(e)", + "603A.345.1", + "603A.346.1", + "603A.495.1", + "603A.495.1(a)", + "603A.495.1(b)", + "603A.495.1(c)", + "603A.495.1(d)", + "603A.495.1(e)", + "603A.495.1(f)", + "603A.495.1(g)", + "603A.495.1(h)", + "603A.495.1(i)", + "603A.495.1(j)", + "603A.495.1(k)", + "603A.495.2" + ], "usa-state-or-ors-646a-2025": [ "646A.578(1)(a)", "646A.578(4)", @@ -421,31 +441,84 @@ "Article 14.4", "Article 14.5(a)" ], - "emea-bel-act-8-1992": [ - "9" + "emea-aut-dpa-2018": [ + "§ 43(1)", + "§ 43(2)", + "§ 43(3)", + "§ 43(4)" ], - "emea-deu-fdpa-2017": [ - "Sec 4", - "Sec 19" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 37(1)", + "Title 2, Chapter III, Art. 37(2)", + "Title 4, Chapter III, Section 1, Art. 193" ], - "emea-ita-pdpc-2003": [ - "11", - "13", - "37" + "emea-deu-fdpa-2017": [ + "3.2.51(4)", + "3.3.55", + "3.3.55.1", + "3.3.55.2", + "3.3.55.3", + "3.3.55.4", + "3.3.55.5", + "3.3.56(1)", + "3.3.56(1)1", + "3.3.56(1)2", + "3.3.56(1)3", + "3.3.56(1)4", + "3.3.56(1)5", + "3.3.56(2)1", + "3.3.56(2)2", + "3.3.56(2)3", + "3.3.56(3)" + ], + "emea-grc-pirppd-1997": [ + "C.11.1", + "C.11.1.a", + "C.11.1.b", + "C.11.1.c", + "C.11.1.d", + "C.11.2", + "C.11.3" + ], + "emea-hun-act-cxii-2011": [ + "II.5.6(4)", + "II.7.8(1)(a)", + "II.14.20(1)", + "II.14.20(2)", + "II.14.20(4)(a)", + "II.14.20(4)(b)", + "II.14.20(4)(d)" + ], + "emea-irl-dpa-2018": [ + "s.90" + ], + "emea-isr-ppl-5741-2025": [ + "s.11" + ], + "emea-ita-pdpc-2018": [ + "Article 2-d(2)", + "Article 77(1)(a)", + "Article 77(1)(b)", + "Article 78(1)", + "Article 78(2)", + "Article 78(3)", + "Article 132-c(1)" ], "emea-ken-pda-2019": [ - "25(e)", - "26(a)", - "29(a)", - "29(b)", - "29(c)", - "29(d)", - "29(e)", - "29(f)", - "29(g)", - "29(h)" + "IV.25(e)", + "IV.26(a)", + "IV.29", + "IV.29(a)", + "IV.29(b)", + "IV.29(c)", + "IV.29(d)", + "IV.29(e)", + "IV.29(f)", + "IV.29(g)", + "IV.29(h)" ], "emea-nga-dpr-2019": [ + "2.3(1)", "2.5", "2.5(a)", "2.5(b)", @@ -457,6 +530,7 @@ "2.5(h)", "2.5(i)", "3.1(1)", + "3.1(7)", "3.1(7)(a)", "3.1(7)(b)", "3.1(7)(c)", @@ -471,34 +545,21 @@ "3.1(7)(l)", "3.1(7)(m)", "3.1(7)(n)", - "3.1(9)", - "3.1(9)(a)", - "3.1(9)(b)", - "3.1(9)(c)", - "3.1(9)(d)", - "3.1(9)(e)" + "3.1(8)" ], - "emea-nor-pda-2018": [ - "31" - ], - "emea-pol-act-29-1997": [ - "23" + "emea-pol-act-10-2018": [ + "Art. 11" ], "emea-qat-pdppl-2020": [ - "6.1", - "8.1", - "9.1", - "9.3", - "9.4", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" - ], - "emea-rus-federal-law-27-2006": [ - "22" + "3.9", + "3.9.1", + "3.9.2", + "3.9.3", + "3.9.4", + "4.17.1" + ], + "emea-rus-152-fz-2025": [ + "Art. 18" ], "emea-sau-pdpl-2023": [ "Article 4.1", @@ -509,22 +570,77 @@ "Article 13.6" ], "emea-srb-act-9-2018": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" + "III.1.21", + "III.2.23-1", + "III.2.23-1(1)", + "III.2.23-1(2)", + "III.2.23-1(3)", + "III.2.23-1(4)", + "III.2.23-1(5)", + "III.2.23-1(6)", + "III.2.23-2", + "III.2.23-2(1)", + "III.2.23-2(2)", + "III.2.23-2(3)", + "III.2.23-2(4)", + "III.2.23-2(5)", + "III.2.23-2(6)", + "III.2.24-1", + "III.2.24-1(1)", + "III.2.24-1(2)", + "III.2.24-1(3)", + "III.2.24-1(4)", + "III.2.24-1(5)", + "III.2.24-1(6)", + "III.2.24-2", + "III.2.24-2(1)", + "III.2.24-2(2)", + "III.2.24-2(3)", + "III.2.24-2(4)", + "III.2.24-2(5)", + "III.2.24-2(6)", + "III.2.24-2(7)", + "III.2.24-3", + "III.2.24-3(1)", + "III.2.24-3(2)", + "III.2.24-3(3)" ], "emea-zaf-popia-2013": [ - "18" - ], - "emea-esp-decree-1720-2007": [ - "8" + "3.A.3.13(1)", + "3.A.3.13(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" + ], + "emea-che-fadp-2025": [ + "2.2.15.3", + "3.19.1", + "3.19.2", + "3.19.2.a", + "3.19.2.b", + "3.19.2.c", + "3.19.3", + "3.19.4", + "3.19.5", + "3.21.1" ], "emea-tur-lppd-2016": [ - "10" + "10(1)", + "10(1)(a)", + "10(1)(b)", + "10(1)(c)", + "10(1)(ç)", + "10(1)(d)", + "11(1)", + "11(1)(a)", + "11(1)(b)", + "11(1)(c)", + "11(1)(ç)", + "11(1)(d)", + "11(1)(e)", + "11(1)(f)", + "11(1)(g)", + "11(1)(ğ)" ], "emea-gbr-def-stan-05-138-2024": [ "2406", @@ -541,26 +657,93 @@ "2406", "2407" ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 8" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 5" + "emea-gbr-dpa-2018": [ + "Section 44(1)", + "Section 44(1)(a)", + "Section 44(1)(b)", + "Section 44(1)(c)", + "Section 44(1)(d)", + "Section 44(1)(d)(i)", + "Section 44(1)(d)(ii)", + "Section 44(1)(d)(iii)", + "Section 44(1)(e)", + "Section 44(2)", + "Section 44(2)(b)", + "Section 44(2)(c)", + "Section 44(2)(d)", + "Section 44(3)", + "Section 69(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 1", - "APP 5" + "1.1.3", + "1.1.4", + "1.1.4.a", + "1.1.4.b", + "1.1.4.c", + "1.1.4.d", + "1.1.4.e", + "1.1.4.f", + "1.1.4.g", + "1.1.5", + "1.1.5.a", + "1.1.5.b", + "1.1.6", + "2.5.1", + "2.5.1.a", + "2.5.1.b", + "2.5.2", + "2.5.2.a", + "2.5.2.b", + "2.5.2.b.i", + "2.5.2.b.ii", + "2.5.2.c", + "2.5.2.d", + "2.5.2.e", + "2.5.2.f", + "2.5.2.g", + "2.5.2.h", + "2.5.2.i", + "2.5.2.j" ], "apac-chn-pipl-2021": [ - "7", - "17", - "17(1)", - "17(2)", - "17(3)", - "17(4)", - "27", - "39", - "48" + "Article 17", + "Article 18", + "Article 30", + "Article 39" + ], + "apac-hkg-pdo-2022": [ + "35C(2)", + "35C(2)(a)", + "35C(2)(a)(i)", + "35C(2)(a)(ii)", + "35C(2)(b)", + "35C(2)(b)(i)", + "35C(2)(b)(ii)", + "35C(2)(c)", + "35C(3)", + "35C(4)", + "35C(5)", + "35J(2)", + "35J(2)(a)", + "35J(2)(a)(i)", + "35J(2)(a)(ii)", + "35J(2)(b)", + "35J(2)(b)(i)", + "35J(2)(b)(ii)", + "35J(2)(b)(iii)", + "35J(2)(b)(iv)", + "35J(2)(c)", + "35J(3)", + "35J(4)", + "35J(5)", + "35J(5)(a)", + "35J(5)(b)", + "Schedule 1 - 1(3)(a)", + "Schedule 1 - 1(3)(b)(ii)(B)", + "Schedule 1 - 5", + "Schedule 1 - 5(a)", + "Schedule 1 - 5(b)", + "Schedule 1 - 5(c)" ], "apac-ind-dpdpa-2023": [ "5(1)(i)", @@ -572,71 +755,214 @@ "6(3)", "6(10)" ], - "apac-jpn-ppi-2020": [ - "15(1)", - "15(2)" + "apac-ind-privacy-rules-2011": [ + "4", + "4(i)", + "4(ii)", + "4(iii)", + "4(iv)", + "4(v)", + "5(3)", + "5(3)(a)", + "5(3)(b)", + "5(3)(c)", + "5(3)(d)", + "5(3)(d)(i)", + "5(3)(d)(ii)" + ], + "apac-jpn-appi-2020": [ + "IV.1.18(1)", + "IV.1.18(2)", + "IV.1.18(3)", + "IV.1.23(2)", + "IV.1.23(2)(i)", + "IV.1.23(2)(ii)", + "IV.1.23(2)(iii)", + "IV.1.23(2)(iv)", + "IV.1.23(2)(v)", + "IV.1.23(2)(vi)", + "IV.1.23(2)(vii)", + "IV.1.23(2)(viii)", + "IV.1.27(1)", + "IV.1.27(1)(i)", + "IV.1.27(1)(ii)", + "IV.1.27(1)(iii)", + "IV.1.27(1)(iv)" ], "apac-mys-pdpa-2010": [ - "7" + "7(1)", + "7(1)(a)", + "7(1)(b)", + "7(1)(c)", + "7(1)(d)", + "7(1)(e)", + "7(1)(f)", + "7(1)(g)", + "7(1)(h)", + "7(2)", + "7(2)(a)", + "7(2)(b)", + "7(2)(c)", + "7(2)(c)(i)", + "7(2)(c)(ii)" + ], + "apac-mys-bnm-rmit-2025": [ + "16.2" ], "apac-nzl-privacy-act-2020": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" + "3.1.22.3(1)", + "3.1.22.3(1)(a)", + "3.1.22.3(1)(b)", + "3.1.22.3(1)(c)", + "3.1.22.3(1)(d)", + "3.1.22.3(1)(d)(i)", + "3.1.22.3(1)(d)(ii)", + "3.1.22.3(1)(e)", + "3.1.22.3(1)(e)(i)", + "3.1.22.3(1)(e)(ii)", + "3.1.22.3(1)(f)", + "3.1.22.3(1)(g)", + "4.1.45(1)", + "4.1.45(1)(a)", + "4.1.45(1)(b)", + "4.1.45(1)(c)", + "4.1.45(2)" ], "apac-sgp-pdpa-2012": [ - "14" + "3.11(5)", + "3.11(5A)", + "4.1.14(1)(a)", + "4.1.15A(4)(b)", + "4.1.15A(4)(b)(i)", + "4.1.15A(4)(b)(ii)", + "4.1.15A(4)(b)(iii)", + "4.2.20(1)(a)", + "4.2.20(1)(b)", + "4.2.20(1)(c)", + "4.2.20(2)" + ], + "apac-sgp-mas-trm-2021": [ + "14.4.1" ], "apac-kor-pipa-2011": [ - "3", - "4" + "III.1.18(3)", + "III.1.18(3)1", + "III.1.18(3)2", + "III.1.18(3)3", + "III.1.18(3)4", + "III.1.18(3)5", + "IV.30(1)", + "IV.30(1)1", + "IV.30(1)2", + "IV.30(1)3", + "IV.30(1)4", + "IV.30(1)5", + "IV.30(1)6", + "IV.30(2)", + "IV.30(3)" ], "apac-twn-pdpa-2025": [ - "5" + "I.8-1", + "I.8.1-1", + "I.8.2-1", + "I.8.3-1", + "I.8.4-1", + "I.8.5-1", + "I.8.6-1", + "I.8-2", + "I.8.1-2", + "I.8.2-2", + "I.8.3-2", + "I.8.4-2", + "I.8.5-2", + "I.8.6-2", + "I.9", + "I.9.1", + "I.9.2", + "I.9.3", + "I.9.4", + "I.9.5" + ], + "americas-bhs-dpa-2003": [ + "II.8(1)", + "II.8(1)(a)", + "II.8(1)(b)", + "II.8(1)(c)", + "II.8(1)(d)", + "II.8(1)(e)", + "II.8(1)(f)", + "II.8(1)(g)", + "II.8(1)(g)(i)", + "II.8(1)(g)(ii)", + "II.8(1)(g)(iii)", + "II.8(1)(h)", + "II.8(1)(i)", + "II.8(2)", + "II.8(2)(a)", + "II.8(2)(b)", + "IV.24(1)(a)", + "IV.24(1)(b)", + "IV.24(1)(b)(i)", + "IV.24(1)(b)(ii)", + "IV.24(1)(b)(iii)", + "IV.24(1)(b)(iv)", + "IV.24(1)(b)(v)", + "IV.24(1)(c)", + "IV.24(1)(c)(i)", + "IV.24(1)(c)(ii)", + "IV.24(1)(c)(iii)", + "IV.24(1)(d)", + "IV.24(1)(e)", + "IV.24(1)(f)", + "IV.24(1)(g)", + "V.45(8)", + "V.52(3)" ], "americas-bra-lgpd-2018": [ - "6.2", - "6.6", - "8" + "II.I.9", + "II.I.9.I", + "II.I.9.II", + "II.I.9.III", + "II.I.9.IV", + "II.I.9.V", + "II.I.9.VI", + "II.I.9.VII", + "II.I.9.VII.1" ], "americas-can-pipeda-2000": [ - "Principle 2" - ], - "americas-chl-act-19628-1999": [ - "5" + "P2-4.2", + "P2-4.2.1", + "P2-4.2.2", + "P2-4.2.3", + "P8-4.8", + "P8-4.8.1", + "P8-4.8.2", + "P8-4.8.2(a)", + "P8-4.8.2(b)", + "P8-4.8.2(c)", + "P8-4.8.2(d)", + "P8-4.8.2(e)", + "P8-4.8.3" ], "americas-col-law-1581-2012": [ - "12" + "VI.17(c)" ], "americas-mex-fdpa-2010": [ - "7", - "16", - "17", - "18" + "II.7", + "II.12", + "II.15", + "II.16", + "II.16.I", + "II.16.II", + "II.16.III", + "II.16.IV", + "II.16.V", + "II.16.VI", + "II.17", + "II.17.I", + "II.17.II", + "II.18", + "V.36" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.1.json b/docs/api/controls/PRI-03.1.json index 76ae9c98..41bf0714 100644 --- a/docs/api/controls/PRI-03.1.json +++ b/docs/api/controls/PRI-03.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to modify permission to collect, receive, process, store, transmit, share, update and/or dispose selected attributes of their Personal Data (PD).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -88,27 +89,23 @@ "general-nist-800-82-r3": [ "PT-04(01)" ], - "general-scf-dpmp-2025": [ - "2.5" - ], "usa-state-tn-tipa-2025": [ "47-18-3203(a)(2)(E)(i)", "47-18-3203(a)(2)(E)(ii)", "47-18-3203(a)(2)(E)(iii)", "47-18-3203(b)" ], - "emea-srb-act-9-2018": [ - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "apac-chn-pipl-2021": [ + "Article 29" + ], + "apac-jpn-appi-2020": [ + "IV.1.30(5)" ], - "emea-zaf-popia-2013": [ - "11" + "apac-kor-pipa-2011": [ + "III.1.22(2)" ], - "apac-twn-pdpa-2025": [ - "5" + "americas-bra-lgpd-2018": [ + "II.I.9.VII.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.10.json b/docs/api/controls/PRI-03.10.json index 13741dad..2aa275b4 100644 --- a/docs/api/controls/PRI-03.10.json +++ b/docs/api/controls/PRI-03.10.json @@ -3,7 +3,7 @@ "title": "Cease Processing, Storing and/or Sharing Personal Data (PD)", "family": "PRI", "description": "Mechanisms exist to ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation.", - "scf_question": "Does the organization ensure it ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation?", + "scf_question": "Does the organization ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Asset / process owners collect, store, processes, transmit share or use PD only for the purposes identified in the data privacy notice.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54,7 +54,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -70,6 +71,18 @@ ], "apac-ind-dpdpa-2023": [ "6(6)" + ], + "apac-mys-pdpa-2010": [ + "38(2)", + "42(1)", + "42(1)(a)" + ], + "apac-sgp-pdpa-2012": [ + "4.1.16(4)" + ], + "americas-bra-lgpd-2018": [ + "II.IV.15.II", + "II.IV.15.IV" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.11.json b/docs/api/controls/PRI-03.11.json index 831127d9..75133883 100644 --- a/docs/api/controls/PRI-03.11.json +++ b/docs/api/controls/PRI-03.11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of processing changes affecting their Personal Data (PD), including:\n(1) Erasure of PD;\n(2) Remediation of incorrect PD; and/or\n(3) Processing restrictions affecting their PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52,13 +52,25 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "emea-eu-gdpr-2016": [ "Article 18.3", "Article 19" + ], + "emea-deu-fdpa-2017": [ + "3.4.75(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.18(1)" + ], + "apac-jpn-appi-2020": [ + "IV.1.23(3)", + "IV.1.23(6)", + "IV.1.30(3)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.12.json b/docs/api/controls/PRI-03.12.json index 852d2525..a15c36b2 100644 --- a/docs/api/controls/PRI-03.12.json +++ b/docs/api/controls/PRI-03.12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to obtain consent from data subjects to opt-in for the following Personal Data (PD) actions:\n(1) Collecting;\n(2) Receiving; \n(3) Processing;\n(4) Storing;\n(5) Transmitting:\n(6) Sharing; and/or\n(7) Updating.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -68,6 +69,9 @@ "usa-state-va-cdpa-2023": [ "59.1-578.F.1", "59.1-578.F.1.b" + ], + "apac-sgp-pdpa-2012": [ + "9.3.46(2)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.13.json b/docs/api/controls/PRI-03.13.json index bbc68795..a610f277 100644 --- a/docs/api/controls/PRI-03.13.json +++ b/docs/api/controls/PRI-03.13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to obtain parental or guardian consent for Personal Data (PD) processing actions through reasonable consumer expectations, when the data subject is a minor.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -77,6 +78,42 @@ "usa-state-va-cdpa-2023": [ "59.1-578.F.1", "59.1-578.F.1.b" + ], + "emea-ken-pda-2019": [ + "IV.27(a)", + "IV.28(2)(d)", + "IV.33(2)", + "IV.33(4)" + ], + "emea-qat-pdppl-2020": [ + "4.17.2" + ], + "apac-chn-pipl-2021": [ + "Article 31" + ], + "apac-kor-pipa-2011": [ + "III.1.22(5)" + ], + "americas-bhs-dpa-2003": [ + "IV.33(1)", + "IV.33(2)", + "IV.33(3)", + "IV.33(4)", + "IV.33(4)(a)", + "IV.33(4)(b)", + "IV.33(4)(c)" + ], + "americas-bra-lgpd-2018": [ + "II.III.14", + "II.III.14.1", + "II.III.14.2", + "II.III.14.3", + "II.III.14.4", + "II.III.14.5", + "II.III.14.6" + ], + "americas-col-law-1581-2012": [ + "III.7" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.2.json b/docs/api/controls/PRI-03.2.json index 3971a1f1..c122829d 100644 --- a/docs/api/controls/PRI-03.2.json +++ b/docs/api/controls/PRI-03.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to present data subjects with a new or updated consent request to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD) in conjunction with the data action, when:\n(1) The original circumstances under which an individual gave consent have changed; or\n(2) A significant amount of time has passed since an individual gave consent.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -96,10 +97,6 @@ "PT-04(02)", "PT-05(01)" ], - "general-scf-dpmp-2025": [ - "2.3", - "5.14" - ], "usa-federal-doc-data-privacy-framework-2023": [ "III.14.b.i", "III.14.b.ii" @@ -115,48 +112,28 @@ "7221(i)", "7221(k)" ], - "emea-aut-fappd-2000": [ - "Sec 8" - ], - "emea-ken-pda-2019": [ - "32(2)", - "32(3)" - ], - "emea-zaf-popia-2013": [ - "15" - ], - "apac-aus-privacy-principles-2026": [ - "APP 5" - ], - "apac-chn-pipl-2021": [ - "14", - "22", - "23", - "27" - ], - "apac-jpn-ppi-2020": [ - "16(2)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" + "apac-jpn-appi-2020": [ + "IV.1.16(2)" ], "apac-kor-pipa-2011": [ - "22" + "III.1.20(1)", + "III.1.20(1)1", + "III.1.20(1)2", + "III.1.20(1)3", + "III.1.22(1)" ], - "apac-twn-pdpa-2025": [ - "5" - ], - "americas-arg-ppd-2018": [ - "27.3" + "americas-bra-lgpd-2018": [ + "II.I.8.6", + "II.I.9.VII.2" ], "americas-can-pipeda-2000": [ - "Sec 6", - "Sec 7", - "Principle 3" + "P2-4.2.4" + ], + "americas-col-law-1581-2012": [ + "VI.17(m)" ], "americas-mex-fdpa-2010": [ - "7" + "II.16.VI" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.3.json b/docs/api/controls/PRI-03.3.json index a9313380..aac171c2 100644 --- a/docs/api/controls/PRI-03.3.json +++ b/docs/api/controls/PRI-03.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Asset / process owners collect, store, processes, transmit share or use PD only for the purposes identified in the data privacy notice.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to prevent the sale, processing and/or sharing of Personal Data (PD) when:\n(1) Instructed by the data subject; or\n(2) The data subject is a minor, where selling and/or sharing PD is legally prohibited.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -69,15 +69,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.5" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(5)(ii)(A)" + "§ 164.502(a)(5)(ii)(A)" ], "usa-state-co-privacy-act-2021": [ "6-1-1308(1)(b)" @@ -99,14 +97,54 @@ "59.1-578.F.1", "59.1-578.F.1.a" ], + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 7" + ], + "emea-grc-pirppd-1997": [ + "B.7.1", + "B.9.1", + "B.9.1.a" + ], + "emea-hun-act-cxii-2011": [ + "II.5.6(3)" + ], + "emea-ita-pdpc-2018": [ + "Article 2-d(1)" + ], + "emea-ken-pda-2019": [ + "IV.36" + ], + "emea-qat-pdppl-2020": [ + "3.12" + ], "emea-srb-act-9-2018": [ - "37" + "II.16" ], - "apac-aus-privacy-principles-2026": [ - "APP 7" + "emea-zaf-popia-2013": [ + "3.C.34", + "3.C.35(1)", + "3.C.35(1)(a)", + "3.C.35(1)(b)", + "3.C.35(1)(c)", + "3.C.35(1)(d)", + "3.C.35(1)(d)(i)", + "3.C.35(1)(d)(ii)", + "3.C.35(1)(d)(iii)", + "3.C.35(1)(e)", + "3.C.35(2)", + "3.C.35(3)", + "3.C.35(3)(a)", + "3.C.35(3)(a)(i)", + "3.C.35(3)(a)(ii)", + "3.C.35(3)(b)", + "3.C.35(3)(b)(i)", + "3.C.35(3)(b)(ii)", + "3.C.35(3)(b)(iii)", + "3.C.35(3)(c)", + "3.C.35(3)(d)" ], - "apac-chn-pipl-2021": [ - "10" + "apac-jpn-appi-2020": [ + "IV.1.23(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.4.json b/docs/api/controls/PRI-03.4.json index bacaa698..de9692cc 100644 --- a/docs/api/controls/PRI-03.4.json +++ b/docs/api/controls/PRI-03.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to revoke consent to collect, receive, process, store, transmit, share and/or update their Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -85,12 +86,14 @@ "general-nist-800-82-r3": [ "PT-04(03)" ], - "general-scf-dpmp-2025": [ - "2.3" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)(ii)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.3(d)", + "603A.505.1(c)", + "603A.535.4" + ], "usa-state-or-ors-646a-2025": [ "646A.576(7)", "646A.578(1)(d)" @@ -101,28 +104,53 @@ "emea-eu-gdpr-2016": [ "Article 7.3" ], + "emea-deu-fdpa-2017": [ + "3.2.51(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.15.21(1)(a)", + "II.15.21(1)(b)" + ], "emea-ken-pda-2019": [ - "26(c)", - "32(2)", - "32(3)" + "IV.26(c)", + "IV.32(2)", + "IV.32(3)" ], "emea-nga-dpr-2019": [ - "2.8", "2.8(a)", - "2.8(b)" + "3.1(9)(b)" ], "emea-qat-pdppl-2020": [ - "5.1" + "2.5.1" ], "emea-sau-pdpl-2023": [ "Article 5.2" ], "emea-srb-act-9-2018": [ - "15", - "37" + "III.3.30-1(2)", + "III.4.37" + ], + "emea-zaf-popia-2013": [ + "3.A.2.11(2)(b)", + "3.A.2.11(3)", + "3.A.2.11(3)(a)", + "3.A.2.11(3)(b)", + "3.A.2.11(4)" + ], + "emea-gbr-dpa-2018": [ + "Section 47(4)" ], "apac-chn-pipl-2021": [ - "15" + "Article 15" + ], + "apac-hkg-pdo-2022": [ + "35G(1)", + "35L(1)", + "35L(1)(a)", + "35L(1)(b)", + "35L(2)", + "35L(3)", + "35L(4)" ], "apac-ind-dpdpa-2023": [ "5(2)(b)", @@ -130,6 +158,34 @@ "6(7)", "8(7)(a)", "8(8)(b)" + ], + "apac-jpn-appi-2020": [ + "IV.1.30(1)" + ], + "apac-mys-pdpa-2010": [ + "38(1)", + "43(1)" + ], + "apac-sgp-pdpa-2012": [ + "4.1.16(1)", + "9.3.47(1)" + ], + "apac-kor-pipa-2011": [ + "V.37(1)" + ], + "americas-bra-lgpd-2018": [ + "II.I.8.5", + "II.IV.15.III" + ], + "americas-can-pipeda-2000": [ + "P3-4.3.8" + ], + "americas-col-law-1581-2012": [ + "IV.8(e)" + ], + "americas-mex-fdpa-2010": [ + "II.8", + "III.25" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.5.json b/docs/api/controls/PRI-03.5.json index f7370a5f..e00c2926 100644 --- a/docs/api/controls/PRI-03.5.json +++ b/docs/api/controls/PRI-03.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to prevent discrimination against a data subject for exercising their legal rights pertaining to modifying or revoking consent, including prohibiting:\n(1) Refusing products and/or services;\n(2) Charging different rates for goods and/or services; and\n(3) Providing different levels of quality.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -66,7 +66,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -74,13 +75,10 @@ "C3.1-POF2", "C3.1-POF3" ], - "general-scf-dpmp-2025": [ - "2.4" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.508(c)(2)(ii)(A)", - "164.508(c)(2)(ii)(B)", - "164.514(f)(2)(iii)" + "§ 164.508(c)(2)(ii)(A)", + "§ 164.508(c)(2)(ii)(B)", + "§ 164.514(f)(2)(iii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7080(a)", @@ -91,6 +89,9 @@ "6-1-1308(1)(c)(I)", "6-1-1308(1)(c)(II)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.535.2" + ], "usa-state-or-cpa-2023": [ "Section 5(2)(d)" ], @@ -102,14 +103,21 @@ "59.1-577.1.E", "59.1-578.A.4" ], + "emea-deu-fdpa-2017": [ + "3.3.59(3)" + ], "emea-ken-pda-2019": [ - "32(4)" + "IV.32(4)" ], "emea-sau-pdpl-2023": [ "Article 7" ], "apac-chn-pipl-2021": [ - "16" + "Article 16" + ], + "apac-kor-pipa-2011": [ + "III.1.16(2)", + "III.1.22(4)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.6.json b/docs/api/controls/PRI-03.6.json index 572ef117..a99a2bc8 100644 --- a/docs/api/controls/PRI-03.6.json +++ b/docs/api/controls/PRI-03.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to authorize another person or entity (e.g., authorized agent, proxy, etc.), acting on the data subject's behalf, to make Personal Data (PD) processing decisions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46,14 +46,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.6" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)", "Sec. 6502.(b)(1)(B)(ii)" @@ -62,10 +59,10 @@ "II.2.b" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(g)(1)", - "164.502(g)(2)", - "164.502(g)(3)(i)", - "164.502(g)(3)(i)(A)" + "§ 164.502(g)(1)", + "§ 164.502(g)(2)", + "§ 164.502(g)(3)(i)", + "§ 164.502(g)(3)(i)(A)" ], "usa-state-ca-ccpa-cpra-2026": [ "7026(j)", @@ -108,28 +105,32 @@ "Article 8.1", "Article 8.2" ], + "emea-hun-act-cxii-2011": [ + "II.5.6(2)" + ], + "emea-ita-pdpc-2018": [ + "Article 82(2)(a)" + ], "emea-ken-pda-2019": [ - "27(a)", - "27(b)", - "27(c)" + "IV.27(a)", + "IV.27(b)", + "IV.27(c)", + "IV.28(2)(d)" ], - "emea-qat-pdppl-2020": [ - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "apac-chn-pipl-2021": [ + "Article 49" ], "apac-ind-dpdpa-2023": [ "6(7)", "9(1)", "14(1)" ], - "apac-jpn-ppi-2020": [ - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" + "apac-phl-dpa-2012": [ + "IV.17" + ], + "apac-kor-pipa-2011": [ + "V.38(1)", + "V.38(2)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.7.json b/docs/api/controls/PRI-03.7.json index 8f8e3710..5401a1c0 100644 --- a/docs/api/controls/PRI-03.7.json +++ b/docs/api/controls/PRI-03.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to compel data subjects to select the level of consent deemed appropriate by the data subject for the relevant business purpose (e.g., opt-in, opt-out, accept all cookies, etc.).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -77,9 +78,6 @@ "general-oecd-privacy-principles-2010": [ "1" ], - "general-scf-dpmp-2025": [ - "6.0" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.2.c", "III.12.a", @@ -111,9 +109,14 @@ "59.1-577.A", "59.1-577.A.5" ], + "emea-hun-act-cxii-2011": [ + "II.14.20(1)" + ], "emea-ken-pda-2019": [ - "26(a)", - "26(c)" + "IV.28(1)" + ], + "emea-zaf-popia-2013": [ + "3.A.2.12(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.8.json b/docs/api/controls/PRI-03.8.json index 423c20b1..ce9eab61 100644 --- a/docs/api/controls/PRI-03.8.json +++ b/docs/api/controls/PRI-03.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically provide data subjects with functionality to exercise pre-selected opt-out preferences (e.g., opt-out signal).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,13 +67,11 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.7" - ], "usa-state-ca-ccpa-cpra-2026": [ "7025(a)", "7025(b)", diff --git a/docs/api/controls/PRI-03.9.json b/docs/api/controls/PRI-03.9.json index 7c5d196d..4532c136 100644 --- a/docs/api/controls/PRI-03.9.json +++ b/docs/api/controls/PRI-03.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to govern the continued use of Personal Data (PD) as it is collected, received, processed, stored, transmitted, shared and/or updated until:\n(1) Disposal of PD occurs when there is no longer a legitimate business purpose;\n(2) Disposal of PD occurs when the data retention timeline for the use case is met; and/or\n(3) Continued use of PD is prohibited upon withdrawal of data subject consent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54,7 +54,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -86,10 +87,37 @@ "emea-eu-gdpr-2016": [ "Article 18.2" ], + "emea-ita-pdpc-2018": [ + "Article 99(1)" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 2(1)(b)(i)", + "Schedule 1 - 2(1)(b)(ii)" + ], "apac-ind-dpdpa-2023": [ "5(2)(b)", "9(2)", "9(3)" + ], + "apac-jpn-appi-2020": [ + "IV.1.30(2)", + "IV.1.30(4)", + "IV.1.30(6)", + "IV.1.30(7)", + "IV.1.31" + ], + "apac-sgp-pdpa-2012": [ + "4.2.19(a)", + "9.3.47(3)" + ], + "americas-bhs-dpa-2003": [ + "IV.35(1)", + "IV.35(1)(a)", + "IV.35(1)(b)", + "IV.36(1)" + ], + "americas-chl-act-19628-1999": [ + "I.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-03.json b/docs/api/controls/PRI-03.json index 04188aeb..a517f21a 100644 --- a/docs/api/controls/PRI-03.json +++ b/docs/api/controls/PRI-03.json @@ -1,9 +1,9 @@ { "control_id": "PRI-03", - "title": "Choice & Consent", + "title": "Data Subject Consent", "family": "PRI", - "description": "Mechanisms exist to enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations?", "relative_weight": 7, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to Mechanisms exist to enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -70,8 +70,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -132,11 +134,6 @@ "1", "4(a)" ], - "general-scf-dpmp-2025": [ - "2.0", - "2.1", - "2.2" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.2.a", "II.2.c" @@ -156,17 +153,17 @@ "155.260(a)(3)(iv)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.506(b)(1)", - "164.508(a)(2)", - "164.508(c)(1)(v)", - "164.508(c)(3)", - "164.510(b)(2)(i)", - "164.510(b)(2)(ii)", - "164.510(b)(2)(iii)", - "164.510(b)(3)", - "164.514(f)(2)(ii)", - "164.514(f)(2)(iv)", - "164.514(f)(2)(v)" + "§ 164.506(b)(1)", + "§ 164.508(a)(2)", + "§ 164.508(c)(1)(v)", + "§ 164.508(c)(3)", + "§ 164.510(b)(2)(i)", + "§ 164.510(b)(2)(ii)", + "§ 164.510(b)(2)(iii)", + "§ 164.510(b)(3)", + "§ 164.514(f)(2)(ii)", + "§ 164.514(f)(2)(iv)", + "§ 164.514(f)(2)(v)" ], "usa-federal-cms-marse-2-0": [ "IP-1", @@ -201,6 +198,22 @@ "15(d)(3)", "15(d)(4)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.2(a)", + "603A.500.2(b)", + "603A.500.3", + "603A.500.3(a)", + "603A.500.3(b)", + "603A.500.3(c)", + "603A.500.3(d)", + "603A.535.5", + "603A.535.6", + "603A.535.6(a)", + "603A.535.6(b)", + "603A.535.6(c)", + "603A.535.6(d)", + "603A.535.7" + ], "usa-state-or-ors-646a-2025": [ "646A.578(6)", "646A.583(1)(a)(C)" @@ -233,53 +246,66 @@ "Article 21.5", "Article 21.6" ], - "emea-aut-fappd-2000": [ - "Sec 8" - ], - "emea-bel-act-8-1992": [ - "45754" + "emea-aut-dpa-2018": [ + "§ 8(1)", + "§ 12(1)", + "§ 12(2)", + "§ 12(3)", + "§ 12(4)" ], "emea-deu-fdpa-2017": [ - "Sec 4a", - "Sec 11" + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.27(4)", + "3.2.51(1)", + "3.2.51(2)", + "3.2.51(5)" ], "emea-grc-pirppd-1997": [ - "5" - ], - "emea-hun-isdfi-2011": [ - "6" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "23", - "24" + "B.5.1", + "B.7.2.a" + ], + "emea-hun-act-cxii-2011": [ + "II.5.5(1)(a)", + "II.5.5(2)(a)", + "II.5.6(3)", + "II.5.6(4)", + "II.7.8(1)(a)", + "II.8.9(4)", + "II.11.12(3)(a)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)" + ], + "emea-isr-ppl-5741-2025": [ + "s.1" ], "emea-ken-pda-2019": [ - "32(1)", - "32(4)" + "IV.26(c)", + "IV.28(2)(c)", + "IV.32(4)" ], "emea-nga-dpr-2019": [ - "2.2(a)", "2.3(2)", "2.3(2)(a)", "2.3(2)(b)", "2.3(2)(c)", "2.3(2)(d)", - "2.3(2)(e)" - ], - "emea-pol-act-29-1997": [ - "23" + "2.3(2)(e)", + "2.8(b)", + "2.12(a)", + "3.1(14)(a)", + "3.1(14)(b)", + "3.1(14)(c)" ], "emea-qat-pdppl-2020": [ - "4", - "5.2", - "10" + "2.4", + "2.5.2" ], - "emea-rus-federal-law-27-2006": [ - "6", - "9" + "emea-rus-152-fz-2025": [ + "Art. 6", + "Art. 9", + "Art. 10.1" ], "emea-sau-pdpl-2023": [ "Article 5.1", @@ -292,41 +318,55 @@ "Article 26" ], "emea-srb-act-9-2018": [ - "12.1", - "15", - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "II.15", + "III.3.31" ], "emea-zaf-popia-2013": [ - "11" - ], - "emea-esp-decree-1720-2007": [ - "8", - "12" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 3" + "6.57(1)", + "6.57(1)(a)", + "6.57(1)(a)(i)", + "6.57(1)(a)(ii)", + "6.57(1)(b)", + "6.57(1)(c)", + "6.57(1)(d)", + "6.57(2)", + "6.57(3)", + "6.57(4)" + ], + "emea-che-fadp-2025": [ + "2.1.6.6", + "2.1.6.7", + "2.1.6.7.a", + "2.1.6.7.b", + "2.1.6.7.c" ], "apac-chn-cybersecurity-law-2017": [ "Article 22" ], "apac-chn-pipl-2021": [ - "13(1)", - "14", - "23", - "27", - "29", - "30", - "44" + "Article 14" + ], + "apac-hkg-pdo-2022": [ + "35E(1)", + "35E(1)(a)", + "35E(1)(b)", + "35E(1)(b)(i)", + "35E(1)(b)(ii)", + "35E(1)(b)(iii)", + "35E(1)(c)", + "35E(2)", + "35E(2)(a)", + "35E(2)(b)", + "35E(3)", + "35E(4)", + "Schedule 1 - 1(3)(a)(i)", + "Schedule 1 - 1(3)(a)(ii)", + "Schedule 1 - 1(3)(b)", + "Schedule 1 - 1(3)(b)(i)", + "Schedule 1 - 1(3)(b)(i)(A)", + "Schedule 1 - 1(3)(b)(i)(B)", + "Schedule 1 - 1(3)(b)(ii)", + "Schedule 1 - 1(3)(b)(ii)(A)" ], "apac-ind-dpdpa-2023": [ "4(1)(a)", @@ -339,56 +379,107 @@ "8(8)(b)" ], "apac-ind-privacy-rules-2011": [ - "5" + "5(1)", + "5(7)" ], - "apac-jpn-ppi-2020": [ - "16(1)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)", - "24(1)", - "24(2)" + "apac-jpn-appi-2020": [ + "IV.1.26-2(1)(i)", + "IV.1.26-2(1)(ii)" ], "apac-mys-pdpa-2010": [ - "7" + "7(3)" ], "apac-phl-dpa-2012": [ - "19" + "III.12(a)" ], "apac-sgp-pdpa-2012": [ - "13" + "4.1.13", + "4.1.14(1)(b)", + "4.1.14(3)", + "4.1.14(4)", + "4.1.15(1)", + "4.1.15(1)(a)", + "4.1.15(1)(b)", + "4.1.15(2)", + "4.1.15(3)", + "4.1.15(6)", + "4.1.15(6)(a)(i)", + "4.1.15(6)(a)(ii)", + "4.1.15(6)(b)", + "4.1.15(6)(c)", + "4.1.15(7)", + "4.1.15(9)(a)", + "4.1.15(9)(b)", + "9.3.46(1)" ], "apac-kor-pipa-2011": [ - "3", - "4", - "22" + "III.1.15(2)", + "III.1.15(2)1", + "III.1.15(2)2", + "III.1.15(2)3", + "III.1.15(2)4", + "III.1.17(1)", + "III.1.17(1)1", + "III.1.17(1)2", + "III.1.17(2)", + "III.1.17(2)1", + "III.1.17(2)2", + "III.1.17(2)3", + "III.1.17(2)4", + "III.1.17(2)5", + "III.1.17(3)", + "III.1.22(3)" ], "apac-twn-pdpa-2025": [ - "5" - ], - "americas-arg-ppd-2018": [ - "5.1", - "5.2" + "I.7" + ], + "americas-bhs-dpa-2003": [ + "II.7(1)", + "IV.32(1)", + "IV.32(2)", + "IV.32(2)(a)", + "IV.32(2)(b)", + "IV.32(2)(c)", + "IV.32(3)", + "IV.32(4)", + "IV.32(5)", + "IV.32(6)", + "IV.36(2)" ], "americas-bra-lgpd-2018": [ - "7.1", - "15" + "II.I.7.I", + "II.I.8", + "II.I.8.1", + "II.I.8.2", + "II.I.8.3", + "II.I.8.4" ], "americas-can-pipeda-2000": [ - "Sec 6", - "Sec 7", - "Principle 3" + "P2-4.2.5", + "P3-4.3", + "P3-4.3.1", + "P3-4.3.2", + "P3-4.3.3", + "P3-4.3.4", + "P3-4.3.5", + "P3-4.3.6", + "P3-4.3.7", + "P3-4.3.7(a)", + "P3-4.3.7(b)", + "P3-4.3.7(c)", + "P3-4.3.7(d)" ], "americas-chl-act-19628-1999": [ - "4" + "I.4", + "I.8" ], "americas-col-law-1581-2012": [ - "4" + "II.4(c)", + "VI.17(b)" ], "americas-mex-fdpa-2010": [ - "8", - "10" + "II.8", + "II.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-04.1.json b/docs/api/controls/PRI-04.1.json index e82f95e1..85e03724 100644 --- a/docs/api/controls/PRI-04.1.json +++ b/docs/api/controls/PRI-04.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -108,9 +109,6 @@ "1", "4(b)" ], - "general-scf-dpmp-2025": [ - "3.1" - ], "general-shared-assessments-sig-2025": [ "P.6" ], @@ -133,11 +131,11 @@ "3" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(1)(i)", - "164.502(a)(1)(ii)", - "164.502(a)(1)(iii)", - "164.502(a)(5)(i)", - "164.502(i)" + "§ 164.502(a)(1)(i)", + "§ 164.502(a)(1)(ii)", + "§ 164.502(a)(1)(iii)", + "§ 164.502(a)(5)(i)", + "§ 164.502(i)" ], "usa-federal-irs-1075-2021": [ "PT-2" @@ -189,198 +187,106 @@ "Article 9.3", "Article 10" ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(4)", + "Title 2, Chapter II, Art. 33(1)", + "Title 2, Chapter II, Art. 33(2)" ], "emea-deu-fdpa-2017": [ - "Sec 4" + "2.1.2.26(1)", + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.26(4)", + "3.2.49", + "3.2.50" ], "emea-grc-pirppd-1997": [ - "4" - ], - "emea-hun-isdfi-2011": [ - "4", - "5" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "11" + "B.4.1.a", + "B.4.1.b", + "B.5.2", + "B.5.2.a", + "B.5.2.b", + "B.5.2.c", + "B.5.2.d", + "B.5.2.e", + "B.8.3" + ], + "emea-hun-act-cxii-2011": [ + "II.4.4(1)", + "II.4.4(2)", + "II.4.4(3)", + "II.4.4(5)", + "II.5.5(1)(b)", + "II.5.5(2)(b)", + "II.5.5(2)(c)", + "II.5.5(3)", + "II.5.5(4)", + "II.5.6(1)(b)", + "II.5.6(5)(a)", + "II.10.11(1)(b)", + "II.11.12(1)" ], "emea-ken-pda-2019": [ - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)" + "IV.25(a)", + "IV.28(3)" ], "emea-nga-dpr-2019": [ - "2.1(1)(a)", - "2.1(1)(a)(i)", - "2.1(1)(a)(ii)", - "2.2(a)", - "2.2(b)", - "2.2(c)", - "2.2(d)", - "2.2(e)", - "2.4(a)" - ], - "emea-pol-act-29-1997": [ - "23" + "2.3(1)" ], - "emea-qat-pdppl-2020": [ - "9.2", - "18.1", - "18.2", - "18.3", - "18.4" + "emea-nor-pda-2018": [ + "8" ], - "emea-rus-federal-law-27-2006": [ - "5" + "emea-qat-pdppl-2020": [ + "2.4", + "3.11.1" ], "emea-sau-pdpl-2023": [ "Article 13.1" ], "emea-srb-act-9-2018": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "7", - "7.1", - "7.2", - "14", - "20" + "II.14" ], "emea-zaf-popia-2013": [ - "2", - "3", - "4" - ], - "emea-esp-decree-1720-2007": [ - "8" + "3.A.2.11(1)", + "3.A.2.11(1)(a)", + "3.A.2.11(1)(b)", + "3.A.2.11(1)(c)", + "3.A.2.11(1)(d)", + "3.A.2.11(1)(e)", + "3.A.2.11(1)(f)" ], - "emea-che-fadp-2025": [ - "4" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "emea-gbr-dpa-2018": [ + "Section 44(2)(a)" ], "apac-aus-privacy-principles-2026": [ - "APP 3", - "APP 7" - ], - "apac-chn-pipl-2021": [ - "5", - "10", - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "26", - "29", - "30", - "47" + "2.3.1", + "2.3.2" ], "apac-ind-dpdpa-2023": [ "4(1)(b)" ], - "apac-ind-privacy-rules-2011": [ - "5" - ], - "apac-jpn-ppi-2020": [ - "17(1)", - "17(2)", - "17(2)(i)", - "17(2)(ii)", - "17(2)(iii)", - "17(2)(iv)", - "17(2)(v)", - "17(2)(vi)" - ], - "apac-phl-dpa-2012": [ - "19" - ], "apac-sgp-pdpa-2012": [ - "17" - ], - "apac-kor-pipa-2011": [ - "3", - "15" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "5.2", - "7.1", - "7.2", - "7.4", - "8" + "4.1.17(1)(a)" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.1", - "10", - "11" + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.36(3)", + "IV.36(3)(a)", + "IV.36(3)(b)", + "IV.36(3)(c)", + "IV.36(3)(c)(i)", + "IV.36(3)(c)(ii)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 4" + "P4-4.4" ], - "americas-col-law-1581-2012": [ - "4" + "americas-chl-act-19628-1999": [ + "I.4" ], "americas-mex-fdpa-2010": [ - "7" + "II.7" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-04.2.json b/docs/api/controls/PRI-04.2.json index e4b18081..c1d99d64 100644 --- a/docs/api/controls/PRI-04.2.json +++ b/docs/api/controls/PRI-04.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure information is directly collected from the data subject, whenever possible.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -73,39 +74,19 @@ "P.5.3" ], "emea-ken-pda-2019": [ - "28(1)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)" + "IV.28(1)" ], "emea-sau-pdpl-2023": [ "Article 10" ], - "apac-chn-pipl-2021": [ - "10" + "apac-aus-privacy-principles-2026": [ + "2.3.6", + "2.3.6.a", + "2.3.6.a.ii", + "2.3.6.b" ], "apac-nzl-privacy-act-2020": [ - "Principle 2", - "P2-(1)", - "P2-(2)", - "P2-(2)(a)", - "P2-(2)(b)", - "P2-(2)(c)", - "P2-(2)(d)", - "P2-(2)(e)(i)", - "P2-(2)(e)(ii)", - "P2-(2)(e)(iii)", - "P2-(2)(e)(iv)", - "P2-(2)(e)(v)", - "P2-(2)(f)", - "P2-(2)(g)(i)", - "P2-(2)(g)(ii)" + "3.1.22.2(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-04.3.json b/docs/api/controls/PRI-04.3.json index 9b7375b3..e2773898 100644 --- a/docs/api/controls/PRI-04.3.json +++ b/docs/api/controls/PRI-04.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -64,12 +64,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": { - "apac-chn-pipl-2021": [ - "26" - ] - } + "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/PRI-04.4.json b/docs/api/controls/PRI-04.4.json index cf2ea041..c9e20512 100644 --- a/docs/api/controls/PRI-04.4.json +++ b/docs/api/controls/PRI-04.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -46,7 +46,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -54,17 +55,6 @@ "Article 10", "Article 14", "Article 15.2" - ], - "emea-srb-act-9-2018": [ - "20" - ], - "apac-jpn-ppi-2020": [ - "18(1)", - "18(2)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-04.5.json b/docs/api/controls/PRI-04.5.json index c3fa23db..f2c98a25 100644 --- a/docs/api/controls/PRI-04.5.json +++ b/docs/api/controls/PRI-04.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-04.6.json b/docs/api/controls/PRI-04.6.json index aafa3c31..a299ca7d 100644 --- a/docs/api/controls/PRI-04.6.json +++ b/docs/api/controls/PRI-04.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-04.7.json b/docs/api/controls/PRI-04.7.json index c737ee73..14395ec8 100644 --- a/docs/api/controls/PRI-04.7.json +++ b/docs/api/controls/PRI-04.7.json @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -62,6 +63,9 @@ "general-iso-29100-2024": [ "6.7" ], + "emea-deu-fdpa-2017": [ + "3.3.56(2)" + ], "emea-sau-pdpl-2023": [ "Article 11.2" ] diff --git a/docs/api/controls/PRI-04.json b/docs/api/controls/PRI-04.json index 342643ab..a0840e88 100644 --- a/docs/api/controls/PRI-04.json +++ b/docs/api/controls/PRI-04.json @@ -1,9 +1,9 @@ { "control_id": "PRI-04", - "title": "Restrict Collection To Identified Purpose", + "title": "Restrict Collection, Processing & Sharing To Identified Purpose", "family": "PRI", - "description": "Mechanisms exist to minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", - "scf_question": "Does the organization minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent?", + "description": "Mechanisms exist to minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", + "scf_question": "Does the organization minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -72,8 +72,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -117,9 +119,6 @@ "general-nist-800-82-r3": [ "PT-02" ], - "general-scf-dpmp-2025": [ - "3.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(a)(1)" ], @@ -150,6 +149,15 @@ "usa-state-il-ipa-2009": [ "10(b)(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.495.3(a)", + "603A.495.3(c)", + "603A.500.1(a)", + "603A.500.1(b)", + "603A.535.1", + "603A.535.1(a)", + "603A.535.1(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.578(1)(b)" ], @@ -179,170 +187,62 @@ "Article 5.1(c)", "Article 8.1" ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 29(1)", + "Title 2, Chapter II, Art. 29(2)" ], "emea-deu-fdpa-2017": [ - "Sec 4" + "3.1.47.2", + "3.1.47.3", + "3.1.47.6" ], "emea-grc-pirppd-1997": [ - "4" - ], - "emea-hun-isdfi-2011": [ - "4", - "5" + "B.4.1.a", + "B.4.1.b" ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "11" + "emea-hun-act-cxii-2011": [ + "II.4.4(1)", + "II.4.4(2)", + "II.11.12(1)", + "II.12.13(2)" ], "emea-ken-pda-2019": [ - "25(c)", - "25(d)", - "27(a)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)" - ], - "emea-pol-act-29-1997": [ - "23" + "IV.25(c)", + "IV.27(a)" ], "emea-qat-pdppl-2020": [ - "9.1", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" - ], - "emea-rus-federal-law-27-2006": [ - "5" - ], - "emea-srb-act-9-2018": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "16" - ], - "emea-zaf-popia-2013": [ - "5", - "11", - "69" - ], - "emea-esp-decree-1720-2007": [ - "8" + "3.12" ], "emea-che-fadp-2025": [ - "4" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 3" - ], - "apac-chn-pipl-2021": [ - "26", - "31" + "2.1.6.3" ], "apac-ind-privacy-rules-2011": [ - "5" - ], - "apac-jpn-ppi-2020": [ - "17(1)" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 1", - "P1-(1)(a)", - "P1-(1)(b)", - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)", - "Principle 4", - "P4-(a)", - "P4-(b)", - "P4-(b)(i)", - "P4-(b)(ii)" - ], - "apac-phl-dpa-2012": [ - "19" - ], - "apac-sgp-pdpa-2012": [ - "17" - ], - "apac-kor-pipa-2011": [ - "3", - "15", - "22" + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(5)" ], - "apac-twn-pdpa-2025": [ - "5", - "19" + "apac-jpn-appi-2020": [ + "IV.1.15(2)" ], - "americas-arg-ppd-2018": [ - "4.1", - "4.2", - "6" + "apac-kor-pipa-2011": [ + "III.1.15(1)", + "III.1.15(1)1", + "III.1.15(1)2", + "III.1.15(1)3", + "III.1.15(1)4", + "III.1.15(1)5", + "III.1.15(1)6" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.2" + "II.5(1)(c)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 4" - ], - "americas-col-law-1581-2012": [ - "4" + "P4-4.4" ], "americas-mex-fdpa-2010": [ - "7" + "II.7", + "II.12" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-05.1.json b/docs/api/controls/PRI-05.1.json index f0081805..e6831d8b 100644 --- a/docs/api/controls/PRI-05.1.json +++ b/docs/api/controls/PRI-05.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to address the use of Personal Data (PD) for internal testing, training and research that:\n(1) Takes measures to limit or minimize the amount of PD used for internal testing, training and research purposes; and\n(2) Authorizes the use of PD when such information is required for internal testing, training and research.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -156,9 +157,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.5.5" ], - "general-scf-dpmp-2025": [ - "3.3" - ], "usa-federal-fbi-cjis-6-0": [ "4.2.2", "4.2.3.1", @@ -196,7 +194,7 @@ "SI-12(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.508(a)(2)(i)(B)" + "§ 164.508(a)(2)(i)(B)" ], "usa-federal-irs-1075-2021": [ "PT-2", @@ -227,158 +225,33 @@ "47-18-3207(b)(3)(B)", "47-18-3207(b)(3)(C)" ], - "emea-aut-fappd-2000": [ - "Sec 12" - ], - "emea-bel-act-8-1992": [ - "4-7", - "21" + "emea-aut-dpa-2018": [ + "§ 7(2)" ], - "emea-hun-isdfi-2011": [ - "9" + "emea-deu-fdpa-2017": [ + "2.1.2.27(3)" ], - "emea-isr-ppl-5741-1981": [ - "8" + "emea-grc-pirppd-1997": [ + "B.7.2.f" ], - "emea-ita-pdpc-2003": [ - "13", - "20" + "emea-ita-pdpc-2018": [ + "Article 99(3)", + "Article 105(1)", + "Article 105(2)", + "Article 105(3)", + "Article 105(4)" ], "emea-ken-pda-2019": [ - "25(a)", - "25(b)", - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "34(1)(a)", - "34(1)(b)", - "34(1)(c)", - "34(1)(d)", - "34(2)(a)", - "34(2)(b)", - "34(3)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)", - "53(1)", - "53(2)", - "53(3)(a)", - "53(3)(b)", - "53(4)" - ], - "emea-nga-dpr-2019": [ - "2.1(1)(b)", - "3.1(12)" - ], - "emea-nor-pda-2018": [ - "11", - "27" - ], - "emea-pol-act-29-1997": [ - "26" - ], - "emea-qat-pdppl-2020": [ - "8.2", - "9.4" - ], - "emea-srb-act-9-2018": [ - "5.1", - "5.3", - "7", - "7.1", - "7.2", - "20" - ], - "emea-zaf-popia-2013": [ - "10" - ], - "emea-esp-decree-1720-2007": [ - "8" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 6" - ], - "apac-chn-pipl-2021": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "28", - "47" - ], - "apac-jpn-ppi-2020": [ - "16-2" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "IV.30(1)(b)(viii)" ], "apac-phl-dpa-2012": [ - "19" - ], - "apac-kor-pipa-2011": [ - "3" - ], - "americas-arg-ppd-2018": [ - "7.3", - "9.2" + "IV.19" ], "americas-bhs-dpa-2003": [ - "6" + "II.5(2)" ], - "americas-col-law-1581-2012": [ - "4" + "americas-bra-lgpd-2018": [ + "II.I.7.IV" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-05.2.json b/docs/api/controls/PRI-05.2.json index 10b2751f..42bb437b 100644 --- a/docs/api/controls/PRI-05.2.json +++ b/docs/api/controls/PRI-05.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n(1) Keeping PD up-to-date; and \n(2) Remediating identified inaccuracies, as necessary.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -98,9 +99,6 @@ "general-nist-800-82-r3-high": [ "PM-24" ], - "general-scf-dpmp-2025": [ - "5.9" - ], "general-shared-assessments-sig-2025": [ "P.5.1" ], @@ -130,68 +128,116 @@ "emea-eu-gdpr-2016": [ "Article 5.1(d)" ], - "emea-ken-pda-2019": [ - "25(f)" + "emea-aut-dpa-2018": [ + "§ 37(6)", + "§ 37(7)" ], - "emea-nor-pda-2018": [ - "11" + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 32(2)" + ], + "emea-deu-fdpa-2017": [ + "3.1.47.4", + "3.4.74(1)" + ], + "emea-hun-act-cxii-2011": [ + "II.4.4(4)", + "II.13.17(1)" + ], + "emea-irl-dpa-2018": [ + "s.74" + ], + "emea-ken-pda-2019": [ + "IV.25(f)" ], "emea-sau-pdpl-2023": [ "Article 14" ], "emea-srb-act-9-2018": [ - "5.4" + "II.11" ], "emea-zaf-popia-2013": [ - "14", - "16" + "3.A.5.16(1)", + "3.A.5.16(2)" ], - "emea-esp-decree-1720-2007": [ - "8" + "emea-che-fadp-2025": [ + "2.1.6.5" ], - "apac-aus-privacy-act-1998": [ - "APP Part 10" + "emea-gbr-dpa-2018": [ + "Section 46(1)", + "Section 47(3)" ], "apac-aus-privacy-principles-2026": [ - "APP 10" + "4.10.1", + "4.10.2" ], "apac-chn-pipl-2021": [ - "8" + "Article 8" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 2(1)(a)", + "Schedule 1 - 2(1)(b)", + "Schedule 1 - 2(1)(c)(i)", + "Schedule 1 - 2(1)(c)(ii)", + "Schedule 1 - 2(1)(c)(ii)(A)", + "Schedule 1 - 2(1)(c)(ii)(B)" ], "apac-ind-dpdpa-2023": [ "8(3)", "8(3)(a)", "8(3)(b)" ], - "apac-jpn-ppi-2020": [ - "19" + "apac-ind-privacy-rules-2011": [ + "5(6)" + ], + "apac-jpn-appi-2020": [ + "IV.1.19" ], "apac-mys-pdpa-2010": [ "11" ], "apac-nzl-privacy-act-2020": [ - "Principle 9" + "3.1.22.8" + ], + "apac-phl-dpa-2012": [ + "III.11(c)" ], "apac-sgp-pdpa-2012": [ - "23" + "6.23", + "6.23(a)", + "6.23(b)", + "6.25", + "6.25(a)", + "6.25(b)" ], - "apac-kor-pipa-2011": [ - "3" + "apac-twn-pdpa-2025": [ + "I.11" ], "americas-arg-ppd-2018": [ - "4.5" + "A.1.3" ], "americas-bhs-dpa-2003": [ - "6" + "II.5(1)(d)", + "II.5(3)", + "II.10(1)", + "II.10(2)", + "II.10(2)(a)", + "II.10(2)(b)" ], "americas-can-pipeda-2000": [ - "Principle 6" + "P6-4.6", + "P6-4.6.1", + "P6-4.6.2", + "P6-4.6.3" + ], + "americas-chl-act-19628-1999": [ + "I.9" ], "americas-col-law-1581-2012": [ - "4" + "VI.17(f)", + "VI.17(g)" ], "americas-mex-fdpa-2010": [ - "9" + "II.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-05.3.json b/docs/api/controls/PRI-05.3.json index c1536780..f1c7107a 100644 --- a/docs/api/controls/PRI-05.3.json +++ b/docs/api/controls/PRI-05.3.json @@ -1,9 +1,9 @@ { "control_id": "PRI-05.3", - "title": "Data Masking", + "title": "Data Anonymization", "family": "PRI", - "description": "Mechanisms exist to mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification.", - "scf_question": "Does the organization mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification?", + "description": "Mechanisms exist to mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification.", + "scf_question": "Does the organization mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -62,8 +62,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-iso-27002-2022": [ @@ -105,9 +107,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "3.4.1" ], - "general-scf-dpmp-2025": [ - "5.1" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-19(04)" ], @@ -126,14 +125,25 @@ "usa-state-va-cdpa-2023": [ "59.1-581.A.1" ], - "apac-aus-privacy-act-1998": [ - "APP Part 2" + "emea-deu-fdpa-2017": [ + "3.2.48(2)6", + "3.2.50" + ], + "emea-rus-152-fz-2025": [ + "Art. 13.1" + ], + "emea-sau-cscc-1-2019": [ + "2-6-1-1" ], - "apac-kor-pipa-2011": [ - "3" + "apac-jpn-appi-2020": [ + "IV.2.35-2(1)" ], - "americas-arg-ppd-2018": [ - "4.4" + "americas-bra-lgpd-2018": [ + "II.II.13", + "II.II.13.1", + "II.II.13.2", + "II.II.13.3", + "II.II.13.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-05.4.json b/docs/api/controls/PRI-05.4.json index df269a8a..eaa0cbaf 100644 --- a/docs/api/controls/PRI-05.4.json +++ b/docs/api/controls/PRI-05.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) to:\n(1) The purpose(s) originally collected, consistent with the data privacy notice(s);\n(2) What is authorized by the data subject, or authorized agent; and\n(3) What is consistent with applicable laws, regulations and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -171,9 +172,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.5.5" ], - "general-scf-dpmp-2025": [ - "3.3" - ], "general-shared-assessments-sig-2025": [ "P.2.3" ], @@ -217,64 +215,64 @@ "155.260(a)(3)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(c)", - "164.502(d)(1)", - "164.504(g)(2)", - "164.506(a)", - "164.506(c)(1)", - "164.506(c)(5)", - "164.508(a)(1)", - "164.508(a)(2)(i)(C)", - "164.510(a)(1)(i)(A)", - "164.510(a)(1)(i)(B)", - "164.510(a)(1)(i)(C)", - "164.510(a)(1)(i)(D)", - "164.510(a)(1)(ii)(A)", - "164.510(a)(1)(ii)(B)", - "164.510(b)(4)", - "164.512", - "164.512(i)(1)", - "164.512(j)(1)", - "164.512(j)(1)(i)(A)", - "164.512(j)(1)(i)(B)", - "164.512(j)(1)(ii)", - "164.512(j)(1)(ii)(A)", - "164.512(j)(1)(ii)(B)", - "164.512(j)(2)(i)", - "164.512(j)(2)(ii)", - "164.512(j)(3)", - "164.512(j)(4)", - "164.512(k)(1)(i)", - "164.512(k)(1)(i)(A)", - "164.512(k)(1)(i)(B)", - "164.512(k)(1)(ii)", - "164.512(k)(1)(iii)", - "164.512(k)(1)(iv)", - "164.512(k)(2)", - "164.512(k)(3)", - "164.512(k)(4)", - "164.512(k)(4)(i)", - "164.512(k)(4)(ii)", - "164.512(k)(4)(iii)", - "164.512(k)(5)(i)", - "164.512(k)(5)(i)(A)", - "164.512(k)(5)(i)(B)", - "164.512(k)(5)(i)(C)", - "164.512(k)(5)(i)(D)", - "164.512(k)(5)(i)(E)", - "164.512(k)(5)(i)(F)", - "164.512(k)(5)(ii)", - "164.512(k)(5)(iii)", - "164.512(k)(6)(i)", - "164.512(k)(6)(ii)", - "164.512(k)(6)(ii)(1)", - "164.514(f)(2)(i)", - "164.514(g)", - "164.530(i)(4)(ii)", - "164.530(i)(4)(ii)(B)", - "164.532(a)", - "164.532(b)", - "164.532(c)" + "§ 164.502(c)", + "§ 164.502(d)(1)", + "§ 164.504(g)(2)", + "§ 164.506(a)", + "§ 164.506(c)(1)", + "§ 164.506(c)(5)", + "§ 164.508(a)(1)", + "§ 164.508(a)(2)(i)(C)", + "§ 164.510(a)(1)(i)(A)", + "§ 164.510(a)(1)(i)(B)", + "§ 164.510(a)(1)(i)(C)", + "§ 164.510(a)(1)(i)(D)", + "§ 164.510(a)(1)(ii)(A)", + "§ 164.510(a)(1)(ii)(B)", + "§ 164.510(b)(4)", + "§ 164.512", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.512(j)(1)(i)(A)", + "§ 164.512(j)(1)(i)(B)", + "§ 164.512(j)(1)(ii)", + "§ 164.512(j)(1)(ii)(A)", + "§ 164.512(j)(1)(ii)(B)", + "§ 164.512(j)(2)(i)", + "§ 164.512(j)(2)(ii)", + "§ 164.512(j)(3)", + "§ 164.512(j)(4)", + "§ 164.512(k)(1)(i)", + "§ 164.512(k)(1)(i)(A)", + "§ 164.512(k)(1)(i)(B)", + "§ 164.512(k)(1)(ii)", + "§ 164.512(k)(1)(iii)", + "§ 164.512(k)(1)(iv)", + "§ 164.512(k)(2)", + "§ 164.512(k)(3)", + "§ 164.512(k)(4)", + "§ 164.512(k)(4)(i)", + "§ 164.512(k)(4)(ii)", + "§ 164.512(k)(4)(iii)", + "§ 164.512(k)(5)(i)", + "§ 164.512(k)(5)(i)(A)", + "§ 164.512(k)(5)(i)(B)", + "§ 164.512(k)(5)(i)(C)", + "§ 164.512(k)(5)(i)(D)", + "§ 164.512(k)(5)(i)(E)", + "§ 164.512(k)(5)(i)(F)", + "§ 164.512(k)(5)(ii)", + "§ 164.512(k)(5)(iii)", + "§ 164.512(k)(6)(i)", + "§ 164.512(k)(6)(ii)", + "§ 164.512(k)(6)(ii)(1)", + "§ 164.514(f)(2)(i)", + "§ 164.514(g)", + "§ 164.530(i)(4)(ii)", + "§ 164.530(i)(4)(ii)(B)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)" ], "usa-federal-irs-1075-2021": [ "PT-2" @@ -323,125 +321,349 @@ "Article 10.5(c)", "Article 10.5(d)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" - ], - "emea-aut-fappd-2000": [ - "Sec 12" - ], - "emea-bel-act-8-1992": [ - "4-7", - "21" - ], - "emea-hun-isdfi-2011": [ - "9" - ], - "emea-isr-ppl-5741-1981": [ - "8" - ], - "emea-ita-pdpc-2003": [ - "13", - "20" + "emea-aut-dpa-2018": [ + "§ 7(1)", + "§ 7(6)", + "§ 38", + "§ 39", + "§ 40(1)", + "§ 40(2)", + "§ 40(3)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 8(3)", + "Title 1, Chapter II, Art. 9", + "Title 1, Chapter II, Art. 10(1)", + "Title 2, Chapter III, Art. 45(2)" + ], + "emea-deu-fdpa-2017": [ + "2.1.1.22(1)", + "2.1.1.22(1)1", + "2.1.1.22(1)1(a)", + "2.1.1.22(1)1(b)", + "2.1.1.22(1)1(c)", + "2.1.1.22(1)1(d)", + "2.1.1.22(1)2(a)", + "2.1.1.22(1)2(b)", + "2.1.1.22(2)", + "2.1.1.22(2)1", + "2.1.1.22(2)2", + "2.1.1.22(2)3", + "2.1.1.22(2)8", + "2.1.1.22(2)9", + "2.1.1.22(2)10", + "2.1.1.24(1)", + "2.1.1.24(1)1", + "2.1.1.24(1)2", + "2.1.1.24(2)", + "2.2.33(1)2(a)", + "2.2.33(1)3(b)", + "3.2.52" + ], + "emea-grc-pirppd-1997": [ + "B.7.1", + "B.7.2", + "B.8.3" + ], + "emea-hun-act-cxii-2011": [ + "II.11.12(3)(a)", + "II.11.12(3)(b)", + "II.12.13(2)" + ], + "emea-irl-dpa-2018": [ + "s.45", + "s.46", + "s.47", + "s.48", + "s.49", + "s.50", + "s.51", + "s.52", + "s.53", + "s.54", + "s.55", + "s.73" + ], + "emea-ita-pdpc-2018": [ + "Article 2-f(1)", + "Article 2-g(1)", + "Article 101(1)", + "Article 101(2)", + "Article 101(3)", + "Article 122(1)" ], "emea-ken-pda-2019": [ - "44", - "45(a)", - "45(a)(i)", - "45(a)(ii)", - "45(b)", - "45(c)(i)", - "45(c)(ii)", - "45(c)(iii)", - "46(1)(a)", - "46(1)(b)", - "46(2)(a)", - "46(2)(b)", - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" + "IV.25(a)", + "IV.25(b)", + "IV.28(3)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(1)(b)(i)", + "IV.30(1)(b)(ii)", + "IV.30(1)(b)(iii)", + "IV.30(1)(b)(iv)", + "IV.30(1)(b)(v)", + "IV.30(1)(b)(vi)", + "IV.30(1)(b)(vii)", + "IV.30(2)", + "IV.33(1)", + "IV.33(1)(a)", + "IV.33(1)(b)", + "IV.36", + "V.45", + "V.45(a)", + "V.45(a)(i)", + "V.45(a)(ii)", + "V.45(b)", + "V.45(c)", + "V.45(c)(i)", + "V.45(c)(ii)", + "V.45(c)(iii)", + "V.46(1)", + "V.46(1)(a)", + "V.46(1)(b)", + "V.46(2)(a)", + "V.46(2)(b)" ], "emea-nga-dpr-2019": [ + "2.1(1)(a)", + "2.1(1)(a)(i)", + "2.1(1)(a)(ii)", + "2.1(1)(b)", + "2.1(1)(c)", + "2.2(a)", + "2.2(c)", + "2.2(d)", + "2.2(e)", "3.1(12)" ], "emea-nor-pda-2018": [ - "9" - ], - "emea-pol-act-29-1997": [ - "27" + "9", + "12" ], "emea-qat-pdppl-2020": [ - "8.2", - "9.4", - "10", - "16", - "22" + "3.10", + "4.16", + "4.17", + "4.17.4" ], - "emea-rus-federal-law-27-2006": [ - "6", - "10" + "emea-rus-152-fz-2025": [ + "Art. 10", + "Art. 11", + "Art. 13" ], "emea-sau-pdpl-2023": [ "Article 11.3" ], "emea-srb-act-9-2018": [ - "5.1", - "5.3", - "17", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5", - "17.6", - "17.7", - "17.8", - "17.9", - "17.10", - "18.1", - "18.2", - "18.3", - "19" + "II.6(1)", + "II.6(2)", + "II.6(3)", + "II.6(4)", + "II.6(5)", + "II.7", + "II.7(1)", + "II.7(2)", + "II.12", + "II.12(1)", + "II.12(2)", + "II.12(3)", + "II.12(4)", + "II.12(5)", + "II.12(6)", + "II.13", + "II.17", + "II.17(1)", + "II.17(2)", + "II.17(3)", + "II.17(4)", + "II.17(5)", + "II.17(6)", + "II.17(7)", + "II.17(8)", + "II.17(9)", + "II.17(10)", + "II.18", + "II.18(1)", + "II.18(2)", + "II.18(3)", + "II.19", + "II.20", + "IV.1.46", + "IV.1.47-1", + "IV.1.47-1(1)", + "IV.1.47-1(2)", + "IV.1.47-1(3)", + "IV.1.47-1(4)", + "IV.1.47-1(5)", + "IV.1.47-1(6)", + "IV.1.47-1(7)" ], "emea-zaf-popia-2013": [ - "15", - "26" + "3.A.4.15(1)", + "3.A.4.15(2)", + "3.A.4.15(2)(a)", + "3.A.4.15(2)(b)", + "3.A.4.15(2)(c)", + "3.A.4.15(2)(d)", + "3.A.4.15(2)(e)", + "3.A.4.15(3)", + "3.A.4.15(3)(a)", + "3.A.4.15(3)(b)", + "3.A.4.15(3)(c)", + "3.A.4.15(3)(c)(i)", + "3.A.4.15(3)(c)(ii)", + "3.A.4.15(3)(c)(iii)", + "3.A.4.15(3)(c)(iv)", + "3.A.4.15(3)(d)", + "3.A.4.15(3)(d)(i)", + "3.A.4.15(3)(d)(ii)", + "3.A.4.15(3)(e)", + "3.A.4.15(3)(f)", + "3.B.26(1)", + "3.B.26(1)(a)", + "3.B.26(1)(b)", + "3.B.26(1)(b)(i)", + "3.B.26(1)(b)(ii)", + "3.B.27(1)", + "3.B.27(1)(a)", + "3.B.27(1)(b)", + "3.B.27(1)(c)", + "3.B.27(1)(d)", + "3.B.27(1)(d)(i)", + "3.B.27(1)(d)(ii)", + "3.B.27(1)(e)", + "3.B.27(1)(f)", + "3.B.27(2)", + "3.B.27(3)" ], "emea-tur-lppd-2016": [ - "6" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "4(1)", + "4(2)", + "4(2)(a)", + "4(2)(b)", + "4(2)(c)", + "4(2)(ç)", + "4(2)(d)", + "5(1)", + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(2)(c)", + "5(2)(ç)", + "5(2)(d)", + "5(2)(e)", + "5(2)(f)", + "6(1)", + "6(2)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "6(3)(ç)", + "6(3)(d)", + "6(3)(e)", + "6(3)(f)", + "6(3)(g)", + "6(4)", + "7(1)", + "7(2)", + "7(3)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(4)", + "Section 44(4)(a)", + "Section 44(4)(b)", + "Section 44(4)(c)", + "Section 44(4)(e)", + "Section 47(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 6", - "APP 7", - "APP 9" + "2.3.3", + "2.3.3.a", + "2.3.3.a.i", + "2.3.3.a.ii", + "2.3.3.b", + "2.3.4", + "2.3.4.a", + "2.3.4.b", + "2.3.4.c", + "2.3.4.d", + "2.3.4.d.i", + "2.3.4.d.ii", + "2.3.4.e", + "2.3.4.e.i", + "2.3.4.e.ii", + "3.6.1", + "3.6.1.a", + "3.6.1.b", + "3.6.2", + "3.6.2.a", + "3.6.2.a.i", + "3.6.2.a.ii", + "3.6.2.b", + "3.6.2.c", + "3.6.2.d", + "3.6.2.e", + "3.6.3", + "3.6.4", + "3.6.4.a", + "3.6.4.b", + "3.7.1", + "3.7.2", + "3.7.2.a", + "3.7.2.b", + "3.7.2.c", + "3.7.2.d", + "3.7.3", + "3.7.3.a", + "3.7.3.a.i", + "3.7.3.a.ii", + "3.7.3.b", + "3.7.3.b.i", + "3.7.3.b.ii", + "3.7.3.c", + "3.7.3.d", + "3.7.3.d.i", + "3.7.3.d.ii", + "3.7.3.e", + "3.7.4", + "3.7.5", + "3.7.5.a", + "3.7.5.b", + "3.7.5.c" ], "apac-chn-cybersecurity-law-2017": [ "Article 41", "Article 44" ], + "apac-chn-csnip-2012": [ + "V" + ], "apac-chn-pipl-2021": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "28", - "29", - "30", - "31", - "32" + "Article 13", + "Article 28" + ], + "apac-hkg-pdo-2022": [ + "35K(1)", + "35K(1)(a)", + "35K(1)(b)", + "35K(1)(c)", + "35K(2)", + "35K(2)(a)", + "35K(2)(b)", + "35K(2)(c)", + "35K(3)", + "Schedule 1 - 3(1)", + "Schedule 1 - 3(2)", + "Schedule 1 - 3(2)(a)", + "Schedule 1 - 3(2)(a)(i)", + "Schedule 1 - 3(2)(a)(ii)", + "Schedule 1 - 3(2)(a)(iii)", + "Schedule 1 - 3(2)(b)", + "Schedule 1 - 3(2)(c)", + "Schedule 1 - 3(3)" ], "apac-ind-dpdpa-2023": [ "7(f)", @@ -450,62 +672,273 @@ "7(i)", "8(1)" ], - "apac-jpn-ppi-2020": [ - "16-2" + "apac-jpn-appi-2020": [ + "IV.1.16(1)", + "IV.1.17(2)", + "IV.1.17(2)(i)", + "IV.1.17(2)(ii)", + "IV.1.17(2)(iii)", + "IV.1.17(2)(iv)", + "IV.1.17(2)(v)", + "IV.1.17(2)(vi)", + "IV.1.23(1)(i)", + "IV.1.23(1)(ii)", + "IV.1.23(1)(iii)", + "IV.1.23(1)(iv)" ], "apac-mys-pdpa-2010": [ - "34" + "6(1)(a)", + "6(2)", + "6(2)(a)", + "6(2)(b)", + "6(2)(c)", + "6(2)(d)", + "6(2)(e)", + "6(2)(f)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "8", + "8(a)", + "8(a)(i)", + "8(a)(ii)", + "8(b)", + "39", + "39(a)", + "39(b)", + "39(b)(i)", + "39(b)(ii)", + "39(c)", + "39(d)", + "39(e)", + "40(1)", + "40(1)(a)", + "40(1)(b)", + "40(1)(b)(i)", + "40(1)(b)(ii)", + "40(1)(b)(ii)(A)", + "40(1)(b)(ii)(B)", + "40(1)(b)(iii)", + "40(1)(b)(iv)", + "40(1)(b)(iv)(A)", + "40(1)(b)(iv)(B)", + "40(1)(b)(v)", + "40(1)(b)(vi)", + "40(1)(b)(vii)", + "40(1)(b)(viii)", + "40(1)(b)(ix)", + "40(1)(b)(x)", + "40(1)(c)", + "42(1)(b)", + "42(1)(b)(A)", + "42(1)(b)(B)", + "42(2)", + "42(2)(a)", + "42(2)(b)", + "42(2)(b)(i)", + "42(2)(b)(ii)", + "42(2)(b)(iii)", + "42(2)(b)(iv)", + "42(2)(c)", + "42(3)", + "42(3)(a)", + "42(3)(b)", + "42(4)", + "42(5)" ], "apac-nzl-privacy-act-2020": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "3.1.22.1(1)", + "3.1.22.1(1)(a)", + "3.1.22.1(1)(b)", + "3.1.22.10(1)", + "3.1.22.10(1)(a)", + "3.1.22.10(1)(b)", + "3.1.22.10(1)(b)(i)", + "3.1.22.10(1)(b)(ii)", + "3.1.22.10(1)(c)", + "3.1.22.10(1)(d)", + "3.1.22.10(1)(e)", + "3.1.22.10(1)(e)(i)", + "3.1.22.10(1)(e)(ii)", + "3.1.22.10(1)(e)(iii)", + "3.1.22.10(1)(e)(iv)", + "3.1.22.10(1)(f)", + "3.1.22.10(1)(f)(i)", + "3.1.22.10(1)(f)(ii)" ], "apac-phl-dpa-2012": [ - "19", - "22", - "34" + "III.11(a)", + "III.11(c)", + "III.12(b)", + "III.12(c)", + "III.12(d)", + "III.12(e)", + "III.12(f)", + "III.13", + "III.13(a)", + "III.13(b)", + "III.13(c)", + "III.13(d)", + "III.13(e)", + "III.13(f)" ], "apac-sgp-pdpa-2012": [ - "14" + "4.1.13", + "4.1.13(a)", + "4.1.13(b)", + "4.1.15(3)(a)", + "4.1.15(3)(b)", + "4.1.15(3)(c)", + "4.1.17(1)(b)", + "4.1.17(2)(a)" ], "apac-kor-pipa-2011": [ - "16", - "18", - "23" + "III.1.18(1)", + "III.1.18(2)", + "III.1.18(2)1", + "III.1.18(2)2", + "III.1.18(2)3", + "III.1.18(2)4", + "III.1.18(2)5", + "III.1.18(2)6", + "III.1.18(2)7", + "III.1.18(2)8", + "III.1.18(2)9", + "III.1.19", + "III.1.19.1", + "III.1.19.2", + "III.2.23.1", + "III.2.23.2" ], "apac-twn-pdpa-2025": [ - "5" - ], - "americas-arg-ppd-2018": [ - "4.3" + "I.6", + "I.6.1", + "I.6.2", + "I.6.3", + "I.6.4", + "I.6.5", + "I.6.6", + "III.19", + "III.19.1", + "III.19.2", + "III.19.3", + "III.19.4", + "III.19.5", + "III.19.6", + "III.19.7", + "III.19.8", + "III.20", + "III.20.1", + "III.20.2", + "III.20.3", + "III.20.4", + "III.20.5", + "III.20.6", + "III.20.7" ], "americas-bhs-dpa-2003": [ - "12" + "IV.29(2)", + "IV.29(2)(a)", + "IV.29(2)(b)", + "IV.29(2)(c)", + "IV.29(2)(d)", + "IV.34(1)", + "IV.34(2)", + "IV.34(2)(a)", + "IV.34(2)(b)", + "IV.34(2)(c)", + "IV.34(2)(d)", + "IV.34(2)(e)", + "IV.34(2)(e)(i)", + "IV.34(2)(e)(ii)", + "IV.34(2)(f)", + "IV.34(2)(g)", + "IV.34(2)(h)", + "IV.34(2)(i)", + "IV.34(2)(j)", + "IV.34(2)(k)", + "IV.34(2)(l)", + "IV.34(2)(m)", + "IV.34(2)(n)", + "IV.34(2)(n)(i)", + "IV.34(2)(n)(ii)", + "IV.34(2)(n)(iii)", + "IV.34(2)(n)(iv)", + "IV.34(2)(o)", + "IV.34(2)(o)(a)", + "IV.34(2)(o)(b)", + "IV.34(2)(p)", + "IV.34(2)(p)(i)", + "IV.34(2)(p)(ii)", + "IV.34(2)(p)(ii)(aa)", + "IV.34(2)(p)(ii)(bb)", + "IV.34(2)(p)(ii)(cc)", + "IV.34(2)(p)(ii)(dd)", + "IV.34(2)(p)(ii)(ee)", + "IV.34(2)(p)(iii)", + "IV.34(2)(q)", + "IV.34(2)(q)(i)", + "IV.34(2)(q)(ii)", + "IV.34(2)(q)(iii)", + "IV.34(2)(r)", + "IV.34(2)(s)", + "IV.34(4)", + "IV.34(4)(a)", + "IV.34(4)(b)", + "IV.34(5)", + "IV.34(5)(a)", + "IV.34(5)(b)", + "IV.34(5)(c)", + "IV.34(5)(d)", + "IV.34(6)" + ], + "americas-bra-lgpd-2018": [ + "II.I.7.II", + "II.I.7.III", + "II.I.7.V", + "II.I.7.VI", + "II.I.7.VII", + "II.I.7.VIII", + "II.I.7.IX", + "II.I.7.X", + "II.I.7.X.1", + "II.I.7.X.2", + "II.I.7.X.3", + "II.I.7.X.4", + "II.I.7.X.5", + "II.I.7.X.6" + ], + "americas-can-pipeda-2000": [ + "P5-4.5", + "P5-4.5.3" ], "americas-chl-act-19628-1999": [ - "10" + "I.6", + "I.10", + "II.15" ], "americas-col-law-1581-2012": [ - "4", - "5", - "6", - "7" + "II.4(f)", + "III.6", + "III.6(a)", + "III.6(b)", + "III.6(c)", + "III.6(d)", + "III.6(e)", + "III.7" ], "americas-mex-fdpa-2010": [ - "7", - "9" + "II.7", + "II.13", + "V.37", + "V.37.I", + "V.37.II", + "V.37.III", + "V.37.IV", + "V.37.V", + "V.37.VI", + "V.37.VII" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-05.5.json b/docs/api/controls/PRI-05.5.json index c6e502be..08826998 100644 --- a/docs/api/controls/PRI-05.5.json +++ b/docs/api/controls/PRI-05.5.json @@ -3,7 +3,7 @@ "title": "Inventory of Personal Data (PD)", "family": "PRI", "description": "Mechanisms exist to establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD).", - "scf_question": "Does the organization establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS)that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD)?", + "scf_question": "Does the organization establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -131,9 +132,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.5.1" ], - "general-scf-dpmp-2025": [ - "1.5" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG2.SP1" ], @@ -163,8 +161,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-05(1)" ], - "apac-kor-pipa-2011": [ - "33" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], + "apac-sgp-pdpa-2012": [ + "4.1.13" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-05.6.json b/docs/api/controls/PRI-05.6.json index 6a8d6ee8..b84d7e8b 100644 --- a/docs/api/controls/PRI-05.6.json +++ b/docs/api/controls/PRI-05.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically determine if Personal Data (PD) is maintained in electronic form.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -67,7 +67,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -84,9 +85,6 @@ "general-nist-800-82-r3": [ "PM-05(01)" ], - "general-scf-dpmp-2025": [ - "1.5" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-05(01)" ], @@ -104,9 +102,6 @@ ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-05(1)" - ], - "emea-rus-federal-law-27-2006": [ - "16" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-05.7.json b/docs/api/controls/PRI-05.7.json index a16438ca..8112c113 100644 --- a/docs/api/controls/PRI-05.7.json +++ b/docs/api/controls/PRI-05.7.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to define and implement data handling and protection requirements for specific categories of sensitive Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -92,10 +93,6 @@ "PT-07(01)", "PT-07(02)" ], - "general-scf-dpmp-2025": [ - "1.2", - "1.7" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)(i)" ], @@ -118,6 +115,9 @@ "usa-state-co-privacy-act-2021": [ "6-1-1308(1)(a)(I)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.340.1(a)" + ], "usa-state-or-cpa-2023": [ "Section 5(4)(a)", "Section 5(4)(e)" @@ -135,29 +135,37 @@ "Article 13.1(e)", "Article 14.1(d)" ], - "emea-ken-pda-2019": [ - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" - ], - "emea-srb-act-9-2018": [ - "9", - "9.1", - "9.2", - "9.3", - "9.4", - "9.5", - "10", - "13" - ], - "apac-aus-privacy-principles-2026": [ - "APP 9" - ], - "apac-chn-pipl-2021": [ - "51(2)" + "emea-aut-dpa-2018": [ + "§ 37(4)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 8(2)", + "Title 1, Chapter II, Art. 10(2)", + "Title 2, Chapter II, Art. 31" + ], + "emea-deu-fdpa-2017": [ + "2.1.2.26(3)", + "2.1.2.26(4)", + "2.1.2.26(7)", + "3.2.48(1)", + "3.2.51(5)", + "3.4.70(2)", + "3.4.72", + "3.4.72.1", + "3.4.72.2", + "3.4.72.3", + "3.4.72.4", + "3.4.72.5", + "3.4.73" + ], + "emea-rus-152-fz-2025": [ + "Art. 10" + ], + "apac-kor-pipa-2011": [ + "III.2.23" + ], + "americas-bhs-dpa-2003": [ + "V.43(4)(b)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-05.8.json b/docs/api/controls/PRI-05.8.json index b2116239..c12388b0 100644 --- a/docs/api/controls/PRI-05.8.json +++ b/docs/api/controls/PRI-05.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to retain Personal Data (PD) in a format permitting data subject identification for no longer than is necessary for legitimate business purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-05.json b/docs/api/controls/PRI-05.json index 2871d06c..15bb4b81 100644 --- a/docs/api/controls/PRI-05.json +++ b/docs/api/controls/PRI-05.json @@ -3,7 +3,7 @@ "title": "Personal Data (PD) Retention & Disposal", "family": "PRI", "description": "Mechanisms exist to: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records).", - "scf_question": "Does the organization: \n (1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n (2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n (3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records)?", + "scf_question": "Does the organization: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -19,11 +19,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -256,9 +257,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.4.6" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "usa-federal-fbi-cjis-6-0": [ "4.2.2", "4.2.3.1", @@ -334,73 +332,52 @@ "emea-eu-gdpr-2016": [ "Article 5.1(e)" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-aut-fappd-2000": [ - "Sec 7" + "emea-aut-dpa-2018": [ + "§ 13(3)", + "§ 37(2)" ], - "emea-bel-act-8-1992": [ - "4-7", - "21" + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 30" ], "emea-deu-fdpa-2017": [ - "Sec 3a", - "Sec 5", - "Sec 13", - "Sec 14", - "Sec 20" - ], - "emea-deu-c5-2020": [ - "OPS-11", - "OPS-12", - "PI-03" + "3.1.47.5", + "3.2.48(2)2", + "3.3.58(2)", + "3.4.62(5)4", + "3.4.75(2)", + "3.4.75(4)" ], "emea-grc-pirppd-1997": [ - "4", - "7" - ], - "emea-hun-isdfi-2011": [ - "5" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-isr-ppl-5741-1981": [ - "8" - ], - "emea-ita-pdpc-2003": [ - "11" + "B.4.1.d", + "B.4.2" + ], + "emea-hun-act-cxii-2011": [ + "II.8.9(1)(b)", + "II.13.15(3)", + "II.13.17(2)(a)", + "II.13.17(2)(b)", + "II.13.17(2)(c)", + "II.13.17(2)(d)", + "II.13.17(2)(e)", + "II.14.20(4)(d)", + "II.15.21(7)" + ], + "emea-ita-pdpc-2018": [ + "Article 99(3)" ], "emea-ken-pda-2019": [ - "25(g)", - "34(3)", - "39(1)", - "39(1)(a)", - "39(1)(b)", - "39(1)(c)", - "39(1)(d)", - "39(2)" + "IV.25(g)", + "IV.34(1)(b)", + "IV.34(3)", + "IV.39(1)", + "IV.39(1)(a)", + "IV.39(1)(b)", + "IV.39(1)(c)", + "IV.39(1)(d)", + "IV.39(2)" ], "emea-nga-dpr-2019": [ - "2.1(1)(c)" - ], - "emea-nor-pda-2018": [ - "8", - "11", - "15", - "27", - "28" - ], - "emea-pol-act-29-1997": [ - "23", - "26" - ], - "emea-rus-federal-law-27-2006": [ - "5" + "3.1(9)(a)" ], "emea-sau-pdpl-2023": [ "Article 11.4", @@ -408,127 +385,103 @@ "Article 18.2.a", "Article 18.2.b" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], "emea-srb-act-9-2018": [ - "5.5", - "8" + "II.8", + "III.3.30-1(1)" ], "emea-zaf-popia-2013": [ - "4", - "14", - "16" - ], - "emea-esp-decree-1720-2007": [ - "8", - "22" + "3.A.3.14(1)", + "3.A.3.14(1)(a)", + "3.A.3.14(1)(b)", + "3.A.3.14(1)(c)", + "3.A.3.14(1)(d)", + "3.A.3.14(2)", + "3.A.3.14(3)", + "3.A.3.14(3)(a)", + "3.A.3.14(3)(b)", + "3.A.3.14(4)", + "3.A.3.14(5)", + "3.A.3.14(6)", + "3.A.3.14(6)(a)", + "3.A.3.14(6)(b)", + "3.A.3.14(6)(c)", + "3.A.3.14(6)(d)", + "3.A.3.14(7)" ], "emea-che-fadp-2025": [ - "4" - ], - "emea-tur-lppd-2016": [ - "5", - "7" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3", - "APP Part 6" + "2.1.6.4" ], "apac-aus-privacy-principles-2026": [ - "APP 4", - "APP 6" + "4.11.2", + "4.11.2.a", + "4.11.2.b", + "4.11.2.c", + "4.11.2.d" ], "apac-chn-pipl-2021": [ - "10", - "19", - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)" + "Article 19", + "Article 47" ], "apac-hkg-pdo-2022": [ - "Principle 2", - "Sec 26", - "Principle 3", - "Sec 4" + "26(1)", + "26(1)(a)", + "26(1)(b)", + "26(2)", + "26(2)(a)", + "26(2)(b)", + "Schedule 1 - 2(2)", + "Schedule 1 - 2(3)" ], "apac-ind-privacy-rules-2011": [ - "5" + "5(4)" ], - "apac-jpn-ppi-2020": [ - "19" + "apac-jpn-appi-2020": [ + "IV.2.35-2(5)" ], "apac-mys-pdpa-2010": [ - "5", - "6", - "10" + "10(1)", + "10(2)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.9" ], "apac-phl-dpa-2012": [ - "19", - "21" + "III.11(e)", + "III.11(f)" ], "apac-sgp-pdpa-2012": [ - "23", - "25" - ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" + "5.22A(1)", + "5.22A(2)" ], "apac-kor-pipa-2011": [ - "3", - "4", - "15", - "19", - "21", - "37" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "5.1", - "4.3", - "9.2" + "III.1.21(1)", + "III.1.21(2)", + "III.1.21(3)", + "III.1.21(4)" ], "americas-bhs-dpa-2003": [ - "6", - "12" + "II.5(1)(e)", + "II.9(1)", + "II.9(1)(a)", + "II.9(1)(b)", + "II.9(1)(c)" ], "americas-bra-lgpd-2018": [ - "6.2", - "6.9", - "13", - "14", - "15", - "21" + "II.IV.16", + "II.IV.16.I", + "II.IV.16.II", + "II.IV.16.III", + "II.IV.16.IV" ], "americas-can-pipeda-2000": [ - "Sec 7", - "Sec 8", - "Principle 5", - "Principle 6" + "P5-4.5.3", + "P7-4.7.5" ], "americas-chl-act-19628-1999": [ - "9" - ], - "americas-col-law-1581-2012": [ - "4" + "I.6" ], "americas-mex-fdpa-2010": [ - "7", - "8", - "9", - "11", - "12", - "13", - "14" + "II.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.1.json b/docs/api/controls/PRI-06.1.json index ffdd9d17..652b1454 100644 --- a/docs/api/controls/PRI-06.1.json +++ b/docs/api/controls/PRI-06.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process for:\n(1) Data subjects to have inaccurate Personal Data (PD) maintained by the organization corrected or amended; and\n(2) Disseminating corrections or amendments of PD to other authorized users of the PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -121,9 +122,6 @@ "SI-18(04)", "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "6.3" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.6.a" ], @@ -147,13 +145,13 @@ "1" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(a)(2)", - "164.526(a)(2)(i)", - "164.526(a)(2)(ii)", - "164.526(a)(2)(iii)", - "164.526(a)(2)(iv)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(a)(2)", + "§ 164.526(a)(2)(i)", + "§ 164.526(a)(2)(ii)", + "§ 164.526(a)(2)(iii)", + "§ 164.526(a)(2)(iv)", + "§ 164.526(b)(1)" ], "usa-federal-cms-marse-2-0": [ "IP-3", @@ -183,152 +181,123 @@ "usa-state-va-cdpa-2023": [ "59.1-577.A.2" ], - "emea-aut-fappd-2000": [ - "Sec 27" - ], - "emea-bel-act-8-1992": [ - "10", - "12" + "emea-aut-dpa-2018": [ + "§ 45(1)" ], "emea-deu-fdpa-2017": [ - "Sec 20" + "3.3.57(1)6", + "3.3.58(1)", + "3.4.75(1)" ], "emea-grc-pirppd-1997": [ - "13" - ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" - ], - "emea-irl-dpa-2003": [ - "2" + "B.4.1.c", + "C.12.2.e" ], - "emea-isr-ppl-5741-1981": [ - "14" + "emea-hun-act-cxii-2011": [ + "II.13.17(1)" ], - "emea-ita-pdpc-2003": [ - "7" + "emea-isr-ppl-5741-2025": [ + "s.14" ], "emea-ken-pda-2019": [ - "25(f)", - "26(d)", - "40(1)(a)", - "40(2)(a)" - ], - "emea-nor-pda-2018": [ - "27" - ], - "emea-pol-act-29-1997": [ - "32" + "IV.25(f)", + "IV.26(d)", + "IV.34(1)(a)", + "IV.40(1)(a)" ], "emea-qat-pdppl-2020": [ - "5.4", - "6.2" - ], - "emea-rus-federal-law-27-2006": [ - "17" + "2.5.4" ], "emea-srb-act-9-2018": [ - "5.4", - "11", - "29" + "III.3.29" ], "emea-zaf-popia-2013": [ - "24" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" + "3.A.8.24(1)", + "3.A.8.24(1)(a)", + "3.A.8.24(1)(b)" ], - "emea-che-fadp-2025": [ - "5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "emea-gbr-dpa-2018": [ + "Section 46(1)", + "Section 46(2)", + "Section 46(3)", + "Section 46(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 13" + "5.13.1", + "5.13.1.a", + "5.13.1.b", + "5.13.1.b.i" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], - "apac-chn-csnip-2012": [ - "8" - ], "apac-chn-pipl-2021": [ - "46", - "49" + "Article 46" ], "apac-hkg-pdo-2022": [ - "Sec 22" + "22(1)(a)", + "22(1)(b)", + "22(1A)", + "22(2)", + "22(2)(a)", + "22(2)(b)", + "22(3)", + "22(4)", + "23(1)", + "23(1)(a)", + "23(1)(c)(i)", + "23(1)(c)(ii)", + "23(2)", + "23(2)(a)", + "23(2)(a)(i)", + "23(2)(a)(ii)", + "23(2)(b)", + "23(3)", + "23(3)(a)", + "23(3)(b)" ], "apac-ind-dpdpa-2023": [ "12(1)", "12(2)(a)", "12(2)(b)" ], - "apac-jpn-ppi-2020": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" + "apac-jpn-appi-2020": [ + "IV.1.29(1)", + "IV.1.29(2)" ], "apac-mys-pdpa-2010": [ - "34" - ], - "apac-nzl-privacy-act-2020": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" - ], - "apac-phl-dpa-2012": [ - "34" + "35(1)", + "35(1)(a)", + "35(1)(b)", + "35(1)(c)", + "35(1)(c)(i)", + "35(1)(c)(ii)", + "35(2)", + "35(2)(a)", + "35(2)(b)", + "35(3)", + "35(4)", + "35(4)(a)", + "35(4)(b)", + "35(5)", + "35(5)(a)", + "35(5)(b)" ], "apac-sgp-pdpa-2012": [ - "22" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "16.1", - "16.3" + "5.22(1)", + "5.22(2)(a)", + "5.22(4)" ], "americas-bhs-dpa-2003": [ - "10" - ], - "americas-bra-lgpd-2018": [ - "18.3" + "IV.26(1)", + "IV.26(2)" ], "americas-can-pipeda-2000": [ - "Principle 10" - ], - "americas-chl-act-19628-1999": [ - "13" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "P9-4.9.5" ], "americas-mex-fdpa-2010": [ - "24", - "28", - "29" + "III.24", + "IV.28" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.2.json b/docs/api/controls/PRI-06.2.json index 9fbfc50b..26676de2 100644 --- a/docs/api/controls/PRI-06.2.json +++ b/docs/api/controls/PRI-06.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify affected data subjects if their Personal Data (PD) has been corrected, amended or deleted.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -98,9 +99,6 @@ "general-nist-800-82-r3": [ "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "6.4" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-18(05)" ], @@ -114,12 +112,12 @@ "SI-18(05)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(c)", - "164.526(c)(1)", - "164.526(c)(2)", - "164.526(c)(3)", - "164.526(c)(3)(i)", - "164.526(c)(3)(ii)" + "§ 164.526(c)", + "§ 164.526(c)(1)", + "§ 164.526(c)(2)", + "§ 164.526(c)(3)", + "§ 164.526(c)(3)(i)", + "§ 164.526(c)(3)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7022(e)", @@ -128,93 +126,89 @@ "usa-state-tn-tipa-2025": [ "47-18-3203(b)(1)" ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17", - "18" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "10" - ], - "emea-nga-dpr-2019": [ - "3.1(13)" + "emea-aut-dpa-2018": [ + "§ 45(5)" ], - "emea-pol-act-29-1997": [ - "32" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 39(5)", + "Title 2, Chapter III, Art. 39(6)" ], - "emea-qat-pdppl-2020": [ - "6.2" - ], - "emea-rus-federal-law-27-2006": [ - "18" - ], - "emea-srb-act-9-2018": [ - "34", - "34.1", - "34.2", - "34.3", - "34.4", - "34.5" + "emea-deu-fdpa-2017": [ + "3.3.58(1)", + "3.3.58(5)", + "3.4.75(3)" ], "emea-zaf-popia-2013": [ - "24" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "3.A.8.24(3)", + "3.A.8.24(4)" + ], + "emea-gbr-dpa-2018": [ + "Section 48(1)", + "Section 48(1)(a)", + "Section 48(1)(b)", + "Section 48(1)(b)(i)", + "Section 48(1)(b)(ii)", + "Section 48(1)(b)(iii)", + "Section 48(1)(b)(iv)", + "Section 48(2)", + "Section 48(2)(a)", + "Section 48(2)(b)", + "Section 48(3)", + "Section 48(3)(a)", + "Section 48(3)(b)", + "Section 48(3)(c)", + "Section 48(3)(e)", + "Section 48(4)", + "Section 48(4)(a)", + "Section 48(4)(b)", + "Section 48(4)(c)", + "Section 48(4)(d)", + "Section 48(5)", + "Section 48(6)", + "Section 48(6)(a)", + "Section 48(6)(b)", + "Section 48(7)", + "Section 48(9)", + "Section 48(9)(a)", + "Section 48(9)(b)", + "Section 48(10)" ], "apac-aus-privacy-principles-2026": [ - "APP 13" - ], - "apac-chn-pipl-2021": [ - "22", - "46", - "49" - ], - "apac-jpn-ppi-2020": [ - "18(3)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)", - "29(1)", - "29(2)", - "29(3)" + "5.13.2", + "5.13.2.a", + "5.13.2.b", + "5.13.3", + "5.13.3.a", + "5.13.3.b", + "5.13.3.c" + ], + "apac-hkg-pdo-2022": [ + "19(3)(b)", + "19(3)(c)", + "19(3)(c)(i)", + "19(3)(c)(i)(A)", + "19(3)(c)(i)(B)", + "19(3)(c)(ii)", + "19(3)(c)(iii)", + "19(3)(c)(iii)(A)", + "19(3)(c)(iii)(B)", + "19(3)(c)(I)", + "19(3)(c)(II)", + "19(3)(c)(iv)", + "19(3)(c)(v)", + "23(1)(b)" + ], + "apac-mys-pdpa-2010": [ + "37(1)", + "37(1)(a)", + "37(1)(b)" ], "apac-nzl-privacy-act-2020": [ - "P6-(2)" - ], - "apac-phl-dpa-2012": [ - "34" - ], - "apac-sgp-pdpa-2012": [ - "23" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "americas-arg-ppd-2018": [ - "16.2" + "3.1.22.7(3)(b)" ], "americas-bhs-dpa-2003": [ - "11" - ], - "americas-bra-lgpd-2018": [ - "18.9" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "IV.26(3)(a)", + "IV.26(3)(b)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.3.json b/docs/api/controls/PRI-06.3.json index b53dc308..18cc1a88 100644 --- a/docs/api/controls/PRI-06.3.json +++ b/docs/api/controls/PRI-06.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process for data subjects to appeal an adverse decision.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -112,9 +113,6 @@ "general-nist-800-161-r1-level-3": [ "PM-26" ], - "general-scf-dpmp-2025": [ - "6.5" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-26" ], @@ -131,7 +129,7 @@ "155.260(a)(3)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(d)(4)" + "§ 164.524(d)(4)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(d)(1)", @@ -140,6 +138,15 @@ "usa-state-co-privacy-act-2021": [ "6-1-1306(3)(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.520.1", + "603A.520.1(a)", + "603A.520.1(b)", + "603A.520.2", + "603A.520.2(a)", + "603A.520.2(b)", + "603A.520.2(c)" + ], "usa-state-or-ors-646a-2025": [ "646A.576(6)", "646A.576(6)(a)", @@ -159,49 +166,8 @@ "usa-state-va-cdpa-2023": [ "59.1-577.C" ], - "emea-aut-fappd-2000": [ - "Sec 28" - ], - "emea-grc-pirppd-1997": [ - "13" - ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17", - "18" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-rus-federal-law-27-2006": [ - "17" - ], - "emea-zaf-popia-2013": [ - "63", - "74" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24" - ], - "apac-jpn-ppi-2020": [ - "31" - ], - "apac-phl-dpa-2012": [ - "34" - ], - "apac-kor-pipa-2011": [ - "38" - ], - "americas-bra-lgpd-2018": [ - "18.9" - ], - "americas-can-pipeda-2000": [ - "Sec 11" - ], - "americas-col-law-1581-2012": [ - "15" + "emea-rus-152-fz-2025": [ + "Art. 17" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.4.json b/docs/api/controls/PRI-06.4.json index a6f137d5..a1e88f25 100644 --- a/docs/api/controls/PRI-06.4.json +++ b/docs/api/controls/PRI-06.4.json @@ -1,9 +1,9 @@ { "control_id": "PRI-06.4", - "title": "User Feedback Management", + "title": "Data Subject Feedback Management", "family": "PRI", - "description": "Mechanisms exist to maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", - "scf_question": "Does the organization maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes?", + "description": "Mechanisms exist to maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", + "scf_question": "Does the organization maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes?", "relative_weight": 5, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75,8 +75,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -103,7 +105,7 @@ "P8.1-POF3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.MT-P7", @@ -148,9 +150,6 @@ "7(c)", "7(d)" ], - "general-scf-dpmp-2025": [ - "6.1" - ], "general-tisax-6-0-3": [ "9.6.1" ], @@ -175,28 +174,28 @@ "6" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(b)(2)(i)", - "164.526(b)(2)(i)(A)", - "164.526(b)(2)(i)(B)", - "164.526(b)(2)(ii)", - "164.526(b)(2)(ii)(A)", - "164.526(b)(2)(ii)(B)", - "164.526(d)", - "164.526(d)(1)", - "164.526(d)(1)(i)", - "164.526(d)(1)(ii)", - "164.526(d)(1)(iii)", - "164.526(d)(1)(iv)", - "164.526(d)(2)", - "164.526(d)(3)", - "164.526(d)(4)", - "164.526(d)(5)(i)", - "164.526(d)(5)(ii)", - "164.526(d)(5)(iii)", - "164.526(e)", - "164.526(f)", - "164.530(d)(1)", - "164.530(d)(2)" + "§ 164.526(b)(2)(i)", + "§ 164.526(b)(2)(i)(A)", + "§ 164.526(b)(2)(i)(B)", + "§ 164.526(b)(2)(ii)", + "§ 164.526(b)(2)(ii)(A)", + "§ 164.526(b)(2)(ii)(B)", + "§ 164.526(d)", + "§ 164.526(d)(1)", + "§ 164.526(d)(1)(i)", + "§ 164.526(d)(1)(ii)", + "§ 164.526(d)(1)(iii)", + "§ 164.526(d)(1)(iv)", + "§ 164.526(d)(2)", + "§ 164.526(d)(3)", + "§ 164.526(d)(4)", + "§ 164.526(d)(5)(i)", + "§ 164.526(d)(5)(ii)", + "§ 164.526(d)(5)(iii)", + "§ 164.526(e)", + "§ 164.526(f)", + "§ 164.530(d)(1)", + "§ 164.530(d)(2)" ], "usa-federal-cms-marse-2-0": [ "IP-4", @@ -248,6 +247,16 @@ "6-1-1306(3)(b)", "6-1-1306(3)(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.345.3", + "603A.345.4", + "603A.346.3", + "603A.346.4", + "603A.510.1", + "603A.510.2", + "603A.510.2(a)", + "603A.510.2(b)" + ], "usa-state-nv-sb220-2019": [ "2.4" ], @@ -312,119 +321,299 @@ "emea-eu-gdpr-2016": [ "Article 12.4" ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" - ], - "emea-ita-pdpc-2003": [ - "9" + "emea-aut-dpa-2018": [ + "§ 42(3)", + "§ 42(4)", + "§ 42(5)", + "§ 42(6)", + "§ 45(8)", + "§ 45(9)", + "§ 44(3)", + "§ 44(4)", + "§ 45(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(3)", + "Title 2, Chapter III, Art. 38(3)", + "Title 2, Chapter III, Art. 39(4)", + "Title 2, Chapter III, Art. 40" + ], + "emea-deu-fdpa-2017": [ + "2.2.34(2)", + "2.2.35(2)", + "3.3.57(6)", + "3.3.59(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)", + "II.13.16(2)", + "II.13.18(2)", + "II.15.21(2)", + "II.15.21(3)" + ], + "emea-irl-dpa-2018": [ + "s.93" ], "emea-ken-pda-2019": [ - "40(1)(b)" + "IV.35(4)(a)", + "IV.35(4)(b)", + "IV.35(4)(c)", + "IV.35(4)(c)(i)", + "IV.35(4)(c)(ii)", + "IV.38(4)" ], "emea-nga-dpr-2019": [ - "2.8", - "2.8(a)", - "2.8(b)", "3.1(2)", - "3.1(4)", + "3.1(3)(b)", "3.1(5)", - "3.1(11)(a)", - "3.1(11)(b)", - "3.1(11)(c)", - "3.1(11)(d)", "3.1(13)" ], "emea-qat-pdppl-2020": [ - "5.3", - "5.4", - "6.3" + "3.11.4" + ], + "emea-rus-152-fz-2025": [ + "Art. 21" ], "emea-srb-act-9-2018": [ - "21", - "21.1", - "21.2", - "22", - "22.1", - "22.2", - "23", - "23.x", - "24", - "24.x", - "25", - "25.x", - "26", - "26.1", - "26.2", - "26.3", - "26.4", - "26.5", - "26.6", - "26.7", - "26.8", - "27.1", - "27.2", - "27.3", - "27.4", - "27.5", - "27.6", - "27.7" - ], - "emea-esp-decree-1720-2007": [ - "26" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "III.1.22", + "III.3.34" + ], + "emea-zaf-popia-2013": [ + "3.A.8.23(4)(a)", + "3.A.8.23(4)(b)", + "3.A.8.23(5)", + "3.A.8.24(2)", + "3.A.8.24(2)(a)", + "3.A.8.24(2)(b)", + "3.A.8.24(2)(c)", + "3.A.8.24(2)(d)" + ], + "emea-che-fadp-2025": [ + "4.25.7", + "4.28.3" + ], + "emea-gbr-dpa-2018": [ + "Section 45(3)", + "Section 45(3)(a)", + "Section 45(3)(b)", + "Section 45(5)", + "Section 45(5)(a)", + "Section 45(5)(b)", + "Section 45(5)(c)", + "Section 45(5)(d)", + "Section 45(5)(e)", + "Section 52(6)", + "Section 53(6)", + "Section 53(6)(a)", + "Section 53(6)(b)", + "Section 53(7)", + "Section 53(7)(a)", + "Section 53(7)(b)" ], "apac-aus-privacy-principles-2026": [ - "APP 12", - "APP 13" + "5.12.3", + "5.12.3.a", + "5.12.3.b", + "5.12.3.c", + "5.12.3.d", + "5.12.3.e", + "5.12.3.f", + "5.12.3.g", + "5.12.3.h", + "5.12.3.h.ii", + "5.12.3.i", + "5.12.3.j", + "5.12.4", + "5.12.4.a", + "5.12.4.a.i", + "5.12.4.a.ii", + "5.12.4.b", + "5.12.5", + "5.12.5.a", + "5.12.5.b", + "5.12.6", + "5.13.4", + "5.13.4.a", + "5.13.5", + "5.13.5.a", + "5.13.5.a.i", + "5.13.5.a.ii", + "5.13.5.b" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], "apac-chn-pipl-2021": [ - "45", - "46", - "50" - ], - "apac-jpn-ppi-2020": [ - "27(3)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)", - "31", + "Article 50" + ], + "apac-hkg-pdo-2022": [ + "18(5)", + "18(5)(a)", + "18(5)(b)", + "19(1)", + "19(1)(a)", + "19(1)(a)(i)", + "19(1)(a)(ii)", + "19(1)(b)", + "19(3)", + "19(3)(a)", + "19(3)(a)(i)", + "19(3)(a)(i)(A)", + "19(3)(a)(i)(B)", + "19(3)(a)(ii)", + "19(4)", + "19(4)(a)", + "19(4)(b)", + "19(4)(b)(i)", + "19(4)(b)(ii)", + "19(4)(b)(ii)(A)", + "19(4)(b)(I)", + "19(4)(b)(II)", + "19(4)(b)(III)", + "19(4)(b)(III)(B)", + "21(1)", + "21(1)(a)", + "21(1)(b)", + "21(1)(c)", + "25(1)", + "25(1)(b)" + ], + "apac-ind-privacy-rules-2011": [ + "5(9)" + ], + "apac-jpn-appi-2020": [ + "IV.1.27(2)", + "IV.1.27(2)(i)", + "IV.1.27(2)(ii)", + "IV.1.27(3)", + "IV.1.28(2)", + "IV.1.28(3)", + "IV.1.35(1)", + "IV.1.35(2)" + ], + "apac-mys-pdpa-2010": [ + "30(3)", + "30(4)", + "30(5)", + "31(1)", + "31(2)", + "31(2)(a)", + "31(2)(b)", + "31(3)", "32(1)", + "32(1)(a)", + "32(1)(b)", + "32(1)(c)", "32(2)", + "32(2)(a)", + "32(2)(b)", + "32(2)(c)", + "32(2)(d)", "32(3)", - "32(4)" + "33", + "33(a)", + "33(b)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.7(2)", + "4.1.44(1)", + "4.1.44(2)", + "4.1.44(2)(b)", + "4.1.44(2)(c)", + "4.1.44(2)(c)(i)", + "4.1.44(2)(c)(ii)", + "4.1.44(2)(d)", + "4.2.63(1)", + "4.2.63(1)(a)", + "4.2.63(1)(b)", + "4.2.63(1)(b)(i)", + "4.2.63(1)(b)(ii)", + "4.2.63(2)", + "4.2.63(3)", + "4.2.63(3)(a)", + "4.2.63(3)(b)", + "4.2.63(3)(c)", + "4.2.64(1)", + "4.2.64(1)(a)", + "4.2.64(1)(b)", + "4.2.64(1)(b)(i)", + "4.2.64(1)(b)(ii)", + "4.2.64(2)", + "4.2.64(3)" + ], + "apac-sgp-pdpa-2012": [ + "3.12(b)", + "4.1.16(2)", + "5.21(6)", + "5.21(6)(b)", + "5.21(7)", + "5.21(7)(b)" ], "apac-kor-pipa-2011": [ - "37" - ], - "americas-arg-ppd-2018": [ - "16.2", - "16.6" + "V.36(2)", + "V.36(3)", + "V.36(4)", + "V.36(5)", + "V.37(2)", + "V.37(2)1", + "V.37(2)2", + "V.37(2)3", + "V.37(2)4", + "V.37(3)", + "V.37(4)" + ], + "apac-twn-pdpa-2025": [ + "I.10", + "I.10.1", + "I.10.2", + "I.10.3" ], "americas-bhs-dpa-2003": [ - "11" + "IV.24(4)", + "IV.24(4)(a)", + "IV.24(4)(b)", + "IV.24(5)", + "IV.24(5)(a)", + "IV.24(5)(b)", + "IV.24(10)", + "IV.24(10)(a)", + "IV.24(10)(b)", + "IV.24(10)(c)", + "IV.24(10)(d)", + "IV.24(13)(f)", + "IV.27(3)", + "IV.28(5)(a)", + "IV.28(5)(b)", + "IV.29(3)(a)", + "IV.29(3)(b)" ], "americas-bra-lgpd-2018": [ - "18", - "19", - "21" + "III.18.IX.4.I", + "III.18.IX.4.II", + "III.18.IX.5" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(b)", + "P9-4.9.1", + "P9-4.9.4", + "P10-4.10.2", + "P10-4.10.3", + "P10-4.10.4" ], "americas-col-law-1581-2012": [ - "12", - "15" + "IV.12(a)", + "IV.12(b)", + "IV.12(c)", + "IV.12(d)", + "V.15.2", + "V.15.3", + "VI.17(j)" ], "americas-mex-fdpa-2010": [ - "30" + "IV.32", + "IV.33" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.5.json b/docs/api/controls/PRI-06.5.json index 0e452e29..8fbe092b 100644 --- a/docs/api/controls/PRI-06.5.json +++ b/docs/api/controls/PRI-06.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to erase a data subject's Personal Data (PD), in accordance with applicable laws, regulations and contractual obligations pertaining to the retention of their PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -75,16 +75,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ "P4.3-POF1" ], - "general-scf-dpmp-2025": [ - "6.6" - ], "usa-state-ca-ccpa-cpra-2026": [ "7022(b)(1)", "7022(f)(2)" @@ -92,6 +90,14 @@ "usa-state-co-privacy-act-2021": [ "6-1-1306(1)(d)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.505.1(d)", + "603A.515.1", + "603A.515.1(a)", + "603A.515.1(b)", + "603A.515.2", + "603A.515.3" + ], "usa-state-or-ors-646a-2025": [ "646A.574(1)(c)" ], @@ -125,66 +131,64 @@ "Article 17.3(d)", "Article 17.3(e)" ], + "emea-aut-dpa-2018": [ + "§ 45(2)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 39(2)" + ], + "emea-deu-fdpa-2017": [ + "2.2.35(1)", + "3.3.58(2)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.e" + ], "emea-ken-pda-2019": [ - "26(e)", - "40(1)(b)", - "40(2)(b)", - "40(3)" + "IV.26(e)", + "IV.40(1)(b)", + "IV.40(3)" ], "emea-nga-dpr-2019": [ - "3.1(13)" + "3.1(9)(e)" ], "emea-qat-pdppl-2020": [ - "5.3" + "2.5.3" ], "emea-srb-act-9-2018": [ - "30", - "30.x", - "32", - "32.1", - "32.2" + "III.3.30-1", + "III.3.32" + ], + "emea-gbr-dpa-2018": [ + "Section 47(1)", + "Section 47(1)(a)", + "Section 47(1)(b)" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], - "apac-chn-pipl-2021": [ - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)", - "49" + "apac-chn-csnip-2012": [ + "VIII" ], "apac-ind-dpdpa-2023": [ "8(7)(a)", "12(1)", "12(3)" ], - "apac-jpn-ppi-2020": [ - "30(1)", - "30(2)", - "30(3)", - "30(4)", - "30(5)", - "30(6)", - "30(7)", - "33(1)", - "33(2)", - "34", - "34(1)", - "34(2)", - "34(3)", - "35(1)", - "35(2)" - ], - "americas-arg-ppd-2018": [ - "16.5", - "16.7" - ], - "americas-bra-lgpd-2018": [ - "18.4", - "18.6" + "americas-bhs-dpa-2003": [ + "IV.28(1)", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(c)", + "IV.28(2)(d)", + "IV.28(2)(e)", + "IV.28(4)", + "IV.28(4)(a)", + "IV.28(4)(b)", + "IV.28(4)(c)", + "IV.28(4)(d)", + "IV.28(4)(e)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.6.json b/docs/api/controls/PRI-06.6.json index 6960a0a3..3c21c5b8 100644 --- a/docs/api/controls/PRI-06.6.json +++ b/docs/api/controls/PRI-06.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to format exports of Personal Data (PD) in a structured, machine-readable format that allows data subjects to transfer their PD to another controller without hindrance.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -59,7 +59,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -70,12 +71,9 @@ "ID.DE-P4", "CT.DM-P6" ], - "general-scf-dpmp-2025": [ - "5.7" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(c)(2)(i)", - "164.524(c)(2)(ii)" + "§ 164.524(c)(2)(i)", + "§ 164.524(c)(2)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7024(g)" @@ -99,44 +97,32 @@ "Article 20.1" ], "emea-ken-pda-2019": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IV.38(1)", + "IV.38(2)", + "IV.38(3)" ], "emea-nga-dpr-2019": [ - "3.1(6)", "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)", "3.1(15)" ], - "emea-qat-pdppl-2020": [ - "6.3" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], "emea-srb-act-9-2018": [ - "21", - "22", - "36", - "36.1", - "36.2" + "III.3.36" + ], + "apac-chn-pipl-2021": [ + "Article 45" ], - "americas-arg-ppd-2018": [ - "15.1", - "15.2", - "15.3" + "apac-phl-dpa-2012": [ + "IV.18" ], "americas-bra-lgpd-2018": [ - "18.5", - "40" + "III.18.IX.7", + "III.19", + "III.19.II", + "III.19.II.1", + "III.19.II.2", + "III.19.II.2.I", + "III.19.II.2.II", + "III.19.II.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.7.json b/docs/api/controls/PRI-06.7.json index 6b7eb0f9..6cb8d735 100644 --- a/docs/api/controls/PRI-06.7.json +++ b/docs/api/controls/PRI-06.7.json @@ -3,7 +3,7 @@ "title": "Personal Data (PD) Exports", "family": "PRI", "description": "Mechanisms exist to export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request.", - "scf_question": "Does the organization process an export of a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request?", + "scf_question": "Does the organization export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57,7 +57,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -83,9 +84,6 @@ "7(b)", "7(b)(iv)" ], - "general-scf-dpmp-2025": [ - "5.7" - ], "usa-state-ca-ccpa-cpra-2026": [ "7024(g)" ], @@ -113,34 +111,32 @@ "Article 20.1(b)" ], "emea-ken-pda-2019": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IV.38(1)", + "IV.38(2)" ], "emea-nga-dpr-2019": [ - "3.1(6)", - "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)" - ], - "emea-qat-pdppl-2020": [ - "6.3" + "3.1(14)" ], - "emea-srb-act-9-2018": [ - "21", - "22" - ], - "apac-chn-pipl-2021": [ - "45" + "emea-gbr-dpa-2018": [ + "Section 52(1)", + "Section 52(2)", + "Section 52(3)", + "Section 52(5)" ], "apac-ind-dpdpa-2023": [ "11(1)(a)" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.58(1)", + "4.1.58(1)(a)", + "4.1.58(1)(b)", + "4.1.58(1)(c)", + "4.1.58(1)(d)", + "4.1.58(1)(e)", + "4.1.58(1)(f)" + ], + "americas-bra-lgpd-2018": [ + "III.19.I" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.8.json b/docs/api/controls/PRI-06.8.json index adf623b7..9d18b9f5 100644 --- a/docs/api/controls/PRI-06.8.json +++ b/docs/api/controls/PRI-06.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to utilize reasonable consumer expectations to verify a data subject's identity, prior to taking action to disclose, share, correct, amend and/or delete Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57,16 +57,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ "A5.1-POF1" ], - "general-scf-dpmp-2025": [ - "6.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7060(a)", "7060(b)", @@ -98,8 +96,43 @@ "6-1-1306(1)", "6-1-1306(2)(d)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.505.2(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.576(2)" + ], + "emea-deu-fdpa-2017": [ + "3.3.57(3)", + "3.3.59(4)" + ], + "emea-nga-dpr-2019": [ + "3.1(5)" + ], + "emea-qat-pdppl-2020": [ + "4.17.3" + ], + "emea-gbr-dpa-2018": [ + "Section 52(4)", + "Section 52(4)(a)", + "Section 52(4)(b)" + ], + "apac-aus-privacy-principles-2026": [ + "1.2.2.a", + "1.2.2.b" + ], + "apac-mys-pdpa-2010": [ + "32(1)(a)(i)", + "32(1)(a)(ii)", + "32(1)(a)(ii)(A)", + "32(1)(a)(ii)(B)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.2" + ], + "americas-col-law-1581-2012": [ + "IV.9", + "IV.12" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-06.json b/docs/api/controls/PRI-06.json index 9e833d1a..76e9da56 100644 --- a/docs/api/controls/PRI-06.json +++ b/docs/api/controls/PRI-06.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide authenticated data subjects the ability to:\n(1) Access their Personal Data (PD) that is being processed, stored and shared, except where the burden, risk or expense of providing access would be disproportionate to the benefit offered to the data subject through granting access;\n(2) Obtain answers on the specifics of how their PD is collected, received, processed, stored, transmitted, shared, updated and/or disposed; \n(3) Obtain the source(s) of their PD; \n(4) Obtain the categories of their PD being collected, received, processed, stored and shared; \n(5) Request correction to their PD due to inaccuracies;\n(6) Request erasure of their PD; and\n(7) Restrict the further collecting, receiving, processing, storing, transmitting, updated and/or sharing of their PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -79,7 +79,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -105,7 +106,7 @@ ], "general-iso-29100-2024": [ "6.9", - "6.1" + "6.10" ], "general-nist-800-53-r4": [ "IP-2" @@ -125,9 +126,6 @@ "general-oecd-privacy-principles-2010": [ "7(a)" ], - "general-scf-dpmp-2025": [ - "6.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)", "Sec. 6502.(b)(1)(B)(iii)" @@ -172,46 +170,46 @@ "155.260(a)(3)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(2)(i)", - "164.502(a)(2)(ii)", - "164.514(h)(1)(i)", - "164.514(h)(1)(ii)", - "164.524(a)(1)", - "164.524(a)(1)(i)", - "164.524(a)(1)(ii)", - "164.524(a)(1)(iii)", - "164.524(a)(1)(iii)(A)", - "164.524(a)(1)(iii)(B)", - "164.524(a)(2)", - "164.524(a)(2)(i)", - "164.524(a)(2)(ii)", - "164.524(a)(2)(iii)", - "164.524(a)(2)(iv)", - "164.524(a)(2)(v)", - "164.524(a)(3)", - "164.524(a)(3)(i)", - "164.524(a)(3)(ii)", - "164.524(a)(3)(iii)", - "164.524(a)(4)", - "164.524(b)(1)", - "164.524(b)(2)(i)", - "164.524(b)(2)(i)(A)", - "164.524(b)(2)(i)(B)", - "164.524(b)(2)(ii)", - "164.524(b)(2)(ii)(A)", - "164.524(b)(2)(ii)(B)", - "164.524(c)", - "164.524(c)(1)", - "164.524(c)(3)(i)", - "164.524(c)(3)(ii)", - "164.524(c)(4)", - "164.524(c)(4)(i)", - "164.524(c)(4)(ii)", - "164.524(c)(4)(iii)", - "164.524(c)(4)(iv)", - "164.524(d)", - "164.524(d)(1)", - "164.524(d)(2)" + "§ 164.502(a)(2)(i)", + "§ 164.502(a)(2)(ii)", + "§ 164.514(h)(1)(i)", + "§ 164.514(h)(1)(ii)", + "§ 164.524(a)(1)", + "§ 164.524(a)(1)(i)", + "§ 164.524(a)(1)(ii)", + "§ 164.524(a)(1)(iii)", + "§ 164.524(a)(1)(iii)(A)", + "§ 164.524(a)(1)(iii)(B)", + "§ 164.524(a)(2)", + "§ 164.524(a)(2)(i)", + "§ 164.524(a)(2)(ii)", + "§ 164.524(a)(2)(iii)", + "§ 164.524(a)(2)(iv)", + "§ 164.524(a)(2)(v)", + "§ 164.524(a)(3)", + "§ 164.524(a)(3)(i)", + "§ 164.524(a)(3)(ii)", + "§ 164.524(a)(3)(iii)", + "§ 164.524(a)(4)", + "§ 164.524(b)(1)", + "§ 164.524(b)(2)(i)", + "§ 164.524(b)(2)(i)(A)", + "§ 164.524(b)(2)(i)(B)", + "§ 164.524(b)(2)(ii)", + "§ 164.524(b)(2)(ii)(A)", + "§ 164.524(b)(2)(ii)(B)", + "§ 164.524(c)", + "§ 164.524(c)(1)", + "§ 164.524(c)(3)(i)", + "§ 164.524(c)(3)(ii)", + "§ 164.524(c)(4)", + "§ 164.524(c)(4)(i)", + "§ 164.524(c)(4)(ii)", + "§ 164.524(c)(4)(iii)", + "§ 164.524(c)(4)(iv)", + "§ 164.524(d)", + "§ 164.524(d)(1)", + "§ 164.524(d)(2)" ], "usa-federal-cms-marse-2-0": [ "IP-2", @@ -244,6 +242,16 @@ "6-1-1306(1)(b)", "6-1-1306(2)(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.345.2", + "603A.346.2", + "603A.505.1(a)", + "603A.505.1(b)", + "603A.505.2", + "603A.505.2(a)", + "603A.510.3(a)(1)", + "603A.510.3(a)(2)" + ], "usa-state-nv-sb220-2019": [ "2.1", "2.2" @@ -302,59 +310,104 @@ "Article 18.1(c)", "Article 18.1(d)" ], - "emea-aut-fappd-2000": [ - "Sec 26" + "emea-aut-dpa-2018": [ + "§ 42(1)", + "§ 42(2)", + "§ 44(1)", + "§ 44(5)" ], - "emea-bel-act-8-1992": [ - "10", - "12" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(2)", + "Title 2, Chapter III, Art. 38(1)", + "Title 2, Chapter III, Art. 38(2)", + "Title 2, Chapter III, Art. 39(1)" ], "emea-deu-fdpa-2017": [ - "Sec 19" + "3.3.57(1)", + "3.3.57(1)2", + "3.3.57(1)3", + "3.3.57(1)4", + "3.3.57(1)5", + "3.3.57(1)6", + "3.3.57(1)7", + "3.3.57(1)8", + "3.3.58(1)", + "3.3.58(2)" ], "emea-grc-pirppd-1997": [ - "11", - "12" - ], - "emea-hun-isdfi-2011": [ - "14", - "15" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "13" - ], - "emea-ita-pdpc-2003": [ - "7" + "C.12.1", + "C.12.2", + "C.12.2.a", + "C.12.2.b", + "C.12.2.c", + "C.12.2.d", + "C.12.2.e", + "C.12.2.f" + ], + "emea-hun-act-cxii-2011": [ + "II.13.14(a)", + "II.13.14(b)", + "II.13.14(c)", + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)" + ], + "emea-irl-dpa-2018": [ + "s.56", + "s.57", + "s.58", + "s.59", + "s.60", + "s.61", + "s.91", + "s.92" + ], + "emea-isr-ppl-5741-2025": [ + "s.13", + "s.14" ], "emea-ken-pda-2019": [ - "26(a)", - "26(b)", - "26(c)", - "26(d)", - "26(e)" + "IV.26(b)", + "IV.27", + "IV.34(1)", + "IV.35(3)(b)(i)", + "IV.35(3)(b)(ii)", + "IV.38(1)", + "IV.38(2)", + "IV.38(3)", + "IV.40(1)", + "IV.40(1)(a)", + "IV.40(1)(b)" ], "emea-nga-dpr-2019": [ - "3.1(1)", - "3.1(3)", - "3.1(3)(a)", - "3.1(3)(b)" - ], - "emea-nor-pda-2018": [ - "18" - ], - "emea-pol-act-29-1997": [ - "32" + "2.8(a)", + "3.1(9)", + "3.1(9)(a)", + "3.1(9)(b)", + "3.1(9)(c)", + "3.1(9)(d)", + "3.1(9)(e)", + "3.1(11)", + "3.1(11)(a)", + "3.1(11)(b)", + "3.1(11)(c)", + "3.1(11)(d)", + "3.1(15)" ], "emea-qat-pdppl-2020": [ - "6", - "21.1", - "21.2" - ], - "emea-rus-federal-law-27-2006": [ - "14" + "2.5.1", + "2.5.2", + "2.5.3", + "2.5.4", + "2.6", + "2.6.1", + "2.6.2", + "3.11.6" + ], + "emea-rus-152-fz-2025": [ + "Art. 14", + "Art. 15", + "Art. 20" ], "emea-sau-pdpl-2023": [ "Article 4.2", @@ -364,131 +417,258 @@ "Article 21" ], "emea-srb-act-9-2018": [ - "21", - "23", - "24", - "25", - "26", - "28.1", - "28.2", - "28.3", - "28.4", - "28.5" + "III.2.26", + "III.2.26(1)", + "III.2.26(2)", + "III.2.26(3)", + "III.2.26(4)", + "III.2.26(5)", + "III.2.26(6)", + "III.2.26(7)", + "III.2.26(8)", + "III.2.27", + "III.2.27(1)", + "III.2.27(2)", + "III.2.27(3)", + "III.2.27(4)", + "III.2.27(5)", + "III.2.27(6)", + "III.2.27(7)" ], "emea-zaf-popia-2013": [ - "23" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "27", - "28", - "29" + "3.A.8.23(1)", + "3.A.8.23(1)(a)", + "3.A.8.23(1)(b)", + "3.A.8.23(1)(b)(i)", + "3.A.8.23(1)(b)(ii)", + "3.A.8.23(1)(b)(iii)", + "3.A.8.23(1)(b)(iv)", + "3.A.8.23(2)", + "3.A.8.23(3)", + "3.A.8.23(3)(a)", + "3.A.8.23(3)(b)" ], "emea-che-fadp-2025": [ - "8" + "3.21.2", + "4.25.1", + "4.25.2", + "4.25.2.a", + "4.25.2.b", + "4.25.2.c", + "4.25.2.d", + "4.25.2.e", + "4.25.2.f", + "4.25.2.g", + "4.25.3", + "4.25.4", + "4.25.5", + "4.28.1", + "4.28.1.a", + "4.28.1.b", + "4.28.2" ], "emea-tur-lppd-2016": [ - "11" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 12" + "13(1)", + "13(2)", + "13(3)" + ], + "emea-gbr-dpa-2018": [ + "Section 45(1)", + "Section 45(1)(a)", + "Section 45(1)(b)", + "Section 45(2)", + "Section 45(2)(a)", + "Section 45(2)(b)", + "Section 45(2)(c)", + "Section 45(2)(d)", + "Section 45(2)(e)", + "Section 45(2)(e)(i)", + "Section 45(2)(e)(ii)", + "Section 45(2)(f)", + "Section 45(2)(g)", + "Section 45(2A)" ], "apac-aus-privacy-principles-2026": [ - "APP 12" + "3.7.6", + "3.7.6.a", + "3.7.6.b", + "3.7.6.c", + "3.7.6.d", + "3.7.6.e", + "3.7.7", + "3.7.7.a", + "3.7.7.b", + "5.12.1" + ], + "apac-chn-csnip-2012": [ + "VIII" ], "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "Article 44", + "Article 48" ], "apac-hkg-pdo-2022": [ - "Principle 6", - "Sec 17A", - "Sec 18" + "18(1)", + "18(1)(a)", + "18(1)(b)", + "18(2)", + "18(3)", + "18(4)", + "18(4)(a)", + "18(4)(b)", + "35G(3)", + "Schedule 1 - 6", + "Schedule 1 - 6(a)", + "Schedule 1 - 6(b)", + "Schedule 1 - 6(b)(i)", + "Schedule 1 - 6(b)(ii)", + "Schedule 1 - 6(b)(iii)", + "Schedule 1 - 6(b)(iv)", + "Schedule 1 - 6(c)", + "Schedule 1 - 6(d)", + "Schedule 1 - 6(e)", + "Schedule 1 - 6(f)", + "Schedule 1 - 6(g)" ], "apac-ind-dpdpa-2023": [ "11(1)(c)", "11(2)" ], - "apac-jpn-ppi-2020": [ - "27(1)", - "27(1)(i)", - "27(1)(ii)", - "27(1)(iii)", - "27(1)(iv)", - "27(2)(i)", - "27(2)(ii)", - "27(3)", - "28(1)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)" + "apac-jpn-appi-2020": [ + "IV.1.28(1)" ], "apac-mys-pdpa-2010": [ "12", - "30" + "30(1)", + "30(2)(a)", + "30(2)(b)", + "34(1)(a)", + "34(1)(b)", + "34(2)" ], "apac-nzl-privacy-act-2020": [ - "Principle 6", - "P6-(1)", - "P6-(1)(a)", - "P6-(1)(b)", - "P6-(2)", - "P6-(3)" + "3.1.22.6(1)", + "3.1.22.6(1)(a)", + "3.1.22.6(1)(b)", + "3.1.22.6(2)", + "3.1.22.7(1)", + "3.1.22.7(3)", + "3.1.22.7(3)(a)", + "4.2.59" ], "apac-phl-dpa-2012": [ - "34" + "IV.16", + "IV.16(a)", + "IV.16(b)", + "IV.16(b)(1)", + "IV.16(b)(2)", + "IV.16(b)(3)", + "IV.16(b)(4)", + "IV.16(b)(5)", + "IV.16(b)(6)", + "IV.16(b)(7)", + "IV.16(b)(8)", + "IV.16(c)", + "IV.16(c)(1)", + "IV.16(c)(2)", + "IV.16(c)(3)", + "IV.16(c)(4)", + "IV.16(c)(5)", + "IV.16(c)(6)", + "IV.16(c)(7)", + "IV.16(c)(8)", + "IV.16(d)", + "IV.16(e)", + "IV.16(f)" ], "apac-sgp-pdpa-2012": [ - "21" + "4.1.16(3)", + "5.21(1)", + "5.21(1)(a)", + "5.21(1)(b)", + "5.21(2)", + "5.21(5)" ], "apac-kor-pipa-2011": [ - "4", - "35" + "V.35(1)", + "V.35(2)", + "V.35(3)", + "V.36(1)" ], "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "4.6", - "13", - "14.1", - "14.2", - "14.3", - "14.4" + "I.3", + "I.3.1", + "I.3.2", + "I.3.3", + "I.3.4", + "I.3.5" ], "americas-bhs-dpa-2003": [ - "8" + "IV.27(1)", + "IV.29(1)", + "IV.29(1)(a)", + "IV.29(1)(b)", + "IV.29(1)(c)", + "IV.29(1)(d)", + "IV.29(1)(e)", + "IV.29(1)(f)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(2)", + "IV.30(2)(a)", + "IV.30(2)(b)", + "IV.30(3)" ], "americas-bra-lgpd-2018": [ - "6.4", - "9", - "17", - "18.1", - "18.2", - "20" + "III.18", + "III.18.I", + "III.18.II", + "III.18.III", + "III.18.IV", + "III.18.V", + "III.18.VI", + "III.18.VII", + "III.18.VIII", + "III.18.IX", + "III.18.IX.1", + "III.18.IX.2", + "III.18.IX.3", + "III.18.IX.4" ], "americas-can-pipeda-2000": [ - "Principle 8", - "Principle 9" + "P9-4.9", + "P10-4.10" ], "americas-chl-act-19628-1999": [ - "12" + "II.12", + "II.13", + "II.14" ], "americas-col-law-1581-2012": [ - "8", - "11" + "II.4(e)", + "IV.8(a)", + "IV.8(b)", + "IV.8(c)", + "IV.8(f)", + "IV.11", + "V.14", + "V.15", + "V.15.1" ], "americas-mex-fdpa-2010": [ - "15", - "22", - "23", - "25" + "II.16.III", + "III.22", + "III.23", + "III.25", + "III.27", + "IV.28", + "IV.29", + "IV.29.I", + "IV.29.II", + "IV.29.III", + "IV.29.IV", + "IV.31" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-07.1.json b/docs/api/controls/PRI-07.1.json index f2268ca0..31cbab99 100644 --- a/docs/api/controls/PRI-07.1.json +++ b/docs/api/controls/PRI-07.1.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include data privacy requirements in contracts and other acquisition-related documents that establish data privacy roles and responsibilities for contractors and service providers.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include data privacy requirements in contracts and other acquisition-related documents that establish data privacy roles and responsibilities for contractors and service providers. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -85,7 +85,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -126,7 +127,7 @@ "5.33" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "ID.DE-P3" @@ -148,22 +149,19 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-tisax-6-0-3": [ "9.5.2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.504(e)(2)(i)", - "164.504(e)(2)(ii)(A)", - "164.504(e)(2)(ii)(B)", - "164.504(e)(2)(ii)(C)", - "164.504(e)(4)(i)", - "164.504(e)(4)(i)(A)", - "164.504(e)(4)(i)(B)", - "164.504(e)(4)(i)(B)(ii)", - "164.504(e)(4)(i)(B)(ii)(A)" + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(ii)(A)", + "§ 164.504(e)(2)(ii)(B)", + "§ 164.504(e)(2)(ii)(C)", + "§ 164.504(e)(4)(i)", + "§ 164.504(e)(4)(i)(A)", + "§ 164.504(e)(4)(i)(B)", + "§ 164.504(e)(4)(i)(B)(ii)", + "§ 164.504(e)(4)(i)(B)(ii)(A)" ], "usa-federal-cms-marse-2-0": [ "AR-3", @@ -212,6 +210,15 @@ "usa-state-il-pipa-2006": [ "45(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.3", + "603A.495.3(d)", + "603A.530.1", + "603A.530.2", + "603A.530.3", + "603A.530.3(a)", + "603A.530.3(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.581(2)" ], @@ -287,124 +294,167 @@ "Article 29", "Article 46.3(a)" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-deu-c5-2020": [ - "HR-06", - "PI-02" - ], - "emea-isr-cmo-1-0": [ - "11.1" + "emea-aut-dpa-2018": [ + "§ 48(1)", + "§ 48(2)", + "§ 48(3)", + "§ 48(4)", + "§ 48(5)", + "§ 48(6)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 3, Art. 53(1)", + "Title 2, Chapter IV, Section 3, Art. 53(2)", + "Title 2, Chapter IV, Section 3, Art. 53(3)", + "Title 2, Chapter IV, Section 3, Art. 53(4)", + "Title 2, Chapter IV, Section 3, Art. 53(5)", + "Title 2, Chapter IV, Section 3, Art. 54" + ], + "emea-grc-pirppd-1997": [ + "B.10.4" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(1)", + "II.8.9(1)(c)", + "II.8.9(1)(e)", + "II.8.9(2)", + "II.8.9(3)", + "II.8.9(5)", + "II.9.10(1)", + "II.9.10(2)", + "II.9.10(3)", + "II.9.10(4)", + "II.10.11(1)(a)" + ], + "emea-irl-dpa-2018": [ + "s.80" + ], + "emea-isr-ppl-5741-2025": [ + "s.13A" ], "emea-ken-pda-2019": [ - "25(h)", - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "IV.25(h)", + "IV.40(2)(a)", + "IV.40(2)(b)", + "IV.40(3)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], "emea-nga-dpr-2019": [ - "2.4(b)", "2.7" ], - "emea-qat-pdppl-2020": [ - "12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-25" - ], "emea-srb-act-9-2018": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "45", - "45.x", - "46" + "IV.1.45-1", + "IV.1.45-1(1)", + "IV.1.45-1(2)", + "IV.1.45-1(3)", + "IV.1.45-1(4)", + "IV.1.45-1(5)", + "IV.1.45-1(6)", + "IV.1.45-1(7)", + "IV.1.45-1(8)", + "IV.1.45-2", + "IV.1.45-2(1)", + "IV.1.45-2(2)", + "IV.1.45-2(3)", + "IV.1.45-2(4)", + "IV.1.45-2(5)", + "IV.1.45-2(6)" ], "emea-zaf-popia-2013": [ - "11", - "20", - "21" - ], - "apac-aus-privacy-principles-2026": [ - "APP 7" + "3.A.7.21(1)", + "3.A.7.21(2)" + ], + "emea-gbr-dpa-2018": [ + "Section 59(1)", + "Section 59(2)", + "Section 59(2)(a)", + "Section 59(2)(b)", + "Section 59(3)", + "Section 59(4)", + "Section 59(5)", + "Section 59(5)(a)", + "Section 59(5)(b)", + "Section 59(5)(c)", + "Section 59(5)(d)", + "Section 59(6)", + "Section 59(6)(a)", + "Section 59(6)(b)", + "Section 59(6)(c)", + "Section 59(6)(d)", + "Section 59(6)(d)(i)", + "Section 59(6)(d)(ii)", + "Section 59(6)(e)", + "Section 59(6)(f)", + "Section 59(7)", + "Section 59(7A)", + "Section 59(8)", + "Section 60", + "Section 60(a)", + "Section 60(b)", + "Section 63" + ], + "apac-aus-cop-sitc-2020": [ + "5" ], "apac-chn-pipl-2021": [ - "20", - "21", - "27", - "38(3)", - "42" + "Article 21" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 4(2)" ], "apac-ind-dpdpa-2023": [ "8(2)", "8(7)(b)" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "apac-ind-privacy-rules-2011": [ + "6(4)" ], - "apac-kor-pipa-2011": [ - "26", - "27" + "apac-phl-dpa-2012": [ + "III.14", + "V.20(d)" ], - "americas-arg-ppd-2018": [ - "11.4" + "apac-kor-pipa-2011": [ + "III.1.18(5)" + ], + "americas-bhs-dpa-2003": [ + "V.51(1)(a)", + "V.51(1)(b)", + "V.51(1)(b)(i)", + "V.51(1)(b)(ii)", + "V.51(1)(b)(iii)", + "V.51(1)(b)(iv)", + "V.51(2)(a)", + "V.51(2)(b)", + "V.51(2)(c)", + "V.51(2)(d)", + "V.51(2)(e)", + "V.51(2)(f)", + "V.51(2)(g)", + "V.51(2)(h)", + "V.51(3)", + "V.51(4)", + "V.51(5)", + "V.51(5)(a)", + "V.51(5)(b)", + "V.51(6)", + "V.51(7)", + "V.51(8)" ], "americas-bra-lgpd-2018": [ - "35", - "39" + "VI.I.39" ], "americas-can-pipeda-2000": [ - "Sec 20", - "Sec 23" + "P1-4.1.3" + ], + "americas-col-law-1581-2012": [ + "VI.17(i)" + ], + "americas-mex-fdpa-2010": [ + "II.21" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-07.2.json b/docs/api/controls/PRI-07.2.json index 3b06d989..1e363279 100644 --- a/docs/api/controls/PRI-07.2.json +++ b/docs/api/controls/PRI-07.2.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to clearly define and communicate the organization's role in processing Personal Data (PD) in the data processing ecosystem.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to clearly define and communicate the organization's role in processing Personal Data (PD) in the data processing ecosystem. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -90,70 +91,50 @@ "general-nist-privacy-framework-1-0": [ "ID.BE-P1" ], - "general-scf-dpmp-2025": [ - "11.1" - ], "usa-state-or-cpa-2023": [ "Section 6(1)(a)" ], "usa-state-tn-tipa-2025": [ "47-18-3205(d)" ], - "emea-ken-pda-2019": [ - "42(2)(a)", - "42(2)(b)", - "42(3)" + "emea-aut-dpa-2018": [ + "§ 47" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 2, Art. 52" + ], + "emea-deu-fdpa-2017": [ + "3.4.62(1)", + "3.4.62(2)", + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)9", + "3.4.63" + ], + "emea-grc-pirppd-1997": [ + "B.8.1" + ], + "emea-irl-dpa-2018": [ + "s.79" ], "emea-srb-act-9-2018": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "43" + "IV.1.43" ], - "apac-chn-pipl-2021": [ - "20", - "21", - "27", - "38(3)" + "emea-gbr-dpa-2018": [ + "Section 58(1)", + "Section 58(2)", + "Section 58(3)" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" + "apac-chn-pipl-2021": [ + "Article 20" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-07.3.json b/docs/api/controls/PRI-07.3.json index b532911d..293cb404 100644 --- a/docs/api/controls/PRI-07.3.json +++ b/docs/api/controls/PRI-07.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to inform applicable third-parties of any modification, deletion or other change that affects shared Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -74,7 +74,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -84,9 +85,6 @@ "general-nist-privacy-framework-1-0": [ "CM.AW-P5" ], - "general-scf-dpmp-2025": [ - "6.4" - ], "usa-state-ca-ccpa-cpra-2026": [ "7022(b)(2)", "7022(b)(3)", @@ -99,48 +97,36 @@ "usa-state-va-cdpa-2023": [ "59.1-579.B.2" ], + "emea-deu-fdpa-2017": [ + "3.3.58(5)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.f" + ], + "emea-hun-act-cxii-2011": [ + "II.13.18(1)" + ], "emea-ken-pda-2019": [ - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)" + "IV.40(2)", + "IV.40(3)" ], "emea-nga-dpr-2019": [ "3.1(10)" ], "emea-srb-act-9-2018": [ - "30", - "30.x", - "32", - "32.1", - "32.2", - "33" + "II.11" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.7(5)" + ], + "americas-bra-lgpd-2018": [ + "III.18.IX.6" ], - "apac-chn-pipl-2021": [ - "46" + "americas-can-pipeda-2000": [ + "P9-4.9.6" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" + "americas-col-law-1581-2012": [ + "VI.17(l)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-07.4.json b/docs/api/controls/PRI-07.4.json index 3c075353..df0f0445 100644 --- a/docs/api/controls/PRI-07.4.json +++ b/docs/api/controls/PRI-07.4.json @@ -1,9 +1,9 @@ { "control_id": "PRI-07.4", - "title": "Reject Unauthenticated or Untrustworthy Disclosure Requests", + "title": "Disclosure Request Rejections", "family": "PRI", - "description": "Mechanisms exist to reject unauthenticated, or untrustworthy, disclosure requests.", - "scf_question": "Does the organization reject unauthenticated, or untrustworthy, disclosure requests?", + "description": "Mechanisms exist to reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful.", + "scf_question": "Does the organization reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject unauthenticated, or untrustworthy, disclosure requests.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -61,8 +61,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -73,15 +75,11 @@ "general-csa-cmm-4-1-0": [ "DSP-18" ], - "general-scf-dpmp-2025": [ - "6.0", - "6.1" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(d)(2)(i)", - "164.524(d)(2)(ii)", - "164.524(d)(2)(iii)", - "164.524(d)(3)" + "§ 164.524(d)(2)(i)", + "§ 164.524(d)(2)(ii)", + "§ 164.524(d)(2)(iii)", + "§ 164.524(d)(3)" ], "usa-state-ca-ccpa-cpra-2026": [ "7022(a)", @@ -99,14 +97,71 @@ "usa-state-tx-cdpa-2025": [ "541.052(e)" ], - "emea-srb-act-9-2018": [ - "21.2", - "22.2" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(4)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(1)" + ], + "emea-gbr-dpa-2018": [ + "Section 53(1)", + "Section 53(1)(a)", + "Section 53(1)(b)", + "Section 53(2)", + "Section 53(3)", + "Section 53(4)", + "Section 53(4A)", + "Section 53(4A)(a)", + "Section 53(4A)(b)", + "Section 53(5)" + ], + "apac-aus-privacy-principles-2026": [ + "5.12.3.h.i" ], "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "Article 50" + ], + "apac-hkg-pdo-2022": [ + "24(1)", + "24(1)(a)", + "24(1)(b)", + "24(1)(b)(i)", + "24(1)(b)(ii)", + "24(2)", + "24(3)", + "24(3)(a)", + "24(3)(b)", + "24(3)(c)", + "24(3)(d)", + "24(3)(e)", + "24(4)" + ], + "apac-mys-pdpa-2010": [ + "36(1)", + "36(1)(a)", + "36(1)(a)(i)", + "36(1)(a)(ii)", + "36(1)(a)(ii)(A)", + "36(1)(a)(ii)(B)", + "36(1)(b)", + "36(1)(c)", + "36(1)(d)", + "36(1)(e)", + "36(2)" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.46(1)" + ], + "apac-kor-pipa-2011": [ + "V.35(4)", + "V.35(4)1", + "V.35(4)2", + "V.35(4)3", + "V.35(4)3.a", + "V.35(4)3.b", + "V.35(4)3.c", + "V.35(4)3.d", + "V.35(4)3.e" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-07.5.json b/docs/api/controls/PRI-07.5.json index b3812c79..56bfeefa 100644 --- a/docs/api/controls/PRI-07.5.json +++ b/docs/api/controls/PRI-07.5.json @@ -2,8 +2,8 @@ "control_id": "PRI-07.5", "title": "Justification To Reject Disclosure Requests", "family": "PRI", - "description": "Mechanisms exist to reject data subject access requests that are categorized as:\n(1) Harassing; \n(2) Repetitive; or\n(3) Fraudulent.", - "scf_question": "Does the organization reject data subject access requests that are categorized as:\n (1) Harassing; \n (2) Repetitive; or\n (3) Fraudulent?", + "description": "Mechanisms exist to document justifiable reasons for rejecting a data subject's access request for disclosure when the request is:\n(1) Harassing;\n(2) Repetitive;\n(3) Fraudulent;\n(4) Unjustified; and/or\n(5) Unlawful.", + "scf_question": "Does the organization document justifiable reasons for rejecting a data subject's access request for disclosure when the request is:\n(1) Harassing;\n(2) Repetitive;\n(3) Fraudulent;\n(4) Unjustified; and/or\n(5) Unlawful?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject data subject access requests that are categorized as:\n(1) Harassing; \n(2) Repetitive; or\n(3) Fraudulent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,8 +61,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Data Privacy", "crosswalks": { "general-csa-cmm-4-1-0": [ @@ -78,14 +80,77 @@ "7027(f)", "7027(j)" ], + "emea-aut-dpa-2018": [ + "§ 44(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(5)" + ], + "emea-deu-fdpa-2017": [ + "2.2.34(2)", + "3.3.59(4)" + ], + "emea-nga-dpr-2019": [ + "3.1(4)" + ], + "emea-nor-pda-2018": [ + "16" + ], "emea-srb-act-9-2018": [ - "21.2", - "22.2" + "III.1.21(2)", + "III.1.22(2)" ], "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "Article 50" + ], + "apac-hkg-pdo-2022": [ + "20(1)", + "20(1)(a)", + "20(1)(a)(i)", + "20(1)(a)(ii)", + "20(1)(a)(ii)(A)", + "20(1)(a)(ii)(B)", + "20(1)(b)", + "20(1)(c)", + "20(2)(a)", + "20(2)(b)", + "20(3)", + "20(3)(a)", + "20(3)(b)", + "20(3)(c)", + "20(3)(c)(i)", + "20(3)(c)(ii)", + "20(3)(c)(iii)", + "20(3)(d)", + "20(3)(e)", + "20(3)(f)", + "25(1)(a)" + ], + "apac-jpn-appi-2020": [ + "IV.1.28(2)(i)", + "IV.1.28(2)(ii)", + "IV.1.28(2)(iii)" + ], + "apac-mys-pdpa-2010": [ + "32(1)(d)", + "32(1)(d)(i)", + "32(1)(d)(ii)", + "32(1)(e)", + "32(1)(f)", + "32(1)(g)", + "32(1)(h)" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.46(2)", + "4.1.46(3)" + ], + "americas-mex-fdpa-2010": [ + "IV.34", + "IV.34.I", + "IV.34.II", + "IV.34.III", + "IV.34.IV", + "IV.34.V" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-07.json b/docs/api/controls/PRI-07.json index 382dad86..30555724 100644 --- a/docs/api/controls/PRI-07.json +++ b/docs/api/controls/PRI-07.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to disclose Personal Data (PD) to third-parties only for the purposes identified in the data privacy notice and with the implicit or explicit consent of the data subject.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to disclose Personal Data (PD) to third-parties only for the purposes identified in the data privacy notice and with the implicit or explicit consent of the data subject. ", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -114,7 +115,7 @@ "5.33" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "CT.PO-P2" @@ -149,9 +150,6 @@ "general-nist-800-161-r1-level-2": [ "AC-21" ], - "general-scf-dpmp-2025": [ - "10.2" - ], "general-tisax-6-0-3": [ "9.5.2" ], @@ -174,12 +172,12 @@ "155.260(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.506(c)(1)", - "164.506(c)(2)", - "164.506(c)(3)", - "164.506(c)(4)", - "164.508(a)(1)", - "164.508(a)(4)(i)" + "§ 164.506(c)(1)", + "§ 164.506(c)(2)", + "§ 164.506(c)(3)", + "§ 164.506(c)(4)", + "§ 164.508(a)(1)", + "§ 164.508(a)(4)(i)" ], "usa-federal-irs-1075-2021": [ "AC-21" @@ -196,138 +194,97 @@ "Section 6(1)(a)", "Section 6(1)(c)" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-isr-cmo-1-0": [ - "10.5" + "emea-deu-fdpa-2017": [ + "3.5.79(1)2", + "3.5.81(1)", + "3.5.81(1)1", + "3.5.81(1)2", + "3.5.81(1)3", + "3.5.81(2)", + "3.5.81(3)", + "3.5.81(4)" + ], + "emea-grc-pirppd-1997": [ + "B.9.1", + "B.9.2.a", + "B.9.2.b", + "B.9.2.b.i", + "B.9.2.b.ii", + "B.9.2.b.iii", + "B.9.2.c", + "B.9.2.d", + "B.9.2.e" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" ], "emea-ken-pda-2019": [ - "25(h)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "IV.25(h)" ], "emea-nga-dpr-2019": [ - "2.4(b)" + "2.12(a)" + ], + "emea-qat-pdppl-2020": [ + "3.12" ], "emea-sau-pdpl-2023": [ "Article 8" ], - "emea-srb-act-9-2018": [ - "5" - ], - "emea-zaf-popia-2013": [ - "18", - "28", - "30", - "31" - ], - "apac-aus-privacy-principles-2026": [ - "APP 7", - "APP 8" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "22", - "27", - "38(3)", - "41", - "42", - "49" + "emea-tur-lppd-2016": [ + "8(1)", + "8(2)", + "8(2)(a)", + "8(2)(b)", + "8(3)" ], "apac-ind-dpdpa-2023": [ "8(2)" ], - "apac-jpn-ppi-2020": [ - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" + "apac-nzl-privacy-act-2020": [ + "3.1.22.11(1)", + "3.1.22.11(1)(a)", + "3.1.22.11(1)(b)", + "3.1.22.11(1)(c)", + "3.1.22.11(1)(d)", + "3.1.22.11(1)(e)", + "3.1.22.11(1)(e)(i)", + "3.1.22.11(1)(e)(ii)", + "3.1.22.11(1)(e)(iii)", + "3.1.22.11(1)(e)(iv)", + "3.1.22.11(1)(f)", + "3.1.22.11(1)(f)(i)", + "3.1.22.11(1)(f)(ii)", + "3.1.22.11(1)(g)", + "3.1.22.11(1)(h)", + "3.1.22.11(1)(h)(i)", + "3.1.22.11(1)(h)(ii)", + "3.1.22.11(1)(i)" ], "apac-sgp-pdpa-2012": [ - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "26", - "27" - ], - "americas-arg-ppd-2018": [ - "11.1", - "11.2", - "11.3", - "11.4", - "12.1", - "16.4" - ], - "americas-can-pipeda-2000": [ - "Sec 20", - "Sec 23" + "4.1.17(1)(c)", + "5.22(2)(b)", + "5.22(3)" + ], + "americas-bhs-dpa-2003": [ + "VI.53(1)", + "VI.54", + "VI.54(a)", + "VI.54(b)", + "VI.54(b)(i)", + "VI.54(b)(ii)", + "VI.54(b)(iii)", + "VI.54(b)(iv)", + "VI.54(b)(v)", + "VI.54(b)(vi)", + "VI.54(c)" + ], + "americas-bra-lgpd-2018": [ + "V.33" ], "americas-col-law-1581-2012": [ - "26" + "VI.17(h)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-08.json b/docs/api/controls/PRI-08.json index ff483f4c..6114adb4 100644 --- a/docs/api/controls/PRI-08.json +++ b/docs/api/controls/PRI-08.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to conduct testing, training and monitoring activities for Personal Data (PD) controls.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to conduct testing, training and monitoring activities for Personal Data (PD) controls.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,9 +83,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -136,9 +136,6 @@ "general-pci-dss-4-0-1": [ "A3.1.4" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-14" ], @@ -166,9 +163,6 @@ ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-14" - ], - "emea-zaf-popia-2013": [ - "19" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-09.json b/docs/api/controls/PRI-09.json index 9d4a06ac..ba07e3bb 100644 --- a/docs/api/controls/PRI-09.json +++ b/docs/api/controls/PRI-09.json @@ -3,7 +3,7 @@ "title": "Personal Data (PD) Lineage", "family": "PRI", "description": "Mechanisms exist to maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD.", - "scf_question": "Does the organization document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD?", + "scf_question": "Does the organization maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -59,7 +59,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -85,10 +86,6 @@ "general-nist-800-82-r3-high": [ "SA-04(12)" ], - "general-scf-dpmp-2025": [ - "5.1", - "5.13" - ], "usa-federal-gsa-fedramp-5-low": [ "SA-04(12)" ], @@ -103,9 +100,6 @@ ], "usa-federal-irs-1075-2021": [ "SA-4(CE-12)" - ], - "emea-zaf-popia-2013": [ - "17" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-10.1.json b/docs/api/controls/PRI-10.1.json index 09b20c13..a54b02d1 100644 --- a/docs/api/controls/PRI-10.1.json +++ b/docs/api/controls/PRI-10.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically support the evaluation of data quality across the information lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,7 +61,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -74,9 +75,6 @@ "general-nist-800-82-r3": [ "PT-03(02)" ], - "general-scf-dpmp-2025": [ - "5.11" - ], "usa-federal-gsa-fedramp-5-low": [ "PT-03(02)" ], diff --git a/docs/api/controls/PRI-10.2.json b/docs/api/controls/PRI-10.2.json index d34a1958..5a121b7c 100644 --- a/docs/api/controls/PRI-10.2.json +++ b/docs/api/controls/PRI-10.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to evaluate its analytical processes for potential bias.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60,12 +60,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": { - "general-scf-dpmp-2025": [ - "5.16" - ] - } + "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/PRI-10.json b/docs/api/controls/PRI-10.json index 6c2d76aa..9bce800b 100644 --- a/docs/api/controls/PRI-10.json +++ b/docs/api/controls/PRI-10.json @@ -2,8 +2,8 @@ "control_id": "PRI-10", "title": "Data Quality Management", "family": "PRI", - "description": "Mechanisms exist to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle.", - "scf_question": "Does the organization manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle?", + "description": "Mechanisms exist to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive and/or regulated data across the information lifecycle.", + "scf_question": "Does the organization manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive and/or regulated data across the information lifecycle?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -135,9 +136,6 @@ "general-oecd-privacy-principles-2010": [ "2" ], - "general-scf-dpmp-2025": [ - "5.11" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-22", "PM-23", @@ -162,10 +160,10 @@ "5" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.512(i)(1)(i)(B)", - "164.512(i)(1)(i)(B)(1)", - "164.512(i)(1)(i)(B)(2)", - "164.512(i)(1)(i)(B)(3)" + "§ 164.512(i)(1)(i)(B)", + "§ 164.512(i)(1)(i)(B)(1)", + "§ 164.512(i)(1)(i)(B)(2)", + "§ 164.512(i)(1)(i)(B)(3)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(c)" @@ -173,18 +171,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-22" ], - "emea-srb-act-9-2018": [ - "5.4", - "11" - ], - "emea-zaf-popia-2013": [ - "4" - ], - "apac-chn-pipl-2021": [ - "8" - ], - "americas-bra-lgpd-2018": [ - "6.5" + "emea-grc-pirppd-1997": [ + "B.4.1.c" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-11.json b/docs/api/controls/PRI-11.json index ccf22adc..80cb026c 100644 --- a/docs/api/controls/PRI-11.json +++ b/docs/api/controls/PRI-11.json @@ -2,8 +2,8 @@ "control_id": "PRI-11", "title": "Data Tagging", "family": "PRI", - "description": "Mechanisms exist to issue data modeling guidelines to support tagging of sensitive/regulated data.", - "scf_question": "Does the organization issue data modeling guidelines to support tagging of sensitive/regulated data?", + "description": "Mechanisms exist to issue data modeling guidelines to support tagging of sensitive and/or regulated data.", + "scf_question": "Does the organization issue data modeling guidelines to support tagging of sensitive and/or regulated data?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to issue data modeling guidelines to support tagging of sensitive/regulated data.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -60,7 +60,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -73,10 +74,6 @@ "general-nist-800-82-r3": [ "PT-03(01)" ], - "general-scf-dpmp-2025": [ - "5.0", - "5.2" - ], "usa-federal-dow-zt-roadmap-1-1": [ "4.2", "4.3", diff --git a/docs/api/controls/PRI-12.1.json b/docs/api/controls/PRI-12.1.json index 9bb7d6b6..4c6070ed 100644 --- a/docs/api/controls/PRI-12.1.json +++ b/docs/api/controls/PRI-12.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to enable data subjects to update their Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54,7 +54,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -62,6 +63,9 @@ "7023(a)", "7023(b)" ], + "apac-aus-privacy-principles-2026": [ + "5.13.1.b.ii" + ], "apac-ind-dpdpa-2023": [ "12(2)(c)" ] diff --git a/docs/api/controls/PRI-12.json b/docs/api/controls/PRI-12.json index 14acdeda..24abec76 100644 --- a/docs/api/controls/PRI-12.json +++ b/docs/api/controls/PRI-12.json @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -70,14 +71,11 @@ "P5.2", "P5.2-POF2" ], - "general-scf-dpmp-2025": [ - "6.2" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(b)(1)", - "164.526(e)", - "164.526(f)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)", + "§ 164.526(e)", + "§ 164.526(f)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(b)", @@ -89,9 +87,6 @@ ], "emea-sau-pdpl-2023": [ "Article 17.1" - ], - "emea-zaf-popia-2013": [ - "16" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-13.json b/docs/api/controls/PRI-13.json index 411b6750..d2e59d80 100644 --- a/docs/api/controls/PRI-13.json +++ b/docs/api/controls/PRI-13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to establish a written charter for a Data Management Board (DMB) and assigned organization-defined roles to the DMB.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -112,9 +113,6 @@ "general-nist-800-161-r1-level-1": [ "PM-23" ], - "general-scf-dpmp-2025": [ - "11.4" - ], "general-shared-assessments-sig-2025": [ "P.8" ], diff --git a/docs/api/controls/PRI-14.1.json b/docs/api/controls/PRI-14.1.json index 1fcc6446..c692cd40 100644 --- a/docs/api/controls/PRI-14.1.json +++ b/docs/api/controls/PRI-14.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with an accounting of disclosures of their Personal Data (PD) controlled by:\n(1) The organization; and/or\n(2) Relevant third-parties that their PD was shared with.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -132,49 +133,46 @@ "general-nist-800-161-r1-level-2": [ "PM-21" ], - "general-scf-dpmp-2025": [ - "5.8" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.528(a)(1)", - "164.528(a)(1)(i)", - "164.528(a)(1)(ii)", - "164.528(a)(1)(iii)", - "164.528(a)(1)(iv)", - "164.528(a)(1)(v)", - "164.528(a)(1)(vi)", - "164.528(a)(1)(vii)", - "164.528(a)(1)(viii)", - "164.528(a)(1)(ix)", - "164.528(b)", - "164.528(b)(1)", - "164.528(b)(2)", - "164.528(b)(2)(i)", - "164.528(b)(2)(ii)", - "164.528(b)(2)(iii)", - "164.528(b)(2)(iv)", - "164.528(b)(3)", - "164.528(b)(3)(i)", - "164.528(b)(3)(ii)", - "164.528(b)(3)(iii)", - "164.528(b)(4)(i)", - "164.528(b)(4)(i)(A)", - "164.528(b)(4)(i)(B)", - "164.528(b)(4)(i)(C)", - "164.528(b)(4)(i)(D)", - "164.528(b)(4)(i)(E)", - "164.528(b)(4)(i)(F)", - "164.528(b)(4)(ii)", - "164.528(c)(1)", - "164.528(c)(1)(i)", - "164.528(c)(1)(ii)", - "164.528(c)(1)(ii)(A)", - "164.528(c)(1)(ii)(B)", - "164.528(c)(2)", - "164.528(d)", - "164.528(d)(1)", - "164.528(d)(2)", - "164.528(d)(3)" + "§ 164.528(a)(1)", + "§ 164.528(a)(1)(i)", + "§ 164.528(a)(1)(ii)", + "§ 164.528(a)(1)(iii)", + "§ 164.528(a)(1)(iv)", + "§ 164.528(a)(1)(v)", + "§ 164.528(a)(1)(vi)", + "§ 164.528(a)(1)(vii)", + "§ 164.528(a)(1)(viii)", + "§ 164.528(a)(1)(ix)", + "§ 164.528(b)", + "§ 164.528(b)(1)", + "§ 164.528(b)(2)", + "§ 164.528(b)(2)(i)", + "§ 164.528(b)(2)(ii)", + "§ 164.528(b)(2)(iii)", + "§ 164.528(b)(2)(iv)", + "§ 164.528(b)(3)", + "§ 164.528(b)(3)(i)", + "§ 164.528(b)(3)(ii)", + "§ 164.528(b)(3)(iii)", + "§ 164.528(b)(4)(i)", + "§ 164.528(b)(4)(i)(A)", + "§ 164.528(b)(4)(i)(B)", + "§ 164.528(b)(4)(i)(C)", + "§ 164.528(b)(4)(i)(D)", + "§ 164.528(b)(4)(i)(E)", + "§ 164.528(b)(4)(i)(F)", + "§ 164.528(b)(4)(ii)", + "§ 164.528(c)(1)", + "§ 164.528(c)(1)(i)", + "§ 164.528(c)(1)(ii)", + "§ 164.528(c)(1)(ii)(A)", + "§ 164.528(c)(1)(ii)(B)", + "§ 164.528(c)(2)", + "§ 164.528(d)", + "§ 164.528(d)(1)", + "§ 164.528(d)(2)", + "§ 164.528(d)(3)" ], "usa-federal-irs-1075-2021": [ "PM-21" @@ -192,28 +190,34 @@ "Section 3(1)(a)(B)(i)", "Section 3(1)(a)(B)(ii)" ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-deu-fdpa-2017": [ + "3.3.57(1)4", + "3.5.79(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.15(2)" ], - "emea-srb-act-9-2018": [ - "33" + "emea-nga-dpr-2019": [ + "3.1(8)" ], - "emea-zaf-popia-2013": [ - "17" + "apac-chn-pipl-2021": [ + "Article 22", + "Article 23" ], "apac-ind-dpdpa-2023": [ "11(1)(b)" ], - "apac-jpn-ppi-2020": [ - "25(1)", - "25(2)" + "apac-jpn-appi-2020": [ + "IV.1.25(1)", + "IV.1.25(2)", + "IV.1.26(3)", + "IV.1.26(4)" ], - "apac-phl-dpa-2012": [ - "20" + "americas-bhs-dpa-2003": [ + "V.43(4)(c)" ], - "americas-bra-lgpd-2018": [ - "18.7", - "37" + "americas-can-pipeda-2000": [ + "P9-4.9.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-14.2.json b/docs/api/controls/PRI-14.2.json index 9f35e055..68d0c31c 100644 --- a/docs/api/controls/PRI-14.2.json +++ b/docs/api/controls/PRI-14.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of applicable legal requests to disclose Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60,26 +60,32 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-csa-cmm-4-1-0": [ "DSP-18" ], - "general-scf-dpmp-2025": [ - "4.0", - "4.1" - ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-nga-dpr-2019": [ + "3.1(8)" ], "emea-sau-pdpl-2023": [ "Article 24.2" ], "emea-srb-act-9-2018": [ - "33", - "35" + "III.3.33" + ], + "apac-aus-privacy-principles-2026": [ + "3.6.5" + ], + "americas-bhs-dpa-2003": [ + "V.46(3)", + "V.46(3)(a)", + "V.46(3)(b)", + "V.46(3)(c)", + "V.46(3)(d)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-14.json b/docs/api/controls/PRI-14.json index 97802ecf..b7160520 100644 --- a/docs/api/controls/PRI-14.json +++ b/docs/api/controls/PRI-14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to document Personal Data (PD) processing activities that covers collection, receiving, processing, storage, transmission, sharing, updating and/or disposal actions with sufficient detail to demonstrate conformity with applicable statutory, regulatory and contractual requirements.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101,7 +101,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -151,10 +152,6 @@ "general-nist-800-161-r1-level-3": [ "PM-27" ], - "general-scf-dpmp-2025": [ - "5.8", - "11.5" - ], "general-shared-assessments-sig-2025": [ "L.1" ], @@ -162,6 +159,19 @@ "AR-6", "DM-2(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.535.3", + "603A.535.3(a)", + "603A.535.3(b)", + "603A.535.3(c)", + "603A.535.3(d)", + "603A.535.3(e)", + "603A.535.3(f)", + "603A.535.3(g)", + "603A.535.3(h)", + "603A.535.3(i)", + "603A.535.8" + ], "usa-state-tx-cdpa-2025": [ "541.052(f)(1)" ], @@ -184,8 +194,67 @@ "Article 30.2(d)", "Article 30.3" ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-aut-dpa-2018": [ + "§ 13(2)", + "§ 49(1)", + "§ 49(2)", + "§ 49(3)", + "§ 50(1)", + "§ 50(2)", + "§ 50(3)", + "§ 50(5)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(3)", + "Title 2, Chapter III, Art. 45(5)", + "Title 2, Chapter IV, Section 4, Art. 55(1)", + "Title 2, Chapter IV, Section 4, Art. 55(2)", + "Title 2, Chapter IV, Section 4, Art. 55(3)", + "Title 2, Chapter IV, Section 4, Art. 56(1)", + "Title 2, Chapter IV, Section 4, Art. 56(2)", + "Title 2, Chapter IV, Section 4, Art. 56(3)", + "Title 2, Chapter IV, Section 4, Art. 57", + "Title 2, Chapter IV, Section 4, Art. 58" + ], + "emea-deu-fdpa-2017": [ + "3.4.70(1)", + "3.4.70(1)1", + "3.4.70(1)2", + "3.4.70(1)3", + "3.4.70(1)4", + "3.4.70(1)5", + "3.4.70(1)6", + "3.4.70(1)7", + "3.4.70(1)8", + "3.4.70(1)9", + "3.4.70(2)1", + "3.4.70(2)2", + "3.4.70(2)3", + "3.4.70(4)", + "3.4.76(1)", + "3.4.76(1)1", + "3.4.76(1)2", + "3.4.76(1)3", + "3.4.76(1)4", + "3.4.76(1)5", + "3.4.76(1)6", + "3.4.76(2)", + "3.4.76(3)", + "3.4.76(4)", + "3.5.79(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.15(2)" + ], + "emea-irl-dpa-2018": [ + "s.81", + "s.82" + ], + "emea-ita-pdpc-2018": [ + "Article 110(2)" + ], + "emea-nga-dpr-2019": [ + "3.1(8)" ], "emea-sau-pdpl-2023": [ "Article 31", @@ -197,17 +266,136 @@ "Article 31.6" ], "emea-srb-act-9-2018": [ - "47", - "47.x", - "48", - "52", - "52.1", - "52.2", - "52.3", - "52.4" + "II.15", + "IV.1.47-2", + "IV.1.47-2(1)", + "IV.1.47-2(2)", + "IV.1.47-2(3)", + "IV.1.47-2(4)", + "IV.1.47-2(5)", + "IV.1.47-2(6)", + "IV.1.47-2(7)", + "IV.1.47-2(8)", + "IV.1.47-2(9)", + "IV.1.47-3", + "IV.1.47-3(1)", + "IV.1.47-3(2)", + "IV.1.47-3(3)", + "IV.1.47-3(4)", + "IV.1.47-4", + "IV.1.47-4(1)", + "IV.1.47-4(2)", + "IV.1.47-4(3)", + "IV.1.47-4(4)" + ], + "emea-che-fadp-2025": [ + "2.1.12.1", + "2.1.12.2", + "2.1.12.2.a", + "2.1.12.2.b", + "2.1.12.2.c", + "2.1.12.2.d", + "2.1.12.2.e", + "2.1.12.2.f", + "2.1.12.2.g", + "2.1.12.3", + "2.2.15.1" + ], + "emea-gbr-dpa-2018": [ + "Section 61(1)", + "Section 61(2)", + "Section 61(2)(a)", + "Section 61(2)(b)", + "Section 61(2)(c)", + "Section 61(2)(d)", + "Section 61(2)(e)", + "Section 61(2)(f)", + "Section 61(2)(f)(i)", + "Section 61(2)(f)(ii)", + "Section 61(2)(g)", + "Section 61(2)(h)", + "Section 61(2)(h)(i)", + "Section 61(2)(j)", + "Section 61(2)(k)", + "Section 61(3)", + "Section 61(4)", + "Section 61(4)(a)", + "Section 61(4)(b)", + "Section 61(4)(c)", + "Section 61(4)(d)", + "Section 61(4)(e)", + "Section 61(4)(f)", + "Section 61(5)", + "Section 62(1)", + "Section 62(1)(a)", + "Section 62(1)(b)", + "Section 62(1)(c)", + "Section 62(1)(d)", + "Section 62(1)(e)", + "Section 62(1)(f)", + "Section 62(2)", + "Section 62(2)(a)", + "Section 62(2)(b)", + "Section 62(3)", + "Section 62(3)(a)", + "Section 62(3)(b)", + "Section 62(3)(b)(i)", + "Section 62(3)(b)(ii)", + "Section 62(4)", + "Section 62(4)(a)", + "Section 62(4)(b)", + "Section 62(4)(c)", + "Section 62(4)(d)", + "Section 62(5)" + ], + "apac-hkg-pdo-2022": [ + "27(1)", + "27(1)(a)", + "27(1)(b)", + "27(1)(c)", + "27(1)(c)(i)", + "27(1)(c)(ii)", + "27(2)", + "27(2)(a)", + "27(2)(b)", + "27(2)(c)", + "27(2)(d)", + "27(3)", + "27(3)(a)", + "27(3)(b)", + "27(3)(c)", + "27(3)(d)", + "27(4)", + "27(4)(a)", + "27(4)(b)" + ], + "apac-mys-pdpa-2010": [ + "44(1)" + ], + "americas-bhs-dpa-2003": [ + "V.43(1)", + "V.43(2)", + "V.43(2)(a)", + "V.43(2)(b)", + "V.43(2)(c)", + "V.43(2)(d)", + "V.43(2)(e)", + "V.43(2)(f)", + "V.43(2)(g)", + "V.43(2)(h)", + "V.43(2)(i)", + "V.43(2)(j)", + "V.43(3)", + "V.43(4)", + "V.43(4)(a)", + "V.43(4)(b)", + "V.43(4)(c)" ], "americas-bra-lgpd-2018": [ - "38" + "VI.I.37" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-15.json b/docs/api/controls/PRI-15.json index 2c1a29bf..6f051f04 100644 --- a/docs/api/controls/PRI-15.json +++ b/docs/api/controls/PRI-15.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to register as a data controller and/or data processor, including registering databases containing Personal Data (PD) with the appropriate Data Authority, when necessary.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -64,115 +64,74 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.3" - ], "general-tisax-6-0-3": [ "9.3.1" ], "usa-state-vt-act-171-2018": [ "2446(a)(1)" ], - "emea-aut-fappd-2000": [ - "Sec 16", - "Sec 17" - ], - "emea-bel-act-8-1992": [ - "17" - ], - "emea-deu-fdpa-2017": [ - "Sec 4d", - "Sec 4e" - ], "emea-grc-pirppd-1997": [ - "6" - ], - "emea-hun-isdfi-2011": [ - "65", - "66" - ], - "emea-irl-dpa-2003": [ - "17" - ], - "emea-isr-ppl-5741-1981": [ - "8", - "9" - ], - "emea-ita-pdpc-2003": [ - "26", - "37" - ], - "emea-ken-pda-2019": [ - "18(1)", - "18(2)", - "18(2)(a)", - "18(2)(b)", - "18(2)(c)", - "18(2)(d)", - "19(1)", - "19(2)", - "19(2)(a)", - "19(2)(b)", - "19(2)(c)", - "19(2)(d)", - "19(2)(e)", - "19(2)(f)", - "19(2)(g)", - "19(3)", - "19(4)", - "19(5)", - "19(6)", - "19(7)", - "20" - ], - "emea-nor-pda-2018": [ - "33" - ], - "emea-pol-act-29-1997": [ - "40" - ], - "emea-rus-federal-law-27-2006": [ - "23" - ], - "emea-esp-decree-1720-2007": [ - "60" - ], - "emea-che-fadp-2025": [ - "11" + "B.6.1", + "B.6.2", + "B.6.2.a", + "B.6.2.b", + "B.6.2.c", + "B.6.2.d", + "B.6.2.e", + "B.6.2.f", + "B.6.2.g", + "B.6.2.h", + "B.6.3", + "B.6.4" + ], + "emea-isr-ppl-5741-2025": [ + "s.8", + "s.8A", + "s.9", + "s.10" + ], + "emea-nga-dpr-2019": [ + "4.1(4)" + ], + "emea-rus-152-fz-2025": [ + "Art. 22" ], "emea-tur-lppd-2016": [ - "16" - ], - "apac-hkg-pdo-2022": [ - "Sec 15" - ], - "apac-mys-pdpa-2010": [ - "14", - "15" - ], - "apac-phl-dpa-2012": [ - "46", - "47", - "48" - ], - "apac-sgp-pdpa-2012": [ - "39" - ], - "apac-kor-pipa-2011": [ - "32" - ], - "americas-arg-ppd-2018": [ - "21.1", - "21.2", - "21.3", - "24" - ], - "americas-col-law-1581-2012": [ - "25" + "16(1)", + "16(2)", + "16(3)", + "16(3)(a)", + "16(3)(b)", + "16(3)(c)", + "16(3)(ç)", + "16(3)(d)", + "16(3)(e)", + "16(3)(f)", + "16(4)", + "16(5)" + ], + "americas-bhs-dpa-2003": [ + "V.41(1)", + "V.41(1)(a)", + "V.41(1)(b)", + "V.41(1)(c)", + "V.41(1)(d)", + "V.41(1)(e)", + "V.41(1)(f)", + "V.41(1)(g)", + "V.41(2)", + "V.41(3)" + ], + "americas-chl-act-19628-1999": [ + "I.5", + "I.5(a)", + "I.5(b)", + "I.5(c)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-16.json b/docs/api/controls/PRI-16.json index a16ff513..86d94300 100644 --- a/docs/api/controls/PRI-16.json +++ b/docs/api/controls/PRI-16.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to constrain the supply of physical and/or digital activity logs to the host government that can directly lead to contravention of the Universal Declaration of Human Rights (UDHR), as well as other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,7 +61,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -72,34 +73,14 @@ "Article 24" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "Article 27", + "Article 33" + ], + "apac-chn-csnip-2012": [ + "VI" ], "apac-chn-pipl-2021": [ - "11", - "12", - "18", - "26", - "38(4)", - "40", - "47(5)" + "Article 38" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-17.1.json b/docs/api/controls/PRI-17.1.json index ed84537a..4680e807 100644 --- a/docs/api/controls/PRI-17.1.json +++ b/docs/api/controls/PRI-17.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a conspicuous link to the organization's data privacy notice on all consumer-facing websites and mobile applications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,13 +73,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.9" - ], "usa-state-ca-ccpa-cpra-2026": [ "7003(c)", "7003(d)" diff --git a/docs/api/controls/PRI-17.2.json b/docs/api/controls/PRI-17.2.json index 7447d794..dcb4991f 100644 --- a/docs/api/controls/PRI-17.2.json +++ b/docs/api/controls/PRI-17.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with a Notice of Financial Incentive that explains the material terms of a financial incentive, price or service difference so the data subject can make an informed decision about whether to participate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,13 +73,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7010(g)", "7080(e)" diff --git a/docs/api/controls/PRI-17.3.json b/docs/api/controls/PRI-17.3.json index b639ff00..ac7ca657 100644 --- a/docs/api/controls/PRI-17.3.json +++ b/docs/api/controls/PRI-17.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain records of data subject requests and responses in accordance with an established documentation retention schedule that adheres to applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -86,6 +87,23 @@ ], "usa-state-va-cdpa-2023": [ "59.1-577.B.5" + ], + "emea-deu-fdpa-2017": [ + "3.3.57(8)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(7)(a)", + "Section 44(7)(b)", + "Section 45(7)(a)", + "Section 45(7)(b)" + ], + "apac-mys-pdpa-2010": [ + "37(2)", + "37(2)(a)", + "37(2)(a)(i)", + "37(2)(a)(ii)", + "37(2)(b)", + "37(3)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-17.4.json b/docs/api/controls/PRI-17.4.json index 5f41423e..e8b9a8db 100644 --- a/docs/api/controls/PRI-17.4.json +++ b/docs/api/controls/PRI-17.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to collect metrics associated with data subject requests and responses.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-17.5.json b/docs/api/controls/PRI-17.5.json index 3b59413d..3578f3f5 100644 --- a/docs/api/controls/PRI-17.5.json +++ b/docs/api/controls/PRI-17.5.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publicly disclose applicable data subject communications metrics, as required by statutory and/or regulatory obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-17.json b/docs/api/controls/PRI-17.json index dfb1ebc7..09b295e2 100644 --- a/docs/api/controls/PRI-17.json +++ b/docs/api/controls/PRI-17.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Communications with data subjects is designed to be readily accessible and written in a manner that is concise, unambiguous and understandable by a reasonable person.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to craft disclosures and communications to data subjects in a manner that is concise, unambiguous and understandable by a reasonable person.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -60,16 +60,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ "P6.7-POF3" ], - "general-scf-dpmp-2025": [ - "1.8" - ], "usa-state-ca-ccpa-cpra-2026": [ "7003(a)", "7004(a)(3)", @@ -100,6 +98,86 @@ ], "usa-state-va-cdpa-2023": [ "59.1-577.B.2" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter III, Art. 36(1)" + ], + "emea-deu-fdpa-2017": [ + "2.2.33(2)", + "2.2.34(2)", + "3.3.57(6)", + "3.3.57(8)", + "3.3.58(6)", + "3.3.59(1)", + "3.3.59(2)", + "3.4.74(2)" + ], + "emea-grc-pirppd-1997": [ + "C.11.3" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(2)", + "II.13.18(2)" + ], + "emea-ken-pda-2019": [ + "IV.34(2)(b)", + "IV.35(3)(a)" + ], + "emea-nga-dpr-2019": [ + "3.1(2)", + "3.1(6)" + ], + "emea-qat-pdppl-2020": [ + "2.6.2", + "3.11.4" + ], + "emea-srb-act-9-2018": [ + "III.3.34" + ], + "emea-zaf-popia-2013": [ + "3.A.3.14(8)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(5)", + "Section 44(5)(a)", + "Section 44(5)(b)", + "Section 44(5)(c)", + "Section 44(5)(d)", + "Section 44(5)(e)", + "Section 44(6)" + ], + "apac-aus-privacy-principles-2026": [ + "5.12.9", + "5.12.9.a", + "5.12.9.b", + "5.12.9.c", + "5.12.10" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.46(2)(a)", + "4.1.46(2)(b)", + "4.1.46(3)(a)", + "4.1.46(3)(b)" + ], + "apac-kor-pipa-2011": [ + "III.2.27(1)", + "III.2.27(1)1", + "III.2.27(1)2", + "III.2.27(1)3", + "III.2.27(2)", + "III.2.27(3)" + ], + "americas-bhs-dpa-2003": [ + "IV.24(2)", + "IV.24(2)(a)", + "IV.24(2)(b)", + "IV.36(4)", + "IV.36(4)(a)", + "IV.36(4)(b)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-18.json b/docs/api/controls/PRI-18.json index a0e76530..63bf631d 100644 --- a/docs/api/controls/PRI-18.json +++ b/docs/api/controls/PRI-18.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to receive and process data controller communications pertaining to:\n(1) Receiving and responding to data subject requests;\n(2) Updating/correcting Personal Data (PD); \n(3) Accounting for disclosures of PD; and\n(4) Accounting for PD that is stored, processed and/or transmitted on behalf of the data controller.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -98,6 +99,25 @@ "usa-state-tx-cdpa-2025": [ "541.053(a)", "541.055(a)(1)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 38(4)" + ], + "emea-zaf-popia-2013": [ + "3.A.3.14(8)" + ], + "apac-jpn-appi-2020": [ + "IV.1.32(1)", + "IV.1.32(2)", + "IV.1.32(3)", + "IV.1.32(4)" + ], + "apac-sgp-pdpa-2012": [ + "5.22(5)", + "5.22(6)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-19.1.json b/docs/api/controls/PRI-19.1.json index d467329e..2a67cabe 100644 --- a/docs/api/controls/PRI-19.1.json +++ b/docs/api/controls/PRI-19.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of their rights through a pre-use notice when their Personal Data (PD) will be processed by an Automated Decision-Making Technology (ADMT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -103,6 +104,12 @@ "7220(e)(2)", "7220(e)(3)", "7220(e)(4)" + ], + "emea-ken-pda-2019": [ + "IV.35(3)(a)" + ], + "emea-zaf-popia-2013": [ + "8.71(3)(b)" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-19.2.json b/docs/api/controls/PRI-19.2.json index c48c6280..3db85eb8 100644 --- a/docs/api/controls/PRI-19.2.json +++ b/docs/api/controls/PRI-19.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide concise, unambiguous and understandable instructions on how data subjects can opt-out of Automated Decision-Making Technology (ADMT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -103,6 +104,21 @@ "7221(n)", "7221(n)(1)", "7221(n)(2)" + ], + "emea-ken-pda-2019": [ + "IV.35(1)" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-srb-act-9-2018": [ + "III.4.38" + ], + "emea-zaf-popia-2013": [ + "8.71(3)(a)" + ], + "emea-che-fadp-2025": [ + "3.21.3.b" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-19.3.json b/docs/api/controls/PRI-19.3.json index b72c2a09..32dab12f 100644 --- a/docs/api/controls/PRI-19.3.json +++ b/docs/api/controls/PRI-19.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with sufficient details of the logic and parameters used by Automated Decision-Making Technology (ADMT) to process the Personal Data (PD) to generate an output with respect to the data subject.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,12 +76,35 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ "7222(a)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.d" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-che-fadp-2025": [ + "3.21.3.a" + ], + "apac-chn-pipl-2021": [ + "Article 24" + ], + "americas-bhs-dpa-2003": [ + "IV.24(3)(a)", + "IV.24(3)(b)", + "IV.24(3)(c)", + "IV.24(3)(d)" + ], + "americas-bra-lgpd-2018": [ + "III.20", + "III.20.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRI-19.json b/docs/api/controls/PRI-19.json index d4b384b2..67a73169 100644 --- a/docs/api/controls/PRI-19.json +++ b/docs/api/controls/PRI-19.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data subject actions utilizing Automated Decision-Making Technology (ADMT) where computation replaces, or substantially replaces, human decisionmaking, conforms with all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -76,8 +76,98 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": {} + "crosswalks": { + "emea-aut-dpa-2018": [ + "§ 41(1)", + "§ 41(2)", + "§ 41(3)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 35" + ], + "emea-deu-fdpa-2017": [ + "2.2.37(1)1", + "2.2.37(1)2", + "2.2.37(2)", + "3.2.54(1)", + "3.2.54(2)", + "3.2.54(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.10.11(2)" + ], + "emea-irl-dpa-2018": [ + "s.89" + ], + "emea-ken-pda-2019": [ + "IV.35(1)" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-srb-act-9-2018": [ + "III.4.39" + ], + "emea-zaf-popia-2013": [ + "8.71(1)", + "8.71(2)", + "8.71(2)(a)", + "8.71(2)(a)(i)", + "8.71(2)(a)(ii)", + "8.71(2)(b)", + "8.71(3)" + ], + "emea-che-fadp-2025": [ + "3.21.3.a" + ], + "emea-gbr-dpa-2018": [ + "Section 50(1)", + "Section 50(1)(a)", + "Section 50(1)(b)", + "Section 50(1)(b)(i)", + "Section 50(1)(b)(ii)", + "Section 50(2)", + "Section 50C(1)", + "Section 50C(1)(a)", + "Section 50C(1)(b)", + "Section 50C(2)", + "Section 50C(2)(a)", + "Section 50C(2)(b)", + "Section 50C(2)(c)", + "Section 50C(2)(d)", + "Section 50C(3)", + "Section 50C(3)(a)", + "Section 50C(3)(b)", + "Section 50C(3)(c)", + "Section 50C(4)", + "Section 50C(4)(a)", + "Section 50C(4)(b)", + "Section 50C(4)(c)", + "Section 50C(4)(d)", + "Section 50C(4)(e)", + "Section 50C(5)" + ], + "apac-chn-pipl-2021": [ + "Article 24" + ], + "americas-bhs-dpa-2003": [ + "IV.24(3)", + "V.49(1)", + "V.49(2)", + "V.49(2)(a)", + "V.49(2)(b)", + "V.49(2)(c)", + "V.49(3)", + "V.49(4)", + "V.49(4)(a)", + "V.49(4)(b)" + ], + "americas-bra-lgpd-2018": [ + "III.20" + ] + } } \ No newline at end of file diff --git a/docs/api/controls/PRI-20.json b/docs/api/controls/PRI-20.json index 870d873d..39f7e7d8 100644 --- a/docs/api/controls/PRI-20.json +++ b/docs/api/controls/PRI-20.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data brokers that collect Personal Data (PD) from a source other than directly from the data subject adhere to all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-21.1.json b/docs/api/controls/PRI-21.1.json index 308be388..d06c1cbb 100644 --- a/docs/api/controls/PRI-21.1.json +++ b/docs/api/controls/PRI-21.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish conspicuous links for data subjects to exercise their rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRI-21.2.json b/docs/api/controls/PRI-21.2.json index 0309438c..f6a34005 100644 --- a/docs/api/controls/PRI-21.2.json +++ b/docs/api/controls/PRI-21.2.json @@ -1,9 +1,9 @@ { "control_id": "PRI-21.2", - "title": "Alternative Out-Out Link", + "title": "Alternative Opt-Out Link", "family": "PRI", - "description": "Mechanisms exist to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", - "scf_question": "Does the organization publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD?", + "description": "Mechanisms exist to publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD.", + "scf_question": "Does the organization publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -18,7 +18,7 @@ "0": "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.", "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.\nMechanisms exist to publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75,8 +75,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ diff --git a/docs/api/controls/PRI-21.json b/docs/api/controls/PRI-21.json index ef5b1bf1..12a526fd 100644 --- a/docs/api/controls/PRI-21.json +++ b/docs/api/controls/PRI-21.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a notification to data subjects within the data privacy notice of:\n(1) Their right to direct an organization that sells or shares their Personal Data (PD) to stop selling or sharing their PD; and\n(2) The methods available to exercise that right.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a notification to data subjects within the data privacy notice of:\n(1) Their right to direct an organization that sells or shares their Personal Data (PD) to stop selling or sharing their PD; and\n(2) The methods available to exercise that right. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { diff --git a/docs/api/controls/PRM-01.1.json b/docs/api/controls/PRM-01.1.json index a042db99..64eef030 100644 --- a/docs/api/controls/PRM-01.1.json +++ b/docs/api/controls/PRM-01.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to establish a:\n(1) Strategic security, compliance and resilience-specific business plan; and \n(2) Set of objectives to achieve that plan.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,9 +82,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -147,10 +147,12 @@ "7102(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(4)", - "3.2.1(5)(a)", - "3.2.1(5)(b)", - "3.2.1(5)(c)" + "3.2.1.4", + "3.2.2.5", + "3.2.2.5(a)", + "3.2.2.5(b)", + "3.2.2.5(c)", + "3.2.2.6" ], "emea-eu-dora-2023": [ "Article 6.8", @@ -173,24 +175,40 @@ "1.2(e)", "1.2(f)" ], + "emea-deu-c5-2020": [ + "SA-02-DOAR" + ], + "emea-isr-cmo-2-0": [ + "2.A", + "4.1, Stage 4", + "4.2, Stage 1.2" + ], "emea-sau-cscc-1-2019": [ - "1-1", "1-1-1" ], "emea-sau-ecc-1-2018": [ "1-1-1", - "1-1-2" + "1-1-2", + "1-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.1.2" - ], - "apac-aus-ism-2024-june": [ + "3.1.2", + "3.1.2.1", + "3.1.2.2", + "3.1.2.2.a", + "3.1.2.2.b", + "3.1.2.2.c", + "3.1.2.3", + "3.1.2.3.a", + "3.1.2.3.b", + "3.1.2.3.c" + ], + "apac-aus-ism-2026-march": [ "ISM-0039", "ISM-0720" ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "apac-aus-ps-cps-230-2023": [ + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -198,21 +216,21 @@ "apac-jpn-ismap": [ "5.1.1.2" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], "apac-nzl-ism-3-9": [ "2.3.25.C.01", "2.3.25.C.02", "2.3.29.C.01" ], - "apac-sgp-mas-trm-2021": [ - "3.1.4", - "3.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.7" - ], "americas-can-osfi-b13-2022": [ "1.2.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRM-01.2.json b/docs/api/controls/PRM-01.2.json index 18b18eb8..b892fb53 100644 --- a/docs/api/controls/PRM-01.2.json +++ b/docs/api/controls/PRM-01.2.json @@ -79,7 +79,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -96,14 +97,20 @@ "general-iso-31000-2018": [ "5.4.4" ], - "apac-aus-ps-cps-234-2019": [ - "15" + "general-nist-cswp-39": [ + "6.5" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stages 2-3" + ], + "apac-aus-ps-cps-230-2023": [ + "27(b)" ], "apac-jpn-ismap": [ "4.4.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "apac-mys-bnm-rmit-2025": [ + "8.1" ], "americas-can-osfi-b13-2022": [ "1.2.1" diff --git a/docs/api/controls/PRM-01.json b/docs/api/controls/PRM-01.json index 0733cb7c..9b0b07b0 100644 --- a/docs/api/controls/PRM-01.json +++ b/docs/api/controls/PRM-01.json @@ -99,9 +99,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -227,12 +227,15 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-csf-2-0": [ "GV.RM", "GV.RR-03" ], - "general-scf-dpmp-2025": [ - "1.4" + "general-nist-cswp-39": [ + "6.1" ], "usa-federal-dow-cert-rmm-1-2": [ "EF:SG1.SP3", @@ -303,12 +306,10 @@ "PL-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(6)", - "3.6.1(61)", - "3.6.1(62)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -316,45 +317,39 @@ "Article 7(c)", "Article 7(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "2.3", "7.4", "7.5", "8.3" ], - "emea-isr-cmo-1-0": [ - "17.5" + "emea-isr-cmo-2-0": [ + "4.1, Stage 4" ], "emea-sau-cscc-1-2019": [ - "1-1" + "1-3-1", + "2-13-1" ], "emea-sau-ecc-1-2018": [ "1-1-3", "1-2-3" ], - "emea-zaf-popia-2013": [ - "19" + "emea-sau-otcc-1-2022": [ + "1-4-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.5.1" ], - "emea-esp-ccn-stic-825-2023": [ - "9" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0720", "ISM-0732" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "25", + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -362,22 +357,24 @@ "apac-jpn-ismap": [ "4.5.1.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], "apac-nzl-ism-3-9": [ "3.2.15.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.22" + "5.2.1", + "5.2.2" ], "americas-can-osfi-b13-2022": [ "1.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.3.1" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] diff --git a/docs/api/controls/PRM-02.1.json b/docs/api/controls/PRM-02.1.json index 6ef39954..15ace79a 100644 --- a/docs/api/controls/PRM-02.1.json +++ b/docs/api/controls/PRM-02.1.json @@ -3,7 +3,7 @@ "title": "Prioritization To Address Evolving Risks & Threats", "family": "PRM", "description": "Mechanisms exist to integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize the organization's exposure to evolving risks and threats.", - "scf_question": "Does the organization integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize the organization's exposure to evolving risks and threats?", + "scf_question": "Does the organization integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize its exposure to evolving risks and threats?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -75,7 +75,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -98,11 +99,46 @@ "4.3.2", "6.3" ], + "general-nist-cswp-39": [ + "6.1" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.6.1.62", + "3.6.1.66" + ], + "emea-deu-c5-2020": [ + "SA-02-BP3" + ], + "emea-isr-cmo-2-0": [ + "2.D", + "4.1, Stage 4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-4" + ], + "emea-sau-otcc-1-2022": [ + "1-4-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2020" + ], + "apac-aus-ps-cps-230-2023": [ + "25", + "27(b)" + ], "apac-jpn-ismap": [ "4.5.5.3" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRM-02.json b/docs/api/controls/PRM-02.json index 7cc535c1..ec646479 100644 --- a/docs/api/controls/PRM-02.json +++ b/docs/api/controls/PRM-02.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.\n▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to address all capital planning and investment requests, including the resources needed to implement the Security, Compliance & Resilience Program (SCRP) and document all exceptions to this requirement.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to address all capital planning and investment requests, including the resources needed to implement the Security, Compliance & Resilience Program (SCRP) and document all exceptions to this requirement. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,9 +82,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -184,8 +184,8 @@ "general-nist-csf-2-0": [ "GV.RR-03" ], - "general-scf-dpmp-2025": [ - "11.0" + "general-nist-cswp-39": [ + "6.1" ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:GG2.GP3", @@ -237,8 +237,9 @@ "PM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.1(61)", - "3.6.1(62)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -249,31 +250,18 @@ "emea-deu-bsrit-2017": [ "2.3" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.8", - "17.9" - ], - "emea-sau-cscc-1-2019": [ - "1-1" - ], "emea-sau-ecc-1-2018": [ "1-1-3" ], "emea-sau-otcc-1-2022": [ - "1-4", - "1-4-1", - "1-4-1-1" + "1-4-2" ], - "apac-aus-ism-2024-june": [ - "ISM-0732" + "apac-aus-ism-2026-march": [ + "ISM-0732", + "ISM-2004" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "27(b)" ], "apac-jpn-ismap": [ "4.5.1.1", @@ -283,18 +271,7 @@ "3.2.15.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.5.1", - "5.5.2" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.22" + "5.1.4" ], "americas-can-osfi-b13-2022": [ "1.2.1" diff --git a/docs/api/controls/PRM-03.json b/docs/api/controls/PRM-03.json index 1e2f0baf..4e431896 100644 --- a/docs/api/controls/PRM-03.json +++ b/docs/api/controls/PRM-03.json @@ -85,7 +85,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -221,10 +222,10 @@ "SA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-2" @@ -246,7 +247,7 @@ "Article 17.1(l)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)" + "3.2.1.3" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -257,23 +258,21 @@ "emea-deu-bsrit-2017": [ "2.3" ], - "emea-isr-cmo-1-0": [ - "17.5" + "emea-isr-cmo-2-0": [ + "4.1, Stage 4" ], - "emea-sau-cscc-1-2019": [ - "1-1" + "emea-sau-otcc-1-2022": [ + "1-4-2" ], - "emea-sau-ecc-1-2018": [ - "1-6-4" + "emea-sau-sama-csf-1-2017": [ + "3.1.1.10" ], - "apac-aus-ism-2024-june": [ - "ISM-0732" + "apac-aus-ism-2026-march": [ + "ISM-0732", + "ISM-2020" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "15" + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -283,11 +282,7 @@ "4.5.5.3" ], "apac-sgp-mas-trm-2021": [ - "5.2.1", - "5.2.2" - ], - "amaericas-can-osfi-self-assessment": [ - "6.22" + "5.1.4" ], "americas-can-osfi-b13-2022": [ "1.2.1" diff --git a/docs/api/controls/PRM-04.json b/docs/api/controls/PRM-04.json index 7413761a..223bc88b 100644 --- a/docs/api/controls/PRM-04.json +++ b/docs/api/controls/PRM-04.json @@ -2,8 +2,8 @@ "control_id": "PRM-04", "title": "Security, Compliance & Resilience In Project Management", "family": "PRM", - "description": "Mechanisms exist 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.", - "scf_question": "Does the organization 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?", + "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.", + "scf_question": "Does the organization 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?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -112,9 +112,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", + "errata": "- wordsmithed control", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -237,15 +238,18 @@ "general-nist-800-161-r1-level-3": [ "CA-2" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A06:2025" ], "general-pci-dss-4-0-1": [ "1.1" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-tisax-6-0-3": [ "1.2.3", "5.3.1" @@ -289,20 +293,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-02" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(14)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(f)", - "3.6.1(62)", - "3.6.1(61)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.3.1.10", + "3.3.1.13(f)", + "3.6.1.61", + "3.6.1.62", + "3.6.1.63", + "3.6.1.63(a)", + "3.6.1.63(b)", + "3.6.1.63(c)", + "3.6.1.63(d)", + "3.6.1.63(e)", + "3.6.1.63(f)", + "3.6.1.64", + "3.6.1.65", + "3.6.1.66", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -318,42 +327,53 @@ "7.2", "7.3" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.8", - "17.9" - ], "emea-sau-cscc-1-2019": [ - "1-3", - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-ecc-1-2018": [ - "1-6-1", - "1-6-4" + "1-5-2", + "1-6-1" ], "emea-sau-otcc-1-2022": [ - "1-4-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-74" + "1-4-1-1", + "1-4-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.1.5" - ], - "apac-aus-ism-2024-june": [ + "3.1.5", + "3.1.5.1", + "3.1.5.2", + "3.1.5.2.a", + "3.1.5.2.b", + "3.1.5.2.c", + "3.1.5.2.d", + "3.1.5.2.e", + "3.1.5.2.f" + ], + "emea-esp-decree-311-2022": [ + "Article 16(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1739" ], + "apac-aus-ps-cps-230-2023": [ + "25", + "27(b)" + ], "apac-jpn-ismap": [ "4.5.1.1", "6.1.5", "6.1.5.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.3", + "10.2", + "10.3", + "10.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP28", "HHSP31", @@ -366,29 +386,19 @@ ], "apac-sgp-mas-trm-2021": [ "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.8.1", - "5.8.2" - ], - "americas-bra-lgpd-2018": [ - "6.8" + "5.1.3" ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "americas-bmu-mba-coc-2020": [ + "5.14" ], "americas-can-osfi-b13-2022": [ "1.2.1", "2.3", "2.3.1", "2.4.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.3.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRM-05.json b/docs/api/controls/PRM-05.json index c9c6ed38..bf7aaeeb 100644 --- a/docs/api/controls/PRM-05.json +++ b/docs/api/controls/PRM-05.json @@ -2,8 +2,8 @@ "control_id": "PRM-05", "title": "Security, Compliance & Resilience Requirements Definition", "family": "PRM", - "description": "Mechanisms exist to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC).", - "scf_question": "Does the organization identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC)?", + "description": "Mechanisms exist to proactively govern Technology Assets, Applications and/or Services (TAAS) by:\n(1) Defining technical security, compliance and resilience requirements; and\n(2) Performing a criticality analysis at predefined decision points in the Secure Development Life Cycle (SDLC).", + "scf_question": "Does the organization proactively govern Technology Assets, Applications and/or Services (TAAS) by:\n(1) Defining technical security, compliance and resilience requirements; and\n(2) Performing a criticality analysis at predefined decision points in the Secure Development Life Cycle (SDLC)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -21,7 +21,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC). ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,9 +95,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", + "errata": "- wordsmithed control", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -232,6 +233,21 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], + "general-nist-800-172-r3": [ + "03.11.10E", + "03.13.01E", + "03.13.02E", + "03.13.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.10E", + "A.03.13.01E.ODP[01]", + "A.03.13.02E.ODP[01]", + "A.03.13.03E.ODP[01]" + ], "general-nist-800-218": [ "PO.1", "PO.1.1" @@ -242,9 +258,6 @@ "general-pci-dss-4-0-1": [ "1.1" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-swift-cscf-2025": [ "2.8", "2.11A" @@ -282,10 +295,10 @@ "RA-09" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7100(b)" @@ -294,10 +307,8 @@ "Article 14.3(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.6.1.64", + "3.6.2.68" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -311,47 +322,38 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(a)" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.6" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" + "emea-deu-bsrit-2017": [ + "7.6" ], "emea-sau-cscc-1-2019": [ - "1-3-1-2", "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-ecc-1-2018": [ - "1-6-1" + "1-6-1", + "2-9-1" ], "emea-sau-otcc-1-2022": [ - "1-4-1", - "1-4-1-1", - "1-4-2" + "1-4-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-43" + "emea-esp-decree-311-2022": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.3 [OP.PL.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.pl.3", + "op.exp.1", + "mp.info.4", + "mp.s.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0720", "ISM-1739" ], + "apac-aus-ps-cps-230-2023": [ + "25" + ], "apac-jpn-ismap": [ "4.4.3.1", "4.4.5.2", @@ -359,7 +361,11 @@ "6.1.5.2", "14.1.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.3", + "10.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP28", "HHSP31", @@ -377,22 +383,13 @@ "12.1.32.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", "5.1.2", - "5.1.3", - "5.1.4", - "5.3.3", - "5.5.1", - "5.5.2", - "5.6.1", - "5.6.2", - "5.6.3" + "5.4.2", + "5.4.3", + "5.5.1" ], - "apac-twn-pdpa-2025": [ - "27" - ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "americas-bmu-mba-coc-2020": [ + "5.14" ], "americas-can-osfi-b13-2022": [ "1.2.1", @@ -402,6 +399,9 @@ "2.4.3", "2.8" ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] diff --git a/docs/api/controls/PRM-06.json b/docs/api/controls/PRM-06.json index 59804243..fa91a873 100644 --- a/docs/api/controls/PRM-06.json +++ b/docs/api/controls/PRM-06.json @@ -80,9 +80,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -221,12 +221,15 @@ "general-nist-800-161-r1-level-3": [ "PM-11" ], + "general-nist-800-172-r3": [ + "03.13.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.01E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-swift-cscf-2025": [ "2.8", "2.11A" @@ -275,10 +278,10 @@ "609.935(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "PM-11", @@ -289,10 +292,9 @@ "PM-11" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.3.2.15", + "3.6.1.64", + "3.6.2.68" ], "emea-eu-dora-2023": [ "Article 8.1" @@ -300,14 +302,15 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(a)" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.6" + "emea-deu-bsrit-2017": [ + "7.6" + ], + "emea-sau-ecc-1-2018": [ + "2-9-1" ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" + "emea-esp-decree-311-2022": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], "apac-jpn-ismap": [ "4.4.3.1", @@ -317,6 +320,9 @@ "13.1.2", "14.1.1.2" ], + "apac-mys-bnm-rmit-2025": [ + "10.2" + ], "apac-nzl-hisf-suppliers-2023": [ "HSUP27" ], @@ -326,8 +332,11 @@ "12.1.32.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.5.1", - "5.5.2" + "5.1.2", + "5.5.1" + ], + "americas-bmu-mba-coc-2020": [ + "6.9" ], "americas-can-osfi-b13-2022": [ "1.2.1", @@ -336,6 +345,9 @@ "2.4.1", "2.4.3", "2.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRM-07.json b/docs/api/controls/PRM-07.json index 57823ec8..113ea716 100644 --- a/docs/api/controls/PRM-07.json +++ b/docs/api/controls/PRM-07.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -115,7 +115,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -203,7 +204,7 @@ "A.6.2.7", "A.6.2.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -284,9 +285,6 @@ "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-tisax-6-0-3": [ "5.3.1" ], @@ -359,15 +357,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-03" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(14)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(f)", - "3.5(55)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)" + "3.3.1.13(f)", + "3.5.55" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -383,39 +378,35 @@ "7.2", "7.3" ], - "emea-isr-cmo-1-0": [ - "17.4", - "17.5", - "17.8" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" - ], "emea-sau-cscc-1-2019": [ - "2-13-4" + "2-13-1" ], "emea-sau-cgiot-2024": [ "1-5-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-74" + "emea-sau-ecc-1-2018": [ + "1-5-3-1", + "1-5-3-2", + "1-5-3-3", + "1-5-3-4" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 8 (end)", - "Article 36" + "emea-sau-sama-csf-1-2017": [ + "3.1.5" ], - "emea-esp-decree-311-2022": [ - "36", - "8 (end)" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "op.exp.5", + "mp.sw.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1526", "ISM-1739" ], - "apac-aus-ps-cps-234-2019": [ - "21(c)" + "apac-aus-ps-cps-230-2023": [ + "25" ], "apac-ind-sebi-2024": [ "PR.IP.S2" @@ -424,19 +415,26 @@ "6.1.5.4", "14.1" ], + "apac-mys-bnm-rmit-2025": [ + "10.5" + ], "apac-sgp-mas-trm-2021": [ "5.1.2", - "5.1.3", - "5.1.4", "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4" + "5.4.4", + "5.5.2", + "5.8.1" + ], + "americas-bmu-mba-coc-2020": [ + "6.20" ], "americas-can-osfi-b13-2022": [ "2.4", "2.4.1", "2.4.3" + ], + "americas-can-osfi-self-assessment-2": [ + "2.4.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/PRM-08.json b/docs/api/controls/PRM-08.json index 24f98e77..0fc725c5 100644 --- a/docs/api/controls/PRM-08.json +++ b/docs/api/controls/PRM-08.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to manage the organizational knowledge of the security, compliance and resilience staff.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to manage the organizational knowledge of the security, compliance and resilience staff.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92,17 +92,14 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-cobit-2019": [ "APO01.08" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "usa-federal-dhs-cisa-cpg-2-0": [ "1.D" ], diff --git a/docs/api/controls/QTS-01.1.json b/docs/api/controls/QTS-01.1.json new file mode 100644 index 00000000..e8747a0b --- /dev/null +++ b/docs/api/controls/QTS-01.1.json @@ -0,0 +1,97 @@ +{ + "control_id": "QTS-01.1", + "title": "Quantum Security Policy", + "family": "QTS", + "description": "Mechanisms exist to establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "scf_question": "Does the organization establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-GOV-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Reference NIST PQC standards in cryptography policy\n∙ Note: Standalone quantum security policy may not be required at this size", + "small": "∙ Addendum to existing cryptography policy covering quantum risks\n∙ NIST PQC reference (https://csrc.nist.gov/pqc)", + "medium": "∙ Formal quantum security policy\n∙ Annual review cycle aligned to NIST PQC updates\n∙ Integration with cryptography standard", + "large": "∙ Standalone quantum security policy with executive approval\n∙ Annual review and update cycle\n∙ Alignment to NIST PQC, NSA CNSA 2.0 and CISA PQC guidance", + "enterprise": "∙ Enterprise quantum security policy with board endorsement\n∙ Alignment to NIST, NSA, CISA, and applicable regulatory guidance\n∙ Integration with security policy framework" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-01.2.json b/docs/api/controls/QTS-01.2.json new file mode 100644 index 00000000..660fc824 --- /dev/null +++ b/docs/api/controls/QTS-01.2.json @@ -0,0 +1,96 @@ +{ + "control_id": "QTS-01.2", + "title": "Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization", + "family": "QTS", + "description": "Mechanisms exist to classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "scf_question": "Does the organization classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-03" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Identify data with long-term confidentiality requirements (e.g., legal, financial, health records)\n∙ Flag for priority PQC protection", + "medium": "∙ Data classification extended to include confidentiality shelf-life dimension\n∙ Prioritize PQC migration for long-lived sensitive data", + "large": "∙ Formal data shelf-life classification taxonomy\n∙ Integration with data catalog and PQC migration prioritization\n∙ Policy-driven PQC protection for long-lived data", + "enterprise": "∙ Automated data shelf-life classification\n∙ Integration with enterprise data catalog and PQC migration roadmap\n∙ Continuous monitoring of long-lived data for PQC readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-01.3.json b/docs/api/controls/QTS-01.3.json new file mode 100644 index 00000000..de46814f --- /dev/null +++ b/docs/api/controls/QTS-01.3.json @@ -0,0 +1,96 @@ +{ + "control_id": "QTS-01.3", + "title": "Long-Lived Data Identification", + "family": "QTS", + "description": "Mechanisms exist to identify data with long-lived confidentiality protection requirements.", + "scf_question": "Does the organization identify data with long-lived confidentiality protection requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-03" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to identify data with long-lived confidentiality protection requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Review data retention schedules to identify long-lived sensitive records", + "medium": "∙ Data discovery tools to identify long-lived sensitive data\n∙ Data retention policy integration\n∙ Tag long-lived data in data catalog", + "large": "∙ Automated long-lived data identification via data discovery tools\n∙ Integration with DLP and data catalog\n∙ PQC priority mapping for identified data", + "enterprise": "∙ Enterprise data discovery and classification platform\n∙ Automated long-lived data tagging and PQC risk mapping\n∙ Continuous monitoring of data with long confidentiality requirements" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-01.4.json b/docs/api/controls/QTS-01.4.json new file mode 100644 index 00000000..a8c1d905 --- /dev/null +++ b/docs/api/controls/QTS-01.4.json @@ -0,0 +1,97 @@ +{ + "control_id": "QTS-01.4", + "title": "Harvest Now, Decrypt Later (HNDL) Mitigation", + "family": "QTS", + "description": "Mechanisms exist to mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control.", + "scf_question": "Does the organization mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-09" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Ensure TLS 1.3 is enforced for sensitive data in transit\n∙ Note: Full HNDL mitigation via ZTNA is typically not feasible at this size", + "small": "∙ Enforce TLS 1.3 for all sensitive communications\n∙ Minimize external exposure of long-lived sensitive data", + "medium": "∙ TLS 1.3 enforcement across all external-facing services\n∙ Data access minimization practices\n∙ Zero Trust Network Architecture (ZTNA) planning", + "large": "∙ Zero Trust Network Architecture (ZTNA) implementation\n∙ TLS 1.3 enforcement with forward secrecy\n∙ Identity-based access controls for sensitive data\n∙ Data microsegmentation", + "enterprise": "∙ Enterprise ZTNA platform (e.g., Zscaler, Netskope, Palo Alto Prisma Access)\n∙ Continuous authentication enforcement\n∙ Data microsegmentation with identity-aware access\n∙ HNDL risk monitoring and response program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-01.json b/docs/api/controls/QTS-01.json new file mode 100644 index 00000000..742656c1 --- /dev/null +++ b/docs/api/controls/QTS-01.json @@ -0,0 +1,98 @@ +{ + "control_id": "QTS-01", + "title": "Quantum Risk Governance", + "family": "QTS", + "description": "Mechanisms exist to establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "scf_question": "Does the organization establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-01", + "E-QTS-02" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Awareness of NIST PQC standards (https://csrc.nist.gov/pqc)\n∙ Note: Formal quantum risk governance may not be cost-effective at this size; monitor NIST guidance", + "small": "∙ Designate a named lead responsible for tracking PQC developments\n∙ NIST Post-Quantum Cryptography standards awareness (https://csrc.nist.gov/pqc)", + "medium": "∙ Designated quantum migration lead within CISO function\n∙ NIST PQC standards alignment\n∙ Include quantum risk in enterprise risk register", + "large": "∙ Executive-sponsored quantum risk governance structure\n∙ Named migration lead with defined authority\n∙ NIST PQC and NSA CNSA 2.0 alignment\n∙ Quantum risk as standing agenda item in executive meetings", + "enterprise": "∙ Board-level quantum risk governance structure\n∙ NIST PQC standards and NSA CNSA 2.0 alignment\n∙ Dedicated PQC migration program team\n∙ Quantum risk integrated into enterprise risk management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-02.1.json b/docs/api/controls/QTS-02.1.json new file mode 100644 index 00000000..c570b609 --- /dev/null +++ b/docs/api/controls/QTS-02.1.json @@ -0,0 +1,96 @@ +{ + "control_id": "QTS-02.1", + "title": "Cryptographic Exception Register", + "family": "QTS", + "description": "Mechanisms exist to govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date.", + "scf_question": "Does the organization govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-07" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Simple exception register for known quantum-vulnerable algorithm uses", + "medium": "∙ Cryptographic exception register with owner, compensating controls, and remediation dates\n∙ Integration with risk register", + "large": "∙ Formal cryptographic exception register\n∙ GRC platform integration\n∙ Regular review and escalation process for aged exceptions", + "enterprise": "∙ Enterprise cryptographic exception register within GRC platform\n∙ Automated exception tracking and escalation\n∙ Integration with PQC migration roadmap and compliance reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-02.2.json b/docs/api/controls/QTS-02.2.json new file mode 100644 index 00000000..85a22851 --- /dev/null +++ b/docs/api/controls/QTS-02.2.json @@ -0,0 +1,97 @@ +{ + "control_id": "QTS-02.2", + "title": "Compensating Controls for Quantum-Vulnerable Systems", + "family": "QTS", + "description": "Mechanisms exist to implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "scf_question": "Does the organization implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Network isolation of legacy systems using quantum-vulnerable algorithms\n∙ Shorten certificate validity periods", + "small": "∙ Network segmentation of quantum-vulnerable systems\n∙ Reduce key lifetimes for quantum-vulnerable certificates", + "medium": "∙ Network segmentation and additional authentication for quantum-vulnerable systems\n∙ Shortened key validity periods\n∙ Out-of-band key transport where applicable", + "large": "∙ Network micro-segmentation of quantum-vulnerable systems\n∙ Shortened key lifetimes and certificate validity periods\n∙ Pre-shared key (PSK) layers on quantum-vulnerable links\n∙ Data minimization on quantum-vulnerable paths", + "enterprise": "∙ Automated micro-segmentation of quantum-vulnerable systems\n∙ Enterprise PSK and data minimization controls\n∙ Continuous monitoring of quantum-vulnerable system exposure\n∙ Integration with PQC migration prioritization" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-02.3.json b/docs/api/controls/QTS-02.3.json new file mode 100644 index 00000000..1fbfa238 --- /dev/null +++ b/docs/api/controls/QTS-02.3.json @@ -0,0 +1,98 @@ +{ + "control_id": "QTS-02.3", + "title": "Crypto Agility Maturity Assessment", + "family": "QTS", + "description": "Mechanisms exist to measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "scf_question": "Does the organization measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Self-assessment against basic cryptographic agility criteria\n∙ NIST PQC readiness checklist", + "medium": "∙ Crypto agility maturity assessment against defined criteria\n∙ NIST or CISA PQC maturity model\n∙ Integration with annual security assessments", + "large": "∙ Formal crypto agility maturity assessment using NIST or CISA PQC maturity framework\n∙ Annual assessment with improvement roadmap", + "enterprise": "∙ Enterprise crypto agility maturity program\n∙ Third-party validated maturity assessments\n∙ Continuous maturity monitoring via GRC platform\n∙ Board-level reporting on crypto agility progress" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "6.5" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-02.json b/docs/api/controls/QTS-02.json new file mode 100644 index 00000000..6d874ab5 --- /dev/null +++ b/docs/api/controls/QTS-02.json @@ -0,0 +1,100 @@ +{ + "control_id": "QTS-02", + "title": "Cryptographic Agility Risk Assessment (CARA)", + "family": "QTS", + "description": "Mechanisms exist to perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact.", + "scf_question": "Does the organization perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-06" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Inventory of cryptographic algorithms in use\n∙ Identification of quantum-vulnerable algorithms (RSA, ECDSA, DH)", + "medium": "∙ Structured CARA aligned to NIST guidance\n∙ Asset-level mapping of cryptographic algorithm use\n∙ Prioritization by business impact", + "large": "∙ Formal CARA process aligned to NIST IR 8547 or equivalent methodology\n∙ Integration with risk register and PQC migration planning", + "enterprise": "∙ Enterprise CARA program with automated cryptographic discovery\n∙ NIST IR 8547 methodology implementation\n∙ Integration with GRC platform and PQC migration roadmap" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "5" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-03.1.json b/docs/api/controls/QTS-03.1.json new file mode 100644 index 00000000..35844f91 --- /dev/null +++ b/docs/api/controls/QTS-03.1.json @@ -0,0 +1,97 @@ +{ + "control_id": "QTS-03.1", + "title": "Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support", + "family": "QTS", + "description": "Mechanisms exist to allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period.", + "scf_question": "Does the organization allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-11", + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor TLS library vendor support for PQC/hybrid modes\n∙ Plan transition for highest-risk systems first", + "medium": "∙ PQC algorithm support assessment for key systems\n∙ Hybrid cryptography pilot for critical services\n∙ Vendor roadmap review for PQC support", + "large": "∙ Hybrid cryptography deployment for critical services\n∙ TLS 1.3 with hybrid PQC key exchange pilot\n∙ Legacy system migration planning and resource allocation", + "enterprise": "∙ Enterprise hybrid cryptography deployment program\n∙ FIPS 140-3 validated PQC module adoption\n∙ Hybrid mode support across all external-facing services\n∙ Automated legacy system discovery and migration tracking" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-03.2.json b/docs/api/controls/QTS-03.2.json new file mode 100644 index 00000000..10d9db0c --- /dev/null +++ b/docs/api/controls/QTS-03.2.json @@ -0,0 +1,94 @@ +{ + "control_id": "QTS-03.2", + "title": "Post-Quantum Cryptography (PQC) Migration Progress Oversight", + "family": "QTS", + "description": "Mechanisms exist to establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership.", + "scf_question": "Does the organization establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Note: Typically not required at this size; document any PQC migration progress informally", + "medium": "∙ PQC migration progress metrics\n∙ Inclusion in security program status reports", + "large": "∙ Executive dashboard for PQC migration progress\n∙ Milestone-based reporting aligned to PQCAP\n∙ Regular reporting to security leadership", + "enterprise": "∙ Board-level PQC migration progress reporting\n∙ Automated migration tracking in GRC platform\n∙ KPIs aligned to PQCAP milestones\n∙ Regulatory compliance reporting on PQC readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-03.3.json b/docs/api/controls/QTS-03.3.json new file mode 100644 index 00000000..693f4383 --- /dev/null +++ b/docs/api/controls/QTS-03.3.json @@ -0,0 +1,97 @@ +{ + "control_id": "QTS-03.3", + "title": "Post-Quantum Cryptography (PQC) Supply Chain Visibility", + "family": "QTS", + "description": "Mechanisms exist to require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "scf_question": "Does the organization require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04", + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Request PQC support roadmaps from key technology vendors\n∙ Include PQC readiness in vendor RFPs", + "medium": "∙ Vendor PQC readiness assessments as part of TPRM\n∙ Contractual requirements for PQC roadmap disclosure\n∙ Vendor questionnaires on quantum readiness", + "large": "∙ Formal vendor PQC disclosure requirements\n∙ PQC readiness as part of third-party risk assessments\n∙ Vendor roadmap tracking for critical suppliers", + "enterprise": "∙ Enterprise vendor PQC supply chain program\n∙ Automated vendor PQC tracking in TPRM platform\n∙ Contractual PQC disclosure requirements for all critical vendors\n∙ Regular supply chain quantum risk reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-03.4.json b/docs/api/controls/QTS-03.4.json new file mode 100644 index 00000000..504de3c9 --- /dev/null +++ b/docs/api/controls/QTS-03.4.json @@ -0,0 +1,95 @@ +{ + "control_id": "QTS-03.4", + "title": "Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements", + "family": "QTS", + "description": "Mechanisms exist to require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "scf_question": "Does the organization require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-CPL-01" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "medium": "∙ Include PQC flow-down requirements in new vendor contracts\n∙ Reference NIST PQC standards in contract language", + "large": "∙ Formal PQC flow-down contract requirements\n∙ Supplier compliance verification\n∙ Integration with third-party risk management", + "enterprise": "∙ Enterprise PQC flow-down program\n∙ Automated contract requirement tracking\n∙ Subcontractor PQC compliance monitoring\n∙ Integration with supply chain risk management platform" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-03.json b/docs/api/controls/QTS-03.json new file mode 100644 index 00000000..4d3bf252 --- /dev/null +++ b/docs/api/controls/QTS-03.json @@ -0,0 +1,105 @@ +{ + "control_id": "QTS-03", + "title": "Post-Quantum Cryptography Agility Plan (PSCAP)", + "family": "QTS", + "description": "Mechanisms exist to develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms.", + "scf_question": "Does the organization develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Basic PQC transition roadmap aligned to NIST PQC standards\n∙ NIST PQCAP guidance (https://csrc.nist.gov/pqc)", + "medium": "∙ Documented PQCAP aligned to NIST standards\n∙ Risk-prioritized migration roadmap\n∙ Integration with enterprise risk management", + "large": "∙ Formal PQCAP with executive sponsorship\n∙ Risk-prioritized migration with milestones\n∙ NIST PQC and NSA CNSA 2.0 alignment\n∙ Annual plan refresh", + "enterprise": "∙ Enterprise PQCAP with board visibility\n∙ Dedicated PQC program office\n∙ NIST, NSA CNSA 2.0, and CISA PQC guidance alignment\n∙ Integration with enterprise architecture and GRC" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "3", + "5", + "5.3", + "6" + ], + "apac-aus-ism-2026-march": [ + "ISM-1917", + "ISM-2073" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-04.1.json b/docs/api/controls/QTS-04.1.json new file mode 100644 index 00000000..7b8104ab --- /dev/null +++ b/docs/api/controls/QTS-04.1.json @@ -0,0 +1,96 @@ +{ + "control_id": "QTS-04.1", + "title": "Post-Quantum Cryptography (PQC) Asset Inventory", + "family": "QTS", + "description": "Mechanisms exist to maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "scf_question": "Does the organization maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Spreadsheet-based cryptographic asset inventory\n∙ Document algorithms, key lengths, and associated systems", + "medium": "∙ Structured cryptographic asset inventory\n∙ FIPS validation status tracking\n∙ Integration with overall asset inventory", + "large": "∙ Formal cryptographic asset inventory with automated updates\n∙ FIPS 140-3 validation tracking\n∙ Integration with vulnerability management and asset management", + "enterprise": "∙ Enterprise cryptographic asset inventory platform\n∙ Automated discovery and inventory maintenance\n∙ FIPS 140-3 validation status integration\n∙ Continuous inventory accuracy monitoring" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-04.2.json b/docs/api/controls/QTS-04.2.json new file mode 100644 index 00000000..a60e1da5 --- /dev/null +++ b/docs/api/controls/QTS-04.2.json @@ -0,0 +1,100 @@ +{ + "control_id": "QTS-04.2", + "title": "Cryptographic Bill of Materials (CBOM)", + "family": "QTS", + "description": "Mechanisms exist to develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing the organization's cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols.", + "scf_question": "Does the organization develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing its cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-05" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing the organization's cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "medium": "∙ Software Composition Analysis (SCA) tools to identify cryptographic library usage\n∙ Manual CBOM for critical applications", + "large": "∙ SCA platform with cryptographic library identification\n∙ CBOM generation for critical systems\n∙ Integration with SBOM processes", + "enterprise": "∙ Enterprise CBOM generation platform\n∙ Integration with SCA and SBOM tooling\n∙ Automated cryptographic dependency tracking\n∙ CBOM as input to PQC migration prioritization" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2082", + "ISM-2083" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-04.3.json b/docs/api/controls/QTS-04.3.json new file mode 100644 index 00000000..982cee10 --- /dev/null +++ b/docs/api/controls/QTS-04.3.json @@ -0,0 +1,96 @@ +{ + "control_id": "QTS-04.3", + "title": "Post-Quantum Cryptography Exposure", + "family": "QTS", + "description": "Mechanisms exist to maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "scf_question": "Does the organization maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-10" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Identify systems using quantum-vulnerable public key algorithms (RSA, ECDSA, DH)\n∙ Prioritize based on data sensitivity", + "medium": "∙ Inventory of systems with PQC exposure\n∙ Risk-based prioritization of exposed systems\n∙ Integration with vulnerability management", + "large": "∙ Formal PQC exposure inventory\n∙ Automated scanning for quantum-vulnerable algorithm use\n∙ Risk-prioritized remediation planning", + "enterprise": "∙ Continuous PQC exposure monitoring\n∙ Enterprise scanning for quantum-vulnerable implementations\n∙ Automated risk prioritization and remediation tracking\n∙ Board-level PQC exposure reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-04.json b/docs/api/controls/QTS-04.json new file mode 100644 index 00000000..b108c4ba --- /dev/null +++ b/docs/api/controls/QTS-04.json @@ -0,0 +1,100 @@ +{ + "control_id": "QTS-04", + "title": "Post-Quantum Cryptography (PQC) Discovery & Visibility", + "family": "QTS", + "description": "Mechanisms exist to gain situational awareness into the organization’s current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques.", + "scf_question": "Does the organization gain situational awareness into its current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to gain situational awareness into the organization’s current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Manual cryptographic algorithm inventory\n∙ Free scanning tools for common quantum-vulnerable implementations", + "medium": "∙ Automated cryptographic discovery tools\n∙ Cryptographic inventory as part of vulnerability management\n∙ NIST guidance on cryptographic discovery (https://csrc.nist.gov/pqc)", + "large": "∙ Automated cryptographic discovery and inventory platform\n∙ Integration with asset management and vulnerability scanning\n∙ Regular cryptographic posture reporting", + "enterprise": "∙ Enterprise cryptographic discovery platform\n∙ Continuous cryptographic inventory maintenance\n∙ Integration with GRC, asset management, and SIEM\n∙ Automated quantum exposure reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "5" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-05.1.json b/docs/api/controls/QTS-05.1.json new file mode 100644 index 00000000..ff031073 --- /dev/null +++ b/docs/api/controls/QTS-05.1.json @@ -0,0 +1,100 @@ +{ + "control_id": "QTS-05.1", + "title": "Quantum Threat Intelligence Monitoring", + "family": "QTS", + "description": "Mechanisms exist to maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists.", + "scf_question": "Does the organization maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-10", + "E-THR-03" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subscribe to NIST and CISA PQC update notifications (https://csrc.nist.gov/pqc)", + "small": "∙ NIST and CISA PQC update subscriptions\n∙ Relevant industry group newsletters or alerts", + "medium": "∙ Dedicated quantum threat intelligence monitoring\n∙ NIST, CISA, and NSA PQC guidance tracking\n∙ Industry-specific quantum security working groups", + "large": "∙ Quantum threat intelligence function within threat intelligence program\n∙ Monitoring of cryptanalytic advances and quantum computing milestones\n∙ NIST algorithm update tracking", + "enterprise": "∙ Dedicated quantum threat intelligence capability\n∙ Monitoring of academic, regulatory, and vendor quantum developments\n∙ Integration with enterprise threat intelligence platform\n∙ Regular quantum threat briefings to leadership" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-05.2.json b/docs/api/controls/QTS-05.2.json new file mode 100644 index 00000000..a925824e --- /dev/null +++ b/docs/api/controls/QTS-05.2.json @@ -0,0 +1,96 @@ +{ + "control_id": "QTS-05.2", + "title": "Collaboration & Information Sharing", + "family": "QTS", + "description": "Mechanisms exist to ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk.", + "scf_question": "Does the organization ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor outputs from sector-specific quantum security working groups\n∙ CISA and NIST information-sharing resources", + "medium": "∙ Participation in sector-appropriate quantum security working groups\n∙ ISAC membership where relevant\n∙ CISA PQC working group engagement", + "large": "∙ Active participation in quantum security forums and ISACs\n∙ NIST PQC working group engagement\n∙ Cross-sector information sharing on quantum threats", + "enterprise": "∙ Enterprise participation in quantum security forums\n∙ ISAC and government information sharing partnerships\n∙ Active contribution to quantum security standards development\n∙ Public-private partnership engagement on quantum readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-05.json b/docs/api/controls/QTS-05.json new file mode 100644 index 00000000..9d356995 --- /dev/null +++ b/docs/api/controls/QTS-05.json @@ -0,0 +1,98 @@ +{ + "control_id": "QTS-05", + "title": "Quantum Security Awareness", + "family": "QTS", + "description": "Mechanisms exist to deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles.", + "scf_question": "Does the organization deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-SAT-05" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Include quantum threat awareness in annual security training\n∙ NIST PQC awareness resources (https://csrc.nist.gov/pqc)", + "medium": "∙ Differentiated quantum security awareness content by role\n∙ General workforce awareness module\n∙ Technical team PQC training", + "large": "∙ Role-specific quantum security awareness program (workforce, technical, leadership)\n∙ Integration with annual security awareness platform", + "enterprise": "∙ Enterprise quantum security awareness program\n∙ Differentiated content for workforce, technical, and leadership roles\n∙ Annual training refresh aligned to NIST and regulatory updates\n∙ Integration with Learning Management System (LMS)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.1.json b/docs/api/controls/QTS-06.1.json new file mode 100644 index 00000000..44b75e1e --- /dev/null +++ b/docs/api/controls/QTS-06.1.json @@ -0,0 +1,95 @@ +{ + "control_id": "QTS-06.1", + "title": "Entropy Source & Random Bit Generation", + "family": "QTS", + "description": "Mechanisms exist to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation.", + "scf_question": "Does the organization use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use OS and cloud provider cryptographically secure random number generators\n∙ Avoid custom entropy implementations", + "small": "∙ Cryptographically secure PRNG from OS or validated cryptographic libraries\n∙ NIST SP 800-90B guidance (https://csrc.nist.gov)", + "medium": "∙ FIPS 140-3 validated entropy sources\n∙ Hardware Security Module (HSM) with validated RNG\n∙ NIST SP 800-90B compliance", + "large": "∙ FIPS 140-3 validated HSMs for key generation\n∙ Validated entropy sources aligned to NIST SP 800-90B\n∙ Enterprise key management platform", + "enterprise": "∙ Enterprise HSM infrastructure with FIPS 140-3 validated entropy\n∙ Quantum random number generators (QRNG) for enhanced entropy\n∙ Centralized key management platform\n∙ Continuous entropy source validation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.10.json b/docs/api/controls/QTS-06.10.json new file mode 100644 index 00000000..b62c8695 --- /dev/null +++ b/docs/api/controls/QTS-06.10.json @@ -0,0 +1,94 @@ +{ + "control_id": "QTS-06.10", + "title": "Cryptographic Application Programming Interface (API) Abstraction", + "family": "QTS", + "description": "Mechanisms exist to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "scf_question": "Does the organization use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Use established cryptographic libraries with abstraction (e.g., OpenSSL, BouncyCastle)\n∙ Avoid direct algorithm calls; use library-level interfaces", + "medium": "∙ Cryptographic abstraction requirements in development standards\n∙ Use of crypto-agility compatible libraries\n∙ Abstract cryptographic operations from application code", + "large": "∙ Enterprise cryptographic API abstraction standard\n∙ Use of PKCS#11 or equivalent for hardware abstraction\n∙ Crypto abstraction layer in enterprise development frameworks", + "enterprise": "∙ Enterprise cryptographic API abstraction framework\n∙ Universal cryptographic interface standard across all applications\n∙ PKCS#11 and provider-based abstraction architecture\n∙ Automated compliance checking for cryptographic abstraction" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.2.json b/docs/api/controls/QTS-06.2.json new file mode 100644 index 00000000..0fcd78ba --- /dev/null +++ b/docs/api/controls/QTS-06.2.json @@ -0,0 +1,95 @@ +{ + "control_id": "QTS-06.2", + "title": "Stateful Hash-Based Signatures for Firmware & Code Signing", + "family": "QTS", + "description": "Mechanisms exist to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases.", + "scf_question": "Does the organization enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use vendor-managed firmware signing", + "small": "∙ Use vendor-managed firmware signing", + "medium": "∙ Review code signing infrastructure for quantum vulnerability\n∙ Plan migration to hash-based signatures for critical firmware\n∙ NIST SP 800-208 guidance (https://csrc.nist.gov)", + "large": "∙ Hash-based signature scheme deployment for firmware signing\n∙ NIST SP 800-208 compliance for firmware and code signing\n∙ State-management controls to prevent key reuse", + "enterprise": "∙ Enterprise hash-based signature infrastructure for firmware and code signing\n∙ NIST SP 800-208 compliant implementation\n∙ Automated state management to prevent one-time key reuse\n∙ HSM-backed hash-based key management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.3.json b/docs/api/controls/QTS-06.3.json new file mode 100644 index 00000000..a8129dad --- /dev/null +++ b/docs/api/controls/QTS-06.3.json @@ -0,0 +1,106 @@ +{ + "control_id": "QTS-06.3", + "title": "Approved Post-Quantum Cryptography (PQC) Algorithm Use", + "family": "QTS", + "description": "Mechanisms exist to define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).", + "scf_question": "Does the organization define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Monitor NIST PQC algorithm approvals (https://csrc.nist.gov/pqc)\n∙ Adopt approved PQC algorithms as available in consumed services", + "small": "∙ Reference NIST PQC approved algorithms in cryptography policy\n∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)", + "medium": "∙ Define approved PQC algorithm list\n∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) adoption\n∙ FIPS 140-3 validated module requirements", + "large": "∙ Formal approved PQC algorithm standard\n∙ NIST FIPS 203/204/205 compliant implementations\n∙ Required validation levels in cryptography policy\n∙ Algorithm approval workflow for exceptions", + "enterprise": "∙ Enterprise approved PQC algorithm governance\n∙ NIST FIPS 203/204/205 and CNSA 2.0 alignment\n∙ Automated algorithm compliance enforcement\n∙ Integration with cryptographic exception register" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1990", + "ISM-1991", + "ISM-1992", + "ISM-1993", + "ISM-1994", + "ISM-1995" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.4.json b/docs/api/controls/QTS-06.4.json new file mode 100644 index 00000000..b9250bd5 --- /dev/null +++ b/docs/api/controls/QTS-06.4.json @@ -0,0 +1,95 @@ +{ + "control_id": "QTS-06.4", + "title": "Post-Quantum Cryptography (PQC) Validation Requirements", + "family": "QTS", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use cloud provider services with FIPS 140-3 validated cryptographic modules\n∙ Prefer managed services over self-hosted cryptography", + "small": "∙ Use FIPS 140-3 validated cryptographic libraries and services\n∙ NIST CMVP validation list (https://csrc.nist.gov/projects/cryptographic-module-validation-program)", + "medium": "∙ FIPS 140-3 validated module requirements for cryptographic operations\n∙ Track NIST CMVP PQC validation certificates\n∙ Policy mandate for validated modules where applicable", + "large": "∙ Enterprise policy requiring FIPS 140-3 validated modules\n∙ Validation tracking in cryptographic asset inventory\n∙ HSM with FIPS 140-3 validation for key management", + "enterprise": "∙ Enterprise FIPS 140-3 validation requirement enforcement\n∙ Automated validation status tracking in cryptographic inventory\n∙ HSM infrastructure with FIPS 140-3 Level 3 validation\n∙ Continuous compliance monitoring for cryptographic module validation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.5.json b/docs/api/controls/QTS-06.5.json new file mode 100644 index 00000000..962173c4 --- /dev/null +++ b/docs/api/controls/QTS-06.5.json @@ -0,0 +1,101 @@ +{ + "control_id": "QTS-06.5", + "title": "Deprecated Cryptographic Algorithms", + "family": "QTS", + "description": "Mechanisms exist to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.", + "scf_question": "Does the organization identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Disable RC4, DES, 3DES and MD5 in systems and services\n∙ Enforce TLS 1.2 minimum (disable TLS 1.0/1.1)\n∙ Reference NIST SP 800-131A for deprecated algorithm guidance", + "small": "∙ Deprecated algorithm disablement per NIST SP 800-131A\n∙ TLS 1.2 minimum enforcement\n∙ Retire RSA-1024 and similar weak key sizes", + "medium": "∙ Deprecated algorithm disablement across all systems\n∙ NIST SP 800-131A and SP 800-57 compliance\n∙ Vulnerability scanning for deprecated algorithm detection", + "large": "∙ Formal deprecated algorithm disablement program\n∙ Automated scanning for deprecated cryptographic use\n∙ NIST SP 800-131A compliance tracking", + "enterprise": "∙ Enterprise deprecated algorithm removal program\n∙ Automated detection and alerting for deprecated algorithm use\n∙ NIST SP 800-131A and CNSA 2.0 compliance enforcement\n∙ Continuous monitoring for deprecated algorithm introduction" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "5.2" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.6.json b/docs/api/controls/QTS-06.6.json new file mode 100644 index 00000000..fea88b3f --- /dev/null +++ b/docs/api/controls/QTS-06.6.json @@ -0,0 +1,95 @@ +{ + "control_id": "QTS-06.6", + "title": "Post-Quantum Cryptography (PQC) Key Management", + "family": "QTS", + "description": "Mechanisms exist to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources.", + "scf_question": "Does the organization manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Shorten TLS certificate validity periods (e.g., 90-day certificates)\n∙ Let's Encrypt for automated short-lived certificate management (https://letsencrypt.org)", + "small": "∙ 90-day certificate validity enforcement\n∙ Automated certificate lifecycle management\n∙ Let's Encrypt or ACME protocol (https://letsencrypt.org)", + "medium": "∙ Shortened certificate validity periods per PQC guidance\n∙ Certificate lifecycle management platform\n∙ PKI preparation for PQC roots of trust", + "large": "∙ Enterprise certificate lifecycle management with shortened validity periods\n∙ PKI infrastructure preparation for PQC transition\n∙ HSM-backed key generation with quantum-safe entropy", + "enterprise": "∙ Enterprise PKI with PQC-ready architecture\n∙ Automated certificate lifecycle management (e.g., Venafi, Keyfactor)\n∙ HSM infrastructure with quantum-safe entropy sources\n∙ Dual-root hybrid trust model support" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.7.json b/docs/api/controls/QTS-06.7.json new file mode 100644 index 00000000..273e1e85 --- /dev/null +++ b/docs/api/controls/QTS-06.7.json @@ -0,0 +1,95 @@ +{ + "control_id": "QTS-06.7", + "title": "Quantum-Safe Public Key Infrastructure (PKI) Transition", + "family": "QTS", + "description": "Mechanisms exist to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.", + "scf_question": "Does the organization transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Rely on cloud provider and CA/Browser Forum quantum-safe transitions", + "small": "∙ Monitor CA/Browser Forum and browser vendor PQC adoption timelines\n∙ Plan reliance on public CA quantum-safe transition", + "medium": "∙ Assess internal PKI for PQC transition readiness\n∙ Evaluate hybrid certificate support in PKI platforms\n∙ Certificate authority PQC roadmap review", + "large": "∙ Internal PKI PQC transition plan\n∙ Hybrid certificate deployment for critical services\n∙ Trust anchor migration planning to quantum-safe algorithms", + "enterprise": "∙ Enterprise quantum-safe PKI transition program\n∙ Hybrid certificate infrastructure deployment\n∙ Trust anchor migration to NIST FIPS 203/204/205 algorithms\n∙ Integration with enterprise certificate lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.8.json b/docs/api/controls/QTS-06.8.json new file mode 100644 index 00000000..ba679209 --- /dev/null +++ b/docs/api/controls/QTS-06.8.json @@ -0,0 +1,95 @@ +{ + "control_id": "QTS-06.8", + "title": "Algorithm Negotiation Integrity", + "family": "QTS", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Enforce TLS 1.3 (includes transcript integrity protection)\n∙ Disable TLS 1.0/1.1 and weak cipher suites", + "small": "∙ TLS 1.3 enforcement\n∙ Disable deprecated cipher suites\n∙ Monitor for TLS downgrade attempts via web application firewall", + "medium": "∙ TLS 1.3 with strong cipher suite enforcement\n∙ Monitoring for algorithm downgrade attempts\n∙ Disallow classical-only cipher suite negotiation where PQC is deployed", + "large": "∙ TLS 1.3 enforcement with integrity-protected handshake\n∙ Algorithm downgrade monitoring and alerting\n∙ Cipher suite allowlisting across enterprise TLS infrastructure", + "enterprise": "∙ Enterprise TLS cipher suite governance with automated enforcement\n∙ Algorithm negotiation integrity monitoring at scale\n∙ Automated detection of downgrade attempts\n∙ Integration with network security monitoring and SIEM" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.9.json b/docs/api/controls/QTS-06.9.json new file mode 100644 index 00000000..84ec3623 --- /dev/null +++ b/docs/api/controls/QTS-06.9.json @@ -0,0 +1,98 @@ +{ + "control_id": "QTS-06.9", + "title": "Hybrid / Composite Cryptography", + "family": "QTS", + "description": "Mechanisms exist to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.", + "scf_question": "Does the organization leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor TLS library and browser vendor hybrid PQC support\n∙ Plan adoption of hybrid modes when widely available", + "medium": "∙ Pilot hybrid cryptography for highest-risk external-facing services\n∙ IETF hybrid draft standards monitoring\n∙ Vendor hybrid mode support assessment", + "large": "∙ Hybrid cryptography deployment for critical services\n∙ ECDH + ML-KEM hybrid KEM support\n∙ Hybrid certificate testing and deployment", + "enterprise": "∙ Enterprise hybrid cryptography deployment program\n∙ Hybrid KEM (ECDH + ML-KEM) and hybrid signatures (ECDSA + ML-DSA)\n∙ PKI infrastructure supporting dual-key/dual-certificate models\n∙ Plan for classical algorithm sunset post-PQC confidence" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1996" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-06.json b/docs/api/controls/QTS-06.json new file mode 100644 index 00000000..8ff81e0e --- /dev/null +++ b/docs/api/controls/QTS-06.json @@ -0,0 +1,102 @@ +{ + "control_id": "QTS-06", + "title": "Crypto-Agility Architecture", + "family": "QTS", + "description": "Mechanisms exist to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "scf_question": "Does the organization validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Use cloud-native cryptographic services with configurable algorithm support\n∙ Avoid hardcoded cryptographic algorithm dependencies", + "medium": "∙ Design systems for cryptographic algorithm replaceability\n∙ Crypto-agility requirements in architecture reviews\n∙ Abstraction of cryptographic operations from application logic", + "large": "∙ Crypto-agility architecture validation in design reviews\n∙ Cryptographic abstraction layer requirements\n∙ Support for PQC key and signature sizes in protocols and libraries", + "enterprise": "∙ Enterprise crypto-agility architecture program\n∙ Formal agility validation across protocols, libraries and hardware\n∙ Cryptographic abstraction APIs enforced organization-wide\n∙ Automated architecture compliance checking" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "4", + "5.4", + "6.2", + "6.3", + "6.4" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/QTS-07.json b/docs/api/controls/QTS-07.json new file mode 100644 index 00000000..787a27f8 --- /dev/null +++ b/docs/api/controls/QTS-07.json @@ -0,0 +1,96 @@ +{ + "control_id": "QTS-07", + "title": "Cryptographic Incident Response (Emergency Algorithm Transition)", + "family": "QTS", + "description": "Mechanisms exist to establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios.", + "scf_question": "Does the organization establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-12" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Maintain vendor and CA contacts for certificate revocation emergencies\n∙ Basic plan for replacing compromised certificates", + "medium": "∙ Emergency certificate replacement procedures\n∙ Pre-identified algorithm alternates in security runbook\n∙ Integration with incident response plan", + "large": "∙ Formal cryptographic incident response plan\n∙ Pre-identified algorithm alternates with tested rollback procedures\n∙ Customer/counterparty communication templates\n∙ Integration with enterprise incident response", + "enterprise": "∙ Enterprise cryptographic incident response program\n∙ Tested emergency algorithm transition procedures\n∙ 24/7 incident response capability for cryptographic emergencies\n∙ Regular cryptographic incident response exercises" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/QTS-08.json b/docs/api/controls/QTS-08.json new file mode 100644 index 00000000..7dca772c --- /dev/null +++ b/docs/api/controls/QTS-08.json @@ -0,0 +1,94 @@ +{ + "control_id": "QTS-08", + "title": "PQC Implementation Validation & Interoperability Testing", + "family": "QTS", + "description": "Mechanisms exist to validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions.", + "scf_question": "Does the organization validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Verify PQC implementations using NIST test vectors (https://csrc.nist.gov/pqc)\n∙ Use FIPS 140-3 validated modules where available", + "medium": "∙ PQC implementation testing using NIST test vectors\n∙ Interoperability testing with key counterparties\n∙ FIPS 140-3 validated module requirement", + "large": "∙ Formal PQC implementation validation program\n∙ Interoperability testing with counterparties and successors\n∙ Performance testing for PQC use cases\n∙ Test result documentation", + "enterprise": "∙ Enterprise PQC implementation validation framework\n∙ Automated test vector validation\n∙ Continuous interoperability testing with ecosystem partners\n∙ Third-party validation for critical implementations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/RSK-01.1.json b/docs/api/controls/RSK-01.1.json index be880a3f..91f541f3 100644 --- a/docs/api/controls/RSK-01.1.json +++ b/docs/api/controls/RSK-01.1.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify:\n(1) Assumptions affecting risk assessments, risk response and risk monitoring;\n(2) Constraints affecting risk assessments, risk response and risk monitoring;\n(3) The organizational risk tolerance; and\n(4) Priorities, benefits and trade-offs considered by the organization for managing risk.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96,7 +96,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -285,10 +286,10 @@ "609.930(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(a)", @@ -302,9 +303,7 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.6.1(66)", - "3.7.2(82)" + "3.3.1.10" ], "emea-eu-dora-2023": [ "Article 8.2" @@ -312,12 +311,18 @@ "emea-eu-nis2-annex-2024": [ "2.1.2(c)" ], - "emea-isr-cmo-1-0": [ - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.1" ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" + "emea-esp-decree-311-2022": [ + "Article 14(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" + ], + "apac-aus-ps-cps-230-2023": [ + "16(b)", + "27" ], "apac-jpn-ismap": [ "4.4.6.1", @@ -329,20 +334,16 @@ "23.2.17.C.01" ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.3.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.15", - "6.24" + "4.2.1" ], "americas-can-osfi-b13-2022": [ "1.3", "3.1.8" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" ] diff --git a/docs/api/controls/RSK-01.2.json b/docs/api/controls/RSK-01.2.json index e8f77e42..7309b01b 100644 --- a/docs/api/controls/RSK-01.2.json +++ b/docs/api/controls/RSK-01.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -100,7 +100,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { diff --git a/docs/api/controls/RSK-01.3.json b/docs/api/controls/RSK-01.3.json index 20e1583b..5592b07a 100644 --- a/docs/api/controls/RSK-01.3.json +++ b/docs/api/controls/RSK-01.3.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk tolerance, the specified range of acceptable results.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -108,7 +108,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -165,13 +166,19 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "2.1.2(b)" ], + "emea-deu-c5-2020": [ + "OIS-07-DOAR" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.11" + ], "apac-aus-ps-cps-230-2023": [ - "26" + "16(b)" ], "apac-ind-sebi-2024": [ "GV.RM.S4" @@ -179,8 +186,20 @@ "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "11.2" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(d)", + "4.4.2" + ], "americas-can-osfi-b13-2022": [ "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-01.4.json b/docs/api/controls/RSK-01.4.json index a6f11a79..8212a906 100644 --- a/docs/api/controls/RSK-01.4.json +++ b/docs/api/controls/RSK-01.4.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -108,7 +108,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -148,19 +149,23 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "13.2.2(b)" ], - "apac-aus-ps-cps-230-2023": [ - "26" - ], "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-sgp-mas-trm-2021": [ + "4.4.2" + ], "americas-can-osfi-b13-2022": [ "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-01.5.json b/docs/api/controls/RSK-01.5.json index 5a47dbf6..bf17b205 100644 --- a/docs/api/controls/RSK-01.5.json +++ b/docs/api/controls/RSK-01.5.json @@ -108,7 +108,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -157,17 +158,23 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(a)" + "3.3.1.10", + "3.3.1.13(a)" ], "emea-eu-nis2-annex-2024": [ "2.1.2(b)" ], + "emea-deu-c5-2020": [ + "OIS-07-DOAR" + ], "emea-sau-cgiot-2024": [ "1-4-5" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.11" + ], "apac-aus-ps-cps-230-2023": [ - "26" + "16(b)" ], "apac-ind-sebi-2024": [ "GV.RM.S4" @@ -175,9 +182,20 @@ "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.5", + "3.1.7(d)" + ], "americas-can-osfi-b13-2022": [ "1.3", "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-01.json b/docs/api/controls/RSK-01.json index 5d67bc65..c7d16aa7 100644 --- a/docs/api/controls/RSK-01.json +++ b/docs/api/controls/RSK-01.json @@ -2,8 +2,8 @@ "control_id": "RSK-01", "title": "Risk Management Program", "family": "RSK", - "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls.", - "scf_question": "Does the organization facilitate the implementation of strategic, operational and tactical risk management controls?", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "scf_question": "Does the organization facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) its Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -118,8 +118,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Risk Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -366,9 +368,12 @@ ], "general-nist-800-171-r3": [ "03.11.01.a", - "03.17.01.a" + "03.17.01.a", + "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", "A.03.17.03.b" ], "general-nist-csf-2-0": [ @@ -395,9 +400,6 @@ "general-pci-dss-4-0-1": [ "12.3" ], - "general-scf-dpmp-2025": [ - "9.0" - ], "general-tisax-6-0-3": [ "1.4.1" ], @@ -460,12 +462,12 @@ "314.4(b)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "PM-9", @@ -521,15 +523,14 @@ "Article 17.1(g)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(7)", - "3.3.1(10)", - "3.3.1(13)(a)", - "3.3.1(13)(b)", - "3.3.1(13)(c)", - "3.3.1(13)(d)", - "3.3.1(13)(e)", - "3.3.1(13)(f)", - "3.3.1(14)" + "3.2.3.7", + "3.3.1.10", + "3.3.1.13", + "3.3.1.13(d)", + "3.3.1.13(e)", + "3.3.1.13(f)", + "3.3.1.14", + "3.3.4.23" ], "emea-eu-dora-2023": [ "Article 6.1", @@ -573,37 +574,20 @@ "7.1", "7.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "3.1", "3.2", - "3.3", - "3.4", - "3.5", - "3.6", - "3.7", - "3.8", - "3.9", - "3.10", - "3.11", - "12.3" + "3.5" ], "emea-deu-c5-2020": [ - "OIS-06" + "OIS-06", + "OIS-07" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.1", - "2.2" + "emea-isr-cmo-2-0": [ + "3" ], "emea-sau-cscc-1-2019": [ - "1-2" + "1-2-1" ], "emea-sau-cgiot-2024": [ "1-4-1" @@ -614,26 +598,38 @@ "1-5-4" ], "emea-sau-otcc-1-2022": [ - "1-3", - "1-3-1", - "1-3-1-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "1-3-1" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 7.1", - "Article 7.2" + "3.2.1", + "3.2.1.1-1", + "3.2.1.2-1", + "3.2.1.3-1", + "3.2.1.4-1", + "3.2.1.5", + "3.2.1.5.a", + "3.2.1.5.b", + "3.2.1.5.c", + "3.2.1.6", + "3.2.1.6.a", + "3.2.1.6.b", + "3.2.1.6.c", + "3.2.1.6.d", + "3.2.1.7", + "3.2.1.8", + "3.2.1.8.a", + "3.2.1.8.b", + "3.2.1.8.c", + "3.2.1.8.d" ], "emea-esp-decree-311-2022": [ - "7.1", - "7.2" + "Article 7(2)", + "Article 12(6)(b)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" ], "emea-gbr-caf-4-0": [ "A2", @@ -659,26 +655,12 @@ "1201", "1204" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0726" ], "apac-aus-ps-cps-230-2023": [ - "12(a)", - "12(c)", - "13", - "16(a)", - "16(b)", - "16(c)", - "16(d)", - "16(e)", - "16(f)", - "17", - "18", - "19(a)", - "19(b)", - "19(c)", - "19(d)", - "19(e)" + "16", + "16(d)" ], "apac-ind-sebi-2024": [ "GV.RM.S1" @@ -688,7 +670,14 @@ "4.5.5.2", "4.8.1.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "9.1", + "9.2", + "9.3", + "11.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP30", "HML30" ], @@ -703,20 +692,16 @@ "5.3.9.C.01" ], "apac-sgp-mas-trm-2021": [ + "3.1.4", + "3.1.7(a)", "4.1.1", - "4.1.2", + "4.1.4", + "4.1.4(d)", "4.1.5" ], "americas-bmu-mba-coc-2020": [ "5.3", - "5.8" - ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "6.4", - "6.8", - "6.16", - "6.24" + "5.11-BP1" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -724,9 +709,15 @@ "1.3.2", "3.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.1", + "1.3.2", + "3.1.8" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", - "03.17.01.A" + "03.17.01.A", + "03.17.03.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-02.1.json b/docs/api/controls/RSK-02.1.json index 85f2c8d9..fbb12ecd 100644 --- a/docs/api/controls/RSK-02.1.json +++ b/docs/api/controls/RSK-02.1.json @@ -93,7 +93,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -138,6 +139,10 @@ "03.11.01.a", "03.14.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.14.03.a" + ], "general-nist-csf-2-0": [ "ID.RA-05", "ID.RA-06" @@ -159,25 +164,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.9(b)(3)" ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "apac-nzl-ism-3-9": [ "23.2.16.C.01", "23.2.17.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.3.1", - "4.3.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.14.03.B" diff --git a/docs/api/controls/RSK-02.json b/docs/api/controls/RSK-02.json index d82bd6cf..f128351f 100644 --- a/docs/api/controls/RSK-02.json +++ b/docs/api/controls/RSK-02.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to categorize TAASD in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -95,7 +95,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -184,6 +185,9 @@ "general-nist-800-171-r3": [ "03.11.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a" + ], "general-nist-csf-2-0": [ "ID.AM" ], @@ -245,10 +249,10 @@ "RA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-cms-marse-2-0": [ "RA-2", @@ -275,18 +279,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "RA-02" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" - ], - "apac-sgp-mas-trm-2021": [ - "4.2.1" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" diff --git a/docs/api/controls/RSK-03.1.json b/docs/api/controls/RSK-03.1.json index 4b3c2007..3408ab2a 100644 --- a/docs/api/controls/RSK-03.1.json +++ b/docs/api/controls/RSK-03.1.json @@ -73,7 +73,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -95,14 +96,12 @@ "TASK 2-1" ], "general-nist-800-171-r3": [ + "03.11.01.a", "03.15.02.a.03" ], "general-nist-800-171a-r3": [ "A.03.11.01.a" ], - "general-nist-800-172": [ - "3.11.5e" - ], "general-nist-csf-2-0": [ "ID" ], @@ -129,10 +128,10 @@ "609.930(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(a)", @@ -150,17 +149,30 @@ "emea-deu-bsrit-2017": [ "3.3" ], + "emea-deu-c5-2020": [ + "OIS-03-DOAR" + ], "emea-sau-cgiot-2024": [ "1-4-2", "1-4-4" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.1-2.2" + ], "apac-jpn-ismap": [ "4.4.7.2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-mas-trm-2021": [ + "4.2.1" + ], "americas-can-osfi-b13-2022": [ "3.1.1" ], "americas-can-itsp-10-171-2025": [ + "03.11.01.A", "03.15.02.A.03" ] } diff --git a/docs/api/controls/RSK-03.2.json b/docs/api/controls/RSK-03.2.json new file mode 100644 index 00000000..d044571f --- /dev/null +++ b/docs/api/controls/RSK-03.2.json @@ -0,0 +1,104 @@ +{ + "control_id": "RSK-03.2", + "title": "Risk Owner", + "family": "RSK", + "description": "Mechanisms exist to identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks.", + "scf_question": "Does the organization identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks?", + "relative_weight": 9, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Risk register with assigned owner column\n∙ Designated security lead responsible for risk follow-up", + "small": "∙ Risk register with mandatory owner assignment\n∙ Regular risk owner check-ins on remediation progress", + "medium": "∙ Formal risk ownership assignment in risk register\n∙ GRC platform with risk owner workflow\n∙ Management accountability for open risk items", + "large": "∙ GRC platform with risk ownership and accountability workflow\n∙ Executive reporting on risk owner compliance\n∙ Risk owner training and awareness", + "enterprise": "∙ Enterprise GRC platform with risk ownership management\n∙ Automated risk owner escalation and reminders\n∙ Board-level reporting on material risk accountability\n∙ Risk ownership integrated into performance management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-17", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - RMiT", + "family_name": "Risk Management", + "crosswalks": { + "emea-deu-bsrit-2017": [ + "3.4" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.3" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/RSK-03.json b/docs/api/controls/RSK-03.json index 3403732e..e0222524 100644 --- a/docs/api/controls/RSK-03.json +++ b/docs/api/controls/RSK-03.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and document risks, both internal and external.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and document risks, both internal and external. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,7 +95,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -233,10 +234,10 @@ "314.4(c)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(b)(1)" @@ -252,9 +253,9 @@ "Article 9.2(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "emea-eu-dora-2023": [ "Article 8.2" @@ -264,31 +265,25 @@ "2.1.2(d)" ], "emea-deu-c5-2020": [ - "SP-03" + "OIS-03-DOAR", + "OIS-07" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.1" ], "emea-sau-cgiot-2024": [ "1-1-2", "1-4-1", "1-4-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.2" + "3.2.1.4-1.a", + "3.2.1.1-2", + "3.2.1.1-2.1", + "3.2.1.1-2.3" ], - "emea-esp-decree-311-2022": [ - "3.2" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], "emea-gbr-cap-1850-2020": [ "A2" @@ -305,13 +300,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1200" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1526" ], + "apac-aus-ps-cps-230-2023": [ + "13", + "16(d)" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], "apac-nzl-ism-3-9": [ "2.4.13.C.01", "2.4.13.C.02", @@ -322,14 +324,12 @@ "2.4.13.C.07" ], "apac-sgp-mas-trm-2021": [ - "4.1.3", - "4.1.4(a)" + "4.1.4(a)", + "4.2.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "5.3-BP1", + "5.5-BP1" ], "americas-can-osfi-b13-2022": [ "1.3", diff --git a/docs/api/controls/RSK-04.1.json b/docs/api/controls/RSK-04.1.json index 431ecbac..30f808d2 100644 --- a/docs/api/controls/RSK-04.1.json +++ b/docs/api/controls/RSK-04.1.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to maintain a risk register that facilitates monitoring and reporting of risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -94,7 +94,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -132,6 +133,10 @@ "03.12.02.a.01", "03.12.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" + ], "general-nist-csf-2-0": [ "GV.RM-06", "ID", @@ -154,9 +159,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.3" - ], "general-tisax-6-0-3": [ "1.4.1" ], @@ -185,15 +187,14 @@ "500.9(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(d)" + "3.3.1.10", + "3.3.1.13(d)" ], "emea-deu-c5-2020": [ - "SP-03" + "OIS-03-DOAR" ], - "emea-isr-cmo-1-0": [ - "2.2", - "6.8" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.2" ], "emea-sau-cscc-1-2019": [ "1-2-1-2" @@ -202,17 +203,11 @@ "1-4-3" ], "emea-sau-otcc-1-2022": [ - "1-3-1-3", - "1-3-1-6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "1-3-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.4" - ], - "emea-zaf-popia-2013": [ - "19" + "3.2.1.4-1.c", + "3.2.1.1-2.2" ], "emea-gbr-def-stan-05-138-2024": [ "4201" @@ -223,27 +218,28 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4201" ], + "apac-aus-ps-cps-230-2023": [ + "13", + "32" + ], "apac-ind-sebi-2024": [ "GV.RM.S4" ], "apac-jpn-ismap": [ "4.4.7.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP65", "HML64" ], "apac-sgp-mas-trm-2021": [ - "4.1.3", - "4.1.4(d)", - "4.5.2", - "4.5.3" + "4.5.2" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "5.5-BP4" ], "americas-can-osfi-b13-2022": [ "1.3", diff --git a/docs/api/controls/RSK-04.2.json b/docs/api/controls/RSK-04.2.json index fee834c5..3118d414 100644 --- a/docs/api/controls/RSK-04.2.json +++ b/docs/api/controls/RSK-04.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to implement a risk assessment methodology to ensure coverage for organizational components relevant for secure, compliant and resilient operations.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -89,7 +89,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -108,9 +109,6 @@ "6.2", "6.7" ], - "general-nist-800-172": [ - "3.11.1e" - ], "general-swift-cscf-2025": [ "7.4A" ], @@ -156,10 +154,33 @@ "7.2(e)", "7.2(f)" ], + "emea-deu-c5-2020": [ + "OIS-07" + ], + "emea-sau-cscc-1-2019": [ + "1-2-1" + ], + "emea-sau-ecc-1-2018": [ + "1-5-1", + "1-5-2" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-1" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.1", "4.4.7.4" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.4(d)" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-04.3.json b/docs/api/controls/RSK-04.3.json index 3f19d1f0..96f4e1e8 100644 --- a/docs/api/controls/RSK-04.3.json +++ b/docs/api/controls/RSK-04.3.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define instances that require a risk assessment to be performed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -86,16 +86,14 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { "general-mpa-csbp-5-3-1": [ "OR-2.0" ], - "general-scf-dpmp-2025": [ - "9.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7150(a)", "7150(b)", @@ -114,6 +112,9 @@ "apac-jpn-ismap": [ "4.4.7.3", "4.5.5.1" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.4(d)" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-04.4.json b/docs/api/controls/RSK-04.4.json index fa191527..8f09c153 100644 --- a/docs/api/controls/RSK-04.4.json +++ b/docs/api/controls/RSK-04.4.json @@ -84,16 +84,17 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { - "general-scf-dpmp-2025": [ - "9.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7151(a)", "7151(b)" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-04.json b/docs/api/controls/RSK-04.json index 68ec48e6..0ceedc98 100644 --- a/docs/api/controls/RSK-04.json +++ b/docs/api/controls/RSK-04.json @@ -95,7 +95,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -286,12 +287,7 @@ "3.11.1[b]" ], "general-nist-800-171a-r3": [ - "A.03.11.01.a", - "A.03.11.01.b" - ], - "general-nist-800-172": [ - "3.11.1e", - "3.11.5e" + "A.03.11.01.a" ], "general-nist-csf-2-0": [ "GV.RM-06", @@ -317,9 +313,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.1" - ], "general-swift-cscf-2025": [ "7.4A" ], @@ -369,6 +362,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "RA-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(1)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(b)", "314.4(b)(1)", @@ -377,12 +373,12 @@ "314.4(b)(1)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "usa-federal-irs-1075-2021": [ "RA-3" @@ -439,10 +435,9 @@ "Article 9.2(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.3.3(20)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "emea-eu-dora-2023": [ "Article 8.3", @@ -459,16 +454,19 @@ "2.1.3", "6.1.1" ], + "emea-eu-psd2-2015": [ + "95(2)" + ], "emea-deu-bsrit-2017": [ - "3.10" + "3.9" ], "emea-deu-c5-2020": [ "OIS-07", - "SP-03" + "BEI-06" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.2", + "4.2, Stage 2.3" ], "emea-sau-cscc-1-2019": [ "1-2-1-1" @@ -481,29 +479,27 @@ "1-5-3" ], "emea-sau-otcc-1-2022": [ - "1-3-1-2" + "1-3-1-2", + "1-3-1-4", + "1-3-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-31" + "VII.B.TPC-31" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.2", - "Article 14.1", - "Article 14.2" + "3.2.1.4-1.b", + "3.2.1.2-2", + "3.2.1.2-2.1", + "3.2.1.2-2.2" ], "emea-esp-decree-311-2022": [ - "14.1", - "14.2", - "3.2" + "Article 14(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.1 [OP.PL.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "mp.if.3", + "mp.if.5", + "mp.if.6" ], "emea-gbr-cap-1850-2020": [ "A2" @@ -526,12 +522,17 @@ "1202", "1204" ], + "apac-aus-ism-2026-march": [ + "ISM-1203" + ], "apac-aus-ps-cps-230-2023": [ - "27(a)", - "27(b)", - "27(c)", + "13", + "16(d)", "28" ], + "apac-chn-data-security-law-2021": [ + "Article 30" + ], "apac-ind-sebi-2024": [ "ID.RA.S1", "ID.RA.S2" @@ -545,7 +546,11 @@ "4.6.1.1", "6.1.5.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.1", + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP32", "HML32" ], @@ -556,18 +561,23 @@ "2.3.27.C.01", "2.3.27.C.02", "5.9.23.C.01", + "22.4.7.C.01", "23.2.16.C.02" ], "apac-sgp-mas-trm-2021": [ "4.1.4(b)", - "4.3.2" + "4.3.1", + "8.5.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "2.1", - "6.8" + "5.3-BP1", + "5.5", + "5.5-BP2", + "5.11", + "6.19", + "6.19-BP1", + "6.19-BP2", + "6.19-BP3" ], "americas-can-osfi-b13-2022": [ "1.3", diff --git a/docs/api/controls/RSK-05.json b/docs/api/controls/RSK-05.json index 759bcdec..c152f78a 100644 --- a/docs/api/controls/RSK-05.json +++ b/docs/api/controls/RSK-05.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93,7 +93,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -130,6 +131,9 @@ "general-nist-800-171-r3": [ "03.11.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a" + ], "general-nist-csf-2-0": [ "ID", "ID.RA-05", @@ -167,32 +171,11 @@ "500.9(b)(3)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "2.1.2(e)" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-sau-sama-csf-1-2017": [ - "3.2.1.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-sgp-mas-trm-2021": [ - "4.2.1" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "2.2" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" ] diff --git a/docs/api/controls/RSK-06.1.json b/docs/api/controls/RSK-06.1.json index 67b679b5..92f9abbe 100644 --- a/docs/api/controls/RSK-06.1.json +++ b/docs/api/controls/RSK-06.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure proper risk response actions were performed to remediate findings from security, compliance and/or resilience-related:\n(1) Assessments;\n(2) Audits; and/or\n(3) Incidents.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -111,9 +111,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -219,13 +219,11 @@ "03.11.04" ], "general-nist-800-171a-r3": [ + "A.03.11.02.b", "A.03.11.04[01]", "A.03.11.04[02]", "A.03.11.04[03]" ], - "general-nist-800-172": [ - "3.11.6e" - ], "general-nist-csf-2-0": [ "GV.RM-04", "ID.RA-05", @@ -246,9 +244,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "9.4" - ], "general-un-155-2021": [ "7.2.2.3" ], @@ -307,24 +302,16 @@ "Article 9.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "3.3.1.13(c)" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.3" + "3.2.1.4-1.d" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 14.2", - "Article 14.3" - ], - "emea-esp-decree-311-2022": [ - "14.2", - "14.3" + "apac-aus-ps-cps-230-2023": [ + "16(d)" ], "apac-jpn-ismap": [ "4.4.7.4", @@ -334,15 +321,8 @@ "4.7.1.3", "4.7.1.6" ], - "apac-sgp-mas-trm-2021": [ - "4.1.5", - "4.5.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", diff --git a/docs/api/controls/RSK-06.2.json b/docs/api/controls/RSK-06.2.json index 5943c5dd..f6be1f44 100644 --- a/docs/api/controls/RSK-06.2.json +++ b/docs/api/controls/RSK-06.2.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and implement compensating countermeasures to reduce risk and exposure to threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -112,7 +112,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -170,6 +171,9 @@ "general-nist-800-171-r3": [ "03.11.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.b" + ], "general-nist-csf-2-0": [ "GV.RM-04", "ID.RA-06" @@ -206,9 +210,6 @@ "2.2.4", "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.0" - ], "general-un-155-2021": [ "7.2.2.3" ], @@ -232,10 +233,10 @@ "314.4(c)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.1.b", @@ -257,22 +258,35 @@ "Article 9.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "emea-eu-nis2-annex-2024": [ "6.6.1(d)" ], + "emea-deu-c5-2020": [ + "OIS-04-DOAR", + "SA-03-DOAR" + ], "emea-sau-otcc-1-2022": [ "1-3-1-6", "1-3-1-7" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-aus-ism-2024-june": [ + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2.6", + "3.2.1.3-2.6.a", + "3.2.1.3-2.6.b", + "3.2.1.3-2.6.b.1", + "3.2.1.3-2.6.b.2", + "3.2.1.3-2.6.b.3", + "3.2.1.3-2.6.c", + "3.2.1.3-2.6.d" + ], + "emea-esp-decree-311-2022": [ + "Article 28(3)" + ], + "apac-aus-ism-2026-march": [ + "ISM-0009", "ISM-1809" ], "apac-ind-sebi-2024": [ @@ -283,7 +297,10 @@ "4.4.8.1", "4.4.8.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP26", "HHSP43", "HHSP65", @@ -292,6 +309,7 @@ "HML64" ], "apac-nzl-ism-3-9": [ + "11.1.18.C.03", "12.4.5.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ @@ -299,20 +317,18 @@ "4.3(c)" ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.4.2", - "4.4.3" + "4.4.1" ], "americas-bmu-mba-coc-2020": [ - "5.8" - ], - "amaericas-can-osfi-self-assessment": [ - "6.16", - "6.24" + "5.11-BP4" ], "americas-can-osfi-b13-2022": [ "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.3", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B" ] diff --git a/docs/api/controls/RSK-06.3.json b/docs/api/controls/RSK-06.3.json index ba65344c..e37f4ba4 100644 --- a/docs/api/controls/RSK-06.3.json +++ b/docs/api/controls/RSK-06.3.json @@ -2,8 +2,8 @@ "control_id": "RSK-06.3", "title": "Risk Treatment Options", "family": "RSK", - "description": "Mechanisms exist to select appropriate risk treatment options, based on applicable risk assessment findings.", - "scf_question": "Does the organization select appropriate risk treatment options, based on applicable risk assessment findings?", + "description": "Mechanisms exist to select appropriate risk treatment options, based on applicable risk assessment findings, including:\n(1) Mitigating the risk to an acceptable level;\n(2) Avoiding the risk (e.g., terminating the project);\n(3) Transferring the risk to a third party (e.g., insurance, service provider, etc.); or\n(4) Accepting the risk.", + "scf_question": "Does the organization select appropriate risk treatment options, based on applicable risk assessment findings, including:\n(1) Mitigating the risk to an acceptable level;\n(2) Avoiding the risk (e.g., terminating the project);\n(3) Transferring the risk to a third party (e.g., insurance, service provider, etc.); or\n(4) Accepting the risk?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to select appropriate risk treatment options, based on applicable risk assessment findings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,8 +103,10 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Risk Management", "crosswalks": { "general-iso-21434-2021": [ @@ -139,10 +141,44 @@ "RISK-4a", "RISK-4b" ], + "emea-deu-bsrit-2017": [ + "3.9" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 3.1" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-6" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.10", + "3.2.1.3-2.3", + "3.2.1.3-2.3.a", + "3.2.1.3-2.3.b", + "3.2.1.3-2.3.b.1", + "3.2.1.3-2.3.b.2", + "3.2.1.3-2.4", + "3.2.1.3-2.5", + "3.2.1.3-2.5.a", + "3.2.1.3-2.5.b", + "3.2.1.3-2.5.c" + ], "apac-jpn-ismap": [ "4.4.7.1", "4.4.8.1", "4.4.8.2" + ], + "apac-mys-bnm-rmit-2025": [ + "11.17" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.3", + "4.1.4(c)", + "4.4.2", + "4.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "5.8" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-06.4.json b/docs/api/controls/RSK-06.4.json index 5c907768..830b8c16 100644 --- a/docs/api/controls/RSK-06.4.json +++ b/docs/api/controls/RSK-06.4.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to formalize a Risk Treatment Plan (RTP) that applicable stakeholders will utilize to remediate identified risks according to a defined timeline.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -105,9 +105,9 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], - "errata": "- renamed", "family_name": "Risk Management", "crosswalks": { "general-cobit-2019": [ @@ -161,6 +161,27 @@ "RISK:SG5.SP2", "TM:SG3.SP2" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 4" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-6" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2.2", + "3.2.1.3-2.7", + "3.2.1.4-2", + "3.2.1.4-2.1", + "3.2.1.4-2.1.a", + "3.2.1.4-2.1.b", + "3.2.1.4-2.2" + ], + "emea-esp-decree-311-2022": [ + "Article 14(3)" + ], + "apac-aus-ps-cps-230-2023": [ + "31" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.1", @@ -173,6 +194,13 @@ "4.7.1.1", "4.7.1.4", "4.9" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.2.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-06.json b/docs/api/controls/RSK-06.json index 1e121c95..1a735080 100644 --- a/docs/api/controls/RSK-06.json +++ b/docs/api/controls/RSK-06.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to remediate risks to an acceptable level.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to remediate risks to an acceptable level. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -112,7 +112,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -225,8 +226,9 @@ "03.11.02.b", "03.12.02.a.02" ], - "general-nist-800-172": [ - "3.11.7e" + "general-nist-800-171a-r3": [ + "A.03.11.02.b", + "A.03.12.02.a.02" ], "general-nist-csf-2-0": [ "GV.RM-04", @@ -308,7 +310,8 @@ "Article 9.2(d)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "emea-eu-nis2-2022": [ "Article 21.4" @@ -319,24 +322,26 @@ "2.1.2(g)", "2.1.2(j)" ], + "emea-deu-bsrit-2017": [ + "11.1" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.3" + ], "emea-sau-cgiot-2024": [ "1-1-2", "1-4-1", "1-4-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 14.2", - "Article 14.3" + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2", + "3.2.1.3-2.1" ], "emea-esp-decree-311-2022": [ - "14.2", - "14.3" + "Article 3(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], "emea-gbr-def-stan-05-138-2024": [ "1200" @@ -351,6 +356,7 @@ "1200" ], "apac-aus-ps-cps-230-2023": [ + "13", "31" ], "apac-ind-sebi-2024": [ @@ -360,24 +366,24 @@ "4.6.1.1", "4.7.1.1" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-pdpa-2012": [ + "4.1.15A(5)(b)(i)", + "4.1.15A(5)(b)(ii)", + "4.1.15A(5)(b)(iii)" + ], "apac-sgp-mas-trm-2021": [ - "4.1.3", "4.1.4(c)", - "4.4.1", - "4.4.2", - "4.4.3", - "13.6.1", - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" + "4.4.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" + "5.3-BP1", + "5.5-BP3" ], - "amaericas-can-osfi-self-assessment": [ - "2.2", - "2.7", - "6.8" + "americas-can-osfi-self-assessment-2": [ + "3.2.3" ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", diff --git a/docs/api/controls/RSK-07.json b/docs/api/controls/RSK-07.json index 89ef373e..df42e4a7 100644 --- a/docs/api/controls/RSK-07.json +++ b/docs/api/controls/RSK-07.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -106,7 +106,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -160,30 +161,11 @@ "500.9(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(f)" + "3.3.1.13(f)" ], "emea-eu-nis2-annex-2024": [ "2.1.4" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS05" - ], - "apac-sgp-mas-trm-2021": [ - "4.1.5" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.B" ] diff --git a/docs/api/controls/RSK-08.json b/docs/api/controls/RSK-08.json index 3b8fd632..ab7986c8 100644 --- a/docs/api/controls/RSK-08.json +++ b/docs/api/controls/RSK-08.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to conduct a Business Impact Analysis (BIA) to identify and assess security, compliance and resilience risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -106,9 +106,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -169,11 +169,9 @@ "general-pci-dss-4-0-1": [ "A3.2.2" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(78)" + "3.3.3.20", + "3.7.1.78" ], "emea-eu-dora-2023": [ "Article 11.5" @@ -182,21 +180,12 @@ "2.1.3", "4.1.3" ], - "emea-bel-act-8-1992": [ - "21" - ], "emea-deu-c5-2020": [ - "BCM-02" - ], - "emea-isr-cmo-1-0": [ - "6.8", - "16.6" + "BCM-02-BP5", + "BCM-04" ], - "emea-sau-ecc-1-2018": [ - "1-5-3-4" - ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.1.2" @@ -210,18 +199,21 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4201" ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "apac-aus-ps-cps-230-2023": [ + "26" ], "apac-jpn-ismap": [ "4.4.7.3" ], - "apac-sgp-mas-trm-2021": [ - "5.1.3", - "5.3.3" + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-ism-3-9": [ + "16.1.30.C.01" ], - "apac-kor-pipa-2011": [ - "33" + "americas-bmu-mba-coc-2020": [ + "5.14", + "7.1-BP1" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-09.1.json b/docs/api/controls/RSK-09.1.json index 4221ead8..725c5b59 100644 --- a/docs/api/controls/RSK-09.1.json +++ b/docs/api/controls/RSK-09.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to periodically assess supply chain risks associated with Technology Assets, Applications and/or Services (TAAS).", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -117,7 +117,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -200,8 +201,10 @@ "03.11.01.b", "03.17.03.a" ], - "general-nist-800-172": [ - "3.11.6e" + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.11.01.b", + "A.03.17.03.a[01]" ], "general-nist-csf-2-0": [ "GV.SC", @@ -210,9 +213,6 @@ "general-owasp-top-10-2025": [ "A03:2025" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "general-un-155-2021": [ "7.2.2.5" ], @@ -255,17 +255,6 @@ "emea-eu-nis2-annex-2024": [ "5.1.3" ], - "emea-isr-cmo-1-0": [ - "16.6", - "17.3", - "17.11" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-3" - ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -278,13 +267,16 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1452", "ISM-1567" ], "apac-ind-sebi-2024": [ "GV.SC.S7" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.11.01.B", diff --git a/docs/api/controls/RSK-09.2.json b/docs/api/controls/RSK-09.2.json index 91cd7b8e..11ee1694 100644 --- a/docs/api/controls/RSK-09.2.json +++ b/docs/api/controls/RSK-09.2.json @@ -103,7 +103,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { diff --git a/docs/api/controls/RSK-09.json b/docs/api/controls/RSK-09.json index 7a4f189d..b99fdd38 100644 --- a/docs/api/controls/RSK-09.json +++ b/docs/api/controls/RSK-09.json @@ -119,7 +119,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -280,16 +281,11 @@ "A.03.17.01.a[10]", "A.03.17.01.b[01]", "A.03.17.01.b[02]", - "A.03.17.01.c", "A.03.17.03.ODP[01]", "A.03.17.03.a[01]", "A.03.17.03.a[02]", "A.03.17.03.b" ], - "general-nist-800-172": [ - "3.11.6e", - "3.11.7e" - ], "general-nist-csf-2-0": [ "GV.SC", "GV.SC-01", @@ -305,9 +301,6 @@ "general-owasp-top-10-2025": [ "A03:2025" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "general-sparta": [ "CM0026" ], @@ -407,23 +400,16 @@ "5.1.6" ], "emea-deu-c5-2020": [ - "OIS-07" + "OIS-07", + "PS-04-DOAR" ], - "emea-isr-cmo-1-0": [ - "16.3", - "17.3", - "17.11" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-3" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" ], "emea-gbr-caf-4-0": [ "A4", "A4.a" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -436,11 +422,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0731", "ISM-1567", "ISM-1785" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-nzl-ism-3-9": [ "2.2.7.C.01", "12.7.14.C.01", @@ -463,13 +452,6 @@ "12.7.20.C.05", "12.7.21.C.01" ], - "apac-sgp-mas-trm-2021": [ - "5.3.1" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.17.01.A", diff --git a/docs/api/controls/RSK-10.json b/docs/api/controls/RSK-10.json index fb037336..31829dca 100644 --- a/docs/api/controls/RSK-10.json +++ b/docs/api/controls/RSK-10.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to conduct a Data Protection Impact Assessment (DPIA) on Technology Assets, Applications and/or Services (TAAS) that store, process and/or transmit Personal Data (PD) to identify and remediate reasonably-expected risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -72,7 +72,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -168,9 +169,6 @@ "general-pci-dss-4-0-1": [ "A3.2.2" ], - "general-scf-dpmp-2025": [ - "9.5" - ], "general-shared-assessments-sig-2025": [ "P.5" ], @@ -315,64 +313,126 @@ "Article 35.11", "Article 36.1" ], - "emea-deu-c5-2020": [ - "BCM-02" + "emea-deu-fdpa-2017": [ + "3.4.67(1)", + "3.4.67(2)", + "3.4.67(3)", + "3.4.67(4)", + "3.4.67(4)1", + "3.4.67(4)2", + "3.4.67(4)3", + "3.4.67(4)4", + "3.4.67(5)" ], - "emea-isr-cmo-1-0": [ - "16.6", - "17.3" + "emea-irl-dpa-2018": [ + "s.84" ], "emea-ken-pda-2019": [ - "31(1)", - "31(2)(a)", - "31(2)(b)", - "31(2)(c)", - "31(2)(d)", - "31(3)", - "31(4)", - "31(5)", - "31(6)" + "IV.31(1)", + "IV.31(2)", + "IV.31(2)(a)", + "IV.31(2)(b)", + "IV.31(2)(c)", + "IV.31(2)(d)", + "IV.31(3)" ], "emea-qat-pdppl-2020": [ - "8.2" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-4" + "3.11.1" ], "emea-sau-pdpl-2023": [ "Article 22" ], "emea-srb-act-9-2018": [ - "54", - "54.x" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "IV.3.54-1", + "IV.3.54-1(1)", + "IV.3.54-1(2)", + "IV.3.54-1(3)", + "IV.3.54-2", + "IV.3.54-2(1)", + "IV.3.54-2(2)", + "IV.3.54-2(3)", + "IV.3.54-2(4)", + "IV.3.55-1", + "IV.3.55-1(1)", + "IV.3.55-1(2)", + "IV.3.55-2", + "IV.3.55-2(1)", + "IV.3.55-2(2)", + "IV.3.55-2(3)", + "IV.3.55-2(4)", + "IV.3.55-2(5)", + "IV.3.55-2(6)" + ], + "emea-esp-decree-311-2022": [ + "Article 3(2)", + "Article 12(1)(f)" + ], + "emea-che-fadp-2025": [ + "3.22.1", + "3.22.2", + "3.22.2.a", + "3.22.2.b", + "3.22.3", + "3.22.4", + "3.22.5", + "3.22.5.a", + "3.22.5.b", + "3.22.5.c" + ], + "emea-gbr-dpa-2018": [ + "Section 64(1)", + "Section 64(2)", + "Section 64(3)", + "Section 64(3)(a)", + "Section 64(3)(b)", + "Section 64(3)(c)", + "Section 64(3)(d)", + "Section 64(4)" + ], + "apac-aus-ps-cps-230-2023": [ + "26" ], "apac-chn-pipl-2021": [ - "55", - "55(1)", - "55(2)", - "55(3)", - "55(4)", - "55(5)", - "56", - "56(1)", - "56(2)", - "56(3)" + "Article 55", + "Article 56" ], "apac-ind-dpdpa-2023": [ "10(2)(c)(i)" ], - "apac-sgp-mas-trm-2021": [ - "5.1.3", - "5.3.3" - ], - "apac-kor-pipa-2011": [ - "33" + "apac-sgp-pdpa-2012": [ + "4.1.15A(4)(a)", + "4.1.15A(5)(a)" + ], + "americas-bhs-dpa-2003": [ + "V.50(1)", + "V.50(1)(a)", + "V.50(1)(b)", + "V.50(2)", + "V.50(2)(a)", + "V.50(2)(b)", + "V.50(2)(c)", + "V.50(3)", + "V.50(3)(a)", + "V.50(3)(b)", + "V.50(3)(c)", + "V.50(3)(d)", + "V.50(4)", + "V.50(5)", + "V.50(6)", + "V.50(7)", + "V.50(8)", + "V.50(8)(a)", + "V.50(8)(b)", + "V.50(8)(c)", + "V.50(8)(d)", + "V.50(8)(e)", + "V.50(8)(f)" + ], + "americas-bra-lgpd-2018": [ + "II.I.10.II.3" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-11.json b/docs/api/controls/RSK-11.json index 6cb57a8d..c0e2151b 100644 --- a/docs/api/controls/RSK-11.json +++ b/docs/api/controls/RSK-11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure risk monitoring as an integral part of the continuous monitoring strategy that includes monitoring the effectiveness of security, compliance and resilience controls, compliance and change management.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,9 +102,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-nist-800-53-r5-2": [ @@ -128,10 +128,11 @@ "general-nist-800-82-r3-high": [ "CA-07(04)" ], - "general-scf-dpmp-2025": [ - "7.11", - "9.0", - "9.3" + "general-nist-800-172-r3": [ + "03.12.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.03E[01]" ], "usa-federal-fbi-cjis-6-0": [ "CA-7(4)" @@ -166,8 +167,11 @@ "emea-eu-nis2-annex-2024": [ "2.1.2(h)" ], - "emea-zaf-popia-2013": [ - "4" + "emea-sau-sama-csf-1-2017": [ + "3.2.1.4-1.d" + ], + "emea-esp-decree-311-2022": [ + "Article 14(1)" ] } } \ No newline at end of file diff --git a/docs/api/controls/RSK-12.json b/docs/api/controls/RSK-12.json index 2dddbdb5..b0141dd9 100644 --- a/docs/api/controls/RSK-12.json +++ b/docs/api/controls/RSK-12.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure teams are committed to a culture that considers and communicates technology-related risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -85,7 +85,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { diff --git a/docs/api/controls/RSK-13.1.json b/docs/api/controls/RSK-13.1.json index 65cb1a84..98624549 100644 --- a/docs/api/controls/RSK-13.1.json +++ b/docs/api/controls/RSK-13.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to document alternative courses of action to ensure executive leadership is reasonably informed of options to manage material risks, including potential:\n(1) Benefits;\n(2) Drawbacks (including technical limitations);\n(3) Costs; and\n(4) Timelines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -47,7 +47,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", "crosswalks": {} diff --git a/docs/api/controls/RSK-13.2.json b/docs/api/controls/RSK-13.2.json index 3f1502d0..ffeecec2 100644 --- a/docs/api/controls/RSK-13.2.json +++ b/docs/api/controls/RSK-13.2.json @@ -49,7 +49,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", "crosswalks": {} diff --git a/docs/api/controls/RSK-13.json b/docs/api/controls/RSK-13.json index 1c456c18..1228b51e 100644 --- a/docs/api/controls/RSK-13.json +++ b/docs/api/controls/RSK-13.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to obtain executive leadership approval for risk management decisions involving material risk.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to obtain executive leadership approval for risk management decisions involving material risk. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -48,8 +48,16 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", - "crosswalks": {} + "crosswalks": { + "emea-deu-bsrit-2017": [ + "3.4" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.10" + ] + } } \ No newline at end of file diff --git a/docs/api/controls/SAT-01.1.json b/docs/api/controls/SAT-01.1.json index c180e327..a0f168c0 100644 --- a/docs/api/controls/SAT-01.1.json +++ b/docs/api/controls/SAT-01.1.json @@ -112,7 +112,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -125,6 +126,32 @@ "general-nist-600-1-gen-ai-profile": [ "MP-3.4-002" ], + "general-nist-800-171-r3": [ + "03.02.01.b", + "03.02.02.a.02", + "03.02.02.b", + "03.06.04.b" + ], + "general-nist-800-171a-r3": [ + "A.03.02.01.b[01]", + "A.03.02.01.b[02]", + "A.03.02.02.b[01]", + "A.03.02.02.b[02]", + "A.03.06.04.ODP[03]", + "A.03.06.04.ODP[04]", + "A.03.06.04.b[01]", + "A.03.06.04.b[02]", + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" + ], + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.b[01]", + "DS-A.03.02.01E.b[02]", + "A.03.02.01E.ODP[03]" + ], "general-swift-cscf-2025": [ "7.2" ], @@ -132,12 +159,35 @@ "WORKFORCE-2g", "WORKFORCE-4e" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "emea-eu-nis2-annex-2024": [ "8.1.2(a)" ], + "emea-deu-bsrit-2017": [ + "4.9" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.6.6", + "3.1.6.6.a", + "3.1.6.6.b" + ], "apac-jpn-ismap": [ "4.5.2.4", "4.5.2.5" + ], + "apac-sgp-mas-trm-2021": [ + "3.6.4" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], + "americas-can-itsp-10-171-2025": [ + "03.02.01.B", + "03.02.02.A.02", + "03.02.02.B", + "03.06.04.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/SAT-01.json b/docs/api/controls/SAT-01.json index cf2456d9..77443ac5 100644 --- a/docs/api/controls/SAT-01.json +++ b/docs/api/controls/SAT-01.json @@ -22,7 +22,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security workforce development and awareness controls.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security workforce development and awareness controls. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -120,9 +120,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -135,7 +135,7 @@ "6" ], "general-cis-csc-8-1": [ - "14.0", + "14", "14.1" ], "general-cis-csc-8-1-ig1": [ @@ -266,8 +266,7 @@ "general-nist-800-171a-r3": [ "A.03.02.01.ODP[01]", "A.03.02.01.ODP[02]", - "A.03.02.01.a.01[01]", - "A.03.02.01.a.01[02]" + "A.03.02.01.a.01[01]" ], "general-nist-csf-2-0": [ "PR.AT" @@ -326,10 +325,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6", - "7.6" - ], "general-swift-cscf-2025": [ "7.2" ], @@ -394,14 +389,18 @@ "AT-01", "PM-13" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)", + "101.650(d)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-irs-1075-2021": [ "2.D.2", @@ -434,8 +433,7 @@ "AT-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -447,65 +445,48 @@ "8.1.3", "8.2.5" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.9" ], "emea-deu-c5-2020": [ - "HR-03", - "DEV-04" - ], - "emea-isr-cmo-1-0": [ - "20.1" - ], - "emea-qat-pdppl-2020": [ - "11.3" + "HR-03" ], "emea-sau-cgiot-2024": [ "1-9-1" ], "emea-sau-ecc-1-2018": [ "1-10-1", - "1-10-5" + "1-10-2" ], "emea-sau-otcc-1-2022": [ - "1-8" - ], - "emea-sau-sacs-002-2022": [ - "TPC-7" + "1-8-1" ], "emea-sau-sama-csf-1-2017": [ - "3.1.6" - ], - "emea-zaf-popia-2013": [ - "4.1.e" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 6.2" - ], - "emea-esp-decree-311-2022": [ - "6.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "3.1.6", + "3.1.6.1", + "3.1.6.2", + "3.1.6.2.a", + "3.1.6.2.b", + "3.1.6.2.c", + "3.1.6.3", + "3.1.6.4", + "3.1.6.5", + "3.1.6.5.a", + "3.1.6.5.b", + "3.1.6.5.c" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" ], "emea-gbr-caf-4-0": [ "B6.a" ], - "emea-gbr-cap-1850-2020": [ - "B6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0252", "ISM-0720", - "ISM-0735" + "ISM-0735", + "ISM-2022" ], "apac-chn-cybersecurity-law-2017": [ "Article 34(2)" @@ -524,7 +505,7 @@ "7.2.2.17", "7.2.2.18" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP22", "HML22" ], @@ -535,21 +516,17 @@ "9.1.4.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.6.1", - "3.6.4", - "6.1.5" - ], - "americas-bmu-mba-coc-2020": [ - "6.7" + "3.1.6" ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "apac-kor-pipa-2011": [ + "III.2.28(2)" ], "americas-can-osfi-b13-2022": [ "3.1.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], "americas-can-itsp-10-171-2025": [ "03.02.01.A" ] diff --git a/docs/api/controls/SAT-02.1.json b/docs/api/controls/SAT-02.1.json index bb8fe7f8..783ec6b7 100644 --- a/docs/api/controls/SAT-02.1.json +++ b/docs/api/controls/SAT-02.1.json @@ -105,7 +105,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -132,8 +133,11 @@ "general-nist-800-161-r1-level-2": [ "AT-2(1)" ], - "general-scf-dpmp-2025": [ - "1.6" + "general-nist-800-172-r3": [ + "03.02.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.02E" ], "usa-federal-irs-1075-2021": [ "AT-2(CE-1)", @@ -147,6 +151,9 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2605" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" ] } } \ No newline at end of file diff --git a/docs/api/controls/SAT-02.2.json b/docs/api/controls/SAT-02.2.json index 98d7349a..5631e37e 100644 --- a/docs/api/controls/SAT-02.2.json +++ b/docs/api/controls/SAT-02.2.json @@ -74,12 +74,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "14.2" ], "general-cis-csc-8-1-ig1": [ @@ -121,8 +122,10 @@ "general-nist-800-171-r3": [ "03.02.01.a.03" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-171a-r3": [ + "A.03.02.01.a.03[03]", + "A.03.02.01.a.03[05]", + "A.03.02.01.a.03[06]" ], "general-pci-dss-4-0-1": [ "12.6.3.1" @@ -160,11 +163,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AT-02 (03)" ], - "emea-isr-cmo-1-0": [ - "20.4" - ], "emea-sau-ecc-1-2018": [ - "1-10-3" + "1-10-3-1" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-7.3" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -175,12 +178,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ - "ISM-0817" - ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" + "apac-aus-ism-2026-march": [ + "ISM-0817", + "ISM-2071" ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.03" diff --git a/docs/api/controls/SAT-02.json b/docs/api/controls/SAT-02.json index 3c51a40a..4193b351 100644 --- a/docs/api/controls/SAT-02.json +++ b/docs/api/controls/SAT-02.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -110,9 +110,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -239,7 +239,6 @@ "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.06.04.a.03" ], "general-nist-800-171a": [ @@ -249,12 +248,13 @@ "3.2.1[d]" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", "A.03.02.01.ODP[03]", "A.03.02.01.ODP[04]", + "A.03.02.01.a.01[01]", "A.03.02.01.a.03[03]", "A.03.02.01.a.03[04]", - "A.03.02.01.a.03[05]", - "A.03.02.01.a.03[06]" + "A.03.06.04.a.03" ], "general-nist-csf-2-0": [ "PR.AT", @@ -316,9 +316,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-swift-cscf-2025": [ "7.2" ], @@ -360,19 +357,27 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(9)", + "101.650(d)(1)", + "101.650(d)(1)(i)", + "101.650(d)(1)(ii)", + "101.650(d)(1)(iii)", + "101.650(d)(1)(iv)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(i)", - "164.530(b)(2)(i)", - "164.530(b)(2)(i)(A)", - "164.530(b)(2)(i)(B)", - "164.530(b)(2)(i)(C)", - "164.530(b)(2)(ii)" + "§ 164.308(a)(5)(i)", + "§ 164.530(b)(2)(i)", + "§ 164.530(b)(2)(i)(A)", + "§ 164.530(b)(2)(i)(B)", + "§ 164.530(b)(2)(i)(C)", + "§ 164.530(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-irs-1075-2021": [ "2.D.2.1", @@ -434,7 +439,7 @@ "2447(b)(2)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -443,34 +448,40 @@ "8.1.1", "8.1.2" ], - "emea-deu-c5-2020": [ - "HR-03", - "DEV-04" + "emea-deu-fdpa-2017": [ + "3.2.48(2)3" ], - "emea-isr-cmo-1-0": [ - "20.2" + "emea-deu-c5-2020": [ + "HR-03" ], "emea-sau-cgiot-2024": [ "1-9-1", "1-9-2" ], "emea-sau-ecc-1-2018": [ - "1-10-2", - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4" + "1-10-1", + "2-6-3-4" ], "emea-sau-otcc-1-2022": [ - "1-8" + "1-8-2" ], "emea-sau-sacs-002-2022": [ - "TPC-7" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "VII.A.TPC-7", + "VII.A.TPC-7.1", + "VII.A.TPC-7.2", + "VII.A.TPC-7.4", + "VII.A.TPC-7.5", + "VII.A.TPC-8", + "VII.A.TPC-9" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.6.7", + "3.1.7", + "3.3.1.3.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" ], "emea-gbr-caf-4-0": [ "B6" @@ -497,7 +508,7 @@ "2602", "2603" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0252", "ISM-0824", "ISM-1146", @@ -516,29 +527,42 @@ "7.2.2.15", "7.2.2.25" ], + "apac-mys-bnm-rmit-2025": [ + "15.1" + ], "apac-nzl-ism-3-9": [ "9.1.5.C.01", "9.1.5.C.02", "9.1.6.C.01", - "9.1.6.C.02" + "9.1.6.C.02", + "16.4.43.C.01", + "20.1.27.C.01" + ], + "apac-sgp-pdpa-2012": [ + "3.12(c)" ], "apac-sgp-mas-trm-2021": [ "3.6.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" + "americas-bmu-mba-coc-2020": [ + "6.7" ], "americas-can-osfi-b13-2022": [ "3.1.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.01.A.01", "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", "03.06.04.A.03" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(c)", + "P7-4.7.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/SAT-03.1.json b/docs/api/controls/SAT-03.1.json index 97fbe897..4526b9de 100644 --- a/docs/api/controls/SAT-03.1.json +++ b/docs/api/controls/SAT-03.1.json @@ -1,6 +1,6 @@ { "control_id": "SAT-03.1", - "title": "Practical Exercises", + "title": "Practical Security Training Exercises", "family": "SAT", "description": "Mechanisms exist to include practical exercises in security, compliance and resilience training that reinforce training objectives.", "scf_question": "Does the organization include practical exercises in security, compliance and resilience training that reinforce training objectives?", @@ -20,7 +20,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to include practical exercises in security, compliance and resilience training that reinforce training objectives.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to include practical exercises in security, compliance and resilience training that reinforce training objectives.\nMechanisms exist to include practical exercises in security, compliance and resilience training that reinforce training objectives.", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -74,9 +74,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", + "errata": "- renamed control", "family_name": "Security Awareness & Training", "crosswalks": { "general-cis-csc-8-1": [ @@ -109,12 +110,6 @@ "general-nist-800-160-vol-2-r1": [ "AT-03(03)" ], - "general-nist-800-172": [ - "3.2.2e" - ], - "general-scf-dpmp-2025": [ - "1.6" - ], "usa-federal-dow-cmmc-2-level-3": [ "AT.L3-3.2.2E" ], diff --git a/docs/api/controls/SAT-03.2.json b/docs/api/controls/SAT-03.2.json index b76e0dc2..072fa867 100644 --- a/docs/api/controls/SAT-03.2.json +++ b/docs/api/controls/SAT-03.2.json @@ -76,8 +76,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "update mappings to NIST 800-53", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -133,8 +135,11 @@ "AT-2(4)", "AT-2(5)" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.02" ], "general-pci-dss-4-0-1": [ "11.5", @@ -151,9 +156,6 @@ "11.5.1", "11.5.1.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -168,10 +170,10 @@ "AT.L3-3.2.1E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "AT-2(CE-4)" @@ -183,11 +185,8 @@ "3.3.1", "3.3.2" ], - "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3", - "2-3-1-12" + "emea-sau-ecc-1-2018": [ + "1-10-3-1" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -198,20 +197,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0817", "ISM-0824", "ISM-1740" ], - "apac-sgp-mas-trm-2021": [ - "9.2.2", - "11.5.5", - "12.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" - ], "americas-can-osfi-b13-2022": [ "3.1.7" ] diff --git a/docs/api/controls/SAT-03.3.json b/docs/api/controls/SAT-03.3.json index 72451ede..7506d59c 100644 --- a/docs/api/controls/SAT-03.3.json +++ b/docs/api/controls/SAT-03.3.json @@ -2,8 +2,8 @@ "control_id": "SAT-03.3", "title": "Sensitive / Regulated Data Storage, Handling & Processing", "family": "SAT", - "description": "Mechanisms exist to ensure that every user accessing a system processing, storing or transmitting sensitive/regulated data is formally trained in data handling requirements.", - "scf_question": "Does the organization ensure that every user accessing a system processing, storing or transmitting sensitive/regulated data is formally trained in data handling requirements?", + "description": "Mechanisms exist to ensure that every user accessing a system processing, storing or transmitting sensitive and/or regulated data is formally trained in data handling requirements.", + "scf_question": "Does the organization ensure that every user accessing a system processing, storing or transmitting sensitive and/or regulated data is formally trained in data handling requirements?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -104,7 +104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -136,7 +137,7 @@ "6.3(a)" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "OR-3.3" @@ -158,6 +159,11 @@ "03.02.01.a.01", "03.02.02.a.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], "general-nist-800-218": [ "PO.2.2" ], @@ -202,9 +208,6 @@ "9.5.1", "9.5.1.3" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -281,17 +284,17 @@ "usa-state-vt-act-171-2018": [ "2447(c)(8)" ], - "emea-isr-cmo-1-0": [ - "20.3" + "emea-aut-dpa-2018": [ + "§ 6(3)" + ], + "emea-deu-c5-2020": [ + "HR-03-BP2" ], "emea-qat-pdppl-2020": [ - "11.3" + "3.11.3" ], "emea-sau-ecc-1-2018": [ - "1-10-4-2" - ], - "emea-sau-sama-csf-1-2017": [ - "3.1.7" + "1-10-3-2" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -302,7 +305,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0831", "ISM-1059" ], @@ -310,13 +313,12 @@ "7.2.2.16", "7.2.2.19.PB" ], - "apac-sgp-mas-trm-2021": [ - "3.6.2", - "3.6.3", - "6.1.5" + "apac-nzl-ism-3-9": [ + "21.1.6.C.01", + "22.1.11.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "1.7" + "apac-sgp-mas-trm-2021": [ + "3.6.1" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", diff --git a/docs/api/controls/SAT-03.4.json b/docs/api/controls/SAT-03.4.json index 8ab1bde5..8e5336fe 100644 --- a/docs/api/controls/SAT-03.4.json +++ b/docs/api/controls/SAT-03.4.json @@ -21,7 +21,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to incorporate vendor-specific security, compliance and resilience training in support of new technology initiatives.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to incorporate vendor-specific security, compliance and resilience training in support of new technology initiatives. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -87,16 +87,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "usa-federal-dhs-cisa-cpg-2-0": [ "2.J" - ], - "emea-deu-c5-2020": [ - "DEV-04" ] } } \ No newline at end of file diff --git a/docs/api/controls/SAT-03.5.json b/docs/api/controls/SAT-03.5.json index 3074093b..3f18174b 100644 --- a/docs/api/controls/SAT-03.5.json +++ b/docs/api/controls/SAT-03.5.json @@ -3,7 +3,7 @@ "title": "Privileged Users", "family": "SAT", "description": "Mechanisms exist to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", - "scf_question": "Does the organization provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", + "scf_question": "Does the organization provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.\n▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data).", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -125,6 +126,10 @@ "03.02.01.a.01", "03.02.02.a.01" ], + "general-nist-800-171a-r3": [ + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], "general-nist-800-218": [ "PO.2.2" ], @@ -155,26 +160,12 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.10(a)(2)" ], - "emea-sau-ecc-1-2018": [ - "1-10-4-1" - ], - "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1565" ], "apac-ind-sebi-2024": [ "PR.AT.S2" ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.7" - ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.01", "03.02.02.A.01" diff --git a/docs/api/controls/SAT-03.6.json b/docs/api/controls/SAT-03.6.json index 293eea14..fd657573 100644 --- a/docs/api/controls/SAT-03.6.json +++ b/docs/api/controls/SAT-03.6.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.\n▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data).\n▪ Business process owners are required to incorporate vendor-specific security training in support of new technology initiatives.\n▪ Security awareness training covers recommended practices for securing laptops and mobile devices while traveling.\n▪ Security awareness training covers reporting of unauthorized alterations and evidence of tampering of equipment", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide role-based security, compliance and resilience awareness training that is current and relevant to the cyber threats that users might encounter in day-to-day business operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -91,9 +91,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", + "errata": "update mappings to NIST 800-53", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -138,20 +139,24 @@ "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a.02" ], "general-nist-800-171a-r3": [ + "A.03.02.01.a.01[01]", "A.03.02.01.a.02", - "A.03.02.01.b[01]", - "A.03.02.01.b[02]" + "A.03.02.01.b[02]", + "A.03.02.02.a.01[01]", + "A.03.02.02.a.02", + "A.03.06.04.a.02" ], - "general-nist-800-172": [ - "3.2.1e", - "3.2.2e" + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.01", + "DS-A.03.02.01E.a.03" ], "general-nist-800-218": [ "PO.2.2" @@ -204,9 +209,6 @@ "9.5.1", "9.5.1.3" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-shared-assessments-sig-2025": [ "P.4" ], @@ -232,14 +234,17 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(4)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "usa-federal-nispom-2020": [ "§117.12(e)(1)", @@ -260,13 +265,19 @@ "8.1.2(c)", "8.2.3(b)" ], + "emea-deu-c5-2020": [ + "HR-03-BP3" + ], "emea-sau-cgiot-2024": [ "1-9-2" ], + "emea-sau-ecc-1-2018": [ + "1-10-3-3", + "1-10-3-4" + ], "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" + "1-8-2-2", + "2-13-1-8" ], "emea-gbr-def-stan-05-138-2024": [ "2601", @@ -289,19 +300,15 @@ "2603", "3106" ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "apac-sgp-mas-trm-2021": [ + "12.1.3" ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.01", "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", "03.02.02.A.01", "03.02.02.A.02", - "03.02.02.B", "03.06.04.A.02" ] } diff --git a/docs/api/controls/SAT-03.7.json b/docs/api/controls/SAT-03.7.json index 713c4f41..f82dc517 100644 --- a/docs/api/controls/SAT-03.7.json +++ b/docs/api/controls/SAT-03.7.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience personnel receive Continuing Professional Education (CPE) training to maintain currency and proficiency with industry-recognized secure practices that are pertinent to their assigned roles and responsibilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -68,9 +68,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -90,9 +90,6 @@ "general-iso-27701-2025": [ "7.2" ], - "general-nist-800-171-r3": [ - "03.06.04.b" - ], "general-nist-csf-2-0": [ "PR.AT-02" ], @@ -102,11 +99,14 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.10(a)(3)" ], + "emea-sau-otcc-1-2022": [ + "1-8-2-1" + ], "apac-jpn-ismap": [ "4.5.2.4" ], - "americas-can-itsp-10-171-2025": [ - "03.06.04.B" + "apac-mys-bnm-rmit-2025": [ + "15.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/SAT-03.8.json b/docs/api/controls/SAT-03.8.json index 28354b92..a8b4cbfe 100644 --- a/docs/api/controls/SAT-03.8.json +++ b/docs/api/controls/SAT-03.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to ensure application development and operations (DevOps) personnel receive Continuing Professional Education (CPE) training on Secure Software Development Practices (SSDP) to appropriately address evolving threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,7 +61,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -92,8 +93,11 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1780" + ], + "apac-sgp-mas-trm-2021": [ + "6.1.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/SAT-03.9.json b/docs/api/controls/SAT-03.9.json index b569a3f7..085172d1 100644 --- a/docs/api/controls/SAT-03.9.json +++ b/docs/api/controls/SAT-03.9.json @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": {} diff --git a/docs/api/controls/SAT-03.json b/docs/api/controls/SAT-03.json index 5cc5053b..5d940111 100644 --- a/docs/api/controls/SAT-03.json +++ b/docs/api/controls/SAT-03.json @@ -3,7 +3,7 @@ "title": "Role-Based Security, Compliance & Resilience Training", "family": "SAT", "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", - "scf_question": "Does the organization provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafterystem changes; and \n (3) Annually thereafter?", + "scf_question": "Does the organization provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -93,9 +93,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -183,7 +183,7 @@ "7.2" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "OR-3.1", @@ -256,11 +256,10 @@ "03.02.02.a", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a", "03.06.04.a.01", "03.06.04.a.02", - "03.06.04.b" + "03.06.04.a.03" ], "general-nist-800-171a": [ "3.2.2[a]", @@ -268,6 +267,10 @@ "3.2.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.01.a.01[02]", + "A.03.02.01.a.02", "A.03.02.02.ODP[01]", "A.03.02.02.ODP[02]", "A.03.02.02.ODP[03]", @@ -276,14 +279,19 @@ "A.03.02.02.a.01[02]", "A.03.02.02.a.01[03]", "A.03.02.02.a.02", - "A.03.02.02.b[01]", - "A.03.02.02.b[02]", + "A.03.06.04.ODP[01]", + "A.03.06.04.ODP[02]", "A.03.06.04.a.01", "A.03.06.04.a.02", "A.03.06.04.a.03" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-172-r3": [ + "03.02.01E", + "03.02.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.02", + "A.03.02.04E.ODP[01]" ], "general-nist-800-218": [ "PO.2.2" @@ -360,9 +368,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -441,6 +446,14 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(9)", + "101.650(d)(1)(v)", + "101.650(d)(2)", + "101.650(d)(2)(i)", + "101.650(d)(2)(ii)", + "101.650(d)(4)" + ], "usa-federal-sro-finra": [ "248.201(e)(3)" ], @@ -451,13 +464,13 @@ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)", - "164.530(b)(1)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)", + "§ 164.530(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "2.D.2.1", @@ -500,8 +513,7 @@ "Article 9.5(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -515,48 +527,53 @@ "8.2.4" ], "emea-deu-c5-2020": [ - "DEV-04" - ], - "emea-isr-cmo-1-0": [ - "20.2", - "25.3" + "HR-03", + "HR-03-BP1", + "HR-03-BP4", + "HR-03-DOAR" ], "emea-qat-pdppl-2020": [ - "11.3" + "3.11.3" ], "emea-sau-cgiot-2024": [ "1-9-1" ], "emea-sau-ecc-1-2018": [ - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4", - "1-10-4", "1-10-4-1", "1-10-4-2", - "1-10-4-3" + "1-10-4-3", + "1-10-5" ], "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-7" + "1-8-2-1", + "2-13-1-8" ], "emea-sau-sama-csf-1-2017": [ - "3.1.6", - "3.1.7" + "3.1.7.1", + "3.1.7.1.a", + "3.1.7.1.b", + "3.1.7.1.c", + "3.1.7.1.d", + "3.1.7.2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "emea-esp-decree-311-2022": [ + "Article 6(2)", + "Article 15(1)", + "Article 16(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" + ], + "emea-che-fadp-2025": [ + "2.1.10.2.a" ], "emea-gbr-caf-4-0": [ "B6.b" ], + "emea-gbr-cap-1850-2020": [ + "B6" + ], "emea-gbr-def-stan-05-138-2024": [ "2321", "2602" @@ -572,14 +589,11 @@ "2321", "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1146", "ISM-1565", "ISM-1740" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-ind-sebi-2024": [ "PR.AT.S2" ], @@ -590,20 +604,20 @@ "7.2.2.14", "7.2.2.19.PB" ], + "apac-mys-bnm-rmit-2025": [ + "15.2", + "15.3" + ], "apac-nzl-ism-3-9": [ + "2.1.47.C.01", "9.1.6.C.01", "9.1.6.C.02", "9.1.6.C.03" ], "apac-sgp-mas-trm-2021": [ + "3.6.1", "3.6.2", - "3.6.3", - "6.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "3.6.3" ], "americas-can-osfi-b13-2022": [ "3.1.7" @@ -615,11 +629,10 @@ "03.02.02.A", "03.02.02.A.01", "03.02.02.A.02", - "03.02.02.B", "03.06.04.A", "03.06.04.A.01", "03.06.04.A.02", - "03.06.04.B" + "03.06.04.A.03" ] } } \ No newline at end of file diff --git a/docs/api/controls/SAT-04.1.json b/docs/api/controls/SAT-04.1.json new file mode 100644 index 00000000..f0ec11ce --- /dev/null +++ b/docs/api/controls/SAT-04.1.json @@ -0,0 +1,78 @@ +{ + "control_id": "SAT-04.1", + "title": "Training Feedback", + "family": "SAT", + "description": "Mechanisms exist to:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders.", + "scf_question": "Does the organization:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders.", + "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Track training completion rates\n∙ Simple feedback survey after training", + "small": "∙ Training completion tracking\n∙ Post-training feedback forms\n∙ Report findings to management", + "medium": "∙ Learning Management System (LMS) with completion and assessment tracking\n∙ Training effectiveness metrics\n∙ Regular reporting to management on training outcomes", + "large": "∙ LMS with detailed completion and assessment analytics\n∙ Training effectiveness measurement\n∙ Reporting to security leadership and HR", + "enterprise": "∙ Enterprise LMS with advanced analytics\n∙ Training effectiveness measurement and outcome reporting\n∙ Behavioral change metrics linked to awareness program\n∙ Board-level workforce security readiness reporting" + }, + "risks": [ + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Security Awareness & Training", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.02.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.03E" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/SAT-04.json b/docs/api/controls/SAT-04.json index 01287750..4dc20b92 100644 --- a/docs/api/controls/SAT-04.json +++ b/docs/api/controls/SAT-04.json @@ -90,9 +90,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-govramp": [ @@ -180,9 +180,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-tisax-6-0-3": [ "8.2.3" ], @@ -201,6 +198,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(4)" + ], "usa-federal-irs-1075-2021": [ "AT-4" ], diff --git a/docs/api/controls/SAT-05.json b/docs/api/controls/SAT-05.json index 65d63965..51e8083e 100644 --- a/docs/api/controls/SAT-05.json +++ b/docs/api/controls/SAT-05.json @@ -23,7 +23,13 @@ "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Informal security knowledge sharing (e.g., team meetings, email updates)\n∙ Subscribe to CISA and NIST security alerts", + "small": "∙ Regular security briefings or newsletter\n∙ CISA and NIST alert subscriptions for the security team", + "medium": "∙ Internal security knowledge sharing program\n∙ Cross-functional security briefings\n∙ Lessons learned from incidents and assessments", + "large": "∙ Formal knowledge sharing program (security communities of practice)\n∙ Internal security portal or wiki\n∙ Cross-functional security training and briefings", + "enterprise": "∙ Enterprise security knowledge management platform\n∙ Communities of practice for security specializations\n∙ Cross-organizational knowledge sharing and lessons learned\n∙ Integration with LMS and professional development programs" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -94,9 +100,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "usa-federal-dhs-cisa-cpg-2-0": [ diff --git a/docs/api/controls/SEA-01.1.json b/docs/api/controls/SEA-01.1.json index 7e4cf20e..7b6851cf 100644 --- a/docs/api/controls/SEA-01.1.json +++ b/docs/api/controls/SEA-01.1.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to centrally-manage the organization-wide management and implementation of security, compliance and resilience controls and related processes.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -109,22 +109,22 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" ], "general-cis-csc-8-1": [ - "16.1" + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.10" ], "general-cobit-2019": [ "APO03.01", @@ -194,9 +194,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-tisax-6-0-3": [ "5.3.1" ], @@ -225,21 +222,12 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-zaf-popia-2013": [ - "8" - ], - "apac-aus-ps-cps-234-2019": [ - "18" + "emea-isr-cmo-2-0": [ + "Appendix C" ], "apac-nzl-ism-3-9": [ "4.3.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.5.1" - ], - "americas-arg-ppd-2018": [ - "9.1" - ], "americas-can-osfi-b13-2022": [ "1.3.1" ] diff --git a/docs/api/controls/SEA-01.2.json b/docs/api/controls/SEA-01.2.json index 73cbede8..3cc4455f 100644 --- a/docs/api/controls/SEA-01.2.json +++ b/docs/api/controls/SEA-01.2.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to achieve resilience requirements in normal and adverse situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -114,6 +115,12 @@ "emea-eu-nis2-annex-2024": [ "4.2.4" ], + "emea-sau-otcc-1-2022": [ + "3-1-1-1" + ], + "emea-gbr-cap-1850-2020": [ + "B5" + ], "emea-gbr-def-stan-05-138-2024": [ "2500", "2501" @@ -133,6 +140,13 @@ "2500", "2501" ], + "apac-mys-bnm-rmit-2025": [ + "10.24", + "10.31", + "10.32", + "10.40", + "11.2" + ], "americas-can-osfi-b13-2022": [ "2", "2.1.2", diff --git a/docs/api/controls/SEA-01.3.json b/docs/api/controls/SEA-01.3.json index 97f547b9..67facab3 100644 --- a/docs/api/controls/SEA-01.3.json +++ b/docs/api/controls/SEA-01.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -67,9 +67,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-csa-cmm-4-1-0": [ @@ -110,6 +110,15 @@ "emea-gbr-caf-4-0": [ "B5", "B5.b" + ], + "emea-gbr-cap-1850-2020": [ + "B5" + ], + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.32", + "10.40", + "11.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-01.4.json b/docs/api/controls/SEA-01.4.json new file mode 100644 index 00000000..15582b80 --- /dev/null +++ b/docs/api/controls/SEA-01.4.json @@ -0,0 +1,132 @@ +{ + "control_id": "SEA-01.4", + "title": "Secure Architecture Principles", + "family": "SEA", + "description": "Mechanisms exist to ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture.", + "scf_question": "Does the organization ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Reference NIST CSF for architecture guidance\n∙ Apply basic secure design principles (least privilege, defense-in-depth)", + "small": "∙ NIST CSF and OWASP design principles\n∙ Documented secure design checklist", + "medium": "∙ TOGAF or SABSA-aligned secure architecture principles\n∙ Documented architecture principles standard\n∙ Security architecture review in project lifecycle", + "large": "∙ Enterprise secure architecture principles aligned to TOGAF or SABSA\n∙ Security Architecture Review Board (SARB)\n∙ Architecture principles enforced in project governance", + "enterprise": "∙ Enterprise architecture framework with embedded security principles (TOGAF or SABSA)\n∙ Dedicated security architecture function\n∙ Automated architecture compliance checking\n∙ Board-approved enterprise architecture standards" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "emea-deu-bsrit-2017": [ + "1.2(d)" + ], + "emea-deu-c5-2020": [ + "UP-01-BP2", + "SA-01-BP5" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.4", + "3.3.4.1", + "3.3.4.3", + "3.3.4.3.a", + "3.3.4.3.b", + "3.3.4.3.c", + "3.3.4.3.d", + "3.3.4.3.e" + ], + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.5", + "10.36", + "10.37", + "10.38", + "10.40" + ], + "apac-nzl-ism-3-9": [ + "1.2.15.C.01", + "2.3.28.C.01" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/SEA-01.5.json b/docs/api/controls/SEA-01.5.json new file mode 100644 index 00000000..0edc37c5 --- /dev/null +++ b/docs/api/controls/SEA-01.5.json @@ -0,0 +1,106 @@ +{ + "control_id": "SEA-01.5", + "title": "Security-Aware Design", + "family": "SEA", + "description": "Mechanisms exist to formally incorporate the organization's secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "scf_question": "Does the organization formally incorporate its secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to formally incorporate the organization's secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Security design checklist for new systems or applications\n∙ OWASP Top 10 design guidance", + "small": "∙ OWASP secure design principles\n∙ Security requirements in development projects", + "medium": "∙ Security-by-design requirements integrated into SDLC\n∙ Threat modeling for new systems\n∙ OWASP Threat Dragon or similar", + "large": "∙ Enterprise secure-by-design program\n∙ Threat modeling requirements in SDLC\n∙ Security architecture approval for new projects\n∙ Privacy and security design reviews", + "enterprise": "∙ Enterprise security-aware design program\n∙ Automated threat modeling integration in SDLC\n∙ Security and privacy design reviews for all new systems\n∙ Board-approved security-by-design policy" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "apac-nzl-ism-3-9": [ + "2.3.28.C.01" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/SEA-01.json b/docs/api/controls/SEA-01.json index 5ed660a0..c1340601 100644 --- a/docs/api/controls/SEA-01.json +++ b/docs/api/controls/SEA-01.json @@ -22,7 +22,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).\n▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of TAAS.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -104,9 +104,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -121,18 +121,18 @@ "general-cis-csc-8-1": [ "12.2", "12.6", - "16.0", - "16.1" + "16", + "16.10" ], "general-cis-csc-8-1-ig2": [ "12.2", "12.6", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ "12.2", "12.6", - "16.1" + "16.10" ], "general-cobit-2019": [ "APO03.01", @@ -208,7 +208,7 @@ "8.26", "8.27" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -346,7 +346,6 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.16.c", "03.01.18.a", "03.13.01.c", @@ -359,7 +358,13 @@ "3.13.2[f]" ], "general-nist-800-171a-r3": [ - "A.03.16.01.ODP[01]" + "A.03.01.12.a[04]", + "A.03.01.16.a[02]", + "A.03.01.16.c", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01.ODP[01]", + "A.03.16.01" ], "general-nist-csf-2-0": [ "PR.IR", @@ -394,10 +399,6 @@ "6.2.1", "8.5.1" ], - "general-scf-dpmp-2025": [ - "5.12", - "7.1" - ], "general-swift-cscf-2025": [ "1.3" ], @@ -485,10 +486,10 @@ "314.4(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "PT-1", @@ -528,7 +529,7 @@ "SI-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -546,107 +547,28 @@ "6.2.2(b)", "6.2.2(c)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-bsrit-2017": [ - "12.1" + "1.2(d)" ], "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "UP-01-BP2", + "DLL-01-BP1" ], "emea-sau-cgiot-2024": [ "1-5-1", "2-5-1" ], "emea-sau-ecc-1-2018": [ + "1-6-3-1", "1-6-3-4", - "2-4-3", "2-15-3-3" ], "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 29" + "1-4-1-3" ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" - ], - "emea-che-fadp-2025": [ - "6", - "7" - ], - "emea-tur-lppd-2016": [ - "8", - "12" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.4", + "mp.s.2" ], "emea-uae-niaf-2023": [ "3.2.1" @@ -655,10 +577,6 @@ "B4.a", "B5.b" ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" - ], "emea-gbr-def-stan-05-138-2024": [ "2400" ], @@ -671,41 +589,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2400" ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", - "ISM-1743" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" + "ISM-1743", + "ISM-1926", + "ISM-1927" ], "apac-ind-sebi-2024": [ "PR.IP.S17" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "14.2.5", "14.2.5.1", @@ -716,10 +608,19 @@ "14.2.5.6", "14.2.5.7" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.5", + "10.22", + "10.26", + "10.36", + "10.37", + "10.38", + "10.40", + "10.43", + "10.52" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP16", "HML16" ], @@ -727,42 +628,16 @@ "HSUP14" ], "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" + "2.3.28.C.01", + "20.2.14.C.01", + "20.2.14.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" + "14.1.1", + "14.2.10" ], "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" + "5.3-BP3" ], "americas-can-osfi-b13-2022": [ "1.3.1", @@ -772,29 +647,18 @@ "3.2", "3.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.1.1", + "2.1.2", + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", - "03.01.16.B", "03.01.16.C", "03.01.18.A", "03.13.01.C", "03.16.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-02.1.json b/docs/api/controls/SEA-02.1.json index 28cd27b5..2e195686 100644 --- a/docs/api/controls/SEA-02.1.json +++ b/docs/api/controls/SEA-02.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -55,7 +55,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -100,15 +101,18 @@ "usa-federal-far-52-204-21": [ "52.204-21(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.615" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.103", - "164.304", - "164.402", - "164.501", - "164.504(a)" + "§ 164.103", + "§ 164.304", + "§ 164.402", + "§ 164.501", + "§ 164.504(a)" ], "usa-state-ca-ccpa-cpra-2026": [ "7001" @@ -136,30 +140,9 @@ "emea-eu-ai-act-2024": [ "Article 3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 3" - ], "emea-eu-gdpr-2016": [ "Article 4" ], - "emea-ken-pda-2019": [ - "2" - ], - "emea-nga-dpr-2019": [ - "1.3" - ], - "emea-qat-pdppl-2020": [ - "1" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 4" - ], - "emea-esp-decree-311-2022": [ - "4" - ], - "amaericas-can-osfi-self-assessment": [ - "6.4" - ], "americas-can-osfi-b13-2022": [ "A.1" ] diff --git a/docs/api/controls/SEA-02.2.json b/docs/api/controls/SEA-02.2.json index 00301b49..22ceb581 100644 --- a/docs/api/controls/SEA-02.2.json +++ b/docs/api/controls/SEA-02.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to identify non-essential functions or services that are capable of being outsourced to external service providers and align with the organization's enterprise architecture and security standards.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -99,6 +100,12 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(d)" ], + "emea-esp-decree-311-2022": [ + "Article 14(1)" + ], + "apac-aus-ps-cps-230-2023": [ + "15" + ], "apac-jpn-ismap": [ "4.5.4.5" ] diff --git a/docs/api/controls/SEA-02.3.json b/docs/api/controls/SEA-02.3.json index 3090128f..0648920b 100644 --- a/docs/api/controls/SEA-02.3.json +++ b/docs/api/controls/SEA-02.3.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to conduct ongoing “technical debt” reviews of hardware and software technologies to remediate outdated and/or unsupported technologies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,7 +94,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { diff --git a/docs/api/controls/SEA-02.json b/docs/api/controls/SEA-02.json index 73c97aad..197527f0 100644 --- a/docs/api/controls/SEA-02.json +++ b/docs/api/controls/SEA-02.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92,9 +92,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -105,15 +105,15 @@ ], "general-cis-csc-8-1": [ "12.2", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig2": [ "12.2", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ "12.2", - "16.1" + "16.10" ], "general-cobit-2019": [ "APO02.01", @@ -221,6 +221,18 @@ "03.13.01.c", "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01" + ], + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.02" + ], "general-nist-csf-2-0": [ "PR.IR", "PR.IR-01", @@ -229,9 +241,6 @@ "general-pci-dss-4-0-1": [ "1.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.3" ], @@ -271,12 +280,12 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "PL-8", @@ -306,7 +315,7 @@ "PL-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -314,207 +323,44 @@ "Article 9.3(c)", "Article 9.3(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-bsrit-2017": [ - "12.1" - ], - "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" + "1.2(d)" ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "emea-sau-cscc-1-2019": [ + "2-12-2" ], "emea-sau-ecc-1-2018": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 29" - ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" - ], - "emea-che-fadp-2025": [ - "6", - "7" - ], - "emea-tur-lppd-2016": [ - "8", - "12" - ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" + "1-6-3-4" ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "mp.info.4", + "mp.s.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", "ISM-1743" ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" - ], - "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.36", + "10.40" ], "americas-can-osfi-b13-2022": [ "2", "2.1", "2.1.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.1.1", + "2.1.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", "03.01.18.A", "03.13.01.C", "03.16.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-03.1.json b/docs/api/controls/SEA-03.1.json index 3f8a6085..93c54d5d 100644 --- a/docs/api/controls/SEA-03.1.json +++ b/docs/api/controls/SEA-03.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to partition systems so that partitions reside in separate physical domains or environments.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to partition systems so that partitions reside in separate physical domains or environments. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -78,7 +79,7 @@ "general-cis-csc-8-1-ig3": [ "3.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1590.002" ], "general-nist-800-53-r4": [ @@ -93,6 +94,14 @@ "general-nist-800-160-vol-2-r1": [ "SC-32" ], + "general-nist-800-172-r3": [ + "03.13.16E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.16E", + "A.03.13.16E.ODP[01]", + "A.03.13.16E.ODP[02]" + ], "usa-federal-cms-marse-2-0": [ "SC-32", "SC-32-iS" diff --git a/docs/api/controls/SEA-03.2.json b/docs/api/controls/SEA-03.2.json index 4b493acf..6f062aac 100644 --- a/docs/api/controls/SEA-03.2.json +++ b/docs/api/controls/SEA-03.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to separate user functionality from system management functionality.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to separate user functionality from system management functionality. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -87,7 +88,7 @@ "general-iec-62443-3-3-2013": [ "SR 5.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1189", "T1190", diff --git a/docs/api/controls/SEA-03.json b/docs/api/controls/SEA-03.json index d39fbf27..b9b18675 100644 --- a/docs/api/controls/SEA-03.json +++ b/docs/api/controls/SEA-03.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).\n▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -92,7 +92,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -128,6 +129,14 @@ "general-nist-800-171-r2": [ "3.13.2" ], + "general-nist-800-172-r3": [ + "03.15.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.02E.a", + "A.03.15.02E.ODP[02]", + "DS-A.03.15.02E.c" + ], "general-owasp-top-10-2025": [ "A01:2025", "A05:2025" @@ -163,14 +172,17 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(iv)" + ], "usa-federal-law-ftc-act": [ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "PL-8(CE-1)", @@ -181,7 +193,7 @@ "500.2(b)(2)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -189,202 +201,19 @@ "Article 9.3(c)", "Article 9.3(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], - "emea-deu-bsrit-2017": [ - "12.1" - ], - "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "emea-isr-cmo-2-0": [ + "2.E" ], "emea-sau-ecc-1-2018": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 9.1", - "Article 9.1(a)", - "Article 9.1(b)", - "Article 9.2" - ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" - ], - "emea-che-fadp-2025": [ - "6", - "7" + "2-15-3-2" ], - "emea-tur-lppd-2016": [ - "8", - "12" - ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", "ISM-1743" ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" - ], - "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" - ], "americas-can-osfi-b13-2022": [ "3.2", "3.2.4" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-04.1.json b/docs/api/controls/SEA-04.1.json index 1319d2c8..9b4be0da 100644 --- a/docs/api/controls/SEA-04.1.json +++ b/docs/api/controls/SEA-04.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate security functions from non-security functions.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate security functions from non-security functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -94,7 +95,7 @@ "general-govramp-high": [ "SC-03" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003.001", "T1021.003", "T1047", diff --git a/docs/api/controls/SEA-04.2.json b/docs/api/controls/SEA-04.2.json index 05f658d2..d5d126c7 100644 --- a/docs/api/controls/SEA-04.2.json +++ b/docs/api/controls/SEA-04.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement underlying hardware separation mechanisms to facilitate process separation.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement underlying hardware separation mechanisms to facilitate process separation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { diff --git a/docs/api/controls/SEA-04.3.json b/docs/api/controls/SEA-04.3.json index b196bdbb..4fe6a378 100644 --- a/docs/api/controls/SEA-04.3.json +++ b/docs/api/controls/SEA-04.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to maintain a separate execution domain for each thread in multi-threaded processing.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to maintain a separate execution domain for each thread in multi-threaded processing. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { diff --git a/docs/api/controls/SEA-04.4.json b/docs/api/controls/SEA-04.4.json index 3abe09ac..f8790a74 100644 --- a/docs/api/controls/SEA-04.4.json +++ b/docs/api/controls/SEA-04.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate, or logically separate, any application, service and/or process running with system privileges.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79,7 +79,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { diff --git a/docs/api/controls/SEA-04.json b/docs/api/controls/SEA-04.json index 857370c7..d115cbce 100644 --- a/docs/api/controls/SEA-04.json +++ b/docs/api/controls/SEA-04.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement a separate execution domain for each executing process.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement a separate execution domain for each executing process. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -86,7 +87,7 @@ "general-iec-tr-60601-4-5-2021": [ "5.2 - CR 2.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", diff --git a/docs/api/controls/SEA-05.json b/docs/api/controls/SEA-05.json index 415c5c46..13e6fec5 100644 --- a/docs/api/controls/SEA-05.json +++ b/docs/api/controls/SEA-05.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent unauthorized and unintended information transfer via shared system resources.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent unauthorized and unintended information transfer via shared system resources. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -108,7 +109,7 @@ "general-govramp-high": [ "SC-04" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1070", @@ -212,17 +213,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-04" ], - "emea-deu-c5-2020": [ - "OPS-24", - "COS-06" - ], - "emea-isr-cmo-1-0": [ - "10.5", - "10.8" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], "emea-gbr-def-stan-05-138-2024": [ "2416" ], diff --git a/docs/api/controls/SEA-06.json b/docs/api/controls/SEA-06.json index 612e5c6a..5cc01f58 100644 --- a/docs/api/controls/SEA-06.json +++ b/docs/api/controls/SEA-06.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically prevent the execution of unauthorized software programs.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically prevent the execution of unauthorized software programs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -67,7 +67,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { diff --git a/docs/api/controls/SEA-07.1.json b/docs/api/controls/SEA-07.1.json index ddeb0d72..caabdaa7 100644 --- a/docs/api/controls/SEA-07.1.json +++ b/docs/api/controls/SEA-07.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -82,7 +82,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -166,6 +167,10 @@ "03.16.02.a", "03.16.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.02.a", + "A.03.16.02.b" + ], "general-nist-csf-2-0": [ "GV.SC-09", "ID.AM-08", @@ -233,7 +238,7 @@ "SA-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(55)" + "3.5.55" ], "emea-eu-nis2-annex-2024": [ "6.7.2(j)", @@ -246,11 +251,8 @@ "emea-sau-cgiot-2024": [ "2-15-3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 36" - ], - "emea-esp-decree-311-2022": [ - "36" + "emea-sau-otcc-1-2022": [ + "2-2-1-1" ], "emea-gbr-caf-4-0": [ "A3.a (point 5)" @@ -258,16 +260,20 @@ "apac-aus-essential-8-2024": [ "ML3-P2" ], + "apac-aus-ps-cps-230-2023": [ + "25" + ], "apac-sgp-mas-trm-2021": [ - "7.3.1", - "7.3.2", - "7.3.3" + "7.3.2" ], "americas-can-osfi-b13-2022": [ "1.3.1", "2.2", "2.2.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.02.A", "03.16.02.B" diff --git a/docs/api/controls/SEA-07.2.json b/docs/api/controls/SEA-07.2.json index b863a9ea..7cb2c704 100644 --- a/docs/api/controls/SEA-07.2.json +++ b/docs/api/controls/SEA-07.2.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -140,9 +141,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SC-24" - ], - "emea-isr-cmo-1-0": [ - "9.17" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-07.3.json b/docs/api/controls/SEA-07.3.json index 9b6932ee..8868a64f 100644 --- a/docs/api/controls/SEA-07.3.json +++ b/docs/api/controls/SEA-07.3.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement fail-safe procedures when failure conditions occur.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement fail-safe procedures when failure conditions occur. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { diff --git a/docs/api/controls/SEA-07.json b/docs/api/controls/SEA-07.json index 5ec49e27..83940122 100644 --- a/docs/api/controls/SEA-07.json +++ b/docs/api/controls/SEA-07.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to determine the Mean Time to Failure (MTTF) for system components in specific environments of operation.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -102,6 +103,9 @@ "general-nist-800-171-r3": [ "03.16.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.02.b" + ], "general-nist-csf-2-0": [ "ID.AM-08" ], diff --git a/docs/api/controls/SEA-08.1.json b/docs/api/controls/SEA-08.1.json index 448b1a52..70919dd8 100644 --- a/docs/api/controls/SEA-08.1.json +++ b/docs/api/controls/SEA-08.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure that software and data needed for system component and service refreshes are obtained from trusted sources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -111,8 +112,12 @@ "general-nist-800-160-vol-2-r1": [ "SI-14(01)" ], - "general-nist-800-172": [ - "3.14.4e" + "general-nist-800-172-r3": [ + "03.14.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.04E", + "A.03.14.04E.ODP[01]" ], "general-shared-assessments-sig-2025": [ "T.3" @@ -128,9 +133,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "SA-03(03)" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3-2" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-08.2.json b/docs/api/controls/SEA-08.2.json new file mode 100644 index 00000000..508a5083 --- /dev/null +++ b/docs/api/controls/SEA-08.2.json @@ -0,0 +1,83 @@ +{ + "control_id": "SEA-08.2", + "title": "Non-Persistent Information", + "family": "SEA", + "description": "Mechanisms exist to:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed.", + "scf_question": "Does the organization:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Session timeout configurations\n∙ Ephemeral file deletion after use", + "small": "∙ Session termination and ephemeral data deletion\n∙ Temporary file cleanup policies", + "medium": "∙ Automated ephemeral data lifecycle management\n∙ Session management with defined timeout and cleanup\n∙ Secure deletion of temporary data stores", + "large": "∙ Automated non-persistent information management\n∙ Defined data refresh cycles for non-persistent stores\n∙ Secure deletion enforcement", + "enterprise": "∙ Enterprise non-persistent information governance\n∙ Automated data lifecycle enforcement for ephemeral data\n∙ Integration with data classification and DLP\n∙ Continuous monitoring for data persistence policy compliance" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-IR-1", + "R-IR-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.14.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.05E.a", + "A.03.14.05E.ODP[01]", + "DS-A.03.14.05E.b" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/SEA-08.json b/docs/api/controls/SEA-08.json index 66e8de52..0a5f77e1 100644 --- a/docs/api/controls/SEA-08.json +++ b/docs/api/controls/SEA-08.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -78,7 +79,7 @@ "general-iec-62443-4-2-2019": [ "CR 4.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1505", "T1505.001", "T1505.002", @@ -99,6 +100,15 @@ "general-nist-800-160-vol-2-r1": [ "SI-14" ], + "general-nist-800-172-r3": [ + "03.14.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.15E.a", + "DS-A.03.14.15E.b", + "DS-A.03.14.15E.c", + "A.03.14.15E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A01:2025", "A05:2025" diff --git a/docs/api/controls/SEA-09.1.json b/docs/api/controls/SEA-09.1.json index a99721f4..4b5d014f 100644 --- a/docs/api/controls/SEA-09.1.json +++ b/docs/api/controls/SEA-09.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to limit the dissemination of Personal Data (PD) to organization-defined elements identified in the Data Protection Impact Assessment (DPIA) and consistent with authorized purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { diff --git a/docs/api/controls/SEA-09.json b/docs/api/controls/SEA-09.json index a8fdebbd..9bcf63d4 100644 --- a/docs/api/controls/SEA-09.json +++ b/docs/api/controls/SEA-09.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -65,11 +65,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.002", "T1021.005", "T1048", diff --git a/docs/api/controls/SEA-10.json b/docs/api/controls/SEA-10.json index 1dba5cff..a27871e7 100644 --- a/docs/api/controls/SEA-10.json +++ b/docs/api/controls/SEA-10.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security safeguards to protect system memory from unauthorized code execution.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security safeguards to protect system memory from unauthorized code execution. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -84,7 +85,7 @@ "general-govramp-high": [ "SI-16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003.001", "T1047", "T1055.009", @@ -146,6 +147,12 @@ "general-nist-800-171-r2": [ "NFO - SI-16" ], + "general-nist-800-172-r3": [ + "03.14.14E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.14E" + ], "usa-federal-fbi-cjis-6-0": [ "SI-16" ], diff --git a/docs/api/controls/SEA-11.json b/docs/api/controls/SEA-11.json index c95b757d..c41c633d 100644 --- a/docs/api/controls/SEA-11.json +++ b/docs/api/controls/SEA-11.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeypots that are specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting and analyzing such attacks.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeypots that are specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting and analyzing such attacks. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -61,11 +61,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1210", "T1211", "T1212" @@ -88,6 +89,14 @@ "IR-04(13)", "SC-26" ], + "general-nist-800-172-r3": [ + "03.13.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.08E[01]", + "DS-A.03.13.08E[02]", + "DS-A.03.13.08E[03]" + ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -105,9 +114,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "IR-04(13)" - ], - "emea-isr-cmo-1-0": [ - "23.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-12.json b/docs/api/controls/SEA-12.json index eb1a9fff..4c3af413 100644 --- a/docs/api/controls/SEA-12.json +++ b/docs/api/controls/SEA-12.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeyclients that proactively seek to identify malicious websites and/or web-based malicious code.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeyclients that proactively seek to identify malicious websites and/or web-based malicious code. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -58,11 +58,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1210", "T1211", "T1212" @@ -99,9 +100,6 @@ ], "usa-federal-irs-1075-2021": [ "SC-35" - ], - "emea-isr-cmo-1-0": [ - "23.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-13.1.json b/docs/api/controls/SEA-13.1.json index d4d4572f..23a9bbb5 100644 --- a/docs/api/controls/SEA-13.1.json +++ b/docs/api/controls/SEA-13.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize virtualization techniques to support the employment of a diversity of operating systems and applications.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -62,7 +62,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -81,6 +82,12 @@ "general-nist-800-160-vol-2-r1": [ "SC-29(01)" ], + "general-nist-800-172-r3": [ + "03.13.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.07E" + ], "general-swift-cscf-2025": [ "1.3" ], @@ -90,10 +97,7 @@ "usa-federal-irs-1075-2021": [ "3.3.7" ], - "emea-deu-c5-2020": [ - "PSS-11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1460", "ISM-1461", "ISM-1604", @@ -102,29 +106,17 @@ "ISM-1607" ], "apac-nzl-ism-3-9": [ - "22.2.12.C.01", - "22.2.12.C.02", - "22.2.12.C.03", - "22.2.12.C.04", - "22.2.13.C.01", - "22.2.13.C.02", - "22.2.14.C.01", - "22.2.14.C.02", - "22.2.14.C.03", - "22.2.14.C.04", - "22.2.14.C.05", - "22.2.14.C.06", - "22.2.14.C.07", - "22.2.15.C.01", - "22.2.15.C.02", - "22.2.15.C.03", - "22.2.15.C.04", - "22.2.15.C.05", - "22.2.15.C.06", - "22.2.15.C.07", - "22.2.16.C.01", - "22.2.16.C.02", - "22.2.16.C.03" + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.12.C.03", + "20.2.12.C.04", + "20.2.14.C.01", + "20.2.14.C.03", + "20.2.14.C.04", + "20.2.14.C.07" + ], + "apac-sgp-mas-trm-2021": [ + "11.4.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-13.json b/docs/api/controls/SEA-13.json index d0a20b57..1eda9bbb 100644 --- a/docs/api/controls/SEA-13.json +++ b/docs/api/controls/SEA-13.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a diverse set of technologies for system components to reduce the impact of technical vulnerabilities from the same Original Equipment Manufacturer (OEM).", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a diverse set of technologies for system components to reduce the impact of technical vulnerabilities from the same Original Equipment Manufacturer (OEM). ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -64,11 +64,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1189", "T1190", "T1203", @@ -96,8 +97,11 @@ "general-nist-800-161-r1-level-3": [ "SC-29" ], - "general-nist-800-172": [ - "3.13.1e" + "general-nist-800-172-r3": [ + "03.13.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.01E" ], "apac-ind-sebi-2024": [ "EV.ST.S2" diff --git a/docs/api/controls/SEA-14.1.json b/docs/api/controls/SEA-14.1.json index 8e0f47c3..935c92f6 100644 --- a/docs/api/controls/SEA-14.1.json +++ b/docs/api/controls/SEA-14.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically introduce randomness into organizational operations and assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -64,7 +64,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -88,6 +89,12 @@ ], "general-nist-800-161-r1-level-3": [ "SC-30(2)" + ], + "general-nist-800-172-r3": [ + "03.13.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.02E" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-14.2.json b/docs/api/controls/SEA-14.2.json index bc94a67a..c384805f 100644 --- a/docs/api/controls/SEA-14.2.json +++ b/docs/api/controls/SEA-14.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically change the location of processing and/or storage at random time intervals.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -64,7 +64,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -91,6 +92,13 @@ ], "general-nist-800-161-r1-level-3": [ "SC-30(3)" + ], + "general-nist-800-172-r3": [ + "03.13.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.05E", + "A.03.13.05E.ODP[01]" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-14.json b/docs/api/controls/SEA-14.json index 7d200226..7148e226 100644 --- a/docs/api/controls/SEA-14.json +++ b/docs/api/controls/SEA-14.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize concealment and misdirection techniques for TAAS to confuse and mislead adversaries.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize concealment and misdirection techniques for TAAS to confuse and mislead adversaries. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -50,14 +50,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-cr-cmm-2026": [ "CR4.1.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1189", "T1190", @@ -99,8 +100,11 @@ "SC-30(4)", "SC-30(5)" ], - "general-nist-800-172": [ - "3.13.3e" + "general-nist-800-172-r3": [ + "03.13.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.03E" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-15.json b/docs/api/controls/SEA-15.json index 7d06a552..a33f3f5a 100644 --- a/docs/api/controls/SEA-15.json +++ b/docs/api/controls/SEA-15.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to distribute processing and storage across multiple physical locations.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to distribute processing and storage across multiple physical locations. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,11 +80,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -126,12 +127,6 @@ "PE-23", "SC-36" ], - "general-nist-800-172": [ - "3.13.5e" - ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-sparta": [ "CM0074" ], @@ -146,66 +141,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "PE-23" - ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-16.json b/docs/api/controls/SEA-16.json index e938ce06..b869c576 100644 --- a/docs/api/controls/SEA-16.json +++ b/docs/api/controls/SEA-16.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize non-modifiable executable programs that load and execute the operating environment and applications from hardware-enforced, read-only media.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -48,11 +48,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1218.015", "T1542", diff --git a/docs/api/controls/SEA-17.json b/docs/api/controls/SEA-17.json index 90a2d69a..85c32d88 100644 --- a/docs/api/controls/SEA-17.json +++ b/docs/api/controls/SEA-17.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a trusted communications path between the user and the security functions of the system.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -67,7 +67,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -80,8 +81,8 @@ "general-iso-27018-2025": [ "8.5" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.6 [OP.ACC.6]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-18.1.json b/docs/api/controls/SEA-18.1.json index 1af7343a..859c8009 100644 --- a/docs/api/controls/SEA-18.1.json +++ b/docs/api/controls/SEA-18.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to configure Microsoft Windows-based systems to display an approved logon banner before granting access to the system.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -70,9 +70,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -97,14 +97,9 @@ "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], - "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.09" ] diff --git a/docs/api/controls/SEA-18.2.json b/docs/api/controls/SEA-18.2.json index da7cc87f..9b03dd7c 100644 --- a/docs/api/controls/SEA-18.2.json +++ b/docs/api/controls/SEA-18.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a truncated system use notification / logon banner on systems not capable of displaying a logon banner from a centralized directory services technology (e.g., Active Directory, Entra ID, etc.).", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -70,9 +70,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -97,14 +97,9 @@ "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], - "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.09" ] diff --git a/docs/api/controls/SEA-18.json b/docs/api/controls/SEA-18.json index 1bb9a21a..f6ea9ba5 100644 --- a/docs/api/controls/SEA-18.json +++ b/docs/api/controls/SEA-18.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize system use notification / logon banners that display an approved system use notification message or banner before granting access to Technology Assets, Applications and/or Services (TAAS).", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -70,9 +70,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-govramp": [ @@ -96,7 +96,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1199" ], "general-nist-800-53-r4": [ @@ -184,13 +184,12 @@ "2406", "2407" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" + "16.1.44.C.02", + "16.1.44.C.03" ], "americas-can-itsp-10-171-2025": [ "03.01.09" diff --git a/docs/api/controls/SEA-19.json b/docs/api/controls/SEA-19.json index d4ca79e4..a7c33a8a 100644 --- a/docs/api/controls/SEA-19.json +++ b/docs/api/controls/SEA-19.json @@ -2,8 +2,8 @@ "control_id": "SEA-19", "title": "Previous Logon Notification", "family": "SEA", - "description": "Mechanisms exist to configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", - "scf_question": "Does the organization configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon?", + "description": "Mechanisms exist to configure systems that process, store or transmit sensitive and/or regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", + "scf_question": "Does the organization configure systems that process, store or transmit sensitive and/or regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -50,7 +50,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -65,11 +66,6 @@ ], "general-nist-800-82-r3": [ "AC-09" - ], - "apac-nzl-ism-3-9": [ - "16.1.49.C.01", - "16.1.50.C.01", - "16.1.50.C.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-20.json b/docs/api/controls/SEA-20.json index 4fee40ca..521f581d 100644 --- a/docs/api/controls/SEA-20.json +++ b/docs/api/controls/SEA-20.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize time-synchronization technology to synchronize all critical system clocks.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize time-synchronization technology to synchronize all critical system clocks. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -205,6 +206,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-08" ], + "emea-sau-ecc-1-2018": [ + "2-3-3-4" + ], "emea-gbr-def-stan-05-138-2024": [ "2421" ], @@ -217,7 +221,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2421" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0988" ], "apac-jpn-ismap": [ @@ -226,6 +230,9 @@ "12.4.4.2", "12.4.4.3", "12.4.4.4.PB" + ], + "americas-arg-ppd-2018": [ + "E.1.2-9" ] } } \ No newline at end of file diff --git a/docs/api/controls/SEA-21.json b/docs/api/controls/SEA-21.json index cec1d144..7f5e9d04 100644 --- a/docs/api/controls/SEA-21.json +++ b/docs/api/controls/SEA-21.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize an application container (virtualization approach) to isolate to a known set of dependencies, access methods and interfaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -47,7 +47,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { diff --git a/docs/api/controls/SEA-22.json b/docs/api/controls/SEA-22.json index ba23910b..ab2cd862 100644 --- a/docs/api/controls/SEA-22.json +++ b/docs/api/controls/SEA-22.json @@ -3,7 +3,7 @@ "title": "Privileged Environments", "family": "SEA", "description": "Mechanisms exist to prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS).", + "scf_question": "Does the organization prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -91,7 +91,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -99,7 +100,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1687" ] } diff --git a/docs/api/controls/TDA-01.1.json b/docs/api/controls/TDA-01.1.json index 06889c5b..0efd1fda 100644 --- a/docs/api/controls/TDA-01.1.json +++ b/docs/api/controls/TDA-01.1.json @@ -107,7 +107,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -233,6 +234,16 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], + "general-nist-800-172-r3": [ + "03.16.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.16.01E", + "A.03.16.01E.ODP[01]" + ], "general-nist-800-218": [ "PO.1", "PO.1.1", @@ -266,9 +277,6 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-ul-2900-1-2017": [ "7.1", "7.1.1", @@ -461,61 +469,53 @@ "emea-eu-ai-act-2024": [ "Article 14.3(b)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 5", - "Article 5.1", - "Article 5.2", - "Article 10.1", - "Article 10.5", - "Article 10.6", - "Article 10.9", - "Article 10.10", - "Article 10.11", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.3", - "Article 13.4", - "Article 13.5", - "Article 13.6", - "Article 14.1", - "Article 14.2", - "Article 14.2(a)", - "Article 14.2(b)", - "Article 14.3", - "Article 14.4" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(j)", - "Annex 1.2(2)", - "Annex 2.1", - "Annex 2.2", - "Annex 2.3", - "Annex 2.4", - "Annex 2.5", - "Annex 2.6", - "Annex 2.7", - "Annex 2.8", - "Annex 2.9", - "Annex 2.9(a)", - "Annex 2.9(b)", - "Annex 2.9(c)", - "Annex 2.9(d)", - "Annex 6 Module A.3", - "Annex 6 Module A.4.1", - "Annex 6 Module C.2.1", - "Annex 6 Module C.3.1", - "Annex 6 Module H.2", - "Annex 6 Module H.3.2", - "Annex 6 Module H.3.4", - "Annex 6 Module H.5.1", - "Annex 6 Module H.5.2", - "Annex 6 Module H.6" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(1)", + "Article 13(5)", + "Article 13(8)", + "Article 13(10)", + "Article 13(11)", + "Article 13(13)", + "Article 13(14)", + "Article 13(15)", + "Article 13(16)", + "Article 13(17)", + "Article 13(18)", + "Article 13(19)", + "Article 13(20)", + "Article 13(21)", + "Article 13(22)", + "Article 13(23)", + "Article 19(1)", + "Article 19(2)", + "Article 19(2)(c)", + "Article 19(2)(d)", + "Article 19(3)", + "Article 19(4)", + "Article 19(5)", + "Article 19(6)", + "Article 20(1)", + "Article 20(2)", + "Article 20(2)(a)", + "Article 20(2)(b)", + "Article 20(3)", + "Article 20(4)", + "Article 24(1)", + "Article 30(1)", + "Article 30(2)", + "Article 30(3)", + "Article 30(4)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(1)", + "Annex I, Part I(2)(g)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)", + "Annex I, Part I(2)(m)", + "Annex I, Part II(1)", + "Annex I, Part II(2)" ], "emea-eu-dora-2023": [ "Article 13.7" @@ -525,36 +525,25 @@ "7.8", "7.9", "7.10", - "7.11", "7.12", "7.13", "7.14" ], - "emea-isr-cmo-1-0": [ - "17.9" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" - ], "emea-sau-cscc-1-2019": [ "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], - "emea-sau-otcc-1-2022": [ - "1-1-2", - "4-1-1-1" + "emea-sau-ecc-1-2018": [ + "1-6-3-4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1796", "ISM-1797", "ISM-1798" ], + "apac-aus-cop-sitc-2020": [ + "11" + ], "apac-chn-cybersecurity-law-2017": [ "Article 22", "Article 46", @@ -564,7 +553,13 @@ "14.1.1", "14.2.7.11" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -594,17 +589,16 @@ "12.4.7.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.8.1", - "5.8.2", - "7.6.1", - "7.6.2", - "14.4.1", - "14.4.2", - "14.4.3" + "5.5.2", + "14.1.5", + "14.1.7" ], "americas-can-osfi-b13-2022": [ "2.4.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] diff --git a/docs/api/controls/TDA-01.2.json b/docs/api/controls/TDA-01.2.json index d5be9ddd..a34c3234 100644 --- a/docs/api/controls/TDA-01.2.json +++ b/docs/api/controls/TDA-01.2.json @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize integrity validation mechanisms for security updates.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -76,14 +76,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-nist-800-172": [ - "3.14.1e", - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], diff --git a/docs/api/controls/TDA-01.3.json b/docs/api/controls/TDA-01.3.json index d24f8cbf..e4fd4535 100644 --- a/docs/api/controls/TDA-01.3.json +++ b/docs/api/controls/TDA-01.3.json @@ -3,7 +3,7 @@ "title": "Malware Testing Prior to Release", "family": "TDA", "description": "Mechanisms exist to utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update.", - "scf_question": "Does the organization utilize at least one (1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update?", + "scf_question": "Does the organization utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -71,7 +71,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -84,6 +85,9 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-01.4.json b/docs/api/controls/TDA-01.4.json index 9cf08668..674c2411 100644 --- a/docs/api/controls/TDA-01.4.json +++ b/docs/api/controls/TDA-01.4.json @@ -104,9 +104,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "usa-federal-dow-zt-roadmap-1-1": [ @@ -115,6 +115,12 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-sgp-mas-trm-2021": [ + "6.3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-01.json b/docs/api/controls/TDA-01.json index 36ef818d..d0027efd 100644 --- a/docs/api/controls/TDA-01.json +++ b/docs/api/controls/TDA-01.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -123,7 +123,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -136,7 +137,7 @@ ], "general-cis-csc-8-1": [ "15.7", - "16.0" + "16" ], "general-cis-csc-8-1-ig3": [ "15.7" @@ -206,7 +207,7 @@ "A.6.1.3", "A.6.2.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -303,11 +304,21 @@ "03.17.02" ], "general-nist-800-171a-r3": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", "A.03.16.01.ODP[01]", + "A.03.16.01", "A.03.17.02[04]", "A.03.17.02[05]", "A.03.17.02[06]" ], + "general-nist-800-172-r3": [ + "03.16.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.16.01E" + ], "general-nist-800-218": [ "PO.1", "PO.3", @@ -346,9 +357,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.1" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "1.d", "4.b" @@ -455,8 +463,8 @@ "Article 14.4" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(67)", - "3.6.2(74)" + "3.6.2.67", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 13.7" @@ -471,73 +479,28 @@ "6.2.2(c)", "6.2.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ + "1.2(f)", "7.7", "7.8", "7.9", - "7.10", - "7.11", - "7.12", - "7.13", - "7.14" + "7.10" ], "emea-deu-c5-2020": [ - "DEV-01" - ], - "emea-isr-cmo-1-0": [ - "17.1", - "17.9" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" + "BEI-01" ], "emea-sau-cscc-1-2019": [ - "2-13", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3", - "2-5-4" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.6" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 19.1", - "Article 19.2", - "Article 19.2(a)", - "Article 19.2(b)", - "Article 19.2(c)", - "Article 19.3" + "1-3-2", + "2-13-1" ], "emea-esp-decree-311-2022": [ - "19.1", - "19.2", - "19.2(a)", - "19.2(b)", - "19.2(c)", - "19.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.3 [OP.PL.3]", - "8.6.1 [MP.SW.1]" - ], - "apac-aus-ism-2024-june": [ + "Article 12(6)(g)", + "Article 19(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" + ], + "apac-aus-ism-2026-march": [ "ISM-0938", "ISM-1780" ], @@ -548,7 +511,13 @@ "14.2.1.13.PB", "14.2.7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -556,38 +525,21 @@ "HSUP42" ], "apac-sgp-mas-trm-2021": [ - "5.3.1", - "5.3.2", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" - ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" + "5.3.2" + ], + "americas-arg-ppd-2018": [ + "H" + ], + "americas-bmu-mba-coc-2020": [ + "6.1-BP3" ], "americas-can-osfi-b13-2022": [ "2.4.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3", + "2.4.4" + ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03", diff --git a/docs/api/controls/TDA-02.1.json b/docs/api/controls/TDA-02.1.json index 5546b385..68b9cd50 100644 --- a/docs/api/controls/TDA-02.1.json +++ b/docs/api/controls/TDA-02.1.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to identify early in the Secure Development Life Cycle (SDLC), the functions, ports, protocols and services intended for use.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to identify early in the Secure Development Life Cycle (SDLC), the functions, ports, protocols and services intended for use. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -171,14 +172,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-04 (09)" ], - "emea-isr-cmo-1-0": [ - "12.9", - "12.29" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-5", - "2-15-3-3" - ], "apac-nzl-ism-3-9": [ "18.1.15.C.01", "18.1.15.C.02", diff --git a/docs/api/controls/TDA-02.10.json b/docs/api/controls/TDA-02.10.json index 7c9e13ea..089162a5 100644 --- a/docs/api/controls/TDA-02.10.json +++ b/docs/api/controls/TDA-02.10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for an appropriate level of security and resiliency based on applicable risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,7 +103,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -124,14 +125,15 @@ "SUM-1(2)(b)", "SUM-1(2)(c)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(3)" + "apac-sgp-mas-trm-2021": [ + "5.6.1", + "5.7.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.12" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-02.11.json b/docs/api/controls/TDA-02.11.json index cf6f9e19..e0b2d4c8 100644 --- a/docs/api/controls/TDA-02.11.json +++ b/docs/api/controls/TDA-02.11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to disclose information about vulnerabilities to relevant stakeholders, including:\n(1) A description of the vulnerability(ies);\n(2) Affected product(s) and/or service(s);\n(3) Potential impact of the vulnerability(ies);\n(4) Severity of the vulnerability(ies); and\n(5) Guidance to remediate the vulnerability(ies).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,7 +102,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -111,9 +112,6 @@ "DM-5(a)", "DM-5(b)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-nerc-cip-2024": [ "CIP-013-2 1.2.4" ], @@ -121,15 +119,26 @@ "7123(c)(6)", "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.7" + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(1)", + "Article 14(2)(a)", + "Article 14(2)(b)", + "Article 14(2)(c)", + "Article 14(2)(i)", + "Article 14(2)(i)(ii)", + "Article 14(2)(i)(iii)", + "Article 20(3)", + "Article 20(4)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(4)", - "Annex 1.2(6)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(5)", + "Annex I, Part II(6)" ], "emea-eu-nis2-annex-2024": [ "6.10.2(e)" + ], + "emea-deu-c5-2020": [ + "RB-21-DOAR" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-02.12.json b/docs/api/controls/TDA-02.12.json index a4ef9a14..33a2a059 100644 --- a/docs/api/controls/TDA-02.12.json +++ b/docs/api/controls/TDA-02.12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to categorize applicable security and resiliency requirements for products and/or services with digital elements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -99,49 +99,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 3 Class 1.1", - "Annex 3 Class 1.2", - "Annex 3 Class 1.3", - "Annex 3 Class 1.4", - "Annex 3 Class 1.5", - "Annex 3 Class 1.6", - "Annex 3 Class 1.7", - "Annex 3 Class 1.8", - "Annex 3 Class 1.9", - "Annex 3 Class 1.10", - "Annex 3 Class 1.11", - "Annex 3 Class 1.12", - "Annex 3 Class 1.13", - "Annex 3 Class 1.14", - "Annex 3 Class 1.15", - "Annex 3 Class 1.16", - "Annex 3 Class 1.17", - "Annex 3 Class 1.18", - "Annex 3 Class 1.19", - "Annex 3 Class 1.20", - "Annex 3 Class 1.21", - "Annex 3 Class 1.22", - "Annex 3 Class 1.23", - "Annex 3 Class 2.1", - "Annex 3 Class 2.2", - "Annex 3 Class 2.3", - "Annex 3 Class 2.4", - "Annex 3 Class 2.5", - "Annex 3 Class 2.6", - "Annex 3 Class 2.7", - "Annex 3 Class 2.8", - "Annex 3 Class 2.9", - "Annex 3 Class 2.10", - "Annex 3 Class 2.11", - "Annex 3 Class 2.12", - "Annex 3 Class 2.13", - "Annex 3 Class 2.14", - "Annex 3 Class 2.15" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(1)" + ], + "apac-mys-bnm-rmit-2025": [ + "12.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-02.13.json b/docs/api/controls/TDA-02.13.json index a281fa39..3a4cb84d 100644 --- a/docs/api/controls/TDA-02.13.json +++ b/docs/api/controls/TDA-02.13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to notify applicable stakeholders about potentially exploitable vulnerabilities in organization-developed Technology Assets, Applications and/or Services (TAAS), as required by statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -99,16 +99,14 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)", "7123(c)(14)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-02.14.json b/docs/api/controls/TDA-02.14.json index ed727dba..54748a67 100644 --- a/docs/api/controls/TDA-02.14.json +++ b/docs/api/controls/TDA-02.14.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers to use an industry-defined secure logging format to generate event logs for specified event types at organization-defined level of detail.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79,7 +79,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-02.2.json b/docs/api/controls/TDA-02.2.json index 2132ea20..9a4f995d 100644 --- a/docs/api/controls/TDA-02.2.json +++ b/docs/api/controls/TDA-02.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit the use of commercially-provided Information Assurance (IA) and IA-enabled IT products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile or the cryptographic module is FIPS-validated or NSA-approved.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -52,7 +52,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-02.3.json b/docs/api/controls/TDA-02.3.json index 3a20f177..8e837dae 100644 --- a/docs/api/controls/TDA-02.3.json +++ b/docs/api/controls/TDA-02.3.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -91,7 +91,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -198,9 +199,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "2" ], @@ -229,23 +227,25 @@ "emea-eu-ai-act-2024": [ "Article 14.1" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(74)" + "emea-sau-ecc-1-2018": [ + "1-6-3-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.1 [MP.SW.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" ], - "apac-sgp-mas-trm-2021": [ - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7" + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.14" ], "americas-can-osfi-b13-2022": [ "2.4.3", "2.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3", + "2.4.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] diff --git a/docs/api/controls/TDA-02.4.json b/docs/api/controls/TDA-02.4.json index 7414d865..2a881579 100644 --- a/docs/api/controls/TDA-02.4.json +++ b/docs/api/controls/TDA-02.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure vendors / manufacturers:\n(1) Deliver the Technology Asset, Application and/or Service (TAAS) with a pre-established, secure configuration implemented; and\n(2) Use the pre-established, secure configuration as the default for any subsequent TAAS reinstallation or upgrade.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -113,15 +114,15 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4", "PW.5.1", "PW.9.1", "PW.9.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "1.e" ], @@ -137,15 +138,17 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(a)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(b)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] diff --git a/docs/api/controls/TDA-02.5.json b/docs/api/controls/TDA-02.5.json index 18b26ba5..48823e06 100644 --- a/docs/api/controls/TDA-02.5.json +++ b/docs/api/controls/TDA-02.5.json @@ -19,9 +19,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require process owners to identify, document and justify the business need for the ports, protocols and other services necessary to operate their technology solutions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require process owners to identify, document and justify the business need for the ports, protocols and other services necessary to operate their technology solutions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-02.6.json b/docs/api/controls/TDA-02.6.json index 747eef1c..346c261a 100644 --- a/docs/api/controls/TDA-02.6.json +++ b/docs/api/controls/TDA-02.6.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to mitigate the risk associated with the use of insecure ports, protocols and services necessary to operate technology solutions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to mitigate the risk associated with the use of insecure ports, protocols and services necessary to operate technology solutions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -125,9 +126,6 @@ "1.2.6", "2.2.5" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ] diff --git a/docs/api/controls/TDA-02.7.json b/docs/api/controls/TDA-02.7.json index 759d792e..3588991a 100644 --- a/docs/api/controls/TDA-02.7.json +++ b/docs/api/controls/TDA-02.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to include appropriate security, compliance and resilience representatives in the product feature and/or functionality change control review process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,9 +103,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-iec-62443-4-1-2018": [ @@ -126,17 +126,14 @@ "RV.1", "RV.3.4" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-irs-1075-2021": [ "SA-10(CE-7)" ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-02.8.json b/docs/api/controls/TDA-02.8.json index 5840205b..2684ce64 100644 --- a/docs/api/controls/TDA-02.8.json +++ b/docs/api/controls/TDA-02.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to minimize the attack surface of Technology Assets, Applications and/or Services (TAAS) by reasonably mitigating known exploitable vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -103,19 +103,17 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(2)", - "Annex 1.1(3)(h)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(d)" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-02.9.json b/docs/api/controls/TDA-02.9.json index 281ae77d..b277f710 100644 --- a/docs/api/controls/TDA-02.9.json +++ b/docs/api/controls/TDA-02.9.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to deliver security updates to Technology Assets, Applications and/or Services (TAAS), where applicable, through:\n(1) Automatic updates; and\n(2) Notification of available updates to affected users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -102,7 +102,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -121,20 +122,27 @@ "SUM-5(d)", "SUM-5(e)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.6" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(8)", + "Article 13(9)", + "Article 13(11)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(c)", + "Annex I, Part I(2)(l)", + "Annex I, Part II(2)", + "Annex I, Part II(3)", + "Annex I, Part II(4)", + "Annex I, Part II(5)", + "Annex I, Part II(6)", + "Annex I, Part II(7)", + "Annex I, Part II(8)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(k)", - "Annex 1.2(2)", - "Annex 1.2(7)", - "Annex 1.2(8)" + "emea-deu-bsrit-2017": [ + "7.12" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-02.json b/docs/api/controls/TDA-02.json index a0276c5e..a379ab47 100644 --- a/docs/api/controls/TDA-02.json +++ b/docs/api/controls/TDA-02.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to design, develop and produce Technology Assets, Applications and/or Services (TAAS) in such a way that risk-based technical and functional specifications ensure Minimum Viable Product (MVP) criteria establish an appropriate level of security and resiliency based on applicable risks and threats.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -109,7 +109,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -220,6 +221,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PO.1", "PO.1.1", @@ -296,33 +300,33 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-04" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(1)", - "Annex 1.1(3)(b)", - "Annex 1.1(3)(c)", - "Annex 1.1(3)(d)", - "Annex 1.1(3)(f)", - "Annex 1.1(3)(g)", - "Annex 1.1(3)(i)", - "Annex 6 Module A.3" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" ], "emea-deu-bsrit-2017": [ "7.7" ], - "emea-deu-c5-2020": [ - "DEV-02" - ], "emea-sau-cscc-1-2019": [ "2-13-1", "2-13-2", + "2-13-3", "2-13-3-1", "2-13-3-2", "2-13-3-3", "2-13-3-4" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" + ], + "apac-aus-cop-sitc-2020": [ + "4" + ], "apac-jpn-ismap": [ "14.1.1.2", "14.1.1.3", @@ -337,12 +341,18 @@ "14.1.1.16", "14.2.1.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP31", "HML31" ], "apac-sgp-mas-trm-2021": [ - "5.3.3" + "5.4.3", + "5.5.2" ], "americas-can-itsp-10-171-2025": [ "03.16.01" diff --git a/docs/api/controls/TDA-03.1.json b/docs/api/controls/TDA-03.1.json index 90962718..d5a1f24b 100644 --- a/docs/api/controls/TDA-03.1.json +++ b/docs/api/controls/TDA-03.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to obtain security, compliance and resilience technologies from different suppliers to minimize supply chain risk.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -78,9 +78,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-nist-800-53-r4": [ @@ -113,6 +113,12 @@ "PL-8(2)", "SR-3(1)" ], + "general-nist-800-172-r3": [ + "03.15.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.03E" + ], "usa-federal-gsa-fedramp-5-low": [ "SR-03(01)" ], diff --git a/docs/api/controls/TDA-03.json b/docs/api/controls/TDA-03.json index 23c8bb64..30096048 100644 --- a/docs/api/controls/TDA-03.json +++ b/docs/api/controls/TDA-03.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, custom-develops business-critical TAAS, when Commercial Off The Shelf (COTS) solutions are unavailable.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize only Commercial Off-the-Shelf (COTS) security products.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize only Commercial Off-the-Shelf (COTS) security products. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -55,7 +55,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -76,6 +77,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4", "PW.4.1" @@ -83,10 +87,6 @@ "general-sparta": [ "CM0007" ], - "apac-sgp-mas-trm-2021": [ - "5.3.3", - "6.1.3" - ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] diff --git a/docs/api/controls/TDA-04.1.json b/docs/api/controls/TDA-04.1.json index 7e323853..da02e09a 100644 --- a/docs/api/controls/TDA-04.1.json +++ b/docs/api/controls/TDA-04.1.json @@ -21,9 +21,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78,9 +78,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-govramp": [ @@ -196,17 +196,11 @@ "SA-04 (01)", "SA-04 (02)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(7)", + "Article 31(1)" ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6", - "17.10" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ] } diff --git a/docs/api/controls/TDA-04.2.json b/docs/api/controls/TDA-04.2.json index ce73a635..57e499c3 100644 --- a/docs/api/controls/TDA-04.2.json +++ b/docs/api/controls/TDA-04.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate, or obtain, a Software Bill of Materials (SBOM) for Technology Assets, Applications and/or Services (TAAS) that lists software packages in use, including versions and applicable licenses.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -145,22 +146,23 @@ "4e(iii)", "4e(vii)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.7" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(1)", - "Annex 1.2(6)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(1)" ], "emea-sau-cgiot-2024": [ "4-1-3" ], - "apac-aus-ism-2024-june": [ - "ISM-1730" + "apac-aus-ism-2026-march": [ + "ISM-1730", + "ISM-2054", + "ISM-2056" ], "apac-ind-sebi-2024": [ "GV.SC.S5", "PR.IP.S5" + ], + "apac-mys-bnm-rmit-2025": [ + "10.15" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-04.json b/docs/api/controls/TDA-04.json index 4b7e8db3..fb29769d 100644 --- a/docs/api/controls/TDA-04.json +++ b/docs/api/controls/TDA-04.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to obtain, protect and distribute administrator documentation for Technology Assets, Applications and/or Services (TAAS) that describe:\n(1) Secure configuration, installation and operation of the TAAS;\n(2) Effective use and maintenance of security features/functions; and\n(3) Known vulnerabilities regarding configuration and use of administrative (e.g., privileged) functions.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -268,22 +269,25 @@ "emea-eu-ai-act-2024": [ "Article 11.1" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(4)", + "Article 13(7)", + "Article 31(1)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(73)" + "3.6.2.73" ], "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6", - "17.10" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" + "UP-01", + "KOS-07" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ], + "apac-aus-cop-sitc-2020": [ + "11", + "12" + ], "apac-jpn-ismap": [ "14.1.1.15", "14.2.7.10" @@ -291,9 +295,6 @@ "apac-nzl-ism-3-9": [ "3.4.10.C.01", "3.4.10.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.4" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-05.1.json b/docs/api/controls/TDA-05.1.json index 9fd3c96a..7e533984 100644 --- a/docs/api/controls/TDA-05.1.json +++ b/docs/api/controls/TDA-05.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to secure physical diagnostic and test interfaces to prevent misuse.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-05.2.json b/docs/api/controls/TDA-05.2.json index 2b6a6f17..5388ef2b 100644 --- a/docs/api/controls/TDA-05.2.json +++ b/docs/api/controls/TDA-05.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to enable endpoint devices to log events and generate alerts for attempts to access diagnostic and test interfaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-05.json b/docs/api/controls/TDA-05.json index e21b3949..797d952f 100644 --- a/docs/api/controls/TDA-05.json +++ b/docs/api/controls/TDA-05.json @@ -3,7 +3,7 @@ "title": "Developer Architecture & Design", "family": "TDA", "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", - "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection?", + "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of its security architecture which is established within and is an integrated part of its enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -117,19 +117,22 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.1", + "16.10" ], "general-govramp": [ "SA-17" @@ -161,7 +164,7 @@ "8.27", "8.30" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -202,6 +205,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4.2", "RV.1.1" @@ -240,35 +246,9 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3-4" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "apac-aus-ism-2026-march": [ + "ISM-2033", + "ISM-2043" ], "americas-can-itsp-10-171-2025": [ "03.16.01" diff --git a/docs/api/controls/TDA-06.1.json b/docs/api/controls/TDA-06.1.json index 7dec47d3..e87bb5ce 100644 --- a/docs/api/controls/TDA-06.1.json +++ b/docs/api/controls/TDA-06.1.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developer of the Technology Asset, Application and/or Service (TAAS) to perform a criticality analysis at organization-defined decision points in the Secure Development Life Cycle (SDLC).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -72,9 +72,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -89,7 +89,7 @@ "general-iso-27018-2025": [ "8.29" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1495", "T1542", @@ -157,15 +157,18 @@ "RA-9", "SA-15(3)" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[01]" + ], "general-nist-800-218": [ "PW.1" ], "general-nist-csf-2-0": [ "PR.PS-06" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-sparta": [ "CM0022" ], @@ -210,11 +213,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.2" ], "apac-nzl-ism-3-9": [ "14.4.6.C.01", diff --git a/docs/api/controls/TDA-06.2.json b/docs/api/controls/TDA-06.2.json index dcd0f4a6..7318aa1e 100644 --- a/docs/api/controls/TDA-06.2.json +++ b/docs/api/controls/TDA-06.2.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform threat modelling and other secure design techniques, to ensure that threats to software and solutions are identified and accounted for.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -222,18 +223,22 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], "emea-sau-cgiot-2024": [ "2-12-1" ], - "apac-aus-ism-2024-june": [ - "ISM-1238" + "apac-aus-ism-2026-march": [ + "ISM-1238", + "ISM-2039" + ], + "apac-aus-ps-cps-230-2023": [ + "27(c)" ], "apac-jpn-ismap": [ "14.2.7.3" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], "apac-nzl-ism-3-9": [ "14.4.6.C.01", "14.4.6.C.02", @@ -242,6 +247,9 @@ "americas-can-osfi-b13-2022": [ "2.4.4", "3.1.6" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-06.3.json b/docs/api/controls/TDA-06.3.json index 8e9c5b22..8f9b730d 100644 --- a/docs/api/controls/TDA-06.3.json +++ b/docs/api/controls/TDA-06.3.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a Software Assurance Maturity Model (SAMM) to govern a secure development lifecycle for the development of Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -141,29 +142,10 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.1 [MP.SW.1]" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.1", - "6.1.2", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3", - "7.6.1", - "7.6.2" + "apac-aus-ism-2026-march": [ + "ISM-2025", + "ISM-2034", + "ISM-2102" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-06.4.json b/docs/api/controls/TDA-06.4.json index 780b184d..2cc2d883 100644 --- a/docs/api/controls/TDA-06.4.json +++ b/docs/api/controls/TDA-06.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically improve the accuracy, consistency and comprehensiveness of secure practices throughout the asset's lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57,7 +57,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -76,6 +77,9 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2031" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-06.5.json b/docs/api/controls/TDA-06.5.json index 81808797..a5179419 100644 --- a/docs/api/controls/TDA-06.5.json +++ b/docs/api/controls/TDA-06.5.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -63,9 +63,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ @@ -101,9 +101,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.3" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0043" ], @@ -116,24 +113,9 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.8(a)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], "emea-sau-cgiot-2024": [ "2-14-3" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.2 [MP.SW.2]" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.4", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.6", - "6.1.7" - ], "americas-can-osfi-b13-2022": [ "2.4.1", "2.4.2" diff --git a/docs/api/controls/TDA-06.6.json b/docs/api/controls/TDA-06.6.json index ad675fb9..67c51e85 100644 --- a/docs/api/controls/TDA-06.6.json +++ b/docs/api/controls/TDA-06.6.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57,7 +57,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -85,6 +86,9 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-aus-ism-2026-march": [ + "ISM-1909" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-06.7.json b/docs/api/controls/TDA-06.7.json new file mode 100644 index 00000000..21cb8fd1 --- /dev/null +++ b/docs/api/controls/TDA-06.7.json @@ -0,0 +1,101 @@ +{ + "control_id": "TDA-06.7", + "title": "Programming Language Selection", + "family": "TDA", + "description": "Mechanisms exist to:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions.", + "scf_question": "Does the organization:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Document approved programming languages for internal development\n∙ Prefer memory-safe languages for security-sensitive code (e.g., Rust, Go, Python)", + "small": "∙ Approved programming language list\n∙ Memory-safe language preference for new development\n∙ Documented justification for language choices", + "medium": "∙ Formal programming language governance standard\n∙ Memory-safe language requirements for security-critical code\n∙ Language selection approval process", + "large": "∙ Enterprise programming language governance program\n∙ Enforcement of approved languages in CI/CD\n∙ Security-focused language selection criteria (e.g., CISA memory safety guidance)", + "enterprise": "∙ Enterprise programming language governance with automated enforcement\n∙ CISA Memory Safe Roadmap alignment\n∙ Automated language compliance checking in CI/CD pipeline\n∙ Developer training on approved languages" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2040", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "emea-deu-c5-2020": [ + "BEI-01-BP3" + ], + "apac-aus-ism-2026-march": [ + "ISM-2040", + "ISM-2041" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/TDA-06.json b/docs/api/controls/TDA-06.json index fff884d0..adf75160 100644 --- a/docs/api/controls/TDA-06.json +++ b/docs/api/controls/TDA-06.json @@ -19,11 +19,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to develop applications based on Secure Software Development Practices (SSDP).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -121,19 +122,22 @@ "PI1.5-POF4" ], "general-cis-csc-8-1": [ - "16.0", + "16", "16.1", "16.5", + "16.10", "16.11" ], "general-cis-csc-8-1-ig2": [ "16.1", "16.5", + "16.10", "16.11" ], "general-cis-csc-8-1-ig3": [ "16.1", "16.5", + "16.10", "16.11" ], "general-cobit-2019": [ @@ -208,7 +212,7 @@ "A.6.1.3", "A.6.2.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -297,6 +301,9 @@ "3.13.2[b]", "3.13.2[e]" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PO.1", "PW.1", @@ -344,10 +351,6 @@ "6.2.1", "6.2.4" ], - "general-scf-dpmp-2025": [ - "5.12", - "7.1" - ], "general-sparta": [ "CM0017", "CM0043" @@ -431,8 +434,16 @@ "SA-03", "SA-15" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)" ], "emea-eu-nis2-2022": [ "Article 21.3" @@ -445,25 +456,16 @@ "7.10" ], "emea-deu-c5-2020": [ - "DEV-02", - "DEV-07", - "DEV-08" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.6", - "17.9", - "17.20", - "17.25" + "UP-01-BP2", + "BEI-01-BP1", + "BEI-01-BP4", + "BEI-01-DOAR", + "BEI-02" ], "emea-sau-cscc-1-2019": [ "1-3-2-3", "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-cgiot-2024": [ "2-14-3" @@ -472,17 +474,47 @@ "1-6-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-60", - "TPC-62" + "VII.B.TPC-74" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.6.4", + "3.3.6.5", + "3.3.6.5.a", + "3.3.6.5.b", + "3.3.6.5.c", + "3.3.6.5.d", + "3.3.6.5.e", + "3.3.6.5.f", + "3.3.6.5.g" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.info.4", + "mp.s.2" ], "emea-gbr-caf-4-0": [ "A4.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0401", "ISM-1239", "ISM-1419", - "ISM-1552" + "ISM-1552", + "ISM-1849", + "ISM-1922", + "ISM-2032", + "ISM-2035", + "ISM-2041", + "ISM-2045", + "ISM-2063", + "ISM-2064", + "ISM-2065", + "ISM-2066", + "ISM-2067" + ], + "apac-aus-cop-sitc-2020": [ + "4", + "6" ], "apac-jpn-ismap": [ "14.1.1.1", @@ -490,7 +522,7 @@ "14.2.1.9", "14.2.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -501,35 +533,21 @@ "14.4.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.3.2", "6.1.1", "6.1.2", "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "6.2.2" ], "americas-bmu-mba-coc-2020": [ "6.20" ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" - ], "americas-can-osfi-b13-2022": [ "2.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.2", + "2.4.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] diff --git a/docs/api/controls/TDA-07.json b/docs/api/controls/TDA-07.json index 790283af..7f0191bb 100644 --- a/docs/api/controls/TDA-07.json +++ b/docs/api/controls/TDA-07.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a segmented development network to ensure a secure development environment.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a segmented development network to ensure a secure development environment. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -188,30 +189,22 @@ "7123(c)(14)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(72)" + "3.6.2.72" ], "emea-eu-nis2-annex-2024": [ "6.2.2(c)", "6.8.2(h)" ], - "emea-deu-c5-2020": [ - "DEV-02", - "DEV-10" - ], - "emea-isr-cmo-1-0": [ - "10.1" - ], "emea-sau-cscc-1-2019": [ "1-3-2-4" ], "emea-sau-otcc-1-2022": [ "1-4-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0400", "ISM-1419" ], @@ -231,6 +224,9 @@ "14.2.6.11", "14.2.6.12" ], + "apac-mys-bnm-rmit-2025": [ + "10.7" + ], "apac-nzl-ism-3-9": [ "14.4.4.C.01" ], diff --git a/docs/api/controls/TDA-08.1.json b/docs/api/controls/TDA-08.1.json index f4399252..db52b858 100644 --- a/docs/api/controls/TDA-08.1.json +++ b/docs/api/controls/TDA-08.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure secure migration practices purge Technology Assets, Applications and/or Services (TAAS) of test/development/staging data and accounts before it is migrated into a production environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79,7 +79,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-08.json b/docs/api/controls/TDA-08.json index a985dca7..7627008c 100644 --- a/docs/api/controls/TDA-08.json +++ b/docs/api/controls/TDA-08.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -112,7 +112,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -222,14 +223,11 @@ "7123(c)(14)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(72)" + "3.6.2.72" ], "emea-deu-c5-2020": [ - "DEV-10" - ], - "emea-isr-cmo-1-0": [ - "10.1" + "BEI-01-BP2", + "BEI-11" ], "emea-sau-cscc-1-2019": [ "1-3-2-4" @@ -237,13 +235,13 @@ "emea-sau-ecc-1-2018": [ "2-5-3-2" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-4" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.g" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0400", "ISM-1273", "ISM-1274" @@ -263,15 +261,30 @@ "12.1.4.8", "12.1.4.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.7", + "10.26", + "10.28" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP58", "HML58" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP50" ], + "apac-nzl-ism-3-9": [ + "20.2.14.C.06" + ], "apac-sgp-mas-trm-2021": [ "5.7.3" + ], + "americas-arg-ppd-2018": [ + "E.1.2-4" + ], + "americas-bmu-mba-coc-2020": [ + "6.20-BP2", + "6.20-BP3" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-09.1.json b/docs/api/controls/TDA-09.1.json index d7647375..d77da6fe 100644 --- a/docs/api/controls/TDA-09.1.json +++ b/docs/api/controls/TDA-09.1.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a plan for the continuous monitoring of security, compliance and/or resilience control effectiveness.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a plan for the continuous monitoring of security, compliance and/or resilience control effectiveness. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -102,9 +102,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ @@ -146,6 +146,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-800-218": [ "RV.1" ], @@ -168,14 +171,6 @@ "usa-federal-irs-1075-2021": [ "SA-4(CE-8)" ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.4", - "17.12" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.4" - ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] diff --git a/docs/api/controls/TDA-09.2.json b/docs/api/controls/TDA-09.2.json index 594af553..0c239977 100644 --- a/docs/api/controls/TDA-09.2.json +++ b/docs/api/controls/TDA-09.2.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Developers of TAAS are required to employ static code analysis tools to identify and remediate common flaws, documenting the results of the analysis before the application is cleared for production usage.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ static code analysis tools to identify and remediate common flaws and document the results of the analysis.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ static code analysis tools to identify and remediate common flaws and document the results of the analysis. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -76,7 +76,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -187,24 +188,15 @@ "SA-11(1)-IS.1", "SA-11(1)-IS.2" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.14" - ], "emea-sau-cscc-1-2019": [ "1-3-2-1" ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2028" ], "apac-sgp-mas-trm-2021": [ "6.1.6" diff --git a/docs/api/controls/TDA-09.3.json b/docs/api/controls/TDA-09.3.json index e3b24e61..0eb3a1d7 100644 --- a/docs/api/controls/TDA-09.3.json +++ b/docs/api/controls/TDA-09.3.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Developers of TAAS are to employ dynamic code analysis tools to identify and remediate common flaws, documenting the results of the analysis before the application is cleared for production usage.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ dynamic code analysis tools to identify and remediate common flaws and document the results of the analysis.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ dynamic code analysis tools to identify and remediate common flaws and document the results of the analysis. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -158,30 +159,27 @@ "usa-federal-eo-14028": [ "4e(iv)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.19" - ], "emea-sau-cscc-1-2019": [ "1-3-2-1" ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2028" ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-mys-bnm-rmit-2025": [ + "10.14" ], "apac-sgp-mas-trm-2021": [ "6.1.6" ], "americas-can-osfi-b13-2022": [ "3.2.9" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-09.4.json b/docs/api/controls/TDA-09.4.json index 72330054..8cf316c1 100644 --- a/docs/api/controls/TDA-09.4.json +++ b/docs/api/controls/TDA-09.4.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, implements a process to check the validity of information inputs.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize testing methods to ensure Technology Assets, Applications and/or Services (TAAS) continue to operate as intended when subject to invalid or unexpected inputs on its interfaces.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -141,21 +142,12 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.24" - ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2057" ], "apac-nzl-ism-3-9": [ "14.5.6.C.01" diff --git a/docs/api/controls/TDA-09.5.json b/docs/api/controls/TDA-09.5.json index 42e647e6..6f3405bb 100644 --- a/docs/api/controls/TDA-09.5.json +++ b/docs/api/controls/TDA-09.5.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform application-level penetration testing of custom-made Technology Assets, Applications and/or Services (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -185,29 +186,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.3", - "17.15", - "17.17" - ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402" ], "apac-nzl-ism-3-9": [ "14.5.6.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-09.6.json b/docs/api/controls/TDA-09.6.json index b85230cf..5e1481c5 100644 --- a/docs/api/controls/TDA-09.6.json +++ b/docs/api/controls/TDA-09.6.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement secure configuration settings by default to reduce the likelihood of Technology Assets, Applications and/or Services (TAAS) being deployed with weak security settings that would put the TAAS at a greater risk of compromise.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -124,11 +125,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.8(a)" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-3" + "apac-aus-ism-2026-march": [ + "ISM-0383", + "ISM-2042", + "ISM-2044" ], - "apac-aus-ism-2024-june": [ - "ISM-0383" + "apac-aus-cop-sitc-2020": [ + "4" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-09.7.json b/docs/api/controls/TDA-09.7.json index e8e91ee9..37b13bc0 100644 --- a/docs/api/controls/TDA-09.7.json +++ b/docs/api/controls/TDA-09.7.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ a manual code review process to identify and remediate unique flaws that require knowledge of the application’s requirements and design.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-09.json b/docs/api/controls/TDA-09.json index bcf3757a..7dff00d6 100644 --- a/docs/api/controls/TDA-09.json +++ b/docs/api/controls/TDA-09.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers/integrators consult with security, compliance and/or resilience personnel to: \n(1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability;\n(2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the control testing and evaluation process; and\n(3) Document the results.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96,9 +96,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -211,7 +211,7 @@ "8.29", "8.30" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -306,6 +306,12 @@ "03.12.03", "03.14.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], "general-nist-800-218": [ "PO.4", "PO.4.1", @@ -366,11 +372,6 @@ "6.2.4", "6.5.6" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.11", - "7.12" - ], "general-ul-2900-1-2017": [ "12.3", "12.3(a)", @@ -474,11 +475,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-11" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(70)", - "3.6.2(71)" - ], "emea-eu-nis2-annex-2024": [ "6.2.2(d)", "6.5.1" @@ -488,42 +484,27 @@ "7.8", "7.9", "7.10", - "7.11", - "7.12", - "7.13", - "7.14" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.3", - "17.4", - "17.12", - "17.15" + "7.12" ], "emea-sau-cscc-1-2019": [ - "1-3-1-1", "1-3-2-1" ], "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-3-4", "1-6-3-3" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.2 [MP.SW.2]" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402", - "ISM-1754" + "ISM-1754", + "ISM-1850", + "ISM-1851", + "ISM-2057", + "ISM-2060", + "ISM-2061", + "ISM-2062" ], "apac-ind-sebi-2024": [ "PR.IP.S6" @@ -538,27 +519,24 @@ "14.2.8.2", "14.2.8.3" ], + "apac-mys-bnm-rmit-2025": [ + "10.10" + ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2", - "5.7.3", "5.7.4", "5.7.5", - "5.7.6", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", "6.1.6", "6.1.7" ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" + "americas-bmu-mba-coc-2020": [ + "6.20-BP1" ], "americas-can-osfi-b13-2022": [ "3.2.9" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.9" + ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03", diff --git a/docs/api/controls/TDA-10.1.json b/docs/api/controls/TDA-10.1.json index a66c0c85..553fba0e 100644 --- a/docs/api/controls/TDA-10.1.json +++ b/docs/api/controls/TDA-10.1.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure the integrity of test data through existing security, compliance and resilience controls.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -66,15 +66,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "emea-eu-nis2-annex-2024": [ "6.2.2(e)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402" ] } diff --git a/docs/api/controls/TDA-10.json b/docs/api/controls/TDA-10.json index e8462ed4..5da1ca7b 100644 --- a/docs/api/controls/TDA-10.json +++ b/docs/api/controls/TDA-10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to approve, document and control the use of live data in development and test environments.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -69,7 +69,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -117,10 +118,7 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(f)" ], - "emea-isr-cmo-1-0": [ - "10.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1420" ], "apac-jpn-ismap": [ @@ -132,9 +130,6 @@ "14.3.1.4", "14.3.1.5", "14.3.1.6" - ], - "apac-sgp-mas-trm-2021": [ - "11.1.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-11.1.json b/docs/api/controls/TDA-11.1.json index 8ab2956b..eacd9ba5 100644 --- a/docs/api/controls/TDA-11.1.json +++ b/docs/api/controls/TDA-11.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to train personnel to detect counterfeit system components, including hardware, software and firmware.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to train personnel to detect counterfeit system components, including hardware, software and firmware. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -123,6 +124,12 @@ "general-nist-800-161-r1-level-3": [ "SR-11(1)" ], + "general-nist-800-172-r3": [ + "03.02.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.04E" + ], "general-sparta": [ "CM0024" ], @@ -140,9 +147,6 @@ ], "usa-federal-irs-1075-2021": [ "SR-11(CE-1)" - ], - "emea-isr-cmo-1-0": [ - "17.21" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-11.2.json b/docs/api/controls/TDA-11.2.json index da33140c..cfb50c4e 100644 --- a/docs/api/controls/TDA-11.2.json +++ b/docs/api/controls/TDA-11.2.json @@ -8,7 +8,7 @@ "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "N/A", - "nist_csf_function": "Protect", + "nist_csf_function": "N/A", "scrm_focus": { "strategic": false, "operational": false, @@ -18,7 +18,7 @@ "0": "N/A", "1": "N/A", "2": "N/A", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ [deprecated - incorporated into AST-09]\nAn implemented and operational capability exists to dispose of system components using organization-defined techniques and methods to prevent such components from entering the gray market.", + "3": "N/A", "4": "N/A", "5": "N/A" }, diff --git a/docs/api/controls/TDA-11.json b/docs/api/controls/TDA-11.json index 6403df2a..3180868f 100644 --- a/docs/api/controls/TDA-11.json +++ b/docs/api/controls/TDA-11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain awareness of component authenticity by developing and implementing Product Tampering and Counterfeiting (PTC) practices that include the means to detect and prevent counterfeit components.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -101,7 +102,7 @@ "general-cis-csc-8-1-ig3": [ "16.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1059.002", "T1195", "T1195.001", @@ -187,6 +188,19 @@ "SR-11", "SR-11(3)" ], + "general-nist-800-172-r3": [ + "03.17.02E", + "03.17.03E", + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.02E.ODP[04]", + "DS-A.03.17.03E.b", + "A.03.17.03E.ODP[01]", + "DS-A.03.17.05E[01]", + "A.03.17.05E.ODP[01]", + "DS-A.03.17.05E[02]" + ], "general-sparta": [ "CM0024", "CM0028" @@ -214,10 +228,7 @@ "SR-10", "SR-11" ], - "emea-isr-cmo-1-0": [ - "17.21" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1790", "ISM-1791", "ISM-1792" diff --git a/docs/api/controls/TDA-12.json b/docs/api/controls/TDA-12.json index cf802410..c682c9cc 100644 --- a/docs/api/controls/TDA-12.json +++ b/docs/api/controls/TDA-12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-13.1.json b/docs/api/controls/TDA-13.1.json new file mode 100644 index 00000000..2a817274 --- /dev/null +++ b/docs/api/controls/TDA-13.1.json @@ -0,0 +1,96 @@ +{ + "control_id": "TDA-13.1", + "title": "Developer Knowledge & Skills Register", + "family": "TDA", + "description": "Mechanisms exist to maintain a cybersecurity knowledge and skills register for developers.", + "scf_question": "Does the organization maintain a cybersecurity knowledge and skills register for developers?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a cybersecurity knowledge and skills register for developers.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Note: Formal developer skills register typically not required at this size\n∙ Track relevant security certifications for development staff", + "small": "∙ Simple skills inventory for development team security knowledge\n∙ Track SSDP training completion", + "medium": "∙ Developer cybersecurity skills register\n∙ Skills gap analysis against SSDP requirements\n∙ Integration with HR and training records", + "large": "∙ Formal developer security knowledge and skills register\n∙ Annual skills assessment and gap analysis\n∙ Integration with training and professional development program", + "enterprise": "∙ Enterprise developer security skills management program\n∙ Automated skills tracking in HR platform\n∙ Skills gap analysis tied to learning pathways\n∙ Integration with workforce planning" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2039", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2038" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/TDA-13.2.json b/docs/api/controls/TDA-13.2.json new file mode 100644 index 00000000..204c873b --- /dev/null +++ b/docs/api/controls/TDA-13.2.json @@ -0,0 +1,96 @@ +{ + "control_id": "TDA-13.2", + "title": "Developer Training", + "family": "TDA", + "description": "Mechanisms exist to ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP).", + "scf_question": "Does the organization ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "People", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP).", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Free OWASP and SANS resources for developer security training.\n∙ Online SSDP training (e.g., Secure Code Warrior free tier)", + "small": "∙ OWASP resources and Secure Code Warrior free tier (https://securecodewarrior.com)\n∙ Annual developer security training requirement", + "medium": "∙ Secure coding training platform (e.g., Secure Code Warrior, Snyk Learn)\n∙ Role-based training for developers on SSDP\n∙ Annual required training completion", + "large": "∙ Enterprise secure coding training platform (e.g., Secure Code Warrior)\n∙ Mandatory annual training tied to developer roles\n∙ Training effectiveness measurement", + "enterprise": "∙ Enterprise developer security training program\n∙ Role-based SSDP training with LMS integration\n∙ Secure Code Warrior or equivalent at scale\n∙ Skills-gap based personalized learning paths" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2038", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2037" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/TDA-13.json b/docs/api/controls/TDA-13.json index 7ce8bca4..f1a71ce6 100644 --- a/docs/api/controls/TDA-13.json +++ b/docs/api/controls/TDA-13.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -137,9 +138,6 @@ ], "emea-eu-nis2-annex-2024": [ "10.2.1" - ], - "emea-deu-c5-2020": [ - "DEV-02" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-14.1.json b/docs/api/controls/TDA-14.1.json index 0852bb14..edd98316 100644 --- a/docs/api/controls/TDA-14.1.json +++ b/docs/api/controls/TDA-14.1.json @@ -21,11 +21,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of software and firmware components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of software and firmware components. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -125,9 +126,6 @@ "general-nist-800-82-r3": [ "SA-10(01)" ], - "general-nist-800-172": [ - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -148,9 +146,6 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.1(c)" - ], - "emea-isr-cmo-1-0": [ - "17.20" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-14.2.json b/docs/api/controls/TDA-14.2.json index 7d511de1..00fe50d3 100644 --- a/docs/api/controls/TDA-14.2.json +++ b/docs/api/controls/TDA-14.2.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -101,9 +102,6 @@ "general-nist-800-82-r3": [ "SA-10(03)" ], - "general-nist-800-172": [ - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], diff --git a/docs/api/controls/TDA-14.json b/docs/api/controls/TDA-14.json index 3aa49e91..f1201e75 100644 --- a/docs/api/controls/TDA-14.json +++ b/docs/api/controls/TDA-14.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to perform configuration management during system design, development, implementation and operation.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -98,7 +98,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -132,7 +133,7 @@ "8.30", "8.32" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1072", "T1078", "T1078.001", @@ -223,11 +224,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-10" ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-15.json b/docs/api/controls/TDA-15.json index fa3dc69a..03c7dd9c 100644 --- a/docs/api/controls/TDA-15.json +++ b/docs/api/controls/TDA-15.json @@ -3,7 +3,7 @@ "title": "Developer Threat Analysis & Flaw Remediation", "family": "TDA", "description": "Mechanisms exist to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", - "scf_question": "Does the organization require system developers and integrators to create a Security Testing and Evaluation (ST&E) plan and implement the plan under the witness of an independent party?", + "scf_question": "Does the organization require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -254,32 +255,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)", - "3.6.2(69)", - "3.6.2(70)" - ], "emea-eu-nis2-2022": [ "Article 21.4" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.13" - ], - "emea-sau-cscc-1-2019": [ - "1-3-2-1" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-3-4" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.6" - ], - "amaericas-can-osfi-self-assessment": [ - "2.7" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-16.json b/docs/api/controls/TDA-16.json index 0a467d71..53e58806 100644 --- a/docs/api/controls/TDA-16.json +++ b/docs/api/controls/TDA-16.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -80,7 +80,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -99,7 +100,7 @@ "general-govramp-high": [ "SA-16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078.001", "T1078.003", "T1574.002" @@ -130,9 +131,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SA-16" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-17.1.json b/docs/api/controls/TDA-17.1.json index 9ced3cf9..b28bdc1a 100644 --- a/docs/api/controls/TDA-17.1.json +++ b/docs/api/controls/TDA-17.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS). ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,7 +95,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -180,9 +181,6 @@ "emea-eu-dora-2023": [ "Article 28.8 (end)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.3 [OP.EXT.3]" - ], "americas-can-itsp-10-171-2025": [ "03.16.02.B" ] diff --git a/docs/api/controls/TDA-17.json b/docs/api/controls/TDA-17.json index 6ebe51f8..3e74a068 100644 --- a/docs/api/controls/TDA-17.json +++ b/docs/api/controls/TDA-17.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, provides in-house support or contract external providers for support with unsupported system components.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -98,7 +98,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -114,7 +115,7 @@ "general-cis-csc-8-1-ig3": [ "2.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1189", "T1195", "T1195.001", @@ -177,9 +178,6 @@ "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "7.5" - ], "usa-federal-fbi-cjis-6-0": [ "SA-22" ], @@ -215,8 +213,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-22" ], - "emea-isr-cmo-1-0": [ - "12.23" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-51" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "3-BP2" ], "apac-aus-essential-8-2024": [ "ML1-P1", @@ -226,13 +227,22 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0304", "ISM-1501", "ISM-1704", - "ISM-1753" + "ISM-1753", + "ISM-1848", + "ISM-1981", + "ISM-1982" + ], + "apac-aus-cop-sitc-2020": [ + "3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP43", "HML43" ], @@ -241,16 +251,17 @@ ], "apac-sgp-mas-trm-2021": [ "7.3.1", - "7.3.2", "7.3.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.6", - "4.9" + "americas-bmu-mba-coc-2020": [ + "6.16" ], "americas-can-osfi-b13-2022": [ "2.2.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.02.A" ] diff --git a/docs/api/controls/TDA-18.json b/docs/api/controls/TDA-18.json index 69246c80..3e84ee58 100644 --- a/docs/api/controls/TDA-18.json +++ b/docs/api/controls/TDA-18.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to check the validity of information inputs.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to check the validity of information inputs. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -143,7 +144,7 @@ "general-iec-62443-4-2-2019": [ "CR 3.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.002", "T1021.005", "T1027.010", @@ -369,6 +370,13 @@ "SI-5", "SI-7" ], + "general-nist-800-172-r3": [ + "03.14.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.12E", + "A.03.14.12E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A08:2025" ], @@ -470,11 +478,11 @@ "SI-07", "SI-10" ], - "emea-isr-cmo-1-0": [ - "17.22" - ], "emea-sau-sacs-002-2022": [ - "TPC-60" + "VII.B.TPC-60" + ], + "apac-aus-ism-2026-march": [ + "ISM-2059" ], "apac-jpn-ismap": [ "14.2.5.9" diff --git a/docs/api/controls/TDA-19.1.json b/docs/api/controls/TDA-19.1.json new file mode 100644 index 00000000..b1831ed2 --- /dev/null +++ b/docs/api/controls/TDA-19.1.json @@ -0,0 +1,90 @@ +{ + "control_id": "TDA-19.1", + "title": "Designated Roles To View Error Messages", + "family": "TDA", + "description": "Mechanisms exist to:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s).", + "scf_question": "Does the organization:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s)?", + "relative_weight": 6, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Configure error messages to suppress technical details from end users\n∙ Role-based access to application error logs", + "small": "∙ Application configuration to display generic errors to end users\n∙ Technical error details restricted to authorized administrators", + "medium": "∙ Error message configuration standards\n∙ Role-based access to error logs and detailed messages\n∙ Centralized log management with access controls", + "large": "∙ Enterprise error message governance standard\n∙ Role-based log access controls\n∙ Automated testing for information disclosure via error messages", + "enterprise": "∙ Enterprise error handling standard with automated enforcement\n∙ Centralized SIEM with role-based log access\n∙ Automated security testing for error message information disclosure\n∙ Integration with code review and CI/CD security gates" + }, + "risks": [ + "R-AC-3", + "R-AC-4", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "general-nist-800-172a-r3": [ + "A.03.14.13E.ODP[01]" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-61" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/TDA-19.json b/docs/api/controls/TDA-19.json index f6ce5d79..a2a3153e 100644 --- a/docs/api/controls/TDA-19.json +++ b/docs/api/controls/TDA-19.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to handle error conditions by: \n(1) Identifying potentially security-relevant error conditions;\n(2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n(3) Revealing error messages only to authorized personnel.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -113,6 +114,13 @@ "general-nist-800-82-r3-high": [ "SI-11" ], + "general-nist-800-172-r3": [ + "03.14.13E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.13E.a", + "DS-A.03.14.13E.b" + ], "general-owasp-top-10-2025": [ "A08:2025", "A10:2025" @@ -137,14 +145,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "SI-11" ], - "emea-deu-c5-2020": [ - "PSS-04" - ], - "emea-isr-cmo-1-0": [ - "17.23" - ], "emea-sau-sacs-002-2022": [ - "TPC-61" + "VII.B.TPC-61" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-20.1.json b/docs/api/controls/TDA-20.1.json index a7592b9c..a1bf8657 100644 --- a/docs/api/controls/TDA-20.1.json +++ b/docs/api/controls/TDA-20.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to publish integrity verification information for software releases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-20.2.json b/docs/api/controls/TDA-20.2.json index e60ea253..20f2cace 100644 --- a/docs/api/controls/TDA-20.2.json +++ b/docs/api/controls/TDA-20.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to archive software releases and all of their components (e.g., code, package files, third-party libraries, documentation) to maintain integrity verification information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -80,6 +81,9 @@ "general-nist-800-218": [ "PS.3", "PS.3.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-20.3.json b/docs/api/controls/TDA-20.3.json index d446face..66cadf43 100644 --- a/docs/api/controls/TDA-20.3.json +++ b/docs/api/controls/TDA-20.3.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to escrow source code and supporting documentation to ensure software availability in the event the software provider goes out of business or is unable to provide support.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to escrow source code and supporting documentation to ensure software availability in the event the software provider goes out of business or is unable to provide support. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -58,7 +58,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -77,6 +78,9 @@ "apac-jpn-ismap": [ "14.2.7.8" ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], "apac-sgp-mas-trm-2021": [ "5.3.4" ] diff --git a/docs/api/controls/TDA-20.4.json b/docs/api/controls/TDA-20.4.json index 62c53874..ff2e3264 100644 --- a/docs/api/controls/TDA-20.4.json +++ b/docs/api/controls/TDA-20.4.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to govern the approval of binaries and code for production use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -77,7 +77,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { diff --git a/docs/api/controls/TDA-20.json b/docs/api/controls/TDA-20.json index 911dbc04..38815e65 100644 --- a/docs/api/controls/TDA-20.json +++ b/docs/api/controls/TDA-20.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, uses a Source Code Manager (SCM) solution to govern modifying, copying, deleting, moving and renaming items in the software library.\n▪ SCM supports integrity checking on the source code repository.\n▪ SCM uses Role-Based Access Controls (RBAC) to limit the logical access and permissions for users in the software library.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit privileges to change software resident within software libraries.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit privileges to change software resident within software libraries. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -171,15 +172,18 @@ "SA-04 (02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(73)" + "3.6.2.73" ], "emea-deu-bsrit-2017": [ "7.9" ], "emea-deu-c5-2020": [ - "DEV-07" + "IDM-13" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "1-3-2-2" + ], + "apac-aus-ism-2026-march": [ "ISM-1422" ], "apac-jpn-ismap": [ @@ -195,12 +199,18 @@ "9.4.5.9", "14.2.1.5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP42", "HML42" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP37" + ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-21.json b/docs/api/controls/TDA-21.json index cfb16d62..35282c1e 100644 --- a/docs/api/controls/TDA-21.json +++ b/docs/api/controls/TDA-21.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure developed Technology Assets, Applications and/or Services (TAAS) conform to applicable statutory and regulatory requirements, based on the product's and/or service's:\n(1) Use case(s); and\n(2) Geographic markets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -123,8 +124,8 @@ "Article 53.1(c)", "Article 111.3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.12" + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-22.1.json b/docs/api/controls/TDA-22.1.json index 2ac27c4b..04cb12c0 100644 --- a/docs/api/controls/TDA-22.1.json +++ b/docs/api/controls/TDA-22.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to include a detailed cybersecurity risk assessment in the technical documentation for Technology Assets, Applications and/or Services (TAAS) to demonstrate applicable risks in approved use cases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -79,15 +79,13 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { "general-shared-assessments-sig-2025": [ "C.4" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/TDA-22.json b/docs/api/controls/TDA-22.json index 67087dfd..a76c4f8b 100644 --- a/docs/api/controls/TDA-22.json +++ b/docs/api/controls/TDA-22.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate appropriate technical documentation artifacts for Technology Assets, Applications and/or Services (TAAS) in sufficient detail to demonstrate conformity with applicable statutory, regulatory and contractual compliance requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -82,7 +82,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -91,9 +92,6 @@ "MP-4.1-010", "MS-2.9-001" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], @@ -103,32 +101,6 @@ "Article 17.1(k)", "Article 23.1(b)", "Article 53.1(a)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.7", - "Article 13.2(b)", - "Article 23.1", - "Article 23.2", - "Article 23.3", - "Article 23.4" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 5", - "Annex 5.1", - "Annex 5.1(a)", - "Annex 5.1(b)", - "Annex 5.1(c)", - "Annex 5.1(d)", - "Annex 5.2", - "Annex 5.2(a)", - "Annex 5.2(b)", - "Annex 5.2(c)", - "Annex 5.3", - "Annex 5.4", - "Annex 5.5", - "Annex 5.6", - "Annex 5.7", - "Annex 6 Module A.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/THR-01.1.json b/docs/api/controls/THR-01.1.json new file mode 100644 index 00000000..afc79eb0 --- /dev/null +++ b/docs/api/controls/THR-01.1.json @@ -0,0 +1,107 @@ +{ + "control_id": "THR-01.1", + "title": "Dynamic Threat Awareness", + "family": "THR", + "description": "Mechanisms exist to determine and maintain ongoing awareness of the current cyber threat environment.", + "scf_question": "Does the organization determine and maintain ongoing awareness of the current cyber threat environment?", + "relative_weight": 3, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to determine and maintain ongoing awareness of the current cyber threat environment.", + "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subscribe to CISA alerts\n∙ MS-ISAC free membership", + "small": "∙ CISA and MS-ISAC alerts\n∙ Industry-specific threat intelligence feeds\n∙ Basic threat awareness program", + "medium": "∙ Threat intelligence feeds (CISA, industry ISACs)\n∙ Regular threat landscape reviews\n∙ Integration with security awareness program", + "large": "∙ Threat intelligence program with dedicated analyst\n∙ ISAC membership and information sharing\n∙ Regular executive threat briefings", + "enterprise": "∙ Enterprise threat intelligence program\n∙ Automated threat intelligence feeds and analysis\n∙ ISAC and government information sharing partnerships\n∙ Threat intelligence integrated with SIEM and SOC operations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Threat Management", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.11.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.08E", + "A.03.11.08E.ODP[01]" + ], + "apac-sgp-mas-trm-2021": [ + "14.1.6" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/THR-01.2.json b/docs/api/controls/THR-01.2.json new file mode 100644 index 00000000..1ef2d753 --- /dev/null +++ b/docs/api/controls/THR-01.2.json @@ -0,0 +1,107 @@ +{ + "control_id": "THR-01.2", + "title": "Predictive Cyber Analytics", + "family": "THR", + "description": "Mechanisms exist to employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 3, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use free threat indicators from CISA and MS-ISAC", + "small": "∙ Use free threat indicators from CISA and MS-ISAC\n∙ Basic anomaly detection via endpoint protection tools", + "medium": "∙ SIEM with anomaly detection capabilities\n∙ User and Entity Behavior Analytics (UEBA) basic functionality", + "large": "∙ SIEM/UEBA platform with predictive analytics\n∙ Machine learning-based anomaly detection\n∙ Threat hunting based on behavioral analytics", + "enterprise": "∙ Enterprise SIEM/SOAR with advanced predictive analytics\n∙ AI/ML-based threat detection (e.g., Darktrace, Vectra AI, Microsoft Sentinel ML)\n∙ Dedicated threat analytics team\n∙ Predictive analytics integrated with SOC operations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Threat Management", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.11.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.03E[01]", + "A.03.11.03E.ODP[01]", + "A.03.11.03E.ODP[02]", + "DS-A.03.11.03E[02]", + "A.03.11.03E.ODP[03]" + ] + } +} \ No newline at end of file diff --git a/docs/api/controls/THR-01.json b/docs/api/controls/THR-01.json index 243efac4..7bf16611 100644 --- a/docs/api/controls/THR-01.json +++ b/docs/api/controls/THR-01.json @@ -117,7 +117,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -202,8 +203,20 @@ ], "general-nist-800-171-r3": [ "03.11.02.a", + "03.14.01.a", "03.14.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.a[01]", + "A.03.14.01.a[01]", + "A.03.14.03.a" + ], + "general-nist-800-172-r3": [ + "03.11.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.01E" + ], "general-nist-800-207": [ "NIST Tenet 7" ], @@ -280,33 +293,37 @@ "Article 45.2", "Article 45.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "3.10", "5.3" ], - "emea-isr-cmo-1-0": [ - "23.1", - "23.4" + "emea-deu-c5-2020": [ + "OIS-05-DOAR" + ], + "emea-isr-cmo-2-0": [ + "2.B" ], "emea-sau-cgiot-2024": [ "2-12-4" ], "emea-sau-ecc-1-2018": [ - "2-10-4", "2-13-1", "2-13-2", - "2-13-3", - "2-13-4" + "2-13-3-5" + ], + "emea-sau-otcc-1-2022": [ + "2-12-1-8" ], "emea-sau-sama-csf-1-2017": [ - "3.3.16" + "3.3.16.1", + "3.3.16.3", + "3.3.16.3.a", + "3.3.16.3.c", + "3.3.16.3.d", + "3.3.16.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "emea-gbr-caf-4-0": [ "A2.b" @@ -326,19 +343,11 @@ "apac-jpn-ismap": [ "5.1.1.4" ], - "apac-sgp-mas-trm-2021": [ - "4.2.1", - "13.5.1", - "13.5.2", - "14.3.1", - "14.3.2", - "14.3.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.2" + "apac-mys-bnm-rmit-2025": [ + "11.10" ], - "amaericas-can-osfi-self-assessment": [ - "1.3" + "apac-sgp-mas-trm-2021": [ + "14.1.6" ], "americas-can-osfi-b13-2022": [ "3.0", @@ -346,8 +355,13 @@ "3.1.1", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.A", + "03.14.01.A", "03.14.03.A" ] } diff --git a/docs/api/controls/THR-02.json b/docs/api/controls/THR-02.json index d32b5837..6fe2f9a0 100644 --- a/docs/api/controls/THR-02.json +++ b/docs/api/controls/THR-02.json @@ -20,9 +20,9 @@ "0": "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.", "1": "Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Threat management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop Indicators of Exposure (IOE) to understand the potential attack vectors that attackers could use to attack the organization.", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop Indicators of Exposure (IOE) to understand the potential attack vectors that attackers could use to attack the organization. ", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -116,16 +117,8 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "3.A" ], - "emea-isr-cmo-1-0": [ - "23.3" - ], - "emea-sau-otcc-1-2022": [ - "2-12-2-8" - ], - "apac-sgp-mas-trm-2021": [ - "14.3.1", - "14.3.2", - "14.3.3" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "americas-can-osfi-b13-2022": [ "3.1" diff --git a/docs/api/controls/THR-03.1.json b/docs/api/controls/THR-03.1.json index 86fca2d2..68c5ab55 100644 --- a/docs/api/controls/THR-03.1.json +++ b/docs/api/controls/THR-03.1.json @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -101,6 +102,7 @@ "03.14.03.b" ], "general-nist-800-171a-r3": [ + "A.03.14.03.a", "A.03.14.03.b[01]", "A.03.14.03.b[02]" ], @@ -115,9 +117,23 @@ "7.5.1", "7.5.2" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)", + "101.625(d)(14)", + "101.650(e)(3)(iii)" + ], + "emea-deu-c5-2020": [ + "OIS-05-DOAR" + ], "emea-sau-cgiot-2024": [ "2-12-4" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.16.3.f" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], "emea-gbr-def-stan-05-138-2024": [ "1204", "3110" @@ -138,6 +154,16 @@ "4.9.2.1", "4.9.2.2" ], + "apac-mys-bnm-rmit-2025": [ + "11.10" + ], + "apac-sgp-mas-trm-2021": [ + "12.1.3" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.14.03.B" ] diff --git a/docs/api/controls/THR-03.json b/docs/api/controls/THR-03.json index 5193d15b..e1d81d2e 100644 --- a/docs/api/controls/THR-03.json +++ b/docs/api/controls/THR-03.json @@ -88,7 +88,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -137,7 +138,7 @@ "general-iso-27018-2025": [ "5.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1210", "T1211", @@ -208,17 +209,20 @@ "general-nist-800-171-r3": [ "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", - "03.02.02.b", "03.11.02.a", "03.14.03.a" ], "general-nist-800-171a-r3": [ + "A.03.02.01.a.02", + "A.03.02.01.b[02]", + "A.03.11.02.a[01]", "A.03.14.03.a" ], - "general-nist-800-172": [ - "3.11.1e", - "3.14.6e" + "general-nist-800-172-r3": [ + "03.11.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.12E" ], "general-nist-800-207": [ "NIST Tenet 7" @@ -313,6 +317,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SI-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(ii)" + ], "usa-federal-irs-1075-2021": [ "SI-5" ], @@ -339,7 +346,7 @@ "SI-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(21)" + "3.3.3.21" ], "emea-eu-dora-2023": [ "Article 13.1" @@ -348,21 +355,26 @@ "6.10.2(a)" ], "emea-deu-bsrit-2017": [ + "3.10", "5.3" ], - "emea-isr-cmo-1-0": [ - "23.2" + "emea-deu-c5-2020": [ + "OIS-05" ], "emea-sau-cgiot-2024": [ "2-12-4" ], "emea-sau-ecc-1-2018": [ - "2-10-3-5", "2-13-3-5" ], "emea-sau-otcc-1-2022": [ - "1-8-3", - "2-12-2-8" + "2-12-1-8" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.16.3.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "emea-gbr-def-stan-05-138-2024": [ "1204", @@ -375,6 +387,9 @@ "1204", "3110" ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], "apac-ind-sebi-2024": [ "EV.ST.S1", "EV.ST.S4", @@ -388,13 +403,19 @@ "12.2.1.12", "12.2.1.13" ], + "apac-mys-bnm-rmit-2025": [ + "11.3", + "11.10", + "12.3", + "12.4" + ], "apac-sgp-mas-trm-2021": [ + "4.2.1", "12.1.1", - "12.1.2", - "12.1.3" + "12.1.2" ], - "amaericas-can-osfi-self-assessment": [ - "3.7" + "americas-bmu-mba-coc-2020": [ + "6.2" ], "americas-can-osfi-b13-2022": [ "3.0", @@ -402,11 +423,13 @@ "3.1.1", "3.1.5" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", - "03.02.02.B", "03.11.02.A", "03.14.03.A" ] diff --git a/docs/api/controls/THR-04.json b/docs/api/controls/THR-04.json index 24e8bc49..480627fd 100644 --- a/docs/api/controls/THR-04.json +++ b/docs/api/controls/THR-04.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Threat management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to implement an insider threat program that includes a cross-discipline insider threat incident handling team.", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to implement an insider threat program that includes a cross-discipline insider threat incident handling team. ", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93,7 +93,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -157,7 +158,7 @@ "§117.18(b)(4)(iii)", "§117.18(b)(4)(iv)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ], diff --git a/docs/api/controls/THR-05.json b/docs/api/controls/THR-05.json index deb112a1..ff4cb552 100644 --- a/docs/api/controls/THR-05.json +++ b/docs/api/controls/THR-05.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to utilize security awareness training on recognizing and reporting potential indicators of insider threat.", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -207,7 +208,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "AT-02 (02)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ], diff --git a/docs/api/controls/THR-06.1.json b/docs/api/controls/THR-06.1.json index fd2c008f..77d2133a 100644 --- a/docs/api/controls/THR-06.1.json +++ b/docs/api/controls/THR-06.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to enable public submissions of discovered or potential security vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,7 +61,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -72,8 +73,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 2.2" + "apac-aus-cop-sitc-2020": [ + "2" ] } } \ No newline at end of file diff --git a/docs/api/controls/THR-06.json b/docs/api/controls/THR-06.json index 734bd269..a9bc15d8 100644 --- a/docs/api/controls/THR-06.json +++ b/docs/api/controls/THR-06.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to establish a Vulnerability Disclosure Program (VDP) to assist with the secure development and maintenance of Technology Assets, Applications and/or Services (TAAS) that receives unsolicited input from the public about vulnerabilities in organizational TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -65,7 +65,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -100,6 +101,13 @@ "general-nist-800-82-r3-high": [ "RA-05(11)" ], + "general-nist-800-171-r3": [ + "03.14.01.a" + ], + "general-nist-800-171a-r3": [ + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], "general-nist-800-218": [ "RV.1.3" ], @@ -127,9 +135,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "T.2" ], @@ -167,17 +172,17 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "RA-05(11)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(5)" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1616", "ISM-1717", "ISM-1755", "ISM-1756" ], "apac-aus-cop-sitc-2020": [ - "Principle 2" + "2" + ], + "apac-mys-bnm-rmit-2025": [ + "11.7" ], "apac-nzl-ism-3-9": [ "5.9.23.C.01", @@ -190,6 +195,9 @@ ], "apac-sgp-mas-trm-2021": [ "13.2.2" + ], + "americas-can-itsp-10-171-2025": [ + "03.14.01.A" ] } } \ No newline at end of file diff --git a/docs/api/controls/THR-07.json b/docs/api/controls/THR-07.json index d8d8d338..91bfa4d8 100644 --- a/docs/api/controls/THR-07.json +++ b/docs/api/controls/THR-07.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to perform cyber threat hunting that uses Indicators of Compromise (IoC) to detect, track and disrupt threats that evade existing security controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -93,14 +93,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { "general-cr-cmm-2026": [ "CR2.2.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1190", "T1195", @@ -137,10 +138,14 @@ "general-nist-800-161-r1-level-3": [ "RA-10" ], - "general-nist-800-172": [ - "3.11.1e", - "3.11.2e", - "3.14.6e" + "general-nist-800-172-r3": [ + "03.11.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.02E.a.01[02]", + "DS-A.03.11.02E.a.02[01]", + "DS-A.03.11.02E.a.02[02]", + "DS-A.03.11.02E.b" ], "general-nist-csf-2-0": [ "ID.RA-03", @@ -174,6 +179,9 @@ "C2.a (point 7)", "C2.a (point 8)" ], + "apac-aus-ism-2026-march": [ + "ISM-1921" + ], "apac-ind-sebi-2024": [ "DE.DP.S5" ], diff --git a/docs/api/controls/THR-08.json b/docs/api/controls/THR-08.json index 3213cce9..39c04df3 100644 --- a/docs/api/controls/THR-08.json +++ b/docs/api/controls/THR-08.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to embed false data or steganographic data in files to enable the organization to determine if data has been exfiltrated and provide a means to identify the individual(s) involved.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -59,7 +59,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -83,6 +84,12 @@ ], "general-nist-800-161-r1-level-3": [ "SI-20" + ], + "general-nist-800-172-r3": [ + "03.14.16E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.16E" ] } } \ No newline at end of file diff --git a/docs/api/controls/THR-09.json b/docs/api/controls/THR-09.json index b7502dc0..f76d425d 100644 --- a/docs/api/controls/THR-09.json +++ b/docs/api/controls/THR-09.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop and keep current a catalog of applicable internal and external threats to the organization, both natural and manmade.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -106,9 +107,6 @@ "general-nist-800-171-r3": [ "03.15.02.a.03" ], - "general-nist-800-172": [ - "3.11.5e" - ], "general-nist-csf-2-0": [ "ID.RA-03", "ID.RA-04", @@ -138,10 +136,10 @@ "RA.L3-3.11.5E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" @@ -154,6 +152,7 @@ ], "emea-deu-bsrit-2017": [ "3.3", + "3.10", "5.3" ], "emea-sau-cgiot-2024": [ @@ -163,10 +162,24 @@ "A2.b", "C1.f" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.3" + ], + "apac-sgp-mas-trm-2021": [ + "4.2.1" + ], + "americas-arg-ppd-2018": [ + "E.1.1-1" + ], "americas-can-osfi-b13-2022": [ "3.0", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.2", + "3.1.6" + ], "americas-can-itsp-10-171-2025": [ "03.15.02.A.03" ] diff --git a/docs/api/controls/THR-10.json b/docs/api/controls/THR-10.json index 33e59d29..5e8ed621 100644 --- a/docs/api/controls/THR-10.json +++ b/docs/api/controls/THR-10.json @@ -72,7 +72,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -108,6 +109,9 @@ "general-nist-800-171-r3": [ "03.14.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.14.03.a" + ], "general-nist-csf-2-0": [ "ID.RA-04", "ID.RA-05", @@ -135,10 +139,10 @@ "THREAT-2i" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(a)" @@ -153,18 +157,42 @@ "3.10", "5.3" ], + "emea-isr-cmo-2-0": [ + "Appendix B" + ], "emea-sau-cgiot-2024": [ "1-4-4" ], + "apac-aus-ism-2026-march": [ + "ISM-1203" + ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], "apac-ind-sebi-2024": [ "ID.RA.S4" ], + "apac-mys-bnm-rmit-2025": [ + "11.3", + "12.4" + ], + "apac-sgp-mas-trm-2021": [ + "4.3.2", + "8.5.1" + ], + "americas-arg-ppd-2018": [ + "E.1.1-1" + ], "americas-can-osfi-b13-2022": [ "3.1", "3.1.1", "3.1.2", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.2", + "3.1.6" + ], "americas-can-itsp-10-171-2025": [ "03.14.03.B" ] diff --git a/docs/api/controls/THR-11.json b/docs/api/controls/THR-11.json index db8b9491..631b71d3 100644 --- a/docs/api/controls/THR-11.json +++ b/docs/api/controls/THR-11.json @@ -22,7 +22,7 @@ "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to automatically establish behavioral baselines that capture information about user and entity behavior to enable dynamic threat discovery.", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -90,7 +90,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -114,6 +115,9 @@ ], "usa-federal-dow-zta-reference-architecture-2-0": [ "1.2" + ], + "apac-sgp-mas-trm-2021": [ + "12.2.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-01.1.json b/docs/api/controls/TPM-01.1.json index 426ac084..6f5780db 100644 --- a/docs/api/controls/TPM-01.1.json +++ b/docs/api/controls/TPM-01.1.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A procurement function maintains a list of all active External Service Providers (ESPs), including pertinent contract information that will assist in a risk assessment.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to maintain a current, accurate and complete list of External Service Providers (ESPs) that can potentially impact the Confidentiality, Integrity, Availability and/or Safety (CIAS) of the organization's TAASD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -139,7 +140,11 @@ "SR-13" ], "general-nist-800-171-r3": [ - "03.07.06.a" + "03.07.06.a", + "03.07.06.b" + ], + "general-nist-800-171a-r3": [ + "A.03.07.06.b" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -245,7 +250,10 @@ "5.2", "5.2(a)" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" + ], + "apac-aus-ism-2026-march": [ "ISM-1631", "ISM-1637", "ISM-1638", @@ -254,7 +262,8 @@ "ISM-1786" ], "apac-aus-ps-cps-230-2023": [ - "49" + "49", + "51" ], "apac-ind-sebi-2024": [ "GV.OC.S3", @@ -262,7 +271,8 @@ "GV.SC.S2" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A" + "03.07.06.A", + "03.07.06.B" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-01.json b/docs/api/controls/TPM-01.json index 24b48ebb..b979639d 100644 --- a/docs/api/controls/TPM-01.json +++ b/docs/api/controls/TPM-01.json @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -148,7 +149,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0", + "15", "15.2" ], "general-cis-csc-8-1-ig2": [ @@ -300,9 +301,19 @@ "03.01.20.c.01", "03.07.06.a", "03.16.01", - "03.16.03.a" + "03.16.03.a", + "03.17.02" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.07.06.a", + "A.03.16.01", + "A.03.16.03.a", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.02[06]", "A.03.17.03.ODP[01]" ], "general-nist-csf-2-0": [ @@ -358,10 +369,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "10.0", - "11.0" - ], "general-sparta": [ "CM0025" ], @@ -435,12 +442,12 @@ "314.4(f)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "1.9.3", @@ -484,8 +491,7 @@ "2447(b)(6)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(7)", - "3.6.2(74)" + "3.2.3.7" ], "emea-eu-dora-2023": [ "Article 30.3 (end)", @@ -499,62 +505,43 @@ "emea-eu-nis2-annex-2024": [ "6.2.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "9.1" ], "emea-deu-c5-2020": [ - "SSO-01", - "SSO-03" + "UP-01", + "DLL-01", + "DLL-02" ], - "emea-isr-cmo-1-0": [ - "11.3", - "11.10", - "16.1", - "17.3" + "emea-isr-cmo-2-0": [ + "Appendix A, 10.1" ], "emea-sau-cscc-1-2019": [ - "4-1" + "4-1-1" ], "emea-sau-ecc-1-2018": [ - "1-5-3-3", "4-1-1", - "4-1-2", - "4-1-3", - "4-1-4" + "4-1-3-2" ], "emea-sau-otcc-1-2022": [ - "4-1", "4-1-1", - "4-1-1-1", - "4-1-1-2", - "4-1-1-3", - "4-1-1-4", "4-1-2" ], "emea-sau-sama-csf-1-2017": [ "3.4.1", - "3.4.2" + "3.4.1.1", + "3.4.1.4", + "3.4.1.4.a", + "3.4.1.6", + "3.4.1.6.a", + "3.4.2.1" ], - "emea-zaf-popia-2013": [ - "20", - "21" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-caf-4-0": [ "A4" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -567,66 +554,24 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1073", "ISM-1785" ], "apac-aus-ps-cps-230-2023": [ - "15", + "12(c)", + "16(f)", "47", + "48", "48(a)", "48(b)", - "48(c)", - "57" - ], - "apac-aus-ps-cps-234-2019": [ - "16", - "20", - "22", - "28" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)", - "42", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "48(c)" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1", "PR.IP.S15" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "24(3)" - ], "apac-jpn-ismap": [ "4.5.3.1", "5.1.1.20", @@ -649,7 +594,13 @@ "15.1.1.13", "15.1.1.14.B" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.24", + "10.25", + "10.46" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HML25" ], @@ -663,24 +614,19 @@ ], "apac-sgp-mas-trm-2021": [ "3.4.1", - "3.4.2", - "3.4.3", - "9.1.8" + "8.3.4" ], "americas-bmu-mba-coc-2020": [ "5.10" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.B", "03.01.20.C.01", "03.07.06.A", "03.16.01", - "03.16.03.A" + "03.16.03.A", + "03.17.02" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-02.json b/docs/api/controls/TPM-02.json index 27ade2b5..2a09c72e 100644 --- a/docs/api/controls/TPM-02.json +++ b/docs/api/controls/TPM-02.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to identify, prioritize and assess suppliers and partners of critical Technology Assets, Applications and/or Services (TAAS) using a supply chain risk assessment process relative to their importance in supporting the delivery of high-value services.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -116,7 +116,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -213,6 +214,16 @@ "03.11.01.a", "03.17.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.03.a[01]" + ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[01]" + ], "general-nist-csf-2-0": [ "GV.OC-04", "GV.OC-05", @@ -223,9 +234,6 @@ "ID.AM-05", "ID.RA-10" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-sparta": [ "CM0022" ], @@ -276,10 +284,10 @@ "314.4(f)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -294,53 +302,51 @@ "500.11(a)(1)", "500.11(a)(4)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.3.2.16" + ], "emea-eu-dora-2023": [ "Article 8.4" ], "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-deu-c5-2020": [ - "SSO-02", - "SSO-03" - ], - "emea-isr-cmo-1-0": [ - "16.1", - "16.6" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1" ], - "emea-sau-otcc-1-2022": [ - "4-1-1-2" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1452" ], "apac-aus-ps-cps-230-2023": [ + "15", + "49", + "50", "50(a)", "50(b)", "50(c)", "50(d)", - "52" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "51" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1", "GV.SC.S2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "10.46" + ], "apac-nzl-ism-3-9": [ "12.7.17.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.27" + "apac-sgp-mas-trm-2021": [ + "5.3.1" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", diff --git a/docs/api/controls/TPM-03.1.json b/docs/api/controls/TPM-03.1.json index 93160d44..3e1a085b 100644 --- a/docs/api/controls/TPM-03.1.json +++ b/docs/api/controls/TPM-03.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize tailored acquisition strategies, contract tools and procurement methods for the purchase of unique Technology Assets, Applications and/or Services (TAAS).", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -85,7 +85,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -107,7 +108,7 @@ "5.21", "5.22" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1059.002", "T1195", "T1195.001", @@ -179,9 +180,14 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.17.01.a[01]", "A.03.17.02[01]", "A.03.17.02[02]", - "A.03.17.02[03]" + "A.03.17.02[03]", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], "general-owasp-top-10-2025": [ "A03:2025" @@ -232,9 +238,6 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-05" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" - ], "emea-eu-dora-2023": [ "Article 29.1 (end)" ], @@ -244,17 +247,15 @@ "emea-deu-bsrit-2017": [ "9.3" ], - "emea-deu-c5-2020": [ - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "16.1" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.2", + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1567", "ISM-1568", "ISM-1632", @@ -262,6 +263,9 @@ "ISM-1788", "ISM-1789" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "americas-can-itsp-10-171-2025": [ "03.17.01.A", "03.17.02", diff --git a/docs/api/controls/TPM-03.2.json b/docs/api/controls/TPM-03.2.json index 65333a86..9293f9c1 100644 --- a/docs/api/controls/TPM-03.2.json +++ b/docs/api/controls/TPM-03.2.json @@ -21,9 +21,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize security safeguards to limit harm from potential adversaries who identify and target the organization's supply chain.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize security safeguards to limit harm from potential adversaries who identify and target the organization's supply chain. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -144,7 +145,7 @@ ], "general-iso-27002-2022": [ "5.19", - "5.2" + "5.20" ], "general-iso-27018-2025": [ "5.19", @@ -166,6 +167,10 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -198,38 +203,17 @@ "Article 21.3" ], "emea-deu-c5-2020": [ - "SSO-02" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.2" + "UP-01-BP1" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "apac-aus-ism-2024-june": [ - "ISM-1567" - ], - "apac-aus-ps-cps-230-2023": [ - "56(a)", - "56(b)", - "56(c)", - "56(d)" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], - "apac-aus-ps-cps-234-2019": [ - "22" - ], - "apac-chn-pipl-2021": [ - "20" - ], - "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" + "apac-aus-ism-2026-march": [ + "ISM-1567" ], "americas-can-itsp-10-171-2025": [ "03.17.03.A", diff --git a/docs/api/controls/TPM-03.3.json b/docs/api/controls/TPM-03.3.json index c911892e..76512fa0 100644 --- a/docs/api/controls/TPM-03.3.json +++ b/docs/api/controls/TPM-03.3.json @@ -3,7 +3,7 @@ "title": "Processes To Address Weaknesses or Deficiencies", "family": "TPM", "description": "Mechanisms exist to address identified weaknesses or deficiencies in the security of the supply chain", - "scf_question": "Does the organization address identified weaknesses or deficiencies in the security of the supply chain", + "scf_question": "Does the organization address identified weaknesses or deficiencies in the security of the supply chain?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -23,7 +23,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No centralized inventory of External Service Providers (ESP) is maintained.\n▪ ESP are not formally managed according to criticality.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address identified weaknesses or deficiencies in the security of the supply chain", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address identified weaknesses or deficiencies in the security of the supply chain ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -177,6 +178,10 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -217,8 +222,9 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-deu-c5-2020": [ - "SSO-02" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2" ], "americas-can-itsp-10-171-2025": [ "03.17.03.A", diff --git a/docs/api/controls/TPM-03.4.json b/docs/api/controls/TPM-03.4.json index baa648ff..7590c8b9 100644 --- a/docs/api/controls/TPM-03.4.json +++ b/docs/api/controls/TPM-03.4.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to develop and implement a spare parts strategy to ensure that an adequate supply of critical components is available to meet operational needs.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to develop and implement a spare parts strategy to ensure that an adequate supply of critical components is available to meet operational needs. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -97,7 +97,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { diff --git a/docs/api/controls/TPM-03.json b/docs/api/controls/TPM-03.json index 69479576..9116bda1 100644 --- a/docs/api/controls/TPM-03.json +++ b/docs/api/controls/TPM-03.json @@ -3,7 +3,7 @@ "title": "Supply Chain Risk Management (SCRM)", "family": "TPM", "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", - "scf_question": "Does the organization:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary?", + "scf_question": "Does the organization:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize its exposure to those risks and threats, as necessary?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -18,11 +18,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -118,7 +118,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -226,6 +227,12 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC", "GV.SC-06", @@ -236,9 +243,6 @@ "A03:2025", "A05:2025" ], - "general-scf-dpmp-2025": [ - "10.1" - ], "general-sparta": [ "CM0026", "CM0027" @@ -305,11 +309,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-02" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.4" - ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" + "3.7.3.86" ], "emea-eu-dora-2023": [ "Article 30.3(f)" @@ -322,37 +323,22 @@ "5.1.6" ], "emea-deu-c5-2020": [ - "SSO-02", - "SSO-03" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.1", - "16.3", - "16.5", - "17.3", - "17.11" - ], - "emea-pol-act-29-1997": [ - "31" + "PS-04-DOAR" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "emea-sau-sama-csf-1-2017": [ - "3.4.2" - ], - "emea-zaf-popia-2013": [ - "20" + "emea-sau-ecc-1-2018": [ + "4-1-3-1" ], - "emea-esp-decree-1720-2007": [ - "20", - "21" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2", + "op.ext.3" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]", - "7.4.3 [OP.EXT.3]" + "emea-gbr-cap-1850-2020": [ + "A4" ], "emea-gbr-def-stan-05-138-2024": [ "1400" @@ -366,20 +352,22 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0731", "ISM-1452", "ISM-1632", "ISM-1789" ], - "apac-aus-ps-cps-234-2019": [ - "22", - "28" + "apac-aus-ps-cps-230-2023": [ + "15" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-nzl-ism-3-9": [ "12.7.14.C.01", "12.7.14.C.02", @@ -401,26 +389,11 @@ "12.7.20.C.05", "12.7.21.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "43" - ], - "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.17.01.A", "03.17.03.A", "03.17.03.B" - ], - "americas-mex-fdpa-2010": [ - "21" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-04.1.json b/docs/api/controls/TPM-04.1.json index 281ebe64..aa8e07e0 100644 --- a/docs/api/controls/TPM-04.1.json +++ b/docs/api/controls/TPM-04.1.json @@ -20,7 +20,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to conduct a risk assessment prior to the acquisition or outsourcing of technology-related Technology Assets, Applications and/or Services (TAAS).", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -208,7 +209,13 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.17.03.a[01]" + "A.03.11.01.a", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.SC-06", @@ -316,9 +323,6 @@ "usa-state-vt-act-171-2018": [ "2447(b)(6)(A)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" - ], "emea-eu-dora-2023": [ "Article 28.4(a)", "Article 28.4(b)", @@ -338,66 +342,62 @@ "9.2", "9.5" ], - "emea-deu-c5-2020": [ - "SSO-02", - "SSO-04" - ], - "emea-isr-cmo-1-0": [ - "16.3", - "16.5", - "17.3" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], "emea-sau-ecc-1-2018": [ - "1-5-3-4", "4-1-3-1" ], "emea-sau-otcc-1-2022": [ - "4-1-1-2", - "4-1-1-4" - ], - "emea-sau-sama-csf-1-2017": [ - "3.4.1", - "3.4.2" + "4-1-1-2" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1568", "ISM-1573", - "ISM-1787" + "ISM-1787", + "ISM-1882" ], "apac-aus-ps-cps-230-2023": [ "15", + "53", "53(a)", "53(b)" ], "apac-aus-ps-cps-234-2019": [ - "22", - "28" + "16" ], "apac-jpn-ismap": [ "14.1.1.14", "15.1.1.16.B" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.46", + "10.47", + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HML25" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP67" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25", - "4.27" + "apac-sgp-mas-trm-2021": [ + "3.4.2", + "5.3.1", + "5.3.2", + "6.4.2", + "6.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "5.10" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", diff --git a/docs/api/controls/TPM-04.2.json b/docs/api/controls/TPM-04.2.json index d3baf42e..f050cf15 100644 --- a/docs/api/controls/TPM-04.2.json +++ b/docs/api/controls/TPM-04.2.json @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -172,9 +173,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SA-09 (02)" - ], - "emea-isr-cmo-1-0": [ - "16.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-04.3.json b/docs/api/controls/TPM-04.3.json index 5d902a96..30204131 100644 --- a/docs/api/controls/TPM-04.3.json +++ b/docs/api/controls/TPM-04.3.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure that the interests of external service providers are consistent with and reflect organizational interests.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -98,7 +98,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -153,12 +154,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" ], - "emea-isr-cmo-1-0": [ - "16.3" - ], - "emea-zaf-popia-2013": [ - "20", - "21" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-04.4.json b/docs/api/controls/TPM-04.4.json index 59c4549c..adf5f831 100644 --- a/docs/api/controls/TPM-04.4.json +++ b/docs/api/controls/TPM-04.4.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to restrict the location of information processing/storage based on business requirements.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to restrict the location of information processing/storage based on business requirements. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -116,7 +116,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -174,6 +175,9 @@ "general-nist-800-171-r3": [ "03.16.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.a" + ], "general-nist-csf-2-0": [ "GV.SC-06" ], @@ -203,9 +207,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "3.2.1" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -243,84 +244,17 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-deu-c5-2020": [ - "PI-02", - "PSS-12" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "16.3" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1572" ], - "apac-chn-pipl-2021": [ - "21", - "38", - "38(3)", - "40" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" + "apac-mys-bnm-rmit-2025": [ + "10.50" ], "americas-can-itsp-10-171-2025": [ "03.16.03.A" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-04.json b/docs/api/controls/TPM-04.json index f1063555..3f6654d9 100644 --- a/docs/api/controls/TPM-04.json +++ b/docs/api/controls/TPM-04.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel proactively control and monitor third-party accounts used to access, support, or maintain system components via remote access.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to mitigate the risks associated with third-party access to the organization's TAASD.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -116,7 +116,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -176,7 +177,7 @@ "A.10.2", "A.10.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -227,6 +228,16 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.a", + "A.03.16.03.c", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -273,11 +284,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.2" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.1", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -321,10 +327,10 @@ "314.4(f)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-irs-1075-2021": [ "2.C.9", @@ -380,74 +386,24 @@ "9.2" ], "emea-deu-c5-2020": [ - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.1", - "22.4" + "PS-04-DOAR" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "emea-sau-otcc-1-2022": [ - "4-1-1-3" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.5" - ], - "emea-esp-decree-311-2022": [ - "13.5" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-36" ], - "emea-gbr-cap-1850-2020": [ - "A4" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1569" ], - "apac-aus-ps-cps-234-2019": [ - "16", - "22", - "28" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)" - ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], - "americas-arg-ppd-2018": [ - "25.1" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.50" ], "americas-can-itsp-10-171-2025": [ "03.16.03.A", diff --git a/docs/api/controls/TPM-05.1.json b/docs/api/controls/TPM-05.1.json index b912a2fe..65fadc7a 100644 --- a/docs/api/controls/TPM-05.1.json +++ b/docs/api/controls/TPM-05.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to compel External Service Providers (ESPs) to provide notification of actual or potential compromises in the supply chain that can potentially affect or have adversely affected Technology Assets, Applications and/or Services (TAAS) that the organization utilizes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -113,7 +113,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -167,6 +168,16 @@ "general-nist-800-171-r3": [ "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.17.02[05]" + ], + "general-nist-800-172-r3": [ + "03.17.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.01E", + "A.03.17.01E.ODP[01]" + ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -192,16 +203,16 @@ "SR-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)", - "164.410(a)(1)", - "164.410(a)(2)", - "164.410(b)", - "164.410(c)(2)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)", + "§ 164.410(a)(1)", + "§ 164.410(a)(2)", + "§ 164.410(b)", + "§ 164.410(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)" ], "usa-federal-nerc-cip-2024": [ "CIP-013-2 1.2.1" @@ -218,9 +229,18 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-08" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "RB-20" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1576" ], + "apac-mys-bnm-rmit-2025": [ + "10.49" + ], "apac-nzl-ism-3-9": [ "7.2.22.C.01", "7.2.23.C.01" diff --git a/docs/api/controls/TPM-05.2.json b/docs/api/controls/TPM-05.2.json index fa8a2740..be828de3 100644 --- a/docs/api/controls/TPM-05.2.json +++ b/docs/api/controls/TPM-05.2.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.\n▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure applicable security, compliance and resilience requirements are included in contracts that flow-down to applicable sub-contractors and suppliers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -94,9 +94,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -151,7 +151,12 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.16.03.ODP[01]" + "A.03.16.03.ODP[01]", + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.OC-03", @@ -160,9 +165,6 @@ "GV.SC-06", "GV.SC-10" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -214,18 +216,18 @@ "155.260(b)(2)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)", - "164.502(e)(1)(ii)", - "164.504(e)(2)(ii)(D)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)", + "§ 164.502(e)(1)(ii)", + "§ 164.504(e)(2)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SR-3(CE-3)" @@ -255,9 +257,7 @@ "59.1-579.B.5" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8" ], "emea-eu-dora-2023": [ "Article 29.2" @@ -268,15 +268,17 @@ "emea-eu-nis2-annex-2024": [ "5.1.4(g)" ], - "emea-qat-pdppl-2020": [ - "12" + "emea-deu-bsrit-2017": [ + "9.4" ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "emea-deu-c5-2020": [ + "UP-01-BP6", + "DLL-01-BP2", + "DLL-01-BP4", + "DLL-01-DOAR" ], - "emea-srb-act-9-2018": [ - "5", - "11" + "emea-sau-ecc-1-2018": [ + "4-1-2-3" ], "emea-gbr-def-stan-05-138-2024": [ "1401" @@ -297,6 +299,9 @@ "GV.SC.S3", "GV.SC.S8" ], + "apac-mys-bnm-rmit-2025": [ + "10.48" + ], "americas-can-itsp-10-171-2025": [ "03.16.03.A", "03.16.03.B", diff --git a/docs/api/controls/TPM-05.3.json b/docs/api/controls/TPM-05.3.json index 0c6a8032..ef1267b0 100644 --- a/docs/api/controls/TPM-05.3.json +++ b/docs/api/controls/TPM-05.3.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure External Service Providers (ESPs) use unique authentication factors for each of its customers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { diff --git a/docs/api/controls/TPM-05.4.json b/docs/api/controls/TPM-05.4.json index 7a642f6c..1cd4a8db 100644 --- a/docs/api/controls/TPM-05.4.json +++ b/docs/api/controls/TPM-05.4.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel govern third-party cybersecurity and data protection roles and responsibilities through a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar shared responsibilities tracking tool.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to document and maintain a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to delineate assignment for security, compliance and resilience controls between internal stakeholders and External Service Providers (ESPs).", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to document and maintain a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to delineate assignment for security, compliance and resilience controls between internal stakeholders and External Service Providers (ESPs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -96,9 +96,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -115,7 +115,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0" + "15" ], "general-coso-2013": [ "12" @@ -190,9 +190,11 @@ ], "general-nist-800-171-r3": [ "03.07.06.a", + "03.07.06.b", "03.16.03.b" ], "general-nist-800-171a-r3": [ + "A.03.07.06.b", "A.03.16.03.b" ], "general-nist-csf-2-0": [ @@ -252,9 +254,6 @@ "12.8.2", "12.8.5" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -273,10 +272,10 @@ "THIRD-PARTIES-1a" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -298,11 +297,8 @@ "500.10(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)", - "3.3.2(16)", - "3.5(55)" + "3.2.3.8", + "3.5.55" ], "emea-eu-nis2-2022": [ "Article 21.3" @@ -312,19 +308,25 @@ "8.1.1", "10.1.2(a)" ], + "emea-deu-c5-2020": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03", + "SIM-06" + ], + "emea-sau-ecc-1-2018": [ + "4-1-2-2" + ], "emea-sau-otcc-1-2022": [ "1-2-1-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2", - "Article 13.5" - ], "emea-esp-decree-311-2022": [ - "13.2", - "13.5" + "Article 11(2)", + "Article 13(3)", + "Article 13(5)" ], - "emea-gbr-cap-1850-2020": [ - "A4" + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "apac-ind-sebi-2024": [ "GV.OC.S3", @@ -340,8 +342,19 @@ "6.1.5.6", "6.3.1.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.46", + "10.48" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.10" + ], "americas-can-itsp-10-171-2025": [ "03.07.06.A", + "03.07.06.B", "03.16.03.B" ] } diff --git a/docs/api/controls/TPM-05.5.json b/docs/api/controls/TPM-05.5.json index 5f4f3115..2bcd44f9 100644 --- a/docs/api/controls/TPM-05.5.json +++ b/docs/api/controls/TPM-05.5.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to perform recurring validation of the Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to ensure security, compliance and resilience control assignments accurately reflect current:\n(1) Contractual obligations for the External Service Provider (ESP);\n(2) Business practices;\n(3) Applicable stakeholders; and\n(4) Deployed Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -80,9 +80,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -92,7 +92,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0" + "15" ], "general-iso-42001-2023": [ "4.3" @@ -104,7 +104,11 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.16.03.c" + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[02]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.SC-06" @@ -146,9 +150,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -163,14 +164,23 @@ "500.11(a)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(55)" + "3.5.55" ], "emea-eu-nis2-2022": [ "Article 21.3" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "UP-01-BP1" + ], + "apac-aus-ism-2026-march": [ "ISM-1793" ], + "apac-mys-bnm-rmit-2025": [ + "10.46" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.16.03.C", "03.17.02", diff --git a/docs/api/controls/TPM-05.6.json b/docs/api/controls/TPM-05.6.json index 2256c0b2..0b9a835b 100644 --- a/docs/api/controls/TPM-05.6.json +++ b/docs/api/controls/TPM-05.6.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to obtain a First-Party Declaration(1PD) from applicable External Service Providers (ESPs) that provides assurance of compliance with specified statutory, regulatory and contractual obligations for security, compliance and resilience controls, including any flow-down requirements to subcontractors.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to obtain a First-Party Declaration(1PD) from applicable External Service Providers (ESPs) that provides assurance of compliance with specified statutory, regulatory and contractual obligations for security, compliance and resilience controls, including any flow-down requirements to subcontractors. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -93,9 +93,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -117,6 +117,7 @@ "03.16.03.c" ], "general-nist-800-171a-r3": [ + "A.03.01.20.c.01", "A.03.16.03.c" ], "general-nist-csf-2-0": [ @@ -135,12 +136,12 @@ "7.2.2.5" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(2)", - "164.502(e)(1)(i)", - "164.502(e)(1)(ii)" + "§ 164.308(b)(2)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(1)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(2)" + "§ 164.308(b)(2)" ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" @@ -155,11 +156,14 @@ "500.11(b)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(9)" + "3.2.3.9" ], "emea-eu-nis2-2022": [ "Article 21.3" ], + "emea-qat-pdppl-2020": [ + "3.11.8" + ], "emea-sau-cgiot-2024": [ "4-1-2" ], diff --git a/docs/api/controls/TPM-05.7.json b/docs/api/controls/TPM-05.7.json index 15ee67de..f9e8d3f8 100644 --- a/docs/api/controls/TPM-05.7.json +++ b/docs/api/controls/TPM-05.7.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Contracts with ESP contain break clauses to enable penalty-free, early termination of a contract for cause, based on ESP cybersecurity and/or data protection practices deficiency(ies).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to include \"break clauses\" within contracts for failure to meet contract criteria for security, compliance and/or resilience controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -91,9 +91,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -131,6 +131,12 @@ "03.17.02", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.01.a[01]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06" ], @@ -147,7 +153,7 @@ "1.H" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.504(e)(2)(iii)" + "§ 164.504(e)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -170,15 +176,18 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1804" ], "apac-aus-ps-cps-230-2023": [ - "50(g)" + "54(g)" ], "apac-ind-sebi-2024": [ "GV.SC.S3" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "americas-can-itsp-10-171-2025": [ "03.17.01.A", "03.17.02", diff --git a/docs/api/controls/TPM-05.8.json b/docs/api/controls/TPM-05.8.json index 49e7dd09..6fcc903b 100644 --- a/docs/api/controls/TPM-05.8.json +++ b/docs/api/controls/TPM-05.8.json @@ -90,9 +90,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-iso-21434-2021": [ @@ -110,6 +110,10 @@ "03.16.03.c" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.16.03.a", "A.03.16.03.c" ], "general-tisax-6-0-3": [ @@ -118,6 +122,16 @@ "usa-state-nv-regulation-5-2024": [ "5.260.5(c)" ], + "emea-deu-c5-2020": [ + "UP-04" + ], + "emea-qat-pdppl-2020": [ + "3.11.8" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-20", + "VII.A.TPC-21" + ], "apac-ind-sebi-2024": [ "PR.IP.S15", "PR.IP.S16" diff --git a/docs/api/controls/TPM-05.json b/docs/api/controls/TPM-05.json index a3070647..90128184 100644 --- a/docs/api/controls/TPM-05.json +++ b/docs/api/controls/TPM-05.json @@ -3,7 +3,7 @@ "title": "Third-Party Contract Requirements", "family": "TPM", "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting its needs to protect its Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -22,7 +22,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.\n▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its TAASD.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -121,9 +121,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -290,8 +290,22 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.07.06.a", "A.03.16.03.ODP[01]", - "A.03.16.03.a" + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" + ], + "general-nist-800-172-r3": [ + "03.17.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.01E.ODP[02]" ], "general-nist-800-218": [ "PO.1" @@ -357,9 +371,6 @@ "12.8.2", "12.8.5" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -433,6 +444,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SR-03(03)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(2)" + ], "usa-federal-sro-finra": [ "248.30(a)(5)(ii)" ], @@ -450,54 +464,54 @@ "155.260(b)(2)(iv)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)", - "164.502(a)(4)(i)", - "164.502(a)(4)(ii)", - "164.502(e)(1)(i)", - "164.502(e)(2)", - "164.504(e)(2)(i)", - "164.504(e)(2)(i)(A)", - "164.504(e)(2)(i)(B)", - "164.504(e)(2)(ii)(J)", - "164.504(e)(4)(i)(B)(ii)(B)(1)", - "164.504(e)(4)(i)(B)(ii)(B)(2)", - "164.504(f)(1)(i)", - "164.504(f)(2)(i)", - "164.504(f)(2)(ii)", - "164.504(f)(2)(ii)(A)", - "164.504(f)(2)(ii)(B)", - "164.504(f)(2)(ii)(C)", - "164.504(f)(2)(ii)(D)", - "164.504(f)(2)(ii)(E)", - "164.504(f)(2)(ii)(F)", - "164.504(f)(2)(ii)(G)", - "164.504(f)(2)(ii)(H)", - "164.504(f)(2)(ii)(I)", - "164.504(f)(2)(ii)(J)", - "164.504(f)(2)(iii)(A)", - "164.504(f)(2)(iii)(B)", - "164.504(f)(2)(iii)(C)", - "164.504(f)(3)(i)", - "164.504(f)(3)(ii)", - "164.504(f)(3)(iii)", - "164.504(f)(3)(iv)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)", + "§ 164.502(a)(4)(i)", + "§ 164.502(a)(4)(ii)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(2)", + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(i)(A)", + "§ 164.504(e)(2)(i)(B)", + "§ 164.504(e)(2)(ii)(J)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(1)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(2)", + "§ 164.504(f)(1)(i)", + "§ 164.504(f)(2)(i)", + "§ 164.504(f)(2)(ii)", + "§ 164.504(f)(2)(ii)(A)", + "§ 164.504(f)(2)(ii)(B)", + "§ 164.504(f)(2)(ii)(C)", + "§ 164.504(f)(2)(ii)(D)", + "§ 164.504(f)(2)(ii)(E)", + "§ 164.504(f)(2)(ii)(F)", + "§ 164.504(f)(2)(ii)(G)", + "§ 164.504(f)(2)(ii)(H)", + "§ 164.504(f)(2)(ii)(I)", + "§ 164.504(f)(2)(ii)(J)", + "§ 164.504(f)(2)(iii)(A)", + "§ 164.504(f)(2)(iii)(B)", + "§ 164.504(f)(2)(iii)(C)", + "§ 164.504(f)(3)(i)", + "§ 164.504(f)(3)(ii)", + "§ 164.504(f)(3)(iii)", + "§ 164.504(f)(3)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "3.3.1.g", @@ -584,9 +598,9 @@ "2447(b)(6)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8", + "3.2.3.8(a)", + "3.2.3.8(b)" ], "emea-eu-dora-2023": [ "Article 28.1(a)", @@ -644,28 +658,21 @@ "9.4" ], "emea-deu-c5-2020": [ - "HR-06", - "PI-02", - "SSO-02", - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "11.1", - "11.3", - "11.10", - "16.2", - "19.5", - "22.4", - "25.17" - ], - "emea-pol-act-29-1997": [ - "31" + "UP-01-BP1", + "UP-01-BP6", + "UP-03", + "OIS-03", + "DLL-01", + "DLL-01-BP1", + "DLL-01-BP2", + "DLL-01-BP3", + "DLL-01-BP4", + "BCM-05" ], "emea-qat-pdppl-2020": [ - "12" + "3.11.8" ], "emea-sau-cscc-1-2019": [ - "4-1-1", "4-1-1-1", "4-1-1-2" ], @@ -674,7 +681,6 @@ "4-2-5" ], "emea-sau-ecc-1-2018": [ - "4-1-2", "4-1-2-1", "4-1-2-2", "4-1-2-3" @@ -687,21 +693,26 @@ "Article 8" ], "emea-sau-sacs-002-2022": [ - "TPC-25" - ], - "emea-srb-act-9-2018": [ - "5", - "11" - ], - "emea-zaf-popia-2013": [ - "20" - ], - "emea-esp-decree-1720-2007": [ - "20", - "21" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]" + "VII.A.TPC-17", + "VII.A.TPC-23-BP2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.4.1.4.b", + "3.4.1.4.c", + "3.4.1.5", + "3.4.1.5.a", + "3.4.1.5.b", + "3.4.1.5.c", + "3.4.1.5.d", + "3.4.1.5.e", + "3.4.1.5.f", + "3.4.1.5.g" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.3", + "mp.com.2", + "mp.com.3" ], "emea-gbr-def-stan-05-138-2024": [ "1401", @@ -719,7 +730,7 @@ "1401", "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0072", "ISM-1395", "ISM-1451", @@ -733,31 +744,27 @@ ], "apac-aus-ps-cps-230-2023": [ "15", + "16(f)", + "54", "54(a)", "54(b)", "54(c)", "54(d)", "54(e)", "54(f)", - "54(g)", + "55", "55(a)", "55(b)", - "55(c)" - ], - "apac-aus-ps-cps-234-2019": [ - "16", - "20", - "28" + "55(c)", + "56", + "56(a)", + "56(b)", + "56(c)", + "56(d)" ], "apac-chn-cybersecurity-law-2017": [ "Article 36" ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)", - "42" - ], "apac-ind-dpdpa-2023": [ "8(7)(b)" ], @@ -767,29 +774,6 @@ "GV.SC.S8", "PR.AT.S3" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], "apac-jpn-ismap": [ "6.3.P", "7.1.1.11", @@ -834,7 +818,15 @@ "15.1.3.11.P", "15.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.24", + "10.25", + "10.46", + "10.48", + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP09", "HHSP36", "HHSP72", @@ -842,30 +834,28 @@ "HML36", "HML72" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS06" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP63", "HSUP68" ], "apac-nzl-ism-3-9": [ "2.3.30.C.01", + "20.1.20.C.05", + "20.1.23.C.02", + "20.1.23.C.03", + "20.1.24.C.01", + "20.1.25.C.01", "23.2.19.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "43" - ], "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2", - "3.4.3" + "3.4.2" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.26", - "4.28" + "americas-bmu-mba-coc-2020": [ + "5.10", + "5.11-BP2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.8.1" ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", @@ -877,9 +867,6 @@ "03.16.03.C", "03.17.02", "03.17.03.B" - ], - "americas-mex-fdpa-2010": [ - "21" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-06.json b/docs/api/controls/TPM-06.json index 4c61f825..ca47868f 100644 --- a/docs/api/controls/TPM-06.json +++ b/docs/api/controls/TPM-06.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to control personnel security requirements including security roles and responsibilities for third-party providers.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -115,7 +115,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -177,23 +178,18 @@ "5.1.4(c)", "10.2.1" ], - "emea-isr-cmo-1-0": [ - "11.1", - "11.3", - "18.10", - "19.5" + "emea-esp-decree-311-2022": [ + "Article 13(5)" ], - "apac-aus-ism-2024-june": [ - "ISM-1569" + "emea-esp-ccn-stic-825-2026": [ + "org.4", + "op.ext.1" ], - "apac-chn-pipl-2021": [ - "52" + "apac-aus-ism-2026-march": [ + "ISM-1569" ], "apac-ind-sebi-2024": [ "PR.AT.S3" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-07.json b/docs/api/controls/TPM-07.json index d89bbebb..fed9fe57 100644 --- a/docs/api/controls/TPM-07.json +++ b/docs/api/controls/TPM-07.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of organizational information.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of organizational information. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -77,7 +77,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -91,22 +92,15 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" ], - "emea-deu-c5-2020": [ - "SSO-04" + "apac-mys-bnm-rmit-2025": [ + "10.49" ], - "emea-isr-cmo-1-0": [ - "11.5", - "11.11" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP73", "HML73" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP64" - ], - "amaericas-can-osfi-self-assessment": [ - "4.27" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-08.json b/docs/api/controls/TPM-08.json index 3b40ad0d..48aac372 100644 --- a/docs/api/controls/TPM-08.json +++ b/docs/api/controls/TPM-08.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -100,9 +100,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -118,7 +118,7 @@ "CC9.2-POF13" ], "general-cis-csc-8-1": [ - "15.0", + "15", "15.6" ], "general-cis-csc-8-1-ig3": [ @@ -209,7 +209,9 @@ "03.17.02" ], "general-nist-800-171a-r3": [ - "A.03.16.03.c" + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]" ], "general-nist-csf-2-0": [ "GV.SC-07", @@ -254,10 +256,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.4" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -315,7 +313,7 @@ "500.11(a)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(9)" + "3.2.3.9" ], "emea-eu-dora-2023": [ "Article 28.6", @@ -329,13 +327,17 @@ "5.1.7(b)", "5.1.7(c)" ], + "emea-deu-bsrit-2017": [ + "9.3" + ], "emea-deu-c5-2020": [ - "SSO-04", - "SSO-05" + "DLL-02", + "DLL-02-BP1", + "DLL-02-BP2", + "DLL-02-BP3" ], - "emea-isr-cmo-1-0": [ - "11.4", - "11.5" + "emea-qat-pdppl-2020": [ + "3.11.8" ], "emea-sau-cgiot-2024": [ "4-1-6" @@ -346,23 +348,21 @@ "emea-sau-pdpl-2023": [ "Article 8" ], - "apac-aus-ism-2024-june": [ - "ISM-1793" + "emea-sau-sama-csf-1-2017": [ + "3.3.11.6" ], - "apac-aus-ps-cps-230-2023": [ - "58(a)", - "58(b)", - "58(c)" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2", + "mp.com.2", + "mp.com.3" ], - "apac-aus-ps-cps-234-2019": [ - "28" + "apac-aus-ism-2026-march": [ + "ISM-1793" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "apac-jpn-ppi-2020": [ - "24(3)" - ], "apac-jpn-ismap": [ "13.1.2.1", "15.2.1", @@ -380,15 +380,15 @@ "15.2.1.12", "15.2.1.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.49" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HHSP73", "HML25", "HML73" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS04" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP64", "HSUP67" @@ -396,9 +396,6 @@ "apac-sgp-mas-trm-2021": [ "3.4.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.27" - ], "americas-can-itsp-10-171-2025": [ "03.16.03.C", "03.17.02" diff --git a/docs/api/controls/TPM-09.json b/docs/api/controls/TPM-09.json index 7b0ac8a7..62d189fb 100644 --- a/docs/api/controls/TPM-09.json +++ b/docs/api/controls/TPM-09.json @@ -18,9 +18,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -115,7 +115,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -150,6 +151,9 @@ "general-nist-800-171-r3": [ "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.17.02[06]" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07", @@ -162,10 +166,6 @@ "general-pci-dss-4-0-1": [ "A3.3.1.2" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -189,21 +189,20 @@ "Article 21.3", "Article 21.4" ], - "emea-deu-c5-2020": [ - "SSO-04" - ], "emea-sau-cgiot-2024": [ "4-1-6" ], - "emea-sau-ecc-1-2018": [ - "4-1-2-3" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "amaericas-can-osfi-self-assessment": [ - "2.7", - "4.27" + "apac-jpn-appi-2020": [ + "IV.5.53(4)" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.3" ], "americas-can-itsp-10-171-2025": [ "03.17.02" diff --git a/docs/api/controls/TPM-10.json b/docs/api/controls/TPM-10.json index 6c43be1e..17755a8a 100644 --- a/docs/api/controls/TPM-10.json +++ b/docs/api/controls/TPM-10.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to control changes to services by suppliers, taking into account the criticality of business TAASD that are in scope by the third-party.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -116,7 +116,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -204,13 +205,13 @@ "03.16.01", "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.16.01", + "A.03.17.02[06]" + ], "general-nist-csf-2-0": [ "GV.SC-08" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-shared-assessments-sig-2025": [ "K.6" ], @@ -260,21 +261,17 @@ "5.1.7(d)" ], "emea-deu-c5-2020": [ - "SSO-04", - "SSO-05" + "OIS-03" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.2 [OP.EXT.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1794" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "apac-jpn-ppi-2020": [ - "24(3)" - ], "apac-jpn-ismap": [ "15.2.1.14", "15.2.1.15", @@ -283,9 +280,6 @@ "15.2.2.2", "15.2.2.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.27" - ], "americas-can-itsp-10-171-2025": [ "03.16.01", "03.17.02" diff --git a/docs/api/controls/TPM-11.json b/docs/api/controls/TPM-11.json index efb0b924..1b1c175d 100644 --- a/docs/api/controls/TPM-11.json +++ b/docs/api/controls/TPM-11.json @@ -20,7 +20,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure response/recovery planning and testing are conducted with critical suppliers/providers.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure response/recovery planning and testing are conducted with critical suppliers/providers. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -115,7 +115,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -197,16 +198,13 @@ "CIP-013-2 1.2.2" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)(b)" - ], - "emea-isr-cmo-1-0": [ - "25.17" + "3.2.3.8(b)" ], "emea-sau-ecc-1-2018": [ "4-1-2-2" ], - "amaericas-can-osfi-self-assessment": [ - "4.28" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/TPM-12.1.json b/docs/api/controls/TPM-12.1.json index 2b1f83a3..1b61f644 100644 --- a/docs/api/controls/TPM-12.1.json +++ b/docs/api/controls/TPM-12.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to periodically review External Service Providers (ESP) for changes that affect Foreign Ownership, Control or Influence (FOCI).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -55,9 +55,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/TPM-12.2.json b/docs/api/controls/TPM-12.2.json index 198f3cdc..bc83c5c1 100644 --- a/docs/api/controls/TPM-12.2.json +++ b/docs/api/controls/TPM-12.2.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to contractually impose safeguards (e.g., additional controls, access modification, contract termination, etc.) from Foreign Ownership, Control or Influence (FOCI) concerns to ensure that:\n(1) Unauthorized access to sensitive and/or regulated data is prevented; and \n(2) Performance of contracts is not adversely affected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -61,9 +61,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/TPM-12.json b/docs/api/controls/TPM-12.json index 6121fe0d..bd95d53e 100644 --- a/docs/api/controls/TPM-12.json +++ b/docs/api/controls/TPM-12.json @@ -3,7 +3,7 @@ "title": "Foreign Ownership, Control or Influence (FOCI)", "family": "TPM", "description": "Mechanisms exist to minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices.", - "scf_question": "Does the organization minimize risk associate with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices?", + "scf_question": "Does the organization minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -57,9 +57,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/VPM-01.1.json b/docs/api/controls/VPM-01.1.json index 8e84fa5a..8d788b01 100644 --- a/docs/api/controls/VPM-01.1.json +++ b/docs/api/controls/VPM-01.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to define and manage the scope for its attack surface management activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -158,7 +159,14 @@ "03.14.01.a" ], "general-nist-800-171a-r3": [ - "A.03.11.02.a[01]" + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" + ], + "general-nist-800-172-r3": [ + "03.12.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.12.01E.ODP[02]" ], "general-nist-csf-2-0": [ "PR.PS-02" @@ -218,9 +226,6 @@ "11.3.2", "11.3.2.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -254,6 +259,9 @@ "SA-11(06)", "SA-11(07)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-irs-1075-2021": [ "SA-11(CE-6)" ], @@ -263,28 +271,24 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.5(a)(1)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], "emea-sau-cscc-1-2019": [ "2-10-1-1" ], "emea-sau-ecc-1-2018": [ - "2-11-3-1", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ - "2-9-1-1" + "2-9-1-1", + "2-10-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-27", - "TPC-28", - "TPC-29" + "apac-mys-bnm-rmit-2025": [ + "10.18" ], "apac-nzl-ism-3-9": [ "6.2.4.C.01" ], "apac-sgp-mas-trm-2021": [ + "6.1.4", "13.1.2" ], "americas-can-itsp-10-171-2025": [ diff --git a/docs/api/controls/VPM-01.json b/docs/api/controls/VPM-01.json index 8aae1090..adcad230 100644 --- a/docs/api/controls/VPM-01.json +++ b/docs/api/controls/VPM-01.json @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -132,9 +133,9 @@ "CC9.2-POF13" ], "general-cis-csc-8-1": [ - "7.0", + "7", "7.1", - "18.0" + "18" ], "general-cis-csc-8-1-ig1": [ "7.1" @@ -269,7 +270,9 @@ "3.14.1[f]" ], "general-nist-800-171a-r3": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" ], "general-nist-csf-2-0": [ "ID.RA-01", @@ -313,9 +316,6 @@ "6.3.1", "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "T.2" ], @@ -455,8 +455,8 @@ "SI-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(21)", - "3.4.4(36)(a)" + "3.3.3.21", + "3.4.4.36(a)" ], "emea-eu-dora-2023": [ "Article 9.4(f)", @@ -473,64 +473,46 @@ "6.10.2(a)", "6.10.2(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.1", - "22.2" + "RB-17", + "RB-17-BP2" ], "emea-sau-cscc-1-2019": [ "2-3-1-3", - "2-9", + "2-9-1", "2-9-2" ], "emea-sau-cgiot-2024": [ "2-9-1" ], "emea-sau-ecc-1-2018": [ - "2-3-4", "2-10-1", "2-10-2", - "2-10-3", - "2-10-4", - "2-11-1", - "2-11-2", - "2-11-3", - "2-11-4", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ - "2-9", "2-9-1", - "2-9-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-11" + "2-9-2", + "2-10-1", + "2-10-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.17" - ], - "emea-zaf-popia-2013": [ - "19" + "3.3.17", + "3.3.17.1", + "3.3.17.3", + "3.3.17.3.a", + "3.3.17.3.b", + "3.3.17.3.c", + "3.3.17.3.d", + "3.3.17.3.e", + "3.3.17.3.f" + ], + "emea-esp-decree-311-2022": [ + "Article 12(6)(i)" ], "emea-gbr-caf-4-0": [ "B4.d" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" - ], "emea-gbr-def-stan-05-138-2024": [ "2402", "2405" @@ -547,7 +529,7 @@ "2402", "2405" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1143", "ISM-1163", "ISM-1460", @@ -580,7 +562,13 @@ "12.6.1.17", "12.6.1.18.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17", + "10.18", + "10.19", + "10.31" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HHSP26", "HML19", @@ -592,22 +580,20 @@ "apac-nzl-ism-3-9": [ "6.2.4.C.01" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" - ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "7.4.1", - "7.4.2" + "6.1.4" ], - "americas-bmu-mba-coc-2020": [ - "6.16" + "americas-arg-ppd-2018": [ + "E" ], "americas-can-osfi-b13-2022": [ "2.6", "3.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.A", "03.14.01.A" diff --git a/docs/api/controls/VPM-02.1.json b/docs/api/controls/VPM-02.1.json new file mode 100644 index 00000000..4898b21a --- /dev/null +++ b/docs/api/controls/VPM-02.1.json @@ -0,0 +1,111 @@ +{ + "control_id": "VPM-02.1", + "title": "Known Exploited Vulnerabilities (KEV) Mitigations", + "family": "VPM", + "description": "Mechanisms exist to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions.", + "scf_question": "Does the organization prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions?", + "relative_weight": 7, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ IT and/or cybersecurity personnel apply software patches through an informal process.", + "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.\n▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Subscribe to CISA KEV catalog alerts (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)\n∙ Prioritize patching KEV-listed vulnerabilities within CISA timeframes", + "small": "∙ CISA KEV catalog subscription and monitoring\n∙ Priority patching for KEV-listed vulnerabilities within CISA-defined windows", + "medium": "∙ KEV-integrated vulnerability management program\n∙ CISA KEV catalog integration with vulnerability scanner\n∙ Accelerated remediation SLAs for KEV items", + "large": "∙ Enterprise vulnerability management with KEV prioritization\n∙ Automated KEV alerting and remediation tracking\n∙ Defined KEV remediation SLAs", + "enterprise": "∙ Enterprise KEV management program\n∙ Automated CISA KEV catalog integration\n∙ Real-time KEV exposure tracking and alerting\n∙ Risk-based KEV remediation with board-level visibility for material exposures" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Vulnerability & Patch Management", + "crosswalks": {} +} \ No newline at end of file diff --git a/docs/api/controls/VPM-02.json b/docs/api/controls/VPM-02.json index ad298cd6..3df0923c 100644 --- a/docs/api/controls/VPM-02.json +++ b/docs/api/controls/VPM-02.json @@ -21,11 +21,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that vulnerabilities are properly identified, tracked and remediated.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -113,7 +113,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -222,7 +223,16 @@ "3.11.3[b]" ], "general-nist-800-171a-r3": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.b", + "A.03.12.02.a.02" + ], + "general-nist-800-172-r3": [ + "03.11.11E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.11E.ODP[01]", + "DS-A.03.11.11E[02]" ], "general-nist-800-218": [ "RV.2.2" @@ -277,9 +287,6 @@ "11.3.2", "11.3.2.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -323,6 +330,9 @@ "PM-04", "SC-18(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-irs-1075-2021": [ "PM-4", "SC-18(CE-1)" @@ -349,6 +359,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-04" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(6)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(2)" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], @@ -357,15 +373,6 @@ "6.10.2(c)", "6.10.3" ], - "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.8", - "22.11", - "22.13" - ], "emea-sau-cscc-1-2019": [ "2-9-1-2" ], @@ -373,18 +380,16 @@ "2-9-1" ], "emea-sau-ecc-1-2018": [ - "2-10-3-3", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ "2-9-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-11", - "TPC-91" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" + "VII.B.TPC-91", + "VII.B.TPC-91-BP1", + "VII.B.TPC-91-BP2", + "VII.B.TPC-91-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2402" @@ -398,8 +403,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2402" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-aus-ism-2026-march": [ + "ISM-1902", + "ISM-1903", + "ISM-1904" ], "apac-ind-sebi-2024": [ "PR.MA.S3" @@ -407,7 +414,10 @@ "apac-jpn-ismap": [ "12.6.1.14" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HHSP59", "HML19", @@ -422,20 +432,21 @@ "23.2.19.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" + "4.2(a)" ], "apac-sgp-mas-trm-2021": [ + "6.1.4", + "13.6.1", "13.6.1(a)", "13.6.1(b)", "13.6.1(c)" ], - "amaericas-can-osfi-self-assessment": [ - "2.7" - ], "americas-can-osfi-b13-2022": [ "2.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", "03.12.02.A.02", diff --git a/docs/api/controls/VPM-03.1.json b/docs/api/controls/VPM-03.1.json index c7306a0f..4e2cf773 100644 --- a/docs/api/controls/VPM-03.1.json +++ b/docs/api/controls/VPM-03.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify, assess, prioritize and document the potential impact(s) and likelihood(s) of applicable internal and external threats exploiting known vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -90,6 +91,10 @@ ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.5(c)" + ], + "emea-deu-c5-2020": [ + "RB-17-BP1", + "RB-19" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-03.json b/docs/api/controls/VPM-03.json index 3806d551..1981c577 100644 --- a/docs/api/controls/VPM-03.json +++ b/docs/api/controls/VPM-03.json @@ -21,9 +21,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -95,7 +95,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -121,6 +122,9 @@ "general-nist-800-171-r3": [ "03.11.02.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.a[01]" + ], "general-nist-csf-2-0": [ "ID.RA-08" ], @@ -152,9 +156,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-sparta": [ "CM0016" ], @@ -174,6 +175,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(2)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.E.2.b" ], @@ -184,29 +188,25 @@ "500.5(c)" ], "emea-deu-c5-2020": [ - "OPS-18", - "OPS-22", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.8" + "RB-17-BP1", + "RB-19" ], "emea-sau-cscc-1-2019": [ "2-9-1-2" ], "emea-sau-ecc-1-2018": [ - "2-10-3-2" - ], - "emea-sau-otcc-1-2022": [ - "2-9-1-2", - "2-9-1-3" + "2-10-3-2", + "2-10-3-3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163" ], "apac-ind-sebi-2024": [ "PR.MA.S3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "americas-can-osfi-b13-2022": [ "3.1.3" ], diff --git a/docs/api/controls/VPM-04.1.json b/docs/api/controls/VPM-04.1.json index f7cb91a8..a6d7b761 100644 --- a/docs/api/controls/VPM-04.1.json +++ b/docs/api/controls/VPM-04.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to install the latest stable version of any software and/or security-related updates on all applicable systems.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -86,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -117,23 +118,16 @@ "usa-state-vt-act-171-2018": [ "2447(c)(6)" ], - "emea-isr-cmo-1-0": [ - "12.22" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1467", "ISM-1483" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP44", "HML44" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS08" - ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "americas-can-osfi-self-assessment-2": [ + "2.6.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-04.2.json b/docs/api/controls/VPM-04.2.json index 4e303619..5925dcbf 100644 --- a/docs/api/controls/VPM-04.2.json +++ b/docs/api/controls/VPM-04.2.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and correct flaws related to the collection, usage, processing or dissemination of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -74,15 +74,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", - "crosswalks": { - "general-scf-dpmp-2025": [ - "5.15" - ], - "emea-zaf-popia-2013": [ - "4" - ] - } + "crosswalks": {} } \ No newline at end of file diff --git a/docs/api/controls/VPM-04.3.json b/docs/api/controls/VPM-04.3.json index ffb8f60d..56da2b1f 100644 --- a/docs/api/controls/VPM-04.3.json +++ b/docs/api/controls/VPM-04.3.json @@ -25,7 +25,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Documented deferred patch register (spreadsheet)\n∙ Management sign-off for deferred patches with interim mitigations documented", + "small": "∙ Formal deferred patch register\n∙ Risk-based justification and management approval\n∙ Compensating control documentation", + "medium": "∙ Deferred patching exception process within vulnerability management program\n∙ Compensating control requirements for deferred patches\n∙ GRC platform for exception tracking", + "large": "∙ Enterprise deferred patch management process\n∙ Formal exception approval with compensating controls\n∙ GRC platform for tracking and reporting\n∙ Regular review of aged deferred patches", + "enterprise": "∙ Enterprise patch exception management program\n∙ Automated deferred patch tracking and escalation\n∙ Compensating control validation for all exceptions\n∙ Board-level reporting on material deferred patches" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -80,7 +86,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -95,6 +102,9 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-04.json b/docs/api/controls/VPM-04.json index 5245ad20..7bbe7a22 100644 --- a/docs/api/controls/VPM-04.json +++ b/docs/api/controls/VPM-04.json @@ -19,11 +19,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -108,7 +108,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -116,7 +117,7 @@ "CC4.2" ], "general-cis-csc-8-1": [ - "7.0", + "7", "7.7", "12.1", "18.3" @@ -171,11 +172,11 @@ ], "general-nist-800-171-r3": [ "03.11.02.b", - "03.14.01.a", - "03.14.01.b" + "03.14.01.a" ], "general-nist-800-171a-r3": [ - "A.03.11.02.b" + "A.03.11.02.b", + "A.03.14.01.a[03]" ], "general-owasp-top-10-2025": [ "A05:2025" @@ -205,9 +206,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -260,48 +258,32 @@ "Article 21.4" ], "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.6", - "22.11" + "RB-17-BP2", + "RB-19", + "RB-21" ], "emea-sau-cscc-1-2019": [ "2-9-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-10-3-3" - ], - "emea-sau-otcc-1-2022": [ - "2-9-1-2", - "2-9-1-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1801" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-mys-bnm-rmit-2025": [ + "10.18" ], "apac-nzl-ism-3-9": [ "6.2.6.C.01", "23.2.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.7" - ], "americas-can-osfi-b13-2022": [ "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", - "03.14.01.A", - "03.14.01.B" + "03.14.01.A" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-05.1.json b/docs/api/controls/VPM-05.1.json index b4614f7d..62b41fae 100644 --- a/docs/api/controls/VPM-05.1.json +++ b/docs/api/controls/VPM-05.1.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to centrally-manage the flaw remediation process.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to centrally-manage the flaw remediation process. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -103,7 +103,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -252,23 +253,17 @@ "Article 21.4" ], "emea-deu-c5-2020": [ - "PSS-03" + "RB-17-BP2" ], - "emea-isr-cmo-1-0": [ - "12.21", - "22.11", - "22.12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-91" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0298", "ISM-0300" ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "apac-mys-bnm-rmit-2025": [ + "10.19" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.6" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-05.2.json b/docs/api/controls/VPM-05.2.json index 85060d5a..03c81d3f 100644 --- a/docs/api/controls/VPM-05.2.json +++ b/docs/api/controls/VPM-05.2.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically determine the state of system components with regard to flaw remediation.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically determine the state of system components with regard to flaw remediation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -64,7 +64,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -141,10 +142,6 @@ ], "usa-federal-cms-marse-2-0": [ "SI-2(2)" - ], - "emea-isr-cmo-1-0": [ - "22.11", - "22.12" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-05.3.json b/docs/api/controls/VPM-05.3.json index 631fafbf..81a48e25 100644 --- a/docs/api/controls/VPM-05.3.json +++ b/docs/api/controls/VPM-05.3.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to track the effectiveness of remediation operations through metrics reporting.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -70,7 +70,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -112,18 +113,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.E.2.a" - ], - "emea-deu-c5-2020": [ - "OPS-19" - ], - "emea-isr-cmo-1-0": [ - "12.22" - ], - "emea-sau-sacs-002-2022": [ - "TPC-91" - ], - "apac-sgp-mas-trm-2021": [ - "13.6.1(b)" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-05.4.json b/docs/api/controls/VPM-05.4.json index d5dfe63a..7f148f4d 100644 --- a/docs/api/controls/VPM-05.4.json +++ b/docs/api/controls/VPM-05.4.json @@ -84,7 +84,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -137,6 +138,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SI-02(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(ii)" + ], "usa-federal-irs-1075-2021": [ "SI-2(CE-4)", "SI-2(CE-5)" @@ -147,21 +151,11 @@ "emea-sau-ecc-1-2018": [ "2-10-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-78" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "3-BP3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1467" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)" - ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-05.5.json b/docs/api/controls/VPM-05.5.json index f5c89fa3..8d9aea39 100644 --- a/docs/api/controls/VPM-05.5.json +++ b/docs/api/controls/VPM-05.5.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { diff --git a/docs/api/controls/VPM-05.6.json b/docs/api/controls/VPM-05.6.json index 24301861..94f24e8a 100644 --- a/docs/api/controls/VPM-05.6.json +++ b/docs/api/controls/VPM-05.6.json @@ -20,7 +20,7 @@ "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform due diligence on software and/or firmware update stability by conducting pre-production testing in a non-production environment.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -109,6 +110,12 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2405" + ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], + "apac-sgp-mas-trm-2021": [ + "7.4.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-05.7.json b/docs/api/controls/VPM-05.7.json index 52fe78c7..6daac3dc 100644 --- a/docs/api/controls/VPM-05.7.json +++ b/docs/api/controls/VPM-05.7.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform out-of-cycle software and/or firmware updates to address time-sensitive remediations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { diff --git a/docs/api/controls/VPM-05.8.json b/docs/api/controls/VPM-05.8.json index a89ee0f8..a0b52bb1 100644 --- a/docs/api/controls/VPM-05.8.json +++ b/docs/api/controls/VPM-05.8.json @@ -84,7 +84,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -99,6 +100,12 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.1(c)" + ], + "emea-sau-otcc-1-2022": [ + "2-4-1-15" + ], + "apac-aus-cop-sitc-2020": [ + "3" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-05.json b/docs/api/controls/VPM-05.json index 4a3f34e2..8148c33b 100644 --- a/docs/api/controls/VPM-05.json +++ b/docs/api/controls/VPM-05.json @@ -3,7 +3,7 @@ "title": "Software & Firmware Patching", "family": "VPM", "description": "Mechanisms exist to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", - "scf_question": "Does the organization conduct software patching for all deployed systems, applications and firmware?", + "scf_question": "Does the organization conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -19,11 +19,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -110,7 +110,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -179,7 +180,7 @@ "general-iso-27018-2025": [ "8.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1027", @@ -335,10 +336,9 @@ ], "general-nist-800-171a-r3": [ "A.03.11.02.b", + "A.03.12.02.a.02", "A.03.14.01.ODP[01]", "A.03.14.01.ODP[02]", - "A.03.14.01.a[01]", - "A.03.14.01.a[02]", "A.03.14.01.a[03]", "A.03.14.01.b[01]", "A.03.14.01.b[02]" @@ -370,9 +370,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "N.4" ], @@ -426,6 +423,10 @@ "SI-02(04)", "SI-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)", + "101.650(e)(3)(i)" + ], "usa-federal-irs-1075-2021": [ "SI-2", "SI-2(CE-4)", @@ -469,10 +470,7 @@ "6.6.1(a)" ], "emea-deu-c5-2020": [ - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "12.21" + "RB-17-BP2" ], "emea-sau-cscc-1-2019": [ "2-3-1-3" @@ -491,11 +489,14 @@ "2-4-1-15" ], "emea-sau-sacs-002-2022": [ - "TPC-11", - "TPC-78" + "VII.A.TPC-11" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" + "3", + "3-BP4", + "3-BP4-1", + "3-BP4-2", + "3-BP4-3" ], "emea-gbr-def-stan-05-138-2024": [ "2402", @@ -521,7 +522,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1143", "ISM-1493", "ISM-1690", @@ -532,10 +533,15 @@ "ISM-1695", "ISM-1696", "ISM-1697", - "ISM-1751" + "ISM-1751", + "ISM-1876", + "ISM-1877", + "ISM-1878", + "ISM-1879", + "ISM-1901" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-aus-cop-sitc-2020": [ + "3" ], "apac-ind-sebi-2024": [ "PR.MA.S3" @@ -543,7 +549,11 @@ "apac-jpn-ismap": [ "12.6.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17", + "10.18" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HML19" ], @@ -551,29 +561,30 @@ "HSUP17" ], "apac-nzl-ism-3-9": [ + "22.1.18.C.01", "23.2.19.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" + "4.2(a)" ], "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "7.4.1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-7" ], "americas-bmu-mba-coc-2020": [ "6.16" ], - "amaericas-can-osfi-self-assessment": [ - "4.5", - "4.7", - "4.9" - ], "americas-can-osfi-b13-2022": [ "2.6", "2.6.1", "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", "03.12.02.A.02", diff --git a/docs/api/controls/VPM-06.1.json b/docs/api/controls/VPM-06.1.json index c0eb8749..8c782f30 100644 --- a/docs/api/controls/VPM-06.1.json +++ b/docs/api/controls/VPM-06.1.json @@ -83,7 +83,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -234,11 +235,8 @@ "emea-eu-nis2-annex-2024": [ "6.10.4" ], - "emea-deu-c5-2020": [ - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "22.7" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-78" ], "apac-aus-essential-8-2024": [ "ML1-P1", @@ -248,7 +246,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1808" ], "americas-can-itsp-10-171-2025": [ diff --git a/docs/api/controls/VPM-06.2.json b/docs/api/controls/VPM-06.2.json index a8f88165..2bc260a7 100644 --- a/docs/api/controls/VPM-06.2.json +++ b/docs/api/controls/VPM-06.2.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify the breadth and depth of coverage for vulnerability scanning that define the system components scanned and types of vulnerabilities that are checked for.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify the breadth and depth of coverage for vulnerability scanning that define the system components scanned and types of vulnerabilities that are checked for. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -155,14 +156,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "RA-05 (03)" ], - "emea-isr-cmo-1-0": [ - "22.6" - ], "emea-sau-cscc-1-2019": [ - "2-9-2-1" - ], - "emea-sau-ecc-1-2018": [ - "2-11-3-1" + "2-9-2" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-06.3.json b/docs/api/controls/VPM-06.3.json index e03427a4..3646829f 100644 --- a/docs/api/controls/VPM-06.3.json +++ b/docs/api/controls/VPM-06.3.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement privileged access authorization for selected vulnerability scanning activities.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement privileged access authorization for selected vulnerability scanning activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -147,9 +148,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "RA-05 (05)" - ], - "emea-isr-cmo-1-0": [ - "22.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-06.4.json b/docs/api/controls/VPM-06.4.json index cad72c6e..f71c648a 100644 --- a/docs/api/controls/VPM-06.4.json +++ b/docs/api/controls/VPM-06.4.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically compare the results of vulnerability scans over time to determine trends in system vulnerabilities.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically compare the results of vulnerability scans over time to determine trends in system vulnerabilities. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -80,7 +80,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -116,12 +117,6 @@ ], "general-swift-cscf-2025": [ "2.7" - ], - "emea-deu-c5-2020": [ - "OPS-20" - ], - "emea-isr-cmo-1-0": [ - "22.10" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-06.5.json b/docs/api/controls/VPM-06.5.json index a24eecab..958dd104 100644 --- a/docs/api/controls/VPM-06.5.json +++ b/docs/api/controls/VPM-06.5.json @@ -18,9 +18,9 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to review historical event logs to determine if identified vulnerabilities have been previously exploited.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to review historical event logs to determine if identified vulnerabilities have been previously exploited. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -108,12 +109,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "RA-05(08)" - ], - "emea-deu-c5-2020": [ - "OPS-20" - ], - "emea-isr-cmo-1-0": [ - "22.10" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-06.6.json b/docs/api/controls/VPM-06.6.json index e9e9e18e..b7bf8ad0 100644 --- a/docs/api/controls/VPM-06.6.json +++ b/docs/api/controls/VPM-06.6.json @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -142,11 +143,8 @@ "11.3.2", "11.3.2.1" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.3" + "emea-sau-cscc-1-2019": [ + "2-9-1-1" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-06.7.json b/docs/api/controls/VPM-06.7.json index eccbf8de..763f24a2 100644 --- a/docs/api/controls/VPM-06.7.json +++ b/docs/api/controls/VPM-06.7.json @@ -98,7 +98,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -130,11 +131,11 @@ "11.3.1.2", "11.3.1.3" ], - "emea-deu-c5-2020": [ - "PSS-02" + "emea-sau-cscc-1-2019": [ + "2-9-1-1" ], - "emea-isr-cmo-1-0": [ - "22.3" + "americas-bmu-mba-coc-2020": [ + "6.15-BP3" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-06.8.json b/docs/api/controls/VPM-06.8.json index 14bfd947..e29c3d97 100644 --- a/docs/api/controls/VPM-06.8.json +++ b/docs/api/controls/VPM-06.8.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to define what information is allowed to be discoverable by adversaries and take corrective actions to remediate non-compliant Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -54,7 +54,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -82,6 +83,12 @@ "general-nist-800-160-vol-2-r1": [ "RA-05(04)" ], + "general-nist-800-172-r3": [ + "03.11.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.11E[01]" + ], "general-pci-dss-4-0-1": [ "1.4.5" ], @@ -102,6 +109,9 @@ ], "apac-nzl-ism-3-9": [ "14.1.14.C.01" + ], + "americas-bmu-mba-coc-2020": [ + "6.15-BP4" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-06.9.json b/docs/api/controls/VPM-06.9.json index 67eab06d..b9de05b5 100644 --- a/docs/api/controls/VPM-06.9.json +++ b/docs/api/controls/VPM-06.9.json @@ -51,7 +51,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { diff --git a/docs/api/controls/VPM-06.json b/docs/api/controls/VPM-06.json index 2e1cc8f5..8b87704d 100644 --- a/docs/api/controls/VPM-06.json +++ b/docs/api/controls/VPM-06.json @@ -23,7 +23,7 @@ "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel configure technologies to update vulnerability scanning tools.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -89,7 +89,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -148,7 +149,7 @@ "general-iso-27018-2025": [ "8.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011.001", "T1021.001", "T1021.003", @@ -306,7 +307,8 @@ "3.11.2" ], "general-nist-800-171-r3": [ - "03.11.02.a" + "03.11.02.a", + "03.14.01.a" ], "general-nist-800-171a": [ "3.11.2[a]", @@ -323,8 +325,8 @@ "A.03.11.02.a[02]", "A.03.11.02.a[03]", "A.03.11.02.a[04]", - "A.03.11.02.c[01]", - "A.03.11.02.c[02]" + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" ], "general-nist-csf-2-0": [ "ID.RA-01" @@ -411,6 +413,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "RA-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(vi)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(2)", "314.4(d)(2)(ii)" @@ -464,20 +469,9 @@ "emea-eu-nis2-annex-2024": [ "6.10.2(b)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-22", - "PSS-02", - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "3.4", - "9.25", - "12.30", - "22.3", - "22.6" + "RB-17-BP1", + "RB-21" ], "emea-sau-cscc-1-2019": [ "2-9-1-1", @@ -489,8 +483,11 @@ "emea-sau-ecc-1-2018": [ "2-10-3-1" ], + "emea-sau-otcc-1-2022": [ + "2-9-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-85" + "VII.B.TPC-85" ], "emea-uae-niaf-2023": [ "3.1.3" @@ -515,7 +512,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163", "ISM-1698", "ISM-1699", @@ -523,12 +520,17 @@ "ISM-1701", "ISM-1702", "ISM-1703", - "ISM-1752" + "ISM-1752", + "ISM-1875", + "ISM-1900" ], "apac-ind-sebi-2024": [ "ID.RA.S1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "11.9" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP26", "HHSP59", "HML26", @@ -541,21 +543,18 @@ "6.2.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "13.1.1", - "13.1.2" - ], - "americas-bmu-mba-coc-2020": [ - "6.15" - ], - "amaericas-can-osfi-self-assessment": [ - "2.5" + "13.1.1" ], "americas-can-osfi-b13-2022": [ "3.1.2", "3.1.3" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.3" + ], "americas-can-itsp-10-171-2025": [ - "03.11.02.A" + "03.11.02.A", + "03.14.01.A" ] } } \ No newline at end of file diff --git a/docs/api/controls/VPM-07.1.json b/docs/api/controls/VPM-07.1.json index a149a3b8..3c038b1a 100644 --- a/docs/api/controls/VPM-07.1.json +++ b/docs/api/controls/VPM-07.1.json @@ -18,7 +18,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, use red team exercises to simulate attempts by adversaries to compromise TAASD in accordance with entity-defined rules of engagement.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize an independent assessor or penetration team to perform penetration testing.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -96,7 +96,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -182,16 +183,6 @@ "Article 27.2(c)", "Article 27.3" ], - "emea-deu-c5-2020": [ - "OPS-19", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.16", - "17.17", - "22.4", - "22.5" - ], "emea-sau-cscc-1-2019": [ "2-10-1-2" ] diff --git a/docs/api/controls/VPM-07.json b/docs/api/controls/VPM-07.json index f99ce665..1135370a 100644 --- a/docs/api/controls/VPM-07.json +++ b/docs/api/controls/VPM-07.json @@ -19,7 +19,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, conduct annual penetration testing on network segments hosting High Value Assets (HVAs).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct penetration testing on Technology Assets, Applications and/or Services (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -103,12 +103,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { "general-cis-csc-8-1": [ - "18.0", + "18", "18.1", "18.2", "18.5" @@ -171,8 +172,11 @@ "CA-08", "SA-11(05)" ], - "general-nist-800-172": [ - "3.12.1e" + "general-nist-800-172-r3": [ + "03.12.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.01E" ], "general-pci-dss-4-0-1": [ "11.4", @@ -247,6 +251,9 @@ "CA-08", "SA-11(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(2)", "314.4(d)(2)(i)" @@ -281,22 +288,12 @@ "Article 26.8(b)", "Article 26.8(c)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-19", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "3.4", - "12.30", - "17.17", - "22.4", - "22.5" + "RB-18", + "RB-18-DOAR" ], "emea-sau-cscc-1-2019": [ - "2-10", + "2-10-1", "2-10-1-1", "2-10-1-2", "2-10-2" @@ -305,21 +302,19 @@ "2-10-1" ], "emea-sau-ecc-1-2018": [ - "2-11-3-1" + "2-11-1", + "2-11-2", + "2-11-3-1", + "2-11-3-2" ], "emea-sau-otcc-1-2022": [ - "2-10", - "2-10-1", - "2-10-1-1", "2-10-1-2", - "2-10-1-3", - "2-10-1-4", - "2-10-2" + "2-10-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-27", - "TPC-28", - "TPC-29" + "VII.B.TPC-27", + "VII.B.TPC-28", + "VII.B.TPC-29" ], "emea-gbr-def-stan-05-138-2024": [ "2403" @@ -333,19 +328,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2403" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163" ], + "apac-mys-bnm-rmit-2025": [ + "11.9" + ], "apac-sgp-mas-trm-2021": [ "13.2.1", "13.2.3", "13.2.4" ], "americas-bmu-mba-coc-2020": [ - "6.15" - ], - "amaericas-can-osfi-self-assessment": [ - "2.6" + "6.15-BP1" ], "americas-can-osfi-b13-2022": [ "3.1.2" diff --git a/docs/api/controls/VPM-08.json b/docs/api/controls/VPM-08.json index a55efc58..635981af 100644 --- a/docs/api/controls/VPM-08.json +++ b/docs/api/controls/VPM-08.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a technical surveillance countermeasures survey.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -68,7 +68,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { diff --git a/docs/api/controls/VPM-09.json b/docs/api/controls/VPM-09.json index b0f80788..0d6797bc 100644 --- a/docs/api/controls/VPM-09.json +++ b/docs/api/controls/VPM-09.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to monitor logs associated with scanning activities and associated administrator accounts to ensure that those activities are limited to the timeframes of legitimate scans.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to monitor logs associated with scanning activities and associated administrator accounts to ensure that those activities are limited to the timeframes of legitimate scans. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -63,7 +63,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": {} diff --git a/docs/api/controls/VPM-10.json b/docs/api/controls/VPM-10.json index b353c24c..84fd6e39 100644 --- a/docs/api/controls/VPM-10.json +++ b/docs/api/controls/VPM-10.json @@ -18,7 +18,7 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, use red team exercises to simulate attempts by adversaries to compromise TAASD in accordance with entity-defined rules of engagement.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize \"red team\" exercises to simulate attempts by adversaries to compromise Technology Assets, Applications and/or Services (TAAS) in accordance with organization-defined rules of engagement.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize \"red team\" exercises to simulate attempts by adversaries to compromise Technology Assets, Applications and/or Services (TAAS) in accordance with organization-defined rules of engagement. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -106,7 +106,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -145,21 +146,17 @@ "usa-federal-gsa-fedramp-5-high": [ "CA-08(02)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-sau-cgiot-2024": [ "2-10-2" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-9" - ], "apac-ind-sebi-2024": [ "DE.DP.S4" ], + "apac-mys-bnm-rmit-2025": [ + "11.6" + ], "apac-sgp-mas-trm-2021": [ - "13.3.1", - "13.3.2", + "8.5.1", "13.4.1", "13.4.2" ] diff --git a/docs/api/controls/WEB-01.1.json b/docs/api/controls/WEB-01.1.json index bc5d706e..b79a9f60 100644 --- a/docs/api/controls/WEB-01.1.json +++ b/docs/api/controls/WEB-01.1.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to prevent unauthorized code from being present in a secure page as it is rendered in a client’s browser.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { diff --git a/docs/api/controls/WEB-01.json b/docs/api/controls/WEB-01.json index 4ef13040..0374ebf6 100644 --- a/docs/api/controls/WEB-01.json +++ b/docs/api/controls/WEB-01.json @@ -97,7 +97,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -111,6 +112,9 @@ "general-nist-800-171-r3": [ "03.01.22.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a" + ], "general-pci-dss-4-0-1": [ "6.4", "6.4.1", @@ -141,15 +145,8 @@ "3.3.8", "3.3.8.c" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-sau-cscc-1-2019": [ - "2-12", + "2-12-1", "2-12-1-1", "2-12-1-2" ], @@ -157,16 +154,19 @@ "2-15-1", "2-15-2", "2-15-3", + "2-15-3-2", + "2-15-3-4", + "2-15-3-5", "2-15-4" ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.2 [MP.S.2]" - ], "apac-nzl-ism-3-9": [ "14.5.6.C.01", "14.5.7.C.01", "14.5.8.C.01" ], + "apac-sgp-mas-trm-2021": [ + "14.1.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A" ] diff --git a/docs/api/controls/WEB-02.json b/docs/api/controls/WEB-02.json index 88f6344e..98849f3e 100644 --- a/docs/api/controls/WEB-02.json +++ b/docs/api/controls/WEB-02.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to utilize a Demilitarized Zone (DMZ) to restrict inbound traffic to authorized Technology Assets, Applications and/or Services (TAAS) on certain services, protocols and ports.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -81,7 +81,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -127,19 +128,18 @@ "usa-federal-irs-1075-2021": [ "3.3.8.a" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-sau-otcc-1-2022": [ - "2-4-1-10", "2-4-1-13" ], "emea-sau-sacs-002-2022": [ - "TPC-41" + "VII.B.TPC-41" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "mp.com.4" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" ] } } \ No newline at end of file diff --git a/docs/api/controls/WEB-03.json b/docs/api/controls/WEB-03.json index 3e37f33b..27e70166 100644 --- a/docs/api/controls/WEB-03.json +++ b/docs/api/controls/WEB-03.json @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy Web Application Firewalls (WAFs) to provide defense-in-depth protection for application-specific threats.", + "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy Web Application Firewalls (WAFs) to provide defense-in-depth protection for application-specific threats. ", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -62,13 +62,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ "4.4", - "13.1" + "13.10" ], "general-cis-csc-8-1-ig1": [ "4.4" @@ -78,7 +79,7 @@ ], "general-cis-csc-8-1-ig3": [ "4.4", - "13.1" + "13.10" ], "general-nist-800-53-r4": [ "SC-7(17)" @@ -113,11 +114,10 @@ "2-15-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-79" + "VII.B.TPC-79" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "apac-aus-ism-2026-march": [ + "ISM-1862" ] } } \ No newline at end of file diff --git a/docs/api/controls/WEB-04.json b/docs/api/controls/WEB-04.json index c75d471e..f4d821bf 100644 --- a/docs/api/controls/WEB-04.json +++ b/docs/api/controls/WEB-04.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy reasonably-expected security, compliance and resilience controls to protect the confidentiality and availability of client data that is stored, transmitted or processed by the Internet-based service.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -73,9 +73,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Web Security", "crosswalks": { "general-nist-800-171-r2": [ @@ -98,12 +98,17 @@ "52.204-21(b)(1)(iv)" ], "emea-sau-cscc-1-2019": [ - "2-12", - "2-12-1-1", - "2-12-1-2" + "2-12-1-1" ], - "emea-zaf-popia-2013": [ - "19" + "apac-sgp-mas-trm-2021": [ + "14.1.1", + "14.1.2", + "14.1.3", + "14.1.4", + "14.2.1", + "14.2.3", + "14.2.4", + "14.2.11" ] } } \ No newline at end of file diff --git a/docs/api/controls/WEB-05.json b/docs/api/controls/WEB-05.json index afb52a23..d59b5a52 100644 --- a/docs/api/controls/WEB-05.json +++ b/docs/api/controls/WEB-05.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to provide individuals with clear and precise information about cookies, in accordance with applicable legal requirements for cookie management.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -64,7 +64,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": {} diff --git a/docs/api/controls/WEB-06.json b/docs/api/controls/WEB-06.json index 84395508..51076e3d 100644 --- a/docs/api/controls/WEB-06.json +++ b/docs/api/controls/WEB-06.json @@ -16,11 +16,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to implement Strong Customer Authentication (SCA) for consumers to reasonably prove their identity.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. " }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -75,7 +75,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -100,14 +101,23 @@ "usa-state-tx-cdpa-2025": [ "541.055(a)(3)" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05" + "emea-eu-psd2-2015": [ + "97(1)", + "97(1)(a)", + "97(1)(b)", + "97(1)(c)", + "97(2)" ], "emea-sau-cscc-1-2019": [ "2-12-1-1" + ], + "apac-sgp-mas-trm-2021": [ + "14.2.1", + "14.2.5", + "14.2.6", + "14.2.7", + "14.2.8", + "14.2.9" ] } } \ No newline at end of file diff --git a/docs/api/controls/WEB-07.json b/docs/api/controls/WEB-07.json index fd72ef1c..8cd5eb24 100644 --- a/docs/api/controls/WEB-07.json +++ b/docs/api/controls/WEB-07.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure the Open Web Application Security Project (OWASP) Application Security Verification Standard is incorporated into the organization's Secure Systems Development Lifecycle (SSDLC) process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,27 +71,32 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ - "16.0", + "16", "16.1", - "16.7" + "16.7", + "16.10" ], "general-cis-csc-8-1-ig2": [ "16.1", - "16.7" + "16.7", + "16.10" ], "general-cis-csc-8-1-ig3": [ "16.1", - "16.7" + "16.7", + "16.10" ], "emea-sau-cscc-1-2019": [ - "2-12-1-2" + "2-12-1-2", + "2-12-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0971", "ISM-1239" ], diff --git a/docs/api/controls/WEB-08.json b/docs/api/controls/WEB-08.json index 30f0028a..973f0ed5 100644 --- a/docs/api/controls/WEB-08.json +++ b/docs/api/controls/WEB-08.json @@ -2,8 +2,8 @@ "control_id": "WEB-08", "title": "Web Application Framework", "family": "WEB", - "description": "Mechanisms exist to ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs.", - "scf_question": "Does the organization ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs?", + "description": "Mechanisms exist to use a robust Web Application Framework to support the development of secure web applications, including web services, web resources and web Application Programming Interfaces (APIs).", + "scf_question": "Does the organization use a robust Web Application Framework to support the development of secure web applications, including web services, web resources and web Application Programming Interfaces (APIs)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -24,7 +24,6 @@ }, "profiles": [], "possible_solutions": { - "micro_small": "∙ Use a security-tested web framework", "small": "∙ Approved secure web framework policy\n∙ Use maintained frameworks only", "medium": "∙ Formal web application framework security requirements\n∙ Approved framework list", "large": "∙ Enterprise web framework governance program\n∙ Security-approved frameworks\n∙ Framework lifecycle management", @@ -71,24 +70,29 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ - "16.0", - "16.1" + "16", + "16.1", + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.1", + "16.10" ], "emea-sau-cscc-1-2019": [ "2-12-1-1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1239" ], "apac-nzl-ism-3-9": [ diff --git a/docs/api/controls/WEB-09.json b/docs/api/controls/WEB-09.json index d7941209..e6ee7044 100644 --- a/docs/api/controls/WEB-09.json +++ b/docs/api/controls/WEB-09.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure all input handled by a web application is validated and/or sanitized.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,11 +71,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1240" ] } diff --git a/docs/api/controls/WEB-10.json b/docs/api/controls/WEB-10.json index b2721e7b..6147ad35 100644 --- a/docs/api/controls/WEB-10.json +++ b/docs/api/controls/WEB-10.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure all web application content is delivered using cryptographic mechanisms (e.g., TLS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -73,7 +73,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -98,8 +99,14 @@ "emea-sau-cscc-1-2019": [ "2-12-1-1" ], - "apac-aus-ism-2024-june": [ + "emea-sau-ecc-1-2018": [ + "2-15-3-3" + ], + "apac-aus-ism-2026-march": [ "ISM-1552" + ], + "apac-sgp-mas-trm-2021": [ + "14.2.2" ] } } \ No newline at end of file diff --git a/docs/api/controls/WEB-11.json b/docs/api/controls/WEB-11.json index 50b974f0..cfcb1ce8 100644 --- a/docs/api/controls/WEB-11.json +++ b/docs/api/controls/WEB-11.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure output encoding is performed on all content produced by a web application to reduce the likelihood of cross-site scripting and other injection attacks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,11 +71,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1241" ] } diff --git a/docs/api/controls/WEB-12.json b/docs/api/controls/WEB-12.json index 40e6ec17..fb1a74dc 100644 --- a/docs/api/controls/WEB-12.json +++ b/docs/api/controls/WEB-12.json @@ -16,7 +16,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure web applications implement Content-Security-Policy, HSTS and X-Frame-Options response headers to protect both the web application and its users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -71,14 +71,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "emea-sau-cscc-1-2019": [ - "2-12-1-1" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1424" ] } diff --git a/docs/api/controls/WEB-13.json b/docs/api/controls/WEB-13.json index b334be38..ae7920d8 100644 --- a/docs/api/controls/WEB-13.json +++ b/docs/api/controls/WEB-13.json @@ -2,8 +2,8 @@ "control_id": "WEB-13", "title": "Website Change Detection", "family": "WEB", - "description": "Mechanisms exist to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data.", - "scf_question": "Does the organization detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data?", + "description": "Mechanisms exist to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive and/or regulated data.", + "scf_question": "Does the organization detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -16,9 +16,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data.", + "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -78,7 +78,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { diff --git a/docs/api/controls/WEB-14.json b/docs/api/controls/WEB-14.json index 7b85c812..1a24d454 100644 --- a/docs/api/controls/WEB-14.json +++ b/docs/api/controls/WEB-14.json @@ -2,8 +2,8 @@ "control_id": "WEB-14", "title": "Publicly Accessible Content Reviews", "family": "WEB", - "description": "Mechanisms exist to routinely review the content on publicly accessible systems for sensitive/regulated data and remove such information, if discovered.", - "scf_question": "Does the organization routinely review the content on publicly accessible systems for sensitive/regulated data and remove such information, if discovered?", + "description": "Mechanisms exist to routinely review the content on publicly accessible systems for sensitive and/or regulated data and remove such information, if discovered.", + "scf_question": "Does the organization routinely review the content on publicly accessible systems for sensitive and/or regulated data and remove such information, if discovered?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -66,13 +66,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-nist-800-171-r3": [ "03.01.22.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.b[02]" + ], "emea-gbr-def-stan-05-138-2024": [ "2321" ], diff --git a/docs/api/crosswalks.json b/docs/api/crosswalks.json index 13a9776c..5c45b2f4 100644 --- a/docs/api/crosswalks.json +++ b/docs/api/crosswalks.json @@ -1,503 +1,503 @@ { - "total_frameworks": 249, + "total_frameworks": 252, "frameworks": [ - { - "framework_id": "amaericas-can-osfi-self-assessment", - "display_name": "Canada - OSFI Cyber Security Self-Assessment Guidance", - "scf_controls_mapped": 141, - "framework_controls_mapped": 88 - }, { "framework_id": "americas-arg-ppd-2018", "display_name": "Argentina - Protection of Personal Data (2018)", - "scf_controls_mapped": 25, - "framework_controls_mapped": 50 + "scf_controls_mapped": 78, + "framework_controls_mapped": 89 }, { "framework_id": "americas-bhs-dpa-2003", - "display_name": "Bahamas - DPA (2003)", - "scf_controls_mapped": 18, - "framework_controls_mapped": 5 + "display_name": "Bahamas - Data Protection Act (DPA) (2003)", + "scf_controls_mapped": 40, + "framework_controls_mapped": 370 }, { "framework_id": "americas-bmu-mba-coc-2020", - "display_name": "Bermuda - Bermuda Monetary Authority Code of Conduct (2020)", - "scf_controls_mapped": 61, - "framework_controls_mapped": 37 + "display_name": "Bermuda - Bermuda Monetary Authority (BMA) Insurance Sector Operational Cyber Risk Management Code of Conduct (2020)", + "scf_controls_mapped": 97, + "framework_controls_mapped": 84 }, { "framework_id": "americas-bra-lgpd-2018", "display_name": "Brazil - General Data Protection Law (LGPD) (2018)", - "scf_controls_mapped": 33, - "framework_controls_mapped": 55 + "scf_controls_mapped": 29, + "framework_controls_mapped": 161 }, { "framework_id": "americas-can-itsp-10-171-2025", - "display_name": "Canada - ITSP.10.171 (2025)", - "scf_controls_mapped": 407, - "framework_controls_mapped": 275 + "display_name": "Canada - Protecting controlled information in non - Government of Canada systems and organizations (ITSP.10.171) (2025)", + "scf_controls_mapped": 415, + "framework_controls_mapped": 279 }, { "framework_id": "americas-can-osfi-b13-2022", - "display_name": "Canada - OSFI B-13 (2022)", + "display_name": "Canada - OSFI B - 13 (2022)", "scf_controls_mapped": 150, "framework_controls_mapped": 77 }, + { + "framework_id": "americas-can-osfi-self-assessment", + "display_name": "Canada - Office of the Superintendent of Financial Institutions Canada (OSFI) - Cyber Security Self - Assessment Guidance", + "scf_controls_mapped": 0, + "framework_controls_mapped": 0 + }, + { + "framework_id": "americas-can-osfi-self-assessment-2", + "display_name": "Canada - OSFI Cyber Security Self - Assessment Guidance", + "scf_controls_mapped": 125, + "framework_controls_mapped": 57 + }, { "framework_id": "americas-can-pipeda-2000", "display_name": "Canada - Personal Information Protection and Electronic Documents Act (PIPEDA) (2000)", - "scf_controls_mapped": 28, - "framework_controls_mapped": 17 + "scf_controls_mapped": 35, + "framework_controls_mapped": 68 }, { "framework_id": "americas-chl-act-19628-1999", - "display_name": "Chile - Act 19628 (1999)", - "scf_controls_mapped": 22, - "framework_controls_mapped": 10 + "display_name": "Chile - Act 19628 - Protection of Personal Data (1999)", + "scf_controls_mapped": 12, + "framework_controls_mapped": 15 }, { "framework_id": "americas-col-law-1581-2012", "display_name": "Colombia - Law 1581 (2012)", - "scf_controls_mapped": 29, - "framework_controls_mapped": 12 + "scf_controls_mapped": 21, + "framework_controls_mapped": 60 }, { "framework_id": "americas-mex-fdpa-2010", "display_name": "Mexico - Federal Law on Protection of Personal Data held by Private Parties (2010)", "scf_controls_mapped": 23, - "framework_controls_mapped": 25 + "framework_controls_mapped": 70 }, { "framework_id": "apac-aus-cop-sitc-2020", "display_name": "Australia - Code of Practice - Securing the Internet of Things for Consumers (2020)", - "scf_controls_mapped": 15, + "scf_controls_mapped": 35, "framework_controls_mapped": 13 }, { "framework_id": "apac-aus-essential-8-2024", - "display_name": "Australia - Essential Eight (2024)", + "display_name": "Australia - Essential Eight maturity model and ISM mapping (2024)", "scf_controls_mapped": 37, "framework_controls_mapped": 24 }, { - "framework_id": "apac-aus-ism-2024-june", - "display_name": "Australia - Information Security Manual (ISM) (June 2024)", - "scf_controls_mapped": 336, - "framework_controls_mapped": 802 - }, - { - "framework_id": "apac-aus-privacy-act-1998", - "display_name": "Australia - Privacy Act of 1998", - "scf_controls_mapped": 23, - "framework_controls_mapped": 12 + "framework_id": "apac-aus-ism-2026-march", + "display_name": "Australia - Information Security Manual (ISM) (March 2026)", + "scf_controls_mapped": 389, + "framework_controls_mapped": 1054 }, { "framework_id": "apac-aus-privacy-principles-2026", "display_name": "Australia - Privacy Principles (2026)", - "scf_controls_mapped": 26, - "framework_controls_mapped": 13 + "scf_controls_mapped": 24, + "framework_controls_mapped": 205 }, { "framework_id": "apac-aus-ps-cps-230-2023", - "display_name": "Australia - Prudential Standard CPS 230 (2023)", - "scf_controls_mapped": 41, - "framework_controls_mapped": 98 + "display_name": "Australia - Prudential Standard CPS 230 - Operational Risk Management (2023)", + "scf_controls_mapped": 69, + "framework_controls_mapped": 97 }, { "framework_id": "apac-aus-ps-cps-234-2019", - "display_name": "Australia - Prudential Standard CPS 234 (2019)", - "scf_controls_mapped": 52, - "framework_controls_mapped": 38 + "display_name": "Australia - Prudential Standard CPS 234 Information Security (2019)", + "scf_controls_mapped": 23, + "framework_controls_mapped": 37 }, { "framework_id": "apac-chn-csnip-2012", "display_name": "China - Decision on Strengthening Network Information Protection (2012)", - "scf_controls_mapped": 10, - "framework_controls_mapped": 4 + "scf_controls_mapped": 7, + "framework_controls_mapped": 7 }, { "framework_id": "apac-chn-cybersecurity-law-2017", - "display_name": "China - Cybersecurity Law (2017)", + "display_name": "China - Cybersecurity Law of the People's Republic of China (2017)", "scf_controls_mapped": 27, "framework_controls_mapped": 34 }, { "framework_id": "apac-chn-data-security-law-2021", - "display_name": "China - Data Security Law (2021)", - "scf_controls_mapped": 15, - "framework_controls_mapped": 24 + "display_name": "China - Data Security Law of the People's Republic of China (2021)", + "scf_controls_mapped": 10, + "framework_controls_mapped": 7 }, { "framework_id": "apac-chn-pipl-2021", - "display_name": "China - Personal Information Protection Law (2021)", - "scf_controls_mapped": 79, - "framework_controls_mapped": 100 + "display_name": "China - Personal Information Protection Law of the People's Republic of China (2021)", + "scf_controls_mapped": 37, + "framework_controls_mapped": 43 }, { "framework_id": "apac-hkg-pdo-2022", "display_name": "Hong Kong - Personal Data Ordinance (2022)", - "scf_controls_mapped": 14, - "framework_controls_mapped": 14 + "scf_controls_mapped": 18, + "framework_controls_mapped": 256 }, { "framework_id": "apac-ind-dpdpa-2023", - "display_name": "India - DPDPA (2023)", + "display_name": "India Digital Personal Data Protection Act (2023)", "scf_controls_mapped": 41, "framework_controls_mapped": 96 }, { "framework_id": "apac-ind-privacy-rules-2011", - "display_name": "India - Privacy Rules (2011)", - "scf_controls_mapped": 12, - "framework_controls_mapped": 5 + "display_name": "India - Information Technology Rules (Privacy Rules) (2011)", + "scf_controls_mapped": 13, + "framework_controls_mapped": 31 }, { "framework_id": "apac-ind-sebi-2024", - "display_name": "India - SEBI CSCRF (2024)", + "display_name": "India - SEBI Cybersecurity and Cyber Resilience Framework (2024)", "scf_controls_mapped": 170, "framework_controls_mapped": 129 }, + { + "framework_id": "apac-jpn-appi-2020", + "display_name": "Japan - Act on the Protection of Personal Information (2020)", + "scf_controls_mapped": 34, + "framework_controls_mapped": 106 + }, { "framework_id": "apac-jpn-ismap", "display_name": "Japan - Information System Security Management and Assessment Program (ISMAP)", "scf_controls_mapped": 249, - "framework_controls_mapped": 1312 - }, - { - "framework_id": "apac-jpn-ppi-2020", - "display_name": "Japan - Act on the Protection of Personal Information (2020)", - "scf_controls_mapped": 58, - "framework_controls_mapped": 134 + "framework_controls_mapped": 1313 }, { "framework_id": "apac-kor-pipa-2011", "display_name": "South Korea - Personal Information Protection Act (PIPA) (2011)", - "scf_controls_mapped": 37, - "framework_controls_mapped": 22 + "scf_controls_mapped": 24, + "framework_controls_mapped": 150 + }, + { + "framework_id": "apac-mys-bnm-rmit-2025", + "display_name": "Malaysia - Risk Management in Technology (RMiT) (2025)", + "scf_controls_mapped": 197, + "framework_controls_mapped": 107 }, { "framework_id": "apac-mys-pdpa-2010", "display_name": "Malaysia - Personal Data Protection Act (PDPA) (2010)", - "scf_controls_mapped": 25, - "framework_controls_mapped": 12 + "scf_controls_mapped": 19, + "framework_controls_mapped": 213 }, { "framework_id": "apac-nzl-hisf-microsmall-2023", "display_name": "New Zealand - HISF MicroSmall (2023)", - "scf_controls_mapped": 32, - "framework_controls_mapped": 21 + "scf_controls_mapped": 102, + "framework_controls_mapped": 150 }, { "framework_id": "apac-nzl-hisf-mlhsp-2023", "display_name": "New Zealand - HISF MLHSP (2023)", - "scf_controls_mapped": 102, - "framework_controls_mapped": 150 + "scf_controls_mapped": 0, + "framework_controls_mapped": 0 }, { "framework_id": "apac-nzl-hisf-suppliers-2023", - "display_name": "New Zealand - HISF Guidance for Suppliers (2023)", + "display_name": "New Zealand - HISO 10029:2024 NZ Health Information Security Framework Guidance for Suppliers", "scf_controls_mapped": 101, "framework_controls_mapped": 68 }, { "framework_id": "apac-nzl-ism-3-9", - "display_name": "New Zealand - Information Security Manual (ISM) (v3.9)", - "scf_controls_mapped": 291, - "framework_controls_mapped": 1392 + "display_name": "New Zealand - Information Security Manual (ISM) v3.9", + "scf_controls_mapped": 289, + "framework_controls_mapped": 1383 }, { "framework_id": "apac-nzl-privacy-act-2020", "display_name": "New Zealand - Privacy Act (2020)", "scf_controls_mapped": 20, - "framework_controls_mapped": 121 + "framework_controls_mapped": 160 }, { "framework_id": "apac-phl-dpa-2012", "display_name": "Philippines - Data Privacy Act (DPA) (2012)", - "scf_controls_mapped": 30, - "framework_controls_mapped": 16 + "scf_controls_mapped": 16, + "framework_controls_mapped": 61 }, { "framework_id": "apac-sgp-cyber-hygiene-practice-2019", "display_name": "Singapore - Cyber Hygiene Practice (2019)", - "scf_controls_mapped": 21, - "framework_controls_mapped": 13 + "scf_controls_mapped": 17, + "framework_controls_mapped": 11 }, { "framework_id": "apac-sgp-mas-trm-2021", "display_name": "Singapore - Monitory Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines (2021)", - "scf_controls_mapped": 214, - "framework_controls_mapped": 280 + "scf_controls_mapped": 219, + "framework_controls_mapped": 279 }, { "framework_id": "apac-sgp-pdpa-2012", "display_name": "Singapore - Personal Data Protection Ac (PDPA) (2012)", - "scf_controls_mapped": 30, - "framework_controls_mapped": 14 + "scf_controls_mapped": 33, + "framework_controls_mapped": 115 }, { "framework_id": "apac-twn-pdpa-2025", "display_name": "Taiwan - Personal Data Protection Act (PDPA) (2025)", - "scf_controls_mapped": 23, - "framework_controls_mapped": 8 + "scf_controls_mapped": 9, + "framework_controls_mapped": 61 }, { - "framework_id": "emea-aut-fappd-2000", - "display_name": "Austria - Federal Act concerning the Protection of Personal Data (2000)", - "scf_controls_mapped": 63, - "framework_controls_mapped": 12 + "framework_id": "emea-aut-dpa-2018", + "display_name": "Austria - Data Protection Act (2018)", + "scf_controls_mapped": 28, + "framework_controls_mapped": 93 }, { - "framework_id": "emea-bel-act-8-1992", - "display_name": "Belgium - Act of 8 December 1992", - "scf_controls_mapped": 59, - "framework_controls_mapped": 10 + "framework_id": "emea-bel-act-30-2018", + "display_name": "Belgium - Act of 30 July 2018", + "scf_controls_mapped": 27, + "framework_controls_mapped": 105 }, { "framework_id": "emea-che-fadp-2025", - "display_name": "Switzerland - FADP", - "scf_controls_mapped": 16, - "framework_controls_mapped": 9 + "display_name": "Switzerland - Federal Act on Data Protection (FADP) (2025)", + "scf_controls_mapped": 25, + "framework_controls_mapped": 104 }, { "framework_id": "emea-deu-bsrit-2017", "display_name": "Germany - Banking Supervisory Requirements for IT (2017)", "scf_controls_mapped": 91, - "framework_controls_mapped": 93 + "framework_controls_mapped": 88 }, { "framework_id": "emea-deu-c5-2020", "display_name": "Germany - Cloud Computing Compliance Controls Catalogue (C5) (2020)", - "scf_controls_mapped": 239, - "framework_controls_mapped": 121 + "scf_controls_mapped": 207, + "framework_controls_mapped": 282 }, { "framework_id": "emea-deu-fdpa-2017", "display_name": "Germany - Federal Data Protection Act (2017)", - "scf_controls_mapped": 18, - "framework_controls_mapped": 20 - }, - { - "framework_id": "emea-esp-boe-a-2022-7191", - "display_name": "Spain - BOE-A-2022-7191", - "scf_controls_mapped": 72, - "framework_controls_mapped": 132 - }, - { - "framework_id": "emea-esp-ccn-stic-825-2023", - "display_name": "Spain - ICT Security Guide CCN-STIC 825 (2023)", - "scf_controls_mapped": 99, - "framework_controls_mapped": 75 + "scf_controls_mapped": 46, + "framework_controls_mapped": 255 }, { - "framework_id": "emea-esp-decree-1720-2007", - "display_name": "Spain - Royal Decree 1720/2007", - "scf_controls_mapped": 17, - "framework_controls_mapped": 16 + "framework_id": "emea-esp-ccn-stic-825-2026", + "display_name": "Spain - ICT Security Guide CCN - STIC 825 (2026)", + "scf_controls_mapped": 234, + "framework_controls_mapped": 70 }, { "framework_id": "emea-esp-decree-311-2022", "display_name": "Spain - Royal Decree 311/2022", - "scf_controls_mapped": 73, - "framework_controls_mapped": 128 + "scf_controls_mapped": 72, + "framework_controls_mapped": 104 }, { "framework_id": "emea-eu-ai-act-2024", - "display_name": "EU Artificial Intelligence Act (AI Act) (2024)", + "display_name": "EU - European Union Artificial Intelligence Act (Regulation (EU) 2024/1689)", "scf_controls_mapped": 119, "framework_controls_mapped": 279 }, { - "framework_id": "emea-eu-cyber-resilience-act-2022", - "display_name": "EU Cyber Resilience Act (CRA) (2022)", - "scf_controls_mapped": 18, - "framework_controls_mapped": 52 + "framework_id": "emea-eu-cyber-resilience-act-2024", + "display_name": "EU - European Union Cyber Resilience Act (2024)", + "scf_controls_mapped": 35, + "framework_controls_mapped": 96 }, { - "framework_id": "emea-eu-cyber-resilience-act-annexes-2022", - "display_name": "EU Cyber Resilience Act Annexes (CRA Annexes) (2022)", - "scf_controls_mapped": 23, - "framework_controls_mapped": 117 + "framework_id": "emea-eu-cyber-resilience-act-annex-i-2024", + "display_name": "EU - European Union Cyber Resilience Act - Annex I (2024)", + "scf_controls_mapped": 16, + "framework_controls_mapped": 24 }, { "framework_id": "emea-eu-dora-2023", - "display_name": "EU Digital Operational Resilience Act (DORA) (2023)", + "display_name": "EU - Digital Operational Resilience Act (2023)", "scf_controls_mapped": 102, "framework_controls_mapped": 241 }, { "framework_id": "emea-eu-eba-ict-srm-2025", - "display_name": "EU EBA Guidelines on ICT and Security Risk Management (2025)", - "scf_controls_mapped": 148, - "framework_controls_mapped": 150 + "display_name": "EU - European Banking Authority Guidelines on ICT and Security Risk Management (2025)", + "scf_controls_mapped": 153, + "framework_controls_mapped": 156 }, { "framework_id": "emea-eu-gdpr-2016", - "display_name": "EU General Data Protection Regulation (GDPR) (2016)", + "display_name": "EU - European Union General Data Protection Regulation (2016)", "scf_controls_mapped": 42, "framework_controls_mapped": 227 }, { "framework_id": "emea-eu-nis2-2022", - "display_name": "EU NIS2 Directive (2022)", + "display_name": "EU - European Union Agency for Cybersecurity NIS2 Directive (EU) 2022/2555)", "scf_controls_mapped": 68, "framework_controls_mapped": 30 }, { "framework_id": "emea-eu-nis2-annex-2024", - "display_name": "EU NIS2 Annex (2024)", + "display_name": "EU - European Union Agency for Cybersecurity NIS2 Annex (2024)", "scf_controls_mapped": 223, "framework_controls_mapped": 351 }, + { + "framework_id": "emea-eu-psd2-2015", + "display_name": "EU - Second Payment Services Directive (PSD2) (2015)", + "scf_controls_mapped": 11, + "framework_controls_mapped": 22 + }, { "framework_id": "emea-gbr-caf-4-0", - "display_name": "UK - Cyber Assessment Framework (CAF) (v4.0)", + "display_name": "UK - Cyber Assessment Framework (CAF) v4.0", "scf_controls_mapped": 66, "framework_controls_mapped": 66 }, { "framework_id": "emea-gbr-cap-1850-2020", "display_name": "UK - Cyber Assessment Framework for Aviation Guidance (CAP1850) (2020)", - "scf_controls_mapped": 43, + "scf_controls_mapped": 36, "framework_controls_mapped": 14 }, { "framework_id": "emea-gbr-cyber-essentials-requirements-3-3", - "display_name": "UK - Cyber Essentials (v3.3)", - "scf_controls_mapped": 26, - "framework_controls_mapped": 5 + "display_name": "UK - Cyber Essentials: Requirements for IT Infrastructure v3.3", + "scf_controls_mapped": 27, + "framework_controls_mapped": 32 }, { "framework_id": "emea-gbr-def-stan-05-138-2024", - "display_name": "UK - Defstan 05-138 (2024)", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024)", "scf_controls_mapped": 213, "framework_controls_mapped": 147 }, { "framework_id": "emea-gbr-def-stan-05-138-l0-2024", - "display_name": "UK - Defstan 05-138 (2024) - L0", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L0", "scf_controls_mapped": 2, "framework_controls_mapped": 3 }, { "framework_id": "emea-gbr-def-stan-05-138-l1-2024", - "display_name": "UK - Defstan 05-138 (2024) - L1", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L1", "scf_controls_mapped": 159, "framework_controls_mapped": 100 }, { "framework_id": "emea-gbr-def-stan-05-138-l2-2024", - "display_name": "UK - Defstan 05-138 (2024) - L2", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L2", "scf_controls_mapped": 206, "framework_controls_mapped": 138 }, { "framework_id": "emea-gbr-def-stan-05-138-l3-2024", - "display_name": "UK - Defstan 05-138 (2024) - L3", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L3", "scf_controls_mapped": 212, "framework_controls_mapped": 143 }, { - "framework_id": "emea-gbr-dpa-1998", - "display_name": "UK - Data Protection Act (DPA) (1998)", - "scf_controls_mapped": 10, - "framework_controls_mapped": 8 + "framework_id": "emea-gbr-dpa-2018", + "display_name": "UK - Data Protection Act (DPA) (2018)", + "scf_controls_mapped": 25, + "framework_controls_mapped": 348 }, { "framework_id": "emea-grc-pirppd-1997", - "display_name": "Greece - Protection of Individuals with Regard to the Processing of Personal Data (1997)", - "scf_controls_mapped": 17, - "framework_controls_mapped": 11 + "display_name": "Greece - Protection of Individuals with Regard to the Processing of Personal Data (2472/1997)", + "scf_controls_mapped": 26, + "framework_controls_mapped": 73 }, { - "framework_id": "emea-hun-isdfi-2011", - "display_name": "Hungary - Informational Self-Determination and Freedom of Information (2011)", - "scf_controls_mapped": 27, - "framework_controls_mapped": 15 + "framework_id": "emea-hun-act-cxii-2011", + "display_name": "Hungary - Act CXII of 2011", + "scf_controls_mapped": 35, + "framework_controls_mapped": 100 }, { - "framework_id": "emea-irl-dpa-2003", - "display_name": "Ireland - Data Protection Act (DPA) (2003)", - "scf_controls_mapped": 25, - "framework_controls_mapped": 4 + "framework_id": "emea-irl-dpa-2018", + "display_name": "Ireland - Data Protection Act (DPA) (2018)", + "scf_controls_mapped": 17, + "framework_controls_mapped": 46 }, { - "framework_id": "emea-isr-cmo-1-0", - "display_name": "Israel - Cybersecurity Methodology for an Organization v1.0", - "scf_controls_mapped": 393, - "framework_controls_mapped": 323 + "framework_id": "emea-isr-cmo-2-0", + "display_name": "Ireland - Cybersecurity Methodology for an Organization (CMO) v2.0", + "scf_controls_mapped": 67, + "framework_controls_mapped": 48 }, { - "framework_id": "emea-isr-ppl-5741-1981", - "display_name": "Israel - Protection of Privacy Law, 5741 (1981)", - "scf_controls_mapped": 22, - "framework_controls_mapped": 8 + "framework_id": "emea-isr-ppl-5741-2025", + "display_name": "Israel - Protection of Privacy Law, 5741 (2025)", + "scf_controls_mapped": 13, + "framework_controls_mapped": 18 }, { - "framework_id": "emea-ita-pdpc-2003", - "display_name": "Italy - Personal Data Protection Code (2003)", - "scf_controls_mapped": 28, - "framework_controls_mapped": 18 + "framework_id": "emea-ita-pdpc-2018", + "display_name": "Italy - Personal Data Protection Code (2018)", + "scf_controls_mapped": 13, + "framework_controls_mapped": 45 }, { "framework_id": "emea-ken-pda-2019", "display_name": "Kenya - Data Protection Act (DPA) (2019)", - "scf_controls_mapped": 41, - "framework_controls_mapped": 237 + "scf_controls_mapped": 42, + "framework_controls_mapped": 196 }, { "framework_id": "emea-nga-dpr-2019", "display_name": "Nigeria - Data Protection Regulation (DPR) (2019)", - "scf_controls_mapped": 25, - "framework_controls_mapped": 107 + "scf_controls_mapped": 32, + "framework_controls_mapped": 111 }, { "framework_id": "emea-nor-pda-2018", "display_name": "Norway - Personal Data Act (PDA) (2018)", - "scf_controls_mapped": 23, - "framework_controls_mapped": 15 + "scf_controls_mapped": 4, + "framework_controls_mapped": 9 }, { - "framework_id": "emea-pol-act-29-1997", - "display_name": "Poland - Act of 29 August 1997 on the Protection of Personal Data", - "scf_controls_mapped": 29, - "framework_controls_mapped": 12 + "framework_id": "emea-pol-act-10-2018", + "display_name": "Poland - Act of 10 May 2018 on the Protection of Personal Data", + "scf_controls_mapped": 2, + "framework_controls_mapped": 3 }, { "framework_id": "emea-qat-pdppl-2020", "display_name": "Qatar - Personal Data Privacy Protection Law (PDPPL) (2020)", - "scf_controls_mapped": 56, - "framework_controls_mapped": 46 + "scf_controls_mapped": 33, + "framework_controls_mapped": 40 }, { - "framework_id": "emea-rus-federal-law-27-2006", - "display_name": "Russia - Federal Law of 27 (2006)", - "scf_controls_mapped": 28, - "framework_controls_mapped": 15 + "framework_id": "emea-rus-152-fz-2025", + "display_name": "Russia - Federal Law No. 152 - FZ (2025)", + "scf_controls_mapped": 17, + "framework_controls_mapped": 21 }, { "framework_id": "emea-sau-cgiot-2024", - "display_name": "Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT-1:2024)", + "display_name": "Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT - 1:2024)", "scf_controls_mapped": 118, "framework_controls_mapped": 81 }, { "framework_id": "emea-sau-cscc-1-2019", "display_name": "Saudi Arabia - Critical Systems Cybersecurity Controls (CSCC – 1: 2019)", - "scf_controls_mapped": 152, - "framework_controls_mapped": 107 + "scf_controls_mapped": 172, + "framework_controls_mapped": 104 }, { "framework_id": "emea-sau-ecc-1-2018", "display_name": "Saudi Arabia - Essential Cybersecurity Controls (ECC – 1 : 2018)", - "scf_controls_mapped": 190, - "framework_controls_mapped": 215 + "scf_controls_mapped": 169, + "framework_controls_mapped": 199 }, { "framework_id": "emea-sau-otcc-1-2022", - "display_name": "Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC -1: 2022)", - "scf_controls_mapped": 198, - "framework_controls_mapped": 189 + "display_name": "Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC - 1: 2022)", + "scf_controls_mapped": 160, + "framework_controls_mapped": 168 }, { "framework_id": "emea-sau-pdpl-2023", @@ -507,27 +507,27 @@ }, { "framework_id": "emea-sau-sacs-002-2022", - "display_name": "Saudi Arabia - SACS-002 Third Party Cybersecurity Standard (2022)", - "scf_controls_mapped": 185, - "framework_controls_mapped": 92 + "display_name": "Saudi Arabia - SACS - 002 Third Party Cybersecurity Standard (2022)", + "scf_controls_mapped": 101, + "framework_controls_mapped": 124 }, { "framework_id": "emea-sau-sama-csf-1-2017", - "display_name": "Saudi Arabia - SAMA CSF Version 1.0 (2017)", - "scf_controls_mapped": 50, - "framework_controls_mapped": 36 + "display_name": "Saudi Arabia - Saudi Arabian Monetary Authority (SAMA) Cyber Security Framework Version 1.0 (2017)", + "scf_controls_mapped": 91, + "framework_controls_mapped": 482 }, { "framework_id": "emea-srb-act-9-2018", - "display_name": "Serbia - Act of 9 November 2018 on Personal Data Protection", - "scf_controls_mapped": 56, - "framework_controls_mapped": 205 + "display_name": "Serbia - Act of 9 November 2018 on Personal Data Protection (Official Gazette No. 87/18)", + "scf_controls_mapped": 31, + "framework_controls_mapped": 330 }, { "framework_id": "emea-tur-lppd-2016", "display_name": "Turkey - Law on the Protection of Personal Data (LPPD) (2016)", - "scf_controls_mapped": 17, - "framework_controls_mapped": 10 + "scf_controls_mapped": 7, + "framework_controls_mapped": 103 }, { "framework_id": "emea-uae-niaf-2023", @@ -535,65 +535,59 @@ "scf_controls_mapped": 20, "framework_controls_mapped": 15 }, - { - "framework_id": "emea-us-psd2-2015", - "display_name": "EU Second Payment Services Directive (PSD2) (2015)", - "scf_controls_mapped": 30, - "framework_controls_mapped": 10 - }, { "framework_id": "emea-zaf-popia-2013", "display_name": "South Africa - Protection of Personal Information Act (POPIA) (2013)", - "scf_controls_mapped": 101, - "framework_controls_mapped": 41 + "scf_controls_mapped": 23, + "framework_controls_mapped": 242 }, { "framework_id": "general-aicpa-pmf-2020", - "display_name": "AICPA Privacy Management Framework (PMF) (2020)", + "display_name": "American Institute of Certified Public Accountants (AICPA) Privacy Management Framework (PMF) (2020)", "scf_controls_mapped": 109, "framework_controls_mapped": 123 }, { "framework_id": "general-aicpa-tsc-2017", - "display_name": "Trust Services Criteria (TSC) (2017)", + "display_name": "American Institute of Certified Public Accountants (AICPA) Trust Services Criteria (2017)", "scf_controls_mapped": 412, "framework_controls_mapped": 399 }, { "framework_id": "general-apec-privacy-framework-2015", - "display_name": "APEC Privacy Framework (2015)", + "display_name": "Asia - Pacific Economic Cooperation (APEC) Privacy Framework (2015)", "scf_controls_mapped": 14, "framework_controls_mapped": 25 }, { "framework_id": "general-bsi-200-1-1-0", - "display_name": "Standard 200-1 (v1.0)", + "display_name": "Bundesamt für Sicherheit in der Informationstechnik (BSI) - Standard 200 - 1 (v1.0)", "scf_controls_mapped": 35, "framework_controls_mapped": 22 }, { "framework_id": "general-cis-csc-8-1", - "display_name": "Critical Security Controls (CSC) (v8.1)", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1", "scf_controls_mapped": 234, - "framework_controls_mapped": 166 + "framework_controls_mapped": 171 }, { "framework_id": "general-cis-csc-8-1-ig1", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG1", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG1", "scf_controls_mapped": 104, "framework_controls_mapped": 56 }, { "framework_id": "general-cis-csc-8-1-ig2", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG2", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG2", "scf_controls_mapped": 208, - "framework_controls_mapped": 126 + "framework_controls_mapped": 130 }, { "framework_id": "general-cis-csc-8-1-ig3", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG3", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG3", "scf_controls_mapped": 230, - "framework_controls_mapped": 148 + "framework_controls_mapped": 153 }, { "framework_id": "general-cobit-2019", @@ -609,85 +603,85 @@ }, { "framework_id": "general-cr-cmm-2026", - "display_name": "Cyber Resilience Capability Maturity Model (CR-CMM) (2026)", + "display_name": "Cyber Resilience Capability Maturity Model (CR - CMM) (2026)", "scf_controls_mapped": 46, "framework_controls_mapped": 40 }, { "framework_id": "general-csa-cmm-4-1-0", - "display_name": "Cloud Controls Matrix (CCM) (v4.1.0)", + "display_name": "Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) v4.1.0", "scf_controls_mapped": 291, "framework_controls_mapped": 207 }, { "framework_id": "general-csa-iot-2", - "display_name": "IoT Security Controls Framework (v2)", + "display_name": "Cloud Security Alliance (CSA) Internet of Things Security Controls Framework v2", "scf_controls_mapped": 253, "framework_controls_mapped": 155 }, { "framework_id": "general-govramp", - "display_name": "GovRAMP", + "display_name": "Government Risk and Authorization Management Program (GovRAMP)", "scf_controls_mapped": 441, "framework_controls_mapped": 383 }, { "framework_id": "general-govramp-core", - "display_name": "GovRAMP Core", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Core Controls", "scf_controls_mapped": 86, "framework_controls_mapped": 60 }, { "framework_id": "general-govramp-high", - "display_name": "GovRAMP High", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - High", "scf_controls_mapped": 441, "framework_controls_mapped": 383 }, { "framework_id": "general-govramp-low", - "display_name": "GovRAMP Low", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Low", "scf_controls_mapped": 166, "framework_controls_mapped": 114 }, { "framework_id": "general-govramp-low-plus", - "display_name": "GovRAMP Low+", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Low+", "scf_controls_mapped": 230, "framework_controls_mapped": 173 }, { "framework_id": "general-govramp-mod", - "display_name": "GovRAMP Moderate", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Moderate", "scf_controls_mapped": 347, "framework_controls_mapped": 290 }, { "framework_id": "general-iec-62443-2-1-2024", - "display_name": "IEC 62443-2-1 (2024)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 2 - 1:2024 - Security for industrial automation and control systems - Part 2 - 1: Security program requirements for IACS asset owners", "scf_controls_mapped": 112, "framework_controls_mapped": 119 }, { "framework_id": "general-iec-62443-3-3-2013", - "display_name": "IEC 62443-3-3 (2013)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 3 - 3:2013 - Industrial communication networks - Network and system security - Part 3 - 3: System security requirements and security levels", "scf_controls_mapped": 80, "framework_controls_mapped": 111 }, { "framework_id": "general-iec-62443-4-1-2018", - "display_name": "IEC 62443-4-1 (2018)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 4 - 1:2018 - Security for industrial automation and control systems - Part 4 - 1: Secure product development lifecycle requirements", "scf_controls_mapped": 25, "framework_controls_mapped": 186 }, { "framework_id": "general-iec-62443-4-2-2019", - "display_name": "IEC 62443-4-2 (2019)", + "display_name": "International Electrotechnical Commission 62443 - 4 - 2 Ed. 1.0 b:2019 - Security for industrial automation and control systems - Part 4 - 2: Technical security requirements for IACS components", "scf_controls_mapped": 89, "framework_controls_mapped": 169 }, { "framework_id": "general-iec-tr-60601-4-5-2021", - "display_name": "IEC TR 60601-4-5 (2021)", + "display_name": "International Electrotechnical Commission (IEC) Technical Report 60601 - 4 - 5:2021 - Medical electrical equipment - Part 4 - 5: Guidance and interpretation - Safety - related technical security specifications", "scf_controls_mapped": 26, "framework_controls_mapped": 37 }, @@ -699,799 +693,823 @@ }, { "framework_id": "general-iso-21434-2021", - "display_name": "ISO 21434 (2021)", + "display_name": "ISO/SAE 21434:2021 - Road vehicles — Cybersecurity engineering", "scf_controls_mapped": 51, "framework_controls_mapped": 232 }, { "framework_id": "general-iso-22301-2019", - "display_name": "ISO 22301 (2019)", + "display_name": "ISO/IEC 22301:2019 - Security and resilience - Business continuity management systems - Requirements", "scf_controls_mapped": 36, "framework_controls_mapped": 259 }, { "framework_id": "general-iso-27001-2022", - "display_name": "ISO 27001 (2022)", + "display_name": "ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements", "scf_controls_mapped": 51, "framework_controls_mapped": 148 }, { "framework_id": "general-iso-27002-2022", - "display_name": "ISO 27002 (2022)", + "display_name": "ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls", "scf_controls_mapped": 316, "framework_controls_mapped": 96 }, { "framework_id": "general-iso-27017-2015", - "display_name": "ISO 27017 (2015)", + "display_name": "ISO/IEC 27017:2015 - Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services", "scf_controls_mapped": 224, "framework_controls_mapped": 118 }, { "framework_id": "general-iso-27018-2025", - "display_name": "ISO 27018 (2025)", + "display_name": "ISO/IEC 27018:2025 - Information security, cybersecurity and privacy protection - Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors", "scf_controls_mapped": 322, "framework_controls_mapped": 108 }, { "framework_id": "general-iso-27701-2025", - "display_name": "ISO 27701 (2025)", + "display_name": "ISO/IEC 27701:2025 - Information security, cybersecurity and privacy protection - Privacy information management systems - Requirements and guidance", "scf_controls_mapped": 59, "framework_controls_mapped": 90 }, { "framework_id": "general-iso-29100-2024", - "display_name": "ISO 29100 (2024)", + "display_name": "ISO/IEC 29100:2024 - Information technology - Security techniques - Privacy framework", "scf_controls_mapped": 43, "framework_controls_mapped": 11 }, { "framework_id": "general-iso-31000-2018", - "display_name": "ISO 31000 (2018)", + "display_name": "ISO/IEC 31000:2018 - Risk management - Guidelines", "scf_controls_mapped": 53, "framework_controls_mapped": 27 }, { "framework_id": "general-iso-31010-2009", - "display_name": "ISO 31010 (2009)", + "display_name": "ISO/IEC 31010:2019 - Risk management - Risk assessment techniques", "scf_controls_mapped": 31, "framework_controls_mapped": 32 }, { "framework_id": "general-iso-42001-2023", - "display_name": "ISO 42001 (2023)", + "display_name": "ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system", "scf_controls_mapped": 149, "framework_controls_mapped": 140 }, { - "framework_id": "general-mitre-att&ck-16-1", - "display_name": "MITRE ATT&CK (v16.1)", + "framework_id": "general-mitre-att_ck-16-1", + "display_name": "MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) - NIST 800 - 53 mappings", "scf_controls_mapped": 108, "framework_controls_mapped": 511 }, { "framework_id": "general-mpa-csbp-5-3-1", - "display_name": "Content Security Best Practices Common Guidelines (v5.3.1)", + "display_name": "Motion Picture Association (MPA) Content Security Best Practices Common Guidelines v5.3.1", "scf_controls_mapped": 232, "framework_controls_mapped": 81 }, { "framework_id": "general-naic-insurance-data-security-model-law-668-2017", - "display_name": "Insurance Data Security Model Law 668 (2017)", + "display_name": "National Association of Insurance Commissioners (NAIC) Insurance Data Security Model Law (MDL - 668) (2017)", "scf_controls_mapped": 58, "framework_controls_mapped": 85 }, { "framework_id": "general-nist-100-1-ai-rmf", - "display_name": "NIST AI 100-1 (AI RMF 1.0)", + "display_name": "NIST AI 100 - 1 - Artificial Intelligence Risk Management Framework (AI RMF 1.0)", "scf_controls_mapped": 158, "framework_controls_mapped": 91 }, { "framework_id": "general-nist-600-1-gen-ai-profile", - "display_name": "NIST AI 600-1", + "display_name": "NIST AI 600 - 1 - Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", "scf_controls_mapped": 139, "framework_controls_mapped": 250 }, { "framework_id": "general-nist-800-160-vol-2-r1", - "display_name": "NIST SP 800-160 (Vol 2, Rev 1)", + "display_name": "NIST SP 800 - 160 Volume 2, Revision 1 - Developing Cyber - Resilient Systems: A Systems Security Engineering Approach", "scf_controls_mapped": 204, "framework_controls_mapped": 196 }, { "framework_id": "general-nist-800-161-r1", - "display_name": "NIST SP 800-161 R1 UDP1", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations", "scf_controls_mapped": 341, "framework_controls_mapped": 308 }, { "framework_id": "general-nist-800-161-r1-cscrm", - "display_name": "NIST SP 800-161 R1 UDP1 - C-SCRM Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - C - SCRM Baseline", "scf_controls_mapped": 132, "framework_controls_mapped": 95 }, { "framework_id": "general-nist-800-161-r1-flowdown", - "display_name": "NIST SP 800-161 R1 UDP1 - Flow Down Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Flow Down Baseline", "scf_controls_mapped": 107, "framework_controls_mapped": 69 }, { "framework_id": "general-nist-800-161-r1-level-1", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 1 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 1 Baseline", "scf_controls_mapped": 95, "framework_controls_mapped": 76 }, { "framework_id": "general-nist-800-161-r1-level-2", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 2 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 2 Baseline", "scf_controls_mapped": 273, "framework_controls_mapped": 236 }, { "framework_id": "general-nist-800-161-r1-level-3", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 3 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 3 Baseline", "scf_controls_mapped": 284, "framework_controls_mapped": 251 }, { "framework_id": "general-nist-800-171-r2", - "display_name": "NIST SP 800-171 R2", + "display_name": "NIST SP 800 - 171 R2 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", "scf_controls_mapped": 251, "framework_controls_mapped": 172 }, { "framework_id": "general-nist-800-171-r3", - "display_name": "NIST SP 800-171 R3", - "scf_controls_mapped": 407, + "display_name": "NIST SP 800 - 171 R3 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", + "scf_controls_mapped": 414, "framework_controls_mapped": 275 }, { "framework_id": "general-nist-800-171a", - "display_name": "NIST SP 800-171A", + "display_name": "NIST SP 800 - 171A - Assessing Security Requirements for Controlled Unclassified Information", "scf_controls_mapped": 134, "framework_controls_mapped": 320 }, { "framework_id": "general-nist-800-171a-r3", - "display_name": "NIST SP 800-171A R3", - "scf_controls_mapped": 215, - "framework_controls_mapped": 508 + "display_name": "NIST SP 800 - 171A R3 - Assessing Security Requirements for Controlled Unclassified Information", + "scf_controls_mapped": 414, + "framework_controls_mapped": 509 }, { - "framework_id": "general-nist-800-172", - "display_name": "NIST SP 800-172", - "scf_controls_mapped": 74, - "framework_controls_mapped": 35 + "framework_id": "general-nist-800-172-r3", + "display_name": "NIST SP 800 - 172 R3 - Enhanced Security Requirements for Protecting Controlled Unclassified Information", + "scf_controls_mapped": 162, + "framework_controls_mapped": 103 + }, + { + "framework_id": "general-nist-800-172a-r3", + "display_name": "NIST SP 800 - 172A R3 - Assessing Enhanced Security Requirements for Controlled Unclassified Information", + "scf_controls_mapped": 163, + "framework_controls_mapped": 364 }, { "framework_id": "general-nist-800-207", - "display_name": "NIST SP 800-207", + "display_name": "NIST SP 800 - 207 - Zero Trust Architecture", "scf_controls_mapped": 93, "framework_controls_mapped": 7 }, { "framework_id": "general-nist-800-218", - "display_name": "NIST SP 800-218", + "display_name": "NIST SP 800 - 218 - Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities", "scf_controls_mapped": 59, "framework_controls_mapped": 60 }, { "framework_id": "general-nist-800-37-r2", - "display_name": "NIST SP 800-37 R2", + "display_name": "NIST SP 800 - 37 R2 - Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy", "scf_controls_mapped": 45, "framework_controls_mapped": 47 }, { "framework_id": "general-nist-800-39", - "display_name": "NIST SP 800-39", + "display_name": "NIST SP 800 - 39 - Managing Information Security Risk: Organization, Mission, and Information System View", "scf_controls_mapped": 17, "framework_controls_mapped": 16 }, { "framework_id": "general-nist-800-53-r4", - "display_name": "NIST SP 800-53 R4", + "display_name": "NIST SP 800 - 53 R4 - Security and Privacy Controls for Federal Information Systems and Organizations", "scf_controls_mapped": 653, "framework_controls_mapped": 682 }, { "framework_id": "general-nist-800-53-r5-2", - "display_name": "NIST SP 800-53 R5", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations", "scf_controls_mapped": 777, "framework_controls_mapped": 810 }, { "framework_id": "general-nist-800-53-r5-2-high", - "display_name": "NIST SP 800-53 R5 - High Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - High Baseline", "scf_controls_mapped": 89, "framework_controls_mapped": 83 }, { "framework_id": "general-nist-800-53-r5-2-low", - "display_name": "NIST SP 800-53 R5 - Low Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Low Baseline", "scf_controls_mapped": 202, "framework_controls_mapped": 149 }, { "framework_id": "general-nist-800-53-r5-2-mod", - "display_name": "NIST SP 800-53 R5 - Moderate Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Moderate Baseline", "scf_controls_mapped": 157, "framework_controls_mapped": 138 }, { "framework_id": "general-nist-800-53-r5-2-privacy", - "display_name": "NIST SP 800-53 R5 - Privacy Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Privacy Baseline", "scf_controls_mapped": 346, "framework_controls_mapped": 236 }, { "framework_id": "general-nist-800-66-r2", - "display_name": "NIST SP 800-66 R2", + "display_name": "NIST SP 800 - 66 R2 - Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide", "scf_controls_mapped": 112, "framework_controls_mapped": 22 }, { "framework_id": "general-nist-800-82-r3", - "display_name": "NIST SP 800-82 R3", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay", "scf_controls_mapped": 777, "framework_controls_mapped": 810 }, { "framework_id": "general-nist-800-82-r3-high", - "display_name": "NIST SP 800-82 R3 - High OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - High OT Overlay", "scf_controls_mapped": 467, "framework_controls_mapped": 418 }, { "framework_id": "general-nist-800-82-r3-low", - "display_name": "NIST SP 800-82 R3 - Low OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay", "scf_controls_mapped": 251, "framework_controls_mapped": 194 }, { "framework_id": "general-nist-800-82-r3-mod", - "display_name": "NIST SP 800-82 R3 - Moderate OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Moderate OT Overlay", "scf_controls_mapped": 390, "framework_controls_mapped": 337 }, { "framework_id": "general-nist-csf-2-0", - "display_name": "NIST Cybersecurity Framework (v2.0)", + "display_name": "NIST Cybersecurity Framework v2.0", "scf_controls_mapped": 250, "framework_controls_mapped": 134 }, + { + "framework_id": "general-nist-cswp-39", + "display_name": "NIST CSWP 39 - Considerations for Achieving Crypto Agility", + "scf_controls_mapped": 15, + "framework_controls_mapped": 18 + }, { "framework_id": "general-nist-privacy-framework-1-0", - "display_name": "NIST Privacy Framework (v1.0)", - "scf_controls_mapped": 152, - "framework_controls_mapped": 122 + "display_name": "NIST Privacy Framework v1.0", + "scf_controls_mapped": 153, + "framework_controls_mapped": 123 }, { "framework_id": "general-oecd-privacy-principles-2010", - "display_name": "OECD Privacy Principles (2010)", + "display_name": "Organisation for Economic Co - operation and Development (EOCD) Privacy Principles", "scf_controls_mapped": 14, "framework_controls_mapped": 17 }, { "framework_id": "general-owasp-top-10-2025", - "display_name": "OWASP Top 10 (2025)", + "display_name": "Open Worldwide Application Security Project (OWASP) Top 10 (2025)", "scf_controls_mapped": 139, "framework_controls_mapped": 10 }, { "framework_id": "general-pci-dss-4-0-1", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) (v4.01)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.01", "scf_controls_mapped": 371, "framework_controls_mapped": 351 }, { "framework_id": "general-pci-dss-4-0-1-saq-a", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ A (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A", "scf_controls_mapped": 71, "framework_controls_mapped": 29 }, { "framework_id": "general-pci-dss-4-0-1-saq-a-ep", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ A-EP (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A - EP", "scf_controls_mapped": 239, "framework_controls_mapped": 139 }, { "framework_id": "general-pci-dss-4-0-1-saq-b", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ B (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B", "scf_controls_mapped": 58, "framework_controls_mapped": 27 }, { "framework_id": "general-pci-dss-4-0-1-saq-b-ip", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ B-IP (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B - IP", "scf_controls_mapped": 121, "framework_controls_mapped": 50 }, { "framework_id": "general-pci-dss-4-0-1-saq-c", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ C (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C", "scf_controls_mapped": 227, "framework_controls_mapped": 124 }, { "framework_id": "general-pci-dss-4-0-1-saq-c-vt", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ C-VT (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C - VT", "scf_controls_mapped": 115, "framework_controls_mapped": 54 }, { "framework_id": "general-pci-dss-4-0-1-saq-d-merchant", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Merchant (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Merchant", "scf_controls_mapped": 322, "framework_controls_mapped": 233 }, { "framework_id": "general-pci-dss-4-0-1-saq-d-service-provider", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Service Provider (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Service Provider", "scf_controls_mapped": 339, "framework_controls_mapped": 257 }, { "framework_id": "general-pci-dss-4-0-1-saq-p2pe", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ P2PE (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) P2PE", "scf_controls_mapped": 47, "framework_controls_mapped": 21 }, { "framework_id": "general-scf-dpmp-2025", - "display_name": "Data Privacy Management Principle (DPMP) (2025)", - "scf_controls_mapped": 218, - "framework_controls_mapped": 83 + "display_name": "Secure Controls Framework (SCF) Data Privacy Management Principles (2025)", + "scf_controls_mapped": 0, + "framework_controls_mapped": 0 }, { "framework_id": "general-shared-assessments-sig-2025", - "display_name": "SIG (2025)", + "display_name": "Shared Assessments Standard Information Gathering (SIG) Questionnaire 2025", "scf_controls_mapped": 128, "framework_controls_mapped": 65 }, { "framework_id": "general-sparta", - "display_name": "SPARTA Countermeasures", + "display_name": "Space Attack Research & Tactic Analysis (SPARTA) Countermeasures", "scf_controls_mapped": 79, "framework_controls_mapped": 53 }, { "framework_id": "general-swift-cscf-2025", - "display_name": "SWIFT Customer Security Controls Framework (2025)", + "display_name": "Society for Worldwide Interbank Financial Telecommunication Customer Security Controls Framework 2025", "scf_controls_mapped": 164, "framework_controls_mapped": 32 }, { "framework_id": "general-tisax-6-0-3", - "display_name": "TISAX ISA (6.0.3)", + "display_name": "Trusted Information Security Assessment Exchange (TISAX) 6.0.3", "scf_controls_mapped": 154, "framework_controls_mapped": 73 }, { "framework_id": "general-ul-2900-1-2017", - "display_name": "UL 2900-1 (2017)", + "display_name": "UL 2900 - 1 - Software Cybersecurity for Network - Connectable Products, Part 1: General Requirements (2017)", "scf_controls_mapped": 23, "framework_controls_mapped": 143 }, { "framework_id": "general-ul-2900-2-2-2016", - "display_name": "UL 2900-2-2 (2016)", + "display_name": "UL 2900 - 2 - 2 Ed. 1 - 2016 - Outline of Investigation for Software Cybersecurity for Network - Connectable Products, Part 2 - 2: Particular Requirements for Industrial Control Systems", "scf_controls_mapped": 20, "framework_controls_mapped": 57 }, { "framework_id": "general-un-155-2021", - "display_name": "UN Regulation No. 155 (2021)", + "display_name": "United Nations - Regulation No. 155 - Cyber security and cyber security management system (2021)", "scf_controls_mapped": 57, "framework_controls_mapped": 55 }, { "framework_id": "general-un-ece-wp-29-2020", - "display_name": "UNECE WP.29 (2020)", + "display_name": "United Nations - United Nations Economic Commission for Europe (UNECE) Working Party 29 (2020)", "scf_controls_mapped": 57, "framework_controls_mapped": 54 }, { "framework_id": "usa-federal-cms-marse-2-0", - "display_name": "MARS-E Document Suite (2.0)", - "scf_controls_mapped": 391, - "framework_controls_mapped": 1286 + "display_name": "US - Centers for Medicare & Medicaid Services MARS - E Document Suite, Version 2.0", + "scf_controls_mapped": 392, + "framework_controls_mapped": 1287 }, { "framework_id": "usa-federal-dhs-cisa-cpg-2-0", - "display_name": "CISA Cross-Sector Cybersecurity Performance Goals (CPG) (2.0)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Cross - Sector Cybersecurity Performance Goals 2.0", "scf_controls_mapped": 126, "framework_controls_mapped": 38 }, { "framework_id": "usa-federal-dhs-cisa-ssdaf-2024", - "display_name": "CISA Secure Software Development Attestation Form (SSDAF) (2024)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Secure Software Development Attestation Form (SSDAF) (2024)", "scf_controls_mapped": 41, "framework_controls_mapped": 15 }, { "framework_id": "usa-federal-dhs-cisa-tic-3-0", - "display_name": "CISA Trusted Internet Connections 3.0 Security Capabilities Catalog (TIC 3.0)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Trusted Internet Connections 3.0 Security Capabilities Catalog", "scf_controls_mapped": 148, "framework_controls_mapped": 117 }, { "framework_id": "usa-federal-doc-data-privacy-framework-2023", - "display_name": "Data Privacy Framework (2023)", + "display_name": "US - Data Privacy Framework (2023)", "scf_controls_mapped": 31, "framework_controls_mapped": 74 }, { "framework_id": "usa-federal-doe-c2m2-2-1", - "display_name": "Cybersecurity Capability Maturity Model (C2M2) (v2.1)", + "display_name": "US - Department of Energy (DOE) - Cybersecurity Capability Maturity Model version 2.1", "scf_controls_mapped": 224, "framework_controls_mapped": 356 }, { "framework_id": "usa-federal-dow-cert-rmm-1-2", - "display_name": "CERT-RMM (v1.2)", + "display_name": "US - Department of War (DoW) - Computer Emergency Response Team (CERT) Resilience Management Model (RMM) Version 1.2", "scf_controls_mapped": 85, "framework_controls_mapped": 753 }, { "framework_id": "usa-federal-dow-cmmc-2-level-1", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1", + "display_name": "US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1", "scf_controls_mapped": 52, "framework_controls_mapped": 15 }, { "framework_id": "usa-federal-dow-cmmc-2-level-1-aos", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1 Assessment Objectives", + "display_name": "US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1 Assessment Objectives", "scf_controls_mapped": 16, "framework_controls_mapped": 59 }, { "framework_id": "usa-federal-dow-cmmc-2-level-2", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 2", + "display_name": "US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 2", "scf_controls_mapped": 198, "framework_controls_mapped": 110 }, { "framework_id": "usa-federal-dow-cmmc-2-level-3", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 3", + "display_name": "US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 3", "scf_controls_mapped": 55, "framework_controls_mapped": 24 }, { "framework_id": "usa-federal-dow-dfars-252-204-7012", - "display_name": "DFARS 252.204-7012", + "display_name": "US - Defense Federal Acquisition Regulation Supplement (DFARS) 252.204 - 7012", "scf_controls_mapped": 19, "framework_controls_mapped": 20 }, { "framework_id": "usa-federal-dow-safeguarding-nnpi-2010", - "display_name": "Safeguarding of NNPI (2010)", + "display_name": "US - Safeguarding of Naval Nuclear Propulsion Information (NNPI) (2010)", "scf_controls_mapped": 32, "framework_controls_mapped": 68 }, { "framework_id": "usa-federal-dow-zt-roadmap-1-1", - "display_name": "Department of War (DoW) - Zero Trust Execution Roadmap (v1.1)", + "display_name": "US - Department of War (DoW) - Zero Trust Execution Roadmap v1.1", "scf_controls_mapped": 117, - "framework_controls_mapped": 190 + "framework_controls_mapped": 191 }, { "framework_id": "usa-federal-dow-zta-reference-architecture-2-0", - "display_name": "Department of War (DoW) - Zero Trust Reference Architecture (v2)", + "display_name": "US - Department of War (DoW) - Zero Trust Reference Architecture v2", "scf_controls_mapped": 39, "framework_controls_mapped": 28 }, { "framework_id": "usa-federal-eo-14028", - "display_name": "Executive Order 14028 - Improving the Nation's Cybersecurity", + "display_name": "US - Executive Order (EO) 14028 - Improving the Nation's Cybersecurity", "scf_controls_mapped": 43, "framework_controls_mapped": 16 }, { "framework_id": "usa-federal-far-52-204-21", - "display_name": "FAR 52.204-21", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 21 - Basic Safeguarding of Covered Contractor Information Systems", "scf_controls_mapped": 59, "framework_controls_mapped": 17 }, { "framework_id": "usa-federal-far-52-204-25", - "display_name": "FAR 52.204-25 (NDAA Section 889)", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 25 (NDAA Section 889) - Prohibition on Contracting With Entities Using Certain Telecommunications and Video Surveillance Services or Equipment", "scf_controls_mapped": 2, "framework_controls_mapped": 5 }, { "framework_id": "usa-federal-far-52-204-27", - "display_name": "FAR 52.204-27", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 27 - Prohibition on a ByteDance Covered Application", "scf_controls_mapped": 3, "framework_controls_mapped": 2 }, { "framework_id": "usa-federal-fbi-cjis-6-0", - "display_name": "Criminal Justice Information Services (CJIS) Security Policy (v6.0)", + "display_name": "US - Department of Justice - Criminal Justice Information Services (CJIS) Security Policy v6.0", "scf_controls_mapped": 365, "framework_controls_mapped": 319 }, { "framework_id": "usa-federal-fda-21-cfr-part-11-2025", - "display_name": "Food & Drug Administration (FDA) 21 CFR Part 11 (2025)", + "display_name": "US - Food & Drug Administration (FDA) 21 CFR Part 11 (2025)", "scf_controls_mapped": 62, "framework_controls_mapped": 28 }, { "framework_id": "usa-federal-gsa-fedramp-5-high", - "display_name": "FedRAMP R5 - High Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - High Baseline", "scf_controls_mapped": 561, "framework_controls_mapped": 490 }, { "framework_id": "usa-federal-gsa-fedramp-5-li-saas", - "display_name": "FedRAMP R5 - Li-SAAS Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Li - SAAS Baseline", "scf_controls_mapped": 383, "framework_controls_mapped": 269 }, { "framework_id": "usa-federal-gsa-fedramp-5-low", - "display_name": "FedRAMP R5 - Low Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Low Baseline", "scf_controls_mapped": 383, "framework_controls_mapped": 269 }, { "framework_id": "usa-federal-gsa-fedramp-5-mod", - "display_name": "FedRAMP R5 - Moderate Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Moderate Baseline", "scf_controls_mapped": 491, "framework_controls_mapped": 410 }, { "framework_id": "usa-federal-hhs-45-cfr-155-260-2016", - "display_name": "HHS § 155.260 (2016)", + "display_name": "US - Health and Human Services (HHS) § 155.260 - Privacy and Security of Personally Identifiable Information (2016)", "scf_controls_mapped": 36, "framework_controls_mapped": 44 }, { "framework_id": "usa-federal-irs-1075-2021", - "display_name": "IRS 1075 (2021)", - "scf_controls_mapped": 442, - "framework_controls_mapped": 743 + "display_name": "US - Internal Revenue Service (IRS) 1075 (2021)", + "scf_controls_mapped": 443, + "framework_controls_mapped": 744 + }, + { + "framework_id": "usa-federal-law-33-cfr-part-101-subpart-f", + "display_name": "US - 33 CFR Part 101 Subpart F (up to date as of 4 - 17 - 2026)", + "scf_controls_mapped": 104, + "framework_controls_mapped": 148 }, { "framework_id": "usa-federal-law-coppa-2024", - "display_name": "Children's Online Privacy Protection Act (COPPA) (2024)", + "display_name": "US - Children's Online Privacy Protection Act (COPPA) (2024)", "scf_controls_mapped": 10, "framework_controls_mapped": 8 }, { "framework_id": "usa-federal-law-facta-fcra-2023", - "display_name": "Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023)", + "display_name": "US - Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023)", "scf_controls_mapped": 3, "framework_controls_mapped": 6 }, { "framework_id": "usa-federal-law-ferpa-2010", - "display_name": "Family Educational Rights and Privacy Act (FERPA) (2010)", + "display_name": "US - Family Educational Rights and Privacy Act (FERPA) (2010)", "scf_controls_mapped": 5, "framework_controls_mapped": 27 }, { "framework_id": "usa-federal-law-ftc-act", - "display_name": "Federal Trade Commission (FTC) Act", + "display_name": "US - Federal Trade Commission (FTC) Act", "scf_controls_mapped": 16, "framework_controls_mapped": 1 }, { "framework_id": "usa-federal-law-glba-cfr-314-2023", - "display_name": "Gramm Leach Bliley Act (GLBA) (2023)", + "display_name": "US - Gramm Leach Bliley Act (GLBA) - CFR 314 (Dec 2023)", "scf_controls_mapped": 70, "framework_controls_mapped": 52 }, { "framework_id": "usa-federal-law-hipaa-security-rule-2013", - "display_name": "HIPAA Security Rule (2013)", + "display_name": "US - Health Insurance Portability and Accountability Act (HIPAA) Security Rule (2013)", "scf_controls_mapped": 136, "framework_controls_mapped": 87 }, { "framework_id": "usa-federal-law-hipaa-simplification-2013", - "display_name": "HIPAA Administrative Simplification (2013)", + "display_name": "US - Health Insurance Portability and Accountability Act (HIPAA) Administrative Simplification (2013)", "scf_controls_mapped": 170, "framework_controls_mapped": 576 }, { "framework_id": "usa-federal-law-sox-2002", - "display_name": "SOX (2002)", + "display_name": "US - Sarbanes Oxley Act (SOX) (2002)", "scf_controls_mapped": 4, "framework_controls_mapped": 17 }, { "framework_id": "usa-federal-nerc-cip-2024", - "display_name": "NERC Critical Infrastructure Protection (CIP) (2024)", + "display_name": "US - North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) (2024)", "scf_controls_mapped": 122, "framework_controls_mapped": 204 }, { "framework_id": "usa-federal-nispom-2020", - "display_name": "National Industrial Security Program Operating Manual (NISPOM) (2020)", + "display_name": "US - National Industrial Security Program Operating Manual (NISPOM) (2020)", "scf_controls_mapped": 35, "framework_controls_mapped": 226 }, { "framework_id": "usa-federal-omb-fipps-1973", - "display_name": "US Fair Information Practice Principles (FIPPs) (1973)", + "display_name": "US - Fair Information Practice Principles (FIPPs) (1973)", "scf_controls_mapped": 30, "framework_controls_mapped": 8 }, { "framework_id": "usa-federal-sec-cybersecurity-rule-2023", - "display_name": "SEC Cybersecurity Rule (2023)", + "display_name": "US - Securities and Exchange Commission (SEC) Cybersecurity Rule (2023)", "scf_controls_mapped": 40, "framework_controls_mapped": 15 }, { "framework_id": "usa-federal-sro-fca-crm-2023", - "display_name": "Farm Credit Administration (FCA) Cyber Risk Management (2023)", + "display_name": "US - Farm Credit Administration (FCA) Cyber Risk Management (2023)", "scf_controls_mapped": 81, "framework_controls_mapped": 34 }, { "framework_id": "usa-federal-sro-finra", - "display_name": "FINRA Cybersecurity Rules", + "display_name": "US - Financial Industry Regulatory Authority (FINRA) Cybersecurity Rules", "scf_controls_mapped": 17, "framework_controls_mapped": 39 }, { "framework_id": "usa-federal-tsa-security-directive-1580-82-2022-01", - "display_name": "TSA Security Directive 1580/82-2022-01", + "display_name": "US - Transportation Security Administration (TSA) Security Directive 1580/82 - 2022 - 01 - Rail Cybersecurity Mitigation Actions and Testing", "scf_controls_mapped": 60, "framework_controls_mapped": 68 }, { "framework_id": "usa-state-ak-pipa-2009", - "display_name": "Alaska Personal Information Protection Act (PIPA) (2009)", + "display_name": "US - Alaska Personal Information Protection Act (PIPA) (2009)", "scf_controls_mapped": 5, "framework_controls_mapped": 25 }, { "framework_id": "usa-state-ca-ccpa-cpra-2026", - "display_name": "California Consumer Privacy Act (CCPA) (2026)", + "display_name": "US - California Consumer Privacy Act (CCPA) (January 2026) - amended California Privacy Rights Act (CPRA)", "scf_controls_mapped": 258, "framework_controls_mapped": 623 }, { "framework_id": "usa-state-ca-sb1386-2002", - "display_name": "California SB1386 (2002)", + "display_name": "US - California SB1386 (2002)", "scf_controls_mapped": 4, "framework_controls_mapped": 6 }, { "framework_id": "usa-state-ca-sb327-2018", - "display_name": "California SB327 (2018)", + "display_name": "US - California SB327 (2018)", "scf_controls_mapped": 3, "framework_controls_mapped": 7 }, { "framework_id": "usa-state-co-privacy-act-2021", - "display_name": "Colorado Privacy Act (2021)", + "display_name": "US - Colorado Privacy Act (2021)", "scf_controls_mapped": 23, "framework_controls_mapped": 52 }, { "framework_id": "usa-state-il-bipa-2008", - "display_name": "Illinois Biometric Information Privacy Act (BIPA) (2008)", + "display_name": "US - Illinois Biometric Information Privacy Act (BIPA) (2008)", "scf_controls_mapped": 6, "framework_controls_mapped": 12 }, { "framework_id": "usa-state-il-ipa-2009", - "display_name": "Illinois Identity Protection Act (IPA) (2009)", + "display_name": "US - Illinois Identity Protection Act (IPA) (2009)", "scf_controls_mapped": 12, "framework_controls_mapped": 33 }, { "framework_id": "usa-state-il-pipa-2006", - "display_name": "Illinois Personal Information Protection Act (PIPA) (2006)", + "display_name": "US - Illinois Personal Information Protection Act (PIPA) (2006)", "scf_controls_mapped": 10, "framework_controls_mapped": 53 }, { "framework_id": "usa-state-ma-201-cmr-17-2008", - "display_name": "Massachusetts 201 CMR 17.00 (2008)", + "display_name": "US - Massachusetts 201 CMR 17.00 (2008)", "scf_controls_mapped": 53, "framework_controls_mapped": 37 }, + { + "framework_id": "usa-state-nv-privacy-law-2023", + "display_name": "US - Nevada Privacy Law (2023) - CHAPTER 603A - SECURITY AND PRIVACY OF PERSONAL INFORMATION", + "scf_controls_mapped": 29, + "framework_controls_mapped": 121 + }, { "framework_id": "usa-state-nv-regulation-5-2024", - "display_name": "Nevada Operation of Gaming Establishment (NOGE) Regulation 5.260 (2024)", + "display_name": "US - Nevada Operation of Gaming Establishments - Regulation 5.260 (Cybersecurity)", "scf_controls_mapped": 20, "framework_controls_mapped": 11 }, { "framework_id": "usa-state-nv-sb220-2019", - "display_name": "Nevada SB220 (2019)", + "display_name": "US - Nevada SB220 (2019)", "scf_controls_mapped": 3, "framework_controls_mapped": 4 }, { "framework_id": "usa-state-ny-dfs-23-nycrr500-2023-amd2", - "display_name": "New York Department of Financial Services 23NYCRR Part 500 (2023 Amendment 2)", + "display_name": "US - New York Department of Financial Services (NY DFS) 23NYCRR Part 500 (2023 Amendment 2)", "scf_controls_mapped": 156, "framework_controls_mapped": 145 }, { "framework_id": "usa-state-ny-shield-act-2019", - "display_name": "New York SHIELD Act (SB S5575B) (2019)", + "display_name": "US - New York SHIELD Act (SB S5575B) (2019)", "scf_controls_mapped": 28, "framework_controls_mapped": 45 }, { "framework_id": "usa-state-or-cpa-2023", - "display_name": "Oregon Consumer Privacy Act (SB 619) (2023)", + "display_name": "US - Oregon Consumer Privacy Act (SB 619) (2023)", "scf_controls_mapped": 34, "framework_controls_mapped": 75 }, { "framework_id": "usa-state-or-ors-646a-2025", - "display_name": "Oregon Consumer Information Protection Act (ORS 646A) (2025)", + "display_name": "US - Oregon Consumer Information Protection Act (ORS 646A) (2025)", "scf_controls_mapped": 24, "framework_controls_mapped": 97 }, { "framework_id": "usa-state-tn-tipa-2025", - "display_name": "Tennessee Information Protection Act (TIPA) (2025)", + "display_name": "US - Tennessee Information Protection Act (TIPA) (2025)", "scf_controls_mapped": 29, "framework_controls_mapped": 76 }, { "framework_id": "usa-state-tx-bc521-2009", - "display_name": "Texas Identity Theft Enforcement and Protection Act (BC521) (2009)", + "display_name": "US - Texas Identity Theft Enforcement and Protection Act (BC521) (2009)", "scf_controls_mapped": 5, "framework_controls_mapped": 27 }, { "framework_id": "usa-state-tx-cdpa-2025", - "display_name": "Texas Consumer Data Protection Act (2025)", + "display_name": "US - Texas Consumer Data Protection Act (2025)", "scf_controls_mapped": 28, "framework_controls_mapped": 89 }, { "framework_id": "usa-state-tx-dir-security-control-standards-catalog-2-2", - "display_name": "Texas DIR Security Control Standards Catalog (v2.2)", + "display_name": "US - Texas DIR Security Control Standards Catalog v2.2", "scf_controls_mapped": 238, "framework_controls_mapped": 228 }, { "framework_id": "usa-state-tx-sb2610-2025", - "display_name": "Texas Safe Harbor Law (SB2610) (2025)", + "display_name": "US - Texas Safe Harbor Law (SB2610) (2025)", "scf_controls_mapped": 6, "framework_controls_mapped": 33 }, { "framework_id": "usa-state-tx-sb820-2019", - "display_name": "Texas SB820 (2019)", + "display_name": "US - Texas SB820 (2019)", "scf_controls_mapped": 4, "framework_controls_mapped": 7 }, { "framework_id": "usa-state-tx-txramp-2-0-level-1", - "display_name": "TX-RAMP 2.0 - Level 1", + "display_name": "US - Texas Risk & Authorization Management Program 2.0 - Level 1", "scf_controls_mapped": 173, "framework_controls_mapped": 117 }, { "framework_id": "usa-state-tx-txramp-2-0-level-2", - "display_name": "TX-RAMP 2.0 - Level 2", + "display_name": "US - Texas Risk & Authorization Management Program 2.0 - Level 2", "scf_controls_mapped": 285, "framework_controls_mapped": 223 }, { "framework_id": "usa-state-va-cdpa-2023", - "display_name": "Virginia Consumer Data Protection Act (2023)", + "display_name": "US - Virginia Consumer Data Protection Act (2023)", "scf_controls_mapped": 44, "framework_controls_mapped": 64 }, { "framework_id": "usa-state-vt-act-171-2018", - "display_name": "Vermont Data Broker Registration Act (Act 171 of 2018)", + "display_name": "US - Vermont Data Broker Registration Act (Act 171 of 2018)", "scf_controls_mapped": 35, "framework_controls_mapped": 61 } diff --git a/docs/api/crosswalks/amaericas-can-osfi-self-assessment.json b/docs/api/crosswalks/amaericas-can-osfi-self-assessment.json deleted file mode 100644 index ee51ad08..00000000 --- a/docs/api/crosswalks/amaericas-can-osfi-self-assessment.json +++ /dev/null @@ -1,990 +0,0 @@ -{ - "framework_id": "amaericas-can-osfi-self-assessment", - "display_name": "Canada - OSFI Cyber Security Self-Assessment Guidance", - "scf_to_framework": { - "total_mappings": 141, - "mappings": { - "GOV-01": [ - "6.5", - "6.6", - "6.7", - "6.23" - ], - "GOV-01.1": [ - "6.5", - "6.6", - "6.7", - "6.21", - "6.22", - "6.23", - "6.24" - ], - "GOV-02": [ - "6.1", - "6.3" - ], - "GOV-04": [ - "1.1", - "1.2", - "6.2" - ], - "GOV-05": [ - "6.9" - ], - "GOV-07": [ - "3.7" - ], - "AST-02": [ - "3.1" - ], - "AST-02.5": [ - "4.21", - "4.24" - ], - "AST-04": [ - "3.1" - ], - "BCD-01": [ - "2.9" - ], - "BCD-01.2": [ - "2.9" - ], - "BCD-02.1": [ - "2.9" - ], - "BCD-02.2": [ - "2.9" - ], - "BCD-02.3": [ - "2.9" - ], - "BCD-03.1": [ - "2.8" - ], - "BCD-04": [ - "2.8" - ], - "BCD-04.1": [ - "2.8" - ], - "BCD-05": [ - "5.9" - ], - "CAP-04": [ - "3.1" - ], - "CHG-01": [ - "4.17", - "4.20", - "6.11" - ], - "CHG-02": [ - "4.18", - "4.20" - ], - "CHG-02.2": [ - "6.11" - ], - "CHG-02.3": [ - "2.4", - "6.11" - ], - "CHG-04.1": [ - "6.11" - ], - "CPL-01.1": [ - "6.10", - "6.14" - ], - "CPL-02": [ - "6.10" - ], - "CPL-02.1": [ - "6.17", - "6.18", - "6.19", - "6.20" - ], - "CPL-03": [ - "6.10" - ], - "CPL-03.1": [ - "6.13", - "6.25" - ], - "CFG-02": [ - "4.16", - "4.20" - ], - "CFG-02.8": [ - "4.19", - "4.20" - ], - "CFG-03.2": [ - "4.19", - "4.20" - ], - "CFG-03.3": [ - "4.19", - "4.20" - ], - "CFG-04.2": [ - "4.6", - "4.9" - ], - "CFG-05": [ - "4.19", - "4.20" - ], - "CFG-05.1": [ - "4.19", - "4.20" - ], - "CFG-05.2": [ - "4.19", - "4.20" - ], - "CFG-06": [ - "4.19", - "4.20" - ], - "CFG-06.1": [ - "4.19", - "4.20" - ], - "MON-01": [ - "3.5" - ], - "MON-01.1": [ - "3.3", - "4.3", - "4.4" - ], - "MON-01.2": [ - "3.4" - ], - "MON-01.4": [ - "3.6" - ], - "MON-01.8": [ - "3.5" - ], - "MON-01.16": [ - "3.5" - ], - "MON-02": [ - "3.2" - ], - "MON-02.1": [ - "3.6" - ], - "END-01": [ - "4.3", - "4.4" - ], - "END-02": [ - "4.3", - "4.4" - ], - "END-04": [ - "4.3", - "4.4" - ], - "END-05": [ - "4.3", - "4.4" - ], - "END-07": [ - "4.3", - "4.4" - ], - "END-08": [ - "4.3", - "4.4" - ], - "END-08.1": [ - "4.3", - "4.4" - ], - "HRS-01": [ - "1.5" - ], - "HRS-03": [ - "1.2" - ], - "HRS-03.2": [ - "1.5", - "1.7" - ], - "HRS-04": [ - "1.6" - ], - "HRS-04.1": [ - "1.6" - ], - "IAC-01": [ - "4.22", - "4.24" - ], - "IAC-16": [ - "4.23", - "4.24" - ], - "IRO-01": [ - "1.3", - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], - "IRO-02.5": [ - "3.6" - ], - "IRO-02.6": [ - "4.13", - "4.15" - ], - "IRO-04": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], - "IRO-04.2": [ - "5.9" - ], - "IRO-05": [ - "2.8" - ], - "IRO-05.1": [ - "2.8" - ], - "IRO-06": [ - "2.8" - ], - "IRO-06.1": [ - "2.8" - ], - "IRO-07": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], - "IRO-13": [ - "5.9" - ], - "IAO-03.2": [ - "4.26", - "4.28" - ], - "IAO-04": [ - "2.7" - ], - "IAO-05": [ - "5.9" - ], - "MDM-01": [ - "4.14", - "4.15" - ], - "NET-01": [ - "4.10", - "4.15" - ], - "NET-02": [ - "4.11", - "4.12", - "4.15" - ], - "NET-02.1": [ - "4.3", - "4.4" - ], - "NET-08": [ - "4.3", - "4.4" - ], - "NET-08.2": [ - "4.3", - "4.4" - ], - "NET-17": [ - "4.1", - "4.2" - ], - "PRM-01": [ - "1.1", - "6.22" - ], - "PRM-01.1": [ - "1.1", - "6.7" - ], - "PRM-01.2": [ - "6.7" - ], - "PRM-02": [ - "1.1", - "6.22" - ], - "PRM-03": [ - "6.22" - ], - "PRM-04": [ - "6.7" - ], - "PRM-05": [ - "6.7" - ], - "RSK-01": [ - "1.3", - "6.4", - "6.8", - "6.16", - "6.24" - ], - "RSK-01.1": [ - "6.15", - "6.24" - ], - "RSK-02": [ - "6.24" - ], - "RSK-02.1": [ - "6.24" - ], - "RSK-03": [ - "6.24" - ], - "RSK-04": [ - "2.1", - "6.8" - ], - "RSK-04.1": [ - "6.24" - ], - "RSK-05": [ - "2.2" - ], - "RSK-06": [ - "2.2", - "2.7", - "6.8" - ], - "RSK-06.1": [ - "6.24" - ], - "RSK-06.2": [ - "6.16", - "6.24" - ], - "RSK-09": [ - "2.3", - "4.25" - ], - "SEA-02.1": [ - "6.4" - ], - "OPS-01": [ - "1.3", - "1.5" - ], - "OPS-02": [ - "4.30" - ], - "OPS-03": [ - "1.3", - "1.5" - ], - "OPS-04": [ - "1.4" - ], - "OPS-05": [ - "4.29", - "4.30" - ], - "SAT-01": [ - "1.7", - "1.8", - "1.9" - ], - "SAT-02": [ - "1.8", - "1.9" - ], - "SAT-02.2": [ - "1.8", - "1.9" - ], - "SAT-03": [ - "1.7", - "1.8", - "1.9" - ], - "SAT-03.2": [ - "1.8", - "1.9" - ], - "SAT-03.3": [ - "1.7" - ], - "SAT-03.5": [ - "1.7" - ], - "SAT-03.6": [ - "1.7", - "1.8", - "1.9" - ], - "TDA-01": [ - "4.8", - "4.9" - ], - "TDA-06": [ - "4.8", - "4.9" - ], - "TDA-09": [ - "4.8", - "4.9" - ], - "TDA-15": [ - "2.7" - ], - "TDA-17": [ - "4.6", - "4.9" - ], - "TPM-01": [ - "2.3", - "4.25" - ], - "TPM-02": [ - "2.3", - "4.27" - ], - "TPM-03": [ - "2.3", - "4.25" - ], - "TPM-03.2": [ - "2.3", - "4.25" - ], - "TPM-04": [ - "2.3", - "4.25" - ], - "TPM-04.1": [ - "2.3", - "4.25", - "4.27" - ], - "TPM-05": [ - "2.3", - "4.26", - "4.28" - ], - "TPM-06": [ - "2.3" - ], - "TPM-07": [ - "4.27" - ], - "TPM-08": [ - "4.27" - ], - "TPM-09": [ - "2.7", - "4.27" - ], - "TPM-10": [ - "4.27" - ], - "TPM-11": [ - "4.28" - ], - "THR-01": [ - "1.3" - ], - "THR-03": [ - "3.7" - ], - "VPM-02": [ - "2.7" - ], - "VPM-04": [ - "2.7" - ], - "VPM-05": [ - "4.5", - "4.7", - "4.9" - ], - "VPM-06": [ - "2.5" - ], - "VPM-07": [ - "2.6" - ], - "WEB-03": [ - "4.3", - "4.4" - ] - } - }, - "framework_to_scf": { - "total_mappings": 88, - "mappings": { - "6.5": [ - "GOV-01", - "GOV-01.1" - ], - "6.6": [ - "GOV-01", - "GOV-01.1" - ], - "6.7": [ - "GOV-01", - "GOV-01.1", - "PRM-01.1", - "PRM-01.2", - "PRM-04", - "PRM-05" - ], - "6.23": [ - "GOV-01", - "GOV-01.1" - ], - "6.21": [ - "GOV-01.1" - ], - "6.22": [ - "GOV-01.1", - "PRM-01", - "PRM-02", - "PRM-03" - ], - "6.24": [ - "GOV-01.1", - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-02.1", - "RSK-03", - "RSK-04.1", - "RSK-06.1", - "RSK-06.2" - ], - "6.1": [ - "GOV-02" - ], - "6.3": [ - "GOV-02" - ], - "1.1": [ - "GOV-04", - "PRM-01", - "PRM-01.1", - "PRM-02" - ], - "1.2": [ - "GOV-04", - "HRS-03" - ], - "6.2": [ - "GOV-04" - ], - "6.9": [ - "GOV-05" - ], - "3.7": [ - "GOV-07", - "THR-03" - ], - "3.1": [ - "AST-02", - "AST-04", - "CAP-04" - ], - "4.21": [ - "AST-02.5" - ], - "4.24": [ - "AST-02.5", - "IAC-01", - "IAC-16" - ], - "2.9": [ - "BCD-01", - "BCD-01.2", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3" - ], - "2.8": [ - "BCD-03.1", - "BCD-04", - "BCD-04.1", - "IRO-05", - "IRO-05.1", - "IRO-06", - "IRO-06.1" - ], - "5.9": [ - "BCD-05", - "IRO-04.2", - "IRO-13", - "IAO-05" - ], - "4.17": [ - "CHG-01" - ], - "4.20": [ - "CHG-01", - "CHG-02", - "CFG-02", - "CFG-02.8", - "CFG-03.2", - "CFG-03.3", - "CFG-05", - "CFG-05.1", - "CFG-05.2", - "CFG-06", - "CFG-06.1" - ], - "6.11": [ - "CHG-01", - "CHG-02.2", - "CHG-02.3", - "CHG-04.1" - ], - "4.18": [ - "CHG-02" - ], - "2.4": [ - "CHG-02.3" - ], - "6.10": [ - "CPL-01.1", - "CPL-02", - "CPL-03" - ], - "6.14": [ - "CPL-01.1" - ], - "6.17": [ - "CPL-02.1" - ], - "6.18": [ - "CPL-02.1" - ], - "6.19": [ - "CPL-02.1" - ], - "6.20": [ - "CPL-02.1" - ], - "6.13": [ - "CPL-03.1" - ], - "6.25": [ - "CPL-03.1" - ], - "4.16": [ - "CFG-02" - ], - "4.19": [ - "CFG-02.8", - "CFG-03.2", - "CFG-03.3", - "CFG-05", - "CFG-05.1", - "CFG-05.2", - "CFG-06", - "CFG-06.1" - ], - "4.6": [ - "CFG-04.2", - "TDA-17" - ], - "4.9": [ - "CFG-04.2", - "TDA-01", - "TDA-06", - "TDA-09", - "TDA-17", - "VPM-05" - ], - "3.5": [ - "MON-01", - "MON-01.8", - "MON-01.16" - ], - "3.3": [ - "MON-01.1" - ], - "4.3": [ - "MON-01.1", - "END-01", - "END-02", - "END-04", - "END-05", - "END-07", - "END-08", - "END-08.1", - "NET-02.1", - "NET-08", - "NET-08.2", - "WEB-03" - ], - "4.4": [ - "MON-01.1", - "END-01", - "END-02", - "END-04", - "END-05", - "END-07", - "END-08", - "END-08.1", - "NET-02.1", - "NET-08", - "NET-08.2", - "WEB-03" - ], - "3.4": [ - "MON-01.2" - ], - "3.6": [ - "MON-01.4", - "MON-02.1", - "IRO-02.5" - ], - "3.2": [ - "MON-02" - ], - "1.5": [ - "HRS-01", - "HRS-03.2", - "OPS-01", - "OPS-03" - ], - "1.7": [ - "HRS-03.2", - "SAT-01", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6" - ], - "1.6": [ - "HRS-04", - "HRS-04.1" - ], - "4.22": [ - "IAC-01" - ], - "4.23": [ - "IAC-16" - ], - "1.3": [ - "IRO-01", - "RSK-01", - "OPS-01", - "OPS-03", - "THR-01" - ], - "5.1": [ - "IRO-01", - "IRO-04", - "IRO-07" - ], - "5.2": [ - "IRO-01", - "IRO-04", - "IRO-07" - ], - "5.3": [ - "IRO-01", - "IRO-04", - "IRO-07" - ], - "5.4": [ - "IRO-01", - "IRO-04", - "IRO-07" - ], - "5.5": [ - "IRO-01", - "IRO-04", - "IRO-07" - ], - "5.6": [ - "IRO-01", - "IRO-04", - "IRO-07" - ], - "5.7": [ - "IRO-01", - "IRO-04", - "IRO-07" - ], - "5.8": [ - "IRO-01", - "IRO-04", - "IRO-07" - ], - "4.13": [ - "IRO-02.6" - ], - "4.15": [ - "IRO-02.6", - "MDM-01", - "NET-01", - "NET-02" - ], - "4.26": [ - "IAO-03.2", - "TPM-05" - ], - "4.28": [ - "IAO-03.2", - "TPM-05", - "TPM-11" - ], - "2.7": [ - "IAO-04", - "RSK-06", - "TDA-15", - "TPM-09", - "VPM-02", - "VPM-04" - ], - "4.14": [ - "MDM-01" - ], - "4.10": [ - "NET-01" - ], - "4.11": [ - "NET-02" - ], - "4.12": [ - "NET-02" - ], - "4.1": [ - "NET-17" - ], - "4.2": [ - "NET-17" - ], - "6.4": [ - "RSK-01", - "SEA-02.1" - ], - "6.8": [ - "RSK-01", - "RSK-04", - "RSK-06" - ], - "6.16": [ - "RSK-01", - "RSK-06.2" - ], - "6.15": [ - "RSK-01.1" - ], - "2.1": [ - "RSK-04" - ], - "2.2": [ - "RSK-05", - "RSK-06" - ], - "2.3": [ - "RSK-09", - "TPM-01", - "TPM-02", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-06" - ], - "4.25": [ - "RSK-09", - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-04.1" - ], - "4.30": [ - "OPS-02", - "OPS-05" - ], - "1.4": [ - "OPS-04" - ], - "4.29": [ - "OPS-05" - ], - "1.8": [ - "SAT-01", - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.6" - ], - "1.9": [ - "SAT-01", - "SAT-02", - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.6" - ], - "4.8": [ - "TDA-01", - "TDA-06", - "TDA-09" - ], - "4.27": [ - "TPM-02", - "TPM-04.1", - "TPM-07", - "TPM-08", - "TPM-09", - "TPM-10" - ], - "4.5": [ - "VPM-05" - ], - "4.7": [ - "VPM-05" - ], - "2.5": [ - "VPM-06" - ], - "2.6": [ - "VPM-07" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/americas-arg-ppd-2018.json b/docs/api/crosswalks/americas-arg-ppd-2018.json index 5b846af9..c75d8bb4 100644 --- a/docs/api/crosswalks/americas-arg-ppd-2018.json +++ b/docs/api/crosswalks/americas-arg-ppd-2018.json @@ -2,284 +2,578 @@ "framework_id": "americas-arg-ppd-2018", "display_name": "Argentina - Protection of Personal Data (2018)", "scf_to_framework": { - "total_mappings": 25, + "total_mappings": 78, "mappings": { - "CLD-09": [ - "12.1", - "12.2" - ], - "CPL-01": [ - "10.1", - "10.2" - ], - "DCH-09.3": [ - "4.7", - "16.7", - "25.2" - ], - "DCH-22.1": [ - "16.1", - "16.3" - ], - "PRI-02.1": [ - "6", - "27.1", - "27.2", - "28.1" - ], - "PRI-03": [ - "5.1", - "5.2" - ], - "PRI-03.2": [ - "27.3" - ], - "PRI-04": [ - "4.1", - "4.2", - "6" - ], - "PRI-04.1": [ - "5.2", - "7.1", - "7.2", - "7.4", - "8" - ], - "PRI-05": [ - "5.1", - "4.3", - "9.2" - ], - "PRI-05.1": [ - "7.3", - "9.2" + "GOV-04": [ + "E.1.2-8" + ], + "AST-01": [ + "B.1.3-3" + ], + "AST-01.1": [ + "B.1.1" + ], + "AST-02": [ + "B.1.1", + "D.1.1-4" + ], + "AST-02.1": [ + "B.1.3-1" + ], + "AST-03": [ + "B.1.2-1", + "B.1.2-2" + ], + "AST-04": [ + "B.1.1", + "E.1.1-2" + ], + "AST-09": [ + "F", + "F.1.2-DS-2" + ], + "BCD-11": [ + "D", + "D.1.1-1" + ], + "BCD-11.1": [ + "D.1.1-2", + "D.1.1-3", + "D.1.2-4" + ], + "BCD-11.2": [ + "D.1.2-DS-2" + ], + "BCD-11.4": [ + "D.1.2-2" + ], + "BCD-12": [ + "D.1.2-3", + "D.1.2-DS-4" + ], + "BCD-13": [ + "D.1.2-DS-4" + ], + "BCD-14": [ + "D.1.2-DS-4" + ], + "CHG-01": [ + "C", + "C.1.1-2" + ], + "CHG-02": [ + "C.1.1-DS" + ], + "CHG-02.2": [ + "C.1.1-3" + ], + "CHG-06": [ + "C.1.1-1" + ], + "CPL-02.2": [ + "E.1.4-DS-2" + ], + "CPL-03": [ + "E.1.4-DS-1" + ], + "CFG-02": [ + "B.2.4-4", + "E.1.2-5" + ], + "CFG-02.5": [ + "E.1.2-2", + "E.1.2-DS-1" + ], + "MON-01.4": [ + "B.2.3-3", + "B.2.3-4", + "B.2.5-DS-3" + ], + "MON-01.8": [ + "B.2.5-DS-3" + ], + "MON-01.15": [ + "B.2.1-3" + ], + "CRY-03": [ + "A.2.1", + "A.2.3-DS" + ], + "CRY-08": [ + "A.2.3" + ], + "CRY-09": [ + "A.2.3" + ], + "DCH-01.4": [ + "B.1.3-2", + "B.2.1-2" + ], + "DCH-03.2": [ + "H.1.1" + ], + "DCH-07": [ + "D.1.2-DS-3" + ], + "DCH-07.1": [ + "D.1.2-DS-3" + ], + "DCH-08": [ + "F.1.2-DS-1" + ], + "DCH-09": [ + "D.1.2-4", + "F.1.2" + ], + "DCH-09.1": [ + "F.1.1", + "F.1.4" + ], + "DCH-23": [ + "H.1.1" + ], + "END-02": [ + "E.1.2-5" + ], + "END-04": [ + "E.1.2-6" + ], + "HRS-03": [ + "B.2.2", + "E.1.2-1", + "F.1.3" + ], + "HRS-03.1": [ + "B.2.2" + ], + "HRS-04.2": [ + "B.2.2" + ], + "IAC-01": [ + "B", + "D.1.2-1" + ], + "IAC-01.2": [ + "B.2.3-1" + ], + "IAC-08": [ + "B.1.2-3" + ], + "IAC-10.1": [ + "B.2.3-7" + ], + "IAC-15.1": [ + "B.2.3-2" + ], + "IAC-15.3": [ + "B.2.5" + ], + "IAC-15.5": [ + "B.2.3-8" + ], + "IAC-16": [ + "B.2.1-2", + "B.2.1-3", + "B.2.3-6", + "B.2.5-DS-2" + ], + "IAC-23": [ + "B.2.5-DS-1" + ], + "IAC-28.1": [ + "B.2.3-5" + ], + "IRO-01": [ + "E.1.2-11", + "G" + ], + "IRO-02": [ + "E.1.2-10", + "E.1.2-11", + "G.1.1-1" + ], + "IRO-04": [ + "G.1.1-1" + ], + "IRO-07": [ + "G.1.1-2" + ], + "IRO-10": [ + "G.1.2" + ], + "IRO-10.2": [ + "G.1.3" + ], + "IAO-03": [ + "B.2.1-1", + "E.1.1-3" + ], + "NET-06": [ + "E.1.2-3" + ], + "NET-08": [ + "E.1.2-DS-2" + ], + "NET-17": [ + "E.1.2-DS-3" + ], + "PES-03": [ + "B.2.4-1", + "B.2.4-2" + ], + "PES-03.1": [ + "B.2.4-3" + ], + "PES-03.3": [ + "B.2.4-3", + "B.2.4-4" + ], + "PES-07.5": [ + "D.1.2-DS-1" + ], + "PES-08": [ + "D.1.2-DS-1" + ], + "PRI-01.6": [ + "E.1.2-1" + ], + "PRI-01.11": [ + "A", + "A.1.1", + "A.1.2", + "A.1.3", + "A.2.2-1", + "A.2.2-2" ], "PRI-05.2": [ - "4.5" - ], - "PRI-05.3": [ - "4.4" - ], - "PRI-05.4": [ - "4.3" - ], - "PRI-06": [ - "4.6", - "13", - "14.1", - "14.2", - "14.3", - "14.4" - ], - "PRI-06.1": [ - "16.1", - "16.3" - ], - "PRI-06.2": [ - "16.2" - ], - "PRI-06.4": [ - "16.2", - "16.6" - ], - "PRI-06.5": [ - "16.5", - "16.7" - ], - "PRI-06.6": [ - "15.1", - "15.2", - "15.3" - ], - "PRI-07": [ - "11.1", - "11.2", - "11.3", - "11.4", - "12.1", - "16.4" - ], - "PRI-07.1": [ - "11.4" - ], - "PRI-15": [ - "21.1", - "21.2", - "21.3", - "24" - ], - "SEA-01.1": [ - "9.1" - ], - "TPM-04": [ - "25.1" + "A.1.3" + ], + "SEA-20": [ + "E.1.2-9" + ], + "OPS-01.1": [ + "B.1.3-1", + "B.1.3-2", + "B.1.3-3", + "B.2.4-2", + "B.2.5" + ], + "TDA-01": [ + "H" + ], + "TDA-08": [ + "E.1.2-4" + ], + "THR-09": [ + "E.1.1-1" + ], + "THR-10": [ + "E.1.1-1" + ], + "VPM-01": [ + "E" + ], + "VPM-05": [ + "E.1.2-7" ] } }, "framework_to_scf": { - "total_mappings": 50, + "total_mappings": 89, "mappings": { - "6": [ - "PRI-02.1", - "PRI-04" + "E.1.2-8": [ + "GOV-04" ], - "8": [ - "PRI-04.1" + "B.1.3-3": [ + "AST-01", + "OPS-01.1" ], - "13": [ - "PRI-06" + "B.1.1": [ + "AST-01.1", + "AST-02", + "AST-04" ], - "24": [ - "PRI-15" + "D.1.1-4": [ + "AST-02" ], - "12.1": [ - "CLD-09", - "PRI-07" + "B.1.3-1": [ + "AST-02.1", + "OPS-01.1" ], - "12.2": [ - "CLD-09" + "B.1.2-1": [ + "AST-03" ], - "10.1": [ - "CPL-01" + "B.1.2-2": [ + "AST-03" ], - "10.2": [ - "CPL-01" + "E.1.1-2": [ + "AST-04" ], - "4.7": [ - "DCH-09.3" + "F": [ + "AST-09" ], - "16.7": [ - "DCH-09.3", - "PRI-06.5" + "F.1.2-DS-2": [ + "AST-09" ], - "25.2": [ - "DCH-09.3" + "D": [ + "BCD-11" ], - "16.1": [ - "DCH-22.1", - "PRI-06.1" + "D.1.1-1": [ + "BCD-11" ], - "16.3": [ - "DCH-22.1", - "PRI-06.1" + "D.1.1-2": [ + "BCD-11.1" ], - "27.1": [ - "PRI-02.1" + "D.1.1-3": [ + "BCD-11.1" ], - "27.2": [ - "PRI-02.1" + "D.1.2-4": [ + "BCD-11.1", + "DCH-09" ], - "28.1": [ - "PRI-02.1" + "D.1.2-DS-2": [ + "BCD-11.2" ], - "5.1": [ - "PRI-03", - "PRI-05" + "D.1.2-2": [ + "BCD-11.4" ], - "5.2": [ - "PRI-03", - "PRI-04.1" + "D.1.2-3": [ + "BCD-12" ], - "27.3": [ - "PRI-03.2" + "D.1.2-DS-4": [ + "BCD-12", + "BCD-13", + "BCD-14" ], - "4.1": [ - "PRI-04" + "C": [ + "CHG-01" ], - "4.2": [ - "PRI-04" + "C.1.1-2": [ + "CHG-01" ], - "7.1": [ - "PRI-04.1" + "C.1.1-DS": [ + "CHG-02" ], - "7.2": [ - "PRI-04.1" + "C.1.1-3": [ + "CHG-02.2" ], - "7.4": [ - "PRI-04.1" + "C.1.1-1": [ + "CHG-06" ], - "4.3": [ - "PRI-05", - "PRI-05.4" + "E.1.4-DS-2": [ + "CPL-02.2" ], - "9.2": [ - "PRI-05", - "PRI-05.1" + "E.1.4-DS-1": [ + "CPL-03" ], - "7.3": [ - "PRI-05.1" + "B.2.4-4": [ + "CFG-02", + "PES-03.3" ], - "4.5": [ - "PRI-05.2" + "E.1.2-5": [ + "CFG-02", + "END-02" + ], + "E.1.2-2": [ + "CFG-02.5" + ], + "E.1.2-DS-1": [ + "CFG-02.5" + ], + "B.2.3-3": [ + "MON-01.4" + ], + "B.2.3-4": [ + "MON-01.4" + ], + "B.2.5-DS-3": [ + "MON-01.4", + "MON-01.8" + ], + "B.2.1-3": [ + "MON-01.15", + "IAC-16" + ], + "A.2.1": [ + "CRY-03" + ], + "A.2.3-DS": [ + "CRY-03" + ], + "A.2.3": [ + "CRY-08", + "CRY-09" + ], + "B.1.3-2": [ + "DCH-01.4", + "OPS-01.1" + ], + "B.2.1-2": [ + "DCH-01.4", + "IAC-16" ], - "4.4": [ - "PRI-05.3" + "H.1.1": [ + "DCH-03.2", + "DCH-23" ], - "4.6": [ - "PRI-06" + "D.1.2-DS-3": [ + "DCH-07", + "DCH-07.1" ], - "14.1": [ - "PRI-06" + "F.1.2-DS-1": [ + "DCH-08" ], - "14.2": [ - "PRI-06" + "F.1.2": [ + "DCH-09" ], - "14.3": [ - "PRI-06" + "F.1.1": [ + "DCH-09.1" ], - "14.4": [ - "PRI-06" + "F.1.4": [ + "DCH-09.1" ], - "16.2": [ - "PRI-06.2", - "PRI-06.4" + "E.1.2-6": [ + "END-04" ], - "16.6": [ - "PRI-06.4" + "B.2.2": [ + "HRS-03", + "HRS-03.1", + "HRS-04.2" ], - "16.5": [ - "PRI-06.5" + "E.1.2-1": [ + "HRS-03", + "PRI-01.6" ], - "15.1": [ - "PRI-06.6" + "F.1.3": [ + "HRS-03" ], - "15.2": [ - "PRI-06.6" + "B": [ + "IAC-01" ], - "15.3": [ - "PRI-06.6" + "D.1.2-1": [ + "IAC-01" ], - "11.1": [ - "PRI-07" + "B.2.3-1": [ + "IAC-01.2" ], - "11.2": [ - "PRI-07" + "B.1.2-3": [ + "IAC-08" + ], + "B.2.3-7": [ + "IAC-10.1" + ], + "B.2.3-2": [ + "IAC-15.1" + ], + "B.2.5": [ + "IAC-15.3", + "OPS-01.1" + ], + "B.2.3-8": [ + "IAC-15.5" + ], + "B.2.3-6": [ + "IAC-16" + ], + "B.2.5-DS-2": [ + "IAC-16" + ], + "B.2.5-DS-1": [ + "IAC-23" + ], + "B.2.3-5": [ + "IAC-28.1" + ], + "E.1.2-11": [ + "IRO-01", + "IRO-02" + ], + "G": [ + "IRO-01" + ], + "E.1.2-10": [ + "IRO-02" + ], + "G.1.1-1": [ + "IRO-02", + "IRO-04" + ], + "G.1.1-2": [ + "IRO-07" + ], + "G.1.2": [ + "IRO-10" + ], + "G.1.3": [ + "IRO-10.2" + ], + "B.2.1-1": [ + "IAO-03" + ], + "E.1.1-3": [ + "IAO-03" + ], + "E.1.2-3": [ + "NET-06" + ], + "E.1.2-DS-2": [ + "NET-08" + ], + "E.1.2-DS-3": [ + "NET-17" + ], + "B.2.4-1": [ + "PES-03" + ], + "B.2.4-2": [ + "PES-03", + "OPS-01.1" + ], + "B.2.4-3": [ + "PES-03.1", + "PES-03.3" + ], + "D.1.2-DS-1": [ + "PES-07.5", + "PES-08" + ], + "A": [ + "PRI-01.11" + ], + "A.1.1": [ + "PRI-01.11" + ], + "A.1.2": [ + "PRI-01.11" + ], + "A.1.3": [ + "PRI-01.11", + "PRI-05.2" ], - "11.3": [ - "PRI-07" + "A.2.2-1": [ + "PRI-01.11" ], - "11.4": [ - "PRI-07", - "PRI-07.1" + "A.2.2-2": [ + "PRI-01.11" ], - "16.4": [ - "PRI-07" + "E.1.2-9": [ + "SEA-20" ], - "21.1": [ - "PRI-15" + "H": [ + "TDA-01" ], - "21.2": [ - "PRI-15" + "E.1.2-4": [ + "TDA-08" ], - "21.3": [ - "PRI-15" + "E.1.1-1": [ + "THR-09", + "THR-10" ], - "9.1": [ - "SEA-01.1" + "E": [ + "VPM-01" ], - "25.1": [ - "TPM-04" + "E.1.2-7": [ + "VPM-05" ] } } diff --git a/docs/api/crosswalks/americas-bhs-dpa-2003.json b/docs/api/crosswalks/americas-bhs-dpa-2003.json index 82540133..f198bc9f 100644 --- a/docs/api/crosswalks/americas-bhs-dpa-2003.json +++ b/docs/api/crosswalks/americas-bhs-dpa-2003.json @@ -1,103 +1,1597 @@ { "framework_id": "americas-bhs-dpa-2003", - "display_name": "Bahamas - DPA (2003)", + "display_name": "Bahamas - Data Protection Act (DPA) (2003)", "scf_to_framework": { - "total_mappings": 18, + "total_mappings": 40, "mappings": { - "GOV-01": [ - "6" - ], "CPL-01": [ - "6" + "II.4(1)", + "IV.24(6)", + "IV.24(7)", + "IV.24(7)(a)", + "IV.24(7)(b)", + "V.45(4)(a)", + "V.45(4)(b)", + "V.45(5)", + "V.45(6)", + "V.45(7)" + ], + "CPL-03": [ + "VI.55", + "VI.55(a)", + "VI.55(b)" + ], + "DCH-01.2": [ + "V.46(1)", + "V.46(2)", + "V.46(2)(a)", + "V.46(2)(b)" + ], + "HRS-05": [ + "II.4(2)" + ], + "IRO-04.1": [ + "V.48(1)" + ], + "IRO-10": [ + "V.48(2)", + "V.48(3)", + "V.48(3)(a)", + "V.48(3)(b)", + "V.48(3)(c)" + ], + "IRO-10.2": [ + "V.47(1)", + "V.47(2)", + "V.47(3)", + "V.47(4)(a)", + "V.47(4)(b)", + "V.47(4)(c)", + "V.47(4)(d)", + "V.47(4)(e)", + "V.47(4)(f)", + "V.47(4)(g)", + "V.47(4)(h)", + "V.47(5)", + "V.47(6)", + "V.47(6)(a)", + "V.47(6)(b)", + "V.47(6)(c)" ], - "DCH-22.1": [ - "10" + "IRO-12": [ + "IV.28(3)(a)", + "IV.28(3)(b)", + "IV.28(3)(b)(i)", + "IV.28(3)(b)(ii)", + "IV.28(3)(b)(iii)" + ], + "IAO-03.2": [ + "V.51(1)(a)" ], "PRI-01": [ - "6" + "V.45(2)(a)", + "V.45(2)(b)", + "V.45(2)(b)(i)", + "V.45(2)(b)(ii)" + ], + "PRI-01.4": [ + "V.45(1)", + "V.45(1)(a)", + "V.45(1)(b)", + "V.45(1)(c)", + "V.45(3)", + "V.45(3)(a)", + "V.45(3)(b)", + "V.45(3)(c)", + "V.45(3)(d)", + "V.45(3)(e)", + "V.45(3)(f)", + "V.45(3)(g)", + "V.45(3)(h)", + "V.45(3)(i)", + "V.45(3)(j)" + ], + "PRI-01.6": [ + "II.5(1)(f)", + "II.9(2)", + "II.11(1)", + "II.11(1)(a)", + "II.11(1)(b)", + "II.11(2)", + "V.43(4)(d)", + "V.43(4)(e)", + "V.52(1)", + "V.52(2)", + "V.52(2)(a)", + "V.52(2)(b)", + "V.52(2)(c)", + "V.52(2)(d)", + "V.52(4)" + ], + "PRI-01.11": [ + "II.5(1)(a)", + "II.5(1)(b)", + "II.5(1)(c)", + "II.5(1)(d)", + "II.5(1)(e)", + "II.5(1)(f)", + "II.5(2)", + "II.5(3)", + "II.8(4)", + "V.43(4)(d)", + "V.43(4)(e)" + ], + "PRI-02": [ + "II.8(1)", + "II.8(1)(a)", + "II.8(1)(b)", + "II.8(1)(c)", + "II.8(1)(d)", + "II.8(1)(e)", + "II.8(1)(f)", + "II.8(1)(g)", + "II.8(1)(g)(i)", + "II.8(1)(g)(ii)", + "II.8(1)(g)(iii)", + "II.8(1)(h)", + "II.8(1)(i)", + "II.8(2)", + "II.8(2)(a)", + "II.8(2)(b)", + "IV.24(1)(a)", + "IV.24(1)(b)", + "IV.24(1)(b)(i)", + "IV.24(1)(b)(ii)", + "IV.24(1)(b)(iii)", + "IV.24(1)(b)(iv)", + "IV.24(1)(b)(v)", + "IV.24(1)(c)", + "IV.24(1)(c)(i)", + "IV.24(1)(c)(ii)", + "IV.24(1)(c)(iii)", + "IV.24(1)(d)", + "IV.24(1)(e)", + "IV.24(1)(f)", + "IV.24(1)(g)", + "V.45(8)", + "V.52(3)" ], "PRI-02.1": [ - "6" + "II.5(1)(b)" + ], + "PRI-03": [ + "II.7(1)", + "IV.32(1)", + "IV.32(2)", + "IV.32(2)(a)", + "IV.32(2)(b)", + "IV.32(2)(c)", + "IV.32(3)", + "IV.32(4)", + "IV.32(5)", + "IV.32(6)", + "IV.36(2)" + ], + "PRI-03.9": [ + "IV.35(1)", + "IV.35(1)(a)", + "IV.35(1)(b)", + "IV.36(1)" + ], + "PRI-03.13": [ + "IV.33(1)", + "IV.33(2)", + "IV.33(3)", + "IV.33(4)", + "IV.33(4)(a)", + "IV.33(4)(b)", + "IV.33(4)(c)" ], "PRI-04": [ - "6" + "II.5(1)(c)" ], "PRI-04.1": [ - "6" + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.36(3)", + "IV.36(3)(a)", + "IV.36(3)(b)", + "IV.36(3)(c)", + "IV.36(3)(c)(i)", + "IV.36(3)(c)(ii)" ], "PRI-05": [ - "6", - "12" + "II.5(1)(e)", + "II.9(1)", + "II.9(1)(a)", + "II.9(1)(b)", + "II.9(1)(c)" ], "PRI-05.1": [ - "6" + "II.5(2)" ], "PRI-05.2": [ - "6" + "II.5(1)(d)", + "II.5(3)", + "II.10(1)", + "II.10(2)", + "II.10(2)(a)", + "II.10(2)(b)" ], "PRI-05.4": [ - "12" + "IV.29(2)", + "IV.29(2)(a)", + "IV.29(2)(b)", + "IV.29(2)(c)", + "IV.29(2)(d)", + "IV.34(1)", + "IV.34(2)", + "IV.34(2)(a)", + "IV.34(2)(b)", + "IV.34(2)(c)", + "IV.34(2)(d)", + "IV.34(2)(e)", + "IV.34(2)(e)(i)", + "IV.34(2)(e)(ii)", + "IV.34(2)(f)", + "IV.34(2)(g)", + "IV.34(2)(h)", + "IV.34(2)(i)", + "IV.34(2)(j)", + "IV.34(2)(k)", + "IV.34(2)(l)", + "IV.34(2)(m)", + "IV.34(2)(n)", + "IV.34(2)(n)(i)", + "IV.34(2)(n)(ii)", + "IV.34(2)(n)(iii)", + "IV.34(2)(n)(iv)", + "IV.34(2)(o)", + "IV.34(2)(o)(a)", + "IV.34(2)(o)(b)", + "IV.34(2)(p)", + "IV.34(2)(p)(i)", + "IV.34(2)(p)(ii)", + "IV.34(2)(p)(ii)(aa)", + "IV.34(2)(p)(ii)(bb)", + "IV.34(2)(p)(ii)(cc)", + "IV.34(2)(p)(ii)(dd)", + "IV.34(2)(p)(ii)(ee)", + "IV.34(2)(p)(iii)", + "IV.34(2)(q)", + "IV.34(2)(q)(i)", + "IV.34(2)(q)(ii)", + "IV.34(2)(q)(iii)", + "IV.34(2)(r)", + "IV.34(2)(s)", + "IV.34(4)", + "IV.34(4)(a)", + "IV.34(4)(b)", + "IV.34(5)", + "IV.34(5)(a)", + "IV.34(5)(b)", + "IV.34(5)(c)", + "IV.34(5)(d)", + "IV.34(6)" + ], + "PRI-05.7": [ + "V.43(4)(b)" ], "PRI-06": [ - "8" + "IV.27(1)", + "IV.29(1)", + "IV.29(1)(a)", + "IV.29(1)(b)", + "IV.29(1)(c)", + "IV.29(1)(d)", + "IV.29(1)(e)", + "IV.29(1)(f)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(2)", + "IV.30(2)(a)", + "IV.30(2)(b)", + "IV.30(3)" ], "PRI-06.1": [ - "10" + "IV.26(1)", + "IV.26(2)" ], "PRI-06.2": [ - "11" + "IV.26(3)(a)", + "IV.26(3)(b)" ], "PRI-06.4": [ - "11" + "IV.24(4)", + "IV.24(4)(a)", + "IV.24(4)(b)", + "IV.24(5)", + "IV.24(5)(a)", + "IV.24(5)(b)", + "IV.24(10)", + "IV.24(10)(a)", + "IV.24(10)(b)", + "IV.24(10)(c)", + "IV.24(10)(d)", + "IV.24(13)(f)", + "IV.27(3)", + "IV.28(5)(a)", + "IV.28(5)(b)", + "IV.29(3)(a)", + "IV.29(3)(b)" + ], + "PRI-06.5": [ + "IV.28(1)", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(c)", + "IV.28(2)(d)", + "IV.28(2)(e)", + "IV.28(4)", + "IV.28(4)(a)", + "IV.28(4)(b)", + "IV.28(4)(c)", + "IV.28(4)(d)", + "IV.28(4)(e)" + ], + "PRI-07": [ + "VI.53(1)", + "VI.54", + "VI.54(a)", + "VI.54(b)", + "VI.54(b)(i)", + "VI.54(b)(ii)", + "VI.54(b)(iii)", + "VI.54(b)(iv)", + "VI.54(b)(v)", + "VI.54(b)(vi)", + "VI.54(c)" + ], + "PRI-07.1": [ + "V.51(1)(a)", + "V.51(1)(b)", + "V.51(1)(b)(i)", + "V.51(1)(b)(ii)", + "V.51(1)(b)(iii)", + "V.51(1)(b)(iv)", + "V.51(2)(a)", + "V.51(2)(b)", + "V.51(2)(c)", + "V.51(2)(d)", + "V.51(2)(e)", + "V.51(2)(f)", + "V.51(2)(g)", + "V.51(2)(h)", + "V.51(3)", + "V.51(4)", + "V.51(5)", + "V.51(5)(a)", + "V.51(5)(b)", + "V.51(6)", + "V.51(7)", + "V.51(8)" + ], + "PRI-14": [ + "V.43(1)", + "V.43(2)", + "V.43(2)(a)", + "V.43(2)(b)", + "V.43(2)(c)", + "V.43(2)(d)", + "V.43(2)(e)", + "V.43(2)(f)", + "V.43(2)(g)", + "V.43(2)(h)", + "V.43(2)(i)", + "V.43(2)(j)", + "V.43(3)", + "V.43(4)", + "V.43(4)(a)", + "V.43(4)(b)", + "V.43(4)(c)" + ], + "PRI-14.1": [ + "V.43(4)(c)" ], - "SEA-01": [ - "6", - "12" + "PRI-14.2": [ + "V.46(3)", + "V.46(3)(a)", + "V.46(3)(b)", + "V.46(3)(c)", + "V.46(3)(d)" ], - "SEA-02": [ - "6", - "12" + "PRI-15": [ + "V.41(1)", + "V.41(1)(a)", + "V.41(1)(b)", + "V.41(1)(c)", + "V.41(1)(d)", + "V.41(1)(e)", + "V.41(1)(f)", + "V.41(1)(g)", + "V.41(2)", + "V.41(3)" ], - "SEA-03": [ - "6", - "12" + "PRI-17": [ + "IV.24(2)", + "IV.24(2)(a)", + "IV.24(2)(b)", + "IV.36(4)", + "IV.36(4)(a)", + "IV.36(4)(b)" + ], + "PRI-19": [ + "IV.24(3)", + "V.49(1)", + "V.49(2)", + "V.49(2)(a)", + "V.49(2)(b)", + "V.49(2)(c)", + "V.49(3)", + "V.49(4)", + "V.49(4)(a)", + "V.49(4)(b)" + ], + "PRI-19.3": [ + "IV.24(3)(a)", + "IV.24(3)(b)", + "IV.24(3)(c)", + "IV.24(3)(d)" + ], + "RSK-10": [ + "V.50(1)", + "V.50(1)(a)", + "V.50(1)(b)", + "V.50(2)", + "V.50(2)(a)", + "V.50(2)(b)", + "V.50(2)(c)", + "V.50(3)", + "V.50(3)(a)", + "V.50(3)(b)", + "V.50(3)(c)", + "V.50(3)(d)", + "V.50(4)", + "V.50(5)", + "V.50(6)", + "V.50(7)", + "V.50(8)", + "V.50(8)(a)", + "V.50(8)(b)", + "V.50(8)(c)", + "V.50(8)(d)", + "V.50(8)(e)", + "V.50(8)(f)" ] } }, "framework_to_scf": { - "total_mappings": 5, + "total_mappings": 370, "mappings": { - "6": [ - "GOV-01", - "CPL-01", - "PRI-01", - "PRI-02.1", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.2", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "8": [ + "II.4(1)": [ + "CPL-01" + ], + "IV.24(6)": [ + "CPL-01" + ], + "IV.24(7)": [ + "CPL-01" + ], + "IV.24(7)(a)": [ + "CPL-01" + ], + "IV.24(7)(b)": [ + "CPL-01" + ], + "V.45(4)(a)": [ + "CPL-01" + ], + "V.45(4)(b)": [ + "CPL-01" + ], + "V.45(5)": [ + "CPL-01" + ], + "V.45(6)": [ + "CPL-01" + ], + "V.45(7)": [ + "CPL-01" + ], + "VI.55": [ + "CPL-03" + ], + "VI.55(a)": [ + "CPL-03" + ], + "VI.55(b)": [ + "CPL-03" + ], + "V.46(1)": [ + "DCH-01.2" + ], + "V.46(2)": [ + "DCH-01.2" + ], + "V.46(2)(a)": [ + "DCH-01.2" + ], + "V.46(2)(b)": [ + "DCH-01.2" + ], + "II.4(2)": [ + "HRS-05" + ], + "V.48(1)": [ + "IRO-04.1" + ], + "V.48(2)": [ + "IRO-10" + ], + "V.48(3)": [ + "IRO-10" + ], + "V.48(3)(a)": [ + "IRO-10" + ], + "V.48(3)(b)": [ + "IRO-10" + ], + "V.48(3)(c)": [ + "IRO-10" + ], + "V.47(1)": [ + "IRO-10.2" + ], + "V.47(2)": [ + "IRO-10.2" + ], + "V.47(3)": [ + "IRO-10.2" + ], + "V.47(4)(a)": [ + "IRO-10.2" + ], + "V.47(4)(b)": [ + "IRO-10.2" + ], + "V.47(4)(c)": [ + "IRO-10.2" + ], + "V.47(4)(d)": [ + "IRO-10.2" + ], + "V.47(4)(e)": [ + "IRO-10.2" + ], + "V.47(4)(f)": [ + "IRO-10.2" + ], + "V.47(4)(g)": [ + "IRO-10.2" + ], + "V.47(4)(h)": [ + "IRO-10.2" + ], + "V.47(5)": [ + "IRO-10.2" + ], + "V.47(6)": [ + "IRO-10.2" + ], + "V.47(6)(a)": [ + "IRO-10.2" + ], + "V.47(6)(b)": [ + "IRO-10.2" + ], + "V.47(6)(c)": [ + "IRO-10.2" + ], + "IV.28(3)(a)": [ + "IRO-12" + ], + "IV.28(3)(b)": [ + "IRO-12" + ], + "IV.28(3)(b)(i)": [ + "IRO-12" + ], + "IV.28(3)(b)(ii)": [ + "IRO-12" + ], + "IV.28(3)(b)(iii)": [ + "IRO-12" + ], + "V.51(1)(a)": [ + "IAO-03.2", + "PRI-07.1" + ], + "V.45(2)(a)": [ + "PRI-01" + ], + "V.45(2)(b)": [ + "PRI-01" + ], + "V.45(2)(b)(i)": [ + "PRI-01" + ], + "V.45(2)(b)(ii)": [ + "PRI-01" + ], + "V.45(1)": [ + "PRI-01.4" + ], + "V.45(1)(a)": [ + "PRI-01.4" + ], + "V.45(1)(b)": [ + "PRI-01.4" + ], + "V.45(1)(c)": [ + "PRI-01.4" + ], + "V.45(3)": [ + "PRI-01.4" + ], + "V.45(3)(a)": [ + "PRI-01.4" + ], + "V.45(3)(b)": [ + "PRI-01.4" + ], + "V.45(3)(c)": [ + "PRI-01.4" + ], + "V.45(3)(d)": [ + "PRI-01.4" + ], + "V.45(3)(e)": [ + "PRI-01.4" + ], + "V.45(3)(f)": [ + "PRI-01.4" + ], + "V.45(3)(g)": [ + "PRI-01.4" + ], + "V.45(3)(h)": [ + "PRI-01.4" + ], + "V.45(3)(i)": [ + "PRI-01.4" + ], + "V.45(3)(j)": [ + "PRI-01.4" + ], + "II.5(1)(f)": [ + "PRI-01.6", + "PRI-01.11" + ], + "II.9(2)": [ + "PRI-01.6" + ], + "II.11(1)": [ + "PRI-01.6" + ], + "II.11(1)(a)": [ + "PRI-01.6" + ], + "II.11(1)(b)": [ + "PRI-01.6" + ], + "II.11(2)": [ + "PRI-01.6" + ], + "V.43(4)(d)": [ + "PRI-01.6", + "PRI-01.11" + ], + "V.43(4)(e)": [ + "PRI-01.6", + "PRI-01.11" + ], + "V.52(1)": [ + "PRI-01.6" + ], + "V.52(2)": [ + "PRI-01.6" + ], + "V.52(2)(a)": [ + "PRI-01.6" + ], + "V.52(2)(b)": [ + "PRI-01.6" + ], + "V.52(2)(c)": [ + "PRI-01.6" + ], + "V.52(2)(d)": [ + "PRI-01.6" + ], + "V.52(4)": [ + "PRI-01.6" + ], + "II.5(1)(a)": [ + "PRI-01.11" + ], + "II.5(1)(b)": [ + "PRI-01.11", + "PRI-02.1" + ], + "II.5(1)(c)": [ + "PRI-01.11", + "PRI-04" + ], + "II.5(1)(d)": [ + "PRI-01.11", + "PRI-05.2" + ], + "II.5(1)(e)": [ + "PRI-01.11", + "PRI-05" + ], + "II.5(2)": [ + "PRI-01.11", + "PRI-05.1" + ], + "II.5(3)": [ + "PRI-01.11", + "PRI-05.2" + ], + "II.8(4)": [ + "PRI-01.11" + ], + "II.8(1)": [ + "PRI-02" + ], + "II.8(1)(a)": [ + "PRI-02" + ], + "II.8(1)(b)": [ + "PRI-02" + ], + "II.8(1)(c)": [ + "PRI-02" + ], + "II.8(1)(d)": [ + "PRI-02" + ], + "II.8(1)(e)": [ + "PRI-02" + ], + "II.8(1)(f)": [ + "PRI-02" + ], + "II.8(1)(g)": [ + "PRI-02" + ], + "II.8(1)(g)(i)": [ + "PRI-02" + ], + "II.8(1)(g)(ii)": [ + "PRI-02" + ], + "II.8(1)(g)(iii)": [ + "PRI-02" + ], + "II.8(1)(h)": [ + "PRI-02" + ], + "II.8(1)(i)": [ + "PRI-02" + ], + "II.8(2)": [ + "PRI-02" + ], + "II.8(2)(a)": [ + "PRI-02" + ], + "II.8(2)(b)": [ + "PRI-02" + ], + "IV.24(1)(a)": [ + "PRI-02" + ], + "IV.24(1)(b)": [ + "PRI-02" + ], + "IV.24(1)(b)(i)": [ + "PRI-02" + ], + "IV.24(1)(b)(ii)": [ + "PRI-02" + ], + "IV.24(1)(b)(iii)": [ + "PRI-02" + ], + "IV.24(1)(b)(iv)": [ + "PRI-02" + ], + "IV.24(1)(b)(v)": [ + "PRI-02" + ], + "IV.24(1)(c)": [ + "PRI-02" + ], + "IV.24(1)(c)(i)": [ + "PRI-02" + ], + "IV.24(1)(c)(ii)": [ + "PRI-02" + ], + "IV.24(1)(c)(iii)": [ + "PRI-02" + ], + "IV.24(1)(d)": [ + "PRI-02" + ], + "IV.24(1)(e)": [ + "PRI-02" + ], + "IV.24(1)(f)": [ + "PRI-02" + ], + "IV.24(1)(g)": [ + "PRI-02" + ], + "V.45(8)": [ + "PRI-02" + ], + "V.52(3)": [ + "PRI-02" + ], + "II.7(1)": [ + "PRI-03" + ], + "IV.32(1)": [ + "PRI-03" + ], + "IV.32(2)": [ + "PRI-03" + ], + "IV.32(2)(a)": [ + "PRI-03" + ], + "IV.32(2)(b)": [ + "PRI-03" + ], + "IV.32(2)(c)": [ + "PRI-03" + ], + "IV.32(3)": [ + "PRI-03" + ], + "IV.32(4)": [ + "PRI-03" + ], + "IV.32(5)": [ + "PRI-03" + ], + "IV.32(6)": [ + "PRI-03" + ], + "IV.36(2)": [ + "PRI-03" + ], + "IV.35(1)": [ + "PRI-03.9" + ], + "IV.35(1)(a)": [ + "PRI-03.9" + ], + "IV.35(1)(b)": [ + "PRI-03.9" + ], + "IV.36(1)": [ + "PRI-03.9" + ], + "IV.33(1)": [ + "PRI-03.13" + ], + "IV.33(2)": [ + "PRI-03.13" + ], + "IV.33(3)": [ + "PRI-03.13" + ], + "IV.33(4)": [ + "PRI-03.13" + ], + "IV.33(4)(a)": [ + "PRI-03.13" + ], + "IV.33(4)(b)": [ + "PRI-03.13" + ], + "IV.33(4)(c)": [ + "PRI-03.13" + ], + "IV.35(2)": [ + "PRI-04.1" + ], + "IV.35(2)(a)": [ + "PRI-04.1" + ], + "IV.35(2)(b)": [ + "PRI-04.1" + ], + "IV.36(3)": [ + "PRI-04.1" + ], + "IV.36(3)(a)": [ + "PRI-04.1" + ], + "IV.36(3)(b)": [ + "PRI-04.1" + ], + "IV.36(3)(c)": [ + "PRI-04.1" + ], + "IV.36(3)(c)(i)": [ + "PRI-04.1" + ], + "IV.36(3)(c)(ii)": [ + "PRI-04.1" + ], + "II.9(1)": [ + "PRI-05" + ], + "II.9(1)(a)": [ + "PRI-05" + ], + "II.9(1)(b)": [ + "PRI-05" + ], + "II.9(1)(c)": [ + "PRI-05" + ], + "II.10(1)": [ + "PRI-05.2" + ], + "II.10(2)": [ + "PRI-05.2" + ], + "II.10(2)(a)": [ + "PRI-05.2" + ], + "II.10(2)(b)": [ + "PRI-05.2" + ], + "IV.29(2)": [ + "PRI-05.4" + ], + "IV.29(2)(a)": [ + "PRI-05.4" + ], + "IV.29(2)(b)": [ + "PRI-05.4" + ], + "IV.29(2)(c)": [ + "PRI-05.4" + ], + "IV.29(2)(d)": [ + "PRI-05.4" + ], + "IV.34(1)": [ + "PRI-05.4" + ], + "IV.34(2)": [ + "PRI-05.4" + ], + "IV.34(2)(a)": [ + "PRI-05.4" + ], + "IV.34(2)(b)": [ + "PRI-05.4" + ], + "IV.34(2)(c)": [ + "PRI-05.4" + ], + "IV.34(2)(d)": [ + "PRI-05.4" + ], + "IV.34(2)(e)": [ + "PRI-05.4" + ], + "IV.34(2)(e)(i)": [ + "PRI-05.4" + ], + "IV.34(2)(e)(ii)": [ + "PRI-05.4" + ], + "IV.34(2)(f)": [ + "PRI-05.4" + ], + "IV.34(2)(g)": [ + "PRI-05.4" + ], + "IV.34(2)(h)": [ + "PRI-05.4" + ], + "IV.34(2)(i)": [ + "PRI-05.4" + ], + "IV.34(2)(j)": [ + "PRI-05.4" + ], + "IV.34(2)(k)": [ + "PRI-05.4" + ], + "IV.34(2)(l)": [ + "PRI-05.4" + ], + "IV.34(2)(m)": [ + "PRI-05.4" + ], + "IV.34(2)(n)": [ + "PRI-05.4" + ], + "IV.34(2)(n)(i)": [ + "PRI-05.4" + ], + "IV.34(2)(n)(ii)": [ + "PRI-05.4" + ], + "IV.34(2)(n)(iii)": [ + "PRI-05.4" + ], + "IV.34(2)(n)(iv)": [ + "PRI-05.4" + ], + "IV.34(2)(o)": [ + "PRI-05.4" + ], + "IV.34(2)(o)(a)": [ + "PRI-05.4" + ], + "IV.34(2)(o)(b)": [ + "PRI-05.4" + ], + "IV.34(2)(p)": [ + "PRI-05.4" + ], + "IV.34(2)(p)(i)": [ + "PRI-05.4" + ], + "IV.34(2)(p)(ii)": [ + "PRI-05.4" + ], + "IV.34(2)(p)(ii)(aa)": [ + "PRI-05.4" + ], + "IV.34(2)(p)(ii)(bb)": [ + "PRI-05.4" + ], + "IV.34(2)(p)(ii)(cc)": [ + "PRI-05.4" + ], + "IV.34(2)(p)(ii)(dd)": [ + "PRI-05.4" + ], + "IV.34(2)(p)(ii)(ee)": [ + "PRI-05.4" + ], + "IV.34(2)(p)(iii)": [ + "PRI-05.4" + ], + "IV.34(2)(q)": [ + "PRI-05.4" + ], + "IV.34(2)(q)(i)": [ + "PRI-05.4" + ], + "IV.34(2)(q)(ii)": [ + "PRI-05.4" + ], + "IV.34(2)(q)(iii)": [ + "PRI-05.4" + ], + "IV.34(2)(r)": [ + "PRI-05.4" + ], + "IV.34(2)(s)": [ + "PRI-05.4" + ], + "IV.34(4)": [ + "PRI-05.4" + ], + "IV.34(4)(a)": [ + "PRI-05.4" + ], + "IV.34(4)(b)": [ + "PRI-05.4" + ], + "IV.34(5)": [ + "PRI-05.4" + ], + "IV.34(5)(a)": [ + "PRI-05.4" + ], + "IV.34(5)(b)": [ + "PRI-05.4" + ], + "IV.34(5)(c)": [ + "PRI-05.4" + ], + "IV.34(5)(d)": [ + "PRI-05.4" + ], + "IV.34(6)": [ + "PRI-05.4" + ], + "V.43(4)(b)": [ + "PRI-05.7", + "PRI-14" + ], + "IV.27(1)": [ + "PRI-06" + ], + "IV.29(1)": [ + "PRI-06" + ], + "IV.29(1)(a)": [ + "PRI-06" + ], + "IV.29(1)(b)": [ + "PRI-06" + ], + "IV.29(1)(c)": [ + "PRI-06" + ], + "IV.29(1)(d)": [ + "PRI-06" + ], + "IV.29(1)(e)": [ "PRI-06" ], - "10": [ - "DCH-22.1", + "IV.29(1)(f)": [ + "PRI-06" + ], + "IV.30(1)": [ + "PRI-06" + ], + "IV.30(1)(a)": [ + "PRI-06" + ], + "IV.30(1)(b)": [ + "PRI-06" + ], + "IV.30(2)": [ + "PRI-06" + ], + "IV.30(2)(a)": [ + "PRI-06" + ], + "IV.30(2)(b)": [ + "PRI-06" + ], + "IV.30(3)": [ + "PRI-06" + ], + "IV.26(1)": [ "PRI-06.1" ], - "11": [ - "PRI-06.2", + "IV.26(2)": [ + "PRI-06.1" + ], + "IV.26(3)(a)": [ + "PRI-06.2" + ], + "IV.26(3)(b)": [ + "PRI-06.2" + ], + "IV.24(4)": [ + "PRI-06.4" + ], + "IV.24(4)(a)": [ + "PRI-06.4" + ], + "IV.24(4)(b)": [ + "PRI-06.4" + ], + "IV.24(5)": [ + "PRI-06.4" + ], + "IV.24(5)(a)": [ + "PRI-06.4" + ], + "IV.24(5)(b)": [ + "PRI-06.4" + ], + "IV.24(10)": [ + "PRI-06.4" + ], + "IV.24(10)(a)": [ + "PRI-06.4" + ], + "IV.24(10)(b)": [ + "PRI-06.4" + ], + "IV.24(10)(c)": [ + "PRI-06.4" + ], + "IV.24(10)(d)": [ + "PRI-06.4" + ], + "IV.24(13)(f)": [ + "PRI-06.4" + ], + "IV.27(3)": [ + "PRI-06.4" + ], + "IV.28(5)(a)": [ + "PRI-06.4" + ], + "IV.28(5)(b)": [ + "PRI-06.4" + ], + "IV.29(3)(a)": [ + "PRI-06.4" + ], + "IV.29(3)(b)": [ "PRI-06.4" ], - "12": [ - "PRI-05", - "PRI-05.4", - "SEA-01", - "SEA-02", - "SEA-03" + "IV.28(1)": [ + "PRI-06.5" + ], + "IV.28(2)": [ + "PRI-06.5" + ], + "IV.28(2)(a)": [ + "PRI-06.5" + ], + "IV.28(2)(b)": [ + "PRI-06.5" + ], + "IV.28(2)(c)": [ + "PRI-06.5" + ], + "IV.28(2)(d)": [ + "PRI-06.5" + ], + "IV.28(2)(e)": [ + "PRI-06.5" + ], + "IV.28(4)": [ + "PRI-06.5" + ], + "IV.28(4)(a)": [ + "PRI-06.5" + ], + "IV.28(4)(b)": [ + "PRI-06.5" + ], + "IV.28(4)(c)": [ + "PRI-06.5" + ], + "IV.28(4)(d)": [ + "PRI-06.5" + ], + "IV.28(4)(e)": [ + "PRI-06.5" + ], + "VI.53(1)": [ + "PRI-07" + ], + "VI.54": [ + "PRI-07" + ], + "VI.54(a)": [ + "PRI-07" + ], + "VI.54(b)": [ + "PRI-07" + ], + "VI.54(b)(i)": [ + "PRI-07" + ], + "VI.54(b)(ii)": [ + "PRI-07" + ], + "VI.54(b)(iii)": [ + "PRI-07" + ], + "VI.54(b)(iv)": [ + "PRI-07" + ], + "VI.54(b)(v)": [ + "PRI-07" + ], + "VI.54(b)(vi)": [ + "PRI-07" + ], + "VI.54(c)": [ + "PRI-07" + ], + "V.51(1)(b)": [ + "PRI-07.1" + ], + "V.51(1)(b)(i)": [ + "PRI-07.1" + ], + "V.51(1)(b)(ii)": [ + "PRI-07.1" + ], + "V.51(1)(b)(iii)": [ + "PRI-07.1" + ], + "V.51(1)(b)(iv)": [ + "PRI-07.1" + ], + "V.51(2)(a)": [ + "PRI-07.1" + ], + "V.51(2)(b)": [ + "PRI-07.1" + ], + "V.51(2)(c)": [ + "PRI-07.1" + ], + "V.51(2)(d)": [ + "PRI-07.1" + ], + "V.51(2)(e)": [ + "PRI-07.1" + ], + "V.51(2)(f)": [ + "PRI-07.1" + ], + "V.51(2)(g)": [ + "PRI-07.1" + ], + "V.51(2)(h)": [ + "PRI-07.1" + ], + "V.51(3)": [ + "PRI-07.1" + ], + "V.51(4)": [ + "PRI-07.1" + ], + "V.51(5)": [ + "PRI-07.1" + ], + "V.51(5)(a)": [ + "PRI-07.1" + ], + "V.51(5)(b)": [ + "PRI-07.1" + ], + "V.51(6)": [ + "PRI-07.1" + ], + "V.51(7)": [ + "PRI-07.1" + ], + "V.51(8)": [ + "PRI-07.1" + ], + "V.43(1)": [ + "PRI-14" + ], + "V.43(2)": [ + "PRI-14" + ], + "V.43(2)(a)": [ + "PRI-14" + ], + "V.43(2)(b)": [ + "PRI-14" + ], + "V.43(2)(c)": [ + "PRI-14" + ], + "V.43(2)(d)": [ + "PRI-14" + ], + "V.43(2)(e)": [ + "PRI-14" + ], + "V.43(2)(f)": [ + "PRI-14" + ], + "V.43(2)(g)": [ + "PRI-14" + ], + "V.43(2)(h)": [ + "PRI-14" + ], + "V.43(2)(i)": [ + "PRI-14" + ], + "V.43(2)(j)": [ + "PRI-14" + ], + "V.43(3)": [ + "PRI-14" + ], + "V.43(4)": [ + "PRI-14" + ], + "V.43(4)(a)": [ + "PRI-14" + ], + "V.43(4)(c)": [ + "PRI-14", + "PRI-14.1" + ], + "V.46(3)": [ + "PRI-14.2" + ], + "V.46(3)(a)": [ + "PRI-14.2" + ], + "V.46(3)(b)": [ + "PRI-14.2" + ], + "V.46(3)(c)": [ + "PRI-14.2" + ], + "V.46(3)(d)": [ + "PRI-14.2" + ], + "V.41(1)": [ + "PRI-15" + ], + "V.41(1)(a)": [ + "PRI-15" + ], + "V.41(1)(b)": [ + "PRI-15" + ], + "V.41(1)(c)": [ + "PRI-15" + ], + "V.41(1)(d)": [ + "PRI-15" + ], + "V.41(1)(e)": [ + "PRI-15" + ], + "V.41(1)(f)": [ + "PRI-15" + ], + "V.41(1)(g)": [ + "PRI-15" + ], + "V.41(2)": [ + "PRI-15" + ], + "V.41(3)": [ + "PRI-15" + ], + "IV.24(2)": [ + "PRI-17" + ], + "IV.24(2)(a)": [ + "PRI-17" + ], + "IV.24(2)(b)": [ + "PRI-17" + ], + "IV.36(4)": [ + "PRI-17" + ], + "IV.36(4)(a)": [ + "PRI-17" + ], + "IV.36(4)(b)": [ + "PRI-17" + ], + "IV.24(3)": [ + "PRI-19" + ], + "V.49(1)": [ + "PRI-19" + ], + "V.49(2)": [ + "PRI-19" + ], + "V.49(2)(a)": [ + "PRI-19" + ], + "V.49(2)(b)": [ + "PRI-19" + ], + "V.49(2)(c)": [ + "PRI-19" + ], + "V.49(3)": [ + "PRI-19" + ], + "V.49(4)": [ + "PRI-19" + ], + "V.49(4)(a)": [ + "PRI-19" + ], + "V.49(4)(b)": [ + "PRI-19" + ], + "IV.24(3)(a)": [ + "PRI-19.3" + ], + "IV.24(3)(b)": [ + "PRI-19.3" + ], + "IV.24(3)(c)": [ + "PRI-19.3" + ], + "IV.24(3)(d)": [ + "PRI-19.3" + ], + "V.50(1)": [ + "RSK-10" + ], + "V.50(1)(a)": [ + "RSK-10" + ], + "V.50(1)(b)": [ + "RSK-10" + ], + "V.50(2)": [ + "RSK-10" + ], + "V.50(2)(a)": [ + "RSK-10" + ], + "V.50(2)(b)": [ + "RSK-10" + ], + "V.50(2)(c)": [ + "RSK-10" + ], + "V.50(3)": [ + "RSK-10" + ], + "V.50(3)(a)": [ + "RSK-10" + ], + "V.50(3)(b)": [ + "RSK-10" + ], + "V.50(3)(c)": [ + "RSK-10" + ], + "V.50(3)(d)": [ + "RSK-10" + ], + "V.50(4)": [ + "RSK-10" + ], + "V.50(5)": [ + "RSK-10" + ], + "V.50(6)": [ + "RSK-10" + ], + "V.50(7)": [ + "RSK-10" + ], + "V.50(8)": [ + "RSK-10" + ], + "V.50(8)(a)": [ + "RSK-10" + ], + "V.50(8)(b)": [ + "RSK-10" + ], + "V.50(8)(c)": [ + "RSK-10" + ], + "V.50(8)(d)": [ + "RSK-10" + ], + "V.50(8)(e)": [ + "RSK-10" + ], + "V.50(8)(f)": [ + "RSK-10" ] } } diff --git a/docs/api/crosswalks/americas-bmu-mba-coc-2020.json b/docs/api/crosswalks/americas-bmu-mba-coc-2020.json index 0991a3aa..e141f302 100644 --- a/docs/api/crosswalks/americas-bmu-mba-coc-2020.json +++ b/docs/api/crosswalks/americas-bmu-mba-coc-2020.json @@ -1,348 +1,634 @@ { "framework_id": "americas-bmu-mba-coc-2020", - "display_name": "Bermuda - Bermuda Monetary Authority Code of Conduct (2020)", + "display_name": "Bermuda - Bermuda Monetary Authority (BMA) Insurance Sector Operational Cyber Risk Management Code of Conduct (2020)", "scf_to_framework": { - "total_mappings": 61, + "total_mappings": 97, "mappings": { "GOV-01": [ - "4", - "5.4" + "6.1" ], "GOV-01.1": [ - "5.1", - "5.6" + "5.1" + ], + "GOV-02": [ + "5.3", + "7.1" ], "GOV-04": [ "5.2" ], - "GOV-05": [ - "5.7" + "GOV-10": [ + "5.3-BP2" ], - "AST-01": [ - "5.9" + "GOV-15": [ + "5.3-BP2", + "5.11-BP4" ], "AST-02": [ "5.9" ], + "AST-03": [ + "5.9-BP1", + "5.9-BP2" + ], "BCD-01": [ - "6.14", + "6.3", "7.1" ], + "BCD-01.7": [ + "7.1" + ], + "BCD-04": [ + "7.1-BP2" + ], "BCD-11": [ "6.14" ], + "BCD-11.5": [ + "6.14" + ], "CAP-01": [ - "6.1" + "6.1-BP5" ], "CHG-01": [ - "6.1" + "6.1-BP2" ], "CLD-01": [ "5.11" ], - "CPL-01.1": [ - "5.7" + "CLD-06.1": [ + "5.11" ], - "CPL-02": [ - "5.7" + "CPL-01.2": [ + "5.11-BP3" ], - "CPL-02.1": [ + "CPL-01.4": [ + "5.7-BP3", + "5.11-BP3", + "6.10" + ], + "CPL-02": [ "5.4", - "5.6" + "5.6", + "5.7-BP2" + ], + "CPL-03": [ + "5.7", + "6.21", + "6.22" ], "CPL-03.2": [ - "5.7" + "5.7-BP1" ], "CFG-01": [ - "6.1" + "6.1-BP1" + ], + "CFG-02": [ + "6.15-BP5" ], "MON-01": [ "6.21" ], - "MON-01.16": [ - "6.21" + "MON-01.4": [ + "6.21-BP6" ], - "MON-02": [ - "6.21" - ], - "MON-02.2": [ - "6.21" + "MON-01.8": [ + "6.21-BP5" ], "MON-03": [ - "6.21" + "6.21-BP6" + ], + "MON-03.1": [ + "6.21-BP2" ], "MON-08": [ - "6.21" + "6.21-BP3" + ], + "MON-08.3": [ + "6.21-BP2" + ], + "MON-10": [ + "6.21-BP1" + ], + "MON-16": [ + "6.21-BP4" ], "CRY-01": [ "6.22" ], "DCH-01": [ - "6.8", - "6.10", + "5.3-BP3" + ], + "DCH-01.2": [ "6.13" ], "DCH-02": [ + "5.3-BP2", + "5.9-BP2", "6.8" ], + "DCH-03.1": [ + "5.9-BP3" + ], "DCH-09": [ "6.17" ], - "END-01": [ - "5.12" + "DCH-09.1": [ + "6.17" + ], + "DCH-18": [ + "5.5" ], "END-04": [ "6.12" ], - "HRS-01": [ - "5.13" - ], "HRS-04": [ "5.13" ], + "HRS-11": [ + "6.6" + ], "IAC-01": [ "6.6" ], + "IAC-08": [ + "6.6" + ], + "IAC-15": [ + "6.6" + ], + "IAC-21.3": [ + "6.6" + ], + "IAC-28.1": [ + "6.6" + ], "IRO-01": [ - "6.1", + "5.3-BP3", + "6.1-BP4", "6.3", "6.4" ], + "IRO-02": [ + "6.4" + ], + "IRO-02.4": [ + "6.4" + ], "IRO-04": [ "6.4" ], + "IRO-06": [ + "6.4" + ], + "IRO-07": [ + "6.4" + ], "IRO-10": [ - "6.5" + "6.4" + ], + "IRO-10.5": [ + "6.5", + "6.5(a)", + "6.5(b)", + "6.5(c)", + "6.5(d)", + "6.5(e)" ], "IRO-13": [ "6.4" ], "IAO-01": [ - "5.14" + "6.15" ], "IAO-02": [ - "5.14" + "6.15-BP2" ], "MDM-01": [ "6.11" ], - "NET-01": [ + "NET-02": [ "6.18" ], "NET-02.1": [ "6.19" ], - "RSK-01": [ - "5.3", - "5.8" + "NET-06": [ + "6.18" ], - "RSK-01.1": [ - "5.5" + "NET-08": [ + "6.18" ], - "RSK-02.1": [ - "5.5" + "NET-17": [ + "6.9" + ], + "PRM-04": [ + "5.14" + ], + "PRM-05": [ + "5.14" + ], + "PRM-06": [ + "6.9" + ], + "PRM-07": [ + "6.20" + ], + "RSK-01": [ + "5.3", + "5.11-BP1" ], "RSK-03": [ - "5.5" + "5.3-BP1", + "5.5-BP1" ], "RSK-04": [ - "5.5" + "5.3-BP1", + "5.5", + "5.5-BP2", + "5.11", + "6.19", + "6.19-BP1", + "6.19-BP2", + "6.19-BP3" ], "RSK-04.1": [ - "5.5" - ], - "RSK-05": [ - "5.5" + "5.5-BP4" ], "RSK-06": [ - "5.5" - ], - "RSK-06.1": [ - "5.5" + "5.3-BP1", + "5.5-BP3" ], "RSK-06.2": [ + "5.11-BP4" + ], + "RSK-06.3": [ "5.8" ], - "SEA-01": [ - "4" + "RSK-08": [ + "5.14", + "7.1-BP1" ], - "SEA-02": [ - "4" + "SEA-01": [ + "5.3-BP3" ], - "SEA-03": [ - "4" + "OPS-01.1": [ + "5.9-BP4" ], - "SAT-01": [ + "SAT-02": [ "6.7" ], + "TDA-01": [ + "6.1-BP3" + ], + "TDA-02.10": [ + "5.12" + ], "TDA-06": [ "6.20" ], + "TDA-08": [ + "6.20-BP2", + "6.20-BP3" + ], + "TDA-09": [ + "6.20-BP1" + ], + "TDA-17": [ + "6.16" + ], "TPM-01": [ "5.10" ], - "THR-01": [ - "6.2" + "TPM-04.1": [ + "5.10" ], - "VPM-01": [ - "6.16" + "TPM-05": [ + "5.10", + "5.11-BP2" + ], + "TPM-05.4": [ + "5.10" + ], + "THR-03": [ + "6.2" ], "VPM-05": [ "6.16" ], - "VPM-06": [ - "6.15" + "VPM-06.7": [ + "6.15-BP3" + ], + "VPM-06.8": [ + "6.15-BP4" ], "VPM-07": [ - "6.15" + "6.15-BP1" + ], + "WEB-02": [ + "6.18" ] } }, "framework_to_scf": { - "total_mappings": 37, + "total_mappings": 84, "mappings": { - "4": [ - "GOV-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "5.4": [ - "GOV-01", - "CPL-02.1" + "6.1": [ + "GOV-01" ], "5.1": [ "GOV-01.1" ], - "5.6": [ - "GOV-01.1", - "CPL-02.1" + "5.3": [ + "GOV-02", + "RSK-01" + ], + "7.1": [ + "GOV-02", + "BCD-01", + "BCD-01.7" ], "5.2": [ "GOV-04" ], - "5.7": [ - "GOV-05", - "CPL-01.1", - "CPL-02", - "CPL-03.2" + "5.3-BP2": [ + "GOV-10", + "GOV-15", + "DCH-02" + ], + "5.11-BP4": [ + "GOV-15", + "RSK-06.2" ], "5.9": [ - "AST-01", "AST-02" ], - "6.14": [ - "BCD-01", - "BCD-11" + "5.9-BP1": [ + "AST-03" ], - "7.1": [ - "BCD-01" + "5.9-BP2": [ + "AST-03", + "DCH-02" ], - "6.1": [ - "CAP-01", - "CHG-01", - "CFG-01", + "6.3": [ + "BCD-01", "IRO-01" ], + "7.1-BP2": [ + "BCD-04" + ], + "6.14": [ + "BCD-11", + "BCD-11.5" + ], + "6.1-BP5": [ + "CAP-01" + ], + "6.1-BP2": [ + "CHG-01" + ], "5.11": [ - "CLD-01" + "CLD-01", + "CLD-06.1", + "RSK-04" + ], + "5.11-BP3": [ + "CPL-01.2", + "CPL-01.4" + ], + "5.7-BP3": [ + "CPL-01.4" + ], + "6.10": [ + "CPL-01.4" + ], + "5.4": [ + "CPL-02" + ], + "5.6": [ + "CPL-02" + ], + "5.7-BP2": [ + "CPL-02" + ], + "5.7": [ + "CPL-03" ], "6.21": [ - "MON-01", - "MON-01.16", - "MON-02", - "MON-02.2", - "MON-03", - "MON-08" + "CPL-03", + "MON-01" ], "6.22": [ + "CPL-03", "CRY-01" ], - "6.8": [ - "DCH-01", - "DCH-02" + "5.7-BP1": [ + "CPL-03.2" ], - "6.10": [ - "DCH-01" + "6.1-BP1": [ + "CFG-01" + ], + "6.15-BP5": [ + "CFG-02" + ], + "6.21-BP6": [ + "MON-01.4", + "MON-03" + ], + "6.21-BP5": [ + "MON-01.8" + ], + "6.21-BP2": [ + "MON-03.1", + "MON-08.3" + ], + "6.21-BP3": [ + "MON-08" + ], + "6.21-BP1": [ + "MON-10" + ], + "6.21-BP4": [ + "MON-16" + ], + "5.3-BP3": [ + "DCH-01", + "IRO-01", + "SEA-01" ], "6.13": [ - "DCH-01" + "DCH-01.2" + ], + "6.8": [ + "DCH-02" + ], + "5.9-BP3": [ + "DCH-03.1" ], "6.17": [ - "DCH-09" + "DCH-09", + "DCH-09.1" ], - "5.12": [ - "END-01" + "5.5": [ + "DCH-18", + "RSK-04" ], "6.12": [ "END-04" ], "5.13": [ - "HRS-01", "HRS-04" ], "6.6": [ - "IAC-01" - ], - "6.3": [ + "HRS-11", + "IAC-01", + "IAC-08", + "IAC-15", + "IAC-21.3", + "IAC-28.1" + ], + "6.1-BP4": [ "IRO-01" ], "6.4": [ "IRO-01", + "IRO-02", + "IRO-02.4", "IRO-04", + "IRO-06", + "IRO-07", + "IRO-10", "IRO-13" ], "6.5": [ - "IRO-10" + "IRO-10.5" ], - "5.14": [ - "IAO-01", + "6.5(a)": [ + "IRO-10.5" + ], + "6.5(b)": [ + "IRO-10.5" + ], + "6.5(c)": [ + "IRO-10.5" + ], + "6.5(d)": [ + "IRO-10.5" + ], + "6.5(e)": [ + "IRO-10.5" + ], + "6.15": [ + "IAO-01" + ], + "6.15-BP2": [ "IAO-02" ], "6.11": [ "MDM-01" ], "6.18": [ - "NET-01" + "NET-02", + "NET-06", + "NET-08", + "WEB-02" ], "6.19": [ - "NET-02.1" + "NET-02.1", + "RSK-04" ], - "5.3": [ - "RSK-01" + "6.9": [ + "NET-17", + "PRM-06" ], - "5.8": [ - "RSK-01", - "RSK-06.2" + "5.14": [ + "PRM-04", + "PRM-05", + "RSK-08" ], - "5.5": [ - "RSK-01.1", - "RSK-02.1", + "6.20": [ + "PRM-07", + "TDA-06" + ], + "5.11-BP1": [ + "RSK-01" + ], + "5.3-BP1": [ "RSK-03", "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1" + "RSK-06" + ], + "5.5-BP1": [ + "RSK-03" + ], + "5.5-BP2": [ + "RSK-04" + ], + "6.19-BP1": [ + "RSK-04" + ], + "6.19-BP2": [ + "RSK-04" + ], + "6.19-BP3": [ + "RSK-04" + ], + "5.5-BP4": [ + "RSK-04.1" + ], + "5.5-BP3": [ + "RSK-06" + ], + "5.8": [ + "RSK-06.3" + ], + "7.1-BP1": [ + "RSK-08" + ], + "5.9-BP4": [ + "OPS-01.1" ], "6.7": [ - "SAT-01" + "SAT-02" ], - "6.20": [ - "TDA-06" + "6.1-BP3": [ + "TDA-01" ], - "5.10": [ - "TPM-01" + "5.12": [ + "TDA-02.10" ], - "6.2": [ - "THR-01" + "6.20-BP2": [ + "TDA-08" + ], + "6.20-BP3": [ + "TDA-08" + ], + "6.20-BP1": [ + "TDA-09" ], "6.16": [ - "VPM-01", + "TDA-17", "VPM-05" ], - "6.15": [ - "VPM-06", + "5.10": [ + "TPM-01", + "TPM-04.1", + "TPM-05", + "TPM-05.4" + ], + "5.11-BP2": [ + "TPM-05" + ], + "6.2": [ + "THR-03" + ], + "6.15-BP3": [ + "VPM-06.7" + ], + "6.15-BP4": [ + "VPM-06.8" + ], + "6.15-BP1": [ "VPM-07" ] } diff --git a/docs/api/crosswalks/americas-bra-lgpd-2018.json b/docs/api/crosswalks/americas-bra-lgpd-2018.json index 1c1652af..01b2c7c3 100644 --- a/docs/api/crosswalks/americas-bra-lgpd-2018.json +++ b/docs/api/crosswalks/americas-bra-lgpd-2018.json @@ -2,348 +2,718 @@ "framework_id": "americas-bra-lgpd-2018", "display_name": "Brazil - General Data Protection Law (LGPD) (2018)", "scf_to_framework": { - "total_mappings": 33, + "total_mappings": 29, "mappings": { - "CLD-09": [ - "33", - "34" - ], "CPL-01": [ - "7.1", - "7.2", - "7.3", - "7.4", - "7.5", - "7.6", - "7.7", - "7.8", - "7.9", - "7.10" - ], - "DCH-01": [ - "46", - "47" - ], - "DCH-09.3": [ - "16" - ], - "DCH-22.1": [ - "18.3" - ], - "DCH-23": [ - "12" - ], - "IRO-02": [ - "48" - ], - "IRO-04.1": [ - "48" + "VII.I.46.2" ], "IRO-10": [ - "48" - ], - "PRI-01": [ - "6.8", - "6.10", - "50" - ], - "PRI-01.1": [ - "6.8", - "6.10" + "VII.I.48", + "VII.I.48.1", + "VII.I.48.1.I", + "VII.I.48.1.II", + "VII.I.48.1.III", + "VII.I.48.1.IV", + "VII.I.48.1.V", + "VII.I.48.1.VI" ], "PRI-01.4": [ - "6.8", - "6.10", - "41" + "VI.II.41", + "VI.II.41.1", + "VI.II.41.2", + "VI.II.41.2.I", + "VI.II.41.2.II", + "VI.II.41.2.III", + "VI.II.41.2.IV", + "VI.II.41.3" + ], + "PRI-01.5": [ + "V.33", + "V.33.I", + "V.33.II", + "V.33.II(a)", + "V.33.II(b)", + "V.33.II(c)", + "V.33.II(d)", + "V.33.III", + "V.33.IV", + "V.33.V", + "V.33.VI", + "V.33.VII", + "V.33.VIII", + "V.33.IX", + "V.34", + "V.34.I", + "V.34.II", + "V.34.III", + "V.34.IV", + "V.34.V", + "V.34.VI" + ], + "PRI-01.6": [ + "VII.I.46", + "VII.I.46.1", + "VII.I.47", + "VII.I.49", + "VII.II.50", + "VII.II.50.1", + "VII.II.50.2", + "VII.II.50.2.I", + "VII.II.50.2.I(a)", + "VII.II.50.2.I(b)", + "VII.II.50.2.I(c)", + "VII.II.50.2.I(d)", + "VII.II.50.2.I(e)", + "VII.II.50.2.I(f)", + "VII.II.50.2.I(g)", + "VII.II.50.2.I(h)", + "VII.II.50.2.II" + ], + "PRI-01.11": [ + "II.I.10", + "II.I.10.I", + "II.I.10.II", + "II.I.10.II.1", + "II.I.10.II.2", + "II.II.11.I", + "II.II.11.II", + "II.II.11.II(a)", + "II.II.11.II(b)", + "II.II.11.II(c)", + "II.II.11.II(d)", + "II.II.11.II(e)", + "II.II.11.II(f)", + "II.II.11.II(g)", + "II.II.11.II(g)1", + "II.II.11.II(g)2", + "II.II.11.II(g)3", + "II.II.11.II(g)4", + "III.21" ], "PRI-02": [ - "6.2", - "6.6", - "8" - ], - "PRI-02.1": [ - "6.1", - "6.3" + "II.I.9", + "II.I.9.I", + "II.I.9.II", + "II.I.9.III", + "II.I.9.IV", + "II.I.9.V", + "II.I.9.VI", + "II.I.9.VII", + "II.I.9.VII.1" + ], + "PRI-02.8": [ + "II.IV.15.I" ], "PRI-03": [ - "7.1", - "15" - ], - "PRI-04": [ - "6.2" - ], - "PRI-04.1": [ - "6.1", - "10", - "11" + "II.I.7.I", + "II.I.8", + "II.I.8.1", + "II.I.8.2", + "II.I.8.3", + "II.I.8.4" + ], + "PRI-03.1": [ + "II.I.9.VII.3" + ], + "PRI-03.2": [ + "II.I.8.6", + "II.I.9.VII.2" + ], + "PRI-03.4": [ + "II.I.8.5", + "II.IV.15.III" + ], + "PRI-03.10": [ + "II.IV.15.II", + "II.IV.15.IV" + ], + "PRI-03.13": [ + "II.III.14", + "II.III.14.1", + "II.III.14.2", + "II.III.14.3", + "II.III.14.4", + "II.III.14.5", + "II.III.14.6" ], "PRI-05": [ - "6.2", - "6.9", - "13", - "14", - "15", - "21" + "II.IV.16", + "II.IV.16.I", + "II.IV.16.II", + "II.IV.16.III", + "II.IV.16.IV" + ], + "PRI-05.1": [ + "II.I.7.IV" + ], + "PRI-05.3": [ + "II.II.13", + "II.II.13.1", + "II.II.13.2", + "II.II.13.3", + "II.II.13.4" + ], + "PRI-05.4": [ + "II.I.7.II", + "II.I.7.III", + "II.I.7.V", + "II.I.7.VI", + "II.I.7.VII", + "II.I.7.VIII", + "II.I.7.IX", + "II.I.7.X", + "II.I.7.X.1", + "II.I.7.X.2", + "II.I.7.X.3", + "II.I.7.X.4", + "II.I.7.X.5", + "II.I.7.X.6" ], "PRI-06": [ - "6.4", - "9", - "17", - "18.1", - "18.2", - "20" - ], - "PRI-06.1": [ - "18.3" - ], - "PRI-06.2": [ - "18.9" - ], - "PRI-06.3": [ - "18.9" + "III.18", + "III.18.I", + "III.18.II", + "III.18.III", + "III.18.IV", + "III.18.V", + "III.18.VI", + "III.18.VII", + "III.18.VIII", + "III.18.IX", + "III.18.IX.1", + "III.18.IX.2", + "III.18.IX.3", + "III.18.IX.4" ], "PRI-06.4": [ - "18", - "19", - "21" - ], - "PRI-06.5": [ - "18.4", - "18.6" + "III.18.IX.4.I", + "III.18.IX.4.II", + "III.18.IX.5" ], "PRI-06.6": [ - "18.5", - "40" + "III.18.IX.7", + "III.19", + "III.19.II", + "III.19.II.1", + "III.19.II.2", + "III.19.II.2.I", + "III.19.II.2.II", + "III.19.II.3" + ], + "PRI-06.7": [ + "III.19.I" + ], + "PRI-07": [ + "V.33" ], "PRI-07.1": [ - "35", - "39" + "VI.I.39" ], - "PRI-10": [ - "6.5" + "PRI-07.3": [ + "III.18.IX.6" ], "PRI-14": [ - "38" - ], - "PRI-14.1": [ - "18.7", - "37" - ], - "PRM-04": [ - "6.8" - ], - "SEA-01": [ - "6.7", - "46", - "37", - "49" - ], - "SEA-02": [ - "6.7", - "46", - "37", - "49" - ], - "SEA-03": [ - "6.7", - "46", - "37", - "49" + "VI.I.37" + ], + "PRI-19": [ + "III.20" + ], + "PRI-19.3": [ + "III.20", + "III.20.1" + ], + "RSK-10": [ + "II.I.10.II.3" ] } }, "framework_to_scf": { - "total_mappings": 55, + "total_mappings": 161, "mappings": { - "8": [ - "PRI-02" + "VII.I.46.2": [ + "CPL-01" ], - "9": [ - "PRI-06" + "VII.I.48": [ + "IRO-10" ], - "10": [ - "PRI-04.1" + "VII.I.48.1": [ + "IRO-10" ], - "11": [ - "PRI-04.1" + "VII.I.48.1.I": [ + "IRO-10" ], - "12": [ - "DCH-23" + "VII.I.48.1.II": [ + "IRO-10" ], - "13": [ - "PRI-05" + "VII.I.48.1.III": [ + "IRO-10" ], - "14": [ - "PRI-05" + "VII.I.48.1.IV": [ + "IRO-10" ], - "15": [ - "PRI-03", - "PRI-05" + "VII.I.48.1.V": [ + "IRO-10" ], - "16": [ - "DCH-09.3" + "VII.I.48.1.VI": [ + "IRO-10" ], - "17": [ - "PRI-06" + "VI.II.41": [ + "PRI-01.4" ], - "18": [ - "PRI-06.4" + "VI.II.41.1": [ + "PRI-01.4" ], - "19": [ - "PRI-06.4" + "VI.II.41.2": [ + "PRI-01.4" ], - "20": [ - "PRI-06" + "VI.II.41.2.I": [ + "PRI-01.4" ], - "21": [ - "PRI-05", - "PRI-06.4" + "VI.II.41.2.II": [ + "PRI-01.4" ], - "33": [ - "CLD-09" + "VI.II.41.2.III": [ + "PRI-01.4" ], - "34": [ - "CLD-09" + "VI.II.41.2.IV": [ + "PRI-01.4" ], - "35": [ - "PRI-07.1" + "VI.II.41.3": [ + "PRI-01.4" ], - "37": [ - "PRI-14.1", - "SEA-01", - "SEA-02", - "SEA-03" + "V.33": [ + "PRI-01.5", + "PRI-07" ], - "38": [ - "PRI-14" + "V.33.I": [ + "PRI-01.5" ], - "39": [ - "PRI-07.1" + "V.33.II": [ + "PRI-01.5" ], - "40": [ - "PRI-06.6" + "V.33.II(a)": [ + "PRI-01.5" ], - "41": [ - "PRI-01.4" + "V.33.II(b)": [ + "PRI-01.5" ], - "46": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "V.33.II(c)": [ + "PRI-01.5" ], - "47": [ - "DCH-01" + "V.33.II(d)": [ + "PRI-01.5" ], - "48": [ - "IRO-02", - "IRO-04.1", - "IRO-10" + "V.33.III": [ + "PRI-01.5" + ], + "V.33.IV": [ + "PRI-01.5" + ], + "V.33.V": [ + "PRI-01.5" + ], + "V.33.VI": [ + "PRI-01.5" + ], + "V.33.VII": [ + "PRI-01.5" + ], + "V.33.VIII": [ + "PRI-01.5" + ], + "V.33.IX": [ + "PRI-01.5" + ], + "V.34": [ + "PRI-01.5" + ], + "V.34.I": [ + "PRI-01.5" + ], + "V.34.II": [ + "PRI-01.5" + ], + "V.34.III": [ + "PRI-01.5" + ], + "V.34.IV": [ + "PRI-01.5" + ], + "V.34.V": [ + "PRI-01.5" + ], + "V.34.VI": [ + "PRI-01.5" + ], + "VII.I.46": [ + "PRI-01.6" + ], + "VII.I.46.1": [ + "PRI-01.6" + ], + "VII.I.47": [ + "PRI-01.6" + ], + "VII.I.49": [ + "PRI-01.6" + ], + "VII.II.50": [ + "PRI-01.6" + ], + "VII.II.50.1": [ + "PRI-01.6" + ], + "VII.II.50.2": [ + "PRI-01.6" + ], + "VII.II.50.2.I": [ + "PRI-01.6" + ], + "VII.II.50.2.I(a)": [ + "PRI-01.6" + ], + "VII.II.50.2.I(b)": [ + "PRI-01.6" + ], + "VII.II.50.2.I(c)": [ + "PRI-01.6" + ], + "VII.II.50.2.I(d)": [ + "PRI-01.6" + ], + "VII.II.50.2.I(e)": [ + "PRI-01.6" ], - "49": [ - "SEA-01", - "SEA-02", - "SEA-03" + "VII.II.50.2.I(f)": [ + "PRI-01.6" ], - "50": [ - "PRI-01" + "VII.II.50.2.I(g)": [ + "PRI-01.6" ], - "7.1": [ - "CPL-01", + "VII.II.50.2.I(h)": [ + "PRI-01.6" + ], + "VII.II.50.2.II": [ + "PRI-01.6" + ], + "II.I.10": [ + "PRI-01.11" + ], + "II.I.10.I": [ + "PRI-01.11" + ], + "II.I.10.II": [ + "PRI-01.11" + ], + "II.I.10.II.1": [ + "PRI-01.11" + ], + "II.I.10.II.2": [ + "PRI-01.11" + ], + "II.II.11.I": [ + "PRI-01.11" + ], + "II.II.11.II": [ + "PRI-01.11" + ], + "II.II.11.II(a)": [ + "PRI-01.11" + ], + "II.II.11.II(b)": [ + "PRI-01.11" + ], + "II.II.11.II(c)": [ + "PRI-01.11" + ], + "II.II.11.II(d)": [ + "PRI-01.11" + ], + "II.II.11.II(e)": [ + "PRI-01.11" + ], + "II.II.11.II(f)": [ + "PRI-01.11" + ], + "II.II.11.II(g)": [ + "PRI-01.11" + ], + "II.II.11.II(g)1": [ + "PRI-01.11" + ], + "II.II.11.II(g)2": [ + "PRI-01.11" + ], + "II.II.11.II(g)3": [ + "PRI-01.11" + ], + "II.II.11.II(g)4": [ + "PRI-01.11" + ], + "III.21": [ + "PRI-01.11" + ], + "II.I.9": [ + "PRI-02" + ], + "II.I.9.I": [ + "PRI-02" + ], + "II.I.9.II": [ + "PRI-02" + ], + "II.I.9.III": [ + "PRI-02" + ], + "II.I.9.IV": [ + "PRI-02" + ], + "II.I.9.V": [ + "PRI-02" + ], + "II.I.9.VI": [ + "PRI-02" + ], + "II.I.9.VII": [ + "PRI-02" + ], + "II.I.9.VII.1": [ + "PRI-02" + ], + "II.IV.15.I": [ + "PRI-02.8" + ], + "II.I.7.I": [ "PRI-03" ], - "7.2": [ - "CPL-01" + "II.I.8": [ + "PRI-03" ], - "7.3": [ - "CPL-01" + "II.I.8.1": [ + "PRI-03" ], - "7.4": [ - "CPL-01" + "II.I.8.2": [ + "PRI-03" ], - "7.5": [ - "CPL-01" + "II.I.8.3": [ + "PRI-03" ], - "7.6": [ - "CPL-01" + "II.I.8.4": [ + "PRI-03" ], - "7.7": [ - "CPL-01" + "II.I.9.VII.3": [ + "PRI-03.1" ], - "7.8": [ - "CPL-01" + "II.I.8.6": [ + "PRI-03.2" ], - "7.9": [ - "CPL-01" + "II.I.9.VII.2": [ + "PRI-03.2" ], - "7.10": [ - "CPL-01" + "II.I.8.5": [ + "PRI-03.4" ], - "18.3": [ - "DCH-22.1", - "PRI-06.1" + "II.IV.15.III": [ + "PRI-03.4" ], - "6.8": [ - "PRI-01", - "PRI-01.1", - "PRI-01.4", - "PRM-04" + "II.IV.15.II": [ + "PRI-03.10" ], - "6.10": [ - "PRI-01", - "PRI-01.1", - "PRI-01.4" + "II.IV.15.IV": [ + "PRI-03.10" + ], + "II.III.14": [ + "PRI-03.13" + ], + "II.III.14.1": [ + "PRI-03.13" + ], + "II.III.14.2": [ + "PRI-03.13" + ], + "II.III.14.3": [ + "PRI-03.13" + ], + "II.III.14.4": [ + "PRI-03.13" ], - "6.2": [ - "PRI-02", - "PRI-04", + "II.III.14.5": [ + "PRI-03.13" + ], + "II.III.14.6": [ + "PRI-03.13" + ], + "II.IV.16": [ "PRI-05" ], - "6.6": [ - "PRI-02" + "II.IV.16.I": [ + "PRI-05" ], - "6.1": [ - "PRI-02.1", - "PRI-04.1" + "II.IV.16.II": [ + "PRI-05" ], - "6.3": [ - "PRI-02.1" + "II.IV.16.III": [ + "PRI-05" ], - "6.9": [ + "II.IV.16.IV": [ "PRI-05" ], - "6.4": [ + "II.I.7.IV": [ + "PRI-05.1" + ], + "II.II.13": [ + "PRI-05.3" + ], + "II.II.13.1": [ + "PRI-05.3" + ], + "II.II.13.2": [ + "PRI-05.3" + ], + "II.II.13.3": [ + "PRI-05.3" + ], + "II.II.13.4": [ + "PRI-05.3" + ], + "II.I.7.II": [ + "PRI-05.4" + ], + "II.I.7.III": [ + "PRI-05.4" + ], + "II.I.7.V": [ + "PRI-05.4" + ], + "II.I.7.VI": [ + "PRI-05.4" + ], + "II.I.7.VII": [ + "PRI-05.4" + ], + "II.I.7.VIII": [ + "PRI-05.4" + ], + "II.I.7.IX": [ + "PRI-05.4" + ], + "II.I.7.X": [ + "PRI-05.4" + ], + "II.I.7.X.1": [ + "PRI-05.4" + ], + "II.I.7.X.2": [ + "PRI-05.4" + ], + "II.I.7.X.3": [ + "PRI-05.4" + ], + "II.I.7.X.4": [ + "PRI-05.4" + ], + "II.I.7.X.5": [ + "PRI-05.4" + ], + "II.I.7.X.6": [ + "PRI-05.4" + ], + "III.18": [ + "PRI-06" + ], + "III.18.I": [ + "PRI-06" + ], + "III.18.II": [ + "PRI-06" + ], + "III.18.III": [ + "PRI-06" + ], + "III.18.IV": [ + "PRI-06" + ], + "III.18.V": [ + "PRI-06" + ], + "III.18.VI": [ + "PRI-06" + ], + "III.18.VII": [ + "PRI-06" + ], + "III.18.VIII": [ + "PRI-06" + ], + "III.18.IX": [ + "PRI-06" + ], + "III.18.IX.1": [ + "PRI-06" + ], + "III.18.IX.2": [ "PRI-06" ], - "18.1": [ + "III.18.IX.3": [ "PRI-06" ], - "18.2": [ + "III.18.IX.4": [ "PRI-06" ], - "18.9": [ - "PRI-06.2", - "PRI-06.3" + "III.18.IX.4.I": [ + "PRI-06.4" + ], + "III.18.IX.4.II": [ + "PRI-06.4" + ], + "III.18.IX.5": [ + "PRI-06.4" + ], + "III.18.IX.7": [ + "PRI-06.6" + ], + "III.19": [ + "PRI-06.6" + ], + "III.19.II": [ + "PRI-06.6" + ], + "III.19.II.1": [ + "PRI-06.6" ], - "18.4": [ - "PRI-06.5" + "III.19.II.2": [ + "PRI-06.6" ], - "18.6": [ - "PRI-06.5" + "III.19.II.2.I": [ + "PRI-06.6" + ], + "III.19.II.2.II": [ + "PRI-06.6" ], - "18.5": [ + "III.19.II.3": [ "PRI-06.6" ], - "6.5": [ - "PRI-10" + "III.19.I": [ + "PRI-06.7" + ], + "VI.I.39": [ + "PRI-07.1" + ], + "III.18.IX.6": [ + "PRI-07.3" + ], + "VI.I.37": [ + "PRI-14" + ], + "III.20": [ + "PRI-19", + "PRI-19.3" ], - "18.7": [ - "PRI-14.1" + "III.20.1": [ + "PRI-19.3" ], - "6.7": [ - "SEA-01", - "SEA-02", - "SEA-03" + "II.I.10.II.3": [ + "RSK-10" ] } } diff --git a/docs/api/crosswalks/americas-can-itsp-10-171-2025.json b/docs/api/crosswalks/americas-can-itsp-10-171-2025.json index be895dcb..8d5e3aee 100644 --- a/docs/api/crosswalks/americas-can-itsp-10-171-2025.json +++ b/docs/api/crosswalks/americas-can-itsp-10-171-2025.json @@ -1,8 +1,8 @@ { "framework_id": "americas-can-itsp-10-171-2025", - "display_name": "Canada - ITSP.10.171 (2025)", + "display_name": "Canada - Protecting controlled information in non - Government of Canada systems and organizations (ITSP.10.171) (2025)", "scf_to_framework": { - "total_mappings": 407, + "total_mappings": 415, "mappings": { "GOV-01": [ "03.15.01.A" @@ -25,6 +25,7 @@ ], "GOV-15": [ "03.15.01.A", + "03.16.01", "03.17.01.A" ], "GOV-15.1": [ @@ -56,6 +57,9 @@ "AST-01.1": [ "03.01.03" ], + "AST-01.4": [ + "03.04.08.C" + ], "AST-02": [ "03.04.08.A", "03.04.08.C", @@ -79,8 +83,7 @@ "AST-02.9": [ "03.04.08.A", "03.04.10.A", - "03.04.10.B", - "03.04.10.C" + "03.04.10.B" ], "AST-03": [ "03.09.02.A.03" @@ -154,17 +157,21 @@ ], "CHG-01": [ "03.04.02.B", - "03.04.03.A" + "03.04.03.A", + "03.04.03.D" ], "CHG-02": [ "03.04.02.B", "03.04.03.A", "03.04.03.B", - "03.04.03.C" + "03.04.03.C", + "03.07.05.A" ], "CHG-02.1": [ "03.04.02.B", - "03.04.03.A" + "03.04.03.A", + "03.04.03.B", + "03.07.05.A" ], "CHG-02.2": [ "03.04.03.B", @@ -198,7 +205,8 @@ "03.12.01" ], "CPL-01.1": [ - "03.12.02.A.01" + "03.12.02.A.01", + "03.12.02.A.02" ], "CPL-01.2": [ "03.04.11.A", @@ -216,14 +224,17 @@ "03.12.03" ], "CPL-03.2": [ + "03.04.02.B", "03.04.08.C", "03.12.03" ], "CFG-01": [ - "03.04.01.A" + "03.04.01.A", + "03.04.03.A" ], "CFG-02": [ "03.01.01.H", + "03.01.03", "03.01.08.A", "03.01.08.B", "03.01.09", @@ -233,34 +244,41 @@ "03.01.11", "03.01.12.A", "03.01.16.A", + "03.01.16.C", "03.01.18.A", + "03.03.08.A", "03.04.01.A", "03.04.02.A", + "03.04.02.B", "03.04.06.A", "03.04.06.B", "03.04.06.D", + "03.05.04", + "03.05.07.C", "03.05.07.D", "03.05.07.E", "03.05.07.F", "03.05.12.D", + "03.07.05.B", "03.08.07.A", "03.13.12.B" ], "CFG-02.1": [ "03.04.01.B", - "03.04.02.B" + "03.04.06.C" ], "CFG-02.2": [ "03.04.02.B", - "03.04.03.D" + "03.04.03.D", + "03.13.13.B" ], "CFG-02.5": [ "03.04.01.A", "03.04.02.A", "03.04.06.A", - "03.04.06.B", "03.04.06.D", - "03.04.12.A" + "03.04.12.A", + "03.14.08.C" ], "CFG-02.7": [ "03.04.01.A", @@ -316,7 +334,8 @@ "MON-01": [ "03.03.01.A", "03.12.03", - "03.14.06.A" + "03.14.06.A", + "03.14.06.A.02" ], "MON-01.1": [ "03.13.01.A" @@ -333,7 +352,6 @@ "03.14.06.C" ], "MON-01.8": [ - "03.03.01.B", "03.03.05.A" ], "MON-01.12": [ @@ -352,13 +370,15 @@ "03.03.05.C" ], "MON-02.2": [ - "03.03.01.B", "03.03.05.A", "03.03.05.C" ], "MON-02.3": [ "03.03.05.C" ], + "MON-02.6": [ + "03.03.01.B" + ], "MON-02.7": [ "03.03.01.A" ], @@ -379,6 +399,9 @@ "MON-03.3": [ "03.01.07.B" ], + "MON-03.6": [ + "03.03.01.B" + ], "MON-05": [ "03.03.04.B" ], @@ -396,7 +419,8 @@ "MON-08": [ "03.03.03.B", "03.03.06.B", - "03.03.08.A" + "03.03.08.A", + "03.03.08.B" ], "MON-08.1": [ "03.03.08.A" @@ -439,10 +463,12 @@ "03.13.11" ], "CRY-03": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "CRY-05": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "CRY-05.1": [ "03.13.08" @@ -531,7 +557,8 @@ ], "DCH-07": [ "03.08.05.A", - "03.08.05.B" + "03.08.05.B", + "03.08.05.C" ], "DCH-07.1": [ "03.08.05.A", @@ -605,6 +632,7 @@ ], "DCH-18": [ "03.01.20.C.02", + "03.10.07.B", "03.14.08" ], "DCH-19": [ @@ -614,7 +642,11 @@ "DCH-21": [ "03.08.03" ], + "DCH-24": [ + "03.04.11.A" + ], "END-01": [ + "03.01.03", "03.14.02.A" ], "END-04": [ @@ -661,16 +693,19 @@ "03.01.01.D.02", "03.01.02", "03.09.01.A", - "03.09.01.B" + "03.09.01.B", + "03.15.03.B" ], "HRS-02.1": [ "03.01.02" ], "HRS-03": [ "03.01.22.A", + "03.02.02.A.01", "03.06.04.A", "03.06.05.D", "03.07.06.A", + "03.07.06.D", "03.08.02", "03.15.03.B", "03.16.03.B" @@ -683,7 +718,9 @@ "03.07.06.D" ], "HRS-04": [ - "03.09.01.A" + "03.09.01.A", + "03.09.01.B", + "03.09.02.B.01" ], "HRS-04.1": [ "03.01.22.A", @@ -701,13 +738,15 @@ "HRS-05": [ "03.01.01.H", "03.01.22.A", - "03.15.03.A" + "03.15.03.A", + "03.15.03.B" ], "HRS-05.1": [ "03.01.12.A", "03.01.18.A", "03.01.22.A", - "03.15.03.A" + "03.15.03.A", + "03.15.03.D" ], "HRS-05.2": [ "03.15.03.A" @@ -726,14 +765,12 @@ "03.15.03.A" ], "HRS-05.7": [ - "03.15.03.B", "03.15.03.C", "03.15.03.D" ], "HRS-06": [ "03.01.18.A", "03.12.05.A", - "03.15.03.B", "03.15.03.C" ], "HRS-06.1": [ @@ -751,12 +788,14 @@ "HRS-08": [ "03.01.01.G.02", "03.09.02.A", - "03.09.02.B.01" + "03.09.02.B.01", + "03.09.02.B.02" ], "HRS-09": [ "03.01.01.F.03", "03.01.01.G.02", "03.09.02.A", + "03.09.02.A.02", "03.09.02.A.03", "03.09.02.B.01" ], @@ -790,6 +829,8 @@ "03.05.12.E" ], "IAC-01.2": [ + "03.01.01.D.01", + "03.01.16.B", "03.05.01.A", "03.05.02", "03.05.05.D", @@ -799,11 +840,11 @@ "03.05.07.D", "03.05.07.E", "03.05.12.D", - "03.05.12.F", "03.07.05.A" ], "IAC-02": [ - "03.05.01.A" + "03.05.01.A", + "03.05.05.D" ], "IAC-02.2": [ "03.05.04", @@ -836,7 +877,11 @@ "IAC-06.3": [ "03.05.03" ], + "IAC-06.4": [ + "03.05.03" + ], "IAC-07": [ + "03.01.01.B", "03.01.01.G.01", "03.01.01.G.02", "03.01.01.G.03", @@ -901,10 +946,8 @@ "03.05.07.E", "03.05.07.F", "03.05.12.B", - "03.05.12.C", "03.05.12.D", - "03.05.12.E", - "03.05.12.F" + "03.05.12.E" ], "IAC-10.3": [ "03.05.12.A" @@ -947,6 +990,7 @@ "03.01.01.D.02", "03.01.01.E", "03.01.01.F.01", + "03.01.01.F.02", "03.01.01.F.03", "03.01.01.F.04", "03.01.01.F.05", @@ -956,9 +1000,11 @@ "03.01.02", "03.01.05.B", "03.01.05.C", - "03.01.05.D" + "03.01.05.D", + "03.05.07.E" ], "IAC-15.1": [ + "03.01.01.D.01", "03.05.05.B", "03.05.05.C", "03.05.05.D", @@ -981,6 +1027,7 @@ "03.01.01.F.05" ], "IAC-15.7": [ + "03.01.01.B", "03.01.01.E", "03.01.05.C" ], @@ -1016,13 +1063,20 @@ "03.01.03", "03.01.04.B", "03.01.05.A", + "03.01.05.B", "03.06.05.D", "03.10.01.A" ], + "IAC-20.4": [ + "03.01.06.C", + "03.14.08.A", + "03.14.08.C" + ], "IAC-21": [ "03.01.01.C.03", "03.01.01.D.01", "03.01.01.D.02", + "03.01.02", "03.01.04.B", "03.01.05.A", "03.01.05.B", @@ -1057,12 +1111,12 @@ "03.01.10.C" ], "IAC-25": [ + "03.01.01.H", "03.01.11", "03.07.05.C" ], "IAC-28": [ - "03.05.12.A", - "03.05.12.C" + "03.05.12.A" ], "IAC-28.1": [ "03.01.01.B", @@ -1077,7 +1131,8 @@ "03.06.02.A", "03.06.02.B", "03.06.02.C", - "03.06.02.D" + "03.06.02.D", + "03.06.05.B" ], "IRO-04": [ "03.06.01", @@ -1088,10 +1143,10 @@ "03.06.05.A.04", "03.06.05.A.05", "03.06.05.A.06", - "03.06.05.B" + "03.06.05.B", + "03.06.05.D" ], "IRO-04.2": [ - "03.06.04.B", "03.06.05.C" ], "IRO-04.3": [ @@ -1104,13 +1159,18 @@ "IRO-06": [ "03.06.03" ], + "IRO-07": [ + "03.06.02.B", + "03.06.02.D" + ], "IRO-09": [ "03.06.02.A", "03.06.02.B" ], "IRO-10": [ "03.06.02.B", - "03.06.02.C" + "03.06.02.C", + "03.06.02.D" ], "IRO-10.2": [ "03.06.02.B", @@ -1120,6 +1180,7 @@ "03.06.02.D" ], "IRO-12": [ + "03.01.22.B", "03.06.01" ], "IRO-13": [ @@ -1138,6 +1199,8 @@ "03.12.01" ], "IAO-03": [ + "03.01.16.A", + "03.04.11.A", "03.04.11.B", "03.15.02.A", "03.15.02.A.01", @@ -1211,12 +1274,10 @@ "03.07.06.D" ], "MNT-06.1": [ - "03.07.06.A", "03.07.06.C", "03.07.06.D" ], "MNT-06.2": [ - "03.07.06.A", "03.07.06.C" ], "MNT-09": [ @@ -1251,9 +1312,9 @@ "NET-01": [ "03.01.12.A", "03.01.16.A", - "03.01.16.B", "03.01.18.A", - "03.13.01.A" + "03.13.01.A", + "03.14.08.B" ], "NET-02": [ "03.13.01.B" @@ -1264,6 +1325,7 @@ ], "NET-03": [ "03.01.12.A", + "03.01.18.A", "03.13.01.A", "03.13.01.B", "03.13.01.C" @@ -1288,7 +1350,6 @@ ], "NET-05.2": [ "03.01.03", - "03.12.05.A", "03.12.05.B", "03.12.05.C" ], @@ -1299,6 +1360,7 @@ "03.13.01.B" ], "NET-07": [ + "03.07.05.C", "03.13.09" ], "NET-08": [ @@ -1315,7 +1377,7 @@ "03.01.12.A", "03.01.12.B", "03.01.12.C", - "03.01.12.D" + "03.14.08.B" ], "NET-14.1": [ "03.01.12.B" @@ -1324,7 +1386,6 @@ "03.01.12.A" ], "NET-14.3": [ - "03.01.12.B", "03.01.12.C" ], "NET-14.4": [ @@ -1332,7 +1393,6 @@ ], "NET-14.5": [ "03.01.12.A", - "03.01.12.C", "03.10.06.A", "03.10.06.B" ], @@ -1359,24 +1419,29 @@ "03.08.01", "03.08.02", "03.10.01.A", - "03.10.07.A" + "03.10.07.A", + "03.10.07.A.01" ], "PES-02": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.A", "03.10.01.B", "03.10.01.C", "03.10.01.D", - "03.10.07.A" + "03.10.07.A", + "03.10.07.A.01" ], "PES-02.1": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.B", "03.10.01.D" ], "PES-03": [ + "03.04.05", "03.10.02.A", "03.10.07.A", "03.10.07.A.01", @@ -1386,10 +1451,12 @@ "PES-03.1": [ "03.10.02.A", "03.10.07.A", + "03.10.07.A.01", "03.10.07.A.02" ], "PES-03.3": [ "03.10.02.A", + "03.10.07.A.02", "03.10.07.B" ], "PES-03.4": [ @@ -1415,19 +1482,18 @@ "03.10.02.B" ], "PES-05.1": [ - "03.10.02.A", - "03.10.02.B" + "03.10.02.A" ], "PES-05.2": [ "03.10.02.A", "03.10.02.B" ], "PES-06": [ - "03.10.02.B", + "03.10.01.A", "03.10.07.C" ], "PES-06.1": [ - "03.10.02.B", + "03.10.01.A", "03.10.07.C" ], "PES-06.2": [ @@ -1464,7 +1530,8 @@ ], "RSK-01": [ "03.11.01.A", - "03.17.01.A" + "03.17.01.A", + "03.17.03.B" ], "RSK-01.1": [ "03.11.01.A" @@ -1480,6 +1547,7 @@ "03.11.01.A" ], "RSK-03.1": [ + "03.11.01.A", "03.15.02.A.03" ], "RSK-04": [ @@ -1521,7 +1589,6 @@ "SEA-01": [ "03.01.12.A", "03.01.16.A", - "03.01.16.B", "03.01.16.C", "03.01.18.A", "03.13.01.C", @@ -1561,17 +1628,22 @@ "03.15.01.A" ], "OPS-03": [ - "03.15.01.B" + "03.15.01.A" ], "SAT-01": [ "03.02.01.A" ], + "SAT-01.1": [ + "03.02.01.B", + "03.02.02.A.02", + "03.02.02.B", + "03.06.04.B" + ], "SAT-02": [ "03.01.22.A", "03.02.01.A.01", "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", "03.06.04.A.03" ], "SAT-02.2": [ @@ -1584,11 +1656,10 @@ "03.02.02.A", "03.02.02.A.01", "03.02.02.A.02", - "03.02.02.B", "03.06.04.A", "03.06.04.A.01", "03.06.04.A.02", - "03.06.04.B" + "03.06.04.A.03" ], "SAT-03.3": [ "03.01.22.A", @@ -1603,15 +1674,10 @@ "03.02.01.A.01", "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", "03.02.02.A.01", "03.02.02.A.02", - "03.02.02.B", "03.06.04.A.02" ], - "SAT-03.7": [ - "03.06.04.B" - ], "TDA-01": [ "03.12.01", "03.12.03", @@ -1660,10 +1726,12 @@ "03.01.20.C.01", "03.07.06.A", "03.16.01", - "03.16.03.A" + "03.16.03.A", + "03.17.02" ], "TPM-01.1": [ - "03.07.06.A" + "03.07.06.A", + "03.07.06.B" ], "TPM-02": [ "03.11.01.A", @@ -1728,6 +1796,7 @@ ], "TPM-05.4": [ "03.07.06.A", + "03.07.06.B", "03.16.03.B" ], "TPM-05.5": [ @@ -1765,13 +1834,12 @@ ], "THR-01": [ "03.11.02.A", + "03.14.01.A", "03.14.03.A" ], "THR-03": [ "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", - "03.02.02.B", "03.11.02.A", "03.14.03.A" ], @@ -1781,6 +1849,9 @@ "THR-05": [ "03.02.01.A.03" ], + "THR-06": [ + "03.14.01.A" + ], "THR-09": [ "03.15.02.A.03" ], @@ -1805,8 +1876,7 @@ ], "VPM-04": [ "03.11.02.B", - "03.14.01.A", - "03.14.01.B" + "03.14.01.A" ], "VPM-05": [ "03.11.02.B", @@ -1815,7 +1885,8 @@ "03.14.01.B" ], "VPM-06": [ - "03.11.02.A" + "03.11.02.A", + "03.14.01.A" ], "VPM-06.1": [ "03.11.02.C" @@ -1829,7 +1900,7 @@ } }, "framework_to_scf": { - "total_mappings": 275, + "total_mappings": 279, "mappings": { "03.15.01.A": [ "GOV-01", @@ -1841,7 +1912,8 @@ "GOV-15.4", "GOV-15.5", "OPS-01", - "OPS-01.1" + "OPS-01.1", + "OPS-03" ], "03.12.03": [ "GOV-01.1", @@ -1858,14 +1930,31 @@ ], "03.15.01.B": [ "GOV-03", - "OPS-01", - "OPS-03" + "OPS-01" ], "03.15.03.D": [ "GOV-03", "HRS-01", + "HRS-05.1", "HRS-05.7" ], + "03.16.01": [ + "GOV-15", + "AST-17", + "PRM-01", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-01", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-03", + "TDA-05", + "TDA-06", + "TPM-01", + "TPM-10" + ], "03.17.01.A": [ "GOV-15", "GOV-15.1", @@ -1885,9 +1974,11 @@ "AST-04", "AST-04.3", "AST-31", + "CFG-02", "DCH-01.4", "DCH-03", "DCH-14.3", + "END-01", "IAC-20", "IAC-20.1", "NET-04", @@ -1910,6 +2001,7 @@ "MDM-06", "MDM-07", "NET-01", + "NET-03", "SEA-01", "SEA-02" ], @@ -1924,7 +2016,9 @@ "CPL-01.2", "DCH-02", "DCH-06.2", - "DCH-19" + "DCH-19", + "DCH-24", + "IAO-03" ], "03.07.04.A": [ "AST-01", @@ -1936,6 +2030,12 @@ "MNT-04", "MNT-09" ], + "03.04.08.C": [ + "AST-01.4", + "AST-02", + "CPL-03.2", + "CFG-03.1" + ], "03.04.08.A": [ "AST-02", "AST-02.9", @@ -1943,11 +2043,6 @@ "CFG-03", "CFG-03.3" ], - "03.04.08.C": [ - "AST-02", - "CPL-03.2", - "CFG-03.1" - ], "03.04.10.A": [ "AST-02", "AST-02.1", @@ -1959,8 +2054,7 @@ "AST-02.9" ], "03.04.10.C": [ - "AST-02.1", - "AST-02.9" + "AST-02.1" ], "03.04.02.B": [ "AST-02.4", @@ -1968,7 +2062,8 @@ "CHG-02", "CHG-02.1", "CHG-04", - "CFG-02.1", + "CPL-03.2", + "CFG-02", "CFG-02.2", "CFG-02.7", "CFG-02.9", @@ -2024,6 +2119,7 @@ "RSK-02", "RSK-02.1", "RSK-03", + "RSK-03.1", "RSK-04", "RSK-05", "RSK-09", @@ -2032,22 +2128,6 @@ "TPM-03", "TPM-04.1" ], - "03.16.01": [ - "AST-17", - "PRM-01", - "PRM-05", - "SEA-01", - "SEA-02", - "TDA-01", - "TDA-02", - "TDA-02.3", - "TDA-02.4", - "TDA-03", - "TDA-05", - "TDA-06", - "TPM-01", - "TPM-10" - ], "03.04.12.A": [ "AST-24", "CFG-02.5", @@ -2075,8 +2155,7 @@ "03.01.12.C": [ "AST-27", "NET-14", - "NET-14.3", - "NET-14.5" + "NET-14.3" ], "03.08.09.A": [ "BCD-11", @@ -2089,10 +2168,16 @@ "CHG-01", "CHG-02", "CHG-02.1", + "CFG-01", "CFG-06" ], + "03.04.03.D": [ + "CHG-01", + "CFG-02.2" + ], "03.04.03.B": [ "CHG-02", + "CHG-02.1", "CHG-02.2", "CHG-03" ], @@ -2102,6 +2187,16 @@ "MNT-01", "MNT-02" ], + "03.07.05.A": [ + "CHG-02", + "CHG-02.1", + "IAC-01.2", + "IAC-05.2", + "MNT-02", + "MNT-05", + "MNT-05.1", + "MNT-05.5" + ], "03.04.04.A": [ "CHG-02.2", "CHG-02.3", @@ -2111,7 +2206,10 @@ "CHG-04", "CHG-04.4", "IAC-08", - "IAC-21" + "IAC-21", + "PES-02", + "PES-02.1", + "PES-03" ], "03.04.04.B": [ "CHG-06" @@ -2132,6 +2230,14 @@ "IAO-05", "RSK-04.1" ], + "03.12.02.A.02": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1", + "RSK-06", + "VPM-02", + "VPM-05" + ], "03.04.01.A": [ "CFG-01", "CFG-02", @@ -2142,7 +2248,8 @@ "03.01.01.H": [ "CFG-02", "HRS-05", - "HRS-05.3" + "HRS-05.3", + "IAC-25" ], "03.01.08.A": [ "CFG-02", @@ -2177,6 +2284,7 @@ "03.01.16.A": [ "CFG-02", "CRY-07", + "IAO-03", "NET-01", "NET-02.2", "NET-15", @@ -2185,23 +2293,48 @@ "SEA-01", "SEA-02" ], - "03.04.02.A": [ + "03.01.16.C": [ "CFG-02", - "CFG-02.5", - "CFG-02.9", - "CFG-03", - "CFG-06" + "NET-15.2", + "NET-15.3", + "SEA-01" ], - "03.04.06.B": [ + "03.03.08.A": [ "CFG-02", - "CFG-02.5", - "CFG-03" + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-08.3", + "IAC-21" + ], + "03.04.02.A": [ + "CFG-02", + "CFG-02.5", + "CFG-02.9", + "CFG-03", + "CFG-06" + ], + "03.04.06.B": [ + "CFG-02", + "CFG-03" ], "03.04.06.D": [ "CFG-02", "CFG-02.5", "CFG-03" ], + "03.05.04": [ + "CFG-02", + "IAC-02.2" + ], + "03.05.07.C": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.11", + "IAC-15.1" + ], "03.05.07.D": [ "CFG-02", "IAC-01.2", @@ -2217,6 +2350,7 @@ "IAC-10", "IAC-10.1", "IAC-10.8", + "IAC-15", "IAC-15.1" ], "03.05.07.F": [ @@ -2234,6 +2368,13 @@ "IAC-10.8", "IAC-15.1" ], + "03.07.05.B": [ + "CFG-02", + "IAC-02.2", + "IAC-06", + "MNT-05", + "MNT-05.3" + ], "03.08.07.A": [ "CFG-02", "DCH-10", @@ -2246,8 +2387,21 @@ "03.04.01.B": [ "CFG-02.1" ], - "03.04.03.D": [ - "CFG-02.2" + "03.04.06.C": [ + "CFG-02.1", + "CFG-03.1" + ], + "03.13.13.B": [ + "CFG-02.2", + "CFG-03.3", + "CFG-04", + "CFG-04.1", + "CFG-05", + "END-10" + ], + "03.14.08.C": [ + "CFG-02.5", + "IAC-20.4" ], "03.03.02.B": [ "CFG-02.9", @@ -2256,10 +2410,9 @@ "03.13.11": [ "CFG-02.9", "CRY-01", - "CRY-01.5" - ], - "03.04.06.C": [ - "CFG-03.1" + "CRY-01.5", + "CRY-03", + "CRY-05" ], "03.04.08.B": [ "CFG-03.2", @@ -2269,13 +2422,6 @@ "CFG-03.3", "END-10" ], - "03.13.13.B": [ - "CFG-03.3", - "CFG-04", - "CFG-04.1", - "CFG-05", - "END-10" - ], "03.01.02": [ "CFG-08", "DCH-01.2", @@ -2285,7 +2431,8 @@ "IAC-08", "IAC-15", "IAC-20", - "IAC-20.1" + "IAC-20.1", + "IAC-21" ], "03.03.01.A": [ "MON-01", @@ -2297,6 +2444,12 @@ "03.14.06.A": [ "MON-01" ], + "03.14.06.A.02": [ + "MON-01", + "MON-11.3", + "MON-16", + "END-07" + ], "03.13.01.A": [ "MON-01.1", "MON-01.3", @@ -2330,10 +2483,6 @@ "MON-16", "END-07" ], - "03.03.01.B": [ - "MON-01.8", - "MON-02.2" - ], "03.03.05.A": [ "MON-01.8", "MON-02", @@ -2361,6 +2510,10 @@ "MON-02.2", "MON-02.3" ], + "03.03.01.B": [ + "MON-02.6", + "MON-03.6" + ], "03.03.02.A": [ "MON-03" ], @@ -2403,14 +2556,8 @@ "03.03.06.B": [ "MON-08" ], - "03.03.08.A": [ - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-08.3", - "IAC-21" - ], "03.03.08.B": [ + "MON-08", "MON-08.2", "IAC-08", "IAC-21" @@ -2418,13 +2565,9 @@ "03.01.22.B": [ "MON-11", "DCH-15", + "IRO-12", "WEB-14" ], - "03.14.06.A.02": [ - "MON-11.3", - "MON-16", - "END-07" - ], "03.01.01.E": [ "MON-16", "IAC-15", @@ -2447,7 +2590,9 @@ "DCH-01", "DCH-01.2", "HRS-02", + "IAC-01.2", "IAC-15", + "IAC-15.1", "IAC-20", "IAC-20.1", "IAC-21" @@ -2529,7 +2674,8 @@ "DCH-01.2", "HRS-03", "IAC-08", - "IAC-20.1" + "IAC-20.1", + "IRO-04" ], "03.08.02": [ "DCH-01.2", @@ -2548,7 +2694,8 @@ "DCH-03.1" ], "03.08.05.C": [ - "DCH-01.3" + "DCH-01.3", + "DCH-07" ], "03.01.04.B": [ "DCH-01.4", @@ -2560,7 +2707,9 @@ "DCH-01.4", "IAC-20.1", "PES-01", - "PES-02" + "PES-02", + "PES-06", + "PES-06.1" ], "03.15.02.C": [ "DCH-01.4", @@ -2605,8 +2754,11 @@ "DCH-14.3", "HRS-06", "HRS-06.1", - "NET-05", - "NET-05.2" + "NET-05" + ], + "03.10.07.B": [ + "DCH-18", + "PES-03.3" ], "03.14.08": [ "DCH-18" @@ -2669,8 +2821,25 @@ ], "03.09.01.B": [ "HRS-02", + "HRS-04", "HRS-04.1" ], + "03.15.03.B": [ + "HRS-02", + "HRS-03", + "HRS-03.1", + "HRS-04.2", + "HRS-05" + ], + "03.02.02.A.01": [ + "HRS-03", + "HRS-04.1", + "HRS-04.2", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" + ], "03.06.04.A": [ "HRS-03", "HRS-04.2", @@ -2682,19 +2851,16 @@ "IAC-08", "MNT-01", "MNT-06", - "MNT-06.1", - "MNT-06.2", "TPM-01", "TPM-01.1", "TPM-05", "TPM-05.4" ], - "03.15.03.B": [ + "03.07.06.D": [ "HRS-03", - "HRS-03.1", - "HRS-04.2", - "HRS-05.7", - "HRS-06" + "HRS-03.2", + "MNT-06", + "MNT-06.1" ], "03.16.03.B": [ "HRS-03", @@ -2703,18 +2869,11 @@ "TPM-05.2", "TPM-05.4" ], - "03.07.06.D": [ - "HRS-03.2", - "MNT-06", - "MNT-06.1" - ], - "03.02.02.A.01": [ - "HRS-04.1", - "HRS-04.2", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6" + "03.09.02.B.01": [ + "HRS-04", + "HRS-08", + "HRS-09", + "HRS-09.2" ], "03.06.04.A.01": [ "HRS-04.2", @@ -2741,22 +2900,23 @@ "HRS-08", "HRS-09" ], - "03.09.02.B.01": [ + "03.09.02.B.02": [ "HRS-08", - "HRS-09", - "HRS-09.2" + "IAC-07.1", + "IAC-20" ], "03.01.01.F.03": [ "HRS-09", "IAC-15" ], - "03.09.02.A.01": [ + "03.09.02.A.02": [ + "HRS-09", "HRS-09.2", "HRS-09.4", "IAC-07", "IAC-07.2" ], - "03.09.02.A.02": [ + "03.09.02.A.01": [ "HRS-09.2", "HRS-09.4", "IAC-07", @@ -2797,6 +2957,12 @@ "IAC-10.1", "IAC-15.1" ], + "03.01.16.B": [ + "IAC-01.2", + "NET-02.2", + "NET-15", + "NET-15.1" + ], "03.05.02": [ "IAC-01.2", "IAC-04", @@ -2804,6 +2970,7 @@ ], "03.05.05.D": [ "IAC-01.2", + "IAC-02", "IAC-09", "IAC-09.2", "IAC-09.5", @@ -2821,42 +2988,18 @@ "IAC-10.4", "IAC-10.11" ], - "03.05.07.C": [ - "IAC-01.2", - "IAC-10", - "IAC-10.5", - "IAC-10.11", - "IAC-15.1" - ], - "03.05.12.F": [ - "IAC-01.2", - "IAC-10", - "IAC-10.1", - "IAC-10.5", - "IAC-15.1" - ], - "03.07.05.A": [ - "IAC-01.2", - "IAC-05.2", - "MNT-02", - "MNT-05", - "MNT-05.1", - "MNT-05.5" - ], - "03.05.04": [ - "IAC-02.2" - ], - "03.07.05.B": [ - "IAC-02.2", - "IAC-06", - "MNT-05", - "MNT-05.3" - ], "03.05.03": [ "IAC-06", "IAC-06.1", "IAC-06.2", - "IAC-06.3" + "IAC-06.3", + "IAC-06.4" + ], + "03.01.01.B": [ + "IAC-07", + "IAC-15", + "IAC-15.7", + "IAC-28.1" ], "03.01.01.G.01": [ "IAC-07", @@ -2869,10 +3012,6 @@ "IAC-15", "IAC-17" ], - "03.09.02.B.02": [ - "IAC-07.1", - "IAC-20" - ], "03.01.01.C.03": [ "IAC-08", "IAC-20", @@ -2883,6 +3022,7 @@ "IAC-08", "IAC-15", "IAC-20", + "IAC-20.1", "IAC-21" ], "03.01.06.A": [ @@ -2911,9 +3051,12 @@ "IAC-10.1" ], "03.05.12.C": [ + "IAC-10" + ], + "03.05.12.F": [ "IAC-10", - "IAC-10.1", - "IAC-28" + "IAC-10.5", + "IAC-15.1" ], "03.05.11": [ "IAC-11" @@ -2921,13 +3064,13 @@ "03.05.01.B": [ "IAC-14" ], - "03.01.01.B": [ - "IAC-15", - "IAC-28.1" - ], "03.01.01.F.01": [ "IAC-15" ], + "03.01.01.F.02": [ + "IAC-15", + "IAC-15.3" + ], "03.01.05.C": [ "IAC-15", "IAC-15.7", @@ -2937,9 +3080,6 @@ "IAC-15", "IAC-17" ], - "03.01.01.F.02": [ - "IAC-15.3" - ], "03.01.07.A": [ "IAC-16", "IAC-21", @@ -2960,13 +3100,20 @@ "IAC-20.1", "IAC-21" ], + "03.01.06.C": [ + "IAC-20.4" + ], + "03.14.08.A": [ + "IAC-20.4" + ], "03.01.06.B": [ "IAC-21.2" ], "03.07.05.C": [ "IAC-25", "MNT-05", - "MNT-05.4" + "MNT-05.4", + "NET-07" ], "03.06.01": [ "IRO-01", @@ -2980,6 +3127,7 @@ ], "03.06.02.B": [ "IRO-02", + "IRO-07", "IRO-09", "IRO-10", "IRO-10.2" @@ -2992,8 +3140,14 @@ ], "03.06.02.D": [ "IRO-02", + "IRO-07", + "IRO-10", "IRO-11" ], + "03.06.05.B": [ + "IRO-02", + "IRO-04" + ], "03.06.05.A": [ "IRO-04" ], @@ -3015,22 +3169,18 @@ "03.06.05.A.06": [ "IRO-04" ], - "03.06.05.B": [ - "IRO-04" + "03.06.05.C": [ + "IRO-04.2" ], "03.06.04.B": [ - "IRO-04.2", "IRO-04.3", "IRO-13", - "SAT-03", - "SAT-03.7" - ], - "03.06.05.C": [ - "IRO-04.2" + "SAT-01.1" ], "03.06.04.A.03": [ "IRO-05", - "SAT-02" + "SAT-02", + "SAT-03" ], "03.06.03": [ "IRO-06" @@ -3067,13 +3217,6 @@ "03.12.02.A": [ "IAO-05" ], - "03.12.02.A.02": [ - "IAO-05", - "RSK-04.1", - "RSK-06", - "VPM-02", - "VPM-05" - ], "03.12.02.B": [ "IAO-05" ], @@ -3090,22 +3233,26 @@ "IAO-05", "TDA-01", "TDA-09", + "THR-01", + "THR-06", "VPM-01", "VPM-01.1", "VPM-02", "VPM-04", - "VPM-05" + "VPM-05", + "VPM-06" ], "03.07.04.B": [ "MNT-04.1" ], "03.01.12.D": [ "MNT-05", - "NET-14", "NET-14.4" ], "03.07.06.B": [ - "MNT-06" + "MNT-06", + "TPM-01.1", + "TPM-05.4" ], "03.07.06.C": [ "MNT-06", @@ -3115,12 +3262,9 @@ "03.01.18.C": [ "MDM-03" ], - "03.01.16.B": [ + "03.14.08.B": [ "NET-01", - "NET-02.2", - "NET-15", - "NET-15.1", - "SEA-01" + "NET-14" ], "03.13.01.B": [ "NET-02", @@ -3154,8 +3298,7 @@ ], "03.01.12.B": [ "NET-14", - "NET-14.1", - "NET-14.3" + "NET-14.1" ], "03.10.06.A": [ "NET-14.5", @@ -3168,17 +3311,21 @@ "03.01.16.D": [ "NET-15.1" ], - "03.01.16.C": [ - "NET-15.2", - "NET-15.3", - "SEA-01" - ], "03.10.07.A": [ "PES-01", "PES-02", "PES-03", "PES-03.1" ], + "03.10.07.A.01": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1", + "PES-03.4", + "PES-04", + "PES-04.1" + ], "03.10.01.B": [ "PES-02", "PES-02.1" @@ -3191,15 +3338,10 @@ "PES-05.1", "PES-05.2" ], - "03.10.07.A.01": [ - "PES-03", - "PES-03.4", - "PES-04", - "PES-04.1" - ], "03.10.07.A.02": [ "PES-03", "PES-03.1", + "PES-03.3", "PES-03.4", "PES-04", "PES-04.1" @@ -3209,15 +3351,9 @@ "PES-04", "PES-04.1" ], - "03.10.07.B": [ - "PES-03.3" - ], "03.10.02.B": [ "PES-05", - "PES-05.1", - "PES-05.2", - "PES-06", - "PES-06.1" + "PES-05.2" ], "03.10.07.C": [ "PES-06", @@ -3235,6 +3371,20 @@ "PES-12", "PES-12.2" ], + "03.17.03.B": [ + "RSK-01", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7" + ], "03.14.03.B": [ "RSK-02.1", "THR-03.1", @@ -3270,19 +3420,6 @@ "TPM-04.1", "TPM-05.5" ], - "03.17.03.B": [ - "RSK-09", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-05.2", - "TPM-05.5", - "TPM-05.7" - ], "03.13.04": [ "SEA-05" ], @@ -3298,6 +3435,17 @@ "03.02.01.A": [ "SAT-01" ], + "03.02.01.B": [ + "SAT-01.1" + ], + "03.02.02.A.02": [ + "SAT-01.1", + "SAT-03", + "SAT-03.6" + ], + "03.02.02.B": [ + "SAT-01.1" + ], "03.02.01.A.01": [ "SAT-02", "SAT-03", @@ -3318,29 +3466,16 @@ "THR-03", "THR-05" ], - "03.02.01.B": [ - "SAT-02", - "SAT-03.6", - "THR-03" - ], "03.02.02.A": [ "SAT-03" ], - "03.02.02.A.02": [ - "SAT-03", - "SAT-03.6" - ], - "03.02.02.B": [ - "SAT-03", - "SAT-03.6", - "THR-03" - ], "03.06.04.A.02": [ "SAT-03", "SAT-03.6" ], "03.17.02": [ "TDA-01", + "TPM-01", "TPM-03.1", "TPM-04", "TPM-04.1", @@ -3383,7 +3518,6 @@ "THR-03" ], "03.14.01.B": [ - "VPM-04", "VPM-05" ], "03.11.02.C": [ diff --git a/docs/api/crosswalks/americas-can-osfi-b13-2022.json b/docs/api/crosswalks/americas-can-osfi-b13-2022.json index 3f5cdb2a..c6bc8295 100644 --- a/docs/api/crosswalks/americas-can-osfi-b13-2022.json +++ b/docs/api/crosswalks/americas-can-osfi-b13-2022.json @@ -1,6 +1,6 @@ { "framework_id": "americas-can-osfi-b13-2022", - "display_name": "Canada - OSFI B-13 (2022)", + "display_name": "Canada - OSFI B - 13 (2022)", "scf_to_framework": { "total_mappings": 150, "mappings": { diff --git a/docs/api/crosswalks/americas-can-osfi-self-assessment-2.json b/docs/api/crosswalks/americas-can-osfi-self-assessment-2.json new file mode 100644 index 00000000..cedf7f6a --- /dev/null +++ b/docs/api/crosswalks/americas-can-osfi-self-assessment-2.json @@ -0,0 +1,700 @@ +{ + "framework_id": "americas-can-osfi-self-assessment-2", + "display_name": "Canada - OSFI Cyber Security Self - Assessment Guidance", + "scf_to_framework": { + "total_mappings": 125, + "mappings": { + "GOV-01": [ + "1.2.1" + ], + "GOV-01.1": [ + "1.3.2" + ], + "GOV-02": [ + "1.3.2", + "2.2.1" + ], + "GOV-04": [ + "1.1.1", + "1.1.2" + ], + "GOV-04.1": [ + "1.1.2" + ], + "GOV-04.2": [ + "1.1.2" + ], + "GOV-05.2": [ + "1.2.1" + ], + "GOV-07": [ + "3.1.5" + ], + "GOV-14": [ + "1.1.2" + ], + "GOV-15": [ + "3.2.1" + ], + "GOV-15.1": [ + "3.2.1" + ], + "GOV-15.2": [ + "3.2.1" + ], + "GOV-15.3": [ + "3.2.1" + ], + "GOV-15.4": [ + "3.2.1" + ], + "GOV-15.5": [ + "3.2.1" + ], + "GOV-16": [ + "2.9.3" + ], + "AST-01.1": [ + "2.2.2", + "2.9.1" + ], + "AST-02": [ + "2.2.2" + ], + "AST-02.4": [ + "2.2.3" + ], + "AST-02.9": [ + "2.2.2", + "2.2.3" + ], + "AST-09": [ + "2.2.4" + ], + "BCD-01": [ + "2.9.1" + ], + "BCD-01.7": [ + "2.9.1" + ], + "BCD-02": [ + "2.9.1" + ], + "BCD-04": [ + "2.9.3" + ], + "BCD-11": [ + "2.9.1" + ], + "CAP-01": [ + "2.8.2" + ], + "CAP-04": [ + "2.8.2" + ], + "CHG-01": [ + "2.5.1" + ], + "CHG-02": [ + "2.5.1" + ], + "CHG-02.1": [ + "2.5.1", + "2.5.3" + ], + "CHG-02.2": [ + "2.5.1" + ], + "CHG-04.1": [ + "2.5.3" + ], + "CHG-07": [ + "2.5.1" + ], + "CFG-02": [ + "3.2.8" + ], + "CFG-02.7": [ + "3.2.8" + ], + "MON-01": [ + "3.3.1" + ], + "MON-01.2": [ + "3.3.1" + ], + "MON-01.4": [ + "3.2.7" + ], + "MON-01.8": [ + "3.3.3" + ], + "MON-02": [ + "3.3.1", + "3.3.2" + ], + "MON-10": [ + "3.3.1" + ], + "MON-11.3": [ + "3.3.2" + ], + "MON-16": [ + "3.3.2" + ], + "CRY-01": [ + "3.2.2" + ], + "CRY-09": [ + "2.9.2", + "3.2.2" + ], + "DCH-01": [ + "3.1.4" + ], + "DCH-02": [ + "3.1.4", + "3.2.5" + ], + "DCH-06.3": [ + "3.1.4" + ], + "END-06.8": [ + "3.3.2" + ], + "HRS-03": [ + "2.7.2" + ], + "HRS-04": [ + "3.2.7" + ], + "HRS-11": [ + "2.5.2" + ], + "IAC-01": [ + "3.2.7" + ], + "IAC-01.2": [ + "3.2.7" + ], + "IAC-06": [ + "3.2.7" + ], + "IAC-16": [ + "3.2.7" + ], + "IRO-01": [ + "2.7.1", + "3.4.3" + ], + "IRO-02": [ + "2.7.1", + "2.7.2", + "2.7.3", + "3", + "3.4.1" + ], + "IRO-02.4": [ + "2.7.2", + "3.4.2" + ], + "IRO-03": [ + "2.7.2" + ], + "IRO-06": [ + "2.7.2" + ], + "IRO-06.1": [ + "2.7.2" + ], + "IRO-07": [ + "3.4.4" + ], + "IRO-08": [ + "3.4.5" + ], + "IRO-13": [ + "2.7.3" + ], + "IAO-02": [ + "2.4.4" + ], + "IAO-04": [ + "2.4.4" + ], + "NET-01": [ + "3.2.4" + ], + "NET-02": [ + "3.2.4" + ], + "NET-04": [ + "3.2.4" + ], + "NET-08": [ + "3.2.4" + ], + "PES-01": [ + "3.2.10" + ], + "PES-01.1": [ + "3.2.10" + ], + "PES-02": [ + "3.2.10" + ], + "PES-02.1": [ + "3.2.10" + ], + "PRM-01": [ + "2.3.1" + ], + "PRM-01.1": [ + "1.2.1" + ], + "PRM-02.1": [ + "1.3.2" + ], + "PRM-04": [ + "2.3.1" + ], + "PRM-05": [ + "1.2.1" + ], + "PRM-06": [ + "1.2.1" + ], + "PRM-07": [ + "2.4.1" + ], + "RSK-01": [ + "1.3.1", + "1.3.2", + "3.1.8" + ], + "RSK-01.1": [ + "1.3.2", + "3.1.8" + ], + "RSK-01.3": [ + "1.3.2", + "3.1.8" + ], + "RSK-01.4": [ + "1.3.2", + "3.1.8" + ], + "RSK-01.5": [ + "1.3.2", + "3.1.8" + ], + "RSK-04.2": [ + "1.3.2", + "3.1.3" + ], + "RSK-06": [ + "3.2.3" + ], + "RSK-06.2": [ + "3.2.3", + "3.2.6" + ], + "RSK-06.4": [ + "1.3.2", + "3.2.3" + ], + "SEA-01": [ + "2.1.1", + "2.1.2", + "3.2.1" + ], + "SEA-02": [ + "2.1.1", + "2.1.2" + ], + "SEA-07.1": [ + "2.2.5" + ], + "OPS-01.1": [ + "2.7.2" + ], + "OPS-03": [ + "2.8.1" + ], + "OPS-06": [ + "3.3.2" + ], + "SAT-01": [ + "3.1.7" + ], + "SAT-01.1": [ + "3.1.7" + ], + "SAT-02": [ + "3.1.7" + ], + "SAT-02.1": [ + "3.1.7" + ], + "TDA-01": [ + "2.4.3", + "2.4.4" + ], + "TDA-01.1": [ + "2.4.3" + ], + "TDA-01.4": [ + "2.4.3" + ], + "TDA-02.3": [ + "2.4.3", + "2.4.5" + ], + "TDA-06": [ + "2.4.2", + "2.4.5" + ], + "TDA-06.2": [ + "3.1.6" + ], + "TDA-09": [ + "3.2.9" + ], + "TDA-09.3": [ + "3.2.9" + ], + "TDA-17": [ + "2.2.5" + ], + "TPM-05": [ + "2.8.1" + ], + "THR-01": [ + "3.1.1", + "3.1.5" + ], + "THR-03": [ + "3.1.1", + "3.1.5" + ], + "THR-03.1": [ + "3.1.1", + "3.1.5" + ], + "THR-09": [ + "3.1.2", + "3.1.6" + ], + "THR-10": [ + "3.1.2", + "3.1.6" + ], + "VPM-01": [ + "2.6.1", + "3.2.6" + ], + "VPM-02": [ + "3.2.6" + ], + "VPM-04": [ + "2.6.1" + ], + "VPM-04.1": [ + "2.6.1" + ], + "VPM-04.3": [ + "2.6.1" + ], + "VPM-05": [ + "2.6.1", + "3.2.6" + ], + "VPM-05.1": [ + "3.2.6" + ], + "VPM-06": [ + "3.1.3" + ] + } + }, + "framework_to_scf": { + "total_mappings": 57, + "mappings": { + "3": [ + "IRO-02" + ], + "1.2.1": [ + "GOV-01", + "GOV-05.2", + "PRM-01.1", + "PRM-05", + "PRM-06" + ], + "1.3.2": [ + "GOV-01.1", + "GOV-02", + "PRM-02.1", + "RSK-01", + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5", + "RSK-04.2", + "RSK-06.4" + ], + "2.2.1": [ + "GOV-02" + ], + "1.1.1": [ + "GOV-04" + ], + "1.1.2": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "GOV-14" + ], + "3.1.5": [ + "GOV-07", + "THR-01", + "THR-03", + "THR-03.1" + ], + "3.2.1": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "SEA-01" + ], + "2.9.3": [ + "GOV-16", + "BCD-04" + ], + "2.2.2": [ + "AST-01.1", + "AST-02", + "AST-02.9" + ], + "2.9.1": [ + "AST-01.1", + "BCD-01", + "BCD-01.7", + "BCD-02", + "BCD-11" + ], + "2.2.3": [ + "AST-02.4", + "AST-02.9" + ], + "2.2.4": [ + "AST-09" + ], + "2.8.2": [ + "CAP-01", + "CAP-04" + ], + "2.5.1": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-02.2", + "CHG-07" + ], + "2.5.3": [ + "CHG-02.1", + "CHG-04.1" + ], + "3.2.8": [ + "CFG-02", + "CFG-02.7" + ], + "3.3.1": [ + "MON-01", + "MON-01.2", + "MON-02", + "MON-10" + ], + "3.2.7": [ + "MON-01.4", + "HRS-04", + "IAC-01", + "IAC-01.2", + "IAC-06", + "IAC-16" + ], + "3.3.3": [ + "MON-01.8" + ], + "3.3.2": [ + "MON-02", + "MON-11.3", + "MON-16", + "END-06.8", + "OPS-06" + ], + "3.2.2": [ + "CRY-01", + "CRY-09" + ], + "2.9.2": [ + "CRY-09" + ], + "3.1.4": [ + "DCH-01", + "DCH-02", + "DCH-06.3" + ], + "3.2.5": [ + "DCH-02" + ], + "2.7.2": [ + "HRS-03", + "IRO-02", + "IRO-02.4", + "IRO-03", + "IRO-06", + "IRO-06.1", + "OPS-01.1" + ], + "2.5.2": [ + "HRS-11" + ], + "2.7.1": [ + "IRO-01", + "IRO-02" + ], + "3.4.3": [ + "IRO-01" + ], + "2.7.3": [ + "IRO-02", + "IRO-13" + ], + "3.4.1": [ + "IRO-02" + ], + "3.4.2": [ + "IRO-02.4" + ], + "3.4.4": [ + "IRO-07" + ], + "3.4.5": [ + "IRO-08" + ], + "2.4.4": [ + "IAO-02", + "IAO-04", + "TDA-01" + ], + "3.2.4": [ + "NET-01", + "NET-02", + "NET-04", + "NET-08" + ], + "3.2.10": [ + "PES-01", + "PES-01.1", + "PES-02", + "PES-02.1" + ], + "2.3.1": [ + "PRM-01", + "PRM-04" + ], + "2.4.1": [ + "PRM-07" + ], + "1.3.1": [ + "RSK-01" + ], + "3.1.8": [ + "RSK-01", + "RSK-01.1", + "RSK-01.3", + "RSK-01.4", + "RSK-01.5" + ], + "3.1.3": [ + "RSK-04.2", + "VPM-06" + ], + "3.2.3": [ + "RSK-06", + "RSK-06.2", + "RSK-06.4" + ], + "3.2.6": [ + "RSK-06.2", + "VPM-01", + "VPM-02", + "VPM-05", + "VPM-05.1" + ], + "2.1.1": [ + "SEA-01", + "SEA-02" + ], + "2.1.2": [ + "SEA-01", + "SEA-02" + ], + "2.2.5": [ + "SEA-07.1", + "TDA-17" + ], + "2.8.1": [ + "OPS-03", + "TPM-05" + ], + "3.1.7": [ + "SAT-01", + "SAT-01.1", + "SAT-02", + "SAT-02.1" + ], + "2.4.3": [ + "TDA-01", + "TDA-01.1", + "TDA-01.4", + "TDA-02.3" + ], + "2.4.5": [ + "TDA-02.3", + "TDA-06" + ], + "2.4.2": [ + "TDA-06" + ], + "3.1.6": [ + "TDA-06.2", + "THR-09", + "THR-10" + ], + "3.2.9": [ + "TDA-09", + "TDA-09.3" + ], + "3.1.1": [ + "THR-01", + "THR-03", + "THR-03.1" + ], + "3.1.2": [ + "THR-09", + "THR-10" + ], + "2.6.1": [ + "VPM-01", + "VPM-04", + "VPM-04.1", + "VPM-04.3", + "VPM-05" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/americas-can-osfi-self-assessment.json b/docs/api/crosswalks/americas-can-osfi-self-assessment.json new file mode 100644 index 00000000..438d663e --- /dev/null +++ b/docs/api/crosswalks/americas-can-osfi-self-assessment.json @@ -0,0 +1,12 @@ +{ + "framework_id": "americas-can-osfi-self-assessment", + "display_name": "Canada - Office of the Superintendent of Financial Institutions Canada (OSFI) - Cyber Security Self - Assessment Guidance", + "scf_to_framework": { + "total_mappings": 0, + "mappings": {} + }, + "framework_to_scf": { + "total_mappings": 0, + "mappings": {} + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/americas-can-pipeda-2000.json b/docs/api/crosswalks/americas-can-pipeda-2000.json index ce3a530f..a56fc1d0 100644 --- a/docs/api/crosswalks/americas-can-pipeda-2000.json +++ b/docs/api/crosswalks/americas-can-pipeda-2000.json @@ -2,186 +2,380 @@ "framework_id": "americas-can-pipeda-2000", "display_name": "Canada - Personal Information Protection and Electronic Documents Act (PIPEDA) (2000)", "scf_to_framework": { - "total_mappings": 28, + "total_mappings": 35, "mappings": { - "GOV-01": [ - "Principle 7" + "GOV-02": [ + "P1-4.1.4" ], "CPL-01": [ - "Principle 7" + "P1-4.1", + "P1-4.1.3" ], - "CPL-02": [ - "Principle 7" + "CPL-05": [ + "P1-4.1.2" ], - "DCH-01": [ - "Principle 7" + "CFG-01": [ + "P7-4.7.3(c)" ], - "DCH-22.1": [ - "Principle 10" + "HRS-04.2": [ + "P1-4.1.4(d)" ], - "DCH-24": [ - "Sec 20" + "HRS-05.7": [ + "P1-4.1.4(d)" ], - "DCH-24.1": [ - "Sec 20" + "IAC-01": [ + "P7-4.7.3(b)" ], - "DCH-25": [ - "Sec 20" + "PES-01": [ + "P7-4.7.3(a)" ], - "PRI-01": [ - "Principle 1", - "Principle 8" + "PRI-01.1": [ + "P1-4.1", + "P1-4.1.1", + "P1-4.1.2" ], - "PRI-01.4": [ - "Sec 6" + "PRI-01.6": [ + "P1-4.1.4(a)", + "P7-4.7", + "P7-4.7.1", + "P7-4.7.2", + "P7-4.7.3" + ], + "PRI-01.11": [ + "P1-4.1.4(a)", + "P3-4.3.3", + "P4-4.4.1", + "P4-4.4.2" ], "PRI-02": [ - "Principle 2" + "P2-4.2", + "P2-4.2.1", + "P2-4.2.2", + "P2-4.2.3", + "P8-4.8", + "P8-4.8.1", + "P8-4.8.2", + "P8-4.8.2(a)", + "P8-4.8.2(b)", + "P8-4.8.2(c)", + "P8-4.8.2(d)", + "P8-4.8.2(e)", + "P8-4.8.3" ], "PRI-02.1": [ - "Sec 5", - "Principle 2" + "P2-4.2" ], "PRI-03": [ - "Sec 6", - "Sec 7", - "Principle 3" + "P2-4.2.5", + "P3-4.3", + "P3-4.3.1", + "P3-4.3.2", + "P3-4.3.3", + "P3-4.3.4", + "P3-4.3.5", + "P3-4.3.6", + "P3-4.3.7", + "P3-4.3.7(a)", + "P3-4.3.7(b)", + "P3-4.3.7(c)", + "P3-4.3.7(d)" ], "PRI-03.2": [ - "Sec 6", - "Sec 7", - "Principle 3" + "P2-4.2.4" + ], + "PRI-03.4": [ + "P3-4.3.8" ], "PRI-04": [ - "Sec 5", - "Principle 4" + "P4-4.4" ], "PRI-04.1": [ - "Sec 5", - "Principle 4" + "P4-4.4" ], "PRI-05": [ - "Sec 7", - "Sec 8", - "Principle 5", - "Principle 6" + "P5-4.5.3", + "P7-4.7.5" ], "PRI-05.2": [ - "Principle 6" + "P6-4.6", + "P6-4.6.1", + "P6-4.6.2", + "P6-4.6.3" + ], + "PRI-05.4": [ + "P5-4.5", + "P5-4.5.3" ], "PRI-06": [ - "Principle 8", - "Principle 9" + "P9-4.9", + "P10-4.10" ], "PRI-06.1": [ - "Principle 10" + "P9-4.9.5" ], - "PRI-06.3": [ - "Sec 11" + "PRI-06.4": [ + "P1-4.1.4(b)", + "P9-4.9.1", + "P9-4.9.4", + "P10-4.10.2", + "P10-4.10.3", + "P10-4.10.4" ], - "PRI-07": [ - "Sec 20", - "Sec 23" + "PRI-06.8": [ + "P9-4.9.2" ], "PRI-07.1": [ - "Sec 20", - "Sec 23" + "P1-4.1.3" + ], + "PRI-07.3": [ + "P9-4.9.6" + ], + "PRI-14": [ + "P5-4.5.1" ], - "SEA-01": [ - "Principle 7" + "PRI-14.1": [ + "P9-4.9.3" ], - "SEA-02": [ - "Principle 7" + "PRI-17": [ + "P9-4.9.4" ], - "SEA-03": [ - "Principle 7" + "PRI-18": [ + "P9-4.9.6" ], - "SEA-15": [ - "Sec 20" + "RSK-10": [ + "P5-4.5.1" ], - "TPM-04.4": [ - "Sec 20" + "OPS-01.1": [ + "P5-4.5.2" + ], + "OPS-03": [ + "P5-4.5.2" + ], + "SAT-02": [ + "P1-4.1.4(c)", + "P7-4.7.4" ] } }, "framework_to_scf": { - "total_mappings": 17, + "total_mappings": 68, "mappings": { - "Principle 7": [ - "GOV-01", + "P1-4.1.4": [ + "GOV-02" + ], + "P1-4.1": [ "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Principle 10": [ - "DCH-22.1", - "PRI-06.1" + "PRI-01.1" ], - "Sec 20": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "PRI-07.1", - "SEA-15", - "TPM-04.4" + "P1-4.1.3": [ + "CPL-01", + "PRI-07.1" ], - "Principle 1": [ - "PRI-01" + "P1-4.1.2": [ + "CPL-05", + "PRI-01.1" ], - "Principle 8": [ - "PRI-01", - "PRI-06" + "P7-4.7.3(c)": [ + "CFG-01" ], - "Sec 6": [ - "PRI-01.4", - "PRI-03", - "PRI-03.2" + "P1-4.1.4(d)": [ + "HRS-04.2", + "HRS-05.7" + ], + "P7-4.7.3(b)": [ + "IAC-01" + ], + "P7-4.7.3(a)": [ + "PES-01" + ], + "P1-4.1.1": [ + "PRI-01.1" + ], + "P1-4.1.4(a)": [ + "PRI-01.6", + "PRI-01.11" + ], + "P7-4.7": [ + "PRI-01.6" + ], + "P7-4.7.1": [ + "PRI-01.6" ], - "Principle 2": [ + "P7-4.7.2": [ + "PRI-01.6" + ], + "P7-4.7.3": [ + "PRI-01.6" + ], + "P3-4.3.3": [ + "PRI-01.11", + "PRI-03" + ], + "P4-4.4.1": [ + "PRI-01.11" + ], + "P4-4.4.2": [ + "PRI-01.11" + ], + "P2-4.2": [ "PRI-02", "PRI-02.1" ], - "Sec 5": [ - "PRI-02.1", - "PRI-04", - "PRI-04.1" + "P2-4.2.1": [ + "PRI-02" ], - "Sec 7": [ - "PRI-03", - "PRI-03.2", - "PRI-05" + "P2-4.2.2": [ + "PRI-02" + ], + "P2-4.2.3": [ + "PRI-02" + ], + "P8-4.8": [ + "PRI-02" + ], + "P8-4.8.1": [ + "PRI-02" + ], + "P8-4.8.2": [ + "PRI-02" + ], + "P8-4.8.2(a)": [ + "PRI-02" + ], + "P8-4.8.2(b)": [ + "PRI-02" + ], + "P8-4.8.2(c)": [ + "PRI-02" + ], + "P8-4.8.2(d)": [ + "PRI-02" + ], + "P8-4.8.2(e)": [ + "PRI-02" + ], + "P8-4.8.3": [ + "PRI-02" + ], + "P2-4.2.5": [ + "PRI-03" ], - "Principle 3": [ - "PRI-03", + "P3-4.3": [ + "PRI-03" + ], + "P3-4.3.1": [ + "PRI-03" + ], + "P3-4.3.2": [ + "PRI-03" + ], + "P3-4.3.4": [ + "PRI-03" + ], + "P3-4.3.5": [ + "PRI-03" + ], + "P3-4.3.6": [ + "PRI-03" + ], + "P3-4.3.7": [ + "PRI-03" + ], + "P3-4.3.7(a)": [ + "PRI-03" + ], + "P3-4.3.7(b)": [ + "PRI-03" + ], + "P3-4.3.7(c)": [ + "PRI-03" + ], + "P3-4.3.7(d)": [ + "PRI-03" + ], + "P2-4.2.4": [ "PRI-03.2" ], - "Principle 4": [ + "P3-4.3.8": [ + "PRI-03.4" + ], + "P4-4.4": [ "PRI-04", "PRI-04.1" ], - "Sec 8": [ - "PRI-05" + "P5-4.5.3": [ + "PRI-05", + "PRI-05.4" ], - "Principle 5": [ + "P7-4.7.5": [ "PRI-05" ], - "Principle 6": [ - "PRI-05", + "P6-4.6": [ + "PRI-05.2" + ], + "P6-4.6.1": [ + "PRI-05.2" + ], + "P6-4.6.2": [ "PRI-05.2" ], - "Principle 9": [ + "P6-4.6.3": [ + "PRI-05.2" + ], + "P5-4.5": [ + "PRI-05.4" + ], + "P9-4.9": [ "PRI-06" ], - "Sec 11": [ - "PRI-06.3" + "P10-4.10": [ + "PRI-06" ], - "Sec 23": [ - "PRI-07", - "PRI-07.1" + "P9-4.9.5": [ + "PRI-06.1" + ], + "P1-4.1.4(b)": [ + "PRI-06.4" + ], + "P9-4.9.1": [ + "PRI-06.4" + ], + "P9-4.9.4": [ + "PRI-06.4", + "PRI-17" + ], + "P10-4.10.2": [ + "PRI-06.4" + ], + "P10-4.10.3": [ + "PRI-06.4" + ], + "P10-4.10.4": [ + "PRI-06.4" + ], + "P9-4.9.2": [ + "PRI-06.8" + ], + "P9-4.9.6": [ + "PRI-07.3", + "PRI-18" + ], + "P5-4.5.1": [ + "PRI-14", + "RSK-10" + ], + "P9-4.9.3": [ + "PRI-14.1" + ], + "P5-4.5.2": [ + "OPS-01.1", + "OPS-03" + ], + "P1-4.1.4(c)": [ + "SAT-02" + ], + "P7-4.7.4": [ + "SAT-02" ] } } diff --git a/docs/api/crosswalks/americas-chl-act-19628-1999.json b/docs/api/crosswalks/americas-chl-act-19628-1999.json index 46a80d1b..d22ea4c2 100644 --- a/docs/api/crosswalks/americas-chl-act-19628-1999.json +++ b/docs/api/crosswalks/americas-chl-act-19628-1999.json @@ -1,125 +1,111 @@ { "framework_id": "americas-chl-act-19628-1999", - "display_name": "Chile - Act 19628 (1999)", + "display_name": "Chile - Act 19628 - Protection of Personal Data (1999)", "scf_to_framework": { - "total_mappings": 22, + "total_mappings": 12, "mappings": { - "GOV-01": [ - "7" - ], - "CPL-01": [ - "7" - ], - "CPL-02": [ - "7" - ], - "CPL-03": [ - "7" - ], - "DCH-01": [ - "7" - ], - "DCH-22.1": [ - "13" - ], - "DCH-24": [ - "7" - ], - "DCH-24.1": [ - "7" - ], - "PRI-01": [ - "Inferred", - "Expectation" + "HRS-06.1": [ + "I.7" ], "PRI-01.1": [ - "7", - "11" + "I.5" ], - "PRI-02": [ - "5" + "PRI-01.6": [ + "I.7", + "I.11" ], - "PRI-02.1": [ - "5" + "PRI-01.11": [ + "I.7", + "I.11" ], "PRI-03": [ - "4" + "I.4", + "I.8" ], - "PRI-05": [ - "9" - ], - "PRI-05.4": [ - "10" + "PRI-03.9": [ + "I.9" ], - "PRI-06": [ - "12" + "PRI-04.1": [ + "I.4" ], - "PRI-06.1": [ - "13" - ], - "SEA-01": [ - "7" - ], - "SEA-02": [ - "7" + "PRI-05": [ + "I.6" ], - "SEA-03": [ - "7" + "PRI-05.2": [ + "I.9" ], - "SEA-15": [ - "7" + "PRI-05.4": [ + "I.6", + "I.10", + "II.15" ], - "TPM-04.4": [ - "7" + "PRI-06": [ + "II.12", + "II.13", + "II.14" + ], + "PRI-15": [ + "I.5", + "I.5(a)", + "I.5(b)", + "I.5(c)" ] } }, "framework_to_scf": { - "total_mappings": 10, + "total_mappings": 15, "mappings": { - "4": [ - "PRI-03" + "I.7": [ + "HRS-06.1", + "PRI-01.6", + "PRI-01.11" ], - "5": [ - "PRI-02", - "PRI-02.1" - ], - "7": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", + "I.5": [ "PRI-01.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "PRI-15" + ], + "I.11": [ + "PRI-01.6", + "PRI-01.11" + ], + "I.4": [ + "PRI-03", + "PRI-04.1" + ], + "I.8": [ + "PRI-03" ], - "9": [ - "PRI-05" + "I.9": [ + "PRI-03.9", + "PRI-05.2" ], - "10": [ + "I.6": [ + "PRI-05", "PRI-05.4" ], - "11": [ - "PRI-01.1" + "I.10": [ + "PRI-05.4" + ], + "II.15": [ + "PRI-05.4" + ], + "II.12": [ + "PRI-06" + ], + "II.13": [ + "PRI-06" ], - "12": [ + "II.14": [ "PRI-06" ], - "13": [ - "DCH-22.1", - "PRI-06.1" + "I.5(a)": [ + "PRI-15" ], - "Inferred": [ - "PRI-01" + "I.5(b)": [ + "PRI-15" ], - "Expectation": [ - "PRI-01" + "I.5(c)": [ + "PRI-15" ] } } diff --git a/docs/api/crosswalks/americas-col-law-1581-2012.json b/docs/api/crosswalks/americas-col-law-1581-2012.json index baf71cd1..e504920f 100644 --- a/docs/api/crosswalks/americas-col-law-1581-2012.json +++ b/docs/api/crosswalks/americas-col-law-1581-2012.json @@ -2,176 +2,298 @@ "framework_id": "americas-col-law-1581-2012", "display_name": "Colombia - Law 1581 (2012)", "scf_to_framework": { - "total_mappings": 29, + "total_mappings": 21, "mappings": { - "GOV-01": [ - "4" + "GOV-02": [ + "VI.17(k)" ], "CPL-01": [ - "4" + "VI.17", + "VI.17(o)", + "VI.18" ], - "DCH-22.1": [ - "8", - "11" + "DCH-02": [ + "III.5" ], - "DCH-24": [ - "26" + "HRS-06.1": [ + "II.4(h)" ], - "DCH-24.1": [ - "26" - ], - "DCH-25": [ - "26" + "IRO-10.2": [ + "VI.17(n)" ], "PRI-01": [ - "4" - ], - "PRI-01.1": [ - "17", - "18" + "VI.18(a)", + "VI.18(b)", + "VI.18(c)", + "VI.18(d)", + "VI.18(e)", + "VI.18(f)", + "VI.18(g)", + "VI.18(h)", + "VI.18(i)", + "VI.18(j)", + "VI.18(k)", + "VI.18(l)" + ], + "PRI-01.6": [ + "II.4(g)", + "VI.17(d)" + ], + "PRI-01.11": [ + "II.4(d)", + "II.4(g)", + "VI.17(a)", + "VI.17(e)" ], "PRI-02": [ - "12" - ], - "PRI-02.1": [ - "4" + "VI.17(c)" ], "PRI-03": [ - "4" + "II.4(c)", + "VI.17(b)" ], - "PRI-04": [ - "4" + "PRI-03.2": [ + "VI.17(m)" ], - "PRI-04.1": [ - "4" + "PRI-03.4": [ + "IV.8(e)" ], - "PRI-05": [ - "4" - ], - "PRI-05.1": [ - "4" + "PRI-03.13": [ + "III.7" ], "PRI-05.2": [ - "4" + "VI.17(f)", + "VI.17(g)" ], "PRI-05.4": [ - "4", - "5", - "6", - "7" + "II.4(f)", + "III.6", + "III.6(a)", + "III.6(b)", + "III.6(c)", + "III.6(d)", + "III.6(e)", + "III.7" ], "PRI-06": [ - "8", - "11" - ], - "PRI-06.1": [ - "8", - "11" - ], - "PRI-06.2": [ - "8", - "11" - ], - "PRI-06.3": [ - "15" + "II.4(e)", + "IV.8(a)", + "IV.8(b)", + "IV.8(c)", + "IV.8(f)", + "IV.11", + "V.14", + "V.15", + "V.15.1" ], "PRI-06.4": [ - "12", - "15" + "IV.12(a)", + "IV.12(b)", + "IV.12(c)", + "IV.12(d)", + "V.15.2", + "V.15.3", + "VI.17(j)" + ], + "PRI-06.8": [ + "IV.9", + "IV.12" ], "PRI-07": [ - "26" - ], - "PRI-15": [ - "25" - ], - "SEA-01": [ - "4", - "26" - ], - "SEA-02": [ - "4", - "26" + "VI.17(h)" ], - "SEA-03": [ - "4", - "26" + "PRI-07.1": [ + "VI.17(i)" ], - "SEA-15": [ - "26" - ], - "TPM-04.4": [ - "26" + "PRI-07.3": [ + "VI.17(l)" ] } }, "framework_to_scf": { - "total_mappings": 12, + "total_mappings": 60, "mappings": { - "4": [ - "GOV-01", - "CPL-01", - "PRI-01", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.2", - "PRI-05.4", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "5": [ + "VI.17(k)": [ + "GOV-02" + ], + "VI.17": [ + "CPL-01" + ], + "VI.17(o)": [ + "CPL-01" + ], + "VI.18": [ + "CPL-01" + ], + "III.5": [ + "DCH-02" + ], + "II.4(h)": [ + "HRS-06.1" + ], + "VI.17(n)": [ + "IRO-10.2" + ], + "VI.18(a)": [ + "PRI-01" + ], + "VI.18(b)": [ + "PRI-01" + ], + "VI.18(c)": [ + "PRI-01" + ], + "VI.18(d)": [ + "PRI-01" + ], + "VI.18(e)": [ + "PRI-01" + ], + "VI.18(f)": [ + "PRI-01" + ], + "VI.18(g)": [ + "PRI-01" + ], + "VI.18(h)": [ + "PRI-01" + ], + "VI.18(i)": [ + "PRI-01" + ], + "VI.18(j)": [ + "PRI-01" + ], + "VI.18(k)": [ + "PRI-01" + ], + "VI.18(l)": [ + "PRI-01" + ], + "II.4(g)": [ + "PRI-01.6", + "PRI-01.11" + ], + "VI.17(d)": [ + "PRI-01.6" + ], + "II.4(d)": [ + "PRI-01.11" + ], + "VI.17(a)": [ + "PRI-01.11" + ], + "VI.17(e)": [ + "PRI-01.11" + ], + "VI.17(c)": [ + "PRI-02" + ], + "II.4(c)": [ + "PRI-03" + ], + "VI.17(b)": [ + "PRI-03" + ], + "VI.17(m)": [ + "PRI-03.2" + ], + "IV.8(e)": [ + "PRI-03.4" + ], + "III.7": [ + "PRI-03.13", + "PRI-05.4" + ], + "VI.17(f)": [ + "PRI-05.2" + ], + "VI.17(g)": [ + "PRI-05.2" + ], + "II.4(f)": [ + "PRI-05.4" + ], + "III.6": [ "PRI-05.4" ], - "6": [ + "III.6(a)": [ "PRI-05.4" ], - "7": [ + "III.6(b)": [ "PRI-05.4" ], - "8": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2" + "III.6(c)": [ + "PRI-05.4" + ], + "III.6(d)": [ + "PRI-05.4" + ], + "III.6(e)": [ + "PRI-05.4" + ], + "II.4(e)": [ + "PRI-06" + ], + "IV.8(a)": [ + "PRI-06" + ], + "IV.8(b)": [ + "PRI-06" + ], + "IV.8(c)": [ + "PRI-06" ], - "11": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2" + "IV.8(f)": [ + "PRI-06" ], - "12": [ - "PRI-02", + "IV.11": [ + "PRI-06" + ], + "V.14": [ + "PRI-06" + ], + "V.15": [ + "PRI-06" + ], + "V.15.1": [ + "PRI-06" + ], + "IV.12(a)": [ + "PRI-06.4" + ], + "IV.12(b)": [ + "PRI-06.4" + ], + "IV.12(c)": [ + "PRI-06.4" + ], + "IV.12(d)": [ + "PRI-06.4" + ], + "V.15.2": [ + "PRI-06.4" + ], + "V.15.3": [ "PRI-06.4" ], - "15": [ - "PRI-06.3", + "VI.17(j)": [ "PRI-06.4" ], - "17": [ - "PRI-01.1" - ], - "18": [ - "PRI-01.1" - ], - "25": [ - "PRI-15" - ], - "26": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "IV.9": [ + "PRI-06.8" + ], + "IV.12": [ + "PRI-06.8" + ], + "VI.17(h)": [ + "PRI-07" + ], + "VI.17(i)": [ + "PRI-07.1" + ], + "VI.17(l)": [ + "PRI-07.3" ] } } diff --git a/docs/api/crosswalks/americas-mex-fdpa-2010.json b/docs/api/crosswalks/americas-mex-fdpa-2010.json index 171f3d5d..2aec10d0 100644 --- a/docs/api/crosswalks/americas-mex-fdpa-2010.json +++ b/docs/api/crosswalks/americas-mex-fdpa-2010.json @@ -4,210 +4,376 @@ "scf_to_framework": { "total_mappings": 23, "mappings": { - "GOV-01": [ - "19" - ], - "CPL-01": [ - "19" + "DCH-18.1": [ + "II.13" ], "DCH-22.1": [ - "24", - "28", - "29" + "III.24", + "IV.28" ], - "IRO-04.1": [ - "20" + "IRO-10": [ + "II.20" ], "PRI-01": [ - "6", - "14", - "30" + "II.6", + "II.14" + ], + "PRI-01.4": [ + "IV.30" + ], + "PRI-01.6": [ + "II.19", + "II.21" + ], + "PRI-01.9": [ + "IV.30" + ], + "PRI-01.11": [ + "II.6", + "II.7", + "II.9", + "II.10", + "II.10.I", + "II.10.II", + "II.10.III", + "II.10.IV", + "II.10.V", + "II.10.VI", + "II.10.VII", + "III.26", + "III.26.I", + "III.26.II", + "III.26.III", + "III.26.IV", + "III.26.V", + "III.26.VI", + "III.26.VII", + "IV.34", + "IV.35" ], "PRI-02": [ - "7", - "16", - "17", - "18" + "II.7", + "II.12", + "II.15", + "II.16", + "II.16.I", + "II.16.II", + "II.16.III", + "II.16.IV", + "II.16.V", + "II.16.VI", + "II.17", + "II.17.I", + "II.17.II", + "II.18", + "V.36" ], "PRI-02.1": [ - "7", - "16", - "17", - "18" - ], - "PRI-02.2": [ - "7" + "II.16.II" ], "PRI-03": [ - "8", - "10" + "II.8", + "II.9" ], "PRI-03.2": [ - "7" + "II.16.VI" + ], + "PRI-03.4": [ + "II.8", + "III.25" ], "PRI-04": [ - "7" + "II.7", + "II.12" ], "PRI-04.1": [ - "7" + "II.7" ], "PRI-05": [ - "7", - "8", - "9", - "11", - "12", - "13", - "14" + "II.11" ], "PRI-05.2": [ - "9" + "II.11" ], "PRI-05.4": [ - "7", - "9" + "II.7", + "II.13", + "V.37", + "V.37.I", + "V.37.II", + "V.37.III", + "V.37.IV", + "V.37.V", + "V.37.VI", + "V.37.VII" ], "PRI-06": [ - "15", - "22", - "23", - "25" + "II.16.III", + "III.22", + "III.23", + "III.25", + "III.27", + "IV.28", + "IV.29", + "IV.29.I", + "IV.29.II", + "IV.29.III", + "IV.29.IV", + "IV.31" ], "PRI-06.1": [ - "24", - "28", - "29" + "III.24", + "IV.28" ], "PRI-06.4": [ - "30" - ], - "SEA-01": [ - "19", - "36", - "37" - ], - "SEA-02": [ - "19", - "36", - "37" - ], - "SEA-03": [ - "19", - "36", - "37" - ], - "TPM-03": [ - "21" - ], - "TPM-05": [ - "21" + "IV.32", + "IV.33" + ], + "PRI-07.1": [ + "II.21" + ], + "PRI-07.5": [ + "IV.34", + "IV.34.I", + "IV.34.II", + "IV.34.III", + "IV.34.IV", + "IV.34.V" ] } }, "framework_to_scf": { - "total_mappings": 25, + "total_mappings": 70, "mappings": { - "6": [ + "II.13": [ + "DCH-18.1", + "PRI-05.4" + ], + "III.24": [ + "DCH-22.1", + "PRI-06.1" + ], + "IV.28": [ + "DCH-22.1", + "PRI-06", + "PRI-06.1" + ], + "II.20": [ + "IRO-10" + ], + "II.6": [ + "PRI-01", + "PRI-01.11" + ], + "II.14": [ "PRI-01" ], - "7": [ + "IV.30": [ + "PRI-01.4", + "PRI-01.9" + ], + "II.19": [ + "PRI-01.6" + ], + "II.21": [ + "PRI-01.6", + "PRI-07.1" + ], + "II.7": [ + "PRI-01.11", "PRI-02", - "PRI-02.1", - "PRI-02.2", - "PRI-03.2", "PRI-04", "PRI-04.1", - "PRI-05", "PRI-05.4" ], - "8": [ - "PRI-03", - "PRI-05" + "II.9": [ + "PRI-01.11", + "PRI-03" ], - "9": [ - "PRI-05", - "PRI-05.2", - "PRI-05.4" + "II.10": [ + "PRI-01.11" ], - "10": [ - "PRI-03" + "II.10.I": [ + "PRI-01.11" ], - "11": [ - "PRI-05" + "II.10.II": [ + "PRI-01.11" ], - "12": [ - "PRI-05" + "II.10.III": [ + "PRI-01.11" ], - "13": [ - "PRI-05" + "II.10.IV": [ + "PRI-01.11" ], - "14": [ - "PRI-01", - "PRI-05" + "II.10.V": [ + "PRI-01.11" ], - "15": [ - "PRI-06" + "II.10.VI": [ + "PRI-01.11" + ], + "II.10.VII": [ + "PRI-01.11" + ], + "III.26": [ + "PRI-01.11" + ], + "III.26.I": [ + "PRI-01.11" + ], + "III.26.II": [ + "PRI-01.11" + ], + "III.26.III": [ + "PRI-01.11" + ], + "III.26.IV": [ + "PRI-01.11" ], - "16": [ + "III.26.V": [ + "PRI-01.11" + ], + "III.26.VI": [ + "PRI-01.11" + ], + "III.26.VII": [ + "PRI-01.11" + ], + "IV.34": [ + "PRI-01.11", + "PRI-07.5" + ], + "IV.35": [ + "PRI-01.11" + ], + "II.12": [ "PRI-02", - "PRI-02.1" + "PRI-04" ], - "17": [ + "II.15": [ + "PRI-02" + ], + "II.16": [ + "PRI-02" + ], + "II.16.I": [ + "PRI-02" + ], + "II.16.II": [ "PRI-02", "PRI-02.1" ], - "18": [ + "II.16.III": [ "PRI-02", - "PRI-02.1" + "PRI-06" + ], + "II.16.IV": [ + "PRI-02" ], - "19": [ - "GOV-01", - "CPL-01", - "SEA-01", - "SEA-02", - "SEA-03" + "II.16.V": [ + "PRI-02" ], - "20": [ - "IRO-04.1" + "II.16.VI": [ + "PRI-02", + "PRI-03.2" + ], + "II.17": [ + "PRI-02" + ], + "II.17.I": [ + "PRI-02" + ], + "II.17.II": [ + "PRI-02" + ], + "II.18": [ + "PRI-02" + ], + "V.36": [ + "PRI-02" + ], + "II.8": [ + "PRI-03", + "PRI-03.4" + ], + "III.25": [ + "PRI-03.4", + "PRI-06" + ], + "II.11": [ + "PRI-05", + "PRI-05.2" + ], + "V.37": [ + "PRI-05.4" + ], + "V.37.I": [ + "PRI-05.4" + ], + "V.37.II": [ + "PRI-05.4" + ], + "V.37.III": [ + "PRI-05.4" + ], + "V.37.IV": [ + "PRI-05.4" + ], + "V.37.V": [ + "PRI-05.4" ], - "21": [ - "TPM-03", - "TPM-05" + "V.37.VI": [ + "PRI-05.4" + ], + "V.37.VII": [ + "PRI-05.4" ], - "22": [ + "III.22": [ "PRI-06" ], - "23": [ + "III.23": [ "PRI-06" ], - "24": [ - "DCH-22.1", - "PRI-06.1" + "III.27": [ + "PRI-06" ], - "25": [ + "IV.29": [ "PRI-06" ], - "28": [ - "DCH-22.1", - "PRI-06.1" + "IV.29.I": [ + "PRI-06" ], - "29": [ - "DCH-22.1", - "PRI-06.1" + "IV.29.II": [ + "PRI-06" ], - "30": [ - "PRI-01", + "IV.29.III": [ + "PRI-06" + ], + "IV.29.IV": [ + "PRI-06" + ], + "IV.31": [ + "PRI-06" + ], + "IV.32": [ + "PRI-06.4" + ], + "IV.33": [ "PRI-06.4" ], - "36": [ - "SEA-01", - "SEA-02", - "SEA-03" + "IV.34.I": [ + "PRI-07.5" + ], + "IV.34.II": [ + "PRI-07.5" + ], + "IV.34.III": [ + "PRI-07.5" + ], + "IV.34.IV": [ + "PRI-07.5" ], - "37": [ - "SEA-01", - "SEA-02", - "SEA-03" + "IV.34.V": [ + "PRI-07.5" ] } } diff --git a/docs/api/crosswalks/apac-aus-cop-sitc-2020.json b/docs/api/crosswalks/apac-aus-cop-sitc-2020.json index 3d27938e..c93de6d6 100644 --- a/docs/api/crosswalks/apac-aus-cop-sitc-2020.json +++ b/docs/api/crosswalks/apac-aus-cop-sitc-2020.json @@ -2,126 +2,182 @@ "framework_id": "apac-aus-cop-sitc-2020", "display_name": "Australia - Code of Practice - Securing the Internet of Things for Consumers (2020)", "scf_to_framework": { - "total_mappings": 15, + "total_mappings": 35, "mappings": { - "AST-18": [ - "Principle 4", - "Principle 7" + "CPL-01": [ + "5" ], - "EMB-02": [ - "Principle 11", - "Principle 13" + "CFG-02": [ + "6" + ], + "CFG-03": [ + "6" + ], + "MON-01.4": [ + "7" + ], + "MON-02.1": [ + "10" + ], + "MON-03": [ + "7" + ], + "CRY-03": [ + "7" ], "EMB-04": [ - "Principle 6", - "Principle 13" + "13" ], "EMB-05": [ - "Principle 8", - "Principle 10" + "8" ], "EMB-06": [ - "Principle 6" + "13" ], "EMB-07": [ - "Principle 3", - "Principle 12" + "3" ], "EMB-08": [ - "Principle 9" + "9" + ], + "EMB-09": [ + "10" ], - "END-06.5": [ - "Principle 8" + "EMB-12": [ + "13" + ], + "EMB-13": [ + "13" ], "END-06.6": [ - "Principle 8" + "8" + ], + "IAC-06": [ + "1" ], "IAC-10.1": [ - "Principle 1" + "1" + ], + "IAC-10.6": [ + "4" + ], + "IAC-15": [ + "1" + ], + "IAC-21": [ + "6" + ], + "NET-14.2": [ + "7" + ], + "PRI-01.6": [ + "5" + ], + "PRI-01.11": [ + "5" + ], + "PRI-07.1": [ + "5" + ], + "TDA-01.1": [ + "11" ], - "IAC-10.8": [ - "Principle 1" + "TDA-02": [ + "4" ], - "SEA-01": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" + "TDA-04": [ + "11", + "12" ], - "SEA-02": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" + "TDA-06": [ + "4", + "6" ], - "SEA-03": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" + "TDA-09.6": [ + "4" + ], + "TDA-17": [ + "3" ], "THR-06": [ - "Principle 2" + "2" + ], + "THR-06.1": [ + "2" + ], + "VPM-05": [ + "3" + ], + "VPM-05.8": [ + "3" ] } }, "framework_to_scf": { "total_mappings": 13, "mappings": { - "Principle 4": [ - "AST-18", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Principle 7": [ - "AST-18", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Principle 11": [ - "EMB-02" - ], - "Principle 13": [ - "EMB-02", - "EMB-04" - ], - "Principle 6": [ - "EMB-04", - "EMB-06", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Principle 8": [ + "1": [ + "IAC-06", + "IAC-10.1", + "IAC-15" + ], + "2": [ + "THR-06", + "THR-06.1" + ], + "3": [ + "EMB-07", + "TDA-17", + "VPM-05", + "VPM-05.8" + ], + "4": [ + "IAC-10.6", + "TDA-02", + "TDA-06", + "TDA-09.6" + ], + "5": [ + "CPL-01", + "PRI-01.6", + "PRI-01.11", + "PRI-07.1" + ], + "6": [ + "CFG-02", + "CFG-03", + "IAC-21", + "TDA-06" + ], + "7": [ + "MON-01.4", + "MON-03", + "CRY-03", + "NET-14.2" + ], + "8": [ "EMB-05", - "END-06.5", "END-06.6" ], - "Principle 10": [ - "EMB-05" - ], - "Principle 3": [ - "EMB-07" - ], - "Principle 12": [ - "EMB-07" - ], - "Principle 9": [ + "9": [ "EMB-08" ], - "Principle 1": [ - "IAC-10.1", - "IAC-10.8" + "10": [ + "MON-02.1", + "EMB-09" ], - "Principle 5": [ - "SEA-01", - "SEA-02", - "SEA-03" + "11": [ + "TDA-01.1", + "TDA-04" ], - "Principle 2": [ - "THR-06" + "12": [ + "TDA-04" + ], + "13": [ + "EMB-04", + "EMB-06", + "EMB-12", + "EMB-13" ] } } diff --git a/docs/api/crosswalks/apac-aus-essential-8-2024.json b/docs/api/crosswalks/apac-aus-essential-8-2024.json index 934ae8c7..eaf39a91 100644 --- a/docs/api/crosswalks/apac-aus-essential-8-2024.json +++ b/docs/api/crosswalks/apac-aus-essential-8-2024.json @@ -1,6 +1,6 @@ { "framework_id": "apac-aus-essential-8-2024", - "display_name": "Australia - Essential Eight (2024)", + "display_name": "Australia - Essential Eight maturity model and ISM mapping (2024)", "scf_to_framework": { "total_mappings": 37, "mappings": { diff --git a/docs/api/crosswalks/apac-aus-ism-2024-june.json b/docs/api/crosswalks/apac-aus-ism-2026-march.json similarity index 78% rename from docs/api/crosswalks/apac-aus-ism-2024-june.json rename to docs/api/crosswalks/apac-aus-ism-2026-march.json index 829c3bb6..8476f557 100644 --- a/docs/api/crosswalks/apac-aus-ism-2024-june.json +++ b/docs/api/crosswalks/apac-aus-ism-2026-march.json @@ -1,28 +1,37 @@ { - "framework_id": "apac-aus-ism-2024-june", - "display_name": "Australia - Information Security Manual (ISM) (June 2024)", + "framework_id": "apac-aus-ism-2026-march", + "display_name": "Australia - Information Security Manual (ISM) (March 2026)", "scf_to_framework": { - "total_mappings": 336, + "total_mappings": 389, "mappings": { "GOV-01": [ - "ISM-0888" + "ISM-0047" ], "GOV-01.1": [ - "ISM-0725" + "ISM-0725", + "ISM-1998", + "ISM-1999", + "ISM-2002", + "ISM-2003", + "ISM-2005", + "ISM-2006" ], "GOV-01.2": [ - "ISM-0718" + "ISM-0718", + "ISM-1918", + "ISM-2000" ], "GOV-02": [ "ISM-0047", - "ISM-0888", "ISM-1478", "ISM-1551", "ISM-1602", "ISM-1784", - "ISM-1785" + "ISM-1785", + "ISM-2074" ], "GOV-03": [ + "ISM-0888", "ISM-1617" ], "GOV-04": [ @@ -36,11 +45,15 @@ "ISM-0732", "ISM-0733", "ISM-0734", - "ISM-0735" + "ISM-0735", + "ISM-1997" ], "GOV-05": [ "ISM-0724" ], + "GOV-14": [ + "ISM-2001" + ], "GOV-15": [ "ISM-1633", "ISM-1634", @@ -65,6 +78,39 @@ "GOV-17": [ "ISM-1587" ], + "GOV-21": [ + "ISM-2005" + ], + "AAT-01": [ + "ISM-2072", + "ISM-2074" + ], + "AAT-03": [ + "ISM-2084" + ], + "AAT-12.1": [ + "ISM-2086", + "ISM-2087" + ], + "AAT-12.5": [ + "ISM-2088" + ], + "AAT-12.6": [ + "ISM-2103" + ], + "AAT-16.11": [ + "ISM-2089" + ], + "AAT-17": [ + "ISM-2094" + ], + "AAT-29.2": [ + "ISM-2092" + ], + "AAT-29.24": [ + "ISM-2090", + "ISM-2091" + ], "AST-01": [ "ISM-0285", "ISM-0286", @@ -77,7 +123,8 @@ "AST-02": [ "ISM-0336", "ISM-1643", - "ISM-1807" + "ISM-1807", + "ISM-1966" ], "AST-02.2": [ "ISM-1807" @@ -95,7 +142,8 @@ "AST-03.2": [ "ISM-1790", "ISM-1791", - "ISM-1792" + "ISM-1792", + "ISM-1816" ], "AST-04": [ "ISM-0516", @@ -106,7 +154,12 @@ "AST-05": [ "ISM-0161", "ISM-0293", - "ISM-1178" + "ISM-1178", + "ISM-1973" + ], + "AST-05.2": [ + "ISM-1974", + "ISM-1975" ], "AST-06": [ "ISM-0161" @@ -132,7 +185,6 @@ "ISM-1221", "ISM-1222", "ISM-1223", - "ISM-1225", "ISM-1534", "ISM-1550", "ISM-1641", @@ -183,7 +235,9 @@ "ISM-0245", "ISM-0589", "ISM-0590", - "ISM-1036" + "ISM-1036", + "ISM-1854", + "ISM-1855" ], "AST-24": [ "ISM-1088", @@ -233,15 +287,19 @@ "ISM-1260", "ISM-1263" ], + "AST-30": [ + "ISM-2053" + ], "BCD-01": [ "ISM-0734" ], "BCD-01.4": [ "ISM-1810" ], + "BCD-02": [ + "ISM-2005" + ], "BCD-11": [ - "ISM-0859", - "ISM-0991", "ISM-1511", "ISM-1547", "ISM-1548", @@ -254,6 +312,14 @@ "BCD-11.2": [ "ISM-1811" ], + "BCD-11.9": [ + "ISM-1812", + "ISM-1813", + "ISM-1814" + ], + "BCD-11.10": [ + "ISM-1814" + ], "BCD-15": [ "ISM-1789" ], @@ -281,6 +347,9 @@ "CHG-02": [ "ISM-1211" ], + "CHG-04": [ + "ISM-1823" + ], "CHG-04.2": [ "ISM-1796" ], @@ -315,6 +384,9 @@ "CPL-03.1": [ "ISM-0100" ], + "CFG-01": [ + "ISM-0912" + ], "CFG-02": [ "ISM-0341", "ISM-0343", @@ -344,7 +416,76 @@ "ISM-1654", "ISM-1655", "ISM-1710", - "ISM-1745" + "ISM-1745", + "ISM-1823", + "ISM-1824", + "ISM-1825", + "ISM-1828", + "ISM-1829", + "ISM-1830", + "ISM-1836", + "ISM-1838", + "ISM-1839", + "ISM-1840", + "ISM-1841", + "ISM-1844", + "ISM-1846", + "ISM-1858", + "ISM-1859", + "ISM-1860", + "ISM-1861", + "ISM-1870", + "ISM-1871", + "ISM-1886", + "ISM-1887", + "ISM-1888", + "ISM-1890", + "ISM-1891", + "ISM-1896", + "ISM-1897", + "ISM-1913", + "ISM-1914", + "ISM-1915", + "ISM-1916", + "ISM-1928", + "ISM-1929", + "ISM-1930", + "ISM-1931", + "ISM-1932", + "ISM-1933", + "ISM-1934", + "ISM-1935", + "ISM-1936", + "ISM-1938", + "ISM-1943", + "ISM-1944", + "ISM-1945", + "ISM-1946", + "ISM-1947", + "ISM-1948", + "ISM-1949", + "ISM-1950", + "ISM-1951", + "ISM-1952", + "ISM-1953", + "ISM-1954", + "ISM-1955", + "ISM-1956", + "ISM-1957", + "ISM-1958", + "ISM-1962", + "ISM-1980", + "ISM-1984", + "ISM-2010", + "ISM-2012", + "ISM-2047", + "ISM-2049", + "ISM-2079", + "ISM-2080", + "ISM-2081", + "ISM-2096", + "ISM-2097", + "ISM-2098" ], "CFG-02.1": [ "ISM-1407", @@ -369,10 +510,11 @@ "ISM-1674", "ISM-1675", "ISM-1676", - "ISM-1677", "ISM-1748", "ISM-1749", - "ISM-1800" + "ISM-1800", + "ISM-1867", + "ISM-1868" ], "CFG-03": [ "ISM-0385", @@ -437,6 +579,20 @@ "ISM-1544", "ISM-1582" ], + "CFG-09": [ + "ISM-2023" + ], + "CFG-09.1": [ + "ISM-2029" + ], + "CFG-09.2": [ + "ISM-2026", + "ISM-2027", + "ISM-2030" + ], + "CFG-09.3": [ + "ISM-2024" + ], "MON-01": [ "ISM-0109", "ISM-0120", @@ -446,6 +602,14 @@ "ISM-1294", "ISM-1586" ], + "MON-01.3": [ + "ISM-1906", + "ISM-1907", + "ISM-2015" + ], + "MON-01.4": [ + "ISM-1959" + ], "MON-01.8": [ "ISM-0109" ], @@ -468,10 +632,22 @@ "ISM-1536", "ISM-1537", "ISM-1566", - "ISM-1650" + "ISM-1650", + "ISM-1911", + "ISM-1960", + "ISM-1963", + "ISM-1976", + "ISM-1977", + "ISM-1978", + "ISM-1979", + "ISM-1983", + "ISM-1986", + "ISM-1987" ], "MON-02.1": [ - "ISM-1228" + "ISM-1228", + "ISM-1961", + "ISM-1964" ], "MON-02.2": [ "ISM-1228" @@ -483,13 +659,19 @@ "ISM-0582", "ISM-0585", "ISM-1536", - "ISM-1537" + "ISM-1537", + "ISM-1895", + "ISM-2051" + ], + "MON-03.1": [ + "ISM-2052" ], "MON-03.2": [ "ISM-0407" ], "MON-03.3": [ - "ISM-1537" + "ISM-1537", + "ISM-1889" ], "MON-03.7": [ "ISM-1537" @@ -498,13 +680,15 @@ "ISM-1660" ], "MON-08": [ - "ISM-0859", - "ISM-0991" + "ISM-1815" + ], + "MON-08.2": [ + "ISM-1985" ], "MON-10": [ - "ISM-0859", - "ISM-0991", - "ISM-1213" + "ISM-1213", + "ISM-1988", + "ISM-1989" ], "MON-11.3": [ "ISM-0120", @@ -538,6 +722,7 @@ "ISM-1080", "ISM-1091", "ISM-1146", + "ISM-1233", "ISM-1446", "ISM-1629", "ISM-1759", @@ -561,7 +746,6 @@ "CRY-03": [ "ISM-0231", "ISM-0232", - "ISM-0241", "ISM-0465", "ISM-0467", "ISM-0469", @@ -598,7 +782,8 @@ ], "CRY-08": [ "ISM-0485", - "ISM-1449" + "ISM-1449", + "ISM-2050" ], "CRY-09": [ "ISM-0455", @@ -745,10 +930,11 @@ "ISM-1779" ], "DCH-18": [ - "ISM-0859", - "ISM-0991", "ISM-1510" ], + "DCH-18.1": [ + "ISM-2021" + ], "DCH-21": [ "ISM-0311" ], @@ -760,7 +946,8 @@ "ISM-1290", "ISM-1293", "ISM-1417", - "ISM-1608" + "ISM-1608", + "ISM-1969" ], "END-04.4": [ "ISM-1284", @@ -796,7 +983,9 @@ "ISM-0732", "ISM-0733", "ISM-0734", - "ISM-0735" + "ISM-0735", + "ISM-2035", + "ISM-2036" ], "HRS-03.1": [ "ISM-0824" @@ -825,11 +1014,14 @@ "HRS-05": [ "ISM-0258", "ISM-0824", - "ISM-1146" + "ISM-1146", + "ISM-1865" ], "HRS-05.1": [ "ISM-0820", - "ISM-0821" + "ISM-0821", + "ISM-1864", + "ISM-2095" ], "HRS-05.2": [ "ISM-0229", @@ -838,15 +1030,12 @@ "ISM-0235", "ISM-0236", "ISM-0240", - "ISM-0241", "ISM-0264", "ISM-0267", "ISM-0588", "ISM-0824", "ISM-0931", - "ISM-1075", "ISM-1078", - "ISM-1092", "ISM-1196", "ISM-1198", "ISM-1199", @@ -854,6 +1043,17 @@ "ISM-1562", "ISM-1644" ], + "HRS-05.3": [ + "ISM-1866", + "ISM-2075", + "ISM-2095", + "ISM-2099", + "ISM-2100", + "ISM-2101" + ], + "HRS-05.4": [ + "ISM-2095" + ], "HRS-05.5": [ "ISM-0229", "ISM-0230", @@ -872,7 +1072,8 @@ "ISM-1198", "ISM-1199", "ISM-1200", - "ISM-1366" + "ISM-1366", + "ISM-1866" ], "HRS-08": [ "ISM-0430" @@ -882,11 +1083,17 @@ ], "IAC-01": [ "ISM-1146", - "ISM-1546" + "ISM-1546", + "ISM-2076", + "ISM-2077" ], "IAC-01.1": [ "ISM-0407" ], + "IAC-01.2": [ + "ISM-2013", + "ISM-2014" + ], "IAC-02": [ "ISM-0414", "ISM-0415", @@ -920,7 +1127,14 @@ "ISM-1681", "ISM-1682", "ISM-1683", - "ISM-1685" + "ISM-1685", + "ISM-1872", + "ISM-1873", + "ISM-1874", + "ISM-1892", + "ISM-1893", + "ISM-1894", + "ISM-2011" ], "IAC-07": [ "ISM-0430" @@ -932,7 +1146,10 @@ "ISM-0430" ], "IAC-08": [ - "ISM-1746" + "ISM-1746", + "ISM-1852", + "ISM-2092", + "ISM-2093" ], "IAC-10": [ "ISM-1227", @@ -947,7 +1164,14 @@ "ISM-1557", "ISM-1558", "ISM-1596", - "ISM-1795" + "ISM-1795", + "ISM-1980", + "ISM-2079", + "ISM-2080", + "ISM-2081" + ], + "IAC-10.4": [ + "ISM-2078" ], "IAC-10.5": [ "ISM-0418", @@ -959,11 +1183,18 @@ ], "IAC-10.8": [ "ISM-1304", - "ISM-1806" + "ISM-1806", + "ISM-2044" ], "IAC-15": [ "ISM-0441", - "ISM-0443" + "ISM-0443", + "ISM-1832", + "ISM-1834", + "ISM-1845", + "ISM-1940", + "ISM-1941", + "ISM-1942" ], "IAC-15.1": [ "ISM-1649" @@ -998,21 +1229,27 @@ "ISM-1650", "ISM-1687", "ISM-1688", - "ISM-1689" + "ISM-1689", + "ISM-1835", + "ISM-1939" ], "IAC-16.4": [ - "ISM-0445" + "ISM-0445", + "ISM-1827", + "ISM-1842" ], "IAC-17": [ "ISM-0405", "ISM-1647", - "ISM-1648", - "ISM-1716" + "ISM-1648" ], "IAC-18": [ "ISM-0421", "ISM-0422" ], + "IAC-20.4": [ + "ISM-1898" + ], "IAC-21": [ "ISM-0441", "ISM-0611", @@ -1021,13 +1258,16 @@ "ISM-1705", "ISM-1706", "ISM-1707", - "ISM-1708" + "ISM-1708", + "ISM-1833" ], "IAC-21.2": [ - "ISM-1175" + "ISM-1175", + "ISM-1883" ], "IAC-21.5": [ - "ISM-1592" + "ISM-1592", + "ISM-2048" ], "IAC-22": [ "ISM-1403" @@ -1052,7 +1292,8 @@ "ISM-0141", "ISM-0917", "ISM-1618", - "ISM-1803" + "ISM-1803", + "ISM-1819" ], "IRO-02.2": [ "ISM-1625", @@ -1067,6 +1308,9 @@ "IRO-04.1": [ "ISM-0133" ], + "IRO-06": [ + "ISM-2006" + ], "IRO-07": [ "ISM-0733", "ISM-1618" @@ -1090,7 +1334,9 @@ "ISM-0137", "ISM-0733", "ISM-1088", - "ISM-1609" + "ISM-1609", + "ISM-1880", + "ISM-1881" ], "IRO-10.2": [ "ISM-0733" @@ -1116,7 +1362,8 @@ "IRO-15": [ "ISM-0651", "ISM-0652", - "ISM-1389" + "ISM-1389", + "ISM-1970" ], "IAO-01": [ "ISM-0027", @@ -1124,12 +1371,16 @@ "ISM-1525" ], "IAO-02": [ - "ISM-0100" + "ISM-0100", + "ISM-1967", + "ISM-1971", + "ISM-1972" ], "IAO-02.2": [ "ISM-0100", "ISM-1137", - "ISM-1570" + "ISM-1570", + "ISM-2019" ], "IAO-02.3": [ "ISM-0100" @@ -1139,7 +1390,10 @@ ], "IAO-03": [ "ISM-0041", - "ISM-0432" + "ISM-0432", + "ISM-0912", + "ISM-1912", + "ISM-2005" ], "IAO-03.2": [ "ISM-0072", @@ -1156,11 +1410,11 @@ "IAO-07": [ "ISM-0027", "ISM-0293", - "ISM-1525" + "ISM-1525", + "ISM-1968" ], "MNT-01": [ - "ISM-0305", - "ISM-1226" + "ISM-0305" ], "MNT-02": [ "ISM-1079" @@ -1282,6 +1536,9 @@ "ISM-1158", "ISM-1386" ], + "NET-04.1": [ + "ISM-2068" + ], "NET-06": [ "ISM-1181", "ISM-1269", @@ -1304,6 +1561,9 @@ "NET-06.4": [ "ISM-1385" ], + "NET-06.5": [ + "ISM-1863" + ], "NET-06.6": [ "ISM-1269", "ISM-1270", @@ -1331,7 +1591,8 @@ "ISM-1183", "ISM-1540", "ISM-1782", - "ISM-1799" + "ISM-1799", + "ISM-2017" ], "NET-10.3": [ "ISM-0574", @@ -1383,7 +1644,6 @@ ], "NET-15": [ "ISM-0225", - "ISM-0248", "ISM-0536", "ISM-1314", "ISM-1315", @@ -1425,7 +1685,8 @@ "ISM-1287", "ISM-1293", "ISM-1502", - "ISM-1524" + "ISM-1524", + "ISM-1965" ], "NET-18.1": [ "ISM-0260", @@ -1509,7 +1770,10 @@ "ISM-1718", "ISM-1719", "ISM-1720", - "ISM-1721" + "ISM-1721", + "ISM-1820", + "ISM-1821", + "ISM-1822" ], "PES-12.2": [ "ISM-1036" @@ -1540,10 +1804,15 @@ "ISM-0720" ], "PRM-02": [ - "ISM-0732" + "ISM-0732", + "ISM-2004" + ], + "PRM-02.1": [ + "ISM-2020" ], "PRM-03": [ - "ISM-0732" + "ISM-0732", + "ISM-2020" ], "PRM-04": [ "ISM-1739" @@ -1556,13 +1825,36 @@ "ISM-1526", "ISM-1739" ], + "QTS-03": [ + "ISM-1917", + "ISM-2073" + ], + "QTS-04.2": [ + "ISM-2082", + "ISM-2083" + ], + "QTS-06.3": [ + "ISM-1990", + "ISM-1991", + "ISM-1992", + "ISM-1993", + "ISM-1994", + "ISM-1995" + ], + "QTS-06.9": [ + "ISM-1996" + ], "RSK-01": [ "ISM-0726" ], "RSK-03": [ "ISM-1526" ], + "RSK-04": [ + "ISM-1203" + ], "RSK-06.2": [ + "ISM-0009", "ISM-1809" ], "RSK-09": [ @@ -1576,7 +1868,9 @@ ], "SEA-01": [ "ISM-1739", - "ISM-1743" + "ISM-1743", + "ISM-1926", + "ISM-1927" ], "SEA-02": [ "ISM-1739", @@ -1612,7 +1906,8 @@ "SAT-01": [ "ISM-0252", "ISM-0720", - "ISM-0735" + "ISM-0735", + "ISM-2022" ], "SAT-02": [ "ISM-0252", @@ -1621,7 +1916,8 @@ "ISM-1740" ], "SAT-02.2": [ - "ISM-0817" + "ISM-0817", + "ISM-2071" ], "SAT-03": [ "ISM-1146", @@ -1662,16 +1958,49 @@ "ISM-1798" ], "TDA-04.2": [ - "ISM-1730" + "ISM-1730", + "ISM-2054", + "ISM-2056" + ], + "TDA-05": [ + "ISM-2033", + "ISM-2043" ], "TDA-06": [ "ISM-0401", "ISM-1239", "ISM-1419", - "ISM-1552" + "ISM-1552", + "ISM-1849", + "ISM-1922", + "ISM-2032", + "ISM-2035", + "ISM-2041", + "ISM-2045", + "ISM-2063", + "ISM-2064", + "ISM-2065", + "ISM-2066", + "ISM-2067" ], "TDA-06.2": [ - "ISM-1238" + "ISM-1238", + "ISM-2039" + ], + "TDA-06.3": [ + "ISM-2025", + "ISM-2034", + "ISM-2102" + ], + "TDA-06.4": [ + "ISM-2031" + ], + "TDA-06.6": [ + "ISM-1909" + ], + "TDA-06.7": [ + "ISM-2040", + "ISM-2041" ], "TDA-07": [ "ISM-0400", @@ -1684,22 +2013,33 @@ ], "TDA-09": [ "ISM-0402", - "ISM-1754" + "ISM-1754", + "ISM-1850", + "ISM-1851", + "ISM-2057", + "ISM-2060", + "ISM-2061", + "ISM-2062" ], "TDA-09.2": [ - "ISM-0402" + "ISM-0402", + "ISM-2028" ], "TDA-09.3": [ - "ISM-0402" + "ISM-0402", + "ISM-2028" ], "TDA-09.4": [ - "ISM-0402" + "ISM-0402", + "ISM-2057" ], "TDA-09.5": [ "ISM-0402" ], "TDA-09.6": [ - "ISM-0383" + "ISM-0383", + "ISM-2042", + "ISM-2044" ], "TDA-10": [ "ISM-1420" @@ -1712,11 +2052,23 @@ "ISM-1791", "ISM-1792" ], + "TDA-13.1": [ + "ISM-2038" + ], + "TDA-13.2": [ + "ISM-2037" + ], "TDA-17": [ "ISM-0304", "ISM-1501", "ISM-1704", - "ISM-1753" + "ISM-1753", + "ISM-1848", + "ISM-1981", + "ISM-1982" + ], + "TDA-18": [ + "ISM-2059" ], "TDA-20": [ "ISM-1422" @@ -1759,7 +2111,8 @@ "TPM-04.1": [ "ISM-1568", "ISM-1573", - "ISM-1787" + "ISM-1787", + "ISM-1882" ], "TPM-04.4": [ "ISM-1572" @@ -1808,12 +2161,23 @@ "ISM-1755", "ISM-1756" ], + "THR-07": [ + "ISM-1921" + ], + "THR-10": [ + "ISM-1203" + ], "VPM-01": [ "ISM-1143", "ISM-1163", "ISM-1460", "ISM-1493" ], + "VPM-02": [ + "ISM-1902", + "ISM-1903", + "ISM-1904" + ], "VPM-03": [ "ISM-1163" ], @@ -1835,7 +2199,12 @@ "ISM-1695", "ISM-1696", "ISM-1697", - "ISM-1751" + "ISM-1751", + "ISM-1876", + "ISM-1877", + "ISM-1878", + "ISM-1879", + "ISM-1901" ], "VPM-05.1": [ "ISM-0298", @@ -1852,7 +2221,9 @@ "ISM-1701", "ISM-1702", "ISM-1703", - "ISM-1752" + "ISM-1752", + "ISM-1875", + "ISM-1900" ], "VPM-06.1": [ "ISM-1808" @@ -1860,6 +2231,9 @@ "VPM-07": [ "ISM-1163" ], + "WEB-03": [ + "ISM-1862" + ], "WEB-07": [ "ISM-0971", "ISM-1239" @@ -1882,9 +2256,9 @@ } }, "framework_to_scf": { - "total_mappings": 802, + "total_mappings": 1054, "mappings": { - "ISM-0888": [ + "ISM-0047": [ "GOV-01", "GOV-02" ], @@ -1893,11 +2267,36 @@ "GOV-04", "HRS-03" ], + "ISM-1998": [ + "GOV-01.1" + ], + "ISM-1999": [ + "GOV-01.1" + ], + "ISM-2002": [ + "GOV-01.1" + ], + "ISM-2003": [ + "GOV-01.1" + ], + "ISM-2005": [ + "GOV-01.1", + "GOV-21", + "BCD-02", + "IAO-03" + ], + "ISM-2006": [ + "GOV-01.1", + "IRO-06" + ], "ISM-0718": [ "GOV-01.2" ], - "ISM-0047": [ - "GOV-02" + "ISM-1918": [ + "GOV-01.2" + ], + "ISM-2000": [ + "GOV-01.2" ], "ISM-1478": [ "GOV-02" @@ -1917,6 +2316,13 @@ "RSK-09", "TPM-01" ], + "ISM-2074": [ + "GOV-02", + "AAT-01" + ], + "ISM-0888": [ + "GOV-03" + ], "ISM-1617": [ "GOV-03" ], @@ -1976,6 +2382,12 @@ "HRS-03", "SAT-01" ], + "ISM-1997": [ + "GOV-04" + ], + "ISM-2001": [ + "GOV-14" + ], "ISM-1633": [ "GOV-15" ], @@ -2004,6 +2416,40 @@ "ISM-1587": [ "GOV-17" ], + "ISM-2072": [ + "AAT-01" + ], + "ISM-2084": [ + "AAT-03" + ], + "ISM-2086": [ + "AAT-12.1" + ], + "ISM-2087": [ + "AAT-12.1" + ], + "ISM-2088": [ + "AAT-12.5" + ], + "ISM-2103": [ + "AAT-12.6" + ], + "ISM-2089": [ + "AAT-16.11" + ], + "ISM-2094": [ + "AAT-17" + ], + "ISM-2092": [ + "AAT-29.2", + "IAC-08" + ], + "ISM-2090": [ + "AAT-29.24" + ], + "ISM-2091": [ + "AAT-29.24" + ], "ISM-0285": [ "AST-01" ], @@ -2036,6 +2482,9 @@ "AST-02", "AST-02.2" ], + "ISM-1966": [ + "AST-02" + ], "ISM-0520": [ "AST-02.5" ], @@ -2062,6 +2511,9 @@ "AST-03.2", "TDA-11" ], + "ISM-1816": [ + "AST-03.2" + ], "ISM-0516": [ "AST-04" ], @@ -2085,6 +2537,15 @@ "ISM-1178": [ "AST-05" ], + "ISM-1973": [ + "AST-05" + ], + "ISM-1974": [ + "AST-05.2" + ], + "ISM-1975": [ + "AST-05.2" + ], "ISM-0311": [ "AST-09", "DCH-08", @@ -2160,9 +2621,6 @@ "ISM-1223": [ "AST-09" ], - "ISM-1225": [ - "AST-09" - ], "ISM-1534": [ "AST-09" ], @@ -2288,6 +2746,12 @@ "AST-23", "PES-12.2" ], + "ISM-1854": [ + "AST-23" + ], + "ISM-1855": [ + "AST-23" + ], "ISM-1088": [ "AST-24", "IRO-10" @@ -2408,22 +2872,13 @@ "ISM-1263": [ "AST-28.1" ], + "ISM-2053": [ + "AST-30" + ], "ISM-1810": [ "BCD-01.4", "BCD-11" ], - "ISM-0859": [ - "BCD-11", - "MON-08", - "MON-10", - "DCH-18" - ], - "ISM-0991": [ - "BCD-11", - "MON-08", - "MON-10", - "DCH-18" - ], "ISM-1511": [ "BCD-11" ], @@ -2440,6 +2895,16 @@ "ISM-1515": [ "BCD-11.1" ], + "ISM-1812": [ + "BCD-11.9" + ], + "ISM-1813": [ + "BCD-11.9" + ], + "ISM-1814": [ + "BCD-11.9", + "BCD-11.10" + ], "ISM-1789": [ "BCD-15", "TPM-03", @@ -2468,6 +2933,10 @@ "CHG-01", "CHG-02" ], + "ISM-1823": [ + "CHG-04", + "CFG-02" + ], "ISM-1796": [ "CHG-04.2", "TDA-01.1" @@ -2513,6 +2982,10 @@ "IAO-02.2", "IAO-02.3" ], + "ISM-0912": [ + "CFG-01", + "IAO-03" + ], "ISM-0341": [ "CFG-02", "DCH-10" @@ -2615,94 +3088,305 @@ "ISM-1745": [ "CFG-02" ], - "ISM-1588": [ - "CFG-02.1" + "ISM-1824": [ + "CFG-02" ], - "ISM-1510": [ - "CFG-02.3", - "DCH-18" + "ISM-1825": [ + "CFG-02" ], - "ISM-0534": [ - "CFG-02.5" + "ISM-1828": [ + "CFG-02" ], - "ISM-1656": [ - "CFG-02.5" + "ISM-1829": [ + "CFG-02" ], - "ISM-1657": [ - "CFG-02.5" + "ISM-1830": [ + "CFG-02" ], - "ISM-1658": [ - "CFG-02.5" + "ISM-1836": [ + "CFG-02" ], - "ISM-1659": [ - "CFG-02.5" + "ISM-1838": [ + "CFG-02" ], - "ISM-1667": [ - "CFG-02.5" + "ISM-1839": [ + "CFG-02" ], - "ISM-1668": [ - "CFG-02.5" + "ISM-1840": [ + "CFG-02" ], - "ISM-1669": [ - "CFG-02.5" + "ISM-1841": [ + "CFG-02" ], - "ISM-1670": [ - "CFG-02.5" + "ISM-1844": [ + "CFG-02" ], - "ISM-1671": [ - "CFG-02.5" + "ISM-1846": [ + "CFG-02" ], - "ISM-1672": [ - "CFG-02.5" + "ISM-1858": [ + "CFG-02" ], - "ISM-1673": [ - "CFG-02.5" + "ISM-1859": [ + "CFG-02" ], - "ISM-1674": [ - "CFG-02.5" + "ISM-1860": [ + "CFG-02" ], - "ISM-1675": [ - "CFG-02.5" + "ISM-1861": [ + "CFG-02" ], - "ISM-1676": [ - "CFG-02.5" + "ISM-1870": [ + "CFG-02" ], - "ISM-1677": [ - "CFG-02.5" + "ISM-1871": [ + "CFG-02" ], - "ISM-1748": [ - "CFG-02.5" + "ISM-1886": [ + "CFG-02" ], - "ISM-1749": [ - "CFG-02.5", - "IAC-10.5" + "ISM-1887": [ + "CFG-02" ], - "ISM-1800": [ - "CFG-02.5" + "ISM-1888": [ + "CFG-02" ], - "ISM-0385": [ - "CFG-03" + "ISM-1890": [ + "CFG-02" ], - "ISM-1006": [ - "CFG-03", - "END-16" + "ISM-1891": [ + "CFG-02" ], - "ISM-1311": [ - "CFG-03" + "ISM-1896": [ + "CFG-02" ], - "ISM-1312": [ - "CFG-03" + "ISM-1897": [ + "CFG-02" ], - "ISM-1392": [ - "CFG-03", - "CFG-06", - "CFG-06.1", - "IAC-21" + "ISM-1913": [ + "CFG-02" ], - "ISM-1479": [ - "CFG-03" + "ISM-1914": [ + "CFG-02" ], - "ISM-1487": [ + "ISM-1915": [ + "CFG-02" + ], + "ISM-1916": [ + "CFG-02" + ], + "ISM-1928": [ + "CFG-02" + ], + "ISM-1929": [ + "CFG-02" + ], + "ISM-1930": [ + "CFG-02" + ], + "ISM-1931": [ + "CFG-02" + ], + "ISM-1932": [ + "CFG-02" + ], + "ISM-1933": [ + "CFG-02" + ], + "ISM-1934": [ + "CFG-02" + ], + "ISM-1935": [ + "CFG-02" + ], + "ISM-1936": [ + "CFG-02" + ], + "ISM-1938": [ + "CFG-02" + ], + "ISM-1943": [ + "CFG-02" + ], + "ISM-1944": [ + "CFG-02" + ], + "ISM-1945": [ + "CFG-02" + ], + "ISM-1946": [ + "CFG-02" + ], + "ISM-1947": [ + "CFG-02" + ], + "ISM-1948": [ + "CFG-02" + ], + "ISM-1949": [ + "CFG-02" + ], + "ISM-1950": [ + "CFG-02" + ], + "ISM-1951": [ + "CFG-02" + ], + "ISM-1952": [ + "CFG-02" + ], + "ISM-1953": [ + "CFG-02" + ], + "ISM-1954": [ + "CFG-02" + ], + "ISM-1955": [ + "CFG-02" + ], + "ISM-1956": [ + "CFG-02" + ], + "ISM-1957": [ + "CFG-02" + ], + "ISM-1958": [ + "CFG-02" + ], + "ISM-1962": [ + "CFG-02" + ], + "ISM-1980": [ + "CFG-02", + "IAC-10.1" + ], + "ISM-1984": [ + "CFG-02" + ], + "ISM-2010": [ + "CFG-02" + ], + "ISM-2012": [ + "CFG-02" + ], + "ISM-2047": [ + "CFG-02" + ], + "ISM-2049": [ + "CFG-02" + ], + "ISM-2079": [ + "CFG-02", + "IAC-10.1" + ], + "ISM-2080": [ + "CFG-02", + "IAC-10.1" + ], + "ISM-2081": [ + "CFG-02", + "IAC-10.1" + ], + "ISM-2096": [ + "CFG-02" + ], + "ISM-2097": [ + "CFG-02" + ], + "ISM-2098": [ + "CFG-02" + ], + "ISM-1588": [ + "CFG-02.1" + ], + "ISM-1510": [ + "CFG-02.3", + "DCH-18" + ], + "ISM-0534": [ + "CFG-02.5" + ], + "ISM-1656": [ + "CFG-02.5" + ], + "ISM-1657": [ + "CFG-02.5" + ], + "ISM-1658": [ + "CFG-02.5" + ], + "ISM-1659": [ + "CFG-02.5" + ], + "ISM-1667": [ + "CFG-02.5" + ], + "ISM-1668": [ + "CFG-02.5" + ], + "ISM-1669": [ + "CFG-02.5" + ], + "ISM-1670": [ + "CFG-02.5" + ], + "ISM-1671": [ + "CFG-02.5" + ], + "ISM-1672": [ + "CFG-02.5" + ], + "ISM-1673": [ + "CFG-02.5" + ], + "ISM-1674": [ + "CFG-02.5" + ], + "ISM-1675": [ + "CFG-02.5" + ], + "ISM-1676": [ + "CFG-02.5" + ], + "ISM-1748": [ + "CFG-02.5" + ], + "ISM-1749": [ + "CFG-02.5", + "IAC-10.5" + ], + "ISM-1800": [ + "CFG-02.5" + ], + "ISM-1867": [ + "CFG-02.5" + ], + "ISM-1868": [ + "CFG-02.5" + ], + "ISM-0385": [ + "CFG-03" + ], + "ISM-1006": [ + "CFG-03", + "END-16" + ], + "ISM-1311": [ + "CFG-03" + ], + "ISM-1312": [ + "CFG-03" + ], + "ISM-1392": [ + "CFG-03", + "CFG-06", + "CFG-06.1", + "IAC-21" + ], + "ISM-1479": [ + "CFG-03" + ], + "ISM-1487": [ "CFG-03" ], "ISM-1488": [ @@ -2788,6 +3472,24 @@ "CFG-06", "CFG-06.1" ], + "ISM-2023": [ + "CFG-09" + ], + "ISM-2029": [ + "CFG-09.1" + ], + "ISM-2026": [ + "CFG-09.2" + ], + "ISM-2027": [ + "CFG-09.2" + ], + "ISM-2030": [ + "CFG-09.2" + ], + "ISM-2024": [ + "CFG-09.3" + ], "ISM-0109": [ "MON-01", "MON-01.8", @@ -2823,6 +3525,18 @@ "MON-01", "MON-01.16" ], + "ISM-1906": [ + "MON-01.3" + ], + "ISM-1907": [ + "MON-01.3" + ], + "ISM-2015": [ + "MON-01.3" + ], + "ISM-1959": [ + "MON-01.4" + ], "ISM-0261": [ "MON-01.9" ], @@ -2852,6 +3566,42 @@ "MON-16.4", "IAC-16" ], + "ISM-1911": [ + "MON-02" + ], + "ISM-1960": [ + "MON-02" + ], + "ISM-1963": [ + "MON-02" + ], + "ISM-1976": [ + "MON-02" + ], + "ISM-1977": [ + "MON-02" + ], + "ISM-1978": [ + "MON-02" + ], + "ISM-1979": [ + "MON-02" + ], + "ISM-1983": [ + "MON-02" + ], + "ISM-1986": [ + "MON-02" + ], + "ISM-1987": [ + "MON-02" + ], + "ISM-1961": [ + "MON-02.1" + ], + "ISM-1964": [ + "MON-02.1" + ], "ISM-0988": [ "MON-02.7", "SEA-20" @@ -2862,18 +3612,42 @@ "ISM-0585": [ "MON-03" ], + "ISM-1895": [ + "MON-03" + ], + "ISM-2051": [ + "MON-03" + ], + "ISM-2052": [ + "MON-03.1" + ], "ISM-0407": [ "MON-03.2", "IAC-01.1" ], + "ISM-1889": [ + "MON-03.3" + ], "ISM-1660": [ "MON-06", "MON-16" ], + "ISM-1815": [ + "MON-08" + ], + "ISM-1985": [ + "MON-08.2" + ], "ISM-1213": [ "MON-10", "IRO-13" ], + "ISM-1988": [ + "MON-10" + ], + "ISM-1989": [ + "MON-10" + ], "ISM-1091": [ "MON-11.3", "CRY-01" @@ -2942,6 +3716,9 @@ "SAT-02", "SAT-03" ], + "ISM-1233": [ + "CRY-01" + ], "ISM-1446": [ "CRY-01" ], @@ -2994,10 +3771,6 @@ "ISM-0232": [ "CRY-03" ], - "ISM-0241": [ - "CRY-03", - "HRS-05.2" - ], "ISM-0465": [ "CRY-03" ], @@ -3073,6 +3846,9 @@ "ISM-1449": [ "CRY-08" ], + "ISM-2050": [ + "CRY-08" + ], "ISM-0455": [ "CRY-09", "CRY-09.3" @@ -3292,6 +4068,9 @@ "DCH-17", "NET-08.4" ], + "ISM-2021": [ + "DCH-18.1" + ], "ISM-1284": [ "END-04", "END-04.4", @@ -3325,6 +4104,9 @@ "END-04", "END-04.4" ], + "ISM-1969": [ + "END-04" + ], "ISM-1782": [ "END-04.4", "NET-10" @@ -3338,6 +4120,13 @@ "ISM-1341": [ "END-07" ], + "ISM-2035": [ + "HRS-03", + "TDA-06" + ], + "ISM-2036": [ + "HRS-03" + ], "ISM-0434": [ "HRS-04" ], @@ -3370,12 +4159,23 @@ "ISM-0258": [ "HRS-05" ], + "ISM-1865": [ + "HRS-05" + ], "ISM-0820": [ "HRS-05.1" ], "ISM-0821": [ "HRS-05.1" ], + "ISM-1864": [ + "HRS-05.1" + ], + "ISM-2095": [ + "HRS-05.1", + "HRS-05.3", + "HRS-05.4" + ], "ISM-0229": [ "HRS-05.2", "HRS-05.5" @@ -3409,15 +4209,9 @@ "ISM-0931": [ "HRS-05.2" ], - "ISM-1075": [ - "HRS-05.2" - ], "ISM-1078": [ "HRS-05.2" ], - "ISM-1092": [ - "HRS-05.2" - ], "ISM-1196": [ "HRS-05.2", "HRS-05.5" @@ -3430,6 +4224,22 @@ "HRS-05.2", "PES-12" ], + "ISM-1866": [ + "HRS-05.3", + "HRS-05.5" + ], + "ISM-2075": [ + "HRS-05.3" + ], + "ISM-2099": [ + "HRS-05.3" + ], + "ISM-2100": [ + "HRS-05.3" + ], + "ISM-2101": [ + "HRS-05.3" + ], "ISM-0701": [ "HRS-05.5" ], @@ -3473,6 +4283,18 @@ "IAC-01", "IAC-02" ], + "ISM-2076": [ + "IAC-01" + ], + "ISM-2077": [ + "IAC-01" + ], + "ISM-2013": [ + "IAC-01.2" + ], + "ISM-2014": [ + "IAC-01.2" + ], "ISM-0414": [ "IAC-02" ], @@ -3535,9 +4357,36 @@ "ISM-1685": [ "IAC-06" ], + "ISM-1872": [ + "IAC-06" + ], + "ISM-1873": [ + "IAC-06" + ], + "ISM-1874": [ + "IAC-06" + ], + "ISM-1892": [ + "IAC-06" + ], + "ISM-1893": [ + "IAC-06" + ], + "ISM-1894": [ + "IAC-06" + ], + "ISM-2011": [ + "IAC-06" + ], "ISM-1746": [ "IAC-08" ], + "ISM-1852": [ + "IAC-08" + ], + "ISM-2093": [ + "IAC-08" + ], "ISM-1227": [ "IAC-10" ], @@ -3573,6 +4422,9 @@ "ISM-1795": [ "IAC-10.1" ], + "ISM-2078": [ + "IAC-10.4" + ], "ISM-0418": [ "IAC-10.5" ], @@ -3594,6 +4446,10 @@ "ISM-1806": [ "IAC-10.8" ], + "ISM-2044": [ + "IAC-10.8", + "TDA-09.6" + ], "ISM-0441": [ "IAC-15", "IAC-21" @@ -3601,6 +4457,24 @@ "ISM-0443": [ "IAC-15" ], + "ISM-1832": [ + "IAC-15" + ], + "ISM-1834": [ + "IAC-15" + ], + "ISM-1845": [ + "IAC-15" + ], + "ISM-1940": [ + "IAC-15" + ], + "ISM-1941": [ + "IAC-15" + ], + "ISM-1942": [ + "IAC-15" + ], "ISM-1649": [ "IAC-15.1", "IAC-16" @@ -3665,11 +4539,23 @@ "ISM-1689": [ "IAC-16" ], + "ISM-1835": [ + "IAC-16" + ], + "ISM-1939": [ + "IAC-16" + ], + "ISM-1827": [ + "IAC-16.4" + ], + "ISM-1842": [ + "IAC-16.4" + ], "ISM-1647": [ "IAC-17" ], - "ISM-1716": [ - "IAC-17" + "ISM-1898": [ + "IAC-20.4" ], "ISM-0611": [ "IAC-21", @@ -3687,6 +4573,15 @@ "ISM-1708": [ "IAC-21" ], + "ISM-1833": [ + "IAC-21" + ], + "ISM-1883": [ + "IAC-21.2" + ], + "ISM-2048": [ + "IAC-21.5" + ], "ISM-1403": [ "IAC-22" ], @@ -3732,6 +4627,9 @@ "IRO-02", "IRO-09" ], + "ISM-1819": [ + "IRO-02" + ], "ISM-1626": [ "IRO-02.2", "THR-04", @@ -3758,6 +4656,12 @@ "ISM-0125": [ "IRO-09" ], + "ISM-1880": [ + "IRO-10" + ], + "ISM-1881": [ + "IRO-10" + ], "ISM-1569": [ "IRO-10.4", "TPM-04", @@ -3777,6 +4681,9 @@ "IRO-15", "NET-03" ], + "ISM-1970": [ + "IRO-15" + ], "ISM-0280": [ "IAO-01" ], @@ -3784,12 +4691,24 @@ "IAO-01", "IAO-07" ], + "ISM-1967": [ + "IAO-02" + ], + "ISM-1971": [ + "IAO-02" + ], + "ISM-1972": [ + "IAO-02" + ], "ISM-1137": [ "IAO-02.2" ], "ISM-1570": [ "IAO-02.2" ], + "ISM-2019": [ + "IAO-02.2" + ], "ISM-1563": [ "IAO-02.4" ], @@ -3799,6 +4718,9 @@ "ISM-0432": [ "IAO-03" ], + "ISM-1912": [ + "IAO-03" + ], "ISM-0072": [ "IAO-03.2", "TPM-05" @@ -3827,14 +4749,14 @@ "ISM-1564": [ "IAO-05" ], + "ISM-1968": [ + "IAO-07" + ], "ISM-0305": [ "MNT-01", "MNT-06", "MNT-08" ], - "ISM-1226": [ - "MNT-01" - ], "ISM-1079": [ "MNT-02" ], @@ -4023,6 +4945,9 @@ "ISM-1386": [ "NET-04" ], + "ISM-2068": [ + "NET-04.1" + ], "ISM-1181": [ "NET-06" ], @@ -4044,6 +4969,9 @@ "ISM-1532": [ "NET-06.2" ], + "ISM-1863": [ + "NET-06.5" + ], "ISM-1028": [ "NET-08" ], @@ -4092,6 +5020,9 @@ "NET-10", "NET-10.3" ], + "ISM-2017": [ + "NET-10" + ], "ISM-1432": [ "NET-10.4" ], @@ -4153,9 +5084,6 @@ "ISM-0225": [ "NET-15" ], - "ISM-0248": [ - "NET-15" - ], "ISM-1315": [ "NET-15" ], @@ -4235,6 +5163,9 @@ "ISM-1524": [ "NET-18" ], + "ISM-1965": [ + "NET-18" + ], "ISM-0260": [ "NET-18.1" ], @@ -4393,6 +5324,15 @@ "PES-12.1", "PES-16" ], + "ISM-1820": [ + "PES-12.1" + ], + "ISM-1821": [ + "PES-12.1" + ], + "ISM-1822": [ + "PES-12.1" + ], "ISM-0246": [ "PES-13" ], @@ -4405,6 +5345,13 @@ "ISM-0039": [ "PRM-01.1" ], + "ISM-2004": [ + "PRM-02" + ], + "ISM-2020": [ + "PRM-02.1", + "PRM-03" + ], "ISM-1739": [ "PRM-04", "PRM-05", @@ -4413,6 +5360,46 @@ "SEA-02", "SEA-03" ], + "ISM-1917": [ + "QTS-03" + ], + "ISM-2073": [ + "QTS-03" + ], + "ISM-2082": [ + "QTS-04.2" + ], + "ISM-2083": [ + "QTS-04.2" + ], + "ISM-1990": [ + "QTS-06.3" + ], + "ISM-1991": [ + "QTS-06.3" + ], + "ISM-1992": [ + "QTS-06.3" + ], + "ISM-1993": [ + "QTS-06.3" + ], + "ISM-1994": [ + "QTS-06.3" + ], + "ISM-1995": [ + "QTS-06.3" + ], + "ISM-1996": [ + "QTS-06.9" + ], + "ISM-1203": [ + "RSK-04", + "THR-10" + ], + "ISM-0009": [ + "RSK-06.2" + ], "ISM-1809": [ "RSK-06.2" ], @@ -4433,6 +5420,12 @@ "SEA-03", "TPM-03.1" ], + "ISM-1926": [ + "SEA-01" + ], + "ISM-1927": [ + "SEA-01" + ], "ISM-1460": [ "SEA-13.1", "VPM-01" @@ -4458,6 +5451,9 @@ "SAT-01", "SAT-02" ], + "ISM-2022": [ + "SAT-01" + ], "ISM-1740": [ "SAT-02", "SAT-03", @@ -4467,6 +5463,9 @@ "SAT-02.2", "SAT-03.2" ], + "ISM-2071": [ + "SAT-02.2" + ], "ISM-1565": [ "SAT-03", "SAT-03.5" @@ -4490,6 +5489,18 @@ "ISM-1730": [ "TDA-04.2" ], + "ISM-2054": [ + "TDA-04.2" + ], + "ISM-2056": [ + "TDA-04.2" + ], + "ISM-2033": [ + "TDA-05" + ], + "ISM-2043": [ + "TDA-05" + ], "ISM-0401": [ "TDA-06" ], @@ -4506,9 +5517,61 @@ "TDA-06", "WEB-10" ], + "ISM-1849": [ + "TDA-06" + ], + "ISM-1922": [ + "TDA-06" + ], + "ISM-2032": [ + "TDA-06" + ], + "ISM-2041": [ + "TDA-06", + "TDA-06.7" + ], + "ISM-2045": [ + "TDA-06" + ], + "ISM-2063": [ + "TDA-06" + ], + "ISM-2064": [ + "TDA-06" + ], + "ISM-2065": [ + "TDA-06" + ], + "ISM-2066": [ + "TDA-06" + ], + "ISM-2067": [ + "TDA-06" + ], "ISM-1238": [ "TDA-06.2" ], + "ISM-2039": [ + "TDA-06.2" + ], + "ISM-2025": [ + "TDA-06.3" + ], + "ISM-2034": [ + "TDA-06.3" + ], + "ISM-2102": [ + "TDA-06.3" + ], + "ISM-2031": [ + "TDA-06.4" + ], + "ISM-1909": [ + "TDA-06.6" + ], + "ISM-2040": [ + "TDA-06.7" + ], "ISM-0400": [ "TDA-07", "TDA-08" @@ -4524,9 +5587,41 @@ "ISM-1754": [ "TDA-09" ], + "ISM-1850": [ + "TDA-09" + ], + "ISM-1851": [ + "TDA-09" + ], + "ISM-2057": [ + "TDA-09", + "TDA-09.4" + ], + "ISM-2060": [ + "TDA-09" + ], + "ISM-2061": [ + "TDA-09" + ], + "ISM-2062": [ + "TDA-09" + ], + "ISM-2028": [ + "TDA-09.2", + "TDA-09.3" + ], + "ISM-2042": [ + "TDA-09.6" + ], "ISM-1420": [ "TDA-10" ], + "ISM-2038": [ + "TDA-13.1" + ], + "ISM-2037": [ + "TDA-13.2" + ], "ISM-0304": [ "TDA-17" ], @@ -4539,6 +5634,18 @@ "ISM-1753": [ "TDA-17" ], + "ISM-1848": [ + "TDA-17" + ], + "ISM-1981": [ + "TDA-17" + ], + "ISM-1982": [ + "TDA-17" + ], + "ISM-2059": [ + "TDA-18" + ], "ISM-1422": [ "TDA-20" ], @@ -4577,6 +5684,9 @@ "ISM-1787": [ "TPM-04.1" ], + "ISM-1882": [ + "TPM-04.1" + ], "ISM-1395": [ "TPM-05" ], @@ -4608,10 +5718,22 @@ "ISM-1756": [ "THR-06" ], + "ISM-1921": [ + "THR-07" + ], "ISM-1143": [ "VPM-01", "VPM-05" ], + "ISM-1902": [ + "VPM-02" + ], + "ISM-1903": [ + "VPM-02" + ], + "ISM-1904": [ + "VPM-02" + ], "ISM-1801": [ "VPM-04" ], @@ -4649,6 +5771,21 @@ "ISM-1751": [ "VPM-05" ], + "ISM-1876": [ + "VPM-05" + ], + "ISM-1877": [ + "VPM-05" + ], + "ISM-1878": [ + "VPM-05" + ], + "ISM-1879": [ + "VPM-05" + ], + "ISM-1901": [ + "VPM-05" + ], "ISM-0298": [ "VPM-05.1" ], @@ -4676,9 +5813,18 @@ "ISM-1752": [ "VPM-06" ], + "ISM-1875": [ + "VPM-06" + ], + "ISM-1900": [ + "VPM-06" + ], "ISM-1808": [ "VPM-06.1" ], + "ISM-1862": [ + "WEB-03" + ], "ISM-0971": [ "WEB-07" ], diff --git a/docs/api/crosswalks/apac-aus-privacy-act-1998.json b/docs/api/crosswalks/apac-aus-privacy-act-1998.json deleted file mode 100644 index b21b5c83..00000000 --- a/docs/api/crosswalks/apac-aus-privacy-act-1998.json +++ /dev/null @@ -1,144 +0,0 @@ -{ - "framework_id": "apac-aus-privacy-act-1998", - "display_name": "Australia - Privacy Act of 1998", - "scf_to_framework": { - "total_mappings": 23, - "mappings": { - "GOV-01": [ - "APP Part 1", - "APP Part 11" - ], - "CPL-01": [ - "APP Part 11" - ], - "CPL-02": [ - "APP Part 11" - ], - "DCH-01": [ - "APP Part 8", - "APP Part 11" - ], - "DCH-22.1": [ - "APP Part 13" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-02": [ - "APP Part 5" - ], - "PRI-02.1": [ - "APP Part 3" - ], - "PRI-03": [ - "APP Part 3" - ], - "PRI-04": [ - "APP Part 3" - ], - "PRI-04.1": [ - "APP Part 3" - ], - "PRI-05": [ - "APP Part 3", - "APP Part 6" - ], - "PRI-05.1": [ - "APP Part 3" - ], - "PRI-05.2": [ - "APP Part 10" - ], - "PRI-05.3": [ - "APP Part 2" - ], - "PRI-05.4": [ - "APP Part 3" - ], - "PRI-06": [ - "APP Part 12" - ], - "PRI-06.1": [ - "APP Part 13" - ], - "PRI-06.2": [ - "APP Part 13" - ], - "PRI-06.4": [ - "APP Part 13" - ], - "SEA-01": [ - "APP Part 8", - "APP Part 11" - ], - "SEA-02": [ - "APP Part 8", - "APP Part 11" - ], - "SEA-03": [ - "APP Part 8", - "APP Part 11" - ] - } - }, - "framework_to_scf": { - "total_mappings": 12, - "mappings": { - "APP Part 1": [ - "GOV-01" - ], - "APP Part 11": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "APP Part 8": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "APP Part 13": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2", - "PRI-06.4" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ], - "APP Part 5": [ - "PRI-02" - ], - "APP Part 3": [ - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.4" - ], - "APP Part 6": [ - "PRI-05" - ], - "APP Part 10": [ - "PRI-05.2" - ], - "APP Part 2": [ - "PRI-05.3" - ], - "APP Part 12": [ - "PRI-06" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/apac-aus-privacy-principles-2026.json b/docs/api/crosswalks/apac-aus-privacy-principles-2026.json index c290c479..7b537480 100644 --- a/docs/api/crosswalks/apac-aus-privacy-principles-2026.json +++ b/docs/api/crosswalks/apac-aus-privacy-principles-2026.json @@ -2,156 +2,888 @@ "framework_id": "apac-aus-privacy-principles-2026", "display_name": "Australia - Privacy Principles (2026)", "scf_to_framework": { - "total_mappings": 26, + "total_mappings": 24, "mappings": { "GOV-02": [ - "APP 1" + "1.1.3" + ], + "CPL-01": [ + "1.1.2.a" + ], + "CPL-07": [ + "1.1.2.b" + ], + "DCH-03.1": [ + "3.9.2", + "3.9.2.a", + "3.9.2.b", + "3.9.2.c", + "3.9.2.d", + "3.9.2.e", + "3.9.2.f", + "3.9.3", + "3.9.3.a", + "3.9.3.b", + "3.9.3.c" + ], + "PRI-01.5": [ + "3.8.1", + "3.8.1.a", + "3.8.1.b", + "3.8.2", + "3.8.2.a", + "3.8.2.a.i", + "3.8.2.a.ii", + "3.8.2.b", + "3.8.2.b.i", + "3.8.2.b.ii", + "3.8.2.c", + "3.8.2.d", + "3.8.2.e", + "3.8.2.f", + "3.8.2.f.i", + "3.8.2.f.ii" + ], + "PRI-01.6": [ + "4.11.1", + "4.11.1.a", + "4.11.1.b" + ], + "PRI-01.7": [ + "3.6.1" + ], + "PRI-01.11": [ + "1.1.2", + "2.3.1", + "2.3.2", + "2.3.5", + "2.3.7", + "2.4.1", + "2.4.1.a", + "2.4.1.b", + "2.4.2", + "2.4.3", + "2.4.3.a", + "2.4.3.b", + "2.4.4", + "3.9.1", + "3.9.1.a", + "3.9.1.b", + "5.12.7", + "5.12.8", + "5.12.8.a", + "5.12.8.b" ], - "CLD-09": [ - "APP 8" + "PRI-02": [ + "1.1.3", + "1.1.4", + "1.1.4.a", + "1.1.4.b", + "1.1.4.c", + "1.1.4.d", + "1.1.4.e", + "1.1.4.f", + "1.1.4.g", + "1.1.5", + "1.1.5.a", + "1.1.5.b", + "1.1.6", + "2.5.1", + "2.5.1.a", + "2.5.1.b", + "2.5.2", + "2.5.2.a", + "2.5.2.b", + "2.5.2.b.i", + "2.5.2.b.ii", + "2.5.2.c", + "2.5.2.d", + "2.5.2.e", + "2.5.2.f", + "2.5.2.g", + "2.5.2.h", + "2.5.2.i", + "2.5.2.j" + ], + "PRI-02.13": [ + "1.2.1" ], - "DCH-01": [ - "APP 11" + "PRI-04.1": [ + "2.3.1", + "2.3.2" ], - "DCH-19": [ - "APP 8" + "PRI-04.2": [ + "2.3.6", + "2.3.6.a", + "2.3.6.a.ii", + "2.3.6.b" ], - "DCH-22.1": [ - "APP 13" + "PRI-05": [ + "4.11.2", + "4.11.2.a", + "4.11.2.b", + "4.11.2.c", + "4.11.2.d" ], - "IAC-09.6": [ - "APP 2" + "PRI-05.2": [ + "4.10.1", + "4.10.2" ], - "PRI-01": [ - "APP 1" + "PRI-05.4": [ + "2.3.3", + "2.3.3.a", + "2.3.3.a.i", + "2.3.3.a.ii", + "2.3.3.b", + "2.3.4", + "2.3.4.a", + "2.3.4.b", + "2.3.4.c", + "2.3.4.d", + "2.3.4.d.i", + "2.3.4.d.ii", + "2.3.4.e", + "2.3.4.e.i", + "2.3.4.e.ii", + "3.6.1", + "3.6.1.a", + "3.6.1.b", + "3.6.2", + "3.6.2.a", + "3.6.2.a.i", + "3.6.2.a.ii", + "3.6.2.b", + "3.6.2.c", + "3.6.2.d", + "3.6.2.e", + "3.6.3", + "3.6.4", + "3.6.4.a", + "3.6.4.b", + "3.7.1", + "3.7.2", + "3.7.2.a", + "3.7.2.b", + "3.7.2.c", + "3.7.2.d", + "3.7.3", + "3.7.3.a", + "3.7.3.a.i", + "3.7.3.a.ii", + "3.7.3.b", + "3.7.3.b.i", + "3.7.3.b.ii", + "3.7.3.c", + "3.7.3.d", + "3.7.3.d.i", + "3.7.3.d.ii", + "3.7.3.e", + "3.7.4", + "3.7.5", + "3.7.5.a", + "3.7.5.b", + "3.7.5.c" ], - "PRI-01.3": [ - "APP 1" + "PRI-06": [ + "3.7.6", + "3.7.6.a", + "3.7.6.b", + "3.7.6.c", + "3.7.6.d", + "3.7.6.e", + "3.7.7", + "3.7.7.a", + "3.7.7.b", + "5.12.1" ], - "PRI-02": [ - "APP 1", - "APP 5" + "PRI-06.1": [ + "5.13.1", + "5.13.1.a", + "5.13.1.b", + "5.13.1.b.i" ], - "PRI-02.1": [ - "APP 1" + "PRI-06.2": [ + "5.13.2", + "5.13.2.a", + "5.13.2.b", + "5.13.3", + "5.13.3.a", + "5.13.3.b", + "5.13.3.c" ], - "PRI-03": [ - "APP 3" + "PRI-06.4": [ + "5.12.3", + "5.12.3.a", + "5.12.3.b", + "5.12.3.c", + "5.12.3.d", + "5.12.3.e", + "5.12.3.f", + "5.12.3.g", + "5.12.3.h", + "5.12.3.h.ii", + "5.12.3.i", + "5.12.3.j", + "5.12.4", + "5.12.4.a", + "5.12.4.a.i", + "5.12.4.a.ii", + "5.12.4.b", + "5.12.5", + "5.12.5.a", + "5.12.5.b", + "5.12.6", + "5.13.4", + "5.13.4.a", + "5.13.5", + "5.13.5.a", + "5.13.5.a.i", + "5.13.5.a.ii", + "5.13.5.b" + ], + "PRI-06.8": [ + "1.2.2.a", + "1.2.2.b" + ], + "PRI-07.4": [ + "5.12.3.h.i" + ], + "PRI-12.1": [ + "5.13.1.b.ii" + ], + "PRI-14.2": [ + "3.6.5" + ], + "PRI-17": [ + "5.12.9", + "5.12.9.a", + "5.12.9.b", + "5.12.9.c", + "5.12.10" + ] + } + }, + "framework_to_scf": { + "total_mappings": 205, + "mappings": { + "1.1.3": [ + "GOV-02", + "PRI-02" ], - "PRI-03.2": [ - "APP 5" + "1.1.2.a": [ + "CPL-01" ], - "PRI-03.3": [ - "APP 7" + "1.1.2.b": [ + "CPL-07" ], - "PRI-04": [ - "APP 3" + "3.9.2": [ + "DCH-03.1" ], - "PRI-04.1": [ - "APP 3", - "APP 7" + "3.9.2.a": [ + "DCH-03.1" ], - "PRI-05": [ - "APP 4", - "APP 6" + "3.9.2.b": [ + "DCH-03.1" ], - "PRI-05.1": [ - "APP 6" + "3.9.2.c": [ + "DCH-03.1" ], - "PRI-05.2": [ - "APP 10" + "3.9.2.d": [ + "DCH-03.1" ], - "PRI-05.4": [ - "APP 6", - "APP 7", - "APP 9" + "3.9.2.e": [ + "DCH-03.1" ], - "PRI-05.7": [ - "APP 9" + "3.9.2.f": [ + "DCH-03.1" ], - "PRI-06": [ - "APP 12" + "3.9.3": [ + "DCH-03.1" ], - "PRI-06.1": [ - "APP 13" + "3.9.3.a": [ + "DCH-03.1" ], - "PRI-06.2": [ - "APP 13" + "3.9.3.b": [ + "DCH-03.1" ], - "PRI-06.4": [ - "APP 12", - "APP 13" + "3.9.3.c": [ + "DCH-03.1" ], - "PRI-07": [ - "APP 7", - "APP 8" + "3.8.1": [ + "PRI-01.5" ], - "PRI-07.1": [ - "APP 7" - ] - } - }, - "framework_to_scf": { - "total_mappings": 13, - "mappings": { - "APP 1": [ - "GOV-02", - "PRI-01", - "PRI-01.3", - "PRI-02", - "PRI-02.1" + "3.8.1.a": [ + "PRI-01.5" ], - "APP 8": [ - "CLD-09", - "DCH-19", - "PRI-07" + "3.8.1.b": [ + "PRI-01.5" ], - "APP 11": [ - "DCH-01" + "3.8.2": [ + "PRI-01.5" ], - "APP 13": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2", - "PRI-06.4" + "3.8.2.a": [ + "PRI-01.5" + ], + "3.8.2.a.i": [ + "PRI-01.5" + ], + "3.8.2.a.ii": [ + "PRI-01.5" + ], + "3.8.2.b": [ + "PRI-01.5" + ], + "3.8.2.b.i": [ + "PRI-01.5" + ], + "3.8.2.b.ii": [ + "PRI-01.5" + ], + "3.8.2.c": [ + "PRI-01.5" ], - "APP 2": [ - "IAC-09.6" + "3.8.2.d": [ + "PRI-01.5" ], - "APP 5": [ - "PRI-02", - "PRI-03.2" + "3.8.2.e": [ + "PRI-01.5" ], - "APP 3": [ - "PRI-03", - "PRI-04", + "3.8.2.f": [ + "PRI-01.5" + ], + "3.8.2.f.i": [ + "PRI-01.5" + ], + "3.8.2.f.ii": [ + "PRI-01.5" + ], + "4.11.1": [ + "PRI-01.6" + ], + "4.11.1.a": [ + "PRI-01.6" + ], + "4.11.1.b": [ + "PRI-01.6" + ], + "3.6.1": [ + "PRI-01.7", + "PRI-05.4" + ], + "1.1.2": [ + "PRI-01.11" + ], + "2.3.1": [ + "PRI-01.11", "PRI-04.1" ], - "APP 7": [ - "PRI-03.3", - "PRI-04.1", - "PRI-05.4", - "PRI-07", - "PRI-07.1" + "2.3.2": [ + "PRI-01.11", + "PRI-04.1" + ], + "2.3.5": [ + "PRI-01.11" + ], + "2.3.7": [ + "PRI-01.11" + ], + "2.4.1": [ + "PRI-01.11" + ], + "2.4.1.a": [ + "PRI-01.11" + ], + "2.4.1.b": [ + "PRI-01.11" + ], + "2.4.2": [ + "PRI-01.11" + ], + "2.4.3": [ + "PRI-01.11" + ], + "2.4.3.a": [ + "PRI-01.11" + ], + "2.4.3.b": [ + "PRI-01.11" + ], + "2.4.4": [ + "PRI-01.11" + ], + "3.9.1": [ + "PRI-01.11" + ], + "3.9.1.a": [ + "PRI-01.11" + ], + "3.9.1.b": [ + "PRI-01.11" + ], + "5.12.7": [ + "PRI-01.11" + ], + "5.12.8": [ + "PRI-01.11" + ], + "5.12.8.a": [ + "PRI-01.11" + ], + "5.12.8.b": [ + "PRI-01.11" + ], + "1.1.4": [ + "PRI-02" + ], + "1.1.4.a": [ + "PRI-02" + ], + "1.1.4.b": [ + "PRI-02" + ], + "1.1.4.c": [ + "PRI-02" + ], + "1.1.4.d": [ + "PRI-02" + ], + "1.1.4.e": [ + "PRI-02" + ], + "1.1.4.f": [ + "PRI-02" + ], + "1.1.4.g": [ + "PRI-02" + ], + "1.1.5": [ + "PRI-02" + ], + "1.1.5.a": [ + "PRI-02" ], - "APP 4": [ + "1.1.5.b": [ + "PRI-02" + ], + "1.1.6": [ + "PRI-02" + ], + "2.5.1": [ + "PRI-02" + ], + "2.5.1.a": [ + "PRI-02" + ], + "2.5.1.b": [ + "PRI-02" + ], + "2.5.2": [ + "PRI-02" + ], + "2.5.2.a": [ + "PRI-02" + ], + "2.5.2.b": [ + "PRI-02" + ], + "2.5.2.b.i": [ + "PRI-02" + ], + "2.5.2.b.ii": [ + "PRI-02" + ], + "2.5.2.c": [ + "PRI-02" + ], + "2.5.2.d": [ + "PRI-02" + ], + "2.5.2.e": [ + "PRI-02" + ], + "2.5.2.f": [ + "PRI-02" + ], + "2.5.2.g": [ + "PRI-02" + ], + "2.5.2.h": [ + "PRI-02" + ], + "2.5.2.i": [ + "PRI-02" + ], + "2.5.2.j": [ + "PRI-02" + ], + "1.2.1": [ + "PRI-02.13" + ], + "2.3.6": [ + "PRI-04.2" + ], + "2.3.6.a": [ + "PRI-04.2" + ], + "2.3.6.a.ii": [ + "PRI-04.2" + ], + "2.3.6.b": [ + "PRI-04.2" + ], + "4.11.2": [ "PRI-05" ], - "APP 6": [ - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "4.11.2.a": [ + "PRI-05" + ], + "4.11.2.b": [ + "PRI-05" + ], + "4.11.2.c": [ + "PRI-05" + ], + "4.11.2.d": [ + "PRI-05" + ], + "4.10.1": [ + "PRI-05.2" ], - "APP 10": [ + "4.10.2": [ "PRI-05.2" ], - "APP 9": [ - "PRI-05.4", - "PRI-05.7" + "2.3.3": [ + "PRI-05.4" + ], + "2.3.3.a": [ + "PRI-05.4" + ], + "2.3.3.a.i": [ + "PRI-05.4" + ], + "2.3.3.a.ii": [ + "PRI-05.4" + ], + "2.3.3.b": [ + "PRI-05.4" + ], + "2.3.4": [ + "PRI-05.4" + ], + "2.3.4.a": [ + "PRI-05.4" + ], + "2.3.4.b": [ + "PRI-05.4" + ], + "2.3.4.c": [ + "PRI-05.4" + ], + "2.3.4.d": [ + "PRI-05.4" + ], + "2.3.4.d.i": [ + "PRI-05.4" + ], + "2.3.4.d.ii": [ + "PRI-05.4" + ], + "2.3.4.e": [ + "PRI-05.4" + ], + "2.3.4.e.i": [ + "PRI-05.4" + ], + "2.3.4.e.ii": [ + "PRI-05.4" + ], + "3.6.1.a": [ + "PRI-05.4" + ], + "3.6.1.b": [ + "PRI-05.4" + ], + "3.6.2": [ + "PRI-05.4" + ], + "3.6.2.a": [ + "PRI-05.4" + ], + "3.6.2.a.i": [ + "PRI-05.4" + ], + "3.6.2.a.ii": [ + "PRI-05.4" ], - "APP 12": [ - "PRI-06", + "3.6.2.b": [ + "PRI-05.4" + ], + "3.6.2.c": [ + "PRI-05.4" + ], + "3.6.2.d": [ + "PRI-05.4" + ], + "3.6.2.e": [ + "PRI-05.4" + ], + "3.6.3": [ + "PRI-05.4" + ], + "3.6.4": [ + "PRI-05.4" + ], + "3.6.4.a": [ + "PRI-05.4" + ], + "3.6.4.b": [ + "PRI-05.4" + ], + "3.7.1": [ + "PRI-05.4" + ], + "3.7.2": [ + "PRI-05.4" + ], + "3.7.2.a": [ + "PRI-05.4" + ], + "3.7.2.b": [ + "PRI-05.4" + ], + "3.7.2.c": [ + "PRI-05.4" + ], + "3.7.2.d": [ + "PRI-05.4" + ], + "3.7.3": [ + "PRI-05.4" + ], + "3.7.3.a": [ + "PRI-05.4" + ], + "3.7.3.a.i": [ + "PRI-05.4" + ], + "3.7.3.a.ii": [ + "PRI-05.4" + ], + "3.7.3.b": [ + "PRI-05.4" + ], + "3.7.3.b.i": [ + "PRI-05.4" + ], + "3.7.3.b.ii": [ + "PRI-05.4" + ], + "3.7.3.c": [ + "PRI-05.4" + ], + "3.7.3.d": [ + "PRI-05.4" + ], + "3.7.3.d.i": [ + "PRI-05.4" + ], + "3.7.3.d.ii": [ + "PRI-05.4" + ], + "3.7.3.e": [ + "PRI-05.4" + ], + "3.7.4": [ + "PRI-05.4" + ], + "3.7.5": [ + "PRI-05.4" + ], + "3.7.5.a": [ + "PRI-05.4" + ], + "3.7.5.b": [ + "PRI-05.4" + ], + "3.7.5.c": [ + "PRI-05.4" + ], + "3.7.6": [ + "PRI-06" + ], + "3.7.6.a": [ + "PRI-06" + ], + "3.7.6.b": [ + "PRI-06" + ], + "3.7.6.c": [ + "PRI-06" + ], + "3.7.6.d": [ + "PRI-06" + ], + "3.7.6.e": [ + "PRI-06" + ], + "3.7.7": [ + "PRI-06" + ], + "3.7.7.a": [ + "PRI-06" + ], + "3.7.7.b": [ + "PRI-06" + ], + "5.12.1": [ + "PRI-06" + ], + "5.13.1": [ + "PRI-06.1" + ], + "5.13.1.a": [ + "PRI-06.1" + ], + "5.13.1.b": [ + "PRI-06.1" + ], + "5.13.1.b.i": [ + "PRI-06.1" + ], + "5.13.2": [ + "PRI-06.2" + ], + "5.13.2.a": [ + "PRI-06.2" + ], + "5.13.2.b": [ + "PRI-06.2" + ], + "5.13.3": [ + "PRI-06.2" + ], + "5.13.3.a": [ + "PRI-06.2" + ], + "5.13.3.b": [ + "PRI-06.2" + ], + "5.13.3.c": [ + "PRI-06.2" + ], + "5.12.3": [ + "PRI-06.4" + ], + "5.12.3.a": [ + "PRI-06.4" + ], + "5.12.3.b": [ + "PRI-06.4" + ], + "5.12.3.c": [ + "PRI-06.4" + ], + "5.12.3.d": [ + "PRI-06.4" + ], + "5.12.3.e": [ + "PRI-06.4" + ], + "5.12.3.f": [ + "PRI-06.4" + ], + "5.12.3.g": [ + "PRI-06.4" + ], + "5.12.3.h": [ + "PRI-06.4" + ], + "5.12.3.h.ii": [ + "PRI-06.4" + ], + "5.12.3.i": [ + "PRI-06.4" + ], + "5.12.3.j": [ + "PRI-06.4" + ], + "5.12.4": [ + "PRI-06.4" + ], + "5.12.4.a": [ + "PRI-06.4" + ], + "5.12.4.a.i": [ "PRI-06.4" + ], + "5.12.4.a.ii": [ + "PRI-06.4" + ], + "5.12.4.b": [ + "PRI-06.4" + ], + "5.12.5": [ + "PRI-06.4" + ], + "5.12.5.a": [ + "PRI-06.4" + ], + "5.12.5.b": [ + "PRI-06.4" + ], + "5.12.6": [ + "PRI-06.4" + ], + "5.13.4": [ + "PRI-06.4" + ], + "5.13.4.a": [ + "PRI-06.4" + ], + "5.13.5": [ + "PRI-06.4" + ], + "5.13.5.a": [ + "PRI-06.4" + ], + "5.13.5.a.i": [ + "PRI-06.4" + ], + "5.13.5.a.ii": [ + "PRI-06.4" + ], + "5.13.5.b": [ + "PRI-06.4" + ], + "1.2.2.a": [ + "PRI-06.8" + ], + "1.2.2.b": [ + "PRI-06.8" + ], + "5.12.3.h.i": [ + "PRI-07.4" + ], + "5.13.1.b.ii": [ + "PRI-12.1" + ], + "3.6.5": [ + "PRI-14.2" + ], + "5.12.9": [ + "PRI-17" + ], + "5.12.9.a": [ + "PRI-17" + ], + "5.12.9.b": [ + "PRI-17" + ], + "5.12.9.c": [ + "PRI-17" + ], + "5.12.10": [ + "PRI-17" ] } } diff --git a/docs/api/crosswalks/apac-aus-ps-cps-230-2023.json b/docs/api/crosswalks/apac-aus-ps-cps-230-2023.json index 91ecf290..52d503fb 100644 --- a/docs/api/crosswalks/apac-aus-ps-cps-230-2023.json +++ b/docs/api/crosswalks/apac-aus-ps-cps-230-2023.json @@ -1,312 +1,393 @@ { "framework_id": "apac-aus-ps-cps-230-2023", - "display_name": "Australia - Prudential Standard CPS 230 (2023)", + "display_name": "Australia - Prudential Standard CPS 230 - Operational Risk Management (2023)", "scf_to_framework": { - "total_mappings": 41, + "total_mappings": 69, "mappings": { + "GOV-01": [ + "12(a)", + "16(c)" + ], "GOV-01.1": [ - "20", - "21", - "22(a)", - "22(b)", - "22(c)", - "23", + "16(a)", + "17", + "18", "24", - "25" + "27(a)" ], "GOV-01.2": [ - "30", - "58(a)", - "58(b)", - "58(c)" + "58" + ], + "GOV-02": [ + "12(a)", + "47" ], "GOV-04": [ - "21", - "24" + "23" ], - "GOV-04.1": [ - "21" + "GOV-09": [ + "29" ], - "GOV-04.2": [ - "21" + "GOV-15": [ + "16(c)" ], - "GOV-06": [ - "33", - "42", - "51", + "GOV-17": [ + "59", "59(a)", "59(b)" ], - "GOV-14": [ - "24" - ], - "GOV-15": [ - "29" + "AST-01.1": [ + "34(a)" ], - "GOV-15.1": [ - "29" + "AST-04": [ + "34(a)" ], - "GOV-15.5": [ - "30" + "AST-04.1": [ + "36", + "36(a)", + "36(b)", + "36(c)", + "36(d)", + "37" ], "BCD-01": [ - "12(b)", "14", - "34(a)", + "15", "34(b)", + "41" + ], + "BCD-01.4": [ + "38", + "38(a)", + "38(b)" + ], + "BCD-01.5": [ + "34(d)" + ], + "BCD-01.7": [ + "16(e)", "34(c)", - "34(d)", - "34(e)", + "40", "40(a)", "40(b)", "40(c)", "40(d)", - "40(e)", - "41" - ], - "BCD-01.4": [ - "38(a)", - "38(b)", - "38(c)", - "39" + "40(e)" ], "BCD-02": [ + "15", "34(a)", - "35", - "36(a)", - "36(b)", - "36(c)", - "36(d)", - "37" + "35" ], "BCD-02.1": [ "34(e)" ], "BCD-02.2": [ - "34(e)" + "34(e)", + "38(c)" ], "BCD-02.3": [ - "34(e)" + "34(e)", + "38(c)" ], "BCD-04": [ + "27(c)", "43", - "44", - "45", - "46" + "44" + ], + "BCD-05": [ + "32", + "45" + ], + "BCD-06": [ + "45" + ], + "BCD-06.1": [ + "45" ], "CPL-01": [ - "28" + "12" ], - "CPL-01.1": [ - "30", - "31" + "CPL-01.4": [ + "28" ], "CPL-02": [ - "29", - "30", + "58", + "58(a)", "58(b)", "58(c)" ], "CPL-02.1": [ - "46", - "60" + "46" + ], + "CPL-03": [ + "30" + ], + "MON-01": [ + "16(d)" + ], + "DCH-02": [ + "36" ], "IRO-01": [ - "32" + "16(d)" ], - "IRO-02": [ - "32" + "IRO-06": [ + "27(c)" ], "IRO-10": [ - "33", "42" ], + "IRO-10.2": [ + "33" + ], + "IRO-13": [ + "32" + ], "PRM-01": [ - "25" + "25", + "27(b)" + ], + "PRM-01.1": [ + "27(b)" + ], + "PRM-01.2": [ + "27(b)" ], "PRM-02": [ - "25" + "27(b)" + ], + "PRM-02.1": [ + "25", + "27(b)" ], "PRM-03": [ + "27(b)" + ], + "PRM-04": [ + "25", + "27(b)" + ], + "PRM-05": [ + "25" + ], + "PRM-07": [ "25" ], "RSK-01": [ - "12(a)", - "12(c)", - "13", - "16(a)", + "16", + "16(d)" + ], + "RSK-01.1": [ "16(b)", - "16(c)", - "16(d)", - "16(e)", - "16(f)", - "17", - "18", - "19(a)", - "19(b)", - "19(c)", - "19(d)", - "19(e)" + "27" ], "RSK-01.3": [ - "26" - ], - "RSK-01.4": [ - "26" + "16(b)" ], "RSK-01.5": [ - "26" + "16(b)" + ], + "RSK-03": [ + "13", + "16(d)" ], "RSK-04": [ - "27(a)", - "27(b)", - "27(c)", + "13", + "16(d)", "28" ], + "RSK-04.1": [ + "13", + "32" + ], "RSK-06": [ + "13", + "31" + ], + "RSK-06.1": [ + "16(d)" + ], + "RSK-06.4": [ "31" ], + "RSK-08": [ + "26" + ], + "RSK-10": [ + "26" + ], + "SEA-02.2": [ + "15" + ], + "SEA-07.1": [ + "25" + ], + "OPS-03": [ + "12(b)" + ], + "TDA-06.2": [ + "27(c)" + ], "TPM-01": [ - "15", + "12(c)", + "16(f)", "47", + "48", "48(a)", "48(b)", - "48(c)", - "57" + "48(c)" ], "TPM-01.1": [ - "49" + "49", + "51" ], "TPM-02": [ + "15", + "49", + "50", "50(a)", "50(b)", "50(c)", "50(d)", - "52" + "51" ], - "TPM-03.2": [ - "56(a)", - "56(b)", - "56(c)", - "56(d)" + "TPM-03": [ + "15" ], "TPM-04.1": [ "15", + "53", "53(a)", "53(b)" ], "TPM-05": [ "15", + "16(f)", + "54", "54(a)", "54(b)", "54(c)", "54(d)", "54(e)", "54(f)", - "54(g)", + "55", "55(a)", "55(b)", - "55(c)" + "55(c)", + "56", + "56(a)", + "56(b)", + "56(c)", + "56(d)" ], "TPM-05.7": [ - "50(g)" + "54(g)" ], - "TPM-08": [ - "58(a)", - "58(b)", - "58(c)" + "THR-03": [ + "16(d)" + ], + "THR-10": [ + "16(d)" ] } }, "framework_to_scf": { - "total_mappings": 98, + "total_mappings": 97, "mappings": { + "12": [ + "CPL-01" + ], "13": [ - "RSK-01" + "RSK-03", + "RSK-04", + "RSK-04.1", + "RSK-06" ], "14": [ "BCD-01" ], "15": [ - "TPM-01", + "BCD-01", + "BCD-02", + "SEA-02.2", + "TPM-02", + "TPM-03", "TPM-04.1", "TPM-05" ], - "17": [ - "RSK-01" - ], - "18": [ + "16": [ "RSK-01" ], - "20": [ + "17": [ "GOV-01.1" ], - "21": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1", - "GOV-04.2" + "18": [ + "GOV-01.1" ], "23": [ - "GOV-01.1" + "GOV-04" ], "24": [ - "GOV-01.1", - "GOV-04", - "GOV-14" + "GOV-01.1" ], "25": [ - "GOV-01.1", "PRM-01", - "PRM-02", - "PRM-03" + "PRM-02.1", + "PRM-04", + "PRM-05", + "PRM-07", + "SEA-07.1" ], "26": [ - "RSK-01.3", - "RSK-01.4", - "RSK-01.5" + "RSK-08", + "RSK-10" + ], + "27": [ + "RSK-01.1" ], "28": [ - "CPL-01", + "CPL-01.4", "RSK-04" ], "29": [ - "GOV-15", - "GOV-15.1", - "CPL-02" + "GOV-09" ], "30": [ - "GOV-01.2", - "GOV-15.5", - "CPL-01.1", - "CPL-02" + "CPL-03" ], "31": [ - "CPL-01.1", - "RSK-06" + "RSK-06", + "RSK-06.4" ], "32": [ - "IRO-01", - "IRO-02" + "BCD-05", + "IRO-13", + "RSK-04.1" ], "33": [ - "GOV-06", - "IRO-10" + "IRO-10.2" ], "35": [ "BCD-02" ], + "36": [ + "AST-04.1", + "DCH-02" + ], "37": [ - "BCD-02" + "AST-04.1" ], - "39": [ + "38": [ "BCD-01.4" ], + "40": [ + "BCD-01.7" + ], "41": [ "BCD-01" ], "42": [ - "GOV-06", "IRO-10" ], "43": [ @@ -316,94 +397,88 @@ "BCD-04" ], "45": [ - "BCD-04" + "BCD-05", + "BCD-06", + "BCD-06.1" ], "46": [ - "BCD-04", "CPL-02.1" ], "47": [ + "GOV-02", "TPM-01" ], - "49": [ - "TPM-01.1" + "48": [ + "TPM-01" ], - "51": [ - "GOV-06" + "49": [ + "TPM-01.1", + "TPM-02" ], - "52": [ + "50": [ "TPM-02" ], - "57": [ - "TPM-01" + "51": [ + "TPM-01.1", + "TPM-02" ], - "60": [ - "CPL-02.1" + "53": [ + "TPM-04.1" ], - "22(a)": [ - "GOV-01.1" + "54": [ + "TPM-05" ], - "22(b)": [ - "GOV-01.1" + "55": [ + "TPM-05" ], - "22(c)": [ - "GOV-01.1" + "56": [ + "TPM-05" ], - "58(a)": [ + "58": [ "GOV-01.2", - "TPM-08" + "CPL-02" ], - "58(b)": [ - "GOV-01.2", - "CPL-02", - "TPM-08" + "59": [ + "GOV-17" ], - "58(c)": [ - "GOV-01.2", - "CPL-02", - "TPM-08" + "12(a)": [ + "GOV-01", + "GOV-02" + ], + "16(c)": [ + "GOV-01", + "GOV-15" + ], + "16(a)": [ + "GOV-01.1" + ], + "27(a)": [ + "GOV-01.1" ], "59(a)": [ - "GOV-06" + "GOV-17" ], "59(b)": [ - "GOV-06" - ], - "12(b)": [ - "BCD-01" + "GOV-17" ], "34(a)": [ - "BCD-01", + "AST-01.1", + "AST-04", "BCD-02" ], - "34(b)": [ - "BCD-01" - ], - "34(c)": [ - "BCD-01" - ], - "34(d)": [ - "BCD-01" - ], - "34(e)": [ - "BCD-01", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3" - ], - "40(a)": [ - "BCD-01" + "36(a)": [ + "AST-04.1" ], - "40(b)": [ - "BCD-01" + "36(b)": [ + "AST-04.1" ], - "40(c)": [ - "BCD-01" + "36(c)": [ + "AST-04.1" ], - "40(d)": [ - "BCD-01" + "36(d)": [ + "AST-04.1" ], - "40(e)": [ + "34(b)": [ "BCD-01" ], "38(a)": [ @@ -412,68 +487,86 @@ "38(b)": [ "BCD-01.4" ], - "38(c)": [ - "BCD-01.4" - ], - "36(a)": [ - "BCD-02" + "34(d)": [ + "BCD-01.5" ], - "36(b)": [ - "BCD-02" + "16(e)": [ + "BCD-01.7" ], - "36(c)": [ - "BCD-02" + "34(c)": [ + "BCD-01.7" ], - "36(d)": [ - "BCD-02" + "40(a)": [ + "BCD-01.7" ], - "12(a)": [ - "RSK-01" + "40(b)": [ + "BCD-01.7" ], - "12(c)": [ - "RSK-01" + "40(c)": [ + "BCD-01.7" ], - "16(a)": [ - "RSK-01" + "40(d)": [ + "BCD-01.7" ], - "16(b)": [ - "RSK-01" + "40(e)": [ + "BCD-01.7" ], - "16(c)": [ - "RSK-01" + "34(e)": [ + "BCD-02.1", + "BCD-02.2", + "BCD-02.3" ], - "16(d)": [ - "RSK-01" + "38(c)": [ + "BCD-02.2", + "BCD-02.3" ], - "16(e)": [ - "RSK-01" + "27(c)": [ + "BCD-04", + "IRO-06", + "TDA-06.2" ], - "16(f)": [ - "RSK-01" + "58(a)": [ + "CPL-02" ], - "19(a)": [ - "RSK-01" + "58(b)": [ + "CPL-02" ], - "19(b)": [ - "RSK-01" + "58(c)": [ + "CPL-02" ], - "19(c)": [ - "RSK-01" + "16(d)": [ + "MON-01", + "IRO-01", + "RSK-01", + "RSK-03", + "RSK-04", + "RSK-06.1", + "THR-03", + "THR-10" ], - "19(d)": [ - "RSK-01" + "27(b)": [ + "PRM-01", + "PRM-01.1", + "PRM-01.2", + "PRM-02", + "PRM-02.1", + "PRM-03", + "PRM-04" ], - "19(e)": [ - "RSK-01" + "16(b)": [ + "RSK-01.1", + "RSK-01.3", + "RSK-01.5" ], - "27(a)": [ - "RSK-04" + "12(b)": [ + "OPS-03" ], - "27(b)": [ - "RSK-04" + "12(c)": [ + "TPM-01" ], - "27(c)": [ - "RSK-04" + "16(f)": [ + "TPM-01", + "TPM-05" ], "48(a)": [ "TPM-01" @@ -496,18 +589,6 @@ "50(d)": [ "TPM-02" ], - "56(a)": [ - "TPM-03.2" - ], - "56(b)": [ - "TPM-03.2" - ], - "56(c)": [ - "TPM-03.2" - ], - "56(d)": [ - "TPM-03.2" - ], "53(a)": [ "TPM-04.1" ], @@ -532,9 +613,6 @@ "54(f)": [ "TPM-05" ], - "54(g)": [ - "TPM-05" - ], "55(a)": [ "TPM-05" ], @@ -544,7 +622,19 @@ "55(c)": [ "TPM-05" ], - "50(g)": [ + "56(a)": [ + "TPM-05" + ], + "56(b)": [ + "TPM-05" + ], + "56(c)": [ + "TPM-05" + ], + "56(d)": [ + "TPM-05" + ], + "54(g)": [ "TPM-05.7" ] } diff --git a/docs/api/crosswalks/apac-aus-ps-cps-234-2019.json b/docs/api/crosswalks/apac-aus-ps-cps-234-2019.json index ca6cc281..faca3060 100644 --- a/docs/api/crosswalks/apac-aus-ps-cps-234-2019.json +++ b/docs/api/crosswalks/apac-aus-ps-cps-234-2019.json @@ -1,405 +1,219 @@ { "framework_id": "apac-aus-ps-cps-234-2019", - "display_name": "Australia - Prudential Standard CPS 234 (2019)", + "display_name": "Australia - Prudential Standard CPS 234 Information Security (2019)", "scf_to_framework": { - "total_mappings": 52, + "total_mappings": 23, "mappings": { "GOV-01": [ - "13", - "18", - "19" + "15", + "17" ], "GOV-01.1": [ - "13", - "19" + "13" ], "GOV-02": [ - "18", - "19" - ], - "GOV-03": [ - "19" + "18" ], "GOV-04": [ - "14", - "19" - ], - "GOV-06": [ - "35", - "35(a)", - "35(b)", - "36" + "14" ], - "AST-01": [ - "21", - "21(c)" + "GOV-04.1": [ + "14" ], - "AST-01.1": [ - "21(a)" + "GOV-04.2": [ + "14" ], - "BCD-02": [ - "21(b)" + "GOV-15": [ + "21" ], - "CHG-03": [ + "GOV-15.1": [ + "21", + "21(a)", + "21(b)", + "21(c)", "21(d)" ], - "CPL-01": [ - "31", - "35", - "35(a)", - "35(b)", - "36" - ], - "CPL-01.1": [ - "29", - "35", - "35(a)", - "35(b)", - "36" - ], "CPL-02": [ - "27", - "27(a)", - "27(b)", - "27(c)", - "27(d)", - "27(e)", - "29" + "29", + "31" ], "CPL-02.1": [ - "31", "32", - "33", "34", "34(a)", "34(b)" ], - "CPL-03": [ - "30" - ], "CPL-03.1": [ "30" ], - "DCH-01": [ - "20", - "21(a)" + "CPL-03.2": [ + "33" ], "DCH-02": [ - "20", - "21(a)" + "20" ], "HRS-03": [ - "14" + "19" ], "IRO-01": [ - "23", - "24" + "23" ], "IRO-02": [ - "23", - "24" + "23" ], "IRO-04": [ - "23", "24", + "25", "25(a)", "25(b)" ], "IRO-06": [ - "26" - ], - "IRO-07": [ - "23", - "24", - "25(a)", - "25(b)" - ], - "IRO-09": [ - "23", - "24" - ], - "IRO-13": [ - "25(a)" - ], - "PRM-01": [ - "13", - "15" - ], - "PRM-01.1": [ - "13", - "15" - ], - "PRM-01.2": [ - "15" - ], - "PRM-02": [ - "13", - "15" - ], - "PRM-03": [ - "15" - ], - "PRM-07": [ - "21(c)" - ], - "RSK-08": [ - "21(d)" - ], - "RSK-10": [ - "21(d)" - ], - "SEA-01": [ - "15", - "18" - ], - "SEA-01.1": [ - "18" - ], - "SEA-02": [ - "15", - "18" - ], - "SEA-03": [ - "15", - "18" - ], - "TDA-06.1": [ - "21(b)" - ], - "TPM-01": [ - "16", - "20", - "22", - "28" - ], - "TPM-02": [ - "21(b)" - ], - "TPM-03": [ - "22", - "28" + "26", + "27", + "27(a)", + "27(b)", + "27(c)", + "27(d)", + "27(e)" ], - "TPM-03.2": [ - "22" + "IRO-10": [ + "35", + "36" ], - "TPM-04": [ - "16", + "IAO-02": [ "22", "28" ], "TPM-04.1": [ - "22", - "28" - ], - "TPM-05": [ - "16", - "20", - "28" - ], - "TPM-08": [ - "28" + "16" ], "THR-01": [ "17" ], "VPM-01": [ "17" - ], - "VPM-02": [ - "21" - ], - "VPM-04": [ - "21" - ], - "VPM-05": [ - "21" ] } }, "framework_to_scf": { - "total_mappings": 38, + "total_mappings": 37, "mappings": { "13": [ - "GOV-01", - "GOV-01.1", - "PRM-01", - "PRM-01.1", - "PRM-02" + "GOV-01.1" ], "14": [ "GOV-04", - "HRS-03" + "GOV-04.1", + "GOV-04.2" ], "15": [ - "PRM-01", - "PRM-01.1", - "PRM-01.2", - "PRM-02", - "PRM-03", - "SEA-01", - "SEA-02", - "SEA-03" + "GOV-01" ], "16": [ - "TPM-01", - "TPM-04", - "TPM-05" + "TPM-04.1" ], "17": [ + "GOV-01", "THR-01", "VPM-01" ], "18": [ - "GOV-01", - "GOV-02", - "SEA-01", - "SEA-01.1", - "SEA-02", - "SEA-03" + "GOV-02" ], "19": [ - "GOV-01", - "GOV-01.1", - "GOV-02", - "GOV-03", - "GOV-04" + "HRS-03" ], "20": [ - "DCH-01", - "DCH-02", - "TPM-01", - "TPM-05" + "DCH-02" ], "21": [ - "AST-01", - "VPM-02", - "VPM-04", - "VPM-05" + "GOV-15", + "GOV-15.1" ], "22": [ - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-04.1" + "IAO-02" ], "23": [ "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09" + "IRO-02" ], "24": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09" + "IRO-04" + ], + "25": [ + "IRO-04" ], "26": [ "IRO-06" ], "27": [ - "CPL-02" + "IRO-06" ], "28": [ - "TPM-01", - "TPM-03", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-08" + "IAO-02" ], "29": [ - "CPL-01.1", "CPL-02" ], "30": [ - "CPL-03", "CPL-03.1" ], "31": [ - "CPL-01", - "CPL-02.1" + "CPL-02" ], "32": [ "CPL-02.1" ], "33": [ - "CPL-02.1" + "CPL-03.2" ], "34": [ "CPL-02.1" ], "35": [ - "GOV-06", - "CPL-01", - "CPL-01.1" + "IRO-10" ], "36": [ - "GOV-06", - "CPL-01", - "CPL-01.1" + "IRO-10" ], - "35(a)": [ - "GOV-06", - "CPL-01", - "CPL-01.1" + "21(a)": [ + "GOV-15.1" ], - "35(b)": [ - "GOV-06", - "CPL-01", - "CPL-01.1" + "21(b)": [ + "GOV-15.1" ], "21(c)": [ - "AST-01", - "PRM-07" + "GOV-15.1" ], - "21(a)": [ - "AST-01.1", - "DCH-01", - "DCH-02" + "21(d)": [ + "GOV-15.1" ], - "21(b)": [ - "BCD-02", - "TDA-06.1", - "TPM-02" + "34(a)": [ + "CPL-02.1" ], - "21(d)": [ - "CHG-03", - "RSK-08", - "RSK-10" + "34(b)": [ + "CPL-02.1" + ], + "25(a)": [ + "IRO-04" + ], + "25(b)": [ + "IRO-04" ], "27(a)": [ - "CPL-02" + "IRO-06" ], "27(b)": [ - "CPL-02" + "IRO-06" ], "27(c)": [ - "CPL-02" + "IRO-06" ], "27(d)": [ - "CPL-02" + "IRO-06" ], "27(e)": [ - "CPL-02" - ], - "34(a)": [ - "CPL-02.1" - ], - "34(b)": [ - "CPL-02.1" - ], - "25(a)": [ - "IRO-04", - "IRO-07", - "IRO-13" - ], - "25(b)": [ - "IRO-04", - "IRO-07" + "IRO-06" ] } } diff --git a/docs/api/crosswalks/apac-chn-csnip-2012.json b/docs/api/crosswalks/apac-chn-csnip-2012.json index 18351274..76579871 100644 --- a/docs/api/crosswalks/apac-chn-csnip-2012.json +++ b/docs/api/crosswalks/apac-chn-csnip-2012.json @@ -2,62 +2,58 @@ "framework_id": "apac-chn-csnip-2012", "display_name": "China - Decision on Strengthening Network Information Protection (2012)", "scf_to_framework": { - "total_mappings": 10, + "total_mappings": 7, "mappings": { - "GOV-01": [ - "4" + "HRS-06.1": [ + "III" ], - "CPL-01": [ - "4" + "PRI-01.6": [ + "IV" ], - "CPL-02": [ - "4" + "PRI-01.11": [ + "I", + "II", + "VI" ], - "DCH-01": [ - "4" + "PRI-05.4": [ + "V" ], - "DCH-22.1": [ - "8" + "PRI-06": [ + "VIII" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-06.5": [ + "VIII" ], - "PRI-06.1": [ - "8" - ], - "SEA-01": [ - "4" - ], - "SEA-02": [ - "4" - ], - "SEA-03": [ - "4" + "PRI-16": [ + "VI" ] } }, "framework_to_scf": { - "total_mappings": 4, + "total_mappings": 7, "mappings": { - "4": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "III": [ + "HRS-06.1" + ], + "IV": [ + "PRI-01.6" + ], + "I": [ + "PRI-01.11" + ], + "II": [ + "PRI-01.11" ], - "8": [ - "DCH-22.1", - "PRI-06.1" + "VI": [ + "PRI-01.11", + "PRI-16" ], - "Inferred": [ - "PRI-01" + "V": [ + "PRI-05.4" ], - "Expectation": [ - "PRI-01" + "VIII": [ + "PRI-06", + "PRI-06.5" ] } } diff --git a/docs/api/crosswalks/apac-chn-cybersecurity-law-2017.json b/docs/api/crosswalks/apac-chn-cybersecurity-law-2017.json index e7153a4a..07b9a646 100644 --- a/docs/api/crosswalks/apac-chn-cybersecurity-law-2017.json +++ b/docs/api/crosswalks/apac-chn-cybersecurity-law-2017.json @@ -1,6 +1,6 @@ { "framework_id": "apac-chn-cybersecurity-law-2017", - "display_name": "China - Cybersecurity Law (2017)", + "display_name": "China - Cybersecurity Law of the People's Republic of China (2017)", "scf_to_framework": { "total_mappings": 27, "mappings": { diff --git a/docs/api/crosswalks/apac-chn-data-security-law-2021.json b/docs/api/crosswalks/apac-chn-data-security-law-2021.json index 88a0ec99..f1ff0052 100644 --- a/docs/api/crosswalks/apac-chn-data-security-law-2021.json +++ b/docs/api/crosswalks/apac-chn-data-security-law-2021.json @@ -1,239 +1,73 @@ { "framework_id": "apac-chn-data-security-law-2021", - "display_name": "China - Data Security Law (2021)", + "display_name": "China - Data Security Law of the People's Republic of China (2021)", "scf_to_framework": { - "total_mappings": 15, + "total_mappings": 10, "mappings": { "GOV-04": [ - "45", - "46" + "Article 27" ], "GOV-12": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "Article 28" ], "GOV-13": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" - ], - "CHG-04.4": [ - "27" + "Article 27" ], "CPL-01": [ - "46" + "Article 27", + "Article 32" ], "CPL-06": [ - "24", - "27", - "31", - "33", - "44" - ], - "DCH-26": [ - "36" - ], - "HRS-03": [ - "27" - ], - "HRS-04.1": [ - "27" + "Article 27", + "Article 31" ], - "HRS-12": [ - "27" + "MON-01": [ + "Article 29" ], - "IAC-07.1": [ - "27" + "IRO-02": [ + "Article 29" ], - "IAC-08": [ - "27" - ], - "PES-02.1": [ - "27" + "PRI-01.11": [ + "Article 33" ], "PRI-16": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "Article 27", + "Article 33" ], - "SAT-03": [ - "27" + "RSK-04": [ + "Article 30" ] } }, "framework_to_scf": { - "total_mappings": 24, + "total_mappings": 7, "mappings": { - "7": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "8": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "9": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "11": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "14": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "15": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "16": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "18": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "19": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "20": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "24": [ - "CPL-06" - ], - "27": [ - "CHG-04.4", - "CPL-06", - "HRS-03", - "HRS-04.1", - "HRS-12", - "IAC-07.1", - "IAC-08", - "PES-02.1", - "SAT-03" - ], - "28": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "31": [ - "GOV-12", - "GOV-13", - "CPL-06", - "PRI-16" - ], - "32": [ - "GOV-12", - "GOV-13", - "PRI-16" - ], - "33": [ - "GOV-12", + "Article 27": [ + "GOV-04", "GOV-13", + "CPL-01", "CPL-06", "PRI-16" ], - "36": [ - "GOV-12", - "GOV-13", - "DCH-26", - "PRI-16" - ], - "37": [ - "GOV-12", - "GOV-13", - "PRI-16" + "Article 28": [ + "GOV-12" ], - "38": [ - "GOV-12", - "GOV-13", - "PRI-16" + "Article 32": [ + "CPL-01" ], - "44": [ + "Article 31": [ "CPL-06" ], - "45": [ - "GOV-04" - ], - "46": [ - "GOV-04", - "CPL-01" + "Article 29": [ + "MON-01", + "IRO-02" ], - "48": [ - "GOV-12", - "GOV-13", + "Article 33": [ + "PRI-01.11", "PRI-16" ], - "53": [ - "GOV-12", - "GOV-13", - "PRI-16" + "Article 30": [ + "RSK-04" ] } } diff --git a/docs/api/crosswalks/apac-chn-pipl-2021.json b/docs/api/crosswalks/apac-chn-pipl-2021.json index 1b51e7a2..628f3eab 100644 --- a/docs/api/crosswalks/apac-chn-pipl-2021.json +++ b/docs/api/crosswalks/apac-chn-pipl-2021.json @@ -1,974 +1,272 @@ { "framework_id": "apac-chn-pipl-2021", - "display_name": "China - Personal Information Protection Law (2021)", + "display_name": "China - Personal Information Protection Law of the People's Republic of China (2021)", "scf_to_framework": { - "total_mappings": 79, + "total_mappings": 37, "mappings": { - "GOV-01": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" - ], - "GOV-04": [ - "52" - ], - "GOV-10": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" - ], - "GOV-12": [ - "38", - "38(4)", - "40" - ], "GOV-13": [ - "11", - "12", - "38(4)", - "40", - "47(5)", - "60", - "63(3)", - "63(4)", - "64" - ], - "AST-20": [ - "26" - ], - "CLD-09": [ - "38", - "39", - "40" - ], - "CPL-01": [ - "32", - "37", - "38(4)", - "42" - ], - "CPL-01.1": [ - "54" - ], - "CPL-02": [ - "54" - ], - "CPL-02.1": [ - "54" - ], - "CPL-03": [ - "38(1)", - "38(2)", - "40" - ], - "CPL-03.1": [ - "38(1)", - "38(2)", - "40" - ], - "CPL-03.2": [ - "54" - ], - "CPL-05": [ - "41" - ], - "CPL-05.1": [ - "18" - ], - "CPL-05.2": [ - "61(4)", - "63", - "63(1)", - "63(2)", - "63(3)", - "63(4)", - "64" + "Article 38" ], "CPL-06": [ - "11", - "12", - "26", - "38(4)", - "40", - "47(5)", - "60", - "61(4)", - "63(3)", - "63(4)", - "64" - ], - "MON-10": [ - "19" - ], - "DCH-18": [ - "19" - ], - "DCH-18.2": [ - "6" - ], - "DCH-19": [ - "38", - "39", - "40" - ], - "DCH-22": [ - "8" - ], - "DCH-22.1": [ - "46", - "49" + "Article 38" ], - "DCH-26": [ - "36", - "38", - "40" + "CPL-08": [ + "Article 53" ], - "EMB-02": [ - "26" + "DCH-03.1": [ + "Article 25" ], - "END-14": [ - "26" + "DCH-26": [ + "Article 40" + ], + "HRS-06.1": [ + "Article 59" ], "IRO-02": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], - "IRO-04": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], - "IRO-04.1": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], - "IRO-10.2": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], - "PES-05.1": [ - "26" + "Article 57" + ], + "IRO-10": [ + "Article 57" ], "PRI-01": [ - "7", - "16", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)", - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)", - "59" - ], - "PRI-01.1": [ - "9", - "52" - ], - "PRI-01.3": [ - "9", - "48" + "Article 51" ], "PRI-01.4": [ - "9", - "52", - "53" + "Article 52", + "Article 54" + ], + "PRI-01.5": [ + "Article 38" ], "PRI-01.6": [ - "9", - "25", - "28", - "59" - ], - "PRI-01.7": [ - "20", - "21", - "22", - "25", - "41" + "Article 9" + ], + "PRI-01.11": [ + "Article 5", + "Article 7", + "Article 10", + "Article 26", + "Article 27" ], "PRI-02": [ - "7", - "17", - "17(1)", - "17(2)", - "17(3)", - "17(4)", - "27", - "39", - "48" + "Article 17", + "Article 18", + "Article 30", + "Article 39" ], "PRI-02.1": [ - "6", - "48" - ], - "PRI-02.2": [ - "24" + "Article 6" ], "PRI-03": [ - "13(1)", - "14", - "23", - "27", - "29", - "30", - "44" - ], - "PRI-03.2": [ - "14", - "22", - "23", - "27" - ], - "PRI-03.3": [ - "10" + "Article 14" + ], + "PRI-03.1": [ + "Article 29" ], "PRI-03.4": [ - "15" + "Article 15" ], "PRI-03.5": [ - "16" - ], - "PRI-04": [ - "26", - "31" - ], - "PRI-04.1": [ - "5", - "10", - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "26", - "29", - "30", - "47" - ], - "PRI-04.2": [ - "10" - ], - "PRI-04.3": [ - "26" + "Article 16" + ], + "PRI-03.6": [ + "Article 49" + ], + "PRI-03.13": [ + "Article 31" ], "PRI-05": [ - "10", - "19", - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)" - ], - "PRI-05.1": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "28", - "47" + "Article 19", + "Article 47" ], "PRI-05.2": [ - "8" + "Article 8" ], "PRI-05.4": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "28", - "29", - "30", - "31", - "32" - ], - "PRI-05.7": [ - "51(2)" + "Article 13", + "Article 28" ], "PRI-06": [ - "45", - "46", - "49" + "Article 44", + "Article 48" ], "PRI-06.1": [ - "46", - "49" - ], - "PRI-06.2": [ - "22", - "46", - "49" + "Article 46" ], "PRI-06.4": [ - "45", - "46", - "50" - ], - "PRI-06.5": [ - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)", - "49" - ], - "PRI-06.7": [ - "45" - ], - "PRI-07": [ - "20", - "21", - "22", - "27", - "38(3)", - "41", - "42", - "49" + "Article 50" + ], + "PRI-06.6": [ + "Article 45" ], "PRI-07.1": [ - "20", - "21", - "27", - "38(3)", - "42" + "Article 21" ], "PRI-07.2": [ - "20", - "21", - "27", - "38(3)" - ], - "PRI-07.3": [ - "46" + "Article 20" ], "PRI-07.4": [ - "45", - "46", - "49" + "Article 50" ], "PRI-07.5": [ - "45", - "46", - "49" + "Article 50" ], - "PRI-10": [ - "8" + "PRI-14.1": [ + "Article 22", + "Article 23" ], "PRI-16": [ - "11", - "12", - "18", - "26", - "38(4)", - "40", - "47(5)" + "Article 38" + ], + "PRI-19": [ + "Article 24" + ], + "PRI-19.3": [ + "Article 24" ], "RSK-10": [ - "55", - "55(1)", - "55(2)", - "55(3)", - "55(4)", - "55(5)", - "56", - "56(1)", - "56(2)", - "56(3)" - ], - "OPS-01": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" - ], - "OPS-01.1": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" - ], - "OPS-03": [ - "51" - ], - "TPM-01": [ - "20", - "21", - "38(3)", - "42", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" - ], - "TPM-03.2": [ - "20" - ], - "TPM-04": [ - "20", - "21", - "38(3)" - ], - "TPM-04.4": [ - "21", - "38", - "38(3)", - "40" - ], - "TPM-05": [ - "20", - "21", - "38(3)", - "42" - ], - "TPM-06": [ - "52" + "Article 55", + "Article 56" ] } }, "framework_to_scf": { - "total_mappings": 100, + "total_mappings": 43, "mappings": { - "5": [ - "PRI-04.1" - ], - "6": [ - "DCH-18.2", - "PRI-02.1" - ], - "7": [ - "PRI-01", - "PRI-02" - ], - "8": [ - "DCH-22", - "PRI-05.2", - "PRI-10" - ], - "9": [ - "PRI-01.1", - "PRI-01.3", - "PRI-01.4", - "PRI-01.6" - ], - "10": [ - "PRI-03.3", - "PRI-04.1", - "PRI-04.2", - "PRI-05" - ], - "11": [ - "GOV-13", - "CPL-06", - "PRI-16" - ], - "12": [ + "Article 38": [ "GOV-13", "CPL-06", + "PRI-01.5", "PRI-16" ], - "13": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" - ], - "14": [ - "PRI-03", - "PRI-03.2" - ], - "15": [ - "PRI-03.4" - ], - "16": [ - "PRI-01", - "PRI-03.5" - ], - "17": [ - "PRI-02" - ], - "18": [ - "CPL-05.1", - "PRI-04.1", - "PRI-05.4", - "PRI-16" - ], - "19": [ - "MON-10", - "DCH-18", - "PRI-05" - ], - "20": [ - "PRI-01.7", - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "TPM-01", - "TPM-03.2", - "TPM-04", - "TPM-05" - ], - "21": [ - "PRI-01.7", - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "TPM-01", - "TPM-04", - "TPM-04.4", - "TPM-05" - ], - "22": [ - "PRI-01.7", - "PRI-03.2", - "PRI-06.2", - "PRI-07" - ], - "23": [ - "PRI-03", - "PRI-03.2" - ], - "24": [ - "PRI-02.2" - ], - "25": [ - "PRI-01.6", - "PRI-01.7" - ], - "26": [ - "AST-20", - "CPL-06", - "EMB-02", - "END-14", - "PES-05.1", - "PRI-04", - "PRI-04.1", - "PRI-04.3", - "PRI-16" - ], - "27": [ - "PRI-02", - "PRI-03", - "PRI-03.2", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "28": [ - "PRI-01.6", - "PRI-05.1", - "PRI-05.4" - ], - "29": [ - "PRI-03", - "PRI-04.1", - "PRI-05.4" - ], - "30": [ - "PRI-03", - "PRI-04.1", - "PRI-05.4" - ], - "31": [ - "PRI-04", - "PRI-05.4" + "Article 53": [ + "CPL-08" ], - "32": [ - "CPL-01", - "PRI-05.4" + "Article 25": [ + "DCH-03.1" ], - "36": [ + "Article 40": [ "DCH-26" ], - "37": [ - "CPL-01" - ], - "38": [ - "GOV-12", - "CLD-09", - "DCH-19", - "DCH-26", - "TPM-04.4" - ], - "39": [ - "CLD-09", - "DCH-19", - "PRI-02" - ], - "40": [ - "GOV-12", - "GOV-13", - "CLD-09", - "CPL-03", - "CPL-03.1", - "CPL-06", - "DCH-19", - "DCH-26", - "PRI-16", - "TPM-04.4" - ], - "41": [ - "CPL-05", - "PRI-01.7", - "PRI-07" - ], - "42": [ - "CPL-01", - "PRI-07", - "PRI-07.1", - "TPM-01", - "TPM-05" - ], - "44": [ - "PRI-03" - ], - "45": [ - "PRI-06", - "PRI-06.4", - "PRI-06.7", - "PRI-07.4", - "PRI-07.5" - ], - "46": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.4", - "PRI-07.3", - "PRI-07.4", - "PRI-07.5" - ], - "47": [ - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-06.5" + "Article 59": [ + "HRS-06.1" ], - "48": [ - "PRI-01.3", - "PRI-02", - "PRI-02.1" - ], - "49": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.5", - "PRI-07", - "PRI-07.4", - "PRI-07.5" - ], - "50": [ - "PRI-06.4" - ], - "51": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "OPS-03", - "TPM-01" - ], - "52": [ - "GOV-04", - "PRI-01.1", - "PRI-01.4", - "TPM-06" - ], - "53": [ - "PRI-01.4" - ], - "54": [ - "CPL-01.1", - "CPL-02", - "CPL-02.1", - "CPL-03.2" - ], - "55": [ - "RSK-10" - ], - "56": [ - "RSK-10" - ], - "57": [ + "Article 57": [ "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-10.2" - ], - "58": [ - "GOV-01", - "GOV-10", - "PRI-01" - ], - "59": [ - "PRI-01", - "PRI-01.6" - ], - "60": [ - "GOV-13", - "CPL-06" + "IRO-10" ], - "63": [ - "CPL-05.2" - ], - "64": [ - "GOV-13", - "CPL-05.2", - "CPL-06" - ], - "58(1)": [ - "GOV-01", - "GOV-10", - "PRI-01" - ], - "58(2)": [ - "GOV-01", - "GOV-10", + "Article 51": [ "PRI-01" ], - "58(3)": [ - "GOV-01", - "GOV-10", - "PRI-01" + "Article 52": [ + "PRI-01.4" ], - "58(4)": [ - "GOV-01", - "GOV-10", - "PRI-01" + "Article 54": [ + "PRI-01.4" ], - "38(4)": [ - "GOV-12", - "GOV-13", - "CPL-01", - "CPL-06", - "PRI-16" + "Article 9": [ + "PRI-01.6" ], - "47(5)": [ - "GOV-13", - "CPL-06", - "PRI-05", - "PRI-06.5", - "PRI-16" + "Article 5": [ + "PRI-01.11" ], - "63(3)": [ - "GOV-13", - "CPL-05.2", - "CPL-06" + "Article 7": [ + "PRI-01.11" ], - "63(4)": [ - "GOV-13", - "CPL-05.2", - "CPL-06" + "Article 10": [ + "PRI-01.11" ], - "38(1)": [ - "CPL-03", - "CPL-03.1" + "Article 26": [ + "PRI-01.11" ], - "38(2)": [ - "CPL-03", - "CPL-03.1" + "Article 27": [ + "PRI-01.11" ], - "61(4)": [ - "CPL-05.2", - "CPL-06" + "Article 17": [ + "PRI-02" ], - "63(1)": [ - "CPL-05.2" + "Article 18": [ + "PRI-02" ], - "63(2)": [ - "CPL-05.2" + "Article 30": [ + "PRI-02" ], - "57(1)": [ - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-10.2" + "Article 39": [ + "PRI-02" ], - "57(2)": [ - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-10.2" + "Article 6": [ + "PRI-02.1" ], - "57(3)": [ - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-10.2" - ], - "51(1)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" - ], - "51(2)": [ - "PRI-01", - "PRI-05.7", - "OPS-01", - "OPS-01.1", - "TPM-01" - ], - "51(3)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" - ], - "51(4)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" - ], - "51(5)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" - ], - "51(6)": [ - "PRI-01", - "OPS-01", - "OPS-01.1", - "TPM-01" - ], - "17(1)": [ - "PRI-02" + "Article 14": [ + "PRI-03" ], - "17(2)": [ - "PRI-02" + "Article 29": [ + "PRI-03.1" ], - "17(3)": [ - "PRI-02" + "Article 15": [ + "PRI-03.4" ], - "17(4)": [ - "PRI-02" + "Article 16": [ + "PRI-03.5" ], - "13(1)": [ - "PRI-03", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "Article 49": [ + "PRI-03.6" ], - "13(2)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "Article 31": [ + "PRI-03.13" ], - "13(3)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "Article 19": [ + "PRI-05" ], - "13(4)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "Article 47": [ + "PRI-05" ], - "13(5)": [ - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "Article 8": [ + "PRI-05.2" ], - "13(6)": [ - "PRI-04.1", - "PRI-05.1", + "Article 13": [ "PRI-05.4" ], - "13(7)": [ - "PRI-04.1", - "PRI-05.1", + "Article 28": [ "PRI-05.4" ], - "47(1)": [ - "PRI-05", - "PRI-06.5" + "Article 44": [ + "PRI-06" ], - "47(2)": [ - "PRI-05", - "PRI-06.5" + "Article 48": [ + "PRI-06" ], - "47(3)": [ - "PRI-05", - "PRI-06.5" + "Article 46": [ + "PRI-06.1" ], - "47(4)": [ - "PRI-05", - "PRI-06.5" - ], - "38(3)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "TPM-01", - "TPM-04", - "TPM-04.4", - "TPM-05" + "Article 50": [ + "PRI-06.4", + "PRI-07.4", + "PRI-07.5" ], - "55(1)": [ - "RSK-10" + "Article 45": [ + "PRI-06.6" ], - "55(2)": [ - "RSK-10" + "Article 21": [ + "PRI-07.1" ], - "55(3)": [ - "RSK-10" + "Article 20": [ + "PRI-07.2" ], - "55(4)": [ - "RSK-10" + "Article 22": [ + "PRI-14.1" ], - "55(5)": [ - "RSK-10" + "Article 23": [ + "PRI-14.1" ], - "56(1)": [ - "RSK-10" + "Article 24": [ + "PRI-19", + "PRI-19.3" ], - "56(2)": [ + "Article 55": [ "RSK-10" ], - "56(3)": [ + "Article 56": [ "RSK-10" ] } diff --git a/docs/api/crosswalks/apac-hkg-pdo-2022.json b/docs/api/crosswalks/apac-hkg-pdo-2022.json index 3fbadb7c..18f626d7 100644 --- a/docs/api/crosswalks/apac-hkg-pdo-2022.json +++ b/docs/api/crosswalks/apac-hkg-pdo-2022.json @@ -2,116 +2,1072 @@ "framework_id": "apac-hkg-pdo-2022", "display_name": "Hong Kong - Personal Data Ordinance (2022)", "scf_to_framework": { - "total_mappings": 14, + "total_mappings": 18, "mappings": { - "GOV-01": [ - "Principle 4" - ], "CPL-01": [ - "Principle 4" + "4" + ], + "PRI-01.6": [ + "Schedule 1 - 4(1)", + "Schedule 1 - 4(1)(a)", + "Schedule 1 - 4(1)(b)", + "Schedule 1 - 4(1)(c)", + "Schedule 1 - 4(1)(d)", + "Schedule 1 - 4(1)(e)" ], - "CPL-02": [ - "Principle 4" + "PRI-01.11": [ + "28(1)", + "28(2)", + "28(3)", + "28(4)", + "28(4)(II)", + "28(5)", + "28(6)", + "28(6)(a)", + "28(6)(b)", + "29", + "29(a)", + "29(b)", + "Schedule 1 - 1(1)(a)", + "Schedule 1 - 1(1)(b)", + "Schedule 1 - 1(1)(c)", + "Schedule 1 - 1(2)(a)", + "Schedule 1 - 1(2)(b)" ], - "DCH-01": [ - "Principle 4", - "Sec 33" + "PRI-02": [ + "35C(2)", + "35C(2)(a)", + "35C(2)(a)(i)", + "35C(2)(a)(ii)", + "35C(2)(b)", + "35C(2)(b)(i)", + "35C(2)(b)(ii)", + "35C(2)(c)", + "35C(3)", + "35C(4)", + "35C(5)", + "35J(2)", + "35J(2)(a)", + "35J(2)(a)(i)", + "35J(2)(a)(ii)", + "35J(2)(b)", + "35J(2)(b)(i)", + "35J(2)(b)(ii)", + "35J(2)(b)(iii)", + "35J(2)(b)(iv)", + "35J(2)(c)", + "35J(3)", + "35J(4)", + "35J(5)", + "35J(5)(a)", + "35J(5)(b)", + "Schedule 1 - 1(3)(a)", + "Schedule 1 - 1(3)(b)(ii)(B)", + "Schedule 1 - 5", + "Schedule 1 - 5(a)", + "Schedule 1 - 5(b)", + "Schedule 1 - 5(c)" ], - "DCH-22.1": [ - "Sec 22" + "PRI-03": [ + "35E(1)", + "35E(1)(a)", + "35E(1)(b)", + "35E(1)(b)(i)", + "35E(1)(b)(ii)", + "35E(1)(b)(iii)", + "35E(1)(c)", + "35E(2)", + "35E(2)(a)", + "35E(2)(b)", + "35E(3)", + "35E(4)", + "Schedule 1 - 1(3)(a)(i)", + "Schedule 1 - 1(3)(a)(ii)", + "Schedule 1 - 1(3)(b)", + "Schedule 1 - 1(3)(b)(i)", + "Schedule 1 - 1(3)(b)(i)(A)", + "Schedule 1 - 1(3)(b)(i)(B)", + "Schedule 1 - 1(3)(b)(ii)", + "Schedule 1 - 1(3)(b)(ii)(A)" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-03.4": [ + "35G(1)", + "35L(1)", + "35L(1)(a)", + "35L(1)(b)", + "35L(2)", + "35L(3)", + "35L(4)" ], - "PRI-02.1": [ - "Principle 1" + "PRI-03.9": [ + "Schedule 1 - 2(1)(b)(i)", + "Schedule 1 - 2(1)(b)(ii)" ], "PRI-05": [ - "Principle 2", - "Sec 26", - "Principle 3", - "Sec 4" + "26(1)", + "26(1)(a)", + "26(1)(b)", + "26(2)", + "26(2)(a)", + "26(2)(b)", + "Schedule 1 - 2(2)", + "Schedule 1 - 2(3)" + ], + "PRI-05.2": [ + "Schedule 1 - 2(1)(a)", + "Schedule 1 - 2(1)(b)", + "Schedule 1 - 2(1)(c)(i)", + "Schedule 1 - 2(1)(c)(ii)", + "Schedule 1 - 2(1)(c)(ii)(A)", + "Schedule 1 - 2(1)(c)(ii)(B)" + ], + "PRI-05.4": [ + "35K(1)", + "35K(1)(a)", + "35K(1)(b)", + "35K(1)(c)", + "35K(2)", + "35K(2)(a)", + "35K(2)(b)", + "35K(2)(c)", + "35K(3)", + "Schedule 1 - 3(1)", + "Schedule 1 - 3(2)", + "Schedule 1 - 3(2)(a)", + "Schedule 1 - 3(2)(a)(i)", + "Schedule 1 - 3(2)(a)(ii)", + "Schedule 1 - 3(2)(a)(iii)", + "Schedule 1 - 3(2)(b)", + "Schedule 1 - 3(2)(c)", + "Schedule 1 - 3(3)" ], "PRI-06": [ - "Principle 6", - "Sec 17A", - "Sec 18" + "18(1)", + "18(1)(a)", + "18(1)(b)", + "18(2)", + "18(3)", + "18(4)", + "18(4)(a)", + "18(4)(b)", + "35G(3)", + "Schedule 1 - 6", + "Schedule 1 - 6(a)", + "Schedule 1 - 6(b)", + "Schedule 1 - 6(b)(i)", + "Schedule 1 - 6(b)(ii)", + "Schedule 1 - 6(b)(iii)", + "Schedule 1 - 6(b)(iv)", + "Schedule 1 - 6(c)", + "Schedule 1 - 6(d)", + "Schedule 1 - 6(e)", + "Schedule 1 - 6(f)", + "Schedule 1 - 6(g)" ], "PRI-06.1": [ - "Sec 22" + "22(1)(a)", + "22(1)(b)", + "22(1A)", + "22(2)", + "22(2)(a)", + "22(2)(b)", + "22(3)", + "22(4)", + "23(1)", + "23(1)(a)", + "23(1)(c)(i)", + "23(1)(c)(ii)", + "23(2)", + "23(2)(a)", + "23(2)(a)(i)", + "23(2)(a)(ii)", + "23(2)(b)", + "23(3)", + "23(3)(a)", + "23(3)(b)" + ], + "PRI-06.2": [ + "19(3)(b)", + "19(3)(c)", + "19(3)(c)(i)", + "19(3)(c)(i)(A)", + "19(3)(c)(i)(B)", + "19(3)(c)(ii)", + "19(3)(c)(iii)", + "19(3)(c)(iii)(A)", + "19(3)(c)(iii)(B)", + "19(3)(c)(I)", + "19(3)(c)(II)", + "19(3)(c)(iv)", + "19(3)(c)(v)", + "23(1)(b)" ], - "PRI-15": [ - "Sec 15" + "PRI-06.4": [ + "18(5)", + "18(5)(a)", + "18(5)(b)", + "19(1)", + "19(1)(a)", + "19(1)(a)(i)", + "19(1)(a)(ii)", + "19(1)(b)", + "19(3)", + "19(3)(a)", + "19(3)(a)(i)", + "19(3)(a)(i)(A)", + "19(3)(a)(i)(B)", + "19(3)(a)(ii)", + "19(4)", + "19(4)(a)", + "19(4)(b)", + "19(4)(b)(i)", + "19(4)(b)(ii)", + "19(4)(b)(ii)(A)", + "19(4)(b)(I)", + "19(4)(b)(II)", + "19(4)(b)(III)", + "19(4)(b)(III)(B)", + "21(1)", + "21(1)(a)", + "21(1)(b)", + "21(1)(c)", + "25(1)", + "25(1)(b)" ], - "SEA-01": [ - "Principle 4", - "Sec 33" + "PRI-07.1": [ + "Schedule 1 - 4(2)" ], - "SEA-02": [ - "Principle 4", - "Sec 33" + "PRI-07.4": [ + "24(1)", + "24(1)(a)", + "24(1)(b)", + "24(1)(b)(i)", + "24(1)(b)(ii)", + "24(2)", + "24(3)", + "24(3)(a)", + "24(3)(b)", + "24(3)(c)", + "24(3)(d)", + "24(3)(e)", + "24(4)" ], - "SEA-03": [ - "Principle 4", - "Sec 33" + "PRI-07.5": [ + "20(1)", + "20(1)(a)", + "20(1)(a)(i)", + "20(1)(a)(ii)", + "20(1)(a)(ii)(A)", + "20(1)(a)(ii)(B)", + "20(1)(b)", + "20(1)(c)", + "20(2)(a)", + "20(2)(b)", + "20(3)", + "20(3)(a)", + "20(3)(b)", + "20(3)(c)", + "20(3)(c)(i)", + "20(3)(c)(ii)", + "20(3)(c)(iii)", + "20(3)(d)", + "20(3)(e)", + "20(3)(f)", + "25(1)(a)" + ], + "PRI-14": [ + "27(1)", + "27(1)(a)", + "27(1)(b)", + "27(1)(c)", + "27(1)(c)(i)", + "27(1)(c)(ii)", + "27(2)", + "27(2)(a)", + "27(2)(b)", + "27(2)(c)", + "27(2)(d)", + "27(3)", + "27(3)(a)", + "27(3)(b)", + "27(3)(c)", + "27(3)(d)", + "27(4)", + "27(4)(a)", + "27(4)(b)" ] } }, "framework_to_scf": { - "total_mappings": 14, + "total_mappings": 256, "mappings": { - "Principle 4": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "4": [ + "CPL-01" ], - "Sec 33": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "29": [ + "PRI-01.11" ], - "Sec 22": [ - "DCH-22.1", - "PRI-06.1" + "Schedule 1 - 4(1)": [ + "PRI-01.6" + ], + "Schedule 1 - 4(1)(a)": [ + "PRI-01.6" + ], + "Schedule 1 - 4(1)(b)": [ + "PRI-01.6" + ], + "Schedule 1 - 4(1)(c)": [ + "PRI-01.6" + ], + "Schedule 1 - 4(1)(d)": [ + "PRI-01.6" + ], + "Schedule 1 - 4(1)(e)": [ + "PRI-01.6" + ], + "28(1)": [ + "PRI-01.11" + ], + "28(2)": [ + "PRI-01.11" + ], + "28(3)": [ + "PRI-01.11" + ], + "28(4)": [ + "PRI-01.11" + ], + "28(4)(II)": [ + "PRI-01.11" + ], + "28(5)": [ + "PRI-01.11" + ], + "28(6)": [ + "PRI-01.11" + ], + "28(6)(a)": [ + "PRI-01.11" + ], + "28(6)(b)": [ + "PRI-01.11" + ], + "29(a)": [ + "PRI-01.11" + ], + "29(b)": [ + "PRI-01.11" + ], + "Schedule 1 - 1(1)(a)": [ + "PRI-01.11" + ], + "Schedule 1 - 1(1)(b)": [ + "PRI-01.11" + ], + "Schedule 1 - 1(1)(c)": [ + "PRI-01.11" + ], + "Schedule 1 - 1(2)(a)": [ + "PRI-01.11" + ], + "Schedule 1 - 1(2)(b)": [ + "PRI-01.11" + ], + "35C(2)": [ + "PRI-02" + ], + "35C(2)(a)": [ + "PRI-02" + ], + "35C(2)(a)(i)": [ + "PRI-02" + ], + "35C(2)(a)(ii)": [ + "PRI-02" + ], + "35C(2)(b)": [ + "PRI-02" + ], + "35C(2)(b)(i)": [ + "PRI-02" + ], + "35C(2)(b)(ii)": [ + "PRI-02" + ], + "35C(2)(c)": [ + "PRI-02" + ], + "35C(3)": [ + "PRI-02" + ], + "35C(4)": [ + "PRI-02" + ], + "35C(5)": [ + "PRI-02" + ], + "35J(2)": [ + "PRI-02" + ], + "35J(2)(a)": [ + "PRI-02" + ], + "35J(2)(a)(i)": [ + "PRI-02" + ], + "35J(2)(a)(ii)": [ + "PRI-02" + ], + "35J(2)(b)": [ + "PRI-02" + ], + "35J(2)(b)(i)": [ + "PRI-02" + ], + "35J(2)(b)(ii)": [ + "PRI-02" + ], + "35J(2)(b)(iii)": [ + "PRI-02" + ], + "35J(2)(b)(iv)": [ + "PRI-02" + ], + "35J(2)(c)": [ + "PRI-02" + ], + "35J(3)": [ + "PRI-02" + ], + "35J(4)": [ + "PRI-02" + ], + "35J(5)": [ + "PRI-02" + ], + "35J(5)(a)": [ + "PRI-02" + ], + "35J(5)(b)": [ + "PRI-02" + ], + "Schedule 1 - 1(3)(a)": [ + "PRI-02" + ], + "Schedule 1 - 1(3)(b)(ii)(B)": [ + "PRI-02" + ], + "Schedule 1 - 5": [ + "PRI-02" + ], + "Schedule 1 - 5(a)": [ + "PRI-02" + ], + "Schedule 1 - 5(b)": [ + "PRI-02" + ], + "Schedule 1 - 5(c)": [ + "PRI-02" + ], + "35E(1)": [ + "PRI-03" + ], + "35E(1)(a)": [ + "PRI-03" + ], + "35E(1)(b)": [ + "PRI-03" + ], + "35E(1)(b)(i)": [ + "PRI-03" + ], + "35E(1)(b)(ii)": [ + "PRI-03" + ], + "35E(1)(b)(iii)": [ + "PRI-03" + ], + "35E(1)(c)": [ + "PRI-03" + ], + "35E(2)": [ + "PRI-03" + ], + "35E(2)(a)": [ + "PRI-03" + ], + "35E(2)(b)": [ + "PRI-03" + ], + "35E(3)": [ + "PRI-03" + ], + "35E(4)": [ + "PRI-03" + ], + "Schedule 1 - 1(3)(a)(i)": [ + "PRI-03" ], - "Inferred": [ - "PRI-01" + "Schedule 1 - 1(3)(a)(ii)": [ + "PRI-03" ], - "Expectation": [ - "PRI-01" + "Schedule 1 - 1(3)(b)": [ + "PRI-03" ], - "Principle 1": [ - "PRI-02.1" + "Schedule 1 - 1(3)(b)(i)": [ + "PRI-03" ], - "Principle 2": [ + "Schedule 1 - 1(3)(b)(i)(A)": [ + "PRI-03" + ], + "Schedule 1 - 1(3)(b)(i)(B)": [ + "PRI-03" + ], + "Schedule 1 - 1(3)(b)(ii)": [ + "PRI-03" + ], + "Schedule 1 - 1(3)(b)(ii)(A)": [ + "PRI-03" + ], + "35G(1)": [ + "PRI-03.4" + ], + "35L(1)": [ + "PRI-03.4" + ], + "35L(1)(a)": [ + "PRI-03.4" + ], + "35L(1)(b)": [ + "PRI-03.4" + ], + "35L(2)": [ + "PRI-03.4" + ], + "35L(3)": [ + "PRI-03.4" + ], + "35L(4)": [ + "PRI-03.4" + ], + "Schedule 1 - 2(1)(b)(i)": [ + "PRI-03.9" + ], + "Schedule 1 - 2(1)(b)(ii)": [ + "PRI-03.9" + ], + "26(1)": [ + "PRI-05" + ], + "26(1)(a)": [ + "PRI-05" + ], + "26(1)(b)": [ + "PRI-05" + ], + "26(2)": [ "PRI-05" ], - "Sec 26": [ + "26(2)(a)": [ "PRI-05" ], - "Principle 3": [ + "26(2)(b)": [ "PRI-05" ], - "Sec 4": [ + "Schedule 1 - 2(2)": [ "PRI-05" ], - "Principle 6": [ + "Schedule 1 - 2(3)": [ + "PRI-05" + ], + "Schedule 1 - 2(1)(a)": [ + "PRI-05.2" + ], + "Schedule 1 - 2(1)(b)": [ + "PRI-05.2" + ], + "Schedule 1 - 2(1)(c)(i)": [ + "PRI-05.2" + ], + "Schedule 1 - 2(1)(c)(ii)": [ + "PRI-05.2" + ], + "Schedule 1 - 2(1)(c)(ii)(A)": [ + "PRI-05.2" + ], + "Schedule 1 - 2(1)(c)(ii)(B)": [ + "PRI-05.2" + ], + "35K(1)": [ + "PRI-05.4" + ], + "35K(1)(a)": [ + "PRI-05.4" + ], + "35K(1)(b)": [ + "PRI-05.4" + ], + "35K(1)(c)": [ + "PRI-05.4" + ], + "35K(2)": [ + "PRI-05.4" + ], + "35K(2)(a)": [ + "PRI-05.4" + ], + "35K(2)(b)": [ + "PRI-05.4" + ], + "35K(2)(c)": [ + "PRI-05.4" + ], + "35K(3)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(1)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(2)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(2)(a)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(2)(a)(i)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(2)(a)(ii)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(2)(a)(iii)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(2)(b)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(2)(c)": [ + "PRI-05.4" + ], + "Schedule 1 - 3(3)": [ + "PRI-05.4" + ], + "18(1)": [ + "PRI-06" + ], + "18(1)(a)": [ + "PRI-06" + ], + "18(1)(b)": [ + "PRI-06" + ], + "18(2)": [ + "PRI-06" + ], + "18(3)": [ + "PRI-06" + ], + "18(4)": [ + "PRI-06" + ], + "18(4)(a)": [ + "PRI-06" + ], + "18(4)(b)": [ + "PRI-06" + ], + "35G(3)": [ + "PRI-06" + ], + "Schedule 1 - 6": [ + "PRI-06" + ], + "Schedule 1 - 6(a)": [ + "PRI-06" + ], + "Schedule 1 - 6(b)": [ + "PRI-06" + ], + "Schedule 1 - 6(b)(i)": [ + "PRI-06" + ], + "Schedule 1 - 6(b)(ii)": [ + "PRI-06" + ], + "Schedule 1 - 6(b)(iii)": [ "PRI-06" ], - "Sec 17A": [ + "Schedule 1 - 6(b)(iv)": [ "PRI-06" ], - "Sec 18": [ + "Schedule 1 - 6(c)": [ "PRI-06" ], - "Sec 15": [ - "PRI-15" + "Schedule 1 - 6(d)": [ + "PRI-06" + ], + "Schedule 1 - 6(e)": [ + "PRI-06" + ], + "Schedule 1 - 6(f)": [ + "PRI-06" + ], + "Schedule 1 - 6(g)": [ + "PRI-06" + ], + "22(1)(a)": [ + "PRI-06.1" + ], + "22(1)(b)": [ + "PRI-06.1" + ], + "22(1A)": [ + "PRI-06.1" + ], + "22(2)": [ + "PRI-06.1" + ], + "22(2)(a)": [ + "PRI-06.1" + ], + "22(2)(b)": [ + "PRI-06.1" + ], + "22(3)": [ + "PRI-06.1" + ], + "22(4)": [ + "PRI-06.1" + ], + "23(1)": [ + "PRI-06.1" + ], + "23(1)(a)": [ + "PRI-06.1" + ], + "23(1)(c)(i)": [ + "PRI-06.1" + ], + "23(1)(c)(ii)": [ + "PRI-06.1" + ], + "23(2)": [ + "PRI-06.1" + ], + "23(2)(a)": [ + "PRI-06.1" + ], + "23(2)(a)(i)": [ + "PRI-06.1" + ], + "23(2)(a)(ii)": [ + "PRI-06.1" + ], + "23(2)(b)": [ + "PRI-06.1" + ], + "23(3)": [ + "PRI-06.1" + ], + "23(3)(a)": [ + "PRI-06.1" + ], + "23(3)(b)": [ + "PRI-06.1" + ], + "19(3)(b)": [ + "PRI-06.2" + ], + "19(3)(c)": [ + "PRI-06.2" + ], + "19(3)(c)(i)": [ + "PRI-06.2" + ], + "19(3)(c)(i)(A)": [ + "PRI-06.2" + ], + "19(3)(c)(i)(B)": [ + "PRI-06.2" + ], + "19(3)(c)(ii)": [ + "PRI-06.2" + ], + "19(3)(c)(iii)": [ + "PRI-06.2" + ], + "19(3)(c)(iii)(A)": [ + "PRI-06.2" + ], + "19(3)(c)(iii)(B)": [ + "PRI-06.2" + ], + "19(3)(c)(I)": [ + "PRI-06.2" + ], + "19(3)(c)(II)": [ + "PRI-06.2" + ], + "19(3)(c)(iv)": [ + "PRI-06.2" + ], + "19(3)(c)(v)": [ + "PRI-06.2" + ], + "23(1)(b)": [ + "PRI-06.2" + ], + "18(5)": [ + "PRI-06.4" + ], + "18(5)(a)": [ + "PRI-06.4" + ], + "18(5)(b)": [ + "PRI-06.4" + ], + "19(1)": [ + "PRI-06.4" + ], + "19(1)(a)": [ + "PRI-06.4" + ], + "19(1)(a)(i)": [ + "PRI-06.4" + ], + "19(1)(a)(ii)": [ + "PRI-06.4" + ], + "19(1)(b)": [ + "PRI-06.4" + ], + "19(3)": [ + "PRI-06.4" + ], + "19(3)(a)": [ + "PRI-06.4" + ], + "19(3)(a)(i)": [ + "PRI-06.4" + ], + "19(3)(a)(i)(A)": [ + "PRI-06.4" + ], + "19(3)(a)(i)(B)": [ + "PRI-06.4" + ], + "19(3)(a)(ii)": [ + "PRI-06.4" + ], + "19(4)": [ + "PRI-06.4" + ], + "19(4)(a)": [ + "PRI-06.4" + ], + "19(4)(b)": [ + "PRI-06.4" + ], + "19(4)(b)(i)": [ + "PRI-06.4" + ], + "19(4)(b)(ii)": [ + "PRI-06.4" + ], + "19(4)(b)(ii)(A)": [ + "PRI-06.4" + ], + "19(4)(b)(I)": [ + "PRI-06.4" + ], + "19(4)(b)(II)": [ + "PRI-06.4" + ], + "19(4)(b)(III)": [ + "PRI-06.4" + ], + "19(4)(b)(III)(B)": [ + "PRI-06.4" + ], + "21(1)": [ + "PRI-06.4" + ], + "21(1)(a)": [ + "PRI-06.4" + ], + "21(1)(b)": [ + "PRI-06.4" + ], + "21(1)(c)": [ + "PRI-06.4" + ], + "25(1)": [ + "PRI-06.4" + ], + "25(1)(b)": [ + "PRI-06.4" + ], + "Schedule 1 - 4(2)": [ + "PRI-07.1" + ], + "24(1)": [ + "PRI-07.4" + ], + "24(1)(a)": [ + "PRI-07.4" + ], + "24(1)(b)": [ + "PRI-07.4" + ], + "24(1)(b)(i)": [ + "PRI-07.4" + ], + "24(1)(b)(ii)": [ + "PRI-07.4" + ], + "24(2)": [ + "PRI-07.4" + ], + "24(3)": [ + "PRI-07.4" + ], + "24(3)(a)": [ + "PRI-07.4" + ], + "24(3)(b)": [ + "PRI-07.4" + ], + "24(3)(c)": [ + "PRI-07.4" + ], + "24(3)(d)": [ + "PRI-07.4" + ], + "24(3)(e)": [ + "PRI-07.4" + ], + "24(4)": [ + "PRI-07.4" + ], + "20(1)": [ + "PRI-07.5" + ], + "20(1)(a)": [ + "PRI-07.5" + ], + "20(1)(a)(i)": [ + "PRI-07.5" + ], + "20(1)(a)(ii)": [ + "PRI-07.5" + ], + "20(1)(a)(ii)(A)": [ + "PRI-07.5" + ], + "20(1)(a)(ii)(B)": [ + "PRI-07.5" + ], + "20(1)(b)": [ + "PRI-07.5" + ], + "20(1)(c)": [ + "PRI-07.5" + ], + "20(2)(a)": [ + "PRI-07.5" + ], + "20(2)(b)": [ + "PRI-07.5" + ], + "20(3)": [ + "PRI-07.5" + ], + "20(3)(a)": [ + "PRI-07.5" + ], + "20(3)(b)": [ + "PRI-07.5" + ], + "20(3)(c)": [ + "PRI-07.5" + ], + "20(3)(c)(i)": [ + "PRI-07.5" + ], + "20(3)(c)(ii)": [ + "PRI-07.5" + ], + "20(3)(c)(iii)": [ + "PRI-07.5" + ], + "20(3)(d)": [ + "PRI-07.5" + ], + "20(3)(e)": [ + "PRI-07.5" + ], + "20(3)(f)": [ + "PRI-07.5" + ], + "25(1)(a)": [ + "PRI-07.5" + ], + "27(1)": [ + "PRI-14" + ], + "27(1)(a)": [ + "PRI-14" + ], + "27(1)(b)": [ + "PRI-14" + ], + "27(1)(c)": [ + "PRI-14" + ], + "27(1)(c)(i)": [ + "PRI-14" + ], + "27(1)(c)(ii)": [ + "PRI-14" + ], + "27(2)": [ + "PRI-14" + ], + "27(2)(a)": [ + "PRI-14" + ], + "27(2)(b)": [ + "PRI-14" + ], + "27(2)(c)": [ + "PRI-14" + ], + "27(2)(d)": [ + "PRI-14" + ], + "27(3)": [ + "PRI-14" + ], + "27(3)(a)": [ + "PRI-14" + ], + "27(3)(b)": [ + "PRI-14" + ], + "27(3)(c)": [ + "PRI-14" + ], + "27(3)(d)": [ + "PRI-14" + ], + "27(4)": [ + "PRI-14" + ], + "27(4)(a)": [ + "PRI-14" + ], + "27(4)(b)": [ + "PRI-14" ] } } diff --git a/docs/api/crosswalks/apac-ind-dpdpa-2023.json b/docs/api/crosswalks/apac-ind-dpdpa-2023.json index f29f09fe..321b0d7f 100644 --- a/docs/api/crosswalks/apac-ind-dpdpa-2023.json +++ b/docs/api/crosswalks/apac-ind-dpdpa-2023.json @@ -1,6 +1,6 @@ { "framework_id": "apac-ind-dpdpa-2023", - "display_name": "India - DPDPA (2023)", + "display_name": "India Digital Personal Data Protection Act (2023)", "scf_to_framework": { "total_mappings": 41, "mappings": { diff --git a/docs/api/crosswalks/apac-ind-privacy-rules-2011.json b/docs/api/crosswalks/apac-ind-privacy-rules-2011.json index 376d9dc4..521504d1 100644 --- a/docs/api/crosswalks/apac-ind-privacy-rules-2011.json +++ b/docs/api/crosswalks/apac-ind-privacy-rules-2011.json @@ -1,81 +1,169 @@ { "framework_id": "apac-ind-privacy-rules-2011", - "display_name": "India - Privacy Rules (2011)", + "display_name": "India - Information Technology Rules (Privacy Rules) (2011)", "scf_to_framework": { - "total_mappings": 12, + "total_mappings": 13, "mappings": { - "GOV-01": [ - "8" + "CPL-07": [ + "5(9)" ], - "CPL-01": [ - "8" + "DCH-03.1": [ + "6(1)", + "6(2)", + "6(3)" ], - "CPL-02": [ - "8" + "PRI-01": [ + "8(1)" ], - "DCH-01": [ - "7", - "8" + "PRI-01.5": [ + "7" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-01.6": [ + "5(8)", + "8(2)" + ], + "PRI-01.11": [ + "4(v)", + "8(1)", + "8(4)" + ], + "PRI-02": [ + "4", + "4(i)", + "4(ii)", + "4(iii)", + "4(iv)", + "4(v)", + "5(3)", + "5(3)(a)", + "5(3)(b)", + "5(3)(c)", + "5(3)(d)", + "5(3)(d)(i)", + "5(3)(d)(ii)" ], "PRI-03": [ - "5" + "5(1)", + "5(7)" ], "PRI-04": [ - "5" - ], - "PRI-04.1": [ - "5" + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(5)" ], "PRI-05": [ - "5" + "5(4)" ], - "SEA-01": [ - "7", - "8" + "PRI-05.2": [ + "5(6)" ], - "SEA-02": [ - "7", - "8" + "PRI-06.4": [ + "5(9)" ], - "SEA-03": [ - "7", - "8" + "PRI-07.1": [ + "6(4)" ] } }, "framework_to_scf": { - "total_mappings": 5, + "total_mappings": 31, "mappings": { - "5": [ - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05" + "4": [ + "PRI-02" ], "7": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "8": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" + "PRI-01.5" + ], + "5(9)": [ + "CPL-07", + "PRI-06.4" + ], + "6(1)": [ + "DCH-03.1" + ], + "6(2)": [ + "DCH-03.1" + ], + "6(3)": [ + "DCH-03.1" + ], + "8(1)": [ + "PRI-01", + "PRI-01.11" + ], + "5(8)": [ + "PRI-01.6" + ], + "8(2)": [ + "PRI-01.6" + ], + "4(v)": [ + "PRI-01.11", + "PRI-02" + ], + "8(4)": [ + "PRI-01.11" + ], + "4(i)": [ + "PRI-02" + ], + "4(ii)": [ + "PRI-02" + ], + "4(iii)": [ + "PRI-02" + ], + "4(iv)": [ + "PRI-02" + ], + "5(3)": [ + "PRI-02" + ], + "5(3)(a)": [ + "PRI-02" + ], + "5(3)(b)": [ + "PRI-02" + ], + "5(3)(c)": [ + "PRI-02" + ], + "5(3)(d)": [ + "PRI-02" + ], + "5(3)(d)(i)": [ + "PRI-02" + ], + "5(3)(d)(ii)": [ + "PRI-02" + ], + "5(1)": [ + "PRI-03" + ], + "5(7)": [ + "PRI-03" + ], + "5(2)": [ + "PRI-04" + ], + "5(2)(a)": [ + "PRI-04" + ], + "5(2)(b)": [ + "PRI-04" + ], + "5(5)": [ + "PRI-04" + ], + "5(4)": [ + "PRI-05" + ], + "5(6)": [ + "PRI-05.2" + ], + "6(4)": [ + "PRI-07.1" ] } } diff --git a/docs/api/crosswalks/apac-ind-sebi-2024.json b/docs/api/crosswalks/apac-ind-sebi-2024.json index 59574e57..c6270a9d 100644 --- a/docs/api/crosswalks/apac-ind-sebi-2024.json +++ b/docs/api/crosswalks/apac-ind-sebi-2024.json @@ -1,6 +1,6 @@ { "framework_id": "apac-ind-sebi-2024", - "display_name": "India - SEBI CSCRF (2024)", + "display_name": "India - SEBI Cybersecurity and Cyber Resilience Framework (2024)", "scf_to_framework": { "total_mappings": 170, "mappings": { diff --git a/docs/api/crosswalks/apac-jpn-appi-2020.json b/docs/api/crosswalks/apac-jpn-appi-2020.json new file mode 100644 index 00000000..777b9f24 --- /dev/null +++ b/docs/api/crosswalks/apac-jpn-appi-2020.json @@ -0,0 +1,508 @@ +{ + "framework_id": "apac-jpn-appi-2020", + "display_name": "Japan - Act on the Protection of Personal Information (2020)", + "scf_to_framework": { + "total_mappings": 34, + "mappings": { + "GOV-17": [ + "IV.5.53(2)" + ], + "CPL-01": [ + "IV.1.16-2", + "IV.1.26(1)", + "IV.1.26(1)(i)", + "IV.1.26(1)(ii)", + "IV.1.26(2)" + ], + "CPL-07": [ + "IV.5.52(1)", + "IV.5.52(2)", + "IV.5.52(3)" + ], + "DCH-22.1": [ + "IV.1.29(3)" + ], + "HRS-01": [ + "IV.1.21", + "IV.1.22" + ], + "IAC-09.6": [ + "IV.2.35-2(1)" + ], + "IRO-10": [ + "IV.1.22-2(2)" + ], + "IRO-10.2": [ + "IV.1.22-2(1)" + ], + "PRI-01": [ + "IV.5.53(1)" + ], + "PRI-01.3": [ + "IV.5.53(3)" + ], + "PRI-01.5": [ + "IV.1.24(1)", + "IV.1.24(2)", + "IV.1.24(3)" + ], + "PRI-01.6": [ + "IV.1.20" + ], + "PRI-01.11": [ + "IV.1.17(1)", + "IV.1.26-2(1)", + "IV.2.35-2(7)", + "IV.2.35-2(8)", + "IV.2.35-3(1)", + "IV.3.36(1)", + "IV.3.36(2)", + "IV.3.36(3)", + "IV.3.36(4)", + "IV.3.36(5)", + "IV.3.36(6)", + "IV.3.37", + "IV.3.38", + "IV.3.39", + "IV.5.54" + ], + "PRI-02": [ + "IV.1.18(1)", + "IV.1.18(2)", + "IV.1.18(3)", + "IV.1.23(2)", + "IV.1.23(2)(i)", + "IV.1.23(2)(ii)", + "IV.1.23(2)(iii)", + "IV.1.23(2)(iv)", + "IV.1.23(2)(v)", + "IV.1.23(2)(vi)", + "IV.1.23(2)(vii)", + "IV.1.23(2)(viii)", + "IV.1.27(1)", + "IV.1.27(1)(i)", + "IV.1.27(1)(ii)", + "IV.1.27(1)(iii)", + "IV.1.27(1)(iv)" + ], + "PRI-02.1": [ + "IV.1.15(1)" + ], + "PRI-03": [ + "IV.1.26-2(1)(i)", + "IV.1.26-2(1)(ii)" + ], + "PRI-03.1": [ + "IV.1.30(5)" + ], + "PRI-03.2": [ + "IV.1.16(2)" + ], + "PRI-03.3": [ + "IV.1.23(1)" + ], + "PRI-03.4": [ + "IV.1.30(1)" + ], + "PRI-03.9": [ + "IV.1.30(2)", + "IV.1.30(4)", + "IV.1.30(6)", + "IV.1.30(7)", + "IV.1.31" + ], + "PRI-03.11": [ + "IV.1.23(3)", + "IV.1.23(6)", + "IV.1.30(3)" + ], + "PRI-04": [ + "IV.1.15(2)" + ], + "PRI-05": [ + "IV.2.35-2(5)" + ], + "PRI-05.2": [ + "IV.1.19" + ], + "PRI-05.3": [ + "IV.2.35-2(1)" + ], + "PRI-05.4": [ + "IV.1.16(1)", + "IV.1.17(2)", + "IV.1.17(2)(i)", + "IV.1.17(2)(ii)", + "IV.1.17(2)(iii)", + "IV.1.17(2)(iv)", + "IV.1.17(2)(v)", + "IV.1.17(2)(vi)", + "IV.1.23(1)(i)", + "IV.1.23(1)(ii)", + "IV.1.23(1)(iii)", + "IV.1.23(1)(iv)" + ], + "PRI-06": [ + "IV.1.28(1)" + ], + "PRI-06.1": [ + "IV.1.29(1)", + "IV.1.29(2)" + ], + "PRI-06.4": [ + "IV.1.27(2)", + "IV.1.27(2)(i)", + "IV.1.27(2)(ii)", + "IV.1.27(3)", + "IV.1.28(2)", + "IV.1.28(3)", + "IV.1.35(1)", + "IV.1.35(2)" + ], + "PRI-07.5": [ + "IV.1.28(2)(i)", + "IV.1.28(2)(ii)", + "IV.1.28(2)(iii)" + ], + "PRI-14.1": [ + "IV.1.25(1)", + "IV.1.25(2)", + "IV.1.26(3)", + "IV.1.26(4)" + ], + "PRI-18": [ + "IV.1.32(1)", + "IV.1.32(2)", + "IV.1.32(3)", + "IV.1.32(4)" + ], + "TPM-09": [ + "IV.5.53(4)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 106, + "mappings": { + "IV.5.53(2)": [ + "GOV-17" + ], + "IV.1.16-2": [ + "CPL-01" + ], + "IV.1.26(1)": [ + "CPL-01" + ], + "IV.1.26(1)(i)": [ + "CPL-01" + ], + "IV.1.26(1)(ii)": [ + "CPL-01" + ], + "IV.1.26(2)": [ + "CPL-01" + ], + "IV.5.52(1)": [ + "CPL-07" + ], + "IV.5.52(2)": [ + "CPL-07" + ], + "IV.5.52(3)": [ + "CPL-07" + ], + "IV.1.29(3)": [ + "DCH-22.1" + ], + "IV.1.21": [ + "HRS-01" + ], + "IV.1.22": [ + "HRS-01" + ], + "IV.2.35-2(1)": [ + "IAC-09.6", + "PRI-05.3" + ], + "IV.1.22-2(2)": [ + "IRO-10" + ], + "IV.1.22-2(1)": [ + "IRO-10.2" + ], + "IV.5.53(1)": [ + "PRI-01" + ], + "IV.5.53(3)": [ + "PRI-01.3" + ], + "IV.1.24(1)": [ + "PRI-01.5" + ], + "IV.1.24(2)": [ + "PRI-01.5" + ], + "IV.1.24(3)": [ + "PRI-01.5" + ], + "IV.1.20": [ + "PRI-01.6" + ], + "IV.1.17(1)": [ + "PRI-01.11" + ], + "IV.1.26-2(1)": [ + "PRI-01.11" + ], + "IV.2.35-2(7)": [ + "PRI-01.11" + ], + "IV.2.35-2(8)": [ + "PRI-01.11" + ], + "IV.2.35-3(1)": [ + "PRI-01.11" + ], + "IV.3.36(1)": [ + "PRI-01.11" + ], + "IV.3.36(2)": [ + "PRI-01.11" + ], + "IV.3.36(3)": [ + "PRI-01.11" + ], + "IV.3.36(4)": [ + "PRI-01.11" + ], + "IV.3.36(5)": [ + "PRI-01.11" + ], + "IV.3.36(6)": [ + "PRI-01.11" + ], + "IV.3.37": [ + "PRI-01.11" + ], + "IV.3.38": [ + "PRI-01.11" + ], + "IV.3.39": [ + "PRI-01.11" + ], + "IV.5.54": [ + "PRI-01.11" + ], + "IV.1.18(1)": [ + "PRI-02" + ], + "IV.1.18(2)": [ + "PRI-02" + ], + "IV.1.18(3)": [ + "PRI-02" + ], + "IV.1.23(2)": [ + "PRI-02" + ], + "IV.1.23(2)(i)": [ + "PRI-02" + ], + "IV.1.23(2)(ii)": [ + "PRI-02" + ], + "IV.1.23(2)(iii)": [ + "PRI-02" + ], + "IV.1.23(2)(iv)": [ + "PRI-02" + ], + "IV.1.23(2)(v)": [ + "PRI-02" + ], + "IV.1.23(2)(vi)": [ + "PRI-02" + ], + "IV.1.23(2)(vii)": [ + "PRI-02" + ], + "IV.1.23(2)(viii)": [ + "PRI-02" + ], + "IV.1.27(1)": [ + "PRI-02" + ], + "IV.1.27(1)(i)": [ + "PRI-02" + ], + "IV.1.27(1)(ii)": [ + "PRI-02" + ], + "IV.1.27(1)(iii)": [ + "PRI-02" + ], + "IV.1.27(1)(iv)": [ + "PRI-02" + ], + "IV.1.15(1)": [ + "PRI-02.1" + ], + "IV.1.26-2(1)(i)": [ + "PRI-03" + ], + "IV.1.26-2(1)(ii)": [ + "PRI-03" + ], + "IV.1.30(5)": [ + "PRI-03.1" + ], + "IV.1.16(2)": [ + "PRI-03.2" + ], + "IV.1.23(1)": [ + "PRI-03.3" + ], + "IV.1.30(1)": [ + "PRI-03.4" + ], + "IV.1.30(2)": [ + "PRI-03.9" + ], + "IV.1.30(4)": [ + "PRI-03.9" + ], + "IV.1.30(6)": [ + "PRI-03.9" + ], + "IV.1.30(7)": [ + "PRI-03.9" + ], + "IV.1.31": [ + "PRI-03.9" + ], + "IV.1.23(3)": [ + "PRI-03.11" + ], + "IV.1.23(6)": [ + "PRI-03.11" + ], + "IV.1.30(3)": [ + "PRI-03.11" + ], + "IV.1.15(2)": [ + "PRI-04" + ], + "IV.2.35-2(5)": [ + "PRI-05" + ], + "IV.1.19": [ + "PRI-05.2" + ], + "IV.1.16(1)": [ + "PRI-05.4" + ], + "IV.1.17(2)": [ + "PRI-05.4" + ], + "IV.1.17(2)(i)": [ + "PRI-05.4" + ], + "IV.1.17(2)(ii)": [ + "PRI-05.4" + ], + "IV.1.17(2)(iii)": [ + "PRI-05.4" + ], + "IV.1.17(2)(iv)": [ + "PRI-05.4" + ], + "IV.1.17(2)(v)": [ + "PRI-05.4" + ], + "IV.1.17(2)(vi)": [ + "PRI-05.4" + ], + "IV.1.23(1)(i)": [ + "PRI-05.4" + ], + "IV.1.23(1)(ii)": [ + "PRI-05.4" + ], + "IV.1.23(1)(iii)": [ + "PRI-05.4" + ], + "IV.1.23(1)(iv)": [ + "PRI-05.4" + ], + "IV.1.28(1)": [ + "PRI-06" + ], + "IV.1.29(1)": [ + "PRI-06.1" + ], + "IV.1.29(2)": [ + "PRI-06.1" + ], + "IV.1.27(2)": [ + "PRI-06.4" + ], + "IV.1.27(2)(i)": [ + "PRI-06.4" + ], + "IV.1.27(2)(ii)": [ + "PRI-06.4" + ], + "IV.1.27(3)": [ + "PRI-06.4" + ], + "IV.1.28(2)": [ + "PRI-06.4" + ], + "IV.1.28(3)": [ + "PRI-06.4" + ], + "IV.1.35(1)": [ + "PRI-06.4" + ], + "IV.1.35(2)": [ + "PRI-06.4" + ], + "IV.1.28(2)(i)": [ + "PRI-07.5" + ], + "IV.1.28(2)(ii)": [ + "PRI-07.5" + ], + "IV.1.28(2)(iii)": [ + "PRI-07.5" + ], + "IV.1.25(1)": [ + "PRI-14.1" + ], + "IV.1.25(2)": [ + "PRI-14.1" + ], + "IV.1.26(3)": [ + "PRI-14.1" + ], + "IV.1.26(4)": [ + "PRI-14.1" + ], + "IV.1.32(1)": [ + "PRI-18" + ], + "IV.1.32(2)": [ + "PRI-18" + ], + "IV.1.32(3)": [ + "PRI-18" + ], + "IV.1.32(4)": [ + "PRI-18" + ], + "IV.5.53(4)": [ + "TPM-09" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/apac-jpn-ismap.json b/docs/api/crosswalks/apac-jpn-ismap.json index 2495583b..c8a5e078 100644 --- a/docs/api/crosswalks/apac-jpn-ismap.json +++ b/docs/api/crosswalks/apac-jpn-ismap.json @@ -985,6 +985,7 @@ ], "IAC-16": [ "9.2.3", + "9.2.3.1", "9.2.3.2", "9.2.3.3", "9.2.3.4", @@ -1930,7 +1931,7 @@ } }, "framework_to_scf": { - "total_mappings": 1312, + "total_mappings": 1313, "mappings": { "5": [ "GOV-02" @@ -4113,6 +4114,9 @@ "9.2.3": [ "IAC-16" ], + "9.2.3.1": [ + "IAC-16" + ], "9.2.3.2": [ "IAC-16" ], diff --git a/docs/api/crosswalks/apac-jpn-ppi-2020.json b/docs/api/crosswalks/apac-jpn-ppi-2020.json deleted file mode 100644 index fee793d0..00000000 --- a/docs/api/crosswalks/apac-jpn-ppi-2020.json +++ /dev/null @@ -1,1204 +0,0 @@ -{ - "framework_id": "apac-jpn-ppi-2020", - "display_name": "Japan - Act on the Protection of Personal Information (2020)", - "scf_to_framework": { - "total_mappings": 58, - "mappings": { - "GOV-01": [ - "20" - ], - "CLD-09": [ - "24(1)" - ], - "CPL-01": [ - "20", - "21", - "22", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" - ], - "CPL-01.1": [ - "40(1)", - "40(2)", - "40(3)" - ], - "CPL-02": [ - "21" - ], - "CPL-03": [ - "40(1)", - "40(2)", - "40(3)" - ], - "DCH-01": [ - "20" - ], - "DCH-01.1": [ - "21" - ], - "DCH-19": [ - "24(1)" - ], - "DCH-22.1": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" - ], - "DCH-22.3": [ - "17(1)" - ], - "DCH-23": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" - ], - "DCH-24": [ - "20" - ], - "DCH-25": [ - "24(1)" - ], - "HRS-01": [ - "21" - ], - "HRS-03": [ - "21" - ], - "HRS-05.1": [ - "21" - ], - "HRS-06": [ - "21" - ], - "HRS-06.1": [ - "21" - ], - "IAC-09.6": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" - ], - "IRO-04.1": [ - "22-2(1)", - "22-2(2)" - ], - "IAO-03.2": [ - "22" - ], - "PRI-01": [ - "24(3)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" - ], - "PRI-01.1": [ - "21" - ], - "PRI-01.6": [ - "20", - "21" - ], - "PRI-02": [ - "15(1)", - "15(2)" - ], - "PRI-02.1": [ - "15(1)", - "15(2)" - ], - "PRI-03": [ - "16(1)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)", - "24(1)", - "24(2)" - ], - "PRI-03.2": [ - "16(2)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" - ], - "PRI-03.6": [ - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" - ], - "PRI-04": [ - "17(1)" - ], - "PRI-04.1": [ - "17(1)", - "17(2)", - "17(2)(i)", - "17(2)(ii)", - "17(2)(iii)", - "17(2)(iv)", - "17(2)(v)", - "17(2)(vi)" - ], - "PRI-04.4": [ - "18(1)", - "18(2)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)" - ], - "PRI-05": [ - "19" - ], - "PRI-05.1": [ - "16-2" - ], - "PRI-05.2": [ - "19" - ], - "PRI-05.4": [ - "16-2" - ], - "PRI-06": [ - "27(1)", - "27(1)(i)", - "27(1)(ii)", - "27(1)(iii)", - "27(1)(iv)", - "27(2)(i)", - "27(2)(ii)", - "27(3)", - "28(1)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)" - ], - "PRI-06.1": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" - ], - "PRI-06.2": [ - "18(3)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)", - "29(1)", - "29(2)", - "29(3)" - ], - "PRI-06.3": [ - "31" - ], - "PRI-06.4": [ - "27(3)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)", - "31", - "32(1)", - "32(2)", - "32(3)", - "32(4)" - ], - "PRI-06.5": [ - "30(1)", - "30(2)", - "30(3)", - "30(4)", - "30(5)", - "30(6)", - "30(7)", - "33(1)", - "33(2)", - "34", - "34(1)", - "34(2)", - "34(3)", - "35(1)", - "35(2)" - ], - "PRI-07": [ - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" - ], - "PRI-07.1": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" - ], - "PRI-07.2": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" - ], - "PRI-07.3": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], - "PRI-14.1": [ - "25(1)", - "25(2)" - ], - "SEA-01": [ - "20" - ], - "SEA-02": [ - "20" - ], - "SEA-03": [ - "20" - ], - "SEA-15": [ - "20" - ], - "TPM-01": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "24(3)" - ], - "TPM-04": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], - "TPM-04.4": [ - "20" - ], - "TPM-05": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], - "TPM-08": [ - "24(3)" - ], - "TPM-10": [ - "24(3)" - ] - } - }, - "framework_to_scf": { - "total_mappings": 134, - "mappings": { - "19": [ - "PRI-05", - "PRI-05.2" - ], - "20": [ - "GOV-01", - "CPL-01", - "DCH-01", - "DCH-24", - "PRI-01.6", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "21": [ - "CPL-01", - "CPL-02", - "DCH-01.1", - "HRS-01", - "HRS-03", - "HRS-05.1", - "HRS-06", - "HRS-06.1", - "PRI-01.1", - "PRI-01.6" - ], - "22": [ - "CPL-01", - "IAO-03.2", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "31": [ - "PRI-06.3", - "PRI-06.4" - ], - "34": [ - "PRI-06.5" - ], - "36": [ - "CPL-01", - "PRI-01" - ], - "37": [ - "CPL-01", - "DCH-23", - "IAC-09.6", - "PRI-01" - ], - "38": [ - "CPL-01", - "DCH-23", - "IAC-09.6", - "PRI-01" - ], - "39": [ - "CPL-01", - "DCH-23", - "IAC-09.6", - "PRI-01" - ], - "54": [ - "CPL-01", - "PRI-01" - ], - "55": [ - "CPL-01", - "PRI-01" - ], - "24(1)": [ - "CLD-09", - "DCH-19", - "DCH-25", - "PRI-03" - ], - "26(1)": [ - "CPL-01", - "DCH-22.1", - "PRI-01", - "PRI-06.1", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26(1)(i)": [ - "CPL-01", - "DCH-22.1", - "PRI-01", - "PRI-06.1", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26(1)(ii)": [ - "CPL-01", - "DCH-22.1", - "PRI-01", - "PRI-06.1", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26(2)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26(3)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26(4)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26-2(1)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26-2(1)(i)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26-2(1)(ii)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26-2(2)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "26-2(3)": [ - "CPL-01", - "PRI-01", - "PRI-07", - "PRI-07.1", - "PRI-07.2" - ], - "51(1)": [ - "CPL-01", - "PRI-01" - ], - "51(2)": [ - "CPL-01", - "PRI-01" - ], - "52(1)": [ - "CPL-01", - "PRI-01" - ], - "53(2)": [ - "CPL-01", - "PRI-01" - ], - "53(3)": [ - "CPL-01", - "PRI-01" - ], - "53(1)": [ - "CPL-01", - "PRI-01" - ], - "53(4)": [ - "CPL-01", - "PRI-01" - ], - "40(1)": [ - "CPL-01.1", - "CPL-03" - ], - "40(2)": [ - "CPL-01.1", - "CPL-03" - ], - "40(3)": [ - "CPL-01.1", - "CPL-03" - ], - "29(1)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" - ], - "29(2)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" - ], - "29(3)": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" - ], - "17(1)": [ - "DCH-22.3", - "PRI-04", - "PRI-04.1" - ], - "35-2(1)": [ - "DCH-23", - "IAC-09.6" - ], - "35-2(2)": [ - "DCH-23", - "IAC-09.6" - ], - "35-2(3)": [ - "DCH-23", - "IAC-09.6" - ], - "35-2(4)": [ - "DCH-23", - "IAC-09.6" - ], - "35-2(5)": [ - "DCH-23", - "IAC-09.6" - ], - "35-2(6)": [ - "DCH-23", - "IAC-09.6" - ], - "35-2(7)": [ - "DCH-23", - "IAC-09.6" - ], - "35-2(8)": [ - "DCH-23", - "IAC-09.6" - ], - "35-2(9)": [ - "DCH-23", - "IAC-09.6" - ], - "36(1)": [ - "DCH-23", - "IAC-09.6" - ], - "36(2)": [ - "DCH-23", - "IAC-09.6" - ], - "36(3)": [ - "DCH-23", - "IAC-09.6" - ], - "36(4)": [ - "DCH-23", - "IAC-09.6" - ], - "22-2(1)": [ - "IRO-04.1" - ], - "22-2(2)": [ - "IRO-04.1" - ], - "24(3)": [ - "PRI-01", - "TPM-01", - "TPM-08", - "TPM-10" - ], - "15(1)": [ - "PRI-02", - "PRI-02.1" - ], - "15(2)": [ - "PRI-02", - "PRI-02.1" - ], - "16(1)": [ - "PRI-03" - ], - "16(3)(i)": [ - "PRI-03", - "PRI-03.2", - "PRI-03.6" - ], - "16(3)(ii)": [ - "PRI-03", - "PRI-03.2", - "PRI-03.6" - ], - "16(3)(iii)": [ - "PRI-03", - "PRI-03.2", - "PRI-03.6" - ], - "16(3)(iv)": [ - "PRI-03", - "PRI-03.2", - "PRI-03.6" - ], - "24(2)": [ - "PRI-03" - ], - "16(2)": [ - "PRI-03.2" - ], - "17(2)": [ - "PRI-04.1" - ], - "17(2)(i)": [ - "PRI-04.1" - ], - "17(2)(ii)": [ - "PRI-04.1" - ], - "17(2)(iii)": [ - "PRI-04.1" - ], - "17(2)(iv)": [ - "PRI-04.1" - ], - "17(2)(v)": [ - "PRI-04.1" - ], - "17(2)(vi)": [ - "PRI-04.1" - ], - "18(1)": [ - "PRI-04.4" - ], - "18(2)": [ - "PRI-04.4" - ], - "18(4)(i)": [ - "PRI-04.4", - "PRI-06.2" - ], - "18(4)(ii)": [ - "PRI-04.4", - "PRI-06.2" - ], - "18(4)(iii)": [ - "PRI-04.4", - "PRI-06.2" - ], - "18(4)(iv)": [ - "PRI-04.4", - "PRI-06.2" - ], - "16-2": [ - "PRI-05.1", - "PRI-05.4" - ], - "27(1)": [ - "PRI-06" - ], - "27(1)(i)": [ - "PRI-06" - ], - "27(1)(ii)": [ - "PRI-06" - ], - "27(1)(iii)": [ - "PRI-06" - ], - "27(1)(iv)": [ - "PRI-06" - ], - "27(2)(i)": [ - "PRI-06" - ], - "27(2)(ii)": [ - "PRI-06" - ], - "27(3)": [ - "PRI-06", - "PRI-06.4" - ], - "28(1)": [ - "PRI-06" - ], - "28(2)": [ - "PRI-06", - "PRI-06.4" - ], - "28(2)(i)": [ - "PRI-06", - "PRI-06.4" - ], - "28(2)(ii)": [ - "PRI-06", - "PRI-06.4" - ], - "28(2)(iii)": [ - "PRI-06", - "PRI-06.4" - ], - "28(3)": [ - "PRI-06", - "PRI-06.4" - ], - "28(4)": [ - "PRI-06", - "PRI-06.4" - ], - "28(5)": [ - "PRI-06", - "PRI-06.4" - ], - "18(3)": [ - "PRI-06.2" - ], - "32(1)": [ - "PRI-06.4" - ], - "32(2)": [ - "PRI-06.4" - ], - "32(3)": [ - "PRI-06.4" - ], - "32(4)": [ - "PRI-06.4" - ], - "30(1)": [ - "PRI-06.5" - ], - "30(2)": [ - "PRI-06.5" - ], - "30(3)": [ - "PRI-06.5" - ], - "30(4)": [ - "PRI-06.5" - ], - "30(5)": [ - "PRI-06.5" - ], - "30(6)": [ - "PRI-06.5" - ], - "30(7)": [ - "PRI-06.5" - ], - "33(1)": [ - "PRI-06.5" - ], - "33(2)": [ - "PRI-06.5" - ], - "34(1)": [ - "PRI-06.5" - ], - "34(2)": [ - "PRI-06.5" - ], - "34(3)": [ - "PRI-06.5" - ], - "35(1)": [ - "PRI-06.5" - ], - "35(2)": [ - "PRI-06.5" - ], - "23(1)(i)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(1)(ii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(1)(iii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(1)(iv)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)(i)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)(ii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)(iii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)(iv)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)(v)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)(vi)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)(vii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(2)(viii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(3)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(4)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(5)(i)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(5)(ii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(5)(iii)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(6)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "23(1)": [ - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "TPM-01", - "TPM-04", - "TPM-05" - ], - "25(1)": [ - "PRI-14.1" - ], - "25(2)": [ - "PRI-14.1" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/apac-kor-pipa-2011.json b/docs/api/crosswalks/apac-kor-pipa-2011.json index ea773784..c67c80f4 100644 --- a/docs/api/crosswalks/apac-kor-pipa-2011.json +++ b/docs/api/crosswalks/apac-kor-pipa-2011.json @@ -2,272 +2,662 @@ "framework_id": "apac-kor-pipa-2011", "display_name": "South Korea - Personal Information Protection Act (PIPA) (2011)", "scf_to_framework": { - "total_mappings": 37, + "total_mappings": 24, "mappings": { - "GOV-01": [ - "3", - "29", - "30" + "DCH-18.1": [ + "III.1.16(1)" ], - "CPL-01": [ - "3", - "29" - ], - "DCH-22.1": [ - "4", - "36" - ], - "DCH-24": [ - "17", - "27" - ], - "DCH-24.1": [ - "17", - "27" - ], - "DCH-25": [ - "17", - "26", - "27" - ], - "IRO-04": [ - "34" + "HRS-01": [ + "III.2.28(1)" ], "IRO-04.1": [ - "34" + "IV.34(2)" ], - "PRI-01": [ - "3", - "30" + "IRO-10": [ + "IV.34(1)", + "IV.34(1)1", + "IV.34(1)2", + "IV.34(1)3", + "IV.34(1)4", + "IV.34(1)5", + "IV.34(3)" ], "PRI-01.1": [ - "31" + "IV.31(1)", + "IV.31(2)", + "IV.31(2)1", + "IV.31(2)2", + "IV.31(2)3", + "IV.31(2)4", + "IV.31(2)5", + "IV.31(2)6", + "IV.31(2)7", + "IV.31(3)", + "IV.31(4)", + "IV.31(5)" + ], + "PRI-01.11": [ + "I.3(1)", + "I.3(2)", + "I.3(3)", + "I.3(4)", + "I.3(5)", + "I.3(6)", + "I.3(7)", + "I.3(8)", + "I.4", + "I.4.1", + "I.4.2", + "I.4.3", + "I.4.4", + "I.4.5", + "III.2.23", + "III.2.24(1)", + "III.2.24(1)1", + "III.2.24(1)2", + "III.2.24(2)", + "III.2.24(3)", + "III.2.24(4)", + "IV.29", + "V.38(3)", + "V.38(4)", + "V.38(5)", + "VIII.60" ], "PRI-02": [ - "3", - "4" - ], - "PRI-02.1": [ - "3", - "4" + "III.1.18(3)", + "III.1.18(3)1", + "III.1.18(3)2", + "III.1.18(3)3", + "III.1.18(3)4", + "III.1.18(3)5", + "IV.30(1)", + "IV.30(1)1", + "IV.30(1)2", + "IV.30(1)3", + "IV.30(1)4", + "IV.30(1)5", + "IV.30(1)6", + "IV.30(2)", + "IV.30(3)" ], "PRI-03": [ - "3", - "4", - "22" + "III.1.15(2)", + "III.1.15(2)1", + "III.1.15(2)2", + "III.1.15(2)3", + "III.1.15(2)4", + "III.1.17(1)", + "III.1.17(1)1", + "III.1.17(1)2", + "III.1.17(2)", + "III.1.17(2)1", + "III.1.17(2)2", + "III.1.17(2)3", + "III.1.17(2)4", + "III.1.17(2)5", + "III.1.17(3)", + "III.1.22(3)" + ], + "PRI-03.1": [ + "III.1.22(2)" ], "PRI-03.2": [ - "22" + "III.1.20(1)", + "III.1.20(1)1", + "III.1.20(1)2", + "III.1.20(1)3", + "III.1.22(1)" ], - "PRI-04": [ - "3", - "15", - "22" + "PRI-03.4": [ + "V.37(1)" ], - "PRI-04.1": [ - "3", - "15" + "PRI-03.5": [ + "III.1.16(2)", + "III.1.22(4)" ], - "PRI-05": [ - "3", - "4", - "15", - "19", - "21", - "37" + "PRI-03.6": [ + "V.38(1)", + "V.38(2)" ], - "PRI-05.1": [ - "3" + "PRI-03.13": [ + "III.1.22(5)" ], - "PRI-05.2": [ - "3" + "PRI-04": [ + "III.1.15(1)", + "III.1.15(1)1", + "III.1.15(1)2", + "III.1.15(1)3", + "III.1.15(1)4", + "III.1.15(1)5", + "III.1.15(1)6" ], - "PRI-05.3": [ - "3" + "PRI-05": [ + "III.1.21(1)", + "III.1.21(2)", + "III.1.21(3)", + "III.1.21(4)" ], "PRI-05.4": [ - "16", - "18", - "23" - ], - "PRI-05.5": [ - "33" + "III.1.18(1)", + "III.1.18(2)", + "III.1.18(2)1", + "III.1.18(2)2", + "III.1.18(2)3", + "III.1.18(2)4", + "III.1.18(2)5", + "III.1.18(2)6", + "III.1.18(2)7", + "III.1.18(2)8", + "III.1.18(2)9", + "III.1.19", + "III.1.19.1", + "III.1.19.2", + "III.2.23.1", + "III.2.23.2" + ], + "PRI-05.7": [ + "III.2.23" ], "PRI-06": [ - "4", - "35" + "V.35(1)", + "V.35(2)", + "V.35(3)", + "V.36(1)" ], - "PRI-06.1": [ - "4", - "36" + "PRI-06.4": [ + "V.36(2)", + "V.36(3)", + "V.36(4)", + "V.36(5)", + "V.37(2)", + "V.37(2)1", + "V.37(2)2", + "V.37(2)3", + "V.37(2)4", + "V.37(3)", + "V.37(4)" ], - "PRI-06.2": [ - "4", - "36" + "PRI-07.1": [ + "III.1.18(5)" + ], + "PRI-07.4": [ + "V.35(4)", + "V.35(4)1", + "V.35(4)2", + "V.35(4)3", + "V.35(4)3.a", + "V.35(4)3.b", + "V.35(4)3.c", + "V.35(4)3.d", + "V.35(4)3.e" + ], + "PRI-17": [ + "III.2.27(1)", + "III.2.27(1)1", + "III.2.27(1)2", + "III.2.27(1)3", + "III.2.27(2)", + "III.2.27(3)" + ], + "SAT-01": [ + "III.2.28(2)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 150, + "mappings": { + "III.1.16(1)": [ + "DCH-18.1" ], - "PRI-06.3": [ - "38" + "III.2.28(1)": [ + "HRS-01" ], - "PRI-06.4": [ - "37" + "IV.34(2)": [ + "IRO-04.1" ], - "PRI-07": [ - "17", - "26", - "27" + "IV.34(1)": [ + "IRO-10" ], - "PRI-07.1": [ - "26", - "27" + "IV.34(1)1": [ + "IRO-10" ], - "PRI-15": [ - "32" + "IV.34(1)2": [ + "IRO-10" ], - "RSK-08": [ - "33" + "IV.34(1)3": [ + "IRO-10" ], - "RSK-10": [ - "33" + "IV.34(1)4": [ + "IRO-10" ], - "SEA-01": [ - "3", - "29" + "IV.34(1)5": [ + "IRO-10" ], - "SEA-02": [ - "3", - "29" + "IV.34(3)": [ + "IRO-10" ], - "SEA-03": [ - "3", - "29" + "IV.31(1)": [ + "PRI-01.1" ], - "SEA-15": [ - "17", - "27" + "IV.31(2)": [ + "PRI-01.1" ], - "TPM-04.4": [ - "17", - "27" - ] - } - }, - "framework_to_scf": { - "total_mappings": 22, - "mappings": { - "3": [ - "GOV-01", - "CPL-01", - "PRI-01", - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.2", - "PRI-05.3", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "4": [ - "DCH-22.1", - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-05", - "PRI-06", - "PRI-06.1", - "PRI-06.2" - ], - "15": [ - "PRI-04", - "PRI-04.1", + "IV.31(2)1": [ + "PRI-01.1" + ], + "IV.31(2)2": [ + "PRI-01.1" + ], + "IV.31(2)3": [ + "PRI-01.1" + ], + "IV.31(2)4": [ + "PRI-01.1" + ], + "IV.31(2)5": [ + "PRI-01.1" + ], + "IV.31(2)6": [ + "PRI-01.1" + ], + "IV.31(2)7": [ + "PRI-01.1" + ], + "IV.31(3)": [ + "PRI-01.1" + ], + "IV.31(4)": [ + "PRI-01.1" + ], + "IV.31(5)": [ + "PRI-01.1" + ], + "I.3(1)": [ + "PRI-01.11" + ], + "I.3(2)": [ + "PRI-01.11" + ], + "I.3(3)": [ + "PRI-01.11" + ], + "I.3(4)": [ + "PRI-01.11" + ], + "I.3(5)": [ + "PRI-01.11" + ], + "I.3(6)": [ + "PRI-01.11" + ], + "I.3(7)": [ + "PRI-01.11" + ], + "I.3(8)": [ + "PRI-01.11" + ], + "I.4": [ + "PRI-01.11" + ], + "I.4.1": [ + "PRI-01.11" + ], + "I.4.2": [ + "PRI-01.11" + ], + "I.4.3": [ + "PRI-01.11" + ], + "I.4.4": [ + "PRI-01.11" + ], + "I.4.5": [ + "PRI-01.11" + ], + "III.2.23": [ + "PRI-01.11", + "PRI-05.7" + ], + "III.2.24(1)": [ + "PRI-01.11" + ], + "III.2.24(1)1": [ + "PRI-01.11" + ], + "III.2.24(1)2": [ + "PRI-01.11" + ], + "III.2.24(2)": [ + "PRI-01.11" + ], + "III.2.24(3)": [ + "PRI-01.11" + ], + "III.2.24(4)": [ + "PRI-01.11" + ], + "IV.29": [ + "PRI-01.11" + ], + "V.38(3)": [ + "PRI-01.11" + ], + "V.38(4)": [ + "PRI-01.11" + ], + "V.38(5)": [ + "PRI-01.11" + ], + "VIII.60": [ + "PRI-01.11" + ], + "III.1.18(3)": [ + "PRI-02" + ], + "III.1.18(3)1": [ + "PRI-02" + ], + "III.1.18(3)2": [ + "PRI-02" + ], + "III.1.18(3)3": [ + "PRI-02" + ], + "III.1.18(3)4": [ + "PRI-02" + ], + "III.1.18(3)5": [ + "PRI-02" + ], + "IV.30(1)": [ + "PRI-02" + ], + "IV.30(1)1": [ + "PRI-02" + ], + "IV.30(1)2": [ + "PRI-02" + ], + "IV.30(1)3": [ + "PRI-02" + ], + "IV.30(1)4": [ + "PRI-02" + ], + "IV.30(1)5": [ + "PRI-02" + ], + "IV.30(1)6": [ + "PRI-02" + ], + "IV.30(2)": [ + "PRI-02" + ], + "IV.30(3)": [ + "PRI-02" + ], + "III.1.15(2)": [ + "PRI-03" + ], + "III.1.15(2)1": [ + "PRI-03" + ], + "III.1.15(2)2": [ + "PRI-03" + ], + "III.1.15(2)3": [ + "PRI-03" + ], + "III.1.15(2)4": [ + "PRI-03" + ], + "III.1.17(1)": [ + "PRI-03" + ], + "III.1.17(1)1": [ + "PRI-03" + ], + "III.1.17(1)2": [ + "PRI-03" + ], + "III.1.17(2)": [ + "PRI-03" + ], + "III.1.17(2)1": [ + "PRI-03" + ], + "III.1.17(2)2": [ + "PRI-03" + ], + "III.1.17(2)3": [ + "PRI-03" + ], + "III.1.17(2)4": [ + "PRI-03" + ], + "III.1.17(2)5": [ + "PRI-03" + ], + "III.1.17(3)": [ + "PRI-03" + ], + "III.1.22(3)": [ + "PRI-03" + ], + "III.1.22(2)": [ + "PRI-03.1" + ], + "III.1.20(1)": [ + "PRI-03.2" + ], + "III.1.20(1)1": [ + "PRI-03.2" + ], + "III.1.20(1)2": [ + "PRI-03.2" + ], + "III.1.20(1)3": [ + "PRI-03.2" + ], + "III.1.22(1)": [ + "PRI-03.2" + ], + "V.37(1)": [ + "PRI-03.4" + ], + "III.1.16(2)": [ + "PRI-03.5" + ], + "III.1.22(4)": [ + "PRI-03.5" + ], + "V.38(1)": [ + "PRI-03.6" + ], + "V.38(2)": [ + "PRI-03.6" + ], + "III.1.22(5)": [ + "PRI-03.13" + ], + "III.1.15(1)": [ + "PRI-04" + ], + "III.1.15(1)1": [ + "PRI-04" + ], + "III.1.15(1)2": [ + "PRI-04" + ], + "III.1.15(1)3": [ + "PRI-04" + ], + "III.1.15(1)4": [ + "PRI-04" + ], + "III.1.15(1)5": [ + "PRI-04" + ], + "III.1.15(1)6": [ + "PRI-04" + ], + "III.1.21(1)": [ "PRI-05" ], - "16": [ + "III.1.21(2)": [ + "PRI-05" + ], + "III.1.21(3)": [ + "PRI-05" + ], + "III.1.21(4)": [ + "PRI-05" + ], + "III.1.18(1)": [ "PRI-05.4" ], - "17": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "SEA-15", - "TPM-04.4" + "III.1.18(2)": [ + "PRI-05.4" ], - "18": [ + "III.1.18(2)1": [ "PRI-05.4" ], - "19": [ - "PRI-05" + "III.1.18(2)2": [ + "PRI-05.4" ], - "21": [ - "PRI-05" + "III.1.18(2)3": [ + "PRI-05.4" ], - "22": [ - "PRI-03", - "PRI-03.2", - "PRI-04" + "III.1.18(2)4": [ + "PRI-05.4" ], - "23": [ + "III.1.18(2)5": [ "PRI-05.4" ], - "26": [ - "DCH-25", - "PRI-07", - "PRI-07.1" + "III.1.18(2)6": [ + "PRI-05.4" ], - "27": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "PRI-07.1", - "SEA-15", - "TPM-04.4" - ], - "29": [ - "GOV-01", - "CPL-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "30": [ - "GOV-01", - "PRI-01" - ], - "31": [ - "PRI-01.1" + "III.1.18(2)7": [ + "PRI-05.4" ], - "32": [ - "PRI-15" + "III.1.18(2)8": [ + "PRI-05.4" ], - "33": [ - "PRI-05.5", - "RSK-08", - "RSK-10" + "III.1.18(2)9": [ + "PRI-05.4" ], - "34": [ - "IRO-04", - "IRO-04.1" + "III.1.19": [ + "PRI-05.4" ], - "35": [ + "III.1.19.1": [ + "PRI-05.4" + ], + "III.1.19.2": [ + "PRI-05.4" + ], + "III.2.23.1": [ + "PRI-05.4" + ], + "III.2.23.2": [ + "PRI-05.4" + ], + "V.35(1)": [ + "PRI-06" + ], + "V.35(2)": [ "PRI-06" ], - "36": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" + "V.35(3)": [ + "PRI-06" + ], + "V.36(1)": [ + "PRI-06" + ], + "V.36(2)": [ + "PRI-06.4" + ], + "V.36(3)": [ + "PRI-06.4" + ], + "V.36(4)": [ + "PRI-06.4" + ], + "V.36(5)": [ + "PRI-06.4" + ], + "V.37(2)": [ + "PRI-06.4" + ], + "V.37(2)1": [ + "PRI-06.4" + ], + "V.37(2)2": [ + "PRI-06.4" + ], + "V.37(2)3": [ + "PRI-06.4" ], - "37": [ - "PRI-05", + "V.37(2)4": [ "PRI-06.4" ], - "38": [ - "PRI-06.3" + "V.37(3)": [ + "PRI-06.4" + ], + "V.37(4)": [ + "PRI-06.4" + ], + "III.1.18(5)": [ + "PRI-07.1" + ], + "V.35(4)": [ + "PRI-07.4" + ], + "V.35(4)1": [ + "PRI-07.4" + ], + "V.35(4)2": [ + "PRI-07.4" + ], + "V.35(4)3": [ + "PRI-07.4" + ], + "V.35(4)3.a": [ + "PRI-07.4" + ], + "V.35(4)3.b": [ + "PRI-07.4" + ], + "V.35(4)3.c": [ + "PRI-07.4" + ], + "V.35(4)3.d": [ + "PRI-07.4" + ], + "V.35(4)3.e": [ + "PRI-07.4" + ], + "III.2.27(1)": [ + "PRI-17" + ], + "III.2.27(1)1": [ + "PRI-17" + ], + "III.2.27(1)2": [ + "PRI-17" + ], + "III.2.27(1)3": [ + "PRI-17" + ], + "III.2.27(2)": [ + "PRI-17" + ], + "III.2.27(3)": [ + "PRI-17" + ], + "III.2.28(2)": [ + "SAT-01" ] } } diff --git a/docs/api/crosswalks/apac-mys-bnm-rmit-2025.json b/docs/api/crosswalks/apac-mys-bnm-rmit-2025.json new file mode 100644 index 00000000..a0470957 --- /dev/null +++ b/docs/api/crosswalks/apac-mys-bnm-rmit-2025.json @@ -0,0 +1,1326 @@ +{ + "framework_id": "apac-mys-bnm-rmit-2025", + "display_name": "Malaysia - Risk Management in Technology (RMiT) (2025)", + "scf_to_framework": { + "total_mappings": 197, + "mappings": { + "GOV-01": [ + "10.1", + "11.1", + "11.2", + "11.5" + ], + "GOV-01.1": [ + "8.2", + "8.3", + "8.4", + "8.5", + "8.7", + "11.17", + "12.3" + ], + "GOV-01.2": [ + "8.4", + "8.6", + "9.3", + "9.5" + ], + "GOV-01.3": [ + "8.2", + "8.4" + ], + "GOV-02": [ + "8.6", + "9.5", + "10.16", + "10.20", + "11.12" + ], + "GOV-03": [ + "9.5" + ], + "GOV-04": [ + "8.6", + "9.4" + ], + "GOV-04.1": [ + "8.6", + "10.35", + "11.8" + ], + "GOV-04.2": [ + "11.8" + ], + "GOV-05": [ + "8.6" + ], + "GOV-05.2": [ + "8.1" + ], + "GOV-14": [ + "9.5" + ], + "GOV-15": [ + "9.5" + ], + "GOV-16": [ + "10.2" + ], + "GOV-16.1": [ + "10.2" + ], + "GOV-17": [ + "16.1", + "17.2", + "17.5" + ], + "AST-01": [ + "10.17" + ], + "AST-01.1": [ + "9.2", + "11.3" + ], + "AST-02": [ + "11.3" + ], + "AST-02.9": [ + "11.3" + ], + "AST-04": [ + "10.41" + ], + "AST-30": [ + "10.13" + ], + "BCD-01": [ + "8.2", + "8.6", + "10.24", + "10.44" + ], + "BCD-01.4": [ + "10.32" + ], + "BCD-01.5": [ + "10.24", + "10.32" + ], + "BCD-01.6": [ + "11.15" + ], + "BCD-02": [ + "9.2", + "10.26", + "11.3" + ], + "BCD-02.2": [ + "10.25", + "10.26" + ], + "BCD-10.4": [ + "11.15" + ], + "BCD-11": [ + "10.44" + ], + "BCD-11.1": [ + "10.44" + ], + "BCD-11.2": [ + "10.44" + ], + "BCD-11.4": [ + "10.45" + ], + "BCD-11.7": [ + "10.25", + "10.26" + ], + "BCD-12": [ + "10.45" + ], + "BCD-14": [ + "10.45" + ], + "CAP-01": [ + "10.29" + ], + "CAP-02": [ + "10.29" + ], + "CAP-03": [ + "10.29" + ], + "CAP-04": [ + "10.30", + "10.39" + ], + "CAP-05": [ + "10.29" + ], + "CHG-01": [ + "10.11" + ], + "CHG-02": [ + "10.11", + "10.18", + "10.27" + ], + "CHG-02.2": [ + "10.18" + ], + "CHG-02.3": [ + "10.11" + ], + "CHG-03": [ + "10.11" + ], + "CHG-04.5": [ + "10.12" + ], + "CHG-05": [ + "10.18" + ], + "CLD-01": [ + "10.26", + "10.50" + ], + "CLD-02": [ + "10.50" + ], + "CLD-06": [ + "10.50" + ], + "CLD-06.1": [ + "10.50" + ], + "CLD-09": [ + "10.50" + ], + "CLD-10": [ + "10.50" + ], + "CPL-01.3": [ + "16.6" + ], + "CPL-01.4": [ + "8.1", + "8.2", + "18.1" + ], + "CPL-01.5": [ + "8.2", + "18.2" + ], + "CPL-01.6": [ + "16.5" + ], + "CPL-02": [ + "13.2" + ], + "CPL-02.1": [ + "13.3" + ], + "CPL-03": [ + "11.9", + "13.1" + ], + "CPL-03.1": [ + "13.4", + "14.1", + "14.2" + ], + "CPL-07": [ + "10.35", + "12.8" + ], + "CPL-13.1": [ + "10.2", + "10.21" + ], + "CFG-03": [ + "10.54" + ], + "CFG-04.1": [ + "10.15" + ], + "MON-01": [ + "10.57", + "11.9", + "12.3" + ], + "MON-10": [ + "10.42" + ], + "MON-16": [ + "10.31", + "10.57", + "11.9" + ], + "CRY-01": [ + "10.20", + "10.22" + ], + "CRY-01.5": [ + "10.20", + "10.22" + ], + "CRY-09": [ + "10.20", + "10.21", + "10.23" + ], + "DCH-01.2": [ + "10.44" + ], + "DCH-06": [ + "10.44" + ], + "DCH-06.1": [ + "10.44" + ], + "HRS-03.2": [ + "9.4" + ], + "IAC-01": [ + "10.53", + "10.54", + "10.56", + "10.57" + ], + "IAC-01.2": [ + "10.54" + ], + "IAC-06": [ + "10.55" + ], + "IAC-08": [ + "10.56" + ], + "IAC-15": [ + "10.56" + ], + "IAC-21": [ + "10.54" + ], + "IAC-29": [ + "10.54" + ], + "IRO-01": [ + "9.2", + "11.2", + "11.12" + ], + "IRO-02": [ + "10.31", + "10.35", + "11.3", + "11.11" + ], + "IRO-04": [ + "10.20", + "11.3", + "11.13" + ], + "IRO-06": [ + "11.16" + ], + "IRO-06.1": [ + "11.3" + ], + "IRO-07": [ + "11.13", + "11.14" + ], + "IRO-10": [ + "10.35", + "11.19" + ], + "IRO-10.2": [ + "11.18" + ], + "IAO-01": [ + "10.2", + "10.6", + "10.8", + "10.15", + "16.2" + ], + "IAO-01.1": [ + "10.8", + "10.9" + ], + "IAO-02": [ + "10.2", + "10.6", + "10.8", + "10.9", + "16.4" + ], + "IAO-02.1": [ + "10.8" + ], + "IAO-02.2": [ + "10.6", + "10.8", + "10.9", + "10.15" + ], + "IAO-02.4": [ + "10.8" + ], + "IAO-04": [ + "10.6", + "10.8", + "10.10" + ], + "IAO-05": [ + "10.8" + ], + "IAO-06": [ + "10.6", + "10.8" + ], + "IAO-07": [ + "10.6", + "10.8", + "10.15" + ], + "MNT-01": [ + "10.26" + ], + "MNT-02": [ + "10.26" + ], + "MDM-01": [ + "12.3" + ], + "NET-01": [ + "10.37", + "12.3", + "12.5" + ], + "NET-02": [ + "12.3" + ], + "NET-06": [ + "10.28" + ], + "PRI-02": [ + "16.2" + ], + "PRM-01": [ + "8.1", + "8.2", + "8.4" + ], + "PRM-01.1": [ + "8.1", + "8.2", + "8.4" + ], + "PRM-01.2": [ + "8.1" + ], + "PRM-02.1": [ + "8.1", + "8.2", + "8.4" + ], + "PRM-04": [ + "9.3", + "10.2", + "10.3", + "10.5" + ], + "PRM-05": [ + "9.3", + "10.2" + ], + "PRM-06": [ + "10.2" + ], + "PRM-07": [ + "10.5" + ], + "RSK-01": [ + "8.2", + "9.1", + "9.2", + "9.3", + "11.3" + ], + "RSK-01.3": [ + "8.1", + "11.2" + ], + "RSK-01.5": [ + "8.1" + ], + "RSK-02": [ + "9.2" + ], + "RSK-02.1": [ + "9.2" + ], + "RSK-03": [ + "9.2" + ], + "RSK-03.1": [ + "9.2" + ], + "RSK-03.2": [ + "8.1" + ], + "RSK-04": [ + "8.1", + "9.2" + ], + "RSK-04.1": [ + "9.2" + ], + "RSK-04.2": [ + "9.2" + ], + "RSK-06": [ + "9.2" + ], + "RSK-06.1": [ + "9.2" + ], + "RSK-06.2": [ + "9.2" + ], + "RSK-06.3": [ + "11.17" + ], + "RSK-06.4": [ + "9.2" + ], + "RSK-08": [ + "10.44" + ], + "RSK-09": [ + "10.15" + ], + "RSK-09.1": [ + "10.15" + ], + "SEA-01": [ + "10.4", + "10.5", + "10.22", + "10.26", + "10.36", + "10.37", + "10.38", + "10.40", + "10.43", + "10.52" + ], + "SEA-01.2": [ + "10.24", + "10.31", + "10.32", + "10.40", + "11.2" + ], + "SEA-01.3": [ + "10.31", + "10.32", + "10.40", + "11.2" + ], + "SEA-01.4": [ + "10.4", + "10.5", + "10.36", + "10.37", + "10.38", + "10.40" + ], + "SEA-02": [ + "10.4", + "10.36", + "10.40" + ], + "OPS-01.1": [ + "10.27" + ], + "OPS-03": [ + "10.31" + ], + "OPS-04": [ + "11.9" + ], + "OPS-07": [ + "10.16" + ], + "SAT-02": [ + "15.1" + ], + "SAT-03": [ + "15.2", + "15.3" + ], + "SAT-03.7": [ + "15.2" + ], + "TDA-01": [ + "10.2", + "10.12", + "12.1", + "12.5" + ], + "TDA-01.1": [ + "10.2", + "10.12", + "12.1", + "12.5" + ], + "TDA-02": [ + "10.12", + "12.1", + "12.5" + ], + "TDA-02.3": [ + "10.12", + "10.14" + ], + "TDA-02.4": [ + "10.12" + ], + "TDA-02.7": [ + "10.12" + ], + "TDA-02.12": [ + "12.1" + ], + "TDA-04.2": [ + "10.15" + ], + "TDA-06.2": [ + "9.2" + ], + "TDA-07": [ + "10.7" + ], + "TDA-08": [ + "10.7", + "10.26", + "10.28" + ], + "TDA-09": [ + "10.10" + ], + "TDA-09.3": [ + "10.14" + ], + "TDA-17": [ + "10.17" + ], + "TDA-20": [ + "10.12" + ], + "TDA-20.2": [ + "10.12" + ], + "TDA-20.3": [ + "10.12" + ], + "TDA-21": [ + "10.12" + ], + "TPM-01": [ + "10.12", + "10.24", + "10.25", + "10.46" + ], + "TPM-02": [ + "9.2", + "10.46" + ], + "TPM-03": [ + "10.15" + ], + "TPM-03.1": [ + "10.50" + ], + "TPM-04": [ + "10.12", + "10.50" + ], + "TPM-04.1": [ + "10.46", + "10.47", + "10.50" + ], + "TPM-04.4": [ + "10.50" + ], + "TPM-05": [ + "10.12", + "10.24", + "10.25", + "10.46", + "10.48", + "10.50" + ], + "TPM-05.1": [ + "10.49" + ], + "TPM-05.2": [ + "10.48" + ], + "TPM-05.4": [ + "10.46", + "10.48" + ], + "TPM-05.5": [ + "10.46" + ], + "TPM-05.7": [ + "10.50" + ], + "TPM-07": [ + "10.49" + ], + "TPM-08": [ + "10.49" + ], + "THR-01": [ + "11.10" + ], + "THR-03": [ + "11.3", + "11.10", + "12.3", + "12.4" + ], + "THR-03.1": [ + "11.10" + ], + "THR-06": [ + "11.7" + ], + "THR-09": [ + "9.2", + "11.3" + ], + "THR-10": [ + "11.3", + "12.4" + ], + "VPM-01": [ + "10.17", + "10.18", + "10.19", + "10.31" + ], + "VPM-01.1": [ + "10.18" + ], + "VPM-02": [ + "10.18" + ], + "VPM-03": [ + "10.18" + ], + "VPM-04": [ + "10.18" + ], + "VPM-05": [ + "10.17", + "10.18" + ], + "VPM-05.1": [ + "10.19" + ], + "VPM-05.6": [ + "10.18" + ], + "VPM-06": [ + "11.9" + ], + "VPM-07": [ + "11.9" + ], + "VPM-10": [ + "11.6" + ] + } + }, + "framework_to_scf": { + "total_mappings": 107, + "mappings": { + "10.1": [ + "GOV-01" + ], + "11.1": [ + "GOV-01" + ], + "11.2": [ + "GOV-01", + "IRO-01", + "RSK-01.3", + "SEA-01.2", + "SEA-01.3" + ], + "11.5": [ + "GOV-01" + ], + "8.2": [ + "GOV-01.1", + "GOV-01.3", + "BCD-01", + "CPL-01.4", + "CPL-01.5", + "PRM-01", + "PRM-01.1", + "PRM-02.1", + "RSK-01" + ], + "8.3": [ + "GOV-01.1" + ], + "8.4": [ + "GOV-01.1", + "GOV-01.2", + "GOV-01.3", + "PRM-01", + "PRM-01.1", + "PRM-02.1" + ], + "8.5": [ + "GOV-01.1" + ], + "8.7": [ + "GOV-01.1" + ], + "11.17": [ + "GOV-01.1", + "RSK-06.3" + ], + "12.3": [ + "GOV-01.1", + "MON-01", + "MDM-01", + "NET-01", + "NET-02", + "THR-03" + ], + "8.6": [ + "GOV-01.2", + "GOV-02", + "GOV-04", + "GOV-04.1", + "GOV-05", + "BCD-01" + ], + "9.3": [ + "GOV-01.2", + "PRM-04", + "PRM-05", + "RSK-01" + ], + "9.5": [ + "GOV-01.2", + "GOV-02", + "GOV-03", + "GOV-14", + "GOV-15" + ], + "10.16": [ + "GOV-02", + "OPS-07" + ], + "10.20": [ + "GOV-02", + "CRY-01", + "CRY-01.5", + "CRY-09", + "IRO-04" + ], + "11.12": [ + "GOV-02", + "IRO-01" + ], + "9.4": [ + "GOV-04", + "HRS-03.2" + ], + "10.35": [ + "GOV-04.1", + "CPL-07", + "IRO-02", + "IRO-10" + ], + "11.8": [ + "GOV-04.1", + "GOV-04.2" + ], + "8.1": [ + "GOV-05.2", + "CPL-01.4", + "PRM-01", + "PRM-01.1", + "PRM-01.2", + "PRM-02.1", + "RSK-01.3", + "RSK-01.5", + "RSK-03.2", + "RSK-04" + ], + "10.2": [ + "GOV-16", + "GOV-16.1", + "CPL-13.1", + "IAO-01", + "IAO-02", + "PRM-04", + "PRM-05", + "PRM-06", + "TDA-01", + "TDA-01.1" + ], + "16.1": [ + "GOV-17" + ], + "17.2": [ + "GOV-17" + ], + "17.5": [ + "GOV-17" + ], + "10.17": [ + "AST-01", + "TDA-17", + "VPM-01", + "VPM-05" + ], + "9.2": [ + "AST-01.1", + "BCD-02", + "IRO-01", + "RSK-01", + "RSK-02", + "RSK-02.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-04.1", + "RSK-04.2", + "RSK-06", + "RSK-06.1", + "RSK-06.2", + "RSK-06.4", + "TDA-06.2", + "TPM-02", + "THR-09" + ], + "11.3": [ + "AST-01.1", + "AST-02", + "AST-02.9", + "BCD-02", + "IRO-02", + "IRO-04", + "IRO-06.1", + "RSK-01", + "THR-03", + "THR-09", + "THR-10" + ], + "10.41": [ + "AST-04" + ], + "10.13": [ + "AST-30" + ], + "10.24": [ + "BCD-01", + "BCD-01.5", + "SEA-01.2", + "TPM-01", + "TPM-05" + ], + "10.44": [ + "BCD-01", + "BCD-11", + "BCD-11.1", + "BCD-11.2", + "DCH-01.2", + "DCH-06", + "DCH-06.1", + "RSK-08" + ], + "10.32": [ + "BCD-01.4", + "BCD-01.5", + "SEA-01.2", + "SEA-01.3" + ], + "11.15": [ + "BCD-01.6", + "BCD-10.4" + ], + "10.26": [ + "BCD-02", + "BCD-02.2", + "BCD-11.7", + "CLD-01", + "MNT-01", + "MNT-02", + "SEA-01", + "TDA-08" + ], + "10.25": [ + "BCD-02.2", + "BCD-11.7", + "TPM-01", + "TPM-05" + ], + "10.45": [ + "BCD-11.4", + "BCD-12", + "BCD-14" + ], + "10.29": [ + "CAP-01", + "CAP-02", + "CAP-03", + "CAP-05" + ], + "10.30": [ + "CAP-04" + ], + "10.39": [ + "CAP-04" + ], + "10.11": [ + "CHG-01", + "CHG-02", + "CHG-02.3", + "CHG-03" + ], + "10.18": [ + "CHG-02", + "CHG-02.2", + "CHG-05", + "VPM-01", + "VPM-01.1", + "VPM-02", + "VPM-03", + "VPM-04", + "VPM-05", + "VPM-05.6" + ], + "10.27": [ + "CHG-02", + "OPS-01.1" + ], + "10.12": [ + "CHG-04.5", + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-02.7", + "TDA-20", + "TDA-20.2", + "TDA-20.3", + "TDA-21", + "TPM-01", + "TPM-04", + "TPM-05" + ], + "10.50": [ + "CLD-01", + "CLD-02", + "CLD-06", + "CLD-06.1", + "CLD-09", + "CLD-10", + "TPM-03.1", + "TPM-04", + "TPM-04.1", + "TPM-04.4", + "TPM-05", + "TPM-05.7" + ], + "16.6": [ + "CPL-01.3" + ], + "18.1": [ + "CPL-01.4" + ], + "18.2": [ + "CPL-01.5" + ], + "16.5": [ + "CPL-01.6" + ], + "13.2": [ + "CPL-02" + ], + "13.3": [ + "CPL-02.1" + ], + "11.9": [ + "CPL-03", + "MON-01", + "MON-16", + "OPS-04", + "VPM-06", + "VPM-07" + ], + "13.1": [ + "CPL-03" + ], + "13.4": [ + "CPL-03.1" + ], + "14.1": [ + "CPL-03.1" + ], + "14.2": [ + "CPL-03.1" + ], + "12.8": [ + "CPL-07" + ], + "10.21": [ + "CPL-13.1", + "CRY-09" + ], + "10.54": [ + "CFG-03", + "IAC-01", + "IAC-01.2", + "IAC-21", + "IAC-29" + ], + "10.15": [ + "CFG-04.1", + "IAO-01", + "IAO-02.2", + "IAO-07", + "RSK-09", + "RSK-09.1", + "TDA-04.2", + "TPM-03" + ], + "10.57": [ + "MON-01", + "MON-16", + "IAC-01" + ], + "10.42": [ + "MON-10" + ], + "10.31": [ + "MON-16", + "IRO-02", + "SEA-01.2", + "SEA-01.3", + "OPS-03", + "VPM-01" + ], + "10.22": [ + "CRY-01", + "CRY-01.5", + "SEA-01" + ], + "10.23": [ + "CRY-09" + ], + "10.53": [ + "IAC-01" + ], + "10.56": [ + "IAC-01", + "IAC-08", + "IAC-15" + ], + "10.55": [ + "IAC-06" + ], + "11.11": [ + "IRO-02" + ], + "11.13": [ + "IRO-04", + "IRO-07" + ], + "11.16": [ + "IRO-06" + ], + "11.14": [ + "IRO-07" + ], + "11.19": [ + "IRO-10" + ], + "11.18": [ + "IRO-10.2" + ], + "10.6": [ + "IAO-01", + "IAO-02", + "IAO-02.2", + "IAO-04", + "IAO-06", + "IAO-07" + ], + "10.8": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-02.4", + "IAO-04", + "IAO-05", + "IAO-06", + "IAO-07" + ], + "16.2": [ + "IAO-01", + "PRI-02" + ], + "10.9": [ + "IAO-01.1", + "IAO-02", + "IAO-02.2" + ], + "16.4": [ + "IAO-02" + ], + "10.10": [ + "IAO-04", + "TDA-09" + ], + "10.37": [ + "NET-01", + "SEA-01", + "SEA-01.4" + ], + "12.5": [ + "NET-01", + "TDA-01", + "TDA-01.1", + "TDA-02" + ], + "10.28": [ + "NET-06", + "TDA-08" + ], + "10.3": [ + "PRM-04" + ], + "10.5": [ + "PRM-04", + "PRM-07", + "SEA-01", + "SEA-01.4" + ], + "9.1": [ + "RSK-01" + ], + "10.4": [ + "SEA-01", + "SEA-01.4", + "SEA-02" + ], + "10.36": [ + "SEA-01", + "SEA-01.4", + "SEA-02" + ], + "10.38": [ + "SEA-01", + "SEA-01.4" + ], + "10.40": [ + "SEA-01", + "SEA-01.2", + "SEA-01.3", + "SEA-01.4", + "SEA-02" + ], + "10.43": [ + "SEA-01" + ], + "10.52": [ + "SEA-01" + ], + "15.1": [ + "SAT-02" + ], + "15.2": [ + "SAT-03", + "SAT-03.7" + ], + "15.3": [ + "SAT-03" + ], + "12.1": [ + "TDA-01", + "TDA-01.1", + "TDA-02", + "TDA-02.12" + ], + "10.14": [ + "TDA-02.3", + "TDA-09.3" + ], + "10.7": [ + "TDA-07", + "TDA-08" + ], + "10.46": [ + "TPM-01", + "TPM-02", + "TPM-04.1", + "TPM-05", + "TPM-05.4", + "TPM-05.5" + ], + "10.47": [ + "TPM-04.1" + ], + "10.48": [ + "TPM-05", + "TPM-05.2", + "TPM-05.4" + ], + "10.49": [ + "TPM-05.1", + "TPM-07", + "TPM-08" + ], + "11.10": [ + "THR-01", + "THR-03", + "THR-03.1" + ], + "12.4": [ + "THR-03", + "THR-10" + ], + "11.7": [ + "THR-06" + ], + "10.19": [ + "VPM-01", + "VPM-05.1" + ], + "11.6": [ + "VPM-10" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/apac-mys-pdpa-2010.json b/docs/api/crosswalks/apac-mys-pdpa-2010.json index b9918bf6..4cdf9f9a 100644 --- a/docs/api/crosswalks/apac-mys-pdpa-2010.json +++ b/docs/api/crosswalks/apac-mys-pdpa-2010.json @@ -2,144 +2,902 @@ "framework_id": "apac-mys-pdpa-2010", "display_name": "Malaysia - Personal Data Protection Act (PDPA) (2010)", "scf_to_framework": { - "total_mappings": 25, + "total_mappings": 19, "mappings": { - "GOV-01": [ - "9" + "PRI-01.5": [ + "129(1)", + "129(2)", + "129(2)(a)", + "129(2)(b)", + "129(3)", + "129(3)(a)", + "129(3)(b)", + "129(3)(c)", + "129(3)(c)(i)", + "129(3)(c)(ii)", + "129(3)(d)", + "129(3)(e)", + "129(3)(e)(i)", + "129(3)(e)(ii)", + "129(3)(e)(iii)", + "129(3)(f)", + "129(3)(g)", + "129(3)(h)", + "129(4)", + "129(4)(a)", + "129(4)(b)" + ], + "PRI-01.6": [ + "9(1)", + "9(1)(a)", + "9(1)(b)", + "9(1)(c)", + "9(1)(d)", + "9(1)(e)", + "9(2)", + "9(2)(a)", + "9(2)(b)" + ], + "PRI-01.11": [ + "5(1)", + "5(1)(a)", + "5(1)(b)", + "5(1)(c)", + "5(1)(d)", + "5(1)(e)", + "5(1)(f)", + "5(1)(g)", + "130(1)", + "130(1)(a)", + "130(1)(b)", + "130(2)", + "130(2)(a)", + "130(2)(a)(i)", + "130(2)(a)(ii)", + "130(2)(b)", + "130(2)(c)", + "130(2)(d)", + "130(3)", + "130(4)", + "130(5)", + "130(5)(a)", + "130(5)(b)", + "130(6)" ], - "CPL-01": [ - "9" + "PRI-02": [ + "7(1)", + "7(1)(a)", + "7(1)(b)", + "7(1)(c)", + "7(1)(d)", + "7(1)(e)", + "7(1)(f)", + "7(1)(g)", + "7(1)(h)", + "7(2)", + "7(2)(a)", + "7(2)(b)", + "7(2)(c)", + "7(2)(c)(i)", + "7(2)(c)(ii)" ], - "CPL-02": [ - "9" + "PRI-03": [ + "7(3)" ], - "CPL-03": [ - "9" + "PRI-03.4": [ + "38(1)", + "43(1)" ], - "DCH-01": [ - "9" + "PRI-03.10": [ + "38(2)", + "42(1)", + "42(1)(a)" ], - "DCH-22.1": [ - "34" + "PRI-05": [ + "10(1)", + "10(2)" ], - "DCH-24": [ - "9" + "PRI-05.2": [ + "11" ], - "DCH-24.1": [ - "9" + "PRI-05.4": [ + "6(1)(a)", + "6(2)", + "6(2)(a)", + "6(2)(b)", + "6(2)(c)", + "6(2)(d)", + "6(2)(e)", + "6(2)(f)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "8", + "8(a)", + "8(a)(i)", + "8(a)(ii)", + "8(b)", + "39", + "39(a)", + "39(b)", + "39(b)(i)", + "39(b)(ii)", + "39(c)", + "39(d)", + "39(e)", + "40(1)", + "40(1)(a)", + "40(1)(b)", + "40(1)(b)(i)", + "40(1)(b)(ii)", + "40(1)(b)(ii)(A)", + "40(1)(b)(ii)(B)", + "40(1)(b)(iii)", + "40(1)(b)(iv)", + "40(1)(b)(iv)(A)", + "40(1)(b)(iv)(B)", + "40(1)(b)(v)", + "40(1)(b)(vi)", + "40(1)(b)(vii)", + "40(1)(b)(viii)", + "40(1)(b)(ix)", + "40(1)(b)(x)", + "40(1)(c)", + "42(1)(b)", + "42(1)(b)(A)", + "42(1)(b)(B)", + "42(2)", + "42(2)(a)", + "42(2)(b)", + "42(2)(b)(i)", + "42(2)(b)(ii)", + "42(2)(b)(iii)", + "42(2)(b)(iv)", + "42(2)(c)", + "42(3)", + "42(3)(a)", + "42(3)(b)", + "42(4)", + "42(5)" ], - "DCH-25": [ - "9" + "PRI-06": [ + "12", + "30(1)", + "30(2)(a)", + "30(2)(b)", + "34(1)(a)", + "34(1)(b)", + "34(2)" ], - "IRO-14": [ - "9" + "PRI-06.1": [ + "35(1)", + "35(1)(a)", + "35(1)(b)", + "35(1)(c)", + "35(1)(c)(i)", + "35(1)(c)(ii)", + "35(2)", + "35(2)(a)", + "35(2)(b)", + "35(3)", + "35(4)", + "35(4)(a)", + "35(4)(b)", + "35(5)", + "35(5)(a)", + "35(5)(b)" + ], + "PRI-06.2": [ + "37(1)", + "37(1)(a)", + "37(1)(b)" + ], + "PRI-06.4": [ + "30(3)", + "30(4)", + "30(5)", + "31(1)", + "31(2)", + "31(2)(a)", + "31(2)(b)", + "31(3)", + "32(1)", + "32(1)(a)", + "32(1)(b)", + "32(1)(c)", + "32(2)", + "32(2)(a)", + "32(2)(b)", + "32(2)(c)", + "32(2)(d)", + "32(3)", + "33", + "33(a)", + "33(b)" + ], + "PRI-06.8": [ + "32(1)(a)(i)", + "32(1)(a)(ii)", + "32(1)(a)(ii)(A)", + "32(1)(a)(ii)(B)" + ], + "PRI-07.4": [ + "36(1)", + "36(1)(a)", + "36(1)(a)(i)", + "36(1)(a)(ii)", + "36(1)(a)(ii)(A)", + "36(1)(a)(ii)(B)", + "36(1)(b)", + "36(1)(c)", + "36(1)(d)", + "36(1)(e)", + "36(2)" + ], + "PRI-07.5": [ + "32(1)(d)", + "32(1)(d)(i)", + "32(1)(d)(ii)", + "32(1)(e)", + "32(1)(f)", + "32(1)(g)", + "32(1)(h)" + ], + "PRI-14": [ + "44(1)" + ], + "PRI-17.3": [ + "37(2)", + "37(2)(a)", + "37(2)(a)(i)", + "37(2)(a)(ii)", + "37(2)(b)", + "37(3)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 213, + "mappings": { + "8": [ + "PRI-05.4" ], - "PRI-01": [ - "23" + "11": [ + "PRI-05.2" ], - "PRI-02": [ - "7" + "12": [ + "PRI-06" ], - "PRI-03": [ - "7" + "33": [ + "PRI-06.4" ], - "PRI-05": [ - "5", - "6", - "10" + "39": [ + "PRI-05.4" ], - "PRI-05.2": [ - "11" + "129(1)": [ + "PRI-01.5" ], - "PRI-05.4": [ - "34" + "129(2)": [ + "PRI-01.5" ], - "PRI-06": [ - "12", - "30" + "129(2)(a)": [ + "PRI-01.5" ], - "PRI-06.1": [ - "34" + "129(2)(b)": [ + "PRI-01.5" ], - "PRI-07": [ - "9" + "129(3)": [ + "PRI-01.5" ], - "PRI-15": [ - "14", - "15" + "129(3)(a)": [ + "PRI-01.5" ], - "SEA-01": [ - "9" + "129(3)(b)": [ + "PRI-01.5" ], - "SEA-02": [ - "9" + "129(3)(c)": [ + "PRI-01.5" ], - "SEA-03": [ - "9" + "129(3)(c)(i)": [ + "PRI-01.5" ], - "SEA-15": [ - "9" + "129(3)(c)(ii)": [ + "PRI-01.5" ], - "TPM-04.4": [ - "9" - ] - } - }, - "framework_to_scf": { - "total_mappings": 12, - "mappings": { - "5": [ - "PRI-05" + "129(3)(d)": [ + "PRI-01.5" ], - "6": [ - "PRI-05" + "129(3)(e)": [ + "PRI-01.5" + ], + "129(3)(e)(i)": [ + "PRI-01.5" + ], + "129(3)(e)(ii)": [ + "PRI-01.5" + ], + "129(3)(e)(iii)": [ + "PRI-01.5" + ], + "129(3)(f)": [ + "PRI-01.5" + ], + "129(3)(g)": [ + "PRI-01.5" + ], + "129(3)(h)": [ + "PRI-01.5" + ], + "129(4)": [ + "PRI-01.5" + ], + "129(4)(a)": [ + "PRI-01.5" + ], + "129(4)(b)": [ + "PRI-01.5" + ], + "9(1)": [ + "PRI-01.6" + ], + "9(1)(a)": [ + "PRI-01.6" + ], + "9(1)(b)": [ + "PRI-01.6" + ], + "9(1)(c)": [ + "PRI-01.6" + ], + "9(1)(d)": [ + "PRI-01.6" + ], + "9(1)(e)": [ + "PRI-01.6" + ], + "9(2)": [ + "PRI-01.6" + ], + "9(2)(a)": [ + "PRI-01.6" + ], + "9(2)(b)": [ + "PRI-01.6" + ], + "5(1)": [ + "PRI-01.11" + ], + "5(1)(a)": [ + "PRI-01.11" + ], + "5(1)(b)": [ + "PRI-01.11" + ], + "5(1)(c)": [ + "PRI-01.11" + ], + "5(1)(d)": [ + "PRI-01.11" + ], + "5(1)(e)": [ + "PRI-01.11" + ], + "5(1)(f)": [ + "PRI-01.11" + ], + "5(1)(g)": [ + "PRI-01.11" + ], + "130(1)": [ + "PRI-01.11" ], - "7": [ - "PRI-02", + "130(1)(a)": [ + "PRI-01.11" + ], + "130(1)(b)": [ + "PRI-01.11" + ], + "130(2)": [ + "PRI-01.11" + ], + "130(2)(a)": [ + "PRI-01.11" + ], + "130(2)(a)(i)": [ + "PRI-01.11" + ], + "130(2)(a)(ii)": [ + "PRI-01.11" + ], + "130(2)(b)": [ + "PRI-01.11" + ], + "130(2)(c)": [ + "PRI-01.11" + ], + "130(2)(d)": [ + "PRI-01.11" + ], + "130(3)": [ + "PRI-01.11" + ], + "130(4)": [ + "PRI-01.11" + ], + "130(5)": [ + "PRI-01.11" + ], + "130(5)(a)": [ + "PRI-01.11" + ], + "130(5)(b)": [ + "PRI-01.11" + ], + "130(6)": [ + "PRI-01.11" + ], + "7(1)": [ + "PRI-02" + ], + "7(1)(a)": [ + "PRI-02" + ], + "7(1)(b)": [ + "PRI-02" + ], + "7(1)(c)": [ + "PRI-02" + ], + "7(1)(d)": [ + "PRI-02" + ], + "7(1)(e)": [ + "PRI-02" + ], + "7(1)(f)": [ + "PRI-02" + ], + "7(1)(g)": [ + "PRI-02" + ], + "7(1)(h)": [ + "PRI-02" + ], + "7(2)": [ + "PRI-02" + ], + "7(2)(a)": [ + "PRI-02" + ], + "7(2)(b)": [ + "PRI-02" + ], + "7(2)(c)": [ + "PRI-02" + ], + "7(2)(c)(i)": [ + "PRI-02" + ], + "7(2)(c)(ii)": [ + "PRI-02" + ], + "7(3)": [ "PRI-03" ], - "9": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "DCH-25", - "IRO-14", - "PRI-07", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "10": [ + "38(1)": [ + "PRI-03.4" + ], + "43(1)": [ + "PRI-03.4" + ], + "38(2)": [ + "PRI-03.10" + ], + "42(1)": [ + "PRI-03.10" + ], + "42(1)(a)": [ + "PRI-03.10" + ], + "10(1)": [ "PRI-05" ], - "11": [ - "PRI-05.2" + "10(2)": [ + "PRI-05" ], - "12": [ + "6(1)(a)": [ + "PRI-05.4" + ], + "6(2)": [ + "PRI-05.4" + ], + "6(2)(a)": [ + "PRI-05.4" + ], + "6(2)(b)": [ + "PRI-05.4" + ], + "6(2)(c)": [ + "PRI-05.4" + ], + "6(2)(d)": [ + "PRI-05.4" + ], + "6(2)(e)": [ + "PRI-05.4" + ], + "6(2)(f)": [ + "PRI-05.4" + ], + "6(3)": [ + "PRI-05.4" + ], + "6(3)(a)": [ + "PRI-05.4" + ], + "6(3)(b)": [ + "PRI-05.4" + ], + "6(3)(c)": [ + "PRI-05.4" + ], + "8(a)": [ + "PRI-05.4" + ], + "8(a)(i)": [ + "PRI-05.4" + ], + "8(a)(ii)": [ + "PRI-05.4" + ], + "8(b)": [ + "PRI-05.4" + ], + "39(a)": [ + "PRI-05.4" + ], + "39(b)": [ + "PRI-05.4" + ], + "39(b)(i)": [ + "PRI-05.4" + ], + "39(b)(ii)": [ + "PRI-05.4" + ], + "39(c)": [ + "PRI-05.4" + ], + "39(d)": [ + "PRI-05.4" + ], + "39(e)": [ + "PRI-05.4" + ], + "40(1)": [ + "PRI-05.4" + ], + "40(1)(a)": [ + "PRI-05.4" + ], + "40(1)(b)": [ + "PRI-05.4" + ], + "40(1)(b)(i)": [ + "PRI-05.4" + ], + "40(1)(b)(ii)": [ + "PRI-05.4" + ], + "40(1)(b)(ii)(A)": [ + "PRI-05.4" + ], + "40(1)(b)(ii)(B)": [ + "PRI-05.4" + ], + "40(1)(b)(iii)": [ + "PRI-05.4" + ], + "40(1)(b)(iv)": [ + "PRI-05.4" + ], + "40(1)(b)(iv)(A)": [ + "PRI-05.4" + ], + "40(1)(b)(iv)(B)": [ + "PRI-05.4" + ], + "40(1)(b)(v)": [ + "PRI-05.4" + ], + "40(1)(b)(vi)": [ + "PRI-05.4" + ], + "40(1)(b)(vii)": [ + "PRI-05.4" + ], + "40(1)(b)(viii)": [ + "PRI-05.4" + ], + "40(1)(b)(ix)": [ + "PRI-05.4" + ], + "40(1)(b)(x)": [ + "PRI-05.4" + ], + "40(1)(c)": [ + "PRI-05.4" + ], + "42(1)(b)": [ + "PRI-05.4" + ], + "42(1)(b)(A)": [ + "PRI-05.4" + ], + "42(1)(b)(B)": [ + "PRI-05.4" + ], + "42(2)": [ + "PRI-05.4" + ], + "42(2)(a)": [ + "PRI-05.4" + ], + "42(2)(b)": [ + "PRI-05.4" + ], + "42(2)(b)(i)": [ + "PRI-05.4" + ], + "42(2)(b)(ii)": [ + "PRI-05.4" + ], + "42(2)(b)(iii)": [ + "PRI-05.4" + ], + "42(2)(b)(iv)": [ + "PRI-05.4" + ], + "42(2)(c)": [ + "PRI-05.4" + ], + "42(3)": [ + "PRI-05.4" + ], + "42(3)(a)": [ + "PRI-05.4" + ], + "42(3)(b)": [ + "PRI-05.4" + ], + "42(4)": [ + "PRI-05.4" + ], + "42(5)": [ + "PRI-05.4" + ], + "30(1)": [ "PRI-06" ], - "14": [ - "PRI-15" + "30(2)(a)": [ + "PRI-06" ], - "15": [ - "PRI-15" + "30(2)(b)": [ + "PRI-06" ], - "23": [ - "PRI-01" + "34(1)(a)": [ + "PRI-06" ], - "30": [ + "34(1)(b)": [ "PRI-06" ], - "34": [ - "DCH-22.1", - "PRI-05.4", + "34(2)": [ + "PRI-06" + ], + "35(1)": [ + "PRI-06.1" + ], + "35(1)(a)": [ + "PRI-06.1" + ], + "35(1)(b)": [ + "PRI-06.1" + ], + "35(1)(c)": [ + "PRI-06.1" + ], + "35(1)(c)(i)": [ + "PRI-06.1" + ], + "35(1)(c)(ii)": [ + "PRI-06.1" + ], + "35(2)": [ + "PRI-06.1" + ], + "35(2)(a)": [ + "PRI-06.1" + ], + "35(2)(b)": [ + "PRI-06.1" + ], + "35(3)": [ + "PRI-06.1" + ], + "35(4)": [ + "PRI-06.1" + ], + "35(4)(a)": [ + "PRI-06.1" + ], + "35(4)(b)": [ + "PRI-06.1" + ], + "35(5)": [ + "PRI-06.1" + ], + "35(5)(a)": [ + "PRI-06.1" + ], + "35(5)(b)": [ "PRI-06.1" + ], + "37(1)": [ + "PRI-06.2" + ], + "37(1)(a)": [ + "PRI-06.2" + ], + "37(1)(b)": [ + "PRI-06.2" + ], + "30(3)": [ + "PRI-06.4" + ], + "30(4)": [ + "PRI-06.4" + ], + "30(5)": [ + "PRI-06.4" + ], + "31(1)": [ + "PRI-06.4" + ], + "31(2)": [ + "PRI-06.4" + ], + "31(2)(a)": [ + "PRI-06.4" + ], + "31(2)(b)": [ + "PRI-06.4" + ], + "31(3)": [ + "PRI-06.4" + ], + "32(1)": [ + "PRI-06.4" + ], + "32(1)(a)": [ + "PRI-06.4" + ], + "32(1)(b)": [ + "PRI-06.4" + ], + "32(1)(c)": [ + "PRI-06.4" + ], + "32(2)": [ + "PRI-06.4" + ], + "32(2)(a)": [ + "PRI-06.4" + ], + "32(2)(b)": [ + "PRI-06.4" + ], + "32(2)(c)": [ + "PRI-06.4" + ], + "32(2)(d)": [ + "PRI-06.4" + ], + "32(3)": [ + "PRI-06.4" + ], + "33(a)": [ + "PRI-06.4" + ], + "33(b)": [ + "PRI-06.4" + ], + "32(1)(a)(i)": [ + "PRI-06.8" + ], + "32(1)(a)(ii)": [ + "PRI-06.8" + ], + "32(1)(a)(ii)(A)": [ + "PRI-06.8" + ], + "32(1)(a)(ii)(B)": [ + "PRI-06.8" + ], + "36(1)": [ + "PRI-07.4" + ], + "36(1)(a)": [ + "PRI-07.4" + ], + "36(1)(a)(i)": [ + "PRI-07.4" + ], + "36(1)(a)(ii)": [ + "PRI-07.4" + ], + "36(1)(a)(ii)(A)": [ + "PRI-07.4" + ], + "36(1)(a)(ii)(B)": [ + "PRI-07.4" + ], + "36(1)(b)": [ + "PRI-07.4" + ], + "36(1)(c)": [ + "PRI-07.4" + ], + "36(1)(d)": [ + "PRI-07.4" + ], + "36(1)(e)": [ + "PRI-07.4" + ], + "36(2)": [ + "PRI-07.4" + ], + "32(1)(d)": [ + "PRI-07.5" + ], + "32(1)(d)(i)": [ + "PRI-07.5" + ], + "32(1)(d)(ii)": [ + "PRI-07.5" + ], + "32(1)(e)": [ + "PRI-07.5" + ], + "32(1)(f)": [ + "PRI-07.5" + ], + "32(1)(g)": [ + "PRI-07.5" + ], + "32(1)(h)": [ + "PRI-07.5" + ], + "44(1)": [ + "PRI-14" + ], + "37(2)": [ + "PRI-17.3" + ], + "37(2)(a)": [ + "PRI-17.3" + ], + "37(2)(a)(i)": [ + "PRI-17.3" + ], + "37(2)(a)(ii)": [ + "PRI-17.3" + ], + "37(2)(b)": [ + "PRI-17.3" + ], + "37(3)": [ + "PRI-17.3" ] } } diff --git a/docs/api/crosswalks/apac-nzl-hisf-microsmall-2023.json b/docs/api/crosswalks/apac-nzl-hisf-microsmall-2023.json index 1e20c3cc..ca345ad4 100644 --- a/docs/api/crosswalks/apac-nzl-hisf-microsmall-2023.json +++ b/docs/api/crosswalks/apac-nzl-hisf-microsmall-2023.json @@ -2,183 +2,1065 @@ "framework_id": "apac-nzl-hisf-microsmall-2023", "display_name": "New Zealand - HISF MicroSmall (2023)", "scf_to_framework": { - "total_mappings": 32, + "total_mappings": 102, "mappings": { + "GOV-01.1": [ + "HHSP12", + "HML12", + "HML21" + ], + "GOV-01.2": [ + "HHSP46", + "HHSP75", + "HML12", + "HML46", + "HML75" + ], "GOV-02": [ - "HMS02" + "HML01", + "HHSP01" ], - "AST-01": [ - "HMS12", - "HMS14" + "GOV-03": [ + "HHSP67", + "HML66" + ], + "GOV-04": [ + "HHSP21", + "HHSP27", + "HML21", + "HML27" ], - "AST-01.4": [ - "HMS12" + "GOV-04.1": [ + "HHSP21", + "HHSP27", + "HML21", + "HML27" ], - "AST-02": [ - "HMS03" + "GOV-04.2": [ + "HHSP21" + ], + "GOV-05": [ + "HHSP46", + "HML46" + ], + "GOV-15": [ + "HHSP11", + "HHSP16", + "HHSP28", + "HML11", + "HML16", + "HML28" + ], + "AST-01": [ + "HHSP05", + "HHSP54", + "HML05", + "HML54" ], - "AST-02.7": [ - "HMS14" + "AST-09": [ + "HHSP06", + "HHSP45", + "HML06", + "HML45" ], "BCD-01": [ - "HMS21" + "HHSP08", + "HHSP24", + "HHSP56", + "HHSP61", + "HML08", + "HML24", + "HML61" + ], + "BCD-01.4": [ + "HHSP24", + "HML24" + ], + "BCD-02.1": [ + "HHSP35", + "HML35" + ], + "BCD-02.2": [ + "HHSP35", + "HML35" + ], + "BCD-05": [ + "HHSP64", + "HML63" ], "BCD-11": [ - "HMS11" + "HHSP17", + "HHSP56", + "HHSP69", + "HML17", + "HML56", + "HML68" ], "BCD-11.1": [ - "HMS11" + "HHSP57", + "HHSP69", + "HML57", + "HML68" + ], + "BCD-11.10": [ + "HHSP56", + "HML56" + ], + "BCD-12": [ + "HHSP17", + "HML17" + ], + "CAP-01": [ + "HHSP61", + "HML61" ], - "BCD-11.4": [ - "HMS11" + "CHG-01": [ + "HHSP18", + "HML18" + ], + "CHG-02": [ + "HHSP18", + "HML18" + ], + "CHG-03": [ + "HHSP33", + "HML33" + ], + "CLD-02": [ + "HHSP51", + "HML51" + ], + "CLD-04": [ + "HHSP52", + "HML52" + ], + "CLD-06": [ + "HHSP53", + "HML53" + ], + "CPL-01": [ + "HHSP29", + "HML29" + ], + "CPL-02": [ + "HHSP67", + "HML66" + ], + "CPL-02.1": [ + "HHSP67", + "HML66" ], "CFG-02": [ - "HMS09" + "HHSP54", + "HHSP60", + "HHSP65", + "HML16", + "HML54", + "HML60", + "HML64" ], "MON-01": [ - "HMS18" + "HHSP70", + "HML70" ], - "MON-01.2": [ - "HMS19" + "MON-01.4": [ + "HHSP69", + "HML68" ], - "MON-10": [ - "HMS18" + "MON-01.12": [ + "HHSP69", + "HML68" ], - "MON-16": [ - "HMS19" + "MON-03": [ + "HHSP70", + "HML70" ], - "DCH-06.2": [ - "HMS03" + "MON-03.2": [ + "HHSP70", + "HML70" + ], + "MON-07.1": [ + "HHSP71", + "HML71" + ], + "MON-11": [ + "HHSP63", + "HML69" + ], + "CRY-01": [ + "HHSP37", + "HML37" + ], + "DCH-01": [ + "HHSP14", + "HHSP34", + "HHSP74", + "HML14", + "HML74" + ], + "DCH-01.2": [ + "HHSP14", + "HHSP74", + "HML14", + "HML74" + ], + "DCH-02": [ + "HML34" ], "DCH-12": [ - "HMS09" + "HHSP14", + "HML14" ], - "END-02": [ - "HMS09" + "END-01": [ + "HHSP34" ], "END-04": [ - "HMS10" + "HHSP62", + "HML62" + ], + "HRS-01": [ + "HML02" ], "HRS-03": [ - "HMS01" + "HHSP02", + "HHSP23", + "HML02", + "HML23" + ], + "HRS-04": [ + "HHSP20", + "HML20" + ], + "HRS-07": [ + "HHSP03", + "HHSP72", + "HHSP73", + "HML03", + "HML72", + "HML73" + ], + "HRS-07.1": [ + "HHSP03", + "HHSP73", + "HML03", + "HML73" + ], + "IAC-01.2": [ + "HHSP39", + "HML39" + ], + "IAC-05": [ + "HHSP49", + "HML49" + ], + "IAC-07": [ + "HHSP04", + "HML04" + ], + "IAC-07.1": [ + "HHSP04", + "HML04" + ], + "IAC-07.2": [ + "HHSP04", + "HML04" ], "IAC-08": [ - "HMS07" + "HHSP40", + "HHSP42", + "HML40", + "HML42" + ], + "IAC-15": [ + "HHSP38", + "HML38" + ], + "IAC-16": [ + "HHSP41", + "HML41" ], "IAC-20": [ - "HMS07" + "HHSP10", + "HHSP40", + "HML10", + "HML40" + ], + "IRO-02": [ + "HHSP07", + "HML07" ], "IRO-04": [ - "HMS20" + "HHSP07", + "HML07" + ], + "IRO-08": [ + "HHSP74", + "HML74" + ], + "IRO-10": [ + "HHSP75", + "HML75" + ], + "IAO-01": [ + "HHSP68", + "HML67" + ], + "IAO-02": [ + "HHSP68", + "HML67" ], - "NET-02.1": [ - "HMS17" + "MNT-01": [ + "HHSP15", + "HML15" + ], + "NET-01": [ + "HHSP49", + "HHSP54", + "HML49", + "HML54" ], "NET-03.7": [ - "HMS16" + "HHSP43", + "HHSP55", + "HML43", + "HML55" + ], + "NET-06": [ + "HHSP55", + "HML55" + ], + "NET-17": [ + "HHSP63", + "HML69" + ], + "PES-01": [ + "HHSP47", + "HML47" + ], + "PES-01.1": [ + "HHSP13", + "HML13" + ], + "PES-02": [ + "HHSP04", + "HML04" + ], + "PES-03": [ + "HHSP48", + "HML48" + ], + "PES-03.4": [ + "HHSP10", + "HML10" + ], + "PES-04": [ + "HHSP48", + "HML48" + ], + "PES-05": [ + "HHSP66", + "HML65" + ], + "PRM-04": [ + "HHSP11", + "HHSP28", + "HHSP31", + "HML11", + "HML28", + "HML31" + ], + "PRM-05": [ + "HHSP11", + "HHSP28", + "HHSP31", + "HML31" + ], + "RSK-01": [ + "HHSP30", + "HML30" + ], + "RSK-04": [ + "HHSP32", + "HML32" ], - "NET-06.3": [ - "HMS15" + "RSK-04.1": [ + "HHSP65", + "HML64" ], - "NET-12": [ - "HMS17" + "RSK-06.2": [ + "HHSP26", + "HHSP43", + "HHSP65", + "HML26", + "HML43", + "HML64" ], - "NET-14": [ - "HMS13" + "SEA-01": [ + "HHSP16", + "HML16" ], - "NET-14.5": [ - "HMS13" + "SAT-01": [ + "HHSP22", + "HML22" ], - "RSK-07": [ - "HMS05" + "TDA-01": [ + "HHSP50", + "HML50" + ], + "TDA-01.1": [ + "HHSP50", + "HML50" + ], + "TDA-02": [ + "HHSP31", + "HML31" + ], + "TDA-06": [ + "HHSP50", + "HML50" + ], + "TDA-08": [ + "HHSP58", + "HML58" + ], + "TDA-17": [ + "HHSP43", + "HML43" + ], + "TDA-20": [ + "HHSP42", + "HML42" + ], + "TPM-01": [ + "HHSP25", + "HML25" + ], + "TPM-04.1": [ + "HHSP25", + "HML25" ], "TPM-05": [ - "HMS06" + "HHSP09", + "HHSP36", + "HHSP72", + "HML09", + "HML36", + "HML72" + ], + "TPM-07": [ + "HHSP73", + "HML73" ], "TPM-08": [ - "HMS04" + "HHSP25", + "HHSP73", + "HML25", + "HML73" + ], + "VPM-01": [ + "HHSP19", + "HHSP26", + "HML19", + "HML26" + ], + "VPM-02": [ + "HHSP19", + "HHSP59", + "HML19", + "HML59" ], "VPM-04.1": [ - "HMS08" + "HHSP44", + "HML44" + ], + "VPM-05": [ + "HHSP19", + "HML19" + ], + "VPM-06": [ + "HHSP26", + "HHSP59", + "HML26", + "HML59" ] } }, "framework_to_scf": { - "total_mappings": 21, + "total_mappings": 150, "mappings": { - "HMS02": [ + "HHSP12": [ + "GOV-01.1" + ], + "HML12": [ + "GOV-01.1", + "GOV-01.2" + ], + "HML21": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1" + ], + "HHSP46": [ + "GOV-01.2", + "GOV-05" + ], + "HHSP75": [ + "GOV-01.2", + "IRO-10" + ], + "HML46": [ + "GOV-01.2", + "GOV-05" + ], + "HML75": [ + "GOV-01.2", + "IRO-10" + ], + "HML01": [ + "GOV-02" + ], + "HHSP01": [ "GOV-02" ], - "HMS12": [ + "HHSP67": [ + "GOV-03", + "CPL-02", + "CPL-02.1" + ], + "HML66": [ + "GOV-03", + "CPL-02", + "CPL-02.1" + ], + "HHSP21": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" + ], + "HHSP27": [ + "GOV-04", + "GOV-04.1" + ], + "HML27": [ + "GOV-04", + "GOV-04.1" + ], + "HHSP11": [ + "GOV-15", + "PRM-04", + "PRM-05" + ], + "HHSP16": [ + "GOV-15", + "SEA-01" + ], + "HHSP28": [ + "GOV-15", + "PRM-04", + "PRM-05" + ], + "HML11": [ + "GOV-15", + "PRM-04" + ], + "HML16": [ + "GOV-15", + "CFG-02", + "SEA-01" + ], + "HML28": [ + "GOV-15", + "PRM-04" + ], + "HHSP05": [ + "AST-01" + ], + "HHSP54": [ "AST-01", - "AST-01.4" + "CFG-02", + "NET-01" + ], + "HML05": [ + "AST-01" ], - "HMS14": [ + "HML54": [ "AST-01", - "AST-02.7" + "CFG-02", + "NET-01" + ], + "HHSP06": [ + "AST-09" + ], + "HHSP45": [ + "AST-09" + ], + "HML06": [ + "AST-09" ], - "HMS03": [ - "AST-02", - "DCH-06.2" + "HML45": [ + "AST-09" ], - "HMS21": [ + "HHSP08": [ "BCD-01" ], - "HMS11": [ + "HHSP24": [ + "BCD-01", + "BCD-01.4" + ], + "HHSP56": [ + "BCD-01", + "BCD-11", + "BCD-11.10" + ], + "HHSP61": [ + "BCD-01", + "CAP-01" + ], + "HML08": [ + "BCD-01" + ], + "HML24": [ + "BCD-01", + "BCD-01.4" + ], + "HML61": [ + "BCD-01", + "CAP-01" + ], + "HHSP35": [ + "BCD-02.1", + "BCD-02.2" + ], + "HML35": [ + "BCD-02.1", + "BCD-02.2" + ], + "HHSP64": [ + "BCD-05" + ], + "HML63": [ + "BCD-05" + ], + "HHSP17": [ + "BCD-11", + "BCD-12" + ], + "HHSP69": [ + "BCD-11", + "BCD-11.1", + "MON-01.4", + "MON-01.12" + ], + "HML17": [ + "BCD-11", + "BCD-12" + ], + "HML56": [ + "BCD-11", + "BCD-11.10" + ], + "HML68": [ "BCD-11", "BCD-11.1", - "BCD-11.4" + "MON-01.4", + "MON-01.12" + ], + "HHSP57": [ + "BCD-11.1" + ], + "HML57": [ + "BCD-11.1" + ], + "HHSP18": [ + "CHG-01", + "CHG-02" + ], + "HML18": [ + "CHG-01", + "CHG-02" + ], + "HHSP33": [ + "CHG-03" + ], + "HML33": [ + "CHG-03" + ], + "HHSP51": [ + "CLD-02" + ], + "HML51": [ + "CLD-02" + ], + "HHSP52": [ + "CLD-04" + ], + "HML52": [ + "CLD-04" + ], + "HHSP53": [ + "CLD-06" ], - "HMS09": [ + "HML53": [ + "CLD-06" + ], + "HHSP29": [ + "CPL-01" + ], + "HML29": [ + "CPL-01" + ], + "HHSP60": [ + "CFG-02" + ], + "HHSP65": [ "CFG-02", - "DCH-12", - "END-02" + "RSK-04.1", + "RSK-06.2" ], - "HMS18": [ + "HML60": [ + "CFG-02" + ], + "HML64": [ + "CFG-02", + "RSK-04.1", + "RSK-06.2" + ], + "HHSP70": [ "MON-01", - "MON-10" + "MON-03", + "MON-03.2" + ], + "HML70": [ + "MON-01", + "MON-03", + "MON-03.2" + ], + "HHSP71": [ + "MON-07.1" + ], + "HML71": [ + "MON-07.1" + ], + "HHSP63": [ + "MON-11", + "NET-17" + ], + "HML69": [ + "MON-11", + "NET-17" + ], + "HHSP37": [ + "CRY-01" + ], + "HML37": [ + "CRY-01" ], - "HMS19": [ - "MON-01.2", - "MON-16" + "HHSP14": [ + "DCH-01", + "DCH-01.2", + "DCH-12" ], - "HMS10": [ + "HHSP34": [ + "DCH-01", + "END-01" + ], + "HHSP74": [ + "DCH-01", + "DCH-01.2", + "IRO-08" + ], + "HML14": [ + "DCH-01", + "DCH-01.2", + "DCH-12" + ], + "HML74": [ + "DCH-01", + "DCH-01.2", + "IRO-08" + ], + "HML34": [ + "DCH-02" + ], + "HHSP62": [ + "END-04" + ], + "HML62": [ "END-04" ], - "HMS01": [ + "HML02": [ + "HRS-01", "HRS-03" ], - "HMS07": [ + "HHSP02": [ + "HRS-03" + ], + "HHSP23": [ + "HRS-03" + ], + "HML23": [ + "HRS-03" + ], + "HHSP20": [ + "HRS-04" + ], + "HML20": [ + "HRS-04" + ], + "HHSP03": [ + "HRS-07", + "HRS-07.1" + ], + "HHSP72": [ + "HRS-07", + "TPM-05" + ], + "HHSP73": [ + "HRS-07", + "HRS-07.1", + "TPM-07", + "TPM-08" + ], + "HML03": [ + "HRS-07", + "HRS-07.1" + ], + "HML72": [ + "HRS-07", + "TPM-05" + ], + "HML73": [ + "HRS-07", + "HRS-07.1", + "TPM-07", + "TPM-08" + ], + "HHSP39": [ + "IAC-01.2" + ], + "HML39": [ + "IAC-01.2" + ], + "HHSP49": [ + "IAC-05", + "NET-01" + ], + "HML49": [ + "IAC-05", + "NET-01" + ], + "HHSP04": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "PES-02" + ], + "HML04": [ + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "PES-02" + ], + "HHSP40": [ + "IAC-08", + "IAC-20" + ], + "HHSP42": [ + "IAC-08", + "TDA-20" + ], + "HML40": [ "IAC-08", "IAC-20" ], - "HMS20": [ + "HML42": [ + "IAC-08", + "TDA-20" + ], + "HHSP38": [ + "IAC-15" + ], + "HML38": [ + "IAC-15" + ], + "HHSP41": [ + "IAC-16" + ], + "HML41": [ + "IAC-16" + ], + "HHSP10": [ + "IAC-20", + "PES-03.4" + ], + "HML10": [ + "IAC-20", + "PES-03.4" + ], + "HHSP07": [ + "IRO-02", "IRO-04" ], - "HMS17": [ - "NET-02.1", - "NET-12" + "HML07": [ + "IRO-02", + "IRO-04" ], - "HMS16": [ - "NET-03.7" + "HHSP68": [ + "IAO-01", + "IAO-02" ], - "HMS15": [ - "NET-06.3" + "HML67": [ + "IAO-01", + "IAO-02" ], - "HMS13": [ - "NET-14", - "NET-14.5" + "HHSP15": [ + "MNT-01" ], - "HMS05": [ - "RSK-07" + "HML15": [ + "MNT-01" ], - "HMS06": [ - "TPM-05" + "HHSP43": [ + "NET-03.7", + "RSK-06.2", + "TDA-17" + ], + "HHSP55": [ + "NET-03.7", + "NET-06" + ], + "HML43": [ + "NET-03.7", + "RSK-06.2", + "TDA-17" + ], + "HML55": [ + "NET-03.7", + "NET-06" + ], + "HHSP47": [ + "PES-01" + ], + "HML47": [ + "PES-01" + ], + "HHSP13": [ + "PES-01.1" + ], + "HML13": [ + "PES-01.1" + ], + "HHSP48": [ + "PES-03", + "PES-04" + ], + "HML48": [ + "PES-03", + "PES-04" + ], + "HHSP66": [ + "PES-05" + ], + "HML65": [ + "PES-05" + ], + "HHSP31": [ + "PRM-04", + "PRM-05", + "TDA-02" ], - "HMS04": [ + "HML31": [ + "PRM-04", + "PRM-05", + "TDA-02" + ], + "HHSP30": [ + "RSK-01" + ], + "HML30": [ + "RSK-01" + ], + "HHSP32": [ + "RSK-04" + ], + "HML32": [ + "RSK-04" + ], + "HHSP26": [ + "RSK-06.2", + "VPM-01", + "VPM-06" + ], + "HML26": [ + "RSK-06.2", + "VPM-01", + "VPM-06" + ], + "HHSP22": [ + "SAT-01" + ], + "HML22": [ + "SAT-01" + ], + "HHSP50": [ + "TDA-01", + "TDA-01.1", + "TDA-06" + ], + "HML50": [ + "TDA-01", + "TDA-01.1", + "TDA-06" + ], + "HHSP58": [ + "TDA-08" + ], + "HML58": [ + "TDA-08" + ], + "HHSP25": [ + "TPM-01", + "TPM-04.1", + "TPM-08" + ], + "HML25": [ + "TPM-01", + "TPM-04.1", "TPM-08" ], - "HMS08": [ + "HHSP09": [ + "TPM-05" + ], + "HHSP36": [ + "TPM-05" + ], + "HML09": [ + "TPM-05" + ], + "HML36": [ + "TPM-05" + ], + "HHSP19": [ + "VPM-01", + "VPM-02", + "VPM-05" + ], + "HML19": [ + "VPM-01", + "VPM-02", + "VPM-05" + ], + "HHSP59": [ + "VPM-02", + "VPM-06" + ], + "HML59": [ + "VPM-02", + "VPM-06" + ], + "HHSP44": [ + "VPM-04.1" + ], + "HML44": [ "VPM-04.1" ] } diff --git a/docs/api/crosswalks/apac-nzl-hisf-mlhsp-2023.json b/docs/api/crosswalks/apac-nzl-hisf-mlhsp-2023.json index 41791cbe..d24b826d 100644 --- a/docs/api/crosswalks/apac-nzl-hisf-mlhsp-2023.json +++ b/docs/api/crosswalks/apac-nzl-hisf-mlhsp-2023.json @@ -2,1067 +2,11 @@ "framework_id": "apac-nzl-hisf-mlhsp-2023", "display_name": "New Zealand - HISF MLHSP (2023)", "scf_to_framework": { - "total_mappings": 102, - "mappings": { - "GOV-01.1": [ - "HHSP12", - "HML12", - "HML21" - ], - "GOV-01.2": [ - "HHSP46", - "HHSP75", - "HML12", - "HML46", - "HML75" - ], - "GOV-02": [ - "HML01", - "HHSP01" - ], - "GOV-03": [ - "HHSP67", - "HML66" - ], - "GOV-04": [ - "HHSP21", - "HHSP27", - "HML21", - "HML27" - ], - "GOV-04.1": [ - "HHSP21", - "HHSP27", - "HML21", - "HML27" - ], - "GOV-04.2": [ - "HHSP21" - ], - "GOV-05": [ - "HHSP46", - "HML46" - ], - "GOV-15": [ - "HHSP11", - "HHSP16", - "HHSP28", - "HML11", - "HML16", - "HML28" - ], - "AST-01": [ - "HHSP05", - "HHSP54", - "HML05", - "HML54" - ], - "AST-09": [ - "HHSP06", - "HHSP45", - "HML06", - "HML45" - ], - "BCD-01": [ - "HHSP08", - "HHSP24", - "HHSP56", - "HHSP61", - "HML08", - "HML24", - "HML61" - ], - "BCD-01.4": [ - "HHSP24", - "HML24" - ], - "BCD-02.1": [ - "HHSP35", - "HML35" - ], - "BCD-02.2": [ - "HHSP35", - "HML35" - ], - "BCD-05": [ - "HHSP64", - "HML63" - ], - "BCD-11": [ - "HHSP17", - "HHSP56", - "HHSP69", - "HML17", - "HML56", - "HML68" - ], - "BCD-11.1": [ - "HHSP57", - "HHSP69", - "HML57", - "HML68" - ], - "BCD-11.10": [ - "HHSP56", - "HML56" - ], - "BCD-12": [ - "HHSP17", - "HML17" - ], - "CAP-01": [ - "HHSP61", - "HML61" - ], - "CHG-01": [ - "HHSP18", - "HML18" - ], - "CHG-02": [ - "HHSP18", - "HML18" - ], - "CHG-03": [ - "HHSP33", - "HML33" - ], - "CLD-02": [ - "HHSP51", - "HML51" - ], - "CLD-04": [ - "HHSP52", - "HML52" - ], - "CLD-06": [ - "HHSP53", - "HML53" - ], - "CPL-01": [ - "HHSP29", - "HML29" - ], - "CPL-02": [ - "HHSP67", - "HML66" - ], - "CPL-02.1": [ - "HHSP67", - "HML66" - ], - "CFG-02": [ - "HHSP54", - "HHSP60", - "HHSP65", - "HML16", - "HML54", - "HML60", - "HML64" - ], - "MON-01": [ - "HHSP70", - "HML70" - ], - "MON-01.4": [ - "HHSP69", - "HML68" - ], - "MON-01.12": [ - "HHSP69", - "HML68" - ], - "MON-03": [ - "HHSP70", - "HML70" - ], - "MON-03.2": [ - "HHSP70", - "HML70" - ], - "MON-07.1": [ - "HHSP71", - "HML71" - ], - "MON-11": [ - "HHSP63", - "HML69" - ], - "CRY-01": [ - "HHSP37", - "HML37" - ], - "DCH-01": [ - "HHSP14", - "HHSP34", - "HHSP74", - "HML14", - "HML74" - ], - "DCH-01.2": [ - "HHSP14", - "HHSP74", - "HML14", - "HML74" - ], - "DCH-02": [ - "HML34" - ], - "DCH-12": [ - "HHSP14", - "HML14" - ], - "END-01": [ - "HHSP34" - ], - "END-04": [ - "HHSP62", - "HML62" - ], - "HRS-01": [ - "HML02" - ], - "HRS-03": [ - "HHSP02", - "HHSP23", - "HML02", - "HML23" - ], - "HRS-04": [ - "HHSP20", - "HML20" - ], - "HRS-07": [ - "HHSP03", - "HHSP72", - "HHSP73", - "HML03", - "HML72", - "HML73" - ], - "HRS-07.1": [ - "HHSP03", - "HHSP73", - "HML03", - "HML73" - ], - "IAC-01.2": [ - "HHSP39", - "HML39" - ], - "IAC-05": [ - "HHSP49", - "HML49" - ], - "IAC-07": [ - "HHSP04", - "HML04" - ], - "IAC-07.1": [ - "HHSP04", - "HML04" - ], - "IAC-07.2": [ - "HHSP04", - "HML04" - ], - "IAC-08": [ - "HHSP40", - "HHSP42", - "HML40", - "HML42" - ], - "IAC-15": [ - "HHSP38", - "HML38" - ], - "IAC-16": [ - "HHSP41", - "HML41" - ], - "IAC-20": [ - "HHSP10", - "HHSP40", - "HML10", - "HML40" - ], - "IRO-02": [ - "HHSP07", - "HML07" - ], - "IRO-04": [ - "HHSP07", - "HML07" - ], - "IRO-08": [ - "HHSP74", - "HML74" - ], - "IRO-10": [ - "HHSP75", - "HML75" - ], - "IAO-01": [ - "HHSP68", - "HML67" - ], - "IAO-02": [ - "HHSP68", - "HML67" - ], - "MNT-01": [ - "HHSP15", - "HML15" - ], - "NET-01": [ - "HHSP49", - "HHSP54", - "HML49", - "HML54" - ], - "NET-03.7": [ - "HHSP43", - "HHSP55", - "HML43", - "HML55" - ], - "NET-06": [ - "HHSP55", - "HML55" - ], - "NET-17": [ - "HHSP63", - "HML69" - ], - "PES-01": [ - "HHSP47", - "HML47" - ], - "PES-01.1": [ - "HHSP13", - "HML13" - ], - "PES-02": [ - "HHSP04", - "HML04" - ], - "PES-03": [ - "HHSP48", - "HML48" - ], - "PES-03.4": [ - "HHSP10", - "HML10" - ], - "PES-04": [ - "HHSP48", - "HML48" - ], - "PES-05": [ - "HHSP66", - "HML65" - ], - "PRM-04": [ - "HHSP11", - "HHSP28", - "HHSP31", - "HML11", - "HML28", - "HML31" - ], - "PRM-05": [ - "HHSP11", - "HHSP28", - "HHSP31", - "HML31" - ], - "RSK-01": [ - "HHSP30", - "HML30" - ], - "RSK-04": [ - "HHSP32", - "HML32" - ], - "RSK-04.1": [ - "HHSP65", - "HML64" - ], - "RSK-06.2": [ - "HHSP26", - "HHSP43", - "HHSP65", - "HML26", - "HML43", - "HML64" - ], - "SEA-01": [ - "HHSP16", - "HML16" - ], - "SAT-01": [ - "HHSP22", - "HML22" - ], - "TDA-01": [ - "HHSP50", - "HML50" - ], - "TDA-01.1": [ - "HHSP50", - "HML50" - ], - "TDA-02": [ - "HHSP31", - "HML31" - ], - "TDA-06": [ - "HHSP50", - "HML50" - ], - "TDA-08": [ - "HHSP58", - "HML58" - ], - "TDA-17": [ - "HHSP43", - "HML43" - ], - "TDA-20": [ - "HHSP42", - "HML42" - ], - "TPM-01": [ - "HHSP25", - "HML25" - ], - "TPM-04.1": [ - "HHSP25", - "HML25" - ], - "TPM-05": [ - "HHSP09", - "HHSP36", - "HHSP72", - "HML09", - "HML36", - "HML72" - ], - "TPM-07": [ - "HHSP73", - "HML73" - ], - "TPM-08": [ - "HHSP25", - "HHSP73", - "HML25", - "HML73" - ], - "VPM-01": [ - "HHSP19", - "HHSP26", - "HML19", - "HML26" - ], - "VPM-02": [ - "HHSP19", - "HHSP59", - "HML19", - "HML59" - ], - "VPM-04.1": [ - "HHSP44", - "HML44" - ], - "VPM-05": [ - "HHSP19", - "HML19" - ], - "VPM-06": [ - "HHSP26", - "HHSP59", - "HML26", - "HML59" - ] - } + "total_mappings": 0, + "mappings": {} }, "framework_to_scf": { - "total_mappings": 150, - "mappings": { - "HHSP12": [ - "GOV-01.1" - ], - "HML12": [ - "GOV-01.1", - "GOV-01.2" - ], - "HML21": [ - "GOV-01.1", - "GOV-04", - "GOV-04.1" - ], - "HHSP46": [ - "GOV-01.2", - "GOV-05" - ], - "HHSP75": [ - "GOV-01.2", - "IRO-10" - ], - "HML46": [ - "GOV-01.2", - "GOV-05" - ], - "HML75": [ - "GOV-01.2", - "IRO-10" - ], - "HML01": [ - "GOV-02" - ], - "HHSP01": [ - "GOV-02" - ], - "HHSP67": [ - "GOV-03", - "CPL-02", - "CPL-02.1" - ], - "HML66": [ - "GOV-03", - "CPL-02", - "CPL-02.1" - ], - "HHSP21": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2" - ], - "HHSP27": [ - "GOV-04", - "GOV-04.1" - ], - "HML27": [ - "GOV-04", - "GOV-04.1" - ], - "HHSP11": [ - "GOV-15", - "PRM-04", - "PRM-05" - ], - "HHSP16": [ - "GOV-15", - "SEA-01" - ], - "HHSP28": [ - "GOV-15", - "PRM-04", - "PRM-05" - ], - "HML11": [ - "GOV-15", - "PRM-04" - ], - "HML16": [ - "GOV-15", - "CFG-02", - "SEA-01" - ], - "HML28": [ - "GOV-15", - "PRM-04" - ], - "HHSP05": [ - "AST-01" - ], - "HHSP54": [ - "AST-01", - "CFG-02", - "NET-01" - ], - "HML05": [ - "AST-01" - ], - "HML54": [ - "AST-01", - "CFG-02", - "NET-01" - ], - "HHSP06": [ - "AST-09" - ], - "HHSP45": [ - "AST-09" - ], - "HML06": [ - "AST-09" - ], - "HML45": [ - "AST-09" - ], - "HHSP08": [ - "BCD-01" - ], - "HHSP24": [ - "BCD-01", - "BCD-01.4" - ], - "HHSP56": [ - "BCD-01", - "BCD-11", - "BCD-11.10" - ], - "HHSP61": [ - "BCD-01", - "CAP-01" - ], - "HML08": [ - "BCD-01" - ], - "HML24": [ - "BCD-01", - "BCD-01.4" - ], - "HML61": [ - "BCD-01", - "CAP-01" - ], - "HHSP35": [ - "BCD-02.1", - "BCD-02.2" - ], - "HML35": [ - "BCD-02.1", - "BCD-02.2" - ], - "HHSP64": [ - "BCD-05" - ], - "HML63": [ - "BCD-05" - ], - "HHSP17": [ - "BCD-11", - "BCD-12" - ], - "HHSP69": [ - "BCD-11", - "BCD-11.1", - "MON-01.4", - "MON-01.12" - ], - "HML17": [ - "BCD-11", - "BCD-12" - ], - "HML56": [ - "BCD-11", - "BCD-11.10" - ], - "HML68": [ - "BCD-11", - "BCD-11.1", - "MON-01.4", - "MON-01.12" - ], - "HHSP57": [ - "BCD-11.1" - ], - "HML57": [ - "BCD-11.1" - ], - "HHSP18": [ - "CHG-01", - "CHG-02" - ], - "HML18": [ - "CHG-01", - "CHG-02" - ], - "HHSP33": [ - "CHG-03" - ], - "HML33": [ - "CHG-03" - ], - "HHSP51": [ - "CLD-02" - ], - "HML51": [ - "CLD-02" - ], - "HHSP52": [ - "CLD-04" - ], - "HML52": [ - "CLD-04" - ], - "HHSP53": [ - "CLD-06" - ], - "HML53": [ - "CLD-06" - ], - "HHSP29": [ - "CPL-01" - ], - "HML29": [ - "CPL-01" - ], - "HHSP60": [ - "CFG-02" - ], - "HHSP65": [ - "CFG-02", - "RSK-04.1", - "RSK-06.2" - ], - "HML60": [ - "CFG-02" - ], - "HML64": [ - "CFG-02", - "RSK-04.1", - "RSK-06.2" - ], - "HHSP70": [ - "MON-01", - "MON-03", - "MON-03.2" - ], - "HML70": [ - "MON-01", - "MON-03", - "MON-03.2" - ], - "HHSP71": [ - "MON-07.1" - ], - "HML71": [ - "MON-07.1" - ], - "HHSP63": [ - "MON-11", - "NET-17" - ], - "HML69": [ - "MON-11", - "NET-17" - ], - "HHSP37": [ - "CRY-01" - ], - "HML37": [ - "CRY-01" - ], - "HHSP14": [ - "DCH-01", - "DCH-01.2", - "DCH-12" - ], - "HHSP34": [ - "DCH-01", - "END-01" - ], - "HHSP74": [ - "DCH-01", - "DCH-01.2", - "IRO-08" - ], - "HML14": [ - "DCH-01", - "DCH-01.2", - "DCH-12" - ], - "HML74": [ - "DCH-01", - "DCH-01.2", - "IRO-08" - ], - "HML34": [ - "DCH-02" - ], - "HHSP62": [ - "END-04" - ], - "HML62": [ - "END-04" - ], - "HML02": [ - "HRS-01", - "HRS-03" - ], - "HHSP02": [ - "HRS-03" - ], - "HHSP23": [ - "HRS-03" - ], - "HML23": [ - "HRS-03" - ], - "HHSP20": [ - "HRS-04" - ], - "HML20": [ - "HRS-04" - ], - "HHSP03": [ - "HRS-07", - "HRS-07.1" - ], - "HHSP72": [ - "HRS-07", - "TPM-05" - ], - "HHSP73": [ - "HRS-07", - "HRS-07.1", - "TPM-07", - "TPM-08" - ], - "HML03": [ - "HRS-07", - "HRS-07.1" - ], - "HML72": [ - "HRS-07", - "TPM-05" - ], - "HML73": [ - "HRS-07", - "HRS-07.1", - "TPM-07", - "TPM-08" - ], - "HHSP39": [ - "IAC-01.2" - ], - "HML39": [ - "IAC-01.2" - ], - "HHSP49": [ - "IAC-05", - "NET-01" - ], - "HML49": [ - "IAC-05", - "NET-01" - ], - "HHSP04": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "PES-02" - ], - "HML04": [ - "IAC-07", - "IAC-07.1", - "IAC-07.2", - "PES-02" - ], - "HHSP40": [ - "IAC-08", - "IAC-20" - ], - "HHSP42": [ - "IAC-08", - "TDA-20" - ], - "HML40": [ - "IAC-08", - "IAC-20" - ], - "HML42": [ - "IAC-08", - "TDA-20" - ], - "HHSP38": [ - "IAC-15" - ], - "HML38": [ - "IAC-15" - ], - "HHSP41": [ - "IAC-16" - ], - "HML41": [ - "IAC-16" - ], - "HHSP10": [ - "IAC-20", - "PES-03.4" - ], - "HML10": [ - "IAC-20", - "PES-03.4" - ], - "HHSP07": [ - "IRO-02", - "IRO-04" - ], - "HML07": [ - "IRO-02", - "IRO-04" - ], - "HHSP68": [ - "IAO-01", - "IAO-02" - ], - "HML67": [ - "IAO-01", - "IAO-02" - ], - "HHSP15": [ - "MNT-01" - ], - "HML15": [ - "MNT-01" - ], - "HHSP43": [ - "NET-03.7", - "RSK-06.2", - "TDA-17" - ], - "HHSP55": [ - "NET-03.7", - "NET-06" - ], - "HML43": [ - "NET-03.7", - "RSK-06.2", - "TDA-17" - ], - "HML55": [ - "NET-03.7", - "NET-06" - ], - "HHSP47": [ - "PES-01" - ], - "HML47": [ - "PES-01" - ], - "HHSP13": [ - "PES-01.1" - ], - "HML13": [ - "PES-01.1" - ], - "HHSP48": [ - "PES-03", - "PES-04" - ], - "HML48": [ - "PES-03", - "PES-04" - ], - "HHSP66": [ - "PES-05" - ], - "HML65": [ - "PES-05" - ], - "HHSP31": [ - "PRM-04", - "PRM-05", - "TDA-02" - ], - "HML31": [ - "PRM-04", - "PRM-05", - "TDA-02" - ], - "HHSP30": [ - "RSK-01" - ], - "HML30": [ - "RSK-01" - ], - "HHSP32": [ - "RSK-04" - ], - "HML32": [ - "RSK-04" - ], - "HHSP26": [ - "RSK-06.2", - "VPM-01", - "VPM-06" - ], - "HML26": [ - "RSK-06.2", - "VPM-01", - "VPM-06" - ], - "HHSP22": [ - "SAT-01" - ], - "HML22": [ - "SAT-01" - ], - "HHSP50": [ - "TDA-01", - "TDA-01.1", - "TDA-06" - ], - "HML50": [ - "TDA-01", - "TDA-01.1", - "TDA-06" - ], - "HHSP58": [ - "TDA-08" - ], - "HML58": [ - "TDA-08" - ], - "HHSP25": [ - "TPM-01", - "TPM-04.1", - "TPM-08" - ], - "HML25": [ - "TPM-01", - "TPM-04.1", - "TPM-08" - ], - "HHSP09": [ - "TPM-05" - ], - "HHSP36": [ - "TPM-05" - ], - "HML09": [ - "TPM-05" - ], - "HML36": [ - "TPM-05" - ], - "HHSP19": [ - "VPM-01", - "VPM-02", - "VPM-05" - ], - "HML19": [ - "VPM-01", - "VPM-02", - "VPM-05" - ], - "HHSP59": [ - "VPM-02", - "VPM-06" - ], - "HML59": [ - "VPM-02", - "VPM-06" - ], - "HHSP44": [ - "VPM-04.1" - ], - "HML44": [ - "VPM-04.1" - ] - } + "total_mappings": 0, + "mappings": {} } } \ No newline at end of file diff --git a/docs/api/crosswalks/apac-nzl-hisf-suppliers-2023.json b/docs/api/crosswalks/apac-nzl-hisf-suppliers-2023.json index 5eeff2dd..5e8f3d0f 100644 --- a/docs/api/crosswalks/apac-nzl-hisf-suppliers-2023.json +++ b/docs/api/crosswalks/apac-nzl-hisf-suppliers-2023.json @@ -1,6 +1,6 @@ { "framework_id": "apac-nzl-hisf-suppliers-2023", - "display_name": "New Zealand - HISF Guidance for Suppliers (2023)", + "display_name": "New Zealand - HISO 10029:2024 NZ Health Information Security Framework Guidance for Suppliers", "scf_to_framework": { "total_mappings": 101, "mappings": { diff --git a/docs/api/crosswalks/apac-nzl-ism-3-9.json b/docs/api/crosswalks/apac-nzl-ism-3-9.json index a6adedb4..e09d63e0 100644 --- a/docs/api/crosswalks/apac-nzl-ism-3-9.json +++ b/docs/api/crosswalks/apac-nzl-ism-3-9.json @@ -1,15 +1,20 @@ { "framework_id": "apac-nzl-ism-3-9", - "display_name": "New Zealand - Information Security Manual (ISM) (v3.9)", + "display_name": "New Zealand - Information Security Manual (ISM) v3.9", "scf_to_framework": { - "total_mappings": 291, + "total_mappings": 289, "mappings": { "GOV-01": [ - "5.1.14.C.01" + "5.1.14.C.01", + "5.1.16.C.01", + "16.1.24.C.01" ], "GOV-01.1": [ "3.2.9.C.01" ], + "GOV-01.4": [ + "5.1.16.C.02" + ], "GOV-02": [ "5.1.7.C.01", "5.1.14.C.01", @@ -21,7 +26,18 @@ "5.1.20.C.01", "5.1.20.C.02", "5.2.3.C.01", - "5.2.3.C.02" + "5.2.3.C.02", + "11.1.15.C.01", + "11.1.15.C.02", + "11.3.5.C.01", + "11.4.9.C.01", + "11.5.13.C.01", + "11.8.3.C.01", + "16.1.24.C.01", + "20.2.15.C.04", + "21.1.6.C.01", + "22.1.10.C.01", + "22.1.22.C.01" ], "GOV-03": [ "5.1.14.C.01", @@ -58,6 +74,9 @@ "3.2.18.C.01", "3.2.19.C.01" ], + "GOV-10": [ + "20.2.16.C.03" + ], "GOV-15": [ "3.2.10.C.04", "3.4.11.C.01" @@ -76,18 +95,26 @@ "23.2.18.C.01" ], "AST-01": [ - "8.4.9.C.01" + "8.4.9.C.01", + "20.2.15.C.04", + "20.2.15.C.07" ], "AST-02": [ "8.4.8.C.01", "8.4.9.C.01" ], + "AST-02.9": [ + "20.2.15.C.07" + ], "AST-04": [ "18.1.9.C.02", "18.1.11.C.01", "18.1.12.C.01", "18.1.12.C.02" ], + "AST-05": [ + "17.9.36.C.01" + ], "AST-08": [ "8.5.3.C.01", "8.5.3.C.02", @@ -100,8 +127,11 @@ ], "AST-09": [ "11.2.13.C.01", - "11.2.13.C.02", "11.7.35.C.01", + "11.8.10.C.03", + "11.8.10.C.05", + "11.8.12.C.01", + "11.8.12.C.02", "12.6.4.C.01", "12.6.4.C.02", "12.6.5.C.01", @@ -112,8 +142,8 @@ "12.6.8.C.01", "12.6.9.C.01", "12.6.10.C.01", - "13.4.19.C.02", "13.4.10.C.01", + "13.4.19.C.02", "13.5.24.C.01", "13.5.24.C.02", "13.5.24.C.03", @@ -134,88 +164,75 @@ "13.6.10.C.02", "13.6.10.C.03", "13.6.11.C.01", - "13.6.12.C.01" - ], - "AST-13": [ - "16.2.3.C.01", - "16.2.3.C.02" + "13.6.12.C.01", + "17.6.6.C.01" ], "AST-14.1": [ - "11.1.8.C.01", - "11.1.10.C.01", - "11.1.10.C.02", - "11.1.10.C.03", - "11.1.11.C.01", - "11.1.11.C.02", - "11.1.12.C.01", - "11.1.13.C.01", - "21.1.16.C.01", - "21.1.16.C.02" + "11.1.19.C.03" ], "AST-14.2": [ - "11.1.9.C.01", - "11.1.9.C.02", - "11.1.9.C.03" + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03" ], "AST-16": [ "8.1.12.C.01", "21.1.12.C.01", - "21.4.7.C.01", - "21.4.7.C.02", - "21.4.8.C.01", - "21.4.8.C.02", - "21.4.9.C.01", - "21.4.10.C.01", - "21.4.10.C.02", - "21.4.10.C.03", - "21.4.10.C.04", - "21.4.10.C.05", - "21.4.10.C.06", - "21.4.10.C.07", - "21.4.10.C.08", - "21.4.10.C.09", - "21.4.10.C.10", - "21.4.10.C.11", - "21.4.10.C.12", - "21.4.10.C.13", - "21.4.10.C.14", - "21.4.10.C.15", - "21.4.10.C.16", - "21.4.11.C.01", - "21.4.11.C.02", - "21.4.11.C.03", - "21.4.11.C.04", - "21.4.11.C.05", - "21.4.11.C.06", - "21.4.11.C.07", - "21.4.11.C.08", - "21.4.11.C.09", - "21.4.11.C.10", - "21.4.11.C.11", - "21.4.11.C.12", - "21.4.11.C.13", - "21.4.11.C.14", - "21.4.11.C.15", - "21.4.11.C.16", - "21.4.11.C.17", - "21.4.11.C.18", - "21.4.11.C.19", - "21.4.11.C.20", - "21.4.13.C.01", - "21.4.13.C.02", - "21.4.13.C.03", - "21.4.13.C.04", - "21.4.13.C.05", - "21.4.13.C.06", - "21.4.13.C.07", - "21.4.13.C.08", - "21.4.13.C.09", - "21.4.13.C.10", - "21.4.13.C.11", - "21.4.14.C.01", - "21.4.14.C.02", - "21.4.14.C.03", - "21.4.14.C.04" + "22.4.7.C.02", + "22.4.8.C.01", + "22.4.8.C.02", + "22.4.10.C.01", + "22.4.10.C.02", + "22.4.10.C.03", + "22.4.10.C.04", + "22.4.10.C.05", + "22.4.10.C.06", + "22.4.10.C.07", + "22.4.10.C.08", + "22.4.10.C.09", + "22.4.10.C.10", + "22.4.10.C.11", + "22.4.10.C.12", + "22.4.10.C.13", + "22.4.10.C.14", + "22.4.10.C.15", + "22.4.10.C.16", + "22.4.11.C.01", + "22.4.11.C.02", + "22.4.11.C.03", + "22.4.11.C.04", + "22.4.11.C.05", + "22.4.11.C.06", + "22.4.11.C.07", + "22.4.11.C.08", + "22.4.11.C.09", + "22.4.11.C.10", + "22.4.11.C.11", + "22.4.11.C.12", + "22.4.11.C.13", + "22.4.11.C.14", + "22.4.11.C.15", + "22.4.11.C.16", + "22.4.11.C.17", + "22.4.11.C.18", + "22.4.11.C.19", + "22.4.11.C.20", + "22.4.12.C.01", + "22.4.13.C.01", + "22.4.13.C.02", + "22.4.13.C.03", + "22.4.13.C.04", + "22.4.13.C.05", + "22.4.13.C.06", + "22.4.13.C.07", + "22.4.13.C.08", + "22.4.13.C.09", + "22.4.13.C.10", + "22.4.13.C.11", + "22.4.14.C.01", + "22.4.14.C.02", + "22.4.14.C.03", + "22.4.14.C.04" ], "AST-19": [ "11.3.5.C.01", @@ -232,7 +249,10 @@ "11.3.12.C.03", "11.3.13.C.01", "11.3.13.C.02", - "11.3.13.C.03" + "11.3.13.C.03", + "11.8.3.C.01", + "11.8.4.C.01", + "11.8.5.C.01" ], "AST-20": [ "18.3.14.C.01", @@ -260,25 +280,14 @@ "18.3.17.C.01" ], "AST-23": [ - "11.2.3.C.01", - "11.2.4.C.01", - "11.2.4.C.02", - "11.2.5.C.01", - "11.2.6.C.01", - "11.2.7.C.01", - "11.2.7.C.02", - "11.2.8.C.01", - "11.2.9.C.01", - "11.2.10.C.01", "11.2.11.C.01", "11.2.11.C.02", - "11.2.11.C.03", - "11.2.11.C.04", - "11.2.11.C.05", "11.2.12.C.01", - "11.2.12.C.02", "11.2.13.C.01", - "11.2.13.C.02" + "11.8.3.C.01", + "11.8.7.C.01", + "11.8.8.C.01", + "11.8.13.C.01" ], "AST-26": [ "3.4.10.C.01", @@ -299,29 +308,7 @@ "5.5.3.C.01", "5.5.4.C.01", "5.5.5.C.01", - "5.5.6.C.01", - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" - ], - "AST-28.1": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" + "5.5.6.C.01" ], "AST-29": [ "11.6.59.C.01", @@ -347,10 +334,7 @@ "11.6.68.C.01", "11.6.69.C.01", "11.6.70.C.01", - "11.6.71.C.01", - "11.6.72.C.01", - "11.6.72.C.02", - "11.6.72.C.03" + "11.6.71.C.01" ], "AST-29.1": [ "11.7.29.C.01", @@ -384,12 +368,15 @@ "13.1.13.C.02", "13.1.13.C.03", "13.1.13.C.04", - "13.1.14.C.01" + "13.1.14.C.01", + "20.2.15.C.03", + "20.2.15.C.06" ], "BCD-01": [ "6.4.5.C.01", "6.4.7.C.01", "6.4.8.C.01", + "20.1.26.C.01", "23.4.12.C.01", "23.4.12.C.02" ], @@ -410,32 +397,23 @@ "6.3.7.C.02", "6.3.7.C.03" ], + "CHG-02.1": [ + "20.2.15.C.02", + "20.2.15.C.05" + ], "CHG-02.2": [ "6.3.8.C.01" ], "CLD-01": [ + "2.3.28.C.01", + "20.1.20.C.01", + "20.1.20.C.02", + "20.1.20.C.03", + "20.1.20.C.04", "22.1.20.C.01", "22.1.20.C.02", "22.1.20.C.03", - "22.1.20.C.04", - "22.1.20.C.05", "22.1.21.C.01", - "22.1.21.C.02", - "22.1.21.C.03", - "22.1.21.C.04", - "22.1.21.C.05", - "22.1.21.C.06", - "22.1.21.C.07", - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04", - "22.1.25.C.01", - "22.1.25.C.02", - "22.1.26.C.01", - "22.1.26.C.02", - "22.1.26.C.03", - "22.1.27.C.01", "23.1.54.C.01", "23.1.54.C.02", "23.2.19.C.01" @@ -450,22 +428,24 @@ "23.5.12.C.02" ], "CLD-01.2": [ + "20.1.26.C.02", + "20.1.26.C.03", "23.4.13.C.01", "23.4.13.C.02", "23.4.13.C.03" ], "CLD-02": [ - "22.1.23.C.01", - "22.1.23.C.02", - "22.1.23.C.03", + "2.3.28.C.01", + "20.1.24.C.02", + "20.1.24.C.03", + "20.1.24.C.04", + "20.2.12.C.01", + "20.2.12.C.02", "23.1.54.C.01", "23.1.54.C.02", "23.1.56.C.01", "23.2.20.C.01" ], - "CLD-03": [ - "22.1.24.C.02" - ], "CLD-06": [ "23.1.55.C.01", "23.1.55.C.02", @@ -473,6 +453,7 @@ "23.2.20.C.01" ], "CLD-06.1": [ + "20.1.21.C.03", "23.1.55.C.01", "23.1.55.C.02", "23.1.55.C.03" @@ -487,32 +468,26 @@ "23.5.12.C.02" ], "CLD-09": [ + "20.1.22.C.01", + "20.1.22.C.02", + "20.1.22.C.03", + "20.1.22.C.04", + "20.1.22.C.05", + "20.1.22.C.06", "22.1.22.C.01", "22.1.22.C.02", - "22.1.22.C.03", - "22.1.22.C.04", - "22.1.22.C.05", - "22.1.22.C.06", "23.4.11.C.01", "23.4.11.C.02" ], - "CLD-10": [ - "2.3.23.C.01", - "22.1.22.C.04", - "22.1.22.C.05" - ], - "CLD-11": [ - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04" - ], "CPL-01": [ "1.1.64.C.01", "1.1.65.C.01", "1.1.66.C.01", "1.1.66.C.02", - "1.1.67.C.01" + "1.1.67.C.01", + "1.2.15.C.01", + "1.2.15.C.02", + "17.9.37.C.01" ], "CPL-01.1": [ "1.1.68.C.01", @@ -523,6 +498,11 @@ "6.1.7.C.01", "23.2.18.C.01" ], + "CPL-02.2": [ + "17.9.33.C.01", + "17.9.33.C.02", + "17.9.33.C.03" + ], "CPL-03": [ "4.3.16.C.01", "6.1.7.C.01", @@ -543,23 +523,66 @@ "12.2.5.C.02", "12.2.6.C.01", "12.2.6.C.02", + "17.9.38.C.03", "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", - "18.1.10.C.04" + "18.1.10.C.04", + "20.2.14.C.02" ], "CFG-01.1": [ "4.3.19.C.01" ], "CFG-02": [ + "11.1.16.C.01", + "11.1.16.C.02", + "11.1.17.C.01", + "11.1.17.C.03", + "11.8.6.C.01", + "11.8.6.C.02", "14.1.8.C.01", "14.1.9.C.01", "14.1.9.C.02", "14.1.10.C.01", "14.1.10.C.02", "14.3.7.C.01", + "15.2.41.C.01", + "15.2.41.C.02", + "15.2.42.C.01", + "15.2.43.C.01", + "15.2.44.C.01", + "15.2.46.C.01", + "15.2.46.C.03", + "15.2.47.C.01", + "15.2.47.C.02", + "15.2.48.C.01", + "15.2.48.C.02", + "15.2.48.C.03", + "15.2.49.C.01", + "15.2.49.C.02", + "15.2.49.C.03", + "15.2.50.C.01", + "15.2.50.C.02", + "15.2.50.C.03", + "15.2.50.C.04", + "16.1.31.C.03", + "16.1.31.C.04", + "16.1.31.C.05", + "16.7.42.C.01", + "20.2.14.C.05", + "20.2.14.C.07", + "22.1.16.C.01", + "22.1.16.C.02", + "22.1.17.C.01", + "22.1.17.C.02", + "22.1.17.C.03", + "22.1.19.C.01", + "22.1.19.C.02", "23.2.21.C.01" ], + "CFG-02.1": [ + "15.2.45.C.01" + ], "CFG-02.4": [ "18.1.10.C.01", "18.1.10.C.02", @@ -567,6 +590,7 @@ "18.1.10.C.04" ], "CFG-02.5": [ + "15.2.38.C.01", "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", @@ -579,10 +603,6 @@ "18.1.10.C.03", "18.1.10.C.04" ], - "CFG-02.9": [ - "16.1.50.C.01", - "16.1.50.C.02" - ], "CFG-03": [ "18.1.15.C.01", "18.1.15.C.02", @@ -602,7 +622,8 @@ "14.2.7.C.04", "14.2.7.C.05", "14.2.7.C.06", - "14.2.7.C.07" + "14.2.7.C.07", + "21.3.12.C.02" ], "CFG-03.4": [ "18.7.14.C.01", @@ -633,7 +654,12 @@ "18.4.12.C.01", "18.4.14.C.01" ], + "MON-01.2": [ + "16.6.15.C.01", + "16.6.15.C.02" + ], "MON-01.3": [ + "15.2.40.C.02", "16.6.10.C.01", "16.6.10.C.02", "18.4.8.C.01", @@ -698,6 +724,10 @@ "16.6.10.C.01", "16.6.10.C.02" ], + "MON-03.3": [ + "16.4.41.C.01", + "16.4.41.C.02" + ], "MON-03.7": [ "16.6.7.C.01", "16.6.9.C.01", @@ -722,6 +752,12 @@ "16.6.13.C.03", "16.6.13.C.04" ], + "MON-08.2": [ + "16.4.41.C.03" + ], + "MON-10": [ + "16.6.13.C.05" + ], "CRY-01": [ "8.4.13.C.01", "17.1.52.C.01", @@ -762,7 +798,6 @@ "17.4.16.C.01", "17.4.16.C.02", "17.5.6.C.01", - "17.6.6.C.01", "17.6.7.C.01", "17.7.6.C.01", "17.8.10.C.01", @@ -774,23 +809,17 @@ "17.8.15.C.01", "17.8.16.C.01", "17.8.17.C.01", - "17.9.24.C.01", - "17.9.24.C.02", - "17.9.24.C.03", - "17.9.25.C.01", - "17.9.26.C.01", - "17.9.26.C.02", - "17.9.27.C.01", - "17.9.27.C.02", - "17.9.27.C.03", - "17.9.28.C.01", - "17.9.29.C.01", "17.9.30.C.01", "17.9.30.C.02", + "17.9.30.C.03", "17.9.31.C.01", "17.9.32.C.01", "17.9.32.C.02", - "17.9.32.C.03" + "17.9.38.C.01", + "17.9.38.C.02" + ], + "CRY-01.5": [ + "17.9.34.C.01" ], "CRY-05": [ "8.4.13.C.01" @@ -800,6 +829,7 @@ ], "CRY-07": [ "18.2.9.C.01", + "18.2.9.C.02", "18.2.10.C.01", "18.2.10.C.02", "18.2.11.C.01", @@ -828,15 +858,11 @@ ], "CRY-08": [ "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03", "23.3.21.C.01", "23.3.22.C.01" ], "CRY-08.1": [ - "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03" + "17.1.51.C.01" ], "CRY-09": [ "17.1.51.C.01", @@ -849,8 +875,7 @@ "23.4.9.C.03" ], "CRY-09.3": [ - "7.2.24.C.01", - "7.2.25.C.01" + "7.2.24.C.01" ], "CRY-09.7": [ "23.4.9.C.02", @@ -880,6 +905,8 @@ "13.2.7.C.01" ], "DCH-01.2": [ + "16.2.7.C.01", + "16.2.7.C.02", "18.6.8.C.01" ], "DCH-02": [ @@ -909,8 +936,11 @@ "13.2.12.C.04", "13.2.13.C.01", "13.2.14.C.01", - "13.2.14.C.02", - "21.1.21.C.01" + "13.2.14.C.02" + ], + "DCH-04.1": [ + "15.2.39.C.02", + "15.2.39.C.03" ], "DCH-06": [ "8.4.10.C.01", @@ -945,6 +975,7 @@ "13.5.30.C.01" ], "DCH-09": [ + "12.6.5.C.05", "13.4.9.C.01", "13.4.11.C.01", "13.4.12.C.01", @@ -955,12 +986,11 @@ "13.4.13.C.05", "13.4.14.C.01", "13.4.15.C.01", - "12.6.5.C.05", - "13.4.19.C.02", "13.4.16.C.01", "13.4.17.C.01", "13.4.18.C.01", "13.4.19.C.01", + "13.4.19.C.02", "13.4.20.C.01", "13.4.20.C.02", "13.4.20.C.03", @@ -995,6 +1025,8 @@ "13.3.10.C.01" ], "DCH-13.2": [ + "11.8.11.C.01", + "11.8.11.C-02", "13.3.7.C.01", "13.3.7.C.02", "13.3.8.C.01", @@ -1003,70 +1035,13 @@ "13.3.9.C.02", "13.3.10.C.01" ], - "DCH-14": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" - ], - "DCH-14.2": [ - "20.1.8.C.01", - "20.2.4.C.01" - ], "DCH-14.3": [ "16.2.5.C.01", "16.2.6.C.01" ], - "DCH-16": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" - ], - "DCH-17": [ - "20.1.11.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04" - ], "END-04": [ - "14.1.9.C.02" + "14.1.9.C.02", + "21.3.10.C.01" ], "END-06": [ "14.1.12.C.01", @@ -1077,12 +1052,7 @@ "18.4.13.C.01" ], "END-08": [ - "15.2.21.C.01", - "15.2.23.C.01", - "15.2.23.C.02", - "15.2.23.C.03", - "15.2.24.C.01", - "15.2.24.C.02" + "15.2.37.C.01" ], "HRS-01": [ "9.2.10.C.01", @@ -1093,7 +1063,6 @@ ], "HRS-02": [ "9.2.10.C.01", - "9.2.10.C.02", "9.2.11.C.01", "9.2.11.C.02" ], @@ -1131,7 +1100,8 @@ "3.3.14.C.03", "3.3.15.C.01", "3.4.10.C.01", - "3.4.10.C.02" + "3.4.10.C.02", + "17.9.35.C.01" ], "HRS-03.2": [ "5.1.14.C.01" @@ -1141,7 +1111,6 @@ ], "HRS-04.3": [ "9.2.10.C.01", - "9.2.10.C.02", "9.2.11.C.01", "9.2.11.C.02", "9.2.15.C.01", @@ -1167,7 +1136,9 @@ "9.3.7.C.04", "9.3.8.C.01", "9.3.8.C.02", - "9.3.8.C.03" + "9.3.8.C.03", + "21.1.6.C.02", + "21.2.3.C.01" ], "HRS-05.1": [ "3.5.4.C.01", @@ -1185,8 +1156,7 @@ "9.3.8.C.03", "14.3.5.C.01", "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "16.4.38.C.02" ], "HRS-05.2": [ "9.3.7.C.01", @@ -1203,9 +1173,23 @@ "9.3.5.C.02", "9.3.9.C.01", "9.3.10.C.01", - "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "11.1.15.C.01", + "11.1.16.C.03", + "11.1.16.C.04", + "11.1.17.C.02", + "11.1.18.C.01", + "11.1.18.C.02", + "11.1.19.C.02", + "11.2.14.C.01", + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03", + "11.8.4.C.01", + "11.8.4.C.02", + "11.8.5.C.01", + "11.8.6.C.01", + "11.8.6.C.02", + "15.1.7.C.01" ], "HRS-05.5": [ "8.1.12.C.01", @@ -1224,49 +1208,57 @@ "11.5.16.C.02", "11.5.16.C.03", "21.1.11.C.01", - "21.1.11.C.02", - "21.1.22.C.01", - "21.1.22.C.02" + "22.1.10.C.02", + "22.1.13.C.01", + "22.1.13.C.02", + "22.1.13.C.03", + "22.1.13.C.04", + "22.1.13.C.05", + "22.2.5.C.01", + "22.2.6.C.01", + "22.2.7.C.01", + "22.2.7.C.02", + "22.3.5.C.01", + "22.3.6.C.01", + "22.4.9.C.01" ], "HRS-06.1": [ "9.1.8.C.01" ], "IAC-01": [ - "16.1.31.C.01" + "16.1.31.C.01", + "16.4.39.C.01", + "20.2.16.C.02" + ], + "IAC-01.2": [ + "16.1.26.C.01" ], "IAC-02": [ "16.1.32.C.01" ], "IAC-02.1": [ "16.1.33.C.01", - "16.1.33.C.02", "16.1.34.C.01" ], "IAC-06": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01", + "16.1.29.C.02", + "16.4.37.C.02", + "16.7.42.C.01", + "16.7.42.C.04", + "16.7.42.C.05", + "16.7.42.C.06", + "16.7.42.C.07", + "16.7.43.C.01", + "16.7.44.C.01", "23.3.19.C.01", "23.3.19.C.02" ], "IAC-06.1": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "16.7.42.C.02", + "16.7.42.C.03" ], "IAC-06.2": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" - ], - "IAC-06.3": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "16.7.42.C.03" ], "IAC-07": [ "23.3.20.C.01" @@ -1281,15 +1273,17 @@ "14.3.13.C.01", "14.3.13.C.02", "14.3.13.C.03", + "16.1.36.C.02", + "16.1.36.C.03", "16.1.40.C.01", - "16.1.40.C.02", "16.1.41.C.01", "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04", "16.1.42.C.01" ], "IAC-10.1": [ + "16.1.29.C.01", + "16.1.31.C.02", + "16.1.31.C.07", "16.1.35.C.01", "16.1.35.C.02", "16.1.42.C.01", @@ -1297,11 +1291,10 @@ ], "IAC-10.4": [ "16.1.41.C.01", - "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04" + "16.1.41.C.02" ], "IAC-10.5": [ + "16.1.34.C.02", "16.1.36.C.01", "16.1.37.C.01", "16.1.38.C.01" @@ -1312,7 +1305,8 @@ "IAC-10.11": [ "14.3.13.C.01", "14.3.13.C.02", - "14.3.13.C.03" + "14.3.13.C.03", + "16.1.37.C.02" ], "IAC-12.1": [ "17.10.12.C.01", @@ -1321,62 +1315,49 @@ "17.10.12.C.04" ], "IAC-15.5": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.28.C.01", "16.1.33.C.01", - "16.1.33.C.02", "16.1.34.C.01" ], "IAC-16": [ "16.3.5.C.01", - "16.3.5.C.02", "16.3.6.C.01", "16.3.6.C.02", "16.3.7.C.01", - "16.4.30.C.01", - "16.4.30.C.02", - "16.4.30.C.03", - "16.4.31.C.01", - "16.4.31.C.02", - "16.4.32.C.01", - "16.4.32.C.02", - "16.4.33.C.01", - "16.4.34.C.01", - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03", "16.4.36.C.01", - "16.4.37.C.01" + "16.4.36.C.02", + "16.4.36.C.03", + "16.4.37.C.01", + "16.4.37.C.03", + "16.4.38.C.01" ], "IAC-16.1": [ - "16.4.34.C.01" + "16.4.40.C.01" ], "IAC-16.2": [ "23.3.18.C.01" ], - "IAC-17": [ - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03" - ], "IAC-18": [ - "16.4.37.C.01" + "16.4.37.C.01", + "16.4.38.C.02" + ], + "IAC-19": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.27.C.03" ], "IAC-21": [ "16.2.4.C.01", - "16.4.31.C.01", - "16.4.31.C.02", "23.4.10.C.01" ], - "IAC-22": [ - "16.1.46.C.01", - "16.1.46.C.02" - ], - "IAC-24": [ - "16.1.45.C.01", - "16.1.45.C.02" - ], "IAC-25": [ "16.1.44.C.01" ], + "IAC-29": [ + "16.1.31.C.06" + ], "IRO-01": [ "7.1.7.C.01", "7.1.7.C.02", @@ -1385,20 +1366,16 @@ ], "IRO-02": [ "5.7.4.C.01", - "7.2.17.C.01", - "7.2.17.C.02", "7.2.18.C.01", + "7.2.18.C.02", "7.2.19.C.01", "7.3.9.C.01", - "7.3.10.C.01" + "7.3.10.C.01", + "20.1.25.C.02" ], "IRO-02.5": [ "7.3.10.C.01" ], - "IRO-03": [ - "7.2.17.C.01", - "7.2.17.C.02" - ], "IRO-04": [ "5.1.12.C.01", "5.1.12.C.02", @@ -1408,7 +1385,8 @@ "7.3.5.C.01", "7.3.9.C.01", "7.3.10.C.01", - "16.1.47.C.01" + "16.4.39.C.02", + "16.4.42.C.01" ], "IRO-07": [ "7.2.18.C.01" @@ -1423,7 +1401,10 @@ ], "IRO-10": [ "7.2.18.C.01", + "7.2.18.C.02", "7.2.20.C.01", + "7.2.20.C.02", + "7.2.20.C.03", "7.2.21.C.01", "7.2.23.C.01" ], @@ -1460,12 +1441,6 @@ "7.3.8.C.01", "7.3.8.C.02" ], - "IRO-14": [ - "2.1.10.C.01" - ], - "IRO-15": [ - "15.2.21.C.01" - ], "IAO-01": [ "2.2.5.C.01", "4.4.4.C.01", @@ -1492,14 +1467,24 @@ "IAO-01.1": [ "5.8.61.C.01", "5.8.61.C.02", - "5.8.61.C.03" + "5.8.61.C.03", + "20.1.21.C.02", + "23.5.10.C.01" ], "IAO-02": [ "4.2.10.C.01", "4.3.20.C.01", "4.3.20.C.02", "4.3.20.C.03", - "6.3.8.C.01" + "6.3.8.C.01", + "11.1.19.C.01", + "16.1.30.C.01", + "16.7.41.C.01", + "20.1.21.C.01", + "20.1.21.C.07", + "20.1.22.C.03", + "20.1.23.C.01", + "23.5.10.C.01" ], "IAO-02.1": [ "4.3.16.C.01" @@ -1507,7 +1492,9 @@ "IAO-02.2": [ "4.3.20.C.01", "4.3.20.C.02", - "4.3.20.C.03" + "4.3.20.C.03", + "20.2.13.C.01", + "20.2.13.C.02" ], "IAO-02.3": [ "4.3.16.C.01", @@ -1556,6 +1543,10 @@ "4.5.18.C.01", "4.5.18.C.02", "4.5.18.C.03", + "20.1.21.C.04", + "20.1.22.C.01", + "20.1.22.C.03", + "20.1.22.C.05", "23.2.16.C.03", "23.2.16.C.04" ], @@ -1566,11 +1557,16 @@ "12.5.6.C.02" ], "MNT-02": [ + "11.8.10.C.01", + "11.8.10.C.04", "12.5.3.C.01", "12.5.3.C.02", "12.5.6.C.01", "12.5.6.C.02" ], + "MNT-04.3": [ + "11.8.10.C.02" + ], "MNT-06.1": [ "12.5.4.C.01", "12.5.4.C.02", @@ -1586,34 +1582,18 @@ "MDM-01": [ "21.1.10.C.01", "21.1.10.C.02", - "21.1.10.C.03", "21.1.11.C.01", - "21.1.11.C.02", "21.1.12.C.01", - "21.1.14.C.01", - "21.1.14.C.02", - "21.1.15.C.01", - "21.1.16.C.01", - "21.1.16.C.02", - "21.1.17.C.01", - "21.1.17.C.02", - "21.1.17.C.03", - "21.1.18.C.01", - "21.1.18.C.02", - "21.1.19.C.01", - "21.1.19.C.02" + "22.1.10.C.01", + "22.1.10.C.03", + "22.1.12.C.01", + "22.1.15.C.01", + "22.1.18.C.02" ], "MDM-03": [ "21.1.13.C.01", - "21.1.13.C.02", - "21.1.13.C.03", - "21.1.13.C.04", - "21.1.13.C.05" - ], - "MDM-05": [ - "21.1.20.C.01", - "21.1.20.C.02", - "21.1.20.C.03" + "22.1.14.C.01", + "22.1.14.C.02" ], "MDM-06": [ "21.1.12.C.01" @@ -1645,7 +1625,9 @@ ], "NET-01.1": [ "2.3.26.C.01", - "2.3.26.C.02" + "2.3.26.C.02", + "16.1.25.C.01", + "16.5.12.C.02" ], "NET-02.1": [ "18.3.18.C.01", @@ -1663,7 +1645,13 @@ "19.2.18.C.01", "19.2.19.C.01", "19.2.19.C.02", - "19.2.20.C.01" + "19.2.20.C.01", + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.14.C.04", + "20.3.9.C.02", + "20.3.9.C.04", + "21.1.8.C.01" ], "NET-03": [ "19.1.10.C.01", @@ -1739,7 +1727,10 @@ "19.5.28.C.05", "19.5.28.C.06", "19.5.28.C.07", - "19.5.29.C.01" + "19.5.29.C.01", + "21.3.5.C.01", + "21.3.5.C.02", + "21.3.6.C.01" ], "NET-03.8": [ "14.1.11.C.01" @@ -1760,40 +1751,14 @@ "14.1.13.C.03" ], "NET-06.2": [ - "22.3.9.C.01", - "22.3.9.C.02", - "22.3.9.C.03", - "22.3.9.C.04", - "22.3.10.C.01", - "22.3.11.C.01", - "22.3.11.C.02" + "20.3.9.C.02", + "20.3.9.C.03", + "20.3.9.C.04" ], "NET-08.1": [ "19.1.14.C.01", "19.1.14.C.02" ], - "NET-08.2": [ - "21.4.12.C.01", - "21.4.12.C.02", - "21.4.12.C.03" - ], - "NET-10": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" - ], - "NET-10.1": [ - "15.2.22.C.01" - ], - "NET-10.3": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" - ], "NET-13": [ "15.1.7.C.01", "15.1.8.C.01", @@ -1815,25 +1780,6 @@ "15.1.19.C.01", "15.1.19.C.02", "15.1.20.C.01", - "15.2.25.C.01", - "15.2.25.C.02", - "15.2.26.C.01", - "15.2.27.C.01", - "15.2.28.C.01", - "15.2.29.C.01", - "15.2.30.C.01", - "15.2.30.C.02", - "15.2.30.C.03", - "15.2.31.C.01", - "15.2.31.C.02", - "15.2.32.C.01", - "15.2.32.C.02", - "15.2.32.C.03", - "15.2.33.C.01", - "15.2.33.C.02", - "15.2.33.C.03", - "15.2.33.C.04", - "16.7.33.C.01", "17.6.6.C.01", "17.6.7.C.01" ], @@ -1858,13 +1804,11 @@ ], "NET-14.5": [ "21.2.4.C.01", - "21.2.4.C.02", "21.2.5.C.01", "21.2.6.C.01", "21.2.7.C.01", - "21.2.7.C.02", - "21.3.5.C.01", - "21.3.6.C.01" + "22.2.4.C.01", + "22.2.4.C.02" ], "NET-15": [ "18.2.5.C.01", @@ -1902,6 +1846,8 @@ "18.2.17.C.01", "18.2.18.C.01", "18.2.19.C.01", + "18.2.19.C.02", + "18.2.19.C.03", "18.2.20.C.01", "18.2.20.C.02", "18.2.20.C.03", @@ -1912,13 +1858,17 @@ "18.2.24.C.01", "18.2.25.C.01" ], - "NET-15.2": [ - "21.1.16.C.01", - "21.1.16.C.02" - ], "NET-15.4": [ "18.2.33.C.01" ], + "NET-15.5": [ + "22.4.12.C.02", + "22.4.12.C.03" + ], + "NET-17": [ + "15.2.39.C.01", + "15.2.40.C.01" + ], "NET-18": [ "9.3.6.C.01", "14.3.6.C.01", @@ -1931,41 +1881,35 @@ "14.3.11.C.01", "14.3.11.C.02", "14.3.12.C.01", - "20.3.4.C.01", - "20.3.4.C.02", - "20.3.5.C.01", - "20.3.5.C.02", - "20.3.6.C.01", - "20.3.7.C.01", - "20.3.7.C.02", - "20.3.8.C.01", "20.3.9.C.01", "20.3.10.C.01", "20.3.11.C.01", "20.3.11.C.02", - "20.3.11.C.03", - "20.3.12.C.01", - "20.3.12.C.02", - "20.3.13.C.01", - "20.3.13.C.02", - "20.3.14.C.01", - "20.3.15.C.01", - "20.3.15.C.02", - "20.3.16.C.01" + "21.3.7.C.01", + "21.3.7.C.02", + "21.3.14.C.01" ], "NET-18.1": [ "14.3.6.C.01", "14.3.6.C.02", - "14.3.6.C.03" + "14.3.6.C.03", + "15.2.46.C.02" ], "NET-18.2": [ "14.3.8.C.01", - "14.3.9.C.01", - "20.3.14.C.01" + "14.3.9.C.01" + ], + "NET-20.4": [ + "15.2.36.C.01", + "15.2.36.C.02", + "15.2.36.C.03", + "15.2.36.C.04", + "15.2.36.C.05" ], "PES-01": [ "5.7.4.C.01", - "8.1.10.C.01" + "8.1.10.C.01", + "20.2.16.C.01" ], "PES-01.1": [ "8.2.7.C.01" @@ -1990,6 +1934,9 @@ "8.2.6.C.01", "8.2.6.C.02" ], + "PES-04.1": [ + "17.9.36.C.02" + ], "PES-04.2": [ "8.1.12.C.01", "8.1.13.C.01", @@ -2121,6 +2068,9 @@ "10.6.30.C.01", "10.6.31.C.01" ], + "PES-12.2": [ + "11.8.9.C.01" + ], "PES-13": [ "10.7.6.C.01", "10.7.6.C.02", @@ -2129,36 +2079,6 @@ "10.7.8.C.01", "10.7.9.C.01" ], - "PRI-07": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" - ], "PRM-01": [ "3.2.15.C.01" ], @@ -2214,11 +2134,16 @@ "2.3.27.C.01", "2.3.27.C.02", "5.9.23.C.01", + "22.4.7.C.01", "23.2.16.C.02" ], "RSK-06.2": [ + "11.1.18.C.03", "12.4.5.C.01" ], + "RSK-08": [ + "16.1.30.C.01" + ], "RSK-09": [ "2.2.7.C.01", "12.7.14.C.01", @@ -2242,64 +2167,33 @@ "12.7.21.C.01" ], "SEA-01": [ - "1.2.13.C.01", - "1.2.13.C.02" + "2.3.28.C.01", + "20.2.14.C.01", + "20.2.14.C.03" ], "SEA-01.1": [ "4.3.19.C.01" ], - "SEA-02": [ - "1.2.13.C.01", - "1.2.13.C.02" + "SEA-01.4": [ + "1.2.15.C.01", + "2.3.28.C.01" ], - "SEA-03": [ - "1.2.13.C.01", - "1.2.13.C.02" + "SEA-01.5": [ + "2.3.28.C.01" ], "SEA-13.1": [ - "22.2.12.C.01", - "22.2.12.C.02", - "22.2.12.C.03", - "22.2.12.C.04", - "22.2.13.C.01", - "22.2.13.C.02", - "22.2.14.C.01", - "22.2.14.C.02", - "22.2.14.C.03", - "22.2.14.C.04", - "22.2.14.C.05", - "22.2.14.C.06", - "22.2.14.C.07", - "22.2.15.C.01", - "22.2.15.C.02", - "22.2.15.C.03", - "22.2.15.C.04", - "22.2.15.C.05", - "22.2.15.C.06", - "22.2.15.C.07", - "22.2.16.C.01", - "22.2.16.C.02", - "22.2.16.C.03" + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.12.C.03", + "20.2.12.C.04", + "20.2.14.C.01", + "20.2.14.C.03", + "20.2.14.C.04", + "20.2.14.C.07" ], "SEA-18": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], - "SEA-18.1": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], - "SEA-18.2": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], - "SEA-19": [ - "16.1.49.C.01", - "16.1.50.C.01", - "16.1.50.C.02" + "16.1.44.C.02", + "16.1.44.C.03" ], "OPS-01.1": [ "3.4.12.C.01", @@ -2309,7 +2203,11 @@ "5.5.3.C.01", "5.5.4.C.01", "5.5.5.C.01", - "5.5.6.C.01" + "5.5.6.C.01", + "16.1.24.C.01", + "20.2.15.C.01", + "21.1.7.C.01", + "21.1.7.C.02" ], "OPS-02": [ "5.1.15.C.01" @@ -2321,13 +2219,20 @@ "9.1.5.C.01", "9.1.5.C.02", "9.1.6.C.01", - "9.1.6.C.02" + "9.1.6.C.02", + "16.4.43.C.01", + "20.1.27.C.01" ], "SAT-03": [ + "2.1.47.C.01", "9.1.6.C.01", "9.1.6.C.02", "9.1.6.C.03" ], + "SAT-03.3": [ + "21.1.6.C.01", + "22.1.11.C.01" + ], "TDA-01.1": [ "12.1.31.C.01", "12.1.32.C.01", @@ -2376,6 +2281,9 @@ "TDA-07": [ "14.4.4.C.01" ], + "TDA-08": [ + "20.2.14.C.06" + ], "TDA-09.4": [ "14.5.6.C.01" ], @@ -2416,6 +2324,11 @@ ], "TPM-05": [ "2.3.30.C.01", + "20.1.20.C.05", + "20.1.23.C.02", + "20.1.23.C.03", + "20.1.24.C.01", + "20.1.25.C.01", "23.2.19.C.01" ], "TPM-05.1": [ @@ -2446,6 +2359,7 @@ "23.2.19.C.01" ], "VPM-05": [ + "22.1.18.C.01", "23.2.19.C.01" ], "VPM-06": [ @@ -2474,7 +2388,7 @@ } }, "framework_to_scf": { - "total_mappings": 1392, + "total_mappings": 1383, "mappings": { "5.1.14.C.01": [ "GOV-01", @@ -2482,17 +2396,24 @@ "GOV-03", "HRS-03.2" ], + "5.1.16.C.01": [ + "GOV-01", + "GOV-02" + ], + "16.1.24.C.01": [ + "GOV-01", + "GOV-02", + "OPS-01.1" + ], "3.2.9.C.01": [ "GOV-01.1", "GOV-04" ], - "5.1.7.C.01": [ - "GOV-02" - ], - "5.1.16.C.01": [ + "5.1.16.C.02": [ + "GOV-01.4", "GOV-02" ], - "5.1.16.C.02": [ + "5.1.7.C.01": [ "GOV-02" ], "5.1.17.C.01": [ @@ -2516,6 +2437,46 @@ "5.2.3.C.02": [ "GOV-02" ], + "11.1.15.C.01": [ + "GOV-02", + "HRS-05.3" + ], + "11.1.15.C.02": [ + "GOV-02" + ], + "11.3.5.C.01": [ + "GOV-02", + "AST-19" + ], + "11.4.9.C.01": [ + "GOV-02", + "HRS-05.5" + ], + "11.5.13.C.01": [ + "GOV-02", + "HRS-05.5" + ], + "11.8.3.C.01": [ + "GOV-02", + "AST-19", + "AST-23" + ], + "20.2.15.C.04": [ + "GOV-02", + "AST-01" + ], + "21.1.6.C.01": [ + "GOV-02", + "SAT-03.3" + ], + "22.1.10.C.01": [ + "GOV-02", + "MDM-01" + ], + "22.1.22.C.01": [ + "GOV-02", + "CLD-09" + ], "5.1.21.C.01": [ "GOV-03" ], @@ -2609,6 +2570,9 @@ "GOV-04", "PRM-08" ], + "20.2.16.C.03": [ + "GOV-10" + ], "3.4.11.C.01": [ "GOV-15", "GOV-15.2" @@ -2631,6 +2595,10 @@ "AST-01", "AST-02" ], + "20.2.15.C.07": [ + "AST-01", + "AST-02.9" + ], "8.4.8.C.01": [ "AST-02" ], @@ -2647,6 +2615,9 @@ "18.1.12.C.02": [ "AST-04" ], + "17.9.36.C.01": [ + "AST-05" + ], "8.5.3.C.01": [ "AST-08" ], @@ -2675,14 +2646,22 @@ "AST-09", "AST-23" ], - "11.2.13.C.02": [ - "AST-09", - "AST-23" - ], "11.7.35.C.01": [ "AST-09", "DCH-08" ], + "11.8.10.C.03": [ + "AST-09" + ], + "11.8.10.C.05": [ + "AST-09" + ], + "11.8.12.C.01": [ + "AST-09" + ], + "11.8.12.C.02": [ + "AST-09" + ], "12.6.4.C.01": [ "AST-09" ], @@ -2714,13 +2693,13 @@ "12.6.10.C.01": [ "AST-09" ], + "13.4.10.C.01": [ + "AST-09" + ], "13.4.19.C.02": [ "AST-09", "DCH-09" ], - "13.4.10.C.01": [ - "AST-09" - ], "13.5.24.C.01": [ "AST-09", "DCH-08" @@ -2795,54 +2774,24 @@ "13.6.12.C.01": [ "AST-09" ], - "16.2.3.C.01": [ - "AST-13" - ], - "16.2.3.C.02": [ - "AST-13" - ], - "11.1.8.C.01": [ - "AST-14.1" - ], - "11.1.10.C.01": [ - "AST-14.1" - ], - "11.1.10.C.02": [ - "AST-14.1" - ], - "11.1.10.C.03": [ - "AST-14.1" - ], - "11.1.11.C.01": [ - "AST-14.1" - ], - "11.1.11.C.02": [ - "AST-14.1" - ], - "11.1.12.C.01": [ - "AST-14.1" + "17.6.6.C.01": [ + "AST-09", + "NET-13" ], - "11.1.13.C.01": [ + "11.1.19.C.03": [ "AST-14.1" ], - "21.1.16.C.01": [ - "AST-14.1", - "MDM-01", - "NET-15.2" - ], - "21.1.16.C.02": [ - "AST-14.1", - "MDM-01", - "NET-15.2" - ], - "11.1.9.C.01": [ - "AST-14.2" + "11.2.15.C.01": [ + "AST-14.2", + "HRS-05.3" ], - "11.1.9.C.02": [ - "AST-14.2" + "11.2.15.C.02": [ + "AST-14.2", + "HRS-05.3" ], - "11.1.9.C.03": [ - "AST-14.2" + "11.2.15.C.03": [ + "AST-14.2", + "HRS-05.3" ], "8.1.12.C.01": [ "AST-16", @@ -2856,177 +2805,171 @@ "MDM-01", "MDM-06" ], - "21.4.7.C.01": [ - "AST-16" - ], - "21.4.7.C.02": [ + "22.4.7.C.02": [ "AST-16" ], - "21.4.8.C.01": [ + "22.4.8.C.01": [ "AST-16" ], - "21.4.8.C.02": [ + "22.4.8.C.02": [ "AST-16" ], - "21.4.9.C.01": [ + "22.4.10.C.01": [ "AST-16" ], - "21.4.10.C.01": [ + "22.4.10.C.02": [ "AST-16" ], - "21.4.10.C.02": [ + "22.4.10.C.03": [ "AST-16" ], - "21.4.10.C.03": [ + "22.4.10.C.04": [ "AST-16" ], - "21.4.10.C.04": [ + "22.4.10.C.05": [ "AST-16" ], - "21.4.10.C.05": [ + "22.4.10.C.06": [ "AST-16" ], - "21.4.10.C.06": [ + "22.4.10.C.07": [ "AST-16" ], - "21.4.10.C.07": [ + "22.4.10.C.08": [ "AST-16" ], - "21.4.10.C.08": [ + "22.4.10.C.09": [ "AST-16" ], - "21.4.10.C.09": [ + "22.4.10.C.10": [ "AST-16" ], - "21.4.10.C.10": [ + "22.4.10.C.11": [ "AST-16" ], - "21.4.10.C.11": [ + "22.4.10.C.12": [ "AST-16" ], - "21.4.10.C.12": [ + "22.4.10.C.13": [ "AST-16" ], - "21.4.10.C.13": [ + "22.4.10.C.14": [ "AST-16" ], - "21.4.10.C.14": [ + "22.4.10.C.15": [ "AST-16" ], - "21.4.10.C.15": [ + "22.4.10.C.16": [ "AST-16" ], - "21.4.10.C.16": [ + "22.4.11.C.01": [ "AST-16" ], - "21.4.11.C.01": [ + "22.4.11.C.02": [ "AST-16" ], - "21.4.11.C.02": [ + "22.4.11.C.03": [ "AST-16" ], - "21.4.11.C.03": [ + "22.4.11.C.04": [ "AST-16" ], - "21.4.11.C.04": [ + "22.4.11.C.05": [ "AST-16" ], - "21.4.11.C.05": [ + "22.4.11.C.06": [ "AST-16" ], - "21.4.11.C.06": [ + "22.4.11.C.07": [ "AST-16" ], - "21.4.11.C.07": [ + "22.4.11.C.08": [ "AST-16" ], - "21.4.11.C.08": [ + "22.4.11.C.09": [ "AST-16" ], - "21.4.11.C.09": [ + "22.4.11.C.10": [ "AST-16" ], - "21.4.11.C.10": [ + "22.4.11.C.11": [ "AST-16" ], - "21.4.11.C.11": [ + "22.4.11.C.12": [ "AST-16" ], - "21.4.11.C.12": [ + "22.4.11.C.13": [ "AST-16" ], - "21.4.11.C.13": [ + "22.4.11.C.14": [ "AST-16" ], - "21.4.11.C.14": [ + "22.4.11.C.15": [ "AST-16" ], - "21.4.11.C.15": [ + "22.4.11.C.16": [ "AST-16" ], - "21.4.11.C.16": [ + "22.4.11.C.17": [ "AST-16" ], - "21.4.11.C.17": [ + "22.4.11.C.18": [ "AST-16" ], - "21.4.11.C.18": [ + "22.4.11.C.19": [ "AST-16" ], - "21.4.11.C.19": [ + "22.4.11.C.20": [ "AST-16" ], - "21.4.11.C.20": [ + "22.4.12.C.01": [ "AST-16" ], - "21.4.13.C.01": [ + "22.4.13.C.01": [ "AST-16" ], - "21.4.13.C.02": [ + "22.4.13.C.02": [ "AST-16" ], - "21.4.13.C.03": [ + "22.4.13.C.03": [ "AST-16" ], - "21.4.13.C.04": [ + "22.4.13.C.04": [ "AST-16" ], - "21.4.13.C.05": [ + "22.4.13.C.05": [ "AST-16" ], - "21.4.13.C.06": [ + "22.4.13.C.06": [ "AST-16" ], - "21.4.13.C.07": [ + "22.4.13.C.07": [ "AST-16" ], - "21.4.13.C.08": [ + "22.4.13.C.08": [ "AST-16" ], - "21.4.13.C.09": [ + "22.4.13.C.09": [ "AST-16" ], - "21.4.13.C.10": [ + "22.4.13.C.10": [ "AST-16" ], - "21.4.13.C.11": [ + "22.4.13.C.11": [ "AST-16" ], - "21.4.14.C.01": [ + "22.4.14.C.01": [ "AST-16" ], - "21.4.14.C.02": [ + "22.4.14.C.02": [ "AST-16" ], - "21.4.14.C.03": [ + "22.4.14.C.03": [ "AST-16" ], - "21.4.14.C.04": [ + "22.4.14.C.04": [ "AST-16" ], - "11.3.5.C.01": [ - "AST-19" - ], "11.3.6.C.01": [ "AST-19" ], @@ -3072,6 +3015,14 @@ "AST-19", "BCD-12.3" ], + "11.8.4.C.01": [ + "AST-19", + "HRS-05.3" + ], + "11.8.5.C.01": [ + "AST-19", + "HRS-05.3" + ], "18.3.14.C.01": [ "AST-20", "AST-21" @@ -3131,55 +3082,22 @@ "18.3.17.C.01": [ "AST-21" ], - "11.2.3.C.01": [ - "AST-23" - ], - "11.2.4.C.01": [ - "AST-23" - ], - "11.2.4.C.02": [ - "AST-23" - ], - "11.2.5.C.01": [ - "AST-23" - ], - "11.2.6.C.01": [ - "AST-23" - ], - "11.2.7.C.01": [ - "AST-23" - ], - "11.2.7.C.02": [ - "AST-23" - ], - "11.2.8.C.01": [ - "AST-23" - ], - "11.2.9.C.01": [ - "AST-23" - ], - "11.2.10.C.01": [ - "AST-23" - ], "11.2.11.C.01": [ "AST-23" ], "11.2.11.C.02": [ "AST-23" ], - "11.2.11.C.03": [ - "AST-23" - ], - "11.2.11.C.04": [ + "11.2.12.C.01": [ "AST-23" ], - "11.2.11.C.05": [ + "11.8.7.C.01": [ "AST-23" ], - "11.2.12.C.01": [ + "11.8.8.C.01": [ "AST-23" ], - "11.2.12.C.02": [ + "11.8.13.C.01": [ "AST-23" ], "3.4.10.C.01": [ @@ -3227,56 +3145,6 @@ "18.6.10.C.01": [ "AST-26" ], - "20.4.3.C.01": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.3.C.02": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.3.C.03": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.3.C.04": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.4.C.01": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.4.C.02": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.5.C.01": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.5.C.02": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.6.C.01": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], - "20.4.6.C.02": [ - "AST-28", - "AST-28.1", - "DCH-16" - ], "11.6.59.C.01": [ "AST-29" ], @@ -3349,15 +3217,6 @@ "11.6.71.C.01": [ "AST-29" ], - "11.6.72.C.01": [ - "AST-29" - ], - "11.6.72.C.02": [ - "AST-29" - ], - "11.6.72.C.03": [ - "AST-29" - ], "11.7.29.C.01": [ "AST-29.1" ], @@ -3449,6 +3308,12 @@ "13.1.14.C.01": [ "AST-30" ], + "20.2.15.C.03": [ + "AST-30" + ], + "20.2.15.C.06": [ + "AST-30" + ], "6.4.5.C.01": [ "BCD-01" ], @@ -3458,6 +3323,9 @@ "6.4.8.C.01": [ "BCD-01" ], + "20.1.26.C.01": [ + "BCD-01" + ], "23.4.12.C.01": [ "BCD-01" ], @@ -3482,81 +3350,47 @@ "6.3.7.C.03": [ "CHG-02" ], + "20.2.15.C.02": [ + "CHG-02.1" + ], + "20.2.15.C.05": [ + "CHG-02.1" + ], "6.3.8.C.01": [ "CHG-02.2", "IAO-02", "IAO-02.4", "IAO-05" ], - "22.1.20.C.01": [ - "CLD-01" - ], - "22.1.20.C.02": [ - "CLD-01" - ], - "22.1.20.C.03": [ - "CLD-01" - ], - "22.1.20.C.04": [ - "CLD-01" - ], - "22.1.20.C.05": [ - "CLD-01" - ], - "22.1.21.C.01": [ - "CLD-01" - ], - "22.1.21.C.02": [ - "CLD-01" - ], - "22.1.21.C.03": [ - "CLD-01" - ], - "22.1.21.C.04": [ - "CLD-01" - ], - "22.1.21.C.05": [ - "CLD-01" + "2.3.28.C.01": [ + "CLD-01", + "CLD-02", + "SEA-01", + "SEA-01.4", + "SEA-01.5" ], - "22.1.21.C.06": [ + "20.1.20.C.01": [ "CLD-01" ], - "22.1.21.C.07": [ + "20.1.20.C.02": [ "CLD-01" ], - "22.1.24.C.01": [ - "CLD-01", - "CLD-11" - ], - "22.1.24.C.02": [ - "CLD-01", - "CLD-03", - "CLD-11" - ], - "22.1.24.C.03": [ - "CLD-01", - "CLD-11" - ], - "22.1.24.C.04": [ - "CLD-01", - "CLD-11" - ], - "22.1.25.C.01": [ + "20.1.20.C.03": [ "CLD-01" ], - "22.1.25.C.02": [ + "20.1.20.C.04": [ "CLD-01" ], - "22.1.26.C.01": [ + "22.1.20.C.01": [ "CLD-01" ], - "22.1.26.C.02": [ + "22.1.20.C.02": [ "CLD-01" ], - "22.1.26.C.03": [ + "22.1.20.C.03": [ "CLD-01" ], - "22.1.27.C.01": [ + "22.1.21.C.01": [ "CLD-01" ], "23.1.54.C.01": [ @@ -3606,6 +3440,12 @@ "CLD-06.2", "CLD-06.4" ], + "20.1.26.C.02": [ + "CLD-01.2" + ], + "20.1.26.C.03": [ + "CLD-01.2" + ], "23.4.13.C.01": [ "CLD-01.2" ], @@ -3615,15 +3455,25 @@ "23.4.13.C.03": [ "CLD-01.2" ], - "22.1.23.C.01": [ + "20.1.24.C.02": [ "CLD-02" ], - "22.1.23.C.02": [ + "20.1.24.C.03": [ "CLD-02" ], - "22.1.23.C.03": [ + "20.1.24.C.04": [ "CLD-02" ], + "20.2.12.C.01": [ + "CLD-02", + "NET-02.3", + "SEA-13.1" + ], + "20.2.12.C.02": [ + "CLD-02", + "NET-02.3", + "SEA-13.1" + ], "23.1.56.C.01": [ "CLD-02" ], @@ -3643,24 +3493,32 @@ "CLD-06", "CLD-06.1" ], - "22.1.22.C.01": [ - "CLD-09" + "20.1.21.C.03": [ + "CLD-06.1" ], - "22.1.22.C.02": [ - "CLD-09" + "20.1.22.C.01": [ + "CLD-09", + "IAO-07" ], - "22.1.22.C.03": [ + "20.1.22.C.02": [ "CLD-09" ], - "22.1.22.C.04": [ + "20.1.22.C.03": [ "CLD-09", - "CLD-10" + "IAO-02", + "IAO-07" + ], + "20.1.22.C.04": [ + "CLD-09" ], - "22.1.22.C.05": [ + "20.1.22.C.05": [ "CLD-09", - "CLD-10" + "IAO-07" ], - "22.1.22.C.06": [ + "20.1.22.C.06": [ + "CLD-09" + ], + "22.1.22.C.02": [ "CLD-09" ], "23.4.11.C.01": [ @@ -3669,9 +3527,6 @@ "23.4.11.C.02": [ "CLD-09" ], - "2.3.23.C.01": [ - "CLD-10" - ], "1.1.64.C.01": [ "CPL-01" ], @@ -3687,6 +3542,16 @@ "1.1.67.C.01": [ "CPL-01" ], + "1.2.15.C.01": [ + "CPL-01", + "SEA-01.4" + ], + "1.2.15.C.02": [ + "CPL-01" + ], + "17.9.37.C.01": [ + "CPL-01" + ], "1.1.68.C.01": [ "CPL-01.1" ], @@ -3701,6 +3566,15 @@ "CPL-03", "CPL-03.2" ], + "17.9.33.C.01": [ + "CPL-02.2" + ], + "17.9.33.C.02": [ + "CPL-02.2" + ], + "17.9.33.C.03": [ + "CPL-02.2" + ], "4.3.16.C.01": [ "CPL-03", "IAO-02.1", @@ -3730,6 +3604,9 @@ "12.2.6.C.02": [ "CFG-01" ], + "17.9.38.C.03": [ + "CFG-01" + ], "18.1.10.C.01": [ "CFG-01", "CFG-02.4", @@ -3754,6 +3631,29 @@ "CFG-02.5", "CFG-02.6" ], + "20.2.14.C.02": [ + "CFG-01" + ], + "11.1.16.C.01": [ + "CFG-02" + ], + "11.1.16.C.02": [ + "CFG-02" + ], + "11.1.17.C.01": [ + "CFG-02" + ], + "11.1.17.C.03": [ + "CFG-02" + ], + "11.8.6.C.01": [ + "CFG-02", + "HRS-05.3" + ], + "11.8.6.C.02": [ + "CFG-02", + "HRS-05.3" + ], "14.1.8.C.01": [ "CFG-02" ], @@ -3773,17 +3673,113 @@ "14.3.7.C.01": [ "CFG-02" ], + "15.2.41.C.01": [ + "CFG-02" + ], + "15.2.41.C.02": [ + "CFG-02" + ], + "15.2.42.C.01": [ + "CFG-02" + ], + "15.2.43.C.01": [ + "CFG-02" + ], + "15.2.44.C.01": [ + "CFG-02" + ], + "15.2.46.C.01": [ + "CFG-02" + ], + "15.2.46.C.03": [ + "CFG-02" + ], + "15.2.47.C.01": [ + "CFG-02" + ], + "15.2.47.C.02": [ + "CFG-02" + ], + "15.2.48.C.01": [ + "CFG-02" + ], + "15.2.48.C.02": [ + "CFG-02" + ], + "15.2.48.C.03": [ + "CFG-02" + ], + "15.2.49.C.01": [ + "CFG-02" + ], + "15.2.49.C.02": [ + "CFG-02" + ], + "15.2.49.C.03": [ + "CFG-02" + ], + "15.2.50.C.01": [ + "CFG-02" + ], + "15.2.50.C.02": [ + "CFG-02" + ], + "15.2.50.C.03": [ + "CFG-02" + ], + "15.2.50.C.04": [ + "CFG-02" + ], + "16.1.31.C.03": [ + "CFG-02" + ], + "16.1.31.C.04": [ + "CFG-02" + ], + "16.1.31.C.05": [ + "CFG-02" + ], + "16.7.42.C.01": [ + "CFG-02", + "IAC-06" + ], + "20.2.14.C.05": [ + "CFG-02" + ], + "20.2.14.C.07": [ + "CFG-02", + "SEA-13.1" + ], + "22.1.16.C.01": [ + "CFG-02" + ], + "22.1.16.C.02": [ + "CFG-02" + ], + "22.1.17.C.01": [ + "CFG-02" + ], + "22.1.17.C.02": [ + "CFG-02" + ], + "22.1.17.C.03": [ + "CFG-02" + ], + "22.1.19.C.01": [ + "CFG-02" + ], + "22.1.19.C.02": [ + "CFG-02" + ], "23.2.21.C.01": [ "CFG-02", "CFG-02.5" ], - "16.1.50.C.01": [ - "CFG-02.9", - "SEA-19" + "15.2.45.C.01": [ + "CFG-02.1" ], - "16.1.50.C.02": [ - "CFG-02.9", - "SEA-19" + "15.2.38.C.01": [ + "CFG-02.5" ], "18.1.15.C.01": [ "CFG-03", @@ -3840,6 +3836,9 @@ "14.2.7.C.07": [ "CFG-03.3" ], + "21.3.12.C.02": [ + "CFG-03.3" + ], "18.7.14.C.01": [ "CFG-03.4" ], @@ -3932,6 +3931,15 @@ "18.4.14.C.01": [ "MON-01.1" ], + "16.6.15.C.01": [ + "MON-01.2" + ], + "16.6.15.C.02": [ + "MON-01.2" + ], + "15.2.40.C.02": [ + "MON-01.3" + ], "14.3.6.C.02": [ "MON-01.9", "NET-18", @@ -3974,6 +3982,12 @@ "MON-03.2", "MON-03.7" ], + "16.4.41.C.01": [ + "MON-03.3" + ], + "16.4.41.C.02": [ + "MON-03.3" + ], "16.6.13.C.01": [ "MON-04", "MON-08", @@ -3994,6 +4008,12 @@ "MON-08", "MON-08.1" ], + "16.4.41.C.03": [ + "MON-08.2" + ], + "16.6.13.C.05": [ + "MON-10" + ], "8.4.13.C.01": [ "CRY-01", "CRY-05", @@ -4117,10 +4137,6 @@ "CRY-01", "NET-14" ], - "17.6.6.C.01": [ - "CRY-01", - "NET-13" - ], "17.6.7.C.01": [ "CRY-01", "NET-13" @@ -4155,45 +4171,15 @@ "17.8.17.C.01": [ "CRY-01" ], - "17.9.24.C.01": [ - "CRY-01" - ], - "17.9.24.C.02": [ - "CRY-01" - ], - "17.9.24.C.03": [ - "CRY-01" - ], - "17.9.25.C.01": [ - "CRY-01" - ], - "17.9.26.C.01": [ - "CRY-01" - ], - "17.9.26.C.02": [ - "CRY-01" - ], - "17.9.27.C.01": [ - "CRY-01" - ], - "17.9.27.C.02": [ - "CRY-01" - ], - "17.9.27.C.03": [ - "CRY-01" - ], - "17.9.28.C.01": [ - "CRY-01" - ], - "17.9.29.C.01": [ - "CRY-01" - ], "17.9.30.C.01": [ "CRY-01" ], "17.9.30.C.02": [ "CRY-01" ], + "17.9.30.C.03": [ + "CRY-01" + ], "17.9.31.C.01": [ "CRY-01" ], @@ -4203,12 +4189,21 @@ "17.9.32.C.02": [ "CRY-01" ], - "17.9.32.C.03": [ + "17.9.38.C.01": [ "CRY-01" ], + "17.9.38.C.02": [ + "CRY-01" + ], + "17.9.34.C.01": [ + "CRY-01.5" + ], "18.2.9.C.01": [ "CRY-07" ], + "18.2.9.C.02": [ + "CRY-07" + ], "18.2.10.C.01": [ "CRY-07", "NET-15.1" @@ -4315,14 +4310,6 @@ "CRY-08.1", "CRY-09" ], - "17.1.51.C.02": [ - "CRY-08", - "CRY-08.1" - ], - "17.1.51.C.03": [ - "CRY-08", - "CRY-08.1" - ], "23.3.21.C.01": [ "CRY-08", "CRY-09", @@ -4345,9 +4332,6 @@ "7.2.24.C.01": [ "CRY-09.3" ], - "7.2.25.C.01": [ - "CRY-09.3" - ], "4.4.10.C.01": [ "DCH-01", "DCH-04", @@ -4405,6 +4389,12 @@ "13.2.7.C.01": [ "DCH-01" ], + "16.2.7.C.01": [ + "DCH-01.2" + ], + "16.2.7.C.02": [ + "DCH-01.2" + ], "18.6.8.C.01": [ "DCH-01.2", "DCH-02" @@ -4463,8 +4453,11 @@ "13.2.14.C.02": [ "DCH-04" ], - "21.1.21.C.01": [ - "DCH-04" + "15.2.39.C.02": [ + "DCH-04.1" + ], + "15.2.39.C.03": [ + "DCH-04.1" ], "8.4.10.C.01": [ "DCH-06" @@ -4594,6 +4587,12 @@ "DCH-12", "DCH-13.2" ], + "11.8.11.C.01": [ + "DCH-13.2" + ], + "11.8.11.C-02": [ + "DCH-13.2" + ], "13.3.7.C.01": [ "DCH-13.2" ], @@ -4612,130 +4611,6 @@ "13.3.9.C.02": [ "DCH-13.2" ], - "20.1.6.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.1.6.C.02": [ - "DCH-14", - "PRI-07" - ], - "20.1.7.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.1.7.C.02": [ - "DCH-14", - "PRI-07" - ], - "20.1.8.C.01": [ - "DCH-14", - "DCH-14.2", - "PRI-07" - ], - "20.1.9.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.1.10.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.1.10.C.02": [ - "DCH-14", - "PRI-07" - ], - "20.1.11.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.1.12.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.1.13.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.2.3.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.2.4.C.01": [ - "DCH-14", - "DCH-14.2", - "PRI-07" - ], - "20.2.5.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.2.6.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.6.C.02": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.6.C.03": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.7.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.8.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.9.C.01": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.9.C.02": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.9.C.03": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.9.C.04": [ - "DCH-14", - "DCH-17", - "PRI-07" - ], - "20.2.10.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.2.10.C.02": [ - "DCH-14", - "PRI-07" - ], - "20.2.11.C.01": [ - "DCH-14", - "PRI-07" - ], - "20.2.11.C.02": [ - "DCH-14", - "PRI-07" - ], - "20.2.11.C.03": [ - "DCH-14", - "PRI-07" - ], "16.2.5.C.01": [ "DCH-14.3", "IAC-08" @@ -4743,6 +4618,9 @@ "16.2.6.C.01": [ "DCH-14.3" ], + "21.3.10.C.01": [ + "END-04" + ], "14.1.12.C.01": [ "END-06" ], @@ -4755,23 +4633,7 @@ "18.4.13.C.01": [ "END-07" ], - "15.2.21.C.01": [ - "END-08", - "IRO-15" - ], - "15.2.23.C.01": [ - "END-08" - ], - "15.2.23.C.02": [ - "END-08" - ], - "15.2.23.C.03": [ - "END-08" - ], - "15.2.24.C.01": [ - "END-08" - ], - "15.2.24.C.02": [ + "15.2.37.C.01": [ "END-08" ], "9.2.10.C.01": [ @@ -4801,10 +4663,6 @@ "HRS-05.3", "NET-13" ], - "9.2.10.C.02": [ - "HRS-02", - "HRS-04.3" - ], "3.3.4.C.01": [ "HRS-03" ], @@ -4901,6 +4759,9 @@ "3.3.15.C.01": [ "HRS-03" ], + "17.9.35.C.01": [ + "HRS-03" + ], "9.1.7.C.01": [ "HRS-04.2" ], @@ -4965,19 +4826,19 @@ "HRS-05.1", "HRS-05.2" ], + "21.1.6.C.02": [ + "HRS-05" + ], + "21.2.3.C.01": [ + "HRS-05" + ], "9.1.8.C.01": [ "HRS-05.1", "HRS-06.1" ], - "21.1.22.C.01": [ - "HRS-05.1", - "HRS-05.3", - "HRS-05.5" - ], - "21.1.22.C.02": [ + "16.4.38.C.02": [ "HRS-05.1", - "HRS-05.3", - "HRS-05.5" + "IAC-18" ], "9.3.4.C.01": [ "HRS-05.3" @@ -4994,8 +4855,29 @@ "9.3.10.C.01": [ "HRS-05.3" ], - "11.4.9.C.01": [ - "HRS-05.5" + "11.1.16.C.03": [ + "HRS-05.3" + ], + "11.1.16.C.04": [ + "HRS-05.3" + ], + "11.1.17.C.02": [ + "HRS-05.3" + ], + "11.1.18.C.01": [ + "HRS-05.3" + ], + "11.1.18.C.02": [ + "HRS-05.3" + ], + "11.1.19.C.02": [ + "HRS-05.3" + ], + "11.2.14.C.01": [ + "HRS-05.3" + ], + "11.8.4.C.02": [ + "HRS-05.3" ], "11.4.10.C.01": [ "HRS-05.5" @@ -5012,9 +4894,6 @@ "11.4.12.C.02": [ "HRS-05.5" ], - "11.5.13.C.01": [ - "HRS-05.5" - ], "11.5.14.C.01": [ "HRS-05.5" ], @@ -5040,13 +4919,57 @@ "HRS-05.5", "MDM-01" ], - "21.1.11.C.02": [ - "HRS-05.5", - "MDM-01" + "22.1.10.C.02": [ + "HRS-05.5" + ], + "22.1.13.C.01": [ + "HRS-05.5" + ], + "22.1.13.C.02": [ + "HRS-05.5" + ], + "22.1.13.C.03": [ + "HRS-05.5" + ], + "22.1.13.C.04": [ + "HRS-05.5" + ], + "22.1.13.C.05": [ + "HRS-05.5" + ], + "22.2.5.C.01": [ + "HRS-05.5" + ], + "22.2.6.C.01": [ + "HRS-05.5" + ], + "22.2.7.C.01": [ + "HRS-05.5" + ], + "22.2.7.C.02": [ + "HRS-05.5" + ], + "22.3.5.C.01": [ + "HRS-05.5" + ], + "22.3.6.C.01": [ + "HRS-05.5" + ], + "22.4.9.C.01": [ + "HRS-05.5" ], "16.1.31.C.01": [ "IAC-01" ], + "16.4.39.C.01": [ + "IAC-01" + ], + "20.2.16.C.02": [ + "IAC-01" + ], + "16.1.26.C.01": [ + "IAC-01.2" + ], "16.1.32.C.01": [ "IAC-02" ], @@ -5054,37 +4977,33 @@ "IAC-02.1", "IAC-15.5" ], - "16.1.33.C.02": [ - "IAC-02.1", - "IAC-15.5" - ], "16.1.34.C.01": [ "IAC-02.1", "IAC-15.5" ], - "16.7.34.C.01": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "16.1.29.C.02": [ + "IAC-06" ], - "16.7.34.C.02": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "16.4.37.C.02": [ + "IAC-06" ], - "16.7.35.C.01": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "16.7.42.C.04": [ + "IAC-06" ], - "16.7.36.C.01": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2", - "IAC-06.3" + "16.7.42.C.05": [ + "IAC-06" + ], + "16.7.42.C.06": [ + "IAC-06" + ], + "16.7.42.C.07": [ + "IAC-06" + ], + "16.7.43.C.01": [ + "IAC-06" + ], + "16.7.44.C.01": [ + "IAC-06" ], "23.3.19.C.01": [ "IAC-06" @@ -5092,6 +5011,13 @@ "23.3.19.C.02": [ "IAC-06" ], + "16.7.42.C.02": [ + "IAC-06.1" + ], + "16.7.42.C.03": [ + "IAC-06.1", + "IAC-06.2" + ], "23.3.20.C.01": [ "IAC-07" ], @@ -5111,10 +5037,13 @@ "IAC-10", "IAC-10.11" ], - "16.1.40.C.01": [ + "16.1.36.C.02": [ "IAC-10" ], - "16.1.40.C.02": [ + "16.1.36.C.03": [ + "IAC-10" + ], + "16.1.40.C.01": [ "IAC-10" ], "16.1.41.C.01": [ @@ -5125,16 +5054,17 @@ "IAC-10", "IAC-10.4" ], - "16.1.41.C.03": [ + "16.1.42.C.01": [ "IAC-10", - "IAC-10.4" + "IAC-10.1" ], - "16.1.41.C.04": [ - "IAC-10", - "IAC-10.4" + "16.1.29.C.01": [ + "IAC-10.1" ], - "16.1.42.C.01": [ - "IAC-10", + "16.1.31.C.02": [ + "IAC-10.1" + ], + "16.1.31.C.07": [ "IAC-10.1" ], "16.1.35.C.01": [ @@ -5146,6 +5076,9 @@ "16.1.43.C.01": [ "IAC-10.1" ], + "16.1.34.C.02": [ + "IAC-10.5" + ], "16.1.36.C.01": [ "IAC-10.5", "IAC-10.6" @@ -5156,6 +5089,9 @@ "16.1.38.C.01": [ "IAC-10.5" ], + "16.1.37.C.02": [ + "IAC-10.11" + ], "17.10.12.C.01": [ "IAC-12.1" ], @@ -5168,10 +5104,18 @@ "17.10.12.C.04": [ "IAC-12.1" ], - "16.3.5.C.01": [ - "IAC-16" + "16.1.27.C.01": [ + "IAC-15.5", + "IAC-19" + ], + "16.1.27.C.02": [ + "IAC-15.5", + "IAC-19" + ], + "16.1.28.C.01": [ + "IAC-15.5" ], - "16.3.5.C.02": [ + "16.3.5.C.01": [ "IAC-16" ], "16.3.6.C.01": [ @@ -5183,73 +5127,40 @@ "16.3.7.C.01": [ "IAC-16" ], - "16.4.30.C.01": [ - "IAC-16" - ], - "16.4.30.C.02": [ - "IAC-16" - ], - "16.4.30.C.03": [ - "IAC-16" - ], - "16.4.31.C.01": [ - "IAC-16", - "IAC-21" - ], - "16.4.31.C.02": [ - "IAC-16", - "IAC-21" - ], - "16.4.32.C.01": [ - "IAC-16" - ], - "16.4.32.C.02": [ + "16.4.36.C.01": [ "IAC-16" ], - "16.4.33.C.01": [ + "16.4.36.C.02": [ "IAC-16" ], - "16.4.34.C.01": [ - "IAC-16", - "IAC-16.1" - ], - "16.4.35.C.01": [ - "IAC-16", - "IAC-17" - ], - "16.4.35.C.02": [ - "IAC-16", - "IAC-17" - ], - "16.4.35.C.03": [ - "IAC-16", - "IAC-17" - ], - "16.4.36.C.01": [ + "16.4.36.C.03": [ "IAC-16" ], "16.4.37.C.01": [ "IAC-16", "IAC-18" ], - "23.3.18.C.01": [ - "IAC-16.2" - ], - "16.1.46.C.01": [ - "IAC-22" + "16.4.37.C.03": [ + "IAC-16" + ], + "16.4.38.C.01": [ + "IAC-16" ], - "16.1.46.C.02": [ - "IAC-22" + "16.4.40.C.01": [ + "IAC-16.1" ], - "16.1.45.C.01": [ - "IAC-24" + "23.3.18.C.01": [ + "IAC-16.2" ], - "16.1.45.C.02": [ - "IAC-24" + "16.1.27.C.03": [ + "IAC-19" ], "16.1.44.C.01": [ "IAC-25" ], + "16.1.31.C.06": [ + "IAC-29" + ], "7.1.7.C.01": [ "IRO-01" ], @@ -5271,13 +5182,9 @@ "IRO-02", "PES-01" ], - "7.2.17.C.01": [ - "IRO-02", - "IRO-03" - ], - "7.2.17.C.02": [ + "7.2.18.C.02": [ "IRO-02", - "IRO-03" + "IRO-10" ], "7.2.19.C.01": [ "IRO-02" @@ -5292,6 +5199,9 @@ "IRO-04", "IRO-11.2" ], + "20.1.25.C.02": [ + "IRO-02" + ], "5.1.12.C.01": [ "IRO-04" ], @@ -5307,7 +5217,10 @@ "7.3.5.C.01": [ "IRO-04" ], - "16.1.47.C.01": [ + "16.4.39.C.02": [ + "IRO-04" + ], + "16.4.42.C.01": [ "IRO-04" ], "7.3.11.C.01": [ @@ -5324,6 +5237,12 @@ "IRO-10", "IRO-10.2" ], + "7.2.20.C.02": [ + "IRO-10" + ], + "7.2.20.C.03": [ + "IRO-10" + ], "7.2.21.C.01": [ "IRO-10", "IRO-10.2" @@ -5371,9 +5290,6 @@ "IRO-12", "IRO-12.4" ], - "2.1.10.C.01": [ - "IRO-14" - ], "2.2.5.C.01": [ "IAO-01", "IAO-07" @@ -5441,6 +5357,13 @@ "5.8.61.C.03": [ "IAO-01.1" ], + "20.1.21.C.02": [ + "IAO-01.1" + ], + "23.5.10.C.01": [ + "IAO-01.1", + "IAO-02" + ], "4.2.10.C.01": [ "IAO-02" ], @@ -5459,6 +5382,31 @@ "IAO-02.2", "IAO-02.3" ], + "11.1.19.C.01": [ + "IAO-02" + ], + "16.1.30.C.01": [ + "IAO-02", + "RSK-08" + ], + "16.7.41.C.01": [ + "IAO-02" + ], + "20.1.21.C.01": [ + "IAO-02" + ], + "20.1.21.C.07": [ + "IAO-02" + ], + "20.1.23.C.01": [ + "IAO-02" + ], + "20.2.13.C.01": [ + "IAO-02.2" + ], + "20.2.13.C.02": [ + "IAO-02.2" + ], "5.8.62.C.01": [ "IAO-02.3" ], @@ -5542,6 +5490,9 @@ "4.5.18.C.03": [ "IAO-07" ], + "20.1.21.C.04": [ + "IAO-07" + ], "12.5.3.C.01": [ "MNT-01", "MNT-02" @@ -5558,6 +5509,15 @@ "MNT-01", "MNT-02" ], + "11.8.10.C.01": [ + "MNT-02" + ], + "11.8.10.C.04": [ + "MNT-02" + ], + "11.8.10.C.02": [ + "MNT-04.3" + ], "12.5.4.C.01": [ "MNT-06.1" ], @@ -5580,63 +5540,27 @@ "21.1.10.C.02": [ "MDM-01" ], - "21.1.10.C.03": [ - "MDM-01" - ], - "21.1.14.C.01": [ - "MDM-01" - ], - "21.1.14.C.02": [ - "MDM-01" - ], - "21.1.15.C.01": [ - "MDM-01" - ], - "21.1.17.C.01": [ - "MDM-01" - ], - "21.1.17.C.02": [ - "MDM-01" - ], - "21.1.17.C.03": [ - "MDM-01" - ], - "21.1.18.C.01": [ + "22.1.10.C.03": [ "MDM-01" ], - "21.1.18.C.02": [ + "22.1.12.C.01": [ "MDM-01" ], - "21.1.19.C.01": [ + "22.1.15.C.01": [ "MDM-01" ], - "21.1.19.C.02": [ + "22.1.18.C.02": [ "MDM-01" ], "21.1.13.C.01": [ "MDM-03" ], - "21.1.13.C.02": [ - "MDM-03" - ], - "21.1.13.C.03": [ - "MDM-03" - ], - "21.1.13.C.04": [ + "22.1.14.C.01": [ "MDM-03" ], - "21.1.13.C.05": [ + "22.1.14.C.02": [ "MDM-03" ], - "21.1.20.C.01": [ - "MDM-05" - ], - "21.1.20.C.02": [ - "MDM-05" - ], - "21.1.20.C.03": [ - "MDM-05" - ], "10.8.34.C.01": [ "NET-01" ], @@ -5709,6 +5633,12 @@ "2.3.26.C.02": [ "NET-01.1" ], + "16.1.25.C.01": [ + "NET-01.1" + ], + "16.5.12.C.02": [ + "NET-01.1" + ], "18.3.18.C.01": [ "NET-02.1" ], @@ -5746,6 +5676,21 @@ "19.2.20.C.01": [ "NET-02.3" ], + "20.2.14.C.04": [ + "NET-02.3", + "SEA-13.1" + ], + "20.3.9.C.02": [ + "NET-02.3", + "NET-06.2" + ], + "20.3.9.C.04": [ + "NET-02.3", + "NET-06.2" + ], + "21.1.8.C.01": [ + "NET-02.3" + ], "19.1.10.C.01": [ "NET-03" ], @@ -5970,6 +5915,15 @@ "19.5.29.C.01": [ "NET-03" ], + "21.3.5.C.01": [ + "NET-03" + ], + "21.3.5.C.02": [ + "NET-03" + ], + "21.3.6.C.01": [ + "NET-03" + ], "14.1.11.C.01": [ "NET-03.8" ], @@ -5994,59 +5948,9 @@ "14.1.13.C.03": [ "NET-05.1" ], - "22.3.9.C.01": [ - "NET-06.2" - ], - "22.3.9.C.02": [ - "NET-06.2" - ], - "22.3.9.C.03": [ - "NET-06.2" - ], - "22.3.9.C.04": [ + "20.3.9.C.03": [ "NET-06.2" ], - "22.3.10.C.01": [ - "NET-06.2" - ], - "22.3.11.C.01": [ - "NET-06.2" - ], - "22.3.11.C.02": [ - "NET-06.2" - ], - "21.4.12.C.01": [ - "NET-08.2" - ], - "21.4.12.C.02": [ - "NET-08.2" - ], - "21.4.12.C.03": [ - "NET-08.2" - ], - "15.2.20.C.01": [ - "NET-10", - "NET-10.3" - ], - "15.2.20.C.02": [ - "NET-10", - "NET-10.3" - ], - "15.2.20.C.03": [ - "NET-10", - "NET-10.3" - ], - "15.2.20.C.04": [ - "NET-10", - "NET-10.3" - ], - "15.2.20.C.05": [ - "NET-10", - "NET-10.3" - ], - "15.2.22.C.01": [ - "NET-10.1" - ], "15.1.8.C.01": [ "NET-13" ], @@ -6104,63 +6008,6 @@ "15.1.20.C.01": [ "NET-13" ], - "15.2.25.C.01": [ - "NET-13" - ], - "15.2.25.C.02": [ - "NET-13" - ], - "15.2.26.C.01": [ - "NET-13" - ], - "15.2.27.C.01": [ - "NET-13" - ], - "15.2.28.C.01": [ - "NET-13" - ], - "15.2.29.C.01": [ - "NET-13" - ], - "15.2.30.C.01": [ - "NET-13" - ], - "15.2.30.C.02": [ - "NET-13" - ], - "15.2.30.C.03": [ - "NET-13" - ], - "15.2.31.C.01": [ - "NET-13" - ], - "15.2.31.C.02": [ - "NET-13" - ], - "15.2.32.C.01": [ - "NET-13" - ], - "15.2.32.C.02": [ - "NET-13" - ], - "15.2.32.C.03": [ - "NET-13" - ], - "15.2.33.C.01": [ - "NET-13" - ], - "15.2.33.C.02": [ - "NET-13" - ], - "15.2.33.C.03": [ - "NET-13" - ], - "15.2.33.C.04": [ - "NET-13" - ], - "16.7.33.C.01": [ - "NET-13" - ], "16.5.10.C.01": [ "NET-14" ], @@ -6202,9 +6049,6 @@ "21.2.4.C.01": [ "NET-14.5" ], - "21.2.4.C.02": [ - "NET-14.5" - ], "21.2.5.C.01": [ "NET-14.5" ], @@ -6214,13 +6058,10 @@ "21.2.7.C.01": [ "NET-14.5" ], - "21.2.7.C.02": [ - "NET-14.5" - ], - "21.3.5.C.01": [ + "22.2.4.C.01": [ "NET-14.5" ], - "21.3.6.C.01": [ + "22.2.4.C.02": [ "NET-14.5" ], "18.2.5.C.01": [ @@ -6268,9 +6109,27 @@ "18.2.34.C.01": [ "NET-15" ], + "18.2.19.C.02": [ + "NET-15.1" + ], + "18.2.19.C.03": [ + "NET-15.1" + ], "18.2.33.C.01": [ "NET-15.4" ], + "22.4.12.C.02": [ + "NET-15.5" + ], + "22.4.12.C.03": [ + "NET-15.5" + ], + "15.2.39.C.01": [ + "NET-17" + ], + "15.2.40.C.01": [ + "NET-17" + ], "9.3.6.C.01": [ "NET-18" ], @@ -6303,30 +6162,6 @@ "14.3.12.C.01": [ "NET-18" ], - "20.3.4.C.01": [ - "NET-18" - ], - "20.3.4.C.02": [ - "NET-18" - ], - "20.3.5.C.01": [ - "NET-18" - ], - "20.3.5.C.02": [ - "NET-18" - ], - "20.3.6.C.01": [ - "NET-18" - ], - "20.3.7.C.01": [ - "NET-18" - ], - "20.3.7.C.02": [ - "NET-18" - ], - "20.3.8.C.01": [ - "NET-18" - ], "20.3.9.C.01": [ "NET-18" ], @@ -6339,43 +6174,45 @@ "20.3.11.C.02": [ "NET-18" ], - "20.3.11.C.03": [ + "21.3.7.C.01": [ "NET-18" ], - "20.3.12.C.01": [ + "21.3.7.C.02": [ "NET-18" ], - "20.3.12.C.02": [ + "21.3.14.C.01": [ "NET-18" ], - "20.3.13.C.01": [ - "NET-18" + "15.2.46.C.02": [ + "NET-18.1" ], - "20.3.13.C.02": [ - "NET-18" + "14.3.8.C.01": [ + "NET-18.2" ], - "20.3.14.C.01": [ - "NET-18", + "14.3.9.C.01": [ "NET-18.2" ], - "20.3.15.C.01": [ - "NET-18" + "15.2.36.C.01": [ + "NET-20.4" ], - "20.3.15.C.02": [ - "NET-18" + "15.2.36.C.02": [ + "NET-20.4" ], - "20.3.16.C.01": [ - "NET-18" + "15.2.36.C.03": [ + "NET-20.4" ], - "14.3.8.C.01": [ - "NET-18.2" + "15.2.36.C.04": [ + "NET-20.4" ], - "14.3.9.C.01": [ - "NET-18.2" + "15.2.36.C.05": [ + "NET-20.4" ], "8.1.10.C.01": [ "PES-01" ], + "20.2.16.C.01": [ + "PES-01" + ], "8.2.7.C.01": [ "PES-01.1" ], @@ -6421,6 +6258,9 @@ "8.2.6.C.02": [ "PES-04" ], + "17.9.36.C.02": [ + "PES-04.1" + ], "8.1.13.C.01": [ "PES-04.2", "VPM-08" @@ -6723,6 +6563,9 @@ "10.6.31.C.01": [ "PES-12.1" ], + "11.8.9.C.01": [ + "PES-12.2" + ], "10.7.6.C.01": [ "PES-13" ], @@ -6825,9 +6668,15 @@ "RSK-04", "THR-06" ], + "22.4.7.C.01": [ + "RSK-04" + ], "23.2.16.C.02": [ "RSK-04" ], + "11.1.18.C.03": [ + "RSK-06.2" + ], "12.4.5.C.01": [ "RSK-06.2", "TDA-01.1" @@ -6912,102 +6761,34 @@ "RSK-09", "TPM-03" ], - "1.2.13.C.01": [ + "20.2.14.C.01": [ "SEA-01", - "SEA-02", - "SEA-03" - ], - "1.2.13.C.02": [ - "SEA-01", - "SEA-02", - "SEA-03" - ], - "22.2.12.C.01": [ - "SEA-13.1" - ], - "22.2.12.C.02": [ - "SEA-13.1" - ], - "22.2.12.C.03": [ - "SEA-13.1" - ], - "22.2.12.C.04": [ - "SEA-13.1" - ], - "22.2.13.C.01": [ - "SEA-13.1" - ], - "22.2.13.C.02": [ - "SEA-13.1" - ], - "22.2.14.C.01": [ - "SEA-13.1" - ], - "22.2.14.C.02": [ - "SEA-13.1" - ], - "22.2.14.C.03": [ - "SEA-13.1" - ], - "22.2.14.C.04": [ - "SEA-13.1" - ], - "22.2.14.C.05": [ - "SEA-13.1" - ], - "22.2.14.C.06": [ - "SEA-13.1" - ], - "22.2.14.C.07": [ - "SEA-13.1" - ], - "22.2.15.C.01": [ - "SEA-13.1" - ], - "22.2.15.C.02": [ - "SEA-13.1" - ], - "22.2.15.C.03": [ - "SEA-13.1" - ], - "22.2.15.C.04": [ - "SEA-13.1" - ], - "22.2.15.C.05": [ - "SEA-13.1" - ], - "22.2.15.C.06": [ "SEA-13.1" ], - "22.2.15.C.07": [ + "20.2.14.C.03": [ + "SEA-01", "SEA-13.1" ], - "22.2.16.C.01": [ + "20.2.12.C.03": [ "SEA-13.1" ], - "22.2.16.C.02": [ + "20.2.12.C.04": [ "SEA-13.1" ], - "22.2.16.C.03": [ - "SEA-13.1" + "16.1.44.C.02": [ + "SEA-18" ], - "16.1.48.C.01": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "16.1.44.C.03": [ + "SEA-18" ], - "16.1.48.C.02": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "20.2.15.C.01": [ + "OPS-01.1" ], - "16.1.48.C.03": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "21.1.7.C.01": [ + "OPS-01.1" ], - "16.1.49.C.01": [ - "SEA-19" + "21.1.7.C.02": [ + "OPS-01.1" ], "5.1.15.C.01": [ "OPS-02" @@ -7029,9 +6810,21 @@ "SAT-02", "SAT-03" ], + "16.4.43.C.01": [ + "SAT-02" + ], + "20.1.27.C.01": [ + "SAT-02" + ], + "2.1.47.C.01": [ + "SAT-03" + ], "9.1.6.C.03": [ "SAT-03" ], + "22.1.11.C.01": [ + "SAT-03.3" + ], "12.1.31.C.01": [ "TDA-01.1" ], @@ -7099,6 +6892,9 @@ "14.4.4.C.01": [ "TDA-07" ], + "20.2.14.C.06": [ + "TDA-08" + ], "14.5.6.C.01": [ "TDA-09.4", "TDA-09.5", @@ -7110,6 +6906,21 @@ "2.2.6.C.02": [ "TPM-01" ], + "20.1.20.C.05": [ + "TPM-05" + ], + "20.1.23.C.02": [ + "TPM-05" + ], + "20.1.23.C.03": [ + "TPM-05" + ], + "20.1.24.C.01": [ + "TPM-05" + ], + "20.1.25.C.01": [ + "TPM-05" + ], "5.9.24.C.01": [ "THR-06" ], @@ -7132,6 +6943,9 @@ "VPM-01", "VPM-01.1" ], + "22.1.18.C.01": [ + "VPM-05" + ], "14.1.14.C.01": [ "VPM-06.8" ], diff --git a/docs/api/crosswalks/apac-nzl-privacy-act-2020.json b/docs/api/crosswalks/apac-nzl-privacy-act-2020.json index a9060228..c0d682dc 100644 --- a/docs/api/crosswalks/apac-nzl-privacy-act-2020.json +++ b/docs/api/crosswalks/apac-nzl-privacy-act-2020.json @@ -4,792 +4,690 @@ "scf_to_framework": { "total_mappings": 20, "mappings": { + "CPL-01": [ + "6.2.126(1)", + "6.2.126(2)", + "6.2.126(2)(a)", + "6.2.126(2)(b)" + ], "DCH-22.1": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" - ], - "DCH-25": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" - ], - "IAC-02": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], - "IAC-03": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], - "IAC-09.2": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], - "IAO-03.2": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "3.1.22.7(4)" + ], + "IRO-10": [ + "6.1.115(1)", + "6.1.115(2)", + "6.1.115(3)", + "6.1.115(3)(a)", + "6.1.115(3)(b)", + "6.1.115(4)", + "6.1.115(4)(a)", + "6.1.115(4)(b)", + "6.1.117(1)", + "6.1.117(1)(a)", + "6.1.117(1)(a)(i)", + "6.1.117(1)(a)(ii)", + "6.1.117(1)(b)", + "6.1.117(1)(c)", + "6.1.117(1)(d)", + "6.1.117(1)(e)", + "6.1.117(1)(f)", + "6.1.117(2)", + "6.1.117(2)(a)", + "6.1.117(2)(b)", + "6.1.117(2)(c)", + "6.1.117(2)(d)", + "6.1.117(2)(e)", + "6.1.117(2)(f)", + "6.1.117(3)", + "6.1.117(4)", + "6.1.117(5)" ], "PRI-01.5": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "3.1.22.12(1)", + "3.1.22.12(1)(a)", + "3.1.22.12(1)(b)", + "3.1.22.12(1)(c)", + "3.1.22.12(1)(d)", + "3.1.22.12(1)(e)", + "3.1.22.12(1)(f)", + "3.1.22.12(2)", + "3.1.22.12(3)" ], "PRI-01.6": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" - ], - "PRI-01.7": [ - "Principle 11", - "P11-(1)", - "P11-(1)(a)", - "P11-(1)(b)", - "P11-(1)(c)", - "P11-(1)(d)", - "P11-(1)(e)(i)", - "P11-(1)(e)(ii)", - "P11-(1)(e)(iii)", - "P11-(1)(e)(iv)", - "P11-(1)(f)(i)", - "P11-(1)(f)(ii)", - "P11-(1)(g)", - "P11-(1)(h)(i)", - "P11-(1)(h)(ii)", - "P11-(1)(i)", - "P11-(2)", - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "3.1.22.5(a)", + "3.1.22.5(a)(i)", + "3.1.22.5(a)(ii)", + "3.1.22.5(a)(iii)" + ], + "PRI-01.11": [ + "3.1.22.4", + "3.1.22.4(a)", + "3.1.22.4(b)", + "3.1.22.4(b)(i)", + "3.1.22.4(b)(ii)", + "3.1.22.5", + "3.1.22.5(b)", + "4.1.47(1)", + "4.1.47(1)(a)", + "4.1.47(1)(b)" ], "PRI-02": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" - ], - "PRI-02.1": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" - ], - "PRI-04": [ - "Principle 1", - "P1-(1)(a)", - "P1-(1)(b)", - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)", - "Principle 4", - "P4-(a)", - "P4-(b)", - "P4-(b)(i)", - "P4-(b)(ii)" + "3.1.22.3(1)", + "3.1.22.3(1)(a)", + "3.1.22.3(1)(b)", + "3.1.22.3(1)(c)", + "3.1.22.3(1)(d)", + "3.1.22.3(1)(d)(i)", + "3.1.22.3(1)(d)(ii)", + "3.1.22.3(1)(e)", + "3.1.22.3(1)(e)(i)", + "3.1.22.3(1)(e)(ii)", + "3.1.22.3(1)(f)", + "3.1.22.3(1)(g)", + "4.1.45(1)", + "4.1.45(1)(a)", + "4.1.45(1)(b)", + "4.1.45(1)(c)", + "4.1.45(2)" ], "PRI-04.2": [ - "Principle 2", - "P2-(1)", - "P2-(2)", - "P2-(2)(a)", - "P2-(2)(b)", - "P2-(2)(c)", - "P2-(2)(d)", - "P2-(2)(e)(i)", - "P2-(2)(e)(ii)", - "P2-(2)(e)(iii)", - "P2-(2)(e)(iv)", - "P2-(2)(e)(v)", - "P2-(2)(f)", - "P2-(2)(g)(i)", - "P2-(2)(g)(ii)" - ], - "PRI-05.1": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "3.1.22.2(1)" + ], + "PRI-05": [ + "3.1.22.9" ], "PRI-05.2": [ - "Principle 9" + "3.1.22.8" ], "PRI-05.4": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "3.1.22.1(1)", + "3.1.22.1(1)(a)", + "3.1.22.1(1)(b)", + "3.1.22.10(1)", + "3.1.22.10(1)(a)", + "3.1.22.10(1)(b)", + "3.1.22.10(1)(b)(i)", + "3.1.22.10(1)(b)(ii)", + "3.1.22.10(1)(c)", + "3.1.22.10(1)(d)", + "3.1.22.10(1)(e)", + "3.1.22.10(1)(e)(i)", + "3.1.22.10(1)(e)(ii)", + "3.1.22.10(1)(e)(iii)", + "3.1.22.10(1)(e)(iv)", + "3.1.22.10(1)(f)", + "3.1.22.10(1)(f)(i)", + "3.1.22.10(1)(f)(ii)" ], "PRI-06": [ - "Principle 6", - "P6-(1)", - "P6-(1)(a)", - "P6-(1)(b)", - "P6-(2)", - "P6-(3)" - ], - "PRI-06.1": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" + "3.1.22.6(1)", + "3.1.22.6(1)(a)", + "3.1.22.6(1)(b)", + "3.1.22.6(2)", + "3.1.22.7(1)", + "3.1.22.7(3)", + "3.1.22.7(3)(a)", + "4.2.59" ], "PRI-06.2": [ - "P6-(2)" - ], - "PRI-07.1": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "3.1.22.7(3)(b)" + ], + "PRI-06.4": [ + "3.1.22.7(2)", + "4.1.44(1)", + "4.1.44(2)", + "4.1.44(2)(b)", + "4.1.44(2)(c)", + "4.1.44(2)(c)(i)", + "4.1.44(2)(c)(ii)", + "4.1.44(2)(d)", + "4.2.63(1)", + "4.2.63(1)(a)", + "4.2.63(1)(b)", + "4.2.63(1)(b)(i)", + "4.2.63(1)(b)(ii)", + "4.2.63(2)", + "4.2.63(3)", + "4.2.63(3)(a)", + "4.2.63(3)(b)", + "4.2.63(3)(c)", + "4.2.64(1)", + "4.2.64(1)(a)", + "4.2.64(1)(b)", + "4.2.64(1)(b)(i)", + "4.2.64(1)(b)(ii)", + "4.2.64(2)", + "4.2.64(3)" + ], + "PRI-06.7": [ + "4.1.58(1)", + "4.1.58(1)(a)", + "4.1.58(1)(b)", + "4.1.58(1)(c)", + "4.1.58(1)(d)", + "4.1.58(1)(e)", + "4.1.58(1)(f)" + ], + "PRI-07": [ + "3.1.22.11(1)", + "3.1.22.11(1)(a)", + "3.1.22.11(1)(b)", + "3.1.22.11(1)(c)", + "3.1.22.11(1)(d)", + "3.1.22.11(1)(e)", + "3.1.22.11(1)(e)(i)", + "3.1.22.11(1)(e)(ii)", + "3.1.22.11(1)(e)(iii)", + "3.1.22.11(1)(e)(iv)", + "3.1.22.11(1)(f)", + "3.1.22.11(1)(f)(i)", + "3.1.22.11(1)(f)(ii)", + "3.1.22.11(1)(g)", + "3.1.22.11(1)(h)", + "3.1.22.11(1)(h)(i)", + "3.1.22.11(1)(h)(ii)", + "3.1.22.11(1)(i)" + ], + "PRI-07.3": [ + "3.1.22.7(5)" + ], + "PRI-07.4": [ + "4.1.46(1)" + ], + "PRI-07.5": [ + "4.1.46(2)", + "4.1.46(3)" + ], + "PRI-17": [ + "4.1.46(2)(a)", + "4.1.46(2)(b)", + "4.1.46(3)(a)", + "4.1.46(3)(b)" ] } }, "framework_to_scf": { - "total_mappings": 121, + "total_mappings": 160, "mappings": { - "P6-(2)": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2" + "6.2.126(1)": [ + "CPL-01" ], - "Principle 7": [ - "DCH-22.1", - "PRI-06.1" - ], - "P7-(1)": [ - "DCH-22.1", - "PRI-06.1" - ], - "P7-(2)": [ - "DCH-22.1", - "PRI-06.1" - ], - "P7-(3)(a)": [ - "DCH-22.1", - "PRI-06.1" - ], - "P7-(3)(b)": [ - "DCH-22.1", - "PRI-06.1" - ], - "P7-(4)": [ - "DCH-22.1", - "PRI-06.1" - ], - "P7-(5)": [ - "DCH-22.1", - "PRI-06.1" - ], - "P7-(6)": [ - "DCH-22.1", - "PRI-06.1" - ], - "Principle 12": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(1)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(1)(a)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(1)(b)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(1)(c)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(1)(d)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(1)(e)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(1)(f)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(2)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "P12-(3)": [ - "DCH-25", - "PRI-01.5", - "PRI-01.7" - ], - "Principle 13": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "P13-(1)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "P13-(2)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "P13-(2)(a)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "P13-(2)(b)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "P13-(3)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "P13-(4)(a)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "P13-(4)(b)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "P13-(5)": [ - "IAC-02", - "IAC-03", - "IAC-09.2" - ], - "Principle 5": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" - ], - "P5-(a)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" - ], - "P5-(a)(i)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" - ], - "P5-(a)(ii)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" - ], - "P5-(a)(iii)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" - ], - "P5-(b)": [ - "IAO-03.2", - "PRI-01.6", - "PRI-07.1" - ], - "Principle 11": [ - "PRI-01.7" - ], - "P11-(1)": [ - "PRI-01.7" - ], - "P11-(1)(a)": [ - "PRI-01.7" - ], - "P11-(1)(b)": [ - "PRI-01.7" - ], - "P11-(1)(c)": [ - "PRI-01.7" - ], - "P11-(1)(d)": [ - "PRI-01.7" - ], - "P11-(1)(e)(i)": [ - "PRI-01.7" - ], - "P11-(1)(e)(ii)": [ - "PRI-01.7" - ], - "P11-(1)(e)(iii)": [ - "PRI-01.7" - ], - "P11-(1)(e)(iv)": [ - "PRI-01.7" - ], - "P11-(1)(f)(i)": [ - "PRI-01.7" - ], - "P11-(1)(f)(ii)": [ - "PRI-01.7" - ], - "P11-(1)(g)": [ - "PRI-01.7" - ], - "P11-(1)(h)(i)": [ - "PRI-01.7" - ], - "P11-(1)(h)(ii)": [ - "PRI-01.7" - ], - "P11-(1)(i)": [ - "PRI-01.7" - ], - "P11-(2)": [ - "PRI-01.7" - ], - "Principle 3": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(a)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(b)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(c)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(d)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(d)(i)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(d)(ii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(e)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(e)(i)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(e)(ii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(f)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(1)(g)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(2)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(3)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(a)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(b)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(b)(i)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(b)(ii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(b)(iii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(b)(iv)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(c)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(d)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(e)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(e)(i)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "P3-(4)(e)(ii)": [ - "PRI-02", - "PRI-02.1", - "PRI-04" - ], - "Principle 1": [ - "PRI-04" - ], - "P1-(1)(a)": [ - "PRI-04" - ], - "P1-(1)(b)": [ - "PRI-04" - ], - "Principle 4": [ - "PRI-04" - ], - "P4-(a)": [ - "PRI-04" - ], - "P4-(b)": [ - "PRI-04" - ], - "P4-(b)(i)": [ - "PRI-04" - ], - "P4-(b)(ii)": [ - "PRI-04" - ], - "Principle 2": [ - "PRI-04.2" + "6.2.126(2)": [ + "CPL-01" ], - "P2-(1)": [ - "PRI-04.2" + "6.2.126(2)(a)": [ + "CPL-01" ], - "P2-(2)": [ - "PRI-04.2" + "6.2.126(2)(b)": [ + "CPL-01" ], - "P2-(2)(a)": [ - "PRI-04.2" + "3.1.22.7(4)": [ + "DCH-22.1" ], - "P2-(2)(b)": [ - "PRI-04.2" + "6.1.115(1)": [ + "IRO-10" ], - "P2-(2)(c)": [ - "PRI-04.2" + "6.1.115(2)": [ + "IRO-10" ], - "P2-(2)(d)": [ - "PRI-04.2" + "6.1.115(3)": [ + "IRO-10" ], - "P2-(2)(e)(i)": [ - "PRI-04.2" + "6.1.115(3)(a)": [ + "IRO-10" ], - "P2-(2)(e)(ii)": [ - "PRI-04.2" + "6.1.115(3)(b)": [ + "IRO-10" ], - "P2-(2)(e)(iii)": [ - "PRI-04.2" + "6.1.115(4)": [ + "IRO-10" ], - "P2-(2)(e)(iv)": [ - "PRI-04.2" + "6.1.115(4)(a)": [ + "IRO-10" ], - "P2-(2)(e)(v)": [ - "PRI-04.2" + "6.1.115(4)(b)": [ + "IRO-10" ], - "P2-(2)(f)": [ - "PRI-04.2" + "6.1.117(1)": [ + "IRO-10" ], - "P2-(2)(g)(i)": [ - "PRI-04.2" + "6.1.117(1)(a)": [ + "IRO-10" + ], + "6.1.117(1)(a)(i)": [ + "IRO-10" + ], + "6.1.117(1)(a)(ii)": [ + "IRO-10" + ], + "6.1.117(1)(b)": [ + "IRO-10" + ], + "6.1.117(1)(c)": [ + "IRO-10" + ], + "6.1.117(1)(d)": [ + "IRO-10" + ], + "6.1.117(1)(e)": [ + "IRO-10" + ], + "6.1.117(1)(f)": [ + "IRO-10" + ], + "6.1.117(2)": [ + "IRO-10" + ], + "6.1.117(2)(a)": [ + "IRO-10" + ], + "6.1.117(2)(b)": [ + "IRO-10" + ], + "6.1.117(2)(c)": [ + "IRO-10" + ], + "6.1.117(2)(d)": [ + "IRO-10" + ], + "6.1.117(2)(e)": [ + "IRO-10" + ], + "6.1.117(2)(f)": [ + "IRO-10" + ], + "6.1.117(3)": [ + "IRO-10" + ], + "6.1.117(4)": [ + "IRO-10" + ], + "6.1.117(5)": [ + "IRO-10" + ], + "3.1.22.12(1)": [ + "PRI-01.5" + ], + "3.1.22.12(1)(a)": [ + "PRI-01.5" + ], + "3.1.22.12(1)(b)": [ + "PRI-01.5" + ], + "3.1.22.12(1)(c)": [ + "PRI-01.5" ], - "P2-(2)(g)(ii)": [ + "3.1.22.12(1)(d)": [ + "PRI-01.5" + ], + "3.1.22.12(1)(e)": [ + "PRI-01.5" + ], + "3.1.22.12(1)(f)": [ + "PRI-01.5" + ], + "3.1.22.12(2)": [ + "PRI-01.5" + ], + "3.1.22.12(3)": [ + "PRI-01.5" + ], + "3.1.22.5(a)": [ + "PRI-01.6" + ], + "3.1.22.5(a)(i)": [ + "PRI-01.6" + ], + "3.1.22.5(a)(ii)": [ + "PRI-01.6" + ], + "3.1.22.5(a)(iii)": [ + "PRI-01.6" + ], + "3.1.22.4": [ + "PRI-01.11" + ], + "3.1.22.4(a)": [ + "PRI-01.11" + ], + "3.1.22.4(b)": [ + "PRI-01.11" + ], + "3.1.22.4(b)(i)": [ + "PRI-01.11" + ], + "3.1.22.4(b)(ii)": [ + "PRI-01.11" + ], + "3.1.22.5": [ + "PRI-01.11" + ], + "3.1.22.5(b)": [ + "PRI-01.11" + ], + "4.1.47(1)": [ + "PRI-01.11" + ], + "4.1.47(1)(a)": [ + "PRI-01.11" + ], + "4.1.47(1)(b)": [ + "PRI-01.11" + ], + "3.1.22.3(1)": [ + "PRI-02" + ], + "3.1.22.3(1)(a)": [ + "PRI-02" + ], + "3.1.22.3(1)(b)": [ + "PRI-02" + ], + "3.1.22.3(1)(c)": [ + "PRI-02" + ], + "3.1.22.3(1)(d)": [ + "PRI-02" + ], + "3.1.22.3(1)(d)(i)": [ + "PRI-02" + ], + "3.1.22.3(1)(d)(ii)": [ + "PRI-02" + ], + "3.1.22.3(1)(e)": [ + "PRI-02" + ], + "3.1.22.3(1)(e)(i)": [ + "PRI-02" + ], + "3.1.22.3(1)(e)(ii)": [ + "PRI-02" + ], + "3.1.22.3(1)(f)": [ + "PRI-02" + ], + "3.1.22.3(1)(g)": [ + "PRI-02" + ], + "4.1.45(1)": [ + "PRI-02" + ], + "4.1.45(1)(a)": [ + "PRI-02" + ], + "4.1.45(1)(b)": [ + "PRI-02" + ], + "4.1.45(1)(c)": [ + "PRI-02" + ], + "4.1.45(2)": [ + "PRI-02" + ], + "3.1.22.2(1)": [ "PRI-04.2" ], - "Principle 10": [ - "PRI-05.1", + "3.1.22.9": [ + "PRI-05" + ], + "3.1.22.8": [ + "PRI-05.2" + ], + "3.1.22.1(1)": [ "PRI-05.4" ], - "P10-(1)": [ - "PRI-05.1", + "3.1.22.1(1)(a)": [ "PRI-05.4" ], - "P10-(1)(a)": [ - "PRI-05.1", + "3.1.22.1(1)(b)": [ "PRI-05.4" ], - "P10-(1)(b)(i)": [ - "PRI-05.1", + "3.1.22.10(1)": [ "PRI-05.4" ], - "P10-(1)(b)(ii)": [ - "PRI-05.1", + "3.1.22.10(1)(a)": [ "PRI-05.4" ], - "P10-(1)(c)": [ - "PRI-05.1", + "3.1.22.10(1)(b)": [ "PRI-05.4" ], - "P10-(1)(d)": [ - "PRI-05.1", + "3.1.22.10(1)(b)(i)": [ "PRI-05.4" ], - "P10-(1)(e)(i)": [ - "PRI-05.1", + "3.1.22.10(1)(b)(ii)": [ "PRI-05.4" ], - "P10-(1)(e)(ii)": [ - "PRI-05.1", + "3.1.22.10(1)(c)": [ "PRI-05.4" ], - "P10-(1)(e)(iii)": [ - "PRI-05.1", + "3.1.22.10(1)(d)": [ "PRI-05.4" ], - "P10-(1)(e)(iv)": [ - "PRI-05.1", + "3.1.22.10(1)(e)": [ "PRI-05.4" ], - "P10-(1)(f)(i)": [ - "PRI-05.1", + "3.1.22.10(1)(e)(i)": [ "PRI-05.4" ], - "P10-(1)(f)(ii)": [ - "PRI-05.1", + "3.1.22.10(1)(e)(ii)": [ "PRI-05.4" ], - "P10-(2)": [ - "PRI-05.1", + "3.1.22.10(1)(e)(iii)": [ "PRI-05.4" ], - "Principle 9": [ - "PRI-05.2" + "3.1.22.10(1)(e)(iv)": [ + "PRI-05.4" + ], + "3.1.22.10(1)(f)": [ + "PRI-05.4" ], - "Principle 6": [ + "3.1.22.10(1)(f)(i)": [ + "PRI-05.4" + ], + "3.1.22.10(1)(f)(ii)": [ + "PRI-05.4" + ], + "3.1.22.6(1)": [ "PRI-06" ], - "P6-(1)": [ + "3.1.22.6(1)(a)": [ "PRI-06" ], - "P6-(1)(a)": [ + "3.1.22.6(1)(b)": [ "PRI-06" ], - "P6-(1)(b)": [ + "3.1.22.6(2)": [ "PRI-06" ], - "P6-(3)": [ + "3.1.22.7(1)": [ "PRI-06" + ], + "3.1.22.7(3)": [ + "PRI-06" + ], + "3.1.22.7(3)(a)": [ + "PRI-06" + ], + "4.2.59": [ + "PRI-06" + ], + "3.1.22.7(3)(b)": [ + "PRI-06.2" + ], + "3.1.22.7(2)": [ + "PRI-06.4" + ], + "4.1.44(1)": [ + "PRI-06.4" + ], + "4.1.44(2)": [ + "PRI-06.4" + ], + "4.1.44(2)(b)": [ + "PRI-06.4" + ], + "4.1.44(2)(c)": [ + "PRI-06.4" + ], + "4.1.44(2)(c)(i)": [ + "PRI-06.4" + ], + "4.1.44(2)(c)(ii)": [ + "PRI-06.4" + ], + "4.1.44(2)(d)": [ + "PRI-06.4" + ], + "4.2.63(1)": [ + "PRI-06.4" + ], + "4.2.63(1)(a)": [ + "PRI-06.4" + ], + "4.2.63(1)(b)": [ + "PRI-06.4" + ], + "4.2.63(1)(b)(i)": [ + "PRI-06.4" + ], + "4.2.63(1)(b)(ii)": [ + "PRI-06.4" + ], + "4.2.63(2)": [ + "PRI-06.4" + ], + "4.2.63(3)": [ + "PRI-06.4" + ], + "4.2.63(3)(a)": [ + "PRI-06.4" + ], + "4.2.63(3)(b)": [ + "PRI-06.4" + ], + "4.2.63(3)(c)": [ + "PRI-06.4" + ], + "4.2.64(1)": [ + "PRI-06.4" + ], + "4.2.64(1)(a)": [ + "PRI-06.4" + ], + "4.2.64(1)(b)": [ + "PRI-06.4" + ], + "4.2.64(1)(b)(i)": [ + "PRI-06.4" + ], + "4.2.64(1)(b)(ii)": [ + "PRI-06.4" + ], + "4.2.64(2)": [ + "PRI-06.4" + ], + "4.2.64(3)": [ + "PRI-06.4" + ], + "4.1.58(1)": [ + "PRI-06.7" + ], + "4.1.58(1)(a)": [ + "PRI-06.7" + ], + "4.1.58(1)(b)": [ + "PRI-06.7" + ], + "4.1.58(1)(c)": [ + "PRI-06.7" + ], + "4.1.58(1)(d)": [ + "PRI-06.7" + ], + "4.1.58(1)(e)": [ + "PRI-06.7" + ], + "4.1.58(1)(f)": [ + "PRI-06.7" + ], + "3.1.22.11(1)": [ + "PRI-07" + ], + "3.1.22.11(1)(a)": [ + "PRI-07" + ], + "3.1.22.11(1)(b)": [ + "PRI-07" + ], + "3.1.22.11(1)(c)": [ + "PRI-07" + ], + "3.1.22.11(1)(d)": [ + "PRI-07" + ], + "3.1.22.11(1)(e)": [ + "PRI-07" + ], + "3.1.22.11(1)(e)(i)": [ + "PRI-07" + ], + "3.1.22.11(1)(e)(ii)": [ + "PRI-07" + ], + "3.1.22.11(1)(e)(iii)": [ + "PRI-07" + ], + "3.1.22.11(1)(e)(iv)": [ + "PRI-07" + ], + "3.1.22.11(1)(f)": [ + "PRI-07" + ], + "3.1.22.11(1)(f)(i)": [ + "PRI-07" + ], + "3.1.22.11(1)(f)(ii)": [ + "PRI-07" + ], + "3.1.22.11(1)(g)": [ + "PRI-07" + ], + "3.1.22.11(1)(h)": [ + "PRI-07" + ], + "3.1.22.11(1)(h)(i)": [ + "PRI-07" + ], + "3.1.22.11(1)(h)(ii)": [ + "PRI-07" + ], + "3.1.22.11(1)(i)": [ + "PRI-07" + ], + "3.1.22.7(5)": [ + "PRI-07.3" + ], + "4.1.46(1)": [ + "PRI-07.4" + ], + "4.1.46(2)": [ + "PRI-07.5" + ], + "4.1.46(3)": [ + "PRI-07.5" + ], + "4.1.46(2)(a)": [ + "PRI-17" + ], + "4.1.46(2)(b)": [ + "PRI-17" + ], + "4.1.46(3)(a)": [ + "PRI-17" + ], + "4.1.46(3)(b)": [ + "PRI-17" ] } } diff --git a/docs/api/crosswalks/apac-phl-dpa-2012.json b/docs/api/crosswalks/apac-phl-dpa-2012.json index 66879025..3d8c6b85 100644 --- a/docs/api/crosswalks/apac-phl-dpa-2012.json +++ b/docs/api/crosswalks/apac-phl-dpa-2012.json @@ -2,192 +2,296 @@ "framework_id": "apac-phl-dpa-2012", "display_name": "Philippines - Data Privacy Act (DPA) (2012)", "scf_to_framework": { - "total_mappings": 30, + "total_mappings": 16, "mappings": { - "GOV-01": [ - "25", - "27", - "28" - ], "CPL-01": [ - "25" - ], - "CPL-02": [ - "25", - "29" - ], - "CPL-03": [ - "25" - ], - "DCH-01": [ - "25" - ], - "DCH-22.1": [ - "34" + "III.11" ], - "DCH-24": [ - "25" - ], - "DCH-24.1": [ - "25" - ], - "IRO-04.1": [ - "38" + "IRO-10.2": [ + "V.20(f)" ], "PRI-01": [ - "Inferred", - "Expectation" + "III.11" + ], + "PRI-01.1": [ + "VI.21", + "VI.21(a)", + "VI.21(b)" + ], + "PRI-01.6": [ + "V.20(a)", + "V.20(b)", + "V.20(c)", + "V.20(c)(1)", + "V.20(c)(2)", + "V.20(c)(3)", + "V.20(c)(4)", + "V.20(d)", + "V.20(e)" + ], + "PRI-01.11": [ + "III.11", + "III.11(b)", + "III.11(d)" ], "PRI-02.1": [ - "19" + "III.12" ], "PRI-03": [ - "19" - ], - "PRI-04": [ - "19" + "III.12(a)" ], - "PRI-04.1": [ - "19" + "PRI-03.6": [ + "IV.17" ], "PRI-05": [ - "19", - "21" + "III.11(e)", + "III.11(f)" ], "PRI-05.1": [ - "19" + "IV.19" + ], + "PRI-05.2": [ + "III.11(c)" ], "PRI-05.4": [ - "19", - "22", - "34" + "III.11(a)", + "III.11(c)", + "III.12(b)", + "III.12(c)", + "III.12(d)", + "III.12(e)", + "III.12(f)", + "III.13", + "III.13(a)", + "III.13(b)", + "III.13(c)", + "III.13(d)", + "III.13(e)", + "III.13(f)" ], "PRI-06": [ - "34" + "IV.16", + "IV.16(a)", + "IV.16(b)", + "IV.16(b)(1)", + "IV.16(b)(2)", + "IV.16(b)(3)", + "IV.16(b)(4)", + "IV.16(b)(5)", + "IV.16(b)(6)", + "IV.16(b)(7)", + "IV.16(b)(8)", + "IV.16(c)", + "IV.16(c)(1)", + "IV.16(c)(2)", + "IV.16(c)(3)", + "IV.16(c)(4)", + "IV.16(c)(5)", + "IV.16(c)(6)", + "IV.16(c)(7)", + "IV.16(c)(8)", + "IV.16(d)", + "IV.16(e)", + "IV.16(f)" + ], + "PRI-06.6": [ + "IV.18" + ], + "PRI-07.1": [ + "III.14", + "V.20(d)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 61, + "mappings": { + "III.11": [ + "CPL-01", + "PRI-01", + "PRI-01.11" ], - "PRI-06.1": [ - "34" + "V.20(f)": [ + "IRO-10.2" ], - "PRI-06.2": [ - "34" + "VI.21": [ + "PRI-01.1" ], - "PRI-06.3": [ - "34" + "VI.21(a)": [ + "PRI-01.1" ], - "PRI-14.1": [ - "20" + "VI.21(b)": [ + "PRI-01.1" ], - "PRI-15": [ - "46", - "47", - "48" + "V.20(a)": [ + "PRI-01.6" ], - "SEA-01": [ - "25", - "29" + "V.20(b)": [ + "PRI-01.6" ], - "SEA-02": [ - "25", - "29" + "V.20(c)": [ + "PRI-01.6" ], - "SEA-03": [ - "25", - "29" + "V.20(c)(1)": [ + "PRI-01.6" ], - "SEA-15": [ - "25" + "V.20(c)(2)": [ + "PRI-01.6" ], - "TPM-03": [ - "25", - "43" + "V.20(c)(3)": [ + "PRI-01.6" ], - "TPM-04.4": [ - "25" + "V.20(c)(4)": [ + "PRI-01.6" ], - "TPM-05": [ - "25", - "43" - ] - } - }, - "framework_to_scf": { - "total_mappings": 16, - "mappings": { - "19": [ - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.4" + "V.20(d)": [ + "PRI-01.6", + "PRI-07.1" + ], + "V.20(e)": [ + "PRI-01.6" + ], + "III.11(b)": [ + "PRI-01.11" + ], + "III.11(d)": [ + "PRI-01.11" ], - "20": [ - "PRI-14.1" + "III.12": [ + "PRI-02.1" ], - "21": [ + "III.12(a)": [ + "PRI-03" + ], + "IV.17": [ + "PRI-03.6" + ], + "III.11(e)": [ "PRI-05" ], - "22": [ + "III.11(f)": [ + "PRI-05" + ], + "IV.19": [ + "PRI-05.1" + ], + "III.11(c)": [ + "PRI-05.2", "PRI-05.4" ], - "25": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-03", - "TPM-04.4", - "TPM-05" - ], - "27": [ - "GOV-01" - ], - "28": [ - "GOV-01" - ], - "29": [ - "CPL-02", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "34": [ - "DCH-22.1", - "PRI-05.4", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3" - ], - "38": [ - "IRO-04.1" - ], - "43": [ - "TPM-03", - "TPM-05" - ], - "46": [ - "PRI-15" - ], - "47": [ - "PRI-15" - ], - "48": [ - "PRI-15" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" + "III.11(a)": [ + "PRI-05.4" + ], + "III.12(b)": [ + "PRI-05.4" + ], + "III.12(c)": [ + "PRI-05.4" + ], + "III.12(d)": [ + "PRI-05.4" + ], + "III.12(e)": [ + "PRI-05.4" + ], + "III.12(f)": [ + "PRI-05.4" + ], + "III.13": [ + "PRI-05.4" + ], + "III.13(a)": [ + "PRI-05.4" + ], + "III.13(b)": [ + "PRI-05.4" + ], + "III.13(c)": [ + "PRI-05.4" + ], + "III.13(d)": [ + "PRI-05.4" + ], + "III.13(e)": [ + "PRI-05.4" + ], + "III.13(f)": [ + "PRI-05.4" + ], + "IV.16": [ + "PRI-06" + ], + "IV.16(a)": [ + "PRI-06" + ], + "IV.16(b)": [ + "PRI-06" + ], + "IV.16(b)(1)": [ + "PRI-06" + ], + "IV.16(b)(2)": [ + "PRI-06" + ], + "IV.16(b)(3)": [ + "PRI-06" + ], + "IV.16(b)(4)": [ + "PRI-06" + ], + "IV.16(b)(5)": [ + "PRI-06" + ], + "IV.16(b)(6)": [ + "PRI-06" + ], + "IV.16(b)(7)": [ + "PRI-06" + ], + "IV.16(b)(8)": [ + "PRI-06" + ], + "IV.16(c)": [ + "PRI-06" + ], + "IV.16(c)(1)": [ + "PRI-06" + ], + "IV.16(c)(2)": [ + "PRI-06" + ], + "IV.16(c)(3)": [ + "PRI-06" + ], + "IV.16(c)(4)": [ + "PRI-06" + ], + "IV.16(c)(5)": [ + "PRI-06" + ], + "IV.16(c)(6)": [ + "PRI-06" + ], + "IV.16(c)(7)": [ + "PRI-06" + ], + "IV.16(c)(8)": [ + "PRI-06" + ], + "IV.16(d)": [ + "PRI-06" + ], + "IV.16(e)": [ + "PRI-06" + ], + "IV.16(f)": [ + "PRI-06" + ], + "IV.18": [ + "PRI-06.6" + ], + "III.14": [ + "PRI-07.1" ] } } diff --git a/docs/api/crosswalks/apac-sgp-cyber-hygiene-practice-2019.json b/docs/api/crosswalks/apac-sgp-cyber-hygiene-practice-2019.json index 8162fbf3..7cac3dfa 100644 --- a/docs/api/crosswalks/apac-sgp-cyber-hygiene-practice-2019.json +++ b/docs/api/crosswalks/apac-sgp-cyber-hygiene-practice-2019.json @@ -2,31 +2,17 @@ "framework_id": "apac-sgp-cyber-hygiene-practice-2019", "display_name": "Singapore - Cyber Hygiene Practice (2019)", "scf_to_framework": { - "total_mappings": 21, + "total_mappings": 17, "mappings": { - "CPL-01": [ - "3.1(a)", - "3.1(b)", - "3.1(c)" - ], - "CFG-01": [ + "GOV-02": [ "4.3(a)" ], "CFG-02": [ - "4.3(a)" - ], - "CFG-02.2": [ "4.3(a)", "4.3(b)" ], - "CFG-02.7": [ - "4.3(c)" - ], - "END-01": [ - "4.5" - ], - "END-02": [ - "4.5" + "CFG-06": [ + "4.3(b)" ], "END-04": [ "4.5" @@ -35,103 +21,89 @@ "4.1" ], "IAC-06": [ + "4.6", "4.6(b)" ], "IAC-06.1": [ "4.6(a)" ], - "IAC-06.3": [ - "4.6(a)" + "IAC-06.2": [ + "4.6(b)" + ], + "IAC-15": [ + "4.1" ], "IAC-16": [ "4.1" ], + "IAO-03": [ + "4.3(a)" + ], "NET-01": [ "4.4" ], - "NET-02": [ + "NET-03": [ "4.4" ], - "NET-03": [ + "NET-04.1": [ "4.4" ], "RSK-06.2": [ "4.2(b)", "4.3(c)" ], - "VPM-01": [ - "4.2(a)", - "4.2(b)" - ], "VPM-02": [ - "4.2(a)", - "4.2(b)" + "4.2(a)" ], "VPM-05": [ - "4.2(a)", - "4.2(b)" - ], - "VPM-05.4": [ "4.2(a)" ] } }, "framework_to_scf": { - "total_mappings": 13, + "total_mappings": 11, "mappings": { - "3.1(a)": [ - "CPL-01" - ], - "3.1(b)": [ - "CPL-01" - ], - "3.1(c)": [ - "CPL-01" - ], "4.3(a)": [ - "CFG-01", + "GOV-02", "CFG-02", - "CFG-02.2" + "IAO-03" ], "4.3(b)": [ - "CFG-02.2" - ], - "4.3(c)": [ - "CFG-02.7", - "RSK-06.2" + "CFG-02", + "CFG-06" ], "4.5": [ - "END-01", - "END-02", "END-04" ], "4.1": [ "IAC-01", + "IAC-15", "IAC-16" ], - "4.6(b)": [ + "4.6": [ "IAC-06" ], + "4.6(b)": [ + "IAC-06", + "IAC-06.2" + ], "4.6(a)": [ - "IAC-06.1", - "IAC-06.3" + "IAC-06.1" ], "4.4": [ "NET-01", - "NET-02", - "NET-03" + "NET-03", + "NET-04.1" ], "4.2(b)": [ - "RSK-06.2", - "VPM-01", - "VPM-02", - "VPM-05" + "RSK-06.2" + ], + "4.3(c)": [ + "RSK-06.2" ], "4.2(a)": [ - "VPM-01", "VPM-02", - "VPM-05", - "VPM-05.4" + "VPM-05" ] } } diff --git a/docs/api/crosswalks/apac-sgp-mas-trm-2021.json b/docs/api/crosswalks/apac-sgp-mas-trm-2021.json index a6c8be3e..4eacb24b 100644 --- a/docs/api/crosswalks/apac-sgp-mas-trm-2021.json +++ b/docs/api/crosswalks/apac-sgp-mas-trm-2021.json @@ -2,70 +2,103 @@ "framework_id": "apac-sgp-mas-trm-2021", "display_name": "Singapore - Monitory Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines (2021)", "scf_to_framework": { - "total_mappings": 214, + "total_mappings": 219, "mappings": { + "GOV-01": [ + "3.1.4" + ], "GOV-01.1": [ "3.1.1", "3.1.2", - "3.1.3", - "3.1.4", "3.1.5", - "3.1.6", + "3.1.7", "3.1.7(a)", "3.1.7(b)", "3.1.7(c)", "3.1.7(d)", "3.1.7(e)", "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", + "3.1.7(g)" + ], + "GOV-01.2": [ + "3.1.3", "3.1.8(e)" ], "GOV-02": [ - "3.2.1" + "3.1.8(c)", + "3.2.1", + "3.3.1(d)", + "5.3.1", + "6.1.3", + "6.4.4", + "11.1.1" + ], + "GOV-02.1": [ + "3.2.2", + "7.3.3" ], "GOV-03": [ - "3.2.2" + "3.2.1" ], "GOV-04": [ - "3.1.7(a)", - "3.1.7(b)", + "3.1.3", + "3.1.8" + ], + "GOV-04.1": [ "3.1.7(c)", - "3.1.7(d)", - "3.1.7(e)", - "3.1.7(f)", - "3.1.7(g)", + "3.1.8", "3.1.8(a)", "3.1.8(b)", "3.1.8(c)", "3.1.8(d)", "3.1.8(e)" ], + "GOV-04.2": [ + "3.1.7(c)" + ], "GOV-05": [ - "4.5.3", - "7.8.3" + "4.5.3" + ], + "GOV-14": [ + "3.1.6", + "4.1.2" + ], + "GOV-15": [ + "4.1.2" + ], + "GOV-18": [ + "5.8.1", + "5.8.2" ], "AST-01": [ - "3.3.1", + "3.3.1" + ], + "AST-01.1": [ "3.3.1(a)", - "3.3.1(d)", - "7.1.1", - "11.4.1", - "11.4.2", - "11.4.3" + "8.1.2" ], "AST-01.2": [ "3.3.1(c)" ], + "AST-01.4": [ + "3.3.1(a)", + "6.5.1" + ], "AST-02": [ "3.3.1(a)", - "3.3.2" + "3.3.2", + "11.5.1" + ], + "AST-02.4": [ + "3.2.2" ], "AST-02.5": [ - "11.2.4" + "11.2.4", + "11.2.5", + "11.5.4" + ], + "AST-04": [ + "8.1.2" ], "AST-09": [ "11.1.7" @@ -73,274 +106,246 @@ "AST-16": [ "11.3.7" ], - "AST-23": [ - "11.5.1" - ], "BCD-01": [ - "8.1.1", - "8.1.2", - "8.1.3", - "8.1.4", - "8.2.1", - "8.2.2", - "8.2.3", - "8.2.4", - "8.5.1", - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" + "8.1.1" + ], + "BCD-01.2": [ + "8.3.4" ], "BCD-01.4": [ - "8.1.4", "8.2.1" ], - "BCD-02": [ - "8.1.2" + "BCD-01.7": [ + "8.2.2", + "8.2.3" + ], + "BCD-03.1": [ + "13.5.1", + "13.5.2" ], "BCD-04": [ - "8.2.3", + "8.2.4", "8.3.1", "8.3.2", + "8.3.3", "8.3.3(a)", "8.3.3(b)", - "8.3.4" - ], - "BCD-04.1": [ - "8.3.4" + "13.5.2" ], "BCD-04.2": [ - "8.2.4" - ], - "BCD-05": [ - "7.8.1", - "7.8.2", - "7.8.3" + "8.5.2", + "8.5.2(a)", + "8.5.2(b)", + "8.5.4" ], "BCD-11": [ "8.4.1", "8.4.2" ], - "BCD-11.1": [ - "8.4.3" + "BCD-11.2": [ + "8.4.4" + ], + "BCD-11.3": [ + "11.4.3" ], "BCD-11.4": [ "8.4.4" ], + "BCD-11.5": [ + "8.4.3" + ], + "BCD-11.7": [ + "8.1.2", + "8.5.2(c)" + ], + "BCD-11.9": [ + "11.4.3" + ], "CAP-01": [ - "8.1.1" + "6.4.8" ], - "CAP-03": [ + "CAP-02": [ + "6.4.8" + ], + "CAP-04": [ "8.1.3" ], + "CAP-05": [ + "8.1.4" + ], "CHG-01": [ - "7.5.1", + "7.5.1" + ], + "CHG-02": [ "7.5.2", - "7.5.3", - "7.5.4", - "7.5.5", - "7.5.6", - "7.5.7" + "7.5.4" ], "CHG-02.1": [ - "7.5.4" + "7.5.2" ], "CHG-02.2": [ - "7.4.2", "7.5.3", "7.5.5", "7.5.7" ], - "CHG-02.3": [ - "7.5.4" - ], "CHG-03": [ "7.5.2" ], - "CHG-06": [ - "7.5.5" + "CHG-04.3": [ + "9.1.1" + ], + "CHG-04.5": [ + "7.6.2" ], - "CPL-01": [ - "3.2.3" + "CHG-07": [ + "7.5.6" ], - "CPL-01.1": [ - "3.2.3", - "4.5.2", - "4.5.3" + "CLD-04": [ + "6.4.1", + "6.4.4" + ], + "CLD-05": [ + "11.4.3" + ], + "CPL-01.6": [ + "15.1.4" ], "CPL-02": [ - "3.2.3" + "3.2.3", + "15.1.1" ], "CPL-02.1": [ "15.1.1", - "15.1.2", - "15.1.3", - "15.1.4" + "15.1.2" + ], + "CPL-02.2": [ + "15.1.3" ], "CPL-03": [ - "4.5.1" + "4.5.1", + "9.1.6", + "11.2.8" ], "CPL-03.2": [ - "4.5.1" + "4.5.1", + "11.2.8" ], "CFG-01": [ - "7.2.1", - "7.2.2", - "7.3.1", - "7.3.2", - "7.3.3" + "7.2.1" ], "CFG-02": [ - "11.2.5", - "11.3.1", - "11.3.2" - ], - "CFG-02.1": [ - "11.2.5" + "6.4.4", + "7.2.2", + "11.1.5", + "11.3.1" ], "CFG-02.2": [ + "7.2.2", "11.3.2" ], - "CFG-02.4": [ - "5.7.3" + "CFG-02.7": [ + "11.3.2" + ], + "CFG-03": [ + "11.2.6" ], "CFG-03.3": [ "11.3.6" ], + "CFG-04": [ + "6.1.3" + ], "CFG-04.1": [ "6.1.3" ], "MON-01": [ - "12.2.1", - "12.2.2", - "12.2.3" + "6.4.7", + "12.2.1" ], - "MON-01.8": [ + "MON-01.2": [ + "6.4.7", + "7.7.4", "12.2.2" ], - "MON-01.16": [ - "12.2.1", - "12.2.2", - "12.2.3" + "MON-01.8": [ + "12.2.6" ], - "MON-02": [ - "9.1.3" + "MON-01.15": [ + "7.6.2" ], "MON-02.1": [ "12.2.5" ], - "MON-02.2": [ - "12.2.6" - ], - "MON-03.2": [ - "9.2.2" - ], - "MON-06": [ - "12.2.6" - ], - "MON-09": [ - "14.2.1", - "14.2.2", - "14.2.3", - "14.2.4", - "14.2.5", - "14.2.6", - "14.2.7", - "14.2.8", - "14.2.9", - "14.2.10", - "14.2.11" + "MON-08": [ + "12.2.2" ], "MON-11.3": [ "11.3.5" ], "MON-16": [ - "9.2.2", "11.5.5", + "12.2.3", "12.2.4" ], - "MON-16.1": [ - "3.5.2" - ], "CRY-01": [ + "6.4.5", "10.1.1", - "10.1.2", "10.1.3", - "10.1.4", + "10.1.4" + ], + "CRY-01.5": [ + "10.1.2", "10.1.5" ], + "CRY-05": [ + "11.1.3" + ], "CRY-09": [ + "6.4.5", "10.2.1", "10.2.2", "10.2.3", "10.2.4", "10.2.5", "10.2.6", - "10.2.7", "10.2.8", - "10.2.9", "10.2.10" ], - "CRY-09.4": [ - "10.2.5" + "CRY-09.3": [ + "10.2.7", + "10.2.9" ], "DCH-01": [ "11.1.1", + "11.1.2" + ], + "DCH-01.2": [ "11.1.1(a)", "11.1.1(b)", "11.1.1(c)", - "11.1.2", - "11.1.3", - "11.1.4", - "11.1.5", - "11.1.6", - "11.1.7" + "11.1.6" ], - "DCH-01.1": [ - "3.3.1(c)" + "DCH-01.4": [ + "11.1.6" ], "DCH-02": [ "3.3.1(b)" ], - "DCH-08": [ - "11.1.7" - ], "DCH-09": [ "11.1.7" ], - "DCH-21": [ - "11.1.7" - ], - "DCH-22": [ - "5.8.1", - "5.8.2" + "DCH-13.2": [ + "11.1.4" ], "EMB-01": [ "11.5.1", "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" - ], - "EMB-02": [ - "11.5.1", - "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" - ], - "EMB-05": [ - "11.5.5" + "11.5.3" ], - "END-01": [ - "11.3.1", - "11.3.2", - "11.3.3", - "11.3.4", - "11.3.5", - "11.4.1", - "11.4.2", - "11.4.3" + "END-02": [ + "11.1.3", + "11.1.4", + "11.1.5" ], "END-04": [ "11.3.3" @@ -348,19 +353,17 @@ "END-04.1": [ "11.3.4" ], - "END-04.3": [ - "11.3.5" - ], - "END-08": [ - "14.1.6" + "END-15": [ + "11.4.2" ], "HRS-01": [ - "3.5.1", - "3.5.2" + "3.5.1" ], - "HRS-02.1": [ - "3.5.2", - "6.1.5" + "HRS-02": [ + "3.5.1" + ], + "HRS-03": [ + "3.5.1" ], "HRS-03.2": [ "3.5.1", @@ -372,547 +375,332 @@ "HRS-04.1": [ "3.5.2" ], + "HRS-05.3": [ + "11.1.5" + ], "HRS-11": [ + "6.3.2", + "7.6.1", "9.1.1" ], "IAC-01": [ - "9.1.2", - "9.1.3", - "9.1.8" + "9.1.8", + "9.2.2" ], - "IAC-05": [ - "9.1.8" + "IAC-01.1": [ + "9.1.3" ], "IAC-06": [ "9.1.5" ], + "IAC-07": [ + "9.1.2" + ], "IAC-08": [ - "9.1.7", - "11.1.6" + "9.1.7" ], "IAC-10.1": [ "9.1.4" ], + "IAC-15": [ + "9.1.8" + ], + "IAC-15.1": [ + "9.2.2" + ], "IAC-16": [ "9.2.1" ], - "IAC-17": [ - "9.1.6" - ], "IAC-21": [ - "9.1.1" + "9.1.7" ], "IRO-01": [ "7.7.1", - "7.7.2", - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "7.7.4", - "7.7.5", - "7.7.6", - "7.7.7" + "7.7.2" ], "IRO-02": [ + "7.7.2", + "7.7.3", "7.7.3(a)", "7.7.3(b)", "7.7.3(c)" ], + "IRO-03": [ + "11.3.5" + ], "IRO-04": [ - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "12.3.1", - "12.3.2", + "12.3.1" + ], + "IRO-04.3": [ + "7.8.3", "12.3.3" ], - "IRO-07": [ - "7.7.5" + "IRO-06": [ + "13.3.1", + "13.3.2", + "13.5.2" ], - "IRO-09": [ - "7.7.5" + "IRO-07": [ + "7.7.5", + "7.7.6" ], "IRO-10": [ "7.7.5", - "7.7.6", "7.7.7" ], "IRO-13": [ "7.8.1", "7.8.2", - "7.8.3", - "12.3.3" - ], - "IRO-16": [ - "7.7.5", - "7.7.6", - "7.7.7" + "12.3.2" ], "IAO-01": [ - "5.1.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.6.1", + "4.5.1", "5.6.2", - "5.6.3", "5.7.1", - "5.7.2" + "6.1.6", + "6.1.7", + "6.4.6", + "6.5.3" ], "IAO-01.1": [ - "5.7.1", - "5.7.2" + "4.5.1", + "5.6.2", + "6.1.6", + "6.4.6" ], "IAO-02": [ - "5.7.1", - "5.7.2" + "4.5.1", + "5.6.2", + "6.1.6" ], "IAO-02.2": [ - "5.7.4" - ], - "IAO-02.4": [ - "5.7.6" - ], - "IAO-03.2": [ - "5.4.3" + "5.3.3", + "5.6.3", + "6.1.6", + "6.4.6" ], "IAO-04": [ "5.7.5" ], - "IAO-05": [ - "4.5.2" - ], - "MDM-04": [ - "14.1.7" - ], - "MDM-06": [ - "14.1.7" + "IAO-06": [ + "5.7.6" ], - "MDM-07": [ - "14.1.7" + "IAO-07": [ + "5.7.6" ], "NET-01": [ - "11.2.1", - "11.2.2", - "11.2.3", - "11.2.4", - "11.2.5", - "11.2.6", - "11.2.7", - "11.2.8" - ], - "NET-02.1": [ - "11.2.7" + "11.2.1" ], "NET-03": [ - "11.2.5", - "11.2.6" + "11.2.1" ], - "NET-03.7": [ - "11.2.6" - ], - "NET-04.6": [ - "11.2.5" + "NET-03.6": [ + "11.5.5" ], "NET-06": [ - "11.2.6" + "11.2.2" ], "NET-08": [ - "11.2.3", - "11.2.4" + "11.2.3" ], "NET-14": [ "9.3.1", "9.3.2" ], - "NET-14.5": [ - "9.3.1", - "9.3.2" + "NET-17": [ + "11.1.1" + ], + "NET-18": [ + "11.2.7" ], "PES-01": [ - "8.5.1", - "8.5.2", "8.5.5", - "8.5.6(a)", - "8.5.6(b)", - "8.5.6(c)", - "8.5.6(d)", - "8.5.6(e)", - "8.5.6(f)" + "8.5.6" ], "PES-02": [ "8.5.6(a)" ], "PES-03": [ - "8.5.6(c)", - "5.5.6(f)" + "8.5.6(e)" ], "PES-03.1": [ - "5.5.6(f)" - ], - "PES-03.2": [ - "8.5.6(d)" + "8.5.6(c)" ], "PES-03.4": [ "8.5.6(d)" ], - "PES-04": [ - "8.5.6(e)" - ], - "PES-04.1": [ - "8.5.6(e)", - "5.5.6(f)" - ], - "PES-05": [ - "5.5.5" - ], - "PES-05.2": [ - "8.5.5" - ], "PES-06": [ - "8.5.6(b)", - "5.5.6(f)" - ], - "PES-07": [ - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" + "8.5.6(b)" ], "PES-08": [ - "8.5.3", - "8.5.4" + "8.5.3" ], "PES-08.1": [ - "8.5.3", - "8.5.4" + "8.5.3" ], - "PES-10": [ - "5.5.6(f)" + "PES-08.2": [ + "8.5.3" ], - "PRI-01.6": [ - "14.1.1", - "14.1.2", - "14.1.3", - "14.1.4", - "14.1.5", - "14.1.6", - "14.1.7" + "PES-10": [ + "8.5.6(f)" ], - "PRI-05": [ - "11.1.7" + "PRI-02": [ + "14.4.1" ], "PRM-01": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4" - ], - "PRM-01.1": [ - "3.1.4", - "3.1.5" + "5.2.1", + "5.2.2" ], "PRM-02": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.5.1", - "5.5.2" + "5.1.4" ], "PRM-03": [ - "5.2.1", - "5.2.2" + "5.1.4" ], "PRM-04": [ "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.8.1", - "5.8.2" + "5.1.3" ], "PRM-05": [ - "5.1.1", "5.1.2", - "5.1.3", - "5.1.4", - "5.3.3", - "5.5.1", - "5.5.2", - "5.6.1", - "5.6.2", - "5.6.3" + "5.4.2", + "5.4.3", + "5.5.1" ], "PRM-06": [ - "5.5.1", - "5.5.2" + "5.1.2", + "5.5.1" ], "PRM-07": [ "5.1.2", - "5.1.3", - "5.1.4", "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4" + "5.4.4", + "5.5.2", + "5.8.1" ], "RSK-01": [ + "3.1.4", + "3.1.7(a)", "4.1.1", - "4.1.2", + "4.1.4", + "4.1.4(d)", "4.1.5" ], "RSK-01.1": [ - "4.2.1", - "4.3.2" - ], - "RSK-02": [ "4.2.1" ], - "RSK-02.1": [ - "4.2.1", - "4.3.1", - "4.3.2" + "RSK-01.3": [ + "3.1.7(d)", + "4.4.2" + ], + "RSK-01.4": [ + "4.4.2" + ], + "RSK-01.5": [ + "3.1.5", + "3.1.7(d)" ], "RSK-03": [ - "4.1.3", - "4.1.4(a)" + "4.1.4(a)", + "4.2.1" + ], + "RSK-03.1": [ + "4.2.1" + ], + "RSK-03.2": [ + "4.1.3" ], "RSK-04": [ "4.1.4(b)", - "4.3.2" + "4.3.1", + "8.5.1" ], "RSK-04.1": [ - "4.1.3", - "4.1.4(d)", - "4.5.2", - "4.5.3" + "4.5.2" ], - "RSK-05": [ - "4.2.1" + "RSK-04.2": [ + "4.1.4(d)" + ], + "RSK-04.3": [ + "4.1.4(d)" ], "RSK-06": [ - "4.1.3", "4.1.4(c)", - "4.4.1", - "4.4.2", - "4.4.3", - "13.6.1", - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" - ], - "RSK-06.1": [ - "4.1.5", - "4.5.3" + "4.4.1" ], "RSK-06.2": [ - "4.2.1", + "4.4.1" + ], + "RSK-06.3": [ + "4.1.3", + "4.1.4(c)", "4.4.2", "4.4.3" ], - "RSK-07": [ - "4.1.5" - ], - "RSK-08": [ - "5.1.3", - "5.3.3" - ], - "RSK-09": [ - "5.3.1" - ], - "RSK-10": [ - "5.1.3", - "5.3.3" - ], "SEA-01": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "SEA-01.1": [ - "4.5.1" - ], - "SEA-02": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "SEA-03": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" + "14.1.1", + "14.2.10" ], "SEA-07.1": [ - "7.3.1", - "7.3.2", - "7.3.3" + "7.3.2" ], - "OPS-01": [ - "7.1.1" + "SEA-13.1": [ + "11.4.1" ], "OPS-03": [ "7.1.1" ], - "OPS-04": [ - "12.2.1" + "OPS-07": [ + "6.5.1", + "6.5.2" ], "SAT-01": [ - "3.6.1", - "3.6.4", - "6.1.5" + "3.1.6" + ], + "SAT-01.1": [ + "3.6.4" ], "SAT-02": [ "3.6.1" ], "SAT-03": [ + "3.6.1", "3.6.2", - "3.6.3", - "6.1.5" - ], - "SAT-03.2": [ - "9.2.2", - "11.5.5", - "12.2.4" + "3.6.3" ], "SAT-03.3": [ - "3.6.2", - "3.6.3", - "6.1.5" + "3.6.1" + ], + "SAT-03.6": [ + "12.1.3" ], - "SAT-03.5": [ + "SAT-03.8": [ "6.1.5" ], "TDA-01": [ - "5.3.1", - "5.3.2", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "5.3.2" ], "TDA-01.1": [ - "5.8.1", - "5.8.2", - "7.6.1", - "7.6.2", - "14.4.1", - "14.4.2", - "14.4.3" - ], - "TDA-02": [ - "5.3.3" - ], - "TDA-02.3": [ - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7" + "5.5.2", + "14.1.5", + "14.1.7" ], - "TDA-03": [ - "5.3.3", - "6.1.3" + "TDA-01.4": [ + "6.3.1" ], - "TDA-04": [ - "6.1.4" + "TDA-02": [ + "5.4.3", + "5.5.2" ], - "TDA-05": [ - "6.1.5", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "TDA-02.10": [ + "5.6.1", + "5.7.2" ], "TDA-06": [ - "5.3.2", - "6.1.1", - "6.1.2", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" - ], - "TDA-06.3": [ "6.1.1", "6.1.2", "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3", - "7.6.1", - "7.6.2" - ], - "TDA-06.5": [ - "5.7.4", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.6", - "6.1.7" + "6.2.2" ], "TDA-07": [ "5.7.3" @@ -921,22 +709,11 @@ "5.7.3" ], "TDA-09": [ - "5.7.1", - "5.7.2", - "5.7.3", "5.7.4", "5.7.5", - "5.7.6", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", "6.1.6", "6.1.7" ], - "TDA-09.1": [ - "6.1.4" - ], "TDA-09.2": [ "6.1.6" ], @@ -946,112 +723,94 @@ "TDA-09.4": [ "6.1.6" ], - "TDA-09.5": [ - "6.1.6" - ], - "TDA-10": [ - "11.1.6" - ], - "TDA-14": [ - "6.1.5" - ], - "TDA-15": [ - "6.1.6" - ], - "TDA-16": [ - "6.1.5" - ], "TDA-17": [ "7.3.1", - "7.3.2", "7.3.3" ], + "TDA-20": [ + "7.6.2" + ], "TDA-20.3": [ "5.3.4" ], "TPM-01": [ "3.4.1", + "8.3.4" + ], + "TPM-02": [ + "5.3.1" + ], + "TPM-04.1": [ "3.4.2", - "3.4.3", - "9.1.8" + "5.3.1", + "5.3.2", + "6.4.2", + "6.4.3" ], - "TPM-03": [ - "3.4.1", + "TPM-05": [ "3.4.2" ], - "TPM-03.2": [ - "3.4.1", + "TPM-05.4": [ "3.4.2" ], - "TPM-05": [ - "3.4.1", - "3.4.2", + "TPM-05.5": [ "3.4.3" ], "TPM-08": [ "3.4.3" ], + "TPM-09": [ + "3.4.3" + ], "THR-01": [ - "4.2.1", - "13.5.1", - "13.5.2", - "14.3.1", - "14.3.2", - "14.3.3" + "14.1.6" ], - "THR-02": [ - "14.3.1", - "14.3.2", - "14.3.3" + "THR-01.1": [ + "14.1.6" ], "THR-03": [ + "4.2.1", "12.1.1", - "12.1.2", + "12.1.2" + ], + "THR-03.1": [ "12.1.3" ], "THR-06": [ "13.2.2" ], + "THR-09": [ + "4.2.1" + ], + "THR-10": [ + "4.3.2", + "8.5.1" + ], + "THR-11": [ + "12.2.3" + ], "VPM-01": [ - "4.2.1", - "7.4.1", - "7.4.2" + "6.1.4" ], "VPM-01.1": [ + "6.1.4", "13.1.2" ], "VPM-02": [ + "6.1.4", + "13.6.1", "13.6.1(a)", "13.6.1(b)", "13.6.1(c)" ], - "VPM-04": [ - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" - ], - "VPM-04.1": [ - "7.4.1", - "7.4.2" - ], "VPM-05": [ - "7.4.1", - "7.4.2" - ], - "VPM-05.1": [ - "7.4.1", - "7.4.2" - ], - "VPM-05.3": [ - "13.6.1(b)" + "7.4.1" ], - "VPM-05.4": [ - "7.4.1", + "VPM-05.6": [ "7.4.2" ], "VPM-06": [ - "13.1.1", - "13.1.2" + "13.1.1" ], "VPM-07": [ "13.2.1", @@ -1059,207 +818,229 @@ "13.2.4" ], "VPM-10": [ - "13.3.1", - "13.3.2", + "8.5.1", "13.4.1", "13.4.2" + ], + "WEB-01": [ + "14.1.1" + ], + "WEB-04": [ + "14.1.1", + "14.1.2", + "14.1.3", + "14.1.4", + "14.2.1", + "14.2.3", + "14.2.4", + "14.2.11" + ], + "WEB-06": [ + "14.2.1", + "14.2.5", + "14.2.6", + "14.2.7", + "14.2.8", + "14.2.9" + ], + "WEB-10": [ + "14.2.2" ] } }, "framework_to_scf": { - "total_mappings": 280, + "total_mappings": 279, "mappings": { + "3.1.4": [ + "GOV-01", + "RSK-01" + ], "3.1.1": [ "GOV-01.1" ], "3.1.2": [ "GOV-01.1" ], - "3.1.3": [ - "GOV-01.1" - ], - "3.1.4": [ - "GOV-01.1", - "PRM-01.1" - ], "3.1.5": [ "GOV-01.1", - "PRM-01.1" + "RSK-01.5" ], - "3.1.6": [ + "3.1.7": [ "GOV-01.1" ], "3.1.7(a)": [ "GOV-01.1", - "GOV-04" + "RSK-01" ], "3.1.7(b)": [ - "GOV-01.1", - "GOV-04" + "GOV-01.1" ], "3.1.7(c)": [ "GOV-01.1", - "GOV-04" + "GOV-04.1", + "GOV-04.2" ], "3.1.7(d)": [ "GOV-01.1", - "GOV-04" + "RSK-01.3", + "RSK-01.5" ], "3.1.7(e)": [ - "GOV-01.1", - "GOV-04" + "GOV-01.1" ], "3.1.7(f)": [ - "GOV-01.1", - "GOV-04" + "GOV-01.1" ], "3.1.7(g)": [ - "GOV-01.1", - "GOV-04" + "GOV-01.1" ], - "3.1.8(a)": [ - "GOV-01.1", + "3.1.3": [ + "GOV-01.2", "GOV-04" ], - "3.1.8(b)": [ - "GOV-01.1", - "GOV-04" + "3.1.8(e)": [ + "GOV-01.2", + "GOV-04.1" ], "3.1.8(c)": [ - "GOV-01.1", - "GOV-04" - ], - "3.1.8(d)": [ - "GOV-01.1", - "GOV-04" - ], - "3.1.8(e)": [ - "GOV-01.1", - "GOV-04" + "GOV-02", + "GOV-04.1" ], "3.2.1": [ + "GOV-02", + "GOV-03" + ], + "3.3.1(d)": [ "GOV-02" ], + "5.3.1": [ + "GOV-02", + "TPM-02", + "TPM-04.1" + ], + "6.1.3": [ + "GOV-02", + "CFG-04", + "CFG-04.1" + ], + "6.4.4": [ + "GOV-02", + "CLD-04", + "CFG-02" + ], + "11.1.1": [ + "GOV-02", + "DCH-01", + "NET-17" + ], "3.2.2": [ - "GOV-03" + "GOV-02.1", + "AST-02.4" + ], + "7.3.3": [ + "GOV-02.1", + "TDA-17" + ], + "3.1.8": [ + "GOV-04", + "GOV-04.1" + ], + "3.1.8(a)": [ + "GOV-04.1" + ], + "3.1.8(b)": [ + "GOV-04.1" + ], + "3.1.8(d)": [ + "GOV-04.1" ], "4.5.3": [ - "GOV-05", - "CPL-01.1", - "RSK-04.1", - "RSK-06.1" + "GOV-05" ], - "7.8.3": [ - "GOV-05", - "BCD-05", - "IRO-13" + "3.1.6": [ + "GOV-14", + "SAT-01" + ], + "4.1.2": [ + "GOV-14", + "GOV-15" + ], + "5.8.1": [ + "GOV-18", + "PRM-07" + ], + "5.8.2": [ + "GOV-18" ], "3.3.1": [ "AST-01" ], "3.3.1(a)": [ - "AST-01", + "AST-01.1", + "AST-01.4", "AST-02" ], - "3.3.1(d)": [ - "AST-01" - ], - "7.1.1": [ - "AST-01", - "OPS-01", - "OPS-03" - ], - "11.4.1": [ - "AST-01", - "END-01" - ], - "11.4.2": [ - "AST-01", - "END-01" - ], - "11.4.3": [ - "AST-01", - "END-01" + "8.1.2": [ + "AST-01.1", + "AST-04", + "BCD-11.7" ], "3.3.1(c)": [ - "AST-01.2", - "DCH-01.1" + "AST-01.2" + ], + "6.5.1": [ + "AST-01.4", + "OPS-07" ], "3.3.2": [ "AST-02" ], + "11.5.1": [ + "AST-02", + "EMB-01" + ], "11.2.4": [ - "AST-02.5", - "NET-01", - "NET-08" + "AST-02.5" + ], + "11.2.5": [ + "AST-02.5" + ], + "11.5.4": [ + "AST-02.5" ], "11.1.7": [ "AST-09", - "DCH-01", - "DCH-08", - "DCH-09", - "DCH-21", - "PRI-05" + "DCH-09" ], "11.3.7": [ "AST-16" ], - "11.5.1": [ - "AST-23", - "EMB-01", - "EMB-02" - ], "8.1.1": [ - "BCD-01", - "CAP-01" - ], - "8.1.2": [ - "BCD-01", - "BCD-02" - ], - "8.1.3": [ - "BCD-01", - "CAP-03" + "BCD-01" ], - "8.1.4": [ - "BCD-01", - "BCD-01.4" + "8.3.4": [ + "BCD-01.2", + "TPM-01" ], "8.2.1": [ - "BCD-01", "BCD-01.4" ], "8.2.2": [ - "BCD-01" + "BCD-01.7" ], "8.2.3": [ - "BCD-01", - "BCD-04" - ], - "8.2.4": [ - "BCD-01", - "BCD-04.2" - ], - "8.5.1": [ - "BCD-01", - "PES-01" + "BCD-01.7" ], - "8.5.2": [ - "BCD-01", - "PES-01", - "PES-07" - ], - "8.5.2(a)": [ - "BCD-01", - "PES-07" + "13.5.1": [ + "BCD-03.1" ], - "8.5.2(b)": [ - "BCD-01", - "PES-07" + "13.5.2": [ + "BCD-03.1", + "BCD-04", + "IRO-06" ], - "8.5.2(c)": [ - "BCD-01", - "PES-07" + "8.2.4": [ + "BCD-04" ], "8.3.1": [ "BCD-04" @@ -1267,23 +1048,26 @@ "8.3.2": [ "BCD-04" ], + "8.3.3": [ + "BCD-04" + ], "8.3.3(a)": [ "BCD-04" ], "8.3.3(b)": [ "BCD-04" ], - "8.3.4": [ - "BCD-04", - "BCD-04.1" + "8.5.2": [ + "BCD-04.2" ], - "7.8.1": [ - "BCD-05", - "IRO-13" + "8.5.2(a)": [ + "BCD-04.2" ], - "7.8.2": [ - "BCD-05", - "IRO-13" + "8.5.2(b)": [ + "BCD-04.2" + ], + "8.5.4": [ + "BCD-04.2" ], "8.4.1": [ "BCD-11" @@ -1291,218 +1075,161 @@ "8.4.2": [ "BCD-11" ], - "8.4.3": [ - "BCD-11.1" - ], "8.4.4": [ + "BCD-11.2", "BCD-11.4" ], + "11.4.3": [ + "BCD-11.3", + "BCD-11.9", + "CLD-05" + ], + "8.4.3": [ + "BCD-11.5" + ], + "8.5.2(c)": [ + "BCD-11.7" + ], + "6.4.8": [ + "CAP-01", + "CAP-02" + ], + "8.1.3": [ + "CAP-04" + ], + "8.1.4": [ + "CAP-05" + ], "7.5.1": [ "CHG-01" ], "7.5.2": [ - "CHG-01", + "CHG-02", + "CHG-02.1", "CHG-03" ], + "7.5.4": [ + "CHG-02" + ], "7.5.3": [ - "CHG-01", "CHG-02.2" ], - "7.5.4": [ - "CHG-01", - "CHG-02.1", - "CHG-02.3" - ], "7.5.5": [ - "CHG-01", - "CHG-02.2", - "CHG-06" - ], - "7.5.6": [ - "CHG-01" + "CHG-02.2" ], "7.5.7": [ - "CHG-01", "CHG-02.2" ], - "7.4.2": [ - "CHG-02.2", - "VPM-01", - "VPM-04.1", - "VPM-05", - "VPM-05.1", - "VPM-05.4" + "9.1.1": [ + "CHG-04.3", + "HRS-11" ], - "3.2.3": [ - "CPL-01", - "CPL-01.1", - "CPL-02" + "7.6.2": [ + "CHG-04.5", + "MON-01.15", + "TDA-20" ], - "4.5.2": [ - "CPL-01.1", - "IAO-05", - "RSK-04.1" + "7.5.6": [ + "CHG-07" ], - "15.1.1": [ - "CPL-02.1" + "6.4.1": [ + "CLD-04" ], - "15.1.2": [ - "CPL-02.1" + "15.1.4": [ + "CPL-01.6" ], - "15.1.3": [ + "3.2.3": [ + "CPL-02" + ], + "15.1.1": [ + "CPL-02", "CPL-02.1" ], - "15.1.4": [ + "15.1.2": [ "CPL-02.1" ], + "15.1.3": [ + "CPL-02.2" + ], "4.5.1": [ "CPL-03", "CPL-03.2", - "SEA-01.1" + "IAO-01", + "IAO-01.1", + "IAO-02" + ], + "9.1.6": [ + "CPL-03" + ], + "11.2.8": [ + "CPL-03", + "CPL-03.2" ], "7.2.1": [ "CFG-01" ], "7.2.2": [ - "CFG-01" - ], - "7.3.1": [ - "CFG-01", - "SEA-07.1", - "TDA-17" - ], - "7.3.2": [ - "CFG-01", - "SEA-07.1", - "TDA-17" - ], - "7.3.3": [ - "CFG-01", - "SEA-07.1", - "TDA-17" + "CFG-02", + "CFG-02.2" ], - "11.2.5": [ + "11.1.5": [ "CFG-02", - "CFG-02.1", - "NET-01", - "NET-03", - "NET-04.6" + "END-02", + "HRS-05.3" ], "11.3.1": [ - "CFG-02", - "END-01" + "CFG-02" ], "11.3.2": [ - "CFG-02", "CFG-02.2", - "END-01" + "CFG-02.7" ], - "5.7.3": [ - "CFG-02.4", - "TDA-07", - "TDA-08", - "TDA-09" + "11.2.6": [ + "CFG-03" ], "11.3.6": [ "CFG-03.3" ], - "6.1.3": [ - "CFG-04.1", - "TDA-01", - "TDA-03", - "TDA-06.5", - "TDA-09" + "6.4.7": [ + "MON-01", + "MON-01.2" ], "12.2.1": [ - "MON-01", - "MON-01.16", - "OPS-04" + "MON-01" ], - "12.2.2": [ - "MON-01", - "MON-01.8", - "MON-01.16" + "7.7.4": [ + "MON-01.2" ], - "12.2.3": [ - "MON-01", - "MON-01.16" + "12.2.2": [ + "MON-01.2", + "MON-08" ], - "9.1.3": [ - "MON-02", - "IAC-01" + "12.2.6": [ + "MON-01.8" ], "12.2.5": [ "MON-02.1" ], - "12.2.6": [ - "MON-02.2", - "MON-06" - ], - "9.2.2": [ - "MON-03.2", - "MON-16", - "SAT-03.2" - ], - "14.2.1": [ - "MON-09" - ], - "14.2.2": [ - "MON-09" - ], - "14.2.3": [ - "MON-09" - ], - "14.2.4": [ - "MON-09" - ], - "14.2.5": [ - "MON-09" - ], - "14.2.6": [ - "MON-09" - ], - "14.2.7": [ - "MON-09" - ], - "14.2.8": [ - "MON-09" - ], - "14.2.9": [ - "MON-09" - ], - "14.2.10": [ - "MON-09" - ], - "14.2.11": [ - "MON-09" - ], "11.3.5": [ "MON-11.3", - "END-01", - "END-04.3" + "IRO-03" ], "11.5.5": [ "MON-16", - "EMB-01", - "EMB-02", - "EMB-05", - "SAT-03.2" + "NET-03.6" ], - "12.2.4": [ + "12.2.3": [ "MON-16", - "SAT-03.2" + "THR-11" ], - "3.5.2": [ - "MON-16.1", - "HRS-01", - "HRS-02.1", - "HRS-04", - "HRS-04.1" + "12.2.4": [ + "MON-16" ], - "10.1.1": [ - "CRY-01" + "6.4.5": [ + "CRY-01", + "CRY-09" ], - "10.1.2": [ + "10.1.1": [ "CRY-01" ], "10.1.3": [ @@ -1511,8 +1238,15 @@ "10.1.4": [ "CRY-01" ], + "10.1.2": [ + "CRY-01.5" + ], "10.1.5": [ - "CRY-01" + "CRY-01.5" + ], + "11.1.3": [ + "CRY-05", + "END-02" ], "10.2.1": [ "CRY-09" @@ -1527,124 +1261,101 @@ "CRY-09" ], "10.2.5": [ - "CRY-09", - "CRY-09.4" - ], - "10.2.6": [ "CRY-09" ], - "10.2.7": [ + "10.2.6": [ "CRY-09" ], "10.2.8": [ "CRY-09" ], - "10.2.9": [ - "CRY-09" - ], "10.2.10": [ "CRY-09" ], - "11.1.1": [ - "DCH-01" - ], - "11.1.1(a)": [ - "DCH-01" - ], - "11.1.1(b)": [ - "DCH-01" + "10.2.7": [ + "CRY-09.3" ], - "11.1.1(c)": [ - "DCH-01" + "10.2.9": [ + "CRY-09.3" ], "11.1.2": [ "DCH-01" ], - "11.1.3": [ - "DCH-01" + "11.1.1(a)": [ + "DCH-01.2" ], - "11.1.4": [ - "DCH-01" + "11.1.1(b)": [ + "DCH-01.2" ], - "11.1.5": [ - "DCH-01" + "11.1.1(c)": [ + "DCH-01.2" ], "11.1.6": [ - "DCH-01", - "IAC-08", - "TDA-10" + "DCH-01.2", + "DCH-01.4" ], "3.3.1(b)": [ "DCH-02" ], - "5.8.1": [ - "DCH-22", - "PRM-04", - "TDA-01.1" - ], - "5.8.2": [ - "DCH-22", - "PRM-04", - "TDA-01.1" + "11.1.4": [ + "DCH-13.2", + "END-02" ], "11.5.2": [ - "EMB-01", - "EMB-02" + "EMB-01" ], "11.5.3": [ - "EMB-01", - "EMB-02" - ], - "11.5.4": [ - "EMB-01", - "EMB-02" + "EMB-01" ], "11.3.3": [ - "END-01", "END-04" ], "11.3.4": [ - "END-01", "END-04.1" ], - "14.1.6": [ - "END-08", - "PRI-01.6" + "11.4.2": [ + "END-15" ], "3.5.1": [ "HRS-01", + "HRS-02", + "HRS-03", "HRS-03.2" ], "6.1.5": [ - "HRS-02.1", "HRS-03.2", - "SAT-01", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "TDA-01", - "TDA-02.3", - "TDA-05", - "TDA-14", - "TDA-16" + "SAT-03.8" ], - "9.1.1": [ - "HRS-11", - "IAC-21" + "3.5.2": [ + "HRS-04", + "HRS-04.1" ], - "9.1.2": [ - "IAC-01" + "6.3.2": [ + "HRS-11" + ], + "7.6.1": [ + "HRS-11" ], "9.1.8": [ "IAC-01", - "IAC-05", - "TPM-01" + "IAC-15" + ], + "9.2.2": [ + "IAC-01", + "IAC-15.1" + ], + "9.1.3": [ + "IAC-01.1" ], "9.1.5": [ "IAC-06" ], + "9.1.2": [ + "IAC-07" + ], "9.1.7": [ - "IAC-08" + "IAC-08", + "IAC-21" ], "9.1.4": [ "IAC-10.1" @@ -1652,567 +1363,359 @@ "9.2.1": [ "IAC-16" ], - "9.1.6": [ - "IAC-17" - ], "7.7.1": [ "IRO-01" ], "7.7.2": [ - "IRO-01" + "IRO-01", + "IRO-02" + ], + "7.7.3": [ + "IRO-02" ], "7.7.3(a)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "IRO-02" ], "7.7.3(b)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "IRO-02" ], "7.7.3(c)": [ - "IRO-01", - "IRO-02", + "IRO-02" + ], + "12.3.1": [ "IRO-04" ], - "7.7.4": [ - "IRO-01" + "7.8.3": [ + "IRO-04.3" + ], + "12.3.3": [ + "IRO-04.3" + ], + "13.3.1": [ + "IRO-06" + ], + "13.3.2": [ + "IRO-06" ], "7.7.5": [ - "IRO-01", "IRO-07", - "IRO-09", - "IRO-10", - "IRO-16" + "IRO-10" ], "7.7.6": [ - "IRO-01", - "IRO-10", - "IRO-16" + "IRO-07" ], "7.7.7": [ - "IRO-01", - "IRO-10", - "IRO-16" - ], - "12.3.1": [ - "IRO-04" - ], - "12.3.2": [ - "IRO-04" + "IRO-10" ], - "12.3.3": [ - "IRO-04", + "7.8.1": [ "IRO-13" ], - "5.1.2": [ - "IAO-01", - "PRM-01", - "PRM-02", - "PRM-04", - "PRM-05", - "PRM-07" - ], - "5.4.1": [ - "IAO-01", - "PRM-04", - "PRM-07" - ], - "5.4.2": [ - "IAO-01", - "PRM-04", - "PRM-07" - ], - "5.4.3": [ - "IAO-01", - "IAO-03.2", - "PRM-04", - "PRM-07" - ], - "5.4.4": [ - "IAO-01", - "PRM-04", - "PRM-07" + "7.8.2": [ + "IRO-13" ], - "5.6.1": [ - "IAO-01", - "PRM-05", - "SEA-01", - "SEA-02", - "SEA-03" + "12.3.2": [ + "IRO-13" ], "5.6.2": [ "IAO-01", - "PRM-05", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "5.6.3": [ - "IAO-01", - "PRM-05", - "SEA-01", - "SEA-02", - "SEA-03" + "IAO-01.1", + "IAO-02" ], "5.7.1": [ + "IAO-01" + ], + "6.1.6": [ "IAO-01", "IAO-01.1", "IAO-02", + "IAO-02.2", + "TDA-09", + "TDA-09.2", + "TDA-09.3", + "TDA-09.4" + ], + "6.1.7": [ + "IAO-01", "TDA-09" ], - "5.7.2": [ + "6.4.6": [ "IAO-01", "IAO-01.1", - "IAO-02", - "TDA-09" + "IAO-02.2" ], - "5.7.4": [ - "IAO-02.2", - "TDA-06.5", - "TDA-09" + "6.5.3": [ + "IAO-01" ], - "5.7.6": [ - "IAO-02.4", - "TDA-09" + "5.3.3": [ + "IAO-02.2" + ], + "5.6.3": [ + "IAO-02.2" ], "5.7.5": [ "IAO-04", "TDA-09" ], - "14.1.7": [ - "MDM-04", - "MDM-06", - "MDM-07", - "PRI-01.6" + "5.7.6": [ + "IAO-06", + "IAO-07" ], "11.2.1": [ - "NET-01" + "NET-01", + "NET-03" ], "11.2.2": [ - "NET-01" + "NET-06" ], "11.2.3": [ - "NET-01", "NET-08" ], - "11.2.6": [ - "NET-01", - "NET-03", - "NET-03.7", - "NET-06" - ], - "11.2.7": [ - "NET-01", - "NET-02.1" - ], - "11.2.8": [ - "NET-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], "9.3.1": [ - "NET-14", - "NET-14.5" + "NET-14" ], "9.3.2": [ - "NET-14", - "NET-14.5" + "NET-14" + ], + "11.2.7": [ + "NET-18" ], "8.5.5": [ - "PES-01", - "PES-05.2" + "PES-01" + ], + "8.5.6": [ + "PES-01" ], "8.5.6(a)": [ - "PES-01", "PES-02" ], - "8.5.6(b)": [ - "PES-01", - "PES-06" + "8.5.6(e)": [ + "PES-03" ], "8.5.6(c)": [ - "PES-01", - "PES-03" + "PES-03.1" ], "8.5.6(d)": [ - "PES-01", - "PES-03.2", "PES-03.4" ], - "8.5.6(e)": [ - "PES-01", - "PES-04", - "PES-04.1" - ], - "8.5.6(f)": [ - "PES-01" - ], - "5.5.6(f)": [ - "PES-03", - "PES-03.1", - "PES-04.1", - "PES-06", - "PES-10" - ], - "5.5.5": [ - "PES-05" + "8.5.6(b)": [ + "PES-06" ], "8.5.3": [ "PES-08", - "PES-08.1" + "PES-08.1", + "PES-08.2" ], - "8.5.4": [ - "PES-08", - "PES-08.1" - ], - "14.1.1": [ - "PRI-01.6" + "8.5.6(f)": [ + "PES-10" ], - "14.1.2": [ - "PRI-01.6" + "14.4.1": [ + "PRI-02" ], - "14.1.3": [ - "PRI-01.6" + "5.2.1": [ + "PRM-01" ], - "14.1.4": [ - "PRI-01.6" + "5.2.2": [ + "PRM-01" ], - "14.1.5": [ - "PRI-01.6" + "5.1.4": [ + "PRM-02", + "PRM-03" ], "5.1.1": [ - "PRM-01", - "PRM-02", - "PRM-04", - "PRM-05" + "PRM-04" ], "5.1.3": [ - "PRM-01", - "PRM-02", - "PRM-04", - "PRM-05", - "PRM-07", - "RSK-08", - "RSK-10" + "PRM-04" ], - "5.1.4": [ - "PRM-01", - "PRM-02", - "PRM-04", + "5.1.2": [ "PRM-05", + "PRM-06", "PRM-07" ], - "5.2.1": [ - "PRM-02", - "PRM-03", - "PRM-04" + "5.4.2": [ + "PRM-05" ], - "5.2.2": [ - "PRM-02", - "PRM-03", - "PRM-04" + "5.4.3": [ + "PRM-05", + "TDA-02" ], "5.5.1": [ - "PRM-02", "PRM-05", "PRM-06" ], - "5.5.2": [ - "PRM-02", - "PRM-05", - "PRM-06" + "5.4.1": [ + "PRM-07" ], - "5.3.3": [ - "PRM-05", - "RSK-08", - "RSK-10", - "TDA-02", - "TDA-03" + "5.4.4": [ + "PRM-07" + ], + "5.5.2": [ + "PRM-07", + "TDA-01.1", + "TDA-02" ], "4.1.1": [ "RSK-01" ], - "4.1.2": [ + "4.1.4": [ "RSK-01" ], - "4.1.5": [ + "4.1.4(d)": [ "RSK-01", - "RSK-06.1", - "RSK-07" + "RSK-04.2", + "RSK-04.3" ], - "4.2.1": [ - "RSK-01.1", - "RSK-02", - "RSK-02.1", - "RSK-05", - "RSK-06.2", - "THR-01", - "VPM-01" + "4.1.5": [ + "RSK-01" ], - "4.3.2": [ + "4.2.1": [ "RSK-01.1", - "RSK-02.1", - "RSK-04" - ], - "4.3.1": [ - "RSK-02.1" - ], - "4.1.3": [ "RSK-03", - "RSK-04.1", - "RSK-06" + "RSK-03.1", + "THR-03", + "THR-09" + ], + "4.4.2": [ + "RSK-01.3", + "RSK-01.4", + "RSK-06.3" ], "4.1.4(a)": [ "RSK-03" ], + "4.1.3": [ + "RSK-03.2", + "RSK-06.3" + ], "4.1.4(b)": [ "RSK-04" ], - "4.1.4(d)": [ + "4.3.1": [ + "RSK-04" + ], + "8.5.1": [ + "RSK-04", + "THR-10", + "VPM-10" + ], + "4.5.2": [ "RSK-04.1" ], "4.1.4(c)": [ - "RSK-06" + "RSK-06", + "RSK-06.3" ], "4.4.1": [ - "RSK-06" - ], - "4.4.2": [ "RSK-06", "RSK-06.2" ], "4.4.3": [ - "RSK-06", - "RSK-06.2" + "RSK-06.3" ], - "13.6.1": [ - "RSK-06" + "14.1.1": [ + "SEA-01", + "WEB-01", + "WEB-04" ], - "13.6.1(a)": [ - "RSK-06", - "VPM-02", - "VPM-04" + "14.2.10": [ + "SEA-01" ], - "13.6.1(b)": [ - "RSK-06", - "VPM-02", - "VPM-04", - "VPM-05.3" + "7.3.2": [ + "SEA-07.1" ], - "13.6.1(c)": [ - "RSK-06", - "VPM-02", - "VPM-04" + "11.4.1": [ + "SEA-13.1" ], - "5.3.1": [ - "RSK-09", - "TDA-01" + "7.1.1": [ + "OPS-03" ], - "3.6.1": [ - "SAT-01", - "SAT-02" + "6.5.2": [ + "OPS-07" ], "3.6.4": [ - "SAT-01" - ], - "3.6.2": [ - "SAT-03", - "SAT-03.3" + "SAT-01.1" ], - "3.6.3": [ + "3.6.1": [ + "SAT-02", "SAT-03", "SAT-03.3" ], - "5.3.2": [ - "TDA-01", - "TDA-06" - ], - "6.1.1": [ - "TDA-01", - "TDA-06", - "TDA-06.3", - "TDA-06.5", - "TDA-09" - ], - "6.1.2": [ - "TDA-01", - "TDA-06", - "TDA-06.3", - "TDA-06.5", - "TDA-09" + "3.6.2": [ + "SAT-03" ], - "6.1.4": [ - "TDA-01", - "TDA-02.3", - "TDA-04", - "TDA-06.5", - "TDA-09", - "TDA-09.1" + "3.6.3": [ + "SAT-03" ], - "6.1.6": [ - "TDA-01", - "TDA-02.3", - "TDA-06.5", - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TDA-15" + "12.1.3": [ + "SAT-03.6", + "THR-03.1" ], - "6.1.7": [ + "5.3.2": [ "TDA-01", - "TDA-02.3", - "TDA-06.5", - "TDA-09" + "TPM-04.1" ], - "6.2.1": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "14.1.5": [ + "TDA-01.1" ], - "6.2.2": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "14.1.7": [ + "TDA-01.1" ], "6.3.1": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" - ], - "6.3.2": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" - ], - "6.4.1": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "TDA-01.4" ], - "6.4.2": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" - ], - "6.4.3": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" - ], - "6.4.4": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" - ], - "6.4.5": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" - ], - "6.4.6": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" - ], - "6.4.7": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" - ], - "6.4.8": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "5.6.1": [ + "TDA-02.10" ], - "6.5.1": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "5.7.2": [ + "TDA-02.10" ], - "6.5.2": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "6.1.1": [ + "TDA-06" ], - "6.5.3": [ - "TDA-01", - "TDA-05", - "TDA-06", - "TDA-06.3" + "6.1.2": [ + "TDA-06" ], - "7.6.1": [ - "TDA-01.1", - "TDA-06.3" + "6.2.1": [ + "TDA-06" ], - "7.6.2": [ - "TDA-01.1", - "TDA-06.3" + "6.2.2": [ + "TDA-06" ], - "14.4.1": [ - "TDA-01.1" + "5.7.3": [ + "TDA-07", + "TDA-08" ], - "14.4.2": [ - "TDA-01.1" + "5.7.4": [ + "TDA-09" ], - "14.4.3": [ - "TDA-01.1" + "7.3.1": [ + "TDA-17" ], "5.3.4": [ "TDA-20.3" ], "3.4.1": [ - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-05" + "TPM-01" ], "3.4.2": [ - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-05" - ], - "3.4.3": [ - "TPM-01", + "TPM-04.1", "TPM-05", - "TPM-08" + "TPM-05.4" ], - "13.5.1": [ - "THR-01" - ], - "13.5.2": [ - "THR-01" + "6.4.2": [ + "TPM-04.1" ], - "14.3.1": [ - "THR-01", - "THR-02" + "6.4.3": [ + "TPM-04.1" ], - "14.3.2": [ - "THR-01", - "THR-02" + "3.4.3": [ + "TPM-05.5", + "TPM-08", + "TPM-09" ], - "14.3.3": [ + "14.1.6": [ "THR-01", - "THR-02" + "THR-01.1" ], "12.1.1": [ "THR-03" @@ -2220,22 +1723,37 @@ "12.1.2": [ "THR-03" ], - "12.1.3": [ - "THR-03" - ], "13.2.2": [ "THR-06" ], - "7.4.1": [ + "4.3.2": [ + "THR-10" + ], + "6.1.4": [ "VPM-01", - "VPM-04.1", - "VPM-05", - "VPM-05.1", - "VPM-05.4" + "VPM-01.1", + "VPM-02" ], "13.1.2": [ - "VPM-01.1", - "VPM-06" + "VPM-01.1" + ], + "13.6.1": [ + "VPM-02" + ], + "13.6.1(a)": [ + "VPM-02" + ], + "13.6.1(b)": [ + "VPM-02" + ], + "13.6.1(c)": [ + "VPM-02" + ], + "7.4.1": [ + "VPM-05" + ], + "7.4.2": [ + "VPM-05.6" ], "13.1.1": [ "VPM-06" @@ -2249,17 +1767,51 @@ "13.2.4": [ "VPM-07" ], - "13.3.1": [ - "VPM-10" - ], - "13.3.2": [ - "VPM-10" - ], "13.4.1": [ "VPM-10" ], "13.4.2": [ "VPM-10" + ], + "14.1.2": [ + "WEB-04" + ], + "14.1.3": [ + "WEB-04" + ], + "14.1.4": [ + "WEB-04" + ], + "14.2.1": [ + "WEB-04", + "WEB-06" + ], + "14.2.3": [ + "WEB-04" + ], + "14.2.4": [ + "WEB-04" + ], + "14.2.11": [ + "WEB-04" + ], + "14.2.5": [ + "WEB-06" + ], + "14.2.6": [ + "WEB-06" + ], + "14.2.7": [ + "WEB-06" + ], + "14.2.8": [ + "WEB-06" + ], + "14.2.9": [ + "WEB-06" + ], + "14.2.2": [ + "WEB-10" ] } } diff --git a/docs/api/crosswalks/apac-sgp-pdpa-2012.json b/docs/api/crosswalks/apac-sgp-pdpa-2012.json index da17e1e9..30230047 100644 --- a/docs/api/crosswalks/apac-sgp-pdpa-2012.json +++ b/docs/api/crosswalks/apac-sgp-pdpa-2012.json @@ -2,186 +2,554 @@ "framework_id": "apac-sgp-pdpa-2012", "display_name": "Singapore - Personal Data Protection Ac (PDPA) (2012)", "scf_to_framework": { - "total_mappings": 30, + "total_mappings": 33, "mappings": { - "GOV-01": [ - "12", - "24" + "GOV-02": [ + "3.12(a)", + "3.12(c)" ], "CPL-01": [ - "24" + "3.11(2)" ], - "CPL-02": [ - "24" + "CPL-05": [ + "3.12(d)", + "3.12(d)(i)", + "3.12(d)(ii)" ], - "CPL-03": [ - "24" + "CPL-05.1": [ + "5.21(4)" ], - "DCH-01": [ - "24", - "26" + "DCH-02": [ + "4.1.13", + "5.21(6)(b)", + "5.22(7)" ], "DCH-22.1": [ - "22" - ], - "DCH-24": [ - "24", - "26" - ], - "DCH-24.1": [ - "24", - "26" - ], - "DCH-25": [ - "24", - "26" - ], - "IRO-14": [ - "11" - ], - "PRI-01": [ - "12" + "5.22(2)(a)" + ], + "IRO-02": [ + "6A.26C(2)" + ], + "IRO-04": [ + "6A.26C(2)", + "6A.26C(4)" + ], + "IRO-10": [ + "6A.26D(1)", + "6A.26D(2)", + "6A.26D(3)", + "6A.26D(4)", + "6A.26D(5)(a)", + "6A.26D(5)(b)", + "6A.26D(6)", + "6A.26D(6)(a)", + "6A.26D(6)(b)", + "6A.26D(9)", + "6A.26E", + "6A.26E(a)", + "6A.26E(b)" + ], + "IRO-10.2": [ + "6A.26C(3)(a)", + "6A.26C(3)(b)", + "6A.26C(4)" ], "PRI-01.1": [ - "11" + "3.11(3)", + "3.11(4)" + ], + "PRI-01.5": [ + "6.26(1)" + ], + "PRI-01.6": [ + "6.24", + "6.24(a)", + "6.24(b)" + ], + "PRI-01.11": [ + "3.11(1)", + "4.1.14(2)(a)", + "4.1.14(2)(b)", + "4.1.15A(4)(c)", + "4.1.15A(5)(c)", + "9.3.46(2)(a)", + "9.3.46(2)(b)", + "9.3.47(2)" ], "PRI-02": [ - "14" - ], - "PRI-02.1": [ - "14", - "19", - "20" + "3.11(5)", + "3.11(5A)", + "4.1.14(1)(a)", + "4.1.15A(4)(b)", + "4.1.15A(4)(b)(i)", + "4.1.15A(4)(b)(ii)", + "4.1.15A(4)(b)(iii)", + "4.2.20(1)(a)", + "4.2.20(1)(b)", + "4.2.20(1)(c)", + "4.2.20(2)" ], "PRI-03": [ - "13" - ], - "PRI-04": [ - "17" + "4.1.13", + "4.1.14(1)(b)", + "4.1.14(3)", + "4.1.14(4)", + "4.1.15(1)", + "4.1.15(1)(a)", + "4.1.15(1)(b)", + "4.1.15(2)", + "4.1.15(3)", + "4.1.15(6)", + "4.1.15(6)(a)(i)", + "4.1.15(6)(a)(ii)", + "4.1.15(6)(b)", + "4.1.15(6)(c)", + "4.1.15(7)", + "4.1.15(9)(a)", + "4.1.15(9)(b)", + "9.3.46(1)" + ], + "PRI-03.4": [ + "4.1.16(1)", + "9.3.47(1)" + ], + "PRI-03.9": [ + "4.2.19(a)", + "9.3.47(3)" + ], + "PRI-03.10": [ + "4.1.16(4)" + ], + "PRI-03.12": [ + "9.3.46(2)" ], "PRI-04.1": [ - "17" + "4.1.17(1)(a)" ], "PRI-05": [ - "23", - "25" + "5.22A(1)", + "5.22A(2)" ], "PRI-05.2": [ - "23" + "6.23", + "6.23(a)", + "6.23(b)", + "6.25", + "6.25(a)", + "6.25(b)" ], "PRI-05.4": [ - "14" + "4.1.13", + "4.1.13(a)", + "4.1.13(b)", + "4.1.15(3)(a)", + "4.1.15(3)(b)", + "4.1.15(3)(c)", + "4.1.17(1)(b)", + "4.1.17(2)(a)" + ], + "PRI-05.5": [ + "4.1.13" ], "PRI-06": [ - "21" + "4.1.16(3)", + "5.21(1)", + "5.21(1)(a)", + "5.21(1)(b)", + "5.21(2)", + "5.21(5)" ], "PRI-06.1": [ - "22" - ], - "PRI-06.2": [ - "23" + "5.22(1)", + "5.22(2)(a)", + "5.22(4)" + ], + "PRI-06.4": [ + "3.12(b)", + "4.1.16(2)", + "5.21(6)", + "5.21(6)(b)", + "5.21(7)", + "5.21(7)(b)" ], "PRI-07": [ - "26" - ], - "PRI-15": [ - "39" - ], - "SEA-01": [ - "24", - "26" + "4.1.17(1)(c)", + "5.22(2)(b)", + "5.22(3)" ], - "SEA-02": [ - "24", - "26" + "PRI-18": [ + "5.22(5)", + "5.22(6)" ], - "SEA-03": [ - "24", - "26" + "RSK-06": [ + "4.1.15A(5)(b)(i)", + "4.1.15A(5)(b)(ii)", + "4.1.15A(5)(b)(iii)" ], - "SEA-15": [ - "24", - "26" + "RSK-10": [ + "4.1.15A(4)(a)", + "4.1.15A(5)(a)" ], - "TPM-04.4": [ - "24", - "26" + "SAT-02": [ + "3.12(c)" ] } }, "framework_to_scf": { - "total_mappings": 14, + "total_mappings": 115, "mappings": { - "11": [ - "IRO-14", + "3.12(a)": [ + "GOV-02" + ], + "3.12(c)": [ + "GOV-02", + "SAT-02" + ], + "3.11(2)": [ + "CPL-01" + ], + "3.12(d)": [ + "CPL-05" + ], + "3.12(d)(i)": [ + "CPL-05" + ], + "3.12(d)(ii)": [ + "CPL-05" + ], + "5.21(4)": [ + "CPL-05.1" + ], + "4.1.13": [ + "DCH-02", + "PRI-03", + "PRI-05.4", + "PRI-05.5" + ], + "5.21(6)(b)": [ + "DCH-02", + "PRI-06.4" + ], + "5.22(7)": [ + "DCH-02" + ], + "5.22(2)(a)": [ + "DCH-22.1", + "PRI-06.1" + ], + "6A.26C(2)": [ + "IRO-02", + "IRO-04" + ], + "6A.26C(4)": [ + "IRO-04", + "IRO-10.2" + ], + "6A.26D(1)": [ + "IRO-10" + ], + "6A.26D(2)": [ + "IRO-10" + ], + "6A.26D(3)": [ + "IRO-10" + ], + "6A.26D(4)": [ + "IRO-10" + ], + "6A.26D(5)(a)": [ + "IRO-10" + ], + "6A.26D(5)(b)": [ + "IRO-10" + ], + "6A.26D(6)": [ + "IRO-10" + ], + "6A.26D(6)(a)": [ + "IRO-10" + ], + "6A.26D(6)(b)": [ + "IRO-10" + ], + "6A.26D(9)": [ + "IRO-10" + ], + "6A.26E": [ + "IRO-10" + ], + "6A.26E(a)": [ + "IRO-10" + ], + "6A.26E(b)": [ + "IRO-10" + ], + "6A.26C(3)(a)": [ + "IRO-10.2" + ], + "6A.26C(3)(b)": [ + "IRO-10.2" + ], + "3.11(3)": [ "PRI-01.1" ], - "12": [ - "GOV-01", - "PRI-01" + "3.11(4)": [ + "PRI-01.1" + ], + "6.26(1)": [ + "PRI-01.5" + ], + "6.24": [ + "PRI-01.6" + ], + "6.24(a)": [ + "PRI-01.6" + ], + "6.24(b)": [ + "PRI-01.6" + ], + "3.11(1)": [ + "PRI-01.11" + ], + "4.1.14(2)(a)": [ + "PRI-01.11" + ], + "4.1.14(2)(b)": [ + "PRI-01.11" + ], + "4.1.15A(4)(c)": [ + "PRI-01.11" + ], + "4.1.15A(5)(c)": [ + "PRI-01.11" + ], + "9.3.46(2)(a)": [ + "PRI-01.11" + ], + "9.3.46(2)(b)": [ + "PRI-01.11" + ], + "9.3.47(2)": [ + "PRI-01.11" + ], + "3.11(5)": [ + "PRI-02" + ], + "3.11(5A)": [ + "PRI-02" + ], + "4.1.14(1)(a)": [ + "PRI-02" + ], + "4.1.15A(4)(b)": [ + "PRI-02" ], - "13": [ + "4.1.15A(4)(b)(i)": [ + "PRI-02" + ], + "4.1.15A(4)(b)(ii)": [ + "PRI-02" + ], + "4.1.15A(4)(b)(iii)": [ + "PRI-02" + ], + "4.2.20(1)(a)": [ + "PRI-02" + ], + "4.2.20(1)(b)": [ + "PRI-02" + ], + "4.2.20(1)(c)": [ + "PRI-02" + ], + "4.2.20(2)": [ + "PRI-02" + ], + "4.1.14(1)(b)": [ "PRI-03" ], - "14": [ - "PRI-02", - "PRI-02.1", - "PRI-05.4" + "4.1.14(3)": [ + "PRI-03" + ], + "4.1.14(4)": [ + "PRI-03" + ], + "4.1.15(1)": [ + "PRI-03" + ], + "4.1.15(1)(a)": [ + "PRI-03" + ], + "4.1.15(1)(b)": [ + "PRI-03" + ], + "4.1.15(2)": [ + "PRI-03" ], - "17": [ - "PRI-04", + "4.1.15(3)": [ + "PRI-03" + ], + "4.1.15(6)": [ + "PRI-03" + ], + "4.1.15(6)(a)(i)": [ + "PRI-03" + ], + "4.1.15(6)(a)(ii)": [ + "PRI-03" + ], + "4.1.15(6)(b)": [ + "PRI-03" + ], + "4.1.15(6)(c)": [ + "PRI-03" + ], + "4.1.15(7)": [ + "PRI-03" + ], + "4.1.15(9)(a)": [ + "PRI-03" + ], + "4.1.15(9)(b)": [ + "PRI-03" + ], + "9.3.46(1)": [ + "PRI-03" + ], + "4.1.16(1)": [ + "PRI-03.4" + ], + "9.3.47(1)": [ + "PRI-03.4" + ], + "4.2.19(a)": [ + "PRI-03.9" + ], + "9.3.47(3)": [ + "PRI-03.9" + ], + "4.1.16(4)": [ + "PRI-03.10" + ], + "9.3.46(2)": [ + "PRI-03.12" + ], + "4.1.17(1)(a)": [ "PRI-04.1" ], - "19": [ - "PRI-02.1" + "5.22A(1)": [ + "PRI-05" + ], + "5.22A(2)": [ + "PRI-05" ], - "20": [ - "PRI-02.1" + "6.23": [ + "PRI-05.2" + ], + "6.23(a)": [ + "PRI-05.2" + ], + "6.23(b)": [ + "PRI-05.2" + ], + "6.25": [ + "PRI-05.2" + ], + "6.25(a)": [ + "PRI-05.2" + ], + "6.25(b)": [ + "PRI-05.2" + ], + "4.1.13(a)": [ + "PRI-05.4" + ], + "4.1.13(b)": [ + "PRI-05.4" ], - "21": [ + "4.1.15(3)(a)": [ + "PRI-05.4" + ], + "4.1.15(3)(b)": [ + "PRI-05.4" + ], + "4.1.15(3)(c)": [ + "PRI-05.4" + ], + "4.1.17(1)(b)": [ + "PRI-05.4" + ], + "4.1.17(2)(a)": [ + "PRI-05.4" + ], + "4.1.16(3)": [ "PRI-06" ], - "22": [ - "DCH-22.1", + "5.21(1)": [ + "PRI-06" + ], + "5.21(1)(a)": [ + "PRI-06" + ], + "5.21(1)(b)": [ + "PRI-06" + ], + "5.21(2)": [ + "PRI-06" + ], + "5.21(5)": [ + "PRI-06" + ], + "5.22(1)": [ "PRI-06.1" ], - "23": [ - "PRI-05", - "PRI-05.2", - "PRI-06.2" - ], - "24": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "DCH-25", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "25": [ - "PRI-05" + "5.22(4)": [ + "PRI-06.1" + ], + "3.12(b)": [ + "PRI-06.4" + ], + "4.1.16(2)": [ + "PRI-06.4" + ], + "5.21(6)": [ + "PRI-06.4" + ], + "5.21(7)": [ + "PRI-06.4" + ], + "5.21(7)(b)": [ + "PRI-06.4" + ], + "4.1.17(1)(c)": [ + "PRI-07" + ], + "5.22(2)(b)": [ + "PRI-07" + ], + "5.22(3)": [ + "PRI-07" + ], + "5.22(5)": [ + "PRI-18" + ], + "5.22(6)": [ + "PRI-18" + ], + "4.1.15A(5)(b)(i)": [ + "RSK-06" + ], + "4.1.15A(5)(b)(ii)": [ + "RSK-06" + ], + "4.1.15A(5)(b)(iii)": [ + "RSK-06" + ], + "4.1.15A(4)(a)": [ + "RSK-10" ], - "26": [ - "DCH-01", - "DCH-24", - "DCH-24.1", - "DCH-25", - "PRI-07", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "39": [ - "PRI-15" + "4.1.15A(5)(a)": [ + "RSK-10" ] } } diff --git a/docs/api/crosswalks/apac-twn-pdpa-2025.json b/docs/api/crosswalks/apac-twn-pdpa-2025.json index 2baf1ed9..a47436cf 100644 --- a/docs/api/crosswalks/apac-twn-pdpa-2025.json +++ b/docs/api/crosswalks/apac-twn-pdpa-2025.json @@ -2,130 +2,274 @@ "framework_id": "apac-twn-pdpa-2025", "display_name": "Taiwan - Personal Data Protection Act (PDPA) (2025)", "scf_to_framework": { - "total_mappings": 23, + "total_mappings": 9, "mappings": { - "GOV-01": [ - "27" + "IRO-10": [ + "I.12", + "I.12.1", + "I.12.2" ], - "CPL-01": [ - "27" + "PRI-01.6": [ + "III.20-1" ], - "CPL-02": [ - "27" + "PRI-01.11": [ + "I.5" ], - "DCH-01": [ - "21" + "PRI-02": [ + "I.8-1", + "I.8.1-1", + "I.8.2-1", + "I.8.3-1", + "I.8.4-1", + "I.8.5-1", + "I.8.6-1", + "I.8-2", + "I.8.1-2", + "I.8.2-2", + "I.8.3-2", + "I.8.4-2", + "I.8.5-2", + "I.8.6-2", + "I.9", + "I.9.1", + "I.9.2", + "I.9.3", + "I.9.4", + "I.9.5" ], - "DCH-22.1": [ - "3" + "PRI-03": [ + "I.7" ], - "IRO-04.1": [ - "12" + "PRI-05.2": [ + "I.11" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-05.4": [ + "I.6", + "I.6.1", + "I.6.2", + "I.6.3", + "I.6.4", + "I.6.5", + "I.6.6", + "III.19", + "III.19.1", + "III.19.2", + "III.19.3", + "III.19.4", + "III.19.5", + "III.19.6", + "III.19.7", + "III.19.8", + "III.20", + "III.20.1", + "III.20.2", + "III.20.3", + "III.20.4", + "III.20.5", + "III.20.6", + "III.20.7" ], - "PRI-02": [ - "5" + "PRI-06": [ + "I.3", + "I.3.1", + "I.3.2", + "I.3.3", + "I.3.4", + "I.3.5" ], - "PRI-02.1": [ - "5", - "19" + "PRI-06.4": [ + "I.10", + "I.10.1", + "I.10.2", + "I.10.3" + ] + } + }, + "framework_to_scf": { + "total_mappings": 61, + "mappings": { + "I.12": [ + "IRO-10" ], - "PRI-02.2": [ - "5" + "I.12.1": [ + "IRO-10" ], - "PRI-03": [ - "5" + "I.12.2": [ + "IRO-10" ], - "PRI-03.1": [ - "5" + "III.20-1": [ + "PRI-01.6" ], - "PRI-03.2": [ - "5" + "I.5": [ + "PRI-01.11" ], - "PRI-04": [ - "5", - "19" + "I.8-1": [ + "PRI-02" ], - "PRI-04.1": [ - "5", - "19" + "I.8.1-1": [ + "PRI-02" ], - "PRI-05": [ - "5", - "19" + "I.8.2-1": [ + "PRI-02" ], - "PRI-05.4": [ - "5" + "I.8.3-1": [ + "PRI-02" ], - "PRI-06": [ - "3" + "I.8.4-1": [ + "PRI-02" ], - "PRI-06.1": [ - "3" + "I.8.5-1": [ + "PRI-02" ], - "PRM-05": [ - "27" + "I.8.6-1": [ + "PRI-02" ], - "SEA-01": [ - "21" + "I.8-2": [ + "PRI-02" ], - "SEA-02": [ - "21" + "I.8.1-2": [ + "PRI-02" ], - "SEA-03": [ - "21" - ] - } - }, - "framework_to_scf": { - "total_mappings": 8, - "mappings": { - "3": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" - ], - "5": [ - "PRI-02", - "PRI-02.1", - "PRI-02.2", - "PRI-03", - "PRI-03.1", - "PRI-03.2", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.4" - ], - "12": [ - "IRO-04.1" - ], - "19": [ - "PRI-02.1", - "PRI-04", - "PRI-04.1", - "PRI-05" - ], - "21": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "27": [ - "GOV-01", - "CPL-01", - "CPL-02", - "PRM-05" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" + "I.8.2-2": [ + "PRI-02" + ], + "I.8.3-2": [ + "PRI-02" + ], + "I.8.4-2": [ + "PRI-02" + ], + "I.8.5-2": [ + "PRI-02" + ], + "I.8.6-2": [ + "PRI-02" + ], + "I.9": [ + "PRI-02" + ], + "I.9.1": [ + "PRI-02" + ], + "I.9.2": [ + "PRI-02" + ], + "I.9.3": [ + "PRI-02" + ], + "I.9.4": [ + "PRI-02" + ], + "I.9.5": [ + "PRI-02" + ], + "I.7": [ + "PRI-03" + ], + "I.11": [ + "PRI-05.2" + ], + "I.6": [ + "PRI-05.4" + ], + "I.6.1": [ + "PRI-05.4" + ], + "I.6.2": [ + "PRI-05.4" + ], + "I.6.3": [ + "PRI-05.4" + ], + "I.6.4": [ + "PRI-05.4" + ], + "I.6.5": [ + "PRI-05.4" + ], + "I.6.6": [ + "PRI-05.4" + ], + "III.19": [ + "PRI-05.4" + ], + "III.19.1": [ + "PRI-05.4" + ], + "III.19.2": [ + "PRI-05.4" + ], + "III.19.3": [ + "PRI-05.4" + ], + "III.19.4": [ + "PRI-05.4" + ], + "III.19.5": [ + "PRI-05.4" + ], + "III.19.6": [ + "PRI-05.4" + ], + "III.19.7": [ + "PRI-05.4" + ], + "III.19.8": [ + "PRI-05.4" + ], + "III.20": [ + "PRI-05.4" + ], + "III.20.1": [ + "PRI-05.4" + ], + "III.20.2": [ + "PRI-05.4" + ], + "III.20.3": [ + "PRI-05.4" + ], + "III.20.4": [ + "PRI-05.4" + ], + "III.20.5": [ + "PRI-05.4" + ], + "III.20.6": [ + "PRI-05.4" + ], + "III.20.7": [ + "PRI-05.4" + ], + "I.3": [ + "PRI-06" + ], + "I.3.1": [ + "PRI-06" + ], + "I.3.2": [ + "PRI-06" + ], + "I.3.3": [ + "PRI-06" + ], + "I.3.4": [ + "PRI-06" + ], + "I.3.5": [ + "PRI-06" + ], + "I.10": [ + "PRI-06.4" + ], + "I.10.1": [ + "PRI-06.4" + ], + "I.10.2": [ + "PRI-06.4" + ], + "I.10.3": [ + "PRI-06.4" ] } } diff --git a/docs/api/crosswalks/emea-aut-dpa-2018.json b/docs/api/crosswalks/emea-aut-dpa-2018.json new file mode 100644 index 00000000..00f74946 --- /dev/null +++ b/docs/api/crosswalks/emea-aut-dpa-2018.json @@ -0,0 +1,452 @@ +{ + "framework_id": "emea-aut-dpa-2018", + "display_name": "Austria - Data Protection Act (2018)", + "scf_to_framework": { + "total_mappings": 28, + "mappings": { + "CPL-01.3": [ + "§ 37(3)" + ], + "CPL-05.2": [ + "§ 51", + "§ 52", + "§ 53" + ], + "END-13.2": [ + "§ 12(2)" + ], + "HRS-05.7": [ + "§ 6(3)" + ], + "HRS-06.1": [ + "§ 5(1)" + ], + "IRO-10": [ + "§ 55(1)", + "§ 55(2)", + "§ 56(1)", + "§ 56(2)" + ], + "PRI-01.4": [ + "§ 5(1)", + "§ 57(1)", + "§ 57(2)", + "§ 57(3)", + "§ 57(4)" + ], + "PRI-01.5": [ + "§ 58(1)", + "§ 58(2)", + "§ 58(3)", + "§ 59(1)", + "§ 59(2)", + "§ 59(3)", + "§ 59(5)", + "§ 59(6)", + "§ 59(7)" + ], + "PRI-01.6": [ + "§ 6(1)", + "§ 13(1)", + "§ 54(1)" + ], + "PRI-01.11": [ + "§ 1(1)", + "§ 1(2)", + "§ 1(3)", + "§ 1(4)", + "§ 6(2)", + "§ 8(1)", + "§ 8(2)", + "§ 8(3)", + "§ 37(1)", + "§ 37(5)", + "§ 37(8)", + "§ 45(3)" + ], + "PRI-02": [ + "§ 43(1)", + "§ 43(2)", + "§ 43(3)", + "§ 43(4)" + ], + "PRI-03": [ + "§ 8(1)", + "§ 12(1)", + "§ 12(2)", + "§ 12(3)", + "§ 12(4)" + ], + "PRI-05": [ + "§ 13(3)", + "§ 37(2)" + ], + "PRI-05.1": [ + "§ 7(2)" + ], + "PRI-05.2": [ + "§ 37(6)", + "§ 37(7)" + ], + "PRI-05.4": [ + "§ 7(1)", + "§ 7(6)", + "§ 38", + "§ 39", + "§ 40(1)", + "§ 40(2)", + "§ 40(3)" + ], + "PRI-05.7": [ + "§ 37(4)" + ], + "PRI-06": [ + "§ 42(1)", + "§ 42(2)", + "§ 44(1)", + "§ 44(5)" + ], + "PRI-06.1": [ + "§ 45(1)" + ], + "PRI-06.2": [ + "§ 45(5)" + ], + "PRI-06.4": [ + "§ 42(3)", + "§ 42(4)", + "§ 42(5)", + "§ 42(6)", + "§ 45(8)", + "§ 45(9)", + "§ 44(3)", + "§ 44(4)", + "§ 45(4)" + ], + "PRI-06.5": [ + "§ 45(2)" + ], + "PRI-07.1": [ + "§ 48(1)", + "§ 48(2)", + "§ 48(3)", + "§ 48(4)", + "§ 48(5)", + "§ 48(6)" + ], + "PRI-07.2": [ + "§ 47" + ], + "PRI-07.5": [ + "§ 44(4)" + ], + "PRI-14": [ + "§ 13(2)", + "§ 49(1)", + "§ 49(2)", + "§ 49(3)", + "§ 50(1)", + "§ 50(2)", + "§ 50(3)", + "§ 50(5)" + ], + "PRI-19": [ + "§ 41(1)", + "§ 41(2)", + "§ 41(3)" + ], + "SAT-03.3": [ + "§ 6(3)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 93, + "mappings": { + "§ 37(3)": [ + "CPL-01.3" + ], + "§ 51": [ + "CPL-05.2" + ], + "§ 52": [ + "CPL-05.2" + ], + "§ 53": [ + "CPL-05.2" + ], + "§ 12(2)": [ + "END-13.2", + "PRI-03" + ], + "§ 6(3)": [ + "HRS-05.7", + "SAT-03.3" + ], + "§ 5(1)": [ + "HRS-06.1", + "PRI-01.4" + ], + "§ 55(1)": [ + "IRO-10" + ], + "§ 55(2)": [ + "IRO-10" + ], + "§ 56(1)": [ + "IRO-10" + ], + "§ 56(2)": [ + "IRO-10" + ], + "§ 57(1)": [ + "PRI-01.4" + ], + "§ 57(2)": [ + "PRI-01.4" + ], + "§ 57(3)": [ + "PRI-01.4" + ], + "§ 57(4)": [ + "PRI-01.4" + ], + "§ 58(1)": [ + "PRI-01.5" + ], + "§ 58(2)": [ + "PRI-01.5" + ], + "§ 58(3)": [ + "PRI-01.5" + ], + "§ 59(1)": [ + "PRI-01.5" + ], + "§ 59(2)": [ + "PRI-01.5" + ], + "§ 59(3)": [ + "PRI-01.5" + ], + "§ 59(5)": [ + "PRI-01.5" + ], + "§ 59(6)": [ + "PRI-01.5" + ], + "§ 59(7)": [ + "PRI-01.5" + ], + "§ 6(1)": [ + "PRI-01.6" + ], + "§ 13(1)": [ + "PRI-01.6" + ], + "§ 54(1)": [ + "PRI-01.6" + ], + "§ 1(1)": [ + "PRI-01.11" + ], + "§ 1(2)": [ + "PRI-01.11" + ], + "§ 1(3)": [ + "PRI-01.11" + ], + "§ 1(4)": [ + "PRI-01.11" + ], + "§ 6(2)": [ + "PRI-01.11" + ], + "§ 8(1)": [ + "PRI-01.11", + "PRI-03" + ], + "§ 8(2)": [ + "PRI-01.11" + ], + "§ 8(3)": [ + "PRI-01.11" + ], + "§ 37(1)": [ + "PRI-01.11" + ], + "§ 37(5)": [ + "PRI-01.11" + ], + "§ 37(8)": [ + "PRI-01.11" + ], + "§ 45(3)": [ + "PRI-01.11" + ], + "§ 43(1)": [ + "PRI-02" + ], + "§ 43(2)": [ + "PRI-02" + ], + "§ 43(3)": [ + "PRI-02" + ], + "§ 43(4)": [ + "PRI-02" + ], + "§ 12(1)": [ + "PRI-03" + ], + "§ 12(3)": [ + "PRI-03" + ], + "§ 12(4)": [ + "PRI-03" + ], + "§ 13(3)": [ + "PRI-05" + ], + "§ 37(2)": [ + "PRI-05" + ], + "§ 7(2)": [ + "PRI-05.1" + ], + "§ 37(6)": [ + "PRI-05.2" + ], + "§ 37(7)": [ + "PRI-05.2" + ], + "§ 7(1)": [ + "PRI-05.4" + ], + "§ 7(6)": [ + "PRI-05.4" + ], + "§ 38": [ + "PRI-05.4" + ], + "§ 39": [ + "PRI-05.4" + ], + "§ 40(1)": [ + "PRI-05.4" + ], + "§ 40(2)": [ + "PRI-05.4" + ], + "§ 40(3)": [ + "PRI-05.4" + ], + "§ 37(4)": [ + "PRI-05.7" + ], + "§ 42(1)": [ + "PRI-06" + ], + "§ 42(2)": [ + "PRI-06" + ], + "§ 44(1)": [ + "PRI-06" + ], + "§ 44(5)": [ + "PRI-06" + ], + "§ 45(1)": [ + "PRI-06.1" + ], + "§ 45(5)": [ + "PRI-06.2" + ], + "§ 42(3)": [ + "PRI-06.4" + ], + "§ 42(4)": [ + "PRI-06.4" + ], + "§ 42(5)": [ + "PRI-06.4" + ], + "§ 42(6)": [ + "PRI-06.4" + ], + "§ 45(8)": [ + "PRI-06.4" + ], + "§ 45(9)": [ + "PRI-06.4" + ], + "§ 44(3)": [ + "PRI-06.4" + ], + "§ 44(4)": [ + "PRI-06.4", + "PRI-07.5" + ], + "§ 45(4)": [ + "PRI-06.4" + ], + "§ 45(2)": [ + "PRI-06.5" + ], + "§ 48(1)": [ + "PRI-07.1" + ], + "§ 48(2)": [ + "PRI-07.1" + ], + "§ 48(3)": [ + "PRI-07.1" + ], + "§ 48(4)": [ + "PRI-07.1" + ], + "§ 48(5)": [ + "PRI-07.1" + ], + "§ 48(6)": [ + "PRI-07.1" + ], + "§ 47": [ + "PRI-07.2" + ], + "§ 13(2)": [ + "PRI-14" + ], + "§ 49(1)": [ + "PRI-14" + ], + "§ 49(2)": [ + "PRI-14" + ], + "§ 49(3)": [ + "PRI-14" + ], + "§ 50(1)": [ + "PRI-14" + ], + "§ 50(2)": [ + "PRI-14" + ], + "§ 50(3)": [ + "PRI-14" + ], + "§ 50(5)": [ + "PRI-14" + ], + "§ 41(1)": [ + "PRI-19" + ], + "§ 41(2)": [ + "PRI-19" + ], + "§ 41(3)": [ + "PRI-19" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-aut-fappd-2000.json b/docs/api/crosswalks/emea-aut-fappd-2000.json deleted file mode 100644 index f4c20984..00000000 --- a/docs/api/crosswalks/emea-aut-fappd-2000.json +++ /dev/null @@ -1,376 +0,0 @@ -{ - "framework_id": "emea-aut-fappd-2000", - "display_name": "Austria - Federal Act concerning the Protection of Personal Data (2000)", - "scf_to_framework": { - "total_mappings": 63, - "mappings": { - "GOV-01": [ - "Sec 14", - "Sec 15" - ], - "GOV-02": [ - "Sec 14", - "Sec 15" - ], - "GOV-03": [ - "Sec 14", - "Sec 15" - ], - "GOV-04": [ - "Sec 14", - "Sec 15" - ], - "AST-01": [ - "Sec 14", - "Sec 15" - ], - "AST-02": [ - "Sec 14", - "Sec 15" - ], - "AST-03": [ - "Sec 14", - "Sec 15" - ], - "AST-04": [ - "Sec 14", - "Sec 15" - ], - "BCD-01": [ - "Sec 14", - "Sec 15" - ], - "CAP-01": [ - "Sec 14", - "Sec 15" - ], - "CHG-01": [ - "Sec 14", - "Sec 15" - ], - "CLD-01": [ - "Sec 14", - "Sec 15" - ], - "CPL-01": [ - "Sec 14", - "Sec 15" - ], - "CFG-01": [ - "Sec 14", - "Sec 15" - ], - "MON-01": [ - "Sec 14", - "Sec 15" - ], - "MON-01.16": [ - "Sec 14", - "Sec 15" - ], - "CRY-01": [ - "Sec 14", - "Sec 15" - ], - "DCH-01": [ - "Sec 14", - "Sec 15" - ], - "DCH-22.1": [ - "Sec 27" - ], - "DCH-24": [ - "Sec 10" - ], - "DCH-24.1": [ - "Sec 10" - ], - "DCH-25": [ - "Sec 10" - ], - "EMB-01": [ - "Sec 14", - "Sec 15" - ], - "END-01": [ - "Sec 14", - "Sec 15" - ], - "HRS-01": [ - "Sec 14", - "Sec 15" - ], - "IAC-01": [ - "Sec 14", - "Sec 15" - ], - "IRO-01": [ - "Sec 14", - "Sec 15" - ], - "IRO-14": [ - "Sec 10" - ], - "IAO-01": [ - "Sec 14", - "Sec 15" - ], - "MNT-01": [ - "Sec 14", - "Sec 15" - ], - "MDM-01": [ - "Sec 14", - "Sec 15" - ], - "NET-01": [ - "Sec 14", - "Sec 15" - ], - "PES-01": [ - "Sec 14", - "Sec 15" - ], - "PRI-01": [ - "Sec 14", - "Sec 15" - ], - "PRI-02.1": [ - "Sec 6" - ], - "PRI-03": [ - "Sec 8" - ], - "PRI-03.2": [ - "Sec 8" - ], - "PRI-04": [ - "Sec 6" - ], - "PRI-04.1": [ - "Sec 6" - ], - "PRI-05": [ - "Sec 7" - ], - "PRI-05.1": [ - "Sec 12" - ], - "PRI-05.4": [ - "Sec 12" - ], - "PRI-06": [ - "Sec 26" - ], - "PRI-06.1": [ - "Sec 27" - ], - "PRI-06.3": [ - "Sec 28" - ], - "PRI-07": [ - "Sec 10" - ], - "PRI-07.1": [ - "Sec 10" - ], - "PRI-15": [ - "Sec 16", - "Sec 17" - ], - "PRM-01": [ - "Sec 14", - "Sec 15" - ], - "RSK-01": [ - "Sec 14", - "Sec 15" - ], - "SEA-01": [ - "Sec 14", - "Sec 15" - ], - "SEA-02": [ - "Sec 14", - "Sec 15" - ], - "SEA-03": [ - "Sec 14", - "Sec 15" - ], - "SEA-15": [ - "Sec 10" - ], - "OPS-01": [ - "Sec 14", - "Sec 15" - ], - "SAT-01": [ - "Sec 14", - "Sec 15" - ], - "TDA-01": [ - "Sec 14", - "Sec 15" - ], - "TPM-01": [ - "Sec 14", - "Sec 15" - ], - "TPM-04.4": [ - "Sec 10" - ], - "THR-01": [ - "Sec 14", - "Sec 15" - ], - "VPM-01": [ - "Sec 14", - "Sec 15" - ], - "WEB-01": [ - "Sec 14", - "Sec 15" - ], - "WEB-02": [ - "Sec 14", - "Sec 15" - ] - } - }, - "framework_to_scf": { - "total_mappings": 12, - "mappings": { - "Sec 14": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-04", - "AST-01", - "AST-02", - "AST-03", - "AST-04", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "CPL-01", - "CFG-01", - "MON-01", - "MON-01.16", - "CRY-01", - "DCH-01", - "EMB-01", - "END-01", - "HRS-01", - "IAC-01", - "IRO-01", - "IAO-01", - "MNT-01", - "MDM-01", - "NET-01", - "PES-01", - "PRI-01", - "PRM-01", - "RSK-01", - "SEA-01", - "SEA-02", - "SEA-03", - "OPS-01", - "SAT-01", - "TDA-01", - "TPM-01", - "THR-01", - "VPM-01", - "WEB-01", - "WEB-02" - ], - "Sec 15": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-04", - "AST-01", - "AST-02", - "AST-03", - "AST-04", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "CPL-01", - "CFG-01", - "MON-01", - "MON-01.16", - "CRY-01", - "DCH-01", - "EMB-01", - "END-01", - "HRS-01", - "IAC-01", - "IRO-01", - "IAO-01", - "MNT-01", - "MDM-01", - "NET-01", - "PES-01", - "PRI-01", - "PRM-01", - "RSK-01", - "SEA-01", - "SEA-02", - "SEA-03", - "OPS-01", - "SAT-01", - "TDA-01", - "TPM-01", - "THR-01", - "VPM-01", - "WEB-01", - "WEB-02" - ], - "Sec 27": [ - "DCH-22.1", - "PRI-06.1" - ], - "Sec 10": [ - "DCH-24", - "DCH-24.1", - "DCH-25", - "IRO-14", - "PRI-07", - "PRI-07.1", - "SEA-15", - "TPM-04.4" - ], - "Sec 6": [ - "PRI-02.1", - "PRI-04", - "PRI-04.1" - ], - "Sec 8": [ - "PRI-03", - "PRI-03.2" - ], - "Sec 7": [ - "PRI-05" - ], - "Sec 12": [ - "PRI-05.1", - "PRI-05.4" - ], - "Sec 26": [ - "PRI-06" - ], - "Sec 28": [ - "PRI-06.3" - ], - "Sec 16": [ - "PRI-15" - ], - "Sec 17": [ - "PRI-15" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-bel-act-30-2018.json b/docs/api/crosswalks/emea-bel-act-30-2018.json new file mode 100644 index 00000000..0b2cce7b --- /dev/null +++ b/docs/api/crosswalks/emea-bel-act-30-2018.json @@ -0,0 +1,490 @@ +{ + "framework_id": "emea-bel-act-30-2018", + "display_name": "Belgium - Act of 30 July 2018", + "scf_to_framework": { + "total_mappings": 27, + "mappings": { + "CPL-01.3": [ + "Title 2, Chapter II, Art. 29(5)" + ], + "DCH-23": [ + "Title 4, Chapter III, Section 3, Art. 198", + "Title 4, Chapter III, Section 3, Art. 199", + "Title 4, Chapter III, Section 3, Art. 200", + "Title 4, Chapter III, Section 3, Art. 201" + ], + "IRO-10": [ + "Title 2, Chapter IV, Section 4, Art. 61(1)", + "Title 2, Chapter IV, Section 4, Art. 61(2)", + "Title 2, Chapter IV, Section 4, Art. 61(3)", + "Title 2, Chapter IV, Section 4, Art. 61(4)", + "Title 2, Chapter IV, Section 4, Art. 61(5)", + "Title 2, Chapter IV, Section 4, Art. 61(6)", + "Title 2, Chapter IV, Section 4, Art. 62(1)", + "Title 2, Chapter IV, Section 4, Art. 62(2)", + "Title 2, Chapter IV, Section 4, Art. 62(3)", + "Title 2, Chapter IV, Section 4, Art. 62(4)", + "Title 2, Chapter IV, Section 4, Art. 62(5)" + ], + "PRI-01.4": [ + "Title 2, Chapter IV, Section 5, Art. 63", + "Title 2, Chapter IV, Section 5, Art. 64", + "Title 2, Chapter IV, Section 5, Art. 65", + "Title 4, Chapter II, Art. 190", + "Title 4, Chapter II, Art. 191", + "Title 4, Chapter II, Art. 192" + ], + "PRI-01.5": [ + "Title 2, Chapter V, Art. 66(1)", + "Title 2, Chapter V, Art. 66(2)", + "Title 2, Chapter V, Art. 67", + "Title 2, Chapter V, Art. 68(1)", + "Title 2, Chapter V, Art. 68(2)", + "Title 2, Chapter V, Art. 68(3)", + "Title 2, Chapter V, Art. 69(1)", + "Title 2, Chapter V, Art. 69(2)", + "Title 2, Chapter V, Art. 69(3)", + "Title 2, Chapter V, Art. 70(1)", + "Title 2, Chapter V, Art. 70(2)", + "Title 2, Chapter V, Art. 70(3)" + ], + "PRI-01.6": [ + "Title 2, Chapter II, Art. 34(2)", + "Title 2, Chapter III, Art. 45(4)", + "Title 2, Chapter IV, Section 1, Art. 50", + "Title 2, Chapter IV, Section 1, Art. 51(1)", + "Title 2, Chapter IV, Section 1, Art. 51(2)", + "Title 2, Chapter IV, Section 4, Art. 60(1)", + "Title 2, Chapter IV, Section 4, Art. 60(2)" + ], + "PRI-01.11": [ + "Title 1, Section III, Art. 14(2)", + "Title 2, Chapter II, Art. 28", + "Title 2, Chapter II, Art. 32(1)", + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter II, Art. 34(1)", + "Title 2, Chapter III, Art. 39(3)", + "Title 2, Chapter III, Art. 45(3)", + "Title 4, Chapter III, Section 2, Art. 194", + "Title 4, Chapter III, Section 2, Art. 195", + "Title 4, Chapter III, Section 2, Art. 196", + "Title 4, Chapter III, Section 2, Art. 197", + "Title 4, Chapter III, Section 3, Art. 202(1)", + "Title 4, Chapter III, Section 3, Art. 202(2)" + ], + "PRI-02": [ + "Title 2, Chapter III, Art. 37(1)", + "Title 2, Chapter III, Art. 37(2)", + "Title 4, Chapter III, Section 1, Art. 193" + ], + "PRI-03.3": [ + "Title 1, Chapter II, Art. 7" + ], + "PRI-04": [ + "Title 2, Chapter II, Art. 29(1)", + "Title 2, Chapter II, Art. 29(2)" + ], + "PRI-04.1": [ + "Title 1, Section III, Art. 14(4)", + "Title 2, Chapter II, Art. 33(1)", + "Title 2, Chapter II, Art. 33(2)" + ], + "PRI-05": [ + "Title 2, Chapter II, Art. 30" + ], + "PRI-05.2": [ + "Title 2, Chapter II, Art. 32(2)" + ], + "PRI-05.4": [ + "Title 1, Chapter II, Art. 8(3)", + "Title 1, Chapter II, Art. 9", + "Title 1, Chapter II, Art. 10(1)", + "Title 2, Chapter III, Art. 45(2)" + ], + "PRI-05.7": [ + "Title 1, Chapter II, Art. 8(2)", + "Title 1, Chapter II, Art. 10(2)", + "Title 2, Chapter II, Art. 31" + ], + "PRI-06": [ + "Title 2, Chapter III, Art. 36(2)", + "Title 2, Chapter III, Art. 38(1)", + "Title 2, Chapter III, Art. 38(2)", + "Title 2, Chapter III, Art. 39(1)" + ], + "PRI-06.2": [ + "Title 2, Chapter III, Art. 39(5)", + "Title 2, Chapter III, Art. 39(6)" + ], + "PRI-06.4": [ + "Title 2, Chapter III, Art. 36(3)", + "Title 2, Chapter III, Art. 38(3)", + "Title 2, Chapter III, Art. 39(4)", + "Title 2, Chapter III, Art. 40" + ], + "PRI-06.5": [ + "Title 2, Chapter III, Art. 39(2)" + ], + "PRI-07.1": [ + "Title 2, Chapter IV, Section 3, Art. 53(1)", + "Title 2, Chapter IV, Section 3, Art. 53(2)", + "Title 2, Chapter IV, Section 3, Art. 53(3)", + "Title 2, Chapter IV, Section 3, Art. 53(4)", + "Title 2, Chapter IV, Section 3, Art. 53(5)", + "Title 2, Chapter IV, Section 3, Art. 54" + ], + "PRI-07.2": [ + "Title 2, Chapter IV, Section 2, Art. 52" + ], + "PRI-07.4": [ + "Title 2, Chapter III, Art. 36(4)" + ], + "PRI-07.5": [ + "Title 2, Chapter III, Art. 36(5)" + ], + "PRI-14": [ + "Title 1, Section III, Art. 14(3)", + "Title 2, Chapter III, Art. 45(5)", + "Title 2, Chapter IV, Section 4, Art. 55(1)", + "Title 2, Chapter IV, Section 4, Art. 55(2)", + "Title 2, Chapter IV, Section 4, Art. 55(3)", + "Title 2, Chapter IV, Section 4, Art. 56(1)", + "Title 2, Chapter IV, Section 4, Art. 56(2)", + "Title 2, Chapter IV, Section 4, Art. 56(3)", + "Title 2, Chapter IV, Section 4, Art. 57", + "Title 2, Chapter IV, Section 4, Art. 58" + ], + "PRI-17": [ + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter III, Art. 36(1)" + ], + "PRI-18": [ + "Title 2, Chapter III, Art. 38(4)" + ], + "PRI-19": [ + "Title 2, Chapter II, Art. 35" + ] + } + }, + "framework_to_scf": { + "total_mappings": 105, + "mappings": { + "Title 2, Chapter II, Art. 29(5)": [ + "CPL-01.3" + ], + "Title 4, Chapter III, Section 3, Art. 198": [ + "DCH-23" + ], + "Title 4, Chapter III, Section 3, Art. 199": [ + "DCH-23" + ], + "Title 4, Chapter III, Section 3, Art. 200": [ + "DCH-23" + ], + "Title 4, Chapter III, Section 3, Art. 201": [ + "DCH-23" + ], + "Title 2, Chapter IV, Section 4, Art. 61(1)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 61(2)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 61(3)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 61(4)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 61(5)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 61(6)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 62(1)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 62(2)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 62(3)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 62(4)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 4, Art. 62(5)": [ + "IRO-10" + ], + "Title 2, Chapter IV, Section 5, Art. 63": [ + "PRI-01.4" + ], + "Title 2, Chapter IV, Section 5, Art. 64": [ + "PRI-01.4" + ], + "Title 2, Chapter IV, Section 5, Art. 65": [ + "PRI-01.4" + ], + "Title 4, Chapter II, Art. 190": [ + "PRI-01.4" + ], + "Title 4, Chapter II, Art. 191": [ + "PRI-01.4" + ], + "Title 4, Chapter II, Art. 192": [ + "PRI-01.4" + ], + "Title 2, Chapter V, Art. 66(1)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 66(2)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 67": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 68(1)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 68(2)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 68(3)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 69(1)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 69(2)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 69(3)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 70(1)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 70(2)": [ + "PRI-01.5" + ], + "Title 2, Chapter V, Art. 70(3)": [ + "PRI-01.5" + ], + "Title 2, Chapter II, Art. 34(2)": [ + "PRI-01.6" + ], + "Title 2, Chapter III, Art. 45(4)": [ + "PRI-01.6" + ], + "Title 2, Chapter IV, Section 1, Art. 50": [ + "PRI-01.6" + ], + "Title 2, Chapter IV, Section 1, Art. 51(1)": [ + "PRI-01.6" + ], + "Title 2, Chapter IV, Section 1, Art. 51(2)": [ + "PRI-01.6" + ], + "Title 2, Chapter IV, Section 4, Art. 60(1)": [ + "PRI-01.6" + ], + "Title 2, Chapter IV, Section 4, Art. 60(2)": [ + "PRI-01.6" + ], + "Title 1, Section III, Art. 14(2)": [ + "PRI-01.11" + ], + "Title 2, Chapter II, Art. 28": [ + "PRI-01.11" + ], + "Title 2, Chapter II, Art. 32(1)": [ + "PRI-01.11" + ], + "Title 2, Chapter II, Art. 32(3)": [ + "PRI-01.11", + "PRI-17" + ], + "Title 2, Chapter II, Art. 34(1)": [ + "PRI-01.11" + ], + "Title 2, Chapter III, Art. 39(3)": [ + "PRI-01.11" + ], + "Title 2, Chapter III, Art. 45(3)": [ + "PRI-01.11" + ], + "Title 4, Chapter III, Section 2, Art. 194": [ + "PRI-01.11" + ], + "Title 4, Chapter III, Section 2, Art. 195": [ + "PRI-01.11" + ], + "Title 4, Chapter III, Section 2, Art. 196": [ + "PRI-01.11" + ], + "Title 4, Chapter III, Section 2, Art. 197": [ + "PRI-01.11" + ], + "Title 4, Chapter III, Section 3, Art. 202(1)": [ + "PRI-01.11" + ], + "Title 4, Chapter III, Section 3, Art. 202(2)": [ + "PRI-01.11" + ], + "Title 2, Chapter III, Art. 37(1)": [ + "PRI-02" + ], + "Title 2, Chapter III, Art. 37(2)": [ + "PRI-02" + ], + "Title 4, Chapter III, Section 1, Art. 193": [ + "PRI-02" + ], + "Title 1, Chapter II, Art. 7": [ + "PRI-03.3" + ], + "Title 2, Chapter II, Art. 29(1)": [ + "PRI-04" + ], + "Title 2, Chapter II, Art. 29(2)": [ + "PRI-04" + ], + "Title 1, Section III, Art. 14(4)": [ + "PRI-04.1" + ], + "Title 2, Chapter II, Art. 33(1)": [ + "PRI-04.1" + ], + "Title 2, Chapter II, Art. 33(2)": [ + "PRI-04.1" + ], + "Title 2, Chapter II, Art. 30": [ + "PRI-05" + ], + "Title 2, Chapter II, Art. 32(2)": [ + "PRI-05.2" + ], + "Title 1, Chapter II, Art. 8(3)": [ + "PRI-05.4" + ], + "Title 1, Chapter II, Art. 9": [ + "PRI-05.4" + ], + "Title 1, Chapter II, Art. 10(1)": [ + "PRI-05.4" + ], + "Title 2, Chapter III, Art. 45(2)": [ + "PRI-05.4" + ], + "Title 1, Chapter II, Art. 8(2)": [ + "PRI-05.7" + ], + "Title 1, Chapter II, Art. 10(2)": [ + "PRI-05.7" + ], + "Title 2, Chapter II, Art. 31": [ + "PRI-05.7" + ], + "Title 2, Chapter III, Art. 36(2)": [ + "PRI-06" + ], + "Title 2, Chapter III, Art. 38(1)": [ + "PRI-06" + ], + "Title 2, Chapter III, Art. 38(2)": [ + "PRI-06" + ], + "Title 2, Chapter III, Art. 39(1)": [ + "PRI-06" + ], + "Title 2, Chapter III, Art. 39(5)": [ + "PRI-06.2" + ], + "Title 2, Chapter III, Art. 39(6)": [ + "PRI-06.2" + ], + "Title 2, Chapter III, Art. 36(3)": [ + "PRI-06.4" + ], + "Title 2, Chapter III, Art. 38(3)": [ + "PRI-06.4" + ], + "Title 2, Chapter III, Art. 39(4)": [ + "PRI-06.4" + ], + "Title 2, Chapter III, Art. 40": [ + "PRI-06.4" + ], + "Title 2, Chapter III, Art. 39(2)": [ + "PRI-06.5" + ], + "Title 2, Chapter IV, Section 3, Art. 53(1)": [ + "PRI-07.1" + ], + "Title 2, Chapter IV, Section 3, Art. 53(2)": [ + "PRI-07.1" + ], + "Title 2, Chapter IV, Section 3, Art. 53(3)": [ + "PRI-07.1" + ], + "Title 2, Chapter IV, Section 3, Art. 53(4)": [ + "PRI-07.1" + ], + "Title 2, Chapter IV, Section 3, Art. 53(5)": [ + "PRI-07.1" + ], + "Title 2, Chapter IV, Section 3, Art. 54": [ + "PRI-07.1" + ], + "Title 2, Chapter IV, Section 2, Art. 52": [ + "PRI-07.2" + ], + "Title 2, Chapter III, Art. 36(4)": [ + "PRI-07.4" + ], + "Title 2, Chapter III, Art. 36(5)": [ + "PRI-07.5" + ], + "Title 1, Section III, Art. 14(3)": [ + "PRI-14" + ], + "Title 2, Chapter III, Art. 45(5)": [ + "PRI-14" + ], + "Title 2, Chapter IV, Section 4, Art. 55(1)": [ + "PRI-14" + ], + "Title 2, Chapter IV, Section 4, Art. 55(2)": [ + "PRI-14" + ], + "Title 2, Chapter IV, Section 4, Art. 55(3)": [ + "PRI-14" + ], + "Title 2, Chapter IV, Section 4, Art. 56(1)": [ + "PRI-14" + ], + "Title 2, Chapter IV, Section 4, Art. 56(2)": [ + "PRI-14" + ], + "Title 2, Chapter IV, Section 4, Art. 56(3)": [ + "PRI-14" + ], + "Title 2, Chapter IV, Section 4, Art. 57": [ + "PRI-14" + ], + "Title 2, Chapter IV, Section 4, Art. 58": [ + "PRI-14" + ], + "Title 2, Chapter III, Art. 36(1)": [ + "PRI-17" + ], + "Title 2, Chapter III, Art. 38(4)": [ + "PRI-18" + ], + "Title 2, Chapter II, Art. 35": [ + "PRI-19" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-bel-act-8-1992.json b/docs/api/crosswalks/emea-bel-act-8-1992.json deleted file mode 100644 index 2c550bee..00000000 --- a/docs/api/crosswalks/emea-bel-act-8-1992.json +++ /dev/null @@ -1,282 +0,0 @@ -{ - "framework_id": "emea-bel-act-8-1992", - "display_name": "Belgium - Act of 8 December 1992", - "scf_to_framework": { - "total_mappings": 59, - "mappings": { - "GOV-01": [ - "16" - ], - "GOV-02": [ - "16" - ], - "GOV-03": [ - "16" - ], - "GOV-04": [ - "16" - ], - "AST-01": [ - "16" - ], - "AST-02": [ - "16" - ], - "AST-03": [ - "16" - ], - "AST-04": [ - "16" - ], - "BCD-01": [ - "16" - ], - "CAP-01": [ - "16" - ], - "CHG-01": [ - "16" - ], - "CLD-01": [ - "16" - ], - "CPL-01": [ - "16" - ], - "CFG-01": [ - "16" - ], - "MON-01": [ - "16" - ], - "MON-01.16": [ - "16" - ], - "CRY-01": [ - "16" - ], - "DCH-01": [ - "16" - ], - "DCH-22.1": [ - "10", - "12" - ], - "DCH-24": [ - "Chapter 4 - 16" - ], - "DCH-24.1": [ - "Chapter 4 - 16" - ], - "EMB-01": [ - "16" - ], - "END-01": [ - "16" - ], - "HRS-01": [ - "16" - ], - "IAC-01": [ - "16" - ], - "IRO-01": [ - "16" - ], - "IAO-01": [ - "16" - ], - "MNT-01": [ - "16" - ], - "MDM-01": [ - "16" - ], - "NET-01": [ - "16" - ], - "PES-01": [ - "16" - ], - "PRI-01": [ - "4" - ], - "PRI-02": [ - "9" - ], - "PRI-02.1": [ - "45754" - ], - "PRI-03": [ - "45754" - ], - "PRI-04": [ - "45754" - ], - "PRI-04.1": [ - "45754" - ], - "PRI-05": [ - "4-7", - "21" - ], - "PRI-05.1": [ - "4-7", - "21" - ], - "PRI-05.4": [ - "4-7", - "21" - ], - "PRI-06": [ - "10", - "12" - ], - "PRI-06.1": [ - "10", - "12" - ], - "PRI-15": [ - "17" - ], - "PRM-01": [ - "16" - ], - "RSK-01": [ - "16" - ], - "RSK-08": [ - "21" - ], - "SEA-01": [ - "16" - ], - "SEA-02": [ - "16" - ], - "SEA-03": [ - "16" - ], - "SEA-15": [ - "Chapter 4 - 16" - ], - "OPS-01": [ - "16" - ], - "SAT-01": [ - "16" - ], - "TDA-01": [ - "16" - ], - "TPM-01": [ - "16" - ], - "TPM-04.4": [ - "Chapter 4 - 16" - ], - "THR-01": [ - "16" - ], - "VPM-01": [ - "16" - ], - "WEB-01": [ - "16" - ], - "WEB-02": [ - "16" - ] - } - }, - "framework_to_scf": { - "total_mappings": 10, - "mappings": { - "4": [ - "PRI-01" - ], - "9": [ - "PRI-02" - ], - "10": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" - ], - "12": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" - ], - "16": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-04", - "AST-01", - "AST-02", - "AST-03", - "AST-04", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "CPL-01", - "CFG-01", - "MON-01", - "MON-01.16", - "CRY-01", - "DCH-01", - "EMB-01", - "END-01", - "HRS-01", - "IAC-01", - "IRO-01", - "IAO-01", - "MNT-01", - "MDM-01", - "NET-01", - "PES-01", - "PRM-01", - "RSK-01", - "SEA-01", - "SEA-02", - "SEA-03", - "OPS-01", - "SAT-01", - "TDA-01", - "TPM-01", - "THR-01", - "VPM-01", - "WEB-01", - "WEB-02" - ], - "17": [ - "PRI-15" - ], - "21": [ - "PRI-05", - "PRI-05.1", - "PRI-05.4", - "RSK-08" - ], - "45754": [ - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1" - ], - "Chapter 4 - 16": [ - "DCH-24", - "DCH-24.1", - "SEA-15", - "TPM-04.4" - ], - "4-7": [ - "PRI-05", - "PRI-05.1", - "PRI-05.4" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-che-fadp-2025.json b/docs/api/crosswalks/emea-che-fadp-2025.json index 6994662e..8e52c9ed 100644 --- a/docs/api/crosswalks/emea-che-fadp-2025.json +++ b/docs/api/crosswalks/emea-che-fadp-2025.json @@ -1,105 +1,483 @@ { "framework_id": "emea-che-fadp-2025", - "display_name": "Switzerland - FADP", + "display_name": "Switzerland - Federal Act on Data Protection (FADP) (2025)", "scf_to_framework": { - "total_mappings": 16, + "total_mappings": 25, "mappings": { - "GOV-01": [ - "7" - ], "CPL-01": [ - "7" + "2.2.14.1.b", + "2.2.14.1.c", + "2.2.14.1.d" ], - "CPL-02": [ - "7" + "CPL-01.2": [ + "2.2.14.1.a" ], - "DCH-01": [ - "6", - "7" + "CPL-05.2": [ + "2.2.15.2" ], - "DCH-22.1": [ - "5" + "CPL-08": [ + "2.2.14.1", + "2.2.14.2", + "2.2.14.3" ], - "IRO-04.1": [ - "12" + "DCH-18.1": [ + "2.1.7.3" ], - "PRI-01": [ - "Inferred", - "Expectation" + "END-13.3": [ + "2.1.7.3" ], - "PRI-04": [ - "4" + "HRS-05": [ + "5.30.1", + "5.30.2", + "5.30.2.a", + "5.30.2.b", + "5.30.2.c", + "5.30.3" + ], + "IRO-10": [ + "3.24.1", + "3.24.2", + "3.24.3", + "3.24.4", + "3.24.5", + "3.24.5.a", + "3.24.5.b", + "3.24.5.c", + "3.24.5bis", + "3.24.6" + ], + "PRI-01.4": [ + "2.1.10.1", + "2.1.10.2", + "2.1.10.2.b" + ], + "PRI-01.5": [ + "2.3.16.1", + "2.3.16.2", + "2.3.16.2.a", + "2.3.16.2.b", + "2.3.16.2.c", + "2.3.16.2.d", + "2.3.16.2.e", + "2.3.16.3" + ], + "PRI-01.6": [ + "2.1.7.2", + "2.1.8.1", + "2.1.8.2" + ], + "PRI-01.11": [ + "2.1.6.1", + "2.1.6.2", + "2.1.7.1", + "4.25.6" + ], + "PRI-02": [ + "2.2.15.3", + "3.19.1", + "3.19.2", + "3.19.2.a", + "3.19.2.b", + "3.19.2.c", + "3.19.3", + "3.19.4", + "3.19.5", + "3.21.1" ], - "PRI-04.1": [ - "4" + "PRI-03": [ + "2.1.6.6", + "2.1.6.7", + "2.1.6.7.a", + "2.1.6.7.b", + "2.1.6.7.c" + ], + "PRI-04": [ + "2.1.6.3" ], "PRI-05": [ - "4" + "2.1.6.4" + ], + "PRI-05.2": [ + "2.1.6.5" ], "PRI-06": [ - "8" + "3.21.2", + "4.25.1", + "4.25.2", + "4.25.2.a", + "4.25.2.b", + "4.25.2.c", + "4.25.2.d", + "4.25.2.e", + "4.25.2.f", + "4.25.2.g", + "4.25.3", + "4.25.4", + "4.25.5", + "4.28.1", + "4.28.1.a", + "4.28.1.b", + "4.28.2" + ], + "PRI-06.4": [ + "4.25.7", + "4.28.3" ], - "PRI-06.1": [ - "5" + "PRI-14": [ + "2.1.12.1", + "2.1.12.2", + "2.1.12.2.a", + "2.1.12.2.b", + "2.1.12.2.c", + "2.1.12.2.d", + "2.1.12.2.e", + "2.1.12.2.f", + "2.1.12.2.g", + "2.1.12.3", + "2.2.15.1" ], - "PRI-15": [ - "11" + "PRI-19": [ + "3.21.3.a" ], - "SEA-01": [ - "6", - "7" + "PRI-19.2": [ + "3.21.3.b" ], - "SEA-02": [ - "6", - "7" + "PRI-19.3": [ + "3.21.3.a" ], - "SEA-03": [ - "6", - "7" + "RSK-10": [ + "3.22.1", + "3.22.2", + "3.22.2.a", + "3.22.2.b", + "3.22.3", + "3.22.4", + "3.22.5", + "3.22.5.a", + "3.22.5.b", + "3.22.5.c" + ], + "SAT-03": [ + "2.1.10.2.a" ] } }, "framework_to_scf": { - "total_mappings": 9, + "total_mappings": 104, "mappings": { - "4": [ - "PRI-04", - "PRI-04.1", + "2.2.14.1.b": [ + "CPL-01" + ], + "2.2.14.1.c": [ + "CPL-01" + ], + "2.2.14.1.d": [ + "CPL-01" + ], + "2.2.14.1.a": [ + "CPL-01.2" + ], + "2.2.15.2": [ + "CPL-05.2" + ], + "2.2.14.1": [ + "CPL-08" + ], + "2.2.14.2": [ + "CPL-08" + ], + "2.2.14.3": [ + "CPL-08" + ], + "2.1.7.3": [ + "DCH-18.1", + "END-13.3" + ], + "5.30.1": [ + "HRS-05" + ], + "5.30.2": [ + "HRS-05" + ], + "5.30.2.a": [ + "HRS-05" + ], + "5.30.2.b": [ + "HRS-05" + ], + "5.30.2.c": [ + "HRS-05" + ], + "5.30.3": [ + "HRS-05" + ], + "3.24.1": [ + "IRO-10" + ], + "3.24.2": [ + "IRO-10" + ], + "3.24.3": [ + "IRO-10" + ], + "3.24.4": [ + "IRO-10" + ], + "3.24.5": [ + "IRO-10" + ], + "3.24.5.a": [ + "IRO-10" + ], + "3.24.5.b": [ + "IRO-10" + ], + "3.24.5.c": [ + "IRO-10" + ], + "3.24.5bis": [ + "IRO-10" + ], + "3.24.6": [ + "IRO-10" + ], + "2.1.10.1": [ + "PRI-01.4" + ], + "2.1.10.2": [ + "PRI-01.4" + ], + "2.1.10.2.b": [ + "PRI-01.4" + ], + "2.3.16.1": [ + "PRI-01.5" + ], + "2.3.16.2": [ + "PRI-01.5" + ], + "2.3.16.2.a": [ + "PRI-01.5" + ], + "2.3.16.2.b": [ + "PRI-01.5" + ], + "2.3.16.2.c": [ + "PRI-01.5" + ], + "2.3.16.2.d": [ + "PRI-01.5" + ], + "2.3.16.2.e": [ + "PRI-01.5" + ], + "2.3.16.3": [ + "PRI-01.5" + ], + "2.1.7.2": [ + "PRI-01.6" + ], + "2.1.8.1": [ + "PRI-01.6" + ], + "2.1.8.2": [ + "PRI-01.6" + ], + "2.1.6.1": [ + "PRI-01.11" + ], + "2.1.6.2": [ + "PRI-01.11" + ], + "2.1.7.1": [ + "PRI-01.11" + ], + "4.25.6": [ + "PRI-01.11" + ], + "2.2.15.3": [ + "PRI-02" + ], + "3.19.1": [ + "PRI-02" + ], + "3.19.2": [ + "PRI-02" + ], + "3.19.2.a": [ + "PRI-02" + ], + "3.19.2.b": [ + "PRI-02" + ], + "3.19.2.c": [ + "PRI-02" + ], + "3.19.3": [ + "PRI-02" + ], + "3.19.4": [ + "PRI-02" + ], + "3.19.5": [ + "PRI-02" + ], + "3.21.1": [ + "PRI-02" + ], + "2.1.6.6": [ + "PRI-03" + ], + "2.1.6.7": [ + "PRI-03" + ], + "2.1.6.7.a": [ + "PRI-03" + ], + "2.1.6.7.b": [ + "PRI-03" + ], + "2.1.6.7.c": [ + "PRI-03" + ], + "2.1.6.3": [ + "PRI-04" + ], + "2.1.6.4": [ "PRI-05" ], - "5": [ - "DCH-22.1", - "PRI-06.1" + "2.1.6.5": [ + "PRI-05.2" + ], + "3.21.2": [ + "PRI-06" + ], + "4.25.1": [ + "PRI-06" + ], + "4.25.2": [ + "PRI-06" + ], + "4.25.2.a": [ + "PRI-06" + ], + "4.25.2.b": [ + "PRI-06" + ], + "4.25.2.c": [ + "PRI-06" + ], + "4.25.2.d": [ + "PRI-06" + ], + "4.25.2.e": [ + "PRI-06" + ], + "4.25.2.f": [ + "PRI-06" + ], + "4.25.2.g": [ + "PRI-06" + ], + "4.25.3": [ + "PRI-06" + ], + "4.25.4": [ + "PRI-06" + ], + "4.25.5": [ + "PRI-06" + ], + "4.28.1": [ + "PRI-06" ], - "6": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "4.28.1.a": [ + "PRI-06" ], - "7": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "4.28.1.b": [ + "PRI-06" ], - "8": [ + "4.28.2": [ "PRI-06" ], - "11": [ - "PRI-15" + "4.25.7": [ + "PRI-06.4" + ], + "4.28.3": [ + "PRI-06.4" + ], + "2.1.12.1": [ + "PRI-14" + ], + "2.1.12.2": [ + "PRI-14" + ], + "2.1.12.2.a": [ + "PRI-14" + ], + "2.1.12.2.b": [ + "PRI-14" + ], + "2.1.12.2.c": [ + "PRI-14" + ], + "2.1.12.2.d": [ + "PRI-14" + ], + "2.1.12.2.e": [ + "PRI-14" + ], + "2.1.12.2.f": [ + "PRI-14" + ], + "2.1.12.2.g": [ + "PRI-14" + ], + "2.1.12.3": [ + "PRI-14" + ], + "2.2.15.1": [ + "PRI-14" + ], + "3.21.3.a": [ + "PRI-19", + "PRI-19.3" + ], + "3.21.3.b": [ + "PRI-19.2" + ], + "3.22.1": [ + "RSK-10" + ], + "3.22.2": [ + "RSK-10" + ], + "3.22.2.a": [ + "RSK-10" + ], + "3.22.2.b": [ + "RSK-10" + ], + "3.22.3": [ + "RSK-10" + ], + "3.22.4": [ + "RSK-10" + ], + "3.22.5": [ + "RSK-10" + ], + "3.22.5.a": [ + "RSK-10" ], - "12": [ - "IRO-04.1" + "3.22.5.b": [ + "RSK-10" ], - "Inferred": [ - "PRI-01" + "3.22.5.c": [ + "RSK-10" ], - "Expectation": [ - "PRI-01" + "2.1.10.2.a": [ + "SAT-03" ] } } diff --git a/docs/api/crosswalks/emea-deu-bsrit-2017.json b/docs/api/crosswalks/emea-deu-bsrit-2017.json index dc789acc..0b589e70 100644 --- a/docs/api/crosswalks/emea-deu-bsrit-2017.json +++ b/docs/api/crosswalks/emea-deu-bsrit-2017.json @@ -5,7 +5,9 @@ "total_mappings": 91, "mappings": { "GOV-01": [ - "4.1" + "3.1", + "4.1", + "4.8" ], "GOV-01.1": [ "1.1", @@ -20,25 +22,30 @@ "2.2", "2.3", "2.4", - "2.5" + "2.5", + "4.3" ], "GOV-01.2": [ - "3.9", "3.11", "4.10", "7.5" ], + "GOV-01.3": [ + "2.2", + "4.4" + ], + "GOV-01.4": [ + "2.1" + ], "GOV-02": [ "4.2", - "4.3", "4.8" ], "GOV-03": [ "4.2", - "4.8" + "4.4" ], "GOV-04": [ - "4.4", "4.5", "4.6" ], @@ -47,44 +54,41 @@ "4.6", "4.10" ], - "GOV-04.2": [ - "4.5", - "4.6", - "4.10" + "GOV-05": [ + "2.5", + "4.9" ], "GOV-15": [ + "3.4", + "3.6", "5.1" ], "GOV-15.1": [ + "3.4", + "3.6", "5.1" ], "GOV-15.2": [ + "3.4", "5.2" ], - "AST-01": [ - "12.2" - ], "AST-01.1": [ - "12.2" + "3.3" ], "AST-02": [ - "8.2", - "12.2" - ], - "AST-04.1": [ - "12.4" + "3.3", + "8.2" ], "BCD-01": [ + "1.2(e)", "10.1", "10.2", "10.3", "10.5" ], - "BCD-02": [ - "12.2" - ], "BCD-04": [ - "10.4" + "10.4", + "10.5" ], "BCD-08": [ "10.5" @@ -111,43 +115,26 @@ "8.5" ], "CPL-01": [ - "12.5" - ], - "CPL-02": [ - "5.6" + "2.1" ], "CPL-03": [ + "3.7", "5.6" ], "CPL-03.2": [ "5.6" ], - "CFG-01": [ - "6.8" - ], "CFG-02": [ "6.8" ], "CFG-02.8": [ "8.6" ], - "MON-01": [ - "5.5", - "6.3", - "6.7" - ], "MON-01.8": [ - "5.5" - ], - "MON-01.14": [ - "6.7" - ], - "MON-01.15": [ "6.7" ], "MON-01.16": [ "5.5", - "6.3", "6.7" ], "MON-03": [ @@ -161,8 +148,7 @@ ], "DCH-02": [ "7.13", - "7.14", - "12.4" + "7.14" ], "IAC-01": [ "6.1", @@ -183,27 +169,15 @@ "6.5", "6.6" ], - "IAC-08": [ - "6.2" - ], - "IAC-15": [ - "6.2" - ], - "IAC-15.7": [ - "6.2" - ], - "IAC-17": [ - "6.2" - ], - "IAC-21": [ - "6.2" - ], "IRO-01": [ "4.7" ], "IRO-02": [ "4.7" ], + "IRO-02.4": [ + "4.7" + ], "IRO-03": [ "5.4" ], @@ -216,6 +190,18 @@ "IAO-02.2": [ "7.11" ], + "IAO-03": [ + "3.6" + ], + "IAO-05": [ + "3.8" + ], + "IAO-06": [ + "7.11" + ], + "IAO-07": [ + "7.11" + ], "PRM-01": [ "2.3", "7.4", @@ -243,6 +229,12 @@ "7.2", "7.3" ], + "PRM-05": [ + "7.6" + ], + "PRM-06": [ + "7.6" + ], "PRM-07": [ "7.1", "7.2", @@ -251,38 +243,40 @@ "RSK-01": [ "3.1", "3.2", - "3.3", - "3.4", - "3.5", - "3.6", - "3.7", - "3.8", - "3.9", - "3.10", - "3.11", - "12.3" + "3.5" ], "RSK-03.1": [ "3.3" ], + "RSK-03.2": [ + "3.4" + ], "RSK-04": [ - "3.10" + "3.9" + ], + "RSK-06": [ + "11.1" + ], + "RSK-06.3": [ + "3.9" + ], + "RSK-13": [ + "3.4" ], "SEA-01": [ - "12.1" + "1.2(d)" ], - "SEA-02": [ - "12.1" + "SEA-01.4": [ + "1.2(d)" ], - "SEA-03": [ - "12.1" + "SEA-02": [ + "1.2(d)" ], "SEA-07.1": [ "8.3" ], "OPS-03": [ "8.1", - "8.2", "11.1", "11.2", "11.3", @@ -295,22 +289,21 @@ "SAT-01": [ "4.9" ], + "SAT-01.1": [ + "4.9" + ], "TDA-01": [ + "1.2(f)", "7.7", "7.8", "7.9", - "7.10", - "7.11", - "7.12", - "7.13", - "7.14" + "7.10" ], "TDA-01.1": [ "7.7", "7.8", "7.9", "7.10", - "7.11", "7.12", "7.13", "7.14" @@ -318,6 +311,9 @@ "TDA-02": [ "7.7" ], + "TDA-02.9": [ + "7.12" + ], "TDA-06": [ "7.6", "7.7", @@ -330,10 +326,7 @@ "7.8", "7.9", "7.10", - "7.11", - "7.12", - "7.13", - "7.14" + "7.12" ], "TDA-20": [ "7.9" @@ -354,41 +347,45 @@ "TPM-05": [ "9.4" ], + "TPM-05.2": [ + "9.4" + ], + "TPM-08": [ + "9.3" + ], "THR-01": [ "3.10", "5.3" ], "THR-03": [ + "3.10", "5.3" ], "THR-09": [ "3.3", + "3.10", "5.3" ], "THR-10": [ "3.10", "5.3" - ], - "VPM-01": [ - "5.6" - ], - "VPM-06": [ - "5.6" - ], - "VPM-07": [ - "5.6" - ], - "VPM-10": [ - "5.6" ] } }, "framework_to_scf": { - "total_mappings": 93, + "total_mappings": 88, "mappings": { + "3.1": [ + "GOV-01", + "RSK-01" + ], "4.1": [ "GOV-01" ], + "4.8": [ + "GOV-01", + "GOV-02" + ], "1.1": [ "GOV-01.1", "PRM-01.1" @@ -411,21 +408,29 @@ ], "1.2(d)": [ "GOV-01.1", - "PRM-01.1" + "PRM-01.1", + "SEA-01", + "SEA-01.4", + "SEA-02" ], "1.2(e)": [ "GOV-01.1", + "BCD-01", "PRM-01.1" ], "1.2(f)": [ "GOV-01.1", - "PRM-01.1" + "PRM-01.1", + "TDA-01" ], "2.1": [ - "GOV-01.1" + "GOV-01.1", + "GOV-01.4", + "CPL-01" ], "2.2": [ - "GOV-01.1" + "GOV-01.1", + "GOV-01.3" ], "2.3": [ "GOV-01.1", @@ -437,48 +442,55 @@ "GOV-01.1" ], "2.5": [ - "GOV-01.1" + "GOV-01.1", + "GOV-05" ], - "3.9": [ - "GOV-01.2", - "RSK-01" + "4.3": [ + "GOV-01.1" ], "3.11": [ - "GOV-01.2", - "RSK-01" + "GOV-01.2" ], "4.10": [ "GOV-01.2", - "GOV-04.1", - "GOV-04.2" + "GOV-04.1" ], "7.5": [ "GOV-01.2", "PRM-01" ], - "4.2": [ - "GOV-02", + "4.4": [ + "GOV-01.3", "GOV-03" ], - "4.3": [ - "GOV-02" - ], - "4.8": [ + "4.2": [ "GOV-02", "GOV-03" ], - "4.4": [ - "GOV-04" - ], "4.5": [ "GOV-04", - "GOV-04.1", - "GOV-04.2" + "GOV-04.1" ], "4.6": [ "GOV-04", - "GOV-04.1", - "GOV-04.2" + "GOV-04.1" + ], + "4.9": [ + "GOV-05", + "SAT-01", + "SAT-01.1" + ], + "3.4": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "RSK-03.2", + "RSK-13" + ], + "3.6": [ + "GOV-15", + "GOV-15.1", + "IAO-03" ], "5.1": [ "GOV-15", @@ -487,19 +499,14 @@ "5.2": [ "GOV-15.2" ], - "12.2": [ - "AST-01", + "3.3": [ "AST-01.1", "AST-02", - "BCD-02" + "RSK-03.1", + "THR-09" ], "8.2": [ - "AST-02", - "OPS-03" - ], - "12.4": [ - "AST-04.1", - "DCH-02" + "AST-02" ], "10.1": [ "BCD-01" @@ -512,6 +519,7 @@ ], "10.5": [ "BCD-01", + "BCD-04", "BCD-08", "BCD-09" ], @@ -532,68 +540,47 @@ "8.5": [ "CHG-02" ], - "12.5": [ - "CPL-01" + "3.7": [ + "CPL-03" ], "5.6": [ - "CPL-02", "CPL-03", - "CPL-03.2", - "VPM-01", - "VPM-06", - "VPM-07", - "VPM-10" + "CPL-03.2" ], "6.8": [ - "CFG-01", "CFG-02" ], "8.6": [ "CFG-02.8" ], - "5.5": [ - "MON-01", + "6.7": [ "MON-01.8", + "MON-01.16" + ], + "5.5": [ "MON-01.16", "MON-16" ], "6.3": [ - "MON-01", - "MON-01.16", "MON-03" ], - "6.7": [ - "MON-01", - "MON-01.14", - "MON-01.15", - "MON-01.16" - ], "5.4": [ "MON-11.3", "IRO-03" ], "7.13": [ "DCH-02", - "TDA-01", - "TDA-01.1", - "TDA-09" + "TDA-01.1" ], "7.14": [ "DCH-02", - "TDA-01", - "TDA-01.1", - "TDA-09" + "TDA-01.1" ], "6.1": [ "IAC-01" ], "6.2": [ - "IAC-01", - "IAC-08", - "IAC-15", - "IAC-15.7", - "IAC-17", - "IAC-21" + "IAC-01" ], "6.4": [ "IAC-07", @@ -612,15 +599,18 @@ ], "4.7": [ "IRO-01", - "IRO-02" + "IRO-02", + "IRO-02.4" ], "7.11": [ "IAO-01", "IAO-02", "IAO-02.2", - "TDA-01", - "TDA-01.1", - "TDA-09" + "IAO-06", + "IAO-07" + ], + "3.8": [ + "IAO-05" ], "7.4": [ "PRM-01" @@ -641,50 +631,26 @@ "PRM-04", "PRM-07" ], - "3.1": [ - "RSK-01" + "7.6": [ + "PRM-05", + "PRM-06", + "TDA-06" ], "3.2": [ "RSK-01" ], - "3.3": [ - "RSK-01", - "RSK-03.1", - "THR-09" - ], - "3.4": [ - "RSK-01" - ], "3.5": [ "RSK-01" ], - "3.6": [ - "RSK-01" - ], - "3.7": [ - "RSK-01" - ], - "3.8": [ - "RSK-01" - ], - "3.10": [ - "RSK-01", + "3.9": [ "RSK-04", - "THR-01", - "THR-10" + "RSK-06.3" ], - "12.3": [ - "RSK-01" - ], - "12.1": [ - "SEA-01", - "SEA-02", - "SEA-03" - ], - "8.1": [ + "11.1": [ + "RSK-06", "OPS-03" ], - "11.1": [ + "8.1": [ "OPS-03" ], "11.2": [ @@ -708,9 +674,6 @@ "11.8": [ "OPS-03" ], - "4.9": [ - "SAT-01" - ], "7.7": [ "TDA-01", "TDA-01.1", @@ -738,18 +701,16 @@ "TDA-09" ], "7.12": [ - "TDA-01", "TDA-01.1", + "TDA-02.9", "TDA-09" ], - "7.6": [ - "TDA-06" - ], "9.1": [ "TPM-01" ], "9.3": [ - "TPM-03.1" + "TPM-03.1", + "TPM-08" ], "9.2": [ "TPM-04", @@ -759,7 +720,14 @@ "TPM-04.1" ], "9.4": [ - "TPM-05" + "TPM-05", + "TPM-05.2" + ], + "3.10": [ + "THR-01", + "THR-03", + "THR-09", + "THR-10" ], "5.3": [ "THR-01", diff --git a/docs/api/crosswalks/emea-deu-c5-2020.json b/docs/api/crosswalks/emea-deu-c5-2020.json index e8939c6c..6275f7df 100644 --- a/docs/api/crosswalks/emea-deu-c5-2020.json +++ b/docs/api/crosswalks/emea-deu-c5-2020.json @@ -2,356 +2,450 @@ "framework_id": "emea-deu-c5-2020", "display_name": "Germany - Cloud Computing Compliance Controls Catalogue (C5) (2020)", "scf_to_framework": { - "total_mappings": 239, + "total_mappings": 207, "mappings": { "GOV-01": [ + "OIS-01", + "OIS-01-BP1", + "OIS-01-DOAR" + ], + "GOV-01.1": [ "OIS-01" ], - "GOV-02": [ + "GOV-01.2": [ + "SPN-01" + ], + "GOV-01.3": [ + "OIS-01-BP3", + "SA-02-BP2" + ], + "GOV-01.4": [ "OIS-01", + "RB-22-DOAR" + ], + "GOV-02": [ "OIS-02", - "SP-01" + "OIS-06", + "SA-01", + "SA-01-BP1", + "SA-01-BP2", + "SA-01-BP3", + "SA-01-BP4", + "SA-01-BP5", + "SA-01-BP6", + "MDM-01" + ], + "GOV-02.1": [ + "SA-03" ], "GOV-03": [ - "OIS-01", - "SP-02" + "SA-02", + "SA-02-BP1", + "SA-02-BP2", + "SA-02-BP3" ], - "GOV-04": [ - "OIS-03" + "GOV-04.1": [ + "SA-01-BP4" ], "GOV-05": [ - "COM-04" + "OIS-01-BP2" ], "GOV-06": [ "OIS-05" ], "GOV-09": [ "OIS-01", - "OIS-02" + "OIS-02", + "DLL-01-BP1" + ], + "GOV-14": [ + "SA-01-BP4" + ], + "GOV-15": [ + "UP-01-BP2" + ], + "GOV-15.1": [ + "DLL-01-BP1" ], "AST-01": [ "AM-03" ], + "AST-01.2": [ + "AM-02" + ], "AST-02": [ "AM-01", - "AM-02" + "RB-12" ], "AST-02.1": [ + "AM-01" + ], + "AST-02.9": [ "AM-01", - "AM-02" + "AM-01-DOAR", + "RB-12" ], - "AST-02.2": [ + "AST-03": [ "AM-02" ], - "AST-02.4": [ - "SP-03" - ], "AST-04": [ - "COS-07" - ], - "AST-06.1": [ - "AM-02" + "KOS-06" ], "AST-09": [ - "AM-04", - "PI-03" + "AM-04" ], "AST-10": [ - "AM-04", - "AM-05" + "AM-04" ], "BCD-01": [ + "UP-01-BP4", + "RB-06", "BCM-01", "BCM-02", - "BCM-03" + "BCM-02-BP1", + "BCM-02-BP2", + "BCM-02-BP3", + "BCM-02-BP4", + "BCM-02-BP5", + "BCM-02-BP6", + "BCM-02-BP7", + "BCM-02-BP8", + "BCM-02-BP9", + "BCM-02-BP10", + "BCM-03", + "BCM-03-BP1", + "BCM-03-BP2", + "BCM-03-BP3", + "BCM-03-BP4", + "BCM-03-BP5", + "BCM-03-BP6", + "BCM-03-BP7", + "BCM-03-BP8" ], "BCD-01.4": [ - "OPS-06", - "OPS-08", - "OPS-09" + "BCM-02-BP6", + "BCM-02-BP8", + "BCM-02-BP9" ], "BCD-02": [ - "BCM-02" + "RB-12", + "BCM-02-BP4" ], - "BCD-04": [ - "PS-02", - "PS-06", - "BCM-04" + "BCD-02.3": [ + "BCM-02-BP7" ], - "BCD-05": [ - "BCM-04" + "BCD-02.4": [ + "BCM-05" + ], + "BCD-04": [ + "PS-03-BP6", + "BCM-04", + "BCM-04-DOAR", + "BCM-05-DOAR" ], "BCD-06": [ "BCM-04" ], - "BCD-08": [ - "PSS-12" - ], - "BCD-08.1": [ - "OPS-09" - ], - "BCD-09": [ - "PSS-12" - ], - "BCD-09.1": [ - "OPS-09" - ], "BCD-11": [ - "OPS-06" + "RB-06", + "RB-07" ], "BCD-11.1": [ - "OPS-06", - "OPS-07", - "OPS-08" + "RB-07" ], "BCD-11.2": [ - "OPS-06", - "PSS-12" + "RB-09" ], - "BCD-11.3": [ - "OPS-09" + "BCD-11.4": [ + "RB-06-DOAR" ], - "BCD-11.7": [ - "PS-02" + "BCD-11.5": [ + "RB-08" ], "CAP-01": [ - "OPS-01", - "OPS-02", - "OPS-03" + "RB-01" ], "CAP-03": [ - "OPS-01", - "OPS-02", - "OPS-03" + "RB-01", + "RB-01-DOAR" + ], + "CAP-04": [ + "RB-02" + ], + "CAP-05": [ + "RB-02" ], "CHG-01": [ - "DEV-03", - "DEV-08" + "BEI-03", + "BEI-03-BP1", + "BEI-03-BP2", + "BEI-05", + "BEI-06", + "BEI-08" ], "CHG-02": [ - "DEV-08" + "BEI-08", + "BEI-09-DOAR" ], "CHG-02.1": [ - "IDM-02" + "BEI-12" ], "CHG-02.2": [ - "DEV-06", - "DEV-08", - "DEV-09" - ], - "CHG-02.3": [ - "DEV-05", - "DEV-09" + "BEI-03-BP3", + "BEI-03-BP4", + "BEI-07", + "BEI-09" ], "CHG-03": [ - "DEV-05", - "BCM-02" + "BEI-04", + "BEI-06" ], - "CHG-04": [ - "DEV-09" + "CHG-05": [ + "BEI-03-BP2" ], - "CHG-04.4": [ - "DEV-09", - "PSS-08" + "CHG-07": [ + "BEI-10" ], - "CHG-04.5": [ - "DEV-07", - "DEV-08" + "CHG-07.1": [ + "BEI-10" ], "CLD-01": [ - "COS-01", - "COS-02" + "UP-01", + "UP-01-BP1", + "UP-01-BP2", + "RB-05" ], - "CLD-02": [ - "COS-01", - "COS-02" - ], - "CLD-03": [ - "COS-01", - "COS-02", - "COS-05" + "CLD-01.2": [ + "PI-02", + "PI-05" ], "CLD-04": [ - "PI-01" - ], - "CLD-05": [ - "PSS-11" + "PI-01", + "PI-04" ], "CLD-06": [ - "OPS-24" + "RB-23" ], - "CLD-07": [ - "PI-01", - "PI-02" + "CLD-06.1": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03" ], - "CLD-08": [ - "PSS-11" + "CLD-06.2": [ + "RB-10" ], - "CLD-09": [ + "CLD-07": [ + "PI-01", "PI-02", - "PSS-12" + "PI-03" ], - "CLD-11": [ - "COS-04" + "CLD-09": [ + "UP-02", + "RB-03" ], "CPL-01": [ - "SP-01", + "SA-01-BP6", "PI-02", + "DLL-01-BP2", "COM-01" ], - "CPL-02": [ - "SP-03" + "CPL-01.1": [ + "SPN-02" ], - "CPL-03": [ - "COM-03" + "CPL-01.3": [ + "UP-04", + "SPN-03-DOAR", + "COM-02-DOAR", + "COM-03-DOAR" ], - "CPL-03.1": [ - "COM-03" + "CPL-02": [ + "RB-05-DOAR", + "SPN-02", + "COM-02" ], - "CPL-03.2": [ - "COM-01" + "CPL-02.1": [ + "SPN-03" ], - "CPL-04": [ + "CPL-02.2": [ + "RB-05-DOAR", + "SPN-02", + "SPN-02-DOAR", "COM-02", + "COM-02-BP1", + "COM-02-BP2", + "COM-02-BP3", "COM-03" ], - "CPL-05": [ - "INQ-01" - ], - "CPL-05.1": [ - "INQ-02" - ], - "CPL-05.2": [ - "INQ-03", - "INQ-04" - ], - "CFG-01": [ - "AM-03" + "CPL-03": [ + "OIS-01-BP2", + "OIS-01-BP3" ], "CFG-02": [ - "AM-02", - "AM-03", - "OPS-23" - ], - "CFG-03.3": [ - "AM-02" + "RB-05", + "RB-22", + "RB-22-DOAR", + "IDM-11", + "IDM-11-BP1", + "IDM-11-BP2", + "IDM-11-BP3", + "IDM-11-BP4", + "IDM-11-BP5", + "IDM-11-DOAR", + "IDM-11-DOAR-BP1", + "IDM-11-DOAR-BP2", + "IDM-11-DOAR-BP3", + "IDM-11-DOAR-BP4", + "IDM-11-DOAR-BP5", + "IDM-11-DOAR-BP6", + "IDM-11-DOAR-BP7" ], "MON-01": [ - "OPS-10" - ], - "MON-01.2": [ - "OPS-13" - ], - "MON-01.4": [ - "OPS-13" - ], - "MON-01.16": [ - "OPS-10" + "RB-10" ], "MON-02": [ - "OPS-14" - ], - "MON-02.1": [ - "OPS-13" + "RB-10", + "RB-13", + "RB-16-DOAR", + "SIM-05" ], "MON-02.2": [ - "OPS-13" + "RB-10", + "SIM-05" ], - "MON-02.6": [ - "OIS-05" + "MON-02.7": [ + "RB-14" ], - "MON-03": [ - "OPS-15" + "MON-02.8": [ + "RB-15" ], - "MON-03.3": [ - "OPS-16" + "MON-03": [ + "RB-10" ], - "MON-05": [ - "OPS-17" + "MON-03.2": [ + "RB-14", + "RB-16" ], "MON-05.1": [ - "OPS-17" + "RB-16-DOAR" ], - "MON-08": [ - "OPS-16" + "MON-06": [ + "RB-16" ], - "MON-08.2": [ - "OPS-16" + "MON-08": [ + "RB-16" ], "MON-10": [ - "OPS-14" + "RB-13" ], "CRY-01": [ - "CRY-01" + "KRY-01", + "KRY-01-BP1", + "KRY-01-BP2", + "KRY-01-BP3", + "KRY-01-BP4", + "KRY-02" ], "CRY-03": [ - "CRY-02" - ], - "CRY-04": [ - "OPS-09" + "KRY-02", + "KRY-02-DOAR" ], "CRY-05": [ - "CRY-03" - ], - "CRY-05.1": [ - "CRY-03" + "KRY-02", + "KRY-03" ], "CRY-09": [ - "CRY-04" + "KRY-03", + "KRY-04", + "KRY-04-BP1", + "KRY-04-BP3", + "KRY-04-BP4", + "KRY-04-BP5", + "KRY-04-BP6", + "KRY-04-BP7", + "KRY-04-BP8" ], "DCH-01": [ - "COS-08" + "AM-07", + "RB-23" ], "DCH-01.1": [ "AM-06" ], + "DCH-01.2": [ + "AM-07", + "RB-11" + ], "DCH-02": [ "AM-02", + "AM-05", "AM-06", - "COS-08", - "PI-01" + "PI-01", + "SIM-02" ], "DCH-04": [ "AM-06" ], - "DCH-08": [ - "PI-03" + "DCH-07": [ + "AM-08" ], - "DCH-21": [ - "PI-03" + "DCH-09": [ + "PI-05" + ], + "DCH-11": [ + "SIM-02" + ], + "DCH-14.2": [ + "AM-08" + ], + "DCH-18": [ + "RB-06" + ], + "DCH-19": [ + "UP-02", + "RB-03" ], "END-04": [ - "OPS-04", - "OPS-05" + "RB-05" + ], + "HRS-01": [ + "HR-02", + "KOS-08-DOAR" + ], + "HRS-02": [ + "HR-01-DOAR" ], "HRS-03": [ - "PSS-08" + "UP-01-BP5", + "OIS-03-BP1", + "OIS-03-BP2", + "OIS-03-BP3", + "SA-01-BP3" ], "HRS-04": [ - "HR-01" + "HR-01", + "HR-01-BP1", + "HR-01-BP2", + "HR-01-BP3", + "HR-01-BP4" ], "HRS-04.1": [ "HR-01", - "PSS-08" + "HR-01-DOAR" ], "HRS-05": [ "HR-02", - "HR-03", - "AM-05" - ], - "HRS-05.1": [ - "HR-03" + "HR-05", + "AM-04" ], - "HRS-05.5": [ - "AM-05" + "HRS-05.7": [ + "HR-02" ], "HRS-06": [ "HR-02" ], "HRS-06.1": [ - "HR-06", - "IDM-08", - "PSS-07" + "IDM-07-DOAR", + "KOS-08" ], "HRS-07": [ "HR-04" @@ -365,1059 +459,1447 @@ ], "HRS-11": [ "OIS-04", - "IDM-01" - ], - "HRS-12": [ - "PSS-08" + "OIS-04-BP1", + "OIS-04-BP2", + "OIS-04-BP3", + "OIS-04-DOAR", + "IDM-01-BP2", + "IDM-01-BP3", + "BEI-12" ], "IAC-01": [ "IDM-01", - "PSS-05", - "PSS-09" - ], - "IAC-02": [ - "IDM-01", - "PSS-05", - "PSS-09" - ], - "IAC-03": [ - "PSS-05", - "PSS-09" + "IDM-03" ], - "IAC-03.2": [ - "PSS-05", - "PSS-09" + "IAC-01.2": [ + "IDM-02", + "IDM-03-BP2", + "IDM-08-BP2" ], - "IAC-04": [ - "PSS-05", - "PSS-09" + "IAC-06": [ + "RB-15-DOAR", + "IDM-08-BP3" ], - "IAC-05": [ - "PSS-05", - "PSS-09" + "IAC-06.3": [ + "RB-15-DOAR" ], "IAC-07": [ - "IDM-01", - "IDM-02", - "PSS-09" - ], - "IAC-07.1": [ - "PS-04", - "PSS-08" + "IDM-01-BP1", + "IDM-01-BP5", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-04", + "IDM-05" ], "IAC-08": [ - "PSS-08", - "PSS-11" + "RB-15", + "IDM-01", + "IDM-01-BP3", + "BEI-12" ], - "IAC-09": [ - "IDM-01" + "IAC-10.5": [ + "IDM-07", + "IDM-08" ], - "IAC-09.5": [ + "IAC-15": [ "IDM-02" ], - "IAC-10": [ - "IDM-08" - ], - "IAC-10.1": [ - "IDM-09", - "PSS-07" + "IAC-15.1": [ + "IDM-03-BP2", + "IDM-08-BP2" ], - "IAC-10.2": [ + "IAC-15.9": [ "IDM-09" ], - "IAC-10.4": [ - "PSS-07" - ], - "IAC-10.5": [ - "IDM-08", - "PSS-07" - ], - "IAC-15.2": [ - "IDM-04", - "PSS-09" - ], - "IAC-15.3": [ - "IDM-03" - ], "IAC-16": [ "IDM-06" ], "IAC-17": [ - "IDM-05" + "IDM-01-BP4", + "IDM-05", + "IDM-05-DOAR", + "IDM-09-DOAR" ], "IAC-20.3": [ - "IDM-06" + "IDM-12" ], "IAC-21": [ - "IDM-07" - ], - "IAC-23": [ - "PSS-06" + "IDM-03-BP1", + "IDM-03-BP2", + "IDM-03-BP4", + "IDM-10", + "IDM-12", + "IDM-13" ], - "IAC-24": [ - "PSS-06" - ], - "IAC-25": [ - "PSS-06" + "IAC-28": [ + "IDM-08-BP1" ], "IAC-28.1": [ - "IDM-01", - "IDM-02" + "IDM-01-BP1", + "IDM-01-BP6", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-06", + "IDM-09", + "BEI-09" ], "IRO-01": [ - "SIM-01" + "UP-01-BP4", + "SIM-01", + "SIM-07" ], - "IRO-02": [ - "SIM-02" - ], - "IRO-02.5": [ - "OPS-21" + "IRO-02.4": [ + "SIM-03", + "SIM-07" ], - "IRO-04.1": [ - "SIM-02" + "IRO-04": [ + "SIM-03" ], "IRO-08": [ - "SIM-03" + "SIM-01-DOAR" + ], + "IRO-09": [ + "SIM-07" ], "IRO-10": [ - "SIM-03", + "RB-20", "SIM-04" ], - "IRO-10.3": [ - "PSS-02" - ], - "IRO-12.3": [ - "OPS-21" - ], "IRO-13": [ - "SIM-05" + "SIM-04" + ], + "IAO-03": [ + "UP-01-BP2", + "UP-01-BP3", + "UP-01-BP5" ], "IAO-03.2": [ - "HR-06", - "PI-02" + "BEI-02", + "BEI-02-BP1", + "BEI-02-BP2", + "BEI-02-BP3", + "BEI-02-BP4" ], - "NET-01": [ - "PSS-10" + "MNT-01": [ + "PS-05" ], - "NET-02": [ - "PSS-10" + "MDM-01": [ + "MDM-01", + "MDM-01-BP2", + "MDM-01-BP3", + "MDM-01-BP5", + "MDM-01-DOAR" ], - "NET-03": [ - "COS-04", - "PSS-10" + "MDM-03": [ + "MDM-01-BP1" ], - "NET-03.1": [ - "COS-04" + "MDM-04": [ + "MDM-01-BP4" ], - "NET-03.2": [ - "COS-03" + "MDM-06": [ + "MDM-01-BP6" ], - "NET-04": [ - "COS-03" + "NET-02": [ + "KOS-01", + "KOS-03-DOAR" + ], + "NET-02.1": [ + "KOS-01" ], - "NET-04.6": [ - "COS-03" + "NET-02.3": [ + "KOS-03" + ], + "NET-03": [ + "KOS-01", + "KOS-02", + "KOS-03" ], - "NET-05": [ - "COS-03" + "NET-03.8": [ + "KOS-02" ], "NET-06": [ - "COS-06" + "RB-23-DOAR", + "KOS-05" ], - "NET-06.1": [ - "COS-04" + "NET-06.2": [ + "KOS-05-DOAR" ], - "NET-09": [ - "PSS-06" + "NET-06.4": [ + "KOS-05" ], - "NET-09.1": [ - "PSS-06" + "NET-06.8": [ + "KOS-04" ], - "PES-01": [ - "PS-01" + "NET-08": [ + "KOS-01", + "KOS-01-DOAR" ], - "PES-03": [ - "PS-03", - "PS-04" + "NET-12": [ + "PI-04" ], - "PES-03.1": [ + "PES-01": [ + "PS-01", + "PS-02", "PS-03" ], - "PES-03.4": [ - "PS-04" + "PES-01.1": [ + "PS-02", + "PS-03" ], - "PES-04": [ - "PS-04" + "PES-01.2": [ + "PS-01-DOAR", + "PS-03-BP1" ], - "PES-06": [ - "PS-04" + "PES-03": [ + "PS-02-DOAR" ], "PES-07": [ - "PS-01", - "PS-06" + "PS-04" ], "PES-07.3": [ - "PS-01", - "PS-06" + "PS-04" ], - "PES-07.5": [ - "PS-01" + "PES-07.7": [ + "PS-04" ], "PES-08": [ - "PS-01", - "PS-05" + "PS-03-BP1", + "PS-03-BP2", + "PS-03-BP4", + "PS-03-BP6" ], "PES-08.1": [ - "PS-05" + "PS-03-BP5" ], "PES-08.2": [ - "PS-05" - ], - "PES-08.3": [ - "PS-05" + "PS-03-BP5" ], "PES-09": [ - "PS-06", - "PS-07" - ], - "PES-09.1": [ - "PS-06", - "PS-07" + "PS-03-BP3", + "PS-03-DOAR" ], - "PES-11": [ - "PS-02" + "PES-12.1": [ + "PS-04" ], - "PRI-05": [ - "OPS-11", - "OPS-12", - "PI-03" + "PRM-01.1": [ + "SA-02-DOAR" ], - "PRI-07.1": [ - "HR-06", - "PI-02" + "PRM-02.1": [ + "SA-02-BP3" ], "RSK-01": [ - "OIS-06" + "OIS-06", + "OIS-07" + ], + "RSK-01.3": [ + "OIS-07-DOAR" + ], + "RSK-01.5": [ + "OIS-07-DOAR" ], "RSK-03": [ - "SP-03" + "OIS-03-DOAR", + "OIS-07" + ], + "RSK-03.1": [ + "OIS-03-DOAR" ], "RSK-04": [ "OIS-07", - "SP-03" + "BEI-06" ], "RSK-04.1": [ - "SP-03" - ], - "RSK-08": [ - "BCM-02" + "OIS-03-DOAR" ], - "RSK-09": [ + "RSK-04.2": [ "OIS-07" ], - "RSK-10": [ - "BCM-02" - ], - "SEA-01": [ - "COS-01" - ], - "SEA-02": [ - "COS-01" - ], - "SEA-03": [ - "COS-01" + "RSK-06.2": [ + "OIS-04-DOAR", + "SA-03-DOAR" ], - "SEA-05": [ - "OPS-24", - "COS-06" - ], - "SEA-13.1": [ - "PSS-11" + "RSK-08": [ + "BCM-02-BP5", + "BCM-04" ], - "OPS-01": [ - "SP-01" + "RSK-09": [ + "OIS-07", + "PS-04-DOAR" ], - "OPS-01.1": [ - "SP-01", - "IDM-02" + "SEA-01": [ + "UP-01-BP2", + "DLL-01-BP1" ], - "OPS-05": [ - "PSS-01" + "SEA-01.4": [ + "UP-01-BP2", + "SA-01-BP5" ], "SAT-01": [ - "HR-03", - "DEV-04" + "HR-03" ], "SAT-02": [ - "HR-03", - "DEV-04" + "HR-03" ], "SAT-03": [ - "DEV-04" + "HR-03", + "HR-03-BP1", + "HR-03-BP4", + "HR-03-DOAR" ], - "SAT-03.4": [ - "DEV-04" + "SAT-03.3": [ + "HR-03-BP2" + ], + "SAT-03.6": [ + "HR-03-BP3" ], "TDA-01": [ - "DEV-01" + "BEI-01" ], - "TDA-02": [ - "DEV-02" + "TDA-02.11": [ + "RB-21-DOAR" ], "TDA-04": [ - "DEV-02" - ], - "TDA-04.1": [ - "DEV-02" - ], - "TDA-05": [ - "DEV-02" + "UP-01", + "KOS-07" ], "TDA-06": [ - "DEV-02", - "DEV-07", - "DEV-08" + "UP-01-BP2", + "BEI-01-BP1", + "BEI-01-BP4", + "BEI-01-DOAR", + "BEI-02" ], - "TDA-07": [ - "DEV-02", - "DEV-10" + "TDA-06.7": [ + "BEI-01-BP3" ], "TDA-08": [ - "DEV-10" - ], - "TDA-09": [ - "DEV-02" - ], - "TDA-09.2": [ - "PSS-02" - ], - "TDA-09.3": [ - "PSS-02" - ], - "TDA-09.4": [ - "PSS-02" - ], - "TDA-09.5": [ - "PSS-02" - ], - "TDA-13": [ - "DEV-02" - ], - "TDA-14": [ - "DEV-02" - ], - "TDA-15": [ - "DEV-02" - ], - "TDA-19": [ - "PSS-04" + "BEI-01-BP2", + "BEI-11" ], "TDA-20": [ - "DEV-07" + "IDM-13" ], "TPM-01": [ - "SSO-01", - "SSO-03" - ], - "TPM-02": [ - "SSO-02", - "SSO-03" + "UP-01", + "DLL-01", + "DLL-02" ], "TPM-03": [ - "SSO-02", - "SSO-03" - ], - "TPM-03.1": [ - "SSO-05" + "PS-04-DOAR" ], "TPM-03.2": [ - "SSO-02" - ], - "TPM-03.3": [ - "SSO-02" + "UP-01-BP1" ], "TPM-04": [ - "SSO-05" - ], - "TPM-04.1": [ - "SSO-02", - "SSO-04" - ], - "TPM-04.4": [ - "PI-02", - "PSS-12" + "PS-04-DOAR" ], "TPM-05": [ - "HR-06", - "PI-02", - "SSO-02", - "SSO-05" - ], - "TPM-07": [ - "SSO-04" + "UP-01-BP1", + "UP-01-BP6", + "UP-03", + "OIS-03", + "DLL-01", + "DLL-01-BP1", + "DLL-01-BP2", + "DLL-01-BP3", + "DLL-01-BP4", + "BCM-05" + ], + "TPM-05.1": [ + "RB-20" + ], + "TPM-05.2": [ + "UP-01-BP6", + "DLL-01-BP2", + "DLL-01-BP4", + "DLL-01-DOAR" + ], + "TPM-05.4": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03", + "SIM-06" + ], + "TPM-05.5": [ + "UP-01-BP1" + ], + "TPM-05.8": [ + "UP-04" ], "TPM-08": [ - "SSO-04", - "SSO-05" - ], - "TPM-09": [ - "SSO-04" + "DLL-02", + "DLL-02-BP1", + "DLL-02-BP2", + "DLL-02-BP3" ], "TPM-10": [ - "SSO-04", - "SSO-05" + "OIS-03" ], - "VPM-01": [ - "OPS-18", - "PSS-02" + "THR-01": [ + "OIS-05-DOAR" + ], + "THR-03": [ + "OIS-05" ], - "VPM-01.1": [ - "PSS-02" + "THR-03.1": [ + "OIS-05-DOAR" ], - "VPM-02": [ - "OPS-18", - "PSS-02" + "VPM-01": [ + "RB-17", + "RB-17-BP2" ], "VPM-03": [ - "OPS-18", - "OPS-22", - "PSS-02" + "RB-17-BP1", + "RB-19" + ], + "VPM-03.1": [ + "RB-17-BP1", + "RB-19" ], "VPM-04": [ - "OPS-18", - "PSS-02" + "RB-17-BP2", + "RB-19", + "RB-21" ], "VPM-05": [ - "PSS-03" + "RB-17-BP2" ], "VPM-05.1": [ - "PSS-03" - ], - "VPM-05.3": [ - "OPS-19" + "RB-17-BP2" ], "VPM-06": [ - "OPS-22", - "PSS-02", - "PSS-03" - ], - "VPM-06.1": [ - "PSS-03" - ], - "VPM-06.4": [ - "OPS-20" - ], - "VPM-06.5": [ - "OPS-20" - ], - "VPM-06.6": [ - "PSS-02" - ], - "VPM-06.7": [ - "PSS-02" + "RB-17-BP1", + "RB-21" ], "VPM-07": [ - "OPS-19", - "PSS-02" - ], - "VPM-07.1": [ - "OPS-19", - "PSS-02" - ], - "WEB-06": [ - "PSS-05" + "RB-18", + "RB-18-DOAR" ] } }, "framework_to_scf": { - "total_mappings": 121, + "total_mappings": 282, "mappings": { "OIS-01": [ "GOV-01", - "GOV-02", - "GOV-03", + "GOV-01.1", + "GOV-01.4", "GOV-09" ], + "OIS-01-BP1": [ + "GOV-01" + ], + "OIS-01-DOAR": [ + "GOV-01" + ], + "SPN-01": [ + "GOV-01.2" + ], + "OIS-01-BP3": [ + "GOV-01.3", + "CPL-03" + ], + "SA-02-BP2": [ + "GOV-01.3", + "GOV-03" + ], + "RB-22-DOAR": [ + "GOV-01.4", + "CFG-02" + ], "OIS-02": [ "GOV-02", "GOV-09" ], - "SP-01": [ + "OIS-06": [ "GOV-02", - "CPL-01", - "OPS-01", - "OPS-01.1" + "RSK-01" ], - "SP-02": [ - "GOV-03" + "SA-01": [ + "GOV-02" ], - "OIS-03": [ - "GOV-04" + "SA-01-BP1": [ + "GOV-02" ], - "COM-04": [ - "GOV-05" + "SA-01-BP2": [ + "GOV-02" ], - "OIS-05": [ - "GOV-06", - "MON-02.6" + "SA-01-BP3": [ + "GOV-02", + "HRS-03" ], - "AM-03": [ - "AST-01", - "CFG-01", - "CFG-02" + "SA-01-BP4": [ + "GOV-02", + "GOV-04.1", + "GOV-14" ], - "AM-01": [ - "AST-02", - "AST-02.1" + "SA-01-BP5": [ + "GOV-02", + "SEA-01.4" + ], + "SA-01-BP6": [ + "GOV-02", + "CPL-01" + ], + "MDM-01": [ + "GOV-02", + "MDM-01" + ], + "SA-03": [ + "GOV-02.1" + ], + "SA-02": [ + "GOV-03" + ], + "SA-02-BP1": [ + "GOV-03" + ], + "SA-02-BP3": [ + "GOV-03", + "PRM-02.1" + ], + "OIS-01-BP2": [ + "GOV-05", + "CPL-03" + ], + "OIS-05": [ + "GOV-06", + "THR-03" + ], + "DLL-01-BP1": [ + "GOV-09", + "GOV-15.1", + "SEA-01", + "TPM-05" + ], + "UP-01-BP2": [ + "GOV-15", + "CLD-01", + "IAO-03", + "SEA-01", + "SEA-01.4", + "TDA-06" + ], + "AM-03": [ + "AST-01" ], "AM-02": [ + "AST-01.2", + "AST-03", + "DCH-02" + ], + "AM-01": [ "AST-02", "AST-02.1", - "AST-02.2", - "AST-06.1", - "CFG-02", - "CFG-03.3", - "DCH-02" + "AST-02.9" ], - "SP-03": [ - "AST-02.4", - "CPL-02", - "RSK-03", - "RSK-04", - "RSK-04.1" + "RB-12": [ + "AST-02", + "AST-02.9", + "BCD-02" ], - "COS-07": [ + "AM-01-DOAR": [ + "AST-02.9" + ], + "KOS-06": [ "AST-04" ], "AM-04": [ "AST-09", - "AST-10" + "AST-10", + "HRS-05" ], - "PI-03": [ - "AST-09", - "DCH-08", - "DCH-21", - "PRI-05" + "UP-01-BP4": [ + "BCD-01", + "IRO-01" ], - "AM-05": [ - "AST-10", - "HRS-05", - "HRS-05.5" + "RB-06": [ + "BCD-01", + "BCD-11", + "DCH-18" ], "BCM-01": [ "BCD-01" ], "BCM-02": [ + "BCD-01" + ], + "BCM-02-BP1": [ + "BCD-01" + ], + "BCM-02-BP2": [ + "BCD-01" + ], + "BCM-02-BP3": [ + "BCD-01" + ], + "BCM-02-BP4": [ "BCD-01", - "BCD-02", - "CHG-03", - "RSK-08", - "RSK-10" + "BCD-02" + ], + "BCM-02-BP5": [ + "BCD-01", + "RSK-08" + ], + "BCM-02-BP6": [ + "BCD-01", + "BCD-01.4" + ], + "BCM-02-BP7": [ + "BCD-01", + "BCD-02.3" + ], + "BCM-02-BP8": [ + "BCD-01", + "BCD-01.4" + ], + "BCM-02-BP9": [ + "BCD-01", + "BCD-01.4" + ], + "BCM-02-BP10": [ + "BCD-01" ], "BCM-03": [ "BCD-01" ], - "OPS-06": [ - "BCD-01.4", - "BCD-11", - "BCD-11.1", - "BCD-11.2" + "BCM-03-BP1": [ + "BCD-01" ], - "OPS-08": [ - "BCD-01.4", - "BCD-11.1" + "BCM-03-BP2": [ + "BCD-01" ], - "OPS-09": [ - "BCD-01.4", - "BCD-08.1", - "BCD-09.1", - "BCD-11.3", - "CRY-04" + "BCM-03-BP3": [ + "BCD-01" ], - "PS-02": [ - "BCD-04", - "BCD-11.7", - "PES-11" + "BCM-03-BP4": [ + "BCD-01" + ], + "BCM-03-BP5": [ + "BCD-01" + ], + "BCM-03-BP6": [ + "BCD-01" + ], + "BCM-03-BP7": [ + "BCD-01" ], - "PS-06": [ + "BCM-03-BP8": [ + "BCD-01" + ], + "BCM-05": [ + "BCD-02.4", + "TPM-05" + ], + "PS-03-BP6": [ "BCD-04", - "PES-07", - "PES-07.3", - "PES-09", - "PES-09.1" + "PES-08" ], "BCM-04": [ "BCD-04", - "BCD-05", - "BCD-06" + "BCD-06", + "RSK-08" ], - "PSS-12": [ - "BCD-08", - "BCD-09", - "BCD-11.2", - "CLD-09", - "TPM-04.4" + "BCM-04-DOAR": [ + "BCD-04" + ], + "BCM-05-DOAR": [ + "BCD-04" ], - "OPS-07": [ + "RB-07": [ + "BCD-11", "BCD-11.1" ], - "OPS-01": [ - "CAP-01", - "CAP-03" + "RB-09": [ + "BCD-11.2" + ], + "RB-06-DOAR": [ + "BCD-11.4" ], - "OPS-02": [ + "RB-08": [ + "BCD-11.5" + ], + "RB-01": [ "CAP-01", "CAP-03" ], - "OPS-03": [ - "CAP-01", + "RB-01-DOAR": [ "CAP-03" ], - "DEV-03": [ + "RB-02": [ + "CAP-04", + "CAP-05" + ], + "BEI-03": [ "CHG-01" ], - "DEV-08": [ + "BEI-03-BP1": [ + "CHG-01" + ], + "BEI-03-BP2": [ "CHG-01", - "CHG-02", - "CHG-02.2", - "CHG-04.5", - "TDA-06" + "CHG-05" ], - "IDM-02": [ + "BEI-05": [ + "CHG-01" + ], + "BEI-06": [ + "CHG-01", + "CHG-03", + "RSK-04" + ], + "BEI-08": [ + "CHG-01", + "CHG-02" + ], + "BEI-09-DOAR": [ + "CHG-02" + ], + "BEI-12": [ "CHG-02.1", - "IAC-07", - "IAC-09.5", - "IAC-28.1", - "OPS-01.1" + "HRS-11", + "IAC-08" + ], + "BEI-03-BP3": [ + "CHG-02.2" + ], + "BEI-03-BP4": [ + "CHG-02.2" ], - "DEV-06": [ + "BEI-07": [ "CHG-02.2" ], - "DEV-09": [ + "BEI-09": [ "CHG-02.2", - "CHG-02.3", - "CHG-04", - "CHG-04.4" + "IAC-28.1" ], - "DEV-05": [ - "CHG-02.3", + "BEI-04": [ "CHG-03" ], - "PSS-08": [ - "CHG-04.4", - "HRS-03", - "HRS-04.1", - "HRS-12", - "IAC-07.1", - "IAC-08" + "BEI-10": [ + "CHG-07", + "CHG-07.1" ], - "DEV-07": [ - "CHG-04.5", - "TDA-06", - "TDA-20" + "UP-01": [ + "CLD-01", + "TDA-04", + "TPM-01" ], - "COS-01": [ + "UP-01-BP1": [ "CLD-01", - "CLD-02", - "CLD-03", - "SEA-01", - "SEA-02", - "SEA-03" + "TPM-03.2", + "TPM-05", + "TPM-05.5" ], - "COS-02": [ + "RB-05": [ "CLD-01", - "CLD-02", - "CLD-03" + "CFG-02", + "END-04" + ], + "PI-02": [ + "CLD-01.2", + "CLD-07", + "CPL-01" ], - "COS-05": [ - "CLD-03" + "PI-05": [ + "CLD-01.2", + "DCH-09" ], "PI-01": [ "CLD-04", "CLD-07", "DCH-02" ], - "PSS-11": [ - "CLD-05", - "CLD-08", - "IAC-08", - "SEA-13.1" + "PI-04": [ + "CLD-04", + "NET-12" ], - "OPS-24": [ + "RB-23": [ "CLD-06", - "SEA-05" + "DCH-01" ], - "PI-02": [ - "CLD-07", + "UP-01-BP5": [ + "CLD-06.1", + "HRS-03", + "IAO-03", + "TPM-05.4" + ], + "UP-01-BP6": [ + "CLD-06.1", + "TPM-05", + "TPM-05.2", + "TPM-05.4" + ], + "OIS-03": [ + "CLD-06.1", + "TPM-05", + "TPM-05.4", + "TPM-10" + ], + "RB-10": [ + "CLD-06.2", + "MON-01", + "MON-02", + "MON-02.2", + "MON-03" + ], + "PI-03": [ + "CLD-07" + ], + "UP-02": [ "CLD-09", - "CPL-01", - "IAO-03.2", - "PRI-07.1", - "TPM-04.4", - "TPM-05" + "DCH-19" ], - "COS-04": [ - "CLD-11", - "NET-03", - "NET-03.1", - "NET-06.1" + "RB-03": [ + "CLD-09", + "DCH-19" ], - "COM-01": [ + "DLL-01-BP2": [ "CPL-01", - "CPL-03.2" + "TPM-05", + "TPM-05.2" ], - "COM-03": [ - "CPL-03", - "CPL-03.1", - "CPL-04" + "COM-01": [ + "CPL-01" + ], + "SPN-02": [ + "CPL-01.1", + "CPL-02", + "CPL-02.2" + ], + "UP-04": [ + "CPL-01.3", + "TPM-05.8" + ], + "SPN-03-DOAR": [ + "CPL-01.3" + ], + "COM-02-DOAR": [ + "CPL-01.3" + ], + "COM-03-DOAR": [ + "CPL-01.3" + ], + "RB-05-DOAR": [ + "CPL-02", + "CPL-02.2" ], "COM-02": [ - "CPL-04" + "CPL-02", + "CPL-02.2" + ], + "SPN-03": [ + "CPL-02.1" ], - "INQ-01": [ - "CPL-05" + "SPN-02-DOAR": [ + "CPL-02.2" ], - "INQ-02": [ - "CPL-05.1" + "COM-02-BP1": [ + "CPL-02.2" ], - "INQ-03": [ - "CPL-05.2" + "COM-02-BP2": [ + "CPL-02.2" ], - "INQ-04": [ - "CPL-05.2" + "COM-02-BP3": [ + "CPL-02.2" ], - "OPS-23": [ + "COM-03": [ + "CPL-02.2" + ], + "RB-22": [ "CFG-02" ], - "OPS-10": [ - "MON-01", - "MON-01.16" + "IDM-11": [ + "CFG-02" ], - "OPS-13": [ - "MON-01.2", - "MON-01.4", - "MON-02.1", - "MON-02.2" + "IDM-11-BP1": [ + "CFG-02" + ], + "IDM-11-BP2": [ + "CFG-02" + ], + "IDM-11-BP3": [ + "CFG-02" + ], + "IDM-11-BP4": [ + "CFG-02" + ], + "IDM-11-BP5": [ + "CFG-02" + ], + "IDM-11-DOAR": [ + "CFG-02" + ], + "IDM-11-DOAR-BP1": [ + "CFG-02" + ], + "IDM-11-DOAR-BP2": [ + "CFG-02" ], - "OPS-14": [ + "IDM-11-DOAR-BP3": [ + "CFG-02" + ], + "IDM-11-DOAR-BP4": [ + "CFG-02" + ], + "IDM-11-DOAR-BP5": [ + "CFG-02" + ], + "IDM-11-DOAR-BP6": [ + "CFG-02" + ], + "IDM-11-DOAR-BP7": [ + "CFG-02" + ], + "RB-13": [ "MON-02", "MON-10" ], - "OPS-15": [ - "MON-03" + "RB-16-DOAR": [ + "MON-02", + "MON-05.1" ], - "OPS-16": [ - "MON-03.3", - "MON-08", - "MON-08.2" + "SIM-05": [ + "MON-02", + "MON-02.2" ], - "OPS-17": [ - "MON-05", - "MON-05.1" + "RB-14": [ + "MON-02.7", + "MON-03.2" ], - "CRY-01": [ + "RB-15": [ + "MON-02.8", + "IAC-08" + ], + "RB-16": [ + "MON-03.2", + "MON-06", + "MON-08" + ], + "KRY-01": [ + "CRY-01" + ], + "KRY-01-BP1": [ + "CRY-01" + ], + "KRY-01-BP2": [ + "CRY-01" + ], + "KRY-01-BP3": [ "CRY-01" ], - "CRY-02": [ + "KRY-01-BP4": [ + "CRY-01" + ], + "KRY-02": [ + "CRY-01", + "CRY-03", + "CRY-05" + ], + "KRY-02-DOAR": [ "CRY-03" ], - "CRY-03": [ + "KRY-03": [ "CRY-05", - "CRY-05.1" + "CRY-09" + ], + "KRY-04": [ + "CRY-09" ], - "CRY-04": [ + "KRY-04-BP1": [ "CRY-09" ], - "COS-08": [ + "KRY-04-BP3": [ + "CRY-09" + ], + "KRY-04-BP4": [ + "CRY-09" + ], + "KRY-04-BP5": [ + "CRY-09" + ], + "KRY-04-BP6": [ + "CRY-09" + ], + "KRY-04-BP7": [ + "CRY-09" + ], + "KRY-04-BP8": [ + "CRY-09" + ], + "AM-07": [ "DCH-01", - "DCH-02" + "DCH-01.2" ], "AM-06": [ "DCH-01.1", "DCH-02", "DCH-04" ], - "OPS-04": [ - "END-04" + "RB-11": [ + "DCH-01.2" ], - "OPS-05": [ - "END-04" + "AM-05": [ + "DCH-02" ], - "HR-01": [ - "HRS-04", - "HRS-04.1" + "SIM-02": [ + "DCH-02", + "DCH-11" + ], + "AM-08": [ + "DCH-07", + "DCH-14.2" ], "HR-02": [ + "HRS-01", "HRS-05", + "HRS-05.7", "HRS-06" ], - "HR-03": [ - "HRS-05", - "HRS-05.1", - "SAT-01", - "SAT-02" + "KOS-08-DOAR": [ + "HRS-01" ], - "HR-06": [ - "HRS-06.1", - "IAO-03.2", - "PRI-07.1", - "TPM-05" + "HR-01-DOAR": [ + "HRS-02", + "HRS-04.1" ], - "IDM-08": [ - "HRS-06.1", - "IAC-10", - "IAC-10.5" + "OIS-03-BP1": [ + "HRS-03" ], - "PSS-07": [ - "HRS-06.1", - "IAC-10.1", - "IAC-10.4", - "IAC-10.5" + "OIS-03-BP2": [ + "HRS-03" ], - "HR-04": [ - "HRS-07" + "OIS-03-BP3": [ + "HRS-03" + ], + "HR-01": [ + "HRS-04", + "HRS-04.1" + ], + "HR-01-BP1": [ + "HRS-04" + ], + "HR-01-BP2": [ + "HRS-04" + ], + "HR-01-BP3": [ + "HRS-04" + ], + "HR-01-BP4": [ + "HRS-04" ], "HR-05": [ + "HRS-05", "HRS-08", "HRS-09" ], + "IDM-07-DOAR": [ + "HRS-06.1" + ], + "KOS-08": [ + "HRS-06.1" + ], + "HR-04": [ + "HRS-07" + ], "IDM-04": [ "HRS-08", - "IAC-15.2" + "IAC-07" ], "OIS-04": [ "HRS-11" ], - "IDM-01": [ + "OIS-04-BP1": [ + "HRS-11" + ], + "OIS-04-BP2": [ + "HRS-11" + ], + "OIS-04-BP3": [ + "HRS-11" + ], + "OIS-04-DOAR": [ "HRS-11", + "RSK-06.2" + ], + "IDM-01-BP2": [ + "HRS-11" + ], + "IDM-01-BP3": [ + "HRS-11", + "IAC-08" + ], + "IDM-01": [ "IAC-01", - "IAC-02", + "IAC-08" + ], + "IDM-03": [ + "IAC-01" + ], + "IDM-02": [ + "IAC-01.2", + "IAC-15" + ], + "IDM-03-BP2": [ + "IAC-01.2", + "IAC-15.1", + "IAC-21" + ], + "IDM-08-BP2": [ + "IAC-01.2", + "IAC-15.1" + ], + "RB-15-DOAR": [ + "IAC-06", + "IAC-06.3" + ], + "IDM-08-BP3": [ + "IAC-06" + ], + "IDM-01-BP1": [ "IAC-07", - "IAC-09", "IAC-28.1" ], - "PSS-05": [ - "IAC-01", - "IAC-02", - "IAC-03", - "IAC-03.2", - "IAC-04", - "IAC-05", - "WEB-06" - ], - "PSS-09": [ - "IAC-01", - "IAC-02", - "IAC-03", - "IAC-03.2", - "IAC-04", - "IAC-05", + "IDM-01-BP5": [ + "IAC-07" + ], + "IDM-03-BP3": [ "IAC-07", - "IAC-15.2" + "IAC-28.1" ], - "PS-04": [ - "IAC-07.1", - "PES-03", - "PES-03.4", - "PES-04", - "PES-06" + "IDM-03-BP4": [ + "IAC-07", + "IAC-21", + "IAC-28.1" ], - "IDM-09": [ - "IAC-10.1", - "IAC-10.2" + "IDM-05": [ + "IAC-07", + "IAC-17" ], - "IDM-03": [ - "IAC-15.3" + "IDM-07": [ + "IAC-10.5" + ], + "IDM-08": [ + "IAC-10.5" + ], + "IDM-09": [ + "IAC-15.9", + "IAC-28.1" ], "IDM-06": [ "IAC-16", - "IAC-20.3" + "IAC-28.1" ], - "IDM-05": [ + "IDM-01-BP4": [ "IAC-17" ], - "IDM-07": [ + "IDM-05-DOAR": [ + "IAC-17" + ], + "IDM-09-DOAR": [ + "IAC-17" + ], + "IDM-12": [ + "IAC-20.3", + "IAC-21" + ], + "IDM-03-BP1": [ + "IAC-21" + ], + "IDM-10": [ "IAC-21" ], - "PSS-06": [ - "IAC-23", - "IAC-24", - "IAC-25", - "NET-09", - "NET-09.1" + "IDM-13": [ + "IAC-21", + "TDA-20" + ], + "IDM-08-BP1": [ + "IAC-28" + ], + "IDM-01-BP6": [ + "IAC-28.1" ], "SIM-01": [ "IRO-01" ], - "SIM-02": [ - "IRO-02", - "IRO-04.1" - ], - "OPS-21": [ - "IRO-02.5", - "IRO-12.3" + "SIM-07": [ + "IRO-01", + "IRO-02.4", + "IRO-09" ], "SIM-03": [ - "IRO-08", - "IRO-10" + "IRO-02.4", + "IRO-04" ], - "SIM-04": [ - "IRO-10" - ], - "PSS-02": [ - "IRO-10.3", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-03", - "VPM-04", - "VPM-06", - "VPM-06.6", - "VPM-06.7", - "VPM-07", - "VPM-07.1" + "SIM-01-DOAR": [ + "IRO-08" ], - "SIM-05": [ + "RB-20": [ + "IRO-10", + "TPM-05.1" + ], + "SIM-04": [ + "IRO-10", "IRO-13" ], - "PSS-10": [ - "NET-01", + "UP-01-BP3": [ + "IAO-03" + ], + "BEI-02": [ + "IAO-03.2", + "TDA-06" + ], + "BEI-02-BP1": [ + "IAO-03.2" + ], + "BEI-02-BP2": [ + "IAO-03.2" + ], + "BEI-02-BP3": [ + "IAO-03.2" + ], + "BEI-02-BP4": [ + "IAO-03.2" + ], + "PS-05": [ + "MNT-01" + ], + "MDM-01-BP2": [ + "MDM-01" + ], + "MDM-01-BP3": [ + "MDM-01" + ], + "MDM-01-BP5": [ + "MDM-01" + ], + "MDM-01-DOAR": [ + "MDM-01" + ], + "MDM-01-BP1": [ + "MDM-03" + ], + "MDM-01-BP4": [ + "MDM-04" + ], + "MDM-01-BP6": [ + "MDM-06" + ], + "KOS-01": [ "NET-02", + "NET-02.1", + "NET-03", + "NET-08" + ], + "KOS-03-DOAR": [ + "NET-02" + ], + "KOS-03": [ + "NET-02.3", "NET-03" ], - "COS-03": [ - "NET-03.2", - "NET-04", - "NET-04.6", - "NET-05" + "KOS-02": [ + "NET-03", + "NET-03.8" + ], + "RB-23-DOAR": [ + "NET-06" ], - "COS-06": [ + "KOS-05": [ "NET-06", - "SEA-05" + "NET-06.4" + ], + "KOS-05-DOAR": [ + "NET-06.2" + ], + "KOS-04": [ + "NET-06.8" + ], + "KOS-01-DOAR": [ + "NET-08" ], "PS-01": [ + "PES-01" + ], + "PS-02": [ "PES-01", + "PES-01.1" + ], + "PS-03": [ + "PES-01", + "PES-01.1" + ], + "PS-01-DOAR": [ + "PES-01.2" + ], + "PS-03-BP1": [ + "PES-01.2", + "PES-08" + ], + "PS-02-DOAR": [ + "PES-03" + ], + "PS-04": [ "PES-07", "PES-07.3", - "PES-07.5", + "PES-07.7", + "PES-12.1" + ], + "PS-03-BP2": [ "PES-08" ], - "PS-03": [ - "PES-03", - "PES-03.1" + "PS-03-BP4": [ + "PES-08" ], - "PS-05": [ - "PES-08", + "PS-03-BP5": [ "PES-08.1", - "PES-08.2", - "PES-08.3" + "PES-08.2" ], - "PS-07": [ - "PES-09", - "PES-09.1" + "PS-03-BP3": [ + "PES-09" ], - "OPS-11": [ - "PRI-05" + "PS-03-DOAR": [ + "PES-09" ], - "OPS-12": [ - "PRI-05" - ], - "OIS-06": [ - "RSK-01" + "SA-02-DOAR": [ + "PRM-01.1" ], "OIS-07": [ + "RSK-01", + "RSK-03", "RSK-04", + "RSK-04.2", "RSK-09" ], - "PSS-01": [ - "OPS-05" + "OIS-07-DOAR": [ + "RSK-01.3", + "RSK-01.5" + ], + "OIS-03-DOAR": [ + "RSK-03", + "RSK-03.1", + "RSK-04.1" ], - "DEV-04": [ + "SA-03-DOAR": [ + "RSK-06.2" + ], + "PS-04-DOAR": [ + "RSK-09", + "TPM-03", + "TPM-04" + ], + "HR-03": [ "SAT-01", "SAT-02", - "SAT-03", - "SAT-03.4" + "SAT-03" + ], + "HR-03-BP1": [ + "SAT-03" ], - "DEV-01": [ + "HR-03-BP4": [ + "SAT-03" + ], + "HR-03-DOAR": [ + "SAT-03" + ], + "HR-03-BP2": [ + "SAT-03.3" + ], + "HR-03-BP3": [ + "SAT-03.6" + ], + "BEI-01": [ "TDA-01" ], - "DEV-02": [ - "TDA-02", - "TDA-04", - "TDA-04.1", - "TDA-05", - "TDA-06", - "TDA-07", - "TDA-09", - "TDA-13", - "TDA-14", - "TDA-15" - ], - "DEV-10": [ - "TDA-07", + "RB-21-DOAR": [ + "TDA-02.11" + ], + "KOS-07": [ + "TDA-04" + ], + "BEI-01-BP1": [ + "TDA-06" + ], + "BEI-01-BP4": [ + "TDA-06" + ], + "BEI-01-DOAR": [ + "TDA-06" + ], + "BEI-01-BP3": [ + "TDA-06.7" + ], + "BEI-01-BP2": [ "TDA-08" ], - "PSS-04": [ - "TDA-19" + "BEI-11": [ + "TDA-08" ], - "SSO-01": [ - "TPM-01" + "DLL-01": [ + "TPM-01", + "TPM-05" ], - "SSO-03": [ + "DLL-02": [ "TPM-01", - "TPM-02", - "TPM-03" + "TPM-08" ], - "SSO-02": [ - "TPM-02", - "TPM-03", - "TPM-03.2", - "TPM-03.3", - "TPM-04.1", + "UP-03": [ "TPM-05" ], - "SSO-05": [ - "TPM-03.1", - "TPM-04", + "DLL-01-BP3": [ + "TPM-05" + ], + "DLL-01-BP4": [ "TPM-05", - "TPM-08", - "TPM-10" + "TPM-05.2" ], - "SSO-04": [ - "TPM-04.1", - "TPM-07", - "TPM-08", - "TPM-09", - "TPM-10" + "DLL-01-DOAR": [ + "TPM-05.2" + ], + "SIM-06": [ + "TPM-05.4" + ], + "DLL-02-BP1": [ + "TPM-08" + ], + "DLL-02-BP2": [ + "TPM-08" ], - "OPS-18": [ + "DLL-02-BP3": [ + "TPM-08" + ], + "OIS-05-DOAR": [ + "THR-01", + "THR-03.1" + ], + "RB-17": [ + "VPM-01" + ], + "RB-17-BP2": [ "VPM-01", - "VPM-02", + "VPM-04", + "VPM-05", + "VPM-05.1" + ], + "RB-17-BP1": [ "VPM-03", - "VPM-04" + "VPM-03.1", + "VPM-06" ], - "OPS-22": [ + "RB-19": [ "VPM-03", + "VPM-03.1", + "VPM-04" + ], + "RB-21": [ + "VPM-04", "VPM-06" ], - "PSS-03": [ - "VPM-05", - "VPM-05.1", - "VPM-06", - "VPM-06.1" - ], - "OPS-19": [ - "VPM-05.3", - "VPM-07", - "VPM-07.1" - ], - "OPS-20": [ - "VPM-06.4", - "VPM-06.5" + "RB-18": [ + "VPM-07" + ], + "RB-18-DOAR": [ + "VPM-07" ] } } diff --git a/docs/api/crosswalks/emea-deu-fdpa-2017.json b/docs/api/crosswalks/emea-deu-fdpa-2017.json index 61bb7ac9..52aca771 100644 --- a/docs/api/crosswalks/emea-deu-fdpa-2017.json +++ b/docs/api/crosswalks/emea-deu-fdpa-2017.json @@ -2,188 +2,1208 @@ "framework_id": "emea-deu-fdpa-2017", "display_name": "Germany - Federal Data Protection Act (2017)", "scf_to_framework": { - "total_mappings": 18, + "total_mappings": 46, "mappings": { - "GOV-01": [ - "Sec 9", - "Sec 9a", - "Annex" + "GOV-17": [ + "3.5.79(3)" ], "CPL-01": [ - "Sec 9", - "Sec 9a", - "Annex" + "3.4.76(5)", + "3.4.77" ], - "CPL-02": [ - "Sec 9", - "Sec 9a", - "Annex" + "CRY-01": [ + "3.2.48(2)7" ], - "DCH-01": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" + "DCH-23": [ + "3.4.64(2)" ], - "DCH-22.1": [ - "Sec 20" + "HRS-05": [ + "3.2.48(2)8" + ], + "IAC-08": [ + "2.1.2.27(1)", + "3.2.48(2)4" + ], + "IRO-04.1": [ + "3.4.65(1)", + "3.4.65(2)" + ], + "IRO-10": [ + "3.4.66(1)", + "3.4.66(2)" + ], + "IRO-10.2": [ + "3.4.65(1)", + "3.4.65(2)", + "3.4.65(3)", + "3.4.65(3)1", + "3.4.65(3)2", + "3.4.65(3)3", + "3.4.65(3)4", + "3.4.65(4)", + "3.4.65(5)", + "3.4.65(6)" ], "PRI-01": [ - "Inferred", - "Expectation" + "2.1.2.26(5)" + ], + "PRI-01.4": [ + "2.1.1.22(2)4", + "2.3.38(1)", + "2.3.38(2)" ], - "PRI-01.1": [ - "Sec 4d", - "Sec 4f", - "Sec 4g" + "PRI-01.5": [ + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)8", + "3.4.62(5)9", + "3.4.62(6)", + "3.4.62(7)", + "3.4.63", + "3.5.78(1)", + "3.5.78(1)1", + "3.5.78(1)2", + "3.5.78(2)", + "3.5.78(3)", + "3.5.78(4)", + "3.5.79(1)", + "3.5.79(1)1" + ], + "PRI-01.6": [ + "2.1.1.22(2)5", + "2.1.1.22(2)6", + "2.1.1.22(2)7", + "2.1.2.28(1)", + "3.2.53", + "3.4.62(5)2", + "3.4.64(1)", + "3.4.64(2)1", + "3.4.64(2)2", + "3.4.64(3)", + "3.4.64(3)1", + "3.4.64(3)2", + "3.4.64(3)3", + "3.4.64(3)4", + "3.4.64(3)5", + "3.4.64(3)6", + "3.4.64(3)7", + "3.4.64(3)8", + "3.4.64(3)9", + "3.4.64(3)10", + "3.4.64(3)11", + "3.4.64(3)12", + "3.4.64(3)13", + "3.4.64(3)14", + "3.4.71(2)" + ], + "PRI-01.11": [ + "2.2.32(1)1", + "2.2.32(1)2", + "2.2.32(1)3", + "2.2.32(1)4", + "2.2.32(1)5", + "2.2.32(2)", + "2.2.32(3)", + "2.2.33(1)1(a)", + "2.2.33(1)1(b)", + "2.2.33(1)2", + "2.2.33(2)", + "2.2.35(3)", + "2.2.36", + "3.1.47.1", + "3.2.48(2)", + "3.2.48(2)1", + "3.2.48(2)5", + "3.3.57(4)", + "3.3.58(3)", + "3.3.58(3)1", + "3.3.58(3)2", + "3.3.58(3)3", + "3.3.58(4)", + "3.3.59(3)", + "3.4.71(1)", + "3.4.74(1)", + "3.4.74(2)", + "3.5.80(1)", + "3.5.80(1)1", + "3.5.80(1)2", + "3.5.80(1)3", + "3.5.80(1)4", + "3.5.80(1)5", + "3.5.80(2)", + "3.5.80(3)", + "3.7.83(2)", + "3.7.83(3)", + "3.7.83(4)", + "3.7.83(5)" ], "PRI-02": [ - "Sec 4", - "Sec 19" + "3.2.51(4)", + "3.3.55", + "3.3.55.1", + "3.3.55.2", + "3.3.55.3", + "3.3.55.4", + "3.3.55.5", + "3.3.56(1)", + "3.3.56(1)1", + "3.3.56(1)2", + "3.3.56(1)3", + "3.3.56(1)4", + "3.3.56(1)5", + "3.3.56(2)1", + "3.3.56(2)2", + "3.3.56(2)3", + "3.3.56(3)" + ], + "PRI-02.1": [ + "3.3.56(1)2" ], "PRI-03": [ - "Sec 4a", - "Sec 11" + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.27(4)", + "3.2.51(1)", + "3.2.51(2)", + "3.2.51(5)" + ], + "PRI-03.4": [ + "3.2.51(3)" + ], + "PRI-03.5": [ + "3.3.59(3)" + ], + "PRI-03.11": [ + "3.4.75(3)" ], "PRI-04": [ - "Sec 4" + "3.1.47.2", + "3.1.47.3", + "3.1.47.6" ], "PRI-04.1": [ - "Sec 4" + "2.1.2.26(1)", + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.26(4)", + "3.2.49", + "3.2.50" + ], + "PRI-04.7": [ + "3.3.56(2)" ], "PRI-05": [ - "Sec 3a", - "Sec 5", - "Sec 13", - "Sec 14", - "Sec 20" + "3.1.47.5", + "3.2.48(2)2", + "3.3.58(2)", + "3.4.62(5)4", + "3.4.75(2)", + "3.4.75(4)" + ], + "PRI-05.1": [ + "2.1.2.27(3)" + ], + "PRI-05.2": [ + "3.1.47.4", + "3.4.74(1)" + ], + "PRI-05.3": [ + "3.2.48(2)6", + "3.2.50" + ], + "PRI-05.4": [ + "2.1.1.22(1)", + "2.1.1.22(1)1", + "2.1.1.22(1)1(a)", + "2.1.1.22(1)1(b)", + "2.1.1.22(1)1(c)", + "2.1.1.22(1)1(d)", + "2.1.1.22(1)2(a)", + "2.1.1.22(1)2(b)", + "2.1.1.22(2)", + "2.1.1.22(2)1", + "2.1.1.22(2)2", + "2.1.1.22(2)3", + "2.1.1.22(2)8", + "2.1.1.22(2)9", + "2.1.1.22(2)10", + "2.1.1.24(1)", + "2.1.1.24(1)1", + "2.1.1.24(1)2", + "2.1.1.24(2)", + "2.2.33(1)2(a)", + "2.2.33(1)3(b)", + "3.2.52" + ], + "PRI-05.7": [ + "2.1.2.26(3)", + "2.1.2.26(4)", + "2.1.2.26(7)", + "3.2.48(1)", + "3.2.51(5)", + "3.4.70(2)", + "3.4.72", + "3.4.72.1", + "3.4.72.2", + "3.4.72.3", + "3.4.72.4", + "3.4.72.5", + "3.4.73" ], "PRI-06": [ - "Sec 19" + "3.3.57(1)", + "3.3.57(1)2", + "3.3.57(1)3", + "3.3.57(1)4", + "3.3.57(1)5", + "3.3.57(1)6", + "3.3.57(1)7", + "3.3.57(1)8", + "3.3.58(1)", + "3.3.58(2)" ], "PRI-06.1": [ - "Sec 20" - ], - "PRI-15": [ - "Sec 4d", - "Sec 4e" - ], - "SEA-01": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], - "SEA-02": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], - "SEA-03": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" + "3.3.57(1)6", + "3.3.58(1)", + "3.4.75(1)" + ], + "PRI-06.2": [ + "3.3.58(1)", + "3.3.58(5)", + "3.4.75(3)" + ], + "PRI-06.4": [ + "2.2.34(2)", + "2.2.35(2)", + "3.3.57(6)", + "3.3.59(2)" + ], + "PRI-06.5": [ + "2.2.35(1)", + "3.3.58(2)" + ], + "PRI-06.8": [ + "3.3.57(3)", + "3.3.59(4)" + ], + "PRI-07": [ + "3.5.79(1)2", + "3.5.81(1)", + "3.5.81(1)1", + "3.5.81(1)2", + "3.5.81(1)3", + "3.5.81(2)", + "3.5.81(3)", + "3.5.81(4)" + ], + "PRI-07.2": [ + "3.4.62(1)", + "3.4.62(2)", + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)9", + "3.4.63" + ], + "PRI-07.3": [ + "3.3.58(5)" + ], + "PRI-07.5": [ + "2.2.34(2)", + "3.3.59(4)" + ], + "PRI-14": [ + "3.4.70(1)", + "3.4.70(1)1", + "3.4.70(1)2", + "3.4.70(1)3", + "3.4.70(1)4", + "3.4.70(1)5", + "3.4.70(1)6", + "3.4.70(1)7", + "3.4.70(1)8", + "3.4.70(1)9", + "3.4.70(2)1", + "3.4.70(2)2", + "3.4.70(2)3", + "3.4.70(4)", + "3.4.76(1)", + "3.4.76(1)1", + "3.4.76(1)2", + "3.4.76(1)3", + "3.4.76(1)4", + "3.4.76(1)5", + "3.4.76(1)6", + "3.4.76(2)", + "3.4.76(3)", + "3.4.76(4)", + "3.5.79(2)" + ], + "PRI-14.1": [ + "3.3.57(1)4", + "3.5.79(2)" + ], + "PRI-17": [ + "2.2.33(2)", + "2.2.34(2)", + "3.3.57(6)", + "3.3.57(8)", + "3.3.58(6)", + "3.3.59(1)", + "3.3.59(2)", + "3.4.74(2)" + ], + "PRI-17.3": [ + "3.3.57(8)" + ], + "PRI-19": [ + "2.2.37(1)1", + "2.2.37(1)2", + "2.2.37(2)", + "3.2.54(1)", + "3.2.54(2)", + "3.2.54(3)" + ], + "RSK-10": [ + "3.4.67(1)", + "3.4.67(2)", + "3.4.67(3)", + "3.4.67(4)", + "3.4.67(4)1", + "3.4.67(4)2", + "3.4.67(4)3", + "3.4.67(4)4", + "3.4.67(5)" + ], + "SAT-02": [ + "3.2.48(2)3" ] } }, "framework_to_scf": { - "total_mappings": 20, + "total_mappings": 255, "mappings": { - "Sec 9": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Sec 9a": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Annex": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Sec 4b": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Sec 16": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Sec 20": [ - "DCH-22.1", - "PRI-05", - "PRI-06.1" + "3.5.79(3)": [ + "GOV-17" ], - "Inferred": [ - "PRI-01" + "3.4.76(5)": [ + "CPL-01" + ], + "3.4.77": [ + "CPL-01" + ], + "3.2.48(2)7": [ + "CRY-01" ], - "Expectation": [ + "3.4.64(2)": [ + "DCH-23" + ], + "3.2.48(2)8": [ + "HRS-05" + ], + "2.1.2.27(1)": [ + "IAC-08" + ], + "3.2.48(2)4": [ + "IAC-08" + ], + "3.4.65(1)": [ + "IRO-04.1", + "IRO-10.2" + ], + "3.4.65(2)": [ + "IRO-04.1", + "IRO-10.2" + ], + "3.4.66(1)": [ + "IRO-10" + ], + "3.4.66(2)": [ + "IRO-10" + ], + "3.4.65(3)": [ + "IRO-10.2" + ], + "3.4.65(3)1": [ + "IRO-10.2" + ], + "3.4.65(3)2": [ + "IRO-10.2" + ], + "3.4.65(3)3": [ + "IRO-10.2" + ], + "3.4.65(3)4": [ + "IRO-10.2" + ], + "3.4.65(4)": [ + "IRO-10.2" + ], + "3.4.65(5)": [ + "IRO-10.2" + ], + "3.4.65(6)": [ + "IRO-10.2" + ], + "2.1.2.26(5)": [ "PRI-01" ], - "Sec 4d": [ - "PRI-01.1", - "PRI-15" + "2.1.1.22(2)4": [ + "PRI-01.4" + ], + "2.3.38(1)": [ + "PRI-01.4" + ], + "2.3.38(2)": [ + "PRI-01.4" + ], + "3.4.62(3)": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(4)": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(5)": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(5)1": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(5)2": [ + "PRI-01.5", + "PRI-01.6", + "PRI-07.2" + ], + "3.4.62(5)3": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(5)4": [ + "PRI-01.5", + "PRI-05", + "PRI-07.2" + ], + "3.4.62(5)5": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(5)6": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(5)7": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(5)8": [ + "PRI-01.5" + ], + "3.4.62(5)9": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.4.62(6)": [ + "PRI-01.5" + ], + "3.4.62(7)": [ + "PRI-01.5" + ], + "3.4.63": [ + "PRI-01.5", + "PRI-07.2" + ], + "3.5.78(1)": [ + "PRI-01.5" + ], + "3.5.78(1)1": [ + "PRI-01.5" + ], + "3.5.78(1)2": [ + "PRI-01.5" + ], + "3.5.78(2)": [ + "PRI-01.5" + ], + "3.5.78(3)": [ + "PRI-01.5" + ], + "3.5.78(4)": [ + "PRI-01.5" + ], + "3.5.79(1)": [ + "PRI-01.5" + ], + "3.5.79(1)1": [ + "PRI-01.5" + ], + "2.1.1.22(2)5": [ + "PRI-01.6" + ], + "2.1.1.22(2)6": [ + "PRI-01.6" + ], + "2.1.1.22(2)7": [ + "PRI-01.6" + ], + "2.1.2.28(1)": [ + "PRI-01.6" + ], + "3.2.53": [ + "PRI-01.6" + ], + "3.4.64(1)": [ + "PRI-01.6" + ], + "3.4.64(2)1": [ + "PRI-01.6" + ], + "3.4.64(2)2": [ + "PRI-01.6" + ], + "3.4.64(3)": [ + "PRI-01.6" + ], + "3.4.64(3)1": [ + "PRI-01.6" + ], + "3.4.64(3)2": [ + "PRI-01.6" + ], + "3.4.64(3)3": [ + "PRI-01.6" + ], + "3.4.64(3)4": [ + "PRI-01.6" + ], + "3.4.64(3)5": [ + "PRI-01.6" + ], + "3.4.64(3)6": [ + "PRI-01.6" + ], + "3.4.64(3)7": [ + "PRI-01.6" + ], + "3.4.64(3)8": [ + "PRI-01.6" + ], + "3.4.64(3)9": [ + "PRI-01.6" + ], + "3.4.64(3)10": [ + "PRI-01.6" + ], + "3.4.64(3)11": [ + "PRI-01.6" + ], + "3.4.64(3)12": [ + "PRI-01.6" + ], + "3.4.64(3)13": [ + "PRI-01.6" + ], + "3.4.64(3)14": [ + "PRI-01.6" + ], + "3.4.71(2)": [ + "PRI-01.6" + ], + "2.2.32(1)1": [ + "PRI-01.11" + ], + "2.2.32(1)2": [ + "PRI-01.11" + ], + "2.2.32(1)3": [ + "PRI-01.11" + ], + "2.2.32(1)4": [ + "PRI-01.11" + ], + "2.2.32(1)5": [ + "PRI-01.11" + ], + "2.2.32(2)": [ + "PRI-01.11" + ], + "2.2.32(3)": [ + "PRI-01.11" + ], + "2.2.33(1)1(a)": [ + "PRI-01.11" + ], + "2.2.33(1)1(b)": [ + "PRI-01.11" + ], + "2.2.33(1)2": [ + "PRI-01.11" + ], + "2.2.33(2)": [ + "PRI-01.11", + "PRI-17" + ], + "2.2.35(3)": [ + "PRI-01.11" + ], + "2.2.36": [ + "PRI-01.11" + ], + "3.1.47.1": [ + "PRI-01.11" + ], + "3.2.48(2)": [ + "PRI-01.11" + ], + "3.2.48(2)1": [ + "PRI-01.11" + ], + "3.2.48(2)5": [ + "PRI-01.11" + ], + "3.3.57(4)": [ + "PRI-01.11" + ], + "3.3.58(3)": [ + "PRI-01.11" + ], + "3.3.58(3)1": [ + "PRI-01.11" + ], + "3.3.58(3)2": [ + "PRI-01.11" + ], + "3.3.58(3)3": [ + "PRI-01.11" + ], + "3.3.58(4)": [ + "PRI-01.11" + ], + "3.3.59(3)": [ + "PRI-01.11", + "PRI-03.5" + ], + "3.4.71(1)": [ + "PRI-01.11" + ], + "3.4.74(1)": [ + "PRI-01.11", + "PRI-05.2" + ], + "3.4.74(2)": [ + "PRI-01.11", + "PRI-17" + ], + "3.5.80(1)": [ + "PRI-01.11" + ], + "3.5.80(1)1": [ + "PRI-01.11" + ], + "3.5.80(1)2": [ + "PRI-01.11" + ], + "3.5.80(1)3": [ + "PRI-01.11" + ], + "3.5.80(1)4": [ + "PRI-01.11" + ], + "3.5.80(1)5": [ + "PRI-01.11" + ], + "3.5.80(2)": [ + "PRI-01.11" + ], + "3.5.80(3)": [ + "PRI-01.11" + ], + "3.7.83(2)": [ + "PRI-01.11" + ], + "3.7.83(3)": [ + "PRI-01.11" + ], + "3.7.83(4)": [ + "PRI-01.11" + ], + "3.7.83(5)": [ + "PRI-01.11" + ], + "3.2.51(4)": [ + "PRI-02" + ], + "3.3.55": [ + "PRI-02" + ], + "3.3.55.1": [ + "PRI-02" ], - "Sec 4f": [ - "PRI-01.1" + "3.3.55.2": [ + "PRI-02" ], - "Sec 4g": [ - "PRI-01.1" + "3.3.55.3": [ + "PRI-02" ], - "Sec 4": [ + "3.3.55.4": [ + "PRI-02" + ], + "3.3.55.5": [ + "PRI-02" + ], + "3.3.56(1)": [ + "PRI-02" + ], + "3.3.56(1)1": [ + "PRI-02" + ], + "3.3.56(1)2": [ "PRI-02", - "PRI-04", + "PRI-02.1" + ], + "3.3.56(1)3": [ + "PRI-02" + ], + "3.3.56(1)4": [ + "PRI-02" + ], + "3.3.56(1)5": [ + "PRI-02" + ], + "3.3.56(2)1": [ + "PRI-02" + ], + "3.3.56(2)2": [ + "PRI-02" + ], + "3.3.56(2)3": [ + "PRI-02" + ], + "3.3.56(3)": [ + "PRI-02" + ], + "2.1.2.26(2)": [ + "PRI-03", "PRI-04.1" ], - "Sec 19": [ - "PRI-02", - "PRI-06" + "2.1.2.26(3)": [ + "PRI-03", + "PRI-04.1", + "PRI-05.7" ], - "Sec 4a": [ + "2.1.2.27(4)": [ "PRI-03" ], - "Sec 11": [ + "3.2.51(1)": [ "PRI-03" ], - "Sec 3a": [ + "3.2.51(2)": [ + "PRI-03" + ], + "3.2.51(5)": [ + "PRI-03", + "PRI-05.7" + ], + "3.2.51(3)": [ + "PRI-03.4" + ], + "3.4.75(3)": [ + "PRI-03.11", + "PRI-06.2" + ], + "3.1.47.2": [ + "PRI-04" + ], + "3.1.47.3": [ + "PRI-04" + ], + "3.1.47.6": [ + "PRI-04" + ], + "2.1.2.26(1)": [ + "PRI-04.1" + ], + "2.1.2.26(4)": [ + "PRI-04.1", + "PRI-05.7" + ], + "3.2.49": [ + "PRI-04.1" + ], + "3.2.50": [ + "PRI-04.1", + "PRI-05.3" + ], + "3.3.56(2)": [ + "PRI-04.7" + ], + "3.1.47.5": [ "PRI-05" ], - "Sec 5": [ + "3.2.48(2)2": [ "PRI-05" ], - "Sec 13": [ + "3.3.58(2)": [ + "PRI-05", + "PRI-06", + "PRI-06.5" + ], + "3.4.75(2)": [ "PRI-05" ], - "Sec 14": [ + "3.4.75(4)": [ "PRI-05" ], - "Sec 4e": [ - "PRI-15" + "2.1.2.27(3)": [ + "PRI-05.1" + ], + "3.1.47.4": [ + "PRI-05.2" + ], + "3.2.48(2)6": [ + "PRI-05.3" + ], + "2.1.1.22(1)": [ + "PRI-05.4" + ], + "2.1.1.22(1)1": [ + "PRI-05.4" + ], + "2.1.1.22(1)1(a)": [ + "PRI-05.4" + ], + "2.1.1.22(1)1(b)": [ + "PRI-05.4" + ], + "2.1.1.22(1)1(c)": [ + "PRI-05.4" + ], + "2.1.1.22(1)1(d)": [ + "PRI-05.4" + ], + "2.1.1.22(1)2(a)": [ + "PRI-05.4" + ], + "2.1.1.22(1)2(b)": [ + "PRI-05.4" + ], + "2.1.1.22(2)": [ + "PRI-05.4" + ], + "2.1.1.22(2)1": [ + "PRI-05.4" + ], + "2.1.1.22(2)2": [ + "PRI-05.4" + ], + "2.1.1.22(2)3": [ + "PRI-05.4" + ], + "2.1.1.22(2)8": [ + "PRI-05.4" + ], + "2.1.1.22(2)9": [ + "PRI-05.4" + ], + "2.1.1.22(2)10": [ + "PRI-05.4" + ], + "2.1.1.24(1)": [ + "PRI-05.4" + ], + "2.1.1.24(1)1": [ + "PRI-05.4" + ], + "2.1.1.24(1)2": [ + "PRI-05.4" + ], + "2.1.1.24(2)": [ + "PRI-05.4" + ], + "2.2.33(1)2(a)": [ + "PRI-05.4" + ], + "2.2.33(1)3(b)": [ + "PRI-05.4" + ], + "3.2.52": [ + "PRI-05.4" + ], + "2.1.2.26(7)": [ + "PRI-05.7" + ], + "3.2.48(1)": [ + "PRI-05.7" + ], + "3.4.70(2)": [ + "PRI-05.7" + ], + "3.4.72": [ + "PRI-05.7" + ], + "3.4.72.1": [ + "PRI-05.7" + ], + "3.4.72.2": [ + "PRI-05.7" + ], + "3.4.72.3": [ + "PRI-05.7" + ], + "3.4.72.4": [ + "PRI-05.7" + ], + "3.4.72.5": [ + "PRI-05.7" + ], + "3.4.73": [ + "PRI-05.7" + ], + "3.3.57(1)": [ + "PRI-06" + ], + "3.3.57(1)2": [ + "PRI-06" + ], + "3.3.57(1)3": [ + "PRI-06" + ], + "3.3.57(1)4": [ + "PRI-06", + "PRI-14.1" + ], + "3.3.57(1)5": [ + "PRI-06" + ], + "3.3.57(1)6": [ + "PRI-06", + "PRI-06.1" + ], + "3.3.57(1)7": [ + "PRI-06" + ], + "3.3.57(1)8": [ + "PRI-06" + ], + "3.3.58(1)": [ + "PRI-06", + "PRI-06.1", + "PRI-06.2" + ], + "3.4.75(1)": [ + "PRI-06.1" + ], + "3.3.58(5)": [ + "PRI-06.2", + "PRI-07.3" + ], + "2.2.34(2)": [ + "PRI-06.4", + "PRI-07.5", + "PRI-17" + ], + "2.2.35(2)": [ + "PRI-06.4" + ], + "3.3.57(6)": [ + "PRI-06.4", + "PRI-17" + ], + "3.3.59(2)": [ + "PRI-06.4", + "PRI-17" + ], + "2.2.35(1)": [ + "PRI-06.5" + ], + "3.3.57(3)": [ + "PRI-06.8" + ], + "3.3.59(4)": [ + "PRI-06.8", + "PRI-07.5" + ], + "3.5.79(1)2": [ + "PRI-07" + ], + "3.5.81(1)": [ + "PRI-07" + ], + "3.5.81(1)1": [ + "PRI-07" + ], + "3.5.81(1)2": [ + "PRI-07" + ], + "3.5.81(1)3": [ + "PRI-07" + ], + "3.5.81(2)": [ + "PRI-07" + ], + "3.5.81(3)": [ + "PRI-07" + ], + "3.5.81(4)": [ + "PRI-07" + ], + "3.4.62(1)": [ + "PRI-07.2" + ], + "3.4.62(2)": [ + "PRI-07.2" + ], + "3.4.70(1)": [ + "PRI-14" + ], + "3.4.70(1)1": [ + "PRI-14" + ], + "3.4.70(1)2": [ + "PRI-14" + ], + "3.4.70(1)3": [ + "PRI-14" + ], + "3.4.70(1)4": [ + "PRI-14" + ], + "3.4.70(1)5": [ + "PRI-14" + ], + "3.4.70(1)6": [ + "PRI-14" + ], + "3.4.70(1)7": [ + "PRI-14" + ], + "3.4.70(1)8": [ + "PRI-14" + ], + "3.4.70(1)9": [ + "PRI-14" + ], + "3.4.70(2)1": [ + "PRI-14" + ], + "3.4.70(2)2": [ + "PRI-14" + ], + "3.4.70(2)3": [ + "PRI-14" + ], + "3.4.70(4)": [ + "PRI-14" + ], + "3.4.76(1)": [ + "PRI-14" + ], + "3.4.76(1)1": [ + "PRI-14" + ], + "3.4.76(1)2": [ + "PRI-14" + ], + "3.4.76(1)3": [ + "PRI-14" + ], + "3.4.76(1)4": [ + "PRI-14" + ], + "3.4.76(1)5": [ + "PRI-14" + ], + "3.4.76(1)6": [ + "PRI-14" + ], + "3.4.76(2)": [ + "PRI-14" + ], + "3.4.76(3)": [ + "PRI-14" + ], + "3.4.76(4)": [ + "PRI-14" + ], + "3.5.79(2)": [ + "PRI-14", + "PRI-14.1" + ], + "3.3.57(8)": [ + "PRI-17", + "PRI-17.3" + ], + "3.3.58(6)": [ + "PRI-17" + ], + "3.3.59(1)": [ + "PRI-17" + ], + "2.2.37(1)1": [ + "PRI-19" + ], + "2.2.37(1)2": [ + "PRI-19" + ], + "2.2.37(2)": [ + "PRI-19" + ], + "3.2.54(1)": [ + "PRI-19" + ], + "3.2.54(2)": [ + "PRI-19" + ], + "3.2.54(3)": [ + "PRI-19" + ], + "3.4.67(1)": [ + "RSK-10" + ], + "3.4.67(2)": [ + "RSK-10" + ], + "3.4.67(3)": [ + "RSK-10" + ], + "3.4.67(4)": [ + "RSK-10" + ], + "3.4.67(4)1": [ + "RSK-10" + ], + "3.4.67(4)2": [ + "RSK-10" + ], + "3.4.67(4)3": [ + "RSK-10" + ], + "3.4.67(4)4": [ + "RSK-10" + ], + "3.4.67(5)": [ + "RSK-10" + ], + "3.2.48(2)3": [ + "SAT-02" ] } } diff --git a/docs/api/crosswalks/emea-esp-boe-a-2022-7191.json b/docs/api/crosswalks/emea-esp-boe-a-2022-7191.json deleted file mode 100644 index 5e73e29e..00000000 --- a/docs/api/crosswalks/emea-esp-boe-a-2022-7191.json +++ /dev/null @@ -1,830 +0,0 @@ -{ - "framework_id": "emea-esp-boe-a-2022-7191", - "display_name": "Spain - BOE-A-2022-7191", - "scf_to_framework": { - "total_mappings": 72, - "mappings": { - "GOV-01": [ - "Article 5", - "Article 6.1", - "Article 6.2", - "Article 13.1", - "Article 35.1" - ], - "GOV-01.1": [ - "Article 5", - "Article 27" - ], - "GOV-02": [ - "Article 12.1", - "Article 12.1(a)", - "Article 12.1(b)", - "Article 12.1(c)", - "Article 12.1(d)", - "Article 12.1(e)", - "Article 12.1(f)", - "Article 12.2", - "Article 12.6", - "Article 12.6(a)", - "Article 12.6(b)", - "Article 12.6(c)", - "Article 12.6(d)", - "Article 12.6(e)", - "Article 12.6(f)", - "Article 12.6(g)", - "Article 12.6(h)", - "Article 12.6(i)", - "Article 12.6(j)", - "Article 12.6(k)", - "Article 12.6(l)", - "Article 12.6(m)", - "Article 12.6(n)", - "Article 12.6(ñ)", - "Article 12.7" - ], - "GOV-03": [ - "Article 27" - ], - "GOV-06": [ - "Article 32.1", - "Article 32.2", - "Article 32.3" - ], - "GOV-15": [ - "Article 5", - "Article 5(a)", - "Article 5(b)", - "Article 5(c)", - "Article 5(d)", - "Article 5(e)", - "Article 5(f)", - "Article 5(g)", - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5", - "Article 28.1", - "Article 37" - ], - "GOV-15.1": [ - "Article 3.3", - "Article 28.1(a)", - "Article 28.1(b)", - "Article 28.1(c)", - "Article 28.2", - "Article 28.3", - "Article 37" - ], - "GOV-15.2": [ - "Article 3.3", - "Article 37" - ], - "AST-01": [ - "Article 18" - ], - "BCD-01": [ - "Article 26" - ], - "BCD-11": [ - "Article 26" - ], - "CHG-01": [ - "Article 21.1" - ], - "CHG-02": [ - "Article 21.1" - ], - "CPL-01": [ - "Article 3.1", - "Article 39" - ], - "CPL-01.2": [ - "Article 38.2" - ], - "CPL-02": [ - "Article 10.1", - "Article 10.2", - "Article 10.3" - ], - "CPL-02.1": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 41.1", - "Article 41.2" - ], - "CPL-03": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7" - ], - "CPL-03.1": [ - "Article 38.1" - ], - "CPL-03.2": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 38.1" - ], - "CFG-01": [ - "Article 30.1", - "Article 30.2" - ], - "CFG-02": [ - "Article 20(d)" - ], - "CFG-02.2": [ - "Article 21.2" - ], - "CFG-03": [ - "Article 20(a)", - "Article 20(b)", - "Article 20(c)", - "Article 20(d)" - ], - "CFG-03.1": [ - "Article 21.2" - ], - "MON-01": [ - "Article 10.1", - "Article 21.2", - "Article 24.1" - ], - "MON-03": [ - "Article 24.1" - ], - "MON-16": [ - "Article 10.1" - ], - "DCH-01": [ - "Article 22.1", - "Article 22.3" - ], - "DCH-01.2": [ - "Article 22.1", - "Article 22.3" - ], - "DCH-02": [ - "Article 40.1", - "Article 40.2", - "Article 41.2" - ], - "DCH-18.1": [ - "Article 24.2" - ], - "HRS-01": [ - "Article 15.1" - ], - "HRS-02": [ - "Article 13.2" - ], - "HRS-03": [ - "Article 11.1", - "Article 11.2", - "Article 11.3", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.2(d)", - "Article 13.3", - "Article 13.4", - "Article 13.5" - ], - "HRS-03.1": [ - "Article 13.1", - "Article 15.1" - ], - "HRS-03.2": [ - "Article 15.1", - "Article 16.1", - "Article 16.2", - "Article 16.3" - ], - "HRS-04.2": [ - "Article 13.2", - "Article 15.1" - ], - "HRS-05": [ - "Article 11.2", - "Article 11.3" - ], - "HRS-05.1": [ - "Article 11.2", - "Article 11.3" - ], - "HRS-11": [ - "Article 13.3" - ], - "IAC-01": [ - "Article 18" - ], - "IAC-02": [ - "Article 24.3" - ], - "IAC-03": [ - "Article 24.3" - ], - "IAC-08": [ - "Article 17" - ], - "IAC-21": [ - "Article 17", - "Article 20" - ], - "IRO-01": [ - "Article 25.1" - ], - "IRO-02": [ - "Article 25.1", - "Article 25.2", - "Article 33.4" - ], - "IRO-02.4": [ - "Article 33.4" - ], - "IRO-04": [ - "Article 25.1", - "Article 25.2" - ], - "IRO-07": [ - "Article 33.3" - ], - "IRO-09": [ - "Article 25.2" - ], - "IRO-10": [ - "Article 25.2", - "Article 33.2", - "Article 33.4", - "Article 33.7" - ], - "NET-01": [ - "Article 23" - ], - "PES-01": [ - "Article 18" - ], - "PRM-07": [ - "Article 8 (end)", - "Article 36" - ], - "RSK-01": [ - "Article 7.1", - "Article 7.2" - ], - "RSK-03": [ - "Article 3.2" - ], - "RSK-04": [ - "Article 3.2", - "Article 14.1", - "Article 14.2" - ], - "RSK-06": [ - "Article 14.2", - "Article 14.3" - ], - "RSK-06.1": [ - "Article 14.2", - "Article 14.3" - ], - "SEA-01": [ - "Article 29" - ], - "SEA-02": [ - "Article 29" - ], - "SEA-02.1": [ - "Article 4" - ], - "SEA-03": [ - "Article 9.1", - "Article 9.1(a)", - "Article 9.1(b)", - "Article 9.2" - ], - "SEA-07.1": [ - "Article 36" - ], - "OPS-01": [ - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5" - ], - "OPS-01.1": [ - "Article 13.2(d)", - "Article 13.4", - "Article 22.2" - ], - "SAT-01": [ - "Article 6.2" - ], - "TDA-01": [ - "Article 19.1", - "Article 19.2", - "Article 19.2(a)", - "Article 19.2(b)", - "Article 19.2(c)", - "Article 19.3" - ], - "TPM-04": [ - "Article 13.5" - ], - "TPM-05.4": [ - "Article 13.2", - "Article 13.5" - ] - } - }, - "framework_to_scf": { - "total_mappings": 132, - "mappings": { - "Article 5": [ - "GOV-01", - "GOV-01.1", - "GOV-15" - ], - "Article 6.1": [ - "GOV-01" - ], - "Article 6.2": [ - "GOV-01", - "SAT-01" - ], - "Article 13.1": [ - "GOV-01", - "HRS-03", - "HRS-03.1" - ], - "Article 35.1": [ - "GOV-01" - ], - "Article 27": [ - "GOV-01.1", - "GOV-03" - ], - "Article 12.1": [ - "GOV-02" - ], - "Article 12.1(a)": [ - "GOV-02" - ], - "Article 12.1(b)": [ - "GOV-02" - ], - "Article 12.1(c)": [ - "GOV-02" - ], - "Article 12.1(d)": [ - "GOV-02" - ], - "Article 12.1(e)": [ - "GOV-02" - ], - "Article 12.1(f)": [ - "GOV-02" - ], - "Article 12.2": [ - "GOV-02" - ], - "Article 12.6": [ - "GOV-02" - ], - "Article 12.6(a)": [ - "GOV-02" - ], - "Article 12.6(b)": [ - "GOV-02" - ], - "Article 12.6(c)": [ - "GOV-02" - ], - "Article 12.6(d)": [ - "GOV-02" - ], - "Article 12.6(e)": [ - "GOV-02" - ], - "Article 12.6(f)": [ - "GOV-02" - ], - "Article 12.6(g)": [ - "GOV-02" - ], - "Article 12.6(h)": [ - "GOV-02" - ], - "Article 12.6(i)": [ - "GOV-02" - ], - "Article 12.6(j)": [ - "GOV-02" - ], - "Article 12.6(k)": [ - "GOV-02" - ], - "Article 12.6(l)": [ - "GOV-02" - ], - "Article 12.6(m)": [ - "GOV-02" - ], - "Article 12.6(n)": [ - "GOV-02" - ], - "Article 12.6(ñ)": [ - "GOV-02" - ], - "Article 12.7": [ - "GOV-02" - ], - "Article 32.1": [ - "GOV-06" - ], - "Article 32.2": [ - "GOV-06" - ], - "Article 32.3": [ - "GOV-06" - ], - "Article 5(a)": [ - "GOV-15" - ], - "Article 5(b)": [ - "GOV-15" - ], - "Article 5(c)": [ - "GOV-15" - ], - "Article 5(d)": [ - "GOV-15" - ], - "Article 5(e)": [ - "GOV-15" - ], - "Article 5(f)": [ - "GOV-15" - ], - "Article 5(g)": [ - "GOV-15" - ], - "Article 8.1": [ - "GOV-15", - "OPS-01" - ], - "Article 8.2": [ - "GOV-15", - "OPS-01" - ], - "Article 8.3": [ - "GOV-15", - "OPS-01" - ], - "Article 8.4": [ - "GOV-15", - "OPS-01" - ], - "Article 8.5": [ - "GOV-15", - "OPS-01" - ], - "Article 28.1": [ - "GOV-15" - ], - "Article 37": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" - ], - "Article 3.3": [ - "GOV-15.1", - "GOV-15.2" - ], - "Article 28.1(a)": [ - "GOV-15.1" - ], - "Article 28.1(b)": [ - "GOV-15.1" - ], - "Article 28.1(c)": [ - "GOV-15.1" - ], - "Article 28.2": [ - "GOV-15.1" - ], - "Article 28.3": [ - "GOV-15.1" - ], - "Article 18": [ - "AST-01", - "IAC-01", - "PES-01" - ], - "Article 26": [ - "BCD-01", - "BCD-11" - ], - "Article 21.1": [ - "CHG-01", - "CHG-02" - ], - "Article 3.1": [ - "CPL-01" - ], - "Article 39": [ - "CPL-01" - ], - "Article 38.2": [ - "CPL-01.2" - ], - "Article 10.1": [ - "CPL-02", - "MON-01", - "MON-16" - ], - "Article 10.2": [ - "CPL-02" - ], - "Article 10.3": [ - "CPL-02" - ], - "Article 31.1": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" - ], - "Article 31.2": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" - ], - "Article 31.3": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" - ], - "Article 31.4": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" - ], - "Article 31.5": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" - ], - "Article 31.6": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" - ], - "Article 31.7": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" - ], - "Article 41.1": [ - "CPL-02.1" - ], - "Article 41.2": [ - "CPL-02.1", - "DCH-02" - ], - "Article 38.1": [ - "CPL-03.1", - "CPL-03.2" - ], - "Article 30.1": [ - "CFG-01" - ], - "Article 30.2": [ - "CFG-01" - ], - "Article 20(d)": [ - "CFG-02", - "CFG-03" - ], - "Article 21.2": [ - "CFG-02.2", - "CFG-03.1", - "MON-01" - ], - "Article 20(a)": [ - "CFG-03" - ], - "Article 20(b)": [ - "CFG-03" - ], - "Article 20(c)": [ - "CFG-03" - ], - "Article 24.1": [ - "MON-01", - "MON-03" - ], - "Article 22.1": [ - "DCH-01", - "DCH-01.2" - ], - "Article 22.3": [ - "DCH-01", - "DCH-01.2" - ], - "Article 40.1": [ - "DCH-02" - ], - "Article 40.2": [ - "DCH-02" - ], - "Article 24.2": [ - "DCH-18.1" - ], - "Article 15.1": [ - "HRS-01", - "HRS-03.1", - "HRS-03.2", - "HRS-04.2" - ], - "Article 13.2": [ - "HRS-02", - "HRS-03", - "HRS-04.2", - "TPM-05.4" - ], - "Article 11.1": [ - "HRS-03" - ], - "Article 11.2": [ - "HRS-03", - "HRS-05", - "HRS-05.1" - ], - "Article 11.3": [ - "HRS-03", - "HRS-05", - "HRS-05.1" - ], - "Article 13.2(a)": [ - "HRS-03" - ], - "Article 13.2(b)": [ - "HRS-03" - ], - "Article 13.2(c)": [ - "HRS-03" - ], - "Article 13.2(d)": [ - "HRS-03", - "OPS-01.1" - ], - "Article 13.3": [ - "HRS-03", - "HRS-11" - ], - "Article 13.4": [ - "HRS-03", - "OPS-01.1" - ], - "Article 13.5": [ - "HRS-03", - "TPM-04", - "TPM-05.4" - ], - "Article 16.1": [ - "HRS-03.2" - ], - "Article 16.2": [ - "HRS-03.2" - ], - "Article 16.3": [ - "HRS-03.2" - ], - "Article 24.3": [ - "IAC-02", - "IAC-03" - ], - "Article 17": [ - "IAC-08", - "IAC-21" - ], - "Article 20": [ - "IAC-21" - ], - "Article 25.1": [ - "IRO-01", - "IRO-02", - "IRO-04" - ], - "Article 25.2": [ - "IRO-02", - "IRO-04", - "IRO-09", - "IRO-10" - ], - "Article 33.4": [ - "IRO-02", - "IRO-02.4", - "IRO-10" - ], - "Article 33.3": [ - "IRO-07" - ], - "Article 33.2": [ - "IRO-10" - ], - "Article 33.7": [ - "IRO-10" - ], - "Article 23": [ - "NET-01" - ], - "Article 8 (end)": [ - "PRM-07" - ], - "Article 36": [ - "PRM-07", - "SEA-07.1" - ], - "Article 7.1": [ - "RSK-01" - ], - "Article 7.2": [ - "RSK-01" - ], - "Article 3.2": [ - "RSK-03", - "RSK-04" - ], - "Article 14.1": [ - "RSK-04" - ], - "Article 14.2": [ - "RSK-04", - "RSK-06", - "RSK-06.1" - ], - "Article 14.3": [ - "RSK-06", - "RSK-06.1" - ], - "Article 29": [ - "SEA-01", - "SEA-02" - ], - "Article 4": [ - "SEA-02.1" - ], - "Article 9.1": [ - "SEA-03" - ], - "Article 9.1(a)": [ - "SEA-03" - ], - "Article 9.1(b)": [ - "SEA-03" - ], - "Article 9.2": [ - "SEA-03" - ], - "Article 22.2": [ - "OPS-01.1" - ], - "Article 19.1": [ - "TDA-01" - ], - "Article 19.2": [ - "TDA-01" - ], - "Article 19.2(a)": [ - "TDA-01" - ], - "Article 19.2(b)": [ - "TDA-01" - ], - "Article 19.2(c)": [ - "TDA-01" - ], - "Article 19.3": [ - "TDA-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-esp-ccn-stic-825-2023.json b/docs/api/crosswalks/emea-esp-ccn-stic-825-2023.json deleted file mode 100644 index f5f900a0..00000000 --- a/docs/api/crosswalks/emea-esp-ccn-stic-825-2023.json +++ /dev/null @@ -1,608 +0,0 @@ -{ - "framework_id": "emea-esp-ccn-stic-825-2023", - "display_name": "Spain - ICT Security Guide CCN-STIC 825 (2023)", - "scf_to_framework": { - "total_mappings": 99, - "mappings": { - "GOV-01": [ - "6.1 [ORG.1]" - ], - "GOV-02": [ - "6.1 [ORG.1]", - "6.2 [ORG.2]" - ], - "GOV-05": [ - "7.6.2 [OP.MON.2]" - ], - "AST-02": [ - "7.3.1 [OP.EXP.1]" - ], - "AST-06": [ - "8.3.2 [MP.EQ.2]" - ], - "AST-09": [ - "8.5.5 [MP.SI.5]" - ], - "BCD-01": [ - "7.5.1 [OP.CONT.1]", - "7.5.2 [OP.CONT.2]" - ], - "BCD-04": [ - "7.5.3 [OP.CONT.3]" - ], - "BCD-08": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.4.4 [MP.COM.4]", - "8.8.4 [MP.S.4]" - ], - "BCD-09": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.8.4 [MP.S.4]" - ], - "BCD-11": [ - "8.7.7 [MP.INFO.7]" - ], - "CAP-01": [ - "7.1.4 [OP.PL.4]" - ], - "CHG-01": [ - "7.3.5 [OP.EXP.5]" - ], - "CPL-01": [ - "7.1.5 [OP.PL.5]" - ], - "CPL-02": [ - "9" - ], - "CPL-03.1": [ - "9" - ], - "CFG-01": [ - "7.3.3 [OP.EXP.3]" - ], - "CFG-02": [ - "7.3.2 [OP.EXP.2]" - ], - "MON-01": [ - "7.3.8 [OP.EXP.8]" - ], - "MON-01.1": [ - "7.6.1 [OP.MON.1]" - ], - "MON-01.4": [ - "7.3.8 [OP.EXP.8]" - ], - "MON-01.16": [ - "7.3.8 [OP.EXP.8]" - ], - "MON-02.2": [ - "7.3.8 [OP.EXP.8]" - ], - "MON-03": [ - "7.3.8 [OP.EXP.8]" - ], - "MON-07": [ - "8.7.5 [MP.INFO.5]" - ], - "MON-08": [ - "7.3.10 [OP.EXP.10]" - ], - "CRY-01": [ - "8.4.2 [MP.COM.2]", - "8.4.3 [MP.COM.3]", - "8.5.2 [MP.SI.2]", - "8.7.3 [MP.INFO.3]", - "8.7.4 [MP.INFO.4]" - ], - "CRY-09": [ - "7.3.11 [OP.EXP.11]" - ], - "DCH-01": [ - "8.5.3 [MP.SI.3]" - ], - "DCH-01.1": [ - "8.5.3 [MP.SI.3]" - ], - "DCH-02": [ - "8.7.2 [MP.INFO.2]" - ], - "DCH-04": [ - "8.5.1 [MP.SI.1]" - ], - "DCH-07": [ - "8.5.4 [MP.SI.4]" - ], - "DCH-07.1": [ - "8.5.3 [MP.SI.3]" - ], - "DCH-08": [ - "8.5.5 [MP.SI.5]" - ], - "DCH-09": [ - "8.7.6 [MP.INFO.6]" - ], - "DCH-18": [ - "9" - ], - "END-01": [ - "8.3.1 [MP.EQ.1]" - ], - "END-04": [ - "7.3.6 [OP.EXP.6]" - ], - "END-07": [ - "7.6.1 [OP.MON.1]" - ], - "HRS-03": [ - "6.4 [ORG.4]", - "8.2.1 [MP.PER.1]", - "8.2.2 [MP.PER.2]" - ], - "HRS-05": [ - "8.2.2 [MP.PER.2]" - ], - "HRS-11": [ - "7.2.3 [OP.ACC.3]" - ], - "HRS-13.2": [ - "8.2.5 [MP.PER.5]" - ], - "HRS-13.3": [ - "8.2.5 [MP.PER.5]" - ], - "HRS-13.4": [ - "8.2.5 [MP.PER.5]" - ], - "IAC-01": [ - "7.2.2 [OP.ACC.2]", - "7.2.4 [OP.ACC.4]" - ], - "IAC-07": [ - "7.2.1 [OP.ACC.1]" - ], - "IAC-08": [ - "7.2.4 [OP.ACC.4]" - ], - "IAC-10": [ - "7.2.5 [OP.ACC.5]" - ], - "IAC-10.1": [ - "7.2.5 [OP.ACC.5]" - ], - "IAC-10.5": [ - "7.2.5 [OP.ACC.5]" - ], - "IAC-10.11": [ - "7.2.5 [OP.ACC.5]" - ], - "IRO-01": [ - "7.3.7 [OP.EXP.7]" - ], - "IRO-02": [ - "7.3.7 [OP.EXP.7]", - "7.3.9 [OP.EXP.9]" - ], - "MNT-01": [ - "7.3.4 [OP.EXP.4]" - ], - "MDM-01": [ - "8.3.3 [MP.EQ.3]" - ], - "NET-01": [ - "8.4.1 [MP.COM.1]", - "8.4.2 [MP.COM.2]" - ], - "NET-02.1": [ - "8.8.3 [MP.S.3]" - ], - "NET-06": [ - "8.4.4 [MP.COM.4]" - ], - "NET-08": [ - "7.6.1 [OP.MON.1]" - ], - "NET-08.2": [ - "7.6.1 [OP.MON.1]" - ], - "NET-13": [ - "8.8.1 [MP.S.1]" - ], - "NET-14": [ - "7.2.7 [OP.ACC.7]" - ], - "NET-14.5": [ - "7.2.7 [OP.ACC.7]", - "9" - ], - "PES-01.1": [ - "8.1.1 [MP.IF.1]" - ], - "PES-02": [ - "8.1.1 [MP.IF.1]" - ], - "PES-02.1": [ - "8.1.1 [MP.IF.1]" - ], - "PES-03": [ - "8.1.1 [MP.IF.1]" - ], - "PES-06": [ - "8.1.2 [MP.IF.2]", - "8.1.7 [MP.IF.7]" - ], - "PES-06.2": [ - "8.1.2 [MP.IF.2]" - ], - "PES-07": [ - "8.1.3 [MP.IF.3]", - "8.1.4 [MP.IF.4]" - ], - "PES-07.1": [ - "8.1.4 [MP.IF.4]" - ], - "PES-07.6": [ - "8.1.6 [MP.IF.6]" - ], - "PES-08": [ - "8.1.5 [MP.IF.5]" - ], - "PES-12": [ - "8.1.3 [MP.IF.3]" - ], - "PRI-01": [ - "8.7.1 [MP.INFO.1]" - ], - "PRM-01": [ - "9" - ], - "PRM-05": [ - "7.1.3 [OP.PL.3]" - ], - "RSK-04": [ - "7.1.1 [OP.PL.1]" - ], - "SEA-01": [ - "7.1.2 [OP.PL.2]" - ], - "SEA-02": [ - "7.1.2 [OP.PL.2]" - ], - "SEA-03": [ - "7.1.2 [OP.PL.2]" - ], - "SEA-17": [ - "7.2.6 [OP.ACC.6]" - ], - "OPS-01.1": [ - "6.3 [ORG.3]" - ], - "SAT-01": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" - ], - "SAT-02": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" - ], - "SAT-03": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" - ], - "TDA-01": [ - "7.1.3 [OP.PL.3]", - "8.6.1 [MP.SW.1]" - ], - "TDA-02.3": [ - "8.6.1 [MP.SW.1]" - ], - "TDA-06.3": [ - "8.6.1 [MP.SW.1]" - ], - "TDA-06.5": [ - "8.6.2 [MP.SW.2]" - ], - "TDA-09": [ - "8.6.2 [MP.SW.2]" - ], - "TDA-17.1": [ - "7.4.3 [OP.EXT.3]" - ], - "TPM-01": [ - "7.4.1 [OP.EXT.1]" - ], - "TPM-03": [ - "7.4.1 [OP.EXT.1]", - "7.4.3 [OP.EXT.3]" - ], - "TPM-05": [ - "7.4.1 [OP.EXT.1]" - ], - "TPM-10": [ - "7.4.2 [OP.EXT.2]" - ], - "WEB-01": [ - "8.8.2 [MP.S.2]" - ] - } - }, - "framework_to_scf": { - "total_mappings": 75, - "mappings": { - "9": [ - "CPL-02", - "CPL-03.1", - "DCH-18", - "NET-14.5", - "PRM-01" - ], - "6.1 [ORG.1]": [ - "GOV-01", - "GOV-02" - ], - "6.2 [ORG.2]": [ - "GOV-02" - ], - "7.6.2 [OP.MON.2]": [ - "GOV-05" - ], - "7.3.1 [OP.EXP.1]": [ - "AST-02" - ], - "8.3.2 [MP.EQ.2]": [ - "AST-06" - ], - "8.5.5 [MP.SI.5]": [ - "AST-09", - "DCH-08" - ], - "7.5.1 [OP.CONT.1]": [ - "BCD-01" - ], - "7.5.2 [OP.CONT.2]": [ - "BCD-01" - ], - "7.5.3 [OP.CONT.3]": [ - "BCD-04" - ], - "8.1.8 [MP.IF.8]": [ - "BCD-08", - "BCD-09" - ], - "8.3.4 [MP.EQ.4]": [ - "BCD-08", - "BCD-09" - ], - "8.4.4 [MP.COM.4]": [ - "BCD-08", - "NET-06" - ], - "8.8.4 [MP.S.4]": [ - "BCD-08", - "BCD-09" - ], - "8.7.7 [MP.INFO.7]": [ - "BCD-11" - ], - "7.1.4 [OP.PL.4]": [ - "CAP-01" - ], - "7.3.5 [OP.EXP.5]": [ - "CHG-01" - ], - "7.1.5 [OP.PL.5]": [ - "CPL-01" - ], - "7.3.3 [OP.EXP.3]": [ - "CFG-01" - ], - "7.3.2 [OP.EXP.2]": [ - "CFG-02" - ], - "7.3.8 [OP.EXP.8]": [ - "MON-01", - "MON-01.4", - "MON-01.16", - "MON-02.2", - "MON-03" - ], - "7.6.1 [OP.MON.1]": [ - "MON-01.1", - "END-07", - "NET-08", - "NET-08.2" - ], - "8.7.5 [MP.INFO.5]": [ - "MON-07" - ], - "7.3.10 [OP.EXP.10]": [ - "MON-08" - ], - "8.4.2 [MP.COM.2]": [ - "CRY-01", - "NET-01" - ], - "8.4.3 [MP.COM.3]": [ - "CRY-01" - ], - "8.5.2 [MP.SI.2]": [ - "CRY-01" - ], - "8.7.3 [MP.INFO.3]": [ - "CRY-01" - ], - "8.7.4 [MP.INFO.4]": [ - "CRY-01" - ], - "7.3.11 [OP.EXP.11]": [ - "CRY-09" - ], - "8.5.3 [MP.SI.3]": [ - "DCH-01", - "DCH-01.1", - "DCH-07.1" - ], - "8.7.2 [MP.INFO.2]": [ - "DCH-02" - ], - "8.5.1 [MP.SI.1]": [ - "DCH-04" - ], - "8.5.4 [MP.SI.4]": [ - "DCH-07" - ], - "8.7.6 [MP.INFO.6]": [ - "DCH-09" - ], - "8.3.1 [MP.EQ.1]": [ - "END-01" - ], - "7.3.6 [OP.EXP.6]": [ - "END-04" - ], - "6.4 [ORG.4]": [ - "HRS-03" - ], - "8.2.1 [MP.PER.1]": [ - "HRS-03" - ], - "8.2.2 [MP.PER.2]": [ - "HRS-03", - "HRS-05" - ], - "7.2.3 [OP.ACC.3]": [ - "HRS-11" - ], - "8.2.5 [MP.PER.5]": [ - "HRS-13.2", - "HRS-13.3", - "HRS-13.4" - ], - "7.2.2 [OP.ACC.2]": [ - "IAC-01" - ], - "7.2.4 [OP.ACC.4]": [ - "IAC-01", - "IAC-08" - ], - "7.2.1 [OP.ACC.1]": [ - "IAC-07" - ], - "7.2.5 [OP.ACC.5]": [ - "IAC-10", - "IAC-10.1", - "IAC-10.5", - "IAC-10.11" - ], - "7.3.7 [OP.EXP.7]": [ - "IRO-01", - "IRO-02" - ], - "7.3.9 [OP.EXP.9]": [ - "IRO-02" - ], - "7.3.4 [OP.EXP.4]": [ - "MNT-01" - ], - "8.3.3 [MP.EQ.3]": [ - "MDM-01" - ], - "8.4.1 [MP.COM.1]": [ - "NET-01" - ], - "8.8.3 [MP.S.3]": [ - "NET-02.1" - ], - "8.8.1 [MP.S.1]": [ - "NET-13" - ], - "7.2.7 [OP.ACC.7]": [ - "NET-14", - "NET-14.5" - ], - "8.1.1 [MP.IF.1]": [ - "PES-01.1", - "PES-02", - "PES-02.1", - "PES-03" - ], - "8.1.2 [MP.IF.2]": [ - "PES-06", - "PES-06.2" - ], - "8.1.7 [MP.IF.7]": [ - "PES-06" - ], - "8.1.3 [MP.IF.3]": [ - "PES-07", - "PES-12" - ], - "8.1.4 [MP.IF.4]": [ - "PES-07", - "PES-07.1" - ], - "8.1.6 [MP.IF.6]": [ - "PES-07.6" - ], - "8.1.5 [MP.IF.5]": [ - "PES-08" - ], - "8.7.1 [MP.INFO.1]": [ - "PRI-01" - ], - "7.1.3 [OP.PL.3]": [ - "PRM-05", - "TDA-01" - ], - "7.1.1 [OP.PL.1]": [ - "RSK-04" - ], - "7.1.2 [OP.PL.2]": [ - "SEA-01", - "SEA-02", - "SEA-03" - ], - "7.2.6 [OP.ACC.6]": [ - "SEA-17" - ], - "6.3 [ORG.3]": [ - "OPS-01.1" - ], - "8.2.3 [MP.PER.3]": [ - "SAT-01", - "SAT-02", - "SAT-03" - ], - "8.2.4 [MP.PER.4]": [ - "SAT-01", - "SAT-02", - "SAT-03" - ], - "8.6.1 [MP.SW.1]": [ - "TDA-01", - "TDA-02.3", - "TDA-06.3" - ], - "8.6.2 [MP.SW.2]": [ - "TDA-06.5", - "TDA-09" - ], - "7.4.3 [OP.EXT.3]": [ - "TDA-17.1", - "TPM-03" - ], - "7.4.1 [OP.EXT.1]": [ - "TPM-01", - "TPM-03", - "TPM-05" - ], - "7.4.2 [OP.EXT.2]": [ - "TPM-10" - ], - "8.8.2 [MP.S.2]": [ - "WEB-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-esp-ccn-stic-825-2026.json b/docs/api/crosswalks/emea-esp-ccn-stic-825-2026.json new file mode 100644 index 00000000..535efe45 --- /dev/null +++ b/docs/api/crosswalks/emea-esp-ccn-stic-825-2026.json @@ -0,0 +1,1546 @@ +{ + "framework_id": "emea-esp-ccn-stic-825-2026", + "display_name": "Spain - ICT Security Guide CCN - STIC 825 (2026)", + "scf_to_framework": { + "total_mappings": 234, + "mappings": { + "GOV-01": [ + "org.1", + "org.2", + "org.3" + ], + "GOV-01.2": [ + "op.mon.2" + ], + "GOV-02": [ + "org.1", + "org.2", + "org.3" + ], + "GOV-03": [ + "org.1", + "org.2", + "org.3" + ], + "GOV-04": [ + "org.4" + ], + "GOV-05": [ + "op.mon.2" + ], + "GOV-10": [ + "mp.info.2" + ], + "AST-01": [ + "op.cont.3" + ], + "AST-01.1": [ + "op.pl.2", + "op.exp.1", + "op.cont.3" + ], + "AST-01.2": [ + "op.pl.2", + "op.exp.1" + ], + "AST-02": [ + "op.pl.2", + "op.exp.1" + ], + "AST-02.8": [ + "op.pl.2", + "op.exp.1" + ], + "AST-02.9": [ + "op.exp.2", + "op.exp.3" + ], + "AST-03": [ + "op.pl.2", + "op.exp.1" + ], + "AST-03.1": [ + "op.pl.2", + "op.exp.1" + ], + "AST-03.2": [ + "op.ext.3" + ], + "AST-04": [ + "op.pl.2", + "op.exp.1", + "op.mon.1", + "mp.com.1" + ], + "AST-04.1": [ + "mp.info.2" + ], + "AST-06": [ + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" + ], + "AST-07": [ + "mp.eq.3", + "mp.eq.4" + ], + "AST-11": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "AST-12": [ + "mp.eq.3", + "mp.eq.4", + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "BCD-01": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" + ], + "BCD-01.1": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" + ], + "BCD-01.2": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" + ], + "BCD-04": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" + ], + "BCD-08": [ + "op.cont.4" + ], + "BCD-09": [ + "op.cont.4" + ], + "BCD-11": [ + "mp.info.6" + ], + "BCD-11.1": [ + "mp.info.6" + ], + "BCD-11.2": [ + "mp.info.6" + ], + "BCD-11.4": [ + "mp.info.6" + ], + "BCD-11.7": [ + "op.cont.4" + ], + "CAP-01": [ + "op.pl.4", + "mp.s.4" + ], + "CAP-03": [ + "op.pl.4", + "mp.s.4" + ], + "CHG-01": [ + "op.exp.5" + ], + "CHG-02": [ + "op.exp.5" + ], + "CHG-02.2": [ + "op.exp.5" + ], + "CLD-01": [ + "op.nub.1" + ], + "CLD-04": [ + "mp.info.4", + "mp.s.2" + ], + "CPL-01": [ + "op.mon.2" + ], + "CPL-01.1": [ + "op.mon.2" + ], + "CPL-01.2": [ + "op.mon.2" + ], + "CPL-03": [ + "op.mon.2" + ], + "CFG-01": [ + "op.exp.2", + "op.exp.3" + ], + "CFG-01.1": [ + "op.exp.2", + "op.exp.3" + ], + "CFG-02": [ + "op.acc.6", + "op.exp.2", + "op.exp.3", + "mp.sw.1", + "mp.info.4", + "mp.s.2" + ], + "CFG-02.1": [ + "op.exp.2", + "op.exp.3" + ], + "CFG-02.4": [ + "mp.sw.1" + ], + "CFG-03": [ + "op.exp.2", + "op.exp.3" + ], + "MON-01": [ + "op.exp.8" + ], + "MON-01.4": [ + "op.exp.8" + ], + "MON-02": [ + "op.exp.8" + ], + "MON-02.1": [ + "op.exp.8" + ], + "MON-02.2": [ + "op.exp.8" + ], + "MON-03": [ + "op.exp.8" + ], + "MON-03.3": [ + "op.exp.8" + ], + "MON-06": [ + "op.exp.8" + ], + "MON-08": [ + "op.exp.8" + ], + "MON-11": [ + "op.mon.3" + ], + "MON-11.3": [ + "op.mon.3" + ], + "CRY-01": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" + ], + "CRY-03": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.1", + "mp.s.2" + ], + "CRY-04": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" + ], + "CRY-05": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" + ], + "CRY-09": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" + ], + "CRY-09.3": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" + ], + "CRY-09.4": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" + ], + "DCH-01": [ + "op.pl.2", + "op.exp.1", + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.info.2" + ], + "DCH-02": [ + "op.pl.2", + "op.exp.1", + "mp.info.2" + ], + "DCH-03": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "DCH-04": [ + "mp.si.1" + ], + "DCH-06": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "DCH-07": [ + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.s.1" + ], + "DCH-07.1": [ + "mp.s.1" + ], + "DCH-07.2": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "DCH-08": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "DCH-10": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "DCH-10.1": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "DCH-12": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "DCH-14": [ + "mp.s.1" + ], + "DCH-17": [ + "mp.s.1" + ], + "END-01": [ + "op.acc.6", + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" + ], + "END-02": [ + "op.acc.6", + "mp.eq.3", + "mp.eq.4" + ], + "END-04": [ + "op.exp.6" + ], + "END-04.1": [ + "op.exp.6" + ], + "END-09": [ + "op.acc.6" + ], + "HRS-03": [ + "org.4" + ], + "HRS-04": [ + "op.pl.1", + "mp.per.1" + ], + "HRS-04.1": [ + "org.4", + "op.pl.1", + "mp.per.1" + ], + "HRS-05": [ + "mp.s.1" + ], + "HRS-05.1": [ + "mp.s.1" + ], + "HRS-06": [ + "mp.s.1" + ], + "HRS-06.1": [ + "mp.s.1" + ], + "HRS-11": [ + "op.acc.3", + "op.acc.4", + "op.acc.5" + ], + "HRS-12": [ + "op.acc.3" + ], + "IAC-01": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-02": [ + "op.acc.2" + ], + "IAC-03": [ + "op.acc.1" + ], + "IAC-04": [ + "op.acc.1" + ], + "IAC-05": [ + "op.acc.1" + ], + "IAC-07": [ + "op.acc.1", + "op.acc.4", + "op.acc.5" + ], + "IAC-07.1": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-07.2": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-08": [ + "op.acc.2" + ], + "IAC-09": [ + "op.acc.1" + ], + "IAC-09.1": [ + "op.acc.1" + ], + "IAC-09.4": [ + "op.acc.1" + ], + "IAC-10": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-10.11": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-15": [ + "op.acc.1", + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-15.1": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-15.2": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-15.3": [ + "op.acc.1" + ], + "IAC-15.5": [ + "op.acc.1" + ], + "IAC-16": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-16.1": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-17": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-19": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-20": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-20.1": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-20.2": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-20.3": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-21": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "IAC-21.3": [ + "op.acc.4", + "op.acc.5" + ], + "IAC-22": [ + "mp.eq.3", + "mp.eq.4" + ], + "IRO-01": [ + "op.exp.7" + ], + "IRO-02": [ + "op.exp.7", + "op.exp.9" + ], + "IRO-04": [ + "op.exp.7", + "op.exp.9" + ], + "IRO-05": [ + "op.cont.1", + "op.cont.2" + ], + "IRO-06": [ + "op.cont.3" + ], + "IRO-06.1": [ + "op.cont.1", + "op.cont.2" + ], + "IRO-07": [ + "op.exp.9" + ], + "IRO-08": [ + "op.exp.9" + ], + "IRO-11.2": [ + "op.cont.1", + "op.cont.2" + ], + "IRO-13": [ + "op.exp.7" + ], + "IAO-01": [ + "op.ext.3" + ], + "IAO-02": [ + "op.ext.3", + "mp.sw.2" + ], + "IAO-02.2": [ + "op.ext.3", + "mp.sw.2" + ], + "IAO-04": [ + "mp.sw.1" + ], + "MNT-01": [ + "op.exp.4" + ], + "MNT-02": [ + "op.exp.4" + ], + "MNT-03": [ + "op.exp.4" + ], + "MDM-01": [ + "mp.eq.3", + "mp.eq.4" + ], + "MDM-02": [ + "mp.eq.3", + "mp.eq.4" + ], + "MDM-05": [ + "mp.eq.3", + "mp.eq.4" + ], + "NET-01": [ + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3", + "mp.s.1" + ], + "NET-02": [ + "op.mon.1", + "mp.com.1" + ], + "NET-03": [ + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3" + ], + "NET-04": [ + "op.mon.1", + "mp.com.1", + "mp.s.1" + ], + "NET-04.1": [ + "op.mon.1", + "mp.com.1", + "mp.s.1" + ], + "NET-06": [ + "op.ext.4", + "op.mon.1", + "mp.com.1", + "mp.com.4" + ], + "NET-06.1": [ + "op.ext.4", + "mp.com.4" + ], + "NET-08": [ + "mp.com.2", + "mp.com.3" + ], + "NET-08.1": [ + "op.mon.1", + "mp.com.1" + ], + "NET-13": [ + "mp.s.1" + ], + "NET-15": [ + "mp.com.2", + "mp.com.3" + ], + "NET-18": [ + "mp.s.1", + "mp.s.3" + ], + "PES-01": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.s.1" + ], + "PES-02": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" + ], + "PES-02.1": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "PES-03": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" + ], + "PES-03.1": [ + "mp.if.1", + "mp.if.2", + "mp.if.7" + ], + "PES-03.3": [ + "mp.if.2", + "mp.if.7" + ], + "PES-04": [ + "op.acc.2", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.eq.1", + "mp.eq.2" + ], + "PES-04.1": [ + "op.acc.2", + "mp.if.2", + "mp.if.7" + ], + "PES-06": [ + "mp.if.2", + "mp.if.7" + ], + "PES-07": [ + "mp.if.4" + ], + "PES-07.1": [ + "mp.if.4" + ], + "PES-07.2": [ + "mp.if.4" + ], + "PES-07.3": [ + "mp.if.4" + ], + "PES-07.4": [ + "mp.if.4" + ], + "PES-10": [ + "mp.if.2", + "mp.if.7" + ], + "PES-12": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" + ], + "PRI-01": [ + "org.1", + "org.2", + "mp.info.1" + ], + "PRI-01.3": [ + "org.1", + "org.2" + ], + "PRI-01.6": [ + "mp.info.1" + ], + "PRI-02": [ + "mp.info.1" + ], + "PRI-02.1": [ + "mp.info.1" + ], + "PRI-05.5": [ + "op.pl.2", + "op.exp.1" + ], + "PRM-01": [ + "op.pl.3" + ], + "PRM-04": [ + "op.pl.3" + ], + "PRM-05": [ + "op.pl.2", + "op.pl.3", + "op.exp.1", + "mp.info.4", + "mp.s.2" + ], + "PRM-07": [ + "op.pl.3", + "op.exp.5", + "mp.sw.1" + ], + "RSK-01": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" + ], + "RSK-01.1": [ + "op.pl.3" + ], + "RSK-03": [ + "op.pl.3" + ], + "RSK-04": [ + "op.pl.3", + "mp.if.3", + "mp.if.5", + "mp.if.6" + ], + "RSK-06": [ + "op.pl.3" + ], + "RSK-06.1": [ + "op.pl.3" + ], + "RSK-08": [ + "op.cont.3" + ], + "RSK-09": [ + "op.ext.3" + ], + "SEA-01": [ + "mp.info.4", + "mp.s.2" + ], + "SEA-02": [ + "op.pl.3", + "mp.info.4", + "mp.s.2" + ], + "SEA-17": [ + "op.acc.6" + ], + "OPS-01": [ + "org.3" + ], + "OPS-01.1": [ + "org.3" + ], + "OPS-03": [ + "org.3" + ], + "SAT-01": [ + "mp.per.3", + "mp.per.4" + ], + "SAT-02": [ + "mp.per.3", + "mp.per.4" + ], + "SAT-03": [ + "mp.per.3", + "mp.per.4" + ], + "TDA-01": [ + "mp.sw.1" + ], + "TDA-02": [ + "mp.sw.1", + "mp.sw.2" + ], + "TDA-02.3": [ + "mp.sw.1", + "mp.sw.2" + ], + "TDA-06": [ + "mp.sw.1", + "mp.info.4", + "mp.s.2" + ], + "TDA-06.1": [ + "mp.sw.2" + ], + "TDA-07": [ + "mp.sw.1" + ], + "TDA-08": [ + "mp.sw.1" + ], + "TDA-09": [ + "mp.sw.1", + "mp.sw.2" + ], + "TDA-14": [ + "op.exp.5" + ], + "TPM-01": [ + "op.ext.1" + ], + "TPM-01.1": [ + "op.ext.1" + ], + "TPM-02": [ + "op.ext.1" + ], + "TPM-03": [ + "op.ext.1", + "op.ext.2", + "op.ext.3" + ], + "TPM-03.1": [ + "op.ext.2", + "op.ext.3" + ], + "TPM-03.2": [ + "op.ext.1" + ], + "TPM-03.3": [ + "op.ext.1", + "op.ext.2" + ], + "TPM-04": [ + "op.ext.1" + ], + "TPM-04.1": [ + "op.ext.1" + ], + "TPM-04.3": [ + "op.ext.1" + ], + "TPM-04.4": [ + "op.ext.3" + ], + "TPM-05": [ + "op.ext.1", + "op.ext.3", + "mp.com.2", + "mp.com.3" + ], + "TPM-05.1": [ + "op.ext.3" + ], + "TPM-05.4": [ + "org.4" + ], + "TPM-06": [ + "org.4", + "op.ext.1" + ], + "TPM-08": [ + "op.ext.1", + "op.ext.2", + "mp.com.2", + "mp.com.3" + ], + "TPM-09": [ + "op.ext.1" + ], + "TPM-10": [ + "op.ext.2" + ], + "TPM-11": [ + "op.ext.1" + ], + "THR-01": [ + "op.mon.3" + ], + "THR-02": [ + "op.mon.3" + ], + "THR-03": [ + "op.mon.3" + ], + "THR-03.1": [ + "op.mon.3" + ], + "WEB-02": [ + "op.ext.4", + "mp.com.4" + ] + } + }, + "framework_to_scf": { + "total_mappings": 70, + "mappings": { + "org.1": [ + "GOV-01", + "GOV-02", + "GOV-03", + "PRI-01", + "PRI-01.3" + ], + "org.2": [ + "GOV-01", + "GOV-02", + "GOV-03", + "PRI-01", + "PRI-01.3" + ], + "org.3": [ + "GOV-01", + "GOV-02", + "GOV-03", + "OPS-01", + "OPS-01.1", + "OPS-03" + ], + "op.mon.2": [ + "GOV-01.2", + "GOV-05", + "CPL-01", + "CPL-01.1", + "CPL-01.2", + "CPL-03" + ], + "org.4": [ + "GOV-04", + "HRS-03", + "HRS-04.1", + "TPM-05.4", + "TPM-06" + ], + "mp.info.2": [ + "GOV-10", + "AST-04.1", + "DCH-01", + "DCH-02" + ], + "op.cont.3": [ + "AST-01", + "AST-01.1", + "BCD-01", + "BCD-01.1", + "BCD-01.2", + "BCD-04", + "IRO-06", + "RSK-08" + ], + "op.pl.2": [ + "AST-01.1", + "AST-01.2", + "AST-02", + "AST-02.8", + "AST-03", + "AST-03.1", + "AST-04", + "DCH-01", + "DCH-02", + "PRI-05.5", + "PRM-05" + ], + "op.exp.1": [ + "AST-01.1", + "AST-01.2", + "AST-02", + "AST-02.8", + "AST-03", + "AST-03.1", + "AST-04", + "DCH-01", + "DCH-02", + "PRI-05.5", + "PRM-05" + ], + "op.exp.2": [ + "AST-02.9", + "CFG-01", + "CFG-01.1", + "CFG-02", + "CFG-02.1", + "CFG-03" + ], + "op.exp.3": [ + "AST-02.9", + "CFG-01", + "CFG-01.1", + "CFG-02", + "CFG-02.1", + "CFG-03" + ], + "op.ext.3": [ + "AST-03.2", + "IAO-01", + "IAO-02", + "IAO-02.2", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-04.4", + "TPM-05", + "TPM-05.1" + ], + "op.mon.1": [ + "AST-04", + "NET-01", + "NET-02", + "NET-03", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" + ], + "mp.com.1": [ + "AST-04", + "NET-01", + "NET-02", + "NET-03", + "NET-04", + "NET-04.1", + "NET-06", + "NET-08.1" + ], + "mp.eq.1": [ + "AST-06", + "END-01", + "PES-04" + ], + "mp.eq.2": [ + "AST-06", + "END-01", + "PES-04" + ], + "mp.eq.3": [ + "AST-06", + "AST-07", + "AST-12", + "END-01", + "END-02", + "IAC-22", + "MDM-01", + "MDM-02", + "MDM-05" + ], + "mp.eq.4": [ + "AST-06", + "AST-07", + "AST-12", + "END-01", + "END-02", + "IAC-22", + "MDM-01", + "MDM-02", + "MDM-05" + ], + "mp.si.3": [ + "AST-11", + "AST-12", + "DCH-01", + "DCH-03", + "DCH-06", + "DCH-07", + "DCH-07.2", + "DCH-08", + "DCH-10", + "DCH-10.1", + "DCH-12" + ], + "mp.si.4": [ + "AST-11", + "AST-12", + "DCH-01", + "DCH-03", + "DCH-06", + "DCH-07", + "DCH-07.2", + "DCH-08", + "DCH-10", + "DCH-10.1", + "DCH-12" + ], + "mp.si.5": [ + "AST-11", + "AST-12", + "DCH-01", + "DCH-03", + "DCH-06", + "DCH-07", + "DCH-07.2", + "DCH-08", + "DCH-10", + "DCH-10.1", + "DCH-12" + ], + "op.cont.1": [ + "BCD-01", + "BCD-01.1", + "BCD-01.2", + "BCD-04", + "IRO-05", + "IRO-06.1", + "IRO-11.2" + ], + "op.cont.2": [ + "BCD-01", + "BCD-01.1", + "BCD-01.2", + "BCD-04", + "IRO-05", + "IRO-06.1", + "IRO-11.2" + ], + "op.cont.4": [ + "BCD-08", + "BCD-09", + "BCD-11.7" + ], + "mp.info.6": [ + "BCD-11", + "BCD-11.1", + "BCD-11.2", + "BCD-11.4" + ], + "op.pl.4": [ + "CAP-01", + "CAP-03" + ], + "mp.s.4": [ + "CAP-01", + "CAP-03" + ], + "op.exp.5": [ + "CHG-01", + "CHG-02", + "CHG-02.2", + "PRM-07", + "TDA-14" + ], + "op.nub.1": [ + "CLD-01" + ], + "mp.info.4": [ + "CLD-04", + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-04", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-06" + ], + "mp.s.2": [ + "CLD-04", + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-04", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-06" + ], + "op.acc.6": [ + "CFG-02", + "END-01", + "END-02", + "END-09", + "SEA-17" + ], + "mp.sw.1": [ + "CFG-02", + "CFG-02.4", + "IAO-04", + "PRM-07", + "TDA-01", + "TDA-02", + "TDA-02.3", + "TDA-06", + "TDA-07", + "TDA-08", + "TDA-09" + ], + "op.exp.8": [ + "MON-01", + "MON-01.4", + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-03", + "MON-03.3", + "MON-06", + "MON-08" + ], + "op.mon.3": [ + "MON-11", + "MON-11.3", + "THR-01", + "THR-02", + "THR-03", + "THR-03.1" + ], + "op.exp.10": [ + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-09", + "CRY-09.3", + "CRY-09.4" + ], + "mp.si.2": [ + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-09", + "CRY-09.3", + "CRY-09.4" + ], + "mp.info.3": [ + "CRY-01", + "CRY-03", + "CRY-04", + "CRY-05", + "CRY-09", + "CRY-09.3", + "CRY-09.4" + ], + "mp.s.1": [ + "CRY-03", + "DCH-07", + "DCH-07.1", + "DCH-14", + "DCH-17", + "HRS-05", + "HRS-05.1", + "HRS-06", + "HRS-06.1", + "NET-01", + "NET-04", + "NET-04.1", + "NET-13", + "NET-18", + "PES-01" + ], + "mp.si.1": [ + "DCH-04" + ], + "op.exp.6": [ + "END-04", + "END-04.1" + ], + "op.pl.1": [ + "HRS-04", + "HRS-04.1" + ], + "mp.per.1": [ + "HRS-04", + "HRS-04.1" + ], + "op.acc.3": [ + "HRS-11", + "HRS-12" + ], + "op.acc.4": [ + "HRS-11", + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-10.11", + "IAC-15", + "IAC-15.1", + "IAC-15.2", + "IAC-16", + "IAC-16.1", + "IAC-17", + "IAC-19", + "IAC-20", + "IAC-20.1", + "IAC-20.2", + "IAC-20.3", + "IAC-21", + "IAC-21.3", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03" + ], + "op.acc.5": [ + "HRS-11", + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-07.2", + "IAC-10", + "IAC-10.11", + "IAC-15", + "IAC-15.1", + "IAC-15.2", + "IAC-16", + "IAC-16.1", + "IAC-17", + "IAC-19", + "IAC-20", + "IAC-20.1", + "IAC-20.2", + "IAC-20.3", + "IAC-21", + "IAC-21.3", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03" + ], + "op.acc.2": [ + "IAC-01", + "IAC-02", + "IAC-08", + "IAC-15", + "IAC-16", + "IAC-17", + "IAC-21", + "PES-01", + "PES-02", + "PES-02.1", + "PES-03", + "PES-04", + "PES-04.1" + ], + "op.acc.1": [ + "IAC-03", + "IAC-04", + "IAC-05", + "IAC-07", + "IAC-09", + "IAC-09.1", + "IAC-09.4", + "IAC-15", + "IAC-15.3", + "IAC-15.5" + ], + "op.exp.7": [ + "IRO-01", + "IRO-02", + "IRO-04", + "IRO-13" + ], + "op.exp.9": [ + "IRO-02", + "IRO-04", + "IRO-07", + "IRO-08" + ], + "mp.sw.2": [ + "IAO-02", + "IAO-02.2", + "TDA-02", + "TDA-02.3", + "TDA-06.1", + "TDA-09" + ], + "op.exp.4": [ + "MNT-01", + "MNT-02", + "MNT-03" + ], + "mp.com.2": [ + "NET-01", + "NET-03", + "NET-08", + "NET-15", + "TPM-05", + "TPM-08" + ], + "mp.com.3": [ + "NET-01", + "NET-03", + "NET-08", + "NET-15", + "TPM-05", + "TPM-08" + ], + "op.ext.4": [ + "NET-06", + "NET-06.1", + "WEB-02" + ], + "mp.com.4": [ + "NET-06", + "NET-06.1", + "WEB-02" + ], + "mp.s.3": [ + "NET-18" + ], + "mp.if.1": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1", + "PES-04" + ], + "mp.if.3": [ + "PES-01", + "PES-04", + "PES-12", + "RSK-01", + "RSK-04" + ], + "mp.if.5": [ + "PES-01", + "PES-04", + "PES-12", + "RSK-01", + "RSK-04" + ], + "mp.if.6": [ + "PES-01", + "PES-04", + "PES-12", + "RSK-01", + "RSK-04" + ], + "mp.if.2": [ + "PES-03.1", + "PES-03.3", + "PES-04.1", + "PES-06", + "PES-10" + ], + "mp.if.7": [ + "PES-03.1", + "PES-03.3", + "PES-04.1", + "PES-06", + "PES-10" + ], + "mp.if.4": [ + "PES-07", + "PES-07.1", + "PES-07.2", + "PES-07.3", + "PES-07.4" + ], + "mp.info.1": [ + "PRI-01", + "PRI-01.6", + "PRI-02", + "PRI-02.1" + ], + "op.pl.3": [ + "PRM-01", + "PRM-04", + "PRM-05", + "PRM-07", + "RSK-01.1", + "RSK-03", + "RSK-04", + "RSK-06", + "RSK-06.1", + "SEA-02" + ], + "mp.per.3": [ + "SAT-01", + "SAT-02", + "SAT-03" + ], + "mp.per.4": [ + "SAT-01", + "SAT-02", + "SAT-03" + ], + "op.ext.1": [ + "TPM-01", + "TPM-01.1", + "TPM-02", + "TPM-03", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-04.3", + "TPM-05", + "TPM-06", + "TPM-08", + "TPM-09", + "TPM-11" + ], + "op.ext.2": [ + "TPM-03", + "TPM-03.1", + "TPM-03.3", + "TPM-08", + "TPM-10" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-esp-decree-1720-2007.json b/docs/api/crosswalks/emea-esp-decree-1720-2007.json deleted file mode 100644 index f5da9370..00000000 --- a/docs/api/crosswalks/emea-esp-decree-1720-2007.json +++ /dev/null @@ -1,152 +0,0 @@ -{ - "framework_id": "emea-esp-decree-1720-2007", - "display_name": "Spain - Royal Decree 1720/2007", - "scf_to_framework": { - "total_mappings": 17, - "mappings": { - "DCH-22.1": [ - "23", - "24", - "31", - "32" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-02": [ - "8" - ], - "PRI-03": [ - "8", - "12" - ], - "PRI-04": [ - "8" - ], - "PRI-04.1": [ - "8" - ], - "PRI-05": [ - "8", - "22" - ], - "PRI-05.1": [ - "8" - ], - "PRI-05.2": [ - "8" - ], - "PRI-06": [ - "23", - "24", - "27", - "28", - "29" - ], - "PRI-06.1": [ - "23", - "24", - "31", - "32" - ], - "PRI-06.2": [ - "23", - "24", - "31", - "32" - ], - "PRI-06.3": [ - "23", - "24" - ], - "PRI-06.4": [ - "26" - ], - "PRI-15": [ - "60" - ], - "TPM-03": [ - "20", - "21" - ], - "TPM-05": [ - "20", - "21" - ] - } - }, - "framework_to_scf": { - "total_mappings": 16, - "mappings": { - "8": [ - "PRI-02", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-05.1", - "PRI-05.2" - ], - "12": [ - "PRI-03" - ], - "20": [ - "TPM-03", - "TPM-05" - ], - "21": [ - "TPM-03", - "TPM-05" - ], - "22": [ - "PRI-05" - ], - "23": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3" - ], - "24": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3" - ], - "26": [ - "PRI-06.4" - ], - "27": [ - "PRI-06" - ], - "28": [ - "PRI-06" - ], - "29": [ - "PRI-06" - ], - "31": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" - ], - "32": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2" - ], - "60": [ - "PRI-15" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-esp-decree-311-2022.json b/docs/api/crosswalks/emea-esp-decree-311-2022.json index 3d3f1217..5b5eebc0 100644 --- a/docs/api/crosswalks/emea-esp-decree-311-2022.json +++ b/docs/api/crosswalks/emea-esp-decree-311-2022.json @@ -2,822 +2,620 @@ "framework_id": "emea-esp-decree-311-2022", "display_name": "Spain - Royal Decree 311/2022", "scf_to_framework": { - "total_mappings": 73, + "total_mappings": 72, "mappings": { "GOV-01": [ - "13.1", - "35.1", - "5", - "6.1", - "6.2" + "Article 8(1)", + "Article 8(2)", + "Article 8(5)", + "Article 9(1)", + "Article 9(1)(a)", + "Article 9(1)(b)", + "Article 9(2)", + "Article 10(1)", + "Article 10(2)", + "Article 10(3)", + "Article 12(6)(a)" ], "GOV-01.1": [ - "27", - "5" + "Article 12(1)(d)" + ], + "GOV-01.2": [ + "Article 31(6)" + ], + "GOV-01.3": [ + "Article 12(6)(ñ)", + "Article 27" + ], + "GOV-01.4": [ + "Article 12(1)(b)" ], "GOV-02": [ - "12.1", - "12.1(a)", - "12.1(b)", - "12.1(c)", - "12.1(d)", - "12.1(e)", - "12.1(f)", - "12.2", - "12.6", - "12.6(a)", - "12.6(b)", - "12.6(c)", - "12.6(d)", - "12.6(e)", - "12.6(f)", - "12.6(g)", - "12.6(h)", - "12.6(i)", - "12.6(j)", - "12.6(k)", - "12.6(l)", - "12.6(m)", - "12.6(n)", - "12.6(ñ)", - "12.7" - ], - "GOV-03": [ - "27" - ], - "GOV-06": [ - "32.1", - "32.2", - "32.3" + "Article 11(3)", + "Article 12(1)", + "Article 12(6)" + ], + "GOV-04": [ + "Article 13(3)" + ], + "GOV-04.1": [ + "Article 11(2)", + "Article 13(3)" + ], + "GOV-08": [ + "Article 12(1)(a)" ], "GOV-15": [ - "28.1", - "37", - "5", - "5(a)", - "5(b)", - "5(c)", - "5(d)", - "5(e)", - "5(f)", - "5(g)", - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" + "Article 13(2)(d)", + "Article 15(1)" ], "GOV-15.1": [ - "28.1(a)", - "28.1(b)", - "28.1(c)", - "28.2", - "28.3", - "3.3", - "37" + "Article 28(2)" ], - "GOV-15.2": [ - "3.3", - "37" + "GOV-19.3": [ + "Article 14(1)", + "Article 16(2)" ], - "AST-01": [ - "18" + "AST-01.2": [ + "Article 11(1)", + "Article 11(2)" + ], + "AST-04.1": [ + "Article 40(1)", + "Article 40(2)" ], "BCD-01": [ - "26" + "Article 12(6)(n)", + "Article 22(2)" ], "BCD-11": [ - "26" + "Article 26" ], - "CHG-01": [ - "21.1" + "CPL-01": [ + "Article 37" ], - "CHG-02": [ - "21.1" + "CPL-01.3": [ + "Article 38(1)" ], - "CPL-01": [ - "3.1", - "39" + "CPL-01.4": [ + "Article 31(1)", + "Article 31(2)", + "Article 31(3)", + "Article 31(4)", + "Article 31(5)", + "Article 31(7)" ], - "CPL-01.2": [ - "38.2" + "CPL-01.5": [ + "Article 38(2)" ], "CPL-02": [ - "10.1", - "10.2", - "10.3" - ], - "CPL-02.1": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "41.1", - "41.2" + "Article 16(1)" ], "CPL-03": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7" - ], - "CPL-03.1": [ - "38.1" - ], - "CPL-03.2": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "38.1" - ], - "CFG-01": [ - "30.1", - "30.2" + "Article 15(1)" ], "CFG-02": [ - "20(d)" + "Article 12(7)", + "Article 20(a)", + "Article 20(c)", + "Article 20(d)", + "Single Transitional Provision(3)" ], "CFG-02.2": [ - "21.2" + "Article 21(2)" ], "CFG-03": [ - "20(a)", - "20(b)", - "20(c)", - "20(d)" - ], - "CFG-03.1": [ - "21.2" + "Article 20(c)" ], "MON-01": [ - "10.1", - "21.2", - "24.1" - ], - "MON-01.16": [ - "10.1", - "21.2", - "24.1" + "Article 8(3)", + "Article 12(6)(l)", + "Article 24(1)", + "Article 24(2)" ], "MON-03": [ - "24.1" + "Article 20(b)" ], - "MON-16": [ - "10.1" + "CRY-01": [ + "Article 12(6)(j)" ], "DCH-01": [ - "22.1", - "22.3" + "Article 22(3)" ], "DCH-01.2": [ - "22.1", - "22.3" + "Article 22(3)" ], "DCH-02": [ - "40.1", - "40.2", - "41.2" + "Article 40(1)" ], - "DCH-18.1": [ - "24.2" + "DCH-13": [ + "Article 22(1)" + ], + "DCH-13.2": [ + "Article 22(1)" + ], + "END-02": [ + "Article 23" ], "HRS-01": [ - "15.1" + "Article 12(6)(c)" ], "HRS-02": [ - "13.2" + "Article 16(3)" ], "HRS-03": [ - "11.1", - "11.2", - "11.3", - "13.1", - "13.2", - "13.2(a)", - "13.2(b)", - "13.2(c)", - "13.2(d)", - "13.3", - "13.4", - "13.5" - ], - "HRS-03.1": [ - "13.1", - "15.1" + "Article 12(1)(c)", + "Article 13(2)" ], "HRS-03.2": [ - "15.1", - "16.1", - "16.2", - "16.3" - ], - "HRS-04.2": [ - "13.2", - "15.1" + "Article 16(2)" ], "HRS-05": [ - "11.2", - "11.3" + "Article 12(6)(d)", + "Article 13(1)" ], "HRS-05.1": [ - "11.2", - "11.3" + "Article 15(2)" ], - "HRS-11": [ - "13.3" + "HRS-05.7": [ + "Article 13(2)" ], "IAC-01": [ - "18" - ], - "IAC-02": [ - "24.3" - ], - "IAC-03": [ - "24.3" + "Article 12(6)(e)", + "Article 24(3)" ], "IAC-08": [ - "17" + "Article 17" ], "IAC-21": [ - "17", - "20" + "Article 12(6)(h)", + "Article 20" ], "IRO-01": [ - "25.1" + "Article 8(4)", + "Article 12(6)(m)", + "Article 25(1)" ], "IRO-02": [ - "25.1", - "25.2", - "33.4" + "Article 25(2)", + "Article 34(1)(a)" ], - "IRO-02.4": [ - "33.4" + "IRO-10.5": [ + "Article 33(7)" ], - "IRO-04": [ - "25.1", - "25.2" + "IAO-01": [ + "Article 13(2)(c)", + "Article 21(1)" ], - "IRO-07": [ - "33.3" + "IAO-03": [ + "Article 12(1)(e)", + "Article 15(2)" ], - "IRO-09": [ - "25.2" + "IAO-07": [ + "Article 21(1)" ], - "IRO-10": [ - "25.2", - "33.2", - "33.4", - "33.7" + "MDM-01": [ + "Article 22(1)" ], "NET-01": [ - "23" + "Article 12(6)(k)", + "Article 18" + ], + "NET-05": [ + "Article 23" ], "PES-01": [ - "18" + "Article 12(6)(f)" ], - "PRM-07": [ - "36", - "8 (end)" + "PRI-01.6": [ + "Article 5(a)", + "Article 5(b)", + "Article 5(c)", + "Article 5(d)", + "Article 5(e)", + "Article 5(f)", + "Article 5(g)" ], - "RSK-01": [ - "7.1", - "7.2" + "PRM-04": [ + "Article 16(1)" ], - "RSK-03": [ - "3.2" + "PRM-05": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], - "RSK-04": [ - "14.1", - "14.2", - "3.2" + "PRM-06": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], - "RSK-06": [ - "14.2", - "14.3" + "RSK-01": [ + "Article 7(2)", + "Article 12(6)(b)" ], - "RSK-06.1": [ - "14.2", - "14.3" + "RSK-01.1": [ + "Article 14(2)" ], - "SEA-01": [ - "29" + "RSK-04": [ + "Article 14(2)" ], - "SEA-02": [ - "29" + "RSK-06": [ + "Article 3(3)" ], - "SEA-02.1": [ - "4" + "RSK-06.2": [ + "Article 28(3)" ], - "SEA-03": [ - "29" + "RSK-06.4": [ + "Article 14(3)" ], - "SEA-07.1": [ - "36" + "RSK-10": [ + "Article 3(2)", + "Article 12(1)(f)" ], - "OPS-01": [ - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" + "RSK-11": [ + "Article 14(1)" ], - "OPS-01.1": [ - "13.2(d)", - "13.4", - "22.2" + "SEA-02.2": [ + "Article 14(1)" ], - "SAT-01": [ - "6.2" + "SAT-03": [ + "Article 6(2)", + "Article 15(1)", + "Article 16(3)" ], "TDA-01": [ - "19.1", - "19.2", - "19.2(a)", - "19.2(b)", - "19.2(c)", - "19.3" - ], - "TPM-04": [ - "13.5" + "Article 12(6)(g)", + "Article 19(1)" ], "TPM-05.4": [ - "13.2", - "13.5" + "Article 11(2)", + "Article 13(3)", + "Article 13(5)" + ], + "TPM-06": [ + "Article 13(5)" + ], + "VPM-01": [ + "Article 12(6)(i)" ] } }, "framework_to_scf": { - "total_mappings": 128, + "total_mappings": 104, "mappings": { - "4": [ - "SEA-02.1" - ], - "5": [ - "GOV-01", - "GOV-01.1", - "GOV-15" - ], - "17": [ - "IAC-08", - "IAC-21" - ], - "18": [ - "AST-01", - "IAC-01", - "PES-01" - ], - "20": [ - "IAC-21" - ], - "23": [ - "NET-01" - ], - "26": [ - "BCD-01", - "BCD-11" - ], - "27": [ - "GOV-01.1", - "GOV-03" - ], - "29": [ - "SEA-01", - "SEA-02", - "SEA-03" - ], - "36": [ - "PRM-07", - "SEA-07.1" - ], - "37": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2" - ], - "39": [ - "CPL-01" - ], - "13.1": [ - "GOV-01", - "HRS-03", - "HRS-03.1" - ], - "35.1": [ + "Article 8(1)": [ "GOV-01" ], - "6.1": [ + "Article 8(2)": [ "GOV-01" ], - "6.2": [ - "GOV-01", - "SAT-01" - ], - "12.1": [ - "GOV-02" - ], - "12.1(a)": [ - "GOV-02" - ], - "12.1(b)": [ - "GOV-02" - ], - "12.1(c)": [ - "GOV-02" - ], - "12.1(d)": [ - "GOV-02" - ], - "12.1(e)": [ - "GOV-02" - ], - "12.1(f)": [ - "GOV-02" - ], - "12.2": [ - "GOV-02" - ], - "12.6": [ - "GOV-02" + "Article 8(5)": [ + "GOV-01" ], - "12.6(a)": [ - "GOV-02" + "Article 9(1)": [ + "GOV-01" ], - "12.6(b)": [ - "GOV-02" + "Article 9(1)(a)": [ + "GOV-01" ], - "12.6(c)": [ - "GOV-02" + "Article 9(1)(b)": [ + "GOV-01" ], - "12.6(d)": [ - "GOV-02" + "Article 9(2)": [ + "GOV-01" ], - "12.6(e)": [ - "GOV-02" + "Article 10(1)": [ + "GOV-01" ], - "12.6(f)": [ - "GOV-02" + "Article 10(2)": [ + "GOV-01" ], - "12.6(g)": [ - "GOV-02" + "Article 10(3)": [ + "GOV-01" ], - "12.6(h)": [ - "GOV-02" + "Article 12(6)(a)": [ + "GOV-01" ], - "12.6(i)": [ - "GOV-02" + "Article 12(1)(d)": [ + "GOV-01.1" ], - "12.6(j)": [ - "GOV-02" + "Article 31(6)": [ + "GOV-01.2" ], - "12.6(k)": [ - "GOV-02" + "Article 12(6)(ñ)": [ + "GOV-01.3" ], - "12.6(l)": [ - "GOV-02" + "Article 27": [ + "GOV-01.3" ], - "12.6(m)": [ - "GOV-02" + "Article 12(1)(b)": [ + "GOV-01.4" ], - "12.6(n)": [ + "Article 11(3)": [ "GOV-02" ], - "12.6(ñ)": [ + "Article 12(1)": [ "GOV-02" ], - "12.7": [ + "Article 12(6)": [ "GOV-02" ], - "32.1": [ - "GOV-06" - ], - "32.2": [ - "GOV-06" - ], - "32.3": [ - "GOV-06" + "Article 13(3)": [ + "GOV-04", + "GOV-04.1", + "TPM-05.4" ], - "28.1": [ - "GOV-15" + "Article 11(2)": [ + "GOV-04.1", + "AST-01.2", + "TPM-05.4" ], - "5(a)": [ - "GOV-15" + "Article 12(1)(a)": [ + "GOV-08" ], - "5(b)": [ + "Article 13(2)(d)": [ "GOV-15" ], - "5(c)": [ - "GOV-15" + "Article 15(1)": [ + "GOV-15", + "CPL-03", + "SAT-03" ], - "5(d)": [ - "GOV-15" + "Article 28(2)": [ + "GOV-15.1" ], - "5(e)": [ - "GOV-15" + "Article 14(1)": [ + "GOV-19.3", + "RSK-11", + "SEA-02.2" ], - "5(f)": [ - "GOV-15" + "Article 16(2)": [ + "GOV-19.3", + "HRS-03.2" ], - "5(g)": [ - "GOV-15" + "Article 11(1)": [ + "AST-01.2" ], - "8.1": [ - "GOV-15", - "OPS-01" + "Article 40(1)": [ + "AST-04.1", + "DCH-02" ], - "8.2": [ - "GOV-15", - "OPS-01" + "Article 40(2)": [ + "AST-04.1" ], - "8.3": [ - "GOV-15", - "OPS-01" + "Article 12(6)(n)": [ + "BCD-01" ], - "8.4": [ - "GOV-15", - "OPS-01" + "Article 22(2)": [ + "BCD-01" ], - "8.5": [ - "GOV-15", - "OPS-01" + "Article 26": [ + "BCD-11" ], - "28.1(a)": [ - "GOV-15.1" + "Article 37": [ + "CPL-01" ], - "28.1(b)": [ - "GOV-15.1" + "Article 38(1)": [ + "CPL-01.3" ], - "28.1(c)": [ - "GOV-15.1" + "Article 31(1)": [ + "CPL-01.4" ], - "28.2": [ - "GOV-15.1" + "Article 31(2)": [ + "CPL-01.4" ], - "28.3": [ - "GOV-15.1" + "Article 31(3)": [ + "CPL-01.4" ], - "3.3": [ - "GOV-15.1", - "GOV-15.2" + "Article 31(4)": [ + "CPL-01.4" ], - "21.1": [ - "CHG-01", - "CHG-02" + "Article 31(5)": [ + "CPL-01.4" ], - "3.1": [ - "CPL-01" + "Article 31(7)": [ + "CPL-01.4" ], - "38.2": [ - "CPL-01.2" + "Article 38(2)": [ + "CPL-01.5" ], - "10.1": [ + "Article 16(1)": [ "CPL-02", - "MON-01", - "MON-01.16", - "MON-16" + "PRM-04" ], - "10.2": [ - "CPL-02" + "Article 12(7)": [ + "CFG-02" ], - "10.3": [ - "CPL-02" + "Article 20(a)": [ + "CFG-02" ], - "31.1": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "Article 20(c)": [ + "CFG-02", + "CFG-03" ], - "31.2": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "Article 20(d)": [ + "CFG-02" ], - "31.3": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "Single Transitional Provision(3)": [ + "CFG-02" ], - "31.4": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "Article 21(2)": [ + "CFG-02.2" ], - "31.5": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "Article 8(3)": [ + "MON-01" ], - "31.6": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "Article 12(6)(l)": [ + "MON-01" ], - "31.7": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" + "Article 24(1)": [ + "MON-01" ], - "41.1": [ - "CPL-02.1" + "Article 24(2)": [ + "MON-01" ], - "41.2": [ - "CPL-02.1", - "DCH-02" + "Article 20(b)": [ + "MON-03" ], - "38.1": [ - "CPL-03.1", - "CPL-03.2" + "Article 12(6)(j)": [ + "CRY-01" ], - "30.1": [ - "CFG-01" + "Article 22(3)": [ + "DCH-01", + "DCH-01.2" ], - "30.2": [ - "CFG-01" + "Article 22(1)": [ + "DCH-13", + "DCH-13.2", + "MDM-01" ], - "20(d)": [ - "CFG-02", - "CFG-03" + "Article 23": [ + "END-02", + "NET-05" ], - "21.2": [ - "CFG-02.2", - "CFG-03.1", - "MON-01", - "MON-01.16" + "Article 12(6)(c)": [ + "HRS-01" ], - "20(a)": [ - "CFG-03" + "Article 16(3)": [ + "HRS-02", + "SAT-03" ], - "20(b)": [ - "CFG-03" + "Article 12(1)(c)": [ + "HRS-03" ], - "20(c)": [ - "CFG-03" + "Article 13(2)": [ + "HRS-03", + "HRS-05.7" ], - "24.1": [ - "MON-01", - "MON-01.16", - "MON-03" + "Article 12(6)(d)": [ + "HRS-05" ], - "22.1": [ - "DCH-01", - "DCH-01.2" + "Article 13(1)": [ + "HRS-05" ], - "22.3": [ - "DCH-01", - "DCH-01.2" + "Article 15(2)": [ + "HRS-05.1", + "IAO-03" ], - "40.1": [ - "DCH-02" + "Article 12(6)(e)": [ + "IAC-01" ], - "40.2": [ - "DCH-02" + "Article 24(3)": [ + "IAC-01" ], - "24.2": [ - "DCH-18.1" + "Article 17": [ + "IAC-08" ], - "15.1": [ - "HRS-01", - "HRS-03.1", - "HRS-03.2", - "HRS-04.2" + "Article 12(6)(h)": [ + "IAC-21" ], - "13.2": [ - "HRS-02", - "HRS-03", - "HRS-04.2", - "TPM-05.4" + "Article 20": [ + "IAC-21" ], - "11.1": [ - "HRS-03" + "Article 8(4)": [ + "IRO-01" ], - "11.2": [ - "HRS-03", - "HRS-05", - "HRS-05.1" + "Article 12(6)(m)": [ + "IRO-01" ], - "11.3": [ - "HRS-03", - "HRS-05", - "HRS-05.1" + "Article 25(1)": [ + "IRO-01" ], - "13.2(a)": [ - "HRS-03" + "Article 25(2)": [ + "IRO-02" ], - "13.2(b)": [ - "HRS-03" + "Article 34(1)(a)": [ + "IRO-02" ], - "13.2(c)": [ - "HRS-03" + "Article 33(7)": [ + "IRO-10.5" ], - "13.2(d)": [ - "HRS-03", - "OPS-01.1" + "Article 13(2)(c)": [ + "IAO-01" ], - "13.3": [ - "HRS-03", - "HRS-11" + "Article 21(1)": [ + "IAO-01", + "IAO-07" ], - "13.4": [ - "HRS-03", - "OPS-01.1" + "Article 12(1)(e)": [ + "IAO-03" ], - "13.5": [ - "HRS-03", - "TPM-04", - "TPM-05.4" + "Article 12(6)(k)": [ + "NET-01" ], - "16.1": [ - "HRS-03.2" + "Article 18": [ + "NET-01" ], - "16.2": [ - "HRS-03.2" + "Article 12(6)(f)": [ + "PES-01" ], - "16.3": [ - "HRS-03.2" + "Article 5(a)": [ + "PRI-01.6" ], - "24.3": [ - "IAC-02", - "IAC-03" + "Article 5(b)": [ + "PRI-01.6" ], - "25.1": [ - "IRO-01", - "IRO-02", - "IRO-04" + "Article 5(c)": [ + "PRI-01.6" ], - "25.2": [ - "IRO-02", - "IRO-04", - "IRO-09", - "IRO-10" + "Article 5(d)": [ + "PRI-01.6" ], - "33.4": [ - "IRO-02", - "IRO-02.4", - "IRO-10" + "Article 5(e)": [ + "PRI-01.6" ], - "33.3": [ - "IRO-07" + "Article 5(f)": [ + "PRI-01.6" ], - "33.2": [ - "IRO-10" + "Article 5(g)": [ + "PRI-01.6" ], - "33.7": [ - "IRO-10" + "Article 13(2)(a)": [ + "PRM-05", + "PRM-06" ], - "8 (end)": [ - "PRM-07" + "Article 13(2)(b)": [ + "PRM-05", + "PRM-06" ], - "7.1": [ + "Article 7(2)": [ "RSK-01" ], - "7.2": [ + "Article 12(6)(b)": [ "RSK-01" ], - "3.2": [ - "RSK-03", + "Article 14(2)": [ + "RSK-01.1", "RSK-04" ], - "14.1": [ - "RSK-04" + "Article 3(3)": [ + "RSK-06" ], - "14.2": [ - "RSK-04", - "RSK-06", - "RSK-06.1" + "Article 28(3)": [ + "RSK-06.2" ], - "14.3": [ - "RSK-06", - "RSK-06.1" + "Article 14(3)": [ + "RSK-06.4" ], - "22.2": [ - "OPS-01.1" + "Article 3(2)": [ + "RSK-10" ], - "19.1": [ - "TDA-01" + "Article 12(1)(f)": [ + "RSK-10" ], - "19.2": [ - "TDA-01" + "Article 6(2)": [ + "SAT-03" ], - "19.2(a)": [ + "Article 12(6)(g)": [ "TDA-01" ], - "19.2(b)": [ + "Article 19(1)": [ "TDA-01" ], - "19.2(c)": [ - "TDA-01" + "Article 13(5)": [ + "TPM-05.4", + "TPM-06" ], - "19.3": [ - "TDA-01" + "Article 12(6)(i)": [ + "VPM-01" ] } } diff --git a/docs/api/crosswalks/emea-eu-ai-act-2024.json b/docs/api/crosswalks/emea-eu-ai-act-2024.json index 6aa69287..10e252ac 100644 --- a/docs/api/crosswalks/emea-eu-ai-act-2024.json +++ b/docs/api/crosswalks/emea-eu-ai-act-2024.json @@ -1,6 +1,6 @@ { "framework_id": "emea-eu-ai-act-2024", - "display_name": "EU Artificial Intelligence Act (AI Act) (2024)", + "display_name": "EU - European Union Artificial Intelligence Act (Regulation (EU) 2024/1689)", "scf_to_framework": { "total_mappings": 119, "mappings": { diff --git a/docs/api/crosswalks/emea-eu-cyber-resilience-act-2022.json b/docs/api/crosswalks/emea-eu-cyber-resilience-act-2022.json deleted file mode 100644 index c1dab0e5..00000000 --- a/docs/api/crosswalks/emea-eu-cyber-resilience-act-2022.json +++ /dev/null @@ -1,274 +0,0 @@ -{ - "framework_id": "emea-eu-cyber-resilience-act-2022", - "display_name": "EU Cyber Resilience Act (CRA) (2022)", - "scf_to_framework": { - "total_mappings": 18, - "mappings": { - "CPL-01.3": [ - "Article 10.13" - ], - "CPL-01.4": [ - "Article 10.2", - "Article 10.7", - "Article 13.2(a)", - "Article 24.1", - "Article 24.1(a)", - "Article 24.1(b)", - "Article 24.1(c)" - ], - "CPL-02.3": [ - "Article 10.12", - "Article 13.6", - "Article 14.4" - ], - "CPL-03.3": [ - "Article 13.8", - "Article 14.5" - ], - "CPL-08": [ - "Article 12.1" - ], - "CPL-08.1": [ - "Article 12.3", - "Article 12.3(a)", - "Article 12.3(b)", - "Article 12.3(c)" - ], - "DCH-18": [ - "Article 10.8", - "Article 13.7" - ], - "IRO-10.5": [ - "Article 11.2", - "Article 11.4" - ], - "SEA-02.1": [ - "Article 3" - ], - "TDA-01.1": [ - "Article 5", - "Article 5.1", - "Article 5.2", - "Article 10.1", - "Article 10.5", - "Article 10.6", - "Article 10.9", - "Article 10.10", - "Article 10.11", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.3", - "Article 13.4", - "Article 13.5", - "Article 13.6", - "Article 14.1", - "Article 14.2", - "Article 14.2(a)", - "Article 14.2(b)", - "Article 14.3", - "Article 14.4" - ], - "TDA-02.9": [ - "Article 10.6" - ], - "TDA-02.11": [ - "Article 11.7" - ], - "TDA-02.13": [ - "Article 11.1" - ], - "TDA-04.2": [ - "Article 11.7" - ], - "TDA-21": [ - "Article 10.12" - ], - "TDA-22": [ - "Article 10.7", - "Article 13.2(b)", - "Article 23.1", - "Article 23.2", - "Article 23.3", - "Article 23.4" - ], - "TDA-22.1": [ - "Article 10.3" - ], - "TPM-03": [ - "Article 10.4" - ] - } - }, - "framework_to_scf": { - "total_mappings": 52, - "mappings": { - "Article 10.13": [ - "CPL-01.3" - ], - "Article 10.2": [ - "CPL-01.4" - ], - "Article 10.7": [ - "CPL-01.4", - "TDA-22" - ], - "Article 13.2(a)": [ - "CPL-01.4", - "TDA-01.1" - ], - "Article 24.1": [ - "CPL-01.4" - ], - "Article 24.1(a)": [ - "CPL-01.4" - ], - "Article 24.1(b)": [ - "CPL-01.4" - ], - "Article 24.1(c)": [ - "CPL-01.4" - ], - "Article 10.12": [ - "CPL-02.3", - "TDA-21" - ], - "Article 13.6": [ - "CPL-02.3", - "TDA-01.1" - ], - "Article 14.4": [ - "CPL-02.3", - "TDA-01.1" - ], - "Article 13.8": [ - "CPL-03.3" - ], - "Article 14.5": [ - "CPL-03.3" - ], - "Article 12.1": [ - "CPL-08" - ], - "Article 12.3": [ - "CPL-08.1" - ], - "Article 12.3(a)": [ - "CPL-08.1" - ], - "Article 12.3(b)": [ - "CPL-08.1" - ], - "Article 12.3(c)": [ - "CPL-08.1" - ], - "Article 10.8": [ - "DCH-18" - ], - "Article 13.7": [ - "DCH-18" - ], - "Article 11.2": [ - "IRO-10.5" - ], - "Article 11.4": [ - "IRO-10.5" - ], - "Article 3": [ - "SEA-02.1" - ], - "Article 5": [ - "TDA-01.1" - ], - "Article 5.1": [ - "TDA-01.1" - ], - "Article 5.2": [ - "TDA-01.1" - ], - "Article 10.1": [ - "TDA-01.1" - ], - "Article 10.5": [ - "TDA-01.1" - ], - "Article 10.6": [ - "TDA-01.1", - "TDA-02.9" - ], - "Article 10.9": [ - "TDA-01.1" - ], - "Article 10.10": [ - "TDA-01.1" - ], - "Article 10.11": [ - "TDA-01.1" - ], - "Article 13.1": [ - "TDA-01.1" - ], - "Article 13.2": [ - "TDA-01.1" - ], - "Article 13.2(b)": [ - "TDA-01.1", - "TDA-22" - ], - "Article 13.2(c)": [ - "TDA-01.1" - ], - "Article 13.3": [ - "TDA-01.1" - ], - "Article 13.4": [ - "TDA-01.1" - ], - "Article 13.5": [ - "TDA-01.1" - ], - "Article 14.1": [ - "TDA-01.1" - ], - "Article 14.2": [ - "TDA-01.1" - ], - "Article 14.2(a)": [ - "TDA-01.1" - ], - "Article 14.2(b)": [ - "TDA-01.1" - ], - "Article 14.3": [ - "TDA-01.1" - ], - "Article 11.7": [ - "TDA-02.11", - "TDA-04.2" - ], - "Article 11.1": [ - "TDA-02.13" - ], - "Article 23.1": [ - "TDA-22" - ], - "Article 23.2": [ - "TDA-22" - ], - "Article 23.3": [ - "TDA-22" - ], - "Article 23.4": [ - "TDA-22" - ], - "Article 10.3": [ - "TDA-22.1" - ], - "Article 10.4": [ - "TPM-03" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-eu-cyber-resilience-act-2024.json b/docs/api/crosswalks/emea-eu-cyber-resilience-act-2024.json new file mode 100644 index 00000000..2ee6b57c --- /dev/null +++ b/docs/api/crosswalks/emea-eu-cyber-resilience-act-2024.json @@ -0,0 +1,534 @@ +{ + "framework_id": "emea-eu-cyber-resilience-act-2024", + "display_name": "EU - European Union Cyber Resilience Act (2024)", + "scf_to_framework": { + "total_mappings": 35, + "mappings": { + "GOV-17": [ + "Article 13(23)", + "Article 19(8)", + "Article 20(6)" + ], + "AAT-09.1": [ + "Article 12(1)" + ], + "CPL-01": [ + "Article 6", + "Article 6(a)", + "Article 6(b)", + "Article 12(1)(a)", + "Article 12(1)(b)", + "Article 19(7)", + "Article 23(1)", + "Article 23(1)(a)", + "Article 23(1)(b)", + "Article 24(2)" + ], + "CPL-01.3": [ + "Article 13(1)", + "Article 32(5)" + ], + "CPL-01.4": [ + "Article 12(3)", + "Article 13(12)", + "Article 19(2)(a)", + "Article 32(1)", + "Article 32(1)(a)", + "Article 32(1)(b)", + "Article 32(1)(c)", + "Article 32(1)(d)", + "Article 32(3)", + "Article 32(3)(a)", + "Article 32(3)(b)", + "Article 32(6)" + ], + "CPL-01.5": [ + "Article 12(1)(c)", + "Article 20(5)" + ], + "CPL-01.7": [ + "Article 18(1)" + ], + "CPL-05.2": [ + "Article 53" + ], + "CPL-07": [ + "Article 13(17)" + ], + "DCH-18": [ + "Article 13(13)", + "Article 19(6)", + "Article 23(2)" + ], + "IRO-02.4": [ + "Article 14(5)", + "Article 14(5)(a)", + "Article 14(5)(b)" + ], + "IRO-10": [ + "Article 14(8)", + "Article 15(1)", + "Article 15(2)" + ], + "IRO-10.2": [ + "Article 14(1)", + "Article 14(3)", + "Article 14(4)(a)", + "Article 14(4)(b)", + "Article 14(4)(c)", + "Article 14(4)(i)", + "Article 14(4)(i)(ii)", + "Article 14(4)(i)(iii)" + ], + "IAO-01": [ + "Article 13(2)" + ], + "IAO-01.1": [ + "Article 13(2)" + ], + "IAO-02": [ + "Article 13(2)", + "Article 32(1)" + ], + "IAO-02.1": [ + "Article 13(2)" + ], + "IAO-02.2": [ + "Article 13(2)", + "Article 13(3)", + "Article 32(1)" + ], + "IAO-02.4": [ + "Article 13(2)" + ], + "IAO-03": [ + "Article 13(2)", + "Article 13(3)", + "Article 13(7)", + "Article 19(2)(b)", + "Article 31(1)", + "Article 31(2)", + "Article 31(3)" + ], + "IAO-03.2": [ + "Article 24(1)" + ], + "IAO-04": [ + "Article 13(6)", + "Article 13(21)" + ], + "IAO-05": [ + "Article 13(2)" + ], + "IAO-06": [ + "Article 13(2)" + ], + "IAO-07": [ + "Article 13(2)" + ], + "PRM-04": [ + "Article 13(14)" + ], + "PRM-07": [ + "Article 13(14)" + ], + "TDA-01.1": [ + "Article 13(1)", + "Article 13(5)", + "Article 13(8)", + "Article 13(10)", + "Article 13(11)", + "Article 13(13)", + "Article 13(14)", + "Article 13(15)", + "Article 13(16)", + "Article 13(17)", + "Article 13(18)", + "Article 13(19)", + "Article 13(20)", + "Article 13(21)", + "Article 13(22)", + "Article 13(23)", + "Article 19(1)", + "Article 19(2)", + "Article 19(2)(c)", + "Article 19(2)(d)", + "Article 19(3)", + "Article 19(4)", + "Article 19(5)", + "Article 19(6)", + "Article 20(1)", + "Article 20(2)", + "Article 20(2)(a)", + "Article 20(2)(b)", + "Article 20(3)", + "Article 20(4)", + "Article 24(1)", + "Article 30(1)", + "Article 30(2)", + "Article 30(3)", + "Article 30(4)" + ], + "TDA-02": [ + "Article 24(1)" + ], + "TDA-02.9": [ + "Article 13(8)", + "Article 13(9)", + "Article 13(11)" + ], + "TDA-02.11": [ + "Article 14(1)", + "Article 14(2)(a)", + "Article 14(2)(b)", + "Article 14(2)(c)", + "Article 14(2)(i)", + "Article 14(2)(i)(ii)", + "Article 14(2)(i)(iii)", + "Article 20(3)", + "Article 20(4)" + ], + "TDA-04": [ + "Article 13(4)", + "Article 13(7)", + "Article 31(1)" + ], + "TDA-04.1": [ + "Article 13(7)", + "Article 31(1)" + ], + "TDA-06": [ + "Article 24(1)" + ], + "VPM-02": [ + "Article 13(6)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 96, + "mappings": { + "Article 13(23)": [ + "GOV-17", + "TDA-01.1" + ], + "Article 19(8)": [ + "GOV-17" + ], + "Article 20(6)": [ + "GOV-17" + ], + "Article 12(1)": [ + "AAT-09.1" + ], + "Article 6": [ + "CPL-01" + ], + "Article 6(a)": [ + "CPL-01" + ], + "Article 6(b)": [ + "CPL-01" + ], + "Article 12(1)(a)": [ + "CPL-01" + ], + "Article 12(1)(b)": [ + "CPL-01" + ], + "Article 19(7)": [ + "CPL-01" + ], + "Article 23(1)": [ + "CPL-01" + ], + "Article 23(1)(a)": [ + "CPL-01" + ], + "Article 23(1)(b)": [ + "CPL-01" + ], + "Article 24(2)": [ + "CPL-01" + ], + "Article 13(1)": [ + "CPL-01.3", + "TDA-01.1" + ], + "Article 32(5)": [ + "CPL-01.3" + ], + "Article 12(3)": [ + "CPL-01.4" + ], + "Article 13(12)": [ + "CPL-01.4" + ], + "Article 19(2)(a)": [ + "CPL-01.4" + ], + "Article 32(1)": [ + "CPL-01.4", + "IAO-02", + "IAO-02.2" + ], + "Article 32(1)(a)": [ + "CPL-01.4" + ], + "Article 32(1)(b)": [ + "CPL-01.4" + ], + "Article 32(1)(c)": [ + "CPL-01.4" + ], + "Article 32(1)(d)": [ + "CPL-01.4" + ], + "Article 32(3)": [ + "CPL-01.4" + ], + "Article 32(3)(a)": [ + "CPL-01.4" + ], + "Article 32(3)(b)": [ + "CPL-01.4" + ], + "Article 32(6)": [ + "CPL-01.4" + ], + "Article 12(1)(c)": [ + "CPL-01.5" + ], + "Article 20(5)": [ + "CPL-01.5" + ], + "Article 18(1)": [ + "CPL-01.7" + ], + "Article 53": [ + "CPL-05.2" + ], + "Article 13(17)": [ + "CPL-07", + "TDA-01.1" + ], + "Article 13(13)": [ + "DCH-18", + "TDA-01.1" + ], + "Article 19(6)": [ + "DCH-18", + "TDA-01.1" + ], + "Article 23(2)": [ + "DCH-18" + ], + "Article 14(5)": [ + "IRO-02.4" + ], + "Article 14(5)(a)": [ + "IRO-02.4" + ], + "Article 14(5)(b)": [ + "IRO-02.4" + ], + "Article 14(8)": [ + "IRO-10" + ], + "Article 15(1)": [ + "IRO-10" + ], + "Article 15(2)": [ + "IRO-10" + ], + "Article 14(1)": [ + "IRO-10.2", + "TDA-02.11" + ], + "Article 14(3)": [ + "IRO-10.2" + ], + "Article 14(4)(a)": [ + "IRO-10.2" + ], + "Article 14(4)(b)": [ + "IRO-10.2" + ], + "Article 14(4)(c)": [ + "IRO-10.2" + ], + "Article 14(4)(i)": [ + "IRO-10.2" + ], + "Article 14(4)(i)(ii)": [ + "IRO-10.2" + ], + "Article 14(4)(i)(iii)": [ + "IRO-10.2" + ], + "Article 13(2)": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-05", + "IAO-06", + "IAO-07" + ], + "Article 13(3)": [ + "IAO-02.2", + "IAO-03" + ], + "Article 13(7)": [ + "IAO-03", + "TDA-04", + "TDA-04.1" + ], + "Article 19(2)(b)": [ + "IAO-03" + ], + "Article 31(1)": [ + "IAO-03", + "TDA-04", + "TDA-04.1" + ], + "Article 31(2)": [ + "IAO-03" + ], + "Article 31(3)": [ + "IAO-03" + ], + "Article 24(1)": [ + "IAO-03.2", + "TDA-01.1", + "TDA-02", + "TDA-06" + ], + "Article 13(6)": [ + "IAO-04", + "VPM-02" + ], + "Article 13(21)": [ + "IAO-04", + "TDA-01.1" + ], + "Article 13(14)": [ + "PRM-04", + "PRM-07", + "TDA-01.1" + ], + "Article 13(5)": [ + "TDA-01.1" + ], + "Article 13(8)": [ + "TDA-01.1", + "TDA-02.9" + ], + "Article 13(10)": [ + "TDA-01.1" + ], + "Article 13(11)": [ + "TDA-01.1", + "TDA-02.9" + ], + "Article 13(15)": [ + "TDA-01.1" + ], + "Article 13(16)": [ + "TDA-01.1" + ], + "Article 13(18)": [ + "TDA-01.1" + ], + "Article 13(19)": [ + "TDA-01.1" + ], + "Article 13(20)": [ + "TDA-01.1" + ], + "Article 13(22)": [ + "TDA-01.1" + ], + "Article 19(1)": [ + "TDA-01.1" + ], + "Article 19(2)": [ + "TDA-01.1" + ], + "Article 19(2)(c)": [ + "TDA-01.1" + ], + "Article 19(2)(d)": [ + "TDA-01.1" + ], + "Article 19(3)": [ + "TDA-01.1" + ], + "Article 19(4)": [ + "TDA-01.1" + ], + "Article 19(5)": [ + "TDA-01.1" + ], + "Article 20(1)": [ + "TDA-01.1" + ], + "Article 20(2)": [ + "TDA-01.1" + ], + "Article 20(2)(a)": [ + "TDA-01.1" + ], + "Article 20(2)(b)": [ + "TDA-01.1" + ], + "Article 20(3)": [ + "TDA-01.1", + "TDA-02.11" + ], + "Article 20(4)": [ + "TDA-01.1", + "TDA-02.11" + ], + "Article 30(1)": [ + "TDA-01.1" + ], + "Article 30(2)": [ + "TDA-01.1" + ], + "Article 30(3)": [ + "TDA-01.1" + ], + "Article 30(4)": [ + "TDA-01.1" + ], + "Article 13(9)": [ + "TDA-02.9" + ], + "Article 14(2)(a)": [ + "TDA-02.11" + ], + "Article 14(2)(b)": [ + "TDA-02.11" + ], + "Article 14(2)(c)": [ + "TDA-02.11" + ], + "Article 14(2)(i)": [ + "TDA-02.11" + ], + "Article 14(2)(i)(ii)": [ + "TDA-02.11" + ], + "Article 14(2)(i)(iii)": [ + "TDA-02.11" + ], + "Article 13(4)": [ + "TDA-04" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-eu-cyber-resilience-act-annex-i-2024.json b/docs/api/crosswalks/emea-eu-cyber-resilience-act-annex-i-2024.json new file mode 100644 index 00000000..9263dd26 --- /dev/null +++ b/docs/api/crosswalks/emea-eu-cyber-resilience-act-annex-i-2024.json @@ -0,0 +1,186 @@ +{ + "framework_id": "emea-eu-cyber-resilience-act-annex-i-2024", + "display_name": "EU - European Union Cyber Resilience Act - Annex I (2024)", + "scf_to_framework": { + "total_mappings": 16, + "mappings": { + "CPL-01": [ + "Annex I, Part II" + ], + "IAO-01": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], + "IAO-02.2": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], + "IAO-04": [ + "Annex I, Part II(2)", + "Annex I, Part II(3)" + ], + "PRI-01.11": [ + "Annex I, Part I(2)(g)" + ], + "TDA-01.1": [ + "Annex I, Part I(1)", + "Annex I, Part I(2)(g)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)", + "Annex I, Part I(2)(m)", + "Annex I, Part II(1)", + "Annex I, Part II(2)" + ], + "TDA-01.3": [ + "Annex I, Part I(2)(a)" + ], + "TDA-02": [ + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" + ], + "TDA-02.4": [ + "Annex I, Part I(2)(b)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" + ], + "TDA-02.8": [ + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(d)" + ], + "TDA-02.9": [ + "Annex I, Part I(2)(c)", + "Annex I, Part I(2)(l)", + "Annex I, Part II(2)", + "Annex I, Part II(3)", + "Annex I, Part II(4)", + "Annex I, Part II(5)", + "Annex I, Part II(6)", + "Annex I, Part II(7)", + "Annex I, Part II(8)" + ], + "TDA-02.11": [ + "Annex I, Part II(5)", + "Annex I, Part II(6)" + ], + "TDA-02.12": [ + "Annex I, Part I(1)" + ], + "TDA-04.2": [ + "Annex I, Part II(1)" + ], + "TDA-06": [ + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)" + ], + "VPM-02": [ + "Annex I, Part II(2)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 24, + "mappings": { + "Annex I, Part II": [ + "CPL-01" + ], + "Annex I, Part I(2)": [ + "IAO-01", + "IAO-02.2" + ], + "Annex I, Part II(3)": [ + "IAO-01", + "IAO-02.2", + "IAO-04", + "TDA-02.9" + ], + "Annex I, Part II(2)": [ + "IAO-04", + "TDA-01.1", + "TDA-02.9", + "VPM-02" + ], + "Annex I, Part I(2)(g)": [ + "PRI-01.11", + "TDA-01.1" + ], + "Annex I, Part I(1)": [ + "TDA-01.1", + "TDA-02.12" + ], + "Annex I, Part I(2)(h)": [ + "TDA-01.1", + "TDA-06" + ], + "Annex I, Part I(2)(i)": [ + "TDA-01.1", + "TDA-06" + ], + "Annex I, Part I(2)(j)": [ + "TDA-01.1", + "TDA-06" + ], + "Annex I, Part I(2)(k)": [ + "TDA-01.1", + "TDA-06" + ], + "Annex I, Part I(2)(m)": [ + "TDA-01.1" + ], + "Annex I, Part II(1)": [ + "TDA-01.1", + "TDA-04.2" + ], + "Annex I, Part I(2)(a)": [ + "TDA-01.3", + "TDA-02", + "TDA-02.8" + ], + "Annex I, Part I(2)(e)": [ + "TDA-02", + "TDA-02.4", + "TDA-06" + ], + "Annex I, Part I(2)(f)": [ + "TDA-02", + "TDA-02.4", + "TDA-06" + ], + "Annex I, Part I(2)(b)": [ + "TDA-02.4" + ], + "Annex I, Part I(2)(d)": [ + "TDA-02.8" + ], + "Annex I, Part I(2)(c)": [ + "TDA-02.9" + ], + "Annex I, Part I(2)(l)": [ + "TDA-02.9" + ], + "Annex I, Part II(4)": [ + "TDA-02.9" + ], + "Annex I, Part II(5)": [ + "TDA-02.9", + "TDA-02.11" + ], + "Annex I, Part II(6)": [ + "TDA-02.9", + "TDA-02.11" + ], + "Annex I, Part II(7)": [ + "TDA-02.9" + ], + "Annex I, Part II(8)": [ + "TDA-02.9" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-eu-cyber-resilience-act-annexes-2022.json b/docs/api/crosswalks/emea-eu-cyber-resilience-act-annexes-2022.json deleted file mode 100644 index 3f3af46d..00000000 --- a/docs/api/crosswalks/emea-eu-cyber-resilience-act-annexes-2022.json +++ /dev/null @@ -1,548 +0,0 @@ -{ - "framework_id": "emea-eu-cyber-resilience-act-annexes-2022", - "display_name": "EU Cyber Resilience Act Annexes (CRA Annexes) (2022)", - "scf_to_framework": { - "total_mappings": 23, - "mappings": { - "CPL-01.4": [ - "Annex 6 Module A.1" - ], - "CPL-01.5": [ - "Annex 4", - "Annex 4.1", - "Annex 4.2", - "Annex 4.3", - "Annex 4.4", - "Annex 4.5", - "Annex 4.6", - "Annex 4.7", - "Annex 4.8", - "Annex 6 Module A.4", - "Annex 6 Module A.4.2", - "Annex 6 Module C.3.2" - ], - "CPL-03.1": [ - "Annex 6 Module H.3.1", - "Annex 6 Module H.3.5" - ], - "CPL-03.3": [ - "Annex 6 Module H.4.2" - ], - "CPL-08": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" - ], - "CPL-08.1": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" - ], - "DCH-01.2": [ - "Annex 1.1(3)(e)" - ], - "DCH-01.4": [ - "Annex 1.1(3)(e)" - ], - "DCH-18": [ - "Annex 6 Module B.9", - "Annex 6 Module C.3.2" - ], - "IAC-21": [ - "Annex 1.1(3)(e)" - ], - "PRI-05.4": [ - "Annex 1.1(3)(e)" - ], - "TDA-01.1": [ - "Annex 1.1(3)(j)", - "Annex 1.2(2)", - "Annex 2.1", - "Annex 2.2", - "Annex 2.3", - "Annex 2.4", - "Annex 2.5", - "Annex 2.6", - "Annex 2.7", - "Annex 2.8", - "Annex 2.9", - "Annex 2.9(a)", - "Annex 2.9(b)", - "Annex 2.9(c)", - "Annex 2.9(d)", - "Annex 6 Module A.3", - "Annex 6 Module A.4.1", - "Annex 6 Module C.2.1", - "Annex 6 Module C.3.1", - "Annex 6 Module H.2", - "Annex 6 Module H.3.2", - "Annex 6 Module H.3.4", - "Annex 6 Module H.5.1", - "Annex 6 Module H.5.2", - "Annex 6 Module H.6" - ], - "TDA-02": [ - "Annex 1.1(1)", - "Annex 1.1(3)(b)", - "Annex 1.1(3)(c)", - "Annex 1.1(3)(d)", - "Annex 1.1(3)(f)", - "Annex 1.1(3)(g)", - "Annex 1.1(3)(i)", - "Annex 6 Module A.3" - ], - "TDA-02.4": [ - "Annex 1.1(3)(a)" - ], - "TDA-02.8": [ - "Annex 1.1(2)", - "Annex 1.1(3)(h)" - ], - "TDA-02.9": [ - "Annex 1.1(3)(k)", - "Annex 1.2(2)", - "Annex 1.2(7)", - "Annex 1.2(8)" - ], - "TDA-02.10": [ - "Annex 1.2(3)" - ], - "TDA-02.11": [ - "Annex 1.2(4)", - "Annex 1.2(6)" - ], - "TDA-02.12": [ - "Annex 3 Class 1.1", - "Annex 3 Class 1.2", - "Annex 3 Class 1.3", - "Annex 3 Class 1.4", - "Annex 3 Class 1.5", - "Annex 3 Class 1.6", - "Annex 3 Class 1.7", - "Annex 3 Class 1.8", - "Annex 3 Class 1.9", - "Annex 3 Class 1.10", - "Annex 3 Class 1.11", - "Annex 3 Class 1.12", - "Annex 3 Class 1.13", - "Annex 3 Class 1.14", - "Annex 3 Class 1.15", - "Annex 3 Class 1.16", - "Annex 3 Class 1.17", - "Annex 3 Class 1.18", - "Annex 3 Class 1.19", - "Annex 3 Class 1.20", - "Annex 3 Class 1.21", - "Annex 3 Class 1.22", - "Annex 3 Class 1.23", - "Annex 3 Class 2.1", - "Annex 3 Class 2.2", - "Annex 3 Class 2.3", - "Annex 3 Class 2.4", - "Annex 3 Class 2.5", - "Annex 3 Class 2.6", - "Annex 3 Class 2.7", - "Annex 3 Class 2.8", - "Annex 3 Class 2.9", - "Annex 3 Class 2.10", - "Annex 3 Class 2.11", - "Annex 3 Class 2.12", - "Annex 3 Class 2.13", - "Annex 3 Class 2.14", - "Annex 3 Class 2.15" - ], - "TDA-04.2": [ - "Annex 1.2(1)", - "Annex 1.2(6)" - ], - "TDA-22": [ - "Annex 5", - "Annex 5.1", - "Annex 5.1(a)", - "Annex 5.1(b)", - "Annex 5.1(c)", - "Annex 5.1(d)", - "Annex 5.2", - "Annex 5.2(a)", - "Annex 5.2(b)", - "Annex 5.2(c)", - "Annex 5.3", - "Annex 5.4", - "Annex 5.5", - "Annex 5.6", - "Annex 5.7", - "Annex 6 Module A.2" - ], - "THR-06": [ - "Annex 1.2(5)" - ], - "THR-06.1": [ - "Annex 2.2" - ] - } - }, - "framework_to_scf": { - "total_mappings": 117, - "mappings": { - "Annex 6 Module A.1": [ - "CPL-01.4" - ], - "Annex 4": [ - "CPL-01.5" - ], - "Annex 4.1": [ - "CPL-01.5" - ], - "Annex 4.2": [ - "CPL-01.5" - ], - "Annex 4.3": [ - "CPL-01.5" - ], - "Annex 4.4": [ - "CPL-01.5" - ], - "Annex 4.5": [ - "CPL-01.5" - ], - "Annex 4.6": [ - "CPL-01.5" - ], - "Annex 4.7": [ - "CPL-01.5" - ], - "Annex 4.8": [ - "CPL-01.5" - ], - "Annex 6 Module A.4": [ - "CPL-01.5" - ], - "Annex 6 Module A.4.2": [ - "CPL-01.5" - ], - "Annex 6 Module C.3.2": [ - "CPL-01.5", - "DCH-18" - ], - "Annex 6 Module H.3.1": [ - "CPL-03.1" - ], - "Annex 6 Module H.3.5": [ - "CPL-03.1" - ], - "Annex 6 Module H.4.2": [ - "CPL-03.3" - ], - "Annex 6 Module A.5": [ - "CPL-08", - "CPL-08.1" - ], - "Annex 6 Module C.4": [ - "CPL-08", - "CPL-08.1" - ], - "Annex 1.1(3)(e)": [ - "DCH-01.2", - "DCH-01.4", - "IAC-21", - "PRI-05.4" - ], - "Annex 6 Module B.9": [ - "DCH-18" - ], - "Annex 1.1(3)(j)": [ - "TDA-01.1" - ], - "Annex 1.2(2)": [ - "TDA-01.1", - "TDA-02.9" - ], - "Annex 2.1": [ - "TDA-01.1" - ], - "Annex 2.2": [ - "TDA-01.1", - "THR-06.1" - ], - "Annex 2.3": [ - "TDA-01.1" - ], - "Annex 2.4": [ - "TDA-01.1" - ], - "Annex 2.5": [ - "TDA-01.1" - ], - "Annex 2.6": [ - "TDA-01.1" - ], - "Annex 2.7": [ - "TDA-01.1" - ], - "Annex 2.8": [ - "TDA-01.1" - ], - "Annex 2.9": [ - "TDA-01.1" - ], - "Annex 2.9(a)": [ - "TDA-01.1" - ], - "Annex 2.9(b)": [ - "TDA-01.1" - ], - "Annex 2.9(c)": [ - "TDA-01.1" - ], - "Annex 2.9(d)": [ - "TDA-01.1" - ], - "Annex 6 Module A.3": [ - "TDA-01.1", - "TDA-02" - ], - "Annex 6 Module A.4.1": [ - "TDA-01.1" - ], - "Annex 6 Module C.2.1": [ - "TDA-01.1" - ], - "Annex 6 Module C.3.1": [ - "TDA-01.1" - ], - "Annex 6 Module H.2": [ - "TDA-01.1" - ], - "Annex 6 Module H.3.2": [ - "TDA-01.1" - ], - "Annex 6 Module H.3.4": [ - "TDA-01.1" - ], - "Annex 6 Module H.5.1": [ - "TDA-01.1" - ], - "Annex 6 Module H.5.2": [ - "TDA-01.1" - ], - "Annex 6 Module H.6": [ - "TDA-01.1" - ], - "Annex 1.1(1)": [ - "TDA-02" - ], - "Annex 1.1(3)(b)": [ - "TDA-02" - ], - "Annex 1.1(3)(c)": [ - "TDA-02" - ], - "Annex 1.1(3)(d)": [ - "TDA-02" - ], - "Annex 1.1(3)(f)": [ - "TDA-02" - ], - "Annex 1.1(3)(g)": [ - "TDA-02" - ], - "Annex 1.1(3)(i)": [ - "TDA-02" - ], - "Annex 1.1(3)(a)": [ - "TDA-02.4" - ], - "Annex 1.1(2)": [ - "TDA-02.8" - ], - "Annex 1.1(3)(h)": [ - "TDA-02.8" - ], - "Annex 1.1(3)(k)": [ - "TDA-02.9" - ], - "Annex 1.2(7)": [ - "TDA-02.9" - ], - "Annex 1.2(8)": [ - "TDA-02.9" - ], - "Annex 1.2(3)": [ - "TDA-02.10" - ], - "Annex 1.2(4)": [ - "TDA-02.11" - ], - "Annex 1.2(6)": [ - "TDA-02.11", - "TDA-04.2" - ], - "Annex 3 Class 1.1": [ - "TDA-02.12" - ], - "Annex 3 Class 1.2": [ - "TDA-02.12" - ], - "Annex 3 Class 1.3": [ - "TDA-02.12" - ], - "Annex 3 Class 1.4": [ - "TDA-02.12" - ], - "Annex 3 Class 1.5": [ - "TDA-02.12" - ], - "Annex 3 Class 1.6": [ - "TDA-02.12" - ], - "Annex 3 Class 1.7": [ - "TDA-02.12" - ], - "Annex 3 Class 1.8": [ - "TDA-02.12" - ], - "Annex 3 Class 1.9": [ - "TDA-02.12" - ], - "Annex 3 Class 1.10": [ - "TDA-02.12" - ], - "Annex 3 Class 1.11": [ - "TDA-02.12" - ], - "Annex 3 Class 1.12": [ - "TDA-02.12" - ], - "Annex 3 Class 1.13": [ - "TDA-02.12" - ], - "Annex 3 Class 1.14": [ - "TDA-02.12" - ], - "Annex 3 Class 1.15": [ - "TDA-02.12" - ], - "Annex 3 Class 1.16": [ - "TDA-02.12" - ], - "Annex 3 Class 1.17": [ - "TDA-02.12" - ], - "Annex 3 Class 1.18": [ - "TDA-02.12" - ], - "Annex 3 Class 1.19": [ - "TDA-02.12" - ], - "Annex 3 Class 1.20": [ - "TDA-02.12" - ], - "Annex 3 Class 1.21": [ - "TDA-02.12" - ], - "Annex 3 Class 1.22": [ - "TDA-02.12" - ], - "Annex 3 Class 1.23": [ - "TDA-02.12" - ], - "Annex 3 Class 2.1": [ - "TDA-02.12" - ], - "Annex 3 Class 2.2": [ - "TDA-02.12" - ], - "Annex 3 Class 2.3": [ - "TDA-02.12" - ], - "Annex 3 Class 2.4": [ - "TDA-02.12" - ], - "Annex 3 Class 2.5": [ - "TDA-02.12" - ], - "Annex 3 Class 2.6": [ - "TDA-02.12" - ], - "Annex 3 Class 2.7": [ - "TDA-02.12" - ], - "Annex 3 Class 2.8": [ - "TDA-02.12" - ], - "Annex 3 Class 2.9": [ - "TDA-02.12" - ], - "Annex 3 Class 2.10": [ - "TDA-02.12" - ], - "Annex 3 Class 2.11": [ - "TDA-02.12" - ], - "Annex 3 Class 2.12": [ - "TDA-02.12" - ], - "Annex 3 Class 2.13": [ - "TDA-02.12" - ], - "Annex 3 Class 2.14": [ - "TDA-02.12" - ], - "Annex 3 Class 2.15": [ - "TDA-02.12" - ], - "Annex 1.2(1)": [ - "TDA-04.2" - ], - "Annex 5": [ - "TDA-22" - ], - "Annex 5.1": [ - "TDA-22" - ], - "Annex 5.1(a)": [ - "TDA-22" - ], - "Annex 5.1(b)": [ - "TDA-22" - ], - "Annex 5.1(c)": [ - "TDA-22" - ], - "Annex 5.1(d)": [ - "TDA-22" - ], - "Annex 5.2": [ - "TDA-22" - ], - "Annex 5.2(a)": [ - "TDA-22" - ], - "Annex 5.2(b)": [ - "TDA-22" - ], - "Annex 5.2(c)": [ - "TDA-22" - ], - "Annex 5.3": [ - "TDA-22" - ], - "Annex 5.4": [ - "TDA-22" - ], - "Annex 5.5": [ - "TDA-22" - ], - "Annex 5.6": [ - "TDA-22" - ], - "Annex 5.7": [ - "TDA-22" - ], - "Annex 6 Module A.2": [ - "TDA-22" - ], - "Annex 1.2(5)": [ - "THR-06" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-eu-dora-2023.json b/docs/api/crosswalks/emea-eu-dora-2023.json index e077aecd..aa3b8384 100644 --- a/docs/api/crosswalks/emea-eu-dora-2023.json +++ b/docs/api/crosswalks/emea-eu-dora-2023.json @@ -1,6 +1,6 @@ { "framework_id": "emea-eu-dora-2023", - "display_name": "EU Digital Operational Resilience Act (DORA) (2023)", + "display_name": "EU - Digital Operational Resilience Act (2023)", "scf_to_framework": { "total_mappings": 102, "mappings": { diff --git a/docs/api/crosswalks/emea-eu-eba-ict-srm-2025.json b/docs/api/crosswalks/emea-eu-eba-ict-srm-2025.json index bebf9479..fd7a14cb 100644 --- a/docs/api/crosswalks/emea-eu-eba-ict-srm-2025.json +++ b/docs/api/crosswalks/emea-eu-eba-ict-srm-2025.json @@ -1,1025 +1,882 @@ { "framework_id": "emea-eu-eba-ict-srm-2025", - "display_name": "EU EBA Guidelines on ICT and Security Risk Management (2025)", + "display_name": "EU - European Banking Authority Guidelines on ICT and Security Risk Management (2025)", "scf_to_framework": { - "total_mappings": 148, + "total_mappings": 153, "mappings": { + "GOV-01": [ + "3.4.1.30" + ], "GOV-01.1": [ - "3.2.1(2)", - "3.2.1(3)", - "3.2.1(4)" + "3.2.1.2", + "3.2.1.3", + "3.2.1.4" ], "GOV-01.2": [ - "3.3.1(13)(e)", - "3.3.5(24)" + "3.3.1.13(e)", + "3.3.5.24" + ], + "GOV-01.3": [ + "3.4.6.48" ], "GOV-02": [ - "3.4.1(28)", - "3.4.1(29)", - "3.4.5(38)" + "3.4.1.28", + "3.4.5.38", + "3.5.50" ], "GOV-03": [ - "3.3.1(14)" + "3.3.1.14" ], "GOV-04": [ - "3.3.1(11)", - "3.3.1(12)", - "3.7.5(91)" + "3.3.1.11" ], "GOV-04.1": [ - "3.3.1(11)", - "3.7.5(91)" + "3.3.1.11", + "3.3.1.12" ], - "GOV-04.2": [ - "3.7.5(91)" + "GOV-05": [ + "3.5.51" ], "GOV-06": [ - "3.7.5(91)" + "3.7.5.91" ], "GOV-08": [ - "3.2.1(4)" - ], - "GOV-09": [ - "3.2.1(5)(c)" + "3.2.1.4", + "3.2.2.5" ], "GOV-15": [ - "3.3.4(22)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "GOV-15.1": [ - "3.3.4(22)", - "3.3.4(23)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "GOV-15.2": [ - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" - ], - "GOV-15.3": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "AST-01": [ - "3.5(53)", - "3.5(54)" + "3.5.53", + "3.5.54" ], "AST-01.1": [ - "3.3.3(17)", - "3.3.3(18)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "AST-01.2": [ - "3.3.2(16)", - "3.5(54)" + "3.5.54" ], "AST-02": [ - "3.5(53)", - "3.5(54)" + "3.3.2.16", + "3.5.53", + "3.5.54" + ], + "AST-02.9": [ + "3.5.54" ], "AST-04.1": [ - "3.3.3(17)", - "3.3.3(18)" + "3.3.3.17", + "3.3.3.18" ], "BCD-01": [ - "3.7(77)", - "3.7.1(78)", - "3.7.1(79)", - "3.7.2(80)", - "3.7.2(81)", - "3.7.2(82)", - "3.7.3(83)", - "3.7.3(84)(a)", - "3.7.3(84)(b)", - "3.7.3(84)(c)", - "3.7.3(85)", - "3.7.3(86)" + "3.7.77", + "3.7.1.78", + "3.7.1.79", + "3.7.2.80", + "3.7.3.83", + "3.7.3.85", + "3.7.3.86", + "3.7.5.91" + ], + "BCD-01.4": [ + "3.7.2.81" + ], + "BCD-01.7": [ + "3.7.2.82", + "3.7.3.83", + "3.7.3.84", + "3.7.3.84(a)", + "3.7.3.84(b)", + "3.7.3.84(c)" ], "BCD-02": [ - "3.7.1(78)", - "3.7.3(83)" + "3.3.2.16", + "3.7.1.78" ], "BCD-04": [ - "3.7.4(87)", - "3.7.4(89)", - "3.7.4(89)(a)", - "3.7.4(89)(b)", - "3.7.4(89)(c)", - "3.7.4(90)" + "3.7.4.87", + "3.7.4.89", + "3.7.4.89(a)", + "3.7.4.89(b)", + "3.7.4.89(c)", + "3.7.4.90" ], "BCD-05": [ - "3.7.4(88)", - "3.7.4(90)" + "3.7.3.84(c)", + "3.7.4.88", + "3.7.4.90" ], "BCD-06": [ - "3.7.4(88)", - "3.7.4(90)" - ], - "BCD-10": [ - "3.7.5(91)" + "3.7.4.88", + "3.7.4.90" ], "BCD-10.3": [ - "3.7.3(86)" + "3.7.3.86" ], "BCD-10.4": [ - "3.7.5(91)" + "3.7.5.91" ], "BCD-11": [ - "3.5(57)" + "3.5.57" ], "BCD-11.2": [ - "3.5(58)" - ], - "BCD-12": [ - "3.7.3(83)" + "3.5.58" ], "CAP-01": [ - "3.5(56)" + "3.5.56" ], "CHG-01": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "CHG-02": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "CHG-02.1": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "CHG-02.2": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "CHG-02.3": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "CHG-03": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.76" ], "CPL-01": [ - "3.1(1)", - "3.8(92)", - "3.8(93)", - "3.8(94)", - "3.8(95)", - "3.8(96)", - "3.8(97)", - "3.8(98)" + "3.1.1", + "3.8.92", + "3.8.93", + "3.8.94", + "3.8.95", + "3.8.96", + "3.8.97", + "3.8.98" + ], + "CPL-01.1": [ + "3.3.6.27" ], "CPL-02": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.1.11", + "3.3.3.19", + "3.3.6.25", + "3.4.6.41", + "3.4.6.46", + "3.4.6.48" ], "CPL-02.1": [ - "3.3.1(11)", - "3.3.6(25)" + "3.3.1.11", + "3.3.6.25" ], "CPL-03": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41", + "3.4.6.44" ], "CPL-03.1": [ - "3.3.6(25)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)(a)", - "3.4.6(43)(b)" + "3.3.6.25", + "3.4.6.41" ], "CPL-03.2": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41" ], "CFG-02": [ - "3.4.4(36)(b)" + "3.4.4.36(b)" + ], + "CFG-02.1": [ + "3.4.6.46" ], "MON-01": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" + "3.4.5.39", + "3.5.52" ], "MON-01.2": [ - "3.4.5(39)", - "3.4.5(40)" + "3.4.5.38", + "3.4.5.39" ], "MON-01.7": [ - "3.4.4(36)(e)" - ], - "MON-01.8": [ - "3.4.5(39)", - "3.4.5(40)" - ], - "MON-01.16": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" + "3.4.4.36(e)" ], "MON-02": [ - "3.5(52)" + "3.4.5.38", + "3.4.5.39", + "3.5.52" ], - "MON-02.2": [ - "3.5(52)" + "MON-02.1": [ + "3.4.5.38(a)", + "3.4.5.38(b)", + "3.4.5.38(c)", + "3.4.5.39", + "3.4.5.40" ], - "MON-03": [ - "3.5(52)" + "MON-02.2": [ + "3.5.52" ], "MON-11.3": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" ], "MON-16": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" + ], + "MON-16.4": [ + "3.4.2.31(c)", + "3.4.2.31(d)" ], "CRY-01": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "CRY-03": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "CRY-05": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "DCH-02": [ - "3.3.3(17)", - "3.3.3(18)", - "3.3.3(19)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "END-01": [ - "3.4.4(36)(d)" + "3.4.4.36(d)" ], "END-06": [ - "3.4.4(36)(e)" + "3.4.4.36(e)" ], "HRS-01": [ - "3.3.2(15)" - ], - "HRS-02": [ - "3.3.2(15)" + "3.2.1.3" ], "HRS-03": [ - "3.3.1(12)", - "3.3.2(15)" + "3.2.1.2", + "3.3.1.12", + "3.4.1.29" + ], + "HRS-13": [ + "3.2.1.3" + ], + "HRS-13.1": [ + "3.2.1.3" + ], + "HRS-13.3": [ + "3.2.1.3" + ], + "IAC-01": [ + "3.4.2.31(g)" + ], + "IAC-01.2": [ + "3.4.2.31(g)" + ], + "IAC-07": [ + "3.4.2.31(e)" ], "IAC-08": [ - "3.4.2.(32)" + "3.4.2.32" + ], + "IAC-15": [ + "3.4.2.31(c)" + ], + "IAC-15.5": [ + "3.4.2.31(b)" + ], + "IAC-16": [ + "3.4.2.31(d)" + ], + "IAC-17": [ + "3.4.2.31(e)", + "3.4.2.31(f)" + ], + "IAC-21": [ + "3.4.2.31(a)" ], "IRO-01": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60" ], "IRO-02": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60", + "3.5.1.60(a)", + "3.5.1.60(b)", + "3.5.1.60(c)", + "3.5.1.60(d)", + "3.5.1.60(d)(i)", + "3.5.1.60(d)(ii)", + "3.5.1.60(e)", + "3.5.1.60(f)", + "3.5.1.60(f)(i)", + "3.5.1.60(f)(ii)" ], "IRO-04": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" - ], - "IRO-07": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)" - ], - "IRO-09": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(ii)" + "3.5.1.59", + "3.5.1.60" ], "IRO-10": [ - "3.7.5(91)" + "3.7.5.91" ], "IRO-10.2": [ - "3.7.5(91)" + "3.7.5.91" ], "IRO-14": [ - "3.7.5(91)" + "3.7.5.91" ], "IRO-16": [ - "3.7.5(91)" + "3.7.5.91" ], "IAO-01": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)" + "3.4.6.42", + "3.4.6.43", + "3.4.6.43(a)", + "3.4.6.43(b)", + "3.4.6.45", + "3.6.2.69", + "3.6.2.70" + ], + "IAO-01.1": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-02": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" + ], + "IAO-02.1": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-02.2": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.4.6.47", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" + ], + "IAO-02.4": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "IAO-03": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "IAO-03.2": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "IAO-04": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-05": [ - "3.3.1(13)(d)" + "3.3.1.13(d)", + "3.3.6.27", + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-06": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "IAO-07": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "NET-06": [ - "3.4.4(36)(c)" + "3.4.4.36(c)" ], "PES-01": [ - "3.4.3(33)" + "3.4.3.33" + ], + "PES-02": [ + "3.4.3.34" ], "PES-02.1": [ - "3.4.3(34)" + "3.4.3.34" ], "PES-07": [ - "3.4.3(35)" + "3.4.3.35" ], "PES-07.1": [ - "3.4.3(35)" + "3.4.3.35" ], "PES-07.5": [ - "3.4.3(35)" + "3.4.3.35" ], "PES-08": [ - "3.4.3(35)" + "3.4.3.35" ], "PES-09": [ - "3.4.3(35)" + "3.4.3.35" ], "PRM-01": [ - "3.2.1(6)", - "3.6.1(61)", - "3.6.1(62)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66", + "3.6.2.74" ], "PRM-01.1": [ - "3.2.1(4)", - "3.2.1(5)(a)", - "3.2.1(5)(b)", - "3.2.1(5)(c)" + "3.2.1.4", + "3.2.2.5", + "3.2.2.5(a)", + "3.2.2.5(b)", + "3.2.2.5(c)", + "3.2.2.6" ], "PRM-02": [ - "3.6.1(61)", - "3.6.1(62)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66" + ], + "PRM-02.1": [ + "3.6.1.62", + "3.6.1.66" ], "PRM-03": [ - "3.2.1(3)" + "3.2.1.3" ], "PRM-04": [ - "3.3.1(10)", - "3.3.1(13)(f)", - "3.6.1(62)", - "3.6.1(61)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.3.1.10", + "3.3.1.13(f)", + "3.6.1.61", + "3.6.1.62", + "3.6.1.63", + "3.6.1.63(a)", + "3.6.1.63(b)", + "3.6.1.63(c)", + "3.6.1.63(d)", + "3.6.1.63(e)", + "3.6.1.63(f)", + "3.6.1.64", + "3.6.1.65", + "3.6.1.66", + "3.6.2.74" ], "PRM-05": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.6.1.64", + "3.6.2.68" ], "PRM-06": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.3.2.15", + "3.6.1.64", + "3.6.2.68" ], "PRM-07": [ - "3.3.1(13)(f)", - "3.5(55)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)" + "3.3.1.13(f)", + "3.5.55" ], "RSK-01": [ - "3.2.3(7)", - "3.3.1(10)", - "3.3.1(13)(a)", - "3.3.1(13)(b)", - "3.3.1(13)(c)", - "3.3.1(13)(d)", - "3.3.1(13)(e)", - "3.3.1(13)(f)", - "3.3.1(14)" + "3.2.3.7", + "3.3.1.10", + "3.3.1.13", + "3.3.1.13(d)", + "3.3.1.13(e)", + "3.3.1.13(f)", + "3.3.1.14", + "3.3.4.23" ], "RSK-01.1": [ - "3.3.1(10)", - "3.6.1(66)", - "3.7.2(82)" + "3.3.1.10" ], "RSK-01.3": [ - "3.3.1(10)" + "3.3.1.10" ], "RSK-01.4": [ - "3.3.1(10)" + "3.3.1.10" ], "RSK-01.5": [ - "3.3.1(10)", - "3.3.1(13)(a)" + "3.3.1.10", + "3.3.1.13(a)" ], "RSK-03": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "RSK-04": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.3.3(20)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "RSK-04.1": [ - "3.3.1(10)", - "3.3.1(13)(d)" + "3.3.1.10", + "3.3.1.13(d)" ], "RSK-05": [ - "3.3.1(10)" + "3.3.1.10" ], "RSK-06": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "RSK-06.1": [ - "3.3.1(13)(c)" + "3.3.1.13(c)" ], "RSK-06.2": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "RSK-07": [ - "3.3.1(13)(f)" + "3.3.1.13(f)" ], "RSK-08": [ - "3.7.1(78)" + "3.3.3.20", + "3.7.1.78" ], "SEA-01": [ - "3.7.1(79)" + "3.7.1.79" ], "SEA-02": [ - "3.7.1(79)" + "3.7.1.79" ], "SEA-03": [ - "3.7.1(79)" + "3.7.1.79" ], "SEA-07.1": [ - "3.5(55)" + "3.5.55" ], "OPS-01.1": [ - "3.4.2.(31)", - "3.4.2(31)(a)", - "3.4.2(31)(b)", - "3.4.2(31)(c)", - "3.4.2(31)(d)", - "3.4.2(31)(e)", - "3.4.2(31)(f)", - "3.4.2(31)(g)", - "3.4.5(38)", - "3.5(50)" + "3.4.2.31", + "3.4.4.36", + "3.5.50" ], "OPS-02": [ - "3.2.1(6)" + "3.2.2.6" ], "SAT-01": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "SAT-02": [ - "3.4.7(49)" + "3.4.7.49" ], "SAT-03": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "TDA-01": [ - "3.6.2(67)", - "3.6.2(74)" - ], - "TDA-01.1": [ - "3.6.2(68)" - ], - "TDA-02": [ - "3.6.2(68)" - ], - "TDA-02.3": [ - "3.6.2(69)", - "3.6.2(74)" - ], - "TDA-02.4": [ - "3.6.2(69)" - ], - "TDA-02.7": [ - "3.6.2(69)" + "3.6.2.67", + "3.6.2.74" ], "TDA-04": [ - "3.6.2(73)" - ], - "TDA-04.1": [ - "3.6.2(69)" - ], - "TDA-05": [ - "3.6.2(69)" - ], - "TDA-06": [ - "3.6.2(69)" - ], - "TDA-06.2": [ - "3.6.2(69)" - ], - "TDA-06.5": [ - "3.6.2(69)" + "3.6.2.73" ], "TDA-07": [ - "3.6.2(69)", - "3.6.2(72)" + "3.6.2.72" ], "TDA-08": [ - "3.6.2(69)", - "3.6.2(72)" - ], - "TDA-09": [ - "3.6.2(69)", - "3.6.2(70)", - "3.6.2(71)" - ], - "TDA-15": [ - "3.6.2(68)", - "3.6.2(69)", - "3.6.2(70)" + "3.6.2.72" ], "TDA-20": [ - "3.6.2(73)" + "3.6.2.73" ], "TPM-01": [ - "3.2.3(7)", - "3.6.2(74)" + "3.2.3.7" ], - "TPM-03": [ - "3.6.2(74)" + "TPM-02": [ + "3.3.2.16" ], - "TPM-03.1": [ - "3.6.2(74)" - ], - "TPM-04.1": [ - "3.6.2(74)" + "TPM-03": [ + "3.7.3.86" ], "TPM-05": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8", + "3.2.3.8(a)", + "3.2.3.8(b)" ], "TPM-05.2": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8" ], "TPM-05.4": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)", - "3.3.2(16)", - "3.5(55)" + "3.2.3.8", + "3.5.55" ], "TPM-05.5": [ - "3.5(55)" + "3.5.55" ], "TPM-05.6": [ - "3.2.3(9)" + "3.2.3.9" ], "TPM-08": [ - "3.2.3(9)" + "3.2.3.9" ], "TPM-11": [ - "3.2.3(8)(b)" + "3.2.3.8(b)" ], "THR-03": [ - "3.3.3(21)" + "3.3.3.21" ], "VPM-01": [ - "3.3.3(21)", - "3.4.4(36)(a)" + "3.3.3.21", + "3.4.4.36(a)" ] } }, "framework_to_scf": { - "total_mappings": 150, + "total_mappings": 156, "mappings": { - "3.2.1(2)": [ - "GOV-01.1" + "3.4.1.30": [ + "GOV-01" ], - "3.2.1(3)": [ + "3.2.1.2": [ "GOV-01.1", - "PRM-03", - "SAT-01", - "SAT-03" + "HRS-03" + ], + "3.2.1.3": [ + "GOV-01.1", + "HRS-01", + "HRS-13", + "HRS-13.1", + "HRS-13.3", + "PRM-03" ], - "3.2.1(4)": [ + "3.2.1.4": [ "GOV-01.1", "GOV-08", "PRM-01.1" ], - "3.3.1(13)(e)": [ + "3.3.1.13(e)": [ "GOV-01.2", "RSK-01" ], - "3.3.5(24)": [ + "3.3.5.24": [ "GOV-01.2" ], - "3.4.1(28)": [ - "GOV-02" + "3.4.6.48": [ + "GOV-01.3", + "CPL-02" ], - "3.4.1(29)": [ + "3.4.1.28": [ "GOV-02" ], - "3.4.5(38)": [ + "3.4.5.38": [ "GOV-02", + "MON-01.2", + "MON-02", "MON-11.3", - "MON-16", + "MON-16" + ], + "3.5.50": [ + "GOV-02", "OPS-01.1" ], - "3.3.1(14)": [ + "3.3.1.14": [ "GOV-03", "RSK-01" ], - "3.3.1(11)": [ + "3.3.1.11": [ "GOV-04", "GOV-04.1", + "CPL-02", "CPL-02.1" ], - "3.3.1(12)": [ - "GOV-04", + "3.3.1.12": [ + "GOV-04.1", "HRS-03" ], - "3.7.5(91)": [ - "GOV-04", - "GOV-04.1", - "GOV-04.2", + "3.5.51": [ + "GOV-05" + ], + "3.7.5.91": [ "GOV-06", - "BCD-10", + "BCD-01", "BCD-10.4", "IRO-10", "IRO-10.2", "IRO-14", "IRO-16" ], - "3.2.1(5)(c)": [ - "GOV-09", + "3.2.2.5": [ + "GOV-08", "PRM-01.1" ], - "3.3.4(22)": [ + "3.3.4.22": [ "GOV-15", "GOV-15.1" ], - "3.4.1(30)(a)": [ + "3.4.1.30(a)": [ "GOV-15", "GOV-15.1", "GOV-15.2" ], - "3.4.1(30)(b)": [ + "3.4.1.30(b)": [ "GOV-15", "GOV-15.1", "GOV-15.2" ], - "3.4.1(30)(c)": [ + "3.4.1.30(c)": [ "GOV-15", "GOV-15.1", "GOV-15.2" ], - "3.4.1(30)(d)": [ + "3.4.1.30(d)": [ "GOV-15", "GOV-15.1", "GOV-15.2" ], - "3.4.1(30)(e)": [ + "3.4.1.30(e)": [ "GOV-15", "GOV-15.1", "GOV-15.2" ], - "3.4.1(30)(f)": [ + "3.4.1.30(f)": [ "GOV-15", "GOV-15.1", "GOV-15.2" ], - "3.4.1(30)(g)": [ + "3.4.1.30(g)": [ "GOV-15", "GOV-15.1", "GOV-15.2" ], - "3.3.4(23)": [ - "GOV-15.1" - ], - "3.4.6(41)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(42)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(43)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(43)(a)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(43)(b)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(44)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(45)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(46)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(47)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.4.6(48)": [ - "GOV-15.3", - "CPL-02", - "CPL-03", - "CPL-03.2", - "IAO-01", - "IAO-02" - ], - "3.5(53)": [ + "3.5.53": [ "AST-01", "AST-02" ], - "3.5(54)": [ + "3.5.54": [ "AST-01", "AST-01.1", "AST-01.2", "AST-02", + "AST-02.9", "DCH-02" ], - "3.3.3(17)": [ + "3.3.3.17": [ "AST-01.1", "AST-04.1", "DCH-02" ], - "3.3.3(18)": [ + "3.3.3.18": [ "AST-01.1", "AST-04.1", "DCH-02" ], - "3.3.2(16)": [ - "AST-01.2", - "TPM-05.4" + "3.3.2.16": [ + "AST-02", + "BCD-02", + "TPM-02" ], - "3.7(77)": [ + "3.7.77": [ "BCD-01" ], - "3.7.1(78)": [ + "3.7.1.78": [ "BCD-01", "BCD-02", "RSK-08" ], - "3.7.1(79)": [ + "3.7.1.79": [ "BCD-01", "SEA-01", "SEA-02", "SEA-03" ], - "3.7.2(80)": [ + "3.7.2.80": [ "BCD-01" ], - "3.7.2(81)": [ + "3.7.3.83": [ + "BCD-01", + "BCD-01.7" + ], + "3.7.3.85": [ "BCD-01" ], - "3.7.2(82)": [ + "3.7.3.86": [ "BCD-01", - "RSK-01.1", - "RSK-03", - "RSK-04" + "BCD-10.3", + "TPM-03" ], - "3.7.3(83)": [ - "BCD-01", - "BCD-02", - "BCD-12" + "3.7.2.81": [ + "BCD-01.4" ], - "3.7.3(84)(a)": [ - "BCD-01" + "3.7.2.82": [ + "BCD-01.7" ], - "3.7.3(84)(b)": [ - "BCD-01" + "3.7.3.84": [ + "BCD-01.7" ], - "3.7.3(84)(c)": [ - "BCD-01" + "3.7.3.84(a)": [ + "BCD-01.7" ], - "3.7.3(85)": [ - "BCD-01" + "3.7.3.84(b)": [ + "BCD-01.7" ], - "3.7.3(86)": [ - "BCD-01", - "BCD-10.3" + "3.7.3.84(c)": [ + "BCD-01.7", + "BCD-05" ], - "3.7.4(87)": [ + "3.7.4.87": [ "BCD-04" ], - "3.7.4(89)": [ + "3.7.4.89": [ "BCD-04" ], - "3.7.4(89)(a)": [ + "3.7.4.89(a)": [ "BCD-04" ], - "3.7.4(89)(b)": [ + "3.7.4.89(b)": [ "BCD-04" ], - "3.7.4(89)(c)": [ + "3.7.4.89(c)": [ "BCD-04" ], - "3.7.4(90)": [ + "3.7.4.90": [ "BCD-04", "BCD-05", "BCD-06" ], - "3.7.4(88)": [ + "3.7.4.88": [ "BCD-05", "BCD-06" ], - "3.5(57)": [ + "3.5.57": [ "BCD-11" ], - "3.5(58)": [ + "3.5.58": [ "BCD-11.2" ], - "3.5(56)": [ + "3.5.56": [ "CAP-01" ], - "3.4.4(37)": [ + "3.4.4.37": [ "CHG-01", "CHG-02", "CHG-02.1", @@ -1027,254 +884,294 @@ "CHG-02.3", "CHG-03" ], - "3.6.3(75)": [ + "3.6.3.75": [ "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "CHG-02.3", - "CHG-03" + "CHG-02" ], - "3.6.3(76)": [ - "CHG-01", - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "CHG-02.3", + "3.6.3.76": [ "CHG-03" ], - "3.1(1)": [ + "3.1.1": [ "CPL-01" ], - "3.8(92)": [ + "3.8.92": [ "CPL-01" ], - "3.8(93)": [ + "3.8.93": [ "CPL-01" ], - "3.8(94)": [ + "3.8.94": [ "CPL-01" ], - "3.8(95)": [ + "3.8.95": [ "CPL-01" ], - "3.8(96)": [ + "3.8.96": [ "CPL-01" ], - "3.8(97)": [ + "3.8.97": [ "CPL-01" ], - "3.8(98)": [ + "3.8.98": [ "CPL-01" ], - "3.3.6(25)": [ + "3.3.6.27": [ + "CPL-01.1", + "IAO-05" + ], + "3.3.3.19": [ + "CPL-02" + ], + "3.3.6.25": [ + "CPL-02", "CPL-02.1", "CPL-03.1" ], - "3.3.6(26)": [ + "3.4.6.41": [ + "CPL-02", "CPL-03", + "CPL-03.1", "CPL-03.2" ], - "3.3.6(27)": [ + "3.4.6.46": [ + "CPL-02", + "CFG-02.1" + ], + "3.3.6.26": [ "CPL-03", "CPL-03.2" ], - "3.4.4(36)(b)": [ - "CFG-02" + "3.4.6.44": [ + "CPL-03" ], - "3.4.5(39)": [ - "MON-01", - "MON-01.2", - "MON-01.8", - "MON-01.16" + "3.4.4.36(b)": [ + "CFG-02" ], - "3.4.5(40)": [ + "3.4.5.39": [ "MON-01", "MON-01.2", - "MON-01.8", - "MON-01.16" + "MON-02", + "MON-02.1" ], - "3.5(52)": [ + "3.5.52": [ "MON-01", - "MON-01.16", "MON-02", - "MON-02.2", - "MON-03" + "MON-02.2" ], - "3.4.4(36)(e)": [ + "3.4.4.36(e)": [ "MON-01.7", "END-06" ], - "3.4.5(38)(a)": [ - "MON-11.3", - "MON-16" + "3.4.5.38(a)": [ + "MON-02.1" ], - "3.4.5(38)(b)": [ - "MON-11.3", - "MON-16" + "3.4.5.38(b)": [ + "MON-02.1" ], - "3.4.5(38)(c)": [ - "MON-11.3", - "MON-16" + "3.4.5.38(c)": [ + "MON-02.1" + ], + "3.4.5.40": [ + "MON-02.1" + ], + "3.4.2.31(c)": [ + "MON-16.4", + "IAC-15" + ], + "3.4.2.31(d)": [ + "MON-16.4", + "IAC-16" ], - "3.4.4(36)(f)": [ + "3.4.4.36(f)": [ "CRY-01", "CRY-03", "CRY-05" ], - "3.3.3(19)": [ - "DCH-02" - ], - "3.4.4(36)(d)": [ + "3.4.4.36(d)": [ "END-01" ], - "3.3.2(15)": [ - "HRS-01", - "HRS-02", + "3.4.1.29": [ "HRS-03" ], - "3.4.2.(32)": [ + "3.4.2.31(g)": [ + "IAC-01", + "IAC-01.2" + ], + "3.4.2.31(e)": [ + "IAC-07", + "IAC-17" + ], + "3.4.2.32": [ "IAC-08" ], - "3.5.1(59)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.4.2.31(b)": [ + "IAC-15.5" ], - "3.5.1(60)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.4.2.31(f)": [ + "IAC-17" ], - "3.5.1(60)(a)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.4.2.31(a)": [ + "IAC-21" ], - "3.5.1(60)(b)": [ + "3.5.1.59": [ "IRO-01", "IRO-02", "IRO-04" ], - "3.5.1(60)(c)": [ + "3.5.1.60": [ "IRO-01", "IRO-02", "IRO-04" ], - "3.5.1(60)(d)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07", - "IRO-09" + "3.5.1.60(a)": [ + "IRO-02" ], - "3.5.1(60)(d)(i)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-07" + "3.5.1.60(b)": [ + "IRO-02" ], - "3.5.1(60)(d)(ii)": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-09" + "3.5.1.60(c)": [ + "IRO-02" ], - "3.5.1(60)(e)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.5.1.60(d)": [ + "IRO-02" ], - "3.5.1(60)(f)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.5.1.60(d)(i)": [ + "IRO-02" ], - "3.5.1(60)(f)(i)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.5.1.60(d)(ii)": [ + "IRO-02" ], - "3.5.1(60)(f)(ii)": [ - "IRO-01", - "IRO-02", - "IRO-04" + "3.5.1.60(e)": [ + "IRO-02" + ], + "3.5.1.60(f)": [ + "IRO-02" + ], + "3.5.1.60(f)(i)": [ + "IRO-02" ], - "3.6.2(70)": [ + "3.5.1.60(f)(ii)": [ + "IRO-02" + ], + "3.4.6.42": [ "IAO-01", + "IAO-01.1", "IAO-02", + "IAO-02.1", "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-03.2", + "IAO-04", + "IAO-05", "IAO-06", - "IAO-07", - "TDA-09", - "TDA-15" + "IAO-07" + ], + "3.4.6.43": [ + "IAO-01" + ], + "3.4.6.43(a)": [ + "IAO-01" + ], + "3.4.6.43(b)": [ + "IAO-01" ], - "3.6.2(71)": [ + "3.4.6.45": [ + "IAO-01" + ], + "3.6.2.69": [ + "IAO-01", + "IAO-01.1", "IAO-02", + "IAO-02.1", "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-03.2", + "IAO-04", + "IAO-05", "IAO-06", - "IAO-07", - "TDA-09" + "IAO-07" + ], + "3.6.2.70": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.1", + "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-03.2", + "IAO-04", + "IAO-05", + "IAO-06", + "IAO-07" + ], + "3.6.2.71": [ + "IAO-02", + "IAO-02.2" + ], + "3.4.6.47": [ + "IAO-02.2" ], - "3.3.1(13)(d)": [ + "3.3.1.13(d)": [ "IAO-05", "RSK-01", "RSK-04.1" ], - "3.4.4(36)(c)": [ + "3.4.4.36(c)": [ "NET-06" ], - "3.4.3(33)": [ + "3.4.3.33": [ "PES-01" ], - "3.4.3(34)": [ + "3.4.3.34": [ + "PES-02", "PES-02.1" ], - "3.4.3(35)": [ + "3.4.3.35": [ "PES-07", "PES-07.1", "PES-07.5", "PES-08", "PES-09" ], - "3.2.1(6)": [ - "PRM-01", - "OPS-02" - ], - "3.6.1(61)": [ + "3.6.1.61": [ "PRM-01", "PRM-02", "PRM-04" ], - "3.6.1(62)": [ + "3.6.1.62": [ "PRM-01", "PRM-02", + "PRM-02.1", "PRM-04" ], - "3.6.1(64)": [ + "3.6.1.66": [ "PRM-01", - "PRM-04", - "PRM-05", - "PRM-06" + "PRM-02", + "PRM-02.1", + "PRM-04" ], - "3.6.1(65)": [ + "3.6.2.74": [ "PRM-01", "PRM-04", - "PRM-05", - "PRM-06" + "TDA-01" ], - "3.6.1(66)": [ - "PRM-01", - "PRM-04", - "RSK-01.1" + "3.2.2.5(a)": [ + "PRM-01.1" ], - "3.2.1(5)(a)": [ + "3.2.2.5(b)": [ "PRM-01.1" ], - "3.2.1(5)(b)": [ + "3.2.2.5(c)": [ "PRM-01.1" ], - "3.3.1(10)": [ + "3.2.2.6": [ + "PRM-01.1", + "OPS-02" + ], + "3.3.1.10": [ "PRM-04", "RSK-01", "RSK-01.1", @@ -1286,165 +1183,126 @@ "RSK-04.1", "RSK-05" ], - "3.3.1(13)(f)": [ + "3.3.1.13(f)": [ "PRM-04", "PRM-07", "RSK-01", + "RSK-03", + "RSK-04", "RSK-07" ], - "3.6.1(63)(a)": [ - "PRM-04", - "PRM-07" + "3.6.1.63": [ + "PRM-04" ], - "3.6.1(63)(b)": [ - "PRM-04", - "PRM-07" + "3.6.1.63(a)": [ + "PRM-04" ], - "3.6.1(63)(c)": [ - "PRM-04", - "PRM-07" + "3.6.1.63(b)": [ + "PRM-04" ], - "3.6.1(63)(d)": [ - "PRM-04", - "PRM-07" + "3.6.1.63(c)": [ + "PRM-04" ], - "3.6.1(63)(e)": [ - "PRM-04", - "PRM-07" + "3.6.1.63(d)": [ + "PRM-04" ], - "3.6.1(63)(f)": [ - "PRM-04", - "PRM-07" + "3.6.1.63(e)": [ + "PRM-04" ], - "3.5(51)": [ + "3.6.1.63(f)": [ + "PRM-04" + ], + "3.6.1.64": [ + "PRM-04", "PRM-05", "PRM-06" ], - "3.6.2(68)": [ + "3.6.1.65": [ + "PRM-04" + ], + "3.6.2.68": [ "PRM-05", - "PRM-06", - "TDA-01.1", - "TDA-02", - "TDA-15" + "PRM-06" ], - "3.5(55)": [ + "3.3.2.15": [ + "PRM-06" + ], + "3.5.55": [ "PRM-07", "SEA-07.1", "TPM-05.4", "TPM-05.5" ], - "3.2.3(7)": [ + "3.2.3.7": [ "RSK-01", "TPM-01" ], - "3.3.1(13)(a)": [ + "3.3.1.13": [ + "RSK-01" + ], + "3.3.4.23": [ "RSK-01", + "RSK-06", + "RSK-06.2" + ], + "3.3.1.13(a)": [ "RSK-01.5" ], - "3.3.1(13)(b)": [ - "RSK-01", + "3.3.1.13(b)": [ "RSK-03", "RSK-04" ], - "3.3.1(13)(c)": [ - "RSK-01", + "3.3.1.13(c)": [ "RSK-06", "RSK-06.1", "RSK-06.2" ], - "3.3.3(20)": [ - "RSK-04" - ], - "3.4.2.(31)": [ - "OPS-01.1" - ], - "3.4.2(31)(a)": [ - "OPS-01.1" - ], - "3.4.2(31)(b)": [ - "OPS-01.1" - ], - "3.4.2(31)(c)": [ - "OPS-01.1" - ], - "3.4.2(31)(d)": [ - "OPS-01.1" - ], - "3.4.2(31)(e)": [ - "OPS-01.1" - ], - "3.4.2(31)(f)": [ - "OPS-01.1" + "3.3.3.20": [ + "RSK-08" ], - "3.4.2(31)(g)": [ + "3.4.2.31": [ "OPS-01.1" ], - "3.5(50)": [ + "3.4.4.36": [ "OPS-01.1" ], - "3.4.7(49)": [ + "3.4.7.49": [ "SAT-01", "SAT-02", "SAT-03" ], - "3.6.2(67)": [ + "3.6.2.67": [ "TDA-01" ], - "3.6.2(74)": [ - "TDA-01", - "TDA-02.3", - "TPM-01", - "TPM-03", - "TPM-03.1", - "TPM-04.1" - ], - "3.6.2(69)": [ - "TDA-02.3", - "TDA-02.4", - "TDA-02.7", - "TDA-04.1", - "TDA-05", - "TDA-06", - "TDA-06.2", - "TDA-06.5", - "TDA-07", - "TDA-08", - "TDA-09", - "TDA-15" - ], - "3.6.2(73)": [ + "3.6.2.73": [ "TDA-04", "TDA-20" ], - "3.6.2(72)": [ + "3.6.2.72": [ "TDA-07", "TDA-08" ], - "3.2.3(8)": [ + "3.2.3.8": [ "TPM-05", "TPM-05.2", "TPM-05.4" ], - "3.2.3(8)(a)": [ - "TPM-05", - "TPM-05.2", - "TPM-05.4" + "3.2.3.8(a)": [ + "TPM-05" ], - "3.2.3(8)(b)": [ + "3.2.3.8(b)": [ "TPM-05", - "TPM-05.2", - "TPM-05.4", "TPM-11" ], - "3.2.3(9)": [ + "3.2.3.9": [ "TPM-05.6", "TPM-08" ], - "3.3.3(21)": [ + "3.3.3.21": [ "THR-03", "VPM-01" ], - "3.4.4(36)(a)": [ + "3.4.4.36(a)": [ "VPM-01" ] } diff --git a/docs/api/crosswalks/emea-eu-gdpr-2016.json b/docs/api/crosswalks/emea-eu-gdpr-2016.json index 724f2418..e064f479 100644 --- a/docs/api/crosswalks/emea-eu-gdpr-2016.json +++ b/docs/api/crosswalks/emea-eu-gdpr-2016.json @@ -1,6 +1,6 @@ { "framework_id": "emea-eu-gdpr-2016", - "display_name": "EU General Data Protection Regulation (GDPR) (2016)", + "display_name": "EU - European Union General Data Protection Regulation (2016)", "scf_to_framework": { "total_mappings": 42, "mappings": { diff --git a/docs/api/crosswalks/emea-eu-nis2-2022.json b/docs/api/crosswalks/emea-eu-nis2-2022.json index 667982e7..36201720 100644 --- a/docs/api/crosswalks/emea-eu-nis2-2022.json +++ b/docs/api/crosswalks/emea-eu-nis2-2022.json @@ -1,6 +1,6 @@ { "framework_id": "emea-eu-nis2-2022", - "display_name": "EU NIS2 Directive (2022)", + "display_name": "EU - European Union Agency for Cybersecurity NIS2 Directive (EU) 2022/2555)", "scf_to_framework": { "total_mappings": 68, "mappings": { diff --git a/docs/api/crosswalks/emea-eu-nis2-annex-2024.json b/docs/api/crosswalks/emea-eu-nis2-annex-2024.json index 0c8b726b..5c8a1683 100644 --- a/docs/api/crosswalks/emea-eu-nis2-annex-2024.json +++ b/docs/api/crosswalks/emea-eu-nis2-annex-2024.json @@ -1,6 +1,6 @@ { "framework_id": "emea-eu-nis2-annex-2024", - "display_name": "EU NIS2 Annex (2024)", + "display_name": "EU - European Union Agency for Cybersecurity NIS2 Annex (2024)", "scf_to_framework": { "total_mappings": 223, "mappings": { diff --git a/docs/api/crosswalks/emea-eu-psd2-2015.json b/docs/api/crosswalks/emea-eu-psd2-2015.json new file mode 100644 index 00000000..aee42c6e --- /dev/null +++ b/docs/api/crosswalks/emea-eu-psd2-2015.json @@ -0,0 +1,130 @@ +{ + "framework_id": "emea-eu-psd2-2015", + "display_name": "EU - Second Payment Services Directive (PSD2) (2015)", + "scf_to_framework": { + "total_mappings": 11, + "mappings": { + "GOV-01": [ + "95(1)", + "97(3)" + ], + "GOV-01.4": [ + "98(1)", + "98(1)(a)", + "98(1)(b)", + "98(1)(c)", + "98(1)(d)", + "98(2)", + "98(3)", + "98(4)", + "98(5)" + ], + "GOV-17": [ + "96(6)" + ], + "CPL-01": [ + "97(3)" + ], + "HRS-06.1": [ + "24(1)" + ], + "IRO-01": [ + "95(1)" + ], + "IRO-10": [ + "96(1)" + ], + "IRO-10.5": [ + "96(1)" + ], + "PRI-01.11": [ + "94(1)", + "94(2)" + ], + "RSK-04": [ + "95(2)" + ], + "WEB-06": [ + "97(1)", + "97(1)(a)", + "97(1)(b)", + "97(1)(c)", + "97(2)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 22, + "mappings": { + "95(1)": [ + "GOV-01", + "IRO-01" + ], + "97(3)": [ + "GOV-01", + "CPL-01" + ], + "98(1)": [ + "GOV-01.4" + ], + "98(1)(a)": [ + "GOV-01.4" + ], + "98(1)(b)": [ + "GOV-01.4" + ], + "98(1)(c)": [ + "GOV-01.4" + ], + "98(1)(d)": [ + "GOV-01.4" + ], + "98(2)": [ + "GOV-01.4" + ], + "98(3)": [ + "GOV-01.4" + ], + "98(4)": [ + "GOV-01.4" + ], + "98(5)": [ + "GOV-01.4" + ], + "96(6)": [ + "GOV-17" + ], + "24(1)": [ + "HRS-06.1" + ], + "96(1)": [ + "IRO-10", + "IRO-10.5" + ], + "94(1)": [ + "PRI-01.11" + ], + "94(2)": [ + "PRI-01.11" + ], + "95(2)": [ + "RSK-04" + ], + "97(1)": [ + "WEB-06" + ], + "97(1)(a)": [ + "WEB-06" + ], + "97(1)(b)": [ + "WEB-06" + ], + "97(1)(c)": [ + "WEB-06" + ], + "97(2)": [ + "WEB-06" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-gbr-caf-4-0.json b/docs/api/crosswalks/emea-gbr-caf-4-0.json index 1a60f50d..ef114341 100644 --- a/docs/api/crosswalks/emea-gbr-caf-4-0.json +++ b/docs/api/crosswalks/emea-gbr-caf-4-0.json @@ -1,6 +1,6 @@ { "framework_id": "emea-gbr-caf-4-0", - "display_name": "UK - Cyber Assessment Framework (CAF) (v4.0)", + "display_name": "UK - Cyber Assessment Framework (CAF) v4.0", "scf_to_framework": { "total_mappings": 66, "mappings": { diff --git a/docs/api/crosswalks/emea-gbr-cap-1850-2020.json b/docs/api/crosswalks/emea-gbr-cap-1850-2020.json index fe29cb52..15273704 100644 --- a/docs/api/crosswalks/emea-gbr-cap-1850-2020.json +++ b/docs/api/crosswalks/emea-gbr-cap-1850-2020.json @@ -2,150 +2,120 @@ "framework_id": "emea-gbr-cap-1850-2020", "display_name": "UK - Cyber Assessment Framework for Aviation Guidance (CAP1850) (2020)", "scf_to_framework": { - "total_mappings": 43, + "total_mappings": 36, "mappings": { "GOV-01": [ - "A1" + "A1", + "B1" ], "GOV-02": [ - "A1", - "A5" + "A1" ], "GOV-15": [ - "A5" + "B4" ], "GOV-15.1": [ - "A5", - "A6" - ], - "GOV-15.2": [ - "A5", - "A6", "B4" ], - "GOV-15.3": [ - "A5", - "A6", + "GOV-15.2": [ "B4" ], - "GOV-15.4": [ - "A5" - ], - "GOV-15.5": [ - "A5" - ], - "AST-01": [ - "A3" - ], "AST-01.1": [ "A4" ], - "BCD-01": [ - "D1" - ], "BCD-02": [ "A4" ], - "BCD-05": [ - "D2" - ], - "CFG-01": [ - "B4" - ], - "CFG-02": [ - "B4" - ], - "CFG-02.5": [ - "B4" - ], "MON-01": [ "C1" ], - "MON-01.8": [ - "C1", - "C2" + "CRY-01": [ + "B3" ], - "MON-01.16": [ - "C1" + "CRY-03": [ + "B3" ], - "MON-02": [ - "C1", - "C2" + "CRY-05": [ + "B3" ], - "MON-02.2": [ - "C1", + "END-04": [ "C2" ], - "MON-02.3": [ - "C1", - "C2" + "IAC-01": [ + "B2" ], - "MON-16": [ - "C1", - "C2" + "IAC-01.2": [ + "B2" ], - "DCH-01": [ - "B3" + "IAC-15.1": [ + "B2" ], - "DCH-01.2": [ - "B3" + "IRO-01": [ + "D1" ], - "DCH-02": [ - "B3" + "IRO-02": [ + "D1" + ], + "IRO-04.3": [ + "D2" ], "IRO-13": [ "D2" ], - "RSK-01": [ + "IAO-01": [ "A2" ], - "RSK-03": [ + "IAO-01.1": [ "A2" ], - "RSK-04": [ + "IAO-02": [ "A2" ], - "RSK-09": [ - "A4" + "IAO-03": [ + "A2", + "A3", + "B1", + "B4" ], - "RSK-09.1": [ - "A4" + "IAO-03.2": [ + "A2", + "B1" ], - "SEA-01": [ - "B4", - "B5" + "IAO-06": [ + "A2" ], - "SEA-02": [ - "B4", - "B5" + "IAO-07": [ + "A2" + ], + "RSK-01": [ + "A2" ], - "SEA-03": [ - "B4", + "RSK-03": [ + "A2" + ], + "RSK-04": [ + "A2" + ], + "SEA-01.2": [ "B5" ], - "SAT-01": [ - "B6" + "SEA-01.3": [ + "B5" ], "SAT-02": [ "B6" ], - "TDA-06.1": [ - "A4" - ], - "TPM-01": [ - "A4" + "SAT-03": [ + "B6" ], "TPM-02": [ "A4" ], - "TPM-04": [ + "TPM-03": [ "A4" ], "TPM-04.1": [ "A4" - ], - "TPM-05.4": [ - "A4" ] } }, @@ -156,86 +126,70 @@ "GOV-01", "GOV-02" ], - "A5": [ - "GOV-02", - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5" - ], - "A6": [ - "GOV-15.1", - "GOV-15.2", - "GOV-15.3" + "B1": [ + "GOV-01", + "IAO-03", + "IAO-03.2" ], "B4": [ + "GOV-15", + "GOV-15.1", "GOV-15.2", - "GOV-15.3", - "CFG-01", - "CFG-02", - "CFG-02.5", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "A3": [ - "AST-01" + "IAO-03" ], "A4": [ "AST-01.1", "BCD-02", - "RSK-09", - "RSK-09.1", - "TDA-06.1", - "TPM-01", "TPM-02", - "TPM-04", - "TPM-04.1", - "TPM-05.4" - ], - "D1": [ - "BCD-01" - ], - "D2": [ - "BCD-05", - "IRO-13" + "TPM-03", + "TPM-04.1" ], "C1": [ - "MON-01", - "MON-01.8", - "MON-01.16", - "MON-02", - "MON-02.2", - "MON-02.3", - "MON-16" + "MON-01" + ], + "B3": [ + "CRY-01", + "CRY-03", + "CRY-05" ], "C2": [ - "MON-01.8", - "MON-02", - "MON-02.2", - "MON-02.3", - "MON-16" + "END-04" ], - "B3": [ - "DCH-01", - "DCH-01.2", - "DCH-02" + "B2": [ + "IAC-01", + "IAC-01.2", + "IAC-15.1" + ], + "D1": [ + "IRO-01", + "IRO-02" + ], + "D2": [ + "IRO-04.3", + "IRO-13" ], "A2": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-03", + "IAO-03.2", + "IAO-06", + "IAO-07", "RSK-01", "RSK-03", "RSK-04" ], + "A3": [ + "IAO-03" + ], "B5": [ - "SEA-01", - "SEA-02", - "SEA-03" + "SEA-01.2", + "SEA-01.3" ], "B6": [ - "SAT-01", - "SAT-02" + "SAT-02", + "SAT-03" ] } } diff --git a/docs/api/crosswalks/emea-gbr-cyber-essentials-requirements-3-3.json b/docs/api/crosswalks/emea-gbr-cyber-essentials-requirements-3-3.json index 8abfddd3..aaadac05 100644 --- a/docs/api/crosswalks/emea-gbr-cyber-essentials-requirements-3-3.json +++ b/docs/api/crosswalks/emea-gbr-cyber-essentials-requirements-3-3.json @@ -1,127 +1,211 @@ { "framework_id": "emea-gbr-cyber-essentials-requirements-3-3", - "display_name": "UK - Cyber Essentials (v3.3)", + "display_name": "UK - Cyber Essentials: Requirements for IT Infrastructure v3.3", "scf_to_framework": { - "total_mappings": 26, + "total_mappings": 27, "mappings": { - "AST-02.7": [ - "3" - ], - "CFG-01": [ + "AST-01": [ "2" ], - "CFG-02": [ - "2" + "AST-01.4": [ + "5-BP2-2" ], - "CFG-03.3": [ - "4" - ], - "CFG-04": [ - "3" - ], - "CFG-05": [ - "3" + "AST-02.7": [ + "3-BP1" ], - "END-01": [ - "4" + "CFG-02": [ + "2-BP3", + "2-BP4" ], - "END-02": [ - "4" + "CFG-03": [ + "2-BP3" ], - "END-03": [ - "3" + "CFG-03.3": [ + "5-BP2", + "5-BP2-1", + "5-BP2-2" ], "END-04": [ - "4" + "5", + "5-BP1" ], "END-04.1": [ - "4" + "5-BP1-1" + ], + "END-04.7": [ + "5-BP1-2", + "5-BP1-3" ], "END-05": [ "1" ], "IAC-01": [ - "2" + "4" ], - "IAC-02": [ - "2" + "IAC-01.2": [ + "2-BP5", + "4", + "4-BP2" ], "IAC-06": [ - "2" + "4-BP4" ], "IAC-07": [ - "3" + "4-BP6" ], - "IAC-08": [ - "3" + "IAC-10.8": [ + "2-BP2" ], - "IAC-09.5": [ - "3" + "IAC-15": [ + "2-BP1", + "4-BP1", + "4-BP3" ], - "IAC-10": [ - "2" + "IAC-15.1": [ + "2-BP6" ], - "IRO-15": [ - "4" + "IAC-15.3": [ + "4-BP3" ], - "NET-01": [ - "1" + "IAC-16": [ + "4-BP6" + ], + "IAC-16.4": [ + "4-BP5" + ], + "IAC-17": [ + "2-BP1" + ], + "IAC-21": [ + "2-BP1" ], "NET-03": [ "1" ], - "NET-03.6": [ - "4" - ], - "VPM-01": [ - "5" + "NET-18": [ + "5-BP1-4" ], - "VPM-02": [ - "5" + "TDA-17": [ + "3-BP2" ], "VPM-05": [ - "5" + "3", + "3-BP4", + "3-BP4-1", + "3-BP4-2", + "3-BP4-3" + ], + "VPM-05.4": [ + "3-BP3" ] } }, "framework_to_scf": { - "total_mappings": 5, + "total_mappings": 32, "mappings": { "1": [ "END-05", - "NET-01", "NET-03" ], "2": [ - "CFG-01", - "CFG-02", - "IAC-01", - "IAC-02", - "IAC-06", - "IAC-10" + "AST-01" ], "3": [ - "AST-02.7", - "CFG-04", - "CFG-05", - "END-03", - "IAC-07", - "IAC-08", - "IAC-09.5" + "VPM-05" ], "4": [ - "CFG-03.3", - "END-01", - "END-02", - "END-04", - "END-04.1", - "IRO-15", - "NET-03.6" + "IAC-01", + "IAC-01.2" ], "5": [ - "VPM-01", - "VPM-02", + "END-04" + ], + "5-BP2-2": [ + "AST-01.4", + "CFG-03.3" + ], + "3-BP1": [ + "AST-02.7" + ], + "2-BP3": [ + "CFG-02", + "CFG-03" + ], + "2-BP4": [ + "CFG-02" + ], + "5-BP2": [ + "CFG-03.3" + ], + "5-BP2-1": [ + "CFG-03.3" + ], + "5-BP1": [ + "END-04" + ], + "5-BP1-1": [ + "END-04.1" + ], + "5-BP1-2": [ + "END-04.7" + ], + "5-BP1-3": [ + "END-04.7" + ], + "2-BP5": [ + "IAC-01.2" + ], + "4-BP2": [ + "IAC-01.2" + ], + "4-BP4": [ + "IAC-06" + ], + "4-BP6": [ + "IAC-07", + "IAC-16" + ], + "2-BP2": [ + "IAC-10.8" + ], + "2-BP1": [ + "IAC-15", + "IAC-17", + "IAC-21" + ], + "4-BP1": [ + "IAC-15" + ], + "4-BP3": [ + "IAC-15", + "IAC-15.3" + ], + "2-BP6": [ + "IAC-15.1" + ], + "4-BP5": [ + "IAC-16.4" + ], + "5-BP1-4": [ + "NET-18" + ], + "3-BP2": [ + "TDA-17" + ], + "3-BP4": [ + "VPM-05" + ], + "3-BP4-1": [ + "VPM-05" + ], + "3-BP4-2": [ + "VPM-05" + ], + "3-BP4-3": [ "VPM-05" + ], + "3-BP3": [ + "VPM-05.4" ] } } diff --git a/docs/api/crosswalks/emea-gbr-def-stan-05-138-2024.json b/docs/api/crosswalks/emea-gbr-def-stan-05-138-2024.json index 67738e11..b271dd25 100644 --- a/docs/api/crosswalks/emea-gbr-def-stan-05-138-2024.json +++ b/docs/api/crosswalks/emea-gbr-def-stan-05-138-2024.json @@ -1,6 +1,6 @@ { "framework_id": "emea-gbr-def-stan-05-138-2024", - "display_name": "UK - Defstan 05-138 (2024)", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024)", "scf_to_framework": { "total_mappings": 213, "mappings": { diff --git a/docs/api/crosswalks/emea-gbr-def-stan-05-138-l0-2024.json b/docs/api/crosswalks/emea-gbr-def-stan-05-138-l0-2024.json index 572fc419..939f9c1a 100644 --- a/docs/api/crosswalks/emea-gbr-def-stan-05-138-l0-2024.json +++ b/docs/api/crosswalks/emea-gbr-def-stan-05-138-l0-2024.json @@ -1,6 +1,6 @@ { "framework_id": "emea-gbr-def-stan-05-138-l0-2024", - "display_name": "UK - Defstan 05-138 (2024) - L0", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L0", "scf_to_framework": { "total_mappings": 2, "mappings": { diff --git a/docs/api/crosswalks/emea-gbr-def-stan-05-138-l1-2024.json b/docs/api/crosswalks/emea-gbr-def-stan-05-138-l1-2024.json index 9a783086..76ae1923 100644 --- a/docs/api/crosswalks/emea-gbr-def-stan-05-138-l1-2024.json +++ b/docs/api/crosswalks/emea-gbr-def-stan-05-138-l1-2024.json @@ -1,6 +1,6 @@ { "framework_id": "emea-gbr-def-stan-05-138-l1-2024", - "display_name": "UK - Defstan 05-138 (2024) - L1", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L1", "scf_to_framework": { "total_mappings": 159, "mappings": { diff --git a/docs/api/crosswalks/emea-gbr-def-stan-05-138-l2-2024.json b/docs/api/crosswalks/emea-gbr-def-stan-05-138-l2-2024.json index 83f1d2ba..77878307 100644 --- a/docs/api/crosswalks/emea-gbr-def-stan-05-138-l2-2024.json +++ b/docs/api/crosswalks/emea-gbr-def-stan-05-138-l2-2024.json @@ -1,6 +1,6 @@ { "framework_id": "emea-gbr-def-stan-05-138-l2-2024", - "display_name": "UK - Defstan 05-138 (2024) - L2", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L2", "scf_to_framework": { "total_mappings": 206, "mappings": { diff --git a/docs/api/crosswalks/emea-gbr-def-stan-05-138-l3-2024.json b/docs/api/crosswalks/emea-gbr-def-stan-05-138-l3-2024.json index 90290ca5..7d2b58f8 100644 --- a/docs/api/crosswalks/emea-gbr-def-stan-05-138-l3-2024.json +++ b/docs/api/crosswalks/emea-gbr-def-stan-05-138-l3-2024.json @@ -1,6 +1,6 @@ { "framework_id": "emea-gbr-def-stan-05-138-l3-2024", - "display_name": "UK - Defstan 05-138 (2024) - L3", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L3", "scf_to_framework": { "total_mappings": 212, "mappings": { diff --git a/docs/api/crosswalks/emea-gbr-dpa-1998.json b/docs/api/crosswalks/emea-gbr-dpa-1998.json deleted file mode 100644 index 6358fd9a..00000000 --- a/docs/api/crosswalks/emea-gbr-dpa-1998.json +++ /dev/null @@ -1,72 +0,0 @@ -{ - "framework_id": "emea-gbr-dpa-1998", - "display_name": "UK - Data Protection Act (DPA) (1998)", - "scf_to_framework": { - "total_mappings": 10, - "mappings": { - "DCH-08": [ - "Chapter29-Schedule1-Part1-Principle 5" - ], - "DCH-18": [ - "Chapter29-Schedule1-Part1-Principle 3 & 5" - ], - "DCH-22": [ - "Chapter29-Schedule1-Part1-Principle 1" - ], - "IRO-04.1": [ - "Chapter29-Schedule1-Part1-Principles 7" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-01.2": [ - "Chapter29-Schedule1-Part1-Principles 8" - ], - "PRI-02": [ - "Chapter29-Schedule1-Part1-Principles 8" - ], - "PRI-05": [ - "Chapter29-Schedule1-Part1-Principle 5" - ], - "PRI-05.1": [ - "Chapter29-Schedule1-Part1-Principle 3" - ], - "PRI-05.4": [ - "Chapter29-Schedule1-Part1-Principle 3" - ] - } - }, - "framework_to_scf": { - "total_mappings": 8, - "mappings": { - "Chapter29-Schedule1-Part1-Principle 5": [ - "DCH-08", - "PRI-05" - ], - "Chapter29-Schedule1-Part1-Principle 3 & 5": [ - "DCH-18" - ], - "Chapter29-Schedule1-Part1-Principle 1": [ - "DCH-22" - ], - "Chapter29-Schedule1-Part1-Principles 7": [ - "IRO-04.1" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ], - "Chapter29-Schedule1-Part1-Principles 8": [ - "PRI-01.2", - "PRI-02" - ], - "Chapter29-Schedule1-Part1-Principle 3": [ - "PRI-05.1", - "PRI-05.4" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-gbr-dpa-2018.json b/docs/api/crosswalks/emea-gbr-dpa-2018.json new file mode 100644 index 00000000..3e051a93 --- /dev/null +++ b/docs/api/crosswalks/emea-gbr-dpa-2018.json @@ -0,0 +1,1460 @@ +{ + "framework_id": "emea-gbr-dpa-2018", + "display_name": "UK - Data Protection Act (DPA) (2018)", + "scf_to_framework": { + "total_mappings": 25, + "mappings": { + "IRO-10": [ + "Section 67(1)", + "Section 67(1)(a)", + "Section 67(1)(b)", + "Section 67(2)", + "Section 67(3)", + "Section 67(4)", + "Section 67(4)(a)", + "Section 67(4)(b)", + "Section 67(4)(c)", + "Section 67(4)(d)", + "Section 67(5)", + "Section 67(6)", + "Section 67(6)(a)", + "Section 67(6)(b)", + "Section 67(6)(c)", + "Section 67(7)", + "Section 67(9)", + "Section 68(1)", + "Section 68(2)", + "Section 68(2)(a)", + "Section 68(2)(b)", + "Section 68(2)(c)", + "Section 68(2)(d)", + "Section 68(3)", + "Section 68(3)(a)", + "Section 68(3)(b)", + "Section 68(3)(c)", + "Section 68(4)", + "Section 68(5)", + "Section 68(6)", + "Section 68(6)(a)", + "Section 68(6)(b)", + "Section 68(7)", + "Section 68(7)(a)", + "Section 68(7)(b)", + "Section 68(7)(c)", + "Section 68(7)(e)", + "Section 68(8)", + "Section 68(9)" + ], + "PRI-01.4": [ + "Section 69(1)", + "Section 69(2)", + "Section 69(2)(a)", + "Section 69(2)(b)", + "Section 69(3)", + "Section 70(1)", + "Section 70(2)", + "Section 70(2)(a)", + "Section 70(2)(b)", + "Section 70(3)", + "Section 70(3)(a)", + "Section 70(3)(b)", + "Section 70(3)(c)", + "Section 70(4)", + "Section 70(4)(a)", + "Section 70(4)(b)", + "Section 70(5)", + "Section 71(1)", + "Section 71(1)(a)", + "Section 71(1)(b)", + "Section 71(1)(c)", + "Section 71(1)(d)", + "Section 71(1)(e)", + "Section 71(1)(f)", + "Section 71(2)", + "Section 71(2)(a)", + "Section 71(2)(b)", + "Section 71(2)(c)", + "Section 71(2)(d)", + "Section 71(3)" + ], + "PRI-01.5": [ + "Section 78", + "Section 78(1)", + "Section 78(1)(a)", + "Section 78(1)(b)", + "Section 78(1)(b)(i)", + "Section 78(1)(b)(ii)", + "Section 78(1A)", + "Section 78(1A)(a)", + "Section 78(1A)(b)", + "Section 78(2)", + "Section 78(3)", + "Section 78(3)(a)", + "Section 78(3)(b)", + "Section 78(3)(c)", + "Section 78(4)", + "Section 78(5)", + "Section 78(5)(a)", + "Section 78(5)(b)", + "Section 78(6)", + "Section 78(7)", + "Section 78(7)(a)", + "Section 78(7)(b)" + ], + "PRI-01.6": [ + "Section 55(3)", + "Section 55(3)(a)", + "Section 55(3)(b)", + "Section 55(3)(c)", + "Section 55(3)(d)", + "Section 56(1)", + "Section 56(2)", + "Section 56(3)", + "Section 57(1)", + "Section 57(1)(a)", + "Section 57(1)(b)", + "Section 57(2)", + "Section 57(3)", + "Section 57(4)", + "Section 57(4)(a)", + "Section 57(4)(b)", + "Section 57(4)(c)", + "Section 57(4)(d)", + "Section 57(5)", + "Section 66(1)", + "Section 66(2)", + "Section 66(2)(a)", + "Section 66(2)(b)", + "Section 66(2)(c)", + "Section 66(2)(d)", + "Section 66(3)" + ], + "PRI-01.11": [ + "Section 45(4)", + "Section 45(4)(a)", + "Section 45(4)(b)", + "Section 45(4)(c)", + "Section 45(4)(e)", + "Section 47(2)" + ], + "PRI-02": [ + "Section 44(1)", + "Section 44(1)(a)", + "Section 44(1)(b)", + "Section 44(1)(c)", + "Section 44(1)(d)", + "Section 44(1)(d)(i)", + "Section 44(1)(d)(ii)", + "Section 44(1)(d)(iii)", + "Section 44(1)(e)", + "Section 44(2)", + "Section 44(2)(b)", + "Section 44(2)(c)", + "Section 44(2)(d)", + "Section 44(3)", + "Section 69(4)" + ], + "PRI-03.4": [ + "Section 47(4)" + ], + "PRI-04.1": [ + "Section 44(2)(a)" + ], + "PRI-05.2": [ + "Section 46(1)", + "Section 47(3)" + ], + "PRI-05.4": [ + "Section 44(4)", + "Section 44(4)(a)", + "Section 44(4)(b)", + "Section 44(4)(c)", + "Section 44(4)(e)", + "Section 47(4)" + ], + "PRI-06": [ + "Section 45(1)", + "Section 45(1)(a)", + "Section 45(1)(b)", + "Section 45(2)", + "Section 45(2)(a)", + "Section 45(2)(b)", + "Section 45(2)(c)", + "Section 45(2)(d)", + "Section 45(2)(e)", + "Section 45(2)(e)(i)", + "Section 45(2)(e)(ii)", + "Section 45(2)(f)", + "Section 45(2)(g)", + "Section 45(2A)" + ], + "PRI-06.1": [ + "Section 46(1)", + "Section 46(2)", + "Section 46(3)", + "Section 46(4)" + ], + "PRI-06.2": [ + "Section 48(1)", + "Section 48(1)(a)", + "Section 48(1)(b)", + "Section 48(1)(b)(i)", + "Section 48(1)(b)(ii)", + "Section 48(1)(b)(iii)", + "Section 48(1)(b)(iv)", + "Section 48(2)", + "Section 48(2)(a)", + "Section 48(2)(b)", + "Section 48(3)", + "Section 48(3)(a)", + "Section 48(3)(b)", + "Section 48(3)(c)", + "Section 48(3)(e)", + "Section 48(4)", + "Section 48(4)(a)", + "Section 48(4)(b)", + "Section 48(4)(c)", + "Section 48(4)(d)", + "Section 48(5)", + "Section 48(6)", + "Section 48(6)(a)", + "Section 48(6)(b)", + "Section 48(7)", + "Section 48(9)", + "Section 48(9)(a)", + "Section 48(9)(b)", + "Section 48(10)" + ], + "PRI-06.4": [ + "Section 45(3)", + "Section 45(3)(a)", + "Section 45(3)(b)", + "Section 45(5)", + "Section 45(5)(a)", + "Section 45(5)(b)", + "Section 45(5)(c)", + "Section 45(5)(d)", + "Section 45(5)(e)", + "Section 52(6)", + "Section 53(6)", + "Section 53(6)(a)", + "Section 53(6)(b)", + "Section 53(7)", + "Section 53(7)(a)", + "Section 53(7)(b)" + ], + "PRI-06.5": [ + "Section 47(1)", + "Section 47(1)(a)", + "Section 47(1)(b)" + ], + "PRI-06.7": [ + "Section 52(1)", + "Section 52(2)", + "Section 52(3)", + "Section 52(5)" + ], + "PRI-06.8": [ + "Section 52(4)", + "Section 52(4)(a)", + "Section 52(4)(b)" + ], + "PRI-07.1": [ + "Section 59(1)", + "Section 59(2)", + "Section 59(2)(a)", + "Section 59(2)(b)", + "Section 59(3)", + "Section 59(4)", + "Section 59(5)", + "Section 59(5)(a)", + "Section 59(5)(b)", + "Section 59(5)(c)", + "Section 59(5)(d)", + "Section 59(6)", + "Section 59(6)(a)", + "Section 59(6)(b)", + "Section 59(6)(c)", + "Section 59(6)(d)", + "Section 59(6)(d)(i)", + "Section 59(6)(d)(ii)", + "Section 59(6)(e)", + "Section 59(6)(f)", + "Section 59(7)", + "Section 59(7A)", + "Section 59(8)", + "Section 60", + "Section 60(a)", + "Section 60(b)", + "Section 63" + ], + "PRI-07.2": [ + "Section 58(1)", + "Section 58(2)", + "Section 58(3)" + ], + "PRI-07.4": [ + "Section 53(1)", + "Section 53(1)(a)", + "Section 53(1)(b)", + "Section 53(2)", + "Section 53(3)", + "Section 53(4)", + "Section 53(4A)", + "Section 53(4A)(a)", + "Section 53(4A)(b)", + "Section 53(5)" + ], + "PRI-14": [ + "Section 61(1)", + "Section 61(2)", + "Section 61(2)(a)", + "Section 61(2)(b)", + "Section 61(2)(c)", + "Section 61(2)(d)", + "Section 61(2)(e)", + "Section 61(2)(f)", + "Section 61(2)(f)(i)", + "Section 61(2)(f)(ii)", + "Section 61(2)(g)", + "Section 61(2)(h)", + "Section 61(2)(h)(i)", + "Section 61(2)(j)", + "Section 61(2)(k)", + "Section 61(3)", + "Section 61(4)", + "Section 61(4)(a)", + "Section 61(4)(b)", + "Section 61(4)(c)", + "Section 61(4)(d)", + "Section 61(4)(e)", + "Section 61(4)(f)", + "Section 61(5)", + "Section 62(1)", + "Section 62(1)(a)", + "Section 62(1)(b)", + "Section 62(1)(c)", + "Section 62(1)(d)", + "Section 62(1)(e)", + "Section 62(1)(f)", + "Section 62(2)", + "Section 62(2)(a)", + "Section 62(2)(b)", + "Section 62(3)", + "Section 62(3)(a)", + "Section 62(3)(b)", + "Section 62(3)(b)(i)", + "Section 62(3)(b)(ii)", + "Section 62(4)", + "Section 62(4)(a)", + "Section 62(4)(b)", + "Section 62(4)(c)", + "Section 62(4)(d)", + "Section 62(5)" + ], + "PRI-17": [ + "Section 44(5)", + "Section 44(5)(a)", + "Section 44(5)(b)", + "Section 44(5)(c)", + "Section 44(5)(d)", + "Section 44(5)(e)", + "Section 44(6)" + ], + "PRI-17.3": [ + "Section 44(7)(a)", + "Section 44(7)(b)", + "Section 45(7)(a)", + "Section 45(7)(b)" + ], + "PRI-19": [ + "Section 50(1)", + "Section 50(1)(a)", + "Section 50(1)(b)", + "Section 50(1)(b)(i)", + "Section 50(1)(b)(ii)", + "Section 50(2)", + "Section 50C(1)", + "Section 50C(1)(a)", + "Section 50C(1)(b)", + "Section 50C(2)", + "Section 50C(2)(a)", + "Section 50C(2)(b)", + "Section 50C(2)(c)", + "Section 50C(2)(d)", + "Section 50C(3)", + "Section 50C(3)(a)", + "Section 50C(3)(b)", + "Section 50C(3)(c)", + "Section 50C(4)", + "Section 50C(4)(a)", + "Section 50C(4)(b)", + "Section 50C(4)(c)", + "Section 50C(4)(d)", + "Section 50C(4)(e)", + "Section 50C(5)" + ], + "RSK-10": [ + "Section 64(1)", + "Section 64(2)", + "Section 64(3)", + "Section 64(3)(a)", + "Section 64(3)(b)", + "Section 64(3)(c)", + "Section 64(3)(d)", + "Section 64(4)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 348, + "mappings": { + "Section 67(1)": [ + "IRO-10" + ], + "Section 67(1)(a)": [ + "IRO-10" + ], + "Section 67(1)(b)": [ + "IRO-10" + ], + "Section 67(2)": [ + "IRO-10" + ], + "Section 67(3)": [ + "IRO-10" + ], + "Section 67(4)": [ + "IRO-10" + ], + "Section 67(4)(a)": [ + "IRO-10" + ], + "Section 67(4)(b)": [ + "IRO-10" + ], + "Section 67(4)(c)": [ + "IRO-10" + ], + "Section 67(4)(d)": [ + "IRO-10" + ], + "Section 67(5)": [ + "IRO-10" + ], + "Section 67(6)": [ + "IRO-10" + ], + "Section 67(6)(a)": [ + "IRO-10" + ], + "Section 67(6)(b)": [ + "IRO-10" + ], + "Section 67(6)(c)": [ + "IRO-10" + ], + "Section 67(7)": [ + "IRO-10" + ], + "Section 67(9)": [ + "IRO-10" + ], + "Section 68(1)": [ + "IRO-10" + ], + "Section 68(2)": [ + "IRO-10" + ], + "Section 68(2)(a)": [ + "IRO-10" + ], + "Section 68(2)(b)": [ + "IRO-10" + ], + "Section 68(2)(c)": [ + "IRO-10" + ], + "Section 68(2)(d)": [ + "IRO-10" + ], + "Section 68(3)": [ + "IRO-10" + ], + "Section 68(3)(a)": [ + "IRO-10" + ], + "Section 68(3)(b)": [ + "IRO-10" + ], + "Section 68(3)(c)": [ + "IRO-10" + ], + "Section 68(4)": [ + "IRO-10" + ], + "Section 68(5)": [ + "IRO-10" + ], + "Section 68(6)": [ + "IRO-10" + ], + "Section 68(6)(a)": [ + "IRO-10" + ], + "Section 68(6)(b)": [ + "IRO-10" + ], + "Section 68(7)": [ + "IRO-10" + ], + "Section 68(7)(a)": [ + "IRO-10" + ], + "Section 68(7)(b)": [ + "IRO-10" + ], + "Section 68(7)(c)": [ + "IRO-10" + ], + "Section 68(7)(e)": [ + "IRO-10" + ], + "Section 68(8)": [ + "IRO-10" + ], + "Section 68(9)": [ + "IRO-10" + ], + "Section 69(1)": [ + "PRI-01.4" + ], + "Section 69(2)": [ + "PRI-01.4" + ], + "Section 69(2)(a)": [ + "PRI-01.4" + ], + "Section 69(2)(b)": [ + "PRI-01.4" + ], + "Section 69(3)": [ + "PRI-01.4" + ], + "Section 70(1)": [ + "PRI-01.4" + ], + "Section 70(2)": [ + "PRI-01.4" + ], + "Section 70(2)(a)": [ + "PRI-01.4" + ], + "Section 70(2)(b)": [ + "PRI-01.4" + ], + "Section 70(3)": [ + "PRI-01.4" + ], + "Section 70(3)(a)": [ + "PRI-01.4" + ], + "Section 70(3)(b)": [ + "PRI-01.4" + ], + "Section 70(3)(c)": [ + "PRI-01.4" + ], + "Section 70(4)": [ + "PRI-01.4" + ], + "Section 70(4)(a)": [ + "PRI-01.4" + ], + "Section 70(4)(b)": [ + "PRI-01.4" + ], + "Section 70(5)": [ + "PRI-01.4" + ], + "Section 71(1)": [ + "PRI-01.4" + ], + "Section 71(1)(a)": [ + "PRI-01.4" + ], + "Section 71(1)(b)": [ + "PRI-01.4" + ], + "Section 71(1)(c)": [ + "PRI-01.4" + ], + "Section 71(1)(d)": [ + "PRI-01.4" + ], + "Section 71(1)(e)": [ + "PRI-01.4" + ], + "Section 71(1)(f)": [ + "PRI-01.4" + ], + "Section 71(2)": [ + "PRI-01.4" + ], + "Section 71(2)(a)": [ + "PRI-01.4" + ], + "Section 71(2)(b)": [ + "PRI-01.4" + ], + "Section 71(2)(c)": [ + "PRI-01.4" + ], + "Section 71(2)(d)": [ + "PRI-01.4" + ], + "Section 71(3)": [ + "PRI-01.4" + ], + "Section 78": [ + "PRI-01.5" + ], + "Section 78(1)": [ + "PRI-01.5" + ], + "Section 78(1)(a)": [ + "PRI-01.5" + ], + "Section 78(1)(b)": [ + "PRI-01.5" + ], + "Section 78(1)(b)(i)": [ + "PRI-01.5" + ], + "Section 78(1)(b)(ii)": [ + "PRI-01.5" + ], + "Section 78(1A)": [ + "PRI-01.5" + ], + "Section 78(1A)(a)": [ + "PRI-01.5" + ], + "Section 78(1A)(b)": [ + "PRI-01.5" + ], + "Section 78(2)": [ + "PRI-01.5" + ], + "Section 78(3)": [ + "PRI-01.5" + ], + "Section 78(3)(a)": [ + "PRI-01.5" + ], + "Section 78(3)(b)": [ + "PRI-01.5" + ], + "Section 78(3)(c)": [ + "PRI-01.5" + ], + "Section 78(4)": [ + "PRI-01.5" + ], + "Section 78(5)": [ + "PRI-01.5" + ], + "Section 78(5)(a)": [ + "PRI-01.5" + ], + "Section 78(5)(b)": [ + "PRI-01.5" + ], + "Section 78(6)": [ + "PRI-01.5" + ], + "Section 78(7)": [ + "PRI-01.5" + ], + "Section 78(7)(a)": [ + "PRI-01.5" + ], + "Section 78(7)(b)": [ + "PRI-01.5" + ], + "Section 55(3)": [ + "PRI-01.6" + ], + "Section 55(3)(a)": [ + "PRI-01.6" + ], + "Section 55(3)(b)": [ + "PRI-01.6" + ], + "Section 55(3)(c)": [ + "PRI-01.6" + ], + "Section 55(3)(d)": [ + "PRI-01.6" + ], + "Section 56(1)": [ + "PRI-01.6" + ], + "Section 56(2)": [ + "PRI-01.6" + ], + "Section 56(3)": [ + "PRI-01.6" + ], + "Section 57(1)": [ + "PRI-01.6" + ], + "Section 57(1)(a)": [ + "PRI-01.6" + ], + "Section 57(1)(b)": [ + "PRI-01.6" + ], + "Section 57(2)": [ + "PRI-01.6" + ], + "Section 57(3)": [ + "PRI-01.6" + ], + "Section 57(4)": [ + "PRI-01.6" + ], + "Section 57(4)(a)": [ + "PRI-01.6" + ], + "Section 57(4)(b)": [ + "PRI-01.6" + ], + "Section 57(4)(c)": [ + "PRI-01.6" + ], + "Section 57(4)(d)": [ + "PRI-01.6" + ], + "Section 57(5)": [ + "PRI-01.6" + ], + "Section 66(1)": [ + "PRI-01.6" + ], + "Section 66(2)": [ + "PRI-01.6" + ], + "Section 66(2)(a)": [ + "PRI-01.6" + ], + "Section 66(2)(b)": [ + "PRI-01.6" + ], + "Section 66(2)(c)": [ + "PRI-01.6" + ], + "Section 66(2)(d)": [ + "PRI-01.6" + ], + "Section 66(3)": [ + "PRI-01.6" + ], + "Section 45(4)": [ + "PRI-01.11" + ], + "Section 45(4)(a)": [ + "PRI-01.11" + ], + "Section 45(4)(b)": [ + "PRI-01.11" + ], + "Section 45(4)(c)": [ + "PRI-01.11" + ], + "Section 45(4)(e)": [ + "PRI-01.11" + ], + "Section 47(2)": [ + "PRI-01.11" + ], + "Section 44(1)": [ + "PRI-02" + ], + "Section 44(1)(a)": [ + "PRI-02" + ], + "Section 44(1)(b)": [ + "PRI-02" + ], + "Section 44(1)(c)": [ + "PRI-02" + ], + "Section 44(1)(d)": [ + "PRI-02" + ], + "Section 44(1)(d)(i)": [ + "PRI-02" + ], + "Section 44(1)(d)(ii)": [ + "PRI-02" + ], + "Section 44(1)(d)(iii)": [ + "PRI-02" + ], + "Section 44(1)(e)": [ + "PRI-02" + ], + "Section 44(2)": [ + "PRI-02" + ], + "Section 44(2)(b)": [ + "PRI-02" + ], + "Section 44(2)(c)": [ + "PRI-02" + ], + "Section 44(2)(d)": [ + "PRI-02" + ], + "Section 44(3)": [ + "PRI-02" + ], + "Section 69(4)": [ + "PRI-02" + ], + "Section 47(4)": [ + "PRI-03.4", + "PRI-05.4" + ], + "Section 44(2)(a)": [ + "PRI-04.1" + ], + "Section 46(1)": [ + "PRI-05.2", + "PRI-06.1" + ], + "Section 47(3)": [ + "PRI-05.2" + ], + "Section 44(4)": [ + "PRI-05.4" + ], + "Section 44(4)(a)": [ + "PRI-05.4" + ], + "Section 44(4)(b)": [ + "PRI-05.4" + ], + "Section 44(4)(c)": [ + "PRI-05.4" + ], + "Section 44(4)(e)": [ + "PRI-05.4" + ], + "Section 45(1)": [ + "PRI-06" + ], + "Section 45(1)(a)": [ + "PRI-06" + ], + "Section 45(1)(b)": [ + "PRI-06" + ], + "Section 45(2)": [ + "PRI-06" + ], + "Section 45(2)(a)": [ + "PRI-06" + ], + "Section 45(2)(b)": [ + "PRI-06" + ], + "Section 45(2)(c)": [ + "PRI-06" + ], + "Section 45(2)(d)": [ + "PRI-06" + ], + "Section 45(2)(e)": [ + "PRI-06" + ], + "Section 45(2)(e)(i)": [ + "PRI-06" + ], + "Section 45(2)(e)(ii)": [ + "PRI-06" + ], + "Section 45(2)(f)": [ + "PRI-06" + ], + "Section 45(2)(g)": [ + "PRI-06" + ], + "Section 45(2A)": [ + "PRI-06" + ], + "Section 46(2)": [ + "PRI-06.1" + ], + "Section 46(3)": [ + "PRI-06.1" + ], + "Section 46(4)": [ + "PRI-06.1" + ], + "Section 48(1)": [ + "PRI-06.2" + ], + "Section 48(1)(a)": [ + "PRI-06.2" + ], + "Section 48(1)(b)": [ + "PRI-06.2" + ], + "Section 48(1)(b)(i)": [ + "PRI-06.2" + ], + "Section 48(1)(b)(ii)": [ + "PRI-06.2" + ], + "Section 48(1)(b)(iii)": [ + "PRI-06.2" + ], + "Section 48(1)(b)(iv)": [ + "PRI-06.2" + ], + "Section 48(2)": [ + "PRI-06.2" + ], + "Section 48(2)(a)": [ + "PRI-06.2" + ], + "Section 48(2)(b)": [ + "PRI-06.2" + ], + "Section 48(3)": [ + "PRI-06.2" + ], + "Section 48(3)(a)": [ + "PRI-06.2" + ], + "Section 48(3)(b)": [ + "PRI-06.2" + ], + "Section 48(3)(c)": [ + "PRI-06.2" + ], + "Section 48(3)(e)": [ + "PRI-06.2" + ], + "Section 48(4)": [ + "PRI-06.2" + ], + "Section 48(4)(a)": [ + "PRI-06.2" + ], + "Section 48(4)(b)": [ + "PRI-06.2" + ], + "Section 48(4)(c)": [ + "PRI-06.2" + ], + "Section 48(4)(d)": [ + "PRI-06.2" + ], + "Section 48(5)": [ + "PRI-06.2" + ], + "Section 48(6)": [ + "PRI-06.2" + ], + "Section 48(6)(a)": [ + "PRI-06.2" + ], + "Section 48(6)(b)": [ + "PRI-06.2" + ], + "Section 48(7)": [ + "PRI-06.2" + ], + "Section 48(9)": [ + "PRI-06.2" + ], + "Section 48(9)(a)": [ + "PRI-06.2" + ], + "Section 48(9)(b)": [ + "PRI-06.2" + ], + "Section 48(10)": [ + "PRI-06.2" + ], + "Section 45(3)": [ + "PRI-06.4" + ], + "Section 45(3)(a)": [ + "PRI-06.4" + ], + "Section 45(3)(b)": [ + "PRI-06.4" + ], + "Section 45(5)": [ + "PRI-06.4" + ], + "Section 45(5)(a)": [ + "PRI-06.4" + ], + "Section 45(5)(b)": [ + "PRI-06.4" + ], + "Section 45(5)(c)": [ + "PRI-06.4" + ], + "Section 45(5)(d)": [ + "PRI-06.4" + ], + "Section 45(5)(e)": [ + "PRI-06.4" + ], + "Section 52(6)": [ + "PRI-06.4" + ], + "Section 53(6)": [ + "PRI-06.4" + ], + "Section 53(6)(a)": [ + "PRI-06.4" + ], + "Section 53(6)(b)": [ + "PRI-06.4" + ], + "Section 53(7)": [ + "PRI-06.4" + ], + "Section 53(7)(a)": [ + "PRI-06.4" + ], + "Section 53(7)(b)": [ + "PRI-06.4" + ], + "Section 47(1)": [ + "PRI-06.5" + ], + "Section 47(1)(a)": [ + "PRI-06.5" + ], + "Section 47(1)(b)": [ + "PRI-06.5" + ], + "Section 52(1)": [ + "PRI-06.7" + ], + "Section 52(2)": [ + "PRI-06.7" + ], + "Section 52(3)": [ + "PRI-06.7" + ], + "Section 52(5)": [ + "PRI-06.7" + ], + "Section 52(4)": [ + "PRI-06.8" + ], + "Section 52(4)(a)": [ + "PRI-06.8" + ], + "Section 52(4)(b)": [ + "PRI-06.8" + ], + "Section 59(1)": [ + "PRI-07.1" + ], + "Section 59(2)": [ + "PRI-07.1" + ], + "Section 59(2)(a)": [ + "PRI-07.1" + ], + "Section 59(2)(b)": [ + "PRI-07.1" + ], + "Section 59(3)": [ + "PRI-07.1" + ], + "Section 59(4)": [ + "PRI-07.1" + ], + "Section 59(5)": [ + "PRI-07.1" + ], + "Section 59(5)(a)": [ + "PRI-07.1" + ], + "Section 59(5)(b)": [ + "PRI-07.1" + ], + "Section 59(5)(c)": [ + "PRI-07.1" + ], + "Section 59(5)(d)": [ + "PRI-07.1" + ], + "Section 59(6)": [ + "PRI-07.1" + ], + "Section 59(6)(a)": [ + "PRI-07.1" + ], + "Section 59(6)(b)": [ + "PRI-07.1" + ], + "Section 59(6)(c)": [ + "PRI-07.1" + ], + "Section 59(6)(d)": [ + "PRI-07.1" + ], + "Section 59(6)(d)(i)": [ + "PRI-07.1" + ], + "Section 59(6)(d)(ii)": [ + "PRI-07.1" + ], + "Section 59(6)(e)": [ + "PRI-07.1" + ], + "Section 59(6)(f)": [ + "PRI-07.1" + ], + "Section 59(7)": [ + "PRI-07.1" + ], + "Section 59(7A)": [ + "PRI-07.1" + ], + "Section 59(8)": [ + "PRI-07.1" + ], + "Section 60": [ + "PRI-07.1" + ], + "Section 60(a)": [ + "PRI-07.1" + ], + "Section 60(b)": [ + "PRI-07.1" + ], + "Section 63": [ + "PRI-07.1" + ], + "Section 58(1)": [ + "PRI-07.2" + ], + "Section 58(2)": [ + "PRI-07.2" + ], + "Section 58(3)": [ + "PRI-07.2" + ], + "Section 53(1)": [ + "PRI-07.4" + ], + "Section 53(1)(a)": [ + "PRI-07.4" + ], + "Section 53(1)(b)": [ + "PRI-07.4" + ], + "Section 53(2)": [ + "PRI-07.4" + ], + "Section 53(3)": [ + "PRI-07.4" + ], + "Section 53(4)": [ + "PRI-07.4" + ], + "Section 53(4A)": [ + "PRI-07.4" + ], + "Section 53(4A)(a)": [ + "PRI-07.4" + ], + "Section 53(4A)(b)": [ + "PRI-07.4" + ], + "Section 53(5)": [ + "PRI-07.4" + ], + "Section 61(1)": [ + "PRI-14" + ], + "Section 61(2)": [ + "PRI-14" + ], + "Section 61(2)(a)": [ + "PRI-14" + ], + "Section 61(2)(b)": [ + "PRI-14" + ], + "Section 61(2)(c)": [ + "PRI-14" + ], + "Section 61(2)(d)": [ + "PRI-14" + ], + "Section 61(2)(e)": [ + "PRI-14" + ], + "Section 61(2)(f)": [ + "PRI-14" + ], + "Section 61(2)(f)(i)": [ + "PRI-14" + ], + "Section 61(2)(f)(ii)": [ + "PRI-14" + ], + "Section 61(2)(g)": [ + "PRI-14" + ], + "Section 61(2)(h)": [ + "PRI-14" + ], + "Section 61(2)(h)(i)": [ + "PRI-14" + ], + "Section 61(2)(j)": [ + "PRI-14" + ], + "Section 61(2)(k)": [ + "PRI-14" + ], + "Section 61(3)": [ + "PRI-14" + ], + "Section 61(4)": [ + "PRI-14" + ], + "Section 61(4)(a)": [ + "PRI-14" + ], + "Section 61(4)(b)": [ + "PRI-14" + ], + "Section 61(4)(c)": [ + "PRI-14" + ], + "Section 61(4)(d)": [ + "PRI-14" + ], + "Section 61(4)(e)": [ + "PRI-14" + ], + "Section 61(4)(f)": [ + "PRI-14" + ], + "Section 61(5)": [ + "PRI-14" + ], + "Section 62(1)": [ + "PRI-14" + ], + "Section 62(1)(a)": [ + "PRI-14" + ], + "Section 62(1)(b)": [ + "PRI-14" + ], + "Section 62(1)(c)": [ + "PRI-14" + ], + "Section 62(1)(d)": [ + "PRI-14" + ], + "Section 62(1)(e)": [ + "PRI-14" + ], + "Section 62(1)(f)": [ + "PRI-14" + ], + "Section 62(2)": [ + "PRI-14" + ], + "Section 62(2)(a)": [ + "PRI-14" + ], + "Section 62(2)(b)": [ + "PRI-14" + ], + "Section 62(3)": [ + "PRI-14" + ], + "Section 62(3)(a)": [ + "PRI-14" + ], + "Section 62(3)(b)": [ + "PRI-14" + ], + "Section 62(3)(b)(i)": [ + "PRI-14" + ], + "Section 62(3)(b)(ii)": [ + "PRI-14" + ], + "Section 62(4)": [ + "PRI-14" + ], + "Section 62(4)(a)": [ + "PRI-14" + ], + "Section 62(4)(b)": [ + "PRI-14" + ], + "Section 62(4)(c)": [ + "PRI-14" + ], + "Section 62(4)(d)": [ + "PRI-14" + ], + "Section 62(5)": [ + "PRI-14" + ], + "Section 44(5)": [ + "PRI-17" + ], + "Section 44(5)(a)": [ + "PRI-17" + ], + "Section 44(5)(b)": [ + "PRI-17" + ], + "Section 44(5)(c)": [ + "PRI-17" + ], + "Section 44(5)(d)": [ + "PRI-17" + ], + "Section 44(5)(e)": [ + "PRI-17" + ], + "Section 44(6)": [ + "PRI-17" + ], + "Section 44(7)(a)": [ + "PRI-17.3" + ], + "Section 44(7)(b)": [ + "PRI-17.3" + ], + "Section 45(7)(a)": [ + "PRI-17.3" + ], + "Section 45(7)(b)": [ + "PRI-17.3" + ], + "Section 50(1)": [ + "PRI-19" + ], + "Section 50(1)(a)": [ + "PRI-19" + ], + "Section 50(1)(b)": [ + "PRI-19" + ], + "Section 50(1)(b)(i)": [ + "PRI-19" + ], + "Section 50(1)(b)(ii)": [ + "PRI-19" + ], + "Section 50(2)": [ + "PRI-19" + ], + "Section 50C(1)": [ + "PRI-19" + ], + "Section 50C(1)(a)": [ + "PRI-19" + ], + "Section 50C(1)(b)": [ + "PRI-19" + ], + "Section 50C(2)": [ + "PRI-19" + ], + "Section 50C(2)(a)": [ + "PRI-19" + ], + "Section 50C(2)(b)": [ + "PRI-19" + ], + "Section 50C(2)(c)": [ + "PRI-19" + ], + "Section 50C(2)(d)": [ + "PRI-19" + ], + "Section 50C(3)": [ + "PRI-19" + ], + "Section 50C(3)(a)": [ + "PRI-19" + ], + "Section 50C(3)(b)": [ + "PRI-19" + ], + "Section 50C(3)(c)": [ + "PRI-19" + ], + "Section 50C(4)": [ + "PRI-19" + ], + "Section 50C(4)(a)": [ + "PRI-19" + ], + "Section 50C(4)(b)": [ + "PRI-19" + ], + "Section 50C(4)(c)": [ + "PRI-19" + ], + "Section 50C(4)(d)": [ + "PRI-19" + ], + "Section 50C(4)(e)": [ + "PRI-19" + ], + "Section 50C(5)": [ + "PRI-19" + ], + "Section 64(1)": [ + "RSK-10" + ], + "Section 64(2)": [ + "RSK-10" + ], + "Section 64(3)": [ + "RSK-10" + ], + "Section 64(3)(a)": [ + "RSK-10" + ], + "Section 64(3)(b)": [ + "RSK-10" + ], + "Section 64(3)(c)": [ + "RSK-10" + ], + "Section 64(3)(d)": [ + "RSK-10" + ], + "Section 64(4)": [ + "RSK-10" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-grc-pirppd-1997.json b/docs/api/crosswalks/emea-grc-pirppd-1997.json index 825881ea..e0618dc4 100644 --- a/docs/api/crosswalks/emea-grc-pirppd-1997.json +++ b/docs/api/crosswalks/emea-grc-pirppd-1997.json @@ -1,109 +1,391 @@ { "framework_id": "emea-grc-pirppd-1997", - "display_name": "Greece - Protection of Individuals with Regard to the Processing of Personal Data (1997)", + "display_name": "Greece - Protection of Individuals with Regard to the Processing of Personal Data (2472/1997)", "scf_to_framework": { - "total_mappings": 17, + "total_mappings": 26, "mappings": { - "GOV-01": [ - "10" + "GOV-17": [ + "B.7.7", + "B.8.2" ], "CPL-01": [ - "10" + "B.5.3" ], - "CPL-02": [ - "10" + "HRS-01": [ + "B.10.2" ], - "DCH-01": [ - "9" + "PRI-01.5": [ + "B.9.1.b", + "B.9.2" ], - "DCH-22.1": [ - "13" + "PRI-01.6": [ + "B.9.2.f", + "B.10.1", + "B.10.2", + "B.10.3" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-01.7": [ + "C.11.3" + ], + "PRI-01.11": [ + "B.4.1.a", + "B.4.1.b", + "B.7.2.b", + "B.7.2.c", + "B.7.2.d", + "B.7.2.e", + "B.7.2.f", + "B.7.2.g", + "B.9.2.f", + "C.11.4", + "C.11.5", + "C.12.3" + ], + "PRI-02": [ + "C.11.1", + "C.11.1.a", + "C.11.1.b", + "C.11.1.c", + "C.11.1.d", + "C.11.2", + "C.11.3" ], "PRI-03": [ - "5" + "B.5.1", + "B.7.2.a" + ], + "PRI-03.3": [ + "B.7.1", + "B.9.1", + "B.9.1.a" ], "PRI-04": [ - "4" + "B.4.1.a", + "B.4.1.b" ], "PRI-04.1": [ - "4" + "B.4.1.a", + "B.4.1.b", + "B.5.2", + "B.5.2.a", + "B.5.2.b", + "B.5.2.c", + "B.5.2.d", + "B.5.2.e", + "B.8.3" ], "PRI-05": [ - "4", - "7" + "B.4.1.d", + "B.4.2" + ], + "PRI-05.1": [ + "B.7.2.f" + ], + "PRI-05.4": [ + "B.7.1", + "B.7.2", + "B.8.3" ], "PRI-06": [ - "11", - "12" + "C.12.1", + "C.12.2", + "C.12.2.a", + "C.12.2.b", + "C.12.2.c", + "C.12.2.d", + "C.12.2.e", + "C.12.2.f" ], "PRI-06.1": [ - "13" + "B.4.1.c", + "C.12.2.e" ], - "PRI-06.3": [ - "13" + "PRI-06.5": [ + "C.12.2.e" ], - "PRI-15": [ - "6" + "PRI-07": [ + "B.9.1", + "B.9.2.a", + "B.9.2.b", + "B.9.2.b.i", + "B.9.2.b.ii", + "B.9.2.b.iii", + "B.9.2.c", + "B.9.2.d", + "B.9.2.e" ], - "SEA-01": [ - "9" + "PRI-07.1": [ + "B.10.4" ], - "SEA-02": [ - "9" + "PRI-07.2": [ + "B.8.1" ], - "SEA-03": [ - "9" + "PRI-07.3": [ + "C.12.2.f" + ], + "PRI-10": [ + "B.4.1.c" + ], + "PRI-15": [ + "B.6.1", + "B.6.2", + "B.6.2.a", + "B.6.2.b", + "B.6.2.c", + "B.6.2.d", + "B.6.2.e", + "B.6.2.f", + "B.6.2.g", + "B.6.2.h", + "B.6.3", + "B.6.4" + ], + "PRI-17": [ + "C.11.3" + ], + "PRI-19.3": [ + "C.12.2.d" ] } }, "framework_to_scf": { - "total_mappings": 11, + "total_mappings": 73, "mappings": { - "4": [ + "B.7.7": [ + "GOV-17" + ], + "B.8.2": [ + "GOV-17" + ], + "B.5.3": [ + "CPL-01" + ], + "B.10.2": [ + "HRS-01", + "PRI-01.6" + ], + "B.9.1.b": [ + "PRI-01.5" + ], + "B.9.2": [ + "PRI-01.5" + ], + "B.9.2.f": [ + "PRI-01.6", + "PRI-01.11" + ], + "B.10.1": [ + "PRI-01.6" + ], + "B.10.3": [ + "PRI-01.6" + ], + "C.11.3": [ + "PRI-01.7", + "PRI-02", + "PRI-17" + ], + "B.4.1.a": [ + "PRI-01.11", "PRI-04", - "PRI-04.1", - "PRI-05" + "PRI-04.1" + ], + "B.4.1.b": [ + "PRI-01.11", + "PRI-04", + "PRI-04.1" + ], + "B.7.2.b": [ + "PRI-01.11" + ], + "B.7.2.c": [ + "PRI-01.11" + ], + "B.7.2.d": [ + "PRI-01.11" + ], + "B.7.2.e": [ + "PRI-01.11" + ], + "B.7.2.f": [ + "PRI-01.11", + "PRI-05.1" + ], + "B.7.2.g": [ + "PRI-01.11" + ], + "C.11.4": [ + "PRI-01.11" + ], + "C.11.5": [ + "PRI-01.11" + ], + "C.12.3": [ + "PRI-01.11" + ], + "C.11.1": [ + "PRI-02" + ], + "C.11.1.a": [ + "PRI-02" ], - "5": [ + "C.11.1.b": [ + "PRI-02" + ], + "C.11.1.c": [ + "PRI-02" + ], + "C.11.1.d": [ + "PRI-02" + ], + "C.11.2": [ + "PRI-02" + ], + "B.5.1": [ "PRI-03" ], - "6": [ - "PRI-15" + "B.7.2.a": [ + "PRI-03" + ], + "B.7.1": [ + "PRI-03.3", + "PRI-05.4" + ], + "B.9.1": [ + "PRI-03.3", + "PRI-07" + ], + "B.9.1.a": [ + "PRI-03.3" + ], + "B.5.2": [ + "PRI-04.1" + ], + "B.5.2.a": [ + "PRI-04.1" + ], + "B.5.2.b": [ + "PRI-04.1" ], - "7": [ + "B.5.2.c": [ + "PRI-04.1" + ], + "B.5.2.d": [ + "PRI-04.1" + ], + "B.5.2.e": [ + "PRI-04.1" + ], + "B.8.3": [ + "PRI-04.1", + "PRI-05.4" + ], + "B.4.1.d": [ + "PRI-05" + ], + "B.4.2": [ "PRI-05" ], - "9": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "B.7.2": [ + "PRI-05.4" + ], + "C.12.1": [ + "PRI-06" + ], + "C.12.2": [ + "PRI-06" ], - "10": [ - "GOV-01", - "CPL-01", - "CPL-02" + "C.12.2.a": [ + "PRI-06" ], - "11": [ + "C.12.2.b": [ "PRI-06" ], - "12": [ + "C.12.2.c": [ "PRI-06" ], - "13": [ - "DCH-22.1", + "C.12.2.d": [ + "PRI-06", + "PRI-19.3" + ], + "C.12.2.e": [ + "PRI-06", + "PRI-06.1", + "PRI-06.5" + ], + "C.12.2.f": [ + "PRI-06", + "PRI-07.3" + ], + "B.4.1.c": [ "PRI-06.1", - "PRI-06.3" + "PRI-10" + ], + "B.9.2.a": [ + "PRI-07" + ], + "B.9.2.b": [ + "PRI-07" + ], + "B.9.2.b.i": [ + "PRI-07" + ], + "B.9.2.b.ii": [ + "PRI-07" + ], + "B.9.2.b.iii": [ + "PRI-07" + ], + "B.9.2.c": [ + "PRI-07" + ], + "B.9.2.d": [ + "PRI-07" + ], + "B.9.2.e": [ + "PRI-07" ], - "Inferred": [ - "PRI-01" + "B.10.4": [ + "PRI-07.1" ], - "Expectation": [ - "PRI-01" + "B.8.1": [ + "PRI-07.2" + ], + "B.6.1": [ + "PRI-15" + ], + "B.6.2": [ + "PRI-15" + ], + "B.6.2.a": [ + "PRI-15" + ], + "B.6.2.b": [ + "PRI-15" + ], + "B.6.2.c": [ + "PRI-15" + ], + "B.6.2.d": [ + "PRI-15" + ], + "B.6.2.e": [ + "PRI-15" + ], + "B.6.2.f": [ + "PRI-15" + ], + "B.6.2.g": [ + "PRI-15" + ], + "B.6.2.h": [ + "PRI-15" + ], + "B.6.3": [ + "PRI-15" + ], + "B.6.4": [ + "PRI-15" ] } } diff --git a/docs/api/crosswalks/emea-hun-act-cxii-2011.json b/docs/api/crosswalks/emea-hun-act-cxii-2011.json new file mode 100644 index 00000000..7c7fbab1 --- /dev/null +++ b/docs/api/crosswalks/emea-hun-act-cxii-2011.json @@ -0,0 +1,570 @@ +{ + "framework_id": "emea-hun-act-cxii-2011", + "display_name": "Hungary - Act CXII of 2011", + "scf_to_framework": { + "total_mappings": 35, + "mappings": { + "GOV-17": [ + "II.13.16(3)" + ], + "CPL-01": [ + "II.5.5(2)(b)", + "II.5.6(1)(a)", + "II.5.6(5)(a)" + ], + "DCH-02": [ + "II.4.4(3)" + ], + "DCH-23": [ + "II.11.12(2)" + ], + "HRS-03": [ + "II.18.24(2)" + ], + "PRI-01": [ + "II.6.7(1)" + ], + "PRI-01.4": [ + "II.18.24(1)(a)", + "II.18.24(1)(b)", + "II.18.24(1)(c)", + "II.18.24(2)", + "II.18.24(2)(a)", + "II.18.24(2)(b)", + "II.18.24(2)(c)", + "II.18.24(2)(d)", + "II.18.24(2)(e)", + "II.18.24(2)(f)" + ], + "PRI-01.5": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" + ], + "PRI-01.6": [ + "II.6.7(2)", + "II.6.7(3)", + "II.6.7(4)", + "II.6.7(5)(a)", + "II.6.7(5)(b)", + "II.6.7(5)(c)", + "II.6.7(5)(d)", + "II.6.7(5)(e)", + "II.6.7(5)(f)", + "II.6.7(6)" + ], + "PRI-01.11": [ + "II.5.6(1)(a)", + "II.5.6(5)(b)", + "II.6.7(1)", + "II.8.9(1)(c)", + "II.8.9(1)(d)", + "II.10.11(1)(a)", + "II.13.16(1)", + "II.13.17(3)", + "II.13.17(4)", + "II.13.17(5)", + "II.14.20(4)(e)", + "II.14.20(4)(f)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)", + "II.15.21(3)", + "II.15.21(7)", + "II.18.24(3)" + ], + "PRI-02": [ + "II.5.6(4)", + "II.7.8(1)(a)", + "II.14.20(1)", + "II.14.20(2)", + "II.14.20(4)(a)", + "II.14.20(4)(b)", + "II.14.20(4)(d)" + ], + "PRI-02.1": [ + "II.8.9(1)(a)", + "II.14.20(2)", + "II.14.20(4)(c)" + ], + "PRI-02.13": [ + "II.14.20(4)(f)" + ], + "PRI-03": [ + "II.5.5(1)(a)", + "II.5.5(2)(a)", + "II.5.6(3)", + "II.5.6(4)", + "II.7.8(1)(a)", + "II.8.9(4)", + "II.11.12(3)(a)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)" + ], + "PRI-03.3": [ + "II.5.6(3)" + ], + "PRI-03.4": [ + "II.15.21(1)(a)", + "II.15.21(1)(b)" + ], + "PRI-03.6": [ + "II.5.6(2)" + ], + "PRI-03.7": [ + "II.14.20(1)" + ], + "PRI-03.11": [ + "II.13.18(1)" + ], + "PRI-04": [ + "II.4.4(1)", + "II.4.4(2)", + "II.11.12(1)", + "II.12.13(2)" + ], + "PRI-04.1": [ + "II.4.4(1)", + "II.4.4(2)", + "II.4.4(3)", + "II.4.4(5)", + "II.5.5(1)(b)", + "II.5.5(2)(b)", + "II.5.5(2)(c)", + "II.5.5(3)", + "II.5.5(4)", + "II.5.6(1)(b)", + "II.5.6(5)(a)", + "II.10.11(1)(b)", + "II.11.12(1)" + ], + "PRI-05": [ + "II.8.9(1)(b)", + "II.13.15(3)", + "II.13.17(2)(a)", + "II.13.17(2)(b)", + "II.13.17(2)(c)", + "II.13.17(2)(d)", + "II.13.17(2)(e)", + "II.14.20(4)(d)", + "II.15.21(7)" + ], + "PRI-05.2": [ + "II.4.4(4)", + "II.13.17(1)" + ], + "PRI-05.4": [ + "II.11.12(3)(a)", + "II.11.12(3)(b)", + "II.12.13(2)" + ], + "PRI-06": [ + "II.13.14(a)", + "II.13.14(b)", + "II.13.14(c)", + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)" + ], + "PRI-06.1": [ + "II.13.17(1)" + ], + "PRI-06.4": [ + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)", + "II.13.16(2)", + "II.13.18(2)", + "II.15.21(2)", + "II.15.21(3)" + ], + "PRI-07": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" + ], + "PRI-07.1": [ + "II.7.8(1)(b)", + "II.8.9(1)", + "II.8.9(1)(c)", + "II.8.9(1)(e)", + "II.8.9(2)", + "II.8.9(3)", + "II.8.9(5)", + "II.9.10(1)", + "II.9.10(2)", + "II.9.10(3)", + "II.9.10(4)", + "II.10.11(1)(a)" + ], + "PRI-07.3": [ + "II.13.18(1)" + ], + "PRI-07.4": [ + "II.13.16(1)" + ], + "PRI-14": [ + "II.13.15(2)" + ], + "PRI-14.1": [ + "II.13.15(2)" + ], + "PRI-17": [ + "II.13.16(2)", + "II.13.18(2)" + ], + "PRI-19": [ + "II.10.11(2)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 100, + "mappings": { + "II.13.16(3)": [ + "GOV-17" + ], + "II.5.5(2)(b)": [ + "CPL-01", + "PRI-04.1" + ], + "II.5.6(1)(a)": [ + "CPL-01", + "PRI-01.11" + ], + "II.5.6(5)(a)": [ + "CPL-01", + "PRI-04.1" + ], + "II.4.4(3)": [ + "DCH-02", + "PRI-04.1" + ], + "II.11.12(2)": [ + "DCH-23" + ], + "II.18.24(2)": [ + "HRS-03", + "PRI-01.4" + ], + "II.6.7(1)": [ + "PRI-01", + "PRI-01.11" + ], + "II.18.24(1)(a)": [ + "PRI-01.4" + ], + "II.18.24(1)(b)": [ + "PRI-01.4" + ], + "II.18.24(1)(c)": [ + "PRI-01.4" + ], + "II.18.24(2)(a)": [ + "PRI-01.4" + ], + "II.18.24(2)(b)": [ + "PRI-01.4" + ], + "II.18.24(2)(c)": [ + "PRI-01.4" + ], + "II.18.24(2)(d)": [ + "PRI-01.4" + ], + "II.18.24(2)(e)": [ + "PRI-01.4" + ], + "II.18.24(2)(f)": [ + "PRI-01.4" + ], + "II.7.8(1)(b)": [ + "PRI-01.5", + "PRI-07", + "PRI-07.1" + ], + "II.8.9(3)": [ + "PRI-01.5", + "PRI-07", + "PRI-07.1" + ], + "II.8.9(5)": [ + "PRI-01.5", + "PRI-07", + "PRI-07.1" + ], + "II.6.7(2)": [ + "PRI-01.6" + ], + "II.6.7(3)": [ + "PRI-01.6" + ], + "II.6.7(4)": [ + "PRI-01.6" + ], + "II.6.7(5)(a)": [ + "PRI-01.6" + ], + "II.6.7(5)(b)": [ + "PRI-01.6" + ], + "II.6.7(5)(c)": [ + "PRI-01.6" + ], + "II.6.7(5)(d)": [ + "PRI-01.6" + ], + "II.6.7(5)(e)": [ + "PRI-01.6" + ], + "II.6.7(5)(f)": [ + "PRI-01.6" + ], + "II.6.7(6)": [ + "PRI-01.6" + ], + "II.5.6(5)(b)": [ + "PRI-01.11" + ], + "II.8.9(1)(c)": [ + "PRI-01.11", + "PRI-07.1" + ], + "II.8.9(1)(d)": [ + "PRI-01.11" + ], + "II.10.11(1)(a)": [ + "PRI-01.11", + "PRI-07.1" + ], + "II.13.16(1)": [ + "PRI-01.11", + "PRI-07.4" + ], + "II.13.17(3)": [ + "PRI-01.11" + ], + "II.13.17(4)": [ + "PRI-01.11" + ], + "II.13.17(5)": [ + "PRI-01.11" + ], + "II.14.20(4)(e)": [ + "PRI-01.11" + ], + "II.14.20(4)(f)": [ + "PRI-01.11", + "PRI-02.13" + ], + "II.15.21(1)(a)": [ + "PRI-01.11", + "PRI-03", + "PRI-03.4" + ], + "II.15.21(1)(b)": [ + "PRI-01.11", + "PRI-03", + "PRI-03.4" + ], + "II.15.21(1)(c)": [ + "PRI-01.11", + "PRI-03" + ], + "II.15.21(3)": [ + "PRI-01.11", + "PRI-06.4" + ], + "II.15.21(7)": [ + "PRI-01.11", + "PRI-05" + ], + "II.18.24(3)": [ + "PRI-01.11" + ], + "II.5.6(4)": [ + "PRI-02", + "PRI-03" + ], + "II.7.8(1)(a)": [ + "PRI-02", + "PRI-03" + ], + "II.14.20(1)": [ + "PRI-02", + "PRI-03.7" + ], + "II.14.20(2)": [ + "PRI-02", + "PRI-02.1" + ], + "II.14.20(4)(a)": [ + "PRI-02" + ], + "II.14.20(4)(b)": [ + "PRI-02" + ], + "II.14.20(4)(d)": [ + "PRI-02", + "PRI-05" + ], + "II.8.9(1)(a)": [ + "PRI-02.1" + ], + "II.14.20(4)(c)": [ + "PRI-02.1" + ], + "II.5.5(1)(a)": [ + "PRI-03" + ], + "II.5.5(2)(a)": [ + "PRI-03" + ], + "II.5.6(3)": [ + "PRI-03", + "PRI-03.3" + ], + "II.8.9(4)": [ + "PRI-03" + ], + "II.11.12(3)(a)": [ + "PRI-03", + "PRI-05.4" + ], + "II.5.6(2)": [ + "PRI-03.6" + ], + "II.13.18(1)": [ + "PRI-03.11", + "PRI-07.3" + ], + "II.4.4(1)": [ + "PRI-04", + "PRI-04.1" + ], + "II.4.4(2)": [ + "PRI-04", + "PRI-04.1" + ], + "II.11.12(1)": [ + "PRI-04", + "PRI-04.1" + ], + "II.12.13(2)": [ + "PRI-04", + "PRI-05.4" + ], + "II.4.4(5)": [ + "PRI-04.1" + ], + "II.5.5(1)(b)": [ + "PRI-04.1" + ], + "II.5.5(2)(c)": [ + "PRI-04.1" + ], + "II.5.5(3)": [ + "PRI-04.1" + ], + "II.5.5(4)": [ + "PRI-04.1" + ], + "II.5.6(1)(b)": [ + "PRI-04.1" + ], + "II.10.11(1)(b)": [ + "PRI-04.1" + ], + "II.8.9(1)(b)": [ + "PRI-05" + ], + "II.13.15(3)": [ + "PRI-05" + ], + "II.13.17(2)(a)": [ + "PRI-05" + ], + "II.13.17(2)(b)": [ + "PRI-05" + ], + "II.13.17(2)(c)": [ + "PRI-05" + ], + "II.13.17(2)(d)": [ + "PRI-05" + ], + "II.13.17(2)(e)": [ + "PRI-05" + ], + "II.4.4(4)": [ + "PRI-05.2" + ], + "II.13.17(1)": [ + "PRI-05.2", + "PRI-06.1" + ], + "II.11.12(3)(b)": [ + "PRI-05.4" + ], + "II.13.14(a)": [ + "PRI-06" + ], + "II.13.14(b)": [ + "PRI-06" + ], + "II.13.14(c)": [ + "PRI-06" + ], + "II.13.15(1)": [ + "PRI-06", + "PRI-06.4" + ], + "II.13.15(2)": [ + "PRI-06", + "PRI-06.4", + "PRI-14", + "PRI-14.1" + ], + "II.13.15(4)": [ + "PRI-06", + "PRI-06.4" + ], + "II.13.16(2)": [ + "PRI-06.4", + "PRI-17" + ], + "II.13.18(2)": [ + "PRI-06.4", + "PRI-17" + ], + "II.15.21(2)": [ + "PRI-06.4" + ], + "II.8.9(1)": [ + "PRI-07.1" + ], + "II.8.9(1)(e)": [ + "PRI-07.1" + ], + "II.8.9(2)": [ + "PRI-07.1" + ], + "II.9.10(1)": [ + "PRI-07.1" + ], + "II.9.10(2)": [ + "PRI-07.1" + ], + "II.9.10(3)": [ + "PRI-07.1" + ], + "II.9.10(4)": [ + "PRI-07.1" + ], + "II.10.11(2)": [ + "PRI-19" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-hun-isdfi-2011.json b/docs/api/crosswalks/emea-hun-isdfi-2011.json deleted file mode 100644 index d70c58ac..00000000 --- a/docs/api/crosswalks/emea-hun-isdfi-2011.json +++ /dev/null @@ -1,194 +0,0 @@ -{ - "framework_id": "emea-hun-isdfi-2011", - "display_name": "Hungary - Informational Self-Determination and Freedom of Information (2011)", - "scf_to_framework": { - "total_mappings": 27, - "mappings": { - "GOV-01": [ - "7" - ], - "CPL-01": [ - "7" - ], - "CPL-02": [ - "7" - ], - "CPL-03": [ - "7" - ], - "DCH-01": [ - "7", - "8" - ], - "DCH-22.1": [ - "14", - "15", - "17" - ], - "DCH-24": [ - "7" - ], - "DCH-24.1": [ - "7" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-01.1": [ - "24" - ], - "PRI-03": [ - "6" - ], - "PRI-04": [ - "4", - "5" - ], - "PRI-04.1": [ - "4", - "5" - ], - "PRI-05": [ - "5" - ], - "PRI-05.1": [ - "9" - ], - "PRI-05.4": [ - "9" - ], - "PRI-06": [ - "14", - "15" - ], - "PRI-06.1": [ - "14", - "15", - "17" - ], - "PRI-06.2": [ - "14", - "15", - "17", - "18" - ], - "PRI-06.3": [ - "14", - "15", - "17", - "18" - ], - "PRI-06.4": [ - "14", - "15", - "17" - ], - "PRI-15": [ - "65", - "66" - ], - "SEA-01": [ - "7", - "8" - ], - "SEA-02": [ - "7", - "8" - ], - "SEA-03": [ - "7", - "8" - ], - "SEA-15": [ - "7" - ], - "TPM-04.4": [ - "7" - ] - } - }, - "framework_to_scf": { - "total_mappings": 15, - "mappings": { - "4": [ - "PRI-04", - "PRI-04.1" - ], - "5": [ - "PRI-04", - "PRI-04.1", - "PRI-05" - ], - "6": [ - "PRI-03" - ], - "7": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "8": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "9": [ - "PRI-05.1", - "PRI-05.4" - ], - "14": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "PRI-06.4" - ], - "15": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "PRI-06.4" - ], - "17": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "PRI-06.4" - ], - "18": [ - "PRI-06.2", - "PRI-06.3" - ], - "24": [ - "PRI-01.1" - ], - "65": [ - "PRI-15" - ], - "66": [ - "PRI-15" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-irl-dpa-2003.json b/docs/api/crosswalks/emea-irl-dpa-2003.json deleted file mode 100644 index 333b15b6..00000000 --- a/docs/api/crosswalks/emea-irl-dpa-2003.json +++ /dev/null @@ -1,124 +0,0 @@ -{ - "framework_id": "emea-irl-dpa-2003", - "display_name": "Ireland - Data Protection Act (DPA) (2003)", - "scf_to_framework": { - "total_mappings": 25, - "mappings": { - "GOV-01": [ - "2" - ], - "CPL-01": [ - "2" - ], - "CPL-02": [ - "2" - ], - "CPL-03": [ - "2" - ], - "DCH-01": [ - "2" - ], - "DCH-22.1": [ - "2" - ], - "DCH-24": [ - "2" - ], - "DCH-24.1": [ - "2" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-01.1": [ - "2" - ], - "PRI-02.1": [ - "2" - ], - "PRI-03": [ - "2" - ], - "PRI-04": [ - "2" - ], - "PRI-04.1": [ - "2" - ], - "PRI-05": [ - "2" - ], - "PRI-06": [ - "2" - ], - "PRI-06.1": [ - "2" - ], - "PRI-06.2": [ - "2" - ], - "PRI-06.3": [ - "2" - ], - "PRI-15": [ - "17" - ], - "SEA-01": [ - "2" - ], - "SEA-02": [ - "2" - ], - "SEA-03": [ - "2" - ], - "SEA-15": [ - "2" - ], - "TPM-04.4": [ - "2" - ] - } - }, - "framework_to_scf": { - "total_mappings": 4, - "mappings": { - "2": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-22.1", - "DCH-24", - "DCH-24.1", - "PRI-01.1", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05", - "PRI-06", - "PRI-06.1", - "PRI-06.2", - "PRI-06.3", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "17": [ - "PRI-15" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-irl-dpa-2018.json b/docs/api/crosswalks/emea-irl-dpa-2018.json new file mode 100644 index 00000000..2b89826e --- /dev/null +++ b/docs/api/crosswalks/emea-irl-dpa-2018.json @@ -0,0 +1,232 @@ +{ + "framework_id": "emea-irl-dpa-2018", + "display_name": "Ireland - Data Protection Act (DPA) (2018)", + "scf_to_framework": { + "total_mappings": 17, + "mappings": { + "CPL-01": [ + "s.83" + ], + "IRO-10": [ + "s.85", + "s.86" + ], + "IRO-10.2": [ + "s.87" + ], + "PRI-01.4": [ + "s.88" + ], + "PRI-01.5": [ + "s.96", + "s.97", + "s.98", + "s.99", + "s.100" + ], + "PRI-01.6": [ + "s.72", + "s.75", + "s.76", + "s.77", + "s.78" + ], + "PRI-01.11": [ + "s.71", + "s.94" + ], + "PRI-02": [ + "s.90" + ], + "PRI-05.2": [ + "s.74" + ], + "PRI-05.4": [ + "s.45", + "s.46", + "s.47", + "s.48", + "s.49", + "s.50", + "s.51", + "s.52", + "s.53", + "s.54", + "s.55", + "s.73" + ], + "PRI-06": [ + "s.56", + "s.57", + "s.58", + "s.59", + "s.60", + "s.61", + "s.91", + "s.92" + ], + "PRI-06.4": [ + "s.93" + ], + "PRI-07.1": [ + "s.80" + ], + "PRI-07.2": [ + "s.79" + ], + "PRI-14": [ + "s.81", + "s.82" + ], + "PRI-19": [ + "s.89" + ], + "RSK-10": [ + "s.84" + ] + } + }, + "framework_to_scf": { + "total_mappings": 46, + "mappings": { + "s.83": [ + "CPL-01" + ], + "s.85": [ + "IRO-10" + ], + "s.86": [ + "IRO-10" + ], + "s.87": [ + "IRO-10.2" + ], + "s.88": [ + "PRI-01.4" + ], + "s.96": [ + "PRI-01.5" + ], + "s.97": [ + "PRI-01.5" + ], + "s.98": [ + "PRI-01.5" + ], + "s.99": [ + "PRI-01.5" + ], + "s.100": [ + "PRI-01.5" + ], + "s.72": [ + "PRI-01.6" + ], + "s.75": [ + "PRI-01.6" + ], + "s.76": [ + "PRI-01.6" + ], + "s.77": [ + "PRI-01.6" + ], + "s.78": [ + "PRI-01.6" + ], + "s.71": [ + "PRI-01.11" + ], + "s.94": [ + "PRI-01.11" + ], + "s.90": [ + "PRI-02" + ], + "s.74": [ + "PRI-05.2" + ], + "s.45": [ + "PRI-05.4" + ], + "s.46": [ + "PRI-05.4" + ], + "s.47": [ + "PRI-05.4" + ], + "s.48": [ + "PRI-05.4" + ], + "s.49": [ + "PRI-05.4" + ], + "s.50": [ + "PRI-05.4" + ], + "s.51": [ + "PRI-05.4" + ], + "s.52": [ + "PRI-05.4" + ], + "s.53": [ + "PRI-05.4" + ], + "s.54": [ + "PRI-05.4" + ], + "s.55": [ + "PRI-05.4" + ], + "s.73": [ + "PRI-05.4" + ], + "s.56": [ + "PRI-06" + ], + "s.57": [ + "PRI-06" + ], + "s.58": [ + "PRI-06" + ], + "s.59": [ + "PRI-06" + ], + "s.60": [ + "PRI-06" + ], + "s.61": [ + "PRI-06" + ], + "s.91": [ + "PRI-06" + ], + "s.92": [ + "PRI-06" + ], + "s.93": [ + "PRI-06.4" + ], + "s.80": [ + "PRI-07.1" + ], + "s.79": [ + "PRI-07.2" + ], + "s.81": [ + "PRI-14" + ], + "s.82": [ + "PRI-14" + ], + "s.89": [ + "PRI-19" + ], + "s.84": [ + "RSK-10" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-isr-cmo-1-0.json b/docs/api/crosswalks/emea-isr-cmo-1-0.json deleted file mode 100644 index 170a4aa6..00000000 --- a/docs/api/crosswalks/emea-isr-cmo-1-0.json +++ /dev/null @@ -1,3110 +0,0 @@ -{ - "framework_id": "emea-isr-cmo-1-0", - "display_name": "Israel - Cybersecurity Methodology for an Organization v1.0", - "scf_to_framework": { - "total_mappings": 393, - "mappings": { - "GOV-01": [ - "3.2", - "4.25" - ], - "GOV-02": [ - "1.1", - "4.1", - "4.25", - "5.2", - "5.3", - "9.1", - "10.1", - "11.2", - "12.1", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "20.1", - "21.1", - "22.1", - "24.1", - "25.1" - ], - "GOV-03": [ - "1.1", - "5.2", - "9.1", - "10.1", - "11.2", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "21.1", - "22.1", - "24.1", - "25.1" - ], - "AST-02.4": [ - "6.8" - ], - "AST-02.5": [ - "23.6" - ], - "AST-02.7": [ - "3.1" - ], - "AST-09": [ - "15.4", - "17.21" - ], - "AST-10": [ - "11.12" - ], - "AST-12": [ - "12.6" - ], - "AST-13": [ - "12.6" - ], - "BCD-01": [ - "11.7", - "25.1" - ], - "BCD-01.1": [ - "25.2" - ], - "BCD-02.1": [ - "21.15", - "21.16" - ], - "BCD-02.2": [ - "18.15", - "25.23" - ], - "BCD-02.3": [ - "21.15", - "21.16" - ], - "BCD-03": [ - "25.3" - ], - "BCD-03.1": [ - "25.4", - "25.5" - ], - "BCD-03.2": [ - "25.8" - ], - "BCD-04": [ - "25.4", - "25.6", - "25.7", - "25.9", - "25.23" - ], - "BCD-04.1": [ - "25.6", - "25.7" - ], - "BCD-08": [ - "11.7", - "25.7", - "25.10" - ], - "BCD-08.1": [ - "25.11" - ], - "BCD-08.2": [ - "25.13" - ], - "BCD-09": [ - "11.7", - "25.7", - "25.10" - ], - "BCD-09.1": [ - "25.11" - ], - "BCD-09.2": [ - "25.13" - ], - "BCD-09.3": [ - "25.12", - "21.14" - ], - "BCD-10": [ - "21.14", - "25.16" - ], - "BCD-10.1": [ - "21.14", - "25.17" - ], - "BCD-11": [ - "25.9" - ], - "BCD-11.1": [ - "25.9", - "25.19" - ], - "BCD-11.2": [ - "25.20" - ], - "BCD-11.3": [ - "25.12", - "25.22" - ], - "BCD-11.4": [ - "25.18" - ], - "BCD-12": [ - "25.9", - "25.12", - "25.22" - ], - "BCD-12.1": [ - "25.9", - "25.21" - ], - "BCD-12.2": [ - "12.26", - "25.12" - ], - "BCD-13": [ - "25.12", - "25.18" - ], - "CAP-01": [ - "25.2" - ], - "CAP-03": [ - "25.2" - ], - "CHG-01": [ - "10.6", - "14.6", - "14.7" - ], - "CHG-02": [ - "10.6", - "14.7" - ], - "CHG-02.1": [ - "14.7" - ], - "CHG-02.2": [ - "10.6", - "12.21", - "12.30", - "14.6", - "14.8", - "14.9", - "14.10" - ], - "CHG-02.3": [ - "14.8" - ], - "CHG-03": [ - "10.6", - "14.8" - ], - "CHG-04.4": [ - "10.4" - ], - "CHG-06": [ - "10.6", - "12.30", - "14.10" - ], - "CLD-01": [ - "11.2" - ], - "CLD-03": [ - "9.2" - ], - "CLD-06": [ - "10.1", - "11.3" - ], - "CLD-10": [ - "11.6" - ], - "CLD-11": [ - "9.10", - "11.8", - "16.4" - ], - "CPL-01": [ - "1.3" - ], - "CPL-02": [ - "1.3", - "3.1" - ], - "CPL-03": [ - "3.1" - ], - "CPL-03.2": [ - "3.1", - "3.3", - "12.30" - ], - "CFG-01": [ - "3.3", - "9.22", - "9.23", - "14.1" - ], - "CFG-02": [ - "3.3", - "4.9", - "4.12", - "4.15", - "6.1", - "9.21", - "12.13", - "12.24", - "12.29", - "13.5", - "13.6", - "14.2", - "15.6" - ], - "CFG-02.1": [ - "3.3", - "14.3" - ], - "CFG-02.2": [ - "3.3", - "6.2", - "6.4", - "9.22", - "9.23", - "14.3", - "14.4" - ], - "CFG-02.3": [ - "14.5" - ], - "CFG-02.4": [ - "10.1", - "10.2" - ], - "CFG-02.5": [ - "4.12", - "9.21", - "10.7" - ], - "CFG-02.6": [ - "9.22" - ], - "CFG-02.9": [ - "10.7" - ], - "CFG-03": [ - "4.8", - "4.9", - "12.9", - "12.13" - ], - "CFG-03.3": [ - "6.7" - ], - "CFG-03.4": [ - "4.15", - "9.13" - ], - "CFG-05": [ - "6.3" - ], - "CFG-05.2": [ - "6.3" - ], - "MON-01": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" - ], - "MON-01.1": [ - "7.4", - "11.11", - "12.18", - "23.6" - ], - "MON-01.2": [ - "11.11", - "12.31" - ], - "MON-01.3": [ - "9.9", - "9.10", - "10.9" - ], - "MON-01.4": [ - "21.2", - "21.4" - ], - "MON-01.5": [ - "7.6" - ], - "MON-01.7": [ - "6.4", - "12.19" - ], - "MON-01.8": [ - "12.31", - "21.3", - "21.11" - ], - "MON-01.9": [ - "9.14", - "21.20" - ], - "MON-01.16": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" - ], - "MON-02": [ - "4.6", - "12.17", - "21.3", - "21.4", - "21.6", - "21.12" - ], - "MON-02.1": [ - "4.6", - "12.17", - "21.6", - "21.12", - "21.13", - "21.19" - ], - "MON-03": [ - "4.6", - "12.17", - "21.2", - "21.5", - "21.7", - "21.10" - ], - "MON-03.1": [ - "21.4" - ], - "MON-03.2": [ - "12.17" - ], - "MON-03.3": [ - "21.10", - "21.21" - ], - "MON-03.4": [ - "21.5", - "21.21" - ], - "MON-04": [ - "21.8" - ], - "MON-05": [ - "21.9" - ], - "MON-05.1": [ - "21.9" - ], - "MON-06": [ - "21.3", - "21.11", - "21.19", - "21.20" - ], - "MON-08": [ - "21.4", - "21.14", - "21.16" - ], - "MON-08.1": [ - "21.14", - "21.15", - "21.17" - ], - "MON-08.2": [ - "21.14" - ], - "MON-09": [ - "21.14" - ], - "MON-10": [ - "21.4", - "21.15", - "21.17" - ], - "MON-12": [ - "21.10", - "21.18" - ], - "MON-13": [ - "21.15" - ], - "MON-15": [ - "21.10" - ], - "MON-16": [ - "4.7", - "21.10", - "21.20" - ], - "MON-16.1": [ - "21.10" - ], - "MON-16.2": [ - "21.10" - ], - "MON-16.3": [ - "21.10" - ], - "CRY-01": [ - "8.1", - "8.8", - "15.7", - "21.16" - ], - "CRY-01.1": [ - "15.7" - ], - "CRY-02": [ - "4.37", - "12.10" - ], - "CRY-03": [ - "4.22", - "8.4", - "8.5", - "8.6", - "9.8", - "9.20", - "12.10", - "13.6" - ], - "CRY-04": [ - "4.22", - "9.8", - "9.20", - "12.10", - "13.6" - ], - "CRY-05": [ - "8.7", - "15.7" - ], - "CRY-05.1": [ - "15.7" - ], - "CRY-07": [ - "4.22" - ], - "CRY-08": [ - "8.2", - "8.9" - ], - "CRY-09": [ - "8.2", - "8.9", - "8.10" - ], - "CRY-09.3": [ - "8.3", - "8.11" - ], - "CRY-09.4": [ - "8.9", - "8.11" - ], - "DCH-01": [ - "5.1", - "5.2", - "5.3", - "5.5", - "11.6", - "15.1", - "15.6", - "15.7" - ], - "DCH-01.1": [ - "11.6" - ], - "DCH-02": [ - "5.3", - "15.2" - ], - "DCH-03.1": [ - "10.5" - ], - "DCH-04": [ - "15.2" - ], - "DCH-06": [ - "15.3" - ], - "DCH-07": [ - "15.7" - ], - "DCH-07.1": [ - "15.7" - ], - "DCH-08": [ - "15.4" - ], - "DCH-09": [ - "15.4" - ], - "DCH-09.1": [ - "15.8" - ], - "DCH-09.2": [ - "15.8" - ], - "DCH-09.3": [ - "15.4" - ], - "DCH-12": [ - "12.24" - ], - "DCH-13": [ - "11.6" - ], - "DCH-13.3": [ - "11.6" - ], - "DCH-14": [ - "5.4", - "10.5" - ], - "DCH-17": [ - "5.1", - "5.4", - "10.5" - ], - "DCH-19": [ - "11.6" - ], - "DCH-21": [ - "11.12", - "15.4" - ], - "DCH-25": [ - "10.5" - ], - "EMB-01": [ - "12.1", - "12.2", - "12.3" - ], - "END-01": [ - "7.1", - "7.3", - "15.5" - ], - "END-02": [ - "7.1", - "7.3", - "15.5" - ], - "END-03": [ - "6.3" - ], - "END-03.1": [ - "6.3" - ], - "END-04": [ - "7.1", - "7.3", - "12.20", - "15.5" - ], - "END-04.1": [ - "7.9" - ], - "END-04.3": [ - "7.7", - "12.20" - ], - "END-04.4": [ - "7.8" - ], - "END-04.6": [ - "12.20" - ], - "END-04.7": [ - "7.5", - "12.25" - ], - "END-06": [ - "6.4", - "12.19" - ], - "END-06.2": [ - "7.2" - ], - "END-07": [ - "7.4", - "7.5", - "12.18", - "12.24", - "23.6" - ], - "END-09": [ - "4.37" - ], - "END-14": [ - "5.6" - ], - "HRS-01": [ - "19.1" - ], - "HRS-02": [ - "19.1" - ], - "HRS-03": [ - "4.13", - "18.10" - ], - "HRS-04": [ - "19.2" - ], - "HRS-04.1": [ - "19.2" - ], - "HRS-05": [ - "5.1", - "19.3", - "19.4" - ], - "HRS-05.1": [ - "5.1", - "15.6", - "19.3", - "19.6" - ], - "HRS-05.2": [ - "4.13", - "19.6", - "19.7" - ], - "HRS-05.3": [ - "5.4", - "9.5", - "15.6", - "19.6" - ], - "HRS-05.4": [ - "15.6", - "19.6" - ], - "HRS-05.5": [ - "13.2", - "13.3", - "13.7", - "13.10", - "15.6", - "19.6" - ], - "HRS-06": [ - "19.6" - ], - "HRS-06.1": [ - "19.4" - ], - "HRS-07": [ - "19.8" - ], - "HRS-08": [ - "19.9" - ], - "HRS-09": [ - "19.9", - "19.10" - ], - "HRS-09.1": [ - "19.10" - ], - "HRS-09.2": [ - "19.10" - ], - "HRS-09.3": [ - "19.10" - ], - "HRS-10": [ - "19.5" - ], - "HRS-11": [ - "4.11", - "10.4" - ], - "IAC-01": [ - "4.1", - "4.8", - "4.34", - "4.37", - "12.15", - "12.28", - "12.29" - ], - "IAC-02": [ - "4.2", - "4.31", - "4.34" - ], - "IAC-02.1": [ - "4.34" - ], - "IAC-02.2": [ - "4.31" - ], - "IAC-03": [ - "4.2", - "4.21" - ], - "IAC-04": [ - "4.33" - ], - "IAC-05": [ - "4.2" - ], - "IAC-06": [ - "4.21", - "4.32" - ], - "IAC-06.1": [ - "4.29" - ], - "IAC-06.3": [ - "4.30" - ], - "IAC-08": [ - "4.2", - "4.8", - "4.9", - "4.10", - "4.11", - "4.20", - "12.28", - "12.29" - ], - "IAC-09": [ - "12.15" - ], - "IAC-09.1": [ - "12.15" - ], - "IAC-10": [ - "4.35", - "12.15", - "12.16" - ], - "IAC-10.1": [ - "4.35", - "12.15", - "12.16" - ], - "IAC-10.2": [ - "12.15", - "12.16" - ], - "IAC-10.5": [ - "4.37" - ], - "IAC-11": [ - "4.36" - ], - "IAC-12": [ - "4.37" - ], - "IAC-15": [ - "4.3", - "4.4", - "4.6" - ], - "IAC-15.2": [ - "4.4" - ], - "IAC-15.3": [ - "4.5" - ], - "IAC-16": [ - "4.2" - ], - "IAC-17": [ - "4.3" - ], - "IAC-21": [ - "4.10", - "12.29" - ], - "IAC-22": [ - "4.14" - ], - "IAC-23": [ - "4.15" - ], - "IAC-24": [ - "4.16" - ], - "IRO-01": [ - "24.1" - ], - "IRO-02": [ - "7.2", - "24.2" - ], - "IRO-02.1": [ - "24.4" - ], - "IRO-04": [ - "7.2", - "24.2", - "24.3", - "24.8", - "24.9" - ], - "IRO-05": [ - "24.10", - "24.11" - ], - "IRO-06": [ - "24.10", - "24.11", - "24.12" - ], - "IRO-07": [ - "24.7", - "24.9" - ], - "IRO-09": [ - "24.5" - ], - "IRO-09.1": [ - "24.5" - ], - "IRO-10": [ - "24.6", - "24.8" - ], - "IRO-10.4": [ - "17.11" - ], - "IAO-01": [ - "10.6", - "16.5", - "17.1", - "17.16", - "17.18" - ], - "IAO-02": [ - "10.6", - "16.5", - "17.2", - "17.16", - "17.18" - ], - "IAO-02.1": [ - "17.2", - "17.16" - ], - "IAO-02.2": [ - "17.2", - "17.16" - ], - "IAO-02.3": [ - "17.2", - "17.16" - ], - "IAO-03.2": [ - "16.5" - ], - "IAO-06": [ - "10.6", - "16.5" - ], - "IAO-07": [ - "10.6", - "16.5" - ], - "MNT-05": [ - "4.18", - "12.7" - ], - "MNT-05.1": [ - "12.7" - ], - "MNT-05.2": [ - "12.7" - ], - "MNT-05.3": [ - "4.20", - "12.7" - ], - "MNT-05.4": [ - "4.18", - "4.20", - "12.7" - ], - "MNT-05.5": [ - "12.7" - ], - "MNT-06": [ - "12.7" - ], - "MNT-06.1": [ - "12.7" - ], - "MDM-01": [ - "4.25", - "4.28", - "13.1", - "13.3", - "13.5", - "13.8", - "13.9", - "13.10" - ], - "MDM-02": [ - "4.27", - "13.2", - "13.3", - "13.5", - "13.7", - "13.9" - ], - "MDM-03": [ - "4.26", - "8.7", - "13.4" - ], - "MDM-04": [ - "13.9" - ], - "MDM-05": [ - "13.8" - ], - "MDM-06": [ - "13.3", - "13.5" - ], - "MDM-07": [ - "13.3", - "13.5" - ], - "NET-01": [ - "9.1" - ], - "NET-02": [ - "9.17" - ], - "NET-02.1": [ - "9.3" - ], - "NET-02.2": [ - "9.18" - ], - "NET-03": [ - "9.3", - "9.18", - "9.23", - "10.9", - "11.8", - "16.4" - ], - "NET-03.1": [ - "9.10", - "9.11", - "16.4" - ], - "NET-03.2": [ - "9.5" - ], - "NET-03.3": [ - "9.19" - ], - "NET-04": [ - "9.12", - "9.16", - "10.9", - "12.11" - ], - "NET-04.1": [ - "9.12", - "12.9" - ], - "NET-04.3": [ - "9.16" - ], - "NET-04.4": [ - "9.16" - ], - "NET-04.6": [ - "9.24" - ], - "NET-05": [ - "16.4" - ], - "NET-05.1": [ - "9.11", - "12.8", - "16.4" - ], - "NET-06": [ - "9.2", - "9.18", - "9.19", - "10.8", - "12.4", - "12.5", - "12.11" - ], - "NET-06.1": [ - "9.2", - "12.4", - "12.5" - ], - "NET-07": [ - "4.16", - "9.4" - ], - "NET-08": [ - "7.4", - "7.6", - "12.18", - "23.6" - ], - "NET-08.2": [ - "4.24", - "12.18", - "23.6" - ], - "NET-09": [ - "17.25" - ], - "NET-10": [ - "9.6" - ], - "NET-10.1": [ - "9.7" - ], - "NET-10.2": [ - "9.7" - ], - "NET-12": [ - "8.4", - "8.6", - "9.20", - "13.6" - ], - "NET-14": [ - "4.17" - ], - "NET-14.1": [ - "4.18" - ], - "NET-14.2": [ - "9.8" - ], - "NET-14.3": [ - "4.19" - ], - "NET-14.4": [ - "4.17", - "4.20" - ], - "NET-15": [ - "4.24", - "12.12", - "12.14" - ], - "NET-15.1": [ - "12.14" - ], - "NET-15.2": [ - "4.24" - ], - "NET-15.3": [ - "12.13" - ], - "NET-15.4": [ - "4.23" - ], - "NET-18": [ - "9.14" - ], - "NET-18.1": [ - "9.14" - ], - "PES-01": [ - "9.15", - "12.27", - "18.1", - "18.2", - "18.10" - ], - "PES-02": [ - "12.27", - "18.3" - ], - "PES-02.1": [ - "12.27", - "18.4" - ], - "PES-03": [ - "9.15", - "12.27", - "18.4" - ], - "PES-03.1": [ - "12.27", - "18.6", - "18.8" - ], - "PES-03.2": [ - "18.6", - "18.11" - ], - "PES-03.3": [ - "18.5" - ], - "PES-04": [ - "9.15", - "18.6" - ], - "PES-04.1": [ - "18.6" - ], - "PES-05": [ - "18.8", - "18.10", - "18.11" - ], - "PES-05.1": [ - "18.9", - "18.11" - ], - "PES-06": [ - "18.3", - "18.12" - ], - "PES-07.3": [ - "18.14", - "18.15" - ], - "PES-07.4": [ - "18.16" - ], - "PES-07.5": [ - "18.19" - ], - "PES-08": [ - "18.17" - ], - "PES-08.1": [ - "18.17" - ], - "PES-08.2": [ - "18.17" - ], - "PES-09": [ - "18.18" - ], - "PES-09.1": [ - "18.18" - ], - "PES-10": [ - "18.20" - ], - "PES-11": [ - "18.21" - ], - "PES-12": [ - "18.7", - "18.13", - "18.22" - ], - "PES-12.1": [ - "9.15", - "18.13" - ], - "PES-12.2": [ - "18.7" - ], - "PRI-05": [ - "15.4" - ], - "PRI-07": [ - "10.5" - ], - "PRI-07.1": [ - "11.1" - ], - "PRM-01": [ - "17.5" - ], - "PRM-02": [ - "17.5", - "17.8", - "17.9" - ], - "PRM-03": [ - "17.5" - ], - "PRM-04": [ - "17.5", - "17.8", - "17.9" - ], - "PRM-05": [ - "17.5", - "17.6" - ], - "PRM-06": [ - "17.5", - "17.6" - ], - "PRM-07": [ - "17.4", - "17.5", - "17.8" - ], - "RSK-01": [ - "1.2", - "2.1", - "2.2" - ], - "RSK-01.1": [ - "2.2" - ], - "RSK-02": [ - "2.2" - ], - "RSK-03": [ - "1.2", - "2.2" - ], - "RSK-04": [ - "1.2", - "2.2" - ], - "RSK-04.1": [ - "2.2", - "6.8" - ], - "RSK-05": [ - "2.2" - ], - "RSK-07": [ - "2.2" - ], - "RSK-08": [ - "6.8", - "16.6" - ], - "RSK-09": [ - "16.3", - "17.3", - "17.11" - ], - "RSK-09.1": [ - "16.6", - "17.3", - "17.11" - ], - "RSK-10": [ - "16.6", - "17.3" - ], - "SEA-01": [ - "2.1", - "15.6", - "17.7" - ], - "SEA-02": [ - "2.1", - "15.6", - "17.7" - ], - "SEA-03": [ - "2.1", - "15.6", - "17.7" - ], - "SEA-05": [ - "10.5", - "10.8" - ], - "SEA-07.2": [ - "9.17" - ], - "SEA-11": [ - "23.5" - ], - "SEA-12": [ - "23.5" - ], - "OPS-01.1": [ - "12.2", - "12.3", - "18.2", - "22.2" - ], - "SAT-01": [ - "20.1" - ], - "SAT-02": [ - "20.2" - ], - "SAT-02.2": [ - "20.4" - ], - "SAT-03": [ - "20.2", - "25.3" - ], - "SAT-03.3": [ - "20.3" - ], - "TDA-01": [ - "17.1", - "17.9" - ], - "TDA-01.1": [ - "17.9" - ], - "TDA-02.1": [ - "12.9", - "12.29" - ], - "TDA-04": [ - "17.6", - "17.10" - ], - "TDA-04.1": [ - "17.6", - "17.10" - ], - "TDA-05": [ - "17.6" - ], - "TDA-06": [ - "11.9", - "17.6", - "17.9", - "17.20", - "17.25" - ], - "TDA-07": [ - "10.1" - ], - "TDA-08": [ - "10.1" - ], - "TDA-09": [ - "11.9", - "17.3", - "17.4", - "17.12", - "17.15" - ], - "TDA-09.1": [ - "17.3", - "17.4", - "17.12" - ], - "TDA-09.2": [ - "17.3", - "17.14" - ], - "TDA-09.3": [ - "17.3", - "17.19" - ], - "TDA-09.4": [ - "17.3", - "17.24" - ], - "TDA-09.5": [ - "11.9", - "17.3", - "17.15", - "17.17" - ], - "TDA-10": [ - "10.3" - ], - "TDA-11": [ - "17.21" - ], - "TDA-11.1": [ - "17.21" - ], - "TDA-14.1": [ - "17.20" - ], - "TDA-15": [ - "17.13" - ], - "TDA-17": [ - "12.23" - ], - "TDA-18": [ - "17.22" - ], - "TDA-19": [ - "17.23" - ], - "TPM-01": [ - "11.3", - "11.10", - "16.1", - "17.3" - ], - "TPM-02": [ - "16.1", - "16.6" - ], - "TPM-03": [ - "11.3", - "16.1", - "16.3", - "16.5", - "17.3", - "17.11" - ], - "TPM-03.1": [ - "16.1" - ], - "TPM-03.2": [ - "11.3", - "16.2" - ], - "TPM-04": [ - "11.3", - "16.1", - "22.4" - ], - "TPM-04.1": [ - "16.3", - "16.5", - "17.3" - ], - "TPM-04.2": [ - "16.3" - ], - "TPM-04.3": [ - "16.3" - ], - "TPM-04.4": [ - "16.3" - ], - "TPM-05": [ - "11.1", - "11.3", - "11.10", - "16.2", - "19.5", - "22.4", - "25.17" - ], - "TPM-06": [ - "11.1", - "11.3", - "18.10", - "19.5" - ], - "TPM-07": [ - "11.5", - "11.11" - ], - "TPM-08": [ - "11.4", - "11.5" - ], - "TPM-11": [ - "25.17" - ], - "THR-01": [ - "23.1", - "23.4" - ], - "THR-02": [ - "23.3" - ], - "THR-03": [ - "23.2" - ], - "VPM-01": [ - "22.1", - "22.2" - ], - "VPM-02": [ - "22.8", - "22.11", - "22.13" - ], - "VPM-03": [ - "22.8" - ], - "VPM-04": [ - "22.6", - "22.11" - ], - "VPM-04.1": [ - "12.22" - ], - "VPM-05": [ - "12.21" - ], - "VPM-05.1": [ - "12.21", - "22.11", - "22.12" - ], - "VPM-05.2": [ - "22.11", - "22.12" - ], - "VPM-05.3": [ - "12.22" - ], - "VPM-06": [ - "3.4", - "9.25", - "12.30", - "22.3", - "22.6" - ], - "VPM-06.1": [ - "22.7" - ], - "VPM-06.2": [ - "22.6" - ], - "VPM-06.3": [ - "22.9" - ], - "VPM-06.4": [ - "22.10" - ], - "VPM-06.5": [ - "22.10" - ], - "VPM-06.6": [ - "22.3" - ], - "VPM-06.7": [ - "22.3" - ], - "VPM-07": [ - "3.4", - "12.30", - "17.17", - "22.4", - "22.5" - ], - "VPM-07.1": [ - "17.16", - "17.17", - "22.4", - "22.5" - ] - } - }, - "framework_to_scf": { - "total_mappings": 323, - "mappings": { - "3.2": [ - "GOV-01" - ], - "4.25": [ - "GOV-01", - "GOV-02", - "MDM-01" - ], - "1.1": [ - "GOV-02", - "GOV-03" - ], - "4.1": [ - "GOV-02", - "IAC-01" - ], - "5.2": [ - "GOV-02", - "GOV-03", - "DCH-01" - ], - "5.3": [ - "GOV-02", - "DCH-01", - "DCH-02" - ], - "9.1": [ - "GOV-02", - "GOV-03", - "NET-01" - ], - "10.1": [ - "GOV-02", - "GOV-03", - "CLD-06", - "CFG-02.4", - "TDA-07", - "TDA-08" - ], - "11.2": [ - "GOV-02", - "GOV-03", - "CLD-01" - ], - "12.1": [ - "GOV-02", - "EMB-01" - ], - "13.1": [ - "GOV-02", - "GOV-03", - "MDM-01" - ], - "14.1": [ - "GOV-02", - "GOV-03", - "CFG-01" - ], - "15.1": [ - "GOV-02", - "GOV-03", - "DCH-01" - ], - "17.1": [ - "GOV-02", - "GOV-03", - "IAO-01", - "TDA-01" - ], - "18.1": [ - "GOV-02", - "GOV-03", - "PES-01" - ], - "20.1": [ - "GOV-02", - "SAT-01" - ], - "21.1": [ - "GOV-02", - "GOV-03", - "MON-01", - "MON-01.16" - ], - "22.1": [ - "GOV-02", - "GOV-03", - "VPM-01" - ], - "24.1": [ - "GOV-02", - "GOV-03", - "IRO-01" - ], - "25.1": [ - "GOV-02", - "GOV-03", - "BCD-01" - ], - "6.8": [ - "AST-02.4", - "MON-01", - "MON-01.16", - "RSK-04.1", - "RSK-08" - ], - "23.6": [ - "AST-02.5", - "MON-01.1", - "END-07", - "NET-08", - "NET-08.2" - ], - "3.1": [ - "AST-02.7", - "CPL-02", - "CPL-03", - "CPL-03.2" - ], - "15.4": [ - "AST-09", - "DCH-08", - "DCH-09", - "DCH-09.3", - "DCH-21", - "PRI-05" - ], - "17.21": [ - "AST-09", - "TDA-11", - "TDA-11.1" - ], - "11.12": [ - "AST-10", - "DCH-21" - ], - "12.6": [ - "AST-12", - "AST-13" - ], - "11.7": [ - "BCD-01", - "BCD-08", - "BCD-09" - ], - "25.2": [ - "BCD-01.1", - "CAP-01", - "CAP-03" - ], - "21.15": [ - "BCD-02.1", - "BCD-02.3", - "MON-08.1", - "MON-10", - "MON-13" - ], - "21.16": [ - "BCD-02.1", - "BCD-02.3", - "MON-08", - "CRY-01" - ], - "18.15": [ - "BCD-02.2", - "PES-07.3" - ], - "25.23": [ - "BCD-02.2", - "BCD-04" - ], - "25.3": [ - "BCD-03", - "SAT-03" - ], - "25.4": [ - "BCD-03.1", - "BCD-04" - ], - "25.5": [ - "BCD-03.1" - ], - "25.8": [ - "BCD-03.2" - ], - "25.6": [ - "BCD-04", - "BCD-04.1" - ], - "25.7": [ - "BCD-04", - "BCD-04.1", - "BCD-08", - "BCD-09" - ], - "25.9": [ - "BCD-04", - "BCD-11", - "BCD-11.1", - "BCD-12", - "BCD-12.1" - ], - "25.10": [ - "BCD-08", - "BCD-09" - ], - "25.11": [ - "BCD-08.1", - "BCD-09.1" - ], - "25.13": [ - "BCD-08.2", - "BCD-09.2" - ], - "25.12": [ - "BCD-09.3", - "BCD-11.3", - "BCD-12", - "BCD-12.2", - "BCD-13" - ], - "21.14": [ - "BCD-09.3", - "BCD-10", - "BCD-10.1", - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-09" - ], - "25.16": [ - "BCD-10" - ], - "25.17": [ - "BCD-10.1", - "TPM-05", - "TPM-11" - ], - "25.19": [ - "BCD-11.1" - ], - "25.20": [ - "BCD-11.2" - ], - "25.22": [ - "BCD-11.3", - "BCD-12" - ], - "25.18": [ - "BCD-11.4", - "BCD-13" - ], - "25.21": [ - "BCD-12.1" - ], - "12.26": [ - "BCD-12.2" - ], - "10.6": [ - "CHG-01", - "CHG-02", - "CHG-02.2", - "CHG-03", - "CHG-06", - "IAO-01", - "IAO-02", - "IAO-06", - "IAO-07" - ], - "14.6": [ - "CHG-01", - "CHG-02.2" - ], - "14.7": [ - "CHG-01", - "CHG-02", - "CHG-02.1" - ], - "12.21": [ - "CHG-02.2", - "VPM-05", - "VPM-05.1" - ], - "12.30": [ - "CHG-02.2", - "CHG-06", - "CPL-03.2", - "VPM-06", - "VPM-07" - ], - "14.8": [ - "CHG-02.2", - "CHG-02.3", - "CHG-03" - ], - "14.9": [ - "CHG-02.2" - ], - "14.10": [ - "CHG-02.2", - "CHG-06" - ], - "10.4": [ - "CHG-04.4", - "HRS-11" - ], - "9.2": [ - "CLD-03", - "NET-06", - "NET-06.1" - ], - "11.3": [ - "CLD-06", - "TPM-01", - "TPM-03", - "TPM-03.2", - "TPM-04", - "TPM-05", - "TPM-06" - ], - "11.6": [ - "CLD-10", - "DCH-01", - "DCH-01.1", - "DCH-13", - "DCH-13.3", - "DCH-19" - ], - "9.10": [ - "CLD-11", - "MON-01", - "MON-01.3", - "MON-01.16", - "NET-03.1" - ], - "11.8": [ - "CLD-11", - "NET-03" - ], - "16.4": [ - "CLD-11", - "NET-03", - "NET-03.1", - "NET-05", - "NET-05.1" - ], - "1.3": [ - "CPL-01", - "CPL-02" - ], - "3.3": [ - "CPL-03.2", - "CFG-01", - "CFG-02", - "CFG-02.1", - "CFG-02.2" - ], - "9.22": [ - "CFG-01", - "CFG-02.2", - "CFG-02.6" - ], - "9.23": [ - "CFG-01", - "CFG-02.2", - "NET-03" - ], - "4.9": [ - "CFG-02", - "CFG-03", - "IAC-08" - ], - "4.12": [ - "CFG-02", - "CFG-02.5" - ], - "4.15": [ - "CFG-02", - "CFG-03.4", - "IAC-23" - ], - "6.1": [ - "CFG-02" - ], - "9.21": [ - "CFG-02", - "CFG-02.5" - ], - "12.13": [ - "CFG-02", - "CFG-03", - "NET-15.3" - ], - "12.24": [ - "CFG-02", - "DCH-12", - "END-07" - ], - "12.29": [ - "CFG-02", - "IAC-01", - "IAC-08", - "IAC-21", - "TDA-02.1" - ], - "13.5": [ - "CFG-02", - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07" - ], - "13.6": [ - "CFG-02", - "CRY-03", - "CRY-04", - "NET-12" - ], - "14.2": [ - "CFG-02" - ], - "15.6": [ - "CFG-02", - "DCH-01", - "HRS-05.1", - "HRS-05.3", - "HRS-05.4", - "HRS-05.5", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "14.3": [ - "CFG-02.1", - "CFG-02.2" - ], - "6.2": [ - "CFG-02.2" - ], - "6.4": [ - "CFG-02.2", - "MON-01.7", - "END-06" - ], - "14.4": [ - "CFG-02.2" - ], - "14.5": [ - "CFG-02.3" - ], - "10.2": [ - "CFG-02.4" - ], - "10.7": [ - "CFG-02.5", - "CFG-02.9" - ], - "4.8": [ - "CFG-03", - "IAC-01", - "IAC-08" - ], - "12.9": [ - "CFG-03", - "NET-04.1", - "TDA-02.1" - ], - "6.7": [ - "CFG-03.3" - ], - "9.13": [ - "CFG-03.4" - ], - "6.3": [ - "CFG-05", - "CFG-05.2", - "END-03", - "END-03.1" - ], - "4.6": [ - "MON-01", - "MON-01.16", - "MON-02", - "MON-02.1", - "MON-03", - "IAC-15" - ], - "11.11": [ - "MON-01", - "MON-01.1", - "MON-01.2", - "MON-01.16", - "TPM-07" - ], - "12.31": [ - "MON-01", - "MON-01.2", - "MON-01.8", - "MON-01.16" - ], - "13.9": [ - "MON-01", - "MON-01.16", - "MDM-01", - "MDM-02", - "MDM-04" - ], - "7.4": [ - "MON-01.1", - "END-07", - "NET-08" - ], - "12.18": [ - "MON-01.1", - "END-07", - "NET-08", - "NET-08.2" - ], - "9.9": [ - "MON-01.3" - ], - "10.9": [ - "MON-01.3", - "NET-03", - "NET-04" - ], - "21.2": [ - "MON-01.4", - "MON-03" - ], - "21.4": [ - "MON-01.4", - "MON-02", - "MON-03.1", - "MON-08", - "MON-10" - ], - "7.6": [ - "MON-01.5", - "NET-08" - ], - "12.19": [ - "MON-01.7", - "END-06" - ], - "21.3": [ - "MON-01.8", - "MON-02", - "MON-06" - ], - "21.11": [ - "MON-01.8", - "MON-06" - ], - "9.14": [ - "MON-01.9", - "NET-18", - "NET-18.1" - ], - "21.20": [ - "MON-01.9", - "MON-06", - "MON-16" - ], - "12.17": [ - "MON-02", - "MON-02.1", - "MON-03", - "MON-03.2" - ], - "21.6": [ - "MON-02", - "MON-02.1" - ], - "21.12": [ - "MON-02", - "MON-02.1" - ], - "21.13": [ - "MON-02.1" - ], - "21.19": [ - "MON-02.1", - "MON-06" - ], - "21.5": [ - "MON-03", - "MON-03.4" - ], - "21.7": [ - "MON-03" - ], - "21.10": [ - "MON-03", - "MON-03.3", - "MON-12", - "MON-15", - "MON-16", - "MON-16.1", - "MON-16.2", - "MON-16.3" - ], - "21.21": [ - "MON-03.3", - "MON-03.4" - ], - "21.8": [ - "MON-04" - ], - "21.9": [ - "MON-05", - "MON-05.1" - ], - "21.17": [ - "MON-08.1", - "MON-10" - ], - "21.18": [ - "MON-12" - ], - "4.7": [ - "MON-16" - ], - "8.1": [ - "CRY-01" - ], - "8.8": [ - "CRY-01" - ], - "15.7": [ - "CRY-01", - "CRY-01.1", - "CRY-05", - "CRY-05.1", - "DCH-01", - "DCH-07", - "DCH-07.1" - ], - "4.37": [ - "CRY-02", - "END-09", - "IAC-01", - "IAC-10.5", - "IAC-12" - ], - "12.10": [ - "CRY-02", - "CRY-03", - "CRY-04" - ], - "4.22": [ - "CRY-03", - "CRY-04", - "CRY-07" - ], - "8.4": [ - "CRY-03", - "NET-12" - ], - "8.5": [ - "CRY-03" - ], - "8.6": [ - "CRY-03", - "NET-12" - ], - "9.8": [ - "CRY-03", - "CRY-04", - "NET-14.2" - ], - "9.20": [ - "CRY-03", - "CRY-04", - "NET-12" - ], - "8.7": [ - "CRY-05", - "MDM-03" - ], - "8.2": [ - "CRY-08", - "CRY-09" - ], - "8.9": [ - "CRY-08", - "CRY-09", - "CRY-09.4" - ], - "8.10": [ - "CRY-09" - ], - "8.3": [ - "CRY-09.3" - ], - "8.11": [ - "CRY-09.3", - "CRY-09.4" - ], - "5.1": [ - "DCH-01", - "DCH-17", - "HRS-05", - "HRS-05.1" - ], - "5.5": [ - "DCH-01" - ], - "15.2": [ - "DCH-02", - "DCH-04" - ], - "10.5": [ - "DCH-03.1", - "DCH-14", - "DCH-17", - "DCH-25", - "PRI-07", - "SEA-05" - ], - "15.3": [ - "DCH-06" - ], - "15.8": [ - "DCH-09.1", - "DCH-09.2" - ], - "5.4": [ - "DCH-14", - "DCH-17", - "HRS-05.3" - ], - "12.2": [ - "EMB-01", - "OPS-01.1" - ], - "12.3": [ - "EMB-01", - "OPS-01.1" - ], - "7.1": [ - "END-01", - "END-02", - "END-04" - ], - "7.3": [ - "END-01", - "END-02", - "END-04" - ], - "15.5": [ - "END-01", - "END-02", - "END-04" - ], - "12.20": [ - "END-04", - "END-04.3", - "END-04.6" - ], - "7.9": [ - "END-04.1" - ], - "7.7": [ - "END-04.3" - ], - "7.8": [ - "END-04.4" - ], - "7.5": [ - "END-04.7", - "END-07" - ], - "12.25": [ - "END-04.7" - ], - "7.2": [ - "END-06.2", - "IRO-02", - "IRO-04" - ], - "5.6": [ - "END-14" - ], - "19.1": [ - "HRS-01", - "HRS-02" - ], - "4.13": [ - "HRS-03", - "HRS-05.2" - ], - "18.10": [ - "HRS-03", - "PES-01", - "PES-05", - "TPM-06" - ], - "19.2": [ - "HRS-04", - "HRS-04.1" - ], - "19.3": [ - "HRS-05", - "HRS-05.1" - ], - "19.4": [ - "HRS-05", - "HRS-06.1" - ], - "19.6": [ - "HRS-05.1", - "HRS-05.2", - "HRS-05.3", - "HRS-05.4", - "HRS-05.5", - "HRS-06" - ], - "19.7": [ - "HRS-05.2" - ], - "9.5": [ - "HRS-05.3", - "NET-03.2" - ], - "13.2": [ - "HRS-05.5", - "MDM-02" - ], - "13.3": [ - "HRS-05.5", - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07" - ], - "13.7": [ - "HRS-05.5", - "MDM-02" - ], - "13.10": [ - "HRS-05.5", - "MDM-01" - ], - "19.8": [ - "HRS-07" - ], - "19.9": [ - "HRS-08", - "HRS-09" - ], - "19.10": [ - "HRS-09", - "HRS-09.1", - "HRS-09.2", - "HRS-09.3" - ], - "19.5": [ - "HRS-10", - "TPM-05", - "TPM-06" - ], - "4.11": [ - "HRS-11", - "IAC-08" - ], - "4.34": [ - "IAC-01", - "IAC-02", - "IAC-02.1" - ], - "12.15": [ - "IAC-01", - "IAC-09", - "IAC-09.1", - "IAC-10", - "IAC-10.1", - "IAC-10.2" - ], - "12.28": [ - "IAC-01", - "IAC-08" - ], - "4.2": [ - "IAC-02", - "IAC-03", - "IAC-05", - "IAC-08", - "IAC-16" - ], - "4.31": [ - "IAC-02", - "IAC-02.2" - ], - "4.21": [ - "IAC-03", - "IAC-06" - ], - "4.33": [ - "IAC-04" - ], - "4.32": [ - "IAC-06" - ], - "4.29": [ - "IAC-06.1" - ], - "4.30": [ - "IAC-06.3" - ], - "4.10": [ - "IAC-08", - "IAC-21" - ], - "4.20": [ - "IAC-08", - "MNT-05.3", - "MNT-05.4", - "NET-14.4" - ], - "4.35": [ - "IAC-10", - "IAC-10.1" - ], - "12.16": [ - "IAC-10", - "IAC-10.1", - "IAC-10.2" - ], - "4.36": [ - "IAC-11" - ], - "4.3": [ - "IAC-15", - "IAC-17" - ], - "4.4": [ - "IAC-15", - "IAC-15.2" - ], - "4.5": [ - "IAC-15.3" - ], - "4.14": [ - "IAC-22" - ], - "4.16": [ - "IAC-24", - "NET-07" - ], - "24.2": [ - "IRO-02", - "IRO-04" - ], - "24.4": [ - "IRO-02.1" - ], - "24.3": [ - "IRO-04" - ], - "24.8": [ - "IRO-04", - "IRO-10" - ], - "24.9": [ - "IRO-04", - "IRO-07" - ], - "24.10": [ - "IRO-05", - "IRO-06" - ], - "24.11": [ - "IRO-05", - "IRO-06" - ], - "24.12": [ - "IRO-06" - ], - "24.7": [ - "IRO-07" - ], - "24.5": [ - "IRO-09", - "IRO-09.1" - ], - "24.6": [ - "IRO-10" - ], - "17.11": [ - "IRO-10.4", - "RSK-09", - "RSK-09.1", - "TPM-03" - ], - "16.5": [ - "IAO-01", - "IAO-02", - "IAO-03.2", - "IAO-06", - "IAO-07", - "TPM-03", - "TPM-04.1" - ], - "17.16": [ - "IAO-01", - "IAO-02", - "IAO-02.1", - "IAO-02.2", - "IAO-02.3", - "VPM-07.1" - ], - "17.18": [ - "IAO-01", - "IAO-02" - ], - "17.2": [ - "IAO-02", - "IAO-02.1", - "IAO-02.2", - "IAO-02.3" - ], - "4.18": [ - "MNT-05", - "MNT-05.4", - "NET-14.1" - ], - "12.7": [ - "MNT-05", - "MNT-05.1", - "MNT-05.2", - "MNT-05.3", - "MNT-05.4", - "MNT-05.5", - "MNT-06", - "MNT-06.1" - ], - "4.28": [ - "MDM-01" - ], - "13.8": [ - "MDM-01", - "MDM-05" - ], - "4.27": [ - "MDM-02" - ], - "4.26": [ - "MDM-03" - ], - "13.4": [ - "MDM-03" - ], - "9.17": [ - "NET-02", - "SEA-07.2" - ], - "9.3": [ - "NET-02.1", - "NET-03" - ], - "9.18": [ - "NET-02.2", - "NET-03", - "NET-06" - ], - "9.11": [ - "NET-03.1", - "NET-05.1" - ], - "9.19": [ - "NET-03.3", - "NET-06" - ], - "9.12": [ - "NET-04", - "NET-04.1" - ], - "9.16": [ - "NET-04", - "NET-04.3", - "NET-04.4" - ], - "12.11": [ - "NET-04", - "NET-06" - ], - "9.24": [ - "NET-04.6" - ], - "12.8": [ - "NET-05.1" - ], - "10.8": [ - "NET-06", - "SEA-05" - ], - "12.4": [ - "NET-06", - "NET-06.1" - ], - "12.5": [ - "NET-06", - "NET-06.1" - ], - "9.4": [ - "NET-07" - ], - "4.24": [ - "NET-08.2", - "NET-15", - "NET-15.2" - ], - "17.25": [ - "NET-09", - "TDA-06" - ], - "9.6": [ - "NET-10" - ], - "9.7": [ - "NET-10.1", - "NET-10.2" - ], - "4.17": [ - "NET-14", - "NET-14.4" - ], - "4.19": [ - "NET-14.3" - ], - "12.12": [ - "NET-15" - ], - "12.14": [ - "NET-15", - "NET-15.1" - ], - "4.23": [ - "NET-15.4" - ], - "9.15": [ - "PES-01", - "PES-03", - "PES-04", - "PES-12.1" - ], - "12.27": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-03.1" - ], - "18.2": [ - "PES-01", - "OPS-01.1" - ], - "18.3": [ - "PES-02", - "PES-06" - ], - "18.4": [ - "PES-02.1", - "PES-03" - ], - "18.6": [ - "PES-03.1", - "PES-03.2", - "PES-04", - "PES-04.1" - ], - "18.8": [ - "PES-03.1", - "PES-05" - ], - "18.11": [ - "PES-03.2", - "PES-05", - "PES-05.1" - ], - "18.5": [ - "PES-03.3" - ], - "18.9": [ - "PES-05.1" - ], - "18.12": [ - "PES-06" - ], - "18.14": [ - "PES-07.3" - ], - "18.16": [ - "PES-07.4" - ], - "18.19": [ - "PES-07.5" - ], - "18.17": [ - "PES-08", - "PES-08.1", - "PES-08.2" - ], - "18.18": [ - "PES-09", - "PES-09.1" - ], - "18.20": [ - "PES-10" - ], - "18.21": [ - "PES-11" - ], - "18.7": [ - "PES-12", - "PES-12.2" - ], - "18.13": [ - "PES-12", - "PES-12.1" - ], - "18.22": [ - "PES-12" - ], - "11.1": [ - "PRI-07.1", - "TPM-05", - "TPM-06" - ], - "17.5": [ - "PRM-01", - "PRM-02", - "PRM-03", - "PRM-04", - "PRM-05", - "PRM-06", - "PRM-07" - ], - "17.8": [ - "PRM-02", - "PRM-04", - "PRM-07" - ], - "17.9": [ - "PRM-02", - "PRM-04", - "TDA-01", - "TDA-01.1", - "TDA-06" - ], - "17.6": [ - "PRM-05", - "PRM-06", - "TDA-04", - "TDA-04.1", - "TDA-05", - "TDA-06" - ], - "17.4": [ - "PRM-07", - "TDA-09", - "TDA-09.1" - ], - "1.2": [ - "RSK-01", - "RSK-03", - "RSK-04" - ], - "2.1": [ - "RSK-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "2.2": [ - "RSK-01", - "RSK-01.1", - "RSK-02", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-07" - ], - "16.6": [ - "RSK-08", - "RSK-09.1", - "RSK-10", - "TPM-02" - ], - "16.3": [ - "RSK-09", - "TPM-03", - "TPM-04.1", - "TPM-04.2", - "TPM-04.3", - "TPM-04.4" - ], - "17.3": [ - "RSK-09", - "RSK-09.1", - "RSK-10", - "TDA-09", - "TDA-09.1", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5", - "TPM-01", - "TPM-03", - "TPM-04.1" - ], - "17.7": [ - "SEA-01", - "SEA-02", - "SEA-03" - ], - "23.5": [ - "SEA-11", - "SEA-12" - ], - "22.2": [ - "OPS-01.1", - "VPM-01" - ], - "20.2": [ - "SAT-02", - "SAT-03" - ], - "20.4": [ - "SAT-02.2" - ], - "20.3": [ - "SAT-03.3" - ], - "17.10": [ - "TDA-04", - "TDA-04.1" - ], - "11.9": [ - "TDA-06", - "TDA-09", - "TDA-09.5" - ], - "17.20": [ - "TDA-06", - "TDA-14.1" - ], - "17.12": [ - "TDA-09", - "TDA-09.1" - ], - "17.15": [ - "TDA-09", - "TDA-09.5" - ], - "17.14": [ - "TDA-09.2" - ], - "17.19": [ - "TDA-09.3" - ], - "17.24": [ - "TDA-09.4" - ], - "17.17": [ - "TDA-09.5", - "VPM-07", - "VPM-07.1" - ], - "10.3": [ - "TDA-10" - ], - "17.13": [ - "TDA-15" - ], - "12.23": [ - "TDA-17" - ], - "17.22": [ - "TDA-18" - ], - "17.23": [ - "TDA-19" - ], - "11.10": [ - "TPM-01", - "TPM-05" - ], - "16.1": [ - "TPM-01", - "TPM-02", - "TPM-03", - "TPM-03.1", - "TPM-04" - ], - "16.2": [ - "TPM-03.2", - "TPM-05" - ], - "22.4": [ - "TPM-04", - "TPM-05", - "VPM-07", - "VPM-07.1" - ], - "11.5": [ - "TPM-07", - "TPM-08" - ], - "11.4": [ - "TPM-08" - ], - "23.1": [ - "THR-01" - ], - "23.4": [ - "THR-01" - ], - "23.3": [ - "THR-02" - ], - "23.2": [ - "THR-03" - ], - "22.8": [ - "VPM-02", - "VPM-03" - ], - "22.11": [ - "VPM-02", - "VPM-04", - "VPM-05.1", - "VPM-05.2" - ], - "22.13": [ - "VPM-02" - ], - "22.6": [ - "VPM-04", - "VPM-06", - "VPM-06.2" - ], - "12.22": [ - "VPM-04.1", - "VPM-05.3" - ], - "22.12": [ - "VPM-05.1", - "VPM-05.2" - ], - "3.4": [ - "VPM-06", - "VPM-07" - ], - "9.25": [ - "VPM-06" - ], - "22.3": [ - "VPM-06", - "VPM-06.6", - "VPM-06.7" - ], - "22.7": [ - "VPM-06.1" - ], - "22.9": [ - "VPM-06.3" - ], - "22.10": [ - "VPM-06.4", - "VPM-06.5" - ], - "22.5": [ - "VPM-07", - "VPM-07.1" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-isr-cmo-2-0.json b/docs/api/crosswalks/emea-isr-cmo-2-0.json new file mode 100644 index 00000000..3ce96649 --- /dev/null +++ b/docs/api/crosswalks/emea-isr-cmo-2-0.json @@ -0,0 +1,396 @@ +{ + "framework_id": "emea-isr-cmo-2-0", + "display_name": "Ireland - Cybersecurity Methodology for an Organization (CMO) v2.0", + "scf_to_framework": { + "total_mappings": 67, + "mappings": { + "GOV-01": [ + "2.A", + "4.2, Stage 0" + ], + "GOV-01.1": [ + "2.A" + ], + "GOV-01.3": [ + "4.1, Stage 5", + "Appendix A, 1.1" + ], + "GOV-03": [ + "Appendix A, 1.1" + ], + "GOV-04": [ + "4.2, Stage 1.1" + ], + "GOV-04.1": [ + "4.2, Stage 1.1" + ], + "GOV-04.2": [ + "4.2, Stage 1.1" + ], + "GOV-05": [ + "4.2, Stage 5", + "Appendix D" + ], + "AST-02": [ + "4.1, Stage 1" + ], + "AST-04": [ + "4.1, Stage 1" + ], + "BCD-11": [ + "Appendix A, 14.1" + ], + "CAP-02": [ + "Appendix A, 7.1" + ], + "CLD-02": [ + "Appendix A, 6.1" + ], + "CLD-06.1": [ + "Appendix A, 5.1" + ], + "CLD-10": [ + "Appendix A, 6.1" + ], + "CPL-02": [ + "4.1, Stage 5" + ], + "CPL-02.1": [ + "4.1, Stage 5" + ], + "CPL-03": [ + "4.2, Stage 5" + ], + "CFG-02": [ + "Appendix A, 3.1", + "Appendix A, 4.1", + "Appendix A, 4.2" + ], + "MON-03": [ + "Appendix A, 12.2" + ], + "CRY-01": [ + "Appendix A, 3.1" + ], + "DCH-01.2": [ + "Appendix A, 5.2" + ], + "DCH-02": [ + "Appendix A, 5.2" + ], + "DCH-14": [ + "Appendix A, 5.2" + ], + "END-04": [ + "Appendix A, 2.1" + ], + "END-04.1": [ + "Appendix A, 2.2" + ], + "END-04.7": [ + "Appendix A, 2.1" + ], + "HRS-05.1": [ + "Appendix A, 9.1" + ], + "HRS-08": [ + "Appendix A, 9.2" + ], + "HRS-09": [ + "Appendix A, 9.2" + ], + "IAC-01": [ + "Appendix A, 8.2" + ], + "IAC-07": [ + "Appendix A, 9.2" + ], + "IAC-07.1": [ + "Appendix A, 9.2" + ], + "IAC-07.2": [ + "Appendix A, 9.2" + ], + "IAC-15": [ + "Appendix A, 8.1" + ], + "IRO-02": [ + "Appendix A, 12.1" + ], + "IRO-02.4": [ + "Appendix B" + ], + "IRO-09": [ + "Appendix A, 13.1" + ], + "IAO-01.1": [ + "4.2, Stage 1.3" + ], + "IAO-05": [ + "4.2, Stage 4" + ], + "NET-03": [ + "Appendix A, 7.3" + ], + "NET-03.1": [ + "Appendix A, 7.4" + ], + "NET-04.1": [ + "Appendix A, 7.4" + ], + "NET-06.9": [ + "Appendix A, 7.5" + ], + "NET-10": [ + "Appendix A, 7.2" + ], + "PES-07.4": [ + "Appendix A, 11.1" + ], + "PES-08": [ + "Appendix A, 11.2" + ], + "PRI-01": [ + "Appendix F" + ], + "PRM-01": [ + "4.1, Stage 4" + ], + "PRM-01.1": [ + "2.A", + "4.1, Stage 4", + "4.2, Stage 1.2" + ], + "PRM-01.2": [ + "4.1, Stages 2-3" + ], + "PRM-02.1": [ + "2.D", + "4.1, Stage 4" + ], + "PRM-03": [ + "4.1, Stage 4" + ], + "RSK-01": [ + "3" + ], + "RSK-01.1": [ + "4.2, Stage 2.1" + ], + "RSK-03": [ + "4.2, Stage 2.1" + ], + "RSK-04": [ + "4.2, Stage 2.2", + "4.2, Stage 2.3" + ], + "RSK-04.1": [ + "4.2, Stage 2.2" + ], + "RSK-06": [ + "4.2, Stage 2.3" + ], + "RSK-06.3": [ + "4.2, Stage 3.1" + ], + "RSK-06.4": [ + "4.2, Stage 4" + ], + "SEA-01.1": [ + "Appendix C" + ], + "SEA-03": [ + "2.E" + ], + "OPS-02": [ + "4.2, Stage 1.2" + ], + "TPM-01": [ + "Appendix A, 10.1" + ], + "THR-01": [ + "2.B" + ], + "THR-10": [ + "Appendix B" + ] + } + }, + "framework_to_scf": { + "total_mappings": 48, + "mappings": { + "3": [ + "RSK-01" + ], + "2.A": [ + "GOV-01", + "GOV-01.1", + "PRM-01.1" + ], + "4.2, Stage 0": [ + "GOV-01" + ], + "4.1, Stage 5": [ + "GOV-01.3", + "CPL-02", + "CPL-02.1" + ], + "Appendix A, 1.1": [ + "GOV-01.3", + "GOV-03" + ], + "4.2, Stage 1.1": [ + "GOV-04", + "GOV-04.1", + "GOV-04.2" + ], + "4.2, Stage 5": [ + "GOV-05", + "CPL-03" + ], + "Appendix D": [ + "GOV-05" + ], + "4.1, Stage 1": [ + "AST-02", + "AST-04" + ], + "Appendix A, 14.1": [ + "BCD-11" + ], + "Appendix A, 7.1": [ + "CAP-02" + ], + "Appendix A, 6.1": [ + "CLD-02", + "CLD-10" + ], + "Appendix A, 5.1": [ + "CLD-06.1" + ], + "Appendix A, 3.1": [ + "CFG-02", + "CRY-01" + ], + "Appendix A, 4.1": [ + "CFG-02" + ], + "Appendix A, 4.2": [ + "CFG-02" + ], + "Appendix A, 12.2": [ + "MON-03" + ], + "Appendix A, 5.2": [ + "DCH-01.2", + "DCH-02", + "DCH-14" + ], + "Appendix A, 2.1": [ + "END-04", + "END-04.7" + ], + "Appendix A, 2.2": [ + "END-04.1" + ], + "Appendix A, 9.1": [ + "HRS-05.1" + ], + "Appendix A, 9.2": [ + "HRS-08", + "HRS-09", + "IAC-07", + "IAC-07.1", + "IAC-07.2" + ], + "Appendix A, 8.2": [ + "IAC-01" + ], + "Appendix A, 8.1": [ + "IAC-15" + ], + "Appendix A, 12.1": [ + "IRO-02" + ], + "Appendix B": [ + "IRO-02.4", + "THR-10" + ], + "Appendix A, 13.1": [ + "IRO-09" + ], + "4.2, Stage 1.3": [ + "IAO-01.1" + ], + "4.2, Stage 4": [ + "IAO-05", + "RSK-06.4" + ], + "Appendix A, 7.3": [ + "NET-03" + ], + "Appendix A, 7.4": [ + "NET-03.1", + "NET-04.1" + ], + "Appendix A, 7.5": [ + "NET-06.9" + ], + "Appendix A, 7.2": [ + "NET-10" + ], + "Appendix A, 11.1": [ + "PES-07.4" + ], + "Appendix A, 11.2": [ + "PES-08" + ], + "Appendix F": [ + "PRI-01" + ], + "4.1, Stage 4": [ + "PRM-01", + "PRM-01.1", + "PRM-02.1", + "PRM-03" + ], + "4.2, Stage 1.2": [ + "PRM-01.1", + "OPS-02" + ], + "4.1, Stages 2-3": [ + "PRM-01.2" + ], + "2.D": [ + "PRM-02.1" + ], + "4.2, Stage 2.1": [ + "RSK-01.1", + "RSK-03" + ], + "4.2, Stage 2.2": [ + "RSK-04", + "RSK-04.1" + ], + "4.2, Stage 2.3": [ + "RSK-04", + "RSK-06" + ], + "4.2, Stage 3.1": [ + "RSK-06.3" + ], + "Appendix C": [ + "SEA-01.1" + ], + "2.E": [ + "SEA-03" + ], + "Appendix A, 10.1": [ + "TPM-01" + ], + "2.B": [ + "THR-01" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-isr-ppl-5741-1981.json b/docs/api/crosswalks/emea-isr-ppl-5741-1981.json deleted file mode 100644 index 25459278..00000000 --- a/docs/api/crosswalks/emea-isr-ppl-5741-1981.json +++ /dev/null @@ -1,148 +0,0 @@ -{ - "framework_id": "emea-isr-ppl-5741-1981", - "display_name": "Israel - Protection of Privacy Law, 5741 (1981)", - "scf_to_framework": { - "total_mappings": 22, - "mappings": { - "GOV-01": [ - "16", - "17" - ], - "CPL-01": [ - "16", - "17" - ], - "CPL-02": [ - "16", - "17" - ], - "CPL-03": [ - "16", - "17" - ], - "DCH-01": [ - "16", - "17" - ], - "DCH-22.1": [ - "14" - ], - "DCH-24": [ - "16", - "17" - ], - "DCH-24.1": [ - "16", - "17" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-01.1": [ - "16", - "17" - ], - "PRI-02.1": [ - "8" - ], - "PRI-05": [ - "8" - ], - "PRI-05.1": [ - "8" - ], - "PRI-05.4": [ - "8" - ], - "PRI-06": [ - "13" - ], - "PRI-06.1": [ - "14" - ], - "PRI-15": [ - "8", - "9" - ], - "SEA-01": [ - "16", - "17" - ], - "SEA-02": [ - "16", - "17" - ], - "SEA-03": [ - "16", - "17" - ], - "SEA-15": [ - "16", - "17" - ], - "TPM-04.4": [ - "16", - "17" - ] - } - }, - "framework_to_scf": { - "total_mappings": 8, - "mappings": { - "8": [ - "PRI-02.1", - "PRI-05", - "PRI-05.1", - "PRI-05.4", - "PRI-15" - ], - "9": [ - "PRI-15" - ], - "13": [ - "PRI-06" - ], - "14": [ - "DCH-22.1", - "PRI-06.1" - ], - "16": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "PRI-01.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "17": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "PRI-01.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-isr-ppl-5741-2025.json b/docs/api/crosswalks/emea-isr-ppl-5741-2025.json new file mode 100644 index 00000000..c37e7200 --- /dev/null +++ b/docs/api/crosswalks/emea-isr-ppl-5741-2025.json @@ -0,0 +1,120 @@ +{ + "framework_id": "emea-isr-ppl-5741-2025", + "display_name": "Israel - Protection of Privacy Law, 5741 (2025)", + "scf_to_framework": { + "total_mappings": 13, + "mappings": { + "GOV-04": [ + "s.17B" + ], + "HRS-03": [ + "s.17B2" + ], + "HRS-03.2": [ + "s.17B3" + ], + "HRS-06.1": [ + "s.16" + ], + "PRI-01.4": [ + "s.17B1", + "s.17B2" + ], + "PRI-01.6": [ + "s.17" + ], + "PRI-01.11": [ + "s.1", + "s.2", + "s.2A", + "s.3", + "s.16" + ], + "PRI-02": [ + "s.11" + ], + "PRI-03": [ + "s.1" + ], + "PRI-06": [ + "s.13", + "s.14" + ], + "PRI-06.1": [ + "s.14" + ], + "PRI-07.1": [ + "s.13A" + ], + "PRI-15": [ + "s.8", + "s.8A", + "s.9", + "s.10" + ] + } + }, + "framework_to_scf": { + "total_mappings": 18, + "mappings": { + "s.17B": [ + "GOV-04" + ], + "s.17B2": [ + "HRS-03", + "PRI-01.4" + ], + "s.17B3": [ + "HRS-03.2" + ], + "s.16": [ + "HRS-06.1", + "PRI-01.11" + ], + "s.17B1": [ + "PRI-01.4" + ], + "s.17": [ + "PRI-01.6" + ], + "s.1": [ + "PRI-01.11", + "PRI-03" + ], + "s.2": [ + "PRI-01.11" + ], + "s.2A": [ + "PRI-01.11" + ], + "s.3": [ + "PRI-01.11" + ], + "s.11": [ + "PRI-02" + ], + "s.13": [ + "PRI-06" + ], + "s.14": [ + "PRI-06", + "PRI-06.1" + ], + "s.13A": [ + "PRI-07.1" + ], + "s.8": [ + "PRI-15" + ], + "s.8A": [ + "PRI-15" + ], + "s.9": [ + "PRI-15" + ], + "s.10": [ + "PRI-15" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-ita-pdpc-2003.json b/docs/api/crosswalks/emea-ita-pdpc-2003.json deleted file mode 100644 index 7923f2f6..00000000 --- a/docs/api/crosswalks/emea-ita-pdpc-2003.json +++ /dev/null @@ -1,228 +0,0 @@ -{ - "framework_id": "emea-ita-pdpc-2003", - "display_name": "Italy - Personal Data Protection Code (2003)", - "scf_to_framework": { - "total_mappings": 28, - "mappings": { - "GOV-01": [ - "31", - "33", - "34", - "35" - ], - "CPL-01": [ - "26", - "31", - "33", - "34", - "35" - ], - "CPL-02": [ - "31", - "33", - "34", - "35" - ], - "CPL-03": [ - "31" - ], - "DCH-01": [ - "31", - "33", - "34", - "35", - "42" - ], - "DCH-22.1": [ - "7" - ], - "DCH-24": [ - "31" - ], - "DCH-24.1": [ - "31" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-01.1": [ - "30" - ], - "PRI-02": [ - "11", - "13", - "37" - ], - "PRI-02.1": [ - "13" - ], - "PRI-03": [ - "23", - "24" - ], - "PRI-04": [ - "11" - ], - "PRI-04.1": [ - "11" - ], - "PRI-05": [ - "11" - ], - "PRI-05.1": [ - "13", - "20" - ], - "PRI-05.4": [ - "13", - "20" - ], - "PRI-06": [ - "7" - ], - "PRI-06.1": [ - "7" - ], - "PRI-06.2": [ - "10" - ], - "PRI-06.4": [ - "9" - ], - "PRI-15": [ - "26", - "37" - ], - "SEA-01": [ - "31", - "33", - "34", - "35", - "42" - ], - "SEA-02": [ - "31", - "33", - "34", - "35", - "42" - ], - "SEA-03": [ - "31", - "33", - "34", - "35", - "42" - ], - "SEA-15": [ - "31" - ], - "TPM-04.4": [ - "31" - ] - } - }, - "framework_to_scf": { - "total_mappings": 18, - "mappings": { - "7": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1" - ], - "9": [ - "PRI-06.4" - ], - "10": [ - "PRI-06.2" - ], - "11": [ - "PRI-02", - "PRI-04", - "PRI-04.1", - "PRI-05" - ], - "13": [ - "PRI-02", - "PRI-02.1", - "PRI-05.1", - "PRI-05.4" - ], - "20": [ - "PRI-05.1", - "PRI-05.4" - ], - "23": [ - "PRI-03" - ], - "24": [ - "PRI-03" - ], - "26": [ - "CPL-01", - "PRI-15" - ], - "30": [ - "PRI-01.1" - ], - "31": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "33": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "34": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "35": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "37": [ - "PRI-02", - "PRI-15" - ], - "42": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-ita-pdpc-2018.json b/docs/api/crosswalks/emea-ita-pdpc-2018.json new file mode 100644 index 00000000..a39b7ad8 --- /dev/null +++ b/docs/api/crosswalks/emea-ita-pdpc-2018.json @@ -0,0 +1,222 @@ +{ + "framework_id": "emea-ita-pdpc-2018", + "display_name": "Italy - Personal Data Protection Code (2018)", + "scf_to_framework": { + "total_mappings": 13, + "mappings": { + "CPL-01": [ + "Article 1(1)" + ], + "HRS-03": [ + "Article 2-o(1)", + "Article 2-o(2)" + ], + "PRI-01.4": [ + "Article 2-q(1)" + ], + "PRI-01.6": [ + "Article 115(1)", + "Article 115(2)" + ], + "PRI-01.11": [ + "Article 75(1)", + "Article 102(1)", + "Article 102(2)(a)", + "Article 102(2)(b)", + "Article 102(2)(c)", + "Article 106(1)", + "Article 106(2)(a)", + "Article 106(2)(b)", + "Article 106(2)(c)", + "Article 106(2)(d)", + "Article 106(2)(g)", + "Article 106(2)(h)", + "Article 106(2)(i)", + "Article 126(1)", + "Article 126(2)", + "Article 126(3)", + "Article 126(4)" + ], + "PRI-02": [ + "Article 2-d(2)", + "Article 77(1)(a)", + "Article 77(1)(b)", + "Article 78(1)", + "Article 78(2)", + "Article 78(3)", + "Article 132-c(1)" + ], + "PRI-03.3": [ + "Article 2-d(1)" + ], + "PRI-03.6": [ + "Article 82(2)(a)" + ], + "PRI-03.9": [ + "Article 99(1)" + ], + "PRI-05": [ + "Article 99(3)" + ], + "PRI-05.1": [ + "Article 99(3)", + "Article 105(1)", + "Article 105(2)", + "Article 105(3)", + "Article 105(4)" + ], + "PRI-05.4": [ + "Article 2-f(1)", + "Article 2-g(1)", + "Article 101(1)", + "Article 101(2)", + "Article 101(3)", + "Article 122(1)" + ], + "PRI-14": [ + "Article 110(2)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 45, + "mappings": { + "Article 1(1)": [ + "CPL-01" + ], + "Article 2-o(1)": [ + "HRS-03" + ], + "Article 2-o(2)": [ + "HRS-03" + ], + "Article 2-q(1)": [ + "PRI-01.4" + ], + "Article 115(1)": [ + "PRI-01.6" + ], + "Article 115(2)": [ + "PRI-01.6" + ], + "Article 75(1)": [ + "PRI-01.11" + ], + "Article 102(1)": [ + "PRI-01.11" + ], + "Article 102(2)(a)": [ + "PRI-01.11" + ], + "Article 102(2)(b)": [ + "PRI-01.11" + ], + "Article 102(2)(c)": [ + "PRI-01.11" + ], + "Article 106(1)": [ + "PRI-01.11" + ], + "Article 106(2)(a)": [ + "PRI-01.11" + ], + "Article 106(2)(b)": [ + "PRI-01.11" + ], + "Article 106(2)(c)": [ + "PRI-01.11" + ], + "Article 106(2)(d)": [ + "PRI-01.11" + ], + "Article 106(2)(g)": [ + "PRI-01.11" + ], + "Article 106(2)(h)": [ + "PRI-01.11" + ], + "Article 106(2)(i)": [ + "PRI-01.11" + ], + "Article 126(1)": [ + "PRI-01.11" + ], + "Article 126(2)": [ + "PRI-01.11" + ], + "Article 126(3)": [ + "PRI-01.11" + ], + "Article 126(4)": [ + "PRI-01.11" + ], + "Article 2-d(2)": [ + "PRI-02" + ], + "Article 77(1)(a)": [ + "PRI-02" + ], + "Article 77(1)(b)": [ + "PRI-02" + ], + "Article 78(1)": [ + "PRI-02" + ], + "Article 78(2)": [ + "PRI-02" + ], + "Article 78(3)": [ + "PRI-02" + ], + "Article 132-c(1)": [ + "PRI-02" + ], + "Article 2-d(1)": [ + "PRI-03.3" + ], + "Article 82(2)(a)": [ + "PRI-03.6" + ], + "Article 99(1)": [ + "PRI-03.9" + ], + "Article 99(3)": [ + "PRI-05", + "PRI-05.1" + ], + "Article 105(1)": [ + "PRI-05.1" + ], + "Article 105(2)": [ + "PRI-05.1" + ], + "Article 105(3)": [ + "PRI-05.1" + ], + "Article 105(4)": [ + "PRI-05.1" + ], + "Article 2-f(1)": [ + "PRI-05.4" + ], + "Article 2-g(1)": [ + "PRI-05.4" + ], + "Article 101(1)": [ + "PRI-05.4" + ], + "Article 101(2)": [ + "PRI-05.4" + ], + "Article 101(3)": [ + "PRI-05.4" + ], + "Article 122(1)": [ + "PRI-05.4" + ], + "Article 110(2)": [ + "PRI-14" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-ken-pda-2019.json b/docs/api/crosswalks/emea-ken-pda-2019.json index 04a94c85..5a330765 100644 --- a/docs/api/crosswalks/emea-ken-pda-2019.json +++ b/docs/api/crosswalks/emea-ken-pda-2019.json @@ -2,1277 +2,945 @@ "framework_id": "emea-ken-pda-2019", "display_name": "Kenya - Data Protection Act (DPA) (2019)", "scf_to_framework": { - "total_mappings": 41, + "total_mappings": 42, "mappings": { - "CLD-09": [ - "25(h)" + "GOV-17": [ + "IV.31(5)" ], "CPL-01": [ - "4(a)", - "4(b)(i)", - "4(b)(ii)", - "51(1)", - "51(2)(a)", - "51(2)(b)", - "51(2)(c)", - "52(1)(a)", - "52(1)(b)", - "52(1)(c)", - "52(2)", - "52(3)", - "54", - "55(1)(a)", - "55(1)(b)", - "55(2)" - ], - "DCH-14.2": [ - "25(h)" - ], - "DCH-19": [ - "25(h)" + "IV.37(1)", + "IV.37(1)(a)", + "IV.37(1)(b)", + "IV.37(2)", + "IV.37(3)" + ], + "CPL-01.3": [ + "IV.32(1)" ], "DCH-23": [ - "39(2)" + "IV.39(2)" ], "DCH-25": [ - "25(h)", - "48(a)", - "48(b)", - "48(c)(i)", - "48(c)(ii)", - "48(c)(iii)", - "48(c)(iv)", - "48(c)(v)", - "48(c)(vi)", - "49(1)", - "49(2)", - "49(3)", - "50" - ], - "DCH-26": [ - "50" - ], - "IRO-04.1": [ - "43(1)(b)", - "43(2)", - "43(3)", - "43(4)", - "43(5)", - "43(5)(a)", - "43(5)(b)", - "43(5)(c)", - "43(5)(d)", - "43(5)(e)", - "43(6)", - "43(7)", - "43(8)(a)", - "43(8)(b)", - "43(8)(c)" + "IV.25(h)" + ], + "IRO-10": [ + "IV.43(1)(b)", + "IV.43(2)", + "IV.43(3)", + "IV.43(4)", + "IV.43(5)", + "IV.43(5)(a)", + "IV.43(5)(b)", + "IV.43(5)(c)", + "IV.43(5)(d)", + "IV.43(5)(e)", + "IV.43(6)", + "IV.43(7)", + "IV.43(8)", + "IV.43(8)(a)", + "IV.43(8)(b)", + "IV.43(8)(c)" + ], + "IRO-10.2": [ + "IV.43(1)(a)" ], "PRI-01": [ - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)" + "IV.25" ], "PRI-01.4": [ - "24(1)", - "24(1)(a)", - "24(1)(b)", - "24(1)(c)", - "24(2)", - "24(3)", - "24(4)", - "24(5)", - "24(6)", - "24(7)(a)", - "24(7)(b)", - "24(7)(c)", - "24(7)(d)", - "24(7)(e)" + "III.24(1)", + "III.24(1)(a)", + "III.24(1)(b)", + "III.24(1)(c)", + "III.24(2)", + "III.24(3)", + "III.24(4)", + "III.24(5)", + "III.24(6)", + "III.24(7)", + "III.24(7)(a)", + "III.24(7)(b)", + "III.24(7)(c)", + "III.24(7)(d)", + "III.24(7)(e)" + ], + "PRI-01.5": [ + "IV.25(h)", + "VI.49(1)", + "VI.49(2)", + "VI.49(3)", + "VI.50" ], "PRI-01.6": [ - "29(f)", - "41(1)", - "41(1)(a)", - "41(1)(b)", - "41(2)", - "41(3)(a)", - "41(3)(b)", - "41(3)(c)", - "41(3)(d)", - "41(3)(e)", - "41(4)(a)", - "41(4)(b)", - "41(4)(c)", - "41(4)(d)", - "41(4)(e)", - "41(4)(f)", - "42(1)(a)", - "42(1)(b)", - "42(1)(c)", - "42(1)(d)", - "42(2)(a)", - "42(2)(b)", - "42(3)", - "42(4)" + "IV.41(1)", + "IV.41(1)(a)", + "IV.41(1)(b)", + "IV.41(2)", + "IV.41(3)", + "IV.41(3)(a)", + "IV.41(3)(b)", + "IV.41(3)(c)", + "IV.41(3)(d)", + "IV.41(3)(e)", + "IV.41(4)", + "IV.41(4)(a)", + "IV.41(4)(b)", + "IV.41(4)(c)", + "IV.41(4)(d)", + "IV.41(4)(e)", + "IV.41(4)(f)", + "IV.42(1)", + "IV.42(1)(a)", + "IV.42(1)(b)", + "IV.42(1)(c)", + "IV.42(1)(d)", + "IV.42(2)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" + ], + "PRI-01.11": [ + "IV.25(b)", + "IV.25(d)", + "IV.26", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(e)", + "IV.28(2)(f)", + "IV.28(2)(f)(i)", + "IV.28(2)(f)(ii)", + "IV.28(2)(f)(iii)", + "IV.28(3)", + "IV.33(2)", + "IV.33(3)", + "IV.33(3)(a)", + "IV.33(3)(b)", + "IV.33(3)(c)", + "IV.33(3)(d)", + "IV.33(3)(e)", + "IV.34(1)(c)", + "IV.34(1)(d)", + "IV.34(2)(a)", + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.35(2)(c)" ], "PRI-02": [ - "25(e)", - "26(a)", - "29(a)", - "29(b)", - "29(c)", - "29(d)", - "29(e)", - "29(f)", - "29(g)", - "29(h)" - ], - "PRI-02.1": [ - "29(c)" + "IV.25(e)", + "IV.26(a)", + "IV.29", + "IV.29(a)", + "IV.29(b)", + "IV.29(c)", + "IV.29(d)", + "IV.29(e)", + "IV.29(f)", + "IV.29(g)", + "IV.29(h)" ], "PRI-02.2": [ - "35(1)", - "35(2)", - "35(2)(a)", - "35(2)(b)", - "35(2)(c)", - "35(3)", - "35(3)(a)", - "35(3)(b)(i)", - "35(3)(b)(ii)", - "35(4)(a)", - "35(4)(b)", - "35(4)(c)(i)", - "35(4)(c)(ii)" + "IV.35(1)" ], "PRI-03": [ - "32(1)", - "32(4)" + "IV.26(c)", + "IV.28(2)(c)", + "IV.32(4)" ], - "PRI-03.2": [ - "32(2)", - "32(3)" + "PRI-03.3": [ + "IV.36" ], "PRI-03.4": [ - "26(c)", - "32(2)", - "32(3)" + "IV.26(c)", + "IV.32(2)", + "IV.32(3)" ], "PRI-03.5": [ - "32(4)" + "IV.32(4)" ], "PRI-03.6": [ - "27(a)", - "27(b)", - "27(c)" + "IV.27(a)", + "IV.27(b)", + "IV.27(c)", + "IV.28(2)(d)" ], "PRI-03.7": [ - "26(a)", - "26(c)" + "IV.28(1)" + ], + "PRI-03.13": [ + "IV.27(a)", + "IV.28(2)(d)", + "IV.33(2)", + "IV.33(4)" ], "PRI-04": [ - "25(c)", - "25(d)", - "27(a)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)" + "IV.25(c)", + "IV.27(a)" ], "PRI-04.1": [ - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)" + "IV.25(a)", + "IV.28(3)" ], "PRI-04.2": [ - "28(1)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)" + "IV.28(1)" ], "PRI-05": [ - "25(g)", - "34(3)", - "39(1)", - "39(1)(a)", - "39(1)(b)", - "39(1)(c)", - "39(1)(d)", - "39(2)" + "IV.25(g)", + "IV.34(1)(b)", + "IV.34(3)", + "IV.39(1)", + "IV.39(1)(a)", + "IV.39(1)(b)", + "IV.39(1)(c)", + "IV.39(1)(d)", + "IV.39(2)" ], "PRI-05.1": [ - "25(a)", - "25(b)", - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "34(1)(a)", - "34(1)(b)", - "34(1)(c)", - "34(1)(d)", - "34(2)(a)", - "34(2)(b)", - "34(3)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)", - "53(1)", - "53(2)", - "53(3)(a)", - "53(3)(b)", - "53(4)" + "IV.30(1)(b)(viii)" ], "PRI-05.2": [ - "25(f)" + "IV.25(f)" ], "PRI-05.4": [ - "44", - "45(a)", - "45(a)(i)", - "45(a)(ii)", - "45(b)", - "45(c)(i)", - "45(c)(ii)", - "45(c)(iii)", - "46(1)(a)", - "46(1)(b)", - "46(2)(a)", - "46(2)(b)", - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" - ], - "PRI-05.7": [ - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" + "IV.25(a)", + "IV.25(b)", + "IV.28(3)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(1)(b)(i)", + "IV.30(1)(b)(ii)", + "IV.30(1)(b)(iii)", + "IV.30(1)(b)(iv)", + "IV.30(1)(b)(v)", + "IV.30(1)(b)(vi)", + "IV.30(1)(b)(vii)", + "IV.30(2)", + "IV.33(1)", + "IV.33(1)(a)", + "IV.33(1)(b)", + "IV.36", + "V.45", + "V.45(a)", + "V.45(a)(i)", + "V.45(a)(ii)", + "V.45(b)", + "V.45(c)", + "V.45(c)(i)", + "V.45(c)(ii)", + "V.45(c)(iii)", + "V.46(1)", + "V.46(1)(a)", + "V.46(1)(b)", + "V.46(2)(a)", + "V.46(2)(b)" ], "PRI-06": [ - "26(a)", - "26(b)", - "26(c)", - "26(d)", - "26(e)" + "IV.26(b)", + "IV.27", + "IV.34(1)", + "IV.35(3)(b)(i)", + "IV.35(3)(b)(ii)", + "IV.38(1)", + "IV.38(2)", + "IV.38(3)", + "IV.40(1)", + "IV.40(1)(a)", + "IV.40(1)(b)" ], "PRI-06.1": [ - "25(f)", - "26(d)", - "40(1)(a)", - "40(2)(a)" + "IV.25(f)", + "IV.26(d)", + "IV.34(1)(a)", + "IV.40(1)(a)" ], "PRI-06.4": [ - "40(1)(b)" + "IV.35(4)(a)", + "IV.35(4)(b)", + "IV.35(4)(c)", + "IV.35(4)(c)(i)", + "IV.35(4)(c)(ii)", + "IV.38(4)" ], "PRI-06.5": [ - "26(e)", - "40(1)(b)", - "40(2)(b)", - "40(3)" + "IV.26(e)", + "IV.40(1)(b)", + "IV.40(3)" ], "PRI-06.6": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IV.38(1)", + "IV.38(2)", + "IV.38(3)" ], "PRI-06.7": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IV.38(1)", + "IV.38(2)" ], "PRI-07": [ - "25(h)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "IV.25(h)" ], "PRI-07.1": [ - "25(h)", - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)", - "42(2)(a)", - "42(2)(b)", - "42(3)" - ], - "PRI-07.2": [ - "42(2)(a)", - "42(2)(b)", - "42(3)" + "IV.25(h)", + "IV.40(2)(a)", + "IV.40(2)(b)", + "IV.40(3)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], "PRI-07.3": [ - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)" - ], - "PRI-15": [ - "18(1)", - "18(2)", - "18(2)(a)", - "18(2)(b)", - "18(2)(c)", - "18(2)(d)", - "19(1)", - "19(2)", - "19(2)(a)", - "19(2)(b)", - "19(2)(c)", - "19(2)(d)", - "19(2)(e)", - "19(2)(f)", - "19(2)(g)", - "19(3)", - "19(4)", - "19(5)", - "19(6)", - "19(7)", - "20" + "IV.40(2)", + "IV.40(3)" + ], + "PRI-17": [ + "IV.34(2)(b)", + "IV.35(3)(a)" + ], + "PRI-19": [ + "IV.35(1)" + ], + "PRI-19.1": [ + "IV.35(3)(a)" + ], + "PRI-19.2": [ + "IV.35(1)" ], "RSK-10": [ - "31(1)", - "31(2)(a)", - "31(2)(b)", - "31(2)(c)", - "31(2)(d)", - "31(3)", - "31(4)", - "31(5)", - "31(6)" - ], - "SEA-02.1": [ - "2" + "IV.31(1)", + "IV.31(2)", + "IV.31(2)(a)", + "IV.31(2)(b)", + "IV.31(2)(c)", + "IV.31(2)(d)", + "IV.31(3)" ] } }, "framework_to_scf": { - "total_mappings": 237, + "total_mappings": 196, "mappings": { - "2": [ - "SEA-02.1" - ], - "20": [ - "PRI-15" - ], - "36": [ - "PRI-04.1", - "PRI-05.1" - ], - "44": [ - "PRI-05.4" - ], - "50": [ - "DCH-25", - "DCH-26" - ], - "54": [ - "CPL-01" - ], - "25(h)": [ - "CLD-09", - "DCH-14.2", - "DCH-19", - "DCH-25", - "PRI-07", - "PRI-07.1" + "IV.31(5)": [ + "GOV-17" ], - "4(a)": [ + "IV.37(1)": [ "CPL-01" ], - "4(b)(i)": [ + "IV.37(1)(a)": [ "CPL-01" ], - "4(b)(ii)": [ + "IV.37(1)(b)": [ "CPL-01" ], - "51(1)": [ + "IV.37(2)": [ "CPL-01" ], - "51(2)(a)": [ + "IV.37(3)": [ "CPL-01" ], - "51(2)(b)": [ - "CPL-01" - ], - "51(2)(c)": [ - "CPL-01" - ], - "52(1)(a)": [ - "CPL-01" - ], - "52(1)(b)": [ - "CPL-01" - ], - "52(1)(c)": [ - "CPL-01" - ], - "52(2)": [ - "CPL-01" - ], - "52(3)": [ - "CPL-01" - ], - "55(1)(a)": [ - "CPL-01" - ], - "55(1)(b)": [ - "CPL-01" - ], - "55(2)": [ - "CPL-01" + "IV.32(1)": [ + "CPL-01.3" ], - "39(2)": [ + "IV.39(2)": [ "DCH-23", "PRI-05" ], - "48(a)": [ - "DCH-25" - ], - "48(b)": [ - "DCH-25" - ], - "48(c)(i)": [ - "DCH-25" - ], - "48(c)(ii)": [ - "DCH-25" - ], - "48(c)(iii)": [ - "DCH-25" - ], - "48(c)(iv)": [ - "DCH-25" - ], - "48(c)(v)": [ - "DCH-25" - ], - "48(c)(vi)": [ - "DCH-25" - ], - "49(1)": [ - "DCH-25" - ], - "49(2)": [ - "DCH-25" - ], - "49(3)": [ - "DCH-25" - ], - "43(1)(b)": [ - "IRO-04.1" - ], - "43(2)": [ - "IRO-04.1" - ], - "43(3)": [ - "IRO-04.1" - ], - "43(4)": [ - "IRO-04.1" - ], - "43(5)": [ - "IRO-04.1" - ], - "43(5)(a)": [ - "IRO-04.1" - ], - "43(5)(b)": [ - "IRO-04.1" + "IV.25(h)": [ + "DCH-25", + "PRI-01.5", + "PRI-07", + "PRI-07.1" ], - "43(5)(c)": [ - "IRO-04.1" + "IV.43(1)(b)": [ + "IRO-10" ], - "43(5)(d)": [ - "IRO-04.1" + "IV.43(2)": [ + "IRO-10" ], - "43(5)(e)": [ - "IRO-04.1" + "IV.43(3)": [ + "IRO-10" ], - "43(6)": [ - "IRO-04.1" + "IV.43(4)": [ + "IRO-10" ], - "43(7)": [ - "IRO-04.1" + "IV.43(5)": [ + "IRO-10" ], - "43(8)(a)": [ - "IRO-04.1" + "IV.43(5)(a)": [ + "IRO-10" ], - "43(8)(b)": [ - "IRO-04.1" + "IV.43(5)(b)": [ + "IRO-10" ], - "43(8)(c)": [ - "IRO-04.1" + "IV.43(5)(c)": [ + "IRO-10" ], - "30(1)(a)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(5)(d)": [ + "IRO-10" ], - "30(1)(b)(i)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(5)(e)": [ + "IRO-10" ], - "30(1)(b)(ii)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(6)": [ + "IRO-10" ], - "30(1)(b)(iii)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(7)": [ + "IRO-10" ], - "30(1)(b)(iv)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(8)": [ + "IRO-10" ], - "30(1)(b)(v)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(8)(a)": [ + "IRO-10" ], - "30(1)(b)(vi)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(8)(b)": [ + "IRO-10" ], - "30(1)(b)(vii)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(8)(c)": [ + "IRO-10" ], - "30(1)(b)(viii)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.43(1)(a)": [ + "IRO-10.2" ], - "30(2)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "IV.25": [ + "PRI-01" ], - "30(3)": [ - "PRI-01", - "PRI-04.1", - "PRI-05.1" + "III.24(1)": [ + "PRI-01.4" ], - "24(1)": [ + "III.24(1)(a)": [ "PRI-01.4" ], - "24(1)(a)": [ + "III.24(1)(b)": [ "PRI-01.4" ], - "24(1)(b)": [ + "III.24(1)(c)": [ "PRI-01.4" ], - "24(1)(c)": [ + "III.24(2)": [ "PRI-01.4" ], - "24(2)": [ + "III.24(3)": [ "PRI-01.4" ], - "24(3)": [ + "III.24(4)": [ "PRI-01.4" ], - "24(4)": [ + "III.24(5)": [ "PRI-01.4" ], - "24(5)": [ + "III.24(6)": [ "PRI-01.4" ], - "24(6)": [ + "III.24(7)": [ "PRI-01.4" ], - "24(7)(a)": [ + "III.24(7)(a)": [ "PRI-01.4" ], - "24(7)(b)": [ + "III.24(7)(b)": [ "PRI-01.4" ], - "24(7)(c)": [ + "III.24(7)(c)": [ "PRI-01.4" ], - "24(7)(d)": [ + "III.24(7)(d)": [ "PRI-01.4" ], - "24(7)(e)": [ + "III.24(7)(e)": [ "PRI-01.4" ], - "29(f)": [ - "PRI-01.6", - "PRI-02" + "VI.49(1)": [ + "PRI-01.5" + ], + "VI.49(2)": [ + "PRI-01.5" + ], + "VI.49(3)": [ + "PRI-01.5" + ], + "VI.50": [ + "PRI-01.5" ], - "41(1)": [ + "IV.41(1)": [ "PRI-01.6" ], - "41(1)(a)": [ + "IV.41(1)(a)": [ "PRI-01.6" ], - "41(1)(b)": [ + "IV.41(1)(b)": [ "PRI-01.6" ], - "41(2)": [ + "IV.41(2)": [ "PRI-01.6" ], - "41(3)(a)": [ + "IV.41(3)": [ "PRI-01.6" ], - "41(3)(b)": [ + "IV.41(3)(a)": [ "PRI-01.6" ], - "41(3)(c)": [ + "IV.41(3)(b)": [ "PRI-01.6" ], - "41(3)(d)": [ + "IV.41(3)(c)": [ "PRI-01.6" ], - "41(3)(e)": [ + "IV.41(3)(d)": [ "PRI-01.6" ], - "41(4)(a)": [ + "IV.41(3)(e)": [ "PRI-01.6" ], - "41(4)(b)": [ + "IV.41(4)": [ "PRI-01.6" ], - "41(4)(c)": [ + "IV.41(4)(a)": [ "PRI-01.6" ], - "41(4)(d)": [ + "IV.41(4)(b)": [ "PRI-01.6" ], - "41(4)(e)": [ + "IV.41(4)(c)": [ "PRI-01.6" ], - "41(4)(f)": [ + "IV.41(4)(d)": [ "PRI-01.6" ], - "42(1)(a)": [ + "IV.41(4)(e)": [ "PRI-01.6" ], - "42(1)(b)": [ + "IV.41(4)(f)": [ "PRI-01.6" ], - "42(1)(c)": [ + "IV.42(1)": [ "PRI-01.6" ], - "42(1)(d)": [ + "IV.42(1)(a)": [ "PRI-01.6" ], - "42(2)(a)": [ - "PRI-01.6", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "IV.42(1)(b)": [ + "PRI-01.6" ], - "42(2)(b)": [ - "PRI-01.6", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "IV.42(1)(c)": [ + "PRI-01.6" ], - "42(3)": [ - "PRI-01.6", - "PRI-07", - "PRI-07.1", - "PRI-07.2" + "IV.42(1)(d)": [ + "PRI-01.6" ], - "42(4)": [ + "IV.42(2)": [ "PRI-01.6" ], - "25(e)": [ - "PRI-02" + "IV.42(2)(a)": [ + "PRI-01.6", + "PRI-07.1" ], - "26(a)": [ - "PRI-02", - "PRI-03.7", - "PRI-06" + "IV.42(2)(b)": [ + "PRI-01.6", + "PRI-07.1" ], - "29(a)": [ - "PRI-02" + "IV.42(3)": [ + "PRI-01.6", + "PRI-07.1" ], - "29(b)": [ - "PRI-02" + "IV.42(4)": [ + "PRI-01.6", + "PRI-07.1" ], - "29(c)": [ - "PRI-02", - "PRI-02.1" + "IV.25(b)": [ + "PRI-01.11", + "PRI-05.4" ], - "29(d)": [ - "PRI-02" + "IV.25(d)": [ + "PRI-01.11" ], - "29(e)": [ - "PRI-02" + "IV.26": [ + "PRI-01.11" ], - "29(g)": [ - "PRI-02" + "IV.28(2)": [ + "PRI-01.11" ], - "29(h)": [ - "PRI-02" + "IV.28(2)(a)": [ + "PRI-01.11" ], - "35(1)": [ - "PRI-02.2" + "IV.28(2)(b)": [ + "PRI-01.11" ], - "35(2)": [ - "PRI-02.2" + "IV.28(2)(e)": [ + "PRI-01.11" ], - "35(2)(a)": [ - "PRI-02.2" + "IV.28(2)(f)": [ + "PRI-01.11" ], - "35(2)(b)": [ - "PRI-02.2" + "IV.28(2)(f)(i)": [ + "PRI-01.11" ], - "35(2)(c)": [ - "PRI-02.2" + "IV.28(2)(f)(ii)": [ + "PRI-01.11" ], - "35(3)": [ - "PRI-02.2" + "IV.28(2)(f)(iii)": [ + "PRI-01.11" ], - "35(3)(a)": [ - "PRI-02.2" + "IV.28(3)": [ + "PRI-01.11", + "PRI-04.1", + "PRI-05.4" ], - "35(3)(b)(i)": [ - "PRI-02.2" + "IV.33(2)": [ + "PRI-01.11", + "PRI-03.13" ], - "35(3)(b)(ii)": [ - "PRI-02.2" + "IV.33(3)": [ + "PRI-01.11" ], - "35(4)(a)": [ - "PRI-02.2" + "IV.33(3)(a)": [ + "PRI-01.11" ], - "35(4)(b)": [ - "PRI-02.2" + "IV.33(3)(b)": [ + "PRI-01.11" ], - "35(4)(c)(i)": [ - "PRI-02.2" + "IV.33(3)(c)": [ + "PRI-01.11" ], - "35(4)(c)(ii)": [ - "PRI-02.2" + "IV.33(3)(d)": [ + "PRI-01.11" ], - "32(1)": [ - "PRI-03" + "IV.33(3)(e)": [ + "PRI-01.11" ], - "32(4)": [ - "PRI-03", - "PRI-03.5" + "IV.34(1)(c)": [ + "PRI-01.11" ], - "32(2)": [ - "PRI-03.2", - "PRI-03.4" + "IV.34(1)(d)": [ + "PRI-01.11" ], - "32(3)": [ - "PRI-03.2", - "PRI-03.4" + "IV.34(2)(a)": [ + "PRI-01.11" ], - "26(c)": [ - "PRI-03.4", - "PRI-03.7", - "PRI-06" + "IV.35(2)": [ + "PRI-01.11" ], - "27(a)": [ - "PRI-03.6", - "PRI-04" + "IV.35(2)(a)": [ + "PRI-01.11" ], - "27(b)": [ - "PRI-03.6" + "IV.35(2)(b)": [ + "PRI-01.11" ], - "27(c)": [ - "PRI-03.6" + "IV.35(2)(c)": [ + "PRI-01.11" ], - "25(c)": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1" + "IV.25(e)": [ + "PRI-02" ], - "25(d)": [ - "PRI-04" + "IV.26(a)": [ + "PRI-02" ], - "28(2)(a)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29": [ + "PRI-02" ], - "28(2)(b)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29(a)": [ + "PRI-02" ], - "28(2)(c)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29(b)": [ + "PRI-02" ], - "28(2)(d)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29(c)": [ + "PRI-02" ], - "28(2)(e)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29(d)": [ + "PRI-02" ], - "28(2)(f)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29(e)": [ + "PRI-02" ], - "28(2)(f)(i)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29(f)": [ + "PRI-02" ], - "28(2)(f)(ii)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29(g)": [ + "PRI-02" ], - "28(2)(f)(iii)": [ - "PRI-04", - "PRI-04.1", - "PRI-04.2", - "PRI-05.1" + "IV.29(h)": [ + "PRI-02" ], - "28(3)": [ - "PRI-04", - "PRI-04.1", - "PRI-05.1" + "IV.35(1)": [ + "PRI-02.2", + "PRI-19", + "PRI-19.2" ], - "33(1)(a)": [ - "PRI-04.1", - "PRI-05.1" + "IV.26(c)": [ + "PRI-03", + "PRI-03.4" ], - "33(1)(b)": [ - "PRI-04.1", - "PRI-05.1" + "IV.28(2)(c)": [ + "PRI-03" ], - "33(2)": [ - "PRI-04.1", - "PRI-05.1" + "IV.32(4)": [ + "PRI-03", + "PRI-03.5" ], - "33(3)(a)": [ - "PRI-04.1", - "PRI-05.1" + "IV.36": [ + "PRI-03.3", + "PRI-05.4" ], - "33(3)(b)": [ - "PRI-04.1", - "PRI-05.1" + "IV.32(2)": [ + "PRI-03.4" ], - "33(3)(c)": [ - "PRI-04.1", - "PRI-05.1" + "IV.32(3)": [ + "PRI-03.4" ], - "33(3)(d)": [ - "PRI-04.1", - "PRI-05.1" + "IV.27(a)": [ + "PRI-03.6", + "PRI-03.13", + "PRI-04" ], - "33(3)(e)": [ - "PRI-04.1", - "PRI-05.1" + "IV.27(b)": [ + "PRI-03.6" ], - "33(4)": [ - "PRI-04.1", - "PRI-05.1" + "IV.27(c)": [ + "PRI-03.6" ], - "37(1)(a)": [ - "PRI-04.1", - "PRI-05.1" + "IV.28(2)(d)": [ + "PRI-03.6", + "PRI-03.13" ], - "37(1)(b)": [ - "PRI-04.1", - "PRI-05.1" + "IV.28(1)": [ + "PRI-03.7", + "PRI-04.2" ], - "37(2)": [ - "PRI-04.1", - "PRI-05.1" + "IV.33(4)": [ + "PRI-03.13" ], - "28(1)": [ - "PRI-04.2" + "IV.25(c)": [ + "PRI-04" + ], + "IV.25(a)": [ + "PRI-04.1", + "PRI-05.4" ], - "25(g)": [ + "IV.25(g)": [ "PRI-05" ], - "34(3)": [ - "PRI-05", - "PRI-05.1" + "IV.34(1)(b)": [ + "PRI-05" ], - "39(1)": [ + "IV.34(3)": [ "PRI-05" ], - "39(1)(a)": [ + "IV.39(1)": [ "PRI-05" ], - "39(1)(b)": [ + "IV.39(1)(a)": [ "PRI-05" ], - "39(1)(c)": [ + "IV.39(1)(b)": [ "PRI-05" ], - "39(1)(d)": [ + "IV.39(1)(c)": [ "PRI-05" ], - "25(a)": [ - "PRI-05.1" + "IV.39(1)(d)": [ + "PRI-05" ], - "25(b)": [ + "IV.30(1)(b)(viii)": [ "PRI-05.1" ], - "34(1)(a)": [ - "PRI-05.1" + "IV.25(f)": [ + "PRI-05.2", + "PRI-06.1" ], - "34(1)(b)": [ - "PRI-05.1" + "IV.30(1)": [ + "PRI-05.4" ], - "34(1)(c)": [ - "PRI-05.1" + "IV.30(1)(a)": [ + "PRI-05.4" ], - "34(1)(d)": [ - "PRI-05.1" + "IV.30(1)(b)": [ + "PRI-05.4" ], - "34(2)(a)": [ - "PRI-05.1" + "IV.30(1)(b)(i)": [ + "PRI-05.4" ], - "34(2)(b)": [ - "PRI-05.1" + "IV.30(1)(b)(ii)": [ + "PRI-05.4" ], - "53(1)": [ - "PRI-05.1" + "IV.30(1)(b)(iii)": [ + "PRI-05.4" ], - "53(2)": [ - "PRI-05.1" + "IV.30(1)(b)(iv)": [ + "PRI-05.4" ], - "53(3)(a)": [ - "PRI-05.1" + "IV.30(1)(b)(v)": [ + "PRI-05.4" ], - "53(3)(b)": [ - "PRI-05.1" + "IV.30(1)(b)(vi)": [ + "PRI-05.4" ], - "53(4)": [ - "PRI-05.1" + "IV.30(1)(b)(vii)": [ + "PRI-05.4" ], - "25(f)": [ - "PRI-05.2", - "PRI-06.1" + "IV.30(2)": [ + "PRI-05.4" ], - "45(a)": [ + "IV.33(1)": [ "PRI-05.4" ], - "45(a)(i)": [ + "IV.33(1)(a)": [ "PRI-05.4" ], - "45(a)(ii)": [ + "IV.33(1)(b)": [ "PRI-05.4" ], - "45(b)": [ + "V.45": [ "PRI-05.4" ], - "45(c)(i)": [ + "V.45(a)": [ "PRI-05.4" ], - "45(c)(ii)": [ + "V.45(a)(i)": [ "PRI-05.4" ], - "45(c)(iii)": [ + "V.45(a)(ii)": [ "PRI-05.4" ], - "46(1)(a)": [ + "V.45(b)": [ "PRI-05.4" ], - "46(1)(b)": [ + "V.45(c)": [ "PRI-05.4" ], - "46(2)(a)": [ + "V.45(c)(i)": [ "PRI-05.4" ], - "46(2)(b)": [ + "V.45(c)(ii)": [ "PRI-05.4" ], - "47(1)": [ - "PRI-05.4", - "PRI-05.7" + "V.45(c)(iii)": [ + "PRI-05.4" ], - "47(2)(a)": [ - "PRI-05.4", - "PRI-05.7" + "V.46(1)": [ + "PRI-05.4" ], - "47(2)(b)": [ - "PRI-05.4", - "PRI-05.7" + "V.46(1)(a)": [ + "PRI-05.4" ], - "47(2)(c)": [ - "PRI-05.4", - "PRI-05.7" + "V.46(1)(b)": [ + "PRI-05.4" ], - "47(2)(d)": [ - "PRI-05.4", - "PRI-05.7" + "V.46(2)(a)": [ + "PRI-05.4" ], - "47(3)": [ - "PRI-05.4", - "PRI-05.7" + "V.46(2)(b)": [ + "PRI-05.4" ], - "26(b)": [ + "IV.26(b)": [ "PRI-06" ], - "26(d)": [ - "PRI-06", - "PRI-06.1" - ], - "26(e)": [ - "PRI-06", - "PRI-06.5" - ], - "40(1)(a)": [ - "PRI-06.1" - ], - "40(2)(a)": [ - "PRI-06.1", - "PRI-07.1", - "PRI-07.3" - ], - "40(1)(b)": [ - "PRI-06.4", - "PRI-06.5" - ], - "40(2)(b)": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.3" - ], - "40(3)": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.3" - ], - "38(1)": [ - "PRI-06.6", - "PRI-06.7" - ], - "38(2)": [ - "PRI-06.6", - "PRI-06.7" - ], - "38(3)": [ - "PRI-06.6", - "PRI-06.7" + "IV.27": [ + "PRI-06" ], - "38(4)": [ - "PRI-06.6", - "PRI-06.7" + "IV.34(1)": [ + "PRI-06" ], - "38(5)(a)": [ - "PRI-06.6", - "PRI-06.7" + "IV.35(3)(b)(i)": [ + "PRI-06" ], - "38(5)(b)": [ - "PRI-06.6", - "PRI-06.7" + "IV.35(3)(b)(ii)": [ + "PRI-06" ], - "38(6)": [ + "IV.38(1)": [ + "PRI-06", "PRI-06.6", "PRI-06.7" ], - "38(7)": [ + "IV.38(2)": [ + "PRI-06", "PRI-06.6", "PRI-06.7" ], - "40(2)": [ - "PRI-07.1", - "PRI-07.3" - ], - "18(1)": [ - "PRI-15" - ], - "18(2)": [ - "PRI-15" - ], - "18(2)(a)": [ - "PRI-15" - ], - "18(2)(b)": [ - "PRI-15" + "IV.38(3)": [ + "PRI-06", + "PRI-06.6" ], - "18(2)(c)": [ - "PRI-15" + "IV.40(1)": [ + "PRI-06" ], - "18(2)(d)": [ - "PRI-15" + "IV.40(1)(a)": [ + "PRI-06", + "PRI-06.1" ], - "19(1)": [ - "PRI-15" + "IV.40(1)(b)": [ + "PRI-06", + "PRI-06.5" ], - "19(2)": [ - "PRI-15" + "IV.26(d)": [ + "PRI-06.1" ], - "19(2)(a)": [ - "PRI-15" + "IV.34(1)(a)": [ + "PRI-06.1" ], - "19(2)(b)": [ - "PRI-15" + "IV.35(4)(a)": [ + "PRI-06.4" ], - "19(2)(c)": [ - "PRI-15" + "IV.35(4)(b)": [ + "PRI-06.4" ], - "19(2)(d)": [ - "PRI-15" + "IV.35(4)(c)": [ + "PRI-06.4" ], - "19(2)(e)": [ - "PRI-15" + "IV.35(4)(c)(i)": [ + "PRI-06.4" ], - "19(2)(f)": [ - "PRI-15" + "IV.35(4)(c)(ii)": [ + "PRI-06.4" ], - "19(2)(g)": [ - "PRI-15" + "IV.38(4)": [ + "PRI-06.4" ], - "19(3)": [ - "PRI-15" + "IV.26(e)": [ + "PRI-06.5" ], - "19(4)": [ - "PRI-15" + "IV.40(3)": [ + "PRI-06.5", + "PRI-07.1", + "PRI-07.3" ], - "19(5)": [ - "PRI-15" + "IV.40(2)(a)": [ + "PRI-07.1" ], - "19(6)": [ - "PRI-15" + "IV.40(2)(b)": [ + "PRI-07.1" ], - "19(7)": [ - "PRI-15" + "IV.40(2)": [ + "PRI-07.3" ], - "31(1)": [ - "RSK-10" + "IV.34(2)(b)": [ + "PRI-17" ], - "31(2)(a)": [ - "RSK-10" + "IV.35(3)(a)": [ + "PRI-17", + "PRI-19.1" ], - "31(2)(b)": [ + "IV.31(1)": [ "RSK-10" ], - "31(2)(c)": [ + "IV.31(2)": [ "RSK-10" ], - "31(2)(d)": [ + "IV.31(2)(a)": [ "RSK-10" ], - "31(3)": [ + "IV.31(2)(b)": [ "RSK-10" ], - "31(4)": [ + "IV.31(2)(c)": [ "RSK-10" ], - "31(5)": [ + "IV.31(2)(d)": [ "RSK-10" ], - "31(6)": [ + "IV.31(3)": [ "RSK-10" ] } diff --git a/docs/api/crosswalks/emea-nga-dpr-2019.json b/docs/api/crosswalks/emea-nga-dpr-2019.json index 2514a7f7..34655dd2 100644 --- a/docs/api/crosswalks/emea-nga-dpr-2019.json +++ b/docs/api/crosswalks/emea-nga-dpr-2019.json @@ -2,60 +2,72 @@ "framework_id": "emea-nga-dpr-2019", "display_name": "Nigeria - Data Protection Regulation (DPR) (2019)", "scf_to_framework": { - "total_mappings": 25, + "total_mappings": 32, "mappings": { - "GOV-02": [ - "4.1(1)" + "GOV-17": [ + "4.1(6)", + "4.1(7)" ], "CPL-01": [ "2.1(2)", "2.1(3)", "3.1(16)", - "4.1(1)", - "4.1(6)", - "4.1(7)" + "4.1(1)" ], - "CPL-02": [ - "4.1(5)(a)", - "4.1(5)(b)", - "4.1(5)(c)", - "4.1(5)(d)", - "4.1(5)(e)", - "4.1(5)(f)", - "4.1(5)(g)", - "4.1(5)(h)", - "4.1(5)(i)", - "4.1(5)(j)", - "4.1(6)", - "4.1(7)" + "CPL-01.3": [ + "3.1(4)" + ], + "CPL-01.4": [ + "4.1(5)", + "4.1(5)a", + "4.1(5)b", + "4.1(5)c", + "4.1(5)d", + "4.1(5)e", + "4.1(5)f", + "4.1(5)g", + "4.1(5)h", + "4.1(5)i", + "4.1(5)j" ], "DCH-25": [ + "2.11" + ], + "PRI-01": [ + "4.1(3)" + ], + "PRI-01.4": [ + "4.1(2)" + ], + "PRI-01.5": [ "2.11", "2.11(a)", "2.11(b)", "2.11(c)", "2.11(d)", "2.11(e)", - "2.12", - "2.12(a)", - "2.12(b)", - "2.12(c)", - "2.12(d)", - "2.12(e)", - "2.12(f)" - ], - "PRI-01": [ - "4.1(3)" - ], - "PRI-01.4": [ - "4.1(2)", - "4.1(3)" + "2.12" ], "PRI-01.6": [ "2.1(1)(d)", "2.6" ], + "PRI-01.11": [ + "2.4(a)", + "2.4(b)", + "2.6", + "2.8", + "2.9", + "2.12(b)", + "2.12(c)", + "2.12(d)", + "2.12(e)", + "2.12(f)", + "3.1(3)", + "3.1(3)(a)" + ], "PRI-02": [ + "2.3(1)", "2.5", "2.5(a)", "2.5(b)", @@ -67,6 +79,7 @@ "2.5(h)", "2.5(i)", "3.1(1)", + "3.1(7)", "3.1(7)(a)", "3.1(7)(b)", "3.1(7)(c)", @@ -81,112 +94,118 @@ "3.1(7)(l)", "3.1(7)(m)", "3.1(7)(n)", - "3.1(9)", - "3.1(9)(a)", - "3.1(9)(b)", - "3.1(9)(c)", - "3.1(9)(d)", - "3.1(9)(e)" + "3.1(8)" ], "PRI-02.1": [ "2.3(1)" ], "PRI-03": [ - "2.2(a)", "2.3(2)", "2.3(2)(a)", "2.3(2)(b)", "2.3(2)(c)", "2.3(2)(d)", - "2.3(2)(e)" + "2.3(2)(e)", + "2.8(b)", + "2.12(a)", + "3.1(14)(a)", + "3.1(14)(b)", + "3.1(14)(c)" ], "PRI-03.4": [ - "2.8", "2.8(a)", - "2.8(b)" + "3.1(9)(b)" ], "PRI-04.1": [ + "2.3(1)" + ], + "PRI-05": [ + "3.1(9)(a)" + ], + "PRI-05.4": [ "2.1(1)(a)", "2.1(1)(a)(i)", "2.1(1)(a)(ii)", + "2.1(1)(b)", + "2.1(1)(c)", "2.2(a)", - "2.2(b)", "2.2(c)", "2.2(d)", "2.2(e)", - "2.4(a)" - ], - "PRI-05": [ - "2.1(1)(c)" - ], - "PRI-05.1": [ - "2.1(1)(b)", - "3.1(12)" - ], - "PRI-05.4": [ "3.1(12)" ], "PRI-06": [ - "3.1(1)", - "3.1(3)", - "3.1(3)(a)", - "3.1(3)(b)" - ], - "PRI-06.2": [ - "3.1(13)" - ], - "PRI-06.4": [ - "2.8", "2.8(a)", - "2.8(b)", - "3.1(2)", - "3.1(4)", - "3.1(5)", + "3.1(9)", + "3.1(9)(a)", + "3.1(9)(b)", + "3.1(9)(c)", + "3.1(9)(d)", + "3.1(9)(e)", + "3.1(11)", "3.1(11)(a)", "3.1(11)(b)", "3.1(11)(c)", "3.1(11)(d)", + "3.1(15)" + ], + "PRI-06.4": [ + "3.1(2)", + "3.1(3)(b)", + "3.1(5)", "3.1(13)" ], "PRI-06.5": [ - "3.1(13)" + "3.1(9)(e)" ], "PRI-06.6": [ - "3.1(6)", "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)", "3.1(15)" ], "PRI-06.7": [ - "3.1(6)", - "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)" + "3.1(14)" + ], + "PRI-06.8": [ + "3.1(5)" ], "PRI-07": [ - "2.4(b)" + "2.12(a)" ], "PRI-07.1": [ - "2.4(b)", "2.7" ], "PRI-07.3": [ "3.1(10)" ], - "SEA-02.1": [ - "1.3" + "PRI-07.5": [ + "3.1(4)" + ], + "PRI-14": [ + "3.1(8)" + ], + "PRI-14.1": [ + "3.1(8)" + ], + "PRI-14.2": [ + "3.1(8)" + ], + "PRI-15": [ + "4.1(4)" + ], + "PRI-17": [ + "3.1(2)", + "3.1(6)" ] } }, "framework_to_scf": { - "total_mappings": 107, + "total_mappings": 111, "mappings": { - "4.1(1)": [ - "GOV-02", - "CPL-01" + "4.1(6)": [ + "GOV-17" + ], + "4.1(7)": [ + "GOV-17" ], "2.1(2)": [ "CPL-01" @@ -197,95 +216,118 @@ "3.1(16)": [ "CPL-01" ], - "4.1(6)": [ - "CPL-01", - "CPL-02" + "4.1(1)": [ + "CPL-01" ], - "4.1(7)": [ - "CPL-01", - "CPL-02" + "3.1(4)": [ + "CPL-01.3", + "PRI-07.5" ], - "4.1(5)(a)": [ - "CPL-02" + "4.1(5)": [ + "CPL-01.4" ], - "4.1(5)(b)": [ - "CPL-02" + "4.1(5)a": [ + "CPL-01.4" ], - "4.1(5)(c)": [ - "CPL-02" + "4.1(5)b": [ + "CPL-01.4" ], - "4.1(5)(d)": [ - "CPL-02" + "4.1(5)c": [ + "CPL-01.4" ], - "4.1(5)(e)": [ - "CPL-02" + "4.1(5)d": [ + "CPL-01.4" ], - "4.1(5)(f)": [ - "CPL-02" + "4.1(5)e": [ + "CPL-01.4" ], - "4.1(5)(g)": [ - "CPL-02" + "4.1(5)f": [ + "CPL-01.4" ], - "4.1(5)(h)": [ - "CPL-02" + "4.1(5)g": [ + "CPL-01.4" ], - "4.1(5)(i)": [ - "CPL-02" + "4.1(5)h": [ + "CPL-01.4" ], - "4.1(5)(j)": [ - "CPL-02" + "4.1(5)i": [ + "CPL-01.4" + ], + "4.1(5)j": [ + "CPL-01.4" ], "2.11": [ - "DCH-25" + "DCH-25", + "PRI-01.5" + ], + "4.1(3)": [ + "PRI-01" + ], + "4.1(2)": [ + "PRI-01.4" ], "2.11(a)": [ - "DCH-25" + "PRI-01.5" ], "2.11(b)": [ - "DCH-25" + "PRI-01.5" ], "2.11(c)": [ - "DCH-25" + "PRI-01.5" ], "2.11(d)": [ - "DCH-25" + "PRI-01.5" ], "2.11(e)": [ - "DCH-25" + "PRI-01.5" ], "2.12": [ - "DCH-25" + "PRI-01.5" ], - "2.12(a)": [ - "DCH-25" + "2.1(1)(d)": [ + "PRI-01.6" + ], + "2.6": [ + "PRI-01.6", + "PRI-01.11" + ], + "2.4(a)": [ + "PRI-01.11" + ], + "2.4(b)": [ + "PRI-01.11" + ], + "2.8": [ + "PRI-01.11" + ], + "2.9": [ + "PRI-01.11" ], "2.12(b)": [ - "DCH-25" + "PRI-01.11" ], "2.12(c)": [ - "DCH-25" + "PRI-01.11" ], "2.12(d)": [ - "DCH-25" + "PRI-01.11" ], "2.12(e)": [ - "DCH-25" + "PRI-01.11" ], "2.12(f)": [ - "DCH-25" + "PRI-01.11" ], - "4.1(3)": [ - "PRI-01", - "PRI-01.4" - ], - "4.1(2)": [ - "PRI-01.4" + "3.1(3)": [ + "PRI-01.11" ], - "2.1(1)(d)": [ - "PRI-01.6" + "3.1(3)(a)": [ + "PRI-01.11" ], - "2.6": [ - "PRI-01.6" + "2.3(1)": [ + "PRI-02", + "PRI-02.1", + "PRI-04.1" ], "2.5": [ "PRI-02" @@ -318,8 +360,10 @@ "PRI-02" ], "3.1(1)": [ - "PRI-02", - "PRI-06" + "PRI-02" + ], + "3.1(7)": [ + "PRI-02" ], "3.1(7)(a)": [ "PRI-02" @@ -363,30 +407,11 @@ "3.1(7)(n)": [ "PRI-02" ], - "3.1(9)": [ - "PRI-02" - ], - "3.1(9)(a)": [ - "PRI-02" - ], - "3.1(9)(b)": [ - "PRI-02" - ], - "3.1(9)(c)": [ - "PRI-02" - ], - "3.1(9)(d)": [ - "PRI-02" - ], - "3.1(9)(e)": [ - "PRI-02" - ], - "2.3(1)": [ - "PRI-02.1" - ], - "2.2(a)": [ - "PRI-03", - "PRI-04.1" + "3.1(8)": [ + "PRI-02", + "PRI-14", + "PRI-14.1", + "PRI-14.2" ], "2.3(2)": [ "PRI-03" @@ -406,122 +431,125 @@ "2.3(2)(e)": [ "PRI-03" ], - "2.8": [ - "PRI-03.4", - "PRI-06.4" + "2.8(b)": [ + "PRI-03" + ], + "2.12(a)": [ + "PRI-03", + "PRI-07" + ], + "3.1(14)(a)": [ + "PRI-03" + ], + "3.1(14)(b)": [ + "PRI-03" + ], + "3.1(14)(c)": [ + "PRI-03" ], "2.8(a)": [ "PRI-03.4", - "PRI-06.4" + "PRI-06" ], - "2.8(b)": [ + "3.1(9)(b)": [ "PRI-03.4", - "PRI-06.4" + "PRI-06" + ], + "3.1(9)(a)": [ + "PRI-05", + "PRI-06" ], "2.1(1)(a)": [ - "PRI-04.1" + "PRI-05.4" ], "2.1(1)(a)(i)": [ - "PRI-04.1" + "PRI-05.4" ], "2.1(1)(a)(ii)": [ - "PRI-04.1" + "PRI-05.4" ], - "2.2(b)": [ - "PRI-04.1" + "2.1(1)(b)": [ + "PRI-05.4" + ], + "2.1(1)(c)": [ + "PRI-05.4" + ], + "2.2(a)": [ + "PRI-05.4" ], "2.2(c)": [ - "PRI-04.1" + "PRI-05.4" ], "2.2(d)": [ - "PRI-04.1" + "PRI-05.4" ], "2.2(e)": [ - "PRI-04.1" - ], - "2.4(a)": [ - "PRI-04.1" - ], - "2.1(1)(c)": [ - "PRI-05" - ], - "2.1(1)(b)": [ - "PRI-05.1" + "PRI-05.4" ], "3.1(12)": [ - "PRI-05.1", "PRI-05.4" ], - "3.1(3)": [ + "3.1(9)": [ "PRI-06" ], - "3.1(3)(a)": [ + "3.1(9)(c)": [ "PRI-06" ], - "3.1(3)(b)": [ + "3.1(9)(d)": [ "PRI-06" ], - "3.1(13)": [ - "PRI-06.2", - "PRI-06.4", + "3.1(9)(e)": [ + "PRI-06", "PRI-06.5" ], - "3.1(2)": [ - "PRI-06.4" - ], - "3.1(4)": [ - "PRI-06.4" - ], - "3.1(5)": [ - "PRI-06.4" + "3.1(11)": [ + "PRI-06" ], "3.1(11)(a)": [ - "PRI-06.4" + "PRI-06" ], "3.1(11)(b)": [ - "PRI-06.4" + "PRI-06" ], "3.1(11)(c)": [ - "PRI-06.4" + "PRI-06" ], "3.1(11)(d)": [ - "PRI-06.4" + "PRI-06" ], - "3.1(6)": [ - "PRI-06.6", - "PRI-06.7" + "3.1(15)": [ + "PRI-06", + "PRI-06.6" ], - "3.1(14)": [ - "PRI-06.6", - "PRI-06.7" + "3.1(2)": [ + "PRI-06.4", + "PRI-17" ], - "3.1(14)(a)": [ - "PRI-06.6", - "PRI-06.7" + "3.1(3)(b)": [ + "PRI-06.4" ], - "3.1(14)(b)": [ - "PRI-06.6", - "PRI-06.7" + "3.1(5)": [ + "PRI-06.4", + "PRI-06.8" ], - "3.1(14)(c)": [ + "3.1(13)": [ + "PRI-06.4" + ], + "3.1(14)": [ "PRI-06.6", "PRI-06.7" ], - "3.1(15)": [ - "PRI-06.6" - ], - "2.4(b)": [ - "PRI-07", - "PRI-07.1" - ], "2.7": [ "PRI-07.1" ], "3.1(10)": [ "PRI-07.3" ], - "1.3": [ - "SEA-02.1" + "4.1(4)": [ + "PRI-15" + ], + "3.1(6)": [ + "PRI-17" ] } } diff --git a/docs/api/crosswalks/emea-nor-pda-2018.json b/docs/api/crosswalks/emea-nor-pda-2018.json index 094fbe77..e22128b5 100644 --- a/docs/api/crosswalks/emea-nor-pda-2018.json +++ b/docs/api/crosswalks/emea-nor-pda-2018.json @@ -2,178 +2,56 @@ "framework_id": "emea-nor-pda-2018", "display_name": "Norway - Personal Data Act (PDA) (2018)", "scf_to_framework": { - "total_mappings": 23, + "total_mappings": 4, "mappings": { - "GOV-01": [ - "13", - "14" + "PRI-01.4": [ + "18", + "18(a)", + "18(b)", + "18(c)", + "18(d)" ], - "CPL-01": [ - "13", - "14" - ], - "CPL-02": [ - "13", - "14" - ], - "CPL-03": [ - "13", - "14" - ], - "DCH-01": [ - "13", - "14", - "29" - ], - "DCH-22.1": [ - "27" - ], - "DCH-24": [ - "13", - "14" - ], - "DCH-24.1": [ - "13", - "14" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-02": [ - "31" - ], - "PRI-02.1": [ - "32" - ], - "PRI-05": [ - "8", - "11", - "15", - "27", - "28" - ], - "PRI-05.1": [ - "11", - "27" - ], - "PRI-05.2": [ - "11" + "PRI-04.1": [ + "8" ], "PRI-05.4": [ - "9" - ], - "PRI-06": [ - "18" + "9", + "12" ], - "PRI-06.1": [ - "27" - ], - "PRI-15": [ - "33" - ], - "SEA-01": [ - "13", - "14", - "29" - ], - "SEA-02": [ - "13", - "14", - "29" - ], - "SEA-03": [ - "13", - "14", - "29" - ], - "SEA-15": [ - "13", - "14" - ], - "TPM-04.4": [ - "13", - "14" + "PRI-07.5": [ + "16" ] } }, "framework_to_scf": { - "total_mappings": 15, + "total_mappings": 9, "mappings": { "8": [ - "PRI-05" + "PRI-04.1" ], "9": [ "PRI-05.4" ], - "11": [ - "PRI-05", - "PRI-05.1", - "PRI-05.2" - ], - "13": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "14": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" + "12": [ + "PRI-05.4" ], - "15": [ - "PRI-05" + "16": [ + "PRI-07.5" ], "18": [ - "PRI-06" - ], - "27": [ - "DCH-22.1", - "PRI-05", - "PRI-05.1", - "PRI-06.1" - ], - "28": [ - "PRI-05" - ], - "29": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "31": [ - "PRI-02" + "PRI-01.4" ], - "32": [ - "PRI-02.1" + "18(a)": [ + "PRI-01.4" ], - "33": [ - "PRI-15" + "18(b)": [ + "PRI-01.4" ], - "Inferred": [ - "PRI-01" + "18(c)": [ + "PRI-01.4" ], - "Expectation": [ - "PRI-01" + "18(d)": [ + "PRI-01.4" ] } } diff --git a/docs/api/crosswalks/emea-pol-act-10-2018.json b/docs/api/crosswalks/emea-pol-act-10-2018.json new file mode 100644 index 00000000..14ea2b9e --- /dev/null +++ b/docs/api/crosswalks/emea-pol-act-10-2018.json @@ -0,0 +1,30 @@ +{ + "framework_id": "emea-pol-act-10-2018", + "display_name": "Poland - Act of 10 May 2018 on the Protection of Personal Data", + "scf_to_framework": { + "total_mappings": 2, + "mappings": { + "PRI-01.4": [ + "Art. 8", + "Art. 11a" + ], + "PRI-02": [ + "Art. 11" + ] + } + }, + "framework_to_scf": { + "total_mappings": 3, + "mappings": { + "Art. 8": [ + "PRI-01.4" + ], + "Art. 11a": [ + "PRI-01.4" + ], + "Art. 11": [ + "PRI-02" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-pol-act-29-1997.json b/docs/api/crosswalks/emea-pol-act-29-1997.json deleted file mode 100644 index bf0f2028..00000000 --- a/docs/api/crosswalks/emea-pol-act-29-1997.json +++ /dev/null @@ -1,190 +0,0 @@ -{ - "framework_id": "emea-pol-act-29-1997", - "display_name": "Poland - Act of 29 August 1997 on the Protection of Personal Data", - "scf_to_framework": { - "total_mappings": 29, - "mappings": { - "GOV-01": [ - "1", - "36" - ], - "CPL-01": [ - "1", - "36" - ], - "CPL-02": [ - "1", - "36" - ], - "CPL-03": [ - "1", - "36" - ], - "DCH-01": [ - "1", - "36", - "47" - ], - "DCH-22.1": [ - "32" - ], - "DCH-24": [ - "1", - "36" - ], - "DCH-24.1": [ - "1", - "36" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-01.1": [ - "46" - ], - "PRI-02": [ - "23" - ], - "PRI-02.1": [ - "23" - ], - "PRI-03": [ - "23" - ], - "PRI-04": [ - "23" - ], - "PRI-04.1": [ - "23" - ], - "PRI-05": [ - "23", - "26" - ], - "PRI-05.1": [ - "26" - ], - "PRI-05.4": [ - "27" - ], - "PRI-06": [ - "32" - ], - "PRI-06.1": [ - "32" - ], - "PRI-06.2": [ - "32" - ], - "PRI-15": [ - "40" - ], - "SEA-01": [ - "1", - "36", - "47" - ], - "SEA-02": [ - "1", - "36", - "47" - ], - "SEA-03": [ - "1", - "36", - "47" - ], - "SEA-15": [ - "1", - "36" - ], - "TPM-03": [ - "31" - ], - "TPM-04.4": [ - "1", - "36" - ], - "TPM-05": [ - "31" - ] - } - }, - "framework_to_scf": { - "total_mappings": 12, - "mappings": { - "1": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "23": [ - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1", - "PRI-05" - ], - "26": [ - "PRI-05", - "PRI-05.1" - ], - "27": [ - "PRI-05.4" - ], - "31": [ - "TPM-03", - "TPM-05" - ], - "32": [ - "DCH-22.1", - "PRI-06", - "PRI-06.1", - "PRI-06.2" - ], - "36": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "40": [ - "PRI-15" - ], - "46": [ - "PRI-01.1" - ], - "47": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-qat-pdppl-2020.json b/docs/api/crosswalks/emea-qat-pdppl-2020.json index b6f7034d..2d28d87c 100644 --- a/docs/api/crosswalks/emea-qat-pdppl-2020.json +++ b/docs/api/crosswalks/emea-qat-pdppl-2020.json @@ -2,480 +2,286 @@ "framework_id": "emea-qat-pdppl-2020", "display_name": "Qatar - Personal Data Privacy Protection Law (PDPPL) (2020)", "scf_to_framework": { - "total_mappings": 56, + "total_mappings": 33, "mappings": { - "GOV-02": [ - "8.4" + "GOV-04.1": [ + "3.11.2" ], - "GOV-15": [ - "8.3" - ], - "GOV-15.1": [ - "8.3", - "11.1" - ], - "GOV-15.2": [ - "8.3", - "11.3", - "11.5", - "11.6" - ], - "GOV-15.3": [ - "8.3", - "11.1", - "11.2" - ], - "GOV-15.4": [ - "8.3", - "11.1" - ], - "GOV-15.5": [ - "8.3", - "11.7", - "11.8" - ], - "CLD-09": [ - "15" + "AST-01.2": [ + "3.11.2" ], "CPL-01": [ - "2" - ], - "CPL-03": [ - "11.7", - "11.8" - ], - "CPL-03.2": [ - "11.7", - "11.8" - ], - "DCH-19": [ - "15" + "3.8" ], - "DCH-25": [ - "15" + "CPL-01.4": [ + "3.11.7" ], - "IRO-04.1": [ - "14" + "CPL-02": [ + "3.11.7" ], - "IRO-10": [ - "14" + "IRO-01": [ + "3.11.5" ], "IRO-10.2": [ - "14" - ], - "IAO-01": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" - ], - "IAO-02": [ - "11.1", - "11.2" - ], - "IAO-03": [ - "11.1" + "3.14" ], "PRI-01": [ - "2", - "3", - "8.1" - ], - "PRI-01.1": [ - "8.1" - ], - "PRI-01.4": [ - "8.2", - "10" + "3.11", + "3.11.5" ], "PRI-01.5": [ - "15" + "3.15" ], "PRI-01.6": [ - "8.3", - "13" + "3.13" + ], + "PRI-01.11": [ + "2.4", + "2.6.3", + "3.8.1", + "3.8.2", + "3.8.3", + "3.8.4", + "3.10", + "3.11.1", + "3.11.6", + "3.13", + "4.17.3", + "4.17.4", + "4.17.5" ], "PRI-02": [ - "6.1", - "8.1", - "9.1", - "9.3", - "9.4", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" - ], - "PRI-02.1": [ - "6.1", - "8.1", - "10" + "3.9", + "3.9.1", + "3.9.2", + "3.9.3", + "3.9.4", + "4.17.1" ], "PRI-03": [ - "4", - "5.2", - "10" + "2.4", + "2.5.2" + ], + "PRI-03.3": [ + "3.12" ], "PRI-03.4": [ - "5.1" + "2.5.1" ], - "PRI-03.6": [ - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "PRI-03.13": [ + "4.17.2" ], "PRI-04": [ - "9.1", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "3.12" ], "PRI-04.1": [ - "9.2", - "18.1", - "18.2", - "18.3", - "18.4" - ], - "PRI-05.1": [ - "8.2", - "9.4" + "2.4", + "3.11.1" ], "PRI-05.4": [ - "8.2", - "9.4", - "10", - "16", - "22" + "3.10", + "4.16", + "4.17", + "4.17.4" ], "PRI-06": [ - "6", - "21.1", - "21.2" + "2.5.1", + "2.5.2", + "2.5.3", + "2.5.4", + "2.6", + "2.6.1", + "2.6.2", + "3.11.6" ], "PRI-06.1": [ - "5.4", - "6.2" - ], - "PRI-06.2": [ - "6.2" + "2.5.4" ], "PRI-06.4": [ - "5.3", - "5.4", - "6.3" + "3.11.4" ], "PRI-06.5": [ - "5.3" - ], - "PRI-06.6": [ - "6.3" + "2.5.3" ], - "PRI-06.7": [ - "6.3" + "PRI-06.8": [ + "4.17.3" ], - "PRI-07.1": [ - "12" + "PRI-07": [ + "3.12" ], - "PRI-14": [ - "6.2" - ], - "PRI-14.1": [ - "6.2" - ], - "PRI-14.2": [ - "6.2" - ], - "PRM-05": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" - ], - "PRM-06": [ - "11.4", - "11.5", - "11.6" - ], - "PRM-07": [ - "11.4", - "11.5", - "11.6" + "PRI-17": [ + "2.6.2", + "3.11.4" ], "RSK-10": [ - "8.2" - ], - "SEA-02.1": [ - "1" - ], - "SAT-01": [ - "11.3" + "3.11.1" ], "SAT-03": [ - "11.3" + "3.11.3" ], "SAT-03.3": [ - "11.3" + "3.11.3" ], - "TDA-01": [ - "11.4", - "11.5", - "11.6" + "TPM-05": [ + "3.11.8" ], - "TDA-01.1": [ - "11.4", - "11.5", - "11.6" + "TPM-05.6": [ + "3.11.8" ], - "TPM-05": [ - "12" + "TPM-05.8": [ + "3.11.8" ], - "TPM-05.2": [ - "12" + "TPM-08": [ + "3.11.8" ] } }, "framework_to_scf": { - "total_mappings": 46, + "total_mappings": 40, "mappings": { - "1": [ - "SEA-02.1" + "3.11.2": [ + "GOV-04.1", + "AST-01.2" ], - "2": [ - "CPL-01", + "3.8": [ + "CPL-01" + ], + "3.11.7": [ + "CPL-01.4", + "CPL-02" + ], + "3.11.5": [ + "IRO-01", "PRI-01" ], - "3": [ + "3.14": [ + "IRO-10.2" + ], + "3.11": [ "PRI-01" ], - "4": [ - "PRI-03" + "3.15": [ + "PRI-01.5" ], - "6": [ - "PRI-06" + "3.13": [ + "PRI-01.6", + "PRI-01.11" ], - "10": [ - "PRI-01.4", - "PRI-02", - "PRI-02.1", + "2.4": [ + "PRI-01.11", "PRI-03", - "PRI-04", - "PRI-05.4" + "PRI-04.1" ], - "12": [ - "PRI-07.1", - "TPM-05", - "TPM-05.2" + "2.6.3": [ + "PRI-01.11" ], - "13": [ - "PRI-01.6" + "3.8.1": [ + "PRI-01.11" ], - "14": [ - "IRO-04.1", - "IRO-10", - "IRO-10.2" + "3.8.2": [ + "PRI-01.11" ], - "15": [ - "CLD-09", - "DCH-19", - "DCH-25", - "PRI-01.5" + "3.8.3": [ + "PRI-01.11" ], - "16": [ - "PRI-05.4" + "3.8.4": [ + "PRI-01.11" ], - "22": [ + "3.10": [ + "PRI-01.11", "PRI-05.4" ], - "8.4": [ - "GOV-02" - ], - "8.3": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "PRI-01.6" - ], - "11.1": [ - "GOV-15.1", - "GOV-15.3", - "GOV-15.4", - "IAO-01", - "IAO-02", - "IAO-03", - "PRM-05" - ], - "11.3": [ - "GOV-15.2", - "IAO-01", - "PRM-05", - "SAT-01", - "SAT-03", - "SAT-03.3" - ], - "11.5": [ - "GOV-15.2", - "IAO-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TDA-01", - "TDA-01.1" - ], - "11.6": [ - "GOV-15.2", - "IAO-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TDA-01", - "TDA-01.1" - ], - "11.2": [ - "GOV-15.3", - "IAO-01", - "IAO-02", - "PRM-05" - ], - "11.7": [ - "GOV-15.5", - "CPL-03", - "CPL-03.2", - "IAO-01", - "PRM-05" - ], - "11.8": [ - "GOV-15.5", - "CPL-03", - "CPL-03.2", - "IAO-01", - "PRM-05" - ], - "11.4": [ - "IAO-01", - "PRM-05", - "PRM-06", - "PRM-07", - "TDA-01", - "TDA-01.1" - ], - "8.1": [ - "PRI-01", - "PRI-01.1", - "PRI-02", - "PRI-02.1" - ], - "8.2": [ - "PRI-01.4", - "PRI-05.1", - "PRI-05.4", + "3.11.1": [ + "PRI-01.11", + "PRI-04.1", "RSK-10" ], - "6.1": [ - "PRI-02", - "PRI-02.1" + "3.11.6": [ + "PRI-01.11", + "PRI-06" + ], + "4.17.3": [ + "PRI-01.11", + "PRI-06.8" ], - "9.1": [ - "PRI-02", - "PRI-04" + "4.17.4": [ + "PRI-01.11", + "PRI-05.4" + ], + "4.17.5": [ + "PRI-01.11" ], - "9.3": [ + "3.9": [ "PRI-02" ], - "9.4": [ - "PRI-02", - "PRI-05.1", - "PRI-05.4" + "3.9.1": [ + "PRI-02" ], - "17.1": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "3.9.2": [ + "PRI-02" ], - "17.2": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "3.9.3": [ + "PRI-02" ], - "17.3": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "3.9.4": [ + "PRI-02" ], - "17.4": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "4.17.1": [ + "PRI-02" ], - "17.5": [ - "PRI-02", - "PRI-03.6", - "PRI-04" + "2.5.2": [ + "PRI-03", + "PRI-06" ], - "5.2": [ - "PRI-03" + "3.12": [ + "PRI-03.3", + "PRI-04", + "PRI-07" ], - "5.1": [ - "PRI-03.4" + "2.5.1": [ + "PRI-03.4", + "PRI-06" ], - "9.2": [ - "PRI-04.1" + "4.17.2": [ + "PRI-03.13" ], - "18.1": [ - "PRI-04.1" + "4.16": [ + "PRI-05.4" ], - "18.2": [ - "PRI-04.1" + "4.17": [ + "PRI-05.4" ], - "18.3": [ - "PRI-04.1" + "2.5.3": [ + "PRI-06", + "PRI-06.5" ], - "18.4": [ - "PRI-04.1" + "2.5.4": [ + "PRI-06", + "PRI-06.1" ], - "21.1": [ + "2.6": [ "PRI-06" ], - "21.2": [ + "2.6.1": [ "PRI-06" ], - "5.4": [ - "PRI-06.1", - "PRI-06.4" - ], - "6.2": [ - "PRI-06.1", - "PRI-06.2", - "PRI-14", - "PRI-14.1", - "PRI-14.2" + "2.6.2": [ + "PRI-06", + "PRI-17" ], - "5.3": [ + "3.11.4": [ "PRI-06.4", - "PRI-06.5" + "PRI-17" ], - "6.3": [ - "PRI-06.4", - "PRI-06.6", - "PRI-06.7" + "3.11.3": [ + "SAT-03", + "SAT-03.3" + ], + "3.11.8": [ + "TPM-05", + "TPM-05.6", + "TPM-05.8", + "TPM-08" ] } } diff --git a/docs/api/crosswalks/emea-rus-152-fz-2025.json b/docs/api/crosswalks/emea-rus-152-fz-2025.json new file mode 100644 index 00000000..11d5c8e9 --- /dev/null +++ b/docs/api/crosswalks/emea-rus-152-fz-2025.json @@ -0,0 +1,146 @@ +{ + "framework_id": "emea-rus-152-fz-2025", + "display_name": "Russia - Federal Law No. 152 - FZ (2025)", + "scf_to_framework": { + "total_mappings": 17, + "mappings": { + "DCH-23": [ + "Art. 13.1" + ], + "PRI-01.4": [ + "Art. 22.1" + ], + "PRI-01.5": [ + "Art. 12" + ], + "PRI-01.6": [ + "Art. 7", + "Art. 18.1", + "Art. 19" + ], + "PRI-01.11": [ + "Art. 5", + "Art. 6", + "Art. 11", + "Art. 18.1" + ], + "PRI-02": [ + "Art. 18" + ], + "PRI-03": [ + "Art. 6", + "Art. 9", + "Art. 10.1" + ], + "PRI-05.3": [ + "Art. 13.1" + ], + "PRI-05.4": [ + "Art. 10", + "Art. 11", + "Art. 13" + ], + "PRI-05.7": [ + "Art. 10" + ], + "PRI-06": [ + "Art. 14", + "Art. 15", + "Art. 20" + ], + "PRI-06.3": [ + "Art. 17" + ], + "PRI-06.4": [ + "Art. 21" + ], + "PRI-15": [ + "Art. 22" + ], + "PRI-19": [ + "Art. 16" + ], + "PRI-19.2": [ + "Art. 16" + ], + "PRI-19.3": [ + "Art. 16" + ] + } + }, + "framework_to_scf": { + "total_mappings": 21, + "mappings": { + "Art. 13.1": [ + "DCH-23", + "PRI-05.3" + ], + "Art. 22.1": [ + "PRI-01.4" + ], + "Art. 12": [ + "PRI-01.5" + ], + "Art. 7": [ + "PRI-01.6" + ], + "Art. 18.1": [ + "PRI-01.6", + "PRI-01.11" + ], + "Art. 19": [ + "PRI-01.6" + ], + "Art. 5": [ + "PRI-01.11" + ], + "Art. 6": [ + "PRI-01.11", + "PRI-03" + ], + "Art. 11": [ + "PRI-01.11", + "PRI-05.4" + ], + "Art. 18": [ + "PRI-02" + ], + "Art. 9": [ + "PRI-03" + ], + "Art. 10.1": [ + "PRI-03" + ], + "Art. 10": [ + "PRI-05.4", + "PRI-05.7" + ], + "Art. 13": [ + "PRI-05.4" + ], + "Art. 14": [ + "PRI-06" + ], + "Art. 15": [ + "PRI-06" + ], + "Art. 20": [ + "PRI-06" + ], + "Art. 17": [ + "PRI-06.3" + ], + "Art. 21": [ + "PRI-06.4" + ], + "Art. 22": [ + "PRI-15" + ], + "Art. 16": [ + "PRI-19", + "PRI-19.2", + "PRI-19.3" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-rus-federal-law-27-2006.json b/docs/api/crosswalks/emea-rus-federal-law-27-2006.json deleted file mode 100644 index 17439e7c..00000000 --- a/docs/api/crosswalks/emea-rus-federal-law-27-2006.json +++ /dev/null @@ -1,184 +0,0 @@ -{ - "framework_id": "emea-rus-federal-law-27-2006", - "display_name": "Russia - Federal Law of 27 (2006)", - "scf_to_framework": { - "total_mappings": 28, - "mappings": { - "GOV-01": [ - "7", - "19" - ], - "CPL-01": [ - "7", - "19" - ], - "CPL-02": [ - "7", - "19" - ], - "CPL-03": [ - "7" - ], - "DCH-01": [ - "7", - "12", - "19" - ], - "DCH-22.1": [ - "17" - ], - "DCH-24": [ - "7" - ], - "DCH-24.1": [ - "7" - ], - "PRI-01": [ - "Inferred", - "Expectation" - ], - "PRI-01.1": [ - "23" - ], - "PRI-02": [ - "22" - ], - "PRI-02.1": [ - "5" - ], - "PRI-03": [ - "6", - "9" - ], - "PRI-04": [ - "5" - ], - "PRI-04.1": [ - "5" - ], - "PRI-05": [ - "5" - ], - "PRI-05.4": [ - "6", - "10" - ], - "PRI-05.6": [ - "16" - ], - "PRI-06": [ - "14" - ], - "PRI-06.1": [ - "17" - ], - "PRI-06.2": [ - "18" - ], - "PRI-06.3": [ - "17" - ], - "PRI-15": [ - "23" - ], - "SEA-01": [ - "7", - "12", - "19" - ], - "SEA-02": [ - "7", - "12", - "19" - ], - "SEA-03": [ - "7", - "12", - "19" - ], - "SEA-15": [ - "7" - ], - "TPM-04.4": [ - "7" - ] - } - }, - "framework_to_scf": { - "total_mappings": 15, - "mappings": { - "5": [ - "PRI-02.1", - "PRI-04", - "PRI-04.1", - "PRI-05" - ], - "6": [ - "PRI-03", - "PRI-05.4" - ], - "7": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-04.4" - ], - "9": [ - "PRI-03" - ], - "10": [ - "PRI-05.4" - ], - "12": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "14": [ - "PRI-06" - ], - "16": [ - "PRI-05.6" - ], - "17": [ - "DCH-22.1", - "PRI-06.1", - "PRI-06.3" - ], - "18": [ - "PRI-06.2" - ], - "19": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "22": [ - "PRI-02" - ], - "23": [ - "PRI-01.1", - "PRI-15" - ], - "Inferred": [ - "PRI-01" - ], - "Expectation": [ - "PRI-01" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-sau-cgiot-2024.json b/docs/api/crosswalks/emea-sau-cgiot-2024.json index 306cbe6d..2511f02a 100644 --- a/docs/api/crosswalks/emea-sau-cgiot-2024.json +++ b/docs/api/crosswalks/emea-sau-cgiot-2024.json @@ -1,6 +1,6 @@ { "framework_id": "emea-sau-cgiot-2024", - "display_name": "Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT-1:2024)", + "display_name": "Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT - 1:2024)", "scf_to_framework": { "total_mappings": 118, "mappings": { diff --git a/docs/api/crosswalks/emea-sau-cscc-1-2019.json b/docs/api/crosswalks/emea-sau-cscc-1-2019.json index 78aca9c5..270b7d6e 100644 --- a/docs/api/crosswalks/emea-sau-cscc-1-2019.json +++ b/docs/api/crosswalks/emea-sau-cscc-1-2019.json @@ -2,14 +2,44 @@ "framework_id": "emea-sau-cscc-1-2019", "display_name": "Saudi Arabia - Critical Systems Cybersecurity Controls (CSCC – 1: 2019)", "scf_to_framework": { - "total_mappings": 152, + "total_mappings": 172, "mappings": { - "GOV-09": [ - "1-1" + "GOV-01": [ + "1-1-1" + ], + "GOV-08": [ + "1-1-1" + ], + "GOV-14": [ + "1-1-1" + ], + "GOV-15": [ + "1-1-1", + "2-1-1" + ], + "GOV-15.1": [ + "1-1-1" + ], + "GOV-15.2": [ + "1-1-1" + ], + "GOV-15.3": [ + "1-1-1" + ], + "GOV-15.4": [ + "1-1-1" + ], + "GOV-15.5": [ + "1-1-1" ], "AST-01": [ - "2-1", - "2-5" + "1-3-1" + ], + "AST-01.1": [ + "3-1-1-2" + ], + "AST-01.2": [ + "2-1-1-2" ], "AST-02": [ "2-1-1-1" @@ -20,9 +50,6 @@ "AST-05.1": [ "2-6-1-5" ], - "AST-16": [ - "2-5" - ], "AST-27": [ "2-3-1-4" ], @@ -30,28 +57,24 @@ "2-2-1-8" ], "BCD-01": [ - "2-8", - "3-1", - "3-1-1-1", - "3-1-1-2" + "2-8-1", + "3-1-1", + "3-1-1-1" ], "BCD-02": [ + "2-1-1-1", "2-8-1-1", "3-1-1-2" ], "BCD-03.1": [ "3-1-1-4" ], - "BCD-04.2": [ - "3-1-1-1" - ], - "BCD-08": [ - "3-1-1-1" - ], - "BCD-09": [ - "3-1-1-1" + "BCD-04": [ + "3-1-1-3", + "3-1-1-4" ], "BCD-11": [ + "2-8-1-1", "2-8-1-2", "2-8-1-3" ], @@ -61,23 +84,23 @@ "BCD-11.4": [ "2-8-1-3" ], - "BCD-11.5": [ - "3-1-1-3" + "BCD-11.9": [ + "2-8-1-3" + ], + "BCD-11.10": [ + "2-8-1-3" ], "BCD-12": [ "2-8-2" ], - "CHG-02.2": [ - "1-3-1-2" - ], - "CHG-03": [ - "1-3-1-2" + "CHG-01": [ + "1-3-1" ], "CHG-04.5": [ "1-3-2-2" ], "CLD-01": [ - "4-2" + "4-2-1" ], "CLD-04": [ "1-3-2-3" @@ -85,45 +108,42 @@ "CLD-09": [ "4-2-1-1" ], - "CPL-01": [ - "1-4" - ], "CPL-02": [ - "1-4" + "1-4-1" ], "CPL-02.1": [ - "1-4-2", - "2-13-4" - ], - "CPL-03": [ - "1-4-1", - "2-13-4" + "1-4-2" ], "CPL-03.1": [ "1-4-2" ], - "CPL-03.2": [ - "1-4-1" - ], "CFG-01": [ "2-3-1-6" ], "CFG-02": [ "1-3-2-3", - "2-3-1-7" + "2-2-1-5", + "2-2-1-6", + "2-3-1-6", + "2-3-1-7", + "2-4-1-3", + "2-12-1" ], "CFG-02.1": [ + "2-3-1-6", + "2-4-1-2" + ], + "CFG-02.2": [ "2-3-1-6" ], "CFG-02.5": [ - "1-3-2-3", - "2-3-1-7" + "2-6-1-3" ], "CFG-03.3": [ "2-3-1-1" ], "MON-01": [ - "2-11" + "2-11-1" ], "MON-01.2": [ "2-11-1-3", @@ -135,9 +155,6 @@ "MON-01.8": [ "2-11-1-2" ], - "MON-01.16": [ - "2-11" - ], "MON-02": [ "2-11-1-3", "2-11-1-4" @@ -149,15 +166,15 @@ "MON-02.2": [ "2-11-1-3" ], - "MON-02.5": [ - "2-3-1-8" - ], "MON-03": [ "2-11-1-5" ], "MON-03.2": [ "2-11-1-3" ], + "MON-03.7": [ + "2-2-1-8" + ], "MON-08": [ "2-3-1-8", "2-11-1-5", @@ -171,7 +188,7 @@ "2-11-2" ], "CRY-01": [ - "2-7", + "2-7-1", "2-7-1-3" ], "CRY-01.5": [ @@ -181,14 +198,27 @@ "2-3-1-5", "2-7-1-1" ], + "CRY-04": [ + "2-3-1-5", + "2-7-1-1" + ], "CRY-05": [ "2-7-1-2" ], "DCH-01": [ - "2-6", + "2-6-1", + "2-6-1-3" + ], + "DCH-01.2": [ + "2-6-1-1", + "2-6-1-3" + ], + "DCH-01.4": [ + "2-6-1-1", "2-6-1-3" ], "DCH-02": [ + "2-6-1-1", "2-6-1-2" ], "DCH-02.1": [ @@ -210,16 +240,17 @@ "DCH-25": [ "2-6-1-5" ], + "DCH-26": [ + "4-2-1-1" + ], "END-01": [ - "2-3-1-2", - "2-5" + "2-3-1-2" ], "END-02": [ "2-3-1-2" ], "HRS-01": [ - "1-5", - "2-5" + "1-5-1" ], "HRS-02": [ "1-5-1-2" @@ -230,20 +261,10 @@ "HRS-04.3": [ "1-5-1-2" ], - "HRS-05": [ - "2-5" - ], - "HRS-05.1": [ - "2-5" - ], - "HRS-05.3": [ - "2-5" - ], "IAC-01": [ - "2-2", - "2-2-1-5" + "2-2-1" ], - "IAC-02.1": [ + "IAC-05": [ "2-2-1-7" ], "IAC-06": [ @@ -259,22 +280,25 @@ "IAC-06.3": [ "2-2-1-4" ], - "IAC-10": [ - "2-2-1-6" - ], "IAC-10.1": [ "2-2-1-5" ], "IAC-10.5": [ "2-2-1-6" ], + "IAC-10.8": [ + "2-3-1-7" + ], "IAC-10.11": [ "2-2-1-6" ], "IAC-15": [ "2-2-1-7" ], - "IAC-18": [ + "IAC-16": [ + "2-2-1-7" + ], + "IAC-17": [ "2-2-2" ], "IAC-20.2": [ @@ -283,8 +307,45 @@ "IAC-20.4": [ "2-3-1-4" ], + "IAO-01": [ + "1-3-1", + "1-3-2", + "2-13-4" + ], + "IAO-01.1": [ + "1-3-1-1", + "2-13-4" + ], + "IAO-02": [ + "1-3-1-1", + "1-3-1-2", + "2-13-4" + ], + "IAO-02.2": [ + "1-3-1-1", + "2-13-4" + ], + "IAO-02.4": [ + "2-13-4" + ], + "IAO-03": [ + "2-13-4" + ], + "IAO-04": [ + "1-3-2-1" + ], + "IAO-05": [ + "2-13-4" + ], + "IAO-06": [ + "1-3-1-2", + "2-13-4" + ], + "IAO-07": [ + "2-13-4" + ], "MDM-01": [ - "2-5" + "2-5-1" ], "MDM-02": [ "2-5-1-1" @@ -292,16 +353,12 @@ "MDM-03": [ "2-5-1-2" ], - "MDM-06": [ - "2-5-1-1" - ], "MDM-11": [ "2-5-1-1" ], "NET-01": [ "2-3-1-5", - "2-4", - "2-4-1-5" + "2-4-1" ], "NET-02": [ "2-4-1-5" @@ -309,6 +366,12 @@ "NET-02.1": [ "2-4-1-8" ], + "NET-02.3": [ + "2-6-1-5" + ], + "NET-03": [ + "2-4-1-5" + ], "NET-04": [ "2-4-1-4", "2-4-1-6", @@ -322,7 +385,6 @@ "2-4-1-9" ], "NET-04.6": [ - "2-3-1-6", "2-4-1-2" ], "NET-06": [ @@ -330,6 +392,7 @@ "2-4-1-1" ], "NET-06.3": [ + "2-3-1-4", "2-4-1-6", "2-4-1-7" ], @@ -341,6 +404,9 @@ "2-2-1-1", "2-2-1-2" ], + "NET-14.1": [ + "2-2-1-2" + ], "NET-14.5": [ "2-2-1-1", "2-2-1-2" @@ -355,45 +421,28 @@ "NET-18.1": [ "2-4-1-3" ], - "PES-01": [ - "2-3" + "PRI-05.3": [ + "2-6-1-1" ], "PRM-01": [ - "1-1" + "1-3-1", + "2-13-1" ], "PRM-01.1": [ - "1-1", "1-1-1" ], - "PRM-02": [ - "1-1" - ], - "PRM-03": [ - "1-1" - ], "PRM-04": [ - "1-3", - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "PRM-05": [ - "1-3-1-2", "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "PRM-07": [ - "2-13-4" + "2-13-1" ], "RSK-01": [ - "1-2" + "1-2-1" ], "RSK-04": [ "1-2-1-1" @@ -401,24 +450,27 @@ "RSK-04.1": [ "1-2-1-2" ], + "RSK-04.2": [ + "1-2-1" + ], + "SEA-02": [ + "2-12-2" + ], + "OPS-02": [ + "1-1-1" + ], "TDA-01": [ - "2-13", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "1-3-2", + "2-13-1" ], "TDA-01.1": [ "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "TDA-02": [ "2-13-1", "2-13-2", + "2-13-3", "2-13-3-1", "2-13-3-2", "2-13-3-3", @@ -427,11 +479,7 @@ "TDA-06": [ "1-3-2-3", "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "TDA-07": [ "1-3-2-4" @@ -443,7 +491,6 @@ "1-3-2-4" ], "TDA-09": [ - "1-3-1-1", "1-3-2-1" ], "TDA-09.2": [ @@ -452,14 +499,14 @@ "TDA-09.3": [ "1-3-2-1" ], - "TDA-15": [ - "1-3-2-1" + "TDA-20": [ + "1-3-2-2" ], "TDA-20.3": [ "1-3-2-2" ], "TPM-01": [ - "4-1" + "4-1-1" ], "TPM-02": [ "4-1-1-1" @@ -485,13 +532,12 @@ "4-1-1-2" ], "TPM-05": [ - "4-1-1", "4-1-1-1", "4-1-1-2" ], "VPM-01": [ "2-3-1-3", - "2-9", + "2-9-1", "2-9-2" ], "VPM-01.1": [ @@ -514,10 +560,16 @@ "2-9-2" ], "VPM-06.2": [ - "2-9-2-1" + "2-9-2" + ], + "VPM-06.6": [ + "2-9-1-1" + ], + "VPM-06.7": [ + "2-9-1-1" ], "VPM-07": [ - "2-10", + "2-10-1", "2-10-1-1", "2-10-1-2", "2-10-2" @@ -526,165 +578,184 @@ "2-10-1-2" ], "WEB-01": [ - "2-12", + "2-12-1", "2-12-1-1", "2-12-1-2" ], "WEB-04": [ - "2-12", - "2-12-1-1", - "2-12-1-2" + "2-12-1-1" ], "WEB-06": [ "2-12-1-1" ], "WEB-07": [ - "2-12-1-2" + "2-12-1-2", + "2-12-2" ], "WEB-08": [ "2-12-1-1" ], "WEB-10": [ "2-12-1-1" - ], - "WEB-12": [ - "2-12-1-1" ] } }, "framework_to_scf": { - "total_mappings": 107, + "total_mappings": 104, "mappings": { - "1-1": [ - "GOV-09", - "PRM-01", + "1-1-1": [ + "GOV-01", + "GOV-08", + "GOV-14", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", "PRM-01.1", - "PRM-02", - "PRM-03" + "OPS-02" ], - "2-1": [ - "AST-01" + "2-1-1": [ + "GOV-15" ], - "2-5": [ + "1-3-1": [ "AST-01", - "AST-16", - "END-01", - "HRS-01", - "HRS-05", - "HRS-05.1", - "HRS-05.3", - "MDM-01" + "CHG-01", + "IAO-01", + "PRM-01" ], - "2-1-1-1": [ - "AST-02" + "3-1-1-2": [ + "AST-01.1", + "BCD-02" ], "2-1-1-2": [ + "AST-01.2", "AST-03" ], + "2-1-1-1": [ + "AST-02", + "BCD-02" + ], "2-6-1-5": [ "AST-05.1", "DCH-14.2", "DCH-17", - "DCH-25" + "DCH-25", + "NET-02.3" ], "2-3-1-4": [ "AST-27", "IAC-20.4", - "NET-06" + "NET-06", + "NET-06.3" ], "2-2-1-8": [ "AST-28", + "MON-03.7", "IAC-20.2" ], - "2-8": [ + "2-8-1": [ "BCD-01" ], - "3-1": [ + "3-1-1": [ "BCD-01" ], "3-1-1-1": [ - "BCD-01", - "BCD-04.2", - "BCD-08", - "BCD-09" - ], - "3-1-1-2": [ - "BCD-01", - "BCD-02" + "BCD-01" ], "2-8-1-1": [ - "BCD-02" + "BCD-02", + "BCD-11" ], "3-1-1-4": [ - "BCD-03.1" + "BCD-03.1", + "BCD-04" + ], + "3-1-1-3": [ + "BCD-04" ], "2-8-1-2": [ "BCD-11" ], "2-8-1-3": [ "BCD-11", - "BCD-11.4" + "BCD-11.4", + "BCD-11.9", + "BCD-11.10" ], "2-8-2": [ "BCD-11.1", "BCD-12" ], - "3-1-1-3": [ - "BCD-11.5" - ], - "1-3-1-2": [ - "CHG-02.2", - "CHG-03", - "PRM-05" - ], "1-3-2-2": [ "CHG-04.5", + "TDA-20", "TDA-20.3" ], - "4-2": [ + "4-2-1": [ "CLD-01" ], "1-3-2-3": [ "CLD-04", "CFG-02", - "CFG-02.5", "TDA-06" ], "4-2-1-1": [ - "CLD-09" + "CLD-09", + "DCH-26" ], - "1-4": [ - "CPL-01", + "1-4-1": [ "CPL-02" ], "1-4-2": [ "CPL-02.1", "CPL-03.1" ], - "2-13-4": [ - "CPL-02.1", - "CPL-03", - "PRM-07" - ], - "1-4-1": [ - "CPL-03", - "CPL-03.2" - ], "2-3-1-6": [ "CFG-01", + "CFG-02", "CFG-02.1", - "NET-04.6" + "CFG-02.2" + ], + "2-2-1-5": [ + "CFG-02", + "IAC-10.1" + ], + "2-2-1-6": [ + "CFG-02", + "IAC-10.5", + "IAC-10.11" ], "2-3-1-7": [ "CFG-02", - "CFG-02.5" + "IAC-10.8" + ], + "2-4-1-3": [ + "CFG-02", + "NET-06.5", + "NET-18.1" + ], + "2-12-1": [ + "CFG-02", + "WEB-01" + ], + "2-4-1-2": [ + "CFG-02.1", + "NET-04.6" + ], + "2-6-1-3": [ + "CFG-02.5", + "DCH-01", + "DCH-01.2", + "DCH-01.4", + "DCH-03.1" ], "2-3-1-1": [ "CFG-03.3" ], - "2-11": [ - "MON-01", - "MON-01.16" + "2-11-1": [ + "MON-01" ], "2-11-1-3": [ "MON-01.2", @@ -704,22 +775,21 @@ "2-11-1-2": [ "MON-01.8" ], - "2-3-1-8": [ - "MON-02.5", - "MON-08" - ], "2-11-1-5": [ "MON-03", "MON-08", "MON-08.1" ], + "2-3-1-8": [ + "MON-08" + ], "2-11-2": [ "MON-08", "MON-08.1", "MON-10", "DCH-18" ], - "2-7": [ + "2-7-1": [ "CRY-01" ], "2-7-1-3": [ @@ -728,28 +798,30 @@ ], "2-3-1-5": [ "CRY-03", + "CRY-04", "NET-01", "NET-15" ], "2-7-1-1": [ - "CRY-03" + "CRY-03", + "CRY-04" ], "2-7-1-2": [ "CRY-05" ], - "2-6": [ + "2-6-1": [ "DCH-01" ], - "2-6-1-3": [ - "DCH-01", - "DCH-03.1" + "2-6-1-1": [ + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-02.1", + "PRI-05.3" ], "2-6-1-2": [ "DCH-02" ], - "2-6-1-1": [ - "DCH-02.1" - ], "2-6-1-4": [ "DCH-18" ], @@ -757,7 +829,7 @@ "END-01", "END-02" ], - "1-5": [ + "1-5-1": [ "HRS-01" ], "1-5-1-2": [ @@ -767,16 +839,13 @@ "1-5-1-1": [ "HRS-04" ], - "2-2": [ + "2-2-1": [ "IAC-01" ], - "2-2-1-5": [ - "IAC-01", - "IAC-10.1" - ], "2-2-1-7": [ - "IAC-02.1", - "IAC-15" + "IAC-05", + "IAC-15", + "IAC-16" ], "2-2-1-3": [ "IAC-06", @@ -787,28 +856,55 @@ "IAC-06.1", "IAC-06.3" ], - "2-2-1-6": [ - "IAC-10", - "IAC-10.5", - "IAC-10.11" - ], "2-2-2": [ - "IAC-18" + "IAC-17" + ], + "1-3-2": [ + "IAO-01", + "TDA-01" + ], + "2-13-4": [ + "IAO-01", + "IAO-01.1", + "IAO-02", + "IAO-02.2", + "IAO-02.4", + "IAO-03", + "IAO-05", + "IAO-06", + "IAO-07" + ], + "1-3-1-1": [ + "IAO-01.1", + "IAO-02", + "IAO-02.2" + ], + "1-3-1-2": [ + "IAO-02", + "IAO-06" + ], + "1-3-2-1": [ + "IAO-04", + "TDA-09", + "TDA-09.2", + "TDA-09.3" + ], + "2-5-1": [ + "MDM-01" ], "2-5-1-1": [ "MDM-02", - "MDM-06", "MDM-11" ], "2-5-1-2": [ "MDM-03" ], - "2-4": [ + "2-4-1": [ "NET-01" ], "2-4-1-5": [ - "NET-01", - "NET-02" + "NET-02", + "NET-03" ], "2-4-1-8": [ "NET-02.1" @@ -834,81 +930,37 @@ "NET-04", "NET-04.1" ], - "2-4-1-2": [ - "NET-04.6" - ], "2-4-1-1": [ "NET-06" ], - "2-4-1-3": [ - "NET-06.5", - "NET-18.1" - ], "2-2-1-1": [ "NET-14", "NET-14.5" ], "2-2-1-2": [ "NET-14", + "NET-14.1", "NET-14.5" ], - "2-3": [ - "PES-01" - ], - "1-1-1": [ - "PRM-01.1" - ], - "1-3": [ - "PRM-04" - ], "2-13-1": [ - "PRM-04", - "PRM-05", - "TDA-01.1", - "TDA-02", - "TDA-06" - ], - "2-13-2": [ - "PRM-04", - "PRM-05", - "TDA-01.1", - "TDA-02", - "TDA-06" - ], - "2-13-3-1": [ - "PRM-04", - "PRM-05", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-06" - ], - "2-13-3-2": [ - "PRM-04", - "PRM-05", - "TDA-01", - "TDA-01.1", - "TDA-02", - "TDA-06" - ], - "2-13-3-3": [ - "PRM-04", + "PRM-01", "PRM-05", + "PRM-07", "TDA-01", "TDA-01.1", "TDA-02", "TDA-06" ], - "2-13-3-4": [ + "2-13-2": [ "PRM-04", "PRM-05", - "TDA-01", "TDA-01.1", "TDA-02", "TDA-06" ], - "1-2": [ - "RSK-01" + "1-2-1": [ + "RSK-01", + "RSK-04.2" ], "1-2-1-1": [ "RSK-04" @@ -916,24 +968,31 @@ "1-2-1-2": [ "RSK-04.1" ], - "2-13": [ - "TDA-01" + "2-12-2": [ + "SEA-02", + "WEB-07" + ], + "2-13-3": [ + "TDA-02" + ], + "2-13-3-1": [ + "TDA-02" + ], + "2-13-3-2": [ + "TDA-02" + ], + "2-13-3-3": [ + "TDA-02" + ], + "2-13-3-4": [ + "TDA-02" ], "1-3-2-4": [ "TDA-07", "TDA-08", "TDA-08.1" ], - "1-3-1-1": [ - "TDA-09" - ], - "1-3-2-1": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-15" - ], - "4-1": [ + "4-1-1": [ "TPM-01" ], "4-1-1-1": [ @@ -953,19 +1012,17 @@ "TPM-04.1", "TPM-05" ], - "4-1-1": [ - "TPM-05" - ], "2-3-1-3": [ "VPM-01", "VPM-05" ], - "2-9": [ + "2-9-1": [ "VPM-01" ], "2-9-2": [ "VPM-01", - "VPM-06" + "VPM-06", + "VPM-06.2" ], "2-10-1-1": [ "VPM-01.1", @@ -979,12 +1036,11 @@ "VPM-04" ], "2-9-1-1": [ - "VPM-06" + "VPM-06", + "VPM-06.6", + "VPM-06.7" ], - "2-9-2-1": [ - "VPM-06.2" - ], - "2-10": [ + "2-10-1": [ "VPM-07" ], "2-10-1-2": [ @@ -994,21 +1050,15 @@ "2-10-2": [ "VPM-07" ], - "2-12": [ - "WEB-01", - "WEB-04" - ], "2-12-1-1": [ "WEB-01", "WEB-04", "WEB-06", "WEB-08", - "WEB-10", - "WEB-12" + "WEB-10" ], "2-12-1-2": [ "WEB-01", - "WEB-04", "WEB-07" ] } diff --git a/docs/api/crosswalks/emea-sau-ecc-1-2018.json b/docs/api/crosswalks/emea-sau-ecc-1-2018.json index 53cc4239..6019a487 100644 --- a/docs/api/crosswalks/emea-sau-ecc-1-2018.json +++ b/docs/api/crosswalks/emea-sau-ecc-1-2018.json @@ -2,24 +2,40 @@ "framework_id": "emea-sau-ecc-1-2018", "display_name": "Saudi Arabia - Essential Cybersecurity Controls (ECC – 1 : 2018)", "scf_to_framework": { - "total_mappings": 190, + "total_mappings": 169, "mappings": { "GOV-01": [ "1-2-1", - "1-3-2" + "2-1-1" + ], + "GOV-01.1": [ + "1-1-1", + "1-2-3", + "1-4-1" + ], + "GOV-01.2": [ + "1-8-3" + ], + "GOV-01.3": [ + "1-1-3", + "1-3-4", + "2-3-4" ], "GOV-02": [ "1-3-1", - "1-3-3" + "1-3-3", + "2-1-1", + "2-1-2", + "2-1-3", + "2-1-4", + "2-2-1", + "2-2-2" ], "GOV-03": [ "1-1-3", "1-3-4", - "1-6-4", - "1-9-6", - "1-10-5", - "2-2-4", - "2-3-4", + "1-4-2", + "2-1-6", "2-4-4", "2-5-4", "2-6-4", @@ -39,41 +55,59 @@ ], "GOV-04": [ "1-2-2", - "1-4-1", - "1-4-2", - "1-5-2" + "1-4-1" + ], + "GOV-04.1": [ + "1-4-1" + ], + "GOV-04.2": [ + "1-4-1" ], "GOV-08": [ "1-1-1" ], - "AST-01": [ - "2-1-1", + "GOV-14": [ + "1-9-2" + ], + "GOV-15": [ + "1-3-2", + "1-9-2", + "1-10-2", "2-1-2", - "2-6-1", + "2-1-4", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", "2-6-2", - "2-6-4" + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-2", + "2-14-2", + "2-15-2", + "3-1-2", + "4-2-2", + "5-1-2" + ], + "AST-04.1": [ + "2-1-5" ], "AST-09": [ "2-14-3-4" ], "AST-16": [ - "2-6-1", - "2-6-2" + "2-6-1" ], "BCD-01": [ - "2-4-4", - "2-9-1", "2-9-2", - "2-9-3", - "2-9-3-1", - "2-9-4", "3-1-1", "3-1-2", - "3-1-3", "3-1-3-1", "3-1-3-2", - "3-1-3-3", - "3-1-4" + "3-1-3-3" ], "BCD-01.1": [ "3-1-3-2" @@ -82,54 +116,28 @@ "3-1-3-2" ], "BCD-01.4": [ - "2-9-3-2" - ], - "BCD-02": [ - "2-9-3-2" - ], - "BCD-02.1": [ - "2-9-3-2" - ], - "BCD-02.2": [ - "2-9-3-2" - ], - "BCD-02.3": [ - "2-9-3-2" - ], - "BCD-06": [ - "3-1-4" + "2-9-1" ], "BCD-11": [ - "2-9-3" + "2-4-3-3", + "2-9-3-1", + "2-9-3-2" ], "BCD-11.1": [ "2-9-3-3" ], - "BCD-12": [ - "2-4-3-3" - ], - "BCD-12.1": [ - "2-4-3-3" - ], - "CHG-01": [ - "1-6-2" - ], - "CHG-02": [ - "1-6-3-5" - ], - "CHG-02.2": [ - "1-6-2-1", - "1-6-3-5" - ], - "CHG-02.3": [ - "1-6-2-2" - ], "CLD-01": [ "4-2-1", "4-2-2", - "4-2-3", + "4-2-3-1", "4-2-3-2", - "4-2-4" + "4-2-3-3" + ], + "CLD-01.1": [ + "4-2-3-1" + ], + "CLD-01.2": [ + "4-2-3-1" ], "CLD-02": [ "4-2-3-2" @@ -143,104 +151,57 @@ "1-7-2" ], "CPL-02": [ - "1-3-2" + "1-8-1", + "1-8-3" ], "CPL-02.1": [ - "1-8-1", "1-8-3" ], "CPL-03": [ "1-3-2", - "1-8-1" + "1-8-1", + "1-8-2", + "2-2-4" ], "CPL-03.1": [ "1-8-2" ], - "CPL-03.2": [ - "1-8-1" - ], - "CFG-01": [ - "1-6-2-2", - "2-4-4", - "2-5-4" + "CPL-08": [ + "4-1-3-2" ], "CFG-02": [ "1-3-3", - "2-4-1", - "2-4-2", - "5-1-3-7" + "2-4-1" ], "CFG-02.1": [ - "1-6-2-2" + "5-1-3-7" ], - "CFG-02.5": [ + "CFG-02.2": [ "5-1-3-7" ], - "CFG-03": [ - "2-5-3-5" + "CFG-02.5": [ + "5-1-3-5", + "5-1-3-6", + "5-1-3-7" ], - "CFG-04.2": [ - "2-4-1", - "2-5-3-3" + "CFG-09.3": [ + "1-6-3-2" ], "MON-01": [ - "2-3-4", "2-12-1", "2-12-2", - "2-12-3", - "2-12-4", "5-1-3-3" ], - "MON-01.1": [ - "2-5-3-6" - ], "MON-01.2": [ "2-12-3-3", + "2-12-3-4", "5-1-3-3" ], "MON-01.4": [ - "2-12-3-1" - ], - "MON-01.8": [ - "2-12-3-4" - ], - "MON-01.12": [ - "2-12-3-1" - ], - "MON-01.14": [ - "2-12-3-2" - ], - "MON-01.15": [ - "2-12-3-2" - ], - "MON-01.16": [ - "2-3-4", - "2-12-1", - "2-12-2", - "2-12-3", - "2-12-4", - "5-1-3-3" - ], - "MON-02.2": [ - "2-12-3-4" - ], - "MON-03.3": [ + "2-12-3-1", "2-12-3-2" ], - "MON-03.6": [ - "2-12-4" - ], - "MON-04": [ - "2-12-3-5" - ], - "MON-07": [ - "2-3-3-4" - ], - "MON-07.1": [ - "2-3-3-4" - ], "MON-08": [ - "2-12-3-5", "2-14-3-3" ], "MON-10": [ @@ -250,11 +211,6 @@ "CRY-01": [ "2-8-1", "2-8-2", - "2-8-3", - "2-8-3-1", - "2-8-4" - ], - "CRY-02": [ "2-8-3-1" ], "CRY-03": [ @@ -263,100 +219,97 @@ "CRY-05": [ "2-8-3-3" ], - "CRY-07": [ - "2-5-3-4" - ], "CRY-09": [ "2-8-3-2" ], "DCH-01": [ - "2-1-6", - "2-3-3", - "2-3-3-2", - "2-3-4", - "2-7-1", - "2-7-2", - "2-7-3", - "2-7-4", - "2-7-3-3" + "2-7-1" ], "DCH-01.1": [ + "2-7-1", "2-7-3-1" ], + "DCH-01.2": [ + "2-7-1" + ], + "DCH-01.4": [ + "2-7-2" + ], "DCH-02": [ "2-1-5", "2-7-3-2", + "2-7-3-3", "4-2-3-1" ], - "DCH-06": [ - "2-3-3-2" + "DCH-04": [ + "2-1-5" ], "DCH-10": [ - "2-3-3-2" - ], - "DCH-12": [ - "2-3-3-2" - ], - "DCH-13": [ - "4-2-3-1" + "5-1-3-5" ], "DCH-13.2": [ + "2-3-3-2", "5-1-3-5" ], - "DCH-24": [ - "4-2-3-1" + "DCH-26": [ + "4-1-3-2", + "4-2-3-3" ], "EMB-01": [ "5-1-1", "5-1-2", - "5-1-3", + "5-1-3-1", + "5-1-3-2", "5-1-4" ], - "END-01": [ - "2-3-4", - "2-4-4" + "EMB-05": [ + "5-1-3-3" + ], + "EMB-09": [ + "5-1-3-3" ], "END-04": [ "2-3-3-1", - "2-4-3-4", "5-1-3-10" ], - "END-04.4": [ + "END-06.8": [ "2-4-3-4" ], "END-08": [ "2-4-3-1" ], "HRS-01": [ + "1-4-2", "1-9-1", - "1-9-6", - "2-6-4" + "1-9-2", + "1-9-3", + "1-9-4", + "1-9-6" ], - "HRS-02": [ - "1-9-2" + "HRS-03": [ + "1-4-1", + "1-4-2", + "1-9-1" ], - "HRS-03.2": [ - "1-9-2" + "HRS-03.1": [ + "1-9-4-1" ], "HRS-04": [ - "1-9-3", "1-9-3-2" ], "HRS-04.1": [ "1-9-3-2" ], "HRS-04.2": [ - "1-9-4", - "1-9-4-1" + "1-9-4-1", + "1-9-4-2" ], "HRS-05": [ - "1-9-3-1", - "1-9-3-2", - "1-9-4-2" + "1-9-1", + "1-9-3-1" ], "HRS-05.1": [ "1-9-3-1", - "1-9-4-2", "2-1-3", "2-1-4", "2-15-3-4" @@ -366,77 +319,60 @@ ], "HRS-05.3": [ "1-9-4-2", - "2-1-3", - "2-6-4", "2-15-3-4" ], "HRS-05.4": [ - "1-9-4-2", - "2-1-3" + "1-9-4-2" ], "HRS-05.5": [ "1-9-4-2" ], - "HRS-06": [ - "1-9-3" + "HRS-05.7": [ + "1-9-4-1", + "1-9-4-2" ], - "HRS-06.1": [ + "HRS-06": [ "1-9-3-1" ], - "HRS-10": [ - "1-9-1" + "HRS-06.1": [ + "1-9-3-1", + "4-1-2-1" ], "IAC-01": [ "2-2-1", - "2-2-2", - "2-2-4" - ], - "IAC-02": [ - "2-2-3" - ], - "IAC-03": [ "2-2-3" ], - "IAC-05": [ - "2-2-3" + "IAC-01.2": [ + "2-2-3-1" ], "IAC-06": [ "2-2-3-2", "2-4-3-2", "2-15-3-5" ], - "IAC-08": [ - "2-2-3-3" - ], - "IAC-09.1": [ - "2-2-3-1" - ], - "IAC-10": [ - "2-2-3-1" + "IAC-07": [ + "1-9-5" ], - "IAC-10.1": [ - "2-2-3-1" + "IAC-08": [ + "2-2-3-3", + "2-6-3-2" ], "IAC-16": [ "2-2-3-4" ], "IAC-17": [ - "1-9-5", "2-2-3-5" ], "IRO-01": [ "2-13-1", "2-13-2", - "2-13-3", - "2-13-3-2", - "2-13-4" + "2-13-3-1" ], - "IRO-02": [ + "IRO-02.4": [ "2-13-3-2" ], "IRO-04": [ - "2-13-3-1", - "2-13-3-2" + "2-13-3-1" ], "IRO-10": [ "2-13-3-3", @@ -446,18 +382,29 @@ "2-13-3-3", "2-13-3-4" ], - "MDM-01": [ - "2-6-3", - "2-6-3-1", - "2-6-3-2", - "2-6-3-3", - "2-6-3-4", - "2-6-4", - "5-1-3-6" + "IAO-01": [ + "1-6-2" ], - "MDM-02": [ - "2-6-3-2", - "5-1-3-6" + "IAO-01.1": [ + "2-11-3-1" + ], + "IAO-02": [ + "1-6-2-1", + "1-6-2-2" + ], + "IAO-02.2": [ + "1-6-2-1", + "1-6-2-2" + ], + "IAO-04": [ + "1-5-3" + ], + "IAO-06": [ + "1-6-3-5" + ], + "MDM-01": [ + "2-6-1", + "2-6-2" ], "MDM-03": [ "2-6-3-1" @@ -472,13 +419,11 @@ "5-1-3-6" ], "NET-01": [ - "2-4-4", "2-5-1", - "2-5-2", - "2-5-4" + "2-5-2" ], "NET-02": [ - "2-5-3-1" + "2-5-3-8" ], "NET-03.7": [ "5-1-3-4" @@ -486,13 +431,13 @@ "NET-04": [ "2-5-3-5" ], - "NET-05.1": [ + "NET-06": [ + "2-5-3-1", + "2-5-3-2", + "5-1-3-1", "5-1-3-2" ], - "NET-05.2": [ - "5-1-3-1" - ], - "NET-06": [ + "NET-06.3": [ "5-1-3-1", "5-1-3-2" ], @@ -500,40 +445,34 @@ "2-5-3-6" ], "NET-10": [ - "2-4-3-5", "2-5-3-7" ], - "NET-18": [ - "2-5-3-3", - "2-5-3-8" + "NET-10.3": [ + "2-4-3-5" ], - "NET-18.1": [ - "2-5-3-8" + "NET-15": [ + "2-5-3-4" + ], + "NET-15.1": [ + "2-5-3-4" + ], + "NET-18": [ + "2-5-3-3" ], "PES-01": [ "2-3-1", "2-3-2", - "2-3-4", "2-14-1", "2-14-2", - "2-14-3", + "2-14-3-1", + "2-14-3-2", + "2-14-3-3", + "2-14-3-5", "2-14-4" ], - "PES-02": [ - "2-14-3-1" - ], - "PES-03": [ - "2-14-3-1" - ], - "PES-03.1": [ - "2-14-3-1" - ], "PES-03.3": [ "2-14-3-3" ], - "PES-03.4": [ - "2-3-3-2" - ], "PES-04": [ "2-14-3-5" ], @@ -546,29 +485,37 @@ "PES-05.1": [ "2-14-3-2" ], - "PRI-06.6": [ - "4-2-3-1" - ], "PRM-01": [ "1-1-3", "1-2-3" ], "PRM-01.1": [ "1-1-1", - "1-1-2" + "1-1-2", + "1-1-3" ], "PRM-02": [ "1-1-3" ], - "PRM-03": [ + "PRM-02.1": [ "1-6-4" ], "PRM-04": [ - "1-6-1", - "1-6-4" + "1-5-2", + "1-6-1" ], "PRM-05": [ - "1-6-1" + "1-6-1", + "2-9-1" + ], + "PRM-06": [ + "2-9-1" + ], + "PRM-07": [ + "1-5-3-1", + "1-5-3-2", + "1-5-3-3", + "1-5-3-4" ], "RSK-01": [ "1-5-1", @@ -578,86 +525,60 @@ "RSK-04": [ "1-5-3" ], - "RSK-07": [ - "1-5-3-2", - "1-5-4" - ], - "RSK-08": [ - "1-5-3-4" - ], - "RSK-09": [ - "1-5-3-3" - ], - "RSK-09.1": [ - "1-5-3-3" - ], - "RSK-10": [ - "1-5-3-4" + "RSK-04.2": [ + "1-5-1", + "1-5-2" ], "SEA-01": [ + "1-6-3-1", "1-6-3-4", - "2-4-3", "2-15-3-3" ], "SEA-02": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" + "1-6-3-4" ], "SEA-03": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" + "2-15-3-2" ], - "SEA-05": [ - "4-2-3-1" + "SEA-20": [ + "2-3-3-4" ], - "SEA-08.1": [ - "1-6-3-2" + "OPS-01.1": [ + "1-3-4" ], "SAT-01": [ "1-10-1", - "1-10-5" + "1-10-2" ], "SAT-02": [ - "1-10-2", - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4" + "1-10-1", + "2-6-3-4" ], "SAT-02.2": [ - "1-10-3" + "1-10-3-1" ], "SAT-03": [ - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4", - "1-10-4", "1-10-4-1", "1-10-4-2", - "1-10-4-3" - ], - "SAT-03.3": [ - "1-10-4-2" + "1-10-4-3", + "1-10-5" ], - "SAT-03.5": [ - "1-10-4-1" + "SAT-03.2": [ + "1-10-3-1" ], - "TDA-01": [ - "1-6-3", - "2-5-4" + "SAT-03.3": [ + "1-10-3-2" ], - "TDA-02.1": [ - "2-5-3-5", - "2-15-3-3" + "SAT-03.6": [ + "1-10-3-3", + "1-10-3-4" ], - "TDA-05": [ + "TDA-01.1": [ "1-6-3-4" ], + "TDA-02.3": [ + "1-6-3-2" + ], "TDA-06": [ "1-6-3-1" ], @@ -665,8 +586,6 @@ "2-5-3-2" ], "TDA-09": [ - "1-5-3-2", - "1-5-3-4", "1-6-3-3" ], "TDA-09.2": [ @@ -681,68 +600,51 @@ "TDA-09.5": [ "1-6-3-3" ], - "TDA-15": [ - "1-5-3-2", - "1-5-3-4" - ], "TPM-01": [ - "1-5-3-3", "4-1-1", - "4-1-2", - "4-1-3", - "4-1-4" + "4-1-3-2" + ], + "TPM-03": [ + "4-1-3-1" ], "TPM-04.1": [ - "1-5-3-4", "4-1-3-1" ], "TPM-05": [ - "4-1-2", "4-1-2-1", "4-1-2-2", "4-1-2-3" ], - "TPM-09": [ + "TPM-05.2": [ "4-1-2-3" ], + "TPM-05.4": [ + "4-1-2-2" + ], "TPM-11": [ "4-1-2-2" ], "THR-01": [ - "2-10-4", "2-13-1", "2-13-2", - "2-13-3", - "2-13-4" + "2-13-3-5" ], "THR-03": [ - "2-10-3-5", "2-13-3-5" ], "VPM-01": [ - "2-3-4", "2-10-1", "2-10-2", - "2-10-3", - "2-10-4", - "2-11-1", - "2-11-2", - "2-11-3", - "2-11-4", "5-1-3-8" ], "VPM-01.1": [ - "2-11-3-1", "5-1-3-8" ], "VPM-02": [ - "2-10-3-3", "5-1-3-8" ], "VPM-03": [ - "2-10-3-2" - ], - "VPM-04": [ + "2-10-3-2", "2-10-3-3" ], "VPM-05": [ @@ -756,126 +658,140 @@ "VPM-06": [ "2-10-3-1" ], - "VPM-06.2": [ - "2-11-3-1" - ], "VPM-07": [ - "2-11-3-1" + "2-11-1", + "2-11-2", + "2-11-3-1", + "2-11-3-2" ], "WEB-01": [ "2-15-1", "2-15-2", "2-15-3", + "2-15-3-2", + "2-15-3-4", + "2-15-3-5", "2-15-4" ], "WEB-03": [ "2-15-3-1" + ], + "WEB-10": [ + "2-15-3-3" ] } }, "framework_to_scf": { - "total_mappings": 215, + "total_mappings": 199, "mappings": { "1-2-1": [ "GOV-01" ], - "1-3-2": [ + "2-1-1": [ "GOV-01", - "CPL-02", - "CPL-03" - ], - "1-3-1": [ "GOV-02" ], - "1-3-3": [ - "GOV-02", - "CFG-02" + "1-1-1": [ + "GOV-01.1", + "GOV-08", + "PRM-01.1" + ], + "1-2-3": [ + "GOV-01.1", + "PRM-01" + ], + "1-4-1": [ + "GOV-01.1", + "GOV-04", + "GOV-04.1", + "GOV-04.2", + "HRS-03" + ], + "1-8-3": [ + "GOV-01.2", + "CPL-02", + "CPL-02.1" ], "1-1-3": [ + "GOV-01.3", "GOV-03", "PRM-01", + "PRM-01.1", "PRM-02" ], "1-3-4": [ - "GOV-03" - ], - "1-6-4": [ + "GOV-01.3", "GOV-03", - "PRM-03", - "PRM-04" + "OPS-01.1" ], - "1-9-6": [ - "GOV-03", - "HRS-01" + "2-3-4": [ + "GOV-01.3" ], - "1-10-5": [ - "GOV-03", - "SAT-01" + "1-3-1": [ + "GOV-02" ], - "2-2-4": [ - "GOV-03", + "1-3-3": [ + "GOV-02", + "CFG-02" + ], + "2-1-2": [ + "GOV-02", + "GOV-15" + ], + "2-1-3": [ + "GOV-02", + "HRS-05.1" + ], + "2-1-4": [ + "GOV-02", + "GOV-15", + "HRS-05.1" + ], + "2-2-1": [ + "GOV-02", "IAC-01" ], - "2-3-4": [ + "2-2-2": [ + "GOV-02", + "GOV-15" + ], + "1-4-2": [ "GOV-03", - "MON-01", - "MON-01.16", - "DCH-01", - "END-01", - "PES-01", - "VPM-01" + "HRS-01", + "HRS-03" + ], + "2-1-6": [ + "GOV-03" ], "2-4-4": [ - "GOV-03", - "BCD-01", - "CFG-01", - "END-01", - "NET-01" + "GOV-03" ], "2-5-4": [ - "GOV-03", - "CFG-01", - "NET-01", - "TDA-01" + "GOV-03" ], "2-6-4": [ - "GOV-03", - "AST-01", - "HRS-01", - "HRS-05.3", - "MDM-01" + "GOV-03" ], "2-7-4": [ - "GOV-03", - "DCH-01" + "GOV-03" ], "2-8-4": [ - "GOV-03", - "CRY-01" + "GOV-03" ], "2-9-4": [ - "GOV-03", - "BCD-01" + "GOV-03" ], "2-10-4": [ - "GOV-03", - "THR-01", - "VPM-01" + "GOV-03" ], "2-11-4": [ - "GOV-03", - "VPM-01" + "GOV-03" ], "2-12-4": [ - "GOV-03", - "MON-01", - "MON-01.16", - "MON-03.6" + "GOV-03" ], "2-13-4": [ - "GOV-03", - "IRO-01", - "THR-01" + "GOV-03" ], "2-14-4": [ "GOV-03", @@ -886,17 +802,13 @@ "WEB-01" ], "3-1-4": [ - "GOV-03", - "BCD-01", - "BCD-06" + "GOV-03" ], "4-1-4": [ - "GOV-03", - "TPM-01" + "GOV-03" ], "4-2-4": [ - "GOV-03", - "CLD-01" + "GOV-03" ], "5-1-4": [ "GOV-03", @@ -905,57 +817,92 @@ "1-2-2": [ "GOV-04" ], - "1-4-1": [ - "GOV-04" - ], - "1-4-2": [ - "GOV-04" + "1-9-2": [ + "GOV-14", + "GOV-15", + "HRS-01" ], - "1-5-2": [ - "GOV-04", - "RSK-01" + "1-3-2": [ + "GOV-15", + "CPL-03" ], - "1-1-1": [ - "GOV-08", - "PRM-01.1" + "1-10-2": [ + "GOV-15", + "SAT-01" ], - "2-1-1": [ - "AST-01" + "2-3-2": [ + "GOV-15", + "PES-01" ], - "2-1-2": [ - "AST-01" + "2-4-2": [ + "GOV-15" ], - "2-6-1": [ - "AST-01", - "AST-16" + "2-5-2": [ + "GOV-15", + "NET-01" ], "2-6-2": [ - "AST-01", - "AST-16" - ], - "2-14-3-4": [ - "AST-09" + "GOV-15", + "MDM-01" ], - "2-9-1": [ - "BCD-01" + "2-8-2": [ + "GOV-15", + "CRY-01" ], "2-9-2": [ + "GOV-15", "BCD-01" ], - "2-9-3": [ - "BCD-01", - "BCD-11" + "2-10-2": [ + "GOV-15", + "VPM-01" ], - "2-9-3-1": [ - "BCD-01" + "2-11-2": [ + "GOV-15", + "VPM-07" ], - "3-1-1": [ - "BCD-01" + "2-12-2": [ + "GOV-15", + "MON-01" + ], + "2-13-2": [ + "GOV-15", + "IRO-01", + "THR-01" + ], + "2-14-2": [ + "GOV-15", + "PES-01" + ], + "2-15-2": [ + "GOV-15", + "WEB-01" ], "3-1-2": [ + "GOV-15", "BCD-01" ], - "3-1-3": [ + "4-2-2": [ + "GOV-15", + "CLD-01" + ], + "5-1-2": [ + "GOV-15", + "EMB-01" + ], + "2-1-5": [ + "AST-04.1", + "DCH-02", + "DCH-04" + ], + "2-14-3-4": [ + "AST-09" + ], + "2-6-1": [ + "AST-16", + "MDM-01" + ], + "3-1-1": [ "BCD-01" ], "3-1-3-1": [ @@ -969,53 +916,46 @@ "3-1-3-3": [ "BCD-01" ], - "2-9-3-2": [ + "2-9-1": [ "BCD-01.4", - "BCD-02", - "BCD-02.1", - "BCD-02.2", - "BCD-02.3" - ], - "2-9-3-3": [ - "BCD-11.1" + "PRM-05", + "PRM-06" ], "2-4-3-3": [ - "BCD-12", - "BCD-12.1" - ], - "1-6-2": [ - "CHG-01" + "BCD-11" ], - "1-6-3-5": [ - "CHG-02", - "CHG-02.2" + "2-9-3-1": [ + "BCD-11" ], - "1-6-2-1": [ - "CHG-02.2" + "2-9-3-2": [ + "BCD-11" ], - "1-6-2-2": [ - "CHG-02.3", - "CFG-01", - "CFG-02.1" + "2-9-3-3": [ + "BCD-11.1" ], "4-2-1": [ "CLD-01" ], - "4-2-2": [ - "CLD-01" - ], - "4-2-3": [ - "CLD-01" + "4-2-3-1": [ + "CLD-01", + "CLD-01.1", + "CLD-01.2", + "DCH-02" ], "4-2-3-2": [ "CLD-01", "CLD-02" ], - "4-1-3-2": [ - "CLD-09" - ], "4-2-3-3": [ - "CLD-09" + "CLD-01", + "CLD-09", + "DCH-26" + ], + "4-1-3-2": [ + "CLD-09", + "CPL-08", + "DCH-26", + "TPM-01" ], "1-7-1": [ "CPL-01" @@ -1024,234 +964,177 @@ "CPL-01" ], "1-8-1": [ - "CPL-02.1", - "CPL-03", - "CPL-03.2" - ], - "1-8-3": [ - "CPL-02.1" + "CPL-02", + "CPL-03" ], "1-8-2": [ + "CPL-03", "CPL-03.1" ], + "2-2-4": [ + "CPL-03" + ], "2-4-1": [ - "CFG-02", - "CFG-04.2" - ], - "2-4-2": [ - "CFG-02" + "CFG-02" ], "5-1-3-7": [ - "CFG-02", + "CFG-02.1", + "CFG-02.2", "CFG-02.5" ], - "2-5-3-5": [ - "CFG-03", - "NET-04", - "TDA-02.1" - ], - "2-5-3-3": [ - "CFG-04.2", - "NET-18" + "5-1-3-5": [ + "CFG-02.5", + "DCH-10", + "DCH-13.2" ], - "2-12-1": [ - "MON-01", - "MON-01.16" + "5-1-3-6": [ + "CFG-02.5", + "MDM-06", + "MDM-07" ], - "2-12-2": [ - "MON-01", - "MON-01.16" + "1-6-3-2": [ + "CFG-09.3", + "TDA-02.3" ], - "2-12-3": [ - "MON-01", - "MON-01.16" + "2-12-1": [ + "MON-01" ], "5-1-3-3": [ "MON-01", "MON-01.2", - "MON-01.16" - ], - "2-5-3-6": [ - "MON-01.1", - "NET-08" + "EMB-05", + "EMB-09" ], "2-12-3-3": [ "MON-01.2" ], - "2-12-3-1": [ - "MON-01.4", - "MON-01.12" - ], "2-12-3-4": [ - "MON-01.8", - "MON-02.2" - ], - "2-12-3-2": [ - "MON-01.14", - "MON-01.15", - "MON-03.3" + "MON-01.2" ], - "2-12-3-5": [ - "MON-04", - "MON-08", - "MON-10" + "2-12-3-1": [ + "MON-01.4" ], - "2-3-3-4": [ - "MON-07", - "MON-07.1" + "2-12-3-2": [ + "MON-01.4" ], "2-14-3-3": [ "MON-08", "MON-10", + "PES-01", "PES-03.3" ], - "2-8-1": [ - "CRY-01" - ], - "2-8-2": [ - "CRY-01" + "2-12-3-5": [ + "MON-10" ], - "2-8-3": [ + "2-8-1": [ "CRY-01" ], "2-8-3-1": [ - "CRY-01", - "CRY-02" + "CRY-01" ], "2-8-3-3": [ "CRY-03", "CRY-05" ], - "2-5-3-4": [ - "CRY-07" - ], "2-8-3-2": [ "CRY-09" ], - "2-1-6": [ - "DCH-01" - ], - "2-3-3": [ - "DCH-01" - ], - "2-3-3-2": [ - "DCH-01", - "DCH-06", - "DCH-10", - "DCH-12", - "PES-03.4" - ], "2-7-1": [ - "DCH-01" - ], - "2-7-2": [ - "DCH-01" - ], - "2-7-3": [ - "DCH-01" - ], - "2-7-3-3": [ - "DCH-01" + "DCH-01", + "DCH-01.1", + "DCH-01.2" ], "2-7-3-1": [ "DCH-01.1" ], - "2-1-5": [ - "DCH-02" + "2-7-2": [ + "DCH-01.4" ], "2-7-3-2": [ "DCH-02" ], - "4-2-3-1": [ - "DCH-02", - "DCH-13", - "DCH-24", - "PRI-06.6", - "SEA-05" + "2-7-3-3": [ + "DCH-02" ], - "5-1-3-5": [ + "2-3-3-2": [ "DCH-13.2" ], "5-1-1": [ "EMB-01" ], - "5-1-2": [ - "EMB-01" + "5-1-3-1": [ + "EMB-01", + "NET-06", + "NET-06.3" ], - "5-1-3": [ - "EMB-01" + "5-1-3-2": [ + "EMB-01", + "NET-06", + "NET-06.3" ], "2-3-3-1": [ "END-04" ], - "2-4-3-4": [ - "END-04", - "END-04.4" - ], "5-1-3-10": [ "END-04" ], + "2-4-3-4": [ + "END-06.8" + ], "2-4-3-1": [ "END-08" ], "1-9-1": [ "HRS-01", - "HRS-10" - ], - "1-9-2": [ - "HRS-02", - "HRS-03.2" + "HRS-03", + "HRS-05" ], "1-9-3": [ - "HRS-04", - "HRS-06" - ], - "1-9-3-2": [ - "HRS-04", - "HRS-04.1", - "HRS-05" + "HRS-01" ], "1-9-4": [ - "HRS-04.2" + "HRS-01" + ], + "1-9-6": [ + "HRS-01" ], "1-9-4-1": [ - "HRS-04.2" + "HRS-03.1", + "HRS-04.2", + "HRS-05.7" ], - "1-9-3-1": [ - "HRS-05", - "HRS-05.1", - "HRS-06.1" + "1-9-3-2": [ + "HRS-04", + "HRS-04.1" ], "1-9-4-2": [ - "HRS-05", - "HRS-05.1", + "HRS-04.2", "HRS-05.2", "HRS-05.3", "HRS-05.4", - "HRS-05.5" + "HRS-05.5", + "HRS-05.7" ], - "2-1-3": [ + "1-9-3-1": [ + "HRS-05", "HRS-05.1", - "HRS-05.3", - "HRS-05.4" - ], - "2-1-4": [ - "HRS-05.1" + "HRS-06", + "HRS-06.1" ], "2-15-3-4": [ "HRS-05.1", - "HRS-05.3" + "HRS-05.3", + "WEB-01" ], - "2-2-1": [ - "IAC-01" + "4-1-2-1": [ + "HRS-06.1", + "TPM-05" ], - "2-2-2": [ + "2-2-3": [ "IAC-01" ], - "2-2-3": [ - "IAC-02", - "IAC-03", - "IAC-05" + "2-2-3-1": [ + "IAC-01.2" ], "2-2-3-2": [ "IAC-06" @@ -1260,22 +1143,21 @@ "IAC-06" ], "2-15-3-5": [ - "IAC-06" + "IAC-06", + "WEB-01" + ], + "1-9-5": [ + "IAC-07" ], "2-2-3-3": [ "IAC-08" ], - "2-2-3-1": [ - "IAC-09.1", - "IAC-10", - "IAC-10.1" + "2-6-3-2": [ + "IAC-08" ], "2-2-3-4": [ "IAC-16" ], - "1-9-5": [ - "IAC-17" - ], "2-2-3-5": [ "IAC-17" ], @@ -1283,21 +1165,12 @@ "IRO-01", "THR-01" ], - "2-13-2": [ - "IRO-01", - "THR-01" - ], - "2-13-3": [ - "IRO-01", - "THR-01" - ], - "2-13-3-2": [ + "2-13-3-1": [ "IRO-01", - "IRO-02", "IRO-04" ], - "2-13-3-1": [ - "IRO-04" + "2-13-3-2": [ + "IRO-02.4" ], "2-13-3-3": [ "IRO-10", @@ -1307,194 +1180,173 @@ "IRO-10", "IRO-10.2" ], - "2-6-3": [ - "MDM-01" + "1-6-2": [ + "IAO-01" + ], + "2-11-3-1": [ + "IAO-01.1", + "VPM-07" + ], + "1-6-2-1": [ + "IAO-02", + "IAO-02.2" + ], + "1-6-2-2": [ + "IAO-02", + "IAO-02.2" + ], + "1-5-3": [ + "IAO-04", + "RSK-04" + ], + "1-6-3-5": [ + "IAO-06" ], "2-6-3-1": [ - "MDM-01", "MDM-03" ], - "2-6-3-2": [ - "MDM-01", - "MDM-02" - ], "2-6-3-3": [ - "MDM-01", "MDM-05" ], - "2-6-3-4": [ - "MDM-01" - ], - "5-1-3-6": [ - "MDM-01", - "MDM-02", - "MDM-06", - "MDM-07" - ], "2-5-1": [ "NET-01" ], - "2-5-2": [ - "NET-01" - ], - "2-5-3-1": [ + "2-5-3-8": [ "NET-02" ], "5-1-3-4": [ "NET-03.7" ], - "5-1-3-2": [ - "NET-05.1", - "NET-06" + "2-5-3-5": [ + "NET-04" ], - "5-1-3-1": [ - "NET-05.2", + "2-5-3-1": [ "NET-06" ], - "2-4-3-5": [ - "NET-10" + "2-5-3-2": [ + "NET-06", + "TDA-08" + ], + "2-5-3-6": [ + "NET-08" ], "2-5-3-7": [ "NET-10" ], - "2-5-3-8": [ - "NET-18", - "NET-18.1" - ], - "2-3-1": [ - "PES-01" + "2-4-3-5": [ + "NET-10.3" ], - "2-3-2": [ - "PES-01" + "2-5-3-4": [ + "NET-15", + "NET-15.1" ], - "2-14-1": [ - "PES-01" + "2-5-3-3": [ + "NET-18" ], - "2-14-2": [ + "2-3-1": [ "PES-01" ], - "2-14-3": [ + "2-14-1": [ "PES-01" ], "2-14-3-1": [ - "PES-02", - "PES-03", - "PES-03.1" - ], - "2-14-3-5": [ - "PES-04", - "PES-04.1" + "PES-01" ], "2-14-3-2": [ + "PES-01", "PES-05", "PES-05.1" ], - "1-2-3": [ - "PRM-01" + "2-14-3-5": [ + "PES-01", + "PES-04", + "PES-04.1" ], "1-1-2": [ "PRM-01.1" ], + "1-6-4": [ + "PRM-02.1" + ], + "1-5-2": [ + "PRM-04", + "RSK-01", + "RSK-04.2" + ], "1-6-1": [ "PRM-04", "PRM-05" ], - "1-5-1": [ - "RSK-01" - ], - "1-5-4": [ - "RSK-01", - "RSK-07" - ], - "1-5-3": [ - "RSK-04" + "1-5-3-1": [ + "PRM-07" ], "1-5-3-2": [ - "RSK-07", - "TDA-09", - "TDA-15" + "PRM-07" + ], + "1-5-3-3": [ + "PRM-07" ], "1-5-3-4": [ - "RSK-08", - "RSK-10", - "TDA-09", - "TDA-15", - "TPM-04.1" + "PRM-07" ], - "1-5-3-3": [ - "RSK-09", - "RSK-09.1", - "TPM-01" + "1-5-1": [ + "RSK-01", + "RSK-04.2" ], - "1-6-3-4": [ + "1-5-4": [ + "RSK-01" + ], + "1-6-3-1": [ "SEA-01", - "SEA-02", - "SEA-03", - "TDA-05" + "TDA-06" ], - "2-4-3": [ + "1-6-3-4": [ "SEA-01", "SEA-02", - "SEA-03" + "TDA-01.1" ], "2-15-3-3": [ "SEA-01", - "SEA-02", + "WEB-10" + ], + "2-15-3-2": [ "SEA-03", - "TDA-02.1" + "WEB-01" ], - "1-6-3-2": [ - "SEA-08.1" + "2-3-3-4": [ + "SEA-20" ], "1-10-1": [ - "SAT-01" - ], - "1-10-2": [ + "SAT-01", "SAT-02" ], - "1-10-3": [ - "SAT-02", - "SAT-02.2", - "SAT-03" + "2-6-3-4": [ + "SAT-02" ], "1-10-3-1": [ - "SAT-02", - "SAT-03" + "SAT-02.2", + "SAT-03.2" ], - "1-10-3-2": [ - "SAT-02", + "1-10-4-1": [ "SAT-03" ], - "1-10-3-3": [ - "SAT-02", + "1-10-4-2": [ "SAT-03" ], - "1-10-3-4": [ - "SAT-02", + "1-10-4-3": [ "SAT-03" ], - "1-10-4": [ + "1-10-5": [ "SAT-03" ], - "1-10-4-1": [ - "SAT-03", - "SAT-03.5" - ], - "1-10-4-2": [ - "SAT-03", + "1-10-3-2": [ "SAT-03.3" ], - "1-10-4-3": [ - "SAT-03" - ], - "1-6-3": [ - "TDA-01" - ], - "1-6-3-1": [ - "TDA-06" + "1-10-3-3": [ + "SAT-03.6" ], - "2-5-3-2": [ - "TDA-08" + "1-10-3-4": [ + "SAT-03.6" ], "1-6-3-3": [ "TDA-09", @@ -1506,67 +1358,35 @@ "4-1-1": [ "TPM-01" ], - "4-1-2": [ - "TPM-01", - "TPM-05" - ], - "4-1-3": [ - "TPM-01" - ], "4-1-3-1": [ + "TPM-03", "TPM-04.1" ], - "4-1-2-1": [ - "TPM-05" - ], "4-1-2-2": [ "TPM-05", + "TPM-05.4", "TPM-11" ], "4-1-2-3": [ "TPM-05", - "TPM-09" - ], - "2-10-3-5": [ - "THR-03", - "VPM-05.4" + "TPM-05.2" ], "2-13-3-5": [ + "THR-01", "THR-03" ], "2-10-1": [ "VPM-01" ], - "2-10-2": [ - "VPM-01" - ], - "2-10-3": [ - "VPM-01" - ], - "2-11-1": [ - "VPM-01" - ], - "2-11-2": [ - "VPM-01" - ], - "2-11-3": [ - "VPM-01" - ], "5-1-3-8": [ "VPM-01", "VPM-01.1", "VPM-02" ], - "2-11-3-1": [ - "VPM-01.1", - "VPM-06.2", - "VPM-07" + "2-10-3-2": [ + "VPM-03" ], "2-10-3-3": [ - "VPM-02", - "VPM-04" - ], - "2-10-3-2": [ "VPM-03" ], "2-3-3-3": [ @@ -1578,13 +1398,19 @@ "5-1-3-9": [ "VPM-05" ], + "2-10-3-5": [ + "VPM-05.4" + ], "2-10-3-1": [ "VPM-06" ], - "2-15-1": [ - "WEB-01" + "2-11-1": [ + "VPM-07" ], - "2-15-2": [ + "2-11-3-2": [ + "VPM-07" + ], + "2-15-1": [ "WEB-01" ], "2-15-3": [ diff --git a/docs/api/crosswalks/emea-sau-otcc-1-2022.json b/docs/api/crosswalks/emea-sau-otcc-1-2022.json index 87e25046..7428af3e 100644 --- a/docs/api/crosswalks/emea-sau-otcc-1-2022.json +++ b/docs/api/crosswalks/emea-sau-otcc-1-2022.json @@ -1,256 +1,193 @@ { "framework_id": "emea-sau-otcc-1-2022", - "display_name": "Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC -1: 2022)", + "display_name": "Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC - 1: 2022)", "scf_to_framework": { - "total_mappings": 198, + "total_mappings": 160, "mappings": { - "GOV-01": [ - "1-1" + "GOV-01.4": [ + "1-1-2" ], "GOV-02": [ - "1-1", - "1-1-1" + "1-1-1", + "1-1-2" ], "GOV-03": [ "1-1-3" ], - "GOV-04": [ - "1-2", - "1-2-1-2" - ], - "GOV-15": [ - "2-3", - "2-3-2" - ], - "GOV-15.1": [ - "2-3", - "2-3-2" - ], - "GOV-15.2": [ - "2-3", - "2-3-2" - ], - "GOV-15.3": [ - "2-3", - "2-3-2" - ], - "GOV-15.4": [ - "2-3", - "2-3-2" + "GOV-05": [ + "1-4-2", + "1-7-2" ], - "GOV-15.5": [ - "2-3", - "2-3-2" + "AAT-30.2": [ + "2-2-1-4" ], "AST-01": [ - "2-1" + "2-1-1", + "2-1-2" ], "AST-01.2": [ "2-1-1-4" ], "AST-02": [ - "2-1", - "2-1-1", - "2-1-1-3" - ], - "AST-02.1": [ "2-1-1-1" ], - "AST-02.2": [ - "2-3-1-11" - ], - "AST-02.8": [ - "2-4-1-16" - ], "AST-02.9": [ - "2-1-1", - "2-1-1-2", - "2-1-1-3" + "2-1-1-2" ], "AST-04": [ "2-4-1-16" ], - "AST-04.2": [ - "2-4-1-16" - ], - "AST-05": [ - "2-6-1-4" + "BCD-01": [ + "2-8-1", + "2-8-2", + "3-1-1" ], - "AST-09": [ - "2-6-1-3" + "BCD-01.1": [ + "2-12-1-1" ], - "AST-30": [ - "2-6-1-3" + "BCD-01.4": [ + "3-1-1-1" ], - "BCD-01": [ - "3-1", - "3-1-1", - "3-1-1-1", - "3-1-1-2", + "BCD-01.7": [ "3-1-1-3", - "3-1-1-4", - "3-1-1-5", - "3-1-1-6", - "3-1-2" + "3-1-1-4" ], "BCD-02": [ "2-1-1-5" ], - "BCD-03.1": [ - "3-1-1-6" + "BCD-02.2": [ + "3-1-1-5" + ], + "BCD-02.3": [ + "3-1-1-5" ], "BCD-04": [ "3-1-1-6" ], "BCD-11": [ - "2-8", - "2-8-1", "2-8-1-1", - "2-8-1-2", - "2-8-1-3", - "2-8-1-4", - "2-8-2" + "2-8-1-3" ], "BCD-11.2": [ - "2-8-1-4" + "2-8-1-2" ], "BCD-11.4": [ "2-8-1-4" ], "BCD-11.6": [ - "2-8-1-4" + "2-8-1-1" ], "BCD-11.7": [ "3-1-1-2" ], - "CHG-01": [ - "1-5", - "1-5-1", - "1-5-2" + "CAP-01": [ + "3-1-1", + "3-1-2" ], - "CHG-02": [ - "1-5", + "CHG-01": [ "1-5-1", "1-5-2", - "1-5-3", - "1-5-3-1" + "1-5-3" ], - "CHG-02.1": [ + "CHG-02": [ + "1-5-3-1", "1-5-3-4" ], "CHG-02.2": [ "1-5-3-2" ], "CHG-02.3": [ - "1-5-2" - ], - "CHG-02.4": [ "1-5-4" ], "CHG-03": [ - "1-5-2", "1-5-4" ], "CHG-04": [ "1-5-3-4" ], "CHG-04.1": [ + "1-5-3-5" + ], + "CHG-06": [ "1-5-4" ], - "CHG-04.3": [ + "CHG-08": [ "2-2-1-6" ], - "CPL-01.1": [ - "1-6", - "1-6-1" - ], - "CPL-02": [ - "1-6", - "1-6-1" - ], "CPL-03": [ - "1-6", + "1-4-2", + "1-5-4", "1-6-1", - "1-6-2" + "1-7-2", + "2-1-2", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-7-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-1-9", + "2-13-2", + "3-1-2", + "4-1-2" ], "CPL-03.1": [ - "1-6-1", "1-6-2" ], "CFG-02": [ - "2-2-1-5", - "2-3-1-1", - "2-3-1-7" + "2-2-1-8", + "2-4-1-4" ], - "CFG-02.1": [ - "2-3-1-2" + "CFG-02.2": [ + "2-3-1-11" ], "CFG-02.5": [ - "2-2-1-5", - "2-3-1-7" + "2-2-1-5" ], "CFG-02.8": [ "2-3-1-11" ], - "CFG-02.9": [ - "2-3-1-7" - ], "CFG-03": [ - "2-2-1-5", - "2-3-1-4" + "2-4-1-14" ], - "CFG-03.2": [ - "2-3-1-11" + "CFG-03.1": [ + "2-3-1-2" ], "CFG-03.3": [ "2-3-1-6" ], - "CFG-05.1": [ - "2-3-1-11" - ], "MON-01": [ - "2-11", "2-11-1", + "2-11-1-10", "2-11-2" ], - "MON-01.7": [ - "1-5-4" - ], - "MON-01.16": [ - "2-11", - "2-11-1", - "2-11-2" + "MON-01.2": [ + "2-11-1-3" ], - "MON-02": [ - "2-11-1-3", - "2-11-1-9" + "MON-01.4": [ + "2-11-1-1" ], - "MON-02.1": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" + "MON-01.8": [ + "2-11-1-4" ], - "MON-02.2": [ - "2-11-1-9", - "2-11-2" + "MON-01.16": [ + "2-11-1-9" ], - "MON-02.3": [ - "2-11-1-4", + "MON-02": [ "2-11-1-5", "2-11-1-6", "2-11-1-7", - "2-11-1-8", - "2-11-1-10" + "2-11-1-8" ], - "MON-02.7": [ - "2-11-1-1", - "2-11-1-2", - "2-11-1-3" + "MON-02.6": [ + "2-11-1-9" ], - "MON-05": [ + "MON-03": [ "2-11-1-2" ], "MON-08": [ @@ -259,168 +196,78 @@ "MON-16": [ "2-3-1-12" ], - "MON-16.3": [ - "2-3-1-11", - "2-3-1-12" - ], "CRY-01": [ - "2-2-1-4", - "2-7", + "2-6-1", "2-7-1", "2-7-2" ], "CRY-03": [ - "2-2-1-4" - ], - "CRY-04": [ - "2-2-1-4" + "2-6-1-1" ], - "CRY-05.1": [ - "2-3-1-8", - "2-3-1-9" + "CRY-05": [ + "2-6-1-1" ], "DCH-01": [ - "2-6", "2-6-1", - "2-6-1-1", "2-6-2" ], "DCH-01.2": [ - "2-6-1-1" - ], - "DCH-02": [ - "2-6-1-1" - ], - "DCH-02.1": [ - "2-6-1-4" - ], - "DCH-03.1": [ - "2-6-1-4" + "2-1-1-3" ], - "DCH-07": [ - "2-6-1-4" + "DCH-12": [ + "2-3-1-9" ], - "DCH-07.1": [ + "DCH-17": [ "2-6-1-4" ], - "DCH-08": [ - "2-6-1-3" - ], - "DCH-09": [ - "2-6-1-3" - ], - "DCH-13.2": [ - "2-3-1-8", - "2-3-1-9" - ], "EMB-01": [ - "1-1-2", - "1-6", - "2-1-2", - "2-3-2" - ], - "EMB-05": [ - "1-5-4" - ], - "EMB-06": [ - "1-5-2", - "1-5-3", - "1-5-4", - "2-3-1-5", - "2-3-1-6" - ], - "EMB-07": [ - "1-5-4", - "2-2-1-4" - ], - "EMB-10": [ - "1-6", - "1-6-1", - "1-6-2", - "2-1-2", - "2-3-2", - "2-7-2", - "2-9-2" - ], - "EMB-13": [ - "2-2-1-4", - "2-2-1-7", - "2-4-1", - "2-4-1-1", - "2-4-1-2", - "2-4-1-3", - "2-4-1-4", - "2-4-1-5", - "2-4-1-6", - "2-4-1-7", - "2-4-1-8", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13", - "2-4-1-14", - "2-4-1-15", - "2-4-1-16" - ], - "EMB-14": [ - "1-5-3-3", - "2-4-1-15" - ], - "EMB-19": [ - "3-1-1-5" - ], - "END-01": [ - "2-5", - "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", - "2-5-1-4", - "2-5-1-5", - "2-5-2" + "1-4-1" ], "END-04": [ + "2-3-1-1", "2-3-1-8" ], - "END-04.7": [ - "2-3-1-8" - ], - "END-06": [ - "1-5-4" + "END-06.8": [ + "2-3-1-1", + "2-3-1-12" ], "HRS-01": [ - "1-7", - "1-7-2", - "1-8" + "1-7-1", + "1-7-2" + ], + "HRS-02": [ + "1-2-1-2" ], "HRS-03": [ - "1-2", "1-2-1", - "1-2-1-1" + "1-2-1-2" ], "HRS-04": [ "1-7-1" ], - "HRS-04.1": [ - "1-7-1" + "HRS-05.5": [ + "2-5-1-1", + "2-5-1-2" ], - "HRS-04.2": [ - "1-8" + "HRS-10": [ + "1-7-1" ], "IAC-01": [ - "2-2", - "2-2-1" + "2-2-1", + "2-2-2" ], - "IAC-07.1": [ - "2-2-1-10" + "IAC-02": [ + "2-2-1-2" ], - "IAC-07.2": [ + "IAC-07": [ "2-2-1-10", "2-2-1-11" ], - "IAC-10": [ - "2-2-1-8" + "IAC-07.1": [ + "2-2-1-11" + ], + "IAC-07.2": [ + "2-2-1-11" ], "IAC-10.1": [ "2-2-1-8" @@ -431,12 +278,6 @@ "IAC-10.11": [ "2-2-1-9" ], - "IAC-15": [ - "2-2-1-10" - ], - "IAC-15.7": [ - "2-2-1-2" - ], "IAC-17": [ "2-2-1-10" ], @@ -446,156 +287,139 @@ "IAC-21": [ "2-3-1-4" ], - "IAC-24": [ - "2-2-1-4" - ], - "IAC-25": [ - "2-2-1-4" - ], "IRO-01": [ - "2-12", "2-12-1", "2-12-2" ], "IRO-02": [ - "2-12-2-1", - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5", - "2-12-2-6", - "2-12-2-7", - "2-12-2-8" - ], - "IRO-03": [ - "2-3-1-12" + "2-12-1-3", + "2-12-1-4" ], "IRO-04": [ - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5" + "2-12-1-1", + "2-12-1-3", + "2-12-1-5" ], "IRO-05": [ - "2-12-2-6" + "2-12-1-6" ], "IRO-06": [ - "2-12-2-7" + "2-12-1-7" + ], + "IRO-07": [ + "2-12-1-4" ], - "IRO-06.1": [ - "2-12-2-8" + "IRO-13": [ + "2-12-1-2" ], "IAO-01": [ - "1-4-1-2" + "1-5-3-3" ], - "IAO-05": [ - "1-3-1-6" + "IAO-02": [ + "1-4-1-2" ], - "MNT-01": [ - "2-13-1-7" + "IAO-02.2": [ + "1-4-1-2", + "1-5-3-3", + "2-10-1-4" ], - "MNT-05": [ - "2-2-1-7" + "IAO-05": [ + "1-3-1-7" ], - "MNT-06": [ - "2-13-1-7" + "IAO-06": [ + "1-4-1-2", + "1-5-3-3" ], - "MNT-06.1": [ - "2-13-1-7" + "IAO-07": [ + "1-4-1-2", + "1-5-3-3" ], "MDM-01": [ - "2-5", "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", "2-5-1-4", - "2-5-1-5", "2-5-2" ], + "MDM-02": [ + "2-5-1-3" + ], + "MDM-03": [ + "2-5-1-5" + ], + "MDM-05": [ + "2-6-1-3" + ], + "MDM-06": [ + "2-5-1-3" + ], "MDM-07": [ - "2-5-1-4" + "2-5-1-1", + "2-5-1-3" ], "NET-01": [ - "2-3", - "2-3-1", - "2-3-1-1", - "2-4", "2-4-1", - "2-4-2", - "2-5-2" - ], - "NET-02": [ - "2-3-1-1" - ], - "NET-02.3": [ - "2-4-1-2" + "2-4-2" ], "NET-03": [ - "2-3-1-1", - "2-4-1-2", - "2-4-1-6" - ], - "NET-03.8": [ - "2-4-1-2" + "2-3-1-13", + "2-4-1-12" ], "NET-04": [ - "2-4-1-6", - "2-4-1-7", - "2-4-1-8", - "2-4-1-10", - "2-4-1-14", - "2-4-1-16" - ], - "NET-04.1": [ "2-4-1-6", "2-4-1-8", - "2-4-1-14" - ], - "NET-05.1": [ - "2-3-1-13" - ], - "NET-05.2": [ - "2-3-1-13" + "2-4-1-9", + "2-4-1-10" ], "NET-06": [ "2-4-1-1", "2-4-1-2", - "2-4-1-3", - "2-4-1-5", - "2-4-1-10" + "2-4-1-5" ], "NET-06.3": [ - "2-4-1-1" + "2-4-1-2", + "2-4-1-3" ], - "NET-06.4": [ - "2-2-1-1", - "2-4-1-3", + "NET-06.5": [ + "2-4-1-7" + ], + "NET-06.9": [ + "2-4-1-1", + "2-4-1-5", + "2-4-1-6", "2-4-1-9", "2-4-1-10", - "2-4-1-11", "2-4-1-12", "2-4-1-13" ], - "NET-06.5": [ - "2-3-1-13", - "2-4-1-7" + "NET-08": [ + "2-3-1-12", + "2-3-1-13" ], "NET-14": [ + "2-2-1-7", + "2-4-1-10" + ], + "NET-14.1": [ + "2-2-1-7" + ], + "NET-14.2": [ "2-2-1-7" ], + "NET-14.3": [ + "2-4-1-7" + ], "NET-15": [ - "2-4-1-4", - "2-4-1-5" + "2-4-1-4" ], "NET-17": [ "2-6-1-2" ], + "NET-18.1": [ + "2-4-1-11" + ], "PES-01": [ - "2-13", + "2-3-1", + "2-3-2", "2-13-1", - "2-13-1-8", - "2-13-1-9", "2-13-2" ], "PES-02": [ @@ -604,147 +428,105 @@ "PES-03": [ "2-13-1-3" ], - "PES-03.1": [ - "2-13-1-3" - ], - "PES-03.2": [ - "2-13-1-4" - ], "PES-03.4": [ "2-13-1-5" ], "PES-04": [ "2-13-1-4" ], - "PES-04.1": [ - "2-13-1-5" + "PES-05": [ + "2-13-1-2" ], "PES-05.1": [ "2-13-1-2" ], + "PES-05.2": [ + "2-13-1-7" + ], "PES-06": [ "2-13-1-6" ], - "PES-06.3": [ - "2-13-1-7" + "PRM-01": [ + "1-4-2" ], "PRM-02": [ - "1-4", - "1-4-1", - "1-4-1-1" + "1-4-2" ], - "PRM-04": [ - "1-4-1-2" + "PRM-02.1": [ + "1-4-2" ], - "PRM-05": [ - "1-4-1", - "1-4-1-1", + "PRM-03": [ "1-4-2" ], - "RSK-01": [ - "1-3", - "1-3-1", - "1-3-1-1" + "PRM-04": [ + "1-4-1-1", + "1-4-1-3" ], - "RSK-01.1": [ - "1-3-1-4", - "1-3-1-5" + "PRM-05": [ + "1-4-1-1" ], - "RSK-02": [ - "1-3-1-4", - "1-3-1-5" + "PRM-07": [ + "1-4-1-1" ], - "RSK-02.1": [ - "1-3-1-4", - "1-3-1-5" + "RSK-01": [ + "1-3-1" ], "RSK-04": [ - "1-3-1-2" + "1-3-1-2", + "1-3-1-4", + "1-3-1-5" ], "RSK-04.1": [ - "1-3-1-3", - "1-3-1-6" + "1-3-1-3" + ], + "RSK-04.2": [ + "1-3-1-1" ], "RSK-06.2": [ "1-3-1-6", "1-3-1-7" ], + "RSK-06.3": [ + "1-3-1-6" + ], + "RSK-06.4": [ + "1-3-1-6" + ], "SEA-01": [ - "1-1-2" + "1-4-1-3" ], - "SEA-02": [ - "1-1-2" + "SEA-01.2": [ + "3-1-1-1" ], - "SEA-03": [ - "1-1-2" + "SEA-07.1": [ + "2-2-1-1" ], "SAT-01": [ - "1-8" + "1-8-1" ], "SAT-02": [ - "1-8" + "1-8-2" ], "SAT-03": [ - "1-8-1", - "1-8-2", - "1-8-3" - ], - "SAT-03.2": [ - "1-8-1", - "1-8-2", - "1-8-3", - "2-3-1-12" - ], - "SAT-03.5": [ - "1-8-1", - "1-8-2", - "1-8-3" + "1-8-2-1", + "2-13-1-8" ], "SAT-03.6": [ - "1-8-1", - "1-8-2", - "1-8-3" - ], - "TDA-01": [ - "1-1-2" - ], - "TDA-01.1": [ - "1-1-2", - "4-1-1-1" + "1-8-2-2", + "2-13-1-8" ], - "TDA-04": [ - "1-1-2" + "SAT-03.7": [ + "1-8-2-1" ], "TDA-07": [ "1-4-1-4" ], - "TDA-08": [ - "1-4-1-4" - ], - "TDA-09": [ - "1-4-1-2" - ], - "TDA-09.6": [ - "1-4-1-3" - ], "TPM-01": [ - "4-1", "4-1-1", - "4-1-1-1", - "4-1-1-2", - "4-1-1-3", - "4-1-1-4", "4-1-2" ], - "TPM-02": [ - "4-1-1-2" - ], - "TPM-04": [ - "4-1-1-3" - ], "TPM-04.1": [ - "4-1-1-2", - "4-1-1-4" + "4-1-1-2" ], "TPM-05": [ "4-1-1-1", @@ -756,62 +538,49 @@ "TPM-08": [ "4-1-1-4" ], - "THR-02": [ - "2-12-2-8" + "THR-01": [ + "2-12-1-8" ], "THR-03": [ - "1-8-3", - "2-12-2-8" + "2-12-1-8" ], "VPM-01": [ - "2-9", "2-9-1", - "2-9-2" + "2-9-2", + "2-10-1", + "2-10-2" ], "VPM-01.1": [ - "2-9-1-1" + "2-9-1-1", + "2-10-1-1" ], "VPM-02": [ "2-9-1-2" ], - "VPM-03": [ - "2-9-1-2", - "2-9-1-3" - ], - "VPM-04": [ - "2-9-1-2", - "2-9-1-3" - ], "VPM-05": [ "2-3-1-3", "2-4-1-15" ], - "VPM-05.4": [ - "2-3-1-3" + "VPM-05.8": [ + "2-4-1-15" + ], + "VPM-06": [ + "2-9-1-3" ], "VPM-07": [ - "2-10", - "2-10-1", - "2-10-1-1", "2-10-1-2", - "2-10-1-3", - "2-10-1-4", - "2-10-2" - ], - "VPM-10": [ - "2-13-1-9" + "2-10-1-3" ], "WEB-02": [ - "2-4-1-10", "2-4-1-13" ] } }, "framework_to_scf": { - "total_mappings": 189, + "total_mappings": 168, "mappings": { - "1-1": [ - "GOV-01", + "1-1-2": [ + "GOV-01.4", "GOV-02" ], "1-1-1": [ @@ -820,778 +589,581 @@ "1-1-3": [ "GOV-03" ], - "1-2": [ - "GOV-04", - "HRS-03" + "1-4-2": [ + "GOV-05", + "CPL-03", + "PRM-01", + "PRM-02", + "PRM-02.1", + "PRM-03" ], - "1-2-1-2": [ - "GOV-04" - ], - "2-3": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "NET-01" + "1-7-2": [ + "GOV-05", + "CPL-03", + "HRS-01" ], - "2-3-2": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "EMB-01", - "EMB-10" - ], - "2-1": [ + "2-2-1-4": [ + "AAT-30.2" + ], + "2-1-1": [ + "AST-01" + ], + "2-1-2": [ "AST-01", - "AST-02" + "CPL-03" ], "2-1-1-4": [ "AST-01.2" ], - "2-1-1": [ - "AST-02", - "AST-02.9" - ], - "2-1-1-3": [ - "AST-02", - "AST-02.9" - ], "2-1-1-1": [ - "AST-02.1" - ], - "2-3-1-11": [ - "AST-02.2", - "CFG-02.8", - "CFG-03.2", - "CFG-05.1", - "MON-16.3" - ], - "2-4-1-16": [ - "AST-02.8", - "AST-04", - "AST-04.2", - "EMB-13", - "NET-04" + "AST-02" ], "2-1-1-2": [ "AST-02.9" ], - "2-6-1-4": [ - "AST-05", - "DCH-02.1", - "DCH-03.1", - "DCH-07", - "DCH-07.1" - ], - "2-6-1-3": [ - "AST-09", - "AST-30", - "DCH-08", - "DCH-09" + "2-4-1-16": [ + "AST-04" ], - "3-1": [ + "2-8-1": [ "BCD-01" ], + "2-8-2": [ + "BCD-01", + "CPL-03" + ], "3-1-1": [ - "BCD-01" + "BCD-01", + "CAP-01" ], - "3-1-1-1": [ - "BCD-01" + "2-12-1-1": [ + "BCD-01.1", + "IRO-04" ], - "3-1-1-2": [ - "BCD-01", - "BCD-11.7" + "3-1-1-1": [ + "BCD-01.4", + "SEA-01.2" ], "3-1-1-3": [ - "BCD-01" + "BCD-01.7" ], "3-1-1-4": [ - "BCD-01" - ], - "3-1-1-5": [ - "BCD-01", - "EMB-19" - ], - "3-1-1-6": [ - "BCD-01", - "BCD-03.1", - "BCD-04" - ], - "3-1-2": [ - "BCD-01" + "BCD-01.7" ], "2-1-1-5": [ "BCD-02" ], - "2-8": [ - "BCD-11" + "3-1-1-5": [ + "BCD-02.2", + "BCD-02.3" ], - "2-8-1": [ - "BCD-11" + "3-1-1-6": [ + "BCD-04" ], "2-8-1-1": [ - "BCD-11" - ], - "2-8-1-2": [ - "BCD-11" + "BCD-11", + "BCD-11.6" ], "2-8-1-3": [ "BCD-11" ], + "2-8-1-2": [ + "BCD-11.2" + ], "2-8-1-4": [ - "BCD-11", - "BCD-11.2", - "BCD-11.4", - "BCD-11.6" + "BCD-11.4" ], - "2-8-2": [ - "BCD-11" + "3-1-1-2": [ + "BCD-11.7" ], - "1-5": [ - "CHG-01", - "CHG-02" + "3-1-2": [ + "CAP-01", + "CPL-03" ], "1-5-1": [ - "CHG-01", - "CHG-02" + "CHG-01" ], "1-5-2": [ - "CHG-01", - "CHG-02", - "CHG-02.3", - "CHG-03", - "EMB-06" + "CHG-01" ], "1-5-3": [ - "CHG-02", - "EMB-06" + "CHG-01" ], "1-5-3-1": [ "CHG-02" ], "1-5-3-4": [ - "CHG-02.1", + "CHG-02", "CHG-04" ], "1-5-3-2": [ "CHG-02.2" ], "1-5-4": [ - "CHG-02.4", + "CHG-02.3", "CHG-03", - "CHG-04.1", - "MON-01.7", - "EMB-05", - "EMB-06", - "EMB-07", - "END-06" + "CHG-06", + "CPL-03" + ], + "1-5-3-5": [ + "CHG-04.1" ], "2-2-1-6": [ - "CHG-04.3" + "CHG-08" + ], + "1-6-1": [ + "CPL-03" ], - "1-6": [ - "CPL-01.1", - "CPL-02", + "2-2-2": [ "CPL-03", - "EMB-01", - "EMB-10" + "IAC-01" ], - "1-6-1": [ - "CPL-01.1", - "CPL-02", + "2-3-2": [ "CPL-03", - "CPL-03.1", - "EMB-10" + "PES-01" ], - "1-6-2": [ + "2-4-2": [ "CPL-03", - "CPL-03.1", - "EMB-10" + "NET-01" ], - "2-2-1-5": [ - "CFG-02", - "CFG-02.5", - "CFG-03" + "2-5-2": [ + "CPL-03", + "MDM-01" ], - "2-3-1-1": [ + "2-6-2": [ + "CPL-03", + "DCH-01" + ], + "2-7-2": [ + "CPL-03", + "CRY-01" + ], + "2-9-2": [ + "CPL-03", + "VPM-01" + ], + "2-10-2": [ + "CPL-03", + "VPM-01" + ], + "2-11-2": [ + "CPL-03", + "MON-01" + ], + "2-12-2": [ + "CPL-03", + "IRO-01" + ], + "2-13-1-9": [ + "CPL-03" + ], + "2-13-2": [ + "CPL-03", + "PES-01" + ], + "4-1-2": [ + "CPL-03", + "TPM-01" + ], + "1-6-2": [ + "CPL-03.1" + ], + "2-2-1-8": [ "CFG-02", - "NET-01", - "NET-02", - "NET-03" + "IAC-10.1" ], - "2-3-1-7": [ + "2-4-1-4": [ "CFG-02", - "CFG-02.5", - "CFG-02.9", - "IAC-20.4" + "NET-15" ], - "2-3-1-2": [ - "CFG-02.1" + "2-3-1-11": [ + "CFG-02.2", + "CFG-02.8" ], - "2-3-1-4": [ - "CFG-03", - "IAC-21" + "2-2-1-5": [ + "CFG-02.5" ], - "2-3-1-6": [ - "CFG-03.3", - "EMB-06" + "2-4-1-14": [ + "CFG-03" ], - "2-11": [ - "MON-01", - "MON-01.16" + "2-3-1-2": [ + "CFG-03.1" + ], + "2-3-1-6": [ + "CFG-03.3" ], "2-11-1": [ - "MON-01", - "MON-01.16" + "MON-01" ], - "2-11-2": [ - "MON-01", - "MON-01.16", - "MON-02.2" + "2-11-1-10": [ + "MON-01" ], "2-11-1-3": [ - "MON-02", - "MON-02.7" + "MON-01.2" ], - "2-11-1-9": [ - "MON-02", - "MON-02.2" + "2-11-1-1": [ + "MON-01.4" ], "2-11-1-4": [ - "MON-02.1", - "MON-02.3" + "MON-01.8" + ], + "2-11-1-9": [ + "MON-01.16", + "MON-02.6" ], "2-11-1-5": [ - "MON-02.1", - "MON-02.3" + "MON-02" ], "2-11-1-6": [ - "MON-02.1", - "MON-02.3" + "MON-02" ], "2-11-1-7": [ - "MON-02.1", - "MON-02.3" + "MON-02" ], "2-11-1-8": [ - "MON-02.1", - "MON-02.3" - ], - "2-11-1-10": [ - "MON-02.1", - "MON-02.3" - ], - "2-11-1-1": [ - "MON-02.7" + "MON-02" ], "2-11-1-2": [ - "MON-02.7", - "MON-05" + "MON-03" ], "2-3-1-10": [ "MON-08" ], "2-3-1-12": [ "MON-16", - "MON-16.3", - "IRO-03", - "SAT-03.2" + "END-06.8", + "NET-08" ], - "2-2-1-4": [ + "2-6-1": [ "CRY-01", - "CRY-03", - "CRY-04", - "EMB-07", - "EMB-13", - "IAC-24", - "IAC-25" - ], - "2-7": [ - "CRY-01" + "DCH-01" ], "2-7-1": [ "CRY-01" ], - "2-7-2": [ - "CRY-01", - "EMB-10" + "2-6-1-1": [ + "CRY-03", + "CRY-05" ], - "2-3-1-8": [ - "CRY-05.1", - "DCH-13.2", - "END-04", - "END-04.7" + "2-1-1-3": [ + "DCH-01.2" ], "2-3-1-9": [ - "CRY-05.1", - "DCH-13.2" + "DCH-12" ], - "2-6": [ - "DCH-01" + "2-6-1-4": [ + "DCH-17" ], - "2-6-1": [ - "DCH-01" - ], - "2-6-1-1": [ - "DCH-01", - "DCH-01.2", - "DCH-02" - ], - "2-6-2": [ - "DCH-01" - ], - "1-1-2": [ - "EMB-01", - "SEA-01", - "SEA-02", - "SEA-03", - "TDA-01", - "TDA-01.1", - "TDA-04" - ], - "2-1-2": [ - "EMB-01", - "EMB-10" - ], - "2-3-1-5": [ - "EMB-06" - ], - "2-9-2": [ - "EMB-10", - "VPM-01" - ], - "2-2-1-7": [ - "EMB-13", - "MNT-05", - "NET-14" - ], - "2-4-1": [ - "EMB-13", - "NET-01" - ], - "2-4-1-1": [ - "EMB-13", - "NET-06", - "NET-06.3" - ], - "2-4-1-2": [ - "EMB-13", - "NET-02.3", - "NET-03", - "NET-03.8", - "NET-06" - ], - "2-4-1-3": [ - "EMB-13", - "NET-06", - "NET-06.4" - ], - "2-4-1-4": [ - "EMB-13", - "NET-15" - ], - "2-4-1-5": [ - "EMB-13", - "NET-06", - "NET-15" - ], - "2-4-1-6": [ - "EMB-13", - "NET-03", - "NET-04", - "NET-04.1" - ], - "2-4-1-7": [ - "EMB-13", - "NET-04", - "NET-06.5" - ], - "2-4-1-8": [ - "EMB-13", - "NET-04", - "NET-04.1" - ], - "2-4-1-9": [ - "EMB-13", - "NET-06.4" - ], - "2-4-1-10": [ - "EMB-13", - "NET-04", - "NET-06", - "NET-06.4", - "WEB-02" - ], - "2-4-1-11": [ - "EMB-13", - "NET-06.4" - ], - "2-4-1-12": [ - "EMB-13", - "NET-06.4" - ], - "2-4-1-13": [ - "EMB-13", - "NET-06.4", - "WEB-02" - ], - "2-4-1-14": [ - "EMB-13", - "NET-04", - "NET-04.1" - ], - "2-4-1-15": [ - "EMB-13", - "EMB-14", - "VPM-05" - ], - "1-5-3-3": [ - "EMB-14" - ], - "2-5": [ - "END-01", - "MDM-01" - ], - "2-5-1": [ - "END-01", - "MDM-01" - ], - "2-5-1-1": [ - "END-01", - "MDM-01" - ], - "2-5-1-2": [ - "END-01", - "MDM-01" - ], - "2-5-1-3": [ - "END-01", - "MDM-01" - ], - "2-5-1-4": [ - "END-01", - "MDM-01", - "MDM-07" - ], - "2-5-1-5": [ - "END-01", - "MDM-01" - ], - "2-5-2": [ - "END-01", - "MDM-01", - "NET-01" + "1-4-1": [ + "EMB-01" ], - "1-7": [ - "HRS-01" + "2-3-1-1": [ + "END-04", + "END-06.8" ], - "1-7-2": [ - "HRS-01" + "2-3-1-8": [ + "END-04" ], - "1-8": [ + "1-7-1": [ "HRS-01", - "HRS-04.2", - "SAT-01", - "SAT-02" + "HRS-04", + "HRS-10" ], - "1-2-1": [ + "1-2-1-2": [ + "HRS-02", "HRS-03" ], - "1-2-1-1": [ - "HRS-03", - "TPM-05.4" + "1-2-1": [ + "HRS-03" ], - "1-7-1": [ - "HRS-04", - "HRS-04.1" + "2-5-1-1": [ + "HRS-05.5", + "MDM-07" ], - "2-2": [ - "IAC-01" + "2-5-1-2": [ + "HRS-05.5" ], "2-2-1": [ "IAC-01" ], + "2-2-1-2": [ + "IAC-02" + ], "2-2-1-10": [ - "IAC-07.1", - "IAC-07.2", - "IAC-15", + "IAC-07", "IAC-17" ], "2-2-1-11": [ + "IAC-07", + "IAC-07.1", "IAC-07.2" ], - "2-2-1-8": [ - "IAC-10", - "IAC-10.1" - ], "2-2-1-3": [ "IAC-10.8" ], "2-2-1-9": [ "IAC-10.11" ], - "2-2-1-2": [ - "IAC-15.7" + "2-3-1-7": [ + "IAC-20.4" ], - "2-12": [ - "IRO-01" + "2-3-1-4": [ + "IAC-21" ], "2-12-1": [ "IRO-01" ], - "2-12-2": [ - "IRO-01" - ], - "2-12-2-1": [ - "IRO-02" - ], - "2-12-2-2": [ + "2-12-1-3": [ "IRO-02", "IRO-04" ], - "2-12-2-3": [ + "2-12-1-4": [ "IRO-02", - "IRO-04" + "IRO-07" ], - "2-12-2-4": [ - "IRO-02", + "2-12-1-5": [ "IRO-04" ], - "2-12-2-5": [ - "IRO-02", - "IRO-04" - ], - "2-12-2-6": [ - "IRO-02", + "2-12-1-6": [ "IRO-05" ], - "2-12-2-7": [ - "IRO-02", + "2-12-1-7": [ "IRO-06" ], - "2-12-2-8": [ - "IRO-02", - "IRO-06.1", - "THR-02", - "THR-03" + "2-12-1-2": [ + "IRO-13" ], - "1-4-1-2": [ + "1-5-3-3": [ "IAO-01", - "PRM-04", - "TDA-09" + "IAO-02.2", + "IAO-06", + "IAO-07" ], - "1-3-1-6": [ + "1-4-1-2": [ + "IAO-02", + "IAO-02.2", + "IAO-06", + "IAO-07" + ], + "2-10-1-4": [ + "IAO-02.2" + ], + "1-3-1-7": [ "IAO-05", - "RSK-04.1", "RSK-06.2" ], - "2-13-1-7": [ - "MNT-01", - "MNT-06", - "MNT-06.1", - "PES-06.3" + "2-5-1": [ + "MDM-01" ], - "2-3-1": [ - "NET-01" + "2-5-1-4": [ + "MDM-01" ], - "2-4": [ - "NET-01" + "2-5-1-3": [ + "MDM-02", + "MDM-06", + "MDM-07" ], - "2-4-2": [ + "2-5-1-5": [ + "MDM-03" + ], + "2-6-1-3": [ + "MDM-05" + ], + "2-4-1": [ "NET-01" ], "2-3-1-13": [ - "NET-05.1", - "NET-05.2", - "NET-06.5" + "NET-03", + "NET-08" ], - "2-2-1-1": [ - "NET-06.4" + "2-4-1-12": [ + "NET-03", + "NET-06.9" + ], + "2-4-1-6": [ + "NET-04", + "NET-06.9" + ], + "2-4-1-8": [ + "NET-04" + ], + "2-4-1-9": [ + "NET-04", + "NET-06.9" + ], + "2-4-1-10": [ + "NET-04", + "NET-06.9", + "NET-14" + ], + "2-4-1-1": [ + "NET-06", + "NET-06.9" + ], + "2-4-1-2": [ + "NET-06", + "NET-06.3" + ], + "2-4-1-5": [ + "NET-06", + "NET-06.9" + ], + "2-4-1-3": [ + "NET-06.3" + ], + "2-4-1-7": [ + "NET-06.5", + "NET-14.3" + ], + "2-4-1-13": [ + "NET-06.9", + "WEB-02" + ], + "2-2-1-7": [ + "NET-14", + "NET-14.1", + "NET-14.2" ], "2-6-1-2": [ "NET-17" ], - "2-13": [ - "PES-01" - ], - "2-13-1": [ - "PES-01" + "2-4-1-11": [ + "NET-18.1" ], - "2-13-1-8": [ + "2-3-1": [ "PES-01" ], - "2-13-1-9": [ - "PES-01", - "VPM-10" - ], - "2-13-2": [ + "2-13-1": [ "PES-01" ], "2-13-1-1": [ "PES-02" ], "2-13-1-3": [ - "PES-03", - "PES-03.1" + "PES-03" + ], + "2-13-1-5": [ + "PES-03.4" ], "2-13-1-4": [ - "PES-03.2", "PES-04" ], - "2-13-1-5": [ - "PES-03.4", - "PES-04.1" - ], "2-13-1-2": [ + "PES-05", "PES-05.1" ], + "2-13-1-7": [ + "PES-05.2" + ], "2-13-1-6": [ "PES-06" ], - "1-4": [ - "PRM-02" - ], - "1-4-1": [ - "PRM-02", - "PRM-05" - ], "1-4-1-1": [ - "PRM-02", - "PRM-05" - ], - "1-4-2": [ - "PRM-05" + "PRM-04", + "PRM-05", + "PRM-07" ], - "1-3": [ - "RSK-01" + "1-4-1-3": [ + "PRM-04", + "SEA-01" ], "1-3-1": [ "RSK-01" ], - "1-3-1-1": [ - "RSK-01" + "1-3-1-2": [ + "RSK-04" ], "1-3-1-4": [ - "RSK-01.1", - "RSK-02", - "RSK-02.1" + "RSK-04" ], "1-3-1-5": [ - "RSK-01.1", - "RSK-02", - "RSK-02.1" - ], - "1-3-1-2": [ "RSK-04" ], "1-3-1-3": [ "RSK-04.1" ], - "1-3-1-7": [ - "RSK-06.2" + "1-3-1-1": [ + "RSK-04.2" + ], + "1-3-1-6": [ + "RSK-06.2", + "RSK-06.3", + "RSK-06.4" + ], + "2-2-1-1": [ + "SEA-07.1" ], "1-8-1": [ - "SAT-03", - "SAT-03.2", - "SAT-03.5", - "SAT-03.6" + "SAT-01" ], "1-8-2": [ + "SAT-02" + ], + "1-8-2-1": [ "SAT-03", - "SAT-03.2", - "SAT-03.5", - "SAT-03.6" + "SAT-03.7" ], - "1-8-3": [ + "2-13-1-8": [ "SAT-03", - "SAT-03.2", - "SAT-03.5", - "SAT-03.6", - "THR-03" + "SAT-03.6" ], - "4-1-1-1": [ - "TDA-01.1", - "TPM-01", - "TPM-05" + "1-8-2-2": [ + "SAT-03.6" ], "1-4-1-4": [ - "TDA-07", - "TDA-08" - ], - "1-4-1-3": [ - "TDA-09.6" - ], - "4-1": [ - "TPM-01" + "TDA-07" ], "4-1-1": [ "TPM-01" ], "4-1-1-2": [ - "TPM-01", - "TPM-02", "TPM-04.1" ], + "4-1-1-1": [ + "TPM-05" + ], "4-1-1-3": [ - "TPM-01", - "TPM-04", "TPM-05" ], + "1-2-1-1": [ + "TPM-05.4" + ], "4-1-1-4": [ - "TPM-01", - "TPM-04.1", "TPM-08" ], - "4-1-2": [ - "TPM-01" + "2-12-1-8": [ + "THR-01", + "THR-03" ], - "2-9": [ + "2-9-1": [ "VPM-01" ], - "2-9-1": [ + "2-10-1": [ "VPM-01" ], "2-9-1-1": [ "VPM-01.1" ], - "2-9-1-2": [ - "VPM-02", - "VPM-03", - "VPM-04" + "2-10-1-1": [ + "VPM-01.1" ], - "2-9-1-3": [ - "VPM-03", - "VPM-04" + "2-9-1-2": [ + "VPM-02" ], "2-3-1-3": [ - "VPM-05", - "VPM-05.4" - ], - "2-10": [ - "VPM-07" + "VPM-05" ], - "2-10-1": [ - "VPM-07" + "2-4-1-15": [ + "VPM-05", + "VPM-05.8" ], - "2-10-1-1": [ - "VPM-07" + "2-9-1-3": [ + "VPM-06" ], "2-10-1-2": [ "VPM-07" ], "2-10-1-3": [ "VPM-07" - ], - "2-10-1-4": [ - "VPM-07" - ], - "2-10-2": [ - "VPM-07" ] } } diff --git a/docs/api/crosswalks/emea-sau-sacs-002-2022.json b/docs/api/crosswalks/emea-sau-sacs-002-2022.json index 67f31084..a85daadb 100644 --- a/docs/api/crosswalks/emea-sau-sacs-002-2022.json +++ b/docs/api/crosswalks/emea-sau-sacs-002-2022.json @@ -1,1110 +1,782 @@ { "framework_id": "emea-sau-sacs-002-2022", - "display_name": "Saudi Arabia - SACS-002 Third Party Cybersecurity Standard (2022)", + "display_name": "Saudi Arabia - SACS - 002 Third Party Cybersecurity Standard (2022)", "scf_to_framework": { - "total_mappings": 185, + "total_mappings": 101, "mappings": { - "GOV-01": [ - "TPC-25" + "GOV-01.3": [ + "VII.B.TPC-69" ], "GOV-02": [ - "TPC-25" + "VII.B.TPC-24", + "VII.B.TPC-25" ], "AST-09": [ - "TPC-19", - "TPC-66" - ], - "AST-12": [ - "TPC-84" - ], - "AST-13": [ - "TPC-84" - ], - "AST-19": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17" - ], - "AST-27": [ - "TPC-41" + "VII.A.TPC-19", + "VII.B.TPC-66" ], "BCD-01": [ - "TPC-67", - "TPC-68", - "TPC-69" - ], - "BCD-02": [ - "TPC-24" + "VII.B.TPC-64" + ], + "BCD-01.7": [ + "VII.B.TPC-67", + "VII.B.TPC-68", + "VII.B.TPC-68(a)", + "VII.B.TPC-68(b)", + "VII.B.TPC-68(c)", + "VII.B.TPC-68(d)", + "VII.B.TPC-68(e)", + "VII.B.TPC-68(f)", + "VII.B.TPC-68(g)", + "VII.B.TPC-68(h)", + "VII.B.TPC-68(i)", + "VII.B.TPC-69" ], "BCD-04": [ - "TPC-70" + "VII.B.TPC-70" ], "BCD-11": [ - "TPC-64" + "VII.B.TPC-64" ], "BCD-11.2": [ - "TPC-38" + "VII.B.TPC-65" ], "BCD-11.4": [ - "TPC-65" - ], - "BCD-11.9": [ - "TPC-50" - ], - "BCD-12.2": [ - "TPC-43" - ], - "CHG-02": [ - "TPC-73" - ], - "CHG-02.1": [ - "TPC-73" - ], - "CHG-02.2": [ - "TPC-73" - ], - "CLD-01": [ - "TPC-43" - ], - "CLD-01.1": [ - "TPC-43" - ], - "CLD-09": [ - "TPC-30" + "VII.B.TPC-50", + "VII.B.TPC-65" ], - "CPL-01": [ - "TPC-20", - "TPC-21", - "TPC-43" - ], - "CPL-03.1": [ - "TPC-20", - "TPC-21" - ], - "CFG-01": [ - "TPC-2" + "CAP-02": [ + "VII.B.TPC-92" ], "CFG-02": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" - ], - "CFG-02.5": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" - ], - "MON-01": [ - "TPC-40", - "TPC-80" - ], - "MON-01.3": [ - "TPC-40" - ], - "MON-01.4": [ - "TPC-80", - "TPC-87" - ], - "MON-01.8": [ - "TPC-40" + "VII.A.TPC-2", + "VII.A.TPC-2-BP1", + "VII.A.TPC-2-BP2", + "VII.A.TPC-2-BP3", + "VII.A.TPC-2-BP4", + "VII.A.TPC-2-BP5", + "VII.A.TPC-10", + "VII.B.TPC-56", + "VII.B.TPC-62", + "VII.B.TPC-63", + "VII.B.TPC-63-BP1", + "VII.B.TPC-63-BP2", + "VII.B.TPC-63-BP3", + "VII.B.TPC-63-BP4" ], "MON-01.15": [ - "TPC-83" - ], - "MON-01.16": [ - "TPC-40", - "TPC-80" - ], - "MON-02": [ - "TPC-81" + "VII.B.TPC-83" ], "MON-02.1": [ - "TPC-81" + "VII.B.TPC-81" ], - "MON-02.2": [ - "TPC-81" + "MON-03": [ + "VII.B.TPC-87" ], "MON-10": [ - "TPC-75" + "VII.B.TPC-75" + ], + "MON-11.3": [ + "VII.B.TPC-80" ], "MON-16": [ - "TPC-80" + "VII.B.TPC-80" ], "CRY-01": [ - "TPC-52", - "TPC-54" + "VII.B.TPC-54" ], "CRY-03": [ - "TPC-52", - "TPC-53" + "VII.B.TPC-52", + "VII.B.TPC-53" ], "CRY-07": [ - "TPC-42" + "VII.B.TPC-42" ], "CRY-09": [ - "TPC-55" - ], - "DCH-01": [ - "TPC-24", - "TPC-39", - "TPC-58" - ], - "DCH-01.1": [ - "TPC-39", - "TPC-58" + "VII.B.TPC-55" ], "DCH-01.2": [ - "TPC-24", - "TPC-39", - "TPC-58" + "VII.B.TPC-39", + "VII.B.TPC-58" ], - "DCH-02": [ - "TPC-24" - ], - "DCH-02.1": [ - "TPC-24" - ], - "DCH-03": [ - "TPC-39" + "DCH-01.4": [ + "VII.B.TPC-39" ], - "DCH-03.1": [ - "TPC-39" + "DCH-02": [ + "VII.B.TPC-24" ], "DCH-09": [ - "TPC-19", - "TPC-66" - ], - "DCH-19": [ - "TPC-30" - ], - "DCH-25": [ - "TPC-30" + "VII.A.TPC-19", + "VII.B.TPC-66" ], - "END-01": [ - "TPC-12", - "TPC-22" + "DCH-13": [ + "VII.B.TPC-36" ], - "END-02": [ - "TPC-22" + "DCH-18": [ + "VII.A.TPC-19" ], "END-04": [ - "TPC-12" + "VII.A.TPC-12" + ], + "END-05": [ + "VII.A.TPC-22" ], "END-08": [ - "TPC-16" + "VII.A.TPC-16" ], "HRS-01": [ - "TPC-6", - "TPC-71" + "VII.B.TPC-26" ], - "HRS-02": [ - "TPC-26" + "HRS-01.1": [ + "VII.A.TPC-18", + "VII.B.TPC-71" ], "HRS-03": [ - "TPC-26" + "VII.B.TPC-26" ], "HRS-03.2": [ - "TPC-26" - ], - "HRS-04.1": [ - "TPC-26" - ], - "HRS-04.2": [ - "TPC-26", - "TPC-71" + "VII.B.TPC-26" ], "HRS-05": [ - "TPC-26" + "VII.A.TPC-1" ], "HRS-05.1": [ - "TPC-1", - "TPC-8", - "TPC-9" + "VII.A.TPC-1" ], "HRS-05.3": [ - "TPC-8", - "TPC-9" - ], - "HRS-05.7": [ - "TPC-26", - "TPC-71" + "VII.A.TPC-8" ], - "HRS-06": [ - "TPC-9", - "TPC-71" + "HRS-05.5": [ + "VII.B.TPC-84" ], "HRS-06.1": [ - "TPC-9", - "TPC-71" - ], - "HRS-08": [ - "TPC-18" - ], - "HRS-09": [ - "TPC-6", - "TPC-18" - ], - "HRS-09.1": [ - "TPC-18" - ], - "HRS-09.2": [ - "TPC-6", - "TPC-18" - ], - "HRS-09.3": [ - "TPC-18" + "VII.A.TPC-9" ], "HRS-09.4": [ - "TPC-6" - ], - "IAC-01": [ - "TPC-10" + "VII.A.TPC-6" ], "IAC-02": [ - "TPC-32" + "VII.B.TPC-32" ], - "IAC-06": [ - "TPC-4", - "TPC-5", - "TPC-37", - "TPC-44", - "TPC-45" - ], - "IAC-06.1": [ - "TPC-5", - "TPC-37" + "IAC-03": [ + "VII.B.TPC-32" ], - "IAC-06.2": [ - "TPC-5", - "TPC-45" + "IAC-06": [ + "VII.A.TPC-4", + "VII.A.TPC-5", + "VII.B.TPC-37", + "VII.B.TPC-44", + "VII.B.TPC-45" ], - "IAC-06.3": [ - "TPC-37" + "IAC-07": [ + "VII.A.TPC-6" ], "IAC-08": [ - "TPC-39" + "VII.B.TPC-34" ], "IAC-10": [ - "TPC-3" + "VII.B.TPC-62" ], "IAC-10.1": [ - "TPC-2" + "VII.A.TPC-2" ], "IAC-10.5": [ - "TPC-3" + "VII.A.TPC-3" ], - "IAC-10.6": [ - "TPC-62" - ], - "IAC-10.11": [ - "TPC-3" - ], - "IAC-16": [ - "TPC-34" - ], - "IAC-16.1": [ - "TPC-34" + "IAC-15": [ + "VII.B.TPC-32" ], "IAC-17": [ - "TPC-33", - "TPC-34" + "VII.B.TPC-33" ], - "IAC-24": [ - "TPC-2" - ], - "IAC-24.1": [ - "TPC-2" + "IAC-21": [ + "VII.B.TPC-34" ], "IRO-01": [ - "TPC-23", - "TPC-88", - "TPC-89" + "VII.A.TPC-23" ], "IRO-02": [ - "TPC-23", - "TPC-88", - "TPC-89" - ], - "IRO-04": [ - "TPC-23", - "TPC-88" + "VII.B.TPC-89" ], - "IRO-05": [ - "TPC-88" + "IRO-03": [ + "VII.B.TPC-80" ], - "IRO-07": [ - "TPC-89" - ], - "IRO-08": [ - "TPC-89" + "IRO-04": [ + "VII.A.TPC-23-BP2", + "VII.B.TPC-88" ], "IRO-09": [ - "TPC-89", - "TPC-90" + "VII.B.TPC-90" ], "IRO-10": [ - "TPC-23", - "TPC-89" - ], - "IRO-10.2": [ - "TPC-23", - "TPC-89" + "VII.A.TPC-23-BP1" ], "IRO-13": [ - "TPC-89" - ], - "IAO-01": [ - "TPC-51" - ], - "IAO-03.2": [ - "TPC-25" - ], - "IAO-07": [ - "TPC-51" + "VII.B.TPC-89" ], - "MNT-01": [ - "TPC-78" + "IAO-02.2": [ + "VII.B.TPC-72" ], - "MNT-02": [ - "TPC-78" + "IAO-04": [ + "VII.B.TPC-72" ], - "MNT-05": [ - "TPC-35" + "IAO-06": [ + "VII.B.TPC-72", + "VII.B.TPC-73" ], - "MDM-02": [ - "TPC-84" + "IAO-07": [ + "VII.B.TPC-72", + "VII.B.TPC-73" ], "MDM-05": [ - "TPC-59" + "VII.B.TPC-59" ], "MDM-06": [ - "TPC-84" - ], - "MDM-11": [ - "TPC-84" - ], - "NET-01": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-78" - ], - "NET-02.1": [ - "TPC-92" + "VII.B.TPC-84" ], "NET-03": [ - "TPC-76" - ], - "NET-03.6": [ - "TPC-38" - ], - "NET-03.8": [ - "TPC-38", - "TPC-40" - ], - "NET-04.1": [ - "TPC-36" + "VII.B.TPC-76" ], "NET-05.1": [ - "TPC-36" + "VII.B.TPC-36" ], "NET-06": [ - "TPC-38", - "TPC-40" + "VII.B.TPC-40" ], "NET-06.3": [ - "TPC-38", - "TPC-40" - ], - "NET-06.5": [ - "TPC-41" + "VII.B.TPC-38" ], "NET-08": [ - "TPC-77" - ], - "NET-08.1": [ - "TPC-41" - ], - "NET-08.2": [ - "TPC-77" + "VII.B.TPC-77" ], "NET-10.3": [ - "TPC-13", - "TPC-14", - "TPC-15" - ], - "NET-14": [ - "TPC-35" + "VII.A.TPC-13", + "VII.A.TPC-14", + "VII.A.TPC-15" ], "NET-14.4": [ - "TPC-35" + "VII.B.TPC-35" ], - "NET-14.6": [ - "TPC-35" + "NET-15.1": [ + "VII.B.TPC-42" ], "NET-18": [ - "TPC-57" - ], - "PES-01": [ - "TPC-46" + "VII.B.TPC-57", + "VII.B.TPC-57-BP1", + "VII.B.TPC-57-BP2", + "VII.B.TPC-57-BP3" ], "PES-02": [ - "TPC-86" + "VII.B.TPC-86" ], "PES-02.1": [ - "TPC-86" + "VII.B.TPC-86" ], "PES-03": [ - "TPC-47", - "TPC-82", - "TPC-86" - ], - "PES-03.1": [ - "TPC-82" + "VII.B.TPC-82" ], "PES-03.2": [ - "TPC-46" + "VII.B.TPC-46" ], "PES-03.4": [ - "TPC-46", - "TPC-49" - ], - "PES-04": [ - "TPC-46" + "VII.B.TPC-46" ], "PES-04.1": [ - "TPC-49" + "VII.B.TPC-49" ], "PES-06": [ - "TPC-47" - ], - "PES-06.1": [ - "TPC-47" + "VII.B.TPC-47", + "VII.B.TPC-47-BP2", + "VII.B.TPC-47-BP3" ], "PES-06.2": [ - "TPC-47" + "VII.B.TPC-47-BP1" ], "PES-06.3": [ - "TPC-48" - ], - "PES-06.6": [ - "TPC-47" + "VII.B.TPC-48" ], "PES-18": [ - "TPC-38" - ], - "PRI-07.1": [ - "TPC-25" - ], - "PRM-04": [ - "TPC-74" - ], - "PRM-05": [ - "TPC-43" - ], - "PRM-07": [ - "TPC-74" - ], - "RSK-01": [ - "TPC-31" - ], - "RSK-03": [ - "TPC-31" + "VII.B.TPC-38", + "VII.B.TPC-49" ], "RSK-04": [ - "TPC-31" - ], - "RSK-04.1": [ - "TPC-31" - ], - "RSK-05": [ - "TPC-31" - ], - "RSK-06": [ - "TPC-31" - ], - "RSK-06.1": [ - "TPC-31" - ], - "RSK-06.2": [ - "TPC-31" - ], - "RSK-07": [ - "TPC-31" - ], - "SEA-01": [ - "TPC-43" - ], - "SEA-02": [ - "TPC-43" - ], - "SEA-03": [ - "TPC-43" - ], - "SAT-01": [ - "TPC-7" + "VII.B.TPC-31" ], "SAT-02": [ - "TPC-7" + "VII.A.TPC-7", + "VII.A.TPC-7.1", + "VII.A.TPC-7.2", + "VII.A.TPC-7.4", + "VII.A.TPC-7.5", + "VII.A.TPC-8", + "VII.A.TPC-9" ], - "SAT-03": [ - "TPC-7" + "SAT-02.2": [ + "VII.A.TPC-7.3" ], "TDA-06": [ - "TPC-60", - "TPC-62" - ], - "TDA-07": [ - "TPC-73" - ], - "TDA-08": [ - "TPC-73" - ], - "TDA-09": [ - "TPC-72" - ], - "TDA-09.2": [ - "TPC-72" - ], - "TDA-09.3": [ - "TPC-72" - ], - "TDA-09.4": [ - "TPC-72" + "VII.B.TPC-74" ], - "TDA-09.5": [ - "TPC-72" + "TDA-17": [ + "VII.B.TPC-51" ], "TDA-18": [ - "TPC-60" + "VII.B.TPC-60" ], "TDA-19": [ - "TPC-61" + "VII.B.TPC-61" ], - "TPM-05": [ - "TPC-25" + "TDA-19.1": [ + "VII.B.TPC-61" ], - "TPM-05.2": [ - "TPC-25" + "TPM-04": [ + "VII.B.TPC-36" ], - "VPM-01": [ - "TPC-11" + "TPM-05": [ + "VII.A.TPC-17", + "VII.A.TPC-23-BP2" ], - "VPM-01.1": [ - "TPC-27", - "TPC-28", - "TPC-29" + "TPM-05.8": [ + "VII.A.TPC-20", + "VII.A.TPC-21" ], "VPM-02": [ - "TPC-11", - "TPC-91" + "VII.B.TPC-91", + "VII.B.TPC-91-BP1", + "VII.B.TPC-91-BP2", + "VII.B.TPC-91-BP3" ], "VPM-05": [ - "TPC-11", - "TPC-78" - ], - "VPM-05.1": [ - "TPC-91" - ], - "VPM-05.3": [ - "TPC-91" - ], - "VPM-05.4": [ - "TPC-78" + "VII.A.TPC-11" ], "VPM-06": [ - "TPC-85" + "VII.B.TPC-85" + ], + "VPM-06.1": [ + "VII.B.TPC-78" ], "VPM-07": [ - "TPC-27", - "TPC-28", - "TPC-29" + "VII.B.TPC-27", + "VII.B.TPC-28", + "VII.B.TPC-29" ], "WEB-02": [ - "TPC-41" + "VII.B.TPC-41" ], "WEB-03": [ - "TPC-79" + "VII.B.TPC-79" ] } }, "framework_to_scf": { - "total_mappings": 92, + "total_mappings": 124, "mappings": { - "TPC-25": [ - "GOV-01", + "VII.B.TPC-69": [ + "GOV-01.3", + "BCD-01.7" + ], + "VII.B.TPC-24": [ "GOV-02", - "IAO-03.2", - "PRI-07.1", - "TPM-05", - "TPM-05.2" + "DCH-02" + ], + "VII.B.TPC-25": [ + "GOV-02" ], - "TPC-19": [ + "VII.A.TPC-19": [ "AST-09", - "DCH-09" + "DCH-09", + "DCH-18" ], - "TPC-66": [ + "VII.B.TPC-66": [ "AST-09", "DCH-09" ], - "TPC-84": [ - "AST-12", - "AST-13", - "MDM-02", - "MDM-06", - "MDM-11" + "VII.B.TPC-64": [ + "BCD-01", + "BCD-11" ], - "TPC-13": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "NET-01", - "NET-10.3" + "VII.B.TPC-67": [ + "BCD-01.7" ], - "TPC-14": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "NET-01", - "NET-10.3" + "VII.B.TPC-68": [ + "BCD-01.7" ], - "TPC-15": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "NET-01", - "NET-10.3" + "VII.B.TPC-68(a)": [ + "BCD-01.7" ], - "TPC-16": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "END-08", - "NET-01" + "VII.B.TPC-68(b)": [ + "BCD-01.7" ], - "TPC-17": [ - "AST-19", - "CFG-02", - "CFG-02.5", - "NET-01" + "VII.B.TPC-68(c)": [ + "BCD-01.7" ], - "TPC-41": [ - "AST-27", - "NET-06.5", - "NET-08.1", - "WEB-02" + "VII.B.TPC-68(d)": [ + "BCD-01.7" ], - "TPC-67": [ - "BCD-01" + "VII.B.TPC-68(e)": [ + "BCD-01.7" ], - "TPC-68": [ - "BCD-01" + "VII.B.TPC-68(f)": [ + "BCD-01.7" ], - "TPC-69": [ - "BCD-01" + "VII.B.TPC-68(g)": [ + "BCD-01.7" ], - "TPC-24": [ - "BCD-02", - "DCH-01", - "DCH-01.2", - "DCH-02", - "DCH-02.1" + "VII.B.TPC-68(h)": [ + "BCD-01.7" ], - "TPC-70": [ - "BCD-04" + "VII.B.TPC-68(i)": [ + "BCD-01.7" ], - "TPC-64": [ - "BCD-11" + "VII.B.TPC-70": [ + "BCD-04" ], - "TPC-38": [ + "VII.B.TPC-65": [ "BCD-11.2", - "CFG-02", - "CFG-02.5", - "NET-03.6", - "NET-03.8", - "NET-06", - "NET-06.3", - "PES-18" + "BCD-11.4" ], - "TPC-65": [ + "VII.B.TPC-50": [ "BCD-11.4" ], - "TPC-50": [ - "BCD-11.9" - ], - "TPC-43": [ - "BCD-12.2", - "CLD-01", - "CLD-01.1", - "CPL-01", - "PRM-05", - "SEA-01", - "SEA-02", - "SEA-03" - ], - "TPC-73": [ - "CHG-02", - "CHG-02.1", - "CHG-02.2", - "TDA-07", - "TDA-08" - ], - "TPC-30": [ - "CLD-09", - "DCH-19", - "DCH-25" - ], - "TPC-20": [ - "CPL-01", - "CPL-03.1" - ], - "TPC-21": [ - "CPL-01", - "CPL-03.1" - ], - "TPC-2": [ - "CFG-01", - "IAC-10.1", - "IAC-24", - "IAC-24.1" - ], - "TPC-10": [ - "CFG-02", - "CFG-02.5", - "IAC-01" + "VII.B.TPC-92": [ + "CAP-02" ], - "TPC-22": [ + "VII.A.TPC-2": [ "CFG-02", - "CFG-02.5", - "END-01", - "END-02" + "IAC-10.1" ], - "TPC-56": [ - "CFG-02", - "CFG-02.5" + "VII.A.TPC-2-BP1": [ + "CFG-02" ], - "TPC-63": [ - "CFG-02", - "CFG-02.5" + "VII.A.TPC-2-BP2": [ + "CFG-02" + ], + "VII.A.TPC-2-BP3": [ + "CFG-02" + ], + "VII.A.TPC-2-BP4": [ + "CFG-02" ], - "TPC-87": [ + "VII.A.TPC-2-BP5": [ + "CFG-02" + ], + "VII.A.TPC-10": [ + "CFG-02" + ], + "VII.B.TPC-56": [ + "CFG-02" + ], + "VII.B.TPC-62": [ "CFG-02", - "CFG-02.5", - "MON-01.4" - ], - "TPC-40": [ - "MON-01", - "MON-01.3", - "MON-01.8", - "MON-01.16", - "NET-03.8", - "NET-06", - "NET-06.3" - ], - "TPC-80": [ - "MON-01", - "MON-01.4", - "MON-01.16", - "MON-16" - ], - "TPC-83": [ + "IAC-10" + ], + "VII.B.TPC-63": [ + "CFG-02" + ], + "VII.B.TPC-63-BP1": [ + "CFG-02" + ], + "VII.B.TPC-63-BP2": [ + "CFG-02" + ], + "VII.B.TPC-63-BP3": [ + "CFG-02" + ], + "VII.B.TPC-63-BP4": [ + "CFG-02" + ], + "VII.B.TPC-83": [ "MON-01.15" ], - "TPC-81": [ - "MON-02", - "MON-02.1", - "MON-02.2" + "VII.B.TPC-81": [ + "MON-02.1" + ], + "VII.B.TPC-87": [ + "MON-03" ], - "TPC-75": [ + "VII.B.TPC-75": [ "MON-10" ], - "TPC-52": [ - "CRY-01", - "CRY-03" + "VII.B.TPC-80": [ + "MON-11.3", + "MON-16", + "IRO-03" ], - "TPC-54": [ + "VII.B.TPC-54": [ "CRY-01" ], - "TPC-53": [ + "VII.B.TPC-52": [ + "CRY-03" + ], + "VII.B.TPC-53": [ "CRY-03" ], - "TPC-42": [ - "CRY-07" + "VII.B.TPC-42": [ + "CRY-07", + "NET-15.1" ], - "TPC-55": [ + "VII.B.TPC-55": [ "CRY-09" ], - "TPC-39": [ - "DCH-01", - "DCH-01.1", + "VII.B.TPC-39": [ "DCH-01.2", - "DCH-03", - "DCH-03.1", - "IAC-08" + "DCH-01.4" ], - "TPC-58": [ - "DCH-01", - "DCH-01.1", + "VII.B.TPC-58": [ "DCH-01.2" ], - "TPC-12": [ - "END-01", + "VII.B.TPC-36": [ + "DCH-13", + "NET-05.1", + "TPM-04" + ], + "VII.A.TPC-12": [ "END-04" ], - "TPC-6": [ - "HRS-01", - "HRS-09", - "HRS-09.2", - "HRS-09.4" + "VII.A.TPC-22": [ + "END-05" ], - "TPC-71": [ - "HRS-01", - "HRS-04.2", - "HRS-05.7", - "HRS-06", - "HRS-06.1" + "VII.A.TPC-16": [ + "END-08" ], - "TPC-26": [ - "HRS-02", + "VII.B.TPC-26": [ + "HRS-01", "HRS-03", - "HRS-03.2", - "HRS-04.1", - "HRS-04.2", - "HRS-05", - "HRS-05.7" + "HRS-03.2" ], - "TPC-1": [ - "HRS-05.1" + "VII.A.TPC-18": [ + "HRS-01.1" ], - "TPC-8": [ - "HRS-05.1", - "HRS-05.3" + "VII.B.TPC-71": [ + "HRS-01.1" ], - "TPC-9": [ - "HRS-05.1", + "VII.A.TPC-1": [ + "HRS-05", + "HRS-05.1" + ], + "VII.A.TPC-8": [ "HRS-05.3", - "HRS-06", - "HRS-06.1" + "SAT-02" ], - "TPC-18": [ - "HRS-08", - "HRS-09", - "HRS-09.1", - "HRS-09.2", - "HRS-09.3" + "VII.B.TPC-84": [ + "HRS-05.5", + "MDM-06" ], - "TPC-32": [ - "IAC-02" + "VII.A.TPC-9": [ + "HRS-06.1", + "SAT-02" ], - "TPC-4": [ + "VII.A.TPC-6": [ + "HRS-09.4", + "IAC-07" + ], + "VII.B.TPC-32": [ + "IAC-02", + "IAC-03", + "IAC-15" + ], + "VII.A.TPC-4": [ "IAC-06" ], - "TPC-5": [ - "IAC-06", - "IAC-06.1", - "IAC-06.2" + "VII.A.TPC-5": [ + "IAC-06" ], - "TPC-37": [ - "IAC-06", - "IAC-06.1", - "IAC-06.3" + "VII.B.TPC-37": [ + "IAC-06" ], - "TPC-44": [ + "VII.B.TPC-44": [ "IAC-06" ], - "TPC-45": [ - "IAC-06", - "IAC-06.2" + "VII.B.TPC-45": [ + "IAC-06" ], - "TPC-3": [ - "IAC-10", - "IAC-10.5", - "IAC-10.11" + "VII.B.TPC-34": [ + "IAC-08", + "IAC-21" ], - "TPC-62": [ - "IAC-10.6", - "TDA-06" + "VII.A.TPC-3": [ + "IAC-10.5" ], - "TPC-34": [ - "IAC-16", - "IAC-16.1", + "VII.B.TPC-33": [ "IAC-17" ], - "TPC-33": [ - "IAC-17" + "VII.A.TPC-23": [ + "IRO-01" ], - "TPC-23": [ - "IRO-01", + "VII.B.TPC-89": [ "IRO-02", - "IRO-04", - "IRO-10", - "IRO-10.2" + "IRO-13" ], - "TPC-88": [ - "IRO-01", - "IRO-02", + "VII.A.TPC-23-BP2": [ "IRO-04", - "IRO-05" + "TPM-05" ], - "TPC-89": [ - "IRO-01", - "IRO-02", - "IRO-07", - "IRO-08", - "IRO-09", - "IRO-10", - "IRO-10.2", - "IRO-13" + "VII.B.TPC-88": [ + "IRO-04" ], - "TPC-90": [ + "VII.B.TPC-90": [ "IRO-09" ], - "TPC-51": [ - "IAO-01", - "IAO-07" + "VII.A.TPC-23-BP1": [ + "IRO-10" ], - "TPC-78": [ - "MNT-01", - "MNT-02", - "NET-01", - "VPM-05", - "VPM-05.4" + "VII.B.TPC-72": [ + "IAO-02.2", + "IAO-04", + "IAO-06", + "IAO-07" ], - "TPC-35": [ - "MNT-05", - "NET-14", - "NET-14.4", - "NET-14.6" + "VII.B.TPC-73": [ + "IAO-06", + "IAO-07" ], - "TPC-59": [ + "VII.B.TPC-59": [ "MDM-05" ], - "TPC-92": [ - "NET-02.1" - ], - "TPC-76": [ + "VII.B.TPC-76": [ "NET-03" ], - "TPC-36": [ - "NET-04.1", - "NET-05.1" + "VII.B.TPC-40": [ + "NET-06" + ], + "VII.B.TPC-38": [ + "NET-06.3", + "PES-18" + ], + "VII.B.TPC-77": [ + "NET-08" + ], + "VII.A.TPC-13": [ + "NET-10.3" + ], + "VII.A.TPC-14": [ + "NET-10.3" + ], + "VII.A.TPC-15": [ + "NET-10.3" ], - "TPC-77": [ - "NET-08", - "NET-08.2" + "VII.B.TPC-35": [ + "NET-14.4" ], - "TPC-57": [ + "VII.B.TPC-57": [ "NET-18" ], - "TPC-46": [ - "PES-01", - "PES-03.2", - "PES-03.4", - "PES-04" + "VII.B.TPC-57-BP1": [ + "NET-18" ], - "TPC-86": [ + "VII.B.TPC-57-BP2": [ + "NET-18" + ], + "VII.B.TPC-57-BP3": [ + "NET-18" + ], + "VII.B.TPC-86": [ "PES-02", - "PES-02.1", + "PES-02.1" + ], + "VII.B.TPC-82": [ "PES-03" ], - "TPC-47": [ - "PES-03", - "PES-06", - "PES-06.1", - "PES-06.2", - "PES-06.6" + "VII.B.TPC-46": [ + "PES-03.2", + "PES-03.4" ], - "TPC-82": [ - "PES-03", - "PES-03.1" + "VII.B.TPC-49": [ + "PES-04.1", + "PES-18" ], - "TPC-49": [ - "PES-03.4", - "PES-04.1" + "VII.B.TPC-47": [ + "PES-06" ], - "TPC-48": [ + "VII.B.TPC-47-BP2": [ + "PES-06" + ], + "VII.B.TPC-47-BP3": [ + "PES-06" + ], + "VII.B.TPC-47-BP1": [ + "PES-06.2" + ], + "VII.B.TPC-48": [ "PES-06.3" ], - "TPC-74": [ - "PRM-04", - "PRM-07" - ], - "TPC-31": [ - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-06.2", - "RSK-07" - ], - "TPC-7": [ - "SAT-01", - "SAT-02", - "SAT-03" - ], - "TPC-60": [ - "TDA-06", + "VII.B.TPC-31": [ + "RSK-04" + ], + "VII.A.TPC-7": [ + "SAT-02" + ], + "VII.A.TPC-7.1": [ + "SAT-02" + ], + "VII.A.TPC-7.2": [ + "SAT-02" + ], + "VII.A.TPC-7.4": [ + "SAT-02" + ], + "VII.A.TPC-7.5": [ + "SAT-02" + ], + "VII.A.TPC-7.3": [ + "SAT-02.2" + ], + "VII.B.TPC-74": [ + "TDA-06" + ], + "VII.B.TPC-51": [ + "TDA-17" + ], + "VII.B.TPC-60": [ "TDA-18" ], - "TPC-72": [ - "TDA-09", - "TDA-09.2", - "TDA-09.3", - "TDA-09.4", - "TDA-09.5" + "VII.B.TPC-61": [ + "TDA-19", + "TDA-19.1" ], - "TPC-61": [ - "TDA-19" + "VII.A.TPC-17": [ + "TPM-05" ], - "TPC-11": [ - "VPM-01", - "VPM-02", + "VII.A.TPC-20": [ + "TPM-05.8" + ], + "VII.A.TPC-21": [ + "TPM-05.8" + ], + "VII.B.TPC-91": [ + "VPM-02" + ], + "VII.B.TPC-91-BP1": [ + "VPM-02" + ], + "VII.B.TPC-91-BP2": [ + "VPM-02" + ], + "VII.B.TPC-91-BP3": [ + "VPM-02" + ], + "VII.A.TPC-11": [ "VPM-05" ], - "TPC-27": [ - "VPM-01.1", - "VPM-07" + "VII.B.TPC-85": [ + "VPM-06" + ], + "VII.B.TPC-78": [ + "VPM-06.1" ], - "TPC-28": [ - "VPM-01.1", + "VII.B.TPC-27": [ "VPM-07" ], - "TPC-29": [ - "VPM-01.1", + "VII.B.TPC-28": [ "VPM-07" ], - "TPC-91": [ - "VPM-02", - "VPM-05.1", - "VPM-05.3" + "VII.B.TPC-29": [ + "VPM-07" ], - "TPC-85": [ - "VPM-06" + "VII.B.TPC-41": [ + "WEB-02" ], - "TPC-79": [ + "VII.B.TPC-79": [ "WEB-03" ] } diff --git a/docs/api/crosswalks/emea-sau-sama-csf-1-2017.json b/docs/api/crosswalks/emea-sau-sama-csf-1-2017.json index b11b21bb..3247031c 100644 --- a/docs/api/crosswalks/emea-sau-sama-csf-1-2017.json +++ b/docs/api/crosswalks/emea-sau-sama-csf-1-2017.json @@ -1,318 +1,2156 @@ { "framework_id": "emea-sau-sama-csf-1-2017", - "display_name": "Saudi Arabia - SAMA CSF Version 1.0 (2017)", + "display_name": "Saudi Arabia - Saudi Arabian Monetary Authority (SAMA) Cyber Security Framework Version 1.0 (2017)", "scf_to_framework": { - "total_mappings": 50, + "total_mappings": 91, "mappings": { "GOV-01": [ "3.1.1" ], "GOV-01.1": [ - "3.1.1" + "3.1.1.1", + "3.1.1.2", + "3.1.1.3", + "3.1.1.3.a", + "3.1.1.3.b", + "3.1.1.3.c", + "3.1.1.4", + "3.1.1.4.a", + "3.1.1.4.b", + "3.1.1.4.c", + "3.1.1.4.d", + "3.1.1.5", + "3.1.1.6", + "3.1.1.7", + "3.1.1.8", + "3.1.1.9", + "3.1.1.9.a", + "3.1.1.9.b", + "3.1.1.9.c" + ], + "GOV-01.4": [ + "3.2.3", + "3.2.3.1", + "3.2.3.1.a", + "3.2.3.1.b", + "3.2.3.1.c" ], "GOV-02": [ - "3.1.3" + "3.1.3", + "3.1.3.1", + "3.1.3.3", + "3.1.3.3.a", + "3.1.3.3.b", + "3.1.3.3.c", + "3.1.3.3.d", + "3.1.3.4", + "3.1.3.4.a", + "3.1.3.4.b", + "3.1.3.4.c", + "3.1.3.4.d", + "3.1.3.4.e", + "3.1.3.4.f", + "3.1.3.4.f.1", + "3.1.3.4.f.2", + "3.1.3.4.f.3", + "3.1.3.4.f.4", + "3.1.3.4.f.5", + "3.1.3.4.f.6", + "3.1.3.4.f.7", + "3.1.3.4.f.8", + "3.3.5.1", + "3.3.5.4", + "3.3.5.4.a", + "3.3.5.4.b", + "3.3.5.4.b.1", + "3.3.5.4.b.2", + "3.3.5.4.b.3", + "3.3.5.4.b.4", + "3.3.5.4.b.5", + "3.3.5.4.b.6", + "3.3.5.4.b.7", + "3.3.5.4.c", + "3.3.5.4.d", + "3.3.5.4.e", + "3.3.5.4.f", + "3.3.5.4.f.1", + "3.3.5.4.f.1.a", + "3.3.5.4.f.1.b", + "3.3.5.4.f.2", + "3.3.5.4.f.3", + "3.3.5.4.f.4", + "3.3.5.4.f.4.a", + "3.3.5.4.f.4.b", + "3.3.5.4.f.4.c", + "3.3.8", + "3.3.8.1", + "3.3.8.4", + "3.3.8.5", + "3.3.8.6", + "3.3.8.6.a", + "3.3.8.6.b", + "3.3.8.6.c", + "3.3.8.6.d", + "3.3.8.6.e", + "3.3.8.6.f", + "3.3.8.6.g", + "3.3.8.6.h", + "3.3.8.6.h.1", + "3.3.8.6.h.2", + "3.3.8.6.h.3", + "3.3.8.6.h.4", + "3.3.8.6.h.5", + "3.3.8.6.i", + "3.3.8.6.j", + "3.3.10", + "3.3.10.1" + ], + "GOV-03": [ + "3.1.3.2" ], "GOV-04": [ - "3.1.4" + "3.1.4", + "3.1.4.4", + "3.1.4.4.a", + "3.1.4.4.a.1", + "3.1.4.4.a.2", + "3.1.4.4.a.3", + "3.1.4.4.a.4", + "3.1.4.4.b", + "3.1.4.4.c", + "3.1.4.4.d", + "3.1.4.4.e", + "3.1.4.4.e.1", + "3.1.4.4.e.2", + "3.1.4.4.e.3", + "3.1.4.4.e.4", + "3.1.4.4.e.5", + "3.1.4.4.f", + "3.1.4.4.g", + "3.1.4.4.g.1", + "3.1.4.4.g.2", + "3.1.4.4.g.3", + "3.1.4.4.h", + "3.1.4.4.i", + "3.1.4.4.i.1", + "3.1.4.4.i.2", + "3.1.4.4.i.3", + "3.1.4.4.i.4" + ], + "GOV-04.1": [ + "3.1.4.1", + "3.1.4.1.a", + "3.1.4.1.b", + "3.1.4.1.c", + "3.1.4.1.c.1", + "3.1.4.1.c.2", + "3.1.4.1.c.3", + "3.1.4.2", + "3.1.4.2.a", + "3.1.4.2.b", + "3.1.4.2.c", + "3.1.4.2.c.1", + "3.1.4.2.c.2", + "3.1.4.2.c.3", + "3.1.4.2.c.4", + "3.1.4.2.c.5", + "3.1.4.2.c.6", + "3.1.4.3", + "3.1.4.3.a", + "3.1.4.3.b", + "3.1.4.3.c", + "3.1.4.5", + "3.1.4.5.a" + ], + "GOV-19.3": [ + "3.4.2.3", + "3.4.2.3.a", + "3.4.2.3.b", + "3.4.2.3.c" ], "AST-01": [ - "3.3.3" - ], - "AST-07": [ - "3.3.12" + "3.3.3", + "3.3.3.1", + "3.3.3.3" + ], + "AST-02.9": [ + "3.3.3.3", + "3.3.3.3.a", + "3.3.3.3.b", + "3.3.3.3.c", + "3.3.3.3.d", + "3.3.3.3.e" ], "AST-09": [ - "3.3.11" + "3.3.2.3.e", + "3.3.11", + "3.3.11.1", + "3.3.11.4", + "3.3.11.5" + ], + "AST-10": [ + "3.3.1.3.e.2" ], "AST-16": [ - "3.3.10" + "3.3.10.4", + "3.3.10.4.a", + "3.3.10.4.b", + "3.3.10.4.c", + "3.3.10.4.d", + "3.3.10.4.e" ], "CHG-01": [ - "3.3.7" + "3.3.7", + "3.3.7.1", + "3.3.7.4" ], - "CLD-01": [ - "3.3.4", - "3.3.8", - "3.4.3" + "CHG-02": [ + "3.3.7.4.c", + "3.3.7.4.d", + "3.3.7.4.e", + "3.3.7.4.i" ], - "CLD-02": [ - "3.3.4", - "3.3.8", - "3.4.3" + "CHG-02.2": [ + "3.3.7.4.b" + ], + "CHG-03": [ + "3.3.7.4.a" + ], + "CHG-06": [ + "3.3.7.4.f" + ], + "CHG-07": [ + "3.3.7.4.h" + ], + "CLD-01": [ + "3.4.3", + "3.4.3.1", + "3.4.3.3", + "3.4.3.4", + "3.4.3.4.a", + "3.4.3.4.a.1", + "3.4.3.4.a.2", + "3.4.3.4.a.3", + "3.4.3.4.b", + "3.4.3.4.b.1", + "3.4.3.4.c", + "3.4.3.4.c.1", + "3.4.3.4.d", + "3.4.3.4.d.1", + "3.4.3.4.e", + "3.4.3.4.e.1", + "3.4.3.4.f", + "3.4.3.4.f.1", + "3.4.3.4.g", + "3.4.3.4.g.1", + "3.4.3.4.g.2", + "3.4.3.4.g.3" + ], + "CLD-01.2": [ + "3.4.3.4.h", + "3.4.3.4.h.1", + "3.4.3.4.h.2", + "3.4.3.4.h.3" ], "CPL-01": [ "3.2.2", - "3.2.3", - "3.3.13" + "3.2.2.1", + "3.2.2.1.a", + "3.2.2.1.b", + "3.2.2.1.c" ], "CPL-02": [ - "3.2.4" + "3.2.5" ], "CPL-02.1": [ - "3.2.5" + "3.2.5.1" + ], + "CPL-02.2": [ + "3.2.5.2" ], "CPL-03": [ "3.2.4", - "3.2.5" + "3.2.4.1", + "3.2.4.2", + "3.2.4.3", + "3.2.4.4", + "3.2.4.5", + "3.2.4.5.a", + "3.2.4.5.b", + "3.2.4.5.c", + "3.3.1.2", + "3.3.2.2", + "3.3.3.2", + "3.3.4.2", + "3.3.5.2", + "3.3.5.3", + "3.3.6.2", + "3.3.6.3", + "3.3.7.2", + "3.3.7.3", + "3.3.8.2", + "3.3.8.3", + "3.3.9.2", + "3.3.9.3", + "3.3.10.2", + "3.3.10.3", + "3.3.11.2", + "3.3.11.3", + "3.3.14.2", + "3.3.14.4.i", + "3.3.14.4.l", + "3.3.15", + "3.3.15.2", + "3.3.16", + "3.3.16.2", + "3.3.17.2", + "3.4.1.2", + "3.4.1.3", + "3.4.2", + "3.4.2.2", + "3.4.3.2" + ], + "CFG-02": [ + "3.3.6", + "3.3.6.1", + "3.3.13.4.c.2" ], "MON-01": [ - "3.3.14" + "3.3.14", + "3.3.14.1", + "3.3.14.3", + "3.3.14.4", + "3.3.14.4.a", + "3.3.14.4.b", + "3.3.14.4.c", + "3.3.14.4.d", + "3.3.14.4.e", + "3.3.14.4.f", + "3.3.14.4.g" ], "MON-01.2": [ - "3.3.14" - ], - "MON-01.16": [ - "3.3.14" + "3.3.14.4.j", + "3.3.14.4.k" ], - "MON-02": [ - "3.3.14" + "MON-03": [ + "3.3.14.3.a" ], - "MON-02.1": [ - "3.3.14" + "MON-08": [ + "3.3.14.4.h" ], "CRY-01": [ - "3.3.9" - ], - "DCH-08": [ - "3.3.11" - ], - "DCH-21": [ - "3.3.11" + "3.3.9", + "3.3.9.1", + "3.3.9.4", + "3.3.9.4.a", + "3.3.9.4.b", + "3.3.9.4.c" ], "HRS-01": [ - "3.3.1" + "3.3.1", + "3.3.1.1", + "3.3.1.3" + ], + "HRS-01.1": [ + "3.3.1.3.e.1", + "3.3.1.3.e.2" ], "HRS-03": [ - "3.1.4" + "3.1.4.6", + "3.1.4.6.a", + "3.3.1.3.a" + ], + "HRS-04": [ + "3.3.1.3.d" + ], + "HRS-04.1": [ + "3.3.1.3.d" + ], + "HRS-04.2": [ + "3.3.1.3.b" + ], + "HRS-05.7": [ + "3.3.1.3.b" + ], + "HRS-06.1": [ + "3.3.1.3.a" + ], + "HRS-06.2": [ + "3.3.1.3.e" + ], + "HRS-07": [ + "3.3.1.3.c" ], "IAC-01": [ + "3.3.5.1" + ], + "IAC-21": [ "3.3.5" ], "IRO-01": [ - "3.3.15" - ], - "NET-01": [ - "3.3.4", - "3.3.8" + "3.3.15.1" + ], + "IRO-02": [ + "3.3.15.3", + "3.3.15.4", + "3.3.15.4.a", + "3.3.15.4.b", + "3.3.15.4.c", + "3.3.15.4.d", + "3.3.15.4.e", + "3.3.15.4.f", + "3.3.15.4.g", + "3.3.15.4.h", + "3.3.15.4.i", + "3.3.15.4.j" + ], + "IRO-10.5": [ + "3.3.15.7", + "3.3.15.7.a", + "3.3.15.7.b", + "3.3.15.7.c", + "3.3.15.7.d", + "3.3.15.7.e", + "3.3.15.7.f", + "3.3.15.7.g", + "3.3.15.7.h", + "3.3.15.7.i", + "3.3.15.7.j", + "3.3.15.7.k" + ], + "IAO-02.2": [ + "3.3.7.4.b.1", + "3.3.7.4.b.2", + "3.3.7.4.b.3", + "3.3.7.4.b.4" + ], + "IAO-05": [ + "3.2.1.4-2.2" + ], + "MDM-01": [ + "3.3.10" ], "PES-01": [ - "3.3.2" + "3.3.2", + "3.3.2.1", + "3.3.2.3" + ], + "PES-03": [ + "3.3.2.3.a" + ], + "PES-04": [ + "3.3.2.3.c" + ], + "PES-05.1": [ + "3.3.2.3.b" + ], + "PES-07": [ + "3.3.2.3.d" ], - "PRI-05": [ - "3.3.11" + "PES-10": [ + "3.3.2.3.e" + ], + "PES-12": [ + "3.3.2.3.e" + ], + "PRM-01": [ + "3.1.5.1" ], "PRM-01.1": [ - "3.1.2" + "3.1.2", + "3.1.2.1", + "3.1.2.2", + "3.1.2.2.a", + "3.1.2.2.b", + "3.1.2.2.c", + "3.1.2.3", + "3.1.2.3.a", + "3.1.2.3.b", + "3.1.2.3.c" + ], + "PRM-03": [ + "3.1.1.10" ], "PRM-04": [ + "3.1.5", + "3.1.5.1", + "3.1.5.2", + "3.1.5.2.a", + "3.1.5.2.b", + "3.1.5.2.c", + "3.1.5.2.d", + "3.1.5.2.e", + "3.1.5.2.f" + ], + "PRM-07": [ "3.1.5" ], "RSK-01": [ - "3.2.1" + "3.2.1", + "3.2.1.1-1", + "3.2.1.2-1", + "3.2.1.3-1", + "3.2.1.4-1", + "3.2.1.5", + "3.2.1.5.a", + "3.2.1.5.b", + "3.2.1.5.c", + "3.2.1.6", + "3.2.1.6.a", + "3.2.1.6.b", + "3.2.1.6.c", + "3.2.1.6.d", + "3.2.1.7", + "3.2.1.8", + "3.2.1.8.a", + "3.2.1.8.b", + "3.2.1.8.c", + "3.2.1.8.d" + ], + "RSK-01.3": [ + "3.2.1.11" + ], + "RSK-01.5": [ + "3.2.1.11" ], "RSK-03": [ - "3.2.1.1" + "3.2.1.4-1.a", + "3.2.1.1-2", + "3.2.1.1-2.1", + "3.2.1.1-2.3" + ], + "RSK-03.1": [ + "3.2.1.1-2.2" ], "RSK-04": [ - "3.2.1.2" + "3.2.1.4-1.b", + "3.2.1.2-2", + "3.2.1.2-2.1", + "3.2.1.2-2.2" ], "RSK-04.1": [ - "3.2.1.4" - ], - "RSK-05": [ - "3.2.1.2" + "3.2.1.4-1.c", + "3.2.1.1-2.2" ], - "RSK-06.1": [ - "3.2.1.3" - ], - "SEA-01": [ - "3.3.4", - "3.3.8", - "3.3.13" + "RSK-04.4": [ + "3.2.1.9" ], - "SEA-02": [ - "3.3.4", - "3.3.8", - "3.3.13" + "RSK-06": [ + "3.2.1.3-2", + "3.2.1.3-2.1" ], - "SEA-03": [ + "RSK-06.1": [ + "3.2.1.4-1.d" + ], + "RSK-06.2": [ + "3.2.1.3-2.6", + "3.2.1.3-2.6.a", + "3.2.1.3-2.6.b", + "3.2.1.3-2.6.b.1", + "3.2.1.3-2.6.b.2", + "3.2.1.3-2.6.b.3", + "3.2.1.3-2.6.c", + "3.2.1.3-2.6.d" + ], + "RSK-06.3": [ + "3.2.1.10", + "3.2.1.3-2.3", + "3.2.1.3-2.3.a", + "3.2.1.3-2.3.b", + "3.2.1.3-2.3.b.1", + "3.2.1.3-2.3.b.2", + "3.2.1.3-2.4", + "3.2.1.3-2.5", + "3.2.1.3-2.5.a", + "3.2.1.3-2.5.b", + "3.2.1.3-2.5.c" + ], + "RSK-06.4": [ + "3.2.1.3-2.2", + "3.2.1.3-2.7", + "3.2.1.4-2", + "3.2.1.4-2.1", + "3.2.1.4-2.1.a", + "3.2.1.4-2.1.b", + "3.2.1.4-2.2" + ], + "RSK-11": [ + "3.2.1.4-1.d" + ], + "RSK-13": [ + "3.2.1.10" + ], + "SEA-01.4": [ "3.3.4", - "3.3.8", - "3.3.13" + "3.3.4.1", + "3.3.4.3", + "3.3.4.3.a", + "3.3.4.3.b", + "3.3.4.3.c", + "3.3.4.3.d", + "3.3.4.3.e" ], "SAT-01": [ - "3.1.6" - ], - "SAT-03": [ "3.1.6", - "3.1.7" + "3.1.6.1", + "3.1.6.2", + "3.1.6.2.a", + "3.1.6.2.b", + "3.1.6.2.c", + "3.1.6.3", + "3.1.6.4", + "3.1.6.5", + "3.1.6.5.a", + "3.1.6.5.b", + "3.1.6.5.c" + ], + "SAT-01.1": [ + "3.1.6.6", + "3.1.6.6.a", + "3.1.6.6.b" + ], + "SAT-02": [ + "3.1.6.7", + "3.1.7", + "3.3.1.3.b" ], - "SAT-03.3": [ - "3.1.7" - ], - "TDA-01": [ - "3.3.6" + "SAT-03": [ + "3.1.7.1", + "3.1.7.1.a", + "3.1.7.1.b", + "3.1.7.1.c", + "3.1.7.1.d", + "3.1.7.2" + ], + "TDA-06": [ + "3.3.6.4", + "3.3.6.5", + "3.3.6.5.a", + "3.3.6.5.b", + "3.3.6.5.c", + "3.3.6.5.d", + "3.3.6.5.e", + "3.3.6.5.f", + "3.3.6.5.g" + ], + "TDA-08": [ + "3.3.7.4.g" ], "TPM-01": [ "3.4.1", - "3.4.2" + "3.4.1.1", + "3.4.1.4", + "3.4.1.4.a", + "3.4.1.6", + "3.4.1.6.a", + "3.4.2.1" + ], + "TPM-05": [ + "3.4.1.4.b", + "3.4.1.4.c", + "3.4.1.5", + "3.4.1.5.a", + "3.4.1.5.b", + "3.4.1.5.c", + "3.4.1.5.d", + "3.4.1.5.e", + "3.4.1.5.f", + "3.4.1.5.g" + ], + "TPM-08": [ + "3.3.11.6" ], - "TPM-03": [ - "3.4.2" + "THR-01": [ + "3.3.16.1", + "3.3.16.3", + "3.3.16.3.a", + "3.3.16.3.c", + "3.3.16.3.d", + "3.3.16.3.e" ], - "TPM-04.1": [ - "3.4.1", - "3.4.2" + "THR-03": [ + "3.3.16.3.b" ], - "THR-01": [ - "3.3.16" + "THR-03.1": [ + "3.3.16.3.f" ], "VPM-01": [ - "3.3.17" + "3.3.17", + "3.3.17.1", + "3.3.17.3", + "3.3.17.3.a", + "3.3.17.3.b", + "3.3.17.3.c", + "3.3.17.3.d", + "3.3.17.3.e", + "3.3.17.3.f" ] } }, "framework_to_scf": { - "total_mappings": 36, + "total_mappings": 482, "mappings": { "3.1.1": [ - "GOV-01", + "GOV-01" + ], + "3.1.1.1": [ + "GOV-01.1" + ], + "3.1.1.2": [ + "GOV-01.1" + ], + "3.1.1.3": [ "GOV-01.1" ], + "3.1.1.3.a": [ + "GOV-01.1" + ], + "3.1.1.3.b": [ + "GOV-01.1" + ], + "3.1.1.3.c": [ + "GOV-01.1" + ], + "3.1.1.4": [ + "GOV-01.1" + ], + "3.1.1.4.a": [ + "GOV-01.1" + ], + "3.1.1.4.b": [ + "GOV-01.1" + ], + "3.1.1.4.c": [ + "GOV-01.1" + ], + "3.1.1.4.d": [ + "GOV-01.1" + ], + "3.1.1.5": [ + "GOV-01.1" + ], + "3.1.1.6": [ + "GOV-01.1" + ], + "3.1.1.7": [ + "GOV-01.1" + ], + "3.1.1.8": [ + "GOV-01.1" + ], + "3.1.1.9": [ + "GOV-01.1" + ], + "3.1.1.9.a": [ + "GOV-01.1" + ], + "3.1.1.9.b": [ + "GOV-01.1" + ], + "3.1.1.9.c": [ + "GOV-01.1" + ], + "3.2.3": [ + "GOV-01.4" + ], + "3.2.3.1": [ + "GOV-01.4" + ], + "3.2.3.1.a": [ + "GOV-01.4" + ], + "3.2.3.1.b": [ + "GOV-01.4" + ], + "3.2.3.1.c": [ + "GOV-01.4" + ], "3.1.3": [ "GOV-02" ], - "3.1.4": [ - "GOV-04", - "HRS-03" + "3.1.3.1": [ + "GOV-02" ], - "3.3.3": [ - "AST-01" + "3.1.3.3": [ + "GOV-02" ], - "3.3.12": [ - "AST-07" + "3.1.3.3.a": [ + "GOV-02" ], - "3.3.11": [ - "AST-09", - "DCH-08", - "DCH-21", - "PRI-05" + "3.1.3.3.b": [ + "GOV-02" ], - "3.3.10": [ - "AST-16" + "3.1.3.3.c": [ + "GOV-02" ], - "3.3.7": [ - "CHG-01" + "3.1.3.3.d": [ + "GOV-02" ], - "3.3.4": [ - "CLD-01", - "CLD-02", - "NET-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.1.3.4": [ + "GOV-02" ], - "3.3.8": [ - "CLD-01", - "CLD-02", - "NET-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.1.3.4.a": [ + "GOV-02" ], - "3.4.3": [ - "CLD-01", - "CLD-02" + "3.1.3.4.b": [ + "GOV-02" ], - "3.2.2": [ - "CPL-01" + "3.1.3.4.c": [ + "GOV-02" ], - "3.2.3": [ - "CPL-01" + "3.1.3.4.d": [ + "GOV-02" ], - "3.3.13": [ - "CPL-01", - "SEA-01", - "SEA-02", - "SEA-03" + "3.1.3.4.e": [ + "GOV-02" ], - "3.2.4": [ - "CPL-02", - "CPL-03" + "3.1.3.4.f": [ + "GOV-02" ], - "3.2.5": [ - "CPL-02.1", - "CPL-03" + "3.1.3.4.f.1": [ + "GOV-02" ], - "3.3.14": [ - "MON-01", - "MON-01.2", - "MON-01.16", - "MON-02", - "MON-02.1" + "3.1.3.4.f.2": [ + "GOV-02" ], - "3.3.9": [ - "CRY-01" + "3.1.3.4.f.3": [ + "GOV-02" ], - "3.3.1": [ - "HRS-01" + "3.1.3.4.f.4": [ + "GOV-02" ], - "3.3.5": [ + "3.1.3.4.f.5": [ + "GOV-02" + ], + "3.1.3.4.f.6": [ + "GOV-02" + ], + "3.1.3.4.f.7": [ + "GOV-02" + ], + "3.1.3.4.f.8": [ + "GOV-02" + ], + "3.3.5.1": [ + "GOV-02", "IAC-01" ], - "3.3.15": [ - "IRO-01" + "3.3.5.4": [ + "GOV-02" ], - "3.3.2": [ - "PES-01" + "3.3.5.4.a": [ + "GOV-02" ], - "3.1.2": [ - "PRM-01.1" + "3.3.5.4.b": [ + "GOV-02" ], - "3.1.5": [ - "PRM-04" + "3.3.5.4.b.1": [ + "GOV-02" ], - "3.2.1": [ - "RSK-01" + "3.3.5.4.b.2": [ + "GOV-02" ], - "3.2.1.1": [ - "RSK-03" + "3.3.5.4.b.3": [ + "GOV-02" ], - "3.2.1.2": [ - "RSK-04", - "RSK-05" + "3.3.5.4.b.4": [ + "GOV-02" ], - "3.2.1.4": [ - "RSK-04.1" + "3.3.5.4.b.5": [ + "GOV-02" ], - "3.2.1.3": [ - "RSK-06.1" + "3.3.5.4.b.6": [ + "GOV-02" ], - "3.1.6": [ - "SAT-01", - "SAT-03" + "3.3.5.4.b.7": [ + "GOV-02" ], - "3.1.7": [ - "SAT-03", - "SAT-03.3" + "3.3.5.4.c": [ + "GOV-02" ], - "3.3.6": [ - "TDA-01" + "3.3.5.4.d": [ + "GOV-02" ], - "3.4.1": [ - "TPM-01", - "TPM-04.1" + "3.3.5.4.e": [ + "GOV-02" ], - "3.4.2": [ - "TPM-01", - "TPM-03", - "TPM-04.1" + "3.3.5.4.f": [ + "GOV-02" ], - "3.3.16": [ - "THR-01" + "3.3.5.4.f.1": [ + "GOV-02" ], - "3.3.17": [ + "3.3.5.4.f.1.a": [ + "GOV-02" + ], + "3.3.5.4.f.1.b": [ + "GOV-02" + ], + "3.3.5.4.f.2": [ + "GOV-02" + ], + "3.3.5.4.f.3": [ + "GOV-02" + ], + "3.3.5.4.f.4": [ + "GOV-02" + ], + "3.3.5.4.f.4.a": [ + "GOV-02" + ], + "3.3.5.4.f.4.b": [ + "GOV-02" + ], + "3.3.5.4.f.4.c": [ + "GOV-02" + ], + "3.3.8": [ + "GOV-02" + ], + "3.3.8.1": [ + "GOV-02" + ], + "3.3.8.4": [ + "GOV-02" + ], + "3.3.8.5": [ + "GOV-02" + ], + "3.3.8.6": [ + "GOV-02" + ], + "3.3.8.6.a": [ + "GOV-02" + ], + "3.3.8.6.b": [ + "GOV-02" + ], + "3.3.8.6.c": [ + "GOV-02" + ], + "3.3.8.6.d": [ + "GOV-02" + ], + "3.3.8.6.e": [ + "GOV-02" + ], + "3.3.8.6.f": [ + "GOV-02" + ], + "3.3.8.6.g": [ + "GOV-02" + ], + "3.3.8.6.h": [ + "GOV-02" + ], + "3.3.8.6.h.1": [ + "GOV-02" + ], + "3.3.8.6.h.2": [ + "GOV-02" + ], + "3.3.8.6.h.3": [ + "GOV-02" + ], + "3.3.8.6.h.4": [ + "GOV-02" + ], + "3.3.8.6.h.5": [ + "GOV-02" + ], + "3.3.8.6.i": [ + "GOV-02" + ], + "3.3.8.6.j": [ + "GOV-02" + ], + "3.3.10": [ + "GOV-02", + "MDM-01" + ], + "3.3.10.1": [ + "GOV-02" + ], + "3.1.3.2": [ + "GOV-03" + ], + "3.1.4": [ + "GOV-04" + ], + "3.1.4.4": [ + "GOV-04" + ], + "3.1.4.4.a": [ + "GOV-04" + ], + "3.1.4.4.a.1": [ + "GOV-04" + ], + "3.1.4.4.a.2": [ + "GOV-04" + ], + "3.1.4.4.a.3": [ + "GOV-04" + ], + "3.1.4.4.a.4": [ + "GOV-04" + ], + "3.1.4.4.b": [ + "GOV-04" + ], + "3.1.4.4.c": [ + "GOV-04" + ], + "3.1.4.4.d": [ + "GOV-04" + ], + "3.1.4.4.e": [ + "GOV-04" + ], + "3.1.4.4.e.1": [ + "GOV-04" + ], + "3.1.4.4.e.2": [ + "GOV-04" + ], + "3.1.4.4.e.3": [ + "GOV-04" + ], + "3.1.4.4.e.4": [ + "GOV-04" + ], + "3.1.4.4.e.5": [ + "GOV-04" + ], + "3.1.4.4.f": [ + "GOV-04" + ], + "3.1.4.4.g": [ + "GOV-04" + ], + "3.1.4.4.g.1": [ + "GOV-04" + ], + "3.1.4.4.g.2": [ + "GOV-04" + ], + "3.1.4.4.g.3": [ + "GOV-04" + ], + "3.1.4.4.h": [ + "GOV-04" + ], + "3.1.4.4.i": [ + "GOV-04" + ], + "3.1.4.4.i.1": [ + "GOV-04" + ], + "3.1.4.4.i.2": [ + "GOV-04" + ], + "3.1.4.4.i.3": [ + "GOV-04" + ], + "3.1.4.4.i.4": [ + "GOV-04" + ], + "3.1.4.1": [ + "GOV-04.1" + ], + "3.1.4.1.a": [ + "GOV-04.1" + ], + "3.1.4.1.b": [ + "GOV-04.1" + ], + "3.1.4.1.c": [ + "GOV-04.1" + ], + "3.1.4.1.c.1": [ + "GOV-04.1" + ], + "3.1.4.1.c.2": [ + "GOV-04.1" + ], + "3.1.4.1.c.3": [ + "GOV-04.1" + ], + "3.1.4.2": [ + "GOV-04.1" + ], + "3.1.4.2.a": [ + "GOV-04.1" + ], + "3.1.4.2.b": [ + "GOV-04.1" + ], + "3.1.4.2.c": [ + "GOV-04.1" + ], + "3.1.4.2.c.1": [ + "GOV-04.1" + ], + "3.1.4.2.c.2": [ + "GOV-04.1" + ], + "3.1.4.2.c.3": [ + "GOV-04.1" + ], + "3.1.4.2.c.4": [ + "GOV-04.1" + ], + "3.1.4.2.c.5": [ + "GOV-04.1" + ], + "3.1.4.2.c.6": [ + "GOV-04.1" + ], + "3.1.4.3": [ + "GOV-04.1" + ], + "3.1.4.3.a": [ + "GOV-04.1" + ], + "3.1.4.3.b": [ + "GOV-04.1" + ], + "3.1.4.3.c": [ + "GOV-04.1" + ], + "3.1.4.5": [ + "GOV-04.1" + ], + "3.1.4.5.a": [ + "GOV-04.1" + ], + "3.4.2.3": [ + "GOV-19.3" + ], + "3.4.2.3.a": [ + "GOV-19.3" + ], + "3.4.2.3.b": [ + "GOV-19.3" + ], + "3.4.2.3.c": [ + "GOV-19.3" + ], + "3.3.3": [ + "AST-01" + ], + "3.3.3.1": [ + "AST-01" + ], + "3.3.3.3": [ + "AST-01", + "AST-02.9" + ], + "3.3.3.3.a": [ + "AST-02.9" + ], + "3.3.3.3.b": [ + "AST-02.9" + ], + "3.3.3.3.c": [ + "AST-02.9" + ], + "3.3.3.3.d": [ + "AST-02.9" + ], + "3.3.3.3.e": [ + "AST-02.9" + ], + "3.3.2.3.e": [ + "AST-09", + "PES-10", + "PES-12" + ], + "3.3.11": [ + "AST-09" + ], + "3.3.11.1": [ + "AST-09" + ], + "3.3.11.4": [ + "AST-09" + ], + "3.3.11.5": [ + "AST-09" + ], + "3.3.1.3.e.2": [ + "AST-10", + "HRS-01.1" + ], + "3.3.10.4": [ + "AST-16" + ], + "3.3.10.4.a": [ + "AST-16" + ], + "3.3.10.4.b": [ + "AST-16" + ], + "3.3.10.4.c": [ + "AST-16" + ], + "3.3.10.4.d": [ + "AST-16" + ], + "3.3.10.4.e": [ + "AST-16" + ], + "3.3.7": [ + "CHG-01" + ], + "3.3.7.1": [ + "CHG-01" + ], + "3.3.7.4": [ + "CHG-01" + ], + "3.3.7.4.c": [ + "CHG-02" + ], + "3.3.7.4.d": [ + "CHG-02" + ], + "3.3.7.4.e": [ + "CHG-02" + ], + "3.3.7.4.i": [ + "CHG-02" + ], + "3.3.7.4.b": [ + "CHG-02.2" + ], + "3.3.7.4.a": [ + "CHG-03" + ], + "3.3.7.4.f": [ + "CHG-06" + ], + "3.3.7.4.h": [ + "CHG-07" + ], + "3.4.3": [ + "CLD-01" + ], + "3.4.3.1": [ + "CLD-01" + ], + "3.4.3.3": [ + "CLD-01" + ], + "3.4.3.4": [ + "CLD-01" + ], + "3.4.3.4.a": [ + "CLD-01" + ], + "3.4.3.4.a.1": [ + "CLD-01" + ], + "3.4.3.4.a.2": [ + "CLD-01" + ], + "3.4.3.4.a.3": [ + "CLD-01" + ], + "3.4.3.4.b": [ + "CLD-01" + ], + "3.4.3.4.b.1": [ + "CLD-01" + ], + "3.4.3.4.c": [ + "CLD-01" + ], + "3.4.3.4.c.1": [ + "CLD-01" + ], + "3.4.3.4.d": [ + "CLD-01" + ], + "3.4.3.4.d.1": [ + "CLD-01" + ], + "3.4.3.4.e": [ + "CLD-01" + ], + "3.4.3.4.e.1": [ + "CLD-01" + ], + "3.4.3.4.f": [ + "CLD-01" + ], + "3.4.3.4.f.1": [ + "CLD-01" + ], + "3.4.3.4.g": [ + "CLD-01" + ], + "3.4.3.4.g.1": [ + "CLD-01" + ], + "3.4.3.4.g.2": [ + "CLD-01" + ], + "3.4.3.4.g.3": [ + "CLD-01" + ], + "3.4.3.4.h": [ + "CLD-01.2" + ], + "3.4.3.4.h.1": [ + "CLD-01.2" + ], + "3.4.3.4.h.2": [ + "CLD-01.2" + ], + "3.4.3.4.h.3": [ + "CLD-01.2" + ], + "3.2.2": [ + "CPL-01" + ], + "3.2.2.1": [ + "CPL-01" + ], + "3.2.2.1.a": [ + "CPL-01" + ], + "3.2.2.1.b": [ + "CPL-01" + ], + "3.2.2.1.c": [ + "CPL-01" + ], + "3.2.5": [ + "CPL-02" + ], + "3.2.5.1": [ + "CPL-02.1" + ], + "3.2.5.2": [ + "CPL-02.2" + ], + "3.2.4": [ + "CPL-03" + ], + "3.2.4.1": [ + "CPL-03" + ], + "3.2.4.2": [ + "CPL-03" + ], + "3.2.4.3": [ + "CPL-03" + ], + "3.2.4.4": [ + "CPL-03" + ], + "3.2.4.5": [ + "CPL-03" + ], + "3.2.4.5.a": [ + "CPL-03" + ], + "3.2.4.5.b": [ + "CPL-03" + ], + "3.2.4.5.c": [ + "CPL-03" + ], + "3.3.1.2": [ + "CPL-03" + ], + "3.3.2.2": [ + "CPL-03" + ], + "3.3.3.2": [ + "CPL-03" + ], + "3.3.4.2": [ + "CPL-03" + ], + "3.3.5.2": [ + "CPL-03" + ], + "3.3.5.3": [ + "CPL-03" + ], + "3.3.6.2": [ + "CPL-03" + ], + "3.3.6.3": [ + "CPL-03" + ], + "3.3.7.2": [ + "CPL-03" + ], + "3.3.7.3": [ + "CPL-03" + ], + "3.3.8.2": [ + "CPL-03" + ], + "3.3.8.3": [ + "CPL-03" + ], + "3.3.9.2": [ + "CPL-03" + ], + "3.3.9.3": [ + "CPL-03" + ], + "3.3.10.2": [ + "CPL-03" + ], + "3.3.10.3": [ + "CPL-03" + ], + "3.3.11.2": [ + "CPL-03" + ], + "3.3.11.3": [ + "CPL-03" + ], + "3.3.14.2": [ + "CPL-03" + ], + "3.3.14.4.i": [ + "CPL-03" + ], + "3.3.14.4.l": [ + "CPL-03" + ], + "3.3.15": [ + "CPL-03" + ], + "3.3.15.2": [ + "CPL-03" + ], + "3.3.16": [ + "CPL-03" + ], + "3.3.16.2": [ + "CPL-03" + ], + "3.3.17.2": [ + "CPL-03" + ], + "3.4.1.2": [ + "CPL-03" + ], + "3.4.1.3": [ + "CPL-03" + ], + "3.4.2": [ + "CPL-03" + ], + "3.4.2.2": [ + "CPL-03" + ], + "3.4.3.2": [ + "CPL-03" + ], + "3.3.6": [ + "CFG-02" + ], + "3.3.6.1": [ + "CFG-02" + ], + "3.3.13.4.c.2": [ + "CFG-02" + ], + "3.3.14": [ + "MON-01" + ], + "3.3.14.1": [ + "MON-01" + ], + "3.3.14.3": [ + "MON-01" + ], + "3.3.14.4": [ + "MON-01" + ], + "3.3.14.4.a": [ + "MON-01" + ], + "3.3.14.4.b": [ + "MON-01" + ], + "3.3.14.4.c": [ + "MON-01" + ], + "3.3.14.4.d": [ + "MON-01" + ], + "3.3.14.4.e": [ + "MON-01" + ], + "3.3.14.4.f": [ + "MON-01" + ], + "3.3.14.4.g": [ + "MON-01" + ], + "3.3.14.4.j": [ + "MON-01.2" + ], + "3.3.14.4.k": [ + "MON-01.2" + ], + "3.3.14.3.a": [ + "MON-03" + ], + "3.3.14.4.h": [ + "MON-08" + ], + "3.3.9": [ + "CRY-01" + ], + "3.3.9.1": [ + "CRY-01" + ], + "3.3.9.4": [ + "CRY-01" + ], + "3.3.9.4.a": [ + "CRY-01" + ], + "3.3.9.4.b": [ + "CRY-01" + ], + "3.3.9.4.c": [ + "CRY-01" + ], + "3.3.1": [ + "HRS-01" + ], + "3.3.1.1": [ + "HRS-01" + ], + "3.3.1.3": [ + "HRS-01" + ], + "3.3.1.3.e.1": [ + "HRS-01.1" + ], + "3.1.4.6": [ + "HRS-03" + ], + "3.1.4.6.a": [ + "HRS-03" + ], + "3.3.1.3.a": [ + "HRS-03", + "HRS-06.1" + ], + "3.3.1.3.d": [ + "HRS-04", + "HRS-04.1" + ], + "3.3.1.3.b": [ + "HRS-04.2", + "HRS-05.7", + "SAT-02" + ], + "3.3.1.3.e": [ + "HRS-06.2" + ], + "3.3.1.3.c": [ + "HRS-07" + ], + "3.3.5": [ + "IAC-21" + ], + "3.3.15.1": [ + "IRO-01" + ], + "3.3.15.3": [ + "IRO-02" + ], + "3.3.15.4": [ + "IRO-02" + ], + "3.3.15.4.a": [ + "IRO-02" + ], + "3.3.15.4.b": [ + "IRO-02" + ], + "3.3.15.4.c": [ + "IRO-02" + ], + "3.3.15.4.d": [ + "IRO-02" + ], + "3.3.15.4.e": [ + "IRO-02" + ], + "3.3.15.4.f": [ + "IRO-02" + ], + "3.3.15.4.g": [ + "IRO-02" + ], + "3.3.15.4.h": [ + "IRO-02" + ], + "3.3.15.4.i": [ + "IRO-02" + ], + "3.3.15.4.j": [ + "IRO-02" + ], + "3.3.15.7": [ + "IRO-10.5" + ], + "3.3.15.7.a": [ + "IRO-10.5" + ], + "3.3.15.7.b": [ + "IRO-10.5" + ], + "3.3.15.7.c": [ + "IRO-10.5" + ], + "3.3.15.7.d": [ + "IRO-10.5" + ], + "3.3.15.7.e": [ + "IRO-10.5" + ], + "3.3.15.7.f": [ + "IRO-10.5" + ], + "3.3.15.7.g": [ + "IRO-10.5" + ], + "3.3.15.7.h": [ + "IRO-10.5" + ], + "3.3.15.7.i": [ + "IRO-10.5" + ], + "3.3.15.7.j": [ + "IRO-10.5" + ], + "3.3.15.7.k": [ + "IRO-10.5" + ], + "3.3.7.4.b.1": [ + "IAO-02.2" + ], + "3.3.7.4.b.2": [ + "IAO-02.2" + ], + "3.3.7.4.b.3": [ + "IAO-02.2" + ], + "3.3.7.4.b.4": [ + "IAO-02.2" + ], + "3.2.1.4-2.2": [ + "IAO-05", + "RSK-06.4" + ], + "3.3.2": [ + "PES-01" + ], + "3.3.2.1": [ + "PES-01" + ], + "3.3.2.3": [ + "PES-01" + ], + "3.3.2.3.a": [ + "PES-03" + ], + "3.3.2.3.c": [ + "PES-04" + ], + "3.3.2.3.b": [ + "PES-05.1" + ], + "3.3.2.3.d": [ + "PES-07" + ], + "3.1.5.1": [ + "PRM-01", + "PRM-04" + ], + "3.1.2": [ + "PRM-01.1" + ], + "3.1.2.1": [ + "PRM-01.1" + ], + "3.1.2.2": [ + "PRM-01.1" + ], + "3.1.2.2.a": [ + "PRM-01.1" + ], + "3.1.2.2.b": [ + "PRM-01.1" + ], + "3.1.2.2.c": [ + "PRM-01.1" + ], + "3.1.2.3": [ + "PRM-01.1" + ], + "3.1.2.3.a": [ + "PRM-01.1" + ], + "3.1.2.3.b": [ + "PRM-01.1" + ], + "3.1.2.3.c": [ + "PRM-01.1" + ], + "3.1.1.10": [ + "PRM-03" + ], + "3.1.5": [ + "PRM-04", + "PRM-07" + ], + "3.1.5.2": [ + "PRM-04" + ], + "3.1.5.2.a": [ + "PRM-04" + ], + "3.1.5.2.b": [ + "PRM-04" + ], + "3.1.5.2.c": [ + "PRM-04" + ], + "3.1.5.2.d": [ + "PRM-04" + ], + "3.1.5.2.e": [ + "PRM-04" + ], + "3.1.5.2.f": [ + "PRM-04" + ], + "3.2.1": [ + "RSK-01" + ], + "3.2.1.1-1": [ + "RSK-01" + ], + "3.2.1.2-1": [ + "RSK-01" + ], + "3.2.1.3-1": [ + "RSK-01" + ], + "3.2.1.4-1": [ + "RSK-01" + ], + "3.2.1.5": [ + "RSK-01" + ], + "3.2.1.5.a": [ + "RSK-01" + ], + "3.2.1.5.b": [ + "RSK-01" + ], + "3.2.1.5.c": [ + "RSK-01" + ], + "3.2.1.6": [ + "RSK-01" + ], + "3.2.1.6.a": [ + "RSK-01" + ], + "3.2.1.6.b": [ + "RSK-01" + ], + "3.2.1.6.c": [ + "RSK-01" + ], + "3.2.1.6.d": [ + "RSK-01" + ], + "3.2.1.7": [ + "RSK-01" + ], + "3.2.1.8": [ + "RSK-01" + ], + "3.2.1.8.a": [ + "RSK-01" + ], + "3.2.1.8.b": [ + "RSK-01" + ], + "3.2.1.8.c": [ + "RSK-01" + ], + "3.2.1.8.d": [ + "RSK-01" + ], + "3.2.1.11": [ + "RSK-01.3", + "RSK-01.5" + ], + "3.2.1.4-1.a": [ + "RSK-03" + ], + "3.2.1.1-2": [ + "RSK-03" + ], + "3.2.1.1-2.1": [ + "RSK-03" + ], + "3.2.1.1-2.3": [ + "RSK-03" + ], + "3.2.1.1-2.2": [ + "RSK-03.1", + "RSK-04.1" + ], + "3.2.1.4-1.b": [ + "RSK-04" + ], + "3.2.1.2-2": [ + "RSK-04" + ], + "3.2.1.2-2.1": [ + "RSK-04" + ], + "3.2.1.2-2.2": [ + "RSK-04" + ], + "3.2.1.4-1.c": [ + "RSK-04.1" + ], + "3.2.1.9": [ + "RSK-04.4" + ], + "3.2.1.3-2": [ + "RSK-06" + ], + "3.2.1.3-2.1": [ + "RSK-06" + ], + "3.2.1.4-1.d": [ + "RSK-06.1", + "RSK-11" + ], + "3.2.1.3-2.6": [ + "RSK-06.2" + ], + "3.2.1.3-2.6.a": [ + "RSK-06.2" + ], + "3.2.1.3-2.6.b": [ + "RSK-06.2" + ], + "3.2.1.3-2.6.b.1": [ + "RSK-06.2" + ], + "3.2.1.3-2.6.b.2": [ + "RSK-06.2" + ], + "3.2.1.3-2.6.b.3": [ + "RSK-06.2" + ], + "3.2.1.3-2.6.c": [ + "RSK-06.2" + ], + "3.2.1.3-2.6.d": [ + "RSK-06.2" + ], + "3.2.1.10": [ + "RSK-06.3", + "RSK-13" + ], + "3.2.1.3-2.3": [ + "RSK-06.3" + ], + "3.2.1.3-2.3.a": [ + "RSK-06.3" + ], + "3.2.1.3-2.3.b": [ + "RSK-06.3" + ], + "3.2.1.3-2.3.b.1": [ + "RSK-06.3" + ], + "3.2.1.3-2.3.b.2": [ + "RSK-06.3" + ], + "3.2.1.3-2.4": [ + "RSK-06.3" + ], + "3.2.1.3-2.5": [ + "RSK-06.3" + ], + "3.2.1.3-2.5.a": [ + "RSK-06.3" + ], + "3.2.1.3-2.5.b": [ + "RSK-06.3" + ], + "3.2.1.3-2.5.c": [ + "RSK-06.3" + ], + "3.2.1.3-2.2": [ + "RSK-06.4" + ], + "3.2.1.3-2.7": [ + "RSK-06.4" + ], + "3.2.1.4-2": [ + "RSK-06.4" + ], + "3.2.1.4-2.1": [ + "RSK-06.4" + ], + "3.2.1.4-2.1.a": [ + "RSK-06.4" + ], + "3.2.1.4-2.1.b": [ + "RSK-06.4" + ], + "3.3.4": [ + "SEA-01.4" + ], + "3.3.4.1": [ + "SEA-01.4" + ], + "3.3.4.3": [ + "SEA-01.4" + ], + "3.3.4.3.a": [ + "SEA-01.4" + ], + "3.3.4.3.b": [ + "SEA-01.4" + ], + "3.3.4.3.c": [ + "SEA-01.4" + ], + "3.3.4.3.d": [ + "SEA-01.4" + ], + "3.3.4.3.e": [ + "SEA-01.4" + ], + "3.1.6": [ + "SAT-01" + ], + "3.1.6.1": [ + "SAT-01" + ], + "3.1.6.2": [ + "SAT-01" + ], + "3.1.6.2.a": [ + "SAT-01" + ], + "3.1.6.2.b": [ + "SAT-01" + ], + "3.1.6.2.c": [ + "SAT-01" + ], + "3.1.6.3": [ + "SAT-01" + ], + "3.1.6.4": [ + "SAT-01" + ], + "3.1.6.5": [ + "SAT-01" + ], + "3.1.6.5.a": [ + "SAT-01" + ], + "3.1.6.5.b": [ + "SAT-01" + ], + "3.1.6.5.c": [ + "SAT-01" + ], + "3.1.6.6": [ + "SAT-01.1" + ], + "3.1.6.6.a": [ + "SAT-01.1" + ], + "3.1.6.6.b": [ + "SAT-01.1" + ], + "3.1.6.7": [ + "SAT-02" + ], + "3.1.7": [ + "SAT-02" + ], + "3.1.7.1": [ + "SAT-03" + ], + "3.1.7.1.a": [ + "SAT-03" + ], + "3.1.7.1.b": [ + "SAT-03" + ], + "3.1.7.1.c": [ + "SAT-03" + ], + "3.1.7.1.d": [ + "SAT-03" + ], + "3.1.7.2": [ + "SAT-03" + ], + "3.3.6.4": [ + "TDA-06" + ], + "3.3.6.5": [ + "TDA-06" + ], + "3.3.6.5.a": [ + "TDA-06" + ], + "3.3.6.5.b": [ + "TDA-06" + ], + "3.3.6.5.c": [ + "TDA-06" + ], + "3.3.6.5.d": [ + "TDA-06" + ], + "3.3.6.5.e": [ + "TDA-06" + ], + "3.3.6.5.f": [ + "TDA-06" + ], + "3.3.6.5.g": [ + "TDA-06" + ], + "3.3.7.4.g": [ + "TDA-08" + ], + "3.4.1": [ + "TPM-01" + ], + "3.4.1.1": [ + "TPM-01" + ], + "3.4.1.4": [ + "TPM-01" + ], + "3.4.1.4.a": [ + "TPM-01" + ], + "3.4.1.6": [ + "TPM-01" + ], + "3.4.1.6.a": [ + "TPM-01" + ], + "3.4.2.1": [ + "TPM-01" + ], + "3.4.1.4.b": [ + "TPM-05" + ], + "3.4.1.4.c": [ + "TPM-05" + ], + "3.4.1.5": [ + "TPM-05" + ], + "3.4.1.5.a": [ + "TPM-05" + ], + "3.4.1.5.b": [ + "TPM-05" + ], + "3.4.1.5.c": [ + "TPM-05" + ], + "3.4.1.5.d": [ + "TPM-05" + ], + "3.4.1.5.e": [ + "TPM-05" + ], + "3.4.1.5.f": [ + "TPM-05" + ], + "3.4.1.5.g": [ + "TPM-05" + ], + "3.3.11.6": [ + "TPM-08" + ], + "3.3.16.1": [ + "THR-01" + ], + "3.3.16.3": [ + "THR-01" + ], + "3.3.16.3.a": [ + "THR-01" + ], + "3.3.16.3.c": [ + "THR-01" + ], + "3.3.16.3.d": [ + "THR-01" + ], + "3.3.16.3.e": [ + "THR-01" + ], + "3.3.16.3.b": [ + "THR-03" + ], + "3.3.16.3.f": [ + "THR-03.1" + ], + "3.3.17": [ + "VPM-01" + ], + "3.3.17.1": [ + "VPM-01" + ], + "3.3.17.3": [ + "VPM-01" + ], + "3.3.17.3.a": [ + "VPM-01" + ], + "3.3.17.3.b": [ + "VPM-01" + ], + "3.3.17.3.c": [ + "VPM-01" + ], + "3.3.17.3.d": [ + "VPM-01" + ], + "3.3.17.3.e": [ + "VPM-01" + ], + "3.3.17.3.f": [ "VPM-01" ] } diff --git a/docs/api/crosswalks/emea-srb-act-9-2018.json b/docs/api/crosswalks/emea-srb-act-9-2018.json index 7ddf4bf7..f24827c5 100644 --- a/docs/api/crosswalks/emea-srb-act-9-2018.json +++ b/docs/api/crosswalks/emea-srb-act-9-2018.json @@ -1,1150 +1,1406 @@ { "framework_id": "emea-srb-act-9-2018", - "display_name": "Serbia - Act of 9 November 2018 on Personal Data Protection", + "display_name": "Serbia - Act of 9 November 2018 on Personal Data Protection (Official Gazette No. 87/18)", "scf_to_framework": { - "total_mappings": 56, + "total_mappings": 31, "mappings": { - "GOV-15": [ - "50", - "51" - ], - "GOV-15.1": [ - "50", - "51" - ], - "GOV-15.2": [ - "50", - "51" - ], - "GOV-15.3": [ - "50", - "51" - ], - "GOV-15.5": [ - "50", - "51" - ], "CPL-01": [ - "5.1", - "13", - "49", - "59" - ], - "DCH-01": [ - "65" - ], - "DCH-13.1": [ - "5.1" + "IV.1.49" ], - "DCH-14.2": [ - "64", - "64.1", - "64.2", - "64.3", - "64.4" - ], - "DCH-18": [ - "5.5" - ], - "DCH-18.2": [ - "5.1" + "CPL-08": [ + "IV.1.44" ], "DCH-23": [ - "50.1" - ], - "DCH-25": [ - "23", - "63", - "63.1", - "63.2", - "63.3", - "63.4", - "65", - "68", - "69", - "69.x", - "70", - "70.1", - "70.2", - "70.3", - "70.4", - "70.5", - "71", - "71.1", - "71.2", - "71.3", - "71.4", - "71.5" - ], - "IRO-04.1": [ - "53", - "53.1", - "53.2", - "53.3" - ], - "IRO-10.2": [ - "52", - "52.1", - "52.2", - "52.3", - "52.4" - ], - "IAO-03.2": [ - "5", - "11" - ], - "PRI-01": [ - "5.1", - "59", - "59.1", - "59.2", - "59.3", - "59.4", - "59.5", - "59.6", - "59.7", - "59.8", - "59.9", - "59.10", - "59.11" + "IV.2.50(1)" + ], + "IRO-10": [ + "IV.2.52", + "IV.2.52(1)", + "IV.2.52(2)", + "IV.2.52(3)", + "IV.2.52(4)", + "IV.2.53" ], "PRI-01.4": [ - "44", - "44.1", - "44.2", - "56", - "56.1", - "56.2", - "56.3", - "57", - "58", - "58.1", - "58.2", - "58.3", - "58.4" + "IV.4.56", + "IV.4.56(1)", + "IV.4.56(2)", + "IV.4.56(3)", + "IV.4.57", + "IV.4.58", + "IV.4.58(1)", + "IV.4.58(2)", + "IV.4.58(3)", + "IV.4.58(4)" ], "PRI-01.5": [ - "65", - "65.x", - "66", - "67", - "67.x" + "V.63", + "V.63(1)", + "V.63(2)", + "V.63(3)", + "V.63(4)", + "V.64", + "V.64(1)", + "V.64(2)", + "V.64(3)", + "V.65-1", + "V.65-1(1)", + "V.65-1(2)", + "V.65-1(3)", + "V.65-1(4)", + "V.65-1(5)", + "V.65-2", + "V.65-2(1)", + "V.65-2(2)", + "V.66", + "V.66(1)", + "V.66(2)", + "V.67-1", + "V.67-1(1)", + "V.67-1(2)", + "V.67-1(3)", + "V.67-2", + "V.67-2(1)", + "V.67-2(2)", + "V.67-2(3)", + "V.67-2(4)", + "V.67-2(5)", + "V.67-2(6)", + "V.67-2(7)", + "V.67-2(8)", + "V.67-2(9)", + "V.67-2(10)", + "V.67-2(11)", + "V.67-2(12)", + "V.67-2(13)", + "V.67-2(14)", + "V.68", + "V.69-1", + "V.69-1(1)", + "V.69-1(2)", + "V.69-1(3)", + "V.69-1(4)", + "V.69-1(5)", + "V.69-1(6)", + "V.69-1(7)", + "V.69-2", + "V.69-2(1)", + "V.69-2(2)", + "V.69-2(3)", + "V.69-2(4)", + "V.70", + "V.70(1)", + "V.70(2)", + "V.70(3)", + "V.70(4)", + "V.70(5)", + "V.71", + "V.71(1)", + "V.71(2)", + "V.71(3)", + "V.71(4)", + "V.71(5)", + "V.72", + "V.72(1)", + "V.72(2)", + "V.72(3)", + "V.72(4)" ], "PRI-01.6": [ - "5.6", - "41", - "42", - "42.1", - "42.2", - "50", - "50.1", - "50.2", - "50.3", - "50.4", - "51", - "51.1", - "51.2", - "51.3", - "51.4", - "51.5", - "51.6", - "51.7", - "51.8", - "51.9", - "51.10" - ], - "PRI-01.7": [ - "33" + "II.6(5)", + "II.8", + "IV.1.41", + "IV.1.42", + "IV.1.42(1)", + "IV.1.42(2)", + "IV.2.50", + "IV.2.50(2)", + "IV.2.50(3)", + "IV.2.50(4)", + "IV.2.51", + "IV.2.51(1)", + "IV.2.51(2)", + "IV.2.51(3)", + "IV.2.51(4)", + "IV.2.51(5)", + "IV.2.51(6)", + "IV.2.51(7)", + "IV.2.51(8)", + "IV.2.51(9)", + "IV.2.51(10)" + ], + "PRI-01.11": [ + "II.5", + "II.5(1)", + "II.5(2)", + "II.5(3)", + "II.5(4)", + "II.5(5)", + "II.5(6)", + "II.6", + "II.12", + "III.1.21(1)", + "III.1.22(1)", + "III.2.24-4", + "III.2.24-4(1)", + "III.2.24-4(2)", + "III.2.24-4(3)", + "III.2.24-4(4)", + "III.2.25-1", + "III.2.25-1(1)", + "III.2.25-1(2)", + "III.2.25-1(3)", + "III.2.25-1(4)", + "III.2.25-1(5)", + "III.2.25-2", + "III.2.25-2(1)", + "III.2.25-2(2)", + "III.2.25-2(3)", + "III.2.25-2(4)", + "III.2.25-3", + "III.2.25-3(1)", + "III.2.25-3(2)", + "III.2.25-3(3)", + "III.2.25-3(4)", + "III.2.25-3(5)", + "III.2.28", + "III.2.28(1)", + "III.2.28(2)", + "III.2.28(3)", + "III.2.28(4)", + "III.2.28(5)", + "III.3.31(1)", + "III.3.31(2)", + "III.3.31(3)", + "III.3.31(4)", + "III.3.32(1)", + "III.3.32(2)", + "III.3.34(1)", + "III.3.34(2)", + "III.3.34(3)", + "III.3.34(4)", + "III.3.34(5)", + "III.4.38(1)", + "III.4.38(2)", + "III.4.38(3)" ], "PRI-02": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" - ], - "PRI-02.1": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" - ], - "PRI-02.2": [ - "38", - "38.1", - "38.2", - "38.3", - "39" + "III.1.21", + "III.2.23-1", + "III.2.23-1(1)", + "III.2.23-1(2)", + "III.2.23-1(3)", + "III.2.23-1(4)", + "III.2.23-1(5)", + "III.2.23-1(6)", + "III.2.23-2", + "III.2.23-2(1)", + "III.2.23-2(2)", + "III.2.23-2(3)", + "III.2.23-2(4)", + "III.2.23-2(5)", + "III.2.23-2(6)", + "III.2.24-1", + "III.2.24-1(1)", + "III.2.24-1(2)", + "III.2.24-1(3)", + "III.2.24-1(4)", + "III.2.24-1(5)", + "III.2.24-1(6)", + "III.2.24-2", + "III.2.24-2(1)", + "III.2.24-2(2)", + "III.2.24-2(3)", + "III.2.24-2(4)", + "III.2.24-2(5)", + "III.2.24-2(6)", + "III.2.24-2(7)", + "III.2.24-3", + "III.2.24-3(1)", + "III.2.24-3(2)", + "III.2.24-3(3)" ], "PRI-03": [ - "12.1", - "15", - "31", - "31.1", - "31.2", - "31.3", - "31.4" - ], - "PRI-03.1": [ - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "II.15", + "III.3.31" ], "PRI-03.3": [ - "37" + "II.16" ], "PRI-03.4": [ - "15", - "37" - ], - "PRI-04": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "16" + "III.3.30-1(2)", + "III.4.37" ], "PRI-04.1": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "7", - "7.1", - "7.2", - "14", - "20" - ], - "PRI-04.4": [ - "20" + "II.14" ], "PRI-05": [ - "5.5", - "8" - ], - "PRI-05.1": [ - "5.1", - "5.3", - "7", - "7.1", - "7.2", - "20" + "II.8", + "III.3.30-1(1)" ], "PRI-05.2": [ - "5.4" + "II.11" ], "PRI-05.4": [ - "5.1", - "5.3", - "17", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5", - "17.6", - "17.7", - "17.8", - "17.9", - "17.10", - "18.1", - "18.2", - "18.3", - "19" - ], - "PRI-05.7": [ - "9", - "9.1", - "9.2", - "9.3", - "9.4", - "9.5", - "10", - "13" + "II.6(1)", + "II.6(2)", + "II.6(3)", + "II.6(4)", + "II.6(5)", + "II.7", + "II.7(1)", + "II.7(2)", + "II.12", + "II.12(1)", + "II.12(2)", + "II.12(3)", + "II.12(4)", + "II.12(5)", + "II.12(6)", + "II.13", + "II.17", + "II.17(1)", + "II.17(2)", + "II.17(3)", + "II.17(4)", + "II.17(5)", + "II.17(6)", + "II.17(7)", + "II.17(8)", + "II.17(9)", + "II.17(10)", + "II.18", + "II.18(1)", + "II.18(2)", + "II.18(3)", + "II.19", + "II.20", + "IV.1.46", + "IV.1.47-1", + "IV.1.47-1(1)", + "IV.1.47-1(2)", + "IV.1.47-1(3)", + "IV.1.47-1(4)", + "IV.1.47-1(5)", + "IV.1.47-1(6)", + "IV.1.47-1(7)" ], "PRI-06": [ - "21", - "23", - "24", - "25", - "26", - "28.1", - "28.2", - "28.3", - "28.4", - "28.5" + "III.2.26", + "III.2.26(1)", + "III.2.26(2)", + "III.2.26(3)", + "III.2.26(4)", + "III.2.26(5)", + "III.2.26(6)", + "III.2.26(7)", + "III.2.26(8)", + "III.2.27", + "III.2.27(1)", + "III.2.27(2)", + "III.2.27(3)", + "III.2.27(4)", + "III.2.27(5)", + "III.2.27(6)", + "III.2.27(7)" ], "PRI-06.1": [ - "5.4", - "11", - "29" - ], - "PRI-06.2": [ - "34", - "34.1", - "34.2", - "34.3", - "34.4", - "34.5" + "III.3.29" ], "PRI-06.4": [ - "21", - "21.1", - "21.2", - "22", - "22.1", - "22.2", - "23", - "23.x", - "24", - "24.x", - "25", - "25.x", - "26", - "26.1", - "26.2", - "26.3", - "26.4", - "26.5", - "26.6", - "26.7", - "26.8", - "27.1", - "27.2", - "27.3", - "27.4", - "27.5", - "27.6", - "27.7" + "III.1.22", + "III.3.34" ], "PRI-06.5": [ - "30", - "30.x", - "32", - "32.1", - "32.2" + "III.3.30-1", + "III.3.32" ], "PRI-06.6": [ - "21", - "22", - "36", - "36.1", - "36.2" - ], - "PRI-06.7": [ - "21", - "22" - ], - "PRI-07": [ - "5" + "III.3.36" ], "PRI-07.1": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "45", - "45.x", - "46" + "IV.1.45-1", + "IV.1.45-1(1)", + "IV.1.45-1(2)", + "IV.1.45-1(3)", + "IV.1.45-1(4)", + "IV.1.45-1(5)", + "IV.1.45-1(6)", + "IV.1.45-1(7)", + "IV.1.45-1(8)", + "IV.1.45-2", + "IV.1.45-2(1)", + "IV.1.45-2(2)", + "IV.1.45-2(3)", + "IV.1.45-2(4)", + "IV.1.45-2(5)", + "IV.1.45-2(6)" ], "PRI-07.2": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "43" + "IV.1.43" ], "PRI-07.3": [ - "30", - "30.x", - "32", - "32.1", - "32.2", - "33" - ], - "PRI-07.4": [ - "21.2", - "22.2" + "II.11" ], "PRI-07.5": [ - "21.2", - "22.2" - ], - "PRI-10": [ - "5.4", - "11" + "III.1.21(2)", + "III.1.22(2)" ], "PRI-14": [ - "47", - "47.x", - "48", - "52", - "52.1", - "52.2", - "52.3", - "52.4" - ], - "PRI-14.1": [ - "33" + "II.15", + "IV.1.47-2", + "IV.1.47-2(1)", + "IV.1.47-2(2)", + "IV.1.47-2(3)", + "IV.1.47-2(4)", + "IV.1.47-2(5)", + "IV.1.47-2(6)", + "IV.1.47-2(7)", + "IV.1.47-2(8)", + "IV.1.47-2(9)", + "IV.1.47-3", + "IV.1.47-3(1)", + "IV.1.47-3(2)", + "IV.1.47-3(3)", + "IV.1.47-3(4)", + "IV.1.47-4", + "IV.1.47-4(1)", + "IV.1.47-4(2)", + "IV.1.47-4(3)", + "IV.1.47-4(4)" ], "PRI-14.2": [ - "33", - "35" + "III.3.33" ], - "RSK-10": [ - "54", - "54.x" + "PRI-17": [ + "III.3.34" ], - "TPM-05": [ - "5", - "11" + "PRI-19": [ + "III.4.39" ], - "TPM-05.2": [ - "5", - "11" + "PRI-19.2": [ + "III.4.38" + ], + "RSK-10": [ + "IV.3.54-1", + "IV.3.54-1(1)", + "IV.3.54-1(2)", + "IV.3.54-1(3)", + "IV.3.54-2", + "IV.3.54-2(1)", + "IV.3.54-2(2)", + "IV.3.54-2(3)", + "IV.3.54-2(4)", + "IV.3.55-1", + "IV.3.55-1(1)", + "IV.3.55-1(2)", + "IV.3.55-2", + "IV.3.55-2(1)", + "IV.3.55-2(2)", + "IV.3.55-2(3)", + "IV.3.55-2(4)", + "IV.3.55-2(5)", + "IV.3.55-2(6)" ] } }, "framework_to_scf": { - "total_mappings": 205, + "total_mappings": 330, "mappings": { - "5": [ - "IAO-03.2", - "PRI-07", - "PRI-07.1", - "PRI-07.2", - "TPM-05", - "TPM-05.2" - ], - "7": [ - "PRI-04.1", - "PRI-05.1" - ], - "8": [ - "PRI-05" - ], - "9": [ - "PRI-05.7" - ], - "10": [ - "PRI-05.7" - ], - "11": [ - "IAO-03.2", - "PRI-06.1", - "PRI-07.1", - "PRI-07.2", - "PRI-10", - "TPM-05", - "TPM-05.2" - ], - "13": [ - "CPL-01", - "PRI-05.7" - ], - "14": [ - "PRI-04.1" - ], - "15": [ - "PRI-03", - "PRI-03.4" - ], - "16": [ - "PRI-04" - ], - "17": [ - "PRI-05.4" - ], - "19": [ - "PRI-05.4" - ], - "20": [ - "PRI-04.1", - "PRI-04.4", - "PRI-05.1" - ], - "21": [ - "PRI-06", - "PRI-06.4", - "PRI-06.6", - "PRI-06.7" + "IV.1.49": [ + "CPL-01" ], - "22": [ - "PRI-06.4", - "PRI-06.6", - "PRI-06.7" + "IV.1.44": [ + "CPL-08" ], - "23": [ - "DCH-25", - "PRI-06", - "PRI-06.4" + "IV.2.50(1)": [ + "DCH-23" ], - "24": [ - "PRI-06", - "PRI-06.4" + "IV.2.52": [ + "IRO-10" ], - "25": [ - "PRI-06", - "PRI-06.4" + "IV.2.52(1)": [ + "IRO-10" ], - "26": [ - "PRI-06", - "PRI-06.4" + "IV.2.52(2)": [ + "IRO-10" ], - "29": [ - "PRI-06.1" + "IV.2.52(3)": [ + "IRO-10" ], - "30": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "IV.2.52(4)": [ + "IRO-10" ], - "31": [ - "PRI-03", - "PRI-03.1" + "IV.2.53": [ + "IRO-10" ], - "32": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "IV.4.56": [ + "PRI-01.4" ], - "33": [ - "PRI-01.7", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3", - "PRI-14.1", - "PRI-14.2" + "IV.4.56(1)": [ + "PRI-01.4" ], - "34": [ - "PRI-06.2" + "IV.4.56(2)": [ + "PRI-01.4" ], - "35": [ - "PRI-14.2" + "IV.4.56(3)": [ + "PRI-01.4" ], - "36": [ - "PRI-06.6" + "IV.4.57": [ + "PRI-01.4" ], - "37": [ - "PRI-03.3", - "PRI-03.4" + "IV.4.58": [ + "PRI-01.4" ], - "38": [ - "PRI-02.2" + "IV.4.58(1)": [ + "PRI-01.4" ], - "39": [ - "PRI-02.2" + "IV.4.58(2)": [ + "PRI-01.4" ], - "41": [ - "PRI-01.6" + "IV.4.58(3)": [ + "PRI-01.4" ], - "42": [ - "PRI-01.6" + "IV.4.58(4)": [ + "PRI-01.4" ], - "43": [ - "PRI-07.2" + "V.63": [ + "PRI-01.5" ], - "44": [ - "PRI-01.4" + "V.63(1)": [ + "PRI-01.5" ], - "45": [ - "PRI-07.1" + "V.63(2)": [ + "PRI-01.5" ], - "46": [ - "PRI-07.1" + "V.63(3)": [ + "PRI-01.5" ], - "47": [ - "PRI-14" + "V.63(4)": [ + "PRI-01.5" ], - "48": [ - "PRI-14" + "V.64": [ + "PRI-01.5" ], - "49": [ - "CPL-01" + "V.64(1)": [ + "PRI-01.5" ], - "50": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.5", - "PRI-01.6" + "V.64(2)": [ + "PRI-01.5" ], - "51": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.5", - "PRI-01.6" + "V.64(3)": [ + "PRI-01.5" ], - "52": [ - "IRO-10.2", - "PRI-14" + "V.65-1": [ + "PRI-01.5" ], - "53": [ - "IRO-04.1" + "V.65-1(1)": [ + "PRI-01.5" ], - "54": [ - "RSK-10" + "V.65-1(2)": [ + "PRI-01.5" ], - "56": [ - "PRI-01.4" + "V.65-1(3)": [ + "PRI-01.5" ], - "57": [ - "PRI-01.4" + "V.65-1(4)": [ + "PRI-01.5" ], - "58": [ - "PRI-01.4" + "V.65-1(5)": [ + "PRI-01.5" ], - "59": [ - "CPL-01", - "PRI-01" + "V.65-2": [ + "PRI-01.5" ], - "63": [ - "DCH-25" + "V.65-2(1)": [ + "PRI-01.5" ], - "64": [ - "DCH-14.2" + "V.65-2(2)": [ + "PRI-01.5" ], - "65": [ - "DCH-01", - "DCH-25", + "V.66": [ "PRI-01.5" ], - "66": [ + "V.66(1)": [ "PRI-01.5" ], - "67": [ + "V.66(2)": [ "PRI-01.5" ], - "68": [ - "DCH-25" + "V.67-1": [ + "PRI-01.5" ], - "69": [ - "DCH-25" + "V.67-1(1)": [ + "PRI-01.5" ], - "70": [ - "DCH-25" + "V.67-1(2)": [ + "PRI-01.5" ], - "71": [ - "DCH-25" + "V.67-1(3)": [ + "PRI-01.5" ], - "5.1": [ - "CPL-01", - "DCH-13.1", - "DCH-18.2", - "PRI-01", - "PRI-02", - "PRI-02.1", - "PRI-04", - "PRI-04.1", - "PRI-05.1", - "PRI-05.4" + "V.67-2": [ + "PRI-01.5" ], - "64.1": [ - "DCH-14.2" + "V.67-2(1)": [ + "PRI-01.5" ], - "64.2": [ - "DCH-14.2" + "V.67-2(2)": [ + "PRI-01.5" ], - "64.3": [ - "DCH-14.2" + "V.67-2(3)": [ + "PRI-01.5" ], - "64.4": [ - "DCH-14.2" + "V.67-2(4)": [ + "PRI-01.5" ], - "5.5": [ - "DCH-18", - "PRI-05" + "V.67-2(5)": [ + "PRI-01.5" ], - "50.1": [ - "DCH-23", - "PRI-01.6" + "V.67-2(6)": [ + "PRI-01.5" ], - "63.1": [ - "DCH-25" + "V.67-2(7)": [ + "PRI-01.5" ], - "63.2": [ - "DCH-25" + "V.67-2(8)": [ + "PRI-01.5" ], - "63.3": [ - "DCH-25" + "V.67-2(9)": [ + "PRI-01.5" ], - "63.4": [ - "DCH-25" + "V.67-2(10)": [ + "PRI-01.5" ], - "69.x": [ - "DCH-25" + "V.67-2(11)": [ + "PRI-01.5" ], - "70.1": [ - "DCH-25" + "V.67-2(12)": [ + "PRI-01.5" ], - "70.2": [ - "DCH-25" + "V.67-2(13)": [ + "PRI-01.5" ], - "70.3": [ - "DCH-25" + "V.67-2(14)": [ + "PRI-01.5" ], - "70.4": [ - "DCH-25" + "V.68": [ + "PRI-01.5" ], - "70.5": [ - "DCH-25" + "V.69-1": [ + "PRI-01.5" ], - "71.1": [ - "DCH-25" + "V.69-1(1)": [ + "PRI-01.5" ], - "71.2": [ - "DCH-25" + "V.69-1(2)": [ + "PRI-01.5" ], - "71.3": [ - "DCH-25" + "V.69-1(3)": [ + "PRI-01.5" ], - "71.4": [ - "DCH-25" + "V.69-1(4)": [ + "PRI-01.5" ], - "71.5": [ - "DCH-25" + "V.69-1(5)": [ + "PRI-01.5" ], - "53.1": [ - "IRO-04.1" + "V.69-1(6)": [ + "PRI-01.5" ], - "53.2": [ - "IRO-04.1" + "V.69-1(7)": [ + "PRI-01.5" ], - "53.3": [ - "IRO-04.1" + "V.69-2": [ + "PRI-01.5" ], - "52.1": [ - "IRO-10.2", - "PRI-14" + "V.69-2(1)": [ + "PRI-01.5" ], - "52.2": [ - "IRO-10.2", - "PRI-14" + "V.69-2(2)": [ + "PRI-01.5" ], - "52.3": [ - "IRO-10.2", - "PRI-14" + "V.69-2(3)": [ + "PRI-01.5" ], - "52.4": [ - "IRO-10.2", - "PRI-14" + "V.69-2(4)": [ + "PRI-01.5" ], - "59.1": [ - "PRI-01" + "V.70": [ + "PRI-01.5" ], - "59.2": [ - "PRI-01" + "V.70(1)": [ + "PRI-01.5" ], - "59.3": [ - "PRI-01" + "V.70(2)": [ + "PRI-01.5" ], - "59.4": [ - "PRI-01" + "V.70(3)": [ + "PRI-01.5" ], - "59.5": [ - "PRI-01" + "V.70(4)": [ + "PRI-01.5" ], - "59.6": [ - "PRI-01" + "V.70(5)": [ + "PRI-01.5" ], - "59.7": [ - "PRI-01" + "V.71": [ + "PRI-01.5" ], - "59.8": [ - "PRI-01" + "V.71(1)": [ + "PRI-01.5" ], - "59.9": [ - "PRI-01" + "V.71(2)": [ + "PRI-01.5" ], - "59.10": [ - "PRI-01" + "V.71(3)": [ + "PRI-01.5" ], - "59.11": [ - "PRI-01" + "V.71(4)": [ + "PRI-01.5" ], - "44.1": [ - "PRI-01.4" + "V.71(5)": [ + "PRI-01.5" ], - "44.2": [ - "PRI-01.4" + "V.72": [ + "PRI-01.5" ], - "56.1": [ - "PRI-01.4" + "V.72(1)": [ + "PRI-01.5" ], - "56.2": [ - "PRI-01.4" + "V.72(2)": [ + "PRI-01.5" ], - "56.3": [ - "PRI-01.4" + "V.72(3)": [ + "PRI-01.5" ], - "58.1": [ - "PRI-01.4" + "V.72(4)": [ + "PRI-01.5" ], - "58.2": [ - "PRI-01.4" + "II.6(5)": [ + "PRI-01.6", + "PRI-05.4" ], - "58.3": [ - "PRI-01.4" + "II.8": [ + "PRI-01.6", + "PRI-05" ], - "58.4": [ - "PRI-01.4" + "IV.1.41": [ + "PRI-01.6" ], - "65.x": [ - "PRI-01.5" + "IV.1.42": [ + "PRI-01.6" ], - "67.x": [ - "PRI-01.5" + "IV.1.42(1)": [ + "PRI-01.6" ], - "5.6": [ + "IV.1.42(2)": [ "PRI-01.6" ], - "42.1": [ + "IV.2.50": [ "PRI-01.6" ], - "42.2": [ + "IV.2.50(2)": [ "PRI-01.6" ], - "50.2": [ + "IV.2.50(3)": [ "PRI-01.6" ], - "50.3": [ + "IV.2.50(4)": [ "PRI-01.6" ], - "50.4": [ + "IV.2.51": [ "PRI-01.6" ], - "51.1": [ + "IV.2.51(1)": [ "PRI-01.6" ], - "51.2": [ + "IV.2.51(2)": [ "PRI-01.6" ], - "51.3": [ + "IV.2.51(3)": [ "PRI-01.6" ], - "51.4": [ + "IV.2.51(4)": [ "PRI-01.6" ], - "51.5": [ + "IV.2.51(5)": [ "PRI-01.6" ], - "51.6": [ + "IV.2.51(6)": [ "PRI-01.6" ], - "51.7": [ + "IV.2.51(7)": [ "PRI-01.6" ], - "51.8": [ + "IV.2.51(8)": [ "PRI-01.6" ], - "51.9": [ + "IV.2.51(9)": [ "PRI-01.6" ], - "51.10": [ + "IV.2.51(10)": [ "PRI-01.6" ], - "6.1": [ - "PRI-02", - "PRI-02.1", - "PRI-04", - "PRI-04.1" + "II.5": [ + "PRI-01.11" ], - "12.2": [ - "PRI-02", - "PRI-02.1" + "II.5(1)": [ + "PRI-01.11" ], - "12.3": [ - "PRI-02", - "PRI-02.1" + "II.5(2)": [ + "PRI-01.11" ], - "12.4": [ - "PRI-02", - "PRI-02.1" + "II.5(3)": [ + "PRI-01.11" ], - "12.5": [ - "PRI-02", - "PRI-02.1" + "II.5(4)": [ + "PRI-01.11" ], - "12.6": [ - "PRI-02", - "PRI-02.1" + "II.5(5)": [ + "PRI-01.11" ], - "38.1": [ - "PRI-02.2" + "II.5(6)": [ + "PRI-01.11" ], - "38.2": [ - "PRI-02.2" + "II.6": [ + "PRI-01.11" ], - "38.3": [ - "PRI-02.2" + "II.12": [ + "PRI-01.11", + "PRI-05.4" ], - "12.1": [ - "PRI-03" + "III.1.21(1)": [ + "PRI-01.11" ], - "31.1": [ - "PRI-03", - "PRI-03.1" + "III.1.22(1)": [ + "PRI-01.11" ], - "31.2": [ - "PRI-03", - "PRI-03.1" + "III.2.24-4": [ + "PRI-01.11" ], - "31.3": [ - "PRI-03", - "PRI-03.1" + "III.2.24-4(1)": [ + "PRI-01.11" + ], + "III.2.24-4(2)": [ + "PRI-01.11" + ], + "III.2.24-4(3)": [ + "PRI-01.11" + ], + "III.2.24-4(4)": [ + "PRI-01.11" + ], + "III.2.25-1": [ + "PRI-01.11" + ], + "III.2.25-1(1)": [ + "PRI-01.11" + ], + "III.2.25-1(2)": [ + "PRI-01.11" + ], + "III.2.25-1(3)": [ + "PRI-01.11" + ], + "III.2.25-1(4)": [ + "PRI-01.11" + ], + "III.2.25-1(5)": [ + "PRI-01.11" + ], + "III.2.25-2": [ + "PRI-01.11" + ], + "III.2.25-2(1)": [ + "PRI-01.11" + ], + "III.2.25-2(2)": [ + "PRI-01.11" + ], + "III.2.25-2(3)": [ + "PRI-01.11" + ], + "III.2.25-2(4)": [ + "PRI-01.11" + ], + "III.2.25-3": [ + "PRI-01.11" + ], + "III.2.25-3(1)": [ + "PRI-01.11" + ], + "III.2.25-3(2)": [ + "PRI-01.11" + ], + "III.2.25-3(3)": [ + "PRI-01.11" + ], + "III.2.25-3(4)": [ + "PRI-01.11" + ], + "III.2.25-3(5)": [ + "PRI-01.11" + ], + "III.2.28": [ + "PRI-01.11" + ], + "III.2.28(1)": [ + "PRI-01.11" + ], + "III.2.28(2)": [ + "PRI-01.11" + ], + "III.2.28(3)": [ + "PRI-01.11" + ], + "III.2.28(4)": [ + "PRI-01.11" + ], + "III.2.28(5)": [ + "PRI-01.11" + ], + "III.3.31(1)": [ + "PRI-01.11" + ], + "III.3.31(2)": [ + "PRI-01.11" + ], + "III.3.31(3)": [ + "PRI-01.11" + ], + "III.3.31(4)": [ + "PRI-01.11" + ], + "III.3.32(1)": [ + "PRI-01.11" + ], + "III.3.32(2)": [ + "PRI-01.11" + ], + "III.3.34(1)": [ + "PRI-01.11" + ], + "III.3.34(2)": [ + "PRI-01.11" + ], + "III.3.34(3)": [ + "PRI-01.11" + ], + "III.3.34(4)": [ + "PRI-01.11" + ], + "III.3.34(5)": [ + "PRI-01.11" + ], + "III.4.38(1)": [ + "PRI-01.11" + ], + "III.4.38(2)": [ + "PRI-01.11" + ], + "III.4.38(3)": [ + "PRI-01.11" + ], + "III.1.21": [ + "PRI-02" + ], + "III.2.23-1": [ + "PRI-02" + ], + "III.2.23-1(1)": [ + "PRI-02" + ], + "III.2.23-1(2)": [ + "PRI-02" + ], + "III.2.23-1(3)": [ + "PRI-02" + ], + "III.2.23-1(4)": [ + "PRI-02" + ], + "III.2.23-1(5)": [ + "PRI-02" + ], + "III.2.23-1(6)": [ + "PRI-02" + ], + "III.2.23-2": [ + "PRI-02" + ], + "III.2.23-2(1)": [ + "PRI-02" + ], + "III.2.23-2(2)": [ + "PRI-02" ], - "31.4": [ + "III.2.23-2(3)": [ + "PRI-02" + ], + "III.2.23-2(4)": [ + "PRI-02" + ], + "III.2.23-2(5)": [ + "PRI-02" + ], + "III.2.23-2(6)": [ + "PRI-02" + ], + "III.2.24-1": [ + "PRI-02" + ], + "III.2.24-1(1)": [ + "PRI-02" + ], + "III.2.24-1(2)": [ + "PRI-02" + ], + "III.2.24-1(3)": [ + "PRI-02" + ], + "III.2.24-1(4)": [ + "PRI-02" + ], + "III.2.24-1(5)": [ + "PRI-02" + ], + "III.2.24-1(6)": [ + "PRI-02" + ], + "III.2.24-2": [ + "PRI-02" + ], + "III.2.24-2(1)": [ + "PRI-02" + ], + "III.2.24-2(2)": [ + "PRI-02" + ], + "III.2.24-2(3)": [ + "PRI-02" + ], + "III.2.24-2(4)": [ + "PRI-02" + ], + "III.2.24-2(5)": [ + "PRI-02" + ], + "III.2.24-2(6)": [ + "PRI-02" + ], + "III.2.24-2(7)": [ + "PRI-02" + ], + "III.2.24-3": [ + "PRI-02" + ], + "III.2.24-3(1)": [ + "PRI-02" + ], + "III.2.24-3(2)": [ + "PRI-02" + ], + "III.2.24-3(3)": [ + "PRI-02" + ], + "II.15": [ "PRI-03", - "PRI-03.1" + "PRI-14" ], - "5.2": [ - "PRI-04", - "PRI-04.1" + "III.3.31": [ + "PRI-03" ], - "6.2": [ - "PRI-04", - "PRI-04.1" + "II.16": [ + "PRI-03.3" ], - "6.3": [ - "PRI-04", - "PRI-04.1" + "III.3.30-1(2)": [ + "PRI-03.4" ], - "6.4": [ - "PRI-04", - "PRI-04.1" + "III.4.37": [ + "PRI-03.4" ], - "6.5": [ - "PRI-04", + "II.14": [ "PRI-04.1" ], - "7.1": [ - "PRI-04.1", - "PRI-05.1" + "III.3.30-1(1)": [ + "PRI-05" ], - "7.2": [ - "PRI-04.1", - "PRI-05.1" + "II.11": [ + "PRI-05.2", + "PRI-07.3" ], - "5.3": [ - "PRI-05.1", + "II.6(1)": [ "PRI-05.4" ], - "5.4": [ - "PRI-05.2", - "PRI-06.1", - "PRI-10" + "II.6(2)": [ + "PRI-05.4" + ], + "II.6(3)": [ + "PRI-05.4" + ], + "II.6(4)": [ + "PRI-05.4" + ], + "II.7": [ + "PRI-05.4" + ], + "II.7(1)": [ + "PRI-05.4" + ], + "II.7(2)": [ + "PRI-05.4" + ], + "II.12(1)": [ + "PRI-05.4" + ], + "II.12(2)": [ + "PRI-05.4" + ], + "II.12(3)": [ + "PRI-05.4" + ], + "II.12(4)": [ + "PRI-05.4" + ], + "II.12(5)": [ + "PRI-05.4" ], - "17.1": [ + "II.12(6)": [ "PRI-05.4" ], - "17.2": [ + "II.13": [ "PRI-05.4" ], - "17.3": [ + "II.17": [ "PRI-05.4" ], - "17.4": [ + "II.17(1)": [ "PRI-05.4" ], - "17.5": [ + "II.17(2)": [ "PRI-05.4" ], - "17.6": [ + "II.17(3)": [ "PRI-05.4" ], - "17.7": [ + "II.17(4)": [ "PRI-05.4" ], - "17.8": [ + "II.17(5)": [ "PRI-05.4" ], - "17.9": [ + "II.17(6)": [ "PRI-05.4" ], - "17.10": [ + "II.17(7)": [ "PRI-05.4" ], - "18.1": [ + "II.17(8)": [ "PRI-05.4" ], - "18.2": [ + "II.17(9)": [ "PRI-05.4" ], - "18.3": [ + "II.17(10)": [ "PRI-05.4" ], - "9.1": [ - "PRI-05.7" + "II.18": [ + "PRI-05.4" + ], + "II.18(1)": [ + "PRI-05.4" + ], + "II.18(2)": [ + "PRI-05.4" + ], + "II.18(3)": [ + "PRI-05.4" + ], + "II.19": [ + "PRI-05.4" + ], + "II.20": [ + "PRI-05.4" + ], + "IV.1.46": [ + "PRI-05.4" + ], + "IV.1.47-1": [ + "PRI-05.4" + ], + "IV.1.47-1(1)": [ + "PRI-05.4" + ], + "IV.1.47-1(2)": [ + "PRI-05.4" + ], + "IV.1.47-1(3)": [ + "PRI-05.4" ], - "9.2": [ - "PRI-05.7" + "IV.1.47-1(4)": [ + "PRI-05.4" ], - "9.3": [ - "PRI-05.7" + "IV.1.47-1(5)": [ + "PRI-05.4" ], - "9.4": [ - "PRI-05.7" + "IV.1.47-1(6)": [ + "PRI-05.4" ], - "9.5": [ - "PRI-05.7" + "IV.1.47-1(7)": [ + "PRI-05.4" ], - "28.1": [ + "III.2.26": [ "PRI-06" ], - "28.2": [ + "III.2.26(1)": [ "PRI-06" ], - "28.3": [ + "III.2.26(2)": [ "PRI-06" ], - "28.4": [ + "III.2.26(3)": [ "PRI-06" ], - "28.5": [ + "III.2.26(4)": [ "PRI-06" ], - "34.1": [ - "PRI-06.2" + "III.2.26(5)": [ + "PRI-06" ], - "34.2": [ - "PRI-06.2" + "III.2.26(6)": [ + "PRI-06" ], - "34.3": [ - "PRI-06.2" + "III.2.26(7)": [ + "PRI-06" ], - "34.4": [ - "PRI-06.2" + "III.2.26(8)": [ + "PRI-06" ], - "34.5": [ - "PRI-06.2" + "III.2.27": [ + "PRI-06" ], - "21.1": [ - "PRI-06.4" + "III.2.27(1)": [ + "PRI-06" ], - "21.2": [ - "PRI-06.4", - "PRI-07.4", - "PRI-07.5" + "III.2.27(2)": [ + "PRI-06" ], - "22.1": [ - "PRI-06.4" + "III.2.27(3)": [ + "PRI-06" ], - "22.2": [ - "PRI-06.4", - "PRI-07.4", - "PRI-07.5" + "III.2.27(4)": [ + "PRI-06" ], - "23.x": [ - "PRI-06.4" + "III.2.27(5)": [ + "PRI-06" ], - "24.x": [ - "PRI-06.4" + "III.2.27(6)": [ + "PRI-06" ], - "25.x": [ - "PRI-06.4" + "III.2.27(7)": [ + "PRI-06" ], - "26.1": [ - "PRI-06.4" + "III.3.29": [ + "PRI-06.1" ], - "26.2": [ + "III.1.22": [ "PRI-06.4" ], - "26.3": [ - "PRI-06.4" + "III.3.34": [ + "PRI-06.4", + "PRI-17" ], - "26.4": [ - "PRI-06.4" + "III.3.30-1": [ + "PRI-06.5" ], - "26.5": [ - "PRI-06.4" + "III.3.32": [ + "PRI-06.5" ], - "26.6": [ - "PRI-06.4" + "III.3.36": [ + "PRI-06.6" ], - "26.7": [ - "PRI-06.4" + "IV.1.45-1": [ + "PRI-07.1" ], - "26.8": [ - "PRI-06.4" + "IV.1.45-1(1)": [ + "PRI-07.1" ], - "27.1": [ - "PRI-06.4" + "IV.1.45-1(2)": [ + "PRI-07.1" ], - "27.2": [ - "PRI-06.4" + "IV.1.45-1(3)": [ + "PRI-07.1" ], - "27.3": [ - "PRI-06.4" + "IV.1.45-1(4)": [ + "PRI-07.1" ], - "27.4": [ - "PRI-06.4" + "IV.1.45-1(5)": [ + "PRI-07.1" ], - "27.5": [ - "PRI-06.4" + "IV.1.45-1(6)": [ + "PRI-07.1" ], - "27.6": [ - "PRI-06.4" + "IV.1.45-1(7)": [ + "PRI-07.1" ], - "27.7": [ - "PRI-06.4" + "IV.1.45-1(8)": [ + "PRI-07.1" ], - "30.x": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "IV.1.45-2": [ + "PRI-07.1" ], - "32.1": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "IV.1.45-2(1)": [ + "PRI-07.1" ], - "32.2": [ - "PRI-06.5", - "PRI-07.1", - "PRI-07.2", - "PRI-07.3" + "IV.1.45-2(2)": [ + "PRI-07.1" ], - "36.1": [ - "PRI-06.6" + "IV.1.45-2(3)": [ + "PRI-07.1" ], - "36.2": [ - "PRI-06.6" + "IV.1.45-2(4)": [ + "PRI-07.1" + ], + "IV.1.45-2(5)": [ + "PRI-07.1" ], - "45.x": [ + "IV.1.45-2(6)": [ "PRI-07.1" ], - "47.x": [ + "IV.1.43": [ + "PRI-07.2" + ], + "III.1.21(2)": [ + "PRI-07.5" + ], + "III.1.22(2)": [ + "PRI-07.5" + ], + "IV.1.47-2": [ + "PRI-14" + ], + "IV.1.47-2(1)": [ + "PRI-14" + ], + "IV.1.47-2(2)": [ + "PRI-14" + ], + "IV.1.47-2(3)": [ + "PRI-14" + ], + "IV.1.47-2(4)": [ + "PRI-14" + ], + "IV.1.47-2(5)": [ + "PRI-14" + ], + "IV.1.47-2(6)": [ + "PRI-14" + ], + "IV.1.47-2(7)": [ + "PRI-14" + ], + "IV.1.47-2(8)": [ + "PRI-14" + ], + "IV.1.47-2(9)": [ + "PRI-14" + ], + "IV.1.47-3": [ + "PRI-14" + ], + "IV.1.47-3(1)": [ "PRI-14" ], - "54.x": [ + "IV.1.47-3(2)": [ + "PRI-14" + ], + "IV.1.47-3(3)": [ + "PRI-14" + ], + "IV.1.47-3(4)": [ + "PRI-14" + ], + "IV.1.47-4": [ + "PRI-14" + ], + "IV.1.47-4(1)": [ + "PRI-14" + ], + "IV.1.47-4(2)": [ + "PRI-14" + ], + "IV.1.47-4(3)": [ + "PRI-14" + ], + "IV.1.47-4(4)": [ + "PRI-14" + ], + "III.3.33": [ + "PRI-14.2" + ], + "III.4.39": [ + "PRI-19" + ], + "III.4.38": [ + "PRI-19.2" + ], + "IV.3.54-1": [ + "RSK-10" + ], + "IV.3.54-1(1)": [ + "RSK-10" + ], + "IV.3.54-1(2)": [ + "RSK-10" + ], + "IV.3.54-1(3)": [ + "RSK-10" + ], + "IV.3.54-2": [ + "RSK-10" + ], + "IV.3.54-2(1)": [ + "RSK-10" + ], + "IV.3.54-2(2)": [ + "RSK-10" + ], + "IV.3.54-2(3)": [ + "RSK-10" + ], + "IV.3.54-2(4)": [ + "RSK-10" + ], + "IV.3.55-1": [ + "RSK-10" + ], + "IV.3.55-1(1)": [ + "RSK-10" + ], + "IV.3.55-1(2)": [ + "RSK-10" + ], + "IV.3.55-2": [ + "RSK-10" + ], + "IV.3.55-2(1)": [ + "RSK-10" + ], + "IV.3.55-2(2)": [ + "RSK-10" + ], + "IV.3.55-2(3)": [ + "RSK-10" + ], + "IV.3.55-2(4)": [ + "RSK-10" + ], + "IV.3.55-2(5)": [ + "RSK-10" + ], + "IV.3.55-2(6)": [ "RSK-10" ] } diff --git a/docs/api/crosswalks/emea-tur-lppd-2016.json b/docs/api/crosswalks/emea-tur-lppd-2016.json index 62cb52b8..ce177085 100644 --- a/docs/api/crosswalks/emea-tur-lppd-2016.json +++ b/docs/api/crosswalks/emea-tur-lppd-2016.json @@ -2,112 +2,438 @@ "framework_id": "emea-tur-lppd-2016", "display_name": "Turkey - Law on the Protection of Personal Data (LPPD) (2016)", "scf_to_framework": { - "total_mappings": 17, + "total_mappings": 7, "mappings": { - "GOV-01": [ - "12" + "PRI-01.5": [ + "9(1)", + "9(2)", + "9(3)", + "9(3)(a)", + "9(3)(b)", + "9(3)(c)", + "9(3)(ç)", + "9(3)(d)", + "9(3)(e)", + "9(4)", + "9(4)(a)", + "9(4)(b)", + "9(4)(c)", + "9(4)(ç)", + "9(5)", + "9(6)", + "9(6)(a)", + "9(6)(b)", + "9(6)(c)", + "9(6)(ç)", + "9(6)(d)", + "9(6)(e)", + "9(6)(f)", + "9(7)", + "9(8)", + "9(9)", + "9(10)", + "9(11)" ], - "CPL-01": [ - "12" + "PRI-01.6": [ + "12(1)", + "12(1)(a)", + "12(1)(b)", + "12(1)(c)", + "12(2)", + "12(3)", + "12(4)", + "12(5)" ], - "CPL-02": [ - "12" + "PRI-02": [ + "10(1)", + "10(1)(a)", + "10(1)(b)", + "10(1)(c)", + "10(1)(ç)", + "10(1)(d)", + "11(1)", + "11(1)(a)", + "11(1)(b)", + "11(1)(c)", + "11(1)(ç)", + "11(1)(d)", + "11(1)(e)", + "11(1)(f)", + "11(1)(g)", + "11(1)(ğ)" ], - "DCH-01": [ - "8", - "12" + "PRI-05.4": [ + "4(1)", + "4(2)", + "4(2)(a)", + "4(2)(b)", + "4(2)(c)", + "4(2)(ç)", + "4(2)(d)", + "5(1)", + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(2)(c)", + "5(2)(ç)", + "5(2)(d)", + "5(2)(e)", + "5(2)(f)", + "6(1)", + "6(2)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "6(3)(ç)", + "6(3)(d)", + "6(3)(e)", + "6(3)(f)", + "6(3)(g)", + "6(4)", + "7(1)", + "7(2)", + "7(3)" ], - "PRI-01": [ - "Inferred", - "Expectation" + "PRI-06": [ + "13(1)", + "13(2)", + "13(3)" ], - "PRI-02": [ - "10" + "PRI-07": [ + "8(1)", + "8(2)", + "8(2)(a)", + "8(2)(b)", + "8(3)" ], - "PRI-02.1": [ - "10" + "PRI-15": [ + "16(1)", + "16(2)", + "16(3)", + "16(3)(a)", + "16(3)(b)", + "16(3)(c)", + "16(3)(ç)", + "16(3)(d)", + "16(3)(e)", + "16(3)(f)", + "16(4)", + "16(5)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 103, + "mappings": { + "9(1)": [ + "PRI-01.5" ], - "PRI-03": [ - "10" + "9(2)": [ + "PRI-01.5" ], - "PRI-04": [ - "10" + "9(3)": [ + "PRI-01.5" ], - "PRI-04.1": [ - "10" + "9(3)(a)": [ + "PRI-01.5" ], - "PRI-05": [ - "5", - "7" + "9(3)(b)": [ + "PRI-01.5" ], - "PRI-05.4": [ - "6" + "9(3)(c)": [ + "PRI-01.5" ], - "PRI-06": [ - "11" + "9(3)(ç)": [ + "PRI-01.5" ], - "PRI-15": [ - "16" + "9(3)(d)": [ + "PRI-01.5" ], - "SEA-01": [ - "8", - "12" + "9(3)(e)": [ + "PRI-01.5" ], - "SEA-02": [ - "8", - "12" + "9(4)": [ + "PRI-01.5" ], - "SEA-03": [ - "8", - "12" - ] - } - }, - "framework_to_scf": { - "total_mappings": 10, - "mappings": { - "5": [ - "PRI-05" + "9(4)(a)": [ + "PRI-01.5" + ], + "9(4)(b)": [ + "PRI-01.5" + ], + "9(4)(c)": [ + "PRI-01.5" + ], + "9(4)(ç)": [ + "PRI-01.5" + ], + "9(5)": [ + "PRI-01.5" + ], + "9(6)": [ + "PRI-01.5" + ], + "9(6)(a)": [ + "PRI-01.5" + ], + "9(6)(b)": [ + "PRI-01.5" + ], + "9(6)(c)": [ + "PRI-01.5" + ], + "9(6)(ç)": [ + "PRI-01.5" + ], + "9(6)(d)": [ + "PRI-01.5" + ], + "9(6)(e)": [ + "PRI-01.5" + ], + "9(6)(f)": [ + "PRI-01.5" + ], + "9(7)": [ + "PRI-01.5" + ], + "9(8)": [ + "PRI-01.5" + ], + "9(9)": [ + "PRI-01.5" + ], + "9(10)": [ + "PRI-01.5" + ], + "9(11)": [ + "PRI-01.5" + ], + "12(1)": [ + "PRI-01.6" + ], + "12(1)(a)": [ + "PRI-01.6" + ], + "12(1)(b)": [ + "PRI-01.6" + ], + "12(1)(c)": [ + "PRI-01.6" + ], + "12(2)": [ + "PRI-01.6" + ], + "12(3)": [ + "PRI-01.6" + ], + "12(4)": [ + "PRI-01.6" + ], + "12(5)": [ + "PRI-01.6" + ], + "10(1)": [ + "PRI-02" + ], + "10(1)(a)": [ + "PRI-02" + ], + "10(1)(b)": [ + "PRI-02" + ], + "10(1)(c)": [ + "PRI-02" + ], + "10(1)(ç)": [ + "PRI-02" + ], + "10(1)(d)": [ + "PRI-02" + ], + "11(1)": [ + "PRI-02" + ], + "11(1)(a)": [ + "PRI-02" + ], + "11(1)(b)": [ + "PRI-02" + ], + "11(1)(c)": [ + "PRI-02" + ], + "11(1)(ç)": [ + "PRI-02" + ], + "11(1)(d)": [ + "PRI-02" + ], + "11(1)(e)": [ + "PRI-02" + ], + "11(1)(f)": [ + "PRI-02" + ], + "11(1)(g)": [ + "PRI-02" + ], + "11(1)(ğ)": [ + "PRI-02" + ], + "4(1)": [ + "PRI-05.4" + ], + "4(2)": [ + "PRI-05.4" + ], + "4(2)(a)": [ + "PRI-05.4" + ], + "4(2)(b)": [ + "PRI-05.4" + ], + "4(2)(c)": [ + "PRI-05.4" + ], + "4(2)(ç)": [ + "PRI-05.4" + ], + "4(2)(d)": [ + "PRI-05.4" + ], + "5(1)": [ + "PRI-05.4" + ], + "5(2)": [ + "PRI-05.4" + ], + "5(2)(a)": [ + "PRI-05.4" + ], + "5(2)(b)": [ + "PRI-05.4" + ], + "5(2)(c)": [ + "PRI-05.4" + ], + "5(2)(ç)": [ + "PRI-05.4" + ], + "5(2)(d)": [ + "PRI-05.4" + ], + "5(2)(e)": [ + "PRI-05.4" + ], + "5(2)(f)": [ + "PRI-05.4" + ], + "6(1)": [ + "PRI-05.4" + ], + "6(2)": [ + "PRI-05.4" + ], + "6(3)": [ + "PRI-05.4" + ], + "6(3)(a)": [ + "PRI-05.4" + ], + "6(3)(b)": [ + "PRI-05.4" + ], + "6(3)(c)": [ + "PRI-05.4" + ], + "6(3)(ç)": [ + "PRI-05.4" + ], + "6(3)(d)": [ + "PRI-05.4" + ], + "6(3)(e)": [ + "PRI-05.4" + ], + "6(3)(f)": [ + "PRI-05.4" + ], + "6(3)(g)": [ + "PRI-05.4" + ], + "6(4)": [ + "PRI-05.4" + ], + "7(1)": [ + "PRI-05.4" ], - "6": [ + "7(2)": [ "PRI-05.4" ], - "7": [ - "PRI-05" + "7(3)": [ + "PRI-05.4" ], - "8": [ - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "13(1)": [ + "PRI-06" ], - "10": [ - "PRI-02", - "PRI-02.1", - "PRI-03", - "PRI-04", - "PRI-04.1" + "13(2)": [ + "PRI-06" ], - "11": [ + "13(3)": [ "PRI-06" ], - "12": [ - "GOV-01", - "CPL-01", - "CPL-02", - "DCH-01", - "SEA-01", - "SEA-02", - "SEA-03" + "8(1)": [ + "PRI-07" + ], + "8(2)": [ + "PRI-07" + ], + "8(2)(a)": [ + "PRI-07" + ], + "8(2)(b)": [ + "PRI-07" + ], + "8(3)": [ + "PRI-07" + ], + "16(1)": [ + "PRI-15" + ], + "16(2)": [ + "PRI-15" + ], + "16(3)": [ + "PRI-15" + ], + "16(3)(a)": [ + "PRI-15" + ], + "16(3)(b)": [ + "PRI-15" + ], + "16(3)(c)": [ + "PRI-15" ], - "16": [ + "16(3)(ç)": [ "PRI-15" ], - "Inferred": [ - "PRI-01" + "16(3)(d)": [ + "PRI-15" ], - "Expectation": [ - "PRI-01" + "16(3)(e)": [ + "PRI-15" + ], + "16(3)(f)": [ + "PRI-15" + ], + "16(4)": [ + "PRI-15" + ], + "16(5)": [ + "PRI-15" ] } } diff --git a/docs/api/crosswalks/emea-us-psd2-2015.json b/docs/api/crosswalks/emea-us-psd2-2015.json deleted file mode 100644 index 1aa01e01..00000000 --- a/docs/api/crosswalks/emea-us-psd2-2015.json +++ /dev/null @@ -1,166 +0,0 @@ -{ - "framework_id": "emea-us-psd2-2015", - "display_name": "EU Second Payment Services Directive (PSD2) (2015)", - "scf_to_framework": { - "total_mappings": 30, - "mappings": { - "GOV-01": [ - "3" - ], - "GOV-02": [ - "3" - ], - "GOV-03": [ - "3" - ], - "GOV-05": [ - "3" - ], - "AST-09": [ - "24" - ], - "CPL-01": [ - "3", - "29" - ], - "CPL-02": [ - "3" - ], - "CPL-03": [ - "3", - "29" - ], - "CPL-03.1": [ - "3" - ], - "CPL-03.2": [ - "3" - ], - "CPL-04": [ - "3" - ], - "MON-09": [ - "26" - ], - "CRY-01": [ - "20", - "30" - ], - "CRY-03": [ - "20", - "30" - ], - "CRY-04": [ - "20", - "30" - ], - "DCH-08": [ - "24" - ], - "DCH-09.3": [ - "24" - ], - "DCH-21": [ - "24" - ], - "IAC-01": [ - "4" - ], - "IAC-03": [ - "4" - ], - "IAC-04": [ - "25" - ], - "IAC-05": [ - "4" - ], - "IAC-06": [ - "4" - ], - "IAC-10": [ - "4" - ], - "IAC-10.1": [ - "4" - ], - "IAC-10.4": [ - "19" - ], - "IAC-10.5": [ - "19", - "22" - ], - "NET-11": [ - "22" - ], - "PRI-05": [ - "24" - ], - "WEB-06": [ - "4" - ] - } - }, - "framework_to_scf": { - "total_mappings": 10, - "mappings": { - "3": [ - "GOV-01", - "GOV-02", - "GOV-03", - "GOV-05", - "CPL-01", - "CPL-02", - "CPL-03", - "CPL-03.1", - "CPL-03.2", - "CPL-04" - ], - "4": [ - "IAC-01", - "IAC-03", - "IAC-05", - "IAC-06", - "IAC-10", - "IAC-10.1", - "WEB-06" - ], - "19": [ - "IAC-10.4", - "IAC-10.5" - ], - "20": [ - "CRY-01", - "CRY-03", - "CRY-04" - ], - "22": [ - "IAC-10.5", - "NET-11" - ], - "24": [ - "AST-09", - "DCH-08", - "DCH-09.3", - "DCH-21", - "PRI-05" - ], - "25": [ - "IAC-04" - ], - "26": [ - "MON-09" - ], - "29": [ - "CPL-01", - "CPL-03" - ], - "30": [ - "CRY-01", - "CRY-03", - "CRY-04" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/emea-zaf-popia-2013.json b/docs/api/crosswalks/emea-zaf-popia-2013.json index 1a9adae8..73ec5ed1 100644 --- a/docs/api/crosswalks/emea-zaf-popia-2013.json +++ b/docs/api/crosswalks/emea-zaf-popia-2013.json @@ -2,614 +2,1028 @@ "framework_id": "emea-zaf-popia-2013", "display_name": "South Africa - Protection of Personal Information Act (POPIA) (2013)", "scf_to_framework": { - "total_mappings": 101, + "total_mappings": 23, "mappings": { - "GOV-01": [ - "19", - "21" + "IRO-10": [ + "3.A.7.22(1)", + "3.A.7.22(1)(a)", + "3.A.7.22(1)(b)", + "3.A.7.22(2)", + "3.A.7.22(3)", + "3.A.7.22(4)", + "3.A.7.22(4)(a)", + "3.A.7.22(4)(b)", + "3.A.7.22(4)(c)", + "3.A.7.22(4)(d)", + "3.A.7.22(4)(e)", + "3.A.7.22(5)", + "3.A.7.22(5)(a)", + "3.A.7.22(5)(b)", + "3.A.7.22(5)(c)", + "3.A.7.22(5)(d)", + "3.A.7.22(6)" + ], + "PRI-01.5": [ + "9.72(1)", + "9.72(1)(a)", + "9.72(1)(a)(i)", + "9.72(1)(a)(ii)", + "9.72(1)(b)", + "9.72(1)(c)", + "9.72(1)(d)", + "9.72(1)(e)", + "9.72(1)(e)(i)", + "9.72(1)(e)(ii)", + "9.72(2)", + "9.72(2)(a)", + "9.72(2)(b)" + ], + "PRI-01.6": [ + "3.A.7.19(1)", + "3.A.7.19(1)(a)", + "3.A.7.19(1)(b)", + "3.A.7.19(2)", + "3.A.7.19(2)(a)", + "3.A.7.19(2)(b)", + "3.A.7.19(2)(c)", + "3.A.7.19(2)(d)", + "3.A.7.19(3)" + ], + "PRI-01.11": [ + "2.5(1)", + "2.5(1)(a)", + "2.5(1)(a)(i)", + "2.5(1)(a)(ii)", + "2.5(1)(b)", + "2.5(1)(c)", + "2.5(1)(d)", + "2.5(1)(e)", + "2.5(1)(e)(i)", + "2.5(1)(e)(ii)", + "2.5(1)(f)", + "2.5(1)(g)", + "2.5(1)(h)", + "2.5(1)(i)", + "3.A.2.9(1)", + "3.A.2.9(1)(a)", + "3.A.2.9(1)(b)", + "3.A.2.10", + "3.A.2.11(2)(a)", + "3.A.2.12(2)", + "3.A.2.12(2)(a)", + "3.A.2.12(2)(b)", + "3.A.2.12(2)(c)", + "3.A.2.12(2)(d)", + "3.A.2.12(2)(d)(i)", + "3.A.2.12(2)(d)(ii)", + "3.A.2.12(2)(d)(iii)", + "3.A.2.12(2)(d)(iv)", + "3.A.2.12(2)(d)(v)", + "3.A.2.12(2)(e)", + "3.A.2.12(2)(f)", + "3.A.6.17", + "3.A.6.18(1)", + "3.A.6.18(1)(a)", + "3.A.6.18(1)(b)", + "3.A.6.18(1)(c)", + "3.A.6.18(1)(d)", + "3.A.6.18(1)(e)", + "3.A.6.18(1)(f)", + "3.A.6.18(1)(g)", + "3.A.6.18(1)(h)", + "3.A.6.18(1)(h)(i)", + "3.A.6.18(1)(h)(ii)", + "3.A.6.18(1)(h)(iii)", + "3.A.6.18(1)(h)(iv)", + "3.A.6.18(1)(h)(v)", + "3.A.6.18(2)", + "3.A.6.18(2)(a)", + "3.A.6.18(2)(b)", + "3.A.6.18(3)", + "3.A.6.18(4)", + "3.A.6.18(4)(a)", + "3.A.6.18(4)(b)", + "3.A.6.18(4)(c)", + "3.A.6.18(4)(c)(i)", + "3.A.6.18(4)(c)(ii)", + "3.A.6.18(4)(c)(iii)", + "3.A.6.18(4)(c)(iv)", + "3.A.6.18(4)(d)", + "3.A.6.18(4)(e)", + "3.A.6.18(4)(f)", + "3.A.6.18(4)(f)(i)", + "3.A.6.18(4)(f)(ii)", + "3.A.7.20(1)", + "3.A.7.20(1)(a)", + "3.A.7.20(1)(b)" ], - "AST-01": [ - "19.1", - "19.2" + "PRI-02": [ + "3.A.3.13(1)", + "3.A.3.13(2)" ], - "BCD-01": [ - "19.1", - "19.2" + "PRI-03": [ + "6.57(1)", + "6.57(1)(a)", + "6.57(1)(a)(i)", + "6.57(1)(a)(ii)", + "6.57(1)(b)", + "6.57(1)(c)", + "6.57(1)(d)", + "6.57(2)", + "6.57(3)", + "6.57(4)" + ], + "PRI-03.3": [ + "3.C.34", + "3.C.35(1)", + "3.C.35(1)(a)", + "3.C.35(1)(b)", + "3.C.35(1)(c)", + "3.C.35(1)(d)", + "3.C.35(1)(d)(i)", + "3.C.35(1)(d)(ii)", + "3.C.35(1)(d)(iii)", + "3.C.35(1)(e)", + "3.C.35(2)", + "3.C.35(3)", + "3.C.35(3)(a)", + "3.C.35(3)(a)(i)", + "3.C.35(3)(a)(ii)", + "3.C.35(3)(b)", + "3.C.35(3)(b)(i)", + "3.C.35(3)(b)(ii)", + "3.C.35(3)(b)(iii)", + "3.C.35(3)(c)", + "3.C.35(3)(d)" + ], + "PRI-03.4": [ + "3.A.2.11(2)(b)", + "3.A.2.11(3)", + "3.A.2.11(3)(a)", + "3.A.2.11(3)(b)", + "3.A.2.11(4)" + ], + "PRI-03.7": [ + "3.A.2.12(1)" ], - "CAP-01": [ - "19.1", - "19.2" + "PRI-04.1": [ + "3.A.2.11(1)", + "3.A.2.11(1)(a)", + "3.A.2.11(1)(b)", + "3.A.2.11(1)(c)", + "3.A.2.11(1)(d)", + "3.A.2.11(1)(e)", + "3.A.2.11(1)(f)" ], - "CHG-01": [ - "19.1", - "19.2" + "PRI-05": [ + "3.A.3.14(1)", + "3.A.3.14(1)(a)", + "3.A.3.14(1)(b)", + "3.A.3.14(1)(c)", + "3.A.3.14(1)(d)", + "3.A.3.14(2)", + "3.A.3.14(3)", + "3.A.3.14(3)(a)", + "3.A.3.14(3)(b)", + "3.A.3.14(4)", + "3.A.3.14(5)", + "3.A.3.14(6)", + "3.A.3.14(6)(a)", + "3.A.3.14(6)(b)", + "3.A.3.14(6)(c)", + "3.A.3.14(6)(d)", + "3.A.3.14(7)" ], - "CLD-01": [ - "19.1", - "19.2" + "PRI-05.2": [ + "3.A.5.16(1)", + "3.A.5.16(2)" ], - "CPL-01": [ - "2", - "3", - "9", - "19", - "21" + "PRI-05.4": [ + "3.A.4.15(1)", + "3.A.4.15(2)", + "3.A.4.15(2)(a)", + "3.A.4.15(2)(b)", + "3.A.4.15(2)(c)", + "3.A.4.15(2)(d)", + "3.A.4.15(2)(e)", + "3.A.4.15(3)", + "3.A.4.15(3)(a)", + "3.A.4.15(3)(b)", + "3.A.4.15(3)(c)", + "3.A.4.15(3)(c)(i)", + "3.A.4.15(3)(c)(ii)", + "3.A.4.15(3)(c)(iii)", + "3.A.4.15(3)(c)(iv)", + "3.A.4.15(3)(d)", + "3.A.4.15(3)(d)(i)", + "3.A.4.15(3)(d)(ii)", + "3.A.4.15(3)(e)", + "3.A.4.15(3)(f)", + "3.B.26(1)", + "3.B.26(1)(a)", + "3.B.26(1)(b)", + "3.B.26(1)(b)(i)", + "3.B.26(1)(b)(ii)", + "3.B.27(1)", + "3.B.27(1)(a)", + "3.B.27(1)(b)", + "3.B.27(1)(c)", + "3.B.27(1)(d)", + "3.B.27(1)(d)(i)", + "3.B.27(1)(d)(ii)", + "3.B.27(1)(e)", + "3.B.27(1)(f)", + "3.B.27(2)", + "3.B.27(3)" ], - "CPL-02": [ - "8", - "19", - "21" + "PRI-06": [ + "3.A.8.23(1)", + "3.A.8.23(1)(a)", + "3.A.8.23(1)(b)", + "3.A.8.23(1)(b)(i)", + "3.A.8.23(1)(b)(ii)", + "3.A.8.23(1)(b)(iii)", + "3.A.8.23(1)(b)(iv)", + "3.A.8.23(2)", + "3.A.8.23(3)", + "3.A.8.23(3)(a)", + "3.A.8.23(3)(b)" ], - "CPL-03": [ - "8", - "19", - "21" + "PRI-06.1": [ + "3.A.8.24(1)", + "3.A.8.24(1)(a)", + "3.A.8.24(1)(b)" ], - "CPL-03.1": [ - "60" + "PRI-06.2": [ + "3.A.8.24(3)", + "3.A.8.24(4)" + ], + "PRI-06.4": [ + "3.A.8.23(4)(a)", + "3.A.8.23(4)(b)", + "3.A.8.23(5)", + "3.A.8.24(2)", + "3.A.8.24(2)(a)", + "3.A.8.24(2)(b)", + "3.A.8.24(2)(c)", + "3.A.8.24(2)(d)" ], - "MON-01": [ - "19.1", - "19.2" + "PRI-07.1": [ + "3.A.7.21(1)", + "3.A.7.21(2)" ], - "MON-01.16": [ - "19.1", - "19.2" + "PRI-17": [ + "3.A.3.14(8)" ], - "CRY-01": [ - "14.1", - "19.1", - "19.2" + "PRI-18": [ + "3.A.3.14(8)" ], - "CRY-03": [ - "14.1" + "PRI-19": [ + "8.71(1)", + "8.71(2)", + "8.71(2)(a)", + "8.71(2)(a)(i)", + "8.71(2)(a)(ii)", + "8.71(2)(b)", + "8.71(3)" ], - "CRY-04": [ - "14.1" + "PRI-19.1": [ + "8.71(3)(b)" ], - "CRY-05": [ - "14.1" + "PRI-19.2": [ + "8.71(3)(a)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 242, + "mappings": { + "3.A.7.22(1)": [ + "IRO-10" ], - "DCH-01": [ - "14.1", - "19", - "21" + "3.A.7.22(1)(a)": [ + "IRO-10" ], - "DCH-09.3": [ - "16.1" + "3.A.7.22(1)(b)": [ + "IRO-10" ], - "DCH-14": [ - "72" + "3.A.7.22(2)": [ + "IRO-10" ], - "DCH-18": [ - "9" + "3.A.7.22(3)": [ + "IRO-10" ], - "DCH-18.1": [ - "19" + "3.A.7.22(4)": [ + "IRO-10" ], - "DCH-18.2": [ - "19" + "3.A.7.22(4)(a)": [ + "IRO-10" ], - "DCH-22.1": [ - "24" + "3.A.7.22(4)(b)": [ + "IRO-10" ], - "DCH-24": [ - "19", - "21" + "3.A.7.22(4)(c)": [ + "IRO-10" ], - "DCH-24.1": [ - "19", - "21" + "3.A.7.22(4)(d)": [ + "IRO-10" ], - "DCH-25": [ - "72" + "3.A.7.22(4)(e)": [ + "IRO-10" ], - "EMB-01": [ - "19" + "3.A.7.22(5)": [ + "IRO-10" ], - "EMB-02": [ - "19" + "3.A.7.22(5)(a)": [ + "IRO-10" ], - "EMB-03": [ - "19" + "3.A.7.22(5)(b)": [ + "IRO-10" ], - "END-01": [ - "19" + "3.A.7.22(5)(c)": [ + "IRO-10" ], - "END-13.1": [ - "8", - "9", - "13.1" + "3.A.7.22(5)(d)": [ + "IRO-10" ], - "END-13.2": [ - "18" + "3.A.7.22(6)": [ + "IRO-10" ], - "END-13.3": [ - "10" + "9.72(1)": [ + "PRI-01.5" ], - "HRS-01": [ - "19", - "20" + "9.72(1)(a)": [ + "PRI-01.5" ], - "HRS-04": [ - "19", - "20" + "9.72(1)(a)(i)": [ + "PRI-01.5" ], - "IAC-01": [ - "19", - "20" + "9.72(1)(a)(ii)": [ + "PRI-01.5" ], - "IAC-09.6": [ - "6.1.b" + "9.72(1)(b)": [ + "PRI-01.5" ], - "IRO-01": [ - "19.1", - "19.3", - "22" + "9.72(1)(c)": [ + "PRI-01.5" ], - "IRO-04.1": [ - "22" + "9.72(1)(d)": [ + "PRI-01.5" ], - "IRO-10": [ - "22" + "9.72(1)(e)": [ + "PRI-01.5" ], - "IRO-11.2": [ - "21.2" + "9.72(1)(e)(i)": [ + "PRI-01.5" ], - "IAO-01": [ - "19", - "60" + "9.72(1)(e)(ii)": [ + "PRI-01.5" ], - "MNT-01": [ - "19" + "9.72(2)": [ + "PRI-01.5" ], - "NET-01": [ - "19" + "9.72(2)(a)": [ + "PRI-01.5" ], - "PES-01": [ - "19" + "9.72(2)(b)": [ + "PRI-01.5" ], - "PRI-01": [ - "19", - "20", - "60" + "3.A.7.19(1)": [ + "PRI-01.6" ], - "PRI-01.1": [ - "55", - "56" + "3.A.7.19(1)(a)": [ + "PRI-01.6" ], - "PRI-01.4": [ - "17", - "55", - "56" + "3.A.7.19(1)(b)": [ + "PRI-01.6" ], - "PRI-02": [ - "18" + "3.A.7.19(2)": [ + "PRI-01.6" ], - "PRI-02.1": [ - "13", - "18" + "3.A.7.19(2)(a)": [ + "PRI-01.6" ], - "PRI-02.2": [ - "5", - "71" + "3.A.7.19(2)(b)": [ + "PRI-01.6" ], - "PRI-03": [ - "11" + "3.A.7.19(2)(c)": [ + "PRI-01.6" ], - "PRI-03.1": [ - "11" + "3.A.7.19(2)(d)": [ + "PRI-01.6" ], - "PRI-03.2": [ - "15" + "3.A.7.19(3)": [ + "PRI-01.6" ], - "PRI-04": [ - "5", - "11", - "69" + "2.5(1)": [ + "PRI-01.11" ], - "PRI-04.1": [ - "2", - "3", - "4" + "2.5(1)(a)": [ + "PRI-01.11" ], - "PRI-05": [ - "4", - "14", - "16" + "2.5(1)(a)(i)": [ + "PRI-01.11" ], - "PRI-05.1": [ - "10" + "2.5(1)(a)(ii)": [ + "PRI-01.11" ], - "PRI-05.2": [ - "14", - "16" + "2.5(1)(b)": [ + "PRI-01.11" ], - "PRI-05.4": [ - "15", - "26" + "2.5(1)(c)": [ + "PRI-01.11" ], - "PRI-06": [ - "23" + "2.5(1)(d)": [ + "PRI-01.11" ], - "PRI-06.1": [ - "24" + "2.5(1)(e)": [ + "PRI-01.11" ], - "PRI-06.2": [ - "24" + "2.5(1)(e)(i)": [ + "PRI-01.11" ], - "PRI-06.3": [ - "63", - "74" + "2.5(1)(e)(ii)": [ + "PRI-01.11" ], - "PRI-07": [ - "18", - "28", - "30", - "31" + "2.5(1)(f)": [ + "PRI-01.11" ], - "PRI-07.1": [ - "11", - "20", - "21" + "2.5(1)(g)": [ + "PRI-01.11" ], - "PRI-08": [ - "19" + "2.5(1)(h)": [ + "PRI-01.11" ], - "PRI-09": [ - "17" + "2.5(1)(i)": [ + "PRI-01.11" ], - "PRI-10": [ - "4" + "3.A.2.9(1)": [ + "PRI-01.11" ], - "PRI-12": [ - "16" + "3.A.2.9(1)(a)": [ + "PRI-01.11" ], - "PRI-14.1": [ - "17" + "3.A.2.9(1)(b)": [ + "PRI-01.11" ], - "PRM-01": [ - "19" + "3.A.2.10": [ + "PRI-01.11" ], - "RSK-01": [ - "19" + "3.A.2.11(2)(a)": [ + "PRI-01.11" ], - "RSK-03": [ - "19" + "3.A.2.12(2)": [ + "PRI-01.11" ], - "RSK-04": [ - "19" + "3.A.2.12(2)(a)": [ + "PRI-01.11" ], - "RSK-04.1": [ - "19" + "3.A.2.12(2)(b)": [ + "PRI-01.11" ], - "RSK-05": [ - "19" + "3.A.2.12(2)(c)": [ + "PRI-01.11" ], - "RSK-06": [ - "19" + "3.A.2.12(2)(d)": [ + "PRI-01.11" ], - "RSK-06.1": [ - "19" + "3.A.2.12(2)(d)(i)": [ + "PRI-01.11" ], - "RSK-06.2": [ - "19" + "3.A.2.12(2)(d)(ii)": [ + "PRI-01.11" ], - "RSK-07": [ - "19" + "3.A.2.12(2)(d)(iii)": [ + "PRI-01.11" ], - "RSK-08": [ - "19" + "3.A.2.12(2)(d)(iv)": [ + "PRI-01.11" ], - "RSK-10": [ - "19" + "3.A.2.12(2)(d)(v)": [ + "PRI-01.11" ], - "RSK-11": [ - "4" + "3.A.2.12(2)(e)": [ + "PRI-01.11" ], - "SEA-01": [ - "19", - "21" + "3.A.2.12(2)(f)": [ + "PRI-01.11" ], - "SEA-01.1": [ - "8" + "3.A.6.17": [ + "PRI-01.11" ], - "SEA-02": [ - "19", - "21" + "3.A.6.18(1)": [ + "PRI-01.11" ], - "SEA-03": [ - "19", - "21" + "3.A.6.18(1)(a)": [ + "PRI-01.11" ], - "SEA-15": [ - "19", - "21" + "3.A.6.18(1)(b)": [ + "PRI-01.11" ], - "OPS-01": [ - "19" + "3.A.6.18(1)(c)": [ + "PRI-01.11" ], - "SAT-01": [ - "4.1.e" + "3.A.6.18(1)(d)": [ + "PRI-01.11" ], - "TPM-01": [ - "20", - "21" + "3.A.6.18(1)(e)": [ + "PRI-01.11" ], - "TPM-03": [ - "20" + "3.A.6.18(1)(f)": [ + "PRI-01.11" ], - "TPM-04": [ - "19" + "3.A.6.18(1)(g)": [ + "PRI-01.11" ], - "TPM-04.1": [ - "19" + "3.A.6.18(1)(h)": [ + "PRI-01.11" ], - "TPM-04.3": [ - "20", - "21" + "3.A.6.18(1)(h)(i)": [ + "PRI-01.11" ], - "TPM-04.4": [ - "19", - "21" + "3.A.6.18(1)(h)(ii)": [ + "PRI-01.11" ], - "TPM-05": [ - "20" + "3.A.6.18(1)(h)(iii)": [ + "PRI-01.11" ], - "VPM-01": [ - "19" + "3.A.6.18(1)(h)(iv)": [ + "PRI-01.11" ], - "VPM-04.2": [ - "4" + "3.A.6.18(1)(h)(v)": [ + "PRI-01.11" ], - "WEB-04": [ - "19" - ] - } - }, - "framework_to_scf": { - "total_mappings": 41, - "mappings": { - "2": [ - "CPL-01", + "3.A.6.18(2)": [ + "PRI-01.11" + ], + "3.A.6.18(2)(a)": [ + "PRI-01.11" + ], + "3.A.6.18(2)(b)": [ + "PRI-01.11" + ], + "3.A.6.18(3)": [ + "PRI-01.11" + ], + "3.A.6.18(4)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(a)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(b)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(c)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(c)(i)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(c)(ii)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(c)(iii)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(c)(iv)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(d)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(e)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(f)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(f)(i)": [ + "PRI-01.11" + ], + "3.A.6.18(4)(f)(ii)": [ + "PRI-01.11" + ], + "3.A.7.20(1)": [ + "PRI-01.11" + ], + "3.A.7.20(1)(a)": [ + "PRI-01.11" + ], + "3.A.7.20(1)(b)": [ + "PRI-01.11" + ], + "3.A.3.13(1)": [ + "PRI-02" + ], + "3.A.3.13(2)": [ + "PRI-02" + ], + "6.57(1)": [ + "PRI-03" + ], + "6.57(1)(a)": [ + "PRI-03" + ], + "6.57(1)(a)(i)": [ + "PRI-03" + ], + "6.57(1)(a)(ii)": [ + "PRI-03" + ], + "6.57(1)(b)": [ + "PRI-03" + ], + "6.57(1)(c)": [ + "PRI-03" + ], + "6.57(1)(d)": [ + "PRI-03" + ], + "6.57(2)": [ + "PRI-03" + ], + "6.57(3)": [ + "PRI-03" + ], + "6.57(4)": [ + "PRI-03" + ], + "3.C.34": [ + "PRI-03.3" + ], + "3.C.35(1)": [ + "PRI-03.3" + ], + "3.C.35(1)(a)": [ + "PRI-03.3" + ], + "3.C.35(1)(b)": [ + "PRI-03.3" + ], + "3.C.35(1)(c)": [ + "PRI-03.3" + ], + "3.C.35(1)(d)": [ + "PRI-03.3" + ], + "3.C.35(1)(d)(i)": [ + "PRI-03.3" + ], + "3.C.35(1)(d)(ii)": [ + "PRI-03.3" + ], + "3.C.35(1)(d)(iii)": [ + "PRI-03.3" + ], + "3.C.35(1)(e)": [ + "PRI-03.3" + ], + "3.C.35(2)": [ + "PRI-03.3" + ], + "3.C.35(3)": [ + "PRI-03.3" + ], + "3.C.35(3)(a)": [ + "PRI-03.3" + ], + "3.C.35(3)(a)(i)": [ + "PRI-03.3" + ], + "3.C.35(3)(a)(ii)": [ + "PRI-03.3" + ], + "3.C.35(3)(b)": [ + "PRI-03.3" + ], + "3.C.35(3)(b)(i)": [ + "PRI-03.3" + ], + "3.C.35(3)(b)(ii)": [ + "PRI-03.3" + ], + "3.C.35(3)(b)(iii)": [ + "PRI-03.3" + ], + "3.C.35(3)(c)": [ + "PRI-03.3" + ], + "3.C.35(3)(d)": [ + "PRI-03.3" + ], + "3.A.2.11(2)(b)": [ + "PRI-03.4" + ], + "3.A.2.11(3)": [ + "PRI-03.4" + ], + "3.A.2.11(3)(a)": [ + "PRI-03.4" + ], + "3.A.2.11(3)(b)": [ + "PRI-03.4" + ], + "3.A.2.11(4)": [ + "PRI-03.4" + ], + "3.A.2.12(1)": [ + "PRI-03.7" + ], + "3.A.2.11(1)": [ "PRI-04.1" ], - "3": [ - "CPL-01", + "3.A.2.11(1)(a)": [ "PRI-04.1" ], - "4": [ - "PRI-04.1", - "PRI-05", - "PRI-10", - "RSK-11", - "VPM-04.2" - ], - "5": [ - "PRI-02.2", - "PRI-04" - ], - "8": [ - "CPL-02", - "CPL-03", - "END-13.1", - "SEA-01.1" - ], - "9": [ - "CPL-01", - "DCH-18", - "END-13.1" - ], - "10": [ - "END-13.3", - "PRI-05.1" - ], - "11": [ - "PRI-03", - "PRI-03.1", - "PRI-04", - "PRI-07.1" + "3.A.2.11(1)(b)": [ + "PRI-04.1" + ], + "3.A.2.11(1)(c)": [ + "PRI-04.1" + ], + "3.A.2.11(1)(d)": [ + "PRI-04.1" + ], + "3.A.2.11(1)(e)": [ + "PRI-04.1" + ], + "3.A.2.11(1)(f)": [ + "PRI-04.1" ], - "13": [ - "PRI-02.1" + "3.A.3.14(1)": [ + "PRI-05" ], - "14": [ - "PRI-05", + "3.A.3.14(1)(a)": [ + "PRI-05" + ], + "3.A.3.14(1)(b)": [ + "PRI-05" + ], + "3.A.3.14(1)(c)": [ + "PRI-05" + ], + "3.A.3.14(1)(d)": [ + "PRI-05" + ], + "3.A.3.14(2)": [ + "PRI-05" + ], + "3.A.3.14(3)": [ + "PRI-05" + ], + "3.A.3.14(3)(a)": [ + "PRI-05" + ], + "3.A.3.14(3)(b)": [ + "PRI-05" + ], + "3.A.3.14(4)": [ + "PRI-05" + ], + "3.A.3.14(5)": [ + "PRI-05" + ], + "3.A.3.14(6)": [ + "PRI-05" + ], + "3.A.3.14(6)(a)": [ + "PRI-05" + ], + "3.A.3.14(6)(b)": [ + "PRI-05" + ], + "3.A.3.14(6)(c)": [ + "PRI-05" + ], + "3.A.3.14(6)(d)": [ + "PRI-05" + ], + "3.A.3.14(7)": [ + "PRI-05" + ], + "3.A.5.16(1)": [ "PRI-05.2" ], - "15": [ - "PRI-03.2", - "PRI-05.4" - ], - "16": [ - "PRI-05", - "PRI-05.2", - "PRI-12" - ], - "17": [ - "PRI-01.4", - "PRI-09", - "PRI-14.1" - ], - "18": [ - "END-13.2", - "PRI-02", - "PRI-02.1", - "PRI-07" - ], - "19": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-18.1", - "DCH-18.2", - "DCH-24", - "DCH-24.1", - "EMB-01", - "EMB-02", - "EMB-03", - "END-01", - "HRS-01", - "HRS-04", - "IAC-01", - "IAO-01", - "MNT-01", - "NET-01", - "PES-01", - "PRI-01", - "PRI-08", - "PRM-01", - "RSK-01", - "RSK-03", - "RSK-04", - "RSK-04.1", - "RSK-05", - "RSK-06", - "RSK-06.1", - "RSK-06.2", - "RSK-07", - "RSK-08", - "RSK-10", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "OPS-01", - "TPM-04", - "TPM-04.1", - "TPM-04.4", - "VPM-01", - "WEB-04" - ], - "20": [ - "HRS-01", - "HRS-04", - "IAC-01", - "PRI-01", - "PRI-07.1", - "TPM-01", - "TPM-03", - "TPM-04.3", - "TPM-05" - ], - "21": [ - "GOV-01", - "CPL-01", - "CPL-02", - "CPL-03", - "DCH-01", - "DCH-24", - "DCH-24.1", - "PRI-07.1", - "SEA-01", - "SEA-02", - "SEA-03", - "SEA-15", - "TPM-01", - "TPM-04.3", - "TPM-04.4" - ], - "22": [ - "IRO-01", - "IRO-04.1", - "IRO-10" + "3.A.5.16(2)": [ + "PRI-05.2" + ], + "3.A.4.15(1)": [ + "PRI-05.4" + ], + "3.A.4.15(2)": [ + "PRI-05.4" + ], + "3.A.4.15(2)(a)": [ + "PRI-05.4" + ], + "3.A.4.15(2)(b)": [ + "PRI-05.4" + ], + "3.A.4.15(2)(c)": [ + "PRI-05.4" + ], + "3.A.4.15(2)(d)": [ + "PRI-05.4" ], - "23": [ + "3.A.4.15(2)(e)": [ + "PRI-05.4" + ], + "3.A.4.15(3)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(a)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(b)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(c)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(c)(i)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(c)(ii)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(c)(iii)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(c)(iv)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(d)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(d)(i)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(d)(ii)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(e)": [ + "PRI-05.4" + ], + "3.A.4.15(3)(f)": [ + "PRI-05.4" + ], + "3.B.26(1)": [ + "PRI-05.4" + ], + "3.B.26(1)(a)": [ + "PRI-05.4" + ], + "3.B.26(1)(b)": [ + "PRI-05.4" + ], + "3.B.26(1)(b)(i)": [ + "PRI-05.4" + ], + "3.B.26(1)(b)(ii)": [ + "PRI-05.4" + ], + "3.B.27(1)": [ + "PRI-05.4" + ], + "3.B.27(1)(a)": [ + "PRI-05.4" + ], + "3.B.27(1)(b)": [ + "PRI-05.4" + ], + "3.B.27(1)(c)": [ + "PRI-05.4" + ], + "3.B.27(1)(d)": [ + "PRI-05.4" + ], + "3.B.27(1)(d)(i)": [ + "PRI-05.4" + ], + "3.B.27(1)(d)(ii)": [ + "PRI-05.4" + ], + "3.B.27(1)(e)": [ + "PRI-05.4" + ], + "3.B.27(1)(f)": [ + "PRI-05.4" + ], + "3.B.27(2)": [ + "PRI-05.4" + ], + "3.B.27(3)": [ + "PRI-05.4" + ], + "3.A.8.23(1)": [ + "PRI-06" + ], + "3.A.8.23(1)(a)": [ + "PRI-06" + ], + "3.A.8.23(1)(b)": [ + "PRI-06" + ], + "3.A.8.23(1)(b)(i)": [ "PRI-06" ], - "24": [ - "DCH-22.1", - "PRI-06.1", + "3.A.8.23(1)(b)(ii)": [ + "PRI-06" + ], + "3.A.8.23(1)(b)(iii)": [ + "PRI-06" + ], + "3.A.8.23(1)(b)(iv)": [ + "PRI-06" + ], + "3.A.8.23(2)": [ + "PRI-06" + ], + "3.A.8.23(3)": [ + "PRI-06" + ], + "3.A.8.23(3)(a)": [ + "PRI-06" + ], + "3.A.8.23(3)(b)": [ + "PRI-06" + ], + "3.A.8.24(1)": [ + "PRI-06.1" + ], + "3.A.8.24(1)(a)": [ + "PRI-06.1" + ], + "3.A.8.24(1)(b)": [ + "PRI-06.1" + ], + "3.A.8.24(3)": [ "PRI-06.2" ], - "26": [ - "PRI-05.4" + "3.A.8.24(4)": [ + "PRI-06.2" ], - "28": [ - "PRI-07" + "3.A.8.23(4)(a)": [ + "PRI-06.4" ], - "30": [ - "PRI-07" + "3.A.8.23(4)(b)": [ + "PRI-06.4" ], - "31": [ - "PRI-07" + "3.A.8.23(5)": [ + "PRI-06.4" ], - "55": [ - "PRI-01.1", - "PRI-01.4" + "3.A.8.24(2)": [ + "PRI-06.4" ], - "56": [ - "PRI-01.1", - "PRI-01.4" + "3.A.8.24(2)(a)": [ + "PRI-06.4" ], - "60": [ - "CPL-03.1", - "IAO-01", - "PRI-01" + "3.A.8.24(2)(b)": [ + "PRI-06.4" ], - "63": [ - "PRI-06.3" + "3.A.8.24(2)(c)": [ + "PRI-06.4" ], - "69": [ - "PRI-04" + "3.A.8.24(2)(d)": [ + "PRI-06.4" ], - "71": [ - "PRI-02.2" + "3.A.7.21(1)": [ + "PRI-07.1" ], - "72": [ - "DCH-14", - "DCH-25" + "3.A.7.21(2)": [ + "PRI-07.1" ], - "74": [ - "PRI-06.3" + "3.A.3.14(8)": [ + "PRI-17", + "PRI-18" ], - "19.1": [ - "AST-01", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "MON-01", - "MON-01.16", - "CRY-01", - "IRO-01" + "8.71(1)": [ + "PRI-19" ], - "19.2": [ - "AST-01", - "BCD-01", - "CAP-01", - "CHG-01", - "CLD-01", - "MON-01", - "MON-01.16", - "CRY-01" + "8.71(2)": [ + "PRI-19" ], - "14.1": [ - "CRY-01", - "CRY-03", - "CRY-04", - "CRY-05", - "DCH-01" + "8.71(2)(a)": [ + "PRI-19" ], - "16.1": [ - "DCH-09.3" + "8.71(2)(a)(i)": [ + "PRI-19" ], - "13.1": [ - "END-13.1" + "8.71(2)(a)(ii)": [ + "PRI-19" ], - "6.1.b": [ - "IAC-09.6" + "8.71(2)(b)": [ + "PRI-19" ], - "19.3": [ - "IRO-01" + "8.71(3)": [ + "PRI-19" ], - "21.2": [ - "IRO-11.2" + "8.71(3)(b)": [ + "PRI-19.1" ], - "4.1.e": [ - "SAT-01" + "8.71(3)(a)": [ + "PRI-19.2" ] } } diff --git a/docs/api/crosswalks/general-aicpa-pmf-2020.json b/docs/api/crosswalks/general-aicpa-pmf-2020.json index d20e32f9..3cf70c57 100644 --- a/docs/api/crosswalks/general-aicpa-pmf-2020.json +++ b/docs/api/crosswalks/general-aicpa-pmf-2020.json @@ -1,6 +1,6 @@ { "framework_id": "general-aicpa-pmf-2020", - "display_name": "AICPA Privacy Management Framework (PMF) (2020)", + "display_name": "American Institute of Certified Public Accountants (AICPA) Privacy Management Framework (PMF) (2020)", "scf_to_framework": { "total_mappings": 109, "mappings": { diff --git a/docs/api/crosswalks/general-aicpa-tsc-2017.json b/docs/api/crosswalks/general-aicpa-tsc-2017.json index e5451d0c..add5d32a 100644 --- a/docs/api/crosswalks/general-aicpa-tsc-2017.json +++ b/docs/api/crosswalks/general-aicpa-tsc-2017.json @@ -1,6 +1,6 @@ { "framework_id": "general-aicpa-tsc-2017", - "display_name": "Trust Services Criteria (TSC) (2017)", + "display_name": "American Institute of Certified Public Accountants (AICPA) Trust Services Criteria (2017)", "scf_to_framework": { "total_mappings": 412, "mappings": { diff --git a/docs/api/crosswalks/general-apec-privacy-framework-2015.json b/docs/api/crosswalks/general-apec-privacy-framework-2015.json index 3872386e..a67a188c 100644 --- a/docs/api/crosswalks/general-apec-privacy-framework-2015.json +++ b/docs/api/crosswalks/general-apec-privacy-framework-2015.json @@ -1,6 +1,6 @@ { "framework_id": "general-apec-privacy-framework-2015", - "display_name": "APEC Privacy Framework (2015)", + "display_name": "Asia - Pacific Economic Cooperation (APEC) Privacy Framework (2015)", "scf_to_framework": { "total_mappings": 14, "mappings": { diff --git a/docs/api/crosswalks/general-bsi-200-1-1-0.json b/docs/api/crosswalks/general-bsi-200-1-1-0.json index ab3c3e65..cdf5436e 100644 --- a/docs/api/crosswalks/general-bsi-200-1-1-0.json +++ b/docs/api/crosswalks/general-bsi-200-1-1-0.json @@ -1,6 +1,6 @@ { "framework_id": "general-bsi-200-1-1-0", - "display_name": "Standard 200-1 (v1.0)", + "display_name": "Bundesamt für Sicherheit in der Informationstechnik (BSI) - Standard 200 - 1 (v1.0)", "scf_to_framework": { "total_mappings": 35, "mappings": { diff --git a/docs/api/crosswalks/general-cis-csc-8-1-ig1.json b/docs/api/crosswalks/general-cis-csc-8-1-ig1.json index a85f904a..247510c2 100644 --- a/docs/api/crosswalks/general-cis-csc-8-1-ig1.json +++ b/docs/api/crosswalks/general-cis-csc-8-1-ig1.json @@ -1,6 +1,6 @@ { "framework_id": "general-cis-csc-8-1-ig1", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG1", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG1", "scf_to_framework": { "total_mappings": 104, "mappings": { diff --git a/docs/api/crosswalks/general-cis-csc-8-1-ig2.json b/docs/api/crosswalks/general-cis-csc-8-1-ig2.json index 9808b844..0ad1da8d 100644 --- a/docs/api/crosswalks/general-cis-csc-8-1-ig2.json +++ b/docs/api/crosswalks/general-cis-csc-8-1-ig2.json @@ -1,6 +1,6 @@ { "framework_id": "general-cis-csc-8-1-ig2", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG2", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG2", "scf_to_framework": { "total_mappings": 208, "mappings": { @@ -85,6 +85,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -174,13 +175,13 @@ ], "MON-04": [ "8.3", - "8.1" + "8.10" ], "MON-07.1": [ "8.4" ], "MON-10": [ - "8.1" + "8.10" ], "MON-16.3": [ "2.3" @@ -188,11 +189,11 @@ "CRY-01": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "CRY-03": [ - "3.1" + "3.10" ], "CRY-05": [ "3.6", @@ -393,7 +394,7 @@ "5.4" ], "IAC-22": [ - "4.1" + "4.10" ], "IAC-24": [ "4.3" @@ -552,14 +553,14 @@ "SEA-01": [ "12.2", "12.6", - "16.1" + "16.10" ], "SEA-01.1": [ - "16.1" + "16.10" ], "SEA-02": [ "12.2", - "16.1" + "16.10" ], "SEA-03.1": [ "3.12" @@ -619,11 +620,13 @@ "16.4" ], "TDA-05": [ - "16.1" + "16.1", + "16.10" ], "TDA-06": [ "16.1", "16.5", + "16.10", "16.11" ], "TDA-06.2": [ @@ -750,15 +753,17 @@ ], "WEB-07": [ "16.1", - "16.7" + "16.7", + "16.10" ], "WEB-08": [ - "16.1" + "16.1", + "16.10" ] } }, "framework_to_scf": { - "total_mappings": 126, + "total_mappings": 130, "mappings": { "2.1": [ "AST-01", @@ -858,8 +863,7 @@ "4.1": [ "CFG-01", "CFG-02", - "CFG-02.1", - "IAC-22" + "CFG-02.1" ], "4.2": [ "CFG-01", @@ -895,6 +899,10 @@ "CFG-02", "CFG-03" ], + "4.10": [ + "CFG-02", + "IAC-22" + ], "10.3": [ "CFG-02", "END-02" @@ -948,9 +956,7 @@ ], "8.1": [ "MON-01.8", - "MON-02", - "MON-04", - "MON-10" + "MON-02" ], "8.3": [ "MON-02", @@ -985,6 +991,10 @@ "8.11": [ "MON-02.2" ], + "8.10": [ + "MON-04", + "MON-10" + ], "3.6": [ "CRY-01", "CRY-05" @@ -994,9 +1004,20 @@ "CRY-05", "CRY-05.1" ], - "3.1": [ + "3.10": [ "CRY-01", - "CRY-03", + "CRY-03" + ], + "3.11": [ + "CRY-01", + "CRY-05" + ], + "12.3": [ + "CRY-06", + "MNT-05.3", + "NET-01" + ], + "3.1": [ "DCH-01", "DCH-01.1", "DCH-01.2", @@ -1008,15 +1029,6 @@ "DCH-09", "DCH-18" ], - "3.11": [ - "CRY-01", - "CRY-05" - ], - "12.3": [ - "CRY-06", - "MNT-05.3", - "NET-01" - ], "3.3": [ "DCH-01", "DCH-01.4", @@ -1233,16 +1245,12 @@ "RSK-09", "TPM-01" ], - "16.1": [ + "16.10": [ "SEA-01", "SEA-01.1", "SEA-02", - "TDA-02.3", "TDA-05", "TDA-06", - "TDA-06.3", - "TDA-09.6", - "TDA-16", "WEB-07", "WEB-08" ], @@ -1288,6 +1296,16 @@ "TDA-02.5", "TDA-04.2" ], + "16.1": [ + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-06.3", + "TDA-09.6", + "TDA-16", + "WEB-07", + "WEB-08" + ], "16.2": [ "TDA-04.2", "TDA-06.2", diff --git a/docs/api/crosswalks/general-cis-csc-8-1-ig3.json b/docs/api/crosswalks/general-cis-csc-8-1-ig3.json index 4e1d90ca..cc0edcf8 100644 --- a/docs/api/crosswalks/general-cis-csc-8-1-ig3.json +++ b/docs/api/crosswalks/general-cis-csc-8-1-ig3.json @@ -1,6 +1,6 @@ { "framework_id": "general-cis-csc-8-1-ig3", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG3", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG3", "scf_to_framework": { "total_mappings": 230, "mappings": { @@ -93,6 +93,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -197,13 +198,13 @@ ], "MON-04": [ "8.3", - "8.1" + "8.10" ], "MON-07.1": [ "8.4" ], "MON-10": [ - "8.1" + "8.10" ], "MON-16.3": [ "2.3" @@ -211,11 +212,11 @@ "CRY-01": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "CRY-03": [ - "3.1" + "3.10" ], "CRY-05": [ "3.6", @@ -424,7 +425,7 @@ "5.4" ], "IAC-22": [ - "4.1" + "4.10" ], "IAC-24": [ "4.3" @@ -566,10 +567,10 @@ "NET-18": [ "9.2", "9.3", - "13.1" + "13.10" ], "NET-18.1": [ - "13.1" + "13.10" ], "NET-20.4": [ "9.5" @@ -616,14 +617,14 @@ "SEA-01": [ "12.2", "12.6", - "16.1" + "16.10" ], "SEA-01.1": [ - "16.1" + "16.10" ], "SEA-02": [ "12.2", - "16.1" + "16.10" ], "SEA-03.1": [ "3.12" @@ -689,11 +690,13 @@ "16.4" ], "TDA-05": [ - "16.1" + "16.1", + "16.10" ], "TDA-06": [ "16.1", "16.5", + "16.10", "16.11" ], "TDA-06.2": [ @@ -840,19 +843,21 @@ ], "WEB-03": [ "4.4", - "13.1" + "13.10" ], "WEB-07": [ "16.1", - "16.7" + "16.7", + "16.10" ], "WEB-08": [ - "16.1" + "16.1", + "16.10" ] } }, "framework_to_scf": { - "total_mappings": 148, + "total_mappings": 153, "mappings": { "2.1": [ "AST-01", @@ -962,8 +967,7 @@ "4.1": [ "CFG-01", "CFG-02", - "CFG-02.1", - "IAC-22" + "CFG-02.1" ], "4.2": [ "CFG-01", @@ -999,6 +1003,10 @@ "CFG-02", "CFG-03" ], + "4.10": [ + "CFG-02", + "IAC-22" + ], "10.3": [ "CFG-02", "END-02" @@ -1058,9 +1066,7 @@ ], "8.1": [ "MON-01.8", - "MON-02", - "MON-04", - "MON-10" + "MON-02" ], "13.11": [ "MON-01.13" @@ -1106,14 +1112,15 @@ "MON-02.3" ], "13.1": [ - "MON-02", - "NET-18", - "NET-18.1", - "WEB-03" + "MON-02" ], "8.11": [ "MON-02.2" ], + "8.10": [ + "MON-04", + "MON-10" + ], "3.6": [ "CRY-01", "CRY-05" @@ -1123,9 +1130,20 @@ "CRY-05", "CRY-05.1" ], - "3.1": [ + "3.10": [ + "CRY-01", + "CRY-03" + ], + "3.11": [ "CRY-01", - "CRY-03", + "CRY-05" + ], + "12.3": [ + "CRY-06", + "MNT-05.3", + "NET-01" + ], + "3.1": [ "DCH-01", "DCH-01.1", "DCH-01.2", @@ -1137,15 +1155,6 @@ "DCH-09", "DCH-18" ], - "3.11": [ - "CRY-01", - "CRY-05" - ], - "12.3": [ - "CRY-06", - "MNT-05.3", - "NET-01" - ], "3.3": [ "DCH-01", "DCH-01.4", @@ -1375,6 +1384,11 @@ "9.3": [ "NET-18" ], + "13.10": [ + "NET-18", + "NET-18.1", + "WEB-03" + ], "15.7": [ "PRM-05", "PRM-06", @@ -1403,16 +1417,12 @@ "TPM-04", "TPM-04.1" ], - "16.1": [ + "16.10": [ "SEA-01", "SEA-01.1", "SEA-02", - "TDA-02.3", "TDA-05", "TDA-06", - "TDA-06.3", - "TDA-09.6", - "TDA-16", "WEB-07", "WEB-08" ], @@ -1458,6 +1468,16 @@ "TDA-02.5", "TDA-04.2" ], + "16.1": [ + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-06.3", + "TDA-09.6", + "TDA-16", + "WEB-07", + "WEB-08" + ], "16.2": [ "TDA-04.2", "TDA-06.2", diff --git a/docs/api/crosswalks/general-cis-csc-8-1.json b/docs/api/crosswalks/general-cis-csc-8-1.json index ee526bf4..a9898d43 100644 --- a/docs/api/crosswalks/general-cis-csc-8-1.json +++ b/docs/api/crosswalks/general-cis-csc-8-1.json @@ -1,19 +1,19 @@ { "framework_id": "general-cis-csc-8-1", - "display_name": "Critical Security Controls (CSC) (v8.1)", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1", "scf_to_framework": { "total_mappings": 234, "mappings": { "AST-01": [ - "1.0", - "2.0", + "1", + "2", "2.1", "2.2" ], "AST-02": [ - "1.0", + "1", "1.1", - "2.0", + "2", "2.1", "2.2", "2.4", @@ -57,7 +57,7 @@ "4.11" ], "BCD-01": [ - "11.0", + "11", "11.1" ], "BCD-11": [ @@ -86,8 +86,8 @@ "18.4" ], "CFG-01": [ - "2.0", - "4.0", + "2", + "4", "4.1", "4.2" ], @@ -100,6 +100,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -115,7 +116,7 @@ "2.3" ], "CFG-03": [ - "4.0", + "4", "4.6", "4.8" ], @@ -129,7 +130,7 @@ "2.7" ], "CFG-04.2": [ - "9.0", + "9", "9.1", "9.4" ], @@ -145,9 +146,9 @@ "2.4" ], "MON-01": [ - "8.0", + "8", "8.2", - "13.0", + "13", "13.6" ], "MON-01.4": [ @@ -208,13 +209,13 @@ ], "MON-04": [ "8.3", - "8.1" + "8.10" ], "MON-07.1": [ "8.4" ], "MON-10": [ - "8.1" + "8.10" ], "MON-16.3": [ "2.3" @@ -222,11 +223,11 @@ "CRY-01": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "CRY-03": [ - "3.1" + "3.10" ], "CRY-05": [ "3.6", @@ -241,10 +242,10 @@ "12.3" ], "DCH-01": [ - "3.0", + "3", "3.1", "3.3", - "11.0", + "11", "11.3" ], "DCH-01.1": [ @@ -308,20 +309,20 @@ "3.5" ], "END-01": [ - "10.0" + "10" ], "END-02": [ - "10.0", + "10", "10.3", "10.4", "10.5", - "11.0" + "11" ], "END-03.1": [ "2.3" ], "END-04": [ - "10.0", + "10", "10.1", "10.4" ], @@ -351,7 +352,7 @@ "13.7" ], "END-08": [ - "9.0", + "9", "9.6", "9.7" ], @@ -359,16 +360,16 @@ "9.4" ], "HRS-05.2": [ - "9.0" + "9" ], "HRS-05.4": [ "9.4" ], "IAC-01": [ "4.7", - "5.0", + "5", "5.6", - "6.0", + "6", "6.6" ], "IAC-01.2": [ @@ -404,7 +405,7 @@ ], "IAC-08": [ "3.3", - "6.0", + "6", "6.8" ], "IAC-09": [ @@ -426,9 +427,9 @@ "6.7" ], "IAC-15.1": [ - "5.0", + "5", "5.6", - "6.0" + "6" ], "IAC-15.3": [ "5.3" @@ -452,18 +453,18 @@ "5.4" ], "IAC-22": [ - "4.1" + "4.10" ], "IAC-24": [ "4.3" ], "IRO-01": [ - "17.0", + "17", "17.5" ], "IRO-02": [ "2.3", - "17.0", + "17", "17.1", "17.3", "17.4", @@ -509,7 +510,7 @@ "17.8" ], "IRO-15": [ - "9.0", + "9", "9.6", "9.7" ], @@ -538,7 +539,7 @@ "4.12" ], "NET-01": [ - "12.0", + "12", "12.1", "12.2", "12.3", @@ -596,13 +597,13 @@ "3.13" ], "NET-18": [ - "9.0", + "9", "9.2", "9.3", - "13.1" + "13.10" ], "NET-18.1": [ - "13.1" + "13.10" ], "NET-20.4": [ "9.5" @@ -649,21 +650,21 @@ "SEA-01": [ "12.2", "12.6", - "16.0", - "16.1" + "16", + "16.10" ], "SEA-01.1": [ - "16.1" + "16.10" ], "SEA-02": [ "12.2", - "16.1" + "16.10" ], "SEA-03.1": [ "3.12" ], "SAT-01": [ - "14.0", + "14", "14.1" ], "SAT-02": [ @@ -672,7 +673,7 @@ "14.8" ], "SAT-02.2": [ - "9.0", + "9", "14.2" ], "SAT-03": [ @@ -700,7 +701,7 @@ ], "TDA-01": [ "15.7", - "16.0" + "16" ], "TDA-01.1": [ "15.7" @@ -726,12 +727,14 @@ "16.4" ], "TDA-05": [ - "16.1" + "16.1", + "16.10" ], "TDA-06": [ - "16.0", + "16", "16.1", "16.5", + "16.10", "16.11" ], "TDA-06.2": [ @@ -798,7 +801,7 @@ "2.2" ], "TPM-01": [ - "15.0", + "15", "15.2" ], "TPM-01.1": [ @@ -824,13 +827,13 @@ "15.4" ], "TPM-05.4": [ - "15.0" + "15" ], "TPM-05.5": [ - "15.0" + "15" ], "TPM-08": [ - "15.0", + "15", "15.6" ], "TPM-10": [ @@ -840,16 +843,16 @@ "16.2" ], "VPM-01": [ - "7.0", + "7", "7.1", - "18.0" + "18" ], "VPM-02": [ "7.2", "7.7" ], "VPM-04": [ - "7.0", + "7", "7.7", "12.1", "18.3" @@ -883,38 +886,111 @@ "7.5" ], "VPM-07": [ - "18.0", + "18", "18.1", "18.2", "18.5" ], "WEB-03": [ "4.4", - "13.1" + "13.10" ], "WEB-07": [ - "16.0", + "16", "16.1", - "16.7" + "16.7", + "16.10" ], "WEB-08": [ - "16.0", - "16.1" + "16", + "16.1", + "16.10" ] } }, "framework_to_scf": { - "total_mappings": 166, + "total_mappings": 171, "mappings": { - "1.0": [ + "1": [ "AST-01", "AST-02" ], - "2.0": [ + "2": [ "AST-01", "AST-02", "CFG-01" ], + "3": [ + "DCH-01" + ], + "4": [ + "CFG-01", + "CFG-03" + ], + "5": [ + "IAC-01", + "IAC-15.1" + ], + "6": [ + "IAC-01", + "IAC-08", + "IAC-15.1" + ], + "7": [ + "VPM-01", + "VPM-04" + ], + "8": [ + "MON-01" + ], + "9": [ + "CFG-04.2", + "END-08", + "HRS-05.2", + "IRO-15", + "NET-18", + "SAT-02.2" + ], + "10": [ + "END-01", + "END-02", + "END-04" + ], + "11": [ + "BCD-01", + "DCH-01", + "END-02" + ], + "12": [ + "NET-01" + ], + "13": [ + "MON-01" + ], + "14": [ + "SAT-01" + ], + "15": [ + "TPM-01", + "TPM-05.4", + "TPM-05.5", + "TPM-08" + ], + "16": [ + "SEA-01", + "TDA-01", + "TDA-06", + "WEB-07", + "WEB-08" + ], + "17": [ + "IRO-01", + "IRO-02" + ], + "18": [ + "VPM-01", + "VPM-07" + ], "2.1": [ "AST-01", "AST-02", @@ -997,11 +1073,6 @@ "MDM-01", "MDM-05" ], - "11.0": [ - "BCD-01", - "DCH-01", - "END-02" - ], "11.1": [ "BCD-01" ], @@ -1025,15 +1096,10 @@ "18.4": [ "CHG-06" ], - "4.0": [ - "CFG-01", - "CFG-03" - ], "4.1": [ "CFG-01", "CFG-02", - "CFG-02.1", - "IAC-22" + "CFG-02.1" ], "4.2": [ "CFG-01", @@ -1069,6 +1135,10 @@ "CFG-02", "CFG-03" ], + "4.10": [ + "CFG-02", + "IAC-22" + ], "10.3": [ "CFG-02", "END-02" @@ -1103,14 +1173,6 @@ "MNT-04", "MNT-04.4" ], - "9.0": [ - "CFG-04.2", - "END-08", - "HRS-05.2", - "IRO-15", - "NET-18", - "SAT-02.2" - ], "9.1": [ "CFG-04.2", "CFG-05.2" @@ -1121,9 +1183,6 @@ "HRS-05.1", "HRS-05.4" ], - "8.0": [ - "MON-01" - ], "8.2": [ "MON-01", "MON-01.4", @@ -1131,9 +1190,6 @@ "MON-02.7", "MON-03" ], - "13.0": [ - "MON-01" - ], "13.6": [ "MON-01", "MON-01.13", @@ -1142,9 +1198,7 @@ ], "8.1": [ "MON-01.8", - "MON-02", - "MON-04", - "MON-10" + "MON-02" ], "13.11": [ "MON-01.13" @@ -1190,14 +1244,15 @@ "MON-02.3" ], "13.1": [ - "MON-02", - "NET-18", - "NET-18.1", - "WEB-03" + "MON-02" ], "8.11": [ "MON-02.2" ], + "8.10": [ + "MON-04", + "MON-10" + ], "3.6": [ "CRY-01", "CRY-05" @@ -1207,19 +1262,9 @@ "CRY-05", "CRY-05.1" ], - "3.1": [ + "3.10": [ "CRY-01", - "CRY-03", - "DCH-01", - "DCH-01.1", - "DCH-01.2", - "DCH-01.4", - "DCH-02", - "DCH-03", - "DCH-03.1", - "DCH-08", - "DCH-09", - "DCH-18" + "CRY-03" ], "3.11": [ "CRY-01", @@ -1230,8 +1275,17 @@ "MNT-05.3", "NET-01" ], - "3.0": [ - "DCH-01" + "3.1": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "DCH-03", + "DCH-03.1", + "DCH-08", + "DCH-09", + "DCH-18" ], "3.3": [ "DCH-01", @@ -1260,11 +1314,6 @@ "3.4": [ "DCH-18" ], - "10.0": [ - "END-01", - "END-02", - "END-04" - ], "10.1": [ "END-04" ], @@ -1294,10 +1343,6 @@ "END-08", "IRO-15" ], - "5.0": [ - "IAC-01", - "IAC-15.1" - ], "5.6": [ "IAC-01", "IAC-01.2", @@ -1305,11 +1350,6 @@ "IAC-09", "IAC-15.1" ], - "6.0": [ - "IAC-01", - "IAC-08", - "IAC-15.1" - ], "12.5": [ "IAC-01.2", "IAC-02", @@ -1363,10 +1403,6 @@ "12.8": [ "IAC-20.4" ], - "17.0": [ - "IRO-01", - "IRO-02" - ], "17.5": [ "IRO-01", "IRO-02", @@ -1424,9 +1460,6 @@ "4.12": [ "MDM-10" ], - "12.0": [ - "NET-01" - ], "12.1": [ "NET-01", "VPM-04", @@ -1483,6 +1516,11 @@ "9.3": [ "NET-18" ], + "13.10": [ + "NET-18", + "NET-18.1", + "WEB-03" + ], "15.7": [ "PRM-05", "PRM-06", @@ -1511,29 +1549,15 @@ "TPM-04", "TPM-04.1" ], - "16.0": [ - "SEA-01", - "TDA-01", - "TDA-06", - "WEB-07", - "WEB-08" - ], - "16.1": [ + "16.10": [ "SEA-01", "SEA-01.1", "SEA-02", - "TDA-02.3", "TDA-05", "TDA-06", - "TDA-06.3", - "TDA-09.6", - "TDA-16", "WEB-07", "WEB-08" ], - "14.0": [ - "SAT-01" - ], "14.1": [ "SAT-01" ], @@ -1576,6 +1600,16 @@ "TDA-02.5", "TDA-04.2" ], + "16.1": [ + "TDA-02.3", + "TDA-05", + "TDA-06", + "TDA-06.3", + "TDA-09.6", + "TDA-16", + "WEB-07", + "WEB-08" + ], "16.2": [ "TDA-04.2", "TDA-06.2", @@ -1608,12 +1642,6 @@ "16.13": [ "TDA-09.5" ], - "15.0": [ - "TPM-01", - "TPM-05.4", - "TPM-05.5", - "TPM-08" - ], "15.1": [ "TPM-01.1" ], @@ -1623,17 +1651,9 @@ "15.6": [ "TPM-08" ], - "7.0": [ - "VPM-01", - "VPM-04" - ], "7.1": [ "VPM-01" ], - "18.0": [ - "VPM-01", - "VPM-07" - ], "7.2": [ "VPM-02" ], diff --git a/docs/api/crosswalks/general-cr-cmm-2026.json b/docs/api/crosswalks/general-cr-cmm-2026.json index 9c30e653..24d1a366 100644 --- a/docs/api/crosswalks/general-cr-cmm-2026.json +++ b/docs/api/crosswalks/general-cr-cmm-2026.json @@ -1,6 +1,6 @@ { "framework_id": "general-cr-cmm-2026", - "display_name": "Cyber Resilience Capability Maturity Model (CR-CMM) (2026)", + "display_name": "Cyber Resilience Capability Maturity Model (CR - CMM) (2026)", "scf_to_framework": { "total_mappings": 46, "mappings": { diff --git a/docs/api/crosswalks/general-csa-cmm-4-1-0.json b/docs/api/crosswalks/general-csa-cmm-4-1-0.json index 36de774b..bb7bc641 100644 --- a/docs/api/crosswalks/general-csa-cmm-4-1-0.json +++ b/docs/api/crosswalks/general-csa-cmm-4-1-0.json @@ -1,6 +1,6 @@ { "framework_id": "general-csa-cmm-4-1-0", - "display_name": "Cloud Controls Matrix (CCM) (v4.1.0)", + "display_name": "Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) v4.1.0", "scf_to_framework": { "total_mappings": 291, "mappings": { diff --git a/docs/api/crosswalks/general-csa-iot-2.json b/docs/api/crosswalks/general-csa-iot-2.json index 6962469f..cc169b38 100644 --- a/docs/api/crosswalks/general-csa-iot-2.json +++ b/docs/api/crosswalks/general-csa-iot-2.json @@ -1,6 +1,6 @@ { "framework_id": "general-csa-iot-2", - "display_name": "IoT Security Controls Framework (v2)", + "display_name": "Cloud Security Alliance (CSA) Internet of Things Security Controls Framework v2", "scf_to_framework": { "total_mappings": 253, "mappings": { diff --git a/docs/api/crosswalks/general-govramp-core.json b/docs/api/crosswalks/general-govramp-core.json index 2babcd5e..3402c27a 100644 --- a/docs/api/crosswalks/general-govramp-core.json +++ b/docs/api/crosswalks/general-govramp-core.json @@ -1,6 +1,6 @@ { "framework_id": "general-govramp-core", - "display_name": "GovRAMP Core", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Core Controls", "scf_to_framework": { "total_mappings": 86, "mappings": { diff --git a/docs/api/crosswalks/general-govramp-high.json b/docs/api/crosswalks/general-govramp-high.json index 6134de8c..23ff481b 100644 --- a/docs/api/crosswalks/general-govramp-high.json +++ b/docs/api/crosswalks/general-govramp-high.json @@ -1,6 +1,6 @@ { "framework_id": "general-govramp-high", - "display_name": "GovRAMP High", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - High", "scf_to_framework": { "total_mappings": 441, "mappings": { diff --git a/docs/api/crosswalks/general-govramp-low-plus.json b/docs/api/crosswalks/general-govramp-low-plus.json index c10f61ee..dad74a0d 100644 --- a/docs/api/crosswalks/general-govramp-low-plus.json +++ b/docs/api/crosswalks/general-govramp-low-plus.json @@ -1,6 +1,6 @@ { "framework_id": "general-govramp-low-plus", - "display_name": "GovRAMP Low+", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Low+", "scf_to_framework": { "total_mappings": 230, "mappings": { diff --git a/docs/api/crosswalks/general-govramp-low.json b/docs/api/crosswalks/general-govramp-low.json index ef3fc54e..7af3a3eb 100644 --- a/docs/api/crosswalks/general-govramp-low.json +++ b/docs/api/crosswalks/general-govramp-low.json @@ -1,6 +1,6 @@ { "framework_id": "general-govramp-low", - "display_name": "GovRAMP Low", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Low", "scf_to_framework": { "total_mappings": 166, "mappings": { diff --git a/docs/api/crosswalks/general-govramp-mod.json b/docs/api/crosswalks/general-govramp-mod.json index ac37e7f7..0098fd71 100644 --- a/docs/api/crosswalks/general-govramp-mod.json +++ b/docs/api/crosswalks/general-govramp-mod.json @@ -1,6 +1,6 @@ { "framework_id": "general-govramp-mod", - "display_name": "GovRAMP Moderate", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Moderate", "scf_to_framework": { "total_mappings": 347, "mappings": { diff --git a/docs/api/crosswalks/general-govramp.json b/docs/api/crosswalks/general-govramp.json index 98364991..584e6a17 100644 --- a/docs/api/crosswalks/general-govramp.json +++ b/docs/api/crosswalks/general-govramp.json @@ -1,6 +1,6 @@ { "framework_id": "general-govramp", - "display_name": "GovRAMP", + "display_name": "Government Risk and Authorization Management Program (GovRAMP)", "scf_to_framework": { "total_mappings": 441, "mappings": { diff --git a/docs/api/crosswalks/general-iec-62443-2-1-2024.json b/docs/api/crosswalks/general-iec-62443-2-1-2024.json index 1f4d71d1..917c13d2 100644 --- a/docs/api/crosswalks/general-iec-62443-2-1-2024.json +++ b/docs/api/crosswalks/general-iec-62443-2-1-2024.json @@ -1,6 +1,6 @@ { "framework_id": "general-iec-62443-2-1-2024", - "display_name": "IEC 62443-2-1 (2024)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 2 - 1:2024 - Security for industrial automation and control systems - Part 2 - 1: Security program requirements for IACS asset owners", "scf_to_framework": { "total_mappings": 112, "mappings": { diff --git a/docs/api/crosswalks/general-iec-62443-3-3-2013.json b/docs/api/crosswalks/general-iec-62443-3-3-2013.json index c396f404..eee9869a 100644 --- a/docs/api/crosswalks/general-iec-62443-3-3-2013.json +++ b/docs/api/crosswalks/general-iec-62443-3-3-2013.json @@ -1,6 +1,6 @@ { "framework_id": "general-iec-62443-3-3-2013", - "display_name": "IEC 62443-3-3 (2013)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 3 - 3:2013 - Industrial communication networks - Network and system security - Part 3 - 3: System security requirements and security levels", "scf_to_framework": { "total_mappings": 80, "mappings": { diff --git a/docs/api/crosswalks/general-iec-62443-4-1-2018.json b/docs/api/crosswalks/general-iec-62443-4-1-2018.json index cd56575d..357108a3 100644 --- a/docs/api/crosswalks/general-iec-62443-4-1-2018.json +++ b/docs/api/crosswalks/general-iec-62443-4-1-2018.json @@ -1,6 +1,6 @@ { "framework_id": "general-iec-62443-4-1-2018", - "display_name": "IEC 62443-4-1 (2018)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 4 - 1:2018 - Security for industrial automation and control systems - Part 4 - 1: Secure product development lifecycle requirements", "scf_to_framework": { "total_mappings": 25, "mappings": { diff --git a/docs/api/crosswalks/general-iec-62443-4-2-2019.json b/docs/api/crosswalks/general-iec-62443-4-2-2019.json index 9dc450f0..2aca0d70 100644 --- a/docs/api/crosswalks/general-iec-62443-4-2-2019.json +++ b/docs/api/crosswalks/general-iec-62443-4-2-2019.json @@ -1,6 +1,6 @@ { "framework_id": "general-iec-62443-4-2-2019", - "display_name": "IEC 62443-4-2 (2019)", + "display_name": "International Electrotechnical Commission 62443 - 4 - 2 Ed. 1.0 b:2019 - Security for industrial automation and control systems - Part 4 - 2: Technical security requirements for IACS components", "scf_to_framework": { "total_mappings": 89, "mappings": { diff --git a/docs/api/crosswalks/general-iec-tr-60601-4-5-2021.json b/docs/api/crosswalks/general-iec-tr-60601-4-5-2021.json index 5173d32d..a7554166 100644 --- a/docs/api/crosswalks/general-iec-tr-60601-4-5-2021.json +++ b/docs/api/crosswalks/general-iec-tr-60601-4-5-2021.json @@ -1,6 +1,6 @@ { "framework_id": "general-iec-tr-60601-4-5-2021", - "display_name": "IEC TR 60601-4-5 (2021)", + "display_name": "International Electrotechnical Commission (IEC) Technical Report 60601 - 4 - 5:2021 - Medical electrical equipment - Part 4 - 5: Guidance and interpretation - Safety - related technical security specifications", "scf_to_framework": { "total_mappings": 26, "mappings": { diff --git a/docs/api/crosswalks/general-iso-21434-2021.json b/docs/api/crosswalks/general-iso-21434-2021.json index d72de669..41d8b5d6 100644 --- a/docs/api/crosswalks/general-iso-21434-2021.json +++ b/docs/api/crosswalks/general-iso-21434-2021.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-21434-2021", - "display_name": "ISO 21434 (2021)", + "display_name": "ISO/SAE 21434:2021 - Road vehicles — Cybersecurity engineering", "scf_to_framework": { "total_mappings": 51, "mappings": { diff --git a/docs/api/crosswalks/general-iso-22301-2019.json b/docs/api/crosswalks/general-iso-22301-2019.json index 8226d45a..8f61ce32 100644 --- a/docs/api/crosswalks/general-iso-22301-2019.json +++ b/docs/api/crosswalks/general-iso-22301-2019.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-22301-2019", - "display_name": "ISO 22301 (2019)", + "display_name": "ISO/IEC 22301:2019 - Security and resilience - Business continuity management systems - Requirements", "scf_to_framework": { "total_mappings": 36, "mappings": { diff --git a/docs/api/crosswalks/general-iso-27001-2022.json b/docs/api/crosswalks/general-iso-27001-2022.json index 34a563aa..92b6b73d 100644 --- a/docs/api/crosswalks/general-iso-27001-2022.json +++ b/docs/api/crosswalks/general-iso-27001-2022.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-27001-2022", - "display_name": "ISO 27001 (2022)", + "display_name": "ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements", "scf_to_framework": { "total_mappings": 51, "mappings": { diff --git a/docs/api/crosswalks/general-iso-27002-2022.json b/docs/api/crosswalks/general-iso-27002-2022.json index 337aafec..9f80ed99 100644 --- a/docs/api/crosswalks/general-iso-27002-2022.json +++ b/docs/api/crosswalks/general-iso-27002-2022.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-27002-2022", - "display_name": "ISO 27002 (2022)", + "display_name": "ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls", "scf_to_framework": { "total_mappings": 316, "mappings": { @@ -825,10 +825,10 @@ "7.2" ], "PES-12": [ - "7.12", "7.3", "7.5", - "7.8" + "7.8", + "7.12" ], "PES-12.1": [ "7.12" @@ -1053,7 +1053,7 @@ ], "TPM-03.2": [ "5.19", - "5.2" + "5.20" ], "TPM-03.3": [ "5.19", @@ -1178,7 +1178,6 @@ "GOV-04", "HRS-03", "HRS-04.1", - "TPM-03.2", "TPM-05.4", "TPM-06" ], @@ -1671,6 +1670,7 @@ "5.20": [ "IRO-10.4", "TPM-01", + "TPM-03.2", "TPM-05", "TPM-08", "TPM-10" diff --git a/docs/api/crosswalks/general-iso-27017-2015.json b/docs/api/crosswalks/general-iso-27017-2015.json index 2fa2ee5c..c2f2896f 100644 --- a/docs/api/crosswalks/general-iso-27017-2015.json +++ b/docs/api/crosswalks/general-iso-27017-2015.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-27017-2015", - "display_name": "ISO 27017 (2015)", + "display_name": "ISO/IEC 27017:2015 - Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services", "scf_to_framework": { "total_mappings": 224, "mappings": { diff --git a/docs/api/crosswalks/general-iso-27018-2025.json b/docs/api/crosswalks/general-iso-27018-2025.json index df6cec35..21cdd099 100644 --- a/docs/api/crosswalks/general-iso-27018-2025.json +++ b/docs/api/crosswalks/general-iso-27018-2025.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-27018-2025", - "display_name": "ISO 27018 (2025)", + "display_name": "ISO/IEC 27018:2025 - Information security, cybersecurity and privacy protection - Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors", "scf_to_framework": { "total_mappings": 322, "mappings": { diff --git a/docs/api/crosswalks/general-iso-27701-2025.json b/docs/api/crosswalks/general-iso-27701-2025.json index 6446335a..5b7b65ce 100644 --- a/docs/api/crosswalks/general-iso-27701-2025.json +++ b/docs/api/crosswalks/general-iso-27701-2025.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-27701-2025", - "display_name": "ISO 27701 (2025)", + "display_name": "ISO/IEC 27701:2025 - Information security, cybersecurity and privacy protection - Privacy information management systems - Requirements and guidance", "scf_to_framework": { "total_mappings": 59, "mappings": { diff --git a/docs/api/crosswalks/general-iso-29100-2024.json b/docs/api/crosswalks/general-iso-29100-2024.json index 15150c35..593d5bd1 100644 --- a/docs/api/crosswalks/general-iso-29100-2024.json +++ b/docs/api/crosswalks/general-iso-29100-2024.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-29100-2024", - "display_name": "ISO 29100 (2024)", + "display_name": "ISO/IEC 29100:2024 - Information technology - Security techniques - Privacy framework", "scf_to_framework": { "total_mappings": 43, "mappings": { @@ -56,19 +56,19 @@ "6.7" ], "IRO-10": [ - "6.1" + "6.10" ], "PRI-01": [ - "6.1" + "6.10" ], "PRI-01.1": [ - "6.1" + "6.10" ], "PRI-01.3": [ "6.8" ], "PRI-01.4": [ - "6.1" + "6.10" ], "PRI-01.6": [ "6.11" @@ -79,7 +79,7 @@ "PRI-01.11": [ "6.5", "6.8", - "6.1" + "6.10" ], "PRI-02": [ "6.3" @@ -118,25 +118,25 @@ ], "PRI-06": [ "6.9", - "6.1" + "6.10" ], "PRI-06.1": [ "6.9" ], "PRI-06.4": [ - "6.1" + "6.10" ], "PRI-07": [ - "6.1" + "6.10" ], "PRI-07.1": [ - "6.1" + "6.10" ], "SAT-03": [ - "6.1" + "6.10" ], "SAT-03.3": [ - "6.1" + "6.10" ] } }, @@ -172,7 +172,7 @@ "PRI-04.7", "PRI-05.2" ], - "6.1": [ + "6.10": [ "IRO-10", "PRI-01", "PRI-01.1", diff --git a/docs/api/crosswalks/general-iso-31000-2018.json b/docs/api/crosswalks/general-iso-31000-2018.json index 9d0a2734..2cb9df93 100644 --- a/docs/api/crosswalks/general-iso-31000-2018.json +++ b/docs/api/crosswalks/general-iso-31000-2018.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-31000-2018", - "display_name": "ISO 31000 (2018)", + "display_name": "ISO/IEC 31000:2018 - Risk management - Guidelines", "scf_to_framework": { "total_mappings": 53, "mappings": { diff --git a/docs/api/crosswalks/general-iso-31010-2009.json b/docs/api/crosswalks/general-iso-31010-2009.json index 15aab896..d3b3ef66 100644 --- a/docs/api/crosswalks/general-iso-31010-2009.json +++ b/docs/api/crosswalks/general-iso-31010-2009.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-31010-2009", - "display_name": "ISO 31010 (2009)", + "display_name": "ISO/IEC 31010:2019 - Risk management - Risk assessment techniques", "scf_to_framework": { "total_mappings": 31, "mappings": { diff --git a/docs/api/crosswalks/general-iso-42001-2023.json b/docs/api/crosswalks/general-iso-42001-2023.json index 27c8b621..4d7eaf06 100644 --- a/docs/api/crosswalks/general-iso-42001-2023.json +++ b/docs/api/crosswalks/general-iso-42001-2023.json @@ -1,6 +1,6 @@ { "framework_id": "general-iso-42001-2023", - "display_name": "ISO 42001 (2023)", + "display_name": "ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system", "scf_to_framework": { "total_mappings": 149, "mappings": { diff --git a/docs/api/crosswalks/general-mitre-att&ck-16-1.json b/docs/api/crosswalks/general-mitre-att_ck-16-1.json similarity index 99% rename from docs/api/crosswalks/general-mitre-att&ck-16-1.json rename to docs/api/crosswalks/general-mitre-att_ck-16-1.json index 4d2ddf82..f4a036ff 100644 --- a/docs/api/crosswalks/general-mitre-att&ck-16-1.json +++ b/docs/api/crosswalks/general-mitre-att_ck-16-1.json @@ -1,6 +1,6 @@ { - "framework_id": "general-mitre-att&ck-16-1", - "display_name": "MITRE ATT&CK (v16.1)", + "framework_id": "general-mitre-att_ck-16-1", + "display_name": "MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) - NIST 800 - 53 mappings", "scf_to_framework": { "total_mappings": 108, "mappings": { diff --git a/docs/api/crosswalks/general-mpa-csbp-5-3-1.json b/docs/api/crosswalks/general-mpa-csbp-5-3-1.json index 2d40eee6..913bf2a7 100644 --- a/docs/api/crosswalks/general-mpa-csbp-5-3-1.json +++ b/docs/api/crosswalks/general-mpa-csbp-5-3-1.json @@ -1,6 +1,6 @@ { "framework_id": "general-mpa-csbp-5-3-1", - "display_name": "Content Security Best Practices Common Guidelines (v5.3.1)", + "display_name": "Motion Picture Association (MPA) Content Security Best Practices Common Guidelines v5.3.1", "scf_to_framework": { "total_mappings": 232, "mappings": { diff --git a/docs/api/crosswalks/general-naic-insurance-data-security-model-law-668-2017.json b/docs/api/crosswalks/general-naic-insurance-data-security-model-law-668-2017.json index 36a1261a..a13296de 100644 --- a/docs/api/crosswalks/general-naic-insurance-data-security-model-law-668-2017.json +++ b/docs/api/crosswalks/general-naic-insurance-data-security-model-law-668-2017.json @@ -1,6 +1,6 @@ { "framework_id": "general-naic-insurance-data-security-model-law-668-2017", - "display_name": "Insurance Data Security Model Law 668 (2017)", + "display_name": "National Association of Insurance Commissioners (NAIC) Insurance Data Security Model Law (MDL - 668) (2017)", "scf_to_framework": { "total_mappings": 58, "mappings": { diff --git a/docs/api/crosswalks/general-nist-100-1-ai-rmf.json b/docs/api/crosswalks/general-nist-100-1-ai-rmf.json index ccd88644..4d6f2934 100644 --- a/docs/api/crosswalks/general-nist-100-1-ai-rmf.json +++ b/docs/api/crosswalks/general-nist-100-1-ai-rmf.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-100-1-ai-rmf", - "display_name": "NIST AI 100-1 (AI RMF 1.0)", + "display_name": "NIST AI 100 - 1 - Artificial Intelligence Risk Management Framework (AI RMF 1.0)", "scf_to_framework": { "total_mappings": 158, "mappings": { diff --git a/docs/api/crosswalks/general-nist-600-1-gen-ai-profile.json b/docs/api/crosswalks/general-nist-600-1-gen-ai-profile.json index 91d473f9..ce69487b 100644 --- a/docs/api/crosswalks/general-nist-600-1-gen-ai-profile.json +++ b/docs/api/crosswalks/general-nist-600-1-gen-ai-profile.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-600-1-gen-ai-profile", - "display_name": "NIST AI 600-1", + "display_name": "NIST AI 600 - 1 - Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", "scf_to_framework": { "total_mappings": 139, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-160-vol-2-r1.json b/docs/api/crosswalks/general-nist-800-160-vol-2-r1.json index 9af95ca7..c2a059b8 100644 --- a/docs/api/crosswalks/general-nist-800-160-vol-2-r1.json +++ b/docs/api/crosswalks/general-nist-800-160-vol-2-r1.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-160-vol-2-r1", - "display_name": "NIST SP 800-160 (Vol 2, Rev 1)", + "display_name": "NIST SP 800 - 160 Volume 2, Revision 1 - Developing Cyber - Resilient Systems: A Systems Security Engineering Approach", "scf_to_framework": { "total_mappings": 204, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-161-r1-cscrm.json b/docs/api/crosswalks/general-nist-800-161-r1-cscrm.json index e1393332..f7b04b0c 100644 --- a/docs/api/crosswalks/general-nist-800-161-r1-cscrm.json +++ b/docs/api/crosswalks/general-nist-800-161-r1-cscrm.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-161-r1-cscrm", - "display_name": "NIST SP 800-161 R1 UDP1 - C-SCRM Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - C - SCRM Baseline", "scf_to_framework": { "total_mappings": 132, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-161-r1-flowdown.json b/docs/api/crosswalks/general-nist-800-161-r1-flowdown.json index 275ea40a..720c6c3a 100644 --- a/docs/api/crosswalks/general-nist-800-161-r1-flowdown.json +++ b/docs/api/crosswalks/general-nist-800-161-r1-flowdown.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-161-r1-flowdown", - "display_name": "NIST SP 800-161 R1 UDP1 - Flow Down Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Flow Down Baseline", "scf_to_framework": { "total_mappings": 107, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-161-r1-level-1.json b/docs/api/crosswalks/general-nist-800-161-r1-level-1.json index a0fac6c1..975f20ec 100644 --- a/docs/api/crosswalks/general-nist-800-161-r1-level-1.json +++ b/docs/api/crosswalks/general-nist-800-161-r1-level-1.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-161-r1-level-1", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 1 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 1 Baseline", "scf_to_framework": { "total_mappings": 95, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-161-r1-level-2.json b/docs/api/crosswalks/general-nist-800-161-r1-level-2.json index 45a742e1..932efa0b 100644 --- a/docs/api/crosswalks/general-nist-800-161-r1-level-2.json +++ b/docs/api/crosswalks/general-nist-800-161-r1-level-2.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-161-r1-level-2", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 2 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 2 Baseline", "scf_to_framework": { "total_mappings": 273, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-161-r1-level-3.json b/docs/api/crosswalks/general-nist-800-161-r1-level-3.json index 3b966392..29ec9ad9 100644 --- a/docs/api/crosswalks/general-nist-800-161-r1-level-3.json +++ b/docs/api/crosswalks/general-nist-800-161-r1-level-3.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-161-r1-level-3", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 3 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 3 Baseline", "scf_to_framework": { "total_mappings": 284, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-161-r1.json b/docs/api/crosswalks/general-nist-800-161-r1.json index 0b6d4fb1..c2d94ba8 100644 --- a/docs/api/crosswalks/general-nist-800-161-r1.json +++ b/docs/api/crosswalks/general-nist-800-161-r1.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-161-r1", - "display_name": "NIST SP 800-161 R1 UDP1", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations", "scf_to_framework": { "total_mappings": 341, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-171-r2.json b/docs/api/crosswalks/general-nist-800-171-r2.json index 81a53a22..d7b9428f 100644 --- a/docs/api/crosswalks/general-nist-800-171-r2.json +++ b/docs/api/crosswalks/general-nist-800-171-r2.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-171-r2", - "display_name": "NIST SP 800-171 R2", + "display_name": "NIST SP 800 - 171 R2 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", "scf_to_framework": { "total_mappings": 251, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-171-r3.json b/docs/api/crosswalks/general-nist-800-171-r3.json index 148b26f2..fbcbf6ae 100644 --- a/docs/api/crosswalks/general-nist-800-171-r3.json +++ b/docs/api/crosswalks/general-nist-800-171-r3.json @@ -1,8 +1,8 @@ { "framework_id": "general-nist-800-171-r3", - "display_name": "NIST SP 800-171 R3", + "display_name": "NIST SP 800 - 171 R3 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", "scf_to_framework": { - "total_mappings": 407, + "total_mappings": 414, "mappings": { "GOV-01": [ "03.15.01.a" @@ -25,6 +25,7 @@ ], "GOV-15": [ "03.15.01.a", + "03.16.01", "03.17.01.a" ], "GOV-15.1": [ @@ -56,6 +57,9 @@ "AST-01.1": [ "03.01.03" ], + "AST-01.4": [ + "03.04.08.c" + ], "AST-02": [ "03.04.08.a", "03.04.08.c", @@ -79,8 +83,7 @@ "AST-02.9": [ "03.04.08.a", "03.04.10.a", - "03.04.10.b", - "03.04.10.c" + "03.04.10.b" ], "AST-03": [ "03.09.02.a.03" @@ -154,17 +157,21 @@ ], "CHG-01": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.d" ], "CHG-02": [ "03.04.02.b", "03.04.03.a", "03.04.03.b", - "03.04.03.c" + "03.04.03.c", + "03.07.05.a" ], "CHG-02.1": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.b", + "03.07.05.a" ], "CHG-02.2": [ "03.04.03.b", @@ -198,7 +205,8 @@ "03.12.01" ], "CPL-01.1": [ - "03.12.02.a.01" + "03.12.02.a.01", + "03.12.02.a.02" ], "CPL-01.2": [ "03.04.11.a", @@ -216,14 +224,17 @@ "03.12.03" ], "CPL-03.2": [ + "03.04.02.b", "03.04.08.c", "03.12.03" ], "CFG-01": [ - "03.04.01.a" + "03.04.01.a", + "03.04.03.a" ], "CFG-02": [ "03.01.01.h", + "03.01.03", "03.01.08.a", "03.01.08.b", "03.01.09", @@ -233,32 +244,38 @@ "03.01.11", "03.01.12.a", "03.01.16.a", + "03.01.16.c", "03.01.18.a", + "03.03.08.a", "03.04.01.a", "03.04.02.a", + "03.04.02.b", "03.04.06.a", "03.04.06.b", "03.04.06.d", + "03.05.04", + "03.05.07.c", "03.05.07.d", "03.05.07.e", "03.05.07.f", "03.05.12.d", + "03.07.05.b", "03.08.07.a", "03.13.12.b" ], "CFG-02.1": [ "03.04.01.b", - "03.04.02.b" + "03.04.06.c" ], "CFG-02.2": [ "03.04.02.b", - "03.04.03.d" + "03.04.03.d", + "03.13.13.b" ], "CFG-02.5": [ "03.04.01.a", "03.04.02.a", "03.04.06.a", - "03.04.06.b", "03.04.06.d", "03.04.12.a" ], @@ -316,7 +333,8 @@ "MON-01": [ "03.03.01.a", "03.12.03", - "03.14.06.a" + "03.14.06.a", + "03.14.06.a.02" ], "MON-01.1": [ "03.13.01.a" @@ -333,7 +351,6 @@ "03.14.06.c" ], "MON-01.8": [ - "03.03.01.b", "03.03.05.a" ], "MON-01.12": [ @@ -352,13 +369,15 @@ "03.03.05.c" ], "MON-02.2": [ - "03.03.01.b", "03.03.05.a", "03.03.05.c" ], "MON-02.3": [ "03.03.05.c" ], + "MON-02.6": [ + "03.03.01.b" + ], "MON-02.7": [ "03.03.01.a" ], @@ -379,6 +398,9 @@ "MON-03.3": [ "03.01.07.b" ], + "MON-03.6": [ + "03.03.01.b" + ], "MON-05": [ "03.03.04.b" ], @@ -396,7 +418,8 @@ "MON-08": [ "03.03.03.b", "03.03.06.b", - "03.03.08.a" + "03.03.08.a", + "03.03.08.b" ], "MON-08.1": [ "03.03.08.a" @@ -439,10 +462,12 @@ "03.13.11" ], "CRY-03": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "CRY-05": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "CRY-05.1": [ "03.13.08" @@ -531,7 +556,8 @@ ], "DCH-07": [ "03.08.05.a", - "03.08.05.b" + "03.08.05.b", + "03.08.05.c" ], "DCH-07.1": [ "03.08.05.a", @@ -605,6 +631,7 @@ ], "DCH-18": [ "03.01.20.c.02", + "03.10.07.b", "03.14.08" ], "DCH-19": [ @@ -614,7 +641,11 @@ "DCH-21": [ "03.08.03" ], + "DCH-24": [ + "03.04.11.a" + ], "END-01": [ + "03.01.03", "03.14.02.a" ], "END-04": [ @@ -661,16 +692,19 @@ "03.01.01.d.02", "03.01.02", "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.15.03.b" ], "HRS-02.1": [ "03.01.02" ], "HRS-03": [ "03.01.22.a", + "03.02.02.a.01", "03.06.04.a", "03.06.05.d", "03.07.06.a", + "03.07.06.d", "03.08.02", "03.15.03.b", "03.16.03.b" @@ -684,7 +718,8 @@ ], "HRS-04": [ "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.09.02.b.01" ], "HRS-04.1": [ "03.01.22.a", @@ -702,7 +737,8 @@ "HRS-05": [ "03.01.01.h", "03.01.22.a", - "03.15.03.a" + "03.15.03.a", + "03.15.03.b" ], "HRS-05.1": [ "03.01.12.a", @@ -728,14 +764,12 @@ "03.15.03.a" ], "HRS-05.7": [ - "03.15.03.b", "03.15.03.c", "03.15.03.d" ], "HRS-06": [ "03.01.18.a", "03.12.05.a", - "03.15.03.b", "03.15.03.c" ], "HRS-06.1": [ @@ -753,12 +787,14 @@ "HRS-08": [ "03.01.01.g.02", "03.09.02.a", - "03.09.02.b.01" + "03.09.02.b.01", + "03.09.02.b.02" ], "HRS-09": [ "03.01.01.f.03", "03.01.01.g.02", "03.09.02.a", + "03.09.02.a.02", "03.09.02.a.03", "03.09.02.b.01" ], @@ -792,6 +828,8 @@ "03.05.12.e" ], "IAC-01.2": [ + "03.01.01.d.01", + "03.01.16.b", "03.05.01.a", "03.05.02", "03.05.05.d", @@ -801,7 +839,6 @@ "03.05.07.d", "03.05.07.e", "03.05.12.d", - "03.05.12.f", "03.07.05.a" ], "IAC-02": [ @@ -839,7 +876,11 @@ "IAC-06.3": [ "03.05.03" ], + "IAC-06.4": [ + "03.05.03" + ], "IAC-07": [ + "03.01.01.b", "03.01.01.g.01", "03.01.01.g.02", "03.01.01.g.03", @@ -904,10 +945,8 @@ "03.05.07.e", "03.05.07.f", "03.05.12.b", - "03.05.12.c", "03.05.12.d", - "03.05.12.e", - "03.05.12.f" + "03.05.12.e" ], "IAC-10.3": [ "03.05.12.a" @@ -950,6 +989,7 @@ "03.01.01.d.02", "03.01.01.e", "03.01.01.f.01", + "03.01.01.f.02", "03.01.01.f.03", "03.01.01.f.04", "03.01.01.f.05", @@ -959,9 +999,11 @@ "03.01.02", "03.01.05.b", "03.01.05.c", - "03.01.05.d" + "03.01.05.d", + "03.05.07.e" ], "IAC-15.1": [ + "03.01.01.d.01", "03.05.05.b", "03.05.05.c", "03.05.05.d", @@ -984,6 +1026,7 @@ "03.01.01.f.05" ], "IAC-15.7": [ + "03.01.01.b", "03.01.01.e", "03.01.05.c" ], @@ -1019,6 +1062,7 @@ "03.01.03", "03.01.04.b", "03.01.05.a", + "03.01.05.b", "03.06.05.d", "03.10.01.a" ], @@ -1026,6 +1070,7 @@ "03.01.01.c.03", "03.01.01.d.01", "03.01.01.d.02", + "03.01.02", "03.01.04.b", "03.01.05.a", "03.01.05.b", @@ -1065,8 +1110,7 @@ "03.07.05.c" ], "IAC-28": [ - "03.05.12.a", - "03.05.12.c" + "03.05.12.a" ], "IAC-28.1": [ "03.01.01.b", @@ -1081,7 +1125,8 @@ "03.06.02.a", "03.06.02.b", "03.06.02.c", - "03.06.02.d" + "03.06.02.d", + "03.06.05.b" ], "IRO-04": [ "03.06.01", @@ -1092,10 +1137,10 @@ "03.06.05.a.04", "03.06.05.a.05", "03.06.05.a.06", - "03.06.05.b" + "03.06.05.b", + "03.06.05.d" ], "IRO-04.2": [ - "03.06.04.b", "03.06.05.c" ], "IRO-04.3": [ @@ -1108,13 +1153,18 @@ "IRO-06": [ "03.06.03" ], + "IRO-07": [ + "03.06.02.b", + "03.06.02.d" + ], "IRO-09": [ "03.06.02.a", "03.06.02.b" ], "IRO-10": [ "03.06.02.b", - "03.06.02.c" + "03.06.02.c", + "03.06.02.d" ], "IRO-10.2": [ "03.06.02.b", @@ -1124,6 +1174,7 @@ "03.06.02.d" ], "IRO-12": [ + "03.01.22.b", "03.06.01" ], "IRO-13": [ @@ -1142,6 +1193,8 @@ "03.12.01" ], "IAO-03": [ + "03.01.16.a", + "03.04.11.a", "03.04.11.b", "03.15.02.a", "03.15.02.a.01", @@ -1215,12 +1268,10 @@ "03.07.06.d" ], "MNT-06.1": [ - "03.07.06.a", "03.07.06.c", "03.07.06.d" ], "MNT-06.2": [ - "03.07.06.a", "03.07.06.c" ], "MNT-09": [ @@ -1255,7 +1306,6 @@ "NET-01": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.18.a", "03.13.01.a" ], @@ -1268,6 +1318,7 @@ ], "NET-03": [ "03.01.12.a", + "03.01.18.a", "03.13.01.a", "03.13.01.b", "03.13.01.c" @@ -1292,7 +1343,6 @@ ], "NET-05.2": [ "03.01.03", - "03.12.05.a", "03.12.05.b", "03.12.05.c" ], @@ -1303,6 +1353,7 @@ "03.13.01.b" ], "NET-07": [ + "03.07.05.c", "03.13.09" ], "NET-08": [ @@ -1318,8 +1369,7 @@ "NET-14": [ "03.01.12.a", "03.01.12.b", - "03.01.12.c", - "03.01.12.d" + "03.01.12.c" ], "NET-14.1": [ "03.01.12.b" @@ -1328,7 +1378,6 @@ "03.01.12.a" ], "NET-14.3": [ - "03.01.12.b", "03.01.12.c" ], "NET-14.4": [ @@ -1336,7 +1385,6 @@ ], "NET-14.5": [ "03.01.12.a", - "03.01.12.c", "03.10.06.a", "03.10.06.b" ], @@ -1363,24 +1411,29 @@ "03.08.01", "03.08.02", "03.10.01.a", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "PES-02": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.a", "03.10.01.b", "03.10.01.c", "03.10.01.d", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "PES-02.1": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.b", "03.10.01.d" ], "PES-03": [ + "03.04.05", "03.10.02.a", "03.10.07.a", "03.10.07.a.01", @@ -1390,10 +1443,12 @@ "PES-03.1": [ "03.10.02.a", "03.10.07.a", + "03.10.07.a.01", "03.10.07.a.02" ], "PES-03.3": [ "03.10.02.a", + "03.10.07.a.02", "03.10.07.b" ], "PES-03.4": [ @@ -1419,19 +1474,18 @@ "03.10.02.b" ], "PES-05.1": [ - "03.10.02.a", - "03.10.02.b" + "03.10.02.a" ], "PES-05.2": [ "03.10.02.a", "03.10.02.b" ], "PES-06": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "PES-06.1": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "PES-06.2": [ @@ -1468,7 +1522,8 @@ ], "RSK-01": [ "03.11.01.a", - "03.17.01.a" + "03.17.01.a", + "03.17.03.b" ], "RSK-01.1": [ "03.11.01.a" @@ -1484,6 +1539,7 @@ "03.11.01.a" ], "RSK-03.1": [ + "03.11.01.a", "03.15.02.a.03" ], "RSK-04": [ @@ -1525,7 +1581,6 @@ "SEA-01": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.16.c", "03.01.18.a", "03.13.01.c", @@ -1565,17 +1620,22 @@ "03.15.01.a" ], "OPS-03": [ - "03.15.01.b" + "03.15.01.a" ], "SAT-01": [ "03.02.01.a" ], + "SAT-01.1": [ + "03.02.01.b", + "03.02.02.a.02", + "03.02.02.b", + "03.06.04.b" + ], "SAT-02": [ "03.01.22.a", "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.06.04.a.03" ], "SAT-02.2": [ @@ -1588,11 +1648,10 @@ "03.02.02.a", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a", "03.06.04.a.01", "03.06.04.a.02", - "03.06.04.b" + "03.06.04.a.03" ], "SAT-03.3": [ "03.01.22.a", @@ -1607,15 +1666,10 @@ "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a.02" ], - "SAT-03.7": [ - "03.06.04.b" - ], "TDA-01": [ "03.12.01", "03.12.03", @@ -1664,10 +1718,12 @@ "03.01.20.c.01", "03.07.06.a", "03.16.01", - "03.16.03.a" + "03.16.03.a", + "03.17.02" ], "TPM-01.1": [ - "03.07.06.a" + "03.07.06.a", + "03.07.06.b" ], "TPM-02": [ "03.11.01.a", @@ -1732,6 +1788,7 @@ ], "TPM-05.4": [ "03.07.06.a", + "03.07.06.b", "03.16.03.b" ], "TPM-05.5": [ @@ -1769,13 +1826,12 @@ ], "THR-01": [ "03.11.02.a", + "03.14.01.a", "03.14.03.a" ], "THR-03": [ "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", - "03.02.02.b", "03.11.02.a", "03.14.03.a" ], @@ -1785,6 +1841,9 @@ "THR-05": [ "03.02.01.a.03" ], + "THR-06": [ + "03.14.01.a" + ], "THR-09": [ "03.15.02.a.03" ], @@ -1809,8 +1868,7 @@ ], "VPM-04": [ "03.11.02.b", - "03.14.01.a", - "03.14.01.b" + "03.14.01.a" ], "VPM-05": [ "03.11.02.b", @@ -1819,7 +1877,8 @@ "03.14.01.b" ], "VPM-06": [ - "03.11.02.a" + "03.11.02.a", + "03.14.01.a" ], "VPM-06.1": [ "03.11.02.c" @@ -1845,7 +1904,8 @@ "GOV-15.4", "GOV-15.5", "OPS-01", - "OPS-01.1" + "OPS-01.1", + "OPS-03" ], "03.12.03": [ "GOV-01.1", @@ -1862,8 +1922,7 @@ ], "03.15.01.b": [ "GOV-03", - "OPS-01", - "OPS-03" + "OPS-01" ], "03.15.03.d": [ "GOV-03", @@ -1871,6 +1930,23 @@ "HRS-05.1", "HRS-05.7" ], + "03.16.01": [ + "GOV-15", + "AST-17", + "PRM-01", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-01", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-03", + "TDA-05", + "TDA-06", + "TPM-01", + "TPM-10" + ], "03.17.01.a": [ "GOV-15", "GOV-15.1", @@ -1890,9 +1966,11 @@ "AST-04", "AST-04.3", "AST-31", + "CFG-02", "DCH-01.4", "DCH-03", "DCH-14.3", + "END-01", "IAC-20", "IAC-20.1", "NET-04", @@ -1915,6 +1993,7 @@ "MDM-06", "MDM-07", "NET-01", + "NET-03", "SEA-01", "SEA-02" ], @@ -1929,7 +2008,9 @@ "CPL-01.2", "DCH-02", "DCH-06.2", - "DCH-19" + "DCH-19", + "DCH-24", + "IAO-03" ], "03.07.04.a": [ "AST-01", @@ -1941,6 +2022,12 @@ "MNT-04", "MNT-09" ], + "03.04.08.c": [ + "AST-01.4", + "AST-02", + "CPL-03.2", + "CFG-03.1" + ], "03.04.08.a": [ "AST-02", "AST-02.9", @@ -1948,11 +2035,6 @@ "CFG-03", "CFG-03.3" ], - "03.04.08.c": [ - "AST-02", - "CPL-03.2", - "CFG-03.1" - ], "03.04.10.a": [ "AST-02", "AST-02.1", @@ -1964,8 +2046,7 @@ "AST-02.9" ], "03.04.10.c": [ - "AST-02.1", - "AST-02.9" + "AST-02.1" ], "03.04.02.b": [ "AST-02.4", @@ -1973,7 +2054,8 @@ "CHG-02", "CHG-02.1", "CHG-04", - "CFG-02.1", + "CPL-03.2", + "CFG-02", "CFG-02.2", "CFG-02.7", "CFG-02.9", @@ -2029,6 +2111,7 @@ "RSK-02", "RSK-02.1", "RSK-03", + "RSK-03.1", "RSK-04", "RSK-05", "RSK-09", @@ -2037,22 +2120,6 @@ "TPM-03", "TPM-04.1" ], - "03.16.01": [ - "AST-17", - "PRM-01", - "PRM-05", - "SEA-01", - "SEA-02", - "TDA-01", - "TDA-02", - "TDA-02.3", - "TDA-02.4", - "TDA-03", - "TDA-05", - "TDA-06", - "TPM-01", - "TPM-10" - ], "03.04.12.a": [ "AST-24", "CFG-02.5", @@ -2080,8 +2147,7 @@ "03.01.12.c": [ "AST-27", "NET-14", - "NET-14.3", - "NET-14.5" + "NET-14.3" ], "03.08.09.a": [ "BCD-11", @@ -2094,10 +2160,16 @@ "CHG-01", "CHG-02", "CHG-02.1", + "CFG-01", "CFG-06" ], + "03.04.03.d": [ + "CHG-01", + "CFG-02.2" + ], "03.04.03.b": [ "CHG-02", + "CHG-02.1", "CHG-02.2", "CHG-03" ], @@ -2107,6 +2179,16 @@ "MNT-01", "MNT-02" ], + "03.07.05.a": [ + "CHG-02", + "CHG-02.1", + "IAC-01.2", + "IAC-05.2", + "MNT-02", + "MNT-05", + "MNT-05.1", + "MNT-05.5" + ], "03.04.04.a": [ "CHG-02.2", "CHG-02.3", @@ -2116,7 +2198,10 @@ "CHG-04", "CHG-04.4", "IAC-08", - "IAC-21" + "IAC-21", + "PES-02", + "PES-02.1", + "PES-03" ], "03.04.04.b": [ "CHG-06" @@ -2137,6 +2222,14 @@ "IAO-05", "RSK-04.1" ], + "03.12.02.a.02": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1", + "RSK-06", + "VPM-02", + "VPM-05" + ], "03.04.01.a": [ "CFG-01", "CFG-02", @@ -2183,6 +2276,7 @@ "03.01.16.a": [ "CFG-02", "CRY-07", + "IAO-03", "NET-01", "NET-02.2", "NET-15", @@ -2191,6 +2285,20 @@ "SEA-01", "SEA-02" ], + "03.01.16.c": [ + "CFG-02", + "NET-15.2", + "NET-15.3", + "SEA-01" + ], + "03.03.08.a": [ + "CFG-02", + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-08.3", + "IAC-21" + ], "03.04.02.a": [ "CFG-02", "CFG-02.5", @@ -2200,7 +2308,6 @@ ], "03.04.06.b": [ "CFG-02", - "CFG-02.5", "CFG-03" ], "03.04.06.d": [ @@ -2208,6 +2315,18 @@ "CFG-02.5", "CFG-03" ], + "03.05.04": [ + "CFG-02", + "IAC-02.2" + ], + "03.05.07.c": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.11", + "IAC-15.1" + ], "03.05.07.d": [ "CFG-02", "IAC-01.2", @@ -2223,6 +2342,7 @@ "IAC-10", "IAC-10.1", "IAC-10.8", + "IAC-15", "IAC-15.1" ], "03.05.07.f": [ @@ -2240,6 +2360,13 @@ "IAC-10.8", "IAC-15.1" ], + "03.07.05.b": [ + "CFG-02", + "IAC-02.2", + "IAC-06", + "MNT-05", + "MNT-05.3" + ], "03.08.07.a": [ "CFG-02", "DCH-10", @@ -2252,8 +2379,17 @@ "03.04.01.b": [ "CFG-02.1" ], - "03.04.03.d": [ - "CFG-02.2" + "03.04.06.c": [ + "CFG-02.1", + "CFG-03.1" + ], + "03.13.13.b": [ + "CFG-02.2", + "CFG-03.3", + "CFG-04", + "CFG-04.1", + "CFG-05", + "END-10" ], "03.03.02.b": [ "CFG-02.9", @@ -2262,10 +2398,9 @@ "03.13.11": [ "CFG-02.9", "CRY-01", - "CRY-01.5" - ], - "03.04.06.c": [ - "CFG-03.1" + "CRY-01.5", + "CRY-03", + "CRY-05" ], "03.04.08.b": [ "CFG-03.2", @@ -2275,13 +2410,6 @@ "CFG-03.3", "END-10" ], - "03.13.13.b": [ - "CFG-03.3", - "CFG-04", - "CFG-04.1", - "CFG-05", - "END-10" - ], "03.01.02": [ "CFG-08", "DCH-01.2", @@ -2291,7 +2419,8 @@ "IAC-08", "IAC-15", "IAC-20", - "IAC-20.1" + "IAC-20.1", + "IAC-21" ], "03.03.01.a": [ "MON-01", @@ -2303,6 +2432,12 @@ "03.14.06.a": [ "MON-01" ], + "03.14.06.a.02": [ + "MON-01", + "MON-11.3", + "MON-16", + "END-07" + ], "03.13.01.a": [ "MON-01.1", "MON-01.3", @@ -2336,10 +2471,6 @@ "MON-16", "END-07" ], - "03.03.01.b": [ - "MON-01.8", - "MON-02.2" - ], "03.03.05.a": [ "MON-01.8", "MON-02", @@ -2367,6 +2498,10 @@ "MON-02.2", "MON-02.3" ], + "03.03.01.b": [ + "MON-02.6", + "MON-03.6" + ], "03.03.02.a": [ "MON-03" ], @@ -2409,14 +2544,8 @@ "03.03.06.b": [ "MON-08" ], - "03.03.08.a": [ - "MON-08", - "MON-08.1", - "MON-08.2", - "MON-08.3", - "IAC-21" - ], "03.03.08.b": [ + "MON-08", "MON-08.2", "IAC-08", "IAC-21" @@ -2424,13 +2553,9 @@ "03.01.22.b": [ "MON-11", "DCH-15", + "IRO-12", "WEB-14" ], - "03.14.06.a.02": [ - "MON-11.3", - "MON-16", - "END-07" - ], "03.01.01.e": [ "MON-16", "IAC-15", @@ -2453,7 +2578,9 @@ "DCH-01", "DCH-01.2", "HRS-02", + "IAC-01.2", "IAC-15", + "IAC-15.1", "IAC-20", "IAC-20.1", "IAC-21" @@ -2535,7 +2662,8 @@ "DCH-01.2", "HRS-03", "IAC-08", - "IAC-20.1" + "IAC-20.1", + "IRO-04" ], "03.08.02": [ "DCH-01.2", @@ -2554,7 +2682,8 @@ "DCH-03.1" ], "03.08.05.c": [ - "DCH-01.3" + "DCH-01.3", + "DCH-07" ], "03.01.04.b": [ "DCH-01.4", @@ -2566,7 +2695,9 @@ "DCH-01.4", "IAC-20.1", "PES-01", - "PES-02" + "PES-02", + "PES-06", + "PES-06.1" ], "03.15.02.c": [ "DCH-01.4", @@ -2611,8 +2742,11 @@ "DCH-14.3", "HRS-06", "HRS-06.1", - "NET-05", - "NET-05.2" + "NET-05" + ], + "03.10.07.b": [ + "DCH-18", + "PES-03.3" ], "03.14.08": [ "DCH-18" @@ -2678,6 +2812,22 @@ "HRS-04", "HRS-04.1" ], + "03.15.03.b": [ + "HRS-02", + "HRS-03", + "HRS-03.1", + "HRS-04.2", + "HRS-05" + ], + "03.02.02.a.01": [ + "HRS-03", + "HRS-04.1", + "HRS-04.2", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" + ], "03.06.04.a": [ "HRS-03", "HRS-04.2", @@ -2689,19 +2839,16 @@ "IAC-08", "MNT-01", "MNT-06", - "MNT-06.1", - "MNT-06.2", "TPM-01", "TPM-01.1", "TPM-05", "TPM-05.4" ], - "03.15.03.b": [ + "03.07.06.d": [ "HRS-03", - "HRS-03.1", - "HRS-04.2", - "HRS-05.7", - "HRS-06" + "HRS-03.2", + "MNT-06", + "MNT-06.1" ], "03.16.03.b": [ "HRS-03", @@ -2710,18 +2857,11 @@ "TPM-05.2", "TPM-05.4" ], - "03.07.06.d": [ - "HRS-03.2", - "MNT-06", - "MNT-06.1" - ], - "03.02.02.a.01": [ - "HRS-04.1", - "HRS-04.2", - "SAT-03", - "SAT-03.3", - "SAT-03.5", - "SAT-03.6" + "03.09.02.b.01": [ + "HRS-04", + "HRS-08", + "HRS-09", + "HRS-09.2" ], "03.06.04.a.01": [ "HRS-04.2", @@ -2748,22 +2888,23 @@ "HRS-08", "HRS-09" ], - "03.09.02.b.01": [ + "03.09.02.b.02": [ "HRS-08", - "HRS-09", - "HRS-09.2" + "IAC-07.1", + "IAC-20" ], "03.01.01.f.03": [ "HRS-09", "IAC-15" ], - "03.09.02.a.01": [ + "03.09.02.a.02": [ + "HRS-09", "HRS-09.2", "HRS-09.4", "IAC-07", "IAC-07.2" ], - "03.09.02.a.02": [ + "03.09.02.a.01": [ "HRS-09.2", "HRS-09.4", "IAC-07", @@ -2804,6 +2945,12 @@ "IAC-10.1", "IAC-15.1" ], + "03.01.16.b": [ + "IAC-01.2", + "NET-02.2", + "NET-15", + "NET-15.1" + ], "03.05.02": [ "IAC-01.2", "IAC-04", @@ -2829,42 +2976,18 @@ "IAC-10.4", "IAC-10.11" ], - "03.05.07.c": [ - "IAC-01.2", - "IAC-10", - "IAC-10.5", - "IAC-10.11", - "IAC-15.1" - ], - "03.05.12.f": [ - "IAC-01.2", - "IAC-10", - "IAC-10.1", - "IAC-10.5", - "IAC-15.1" - ], - "03.07.05.a": [ - "IAC-01.2", - "IAC-05.2", - "MNT-02", - "MNT-05", - "MNT-05.1", - "MNT-05.5" - ], - "03.05.04": [ - "IAC-02.2" - ], - "03.07.05.b": [ - "IAC-02.2", - "IAC-06", - "MNT-05", - "MNT-05.3" - ], "03.05.03": [ "IAC-06", "IAC-06.1", "IAC-06.2", - "IAC-06.3" + "IAC-06.3", + "IAC-06.4" + ], + "03.01.01.b": [ + "IAC-07", + "IAC-15", + "IAC-15.7", + "IAC-28.1" ], "03.01.01.g.01": [ "IAC-07", @@ -2877,10 +3000,6 @@ "IAC-15", "IAC-17" ], - "03.09.02.b.02": [ - "IAC-07.1", - "IAC-20" - ], "03.01.01.c.03": [ "IAC-08", "IAC-20", @@ -2891,6 +3010,7 @@ "IAC-08", "IAC-15", "IAC-20", + "IAC-20.1", "IAC-21" ], "03.01.06.a": [ @@ -2919,9 +3039,12 @@ "IAC-10.1" ], "03.05.12.c": [ + "IAC-10" + ], + "03.05.12.f": [ "IAC-10", - "IAC-10.1", - "IAC-28" + "IAC-10.5", + "IAC-15.1" ], "03.05.11": [ "IAC-11" @@ -2929,13 +3052,13 @@ "03.05.01.b": [ "IAC-14" ], - "03.01.01.b": [ - "IAC-15", - "IAC-28.1" - ], "03.01.01.f.01": [ "IAC-15" ], + "03.01.01.f.02": [ + "IAC-15", + "IAC-15.3" + ], "03.01.05.c": [ "IAC-15", "IAC-15.7", @@ -2945,9 +3068,6 @@ "IAC-15", "IAC-17" ], - "03.01.01.f.02": [ - "IAC-15.3" - ], "03.01.07.a": [ "IAC-16", "IAC-21", @@ -2974,7 +3094,8 @@ "03.07.05.c": [ "IAC-25", "MNT-05", - "MNT-05.4" + "MNT-05.4", + "NET-07" ], "03.06.01": [ "IRO-01", @@ -2988,6 +3109,7 @@ ], "03.06.02.b": [ "IRO-02", + "IRO-07", "IRO-09", "IRO-10", "IRO-10.2" @@ -3000,8 +3122,14 @@ ], "03.06.02.d": [ "IRO-02", + "IRO-07", + "IRO-10", "IRO-11" ], + "03.06.05.b": [ + "IRO-02", + "IRO-04" + ], "03.06.05.a": [ "IRO-04" ], @@ -3023,22 +3151,18 @@ "03.06.05.a.06": [ "IRO-04" ], - "03.06.05.b": [ - "IRO-04" + "03.06.05.c": [ + "IRO-04.2" ], "03.06.04.b": [ - "IRO-04.2", "IRO-04.3", "IRO-13", - "SAT-03", - "SAT-03.7" - ], - "03.06.05.c": [ - "IRO-04.2" + "SAT-01.1" ], "03.06.04.a.03": [ "IRO-05", - "SAT-02" + "SAT-02", + "SAT-03" ], "03.06.03": [ "IRO-06" @@ -3075,13 +3199,6 @@ "03.12.02.a": [ "IAO-05" ], - "03.12.02.a.02": [ - "IAO-05", - "RSK-04.1", - "RSK-06", - "VPM-02", - "VPM-05" - ], "03.12.02.b": [ "IAO-05" ], @@ -3098,22 +3215,26 @@ "IAO-05", "TDA-01", "TDA-09", + "THR-01", + "THR-06", "VPM-01", "VPM-01.1", "VPM-02", "VPM-04", - "VPM-05" + "VPM-05", + "VPM-06" ], "03.07.04.b": [ "MNT-04.1" ], "03.01.12.d": [ "MNT-05", - "NET-14", "NET-14.4" ], "03.07.06.b": [ - "MNT-06" + "MNT-06", + "TPM-01.1", + "TPM-05.4" ], "03.07.06.c": [ "MNT-06", @@ -3123,13 +3244,6 @@ "03.01.18.c": [ "MDM-03" ], - "03.01.16.b": [ - "NET-01", - "NET-02.2", - "NET-15", - "NET-15.1", - "SEA-01" - ], "03.13.01.b": [ "NET-02", "NET-03", @@ -3162,8 +3276,7 @@ ], "03.01.12.b": [ "NET-14", - "NET-14.1", - "NET-14.3" + "NET-14.1" ], "03.10.06.a": [ "NET-14.5", @@ -3176,17 +3289,21 @@ "03.01.16.d": [ "NET-15.1" ], - "03.01.16.c": [ - "NET-15.2", - "NET-15.3", - "SEA-01" - ], "03.10.07.a": [ "PES-01", "PES-02", "PES-03", "PES-03.1" ], + "03.10.07.a.01": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1", + "PES-03.4", + "PES-04", + "PES-04.1" + ], "03.10.01.b": [ "PES-02", "PES-02.1" @@ -3199,15 +3316,10 @@ "PES-05.1", "PES-05.2" ], - "03.10.07.a.01": [ - "PES-03", - "PES-03.4", - "PES-04", - "PES-04.1" - ], "03.10.07.a.02": [ "PES-03", "PES-03.1", + "PES-03.3", "PES-03.4", "PES-04", "PES-04.1" @@ -3217,15 +3329,9 @@ "PES-04", "PES-04.1" ], - "03.10.07.b": [ - "PES-03.3" - ], "03.10.02.b": [ "PES-05", - "PES-05.1", - "PES-05.2", - "PES-06", - "PES-06.1" + "PES-05.2" ], "03.10.07.c": [ "PES-06", @@ -3243,6 +3349,20 @@ "PES-12", "PES-12.2" ], + "03.17.03.b": [ + "RSK-01", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7" + ], "03.14.03.b": [ "RSK-02.1", "THR-03.1", @@ -3278,19 +3398,6 @@ "TPM-04.1", "TPM-05.5" ], - "03.17.03.b": [ - "RSK-09", - "TPM-03", - "TPM-03.1", - "TPM-03.2", - "TPM-03.3", - "TPM-04", - "TPM-04.1", - "TPM-05", - "TPM-05.2", - "TPM-05.5", - "TPM-05.7" - ], "03.13.04": [ "SEA-05" ], @@ -3306,6 +3413,17 @@ "03.02.01.a": [ "SAT-01" ], + "03.02.01.b": [ + "SAT-01.1" + ], + "03.02.02.a.02": [ + "SAT-01.1", + "SAT-03", + "SAT-03.6" + ], + "03.02.02.b": [ + "SAT-01.1" + ], "03.02.01.a.01": [ "SAT-02", "SAT-03", @@ -3326,29 +3444,16 @@ "THR-03", "THR-05" ], - "03.02.01.b": [ - "SAT-02", - "SAT-03.6", - "THR-03" - ], "03.02.02.a": [ "SAT-03" ], - "03.02.02.a.02": [ - "SAT-03", - "SAT-03.6" - ], - "03.02.02.b": [ - "SAT-03", - "SAT-03.6", - "THR-03" - ], "03.06.04.a.02": [ "SAT-03", "SAT-03.6" ], "03.17.02": [ "TDA-01", + "TPM-01", "TPM-03.1", "TPM-04", "TPM-04.1", @@ -3391,7 +3496,6 @@ "THR-03" ], "03.14.01.b": [ - "VPM-04", "VPM-05" ], "03.11.02.c": [ diff --git a/docs/api/crosswalks/general-nist-800-171a-r3.json b/docs/api/crosswalks/general-nist-800-171a-r3.json index 75986e21..a59881fb 100644 --- a/docs/api/crosswalks/general-nist-800-171a-r3.json +++ b/docs/api/crosswalks/general-nist-800-171a-r3.json @@ -1,9 +1,18 @@ { "framework_id": "general-nist-800-171a-r3", - "display_name": "NIST SP 800-171A R3", + "display_name": "NIST SP 800 - 171A R3 - Assessing Security Requirements for Controlled Unclassified Information", "scf_to_framework": { - "total_mappings": 215, + "total_mappings": 414, "mappings": { + "GOV-01": [ + "A.03.15.01.a[01]" + ], + "GOV-01.1": [ + "A.03.12.03[01]" + ], + "GOV-01.2": [ + "A.03.12.03[01]" + ], "GOV-02": [ "A.03.15.01.a[01]", "A.03.15.01.a[02]", @@ -13,25 +22,70 @@ "GOV-03": [ "A.03.15.01.ODP[01]", "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.b[02]", + "A.03.15.03.d[01]" + ], + "GOV-05": [ + "A.03.12.03[01]" ], "GOV-15": [ - "A.03.16.01" + "A.03.15.01.a[03]", + "A.03.16.01", + "A.03.17.01.a[01]" + ], + "GOV-15.1": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "GOV-15.2": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "GOV-15.3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "GOV-15.4": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "GOV-15.5": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" + ], + "AST-01": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.18.a[01]", + "A.03.04.11.a[02]", + "A.03.07.04.a[01]" + ], + "AST-01.1": [ + "A.03.01.03[02]" ], "AST-01.4": [ "A.03.04.08.c" ], "AST-02": [ + "A.03.04.08.a", + "A.03.04.08.c", "A.03.04.10.ODP[01]", "A.03.04.10.a", "A.03.04.10.b[01]", - "A.03.04.10.b[02]" + "A.03.04.10.b[02]", + "A.03.04.11.a[02]" ], "AST-02.1": [ + "A.03.04.10.a", + "A.03.04.10.b[02]", "A.03.04.10.c[01]", "A.03.04.10.c[02]", "A.03.04.10.c[03]" ], + "AST-02.4": [ + "A.03.04.02.a[02]", + "A.03.04.06.a" + ], "AST-02.8": [ "A.03.04.11.a[01]", "A.03.04.11.a[02]", @@ -39,37 +93,123 @@ "A.03.04.11.b[01]", "A.03.04.11.b[02]" ], + "AST-02.9": [ + "A.03.04.08.a", + "A.03.04.10.a", + "A.03.04.10.b[02]" + ], + "AST-03": [ + "A.03.09.02.a.03" + ], + "AST-03.1": [ + "A.03.09.02.a.03" + ], + "AST-04": [ + "A.03.01.03[02]", + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "AST-04.1": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "AST-04.2": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "AST-04.3": [ + "A.03.01.03[02]" + ], + "AST-05": [ + "A.03.07.04.a[02]" + ], + "AST-09": [ + "A.03.07.04.c", + "A.03.08.03" + ], "AST-10": [ "A.03.09.02.a.03" ], + "AST-12": [ + "A.03.01.18.a[01]" + ], + "AST-13": [ + "A.03.01.18.a[01]" + ], + "AST-14": [ + "A.03.01.18.a[01]" + ], + "AST-16": [ + "A.03.01.18.a[01]" + ], + "AST-17": [ + "A.03.11.01.a", + "A.03.16.01" + ], "AST-24": [ - "A.03.04.12.a" + "A.03.04.12.a", + "A.03.04.12.b" ], "AST-25": [ "A.03.04.12.b" ], + "AST-27": [ + "A.03.01.12.a[01]", + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" + ], + "AST-31": [ + "A.03.01.03[02]" + ], + "BCD-11": [ + "A.03.08.09.a" + ], "BCD-11.4": [ "A.03.08.09.a", "A.03.08.09.b" ], "CHG-01": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.d[01]", "A.03.04.03.d[02]" ], "CHG-02": [ + "A.03.04.02.b[01]", "A.03.04.03.a", - "A.03.04.03.c[01]" + "A.03.04.03.b[02]", + "A.03.04.03.c[01]", + "A.03.07.05.a[01]" ], "CHG-02.1": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.b[02]", - "A.03.04.05[05]" + "A.03.04.05[05]", + "A.03.07.05.a[01]" ], "CHG-02.2": [ - "A.03.04.03.c[02]" + "A.03.04.03.b[02]", + "A.03.04.03.c[02]", + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "CHG-02.3": [ + "A.03.04.04.a" ], "CHG-03": [ "A.03.04.03.b[01]", - "A.03.04.04.a" + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "CHG-04": [ + "A.03.04.02.b[01]", + "A.03.04.05[06]" ], "CHG-04.4": [ "A.03.04.05[06]" @@ -81,25 +221,52 @@ "CHG-06": [ "A.03.04.04.b" ], + "CPL-01": [ + "A.03.04.11.a[01]", + "A.03.12.01" + ], + "CPL-01.1": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" + ], + "CPL-01.2": [ + "A.03.04.11.a[01]" + ], "CPL-02": [ + "A.03.12.01", "A.03.12.03[01]", "A.03.12.03[03]", "A.03.12.03[04]" ], "CPL-02.1": [ - "A.03.12.01.ODP[01]" + "A.03.12.01.ODP[01]", + "A.03.12.01" ], "CPL-03": [ - "A.03.12.01" + "A.03.12.01", + "A.03.12.03[01]" ], "CPL-03.2": [ + "A.03.04.02.b[01]", + "A.03.04.08.c", "A.03.12.03[02]" ], "CFG-01": [ + "A.03.04.01.a[02]", "A.03.04.03.a" ], "CFG-02": [ + "A.03.01.01.h", "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.08.a", + "A.03.01.08.b", + "A.03.01.09", + "A.03.01.10.a", + "A.03.01.10.b", + "A.03.01.10.c", + "A.03.01.11", + "A.03.01.12.a[03]", "A.03.01.16.a[03]", "A.03.01.16.c", "A.03.01.18.a[02]", @@ -113,18 +280,23 @@ "A.03.04.06.ODP[03]", "A.03.04.06.ODP[04]", "A.03.04.06.ODP[05]", + "A.03.04.06.a", "A.03.04.06.b[01]", "A.03.04.06.b[02]", "A.03.04.06.b[03]", "A.03.04.06.b[04]", "A.03.04.06.b[05]", + "A.03.04.06.d", "A.03.05.04[01]", "A.03.05.04[02]", "A.03.05.07.c", "A.03.05.07.d", "A.03.05.07.e", "A.03.05.07.f", - "A.03.07.05.b[02]" + "A.03.05.12.d", + "A.03.07.05.b[01]", + "A.03.08.07.a", + "A.03.13.12.b" ], "CFG-02.1": [ "A.03.04.01.ODP[01]", @@ -135,72 +307,145 @@ "A.03.04.06.c" ], "CFG-02.2": [ + "A.03.04.02.b[01]", "A.03.04.03.d[01]", - "A.03.04.03.d[02]" + "A.03.04.03.d[02]", + "A.03.13.13.b[02]" ], "CFG-02.5": [ + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.d", "A.03.04.12.ODP[01]", - "A.03.04.12.ODP[02]" + "A.03.04.12.ODP[02]", + "A.03.04.12.a" ], "CFG-02.7": [ - "A.03.04.02.b[01]", + "A.03.04.01.a[01]", "A.03.04.02.b[02]" ], "CFG-02.9": [ - "A.03.03.02.b" + "A.03.03.02.b", + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.06.a", + "A.03.04.08.a", + "A.03.04.12.a", + "A.03.13.11" ], "CFG-03": [ "A.03.04.02.ODP[01]", - "A.03.04.06.d" + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.b[01]", + "A.03.04.06.b[02]", + "A.03.04.06.b[03]", + "A.03.04.06.b[04]", + "A.03.04.06.b[05]", + "A.03.04.06.d", + "A.03.04.08.a" ], "CFG-03.1": [ - "A.03.04.06.ODP[06]" + "A.03.04.06.ODP[06]", + "A.03.04.06.c", + "A.03.04.08.c" + ], + "CFG-03.2": [ + "A.03.04.08.b" ], "CFG-03.3": [ "A.03.04.08.ODP[01]", "A.03.04.08.a", "A.03.04.08.b", + "A.03.13.13.a[01]", + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", + "A.03.13.13.b[03]" + ], + "CFG-04": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", + "A.03.13.13.b[03]" + ], + "CFG-04.1": [ + "A.03.13.13.a[02]", "A.03.13.13.b[03]" ], + "CFG-05": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], + "CFG-06": [ + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.03.a" + ], "CFG-08": [ - "A.03.01.02[01]" + "A.03.01.02[01]", + "A.03.01.02[02]" ], "MON-01": [ + "A.03.03.01.a", + "A.03.12.03[01]", "A.03.14.06.a.01[01]", "A.03.14.06.a.01[02]", "A.03.14.06.a.02" ], + "MON-01.1": [ + "A.03.13.01.a[01]" + ], "MON-01.3": [ "A.03.13.01.a[01]", "A.03.13.01.a[03]", - "A.03.14.06.c[01]", - "A.03.14.06.c[02]" + "A.03.14.06.b", + "A.03.14.06.c[01]" ], "MON-01.4": [ - "A.03.03.02.a.01", - "A.03.03.03.a" + "A.03.03.01.a", + "A.03.03.03.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" ], "MON-01.8": [ "A.03.03.01.ODP[02]", - "A.03.03.01.b[01]", "A.03.03.05.ODP[01]", "A.03.03.05.a" ], "MON-01.12": [ "A.03.03.05.b" ], + "MON-01.15": [ + "A.03.01.07.b" + ], "MON-02": [ "A.03.03.05.ODP[01]", "A.03.03.05.a", "A.03.03.05.c[01]" ], "MON-02.1": [ + "A.03.03.05.a", "A.03.03.05.c[02]" ], + "MON-02.2": [ + "A.03.03.05.a", + "A.03.03.05.c[01]" + ], + "MON-02.3": [ + "A.03.03.05.c[02]" + ], + "MON-02.6": [ + "A.03.03.01.b[01]" + ], + "MON-02.7": [ + "A.03.03.01.a" + ], "MON-03": [ "A.03.03.01.ODP[01]", "A.03.03.01.a", - "A.03.03.01.b[02]", + "A.03.03.02.a.01", "A.03.03.02.a.02", "A.03.03.02.a.03", "A.03.03.02.a.04", @@ -208,9 +453,16 @@ "A.03.03.02.a.06", "A.03.03.02.b" ], + "MON-03.2": [ + "A.03.03.01.a" + ], "MON-03.3": [ "A.03.01.07.b" ], + "MON-03.6": [ + "A.03.03.01.b[01]", + "A.03.03.01.b[02]" + ], "MON-05": [ "A.03.03.04.ODP[01]", "A.03.03.04.ODP[02]", @@ -225,6 +477,7 @@ "A.03.03.06.a[04]" ], "MON-07": [ + "A.03.03.02.a.02", "A.03.03.07.ODP[01]", "A.03.03.07.a", "A.03.03.07.b[01]" @@ -239,13 +492,34 @@ "A.03.03.08.a[01]", "A.03.03.08.b" ], + "MON-08.1": [ + "A.03.03.08.a[01]" + ], "MON-08.2": [ + "A.03.03.08.a[01]", "A.03.03.08.b" ], + "MON-08.3": [ + "A.03.03.08.a[01]" + ], "MON-10": [ "A.03.03.03.b" ], + "MON-11": [ + "A.03.01.22.b[01]" + ], + "MON-11.3": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", + "A.03.14.06.b" + ], "MON-16": [ + "A.03.01.01.e", + "A.03.03.05.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", "A.03.14.06.b" ], "CRY-01": [ @@ -254,6 +528,12 @@ "A.03.13.11.ODP[01]", "A.03.13.11" ], + "CRY-01.1": [ + "A.03.13.08[02]" + ], + "CRY-01.5": [ + "A.03.13.11" + ], "CRY-03": [ "A.03.13.08[01]", "A.03.13.11.ODP[01]", @@ -264,19 +544,86 @@ "A.03.13.11.ODP[01]", "A.03.13.11" ], + "CRY-05.1": [ + "A.03.13.08[02]" + ], + "CRY-07": [ + "A.03.01.16.a[02]" + ], + "CRY-08": [ + "A.03.13.10[01]" + ], "CRY-09": [ "A.03.13.10.ODP[01]", "A.03.13.10[01]", "A.03.13.10[02]" ], + "CRY-09.3": [ + "A.03.13.10[02]" + ], + "CRY-09.4": [ + "A.03.13.10[02]" + ], + "DCH-01": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.08.01[01]", + "A.03.08.01[02]" + ], + "DCH-01.1": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.05.a[01]" + ], + "DCH-01.2": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.d", + "A.03.06.05.d", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.08.05.a[02]", + "A.03.17.01.c" + ], + "DCH-01.3": [ + "A.03.08.05.c" + ], "DCH-01.4": [ + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", "A.03.15.02.c", "A.03.17.01.c" ], + "DCH-02": [ + "A.03.04.11.a[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.04[01]" + ], "DCH-03": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", "A.03.08.02" ], "DCH-03.1": [ + "A.03.01.22.a", "A.03.15.02.c", "A.03.17.01.c" ], @@ -289,13 +636,37 @@ "A.03.08.01[01]", "A.03.08.01[02]" ], + "DCH-06.1": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], + "DCH-06.2": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "DCH-06.4": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], "DCH-07": [ "A.03.08.05.a[01]", "A.03.08.05.a[02]", "A.03.08.05.b", "A.03.08.05.c" ], + "DCH-07.1": [ + "A.03.08.05.a[02]", + "A.03.08.05.b" + ], + "DCH-07.2": [ + "A.03.08.05.a[02]" + ], + "DCH-08": [ + "A.03.08.03" + ], "DCH-09": [ + "A.03.07.04.c", "A.03.08.03" ], "DCH-10": [ @@ -305,51 +676,108 @@ "DCH-10.2": [ "A.03.08.07.b" ], + "DCH-12": [ + "A.03.08.07.a" + ], "DCH-13": [ "A.03.01.20.ODP[01]", "A.03.01.20.a", "A.03.01.20.b", "A.03.01.20.c.01", - "A.03.01.20.c.02" + "A.03.01.20.c.02", + "A.03.01.20.d" + ], + "DCH-13.1": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.01.20.d" ], "DCH-13.2": [ + "A.03.01.20.a", "A.03.01.20.d" ], - "DCH-15": [ - "A.03.01.22.a", - "A.03.01.22.b[01]", - "A.03.01.22.b[02]" + "DCH-13.3": [ + "A.03.01.20.b", + "A.03.01.20.c.01" ], - "DCH-18": [ + "DCH-13.4": [ + "A.03.01.20.a", + "A.03.01.20.c.01", + "A.03.01.20.d" + ], + "DCH-14": [ + "A.03.01.20.b" + ], + "DCH-14.2": [ + "A.03.01.20.b", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], + "DCH-14.3": [ + "A.03.01.03[02]", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], + "DCH-15": [ + "A.03.01.22.a", + "A.03.01.22.b[01]" + ], + "DCH-17": [ + "A.03.01.20.a" + ], + "DCH-18": [ + "A.03.01.20.c.02", + "A.03.10.07.b", "A.03.14.08[01]", "A.03.14.08[02]", "A.03.14.08[03]", "A.03.14.08[04]" ], + "DCH-19": [ + "A.03.04.11.a[01]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "DCH-21": [ + "A.03.08.03" + ], "DCH-24": [ "A.03.04.11.a[01]" ], "END-01": [ - "A.03.01.03[01]" + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.14.02.a[01]" ], "END-04": [ "A.03.14.02.ODP[01]", "A.03.14.02.a[01]", "A.03.14.02.a[02]", + "A.03.14.02.c.01[01]", "A.03.14.02.c.02" ], "END-04.1": [ "A.03.14.02.b" ], + "END-04.3": [ + "A.03.14.02.a[01]" + ], "END-04.7": [ + "A.03.14.02.a[01]", "A.03.14.02.c.01[01]", "A.03.14.02.c.01[02]" ], + "END-07": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" + ], "END-10": [ "A.03.13.13.a[01]", "A.03.13.13.a[02]", "A.03.13.13.b[01]", - "A.03.13.13.b[02]", "A.03.13.13.b[03]" ], "END-14": [ @@ -363,10 +791,43 @@ "A.03.01.01.ODP[01]", "A.03.01.01.ODP[02]", "A.03.01.01.ODP[03]", - "A.03.01.01.ODP[04]" + "A.03.01.01.ODP[04]", + "A.03.01.01.g.02", + "A.03.15.03.a", + "A.03.15.03.d[01]" + ], + "HRS-02": [ + "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.09.01.a", + "A.03.09.01.b", + "A.03.15.03.b" + ], + "HRS-02.1": [ + "A.03.01.02[01]", + "A.03.01.02[02]" ], "HRS-03": [ - "A.03.06.05.d" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.05.d", + "A.03.07.06.a", + "A.03.07.06.d[02]", + "A.03.08.02", + "A.03.15.03.b", + "A.03.16.03.b" + ], + "HRS-03.1": [ + "A.03.01.22.a", + "A.03.15.03.b" + ], + "HRS-03.2": [ + "A.03.07.06.d[01]" ], "HRS-04": [ "A.03.09.01.ODP[01]", @@ -375,12 +836,28 @@ "A.03.09.02.b.01[01]" ], "HRS-04.1": [ - "A.03.09.01.ODP[01]" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.09.01.ODP[01]", + "A.03.09.01.a", + "A.03.09.01.b" + ], + "HRS-04.2": [ + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.04.a.01", + "A.03.15.03.b" ], "HRS-05": [ + "A.03.01.01.h", + "A.03.01.22.a", + "A.03.15.03.a", "A.03.15.03.b" ], "HRS-05.1": [ + "A.03.01.18.a[01]", + "A.03.01.22.a", "A.03.15.03.ODP[01]", "A.03.15.03.a", "A.03.15.03.d[01]", @@ -390,39 +867,103 @@ "A.03.15.03.a" ], "HRS-05.3": [ + "A.03.01.01.h", + "A.03.01.18.a[01]", + "A.03.15.03.a" + ], + "HRS-05.4": [ "A.03.15.03.a" ], "HRS-05.5": [ + "A.03.01.18.a[01]", "A.03.15.03.a" ], "HRS-05.7": [ + "A.03.15.03.c", + "A.03.15.03.d[02]" + ], + "HRS-06": [ + "A.03.01.18.a[01]", + "A.03.12.05.a[01]", + "A.03.15.03.c" + ], + "HRS-06.1": [ + "A.03.12.05.a[01]", "A.03.15.03.c" ], + "HRS-07": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], + "HRS-07.1": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], "HRS-08": [ + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", + "A.03.09.02.a.01", "A.03.09.02.b.01[01]", "A.03.09.02.b.01[02]", "A.03.09.02.b.02" ], "HRS-09": [ + "A.03.01.01.f.03", + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", "A.03.09.02.a.01", "A.03.09.02.a.02[01]", "A.03.09.02.a.02[02]", - "A.03.09.02.a.03" + "A.03.09.02.a.03", + "A.03.09.02.b.01[01]" ], "HRS-09.1": [ "A.03.09.02.a.03" ], + "HRS-09.2": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]", + "A.03.09.02.b.01[01]" + ], + "HRS-09.4": [ + "A.03.01.01.g.02", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], + "HRS-10": [ + "A.03.16.03.b" + ], "HRS-11": [ "A.03.01.04.a" ], + "HRS-12": [ + "A.03.01.04.a" + ], + "IAC-01": [ + "A.03.01.01.a[01]", + "A.03.01.01.a[02]", + "A.03.01.18.b", + "A.03.05.01.a[01]", + "A.03.05.05.a", + "A.03.05.12.e" + ], "IAC-01.2": [ "A.03.01.01.d.01", - "A.03.01.01.d.02", "A.03.01.16.b", "A.03.05.01.a[01]", - "A.03.05.01.a[02]" + "A.03.05.01.a[02]", + "A.03.05.02[01]", + "A.03.05.02[02]", + "A.03.05.05.d", + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.12.d", + "A.03.07.05.a[01]" ], "IAC-02": [ "A.03.05.01.a[03]", @@ -433,16 +974,37 @@ "A.03.05.04[02]", "A.03.07.05.b[02]" ], + "IAC-03": [ + "A.03.05.01.a[03]" + ], "IAC-04": [ + "A.03.01.18.b", "A.03.05.02.ODP[01]", "A.03.05.02[01]", "A.03.05.02[02]" ], + "IAC-05": [ + "A.03.05.01.a[03]", + "A.03.05.02[01]", + "A.03.05.02[02]" + ], + "IAC-05.2": [ + "A.03.07.05.a[01]" + ], "IAC-06": [ "A.03.05.03[01]", "A.03.05.03[02]", "A.03.07.05.b[01]" ], + "IAC-06.1": [ + "A.03.05.03[01]" + ], + "IAC-06.2": [ + "A.03.05.03[02]" + ], + "IAC-06.3": [ + "A.03.05.03[01]" + ], "IAC-06.4": [ "A.03.05.03[01]", "A.03.05.03[02]" @@ -453,29 +1015,70 @@ "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.05.05.a" + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], + "IAC-07.1": [ + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" + ], + "IAC-07.2": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" ], "IAC-08": [ + "A.03.01.01.c.01", "A.03.01.01.c.02", "A.03.01.01.c.03", + "A.03.01.02[01]", + "A.03.01.02[02]", "A.03.01.05.ODP[01]", "A.03.01.05.ODP[02]", "A.03.01.05.b[01]", "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.12.a[02]", + "A.03.03.08.b", "A.03.04.05[04]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.07.06.a" ], "IAC-09": [ "A.03.05.05.ODP[01]", "A.03.05.05.b[01]", "A.03.05.05.b[02]", - "A.03.05.05.c" + "A.03.05.05.c", + "A.03.05.05.d" + ], + "IAC-09.1": [ + "A.03.05.05.b[01]", + "A.03.05.05.b[02]" ], "IAC-09.2": [ "A.03.05.05.ODP[02]", "A.03.05.05.d" ], + "IAC-09.5": [ + "A.03.01.07.b", + "A.03.05.05.d" + ], "IAC-10": [ + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", "A.03.05.12.ODP[01]", "A.03.05.12.ODP[02]", "A.03.05.12.a", @@ -493,7 +1096,14 @@ ], "IAC-10.1": [ "A.03.05.07.ODP[02]", - "A.03.05.07.f" + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.b", + "A.03.05.12.d", + "A.03.05.12.e" + ], + "IAC-10.3": [ + "A.03.05.12.a" ], "IAC-10.4": [ "A.03.05.07.ODP[01]", @@ -508,12 +1118,22 @@ "A.03.05.12.f[01]", "A.03.05.12.f[02]" ], + "IAC-10.6": [ + "A.03.05.07.d" + ], + "IAC-10.8": [ + "A.03.05.07.e", + "A.03.05.12.d" + ], "IAC-10.11": [ "A.03.05.07.ODP[01]", "A.03.05.07.a[01]", "A.03.05.07.a[02]", "A.03.05.07.a[03]", - "A.03.05.07.b" + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.f" ], "IAC-11": [ "A.03.05.11" @@ -526,7 +1146,13 @@ "A.03.01.01.ODP[01]", "A.03.01.01.a[01]", "A.03.01.01.a[02]", + "A.03.01.01.b[01]", + "A.03.01.01.b[02]", + "A.03.01.01.b[03]", "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", "A.03.01.01.e", "A.03.01.01.f.01", "A.03.01.01.f.02", @@ -536,41 +1162,117 @@ "A.03.01.01.g.01", "A.03.01.01.g.02", "A.03.01.01.g.03", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.05.c", + "A.03.01.05.d", "A.03.05.07.e" ], + "IAC-15.1": [ + "A.03.01.01.d.01", + "A.03.05.05.b[01]", + "A.03.05.05.b[02]", + "A.03.05.05.c", + "A.03.05.05.d", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.d", + "A.03.05.12.e", + "A.03.05.12.f[01]", + "A.03.05.12.f[02]" + ], "IAC-15.3": [ "A.03.01.01.f.02" ], + "IAC-15.5": [ + "A.03.01.01.c.01" + ], + "IAC-15.6": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], "IAC-15.7": [ - "A.03.01.01.a[01]", - "A.03.01.01.a[02]", - "A.03.01.01.b[01]", - "A.03.01.01.b[02]", - "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.01.01.c.01" + "A.03.01.01.e", + "A.03.01.05.c" + ], + "IAC-16": [ + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.01.07.b" ], "IAC-17": [ + "A.03.01.01.g.03", "A.03.01.05.ODP[03]", "A.03.01.05.c", - "A.03.01.05.d" + "A.03.01.05.d", + "A.03.10.01.c", + "A.03.10.01.d" + ], + "IAC-20": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" ], "IAC-20.1": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", "A.03.01.05.b[01]", "A.03.01.05.b[02]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]" ], "IAC-21": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", "A.03.01.02[02]", - "A.03.01.05.a" + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.03.08.a[02]", + "A.03.03.08.b", + "A.03.04.05[04]" ], "IAC-21.2": [ "A.03.01.06.b" ], "IAC-21.3": [ "A.03.01.06.ODP[01]", - "A.03.01.06.a" + "A.03.01.06.a", + "A.03.01.07.a" + ], + "IAC-21.4": [ + "A.03.01.07.b" ], "IAC-21.5": [ "A.03.01.07.a" @@ -600,18 +1302,32 @@ "A.03.01.11", "A.03.07.05.c[01]" ], + "IAC-28": [ + "A.03.05.12.a" + ], + "IAC-28.1": [ + "A.03.01.01.b[02]", + "A.03.05.05.a" + ], "IRO-01": [ "A.03.06.01[01]" ], "IRO-02": [ + "A.03.03.04.b", "A.03.06.01[02]", "A.03.06.01[03]", "A.03.06.01[04]", "A.03.06.01[05]", "A.03.06.01[06]", - "A.03.06.02.b" + "A.03.06.02.a[01]", + "A.03.06.02.a[02]", + "A.03.06.02.b", + "A.03.06.02.c", + "A.03.06.02.d", + "A.03.06.05.b[01]" ], "IRO-04": [ + "A.03.06.01[01]", "A.03.06.02.ODP[01]", "A.03.06.02.ODP[02]", "A.03.06.05.a.01", @@ -627,16 +1343,12 @@ "IRO-04.2": [ "A.03.06.05.c" ], + "IRO-04.3": [ + "A.03.06.04.b[03]" + ], "IRO-05": [ - "A.03.06.04.ODP[01]", - "A.03.06.04.ODP[02]", - "A.03.06.04.ODP[03]", - "A.03.06.04.ODP[04]", "A.03.06.04.a.01", - "A.03.06.04.b[01]", - "A.03.06.04.b[02]", - "A.03.06.04.b[03]", - "A.03.06.04.b[04]" + "A.03.06.04.a.03" ], "IRO-06": [ "A.03.06.03.ODP[01]", @@ -648,7 +1360,8 @@ ], "IRO-09": [ "A.03.06.02.a[01]", - "A.03.06.02.a[02]" + "A.03.06.02.a[02]", + "A.03.06.02.b" ], "IRO-10": [ "A.03.06.02.ODP[01]", @@ -657,24 +1370,37 @@ "A.03.06.02.d" ], "IRO-10.2": [ - "A.03.06.02.ODP[02]" + "A.03.06.02.ODP[02]", + "A.03.06.02.b" ], "IRO-11": [ "A.03.06.02.d" ], "IRO-12": [ - "A.03.01.22.b[02]" + "A.03.01.22.b[02]", + "A.03.06.01[01]" ], "IRO-13": [ - "A.03.06.04.ODP[04]" + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" ], "IRO-14": [ "A.03.06.02.ODP[02]" ], - "IAO-03": [ - "A.03.04.11.a[02]", - "A.03.04.11.a[03]", - "A.03.04.11.b[01]", + "IAO-01": [ + "A.03.12.01" + ], + "IAO-01.1": [ + "A.03.12.01" + ], + "IAO-02": [ + "A.03.12.01" + ], + "IAO-03": [ + "A.03.01.16.a[01]", + "A.03.04.11.a[02]", + "A.03.04.11.a[03]", + "A.03.04.11.b[01]", "A.03.04.11.b[02]", "A.03.15.02.ODP[01]", "A.03.15.02.a.01", @@ -686,24 +1412,43 @@ "A.03.15.02.a.07", "A.03.15.02.a.08", "A.03.15.02.b[01]", - "A.03.15.02.b[02]", - "A.03.15.02.c" + "A.03.15.02.b[02]" ], "IAO-05": [ + "A.03.04.11.b[01]", + "A.03.04.11.b[02]", "A.03.12.02.a.01", "A.03.12.02.a.02", "A.03.12.02.b.01", "A.03.12.02.b.02", - "A.03.12.02.b.03" + "A.03.12.02.b.03", + "A.03.14.01.a[01]" + ], + "MNT-01": [ + "A.03.04.03.c[01]", + "A.03.07.04.a[01]", + "A.03.07.04.a[02]", + "A.03.07.06.a" ], "MNT-02": [ - "A.03.04.03.c[01]" + "A.03.04.03.c[01]", + "A.03.07.04.a[02]", + "A.03.07.05.a[01]" + ], + "MNT-03": [ + "A.03.07.04.a[02]" + ], + "MNT-03.1": [ + "A.03.07.04.a[02]" ], "MNT-04": [ "A.03.07.04.a[01]", "A.03.07.04.a[02]", "A.03.07.04.a[03]" ], + "MNT-04.1": [ + "A.03.07.04.b" + ], "MNT-04.2": [ "A.03.07.04.b" ], @@ -711,37 +1456,75 @@ "A.03.07.04.c" ], "MNT-05": [ + "A.03.01.12.d[1]", "A.03.07.05.a[01]", + "A.03.07.05.a[02]", + "A.03.07.05.b[01]", + "A.03.07.05.c[01]" + ], + "MNT-05.1": [ "A.03.07.05.a[02]" ], "MNT-05.3": [ - "A.03.07.05.b[02]" + "A.03.07.05.b[01]" ], "MNT-05.4": [ "A.03.07.05.c[01]" ], + "MNT-05.5": [ + "A.03.07.05.a[01]" + ], "MNT-06": [ "A.03.07.06.a", "A.03.07.06.b", "A.03.07.06.c", - "A.03.07.06.d[01]", - "A.03.07.06.d[02]" + "A.03.07.06.d[01]" ], "MNT-06.1": [ - "A.03.07.06.c" + "A.03.07.06.c", + "A.03.07.06.d[01]", + "A.03.07.06.d[02]" ], "MNT-06.2": [ "A.03.07.06.c" ], + "MNT-09": [ + "A.03.07.04.a[02]" + ], "MDM-01": [ - "A.03.01.18.a[01]" + "A.03.01.18.a[01]", + "A.03.01.20.d" ], "MDM-02": [ + "A.03.01.18.a[02]", "A.03.01.18.b" ], "MDM-03": [ "A.03.01.18.c" ], + "MDM-04": [ + "A.03.04.12.b" + ], + "MDM-06": [ + "A.03.01.18.a[01]", + "A.03.01.18.b" + ], + "MDM-07": [ + "A.03.01.18.a[01]", + "A.03.01.18.b", + "A.03.01.20.d" + ], + "MDM-11": [ + "A.03.01.18.b" + ], + "NET-01": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[03]", + "A.03.13.01.a[02]" + ], + "NET-02": [ + "A.03.13.01.b" + ], "NET-02.2": [ "A.03.01.16.a[01]", "A.03.01.16.a[02]", @@ -752,17 +1535,25 @@ "A.03.01.18.a[03]", "A.03.13.01.a[02]", "A.03.13.01.a[04]", + "A.03.13.01.b", "A.03.13.01.c" ], + "NET-03.8": [ + "A.03.13.01.b" + ], "NET-04": [ - "A.03.01.03[02]" + "A.03.01.03[02]", + "A.03.13.01.a[02]", + "A.03.13.01.c" ], "NET-04.1": [ + "A.03.13.01.a[02]", "A.03.13.06[01]", "A.03.13.06[02]" ], "NET-05": [ "A.03.01.03[02]", + "A.03.01.20.c.02", "A.03.12.05.ODP[01]", "A.03.12.05.ODP[02]", "A.03.12.05.a[01]", @@ -773,33 +1564,54 @@ "A.03.12.05.c[01]", "A.03.12.05.c[02]" ], + "NET-05.2": [ + "A.03.01.03[02]" + ], "NET-06": [ "A.03.13.01.b" ], + "NET-06.3": [ + "A.03.13.01.b" + ], "NET-07": [ "A.03.07.05.c[02]", "A.03.13.09.ODP[01]", "A.03.13.09" ], + "NET-08": [ + "A.03.13.01.a[02]", + "A.03.14.06.c[01]" + ], + "NET-08.1": [ + "A.03.13.01.b" + ], "NET-09": [ "A.03.13.15" ], "NET-14": [ "A.03.01.12.a[01]", "A.03.01.12.a[02]", - "A.03.01.12.a[03]", "A.03.01.12.a[04]", "A.03.01.12.b", "A.03.01.12.c[01]", - "A.03.01.12.c[02]", - "A.03.01.12.d[1]", - "A.03.01.12.d[2]" + "A.03.01.12.c[02]" + ], + "NET-14.1": [ + "A.03.01.12.b" + ], + "NET-14.2": [ + "A.03.01.12.a[04]" + ], + "NET-14.3": [ + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" ], "NET-14.4": [ "A.03.01.12.d[1]", "A.03.01.12.d[2]" ], "NET-14.5": [ + "A.03.01.12.a[01]", "A.03.10.06.ODP[01]", "A.03.10.06.a", "A.03.10.06.b" @@ -807,35 +1619,94 @@ "NET-15": [ "A.03.01.16.a[01]", "A.03.01.16.a[02]", - "A.03.01.16.a[04]" + "A.03.01.16.a[04]", + "A.03.01.16.b" ], "NET-15.1": [ + "A.03.01.16.a[04]", + "A.03.01.16.b", "A.03.01.16.d[01]", "A.03.01.16.d[02]" ], + "NET-15.2": [ + "A.03.01.16.c" + ], + "NET-15.3": [ + "A.03.01.16.a[03]", + "A.03.01.16.c" + ], + "NET-18": [ + "A.03.14.06.c[02]" + ], + "PES-01": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", + "A.03.10.07.a.01" + ], "PES-02": [ "A.03.04.05[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", "A.03.10.01.a[01]", "A.03.10.01.a[02]", "A.03.10.01.a[03]", + "A.03.10.01.b", "A.03.10.01.c", "A.03.10.01.d", "A.03.10.07.a.01" ], "PES-02.1": [ "A.03.04.05[01]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", - "A.03.10.01.b" + "A.03.10.01.b", + "A.03.10.01.d" ], "PES-03": [ "A.03.04.05[03]", + "A.03.10.02.a[01]", + "A.03.10.07.a.01", "A.03.10.07.a.02", "A.03.10.07.d" ], + "PES-03.1": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], "PES-03.3": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.02", "A.03.10.07.b" ], + "PES-03.4": [ + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], + "PES-04": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" + ], + "PES-04.1": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" + ], "PES-05": [ "A.03.10.02.ODP[01]", "A.03.10.02.ODP[02]", @@ -844,11 +1715,25 @@ "A.03.10.02.b[01]", "A.03.10.02.b[02]" ], + "PES-05.1": [ + "A.03.10.02.a[01]" + ], + "PES-05.2": [ + "A.03.10.02.a[01]", + "A.03.10.02.b[01]", + "A.03.10.02.b[02]" + ], "PES-06": [ + "A.03.10.01.a[02]", "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], "PES-06.1": [ + "A.03.10.01.a[02]", + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], + "PES-06.2": [ "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], @@ -856,23 +1741,49 @@ "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], + "PES-06.6": [ + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], + "PES-07": [ + "A.03.10.08" + ], "PES-11": [ "A.03.10.06.ODP[01]", "A.03.10.06.a", "A.03.10.06.b" ], + "PES-12": [ + "A.03.10.07.e", + "A.03.10.08" + ], "PES-12.1": [ "A.03.10.08" ], "PES-12.2": [ "A.03.10.07.e" ], + "PRM-01": [ + "A.03.16.01" + ], + "PRM-05": [ + "A.03.16.01" + ], "RSK-01": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", "A.03.17.03.b" ], "RSK-01.1": [ "A.03.11.01.a" ], + "RSK-02": [ + "A.03.11.01.a" + ], + "RSK-02.1": [ + "A.03.11.01.a", + "A.03.14.03.a" + ], "RSK-03": [ "A.03.11.01.a" ], @@ -880,14 +1791,28 @@ "A.03.11.01.a" ], "RSK-04": [ - "A.03.11.01.a", - "A.03.11.01.b" + "A.03.11.01.a" + ], + "RSK-04.1": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" + ], + "RSK-05": [ + "A.03.11.01.a" + ], + "RSK-06": [ + "A.03.11.02.b", + "A.03.12.02.a.02" ], "RSK-06.1": [ + "A.03.11.02.b", "A.03.11.04[01]", "A.03.11.04[02]", "A.03.11.04[03]" ], + "RSK-06.2": [ + "A.03.11.02.b" + ], "RSK-07": [ "A.03.11.01.ODP[01]", "A.03.11.01.b" @@ -907,19 +1832,42 @@ "A.03.17.01.a[10]", "A.03.17.01.b[01]", "A.03.17.01.b[02]", - "A.03.17.01.c", "A.03.17.03.ODP[01]", "A.03.17.03.a[01]", "A.03.17.03.a[02]", "A.03.17.03.b" ], + "RSK-09.1": [ + "A.03.11.01.a", + "A.03.11.01.b", + "A.03.17.03.a[01]" + ], "SEA-01": [ - "A.03.16.01.ODP[01]" + "A.03.01.12.a[04]", + "A.03.01.16.a[02]", + "A.03.01.16.c", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01.ODP[01]", + "A.03.16.01" + ], + "SEA-02": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01" ], "SEA-05": [ "A.03.13.04[01]", "A.03.13.04[02]" ], + "SEA-07": [ + "A.03.16.02.b" + ], + "SEA-07.1": [ + "A.03.16.02.a", + "A.03.16.02.b" + ], "SEA-18": [ "A.03.01.09" ], @@ -929,27 +1877,52 @@ "SEA-18.2": [ "A.03.01.09" ], + "OPS-01": [ + "A.03.15.01.a[03]" + ], "OPS-01.1": [ "A.03.15.01.a[03]", - "A.03.15.01.a[04]", - "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.a[04]" + ], + "OPS-03": [ + "A.03.15.01.a[04]" ], "SAT-01": [ "A.03.02.01.ODP[01]", "A.03.02.01.ODP[02]", - "A.03.02.01.a.01[01]", - "A.03.02.01.a.01[02]" + "A.03.02.01.a.01[01]" + ], + "SAT-01.1": [ + "A.03.02.01.b[01]", + "A.03.02.01.b[02]", + "A.03.02.02.b[01]", + "A.03.02.02.b[02]", + "A.03.06.04.ODP[03]", + "A.03.06.04.ODP[04]", + "A.03.06.04.b[01]", + "A.03.06.04.b[02]", + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" ], "SAT-02": [ + "A.03.01.22.a", "A.03.02.01.ODP[03]", "A.03.02.01.ODP[04]", + "A.03.02.01.a.01[01]", "A.03.02.01.a.03[03]", "A.03.02.01.a.03[04]", + "A.03.06.04.a.03" + ], + "SAT-02.2": [ + "A.03.02.01.a.03[03]", "A.03.02.01.a.03[05]", "A.03.02.01.a.03[06]" ], "SAT-03": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.01.a.01[02]", + "A.03.02.01.a.02", "A.03.02.02.ODP[01]", "A.03.02.02.ODP[02]", "A.03.02.02.ODP[03]", @@ -958,27 +1931,70 @@ "A.03.02.02.a.01[02]", "A.03.02.02.a.01[03]", "A.03.02.02.a.02", - "A.03.02.02.b[01]", - "A.03.02.02.b[02]", + "A.03.06.04.ODP[01]", + "A.03.06.04.ODP[02]", "A.03.06.04.a.01", "A.03.06.04.a.02", "A.03.06.04.a.03" ], + "SAT-03.3": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], + "SAT-03.5": [ + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], "SAT-03.6": [ + "A.03.02.01.a.01[01]", "A.03.02.01.a.02", - "A.03.02.01.b[01]", - "A.03.02.01.b[02]" + "A.03.02.01.b[02]", + "A.03.02.02.a.01[01]", + "A.03.02.02.a.02", + "A.03.06.04.a.02" ], "TDA-01": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", "A.03.16.01.ODP[01]", + "A.03.16.01", "A.03.17.02[04]", "A.03.17.02[05]", "A.03.17.02[06]" ], + "TDA-01.1": [ + "A.03.12.03[01]" + ], + "TDA-02": [ + "A.03.16.01" + ], "TDA-02.3": [ "A.03.16.01.ODP[01]", "A.03.16.01" ], + "TDA-02.4": [ + "A.03.16.01" + ], + "TDA-03": [ + "A.03.16.01" + ], + "TDA-05": [ + "A.03.16.01" + ], + "TDA-06": [ + "A.03.16.01" + ], + "TDA-09": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], + "TDA-09.1": [ + "A.03.12.03[01]" + ], "TDA-17": [ "A.03.16.02.a" ], @@ -986,42 +2002,146 @@ "A.03.16.02.b" ], "TPM-01": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.07.06.a", + "A.03.16.01", + "A.03.16.03.a", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.02[06]", "A.03.17.03.ODP[01]" ], - "TPM-03.1": [ - "A.03.17.02[01]", - "A.03.17.02[02]", - "A.03.17.02[03]" + "TPM-01.1": [ + "A.03.07.06.b" ], - "TPM-04.1": [ + "TPM-02": [ + "A.03.11.01.a", "A.03.17.03.a[01]" ], - "TPM-05": [ - "A.03.16.03.ODP[01]", - "A.03.16.03.a" + "TPM-03": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], - "TPM-05.2": [ - "A.03.16.03.ODP[01]" + "TPM-03.1": [ + "A.03.17.01.a[01]", + "A.03.17.02[01]", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], - "TPM-05.4": [ - "A.03.16.03.b" + "TPM-03.2": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" ], - "TPM-05.5": [ - "A.03.16.03.c" + "TPM-03.3": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" ], - "TPM-05.6": [ - "A.03.16.03.c" + "TPM-04": [ + "A.03.16.03.a", + "A.03.16.03.c", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], - "TPM-05.8": [ - "A.03.16.03.c" + "TPM-04.1": [ + "A.03.11.01.a", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], - "TPM-08": [ + "TPM-04.4": [ + "A.03.16.03.a" + ], + "TPM-05": [ + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.07.06.a", + "A.03.16.03.ODP[01]", + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" + ], + "TPM-05.1": [ + "A.03.17.02[05]" + ], + "TPM-05.2": [ + "A.03.16.03.ODP[01]", + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" + ], + "TPM-05.4": [ + "A.03.07.06.b", + "A.03.16.03.b" + ], + "TPM-05.5": [ + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[02]", + "A.03.17.03.b" + ], + "TPM-05.6": [ + "A.03.01.20.c.01", + "A.03.16.03.c" + ], + "TPM-05.7": [ + "A.03.17.01.a[01]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.b" + ], + "TPM-05.8": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.16.03.a", "A.03.16.03.c" ], + "TPM-08": [ + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]" + ], + "TPM-09": [ + "A.03.17.02[06]" + ], + "TPM-10": [ + "A.03.16.01", + "A.03.17.02[06]" + ], + "THR-01": [ + "A.03.11.02.a[01]", + "A.03.14.01.a[01]", + "A.03.14.03.a" + ], "THR-03": [ + "A.03.02.01.a.02", + "A.03.02.01.b[02]", + "A.03.11.02.a[01]", "A.03.14.03.a" ], "THR-03.1": [ + "A.03.14.03.a", "A.03.14.03.b[01]", "A.03.14.03.b[02]" ], @@ -1029,24 +2149,39 @@ "A.03.02.01.a.03[01]", "A.03.02.01.a.03[02]" ], + "THR-06": [ + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], + "THR-10": [ + "A.03.14.03.a" + ], "VPM-01": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" ], "VPM-01.1": [ - "A.03.11.02.a[01]" + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" ], "VPM-02": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.b", + "A.03.12.02.a.02" + ], + "VPM-03": [ + "A.03.11.02.a[01]" ], "VPM-04": [ - "A.03.11.02.b" + "A.03.11.02.b", + "A.03.14.01.a[03]" ], "VPM-05": [ "A.03.11.02.b", + "A.03.12.02.a.02", "A.03.14.01.ODP[01]", "A.03.14.01.ODP[02]", - "A.03.14.01.a[01]", - "A.03.14.01.a[02]", "A.03.14.01.a[03]", "A.03.14.01.b[01]", "A.03.14.01.b[02]" @@ -1059,62 +2194,190 @@ "A.03.11.02.a[02]", "A.03.11.02.a[03]", "A.03.11.02.a[04]", - "A.03.11.02.c[01]", - "A.03.11.02.c[02]" + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" ], "VPM-06.1": [ "A.03.11.02.ODP[04]", "A.03.11.02.c[01]", "A.03.11.02.c[02]" + ], + "WEB-01": [ + "A.03.01.22.a" + ], + "WEB-14": [ + "A.03.01.22.b[02]" ] } }, "framework_to_scf": { - "total_mappings": 508, + "total_mappings": 509, "mappings": { "A.03.15.01.a[01]": [ + "GOV-01", "GOV-02" ], + "A.03.12.03[01]": [ + "GOV-01.1", + "GOV-01.2", + "GOV-05", + "CPL-02", + "CPL-03", + "MON-01", + "TDA-01", + "TDA-01.1", + "TDA-09", + "TDA-09.1" + ], "A.03.15.01.a[02]": [ "GOV-02" ], "A.03.15.01.a[03]": [ "GOV-02", + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "OPS-01", "OPS-01.1" ], "A.03.15.01.a[04]": [ "GOV-02", - "OPS-01.1" + "OPS-01.1", + "OPS-03" ], "A.03.15.01.ODP[01]": [ "GOV-03" ], "A.03.15.01.b[01]": [ - "GOV-03", - "OPS-01.1" + "GOV-03" ], "A.03.15.01.b[02]": [ + "GOV-03" + ], + "A.03.15.03.d[01]": [ "GOV-03", - "OPS-01.1" + "HRS-01", + "HRS-05.1" ], "A.03.16.01": [ "GOV-15", - "TDA-02.3" + "AST-17", + "PRM-01", + "PRM-05", + "SEA-01", + "SEA-02", + "TDA-01", + "TDA-02", + "TDA-02.3", + "TDA-02.4", + "TDA-03", + "TDA-05", + "TDA-06", + "TPM-01", + "TPM-10" + ], + "A.03.17.01.a[01]": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3", + "GOV-15.4", + "GOV-15.5", + "RSK-01", + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-05.7" + ], + "A.03.01.03[01]": [ + "AST-01", + "CFG-02", + "DCH-01.4", + "DCH-03", + "END-01", + "IAC-20", + "IAC-20.1" + ], + "A.03.01.03[02]": [ + "AST-01", + "AST-01.1", + "AST-04", + "AST-04.3", + "AST-31", + "CFG-02", + "DCH-01.4", + "DCH-03", + "DCH-14.3", + "END-01", + "IAC-20", + "IAC-20.1", + "NET-04", + "NET-05", + "NET-05.2" + ], + "A.03.01.18.a[01]": [ + "AST-01", + "AST-12", + "AST-13", + "AST-14", + "AST-16", + "HRS-05.1", + "HRS-05.3", + "HRS-05.5", + "HRS-06", + "MDM-01", + "MDM-06", + "MDM-07", + "SEA-01", + "SEA-02" + ], + "A.03.04.11.a[02]": [ + "AST-01", + "AST-02", + "AST-02.8", + "AST-04", + "AST-04.1", + "AST-04.2", + "DCH-02", + "DCH-06.2", + "IAO-03" + ], + "A.03.07.04.a[01]": [ + "AST-01", + "MNT-01", + "MNT-04" ], "A.03.04.08.c": [ - "AST-01.4" + "AST-01.4", + "AST-02", + "CPL-03.2", + "CFG-03.1" + ], + "A.03.04.08.a": [ + "AST-02", + "AST-02.9", + "CFG-02.9", + "CFG-03", + "CFG-03.3" ], "A.03.04.10.ODP[01]": [ "AST-02" ], "A.03.04.10.a": [ - "AST-02" + "AST-02", + "AST-02.1", + "AST-02.9" ], "A.03.04.10.b[01]": [ "AST-02" ], "A.03.04.10.b[02]": [ - "AST-02" + "AST-02", + "AST-02.1", + "AST-02.9" ], "A.03.04.10.c[01]": [ "AST-02.1" @@ -1125,45 +2388,146 @@ "A.03.04.10.c[03]": [ "AST-02.1" ], + "A.03.04.02.a[02]": [ + "AST-02.4", + "CFG-02" + ], + "A.03.04.06.a": [ + "AST-02.4", + "CFG-02", + "CFG-02.5", + "CFG-02.9", + "CFG-03" + ], "A.03.04.11.a[01]": [ "AST-02.8", + "CPL-01", + "CPL-01.2", + "DCH-19", "DCH-24" ], - "A.03.04.11.a[02]": [ - "AST-02.8", - "IAO-03" - ], "A.03.04.11.a[03]": [ "AST-02.8", "IAO-03" ], "A.03.04.11.b[01]": [ "AST-02.8", + "AST-04", + "AST-04.1", + "AST-04.2", + "CHG-02.2", + "CHG-03", "CHG-05", - "IAO-03" + "DCH-06.2", + "DCH-19", + "IAO-03", + "IAO-05" ], "A.03.04.11.b[02]": [ "AST-02.8", + "AST-04", + "AST-04.1", + "AST-04.2", + "CHG-02.2", + "CHG-03", "CHG-05", - "IAO-03" + "DCH-06.2", + "DCH-19", + "IAO-03", + "IAO-05" ], "A.03.09.02.a.03": [ + "AST-03", + "AST-03.1", "AST-10", "HRS-09", "HRS-09.1" ], + "A.03.07.04.a[02]": [ + "AST-05", + "MNT-01", + "MNT-02", + "MNT-03", + "MNT-03.1", + "MNT-04", + "MNT-09" + ], + "A.03.07.04.c": [ + "AST-09", + "DCH-09", + "MNT-04.3" + ], + "A.03.08.03": [ + "AST-09", + "DCH-08", + "DCH-09", + "DCH-21" + ], + "A.03.11.01.a": [ + "AST-17", + "RSK-01", + "RSK-01.1", + "RSK-02", + "RSK-02.1", + "RSK-03", + "RSK-03.1", + "RSK-04", + "RSK-05", + "RSK-09", + "RSK-09.1", + "TPM-02", + "TPM-03", + "TPM-04.1" + ], "A.03.04.12.a": [ - "AST-24" + "AST-24", + "CFG-02.5", + "CFG-02.9" ], "A.03.04.12.b": [ - "AST-25" + "AST-24", + "AST-25", + "MDM-04" + ], + "A.03.01.12.a[01]": [ + "AST-27", + "NET-14", + "NET-14.5" + ], + "A.03.01.12.c[01]": [ + "AST-27", + "NET-14", + "NET-14.3" + ], + "A.03.01.12.c[02]": [ + "AST-27", + "NET-14", + "NET-14.3" ], "A.03.08.09.a": [ + "BCD-11", "BCD-11.4" ], "A.03.08.09.b": [ "BCD-11.4" ], + "A.03.04.02.b[01]": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CHG-04", + "CPL-03.2", + "CFG-02.2", + "CFG-02.9", + "CFG-06" + ], + "A.03.04.03.a": [ + "CHG-01", + "CHG-02", + "CHG-02.1", + "CFG-01", + "CFG-06" + ], "A.03.04.03.d[01]": [ "CHG-01", "CFG-02.2" @@ -1172,16 +2536,24 @@ "CHG-01", "CFG-02.2" ], - "A.03.04.03.a": [ + "A.03.04.03.b[02]": [ "CHG-02", - "CFG-01" + "CHG-02.1", + "CHG-02.2" ], "A.03.04.03.c[01]": [ "CHG-02", + "MNT-01", "MNT-02" ], - "A.03.04.03.b[02]": [ - "CHG-02.1" + "A.03.07.05.a[01]": [ + "CHG-02", + "CHG-02.1", + "IAC-01.2", + "IAC-05.2", + "MNT-02", + "MNT-05", + "MNT-05.5" ], "A.03.04.05[05]": [ "CHG-02.1" @@ -1189,20 +2561,44 @@ "A.03.04.03.c[02]": [ "CHG-02.2" ], - "A.03.04.03.b[01]": [ + "A.03.04.04.a": [ + "CHG-02.2", + "CHG-02.3", "CHG-03" ], - "A.03.04.04.a": [ + "A.03.04.03.b[01]": [ "CHG-03" ], "A.03.04.05[06]": [ + "CHG-04", "CHG-04.4" ], "A.03.04.04.b": [ "CHG-06" ], - "A.03.12.03[01]": [ - "CPL-02" + "A.03.12.01": [ + "CPL-01", + "CPL-02", + "CPL-02.1", + "CPL-03", + "IAO-01", + "IAO-01.1", + "IAO-02", + "TDA-01", + "TDA-09" + ], + "A.03.12.02.a.01": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1" + ], + "A.03.12.02.a.02": [ + "CPL-01.1", + "IAO-05", + "RSK-04.1", + "RSK-06", + "VPM-02", + "VPM-05" ], "A.03.12.03[03]": [ "CPL-02" @@ -1213,48 +2609,91 @@ "A.03.12.01.ODP[01]": [ "CPL-02.1" ], - "A.03.12.01": [ - "CPL-03" - ], "A.03.12.03[02]": [ "CPL-03.2" ], - "A.03.01.03[01]": [ - "CFG-02", - "END-01" - ], - "A.03.01.16.a[03]": [ + "A.03.04.01.a[02]": [ + "CFG-01", "CFG-02" ], - "A.03.01.16.c": [ - "CFG-02" + "A.03.01.01.h": [ + "CFG-02", + "HRS-05", + "HRS-05.3", + "IAC-25" ], - "A.03.01.18.a[02]": [ - "CFG-02" + "A.03.01.08.a": [ + "CFG-02", + "IAC-22" ], - "A.03.03.08.a[02]": [ - "CFG-02" + "A.03.01.08.b": [ + "CFG-02", + "IAC-22" ], - "A.03.04.01.a[01]": [ - "CFG-02" + "A.03.01.09": [ + "CFG-02", + "SEA-18", + "SEA-18.1", + "SEA-18.2" ], - "A.03.04.01.a[02]": [ - "CFG-02" + "A.03.01.10.a": [ + "CFG-02", + "IAC-24" ], - "A.03.04.02.a[01]": [ - "CFG-02" + "A.03.01.10.b": [ + "CFG-02", + "IAC-24" ], - "A.03.04.02.a[02]": [ - "CFG-02" + "A.03.01.10.c": [ + "CFG-02", + "IAC-24.1" ], - "A.03.04.06.ODP[01]": [ - "CFG-02" + "A.03.01.11": [ + "CFG-02", + "IAC-25" ], - "A.03.04.06.ODP[02]": [ + "A.03.01.12.a[03]": [ "CFG-02" ], - "A.03.04.06.ODP[03]": [ - "CFG-02" + "A.03.01.16.a[03]": [ + "CFG-02", + "NET-15.3" + ], + "A.03.01.16.c": [ + "CFG-02", + "NET-15.2", + "NET-15.3", + "SEA-01" + ], + "A.03.01.18.a[02]": [ + "CFG-02", + "MDM-02" + ], + "A.03.03.08.a[02]": [ + "CFG-02", + "IAC-21" + ], + "A.03.04.01.a[01]": [ + "CFG-02", + "CFG-02.5", + "CFG-02.7", + "CFG-02.9" + ], + "A.03.04.02.a[01]": [ + "CFG-02", + "CFG-02.5", + "CFG-02.9", + "CFG-03", + "CFG-06" + ], + "A.03.04.06.ODP[01]": [ + "CFG-02" + ], + "A.03.04.06.ODP[02]": [ + "CFG-02" + ], + "A.03.04.06.ODP[03]": [ + "CFG-02" ], "A.03.04.06.ODP[04]": [ "CFG-02" @@ -1263,19 +2702,29 @@ "CFG-02" ], "A.03.04.06.b[01]": [ - "CFG-02" + "CFG-02", + "CFG-03" ], "A.03.04.06.b[02]": [ - "CFG-02" + "CFG-02", + "CFG-03" ], "A.03.04.06.b[03]": [ - "CFG-02" + "CFG-02", + "CFG-03" ], "A.03.04.06.b[04]": [ - "CFG-02" + "CFG-02", + "CFG-03" ], "A.03.04.06.b[05]": [ - "CFG-02" + "CFG-02", + "CFG-03" + ], + "A.03.04.06.d": [ + "CFG-02", + "CFG-02.5", + "CFG-03" ], "A.03.05.04[01]": [ "CFG-02", @@ -1287,25 +2736,60 @@ ], "A.03.05.07.c": [ "CFG-02", - "IAC-10.5" + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.11", + "IAC-15.1" ], "A.03.05.07.d": [ "CFG-02", - "IAC-10.5" + "IAC-01.2", + "IAC-10", + "IAC-10.5", + "IAC-10.6", + "IAC-10.11", + "IAC-15.1" ], "A.03.05.07.e": [ "CFG-02", - "IAC-15" + "IAC-01.2", + "IAC-10", + "IAC-10.1", + "IAC-10.8", + "IAC-15", + "IAC-15.1" ], "A.03.05.07.f": [ "CFG-02", - "IAC-10.1" + "IAC-10", + "IAC-10.1", + "IAC-10.11", + "IAC-15.1" ], - "A.03.07.05.b[02]": [ + "A.03.05.12.d": [ + "CFG-02", + "IAC-01.2", + "IAC-10", + "IAC-10.1", + "IAC-10.8", + "IAC-15.1" + ], + "A.03.07.05.b[01]": [ "CFG-02", - "IAC-02.2", + "IAC-06", + "MNT-05", "MNT-05.3" ], + "A.03.08.07.a": [ + "CFG-02", + "DCH-10", + "DCH-12" + ], + "A.03.13.12.b": [ + "CFG-02", + "END-14.6" + ], "A.03.04.01.ODP[01]": [ "CFG-02.1" ], @@ -1322,7 +2806,11 @@ "CFG-02.1" ], "A.03.04.06.c": [ - "CFG-02.1" + "CFG-02.1", + "CFG-03.1" + ], + "A.03.13.13.b[02]": [ + "CFG-02.2" ], "A.03.04.12.ODP[01]": [ "CFG-02.5" @@ -1330,9 +2818,6 @@ "A.03.04.12.ODP[02]": [ "CFG-02.5" ], - "A.03.04.02.b[01]": [ - "CFG-02.7" - ], "A.03.04.02.b[02]": [ "CFG-02.7" ], @@ -1340,54 +2825,116 @@ "CFG-02.9", "MON-03" ], - "A.03.04.02.ODP[01]": [ - "CFG-03" + "A.03.13.11": [ + "CFG-02.9", + "CRY-01", + "CRY-01.5", + "CRY-03", + "CRY-05" ], - "A.03.04.06.d": [ + "A.03.04.02.ODP[01]": [ "CFG-03" ], "A.03.04.06.ODP[06]": [ "CFG-03.1" ], - "A.03.04.08.ODP[01]": [ + "A.03.04.08.b": [ + "CFG-03.2", "CFG-03.3" ], - "A.03.04.08.a": [ + "A.03.04.08.ODP[01]": [ "CFG-03.3" ], - "A.03.04.08.b": [ - "CFG-03.3" + "A.03.13.13.a[01]": [ + "CFG-03.3", + "END-10" + ], + "A.03.13.13.a[02]": [ + "CFG-03.3", + "CFG-04", + "CFG-04.1", + "CFG-05", + "END-10" + ], + "A.03.13.13.b[01]": [ + "CFG-03.3", + "CFG-04", + "END-10" ], "A.03.13.13.b[03]": [ "CFG-03.3", + "CFG-04", + "CFG-04.1", + "CFG-05", "END-10" ], "A.03.01.02[01]": [ - "CFG-08" + "CFG-08", + "DCH-01.2", + "DCH-01.4", + "HRS-02", + "HRS-02.1", + "IAC-08", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" + ], + "A.03.01.02[02]": [ + "CFG-08", + "DCH-01.2", + "DCH-01.4", + "HRS-02", + "HRS-02.1", + "IAC-08", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" + ], + "A.03.03.01.a": [ + "MON-01", + "MON-01.4", + "MON-02.7", + "MON-03", + "MON-03.2" ], "A.03.14.06.a.01[01]": [ - "MON-01" + "MON-01", + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07" ], "A.03.14.06.a.01[02]": [ - "MON-01" + "MON-01", + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07" ], "A.03.14.06.a.02": [ - "MON-01" + "MON-01", + "MON-11.3", + "MON-16" ], "A.03.13.01.a[01]": [ + "MON-01.1", "MON-01.3" ], "A.03.13.01.a[03]": [ "MON-01.3" ], - "A.03.14.06.c[01]": [ - "MON-01.3" - ], - "A.03.14.06.c[02]": [ - "MON-01.3" + "A.03.14.06.b": [ + "MON-01.3", + "MON-01.4", + "MON-11.3", + "MON-16", + "END-07" ], - "A.03.03.02.a.01": [ - "MON-01.4" + "A.03.14.06.c[01]": [ + "MON-01.3", + "NET-08" ], "A.03.03.03.a": [ "MON-01.4" @@ -1395,38 +2942,49 @@ "A.03.03.01.ODP[02]": [ "MON-01.8" ], - "A.03.03.01.b[01]": [ - "MON-01.8" - ], "A.03.03.05.ODP[01]": [ "MON-01.8", "MON-02" ], "A.03.03.05.a": [ "MON-01.8", - "MON-02" + "MON-02", + "MON-02.1", + "MON-02.2", + "MON-16" ], "A.03.03.05.b": [ "MON-01.12", "MON-06" ], + "A.03.01.07.b": [ + "MON-01.15", + "MON-03.3", + "IAC-09.5", + "IAC-16", + "IAC-21.4" + ], "A.03.03.05.c[01]": [ - "MON-02" + "MON-02", + "MON-02.2" ], "A.03.03.05.c[02]": [ - "MON-02.1" + "MON-02.1", + "MON-02.3" ], - "A.03.03.01.ODP[01]": [ - "MON-03" + "A.03.03.01.b[01]": [ + "MON-02.6", + "MON-03.6" ], - "A.03.03.01.a": [ + "A.03.03.01.ODP[01]": [ "MON-03" ], - "A.03.03.01.b[02]": [ + "A.03.03.02.a.01": [ "MON-03" ], "A.03.03.02.a.02": [ - "MON-03" + "MON-03", + "MON-07" ], "A.03.03.02.a.03": [ "MON-03" @@ -1440,8 +2998,8 @@ "A.03.03.02.a.06": [ "MON-03" ], - "A.03.01.07.b": [ - "MON-03.3" + "A.03.03.01.b[02]": [ + "MON-03.6" ], "A.03.03.04.ODP[01]": [ "MON-05" @@ -1453,7 +3011,8 @@ "MON-05" ], "A.03.03.04.b": [ - "MON-05" + "MON-05", + "IRO-02" ], "A.03.03.06.a[01]": [ "MON-06" @@ -1490,14 +3049,25 @@ "MON-08" ], "A.03.03.08.a[01]": [ - "MON-08" + "MON-08", + "MON-08.1", + "MON-08.2", + "MON-08.3" ], "A.03.03.08.b": [ "MON-08", - "MON-08.2" + "MON-08.2", + "IAC-08", + "IAC-21" ], - "A.03.14.06.b": [ - "MON-16" + "A.03.01.22.b[01]": [ + "MON-11", + "DCH-15" + ], + "A.03.01.01.e": [ + "MON-16", + "IAC-15", + "IAC-15.7" ], "A.03.13.08[01]": [ "CRY-01", @@ -1505,74 +3075,226 @@ ], "A.03.13.08[02]": [ "CRY-01", - "CRY-05" + "CRY-01.1", + "CRY-05", + "CRY-05.1" ], "A.03.13.11.ODP[01]": [ "CRY-01", "CRY-03", "CRY-05" ], - "A.03.13.11": [ - "CRY-01", - "CRY-03", - "CRY-05" + "A.03.01.16.a[02]": [ + "CRY-07", + "NET-01", + "NET-02.2", + "NET-15", + "SEA-01", + "SEA-02" ], - "A.03.13.10.ODP[01]": [ + "A.03.13.10[01]": [ + "CRY-08", "CRY-09" ], - "A.03.13.10[01]": [ + "A.03.13.10.ODP[01]": [ "CRY-09" ], "A.03.13.10[02]": [ - "CRY-09" + "CRY-09", + "CRY-09.3", + "CRY-09.4" ], - "A.03.15.02.c": [ + "A.03.01.01.d.01": [ + "DCH-01", + "DCH-01.2", + "HRS-02", + "IAC-01.2", + "IAC-15", + "IAC-15.1", + "IAC-20", + "IAC-20.1", + "IAC-21" + ], + "A.03.01.01.d.02": [ + "DCH-01", + "DCH-01.2", + "HRS-02", + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" + ], + "A.03.08.01[01]": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", "DCH-01.4", - "DCH-03.1", - "IAO-03" + "DCH-02", + "DCH-03", + "DCH-06", + "DCH-06.1", + "DCH-06.4", + "PES-01", + "PES-02", + "PES-02.1", + "PES-04", + "PES-04.1" ], - "A.03.17.01.c": [ + "A.03.08.01[02]": [ + "DCH-01", + "DCH-01.1", + "DCH-01.2", "DCH-01.4", - "DCH-03.1", - "RSK-09" + "DCH-02", + "DCH-03", + "DCH-06", + "DCH-06.1", + "DCH-06.4", + "PES-01", + "PES-02", + "PES-02.1", + "PES-04", + "PES-04.1" ], - "A.03.08.02": [ - "DCH-03" + "A.03.08.05.a[01]": [ + "DCH-01.1", + "DCH-07" ], - "A.03.08.04[01]": [ - "DCH-04" + "A.03.01.20.a": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.2", + "DCH-13.4", + "DCH-17", + "TPM-01", + "TPM-05.8" ], - "A.03.08.04[02]": [ - "DCH-04" + "A.03.01.20.b": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.3", + "DCH-14", + "DCH-14.2", + "TPM-01", + "TPM-05", + "TPM-05.8" ], - "A.03.08.04[03]": [ - "DCH-04" + "A.03.01.20.c.01": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.3", + "DCH-13.4", + "TPM-01", + "TPM-05", + "TPM-05.6", + "TPM-05.8" ], - "A.03.08.01[01]": [ - "DCH-06" + "A.03.01.20.d": [ + "DCH-01.2", + "DCH-13", + "DCH-13.1", + "DCH-13.2", + "DCH-13.4", + "MDM-01", + "MDM-07" ], - "A.03.08.01[02]": [ - "DCH-06" + "A.03.06.05.d": [ + "DCH-01.2", + "HRS-03", + "IAC-08", + "IAC-20.1", + "IRO-04" ], - "A.03.08.05.a[01]": [ - "DCH-07" + "A.03.08.02": [ + "DCH-01.2", + "DCH-01.4", + "DCH-03", + "HRS-03", + "PES-01", + "PES-02", + "PES-02.1", + "PES-04", + "PES-04.1" ], "A.03.08.05.a[02]": [ - "DCH-07" + "DCH-01.2", + "DCH-07", + "DCH-07.1", + "DCH-07.2" ], - "A.03.08.05.b": [ - "DCH-07" + "A.03.17.01.c": [ + "DCH-01.2", + "DCH-01.4", + "DCH-03.1" ], "A.03.08.05.c": [ + "DCH-01.3", "DCH-07" ], - "A.03.08.03": [ - "DCH-09" + "A.03.01.04.a": [ + "DCH-01.4", + "HRS-11", + "HRS-12", + "IAC-20", + "IAC-20.1", + "IAC-21" ], - "A.03.08.07.ODP[01]": [ - "DCH-10" + "A.03.10.01.a[01]": [ + "DCH-01.4", + "IAC-20.1", + "PES-01", + "PES-02" ], - "A.03.08.07.a": [ + "A.03.10.01.a[02]": [ + "DCH-01.4", + "IAC-20.1", + "PES-01", + "PES-02", + "PES-06", + "PES-06.1" + ], + "A.03.10.01.a[03]": [ + "DCH-01.4", + "IAC-20.1", + "PES-01", + "PES-02" + ], + "A.03.15.02.c": [ + "DCH-01.4", + "DCH-03.1" + ], + "A.03.08.04[01]": [ + "DCH-02", + "DCH-04" + ], + "A.03.01.22.a": [ + "DCH-03.1", + "DCH-15", + "HRS-03", + "HRS-03.1", + "HRS-04.1", + "HRS-04.2", + "HRS-05", + "HRS-05.1", + "SAT-02", + "SAT-03", + "SAT-03.3", + "WEB-01" + ], + "A.03.08.04[02]": [ + "DCH-04" + ], + "A.03.08.04[03]": [ + "DCH-04" + ], + "A.03.08.05.b": [ + "DCH-07", + "DCH-07.1" + ], + "A.03.08.07.ODP[01]": [ "DCH-10" ], "A.03.08.07.b": [ @@ -1581,30 +3303,25 @@ "A.03.01.20.ODP[01]": [ "DCH-13" ], - "A.03.01.20.a": [ - "DCH-13" - ], - "A.03.01.20.b": [ - "DCH-13" - ], - "A.03.01.20.c.01": [ - "DCH-13" - ], "A.03.01.20.c.02": [ - "DCH-13" - ], - "A.03.01.20.d": [ - "DCH-13.2" - ], - "A.03.01.22.a": [ - "DCH-15" + "DCH-13", + "DCH-13.1", + "DCH-14.2", + "DCH-14.3", + "DCH-18", + "NET-05", + "TPM-05" ], - "A.03.01.22.b[01]": [ - "DCH-15" + "A.03.12.05.a[01]": [ + "DCH-14.2", + "DCH-14.3", + "HRS-06", + "HRS-06.1", + "NET-05" ], - "A.03.01.22.b[02]": [ - "DCH-15", - "IRO-12" + "A.03.10.07.b": [ + "DCH-18", + "PES-03.3" ], "A.03.14.08[01]": [ "DCH-18" @@ -1618,48 +3335,37 @@ "A.03.14.08[04]": [ "DCH-18" ], - "A.03.14.02.ODP[01]": [ - "END-04" - ], "A.03.14.02.a[01]": [ + "END-01", + "END-04", + "END-04.3", + "END-04.7" + ], + "A.03.14.02.ODP[01]": [ "END-04" ], "A.03.14.02.a[02]": [ "END-04" ], + "A.03.14.02.c.01[01]": [ + "END-04", + "END-04.7" + ], "A.03.14.02.c.02": [ "END-04" ], "A.03.14.02.b": [ "END-04.1" ], - "A.03.14.02.c.01[01]": [ - "END-04.7" - ], "A.03.14.02.c.01[02]": [ "END-04.7" ], - "A.03.13.13.a[01]": [ - "END-10" - ], - "A.03.13.13.a[02]": [ - "END-10" - ], - "A.03.13.13.b[01]": [ - "END-10" - ], - "A.03.13.13.b[02]": [ - "END-10" - ], "A.03.13.12.ODP[01]": [ "END-14" ], "A.03.13.12.a": [ "END-14" ], - "A.03.13.12.b": [ - "END-14.6" - ], "A.03.01.01.ODP[01]": [ "HRS-01", "IAC-15" @@ -1673,123 +3379,274 @@ "A.03.01.01.ODP[04]": [ "HRS-01" ], - "A.03.06.05.d": [ - "HRS-03", + "A.03.01.01.g.02": [ + "HRS-01", + "HRS-08", + "HRS-09", + "HRS-09.4", + "IAC-07", + "IAC-07.1", + "IAC-15" + ], + "A.03.15.03.a": [ + "HRS-01", + "HRS-05", + "HRS-05.1", + "HRS-05.2", + "HRS-05.3", + "HRS-05.4", + "HRS-05.5" + ], + "A.03.01.01.c.01": [ + "HRS-02", "IAC-08", - "IAC-20.1", - "IRO-04" + "IAC-15", + "IAC-15.5" ], - "A.03.09.01.ODP[01]": [ - "HRS-04", - "HRS-04.1" + "A.03.01.01.c.02": [ + "HRS-02", + "IAC-08", + "IAC-15" ], "A.03.09.01.a": [ - "HRS-04" + "HRS-02", + "HRS-04", + "HRS-04.1" ], "A.03.09.01.b": [ - "HRS-04" - ], - "A.03.09.02.b.01[01]": [ + "HRS-02", "HRS-04", - "HRS-08" + "HRS-04.1" ], "A.03.15.03.b": [ + "HRS-02", + "HRS-03", + "HRS-03.1", + "HRS-04.2", "HRS-05" ], - "A.03.15.03.ODP[01]": [ - "HRS-05.1" + "A.03.02.02.a.01[01]": [ + "HRS-03", + "HRS-04.1", + "HRS-04.2", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" ], - "A.03.15.03.a": [ - "HRS-05.1", - "HRS-05.2", - "HRS-05.3", - "HRS-05.5" + "A.03.06.04.ODP[01]": [ + "HRS-03", + "HRS-04.2", + "SAT-03" ], - "A.03.15.03.d[01]": [ + "A.03.07.06.a": [ + "HRS-03", + "IAC-08", + "MNT-01", + "MNT-06", + "TPM-01", + "TPM-05" + ], + "A.03.07.06.d[02]": [ + "HRS-03", + "MNT-06.1" + ], + "A.03.16.03.b": [ + "HRS-03", + "HRS-10", + "TPM-05", + "TPM-05.2", + "TPM-05.4" + ], + "A.03.07.06.d[01]": [ + "HRS-03.2", + "MNT-06", + "MNT-06.1" + ], + "A.03.09.01.ODP[01]": [ + "HRS-04", + "HRS-04.1" + ], + "A.03.09.02.b.01[01]": [ + "HRS-04", + "HRS-08", + "HRS-09", + "HRS-09.2" + ], + "A.03.06.04.a.01": [ + "HRS-04.2", + "IRO-05", + "SAT-03" + ], + "A.03.15.03.ODP[01]": [ "HRS-05.1" ], "A.03.15.03.d[02]": [ - "HRS-05.1" + "HRS-05.1", + "HRS-05.7" ], "A.03.15.03.c": [ - "HRS-05.7" + "HRS-05.7", + "HRS-06", + "HRS-06.1" + ], + "A.03.01.01.f.04": [ + "HRS-07", + "HRS-07.1", + "IAC-15", + "IAC-15.6" + ], + "A.03.01.01.f.05": [ + "HRS-07", + "HRS-07.1", + "IAC-15", + "IAC-15.6" ], "A.03.09.02.ODP[01]": [ "HRS-08", "HRS-09" ], + "A.03.09.02.a.01": [ + "HRS-08", + "HRS-09", + "HRS-09.2", + "HRS-09.4", + "IAC-07", + "IAC-07.2" + ], "A.03.09.02.b.01[02]": [ - "HRS-08" + "HRS-08", + "IAC-07.1", + "IAC-20" ], "A.03.09.02.b.02": [ - "HRS-08" + "HRS-08", + "IAC-07.1", + "IAC-20" ], - "A.03.09.02.a.01": [ - "HRS-09" + "A.03.01.01.f.03": [ + "HRS-09", + "IAC-15" ], "A.03.09.02.a.02[01]": [ - "HRS-09" + "HRS-09", + "HRS-09.2", + "HRS-09.4", + "IAC-07", + "IAC-07.2" ], "A.03.09.02.a.02[02]": [ - "HRS-09" + "HRS-09", + "HRS-09.2", + "HRS-09.4", + "IAC-07", + "IAC-07.2" ], - "A.03.01.04.a": [ - "HRS-11" + "A.03.01.01.a[01]": [ + "IAC-01", + "IAC-15" ], - "A.03.01.01.d.01": [ + "A.03.01.01.a[02]": [ + "IAC-01", + "IAC-15" + ], + "A.03.01.18.b": [ + "IAC-01", + "IAC-04", + "MDM-02", + "MDM-06", + "MDM-07", + "MDM-11" + ], + "A.03.05.01.a[01]": [ + "IAC-01", "IAC-01.2" ], - "A.03.01.01.d.02": [ - "IAC-01.2" + "A.03.05.05.a": [ + "IAC-01", + "IAC-07", + "IAC-07.1", + "IAC-28.1" + ], + "A.03.05.12.e": [ + "IAC-01", + "IAC-10", + "IAC-10.1", + "IAC-15.1" ], "A.03.01.16.b": [ "IAC-01.2", - "NET-02.2" - ], - "A.03.05.01.a[01]": [ - "IAC-01.2" + "NET-02.2", + "NET-15", + "NET-15.1" ], "A.03.05.01.a[02]": [ "IAC-01.2" ], - "A.03.05.01.a[03]": [ - "IAC-02" + "A.03.05.02[01]": [ + "IAC-01.2", + "IAC-04", + "IAC-05" + ], + "A.03.05.02[02]": [ + "IAC-01.2", + "IAC-04", + "IAC-05" ], "A.03.05.05.d": [ + "IAC-01.2", "IAC-02", - "IAC-09.2" + "IAC-09", + "IAC-09.2", + "IAC-09.5", + "IAC-15.1" ], - "A.03.05.02.ODP[01]": [ - "IAC-04" + "A.03.05.07.a[01]": [ + "IAC-01.2", + "IAC-10", + "IAC-10.4", + "IAC-10.11" ], - "A.03.05.02[01]": [ - "IAC-04" + "A.03.05.07.b": [ + "IAC-01.2", + "IAC-10", + "IAC-10.4", + "IAC-10.11" ], - "A.03.05.02[02]": [ + "A.03.05.01.a[03]": [ + "IAC-02", + "IAC-03", + "IAC-05" + ], + "A.03.07.05.b[02]": [ + "IAC-02.2" + ], + "A.03.05.02.ODP[01]": [ "IAC-04" ], "A.03.05.03[01]": [ "IAC-06", + "IAC-06.1", + "IAC-06.3", "IAC-06.4" ], "A.03.05.03[02]": [ "IAC-06", + "IAC-06.2", "IAC-06.4" ], - "A.03.07.05.b[01]": [ - "IAC-06" - ], "A.03.01.01.b[01]": [ "IAC-07", - "IAC-15.7" + "IAC-15" ], "A.03.01.01.b[02]": [ "IAC-07", - "IAC-15.7" + "IAC-15", + "IAC-28.1" ], "A.03.01.01.b[03]": [ "IAC-07", - "IAC-15.7" + "IAC-15" ], "A.03.01.01.b[04]": [ "IAC-07", @@ -1799,14 +3656,22 @@ "IAC-07", "IAC-15.7" ], - "A.03.05.05.a": [ - "IAC-07" + "A.03.01.01.g.01": [ + "IAC-07", + "IAC-07.1", + "IAC-15" ], - "A.03.01.01.c.02": [ - "IAC-08" + "A.03.01.01.g.03": [ + "IAC-07", + "IAC-07.1", + "IAC-15", + "IAC-17" ], "A.03.01.01.c.03": [ - "IAC-08" + "IAC-08", + "IAC-20", + "IAC-20.1", + "IAC-21" ], "A.03.01.05.ODP[01]": [ "IAC-08" @@ -1816,26 +3681,49 @@ ], "A.03.01.05.b[01]": [ "IAC-08", - "IAC-20.1" + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" ], "A.03.01.05.b[02]": [ "IAC-08", - "IAC-20.1" + "IAC-15", + "IAC-20", + "IAC-20.1", + "IAC-21" + ], + "A.03.01.06.a": [ + "IAC-08", + "IAC-16", + "IAC-20", + "IAC-21", + "IAC-21.3" + ], + "A.03.01.12.a[02]": [ + "IAC-08", + "NET-14" ], "A.03.04.05[04]": [ - "IAC-08" + "IAC-08", + "IAC-21" ], "A.03.05.05.ODP[01]": [ "IAC-09" ], "A.03.05.05.b[01]": [ - "IAC-09" + "IAC-09", + "IAC-09.1", + "IAC-15.1" ], "A.03.05.05.b[02]": [ - "IAC-09" + "IAC-09", + "IAC-09.1", + "IAC-15.1" ], "A.03.05.05.c": [ - "IAC-09" + "IAC-09", + "IAC-15.1" ], "A.03.05.05.ODP[02]": [ "IAC-09.2" @@ -1847,10 +3735,13 @@ "IAC-10" ], "A.03.05.12.a": [ - "IAC-10" + "IAC-10", + "IAC-10.3", + "IAC-28" ], "A.03.05.12.b": [ - "IAC-10" + "IAC-10", + "IAC-10.1" ], "A.03.05.12.c[01]": [ "IAC-10" @@ -1870,19 +3761,15 @@ "A.03.05.12.c[06]": [ "IAC-10" ], - "A.03.05.12.d": [ - "IAC-10" - ], - "A.03.05.12.e": [ - "IAC-10" - ], "A.03.05.12.f[01]": [ "IAC-10", - "IAC-10.5" + "IAC-10.5", + "IAC-15.1" ], "A.03.05.12.f[02]": [ "IAC-10", - "IAC-10.5" + "IAC-10.5", + "IAC-15.1" ], "A.03.05.07.ODP[02]": [ "IAC-10.1" @@ -1891,10 +3778,6 @@ "IAC-10.4", "IAC-10.11" ], - "A.03.05.07.a[01]": [ - "IAC-10.4", - "IAC-10.11" - ], "A.03.05.07.a[02]": [ "IAC-10.4", "IAC-10.11" @@ -1903,10 +3786,6 @@ "IAC-10.4", "IAC-10.11" ], - "A.03.05.07.b": [ - "IAC-10.4", - "IAC-10.11" - ], "A.03.05.11": [ "IAC-11" ], @@ -1916,21 +3795,6 @@ "A.03.05.01.b": [ "IAC-14" ], - "A.03.01.01.a[01]": [ - "IAC-15", - "IAC-15.7" - ], - "A.03.01.01.a[02]": [ - "IAC-15", - "IAC-15.7" - ], - "A.03.01.01.c.01": [ - "IAC-15", - "IAC-15.7" - ], - "A.03.01.01.e": [ - "IAC-15" - ], "A.03.01.01.f.01": [ "IAC-15" ], @@ -1938,37 +3802,36 @@ "IAC-15", "IAC-15.3" ], - "A.03.01.01.f.03": [ - "IAC-15" - ], - "A.03.01.01.f.04": [ - "IAC-15" - ], - "A.03.01.01.f.05": [ - "IAC-15" - ], - "A.03.01.01.g.01": [ - "IAC-15" + "A.03.01.05.c": [ + "IAC-15", + "IAC-15.7", + "IAC-17" ], - "A.03.01.01.g.02": [ - "IAC-15" + "A.03.01.05.d": [ + "IAC-15", + "IAC-17" ], - "A.03.01.01.g.03": [ - "IAC-15" + "A.03.01.07.a": [ + "IAC-16", + "IAC-21", + "IAC-21.3", + "IAC-21.5" ], "A.03.01.05.ODP[03]": [ "IAC-17" ], - "A.03.01.05.c": [ - "IAC-17" - ], - "A.03.01.05.d": [ - "IAC-17" + "A.03.10.01.c": [ + "IAC-17", + "PES-02" ], - "A.03.01.02[02]": [ - "IAC-21" + "A.03.10.01.d": [ + "IAC-17", + "PES-02", + "PES-02.1" ], "A.03.01.05.a": [ + "IAC-20", + "IAC-20.1", "IAC-21" ], "A.03.01.06.b": [ @@ -1977,12 +3840,6 @@ "A.03.01.06.ODP[01]": [ "IAC-21.3" ], - "A.03.01.06.a": [ - "IAC-21.3" - ], - "A.03.01.07.a": [ - "IAC-21.5" - ], "A.03.01.08.ODP[01]": [ "IAC-22" ], @@ -1995,48 +3852,30 @@ "A.03.01.08.ODP[04]": [ "IAC-22" ], - "A.03.01.08.a": [ - "IAC-22" - ], - "A.03.01.08.b": [ - "IAC-22" - ], "A.03.01.10.ODP[01]": [ "IAC-24" ], "A.03.01.10.ODP[02]": [ "IAC-24" ], - "A.03.01.10.a": [ - "IAC-24" - ], - "A.03.01.10.b": [ - "IAC-24" - ], - "A.03.01.10.c": [ - "IAC-24.1" - ], "A.03.01.01.ODP[05]": [ "IAC-25" ], "A.03.01.01.ODP[06]": [ "IAC-25" ], - "A.03.01.01.h": [ - "IAC-25" - ], "A.03.01.11.ODP[01]": [ "IAC-25" ], - "A.03.01.11": [ - "IAC-25" - ], "A.03.07.05.c[01]": [ "IAC-25", + "MNT-05", "MNT-05.4" ], "A.03.06.01[01]": [ - "IRO-01" + "IRO-01", + "IRO-04", + "IRO-12" ], "A.03.06.01[02]": [ "IRO-02" @@ -2053,11 +3892,35 @@ "A.03.06.01[06]": [ "IRO-02" ], + "A.03.06.02.a[01]": [ + "IRO-02", + "IRO-09" + ], + "A.03.06.02.a[02]": [ + "IRO-02", + "IRO-09" + ], "A.03.06.02.b": [ "IRO-02", "IRO-07", + "IRO-09", + "IRO-10", + "IRO-10.2" + ], + "A.03.06.02.c": [ + "IRO-02", "IRO-10" ], + "A.03.06.02.d": [ + "IRO-02", + "IRO-07", + "IRO-10", + "IRO-11" + ], + "A.03.06.05.b[01]": [ + "IRO-02", + "IRO-04" + ], "A.03.06.02.ODP[01]": [ "IRO-04", "IRO-10" @@ -2085,63 +3948,40 @@ "A.03.06.05.a.06": [ "IRO-04" ], - "A.03.06.05.b[01]": [ - "IRO-04" - ], "A.03.06.05.b[02]": [ "IRO-04" ], "A.03.06.05.c": [ "IRO-04.2" ], - "A.03.06.04.ODP[01]": [ - "IRO-05" - ], - "A.03.06.04.ODP[02]": [ - "IRO-05" - ], - "A.03.06.04.ODP[03]": [ - "IRO-05" - ], - "A.03.06.04.ODP[04]": [ - "IRO-05", - "IRO-13" + "A.03.06.04.b[03]": [ + "IRO-04.3", + "IRO-13", + "SAT-01.1" ], - "A.03.06.04.a.01": [ + "A.03.06.04.a.03": [ "IRO-05", + "SAT-02", "SAT-03" ], - "A.03.06.04.b[01]": [ - "IRO-05" - ], - "A.03.06.04.b[02]": [ - "IRO-05" - ], - "A.03.06.04.b[03]": [ - "IRO-05" - ], - "A.03.06.04.b[04]": [ - "IRO-05" - ], "A.03.06.03.ODP[01]": [ "IRO-06" ], "A.03.06.03": [ "IRO-06" ], - "A.03.06.02.d": [ - "IRO-07", - "IRO-10", - "IRO-11" - ], - "A.03.06.02.a[01]": [ - "IRO-09" + "A.03.01.22.b[02]": [ + "IRO-12", + "WEB-14" ], - "A.03.06.02.a[02]": [ - "IRO-09" + "A.03.06.04.b[04]": [ + "IRO-13", + "SAT-01.1" ], - "A.03.06.02.c": [ - "IRO-10" + "A.03.01.16.a[01]": [ + "IAO-03", + "NET-02.2", + "NET-15" ], "A.03.15.02.ODP[01]": [ "IAO-03" @@ -2176,12 +4016,6 @@ "A.03.15.02.b[02]": [ "IAO-03" ], - "A.03.12.02.a.01": [ - "IAO-05" - ], - "A.03.12.02.a.02": [ - "IAO-05" - ], "A.03.12.02.b.01": [ "IAO-05" ], @@ -2191,80 +4025,76 @@ "A.03.12.02.b.03": [ "IAO-05" ], - "A.03.07.04.a[01]": [ - "MNT-04" - ], - "A.03.07.04.a[02]": [ - "MNT-04" + "A.03.14.01.a[01]": [ + "IAO-05", + "TDA-01", + "TDA-09", + "THR-01", + "THR-06", + "VPM-01", + "VPM-01.1", + "VPM-06" ], "A.03.07.04.a[03]": [ "MNT-04" ], "A.03.07.04.b": [ + "MNT-04.1", "MNT-04.2" ], - "A.03.07.04.c": [ - "MNT-04.3" - ], - "A.03.07.05.a[01]": [ - "MNT-05" + "A.03.01.12.d[1]": [ + "MNT-05", + "NET-14.4" ], "A.03.07.05.a[02]": [ - "MNT-05" - ], - "A.03.07.06.a": [ - "MNT-06" + "MNT-05", + "MNT-05.1" ], "A.03.07.06.b": [ - "MNT-06" + "MNT-06", + "TPM-01.1", + "TPM-05.4" ], "A.03.07.06.c": [ "MNT-06", "MNT-06.1", "MNT-06.2" ], - "A.03.07.06.d[01]": [ - "MNT-06" - ], - "A.03.07.06.d[02]": [ - "MNT-06" - ], - "A.03.01.18.a[01]": [ - "MDM-01" - ], - "A.03.01.18.b": [ - "MDM-02" - ], "A.03.01.18.c": [ "MDM-03" ], - "A.03.01.16.a[01]": [ - "NET-02.2", - "NET-15" - ], - "A.03.01.16.a[02]": [ - "NET-02.2", - "NET-15" - ], - "A.03.01.16.a[04]": [ - "NET-02.2", - "NET-15" - ], "A.03.01.18.a[03]": [ + "NET-01", "NET-03" ], "A.03.13.01.a[02]": [ - "NET-03" + "NET-01", + "NET-03", + "NET-04", + "NET-04.1", + "NET-08" + ], + "A.03.13.01.b": [ + "NET-02", + "NET-03", + "NET-03.8", + "NET-06", + "NET-06.3", + "NET-08.1" + ], + "A.03.01.16.a[04]": [ + "NET-02.2", + "NET-15", + "NET-15.1" ], "A.03.13.01.a[04]": [ "NET-03" ], "A.03.13.01.c": [ - "NET-03" - ], - "A.03.01.03[02]": [ + "NET-03", "NET-04", - "NET-05" + "SEA-01", + "SEA-02" ], "A.03.13.06[01]": [ "NET-04.1" @@ -2278,9 +4108,6 @@ "A.03.12.05.ODP[02]": [ "NET-05" ], - "A.03.12.05.a[01]": [ - "NET-05" - ], "A.03.12.05.a[02]": [ "NET-05" ], @@ -2299,9 +4126,6 @@ "A.03.12.05.c[02]": [ "NET-05" ], - "A.03.13.01.b": [ - "NET-06" - ], "A.03.07.05.c[02]": [ "NET-07" ], @@ -2314,33 +4138,16 @@ "A.03.13.15": [ "NET-09" ], - "A.03.01.12.a[01]": [ - "NET-14" - ], - "A.03.01.12.a[02]": [ - "NET-14" - ], - "A.03.01.12.a[03]": [ - "NET-14" - ], "A.03.01.12.a[04]": [ - "NET-14" + "NET-14", + "NET-14.2", + "SEA-01" ], "A.03.01.12.b": [ - "NET-14" - ], - "A.03.01.12.c[01]": [ - "NET-14" - ], - "A.03.01.12.c[02]": [ - "NET-14" - ], - "A.03.01.12.d[1]": [ "NET-14", - "NET-14.4" + "NET-14.1" ], "A.03.01.12.d[2]": [ - "NET-14", "NET-14.4" ], "A.03.10.06.ODP[01]": [ @@ -2361,6 +4168,18 @@ "A.03.01.16.d[02]": [ "NET-15.1" ], + "A.03.14.06.c[02]": [ + "NET-18" + ], + "A.03.10.07.a.01": [ + "PES-01", + "PES-02", + "PES-03", + "PES-03.1", + "PES-03.4", + "PES-04", + "PES-04.1" + ], "A.03.04.05[02]": [ "PES-02" ], @@ -2368,41 +4187,36 @@ "PES-02", "PES-02.1" ], - "A.03.10.01.a[01]": [ - "PES-02" - ], - "A.03.10.01.a[02]": [ - "PES-02" - ], - "A.03.10.01.a[03]": [ - "PES-02" - ], - "A.03.10.01.c": [ - "PES-02" - ], - "A.03.10.01.d": [ - "PES-02" - ], - "A.03.10.07.a.01": [ - "PES-02" - ], - "A.03.04.05[01]": [ + "A.03.10.01.b": [ + "PES-02", "PES-02.1" ], - "A.03.10.01.b": [ + "A.03.04.05[01]": [ "PES-02.1" ], "A.03.04.05[03]": [ "PES-03" ], + "A.03.10.02.a[01]": [ + "PES-03", + "PES-03.1", + "PES-03.3", + "PES-05", + "PES-05.1", + "PES-05.2" + ], "A.03.10.07.a.02": [ - "PES-03" + "PES-03", + "PES-03.1", + "PES-03.3", + "PES-03.4", + "PES-04", + "PES-04.1" ], "A.03.10.07.d": [ - "PES-03" - ], - "A.03.10.07.b": [ - "PES-03.3" + "PES-03", + "PES-04", + "PES-04.1" ], "A.03.10.02.ODP[01]": [ "PES-05" @@ -2410,48 +4224,68 @@ "A.03.10.02.ODP[02]": [ "PES-05" ], - "A.03.10.02.a[01]": [ - "PES-05" - ], "A.03.10.02.a[02]": [ "PES-05" ], "A.03.10.02.b[01]": [ - "PES-05" + "PES-05", + "PES-05.2" ], "A.03.10.02.b[02]": [ - "PES-05" + "PES-05", + "PES-05.2" ], "A.03.10.07.c[01]": [ "PES-06", "PES-06.1", - "PES-06.3" + "PES-06.2", + "PES-06.3", + "PES-06.6" ], "A.03.10.07.c[02]": [ "PES-06", "PES-06.1", - "PES-06.3" + "PES-06.2", + "PES-06.3", + "PES-06.6" ], "A.03.10.08": [ + "PES-07", + "PES-12", "PES-12.1" ], "A.03.10.07.e": [ + "PES-12", "PES-12.2" ], "A.03.17.03.b": [ "RSK-01", - "RSK-09" + "RSK-09", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7" ], - "A.03.11.01.a": [ - "RSK-01.1", - "RSK-03", - "RSK-03.1", - "RSK-04", - "RSK-09" + "A.03.14.03.a": [ + "RSK-02.1", + "THR-01", + "THR-03", + "THR-03.1", + "THR-10" ], - "A.03.11.01.b": [ - "RSK-04", - "RSK-07" + "A.03.11.02.b": [ + "RSK-06", + "RSK-06.1", + "RSK-06.2", + "VPM-02", + "VPM-04", + "VPM-05" ], "A.03.11.04[01]": [ "RSK-06.1" @@ -2465,10 +4299,11 @@ "A.03.11.01.ODP[01]": [ "RSK-07" ], - "A.03.17.01.ODP[01]": [ - "RSK-09" + "A.03.11.01.b": [ + "RSK-07", + "RSK-09.1" ], - "A.03.17.01.a[01]": [ + "A.03.17.01.ODP[01]": [ "RSK-09" ], "A.03.17.01.a[02]": [ @@ -2510,10 +4345,18 @@ ], "A.03.17.03.a[01]": [ "RSK-09", + "RSK-09.1", + "TPM-02", + "TPM-03", + "TPM-03.1", + "TPM-03.2", + "TPM-03.3", + "TPM-04", "TPM-04.1" ], "A.03.17.03.a[02]": [ - "RSK-09" + "RSK-09", + "TPM-05.5" ], "A.03.16.01.ODP[01]": [ "SEA-01", @@ -2526,10 +4369,14 @@ "A.03.13.04[02]": [ "SEA-05" ], - "A.03.01.09": [ - "SEA-18", - "SEA-18.1", - "SEA-18.2" + "A.03.16.02.b": [ + "SEA-07", + "SEA-07.1", + "TDA-17.1" + ], + "A.03.16.02.a": [ + "SEA-07.1", + "TDA-17" ], "A.03.02.01.ODP[01]": [ "SAT-01" @@ -2538,10 +4385,38 @@ "SAT-01" ], "A.03.02.01.a.01[01]": [ - "SAT-01" + "SAT-01", + "SAT-02", + "SAT-03", + "SAT-03.3", + "SAT-03.5", + "SAT-03.6" ], - "A.03.02.01.a.01[02]": [ - "SAT-01" + "A.03.02.01.b[01]": [ + "SAT-01.1" + ], + "A.03.02.01.b[02]": [ + "SAT-01.1", + "SAT-03.6", + "THR-03" + ], + "A.03.02.02.b[01]": [ + "SAT-01.1" + ], + "A.03.02.02.b[02]": [ + "SAT-01.1" + ], + "A.03.06.04.ODP[03]": [ + "SAT-01.1" + ], + "A.03.06.04.ODP[04]": [ + "SAT-01.1" + ], + "A.03.06.04.b[01]": [ + "SAT-01.1" + ], + "A.03.06.04.b[02]": [ + "SAT-01.1" ], "A.03.02.01.ODP[03]": [ "SAT-02" @@ -2550,16 +4425,25 @@ "SAT-02" ], "A.03.02.01.a.03[03]": [ - "SAT-02" + "SAT-02", + "SAT-02.2" ], "A.03.02.01.a.03[04]": [ "SAT-02" ], "A.03.02.01.a.03[05]": [ - "SAT-02" + "SAT-02.2" ], "A.03.02.01.a.03[06]": [ - "SAT-02" + "SAT-02.2" + ], + "A.03.02.01.a.01[02]": [ + "SAT-03" + ], + "A.03.02.01.a.02": [ + "SAT-03", + "SAT-03.6", + "THR-03" ], "A.03.02.02.ODP[01]": [ "SAT-03" @@ -2573,9 +4457,6 @@ "A.03.02.02.ODP[04]": [ "SAT-03" ], - "A.03.02.02.a.01[01]": [ - "SAT-03" - ], "A.03.02.02.a.01[02]": [ "SAT-03" ], @@ -2583,71 +4464,91 @@ "SAT-03" ], "A.03.02.02.a.02": [ - "SAT-03" - ], - "A.03.02.02.b[01]": [ - "SAT-03" + "SAT-03", + "SAT-03.6" ], - "A.03.02.02.b[02]": [ + "A.03.06.04.ODP[02]": [ "SAT-03" ], "A.03.06.04.a.02": [ - "SAT-03" - ], - "A.03.06.04.a.03": [ - "SAT-03" - ], - "A.03.02.01.a.02": [ - "SAT-03.6" - ], - "A.03.02.01.b[01]": [ - "SAT-03.6" - ], - "A.03.02.01.b[02]": [ + "SAT-03", "SAT-03.6" ], "A.03.17.02[04]": [ - "TDA-01" + "TDA-01", + "TPM-01", + "TPM-03.1" ], "A.03.17.02[05]": [ - "TDA-01" + "TDA-01", + "TPM-01", + "TPM-03.1", + "TPM-04", + "TPM-04.1", + "TPM-05", + "TPM-05.1", + "TPM-05.2", + "TPM-05.5", + "TPM-05.7", + "TPM-08" ], "A.03.17.02[06]": [ - "TDA-01" + "TDA-01", + "TPM-01", + "TPM-04", + "TPM-04.1", + "TPM-05.5", + "TPM-05.7", + "TPM-08", + "TPM-09", + "TPM-10" ], - "A.03.16.02.a": [ - "TDA-17" + "A.03.14.01.a[02]": [ + "TDA-09", + "THR-06", + "VPM-06" ], - "A.03.16.02.b": [ - "TDA-17.1" + "A.03.16.03.a": [ + "TPM-01", + "TPM-04", + "TPM-04.4", + "TPM-05", + "TPM-05.2", + "TPM-05.8" ], "A.03.17.02[01]": [ "TPM-03.1" ], "A.03.17.02[02]": [ - "TPM-03.1" + "TPM-03.1", + "TPM-04", + "TPM-04.1" ], "A.03.17.02[03]": [ - "TPM-03.1" - ], - "A.03.16.03.ODP[01]": [ - "TPM-05", - "TPM-05.2" - ], - "A.03.16.03.a": [ - "TPM-05" - ], - "A.03.16.03.b": [ - "TPM-05.4" + "TPM-03.1", + "TPM-04", + "TPM-04.1" ], "A.03.16.03.c": [ + "TPM-04", + "TPM-05", + "TPM-05.2", "TPM-05.5", "TPM-05.6", "TPM-05.8", "TPM-08" ], - "A.03.14.03.a": [ - "THR-03" + "A.03.16.03.ODP[01]": [ + "TPM-05", + "TPM-05.2" + ], + "A.03.11.02.a[01]": [ + "THR-01", + "THR-03", + "VPM-01", + "VPM-01.1", + "VPM-03", + "VPM-06" ], "A.03.14.03.b[01]": [ "THR-03.1" @@ -2665,11 +4566,7 @@ "VPM-01", "VPM-02" ], - "A.03.11.02.a[01]": [ - "VPM-01.1", - "VPM-06" - ], - "A.03.11.02.b": [ + "A.03.14.01.a[03]": [ "VPM-04", "VPM-05" ], @@ -2679,15 +4576,6 @@ "A.03.14.01.ODP[02]": [ "VPM-05" ], - "A.03.14.01.a[01]": [ - "VPM-05" - ], - "A.03.14.01.a[02]": [ - "VPM-05" - ], - "A.03.14.01.a[03]": [ - "VPM-05" - ], "A.03.14.01.b[01]": [ "VPM-05" ], @@ -2714,11 +4602,9 @@ "VPM-06" ], "A.03.11.02.c[01]": [ - "VPM-06", "VPM-06.1" ], "A.03.11.02.c[02]": [ - "VPM-06", "VPM-06.1" ] } diff --git a/docs/api/crosswalks/general-nist-800-171a.json b/docs/api/crosswalks/general-nist-800-171a.json index 861c6f67..b68c0155 100644 --- a/docs/api/crosswalks/general-nist-800-171a.json +++ b/docs/api/crosswalks/general-nist-800-171a.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-171a", - "display_name": "NIST SP 800-171A", + "display_name": "NIST SP 800 - 171A - Assessing Security Requirements for Controlled Unclassified Information", "scf_to_framework": { "total_mappings": 134, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-172-r3.json b/docs/api/crosswalks/general-nist-800-172-r3.json new file mode 100644 index 00000000..edb9c893 --- /dev/null +++ b/docs/api/crosswalks/general-nist-800-172-r3.json @@ -0,0 +1,1018 @@ +{ + "framework_id": "general-nist-800-172-r3", + "display_name": "NIST SP 800 - 172 R3 - Enhanced Security Requirements for Protecting Controlled Unclassified Information", + "scf_to_framework": { + "total_mappings": 162, + "mappings": { + "GOV-02": [ + "03.01.17E", + "03.05.07E", + "03.17.03E" + ], + "AST-02.2": [ + "03.04.02E" + ], + "AST-02.8": [ + "03.01.14E" + ], + "AST-02.9": [ + "03.04.03E", + "03.04.08E" + ], + "AST-03.2": [ + "03.17.04E" + ], + "AST-04": [ + "03.01.14E" + ], + "AST-04.1": [ + "03.06.03E" + ], + "AST-08": [ + "03.17.02E", + "03.17.05E" + ], + "AST-15": [ + "03.17.05E" + ], + "AST-15.1": [ + "03.17.02E" + ], + "BCD-01": [ + "03.04.04E", + "03.08.04E" + ], + "BCD-01.4": [ + "03.08.04E" + ], + "BCD-02": [ + "03.11.10E" + ], + "BCD-11.1": [ + "03.08.03E" + ], + "BCD-11.8": [ + "03.08.02E" + ], + "BCD-12": [ + "03.08.04E" + ], + "CAP-01": [ + "03.13.12E" + ], + "CAP-02": [ + "03.13.12E" + ], + "CAP-03": [ + "03.13.12E" + ], + "CHG-02.2": [ + "03.04.07E" + ], + "CHG-04.3": [ + "03.04.05E" + ], + "CHG-06": [ + "03.04.07E" + ], + "CPL-02": [ + "03.12.03E" + ], + "CFG-02": [ + "03.01.04E", + "03.01.14E", + "03.01.16E", + "03.05.01E", + "03.05.05E", + "03.12.04E", + "03.13.06E", + "03.13.11E", + "03.13.13E", + "03.14.11E" + ], + "CFG-02.2": [ + "03.04.02E", + "03.04.04E" + ], + "CFG-02.3": [ + "03.04.06E" + ], + "CFG-02.8": [ + "03.04.02E" + ], + "CFG-03.3": [ + "03.13.06E" + ], + "CFG-05.1": [ + "03.04.02E" + ], + "CFG-06.1": [ + "03.14.11E" + ], + "MON-01.4": [ + "03.14.17E" + ], + "MON-01.5": [ + "03.14.19E" + ], + "MON-01.7": [ + "03.14.01E" + ], + "MON-01.8": [ + "03.01.08E", + "03.11.09E", + "03.14.01E" + ], + "MON-01.12": [ + "03.14.17E", + "03.14.18E" + ], + "MON-02.3": [ + "03.03.04E" + ], + "MON-05": [ + "03.03.02E" + ], + "MON-05.1": [ + "03.03.02E" + ], + "MON-08.1": [ + "03.03.01E" + ], + "MON-08.4": [ + "03.03.03E" + ], + "MON-11.3": [ + "03.01.08E", + "03.11.02E", + "03.11.09E", + "03.14.17E", + "03.14.18E" + ], + "MON-16": [ + "03.01.08E", + "03.06.03E" + ], + "CRY-01": [ + "03.14.09E" + ], + "DCH-01": [ + "03.01.17E" + ], + "DCH-01.2": [ + "03.01.17E" + ], + "DCH-01.4": [ + "03.01.17E" + ], + "DCH-02": [ + "03.01.17E" + ], + "DCH-09": [ + "03.08.01E" + ], + "DCH-09.5": [ + "03.08.01E", + "03.08.02E" + ], + "DCH-13.4": [ + "03.01.02E" + ], + "DCH-18": [ + "03.04.06E", + "03.10.01E" + ], + "END-03.1": [ + "03.04.02E" + ], + "END-06": [ + "03.14.01E" + ], + "END-06.1": [ + "03.14.08E" + ], + "END-06.2": [ + "03.14.11E" + ], + "END-06.6": [ + "03.14.10E" + ], + "END-06.8": [ + "03.14.11E" + ], + "END-10": [ + "03.13.06E" + ], + "END-11": [ + "03.13.11E" + ], + "END-12": [ + "03.13.13E" + ], + "HRS-01": [ + "03.09.03E", + "03.09.04E" + ], + "HRS-03": [ + "03.01.08E", + "03.01.11E", + "03.14.17E", + "03.14.18E", + "03.17.03E" + ], + "HRS-04.3": [ + "03.09.04E" + ], + "HRS-06": [ + "03.09.03E" + ], + "HRS-12.1": [ + "03.01.01E" + ], + "IAC-01": [ + "03.05.07E" + ], + "IAC-01.4": [ + "03.05.07E" + ], + "IAC-04": [ + "03.05.01E", + "03.05.03E" + ], + "IAC-04.1": [ + "03.05.03E" + ], + "IAC-08": [ + "03.01.11E" + ], + "IAC-10.1": [ + "03.05.02E" + ], + "IAC-10.4": [ + "03.05.02E" + ], + "IAC-10.5": [ + "03.05.02E" + ], + "IAC-10.6": [ + "03.05.04E" + ], + "IAC-10.10": [ + "03.05.05E" + ], + "IAC-10.11": [ + "03.05.02E" + ], + "IAC-15.1": [ + "03.01.07E", + "03.01.11E" + ], + "IAC-15.4": [ + "03.01.07E" + ], + "IAC-20.5": [ + "03.01.01E" + ], + "IAC-23": [ + "03.01.04E" + ], + "IAC-28": [ + "03.05.06E" + ], + "IAC-29": [ + "03.01.09E" + ], + "IRO-01": [ + "03.11.09E" + ], + "IRO-02": [ + "03.17.03E" + ], + "IRO-03": [ + "03.01.08E", + "03.02.01E", + "03.11.02E", + "03.11.09E", + "03.14.17E" + ], + "IRO-07": [ + "03.06.02E" + ], + "IRO-09.1": [ + "03.06.04E" + ], + "IRO-15": [ + "03.13.14E" + ], + "IAO-02.1": [ + "03.12.02E" + ], + "IAO-03": [ + "03.01.04E", + "03.01.06E", + "03.13.11E", + "03.13.14E", + "03.13.16E", + "03.14.08E", + "03.14.10E", + "03.14.14E", + "03.14.15E", + "03.14.16E", + "03.15.01E", + "03.15.02E", + "03.15.03E", + "03.16.01E", + "03.17.02E" + ], + "MNT-04": [ + "03.07.01E" + ], + "NET-02.1": [ + "03.13.12E" + ], + "NET-03": [ + "03.01.12E", + "03.13.04E" + ], + "NET-03.7": [ + "03.13.04E" + ], + "NET-03.8": [ + "03.13.10E", + "03.13.15E" + ], + "NET-04.2": [ + "03.01.10E" + ], + "NET-04.5": [ + "03.01.13E" + ], + "NET-04.7": [ + "03.01.10E", + "03.01.13E", + "03.01.14E" + ], + "NET-04.8": [ + "03.01.13E", + "03.01.14E", + "03.01.15E" + ], + "NET-04.9": [ + "03.01.16E" + ], + "NET-04.10": [ + "03.01.17E" + ], + "NET-05": [ + "03.12.04E" + ], + "NET-05.2": [ + "03.12.04E" + ], + "NET-06": [ + "03.01.12E" + ], + "NET-06.1": [ + "03.13.09E", + "03.13.15E" + ], + "NET-06.9": [ + "03.13.09E", + "03.13.15E" + ], + "NET-14": [ + "03.01.06E" + ], + "NET-14.1": [ + "03.01.05E" + ], + "NET-17": [ + "03.01.17E" + ], + "PES-05": [ + "03.10.01E", + "03.10.02E" + ], + "PES-05.1": [ + "03.10.01E" + ], + "PES-05.2": [ + "03.10.01E" + ], + "PES-06": [ + "03.10.01E" + ], + "PES-10": [ + "03.10.02E" + ], + "PRM-04": [ + "03.11.10E" + ], + "PRM-05": [ + "03.11.10E", + "03.13.01E", + "03.13.02E", + "03.13.03E" + ], + "PRM-06": [ + "03.13.01E" + ], + "RSK-11": [ + "03.12.03E" + ], + "SEA-01.4": [ + "03.15.01E" + ], + "SEA-01.5": [ + "03.15.01E" + ], + "SEA-02": [ + "03.15.01E" + ], + "SEA-03": [ + "03.15.02E" + ], + "SEA-03.1": [ + "03.13.16E" + ], + "SEA-08": [ + "03.14.15E" + ], + "SEA-08.1": [ + "03.14.04E" + ], + "SEA-08.2": [ + "03.14.05E" + ], + "SEA-10": [ + "03.14.14E" + ], + "SEA-11": [ + "03.13.08E" + ], + "SEA-13": [ + "03.13.01E" + ], + "SEA-13.1": [ + "03.13.07E" + ], + "SEA-14": [ + "03.13.03E" + ], + "SEA-14.1": [ + "03.13.02E" + ], + "SEA-14.2": [ + "03.13.05E" + ], + "OPS-01.1": [ + "03.02.01E", + "03.08.03E", + "03.09.03E", + "03.11.02E", + "03.12.01E", + "03.13.05E", + "03.13.07E", + "03.14.08E", + "03.14.15E", + "03.15.01E", + "03.17.02E" + ], + "OPS-04": [ + "03.06.01E" + ], + "SAT-01.1": [ + "03.02.01E" + ], + "SAT-02.1": [ + "03.02.02E" + ], + "SAT-03": [ + "03.02.01E", + "03.02.04E" + ], + "SAT-03.2": [ + "03.02.01E" + ], + "SAT-03.6": [ + "03.02.01E" + ], + "SAT-04.1": [ + "03.02.03E" + ], + "TDA-01": [ + "03.16.01E" + ], + "TDA-01.1": [ + "03.16.01E" + ], + "TDA-03.1": [ + "03.15.03E" + ], + "TDA-06.1": [ + "03.11.10E" + ], + "TDA-11": [ + "03.17.02E", + "03.17.03E", + "03.17.05E" + ], + "TDA-11.1": [ + "03.02.04E" + ], + "TDA-18": [ + "03.14.12E" + ], + "TDA-19": [ + "03.14.13E" + ], + "TPM-02": [ + "03.11.10E" + ], + "TPM-05": [ + "03.17.01E" + ], + "TPM-05.1": [ + "03.17.01E" + ], + "THR-01": [ + "03.11.01E" + ], + "THR-01.1": [ + "03.11.08E" + ], + "THR-01.2": [ + "03.11.03E" + ], + "THR-03": [ + "03.11.12E" + ], + "THR-07": [ + "03.11.02E" + ], + "THR-08": [ + "03.14.16E" + ], + "VPM-01.1": [ + "03.12.01E" + ], + "VPM-02": [ + "03.11.11E" + ], + "VPM-06.8": [ + "03.11.11E" + ], + "VPM-07": [ + "03.12.01E" + ] + } + }, + "framework_to_scf": { + "total_mappings": 103, + "mappings": { + "03.01.17E": [ + "GOV-02", + "DCH-01", + "DCH-01.2", + "DCH-01.4", + "DCH-02", + "NET-04.10", + "NET-17" + ], + "03.05.07E": [ + "GOV-02", + "IAC-01", + "IAC-01.4" + ], + "03.17.03E": [ + "GOV-02", + "HRS-03", + "IRO-02", + "TDA-11" + ], + "03.04.02E": [ + "AST-02.2", + "CFG-02.2", + "CFG-02.8", + "CFG-05.1", + "END-03.1" + ], + "03.01.14E": [ + "AST-02.8", + "AST-04", + "CFG-02", + "NET-04.7", + "NET-04.8" + ], + "03.04.03E": [ + "AST-02.9" + ], + "03.04.08E": [ + "AST-02.9" + ], + "03.17.04E": [ + "AST-03.2" + ], + "03.06.03E": [ + "AST-04.1", + "MON-16" + ], + "03.17.02E": [ + "AST-08", + "AST-15.1", + "IAO-03", + "OPS-01.1", + "TDA-11" + ], + "03.17.05E": [ + "AST-08", + "AST-15", + "TDA-11" + ], + "03.04.04E": [ + "BCD-01", + "CFG-02.2" + ], + "03.08.04E": [ + "BCD-01", + "BCD-01.4", + "BCD-12" + ], + "03.11.10E": [ + "BCD-02", + "PRM-04", + "PRM-05", + "TDA-06.1", + "TPM-02" + ], + "03.08.03E": [ + "BCD-11.1", + "OPS-01.1" + ], + "03.08.02E": [ + "BCD-11.8", + "DCH-09.5" + ], + "03.13.12E": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "03.04.07E": [ + "CHG-02.2", + "CHG-06" + ], + "03.04.05E": [ + "CHG-04.3" + ], + "03.12.03E": [ + "CPL-02", + "RSK-11" + ], + "03.01.04E": [ + "CFG-02", + "IAC-23", + "IAO-03" + ], + "03.01.16E": [ + "CFG-02", + "NET-04.9" + ], + "03.05.01E": [ + "CFG-02", + "IAC-04" + ], + "03.05.05E": [ + "CFG-02", + "IAC-10.10" + ], + "03.12.04E": [ + "CFG-02", + "NET-05", + "NET-05.2" + ], + "03.13.06E": [ + "CFG-02", + "CFG-03.3", + "END-10" + ], + "03.13.11E": [ + "CFG-02", + "END-11", + "IAO-03" + ], + "03.13.13E": [ + "CFG-02", + "END-12" + ], + "03.14.11E": [ + "CFG-02", + "CFG-06.1", + "END-06.2", + "END-06.8" + ], + "03.04.06E": [ + "CFG-02.3", + "DCH-18" + ], + "03.14.17E": [ + "MON-01.4", + "MON-01.12", + "MON-11.3", + "HRS-03", + "IRO-03" + ], + "03.14.19E": [ + "MON-01.5" + ], + "03.14.01E": [ + "MON-01.7", + "MON-01.8", + "END-06" + ], + "03.01.08E": [ + "MON-01.8", + "MON-11.3", + "MON-16", + "HRS-03", + "IRO-03" + ], + "03.11.09E": [ + "MON-01.8", + "MON-11.3", + "IRO-01", + "IRO-03" + ], + "03.14.18E": [ + "MON-01.12", + "MON-11.3", + "HRS-03" + ], + "03.03.04E": [ + "MON-02.3" + ], + "03.03.02E": [ + "MON-05", + "MON-05.1" + ], + "03.03.01E": [ + "MON-08.1" + ], + "03.03.03E": [ + "MON-08.4" + ], + "03.11.02E": [ + "MON-11.3", + "IRO-03", + "OPS-01.1", + "THR-07" + ], + "03.14.09E": [ + "CRY-01" + ], + "03.08.01E": [ + "DCH-09", + "DCH-09.5" + ], + "03.01.02E": [ + "DCH-13.4" + ], + "03.10.01E": [ + "DCH-18", + "PES-05", + "PES-05.1", + "PES-05.2", + "PES-06" + ], + "03.14.08E": [ + "END-06.1", + "IAO-03", + "OPS-01.1" + ], + "03.14.10E": [ + "END-06.6", + "IAO-03" + ], + "03.09.03E": [ + "HRS-01", + "HRS-06", + "OPS-01.1" + ], + "03.09.04E": [ + "HRS-01", + "HRS-04.3" + ], + "03.01.11E": [ + "HRS-03", + "IAC-08", + "IAC-15.1" + ], + "03.01.01E": [ + "HRS-12.1", + "IAC-20.5" + ], + "03.05.03E": [ + "IAC-04", + "IAC-04.1" + ], + "03.05.02E": [ + "IAC-10.1", + "IAC-10.4", + "IAC-10.5", + "IAC-10.11" + ], + "03.05.04E": [ + "IAC-10.6" + ], + "03.01.07E": [ + "IAC-15.1", + "IAC-15.4" + ], + "03.05.06E": [ + "IAC-28" + ], + "03.01.09E": [ + "IAC-29" + ], + "03.02.01E": [ + "IRO-03", + "OPS-01.1", + "SAT-01.1", + "SAT-03", + "SAT-03.2", + "SAT-03.6" + ], + "03.06.02E": [ + "IRO-07" + ], + "03.06.04E": [ + "IRO-09.1" + ], + "03.13.14E": [ + "IRO-15", + "IAO-03" + ], + "03.12.02E": [ + "IAO-02.1" + ], + "03.01.06E": [ + "IAO-03", + "NET-14" + ], + "03.13.16E": [ + "IAO-03", + "SEA-03.1" + ], + "03.14.14E": [ + "IAO-03", + "SEA-10" + ], + "03.14.15E": [ + "IAO-03", + "SEA-08", + "OPS-01.1" + ], + "03.14.16E": [ + "IAO-03", + "THR-08" + ], + "03.15.01E": [ + "IAO-03", + "SEA-01.4", + "SEA-01.5", + "SEA-02", + "OPS-01.1" + ], + "03.15.02E": [ + "IAO-03", + "SEA-03" + ], + "03.15.03E": [ + "IAO-03", + "TDA-03.1" + ], + "03.16.01E": [ + "IAO-03", + "TDA-01", + "TDA-01.1" + ], + "03.07.01E": [ + "MNT-04" + ], + "03.01.12E": [ + "NET-03", + "NET-06" + ], + "03.13.04E": [ + "NET-03", + "NET-03.7" + ], + "03.13.10E": [ + "NET-03.8" + ], + "03.13.15E": [ + "NET-03.8", + "NET-06.1", + "NET-06.9" + ], + "03.01.10E": [ + "NET-04.2", + "NET-04.7" + ], + "03.01.13E": [ + "NET-04.5", + "NET-04.7", + "NET-04.8" + ], + "03.01.15E": [ + "NET-04.8" + ], + "03.13.09E": [ + "NET-06.1", + "NET-06.9" + ], + "03.01.05E": [ + "NET-14.1" + ], + "03.10.02E": [ + "PES-05", + "PES-10" + ], + "03.13.01E": [ + "PRM-05", + "PRM-06", + "SEA-13" + ], + "03.13.02E": [ + "PRM-05", + "SEA-14.1" + ], + "03.13.03E": [ + "PRM-05", + "SEA-14" + ], + "03.14.04E": [ + "SEA-08.1" + ], + "03.14.05E": [ + "SEA-08.2" + ], + "03.13.08E": [ + "SEA-11" + ], + "03.13.07E": [ + "SEA-13.1", + "OPS-01.1" + ], + "03.13.05E": [ + "SEA-14.2", + "OPS-01.1" + ], + "03.12.01E": [ + "OPS-01.1", + "VPM-01.1", + "VPM-07" + ], + "03.06.01E": [ + "OPS-04" + ], + "03.02.02E": [ + "SAT-02.1" + ], + "03.02.04E": [ + "SAT-03", + "TDA-11.1" + ], + "03.02.03E": [ + "SAT-04.1" + ], + "03.14.12E": [ + "TDA-18" + ], + "03.14.13E": [ + "TDA-19" + ], + "03.17.01E": [ + "TPM-05", + "TPM-05.1" + ], + "03.11.01E": [ + "THR-01" + ], + "03.11.08E": [ + "THR-01.1" + ], + "03.11.03E": [ + "THR-01.2" + ], + "03.11.12E": [ + "THR-03" + ], + "03.11.11E": [ + "VPM-02", + "VPM-06.8" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/general-nist-800-172.json b/docs/api/crosswalks/general-nist-800-172.json deleted file mode 100644 index e646f718..00000000 --- a/docs/api/crosswalks/general-nist-800-172.json +++ /dev/null @@ -1,400 +0,0 @@ -{ - "framework_id": "general-nist-800-172", - "display_name": "NIST SP 800-172", - "scf_to_framework": { - "total_mappings": 74, - "mappings": { - "AST-02": [ - "3.1.2e" - ], - "AST-02.5": [ - "3.5.3e" - ], - "AST-02.8": [ - "3.1.3e" - ], - "AST-02.9": [ - "3.4.1e", - "3.4.3e" - ], - "AST-04": [ - "3.1.3e" - ], - "AST-04.1": [ - "3.14.3e" - ], - "AST-18": [ - "3.14.1e" - ], - "BCD-02.4": [ - "3.14.5e" - ], - "CHG-01": [ - "3.13.2e" - ], - "CPL-01.2": [ - "3.11.5e", - "3.14.3e" - ], - "CPL-03": [ - "3.11.5e" - ], - "CFG-02.2": [ - "3.4.2e" - ], - "CFG-02.7": [ - "3.5.2e" - ], - "CFG-02.8": [ - "3.4.2e" - ], - "CFG-06": [ - "3.4.2e" - ], - "CFG-06.1": [ - "3.4.2e", - "3.14.7e" - ], - "MON-01": [ - "3.14.2e" - ], - "MON-01.1": [ - "3.14.6e" - ], - "MON-11.3": [ - "3.11.2e" - ], - "MON-16": [ - "3.14.2e" - ], - "CRY-13": [ - "3.14.1e" - ], - "DCH-01.2": [ - "3.14.5e" - ], - "DCH-06.2": [ - "3.1.2e" - ], - "HRS-02": [ - "3.9.1e" - ], - "HRS-02.1": [ - "3.9.2e" - ], - "HRS-03": [ - "3.9.1e" - ], - "HRS-04": [ - "3.9.1e" - ], - "HRS-04.1": [ - "3.9.1e" - ], - "HRS-07": [ - "3.9.2e" - ], - "HRS-07.1": [ - "3.9.2e" - ], - "HRS-07.3": [ - "3.9.2e" - ], - "IAC-01.2": [ - "3.5.2e" - ], - "IAC-02.2": [ - "3.5.1e" - ], - "IAC-04": [ - "3.5.1e" - ], - "IAC-08": [ - "3.1.2e" - ], - "IAC-10.11": [ - "3.5.2e" - ], - "IAC-20.5": [ - "3.1.1e" - ], - "IRO-07": [ - "3.6.2e" - ], - "IAO-03": [ - "3.11.4e" - ], - "NET-02": [ - "3.13.4e" - ], - "NET-02.3": [ - "3.1.3e" - ], - "NET-03.7": [ - "3.13.4e" - ], - "NET-04": [ - "3.1.3e" - ], - "NET-06": [ - "3.14.3e" - ], - "NET-06.4": [ - "3.14.3e" - ], - "PES-03": [ - "3.1.2e" - ], - "PES-04.1": [ - "3.13.4e" - ], - "PES-12": [ - "3.13.4e" - ], - "PES-18": [ - "3.13.4e" - ], - "RSK-03.1": [ - "3.11.5e" - ], - "RSK-04": [ - "3.11.1e", - "3.11.5e" - ], - "RSK-04.2": [ - "3.11.1e" - ], - "RSK-06": [ - "3.11.7e" - ], - "RSK-06.1": [ - "3.11.6e" - ], - "RSK-09": [ - "3.11.6e", - "3.11.7e" - ], - "RSK-09.1": [ - "3.11.6e" - ], - "SEA-08.1": [ - "3.14.4e" - ], - "SEA-13": [ - "3.13.1e" - ], - "SEA-14": [ - "3.13.3e" - ], - "SEA-15": [ - "3.13.5e" - ], - "OPS-04": [ - "3.6.1e" - ], - "OPS-06": [ - "3.11.3e" - ], - "SAT-02.2": [ - "3.2.1e" - ], - "SAT-03": [ - "3.2.1e" - ], - "SAT-03.1": [ - "3.2.2e" - ], - "SAT-03.2": [ - "3.2.1e" - ], - "SAT-03.6": [ - "3.2.1e", - "3.2.2e" - ], - "TDA-01.2": [ - "3.14.1e", - "3.14.7e" - ], - "TDA-14.1": [ - "3.14.7e" - ], - "TDA-14.2": [ - "3.14.7e" - ], - "THR-03": [ - "3.11.1e", - "3.14.6e" - ], - "THR-07": [ - "3.11.1e", - "3.11.2e", - "3.14.6e" - ], - "THR-09": [ - "3.11.5e" - ], - "VPM-07": [ - "3.12.1e" - ] - } - }, - "framework_to_scf": { - "total_mappings": 35, - "mappings": { - "3.1.2e": [ - "AST-02", - "DCH-06.2", - "IAC-08", - "PES-03" - ], - "3.5.3e": [ - "AST-02.5" - ], - "3.1.3e": [ - "AST-02.8", - "AST-04", - "NET-02.3", - "NET-04" - ], - "3.4.1e": [ - "AST-02.9" - ], - "3.4.3e": [ - "AST-02.9" - ], - "3.14.3e": [ - "AST-04.1", - "CPL-01.2", - "NET-06", - "NET-06.4" - ], - "3.14.1e": [ - "AST-18", - "CRY-13", - "TDA-01.2" - ], - "3.14.5e": [ - "BCD-02.4", - "DCH-01.2" - ], - "3.13.2e": [ - "CHG-01" - ], - "3.11.5e": [ - "CPL-01.2", - "CPL-03", - "RSK-03.1", - "RSK-04", - "THR-09" - ], - "3.4.2e": [ - "CFG-02.2", - "CFG-02.8", - "CFG-06", - "CFG-06.1" - ], - "3.5.2e": [ - "CFG-02.7", - "IAC-01.2", - "IAC-10.11" - ], - "3.14.7e": [ - "CFG-06.1", - "TDA-01.2", - "TDA-14.1", - "TDA-14.2" - ], - "3.14.2e": [ - "MON-01", - "MON-16" - ], - "3.14.6e": [ - "MON-01.1", - "THR-03", - "THR-07" - ], - "3.11.2e": [ - "MON-11.3", - "THR-07" - ], - "3.9.1e": [ - "HRS-02", - "HRS-03", - "HRS-04", - "HRS-04.1" - ], - "3.9.2e": [ - "HRS-02.1", - "HRS-07", - "HRS-07.1", - "HRS-07.3" - ], - "3.5.1e": [ - "IAC-02.2", - "IAC-04" - ], - "3.1.1e": [ - "IAC-20.5" - ], - "3.6.2e": [ - "IRO-07" - ], - "3.11.4e": [ - "IAO-03" - ], - "3.13.4e": [ - "NET-02", - "NET-03.7", - "PES-04.1", - "PES-12", - "PES-18" - ], - "3.11.1e": [ - "RSK-04", - "RSK-04.2", - "THR-03", - "THR-07" - ], - "3.11.7e": [ - "RSK-06", - "RSK-09" - ], - "3.11.6e": [ - "RSK-06.1", - "RSK-09", - "RSK-09.1" - ], - "3.14.4e": [ - "SEA-08.1" - ], - "3.13.1e": [ - "SEA-13" - ], - "3.13.3e": [ - "SEA-14" - ], - "3.13.5e": [ - "SEA-15" - ], - "3.6.1e": [ - "OPS-04" - ], - "3.11.3e": [ - "OPS-06" - ], - "3.2.1e": [ - "SAT-02.2", - "SAT-03", - "SAT-03.2", - "SAT-03.6" - ], - "3.2.2e": [ - "SAT-03.1", - "SAT-03.6" - ], - "3.12.1e": [ - "VPM-07" - ] - } - } -} \ No newline at end of file diff --git a/docs/api/crosswalks/general-nist-800-172a-r3.json b/docs/api/crosswalks/general-nist-800-172a-r3.json new file mode 100644 index 00000000..da8e8a05 --- /dev/null +++ b/docs/api/crosswalks/general-nist-800-172a-r3.json @@ -0,0 +1,1896 @@ +{ + "framework_id": "general-nist-800-172a-r3", + "display_name": "NIST SP 800 - 172A R3 - Assessing Enhanced Security Requirements for Controlled Unclassified Information", + "scf_to_framework": { + "total_mappings": 163, + "mappings": { + "GOV-02": [ + "A.03.01.17E.ODP[02]", + "A.03.05.07E.ODP[01]", + "DS-A.03.17.03E.a[01]", + "DS-A.03.17.03E.a[02]", + "DS-A.03.17.03E.a[03]", + "DS-A.03.17.03E.a[04]" + ], + "GOV-04.1": [ + "A.03.02.03E.ODP[01]" + ], + "AST-02.2": [ + "DS-A.03.04.02E.a", + "A.03.04.02E.ODP[01]" + ], + "AST-02.8": [ + "A.03.01.14E.ODP[02]" + ], + "AST-02.9": [ + "DS-A.03.04.03E[01]", + "A.03.04.03E.ODP[01]", + "DS-A.03.04.03E[02]", + "A.03.04.03E.ODP[02]", + "DS-A.03.04.03E[03]", + "A.03.04.03E.ODP[03]", + "DS-A.03.04.04E[01]", + "DS-A.03.04.04E[02]", + "DS-A.03.04.04E[03]", + "DS-A.03.04.08E" + ], + "AST-03.2": [ + "DS-A.03.17.04E[01]", + "A.03.17.04E.ODP[01]", + "DS-A.03.17.04E[02]", + "DS-A.03.17.04E[03]" + ], + "AST-04": [ + "A.03.01.14E.ODP[02]" + ], + "AST-04.1": [ + "A.03.06.03E.ODP[01]" + ], + "AST-08": [ + "A.03.17.02E.ODP[04]", + "A.03.17.05E.ODP[02]" + ], + "AST-15": [ + "A.03.17.05E.ODP[02]" + ], + "AST-15.1": [ + "DS-A.03.17.02E" + ], + "BCD-01": [ + "DS-A.03.04.03E[04]", + "A.03.04.03E.ODP[04]", + "DS-A.03.04.04E[04]", + "DS-A.03.08.04E[01]" + ], + "BCD-01.4": [ + "A.03.08.04E.ODP[01]", + "A.03.08.04E.ODP[02]" + ], + "BCD-02": [ + "DS-A.03.11.10E" + ], + "BCD-11.1": [ + "DS-A.03.08.03E[01]", + "DS-A.03.08.03E[02]" + ], + "BCD-11.8": [ + "DS-A.03.08.02E" + ], + "BCD-12": [ + "DS-A.03.08.04E[02]" + ], + "CAP-01": [ + "DS-A.03.13.12E.b" + ], + "CAP-02": [ + "DS-A.03.13.12E.b" + ], + "CAP-03": [ + "DS-A.03.13.12E.b" + ], + "CHG-02.2": [ + "DS-A.03.04.07E[01]", + "DS-A.03.04.07E[03]" + ], + "CHG-04.3": [ + "DS-A.03.04.05E[01]", + "A.03.04.05E.ODP[01]", + "DS-A.03.04.05E[02]", + "A.03.04.05E.ODP[02]" + ], + "CHG-06": [ + "DS-A.03.04.07E[02]" + ], + "CPL-02": [ + "DS-A.03.12.03E[02]", + "DS-A.03.12.03E[03]", + "DS-A.03.12.03E[04]" + ], + "CFG-02": [ + "A.03.01.04E.ODP[01]", + "A.03.01.14E.ODP[03]", + "A.03.01.14E.ODP[04]", + "DS-A.03.01.16E", + "A.03.05.01E.ODP[01]", + "DS-A.03.05.05E", + "DS-A.03.12.04E.c", + "A.03.13.06E.ODP[01]", + "DS-A.03.13.11E[02]", + "A.03.13.13E.ODP[01]", + "A.03.14.11E.ODP[01]" + ], + "CFG-02.2": [ + "A.03.04.02E.ODP[03]", + "DS-A.03.04.03E[01]", + "A.03.04.04E.ODP[01]" + ], + "CFG-02.3": [ + "DS-A.03.04.06E", + "A.03.04.06E.ODP[01]" + ], + "CFG-02.8": [ + "DS-A.03.04.02E.b", + "A.03.04.02E.ODP[02]" + ], + "CFG-03.3": [ + "A.03.13.06E.ODP[01]" + ], + "CFG-05.1": [ + "DS-A.03.04.02E.b" + ], + "CFG-06.1": [ + "DS-A.03.14.11E" + ], + "MON-01.4": [ + "DS-A.03.14.17E" + ], + "MON-01.5": [ + "DS-A.03.14.19E[01]", + "DS-A.03.14.19E[02]", + "DS-A.03.14.19E[03]" + ], + "MON-01.7": [ + "DS-A.03.14.01E.a[03]", + "A.03.14.01E.ODP[03]" + ], + "MON-01.8": [ + "DS-A.03.01.08E.b", + "DS-A.03.11.09E[03]", + "DS-A.03.14.01E.b[01]", + "A.03.14.01E.ODP[04]", + "DS-A.03.14.01E.b[02]", + "A.03.14.01E.ODP[05]", + "DS-A.03.14.01E.b[03]", + "A.03.14.01E.ODP[06]" + ], + "MON-01.12": [ + "DS-A.03.14.17E", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[02]" + ], + "MON-02.3": [ + "DS-A.03.03.04E", + "A.03.03.04E.ODP[01]", + "A.03.03.04E.ODP[02]" + ], + "MON-05": [ + "DS-A.03.03.02E", + "A.03.03.02E.ODP[03]", + "A.03.03.02E.ODP[02]" + ], + "MON-05.1": [ + "A.03.03.02E.ODP[01]" + ], + "MON-08.1": [ + "DS-A.03.03.01E" + ], + "MON-08.4": [ + "DS-A.03.03.03E", + "A.03.03.03E.ODP[01]", + "A.03.03.03E.ODP[02]" + ], + "MON-11.3": [ + "DS-A.03.01.08E.a", + "DS-A.03.11.02E.a.01[01]", + "DS-A.03.11.09E[01]", + "DS-A.03.11.09E[02]", + "DS-A.03.14.17E", + "A.03.14.18E.ODP[03]" + ], + "MON-16": [ + "DS-A.03.01.08E.a", + "DS-A.03.06.03E" + ], + "CRY-01": [ + "DS-A.03.14.09E[01]", + "DS-A.03.14.09E[02]", + "DS-A.03.14.09E[03]" + ], + "DCH-01": [ + "A.03.01.17E.ODP[02]" + ], + "DCH-01.2": [ + "A.03.01.17E.ODP[02]" + ], + "DCH-01.4": [ + "DS-A.03.01.17E.b", + "A.03.01.17E.ODP[02]" + ], + "DCH-02": [ + "A.03.01.17E.ODP[01]" + ], + "DCH-09": [ + "A.03.08.01E.ODP[01]" + ], + "DCH-09.5": [ + "DS-A.03.08.01E", + "A.03.08.02E.ODP[01]" + ], + "DCH-13.4": [ + "DS-A.03.01.02E", + "A.03.01.02E.ODP[01]" + ], + "DCH-18": [ + "DS-A.03.04.06E", + "A.03.10.01E.ODP[01]" + ], + "END-06": [ + "DS-A.03.14.01E.a[01]", + "A.03.14.01E.ODP[01]", + "DS-A.03.14.01E.a[02]", + "A.03.14.01E.ODP[02]" + ], + "END-06.1": [ + "DS-A.03.14.08E[01]", + "A.03.14.08E.ODP[02]", + "A.03.14.08E.ODP[04]", + "DS-A.03.14.08E[02]", + "A.03.14.08E.ODP[06]", + "DS-A.03.14.08E[03]", + "A.03.14.08E.ODP[10]" + ], + "END-06.2": [ + "DS-A.03.14.11E" + ], + "END-06.6": [ + "DS-A.03.14.10E", + "A.03.14.10E.ODP[01]" + ], + "END-06.8": [ + "DS-A.03.14.11E" + ], + "END-10": [ + "DS-A.03.13.06E" + ], + "END-11": [ + "DS-A.03.13.11E[01]" + ], + "END-12": [ + "DS-A.03.13.13E", + "A.03.13.13E.ODP[02]", + "A.03.13.13E.ODP[03]" + ], + "HRS-01": [ + "DS-A.03.09.03E.a", + "A.03.09.04E.ODP[01]" + ], + "HRS-03": [ + "A.03.01.08E.ODP[02]", + "A.03.01.11E.ODP[01]", + "A.03.14.17E.ODP[01]", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[01]", + "A.03.17.03E.ODP[03]" + ], + "HRS-04.3": [ + "DS-A.03.09.04E" + ], + "HRS-06": [ + "DS-A.03.09.03E.c.01" + ], + "HRS-12.1": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" + ], + "IAC-01": [ + "A.03.05.07E.ODP[01]" + ], + "IAC-01.4": [ + "DS-A.03.05.07E[01]", + "A.03.05.07E.ODP[02]", + "DS-A.03.05.07E[02]", + "DS-A.03.05.07E[03]" + ], + "IAC-04": [ + "DS-A.03.05.01E", + "DS-A.03.05.03E" + ], + "IAC-04.1": [ + "A.03.05.03E.ODP[01]" + ], + "IAC-08": [ + "DS-A.03.01.11E.a", + "DS-A.03.01.11E.b" + ], + "IAC-10.1": [ + "A.03.05.02E.ODP[02]" + ], + "IAC-10.4": [ + "A.03.05.02E.ODP[01]" + ], + "IAC-10.5": [ + "DS-A.03.05.02E.b" + ], + "IAC-10.6": [ + "DS-A.03.05.04E" + ], + "IAC-10.10": [ + "A.03.05.05E.ODP[01]" + ], + "IAC-10.11": [ + "DS-A.03.05.02E.a" + ], + "IAC-15.1": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]", + "DS-A.03.01.11E.a" + ], + "IAC-15.4": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]" + ], + "IAC-20.5": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" + ], + "IAC-23": [ + "DS-A.03.01.04E", + "A.03.01.04E.ODP[01]", + "A.03.01.04E.ODP[02]" + ], + "IAC-28": [ + "DS-A.03.05.06E.a", + "DS-A.03.05.06E.b", + "DS-A.03.05.06E.c[01]", + "DS-A.03.05.06E.c[02]", + "DS-A.03.05.06E.c[03]" + ], + "IAC-29": [ + "DS-A.03.01.09E.a[01]", + "DS-A.03.01.09E.a[02]", + "DS-A.03.01.09E.b", + "A.03.01.09E.ODP[01]" + ], + "IRO-01": [ + "A.03.11.09E.ODP[02]" + ], + "IRO-02": [ + "A.03.17.03E.ODP[02]" + ], + "IRO-03": [ + "A.03.01.08E.ODP[01]", + "A.03.02.01E.ODP[01]", + "DS-A.03.11.02E.a.01[01]", + "A.03.11.09E.ODP[01]", + "A.03.14.17E.ODP[02]" + ], + "IRO-07": [ + "DS-A.03.06.02E[01]", + "A.03.06.02E.ODP[01]", + "DS-A.03.06.02E[02]", + "DS-A.03.06.02E[03]" + ], + "IRO-09.1": [ + "DS-A.03.06.04E[01]", + "A.03.06.04E.ODP[01]", + "DS-A.03.06.04E[02]", + "A.03.06.04E.ODP[02]", + "DS-A.03.06.04E[03]", + "A.03.06.04E.ODP[03]" + ], + "IRO-15": [ + "DS-A.03.13.14E" + ], + "IAO-02.1": [ + "DS-A.03.12.02E" + ], + "IAO-03": [ + "A.03.01.04E.ODP[02]", + "DS-A.03.01.06E", + "A.03.13.11E.ODP[01]", + "A.03.13.14E.ODP[01]", + "A.03.13.16E.ODP[03]", + "A.03.14.08E.ODP[01]", + "A.03.14.08E.ODP[03]", + "A.03.14.08E.ODP[05]", + "A.03.14.08E.ODP[07]", + "A.03.14.08E.ODP[11]", + "A.03.14.10E.ODP[02]", + "A.03.14.14E.ODP[01]", + "A.03.14.15E.ODP[01]", + "A.03.14.16E.ODP[01]", + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.03", + "DS-A.03.15.01E.b", + "DS-A.03.15.01E.c", + "DS-A.03.15.02E.b", + "A.03.15.02E.ODP[01]", + "A.03.15.03E.ODP[01]", + "A.03.15.03E.ODP[02]", + "A.03.16.01E.ODP[02]", + "A.03.17.02E.ODP[01]" + ], + "MNT-04": [ + "DS-A.03.07.01E" + ], + "NET-02.1": [ + "DS-A.03.13.12E.a", + "A.03.13.12E.ODP[01]", + "A.03.13.12E.ODP[02]", + "DS-A.03.13.12E.b", + "A.03.13.12E.ODP[03]" + ], + "NET-03": [ + "A.03.01.12E.ODP[01]", + "DS-A.03.13.04E" + ], + "NET-03.7": [ + "A.03.13.04E.ODP[01]" + ], + "NET-03.8": [ + "DS-A.03.13.10E", + "DS-A.03.13.15E" + ], + "NET-04.2": [ + "DS-A.03.01.10E", + "A.03.01.10E.ODP[01]", + "A.03.01.10E.ODP[02]", + "A.03.01.10E.ODP[03]", + "A.03.01.10E.ODP[04]" + ], + "NET-04.5": [ + "A.03.01.13E.ODP[01]" + ], + "NET-04.7": [ + "A.03.01.10E.ODP[05]", + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "A.03.01.14E.ODP[01]", + "DS-A.03.01.14E.b" + ], + "NET-04.8": [ + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "DS-A.03.01.15E", + "A.03.01.15E.ODP[01]" + ], + "NET-04.9": [ + "A.03.01.16E.ODP[01]" + ], + "NET-04.10": [ + "DS-A.03.01.17E.a" + ], + "NET-05": [ + "DS-A.03.12.04E.a", + "A.03.12.04E.ODP[01]", + "DS-A.03.12.04E.b[01]", + "DS-A.03.12.04E.b[02]", + "DS-A.03.12.04E.b[03]", + "A.03.12.04E.ODP[02]", + "DS-A.03.12.04E.d" + ], + "NET-05.2": [ + "DS-A.03.12.04E.c" + ], + "NET-06": [ + "DS-A.03.01.12E", + "A.03.01.12E.ODP[01]" + ], + "NET-06.1": [ + "DS-A.03.13.09E", + "DS-A.03.13.15E" + ], + "NET-06.9": [ + "A.03.13.09E.ODP[01]", + "DS-A.03.13.15E", + "A.03.13.15E.ODP[01]", + "A.03.13.15E.ODP[02]" + ], + "NET-14": [ + "DS-A.03.01.06E" + ], + "NET-14.1": [ + "DS-A.03.01.05E[01]", + "DS-A.03.01.05E[02]" + ], + "NET-17": [ + "DS-A.03.01.17E.a" + ], + "PES-05": [ + "DS-A.03.10.01E[02]", + "DS-A.03.10.02E.b" + ], + "PES-05.1": [ + "DS-A.03.10.01E[02]" + ], + "PES-05.2": [ + "DS-A.03.10.01E[01]" + ], + "PES-06": [ + "A.03.10.01E.ODP[01]" + ], + "PES-10": [ + "DS-A.03.10.02E.a[01]", + "A.03.10.02E.ODP[01]", + "DS-A.03.10.02E.a[02]", + "DS-A.03.10.02E.a[03]", + "A.03.10.02E.ODP[02]", + "DS-A.03.10.02E.a[04]" + ], + "PRM-04": [ + "A.03.11.10E.ODP[02]" + ], + "PRM-05": [ + "DS-A.03.11.10E", + "A.03.13.01E.ODP[01]", + "A.03.13.02E.ODP[01]", + "A.03.13.03E.ODP[01]" + ], + "PRM-06": [ + "A.03.13.01E.ODP[01]" + ], + "RSK-11": [ + "DS-A.03.12.03E[01]" + ], + "SEA-01.4": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "SEA-01.5": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "SEA-02": [ + "DS-A.03.15.01E.a.02" + ], + "SEA-03": [ + "DS-A.03.15.02E.a", + "A.03.15.02E.ODP[02]", + "DS-A.03.15.02E.c" + ], + "SEA-03.1": [ + "DS-A.03.13.16E", + "A.03.13.16E.ODP[01]", + "A.03.13.16E.ODP[02]" + ], + "SEA-08": [ + "DS-A.03.14.15E.a", + "DS-A.03.14.15E.b", + "DS-A.03.14.15E.c", + "A.03.14.15E.ODP[02]" + ], + "SEA-08.1": [ + "DS-A.03.14.04E", + "A.03.14.04E.ODP[01]" + ], + "SEA-08.2": [ + "DS-A.03.14.05E.a", + "A.03.14.05E.ODP[01]", + "DS-A.03.14.05E.b" + ], + "SEA-10": [ + "DS-A.03.14.14E" + ], + "SEA-11": [ + "DS-A.03.13.08E[01]", + "DS-A.03.13.08E[02]", + "DS-A.03.13.08E[03]" + ], + "SEA-13": [ + "DS-A.03.13.01E" + ], + "SEA-13.1": [ + "DS-A.03.13.07E" + ], + "SEA-14": [ + "DS-A.03.13.03E" + ], + "SEA-14.1": [ + "DS-A.03.13.02E" + ], + "SEA-14.2": [ + "DS-A.03.13.05E", + "A.03.13.05E.ODP[01]" + ], + "OPS-01.1": [ + "A.03.02.01E.ODP[02]", + "A.03.08.03E.ODP[01]", + "A.03.08.03E.ODP[02]", + "DS-A.03.09.03E.b[01]", + "A.03.09.03E.ODP[01]", + "DS-A.03.09.03E.b[02]", + "DS-A.03.09.03E.c.02", + "A.03.09.03E.ODP[02]", + "A.03.11.02E.ODP[01]", + "A.03.12.01E.ODP[01]", + "A.03.12.04E.ODP[03]", + "A.03.13.05E.ODP[02]", + "A.03.13.05E.ODP[03]", + "A.03.13.07E.ODP[01]", + "A.03.14.05E.ODP[02]", + "A.03.14.05E.ODP[03]", + "A.03.14.05E.ODP[04]", + "A.03.14.08E.ODP[08]", + "A.03.14.08E.ODP[09]", + "A.03.14.08E.ODP[12]", + "A.03.14.15E.ODP[03]", + "A.03.15.01E.ODP[01]", + "A.03.17.02E.ODP[02]", + "A.03.17.02E.ODP[03]" + ], + "OPS-04": [ + "DS-A.03.06.01E[01]", + "DS-A.03.06.01E[02]" + ], + "SAT-01.1": [ + "DS-A.03.02.01E.b[01]", + "DS-A.03.02.01E.b[02]", + "A.03.02.01E.ODP[03]" + ], + "SAT-02.1": [ + "DS-A.03.02.02E" + ], + "SAT-03": [ + "DS-A.03.02.01E.a.02", + "A.03.02.04E.ODP[01]" + ], + "SAT-03.2": [ + "DS-A.03.02.01E.a.02" + ], + "SAT-03.6": [ + "DS-A.03.02.01E.a.01", + "DS-A.03.02.01E.a.03" + ], + "SAT-04.1": [ + "DS-A.03.02.03E" + ], + "TDA-01": [ + "DS-A.03.16.01E" + ], + "TDA-01.1": [ + "DS-A.03.16.01E", + "A.03.16.01E.ODP[01]" + ], + "TDA-03.1": [ + "DS-A.03.15.03E" + ], + "TDA-06.1": [ + "A.03.11.10E.ODP[01]" + ], + "TDA-11": [ + "A.03.17.02E.ODP[04]", + "DS-A.03.17.03E.b", + "A.03.17.03E.ODP[01]", + "DS-A.03.17.05E[01]", + "A.03.17.05E.ODP[01]", + "DS-A.03.17.05E[02]" + ], + "TDA-11.1": [ + "DS-A.03.02.04E" + ], + "TDA-18": [ + "DS-A.03.14.12E", + "A.03.14.12E.ODP[01]" + ], + "TDA-19": [ + "DS-A.03.14.13E.a", + "DS-A.03.14.13E.b" + ], + "TDA-19.1": [ + "A.03.14.13E.ODP[01]" + ], + "TPM-02": [ + "A.03.11.10E.ODP[01]" + ], + "TPM-05": [ + "A.03.17.01E.ODP[02]" + ], + "TPM-05.1": [ + "DS-A.03.17.01E", + "A.03.17.01E.ODP[01]" + ], + "THR-01": [ + "DS-A.03.11.01E" + ], + "THR-01.1": [ + "DS-A.03.11.08E", + "A.03.11.08E.ODP[01]" + ], + "THR-01.2": [ + "DS-A.03.11.03E[01]", + "A.03.11.03E.ODP[01]", + "A.03.11.03E.ODP[02]", + "DS-A.03.11.03E[02]", + "A.03.11.03E.ODP[03]" + ], + "THR-03": [ + "DS-A.03.11.12E" + ], + "THR-07": [ + "DS-A.03.11.02E.a.01[02]", + "DS-A.03.11.02E.a.02[01]", + "DS-A.03.11.02E.a.02[02]", + "DS-A.03.11.02E.b" + ], + "THR-08": [ + "DS-A.03.14.16E" + ], + "VPM-01.1": [ + "A.03.12.01E.ODP[02]" + ], + "VPM-02": [ + "A.03.11.11E.ODP[01]", + "DS-A.03.11.11E[02]" + ], + "VPM-06.8": [ + "DS-A.03.11.11E[01]" + ], + "VPM-07": [ + "DS-A.03.12.01E" + ] + } + }, + "framework_to_scf": { + "total_mappings": 364, + "mappings": { + "A.03.01.17E.ODP[02]": [ + "GOV-02", + "DCH-01", + "DCH-01.2", + "DCH-01.4" + ], + "A.03.05.07E.ODP[01]": [ + "GOV-02", + "IAC-01" + ], + "DS-A.03.17.03E.a[01]": [ + "GOV-02" + ], + "DS-A.03.17.03E.a[02]": [ + "GOV-02" + ], + "DS-A.03.17.03E.a[03]": [ + "GOV-02" + ], + "DS-A.03.17.03E.a[04]": [ + "GOV-02" + ], + "A.03.02.03E.ODP[01]": [ + "GOV-04.1" + ], + "DS-A.03.04.02E.a": [ + "AST-02.2" + ], + "A.03.04.02E.ODP[01]": [ + "AST-02.2" + ], + "A.03.01.14E.ODP[02]": [ + "AST-02.8", + "AST-04" + ], + "DS-A.03.04.03E[01]": [ + "AST-02.9", + "CFG-02.2" + ], + "A.03.04.03E.ODP[01]": [ + "AST-02.9" + ], + "DS-A.03.04.03E[02]": [ + "AST-02.9" + ], + "A.03.04.03E.ODP[02]": [ + "AST-02.9" + ], + "DS-A.03.04.03E[03]": [ + "AST-02.9" + ], + "A.03.04.03E.ODP[03]": [ + "AST-02.9" + ], + "DS-A.03.04.04E[01]": [ + "AST-02.9" + ], + "DS-A.03.04.04E[02]": [ + "AST-02.9" + ], + "DS-A.03.04.04E[03]": [ + "AST-02.9" + ], + "DS-A.03.04.08E": [ + "AST-02.9" + ], + "DS-A.03.17.04E[01]": [ + "AST-03.2" + ], + "A.03.17.04E.ODP[01]": [ + "AST-03.2" + ], + "DS-A.03.17.04E[02]": [ + "AST-03.2" + ], + "DS-A.03.17.04E[03]": [ + "AST-03.2" + ], + "A.03.06.03E.ODP[01]": [ + "AST-04.1" + ], + "A.03.17.02E.ODP[04]": [ + "AST-08", + "TDA-11" + ], + "A.03.17.05E.ODP[02]": [ + "AST-08", + "AST-15" + ], + "DS-A.03.17.02E": [ + "AST-15.1" + ], + "DS-A.03.04.03E[04]": [ + "BCD-01" + ], + "A.03.04.03E.ODP[04]": [ + "BCD-01" + ], + "DS-A.03.04.04E[04]": [ + "BCD-01" + ], + "DS-A.03.08.04E[01]": [ + "BCD-01" + ], + "A.03.08.04E.ODP[01]": [ + "BCD-01.4" + ], + "A.03.08.04E.ODP[02]": [ + "BCD-01.4" + ], + "DS-A.03.11.10E": [ + "BCD-02", + "PRM-05" + ], + "DS-A.03.08.03E[01]": [ + "BCD-11.1" + ], + "DS-A.03.08.03E[02]": [ + "BCD-11.1" + ], + "DS-A.03.08.02E": [ + "BCD-11.8" + ], + "DS-A.03.08.04E[02]": [ + "BCD-12" + ], + "DS-A.03.13.12E.b": [ + "CAP-01", + "CAP-02", + "CAP-03", + "NET-02.1" + ], + "DS-A.03.04.07E[01]": [ + "CHG-02.2" + ], + "DS-A.03.04.07E[03]": [ + "CHG-02.2" + ], + "DS-A.03.04.05E[01]": [ + "CHG-04.3" + ], + "A.03.04.05E.ODP[01]": [ + "CHG-04.3" + ], + "DS-A.03.04.05E[02]": [ + "CHG-04.3" + ], + "A.03.04.05E.ODP[02]": [ + "CHG-04.3" + ], + "DS-A.03.04.07E[02]": [ + "CHG-06" + ], + "DS-A.03.12.03E[02]": [ + "CPL-02" + ], + "DS-A.03.12.03E[03]": [ + "CPL-02" + ], + "DS-A.03.12.03E[04]": [ + "CPL-02" + ], + "A.03.01.04E.ODP[01]": [ + "CFG-02", + "IAC-23" + ], + "A.03.01.14E.ODP[03]": [ + "CFG-02" + ], + "A.03.01.14E.ODP[04]": [ + "CFG-02" + ], + "DS-A.03.01.16E": [ + "CFG-02" + ], + "A.03.05.01E.ODP[01]": [ + "CFG-02" + ], + "DS-A.03.05.05E": [ + "CFG-02" + ], + "DS-A.03.12.04E.c": [ + "CFG-02", + "NET-05.2" + ], + "A.03.13.06E.ODP[01]": [ + "CFG-02", + "CFG-03.3" + ], + "DS-A.03.13.11E[02]": [ + "CFG-02" + ], + "A.03.13.13E.ODP[01]": [ + "CFG-02" + ], + "A.03.14.11E.ODP[01]": [ + "CFG-02" + ], + "A.03.04.02E.ODP[03]": [ + "CFG-02.2" + ], + "A.03.04.04E.ODP[01]": [ + "CFG-02.2" + ], + "DS-A.03.04.06E": [ + "CFG-02.3", + "DCH-18" + ], + "A.03.04.06E.ODP[01]": [ + "CFG-02.3" + ], + "DS-A.03.04.02E.b": [ + "CFG-02.8", + "CFG-05.1" + ], + "A.03.04.02E.ODP[02]": [ + "CFG-02.8" + ], + "DS-A.03.14.11E": [ + "CFG-06.1", + "END-06.2", + "END-06.8" + ], + "DS-A.03.14.17E": [ + "MON-01.4", + "MON-01.12", + "MON-11.3" + ], + "DS-A.03.14.19E[01]": [ + "MON-01.5" + ], + "DS-A.03.14.19E[02]": [ + "MON-01.5" + ], + "DS-A.03.14.19E[03]": [ + "MON-01.5" + ], + "DS-A.03.14.01E.a[03]": [ + "MON-01.7" + ], + "A.03.14.01E.ODP[03]": [ + "MON-01.7" + ], + "DS-A.03.01.08E.b": [ + "MON-01.8" + ], + "DS-A.03.11.09E[03]": [ + "MON-01.8" + ], + "DS-A.03.14.01E.b[01]": [ + "MON-01.8" + ], + "A.03.14.01E.ODP[04]": [ + "MON-01.8" + ], + "DS-A.03.14.01E.b[02]": [ + "MON-01.8" + ], + "A.03.14.01E.ODP[05]": [ + "MON-01.8" + ], + "DS-A.03.14.01E.b[03]": [ + "MON-01.8" + ], + "A.03.14.01E.ODP[06]": [ + "MON-01.8" + ], + "DS-A.03.14.18E": [ + "MON-01.12", + "HRS-03" + ], + "A.03.14.18E.ODP[02]": [ + "MON-01.12" + ], + "DS-A.03.03.04E": [ + "MON-02.3" + ], + "A.03.03.04E.ODP[01]": [ + "MON-02.3" + ], + "A.03.03.04E.ODP[02]": [ + "MON-02.3" + ], + "DS-A.03.03.02E": [ + "MON-05" + ], + "A.03.03.02E.ODP[03]": [ + "MON-05" + ], + "A.03.03.02E.ODP[02]": [ + "MON-05" + ], + "A.03.03.02E.ODP[01]": [ + "MON-05.1" + ], + "DS-A.03.03.01E": [ + "MON-08.1" + ], + "DS-A.03.03.03E": [ + "MON-08.4" + ], + "A.03.03.03E.ODP[01]": [ + "MON-08.4" + ], + "A.03.03.03E.ODP[02]": [ + "MON-08.4" + ], + "DS-A.03.01.08E.a": [ + "MON-11.3", + "MON-16" + ], + "DS-A.03.11.02E.a.01[01]": [ + "MON-11.3", + "IRO-03" + ], + "DS-A.03.11.09E[01]": [ + "MON-11.3" + ], + "DS-A.03.11.09E[02]": [ + "MON-11.3" + ], + "A.03.14.18E.ODP[03]": [ + "MON-11.3" + ], + "DS-A.03.06.03E": [ + "MON-16" + ], + "DS-A.03.14.09E[01]": [ + "CRY-01" + ], + "DS-A.03.14.09E[02]": [ + "CRY-01" + ], + "DS-A.03.14.09E[03]": [ + "CRY-01" + ], + "DS-A.03.01.17E.b": [ + "DCH-01.4" + ], + "A.03.01.17E.ODP[01]": [ + "DCH-02" + ], + "A.03.08.01E.ODP[01]": [ + "DCH-09" + ], + "DS-A.03.08.01E": [ + "DCH-09.5" + ], + "A.03.08.02E.ODP[01]": [ + "DCH-09.5" + ], + "DS-A.03.01.02E": [ + "DCH-13.4" + ], + "A.03.01.02E.ODP[01]": [ + "DCH-13.4" + ], + "A.03.10.01E.ODP[01]": [ + "DCH-18", + "PES-06" + ], + "DS-A.03.14.01E.a[01]": [ + "END-06" + ], + "A.03.14.01E.ODP[01]": [ + "END-06" + ], + "DS-A.03.14.01E.a[02]": [ + "END-06" + ], + "A.03.14.01E.ODP[02]": [ + "END-06" + ], + "DS-A.03.14.08E[01]": [ + "END-06.1" + ], + "A.03.14.08E.ODP[02]": [ + "END-06.1" + ], + "A.03.14.08E.ODP[04]": [ + "END-06.1" + ], + "DS-A.03.14.08E[02]": [ + "END-06.1" + ], + "A.03.14.08E.ODP[06]": [ + "END-06.1" + ], + "DS-A.03.14.08E[03]": [ + "END-06.1" + ], + "A.03.14.08E.ODP[10]": [ + "END-06.1" + ], + "DS-A.03.14.10E": [ + "END-06.6" + ], + "A.03.14.10E.ODP[01]": [ + "END-06.6" + ], + "DS-A.03.13.06E": [ + "END-10" + ], + "DS-A.03.13.11E[01]": [ + "END-11" + ], + "DS-A.03.13.13E": [ + "END-12" + ], + "A.03.13.13E.ODP[02]": [ + "END-12" + ], + "A.03.13.13E.ODP[03]": [ + "END-12" + ], + "DS-A.03.09.03E.a": [ + "HRS-01" + ], + "A.03.09.04E.ODP[01]": [ + "HRS-01" + ], + "A.03.01.08E.ODP[02]": [ + "HRS-03" + ], + "A.03.01.11E.ODP[01]": [ + "HRS-03" + ], + "A.03.14.17E.ODP[01]": [ + "HRS-03" + ], + "A.03.14.18E.ODP[01]": [ + "HRS-03" + ], + "A.03.17.03E.ODP[03]": [ + "HRS-03" + ], + "DS-A.03.09.04E": [ + "HRS-04.3" + ], + "DS-A.03.09.03E.c.01": [ + "HRS-06" + ], + "DS-A.03.01.01E": [ + "HRS-12.1", + "IAC-20.5" + ], + "A.03.01.01E.ODP[01]": [ + "HRS-12.1", + "IAC-20.5" + ], + "DS-A.03.05.07E[01]": [ + "IAC-01.4" + ], + "A.03.05.07E.ODP[02]": [ + "IAC-01.4" + ], + "DS-A.03.05.07E[02]": [ + "IAC-01.4" + ], + "DS-A.03.05.07E[03]": [ + "IAC-01.4" + ], + "DS-A.03.05.01E": [ + "IAC-04" + ], + "DS-A.03.05.03E": [ + "IAC-04" + ], + "A.03.05.03E.ODP[01]": [ + "IAC-04.1" + ], + "DS-A.03.01.11E.a": [ + "IAC-08", + "IAC-15.1" + ], + "DS-A.03.01.11E.b": [ + "IAC-08" + ], + "A.03.05.02E.ODP[02]": [ + "IAC-10.1" + ], + "A.03.05.02E.ODP[01]": [ + "IAC-10.4" + ], + "DS-A.03.05.02E.b": [ + "IAC-10.5" + ], + "DS-A.03.05.04E": [ + "IAC-10.6" + ], + "A.03.05.05E.ODP[01]": [ + "IAC-10.10" + ], + "DS-A.03.05.02E.a": [ + "IAC-10.11" + ], + "DS-A.03.01.07E[01]": [ + "IAC-15.1", + "IAC-15.4" + ], + "DS-A.03.01.07E[02]": [ + "IAC-15.1", + "IAC-15.4" + ], + "DS-A.03.01.07E[03]": [ + "IAC-15.1", + "IAC-15.4" + ], + "DS-A.03.01.07E[04]": [ + "IAC-15.1", + "IAC-15.4" + ], + "DS-A.03.01.07E[05]": [ + "IAC-15.1", + "IAC-15.4" + ], + "DS-A.03.01.04E": [ + "IAC-23" + ], + "A.03.01.04E.ODP[02]": [ + "IAC-23", + "IAO-03" + ], + "DS-A.03.05.06E.a": [ + "IAC-28" + ], + "DS-A.03.05.06E.b": [ + "IAC-28" + ], + "DS-A.03.05.06E.c[01]": [ + "IAC-28" + ], + "DS-A.03.05.06E.c[02]": [ + "IAC-28" + ], + "DS-A.03.05.06E.c[03]": [ + "IAC-28" + ], + "DS-A.03.01.09E.a[01]": [ + "IAC-29" + ], + "DS-A.03.01.09E.a[02]": [ + "IAC-29" + ], + "DS-A.03.01.09E.b": [ + "IAC-29" + ], + "A.03.01.09E.ODP[01]": [ + "IAC-29" + ], + "A.03.11.09E.ODP[02]": [ + "IRO-01" + ], + "A.03.17.03E.ODP[02]": [ + "IRO-02" + ], + "A.03.01.08E.ODP[01]": [ + "IRO-03" + ], + "A.03.02.01E.ODP[01]": [ + "IRO-03" + ], + "A.03.11.09E.ODP[01]": [ + "IRO-03" + ], + "A.03.14.17E.ODP[02]": [ + "IRO-03" + ], + "DS-A.03.06.02E[01]": [ + "IRO-07" + ], + "A.03.06.02E.ODP[01]": [ + "IRO-07" + ], + "DS-A.03.06.02E[02]": [ + "IRO-07" + ], + "DS-A.03.06.02E[03]": [ + "IRO-07" + ], + "DS-A.03.06.04E[01]": [ + "IRO-09.1" + ], + "A.03.06.04E.ODP[01]": [ + "IRO-09.1" + ], + "DS-A.03.06.04E[02]": [ + "IRO-09.1" + ], + "A.03.06.04E.ODP[02]": [ + "IRO-09.1" + ], + "DS-A.03.06.04E[03]": [ + "IRO-09.1" + ], + "A.03.06.04E.ODP[03]": [ + "IRO-09.1" + ], + "DS-A.03.13.14E": [ + "IRO-15" + ], + "DS-A.03.12.02E": [ + "IAO-02.1" + ], + "DS-A.03.01.06E": [ + "IAO-03", + "NET-14" + ], + "A.03.13.11E.ODP[01]": [ + "IAO-03" + ], + "A.03.13.14E.ODP[01]": [ + "IAO-03" + ], + "A.03.13.16E.ODP[03]": [ + "IAO-03" + ], + "A.03.14.08E.ODP[01]": [ + "IAO-03" + ], + "A.03.14.08E.ODP[03]": [ + "IAO-03" + ], + "A.03.14.08E.ODP[05]": [ + "IAO-03" + ], + "A.03.14.08E.ODP[07]": [ + "IAO-03" + ], + "A.03.14.08E.ODP[11]": [ + "IAO-03" + ], + "A.03.14.10E.ODP[02]": [ + "IAO-03" + ], + "A.03.14.14E.ODP[01]": [ + "IAO-03" + ], + "A.03.14.15E.ODP[01]": [ + "IAO-03" + ], + "A.03.14.16E.ODP[01]": [ + "IAO-03" + ], + "DS-A.03.15.01E.a.01": [ + "IAO-03", + "SEA-01.4", + "SEA-01.5" + ], + "DS-A.03.15.01E.a.03": [ + "IAO-03" + ], + "DS-A.03.15.01E.b": [ + "IAO-03" + ], + "DS-A.03.15.01E.c": [ + "IAO-03" + ], + "DS-A.03.15.02E.b": [ + "IAO-03" + ], + "A.03.15.02E.ODP[01]": [ + "IAO-03" + ], + "A.03.15.03E.ODP[01]": [ + "IAO-03" + ], + "A.03.15.03E.ODP[02]": [ + "IAO-03" + ], + "A.03.16.01E.ODP[02]": [ + "IAO-03" + ], + "A.03.17.02E.ODP[01]": [ + "IAO-03" + ], + "DS-A.03.07.01E": [ + "MNT-04" + ], + "DS-A.03.13.12E.a": [ + "NET-02.1" + ], + "A.03.13.12E.ODP[01]": [ + "NET-02.1" + ], + "A.03.13.12E.ODP[02]": [ + "NET-02.1" + ], + "A.03.13.12E.ODP[03]": [ + "NET-02.1" + ], + "A.03.01.12E.ODP[01]": [ + "NET-03", + "NET-06" + ], + "DS-A.03.13.04E": [ + "NET-03" + ], + "A.03.13.04E.ODP[01]": [ + "NET-03.7" + ], + "DS-A.03.13.10E": [ + "NET-03.8" + ], + "DS-A.03.13.15E": [ + "NET-03.8", + "NET-06.1", + "NET-06.9" + ], + "DS-A.03.01.10E": [ + "NET-04.2" + ], + "A.03.01.10E.ODP[01]": [ + "NET-04.2" + ], + "A.03.01.10E.ODP[02]": [ + "NET-04.2" + ], + "A.03.01.10E.ODP[03]": [ + "NET-04.2" + ], + "A.03.01.10E.ODP[04]": [ + "NET-04.2" + ], + "A.03.01.13E.ODP[01]": [ + "NET-04.5" + ], + "A.03.01.10E.ODP[05]": [ + "NET-04.7" + ], + "DS-A.03.01.13E": [ + "NET-04.7", + "NET-04.8" + ], + "DS-A.03.01.14E.a": [ + "NET-04.7", + "NET-04.8" + ], + "A.03.01.14E.ODP[01]": [ + "NET-04.7" + ], + "DS-A.03.01.14E.b": [ + "NET-04.7" + ], + "DS-A.03.01.15E": [ + "NET-04.8" + ], + "A.03.01.15E.ODP[01]": [ + "NET-04.8" + ], + "A.03.01.16E.ODP[01]": [ + "NET-04.9" + ], + "DS-A.03.01.17E.a": [ + "NET-04.10", + "NET-17" + ], + "DS-A.03.12.04E.a": [ + "NET-05" + ], + "A.03.12.04E.ODP[01]": [ + "NET-05" + ], + "DS-A.03.12.04E.b[01]": [ + "NET-05" + ], + "DS-A.03.12.04E.b[02]": [ + "NET-05" + ], + "DS-A.03.12.04E.b[03]": [ + "NET-05" + ], + "A.03.12.04E.ODP[02]": [ + "NET-05" + ], + "DS-A.03.12.04E.d": [ + "NET-05" + ], + "DS-A.03.01.12E": [ + "NET-06" + ], + "DS-A.03.13.09E": [ + "NET-06.1" + ], + "A.03.13.09E.ODP[01]": [ + "NET-06.9" + ], + "A.03.13.15E.ODP[01]": [ + "NET-06.9" + ], + "A.03.13.15E.ODP[02]": [ + "NET-06.9" + ], + "DS-A.03.01.05E[01]": [ + "NET-14.1" + ], + "DS-A.03.01.05E[02]": [ + "NET-14.1" + ], + "DS-A.03.10.01E[02]": [ + "PES-05", + "PES-05.1" + ], + "DS-A.03.10.02E.b": [ + "PES-05" + ], + "DS-A.03.10.01E[01]": [ + "PES-05.2" + ], + "DS-A.03.10.02E.a[01]": [ + "PES-10" + ], + "A.03.10.02E.ODP[01]": [ + "PES-10" + ], + "DS-A.03.10.02E.a[02]": [ + "PES-10" + ], + "DS-A.03.10.02E.a[03]": [ + "PES-10" + ], + "A.03.10.02E.ODP[02]": [ + "PES-10" + ], + "DS-A.03.10.02E.a[04]": [ + "PES-10" + ], + "A.03.11.10E.ODP[02]": [ + "PRM-04" + ], + "A.03.13.01E.ODP[01]": [ + "PRM-05", + "PRM-06" + ], + "A.03.13.02E.ODP[01]": [ + "PRM-05" + ], + "A.03.13.03E.ODP[01]": [ + "PRM-05" + ], + "DS-A.03.12.03E[01]": [ + "RSK-11" + ], + "DS-A.03.15.01E.a.02": [ + "SEA-01.4", + "SEA-01.5", + "SEA-02" + ], + "DS-A.03.15.02E.a": [ + "SEA-03" + ], + "A.03.15.02E.ODP[02]": [ + "SEA-03" + ], + "DS-A.03.15.02E.c": [ + "SEA-03" + ], + "DS-A.03.13.16E": [ + "SEA-03.1" + ], + "A.03.13.16E.ODP[01]": [ + "SEA-03.1" + ], + "A.03.13.16E.ODP[02]": [ + "SEA-03.1" + ], + "DS-A.03.14.15E.a": [ + "SEA-08" + ], + "DS-A.03.14.15E.b": [ + "SEA-08" + ], + "DS-A.03.14.15E.c": [ + "SEA-08" + ], + "A.03.14.15E.ODP[02]": [ + "SEA-08" + ], + "DS-A.03.14.04E": [ + "SEA-08.1" + ], + "A.03.14.04E.ODP[01]": [ + "SEA-08.1" + ], + "DS-A.03.14.05E.a": [ + "SEA-08.2" + ], + "A.03.14.05E.ODP[01]": [ + "SEA-08.2" + ], + "DS-A.03.14.05E.b": [ + "SEA-08.2" + ], + "DS-A.03.14.14E": [ + "SEA-10" + ], + "DS-A.03.13.08E[01]": [ + "SEA-11" + ], + "DS-A.03.13.08E[02]": [ + "SEA-11" + ], + "DS-A.03.13.08E[03]": [ + "SEA-11" + ], + "DS-A.03.13.01E": [ + "SEA-13" + ], + "DS-A.03.13.07E": [ + "SEA-13.1" + ], + "DS-A.03.13.03E": [ + "SEA-14" + ], + "DS-A.03.13.02E": [ + "SEA-14.1" + ], + "DS-A.03.13.05E": [ + "SEA-14.2" + ], + "A.03.13.05E.ODP[01]": [ + "SEA-14.2" + ], + "A.03.02.01E.ODP[02]": [ + "OPS-01.1" + ], + "A.03.08.03E.ODP[01]": [ + "OPS-01.1" + ], + "A.03.08.03E.ODP[02]": [ + "OPS-01.1" + ], + "DS-A.03.09.03E.b[01]": [ + "OPS-01.1" + ], + "A.03.09.03E.ODP[01]": [ + "OPS-01.1" + ], + "DS-A.03.09.03E.b[02]": [ + "OPS-01.1" + ], + "DS-A.03.09.03E.c.02": [ + "OPS-01.1" + ], + "A.03.09.03E.ODP[02]": [ + "OPS-01.1" + ], + "A.03.11.02E.ODP[01]": [ + "OPS-01.1" + ], + "A.03.12.01E.ODP[01]": [ + "OPS-01.1" + ], + "A.03.12.04E.ODP[03]": [ + "OPS-01.1" + ], + "A.03.13.05E.ODP[02]": [ + "OPS-01.1" + ], + "A.03.13.05E.ODP[03]": [ + "OPS-01.1" + ], + "A.03.13.07E.ODP[01]": [ + "OPS-01.1" + ], + "A.03.14.05E.ODP[02]": [ + "OPS-01.1" + ], + "A.03.14.05E.ODP[03]": [ + "OPS-01.1" + ], + "A.03.14.05E.ODP[04]": [ + "OPS-01.1" + ], + "A.03.14.08E.ODP[08]": [ + "OPS-01.1" + ], + "A.03.14.08E.ODP[09]": [ + "OPS-01.1" + ], + "A.03.14.08E.ODP[12]": [ + "OPS-01.1" + ], + "A.03.14.15E.ODP[03]": [ + "OPS-01.1" + ], + "A.03.15.01E.ODP[01]": [ + "OPS-01.1" + ], + "A.03.17.02E.ODP[02]": [ + "OPS-01.1" + ], + "A.03.17.02E.ODP[03]": [ + "OPS-01.1" + ], + "DS-A.03.06.01E[01]": [ + "OPS-04" + ], + "DS-A.03.06.01E[02]": [ + "OPS-04" + ], + "DS-A.03.02.01E.b[01]": [ + "SAT-01.1" + ], + "DS-A.03.02.01E.b[02]": [ + "SAT-01.1" + ], + "A.03.02.01E.ODP[03]": [ + "SAT-01.1" + ], + "DS-A.03.02.02E": [ + "SAT-02.1" + ], + "DS-A.03.02.01E.a.02": [ + "SAT-03", + "SAT-03.2" + ], + "A.03.02.04E.ODP[01]": [ + "SAT-03" + ], + "DS-A.03.02.01E.a.01": [ + "SAT-03.6" + ], + "DS-A.03.02.01E.a.03": [ + "SAT-03.6" + ], + "DS-A.03.02.03E": [ + "SAT-04.1" + ], + "DS-A.03.16.01E": [ + "TDA-01", + "TDA-01.1" + ], + "A.03.16.01E.ODP[01]": [ + "TDA-01.1" + ], + "DS-A.03.15.03E": [ + "TDA-03.1" + ], + "A.03.11.10E.ODP[01]": [ + "TDA-06.1", + "TPM-02" + ], + "DS-A.03.17.03E.b": [ + "TDA-11" + ], + "A.03.17.03E.ODP[01]": [ + "TDA-11" + ], + "DS-A.03.17.05E[01]": [ + "TDA-11" + ], + "A.03.17.05E.ODP[01]": [ + "TDA-11" + ], + "DS-A.03.17.05E[02]": [ + "TDA-11" + ], + "DS-A.03.02.04E": [ + "TDA-11.1" + ], + "DS-A.03.14.12E": [ + "TDA-18" + ], + "A.03.14.12E.ODP[01]": [ + "TDA-18" + ], + "DS-A.03.14.13E.a": [ + "TDA-19" + ], + "DS-A.03.14.13E.b": [ + "TDA-19" + ], + "A.03.14.13E.ODP[01]": [ + "TDA-19.1" + ], + "A.03.17.01E.ODP[02]": [ + "TPM-05" + ], + "DS-A.03.17.01E": [ + "TPM-05.1" + ], + "A.03.17.01E.ODP[01]": [ + "TPM-05.1" + ], + "DS-A.03.11.01E": [ + "THR-01" + ], + "DS-A.03.11.08E": [ + "THR-01.1" + ], + "A.03.11.08E.ODP[01]": [ + "THR-01.1" + ], + "DS-A.03.11.03E[01]": [ + "THR-01.2" + ], + "A.03.11.03E.ODP[01]": [ + "THR-01.2" + ], + "A.03.11.03E.ODP[02]": [ + "THR-01.2" + ], + "DS-A.03.11.03E[02]": [ + "THR-01.2" + ], + "A.03.11.03E.ODP[03]": [ + "THR-01.2" + ], + "DS-A.03.11.12E": [ + "THR-03" + ], + "DS-A.03.11.02E.a.01[02]": [ + "THR-07" + ], + "DS-A.03.11.02E.a.02[01]": [ + "THR-07" + ], + "DS-A.03.11.02E.a.02[02]": [ + "THR-07" + ], + "DS-A.03.11.02E.b": [ + "THR-07" + ], + "DS-A.03.14.16E": [ + "THR-08" + ], + "A.03.12.01E.ODP[02]": [ + "VPM-01.1" + ], + "A.03.11.11E.ODP[01]": [ + "VPM-02" + ], + "DS-A.03.11.11E[02]": [ + "VPM-02" + ], + "DS-A.03.11.11E[01]": [ + "VPM-06.8" + ], + "DS-A.03.12.01E": [ + "VPM-07" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/general-nist-800-207.json b/docs/api/crosswalks/general-nist-800-207.json index 8438827b..eeebeeed 100644 --- a/docs/api/crosswalks/general-nist-800-207.json +++ b/docs/api/crosswalks/general-nist-800-207.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-207", - "display_name": "NIST SP 800-207", + "display_name": "NIST SP 800 - 207 - Zero Trust Architecture", "scf_to_framework": { "total_mappings": 93, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-218.json b/docs/api/crosswalks/general-nist-800-218.json index 93ec2fa5..6dbb0f4d 100644 --- a/docs/api/crosswalks/general-nist-800-218.json +++ b/docs/api/crosswalks/general-nist-800-218.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-218", - "display_name": "NIST SP 800-218", + "display_name": "NIST SP 800 - 218 - Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities", "scf_to_framework": { "total_mappings": 59, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-37-r2.json b/docs/api/crosswalks/general-nist-800-37-r2.json index f444e35a..0f750187 100644 --- a/docs/api/crosswalks/general-nist-800-37-r2.json +++ b/docs/api/crosswalks/general-nist-800-37-r2.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-37-r2", - "display_name": "NIST SP 800-37 R2", + "display_name": "NIST SP 800 - 37 R2 - Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy", "scf_to_framework": { "total_mappings": 45, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-39.json b/docs/api/crosswalks/general-nist-800-39.json index 64c709c2..075f6230 100644 --- a/docs/api/crosswalks/general-nist-800-39.json +++ b/docs/api/crosswalks/general-nist-800-39.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-39", - "display_name": "NIST SP 800-39", + "display_name": "NIST SP 800 - 39 - Managing Information Security Risk: Organization, Mission, and Information System View", "scf_to_framework": { "total_mappings": 17, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-53-r4.json b/docs/api/crosswalks/general-nist-800-53-r4.json index 1a31ee2f..1ded1e68 100644 --- a/docs/api/crosswalks/general-nist-800-53-r4.json +++ b/docs/api/crosswalks/general-nist-800-53-r4.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-53-r4", - "display_name": "NIST SP 800-53 R4", + "display_name": "NIST SP 800 - 53 R4 - Security and Privacy Controls for Federal Information Systems and Organizations", "scf_to_framework": { "total_mappings": 653, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-53-r5-2-high.json b/docs/api/crosswalks/general-nist-800-53-r5-2-high.json index 77cdeefa..e688e752 100644 --- a/docs/api/crosswalks/general-nist-800-53-r5-2-high.json +++ b/docs/api/crosswalks/general-nist-800-53-r5-2-high.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-53-r5-2-high", - "display_name": "NIST SP 800-53 R5 - High Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - High Baseline", "scf_to_framework": { "total_mappings": 89, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-53-r5-2-low.json b/docs/api/crosswalks/general-nist-800-53-r5-2-low.json index bf692f3b..6337da16 100644 --- a/docs/api/crosswalks/general-nist-800-53-r5-2-low.json +++ b/docs/api/crosswalks/general-nist-800-53-r5-2-low.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-53-r5-2-low", - "display_name": "NIST SP 800-53 R5 - Low Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Low Baseline", "scf_to_framework": { "total_mappings": 202, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-53-r5-2-mod.json b/docs/api/crosswalks/general-nist-800-53-r5-2-mod.json index 9c2b4e57..fca8fd55 100644 --- a/docs/api/crosswalks/general-nist-800-53-r5-2-mod.json +++ b/docs/api/crosswalks/general-nist-800-53-r5-2-mod.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-53-r5-2-mod", - "display_name": "NIST SP 800-53 R5 - Moderate Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Moderate Baseline", "scf_to_framework": { "total_mappings": 157, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-53-r5-2-privacy.json b/docs/api/crosswalks/general-nist-800-53-r5-2-privacy.json index b8190a95..e130c6f4 100644 --- a/docs/api/crosswalks/general-nist-800-53-r5-2-privacy.json +++ b/docs/api/crosswalks/general-nist-800-53-r5-2-privacy.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-53-r5-2-privacy", - "display_name": "NIST SP 800-53 R5 - Privacy Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Privacy Baseline", "scf_to_framework": { "total_mappings": 346, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-53-r5-2.json b/docs/api/crosswalks/general-nist-800-53-r5-2.json index c7dde9d2..19a41b8b 100644 --- a/docs/api/crosswalks/general-nist-800-53-r5-2.json +++ b/docs/api/crosswalks/general-nist-800-53-r5-2.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-53-r5-2", - "display_name": "NIST SP 800-53 R5", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations", "scf_to_framework": { "total_mappings": 777, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-66-r2.json b/docs/api/crosswalks/general-nist-800-66-r2.json index dabc384c..b42f9a8f 100644 --- a/docs/api/crosswalks/general-nist-800-66-r2.json +++ b/docs/api/crosswalks/general-nist-800-66-r2.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-66-r2", - "display_name": "NIST SP 800-66 R2", + "display_name": "NIST SP 800 - 66 R2 - Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide", "scf_to_framework": { "total_mappings": 112, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-82-r3-high.json b/docs/api/crosswalks/general-nist-800-82-r3-high.json index ff7464c0..f39cc9ac 100644 --- a/docs/api/crosswalks/general-nist-800-82-r3-high.json +++ b/docs/api/crosswalks/general-nist-800-82-r3-high.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-82-r3-high", - "display_name": "NIST SP 800-82 R3 - High OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - High OT Overlay", "scf_to_framework": { "total_mappings": 467, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-82-r3-low.json b/docs/api/crosswalks/general-nist-800-82-r3-low.json index 65cb0564..73c10a5d 100644 --- a/docs/api/crosswalks/general-nist-800-82-r3-low.json +++ b/docs/api/crosswalks/general-nist-800-82-r3-low.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-82-r3-low", - "display_name": "NIST SP 800-82 R3 - Low OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay", "scf_to_framework": { "total_mappings": 251, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-82-r3-mod.json b/docs/api/crosswalks/general-nist-800-82-r3-mod.json index 2f1250ba..e0f0a21f 100644 --- a/docs/api/crosswalks/general-nist-800-82-r3-mod.json +++ b/docs/api/crosswalks/general-nist-800-82-r3-mod.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-82-r3-mod", - "display_name": "NIST SP 800-82 R3 - Moderate OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Moderate OT Overlay", "scf_to_framework": { "total_mappings": 390, "mappings": { diff --git a/docs/api/crosswalks/general-nist-800-82-r3.json b/docs/api/crosswalks/general-nist-800-82-r3.json index 2fb4bfcf..df1b6074 100644 --- a/docs/api/crosswalks/general-nist-800-82-r3.json +++ b/docs/api/crosswalks/general-nist-800-82-r3.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-800-82-r3", - "display_name": "NIST SP 800-82 R3", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay", "scf_to_framework": { "total_mappings": 777, "mappings": { diff --git a/docs/api/crosswalks/general-nist-csf-2-0.json b/docs/api/crosswalks/general-nist-csf-2-0.json index dc814fb3..47bb5a4f 100644 --- a/docs/api/crosswalks/general-nist-csf-2-0.json +++ b/docs/api/crosswalks/general-nist-csf-2-0.json @@ -1,6 +1,6 @@ { "framework_id": "general-nist-csf-2-0", - "display_name": "NIST Cybersecurity Framework (v2.0)", + "display_name": "NIST Cybersecurity Framework v2.0", "scf_to_framework": { "total_mappings": 250, "mappings": { diff --git a/docs/api/crosswalks/general-nist-cswp-39.json b/docs/api/crosswalks/general-nist-cswp-39.json new file mode 100644 index 00000000..f52c36ef --- /dev/null +++ b/docs/api/crosswalks/general-nist-cswp-39.json @@ -0,0 +1,128 @@ +{ + "framework_id": "general-nist-cswp-39", + "display_name": "NIST CSWP 39 - Considerations for Achieving Crypto Agility", + "scf_to_framework": { + "total_mappings": 15, + "mappings": { + "CLD-02": [ + "6.4" + ], + "CPL-01": [ + "3.1.1", + "3.1.2", + "5.1" + ], + "CRY-01.5": [ + "3.1" + ], + "CRY-09": [ + "3.3" + ], + "EMB-18": [ + "4.4" + ], + "PRM-01": [ + "6.1" + ], + "PRM-01.2": [ + "6.5" + ], + "PRM-02": [ + "6.1" + ], + "PRM-02.1": [ + "6.1" + ], + "QTS-02": [ + "5" + ], + "QTS-02.3": [ + "6.5" + ], + "QTS-03": [ + "3", + "5", + "5.3", + "6" + ], + "QTS-04": [ + "5" + ], + "QTS-06": [ + "4", + "5.4", + "6.2", + "6.3", + "6.4" + ], + "QTS-06.5": [ + "5.2" + ] + } + }, + "framework_to_scf": { + "total_mappings": 18, + "mappings": { + "3": [ + "QTS-03" + ], + "4": [ + "QTS-06" + ], + "5": [ + "QTS-02", + "QTS-03", + "QTS-04" + ], + "6": [ + "QTS-03" + ], + "6.4": [ + "CLD-02", + "QTS-06" + ], + "3.1.1": [ + "CPL-01" + ], + "3.1.2": [ + "CPL-01" + ], + "5.1": [ + "CPL-01" + ], + "3.1": [ + "CRY-01.5" + ], + "3.3": [ + "CRY-09" + ], + "4.4": [ + "EMB-18" + ], + "6.1": [ + "PRM-01", + "PRM-02", + "PRM-02.1" + ], + "6.5": [ + "PRM-01.2", + "QTS-02.3" + ], + "5.3": [ + "QTS-03" + ], + "5.4": [ + "QTS-06" + ], + "6.2": [ + "QTS-06" + ], + "6.3": [ + "QTS-06" + ], + "5.2": [ + "QTS-06.5" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/general-nist-privacy-framework-1-0.json b/docs/api/crosswalks/general-nist-privacy-framework-1-0.json index ea5f0a1a..d35d33c6 100644 --- a/docs/api/crosswalks/general-nist-privacy-framework-1-0.json +++ b/docs/api/crosswalks/general-nist-privacy-framework-1-0.json @@ -1,8 +1,8 @@ { "framework_id": "general-nist-privacy-framework-1-0", - "display_name": "NIST Privacy Framework (v1.0)", + "display_name": "NIST Privacy Framework v1.0", "scf_to_framework": { - "total_mappings": 152, + "total_mappings": 153, "mappings": { "GOV-01": [ "ID-P", @@ -369,6 +369,9 @@ "CM.AW-P2", "CM.AW-P3" ], + "PRI-01.12": [ + "CT.DM-P10" + ], "PRI-02": [ "CM.PO-P1", "CM.AW-P1" @@ -595,7 +598,7 @@ } }, "framework_to_scf": { - "total_mappings": 122, + "total_mappings": 123, "mappings": { "ID-P": [ "GOV-01" @@ -1018,6 +1021,9 @@ "PRM-07", "SEA-01" ], + "CT.DM-P10": [ + "PRI-01.12" + ], "CT.PO-P4": [ "PRI-06.2", "PRI-06.4", diff --git a/docs/api/crosswalks/general-oecd-privacy-principles-2010.json b/docs/api/crosswalks/general-oecd-privacy-principles-2010.json index c653afcc..df1ea149 100644 --- a/docs/api/crosswalks/general-oecd-privacy-principles-2010.json +++ b/docs/api/crosswalks/general-oecd-privacy-principles-2010.json @@ -1,6 +1,6 @@ { "framework_id": "general-oecd-privacy-principles-2010", - "display_name": "OECD Privacy Principles (2010)", + "display_name": "Organisation for Economic Co - operation and Development (EOCD) Privacy Principles", "scf_to_framework": { "total_mappings": 14, "mappings": { diff --git a/docs/api/crosswalks/general-owasp-top-10-2025.json b/docs/api/crosswalks/general-owasp-top-10-2025.json index 0fea44a2..2801fadf 100644 --- a/docs/api/crosswalks/general-owasp-top-10-2025.json +++ b/docs/api/crosswalks/general-owasp-top-10-2025.json @@ -1,6 +1,6 @@ { "framework_id": "general-owasp-top-10-2025", - "display_name": "OWASP Top 10 (2025)", + "display_name": "Open Worldwide Application Security Project (OWASP) Top 10 (2025)", "scf_to_framework": { "total_mappings": 139, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-a-ep.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-a-ep.json index 096e1b1c..7e1d0ee2 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-a-ep.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-a-ep.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-a-ep", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ A-EP (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A - EP", "scf_to_framework": { "total_mappings": 239, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-a.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-a.json index 5d54d89d..3e50e204 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-a.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-a.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-a", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ A (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A", "scf_to_framework": { "total_mappings": 71, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-b-ip.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-b-ip.json index 46c69301..5f1d3868 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-b-ip.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-b-ip.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-b-ip", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ B-IP (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B - IP", "scf_to_framework": { "total_mappings": 121, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-b.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-b.json index 6490393f..de9c6af0 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-b.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-b.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-b", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ B (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B", "scf_to_framework": { "total_mappings": 58, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-c-vt.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-c-vt.json index 798e6af9..ef9f1afc 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-c-vt.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-c-vt.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-c-vt", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ C-VT (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C - VT", "scf_to_framework": { "total_mappings": 115, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-c.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-c.json index f7a4d3b1..b9a6ca49 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-c.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-c.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-c", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ C (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C", "scf_to_framework": { "total_mappings": 227, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-d-merchant.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-d-merchant.json index 7b800f2f..0e2fbedf 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-d-merchant.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-d-merchant.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-d-merchant", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Merchant (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Merchant", "scf_to_framework": { "total_mappings": 322, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-d-service-provider.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-d-service-provider.json index 4ba652ca..c6ad3177 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-d-service-provider.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-d-service-provider.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-d-service-provider", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Service Provider (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Service Provider", "scf_to_framework": { "total_mappings": 339, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-p2pe.json b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-p2pe.json index c5ab9e2a..be27a86a 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1-saq-p2pe.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1-saq-p2pe.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1-saq-p2pe", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ P2PE (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) P2PE", "scf_to_framework": { "total_mappings": 47, "mappings": { diff --git a/docs/api/crosswalks/general-pci-dss-4-0-1.json b/docs/api/crosswalks/general-pci-dss-4-0-1.json index dcb1c00d..dd973d67 100644 --- a/docs/api/crosswalks/general-pci-dss-4-0-1.json +++ b/docs/api/crosswalks/general-pci-dss-4-0-1.json @@ -1,6 +1,6 @@ { "framework_id": "general-pci-dss-4-0-1", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) (v4.01)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.01", "scf_to_framework": { "total_mappings": 371, "mappings": { diff --git a/docs/api/crosswalks/general-scf-dpmp-2025.json b/docs/api/crosswalks/general-scf-dpmp-2025.json index 16d80a25..355abbc3 100644 --- a/docs/api/crosswalks/general-scf-dpmp-2025.json +++ b/docs/api/crosswalks/general-scf-dpmp-2025.json @@ -1,1128 +1,12 @@ { "framework_id": "general-scf-dpmp-2025", - "display_name": "Data Privacy Management Principle (DPMP) (2025)", + "display_name": "Secure Controls Framework (SCF) Data Privacy Management Principles (2025)", "scf_to_framework": { - "total_mappings": 218, - "mappings": { - "GOV-01": [ - "1.0" - ], - "GOV-01.2": [ - "11.5", - "11.8" - ], - "GOV-02": [ - "11.2" - ], - "GOV-03": [ - "11.3" - ], - "GOV-05": [ - "11.5" - ], - "GOV-08": [ - "11.1" - ], - "GOV-10": [ - "5.9" - ], - "GOV-15": [ - "7.0", - "7.1" - ], - "GOV-15.1": [ - "7.0", - "7.1" - ], - "GOV-15.2": [ - "7.0", - "7.1" - ], - "GOV-15.3": [ - "7.0", - "7.1" - ], - "GOV-15.4": [ - "7.0", - "7.1" - ], - "GOV-15.5": [ - "7.0", - "7.1" - ], - "AST-02": [ - "5.2" - ], - "AST-02.8": [ - "5.2" - ], - "AST-03": [ - "5.3" - ], - "AST-03.1": [ - "5.3" - ], - "AST-04": [ - "5.2" - ], - "BCD-02": [ - "11.7" - ], - "CHG-02": [ - "7.1" - ], - "CHG-03": [ - "7.1" - ], - "CLD-01": [ - "7.1" - ], - "CLD-02": [ - "7.1" - ], - "CPL-01": [ - "2.4", - "11.6" - ], - "CPL-01.1": [ - "11.6" - ], - "CPL-01.2": [ - "11.6" - ], - "CPL-01.3": [ - "11.6" - ], - "CPL-01.4": [ - "11.6" - ], - "CPL-02": [ - "11.4" - ], - "CPL-03": [ - "11.3" - ], - "CFG-01": [ - "7.12" - ], - "CFG-02": [ - "7.12" - ], - "CFG-08.1": [ - "5.2" - ], - "MON-01": [ - "7.0" - ], - "MON-02": [ - "7.0", - "7.13" - ], - "MON-02.1": [ - "7.13" - ], - "MON-10": [ - "11.6" - ], - "CRY-01": [ - "7.2" - ], - "CRY-03": [ - "7.2" - ], - "CRY-05": [ - "7.2" - ], - "DCH-01": [ - "5.0" - ], - "DCH-01.3": [ - "5.2" - ], - "DCH-02": [ - "1.2" - ], - "DCH-09.3": [ - "5.5" - ], - "DCH-18": [ - "5.4" - ], - "DCH-18.1": [ - "3.3", - "5.4" - ], - "DCH-18.2": [ - "3.2" - ], - "DCH-21": [ - "5.5" - ], - "DCH-22.1": [ - "5.15", - "6.1", - "6.2" - ], - "DCH-23": [ - "5.1" - ], - "DCH-24": [ - "5.6" - ], - "DCH-25": [ - "5.6" - ], - "EMB-01": [ - "7.4" - ], - "END-13.1": [ - "7.4" - ], - "END-13.2": [ - "7.4" - ], - "END-13.3": [ - "7.4" - ], - "HRS-01": [ - "7.9" - ], - "HRS-04": [ - "7.1" - ], - "HRS-05.1": [ - "7.7" - ], - "HRS-05.2": [ - "7.7" - ], - "HRS-07": [ - "7.8" - ], - "IAC-01": [ - "7.0" - ], - "IAC-01.2": [ - "7.1" - ], - "IAC-06": [ - "7.1" - ], - "IAC-08": [ - "7.1" - ], - "IAC-16": [ - "7.1" - ], - "IAC-21": [ - "7.1" - ], - "IAC-28.1": [ - "7.1" - ], - "IRO-01": [ - "8.0" - ], - "IRO-02": [ - "8.0", - "8.1" - ], - "IRO-04": [ - "8.0" - ], - "IRO-04.1": [ - "8.0" - ], - "IRO-06": [ - "8.0" - ], - "IRO-07": [ - "8.1" - ], - "IRO-10": [ - "8.2" - ], - "IRO-11": [ - "8.0" - ], - "IRO-11.2": [ - "8.2" - ], - "IAO-01": [ - "7.11" - ], - "IAO-03": [ - "5.13" - ], - "IAO-05": [ - "9.3" - ], - "IAO-07": [ - "7.11" - ], - "PES-01": [ - "7.3" - ], - "PES-02": [ - "7.3" - ], - "PES-02.1": [ - "7.3" - ], - "PES-03": [ - "7.3" - ], - "PES-04": [ - "7.3" - ], - "PES-05": [ - "7.3" - ], - "PES-06": [ - "7.3" - ], - "PRI-01": [ - "1.0", - "1.1" - ], - "PRI-01.1": [ - "1.1" - ], - "PRI-01.2": [ - "4.0" - ], - "PRI-01.3": [ - "1.0", - "11.2" - ], - "PRI-01.4": [ - "1.1" - ], - "PRI-01.6": [ - "7.0", - "7.1" - ], - "PRI-01.11": [ - "1.0" - ], - "PRI-02": [ - "4.0" - ], - "PRI-02.1": [ - "4.1" - ], - "PRI-02.2": [ - "5.0" - ], - "PRI-02.3": [ - "11.6" - ], - "PRI-02.4": [ - "11.6" - ], - "PRI-02.5": [ - "11.6" - ], - "PRI-02.6": [ - "11.6" - ], - "PRI-03": [ - "2.0", - "2.1", - "2.2" - ], - "PRI-03.1": [ - "2.5" - ], - "PRI-03.2": [ - "2.3", - "5.14" - ], - "PRI-03.3": [ - "2.5" - ], - "PRI-03.4": [ - "2.3" - ], - "PRI-03.5": [ - "2.4" - ], - "PRI-03.6": [ - "2.6" - ], - "PRI-03.7": [ - "6.0" - ], - "PRI-03.8": [ - "2.7" - ], - "PRI-04": [ - "3.0" - ], - "PRI-04.1": [ - "3.1" - ], - "PRI-05": [ - "5.0" - ], - "PRI-05.1": [ - "3.3" - ], - "PRI-05.2": [ - "5.9" - ], - "PRI-05.3": [ - "5.1" - ], - "PRI-05.4": [ - "3.3" - ], - "PRI-05.5": [ - "1.5" - ], - "PRI-05.6": [ - "1.5" - ], - "PRI-05.7": [ - "1.2", - "1.7" - ], - "PRI-06": [ - "6.0" - ], - "PRI-06.1": [ - "6.3" - ], - "PRI-06.2": [ - "6.4" - ], - "PRI-06.3": [ - "6.5" - ], - "PRI-06.4": [ - "6.1" - ], - "PRI-06.5": [ - "6.6" - ], - "PRI-06.6": [ - "5.7" - ], - "PRI-06.7": [ - "5.7" - ], - "PRI-06.8": [ - "6.1" - ], - "PRI-07": [ - "10.2" - ], - "PRI-07.1": [ - "10.3" - ], - "PRI-07.2": [ - "11.1" - ], - "PRI-07.3": [ - "6.4" - ], - "PRI-07.4": [ - "6.0", - "6.1" - ], - "PRI-08": [ - "10.4" - ], - "PRI-09": [ - "5.1", - "5.13" - ], - "PRI-10": [ - "5.11" - ], - "PRI-10.1": [ - "5.11" - ], - "PRI-10.2": [ - "5.16" - ], - "PRI-11": [ - "5.0", - "5.2" - ], - "PRI-12": [ - "6.2" - ], - "PRI-13": [ - "11.4" - ], - "PRI-14": [ - "5.8", - "11.5" - ], - "PRI-14.1": [ - "5.8" - ], - "PRI-14.2": [ - "4.0", - "4.1" - ], - "PRI-15": [ - "1.3" - ], - "PRI-17": [ - "1.8" - ], - "PRI-17.1": [ - "1.9" - ], - "PRI-17.2": [ - "1.1" - ], - "PRM-01": [ - "1.4" - ], - "PRM-02": [ - "11.0" - ], - "PRM-04": [ - "5.12" - ], - "PRM-05": [ - "5.12" - ], - "PRM-06": [ - "5.12" - ], - "PRM-07": [ - "5.12" - ], - "PRM-08": [ - "5.12" - ], - "RSK-01": [ - "9.0" - ], - "RSK-04": [ - "9.1" - ], - "RSK-04.1": [ - "9.3" - ], - "RSK-04.3": [ - "9.1" - ], - "RSK-04.4": [ - "9.1" - ], - "RSK-06.1": [ - "9.4" - ], - "RSK-06.2": [ - "9.0" - ], - "RSK-08": [ - "9.2" - ], - "RSK-09": [ - "9.2" - ], - "RSK-09.1": [ - "9.2" - ], - "RSK-10": [ - "9.5" - ], - "RSK-11": [ - "7.11", - "9.0", - "9.3" - ], - "SEA-01": [ - "5.12", - "7.1" - ], - "SEA-01.1": [ - "7.0" - ], - "SEA-02": [ - "7.1" - ], - "SEA-15": [ - "5.6" - ], - "SAT-01": [ - "1.6", - "7.6" - ], - "SAT-02": [ - "1.6" - ], - "SAT-02.1": [ - "1.6" - ], - "SAT-03": [ - "1.6" - ], - "SAT-03.1": [ - "1.6" - ], - "SAT-03.2": [ - "1.6" - ], - "SAT-03.3": [ - "1.6" - ], - "SAT-03.6": [ - "1.6" - ], - "SAT-04": [ - "1.6" - ], - "TDA-01": [ - "7.0" - ], - "TDA-01.1": [ - "7.1" - ], - "TDA-02.3": [ - "7.1" - ], - "TDA-02.4": [ - "7.1" - ], - "TDA-02.6": [ - "7.1" - ], - "TDA-02.7": [ - "7.1" - ], - "TDA-02.8": [ - "7.1" - ], - "TDA-02.9": [ - "7.1" - ], - "TDA-02.10": [ - "7.1" - ], - "TDA-02.11": [ - "7.1" - ], - "TDA-06": [ - "5.12", - "7.1" - ], - "TDA-06.1": [ - "11.7" - ], - "TDA-06.5": [ - "7.1" - ], - "TDA-09": [ - "7.0", - "7.11", - "7.12" - ], - "TDA-17": [ - "7.5" - ], - "TDA-22": [ - "7.1" - ], - "TPM-01": [ - "10.0", - "11.0" - ], - "TPM-02": [ - "11.7" - ], - "TPM-03": [ - "10.1" - ], - "TPM-04": [ - "10.0", - "10.1", - "10.4" - ], - "TPM-04.4": [ - "5.6" - ], - "TPM-05": [ - "10.3" - ], - "TPM-05.2": [ - "10.3" - ], - "TPM-05.4": [ - "10.4" - ], - "TPM-05.5": [ - "10.4" - ], - "TPM-08": [ - "10.0", - "10.4" - ], - "TPM-09": [ - "10.0", - "10.4" - ], - "TPM-10": [ - "10.0", - "10.4" - ], - "THR-06": [ - "5.15" - ], - "VPM-01": [ - "5.15" - ], - "VPM-01.1": [ - "5.15" - ], - "VPM-02": [ - "5.15" - ], - "VPM-03": [ - "5.15" - ], - "VPM-04": [ - "5.15" - ], - "VPM-04.2": [ - "5.15" - ], - "VPM-05": [ - "5.15" - ] - } + "total_mappings": 0, + "mappings": {} }, "framework_to_scf": { - "total_mappings": 83, - "mappings": { - "1.0": [ - "GOV-01", - "PRI-01", - "PRI-01.3", - "PRI-01.11" - ], - "11.5": [ - "GOV-01.2", - "GOV-05", - "PRI-14" - ], - "11.8": [ - "GOV-01.2" - ], - "11.2": [ - "GOV-02", - "PRI-01.3" - ], - "11.3": [ - "GOV-03", - "CPL-03" - ], - "11.1": [ - "GOV-08", - "PRI-07.2" - ], - "5.9": [ - "GOV-10", - "PRI-05.2" - ], - "7.0": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "MON-01", - "MON-02", - "IAC-01", - "PRI-01.6", - "SEA-01.1", - "TDA-01", - "TDA-09" - ], - "7.1": [ - "GOV-15", - "GOV-15.1", - "GOV-15.2", - "GOV-15.3", - "GOV-15.4", - "GOV-15.5", - "CHG-02", - "CHG-03", - "CLD-01", - "CLD-02", - "HRS-04", - "IAC-01.2", - "IAC-06", - "IAC-08", - "IAC-16", - "IAC-21", - "IAC-28.1", - "PRI-01.6", - "SEA-01", - "SEA-02", - "TDA-01.1", - "TDA-02.3", - "TDA-02.4", - "TDA-02.6", - "TDA-02.7", - "TDA-02.8", - "TDA-02.9", - "TDA-02.10", - "TDA-02.11", - "TDA-06", - "TDA-06.5", - "TDA-22" - ], - "5.2": [ - "AST-02", - "AST-02.8", - "AST-04", - "CFG-08.1", - "DCH-01.3", - "PRI-11" - ], - "5.3": [ - "AST-03", - "AST-03.1" - ], - "11.7": [ - "BCD-02", - "TDA-06.1", - "TPM-02" - ], - "2.4": [ - "CPL-01", - "PRI-03.5" - ], - "11.6": [ - "CPL-01", - "CPL-01.1", - "CPL-01.2", - "CPL-01.3", - "CPL-01.4", - "MON-10", - "PRI-02.3", - "PRI-02.4", - "PRI-02.5", - "PRI-02.6" - ], - "11.4": [ - "CPL-02", - "PRI-13" - ], - "7.12": [ - "CFG-01", - "CFG-02", - "TDA-09" - ], - "7.13": [ - "MON-02", - "MON-02.1" - ], - "7.2": [ - "CRY-01", - "CRY-03", - "CRY-05" - ], - "5.0": [ - "DCH-01", - "PRI-02.2", - "PRI-05", - "PRI-11" - ], - "1.2": [ - "DCH-02", - "PRI-05.7" - ], - "5.5": [ - "DCH-09.3", - "DCH-21" - ], - "5.4": [ - "DCH-18", - "DCH-18.1" - ], - "3.3": [ - "DCH-18.1", - "PRI-05.1", - "PRI-05.4" - ], - "3.2": [ - "DCH-18.2" - ], - "5.15": [ - "DCH-22.1", - "THR-06", - "VPM-01", - "VPM-01.1", - "VPM-02", - "VPM-03", - "VPM-04", - "VPM-04.2", - "VPM-05" - ], - "6.1": [ - "DCH-22.1", - "PRI-06.4", - "PRI-06.8", - "PRI-07.4" - ], - "6.2": [ - "DCH-22.1", - "PRI-12" - ], - "5.1": [ - "DCH-23", - "PRI-05.3", - "PRI-09" - ], - "5.6": [ - "DCH-24", - "DCH-25", - "SEA-15", - "TPM-04.4" - ], - "7.4": [ - "EMB-01", - "END-13.1", - "END-13.2", - "END-13.3" - ], - "7.9": [ - "HRS-01" - ], - "7.7": [ - "HRS-05.1", - "HRS-05.2" - ], - "7.8": [ - "HRS-07" - ], - "8.0": [ - "IRO-01", - "IRO-02", - "IRO-04", - "IRO-04.1", - "IRO-06", - "IRO-11" - ], - "8.1": [ - "IRO-02", - "IRO-07" - ], - "8.2": [ - "IRO-10", - "IRO-11.2" - ], - "7.11": [ - "IAO-01", - "IAO-07", - "RSK-11", - "TDA-09" - ], - "5.13": [ - "IAO-03", - "PRI-09" - ], - "9.3": [ - "IAO-05", - "RSK-04.1", - "RSK-11" - ], - "7.3": [ - "PES-01", - "PES-02", - "PES-02.1", - "PES-03", - "PES-04", - "PES-05", - "PES-06" - ], - "1.1": [ - "PRI-01", - "PRI-01.1", - "PRI-01.4", - "PRI-17.2" - ], - "4.0": [ - "PRI-01.2", - "PRI-02", - "PRI-14.2" - ], - "4.1": [ - "PRI-02.1", - "PRI-14.2" - ], - "2.0": [ - "PRI-03" - ], - "2.1": [ - "PRI-03" - ], - "2.2": [ - "PRI-03" - ], - "2.5": [ - "PRI-03.1", - "PRI-03.3" - ], - "2.3": [ - "PRI-03.2", - "PRI-03.4" - ], - "5.14": [ - "PRI-03.2" - ], - "2.6": [ - "PRI-03.6" - ], - "6.0": [ - "PRI-03.7", - "PRI-06", - "PRI-07.4" - ], - "2.7": [ - "PRI-03.8" - ], - "3.0": [ - "PRI-04" - ], - "3.1": [ - "PRI-04.1" - ], - "1.5": [ - "PRI-05.5", - "PRI-05.6" - ], - "1.7": [ - "PRI-05.7" - ], - "6.3": [ - "PRI-06.1" - ], - "6.4": [ - "PRI-06.2", - "PRI-07.3" - ], - "6.5": [ - "PRI-06.3" - ], - "6.6": [ - "PRI-06.5" - ], - "5.7": [ - "PRI-06.6", - "PRI-06.7" - ], - "10.2": [ - "PRI-07" - ], - "10.3": [ - "PRI-07.1", - "TPM-05", - "TPM-05.2" - ], - "10.4": [ - "PRI-08", - "TPM-04", - "TPM-05.4", - "TPM-05.5", - "TPM-08", - "TPM-09", - "TPM-10" - ], - "5.11": [ - "PRI-10", - "PRI-10.1" - ], - "5.16": [ - "PRI-10.2" - ], - "5.8": [ - "PRI-14", - "PRI-14.1" - ], - "1.3": [ - "PRI-15" - ], - "1.8": [ - "PRI-17" - ], - "1.9": [ - "PRI-17.1" - ], - "1.4": [ - "PRM-01" - ], - "11.0": [ - "PRM-02", - "TPM-01" - ], - "5.12": [ - "PRM-04", - "PRM-05", - "PRM-06", - "PRM-07", - "PRM-08", - "SEA-01", - "TDA-06" - ], - "9.0": [ - "RSK-01", - "RSK-06.2", - "RSK-11" - ], - "9.1": [ - "RSK-04", - "RSK-04.3", - "RSK-04.4" - ], - "9.4": [ - "RSK-06.1" - ], - "9.2": [ - "RSK-08", - "RSK-09", - "RSK-09.1" - ], - "9.5": [ - "RSK-10" - ], - "1.6": [ - "SAT-01", - "SAT-02", - "SAT-02.1", - "SAT-03", - "SAT-03.1", - "SAT-03.2", - "SAT-03.3", - "SAT-03.6", - "SAT-04" - ], - "7.6": [ - "SAT-01" - ], - "7.5": [ - "TDA-17" - ], - "10.0": [ - "TPM-01", - "TPM-04", - "TPM-08", - "TPM-09", - "TPM-10" - ], - "10.1": [ - "TPM-03", - "TPM-04" - ] - } + "total_mappings": 0, + "mappings": {} } } \ No newline at end of file diff --git a/docs/api/crosswalks/general-shared-assessments-sig-2025.json b/docs/api/crosswalks/general-shared-assessments-sig-2025.json index 3ee4c317..775204ec 100644 --- a/docs/api/crosswalks/general-shared-assessments-sig-2025.json +++ b/docs/api/crosswalks/general-shared-assessments-sig-2025.json @@ -1,6 +1,6 @@ { "framework_id": "general-shared-assessments-sig-2025", - "display_name": "SIG (2025)", + "display_name": "Shared Assessments Standard Information Gathering (SIG) Questionnaire 2025", "scf_to_framework": { "total_mappings": 128, "mappings": { diff --git a/docs/api/crosswalks/general-sparta.json b/docs/api/crosswalks/general-sparta.json index 721d6000..f338f395 100644 --- a/docs/api/crosswalks/general-sparta.json +++ b/docs/api/crosswalks/general-sparta.json @@ -1,6 +1,6 @@ { "framework_id": "general-sparta", - "display_name": "SPARTA Countermeasures", + "display_name": "Space Attack Research & Tactic Analysis (SPARTA) Countermeasures", "scf_to_framework": { "total_mappings": 79, "mappings": { diff --git a/docs/api/crosswalks/general-swift-cscf-2025.json b/docs/api/crosswalks/general-swift-cscf-2025.json index 6a26268d..353f8cd6 100644 --- a/docs/api/crosswalks/general-swift-cscf-2025.json +++ b/docs/api/crosswalks/general-swift-cscf-2025.json @@ -1,6 +1,6 @@ { "framework_id": "general-swift-cscf-2025", - "display_name": "SWIFT Customer Security Controls Framework (2025)", + "display_name": "Society for Worldwide Interbank Financial Telecommunication Customer Security Controls Framework 2025", "scf_to_framework": { "total_mappings": 164, "mappings": { diff --git a/docs/api/crosswalks/general-tisax-6-0-3.json b/docs/api/crosswalks/general-tisax-6-0-3.json index 11a045c1..f5343c97 100644 --- a/docs/api/crosswalks/general-tisax-6-0-3.json +++ b/docs/api/crosswalks/general-tisax-6-0-3.json @@ -1,6 +1,6 @@ { "framework_id": "general-tisax-6-0-3", - "display_name": "TISAX ISA (6.0.3)", + "display_name": "Trusted Information Security Assessment Exchange (TISAX) 6.0.3", "scf_to_framework": { "total_mappings": 154, "mappings": { diff --git a/docs/api/crosswalks/general-ul-2900-1-2017.json b/docs/api/crosswalks/general-ul-2900-1-2017.json index e254bad6..1fbbc682 100644 --- a/docs/api/crosswalks/general-ul-2900-1-2017.json +++ b/docs/api/crosswalks/general-ul-2900-1-2017.json @@ -1,6 +1,6 @@ { "framework_id": "general-ul-2900-1-2017", - "display_name": "UL 2900-1 (2017)", + "display_name": "UL 2900 - 1 - Software Cybersecurity for Network - Connectable Products, Part 1: General Requirements (2017)", "scf_to_framework": { "total_mappings": 23, "mappings": { diff --git a/docs/api/crosswalks/general-ul-2900-2-2-2016.json b/docs/api/crosswalks/general-ul-2900-2-2-2016.json index 4bbe06ab..e00e643e 100644 --- a/docs/api/crosswalks/general-ul-2900-2-2-2016.json +++ b/docs/api/crosswalks/general-ul-2900-2-2-2016.json @@ -1,6 +1,6 @@ { "framework_id": "general-ul-2900-2-2-2016", - "display_name": "UL 2900-2-2 (2016)", + "display_name": "UL 2900 - 2 - 2 Ed. 1 - 2016 - Outline of Investigation for Software Cybersecurity for Network - Connectable Products, Part 2 - 2: Particular Requirements for Industrial Control Systems", "scf_to_framework": { "total_mappings": 20, "mappings": { diff --git a/docs/api/crosswalks/general-un-155-2021.json b/docs/api/crosswalks/general-un-155-2021.json index c1df57d3..e753ddf4 100644 --- a/docs/api/crosswalks/general-un-155-2021.json +++ b/docs/api/crosswalks/general-un-155-2021.json @@ -1,6 +1,6 @@ { "framework_id": "general-un-155-2021", - "display_name": "UN Regulation No. 155 (2021)", + "display_name": "United Nations - Regulation No. 155 - Cyber security and cyber security management system (2021)", "scf_to_framework": { "total_mappings": 57, "mappings": { diff --git a/docs/api/crosswalks/general-un-ece-wp-29-2020.json b/docs/api/crosswalks/general-un-ece-wp-29-2020.json index 095ea0a2..b2302657 100644 --- a/docs/api/crosswalks/general-un-ece-wp-29-2020.json +++ b/docs/api/crosswalks/general-un-ece-wp-29-2020.json @@ -1,6 +1,6 @@ { "framework_id": "general-un-ece-wp-29-2020", - "display_name": "UNECE WP.29 (2020)", + "display_name": "United Nations - United Nations Economic Commission for Europe (UNECE) Working Party 29 (2020)", "scf_to_framework": { "total_mappings": 57, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-cms-marse-2-0.json b/docs/api/crosswalks/usa-federal-cms-marse-2-0.json index 4270c562..5ffff529 100644 --- a/docs/api/crosswalks/usa-federal-cms-marse-2-0.json +++ b/docs/api/crosswalks/usa-federal-cms-marse-2-0.json @@ -1,8 +1,8 @@ { "framework_id": "usa-federal-cms-marse-2-0", - "display_name": "MARS-E Document Suite (2.0)", + "display_name": "US - Centers for Medicare & Medicaid Services MARS - E Document Suite, Version 2.0", "scf_to_framework": { - "total_mappings": 391, + "total_mappings": 392, "mappings": { "GOV-01": [ "PM-1", @@ -254,6 +254,9 @@ "CP-10-IS.1.d", "CP-10-IS.1.e" ], + "BCD-12.1": [ + "CP-10(2)" + ], "CAP-01": [ "SC-5" ], @@ -2249,7 +2252,7 @@ } }, "framework_to_scf": { - "total_mappings": 1286, + "total_mappings": 1287, "mappings": { "PM-1": [ "GOV-01", @@ -2752,6 +2755,9 @@ "CP-10-IS.1.e": [ "BCD-12" ], + "CP-10(2)": [ + "BCD-12.1" + ], "SC-5": [ "CAP-01", "CAP-02", diff --git a/docs/api/crosswalks/usa-federal-dhs-cisa-cpg-2-0.json b/docs/api/crosswalks/usa-federal-dhs-cisa-cpg-2-0.json index 9cbe1e79..ca9845f3 100644 --- a/docs/api/crosswalks/usa-federal-dhs-cisa-cpg-2-0.json +++ b/docs/api/crosswalks/usa-federal-dhs-cisa-cpg-2-0.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dhs-cisa-cpg-2-0", - "display_name": "CISA Cross-Sector Cybersecurity Performance Goals (CPG) (2.0)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Cross - Sector Cybersecurity Performance Goals 2.0", "scf_to_framework": { "total_mappings": 126, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dhs-cisa-ssdaf-2024.json b/docs/api/crosswalks/usa-federal-dhs-cisa-ssdaf-2024.json index 9012eb03..a1f0ef2e 100644 --- a/docs/api/crosswalks/usa-federal-dhs-cisa-ssdaf-2024.json +++ b/docs/api/crosswalks/usa-federal-dhs-cisa-ssdaf-2024.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dhs-cisa-ssdaf-2024", - "display_name": "CISA Secure Software Development Attestation Form (SSDAF) (2024)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Secure Software Development Attestation Form (SSDAF) (2024)", "scf_to_framework": { "total_mappings": 41, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dhs-cisa-tic-3-0.json b/docs/api/crosswalks/usa-federal-dhs-cisa-tic-3-0.json index ea723f03..83817888 100644 --- a/docs/api/crosswalks/usa-federal-dhs-cisa-tic-3-0.json +++ b/docs/api/crosswalks/usa-federal-dhs-cisa-tic-3-0.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dhs-cisa-tic-3-0", - "display_name": "CISA Trusted Internet Connections 3.0 Security Capabilities Catalog (TIC 3.0)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Trusted Internet Connections 3.0 Security Capabilities Catalog", "scf_to_framework": { "total_mappings": 148, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-doc-data-privacy-framework-2023.json b/docs/api/crosswalks/usa-federal-doc-data-privacy-framework-2023.json index 4f9575cc..b247e62e 100644 --- a/docs/api/crosswalks/usa-federal-doc-data-privacy-framework-2023.json +++ b/docs/api/crosswalks/usa-federal-doc-data-privacy-framework-2023.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-doc-data-privacy-framework-2023", - "display_name": "Data Privacy Framework (2023)", + "display_name": "US - Data Privacy Framework (2023)", "scf_to_framework": { "total_mappings": 31, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-doe-c2m2-2-1.json b/docs/api/crosswalks/usa-federal-doe-c2m2-2-1.json index 4c1f1dd5..21248f73 100644 --- a/docs/api/crosswalks/usa-federal-doe-c2m2-2-1.json +++ b/docs/api/crosswalks/usa-federal-doe-c2m2-2-1.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-doe-c2m2-2-1", - "display_name": "Cybersecurity Capability Maturity Model (C2M2) (v2.1)", + "display_name": "US - Department of Energy (DOE) - Cybersecurity Capability Maturity Model version 2.1", "scf_to_framework": { "total_mappings": 224, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dow-cert-rmm-1-2.json b/docs/api/crosswalks/usa-federal-dow-cert-rmm-1-2.json index d0f36b28..28e7ebff 100644 --- a/docs/api/crosswalks/usa-federal-dow-cert-rmm-1-2.json +++ b/docs/api/crosswalks/usa-federal-dow-cert-rmm-1-2.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-cert-rmm-1-2", - "display_name": "CERT-RMM (v1.2)", + "display_name": "US - Department of War (DoW) - Computer Emergency Response Team (CERT) Resilience Management Model (RMM) Version 1.2", "scf_to_framework": { "total_mappings": 85, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-1-aos.json b/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-1-aos.json index 0104ba7b..d39c6ae8 100644 --- a/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-1-aos.json +++ b/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-1-aos.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-cmmc-2-level-1-aos", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1 Assessment Objectives", + "display_name": "US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1 Assessment Objectives", "scf_to_framework": { "total_mappings": 16, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-1.json b/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-1.json index 9938b892..be64fb60 100644 --- a/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-1.json +++ b/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-1.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-cmmc-2-level-1", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1", + "display_name": "US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1", "scf_to_framework": { "total_mappings": 52, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-2.json b/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-2.json index 67039401..00a66a2c 100644 --- a/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-2.json +++ b/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-2.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-cmmc-2-level-2", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 2", + "display_name": "US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 2", "scf_to_framework": { "total_mappings": 198, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-3.json b/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-3.json index 84b668c2..d0ebd888 100644 --- a/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-3.json +++ b/docs/api/crosswalks/usa-federal-dow-cmmc-2-level-3.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-cmmc-2-level-3", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 3", + "display_name": "US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 3", "scf_to_framework": { "total_mappings": 55, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dow-dfars-252-204-7012.json b/docs/api/crosswalks/usa-federal-dow-dfars-252-204-7012.json index 7c53ee85..3c3e8d11 100644 --- a/docs/api/crosswalks/usa-federal-dow-dfars-252-204-7012.json +++ b/docs/api/crosswalks/usa-federal-dow-dfars-252-204-7012.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-dfars-252-204-7012", - "display_name": "DFARS 252.204-7012", + "display_name": "US - Defense Federal Acquisition Regulation Supplement (DFARS) 252.204 - 7012", "scf_to_framework": { "total_mappings": 19, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dow-safeguarding-nnpi-2010.json b/docs/api/crosswalks/usa-federal-dow-safeguarding-nnpi-2010.json index bcab865a..efb0562b 100644 --- a/docs/api/crosswalks/usa-federal-dow-safeguarding-nnpi-2010.json +++ b/docs/api/crosswalks/usa-federal-dow-safeguarding-nnpi-2010.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-safeguarding-nnpi-2010", - "display_name": "Safeguarding of NNPI (2010)", + "display_name": "US - Safeguarding of Naval Nuclear Propulsion Information (NNPI) (2010)", "scf_to_framework": { "total_mappings": 32, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-dow-zt-roadmap-1-1.json b/docs/api/crosswalks/usa-federal-dow-zt-roadmap-1-1.json index 569ea214..56e40e68 100644 --- a/docs/api/crosswalks/usa-federal-dow-zt-roadmap-1-1.json +++ b/docs/api/crosswalks/usa-federal-dow-zt-roadmap-1-1.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-zt-roadmap-1-1", - "display_name": "Department of War (DoW) - Zero Trust Execution Roadmap (v1.1)", + "display_name": "US - Department of War (DoW) - Zero Trust Execution Roadmap v1.1", "scf_to_framework": { "total_mappings": 117, "mappings": { @@ -82,6 +82,7 @@ "6.6.3" ], "CLD-04.1": [ + "3.4", "3.4.1" ], "CLD-09": [ @@ -553,7 +554,7 @@ } }, "framework_to_scf": { - "total_mappings": 190, + "total_mappings": 191, "mappings": { "6.1.1": [ "GOV-02" @@ -684,6 +685,9 @@ "CLD-04", "CFG-02" ], + "3.4": [ + "CLD-04.1" + ], "3.4.1": [ "CLD-04.1" ], diff --git a/docs/api/crosswalks/usa-federal-dow-zta-reference-architecture-2-0.json b/docs/api/crosswalks/usa-federal-dow-zta-reference-architecture-2-0.json index ef203340..6b65ad65 100644 --- a/docs/api/crosswalks/usa-federal-dow-zta-reference-architecture-2-0.json +++ b/docs/api/crosswalks/usa-federal-dow-zta-reference-architecture-2-0.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-dow-zta-reference-architecture-2-0", - "display_name": "Department of War (DoW) - Zero Trust Reference Architecture (v2)", + "display_name": "US - Department of War (DoW) - Zero Trust Reference Architecture v2", "scf_to_framework": { "total_mappings": 39, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-eo-14028.json b/docs/api/crosswalks/usa-federal-eo-14028.json index 5a82f62a..eb9f1a34 100644 --- a/docs/api/crosswalks/usa-federal-eo-14028.json +++ b/docs/api/crosswalks/usa-federal-eo-14028.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-eo-14028", - "display_name": "Executive Order 14028 - Improving the Nation's Cybersecurity", + "display_name": "US - Executive Order (EO) 14028 - Improving the Nation's Cybersecurity", "scf_to_framework": { "total_mappings": 43, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-far-52-204-21.json b/docs/api/crosswalks/usa-federal-far-52-204-21.json index f7cce53c..b541f699 100644 --- a/docs/api/crosswalks/usa-federal-far-52-204-21.json +++ b/docs/api/crosswalks/usa-federal-far-52-204-21.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-far-52-204-21", - "display_name": "FAR 52.204-21", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 21 - Basic Safeguarding of Covered Contractor Information Systems", "scf_to_framework": { "total_mappings": 59, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-far-52-204-25.json b/docs/api/crosswalks/usa-federal-far-52-204-25.json index fa489a28..afb2e5d9 100644 --- a/docs/api/crosswalks/usa-federal-far-52-204-25.json +++ b/docs/api/crosswalks/usa-federal-far-52-204-25.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-far-52-204-25", - "display_name": "FAR 52.204-25 (NDAA Section 889)", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 25 (NDAA Section 889) - Prohibition on Contracting With Entities Using Certain Telecommunications and Video Surveillance Services or Equipment", "scf_to_framework": { "total_mappings": 2, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-far-52-204-27.json b/docs/api/crosswalks/usa-federal-far-52-204-27.json index e13aaf91..6cebe4c5 100644 --- a/docs/api/crosswalks/usa-federal-far-52-204-27.json +++ b/docs/api/crosswalks/usa-federal-far-52-204-27.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-far-52-204-27", - "display_name": "FAR 52.204-27", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 27 - Prohibition on a ByteDance Covered Application", "scf_to_framework": { "total_mappings": 3, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-fbi-cjis-6-0.json b/docs/api/crosswalks/usa-federal-fbi-cjis-6-0.json index 8e9d9a1a..7273008c 100644 --- a/docs/api/crosswalks/usa-federal-fbi-cjis-6-0.json +++ b/docs/api/crosswalks/usa-federal-fbi-cjis-6-0.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-fbi-cjis-6-0", - "display_name": "Criminal Justice Information Services (CJIS) Security Policy (v6.0)", + "display_name": "US - Department of Justice - Criminal Justice Information Services (CJIS) Security Policy v6.0", "scf_to_framework": { "total_mappings": 365, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-fda-21-cfr-part-11-2025.json b/docs/api/crosswalks/usa-federal-fda-21-cfr-part-11-2025.json index bdce065c..2ce3d1b7 100644 --- a/docs/api/crosswalks/usa-federal-fda-21-cfr-part-11-2025.json +++ b/docs/api/crosswalks/usa-federal-fda-21-cfr-part-11-2025.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-fda-21-cfr-part-11-2025", - "display_name": "Food & Drug Administration (FDA) 21 CFR Part 11 (2025)", + "display_name": "US - Food & Drug Administration (FDA) 21 CFR Part 11 (2025)", "scf_to_framework": { "total_mappings": 62, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-gsa-fedramp-5-high.json b/docs/api/crosswalks/usa-federal-gsa-fedramp-5-high.json index 1ea03ab9..ba6e2f88 100644 --- a/docs/api/crosswalks/usa-federal-gsa-fedramp-5-high.json +++ b/docs/api/crosswalks/usa-federal-gsa-fedramp-5-high.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-gsa-fedramp-5-high", - "display_name": "FedRAMP R5 - High Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - High Baseline", "scf_to_framework": { "total_mappings": 561, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-gsa-fedramp-5-li-saas.json b/docs/api/crosswalks/usa-federal-gsa-fedramp-5-li-saas.json index 414ba043..604ab54e 100644 --- a/docs/api/crosswalks/usa-federal-gsa-fedramp-5-li-saas.json +++ b/docs/api/crosswalks/usa-federal-gsa-fedramp-5-li-saas.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-gsa-fedramp-5-li-saas", - "display_name": "FedRAMP R5 - Li-SAAS Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Li - SAAS Baseline", "scf_to_framework": { "total_mappings": 383, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-gsa-fedramp-5-low.json b/docs/api/crosswalks/usa-federal-gsa-fedramp-5-low.json index c3b5c175..bba41146 100644 --- a/docs/api/crosswalks/usa-federal-gsa-fedramp-5-low.json +++ b/docs/api/crosswalks/usa-federal-gsa-fedramp-5-low.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-gsa-fedramp-5-low", - "display_name": "FedRAMP R5 - Low Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Low Baseline", "scf_to_framework": { "total_mappings": 383, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-gsa-fedramp-5-mod.json b/docs/api/crosswalks/usa-federal-gsa-fedramp-5-mod.json index 16515fb5..d94463d1 100644 --- a/docs/api/crosswalks/usa-federal-gsa-fedramp-5-mod.json +++ b/docs/api/crosswalks/usa-federal-gsa-fedramp-5-mod.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-gsa-fedramp-5-mod", - "display_name": "FedRAMP R5 - Moderate Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Moderate Baseline", "scf_to_framework": { "total_mappings": 491, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-hhs-45-cfr-155-260-2016.json b/docs/api/crosswalks/usa-federal-hhs-45-cfr-155-260-2016.json index fe576f28..6b0a75b0 100644 --- a/docs/api/crosswalks/usa-federal-hhs-45-cfr-155-260-2016.json +++ b/docs/api/crosswalks/usa-federal-hhs-45-cfr-155-260-2016.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-hhs-45-cfr-155-260-2016", - "display_name": "HHS § 155.260 (2016)", + "display_name": "US - Health and Human Services (HHS) § 155.260 - Privacy and Security of Personally Identifiable Information (2016)", "scf_to_framework": { "total_mappings": 36, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-irs-1075-2021.json b/docs/api/crosswalks/usa-federal-irs-1075-2021.json index 09e4c8b6..04623644 100644 --- a/docs/api/crosswalks/usa-federal-irs-1075-2021.json +++ b/docs/api/crosswalks/usa-federal-irs-1075-2021.json @@ -1,8 +1,8 @@ { "framework_id": "usa-federal-irs-1075-2021", - "display_name": "IRS 1075 (2021)", + "display_name": "US - Internal Revenue Service (IRS) 1075 (2021)", "scf_to_framework": { - "total_mappings": 442, + "total_mappings": 443, "mappings": { "GOV-01": [ "PM-1" @@ -1382,8 +1382,12 @@ "PE-8" ], "PES-04": [ + "2.B.3", "2.B.3.3" ], + "PES-04.1": [ + "2.B.3" + ], "PES-05": [ "PE-6" ], @@ -1834,7 +1838,7 @@ } }, "framework_to_scf": { - "total_mappings": 743, + "total_mappings": 744, "mappings": { "PM-1": [ "GOV-01", @@ -3813,6 +3817,10 @@ "PE-8": [ "PES-03.3" ], + "2.B.3": [ + "PES-04", + "PES-04.1" + ], "2.B.3.3": [ "PES-04" ], diff --git a/docs/api/crosswalks/usa-federal-law-33-cfr-part-101-subpart-f.json b/docs/api/crosswalks/usa-federal-law-33-cfr-part-101-subpart-f.json new file mode 100644 index 00000000..5d24faad --- /dev/null +++ b/docs/api/crosswalks/usa-federal-law-33-cfr-part-101-subpart-f.json @@ -0,0 +1,920 @@ +{ + "framework_id": "usa-federal-law-33-cfr-part-101-subpart-f", + "display_name": "US - 33 CFR Part 101 Subpart F (up to date as of 4 - 17 - 2026)", + "scf_to_framework": { + "total_mappings": 104, + "mappings": { + "GOV-01": [ + "101.620(b)(1)" + ], + "GOV-01.2": [ + "101.625(d)(14)", + "101.645(a)" + ], + "GOV-02": [ + "101.625(d)(5)" + ], + "GOV-02.1": [ + "101.625(d)(14)" + ], + "GOV-03": [ + "101.625(d)(5)" + ], + "GOV-04": [ + "101.620(b)(2)", + "101.620(b)(3)", + "101.625(c)" + ], + "GOV-04.1": [ + "101.620(b)(2)" + ], + "GOV-15": [ + "101.625(d)(2)", + "101.625(d)(5)", + "101.650(c)" + ], + "GOV-15.1": [ + "101.625(d)(2)" + ], + "GOV-15.2": [ + "101.625(d)(2)" + ], + "GOV-15.3": [ + "101.625(d)(2)" + ], + "GOV-17": [ + "101.625(d)(12)", + "101.625(d)(13)", + "101.630(d)", + "101.630(e)(2)", + "101.630(e)(2)(ii)", + "101.630(e)(3)", + "101.630(e)(4)", + "101.630(f)(3)", + "101.630(f)(5)" + ], + "AST-01": [ + "101.650(i)(2)" + ], + "AST-01.4": [ + "101.650(b)(1)" + ], + "AST-01.5": [ + "101.650(i)(2)" + ], + "AST-02": [ + "101.650(b)(3)" + ], + "AST-02.2": [ + "101.650(i)(2)" + ], + "AST-04": [ + "101.650(b)(4)" + ], + "BCD-11": [ + "101.650(g)(4)" + ], + "CAP-01": [ + "101.650(f)(1)" + ], + "CPL-01": [ + "101.620(a)", + "101.620(b)(4)", + "101.620(b)(5)", + "101.650(b)", + "101.650(e)", + "101.650(e)(3)", + "101.650(f)", + "101.650(g)", + "101.650(h)", + "101.650(i)" + ], + "CPL-01.2": [ + "101.605(a)", + "101.605(b)", + "101.625(d)", + "101.630(d)(2)" + ], + "CPL-01.3": [ + "101.625(d)(6)", + "101.660" + ], + "CPL-01.4": [ + "101.650(g)(3)" + ], + "CPL-01.6": [ + "101.630(f)(4)", + "101.630(f)(4)(i)" + ], + "CPL-02": [ + "101.625(d)(7)" + ], + "CPL-02.2": [ + "101.625(d)(3)" + ], + "CPL-02.3": [ + "101.625(d)(7)" + ], + "CPL-03": [ + "101.630(f)(1)", + "101.630(f)(2)" + ], + "CPL-03.1": [ + "101.630(f)(4)(ii)", + "101.630(f)(4)(iii)" + ], + "CPL-05.2": [ + "101.625(d)(6)" + ], + "CPL-13": [ + "101.640" + ], + "CFG-02": [ + "101.650(b)(2)", + "101.650(c)(2)" + ], + "CFG-02.5": [ + "101.650(b)(2)" + ], + "MON-01": [ + "101.650(c)(1)", + "101.650(f)(3)" + ], + "MON-01.3": [ + "101.650(f)(3)", + "101.650(h)(2)" + ], + "MON-01.4": [ + "101.650(c)(1)", + "101.650(h)(2)" + ], + "MON-01.8": [ + "101.650(c)(1)" + ], + "MON-08": [ + "101.650(c)(1)" + ], + "MON-08.2": [ + "101.650(c)(1)" + ], + "MON-10": [ + "101.650(c)(1)" + ], + "CRY-01": [ + "101.650(c)(2)" + ], + "CRY-03": [ + "101.650(c)(2)" + ], + "CRY-05": [ + "101.650(c)(2)" + ], + "DCH-01": [ + "101.630(b)" + ], + "DCH-01.4": [ + "101.630(b)" + ], + "DCH-18": [ + "101.625(d)(11)", + "101.640" + ], + "EMB-03": [ + "101.650(e)(3)(v)" + ], + "HRS-01.1": [ + "101.650(a)(7)" + ], + "HRS-02": [ + "101.625(a)" + ], + "HRS-03": [ + "101.620(b)(2)", + "101.625(a)" + ], + "HRS-03.1": [ + "101.625(d)(8)" + ], + "HRS-03.2": [ + "101.625(e)", + "101.625(e)(1)", + "101.625(e)(2)", + "101.625(e)(3)", + "101.625(e)(4)", + "101.625(e)(5)", + "101.625(e)(6)", + "101.625(e)(7)", + "101.625(e)(8)", + "101.625(e)(9)", + "101.625(e)(10)", + "101.625(e)(11)", + "101.625(e)(12)" + ], + "HRS-04.2": [ + "101.625(d)(8)" + ], + "HRS-11": [ + "101.650(a)(6)" + ], + "IAC-01": [ + "101.650(a)" + ], + "IAC-06": [ + "101.650(a)(4)" + ], + "IAC-07": [ + "101.650(a)(7)" + ], + "IAC-10.1": [ + "101.650(a)(3)" + ], + "IAC-10.8": [ + "101.650(a)(2)" + ], + "IAC-15.10": [ + "101.650(a)(6)" + ], + "IAC-16.2": [ + "101.650(a)(6)" + ], + "IAC-21": [ + "101.650(a)(5)" + ], + "IAC-22": [ + "101.650(a)(1)" + ], + "IRO-02": [ + "101.625(d)(4)" + ], + "IRO-04": [ + "101.620(b)(6)", + "101.650(g)(2)" + ], + "IRO-06": [ + "101.635(a)(1)", + "101.635(b)(1)", + "101.635(b)(2)", + "101.635(b)(3)", + "101.635(c)(1)", + "101.635(c)(2)", + "101.635(c)(2)(i)", + "101.635(c)(2)(ii)", + "101.635(c)(2)(iii)", + "101.635(c)(2)(iv)", + "101.635(c)(3)", + "101.635(c)(4)", + "101.635(c)(5)" + ], + "IRO-06.1": [ + "101.635(a)(1)" + ], + "IRO-10": [ + "101.625(d)(10)" + ], + "IRO-10.2": [ + "101.620(b)(7)", + "101.625(d)(10)", + "101.650(g)(1)" + ], + "IRO-10.5": [ + "101.625(d)(10)" + ], + "IRO-13": [ + "101.635(c)(6)" + ], + "IRO-14": [ + "101.620(b)(3)" + ], + "IAO-02": [ + "101.650(e)(1)", + "101.650(e)(1)(i)", + "101.650(e)(1)(ii)" + ], + "IAO-02.4": [ + "101.650(e)(1)(iii)" + ], + "IAO-03": [ + "101.625(d)(5)", + "101.630(a)", + "101.630(c)", + "101.630(c)(1)", + "101.630(c)(2)", + "101.630(c)(3)", + "101.630(c)(4)", + "101.630(c)(5)", + "101.630(c)(6)", + "101.630(c)(7)", + "101.630(c)(8)", + "101.630(c)(9)", + "101.630(c)(10)", + "101.630(c)(11)", + "101.630(c)(12)", + "101.630(c)(13)", + "101.630(c)(14)", + "101.650(c)", + "101.650(e)(1)(v)" + ], + "IAO-05": [ + "101.650(e)(1)(iv)" + ], + "MNT-06.1": [ + "101.650(d)(3)" + ], + "MNT-06.2": [ + "101.650(d)(3)" + ], + "NET-06": [ + "101.650(h)(1)" + ], + "NET-06.5": [ + "101.650(e)(3)(iv)", + "101.650(e)(3)(v)" + ], + "PES-02": [ + "101.650(i)(1)" + ], + "PES-02.1": [ + "101.650(i)(1)" + ], + "PES-03": [ + "101.650(i)(1)" + ], + "PES-06.3": [ + "101.650(d)(3)" + ], + "RSK-04": [ + "101.625(d)(1)" + ], + "SEA-02.1": [ + "101.615" + ], + "SEA-03": [ + "101.650(e)(3)(iv)" + ], + "SAT-01": [ + "101.625(d)(8)", + "101.650(d)" + ], + "SAT-01.1": [ + "101.625(d)(8)" + ], + "SAT-02": [ + "101.625(d)(9)", + "101.650(d)(1)", + "101.650(d)(1)(i)", + "101.650(d)(1)(ii)", + "101.650(d)(1)(iii)", + "101.650(d)(1)(iv)" + ], + "SAT-03": [ + "101.625(d)(9)", + "101.650(d)(1)(v)", + "101.650(d)(2)", + "101.650(d)(2)(i)", + "101.650(d)(2)(ii)", + "101.650(d)(4)" + ], + "SAT-03.6": [ + "101.625(d)(8)" + ], + "SAT-04": [ + "101.650(d)(4)" + ], + "TPM-05": [ + "101.650(f)(2)" + ], + "THR-03": [ + "101.650(e)(3)(ii)" + ], + "THR-03.1": [ + "101.625(d)(8)", + "101.625(d)(14)", + "101.650(e)(3)(iii)" + ], + "VPM-01.1": [ + "101.625(d)(15)" + ], + "VPM-02": [ + "101.625(d)(15)" + ], + "VPM-03": [ + "101.625(d)(15)" + ], + "VPM-05": [ + "101.625(d)(15)", + "101.650(e)(3)(i)" + ], + "VPM-05.4": [ + "101.650(e)(3)(ii)" + ], + "VPM-06": [ + "101.650(e)(3)(vi)" + ], + "VPM-07": [ + "101.650(e)(2)" + ] + } + }, + "framework_to_scf": { + "total_mappings": 148, + "mappings": { + "101.620(b)(1)": [ + "GOV-01" + ], + "101.625(d)(14)": [ + "GOV-01.2", + "GOV-02.1", + "THR-03.1" + ], + "101.645(a)": [ + "GOV-01.2" + ], + "101.625(d)(5)": [ + "GOV-02", + "GOV-03", + "GOV-15", + "IAO-03" + ], + "101.620(b)(2)": [ + "GOV-04", + "GOV-04.1", + "HRS-03" + ], + "101.620(b)(3)": [ + "GOV-04", + "IRO-14" + ], + "101.625(c)": [ + "GOV-04" + ], + "101.625(d)(2)": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2", + "GOV-15.3" + ], + "101.650(c)": [ + "GOV-15", + "IAO-03" + ], + "101.625(d)(12)": [ + "GOV-17" + ], + "101.625(d)(13)": [ + "GOV-17" + ], + "101.630(d)": [ + "GOV-17" + ], + "101.630(e)(2)": [ + "GOV-17" + ], + "101.630(e)(2)(ii)": [ + "GOV-17" + ], + "101.630(e)(3)": [ + "GOV-17" + ], + "101.630(e)(4)": [ + "GOV-17" + ], + "101.630(f)(3)": [ + "GOV-17" + ], + "101.630(f)(5)": [ + "GOV-17" + ], + "101.650(i)(2)": [ + "AST-01", + "AST-01.5", + "AST-02.2" + ], + "101.650(b)(1)": [ + "AST-01.4" + ], + "101.650(b)(3)": [ + "AST-02" + ], + "101.650(b)(4)": [ + "AST-04" + ], + "101.650(g)(4)": [ + "BCD-11" + ], + "101.650(f)(1)": [ + "CAP-01" + ], + "101.620(a)": [ + "CPL-01" + ], + "101.620(b)(4)": [ + "CPL-01" + ], + "101.620(b)(5)": [ + "CPL-01" + ], + "101.650(b)": [ + "CPL-01" + ], + "101.650(e)": [ + "CPL-01" + ], + "101.650(e)(3)": [ + "CPL-01" + ], + "101.650(f)": [ + "CPL-01" + ], + "101.650(g)": [ + "CPL-01" + ], + "101.650(h)": [ + "CPL-01" + ], + "101.650(i)": [ + "CPL-01" + ], + "101.605(a)": [ + "CPL-01.2" + ], + "101.605(b)": [ + "CPL-01.2" + ], + "101.625(d)": [ + "CPL-01.2" + ], + "101.630(d)(2)": [ + "CPL-01.2" + ], + "101.625(d)(6)": [ + "CPL-01.3", + "CPL-05.2" + ], + "101.660": [ + "CPL-01.3" + ], + "101.650(g)(3)": [ + "CPL-01.4" + ], + "101.630(f)(4)": [ + "CPL-01.6" + ], + "101.630(f)(4)(i)": [ + "CPL-01.6" + ], + "101.625(d)(7)": [ + "CPL-02", + "CPL-02.3" + ], + "101.625(d)(3)": [ + "CPL-02.2" + ], + "101.630(f)(1)": [ + "CPL-03" + ], + "101.630(f)(2)": [ + "CPL-03" + ], + "101.630(f)(4)(ii)": [ + "CPL-03.1" + ], + "101.630(f)(4)(iii)": [ + "CPL-03.1" + ], + "101.640": [ + "CPL-13", + "DCH-18" + ], + "101.650(b)(2)": [ + "CFG-02", + "CFG-02.5" + ], + "101.650(c)(2)": [ + "CFG-02", + "CRY-01", + "CRY-03", + "CRY-05" + ], + "101.650(c)(1)": [ + "MON-01", + "MON-01.4", + "MON-01.8", + "MON-08", + "MON-08.2", + "MON-10" + ], + "101.650(f)(3)": [ + "MON-01", + "MON-01.3" + ], + "101.650(h)(2)": [ + "MON-01.3", + "MON-01.4" + ], + "101.630(b)": [ + "DCH-01", + "DCH-01.4" + ], + "101.625(d)(11)": [ + "DCH-18" + ], + "101.650(e)(3)(v)": [ + "EMB-03", + "NET-06.5" + ], + "101.650(a)(7)": [ + "HRS-01.1", + "IAC-07" + ], + "101.625(a)": [ + "HRS-02", + "HRS-03" + ], + "101.625(d)(8)": [ + "HRS-03.1", + "HRS-04.2", + "SAT-01", + "SAT-01.1", + "SAT-03.6", + "THR-03.1" + ], + "101.625(e)": [ + "HRS-03.2" + ], + "101.625(e)(1)": [ + "HRS-03.2" + ], + "101.625(e)(2)": [ + "HRS-03.2" + ], + "101.625(e)(3)": [ + "HRS-03.2" + ], + "101.625(e)(4)": [ + "HRS-03.2" + ], + "101.625(e)(5)": [ + "HRS-03.2" + ], + "101.625(e)(6)": [ + "HRS-03.2" + ], + "101.625(e)(7)": [ + "HRS-03.2" + ], + "101.625(e)(8)": [ + "HRS-03.2" + ], + "101.625(e)(9)": [ + "HRS-03.2" + ], + "101.625(e)(10)": [ + "HRS-03.2" + ], + "101.625(e)(11)": [ + "HRS-03.2" + ], + "101.625(e)(12)": [ + "HRS-03.2" + ], + "101.650(a)(6)": [ + "HRS-11", + "IAC-15.10", + "IAC-16.2" + ], + "101.650(a)": [ + "IAC-01" + ], + "101.650(a)(4)": [ + "IAC-06" + ], + "101.650(a)(3)": [ + "IAC-10.1" + ], + "101.650(a)(2)": [ + "IAC-10.8" + ], + "101.650(a)(5)": [ + "IAC-21" + ], + "101.650(a)(1)": [ + "IAC-22" + ], + "101.625(d)(4)": [ + "IRO-02" + ], + "101.620(b)(6)": [ + "IRO-04" + ], + "101.650(g)(2)": [ + "IRO-04" + ], + "101.635(a)(1)": [ + "IRO-06", + "IRO-06.1" + ], + "101.635(b)(1)": [ + "IRO-06" + ], + "101.635(b)(2)": [ + "IRO-06" + ], + "101.635(b)(3)": [ + "IRO-06" + ], + "101.635(c)(1)": [ + "IRO-06" + ], + "101.635(c)(2)": [ + "IRO-06" + ], + "101.635(c)(2)(i)": [ + "IRO-06" + ], + "101.635(c)(2)(ii)": [ + "IRO-06" + ], + "101.635(c)(2)(iii)": [ + "IRO-06" + ], + "101.635(c)(2)(iv)": [ + "IRO-06" + ], + "101.635(c)(3)": [ + "IRO-06" + ], + "101.635(c)(4)": [ + "IRO-06" + ], + "101.635(c)(5)": [ + "IRO-06" + ], + "101.625(d)(10)": [ + "IRO-10", + "IRO-10.2", + "IRO-10.5" + ], + "101.620(b)(7)": [ + "IRO-10.2" + ], + "101.650(g)(1)": [ + "IRO-10.2" + ], + "101.635(c)(6)": [ + "IRO-13" + ], + "101.650(e)(1)": [ + "IAO-02" + ], + "101.650(e)(1)(i)": [ + "IAO-02" + ], + "101.650(e)(1)(ii)": [ + "IAO-02" + ], + "101.650(e)(1)(iii)": [ + "IAO-02.4" + ], + "101.630(a)": [ + "IAO-03" + ], + "101.630(c)": [ + "IAO-03" + ], + "101.630(c)(1)": [ + "IAO-03" + ], + "101.630(c)(2)": [ + "IAO-03" + ], + "101.630(c)(3)": [ + "IAO-03" + ], + "101.630(c)(4)": [ + "IAO-03" + ], + "101.630(c)(5)": [ + "IAO-03" + ], + "101.630(c)(6)": [ + "IAO-03" + ], + "101.630(c)(7)": [ + "IAO-03" + ], + "101.630(c)(8)": [ + "IAO-03" + ], + "101.630(c)(9)": [ + "IAO-03" + ], + "101.630(c)(10)": [ + "IAO-03" + ], + "101.630(c)(11)": [ + "IAO-03" + ], + "101.630(c)(12)": [ + "IAO-03" + ], + "101.630(c)(13)": [ + "IAO-03" + ], + "101.630(c)(14)": [ + "IAO-03" + ], + "101.650(e)(1)(v)": [ + "IAO-03" + ], + "101.650(e)(1)(iv)": [ + "IAO-05" + ], + "101.650(d)(3)": [ + "MNT-06.1", + "MNT-06.2", + "PES-06.3" + ], + "101.650(h)(1)": [ + "NET-06" + ], + "101.650(e)(3)(iv)": [ + "NET-06.5", + "SEA-03" + ], + "101.650(i)(1)": [ + "PES-02", + "PES-02.1", + "PES-03" + ], + "101.625(d)(1)": [ + "RSK-04" + ], + "101.615": [ + "SEA-02.1" + ], + "101.650(d)": [ + "SAT-01" + ], + "101.625(d)(9)": [ + "SAT-02", + "SAT-03" + ], + "101.650(d)(1)": [ + "SAT-02" + ], + "101.650(d)(1)(i)": [ + "SAT-02" + ], + "101.650(d)(1)(ii)": [ + "SAT-02" + ], + "101.650(d)(1)(iii)": [ + "SAT-02" + ], + "101.650(d)(1)(iv)": [ + "SAT-02" + ], + "101.650(d)(1)(v)": [ + "SAT-03" + ], + "101.650(d)(2)": [ + "SAT-03" + ], + "101.650(d)(2)(i)": [ + "SAT-03" + ], + "101.650(d)(2)(ii)": [ + "SAT-03" + ], + "101.650(d)(4)": [ + "SAT-03", + "SAT-04" + ], + "101.650(f)(2)": [ + "TPM-05" + ], + "101.650(e)(3)(ii)": [ + "THR-03", + "VPM-05.4" + ], + "101.650(e)(3)(iii)": [ + "THR-03.1" + ], + "101.625(d)(15)": [ + "VPM-01.1", + "VPM-02", + "VPM-03", + "VPM-05" + ], + "101.650(e)(3)(i)": [ + "VPM-05" + ], + "101.650(e)(3)(vi)": [ + "VPM-06" + ], + "101.650(e)(2)": [ + "VPM-07" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/usa-federal-law-coppa-2024.json b/docs/api/crosswalks/usa-federal-law-coppa-2024.json index cd4ac285..dd035a60 100644 --- a/docs/api/crosswalks/usa-federal-law-coppa-2024.json +++ b/docs/api/crosswalks/usa-federal-law-coppa-2024.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-law-coppa-2024", - "display_name": "Children's Online Privacy Protection Act (COPPA) (2024)", + "display_name": "US - Children's Online Privacy Protection Act (COPPA) (2024)", "scf_to_framework": { "total_mappings": 10, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-law-facta-fcra-2023.json b/docs/api/crosswalks/usa-federal-law-facta-fcra-2023.json index b0890611..11074109 100644 --- a/docs/api/crosswalks/usa-federal-law-facta-fcra-2023.json +++ b/docs/api/crosswalks/usa-federal-law-facta-fcra-2023.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-law-facta-fcra-2023", - "display_name": "Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023)", + "display_name": "US - Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023)", "scf_to_framework": { "total_mappings": 3, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-law-ferpa-2010.json b/docs/api/crosswalks/usa-federal-law-ferpa-2010.json index 459de4cd..c54b2028 100644 --- a/docs/api/crosswalks/usa-federal-law-ferpa-2010.json +++ b/docs/api/crosswalks/usa-federal-law-ferpa-2010.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-law-ferpa-2010", - "display_name": "Family Educational Rights and Privacy Act (FERPA) (2010)", + "display_name": "US - Family Educational Rights and Privacy Act (FERPA) (2010)", "scf_to_framework": { "total_mappings": 5, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-law-ftc-act.json b/docs/api/crosswalks/usa-federal-law-ftc-act.json index 3eee9271..fd48ee54 100644 --- a/docs/api/crosswalks/usa-federal-law-ftc-act.json +++ b/docs/api/crosswalks/usa-federal-law-ftc-act.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-law-ftc-act", - "display_name": "Federal Trade Commission (FTC) Act", + "display_name": "US - Federal Trade Commission (FTC) Act", "scf_to_framework": { "total_mappings": 16, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-law-glba-cfr-314-2023.json b/docs/api/crosswalks/usa-federal-law-glba-cfr-314-2023.json index a13b7e82..3f7e1349 100644 --- a/docs/api/crosswalks/usa-federal-law-glba-cfr-314-2023.json +++ b/docs/api/crosswalks/usa-federal-law-glba-cfr-314-2023.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-law-glba-cfr-314-2023", - "display_name": "Gramm Leach Bliley Act (GLBA) (2023)", + "display_name": "US - Gramm Leach Bliley Act (GLBA) - CFR 314 (Dec 2023)", "scf_to_framework": { "total_mappings": 70, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-law-hipaa-security-rule-2013.json b/docs/api/crosswalks/usa-federal-law-hipaa-security-rule-2013.json index 48aec1b7..9a80649d 100644 --- a/docs/api/crosswalks/usa-federal-law-hipaa-security-rule-2013.json +++ b/docs/api/crosswalks/usa-federal-law-hipaa-security-rule-2013.json @@ -1,512 +1,512 @@ { "framework_id": "usa-federal-law-hipaa-security-rule-2013", - "display_name": "HIPAA Security Rule (2013)", + "display_name": "US - Health Insurance Portability and Accountability Act (HIPAA) Security Rule (2013)", "scf_to_framework": { "total_mappings": 136, "mappings": { "GOV-01": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)" ], "GOV-02": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)" ], "GOV-02.1": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "GOV-03": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)" ], "GOV-04": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "GOV-08": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "GOV-09": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "GOV-15": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "GOV-15.1": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.2": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "GOV-15.3": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.4": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.5": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "AST-01": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "AST-01.1": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "AST-02": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-02.1": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-02.9": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-03": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-03.1": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-09": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "AST-11": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "BCD-01": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "BCD-02": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "BCD-02.2": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "BCD-04": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "BCD-05": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "BCD-09.2": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "BCD-11": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "BCD-12": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "CHG-01": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "CPL-01": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)" ], "CPL-02": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "CPL-03": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "CPL-03.2": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "CFG-01": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "CFG-02": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "CFG-08": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "CFG-08.1": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "MON-01.4": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-01.7": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01.8": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "MON-01.15": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01.16": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-03": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-03.2": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-16": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "CRY-01": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "CRY-03": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "CRY-04": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "DCH-01": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)" ], "DCH-01.2": [ - "164.312(c)(1)" + "§ 164.312(c)(1)" ], "DCH-03": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-07": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-07.1": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-09": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "DCH-13.2": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-18": [ - "164.316(b)(2)(i)" + "§ 164.316(b)(2)(i)" ], "END-01": [ - "164.310(b)" + "§ 164.310(b)" ], "END-02": [ - "164.310(c)" + "§ 164.310(c)" ], "HRS-01": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)" ], "HRS-02": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)" ], "HRS-03": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)" ], "HRS-04": [ - "164.312(d)" + "§ 164.312(d)" ], "HRS-05": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.1": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.3": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-07": [ - "164.308(a)(1)(ii)(C)" + "§ 164.308(a)(1)(ii)(C)" ], "HRS-08": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "HRS-09": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-01": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)" ], "IAC-02": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "IAC-07": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-07.1": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "IAC-07.2": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-08": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)" ], "IAC-09": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "IAC-15": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-15.2": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-15.9": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-17": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "IAC-21": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "IAC-25": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "IAC-28": [ - "164.312(d)" + "§ 164.312(d)" ], "IAC-28.1": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "IAC-28.2": [ - "164.312(d)" + "§ 164.312(d)" ], "IAC-28.3": [ - "164.312(d)" + "§ 164.312(d)" ], "IRO-01": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "IRO-02": [ - "164.308(a)(6)(ii)" + "§ 164.308(a)(6)(ii)" ], "IRO-09": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "IAO-01.1": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "IAO-02": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "IAO-03.2": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "MNT-01": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "MNT-02": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "MNT-04.3": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "NET-01": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "PES-01": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "PES-02": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "PES-02.1": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "PES-03": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "PES-03.4": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "PES-04": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "PES-04.1": [ - "164.310(c)" + "§ 164.310(c)" ], "PES-06": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "PRM-03": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "PRM-05": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "PRM-06": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "RSK-01": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "RSK-01.1": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-02": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-03": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-03.1": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-04": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "RSK-06.2": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "SEA-01": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "SEA-02": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "SEA-03": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "OPS-01.1": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "OPS-03": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "SAT-01": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "SAT-02": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "SAT-03": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)" ], "SAT-03.2": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "SAT-03.6": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "TPM-01": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "TPM-02": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "TPM-04": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "TPM-05": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)" ], "TPM-05.1": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)" ], "TPM-05.2": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)" ], "TPM-05.4": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "TPM-05.6": [ - "164.308(b)(2)" + "§ 164.308(b)(2)" ], "THR-09": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "THR-10": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ] } }, "framework_to_scf": { "total_mappings": 87, "mappings": { - "164.306(a)(1)": [ + "§ 164.306(a)(1)": [ "GOV-01", "GOV-15", "GOV-15.1", @@ -515,64 +515,64 @@ "GOV-15.4", "GOV-15.5" ], - "164.306(a)(2)": [ + "§ 164.306(a)(2)": [ "GOV-01" ], - "164.306(a)(3)": [ + "§ 164.306(a)(3)": [ "GOV-01", "DCH-01", "RSK-01" ], - "164.316(a)": [ + "§ 164.316(a)": [ "GOV-01", "GOV-02" ], - "164.308(a)(1)(i)": [ + "§ 164.308(a)(1)(i)": [ "GOV-02", "CHG-01", "CFG-01", "MON-01", "IRO-01" ], - "164.308(a)(3)(i)": [ + "§ 164.308(a)(3)(i)": [ "GOV-02", "CFG-08", "IAC-01", "IAC-08", "IAC-21" ], - "164.308(a)(4)(i)": [ + "§ 164.308(a)(4)(i)": [ "GOV-02", "IAC-01" ], - "164.308(a)(4)(ii)(A)": [ + "§ 164.308(a)(4)(ii)(A)": [ "GOV-02" ], - "164.308(a)(6)(i)": [ + "§ 164.308(a)(6)(i)": [ "GOV-02", "IRO-01" ], - "164.308(a)(7)(i)": [ + "§ 164.308(a)(7)(i)": [ "GOV-02", "BCD-01", "IRO-01" ], - "164.310(a)(1)": [ + "§ 164.310(a)(1)": [ "GOV-02", "PES-01" ], - "164.310(a)(2)(ii)": [ + "§ 164.310(a)(2)(ii)": [ "GOV-02", "PES-01", "PES-03" ], - "164.310(a)(2)(iv)": [ + "§ 164.310(a)(2)(iv)": [ "GOV-02", "MNT-01", "MNT-02", "PES-01" ], - "164.310(b)": [ + "§ 164.310(b)": [ "GOV-02", "END-01", "HRS-05", @@ -583,7 +583,7 @@ "OPS-01.1", "OPS-03" ], - "164.310(d)(1)": [ + "§ 164.310(d)(1)": [ "GOV-02", "AST-01", "AST-11", @@ -595,12 +595,12 @@ "MNT-01", "MNT-04.3" ], - "164.310(d)(2)(i)": [ + "§ 164.310(d)(2)(i)": [ "GOV-02", "AST-01", "AST-09" ], - "164.312(a)(1)": [ + "§ 164.312(a)(1)": [ "GOV-02", "HRS-02", "HRS-03", @@ -608,146 +608,146 @@ "IAC-08", "IAC-21" ], - "164.312(c)(1)": [ + "§ 164.312(c)(1)": [ "GOV-02", "DCH-01", "DCH-01.2" ], - "164.316(b)(1)(i)": [ + "§ 164.316(b)(1)(i)": [ "GOV-02" ], - "164.306(d)(3)(ii)(B)(1)": [ + "§ 164.306(d)(3)(ii)(B)(1)": [ "GOV-02.1" ], - "164.316(b)(1)(ii)": [ + "§ 164.316(b)(1)(ii)": [ "GOV-03", "CPL-03" ], - "164.316(b)(2)(iii)": [ + "§ 164.316(b)(2)(iii)": [ "GOV-03", "CPL-02" ], - "164.308(a)(2)": [ + "§ 164.308(a)(2)": [ "GOV-04" ], - "164.306(b)(2)(i)": [ + "§ 164.306(b)(2)(i)": [ "GOV-08", "PRM-06" ], - "164.306(b)(1)": [ + "§ 164.306(b)(1)": [ "GOV-09", "GOV-15", "SEA-01", "SEA-02", "SEA-03" ], - "164.308(a)(1)(ii)(B)": [ + "§ 164.308(a)(1)(ii)(B)": [ "GOV-09", "GOV-15.2" ], - "164.306(d)(3)(ii)(A)": [ + "§ 164.306(d)(3)(ii)(A)": [ "GOV-15.2" ], - "164.308(a)(7)(ii)(E)": [ + "§ 164.308(a)(7)(ii)(E)": [ "AST-01", "AST-01.1", "BCD-02", "TPM-02" ], - "164.310(d)(2)(iii)": [ + "§ 164.310(d)(2)(iii)": [ "AST-02", "AST-02.1", "AST-02.9", "AST-03", "AST-03.1" ], - "164.310(d)(2)(ii)": [ + "§ 164.310(d)(2)(ii)": [ "AST-09", "DCH-09" ], - "164.308(a)(7)(ii)(C)": [ + "§ 164.308(a)(7)(ii)(C)": [ "BCD-01", "BCD-02.2" ], - "164.308(a)(7)(ii)(D)": [ + "§ 164.308(a)(7)(ii)(D)": [ "BCD-04", "BCD-05" ], - "164.310(a)(2)(i)": [ + "§ 164.310(a)(2)(i)": [ "BCD-09.2", "HRS-03", "PES-02", "PES-02.1" ], - "164.308(a)(7)(ii)(A)": [ + "§ 164.308(a)(7)(ii)(A)": [ "BCD-11" ], - "164.310(d)(2)(iv)": [ + "§ 164.310(d)(2)(iv)": [ "BCD-11" ], - "164.308(a)(7)(ii)(B)": [ + "§ 164.308(a)(7)(ii)(B)": [ "BCD-12" ], - "164.306(c)": [ + "§ 164.306(c)": [ "CPL-01" ], - "164.306(d)(1)": [ + "§ 164.306(d)(1)": [ "CPL-01" ], - "164.306(d)(2)": [ + "§ 164.306(d)(2)": [ "CPL-01" ], - "164.314(a)(1)": [ + "§ 164.314(a)(1)": [ "CPL-01" ], - "164.314(a)(2)(ii)": [ + "§ 164.314(a)(2)(ii)": [ "CPL-01" ], - "164.306(d)(3)(i)": [ + "§ 164.306(d)(3)(i)": [ "CPL-02", "CPL-03", "CPL-03.2" ], - "164.306(e)": [ + "§ 164.306(e)": [ "CPL-03.2" ], - "164.308(a)(8)": [ + "§ 164.308(a)(8)": [ "CPL-03.2", "IAO-01.1", "IAO-02" ], - "164.312(a)(2)(iii)": [ + "§ 164.312(a)(2)(iii)": [ "CFG-02", "IAC-25" ], - "164.312(e)(1)": [ + "§ 164.312(e)(1)": [ "CFG-02", "CRY-03", "NET-01" ], - "164.312(e)(2)(i)": [ + "§ 164.312(e)(2)(i)": [ "CFG-02", "CRY-04", "NET-01" ], - "164.312(e)(2)(ii)": [ + "§ 164.312(e)(2)(ii)": [ "CFG-02", "CRY-01", "OPS-03" ], - "164.312(c)(2)": [ + "§ 164.312(c)(2)": [ "CFG-08", "CFG-08.1", "MON-01.7", "MON-01.15", "MON-16" ], - "164.308(a)(1)(ii)(D)": [ + "§ 164.308(a)(1)(ii)(D)": [ "MON-01", "MON-01.8", "IRO-09" ], - "164.312(b)": [ + "§ 164.312(b)": [ "MON-01", "MON-01.4", "MON-01.8", @@ -756,26 +756,26 @@ "MON-03.2", "MON-16" ], - "164.312(a)(2)(iv)": [ + "§ 164.312(a)(2)(iv)": [ "CRY-01" ], - "164.316(b)(2)(i)": [ + "§ 164.316(b)(2)(i)": [ "DCH-18" ], - "164.310(c)": [ + "§ 164.310(c)": [ "END-02", "PES-03", "PES-03.4", "PES-04", "PES-04.1" ], - "164.308(a)(3)(ii)(A)": [ + "§ 164.308(a)(3)(ii)(A)": [ "HRS-01", "IAC-07.1", "IAC-08", "IAC-28.1" ], - "164.312(d)": [ + "§ 164.312(d)": [ "HRS-01", "HRS-04", "IAC-28", @@ -783,56 +783,56 @@ "IAC-28.3", "TPM-01" ], - "164.308(a)(3)(ii)(B)": [ + "§ 164.308(a)(3)(ii)(B)": [ "HRS-02", "HRS-03", "IAC-17" ], - "164.308(a)(1)(ii)(C)": [ + "§ 164.308(a)(1)(ii)(C)": [ "HRS-07" ], - "164.308(a)(3)(ii)(C)": [ + "§ 164.308(a)(3)(ii)(C)": [ "HRS-08", "HRS-09", "IAC-07", "IAC-07.2" ], - "164.308(a)(4)(ii)(B)": [ + "§ 164.308(a)(4)(ii)(B)": [ "IAC-01" ], - "164.310(a)(2)(iii)": [ + "§ 164.310(a)(2)(iii)": [ "IAC-01", "PES-02", "PES-03", "PES-06" ], - "164.312(a)(2)(i)": [ + "§ 164.312(a)(2)(i)": [ "IAC-02", "IAC-09" ], - "164.308(a)(4)(ii)(C)": [ + "§ 164.308(a)(4)(ii)(C)": [ "IAC-08" ], - "164.312(a)(2)(ii)": [ + "§ 164.312(a)(2)(ii)": [ "IAC-15", "IAC-15.2", "IAC-15.9" ], - "164.308(a)(6)(ii)": [ + "§ 164.308(a)(6)(ii)": [ "IRO-02" ], - "164.308(b)(3)": [ + "§ 164.308(b)(3)": [ "IAO-03.2", "TPM-05" ], - "164.306(b)(2)(iii)": [ + "§ 164.306(b)(2)(iii)": [ "PRM-03" ], - "164.306(b)(2)(ii)": [ + "§ 164.306(b)(2)(ii)": [ "PRM-05", "SEA-02" ], - "164.306(b)(2)(iv)": [ + "§ 164.306(b)(2)(iv)": [ "RSK-01", "RSK-01.1", "RSK-02", @@ -842,67 +842,67 @@ "THR-09", "THR-10" ], - "164.308(a)(1)(ii)(A)": [ + "§ 164.308(a)(1)(ii)(A)": [ "RSK-04" ], - "164.306(d)(3)(ii)(B)(2)": [ + "§ 164.306(d)(3)(ii)(B)(2)": [ "RSK-06.2" ], - "164.316(b)(2)(ii)": [ + "§ 164.316(b)(2)(ii)": [ "OPS-01.1", "OPS-03" ], - "164.308(a)(5)(i)": [ + "§ 164.308(a)(5)(i)": [ "SAT-01", "SAT-02" ], - "164.308(a)(5)(ii)(C)": [ + "§ 164.308(a)(5)(ii)(C)": [ "SAT-03" ], - "164.308(a)(5)(ii)(D)": [ + "§ 164.308(a)(5)(ii)(D)": [ "SAT-03" ], - "164.308(a)(5)(ii)(B)": [ + "§ 164.308(a)(5)(ii)(B)": [ "SAT-03.2" ], - "164.308(a)(5)(ii)(A)": [ + "§ 164.308(a)(5)(ii)(A)": [ "SAT-03.6" ], - "164.308(b)(1)": [ + "§ 164.308(b)(1)": [ "TPM-01", "TPM-04", "TPM-05", "TPM-05.2", "TPM-05.4" ], - "164.308(b)(2)": [ + "§ 164.308(b)(2)": [ "TPM-05", "TPM-05.2", "TPM-05.6" ], - "164.314(a)(2)(iii)": [ + "§ 164.314(a)(2)(iii)": [ "TPM-05", "TPM-05.2" ], - "164.314(b)(1)": [ + "§ 164.314(b)(1)": [ "TPM-05" ], - "164.314(b)(2)(i)": [ + "§ 164.314(b)(2)(i)": [ "TPM-05" ], - "164.314(b)(2)(ii)": [ + "§ 164.314(b)(2)(ii)": [ "TPM-05" ], - "164.314(b)(2)(iii)": [ + "§ 164.314(b)(2)(iii)": [ "TPM-05" ], - "164.314(a)(2)(i)(C)": [ + "§ 164.314(a)(2)(i)(C)": [ "TPM-05.1" ], - "164.314(b)(2)(iv)": [ + "§ 164.314(b)(2)(iv)": [ "TPM-05.1" ], - "164.314(a)(2)(i)(B)": [ + "§ 164.314(a)(2)(i)(B)": [ "TPM-05.2" ] } diff --git a/docs/api/crosswalks/usa-federal-law-hipaa-simplification-2013.json b/docs/api/crosswalks/usa-federal-law-hipaa-simplification-2013.json index 891c9550..4c90e2d2 100644 --- a/docs/api/crosswalks/usa-federal-law-hipaa-simplification-2013.json +++ b/docs/api/crosswalks/usa-federal-law-hipaa-simplification-2013.json @@ -1,1098 +1,1098 @@ { "framework_id": "usa-federal-law-hipaa-simplification-2013", - "display_name": "HIPAA Administrative Simplification (2013)", + "display_name": "US - Health Insurance Portability and Accountability Act (HIPAA) Administrative Simplification (2013)", "scf_to_framework": { "total_mappings": 170, "mappings": { "GOV-01": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)", - "164.530(c)(1)", - "164.530(i)(1)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)", + "§ 164.530(c)(1)", + "§ 164.530(i)(1)" ], "GOV-02": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)", - "164.530(j)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)", + "§ 164.530(j)(1)(i)" ], "GOV-02.1": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "GOV-03": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)", - "164.530(i)(2)(i)", - "164.530(i)(2)(ii)", - "164.530(i)(2)(iii)", - "164.530(i)(3)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)", + "§ 164.530(i)(2)(i)", + "§ 164.530(i)(2)(ii)", + "§ 164.530(i)(2)(iii)", + "§ 164.530(i)(3)" ], "GOV-04": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "GOV-08": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "GOV-09": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "GOV-15": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "GOV-15.1": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.2": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "GOV-15.3": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.4": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "GOV-15.5": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "AST-01": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "AST-01.1": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "AST-02": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-02.1": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-02.9": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-03": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-03.1": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "AST-09": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "AST-11": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "BCD-01": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "BCD-02": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "BCD-02.2": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "BCD-04": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "BCD-05": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "BCD-09.2": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "BCD-11": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "BCD-12": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "CHG-01": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "CPL-01": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)", - "164.504(g)(1)", - "164.530(i)(1)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)", + "§ 164.504(g)(1)", + "§ 164.530(i)(1)" ], "CPL-02": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "CPL-03": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "CPL-03.2": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "CFG-01": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "CFG-02": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "CFG-08": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "CFG-08.1": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "MON-01.4": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-01.7": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01.8": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "MON-01.15": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "MON-01.16": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-03": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-03.2": [ - "164.312(b)" + "§ 164.312(b)" ], "MON-16": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "CRY-01": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "CRY-03": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "CRY-04": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "DCH-01": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "DCH-01.2": [ - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "DCH-03": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-03.1": [ - "164.510(b)(1)(i)", - "164.510(b)(1)(ii)", - "164.510(b)(2)", - "164.510(b)(4)", - "164.510(b)(5)", - "164.512", - "164.512(a)(1)", - "164.512(c)(1)", - "164.512(c)(1)(i)", - "164.512(c)(1)(ii)", - "164.512(c)(1)(iii)(A)", - "164.512(c)(1)(iii)(B)", - "164.512(c)(2)", - "164.512(c)(2)(i)", - "164.512(c)(2)(ii)", - "164.512(d)(1)", - "164.512(d)(1)(i)", - "164.512(d)(1)(ii)", - "164.512(d)(1)(iii)", - "164.512(d)(1)(iv)", - "164.512(e)(1)", - "164.512(e)(1)(i)", - "164.512(e)(1)(ii)", - "164.512(e)(1)(ii)(A)", - "164.512(e)(1)(ii)(B)", - "164.512(e)(1)(iii)", - "164.512(e)(1)(iii)(A)", - "164.512(e)(1)(iii)(B)", - "164.512(e)(1)(iii)(C)", - "164.512(e)(1)(iii)(C)(1)", - "164.512(e)(1)(iii)(C)(2)", - "164.512(e)(1)(iv)", - "164.512(e)(1)(iv)(A)", - "164.512(e)(1)(iv)(B)", - "164.512(e)(1)(v)", - "164.512(e)(1)(v)(A)", - "164.512(e)(1)(v)(B)", - "164.512(e)(1)(vi)", - "164.512(f)", - "164.512(f)(1)", - "164.512(f)(1)(i)", - "164.512(f)(1)(ii)(A)", - "164.512(f)(1)(ii)(B)", - "164.512(f)(1)(ii)(C)", - "164.512(f)(1)(ii)(C)(1)", - "164.512(f)(1)(ii)(C)(2)", - "164.512(f)(1)(ii)(C)(3)", - "164.512(f)(2)", - "164.512(f)(2)(i)(A)", - "164.512(f)(2)(i)(B)", - "164.512(f)(2)(i)(C)", - "164.512(f)(2)(i)(D)", - "164.512(f)(2)(i)(E)", - "164.512(f)(2)(i)(F)", - "164.512(f)(2)(i)(G)", - "164.512(f)(2)(i)(H)", - "164.512(f)(2)(ii)", - "164.512(f)(3)", - "164.512(f)(3)(i)", - "164.512(f)(3)(ii)", - "164.512(f)(3)(ii)(A)", - "164.512(f)(3)(ii)(B)", - "164.512(f)(3)(ii)(C)", - "164.512(f)(4)", - "164.512(f)(5)", - "164.512(f)(6)(i)", - "164.512(f)(6)(i)(A)", - "164.512(f)(6)(i)(B)", - "164.512(f)(6)(i)(C)", - "164.512(f)(6)(ii)", - "164.512(g)(1)", - "164.512(g)(2)", - "164.512(h)", - "164.512(i)(1)", - "164.512(j)(1)", - "164.514(d)(3)(i)", - "164.514(d)(3)(ii)(A)", - "164.514(d)(3)(ii)(B)", - "164.514(d)(3)(iii)", - "164.514(d)(3)(iii)(A)", - "164.514(d)(3)(iii)(B)", - "164.514(d)(3)(iii)(C)", - "164.514(d)(3)(iii)(D)", - "164.514(d)(4)", - "164.514(d)(4)(i)", - "164.514(d)(4)(ii)", - "164.514(d)(4)(iii)(A)", - "164.514(d)(4)(iii)(B)", - "164.514(d)(5)", - "164.514(e)(1)", - "164.514(e)(2)", - "164.514(e)(2)(i)", - "164.514(e)(2)(ii)", - "164.514(e)(2)(iii)", - "164.514(e)(2)(iv)", - "164.514(e)(2)(v)", - "164.514(e)(2)(vi)", - "164.514(e)(2)(vii)", - "164.514(e)(2)(viii)", - "164.514(e)(2)(ix)", - "164.514(e)(2)(x)", - "164.514(e)(2)(xi)", - "164.514(e)(2)(xii)", - "164.514(e)(2)(xiii)", - "164.514(e)(2)(xiv)", - "164.514(e)(2)(xv)", - "164.514(e)(2)(xvi)", - "164.514(e)(3)(i)", - "164.514(e)(3)(ii)", - "164.514(e)(4)(i)", - "164.514(e)(4)(ii)", - "164.514(e)(4)(ii)(A)", - "164.514(e)(4)(ii)(B)", - "164.514(e)(4)(ii)(C)", - "164.514(e)(4)(ii)(C)(1)", - "164.514(e)(4)(ii)(C)(2)", - "164.514(e)(4)(ii)(C)(3)", - "164.514(e)(4)(ii)(C)(4)", - "164.514(e)(4)(ii)(C)(5)", - "164.532(a)", - "164.532(b)", - "164.532(c)", - "164.532(c)(1)", - "164.532(d)" + "§ 164.510(b)(1)(i)", + "§ 164.510(b)(1)(ii)", + "§ 164.510(b)(2)", + "§ 164.510(b)(4)", + "§ 164.510(b)(5)", + "§ 164.512", + "§ 164.512(a)(1)", + "§ 164.512(c)(1)", + "§ 164.512(c)(1)(i)", + "§ 164.512(c)(1)(ii)", + "§ 164.512(c)(1)(iii)(A)", + "§ 164.512(c)(1)(iii)(B)", + "§ 164.512(c)(2)", + "§ 164.512(c)(2)(i)", + "§ 164.512(c)(2)(ii)", + "§ 164.512(d)(1)", + "§ 164.512(d)(1)(i)", + "§ 164.512(d)(1)(ii)", + "§ 164.512(d)(1)(iii)", + "§ 164.512(d)(1)(iv)", + "§ 164.512(e)(1)", + "§ 164.512(e)(1)(i)", + "§ 164.512(e)(1)(ii)", + "§ 164.512(e)(1)(ii)(A)", + "§ 164.512(e)(1)(ii)(B)", + "§ 164.512(e)(1)(iii)", + "§ 164.512(e)(1)(iii)(A)", + "§ 164.512(e)(1)(iii)(B)", + "§ 164.512(e)(1)(iii)(C)", + "§ 164.512(e)(1)(iii)(C)(1)", + "§ 164.512(e)(1)(iii)(C)(2)", + "§ 164.512(e)(1)(iv)", + "§ 164.512(e)(1)(iv)(A)", + "§ 164.512(e)(1)(iv)(B)", + "§ 164.512(e)(1)(v)", + "§ 164.512(e)(1)(v)(A)", + "§ 164.512(e)(1)(v)(B)", + "§ 164.512(e)(1)(vi)", + "§ 164.512(f)", + "§ 164.512(f)(1)", + "§ 164.512(f)(1)(i)", + "§ 164.512(f)(1)(ii)(A)", + "§ 164.512(f)(1)(ii)(B)", + "§ 164.512(f)(1)(ii)(C)", + "§ 164.512(f)(1)(ii)(C)(1)", + "§ 164.512(f)(1)(ii)(C)(2)", + "§ 164.512(f)(1)(ii)(C)(3)", + "§ 164.512(f)(2)", + "§ 164.512(f)(2)(i)(A)", + "§ 164.512(f)(2)(i)(B)", + "§ 164.512(f)(2)(i)(C)", + "§ 164.512(f)(2)(i)(D)", + "§ 164.512(f)(2)(i)(E)", + "§ 164.512(f)(2)(i)(F)", + "§ 164.512(f)(2)(i)(G)", + "§ 164.512(f)(2)(i)(H)", + "§ 164.512(f)(2)(ii)", + "§ 164.512(f)(3)", + "§ 164.512(f)(3)(i)", + "§ 164.512(f)(3)(ii)", + "§ 164.512(f)(3)(ii)(A)", + "§ 164.512(f)(3)(ii)(B)", + "§ 164.512(f)(3)(ii)(C)", + "§ 164.512(f)(4)", + "§ 164.512(f)(5)", + "§ 164.512(f)(6)(i)", + "§ 164.512(f)(6)(i)(A)", + "§ 164.512(f)(6)(i)(B)", + "§ 164.512(f)(6)(i)(C)", + "§ 164.512(f)(6)(ii)", + "§ 164.512(g)(1)", + "§ 164.512(g)(2)", + "§ 164.512(h)", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.514(d)(3)(ii)(A)", + "§ 164.514(d)(3)(ii)(B)", + "§ 164.514(d)(3)(iii)", + "§ 164.514(d)(3)(iii)(A)", + "§ 164.514(d)(3)(iii)(B)", + "§ 164.514(d)(3)(iii)(C)", + "§ 164.514(d)(3)(iii)(D)", + "§ 164.514(d)(4)", + "§ 164.514(d)(4)(i)", + "§ 164.514(d)(4)(ii)", + "§ 164.514(d)(4)(iii)(A)", + "§ 164.514(d)(4)(iii)(B)", + "§ 164.514(d)(5)", + "§ 164.514(e)(1)", + "§ 164.514(e)(2)", + "§ 164.514(e)(2)(i)", + "§ 164.514(e)(2)(ii)", + "§ 164.514(e)(2)(iii)", + "§ 164.514(e)(2)(iv)", + "§ 164.514(e)(2)(v)", + "§ 164.514(e)(2)(vi)", + "§ 164.514(e)(2)(vii)", + "§ 164.514(e)(2)(viii)", + "§ 164.514(e)(2)(ix)", + "§ 164.514(e)(2)(x)", + "§ 164.514(e)(2)(xi)", + "§ 164.514(e)(2)(xii)", + "§ 164.514(e)(2)(xiii)", + "§ 164.514(e)(2)(xiv)", + "§ 164.514(e)(2)(xv)", + "§ 164.514(e)(2)(xvi)", + "§ 164.514(e)(3)(i)", + "§ 164.514(e)(3)(ii)", + "§ 164.514(e)(4)(i)", + "§ 164.514(e)(4)(ii)", + "§ 164.514(e)(4)(ii)(A)", + "§ 164.514(e)(4)(ii)(B)", + "§ 164.514(e)(4)(ii)(C)", + "§ 164.514(e)(4)(ii)(C)(1)", + "§ 164.514(e)(4)(ii)(C)(2)", + "§ 164.514(e)(4)(ii)(C)(3)", + "§ 164.514(e)(4)(ii)(C)(4)", + "§ 164.514(e)(4)(ii)(C)(5)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)", + "§ 164.532(c)(1)", + "§ 164.532(d)" ], "DCH-07": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-07.1": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-09": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "DCH-13.2": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "DCH-18": [ - "164.316(b)(2)(i)", - "164.530(j)(2)" + "§ 164.316(b)(2)(i)", + "§ 164.530(j)(2)" ], "DCH-18.1": [ - "164.502(b)(1)" + "§ 164.502(b)(1)" ], "DCH-22.1": [ - "164.526(a)(1)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)" ], "END-01": [ - "164.310(b)" + "§ 164.310(b)" ], "END-02": [ - "164.310(c)" + "§ 164.310(c)" ], "HRS-01": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)", - "164.530(e)(2)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)", + "§ 164.530(e)(2)" ], "HRS-02": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "HRS-03": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "HRS-04": [ - "164.312(d)" + "§ 164.312(d)" ], "HRS-05": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.1": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.3": [ - "164.310(b)" + "§ 164.310(b)" ], "HRS-05.7": [ - "164.530(b)(1)" + "§ 164.530(b)(1)" ], "HRS-06.1": [ - "164.502(a)" + "§ 164.502(a)" ], "HRS-07": [ - "164.308(a)(1)(ii)(C)", - "164.530(e)(1)" + "§ 164.308(a)(1)(ii)(C)", + "§ 164.530(e)(1)" ], "HRS-08": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "HRS-09": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-01": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)", + "§ 164.530(c)(2)(ii)" ], "IAC-02": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "IAC-07": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-07.1": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "IAC-07.2": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "IAC-08": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)", - "164.514(d)(2)(i)(A)", - "164.514(d)(2)(i)(B)", - "164.514(d)(2)(ii)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)", + "§ 164.514(d)(2)(i)(A)", + "§ 164.514(d)(2)(i)(B)", + "§ 164.514(d)(2)(ii)", + "§ 164.530(c)(2)(ii)" ], "IAC-09": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "IAC-15": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-15.2": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-15.9": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "IAC-17": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "IAC-21": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "IAC-25": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "IAC-28": [ - "164.312(d)" + "§ 164.312(d)" ], "IAC-28.1": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "IAC-28.2": [ - "164.312(d)" + "§ 164.312(d)" ], "IAC-28.3": [ - "164.312(d)" + "§ 164.312(d)" ], "IRO-01": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "IRO-02": [ - "164.308(a)(6)(ii)", - "164.412", - "164.412(a)", - "164.412(b)", - "164.530(f)" + "§ 164.308(a)(6)(ii)", + "§ 164.412", + "§ 164.412(a)", + "§ 164.412(b)", + "§ 164.530(f)" ], "IRO-04.1": [ - "164.404(a)(1)", - "164.404(a)(2)", - "164.404(c)(1)(A)", - "164.404(c)(1)(B)", - "164.404(c)(1)(C)", - "164.404(c)(1)(D)", - "164.404(c)(1)(E)", - "164.404(c)(2)", - "164.404(d)(1)(i)", - "164.404(d)(1)(ii)", - "164.404(d)(2)", - "164.404(d)(2)(i)", - "164.404(d)(2)(ii)(A)", - "164.404(d)(2)(ii)(B)", - "164.404(d)(3)", - "164.406(a)", - "164.406(b)", - "164.406(c)", - "164.410(c)(1)" + "§ 164.404(a)(1)", + "§ 164.404(a)(2)", + "§ 164.404(c)(1)(A)", + "§ 164.404(c)(1)(B)", + "§ 164.404(c)(1)(C)", + "§ 164.404(c)(1)(D)", + "§ 164.404(c)(1)(E)", + "§ 164.404(c)(2)", + "§ 164.404(d)(1)(i)", + "§ 164.404(d)(1)(ii)", + "§ 164.404(d)(2)", + "§ 164.404(d)(2)(i)", + "§ 164.404(d)(2)(ii)(A)", + "§ 164.404(d)(2)(ii)(B)", + "§ 164.404(d)(3)", + "§ 164.406(a)", + "§ 164.406(b)", + "§ 164.406(c)", + "§ 164.410(c)(1)" ], "IRO-09": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "IRO-10": [ - "164.404(b)", - "164.408(a)", - "164.408(b)", - "164.408(c)" + "§ 164.404(b)", + "§ 164.408(a)", + "§ 164.408(b)", + "§ 164.408(c)" ], "IRO-10.2": [ - "164.410(a)(1)" + "§ 164.410(a)(1)" ], "IAO-01.1": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "IAO-02": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "IAO-03.2": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "MNT-01": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "MNT-02": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "MNT-04.3": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "NET-01": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "PES-01": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "PES-02": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "PES-02.1": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "PES-03": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "PES-03.4": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "PES-04": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "PES-04.1": [ - "164.310(c)" + "§ 164.310(c)" ], "PES-06": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "PRI-01": [ - "164.502(a)", - "164.530(a)(1)(i)", - "164.530(i)(1)", - "164.530(i)(4)(i)(A)", - "164.530(i)(4)(i)(B)", - "164.530(i)(5)", - "164.530(i)(5)(i)", - "164.530(i)(5)(ii)" + "§ 164.502(a)", + "§ 164.530(a)(1)(i)", + "§ 164.530(i)(1)", + "§ 164.530(i)(4)(i)(A)", + "§ 164.530(i)(4)(i)(B)", + "§ 164.530(i)(5)", + "§ 164.530(i)(5)(i)", + "§ 164.530(i)(5)(ii)" ], "PRI-01.1": [ - "164.530(a)(1)(i)" + "§ 164.530(a)(1)(i)" ], "PRI-01.4": [ - "164.530(a)(1)(ii)" + "§ 164.530(a)(1)(ii)" ], "PRI-02": [ - "164.520(a)(1)", - "164.520(a)(2)(i)", - "164.520(a)(2)(i)(A)", - "164.520(a)(2)(i)(B)", - "164.520(a)(2)(ii)", - "164.520(a)(2)(ii)(A)", - "164.520(a)(2)(ii)(B)", - "164.520(a)(2)(iii)", - "164.520(b)(1)", - "164.520(b)(1)(i)", - "164.520(b)(1)(ii)", - "164.520(b)(1)(ii)(A)", - "164.520(b)(1)(ii)(B)", - "164.520(b)(1)(ii)(C)", - "164.520(b)(1)(ii)(D)", - "164.520(b)(1)(ii)(E)", - "164.520(b)(1)(iv)", - "164.520(b)(1)(iv)(A)", - "164.520(b)(1)(iv)(B)", - "164.520(b)(1)(iv)(C)", - "164.520(b)(1)(iv)(D)", - "164.520(b)(1)(iv)(E)", - "164.520(b)(1)(iv)(F)", - "164.520(b)(1)(v)", - "164.520(b)(1)(v)(A)", - "164.520(b)(1)(v)(B)", - "164.520(b)(1)(v)(C)", - "164.520(b)(1)(vi)", - "164.520(b)(1)(vii)", - "164.520(b)(1)(viii)", - "164.520(b)(2)(i)", - "164.520(b)(2)(ii)", - "164.520(b)(3)", - "164.520(c)", - "164.520(c)(1)(i)", - "164.520(c)(1)(i)(A)", - "164.520(c)(1)(i)(B)", - "164.520(c)(1)(ii)", - "164.520(c)(1)(iii)", - "164.520(c)(1)(iv)", - "164.520(c)(1)(v)", - "164.520(c)(1)(v)(A)", - "164.520(c)(1)(v)(B)", - "164.530(i)(4)(i)(C)" + "§ 164.520(a)(1)", + "§ 164.520(a)(2)(i)", + "§ 164.520(a)(2)(i)(A)", + "§ 164.520(a)(2)(i)(B)", + "§ 164.520(a)(2)(ii)", + "§ 164.520(a)(2)(ii)(A)", + "§ 164.520(a)(2)(ii)(B)", + "§ 164.520(a)(2)(iii)", + "§ 164.520(b)(1)", + "§ 164.520(b)(1)(i)", + "§ 164.520(b)(1)(ii)", + "§ 164.520(b)(1)(ii)(A)", + "§ 164.520(b)(1)(ii)(B)", + "§ 164.520(b)(1)(ii)(C)", + "§ 164.520(b)(1)(ii)(D)", + "§ 164.520(b)(1)(ii)(E)", + "§ 164.520(b)(1)(iv)", + "§ 164.520(b)(1)(iv)(A)", + "§ 164.520(b)(1)(iv)(B)", + "§ 164.520(b)(1)(iv)(C)", + "§ 164.520(b)(1)(iv)(D)", + "§ 164.520(b)(1)(iv)(E)", + "§ 164.520(b)(1)(iv)(F)", + "§ 164.520(b)(1)(v)", + "§ 164.520(b)(1)(v)(A)", + "§ 164.520(b)(1)(v)(B)", + "§ 164.520(b)(1)(v)(C)", + "§ 164.520(b)(1)(vi)", + "§ 164.520(b)(1)(vii)", + "§ 164.520(b)(1)(viii)", + "§ 164.520(b)(2)(i)", + "§ 164.520(b)(2)(ii)", + "§ 164.520(b)(3)", + "§ 164.520(c)", + "§ 164.520(c)(1)(i)", + "§ 164.520(c)(1)(i)(A)", + "§ 164.520(c)(1)(i)(B)", + "§ 164.520(c)(1)(ii)", + "§ 164.520(c)(1)(iii)", + "§ 164.520(c)(1)(iv)", + "§ 164.520(c)(1)(v)", + "§ 164.520(c)(1)(v)(A)", + "§ 164.520(c)(1)(v)(B)", + "§ 164.530(i)(4)(i)(C)" ], "PRI-02.1": [ - "164.502(a)(3)", - "164.508(c)(1)(i)", - "164.508(c)(1)(ii)", - "164.508(c)(1)(iii)", - "164.508(c)(1)(iv)", - "164.508(c)(2)(i)(A)", - "164.508(c)(2)(i)(B)" + "§ 164.502(a)(3)", + "§ 164.508(c)(1)(i)", + "§ 164.508(c)(1)(ii)", + "§ 164.508(c)(1)(iii)", + "§ 164.508(c)(1)(iv)", + "§ 164.508(c)(2)(i)(A)", + "§ 164.508(c)(2)(i)(B)" ], "PRI-03": [ - "164.506(b)(1)", - "164.508(a)(2)", - "164.508(c)(1)(v)", - "164.508(c)(3)", - "164.510(b)(2)(i)", - "164.510(b)(2)(ii)", - "164.510(b)(2)(iii)", - "164.510(b)(3)", - "164.514(f)(2)(ii)", - "164.514(f)(2)(iv)", - "164.514(f)(2)(v)" + "§ 164.506(b)(1)", + "§ 164.508(a)(2)", + "§ 164.508(c)(1)(v)", + "§ 164.508(c)(3)", + "§ 164.510(b)(2)(i)", + "§ 164.510(b)(2)(ii)", + "§ 164.510(b)(2)(iii)", + "§ 164.510(b)(3)", + "§ 164.514(f)(2)(ii)", + "§ 164.514(f)(2)(iv)", + "§ 164.514(f)(2)(v)" ], "PRI-03.3": [ - "164.502(a)(5)(ii)(A)" + "§ 164.502(a)(5)(ii)(A)" ], "PRI-03.5": [ - "164.508(c)(2)(ii)(A)", - "164.508(c)(2)(ii)(B)", - "164.514(f)(2)(iii)" + "§ 164.508(c)(2)(ii)(A)", + "§ 164.508(c)(2)(ii)(B)", + "§ 164.514(f)(2)(iii)" ], "PRI-03.6": [ - "164.502(g)(1)", - "164.502(g)(2)", - "164.502(g)(3)(i)", - "164.502(g)(3)(i)(A)" + "§ 164.502(g)(1)", + "§ 164.502(g)(2)", + "§ 164.502(g)(3)(i)", + "§ 164.502(g)(3)(i)(A)" ], "PRI-04.1": [ - "164.502(a)(1)(i)", - "164.502(a)(1)(ii)", - "164.502(a)(1)(iii)", - "164.502(a)(5)(i)", - "164.502(i)" + "§ 164.502(a)(1)(i)", + "§ 164.502(a)(1)(ii)", + "§ 164.502(a)(1)(iii)", + "§ 164.502(a)(5)(i)", + "§ 164.502(i)" ], "PRI-05.1": [ - "164.508(a)(2)(i)(B)" + "§ 164.508(a)(2)(i)(B)" ], "PRI-05.4": [ - "164.502(c)", - "164.502(d)(1)", - "164.504(g)(2)", - "164.506(a)", - "164.506(c)(1)", - "164.506(c)(5)", - "164.508(a)(1)", - "164.508(a)(2)(i)(C)", - "164.510(a)(1)(i)(A)", - "164.510(a)(1)(i)(B)", - "164.510(a)(1)(i)(C)", - "164.510(a)(1)(i)(D)", - "164.510(a)(1)(ii)(A)", - "164.510(a)(1)(ii)(B)", - "164.510(b)(4)", - "164.512", - "164.512(i)(1)", - "164.512(j)(1)", - "164.512(j)(1)(i)(A)", - "164.512(j)(1)(i)(B)", - "164.512(j)(1)(ii)", - "164.512(j)(1)(ii)(A)", - "164.512(j)(1)(ii)(B)", - "164.512(j)(2)(i)", - "164.512(j)(2)(ii)", - "164.512(j)(3)", - "164.512(j)(4)", - "164.512(k)(1)(i)", - "164.512(k)(1)(i)(A)", - "164.512(k)(1)(i)(B)", - "164.512(k)(1)(ii)", - "164.512(k)(1)(iii)", - "164.512(k)(1)(iv)", - "164.512(k)(2)", - "164.512(k)(3)", - "164.512(k)(4)", - "164.512(k)(4)(i)", - "164.512(k)(4)(ii)", - "164.512(k)(4)(iii)", - "164.512(k)(5)(i)", - "164.512(k)(5)(i)(A)", - "164.512(k)(5)(i)(B)", - "164.512(k)(5)(i)(C)", - "164.512(k)(5)(i)(D)", - "164.512(k)(5)(i)(E)", - "164.512(k)(5)(i)(F)", - "164.512(k)(5)(ii)", - "164.512(k)(5)(iii)", - "164.512(k)(6)(i)", - "164.512(k)(6)(ii)", - "164.512(k)(6)(ii)(1)", - "164.514(f)(2)(i)", - "164.514(g)", - "164.530(i)(4)(ii)", - "164.530(i)(4)(ii)(B)", - "164.532(a)", - "164.532(b)", - "164.532(c)" + "§ 164.502(c)", + "§ 164.502(d)(1)", + "§ 164.504(g)(2)", + "§ 164.506(a)", + "§ 164.506(c)(1)", + "§ 164.506(c)(5)", + "§ 164.508(a)(1)", + "§ 164.508(a)(2)(i)(C)", + "§ 164.510(a)(1)(i)(A)", + "§ 164.510(a)(1)(i)(B)", + "§ 164.510(a)(1)(i)(C)", + "§ 164.510(a)(1)(i)(D)", + "§ 164.510(a)(1)(ii)(A)", + "§ 164.510(a)(1)(ii)(B)", + "§ 164.510(b)(4)", + "§ 164.512", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.512(j)(1)(i)(A)", + "§ 164.512(j)(1)(i)(B)", + "§ 164.512(j)(1)(ii)", + "§ 164.512(j)(1)(ii)(A)", + "§ 164.512(j)(1)(ii)(B)", + "§ 164.512(j)(2)(i)", + "§ 164.512(j)(2)(ii)", + "§ 164.512(j)(3)", + "§ 164.512(j)(4)", + "§ 164.512(k)(1)(i)", + "§ 164.512(k)(1)(i)(A)", + "§ 164.512(k)(1)(i)(B)", + "§ 164.512(k)(1)(ii)", + "§ 164.512(k)(1)(iii)", + "§ 164.512(k)(1)(iv)", + "§ 164.512(k)(2)", + "§ 164.512(k)(3)", + "§ 164.512(k)(4)", + "§ 164.512(k)(4)(i)", + "§ 164.512(k)(4)(ii)", + "§ 164.512(k)(4)(iii)", + "§ 164.512(k)(5)(i)", + "§ 164.512(k)(5)(i)(A)", + "§ 164.512(k)(5)(i)(B)", + "§ 164.512(k)(5)(i)(C)", + "§ 164.512(k)(5)(i)(D)", + "§ 164.512(k)(5)(i)(E)", + "§ 164.512(k)(5)(i)(F)", + "§ 164.512(k)(5)(ii)", + "§ 164.512(k)(5)(iii)", + "§ 164.512(k)(6)(i)", + "§ 164.512(k)(6)(ii)", + "§ 164.512(k)(6)(ii)(1)", + "§ 164.514(f)(2)(i)", + "§ 164.514(g)", + "§ 164.530(i)(4)(ii)", + "§ 164.530(i)(4)(ii)(B)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)" ], "PRI-06": [ - "164.502(a)(2)(i)", - "164.502(a)(2)(ii)", - "164.514(h)(1)(i)", - "164.514(h)(1)(ii)", - "164.524(a)(1)", - "164.524(a)(1)(i)", - "164.524(a)(1)(ii)", - "164.524(a)(1)(iii)", - "164.524(a)(1)(iii)(A)", - "164.524(a)(1)(iii)(B)", - "164.524(a)(2)", - "164.524(a)(2)(i)", - "164.524(a)(2)(ii)", - "164.524(a)(2)(iii)", - "164.524(a)(2)(iv)", - "164.524(a)(2)(v)", - "164.524(a)(3)", - "164.524(a)(3)(i)", - "164.524(a)(3)(ii)", - "164.524(a)(3)(iii)", - "164.524(a)(4)", - "164.524(b)(1)", - "164.524(b)(2)(i)", - "164.524(b)(2)(i)(A)", - "164.524(b)(2)(i)(B)", - "164.524(b)(2)(ii)", - "164.524(b)(2)(ii)(A)", - "164.524(b)(2)(ii)(B)", - "164.524(c)", - "164.524(c)(1)", - "164.524(c)(3)(i)", - "164.524(c)(3)(ii)", - "164.524(c)(4)", - "164.524(c)(4)(i)", - "164.524(c)(4)(ii)", - "164.524(c)(4)(iii)", - "164.524(c)(4)(iv)", - "164.524(d)", - "164.524(d)(1)", - "164.524(d)(2)" + "§ 164.502(a)(2)(i)", + "§ 164.502(a)(2)(ii)", + "§ 164.514(h)(1)(i)", + "§ 164.514(h)(1)(ii)", + "§ 164.524(a)(1)", + "§ 164.524(a)(1)(i)", + "§ 164.524(a)(1)(ii)", + "§ 164.524(a)(1)(iii)", + "§ 164.524(a)(1)(iii)(A)", + "§ 164.524(a)(1)(iii)(B)", + "§ 164.524(a)(2)", + "§ 164.524(a)(2)(i)", + "§ 164.524(a)(2)(ii)", + "§ 164.524(a)(2)(iii)", + "§ 164.524(a)(2)(iv)", + "§ 164.524(a)(2)(v)", + "§ 164.524(a)(3)", + "§ 164.524(a)(3)(i)", + "§ 164.524(a)(3)(ii)", + "§ 164.524(a)(3)(iii)", + "§ 164.524(a)(4)", + "§ 164.524(b)(1)", + "§ 164.524(b)(2)(i)", + "§ 164.524(b)(2)(i)(A)", + "§ 164.524(b)(2)(i)(B)", + "§ 164.524(b)(2)(ii)", + "§ 164.524(b)(2)(ii)(A)", + "§ 164.524(b)(2)(ii)(B)", + "§ 164.524(c)", + "§ 164.524(c)(1)", + "§ 164.524(c)(3)(i)", + "§ 164.524(c)(3)(ii)", + "§ 164.524(c)(4)", + "§ 164.524(c)(4)(i)", + "§ 164.524(c)(4)(ii)", + "§ 164.524(c)(4)(iii)", + "§ 164.524(c)(4)(iv)", + "§ 164.524(d)", + "§ 164.524(d)(1)", + "§ 164.524(d)(2)" ], "PRI-06.1": [ - "164.526(a)(1)", - "164.526(a)(2)", - "164.526(a)(2)(i)", - "164.526(a)(2)(ii)", - "164.526(a)(2)(iii)", - "164.526(a)(2)(iv)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(a)(2)", + "§ 164.526(a)(2)(i)", + "§ 164.526(a)(2)(ii)", + "§ 164.526(a)(2)(iii)", + "§ 164.526(a)(2)(iv)", + "§ 164.526(b)(1)" ], "PRI-06.2": [ - "164.526(c)", - "164.526(c)(1)", - "164.526(c)(2)", - "164.526(c)(3)", - "164.526(c)(3)(i)", - "164.526(c)(3)(ii)" + "§ 164.526(c)", + "§ 164.526(c)(1)", + "§ 164.526(c)(2)", + "§ 164.526(c)(3)", + "§ 164.526(c)(3)(i)", + "§ 164.526(c)(3)(ii)" ], "PRI-06.3": [ - "164.524(d)(4)" + "§ 164.524(d)(4)" ], "PRI-06.4": [ - "164.526(b)(2)(i)", - "164.526(b)(2)(i)(A)", - "164.526(b)(2)(i)(B)", - "164.526(b)(2)(ii)", - "164.526(b)(2)(ii)(A)", - "164.526(b)(2)(ii)(B)", - "164.526(d)", - "164.526(d)(1)", - "164.526(d)(1)(i)", - "164.526(d)(1)(ii)", - "164.526(d)(1)(iii)", - "164.526(d)(1)(iv)", - "164.526(d)(2)", - "164.526(d)(3)", - "164.526(d)(4)", - "164.526(d)(5)(i)", - "164.526(d)(5)(ii)", - "164.526(d)(5)(iii)", - "164.526(e)", - "164.526(f)", - "164.530(d)(1)", - "164.530(d)(2)" + "§ 164.526(b)(2)(i)", + "§ 164.526(b)(2)(i)(A)", + "§ 164.526(b)(2)(i)(B)", + "§ 164.526(b)(2)(ii)", + "§ 164.526(b)(2)(ii)(A)", + "§ 164.526(b)(2)(ii)(B)", + "§ 164.526(d)", + "§ 164.526(d)(1)", + "§ 164.526(d)(1)(i)", + "§ 164.526(d)(1)(ii)", + "§ 164.526(d)(1)(iii)", + "§ 164.526(d)(1)(iv)", + "§ 164.526(d)(2)", + "§ 164.526(d)(3)", + "§ 164.526(d)(4)", + "§ 164.526(d)(5)(i)", + "§ 164.526(d)(5)(ii)", + "§ 164.526(d)(5)(iii)", + "§ 164.526(e)", + "§ 164.526(f)", + "§ 164.530(d)(1)", + "§ 164.530(d)(2)" ], "PRI-06.6": [ - "164.524(c)(2)(i)", - "164.524(c)(2)(ii)" + "§ 164.524(c)(2)(i)", + "§ 164.524(c)(2)(ii)" ], "PRI-07": [ - "164.506(c)(1)", - "164.506(c)(2)", - "164.506(c)(3)", - "164.506(c)(4)", - "164.508(a)(1)", - "164.508(a)(4)(i)" + "§ 164.506(c)(1)", + "§ 164.506(c)(2)", + "§ 164.506(c)(3)", + "§ 164.506(c)(4)", + "§ 164.508(a)(1)", + "§ 164.508(a)(4)(i)" ], "PRI-07.1": [ - "164.504(e)(2)(i)", - "164.504(e)(2)(ii)(A)", - "164.504(e)(2)(ii)(B)", - "164.504(e)(2)(ii)(C)", - "164.504(e)(4)(i)", - "164.504(e)(4)(i)(A)", - "164.504(e)(4)(i)(B)", - "164.504(e)(4)(i)(B)(ii)", - "164.504(e)(4)(i)(B)(ii)(A)" + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(ii)(A)", + "§ 164.504(e)(2)(ii)(B)", + "§ 164.504(e)(2)(ii)(C)", + "§ 164.504(e)(4)(i)", + "§ 164.504(e)(4)(i)(A)", + "§ 164.504(e)(4)(i)(B)", + "§ 164.504(e)(4)(i)(B)(ii)", + "§ 164.504(e)(4)(i)(B)(ii)(A)" ], "PRI-07.4": [ - "164.524(d)(2)(i)", - "164.524(d)(2)(ii)", - "164.524(d)(2)(iii)", - "164.524(d)(3)" + "§ 164.524(d)(2)(i)", + "§ 164.524(d)(2)(ii)", + "§ 164.524(d)(2)(iii)", + "§ 164.524(d)(3)" ], "PRI-10": [ - "164.512(i)(1)(i)(B)", - "164.512(i)(1)(i)(B)(1)", - "164.512(i)(1)(i)(B)(2)", - "164.512(i)(1)(i)(B)(3)" + "§ 164.512(i)(1)(i)(B)", + "§ 164.512(i)(1)(i)(B)(1)", + "§ 164.512(i)(1)(i)(B)(2)", + "§ 164.512(i)(1)(i)(B)(3)" ], "PRI-12": [ - "164.526(a)(1)", - "164.526(b)(1)", - "164.526(e)", - "164.526(f)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)", + "§ 164.526(e)", + "§ 164.526(f)" ], "PRI-14.1": [ - "164.528(a)(1)", - "164.528(a)(1)(i)", - "164.528(a)(1)(ii)", - "164.528(a)(1)(iii)", - "164.528(a)(1)(iv)", - "164.528(a)(1)(v)", - "164.528(a)(1)(vi)", - "164.528(a)(1)(vii)", - "164.528(a)(1)(viii)", - "164.528(a)(1)(ix)", - "164.528(b)", - "164.528(b)(1)", - "164.528(b)(2)", - "164.528(b)(2)(i)", - "164.528(b)(2)(ii)", - "164.528(b)(2)(iii)", - "164.528(b)(2)(iv)", - "164.528(b)(3)", - "164.528(b)(3)(i)", - "164.528(b)(3)(ii)", - "164.528(b)(3)(iii)", - "164.528(b)(4)(i)", - "164.528(b)(4)(i)(A)", - "164.528(b)(4)(i)(B)", - "164.528(b)(4)(i)(C)", - "164.528(b)(4)(i)(D)", - "164.528(b)(4)(i)(E)", - "164.528(b)(4)(i)(F)", - "164.528(b)(4)(ii)", - "164.528(c)(1)", - "164.528(c)(1)(i)", - "164.528(c)(1)(ii)", - "164.528(c)(1)(ii)(A)", - "164.528(c)(1)(ii)(B)", - "164.528(c)(2)", - "164.528(d)", - "164.528(d)(1)", - "164.528(d)(2)", - "164.528(d)(3)" + "§ 164.528(a)(1)", + "§ 164.528(a)(1)(i)", + "§ 164.528(a)(1)(ii)", + "§ 164.528(a)(1)(iii)", + "§ 164.528(a)(1)(iv)", + "§ 164.528(a)(1)(v)", + "§ 164.528(a)(1)(vi)", + "§ 164.528(a)(1)(vii)", + "§ 164.528(a)(1)(viii)", + "§ 164.528(a)(1)(ix)", + "§ 164.528(b)", + "§ 164.528(b)(1)", + "§ 164.528(b)(2)", + "§ 164.528(b)(2)(i)", + "§ 164.528(b)(2)(ii)", + "§ 164.528(b)(2)(iii)", + "§ 164.528(b)(2)(iv)", + "§ 164.528(b)(3)", + "§ 164.528(b)(3)(i)", + "§ 164.528(b)(3)(ii)", + "§ 164.528(b)(3)(iii)", + "§ 164.528(b)(4)(i)", + "§ 164.528(b)(4)(i)(A)", + "§ 164.528(b)(4)(i)(B)", + "§ 164.528(b)(4)(i)(C)", + "§ 164.528(b)(4)(i)(D)", + "§ 164.528(b)(4)(i)(E)", + "§ 164.528(b)(4)(i)(F)", + "§ 164.528(b)(4)(ii)", + "§ 164.528(c)(1)", + "§ 164.528(c)(1)(i)", + "§ 164.528(c)(1)(ii)", + "§ 164.528(c)(1)(ii)(A)", + "§ 164.528(c)(1)(ii)(B)", + "§ 164.528(c)(2)", + "§ 164.528(d)", + "§ 164.528(d)(1)", + "§ 164.528(d)(2)", + "§ 164.528(d)(3)" ], "PRM-03": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "PRM-05": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "PRM-06": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "RSK-01": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "RSK-01.1": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-02": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-03": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-03.1": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "RSK-04": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "RSK-06.2": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "SEA-01": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "SEA-02": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "SEA-02.1": [ - "164.103", - "164.304", - "164.402", - "164.501", - "164.504(a)" + "§ 164.103", + "§ 164.304", + "§ 164.402", + "§ 164.501", + "§ 164.504(a)" ], "SEA-03": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "OPS-01.1": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "OPS-03": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "SAT-01": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "SAT-02": [ - "164.308(a)(5)(i)", - "164.530(b)(2)(i)", - "164.530(b)(2)(i)(A)", - "164.530(b)(2)(i)(B)", - "164.530(b)(2)(i)(C)", - "164.530(b)(2)(ii)" + "§ 164.308(a)(5)(i)", + "§ 164.530(b)(2)(i)", + "§ 164.530(b)(2)(i)(A)", + "§ 164.530(b)(2)(i)(B)", + "§ 164.530(b)(2)(i)(C)", + "§ 164.530(b)(2)(ii)" ], "SAT-03": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)", - "164.530(b)(1)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)", + "§ 164.530(b)(1)" ], "SAT-03.2": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "SAT-03.6": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "TPM-01": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "TPM-02": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "TPM-04": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "TPM-05": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)", - "164.502(a)(4)(i)", - "164.502(a)(4)(ii)", - "164.502(e)(1)(i)", - "164.502(e)(2)", - "164.504(e)(2)(i)", - "164.504(e)(2)(i)(A)", - "164.504(e)(2)(i)(B)", - "164.504(e)(2)(ii)(J)", - "164.504(e)(4)(i)(B)(ii)(B)(1)", - "164.504(e)(4)(i)(B)(ii)(B)(2)", - "164.504(f)(1)(i)", - "164.504(f)(2)(i)", - "164.504(f)(2)(ii)", - "164.504(f)(2)(ii)(A)", - "164.504(f)(2)(ii)(B)", - "164.504(f)(2)(ii)(C)", - "164.504(f)(2)(ii)(D)", - "164.504(f)(2)(ii)(E)", - "164.504(f)(2)(ii)(F)", - "164.504(f)(2)(ii)(G)", - "164.504(f)(2)(ii)(H)", - "164.504(f)(2)(ii)(I)", - "164.504(f)(2)(ii)(J)", - "164.504(f)(2)(iii)(A)", - "164.504(f)(2)(iii)(B)", - "164.504(f)(2)(iii)(C)", - "164.504(f)(3)(i)", - "164.504(f)(3)(ii)", - "164.504(f)(3)(iii)", - "164.504(f)(3)(iv)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)", + "§ 164.502(a)(4)(i)", + "§ 164.502(a)(4)(ii)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(2)", + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(i)(A)", + "§ 164.504(e)(2)(i)(B)", + "§ 164.504(e)(2)(ii)(J)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(1)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(2)", + "§ 164.504(f)(1)(i)", + "§ 164.504(f)(2)(i)", + "§ 164.504(f)(2)(ii)", + "§ 164.504(f)(2)(ii)(A)", + "§ 164.504(f)(2)(ii)(B)", + "§ 164.504(f)(2)(ii)(C)", + "§ 164.504(f)(2)(ii)(D)", + "§ 164.504(f)(2)(ii)(E)", + "§ 164.504(f)(2)(ii)(F)", + "§ 164.504(f)(2)(ii)(G)", + "§ 164.504(f)(2)(ii)(H)", + "§ 164.504(f)(2)(ii)(I)", + "§ 164.504(f)(2)(ii)(J)", + "§ 164.504(f)(2)(iii)(A)", + "§ 164.504(f)(2)(iii)(B)", + "§ 164.504(f)(2)(iii)(C)", + "§ 164.504(f)(3)(i)", + "§ 164.504(f)(3)(ii)", + "§ 164.504(f)(3)(iii)", + "§ 164.504(f)(3)(iv)" ], "TPM-05.1": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)", - "164.410(a)(1)", - "164.410(a)(2)", - "164.410(b)", - "164.410(c)(2)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)", + "§ 164.410(a)(1)", + "§ 164.410(a)(2)", + "§ 164.410(b)", + "§ 164.410(c)(2)" ], "TPM-05.2": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)", - "164.502(e)(1)(ii)", - "164.504(e)(2)(ii)(D)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)", + "§ 164.502(e)(1)(ii)", + "§ 164.504(e)(2)(ii)(D)" ], "TPM-05.4": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "TPM-05.6": [ - "164.308(b)(2)", - "164.502(e)(1)(i)", - "164.502(e)(1)(ii)" + "§ 164.308(b)(2)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(1)(ii)" ], "TPM-05.7": [ - "164.504(e)(2)(iii)" + "§ 164.504(e)(2)(iii)" ], "THR-09": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "THR-10": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ] } }, "framework_to_scf": { "total_mappings": 576, "mappings": { - "164.306(a)(1)": [ + "§ 164.306(a)(1)": [ "GOV-01", "GOV-15", "GOV-15.1", @@ -1101,72 +1101,72 @@ "GOV-15.4", "GOV-15.5" ], - "164.306(a)(2)": [ + "§ 164.306(a)(2)": [ "GOV-01" ], - "164.306(a)(3)": [ + "§ 164.306(a)(3)": [ "GOV-01", "DCH-01", "RSK-01" ], - "164.316(a)": [ + "§ 164.316(a)": [ "GOV-01", "GOV-02" ], - "164.530(c)(1)": [ + "§ 164.530(c)(1)": [ "GOV-01" ], - "164.530(i)(1)": [ + "§ 164.530(i)(1)": [ "GOV-01", "CPL-01", "PRI-01" ], - "164.308(a)(1)(i)": [ + "§ 164.308(a)(1)(i)": [ "GOV-02", "CHG-01", "CFG-01", "MON-01", "IRO-01" ], - "164.308(a)(3)(i)": [ + "§ 164.308(a)(3)(i)": [ "GOV-02", "CFG-08", "IAC-01", "IAC-08", "IAC-21" ], - "164.308(a)(4)(i)": [ + "§ 164.308(a)(4)(i)": [ "GOV-02", "IAC-01" ], - "164.308(a)(4)(ii)(A)": [ + "§ 164.308(a)(4)(ii)(A)": [ "GOV-02" ], - "164.308(a)(6)(i)": [ + "§ 164.308(a)(6)(i)": [ "GOV-02", "IRO-01" ], - "164.308(a)(7)(i)": [ + "§ 164.308(a)(7)(i)": [ "GOV-02", "BCD-01", "IRO-01" ], - "164.310(a)(1)": [ + "§ 164.310(a)(1)": [ "GOV-02", "PES-01" ], - "164.310(a)(2)(ii)": [ + "§ 164.310(a)(2)(ii)": [ "GOV-02", "PES-01", "PES-03" ], - "164.310(a)(2)(iv)": [ + "§ 164.310(a)(2)(iv)": [ "GOV-02", "MNT-01", "MNT-02", "PES-01" ], - "164.310(b)": [ + "§ 164.310(b)": [ "GOV-02", "END-01", "HRS-05", @@ -1177,7 +1177,7 @@ "OPS-01.1", "OPS-03" ], - "164.310(d)(1)": [ + "§ 164.310(d)(1)": [ "GOV-02", "AST-01", "AST-11", @@ -1189,12 +1189,12 @@ "MNT-01", "MNT-04.3" ], - "164.310(d)(2)(i)": [ + "§ 164.310(d)(2)(i)": [ "GOV-02", "AST-01", "AST-09" ], - "164.312(a)(1)": [ + "§ 164.312(a)(1)": [ "GOV-02", "HRS-02", "HRS-03", @@ -1202,164 +1202,164 @@ "IAC-08", "IAC-21" ], - "164.312(c)(1)": [ + "§ 164.312(c)(1)": [ "GOV-02", "DCH-01", "DCH-01.2" ], - "164.316(b)(1)(i)": [ + "§ 164.316(b)(1)(i)": [ "GOV-02" ], - "164.530(j)(1)(i)": [ + "§ 164.530(j)(1)(i)": [ "GOV-02" ], - "164.306(d)(3)(ii)(B)(1)": [ + "§ 164.306(d)(3)(ii)(B)(1)": [ "GOV-02.1" ], - "164.316(b)(1)(ii)": [ + "§ 164.316(b)(1)(ii)": [ "GOV-03", "CPL-03" ], - "164.316(b)(2)(iii)": [ + "§ 164.316(b)(2)(iii)": [ "GOV-03", "CPL-02" ], - "164.530(i)(2)(i)": [ + "§ 164.530(i)(2)(i)": [ "GOV-03" ], - "164.530(i)(2)(ii)": [ + "§ 164.530(i)(2)(ii)": [ "GOV-03" ], - "164.530(i)(2)(iii)": [ + "§ 164.530(i)(2)(iii)": [ "GOV-03" ], - "164.530(i)(3)": [ + "§ 164.530(i)(3)": [ "GOV-03" ], - "164.308(a)(2)": [ + "§ 164.308(a)(2)": [ "GOV-04" ], - "164.306(b)(2)(i)": [ + "§ 164.306(b)(2)(i)": [ "GOV-08", "PRM-06" ], - "164.306(b)(1)": [ + "§ 164.306(b)(1)": [ "GOV-09", "GOV-15", "SEA-01", "SEA-02", "SEA-03" ], - "164.308(a)(1)(ii)(B)": [ + "§ 164.308(a)(1)(ii)(B)": [ "GOV-09", "GOV-15.2" ], - "164.306(d)(3)(ii)(A)": [ + "§ 164.306(d)(3)(ii)(A)": [ "GOV-15.2" ], - "164.308(a)(7)(ii)(E)": [ + "§ 164.308(a)(7)(ii)(E)": [ "AST-01", "AST-01.1", "BCD-02", "TPM-02" ], - "164.310(d)(2)(iii)": [ + "§ 164.310(d)(2)(iii)": [ "AST-02", "AST-02.1", "AST-02.9", "AST-03", "AST-03.1" ], - "164.310(d)(2)(ii)": [ + "§ 164.310(d)(2)(ii)": [ "AST-09", "DCH-09" ], - "164.308(a)(7)(ii)(C)": [ + "§ 164.308(a)(7)(ii)(C)": [ "BCD-01", "BCD-02.2" ], - "164.308(a)(7)(ii)(D)": [ + "§ 164.308(a)(7)(ii)(D)": [ "BCD-04", "BCD-05" ], - "164.310(a)(2)(i)": [ + "§ 164.310(a)(2)(i)": [ "BCD-09.2", "HRS-03", "PES-02", "PES-02.1" ], - "164.308(a)(7)(ii)(A)": [ + "§ 164.308(a)(7)(ii)(A)": [ "BCD-11" ], - "164.310(d)(2)(iv)": [ + "§ 164.310(d)(2)(iv)": [ "BCD-11" ], - "164.308(a)(7)(ii)(B)": [ + "§ 164.308(a)(7)(ii)(B)": [ "BCD-12" ], - "164.306(c)": [ + "§ 164.306(c)": [ "CPL-01" ], - "164.306(d)(1)": [ + "§ 164.306(d)(1)": [ "CPL-01" ], - "164.306(d)(2)": [ + "§ 164.306(d)(2)": [ "CPL-01" ], - "164.314(a)(1)": [ + "§ 164.314(a)(1)": [ "CPL-01" ], - "164.314(a)(2)(ii)": [ + "§ 164.314(a)(2)(ii)": [ "CPL-01" ], - "164.504(g)(1)": [ + "§ 164.504(g)(1)": [ "CPL-01" ], - "164.306(d)(3)(i)": [ + "§ 164.306(d)(3)(i)": [ "CPL-02", "CPL-03", "CPL-03.2" ], - "164.306(e)": [ + "§ 164.306(e)": [ "CPL-03.2" ], - "164.308(a)(8)": [ + "§ 164.308(a)(8)": [ "CPL-03.2", "IAO-01.1", "IAO-02" ], - "164.312(a)(2)(iii)": [ + "§ 164.312(a)(2)(iii)": [ "CFG-02", "IAC-25" ], - "164.312(e)(1)": [ + "§ 164.312(e)(1)": [ "CFG-02", "CRY-03", "NET-01" ], - "164.312(e)(2)(i)": [ + "§ 164.312(e)(2)(i)": [ "CFG-02", "CRY-04", "NET-01" ], - "164.312(e)(2)(ii)": [ + "§ 164.312(e)(2)(ii)": [ "CFG-02", "CRY-01", "OPS-03" ], - "164.312(c)(2)": [ + "§ 164.312(c)(2)": [ "CFG-08", "CFG-08.1", "MON-01.7", "MON-01.15", "MON-16" ], - "164.308(a)(1)(ii)(D)": [ + "§ 164.308(a)(1)(ii)(D)": [ "MON-01", "MON-01.8", "IRO-09" ], - "164.312(b)": [ + "§ 164.312(b)": [ "MON-01", "MON-01.4", "MON-01.8", @@ -1368,427 +1368,427 @@ "MON-03.2", "MON-16" ], - "164.312(a)(2)(iv)": [ + "§ 164.312(a)(2)(iv)": [ "CRY-01" ], - "164.514(d)(3)(i)": [ + "§ 164.514(d)(3)(i)": [ "DCH-01", "DCH-01.2", "DCH-03.1" ], - "164.530(c)(2)(i)": [ + "§ 164.530(c)(2)(i)": [ "DCH-01", "DCH-01.2" ], - "164.510(b)(1)(i)": [ + "§ 164.510(b)(1)(i)": [ "DCH-03.1" ], - "164.510(b)(1)(ii)": [ + "§ 164.510(b)(1)(ii)": [ "DCH-03.1" ], - "164.510(b)(2)": [ + "§ 164.510(b)(2)": [ "DCH-03.1" ], - "164.510(b)(4)": [ + "§ 164.510(b)(4)": [ "DCH-03.1", "PRI-05.4" ], - "164.510(b)(5)": [ + "§ 164.510(b)(5)": [ "DCH-03.1" ], - "164.512": [ + "§ 164.512": [ "DCH-03.1", "PRI-05.4" ], - "164.512(a)(1)": [ + "§ 164.512(a)(1)": [ "DCH-03.1" ], - "164.512(c)(1)": [ + "§ 164.512(c)(1)": [ "DCH-03.1" ], - "164.512(c)(1)(i)": [ + "§ 164.512(c)(1)(i)": [ "DCH-03.1" ], - "164.512(c)(1)(ii)": [ + "§ 164.512(c)(1)(ii)": [ "DCH-03.1" ], - "164.512(c)(1)(iii)(A)": [ + "§ 164.512(c)(1)(iii)(A)": [ "DCH-03.1" ], - "164.512(c)(1)(iii)(B)": [ + "§ 164.512(c)(1)(iii)(B)": [ "DCH-03.1" ], - "164.512(c)(2)": [ + "§ 164.512(c)(2)": [ "DCH-03.1" ], - "164.512(c)(2)(i)": [ + "§ 164.512(c)(2)(i)": [ "DCH-03.1" ], - "164.512(c)(2)(ii)": [ + "§ 164.512(c)(2)(ii)": [ "DCH-03.1" ], - "164.512(d)(1)": [ + "§ 164.512(d)(1)": [ "DCH-03.1" ], - "164.512(d)(1)(i)": [ + "§ 164.512(d)(1)(i)": [ "DCH-03.1" ], - "164.512(d)(1)(ii)": [ + "§ 164.512(d)(1)(ii)": [ "DCH-03.1" ], - "164.512(d)(1)(iii)": [ + "§ 164.512(d)(1)(iii)": [ "DCH-03.1" ], - "164.512(d)(1)(iv)": [ + "§ 164.512(d)(1)(iv)": [ "DCH-03.1" ], - "164.512(e)(1)": [ + "§ 164.512(e)(1)": [ "DCH-03.1" ], - "164.512(e)(1)(i)": [ + "§ 164.512(e)(1)(i)": [ "DCH-03.1" ], - "164.512(e)(1)(ii)": [ + "§ 164.512(e)(1)(ii)": [ "DCH-03.1" ], - "164.512(e)(1)(ii)(A)": [ + "§ 164.512(e)(1)(ii)(A)": [ "DCH-03.1" ], - "164.512(e)(1)(ii)(B)": [ + "§ 164.512(e)(1)(ii)(B)": [ "DCH-03.1" ], - "164.512(e)(1)(iii)": [ + "§ 164.512(e)(1)(iii)": [ "DCH-03.1" ], - "164.512(e)(1)(iii)(A)": [ + "§ 164.512(e)(1)(iii)(A)": [ "DCH-03.1" ], - "164.512(e)(1)(iii)(B)": [ + "§ 164.512(e)(1)(iii)(B)": [ "DCH-03.1" ], - "164.512(e)(1)(iii)(C)": [ + "§ 164.512(e)(1)(iii)(C)": [ "DCH-03.1" ], - "164.512(e)(1)(iii)(C)(1)": [ + "§ 164.512(e)(1)(iii)(C)(1)": [ "DCH-03.1" ], - "164.512(e)(1)(iii)(C)(2)": [ + "§ 164.512(e)(1)(iii)(C)(2)": [ "DCH-03.1" ], - "164.512(e)(1)(iv)": [ + "§ 164.512(e)(1)(iv)": [ "DCH-03.1" ], - "164.512(e)(1)(iv)(A)": [ + "§ 164.512(e)(1)(iv)(A)": [ "DCH-03.1" ], - "164.512(e)(1)(iv)(B)": [ + "§ 164.512(e)(1)(iv)(B)": [ "DCH-03.1" ], - "164.512(e)(1)(v)": [ + "§ 164.512(e)(1)(v)": [ "DCH-03.1" ], - "164.512(e)(1)(v)(A)": [ + "§ 164.512(e)(1)(v)(A)": [ "DCH-03.1" ], - "164.512(e)(1)(v)(B)": [ + "§ 164.512(e)(1)(v)(B)": [ "DCH-03.1" ], - "164.512(e)(1)(vi)": [ + "§ 164.512(e)(1)(vi)": [ "DCH-03.1" ], - "164.512(f)": [ + "§ 164.512(f)": [ "DCH-03.1" ], - "164.512(f)(1)": [ + "§ 164.512(f)(1)": [ "DCH-03.1" ], - "164.512(f)(1)(i)": [ + "§ 164.512(f)(1)(i)": [ "DCH-03.1" ], - "164.512(f)(1)(ii)(A)": [ + "§ 164.512(f)(1)(ii)(A)": [ "DCH-03.1" ], - "164.512(f)(1)(ii)(B)": [ + "§ 164.512(f)(1)(ii)(B)": [ "DCH-03.1" ], - "164.512(f)(1)(ii)(C)": [ + "§ 164.512(f)(1)(ii)(C)": [ "DCH-03.1" ], - "164.512(f)(1)(ii)(C)(1)": [ + "§ 164.512(f)(1)(ii)(C)(1)": [ "DCH-03.1" ], - "164.512(f)(1)(ii)(C)(2)": [ + "§ 164.512(f)(1)(ii)(C)(2)": [ "DCH-03.1" ], - "164.512(f)(1)(ii)(C)(3)": [ + "§ 164.512(f)(1)(ii)(C)(3)": [ "DCH-03.1" ], - "164.512(f)(2)": [ + "§ 164.512(f)(2)": [ "DCH-03.1" ], - "164.512(f)(2)(i)(A)": [ + "§ 164.512(f)(2)(i)(A)": [ "DCH-03.1" ], - "164.512(f)(2)(i)(B)": [ + "§ 164.512(f)(2)(i)(B)": [ "DCH-03.1" ], - "164.512(f)(2)(i)(C)": [ + "§ 164.512(f)(2)(i)(C)": [ "DCH-03.1" ], - "164.512(f)(2)(i)(D)": [ + "§ 164.512(f)(2)(i)(D)": [ "DCH-03.1" ], - "164.512(f)(2)(i)(E)": [ + "§ 164.512(f)(2)(i)(E)": [ "DCH-03.1" ], - "164.512(f)(2)(i)(F)": [ + "§ 164.512(f)(2)(i)(F)": [ "DCH-03.1" ], - "164.512(f)(2)(i)(G)": [ + "§ 164.512(f)(2)(i)(G)": [ "DCH-03.1" ], - "164.512(f)(2)(i)(H)": [ + "§ 164.512(f)(2)(i)(H)": [ "DCH-03.1" ], - "164.512(f)(2)(ii)": [ + "§ 164.512(f)(2)(ii)": [ "DCH-03.1" ], - "164.512(f)(3)": [ + "§ 164.512(f)(3)": [ "DCH-03.1" ], - "164.512(f)(3)(i)": [ + "§ 164.512(f)(3)(i)": [ "DCH-03.1" ], - "164.512(f)(3)(ii)": [ + "§ 164.512(f)(3)(ii)": [ "DCH-03.1" ], - "164.512(f)(3)(ii)(A)": [ + "§ 164.512(f)(3)(ii)(A)": [ "DCH-03.1" ], - "164.512(f)(3)(ii)(B)": [ + "§ 164.512(f)(3)(ii)(B)": [ "DCH-03.1" ], - "164.512(f)(3)(ii)(C)": [ + "§ 164.512(f)(3)(ii)(C)": [ "DCH-03.1" ], - "164.512(f)(4)": [ + "§ 164.512(f)(4)": [ "DCH-03.1" ], - "164.512(f)(5)": [ + "§ 164.512(f)(5)": [ "DCH-03.1" ], - "164.512(f)(6)(i)": [ + "§ 164.512(f)(6)(i)": [ "DCH-03.1" ], - "164.512(f)(6)(i)(A)": [ + "§ 164.512(f)(6)(i)(A)": [ "DCH-03.1" ], - "164.512(f)(6)(i)(B)": [ + "§ 164.512(f)(6)(i)(B)": [ "DCH-03.1" ], - "164.512(f)(6)(i)(C)": [ + "§ 164.512(f)(6)(i)(C)": [ "DCH-03.1" ], - "164.512(f)(6)(ii)": [ + "§ 164.512(f)(6)(ii)": [ "DCH-03.1" ], - "164.512(g)(1)": [ + "§ 164.512(g)(1)": [ "DCH-03.1" ], - "164.512(g)(2)": [ + "§ 164.512(g)(2)": [ "DCH-03.1" ], - "164.512(h)": [ + "§ 164.512(h)": [ "DCH-03.1" ], - "164.512(i)(1)": [ + "§ 164.512(i)(1)": [ "DCH-03.1", "PRI-05.4" ], - "164.512(j)(1)": [ + "§ 164.512(j)(1)": [ "DCH-03.1", "PRI-05.4" ], - "164.514(d)(3)(ii)(A)": [ + "§ 164.514(d)(3)(ii)(A)": [ "DCH-03.1" ], - "164.514(d)(3)(ii)(B)": [ + "§ 164.514(d)(3)(ii)(B)": [ "DCH-03.1" ], - "164.514(d)(3)(iii)": [ + "§ 164.514(d)(3)(iii)": [ "DCH-03.1" ], - "164.514(d)(3)(iii)(A)": [ + "§ 164.514(d)(3)(iii)(A)": [ "DCH-03.1" ], - "164.514(d)(3)(iii)(B)": [ + "§ 164.514(d)(3)(iii)(B)": [ "DCH-03.1" ], - "164.514(d)(3)(iii)(C)": [ + "§ 164.514(d)(3)(iii)(C)": [ "DCH-03.1" ], - "164.514(d)(3)(iii)(D)": [ + "§ 164.514(d)(3)(iii)(D)": [ "DCH-03.1" ], - "164.514(d)(4)": [ + "§ 164.514(d)(4)": [ "DCH-03.1" ], - "164.514(d)(4)(i)": [ + "§ 164.514(d)(4)(i)": [ "DCH-03.1" ], - "164.514(d)(4)(ii)": [ + "§ 164.514(d)(4)(ii)": [ "DCH-03.1" ], - "164.514(d)(4)(iii)(A)": [ + "§ 164.514(d)(4)(iii)(A)": [ "DCH-03.1" ], - "164.514(d)(4)(iii)(B)": [ + "§ 164.514(d)(4)(iii)(B)": [ "DCH-03.1" ], - "164.514(d)(5)": [ + "§ 164.514(d)(5)": [ "DCH-03.1" ], - "164.514(e)(1)": [ + "§ 164.514(e)(1)": [ "DCH-03.1" ], - "164.514(e)(2)": [ + "§ 164.514(e)(2)": [ "DCH-03.1" ], - "164.514(e)(2)(i)": [ + "§ 164.514(e)(2)(i)": [ "DCH-03.1" ], - "164.514(e)(2)(ii)": [ + "§ 164.514(e)(2)(ii)": [ "DCH-03.1" ], - "164.514(e)(2)(iii)": [ + "§ 164.514(e)(2)(iii)": [ "DCH-03.1" ], - "164.514(e)(2)(iv)": [ + "§ 164.514(e)(2)(iv)": [ "DCH-03.1" ], - "164.514(e)(2)(v)": [ + "§ 164.514(e)(2)(v)": [ "DCH-03.1" ], - "164.514(e)(2)(vi)": [ + "§ 164.514(e)(2)(vi)": [ "DCH-03.1" ], - "164.514(e)(2)(vii)": [ + "§ 164.514(e)(2)(vii)": [ "DCH-03.1" ], - "164.514(e)(2)(viii)": [ + "§ 164.514(e)(2)(viii)": [ "DCH-03.1" ], - "164.514(e)(2)(ix)": [ + "§ 164.514(e)(2)(ix)": [ "DCH-03.1" ], - "164.514(e)(2)(x)": [ + "§ 164.514(e)(2)(x)": [ "DCH-03.1" ], - "164.514(e)(2)(xi)": [ + "§ 164.514(e)(2)(xi)": [ "DCH-03.1" ], - "164.514(e)(2)(xii)": [ + "§ 164.514(e)(2)(xii)": [ "DCH-03.1" ], - "164.514(e)(2)(xiii)": [ + "§ 164.514(e)(2)(xiii)": [ "DCH-03.1" ], - "164.514(e)(2)(xiv)": [ + "§ 164.514(e)(2)(xiv)": [ "DCH-03.1" ], - "164.514(e)(2)(xv)": [ + "§ 164.514(e)(2)(xv)": [ "DCH-03.1" ], - "164.514(e)(2)(xvi)": [ + "§ 164.514(e)(2)(xvi)": [ "DCH-03.1" ], - "164.514(e)(3)(i)": [ + "§ 164.514(e)(3)(i)": [ "DCH-03.1" ], - "164.514(e)(3)(ii)": [ + "§ 164.514(e)(3)(ii)": [ "DCH-03.1" ], - "164.514(e)(4)(i)": [ + "§ 164.514(e)(4)(i)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)": [ + "§ 164.514(e)(4)(ii)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)(A)": [ + "§ 164.514(e)(4)(ii)(A)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)(B)": [ + "§ 164.514(e)(4)(ii)(B)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)(C)": [ + "§ 164.514(e)(4)(ii)(C)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)(C)(1)": [ + "§ 164.514(e)(4)(ii)(C)(1)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)(C)(2)": [ + "§ 164.514(e)(4)(ii)(C)(2)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)(C)(3)": [ + "§ 164.514(e)(4)(ii)(C)(3)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)(C)(4)": [ + "§ 164.514(e)(4)(ii)(C)(4)": [ "DCH-03.1" ], - "164.514(e)(4)(ii)(C)(5)": [ + "§ 164.514(e)(4)(ii)(C)(5)": [ "DCH-03.1" ], - "164.532(a)": [ + "§ 164.532(a)": [ "DCH-03.1", "PRI-05.4" ], - "164.532(b)": [ + "§ 164.532(b)": [ "DCH-03.1", "PRI-05.4" ], - "164.532(c)": [ + "§ 164.532(c)": [ "DCH-03.1", "PRI-05.4" ], - "164.532(c)(1)": [ + "§ 164.532(c)(1)": [ "DCH-03.1" ], - "164.532(d)": [ + "§ 164.532(d)": [ "DCH-03.1" ], - "164.316(b)(2)(i)": [ + "§ 164.316(b)(2)(i)": [ "DCH-18" ], - "164.530(j)(2)": [ + "§ 164.530(j)(2)": [ "DCH-18" ], - "164.502(b)(1)": [ + "§ 164.502(b)(1)": [ "DCH-18.1" ], - "164.526(a)(1)": [ + "§ 164.526(a)(1)": [ "DCH-22.1", "PRI-06.1", "PRI-12" ], - "164.526(b)(1)": [ + "§ 164.526(b)(1)": [ "DCH-22.1", "PRI-06.1", "PRI-12" ], - "164.310(c)": [ + "§ 164.310(c)": [ "END-02", "PES-03", "PES-03.4", "PES-04", "PES-04.1" ], - "164.308(a)(3)(ii)(A)": [ + "§ 164.308(a)(3)(ii)(A)": [ "HRS-01", "IAC-07.1", "IAC-08", "IAC-28.1" ], - "164.312(d)": [ + "§ 164.312(d)": [ "HRS-01", "HRS-04", "IAC-28", @@ -1796,988 +1796,988 @@ "IAC-28.3", "TPM-01" ], - "164.530(e)(2)": [ + "§ 164.530(e)(2)": [ "HRS-01" ], - "164.308(a)(3)(ii)(B)": [ + "§ 164.308(a)(3)(ii)(B)": [ "HRS-02", "HRS-03", "IAC-17" ], - "164.530(a)(2)": [ + "§ 164.530(a)(2)": [ "HRS-02", "HRS-03" ], - "164.530(b)(1)": [ + "§ 164.530(b)(1)": [ "HRS-05.7", "SAT-03" ], - "164.502(a)": [ + "§ 164.502(a)": [ "HRS-06.1", "PRI-01" ], - "164.308(a)(1)(ii)(C)": [ + "§ 164.308(a)(1)(ii)(C)": [ "HRS-07" ], - "164.530(e)(1)": [ + "§ 164.530(e)(1)": [ "HRS-07" ], - "164.308(a)(3)(ii)(C)": [ + "§ 164.308(a)(3)(ii)(C)": [ "HRS-08", "HRS-09", "IAC-07", "IAC-07.2" ], - "164.308(a)(4)(ii)(B)": [ + "§ 164.308(a)(4)(ii)(B)": [ "IAC-01" ], - "164.310(a)(2)(iii)": [ + "§ 164.310(a)(2)(iii)": [ "IAC-01", "PES-02", "PES-03", "PES-06" ], - "164.530(c)(2)(ii)": [ + "§ 164.530(c)(2)(ii)": [ "IAC-01", "IAC-08" ], - "164.312(a)(2)(i)": [ + "§ 164.312(a)(2)(i)": [ "IAC-02", "IAC-09" ], - "164.308(a)(4)(ii)(C)": [ + "§ 164.308(a)(4)(ii)(C)": [ "IAC-08" ], - "164.514(d)(2)(i)(A)": [ + "§ 164.514(d)(2)(i)(A)": [ "IAC-08" ], - "164.514(d)(2)(i)(B)": [ + "§ 164.514(d)(2)(i)(B)": [ "IAC-08" ], - "164.514(d)(2)(ii)": [ + "§ 164.514(d)(2)(ii)": [ "IAC-08" ], - "164.312(a)(2)(ii)": [ + "§ 164.312(a)(2)(ii)": [ "IAC-15", "IAC-15.2", "IAC-15.9" ], - "164.308(a)(6)(ii)": [ + "§ 164.308(a)(6)(ii)": [ "IRO-02" ], - "164.412": [ + "§ 164.412": [ "IRO-02" ], - "164.412(a)": [ + "§ 164.412(a)": [ "IRO-02" ], - "164.412(b)": [ + "§ 164.412(b)": [ "IRO-02" ], - "164.530(f)": [ + "§ 164.530(f)": [ "IRO-02" ], - "164.404(a)(1)": [ + "§ 164.404(a)(1)": [ "IRO-04.1" ], - "164.404(a)(2)": [ + "§ 164.404(a)(2)": [ "IRO-04.1" ], - "164.404(c)(1)(A)": [ + "§ 164.404(c)(1)(A)": [ "IRO-04.1" ], - "164.404(c)(1)(B)": [ + "§ 164.404(c)(1)(B)": [ "IRO-04.1" ], - "164.404(c)(1)(C)": [ + "§ 164.404(c)(1)(C)": [ "IRO-04.1" ], - "164.404(c)(1)(D)": [ + "§ 164.404(c)(1)(D)": [ "IRO-04.1" ], - "164.404(c)(1)(E)": [ + "§ 164.404(c)(1)(E)": [ "IRO-04.1" ], - "164.404(c)(2)": [ + "§ 164.404(c)(2)": [ "IRO-04.1" ], - "164.404(d)(1)(i)": [ + "§ 164.404(d)(1)(i)": [ "IRO-04.1" ], - "164.404(d)(1)(ii)": [ + "§ 164.404(d)(1)(ii)": [ "IRO-04.1" ], - "164.404(d)(2)": [ + "§ 164.404(d)(2)": [ "IRO-04.1" ], - "164.404(d)(2)(i)": [ + "§ 164.404(d)(2)(i)": [ "IRO-04.1" ], - "164.404(d)(2)(ii)(A)": [ + "§ 164.404(d)(2)(ii)(A)": [ "IRO-04.1" ], - "164.404(d)(2)(ii)(B)": [ + "§ 164.404(d)(2)(ii)(B)": [ "IRO-04.1" ], - "164.404(d)(3)": [ + "§ 164.404(d)(3)": [ "IRO-04.1" ], - "164.406(a)": [ + "§ 164.406(a)": [ "IRO-04.1" ], - "164.406(b)": [ + "§ 164.406(b)": [ "IRO-04.1" ], - "164.406(c)": [ + "§ 164.406(c)": [ "IRO-04.1" ], - "164.410(c)(1)": [ + "§ 164.410(c)(1)": [ "IRO-04.1" ], - "164.404(b)": [ + "§ 164.404(b)": [ "IRO-10" ], - "164.408(a)": [ + "§ 164.408(a)": [ "IRO-10" ], - "164.408(b)": [ + "§ 164.408(b)": [ "IRO-10" ], - "164.408(c)": [ + "§ 164.408(c)": [ "IRO-10" ], - "164.410(a)(1)": [ + "§ 164.410(a)(1)": [ "IRO-10.2", "TPM-05.1" ], - "164.308(b)(3)": [ + "§ 164.308(b)(3)": [ "IAO-03.2", "TPM-05" ], - "164.530(a)(1)(i)": [ + "§ 164.530(a)(1)(i)": [ "PRI-01", "PRI-01.1" ], - "164.530(i)(4)(i)(A)": [ + "§ 164.530(i)(4)(i)(A)": [ "PRI-01" ], - "164.530(i)(4)(i)(B)": [ + "§ 164.530(i)(4)(i)(B)": [ "PRI-01" ], - "164.530(i)(5)": [ + "§ 164.530(i)(5)": [ "PRI-01" ], - "164.530(i)(5)(i)": [ + "§ 164.530(i)(5)(i)": [ "PRI-01" ], - "164.530(i)(5)(ii)": [ + "§ 164.530(i)(5)(ii)": [ "PRI-01" ], - "164.530(a)(1)(ii)": [ + "§ 164.530(a)(1)(ii)": [ "PRI-01.4" ], - "164.520(a)(1)": [ + "§ 164.520(a)(1)": [ "PRI-02" ], - "164.520(a)(2)(i)": [ + "§ 164.520(a)(2)(i)": [ "PRI-02" ], - "164.520(a)(2)(i)(A)": [ + "§ 164.520(a)(2)(i)(A)": [ "PRI-02" ], - "164.520(a)(2)(i)(B)": [ + "§ 164.520(a)(2)(i)(B)": [ "PRI-02" ], - "164.520(a)(2)(ii)": [ + "§ 164.520(a)(2)(ii)": [ "PRI-02" ], - "164.520(a)(2)(ii)(A)": [ + "§ 164.520(a)(2)(ii)(A)": [ "PRI-02" ], - "164.520(a)(2)(ii)(B)": [ + "§ 164.520(a)(2)(ii)(B)": [ "PRI-02" ], - "164.520(a)(2)(iii)": [ + "§ 164.520(a)(2)(iii)": [ "PRI-02" ], - "164.520(b)(1)": [ + "§ 164.520(b)(1)": [ "PRI-02" ], - "164.520(b)(1)(i)": [ + "§ 164.520(b)(1)(i)": [ "PRI-02" ], - "164.520(b)(1)(ii)": [ + "§ 164.520(b)(1)(ii)": [ "PRI-02" ], - "164.520(b)(1)(ii)(A)": [ + "§ 164.520(b)(1)(ii)(A)": [ "PRI-02" ], - "164.520(b)(1)(ii)(B)": [ + "§ 164.520(b)(1)(ii)(B)": [ "PRI-02" ], - "164.520(b)(1)(ii)(C)": [ + "§ 164.520(b)(1)(ii)(C)": [ "PRI-02" ], - "164.520(b)(1)(ii)(D)": [ + "§ 164.520(b)(1)(ii)(D)": [ "PRI-02" ], - "164.520(b)(1)(ii)(E)": [ + "§ 164.520(b)(1)(ii)(E)": [ "PRI-02" ], - "164.520(b)(1)(iv)": [ + "§ 164.520(b)(1)(iv)": [ "PRI-02" ], - "164.520(b)(1)(iv)(A)": [ + "§ 164.520(b)(1)(iv)(A)": [ "PRI-02" ], - "164.520(b)(1)(iv)(B)": [ + "§ 164.520(b)(1)(iv)(B)": [ "PRI-02" ], - "164.520(b)(1)(iv)(C)": [ + "§ 164.520(b)(1)(iv)(C)": [ "PRI-02" ], - "164.520(b)(1)(iv)(D)": [ + "§ 164.520(b)(1)(iv)(D)": [ "PRI-02" ], - "164.520(b)(1)(iv)(E)": [ + "§ 164.520(b)(1)(iv)(E)": [ "PRI-02" ], - "164.520(b)(1)(iv)(F)": [ + "§ 164.520(b)(1)(iv)(F)": [ "PRI-02" ], - "164.520(b)(1)(v)": [ + "§ 164.520(b)(1)(v)": [ "PRI-02" ], - "164.520(b)(1)(v)(A)": [ + "§ 164.520(b)(1)(v)(A)": [ "PRI-02" ], - "164.520(b)(1)(v)(B)": [ + "§ 164.520(b)(1)(v)(B)": [ "PRI-02" ], - "164.520(b)(1)(v)(C)": [ + "§ 164.520(b)(1)(v)(C)": [ "PRI-02" ], - "164.520(b)(1)(vi)": [ + "§ 164.520(b)(1)(vi)": [ "PRI-02" ], - "164.520(b)(1)(vii)": [ + "§ 164.520(b)(1)(vii)": [ "PRI-02" ], - "164.520(b)(1)(viii)": [ + "§ 164.520(b)(1)(viii)": [ "PRI-02" ], - "164.520(b)(2)(i)": [ + "§ 164.520(b)(2)(i)": [ "PRI-02" ], - "164.520(b)(2)(ii)": [ + "§ 164.520(b)(2)(ii)": [ "PRI-02" ], - "164.520(b)(3)": [ + "§ 164.520(b)(3)": [ "PRI-02" ], - "164.520(c)": [ + "§ 164.520(c)": [ "PRI-02" ], - "164.520(c)(1)(i)": [ + "§ 164.520(c)(1)(i)": [ "PRI-02" ], - "164.520(c)(1)(i)(A)": [ + "§ 164.520(c)(1)(i)(A)": [ "PRI-02" ], - "164.520(c)(1)(i)(B)": [ + "§ 164.520(c)(1)(i)(B)": [ "PRI-02" ], - "164.520(c)(1)(ii)": [ + "§ 164.520(c)(1)(ii)": [ "PRI-02" ], - "164.520(c)(1)(iii)": [ + "§ 164.520(c)(1)(iii)": [ "PRI-02" ], - "164.520(c)(1)(iv)": [ + "§ 164.520(c)(1)(iv)": [ "PRI-02" ], - "164.520(c)(1)(v)": [ + "§ 164.520(c)(1)(v)": [ "PRI-02" ], - "164.520(c)(1)(v)(A)": [ + "§ 164.520(c)(1)(v)(A)": [ "PRI-02" ], - "164.520(c)(1)(v)(B)": [ + "§ 164.520(c)(1)(v)(B)": [ "PRI-02" ], - "164.530(i)(4)(i)(C)": [ + "§ 164.530(i)(4)(i)(C)": [ "PRI-02" ], - "164.502(a)(3)": [ + "§ 164.502(a)(3)": [ "PRI-02.1" ], - "164.508(c)(1)(i)": [ + "§ 164.508(c)(1)(i)": [ "PRI-02.1" ], - "164.508(c)(1)(ii)": [ + "§ 164.508(c)(1)(ii)": [ "PRI-02.1" ], - "164.508(c)(1)(iii)": [ + "§ 164.508(c)(1)(iii)": [ "PRI-02.1" ], - "164.508(c)(1)(iv)": [ + "§ 164.508(c)(1)(iv)": [ "PRI-02.1" ], - "164.508(c)(2)(i)(A)": [ + "§ 164.508(c)(2)(i)(A)": [ "PRI-02.1" ], - "164.508(c)(2)(i)(B)": [ + "§ 164.508(c)(2)(i)(B)": [ "PRI-02.1" ], - "164.506(b)(1)": [ + "§ 164.506(b)(1)": [ "PRI-03" ], - "164.508(a)(2)": [ + "§ 164.508(a)(2)": [ "PRI-03" ], - "164.508(c)(1)(v)": [ + "§ 164.508(c)(1)(v)": [ "PRI-03" ], - "164.508(c)(3)": [ + "§ 164.508(c)(3)": [ "PRI-03" ], - "164.510(b)(2)(i)": [ + "§ 164.510(b)(2)(i)": [ "PRI-03" ], - "164.510(b)(2)(ii)": [ + "§ 164.510(b)(2)(ii)": [ "PRI-03" ], - "164.510(b)(2)(iii)": [ + "§ 164.510(b)(2)(iii)": [ "PRI-03" ], - "164.510(b)(3)": [ + "§ 164.510(b)(3)": [ "PRI-03" ], - "164.514(f)(2)(ii)": [ + "§ 164.514(f)(2)(ii)": [ "PRI-03" ], - "164.514(f)(2)(iv)": [ + "§ 164.514(f)(2)(iv)": [ "PRI-03" ], - "164.514(f)(2)(v)": [ + "§ 164.514(f)(2)(v)": [ "PRI-03" ], - "164.502(a)(5)(ii)(A)": [ + "§ 164.502(a)(5)(ii)(A)": [ "PRI-03.3" ], - "164.508(c)(2)(ii)(A)": [ + "§ 164.508(c)(2)(ii)(A)": [ "PRI-03.5" ], - "164.508(c)(2)(ii)(B)": [ + "§ 164.508(c)(2)(ii)(B)": [ "PRI-03.5" ], - "164.514(f)(2)(iii)": [ + "§ 164.514(f)(2)(iii)": [ "PRI-03.5" ], - "164.502(g)(1)": [ + "§ 164.502(g)(1)": [ "PRI-03.6" ], - "164.502(g)(2)": [ + "§ 164.502(g)(2)": [ "PRI-03.6" ], - "164.502(g)(3)(i)": [ + "§ 164.502(g)(3)(i)": [ "PRI-03.6" ], - "164.502(g)(3)(i)(A)": [ + "§ 164.502(g)(3)(i)(A)": [ "PRI-03.6" ], - "164.502(a)(1)(i)": [ + "§ 164.502(a)(1)(i)": [ "PRI-04.1" ], - "164.502(a)(1)(ii)": [ + "§ 164.502(a)(1)(ii)": [ "PRI-04.1" ], - "164.502(a)(1)(iii)": [ + "§ 164.502(a)(1)(iii)": [ "PRI-04.1" ], - "164.502(a)(5)(i)": [ + "§ 164.502(a)(5)(i)": [ "PRI-04.1" ], - "164.502(i)": [ + "§ 164.502(i)": [ "PRI-04.1" ], - "164.508(a)(2)(i)(B)": [ + "§ 164.508(a)(2)(i)(B)": [ "PRI-05.1" ], - "164.502(c)": [ + "§ 164.502(c)": [ "PRI-05.4" ], - "164.502(d)(1)": [ + "§ 164.502(d)(1)": [ "PRI-05.4" ], - "164.504(g)(2)": [ + "§ 164.504(g)(2)": [ "PRI-05.4" ], - "164.506(a)": [ + "§ 164.506(a)": [ "PRI-05.4" ], - "164.506(c)(1)": [ + "§ 164.506(c)(1)": [ "PRI-05.4", "PRI-07" ], - "164.506(c)(5)": [ + "§ 164.506(c)(5)": [ "PRI-05.4" ], - "164.508(a)(1)": [ + "§ 164.508(a)(1)": [ "PRI-05.4", "PRI-07" ], - "164.508(a)(2)(i)(C)": [ + "§ 164.508(a)(2)(i)(C)": [ "PRI-05.4" ], - "164.510(a)(1)(i)(A)": [ + "§ 164.510(a)(1)(i)(A)": [ "PRI-05.4" ], - "164.510(a)(1)(i)(B)": [ + "§ 164.510(a)(1)(i)(B)": [ "PRI-05.4" ], - "164.510(a)(1)(i)(C)": [ + "§ 164.510(a)(1)(i)(C)": [ "PRI-05.4" ], - "164.510(a)(1)(i)(D)": [ + "§ 164.510(a)(1)(i)(D)": [ "PRI-05.4" ], - "164.510(a)(1)(ii)(A)": [ + "§ 164.510(a)(1)(ii)(A)": [ "PRI-05.4" ], - "164.510(a)(1)(ii)(B)": [ + "§ 164.510(a)(1)(ii)(B)": [ "PRI-05.4" ], - "164.512(j)(1)(i)(A)": [ + "§ 164.512(j)(1)(i)(A)": [ "PRI-05.4" ], - "164.512(j)(1)(i)(B)": [ + "§ 164.512(j)(1)(i)(B)": [ "PRI-05.4" ], - "164.512(j)(1)(ii)": [ + "§ 164.512(j)(1)(ii)": [ "PRI-05.4" ], - "164.512(j)(1)(ii)(A)": [ + "§ 164.512(j)(1)(ii)(A)": [ "PRI-05.4" ], - "164.512(j)(1)(ii)(B)": [ + "§ 164.512(j)(1)(ii)(B)": [ "PRI-05.4" ], - "164.512(j)(2)(i)": [ + "§ 164.512(j)(2)(i)": [ "PRI-05.4" ], - "164.512(j)(2)(ii)": [ + "§ 164.512(j)(2)(ii)": [ "PRI-05.4" ], - "164.512(j)(3)": [ + "§ 164.512(j)(3)": [ "PRI-05.4" ], - "164.512(j)(4)": [ + "§ 164.512(j)(4)": [ "PRI-05.4" ], - "164.512(k)(1)(i)": [ + "§ 164.512(k)(1)(i)": [ "PRI-05.4" ], - "164.512(k)(1)(i)(A)": [ + "§ 164.512(k)(1)(i)(A)": [ "PRI-05.4" ], - "164.512(k)(1)(i)(B)": [ + "§ 164.512(k)(1)(i)(B)": [ "PRI-05.4" ], - "164.512(k)(1)(ii)": [ + "§ 164.512(k)(1)(ii)": [ "PRI-05.4" ], - "164.512(k)(1)(iii)": [ + "§ 164.512(k)(1)(iii)": [ "PRI-05.4" ], - "164.512(k)(1)(iv)": [ + "§ 164.512(k)(1)(iv)": [ "PRI-05.4" ], - "164.512(k)(2)": [ + "§ 164.512(k)(2)": [ "PRI-05.4" ], - "164.512(k)(3)": [ + "§ 164.512(k)(3)": [ "PRI-05.4" ], - "164.512(k)(4)": [ + "§ 164.512(k)(4)": [ "PRI-05.4" ], - "164.512(k)(4)(i)": [ + "§ 164.512(k)(4)(i)": [ "PRI-05.4" ], - "164.512(k)(4)(ii)": [ + "§ 164.512(k)(4)(ii)": [ "PRI-05.4" ], - "164.512(k)(4)(iii)": [ + "§ 164.512(k)(4)(iii)": [ "PRI-05.4" ], - "164.512(k)(5)(i)": [ + "§ 164.512(k)(5)(i)": [ "PRI-05.4" ], - "164.512(k)(5)(i)(A)": [ + "§ 164.512(k)(5)(i)(A)": [ "PRI-05.4" ], - "164.512(k)(5)(i)(B)": [ + "§ 164.512(k)(5)(i)(B)": [ "PRI-05.4" ], - "164.512(k)(5)(i)(C)": [ + "§ 164.512(k)(5)(i)(C)": [ "PRI-05.4" ], - "164.512(k)(5)(i)(D)": [ + "§ 164.512(k)(5)(i)(D)": [ "PRI-05.4" ], - "164.512(k)(5)(i)(E)": [ + "§ 164.512(k)(5)(i)(E)": [ "PRI-05.4" ], - "164.512(k)(5)(i)(F)": [ + "§ 164.512(k)(5)(i)(F)": [ "PRI-05.4" ], - "164.512(k)(5)(ii)": [ + "§ 164.512(k)(5)(ii)": [ "PRI-05.4" ], - "164.512(k)(5)(iii)": [ + "§ 164.512(k)(5)(iii)": [ "PRI-05.4" ], - "164.512(k)(6)(i)": [ + "§ 164.512(k)(6)(i)": [ "PRI-05.4" ], - "164.512(k)(6)(ii)": [ + "§ 164.512(k)(6)(ii)": [ "PRI-05.4" ], - "164.512(k)(6)(ii)(1)": [ + "§ 164.512(k)(6)(ii)(1)": [ "PRI-05.4" ], - "164.514(f)(2)(i)": [ + "§ 164.514(f)(2)(i)": [ "PRI-05.4" ], - "164.514(g)": [ + "§ 164.514(g)": [ "PRI-05.4" ], - "164.530(i)(4)(ii)": [ + "§ 164.530(i)(4)(ii)": [ "PRI-05.4" ], - "164.530(i)(4)(ii)(B)": [ + "§ 164.530(i)(4)(ii)(B)": [ "PRI-05.4" ], - "164.502(a)(2)(i)": [ + "§ 164.502(a)(2)(i)": [ "PRI-06" ], - "164.502(a)(2)(ii)": [ + "§ 164.502(a)(2)(ii)": [ "PRI-06" ], - "164.514(h)(1)(i)": [ + "§ 164.514(h)(1)(i)": [ "PRI-06" ], - "164.514(h)(1)(ii)": [ + "§ 164.514(h)(1)(ii)": [ "PRI-06" ], - "164.524(a)(1)": [ + "§ 164.524(a)(1)": [ "PRI-06" ], - "164.524(a)(1)(i)": [ + "§ 164.524(a)(1)(i)": [ "PRI-06" ], - "164.524(a)(1)(ii)": [ + "§ 164.524(a)(1)(ii)": [ "PRI-06" ], - "164.524(a)(1)(iii)": [ + "§ 164.524(a)(1)(iii)": [ "PRI-06" ], - "164.524(a)(1)(iii)(A)": [ + "§ 164.524(a)(1)(iii)(A)": [ "PRI-06" ], - "164.524(a)(1)(iii)(B)": [ + "§ 164.524(a)(1)(iii)(B)": [ "PRI-06" ], - "164.524(a)(2)": [ + "§ 164.524(a)(2)": [ "PRI-06" ], - "164.524(a)(2)(i)": [ + "§ 164.524(a)(2)(i)": [ "PRI-06" ], - "164.524(a)(2)(ii)": [ + "§ 164.524(a)(2)(ii)": [ "PRI-06" ], - "164.524(a)(2)(iii)": [ + "§ 164.524(a)(2)(iii)": [ "PRI-06" ], - "164.524(a)(2)(iv)": [ + "§ 164.524(a)(2)(iv)": [ "PRI-06" ], - "164.524(a)(2)(v)": [ + "§ 164.524(a)(2)(v)": [ "PRI-06" ], - "164.524(a)(3)": [ + "§ 164.524(a)(3)": [ "PRI-06" ], - "164.524(a)(3)(i)": [ + "§ 164.524(a)(3)(i)": [ "PRI-06" ], - "164.524(a)(3)(ii)": [ + "§ 164.524(a)(3)(ii)": [ "PRI-06" ], - "164.524(a)(3)(iii)": [ + "§ 164.524(a)(3)(iii)": [ "PRI-06" ], - "164.524(a)(4)": [ + "§ 164.524(a)(4)": [ "PRI-06" ], - "164.524(b)(1)": [ + "§ 164.524(b)(1)": [ "PRI-06" ], - "164.524(b)(2)(i)": [ + "§ 164.524(b)(2)(i)": [ "PRI-06" ], - "164.524(b)(2)(i)(A)": [ + "§ 164.524(b)(2)(i)(A)": [ "PRI-06" ], - "164.524(b)(2)(i)(B)": [ + "§ 164.524(b)(2)(i)(B)": [ "PRI-06" ], - "164.524(b)(2)(ii)": [ + "§ 164.524(b)(2)(ii)": [ "PRI-06" ], - "164.524(b)(2)(ii)(A)": [ + "§ 164.524(b)(2)(ii)(A)": [ "PRI-06" ], - "164.524(b)(2)(ii)(B)": [ + "§ 164.524(b)(2)(ii)(B)": [ "PRI-06" ], - "164.524(c)": [ + "§ 164.524(c)": [ "PRI-06" ], - "164.524(c)(1)": [ + "§ 164.524(c)(1)": [ "PRI-06" ], - "164.524(c)(3)(i)": [ + "§ 164.524(c)(3)(i)": [ "PRI-06" ], - "164.524(c)(3)(ii)": [ + "§ 164.524(c)(3)(ii)": [ "PRI-06" ], - "164.524(c)(4)": [ + "§ 164.524(c)(4)": [ "PRI-06" ], - "164.524(c)(4)(i)": [ + "§ 164.524(c)(4)(i)": [ "PRI-06" ], - "164.524(c)(4)(ii)": [ + "§ 164.524(c)(4)(ii)": [ "PRI-06" ], - "164.524(c)(4)(iii)": [ + "§ 164.524(c)(4)(iii)": [ "PRI-06" ], - "164.524(c)(4)(iv)": [ + "§ 164.524(c)(4)(iv)": [ "PRI-06" ], - "164.524(d)": [ + "§ 164.524(d)": [ "PRI-06" ], - "164.524(d)(1)": [ + "§ 164.524(d)(1)": [ "PRI-06" ], - "164.524(d)(2)": [ + "§ 164.524(d)(2)": [ "PRI-06" ], - "164.526(a)(2)": [ + "§ 164.526(a)(2)": [ "PRI-06.1" ], - "164.526(a)(2)(i)": [ + "§ 164.526(a)(2)(i)": [ "PRI-06.1" ], - "164.526(a)(2)(ii)": [ + "§ 164.526(a)(2)(ii)": [ "PRI-06.1" ], - "164.526(a)(2)(iii)": [ + "§ 164.526(a)(2)(iii)": [ "PRI-06.1" ], - "164.526(a)(2)(iv)": [ + "§ 164.526(a)(2)(iv)": [ "PRI-06.1" ], - "164.526(c)": [ + "§ 164.526(c)": [ "PRI-06.2" ], - "164.526(c)(1)": [ + "§ 164.526(c)(1)": [ "PRI-06.2" ], - "164.526(c)(2)": [ + "§ 164.526(c)(2)": [ "PRI-06.2" ], - "164.526(c)(3)": [ + "§ 164.526(c)(3)": [ "PRI-06.2" ], - "164.526(c)(3)(i)": [ + "§ 164.526(c)(3)(i)": [ "PRI-06.2" ], - "164.526(c)(3)(ii)": [ + "§ 164.526(c)(3)(ii)": [ "PRI-06.2" ], - "164.524(d)(4)": [ + "§ 164.524(d)(4)": [ "PRI-06.3" ], - "164.526(b)(2)(i)": [ + "§ 164.526(b)(2)(i)": [ "PRI-06.4" ], - "164.526(b)(2)(i)(A)": [ + "§ 164.526(b)(2)(i)(A)": [ "PRI-06.4" ], - "164.526(b)(2)(i)(B)": [ + "§ 164.526(b)(2)(i)(B)": [ "PRI-06.4" ], - "164.526(b)(2)(ii)": [ + "§ 164.526(b)(2)(ii)": [ "PRI-06.4" ], - "164.526(b)(2)(ii)(A)": [ + "§ 164.526(b)(2)(ii)(A)": [ "PRI-06.4" ], - "164.526(b)(2)(ii)(B)": [ + "§ 164.526(b)(2)(ii)(B)": [ "PRI-06.4" ], - "164.526(d)": [ + "§ 164.526(d)": [ "PRI-06.4" ], - "164.526(d)(1)": [ + "§ 164.526(d)(1)": [ "PRI-06.4" ], - "164.526(d)(1)(i)": [ + "§ 164.526(d)(1)(i)": [ "PRI-06.4" ], - "164.526(d)(1)(ii)": [ + "§ 164.526(d)(1)(ii)": [ "PRI-06.4" ], - "164.526(d)(1)(iii)": [ + "§ 164.526(d)(1)(iii)": [ "PRI-06.4" ], - "164.526(d)(1)(iv)": [ + "§ 164.526(d)(1)(iv)": [ "PRI-06.4" ], - "164.526(d)(2)": [ + "§ 164.526(d)(2)": [ "PRI-06.4" ], - "164.526(d)(3)": [ + "§ 164.526(d)(3)": [ "PRI-06.4" ], - "164.526(d)(4)": [ + "§ 164.526(d)(4)": [ "PRI-06.4" ], - "164.526(d)(5)(i)": [ + "§ 164.526(d)(5)(i)": [ "PRI-06.4" ], - "164.526(d)(5)(ii)": [ + "§ 164.526(d)(5)(ii)": [ "PRI-06.4" ], - "164.526(d)(5)(iii)": [ + "§ 164.526(d)(5)(iii)": [ "PRI-06.4" ], - "164.526(e)": [ + "§ 164.526(e)": [ "PRI-06.4", "PRI-12" ], - "164.526(f)": [ + "§ 164.526(f)": [ "PRI-06.4", "PRI-12" ], - "164.530(d)(1)": [ + "§ 164.530(d)(1)": [ "PRI-06.4" ], - "164.530(d)(2)": [ + "§ 164.530(d)(2)": [ "PRI-06.4" ], - "164.524(c)(2)(i)": [ + "§ 164.524(c)(2)(i)": [ "PRI-06.6" ], - "164.524(c)(2)(ii)": [ + "§ 164.524(c)(2)(ii)": [ "PRI-06.6" ], - "164.506(c)(2)": [ + "§ 164.506(c)(2)": [ "PRI-07" ], - "164.506(c)(3)": [ + "§ 164.506(c)(3)": [ "PRI-07" ], - "164.506(c)(4)": [ + "§ 164.506(c)(4)": [ "PRI-07" ], - "164.508(a)(4)(i)": [ + "§ 164.508(a)(4)(i)": [ "PRI-07" ], - "164.504(e)(2)(i)": [ + "§ 164.504(e)(2)(i)": [ "PRI-07.1", "TPM-05" ], - "164.504(e)(2)(ii)(A)": [ + "§ 164.504(e)(2)(ii)(A)": [ "PRI-07.1" ], - "164.504(e)(2)(ii)(B)": [ + "§ 164.504(e)(2)(ii)(B)": [ "PRI-07.1" ], - "164.504(e)(2)(ii)(C)": [ + "§ 164.504(e)(2)(ii)(C)": [ "PRI-07.1" ], - "164.504(e)(4)(i)": [ + "§ 164.504(e)(4)(i)": [ "PRI-07.1" ], - "164.504(e)(4)(i)(A)": [ + "§ 164.504(e)(4)(i)(A)": [ "PRI-07.1" ], - "164.504(e)(4)(i)(B)": [ + "§ 164.504(e)(4)(i)(B)": [ "PRI-07.1" ], - "164.504(e)(4)(i)(B)(ii)": [ + "§ 164.504(e)(4)(i)(B)(ii)": [ "PRI-07.1" ], - "164.504(e)(4)(i)(B)(ii)(A)": [ + "§ 164.504(e)(4)(i)(B)(ii)(A)": [ "PRI-07.1" ], - "164.524(d)(2)(i)": [ + "§ 164.524(d)(2)(i)": [ "PRI-07.4" ], - "164.524(d)(2)(ii)": [ + "§ 164.524(d)(2)(ii)": [ "PRI-07.4" ], - "164.524(d)(2)(iii)": [ + "§ 164.524(d)(2)(iii)": [ "PRI-07.4" ], - "164.524(d)(3)": [ + "§ 164.524(d)(3)": [ "PRI-07.4" ], - "164.512(i)(1)(i)(B)": [ + "§ 164.512(i)(1)(i)(B)": [ "PRI-10" ], - "164.512(i)(1)(i)(B)(1)": [ + "§ 164.512(i)(1)(i)(B)(1)": [ "PRI-10" ], - "164.512(i)(1)(i)(B)(2)": [ + "§ 164.512(i)(1)(i)(B)(2)": [ "PRI-10" ], - "164.512(i)(1)(i)(B)(3)": [ + "§ 164.512(i)(1)(i)(B)(3)": [ "PRI-10" ], - "164.528(a)(1)": [ + "§ 164.528(a)(1)": [ "PRI-14.1" ], - "164.528(a)(1)(i)": [ + "§ 164.528(a)(1)(i)": [ "PRI-14.1" ], - "164.528(a)(1)(ii)": [ + "§ 164.528(a)(1)(ii)": [ "PRI-14.1" ], - "164.528(a)(1)(iii)": [ + "§ 164.528(a)(1)(iii)": [ "PRI-14.1" ], - "164.528(a)(1)(iv)": [ + "§ 164.528(a)(1)(iv)": [ "PRI-14.1" ], - "164.528(a)(1)(v)": [ + "§ 164.528(a)(1)(v)": [ "PRI-14.1" ], - "164.528(a)(1)(vi)": [ + "§ 164.528(a)(1)(vi)": [ "PRI-14.1" ], - "164.528(a)(1)(vii)": [ + "§ 164.528(a)(1)(vii)": [ "PRI-14.1" ], - "164.528(a)(1)(viii)": [ + "§ 164.528(a)(1)(viii)": [ "PRI-14.1" ], - "164.528(a)(1)(ix)": [ + "§ 164.528(a)(1)(ix)": [ "PRI-14.1" ], - "164.528(b)": [ + "§ 164.528(b)": [ "PRI-14.1" ], - "164.528(b)(1)": [ + "§ 164.528(b)(1)": [ "PRI-14.1" ], - "164.528(b)(2)": [ + "§ 164.528(b)(2)": [ "PRI-14.1" ], - "164.528(b)(2)(i)": [ + "§ 164.528(b)(2)(i)": [ "PRI-14.1" ], - "164.528(b)(2)(ii)": [ + "§ 164.528(b)(2)(ii)": [ "PRI-14.1" ], - "164.528(b)(2)(iii)": [ + "§ 164.528(b)(2)(iii)": [ "PRI-14.1" ], - "164.528(b)(2)(iv)": [ + "§ 164.528(b)(2)(iv)": [ "PRI-14.1" ], - "164.528(b)(3)": [ + "§ 164.528(b)(3)": [ "PRI-14.1" ], - "164.528(b)(3)(i)": [ + "§ 164.528(b)(3)(i)": [ "PRI-14.1" ], - "164.528(b)(3)(ii)": [ + "§ 164.528(b)(3)(ii)": [ "PRI-14.1" ], - "164.528(b)(3)(iii)": [ + "§ 164.528(b)(3)(iii)": [ "PRI-14.1" ], - "164.528(b)(4)(i)": [ + "§ 164.528(b)(4)(i)": [ "PRI-14.1" ], - "164.528(b)(4)(i)(A)": [ + "§ 164.528(b)(4)(i)(A)": [ "PRI-14.1" ], - "164.528(b)(4)(i)(B)": [ + "§ 164.528(b)(4)(i)(B)": [ "PRI-14.1" ], - "164.528(b)(4)(i)(C)": [ + "§ 164.528(b)(4)(i)(C)": [ "PRI-14.1" ], - "164.528(b)(4)(i)(D)": [ + "§ 164.528(b)(4)(i)(D)": [ "PRI-14.1" ], - "164.528(b)(4)(i)(E)": [ + "§ 164.528(b)(4)(i)(E)": [ "PRI-14.1" ], - "164.528(b)(4)(i)(F)": [ + "§ 164.528(b)(4)(i)(F)": [ "PRI-14.1" ], - "164.528(b)(4)(ii)": [ + "§ 164.528(b)(4)(ii)": [ "PRI-14.1" ], - "164.528(c)(1)": [ + "§ 164.528(c)(1)": [ "PRI-14.1" ], - "164.528(c)(1)(i)": [ + "§ 164.528(c)(1)(i)": [ "PRI-14.1" ], - "164.528(c)(1)(ii)": [ + "§ 164.528(c)(1)(ii)": [ "PRI-14.1" ], - "164.528(c)(1)(ii)(A)": [ + "§ 164.528(c)(1)(ii)(A)": [ "PRI-14.1" ], - "164.528(c)(1)(ii)(B)": [ + "§ 164.528(c)(1)(ii)(B)": [ "PRI-14.1" ], - "164.528(c)(2)": [ + "§ 164.528(c)(2)": [ "PRI-14.1" ], - "164.528(d)": [ + "§ 164.528(d)": [ "PRI-14.1" ], - "164.528(d)(1)": [ + "§ 164.528(d)(1)": [ "PRI-14.1" ], - "164.528(d)(2)": [ + "§ 164.528(d)(2)": [ "PRI-14.1" ], - "164.528(d)(3)": [ + "§ 164.528(d)(3)": [ "PRI-14.1" ], - "164.306(b)(2)(iii)": [ + "§ 164.306(b)(2)(iii)": [ "PRM-03" ], - "164.306(b)(2)(ii)": [ + "§ 164.306(b)(2)(ii)": [ "PRM-05", "SEA-02" ], - "164.306(b)(2)(iv)": [ + "§ 164.306(b)(2)(iv)": [ "RSK-01", "RSK-01.1", "RSK-02", @@ -2787,204 +2787,204 @@ "THR-09", "THR-10" ], - "164.308(a)(1)(ii)(A)": [ + "§ 164.308(a)(1)(ii)(A)": [ "RSK-04" ], - "164.306(d)(3)(ii)(B)(2)": [ + "§ 164.306(d)(3)(ii)(B)(2)": [ "RSK-06.2" ], - "164.103": [ + "§ 164.103": [ "SEA-02.1" ], - "164.304": [ + "§ 164.304": [ "SEA-02.1" ], - "164.402": [ + "§ 164.402": [ "SEA-02.1" ], - "164.501": [ + "§ 164.501": [ "SEA-02.1" ], - "164.504(a)": [ + "§ 164.504(a)": [ "SEA-02.1" ], - "164.316(b)(2)(ii)": [ + "§ 164.316(b)(2)(ii)": [ "OPS-01.1", "OPS-03" ], - "164.308(a)(5)(i)": [ + "§ 164.308(a)(5)(i)": [ "SAT-01", "SAT-02" ], - "164.530(b)(2)(i)": [ + "§ 164.530(b)(2)(i)": [ "SAT-02" ], - "164.530(b)(2)(i)(A)": [ + "§ 164.530(b)(2)(i)(A)": [ "SAT-02" ], - "164.530(b)(2)(i)(B)": [ + "§ 164.530(b)(2)(i)(B)": [ "SAT-02" ], - "164.530(b)(2)(i)(C)": [ + "§ 164.530(b)(2)(i)(C)": [ "SAT-02" ], - "164.530(b)(2)(ii)": [ + "§ 164.530(b)(2)(ii)": [ "SAT-02" ], - "164.308(a)(5)(ii)(C)": [ + "§ 164.308(a)(5)(ii)(C)": [ "SAT-03" ], - "164.308(a)(5)(ii)(D)": [ + "§ 164.308(a)(5)(ii)(D)": [ "SAT-03" ], - "164.308(a)(5)(ii)(B)": [ + "§ 164.308(a)(5)(ii)(B)": [ "SAT-03.2" ], - "164.308(a)(5)(ii)(A)": [ + "§ 164.308(a)(5)(ii)(A)": [ "SAT-03.6" ], - "164.308(b)(1)": [ + "§ 164.308(b)(1)": [ "TPM-01", "TPM-04", "TPM-05", "TPM-05.2", "TPM-05.4" ], - "164.308(b)(2)": [ + "§ 164.308(b)(2)": [ "TPM-05", "TPM-05.2", "TPM-05.6" ], - "164.314(a)(2)(iii)": [ + "§ 164.314(a)(2)(iii)": [ "TPM-05", "TPM-05.2" ], - "164.314(b)(1)": [ + "§ 164.314(b)(1)": [ "TPM-05" ], - "164.314(b)(2)(i)": [ + "§ 164.314(b)(2)(i)": [ "TPM-05" ], - "164.314(b)(2)(ii)": [ + "§ 164.314(b)(2)(ii)": [ "TPM-05" ], - "164.314(b)(2)(iii)": [ + "§ 164.314(b)(2)(iii)": [ "TPM-05" ], - "164.502(a)(4)(i)": [ + "§ 164.502(a)(4)(i)": [ "TPM-05" ], - "164.502(a)(4)(ii)": [ + "§ 164.502(a)(4)(ii)": [ "TPM-05" ], - "164.502(e)(1)(i)": [ + "§ 164.502(e)(1)(i)": [ "TPM-05", "TPM-05.6" ], - "164.502(e)(2)": [ + "§ 164.502(e)(2)": [ "TPM-05" ], - "164.504(e)(2)(i)(A)": [ + "§ 164.504(e)(2)(i)(A)": [ "TPM-05" ], - "164.504(e)(2)(i)(B)": [ + "§ 164.504(e)(2)(i)(B)": [ "TPM-05" ], - "164.504(e)(2)(ii)(J)": [ + "§ 164.504(e)(2)(ii)(J)": [ "TPM-05" ], - "164.504(e)(4)(i)(B)(ii)(B)(1)": [ + "§ 164.504(e)(4)(i)(B)(ii)(B)(1)": [ "TPM-05" ], - "164.504(e)(4)(i)(B)(ii)(B)(2)": [ + "§ 164.504(e)(4)(i)(B)(ii)(B)(2)": [ "TPM-05" ], - "164.504(f)(1)(i)": [ + "§ 164.504(f)(1)(i)": [ "TPM-05" ], - "164.504(f)(2)(i)": [ + "§ 164.504(f)(2)(i)": [ "TPM-05" ], - "164.504(f)(2)(ii)": [ + "§ 164.504(f)(2)(ii)": [ "TPM-05" ], - "164.504(f)(2)(ii)(A)": [ + "§ 164.504(f)(2)(ii)(A)": [ "TPM-05" ], - "164.504(f)(2)(ii)(B)": [ + "§ 164.504(f)(2)(ii)(B)": [ "TPM-05" ], - "164.504(f)(2)(ii)(C)": [ + "§ 164.504(f)(2)(ii)(C)": [ "TPM-05" ], - "164.504(f)(2)(ii)(D)": [ + "§ 164.504(f)(2)(ii)(D)": [ "TPM-05" ], - "164.504(f)(2)(ii)(E)": [ + "§ 164.504(f)(2)(ii)(E)": [ "TPM-05" ], - "164.504(f)(2)(ii)(F)": [ + "§ 164.504(f)(2)(ii)(F)": [ "TPM-05" ], - "164.504(f)(2)(ii)(G)": [ + "§ 164.504(f)(2)(ii)(G)": [ "TPM-05" ], - "164.504(f)(2)(ii)(H)": [ + "§ 164.504(f)(2)(ii)(H)": [ "TPM-05" ], - "164.504(f)(2)(ii)(I)": [ + "§ 164.504(f)(2)(ii)(I)": [ "TPM-05" ], - "164.504(f)(2)(ii)(J)": [ + "§ 164.504(f)(2)(ii)(J)": [ "TPM-05" ], - "164.504(f)(2)(iii)(A)": [ + "§ 164.504(f)(2)(iii)(A)": [ "TPM-05" ], - "164.504(f)(2)(iii)(B)": [ + "§ 164.504(f)(2)(iii)(B)": [ "TPM-05" ], - "164.504(f)(2)(iii)(C)": [ + "§ 164.504(f)(2)(iii)(C)": [ "TPM-05" ], - "164.504(f)(3)(i)": [ + "§ 164.504(f)(3)(i)": [ "TPM-05" ], - "164.504(f)(3)(ii)": [ + "§ 164.504(f)(3)(ii)": [ "TPM-05" ], - "164.504(f)(3)(iii)": [ + "§ 164.504(f)(3)(iii)": [ "TPM-05" ], - "164.504(f)(3)(iv)": [ + "§ 164.504(f)(3)(iv)": [ "TPM-05" ], - "164.314(a)(2)(i)(C)": [ + "§ 164.314(a)(2)(i)(C)": [ "TPM-05.1" ], - "164.314(b)(2)(iv)": [ + "§ 164.314(b)(2)(iv)": [ "TPM-05.1" ], - "164.410(a)(2)": [ + "§ 164.410(a)(2)": [ "TPM-05.1" ], - "164.410(b)": [ + "§ 164.410(b)": [ "TPM-05.1" ], - "164.410(c)(2)": [ + "§ 164.410(c)(2)": [ "TPM-05.1" ], - "164.314(a)(2)(i)(B)": [ + "§ 164.314(a)(2)(i)(B)": [ "TPM-05.2" ], - "164.502(e)(1)(ii)": [ + "§ 164.502(e)(1)(ii)": [ "TPM-05.2", "TPM-05.6" ], - "164.504(e)(2)(ii)(D)": [ + "§ 164.504(e)(2)(ii)(D)": [ "TPM-05.2" ], - "164.504(e)(2)(iii)": [ + "§ 164.504(e)(2)(iii)": [ "TPM-05.7" ] } diff --git a/docs/api/crosswalks/usa-federal-law-sox-2002.json b/docs/api/crosswalks/usa-federal-law-sox-2002.json index c97dfeb8..c34a4ea5 100644 --- a/docs/api/crosswalks/usa-federal-law-sox-2002.json +++ b/docs/api/crosswalks/usa-federal-law-sox-2002.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-law-sox-2002", - "display_name": "SOX (2002)", + "display_name": "US - Sarbanes Oxley Act (SOX) (2002)", "scf_to_framework": { "total_mappings": 4, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-nerc-cip-2024.json b/docs/api/crosswalks/usa-federal-nerc-cip-2024.json index b2b0fbcf..1c4a7b39 100644 --- a/docs/api/crosswalks/usa-federal-nerc-cip-2024.json +++ b/docs/api/crosswalks/usa-federal-nerc-cip-2024.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-nerc-cip-2024", - "display_name": "NERC Critical Infrastructure Protection (CIP) (2024)", + "display_name": "US - North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) (2024)", "scf_to_framework": { "total_mappings": 122, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-nispom-2020.json b/docs/api/crosswalks/usa-federal-nispom-2020.json index ebe685a4..79e1b189 100644 --- a/docs/api/crosswalks/usa-federal-nispom-2020.json +++ b/docs/api/crosswalks/usa-federal-nispom-2020.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-nispom-2020", - "display_name": "National Industrial Security Program Operating Manual (NISPOM) (2020)", + "display_name": "US - National Industrial Security Program Operating Manual (NISPOM) (2020)", "scf_to_framework": { "total_mappings": 35, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-omb-fipps-1973.json b/docs/api/crosswalks/usa-federal-omb-fipps-1973.json index e9fc05b5..52c371a8 100644 --- a/docs/api/crosswalks/usa-federal-omb-fipps-1973.json +++ b/docs/api/crosswalks/usa-federal-omb-fipps-1973.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-omb-fipps-1973", - "display_name": "US Fair Information Practice Principles (FIPPs) (1973)", + "display_name": "US - Fair Information Practice Principles (FIPPs) (1973)", "scf_to_framework": { "total_mappings": 30, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-sec-cybersecurity-rule-2023.json b/docs/api/crosswalks/usa-federal-sec-cybersecurity-rule-2023.json index cad56894..684665e1 100644 --- a/docs/api/crosswalks/usa-federal-sec-cybersecurity-rule-2023.json +++ b/docs/api/crosswalks/usa-federal-sec-cybersecurity-rule-2023.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-sec-cybersecurity-rule-2023", - "display_name": "SEC Cybersecurity Rule (2023)", + "display_name": "US - Securities and Exchange Commission (SEC) Cybersecurity Rule (2023)", "scf_to_framework": { "total_mappings": 40, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-sro-fca-crm-2023.json b/docs/api/crosswalks/usa-federal-sro-fca-crm-2023.json index d33189db..16c09ff3 100644 --- a/docs/api/crosswalks/usa-federal-sro-fca-crm-2023.json +++ b/docs/api/crosswalks/usa-federal-sro-fca-crm-2023.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-sro-fca-crm-2023", - "display_name": "Farm Credit Administration (FCA) Cyber Risk Management (2023)", + "display_name": "US - Farm Credit Administration (FCA) Cyber Risk Management (2023)", "scf_to_framework": { "total_mappings": 81, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-sro-finra.json b/docs/api/crosswalks/usa-federal-sro-finra.json index f8b56bb9..578637b6 100644 --- a/docs/api/crosswalks/usa-federal-sro-finra.json +++ b/docs/api/crosswalks/usa-federal-sro-finra.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-sro-finra", - "display_name": "FINRA Cybersecurity Rules", + "display_name": "US - Financial Industry Regulatory Authority (FINRA) Cybersecurity Rules", "scf_to_framework": { "total_mappings": 17, "mappings": { diff --git a/docs/api/crosswalks/usa-federal-tsa-security-directive-1580-82-2022-01.json b/docs/api/crosswalks/usa-federal-tsa-security-directive-1580-82-2022-01.json index 0c49521b..6734a726 100644 --- a/docs/api/crosswalks/usa-federal-tsa-security-directive-1580-82-2022-01.json +++ b/docs/api/crosswalks/usa-federal-tsa-security-directive-1580-82-2022-01.json @@ -1,6 +1,6 @@ { "framework_id": "usa-federal-tsa-security-directive-1580-82-2022-01", - "display_name": "TSA Security Directive 1580/82-2022-01", + "display_name": "US - Transportation Security Administration (TSA) Security Directive 1580/82 - 2022 - 01 - Rail Cybersecurity Mitigation Actions and Testing", "scf_to_framework": { "total_mappings": 60, "mappings": { diff --git a/docs/api/crosswalks/usa-state-ak-pipa-2009.json b/docs/api/crosswalks/usa-state-ak-pipa-2009.json index 007cdf4f..fe1dd54a 100644 --- a/docs/api/crosswalks/usa-state-ak-pipa-2009.json +++ b/docs/api/crosswalks/usa-state-ak-pipa-2009.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-ak-pipa-2009", - "display_name": "Alaska Personal Information Protection Act (PIPA) (2009)", + "display_name": "US - Alaska Personal Information Protection Act (PIPA) (2009)", "scf_to_framework": { "total_mappings": 5, "mappings": { diff --git a/docs/api/crosswalks/usa-state-ca-ccpa-cpra-2026.json b/docs/api/crosswalks/usa-state-ca-ccpa-cpra-2026.json index 495107c3..718a7765 100644 --- a/docs/api/crosswalks/usa-state-ca-ccpa-cpra-2026.json +++ b/docs/api/crosswalks/usa-state-ca-ccpa-cpra-2026.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-ca-ccpa-cpra-2026", - "display_name": "California Consumer Privacy Act (CCPA) (2026)", + "display_name": "US - California Consumer Privacy Act (CCPA) (January 2026) - amended California Privacy Rights Act (CPRA)", "scf_to_framework": { "total_mappings": 258, "mappings": { diff --git a/docs/api/crosswalks/usa-state-ca-sb1386-2002.json b/docs/api/crosswalks/usa-state-ca-sb1386-2002.json index 1a756dcc..2d2eb653 100644 --- a/docs/api/crosswalks/usa-state-ca-sb1386-2002.json +++ b/docs/api/crosswalks/usa-state-ca-sb1386-2002.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-ca-sb1386-2002", - "display_name": "California SB1386 (2002)", + "display_name": "US - California SB1386 (2002)", "scf_to_framework": { "total_mappings": 4, "mappings": { diff --git a/docs/api/crosswalks/usa-state-ca-sb327-2018.json b/docs/api/crosswalks/usa-state-ca-sb327-2018.json index 539d6a54..d693d17b 100644 --- a/docs/api/crosswalks/usa-state-ca-sb327-2018.json +++ b/docs/api/crosswalks/usa-state-ca-sb327-2018.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-ca-sb327-2018", - "display_name": "California SB327 (2018)", + "display_name": "US - California SB327 (2018)", "scf_to_framework": { "total_mappings": 3, "mappings": { diff --git a/docs/api/crosswalks/usa-state-co-privacy-act-2021.json b/docs/api/crosswalks/usa-state-co-privacy-act-2021.json index 71409c9d..6741933a 100644 --- a/docs/api/crosswalks/usa-state-co-privacy-act-2021.json +++ b/docs/api/crosswalks/usa-state-co-privacy-act-2021.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-co-privacy-act-2021", - "display_name": "Colorado Privacy Act (2021)", + "display_name": "US - Colorado Privacy Act (2021)", "scf_to_framework": { "total_mappings": 23, "mappings": { diff --git a/docs/api/crosswalks/usa-state-il-bipa-2008.json b/docs/api/crosswalks/usa-state-il-bipa-2008.json index 918d272e..cd3964b5 100644 --- a/docs/api/crosswalks/usa-state-il-bipa-2008.json +++ b/docs/api/crosswalks/usa-state-il-bipa-2008.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-il-bipa-2008", - "display_name": "Illinois Biometric Information Privacy Act (BIPA) (2008)", + "display_name": "US - Illinois Biometric Information Privacy Act (BIPA) (2008)", "scf_to_framework": { "total_mappings": 6, "mappings": { diff --git a/docs/api/crosswalks/usa-state-il-ipa-2009.json b/docs/api/crosswalks/usa-state-il-ipa-2009.json index e4d35f44..d656f008 100644 --- a/docs/api/crosswalks/usa-state-il-ipa-2009.json +++ b/docs/api/crosswalks/usa-state-il-ipa-2009.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-il-ipa-2009", - "display_name": "Illinois Identity Protection Act (IPA) (2009)", + "display_name": "US - Illinois Identity Protection Act (IPA) (2009)", "scf_to_framework": { "total_mappings": 12, "mappings": { diff --git a/docs/api/crosswalks/usa-state-il-pipa-2006.json b/docs/api/crosswalks/usa-state-il-pipa-2006.json index abd38113..61fb24f3 100644 --- a/docs/api/crosswalks/usa-state-il-pipa-2006.json +++ b/docs/api/crosswalks/usa-state-il-pipa-2006.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-il-pipa-2006", - "display_name": "Illinois Personal Information Protection Act (PIPA) (2006)", + "display_name": "US - Illinois Personal Information Protection Act (PIPA) (2006)", "scf_to_framework": { "total_mappings": 10, "mappings": { diff --git a/docs/api/crosswalks/usa-state-ma-201-cmr-17-2008.json b/docs/api/crosswalks/usa-state-ma-201-cmr-17-2008.json index 77f48e72..9ffc635d 100644 --- a/docs/api/crosswalks/usa-state-ma-201-cmr-17-2008.json +++ b/docs/api/crosswalks/usa-state-ma-201-cmr-17-2008.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-ma-201-cmr-17-2008", - "display_name": "Massachusetts 201 CMR 17.00 (2008)", + "display_name": "US - Massachusetts 201 CMR 17.00 (2008)", "scf_to_framework": { "total_mappings": 53, "mappings": { diff --git a/docs/api/crosswalks/usa-state-nv-privacy-law-2023.json b/docs/api/crosswalks/usa-state-nv-privacy-law-2023.json new file mode 100644 index 00000000..3639d78e --- /dev/null +++ b/docs/api/crosswalks/usa-state-nv-privacy-law-2023.json @@ -0,0 +1,576 @@ +{ + "framework_id": "usa-state-nv-privacy-law-2023", + "display_name": "US - Nevada Privacy Law (2023) - CHAPTER 603A - SECURITY AND PRIVACY OF PERSONAL INFORMATION", + "scf_to_framework": { + "total_mappings": 29, + "mappings": { + "GOV-02": [ + "603A.525.2", + "603A.525.2(a)" + ], + "GOV-15": [ + "603A.210.2", + "603A.215.1" + ], + "GOV-15.1": [ + "603A.210.2", + "603A.215.1" + ], + "GOV-15.2": [ + "603A.210.2", + "603A.215.1" + ], + "CPL-01": [ + "603A.500.2(c)", + "603A.525.2(b)" + ], + "CRY-03": [ + "603A.215.2(a)" + ], + "DCH-01": [ + "603A.200.1" + ], + "DCH-01.1": [ + "603A.215.2(b)" + ], + "DCH-01.2": [ + "603A.215.2(b)" + ], + "DCH-03.1": [ + "603A.495.3(b)", + "603A.500.2" + ], + "DCH-08": [ + "603A.200.1" + ], + "DCH-18": [ + "603A.200.1" + ], + "DCH-21": [ + "603A.200.1" + ], + "IRO-10": [ + "603A.220.1", + "603A.220.2", + "603A.220.3", + "603A.220.4", + "603A.220.4(a)", + "603A.220.4(b)", + "603A.220.4(c)", + "603A.220.4(c)(1)", + "603A.220.4(c)(2)", + "603A.220.4(c)(3)", + "603A.220.6" + ], + "PRI-01.6": [ + "603A.210.1" + ], + "PRI-01.11": [ + "603A.210.1", + "603A.510.3(b)", + "603A.525.1", + "603A.525.1(a)", + "603A.525.1(b)", + "603A.525.2(c)" + ], + "PRI-02": [ + "603A.340.1", + "603A.340.1(b)", + "603A.340.1(c)", + "603A.340.1(d)", + "603A.340.1(e)", + "603A.345.1", + "603A.346.1", + "603A.495.1", + "603A.495.1(a)", + "603A.495.1(b)", + "603A.495.1(c)", + "603A.495.1(d)", + "603A.495.1(e)", + "603A.495.1(f)", + "603A.495.1(g)", + "603A.495.1(h)", + "603A.495.1(i)", + "603A.495.1(j)", + "603A.495.1(k)", + "603A.495.2" + ], + "PRI-03": [ + "603A.500.2(a)", + "603A.500.2(b)", + "603A.500.3", + "603A.500.3(a)", + "603A.500.3(b)", + "603A.500.3(c)", + "603A.500.3(d)", + "603A.535.5", + "603A.535.6", + "603A.535.6(a)", + "603A.535.6(b)", + "603A.535.6(c)", + "603A.535.6(d)", + "603A.535.7" + ], + "PRI-03.4": [ + "603A.500.3(d)", + "603A.505.1(c)", + "603A.535.4" + ], + "PRI-03.5": [ + "603A.535.2" + ], + "PRI-04": [ + "603A.495.3(a)", + "603A.495.3(c)", + "603A.500.1(a)", + "603A.500.1(b)", + "603A.535.1", + "603A.535.1(a)", + "603A.535.1(b)" + ], + "PRI-05.7": [ + "603A.340.1(a)" + ], + "PRI-06": [ + "603A.345.2", + "603A.346.2", + "603A.505.1(a)", + "603A.505.1(b)", + "603A.505.2", + "603A.505.2(a)", + "603A.510.3(a)(1)", + "603A.510.3(a)(2)" + ], + "PRI-06.3": [ + "603A.520.1", + "603A.520.1(a)", + "603A.520.1(b)", + "603A.520.2", + "603A.520.2(a)", + "603A.520.2(b)", + "603A.520.2(c)" + ], + "PRI-06.4": [ + "603A.345.3", + "603A.345.4", + "603A.346.3", + "603A.346.4", + "603A.510.1", + "603A.510.2", + "603A.510.2(a)", + "603A.510.2(b)" + ], + "PRI-06.5": [ + "603A.505.1(d)", + "603A.515.1", + "603A.515.1(a)", + "603A.515.1(b)", + "603A.515.2", + "603A.515.3" + ], + "PRI-06.8": [ + "603A.505.2(b)" + ], + "PRI-07.1": [ + "603A.210.3", + "603A.495.3(d)", + "603A.530.1", + "603A.530.2", + "603A.530.3", + "603A.530.3(a)", + "603A.530.3(b)" + ], + "PRI-14": [ + "603A.535.3", + "603A.535.3(a)", + "603A.535.3(b)", + "603A.535.3(c)", + "603A.535.3(d)", + "603A.535.3(e)", + "603A.535.3(f)", + "603A.535.3(g)", + "603A.535.3(h)", + "603A.535.3(i)", + "603A.535.8" + ] + } + }, + "framework_to_scf": { + "total_mappings": 121, + "mappings": { + "603A.525.2": [ + "GOV-02" + ], + "603A.525.2(a)": [ + "GOV-02" + ], + "603A.210.2": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" + ], + "603A.215.1": [ + "GOV-15", + "GOV-15.1", + "GOV-15.2" + ], + "603A.500.2(c)": [ + "CPL-01" + ], + "603A.525.2(b)": [ + "CPL-01" + ], + "603A.215.2(a)": [ + "CRY-03" + ], + "603A.200.1": [ + "DCH-01", + "DCH-08", + "DCH-18", + "DCH-21" + ], + "603A.215.2(b)": [ + "DCH-01.1", + "DCH-01.2" + ], + "603A.495.3(b)": [ + "DCH-03.1" + ], + "603A.500.2": [ + "DCH-03.1" + ], + "603A.220.1": [ + "IRO-10" + ], + "603A.220.2": [ + "IRO-10" + ], + "603A.220.3": [ + "IRO-10" + ], + "603A.220.4": [ + "IRO-10" + ], + "603A.220.4(a)": [ + "IRO-10" + ], + "603A.220.4(b)": [ + "IRO-10" + ], + "603A.220.4(c)": [ + "IRO-10" + ], + "603A.220.4(c)(1)": [ + "IRO-10" + ], + "603A.220.4(c)(2)": [ + "IRO-10" + ], + "603A.220.4(c)(3)": [ + "IRO-10" + ], + "603A.220.6": [ + "IRO-10" + ], + "603A.210.1": [ + "PRI-01.6", + "PRI-01.11" + ], + "603A.510.3(b)": [ + "PRI-01.11" + ], + "603A.525.1": [ + "PRI-01.11" + ], + "603A.525.1(a)": [ + "PRI-01.11" + ], + "603A.525.1(b)": [ + "PRI-01.11" + ], + "603A.525.2(c)": [ + "PRI-01.11" + ], + "603A.340.1": [ + "PRI-02" + ], + "603A.340.1(b)": [ + "PRI-02" + ], + "603A.340.1(c)": [ + "PRI-02" + ], + "603A.340.1(d)": [ + "PRI-02" + ], + "603A.340.1(e)": [ + "PRI-02" + ], + "603A.345.1": [ + "PRI-02" + ], + "603A.346.1": [ + "PRI-02" + ], + "603A.495.1": [ + "PRI-02" + ], + "603A.495.1(a)": [ + "PRI-02" + ], + "603A.495.1(b)": [ + "PRI-02" + ], + "603A.495.1(c)": [ + "PRI-02" + ], + "603A.495.1(d)": [ + "PRI-02" + ], + "603A.495.1(e)": [ + "PRI-02" + ], + "603A.495.1(f)": [ + "PRI-02" + ], + "603A.495.1(g)": [ + "PRI-02" + ], + "603A.495.1(h)": [ + "PRI-02" + ], + "603A.495.1(i)": [ + "PRI-02" + ], + "603A.495.1(j)": [ + "PRI-02" + ], + "603A.495.1(k)": [ + "PRI-02" + ], + "603A.495.2": [ + "PRI-02" + ], + "603A.500.2(a)": [ + "PRI-03" + ], + "603A.500.2(b)": [ + "PRI-03" + ], + "603A.500.3": [ + "PRI-03" + ], + "603A.500.3(a)": [ + "PRI-03" + ], + "603A.500.3(b)": [ + "PRI-03" + ], + "603A.500.3(c)": [ + "PRI-03" + ], + "603A.500.3(d)": [ + "PRI-03", + "PRI-03.4" + ], + "603A.535.5": [ + "PRI-03" + ], + "603A.535.6": [ + "PRI-03" + ], + "603A.535.6(a)": [ + "PRI-03" + ], + "603A.535.6(b)": [ + "PRI-03" + ], + "603A.535.6(c)": [ + "PRI-03" + ], + "603A.535.6(d)": [ + "PRI-03" + ], + "603A.535.7": [ + "PRI-03" + ], + "603A.505.1(c)": [ + "PRI-03.4" + ], + "603A.535.4": [ + "PRI-03.4" + ], + "603A.535.2": [ + "PRI-03.5" + ], + "603A.495.3(a)": [ + "PRI-04" + ], + "603A.495.3(c)": [ + "PRI-04" + ], + "603A.500.1(a)": [ + "PRI-04" + ], + "603A.500.1(b)": [ + "PRI-04" + ], + "603A.535.1": [ + "PRI-04" + ], + "603A.535.1(a)": [ + "PRI-04" + ], + "603A.535.1(b)": [ + "PRI-04" + ], + "603A.340.1(a)": [ + "PRI-05.7" + ], + "603A.345.2": [ + "PRI-06" + ], + "603A.346.2": [ + "PRI-06" + ], + "603A.505.1(a)": [ + "PRI-06" + ], + "603A.505.1(b)": [ + "PRI-06" + ], + "603A.505.2": [ + "PRI-06" + ], + "603A.505.2(a)": [ + "PRI-06" + ], + "603A.510.3(a)(1)": [ + "PRI-06" + ], + "603A.510.3(a)(2)": [ + "PRI-06" + ], + "603A.520.1": [ + "PRI-06.3" + ], + "603A.520.1(a)": [ + "PRI-06.3" + ], + "603A.520.1(b)": [ + "PRI-06.3" + ], + "603A.520.2": [ + "PRI-06.3" + ], + "603A.520.2(a)": [ + "PRI-06.3" + ], + "603A.520.2(b)": [ + "PRI-06.3" + ], + "603A.520.2(c)": [ + "PRI-06.3" + ], + "603A.345.3": [ + "PRI-06.4" + ], + "603A.345.4": [ + "PRI-06.4" + ], + "603A.346.3": [ + "PRI-06.4" + ], + "603A.346.4": [ + "PRI-06.4" + ], + "603A.510.1": [ + "PRI-06.4" + ], + "603A.510.2": [ + "PRI-06.4" + ], + "603A.510.2(a)": [ + "PRI-06.4" + ], + "603A.510.2(b)": [ + "PRI-06.4" + ], + "603A.505.1(d)": [ + "PRI-06.5" + ], + "603A.515.1": [ + "PRI-06.5" + ], + "603A.515.1(a)": [ + "PRI-06.5" + ], + "603A.515.1(b)": [ + "PRI-06.5" + ], + "603A.515.2": [ + "PRI-06.5" + ], + "603A.515.3": [ + "PRI-06.5" + ], + "603A.505.2(b)": [ + "PRI-06.8" + ], + "603A.210.3": [ + "PRI-07.1" + ], + "603A.495.3(d)": [ + "PRI-07.1" + ], + "603A.530.1": [ + "PRI-07.1" + ], + "603A.530.2": [ + "PRI-07.1" + ], + "603A.530.3": [ + "PRI-07.1" + ], + "603A.530.3(a)": [ + "PRI-07.1" + ], + "603A.530.3(b)": [ + "PRI-07.1" + ], + "603A.535.3": [ + "PRI-14" + ], + "603A.535.3(a)": [ + "PRI-14" + ], + "603A.535.3(b)": [ + "PRI-14" + ], + "603A.535.3(c)": [ + "PRI-14" + ], + "603A.535.3(d)": [ + "PRI-14" + ], + "603A.535.3(e)": [ + "PRI-14" + ], + "603A.535.3(f)": [ + "PRI-14" + ], + "603A.535.3(g)": [ + "PRI-14" + ], + "603A.535.3(h)": [ + "PRI-14" + ], + "603A.535.3(i)": [ + "PRI-14" + ], + "603A.535.8": [ + "PRI-14" + ] + } + } +} \ No newline at end of file diff --git a/docs/api/crosswalks/usa-state-nv-regulation-5-2024.json b/docs/api/crosswalks/usa-state-nv-regulation-5-2024.json index 436162d8..5e565864 100644 --- a/docs/api/crosswalks/usa-state-nv-regulation-5-2024.json +++ b/docs/api/crosswalks/usa-state-nv-regulation-5-2024.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-nv-regulation-5-2024", - "display_name": "Nevada Operation of Gaming Establishment (NOGE) Regulation 5.260 (2024)", + "display_name": "US - Nevada Operation of Gaming Establishments - Regulation 5.260 (Cybersecurity)", "scf_to_framework": { "total_mappings": 20, "mappings": { diff --git a/docs/api/crosswalks/usa-state-nv-sb220-2019.json b/docs/api/crosswalks/usa-state-nv-sb220-2019.json index 2ae514ed..3e2b5b8b 100644 --- a/docs/api/crosswalks/usa-state-nv-sb220-2019.json +++ b/docs/api/crosswalks/usa-state-nv-sb220-2019.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-nv-sb220-2019", - "display_name": "Nevada SB220 (2019)", + "display_name": "US - Nevada SB220 (2019)", "scf_to_framework": { "total_mappings": 3, "mappings": { diff --git a/docs/api/crosswalks/usa-state-ny-dfs-23-nycrr500-2023-amd2.json b/docs/api/crosswalks/usa-state-ny-dfs-23-nycrr500-2023-amd2.json index c1dc9616..0a5e7473 100644 --- a/docs/api/crosswalks/usa-state-ny-dfs-23-nycrr500-2023-amd2.json +++ b/docs/api/crosswalks/usa-state-ny-dfs-23-nycrr500-2023-amd2.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-ny-dfs-23-nycrr500-2023-amd2", - "display_name": "New York Department of Financial Services 23NYCRR Part 500 (2023 Amendment 2)", + "display_name": "US - New York Department of Financial Services (NY DFS) 23NYCRR Part 500 (2023 Amendment 2)", "scf_to_framework": { "total_mappings": 156, "mappings": { diff --git a/docs/api/crosswalks/usa-state-ny-shield-act-2019.json b/docs/api/crosswalks/usa-state-ny-shield-act-2019.json index 199871c6..778ea4f9 100644 --- a/docs/api/crosswalks/usa-state-ny-shield-act-2019.json +++ b/docs/api/crosswalks/usa-state-ny-shield-act-2019.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-ny-shield-act-2019", - "display_name": "New York SHIELD Act (SB S5575B) (2019)", + "display_name": "US - New York SHIELD Act (SB S5575B) (2019)", "scf_to_framework": { "total_mappings": 28, "mappings": { diff --git a/docs/api/crosswalks/usa-state-or-cpa-2023.json b/docs/api/crosswalks/usa-state-or-cpa-2023.json index 2370a26e..d6b29788 100644 --- a/docs/api/crosswalks/usa-state-or-cpa-2023.json +++ b/docs/api/crosswalks/usa-state-or-cpa-2023.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-or-cpa-2023", - "display_name": "Oregon Consumer Privacy Act (SB 619) (2023)", + "display_name": "US - Oregon Consumer Privacy Act (SB 619) (2023)", "scf_to_framework": { "total_mappings": 34, "mappings": { diff --git a/docs/api/crosswalks/usa-state-or-ors-646a-2025.json b/docs/api/crosswalks/usa-state-or-ors-646a-2025.json index 3c1cf0ab..ac49a06a 100644 --- a/docs/api/crosswalks/usa-state-or-ors-646a-2025.json +++ b/docs/api/crosswalks/usa-state-or-ors-646a-2025.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-or-ors-646a-2025", - "display_name": "Oregon Consumer Information Protection Act (ORS 646A) (2025)", + "display_name": "US - Oregon Consumer Information Protection Act (ORS 646A) (2025)", "scf_to_framework": { "total_mappings": 24, "mappings": { diff --git a/docs/api/crosswalks/usa-state-tn-tipa-2025.json b/docs/api/crosswalks/usa-state-tn-tipa-2025.json index 4b756f61..a1bf068a 100644 --- a/docs/api/crosswalks/usa-state-tn-tipa-2025.json +++ b/docs/api/crosswalks/usa-state-tn-tipa-2025.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-tn-tipa-2025", - "display_name": "Tennessee Information Protection Act (TIPA) (2025)", + "display_name": "US - Tennessee Information Protection Act (TIPA) (2025)", "scf_to_framework": { "total_mappings": 29, "mappings": { diff --git a/docs/api/crosswalks/usa-state-tx-bc521-2009.json b/docs/api/crosswalks/usa-state-tx-bc521-2009.json index 7a679f05..94e03b97 100644 --- a/docs/api/crosswalks/usa-state-tx-bc521-2009.json +++ b/docs/api/crosswalks/usa-state-tx-bc521-2009.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-tx-bc521-2009", - "display_name": "Texas Identity Theft Enforcement and Protection Act (BC521) (2009)", + "display_name": "US - Texas Identity Theft Enforcement and Protection Act (BC521) (2009)", "scf_to_framework": { "total_mappings": 5, "mappings": { diff --git a/docs/api/crosswalks/usa-state-tx-cdpa-2025.json b/docs/api/crosswalks/usa-state-tx-cdpa-2025.json index 734c44fb..e982df49 100644 --- a/docs/api/crosswalks/usa-state-tx-cdpa-2025.json +++ b/docs/api/crosswalks/usa-state-tx-cdpa-2025.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-tx-cdpa-2025", - "display_name": "Texas Consumer Data Protection Act (2025)", + "display_name": "US - Texas Consumer Data Protection Act (2025)", "scf_to_framework": { "total_mappings": 28, "mappings": { diff --git a/docs/api/crosswalks/usa-state-tx-dir-security-control-standards-catalog-2-2.json b/docs/api/crosswalks/usa-state-tx-dir-security-control-standards-catalog-2-2.json index dabab92e..2f25c176 100644 --- a/docs/api/crosswalks/usa-state-tx-dir-security-control-standards-catalog-2-2.json +++ b/docs/api/crosswalks/usa-state-tx-dir-security-control-standards-catalog-2-2.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-tx-dir-security-control-standards-catalog-2-2", - "display_name": "Texas DIR Security Control Standards Catalog (v2.2)", + "display_name": "US - Texas DIR Security Control Standards Catalog v2.2", "scf_to_framework": { "total_mappings": 238, "mappings": { diff --git a/docs/api/crosswalks/usa-state-tx-sb2610-2025.json b/docs/api/crosswalks/usa-state-tx-sb2610-2025.json index 31d343aa..0bb1a97a 100644 --- a/docs/api/crosswalks/usa-state-tx-sb2610-2025.json +++ b/docs/api/crosswalks/usa-state-tx-sb2610-2025.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-tx-sb2610-2025", - "display_name": "Texas Safe Harbor Law (SB2610) (2025)", + "display_name": "US - Texas Safe Harbor Law (SB2610) (2025)", "scf_to_framework": { "total_mappings": 6, "mappings": { diff --git a/docs/api/crosswalks/usa-state-tx-sb820-2019.json b/docs/api/crosswalks/usa-state-tx-sb820-2019.json index 48c9ca92..737dd11d 100644 --- a/docs/api/crosswalks/usa-state-tx-sb820-2019.json +++ b/docs/api/crosswalks/usa-state-tx-sb820-2019.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-tx-sb820-2019", - "display_name": "Texas SB820 (2019)", + "display_name": "US - Texas SB820 (2019)", "scf_to_framework": { "total_mappings": 4, "mappings": { diff --git a/docs/api/crosswalks/usa-state-tx-txramp-2-0-level-1.json b/docs/api/crosswalks/usa-state-tx-txramp-2-0-level-1.json index 3435aa6f..6ade4736 100644 --- a/docs/api/crosswalks/usa-state-tx-txramp-2-0-level-1.json +++ b/docs/api/crosswalks/usa-state-tx-txramp-2-0-level-1.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-tx-txramp-2-0-level-1", - "display_name": "TX-RAMP 2.0 - Level 1", + "display_name": "US - Texas Risk & Authorization Management Program 2.0 - Level 1", "scf_to_framework": { "total_mappings": 173, "mappings": { diff --git a/docs/api/crosswalks/usa-state-tx-txramp-2-0-level-2.json b/docs/api/crosswalks/usa-state-tx-txramp-2-0-level-2.json index e4db5b3e..e3db357c 100644 --- a/docs/api/crosswalks/usa-state-tx-txramp-2-0-level-2.json +++ b/docs/api/crosswalks/usa-state-tx-txramp-2-0-level-2.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-tx-txramp-2-0-level-2", - "display_name": "TX-RAMP 2.0 - Level 2", + "display_name": "US - Texas Risk & Authorization Management Program 2.0 - Level 2", "scf_to_framework": { "total_mappings": 285, "mappings": { diff --git a/docs/api/crosswalks/usa-state-va-cdpa-2023.json b/docs/api/crosswalks/usa-state-va-cdpa-2023.json index c416b513..3c310153 100644 --- a/docs/api/crosswalks/usa-state-va-cdpa-2023.json +++ b/docs/api/crosswalks/usa-state-va-cdpa-2023.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-va-cdpa-2023", - "display_name": "Virginia Consumer Data Protection Act (2023)", + "display_name": "US - Virginia Consumer Data Protection Act (2023)", "scf_to_framework": { "total_mappings": 44, "mappings": { diff --git a/docs/api/crosswalks/usa-state-vt-act-171-2018.json b/docs/api/crosswalks/usa-state-vt-act-171-2018.json index f41bc560..d317ef9e 100644 --- a/docs/api/crosswalks/usa-state-vt-act-171-2018.json +++ b/docs/api/crosswalks/usa-state-vt-act-171-2018.json @@ -1,6 +1,6 @@ { "framework_id": "usa-state-vt-act-171-2018", - "display_name": "Vermont Data Broker Registration Act (Act 171 of 2018)", + "display_name": "US - Vermont Data Broker Registration Act (Act 171 of 2018)", "scf_to_framework": { "total_mappings": 35, "mappings": { diff --git a/docs/api/docs.md b/docs/api/docs.md index 3ecb7aea..4b418914 100644 --- a/docs/api/docs.md +++ b/docs/api/docs.md @@ -1,13 +1,13 @@ # SCF API Reference -Static JSON API for the [Secure Controls Framework](https://securecontrolsframework.com) (SCF) v2026.1.1, +Static JSON API for the [Secure Controls Framework](https://securecontrolsframework.com) (SCF) v2026.2, maintained by SC2 (sc2in/scf). -- **1468** controls across **33** families -- **249** framework crosswalks -- **41** threats, **39** risks -- **5776** assessment objectives, **303** evidence requests -- **1305** compensating controls, **258** privacy principles +- **1534** controls across **34** families +- **252** framework crosswalks +- **42** threats, **39** risks +- **5956** assessment objectives, **316** evidence requests +- **1371** compensating controls, **258** privacy principles - All static JSON, no auth, CC BY-ND. ## Endpoints @@ -67,38 +67,39 @@ maintained by SC2 (sc2in/scf). | code | family | controls | |---|---|---| -| AAT | Artificial Intelligence & Autonomous Technologies | 156 | -| AST | Asset Management | 63 | +| AAT | Artificial Intelligence & Autonomous Technologies | 161 | +| AST | Asset Management | 64 | | BCD | Business Continuity & Disaster Recovery | 59 | | CAP | Capacity & Performance Planning | 6 | -| CFG | Configuration Management | 28 | +| CFG | Configuration Management | 32 | | CHG | Change Management | 20 | | CLD | Cloud Security | 24 | -| CPL | Compliance | 40 | +| CPL | Compliance | 41 | | CRY | Cryptographic Protections | 29 | | DCH | Data Classification & Handling | 85 | | EMB | Embedded Technology | 19 | | END | Endpoint Security | 47 | -| GOV | Cybersecurity & Data Protection Governance | 38 | +| GOV | Security, Compliance & Resilience Governance | 42 | | HRS | Human Resources Security | 46 | -| IAC | Identification & Authentication | 114 | +| IAC | Identification & Authentication | 116 | | IAO | Information Assurance | 15 | | IRO | Incident Response | 44 | | MDM | Mobile Device Management | 11 | | MNT | Maintenance | 28 | | MON | Continuous Monitoring | 71 | -| NET | Network Security | 98 | +| NET | Network Security | 100 | | OPS | Security Operations | 8 | | PES | Physical & Environmental Security | 51 | -| PRI | Data Privacy | 102 | +| PRI | Data Privacy | 103 | | PRM | Project & Resource Management | 11 | -| RSK | Risk Management | 32 | -| SAT | Security Awareness & Training | 17 | -| SEA | Secure Engineering & Architecture | 44 | -| TDA | Technology Development & Acquisition | 70 | -| THR | Threat Management | 13 | +| QTS | Quantum Security | 34 | +| RSK | Risk Management | 33 | +| SAT | Security Awareness & Training | 18 | +| SEA | Secure Engineering & Architecture | 47 | +| TDA | Technology Development & Acquisition | 74 | +| THR | Threat Management | 15 | | TPM | Third-Party Management | 31 | -| VPM | Vulnerability & Patch Management | 33 | +| VPM | Vulnerability & Patch Management | 34 | | WEB | Web Security | 15 | Data: Control identifiers, titles, and crosswalk references from the Secure Controls Framework (SCF), https://securecontrolsframework.com, licensed CC BY-ND 4.0. diff --git a/docs/api/evidence-requests.json b/docs/api/evidence-requests.json index a3b28452..19a1180c 100644 --- a/docs/api/evidence-requests.json +++ b/docs/api/evidence-requests.json @@ -1,5 +1,5 @@ { - "total": 303, + "total": 316, "evidence_requests": [ { "erl_id": "E-GOV-01", @@ -1019,7 +1019,8 @@ "artifact_description": "Documented evidence of applicable statutory, regulatory and/or contractual obligations for cybersecurity & data privacy controls.", "scf_controls": [ "CPL-01", - "MON-03" + "MON-03", + "QTS-03.4" ], "cmmc_mapping": "" }, @@ -1394,6 +1395,7 @@ "artifact_description": "Documented evidence of specialized user training for privileged users, executives, individuals who handle sensitive/regulated data, etc.", "scf_controls": [ "DCH-14", + "QTS-05", "SAT-01", "SAT-03", "SAT-03.4", @@ -3194,6 +3196,7 @@ "artifact_name": "Threat Intelligence Feeds (TIF)", "artifact_description": "Documented evidence of threat intelligence feeds.", "scf_controls": [ + "QTS-05.1", "THR-03" ], "cmmc_mapping": "SI.L2-3.14.3" @@ -3501,6 +3504,143 @@ "MON-01.4" ], "cmmc_mapping": "SI.L1-3.14.4\nSI.L1-3.14.5" + }, + { + "erl_id": "E-QTS-01", + "area": "Quantum Security", + "artifact_name": "Quantum Risk Governance Charter", + "artifact_description": "Documented evidence of a quantum risk governance charter with named lead and steering committee.", + "scf_controls": [ + "QTS-01" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-02", + "area": "Quantum Security", + "artifact_name": "Post-Quantum Cryptography (PQC)-Specific Status Reporting", + "artifact_description": "Documented evidence of a Post-Quantum Cryptography (PQC)-specific board / risk committee reporting pack (e.g., status, metrics/analytics, exceptions, etc.).", + "scf_controls": [ + "QTS-01" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-03", + "area": "Quantum Security", + "artifact_name": "Long-Lived Data Identification", + "artifact_description": "Documented evidence of a data classifications by the usable lifespan of the data that can be used to prioritize Post-Quantum Cryptography (PQC) remediation efforts.", + "scf_controls": [ + "QTS-01.3" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-04", + "area": "Quantum Security", + "artifact_name": "Cryptographic Asset Inventory", + "artifact_description": "Documented evidence of a cryptographic asset inventory.", + "scf_controls": [ + "CRY-01.5", + "QTS-03.3", + "QTS-04", + "QTS-04.1" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-05", + "area": "Quantum Security", + "artifact_name": "Cryptographic Bill of Materials (CBOM)", + "artifact_description": "Documented evidence of a Cryptographic Bill of Materials (CBOM).", + "scf_controls": [ + "QTS-04.2" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-06", + "area": "Quantum Security", + "artifact_name": "Cryptographic Agility Risk Assessment (CARA) Methodology", + "artifact_description": "Documented evidence of a Cryptographic Agility Risk Assessment (CARA) methodology.", + "scf_controls": [ + "QTS-02" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-07", + "area": "Quantum Security", + "artifact_name": "Cryptographic Exception Register", + "artifact_description": "Documented evidence of a formal cryptographic exception register.", + "scf_controls": [ + "QTS-02.1" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-08", + "area": "Quantum Security", + "artifact_name": "Approved / Deprecated Algorithm List", + "artifact_description": "Documented evidence of an approved / deprecated algorithm list.", + "scf_controls": [ + "QTS-06.3", + "QTS-06.5" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-09", + "area": "Quantum Security", + "artifact_name": "Zero Trust Network Architecture (ZTNA)", + "artifact_description": "Documented evidence of Zero Trust Network Architecture (ZTNA) (e.g., architecture diagrams, segmentation matrices, access policies, etc.).", + "scf_controls": [ + "QTS-01.4" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-10", + "area": "Quantum Security", + "artifact_name": "Cryptographic Telemetry", + "artifact_description": "Documented evidence of situational awareness dashboards for cryptographic telemetry (e.g., SIEM/XDR dashboards).", + "scf_controls": [ + "QTS-04.3", + "QTS-05.1" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-11", + "area": "Quantum Security", + "artifact_name": "Interoperability Test Records", + "artifact_description": "Documented evidence of cryptographic algorithm interoperability, performance and rollback tests.", + "scf_controls": [ + "QTS-03.1" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-12", + "area": "Quantum Security", + "artifact_name": "Cryptographic Incident Playbooks", + "artifact_description": "Documented evidence of incident playbooks and exercise records for cryptographic scenarios.", + "scf_controls": [ + "QTS-07" + ], + "cmmc_mapping": "" + }, + { + "erl_id": "E-QTS-13", + "area": "Quantum Security", + "artifact_name": "Post-Quantum Cryptography (PQC)-Specific Vendor Roadmaps", + "artifact_description": "Documented evidence of a vendor-related Post-Quantum Cryptography (PQC) roadmaps, contract clauses, and attestations.", + "scf_controls": [ + "QTS-02.2", + "QTS-03.1", + "QTS-03.3" + ], + "cmmc_mapping": "" } ] } \ No newline at end of file diff --git a/docs/api/evidence-requests/E-CPL-01.json b/docs/api/evidence-requests/E-CPL-01.json index 4d2ce894..be7d0c76 100644 --- a/docs/api/evidence-requests/E-CPL-01.json +++ b/docs/api/evidence-requests/E-CPL-01.json @@ -5,7 +5,8 @@ "artifact_description": "Documented evidence of applicable statutory, regulatory and/or contractual obligations for cybersecurity & data privacy controls.", "scf_controls": [ "CPL-01", - "MON-03" + "MON-03", + "QTS-03.4" ], "cmmc_mapping": "" } \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-01.json b/docs/api/evidence-requests/E-QTS-01.json new file mode 100644 index 00000000..9e28f4fc --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-01.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-01", + "area": "Quantum Security", + "artifact_name": "Quantum Risk Governance Charter", + "artifact_description": "Documented evidence of a quantum risk governance charter with named lead and steering committee.", + "scf_controls": [ + "QTS-01" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-02.json b/docs/api/evidence-requests/E-QTS-02.json new file mode 100644 index 00000000..268bf24b --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-02.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-02", + "area": "Quantum Security", + "artifact_name": "Post-Quantum Cryptography (PQC)-Specific Status Reporting", + "artifact_description": "Documented evidence of a Post-Quantum Cryptography (PQC)-specific board / risk committee reporting pack (e.g., status, metrics/analytics, exceptions, etc.).", + "scf_controls": [ + "QTS-01" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-03.json b/docs/api/evidence-requests/E-QTS-03.json new file mode 100644 index 00000000..77d929d4 --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-03.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-03", + "area": "Quantum Security", + "artifact_name": "Long-Lived Data Identification", + "artifact_description": "Documented evidence of a data classifications by the usable lifespan of the data that can be used to prioritize Post-Quantum Cryptography (PQC) remediation efforts.", + "scf_controls": [ + "QTS-01.3" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-04.json b/docs/api/evidence-requests/E-QTS-04.json new file mode 100644 index 00000000..20b91306 --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-04.json @@ -0,0 +1,13 @@ +{ + "erl_id": "E-QTS-04", + "area": "Quantum Security", + "artifact_name": "Cryptographic Asset Inventory", + "artifact_description": "Documented evidence of a cryptographic asset inventory.", + "scf_controls": [ + "CRY-01.5", + "QTS-03.3", + "QTS-04", + "QTS-04.1" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-05.json b/docs/api/evidence-requests/E-QTS-05.json new file mode 100644 index 00000000..29b89425 --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-05.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-05", + "area": "Quantum Security", + "artifact_name": "Cryptographic Bill of Materials (CBOM)", + "artifact_description": "Documented evidence of a Cryptographic Bill of Materials (CBOM).", + "scf_controls": [ + "QTS-04.2" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-06.json b/docs/api/evidence-requests/E-QTS-06.json new file mode 100644 index 00000000..43c2c8b0 --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-06.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-06", + "area": "Quantum Security", + "artifact_name": "Cryptographic Agility Risk Assessment (CARA) Methodology", + "artifact_description": "Documented evidence of a Cryptographic Agility Risk Assessment (CARA) methodology.", + "scf_controls": [ + "QTS-02" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-07.json b/docs/api/evidence-requests/E-QTS-07.json new file mode 100644 index 00000000..7fc5b70c --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-07.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-07", + "area": "Quantum Security", + "artifact_name": "Cryptographic Exception Register", + "artifact_description": "Documented evidence of a formal cryptographic exception register.", + "scf_controls": [ + "QTS-02.1" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-08.json b/docs/api/evidence-requests/E-QTS-08.json new file mode 100644 index 00000000..d1fab75e --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-08.json @@ -0,0 +1,11 @@ +{ + "erl_id": "E-QTS-08", + "area": "Quantum Security", + "artifact_name": "Approved / Deprecated Algorithm List", + "artifact_description": "Documented evidence of an approved / deprecated algorithm list.", + "scf_controls": [ + "QTS-06.3", + "QTS-06.5" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-09.json b/docs/api/evidence-requests/E-QTS-09.json new file mode 100644 index 00000000..45a8a635 --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-09.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-09", + "area": "Quantum Security", + "artifact_name": "Zero Trust Network Architecture (ZTNA)", + "artifact_description": "Documented evidence of Zero Trust Network Architecture (ZTNA) (e.g., architecture diagrams, segmentation matrices, access policies, etc.).", + "scf_controls": [ + "QTS-01.4" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-10.json b/docs/api/evidence-requests/E-QTS-10.json new file mode 100644 index 00000000..35d3377b --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-10.json @@ -0,0 +1,11 @@ +{ + "erl_id": "E-QTS-10", + "area": "Quantum Security", + "artifact_name": "Cryptographic Telemetry", + "artifact_description": "Documented evidence of situational awareness dashboards for cryptographic telemetry (e.g., SIEM/XDR dashboards).", + "scf_controls": [ + "QTS-04.3", + "QTS-05.1" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-11.json b/docs/api/evidence-requests/E-QTS-11.json new file mode 100644 index 00000000..21ea31c3 --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-11.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-11", + "area": "Quantum Security", + "artifact_name": "Interoperability Test Records", + "artifact_description": "Documented evidence of cryptographic algorithm interoperability, performance and rollback tests.", + "scf_controls": [ + "QTS-03.1" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-12.json b/docs/api/evidence-requests/E-QTS-12.json new file mode 100644 index 00000000..a954aa49 --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-12.json @@ -0,0 +1,10 @@ +{ + "erl_id": "E-QTS-12", + "area": "Quantum Security", + "artifact_name": "Cryptographic Incident Playbooks", + "artifact_description": "Documented evidence of incident playbooks and exercise records for cryptographic scenarios.", + "scf_controls": [ + "QTS-07" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-QTS-13.json b/docs/api/evidence-requests/E-QTS-13.json new file mode 100644 index 00000000..f6a01a51 --- /dev/null +++ b/docs/api/evidence-requests/E-QTS-13.json @@ -0,0 +1,12 @@ +{ + "erl_id": "E-QTS-13", + "area": "Quantum Security", + "artifact_name": "Post-Quantum Cryptography (PQC)-Specific Vendor Roadmaps", + "artifact_description": "Documented evidence of a vendor-related Post-Quantum Cryptography (PQC) roadmaps, contract clauses, and attestations.", + "scf_controls": [ + "QTS-02.2", + "QTS-03.1", + "QTS-03.3" + ], + "cmmc_mapping": "" +} \ No newline at end of file diff --git a/docs/api/evidence-requests/E-SAT-05.json b/docs/api/evidence-requests/E-SAT-05.json index 70caa322..5b419113 100644 --- a/docs/api/evidence-requests/E-SAT-05.json +++ b/docs/api/evidence-requests/E-SAT-05.json @@ -5,6 +5,7 @@ "artifact_description": "Documented evidence of specialized user training for privileged users, executives, individuals who handle sensitive/regulated data, etc.", "scf_controls": [ "DCH-14", + "QTS-05", "SAT-01", "SAT-03", "SAT-03.4", diff --git a/docs/api/evidence-requests/E-THR-03.json b/docs/api/evidence-requests/E-THR-03.json index b2ec4b79..8cc3059d 100644 --- a/docs/api/evidence-requests/E-THR-03.json +++ b/docs/api/evidence-requests/E-THR-03.json @@ -4,6 +4,7 @@ "artifact_name": "Threat Intelligence Feeds (TIF)", "artifact_description": "Documented evidence of threat intelligence feeds.", "scf_controls": [ + "QTS-05.1", "THR-03" ], "cmmc_mapping": "SI.L2-3.14.3" diff --git a/docs/api/families.json b/docs/api/families.json index 839d2648..2baa85bb 100644 --- a/docs/api/families.json +++ b/docs/api/families.json @@ -1,16 +1,16 @@ { - "total_families": 33, - "total_controls": 1468, + "total_families": 34, + "total_controls": 1534, "families": [ { "family_code": "AAT", "family_name": "Artificial Intelligence & Autonomous Technologies", - "control_count": 156 + "control_count": 161 }, { "family_code": "AST", "family_name": "Asset Management", - "control_count": 63 + "control_count": 64 }, { "family_code": "BCD", @@ -25,7 +25,7 @@ { "family_code": "CFG", "family_name": "Configuration Management", - "control_count": 28 + "control_count": 32 }, { "family_code": "CHG", @@ -40,7 +40,7 @@ { "family_code": "CPL", "family_name": "Compliance", - "control_count": 40 + "control_count": 41 }, { "family_code": "CRY", @@ -64,8 +64,8 @@ }, { "family_code": "GOV", - "family_name": "Cybersecurity & Data Protection Governance", - "control_count": 38 + "family_name": "Security, Compliance & Resilience Governance", + "control_count": 42 }, { "family_code": "HRS", @@ -75,7 +75,7 @@ { "family_code": "IAC", "family_name": "Identification & Authentication", - "control_count": 114 + "control_count": 116 }, { "family_code": "IAO", @@ -105,7 +105,7 @@ { "family_code": "NET", "family_name": "Network Security", - "control_count": 98 + "control_count": 100 }, { "family_code": "OPS", @@ -120,37 +120,42 @@ { "family_code": "PRI", "family_name": "Data Privacy", - "control_count": 102 + "control_count": 103 }, { "family_code": "PRM", "family_name": "Project & Resource Management", "control_count": 11 }, + { + "family_code": "QTS", + "family_name": "Quantum Security", + "control_count": 34 + }, { "family_code": "RSK", "family_name": "Risk Management", - "control_count": 32 + "control_count": 33 }, { "family_code": "SAT", "family_name": "Security Awareness & Training", - "control_count": 17 + "control_count": 18 }, { "family_code": "SEA", "family_name": "Secure Engineering & Architecture", - "control_count": 44 + "control_count": 47 }, { "family_code": "TDA", "family_name": "Technology Development & Acquisition", - "control_count": 70 + "control_count": 74 }, { "family_code": "THR", "family_name": "Threat Management", - "control_count": 13 + "control_count": 15 }, { "family_code": "TPM", @@ -160,7 +165,7 @@ { "family_code": "VPM", "family_name": "Vulnerability & Patch Management", - "control_count": 33 + "control_count": 34 }, { "family_code": "WEB", diff --git a/docs/api/families/AAT.json b/docs/api/families/AAT.json index 4b9d0b6c..5662508b 100644 --- a/docs/api/families/AAT.json +++ b/docs/api/families/AAT.json @@ -1,7 +1,7 @@ { "family_code": "AAT", "family_name": "Artificial Intelligence & Autonomous Technologies", - "control_count": 156, + "control_count": 161, "controls": [ { "control_id": "AAT-01", @@ -112,7 +112,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -187,6 +188,10 @@ ], "emea-eu-ai-act-2024": [ "Article 17.1(c)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2072", + "ISM-2074" ] } }, @@ -276,7 +281,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -404,7 +410,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -441,7 +448,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to sustain the value of deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -520,7 +527,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -636,11 +644,116 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} }, + { + "control_id": "AAT-01.5", + "title": "Artificial Intelligence and Autonomous Technologies (AAT) & AI Agent Categorization", + "family": "AAT", + "description": "Mechanisms exist to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements.", + "scf_question": "Does the organization assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to assign defined classes to Artificial Intelligence and Autonomous Technologies (AAT) and AI agents based on their characteristics (e.g., intended use, autonomy, access, potential impact and risk) to determine applicable:\n(1) Approval requirements;\n(2) Security, compliance and/or resilience controls;\n(3) Testing rigor;\n(4) Monitoring requirements;\n(5) Supporting documentation; and\n(6) Oversight requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ AI system inventory with basic use-case categorization\n∙ NIST AI RMF categorization guidance.\n∙ Designated responsible party for AI tools in use", + "small": "∙ AI system inventory with risk-based categorization\n∙ NIST AI RMF categorization guidance\n∙ EU AI Act risk tier mapping.", + "medium": "∙ Formal AI system categorization process\n∙ EU AI Act risk tier mapping\n∙ NIST AI RMF implementation\n∙ AI risk register with categorization metadata", + "large": "∙ Formal AI governance program with defined categorization criteria\n∙ EU AI Act compliance mapping\n∙ NIST AI RMF full implementation\n∙ AI Risk Management Committee-approved categorization", + "enterprise": "∙ Enterprise AI categorization program with automated registry\n∙ EU AI Act and ISO/IEC 42001 alignment\n∙ Board-level AI risk reporting by category" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": {} + }, { "control_id": "AAT-02", "title": "Situational Awareness of AI & Autonomous Technologies", @@ -739,7 +852,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -861,7 +975,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -986,9 +1101,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-iso-42001-2023": [ @@ -1022,7 +1137,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AAT include reasonable security, compliance and resilience protections that are commensurate with assessed risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1101,9 +1216,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-600-1-gen-ai-profile": [ @@ -1213,7 +1328,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -1318,7 +1434,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -1342,6 +1459,9 @@ ], "emea-eu-ai-act-2024": [ "Article 8.1" + ], + "apac-aus-ism-2026-march": [ + "ISM-2084" ] } }, @@ -1363,7 +1483,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to define and document the organization's mission and defined goals for AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1441,7 +1561,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -1559,7 +1680,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -1649,7 +1771,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -1773,7 +1896,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -1880,7 +2004,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -1995,7 +2120,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -2092,7 +2218,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -2202,7 +2329,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -2311,7 +2439,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -2427,7 +2556,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -2575,7 +2705,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -2701,7 +2832,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -2834,7 +2966,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -2950,7 +3083,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3077,7 +3211,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3112,8 +3247,8 @@ "control_id": "AAT-09.1", "title": "AI & Autonomous Technologies High Risk Designations", "family": "AAT", - "description": "Mechanisms exist to designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", - "scf_question": "Does the organization designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making?", + "description": "Mechanisms exist to designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one (1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", + "scf_question": "Does the organization designate Artificial Intelligence (AI) and Autonomous Technologies (AAT) \"High Risk\" if one (1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making?", "relative_weight": 7, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -3126,7 +3261,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to designate AAT \"High Risk\" if one(1), or more, of the following criteria are met:\n(1) AAT is used as a safety component of a product or service;\n(2) AAT poses a significant risk of harm to an individual's health, safety or fundamental rights; and/or\n(3) AAT materially influences the outcome of an individual's decision making.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3206,7 +3341,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3221,6 +3357,9 @@ "Article 51.1", "Article 51.1(a)", "Article 51.2" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(1)" ] } }, @@ -3245,7 +3384,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices to enable AAT-related security, resilience and compliance-related conformity testing throughout the lifecycle of the AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3325,7 +3464,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3414,7 +3554,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate AAT for trustworthy behavior and operation including security, anonymization and disaggregation of captured and stored data for approved purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3493,7 +3633,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3534,7 +3675,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to document test sets, metrics and details about the tools used during Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3612,7 +3753,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3643,7 +3785,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to demonstrate the AAT to be deployed are:\n(1) Valid;\n(2) Reliable; and\n(3) Operate as intended, based on approved designs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3721,7 +3863,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3754,7 +3897,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to demonstrate the AAT to be deployed are safe, residual risk does not exceed the organization's risk tolerance and can fail safely, particularly if made to operate beyond its knowledge limits.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3832,7 +3975,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3868,7 +4012,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the security and resilience of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3946,7 +4090,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -3980,7 +4125,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine risks associated with transparency and accountability of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4044,7 +4189,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4075,7 +4221,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine the data privacy risk of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4139,7 +4285,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4169,7 +4316,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to examine fairness and bias of AAT to be deployed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4233,7 +4380,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4278,7 +4426,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate the AAT model.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4356,7 +4504,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4387,7 +4536,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the results of Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) to determine the viability of the proposed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4448,7 +4597,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4479,7 +4629,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate the effectiveness of the processes utilized to perform Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4557,7 +4707,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4587,7 +4738,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate AAT-related performance or the assurance criteria demonstrated for conditions similar to deployment settings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4665,7 +4816,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4696,7 +4848,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to proactively and continuously monitor deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4775,7 +4927,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4818,7 +4971,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to integrate continual improvements for deployed AAT.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4879,7 +5032,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -4912,7 +5066,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to report the status and results of Artificial Intelligence Test, Evaluation, Validation & Verification (AI TEVV) to relevant stakeholders, including governing bodies, as required.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4990,7 +5144,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -5022,7 +5177,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to evaluate claims of AAT model capabilities using empirically validated methods.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5100,7 +5255,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -5115,7 +5271,7 @@ "title": "AI TEVV Benchmarking Content Provenance", "family": "AAT", "description": "Mechanisms exist to benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry-recognized standards.", - "scf_question": "Does the organization benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry -recognized standards?", + "scf_question": "Does the organization benchmark the verifiable lineage and origin of content used by Artificial Intelligence (AI) and Autonomous Technologies (AAT) according to industry-recognized standards?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5128,7 +5284,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to benchmark the verifiable lineage and origin of content used by AAT according to industry-recognized standards.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5206,7 +5362,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -5237,7 +5394,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to mitigate concerns of model collapse by:\n(1) Assessing the proportion of synthetic to non-synthetic training data; and\n(2) Verifying training data is not overly homogenous or AAT system-produced.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5315,7 +5472,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -5422,7 +5580,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -5525,7 +5684,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -5675,7 +5835,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -5795,7 +5956,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -5918,7 +6080,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -5966,7 +6129,7 @@ "0": "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.", "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to communicate AAT-related incidents and/or errors to relevant stakeholders, including affected communities.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to communicate AAT-related incidents and/or errors to relevant stakeholders, including affected communities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6042,7 +6205,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -6148,7 +6312,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -6274,7 +6439,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -6316,6 +6482,10 @@ ], "emea-eu-ai-act-2024": [ "Article 17.1(f)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2086", + "ISM-2087" ] } }, @@ -6412,7 +6582,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -6534,7 +6705,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -6644,7 +6816,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -6654,6 +6827,216 @@ ] } }, + { + "control_id": "AAT-12.5", + "title": "Training Data Source & Integrity", + "family": "AAT", + "description": "Mechanisms exist to validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT).", + "scf_question": "Does the organization validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate the reliability, accuracy and integrity of training data used by Artificial Intelligence and Autonomous Technologies (AAT).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Documented training data provenance\n∙ Basic data quality checks before model training\n∙ Vendor attestations for third-party training data", + "small": "∙ Training data source documentation\n∙ Vendor-supplied training data integrity attestations\n∙ Data quality validation before training", + "medium": "∙ Training data validation pipeline\n∙ Data provenance documentation\n∙ Data integrity checks (hash verification, data quality metrics)", + "large": "∙ Formal training data governance program\n∙ Automated data quality and integrity validation\n∙ Training data lineage tracking", + "enterprise": "∙ Enterprise AI data governance framework\n∙ Automated training data validation pipelines\n∙ Third-party training data audits\n∙ Data integrity monitoring throughout the AI lifecycle" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SM-2088", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2088" + ] + } + }, + { + "control_id": "AAT-12.6", + "title": "Prohibit Training", + "family": "AAT", + "description": "Mechanisms exist to prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "scf_question": "Does the organization prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit Artificial Intelligence and Autonomous Technologies (AAT) from training, fine-tuning and/or improving capabilities using organizational data without prior, explicit consent from applicable data owner(s).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Acceptable Use Policy (AUP) prohibiting unauthorized AI training\n∙ Contractual review of AI vendor terms of service", + "small": "∙ AI usage policy prohibiting unauthorized training\n∙ Employee acknowledgment of AI data use restrictions", + "medium": "∙ AI usage policy prohibiting unauthorized training on organizational data\n∙ Vendor contract reviews for training restrictions\n∙ Data Handling Agreements (DHA) with AI vendors", + "large": "∙ Formal AI data usage policy\n∙ Technical controls preventing data uploads to unauthorized AI systems\n∙ Data Loss Prevention (DLP) for AI training data", + "enterprise": "∙ Enterprise AI data governance policy\n∙ DLP controls restricting data to authorized AI platforms\n∙ Automated enforcement of training data restrictions\n∙ Regular audits of AI vendor training data handling" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2103", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2103" + ] + } + }, { "control_id": "AAT-13", "title": "AI & Autonomous Technologies Stakeholder Diversity", @@ -6750,7 +7133,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -6861,7 +7245,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -6981,7 +7366,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -7098,7 +7484,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -7211,7 +7598,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -7324,7 +7712,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -7436,7 +7825,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -7553,7 +7943,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -7677,7 +8068,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -7804,7 +8196,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -7909,9 +8302,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-100-1-ai-rmf": [ @@ -8022,7 +8415,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -8136,7 +8530,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -8245,7 +8640,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -8360,7 +8756,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -8466,7 +8863,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -8574,7 +8972,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -8691,7 +9090,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -8728,7 +9128,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to perform an investigation when there is a serious incident involving operational AAT that documents a:\n(1) Root Cause Analysis (RCA);\n(2) Risk assessment of the incident; and \n(3) Description of corrective actions taken, including measures implemented to prevent a recurrence of the incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8807,7 +9207,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -8834,7 +9235,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to analyze anomalous AAT behavior and provide escalation paths for human oversight, including:\n(1) Real-time review; and\n(2) Intervention.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8914,12 +9315,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-csa-iot-2": [ "SAP-10" + ], + "apac-aus-ism-2026-march": [ + "ISM-2089" ] } }, @@ -8941,7 +9346,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to require human review and clear escalation paths for approval for high-risk or ambiguous AAT actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9021,7 +9426,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -9044,7 +9450,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and contain emergent or collusive behaviors among multiple AAT, including:\n(1) Automated or human-triggered containment; and \n(2) Formal investigation to determine the root cause of agentic cascades or collusion.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9124,7 +9530,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -9225,7 +9632,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -9329,7 +9737,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -9343,6 +9752,9 @@ ], "emea-eu-ai-act-2024": [ "Article 14.2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2094" ] } }, @@ -9444,7 +9856,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -9557,7 +9970,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -9673,7 +10087,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -9797,7 +10212,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -9902,9 +10318,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { "general-nist-600-1-gen-ai-profile": [ @@ -10010,7 +10426,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10043,7 +10460,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prioritize, respond to and remediate AAT-related risks based on assessments and other analytical output.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10123,7 +10540,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10170,7 +10588,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure deployed AAT conform to applicable statutory and regulatory requirements, based on:\n(1) Defined use cases;\n(2) Geographic markets; and\n(3) Use of Intellectual Property (IP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10250,7 +10668,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10281,7 +10700,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that utilize manipulative or deceptive techniques (including biased data) to impair an individual's ability to make a reasonably informed decision.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10360,7 +10779,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10387,7 +10807,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that exploit a human subject to materially affect a targeted behavior due to their:\n(1) Age;\n(2) Disability; or \n(3) Specific social or economic situation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10466,7 +10886,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10493,7 +10914,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that: \n(1) Evaluate human subjects over a certain period of time based on their social behavior or known, inferred or predicted personal or personality characteristics; and\n(2) Assign a \"social score\" branding or equivalent classification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10572,7 +10993,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10599,7 +11021,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that lead to the detrimental or unfavorable treatment of certain data subjects, or groups of data subjects, in social contexts that is:\n(1) Are unrelated to the contexts in which the data was originally generated or collected; and/or\n(2) Is unjustified or disproportionate to their social behavior or its gravity.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10678,7 +11100,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10706,7 +11129,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that:\n(1) Assess the risk of an individual committing a criminal offence; and\n(2) Predicts risk based solely on the profiling of personality traits and characteristics.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10785,7 +11208,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10812,7 +11236,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that create, or expand, facial recognition databases through scraping facial images from:\n(1) The Internet; or \n(2) Closed-Circuit Television (CCTV) footage.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10891,7 +11315,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -10918,7 +11343,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prohibit the sale, deployment and/or use of AAT that infer human emotions of an individual based on observed characteristics.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10997,7 +11422,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11103,7 +11529,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11120,7 +11547,7 @@ "title": "AI & Autonomous Technologies Development Practices", "family": "AAT", "description": "Measures exist to ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals.", - "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness, and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals?", + "scf_question": "Does the organization ensure Artificial Intelligence (AI) and Autonomous Technologies (AAT) are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -11137,7 +11564,7 @@ "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ Measures exist to ensure AAT are designed and developed to:\n(1) Achieve an appropriate level of accuracy, robustness and cybersecurity; \n(2) Perform consistently in those respects throughout the AAT system's lifecycle; and\n(3) Be effectively overseen by competent individuals.", "4": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -11212,7 +11639,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11326,7 +11754,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11442,7 +11871,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11493,7 +11923,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to document the extent to which human domain knowledge is employed to improve AAT performance including:\n(1) Reinforcement Learning from Human Feedback (RLHF);\n(2) Fine-tuning;\n(3) Retrieval- augmented generation;\n(4) Content moderation; and\n(5) Business rules.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11571,7 +12001,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11675,7 +12106,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11789,7 +12221,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -11896,7 +12329,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12003,7 +12437,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12108,7 +12543,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12215,7 +12651,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12320,7 +12757,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12425,7 +12863,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12530,7 +12969,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12638,7 +13078,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12749,7 +13190,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12859,7 +13301,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -12972,7 +13415,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13078,7 +13522,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13184,7 +13629,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13297,7 +13743,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13404,7 +13851,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13509,7 +13957,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13615,7 +14064,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13720,7 +14170,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13750,7 +14201,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to assign personnel to review AAT-generated content for alignment with culturally accepted norms.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13828,7 +14279,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -13855,7 +14307,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI models are designed with resilience capabilities that are sufficient to withstand reasonable threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13934,7 +14386,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -13957,7 +14410,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent \"model pollution\" due to accidental and/or malicious inputs by an AI agent that can negatively alter the AI model.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14036,7 +14489,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14059,7 +14513,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and prevent the propagation of false data (e.g., hallucinations) within the AI model or between AI agents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14138,7 +14592,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14161,7 +14616,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to monitor and prevent resource overload or Denial of Service (DoS) conditions through:\n(1) Enforcement of quotas;\n(2) Workload controls; and \n(3) Auto-suspension of runaway AI agent processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14240,7 +14695,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14263,7 +14719,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ AAT is regarded as a technology and governed by the entity's existing IT governance practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide oversight of AAT-related activities. GRC functions are assigned to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agents are designed, developed and deployed to securely operate under human oversight.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14343,7 +14799,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14366,7 +14823,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to protect, isolate and harden infrastructure resources used by AI agents, including:\n(1) Resource allocation;\n(2) Privilege management;\n(3) Network segmentation; and \n(4) Workload isolation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14446,7 +14903,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14469,7 +14927,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement limitations for AI agents according to:\n(1) Least privileges, where the AI agent operates with the minimal permissions necessary to perform designated tasks; and\n(2) Least functionality, where the AI agent is restricted to communicate with the minimal Technology Assets, Applications and/or Services (TAAS) and networks necessary to perform designated tasks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14549,10 +15007,15 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", - "crosswalks": {} + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2092" + ] + } }, { "control_id": "AAT-29.3", @@ -14572,7 +15035,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to authenticate, authorize, validate and monitor all tool and Application Programming Interface (API) invocations by AI agents, including;\n(1) Schema validation;\n(2) Rate limiting;\n(3) Access controls; and\n(4) Output validation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14652,7 +15115,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14675,7 +15139,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate, secure and restrict AI agent orchestration protocols to prevent:\n(1) Unauthorized tool chaining;\n(2) Context manipulation; and/or\n(3) Protocol-based escalation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14755,7 +15219,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14778,7 +15243,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate, sanitize and monitor all data inputs and retrieval pipelines for AI agents to:\n(1) Ensure data provenance; and \n(2) Prevent unauthorized access risks (e.g., injection, manipulation or exfiltration).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14858,7 +15323,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14881,7 +15347,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent privilege escalation or unauthorized delegation by AI agents by:\n(1) Monitoring and enforcing dynamic roles; and\n(2) Establishing cross-agent delegation boundaries and privileged actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14961,7 +15427,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -14970,8 +15437,8 @@ "control_id": "AAT-29.7", "title": "AI Agent Data Access Restrictions", "family": "AAT", - "description": "Mechanisms exist to restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", - "scf_question": "Does the organization restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data?", + "description": "Mechanisms exist to restrict agent access to sensitive and/or regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", + "scf_question": "Does the organization restrict agent access to sensitive and/or regulated data so that AI agents cannot ingest, generate or act on unauthorized data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -14984,7 +15451,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict agent access to sensitive/regulated data so that AI agents cannot ingest, generate or act on unauthorized data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15064,7 +15531,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15073,8 +15541,8 @@ "control_id": "AAT-29.8", "title": "Data Extraction", "family": "AAT", - "description": "Mechanisms exist to prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point.", - "scf_question": "Does the organization prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point?", + "description": "Mechanisms exist to prevent AI agents from extracting sensitive and/or regulated data from volatile memory that can be exploited at a later point.", + "scf_question": "Does the organization prevent AI agents from extracting sensitive and/or regulated data from volatile memory that can be exploited at a later point?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -15087,7 +15555,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent AI agents from extracting sensitive/regulated data from volatile memory that can be exploited at a later point.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15167,7 +15635,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15190,7 +15659,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure user identification and authentication methods are capable of preventing AI agents from \n(1) Spoofing;\n(2) Mimicry; and/or\n(3) Impersonation attacks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15270,7 +15739,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15293,7 +15763,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent AI agent logic from being subverted or manipulated.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15373,7 +15843,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15396,7 +15867,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to utilize a \"sandbox\" capability to restrict AI agents from unrestricted access to both local and remote resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15476,7 +15947,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15499,7 +15971,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect and mitigate prompt injection / input attacks that seek to manipulate AI agent instructions, bypass security, compliance and/or resilience controls or result in unauthorized actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15579,9 +16051,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} }, @@ -15603,7 +16075,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to allow authorized users or operators to immediately halt or disable AI agent activity in case of unexpected behavior or harm.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15683,7 +16155,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15706,7 +16179,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to regularly conduct adversarial testing that simulates attacks against AI agents to identify and mitigate vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15786,7 +16259,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15809,7 +16283,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to control, restrict and log AI agent self-modification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15889,7 +16363,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -15912,7 +16387,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict purging of any persistent memory or long-term data used by AI agents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15992,7 +16467,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16015,7 +16491,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to restrict agentic delegation, chaining and multi-agent communication to prevent unauthorized task escalation or emergent risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16095,7 +16571,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16118,7 +16595,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to continuously monitor for behavioral drift or deviation from established AI agent baselines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16198,7 +16675,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16221,7 +16699,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure that all AI agent-initiated actions are properly mapped to authenticated user or system identities, with enforced authorization checks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16301,7 +16779,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16324,7 +16803,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to provide comprehensive audit trails of AI agent actions including:\n(1) Rationales; and \n(2) User/trigger mappings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16404,7 +16883,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16427,7 +16907,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to:\n(1) Provide human-understandable explanations for significant AI agent actions or decisions; and \n(2) Enable users to contest outcomes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16507,7 +16987,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16530,7 +17011,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to detect unfair, unethical or biased AI agent actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16610,7 +17091,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16633,7 +17115,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to validate AI agent-generated outputs through the use of:\n(1) Content scanning; and\n(2) Output vetting through human approvals, where appropriate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16713,11 +17195,86 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} }, + { + "control_id": "AAT-29.24", + "title": "Resource Limiting", + "family": "AAT", + "description": "Automated mechanisms exist to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget).", + "scf_question": "Does the organization use automated mechanisms to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget)?", + "relative_weight": 5, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to enforce resource limits for Artificial Intelligence (AI) and Autonomous Technologies (AAT), including:\n(1) Energy consumption;\n(2) Processing capacity; and\n(3) Financial consumption (e.g., allocated budget).", + "4": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Artificial Intelligence and Autonomous Technology (AAT) capabilities are \"world class\" efforts the leverage predictive analysis (e.g., machine learning, AI, etc.) to enable continuously improving capabilities. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Cloud provider resource quotas and budget alerts\n∙ API rate limiting for AI tool usage\n∙ Basic AI tool usage monitoring", + "small": "∙ Cloud provider resource quotas and API rate limiting\n∙ Cost alerting for AI workload spend", + "medium": "∙ Resource quotas and limits in AI deployment platforms\n∙ Cloud cost management tools (e.g., AWS Cost Explorer, Azure Cost Management)\n∙ API rate limiting and throttling", + "large": "∙ Enterprise resource governance for AI workloads\n∙ Cloud FinOps practices\n∙ Automated resource limit enforcement\n∙ AI workload monitoring and alerting", + "enterprise": "∙ Enterprise AI resource governance platform\n∙ Automated resource limit enforcement with alerting\n∙ AI workload orchestration (e.g., Kubernetes resource limits)\n∙ FinOps program for AI infrastructure costs" + }, + "risks": [ + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-GV-1" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2090 & 2091", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2090", + "ISM-2091" + ] + } + }, { "control_id": "AAT-30", "title": "Agentic Output Traceability & Repudiation", @@ -16736,7 +17293,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to ensure AI agent actions offer non-repudiation and enable forensic examination to determine accountability.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16816,7 +17373,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16839,7 +17397,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to generate event logs for AAT actions to ensure transparency and auditability.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16919,7 +17477,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -16942,7 +17501,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to control AI agent sessions by:\n(1) Embedding session IDs into the requests to the AI model;\n(2) Implementing capabilities to correlate sessions; and\n(3) Terminating sessions after a defined time period.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17022,10 +17581,15 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", - "crosswalks": {} + "crosswalks": { + "emea-sau-otcc-1-2022": [ + "2-2-1-4" + ] + } }, { "control_id": "AAT-31", @@ -17045,7 +17609,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to prevent cognitive overload or decision fatigue for humans-in-the-loop (HITL) through risk-based prioritization.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17125,7 +17689,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": {} @@ -17148,7 +17713,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to implement Robotic Process Automation (RPA) to improve efficiency, accuracy and speed for high-volume, repetitive and rules-based business processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -17226,7 +17791,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -17337,7 +17903,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Artificial Intelligence & Autonomous Technologies", "crosswalks": { @@ -17347,6 +17914,109 @@ "6.7.4" ] } + }, + { + "control_id": "AAT-33", + "title": "Release Owner Gate (ROG) For AI-Augmented Content", + "family": "AAT", + "description": "Mechanisms exist to implement a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization.", + "scf_question": "Does the organization implement a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Artificial Intelligence and Autonomous Technology (AAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ AAT-related processes are expected to follow the organization's existing processes (e.g., incident response, asset management, change control, risk assessments, etc.).\n▪ No formal Governance, Risk & Compliance (GRC) team exists to provide AAT oversight, where the Chief Information Officer (CIO), or similar function, governs technology decisions what is acceptable for AAT within the organization.", + "2": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are documented and maintained by process owners.\n▪ 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 AAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Artificial Intelligence (AI)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Artificial Intelligence and Autonomous Technology (AAT) 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:\n▪ Policies and standards associated with AAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AAT domain capabilities are well-documented and kept current by process owners.\n▪ An Artificial Intelligence Governance (AIG) team, or similar function, is appropriately staffed and supported to implement and maintain AAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of AI governance, risk management and compliance operations (e.g., dedicated AI governance platform).\n▪ 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 AAT 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).\n▪ An implemented and operational capability exists to govern a Release Owner Gate (ROG), or similar function, that prohibits the external release of AI-augmented content without formal Subject Matter Expert (SME) review and Line of Business (LOB) approval that validates:\n(1) Material facts;\n(2) Citations; and\n(3) Other relevant content that could discredit the organization.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Manual review and approval process before publishing AI-generated content\n∙ Designated content reviewer for AI-assisted materials", + "small": "∙ Documented AI content review workflow\n∙ SME review checklist for AI-augmented content\n∙ Management sign-off before external release", + "medium": "∙ Formal content release workflow with ROG checkpoint\n∙ SME review requirements for AI-augmented content\n∙ CMS approval workflow for externally published content", + "large": "∙ Enterprise ROG program with defined approval authorities\n∙ Automated flagging of AI-augmented content for review\n∙ Cross-functional review panel for sensitive AI content", + "enterprise": "∙ Enterprise AI content governance program\n∙ Automated AI content detection and flagging\n∙ Multi-stage ROG approval workflows in enterprise CMS\n∙ Board-level visibility into high-risk AI content releases" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Artificial Intelligence & Autonomous Technologies", + "crosswalks": {} } ] } \ No newline at end of file diff --git a/docs/api/families/AST.json b/docs/api/families/AST.json index 4f4919e1..edffd27b 100644 --- a/docs/api/families/AST.json +++ b/docs/api/families/AST.json @@ -1,7 +1,7 @@ { "family_code": "AST", "family_name": "Asset Management", - "control_count": 63, + "control_count": 64, "controls": [ { "control_id": "AST-01", @@ -23,11 +23,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to facilitate an IT Asset Management (ITAM) program to implement and manage asset management controls.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -98,7 +98,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -113,8 +114,8 @@ "CC6.1-POF9" ], "general-cis-csc-8-1": [ - "1.0", - "2.0", + "1", + "2", "2.1", "2.2" ], @@ -217,6 +218,13 @@ "03.04.11.a", "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.18.a[01]", + "A.03.04.11.a[02]", + "A.03.07.04.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 1", "NIST Tenet 5" @@ -319,15 +327,18 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PM-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)", - "164.310(d)(1)", - "164.310(d)(2)(i)" + "§ 164.308(a)(7)(ii)(E)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)" ], "usa-federal-irs-1075-2021": [ "2.B.7.1", @@ -353,8 +364,8 @@ "PM-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(53)", - "3.5(54)" + "3.5.53", + "3.5.54" ], "emea-eu-nis2-2022": [ "Article 21.2(i)" @@ -367,51 +378,29 @@ "12.2.3", "12.3.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "12.2" - ], "emea-deu-c5-2020": [ "AM-03" ], "emea-sau-cscc-1-2019": [ - "2-1", - "2-5" - ], - "emea-sau-ecc-1-2018": [ - "2-1-1", - "2-1-2", - "2-6-1", - "2-6-2", - "2-6-4" + "1-3-1" ], "emea-sau-otcc-1-2022": [ - "2-1" + "2-1-1", + "2-1-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.3" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" + "3.3.3", + "3.3.3.1", + "3.3.3.3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" - ], - "emea-esp-decree-311-2022": [ - "18" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-gbr-caf-4-0": [ "A3" ], - "emea-gbr-cap-1850-2020": [ - "A3" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2" ], "emea-gbr-def-stan-05-138-2024": [ "1300", @@ -431,7 +420,7 @@ "1301", "2202" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0285", "ISM-0286", "ISM-0289", @@ -440,10 +429,6 @@ "ISM-1457", "ISM-1480" ], - "apac-aus-ps-cps-234-2019": [ - "21", - "21(c)" - ], "apac-ind-sebi-2024": [ "GV.PO.S5" ], @@ -453,34 +438,29 @@ "8.1.1.1", "8.1.1.6.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP05", "HHSP54", "HML05", "HML54" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS12", - "HMS14" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP05", "HSUP46" ], "apac-nzl-ism-3-9": [ - "8.4.9.C.01" + "8.4.9.C.01", + "20.2.15.C.04", + "20.2.15.C.07" ], "apac-sgp-mas-trm-2021": [ - "3.3.1", - "3.3.1(a)", - "3.3.1(d)", - "7.1.1", - "11.4.1", - "11.4.2", - "11.4.3" + "3.3.1" ], - "americas-bmu-mba-coc-2020": [ - "5.9" + "americas-arg-ppd-2018": [ + "B.1.3-3" ], "americas-can-osfi-b13-2022": [ "2.2", @@ -518,7 +498,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ Data / process owners maintain limited network diagrams to document the flow of sensitive/regulated data that is specific to their initiative.\n▪ Inventory of physical technology assets are assigned to individual users or teams and covers common devices (e.g., laptops, workstations and servers).\n▪ No structured process exists to review or share the results of the inventories.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to i identify and assess the security of Technology Assets, Applications and/or Services (TAAS) that support more than one critical business function.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to i identify and assess the security of Technology Assets, Applications and/or Services (TAAS) that support more than one critical business function. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -581,9 +561,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -621,6 +601,9 @@ "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -647,10 +630,10 @@ "THIRD-PARTIES-1a" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-nerc-cip-2024": [ "CIP-011-3 1.2" @@ -659,19 +642,27 @@ "III.B.1.a" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "emea-eu-dora-2023": [ "Article 8.5" ], "emea-deu-bsrit-2017": [ - "12.2" + "3.3" + ], + "emea-sau-cscc-1-2019": [ + "3-1-1-2" ], "emea-sau-cgiot-2024": [ "4-1-4" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "op.cont.3" + ], "emea-gbr-caf-4-0": [ "A3", "A3.a (point 2)" @@ -679,14 +670,29 @@ "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ps-cps-234-2019": [ - "21(a)" + "apac-aus-ps-cps-230-2023": [ + "34(a)" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.3" + ], + "apac-sgp-mas-trm-2021": [ + "3.3.1(a)", + "8.1.2" + ], + "americas-arg-ppd-2018": [ + "B.1.1" ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.2", "2.9.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2", + "2.9.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.03" ] @@ -712,7 +718,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Inventories may be manual (e.g., spreadsheets) or automated.\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to identify and involve pertinent stakeholders of critical TAASD to support the ongoing secure management of those assets.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -757,7 +763,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -849,12 +856,28 @@ "III.A" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.2(16)", - "3.5(54)" + "3.5.54" + ], + "emea-deu-c5-2020": [ + "AM-02" + ], + "emea-qat-pdppl-2020": [ + "3.11.2" + ], + "emea-sau-cscc-1-2019": [ + "2-1-1-2" ], "emea-sau-otcc-1-2022": [ "2-1-1-4" ], + "emea-esp-decree-311-2022": [ + "Article 11(1)", + "Article 11(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], "emea-gbr-caf-4-0": [ "A3.a (point 4)" ], @@ -887,7 +910,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement a scalable, standardized naming convention for TAASD that avoids asset naming conflicts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -941,7 +964,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -973,7 +997,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ Inventory of physical technology assets are assigned to individual users or teams and covers common devices (e.g., laptops, workstations and servers).\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ No structured process exists to review or share the results of the inventories.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain a current list of approved technologies (hardware and software).", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain a current list of approved technologies (hardware and software). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1044,13 +1068,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { + "general-nist-800-171-r3": [ + "03.04.08.c" + ], "general-nist-800-171a-r3": [ "A.03.04.08.c" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(1)" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP2-2" + ], "emea-gbr-def-stan-05-138-2024": [ "2410" ], @@ -1063,8 +1097,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2410" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS12" + "apac-sgp-mas-trm-2021": [ + "3.3.1(a)", + "6.5.1" + ], + "americas-can-itsp-10-171-2025": [ + "03.04.08.C" ] } }, @@ -1119,11 +1157,15 @@ "MT-5", "MT-8", "MT-9", - "MT-10" + "MT-10", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Asset Management", - "crosswalks": {} + "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ] + } }, { "control_id": "AST-02", @@ -1148,11 +1190,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Inventories may be manual (e.g., spreadsheets) or automated.\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ No structured process exists to review or share the results of the inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to perform inventories of TAASD that:\n(1) Accurately reflects the current TAASD in use; \n(2) Identifies authorized software products, including business justification details;\n(3) Is at the level of granularity deemed necessary for tracking and reporting;\n(4) Includes organization-defined information deemed necessary to achieve effective property accountability; and\n(5) Is available for review and audit by designated organizational personnel.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -1226,7 +1268,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -1239,9 +1282,9 @@ "CC6.1-POF1" ], "general-cis-csc-8-1": [ - "1.0", + "1", "1.1", - "2.0", + "2", "2.1", "2.2", "2.4", @@ -1328,7 +1371,7 @@ "general-iso-27018-2025": [ "5.9" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011.001", "T1020.001", "T1021.001", @@ -1518,13 +1561,13 @@ "3.4.1[f]" ], "general-nist-800-171a-r3": [ + "A.03.04.08.a", + "A.03.04.08.c", "A.03.04.10.ODP[01]", "A.03.04.10.a", "A.03.04.10.b[01]", - "A.03.04.10.b[02]" - ], - "general-nist-800-172": [ - "3.1.2e" + "A.03.04.10.b[02]", + "A.03.04.11.a[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -1573,9 +1616,6 @@ "9.5.1", "9.5.1.1" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG1.SP1" ], @@ -1630,11 +1670,14 @@ "CM-08", "PM-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(3)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "PM-5" @@ -1680,8 +1723,9 @@ "CM-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(53)", - "3.5(54)" + "3.3.2.16", + "3.5.53", + "3.5.54" ], "emea-eu-dora-2023": [ "Article 8.4", @@ -1697,20 +1741,16 @@ "12.4.2(a)", "12.4.2(b)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ - "8.2", - "12.2" + "3.3", + "8.2" ], "emea-deu-c5-2020": [ "AM-01", - "AM-02" + "RB-12" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 1" ], "emea-sau-cscc-1-2019": [ "2-1-1-1" @@ -1719,12 +1759,11 @@ "2-1-1" ], "emea-sau-otcc-1-2022": [ - "2-1", - "2-1-1", - "2-1-1-3" + "2-1-1-1" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.1 [OP.EXP.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "emea-uae-niaf-2023": [ "3.1.1" @@ -1758,10 +1797,11 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0336", "ISM-1643", - "ISM-1807" + "ISM-1807", + "ISM-1966" ], "apac-ind-sebi-2024": [ "ID.AM.S1", @@ -1775,8 +1815,8 @@ "8.1.1.4", "8.1.2.3" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS03" + "apac-mys-bnm-rmit-2025": [ + "11.3" ], "apac-nzl-ism-3-9": [ "8.4.8.C.01", @@ -1784,19 +1824,24 @@ ], "apac-sgp-mas-trm-2021": [ "3.3.1(a)", - "3.3.2" + "3.3.2", + "11.5.1" + ], + "americas-arg-ppd-2018": [ + "B.1.1", + "D.1.1-4" ], "americas-bmu-mba-coc-2020": [ "5.9" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" - ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.2", "2.2.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.08.C", @@ -1824,9 +1869,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to update asset inventories as part of component installations, removals and asset upgrades.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to update asset inventories as part of component installations, removals and asset upgrades. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1865,7 +1910,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -1920,6 +1966,8 @@ "3.4.1[f]" ], "general-nist-800-171a-r3": [ + "A.03.04.10.a", + "A.03.04.10.b[02]", "A.03.04.10.c[01]", "A.03.04.10.c[02]", "A.03.04.10.c[03]" @@ -1940,10 +1988,10 @@ "CM-08(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "CM-8(CE-1)" @@ -1961,14 +2009,13 @@ "12.4.3" ], "emea-deu-c5-2020": [ - "AM-01", - "AM-02" + "AM-01" ], "emea-sau-cgiot-2024": [ "2-1-2" ], - "emea-sau-otcc-1-2022": [ - "2-1-1-1" + "americas-arg-ppd-2018": [ + "B.1.3-1" ], "americas-can-itsp-10-171-2025": [ "03.04.10.A", @@ -1995,7 +2042,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to automatically detect and alert upon the detection of unauthorized hardware, software and firmware components.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2034,7 +2081,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -2104,6 +2152,13 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.a", + "A.03.04.02E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 6" @@ -2123,6 +2178,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-08(03)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(2)" + ], "usa-federal-irs-1075-2021": [ "CM-8(CE-3)", "CM-8(CE-3).a", @@ -2139,12 +2197,6 @@ "CM-8(3)-IS.1", "CM-8(3)-IS.2" ], - "emea-deu-c5-2020": [ - "AM-02" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], "emea-gbr-def-stan-05-138-2024": [ "3204" ], @@ -2157,7 +2209,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3204" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1807" ] } @@ -2231,7 +2283,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -2362,9 +2415,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to document and govern instances of approved deviations from established baseline configurations.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to document and govern instances of approved deviations from established baseline configurations. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2422,7 +2475,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -2448,11 +2502,9 @@ "03.04.02.b", "03.04.06.a" ], - "emea-deu-c5-2020": [ - "SP-03" - ], - "emea-isr-cmo-1-0": [ - "6.8" + "general-nist-800-171a-r3": [ + "A.03.04.02.a[02]", + "A.03.04.06.a" ], "emea-gbr-def-stan-05-138-2024": [ "2202" @@ -2463,6 +2515,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2202" ], + "apac-sgp-mas-trm-2021": [ + "3.2.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", "03.04.06.A" @@ -2487,7 +2545,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to automatically employ Network Access Control (NAC), or a similar technology, which is capable of detecting unauthorized devices and disable network access to those unauthorized devices.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2502,7 +2560,7 @@ "small": "∙ VLAN segmentation to isolate unknown devices\n∙ MAC address filtering (basic NAC)\n∙ Wireless access point policies", "medium": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Open-source NAC (e.g., PacketFence)", "large": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ 802.1X certificate-based authentication", - "enterprise": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Zero Trust Network Access (ZTNA) integration\n∙ 802.1X with EAP-TLS and certificate infrastructure" + "enterprise": "∙ Cisco Identity Services Engine (ISE) (https://cisco.com)\n∙ HPE Aruba Central (https://arubanetworks.com)\n∙ Juniper Mist Access Assurance (https://juniper.net)\n∙ Zero Trust Network Architecture (ZTNA) integration\n∙ 802.1X with EAP-TLS and certificate infrastructure" }, "risks": [ "R-AC-1", @@ -2554,7 +2612,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -2581,9 +2640,6 @@ "general-nist-800-161-r1-level-3": [ "SC-7(19)" ], - "general-nist-800-172": [ - "3.5.3e" - ], "general-nist-800-207": [ "NIST Tenet 6" ], @@ -2596,19 +2652,14 @@ "usa-federal-dow-cmmc-2-level-3": [ "IA.L3-3.5.3E" ], - "emea-isr-cmo-1-0": [ - "23.6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0520", "ISM-1182" ], "apac-sgp-mas-trm-2021": [ - "11.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "4.21", - "4.24" + "11.2.4", + "11.2.5", + "11.5.4" ] } }, @@ -2634,7 +2685,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to enable Dynamic Host Configuration Protocol (DHCP) server logging to improve asset inventories and assist in detecting unknown systems.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to enable Dynamic Host Configuration Protocol (DHCP) server logging to improve asset inventories and assist in detecting unknown systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2691,7 +2742,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -2734,7 +2786,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Software licensing is tracked as part of IT asset inventories.\n▪ Software licensing restrictions for users, as part of acceptable and unacceptable behaviors are primarily administrative and preventative in nature.", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to protect Intellectual Property (IP) rights with software licensing restrictions.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to protect Intellectual Property (IP) rights with software licensing restrictions.\n", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2782,7 +2834,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -2849,11 +2902,8 @@ "usa-federal-irs-1075-2021": [ "SC-18(CE-2)" ], - "emea-isr-cmo-1-0": [ - "3.1" - ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "3-BP1" ], "apac-jpn-ismap": [ "14.2.7.1", @@ -2870,9 +2920,6 @@ "18.1.2.10", "18.1.2.11", "18.1.2.12" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS14" ] } }, @@ -2880,8 +2927,8 @@ "control_id": "AST-02.8", "title": "Data Action Mapping", "family": "AST", - "description": "Mechanisms exist to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed.", - "scf_question": "Does the organization create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed?", + "description": "Mechanisms exist to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive and/or regulated data is stored, transmitted or processed.", + "scf_question": "Does the organization create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive and/or regulated data is stored, transmitted or processed?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -2896,7 +2943,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT and/or cybersecurity personnel work with process owners to generate and maintain Data Flow Diagrams (DFDs) and network diagrams to document the flow of data to create and maintain a map of systems where sensitive/regulated data is stored, transmitted or processed.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to create and maintain a map of Technology Assets, Applications and/or Services (TAAS) where sensitive/regulated data is stored, transmitted or processed.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2958,7 +3005,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -3007,16 +3055,16 @@ "A.03.04.11.b[01]", "A.03.04.11.b[02]" ], - "general-nist-800-172": [ - "3.1.3e" + "general-nist-800-172-r3": [ + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.14E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 1", "NIST Tenet 7" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DA.DAUTE" ], @@ -3034,8 +3082,9 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(4)(A)" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-16" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "apac-ind-sebi-2024": [ "ID.AM.S2" @@ -3064,7 +3113,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and manage a Configuration Management Database (CMDB), or similar technology, to monitor and govern technology asset-specific information.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3132,7 +3181,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -3208,12 +3258,28 @@ "general-nist-800-171-r3": [ "03.04.08.a", "03.04.10.a", - "03.04.10.b", - "03.04.10.c" + "03.04.10.b" + ], + "general-nist-800-171a-r3": [ + "A.03.04.08.a", + "A.03.04.10.a", + "A.03.04.10.b[02]" ], - "general-nist-800-172": [ - "3.4.1e", - "3.4.3e" + "general-nist-800-172-r3": [ + "03.04.03E", + "03.04.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.03E[01]", + "A.03.04.03E.ODP[01]", + "DS-A.03.04.03E[02]", + "A.03.04.03E.ODP[02]", + "DS-A.03.04.03E[03]", + "A.03.04.03E.ODP[03]", + "DS-A.03.04.04E[01]", + "DS-A.03.04.04E[02]", + "DS-A.03.04.04E[03]", + "DS-A.03.04.08E" ], "general-nist-800-207": [ "NIST Tenet 1", @@ -3243,18 +3309,36 @@ "CM-08(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.5.54" + ], + "emea-deu-c5-2020": [ + "AM-01", + "AM-01-DOAR", + "RB-12" ], "emea-sau-cgiot-2024": [ "2-1-2" ], "emea-sau-otcc-1-2022": [ - "2-1-1", - "2-1-1-2", - "2-1-1-3" + "2-1-1-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.3.3", + "3.3.3.3.a", + "3.3.3.3.b", + "3.3.3.3.c", + "3.3.3.3.d", + "3.3.3.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-def-stan-05-138-2024": [ "1301", @@ -3271,17 +3355,26 @@ "1301", "2423" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1493" ], + "apac-mys-bnm-rmit-2025": [ + "11.3" + ], + "apac-nzl-ism-3-9": [ + "20.2.15.C.07" + ], "americas-can-osfi-b13-2022": [ "2.2.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.2", + "2.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.10.A", - "03.04.10.B", - "03.04.10.C" + "03.04.10.B" ] } }, @@ -3303,11 +3396,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to track the geographic location of system components.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -3336,7 +3429,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -3413,7 +3507,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -3455,11 +3550,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure asset ownership responsibilities are assigned, tracked and managed at a team, individual, or responsible organization level to establish a common understanding of requirements for asset protection.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -3531,7 +3626,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -3576,6 +3672,9 @@ "general-nist-800-171-r3": [ "03.09.02.a.03" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.03" + ], "general-nist-csf-2-0": [ "ID.AM" ], @@ -3620,9 +3719,6 @@ "2.2.5", "6.5.2" ], - "general-scf-dpmp-2025": [ - "5.3" - ], "general-tisax-6-0-3": [ "1.3.1" ], @@ -3642,10 +3738,10 @@ "SA-04(12)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-4(CE-12)", @@ -3654,20 +3750,20 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.A" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-deu-c5-2020": [ + "AM-02" ], "emea-sau-cscc-1-2019": [ "2-1-1-2" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], "emea-gbr-caf-4-0": [ "A3.a (point 4)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1071" ], "apac-ind-sebi-2024": [ @@ -3679,6 +3775,14 @@ "8.1.2.1", "8.1.2.2" ], + "americas-arg-ppd-2018": [ + "B.1.2-1", + "B.1.2-2" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP1", + "5.9-BP2" + ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" ] @@ -3704,7 +3808,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Data/process owners for business-critical assets are documented and are reviewed as part of the annual asset inventories.\n▪ Annual IT asset inventories validate or update stakeholders /owners.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to include capturing the name, position and/or role of individuals responsible/accountable for administering assets as part of the technology asset inventory process.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3772,7 +3876,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -3827,12 +3932,12 @@ "general-nist-800-171-r3": [ "03.09.02.a.03" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.03" + ], "general-nist-csf-2-0": [ "ID.AM" ], - "general-scf-dpmp-2025": [ - "5.3" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG1.SP3" ], @@ -3840,10 +3945,14 @@ "CM-08(04)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(iii)" + "§ 164.310(d)(2)(iii)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" @@ -3947,7 +4056,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -3972,7 +4082,7 @@ "general-iso-42001-2023": [ "A.7.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -4020,6 +4130,15 @@ "general-nist-800-161-r1-level-3": [ "SR-4" ], + "general-nist-800-172-r3": [ + "03.17.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.04E[01]", + "A.03.17.04E.ODP[01]", + "DS-A.03.17.04E[02]", + "DS-A.03.17.04E[03]" + ], "general-sparta": [ "CM0026", "CM0049" @@ -4027,10 +4146,14 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "4.2" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1790", "ISM-1791", - "ISM-1792" + "ISM-1792", + "ISM-1816" ] } }, @@ -4038,8 +4161,8 @@ "control_id": "AST-04", "title": "Network Diagrams & Data Flow Diagrams (DFDs)", "family": "AST", - "description": "Mechanisms exist to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive/regulated data flows.", - "scf_question": "Does the organization maintain network architecture diagrams that: \n (1) Contain sufficient detail to assess the security of the network's architecture;\n (2) Reflect the current architecture of the network environment; and\n (3) Document all sensitive/regulated data flows?", + "description": "Mechanisms exist to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive and/or regulated data flows.", + "scf_question": "Does the organization maintain network architecture diagrams that: \n (1) Contain sufficient detail to assess the security of the network's architecture;\n (2) Reflect the current architecture of the network environment; and\n (3) Document all sensitive and/or regulated data flows?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -4056,7 +4179,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT and/or cybersecurity personnel work with process owners to generate and maintain Data Flow Diagrams (DFDs) and network diagrams to document the flow of data to create and maintain a map of systems where sensitive/regulated data is stored, transmitted or processed.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain network architecture diagrams that: \n(1) Contain sufficient detail to assess the security of the network's architecture;\n(2) Reflect the current architecture of the network environment; and\n(3) Document all sensitive/regulated data flows.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4129,7 +4252,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -4267,8 +4391,17 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.1.3e" + "general-nist-800-171a-r3": [ + "A.03.01.03[02]", + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.14E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -4295,9 +4428,6 @@ "1.2.3", "1.2.4" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "general-sparta": [ "CM0022" ], @@ -4339,6 +4469,9 @@ "SA-04(01)", "SA-04(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(4)" + ], "usa-federal-irs-1075-2021": [ "PL-2", "SA-4(CE-1)", @@ -4374,19 +4507,21 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(a)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "COS-07" + "KOS-06" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 1" ], "emea-sau-otcc-1-2022": [ "2-4-1-16" ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "op.mon.1", + "mp.com.1" + ], "emea-gbr-caf-4-0": [ "B3.a" ], @@ -4405,26 +4540,36 @@ "1203", "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0516", "ISM-0518", "ISM-1645", "ISM-1646" ], + "apac-aus-ps-cps-230-2023": [ + "34(a)" + ], "apac-ind-sebi-2024": [ "ID.AM.S2" ], "apac-jpn-ismap": [ "4.4.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.41" + ], "apac-nzl-ism-3-9": [ "18.1.9.C.02", "18.1.11.C.01", "18.1.12.C.01", "18.1.12.C.02" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" + "apac-sgp-mas-trm-2021": [ + "8.1.2" + ], + "americas-arg-ppd-2018": [ + "B.1.1", + "E.1.1-2" ], "americas-can-itsp-10-171-2025": [ "03.01.03", @@ -4456,7 +4601,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to determine security, compliance and resilience control applicability by identifying, assigning and documenting the appropriate asset scope categorization for all Technology Assets, Applications and/or Services (TAAS) and personnel (internal and third-parties).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4515,9 +4660,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -4606,8 +4751,16 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.14.3e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.06.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.06.03E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -4677,16 +4830,31 @@ "SA-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)" + "3.3.3.17", + "3.3.3.18" ], "emea-eu-nis2-annex-2024": [ "11.7.2", "12.1.1", "12.1.3" ], - "emea-deu-bsrit-2017": [ - "12.4" + "emea-sau-ecc-1-2018": [ + "2-1-5" + ], + "emea-esp-decree-311-2022": [ + "Article 40(1)", + "Article 40(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.2" + ], + "apac-aus-ps-cps-230-2023": [ + "36", + "36(a)", + "36(b)", + "36(c)", + "36(d)", + "37" ], "apac-jpn-ismap": [ "4.4.4", @@ -4720,7 +4888,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure control applicability is appropriately-determined for Technology Assets, Applications and/or Services (TAAS) and third parties by graphically representing applicable boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4754,7 +4922,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -4767,6 +4936,11 @@ "03.04.11.b", "03.15.02.a.04" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], "general-nist-csf-2-0": [ "ID.AM-03" ], @@ -4794,9 +4968,6 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.B.1.c" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-16" - ], "americas-can-itsp-10-171-2025": [ "03.04.11.A", "03.04.11.B", @@ -4858,13 +5029,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-pci-dss-4-0-1": [ "6.3.2", "12.5.1", @@ -4896,8 +5071,8 @@ "control_id": "AST-05", "title": "Security of Assets & Media", "family": "AST", - "description": "Mechanisms exist to maintain strict control over the internal or external distribution of any kind of sensitive/regulated media.", - "scf_question": "Does the organization maintain strict control over the internal or external distribution of any kind of sensitive/regulated media?", + "description": "Mechanisms exist to maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity.", + "scf_question": "Does the organization maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -4910,9 +5085,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT personnel collect technology assets and media for destruction when it is no longer needed for business or legal reasons.", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain strict control over the internal or external distribution of any kind of sensitive/regulated media.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to maintain strict control over Technology Assets, Applications, Services and/or Data (TAASD) to preserve confidentiality and integrity.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4998,8 +5173,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed", "family_name": "Asset Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -5023,6 +5200,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-pci-dss-4-0-1": [ "9.4", "9.4.4" @@ -5054,18 +5234,19 @@ "emea-eu-nis2-annex-2024": [ "12.2.2(c)" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0161", "ISM-0293", - "ISM-1178" + "ISM-1178", + "ISM-1973" ], "apac-jpn-ismap": [ "8.3", "8.3.1" ], + "apac-nzl-ism-3-9": [ + "17.9.36.C.01" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.A" ] @@ -5075,8 +5256,8 @@ "control_id": "AST-05.1", "title": "Management Approval For External Media Transfer", "family": "AST", - "description": "Mechanisms exist to obtain management approval for any sensitive/regulated media that is transferred outside of the organization's facilities.", - "scf_question": "Does the organization obtain management approval for any sensitive/regulated media that is transferred outside of its facilities?", + "description": "Mechanisms exist to obtain management approval for any sensitive and/or regulated media that is transferred outside of the organization's facilities.", + "scf_question": "Does the organization obtain management approval for any sensitive and/or regulated media that is transferred outside of its facilities?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5164,7 +5345,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -5207,6 +5389,120 @@ ] } }, + { + "control_id": "AST-05.2", + "title": "Technology Assets, Applications, Services and/or Data (TAASD) Storage", + "family": "AST", + "description": "Mechanisms exist to ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "scf_question": "Does the organization ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", + "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications, Services and/or Data (TAASD) are stored in rooms and/or facilities with reasonable physical security protections.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Locked cabinet or secure room for equipment\n∙ Basic physical access controls (key or PIN)", + "small": "∙ Locked server room with physical access controls\n∙ Physical access log\n∙ Environmental controls (temperature, humidity)", + "medium": "∙ Dedicated server room with physical access controls and monitoring\n∙ Physical access logging\n∙ Co-location or private cage in certified data center", + "large": "∙ Secure data center facilities (access control, CCTV, environmental monitoring)\n∙ Co-location or private cage in certified data center\n∙ Physical security assessments", + "enterprise": "∙ Co-location or private cage in certified data center\n∙ Multi-layer physical access controls (mantraps, biometrics)\n∙ 24/7 physical security monitoring\n∙ Redundant physical infrastructure" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - AU ISM ISM-1975", + "family_name": "Asset Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1974", + "ISM-1975" + ] + } + }, { "control_id": "AST-06", "title": "Unattended End-User Equipment", @@ -5310,7 +5606,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -5354,10 +5651,13 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.5.1" ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.2 [MP.EQ.2]" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0161" ], "apac-jpn-ismap": [ @@ -5455,21 +5755,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", - "crosswalks": { - "emea-deu-c5-2020": [ - "AM-02" - ] - } + "crosswalks": {} }, { "control_id": "AST-07", "title": "Kiosks & Point of Interaction (PoI) Devices", "family": "AST", - "description": "Mechanisms exist to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution.", - "scf_question": "Does the organization appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution?", + "description": "Mechanisms exist to appropriately protect devices that capture sensitive and/or regulated data via direct physical interaction from tampering and substitution.", + "scf_question": "Does the organization appropriately protect devices that capture sensitive and/or regulated data via direct physical interaction from tampering and substitution?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5484,7 +5781,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to appropriately protect devices that capture sensitive/regulated data via direct physical interaction from tampering and substitution. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5565,7 +5862,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -5614,8 +5912,9 @@ "9.5.1.1", "9.5.1.2" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.12" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ] } }, @@ -5720,7 +6019,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -5742,6 +6042,14 @@ "general-iso-27018-2025": [ "7.9" ], + "general-nist-800-172-r3": [ + "03.17.02E", + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.02E.ODP[04]", + "A.03.17.05E.ODP[02]" + ], "general-pci-dss-4-0-1": [ "9.5.1.2", "9.5.1.2.1" @@ -5884,7 +6192,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -5981,6 +6290,10 @@ "03.07.04.c", "03.08.03" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.c", + "A.03.08.03" + ], "general-pci-dss-4-0-1": [ "9.4.7" ], @@ -6028,12 +6341,12 @@ "314.4(c)(6)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(i)", - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(i)", + "§ 164.310(d)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.F.3.1" @@ -6055,16 +6368,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-12" ], - "emea-us-psd2-2015": [ - "24" - ], "emea-deu-c5-2020": [ - "AM-04", - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "15.4", - "17.21" + "AM-04" ], "emea-sau-cgiot-2024": [ "2-5-1", @@ -6073,18 +6378,16 @@ "emea-sau-ecc-1-2018": [ "2-14-3-4" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" - ], "emea-sau-sacs-002-2022": [ - "TPC-19", - "TPC-66" + "VII.A.TPC-19", + "VII.B.TPC-66" ], "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.5 [MP.SI.5]" + "3.3.2.3.e", + "3.3.11", + "3.3.11.1", + "3.3.11.4", + "3.3.11.5" ], "emea-gbr-def-stan-05-138-2024": [ "2323" @@ -6098,7 +6401,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0312", "ISM-0315", @@ -6119,7 +6422,6 @@ "ISM-1221", "ISM-1222", "ISM-1223", - "ISM-1225", "ISM-1534", "ISM-1550", "ISM-1641", @@ -6148,7 +6450,7 @@ "11.2.7.1", "11.2.7.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP06", "HHSP45", "HML06", @@ -6159,8 +6461,11 @@ ], "apac-nzl-ism-3-9": [ "11.2.13.C.01", - "11.2.13.C.02", "11.7.35.C.01", + "11.8.10.C.03", + "11.8.10.C.05", + "11.8.12.C.01", + "11.8.12.C.02", "12.6.4.C.01", "12.6.4.C.02", "12.6.5.C.01", @@ -6171,8 +6476,8 @@ "12.6.8.C.01", "12.6.9.C.01", "12.6.10.C.01", - "13.4.19.C.02", "13.4.10.C.01", + "13.4.19.C.02", "13.5.24.C.01", "13.5.24.C.02", "13.5.24.C.03", @@ -6193,15 +6498,23 @@ "13.6.10.C.02", "13.6.10.C.03", "13.6.11.C.01", - "13.6.12.C.01" + "13.6.12.C.01", + "17.6.6.C.01" ], "apac-sgp-mas-trm-2021": [ "11.1.7" ], + "americas-arg-ppd-2018": [ + "F", + "F.1.2-DS-2" + ], "americas-can-osfi-b13-2022": [ "2.2", "2.2.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.C", "03.08.03" @@ -6296,7 +6609,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -6323,11 +6637,10 @@ "A.03.09.02.a.03" ], "emea-deu-c5-2020": [ - "AM-04", - "AM-05" + "AM-04" ], - "emea-isr-cmo-1-0": [ - "11.12" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e.2" ], "apac-jpn-ismap": [ "8.1.4" @@ -6357,7 +6670,7 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to authorize, control and track technology assets entering and exiting organizational facilities.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to authorize, control and track technology assets entering and exiting organizational facilities. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6425,7 +6738,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -6445,10 +6759,15 @@ "164.310(d)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ] } }, @@ -6561,7 +6880,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -6576,11 +6896,15 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], - "emea-isr-cmo-1-0": [ - "12.6" + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4", + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A" @@ -6605,7 +6929,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to reduce the risk associated with third-party assets that are attached to the network from harming organizational assets or exfiltrating organizational data.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6678,22 +7002,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-nist-800-171-r3": [ "03.01.18.a" ], - "emea-isr-cmo-1-0": [ - "12.6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-84" - ], - "apac-nzl-ism-3-9": [ - "16.2.3.C.01", - "16.2.3.C.02" + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A" @@ -6718,11 +7036,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to monitor and enforce usage parameters that limit the potential damage caused from the unauthorized or unintentional alteration of system parameters.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to monitor and enforce usage parameters that limit the potential damage caused from the unauthorized or unintentional alteration of system parameters. \n", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -6779,11 +7097,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011", "T1078", "T1078.004", @@ -6802,6 +7121,9 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" + ], "general-swift-cscf-2025": [ "2.9" ], @@ -6828,7 +7150,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to prevent the usage of Bluetooth and wireless devices (e.g., Near Field Communications (NFC)) in sensitive areas or unless used in a Radio Frequency (RF)-screened building.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6899,7 +7221,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -6910,22 +7233,13 @@ "usa-federal-fbi-cjis-6-0": [ "5.20.1.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0233", "ISM-1199", "ISM-1200" ], "apac-nzl-ism-3-9": [ - "11.1.8.C.01", - "11.1.10.C.01", - "11.1.10.C.02", - "11.1.10.C.03", - "11.1.11.C.01", - "11.1.11.C.02", - "11.1.12.C.01", - "11.1.13.C.01", - "21.1.16.C.01", - "21.1.16.C.02" + "11.1.19.C.03" ] } }, @@ -7018,7 +7332,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -7026,9 +7341,9 @@ "O.9" ], "apac-nzl-ism-3-9": [ - "11.1.9.C.01", - "11.1.9.C.02", - "11.1.9.C.03" + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03" ] } }, @@ -7056,7 +7371,7 @@ "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Periodic physical inspections are performed to validate the integrity of unattended technology assets (e.g., kiosks, ATMs, point of sale devices, etc.).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to assess the integrity of critical Technology Assets, Applications and/or Services (TAAS) to detect evidence of tampering, where:\n(1)\tLogical assessments evaluate the integrity of critical components (e.g., configuration settings); and\n(2)\tPhysical assessments evaluate assets for evidence of unauthorized access and/or modifications.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -7111,7 +7426,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -7159,6 +7475,12 @@ "general-nist-800-161-r1-level-3": [ "SR-9" ], + "general-nist-800-172-r3": [ + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.05E.ODP[02]" + ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -7216,9 +7538,9 @@ "0": "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.", "1": "Asset Management (AST) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with AST domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Asset management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Asset management is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Periodic physical inspections are performed to validate the integrity of unattended technology assets (e.g., kiosks, ATMs, point of sale devices, etc.).", - "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to physically and logically inspect critical technology assets to detect evidence of tampering.", + "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to physically and logically inspect critical technology assets to detect evidence of tampering. ", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -7289,7 +7611,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -7335,6 +7658,12 @@ "general-nist-800-161-r1-level-3": [ "SR-10" ], + "general-nist-800-172-r3": [ + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.02E" + ], "general-pci-dss-4-0-1": [ "9.5.1", "9.5.1.2" @@ -7401,7 +7730,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ The use of personal devices (e.g., Bring Your Own Device (BYOD), as part of acceptable and unacceptable behaviors are primarily administrative and preventative in nature.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and govern a Bring Your Own Device (BYOD) program to reduce risk associated with personally-owned devices in the workplace.", "4": "Asset Management (AST) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7473,7 +7802,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -7489,19 +7819,23 @@ "general-nist-800-171-r3": [ "03.01.18.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.4", "2.4.2" ], - "emea-sau-cscc-1-2019": [ - "2-5" - ], "emea-sau-ecc-1-2018": [ - "2-6-1", - "2-6-2" + "2-6-1" ], "emea-sau-sama-csf-1-2017": [ - "3.3.10" + "3.3.10.4", + "3.3.10.4.a", + "3.3.10.4.b", + "3.3.10.4.c", + "3.3.10.4.d", + "3.3.10.4.e" ], "emea-gbr-def-stan-05-138-2024": [ "2322" @@ -7515,68 +7849,67 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1297" ], "apac-nzl-ism-3-9": [ "8.1.12.C.01", "21.1.12.C.01", - "21.4.7.C.01", - "21.4.7.C.02", - "21.4.8.C.01", - "21.4.8.C.02", - "21.4.9.C.01", - "21.4.10.C.01", - "21.4.10.C.02", - "21.4.10.C.03", - "21.4.10.C.04", - "21.4.10.C.05", - "21.4.10.C.06", - "21.4.10.C.07", - "21.4.10.C.08", - "21.4.10.C.09", - "21.4.10.C.10", - "21.4.10.C.11", - "21.4.10.C.12", - "21.4.10.C.13", - "21.4.10.C.14", - "21.4.10.C.15", - "21.4.10.C.16", - "21.4.11.C.01", - "21.4.11.C.02", - "21.4.11.C.03", - "21.4.11.C.04", - "21.4.11.C.05", - "21.4.11.C.06", - "21.4.11.C.07", - "21.4.11.C.08", - "21.4.11.C.09", - "21.4.11.C.10", - "21.4.11.C.11", - "21.4.11.C.12", - "21.4.11.C.13", - "21.4.11.C.14", - "21.4.11.C.15", - "21.4.11.C.16", - "21.4.11.C.17", - "21.4.11.C.18", - "21.4.11.C.19", - "21.4.11.C.20", - "21.4.13.C.01", - "21.4.13.C.02", - "21.4.13.C.03", - "21.4.13.C.04", - "21.4.13.C.05", - "21.4.13.C.06", - "21.4.13.C.07", - "21.4.13.C.08", - "21.4.13.C.09", - "21.4.13.C.10", - "21.4.13.C.11", - "21.4.14.C.01", - "21.4.14.C.02", - "21.4.14.C.03", - "21.4.14.C.04" + "22.4.7.C.02", + "22.4.8.C.01", + "22.4.8.C.02", + "22.4.10.C.01", + "22.4.10.C.02", + "22.4.10.C.03", + "22.4.10.C.04", + "22.4.10.C.05", + "22.4.10.C.06", + "22.4.10.C.07", + "22.4.10.C.08", + "22.4.10.C.09", + "22.4.10.C.10", + "22.4.10.C.11", + "22.4.10.C.12", + "22.4.10.C.13", + "22.4.10.C.14", + "22.4.10.C.15", + "22.4.10.C.16", + "22.4.11.C.01", + "22.4.11.C.02", + "22.4.11.C.03", + "22.4.11.C.04", + "22.4.11.C.05", + "22.4.11.C.06", + "22.4.11.C.07", + "22.4.11.C.08", + "22.4.11.C.09", + "22.4.11.C.10", + "22.4.11.C.11", + "22.4.11.C.12", + "22.4.11.C.13", + "22.4.11.C.14", + "22.4.11.C.15", + "22.4.11.C.16", + "22.4.11.C.17", + "22.4.11.C.18", + "22.4.11.C.19", + "22.4.11.C.20", + "22.4.12.C.01", + "22.4.13.C.01", + "22.4.13.C.02", + "22.4.13.C.03", + "22.4.13.C.04", + "22.4.13.C.05", + "22.4.13.C.06", + "22.4.13.C.07", + "22.4.13.C.08", + "22.4.13.C.09", + "22.4.13.C.10", + "22.4.13.C.11", + "22.4.14.C.01", + "22.4.14.C.02", + "22.4.14.C.03", + "22.4.14.C.04" ], "apac-sgp-mas-trm-2021": [ "11.3.7" @@ -7606,7 +7939,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to govern Supply Chain Risk Management (SCRM) sanctions that require the removal and prohibition of certain Technology Assets, Applications and/or Services (TAAS) that are designated as supply chain threats by a statutory or regulatory body.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7680,7 +8013,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -7688,6 +8022,10 @@ "03.11.01.a", "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.16.01" + ], "usa-federal-far-52-204-25": [ "52.204-25(b)(1)", "52.204-25(b)(2)" @@ -7721,7 +8059,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to provision and protect the confidentiality, integrity and authenticity of product supplier keys and data that can be used as a “roots of trust” basis for integrity verification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7786,7 +8124,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -7803,9 +8142,6 @@ "NDR 3.13(a)", "NDR 3.13(b)" ], - "general-nist-800-172": [ - "3.14.1e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -7817,10 +8153,6 @@ ], "emea-sau-cgiot-2024": [ "2-15-1" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 7" ] } }, @@ -7842,7 +8174,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for telecommunication equipment to prevent potential damage or unauthorized modification and to prevent potential eavesdropping.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7906,18 +8238,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0558" ], "apac-nzl-ism-3-9": [ @@ -7935,7 +8261,10 @@ "11.3.12.C.03", "11.3.13.C.01", "11.3.13.C.02", - "11.3.13.C.03" + "11.3.13.C.03", + "11.8.3.C.01", + "11.8.4.C.01", + "11.8.5.C.01" ] } }, @@ -7957,7 +8286,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement secure Video Teleconference (VTC) capabilities on endpoint devices and in designated conference rooms, to prevent potential eavesdropping.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8021,14 +8350,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-shared-assessments-sig-2025": [ "M.1.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0548", "ISM-0551", "ISM-0553", @@ -8037,9 +8367,6 @@ "ISM-1014", "ISM-1562" ], - "apac-chn-pipl-2021": [ - "26" - ], "apac-nzl-ism-3-9": [ "18.3.14.C.01", "18.3.14.C.02" @@ -8064,7 +8391,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement secure Internet Protocol Telephony (IPT) that logically or physically separates Voice Over Internet Protocol (VoIP) traffic from data networks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8128,7 +8455,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -8149,7 +8477,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2412" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0549", "ISM-0551", "ISM-0555", @@ -8184,8 +8512,8 @@ "control_id": "AST-22", "title": "Microphones & Web Cameras", "family": "AST", - "description": "Mechanisms exist to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed.", - "scf_question": "Does the organization configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed?", + "description": "Mechanisms exist to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive and/or regulated information is discussed.", + "scf_question": "Does the organization configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive and/or regulated information is discussed?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8198,7 +8526,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to configure assets to prohibit the use of endpoint-based microphones and web cameras in secure areas or where sensitive/regulated information is discussed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8262,14 +8590,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { "general-shared-assessments-sig-2025": [ "N.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0559", "ISM-1450" ] @@ -8295,7 +8624,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely configure Multi-Function Devices (MFD) according to industry-recognized secure practices for the type of device.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8359,7 +8688,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -8371,35 +8701,23 @@ "3.3.5.b-2", "3.3.5.c-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0245", "ISM-0589", "ISM-0590", - "ISM-1036" + "ISM-1036", + "ISM-1854", + "ISM-1855" ], "apac-nzl-ism-3-9": [ - "11.2.3.C.01", - "11.2.4.C.01", - "11.2.4.C.02", - "11.2.5.C.01", - "11.2.6.C.01", - "11.2.7.C.01", - "11.2.7.C.02", - "11.2.8.C.01", - "11.2.9.C.01", - "11.2.10.C.01", "11.2.11.C.01", "11.2.11.C.02", - "11.2.11.C.03", - "11.2.11.C.04", - "11.2.11.C.05", "11.2.12.C.01", - "11.2.12.C.02", "11.2.13.C.01", - "11.2.13.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.1" + "11.8.3.C.01", + "11.8.7.C.01", + "11.8.8.C.01", + "11.8.13.C.01" ] } }, @@ -8421,7 +8739,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to issue personnel travelling overseas with temporary, loaner or \"travel-only\" end user technology (e.g., laptops and mobile devices) when travelling to authoritarian countries with a higher-than average risk for Intellectual Property (IP) theft or espionage against individuals and private companies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8495,7 +8813,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -8504,9 +8823,10 @@ "03.04.12.b" ], "general-nist-800-171a-r3": [ - "A.03.04.12.a" + "A.03.04.12.a", + "A.03.04.12.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1088", "ISM-1298", "ISM-1299", @@ -8539,7 +8859,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to re-image end user technology (e.g., laptops and mobile devices) when returning from overseas travel to an authoritarian country with a higher-than average risk for Intellectual Property (IP) theft or espionage against individuals and private companies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8617,7 +8937,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -8627,7 +8948,7 @@ "general-nist-800-171a-r3": [ "A.03.04.12.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1300", "ISM-1556" ], @@ -8654,7 +8975,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to develop, implement and govern system administration processes, with corresponding Standardized Operating Procedures (SOP), for operating and maintaining Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8730,11 +9051,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0042", "ISM-1380", "ISM-1385" @@ -8770,7 +9092,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to conduct remote system administrative functions via a \"jump box\" or \"jump server\" that is located in a separate network zone to user workstations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8860,7 +9182,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -8868,6 +9191,11 @@ "03.01.12.a", "03.01.12.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.a[01]", + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" + ], "general-swift-cscf-2025": [ "1.5", "2.6" @@ -8878,14 +9206,11 @@ "emea-sau-cscc-1-2019": [ "2-3-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" - ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1387" ], @@ -8913,7 +9238,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to develop, implement and govern database management processes, with corresponding Standardized Operating Procedures (SOP), for operating and maintaining databases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8989,7 +9314,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -8999,7 +9325,7 @@ "emea-sau-cscc-1-2019": [ "2-2-1-8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0393", "ISM-1243", "ISM-1255", @@ -9024,17 +9350,7 @@ "5.5.3.C.01", "5.5.4.C.01", "5.5.5.C.01", - "5.5.6.C.01", - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" + "5.5.6.C.01" ] } }, @@ -9056,7 +9372,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Database administrators implement and maintain Database Management Systems (DBMSs), where applicable.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to implement and maintain Database Management Systems (DBMSs), where applicable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9130,7 +9446,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -9140,7 +9457,7 @@ "usa-federal-dow-zt-roadmap-1-1": [ "4.4.6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1245", "ISM-1246", "ISM-1247", @@ -9148,18 +9465,6 @@ "ISM-1250", "ISM-1260", "ISM-1263" - ], - "apac-nzl-ism-3-9": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" ] } }, @@ -9181,7 +9486,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ Enhanced security requirements for Bluetooth and wireless devices in sensitive/regulated areas are primarily administrative and preventative in nature.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely govern Radio Frequency Identification (RFID) deployments to ensure RFID is used safely and securely to protect the confidentiality and integrity of data and prevent the compromise of secure spaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9245,7 +9550,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -9273,10 +9579,7 @@ "11.6.68.C.01", "11.6.69.C.01", "11.6.70.C.01", - "11.6.71.C.01", - "11.6.72.C.01", - "11.6.72.C.02", - "11.6.72.C.03" + "11.6.71.C.01" ] } }, @@ -9298,7 +9601,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to securely configure contactless access control systems incorporating contactless RFID or smart cards to protect the confidentiality and integrity of data and prevent the compromise of secure spaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9362,7 +9665,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -9403,7 +9707,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).\n▪ IT personnel collect technology assets and media for destruction when it is no longer needed for business or legal reasons.\n▪ Asset decommissioning consists of mainly wiping hard drives.", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications and/or Services (TAAS) are properly decommissioned so that data is properly transitioned to new systems or archived in accordance with applicable organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9489,7 +9793,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -9506,8 +9811,11 @@ "11-3.a(5)(a)", "11-3.a(5)(b)" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" + "apac-aus-ism-2026-march": [ + "ISM-2053" + ], + "apac-mys-bnm-rmit-2025": [ + "10.13" ], "apac-nzl-ism-3-9": [ "2.3.30.C.01", @@ -9524,7 +9832,9 @@ "13.1.13.C.02", "13.1.13.C.03", "13.1.13.C.04", - "13.1.14.C.01" + "13.1.14.C.01", + "20.2.15.C.03", + "20.2.15.C.06" ] } }, @@ -9548,7 +9858,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9638,7 +9948,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -9648,6 +9959,9 @@ "general-nist-800-171-r3": [ "03.01.03" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], "general-sparta": [ "CM0022" ], @@ -9684,7 +9998,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize Artificial Intelligence (AI) and Autonomous Technologies (AAT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9762,7 +10076,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -9792,7 +10107,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to categorize a system and/or service as \"High Risk\" if it poses a significant risk of harm to an individual's:\n(1) Health;\n(2) Safety; and/or \n(3) Fundamental human rights.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9841,7 +10156,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -9871,7 +10187,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are documented and maintained by process owners.\n▪ 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 AST domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers).", "3": "Asset Management (AST) 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:\n▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.\n▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution, etc.).\n▪ 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 AST 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).\n▪ An implemented and operational capability exists to dynamically associate asset-specific attributes to enable Attribute-Based Access Control (ABAC).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9926,7 +10242,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { @@ -10020,7 +10337,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Asset Management", "crosswalks": { diff --git a/docs/api/families/BCD.json b/docs/api/families/BCD.json index 3ba7b879..c493869d 100644 --- a/docs/api/families/BCD.json +++ b/docs/api/families/BCD.json @@ -108,7 +108,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -137,7 +138,7 @@ "CC9.1-POF2" ], "general-cis-csc-8-1": [ - "11.0", + "11", "11.1" ], "general-cis-csc-8-1-ig1": [ @@ -308,7 +309,7 @@ "5.30", "8.13(a)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1485", "T1486", "T1490", @@ -413,6 +414,16 @@ "CP-1", "CP-2" ], + "general-nist-800-172-r3": [ + "03.04.04E", + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.03E[04]", + "A.03.04.03E.ODP[04]", + "DS-A.03.04.04E[04]", + "DS-A.03.08.04E[01]" + ], "general-nist-csf-2-0": [ "GV.SC-08", "ID.IM-04", @@ -525,12 +536,12 @@ "PM-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(i)", - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(i)", + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "CP-1", @@ -593,18 +604,14 @@ "CP-10" ], "emea-eu-eba-ict-srm-2025": [ - "3.7(77)", - "3.7.1(78)", - "3.7.1(79)", - "3.7.2(80)", - "3.7.2(81)", - "3.7.2(82)", - "3.7.3(83)", - "3.7.3(84)(a)", - "3.7.3(84)(b)", - "3.7.3(84)(c)", - "3.7.3(85)", - "3.7.3(86)" + "3.7.77", + "3.7.1.78", + "3.7.1.79", + "3.7.2.80", + "3.7.3.83", + "3.7.3.85", + "3.7.3.86", + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 11.1", @@ -652,33 +659,42 @@ "12.1.2(c)", "13.2.2(a)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ + "1.2(e)", "10.1", "10.2", "10.3", "10.5" ], "emea-deu-c5-2020": [ + "UP-01-BP4", + "RB-06", "BCM-01", "BCM-02", - "BCM-03" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.1" + "BCM-02-BP1", + "BCM-02-BP2", + "BCM-02-BP3", + "BCM-02-BP4", + "BCM-02-BP5", + "BCM-02-BP6", + "BCM-02-BP7", + "BCM-02-BP8", + "BCM-02-BP9", + "BCM-02-BP10", + "BCM-03", + "BCM-03-BP1", + "BCM-03-BP2", + "BCM-03-BP3", + "BCM-03-BP4", + "BCM-03-BP5", + "BCM-03-BP6", + "BCM-03-BP7", + "BCM-03-BP8" ], "emea-sau-cscc-1-2019": [ - "2-8", - "3-1", - "3-1-1-1", - "3-1-1-2" + "2-8-1", + "3-1-1", + "3-1-1-1" ], "emea-sau-cgiot-2024": [ "2-8-1", @@ -686,49 +702,29 @@ "3-1-1" ], "emea-sau-ecc-1-2018": [ - "2-4-4", - "2-9-1", "2-9-2", - "2-9-3", - "2-9-3-1", - "2-9-4", "3-1-1", "3-1-2", - "3-1-3", "3-1-3-1", "3-1-3-2", - "3-1-3-3", - "3-1-4" + "3-1-3-3" ], "emea-sau-otcc-1-2022": [ - "3-1", - "3-1-1", - "3-1-1-1", - "3-1-1-2", - "3-1-1-3", - "3-1-1-4", - "3-1-1-5", - "3-1-1-6", - "3-1-2" + "2-8-1", + "2-8-2", + "3-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-67", - "TPC-68", - "TPC-69" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 26" + "VII.B.TPC-64" ], "emea-esp-decree-311-2022": [ - "26" + "Article 12(6)(n)", + "Article 22(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.5.1 [OP.CONT.1]", - "7.5.2 [OP.CONT.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.4", @@ -739,9 +735,6 @@ "emea-gbr-caf-4-0": [ "B5.a" ], - "emea-gbr-cap-1850-2020": [ - "D1" - ], "emea-gbr-def-stan-05-138-2024": [ "2501", "2502", @@ -760,22 +753,13 @@ "2501", "4100" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0734" ], "apac-aus-ps-cps-230-2023": [ - "12(b)", "14", - "34(a)", + "15", "34(b)", - "34(c)", - "34(d)", - "34(e)", - "40(a)", - "40(b)", - "40(c)", - "40(d)", - "40(e)", "41" ], "apac-chn-cybersecurity-law-2017": [ @@ -801,7 +785,13 @@ "17.1.3.1", "17.1.3.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.6", + "10.24", + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP08", "HHSP24", "HHSP56", @@ -810,9 +800,6 @@ "HML24", "HML61" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS21" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP08", "HSUP22", @@ -822,34 +809,23 @@ "6.4.5.C.01", "6.4.7.C.01", "6.4.8.C.01", + "20.1.26.C.01", "23.4.12.C.01", "23.4.12.C.02" ], "apac-sgp-mas-trm-2021": [ - "8.1.1", - "8.1.2", - "8.1.3", - "8.1.4", - "8.2.1", - "8.2.2", - "8.2.3", - "8.2.4", - "8.5.1", - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" + "8.1.1" ], "americas-bmu-mba-coc-2020": [ - "6.14", + "6.3", "7.1" ], - "amaericas-can-osfi-self-assessment": [ - "2.9" - ], "americas-can-osfi-b13-2022": [ "2.9", "2.9.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } }, @@ -875,7 +851,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan development with internal and external elements responsible for related plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan development with internal and external elements responsible for related plans. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -931,7 +907,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -1009,11 +986,16 @@ "emea-eu-nis2-annex-2024": [ "4.3.3" ], - "emea-isr-cmo-1-0": [ - "25.2" - ], "emea-sau-ecc-1-2018": [ "3-1-3-2" + ], + "emea-sau-otcc-1-2022": [ + "2-12-1-1" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ] } }, @@ -1037,7 +1019,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate internal contingency plans with the contingency plans of external service providers to ensure that contingency requirements can be satisfied.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1112,7 +1094,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -1155,11 +1138,16 @@ "emea-sau-ecc-1-2018": [ "3-1-3-2" ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" + ], "apac-ind-sebi-2024": [ "GV.SC.S6" ], - "amaericas-can-osfi-self-assessment": [ - "2.9" + "apac-sgp-mas-trm-2021": [ + "8.3.4" ] } }, @@ -1183,7 +1171,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to redeploy personnel to other roles during a disruptive event or in the execution of a continuity plan.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1253,7 +1241,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -1289,7 +1278,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to facilitate recovery operations in accordance with Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1366,7 +1355,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -1430,6 +1420,13 @@ "CP-06(02)", "CP-10" ], + "general-nist-800-172-r3": [ + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.08.04E.ODP[01]", + "A.03.08.04E.ODP[02]" + ], "general-nist-csf-2-0": [ "RC.RP", "RC.RP-02", @@ -1472,6 +1469,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "CP-10" ], + "emea-eu-eba-ict-srm-2025": [ + "3.7.2.81" + ], "emea-eu-dora-2023": [ "Article 12.6" ], @@ -1480,31 +1480,36 @@ "4.2.2(a)" ], "emea-deu-c5-2020": [ - "OPS-06", - "OPS-08", - "OPS-09" + "BCM-02-BP6", + "BCM-02-BP8", + "BCM-02-BP9" ], "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "2-9-1" + ], + "emea-sau-otcc-1-2022": [ + "3-1-1-1" ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1810" ], "apac-aus-ps-cps-230-2023": [ + "38", "38(a)", - "38(b)", - "38(c)", - "39" + "38(b)" ], "apac-ind-sebi-2024": [ "RC.RP.S2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.32" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP24", "HML24" ], @@ -1512,7 +1517,6 @@ "HSUP22" ], "apac-sgp-mas-trm-2021": [ - "8.1.4", "8.2.1" ], "americas-can-osfi-b13-2022": [ @@ -1596,7 +1600,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -1619,9 +1624,16 @@ "emea-uae-niaf-2023": [ "3.4.2" ], + "apac-aus-ps-cps-230-2023": [ + "34(d)" + ], "apac-ind-sebi-2024": [ "RC.RP.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.24", + "10.32" + ], "americas-can-osfi-b13-2022": [ "2.9.1" ] @@ -1707,7 +1719,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -1725,6 +1738,9 @@ ], "emea-eu-nis2-annex-2024": [ "4.1.2(c)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.15" ] } }, @@ -1733,7 +1749,7 @@ "title": "Business Continuity & Disaster Recovery (BC/DR) Plans", "family": "BCD", "description": "Mechanisms exist for process owners to establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions.", - "scf_question": "Does the organization process owners to establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions?", + "scf_question": "Does the organization ensure process owners establish and maintain formal Business Continuity & Disaster Recovery (BC/DR) plans to ensure information is detailed enough, accurate and representative of current operations in order to sustain and/or restore operations under adverse conditions?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -1803,9 +1819,9 @@ "MT-10", "MT-11", "MT-24", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-cr-cmm-2026": [ @@ -1831,6 +1847,42 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "CP-02-SID" ], + "emea-eu-eba-ict-srm-2025": [ + "3.7.2.82", + "3.7.3.83", + "3.7.3.84", + "3.7.3.84(a)", + "3.7.3.84(b)", + "3.7.3.84(c)" + ], + "emea-sau-otcc-1-2022": [ + "3-1-1-3", + "3-1-1-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-67", + "VII.B.TPC-68", + "VII.B.TPC-68(a)", + "VII.B.TPC-68(b)", + "VII.B.TPC-68(c)", + "VII.B.TPC-68(d)", + "VII.B.TPC-68(e)", + "VII.B.TPC-68(f)", + "VII.B.TPC-68(g)", + "VII.B.TPC-68(h)", + "VII.B.TPC-68(i)", + "VII.B.TPC-69" + ], + "apac-aus-ps-cps-230-2023": [ + "16(e)", + "34(c)", + "40", + "40(a)", + "40(b)", + "40(c)", + "40(d)", + "40(e)" + ], "apac-jpn-ismap": [ "12.2.1.10", "12.2.1.11", @@ -1841,6 +1893,16 @@ "17.1.2.4", "17.1.2.5", "17.1.2.6" + ], + "apac-sgp-mas-trm-2021": [ + "8.2.2", + "8.2.3" + ], + "americas-bmu-mba-coc-2020": [ + "7.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } }, @@ -1923,7 +1985,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -2007,6 +2070,12 @@ "general-nist-800-161-r1-level-3": [ "CP-2(8)" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.10E" + ], "general-nist-csf-2-0": [ "GV.OC-04", "GV.OC-05", @@ -2015,9 +2084,6 @@ "RC.RP-02", "RC.RP-04" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -2046,10 +2112,10 @@ "CP-02(08)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-irs-1075-2021": [ "CP-2(CE-8)" @@ -2062,31 +2128,24 @@ "500.16(a)(2)(vi)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(78)", - "3.7.3(83)" + "3.3.2.16", + "3.7.1.78" ], "emea-eu-dora-2023": [ "Article 8.4" ], - "emea-deu-bsrit-2017": [ - "12.2" - ], "emea-deu-c5-2020": [ - "BCM-02" + "RB-12", + "BCM-02-BP4" ], "emea-sau-cscc-1-2019": [ + "2-1-1-1", "2-8-1-1", "3-1-1-2" ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" - ], "emea-sau-otcc-1-2022": [ "2-1-1-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-24" - ], "emea-uae-niaf-2023": [ "3.4" ], @@ -2096,27 +2155,28 @@ "emea-gbr-cap-1850-2020": [ "A4" ], + "apac-aus-ism-2026-march": [ + "ISM-2005" + ], "apac-aus-ps-cps-230-2023": [ + "15", "34(a)", - "35", - "36(a)", - "36(b)", - "36(c)", - "36(d)", - "37" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "35" ], "apac-ind-sebi-2024": [ "ID.AM.S4" ], - "apac-sgp-mas-trm-2021": [ - "8.1.2" + "apac-mys-bnm-rmit-2025": [ + "9.2", + "10.26", + "11.3" ], "americas-can-osfi-b13-2022": [ "2.2.2", "2.9.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" ] } }, @@ -2215,7 +2275,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -2294,28 +2355,18 @@ "emea-eu-nis2-annex-2024": [ "4.1.2(h)" ], - "emea-isr-cmo-1-0": [ - "21.15", - "21.16" - ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" - ], "emea-uae-niaf-2023": [ "3.4.3" ], "apac-aus-ps-cps-230-2023": [ "34(e)" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP35", "HML35" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP31" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" ] } }, @@ -2410,7 +2461,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -2467,33 +2519,31 @@ "CP-02(05)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(C)" + "§ 164.308(a)(7)(ii)(C)" ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.16(a)(2)(iv)" ], - "emea-isr-cmo-1-0": [ - "18.15", - "25.23" - ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "emea-sau-otcc-1-2022": [ + "3-1-1-5" ], "apac-aus-ps-cps-230-2023": [ - "34(e)" + "34(e)", + "38(c)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.25", + "10.26" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP35", "HML35" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP31" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" ] } }, @@ -2515,9 +2565,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.\n▪ Business stakeholders and process owners define Recovery Time Objectives (RTOs) for business-critical TAASD.\n▪ Business stakeholders and process owners define Recovery Point Objectives (RPOs) for business-critical TAASD.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to resume essential missions and business functions within an organization-defined time period of contingency plan activation.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to resume essential missions and business functions within an organization-defined time period of contingency plan activation. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2588,7 +2638,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -2656,18 +2707,15 @@ "emea-eu-nis2-annex-2024": [ "4.1.2(h)" ], - "emea-isr-cmo-1-0": [ - "21.15", - "21.16" + "emea-deu-c5-2020": [ + "BCM-02-BP7" ], - "emea-sau-ecc-1-2018": [ - "2-9-3-2" + "emea-sau-otcc-1-2022": [ + "3-1-1-5" ], "apac-aus-ps-cps-230-2023": [ - "34(e)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.9" + "34(e)", + "38(c)" ] } }, @@ -2675,8 +2723,8 @@ "control_id": "BCD-02.4", "title": "Data Storage Location Reviews", "family": "BCD", - "description": "Mechanisms exist to perform periodic security reviews of storage locations that contain sensitive/regulated data.", - "scf_question": "Does the organization perform periodic security reviews of storage locations that contain sensitive/regulated data?", + "description": "Mechanisms exist to perform periodic security reviews of storage locations that contain sensitive and/or regulated data.", + "scf_question": "Does the organization perform periodic security reviews of storage locations that contain sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -2691,7 +2739,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners identify business-critical TAASD and External Service Providers (ESPs).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify single points of failure from a TAASD perspective.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to perform periodic security reviews of storage locations that contain sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2766,16 +2814,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF9" ], - "general-nist-800-172": [ - "3.14.5e" - ], "general-pci-dss-4-0-1": [ "9.4.1.2" ], @@ -2787,6 +2833,9 @@ ], "general-shared-assessments-sig-2025": [ "F.1" + ], + "emea-deu-c5-2020": [ + "BCM-05" ] } }, @@ -2810,9 +2859,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to adequately train contingency personnel and applicable stakeholders in their contingency roles and responsibilities.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to adequately train contingency personnel and applicable stakeholders in their contingency roles and responsibilities. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2882,7 +2931,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -2975,9 +3025,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CP-03" - ], - "emea-isr-cmo-1-0": [ - "25.3" ] } }, @@ -3001,7 +3048,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to incorporate simulated events into contingency training to facilitate effective response by personnel in crisis situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3051,7 +3098,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -3097,18 +3145,12 @@ "usa-federal-gsa-fedramp-5-high": [ "CP-03(01)" ], - "emea-isr-cmo-1-0": [ - "25.4", - "25.5" - ], "emea-sau-cscc-1-2019": [ "3-1-1-4" ], - "emea-sau-otcc-1-2022": [ - "3-1-1-6" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-sgp-mas-trm-2021": [ + "13.5.1", + "13.5.2" ] } }, @@ -3177,7 +3219,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -3192,9 +3235,6 @@ ], "general-nist-800-82-r3": [ "CP-03(02)" - ], - "emea-isr-cmo-1-0": [ - "25.8" ] } }, @@ -3221,7 +3261,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to conduct tests and/or exercises to evaluate the contingency plan's effectiveness and the organization's readiness to execute the plan.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to conduct tests and/or exercises to evaluate the contingency plan's effectiveness and the organization's readiness to execute the plan. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3291,7 +3331,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -3421,10 +3462,10 @@ "CP-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "CP-4" @@ -3456,12 +3497,12 @@ "CP-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(87)", - "3.7.4(89)", - "3.7.4(89)(a)", - "3.7.4(89)(b)", - "3.7.4(89)(c)", - "3.7.4(90)" + "3.7.4.87", + "3.7.4.89", + "3.7.4.89(a)", + "3.7.4.89(b)", + "3.7.4.89(c)", + "3.7.4.90" ], "emea-eu-dora-2023": [ "Article 11.4", @@ -3481,28 +3522,29 @@ "4.3.4" ], "emea-deu-bsrit-2017": [ - "10.4" + "10.4", + "10.5" ], "emea-deu-c5-2020": [ - "PS-02", - "PS-06", - "BCM-04" + "PS-03-BP6", + "BCM-04", + "BCM-04-DOAR", + "BCM-05-DOAR" ], - "emea-isr-cmo-1-0": [ - "25.4", - "25.6", - "25.7", - "25.9", - "25.23" + "emea-sau-cscc-1-2019": [ + "3-1-1-3", + "3-1-1-4" ], "emea-sau-otcc-1-2022": [ "3-1-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-70" + "VII.B.TPC-70" ], - "emea-esp-ccn-stic-825-2023": [ - "7.5.3 [OP.CONT.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2", + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.4.1" @@ -3517,10 +3559,9 @@ "2503" ], "apac-aus-ps-cps-230-2023": [ + "27(c)", "43", - "44", - "45", - "46" + "44" ], "apac-chn-cybersecurity-law-2017": [ "Article 34(4)" @@ -3536,18 +3577,22 @@ "17.1.3.3" ], "apac-sgp-mas-trm-2021": [ - "8.2.3", + "8.2.4", "8.3.1", "8.3.2", + "8.3.3", "8.3.3(a)", "8.3.3(b)", - "8.3.4" + "13.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "americas-bmu-mba-coc-2020": [ + "7.1-BP2" ], "americas-can-osfi-b13-2022": [ "2.9.3" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.3" ] } }, @@ -3569,9 +3614,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan testing with internal and external elements responsible for related plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to coordinate contingency plan testing with internal and external elements responsible for related plans. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3623,7 +3668,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -3671,16 +3717,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-4(1)" - ], - "emea-isr-cmo-1-0": [ - "25.6", - "25.7" - ], - "apac-sgp-mas-trm-2021": [ - "8.3.4" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" ] } }, @@ -3704,7 +3740,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ IT and/or cybersecurity personnel develop limited Disaster Recovery Plans (DRP) to recover business-critical Technology Assets, Applications and/or Services (TAAS) and services.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A dedicated alternate site(s) is/are equipped to be compatible with the production network's processing, storage, connectivity and other infrastructure needs.\n▪ Alternate sites are given priority of service to meet applicable RTOs and/or RPOs.\n▪ RTOs are used to identify business-critical TAASD, which are given priority of service in alternate processing and storage sites.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to test contingency plans at alternate storage & processing sites to both familiarize contingency personnel with the facility and evaluate the capabilities of the alternate processing site to support contingency operations.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to test contingency plans at alternate storage & processing sites to both familiarize contingency personnel with the facility and evaluate the capabilities of the alternate processing site to support contingency operations. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3775,7 +3811,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -3809,11 +3846,11 @@ "emea-eu-nis2-annex-2024": [ "4.2.2(c)" ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], "apac-sgp-mas-trm-2021": [ - "8.2.4" + "8.5.2", + "8.5.2(a)", + "8.5.2(b)", + "8.5.4" ] } }, @@ -3909,7 +3946,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -4001,10 +4039,10 @@ "CP-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(D)" + "§ 164.308(a)(7)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "CP-4" @@ -4026,8 +4064,9 @@ "CP-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(88)", - "3.7.4(90)" + "3.7.3.84(c)", + "3.7.4.88", + "3.7.4.90" ], "emea-eu-dora-2023": [ "Article 13.2", @@ -4040,11 +4079,9 @@ "emea-eu-nis2-annex-2024": [ "4.1.4" ], - "emea-deu-c5-2020": [ - "BCM-04" - ], - "emea-gbr-cap-1850-2020": [ - "D2" + "apac-aus-ps-cps-230-2023": [ + "32", + "45" ], "apac-ind-sebi-2024": [ "RC.IM.S1", @@ -4054,20 +4091,12 @@ "RS.AN.S4b", "RS.IM.S1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP64", "HML63" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP56" - ], - "apac-sgp-mas-trm-2021": [ - "7.8.1", - "7.8.2", - "7.8.3" - ], - "amaericas-can-osfi-self-assessment": [ - "5.9" ] } }, @@ -4091,7 +4120,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Production TAASD support business-critical application and services failover.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to develop BC/DR plans to recover business-critical TAASD.\n▪ Data/process owners conduct a Business Impact Analysis (BIA) at least annually, or after any major technology or process change, to identify TAASD that are critical to the business, as well as single points of failure.\n▪ Business stakeholders and process owners designate alternative decision-makers if primary decision-makers are unavailable.\n▪ Within the BC/DR plans, alternate communications channels are defined if primary means of communication are unavailable.\n▪ RTOs are used to identify business-critical TAASD, which are given priority of service in alternate processing and storage sites.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to update contingency plans due to changes affecting:\n(1) People (e.g., personnel changes);\n(2) Processes (e.g., new, altered or decommissioned business practices, including third-party services)\n(3) Technologies (e.g., new, altered or decommissioned technologies);\n(4) Data (e.g., changes to data flows and/or data repositories);\n(5) Facilities (e.g., new, altered or decommissioned physical infrastructure); and/or\n(6) Feedback from contingency plan testing activities.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4146,7 +4175,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -4270,14 +4300,14 @@ "CP-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.4(88)", - "3.7.4(90)" + "3.7.4.88", + "3.7.4.90" ], "emea-deu-c5-2020": [ "BCM-04" ], - "emea-sau-ecc-1-2018": [ - "3-1-4" + "apac-aus-ps-cps-230-2023": [ + "45" ] } }, @@ -4286,7 +4316,7 @@ "title": "Contingency Planning Components", "family": "BCD", "description": "Mechanisms exist to identify components that potentially impact the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure.", - "scf_question": "Does the organization identify components that potentially impacts the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure?", + "scf_question": "Does the organization identify components that potentially impact its ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -4301,7 +4331,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify components that potentially impacts the organization's ability to execute contingency plans, including changes to:\n(1) Personnel roles;\n(2) Business processes (including the use of third-party services);\n(3) Deployed technologies; \n(4) Data repositories and/or data flows; and/or\n(5) Physical infrastructure.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4353,7 +4383,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -4366,6 +4397,9 @@ ], "usa-federal-nerc-cip-2024": [ "CIP-009-6 3.2" + ], + "apac-aus-ps-cps-230-2023": [ + "45" ] } }, @@ -4389,7 +4423,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to keep stakeholders informed of changes to contingency plans.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to keep stakeholders informed of changes to contingency plans.\n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4437,7 +4471,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -4467,9 +4502,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to implement alternative or compensating controls to satisfy security functions when the primary means of implementing the security function is unavailable or compromised. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4525,7 +4560,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -4567,9 +4603,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate storage site that includes both the assets and necessary agreements to permit the storage and recovery of system backup information.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate storage site that includes both the assets and necessary agreements to permit the storage and recovery of system backup information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4631,7 +4667,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -4660,7 +4697,7 @@ "general-iso-27018-2025": [ "8.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -4742,22 +4779,8 @@ "emea-deu-bsrit-2017": [ "10.5" ], - "emea-deu-c5-2020": [ - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.7", - "25.10" - ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.4.4 [MP.COM.4]", - "8.8.4 [MP.S.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" ] } }, @@ -4779,7 +4802,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to separate the alternate storage site from the primary storage site to reduce susceptibility to similar threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4821,9 +4844,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -4876,12 +4899,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-6(1)" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.11" ] } }, @@ -4890,7 +4907,7 @@ "title": "Primary Storage Site Accessibility", "family": "BCD", "description": "Mechanisms exist to identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster.", - "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster?", + "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -4903,7 +4920,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify and mitigate potential accessibility problems to the alternate storage sites in the event of an area-wide disruption or disaster.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4965,9 +4982,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -5011,9 +5028,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-6(3)" - ], - "emea-isr-cmo-1-0": [ - "25.13" ] } }, @@ -5035,7 +5049,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to establish an alternate processing site that provides security measures equivalent to that of the primary site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5099,7 +5113,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -5134,7 +5149,7 @@ "general-iso-27018-2025": [ "8.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -5232,21 +5247,8 @@ "emea-deu-bsrit-2017": [ "10.5" ], - "emea-deu-c5-2020": [ - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "11.7", - "25.7", - "25.10" - ], - "emea-sau-cscc-1-2019": [ - "3-1-1-1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.8 [MP.IF.8]", - "8.3.4 [MP.EQ.4]", - "8.8.4 [MP.S.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" ], "apac-jpn-ismap": [ "17.2", @@ -5275,7 +5277,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to separate the alternate processing site from the primary processing site to reduce susceptibility to similar threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5317,9 +5319,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -5366,12 +5368,6 @@ ], "emea-eu-dora-2023": [ "Article 12.5(a)" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.11" ] } }, @@ -5380,7 +5376,7 @@ "title": "Alternate Processing Site Accessibility", "family": "BCD", "description": "Mechanisms exist to identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster.", - "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate processing site and possible mitigation actions, in the event of an area-wide disruption or disaster?", + "scf_question": "Does the organization identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5393,7 +5389,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to identify and mitigate potential accessibility problems to the alternate processing sites and possible mitigation actions, in the event of an area-wide disruption or disaster.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5453,9 +5449,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -5501,19 +5497,16 @@ "CP-07(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "CP-7(2)" ], "emea-eu-dora-2023": [ "Article 12.5(c)" - ], - "emea-isr-cmo-1-0": [ - "25.13" ] } }, @@ -5537,9 +5530,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to address priority-of-service provisions in alternate processing and storage sites that support availability requirements, including Recovery Time Objectives (RTOs).", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to address priority-of-service provisions in alternate processing and storage sites that support availability requirements, including Recovery Time Objectives (RTOs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5593,7 +5586,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -5638,10 +5632,6 @@ ], "usa-federal-cms-marse-2-0": [ "CP-7(3)" - ], - "emea-isr-cmo-1-0": [ - "25.12", - "21.14" ] } }, @@ -5719,7 +5709,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -5754,7 +5745,7 @@ "title": "Inability to Return to Primary Site", "family": "BCD", "description": "Mechanisms exist to plan and prepare for both natural and manmade circumstances that preclude returning to the primary site.", - "scf_question": "Does the organization plan and prepare for both natural and manmade circumstances that preclude returning to the primary processing site?", + "scf_question": "Does the organization plan and prepare for both natural and manmade circumstances that preclude returning to the primary site?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5767,7 +5758,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to plan and prepare for both natural and manmade circumstances that preclude returning to the primary site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5825,9 +5816,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { "general-nist-800-53-r4": [ @@ -5859,7 +5850,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to reduce the likelihood of a single point of failure with primary telecommunications services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5915,7 +5906,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -6007,13 +5999,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CP-08" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" - ], - "emea-isr-cmo-1-0": [ - "21.14", - "25.16" ] } }, @@ -6037,9 +6022,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to formalize primary and alternate telecommunications service agreements contain priority-of-service provisions that support availability requirements, including Recovery Time Objectives (RTOs).", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to formalize primary and alternate telecommunications service agreements contain priority-of-service provisions that support availability requirements, including Recovery Time Objectives (RTOs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6076,7 +6061,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -6126,10 +6112,6 @@ "CP-8(1)", "CP-8(1).a", "CP-8(1).b" - ], - "emea-isr-cmo-1-0": [ - "21.14", - "25.17" ] } }, @@ -6151,9 +6133,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6207,7 +6189,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -6267,7 +6250,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to contractually-require external service providers to have contingency plans that meet organizational contingency requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6325,7 +6308,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -6366,7 +6350,7 @@ "CP-08(04)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.3(86)" + "3.7.3.86" ] } }, @@ -6440,7 +6424,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -6478,10 +6463,13 @@ "CM0070" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-nis2-annex-2024": [ "4.3.2(b)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.15" ] } }, @@ -6573,7 +6561,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -6643,7 +6632,7 @@ "general-iso-27018-2025": [ "8.13" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1005", @@ -6716,6 +6705,9 @@ "general-nist-800-171a": [ "3.8.9" ], + "general-nist-800-171a-r3": [ + "A.03.08.09.a" + ], "general-nist-csf-2-0": [ "PR.DS-11" ], @@ -6803,13 +6795,16 @@ "CP-09", "SC-28(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(g)(4)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(A)", - "164.310(d)(2)(iv)" + "§ 164.308(a)(7)(ii)(A)", + "§ 164.310(d)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "CP-9" @@ -6844,7 +6839,7 @@ "CP-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(57)" + "3.5.57" ], "emea-eu-dora-2023": [ "Article 12.1", @@ -6866,12 +6861,14 @@ "8.7" ], "emea-deu-c5-2020": [ - "OPS-06" + "RB-06", + "RB-07" ], - "emea-isr-cmo-1-0": [ - "25.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 14.1" ], "emea-sau-cscc-1-2019": [ + "2-8-1-1", "2-8-1-2", "2-8-1-3" ], @@ -6880,28 +6877,22 @@ "2-8-2" ], "emea-sau-ecc-1-2018": [ - "2-9-3" + "2-4-3-3", + "2-9-3-1", + "2-9-3-2" ], "emea-sau-otcc-1-2022": [ - "2-8", - "2-8-1", "2-8-1-1", - "2-8-1-2", - "2-8-1-3", - "2-8-1-4", - "2-8-2" + "2-8-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-64" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 26" + "VII.B.TPC-64" ], "emea-esp-decree-311-2022": [ - "26" + "Article 26" ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.7 [MP.INFO.7]" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-caf-4-0": [ "B5.c" @@ -6924,9 +6915,7 @@ "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", + "apac-aus-ism-2026-march": [ "ISM-1511", "ISM-1547", "ISM-1548", @@ -6959,7 +6948,10 @@ "12.3.1.21.P", "12.3.1.24.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP17", "HHSP56", "HHSP69", @@ -6967,9 +6959,6 @@ "HML56", "HML68" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP15", "HSUP48", @@ -6982,12 +6971,19 @@ "8.4.1", "8.4.2" ], + "americas-arg-ppd-2018": [ + "D", + "D.1.1-1" + ], "americas-bmu-mba-coc-2020": [ "6.14" ], "americas-can-osfi-b13-2022": [ "2.9.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.9.1" + ], "americas-can-itsp-10-171-2025": [ "03.08.09.A" ] @@ -7015,7 +7011,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ A random sampling of backups is tested at least annually to verify integrity and recoverability of backed up data.", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel perform a random sampling of backups is tested at least semi-annually to verify integrity and recoverability of backed up data.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to routinely test backups that verify the reliability of the backup process, as well as the integrity and availability of the data.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to routinely test backups that verify the reliability of the backup process, as well as the integrity and availability of the data. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7060,7 +7056,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -7138,6 +7135,13 @@ "general-nist-800-160-vol-2-r1": [ "CP-09(01)" ], + "general-nist-800-172-r3": [ + "03.08.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.03E[01]", + "DS-A.03.08.03E[02]" + ], "general-nist-csf-2-0": [ "PR.DS-11" ], @@ -7178,13 +7182,7 @@ "4.2.2(b)" ], "emea-deu-c5-2020": [ - "OPS-06", - "OPS-07", - "OPS-08" - ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.19" + "RB-07" ], "emea-sau-cscc-1-2019": [ "2-8-2" @@ -7195,6 +7193,9 @@ "emea-sau-ecc-1-2018": [ "2-9-3-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" + ], "emea-gbr-def-stan-05-138-2024": [ "2504", "2505" @@ -7208,27 +7209,29 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2505" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1515" ], "apac-ind-sebi-2024": [ "PR.IP.S8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP57", "HHSP69", "HML57", "HML68" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP49", "HSUP60" ], - "apac-sgp-mas-trm-2021": [ - "8.4.3" + "americas-arg-ppd-2018": [ + "D.1.1-2", + "D.1.1-3", + "D.1.2-4" ] } }, @@ -7315,7 +7318,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -7408,23 +7412,22 @@ "CP-09(3)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(58)" + "3.5.58" ], "emea-eu-dora-2023": [ "Article 12.3" ], "emea-deu-c5-2020": [ - "OPS-06", - "PSS-12" - ], - "emea-isr-cmo-1-0": [ - "25.20" + "RB-09" ], "emea-sau-otcc-1-2022": [ - "2-8-1-4" + "2-8-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-38" + "VII.B.TPC-65" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-def-stan-05-138-2024": [ "2505" @@ -7440,7 +7443,7 @@ "ML2-P8", "ML3-P8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1811" ], "apac-jpn-ismap": [ @@ -7448,6 +7451,15 @@ "12.3.1.6", "12.3.1.7", "12.3.1.23.P" + ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-sgp-mas-trm-2021": [ + "8.4.4" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-2" ] } }, @@ -7515,7 +7527,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -7525,12 +7538,8 @@ "general-cr-cmm-2026": [ "CR10.2.6" ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "25.12", - "25.22" + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } }, @@ -7606,7 +7615,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -7728,8 +7738,8 @@ "CP-09 (08)", "SC-28 (01)" ], - "emea-isr-cmo-1-0": [ - "25.18" + "emea-deu-c5-2020": [ + "RB-06-DOAR" ], "emea-sau-cscc-1-2019": [ "2-8-1-3" @@ -7738,7 +7748,11 @@ "2-8-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-65" + "VII.B.TPC-50", + "VII.B.TPC-65" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.6" ], "emea-gbr-def-stan-05-138-2024": [ "2506" @@ -7749,12 +7763,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2506" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS11" + "apac-mys-bnm-rmit-2025": [ + "10.45" ], "apac-sgp-mas-trm-2021": [ "8.4.4" ], + "americas-arg-ppd-2018": [ + "D.1.2-2" + ], "americas-can-itsp-10-171-2025": [ "03.08.09.A", "03.08.09.B" @@ -7781,9 +7798,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel perform a random sampling of backups is tested at least semi-annually to verify integrity and recoverability of backed up data.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize sampling of available backups to test recovery capabilities as part of business continuity plan testing.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize sampling of available backups to test recovery capabilities as part of business continuity plan testing. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7834,7 +7851,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -7897,8 +7915,8 @@ "Article 12.2", "Article 12.7" ], - "emea-sau-cscc-1-2019": [ - "3-1-1-3" + "emea-deu-c5-2020": [ + "RB-08" ], "emea-sau-cgiot-2024": [ "2-8-3" @@ -7923,6 +7941,12 @@ "12.3.1.10", "12.3.1.20.P", "12.3.1.22.P" + ], + "apac-sgp-mas-trm-2021": [ + "8.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "6.14" ] } }, @@ -7946,7 +7970,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to transfer backup data to the alternate storage site at a rate that is capable of meeting both Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8008,7 +8032,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -8049,7 +8074,7 @@ "Article 12.3" ], "emea-sau-otcc-1-2022": [ - "2-8-1-4" + "2-8-1-1" ], "emea-gbr-def-stan-05-138-2024": [ "2506" @@ -8080,7 +8105,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to maintain a failover capability, which is not collocated with the primary Technology Asset, Application and/or Service (TAAS), which can be activated with little-to-no loss of information or disruption to operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8140,7 +8165,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -8180,11 +8206,19 @@ "4.2.4(d)", "13.1.2(b)" ], - "emea-deu-c5-2020": [ - "PS-02" - ], "emea-sau-otcc-1-2022": [ "3-1-1-2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.4" + ], + "apac-mys-bnm-rmit-2025": [ + "10.25", + "10.26" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.2", + "8.5.2(c)" ] } }, @@ -8206,7 +8240,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to enforce dual authorization for the deletion or destruction of sensitive backup media and data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8261,7 +8295,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -8279,6 +8314,12 @@ ], "general-nist-800-160-vol-2-r1": [ "CP-09(07)" + ], + "general-nist-800-172-r3": [ + "03.08.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.02E" ] } }, @@ -8300,7 +8341,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restrict access to backups to privileged users with assigned roles for data backup and recovery operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8352,7 +8393,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -8365,13 +8407,21 @@ "emea-eu-nis2-annex-2024": [ "4.2.2(d)" ], - "emea-sau-sacs-002-2022": [ - "TPC-50" + "emea-sau-cscc-1-2019": [ + "2-8-1-3" ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" + ], + "apac-aus-ism-2026-march": [ + "ISM-1812", + "ISM-1813", + "ISM-1814" + ], + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } }, @@ -8445,16 +8495,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { + "emea-sau-cscc-1-2019": [ + "2-8-1-3" + ], "apac-aus-essential-8-2024": [ "ML1-P8", "ML2-P8", "ML3-P8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-aus-ism-2026-march": [ + "ISM-1814" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP56", "HML56" ], @@ -8483,7 +8540,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to ensure the secure recovery and reconstitution of Technology Assets, Applications and/or Services (TAAS) to a known state after a disruption, compromise or failure.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8559,7 +8616,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -8618,7 +8676,7 @@ "general-iec-62443-4-2-2019": [ "CR 7.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1485", "T1485.001", "T1486", @@ -8659,6 +8717,12 @@ "general-nist-800-82-r3-high": [ "CP-10" ], + "general-nist-800-172-r3": [ + "03.08.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.04E[02]" + ], "general-nist-csf-2-0": [ "RC", "RC.RP-01", @@ -8680,10 +8744,10 @@ "CP-10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(B)" + "§ 164.308(a)(7)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "CP-10" @@ -8706,29 +8770,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "CP-10" ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.3(83)" - ], "emea-eu-nis2-2022": [ "Article 21.2(c)" ], "emea-eu-nis2-annex-2024": [ "4.2.2(e)" ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.12", - "25.22" - ], "emea-sau-cscc-1-2019": [ "2-8-2" ], "emea-sau-cgiot-2024": [ "2-12-2" ], - "emea-sau-ecc-1-2018": [ - "2-4-3-3" - ], "emea-gbr-def-stan-05-138-2024": [ "4202" ], @@ -8738,12 +8791,19 @@ "apac-ind-sebi-2024": [ "PR.IP.S7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.45" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP17", "HML17" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP15" + ], + "americas-arg-ppd-2018": [ + "D.1.2-3", + "D.1.2-DS-4" ] } }, @@ -8837,7 +8897,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -8886,12 +8947,8 @@ "usa-federal-irs-1075-2021": [ "CP-10(CE-2)" ], - "emea-isr-cmo-1-0": [ - "25.9", - "25.21" - ], - "emea-sau-ecc-1-2018": [ - "2-4-3-3" + "usa-federal-cms-marse-2-0": [ + "CP-10(2)" ] } }, @@ -8985,7 +9042,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -9037,13 +9095,6 @@ "emea-eu-dora-2023": [ "Article 12.4" ], - "emea-isr-cmo-1-0": [ - "12.26", - "25.12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], "emea-gbr-def-stan-05-138-2024": [ "4202" ], @@ -9070,7 +9121,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize electronic discovery (eDiscovery) that covers current and archived communication transactions.", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9116,7 +9167,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -9150,7 +9202,7 @@ "0": "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.", "1": "Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs, redundant power, etc.).\n▪ Backups are performed ad-hoc and focus on business-critical Technology Assets, Applications, Services and/or Data (TAASD).\n▪ IT and/or cybersecurity personnel use a backup methodology (e.g., grandfather, father & son rotation) to create backups to support business needs (e.g., Recovery Time Objectives).", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restore TAASD within organization-defined restoration time-periods from configuration-controlled and integrity-protected information; representing a known, operational state for the asset.", + "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to restore TAASD within organization-defined restoration time-periods from configuration-controlled and integrity-protected information; representing a known, operational state for the asset. ", "4": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9210,7 +9262,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -9342,7 +9395,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -9386,9 +9440,8 @@ "4.2.2(e)", "4.2.3" ], - "emea-isr-cmo-1-0": [ - "25.12", - "25.18" + "americas-arg-ppd-2018": [ + "D.1.2-DS-4" ] } }, @@ -9413,7 +9466,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to verify the integrity of backups and other restoration assets prior to using them for restoration.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9465,7 +9518,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -9498,7 +9552,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.\n▪ 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to utilize an isolated, non-production environment to perform data backup and recovery operations through offline, cloud or off-site capabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9550,7 +9604,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -9571,6 +9626,12 @@ ], "general-shared-assessments-sig-2025": [ "K.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.45" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-4" ] } }, @@ -9592,7 +9653,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Business Continuity & Disaster Recovery (BCD) 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:\n▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 BCD 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).\n▪ An implemented and operational capability exists to purchase and maintain a sufficient reserve of spare hardware to ensure essential missions and business functions can be maintained in the event of a supply chain disruption.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9674,7 +9735,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { @@ -9682,7 +9744,7 @@ "RESPONSE-4c", "RESPONSE-4l" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1789" ] } @@ -9793,7 +9855,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Business Continuity & Disaster Recovery", "crosswalks": { diff --git a/docs/api/families/CAP.json b/docs/api/families/CAP.json index bea0bc2a..6982750c 100644 --- a/docs/api/families/CAP.json +++ b/docs/api/families/CAP.json @@ -27,7 +27,7 @@ "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to facilitate the implementation of capacity management controls to ensure optimal system performance to meet expected and anticipated future capacity requirements.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -83,7 +83,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -168,6 +169,12 @@ "general-nist-800-160-vol-2-r1": [ "SC-05(03)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -198,6 +205,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(1)" + ], "usa-federal-cms-marse-2-0": [ "SC-5" ], @@ -214,34 +224,23 @@ "SC-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(56)" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "3.5.56" ], "emea-deu-bsrit-2017": [ "8.8" ], "emea-deu-c5-2020": [ - "OPS-01", - "OPS-02", - "OPS-03" - ], - "emea-isr-cmo-1-0": [ - "25.2" + "RB-01" ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" + "emea-sau-otcc-1-2022": [ + "3-1-1", + "3-1-2" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.4 [OP.PL.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.4", + "mp.s.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" @@ -260,7 +259,10 @@ "12.1.3.7", "12.1.3.8" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP61", "HML61" ], @@ -268,14 +270,17 @@ "HSUP53" ], "apac-sgp-mas-trm-2021": [ - "8.1.1" + "6.4.8" ], "americas-bmu-mba-coc-2020": [ - "6.1" + "6.1-BP5" ], "americas-can-osfi-b13-2022": [ "2", "2.8.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.8.2" ] } }, @@ -303,7 +308,7 @@ "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to control resource utilization of Technology Assets, Applications and/or Services (TAAS) that are susceptible to Denial of Service (DoS) attacks to limit and prioritize the use of resources.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -349,7 +354,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -378,7 +384,7 @@ "SC-05", "SC-06" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1564.009" ], "general-nist-800-53-r4": [ @@ -425,6 +431,12 @@ "general-nist-800-161-r1-level-2": [ "SC-5(2)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -463,10 +475,22 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-05" ], - "apac-aus-ism-2024-june": [ + "emea-isr-cmo-2-0": [ + "Appendix A, 7.1" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-92" + ], + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" + ], + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-sgp-mas-trm-2021": [ + "6.4.8" ] } }, @@ -490,11 +514,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", - "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support will exist during contingency operations.", + "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to conduct capacity planning so that necessary capacity for information processing, telecommunications and environmental support will exist during contingency operations. ", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -542,7 +566,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -632,6 +657,12 @@ "general-nist-800-161-r1-level-3": [ "CP-2(2)" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.b" + ], "general-nist-csf-2-0": [ "PR.IR-04" ], @@ -678,20 +709,20 @@ "8.8" ], "emea-deu-c5-2020": [ - "OPS-01", - "OPS-02", - "OPS-03" + "RB-01", + "RB-01-DOAR" ], - "emea-isr-cmo-1-0": [ - "25.2" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.4", + "mp.s.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1579", "ISM-1580", "ISM-1581" ], - "apac-sgp-mas-trm-2021": [ - "8.1.3" + "apac-mys-bnm-rmit-2025": [ + "10.29" ], "americas-can-osfi-b13-2022": [ "2.8.2" @@ -718,11 +749,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are documented and maintained by process owners.\n▪ 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 CAP domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Capability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Capability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel work with business stakeholders and process owners to create and maintain infrastructure performance metrics to understand current resource needs.", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to automatically centrally-monitor and alert on the operating state and health status of critical Technology Assets, Applications and/or Services (TAAS).", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -784,7 +815,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -800,14 +832,24 @@ "emea-deu-bsrit-2017": [ "8.8" ], + "emea-deu-c5-2020": [ + "RB-02" + ], "apac-ind-sebi-2024": [ "DE.CM.S4" ], - "amaericas-can-osfi-self-assessment": [ - "3.1" + "apac-mys-bnm-rmit-2025": [ + "10.30", + "10.39" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.3" ], "americas-can-osfi-b13-2022": [ "2.8.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.8.2" ] } }, @@ -831,11 +873,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to automatically scale the resources available for Technology Assets, Applications and/or Services (TAAS), as demand conditions change.", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -892,7 +934,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { @@ -905,8 +948,17 @@ "usa-federal-dow-zt-roadmap-1-1": [ "7.1.1" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "RB-02" + ], + "apac-aus-ism-2026-march": [ "ISM-1579" + ], + "apac-mys-bnm-rmit-2025": [ + "10.29" + ], + "apac-sgp-mas-trm-2021": [ + "8.1.4" ] } }, @@ -932,7 +984,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Capability & Performance Planning (CAP) 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:\n▪ Policies and standards associated with CAP domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CAP domain capabilities are well-documented and kept current by process owners.\n▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools, etc.).\n▪ 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 CAP 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).\n▪ An implemented and operational capability exists to support operations that are geographically dispersed via regional delivery of technological Technology Assets, Applications and/or Services (TAAS).", "4": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Capability & Performance Planning (CAP) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.\n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -987,7 +1039,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Capacity & Performance Planning", "crosswalks": { diff --git a/docs/api/families/CFG.json b/docs/api/families/CFG.json index 1d3cc988..ecc0a488 100644 --- a/docs/api/families/CFG.json +++ b/docs/api/families/CFG.json @@ -1,7 +1,7 @@ { "family_code": "CFG", "family_name": "Configuration Management", - "control_count": 28, + "control_count": 32, "controls": [ { "control_id": "CFG-01", @@ -28,7 +28,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to facilitate the implementation of configuration management controls.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -107,7 +107,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -121,8 +122,8 @@ "CC8.1-POF12" ], "general-cis-csc-8-1": [ - "2.0", - "4.0", + "2", + "4", "4.1", "4.2" ], @@ -252,9 +253,11 @@ "NFO - CM-9" ], "general-nist-800-171-r3": [ - "03.04.01.a" + "03.04.01.a", + "03.04.03.a" ], "general-nist-800-171a-r3": [ + "A.03.04.01.a[02]", "A.03.04.03.a" ], "general-nist-800-207": [ @@ -273,9 +276,6 @@ "2.2", "8.5" ], - "general-scf-dpmp-2025": [ - "7.12" - ], "general-sparta": [ "CM0023" ], @@ -315,10 +315,10 @@ "CM-09" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "CM-1", @@ -366,56 +366,19 @@ "6.3.1", "6.3.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "6.8" - ], - "emea-deu-c5-2020": [ - "AM-03" - ], - "emea-isr-cmo-1-0": [ - "3.3", - "9.22", - "9.23", - "14.1" - ], "emea-sau-cscc-1-2019": [ "2-3-1-6" ], - "emea-sau-ecc-1-2018": [ - "1-6-2-2", - "2-4-4", - "2-5-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 30.1", - "Article 30.2" - ], - "emea-esp-decree-311-2022": [ - "30.1", - "30.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.3 [OP.EXP.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-caf-4-0": [ "B4", "B4.c" ], - "emea-gbr-cap-1850-2020": [ - "B4" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "apac-aus-ism-2026-march": [ + "ISM-0912" ], "apac-ind-sebi-2024": [ "PR.IP.S3" @@ -426,29 +389,28 @@ "12.2.5.C.02", "12.2.6.C.01", "12.2.6.C.02", + "17.9.38.C.03", "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", - "18.1.10.C.04" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)" + "18.1.10.C.04", + "20.2.14.C.02" ], "apac-sgp-mas-trm-2021": [ - "7.2.1", - "7.2.2", - "7.3.1", - "7.3.2", - "7.3.3" + "7.2.1" ], "americas-bmu-mba-coc-2020": [ - "6.1" + "6.1-BP1" ], "americas-can-osfi-b13-2022": [ "3.2.8" ], "americas-can-itsp-10-171-2025": [ - "03.04.01.A" + "03.04.01.A", + "03.04.03.A" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(c)" ] } }, @@ -538,7 +500,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -569,6 +532,10 @@ "general-pci-dss-4-0-1": [ "2.1" ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" + ], "apac-nzl-ism-3-9": [ "4.3.19.C.01" ] @@ -605,9 +572,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -680,7 +647,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -702,6 +670,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -726,6 +695,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -740,6 +710,7 @@ "4.6", "4.7", "4.8", + "4.10", "10.3", "10.4", "10.5", @@ -838,7 +809,7 @@ "8.25", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -1321,6 +1292,7 @@ ], "general-nist-800-171-r3": [ "03.01.01.h", + "03.01.03", "03.01.08.a", "03.01.08.b", "03.01.09", @@ -1330,16 +1302,22 @@ "03.01.11", "03.01.12.a", "03.01.16.a", + "03.01.16.c", "03.01.18.a", + "03.03.08.a", "03.04.01.a", "03.04.02.a", + "03.04.02.b", "03.04.06.a", "03.04.06.b", "03.04.06.d", + "03.05.04", + "03.05.07.c", "03.05.07.d", "03.05.07.e", "03.05.07.f", "03.05.12.d", + "03.07.05.b", "03.08.07.a", "03.13.12.b" ], @@ -1351,7 +1329,17 @@ "3.4.2[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.08.a", + "A.03.01.08.b", + "A.03.01.09", + "A.03.01.10.a", + "A.03.01.10.b", + "A.03.01.10.c", + "A.03.01.11", + "A.03.01.12.a[03]", "A.03.01.16.a[03]", "A.03.01.16.c", "A.03.01.18.a[02]", @@ -1365,18 +1353,48 @@ "A.03.04.06.ODP[03]", "A.03.04.06.ODP[04]", "A.03.04.06.ODP[05]", + "A.03.04.06.a", "A.03.04.06.b[01]", "A.03.04.06.b[02]", "A.03.04.06.b[03]", "A.03.04.06.b[04]", "A.03.04.06.b[05]", + "A.03.04.06.d", "A.03.05.04[01]", "A.03.05.04[02]", "A.03.05.07.c", "A.03.05.07.d", "A.03.05.07.e", "A.03.05.07.f", - "A.03.07.05.b[02]" + "A.03.05.12.d", + "A.03.07.05.b[01]", + "A.03.08.07.a", + "A.03.13.12.b" + ], + "general-nist-800-172-r3": [ + "03.01.04E", + "03.01.14E", + "03.01.16E", + "03.05.01E", + "03.05.05E", + "03.12.04E", + "03.13.06E", + "03.13.11E", + "03.13.13E", + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.04E.ODP[01]", + "A.03.01.14E.ODP[03]", + "A.03.01.14E.ODP[04]", + "DS-A.03.01.16E", + "A.03.05.01E.ODP[01]", + "DS-A.03.05.05E", + "DS-A.03.12.04E.c", + "A.03.13.06E.ODP[01]", + "DS-A.03.13.11E[02]", + "A.03.13.13E.ODP[01]", + "A.03.14.11E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -1491,9 +1509,6 @@ "10.6.2", "10.6.3" ], - "general-scf-dpmp-2025": [ - "7.12" - ], "general-shared-assessments-sig-2025": [ "N.11" ], @@ -1596,20 +1611,24 @@ "SA-08", "SA-15(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(2)", + "101.650(c)(2)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iii)", - "164.312(e)(1)", - "164.312(e)(2)(i)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iii)", + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "3.3.8.b", @@ -1745,7 +1764,7 @@ "Article 17.1(e)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(b)" + "3.4.4.36(b)" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -1766,28 +1785,37 @@ "6.8" ], "emea-deu-c5-2020": [ - "AM-02", - "AM-03", - "OPS-23" - ], - "emea-isr-cmo-1-0": [ - "3.3", - "4.9", - "4.12", - "4.15", - "6.1", - "9.21", - "12.13", - "12.24", - "12.29", - "13.5", - "13.6", - "14.2", - "15.6" + "RB-05", + "RB-22", + "RB-22-DOAR", + "IDM-11", + "IDM-11-BP1", + "IDM-11-BP2", + "IDM-11-BP3", + "IDM-11-BP4", + "IDM-11-BP5", + "IDM-11-DOAR", + "IDM-11-DOAR-BP1", + "IDM-11-DOAR-BP2", + "IDM-11-DOAR-BP3", + "IDM-11-DOAR-BP4", + "IDM-11-DOAR-BP5", + "IDM-11-DOAR-BP6", + "IDM-11-DOAR-BP7" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 3.1", + "Appendix A, 4.1", + "Appendix A, 4.2" ], "emea-sau-cscc-1-2019": [ "1-3-2-3", - "2-3-1-7" + "2-2-1-5", + "2-2-1-6", + "2-3-1-6", + "2-3-1-7", + "2-4-1-3", + "2-12-1" ], "emea-sau-cgiot-2024": [ "1-2-2", @@ -1798,36 +1826,47 @@ ], "emea-sau-ecc-1-2018": [ "1-3-3", - "2-4-1", - "2-4-2", - "5-1-3-7" + "2-4-1" ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-1", - "2-3-1-7" + "2-2-1-8", + "2-4-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 20(d)" + "VII.A.TPC-2", + "VII.A.TPC-2-BP1", + "VII.A.TPC-2-BP2", + "VII.A.TPC-2-BP3", + "VII.A.TPC-2-BP4", + "VII.A.TPC-2-BP5", + "VII.A.TPC-10", + "VII.B.TPC-56", + "VII.B.TPC-62", + "VII.B.TPC-63", + "VII.B.TPC-63-BP1", + "VII.B.TPC-63-BP2", + "VII.B.TPC-63-BP3", + "VII.B.TPC-63-BP4" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.6", + "3.3.6.1", + "3.3.13.4.c.2" ], "emea-esp-decree-311-2022": [ - "20(d)" + "Article 12(7)", + "Article 20(a)", + "Article 20(c)", + "Article 20(d)", + "Single Transitional Provision(3)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.2 [OP.EXP.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "op.exp.2", + "op.exp.3", + "mp.sw.1", + "mp.info.4", + "mp.s.2" ], "emea-uae-niaf-2023": [ "3.2.1" @@ -1836,11 +1875,9 @@ "B4", "B4.b" ], - "emea-gbr-cap-1850-2020": [ - "B4" - ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "2-BP3", + "2-BP4" ], "emea-gbr-def-stan-05-138-2024": [ "2204", @@ -1881,7 +1918,7 @@ "ML3-P6", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0341", "ISM-0343", "ISM-0345", @@ -1910,7 +1947,79 @@ "ISM-1654", "ISM-1655", "ISM-1710", - "ISM-1745" + "ISM-1745", + "ISM-1823", + "ISM-1824", + "ISM-1825", + "ISM-1828", + "ISM-1829", + "ISM-1830", + "ISM-1836", + "ISM-1838", + "ISM-1839", + "ISM-1840", + "ISM-1841", + "ISM-1844", + "ISM-1846", + "ISM-1858", + "ISM-1859", + "ISM-1860", + "ISM-1861", + "ISM-1870", + "ISM-1871", + "ISM-1886", + "ISM-1887", + "ISM-1888", + "ISM-1890", + "ISM-1891", + "ISM-1896", + "ISM-1897", + "ISM-1913", + "ISM-1914", + "ISM-1915", + "ISM-1916", + "ISM-1928", + "ISM-1929", + "ISM-1930", + "ISM-1931", + "ISM-1932", + "ISM-1933", + "ISM-1934", + "ISM-1935", + "ISM-1936", + "ISM-1938", + "ISM-1943", + "ISM-1944", + "ISM-1945", + "ISM-1946", + "ISM-1947", + "ISM-1948", + "ISM-1949", + "ISM-1950", + "ISM-1951", + "ISM-1952", + "ISM-1953", + "ISM-1954", + "ISM-1955", + "ISM-1956", + "ISM-1957", + "ISM-1958", + "ISM-1962", + "ISM-1980", + "ISM-1984", + "ISM-2010", + "ISM-2012", + "ISM-2047", + "ISM-2049", + "ISM-2079", + "ISM-2080", + "ISM-2081", + "ISM-2096", + "ISM-2097", + "ISM-2098" + ], + "apac-aus-cop-sitc-2020": [ + "6" ], "apac-ind-sebi-2024": [ "PR.IP.S1" @@ -1918,7 +2027,7 @@ "apac-jpn-ismap": [ "8.3.1.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP54", "HHSP60", "HHSP65", @@ -1927,40 +2036,84 @@ "HML60", "HML64" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP14", "HSUP46", "HSUP52" ], "apac-nzl-ism-3-9": [ + "11.1.16.C.01", + "11.1.16.C.02", + "11.1.17.C.01", + "11.1.17.C.03", + "11.8.6.C.01", + "11.8.6.C.02", "14.1.8.C.01", "14.1.9.C.01", "14.1.9.C.02", "14.1.10.C.01", "14.1.10.C.02", "14.3.7.C.01", + "15.2.41.C.01", + "15.2.41.C.02", + "15.2.42.C.01", + "15.2.43.C.01", + "15.2.44.C.01", + "15.2.46.C.01", + "15.2.46.C.03", + "15.2.47.C.01", + "15.2.47.C.02", + "15.2.48.C.01", + "15.2.48.C.02", + "15.2.48.C.03", + "15.2.49.C.01", + "15.2.49.C.02", + "15.2.49.C.03", + "15.2.50.C.01", + "15.2.50.C.02", + "15.2.50.C.03", + "15.2.50.C.04", + "16.1.31.C.03", + "16.1.31.C.04", + "16.1.31.C.05", + "16.7.42.C.01", + "20.2.14.C.05", + "20.2.14.C.07", + "22.1.16.C.01", + "22.1.16.C.02", + "22.1.17.C.01", + "22.1.17.C.02", + "22.1.17.C.03", + "22.1.19.C.01", + "22.1.19.C.02", "23.2.21.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)" + "4.3(a)", + "4.3(b)" ], "apac-sgp-mas-trm-2021": [ - "11.2.5", - "11.3.1", - "11.3.2" + "6.4.4", + "7.2.2", + "11.1.5", + "11.3.1" + ], + "americas-arg-ppd-2018": [ + "B.2.4-4", + "E.1.2-5" ], - "amaericas-can-osfi-self-assessment": [ - "4.16", - "4.20" + "americas-bmu-mba-coc-2020": [ + "6.15-BP5" ], "americas-can-osfi-b13-2022": [ "3.2.8" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.8" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", + "03.01.03", "03.01.08.A", "03.01.08.B", "03.01.09", @@ -1970,16 +2123,22 @@ "03.01.11", "03.01.12.A", "03.01.16.A", + "03.01.16.C", "03.01.18.A", + "03.03.08.A", "03.04.01.A", "03.04.02.A", + "03.04.02.B", "03.04.06.A", "03.04.06.B", "03.04.06.D", + "03.05.04", + "03.05.07.C", "03.05.07.D", "03.05.07.E", "03.05.07.F", "03.05.12.D", + "03.07.05.B", "03.08.07.A", "03.13.12.B" ] @@ -2005,11 +2164,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to review and update baseline configurations:\n(1) At least annually;\n(2) When required due to so; or\n(3) As part of system component installations and upgrades.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -2079,7 +2238,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -2177,7 +2337,7 @@ ], "general-nist-800-171-r3": [ "03.04.01.b", - "03.04.02.b" + "03.04.06.c" ], "general-nist-800-171a-r3": [ "A.03.04.01.ODP[01]", @@ -2256,24 +2416,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-02" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.46" + ], "emea-eu-nis2-annex-2024": [ "6.3.3" ], - "emea-isr-cmo-1-0": [ - "3.3", - "14.3" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-6" + "2-3-1-6", + "2-4-1-2" ], "emea-sau-cgiot-2024": [ "2-14-4" ], "emea-sau-ecc-1-2018": [ - "1-6-2-2" + "5-1-3-7" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" ], "emea-gbr-def-stan-05-138-2024": [ "2418" @@ -2292,19 +2453,19 @@ "ML3-P5", "ML3-P6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1407", "ISM-1588" ], "apac-ind-sebi-2024": [ "PR.IP.S1" ], - "apac-sgp-mas-trm-2021": [ - "11.2.5" + "apac-nzl-ism-3-9": [ + "15.2.45.C.01" ], "americas-can-itsp-10-171-2025": [ "03.04.01.B", - "03.04.02.B" + "03.04.06.C" ] } }, @@ -2330,7 +2491,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically govern and report on baseline configurations of Technology Assets, Applications and/or Services (TAAS) through Continuous Diagnostics and Mitigation (CDM), or similar technologies.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -2372,7 +2533,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -2463,14 +2625,23 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.d" + "03.04.03.d", + "03.13.13.b" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", "A.03.04.03.d[01]", - "A.03.04.03.d[02]" + "A.03.04.03.d[02]", + "A.03.13.13.b[02]" + ], + "general-nist-800-172-r3": [ + "03.04.02E", + "03.04.04E" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-172a-r3": [ + "A.03.04.02E.ODP[03]", + "DS-A.03.04.03E[01]", + "A.03.04.04E.ODP[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -2519,20 +2690,17 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.c" ], - "emea-isr-cmo-1-0": [ - "3.3", - "6.2", - "6.4", - "9.22", - "9.23", - "14.3", - "14.4" + "emea-sau-cscc-1-2019": [ + "2-3-1-6" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.2" + "emea-sau-ecc-1-2018": [ + "5-1-3-7" + ], + "emea-sau-otcc-1-2022": [ + "2-3-1-11" ], "emea-esp-decree-311-2022": [ - "21.2" + "Article 21(2)" ], "emea-gbr-def-stan-05-138-2024": [ "2415" @@ -2540,16 +2708,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2415" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(a)", - "4.3(b)" - ], "apac-sgp-mas-trm-2021": [ + "7.2.2", "11.3.2" ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.D" + "03.04.03.D", + "03.13.13.B" ] } }, @@ -2573,7 +2739,7 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Historical versions of configurations are maintained for troubleshooting and forensics purposes.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2639,7 +2805,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -2673,6 +2840,13 @@ "general-nist-800-82-r3-high": [ "CM-02(03)" ], + "general-nist-800-172-r3": [ + "03.04.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.06E", + "A.03.04.06E.ODP[01]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.UNI.BRECO" ], @@ -2694,10 +2868,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-02 (03)" ], - "emea-isr-cmo-1-0": [ - "14.5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1510" ] } @@ -2724,7 +2895,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to manage baseline configurations for development and test environments separately from operational baseline configurations to minimize the risk of unintentional changes.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -2789,7 +2960,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -2845,18 +3017,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-isr-cmo-1-0": [ - "10.1", - "10.2" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], "apac-nzl-ism-3-9": [ "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", "18.1.10.C.04" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.3" ] } }, @@ -2890,11 +3058,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) utilized in high-risk areas with more restrictive baseline configurations.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -2965,7 +3133,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -3058,13 +3227,17 @@ "03.04.01.a", "03.04.02.a", "03.04.06.a", - "03.04.06.b", "03.04.06.d", "03.04.12.a" ], "general-nist-800-171a-r3": [ + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.d", "A.03.04.12.ODP[01]", - "A.03.04.12.ODP[02]" + "A.03.04.12.ODP[02]", + "A.03.04.12.a" ], "general-nist-800-218": [ "PO.5.2" @@ -3182,6 +3355,9 @@ "usa-federal-gsa-fedramp-5-high": [ "CM-02(07)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(b)(2)" + ], "usa-federal-irs-1075-2021": [ "CM-2(CE-7)", "CM-2(CE-7).a", @@ -3197,37 +3373,16 @@ "emea-eu-ai-act-2024": [ "Article 14.3(a)" ], - "emea-isr-cmo-1-0": [ - "4.12", - "9.21", - "10.7" - ], "emea-sau-cscc-1-2019": [ - "1-3-2-3", - "2-3-1-7" + "2-6-1-3" ], "emea-sau-ecc-1-2018": [ + "5-1-3-5", + "5-1-3-6", "5-1-3-7" ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-10", - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-22", - "TPC-38", - "TPC-56", - "TPC-63", - "TPC-87" - ], - "emea-gbr-cap-1850-2020": [ - "B4" + "2-2-1-5" ], "emea-gbr-def-stan-05-138-2024": [ "2312" @@ -3241,7 +3396,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2312" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0534", "ISM-1656", "ISM-1657", @@ -3257,18 +3412,24 @@ "ISM-1674", "ISM-1675", "ISM-1676", - "ISM-1677", "ISM-1748", "ISM-1749", - "ISM-1800" + "ISM-1800", + "ISM-1867", + "ISM-1868" ], "apac-nzl-ism-3-9": [ + "15.2.38.C.01", "18.1.10.C.01", "18.1.10.C.02", "18.1.10.C.03", "18.1.10.C.04", "23.2.21.C.01" ], + "americas-arg-ppd-2018": [ + "E.1.2-2", + "E.1.2-DS-1" + ], "americas-can-osfi-b13-2022": [ "3.2.3" ], @@ -3276,9 +3437,9 @@ "03.04.01.A", "03.04.02.A", "03.04.06.A", - "03.04.06.B", "03.04.06.D", - "03.04.12.A" + "03.04.12.A", + "03.14.08.C" ] } }, @@ -3302,7 +3463,7 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3362,7 +3523,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -3378,9 +3540,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.2.8" ], - "emea-isr-cmo-1-0": [ - "9.22" - ], "apac-nzl-ism-3-9": [ "18.1.10.C.01", "18.1.10.C.02", @@ -3409,11 +3568,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Any deviations from approved baseline configurations are reviewed, approved and documented on a case-by-case basis by IT and/or cybersecurity personnel.\n▪ Deviations to baseline configurations are required to have a risk assessment and the business process owner's acceptance of the risk(s) associated with the deviation.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to document, assess risk and approve or deny deviations to standardized configurations.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -3483,7 +3642,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -3553,12 +3713,9 @@ "03.04.02.b" ], "general-nist-800-171a-r3": [ - "A.03.04.02.b[01]", + "A.03.04.01.a[01]", "A.03.04.02.b[02]" ], - "general-nist-800-172": [ - "3.5.2e" - ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -3607,8 +3764,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-06" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.3(c)" + "apac-sgp-mas-trm-2021": [ + "11.3.2" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.8" ], "americas-can-itsp-10-171-2025": [ "03.04.01.A", @@ -3636,9 +3796,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to verify the functionality of security controls when anomalies or misconfigurations are discovered.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 3 Advanced Threats", @@ -3704,7 +3864,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -3750,8 +3911,12 @@ "general-nist-800-161-r1-level-3": [ "CM-6(2)" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.b", + "A.03.04.02E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -3785,10 +3950,6 @@ ], "emea-sau-otcc-1-2022": [ "2-3-1-11" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } }, @@ -3813,11 +3974,11 @@ }, "maturity": { "0": "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.", - "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment.\n▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices.", + "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment.\n▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.\n▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met.", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to allow baseline controls to be specialized or customized by applying a defined set of tailoring actions that are specific to:\n(1) Mission / business functions;\n(2) Operational environment;\n(3) Specific threats or vulnerabilities; or\n(4) Other conditions or situations that could affect mission / business success.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -3885,7 +4046,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -3932,7 +4094,14 @@ "03.13.11" ], "general-nist-800-171a-r3": [ - "A.03.03.02.b" + "A.03.03.02.b", + "A.03.04.01.a[01]", + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.06.a", + "A.03.04.08.a", + "A.03.04.12.a", + "A.03.13.11" ], "general-shared-assessments-sig-2025": [ "N.11" @@ -3989,12 +4158,6 @@ "PL-11-SID.1", "PL-11-SID.2" ], - "emea-isr-cmo-1-0": [ - "10.7" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-7" - ], "emea-gbr-def-stan-05-138-2024": [ "2418" ], @@ -4011,10 +4174,6 @@ "9.5.2.P", "9.5.2.1.PB" ], - "apac-nzl-ism-3-9": [ - "16.1.50.C.01", - "16.1.50.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.03.02.B", "03.04.01.A", @@ -4058,9 +4217,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to provide only essential capabilities by specifically prohibiting or restricting the use of ports, protocols, and/or services.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to provide only essential capabilities by specifically prohibiting or restricting the use of ports, protocols, and/or services. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -4131,7 +4290,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -4141,7 +4301,7 @@ "CC6.7-POF1" ], "general-cis-csc-8-1": [ - "4.0", + "4", "4.6", "4.8" ], @@ -4196,7 +4356,7 @@ "8.9", "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -4479,7 +4639,15 @@ ], "general-nist-800-171a-r3": [ "A.03.04.02.ODP[01]", - "A.03.04.06.d" + "A.03.04.02.a[01]", + "A.03.04.06.a", + "A.03.04.06.b[01]", + "A.03.04.06.b[02]", + "A.03.04.06.b[03]", + "A.03.04.06.b[04]", + "A.03.04.06.b[05]", + "A.03.04.06.d", + "A.03.04.08.a" ], "general-nist-csf-2-0": [ "PR.PS-05" @@ -4586,30 +4754,18 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(f)" ], - "emea-isr-cmo-1-0": [ - "4.8", - "4.9", - "12.9", - "12.13" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-5" - ], "emea-sau-otcc-1-2022": [ - "2-2-1-5", - "2-3-1-4" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 20(a)", - "Article 20(b)", - "Article 20(c)", - "Article 20(d)" + "2-4-1-14" ], "emea-esp-decree-311-2022": [ - "20(a)", - "20(b)", - "20(c)", - "20(d)" + "Article 20(c)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.2", + "op.exp.3" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2204", @@ -4630,7 +4786,7 @@ "2430", "2507" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0385", "ISM-1006", "ISM-1311", @@ -4642,15 +4798,24 @@ "ISM-1489", "ISM-1621" ], + "apac-aus-cop-sitc-2020": [ + "6" + ], "apac-ind-sebi-2024": [ "PR.IP.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], "apac-nzl-ism-3-9": [ "18.1.15.C.01", "18.1.15.C.02", "18.1.15.C.03", "18.1.15.C.04" ], + "apac-sgp-mas-trm-2021": [ + "11.2.6" + ], "americas-can-osfi-b13-2022": [ "3.2.8" ], @@ -4685,7 +4850,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to periodically review system configurations to identify and disable unnecessary and/or non-secure functions, ports, protocols and services.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -4753,7 +4918,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -4834,7 +5000,9 @@ "3.4.7[o]" ], "general-nist-800-171a-r3": [ - "A.03.04.06.ODP[06]" + "A.03.04.06.ODP[06]", + "A.03.04.06.c", + "A.03.04.08.c" ], "general-pci-dss-4-0-1": [ "1.2.7", @@ -4903,11 +5071,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (01)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.2" - ], - "emea-esp-decree-311-2022": [ - "21.2" + "emea-sau-otcc-1-2022": [ + "2-3-1-2" ], "emea-gbr-def-stan-05-138-2024": [ "2430", @@ -4956,9 +5121,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the execution of unauthorized software programs.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the execution of unauthorized software programs. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -5027,7 +5192,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -5073,6 +5239,9 @@ "general-nist-800-171-r3": [ "03.04.08.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.08.b" + ], "general-nist-csf-2-0": [ "PR.PS-05" ], @@ -5103,17 +5272,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (02)" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], "apac-aus-essential-8-2024": [ "ML2-P5", "ML3-P5" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.04.08.B" ] @@ -5143,7 +5305,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to explicitly allow (allowlist / whitelist) and/or block (denylist / blacklist) applications that are authorized to execute on systems.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -5213,7 +5375,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -5312,8 +5475,17 @@ "A.03.04.08.ODP[01]", "A.03.04.08.a", "A.03.04.08.b", + "A.03.13.13.a[01]", + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", "A.03.13.13.b[03]" ], + "general-nist-800-172-r3": [ + "03.13.06E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.06E.ODP[01]" + ], "general-sparta": [ "CM0047", "CM0069" @@ -5362,12 +5534,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-07 (05)" ], - "emea-deu-c5-2020": [ - "AM-02" - ], - "emea-isr-cmo-1-0": [ - "6.7" - ], "emea-sau-cscc-1-2019": [ "2-3-1-1" ], @@ -5378,7 +5544,9 @@ "2-3-1-6" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5-BP2", + "5-BP2-1", + "5-BP2-2" ], "emea-gbr-def-stan-05-138-2024": [ "2409" @@ -5397,7 +5565,7 @@ "ML2-P5", "ML3-P5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-1235", @@ -5416,15 +5584,12 @@ "14.2.7.C.04", "14.2.7.C.05", "14.2.7.C.06", - "14.2.7.C.07" + "14.2.7.C.07", + "21.3.12.C.02" ], "apac-sgp-mas-trm-2021": [ "11.3.6" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.04.08.A", "03.04.08.B", @@ -5438,7 +5603,7 @@ "title": "Split Tunneling", "family": "CFG", "description": "Mechanisms exist to prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards.", - "scf_question": "Does the organization prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?\n\nPrevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?", + "scf_question": "Does the organization prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5455,7 +5620,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to prevent split tunneling for remote devices unless the split tunnel is securely provisioned using organization-defined safeguards.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -5504,7 +5669,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -5587,10 +5753,6 @@ "usa-federal-cms-marse-2-0": [ "SC-7(7)" ], - "emea-isr-cmo-1-0": [ - "4.15", - "9.13" - ], "emea-gbr-def-stan-05-138-2024": [ "2305" ], @@ -5603,7 +5765,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2305" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0705" ], "apac-nzl-ism-3-9": [ @@ -5634,7 +5796,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to enforce software usage restrictions to comply with applicable contract agreements and copyright laws.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -5705,7 +5867,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -5721,7 +5884,7 @@ "general-govramp-high": [ "CM-10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1546.008", "T1546.013", "T1550.001", @@ -5768,6 +5931,11 @@ "general-nist-800-171-r3": [ "03.13.13.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[01]", + "A.03.13.13.b[03]" + ], "general-tisax-6-0-3": [ "1.3.4" ], @@ -5804,8 +5972,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-10" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "apac-sgp-mas-trm-2021": [ + "6.1.3" ], "americas-can-itsp-10-171-2025": [ "03.13.13.B" @@ -5832,9 +6000,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to establish parameters for the secure use of open source software.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to establish parameters for the secure use of open source software. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -5904,7 +6072,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -5943,12 +6112,19 @@ "general-nist-800-171-r3": [ "03.13.13.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], "usa-federal-cms-marse-2-0": [ "CM-10(1)", "CM-10(1).a", "CM-10(1).b", "CM-10(1).c" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-sgp-mas-trm-2021": [ "6.1.3" ], @@ -5979,7 +6155,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to allow only approved Internet browsers and email clients to run on systems.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -6047,7 +6223,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -6055,7 +6232,7 @@ "CC6.7" ], "general-cis-csc-8-1": [ - "9.0", + "9", "9.1", "9.4" ], @@ -6070,11 +6247,7 @@ "9.1", "9.4" ], - "emea-sau-ecc-1-2018": [ - "2-4-1", - "2-5-3-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0824", "ISM-1235", "ISM-1412", @@ -6086,10 +6259,6 @@ "ISM-1601", "ISM-1654", "ISM-1655" - ], - "amaericas-can-osfi-self-assessment": [ - "4.6", - "4.9" ] } }, @@ -6119,7 +6288,7 @@ "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to restrict the ability of non-privileged users to install unauthorized software.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -6190,7 +6359,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -6212,7 +6382,7 @@ "general-govramp-high": [ "CM-11" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.005", "T1059", "T1059.006", @@ -6296,6 +6466,10 @@ "3.4.9[b]", "3.4.9[c]" ], + "general-nist-800-171a-r3": [ + "A.03.13.13.a[02]", + "A.03.13.13.b[03]" + ], "general-nist-csf-2-0": [ "PR.PS-05" ], @@ -6345,21 +6519,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-11" ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0382", "ISM-1592", "ISM-1655" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" - ], "americas-can-itsp-10-171-2025": [ "03.13.13.B" ] @@ -6385,9 +6549,9 @@ "0": "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.", "1": "Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).\n▪ Secure baseline configurations generate logs that contain sufficient information to establish necessary details of activity and allow for forensics analysis.", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", - "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to generate an alert when the unauthorized installation of software is detected.", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to generate an alert when the unauthorized installation of software is detected. ", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -6436,7 +6600,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -6491,6 +6656,12 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.02E.b" + ], "usa-federal-fbi-cjis-6-0": [ "CM-8(3)" ], @@ -6515,13 +6686,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.c" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } }, @@ -6543,11 +6707,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure systems to prevent the installation of software, unless the action is performed by a privileged user or service.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -6615,7 +6779,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -6667,10 +6832,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(02)" ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0382", "ISM-1592" ], @@ -6685,10 +6847,6 @@ "12.6.2.2", "12.6.2.3", "12.6.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } }, @@ -6710,11 +6868,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically monitor, enforce and report on configurations for endpoint devices.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -6783,7 +6941,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -6815,8 +6974,10 @@ "03.04.02.b", "03.04.03.a" ], - "general-nist-800-172": [ - "3.4.2e" + "general-nist-800-171a-r3": [ + "A.03.04.02.a[01]", + "A.03.04.02.b[01]", + "A.03.04.03.a" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -6836,7 +6997,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-0955", @@ -6849,9 +7010,8 @@ "apac-ind-sebi-2024": [ "PR.DS.S6" ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(b)" ], "americas-can-itsp-10-171-2025": [ "03.04.02.A", @@ -6878,7 +7038,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to automatically identify unauthorized deviations from an approved baseline and implement automated resiliency actions to remediate the unauthorized change.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6949,7 +7109,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -6983,9 +7144,11 @@ "CM-03(08)", "CM-11(03)" ], - "general-nist-800-172": [ - "3.4.2e", - "3.14.7e" + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -7005,7 +7168,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CM-11(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0843", "ISM-0846", "ISM-0955", @@ -7017,10 +7180,6 @@ ], "apac-ind-sebi-2024": [ "PR.DS.S6" - ], - "amaericas-can-osfi-self-assessment": [ - "4.19", - "4.20" ] } }, @@ -7042,7 +7201,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to implement Zero-Touch Provisioning (ZTP), or similar technology, to automatically and securely configure devices upon being added to a network.", "4": "Configuration Management (CFG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7090,7 +7249,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -7106,8 +7266,8 @@ "control_id": "CFG-08", "title": "Sensitive / Regulated Data Access Enforcement", "family": "CFG", - "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data.", - "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data?", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive and/or regulated data.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive and/or regulated data?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -7122,7 +7282,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).", "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to restrict access to sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7210,7 +7370,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -7234,7 +7395,8 @@ "03.01.02" ], "general-nist-800-171a-r3": [ - "A.03.01.02[01]" + "A.03.01.02[01]", + "A.03.01.02[02]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -7246,12 +7408,12 @@ "248.30(a)(2)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.312(c)(2)" + "§ 164.308(a)(3)(i)", + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "AC-3(CE-11)" @@ -7265,8 +7427,8 @@ "control_id": "CFG-08.1", "title": "Sensitive / Regulated Data Actions", "family": "CFG", - "description": "Automated mechanisms exist to generate event logs whenever sensitive/regulated data is collected, created, updated, deleted and/or archived.", - "scf_question": "Does the organization use automated mechanisms to generate event logs whenever sensitive/regulated data is collected, created, updated, deleted and/or archived?", + "description": "Automated mechanisms exist to generate event logs whenever sensitive and/or regulated data is collected, created, updated, deleted and/or archived.", + "scf_question": "Does the organization use automated mechanisms to generate event logs whenever sensitive and/or regulated data is collected, created, updated, deleted and/or archived?", "relative_weight": 7, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -7362,7 +7524,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Configuration Management", "crosswalks": { @@ -7372,14 +7535,320 @@ "general-nist-800-66-r2": [ "164.312(c)" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" + ] + } + }, + { + "control_id": "CFG-09", + "title": "Production Software Repository", + "family": "CFG", + "description": "Mechanisms exist to maintain an authoritative repository for production software.", + "scf_question": "Does the organization maintain an authoritative repository for production software?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to maintain an authoritative repository for production software.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Version control system with protected production branch (e.g., GitHub, GitLab).\n∙ Designated production branch with access controls", + "small": "∙ Version control with protected production branches.\n∙ Access restrictions on production branch", + "medium": "∙ Artifact repository manager (e.g., JFrog Artifactory, Nexus)\n∙ Version-controlled production software with access restrictions", + "large": "∙ Enterprise artifact repository (e.g., JFrog Artifactory, Nexus)\n∙ Access controls on production repository\n∙ Immutable artifact storage", + "enterprise": "∙ Enterprise artifact repository (e.g., JFrog Artifactory)\n∙ Software Bill of Materials (SBOM) generation\n∙ Immutable artifact storage with digital signing\n∙ Integration with CI/CD pipeline" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2023", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2023" + ] + } + }, + { + "control_id": "CFG-09.1", + "title": "Third-Party Libraries", + "family": "CFG", + "description": "Mechanisms exist to restrict the use and import of third-party libraries and/or software components to trustworthy sources.", + "scf_question": "Does the organization restrict the use and import of third-party libraries and/or software components to trustworthy sources?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to restrict the use and import of third-party libraries and/or software components to trustworthy sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Manual review of third-party libraries before use\n∙ OWASP Dependency-Check\n∙ Approved library list", + "small": "∙ OWASP Dependency-Check for vulnerability scanning\n∙ Approved third-party library register", + "medium": "∙ Software Composition Analysis (SCA) tool\n∙ Approved vendor/library register\n∙ Dependency vulnerability scanning in CI/CD", + "large": "∙ Enterprise SCA tool (e.g., Snyk, Mend, Black Duck)\n∙ Approved library registry\n∙ Automated dependency scanning in CI/CD pipeline", + "enterprise": "∙ Enterprise SCA platform (e.g., Snyk, Black Duck\n∙ Automated library approval workflows\n∙ SBOM generation for all dependencies\n∙ Real-time vulnerability alerting for in-use libraries" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2029", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2029" + ] + } + }, + { + "control_id": "CFG-09.2", + "title": "Software Repository Protections", + "family": "CFG", + "description": "Mechanisms exist to protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys.", + "scf_question": "Does the organization protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to protect software repositories from importing untrusted and/or malicious software artifacts by:\n(1) Scanning artifacts for malicious content;\n(2) Verifying a digital signature or secure hash provided over a secure channel; and\n(3) Scanning artifacts to identify plain text or encoded secrets and keys.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Checksum verification of downloaded packages\n∙ Use of reputable package registries only", + "small": "∙ Package signature verification\n∙ Private package mirror or proxy", + "medium": "∙ Artifact repository with malware scanning\n∙ Package signature and hash verification\n∙ Private package registry to proxy public registries", + "large": "∙ Enterprise artifact repository with integrated security scanning\n∙ Signed artifact enforcement\n∙ Private package proxy with allowlist", + "enterprise": "∙ Enterprise artifact repository with automated malware scanning and secret detection\n∙ Code signing enforcement\n∙ Supply chain security tools.\n∙ Private package proxy with security scanning" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2026 & ISM-2027", + "family_name": "Configuration Management", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2026", + "ISM-2027", + "ISM-2030" + ] + } + }, + { + "control_id": "CFG-09.3", + "title": "Software Development Repository", + "family": "CFG", + "description": "Mechanisms exist to maintain an authoritative repository for software development activities that is separate from production software.", + "scf_question": "Does the organization maintain an authoritative repository for software development activities that is separate from production software?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.\n▪ 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Configuration Management (CFG) 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:\n▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.\n▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 CFG 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).\n▪ An implemented and operational capability exists to maintain an authoritative repository for software development activities that is separate from production software.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Separate development branch in version control\n∙ GitHub or GitLab for development repository.", + "small": "∙ Separate development environment and repository\n∙ Branch-based development workflow separate from production", + "medium": "∙ Separate development, staging and production repositories\n∙ Access controls separating development from production code", + "large": "∙ Enterprise repository management with environment separation\n∙ Strict access controls between dev and production repositories\n∙ Code review requirements before production promotion", + "enterprise": "∙ Enterprise DevSecOps platform with environment-separated repositories\n∙ Automated promotion gates between environments\n∙ Immutable production code repository\n∙ Integration with ITSM change management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM-2024", + "family_name": "Configuration Management", + "crosswalks": { + "emea-sau-ecc-1-2018": [ + "1-6-3-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2024" ] } } diff --git a/docs/api/families/CHG.json b/docs/api/families/CHG.json index 167eb3f4..f297bb4f 100644 --- a/docs/api/families/CHG.json +++ b/docs/api/families/CHG.json @@ -118,7 +118,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -242,15 +243,15 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.d" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.d[01]", "A.03.04.03.d[02]" ], - "general-nist-800-172": [ - "3.13.2e" - ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -333,10 +334,10 @@ "314.4(c)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)" + "§ 164.308(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "CM-3" @@ -365,9 +366,8 @@ "CM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "emea-eu-dora-2023": [ "Article 9.4(e)" @@ -379,51 +379,35 @@ "6.6.1", "6.10.2(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "8.4" ], "emea-deu-c5-2020": [ - "DEV-03", - "DEV-08" + "BEI-03", + "BEI-03-BP1", + "BEI-03-BP2", + "BEI-05", + "BEI-06", + "BEI-08" ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.6", - "14.7" + "emea-sau-cscc-1-2019": [ + "1-3-1" ], "emea-sau-cgiot-2024": [ "1-5-3" ], - "emea-sau-ecc-1-2018": [ - "1-6-2" - ], "emea-sau-otcc-1-2022": [ - "1-5", "1-5-1", - "1-5-2" + "1-5-2", + "1-5-3" ], "emea-sau-sama-csf-1-2017": [ - "3.3.7" + "3.3.7", + "3.3.7.1", + "3.3.7.4" ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.1" - ], - "emea-esp-decree-311-2022": [ - "21.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.5 [OP.EXP.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], "emea-gbr-def-stan-05-138-2024": [ "2404" @@ -437,7 +421,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2404" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1211" ], "apac-ind-sebi-2024": [ @@ -449,7 +433,10 @@ "12.1.2.1", "12.1.2.11.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.11" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP18", "HML18" ], @@ -460,29 +447,26 @@ "6.3.6.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.5.1", - "7.5.2", - "7.5.3", - "7.5.4", - "7.5.5", - "7.5.6", - "7.5.7" + "7.5.1" ], - "americas-bmu-mba-coc-2020": [ - "6.1" + "americas-arg-ppd-2018": [ + "C", + "C.1.1-2" ], - "amaericas-can-osfi-self-assessment": [ - "4.17", - "4.20", - "6.11" + "americas-bmu-mba-coc-2020": [ + "6.1-BP2" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.A" + "03.04.03.A", + "03.04.03.D" ] } }, @@ -582,7 +566,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -661,7 +646,7 @@ "general-iso-42001-2023": [ "6.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.005", "T1059.006", "T1176", @@ -747,7 +732,8 @@ "03.04.02.b", "03.04.03.a", "03.04.03.b", - "03.04.03.c" + "03.04.03.c", + "03.07.05.a" ], "general-nist-800-171a": [ "3.4.3[a]", @@ -756,8 +742,11 @@ "3.4.3[d]" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", "A.03.04.03.a", - "A.03.04.03.c[01]" + "A.03.04.03.b[02]", + "A.03.04.03.c[01]", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -790,9 +779,6 @@ "6.5.6", "12.4.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-tisax-6-0-3": [ "5.2.1" ], @@ -861,9 +847,8 @@ "CM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.75" ], "emea-eu-dora-2023": [ "Article 9.4(e)" @@ -876,32 +861,23 @@ "8.5" ], "emea-deu-c5-2020": [ - "DEV-08" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.7" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3-5" + "BEI-08", + "BEI-09-DOAR" ], "emea-sau-otcc-1-2022": [ - "1-5", - "1-5-1", - "1-5-2", - "1-5-3", - "1-5-3-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "1-5-3-1", + "1-5-3-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 21.1" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.c", + "3.3.7.4.d", + "3.3.7.4.e", + "3.3.7.4.i" ], - "emea-esp-decree-311-2022": [ - "21.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1211" ], "apac-ind-sebi-2024": [ @@ -954,7 +930,12 @@ "14.2.4.9", "14.2.4.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.11", + "10.18", + "10.27" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP18", "HML18" ], @@ -967,20 +948,27 @@ "6.3.7.C.02", "6.3.7.C.03" ], - "amaericas-can-osfi-self-assessment": [ - "4.18", - "4.20" + "apac-sgp-mas-trm-2021": [ + "7.5.2", + "7.5.4" + ], + "americas-arg-ppd-2018": [ + "C.1.1-DS" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1", "2.5.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", "03.04.03.A", "03.04.03.B", - "03.04.03.C" + "03.04.03.C", + "03.07.05.A" ] } }, @@ -1078,7 +1066,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -1131,11 +1120,16 @@ ], "general-nist-800-171-r3": [ "03.04.02.b", - "03.04.03.a" + "03.04.03.a", + "03.04.03.b", + "03.07.05.a" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.03.a", "A.03.04.03.b[02]", - "A.03.04.05[05]" + "A.03.04.05[05]", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 5" @@ -1175,21 +1169,10 @@ "7123(c)(5)(E)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "emea-deu-c5-2020": [ - "IDM-02" - ], - "emea-isr-cmo-1-0": [ - "14.7" - ], - "emea-sau-otcc-1-2022": [ - "1-5-3-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "BEI-12" ], "apac-jpn-ismap": [ "14.2.4", @@ -1200,16 +1183,26 @@ "14.2.4.5", "14.2.4.6" ], + "apac-nzl-ism-3-9": [ + "20.2.15.C.02", + "20.2.15.C.05" + ], "apac-sgp-mas-trm-2021": [ - "7.5.4" + "7.5.2" ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1", + "2.5.3" + ], "americas-can-itsp-10-171-2025": [ "03.04.02.B", - "03.04.03.A" + "03.04.03.A", + "03.04.03.B", + "03.07.05.A" ] } }, @@ -1307,7 +1300,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -1409,7 +1403,18 @@ "03.04.11.b" ], "general-nist-800-171a-r3": [ - "A.03.04.03.c[02]" + "A.03.04.03.b[02]", + "A.03.04.03.c[02]", + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], + "general-nist-800-172-r3": [ + "03.04.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.07E[01]", + "DS-A.03.04.07E[03]" ], "general-nist-csf-2-0": [ "ID.RA-07" @@ -1483,39 +1488,25 @@ "CM-03 (02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37" ], "emea-deu-c5-2020": [ - "DEV-06", - "DEV-08", - "DEV-09" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "12.21", - "12.30", - "14.6", - "14.8", - "14.9", - "14.10" - ], - "emea-sau-cscc-1-2019": [ - "1-3-1-2" + "BEI-03-BP3", + "BEI-03-BP4", + "BEI-07", + "BEI-09" ], "emea-sau-cgiot-2024": [ "1-5-3" ], - "emea-sau-ecc-1-2018": [ - "1-6-2-1", - "1-6-3-5" - ], "emea-sau-otcc-1-2022": [ "1-5-3-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ], "apac-ind-sebi-2024": [ "PR.MA.S1" @@ -1529,21 +1520,26 @@ "14.2.3.2", "14.2.3.3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "apac-nzl-ism-3-9": [ "6.3.8.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.4.2", "7.5.3", "7.5.5", "7.5.7" ], - "amaericas-can-osfi-self-assessment": [ - "6.11" + "americas-arg-ppd-2018": [ + "C.1.1-3" ], "americas-can-osfi-b13-2022": [ "2.5.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.04.03.B", "03.04.03.C", @@ -1572,7 +1568,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to include a cybersecurity and/or data protection representative in the configuration change control review process.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1644,9 +1640,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Change Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -1695,6 +1691,9 @@ "general-nist-800-171-r3": [ "03.04.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.04.04.a" + ], "general-tisax-6-0-3": [ "5.2.2" ], @@ -1722,29 +1721,13 @@ "CM-03 (04)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" - ], - "emea-deu-c5-2020": [ - "DEV-05", - "DEV-09" - ], - "emea-isr-cmo-1-0": [ - "14.8" - ], - "emea-sau-ecc-1-2018": [ - "1-6-2-2" + "3.4.4.37" ], "emea-sau-otcc-1-2022": [ - "1-5-2" - ], - "apac-sgp-mas-trm-2021": [ - "7.5.4" + "1-5-4" ], - "amaericas-can-osfi-self-assessment": [ - "2.4", - "6.11" + "apac-mys-bnm-rmit-2025": [ + "10.11" ], "americas-can-itsp-10-171-2025": [ "03.04.04.A" @@ -1769,7 +1752,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions upon the detection of unauthorized baseline configurations change(s).", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1824,7 +1807,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -1850,9 +1834,6 @@ ], "general-pci-dss-4-0-1": [ "10.7" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" ] } }, @@ -1876,7 +1857,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern assets involved in providing cryptographic protections according to the organization's configuration management processes.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern assets involved in providing cryptographic protections according to the organization's configuration management processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1908,7 +1889,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -2021,7 +2003,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -2109,7 +2092,9 @@ ], "general-nist-800-171a-r3": [ "A.03.04.03.b[01]", - "A.03.04.04.a" + "A.03.04.04.a", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" ], "general-nist-csf-2-0": [ "ID.RA-07" @@ -2134,9 +2119,6 @@ "6.5.2", "6.5.6" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-tisax-6-0-3": [ "5.2.2", "5.3.1" @@ -2184,29 +2166,23 @@ "CM-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(37)", - "3.6.3(75)", - "3.6.3(76)" + "3.4.4.37", + "3.6.3.76" ], "emea-deu-c5-2020": [ - "DEV-05", - "BCM-02" - ], - "emea-isr-cmo-1-0": [ - "10.6", - "14.8" - ], - "emea-sau-cscc-1-2019": [ - "1-3-1-2" + "BEI-04", + "BEI-06" ], "emea-sau-otcc-1-2022": [ - "1-5-2", "1-5-4" ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.a" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.11" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP33", "HML33" ], @@ -2244,7 +2220,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2285,7 +2261,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -2311,7 +2288,7 @@ "general-govramp-high": [ "CM-05" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -2528,6 +2505,10 @@ "3.4.5[g]", "3.4.5[h]" ], + "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.05[06]" + ], "general-nist-800-218": [ "PS.1" ], @@ -2587,9 +2568,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-05" ], - "emea-deu-c5-2020": [ - "DEV-09" - ], "emea-sau-otcc-1-2022": [ "1-5-3-4" ], @@ -2605,6 +2583,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2422" ], + "apac-aus-ism-2026-march": [ + "ISM-1823" + ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.2" @@ -2633,7 +2614,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to perform after-the-fact reviews of configuration change logs to discover any unauthorized changes.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2691,7 +2672,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -2752,10 +2734,10 @@ "CM-5(1)" ], "emea-sau-otcc-1-2022": [ - "1-5-4" + "1-5-3-5" ], - "amaericas-can-osfi-self-assessment": [ - "6.11" + "americas-can-osfi-self-assessment-2": [ + "2.5.3" ] } }, @@ -2777,7 +2759,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to prevent the installation of software and firmware components without verification that the component has been digitally signed using an organization-approved certificate authority.", "4": "Change Management (CHG) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2813,7 +2795,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -2862,7 +2845,7 @@ "usa-federal-irs-1075-2021": [ "CM-14" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1796" ] } @@ -2885,7 +2868,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to enforce a two-person rule for implementing changes to critical Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2940,7 +2923,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -2998,6 +2982,15 @@ "general-nist-800-161-r1-level-3": [ "AC-5" ], + "general-nist-800-172-r3": [ + "03.04.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.05E[01]", + "A.03.04.05E.ODP[01]", + "DS-A.03.04.05E[02]", + "A.03.04.05E.ODP[02]" + ], "usa-federal-fbi-cjis-6-0": [ "AC-5" ], @@ -3025,8 +3018,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-05" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-6" + "apac-sgp-mas-trm-2021": [ + "9.1.1" ] } }, @@ -3106,7 +3099,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -3171,16 +3165,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-05 (05)" ], - "emea-deu-c5-2020": [ - "DEV-09", - "PSS-08" - ], - "emea-isr-cmo-1-0": [ - "10.4" - ], - "apac-chn-data-security-law-2021": [ - "27" - ], "americas-can-osfi-b13-2022": [ "2.5", "2.5.2" @@ -3210,7 +3194,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to restrict software library privileges to those individuals with a pertinent business need for access.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to restrict software library privileges to those individuals with a pertinent business need for access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3265,7 +3249,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -3293,15 +3278,17 @@ "general-ul-2900-1-2017": [ "4.1(e)" ], - "emea-deu-c5-2020": [ - "DEV-07", - "DEV-08" - ], "emea-sau-cscc-1-2019": [ "1-3-2-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0405" + ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" ] } }, @@ -3327,7 +3314,7 @@ "0": "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.", "1": "Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Limited information is provided to stakeholders about proposed changes.", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to ensure stakeholders are made aware of and understand the impact of proposed changes.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to ensure stakeholders are made aware of and understand the impact of proposed changes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3384,7 +3371,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -3492,9 +3480,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-09" ], + "emea-deu-c5-2020": [ + "BEI-03-BP2" + ], "emea-sau-cgiot-2024": [ "1-5-3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "americas-can-itsp-10-171-2025": [ "03.04.11.B" ] @@ -3505,7 +3499,7 @@ "title": "Control Functionality Verification", "family": "CHG", "description": "Mechanisms exist to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed.", - "scf_question": "Does the organization verify the functionality of cybersecurity and/or data protection controls following implemented changes to ensure applicable controls operate as designed?", + "scf_question": "Does the organization verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -3518,9 +3512,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", - "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed.", + "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to verify the functionality of security, compliance and resilience controls following implemented changes to ensure applicable controls operate as designed. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3585,9 +3579,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Change Management", "crosswalks": { "general-cis-csc-8-1": [ @@ -3671,6 +3665,12 @@ "general-nist-800-171a-r3": [ "A.03.04.04.b" ], + "general-nist-800-172-r3": [ + "03.04.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.07E[02]" + ], "general-pci-dss-4-0-1": [ "6.5.2", "10.7.3", @@ -3729,13 +3729,14 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-03 (02)" ], - "emea-isr-cmo-1-0": [ - "10.6", - "12.30", - "14.10" + "emea-sau-otcc-1-2022": [ + "1-5-4" ], - "apac-sgp-mas-trm-2021": [ - "7.5.5" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.f" + ], + "americas-arg-ppd-2018": [ + "C.1.1-1" ], "americas-can-itsp-10-171-2025": [ "03.04.04.B" @@ -3747,7 +3748,7 @@ "title": "Report Verification Results", "family": "CHG", "description": "Mechanisms exist to report the results of security, compliance and resilience capability verification to appropriate organizational management.", - "scf_question": "Does the organization report the results of cybersecurity and data protection function verification to appropriate organizational management?", + "scf_question": "Does the organization report the results of security, compliance and resilience capability verification to appropriate organizational management?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -3760,7 +3761,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to report the results of security, compliance and resilience capability verification to appropriate organizational management.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3804,9 +3805,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Change Management", "crosswalks": { "general-nist-800-53-r5-2": [ @@ -3850,7 +3851,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to govern change management procedures for \"emergency\" changes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3859,7 +3860,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Documented emergency change procedure\n∙ Post-implementation documentation requirement", + "small": "∙ Emergency change request process\n∙ Designated emergency change approver\n∙ Post-implementation review", + "medium": "∙ Formal emergency change management process\n∙ ITSM tool emergency change workflow (e.g., ServiceNow, Jira)\n∙ Emergency Change Advisory Board (CAB) approval", + "large": "∙ Enterprise emergency change management process in ITSM platform\n∙ Emergency CAB with on-call members\n∙ Integration with incident response", + "enterprise": "∙ Enterprise ITSM emergency change workflow\n∙ 24/7 emergency CAB availability\n∙ Automated emergency change tracking and audit trail\n∙ Integration with incident response processes" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -3911,7 +3918,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { @@ -3923,6 +3931,18 @@ ], "emea-eu-nis2-annex-2024": [ "6.4.3" + ], + "emea-deu-c5-2020": [ + "BEI-10" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.h" + ], + "apac-sgp-mas-trm-2021": [ + "7.5.6" + ], + "americas-can-osfi-self-assessment-2": [ + "2.5.1" ] } }, @@ -3953,7 +3973,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Emergency change log (spreadsheet)\n∙ Post-hoc documentation template for emergency changes", + "small": "∙ Emergency change documentation register\n∙ Mandatory post-implementation review requirement", + "medium": "∙ ITSM-based post-implementation emergency change documentation\n∙ Mandatory post-implementation review within defined timeframe", + "large": "∙ ITSM platform mandatory documentation workflow\n∙ Post-implementation review with management sign-off\n∙ Integration with audit trail", + "enterprise": "∙ Automated ITSM documentation requirements for emergency changes\n∙ Mandatory post-implementation review with sign-off\n∙ Integration with GRC and audit reporting" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -4005,12 +4031,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Change Management", "crosswalks": { "emea-eu-nis2-annex-2024": [ "6.4.3" + ], + "emea-deu-c5-2020": [ + "BEI-10" ] } }, @@ -4019,7 +4049,7 @@ "title": "Dual Approval For High-Impact Environments", "family": "CHG", "description": "Mechanisms exist to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization require dual approval for any changes that might result in a serious, but adverse impact to:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -4032,7 +4062,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are documented and maintained by process owners.\n▪ 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.", "3": "Change Management (CHG) 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:\n▪ Policies and standards associated with CHG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CHG domain capabilities are well-documented and kept current by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.\n▪ 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 CHG 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).\n▪ An implemented and operational capability exists to require dual approval for any changes that might result in a serious incident that could adversely impact:\n(1) Business processes; and/or\n(2) Technology Assets, Applications, Services and/or Data (TAASD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4064,13 +4094,16 @@ "MT-8", "MT-9", "MT-10", - "MT-11" + "MT-11", + "MT-28" ], - "errata": "- new control (IEC 62443-4-2)", "family_name": "Change Management", "crosswalks": { "general-iec-62443-4-2-2019": [ "CR 2.1(4)" + ], + "emea-sau-otcc-1-2022": [ + "2-2-1-6" ] } } diff --git a/docs/api/families/CLD.json b/docs/api/families/CLD.json index 77e264c9..80e82ee5 100644 --- a/docs/api/families/CLD.json +++ b/docs/api/families/CLD.json @@ -23,9 +23,9 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to identify cybersecurity and data protection requirements for CSP environments, including dedicated and multi-client environments.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to facilitate the implementation of cloud management controls to ensure cloud instances are secure and in-line with industry practices. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -122,7 +122,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -189,9 +190,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-shared-assessments-sig-2025": [ "J.1" ], @@ -210,22 +208,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "COS-01", - "COS-02" - ], - "emea-isr-cmo-1-0": [ - "11.2" + "UP-01", + "UP-01-BP1", + "UP-01-BP2", + "RB-05" ], "emea-sau-cscc-1-2019": [ - "4-2" + "4-2-1" ], "emea-sau-cgiot-2024": [ "4-2-1" @@ -233,23 +223,38 @@ "emea-sau-ecc-1-2018": [ "4-2-1", "4-2-2", - "4-2-3", + "4-2-3-1", "4-2-3-2", - "4-2-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" + "4-2-3-3" ], "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.4.3" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "apac-aus-ism-2024-june": [ + "3.4.3", + "3.4.3.1", + "3.4.3.3", + "3.4.3.4", + "3.4.3.4.a", + "3.4.3.4.a.1", + "3.4.3.4.a.2", + "3.4.3.4.a.3", + "3.4.3.4.b", + "3.4.3.4.b.1", + "3.4.3.4.c", + "3.4.3.4.c.1", + "3.4.3.4.d", + "3.4.3.4.d.1", + "3.4.3.4.e", + "3.4.3.4.e.1", + "3.4.3.4.f", + "3.4.3.4.f.1", + "3.4.3.4.g", + "3.4.3.4.g.1", + "3.4.3.4.g.2", + "3.4.3.4.g.3" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.nub.1" + ], + "apac-aus-ism-2026-march": [ "ISM-1437", "ISM-1529", "ISM-1579", @@ -270,29 +275,20 @@ "5.1.1.29.P", "5.1.1.30.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.26", + "10.50" + ], "apac-nzl-ism-3-9": [ + "2.3.28.C.01", + "20.1.20.C.01", + "20.1.20.C.02", + "20.1.20.C.03", + "20.1.20.C.04", "22.1.20.C.01", "22.1.20.C.02", "22.1.20.C.03", - "22.1.20.C.04", - "22.1.20.C.05", "22.1.21.C.01", - "22.1.21.C.02", - "22.1.21.C.03", - "22.1.21.C.04", - "22.1.21.C.05", - "22.1.21.C.06", - "22.1.21.C.07", - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04", - "22.1.25.C.01", - "22.1.25.C.02", - "22.1.26.C.01", - "22.1.26.C.02", - "22.1.26.C.03", - "22.1.27.C.01", "23.1.54.C.01", "23.1.54.C.02", "23.2.19.C.01" @@ -320,7 +316,7 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud services are designed and configured so Technology Assets, Applications and/or Services (TAAS) are secured in accordance with applicable organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -394,12 +390,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { - "emea-sau-sacs-002-2022": [ - "TPC-43" + "emea-sau-ecc-1-2018": [ + "4-2-3-1" ], "apac-nzl-ism-3-9": [ "23.4.9.C.01", @@ -499,10 +496,24 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { + "emea-deu-c5-2020": [ + "PI-02", + "PI-05" + ], + "emea-sau-ecc-1-2018": [ + "4-2-3-1" + ], + "emea-sau-sama-csf-1-2017": [ + "3.4.3.4.h", + "3.4.3.4.h.1", + "3.4.3.4.h.2", + "3.4.3.4.h.3" + ], "apac-jpn-ismap": [ "8.1.5.P", "8.1.5.1.P", @@ -511,6 +522,8 @@ "8.1.5.4.P" ], "apac-nzl-ism-3-9": [ + "20.1.26.C.02", + "20.1.26.C.03", "23.4.13.C.01", "23.4.13.C.02", "23.4.13.C.03" @@ -537,9 +550,9 @@ }, "maturity": { "0": "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.", - "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network).", + "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cloud-based technologies are governed no differently from on-premise network assets (e.g., cloud-based technology is viewed as an extension of the corporate network). ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to ensure the architecture for cloud-based technologies supports applicable cybersecurity and data protection requirements.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -610,7 +623,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -638,8 +652,8 @@ "3.1.22", "NFO–PL-8" ], - "general-scf-dpmp-2025": [ - "7.1" + "general-nist-cswp-39": [ + "6.4" ], "general-shared-assessments-sig-2025": [ "N.2" @@ -663,9 +677,8 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-01", - "COS-02" + "emea-isr-cmo-2-0": [ + "Appendix A, 6.1" ], "emea-sau-cgiot-2024": [ "4-2-1", @@ -674,11 +687,6 @@ "emea-sau-ecc-1-2018": [ "4-2-3-2" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.4.3" - ], "apac-ind-sebi-2024": [ "PR.IP.S13" ], @@ -686,7 +694,10 @@ "8.1.2.7.PB", "9.2.3.11.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP51", "HML51" ], @@ -694,9 +705,12 @@ "HSUP43" ], "apac-nzl-ism-3-9": [ - "22.1.23.C.01", - "22.1.23.C.02", - "22.1.23.C.03", + "2.3.28.C.01", + "20.1.24.C.02", + "20.1.24.C.03", + "20.1.24.C.04", + "20.2.12.C.01", + "20.2.12.C.02", "23.1.54.C.01", "23.1.54.C.02", "23.1.56.C.01", @@ -722,7 +736,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ The cloud infrastructure incorporates a managed security zone to house cybersecurity and data protection tools.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to host security-specific technologies in a dedicated subnet.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -762,7 +776,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -810,20 +825,9 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-01", - "COS-02", - "COS-05" - ], - "emea-isr-cmo-1-0": [ - "9.2" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1750" - ], - "apac-nzl-ism-3-9": [ - "22.1.24.C.02" ] } }, @@ -845,7 +849,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure support for secure interoperability between components with Application Programming Interfaces (APIs).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -893,7 +897,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -924,20 +929,29 @@ "155.260(a)(6)" ], "emea-deu-c5-2020": [ - "PI-01" + "PI-01", + "PI-04" ], "emea-sau-cscc-1-2019": [ "1-3-2-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.4", + "mp.s.2" + ], "apac-ind-sebi-2024": [ "PR.AA.S17" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP52", "HML52" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP44" + ], + "apac-sgp-mas-trm-2021": [ + "6.4.1", + "6.4.4" ] } }, @@ -1024,11 +1038,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { "usa-federal-dow-zt-roadmap-1-1": [ + "3.4", "3.4.1" ] } @@ -1053,7 +1069,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the integrity of virtual machine images at all times.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure the integrity of virtual machine images at all times. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1095,12 +1111,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { - "emea-deu-c5-2020": [ - "PSS-11" + "apac-sgp-mas-trm-2021": [ + "11.4.3" ] } }, @@ -1122,7 +1139,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure multi-tenant owned or managed assets (physical and virtual) are designed and governed such that provider and customer (tenant) user access is appropriately segmented from other tenant users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1210,7 +1227,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -1259,13 +1277,9 @@ "52.204-21(b)(1)(iv)" ], "emea-deu-c5-2020": [ - "OPS-24" + "RB-23" ], - "emea-isr-cmo-1-0": [ - "10.1", - "11.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1529" ], "apac-jpn-ismap": [ @@ -1275,7 +1289,10 @@ "9.5.1.3.P", "9.5.1.4.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP53", "HML53" ], @@ -1358,9 +1375,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": { "general-iso-27001-2022": [ @@ -1381,13 +1398,28 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.1" ], + "emea-deu-c5-2020": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 5.1" + ], "apac-jpn-ismap": [ "6.3.1.1.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "apac-nzl-ism-3-9": [ + "20.1.21.C.03", "23.1.55.C.01", "23.1.55.C.02", "23.1.55.C.03" + ], + "americas-bmu-mba-coc-2020": [ + "5.11" ] } }, @@ -1409,7 +1441,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure Multi-Tenant Service Providers (MTSP) facilitate security event logging capabilities for its customers that are consistent with applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1454,7 +1486,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -1465,6 +1498,9 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "A1.2.1" ], + "emea-deu-c5-2020": [ + "RB-10" + ], "apac-nzl-ism-3-9": [ "23.5.11.C.01", "23.5.12.C.01", @@ -1490,7 +1526,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure Multi-Tenant Service Providers (MTSP) facilitate prompt forensic investigations in the event of a suspected or confirmed security incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1535,7 +1571,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -1611,7 +1648,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -1648,7 +1686,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud providers use secure protocols for the import, export and management of data in cloud-based Technology Assets, Applications and/or Services (TAAS).", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to ensure cloud providers use secure protocols for the import, export and management of data in cloud-based Technology Assets, Applications and/or Services (TAAS). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1681,7 +1719,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -1690,7 +1729,8 @@ ], "emea-deu-c5-2020": [ "PI-01", - "PI-02" + "PI-02", + "PI-03" ] } }, @@ -1752,14 +1792,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", - "crosswalks": { - "emea-deu-c5-2020": [ - "PSS-11" - ] - } + "crosswalks": {} }, { "control_id": "CLD-09", @@ -1785,9 +1822,9 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Geolocation requirements for sensitive/regulated data types identify restrictions on transfer of data to third-countries or international organizations.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to govern geolocation requirements for sensitive/regulated data types, including the transfer of data to third-countries or international organizations.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to control the location of cloud processing/storage based on business requirements that includes statutory, regulatory and contractual obligations.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to control the location of cloud processing/storage based on business requirements that includes statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cloud Security (CLD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cloud Security (CLD) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -1835,7 +1872,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -1911,14 +1949,8 @@ "SA-09 (05)" ], "emea-deu-c5-2020": [ - "PI-02", - "PSS-12" - ], - "emea-ken-pda-2019": [ - "25(h)" - ], - "emea-qat-pdppl-2020": [ - "15" + "UP-02", + "RB-03" ], "emea-sau-cscc-1-2019": [ "4-2-1-1" @@ -1927,43 +1959,26 @@ "4-1-3-2", "4-2-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-30" - ], - "apac-aus-privacy-principles-2026": [ - "APP 8" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1572" ], - "apac-chn-pipl-2021": [ - "38", - "39", - "40" - ], "apac-ind-sebi-2024": [ "PR.DS.S2" ], - "apac-jpn-ppi-2020": [ - "24(1)" + "apac-mys-bnm-rmit-2025": [ + "10.50" ], "apac-nzl-ism-3-9": [ + "20.1.22.C.01", + "20.1.22.C.02", + "20.1.22.C.03", + "20.1.22.C.04", + "20.1.22.C.05", + "20.1.22.C.06", "22.1.22.C.01", "22.1.22.C.02", - "22.1.22.C.03", - "22.1.22.C.04", - "22.1.22.C.05", - "22.1.22.C.06", "23.4.11.C.01", "23.4.11.C.02" - ], - "americas-arg-ppd-2018": [ - "12.1", - "12.2" - ], - "americas-bra-lgpd-2018": [ - "33", - "34" ] } }, @@ -1971,8 +1986,8 @@ "control_id": "CLD-10", "title": "Sensitive Data In Public Cloud Providers", "family": "CLD", - "description": "Mechanisms exist to limit and manage the storage of sensitive/regulated data in public cloud providers.", - "scf_question": "Does the organization limit and manage the storage of sensitive/regulated data in public cloud providers?", + "description": "Mechanisms exist to limit and manage the storage of sensitive and/or regulated data in public cloud providers.", + "scf_question": "Does the organization limit and manage the storage of sensitive and/or regulated data in public cloud providers?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1989,7 +2004,7 @@ "0": "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.", "1": "Cloud Security (CLD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CLD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cloud management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are documented and maintained by process owners.\n▪ 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 CLD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cloud management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cloud management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Cloud-based Technology Assets, Applications and/or Services (TAAS) are governed according to the same processes used for on-premises TAAS, where no formal, dedicated cloud governance process exists.", - "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to limit and manage the storage of sensitive/regulated data in public cloud providers.", + "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to limit and manage the storage of sensitive/regulated data in public cloud providers. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2035,7 +2050,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -2061,13 +2077,11 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(iv)" ], - "emea-isr-cmo-1-0": [ - "11.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 6.1" ], - "apac-nzl-ism-3-9": [ - "2.3.23.C.01", - "22.1.22.C.04", - "22.1.22.C.05" + "apac-mys-bnm-rmit-2025": [ + "10.50" ] } }, @@ -2089,7 +2103,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to utilize a Cloud Access Security Broker (CASB), or similar technology, to provide boundary protection and monitoring functions that both provide access to the cloud and protect the organization from misuse of cloud resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2125,7 +2139,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -2137,20 +2152,6 @@ ], "general-shared-assessments-sig-2025": [ "P.8" - ], - "emea-deu-c5-2020": [ - "COS-04" - ], - "emea-isr-cmo-1-0": [ - "9.10", - "11.8", - "16.4" - ], - "apac-nzl-ism-3-9": [ - "22.1.24.C.01", - "22.1.24.C.02", - "22.1.24.C.03", - "22.1.24.C.04" ] } }, @@ -2172,7 +2173,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to prevent \"side channel attacks\" when using a Content Delivery Network (CDN) by restricting access to the origin server's IP address to the CDN and an authorized management network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2212,7 +2213,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { @@ -2229,7 +2231,7 @@ "general-shared-assessments-sig-2025": [ "N.11" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1438", "ISM-1439" ] @@ -2253,7 +2255,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to specify applicable security, compliance and resilience that must be implemented on external Technology Assets, Applications and/or Services (TAAS), consistent with the contractual obligations established with the External Service Providers (ESP) owning, operating and/or maintaining external TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2323,9 +2325,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": { "general-nist-800-207": [ @@ -2351,7 +2353,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to authorize specified individuals to access External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2421,7 +2423,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": {} @@ -2430,8 +2433,8 @@ "control_id": "CLD-13.2", "title": "Sensitive / Regulated Data On Hosted Assets, Applications & Services", "family": "CLD", - "description": "Mechanisms exist to define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", - "scf_question": "Does the organization define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations?", + "description": "Mechanisms exist to define formal processes to store, process and/or transmit sensitive and/or regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", + "scf_question": "Does the organization define formal processes to store, process and/or transmit sensitive and/or regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -2444,7 +2447,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to define formal processes to store, process and/or transmit sensitive/regulated data using External Service Providers (ESP) owned, operated and/or maintained external Technology Assets, Applications and/or Services (TAAS), in accordance with all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2514,7 +2517,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": {} @@ -2537,7 +2541,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cloud Security (CLD) 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:\n▪ Policies and standards associated with CLD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CLD domain capabilities are well-documented and kept current by process owners.\n▪ A cloud governance team, or similar function, is appropriately staffed and supported to implement and maintain CLD domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cloud governance operations (e.g., multi-cloud governance tools, policy enforcement, cost management, etc.).\n▪ 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 CLD 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).\n▪ An implemented and operational capability exists to prohibit access to, or usage of, hosted Technology Assets, Applications and/or Services (TAAS) until applicable security, compliance and/or resilience control implementation is verified.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2607,9 +2611,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Cloud Security", "crosswalks": {} }, @@ -2618,7 +2622,7 @@ "title": "Software Defined Storage (SDS)", "family": "CLD", "description": "Automated mechanisms exist to utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization use automated mechanisms to utilize Software Defined Storage (SDS) to scale access management permissions to Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 3, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -2699,7 +2703,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cloud Security", "crosswalks": { diff --git a/docs/api/families/CPL.json b/docs/api/families/CPL.json index 399ce80c..68365ee3 100644 --- a/docs/api/families/CPL.json +++ b/docs/api/families/CPL.json @@ -1,7 +1,7 @@ { "family_code": "CPL", "family_name": "Compliance", - "control_count": 40, + "control_count": 41, "controls": [ { "control_id": "CPL-01", @@ -24,7 +24,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -127,7 +127,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -290,6 +291,10 @@ "03.04.11.a", "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]", + "A.03.12.01" + ], "general-nist-800-218": [ "PO.1", "PO.1.2" @@ -300,6 +305,11 @@ "GV.SC-05", "PR" ], + "general-nist-cswp-39": [ + "3.1.1", + "3.1.2", + "5.1" + ], "general-pci-dss-4-0-1": [ "12.4", "12.4.2", @@ -309,10 +319,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.2" ], - "general-scf-dpmp-2025": [ - "2.4", - "11.6" - ], "general-shared-assessments-sig-2025": [ "L.1" ], @@ -396,6 +402,18 @@ "PL-01", "PM-08" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(a)", + "101.620(b)(4)", + "101.620(b)(5)", + "101.650(b)", + "101.650(e)", + "101.650(e)(3)", + "101.650(f)", + "101.650(g)", + "101.650(h)", + "101.650(i)" + ], "usa-federal-law-ferpa-2010": [ "1232h(c)(1)(C)(i)" ], @@ -416,20 +434,20 @@ "155.260(e)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)", - "164.504(g)(1)", - "164.530(i)(1)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)", + "§ 164.504(g)(1)", + "§ 164.530(i)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(c)", - "164.306(d)(1)", - "164.306(d)(2)", - "164.314(a)(1)", - "164.314(a)(2)(ii)" + "§ 164.306(c)", + "§ 164.306(d)(1)", + "§ 164.306(d)(2)", + "§ 164.314(a)(1)", + "§ 164.314(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.E.6.1", @@ -483,6 +501,10 @@ "35(a)(1)", "37(a)(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.2(c)", + "603A.525.2(b)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(b)(6)", "500.2(d)", @@ -556,15 +578,30 @@ "Article 21.3", "Article 40.1" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 6", + "Article 6(a)", + "Article 6(b)", + "Article 12(1)(a)", + "Article 12(1)(b)", + "Article 19(7)", + "Article 23(1)", + "Article 23(1)(a)", + "Article 23(1)(b)", + "Article 24(2)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II" + ], "emea-eu-eba-ict-srm-2025": [ - "3.1(1)", - "3.8(92)", - "3.8(93)", - "3.8(94)", - "3.8(95)", - "3.8(96)", - "3.8(97)", - "3.8(98)" + "3.1.1", + "3.8.92", + "3.8.93", + "3.8.94", + "3.8.95", + "3.8.96", + "3.8.97", + "3.8.98" ], "emea-eu-dora-2023": [ "Article 4.1", @@ -575,96 +612,51 @@ "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3", - "29" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-eu-psd2-2015": [ + "97(3)" ], "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" + "3.4.76(5)", + "3.4.77" ], "emea-deu-bsrit-2017": [ - "12.5" + "2.1" ], "emea-deu-c5-2020": [ - "SP-01", + "SA-01-BP6", "PI-02", + "DLL-01-BP2", "COM-01" ], "emea-grc-pirppd-1997": [ - "10" - ], - "emea-hun-isdfi-2011": [ - "7" + "B.5.3" ], - "emea-irl-dpa-2003": [ - "2" + "emea-hun-act-cxii-2011": [ + "II.5.5(2)(b)", + "II.5.6(1)(a)", + "II.5.6(5)(a)" ], - "emea-isr-cmo-1-0": [ - "1.3" + "emea-irl-dpa-2018": [ + "s.83" ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "26", - "31", - "33", - "34", - "35" + "emea-ita-pdpc-2018": [ + "Article 1(1)" ], "emea-ken-pda-2019": [ - "4(a)", - "4(b)(i)", - "4(b)(ii)", - "51(1)", - "51(2)(a)", - "51(2)(b)", - "51(2)(c)", - "52(1)(a)", - "52(1)(b)", - "52(1)(c)", - "52(2)", - "52(3)", - "54", - "55(1)(a)", - "55(1)(b)", - "55(2)" + "IV.37(1)", + "IV.37(1)(a)", + "IV.37(1)(b)", + "IV.37(2)", + "IV.37(3)" ], "emea-nga-dpr-2019": [ "2.1(2)", "2.1(3)", "3.1(16)", - "4.1(1)", - "4.1(6)", - "4.1(7)" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" + "4.1(1)" ], "emea-qat-pdppl-2020": [ - "2" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" - ], - "emea-sau-cscc-1-2019": [ - "1-4" + "3.8" ], "emea-sau-cgiot-2024": [ "1-2-3", @@ -680,45 +672,26 @@ "Article 2.1", "Article 30.3" ], - "emea-sau-sacs-002-2022": [ - "TPC-20", - "TPC-21", - "TPC-43" - ], "emea-sau-sama-csf-1-2017": [ "3.2.2", - "3.2.3", - "3.3.13" + "3.2.2.1", + "3.2.2.1.a", + "3.2.2.1.b", + "3.2.2.1.c" ], "emea-srb-act-9-2018": [ - "5.1", - "13", - "49", - "59" - ], - "emea-zaf-popia-2013": [ - "2", - "3", - "9", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.1", - "Article 39" + "IV.1.49" ], "emea-esp-decree-311-2022": [ - "3.1", - "39" + "Article 37" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.5 [OP.PL.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "2.2.14.1.b", + "2.2.14.1.c", + "2.2.14.1.d" ], "emea-gbr-def-stan-05-138-2024": [ "0001", @@ -743,22 +716,18 @@ "0002", "2314" ], - "apac-aus-privacy-act-1998": [ - "APP Part 11" + "apac-aus-privacy-principles-2026": [ + "1.1.2.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0078", "ISM-0854" ], - "apac-aus-ps-cps-230-2023": [ - "28" + "apac-aus-cop-sitc-2020": [ + "5" ], - "apac-aus-ps-cps-234-2019": [ - "31", - "35", - "35(a)", - "35(b)", - "36" + "apac-aus-ps-cps-230-2023": [ + "12" ], "apac-chn-cybersecurity-law-2017": [ "Article 9", @@ -773,19 +742,11 @@ "Article 47" ], "apac-chn-data-security-law-2021": [ - "46" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "32", - "37", - "38(4)", - "42" + "Article 27", + "Article 32" ], "apac-hkg-pdo-2022": [ - "Principle 4" + "4" ], "apac-ind-dpdpa-2023": [ "7(c)", @@ -794,42 +755,17 @@ "8(1)", "8(4)" ], - "apac-ind-privacy-rules-2011": [ - "8" - ], "apac-ind-sebi-2024": [ "GV.OC.S2", "PR.IP.S13", "RS.MA.S5" ], - "apac-jpn-ppi-2020": [ - "20", - "21", - "22", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" + "apac-jpn-appi-2020": [ + "IV.1.16-2", + "IV.1.26(1)", + "IV.1.26(1)(i)", + "IV.1.26(1)(ii)", + "IV.1.26(2)" ], "apac-jpn-ismap": [ "4.4.2.1", @@ -846,10 +782,7 @@ "18.1.1.7.P", "18.1.5.7.PB" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP29", "HML29" ], @@ -861,47 +794,37 @@ "1.1.65.C.01", "1.1.66.C.01", "1.1.66.C.02", - "1.1.67.C.01" + "1.1.67.C.01", + "1.2.15.C.01", + "1.2.15.C.02", + "17.9.37.C.01" + ], + "apac-nzl-privacy-act-2020": [ + "6.2.126(1)", + "6.2.126(2)", + "6.2.126(2)(a)", + "6.2.126(2)(b)" ], "apac-phl-dpa-2012": [ - "25" + "III.11" ], "apac-sgp-pdpa-2012": [ - "24" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "3.1(a)", - "3.1(b)", - "3.1(c)" - ], - "apac-sgp-mas-trm-2021": [ - "3.2.3" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "27" - ], - "americas-arg-ppd-2018": [ - "10.1", - "10.2" + "3.11(2)" ], "americas-bhs-dpa-2003": [ - "6" + "II.4(1)", + "IV.24(6)", + "IV.24(7)", + "IV.24(7)(a)", + "IV.24(7)(b)", + "V.45(4)(a)", + "V.45(4)(b)", + "V.45(5)", + "V.45(6)", + "V.45(7)" ], "americas-bra-lgpd-2018": [ - "7.1", - "7.2", - "7.3", - "7.4", - "7.5", - "7.6", - "7.7", - "7.8", - "7.9", - "7.10" + "VII.I.46.2" ], "americas-can-osfi-b13-2022": [ "1.3.1" @@ -911,16 +834,13 @@ "03.12.01" ], "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" + "P1-4.1", + "P1-4.1.3" ], "americas-col-law-1581-2012": [ - "4" - ], - "americas-mex-fdpa-2010": [ - "19" + "VI.17", + "VI.17(o)", + "VI.18" ] } }, @@ -944,7 +864,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to document and review instances of non-compliance with statutory, regulatory and/or contractual obligations to develop appropriate risk mitigation actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1037,7 +957,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -1131,7 +1052,12 @@ "4.E(2)(b)" ], "general-nist-800-171-r3": [ - "03.12.02.a.01" + "03.12.02.a.01", + "03.12.02.a.02" + ], + "general-nist-800-171a-r3": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" ], "general-pci-dss-4-0-1": [ "12.4.2" @@ -1139,9 +1065,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.4.2" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-tisax-6-0-3": [ "1.5.1" ], @@ -1173,34 +1096,20 @@ "Article 20.1", "Article 41.5" ], + "emea-eu-eba-ict-srm-2025": [ + "3.3.6.27" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], + "emea-deu-c5-2020": [ + "SPN-02" + ], "emea-sau-cgiot-2024": [ "1-7-3" ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1" - ], - "apac-aus-ps-cps-230-2023": [ - "30", - "31" - ], - "apac-aus-ps-cps-234-2019": [ - "29", - "35", - "35(a)", - "35(b)", - "36" - ], - "apac-chn-pipl-2021": [ - "54" - ], - "apac-jpn-ppi-2020": [ - "40(1)", - "40(2)", - "40(3)" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], "apac-jpn-ismap": [ "4.6.1.1", @@ -1212,23 +1121,12 @@ "1.1.69.C.01", "1.1.69.C.02" ], - "apac-sgp-mas-trm-2021": [ - "3.2.3", - "4.5.2", - "4.5.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.10", - "6.14" - ], "americas-can-osfi-b13-2022": [ "1.3.1" ], "americas-can-itsp-10-171-2025": [ - "03.12.02.A.01" + "03.12.02.A.01", + "03.12.02.A.02" ] } }, @@ -1254,7 +1152,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to perform compliance scoping of control applicability for statutory, regulatory and/or contractual compliance obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to document and validate the scope of security, compliance and resilience controls that are determined to meet statutory, regulatory and/or contractual compliance obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1305,9 +1203,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -1363,9 +1261,8 @@ "03.04.11.a", "03.15.02.a.04" ], - "general-nist-800-172": [ - "3.11.5e", - "3.14.3e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]" ], "general-nist-800-218": [ "PO.1" @@ -1389,9 +1286,6 @@ "12.5.1", "12.5.2" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-tisax-6-0-3": [ "1.2.1" ], @@ -1399,6 +1293,12 @@ "RA.L3-3.11.5E", "SI.L3-3.14.3E" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.605(a)", + "101.605(b)", + "101.625(d)", + "101.630(d)(2)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7123(b)(2)", "7123(b)(3)" @@ -1421,16 +1321,19 @@ "emea-sau-pdpl-2023": [ "Article 2.2" ], - "emea-esp-boe-a-2022-7191": [ - "Article 38.2" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], - "emea-esp-decree-311-2022": [ - "38.2" + "emea-che-fadp-2025": [ + "2.2.14.1.a" ], "apac-jpn-ismap": [ "4.4.4", "4.4.4.1" ], + "americas-bmu-mba-coc-2020": [ + "5.11-BP3" + ], "americas-can-osfi-b13-2022": [ "1.3.1" ], @@ -1458,7 +1361,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1532,9 +1435,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -1550,9 +1453,6 @@ "general-iso-29100-2024": [ "6.12" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-dow-cert-rmm-1-2": [ "COMP:SG3.SP1", "COMP:SG3.SP2" @@ -1567,6 +1467,10 @@ "usa-federal-eo-14028": [ "4e(ii)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(6)", + "101.660" + ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "IV.C.1" ], @@ -1598,8 +1502,9 @@ "Article 22.3", "Article 22.3(a)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.13" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(1)", + "Article 32(5)" ], "emea-eu-gdpr-2016": [ "Article 5.2", @@ -1607,9 +1512,30 @@ "Article 30.4", "Article 31" ], + "emea-aut-dpa-2018": [ + "§ 37(3)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 29(5)" + ], + "emea-deu-c5-2020": [ + "UP-04", + "SPN-03-DOAR", + "COM-02-DOAR", + "COM-03-DOAR" + ], + "emea-ken-pda-2019": [ + "IV.32(1)" + ], + "emea-nga-dpr-2019": [ + "3.1(4)" + ], "emea-sau-pdpl-2023": [ "Article 30.4.a" ], + "emea-esp-decree-311-2022": [ + "Article 38(1)" + ], "apac-ind-sebi-2024": [ "PR.IP.S17" ], @@ -1617,6 +1543,9 @@ "4.5.4.3", "18.2.1.11.P", "18.2.1.12.P" + ], + "apac-mys-bnm-rmit-2025": [ + "16.6" ] } }, @@ -1638,7 +1567,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1737,9 +1666,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -1758,9 +1687,6 @@ "general-nist-600-1-gen-ai-profile": [ "MP-3.4-003" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-un-155-2021": [ "7.2.2.1", "7.2.2.2" @@ -1777,6 +1703,9 @@ "609.930(c)(6)(iii)", "609.935(c)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(g)(3)" + ], "usa-federal-law-sox-2002": [ "404(a)", "404(a)(2)", @@ -1808,28 +1737,67 @@ "Article 43.3", "Article 43.4" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.2", - "Article 10.7", - "Article 13.2(a)", - "Article 24.1", - "Article 24.1(a)", - "Article 24.1(b)", - "Article 24.1(c)" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.1" + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(3)", + "Article 13(12)", + "Article 19(2)(a)", + "Article 32(1)", + "Article 32(1)(a)", + "Article 32(1)(b)", + "Article 32(1)(c)", + "Article 32(1)(d)", + "Article 32(3)", + "Article 32(3)(a)", + "Article 32(3)(b)", + "Article 32(6)" ], "emea-eu-nis2-annex-2024": [ "2.2.1", "2.2.3" ], + "emea-nga-dpr-2019": [ + "4.1(5)", + "4.1(5)a", + "4.1(5)b", + "4.1(5)c", + "4.1(5)d", + "4.1(5)e", + "4.1(5)f", + "4.1(5)g", + "4.1(5)h", + "4.1(5)i", + "4.1(5)j" + ], + "emea-qat-pdppl-2020": [ + "3.11.7" + ], + "emea-esp-decree-311-2022": [ + "Article 31(1)", + "Article 31(2)", + "Article 31(3)", + "Article 31(4)", + "Article 31(5)", + "Article 31(7)" + ], "emea-gbr-caf-4-0": [ "A2.c" ], + "apac-aus-ps-cps-230-2023": [ + "28" + ], "apac-jpn-ismap": [ "4.5.4.3", "4.6.2.2" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "18.1" + ], + "americas-bmu-mba-coc-2020": [ + "5.7-BP3", + "5.11-BP3", + "6.10" ] } }, @@ -1851,7 +1819,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ A formal report is generated for each security assessment/audit with sufficient details to understand the organization's ability to demonstrate conformity with its requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to generate a declaration of conformity for each conformity assessment, where the document:\n(1) Is concise;\n(2) Unambiguously reflects the current status;\n(3) Is physically or electronically signed; and\n(4) Where possible, is machine readable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1923,7 +1891,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -1968,19 +1937,16 @@ "Article 47.3", "Article 47.4" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 4", - "Annex 4.1", - "Annex 4.2", - "Annex 4.3", - "Annex 4.4", - "Annex 4.5", - "Annex 4.6", - "Annex 4.7", - "Annex 4.8", - "Annex 6 Module A.4", - "Annex 6 Module A.4.2", - "Annex 6 Module C.3.2" + "emea-eu-cyber-resilience-act-2024": [ + "Article 12(1)(c)", + "Article 20(5)" + ], + "emea-esp-decree-311-2022": [ + "Article 38(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "8.2", + "18.2" ] } }, @@ -2002,7 +1968,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure individuals performing audits and/or assessments have reasonable:\n(1) Professional qualifications to perform the audit and/or assessment; and\n(2) Subject matter expertise to perform review, interview and test activities for in-scope People, Processes, Technologies, Data and/or Facilities (PPTDF).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2062,13 +2028,24 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Compliance", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(4)", + "101.630(f)(4)(i)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7122(a)(1)", "7122(d)" + ], + "apac-mys-bnm-rmit-2025": [ + "16.5" + ], + "apac-sgp-mas-trm-2021": [ + "15.1.4" ] } }, @@ -2090,10 +2067,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to designate an individual the authority to make statements of conformity on behalf of the organization.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define." + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to designate an individual the authority to make statements of conformity on behalf of the organization. ", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { @@ -2114,9 +2092,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (SOX)", "family_name": "Compliance", "crosswalks": { "usa-federal-law-sox-2002": [ @@ -2126,6 +2104,9 @@ "302(a)(4)(B)", "302(a)(4)(C)", "302(a)(4)(D)" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 18(1)" ] } }, @@ -2134,7 +2115,7 @@ "title": "Conformity Attestations", "family": "CPL", "description": "Mechanisms exist for the certifying official to attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria.", - "scf_question": "Does the organization's certifying official attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria", + "scf_question": "Does the organization have a certifying official attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2147,10 +2128,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists for the certifying official to attest to the accuracy of conformity attestations, based on applicable laws, regulations and/or contractual criteria.", - "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define." + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { @@ -2171,9 +2153,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (SOX)", "family_name": "Compliance", "crosswalks": { "usa-federal-law-sox-2002": [ @@ -2192,7 +2174,7 @@ "title": "Security, Compliance & Resilience Controls Oversight", "family": "CPL", "description": "Mechanisms exist to provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership.", - "scf_question": "Does the organization provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership?", + "scf_question": "Does the organization provide a security, compliance and resilience controls oversight function that reports to its executive leadership?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -2213,7 +2195,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.\n▪ A formal report is generated for each security assessment/audit with sufficient details to understand the organization's ability to demonstrate conformity with its requirements.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide a security, compliance and resilience controls oversight function that reports to the organization's executive leadership.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2305,9 +2287,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -2402,7 +2384,7 @@ "general-iso-31000-2018": [ "6.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -2695,10 +2677,19 @@ "3.12.3" ], "general-nist-800-171a-r3": [ + "A.03.12.01", "A.03.12.03[01]", "A.03.12.03[03]", "A.03.12.03[04]" ], + "general-nist-800-172-r3": [ + "03.12.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.03E[02]", + "DS-A.03.12.03E[03]", + "DS-A.03.12.03E[04]" + ], "general-nist-csf-2-0": [ "GV.OC-03" ], @@ -2717,9 +2708,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "11.4" - ], "general-tisax-6-0-3": [ "1.5.1", "5.2.6" @@ -2800,6 +2788,9 @@ "CA-07(01)", "PM-14" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(7)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(1)" ], @@ -2807,12 +2798,12 @@ "155.260(a)(3)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(2)(iii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.D.3", @@ -2865,122 +2856,42 @@ "2447(b)(8)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.1.11", + "3.3.3.19", + "3.3.6.25", + "3.4.6.41", + "3.4.6.46", + "3.4.6.48" ], "emea-eu-gdpr-2016": [ "Article 32.1(d)" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" - ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "SP-03" - ], - "emea-grc-pirppd-1997": [ - "10" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" + "RB-05-DOAR", + "SPN-02", + "COM-02" ], - "emea-isr-cmo-1-0": [ - "1.3", - "3.1" + "emea-isr-cmo-2-0": [ + "4.1, Stage 5" ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35" - ], - "emea-nga-dpr-2019": [ - "4.1(5)(a)", - "4.1(5)(b)", - "4.1(5)(c)", - "4.1(5)(d)", - "4.1(5)(e)", - "4.1(5)(f)", - "4.1(5)(g)", - "4.1(5)(h)", - "4.1(5)(i)", - "4.1(5)(j)", - "4.1(6)", - "4.1(7)" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" + "emea-qat-pdppl-2020": [ + "3.11.7" ], "emea-sau-cscc-1-2019": [ - "1-4" + "1-4-1" ], "emea-sau-cgiot-2024": [ "1-7-3" ], "emea-sau-ecc-1-2018": [ - "1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1" + "1-8-1", + "1-8-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.4" - ], - "emea-zaf-popia-2013": [ - "8", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1", - "Article 10.2", - "Article 10.3" + "3.2.5" ], "emea-esp-decree-311-2022": [ - "10.1", - "10.2", - "10.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "Article 16(1)" ], "emea-gbr-def-stan-05-138-2024": [ "1206" @@ -2991,42 +2902,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1206" ], - "apac-aus-privacy-act-1998": [ - "APP Part 11" - ], "apac-aus-ps-cps-230-2023": [ - "29", - "30", + "58", + "58(a)", "58(b)", "58(c)" ], "apac-aus-ps-cps-234-2019": [ - "27", - "27(a)", - "27(b)", - "27(c)", - "27(d)", - "27(e)", - "29" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "54" - ], - "apac-hkg-pdo-2022": [ - "Principle 4" - ], - "apac-ind-privacy-rules-2011": [ - "8" + "29", + "31" ], "apac-ind-sebi-2024": [ "EV.ST.S4" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "4.6.1.1", "4.6.2.2", @@ -3035,10 +2923,10 @@ "12.7.1.8", "12.7.1.9" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "13.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -3049,34 +2937,18 @@ "6.1.7.C.01", "23.2.18.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24" - ], "apac-sgp-mas-trm-2021": [ - "3.2.3" - ], - "apac-twn-pdpa-2025": [ - "27" + "3.2.3", + "15.1.1" ], "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.10" + "5.4", + "5.6", + "5.7-BP2" ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" ] } }, @@ -3101,7 +2973,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to implement an internal audit function that is capable of providing senior organization management with insights into the appropriateness of the organization's technology and information governance processes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3192,7 +3064,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -3285,7 +3158,8 @@ "03.12.01" ], "general-nist-800-171a-r3": [ - "A.03.12.01.ODP[01]" + "A.03.12.01.ODP[01]", + "A.03.12.01" ], "general-tisax-6-0-3": [ "1.5.1", @@ -3304,60 +3178,36 @@ "5.260.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.3.6(25)" + "3.3.1.11", + "3.3.6.25" ], "emea-eu-nis2-annex-2024": [ "2.3.2" ], + "emea-deu-c5-2020": [ + "SPN-03" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 5" + ], "emea-sau-cscc-1-2019": [ - "1-4-2", - "2-13-4" + "1-4-2" ], "emea-sau-ecc-1-2018": [ - "1-8-1", "1-8-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.5" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 41.1", - "Article 41.2" - ], - "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "41.1", - "41.2" + "3.2.5.1" ], "apac-aus-ps-cps-230-2023": [ - "46", - "60" + "46" ], "apac-aus-ps-cps-234-2019": [ - "31", "32", - "33", "34", "34(a)", "34(b)" ], - "apac-chn-pipl-2021": [ - "54" - ], "apac-ind-dpdpa-2023": [ "10(2)(b)" ], @@ -3365,7 +3215,10 @@ "4.6.2.2", "4.6.2.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "13.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -3374,19 +3227,7 @@ ], "apac-sgp-mas-trm-2021": [ "15.1.1", - "15.1.2", - "15.1.3", - "15.1.4" - ], - "americas-bmu-mba-coc-2020": [ - "5.4", - "5.6" - ], - "amaericas-can-osfi-self-assessment": [ - "6.17", - "6.18", - "6.19", - "6.20" + "15.1.2" ], "americas-can-itsp-10-171-2025": [ "03.12.01" @@ -3398,7 +3239,7 @@ "title": "Periodic Audits", "family": "CPL", "description": "Mechanisms exist to conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures.", - "scf_question": "Does the organization conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures?", + "scf_question": "Does the organization conduct periodic audits of security, compliance and resilience controls to evaluate conformity with its documented policies, standards and procedures?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -3411,17 +3252,23 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.\n▪ Specialized assessments are conducted for specific statutory, regulatory and/or contractual compliance obligations, as well as business-critical TAASD.\n▪ IT and/or cybersecurity use an impartial member of its team or a third-party assessor to perform an independent assessment of cybersecurity and data protection controls.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to conduct periodic audits of security, compliance and resilience controls to evaluate conformity with the organization's documented policies, standards and procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Annual self-assessment against applicable compliance requirements\n∙ External compliance review if contractually required", + "small": "∙ Annual internal review of key security controls\n∙ External audit for compliance requirements", + "medium": "∙ Internal audit program\n∙ Annual external compliance audits\n∙ GRC platform for audit tracking.", + "large": "∙ Enterprise internal audit function\n∙ Annual external audits.\n∙ GRC platform with audit management", + "enterprise": "∙ Enterprise internal audit program with dedicated resources\n∙ Multiple external compliance audits\n∙ Continuous control monitoring and automated audit reporting" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -3495,9 +3342,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-cobit-2019": [ @@ -3518,6 +3365,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(6)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(3)" + ], "usa-state-nv-regulation-5-2024": [ "5.260.5(b)" ], @@ -3528,9 +3378,22 @@ "2.3.2", "2.3.4" ], + "emea-deu-c5-2020": [ + "RB-05-DOAR", + "SPN-02", + "SPN-02-DOAR", + "COM-02", + "COM-02-BP1", + "COM-02-BP2", + "COM-02-BP3", + "COM-03" + ], "emea-sau-cgiot-2024": [ "1-7-1" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.5.2" + ], "emea-gbr-def-stan-05-138-2024": [ "1206" ], @@ -3545,6 +3408,17 @@ ], "apac-ind-sebi-2024": [ "DE.CM.S5" + ], + "apac-nzl-ism-3-9": [ + "17.9.33.C.01", + "17.9.33.C.02", + "17.9.33.C.03" + ], + "apac-sgp-mas-trm-2021": [ + "15.1.3" + ], + "americas-arg-ppd-2018": [ + "E.1.4-DS-2" ] } }, @@ -3566,7 +3440,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to take corrective action to remediate instances of non-conformity with applicable statutory, regulatory, and/or contractual compliance obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3576,7 +3450,13 @@ "CORE AI Model Deployment", "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Corrective action log (spreadsheet)\n∙ Documented remediation plans for audit findings", + "small": "∙ Corrective action register with remediation tracking\n∙ Management review of open findings", + "medium": "∙ Formal corrective action plan process\n∙ GRC platform for finding tracking and remediation\n∙ Management review of open findings", + "large": "∙ Enterprise corrective action management program\n∙ GRC platform with workflow-driven remediation tracking\n∙ Executive reporting on open findings", + "enterprise": "∙ Enterprise GRC platform for corrective action management\n∙ Automated finding tracking and escalation workflows\n∙ Board-level reporting on material findings" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -3650,13 +3530,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { "general-iso-29100-2024": [ "6.12" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(7)" + ], "emea-eu-ai-act-2024": [ "Article 79.4", "Article 80.4", @@ -3665,20 +3549,15 @@ "Article 93.1(a)", "Article 93.1(b)", "Article 93.1(c)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.12", - "Article 13.6", - "Article 14.4" ] } }, { "control_id": "CPL-03", - "title": "Security, Compliance & Resilience Assessments", + "title": "Control Conformity Monitoring", "family": "CPL", - "description": "Mechanisms exist to regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", - "scf_question": "Does the organization regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements?", + "description": "Mechanisms exist to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "scf_question": "Does the organization validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to its security, compliance and/or resilience policies, standards and other applicable requirements?", "relative_weight": 10, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -3696,7 +3575,7 @@ "0": "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.", "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments. \n▪ For specific statutory, regulatory and/or contractual obligations, stakeholders may contract with a third-party auditor/assessor to perform an independent assessment of cybersecurity and data protection controls.", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review processes and documented procedures to ensure conformity with the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to validate that Technology Assets, Applications, Services and/or Data (TAASD) conform to the organization's security, compliance and/or resilience policies, standards and other applicable requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3707,8 +3586,8 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", - "small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", + "micro_small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, SimpleRisk, etc.)", + "small": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, SimpleRisk, etc.)", "medium": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", "large": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)", "enterprise": "∙ Information Assurance Program (IAP)\n∙ Control Validation Testing (CVT) / Security Test & Evaluation (STE)\n∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)" @@ -3784,9 +3663,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", + "errata": "- renamed control\n- wordsmithed control", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -3917,10 +3797,8 @@ "03.12.03" ], "general-nist-800-171a-r3": [ - "A.03.12.01" - ], - "general-nist-800-172": [ - "3.11.5e" + "A.03.12.01", + "A.03.12.03[01]" ], "general-nist-csf-2-0": [ "ID.IM-01", @@ -3944,9 +3822,6 @@ "10.7.3", "12.4.2" ], - "general-scf-dpmp-2025": [ - "11.3" - ], "general-tisax-6-0-3": [ "1.5.2", "5.2.6" @@ -3981,16 +3856,20 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(1)", + "101.630(f)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.316(b)(1)(ii)" + "§ 164.306(d)(3)(i)", + "§ 164.316(b)(1)(ii)" ], "usa-federal-irs-1075-2021": [ "CA-2" @@ -4019,119 +3898,106 @@ "CA-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41", + "3.4.6.44" ], "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3", - "29" - ], "emea-deu-bsrit-2017": [ + "3.7", "5.6" ], "emea-deu-c5-2020": [ - "COM-03" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "3.1" + "OIS-01-BP2", + "OIS-01-BP3" ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-qat-pdppl-2020": [ - "11.7", - "11.8" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-sau-cscc-1-2019": [ - "1-4-1", - "2-13-4" + "emea-isr-cmo-2-0": [ + "4.2, Stage 5" ], "emea-sau-ecc-1-2018": [ "1-3-2", - "1-8-1" + "1-8-1", + "1-8-2", + "2-2-4" ], "emea-sau-otcc-1-2022": [ - "1-6", + "1-4-2", + "1-5-4", "1-6-1", - "1-6-2" + "1-7-2", + "2-1-2", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-7-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-1-9", + "2-13-2", + "3-1-2", + "4-1-2" ], "emea-sau-sama-csf-1-2017": [ "3.2.4", - "3.2.5" - ], - "emea-zaf-popia-2013": [ - "8", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7" + "3.2.4.1", + "3.2.4.2", + "3.2.4.3", + "3.2.4.4", + "3.2.4.5", + "3.2.4.5.a", + "3.2.4.5.b", + "3.2.4.5.c", + "3.3.1.2", + "3.3.2.2", + "3.3.3.2", + "3.3.4.2", + "3.3.5.2", + "3.3.5.3", + "3.3.6.2", + "3.3.6.3", + "3.3.7.2", + "3.3.7.3", + "3.3.8.2", + "3.3.8.3", + "3.3.9.2", + "3.3.9.3", + "3.3.10.2", + "3.3.10.3", + "3.3.11.2", + "3.3.11.3", + "3.3.14.2", + "3.3.14.4.i", + "3.3.14.4.l", + "3.3.15", + "3.3.15.2", + "3.3.16", + "3.3.16.2", + "3.3.17.2", + "3.4.1.2", + "3.4.1.3", + "3.4.2", + "3.4.2.2", + "3.4.3.2" ], "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7" + "Article 15(1)" ], - "apac-aus-ps-cps-234-2019": [ - "30" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], - "apac-chn-pipl-2021": [ - "38(1)", - "38(2)", - "40" + "apac-aus-ps-cps-230-2023": [ + "30" ], "apac-ind-sebi-2024": [ "EV.ST.S5" ], - "apac-jpn-ppi-2020": [ - "40(1)", - "40(2)", - "40(3)" - ], "apac-jpn-ismap": [ "4.6.2.3", "4.6.2.5", @@ -4154,8 +4020,9 @@ "18.2.2.7", "18.2.2.8" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "11.9", + "13.1" ], "apac-nzl-ism-3-9": [ "4.3.16.C.01", @@ -4163,24 +4030,27 @@ "6.1.9.C.01", "23.2.18.C.01" ], - "apac-phl-dpa-2012": [ - "25" + "apac-sgp-mas-trm-2021": [ + "4.5.1", + "9.1.6", + "11.2.8" ], - "apac-sgp-pdpa-2012": [ - "24" + "americas-arg-ppd-2018": [ + "E.1.4-DS-1" ], - "apac-sgp-mas-trm-2021": [ - "4.5.1" + "americas-bhs-dpa-2003": [ + "VI.55", + "VI.55(a)", + "VI.55(b)" ], - "amaericas-can-osfi-self-assessment": [ - "6.10" + "americas-bmu-mba-coc-2020": [ + "5.7", + "6.21", + "6.22" ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03" - ], - "americas-chl-act-19628-1999": [ - "7" ] } }, @@ -4290,9 +4160,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-cobit-2019": [ @@ -4372,6 +4242,10 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-07(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(f)(4)(ii)", + "101.630(f)(4)(iii)" + ], "usa-federal-irs-1075-2021": [ "CA-7(CE-1)" ], @@ -4387,26 +4261,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(c)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module H.3.1", - "Annex 6 Module H.3.5" - ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(25)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)(a)", - "3.4.6(43)(b)" + "3.3.6.25", + "3.4.6.41" ], "emea-eu-nis2-annex-2024": [ "2.3.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-c5-2020": [ - "COM-03" - ], "emea-sau-cscc-1-2019": [ "1-4-2" ], @@ -4417,26 +4278,9 @@ "1-8-2" ], "emea-sau-otcc-1-2022": [ - "1-6-1", "1-6-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-20", - "TPC-21" - ], - "emea-zaf-popia-2013": [ - "60" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 38.1" - ], - "emea-esp-decree-311-2022": [ - "38.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0100" ], "apac-aus-ps-cps-234-2019": [ @@ -4445,11 +4289,6 @@ "apac-chn-cybersecurity-law-2017": [ "Article 38" ], - "apac-chn-pipl-2021": [ - "38(1)", - "38(2)", - "40" - ], "apac-ind-dpdpa-2023": [ "10(2)(b)" ], @@ -4469,12 +4308,13 @@ "18.2.1.10.P", "18.2.1.13.P" ], + "apac-mys-bnm-rmit-2025": [ + "13.4", + "14.1", + "14.2" + ], "apac-nzl-ism-3-9": [ "6.1.8.C.01" - ], - "amaericas-can-osfi-self-assessment": [ - "6.13", - "6.25" ] } }, @@ -4483,7 +4323,7 @@ "title": "Functional Review Of Security, Compliance & Resilience Controls", "family": "CPL", "description": "Mechanisms exist to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards.", - "scf_question": "Does the organization regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards?", + "scf_question": "Does the organization regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to its security, compliance and/or resilience policies and standards?", "relative_weight": 8, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -4498,9 +4338,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel use an entity-defined set of controls to conduct cybersecurity and data protection control assessments.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for adherence to the organization's security, compliance and/or resilience policies and standards. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4591,9 +4431,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Compliance", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -4717,10 +4557,13 @@ "RA-3" ], "general-nist-800-171-r3": [ + "03.04.02.b", "03.04.08.c", "03.12.03" ], "general-nist-800-171a-r3": [ + "A.03.04.02.b[01]", + "A.03.04.08.c", "A.03.12.03[02]" ], "general-nist-csf-2-0": [ @@ -4791,14 +4634,14 @@ "RA-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(i)", - "164.306(e)", - "164.308(a)(8)" + "§ 164.306(d)(3)(i)", + "§ 164.306(e)", + "§ 164.308(a)(8)" ], "usa-federal-irs-1075-2021": [ "CA-2", @@ -4825,69 +4668,18 @@ "RA-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.6(26)", - "3.3.6(27)", - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" + "3.3.6.26", + "3.4.6.41" ], "emea-eu-nis2-2022": [ "Article 21.1" ], - "emea-us-psd2-2015": [ - "3" - ], "emea-deu-bsrit-2017": [ "5.6" ], - "emea-deu-c5-2020": [ - "COM-01" - ], - "emea-isr-cmo-1-0": [ - "3.1", - "3.3", - "12.30" - ], - "emea-qat-pdppl-2020": [ - "11.7", - "11.8" - ], - "emea-sau-cscc-1-2019": [ - "1-4-1" - ], "emea-sau-cgiot-2024": [ "1-7-1" ], - "emea-sau-ecc-1-2018": [ - "1-8-1" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 31.1", - "Article 31.2", - "Article 31.3", - "Article 31.4", - "Article 31.5", - "Article 31.6", - "Article 31.7", - "Article 38.1" - ], - "emea-esp-decree-311-2022": [ - "31.1", - "31.2", - "31.3", - "31.4", - "31.5", - "31.6", - "31.7", - "38.1" - ], "emea-gbr-def-stan-05-138-2024": [ "1206" ], @@ -4897,8 +4689,8 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1206" ], - "apac-chn-pipl-2021": [ - "54" + "apac-aus-ps-cps-234-2019": [ + "33" ], "apac-ind-sebi-2024": [ "DE.CM.S5" @@ -4917,12 +4709,14 @@ "23.2.18.C.01" ], "apac-sgp-mas-trm-2021": [ - "4.5.1" + "4.5.1", + "11.2.8" ], "americas-bmu-mba-coc-2020": [ - "5.7" + "5.7-BP1" ], "americas-can-itsp-10-171-2025": [ + "03.04.02.B", "03.04.08.C", "03.12.03" ] @@ -4946,7 +4740,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to grant assessors minimum necessary access to conduct conformity assessments, including:\n(1) Logical access to design, development, production, inspection and testing artifacts; and \n(2) Physical access to facilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5033,7 +4827,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -5049,13 +4844,6 @@ "IV.C.2.e.iii", "IV.C.2.e.iv", "IV.C.2.f" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 13.8", - "Article 14.5" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module H.4.2" ] } }, @@ -5077,7 +4865,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define acceptable methods to conduct a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5166,7 +4954,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -5189,7 +4978,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define the level of assessment rigor necessary to conduct a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5278,7 +5067,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -5301,7 +5091,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define an Evidence Request List (ERL) prior to the start of a cybersecurity and/or data protection assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5390,7 +5180,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -5413,7 +5204,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. \n▪ IT and/or cybersecurity personnel self-identify a set of controls that are used to conduct cybersecurity and data privacy control assessments. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define evidence sampling criteria for cybersecurity and/or data protection assessments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5502,11 +5293,126 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} }, + { + "control_id": "CPL-03.8", + "title": "Continuous Control Monitoring (CCM)", + "family": "CPL", + "description": "Automated mechanisms exist to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "scf_question": "Does the organization use automated mechanisms to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform Continuous Control Monitoring (CCM) to assess and report the conformity status of the organization’s Technology Assets, Applications, Services and Data (TAASD) against applicable security, compliance and resilience controls.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Periodic manual control reviews", + "small": "∙ GRC solution with control tracking\n∙ Regular control status reviews", + "medium": "∙ GRC platform with control monitoring\n∙ Regular automated control status reporting", + "large": "∙ GRC platform with continuous control monitoring\n∙ Integration with SIEM and vulnerability management\n∙ Automated control evidence collection", + "enterprise": "∙ Enterprise continuous control monitoring platform\n∙ Automated evidence collection and control testing\n∙ Real-time control dashboards\n∙ Integration with GRC, SIEM, and asset management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-1", + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Compliance", + "crosswalks": {} + }, { "control_id": "CPL-04", "title": "Audit Activities", @@ -5525,7 +5431,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to thoughtfully plan audits by including input from operational risk and compliance partners to minimize the impact of audit-related activities on business operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5590,7 +5496,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -5617,13 +5524,6 @@ ], "general-nist-100-1-ai-rmf": [ "GOVERN 1.5" - ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-deu-c5-2020": [ - "COM-02", - "COM-03" ] } }, @@ -5645,7 +5545,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with the organization's legal counsel for guidance on how to respond to legal orders (e.g., court orders, investigations, etc.).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to determine whether a government agency has an applicable and valid legal basis to request data from the organization and what further steps need to be taken, if necessary.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5732,7 +5632,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -5757,14 +5658,16 @@ "Article 92.4", "Article 92.5" ], - "emea-deu-c5-2020": [ - "INQ-01" - ], "apac-chn-cybersecurity-law-2017": [ "Article 72" ], - "apac-chn-pipl-2021": [ - "41" + "apac-sgp-pdpa-2012": [ + "3.12(d)", + "3.12(d)(i)", + "3.12(d)(ii)" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.2" ] } }, @@ -5786,7 +5689,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to notify customers about investigation request notifications, unless the applicable legal basis for a government agency's action prohibits notification (e.g., potential criminal prosecution).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5870,18 +5773,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { "general-csa-cmm-4-1-0": [ "DSP-18" ], - "emea-deu-c5-2020": [ - "INQ-02" - ], - "apac-chn-pipl-2021": [ - "18" + "apac-sgp-pdpa-2012": [ + "5.21(4)" ] } }, @@ -5903,7 +5804,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to support official investigations by provisioning government investigators with \"least privileges\" and \"least functionality\" to ensure that government investigators only have access to the TAASD needed to perform the investigation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5989,7 +5890,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -5999,6 +5901,9 @@ "usa-federal-doc-data-privacy-framework-2023": [ "III.5.b.ii" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(6)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(e)", "500.17(a)(2)" @@ -6012,23 +5917,21 @@ "emea-eu-ai-act-2024": [ "Article 21.2" ], - "emea-deu-c5-2020": [ - "INQ-03", - "INQ-04" + "emea-eu-cyber-resilience-act-2024": [ + "Article 53" + ], + "emea-aut-dpa-2018": [ + "§ 51", + "§ 52", + "§ 53" + ], + "emea-che-fadp-2025": [ + "2.2.15.2" ], "apac-chn-cybersecurity-law-2017": [ "Article 28", "Article 55", "Article 56" - ], - "apac-chn-pipl-2021": [ - "61(4)", - "63", - "63(1)", - "63(2)", - "63(3)", - "63(4)", - "64" ] } }, @@ -6050,7 +5953,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to constrain the host government from having unrestricted and non-monitored access to the organization's TAASD that could potentially violate other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6116,7 +6019,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -6125,24 +6029,11 @@ "Article 29" ], "apac-chn-data-security-law-2021": [ - "24", - "27", - "31", - "33", - "44" + "Article 27", + "Article 31" ], "apac-chn-pipl-2021": [ - "11", - "12", - "26", - "38(4)", - "40", - "47(5)", - "60", - "61(4)", - "63(3)", - "63(4)", - "64" + "Article 38" ] } }, @@ -6151,7 +6042,7 @@ "title": "Grievances", "family": "CPL", "description": "Mechanisms exist to govern the intake and analysis of grievances related to the organization's cybersecurity and/or data protection practices.", - "scf_question": "Does the organization govern the intake, analysis, assignment and remediation of grievances related to its cybersecurity and/or data protection practices?", + "scf_question": "Does the organization govern the intake and analysis of grievances related to its cybersecurity and/or data protection practices?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -6164,7 +6055,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6236,15 +6127,34 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(17)" + ], + "apac-aus-privacy-principles-2026": [ + "1.1.2.b" + ], "apac-ind-dpdpa-2023": [ "13(1)" ], + "apac-ind-privacy-rules-2011": [ + "5(9)" + ], + "apac-jpn-appi-2020": [ + "IV.5.52(1)", + "IV.5.52(2)", + "IV.5.52(3)" + ], "apac-jpn-ismap": [ "18.1.2.13.PB" + ], + "apac-mys-bnm-rmit-2025": [ + "10.35", + "12.8" ] } }, @@ -6266,7 +6176,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to respond to legitimate grievances related to the organization's cybersecurity and/or data protection practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6338,7 +6248,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -6365,7 +6276,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to appoint localized representation with a physical presence in localities, as required by applicable laws and/or regulations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6463,7 +6374,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -6474,12 +6386,19 @@ "Article 23.1(d)", "Article 54.1" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 12.1" + "emea-sau-ecc-1-2018": [ + "4-1-3-2" + ], + "emea-srb-act-9-2018": [ + "IV.1.44" + ], + "emea-che-fadp-2025": [ + "2.2.14.1", + "2.2.14.2", + "2.2.14.3" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" + "apac-chn-pipl-2021": [ + "Article 53" ] } }, @@ -6501,7 +6420,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to contract localized representation to perform specified functions in regard to representing statutory and/or regulatory compliance matters.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6599,7 +6518,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -6612,16 +6532,6 @@ "Article 54.3(d)", "Article 54.4", "Article 54.5" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 12.3", - "Article 12.3(a)", - "Article 12.3(b)", - "Article 12.3(c)" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module A.5", - "Annex 6 Module C.4" ] } }, @@ -6643,7 +6553,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define instances of control reciprocity within assessment boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6676,7 +6586,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -6699,7 +6610,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to define instances of control inheritance within assessment boundaries.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6732,7 +6643,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -6755,7 +6667,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern technologies and/or data that have potential:\n(1) \"Dual-use” capabilities for civil and military;\n(2) Use by terrorists; and/or \n(3) Weapons of Mass Destruction (WMD) applications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6831,7 +6743,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -6854,7 +6767,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify if the organization handles United States Munitions List (USML) or Commerce Control List (CCL):\n(1) Items;\n(2) Technical data; and/or\n(3) Provides defense services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6930,7 +6843,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -6953,7 +6867,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict logical and physical access to United States (US) export-controlled data to US: \n(1) Citizens; and/or\n(2) Green Card holders.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7029,7 +6943,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -7052,7 +6967,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to generate detailed logs of export-controlled data including:\n(1) Logical and physical access; and\n(2) Export activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7128,7 +7043,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Compliance", "crosswalks": {} @@ -7153,7 +7069,7 @@ }, "maturity": { "0": "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.", - "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.", + "1": "Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Compliance efforts are narrowly-limited to certain compliance requirements.\n▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce a Statement of Applicability (SOA), or similar document, for compliance-related scoping activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7179,7 +7095,8 @@ "MT-8", "MT-9", "MT-14", - "MT-15" + "MT-15", + "MT-28" ], "family_name": "Compliance", "crosswalks": { @@ -7206,7 +7123,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce work products (e.g., process artifacts) that demonstrate the ability to comply with applicable requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7231,9 +7148,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (CERT-RMM 1.2)", "family_name": "Compliance", "crosswalks": { "general-iso-21434-2021": [ @@ -7298,6 +7215,9 @@ "VAR:GG3.GP2", "GG1.GP1", "GG3.GP2" + ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.640" ] } }, @@ -7319,7 +7239,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce evidence of due diligence activities performed, capable of withstanding external audit or regulatory scrutiny.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7348,13 +7268,17 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control", "family_name": "Compliance", "crosswalks": { "apac-jpn-ismap": [ "4.6.2.7" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.21" ] } }, @@ -7376,7 +7300,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to produce evidence of due care activities performed, capable of withstanding external audit or regulatory scrutiny.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7405,9 +7329,9 @@ "MT-8", "MT-9", "MT-11", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control", "family_name": "Compliance", "crosswalks": { "apac-jpn-ismap": [ diff --git a/docs/api/families/CRY.json b/docs/api/families/CRY.json index adce5354..52f751fd 100644 --- a/docs/api/families/CRY.json +++ b/docs/api/families/CRY.json @@ -89,7 +89,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -107,7 +108,7 @@ "general-cis-csc-8-1": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-cis-csc-8-1-ig1": [ @@ -116,13 +117,13 @@ "general-cis-csc-8-1-ig2": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-cis-csc-8-1-ig3": [ "3.6", "3.9", - "3.1", + "3.10", "3.11" ], "general-csa-cmm-4-1-0": [ @@ -188,7 +189,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -267,6 +268,14 @@ "A.03.13.11.ODP[01]", "A.03.13.11" ], + "general-nist-800-172-r3": [ + "03.14.09E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.09E[01]", + "DS-A.03.14.09E[02]", + "DS-A.03.14.09E[03]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -311,9 +320,6 @@ "8.3.2", "12.3.3" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-sparta": [ "CM0050" ], @@ -376,16 +382,19 @@ "SC-08(02)", "SC-13" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iv)", - "164.312(e)(2)(ii)" + "§ 164.312(a)(2)(iv)", + "§ 164.312(e)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.E.2", @@ -431,7 +440,7 @@ "SC-13" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "emea-eu-gdpr-2016": [ "Article 32.1(a)" @@ -444,61 +453,57 @@ "9.2(a)", "9.2(b)" ], - "emea-us-psd2-2015": [ - "20", - "30" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-deu-fdpa-2017": [ + "3.2.48(2)7" ], "emea-deu-c5-2020": [ - "CRY-01" + "KRY-01", + "KRY-01-BP1", + "KRY-01-BP2", + "KRY-01-BP3", + "KRY-01-BP4", + "KRY-02" ], - "emea-isr-cmo-1-0": [ - "8.1", - "8.8", - "15.7", - "21.16" + "emea-isr-cmo-2-0": [ + "Appendix A, 3.1" ], "emea-sau-cscc-1-2019": [ - "2-7", + "2-7-1", "2-7-1-3" ], "emea-sau-ecc-1-2018": [ "2-8-1", "2-8-2", - "2-8-3", - "2-8-3-1", - "2-8-4" + "2-8-3-1" ], "emea-sau-otcc-1-2022": [ - "2-2-1-4", - "2-7", + "2-6-1", "2-7-1", "2-7-2" ], "emea-sau-sacs-002-2022": [ - "TPC-52", - "TPC-54" + "VII.B.TPC-54" ], "emea-sau-sama-csf-1-2017": [ - "3.3.9" - ], - "emea-zaf-popia-2013": [ - "14.1", - "19.1", - "19.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.2 [MP.COM.2]", - "8.4.3 [MP.COM.3]", - "8.5.2 [MP.SI.2]", - "8.7.3 [MP.INFO.3]", - "8.7.4 [MP.INFO.4]" + "3.3.9", + "3.3.9.1", + "3.3.9.4", + "3.3.9.4.a", + "3.3.9.4.b", + "3.3.9.4.c" + ], + "emea-esp-decree-311-2022": [ + "Article 12(6)(j)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" + ], + "emea-gbr-cap-1850-2020": [ + "B3" ], "emea-gbr-def-stan-05-138-2024": [ "2304", @@ -520,7 +525,7 @@ "2317", "2318" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0142", "ISM-0457", "ISM-0460", @@ -539,6 +544,7 @@ "ISM-1080", "ISM-1091", "ISM-1146", + "ISM-1233", "ISM-1446", "ISM-1629", "ISM-1759", @@ -582,7 +588,11 @@ "14.1.3.5", "14.1.3.6" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.22" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP37", "HML37" ], @@ -629,7 +639,6 @@ "17.4.16.C.01", "17.4.16.C.02", "17.5.6.C.01", - "17.6.6.C.01", "17.6.7.C.01", "17.7.6.C.01", "17.8.10.C.01", @@ -641,30 +650,20 @@ "17.8.15.C.01", "17.8.16.C.01", "17.8.17.C.01", - "17.9.24.C.01", - "17.9.24.C.02", - "17.9.24.C.03", - "17.9.25.C.01", - "17.9.26.C.01", - "17.9.26.C.02", - "17.9.27.C.01", - "17.9.27.C.02", - "17.9.27.C.03", - "17.9.28.C.01", - "17.9.29.C.01", "17.9.30.C.01", "17.9.30.C.02", + "17.9.30.C.03", "17.9.31.C.01", "17.9.32.C.01", "17.9.32.C.02", - "17.9.32.C.03" + "17.9.38.C.01", + "17.9.38.C.02" ], "apac-sgp-mas-trm-2021": [ + "6.4.5", "10.1.1", - "10.1.2", "10.1.3", - "10.1.4", - "10.1.5" + "10.1.4" ], "americas-bmu-mba-coc-2020": [ "6.22" @@ -672,6 +671,9 @@ "americas-can-osfi-b13-2022": [ "3.2.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.13.08", "03.13.11" @@ -698,9 +700,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of information as an alternative to physical safeguards.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of information as an alternative to physical safeguards. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -769,7 +771,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -820,6 +823,9 @@ "3.13.8[b]", "3.13.8[c]" ], + "general-nist-800-171a-r3": [ + "A.03.13.08[02]" + ], "general-nist-csf-2-0": [ "PR.DS-01" ], @@ -854,9 +860,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-08 (01)" ], - "emea-isr-cmo-1-0": [ - "15.7" - ], "americas-can-itsp-10-171-2025": [ "03.13.08" ] @@ -880,7 +883,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to address the exporting of cryptographic technologies in compliance with relevant statutory and regulatory requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -914,7 +917,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -1025,7 +1029,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to ensure the confidentiality and integrity of information during preparation for transmission and during reception.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1064,7 +1068,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -1095,7 +1100,7 @@ "usa-federal-cms-marse-2-0": [ "SC-8(2)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0548", "ISM-0554" ] @@ -1119,7 +1124,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to conceal or randomize communication patterns.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1155,7 +1160,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -1181,7 +1187,9 @@ "scf_question": "Does the organization identify, document and review deployed cryptographic cipher suites and protocols to proactively respond to industry trends regarding the continued viability of utilized cryptographic cipher suites and protocols?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", - "evidence_requests": [], + "evidence_requests": [ + "E-QTS-04" + ], "pptdf": "Process", "nist_csf_function": "Protect", "scrm_focus": { @@ -1191,7 +1199,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to identify, document and review deployed cryptographic cipher suites and protocols to proactively respond to industry trends regarding the continued viability of utilized cryptographic cipher suites and protocols.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1227,13 +1235,20 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { "general-nist-800-171-r3": [ "03.13.11" ], + "general-nist-800-171a-r3": [ + "A.03.13.11" + ], + "general-nist-cswp-39": [ + "3.1" + ], "general-pci-dss-4-0-1": [ "12.3.3" ], @@ -1246,6 +1261,17 @@ "emea-sau-cscc-1-2019": [ "2-7-1-3" ], + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.22" + ], + "apac-nzl-ism-3-9": [ + "17.9.34.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "10.1.2", + "10.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.13.11" ] @@ -1321,9 +1347,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Cryptographic Protections", "crosswalks": { "general-govramp": [ @@ -1420,13 +1446,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-07" - ], - "emea-isr-cmo-1-0": [ - "4.37", - "12.10" - ], - "emea-sau-ecc-1-2018": [ - "2-8-3-1" ] } }, @@ -1452,7 +1471,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Sensitive/regulated data is encrypted in transit according to standardized processes.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ Sensitive/regulated data is encrypted at rest using cryptographic protections that are commensurate with the sensitivity of the data.\n▪ Sensitive/regulated data is encrypted during transmission using cryptographic protections that are commensurate with the sensitivity of the data.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality of data being transmitted.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality of data being transmitted. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1508,7 +1527,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -1522,13 +1542,13 @@ "CC6.7-POF2" ], "general-cis-csc-8-1": [ - "3.1" + "3.10" ], "general-cis-csc-8-1-ig2": [ - "3.1" + "3.10" ], "general-cis-csc-8-1-ig3": [ - "3.1" + "3.10" ], "general-csa-cmm-4-1-0": [ "CEK-03", @@ -1580,7 +1600,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1090", @@ -1662,7 +1682,8 @@ "3.13.8" ], "general-nist-800-171-r3": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "general-nist-800-171a": [ "3.13.8[a]", @@ -1720,9 +1741,6 @@ "A2.1.1", "A2.1.2" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-swift-cscf-2025": [ "2.1", "2.5A", @@ -1772,14 +1790,17 @@ "SC-08", "SC-08(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(1)" + "§ 164.312(e)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.d", @@ -1797,6 +1818,9 @@ "usa-state-ma-201-cmr-17-2008": [ "17.04(3)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(a)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.15(a)" ], @@ -1813,24 +1837,11 @@ "2447(c)(5)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" - ], - "emea-us-psd2-2015": [ - "20", - "30" + "3.4.4.36(f)" ], "emea-deu-c5-2020": [ - "CRY-02" - ], - "emea-isr-cmo-1-0": [ - "4.22", - "8.4", - "8.5", - "8.6", - "9.8", - "9.20", - "12.10", - "13.6" + "KRY-02", + "KRY-02-DOAR" ], "emea-sau-cscc-1-2019": [ "2-3-1-5", @@ -1846,18 +1857,26 @@ "2-8-3-3" ], "emea-sau-otcc-1-2022": [ - "2-2-1-4" + "2-6-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-52", - "TPC-53" + "VII.B.TPC-52", + "VII.B.TPC-53" ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.1", + "mp.s.2" ], "emea-gbr-caf-4-0": [ "B3.b" ], + "emea-gbr-cap-1850-2020": [ + "B3" + ], "emea-gbr-def-stan-05-138-2024": [ "2302", "2306" @@ -1873,10 +1892,9 @@ "2302", "2306" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0231", "ISM-0232", - "ISM-0241", "ISM-0465", "ISM-0467", "ISM-0469", @@ -1896,11 +1914,19 @@ "ISM-1589", "ISM-1781" ], + "apac-aus-cop-sitc-2020": [ + "7" + ], "apac-ind-sebi-2024": [ "PR.DS.S1" ], + "americas-arg-ppd-2018": [ + "A.2.1", + "A.2.3-DS" + ], "americas-can-itsp-10-171-2025": [ - "03.13.08" + "03.13.08", + "03.13.11" ] } }, @@ -1926,7 +1952,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ Sensitive/regulated data is encrypted at rest using cryptographic protections that are commensurate with the sensitivity of the data.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity of data being transmitted.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity of data being transmitted. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1980,7 +2006,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -2028,7 +2055,7 @@ "8.24", "8.26" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1090", @@ -2159,10 +2186,10 @@ "SC-28(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(2)(i)" + "§ 164.312(e)(2)(i)" ], "usa-federal-irs-1075-2021": [ "SC-8", @@ -2180,32 +2207,23 @@ "SC-08", "SC-28 (01)" ], - "emea-us-psd2-2015": [ - "20", - "30" - ], - "emea-deu-c5-2020": [ - "OPS-09" - ], - "emea-isr-cmo-1-0": [ - "4.22", - "9.8", - "9.20", - "12.10", - "13.6" + "emea-sau-cscc-1-2019": [ + "2-3-1-5", + "2-7-1-1" ], "emea-sau-cgiot-2024": [ "2-4-1", "2-4-2", "2-4-3" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3", + "mp.info.4", + "mp.s.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0677" ], "apac-jpn-ismap": [ @@ -2235,7 +2253,7 @@ "0": "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.", "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of data at rest.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to prevent unauthorized disclosure of data at rest. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2291,7 +2309,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -2367,7 +2386,7 @@ "general-iso-27018-2025": [ "8.24" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -2481,7 +2500,8 @@ "3.13.16" ], "general-nist-800-171-r3": [ - "03.13.08" + "03.13.08", + "03.13.11" ], "general-nist-800-171a": [ "3.8.6" @@ -2523,9 +2543,6 @@ "3.5.1.3", "8.3.2" ], - "general-scf-dpmp-2025": [ - "7.2" - ], "general-swift-cscf-2025": [ "2.5A" ], @@ -2580,6 +2597,9 @@ "SC-28", "SC-28(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(2)" + ], "usa-federal-irs-1075-2021": [ "2.B.6-1", "3.3.1.e", @@ -2610,14 +2630,11 @@ "SC-28 (01)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(f)" + "3.4.4.36(f)" ], "emea-deu-c5-2020": [ - "CRY-03" - ], - "emea-isr-cmo-1-0": [ - "8.7", - "15.7" + "KRY-02", + "KRY-03" ], "emea-sau-cscc-1-2019": [ "2-7-1-2" @@ -2628,12 +2645,20 @@ "emea-sau-ecc-1-2018": [ "2-8-3-3" ], - "emea-zaf-popia-2013": [ - "14.1" + "emea-sau-otcc-1-2022": [ + "2-6-1-1" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "emea-gbr-caf-4-0": [ "B3.c" ], + "emea-gbr-cap-1850-2020": [ + "B3" + ], "emea-gbr-def-stan-05-138-2024": [ "2310", "2317" @@ -2650,7 +2675,7 @@ "2310", "2317" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0459", "ISM-1080" ], @@ -2663,8 +2688,12 @@ "apac-nzl-ism-3-9": [ "8.4.13.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.3" + ], "americas-can-itsp-10-171-2025": [ - "03.13.08" + "03.13.08", + "03.13.11" ] } }, @@ -2672,8 +2701,8 @@ "control_id": "CRY-05.1", "title": "Storage Media", "family": "CRY", - "description": "Cryptographic mechanisms exist to protect the confidentiality and integrity of sensitive/regulated data residing on storage media.", - "scf_question": "Are cryptographic mechanisms utilized to protect the confidentiality and integrity of sensitive/regulated data residing on storage media?", + "description": "Cryptographic mechanisms exist to protect the confidentiality and integrity of sensitive and/or regulated data residing on storage media.", + "scf_question": "Are cryptographic mechanisms utilized to protect the confidentiality and integrity of sensitive and/or regulated data residing on storage media?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2686,7 +2715,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of sensitive/regulated data residing on storage media.", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2741,7 +2770,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -2763,22 +2793,15 @@ "general-nist-800-171-r3": [ "03.13.08" ], + "general-nist-800-171a-r3": [ + "A.03.13.08[02]" + ], "general-pci-dss-4-0-1": [ "9.4" ], "general-swift-cscf-2025": [ "2.5A" ], - "emea-deu-c5-2020": [ - "CRY-03" - ], - "emea-isr-cmo-1-0": [ - "15.7" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8", - "2-3-1-9" - ], "apac-nzl-ism-3-9": [ "8.4.13.C.01" ], @@ -2872,7 +2895,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -2920,7 +2944,7 @@ }, "maturity": { "0": "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.", - "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.).", + "1": "Cryptographic Protections (CRY) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with CRY domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cryptography management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel provide an encryption solution (software or hardware) for the storage of sensitive/regulated data.\n▪ Databases containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information in the database (e.g., column-level, Transparent Data Encryption (TDE), etc.). ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure that database servers utilize encryption to protect the confidentiality of the data within the databases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2987,11 +3011,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1080", "ISM-1277" ] @@ -3066,7 +3091,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -3181,7 +3207,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -3258,6 +3285,9 @@ "general-nist-800-171-r3": [ "03.01.16.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -3324,21 +3354,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-18" ], - "emea-isr-cmo-1-0": [ - "4.22" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-4" - ], "emea-sau-sacs-002-2022": [ - "TPC-42" + "VII.B.TPC-42" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1314", "ISM-1332" ], "apac-nzl-ism-3-9": [ "18.2.9.C.01", + "18.2.9.C.02", "18.2.10.C.01", "18.2.10.C.02", "18.2.11.C.01", @@ -3388,9 +3413,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.\n▪ The IT department implements Public Key Infrastructure (PKI) key management controls to protect the confidentiality, integrity and availability of keys.\n▪ The IT department implements and maintains an internal PKI infrastructure or obtains PKI services from a reputable PKI service provider.\n▪ The PKI infrastructure enables the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes.\n▪ The PKI infrastructure ensures the availability of information in the event of the loss of cryptographic keys by individual users.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to securely implement an internal Public Key Infrastructure (PKI) infrastructure or obtain PKI services from a reputable PKI service provider. ", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3449,7 +3474,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -3489,7 +3515,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1072", "T1098.004", "T1521.003", @@ -3544,6 +3570,9 @@ "3.13.10[a]", "3.13.10[b]" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[01]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -3597,21 +3626,19 @@ "SC-12", "SC-17" ], - "emea-isr-cmo-1-0": [ - "8.2", - "8.9" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0485", - "ISM-1449" + "ISM-1449", + "ISM-2050" ], "apac-nzl-ism-3-9": [ "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03", "23.3.21.C.01", "23.3.22.C.01" ], + "americas-arg-ppd-2018": [ + "A.2.3" + ], "americas-can-itsp-10-171-2025": [ "03.13.10" ] @@ -3635,7 +3662,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of data in the event of the loss of cryptographic keys.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3701,7 +3728,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -3715,9 +3743,7 @@ "3.6.1" ], "apac-nzl-ism-3-9": [ - "17.1.51.C.01", - "17.1.51.C.02", - "17.1.51.C.03" + "17.1.51.C.01" ] } }, @@ -3742,7 +3768,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.\n▪ External compliance requirements for cryptography are identified and documented, based on applicable laws, regulations and contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement cryptographic mechanisms that are applicability for statutory, regulatory and/or contractual compliance obligations.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate cryptographic key management controls to protect the confidentiality, integrity and availability of keys.", "4": "Cryptographic Protections (CRY) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3830,7 +3856,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -3913,6 +3940,9 @@ "A.03.13.10[01]", "A.03.13.10[02]" ], + "general-nist-cswp-39": [ + "3.3" + ], "general-owasp-top-10-2025": [ "A04:2025" ], @@ -3992,21 +4022,26 @@ "9.3" ], "emea-deu-c5-2020": [ - "CRY-04" - ], - "emea-isr-cmo-1-0": [ - "8.2", - "8.9", - "8.10" + "KRY-03", + "KRY-04", + "KRY-04-BP1", + "KRY-04-BP3", + "KRY-04-BP4", + "KRY-04-BP5", + "KRY-04-BP6", + "KRY-04-BP7", + "KRY-04-BP8" ], "emea-sau-ecc-1-2018": [ "2-8-3-2" ], "emea-sau-sacs-002-2022": [ - "TPC-55" + "VII.B.TPC-55" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.11 [OP.EXP.11]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "emea-gbr-def-stan-05-138-2024": [ "2319" @@ -4020,7 +4055,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2319" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0455", "ISM-0507" ], @@ -4047,6 +4082,11 @@ "10.1.2.19", "10.1.2.20.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.20", + "10.21", + "10.23" + ], "apac-nzl-ism-3-9": [ "17.1.51.C.01", "17.1.58.C.01", @@ -4058,20 +4098,26 @@ "23.4.9.C.03" ], "apac-sgp-mas-trm-2021": [ + "6.4.5", "10.2.1", "10.2.2", "10.2.3", "10.2.4", "10.2.5", "10.2.6", - "10.2.7", "10.2.8", - "10.2.9", "10.2.10" ], + "americas-arg-ppd-2018": [ + "A.2.3" + ], "americas-can-osfi-b13-2022": [ "3.2.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.9.2", + "3.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.13.10" ] @@ -4097,9 +4143,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of symmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of symmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4162,7 +4208,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -4221,9 +4268,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of asymmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes that protect the user’s private key.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the production and management of asymmetric cryptographic keys using Federal Information Processing Standards (FIPS)-compliant key management technology and processes that protect the user’s private key. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4286,7 +4333,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -4333,9 +4381,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of information in the event of the loss of cryptographic keys by individual users.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure the availability of information in the event of the loss of cryptographic keys by individual users. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4417,7 +4465,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -4471,6 +4520,9 @@ "general-nist-800-171-r3": [ "03.13.10" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[02]" + ], "general-pci-dss-4-0-1": [ "2.3.2", "3.6.1", @@ -4501,17 +4553,21 @@ "emea-eu-nis2-annex-2024": [ "9.2(c)(v)" ], - "emea-isr-cmo-1-0": [ - "8.3", - "8.11" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0455", "ISM-0462" ], "apac-nzl-ism-3-9": [ - "7.2.24.C.01", - "7.2.25.C.01" + "7.2.24.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "10.2.7", + "10.2.9" ], "americas-can-itsp-10-171-2025": [ "03.13.10" @@ -4536,9 +4592,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to facilitate the secure distribution of symmetric and asymmetric cryptographic keys using industry recognized key management technology and processes. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4620,7 +4676,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -4645,6 +4702,9 @@ "general-nist-800-171-r3": [ "03.13.10" ], + "general-nist-800-171a-r3": [ + "A.03.13.10[02]" + ], "general-pci-dss-4-0-1": [ "3.6.1" ], @@ -4661,12 +4721,10 @@ "9.2(c)(iv)", "9.2(c)(v)" ], - "emea-isr-cmo-1-0": [ - "8.9", - "8.11" - ], - "apac-sgp-mas-trm-2021": [ - "10.2.5" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.10", + "mp.si.2", + "mp.info.3" ], "americas-can-itsp-10-171-2025": [ "03.13.10" @@ -4691,9 +4749,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure cryptographic keys are bound to individual identities.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure cryptographic keys are bound to individual identities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4755,7 +4813,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": {} @@ -4778,7 +4837,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to ensure customers are provided with appropriate key management guidance whenever cryptographic keys are shared.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4813,7 +4872,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -4846,7 +4906,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to maintain control of cryptographic keys for encrypted material stored or transmitted through an external system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4916,7 +4976,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -4953,9 +5014,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are documented and maintained by process owners.\n▪ 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 CRY domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Cryptographic management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Cryptographic management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Technology Assets, Applications and/or Services (TAAS) that store, process or transmit sensitive/regulated data use cryptographic mechanisms to prevent unauthorized disclosure of information as an alternate to physical safeguards.", - "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to associate Technology Assets, Applications and/or Services (TAAS) security attributes with information exchanged between TAAS.", + "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to associate Technology Assets, Applications and/or Services (TAAS) security attributes with information exchanged between TAAS. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5008,11 +5069,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1505", "T1505.002", "T1573", @@ -5069,7 +5131,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Cryptographic Protections (CRY) 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:\n▪ Policies and standards associated with CRY domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with CRY domain capabilities are well-documented and kept current by process owners.\n▪ A security engineering team, or similar function, is appropriately staffed and supported to implement and maintain CRY domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of cryptographic protections operations (e.g., PKI management tool, etc.).\n▪ 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 CRY 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).\n▪ An implemented and operational capability exists to automatically enable the use of organization-defined Certificate Authorities (CAs) to facilitate the establishment of protected sessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5138,7 +5200,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -5252,7 +5315,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { @@ -5326,13 +5390,11 @@ "MT-16", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Cryptographic Protections", "crosswalks": { - "general-nist-800-172": [ - "3.14.1e" - ], "usa-federal-dow-cmmc-2-level-3": [ "SI.L3-3.14.1E" ] diff --git a/docs/api/families/DCH.json b/docs/api/families/DCH.json index 6cce9239..47d524ea 100644 --- a/docs/api/families/DCH.json +++ b/docs/api/families/DCH.json @@ -25,7 +25,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ A basic data classification process exists to identify categories of sensitive/regulated data for compliance-related protection requirements.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of data protection controls.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of data protection controls. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -124,7 +124,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -153,10 +154,10 @@ "PI1.5-POF4" ], "general-cis-csc-8-1": [ - "3.0", + "3", "3.1", "3.3", - "11.0", + "11", "11.3" ], "general-cis-csc-8-1-ig1": [ @@ -317,6 +318,18 @@ "3.8.1[c]", "3.8.1[d]" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.08.01[01]", + "A.03.08.01[02]" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -358,9 +371,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.4.1" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "general-shared-assessments-sig-2025": [ "P.3" ], @@ -439,6 +449,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "MP-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(b)" + ], "usa-federal-sro-finra": [ "248.30(a)(2)(i)", "248.30(a)(2)(iii)" @@ -452,16 +465,16 @@ "155.260(a)(4)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(3)", - "164.310(d)(1)", - "164.312(c)(1)" + "§ 164.306(a)(3)", + "§ 164.310(d)(1)", + "§ 164.312(c)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.2", @@ -485,6 +498,9 @@ "usa-federal-dow-safeguarding-nnpi-2010": [ "9-2" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.3(b)", "500.18" @@ -504,128 +520,35 @@ "emea-eu-ai-act-2024": [ "Article 17.1(f)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-c5-2020": [ - "COS-08" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "5.2", - "5.3", - "5.5", - "11.6", - "15.1", - "15.6", - "15.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "AM-07", + "RB-23" ], "emea-sau-cscc-1-2019": [ - "2-6", + "2-6-1", "2-6-1-3" ], "emea-sau-ecc-1-2018": [ - "2-1-6", - "2-3-3", - "2-3-3-2", - "2-3-4", - "2-7-1", - "2-7-2", - "2-7-3", - "2-7-4", - "2-7-3-3" + "2-7-1" ], "emea-sau-otcc-1-2022": [ - "2-6", "2-6-1", - "2-6-1-1", "2-6-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-24", - "TPC-39", - "TPC-58" - ], - "emea-srb-act-9-2018": [ - "65" - ], - "emea-zaf-popia-2013": [ - "14.1", - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 22.1", - "Article 22.3" - ], "emea-esp-decree-311-2022": [ - "22.1", - "22.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" + "Article 22(3)" ], - "emea-che-fadp-2025": [ - "6", - "7" - ], - "emea-tur-lppd-2016": [ - "8", - "12" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.info.2" ], "emea-gbr-caf-4-0": [ "B3" ], - "emea-gbr-cap-1850-2020": [ - "B3" - ], "emea-gbr-def-stan-05-138-2024": [ "2300", "2308" @@ -639,45 +562,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2308" ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-privacy-principles-2026": [ - "APP 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0337", "ISM-0831", "ISM-1059", "ISM-1549", "ISM-1599" ], - "apac-aus-ps-cps-234-2019": [ - "20", - "21(a)" - ], "apac-chn-cybersecurity-law-2017": [ "Article 40" ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], "apac-ind-sebi-2024": [ "PR.AA.S14", "PR.DS.S4" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "5.1.1.10", "5.1.1.14", @@ -691,10 +589,7 @@ "13.2.1.13", "13.2.1.14" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HHSP34", "HHSP74", @@ -725,51 +620,24 @@ "13.2.6.C.01", "13.2.7.C.01" ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], "apac-sgp-mas-trm-2021": [ "11.1.1", - "11.1.1(a)", - "11.1.1(b)", - "11.1.1(c)", - "11.1.2", - "11.1.3", - "11.1.4", - "11.1.5", - "11.1.6", - "11.1.7" - ], - "apac-twn-pdpa-2025": [ - "21" + "11.1.2" ], "americas-bmu-mba-coc-2020": [ - "6.8", - "6.10", - "6.13" - ], - "americas-bra-lgpd-2018": [ - "46", - "47" + "5.3-BP3" ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.D.01", "03.01.01.D.02", "03.08.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" ] } }, @@ -796,7 +664,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data stewardship is assigned, documented and communicated.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data stewardship is assigned, documented and communicated. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -868,7 +736,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -918,6 +787,11 @@ "03.08.01", "03.08.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.05.a[01]" + ], "general-nist-csf-2-0": [ "ID.AM-08", "PR.DS" @@ -976,28 +850,16 @@ "usa-federal-irs-1075-2021": [ "SA-4(CE-12)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(b)" + ], "emea-deu-c5-2020": [ "AM-06" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], "emea-sau-ecc-1-2018": [ + "2-7-1", "2-7-3-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-39", - "TPC-58" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" - ], - "apac-jpn-ppi-2020": [ - "21" - ], - "apac-sgp-mas-trm-2021": [ - "3.3.1(c)" - ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.05.A" @@ -1008,8 +870,8 @@ "control_id": "DCH-01.2", "title": "Sensitive / Regulated Data Protection", "family": "DCH", - "description": "Mechanisms exist to protect sensitive/regulated data wherever it is processed and/or stored.", - "scf_question": "Does the organization protect sensitive/regulated data wherever it is processed and/or stored?", + "description": "Mechanisms exist to protect sensitive and/or regulated data wherever it is processed and/or stored.", + "scf_question": "Does the organization protect sensitive and/or regulated data wherever it is processed and/or stored?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1026,7 +888,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data wherever it is processed and/or stored.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1067,7 +929,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -1135,8 +998,27 @@ "03.08.05.a", "03.17.01.c" ], - "general-nist-800-172": [ - "3.14.5e" + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.d", + "A.03.06.05.d", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.08.05.a[02]", + "A.03.17.01.c" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -1188,12 +1070,12 @@ "52.204-21(b)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(1)", - "164.514(d)(3)(i)", - "164.530(c)(2)(i)" + "§ 164.312(c)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.530(c)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(1)" + "§ 164.312(c)(1)" ], "usa-federal-irs-1075-2021": [ "2.C.5", @@ -1247,6 +1129,9 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(g)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.215.2(b)" + ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.18" ], @@ -1261,27 +1146,29 @@ "usa-state-vt-act-171-2018": [ "2447(b)(3)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-deu-c5-2020": [ + "AM-07", + "RB-11" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" + ], + "emea-sau-cscc-1-2019": [ + "2-6-1-1", + "2-6-1-3" + ], + "emea-sau-ecc-1-2018": [ + "2-7-1" ], "emea-sau-otcc-1-2022": [ - "2-6-1-1" + "2-1-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-24", - "TPC-39", - "TPC-58" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 22.1", - "Article 22.3" + "VII.B.TPC-39", + "VII.B.TPC-58" ], "emea-esp-decree-311-2022": [ - "22.1", - "22.3" - ], - "emea-gbr-cap-1850-2020": [ - "B3" + "Article 22(3)" ], "emea-gbr-def-stan-05-138-2024": [ "2308" @@ -1292,10 +1179,13 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2308" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1802" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HHSP74", "HML14", @@ -1306,8 +1196,25 @@ "HSUP66" ], "apac-nzl-ism-3-9": [ + "16.2.7.C.01", + "16.2.7.C.02", "18.6.8.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.1(a)", + "11.1.1(b)", + "11.1.1(c)", + "11.1.6" + ], + "americas-bhs-dpa-2003": [ + "V.46(1)", + "V.46(2)", + "V.46(2)(a)", + "V.46(2)(b)" + ], + "americas-bmu-mba-coc-2020": [ + "6.13" + ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" @@ -1332,8 +1239,8 @@ "control_id": "DCH-01.3", "title": "Sensitive / Regulated Media Records", "family": "DCH", - "description": "Mechanisms exist to ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", - "scf_question": "Does the organization ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident?", + "description": "Mechanisms exist to ensure media records for sensitive and/or regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", + "scf_question": "Does the organization ensure media records for sensitive and/or regulated data contain sufficient information to determine the potential impact in the event of a data loss incident?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1348,7 +1255,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure media records for sensitive/regulated data contain sufficient information to determine the potential impact in the event of a data loss incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1437,7 +1344,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -1447,12 +1355,12 @@ "general-nist-800-171-r3": [ "03.08.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.c" + ], "general-nist-csf-2-0": [ "PR.DS" ], - "general-scf-dpmp-2025": [ - "5.2" - ], "apac-jpn-ismap": [ "8.2.3.3", "8.2.3.4", @@ -1467,8 +1375,8 @@ "control_id": "DCH-01.4", "title": "Defining Access Authorizations for Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data.", - "scf_question": "Does the organization explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data?", + "description": "Mechanisms exist to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive and/or regulated data.", + "scf_question": "Does the organization explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive and/or regulated data?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1484,7 +1392,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to explicitly define authorizations for specific individuals and/or roles for logical and /or physical access to sensitive/regulated data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1559,7 +1467,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -1608,9 +1517,27 @@ "03.17.01.c" ], "general-nist-800-171a-r3": [ + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", "A.03.15.02.c", "A.03.17.01.c" ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.b", + "A.03.01.17E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -1627,14 +1554,24 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "5.0" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.630(b)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(4)(ii)" ], "usa-federal-dow-safeguarding-nnpi-2010": [ "9-2.a" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-sau-cscc-1-2019": [ + "2-6-1-1", + "2-6-1-3" + ], + "emea-sau-ecc-1-2018": [ + "2-7-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-39" ], "emea-gbr-def-stan-05-138-2024": [ "2301" @@ -1648,6 +1585,13 @@ "apac-jpn-ismap": [ "8.2.3.2" ], + "apac-sgp-mas-trm-2021": [ + "11.1.6" + ], + "americas-arg-ppd-2018": [ + "B.1.3-2", + "B.2.1-2" + ], "americas-can-itsp-10-171-2025": [ "03.01.02", "03.01.03", @@ -1681,9 +1625,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to categorize data in accordance with organizational policies and standards.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure data and assets are categorized in accordance with applicable statutory, regulatory and contractual requirements. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1758,7 +1702,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -1831,6 +1776,18 @@ "03.08.01", "03.08.04" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.04[01]" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -1865,9 +1822,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.4.2" ], - "general-scf-dpmp-2025": [ - "1.2" - ], "general-sparta": [ "CM0001" ], @@ -1911,10 +1865,9 @@ "Article 17.1(f)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(17)", - "3.3.3(18)", - "3.3.3(19)", - "3.5(54)" + "3.3.3.17", + "3.3.3.18", + "3.5.54" ], "emea-eu-nis2-annex-2024": [ "2.1.3", @@ -1923,20 +1876,23 @@ ], "emea-deu-bsrit-2017": [ "7.13", - "7.14", - "12.4" + "7.14" ], "emea-deu-c5-2020": [ "AM-02", + "AM-05", "AM-06", - "COS-08", - "PI-01" + "PI-01", + "SIM-02" ], - "emea-isr-cmo-1-0": [ - "5.3", - "15.2" + "emea-hun-act-cxii-2011": [ + "II.4.4(3)" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" ], "emea-sau-cscc-1-2019": [ + "2-6-1-1", "2-6-1-2" ], "emea-sau-cgiot-2024": [ @@ -1945,33 +1901,23 @@ "emea-sau-ecc-1-2018": [ "2-1-5", "2-7-3-2", + "2-7-3-3", "4-2-3-1" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-1" - ], "emea-sau-sacs-002-2022": [ - "TPC-24" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 40.1", - "Article 40.2", - "Article 41.2" + "VII.B.TPC-24" ], "emea-esp-decree-311-2022": [ - "40.1", - "40.2", - "41.2" + "Article 40(1)" ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.2 [MP.INFO.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1", + "mp.info.2" ], "emea-gbr-caf-4-0": [ "B3.a" ], - "emea-gbr-cap-1850-2020": [ - "B3" - ], "emea-gbr-def-stan-05-138-2024": [ "2301" ], @@ -1981,7 +1927,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0270", "ISM-0271", "ISM-0272", @@ -1990,9 +1936,11 @@ "ISM-0323", "ISM-0393" ], + "apac-aus-ps-cps-230-2023": [ + "36" + ], "apac-aus-ps-cps-234-2019": [ - "20", - "21(a)" + "20" ], "apac-ind-sebi-2024": [ "PR.DS.S2" @@ -2010,7 +1958,7 @@ "8.2.1.9", "8.2.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HML34" ], "apac-nzl-hisf-suppliers-2023": [ @@ -2024,20 +1972,34 @@ "12.3.7.C.01", "18.6.8.C.01" ], + "apac-sgp-pdpa-2012": [ + "4.1.13", + "5.21(6)(b)", + "5.22(7)" + ], "apac-sgp-mas-trm-2021": [ "3.3.1(b)" ], "americas-bmu-mba-coc-2020": [ + "5.3-BP2", + "5.9-BP2", "6.8" ], "americas-can-osfi-b13-2022": [ "2.2.2", "3.1.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4", + "3.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.04.11.A", "03.08.01", "03.08.04" + ], + "americas-col-law-1581-2012": [ + "III.5" ] } }, @@ -2059,7 +2021,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ TAASD are categorized according to data classification and business criticality.\n▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to categorize data in accordance with organizational policies and standards.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that Technology Assets, Applications and/or Services (TAAS) are classified according to the highest level of data sensitivity that is stored, transmitted and/or processed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2128,7 +2090,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -2156,13 +2119,7 @@ "emea-sau-cscc-1-2019": [ "2-6-1-1" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-24" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0323", "ISM-0325" ], @@ -2194,9 +2151,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to control and restrict access to digital and non-digital media to authorized individuals.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to control and restrict access to digital and non-digital media to authorized individuals. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2284,7 +2241,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -2369,6 +2327,10 @@ "3.8.2" ], "general-nist-800-171a-r3": [ + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", "A.03.08.02" ], "general-nist-csf-2-0": [ @@ -2397,10 +2359,10 @@ "MP-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MP-2" @@ -2417,8 +2379,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-02" ], - "emea-sau-sacs-002-2022": [ - "TPC-39" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2301" @@ -2440,8 +2404,8 @@ "control_id": "DCH-03.1", "title": "Disclosure of Information", "family": "DCH", - "description": "Mechanisms exist to restrict the disclosure of sensitive/regulated data to authorized parties with a need to know.", - "scf_question": "Does the organization restrict the disclosure of sensitive/regulated data to authorized parties with a need to know?", + "description": "Mechanisms exist to restrict the disclosure of sensitive and/or regulated data to authorized parties with a need to know.", + "scf_question": "Does the organization restrict the disclosure of sensitive and/or regulated data to authorized parties with a need to know?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2454,7 +2418,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the disclosure of sensitive/regulated data to authorized parties with a need to know.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2536,7 +2500,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -2595,6 +2560,7 @@ "03.17.01.c" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", "A.03.15.02.c", "A.03.17.01.c" ], @@ -2630,130 +2596,130 @@ "1232h(c)(1)(B)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.510(b)(1)(i)", - "164.510(b)(1)(ii)", - "164.510(b)(2)", - "164.510(b)(4)", - "164.510(b)(5)", - "164.512", - "164.512(a)(1)", - "164.512(c)(1)", - "164.512(c)(1)(i)", - "164.512(c)(1)(ii)", - "164.512(c)(1)(iii)(A)", - "164.512(c)(1)(iii)(B)", - "164.512(c)(2)", - "164.512(c)(2)(i)", - "164.512(c)(2)(ii)", - "164.512(d)(1)", - "164.512(d)(1)(i)", - "164.512(d)(1)(ii)", - "164.512(d)(1)(iii)", - "164.512(d)(1)(iv)", - "164.512(e)(1)", - "164.512(e)(1)(i)", - "164.512(e)(1)(ii)", - "164.512(e)(1)(ii)(A)", - "164.512(e)(1)(ii)(B)", - "164.512(e)(1)(iii)", - "164.512(e)(1)(iii)(A)", - "164.512(e)(1)(iii)(B)", - "164.512(e)(1)(iii)(C)", - "164.512(e)(1)(iii)(C)(1)", - "164.512(e)(1)(iii)(C)(2)", - "164.512(e)(1)(iv)", - "164.512(e)(1)(iv)(A)", - "164.512(e)(1)(iv)(B)", - "164.512(e)(1)(v)", - "164.512(e)(1)(v)(A)", - "164.512(e)(1)(v)(B)", - "164.512(e)(1)(vi)", - "164.512(f)", - "164.512(f)(1)", - "164.512(f)(1)(i)", - "164.512(f)(1)(ii)(A)", - "164.512(f)(1)(ii)(B)", - "164.512(f)(1)(ii)(C)", - "164.512(f)(1)(ii)(C)(1)", - "164.512(f)(1)(ii)(C)(2)", - "164.512(f)(1)(ii)(C)(3)", - "164.512(f)(2)", - "164.512(f)(2)(i)(A)", - "164.512(f)(2)(i)(B)", - "164.512(f)(2)(i)(C)", - "164.512(f)(2)(i)(D)", - "164.512(f)(2)(i)(E)", - "164.512(f)(2)(i)(F)", - "164.512(f)(2)(i)(G)", - "164.512(f)(2)(i)(H)", - "164.512(f)(2)(ii)", - "164.512(f)(3)", - "164.512(f)(3)(i)", - "164.512(f)(3)(ii)", - "164.512(f)(3)(ii)(A)", - "164.512(f)(3)(ii)(B)", - "164.512(f)(3)(ii)(C)", - "164.512(f)(4)", - "164.512(f)(5)", - "164.512(f)(6)(i)", - "164.512(f)(6)(i)(A)", - "164.512(f)(6)(i)(B)", - "164.512(f)(6)(i)(C)", - "164.512(f)(6)(ii)", - "164.512(g)(1)", - "164.512(g)(2)", - "164.512(h)", - "164.512(i)(1)", - "164.512(j)(1)", - "164.514(d)(3)(i)", - "164.514(d)(3)(ii)(A)", - "164.514(d)(3)(ii)(B)", - "164.514(d)(3)(iii)", - "164.514(d)(3)(iii)(A)", - "164.514(d)(3)(iii)(B)", - "164.514(d)(3)(iii)(C)", - "164.514(d)(3)(iii)(D)", - "164.514(d)(4)", - "164.514(d)(4)(i)", - "164.514(d)(4)(ii)", - "164.514(d)(4)(iii)(A)", - "164.514(d)(4)(iii)(B)", - "164.514(d)(5)", - "164.514(e)(1)", - "164.514(e)(2)", - "164.514(e)(2)(i)", - "164.514(e)(2)(ii)", - "164.514(e)(2)(iii)", - "164.514(e)(2)(iv)", - "164.514(e)(2)(v)", - "164.514(e)(2)(vi)", - "164.514(e)(2)(vii)", - "164.514(e)(2)(viii)", - "164.514(e)(2)(ix)", - "164.514(e)(2)(x)", - "164.514(e)(2)(xi)", - "164.514(e)(2)(xii)", - "164.514(e)(2)(xiii)", - "164.514(e)(2)(xiv)", - "164.514(e)(2)(xv)", - "164.514(e)(2)(xvi)", - "164.514(e)(3)(i)", - "164.514(e)(3)(ii)", - "164.514(e)(4)(i)", - "164.514(e)(4)(ii)", - "164.514(e)(4)(ii)(A)", - "164.514(e)(4)(ii)(B)", - "164.514(e)(4)(ii)(C)", - "164.514(e)(4)(ii)(C)(1)", - "164.514(e)(4)(ii)(C)(2)", - "164.514(e)(4)(ii)(C)(3)", - "164.514(e)(4)(ii)(C)(4)", - "164.514(e)(4)(ii)(C)(5)", - "164.532(a)", - "164.532(b)", - "164.532(c)", - "164.532(c)(1)", - "164.532(d)" + "§ 164.510(b)(1)(i)", + "§ 164.510(b)(1)(ii)", + "§ 164.510(b)(2)", + "§ 164.510(b)(4)", + "§ 164.510(b)(5)", + "§ 164.512", + "§ 164.512(a)(1)", + "§ 164.512(c)(1)", + "§ 164.512(c)(1)(i)", + "§ 164.512(c)(1)(ii)", + "§ 164.512(c)(1)(iii)(A)", + "§ 164.512(c)(1)(iii)(B)", + "§ 164.512(c)(2)", + "§ 164.512(c)(2)(i)", + "§ 164.512(c)(2)(ii)", + "§ 164.512(d)(1)", + "§ 164.512(d)(1)(i)", + "§ 164.512(d)(1)(ii)", + "§ 164.512(d)(1)(iii)", + "§ 164.512(d)(1)(iv)", + "§ 164.512(e)(1)", + "§ 164.512(e)(1)(i)", + "§ 164.512(e)(1)(ii)", + "§ 164.512(e)(1)(ii)(A)", + "§ 164.512(e)(1)(ii)(B)", + "§ 164.512(e)(1)(iii)", + "§ 164.512(e)(1)(iii)(A)", + "§ 164.512(e)(1)(iii)(B)", + "§ 164.512(e)(1)(iii)(C)", + "§ 164.512(e)(1)(iii)(C)(1)", + "§ 164.512(e)(1)(iii)(C)(2)", + "§ 164.512(e)(1)(iv)", + "§ 164.512(e)(1)(iv)(A)", + "§ 164.512(e)(1)(iv)(B)", + "§ 164.512(e)(1)(v)", + "§ 164.512(e)(1)(v)(A)", + "§ 164.512(e)(1)(v)(B)", + "§ 164.512(e)(1)(vi)", + "§ 164.512(f)", + "§ 164.512(f)(1)", + "§ 164.512(f)(1)(i)", + "§ 164.512(f)(1)(ii)(A)", + "§ 164.512(f)(1)(ii)(B)", + "§ 164.512(f)(1)(ii)(C)", + "§ 164.512(f)(1)(ii)(C)(1)", + "§ 164.512(f)(1)(ii)(C)(2)", + "§ 164.512(f)(1)(ii)(C)(3)", + "§ 164.512(f)(2)", + "§ 164.512(f)(2)(i)(A)", + "§ 164.512(f)(2)(i)(B)", + "§ 164.512(f)(2)(i)(C)", + "§ 164.512(f)(2)(i)(D)", + "§ 164.512(f)(2)(i)(E)", + "§ 164.512(f)(2)(i)(F)", + "§ 164.512(f)(2)(i)(G)", + "§ 164.512(f)(2)(i)(H)", + "§ 164.512(f)(2)(ii)", + "§ 164.512(f)(3)", + "§ 164.512(f)(3)(i)", + "§ 164.512(f)(3)(ii)", + "§ 164.512(f)(3)(ii)(A)", + "§ 164.512(f)(3)(ii)(B)", + "§ 164.512(f)(3)(ii)(C)", + "§ 164.512(f)(4)", + "§ 164.512(f)(5)", + "§ 164.512(f)(6)(i)", + "§ 164.512(f)(6)(i)(A)", + "§ 164.512(f)(6)(i)(B)", + "§ 164.512(f)(6)(i)(C)", + "§ 164.512(f)(6)(ii)", + "§ 164.512(g)(1)", + "§ 164.512(g)(2)", + "§ 164.512(h)", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.514(d)(3)(i)", + "§ 164.514(d)(3)(ii)(A)", + "§ 164.514(d)(3)(ii)(B)", + "§ 164.514(d)(3)(iii)", + "§ 164.514(d)(3)(iii)(A)", + "§ 164.514(d)(3)(iii)(B)", + "§ 164.514(d)(3)(iii)(C)", + "§ 164.514(d)(3)(iii)(D)", + "§ 164.514(d)(4)", + "§ 164.514(d)(4)(i)", + "§ 164.514(d)(4)(ii)", + "§ 164.514(d)(4)(iii)(A)", + "§ 164.514(d)(4)(iii)(B)", + "§ 164.514(d)(5)", + "§ 164.514(e)(1)", + "§ 164.514(e)(2)", + "§ 164.514(e)(2)(i)", + "§ 164.514(e)(2)(ii)", + "§ 164.514(e)(2)(iii)", + "§ 164.514(e)(2)(iv)", + "§ 164.514(e)(2)(v)", + "§ 164.514(e)(2)(vi)", + "§ 164.514(e)(2)(vii)", + "§ 164.514(e)(2)(viii)", + "§ 164.514(e)(2)(ix)", + "§ 164.514(e)(2)(x)", + "§ 164.514(e)(2)(xi)", + "§ 164.514(e)(2)(xii)", + "§ 164.514(e)(2)(xiii)", + "§ 164.514(e)(2)(xiv)", + "§ 164.514(e)(2)(xv)", + "§ 164.514(e)(2)(xvi)", + "§ 164.514(e)(3)(i)", + "§ 164.514(e)(3)(ii)", + "§ 164.514(e)(4)(i)", + "§ 164.514(e)(4)(ii)", + "§ 164.514(e)(4)(ii)(A)", + "§ 164.514(e)(4)(ii)(B)", + "§ 164.514(e)(4)(ii)(C)", + "§ 164.514(e)(4)(ii)(C)(1)", + "§ 164.514(e)(4)(ii)(C)(2)", + "§ 164.514(e)(4)(ii)(C)(3)", + "§ 164.514(e)(4)(ii)(C)(4)", + "§ 164.514(e)(4)(ii)(C)(5)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)", + "§ 164.532(c)(1)", + "§ 164.532(d)" ], "usa-federal-nispom-2020": [ "§117.15(h)", @@ -2779,15 +2745,13 @@ "45.48.430.5", "45.48.430.6" ], - "emea-isr-cmo-1-0": [ - "10.5" + "usa-state-nv-privacy-law-2023": [ + "603A.495.3(b)", + "603A.500.2" ], "emea-sau-cscc-1-2019": [ "2-6-1-3" ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], "emea-sau-pdpl-2023": [ "Article 15.3", "Article 15.4", @@ -2803,8 +2767,29 @@ "Article 16.8", "Article 16.9" ], - "emea-sau-sacs-002-2022": [ - "TPC-39" + "apac-aus-privacy-principles-2026": [ + "3.9.2", + "3.9.2.a", + "3.9.2.b", + "3.9.2.c", + "3.9.2.d", + "3.9.2.e", + "3.9.2.f", + "3.9.3", + "3.9.3.a", + "3.9.3.b", + "3.9.3.c" + ], + "apac-chn-pipl-2021": [ + "Article 25" + ], + "apac-ind-privacy-rules-2011": [ + "6(1)", + "6(2)", + "6(3)" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP3" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", @@ -2817,8 +2802,8 @@ "control_id": "DCH-03.2", "title": "Masking Displayed Data", "family": "DCH", - "description": "Mechanisms exist to apply data masking to sensitive/regulated information that is displayed or printed.", - "scf_question": "Does the organization apply data masking to sensitive/regulated information that is displayed or printed?", + "description": "Mechanisms exist to apply data masking to sensitive and/or regulated information that is displayed or printed.", + "scf_question": "Does the organization apply data masking to sensitive and/or regulated information that is displayed or printed?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2831,9 +2816,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply data masking to sensitive/regulated information that is displayed or printed.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply data masking to sensitive/regulated information that is displayed or printed. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2877,7 +2862,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -2917,6 +2903,9 @@ "usa-state-il-ipa-2009": [ "35(a)(4)", "37(a)(4)" + ], + "americas-arg-ppd-2018": [ + "H.1.1" ] } }, @@ -2938,7 +2927,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically validate cybersecurity and data protection attributes prior to releasing information to external Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2968,7 +2957,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -3023,9 +3013,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to mark media in accordance with data protection requirements so that personnel are alerted to distribution limitations, handling caveats and applicable security requirements.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to mark media in accordance with data protection requirements so that personnel are alerted to distribution limitations, handling caveats and applicable security requirements. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3074,7 +3064,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -3249,13 +3240,13 @@ "emea-deu-c5-2020": [ "AM-06" ], - "emea-isr-cmo-1-0": [ - "15.2" + "emea-sau-ecc-1-2018": [ + "2-1-5" ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.1 [MP.SI.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0201", "ISM-0270", "ISM-0272", @@ -3290,8 +3281,7 @@ "13.2.12.C.04", "13.2.13.C.01", "13.2.14.C.01", - "13.2.14.C.02", - "21.1.21.C.01" + "13.2.14.C.02" ], "americas-can-itsp-10-171-2025": [ "03.08.04" @@ -3316,9 +3306,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically mark physical media and digital files to indicate the distribution limitations, handling requirements and applicable security markings (if any) of the information to aid Data Loss Prevention (DLP) technologies.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically mark physical media and digital files to indicate the distribution limitations, handling requirements and applicable security markings (if any) of the information to aid Data Loss Prevention (DLP) technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3378,7 +3368,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -3445,8 +3436,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-03" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0271" + ], + "apac-nzl-ism-3-9": [ + "15.2.39.C.02", + "15.2.39.C.03" ] } }, @@ -3468,7 +3463,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to bind cybersecurity and data protection attributes to information as it is stored, transmitted and processed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3515,14 +3510,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { "general-csa-iot-2": [ "DAT-01" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1005", @@ -3618,7 +3614,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to dynamically associate cybersecurity and data protection attributes with individuals and objects as information is created, combined, or transformed, in accordance with organization-defined cybersecurity and data protection policies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3665,7 +3661,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -3698,7 +3695,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide authorized individuals (or processes acting on behalf of individuals) the capability to define or change the value of associated cybersecurity and data protection attributes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3745,7 +3742,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -3775,7 +3773,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain the association and integrity of cybersecurity and data protection attributes to individuals and objects.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3822,7 +3820,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -3852,7 +3851,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide the capability to associate cybersecurity and data protection attributes with individuals and objects by authorized individuals (or processes acting on behalf of individuals).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3899,7 +3898,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -3929,7 +3929,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to display cybersecurity and data protection attributes in human-readable form on each object that the system transmits to output devices to identify special dissemination, handling or distribution instructions using human-readable, standard naming conventions.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3976,7 +3976,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -4006,7 +4007,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to require personnel to associate and maintain the association of cybersecurity and data protection attributes with individuals and objects in accordance with cybersecurity and data protection policies.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4053,7 +4054,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -4083,7 +4085,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide a consistent, organizationally agreed upon interpretation of cybersecurity and data protection attributes employed in access enforcement and flow enforcement decisions between distributed system components.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4130,7 +4132,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -4160,7 +4163,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to associate cybersecurity and data protection attributes to information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4207,7 +4210,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -4237,7 +4241,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to reclassify data as required, due to changing business/technical requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4284,7 +4288,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -4294,7 +4299,7 @@ "general-nist-800-82-r3": [ "AC-16(09)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0325" ] } @@ -4317,7 +4322,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to provide authorized individuals the capability to define or change the type and value of cybersecurity and data protection attributes available for association with subjects and objects.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4364,7 +4369,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -4398,7 +4404,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to audit changes to cybersecurity and data protection attributes and responds to events in accordance with incident response procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -4446,7 +4452,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} @@ -4456,7 +4463,7 @@ "title": "Media Storage", "family": "DCH", "description": "Mechanisms exist to: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures.", - "scf_question": "Does the organization: \n (1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n (2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures?", + "scf_question": "Does the organization: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -4476,7 +4483,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to: \n(1) Physically control and securely store digital and non-digital media within controlled areas using organization-defined security measures; and\n(2) Protect system media until the media are destroyed or sanitized using approved equipment, techniques and procedures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -4550,7 +4557,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -4685,11 +4693,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-04" ], - "emea-isr-cmo-1-0": [ - "15.3" - ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2308" @@ -4706,6 +4713,9 @@ "apac-jpn-ismap": [ "8.3.1.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], "apac-nzl-ism-3-9": [ "8.4.10.C.01", "8.4.11.C.01", @@ -4736,7 +4746,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to physically secure all media that contains sensitive information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4812,7 +4822,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -4822,6 +4833,10 @@ "general-nist-800-171-r3": [ "03.08.01" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], "general-pci-dss-4-0-1": [ "9.1", "9.4", @@ -4865,6 +4880,9 @@ "apac-jpn-ismap": [ "8.3.1.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], "americas-can-itsp-10-171-2025": [ "03.08.01" ] @@ -4890,9 +4908,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain inventory logs of all sensitive media and conduct sensitive media inventories at least annually.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to maintain inventory logs of all sensitive media and conduct sensitive media inventories at least annually. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4969,7 +4987,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -5005,8 +5024,10 @@ "03.04.11.a", "03.04.11.b" ], - "general-nist-800-172": [ - "3.1.2e" + "general-nist-800-171a-r3": [ + "A.03.04.11.a[02]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -5041,15 +5062,12 @@ "emea-gbr-caf-4-0": [ "B3.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0336" ], "apac-ind-sebi-2024": [ "ID.AM.S5" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS03" - ], "americas-can-osfi-b13-2022": [ "2.2.2", "3.1.4" @@ -5064,8 +5082,8 @@ "control_id": "DCH-06.3", "title": "Periodic Scans for Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", - "scf_question": "Does the organization periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations?", + "description": "Mechanisms exist to periodically scan unstructured data sources for sensitive and/or regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", + "scf_question": "Does the organization periodically scan unstructured data sources for sensitive and/or regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations?", "relative_weight": 7, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -5080,9 +5098,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to periodically scan unstructured data sources for sensitive/regulated data or data requiring special protection measures by statutory, regulatory or contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5142,7 +5160,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -5164,6 +5183,9 @@ "general-pci-dss-4-0-1": [ "A3.2.5", "A3.2.5.1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.4" ] } }, @@ -5171,8 +5193,8 @@ "control_id": "DCH-06.4", "title": "Making Sensitive Data Unreadable In Storage", "family": "DCH", - "description": "Mechanisms exist to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored.", - "scf_question": "Does the organization ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored?", + "description": "Mechanisms exist to ensure sensitive and/or regulated data is rendered human unreadable anywhere sensitive and/or regulated data is stored.", + "scf_question": "Does the organization ensure sensitive and/or regulated data is rendered human unreadable anywhere sensitive and/or regulated data is stored?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5185,9 +5207,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure sensitive/regulated data is rendered human unreadable anywhere sensitive/regulated data is stored. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5245,7 +5267,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -5255,6 +5278,10 @@ "general-nist-800-171-r3": [ "03.08.01" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]" + ], "general-pci-dss-4-0-1": [ "9.4" ], @@ -5284,9 +5311,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the storage of sensitive transaction authentication data after authorization.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the storage of sensitive transaction authentication data after authorization. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5341,7 +5368,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -5415,7 +5443,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ Data classification and handling criteria govern user behavior for media handling.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect and control digital and non-digital media during transport outside of controlled areas using appropriate security measures.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -5501,7 +5529,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -5573,7 +5602,8 @@ ], "general-nist-800-171-r3": [ "03.08.05.a", - "03.08.05.b" + "03.08.05.b", + "03.08.05.c" ], "general-nist-800-171a": [ "3.8.5[a]", @@ -5626,10 +5656,10 @@ "MP-05" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.4", @@ -5666,14 +5696,14 @@ "emea-eu-nis2-annex-2024": [ "12.3.2(c)" ], - "emea-isr-cmo-1-0": [ - "15.7" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" + "emea-deu-c5-2020": [ + "AM-08" ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.4 [MP.SI.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2302", @@ -5696,9 +5726,13 @@ "8.3.3.5", "13.2.2.5" ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-3" + ], "americas-can-itsp-10-171-2025": [ "03.08.05.A", - "03.08.05.B" + "03.08.05.B", + "03.08.05.C" ] } }, @@ -5722,7 +5756,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ Data classification and handling criteria govern user behavior for media handling.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify custodians throughout the transport of digital or non-digital media.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify custodians throughout the transport of digital or non-digital media. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5806,7 +5840,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -5847,6 +5882,10 @@ "03.08.05.a", "03.08.05.b" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.a[02]", + "A.03.08.05.b" + ], "general-pci-dss-4-0-1": [ "9.4.3" ], @@ -5878,10 +5917,10 @@ "8.2.7" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "2.B.4", @@ -5894,18 +5933,15 @@ "§117.15(f)(4)(iii)", "§117.15(f)(4)(iv)" ], - "emea-isr-cmo-1-0": [ - "15.7" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-4" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.3 [MP.SI.3]" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "apac-jpn-ismap": [ "8.3.1.10" ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-3" + ], "americas-can-itsp-10-171-2025": [ "03.08.05.A", "03.08.05.B" @@ -5930,7 +5966,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5990,7 +6026,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -6039,6 +6076,9 @@ "general-nist-800-171-r3": [ "03.08.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.05.a[02]" + ], "usa-federal-fbi-cjis-6-0": [ "SC-28(1)" ], @@ -6066,6 +6106,11 @@ "emea-eu-nis2-annex-2024": [ "12.3.2(c)" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], "emea-gbr-def-stan-05-138-2024": [ "2302" ], @@ -6103,9 +6148,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of media when it is no longer required, using formal procedures.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of media when it is no longer required, using formal procedures. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6181,7 +6226,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -6285,6 +6331,9 @@ "general-nist-800-171-r3": [ "03.08.03" ], + "general-nist-800-171a-r3": [ + "A.03.08.03" + ], "general-pci-dss-4-0-1": [ "9.4", "9.4.6" @@ -6365,6 +6414,9 @@ "usa-state-il-pipa-2006": [ "40(b)(2)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(C)(1)" ], @@ -6377,28 +6429,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-deu-c5-2020": [ - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.5.5 [MP.SI.5]" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0312", "ISM-0315", @@ -6446,8 +6482,8 @@ "13.5.29.C.02", "13.5.30.C.01" ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" + "americas-arg-ppd-2018": [ + "F.1.2-DS-1" ], "americas-can-itsp-10-171-2025": [ "03.08.03" @@ -6475,7 +6511,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to sanitize system media with the strength and integrity commensurate with the classification or sensitivity of the information prior to disposal, release out of organizational control or release for reuse.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6552,7 +6588,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -6679,8 +6716,15 @@ "3.8.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.07.04.c", "A.03.08.03" ], + "general-nist-800-172-r3": [ + "03.08.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.08.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "9.4.7" ], @@ -6730,10 +6774,10 @@ "155.260(a)(4)(vi)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(2)(ii)" + "§ 164.310(d)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "2.F.3.1-1", @@ -6764,18 +6808,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-sau-otcc-1-2022": [ - "2-6-1-3" + "emea-deu-c5-2020": [ + "PI-05" ], "emea-sau-sacs-002-2022": [ - "TPC-19", - "TPC-66" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.6 [MP.INFO.6]" + "VII.A.TPC-19", + "VII.B.TPC-66" ], "emea-gbr-caf-4-0": [ "B3.e" @@ -6795,7 +6833,7 @@ "2313", "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311", "ISM-0313", "ISM-0317", @@ -6824,6 +6862,7 @@ "11.2.7.3" ], "apac-nzl-ism-3-9": [ + "12.6.5.C.05", "13.4.9.C.01", "13.4.11.C.01", "13.4.12.C.01", @@ -6834,12 +6873,11 @@ "13.4.13.C.05", "13.4.14.C.01", "13.4.15.C.01", - "12.6.5.C.05", - "13.4.19.C.02", "13.4.16.C.01", "13.4.17.C.01", "13.4.18.C.01", "13.4.19.C.01", + "13.4.19.C.02", "13.4.20.C.01", "13.4.20.C.02", "13.4.20.C.03", @@ -6849,6 +6887,10 @@ "apac-sgp-mas-trm-2021": [ "11.1.7" ], + "americas-arg-ppd-2018": [ + "D.1.2-4", + "F.1.2" + ], "americas-bmu-mba-coc-2020": [ "6.17" ], @@ -6879,9 +6921,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to supervise, track, document and verify system media sanitization and disposal actions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to supervise, track, document and verify system media sanitization and disposal actions. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6952,7 +6994,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -7019,9 +7062,6 @@ "MP-06(1)", "MP-06(1)-SID" ], - "emea-isr-cmo-1-0": [ - "15.8" - ], "emea-gbr-def-stan-05-138-2024": [ "2323" ], @@ -7034,7 +7074,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0316", "ISM-0363", "ISM-0370", @@ -7052,6 +7092,13 @@ "13.5.27.C.03", "13.5.28.C.01", "13.5.28.C.02" + ], + "americas-arg-ppd-2018": [ + "F.1.1", + "F.1.4" + ], + "americas-bmu-mba-coc-2020": [ + "6.17" ] } }, @@ -7073,9 +7120,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to test sanitization equipment and procedures to verify that the intended result is achieved.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to test sanitization equipment and procedures to verify that the intended result is achieved. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7146,7 +7193,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -7180,9 +7228,6 @@ "usa-federal-cms-marse-2-0": [ "MP-6(2)" ], - "emea-isr-cmo-1-0": [ - "15.8" - ], "apac-nzl-ism-3-9": [ "13.4.23.C.01" ] @@ -7206,7 +7251,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the sanitization of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7284,7 +7329,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -7357,9 +7403,6 @@ "general-nist-800-161-r1-level-3": [ "MP-6" ], - "general-scf-dpmp-2025": [ - "5.5" - ], "general-tisax-6-0-3": [ "8.2.6" ], @@ -7408,25 +7451,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "MP-06" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-zaf-popia-2013": [ - "16.1" - ], "apac-ind-dpdpa-2023": [ "8(7)(a)" - ], - "americas-arg-ppd-2018": [ - "4.7", - "16.7", - "25.2" - ], - "americas-bra-lgpd-2018": [ - "16" ] } }, @@ -7448,7 +7474,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to apply nondestructive sanitization techniques to portable storage devices prior to first use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7507,7 +7533,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -7547,7 +7574,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "MP-06(03)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1600", "ISM-1642" ] @@ -7557,8 +7584,8 @@ "control_id": "DCH-09.5", "title": "Dual Authorization for Sensitive Data Destruction", "family": "DCH", - "description": "Mechanisms exist to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data.", - "scf_question": "Does the organization enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data?", + "description": "Mechanisms exist to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive and/or regulated data.", + "scf_question": "Does the organization enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive and/or regulated data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7571,7 +7598,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to enforce dual authorization for the destruction, disposal or sanitization of digital media that contains sensitive/regulated data.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7652,7 +7679,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -7664,6 +7692,14 @@ ], "general-nist-800-82-r3": [ "MP-06(07)" + ], + "general-nist-800-172-r3": [ + "03.08.01E", + "03.08.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.08.01E", + "A.03.08.02E.ODP[01]" ] } }, @@ -7685,9 +7721,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of types of digital media on systems or system components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of types of digital media on systems or system components. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7746,7 +7782,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -7768,7 +7805,7 @@ "general-iso-27018-2025": [ "7.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1025", "T1052", "T1052.001", @@ -7859,7 +7896,12 @@ "MP-07" ], "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "5-1-3-5" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2310" @@ -7873,7 +7915,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2310" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0341", "ISM-0343" ], @@ -7889,8 +7931,8 @@ "control_id": "DCH-10.1", "title": "Limitations on Use", "family": "DCH", - "description": "Mechanisms exist to restrict the use and distribution of sensitive/regulated data.", - "scf_question": "Does the organization restrict the use and distribution of sensitive/regulated data?", + "description": "Mechanisms exist to restrict the use and distribution of sensitive and/or regulated data.", + "scf_question": "Does the organization restrict the use and distribution of sensitive and/or regulated data?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7905,9 +7947,9 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ Limited media handling guidance exists for users.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use and distribution of sensitive/regulated data.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use and distribution of sensitive/regulated data. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -7960,7 +8002,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -7973,7 +8016,12 @@ "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(2)" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" + ], + "apac-aus-ism-2026-march": [ "ISM-0343" ], "apac-nzl-ism-3-9": [ @@ -7999,7 +8047,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit the use of portable storage devices in organizational systems when such devices have no identifiable owner.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8059,7 +8107,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -8162,11 +8211,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to reclassify data, including associated Technology Assets, Applications and/or Services (TAAS), commensurate with the security category and/or classification level of the information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -8227,7 +8276,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -8245,7 +8295,10 @@ "MP-08", "MP-08(03)" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "SIM-02" + ], + "apac-aus-ism-2026-march": [ "ISM-0325", "ISM-0330" ], @@ -8273,7 +8326,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict removable media in accordance with data handling and acceptable usage parameters.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8342,7 +8395,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -8375,6 +8429,9 @@ "general-nist-800-171-r3": [ "03.08.07.a" ], + "general-nist-800-171a-r3": [ + "A.03.08.07.a" + ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.V" ], @@ -8386,11 +8443,13 @@ "12.3.2(a)", "12.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "12.24" + "emea-sau-otcc-1-2022": [ + "2-3-1-9" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" + "emea-esp-ccn-stic-825-2026": [ + "mp.si.3", + "mp.si.4", + "mp.si.5" ], "emea-gbr-def-stan-05-138-2024": [ "2310" @@ -8404,17 +8463,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2310" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1359", "ISM-1713" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP14", "HML14" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP12" ], @@ -8447,11 +8503,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern how external parties, including Technology Assets, Applications and/or Services (TAAS), are used to securely store, process and transmit data.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to govern how external parties, including Technology Assets, Applications and/or Services (TAAS), are used to securely store, process and transmit data. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -8535,7 +8591,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -8557,7 +8614,7 @@ "general-govramp-high": [ "AC-20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1021", "T1021.001", @@ -8685,7 +8742,8 @@ "A.03.01.20.a", "A.03.01.20.b", "A.03.01.20.c.01", - "A.03.01.20.c.02" + "A.03.01.20.c.02", + "A.03.01.20.d" ], "usa-federal-fbi-cjis-6-0": [ "AC-20" @@ -8741,11 +8799,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-20" ], - "emea-isr-cmo-1-0": [ - "11.6" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-36" ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" + "emea-esp-decree-311-2022": [ + "Article 22(1)" ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", @@ -8774,7 +8832,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prohibit external parties, including Technology Assets, Applications and/or Services (TAAS), from storing, processing and transmitting data unless authorized individuals first: \n(1) Verifying the implementation of required security, compliance and/or resilience controls; or\n(2) Retaining a processing agreement with the entity hosting the external TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8842,9 +8900,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Classification & Handling", "crosswalks": { "general-cis-csc-8-1": [ @@ -8908,6 +8966,13 @@ "03.01.20.c.02", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.01.20.d" + ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -8952,9 +9017,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-20 (01)" ], - "emea-srb-act-9-2018": [ - "5.1" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.B", @@ -8982,9 +9044,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict or prohibit the use of portable storage devices by users on external systems.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict or prohibit the use of portable storage devices by users on external systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9067,7 +9129,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -9127,6 +9190,7 @@ "3.1.21[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", "A.03.01.20.d" ], "usa-federal-fbi-cjis-6-0": [ @@ -9142,10 +9206,10 @@ "AC-20(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "AC-20(CE-2)", @@ -9156,13 +9220,15 @@ "AC-20(2)-IS.a" ], "emea-sau-ecc-1-2018": [ + "2-3-3-2", "5-1-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8", - "2-3-1-9" + "emea-esp-decree-311-2022": [ + "Article 22(1)" ], "apac-nzl-ism-3-9": [ + "11.8.11.C.01", + "11.8.11.C-02", "13.3.7.C.01", "13.3.7.C.02", "13.3.8.C.01", @@ -9171,6 +9237,9 @@ "13.3.9.C.02", "13.3.10.C.01" ], + "apac-sgp-mas-trm-2021": [ + "11.1.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.D" @@ -9181,8 +9250,8 @@ "control_id": "DCH-13.3", "title": "Protecting Sensitive / Regulated Data on External Technology Assets, Applications and/or Services (TAAS)", "family": "DCH", - "description": "Mechanisms exist to ensure that the requirements for the protection of sensitive/regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization ensure that the requirements for the protection of sensitive/regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to ensure that the requirements for the protection of sensitive and/or regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization ensure that the requirements for the protection of sensitive and/or regulated data processed, stored or transmitted on external Technology Assets, Applications and/or Services (TAAS), are implemented in accordance with applicable statutory, regulatory and contractual obligations?", "relative_weight": 10, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -9280,7 +9349,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -9315,13 +9385,14 @@ "03.01.20.b", "03.01.20.c.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.01" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", "03.01.20.C.01" @@ -9346,7 +9417,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict the use of non-organizationally owned Technology Assets, Applications and/or Services (TAAS) to process, store or transmit organizational information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9430,7 +9501,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -9457,6 +9529,18 @@ "03.01.20.c.01", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.c.01", + "A.03.01.20.d" + ], + "general-nist-800-172-r3": [ + "03.01.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.02E", + "A.03.01.02E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -9491,11 +9575,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a process to assist users in making information sharing decisions to ensure data is appropriately protected.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -9560,7 +9644,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -9604,7 +9689,7 @@ "general-iso-27018-2025": [ "5.14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1213", "T1213.001", "T1213.002", @@ -9638,6 +9723,9 @@ "general-nist-800-171-r3": [ "03.01.20.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b" + ], "general-swift-cscf-2025": [ "2.1", "2.4", @@ -9671,14 +9759,13 @@ "usa-state-ca-ccpa-cpra-2026": [ "7153(a)" ], - "emea-isr-cmo-1-0": [ - "5.4", - "10.5" + "emea-isr-cmo-2-0": [ + "Appendix A, 5.2" ], - "emea-zaf-popia-2013": [ - "72" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0657", "ISM-0661", "ISM-0663", @@ -9693,36 +9780,6 @@ "13.2.1.5", "13.2.1.9" ], - "apac-nzl-ism-3-9": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B" ] @@ -9746,7 +9803,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to ensure Technology Assets, Applications and/or Services (TAAS) implement data search and retrieval functions that properly enforce data protection / sharing restrictions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9819,7 +9876,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -9852,7 +9910,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to verify that individuals or Technology Assets, Applications and/or Services (TAAS) transferring data between interconnecting TAAS have the requisite authorizations (e.g., write permissions or privileges) prior to transferring said data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9920,7 +9978,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -9956,6 +10015,11 @@ "03.01.20.c.02", "03.12.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -9970,23 +10034,12 @@ "usa-federal-irs-1075-2021": [ "2.E.6.2" ], - "emea-ken-pda-2019": [ - "25(h)" + "emea-deu-c5-2020": [ + "AM-08" ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], - "emea-srb-act-9-2018": [ - "64", - "64.1", - "64.2", - "64.3", - "64.4" - ], - "apac-nzl-ism-3-9": [ - "20.1.8.C.01", - "20.2.4.C.01" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", "03.01.20.C.02", @@ -9998,8 +10051,8 @@ "control_id": "DCH-14.3", "title": "Data Access Mapping", "family": "DCH", - "description": "Mechanisms exist to leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive/regulated data is shared.", - "scf_question": "Does the organization leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive/regulated data is shared?", + "description": "Mechanisms exist to leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive and/or regulated data is shared.", + "scf_question": "Does the organization leverage data-specific Access Control Lists (ACL) or Interconnection Security Agreements (ISAs) to generate a logical map of the parties with whom sensitive and/or regulated data is shared?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -10081,7 +10134,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -10105,6 +10159,11 @@ "03.01.20.c.02", "03.12.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]", + "A.03.01.20.c.02", + "A.03.12.05.a[01]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DA.DAUTE" ], @@ -10211,7 +10270,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -10273,8 +10333,7 @@ ], "general-nist-800-171a-r3": [ "A.03.01.22.a", - "A.03.01.22.b[01]", - "A.03.01.22.b[02]" + "A.03.01.22.b[01]" ], "general-pci-dss-4-0-1": [ "1.4.4" @@ -10373,7 +10432,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect data storage objects against unauthorized data mining and data harvesting techniques.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect data storage objects against unauthorized data mining and data harvesting techniques. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10430,11 +10489,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -10510,18 +10570,6 @@ ], "usa-federal-irs-1075-2021": [ "AC-23" - ], - "apac-nzl-ism-3-9": [ - "20.4.3.C.01", - "20.4.3.C.02", - "20.4.3.C.03", - "20.4.3.C.04", - "20.4.4.C.01", - "20.4.4.C.02", - "20.4.5.C.01", - "20.4.5.C.02", - "20.4.6.C.01", - "20.4.6.C.02" ] } }, @@ -10547,7 +10595,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to secure ad-hoc exchanges of large digital files with internal or external parties.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -10615,7 +10663,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -10647,6 +10696,9 @@ "general-nist-800-171-r3": [ "03.01.20.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.20.a" + ], "usa-federal-dow-cmmc-2-level-1": [ "AC.L1-B.1.III" ], @@ -10659,32 +10711,21 @@ "usa-federal-irs-1075-2021": [ "2.E.2" ], - "emea-isr-cmo-1-0": [ - "5.1", - "5.4", - "10.5" - ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], - "apac-aus-ism-2024-june": [ + "emea-sau-otcc-1-2022": [ + "2-6-1-4" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" + ], + "apac-aus-ism-2026-march": [ "ISM-0347", "ISM-0947", "ISM-1778", "ISM-1779" ], - "apac-nzl-ism-3-9": [ - "20.1.11.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A" ] @@ -10712,7 +10753,7 @@ "0": "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.", "1": "Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media.\n▪ A manual data retention process exists.\n▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures.", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10798,7 +10839,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -10863,7 +10905,7 @@ "5.33", "8.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1020.001", @@ -10959,14 +11001,25 @@ ], "general-nist-800-171-r3": [ "03.01.20.c.02", + "03.10.07.b", "03.14.08" ], "general-nist-800-171a-r3": [ + "A.03.01.20.c.02", + "A.03.10.07.b", "A.03.14.08[01]", "A.03.14.08[02]", "A.03.14.08[03]", "A.03.14.08[04]" ], + "general-nist-800-172-r3": [ + "03.04.06E", + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.04.06E", + "A.03.10.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "3.2", "3.2.1", @@ -11017,9 +11070,6 @@ "3.2.1", "9.4.6" ], - "general-scf-dpmp-2025": [ - "5.4" - ], "general-swift-cscf-2025": [ "6.4" ], @@ -11050,15 +11100,19 @@ "MP-07", "SI-12" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(11)", + "101.640" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(6)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.316(b)(2)(i)", - "164.530(j)(2)" + "§ 164.316(b)(2)(i)", + "§ 164.530(j)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.316(b)(2)(i)" + "§ 164.316(b)(2)(i)" ], "usa-federal-irs-1075-2021": [ "MP-7", @@ -11081,6 +11135,9 @@ "usa-state-il-pipa-2006": [ "30" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-nv-regulation-5-2024": [ "5.260.5(b)", "5.260.5(c)" @@ -11117,42 +11174,28 @@ "Article 18.1(e)", "Article 18.3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.8", - "Article 13.7" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 6 Module B.9", - "Annex 6 Module C.3.2" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(13)", + "Article 19(6)", + "Article 23(2)" ], "emea-eu-nis2-annex-2024": [ "1.1.1(h)", "4.2.2(f)" ], + "emea-deu-c5-2020": [ + "RB-06" + ], "emea-sau-cscc-1-2019": [ "2-6-1-4", "2-11-2" ], - "emea-srb-act-9-2018": [ - "5.5" - ], - "emea-zaf-popia-2013": [ - "9" - ], - "emea-esp-ccn-stic-825-2023": [ - "9" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3 & 5" + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-19" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", + "apac-aus-ism-2026-march": [ "ISM-1510" ], - "apac-chn-pipl-2021": [ - "19" - ], "apac-ind-dpdpa-2023": [ "8(7)(a)", "8(8)" @@ -11181,8 +11224,12 @@ "18.1.3.12", "18.1.3.13.PB" ], + "americas-bmu-mba-coc-2020": [ + "5.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.20.C.02", + "03.10.07.B", "03.14.08" ] } @@ -11191,8 +11238,8 @@ "control_id": "DCH-18.1", "title": "Minimize Sensitive / Regulated Data", "family": "DCH", - "description": "Mechanisms exist to minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", - "scf_question": "Does the organization minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes?", + "description": "Mechanisms exist to minimize sensitive and/or regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", + "scf_question": "Does the organization minimize sensitive and/or regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -11209,7 +11256,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to minimize sensitive/regulated data that is collected, received, processed, stored and/or transmitted throughout the information lifecycle to only those elements necessary to support necessary business processes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -11272,7 +11319,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -11294,10 +11342,6 @@ "general-nist-800-82-r3": [ "SI-12(01)" ], - "general-scf-dpmp-2025": [ - "3.3", - "5.4" - ], "general-shared-assessments-sig-2025": [ "P.6" ], @@ -11317,19 +11361,22 @@ "SI-12(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(b)(1)" + "§ 164.502(b)(1)" ], "emea-sau-pdpl-2023": [ "Article 11.3" ], - "emea-zaf-popia-2013": [ - "19" + "emea-che-fadp-2025": [ + "2.1.7.3" + ], + "apac-aus-ism-2026-march": [ + "ISM-2021" ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.2" + "apac-kor-pipa-2011": [ + "III.1.16(1)" ], - "emea-esp-decree-311-2022": [ - "24.2" + "americas-mex-fdpa-2010": [ + "II.13" ] } }, @@ -11337,8 +11384,8 @@ "control_id": "DCH-18.2", "title": "Limit Sensitive / Regulated Data In Testing, Training & Research", "family": "DCH", - "description": "Mechanisms exist to minimize the use of sensitive/regulated data for research, testing, or training, in accordance with authorized, legitimate business practices.", - "scf_question": "Does the organization minimize the use of Personal Data (PD) for research, testing, or training, in accordance with the Data Protection Impact Assessment (DPIA)?", + "description": "Mechanisms exist to minimize the use of sensitive and/or regulated data for research, testing, or training, in accordance with authorized, legitimate business practices.", + "scf_question": "Does the organization minimize the use of sensitive and/or regulated data for research, testing, or training, in accordance with authorized, legitimate business practices?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -11419,7 +11466,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -11455,9 +11503,6 @@ "general-nist-800-161-r1-level-2": [ "PM-25" ], - "general-scf-dpmp-2025": [ - "3.2" - ], "usa-federal-fbi-cjis-6-0": [ "SI-12(2)" ], @@ -11496,15 +11541,6 @@ ], "emea-eu-nis2-annex-2024": [ "6.2.2(f)" - ], - "emea-srb-act-9-2018": [ - "5.1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-chn-pipl-2021": [ - "6" ] } }, @@ -11530,7 +11566,7 @@ "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform periodic checks of temporary files for the existence of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -11591,7 +11627,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} @@ -11616,11 +11653,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to inventory, document and maintain data flows for data that is resident (permanently or temporarily) within a service's geographically distributed applications (physical and virtual), infrastructure, systems components and/or shared with other third-parties.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -11703,7 +11740,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -11752,6 +11790,11 @@ "03.04.11.a", "03.04.11.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.11.a[01]", + "A.03.04.11.b[01]", + "A.03.04.11.b[02]" + ], "general-nist-csf-2-0": [ "ID.AM-03" ], @@ -11781,32 +11824,13 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-09 (05)" ], - "emea-isr-cmo-1-0": [ - "11.6" - ], - "emea-ken-pda-2019": [ - "25(h)" - ], - "emea-qat-pdppl-2020": [ - "15" - ], - "emea-sau-sacs-002-2022": [ - "TPC-30" + "emea-deu-c5-2020": [ + "UP-02", + "RB-03" ], "emea-gbr-caf-4-0": [ "B3.a" ], - "apac-aus-privacy-principles-2026": [ - "APP 8" - ], - "apac-chn-pipl-2021": [ - "38", - "39", - "40" - ], - "apac-jpn-ppi-2020": [ - "24(1)" - ], "americas-can-osfi-b13-2022": [ "2.9.2", "3.1.4" @@ -11835,9 +11859,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect archived data in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to protect archived data in accordance with applicable statutory, regulatory and contractual obligations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -11894,7 +11918,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": {} @@ -11917,7 +11942,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to securely dispose of, destroy or erase information.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -12003,7 +12028,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -12056,8 +12082,8 @@ "general-nist-800-171-r3": [ "03.08.03" ], - "general-scf-dpmp-2025": [ - "5.5" + "general-nist-800-171a-r3": [ + "A.03.08.03" ], "usa-federal-fbi-cjis-6-0": [ "SI-12(3)" @@ -12105,31 +12131,18 @@ "40(b)(1)", "40(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.200.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(C)(1)" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-deu-c5-2020": [ - "PI-03" - ], - "emea-isr-cmo-1-0": [ - "11.12", - "15.4" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0311" ], "apac-ind-sebi-2024": [ "PR.AA.S13" ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" - ], "americas-can-itsp-10-171-2025": [ "03.08.03" ] @@ -12140,7 +12153,7 @@ "title": "Data Quality Operations", "family": "DCH", "description": "Mechanisms exist to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", - "scf_question": "Does the organization check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", + "scf_question": "Does the organization check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -12153,11 +12166,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to check for Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data to ensure the accuracy, relevance, timeliness, impact, completeness and de-identification of information throughout the information lifecycle.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -12211,7 +12224,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -12310,16 +12324,6 @@ "emea-eu-ai-act-2024": [ "Article 10.3", "Article 17.1(f)" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 1" - ], - "apac-chn-pipl-2021": [ - "8" - ], - "apac-sgp-mas-trm-2021": [ - "5.8.1", - "5.8.2" ] } }, @@ -12341,7 +12345,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize technical controls to correct Personal Data (PD) that is inaccurate or outdated, incorrectly determined regarding impact, or incorrectly de-identified.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -12411,7 +12415,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -12437,11 +12442,6 @@ "SI-18(04)", "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "5.15", - "6.1", - "6.2" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-18(04)", "SI-18(05)" @@ -12462,8 +12462,8 @@ "155.260(a)(3)(vi)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)" ], "usa-federal-cms-marse-2-0": [ "IP-3" @@ -12474,132 +12474,21 @@ "usa-state-va-cdpa-2023": [ "59.1-577.A.2" ], - "emea-aut-fappd-2000": [ - "Sec 27" - ], - "emea-bel-act-8-1992": [ - "10", - "12" - ], - "emea-deu-fdpa-2017": [ - "Sec 20" - ], - "emea-grc-pirppd-1997": [ - "13" - ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "14" - ], - "emea-ita-pdpc-2003": [ - "7" - ], - "emea-nor-pda-2018": [ - "27" - ], - "emea-pol-act-29-1997": [ - "32" - ], - "emea-rus-federal-law-27-2006": [ - "17" - ], "emea-sau-pdpl-2023": [ "Article 17.1" ], - "emea-zaf-popia-2013": [ - "24" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" - ], - "emea-che-fadp-2025": [ - "5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" - ], - "apac-aus-privacy-principles-2026": [ - "APP 13" - ], - "apac-chn-csnip-2012": [ - "8" - ], - "apac-chn-pipl-2021": [ - "46", - "49" - ], - "apac-hkg-pdo-2022": [ - "Sec 22" - ], - "apac-jpn-ppi-2020": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" - ], - "apac-mys-pdpa-2010": [ - "34" + "apac-jpn-appi-2020": [ + "IV.1.29(3)" ], "apac-nzl-privacy-act-2020": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" - ], - "apac-phl-dpa-2012": [ - "34" + "3.1.22.7(4)" ], "apac-sgp-pdpa-2012": [ - "22" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "16.1", - "16.3" - ], - "americas-bhs-dpa-2003": [ - "10" - ], - "americas-bra-lgpd-2018": [ - "18.3" - ], - "americas-can-pipeda-2000": [ - "Principle 10" - ], - "americas-chl-act-19628-1999": [ - "13" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "5.22(2)(a)" ], "americas-mex-fdpa-2010": [ - "24", - "28", - "29" + "III.24", + "IV.28" ] } }, @@ -12607,8 +12496,8 @@ "control_id": "DCH-22.2", "title": "Data Tags", "family": "DCH", - "description": "Mechanisms exist to utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle.", - "scf_question": "Does the organization utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle?", + "description": "Mechanisms exist to utilize data tags to automate tracking of sensitive and/or regulated data across the information lifecycle.", + "scf_question": "Does the organization utilize data tags to automate tracking of sensitive and/or regulated data across the information lifecycle?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -12621,11 +12510,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to utilize data tags to automate tracking of sensitive/regulated data across the information lifecycle.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -12680,7 +12569,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -12735,9 +12625,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to collect Personal Data (PD) directly from the individual.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to collect Personal Data (PD) directly from the individual. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12783,7 +12673,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -12815,9 +12706,6 @@ ], "emea-sau-pdpl-2023": [ "Article 10" - ], - "apac-jpn-ppi-2020": [ - "17(1)" ] } }, @@ -12839,7 +12727,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to anonymize data by removing Personal Data (PD) from datasets.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -12890,7 +12778,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -12927,9 +12816,6 @@ "general-nist-800-82-r3": [ "SI-19" ], - "general-scf-dpmp-2025": [ - "5.1" - ], "usa-federal-doc-data-privacy-framework-2023": [ "III.14.a.i", "III.14.g.i" @@ -12955,32 +12841,29 @@ "emea-eu-ai-act-2024": [ "Article 10.5(b)" ], + "emea-bel-act-30-2018": [ + "Title 4, Chapter III, Section 3, Art. 198", + "Title 4, Chapter III, Section 3, Art. 199", + "Title 4, Chapter III, Section 3, Art. 200", + "Title 4, Chapter III, Section 3, Art. 201" + ], + "emea-deu-fdpa-2017": [ + "3.4.64(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.11.12(2)" + ], "emea-ken-pda-2019": [ - "39(2)" + "IV.39(2)" + ], + "emea-rus-152-fz-2025": [ + "Art. 13.1" ], "emea-srb-act-9-2018": [ - "50.1" - ], - "apac-jpn-ppi-2020": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" - ], - "americas-bra-lgpd-2018": [ - "12" + "IV.2.50(1)" + ], + "americas-arg-ppd-2018": [ + "H.1.1" ] } }, @@ -13002,7 +12885,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to de-identify the dataset upon collection by not collecting Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13051,7 +12934,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13096,7 +12980,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to refrain from archiving Personal Data (PD) elements if those elements in a dataset will not be needed after the dataset is archived.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13145,7 +13029,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13175,7 +13060,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to remove Personal Data (PD) elements from a dataset prior to its release if those elements in the dataset do not need to be part of the data release.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13226,7 +13111,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13256,7 +13142,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to remove, mask, encrypt, hash or replace direct identifiers in a dataset.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13306,7 +13192,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13363,7 +13250,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to manipulate numerical data, contingency tables and statistical findings so that no person or organization is identifiable in the results of the analysis.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13402,7 +13289,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13432,7 +13320,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to prevent disclosure of Personal Data (PD) by adding non-deterministic noise to the results of mathematical operations before the results are reported.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13471,7 +13359,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13490,8 +13379,8 @@ "control_id": "DCH-23.7", "title": "Automated De-Identification of Sensitive Data", "family": "DCH", - "description": "Mechanisms exist to perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms.", - "scf_question": "Does the organization perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms?", + "description": "Mechanisms exist to perform de-identification of sensitive and/or regulated data, using validated algorithms and software to implement the algorithms.", + "scf_question": "Does the organization perform de-identification of sensitive and/or regulated data, using validated algorithms and software to implement the algorithms?", "relative_weight": 1, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13504,7 +13393,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform de-identification of sensitive/regulated data, using validated algorithms and software to implement the algorithms.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13542,7 +13431,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13572,7 +13462,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to perform a motivated intruder test on the de-identified dataset to determine if the identified data remains or if the de-identified data can be re-identified.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13611,7 +13501,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13630,8 +13521,8 @@ "control_id": "DCH-23.9", "title": "Code Names", "family": "DCH", - "description": "Mechanisms exist to use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data.", - "scf_question": "Does the organization use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data?", + "description": "Mechanisms exist to use aliases to name assets, which are mission-critical and/or contain highly-sensitive and/or regulated data, are unique and not readily associated with a product, project or type of data.", + "scf_question": "Does the organization use aliases to name assets, which are mission-critical and/or contain highly-sensitive and/or regulated data, are unique and not readily associated with a product, project or type of data?", "relative_weight": 1, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13644,7 +13535,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to use aliases to name assets, which are mission-critical and/or contain highly-sensitive/regulated data, are unique and not readily associated with a product, project or type of data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13683,7 +13574,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -13712,11 +13604,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to document where sensitive/regulated data is stored, transmitted and/or processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to identify and document the location of information and the specific system components on which the information resides.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -13779,14 +13671,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF9" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025" ], @@ -13814,15 +13707,15 @@ "general-nist-800-161-r1-level-3": [ "CM-12" ], + "general-nist-800-171-r3": [ + "03.04.11.a" + ], "general-nist-800-171a-r3": [ "A.03.04.11.a[01]" ], "general-nist-800-207": [ "NIST Tenet 1" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "usa-federal-fbi-cjis-6-0": [ "CM-12" ], @@ -13839,68 +13732,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CM-12" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" + "americas-can-itsp-10-171-2025": [ + "03.04.11.A" ] } }, @@ -13909,7 +13742,7 @@ "title": "Automated Tools to Support Information Location", "family": "DCH", "description": "Automated mechanisms exist to identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection.", - "scf_question": "Does the organization identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection?", + "scf_question": "Does the organization use automated mechanisms to identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection?", "relative_weight": 6, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -13926,7 +13759,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to automatically identify by data classification type to ensure adequate security, compliance and resilience controls are in place to protect organizational information and individual data protection.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -13983,9 +13816,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Classification & Handling", "crosswalks": { "general-nist-800-53-r5-2": [ @@ -14024,63 +13857,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "CM-12(01)" - ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } }, @@ -14102,11 +13878,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to restrict and govern the transfer of sensitive and/or regulated data to third-countries or international organizations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -14169,7 +13945,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -14186,9 +13963,6 @@ "general-nist-800-207": [ "NIST Tenet 4" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-swift-cscf-2025": [ "2.4", "2.5A", @@ -14213,113 +13987,17 @@ "Article 49.4", "Article 49.6" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-isr-cmo-1-0": [ - "10.5" - ], "emea-ken-pda-2019": [ - "25(h)", - "48(a)", - "48(b)", - "48(c)(i)", - "48(c)(ii)", - "48(c)(iii)", - "48(c)(iv)", - "48(c)(v)", - "48(c)(vi)", - "49(1)", - "49(2)", - "49(3)", - "50" + "IV.25(h)" ], "emea-nga-dpr-2019": [ - "2.11", - "2.11(a)", - "2.11(b)", - "2.11(c)", - "2.11(d)", - "2.11(e)", - "2.12", - "2.12(a)", - "2.12(b)", - "2.12(c)", - "2.12(d)", - "2.12(e)", - "2.12(f)" - ], - "emea-qat-pdppl-2020": [ - "15" + "2.11" ], "emea-sau-cscc-1-2019": [ "2-6-1-5" ], "emea-sau-pdpl-2023": [ "Article 29.1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-30" - ], - "emea-srb-act-9-2018": [ - "23", - "63", - "63.1", - "63.2", - "63.3", - "63.4", - "65", - "68", - "69", - "69.x", - "70", - "70.1", - "70.2", - "70.3", - "70.4", - "70.5", - "71", - "71.1", - "71.2", - "71.3", - "71.4", - "71.5" - ], - "emea-zaf-popia-2013": [ - "72" - ], - "apac-jpn-ppi-2020": [ - "24(1)" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "26", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-col-law-1581-2012": [ - "26" ] } }, @@ -14341,7 +14019,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with DCH domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to establish organization-defined \"normal business activities\" to identify anomalous transaction activities that can reduce the opportunity for sending (outbound) and/or receiving (inbound) fraudulent actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14387,7 +14065,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { @@ -14420,7 +14099,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are well-documented and kept current by process owners.\n▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform).\n▪ 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).\n▪ An implemented and operational capability exists to constrain the impact of \"digital sovereignty laws,\" that require localized data within the host country, where data and processes may be subjected to arbitrary enforcement actions that potentially violate other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14487,23 +14166,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { - "emea-ken-pda-2019": [ - "50" + "emea-sau-cscc-1-2019": [ + "4-2-1-1" + ], + "emea-sau-ecc-1-2018": [ + "4-1-3-2", + "4-2-3-3" ], "apac-chn-cybersecurity-law-2017": [ "Article 37" ], - "apac-chn-data-security-law-2021": [ - "36" - ], "apac-chn-pipl-2021": [ - "36", - "38", - "40" + "Article 40" ], "apac-ind-sebi-2024": [ "PR.DS.S2" @@ -14615,7 +14294,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Classification & Handling", "crosswalks": { diff --git a/docs/api/families/EMB.json b/docs/api/families/EMB.json index 35b5da5d..1abc8c3b 100644 --- a/docs/api/families/EMB.json +++ b/docs/api/families/EMB.json @@ -25,7 +25,7 @@ "0": "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.", "1": "Embedded Technology (EMB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with EMB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Embedded technology management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Embedded technologies (e.g., Operational Technology (OT) and Internet of Things (IoT) are managed in the same manner as any other technology asset.", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.", - "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to facilitate the implementation of embedded technology controls.", + "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to facilitate the implementation of embedded technology controls. ", "4": "Embedded Technology (EMB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -119,7 +119,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -139,9 +140,6 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-shared-assessments-sig-2025": [ "M.1.1" ], @@ -154,18 +152,6 @@ "usa-federal-dow-zt-roadmap-1-1": [ "2.4.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "12.1", - "12.2", - "12.3" - ], "emea-sau-cgiot-2024": [ "1-1-1", "1-1-2", @@ -175,24 +161,17 @@ "emea-sau-ecc-1-2018": [ "5-1-1", "5-1-2", - "5-1-3", + "5-1-3-1", + "5-1-3-2", "5-1-4" ], "emea-sau-otcc-1-2022": [ - "1-1-2", - "1-6", - "2-1-2", - "2-3-2" - ], - "emea-zaf-popia-2013": [ - "19" + "1-4-1" ], "apac-sgp-mas-trm-2021": [ "11.5.1", "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" + "11.5.3" ] } }, @@ -301,30 +280,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Embedded Technology", "crosswalks": { "emea-sau-cgiot-2024": [ "2-5-1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 11", - "Principle 13" - ], - "apac-chn-pipl-2021": [ - "26" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.1", - "11.5.2", - "11.5.3", - "11.5.4", - "11.5.5" ] } }, @@ -433,13 +395,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Embedded Technology", "crosswalks": { - "emea-zaf-popia-2013": [ - "19" + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(v)" ] } }, @@ -461,7 +423,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Special baselines for embedded technologies configurations are created for higher-risk environments.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to protect embedded devices against unauthorized use of the physical factory diagnostic and test interface(s).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -546,7 +508,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -564,8 +527,7 @@ "2-14-1" ], "apac-aus-cop-sitc-2020": [ - "Principle 6", - "Principle 13" + "13" ] } }, @@ -587,7 +549,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to generate log entries on embedded devices when configuration changes or attempts to access interfaces are detected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -672,7 +634,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -691,15 +654,11 @@ "emea-sau-cgiot-2024": [ "2-11-2" ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "emea-sau-ecc-1-2018": [ + "5-1-3-3" ], "apac-aus-cop-sitc-2020": [ - "Principle 8", - "Principle 10" - ], - "apac-sgp-mas-trm-2021": [ - "11.5.5" + "8" ] } }, @@ -721,7 +680,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to protect embedded devices by preventing the unauthorized installation and execution of software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -808,7 +767,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -827,15 +787,8 @@ "emea-sau-cgiot-2024": [ "2-6-2" ], - "emea-sau-otcc-1-2022": [ - "1-5-2", - "1-5-3", - "1-5-4", - "2-3-1-5", - "2-3-1-6" - ], "apac-aus-cop-sitc-2020": [ - "Principle 6" + "13" ] } }, @@ -857,7 +810,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.\n▪ Unauthorized configuration changes to embedded technologies are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to securely update software and upgrade functionality on embedded devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -944,20 +897,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "emea-sau-cgiot-2024": [ "2-4-6" ], - "emea-sau-otcc-1-2022": [ - "1-5-4", - "2-2-1-4" - ], "apac-aus-cop-sitc-2020": [ - "Principle 3", - "Principle 12" + "3" ] } }, @@ -979,7 +928,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are documented and maintained by process owners.\n▪ 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 EMB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Embedded technology-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Embedded technology management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Embedded technologies (e.g., IoT and OT) are governed according to the same processes used for generic Technology Assets, Applications and/or Services (TAAS), where no formal, dedicated embedded technology governance process exists.\n▪ Business stakeholders and process owners are expected to take the initiative to work with IT and/or cybersecurity personnel to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ Secure Baseline Configurations (SBCs) protect embedded technologies commensurate with the criticality of the device and/or sensitivity of the data, in accordance with applicable laws, regulations and frameworks.", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to configure embedded technology to be resilient to data network and power outages.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1064,7 +1013,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1076,7 +1026,7 @@ "3-1-2" ], "apac-aus-cop-sitc-2020": [ - "Principle 9" + "9" ] } }, @@ -1098,7 +1048,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to automatically monitor the power levels of embedded technologies for decreased or excessive power usage, including battery drainage, to investigate for device tampering.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1160,7 +1110,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1169,6 +1120,12 @@ ], "emea-sau-cgiot-2024": [ "2-11-2" + ], + "emea-sau-ecc-1-2018": [ + "5-1-3-3" + ], + "apac-aus-cop-sitc-2020": [ + "10" ] } }, @@ -1190,7 +1147,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to perform evaluations of deployed embedded technologies as needed, or at least on an annual basis, to ensure that necessary updates to mitigate the risks associated with legacy embedded technologies are identified and implemented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1245,7 +1202,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1255,15 +1213,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.5" - ], - "emea-sau-otcc-1-2022": [ - "1-6", - "1-6-1", - "1-6-2", - "2-1-2", - "2-3-2", - "2-7-2", - "2-9-2" ] } }, @@ -1285,7 +1234,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to enforce the security of Message Queuing Telemetry Transport (MQTT) traffic.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1332,7 +1281,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1363,7 +1313,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to require embedded technologies to initiate all communications and drop new, incoming communications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1410,13 +1360,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "general-csa-iot-2": [ "CLS-08", "COM-10" + ], + "apac-aus-cop-sitc-2020": [ + "13" ] } }, @@ -1438,7 +1392,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to restrict embedded technologies to communicate only with authorized peers and service endpoints.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1485,7 +1439,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1497,26 +1452,8 @@ "general-shared-assessments-sig-2025": [ "M.1.1" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4", - "2-2-1-7", - "2-4-1", - "2-4-1-1", - "2-4-1-2", - "2-4-1-3", - "2-4-1-4", - "2-4-1-5", - "2-4-1-6", - "2-4-1-7", - "2-4-1-8", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13", - "2-4-1-14", - "2-4-1-15", - "2-4-1-16" + "apac-aus-cop-sitc-2020": [ + "13" ] } }, @@ -1538,7 +1475,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to determine if embedded technologies are certified for secure use in the proposed operating environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1596,7 +1533,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1610,10 +1548,6 @@ "general-ul-2900-2-2-2016": [ "8.3", "9.2" - ], - "emea-sau-otcc-1-2022": [ - "1-5-3-3", - "2-4-1-15" ] } }, @@ -1635,7 +1569,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to evaluate the safety aspects of embedded technologies via a fault tree analysis, or similar method, to determine possible consequences of misuse, misconfiguration and/or failure.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1714,7 +1648,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1753,7 +1688,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to enforce certificate-based authentication for embedded technologies (e.g., IoT, OT, etc.) and their supporting services.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1800,7 +1735,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1832,7 +1768,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to implement embedded technologies that utilize pre-provisioned cloud trust anchors to support secure bootstrap and Zero Touch Provisioning (ZTP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1879,7 +1815,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1907,7 +1844,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to ensure embedded technologies utilize a securely configured Real-Time Operating System (RTOS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1954,7 +1891,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { @@ -1962,6 +1900,9 @@ "IOT-06", "IOT-07", "IOT-09" + ], + "general-nist-cswp-39": [ + "4.4" ] } }, @@ -1983,7 +1924,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Embedded Technology (EMB) 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:\n▪ Policies and standards associated with EMB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with EMB domain capabilities are well-documented and kept current by process owners.\n▪ An embedded systems team, or similar function, is appropriately staffed and supported to implement and maintain EMB domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of embedded technology operations (e.g., Configuration Management Database (CMBD) Asset Management solution).\n▪ 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 EMB 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).\n▪ An implemented and operational capability exists to continuously validate autonomous systems that trigger an automatic state change when safe operation is no longer assured.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2045,16 +1986,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Embedded Technology", "crosswalks": { "general-csa-iot-2": [ "SAP-02", "SAP-09" - ], - "emea-sau-otcc-1-2022": [ - "3-1-1-5" ] } } diff --git a/docs/api/families/END.json b/docs/api/families/END.json index 81d84347..16a4d27c 100644 --- a/docs/api/families/END.json +++ b/docs/api/families/END.json @@ -123,7 +123,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -134,7 +135,7 @@ "CC6.7-POF4" ], "general-cis-csc-8-1": [ - "10.0" + "10" ], "general-cobit-2019": [ "DSS05.03", @@ -215,6 +216,7 @@ "3.14.2" ], "general-nist-800-171-r3": [ + "03.01.03", "03.14.02.a" ], "general-nist-800-171a": [ @@ -225,7 +227,9 @@ "3.4.2[b]" ], "general-nist-800-171a-r3": [ - "A.03.01.03[01]" + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.14.02.a[01]" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -292,10 +296,10 @@ "MP-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "MP-2" @@ -316,57 +320,24 @@ "MP-02" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(d)" + "3.4.4.36(d)" ], "emea-eu-nis2-annex-2024": [ "6.9.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "15.5" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-2", - "2-5" - ], - "emea-sau-ecc-1-2018": [ - "2-3-4", - "2-4-4" - ], - "emea-sau-otcc-1-2022": [ - "2-5", - "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", - "2-5-1-4", - "2-5-1-5", - "2-5-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-12", - "TPC-22" - ], - "emea-zaf-popia-2013": [ - "19" + "2-3-1-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.1 [MP.EQ.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "mp.eq.1", + "mp.eq.2", + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-caf-4-0": [ "B3.d" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" - ], "emea-gbr-def-stan-05-138-2024": [ "2317", "2411" @@ -387,33 +358,14 @@ "5.1.1.15", "12.2.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP34" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP30" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.5" - ], - "apac-sgp-mas-trm-2021": [ - "11.3.1", - "11.3.2", - "11.3.3", - "11.3.4", - "11.3.5", - "11.4.1", - "11.4.2", - "11.4.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.12" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ + "03.01.03", "03.14.02.A" ] } @@ -529,7 +481,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -576,7 +529,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to protect the confidentiality, integrity, availability and safety of endpoint devices.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -660,16 +613,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { "general-cis-csc-8-1": [ - "10.0", + "10", "10.3", "10.4", "10.5", - "11.0" + "11" ], "general-cis-csc-8-1-ig1": [ "10.3" @@ -802,10 +756,10 @@ "SC-28" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ "SC-28" @@ -826,19 +780,16 @@ "usa-state-vt-act-171-2018": [ "2447(c)(6)" ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "15.5" - ], "emea-sau-cscc-1-2019": [ "2-3-1-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-22" + "emea-esp-decree-311-2022": [ + "Article 23" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6", + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -874,15 +825,13 @@ "6.2.1.21", "6.2.1.22" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS09" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.5" + "apac-sgp-mas-trm-2021": [ + "11.1.3", + "11.1.4", + "11.1.5" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "americas-arg-ppd-2018": [ + "E.1.2-5" ] } }, @@ -908,7 +857,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically prohibit software installations without explicitly assigned privileged status.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically prohibit software installations without explicitly assigned privileged status. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -980,7 +929,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -1088,12 +1038,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "CM-11" - ], - "emea-isr-cmo-1-0": [ - "6.3" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" ] } }, @@ -1117,7 +1061,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to generate an alert when new software is detected.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to generate an alert when new software is detected. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1186,7 +1130,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -1241,6 +1186,9 @@ "general-nist-800-160-vol-2-r1": [ "CM-08(03)" ], + "general-nist-800-172-r3": [ + "03.04.02E" + ], "usa-federal-fbi-cjis-6-0": [ "CM-8(3)" ], @@ -1262,9 +1210,6 @@ ], "usa-federal-cms-marse-2-0": [ "CM-8(3)" - ], - "emea-isr-cmo-1-0": [ - "6.3" ] } }, @@ -1360,7 +1305,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -1484,7 +1430,7 @@ }, "maturity": { "0": "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.", - "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-malware technologies are decentralized but are deployed on all technology assets that can run anti-malware software.", + "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-malware technologies are decentralized but are deployed on all technology assets that can run anti-malware software. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).\n▪ Anti-malware detection tools are configured to automatically update.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize antimalware technologies to detect and eradicate malicious code.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1560,7 +1506,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -1572,7 +1519,7 @@ "CC6.8-POF4" ], "general-cis-csc-8-1": [ - "10.0", + "10", "10.1", "10.4" ], @@ -1635,7 +1582,7 @@ "general-iso-27018-2025": [ "8.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -1926,6 +1873,7 @@ "A.03.14.02.ODP[01]", "A.03.14.02.a[01]", "A.03.14.02.a[02]", + "A.03.14.02.c.01[01]", "A.03.14.02.c.02" ], "general-nist-csf-2-0": [ @@ -2076,31 +2024,31 @@ "6.9.2" ], "emea-deu-c5-2020": [ - "OPS-04", - "OPS-05" + "RB-05" ], - "emea-isr-cmo-1-0": [ - "7.1", - "7.3", - "12.20", - "15.5" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.1" ], "emea-sau-ecc-1-2018": [ "2-3-3-1", - "2-4-3-4", "5-1-3-10" ], "emea-sau-otcc-1-2022": [ + "2-3-1-1", "2-3-1-8" ], "emea-sau-sacs-002-2022": [ - "TPC-12" + "VII.A.TPC-12" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.6" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.6 [OP.EXP.6]" + "emea-gbr-cap-1850-2020": [ + "C2" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5", + "5-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "2411", @@ -2118,7 +2066,7 @@ "2411", "2426" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1284", "ISM-1286", "ISM-1288", @@ -2126,7 +2074,8 @@ "ISM-1290", "ISM-1293", "ISM-1417", - "ISM-1608" + "ISM-1608", + "ISM-1969" ], "apac-ind-sebi-2024": [ "PR.IP.S4" @@ -2144,18 +2093,16 @@ "12.2.1.9", "12.2.1.15" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP62", "HML62" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS10" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP54" ], "apac-nzl-ism-3-9": [ - "14.1.9.C.02" + "14.1.9.C.02", + "21.3.10.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.5" @@ -2163,13 +2110,12 @@ "apac-sgp-mas-trm-2021": [ "11.3.3" ], + "americas-arg-ppd-2018": [ + "E.1.2-6" + ], "americas-bmu-mba-coc-2020": [ "6.12" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ "03.14.02.C", "03.14.02.C.01", @@ -2182,7 +2128,7 @@ "title": "Automatic Antimalware Signature Updates", "family": "END", "description": "Automated mechanisms exist to update antimalware technologies, including signature definitions.", - "scf_question": "Does the organization automatically update antimalware technologies, including signature definitions?", + "scf_question": "Does the organization use automated mechanisms to update antimalware technologies, including signature definitions?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -2199,7 +2145,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware detection tools are configured to automatically update.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically update antimalware technologies, including signature definitions.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically update antimalware technologies, including signature definitions. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2271,7 +2217,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -2476,11 +2423,14 @@ "emea-eu-nis2-annex-2024": [ "6.9.2" ], - "emea-isr-cmo-1-0": [ - "7.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.6" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "5-BP1-1" ], "emea-gbr-def-stan-05-138-2024": [ "2426" @@ -2568,7 +2518,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -2697,7 +2648,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -2740,6 +2692,9 @@ "general-nist-800-171-r3": [ "03.14.02.a" ], + "general-nist-800-171a-r3": [ + "A.03.14.02.a[01]" + ], "general-pci-dss-4-0-1": [ "5.3.4" ], @@ -2776,13 +2731,6 @@ "usa-federal-cms-marse-2-0": [ "SI-3(1)" ], - "emea-isr-cmo-1-0": [ - "7.7", - "12.20" - ], - "apac-sgp-mas-trm-2021": [ - "11.3.5" - ], "americas-can-itsp-10-171-2025": [ "03.14.02.A" ] @@ -2880,7 +2828,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -2986,13 +2935,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "SI-03" ], - "emea-isr-cmo-1-0": [ - "7.8" - ], - "emea-sau-ecc-1-2018": [ - "2-4-3-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1284", "ISM-1286", "ISM-1288", @@ -3024,7 +2967,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to test antimalware technologies by introducing a known benign, non-spreading test case into the system and subsequently verifying that both detection of the test case and associated incident reporting occurs.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to test antimalware technologies by introducing a known benign, non-spreading test case into the system and subsequently verifying that both detection of the test case and associated incident reporting occurs. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3091,7 +3034,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -3129,7 +3073,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to perform periodic evaluations evolving malware threats to assess systems that are generally not considered to be commonly affected by malicious software.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to perform periodic evaluations evolving malware threats to assess systems that are generally not considered to be commonly affected by malicious software. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3196,7 +3140,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -3222,9 +3167,6 @@ ], "general-shared-assessments-sig-2025": [ "J.5.1" - ], - "emea-isr-cmo-1-0": [ - "12.20" ] } }, @@ -3248,7 +3190,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-malware technologies are centralized, deployed on all technology assets that can run anti-malware software.\n▪ Anti-malware technologies are configured to generate event logs that can be centrally-reviewed (e.g., forwarded to a SIEM).\n▪ Anti-malware detection tools are configured to provide real-time protection (e.g., always on).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure that anti-malware technologies are continuously running in real-time and cannot be disabled or altered by non-privileged users, unless specifically authorized by management on a case-by-case basis for a limited time period.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure that anti-malware technologies are continuously running in real-time and cannot be disabled or altered by non-privileged users, unless specifically authorized by management on a case-by-case basis for a limited time period. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3320,7 +3262,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -3361,6 +3304,7 @@ "3.14.5[c]" ], "general-nist-800-171a-r3": [ + "A.03.14.02.a[01]", "A.03.14.02.c.01[01]", "A.03.14.02.c.01[02]" ], @@ -3416,12 +3360,12 @@ "SI-3(IRS-Defined)-1", "SI-3(IRS-Defined)-2" ], - "emea-isr-cmo-1-0": [ - "7.5", - "12.25" + "emea-isr-cmo-2-0": [ + "Appendix A, 2.1" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-8" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP1-2", + "5-BP1-3" ], "emea-gbr-def-stan-05-138-2024": [ "2426" @@ -3532,7 +3476,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -3570,15 +3515,14 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.5.1" ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-22" + ], "emea-gbr-cyber-essentials-requirements-3-3": [ "1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1416" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } }, @@ -3606,7 +3550,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize File Integrity Monitor (FIM), or similar technologies, to detect and report on unauthorized changes to selected files and configuration settings.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -3676,7 +3620,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -3710,7 +3655,7 @@ "general-iec-62443-4-2-2019": [ "CR 3.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.003", "T1020.001", @@ -3963,6 +3908,15 @@ "general-nist-800-161-r1-level-3": [ "SI-7" ], + "general-nist-800-172-r3": [ + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.01E.a[01]", + "A.03.14.01E.ODP[01]", + "DS-A.03.14.01E.a[02]", + "A.03.14.01E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.CM-09" ], @@ -4022,14 +3976,7 @@ "SI-07" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(e)" - ], - "emea-isr-cmo-1-0": [ - "6.4", - "12.19" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "3.4.4.36(e)" ], "emea-gbr-def-stan-05-138-2024": [ "2425" @@ -4069,7 +4016,7 @@ "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to validate configurations through integrity checking of software and firmware.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -4134,7 +4081,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -4181,6 +4129,18 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(01)" ], + "general-nist-800-172-r3": [ + "03.14.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.08E[01]", + "A.03.14.08E.ODP[02]", + "A.03.14.08E.ODP[04]", + "DS-A.03.14.08E[02]", + "A.03.14.08E.ODP[06]", + "DS-A.03.14.08E[03]", + "A.03.14.08E.ODP[10]" + ], "general-swift-cscf-2025": [ "6.2" ], @@ -4231,7 +4191,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to detect and respond to unauthorized configuration changes as cybersecurity incidents.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4302,7 +4262,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -4359,6 +4320,12 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(07)" ], + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" + ], "general-pci-dss-4-0-1": [ "10.7", "10.7.1", @@ -4405,9 +4372,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SI-07 (07)" - ], - "emea-isr-cmo-1-0": [ - "7.2" ] } }, @@ -4429,11 +4393,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically alert incident response personnel upon discovering discrepancies during integrity verification.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically alert incident response personnel upon discovering discrepancies during integrity verification. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -4497,7 +4461,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -4548,11 +4513,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions when integrity violations are discovered.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically implement remediation actions when integrity violations are discovered. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -4616,7 +4581,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -4667,11 +4633,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically verify the integrity of the boot process of systems.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -4735,7 +4701,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -4759,9 +4726,6 @@ ], "general-sparta": [ "CM0014" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 8" ] } }, @@ -4787,7 +4751,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to automatically protect the integrity of boot firmware in systems.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -4853,7 +4817,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -4874,6 +4839,13 @@ "general-nist-800-160-vol-2-r1": [ "SI-07(10)" ], + "general-nist-800-172-r3": [ + "03.14.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.10E", + "A.03.14.10E.ODP[01]" + ], "general-sparta": [ "CM0014" ], @@ -4881,7 +4853,7 @@ "SI-7(CE-10)" ], "apac-aus-cop-sitc-2020": [ - "Principle 8" + "8" ] } }, @@ -4903,7 +4875,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to prohibit the use of binary or machine-executable code from sources with limited or no warranty and without access to source code.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4972,7 +4944,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -5086,13 +5059,30 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { + "general-nist-800-172-r3": [ + "03.14.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.11E" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.7.2", "2.7.3" + ], + "emea-sau-ecc-1-2018": [ + "2-4-3-4" + ], + "emea-sau-otcc-1-2022": [ + "2-3-1-1", + "2-3-1-12" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" ] } }, @@ -5187,7 +5177,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -5218,6 +5209,11 @@ "03.14.06.b", "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" + ], "general-shared-assessments-sig-2025": [ "N.7" ], @@ -5232,17 +5228,7 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.14(b)(1)" ], - "emea-isr-cmo-1-0": [ - "7.4", - "7.5", - "12.18", - "12.24", - "23.6" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1034", "ISM-1341", "ISM-1418" @@ -5250,10 +5236,6 @@ "apac-nzl-ism-3-9": [ "18.4.13.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" - ], "americas-can-itsp-10-171-2025": [ "03.14.06.A.01", "03.14.06.A.02", @@ -5356,12 +5338,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.6", "9.7" ], @@ -5384,7 +5367,7 @@ "general-govramp-high": [ "SI-08" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.001", "T1137.002", @@ -5482,7 +5465,7 @@ "2-4-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-16" + "VII.A.TPC-16" ], "emea-gbr-def-stan-05-138-2024": [ "2509" @@ -5497,28 +5480,16 @@ "2509" ], "apac-nzl-ism-3-9": [ - "15.2.21.C.01", - "15.2.23.C.01", - "15.2.23.C.02", - "15.2.23.C.03", - "15.2.24.C.01", - "15.2.24.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.6" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "15.2.37.C.01" ] } }, { "control_id": "END-08.1", - "title": "Central Management", + "title": "Phishing & Spam Protection Centralized Management", "family": "END", - "description": "Mechanisms exist to centrally-manage anti-phishing and spam protection technologies.", - "scf_question": "Does the organization centrally-manage anti-phishing and spam protection technologies?", + "description": "Mechanisms exist to centrally manage anti-phishing and spam protection technologies.", + "scf_question": "Does the organization centrally manage anti-phishing and spam protection technologies?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5533,7 +5504,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Anti-spam/phishing technologies are centralized and built into existing email capabilities.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Anti-spam/phishing technologies are centralized and built into existing email capabilities.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to centrally-manage anti-phishing and spam protection technologies.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to centrally manage anti-phishing and spam protection technologies.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5618,8 +5589,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control\n- wordsmithed", "family_name": "Endpoint Security", "crosswalks": { "general-nist-800-53-r4": [ @@ -5657,10 +5630,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "PL-09" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } }, @@ -5751,7 +5720,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -5880,7 +5850,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -5908,8 +5879,8 @@ "general-ul-2900-2-2-2016": [ "8.10(b)" ], - "emea-isr-cmo-1-0": [ - "4.37" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6" ] } }, @@ -5935,7 +5906,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to address mobile code / operating system-independent applications.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to address mobile code / operating system-independent applications. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6006,7 +5977,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -6046,7 +6018,7 @@ "NDR 2.4(c)", "NDR 2.4(1)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.003", "T1055", "T1055.001", @@ -6156,9 +6128,14 @@ "A.03.13.13.a[01]", "A.03.13.13.a[02]", "A.03.13.13.b[01]", - "A.03.13.13.b[02]", "A.03.13.13.b[03]" ], + "general-nist-800-172-r3": [ + "03.13.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.06E" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.SE.ACMIT", "3.PEP.WE.ACMIT" @@ -6253,7 +6230,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to configure thin nodes to have minimal functionality and information storage.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to configure thin nodes to have minimal functionality and information storage. ", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6320,7 +6297,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -6335,6 +6313,12 @@ ], "general-nist-800-160-vol-2-r1": [ "SC-25" + ], + "general-nist-800-172-r3": [ + "03.13.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.11E[01]" ] } }, @@ -6425,11 +6409,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1025", "T1052", "T1052.001", @@ -6454,6 +6439,14 @@ "general-nist-800-82-r3-high": [ "SC-41" ], + "general-nist-800-172-r3": [ + "03.13.13E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.13E", + "A.03.13.13E.ODP[02]", + "A.03.13.13E.ODP[03]" + ], "usa-federal-nerc-cip-2024": [ "CIP-007-6 1.2" ] @@ -6548,7 +6541,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -6652,7 +6646,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -6665,16 +6660,8 @@ "general-nist-800-82-r3": [ "SC-42(02)" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-shared-assessments-sig-2025": [ "P.2.2.1" - ], - "emea-zaf-popia-2013": [ - "8", - "9", - "13.1" ] } }, @@ -6751,7 +6738,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -6761,14 +6749,11 @@ "general-nist-800-82-r3": [ "SC-42(04)" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "general-tisax-6-0-3": [ "8.2.6" ], - "emea-zaf-popia-2013": [ - "18" + "emea-aut-dpa-2018": [ + "§ 12(2)" ] } }, @@ -6790,7 +6775,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to utilize sensors that are configured to minimize the collection of information about individuals.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6845,7 +6830,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -6881,9 +6867,6 @@ "general-nist-800-161-r1-level-2": [ "PM-25" ], - "general-scf-dpmp-2025": [ - "7.4" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-25", "SA-08(33)" @@ -6903,8 +6886,8 @@ "emea-sau-cgiot-2024": [ "2-6-3" ], - "emea-zaf-popia-2013": [ - "10" + "emea-che-fadp-2025": [ + "2.1.7.3" ] } }, @@ -6995,7 +6978,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7098,7 +7082,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7182,15 +7167,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-15" ], - "emea-isr-cmo-1-0": [ - "5.6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0231" ], - "apac-chn-pipl-2021": [ - "26" - ], "americas-can-itsp-10-171-2025": [ "03.13.12.A" ] @@ -7214,11 +7193,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to disable or remove collaborative computing devices from critical systems and secure work areas.", "4": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Endpoint Security (END) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -7286,7 +7265,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7392,7 +7372,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7481,7 +7462,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7508,7 +7490,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to ensure the meeting host can positively control an individual's participation in virtual meetings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7557,7 +7539,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7620,7 +7603,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7701,7 +7685,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7810,10 +7795,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", - "crosswalks": {} + "crosswalks": { + "apac-sgp-mas-trm-2021": [ + "11.4.2" + ] + } }, { "control_id": "END-16", @@ -7903,7 +7893,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { @@ -7988,7 +7979,7 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-03" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1006" ] } @@ -8013,7 +8004,7 @@ "0": "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.", "1": "Endpoint Security (END) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with END domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Endpoint security management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are documented and maintained by process owners.\n▪ 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 END domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Endpoint security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Endpoint security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to implement underlying software separation mechanisms to facilitate security function isolation.", + "3": "Endpoint Security (END) 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:\n▪ Policies and standards associated with END domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with END domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain END domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of endpoint security operations (e.g., unified endpoint management solution, etc.).\n▪ 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 END 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).\n▪ An implemented and operational capability exists to implement underlying software separation mechanisms to facilitate security function isolation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8079,7 +8070,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Endpoint Security", "crosswalks": { diff --git a/docs/api/families/GOV.json b/docs/api/families/GOV.json index 499d779c..67808358 100644 --- a/docs/api/families/GOV.json +++ b/docs/api/families/GOV.json @@ -1,7 +1,7 @@ { "family_code": "GOV", - "family_name": "Cybersecurity & Data Protection Governance", - "control_count": 38, + "family_name": "Security, Compliance & Resilience Governance", + "control_count": 42, "controls": [ { "control_id": "GOV-01", @@ -24,9 +24,9 @@ }, "maturity": { "0": "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.", - "1": "Cybersecurity & Data Protection Governance (GOV) capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement and manage the organization's internal control system.\n▪ Legal representation is consulted on an as-needed basis.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -107,10 +107,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF6" @@ -268,6 +268,9 @@ "general-nist-800-171-r3": [ "03.15.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[01]" + ], "general-nist-csf-2-0": [ "GV", "GV.RM-01", @@ -285,9 +288,6 @@ "12.4", "A3.1.2" ], - "general-scf-dpmp-2025": [ - "1.0" - ], "general-sparta": [ "CM0005" ], @@ -431,6 +431,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PM-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(1)" + ], "usa-federal-sro-finra": [ "248.30(a)(2)(ii)", "248.201(e)" @@ -451,18 +454,18 @@ "155.260(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)", - "164.530(c)(1)", - "164.530(i)(1)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)", + "§ 164.530(c)(1)", + "§ 164.530(i)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(a)(2)", - "164.306(a)(3)", - "164.316(a)" + "§ 164.306(a)(1)", + "§ 164.306(a)(2)", + "§ 164.306(a)(3)", + "§ 164.316(a)" ], "usa-federal-irs-1075-2021": [ "PM-1" @@ -536,6 +539,9 @@ "emea-eu-ai-act-2024": [ "Article 17.2" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.1.30" + ], "emea-eu-dora-2023": [ "Article 5.1", "Article 9.4", @@ -568,144 +574,75 @@ "1.1.1(b)", "6.7.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 9", - "Sec 9a", - "Annex" + "emea-eu-psd2-2015": [ + "95(1)", + "97(3)" ], "emea-deu-bsrit-2017": [ - "4.1" + "3.1", + "4.1", + "4.8" ], "emea-deu-c5-2020": [ - "OIS-01" - ], - "emea-grc-pirppd-1997": [ - "10" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "3.2", - "4.25" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35" - ], - "emea-nor-pda-2018": [ - "13", - "14" + "OIS-01", + "OIS-01-BP1", + "OIS-01-DOAR" ], - "emea-pol-act-29-1997": [ - "1", - "36" + "emea-isr-cmo-2-0": [ + "2.A", + "4.2, Stage 0" ], - "emea-rus-federal-law-27-2006": [ - "7", - "19" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-1-2" ], "emea-sau-ecc-1-2018": [ "1-2-1", - "1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "1-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "2-1-1" ], "emea-sau-sama-csf-1-2017": [ "3.1.1" ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 6.1", - "Article 6.2", - "Article 13.1", - "Article 35.1" - ], "emea-esp-decree-311-2022": [ - "13.1", - "35.1", - "5", - "6.1", - "6.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "6.1 [ORG.1]" - ], - "emea-che-fadp-2025": [ - "7" - ], - "emea-tur-lppd-2016": [ - "12" + "Article 8(1)", + "Article 8(2)", + "Article 8(5)", + "Article 9(1)", + "Article 9(1)(a)", + "Article 9(1)(b)", + "Article 9(2)", + "Article 10(1)", + "Article 10(2)", + "Article 10(3)", + "Article 12(6)(a)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-cap-1850-2020": [ - "A1" + "A1", + "B1" ], - "apac-aus-privacy-act-1998": [ - "APP Part 1", - "APP Part 11" + "apac-aus-ism-2026-march": [ + "ISM-0047" ], - "apac-aus-ism-2024-june": [ - "ISM-0888" + "apac-aus-ps-cps-230-2023": [ + "12(a)", + "16(c)" ], "apac-aus-ps-cps-234-2019": [ - "13", - "18", - "19" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-chn-pipl-2021": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" - ], - "apac-hkg-pdo-2022": [ - "Principle 4" - ], - "apac-ind-privacy-rules-2011": [ - "8" + "15", + "17" ], "apac-ind-sebi-2024": [ "GV.OC.S1", "GV.OC.S2", "PR.IP.S17" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "4.4.1.1", "4.4.1.2", @@ -718,41 +655,22 @@ "5.1.1", "6.1" ], - "apac-mys-pdpa-2010": [ - "9" + "apac-mys-bnm-rmit-2025": [ + "10.1", + "11.1", + "11.2", + "11.5" ], "apac-nzl-ism-3-9": [ - "5.1.14.C.01" - ], - "apac-phl-dpa-2012": [ - "25", - "27", - "28" - ], - "apac-sgp-pdpa-2012": [ - "12", - "24" - ], - "apac-kor-pipa-2011": [ - "3", - "29", - "30" - ], - "apac-twn-pdpa-2025": [ - "27" + "5.1.14.C.01", + "5.1.16.C.01", + "16.1.24.C.01" ], - "americas-bhs-dpa-2003": [ - "6" + "apac-sgp-mas-trm-2021": [ + "3.1.4" ], "americas-bmu-mba-coc-2020": [ - "4", - "5.4" - ], - "amaericas-can-osfi-self-assessment": [ - "6.5", - "6.6", - "6.7", - "6.23" + "6.1" ], "americas-can-osfi-b13-2022": [ "1", @@ -761,20 +679,11 @@ "2.1.1", "3" ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4" - ], - "americas-mex-fdpa-2010": [ - "19" ] } }, @@ -799,9 +708,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to trends.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align security, compliance and resilience capabilities with business requirements through a steering committee or advisory board, comprised of key cybersecurity, data protection and business executives, which meets formally and on a regular basis.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align security, compliance and resilience capabilities with business requirements through a steering committee or advisory board, comprised of key cybersecurity, data protection and business executives, which meets formally and on a regular basis.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -877,10 +786,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", @@ -1035,6 +944,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-csf-2-0": [ "GV.RM-01", "GV.RM-03", @@ -1137,9 +1049,9 @@ "500.4(d)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(2)", - "3.2.1(3)", - "3.2.1(4)" + "3.2.1.2", + "3.2.1.3", + "3.2.1.4" ], "emea-eu-dora-2023": [ "Article 5.2", @@ -1174,21 +1086,46 @@ "2.2", "2.3", "2.4", - "2.5" + "2.5", + "4.3" + ], + "emea-deu-c5-2020": [ + "OIS-01" + ], + "emea-isr-cmo-2-0": [ + "2.A" ], "emea-sau-cgiot-2024": [ "1-1-4" ], - "emea-sau-sama-csf-1-2017": [ - "3.1.1" + "emea-sau-ecc-1-2018": [ + "1-1-1", + "1-2-3", + "1-4-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 27" + "emea-sau-sama-csf-1-2017": [ + "3.1.1.1", + "3.1.1.2", + "3.1.1.3", + "3.1.1.3.a", + "3.1.1.3.b", + "3.1.1.3.c", + "3.1.1.4", + "3.1.1.4.a", + "3.1.1.4.b", + "3.1.1.4.c", + "3.1.1.4.d", + "3.1.1.5", + "3.1.1.6", + "3.1.1.7", + "3.1.1.8", + "3.1.1.9", + "3.1.1.9.a", + "3.1.1.9.b", + "3.1.1.9.c" ], "emea-esp-decree-311-2022": [ - "27", - "5" + "Article 12(1)(d)" ], "emea-gbr-caf-4-0": [ "A1.a", @@ -1212,22 +1149,24 @@ "1103", "1202" ], - "apac-aus-ism-2024-june": [ - "ISM-0725" + "apac-aus-ism-2026-march": [ + "ISM-0725", + "ISM-1998", + "ISM-1999", + "ISM-2002", + "ISM-2003", + "ISM-2005", + "ISM-2006" ], "apac-aus-ps-cps-230-2023": [ - "20", - "21", - "22(a)", - "22(b)", - "22(c)", - "23", + "16(a)", + "17", + "18", "24", - "25" + "27(a)" ], "apac-aus-ps-cps-234-2019": [ - "13", - "19" + "13" ], "apac-ind-dpdpa-2023": [ "8(6)", @@ -1265,7 +1204,16 @@ "4.6.3.2", "4.6.3.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.3", + "8.4", + "8.5", + "8.7", + "11.17", + "12.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP12", "HML12", "HML21" @@ -1280,41 +1228,27 @@ "apac-sgp-mas-trm-2021": [ "3.1.1", "3.1.2", - "3.1.3", - "3.1.4", "3.1.5", - "3.1.6", + "3.1.7", "3.1.7(a)", "3.1.7(b)", "3.1.7(c)", "3.1.7(d)", "3.1.7(e)", "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", - "3.1.8(e)" + "3.1.7(g)" ], "americas-bmu-mba-coc-2020": [ - "5.1", - "5.6" - ], - "amaericas-can-osfi-self-assessment": [ - "6.5", - "6.6", - "6.7", - "6.21", - "6.22", - "6.23", - "6.24" + "5.1" ], "americas-can-osfi-b13-2022": [ "1", "1.1.2", "1.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] @@ -1325,7 +1259,7 @@ "title": "Status Reporting To Governing Body", "family": "GOV", "description": "Mechanisms exist to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", - "scf_question": "Does the organization provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP)?", + "scf_question": "Does the organization provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to its Security, Compliance & Resilience Program (SCRP)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1347,9 +1281,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to trends.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1406,10 +1340,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF2", @@ -1485,6 +1419,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-csf-2-0": [ "GV.OV", "GV.OV-01", @@ -1493,16 +1430,16 @@ "GV.SC-09", "ID" ], - "general-scf-dpmp-2025": [ - "11.5", - "11.8" - ], "usa-federal-doe-c2m2-2-1": [ "PROGRAM-2g" ], "usa-federal-sro-fca-crm-2023": [ "609.930(e)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(14)", + "101.645(a)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(i)", "314.4(i)(1)", @@ -1523,8 +1460,8 @@ "500.4(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(e)", - "3.3.5(24)" + "3.3.1.13(e)", + "3.3.5.24" ], "emea-eu-dora-2023": [ "Article 5.2(i)", @@ -1539,19 +1476,29 @@ "13.2.2(c)" ], "emea-deu-bsrit-2017": [ - "3.9", "3.11", "4.10", "7.5" ], - "apac-aus-ism-2024-june": [ - "ISM-0718" + "emea-deu-c5-2020": [ + "SPN-01" + ], + "emea-sau-ecc-1-2018": [ + "1-8-3" + ], + "emea-esp-decree-311-2022": [ + "Article 31(6)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" + ], + "apac-aus-ism-2026-march": [ + "ISM-0718", + "ISM-1918", + "ISM-2000" ], "apac-aus-ps-cps-230-2023": [ - "30", - "58(a)", - "58(b)", - "58(c)" + "58" ], "apac-ind-dpdpa-2023": [ "10(2)(c)(ii)" @@ -1562,7 +1509,13 @@ "apac-jpn-ismap": [ "4.6.1.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.4", + "8.6", + "9.3", + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP46", "HHSP75", "HML12", @@ -1574,6 +1527,10 @@ "HSUP38", "HSUP65" ], + "apac-sgp-mas-trm-2021": [ + "3.1.3", + "3.1.8(e)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1.2" @@ -1588,7 +1545,7 @@ "title": "Commitment To Continual Improvements", "family": "GOV", "description": "Mechanisms exist to commit appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", - "scf_question": "Does the organization commit appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies?", + "scf_question": "Does the organization commit appropriate resources needed for continual improvement of its Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -1603,7 +1560,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to observed trends.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ Appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ Appropriate resources needed for continual improvement of the organization's Security, Compliance & Resilience Program (SCRP), including:\n(1) Staffing;\n(2) Budget;\n(3) Processes; and\n(4) Technologies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1645,10 +1602,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.3-POF4" @@ -1691,14 +1648,175 @@ "EF:SG3.SP3", "EF:SG4.SP3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.48" + ], "emea-eu-nis2-annex-2024": [ "1.1.1(d)", "1.1.1(e)" ], + "emea-deu-bsrit-2017": [ + "2.2", + "4.4" + ], + "emea-deu-c5-2020": [ + "OIS-01-BP3", + "SA-02-BP2" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stage 5", + "Appendix A, 1.1" + ], + "emea-sau-ecc-1-2018": [ + "1-1-3", + "1-3-4", + "2-3-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-69" + ], + "emea-esp-decree-311-2022": [ + "Article 12(6)(ñ)", + "Article 27" + ], "apac-jpn-ismap": [ "4.6.1.1", "4.6.1.2", "4.6.3.3" + ], + "apac-mys-bnm-rmit-2025": [ + "8.2", + "8.4" + ] + } + }, + { + "control_id": "GOV-01.4", + "title": "Secure Practices Alignment Justification", + "family": "GOV", + "description": "Mechanisms exist to align the organization’s Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices.", + "scf_question": "Does the organization align its Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices?", + "relative_weight": 8, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to align the organization’s Security, Compliance & Resilience Program (SCRP) with one or more industry-recognized frameworks that:\n(1) Support external scrutiny; and\n(2) Provide defensible justification for secure practices.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Informal alignment with NIST CSF 2.0, SCF CORE Fundamentals, CIS Controls or another framework that meets the organization's needs.", + "small": "∙ Formal alignment with NIST CSF 2.0, SCF CORE Fundamentals, CIS Controls or another framework that meets the organization's needs.\n∙ Gap analysis documentation\n∙ Written justification for framework choices.", + "medium": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ Documented gap analysis and justification\n∙ GRC platform alignment reports (e.g., SCFConnect)", + "large": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ Regulatory mapping evidence packages\n∙ GRC platform with framework comparison reporting", + "enterprise": "∙ Formal alignment to a framework or metaframework capable of addressing security, compliance and resilience needs.\n∙ External auditor validation\n∙ Board-level reporting on framework compliance\n∙ GRC platform with automated framework mapping" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "emea-eu-psd2-2015": [ + "98(1)", + "98(1)(a)", + "98(1)(b)", + "98(1)(c)", + "98(1)(d)", + "98(2)", + "98(3)", + "98(4)", + "98(5)" + ], + "emea-deu-bsrit-2017": [ + "2.1" + ], + "emea-deu-c5-2020": [ + "OIS-01", + "RB-22-DOAR" + ], + "emea-sau-otcc-1-2022": [ + "1-1-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.3", + "3.2.3.1", + "3.2.3.1.a", + "3.2.3.1.b", + "3.2.3.1.c" + ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(b)" + ], + "apac-nzl-ism-3-9": [ + "5.1.16.C.02" ] } }, @@ -1726,7 +1844,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.\n▪ No formal cybersecurity and/or data protection principles are identified for the organization.\n▪ Informal recommendations are leveraged to update existing policies and standards.\n▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.\n▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).\n▪ People affected by documentation changes are provided notification of the policy and standard changes.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).\n▪ The organization's cybersecurity policies and standards are made available to internal personnel.\n▪ Documented procedures exist for requesting a deviation from approved standards.\n▪ The responsibility for enforcing cybersecurity and data protection control implementation is assigned to business / process owners and asset custodians.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1799,10 +1917,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.0", @@ -2369,6 +2487,19 @@ "A.03.15.01.a[03]", "A.03.15.01.a[04]" ], + "general-nist-800-172-r3": [ + "03.01.17E", + "03.05.07E", + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.17E.ODP[02]", + "A.03.05.07E.ODP[01]", + "DS-A.03.17.03E.a[01]", + "DS-A.03.17.03E.a[02]", + "DS-A.03.17.03E.a[03]", + "DS-A.03.17.03E.a[04]" + ], "general-nist-csf-2-0": [ "GV.PO", "GV.PO-01", @@ -2506,9 +2637,6 @@ "12.1.2", "12.1.3" ], - "general-scf-dpmp-2025": [ - "11.2" - ], "general-sparta": [ "CM0088" ], @@ -2659,6 +2787,9 @@ "SI-01", "SR-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)" + ], "usa-federal-sro-finra": [ "248.30(a)(1)", "248.30(a)(2)" @@ -2674,41 +2805,41 @@ "155.260(d)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)", - "164.530(j)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)", + "§ 164.530(j)(1)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(A)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)", - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)", - "164.310(b)", - "164.310(d)(1)", - "164.310(d)(2)(i)", - "164.312(a)(1)", - "164.312(c)(1)", - "164.316(a)", - "164.316(b)(1)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(A)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)", + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)", + "§ 164.310(b)", + "§ 164.310(d)(1)", + "§ 164.310(d)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.312(c)(1)", + "§ 164.316(a)", + "§ 164.316(b)(1)(i)" ], "usa-federal-irs-1075-2021": [ "2.C.2", @@ -2818,6 +2949,10 @@ "17.03(2)(c)", "17.04" ], + "usa-state-nv-privacy-law-2023": [ + "603A.525.2", + "603A.525.2(a)" + ], "usa-state-nv-regulation-5-2024": [ "5.260.6" ], @@ -2913,9 +3048,9 @@ "SI-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.1(28)", - "3.4.1(29)", - "3.4.5(38)" + "3.4.1.28", + "3.4.5.38", + "3.5.50" ], "emea-eu-dora-2023": [ "Article 6.2", @@ -2949,127 +3084,122 @@ "9.1", "11.1.1" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.2", - "4.3", "4.8" ], "emea-deu-c5-2020": [ - "OIS-01", "OIS-02", - "SP-01" - ], - "emea-isr-cmo-1-0": [ - "1.1", - "4.1", - "4.25", - "5.2", - "5.3", - "9.1", - "10.1", - "11.2", - "12.1", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "20.1", - "21.1", - "22.1", - "24.1", - "25.1" - ], - "emea-nga-dpr-2019": [ - "4.1(1)" - ], - "emea-qat-pdppl-2020": [ - "8.4" + "OIS-06", + "SA-01", + "SA-01-BP1", + "SA-01-BP2", + "SA-01-BP3", + "SA-01-BP4", + "SA-01-BP5", + "SA-01-BP6", + "MDM-01" ], "emea-sau-cgiot-2024": [ "1-2-1" ], "emea-sau-ecc-1-2018": [ "1-3-1", - "1-3-3" + "1-3-3", + "2-1-1", + "2-1-2", + "2-1-3", + "2-1-4", + "2-2-1", + "2-2-2" ], "emea-sau-otcc-1-2022": [ - "1-1", - "1-1-1" + "1-1-1", + "1-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-25" + "VII.B.TPC-24", + "VII.B.TPC-25" ], "emea-sau-sama-csf-1-2017": [ - "3.1.3" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 12.1", - "Article 12.1(a)", - "Article 12.1(b)", - "Article 12.1(c)", - "Article 12.1(d)", - "Article 12.1(e)", - "Article 12.1(f)", - "Article 12.2", - "Article 12.6", - "Article 12.6(a)", - "Article 12.6(b)", - "Article 12.6(c)", - "Article 12.6(d)", - "Article 12.6(e)", - "Article 12.6(f)", - "Article 12.6(g)", - "Article 12.6(h)", - "Article 12.6(i)", - "Article 12.6(j)", - "Article 12.6(k)", - "Article 12.6(l)", - "Article 12.6(m)", - "Article 12.6(n)", - "Article 12.6(ñ)", - "Article 12.7" + "3.1.3", + "3.1.3.1", + "3.1.3.3", + "3.1.3.3.a", + "3.1.3.3.b", + "3.1.3.3.c", + "3.1.3.3.d", + "3.1.3.4", + "3.1.3.4.a", + "3.1.3.4.b", + "3.1.3.4.c", + "3.1.3.4.d", + "3.1.3.4.e", + "3.1.3.4.f", + "3.1.3.4.f.1", + "3.1.3.4.f.2", + "3.1.3.4.f.3", + "3.1.3.4.f.4", + "3.1.3.4.f.5", + "3.1.3.4.f.6", + "3.1.3.4.f.7", + "3.1.3.4.f.8", + "3.3.5.1", + "3.3.5.4", + "3.3.5.4.a", + "3.3.5.4.b", + "3.3.5.4.b.1", + "3.3.5.4.b.2", + "3.3.5.4.b.3", + "3.3.5.4.b.4", + "3.3.5.4.b.5", + "3.3.5.4.b.6", + "3.3.5.4.b.7", + "3.3.5.4.c", + "3.3.5.4.d", + "3.3.5.4.e", + "3.3.5.4.f", + "3.3.5.4.f.1", + "3.3.5.4.f.1.a", + "3.3.5.4.f.1.b", + "3.3.5.4.f.2", + "3.3.5.4.f.3", + "3.3.5.4.f.4", + "3.3.5.4.f.4.a", + "3.3.5.4.f.4.b", + "3.3.5.4.f.4.c", + "3.3.8", + "3.3.8.1", + "3.3.8.4", + "3.3.8.5", + "3.3.8.6", + "3.3.8.6.a", + "3.3.8.6.b", + "3.3.8.6.c", + "3.3.8.6.d", + "3.3.8.6.e", + "3.3.8.6.f", + "3.3.8.6.g", + "3.3.8.6.h", + "3.3.8.6.h.1", + "3.3.8.6.h.2", + "3.3.8.6.h.3", + "3.3.8.6.h.4", + "3.3.8.6.h.5", + "3.3.8.6.i", + "3.3.8.6.j", + "3.3.10", + "3.3.10.1" ], "emea-esp-decree-311-2022": [ - "12.1", - "12.1(a)", - "12.1(b)", - "12.1(c)", - "12.1(d)", - "12.1(e)", - "12.1(f)", - "12.2", - "12.6", - "12.6(a)", - "12.6(b)", - "12.6(c)", - "12.6(d)", - "12.6(e)", - "12.6(f)", - "12.6(g)", - "12.6(h)", - "12.6(i)", - "12.6(j)", - "12.6(k)", - "12.6(l)", - "12.6(m)", - "12.6(n)", - "12.6(ñ)", - "12.7" - ], - "emea-esp-ccn-stic-825-2023": [ - "6.1 [ORG.1]", - "6.2 [ORG.2]" + "Article 11(3)", + "Article 12(1)", + "Article 12(6)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-caf-4-0": [ "A1", @@ -3077,8 +3207,7 @@ "B1.b" ], "emea-gbr-cap-1850-2020": [ - "A1", - "A5" + "A1" ], "emea-gbr-def-stan-05-138-2024": [ "1100", @@ -3103,20 +3232,23 @@ "2101" ], "apac-aus-privacy-principles-2026": [ - "APP 1" + "1.1.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0047", - "ISM-0888", "ISM-1478", "ISM-1551", "ISM-1602", "ISM-1784", - "ISM-1785" + "ISM-1785", + "ISM-2074" + ], + "apac-aus-ps-cps-230-2023": [ + "12(a)", + "47" ], "apac-aus-ps-cps-234-2019": [ - "18", - "19" + "18" ], "apac-ind-sebi-2024": [ "GV.PO.S1" @@ -3134,12 +3266,16 @@ "6", "6.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HML01", - "HHSP01" + "apac-mys-bnm-rmit-2025": [ + "8.6", + "9.5", + "10.16", + "10.20", + "11.12" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS02" + "HML01", + "HHSP01" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP01" @@ -3155,21 +3291,55 @@ "5.1.20.C.01", "5.1.20.C.02", "5.2.3.C.01", - "5.2.3.C.02" + "5.2.3.C.02", + "11.1.15.C.01", + "11.1.15.C.02", + "11.3.5.C.01", + "11.4.9.C.01", + "11.5.13.C.01", + "11.8.3.C.01", + "16.1.24.C.01", + "20.2.15.C.04", + "21.1.6.C.01", + "22.1.10.C.01", + "22.1.22.C.01" + ], + "apac-sgp-pdpa-2012": [ + "3.12(a)", + "3.12(c)" + ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(a)" ], "apac-sgp-mas-trm-2021": [ - "3.2.1" + "3.1.8(c)", + "3.2.1", + "3.3.1(d)", + "5.3.1", + "6.1.3", + "6.4.4", + "11.1.1" ], - "amaericas-can-osfi-self-assessment": [ - "6.1", - "6.3" + "americas-bmu-mba-coc-2020": [ + "5.3", + "7.1" ], "americas-can-osfi-b13-2022": [ "1", "3" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "2.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4" + ], + "americas-col-law-1581-2012": [ + "VI.17(k)" ] } }, @@ -3195,7 +3365,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to prohibit exceptions to standards, except when the exception has been formally assessed for risk impact, approved and recorded.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to prohibit exceptions to standards, except when the exception has been formally assessed for risk impact, approved and recorded.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3271,9 +3441,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-cobit-2019": [ "DSS06.04" @@ -3292,11 +3463,14 @@ "2.3.7", "2.7.3" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(14)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(ii)(B)(1)" + "§ 164.306(d)(3)(ii)(B)(1)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.1", @@ -3308,11 +3482,18 @@ "500.12(b)", "500.15(b)" ], + "emea-deu-c5-2020": [ + "SA-03" + ], "apac-ind-sebi-2024": [ "GV.PO.S3" ], "apac-jpn-ismap": [ "5.1.1.7" + ], + "apac-sgp-mas-trm-2021": [ + "3.2.2", + "7.3.3" ] } }, @@ -3336,9 +3517,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel perform an annual documentation review process that includes the scope of applicable statutory, regulatory and/or contractual obligations.\n▪ Recommendations for documentation edits are submitted for review and are handled in accordance with documentation change control processes.\n▪ Updated documentation versions are published, based on no less than an annual review cycle.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to review the Security, Compliance & Resilience Program (SCRP), including policies, standards and procedures, at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to review the Security, Compliance & Resilience Program (SCRP), including policies, standards and procedures, at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness. ", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3393,10 +3574,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF5", @@ -3832,7 +4013,8 @@ "general-nist-800-171a-r3": [ "A.03.15.01.ODP[01]", "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.b[02]", + "A.03.15.03.d[01]" ], "general-nist-csf-2-0": [ "GV.PO-02", @@ -3936,9 +4118,6 @@ "12.1.1", "12.1.2" ], - "general-scf-dpmp-2025": [ - "11.3" - ], "general-tisax-6-0-3": [ "1.5.1" ], @@ -4053,6 +4232,9 @@ "SI-01", "SR-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(b)", "314.4(g)" @@ -4061,16 +4243,16 @@ "155.260(a)(5)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)", - "164.530(i)(2)(i)", - "164.530(i)(2)(ii)", - "164.530(i)(2)(iii)", - "164.530(i)(3)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)", + "§ 164.530(i)(2)(i)", + "§ 164.530(i)(2)(ii)", + "§ 164.530(i)(2)(iii)", + "§ 164.530(i)(3)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.316(b)(1)(ii)", - "164.316(b)(2)(iii)" + "§ 164.316(b)(1)(ii)", + "§ 164.316(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "AC-1", @@ -4191,7 +4373,7 @@ "2447(b)(9)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(14)" + "3.3.1.14" ], "emea-eu-nis2-annex-2024": [ "1.1.2", @@ -4199,39 +4381,18 @@ "5.1.6", "6.7.3" ], - "emea-us-psd2-2015": [ - "3" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.2", - "4.8" + "4.4" ], "emea-deu-c5-2020": [ - "OIS-01", - "SP-02" + "SA-02", + "SA-02-BP1", + "SA-02-BP2", + "SA-02-BP3" ], - "emea-isr-cmo-1-0": [ - "1.1", - "5.2", - "9.1", - "10.1", - "11.2", - "13.1", - "14.1", - "15.1", - "17.1", - "18.1", - "21.1", - "22.1", - "24.1", - "25.1" + "emea-isr-cmo-2-0": [ + "Appendix A, 1.1" ], "emea-sau-cgiot-2024": [ "1-1-4", @@ -4242,11 +4403,8 @@ "emea-sau-ecc-1-2018": [ "1-1-3", "1-3-4", - "1-6-4", - "1-9-6", - "1-10-5", - "2-2-4", - "2-3-4", + "1-4-2", + "2-1-6", "2-4-4", "2-5-4", "2-6-4", @@ -4267,11 +4425,13 @@ "emea-sau-otcc-1-2022": [ "1-1-3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 27" + "emea-sau-sama-csf-1-2017": [ + "3.1.3.2" ], - "emea-esp-decree-311-2022": [ - "27" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "org.3" ], "emea-gbr-caf-4-0": [ "B1.a" @@ -4291,12 +4451,10 @@ "2100", "2101" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ + "ISM-0888", "ISM-1617" ], - "apac-aus-ps-cps-234-2019": [ - "19" - ], "apac-ind-sebi-2024": [ "GV.PO.S2", "GV.PO.S3", @@ -4312,7 +4470,10 @@ "5.1.2.3", "5.1.2.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP67", "HML66" ], @@ -4325,7 +4486,7 @@ "5.1.21.C.02" ], "apac-sgp-mas-trm-2021": [ - "3.2.2" + "3.2.1" ], "americas-can-osfi-b13-2022": [ "1", @@ -4365,9 +4526,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is assigned the role and responsibilities to centrally manage, coordinate, develop, implement and maintain a cybersecurity and data protection program (e.g., cybersecurity director or Chief Information Security Officer (CISO)).\n▪ The individual assigned the role and responsibilities to centrally manage, coordinate, develop, implement and maintain a cybersecurity and data protection program develops plans to implement the organization's security, compliance and resiliency-related objectives.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ A qualified individual is assigned the role and responsibilities to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP) (e.g., cybersecurity director or Chief Information Security Officer (CISO)).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ A qualified individual is assigned the role and responsibilities to centrally-manage, coordinate, develop, implement and maintain an enterprise-wide Security, Compliance & Resilience Program (SCRP) (e.g., cybersecurity director or Chief Information Security Officer (CISO)).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4438,10 +4599,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1" @@ -4708,6 +4869,11 @@ "PM-06", "PM-29" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)", + "101.620(b)(3)", + "101.625(c)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(a)", "314.4(a)(1)", @@ -4715,10 +4881,10 @@ "314.4(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(2)" + "§ 164.308(a)(2)" ], "usa-federal-irs-1075-2021": [ "PM-2", @@ -4767,9 +4933,7 @@ "Article 17.1(m)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.3.1(12)", - "3.7.5(91)" + "3.3.1.11" ], "emea-eu-dora-2023": [ "Article 5.2", @@ -4791,33 +4955,54 @@ "1.2.1", "1.2.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ - "4.4", "4.5", "4.6" ], - "emea-deu-c5-2020": [ - "OIS-03" + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B" ], "emea-sau-ecc-1-2018": [ "1-2-2", - "1-4-1", - "1-4-2", - "1-5-2" - ], - "emea-sau-otcc-1-2022": [ - "1-2", - "1-2-1-2" + "1-4-1" ], "emea-sau-sama-csf-1-2017": [ - "3.1.4" + "3.1.4", + "3.1.4.4", + "3.1.4.4.a", + "3.1.4.4.a.1", + "3.1.4.4.a.2", + "3.1.4.4.a.3", + "3.1.4.4.a.4", + "3.1.4.4.b", + "3.1.4.4.c", + "3.1.4.4.d", + "3.1.4.4.e", + "3.1.4.4.e.1", + "3.1.4.4.e.2", + "3.1.4.4.e.3", + "3.1.4.4.e.4", + "3.1.4.4.e.5", + "3.1.4.4.f", + "3.1.4.4.g", + "3.1.4.4.g.1", + "3.1.4.4.g.2", + "3.1.4.4.g.3", + "3.1.4.4.h", + "3.1.4.4.i", + "3.1.4.4.i.1", + "3.1.4.4.i.2", + "3.1.4.4.i.3", + "3.1.4.4.i.4" + ], + "emea-esp-decree-311-2022": [ + "Article 13(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "emea-gbr-caf-4-0": [ "A1.b", @@ -4838,7 +5023,7 @@ "1102", "1103" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0714", "ISM-0717", "ISM-0720", @@ -4849,22 +5034,17 @@ "ISM-0732", "ISM-0733", "ISM-0734", - "ISM-0735" + "ISM-0735", + "ISM-1997" ], "apac-aus-ps-cps-230-2023": [ - "21", - "24" + "23" ], "apac-aus-ps-cps-234-2019": [ - "14", - "19" + "14" ], "apac-chn-data-security-law-2021": [ - "45", - "46" - ], - "apac-chn-pipl-2021": [ - "52" + "Article 27" ], "apac-ind-dpdpa-2023": [ "19(3)" @@ -4879,7 +5059,11 @@ "5.1.1.6", "5.1.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6", + "9.4" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21", "HHSP27", "HML21", @@ -4920,32 +5104,24 @@ "3.2.19.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.1.7(a)", - "3.1.7(b)", - "3.1.7(c)", - "3.1.7(d)", - "3.1.7(e)", - "3.1.7(f)", - "3.1.7(g)", - "3.1.8(a)", - "3.1.8(b)", - "3.1.8(c)", - "3.1.8(d)", - "3.1.8(e)" + "3.1.3", + "3.1.8" + ], + "americas-arg-ppd-2018": [ + "E.1.2-8" ], "americas-bmu-mba-coc-2020": [ "5.2" ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "1.2", - "6.2" - ], "americas-can-osfi-b13-2022": [ "1", "1.1", "1.1.1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.1", + "1.1.2" ] } }, @@ -4969,9 +5145,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to enforce an accountability structure so that appropriate teams and individuals are empowered, responsible and trained for mapping, measuring and managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to enforce an accountability structure so that appropriate teams and individuals are empowered, responsible and trained for mapping, measuring and managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5056,10 +5232,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1", @@ -5134,6 +5310,9 @@ "general-nist-800-37-r2": [ "TASK P-9" ], + "general-nist-800-172a-r3": [ + "A.03.02.03E.ODP[01]" + ], "general-nist-800-218": [ "PO.2.3" ], @@ -5163,6 +5342,9 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)" + ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(c)(1)" ], @@ -5174,14 +5356,55 @@ "Article 17.1(m)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(11)", - "3.7.5(91)" + "3.3.1.11", + "3.3.1.12" ], "emea-deu-bsrit-2017": [ "4.5", "4.6", "4.10" ], + "emea-deu-c5-2020": [ + "SA-01-BP4" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" + ], + "emea-qat-pdppl-2020": [ + "3.11.2" + ], + "emea-sau-ecc-1-2018": [ + "1-4-1" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.4.1", + "3.1.4.1.a", + "3.1.4.1.b", + "3.1.4.1.c", + "3.1.4.1.c.1", + "3.1.4.1.c.2", + "3.1.4.1.c.3", + "3.1.4.2", + "3.1.4.2.a", + "3.1.4.2.b", + "3.1.4.2.c", + "3.1.4.2.c.1", + "3.1.4.2.c.2", + "3.1.4.2.c.3", + "3.1.4.2.c.4", + "3.1.4.2.c.5", + "3.1.4.2.c.6", + "3.1.4.3", + "3.1.4.3.a", + "3.1.4.3.b", + "3.1.4.3.c", + "3.1.4.5", + "3.1.4.5.a" + ], + "emea-esp-decree-311-2022": [ + "Article 11(2)", + "Article 13(3)" + ], "emea-gbr-caf-4-0": [ "A1.b" ], @@ -5197,14 +5420,19 @@ "1101", "1103" ], - "apac-aus-ps-cps-230-2023": [ - "21" + "apac-aus-ps-cps-234-2019": [ + "14" ], "apac-ind-sebi-2024": [ "GV.RR.S1", "GV.RR.S2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6", + "10.35", + "11.8" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21", "HHSP27", "HML21", @@ -5214,11 +5442,23 @@ "HSUP19", "HSUP23" ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(c)", + "3.1.8", + "3.1.8(a)", + "3.1.8(b)", + "3.1.8(c)", + "3.1.8(d)", + "3.1.8(e)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1", "1.1.1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } }, @@ -5244,7 +5484,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish an authoritative chain of command with clear lines of communication to remove ambiguity from individuals and teams related to managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish an authoritative chain of command with clear lines of communication to remove ambiguity from individuals and teams related to managing Technology Assets, Applications, Services and/or Data (TAASD)-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5324,10 +5564,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-pmf-2020": [ "M1.2-POF1" @@ -5399,13 +5639,11 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.4(b)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.1" ], - "emea-deu-bsrit-2017": [ - "4.5", - "4.6", - "4.10" + "emea-sau-ecc-1-2018": [ + "1-4-1" ], "emea-gbr-caf-4-0": [ "A1.b" @@ -5419,19 +5657,28 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1103" ], - "apac-aus-ps-cps-230-2023": [ - "21" + "apac-aus-ps-cps-234-2019": [ + "14" ], "apac-ind-sebi-2024": [ "GV.OC.S1", "GV.PO.S5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "11.8" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP21" ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(c)" + ], "americas-can-osfi-b13-2022": [ "1", "1.1.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } }, @@ -5455,11 +5702,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Basic metrics are developed to provide operational oversight of a limited scope of cybersecurity and data protection controls.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -5505,10 +5752,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.1-POF3", @@ -5632,6 +5879,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-800-207": [ "NIST Tenet 7" ], @@ -5644,9 +5894,6 @@ "GV.SC-09", "ID.IM-03" ], - "general-scf-dpmp-2025": [ - "11.5" - ], "general-tisax-6-0-3": [ "1.2.1" ], @@ -5697,6 +5944,9 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-06" ], + "emea-eu-eba-ict-srm-2025": [ + "3.5.51" + ], "emea-eu-dora-2023": [ "Article 13.4" ], @@ -5706,19 +5956,28 @@ "emea-eu-nis2-annex-2024": [ "1.1.1(j)" ], - "emea-us-psd2-2015": [ - "3" + "emea-deu-bsrit-2017": [ + "2.5", + "4.9" ], "emea-deu-c5-2020": [ - "COM-04" + "OIS-01-BP2" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 5", + "Appendix D" ], "emea-sau-cgiot-2024": [ "1-1-4" ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.2 [OP.MON.2]" + "emea-sau-otcc-1-2022": [ + "1-4-2", + "1-7-2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0724" ], "apac-ind-sebi-2024": [ @@ -5729,7 +5988,10 @@ "apac-jpn-ismap": [ "4.6.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.6" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP46", "HML46" ], @@ -5737,14 +5999,7 @@ "HSUP38" ], "apac-sgp-mas-trm-2021": [ - "4.5.3", - "7.8.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.7" - ], - "amaericas-can-osfi-self-assessment": [ - "6.9" + "4.5.3" ], "americas-can-osfi-b13-2022": [ "1", @@ -5774,11 +6029,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -5821,10 +6076,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", @@ -5881,9 +6136,9 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Organizational leadership maintains an informal process to review and respond to observed trends.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -5929,10 +6184,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2", @@ -5958,6 +6213,12 @@ ], "general-nist-csf-2-0": [ "GV.RM-01" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } }, @@ -5981,9 +6242,9 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity personnel identify and maintain contact information for local and national law enforcement (e.g., FBI field office) in case of cybersecurity incidents that require law enforcement involvement.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -6032,9 +6293,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF4", @@ -6138,7 +6400,7 @@ "IR-06" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 31.4" @@ -6146,29 +6408,6 @@ "emea-deu-c5-2020": [ "OIS-05" ], - "emea-esp-boe-a-2022-7191": [ - "Article 32.1", - "Article 32.2", - "Article 32.3" - ], - "emea-esp-decree-311-2022": [ - "32.1", - "32.2", - "32.3" - ], - "apac-aus-ps-cps-230-2023": [ - "33", - "42", - "51", - "59(a)", - "59(b)" - ], - "apac-aus-ps-cps-234-2019": [ - "35", - "35(a)", - "35(b)", - "36" - ], "apac-jpn-ismap": [ "6.1.3", "6.1.3.1", @@ -6196,11 +6435,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.\n▪ Cybersecurity and data privacy personnel identify and maintain contact information for local, regional and national cybersecurity / data privacy groups and associations.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish contact with selected groups and associations within the security, compliance and resilience communities to: \n(1) Facilitate ongoing cybersecurity and data protection education and training for organizational personnel;\n(2) Maintain currency with recommended cybersecurity and data protection practices, techniques and technologies; and\n(3) Share current cybersecurity and/or data protection-related information including threats, vulnerabilities and incidents.\n", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -6265,10 +6504,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.2-POF4", @@ -6386,8 +6625,8 @@ "6.1.4.5", "6.1.4.6" ], - "amaericas-can-osfi-self-assessment": [ - "3.7" + "americas-can-osfi-self-assessment-2": [ + "3.1.5" ] } }, @@ -6396,7 +6635,7 @@ "title": "Defining Business Context & Mission", "family": "GOV", "description": "Mechanisms exist to define the context of its business model and document the organization's mission.", - "scf_question": "Does the organization define the context of its business model and document the mission of the organization?", + "scf_question": "Does the organization define the context of its business model and document its mission?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -6411,9 +6650,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ The context of the entity's business model and its mission are documented.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ The context of the entity's business model and its mission are documented.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6484,9 +6723,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2-POF1", @@ -6554,9 +6794,6 @@ "GV.OV-01", "GV.SC-03" ], - "general-scf-dpmp-2025": [ - "11.1" - ], "general-shared-assessments-sig-2025": [ "B.1" ], @@ -6570,20 +6807,27 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(4)" + "3.2.1.4", + "3.2.2.5" ], "emea-eu-nis2-annex-2024": [ "1.1.1(b)" ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], "emea-sau-ecc-1-2018": [ "1-1-1" ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(a)" + ], "americas-can-osfi-b13-2022": [ "1.2", "2.1.1" @@ -6595,7 +6839,7 @@ "title": "Define Control Objectives", "family": "GOV", "description": "Mechanisms exist to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", - "scf_question": "Does the organization establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system?", + "scf_question": "Does the organization establish control objectives as the basis for the selection, implementation and management of its internal security, compliance and resilience control system?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -6612,7 +6856,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to establish control objectives as the basis for the selection, implementation and management of the organization's internal security, compliance and resilience control system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6682,10 +6926,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF1", @@ -6763,25 +7007,23 @@ "314.3(b)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)", - "164.308(a)(1)(ii)(B)" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.2.1(5)(c)" + "§ 164.306(b)(1)", + "§ 164.308(a)(1)(ii)(B)" ], "emea-eu-nis2-annex-2024": [ "1.1.1(c)" ], "emea-deu-c5-2020": [ "OIS-01", - "OIS-02" + "OIS-02", + "DLL-01-BP1" ], - "emea-sau-cscc-1-2019": [ - "1-1" + "apac-aus-ps-cps-230-2023": [ + "29" ], "apac-ind-sebi-2024": [ "GV.OC.S1", @@ -6801,8 +7043,8 @@ "control_id": "GOV-10", "title": "Data Governance", "family": "GOV", - "description": "Mechanisms exist to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization facilitate data governance to oversee its policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive and/or regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization facilitate data governance to oversee its policies, standards and procedures so that sensitive and/or regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -6817,7 +7059,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Administrative processes require all employees and contractors to apply cybersecurity and data protection principles in their daily work (e.g., policies & standards).\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to facilitate data governance to oversee the organization's policies, standards and procedures so that sensitive/regulated data is effectively managed and maintained in accordance with applicable statutory, regulatory and contractual obligations.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6890,9 +7132,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.2-POF1" @@ -6939,9 +7182,6 @@ "general-pci-dss-4-0-1": [ "A3.2.5" ], - "general-scf-dpmp-2025": [ - "5.9" - ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -6964,15 +7204,117 @@ "PM-23", "PM-24" ], - "apac-chn-pipl-2021": [ - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.2" + ], + "apac-nzl-ism-3-9": [ + "20.2.16.C.03" + ], + "americas-bmu-mba-coc-2020": [ + "5.3-BP2" ] } }, + { + "control_id": "GOV-10.1", + "title": "Data Catalog", + "family": "GOV", + "description": "Mechanisms exist to identify and catalog the organization's data holdings in a structured format to document each significant data asset.", + "scf_question": "Does the organization identify and catalog its data holdings in a structured format to document each significant data asset?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and catalog the organization's data holdings in a structured format to document each significant data asset.", + "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Spreadsheet-based data inventory\n∙ Manual data catalog template", + "small": "∙ Spreadsheet data catalog with sensitivity classifications\n∙ Data classification register for significant data assets", + "medium": "∙ Data catalog platform (e.g., Collibra, Alation)\n∙ Structured data inventory with metadata\n∙ Microsoft Purview basic tier (https://microsoft.com)", + "large": "∙ Enterprise data catalog (e.g., Collibra (https://collibra.com), Alation (https://alation.com))\n∙ Data lineage tracking\n∙ Microsoft Purview (https://microsoft.com)", + "enterprise": "∙ Enterprise data catalog with automated discovery\n∙ Microsoft Purview or equivalent (https://microsoft.com)\n∙ Automated data lineage and classification at scale" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": {} + }, { "control_id": "GOV-11", "title": "Purpose Validation", @@ -6991,9 +7333,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to monitor mission/business-critical Technology Assets, Applications and/or Services (TAAS) to ensure those resources are being used consistent with their intended purpose.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to monitor mission/business-critical Technology Assets, Applications and/or Services (TAAS) to ensure those resources are being used consistent with their intended purpose.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7058,9 +7400,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-42001-2023": [ "6.2" @@ -7098,8 +7441,8 @@ "control_id": "GOV-12", "title": "Forced Technology Transfer (FTT)", "family": "GOV", - "description": "Mechanisms exist to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", - "scf_question": "Does the organization avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices?", + "description": "Mechanisms exist to avoid and/or constrain the forced exfiltration of sensitive and/or regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", + "scf_question": "Does the organization avoid and/or constrain the forced exfiltration of sensitive and/or regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7112,9 +7455,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to avoid and/or constrain the forced exfiltration of sensitive/regulated information (e.g., Intellectual Property (IP)) to the host government for purposes of market access or market management practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7178,38 +7521,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "apac-chn-cybersecurity-law-2017": [ "Article 28" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" - ], - "apac-chn-pipl-2021": [ - "38", - "38(4)", - "40" + "Article 28" ] } }, @@ -7231,9 +7552,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to constrain the host government's ability to leverage the organization's Technology Assets, Applications and/or Services (TAAS) for economic or political espionage and/or cyberwarfare activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to constrain the host government's ability to leverage the organization's Technology Assets, Applications and/or Services (TAAS) for economic or political espionage and/or cyberwarfare activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7297,44 +7618,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "apac-chn-cybersecurity-law-2017": [ "Article 28" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "Article 27" ], "apac-chn-pipl-2021": [ - "11", - "12", - "38(4)", - "40", - "47(5)", - "60", - "63(3)", - "63(4)", - "64" + "Article 38" ] } }, @@ -7356,9 +7652,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to incorporate security, compliance and resilience principles into Business As Usual (BAU) practices through executive leadership involvement.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to incorporate security, compliance and resilience principles into Business As Usual (BAU) practices through executive leadership involvement.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7421,10 +7717,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC1.1-POF1", @@ -7473,8 +7769,17 @@ "usa-federal-law-ftc-act": [ "45(a)(1)" ], - "apac-aus-ps-cps-230-2023": [ - "24" + "emea-deu-c5-2020": [ + "SA-01-BP4" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], + "emea-sau-ecc-1-2018": [ + "1-9-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2001" ], "apac-ind-sebi-2024": [ "GV.RR.S1" @@ -7483,9 +7788,19 @@ "4.5.2.1", "7.2.1.8" ], + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.6", + "4.1.2" + ], "americas-can-osfi-b13-2022": [ "1.1.1", "3.2.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.1.2" ] } }, @@ -7493,8 +7808,8 @@ "control_id": "GOV-15", "title": "Operationalizing Security, Compliance & Resilience Capabilities", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -7509,9 +7824,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to operationalize security, compliance and resilience practices for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7603,10 +7918,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "errata": "- wordsmithed", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC2.1-POF1", @@ -7679,14 +7995,13 @@ ], "general-nist-800-171-r3": [ "03.15.01.a", + "03.16.01", "03.17.01.a" ], "general-nist-800-171a-r3": [ - "A.03.16.01" - ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "A.03.15.01.a[03]", + "A.03.16.01", + "A.03.17.01.a[01]" ], "general-swift-cscf-2025": [ "2.4" @@ -7720,6 +8035,11 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.30" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)", + "101.625(d)(5)", + "101.650(c)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -7734,12 +8054,12 @@ "155.260(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(b)(1)" + "§ 164.306(a)(1)", + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.l" @@ -7771,6 +8091,10 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], @@ -7778,14 +8102,14 @@ "Article 17.2" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.4(22)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7", @@ -7813,70 +8137,64 @@ "6.7.1" ], "emea-deu-bsrit-2017": [ + "3.4", + "3.6", "5.1" ], - "emea-qat-pdppl-2020": [ - "8.3" + "emea-deu-c5-2020": [ + "UP-01-BP2" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1", + "2-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 5", - "Article 5(a)", - "Article 5(b)", - "Article 5(c)", - "Article 5(d)", - "Article 5(e)", - "Article 5(f)", - "Article 5(g)", - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5", - "Article 28.1", - "Article 37" + "emea-sau-ecc-1-2018": [ + "1-3-2", + "1-9-2", + "1-10-2", + "2-1-2", + "2-1-4", + "2-2-2", + "2-3-2", + "2-4-2", + "2-5-2", + "2-6-2", + "2-8-2", + "2-9-2", + "2-10-2", + "2-11-2", + "2-12-2", + "2-13-2", + "2-14-2", + "2-15-2", + "3-1-2", + "4-2-2", + "5-1-2" ], "emea-esp-decree-311-2022": [ - "28.1", - "37", - "5", - "5(a)", - "5(b)", - "5(c)", - "5(d)", - "5(e)", - "5(f)", - "5(g)", - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" + "Article 13(2)(d)", + "Article 15(1)" ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5" + "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1633", "ISM-1634", "ISM-1635", "ISM-1636" ], "apac-aus-ps-cps-230-2023": [ - "29" + "16(c)" + ], + "apac-aus-ps-cps-234-2019": [ + "21" ], "apac-ind-sebi-2024": [ "GV.RM.S2" @@ -7885,7 +8203,10 @@ "4.4.4.1", "4.5.2.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP16", "HHSP28", @@ -7901,13 +8222,24 @@ "3.2.10.C.04", "3.4.11.C.01" ], + "apac-sgp-mas-trm-2021": [ + "4.1.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.3-BP2", + "5.11-BP4" + ], "americas-can-osfi-b13-2022": [ "1.1.1", "2.1.1", "3.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", + "03.16.01", "03.17.01.A" ] } @@ -7916,8 +8248,8 @@ "control_id": "GOV-15.1", "title": "Select Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7930,9 +8262,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to select required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to select required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8008,10 +8340,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" @@ -8043,9 +8376,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "1.2.1", @@ -8075,6 +8408,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -8085,10 +8421,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-irs-1075-2021": [ "3.3.1.l" @@ -8112,19 +8448,22 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.4(22)", - "3.3.4(23)", - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.3.4.22", + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -8146,53 +8485,37 @@ "Article 21.2(j)" ], "emea-deu-bsrit-2017": [ + "3.4", + "3.6", "5.1" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1" + "emea-deu-c5-2020": [ + "DLL-01-BP1" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.3", - "Article 28.1(a)", - "Article 28.1(b)", - "Article 28.1(c)", - "Article 28.2", - "Article 28.3", - "Article 37" - ], "emea-esp-decree-311-2022": [ - "28.1(a)", - "28.1(b)", - "28.1(c)", - "28.2", - "28.3", - "3.3", - "37" + "Article 28(2)" ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5", - "A6" + "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1634" ], - "apac-aus-ps-cps-230-2023": [ - "29" + "apac-aus-ps-cps-234-2019": [ + "21", + "21(a)", + "21(b)", + "21(c)", + "21(d)" ], "apac-jpn-ismap": [ "4.4.4.1" @@ -8204,6 +8527,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -8214,8 +8540,8 @@ "control_id": "GOV-15.2", "title": "Implement Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", - "scf_question": "Does the organization compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control?", + "description": "Mechanisms exist to compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", + "scf_question": "Does the organization compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8228,9 +8554,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to implement required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to implement required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8321,10 +8647,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" @@ -8358,9 +8685,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1", @@ -8375,6 +8702,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -8385,14 +8715,14 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)", - "164.306(d)(3)(ii)(A)", - "164.308(a)(1)(ii)(B)" + "§ 164.306(a)(1)", + "§ 164.306(d)(3)(ii)(A)", + "§ 164.308(a)(1)(ii)(B)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -8410,6 +8740,10 @@ "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.2", + "603A.215.1" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(b)(ii)(B)" ], @@ -8417,13 +8751,13 @@ "Article 17.1(e)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.1(30)(a)", - "3.4.1(30)(b)", - "3.4.1(30)(c)", - "3.4.1(30)(d)", - "3.4.1(30)(e)", - "3.4.1(30)(f)", - "3.4.1(30)(g)" + "3.4.1.30(a)", + "3.4.1.30(b)", + "3.4.1.30(c)", + "3.4.1.30(d)", + "3.4.1.30(e)", + "3.4.1.30(f)", + "3.4.1.30(g)" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -8445,42 +8779,22 @@ "Article 21.2(j)" ], "emea-deu-bsrit-2017": [ + "3.4", "5.2" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.3", - "11.5", - "11.6" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.3", - "Article 37" - ], - "emea-esp-decree-311-2022": [ - "3.3", - "37" - ], "emea-gbr-caf-4-0": [ "B4.a" ], "emea-gbr-cap-1850-2020": [ - "A5", - "A6", "B4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1635" ], "apac-nzl-ism-3-9": [ @@ -8490,6 +8804,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -8500,8 +8817,8 @@ "control_id": "GOV-15.3", "title": "Assess Controls", "family": "GOV", - "description": "Mechanisms exist to compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", - "scf_question": "Does the organization compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended?", + "description": "Mechanisms exist to compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", + "scf_question": "Does the organization compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8514,9 +8831,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to assess if required security, compliance and resilience controls for each Technology Asset, Application and/or Service (TAAS) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to assess if required security, compliance and resilience controls for Technology Assets, Applications, Services and/or Data (TAASD) under their control are:\n(1) Implemented correctly; and \n(2) Operating as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8606,10 +8923,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC4.2-POF1" @@ -8634,9 +8952,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1" @@ -8653,6 +8971,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(2)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -8663,10 +8984,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -8682,52 +9003,28 @@ "899-bb.2(b)(ii)(B)", "899-bb.2(b)(ii)(B)(4)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)" - ], "emea-eu-dora-2023": [ "Article 7(a)", "Article 7(b)", "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1", - "11.2" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-gbr-cap-1850-2020": [ - "A5", - "A6", - "B4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1636" ], "americas-can-osfi-b13-2022": [ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -8752,9 +9049,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to obtain authorization for the production use of each Technology Asset, Application and/or Service (TAAS) under their control.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to obtain authorization for the production use of each Technology Asset, Application and/or Service (TAAS) under their control.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8844,9 +9141,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-22301-2019": [ "8.1" @@ -8864,9 +9162,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "general-tisax-6-0-3": [ "5.3.1" @@ -8887,10 +9185,10 @@ "155.260(a)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -8914,21 +9212,13 @@ "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.1" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-gbr-cap-1850-2020": [ - "A5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0027" ], "apac-nzl-ism-3-9": [ @@ -8939,6 +9229,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -8963,9 +9256,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to monitor Technology Assets, Applications, Services and/or Data (TAASD) under their control on an ongoing basis for applicable threats and risks, as well as to ensure security, compliance and resilience controls are operating as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to compel data and/or process owners to monitor Technology Assets, Applications, Services and/or Data (TAASD) under their control on an ongoing basis for applicable threats and risks, as well as to ensure security, compliance and resilience controls are operating as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9055,10 +9348,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-iso-27001-2022": [ "9.2.2" @@ -9079,9 +9372,9 @@ "03.15.01.a", "03.17.01.a" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]", + "A.03.17.01.a[01]" ], "usa-federal-dow-dfars-252-204-7012": [ "252.204-7012(b)" @@ -9096,10 +9389,10 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(1)" + "§ 164.306(a)(1)" ], "usa-federal-nispom-2020": [ "§117.18(a)(1)", @@ -9124,31 +9417,15 @@ "Article 7(c)", "Article 7(d)" ], - "emea-qat-pdppl-2020": [ - "8.3", - "11.7", - "11.8" + "emea-sau-cscc-1-2019": [ + "1-1-1" ], "emea-sau-cgiot-2024": [ "1-6-1" ], - "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-2" - ], - "emea-srb-act-9-2018": [ - "50", - "51" - ], - "emea-gbr-cap-1850-2020": [ - "A5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1526" ], - "apac-aus-ps-cps-230-2023": [ - "30" - ], "apac-nzl-ism-3-9": [ "23.2.18.C.01" ], @@ -9156,6 +9433,9 @@ "1.1.1", "2.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A", "03.17.01.A" @@ -9182,9 +9462,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define materiality threshold criteria capable of designating an incident as material.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define materiality threshold criteria capable of designating an incident as material.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9221,9 +9501,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC3.1-POF6" @@ -9254,6 +9535,12 @@ "500.4(b)(5)", "500.9(b)(1)", "500.9(b)(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.9.3" ] } }, @@ -9277,9 +9564,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a risk as a material risk.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a risk as a material risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9313,9 +9600,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-csa-iot-2": [ "RSM-01" @@ -9347,6 +9635,9 @@ "500.4(b)(5)", "500.9(b)(1)", "500.9(b)(2)" + ], + "apac-mys-bnm-rmit-2025": [ + "10.2" ] } }, @@ -9370,9 +9661,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a threat as a material threat.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define criteria necessary to designate a threat as a material threat.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9406,9 +9697,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-csa-iot-2": [ "RSM-01" @@ -9439,7 +9731,7 @@ "title": "Security, Compliance & Resilience Status Reporting", "family": "GOV", "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.", - "scf_question": "Does the organization submit status reporting of the organization's security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required?", + "scf_question": "Does the organization submit status reporting of its security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -9454,9 +9746,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9499,10 +9791,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-aicpa-tsc-2017": [ "CC3.1-POF10", @@ -9516,6 +9808,17 @@ "52.204-25(d)(2)(ii)", "52.204-25(d)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(12)", + "101.625(d)(13)", + "101.630(d)", + "101.630(e)(2)", + "101.630(e)(2)(ii)", + "101.630(e)(3)", + "101.630(e)(4)", + "101.630(f)(3)", + "101.630(f)(5)" + ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(b)", "17 CFR 229.106(d)" @@ -9579,18 +9882,56 @@ "usa-state-va-cdpa-2023": [ "59.1-580.C" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(23)", + "Article 19(8)", + "Article 20(6)" + ], "emea-eu-nis2-annex-2024": [ "1.2.3" ], - "apac-aus-ism-2024-june": [ + "emea-eu-psd2-2015": [ + "96(6)" + ], + "emea-deu-fdpa-2017": [ + "3.5.79(3)" + ], + "emea-grc-pirppd-1997": [ + "B.7.7", + "B.8.2" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(3)" + ], + "emea-ken-pda-2019": [ + "IV.31(5)" + ], + "emea-nga-dpr-2019": [ + "4.1(6)", + "4.1(7)" + ], + "apac-aus-ism-2026-march": [ "ISM-1587" ], + "apac-aus-ps-cps-230-2023": [ + "59", + "59(a)", + "59(b)" + ], "apac-chn-cybersecurity-law-2017": [ "Article 38", "Article 54(1)" ], + "apac-jpn-appi-2020": [ + "IV.5.53(2)" + ], "apac-jpn-ismap": [ "4.5.3.1" + ], + "apac-mys-bnm-rmit-2025": [ + "16.1", + "17.2", + "17.5" ] } }, @@ -9614,7 +9955,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Unstructured review of the cybersecurity and/or data privacy program is performed on an annual basis.\n▪ Administrative processes require all employees and contractors to apply cybersecurity and data protection principles in their daily work (e.g., policies & standards).", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to govern a Quality Management System (QMS) to ensure security, compliance and resilience processes conform with applicable statutory, regulatory and/or contractual obligations.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to govern a Quality Management System (QMS) to ensure security, compliance and resilience processes conform with applicable statutory, regulatory and/or contractual obligations.", "4": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9687,10 +10028,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "general-cobit-2019": [ "APO11.01", @@ -9707,6 +10048,10 @@ "emea-eu-ai-act-2024": [ "Article 16(c)", "Article 17.1" + ], + "apac-sgp-mas-trm-2021": [ + "5.8.1", + "5.8.2" ] } }, @@ -9730,7 +10075,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define the basis for confidence that implemented practices conform to applicable security, compliance and resilience controls, where the control implementation performs as intended.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define the basis for confidence that implemented practices conform to applicable security, compliance and resilience controls, where the control implementation performs as intended.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9785,10 +10130,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "emea-gbr-caf-4-0": [ "A2.c" @@ -9815,7 +10160,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assurance Levels (AL) for assessment activities to standardize the following assurance attributes:\n(1) Depth that addresses the rigor and level of detail of the assessment; and\n(2) Coverage that addresses the scope and breadth of the assessment.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assurance Levels (AL) for assessment activities to standardize the following assurance attributes:\n(1) Depth that addresses the rigor and level of detail of the assessment; and\n(2) Coverage that addresses the scope and breadth of the assessment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9869,9 +10214,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} }, { @@ -9894,7 +10240,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assessment Objectives (AO) to assess the implementation of requirements, when available.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to utilize defined Assessment Objectives (AO) to assess the implementation of requirements, when available.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9948,9 +10294,10 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": { "usa-federal-dow-cert-rmm-1-2": [ "ADM:GG2.GP9", @@ -9983,6 +10330,127 @@ ] } }, + { + "control_id": "GOV-19.3", + "title": "Security, Compliance & Resilince Outsourcing Limitations", + "family": "GOV", + "description": "Mechanisms exist to ensure organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations.", + "scf_question": "Does the organization ensure third-parties involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to ensure organizations involved in developing, implementing and/or maintaining Technology Assets, Applications and/or Services (TAAS) provide assurance of internal oversight capabilities that demonstrate:\n(1) Governance of internal controls;\n(2) Risk management, including analysis and mitigation activities; and\n(3) Compliance with applicable laws, regulations and contractual obligations.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Vendor due diligence checklist\n∙ Third-party security questionnaire (e.g., CAIQ, SIG)", + "small": "∙ Vendor security questionnaire (CAIQ or SIG)\n∙ Third-party risk assessment prior to outsourcing", + "medium": "∙ Third-party risk management program\n∙ Vendor security assessments with contractual security obligations\n∙ Contract security requirements for outsourced functions", + "large": "∙ Third-party risk management (TPRM) program\n∙ Vendor SOC 2 and ISO 27001 certification requirements\n∙ Contractual security and compliance obligations", + "enterprise": "∙ Enterprise TPRM program with automated vendor risk assessment\n∙ Third-party risk ratings (e.g., BitSight, SecurityScorecard)\n∙ Contractual oversight and audit rights for outsourced functions" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-14", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "emea-sau-sama-csf-1-2017": [ + "3.4.2.3", + "3.4.2.3.a", + "3.4.2.3.b", + "3.4.2.3.c" + ], + "emea-esp-decree-311-2022": [ + "Article 14(1)", + "Article 16(2)" + ] + } + }, { "control_id": "GOV-20", "title": "Mergers, Acquisitions & Divestitures (MA&D)", @@ -10003,7 +10471,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data privacy governance practices are informally assigned as an additional duty to existing IT/cybersecurity personnel.\n▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to define standardized practices to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10057,9 +10525,10 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} }, { @@ -10082,7 +10551,7 @@ "0": "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.", "1": "Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.\n▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.", "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", - "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's GRC team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provision a Virtual Data Room (VDR), or similar technology, to securely share documentation among stakeholders to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to provision a Virtual Data Room (VDR), or similar technology, to securely share documentation among stakeholders to conduct Mergers, Acquisitions and Divestiture (MA&D) activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10139,10 +10608,111 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "family_name": "Cybersecurity & Data Protection Governance", + "family_name": "Security, Compliance & Resilience Governance", "crosswalks": {} + }, + { + "control_id": "GOV-21", + "title": "High Value Assets (HVAs)", + "family": "GOV", + "description": "Mechanisms exist to identify and catalog the organization's High Value Assets (HVAs) (e.g., crown jewels), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA;\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a HVA based on business process criticality or dependency relationships;\n(3) Location of HVA Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements.", + "scf_question": "Does the organization identify and catalog its High Value Assets (HVAs) (e.g., crown jewels), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA;\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a HVA based on business process criticality or dependency relationships;\n(3) Location of HVA Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Govern", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.\n▪ 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.", + "3": "Cybersecurity & Data Protection Governance (GOV) 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:\n▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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).\n▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).\n▪ An implemented and operational capability exists to identify and catalog the organization's High Value Assets (HVAs), including defining:\n(1) Criteria for high-value Intellectual Property (IP) to be categorized as a HVA (e.g., \"crown jewel\" IP);\n(2) Criteria for Technology Assets, Applications and Services (TAAS) to be categorized as a \"crown jewel,\" based on business process criticality or dependency relationships;\n(3) Location of \"crown jewel\" Technology Assets, Applications, Services and/or Data (TAASD);\n(4) Assigned owners;\n(5) Minimum protection mechanisms that must be implemented; and\n(6) Assurance requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Manual identification of most critical business assets\n∙ HVA asset register (spreadsheet)", + "small": "∙ HVA asset register with basic protection requirements\n∙ Critical asset identification by business process dependency", + "medium": "∙ HVA identification process\n∙ Critical asset register with minimum protection requirements\n∙ Risk-based prioritization of HVA assets", + "large": "∙ Formal HVA identification program\n∙ Critical asset protection requirements matrix\n∙ Regular HVA review cycle", + "enterprise": "∙ Enterprise HVA program with board-level visibility\n∙ Integrated critical asset protection within GRC platform\n∙ Threat modeling centered on HVA assets" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-GV-1" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-12", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Security, Compliance & Resilience Governance", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2005" + ] + } } ] } \ No newline at end of file diff --git a/docs/api/families/HRS.json b/docs/api/families/HRS.json index 5e942e2e..63a2c3e5 100644 --- a/docs/api/families/HRS.json +++ b/docs/api/families/HRS.json @@ -122,7 +122,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -277,7 +278,18 @@ "A.03.01.01.ODP[01]", "A.03.01.01.ODP[02]", "A.03.01.01.ODP[03]", - "A.03.01.01.ODP[04]" + "A.03.01.01.ODP[04]", + "A.03.01.01.g.02", + "A.03.15.03.a", + "A.03.15.03.d[01]" + ], + "general-nist-800-172-r3": [ + "03.09.03E", + "03.09.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.03E.a", + "A.03.09.04E.ODP[01]" ], "general-nist-800-218": [ "PO.2.1" @@ -303,9 +315,6 @@ "12.2.1", "12.7.1" ], - "general-scf-dpmp-2025": [ - "7.9" - ], "general-swift-cscf-2025": [ "5.1", "5.3A" @@ -385,13 +394,13 @@ "314.4(e)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)", - "164.530(e)(2)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)", + "§ 164.530(e)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)", - "164.312(d)" + "§ 164.308(a)(3)(ii)(A)", + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "2.C.3-1", @@ -422,7 +431,7 @@ "PS-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.2(15)" + "3.2.1.3" ], "emea-eu-nis2-2022": [ "Article 21.2(i)" @@ -432,50 +441,42 @@ "10.1.3", "10.2.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-deu-c5-2020": [ + "HR-02", + "KOS-08-DOAR" ], - "emea-isr-cmo-1-0": [ - "19.1" + "emea-grc-pirppd-1997": [ + "B.10.2" ], "emea-sau-cscc-1-2019": [ - "1-5", - "2-5" + "1-5-1" ], "emea-sau-cgiot-2024": [ "1-3-2", "1-8-1" ], "emea-sau-ecc-1-2018": [ + "1-4-2", "1-9-1", - "1-9-6", - "2-6-4" + "1-9-2", + "1-9-3", + "1-9-4", + "1-9-6" ], "emea-sau-otcc-1-2022": [ - "1-7", - "1-7-2", - "1-8" + "1-7-1", + "1-7-2" ], "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-71" + "VII.B.TPC-26" ], "emea-sau-sama-csf-1-2017": [ - "3.3.1" - ], - "emea-zaf-popia-2013": [ - "19", - "20" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 15.1" + "3.3.1", + "3.3.1.1", + "3.3.1.3" ], "emea-esp-decree-311-2022": [ - "15.1" + "Article 12(6)(c)" ], "emea-uae-niaf-2023": [ "3.2.3" @@ -514,8 +515,9 @@ "GV.RR.S6", "RS.CO.S1" ], - "apac-jpn-ppi-2020": [ - "21" + "apac-jpn-appi-2020": [ + "IV.1.21", + "IV.1.22" ], "apac-jpn-ismap": [ "4.5.2.2", @@ -524,7 +526,7 @@ "7.1", "7.1.1.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HML02" ], "apac-nzl-hisf-suppliers-2023": [ @@ -538,14 +540,10 @@ "15.1.7.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.5.1", - "3.5.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.13" + "3.5.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.5" + "apac-kor-pipa-2011": [ + "III.2.28(1)" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", @@ -643,7 +641,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -675,6 +674,9 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10(j)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(7)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -707,6 +709,14 @@ "1-8-1", "1-8-2" ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-18", + "VII.B.TPC-71" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e.1", + "3.3.1.3.e.2" + ], "emea-uae-niaf-2023": [ "3.2.3" ], @@ -829,7 +839,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -902,10 +913,19 @@ "03.01.01.d.02", "03.01.02", "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.15.03.b" ], - "general-nist-800-172": [ - "3.9.1e" + "general-nist-800-171a-r3": [ + "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.09.01.a", + "A.03.09.01.b", + "A.03.15.03.b" ], "general-nist-csf-2-0": [ "GV.RR-02", @@ -956,17 +976,20 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PS-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(a)" + ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "PS-2" @@ -992,9 +1015,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PS-02" ], - "emea-eu-eba-ict-srm-2025": [ - "3.3.2(15)" - ], "emea-eu-gdpr-2016": [ "Article 32.4" ], @@ -1002,8 +1022,8 @@ "10.1.2(b)", "10.1.3" ], - "emea-isr-cmo-1-0": [ - "19.1" + "emea-deu-c5-2020": [ + "HR-01-DOAR" ], "emea-sau-cscc-1-2019": [ "1-5-1-2" @@ -1011,17 +1031,11 @@ "emea-sau-cgiot-2024": [ "1-8-1" ], - "emea-sau-ecc-1-2018": [ - "1-9-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2" + "emea-sau-otcc-1-2022": [ + "1-2-1-2" ], "emea-esp-decree-311-2022": [ - "13.2" + "Article 16(3)" ], "apac-ind-sebi-2024": [ "DE.DP.S1", @@ -1034,10 +1048,12 @@ ], "apac-nzl-ism-3-9": [ "9.2.10.C.01", - "9.2.10.C.02", "9.2.11.C.01", "9.2.11.C.02" ], + "apac-sgp-mas-trm-2021": [ + "3.5.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01", "03.01.01.C.02", @@ -1045,7 +1061,8 @@ "03.01.01.D.02", "03.01.02", "03.09.01.A", - "03.09.01.B" + "03.09.01.B", + "03.15.03.B" ] } }, @@ -1053,8 +1070,8 @@ "control_id": "HRS-02.1", "title": "Users With Elevated Privileges", "family": "HRS", - "description": "Mechanisms exist to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question.", - "scf_question": "Does the organization ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question?", + "description": "Mechanisms exist to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive and/or regulated data is cleared and regularly trained to handle the information in question.", + "scf_question": "Does the organization ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive and/or regulated data is cleared and regularly trained to handle the information in question?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -1073,7 +1090,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates risk for individuals requiring elevated privileges or access to sensitive/regulated data.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that every user accessing Technology Assets, Applications and/or Services (TAAS) that process, store and/or transmit sensitive/regulated data is cleared and regularly trained to handle the information in question.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1146,7 +1163,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -1159,8 +1177,9 @@ "general-nist-800-171-r3": [ "03.01.02" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.02[01]", + "A.03.01.02[02]" ], "general-pci-dss-4-0-1": [ "12.7", @@ -1193,10 +1212,6 @@ "emea-eu-nis2-annex-2024": [ "10.1.2(b)" ], - "apac-sgp-mas-trm-2021": [ - "3.5.2", - "6.1.5" - ], "americas-can-itsp-10-171-2025": [ "03.01.02" ] @@ -1288,7 +1303,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -1334,7 +1350,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Formal roles and responsibilities for cybersecurity and/or data protection are not consistent and/or standardized.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define cybersecurity roles & responsibilities for all personnel.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define cybersecurity roles & responsibilities for all personnel. ", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1403,7 +1419,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -1558,18 +1575,40 @@ ], "general-nist-800-171-r3": [ "03.01.22.a", + "03.02.02.a.01", "03.06.04.a", "03.06.05.d", "03.07.06.a", + "03.07.06.d", "03.08.02", "03.15.03.b", "03.16.03.b" ], "general-nist-800-171a-r3": [ - "A.03.06.05.d" - ], - "general-nist-800-172": [ - "3.9.1e" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.05.d", + "A.03.07.06.a", + "A.03.07.06.d[02]", + "A.03.08.02", + "A.03.15.03.b", + "A.03.16.03.b" + ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.01.11E", + "03.14.17E", + "03.14.18E", + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.08E.ODP[02]", + "A.03.01.11E.ODP[01]", + "A.03.14.17E.ODP[01]", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[01]", + "A.03.17.03E.ODP[03]" ], "general-nist-800-218": [ "PO.2", @@ -1755,19 +1794,23 @@ "PM-13", "PS-09" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(2)", + "101.625(a)" + ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)", - "164.530(a)(2)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)", + "§ 164.530(a)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)", - "164.310(a)(2)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(ii)(B)", + "§ 164.310(a)(2)(i)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "PS-9" @@ -1827,8 +1870,9 @@ "PS-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(12)", - "3.3.2(15)" + "3.2.1.2", + "3.3.1.12", + "3.4.1.29" ], "emea-eu-dora-2023": [ "Article 5.2(c)" @@ -1849,63 +1893,53 @@ "10.1.1" ], "emea-deu-c5-2020": [ - "PSS-08" + "UP-01-BP5", + "OIS-03-BP1", + "OIS-03-BP2", + "OIS-03-BP3", + "SA-01-BP3" + ], + "emea-hun-act-cxii-2011": [ + "II.18.24(2)" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B2" ], - "emea-isr-cmo-1-0": [ - "4.13", - "18.10" + "emea-ita-pdpc-2018": [ + "Article 2-o(1)", + "Article 2-o(2)" ], "emea-sau-cgiot-2024": [ "1-3-1", "1-3-2", "1-8-1" ], + "emea-sau-ecc-1-2018": [ + "1-4-1", + "1-4-2", + "1-9-1" + ], "emea-sau-otcc-1-2022": [ - "1-2", "1-2-1", - "1-2-1-1" + "1-2-1-2" ], "emea-sau-pdpl-2023": [ "Article 30.2" ], "emea-sau-sacs-002-2022": [ - "TPC-26" + "VII.B.TPC-26" ], "emea-sau-sama-csf-1-2017": [ - "3.1.4" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.1", - "Article 11.2", - "Article 11.3", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.2(d)", - "Article 13.3", - "Article 13.4", - "Article 13.5" + "3.1.4.6", + "3.1.4.6.a", + "3.3.1.3.a" ], "emea-esp-decree-311-2022": [ - "11.1", - "11.2", - "11.3", - "13.1", - "13.2", - "13.2(a)", - "13.2(b)", - "13.2(c)", - "13.2(d)", - "13.3", - "13.4", - "13.5" - ], - "emea-esp-ccn-stic-825-2023": [ - "6.4 [ORG.4]", - "8.2.1 [MP.PER.1]", - "8.2.2 [MP.PER.2]" + "Article 12(1)(c)", + "Article 13(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "emea-gbr-def-stan-05-138-2024": [ "1102", @@ -1928,7 +1962,7 @@ "2321", "3102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0717", "ISM-0720", "ISM-0724", @@ -1938,13 +1972,12 @@ "ISM-0732", "ISM-0733", "ISM-0734", - "ISM-0735" + "ISM-0735", + "ISM-2035", + "ISM-2036" ], "apac-aus-ps-cps-234-2019": [ - "14" - ], - "apac-chn-data-security-law-2021": [ - "27" + "19" ], "apac-ind-dpdpa-2023": [ "6(9)", @@ -1957,9 +1990,6 @@ "PR.AT.S5", "RS.CO.S1" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "4.5.2.2", "6.1.1", @@ -1972,15 +2002,12 @@ "6.1.1.7", "6.1.1.13.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP02", "HHSP23", "HML02", "HML23" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS01" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP02", "HSUP21" @@ -2019,16 +2046,27 @@ "3.3.14.C.03", "3.3.15.C.01", "3.4.10.C.01", - "3.4.10.C.02" + "3.4.10.C.02", + "17.9.35.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "3.5.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.2" + "americas-arg-ppd-2018": [ + "B.2.2", + "E.1.2-1", + "F.1.3" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", + "03.02.02.A.01", "03.06.04.A", "03.06.05.D", "03.07.06.A", + "03.07.06.D", "03.08.02", "03.15.03.B", "03.16.03.B" @@ -2058,7 +2096,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to communicate with users about their roles and responsibilities to maintain a safe and secure working environment.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2144,7 +2182,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -2187,6 +2226,10 @@ "03.01.22.a", "03.15.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.15.03.b" + ], "general-nist-csf-2-0": [ "GV.RR-04" ], @@ -2265,6 +2308,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(4)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 R2", "CIP-004-7 2.2" @@ -2280,13 +2326,8 @@ "10.1.2(a)", "10.1.2(c)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.1", - "Article 15.1" - ], - "emea-esp-decree-311-2022": [ - "13.1", - "15.1" + "emea-sau-ecc-1-2018": [ + "1-9-4-1" ], "emea-gbr-def-stan-05-138-2024": [ "2600", @@ -2304,7 +2345,7 @@ "2600", "2603" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0824" ], "apac-ind-sebi-2024": [ @@ -2321,6 +2362,9 @@ "7.2.1.4", "8.1.3.1" ], + "americas-arg-ppd-2018": [ + "B.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.15.03.B" @@ -2350,7 +2394,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Formal roles and responsibilities for cybersecurity and/or data protection are not consistent and/or standardized.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that all security-related positions are staffed by qualified individuals who have the necessary skill set.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that all security-related positions are staffed by qualified individuals who have the necessary skill set. ", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2434,7 +2478,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -2537,6 +2582,9 @@ "general-nist-800-171-r3": [ "03.07.06.d" ], + "general-nist-800-171a-r3": [ + "A.03.07.06.d[01]" + ], "general-nist-800-218": [ "PO.2" ], @@ -2593,6 +2641,21 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PS-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(e)", + "101.625(e)(1)", + "101.625(e)(2)", + "101.625(e)(3)", + "101.625(e)(4)", + "101.625(e)(5)", + "101.625(e)(6)", + "101.625(e)(7)", + "101.625(e)(8)", + "101.625(e)(9)", + "101.625(e)(10)", + "101.625(e)(11)", + "101.625(e)(12)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(2)" ], @@ -2617,23 +2680,14 @@ "usa-state-tx-txramp-2-0-level-2": [ "PS-02" ], - "emea-sau-ecc-1-2018": [ - "1-9-2" + "emea-isr-ppl-5741-2025": [ + "s.17B3" ], "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 15.1", - "Article 16.1", - "Article 16.2", - "Article 16.3" + "VII.B.TPC-26" ], "emea-esp-decree-311-2022": [ - "15.1", - "16.1", - "16.2", - "16.3" + "Article 16(2)" ], "emea-gbr-caf-4-0": [ "C1.e" @@ -2646,6 +2700,9 @@ "14.2.1.8", "14.2.1.11" ], + "apac-mys-bnm-rmit-2025": [ + "9.4" + ], "apac-nzl-ism-3-9": [ "5.1.14.C.01" ], @@ -2653,10 +2710,6 @@ "3.5.1", "6.1.5" ], - "amaericas-can-osfi-self-assessment": [ - "1.5", - "1.7" - ], "americas-can-itsp-10-171-2025": [ "03.07.06.D" ] @@ -2771,7 +2824,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -2865,7 +2919,8 @@ ], "general-nist-800-171-r3": [ "03.09.01.a", - "03.09.01.b" + "03.09.01.b", + "03.09.02.b.01" ], "general-nist-800-171a": [ "3.9.1" @@ -2876,9 +2931,6 @@ "A.03.09.01.b", "A.03.09.02.b.01[01]" ], - "general-nist-800-172": [ - "3.9.1e" - ], "general-pci-dss-4-0-1": [ "12.7", "12.7.1" @@ -2889,9 +2941,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.7.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "5.3A" ], @@ -2923,10 +2972,10 @@ "PS-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "2.C.3", @@ -2970,24 +3019,27 @@ "10.2.2(b)" ], "emea-deu-c5-2020": [ - "HR-01" - ], - "emea-isr-cmo-1-0": [ - "19.2" + "HR-01", + "HR-01-BP1", + "HR-01-BP2", + "HR-01-BP3", + "HR-01-BP4" ], "emea-sau-cscc-1-2019": [ "1-5-1-1" ], "emea-sau-ecc-1-2018": [ - "1-9-3", "1-9-3-2" ], "emea-sau-otcc-1-2022": [ "1-7-1" ], - "emea-zaf-popia-2013": [ - "19", - "20" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.d" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.1", + "mp.per.1" ], "emea-gbr-def-stan-05-138-2024": [ "2700", @@ -3005,7 +3057,7 @@ "2700", "2701" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0434" ], "apac-jpn-ismap": [ @@ -3017,7 +3069,7 @@ "7.1.1.9", "7.1.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP20", "HML20" ], @@ -3030,11 +3082,13 @@ "americas-bmu-mba-coc-2020": [ "5.13" ], - "amaericas-can-osfi-self-assessment": [ - "1.6" + "americas-can-osfi-self-assessment-2": [ + "3.2.7" ], "americas-can-itsp-10-171-2025": [ - "03.09.01.A" + "03.09.01.A", + "03.09.01.B", + "03.09.02.B.01" ] } }, @@ -3059,7 +3113,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure that individuals accessing a system that stores, transmits or processes information requiring special protection satisfy organization-defined personnel screening criteria.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3132,7 +3186,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -3199,10 +3254,11 @@ "03.09.01.b" ], "general-nist-800-171a-r3": [ - "A.03.09.01.ODP[01]" - ], - "general-nist-800-172": [ - "3.9.1e" + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.09.01.ODP[01]", + "A.03.09.01.a", + "A.03.09.01.b" ], "general-pci-dss-4-0-1": [ "12.7", @@ -3251,27 +3307,23 @@ ], "emea-deu-c5-2020": [ "HR-01", - "PSS-08" - ], - "emea-isr-cmo-1-0": [ - "19.2" + "HR-01-DOAR" ], "emea-sau-ecc-1-2018": [ "1-9-3-2" ], - "emea-sau-otcc-1-2022": [ - "1-7-1" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.d" ], - "emea-sau-sacs-002-2022": [ - "TPC-26" + "emea-esp-ccn-stic-825-2026": [ + "org.4", + "op.pl.1", + "mp.per.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0446", "ISM-0447" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-jpn-ismap": [ "7.1.1.7", "7.1.1.8" @@ -3279,9 +3331,6 @@ "apac-sgp-mas-trm-2021": [ "3.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "1.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.02.A.01", @@ -3310,7 +3359,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department governs personnel management operations and notifies IT and/or cybersecurity personnel of role changes for logical access provisioning and deprovisioning actions.\n▪ Personnel managers ensure personnel are responsible for educating new hires on the organization's cybersecurity and data protection policies.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to formally educate authorized users on proper data handling practices for all the relevant types of data to which they have access.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3394,7 +3443,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -3456,6 +3506,13 @@ "03.06.04.a.01", "03.15.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.02.a.01[01]", + "A.03.06.04.ODP[01]", + "A.03.06.04.a.01", + "A.03.15.03.b" + ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e", "WORKFORCE-2a" @@ -3468,6 +3525,9 @@ "11.10(i)", "11.10(j)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-omb-fipps-1973": [ "2" ], @@ -3475,25 +3535,13 @@ "500.10(a)(2)" ], "emea-sau-ecc-1-2018": [ - "1-9-4", - "1-9-4-1" - ], - "emea-sau-otcc-1-2022": [ - "1-8" - ], - "emea-sau-sacs-002-2022": [ - "TPC-26", - "TPC-71" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2", - "Article 15.1" + "1-9-4-1", + "1-9-4-2" ], - "emea-esp-decree-311-2022": [ - "13.2", - "15.1" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0435" ], "apac-jpn-ismap": [ @@ -3505,12 +3553,18 @@ "apac-nzl-ism-3-9": [ "9.1.7.C.01" ], + "americas-arg-ppd-2018": [ + "B.2.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.02.A.01", "03.06.04.A", "03.06.04.A.01", "03.15.03.B" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(d)" ] } }, @@ -3532,7 +3586,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to verify that individuals accessing a system processing, storing, or transmitting sensitive information meet applicable statutory, regulatory and/or contractual requirements for citizenship.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3600,7 +3654,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -3610,10 +3665,16 @@ "general-nist-800-82-r3": [ "PS-03(04)" ], + "general-nist-800-172-r3": [ + "03.09.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.04E" + ], "emea-sau-cscc-1-2019": [ "1-5-1-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0409", "ISM-0411", "ISM-0420", @@ -3623,7 +3684,6 @@ ], "apac-nzl-ism-3-9": [ "9.2.10.C.01", - "9.2.10.C.02", "9.2.11.C.01", "9.2.11.C.02", "9.2.15.C.01", @@ -3650,7 +3710,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to identify foreign nationals, including by their specific citizenship.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3718,11 +3778,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0420" ], "apac-nzl-ism-3-9": [ @@ -3843,9 +3904,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -3950,9 +4011,13 @@ "general-nist-800-171-r3": [ "03.01.01.h", "03.01.22.a", - "03.15.03.a" + "03.15.03.a", + "03.15.03.b" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", + "A.03.01.22.a", + "A.03.15.03.a", "A.03.15.03.b" ], "general-nist-csf-2-0": [ @@ -4028,10 +4093,10 @@ "155.260(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "PL-4" @@ -4055,37 +4120,35 @@ "1.2.2", "10.3.2" ], + "emea-deu-fdpa-2017": [ + "3.2.48(2)8" + ], "emea-deu-c5-2020": [ "HR-02", - "HR-03", - "AM-05" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "19.3", - "19.4" - ], - "emea-sau-cscc-1-2019": [ - "2-5" + "HR-05", + "AM-04" ], "emea-sau-ecc-1-2018": [ - "1-9-3-1", - "1-9-3-2", - "1-9-4-2" + "1-9-1", + "1-9-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-26" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.2", - "Article 11.3" + "VII.A.TPC-1" ], "emea-esp-decree-311-2022": [ - "11.2", - "11.3" + "Article 12(6)(d)", + "Article 13(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.2 [MP.PER.2]" + "emea-che-fadp-2025": [ + "5.30.1", + "5.30.2", + "5.30.2.a", + "5.30.2.b", + "5.30.2.c", + "5.30.3" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -4099,10 +4162,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0258", "ISM-0824", - "ISM-1146" + "ISM-1146", + "ISM-1865" ], "apac-jpn-ismap": [ "7.1.2", @@ -4130,12 +4194,18 @@ "9.3.7.C.04", "9.3.8.C.01", "9.3.8.C.02", - "9.3.8.C.03" + "9.3.8.C.03", + "21.1.6.C.02", + "21.2.3.C.01" + ], + "americas-bhs-dpa-2003": [ + "II.4(2)" ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", "03.01.22.A", - "03.15.03.A" + "03.15.03.A", + "03.15.03.B" ] } }, @@ -4247,7 +4317,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -4376,6 +4447,8 @@ "03.15.03.d" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.22.a", "A.03.15.03.ODP[01]", "A.03.15.03.a", "A.03.15.03.d[01]", @@ -4413,9 +4486,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.1.3" ], - "general-scf-dpmp-2025": [ - "7.7" - ], "general-tisax-6-0-3": [ "8.2.5", "8.2.7" @@ -4458,10 +4528,10 @@ "PL-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "PL-4" @@ -4489,37 +4559,23 @@ "emea-eu-nis2-annex-2024": [ "12.2.2(b)" ], - "emea-deu-c5-2020": [ - "HR-03" - ], - "emea-isr-cmo-1-0": [ - "5.1", - "15.6", - "19.3", - "19.6" - ], - "emea-sau-cscc-1-2019": [ - "2-5" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.1" ], "emea-sau-ecc-1-2018": [ "1-9-3-1", - "1-9-4-2", "2-1-3", "2-1-4", "2-15-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-1", - "TPC-8", - "TPC-9" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 11.2", - "Article 11.3" + "VII.A.TPC-1" ], "emea-esp-decree-311-2022": [ - "11.2", - "11.3" + "Article 15(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -4533,12 +4589,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0820", - "ISM-0821" - ], - "apac-jpn-ppi-2020": [ - "21" + "ISM-0821", + "ISM-1864", + "ISM-2095" ], "apac-jpn-ismap": [ "7.2.1.2", @@ -4564,14 +4619,14 @@ "9.3.8.C.03", "14.3.5.C.01", "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "16.4.38.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.18.A", "03.01.22.A", - "03.15.03.A" + "03.15.03.A", + "03.15.03.D" ] } }, @@ -4598,7 +4653,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define rules of behavior that contain explicit restrictions on the use of social media and networking sites, posting information on commercial websites and sharing account information.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to define rules of behavior that contain explicit restrictions on the use of social media and networking sites, posting information on commercial websites and sharing account information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4666,12 +4721,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0" + "9" ], "general-govramp": [ "PL-04(01)" @@ -4741,9 +4797,6 @@ "general-nist-800-171a-r3": [ "A.03.15.03.a" ], - "general-scf-dpmp-2025": [ - "7.7" - ], "usa-federal-fbi-cjis-6-0": [ "PL-4(1)" ], @@ -4786,11 +4839,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PL-04 (01)" ], - "emea-isr-cmo-1-0": [ - "4.13", - "19.6", - "19.7" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2" ], @@ -4806,22 +4854,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0229", "ISM-0230", "ISM-0233", "ISM-0235", "ISM-0236", "ISM-0240", - "ISM-0241", "ISM-0264", "ISM-0267", "ISM-0588", "ISM-0824", "ISM-0931", - "ISM-1075", "ISM-1078", - "ISM-1092", "ISM-1196", "ISM-1198", "ISM-1199", @@ -4848,7 +4893,7 @@ "title": "Technology Use Restrictions", "family": "HRS", "description": "Mechanisms exist to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously.", - "scf_question": "Does the organization establish usage restrictions and implementation guidance for communications technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously?", + "scf_question": "Does the organization establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -4865,7 +4910,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to establish usage restrictions and implementation guidance for organizational technologies based on the potential to cause damage to Technology Assets, Applications and/or Services (TAAS), if used maliciously. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4950,7 +4995,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -5049,6 +5095,8 @@ "03.15.03.a" ], "general-nist-800-171a-r3": [ + "A.03.01.01.h", + "A.03.01.18.a[01]", "A.03.15.03.a" ], "general-pci-dss-4-0-1": [ @@ -5086,10 +5134,10 @@ "PL-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)" + "§ 164.310(b)" ], "usa-federal-irs-1075-2021": [ "3.3.2", @@ -5130,24 +5178,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PL-04" ], - "emea-isr-cmo-1-0": [ - "5.4", - "9.5", - "15.6", - "19.6" - ], - "emea-sau-cscc-1-2019": [ - "2-5" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2", - "2-1-3", - "2-6-4", "2-15-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-8", - "TPC-9" + "VII.A.TPC-8" ], "emea-gbr-def-stan-05-138-2024": [ "2604" @@ -5161,6 +5197,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2604" ], + "apac-aus-ism-2026-march": [ + "ISM-1866", + "ISM-2075", + "ISM-2095", + "ISM-2099", + "ISM-2100", + "ISM-2101" + ], "apac-jpn-ismap": [ "13.2.1.1", "13.2.1.2", @@ -5175,9 +5219,26 @@ "9.3.5.C.02", "9.3.9.C.01", "9.3.10.C.01", - "15.1.7.C.01", - "21.1.22.C.01", - "21.1.22.C.02" + "11.1.15.C.01", + "11.1.16.C.03", + "11.1.16.C.04", + "11.1.17.C.02", + "11.1.18.C.01", + "11.1.18.C.02", + "11.1.19.C.02", + "11.2.14.C.01", + "11.2.15.C.01", + "11.2.15.C.02", + "11.2.15.C.03", + "11.8.4.C.01", + "11.8.4.C.02", + "11.8.5.C.01", + "11.8.6.C.01", + "11.8.6.C.02", + "15.1.7.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.1.5" ], "americas-can-itsp-10-171-2025": [ "03.01.01.H", @@ -5209,7 +5270,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.\n▪ ToE and/or RoB address the use of entity-issued and personally-owned devices.\n▪ ToE and/or RoB address the requirement to comply with applicable software usage requirements and copyright laws.\n▪ ToE and/or RoB address posting content to websites, social media or other publicly-accessible sources.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern usage policies for critical technologies.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern usage policies for critical technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5293,7 +5354,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -5331,16 +5393,17 @@ "general-nist-800-171-r3": [ "03.15.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.15.03.a" + ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e" ], - "emea-isr-cmo-1-0": [ - "15.6", - "19.6" - ], "emea-sau-ecc-1-2018": [ - "1-9-4-2", - "2-1-3" + "1-9-4-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2095" ], "americas-can-itsp-10-171-2025": [ "03.15.03.A" @@ -5367,7 +5430,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to manage business risks associated with permitting mobile device access to organizational resources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5453,7 +5516,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -5483,6 +5547,7 @@ "03.15.03.a" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", "A.03.15.03.a" ], "general-shared-assessments-sig-2025": [ @@ -5491,20 +5556,16 @@ "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1e" ], - "emea-deu-c5-2020": [ - "AM-05" - ], - "emea-isr-cmo-1-0": [ - "13.2", - "13.3", - "13.7", - "13.10", - "15.6", - "19.6" - ], "emea-sau-ecc-1-2018": [ "1-9-4-2" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-1", + "2-5-1-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-84" + ], "emea-gbr-def-stan-05-138-2024": [ "2322" ], @@ -5517,7 +5578,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0229", "ISM-0230", "ISM-0240", @@ -5535,7 +5596,8 @@ "ISM-1198", "ISM-1199", "ISM-1200", - "ISM-1366" + "ISM-1366", + "ISM-1866" ], "apac-nzl-ism-3-9": [ "8.1.12.C.01", @@ -5554,9 +5616,19 @@ "11.5.16.C.02", "11.5.16.C.03", "21.1.11.C.01", - "21.1.11.C.02", - "21.1.22.C.01", - "21.1.22.C.02" + "22.1.10.C.02", + "22.1.13.C.01", + "22.1.13.C.02", + "22.1.13.C.03", + "22.1.13.C.04", + "22.1.13.C.05", + "22.2.5.C.01", + "22.2.6.C.01", + "22.2.7.C.01", + "22.2.7.C.02", + "22.3.5.C.01", + "22.3.6.C.01", + "22.4.9.C.01" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", @@ -5582,7 +5654,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to prohibit the use of oversized clothing (e.g., baggy pants, oversized hooded sweatshirts, etc.) to prevent the unauthorized exfiltration of data and technology assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5619,7 +5691,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": {} @@ -5629,7 +5702,7 @@ "title": "Policy Familiarization & Acknowledgement", "family": "HRS", "description": "Mechanisms exist to ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement.", - "scf_question": "Does the organization ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement?", + "scf_question": "Does the organization ensure personnel receive recurring familiarization with its security, compliance and resilience policies and provide acknowledgement?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -5646,7 +5719,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to ensure personnel receive recurring familiarization with the organization's security, compliance and resilience policies and provide acknowledgement.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5729,9 +5802,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-iso-27001-2022": [ @@ -5745,12 +5818,12 @@ "OR-3.1" ], "general-nist-800-171-r3": [ - "03.15.03.b", "03.15.03.c", "03.15.03.d" ], "general-nist-800-171a-r3": [ - "A.03.15.03.c" + "A.03.15.03.c", + "A.03.15.03.d[02]" ], "general-nist-csf-2-0": [ "GV.PO", @@ -5773,7 +5846,7 @@ "609.930(c)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(b)(1)" + "§ 164.530(b)(1)" ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PL-04-SID" @@ -5781,9 +5854,21 @@ "emea-eu-nis2-annex-2024": [ "1.1.1(f)" ], - "emea-sau-sacs-002-2022": [ - "TPC-26", - "TPC-71" + "emea-aut-dpa-2018": [ + "§ 6(3)" + ], + "emea-deu-c5-2020": [ + "HR-02" + ], + "emea-sau-ecc-1-2018": [ + "1-9-4-1", + "1-9-4-2" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.b" + ], + "emea-esp-decree-311-2022": [ + "Article 13(2)" ], "apac-jpn-ismap": [ "4.5.2.6", @@ -5793,9 +5878,11 @@ "8.1.3.1" ], "americas-can-itsp-10-171-2025": [ - "03.15.03.B", "03.15.03.C", "03.15.03.D" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(d)" ] } }, @@ -5819,9 +5906,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ HR defines terms of employment, including acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior.\n▪ HR maintains formal Terms of Employment (ToE) and/or Rules of Behavior (RoB) that stipulates acceptable and unacceptable employee activities.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to require internal and third-party users to sign appropriate access agreements prior to being granted access.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to require internal and third-party users to sign appropriate access agreements prior to being granted access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5889,7 +5976,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -5982,9 +6070,19 @@ "general-nist-800-171-r3": [ "03.01.18.a", "03.12.05.a", - "03.15.03.b", "03.15.03.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.12.05.a[01]", + "A.03.15.03.c" + ], + "general-nist-800-172-r3": [ + "03.09.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.09.03E.c.01" + ], "general-tisax-6-0-3": [ "2.1.2" ], @@ -6036,26 +6134,18 @@ "emea-deu-c5-2020": [ "HR-02" ], - "emea-isr-cmo-1-0": [ - "19.6" - ], "emea-sau-ecc-1-2018": [ - "1-9-3" + "1-9-3-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-9", - "TPC-71" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], "apac-ind-sebi-2024": [ "GV.RR.S5" ], - "apac-jpn-ppi-2020": [ - "21" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.12.05.A", - "03.15.03.B", "03.15.03.C" ] } @@ -6150,7 +6240,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -6244,6 +6335,10 @@ "03.12.05.a", "03.15.03.c" ], + "general-nist-800-171a-r3": [ + "A.03.12.05.a[01]", + "A.03.15.03.c" + ], "general-tisax-6-0-3": [ "2.1.2", "6.1.2" @@ -6271,7 +6366,7 @@ "PS-06(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)" + "§ 164.502(a)" ], "usa-federal-irs-1075-2021": [ "PS-6" @@ -6294,27 +6389,41 @@ "emea-eu-nis2-annex-2024": [ "10.3.2" ], + "emea-eu-psd2-2015": [ + "24(1)" + ], + "emea-aut-dpa-2018": [ + "§ 5(1)" + ], "emea-deu-c5-2020": [ - "HR-06", - "IDM-08", - "PSS-07" + "IDM-07-DOAR", + "KOS-08" ], - "emea-isr-cmo-1-0": [ - "19.4" + "emea-isr-ppl-5741-2025": [ + "s.16" ], "emea-sau-ecc-1-2018": [ - "1-9-3-1" + "1-9-3-1", + "4-1-2-1" ], "emea-sau-sacs-002-2022": [ - "TPC-9", - "TPC-71" + "VII.A.TPC-9" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.a" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" + ], + "apac-chn-csnip-2012": [ + "III" + ], + "apac-chn-pipl-2021": [ + "Article 59" ], "apac-ind-sebi-2024": [ "GV.RR.S5" ], - "apac-jpn-ppi-2020": [ - "21" - ], "apac-jpn-ismap": [ "13.2.4", "13.2.4.1", @@ -6340,6 +6449,12 @@ "americas-can-itsp-10-171-2025": [ "03.12.05.A", "03.15.03.C" + ], + "americas-chl-act-19628-1999": [ + "I.7" + ], + "americas-col-law-1581-2012": [ + "II.4(h)" ] } }, @@ -6347,8 +6462,8 @@ "control_id": "HRS-06.2", "title": "Post-Employment Requirements Awareness", "family": "HRS", - "description": "Mechanisms exist to notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive/regulated data.", - "scf_question": "Does the organization notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive/regulated data?", + "description": "Mechanisms exist to notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive and/or regulated data.", + "scf_question": "Does the organization notify individuals of their applicable, legally-binding post-employment requirements for the protection of sensitive and/or regulated data?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -6444,7 +6559,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -6462,6 +6578,9 @@ "PS-6(CE-3).a", "PS-6(CE-3).b" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.e" + ], "apac-jpn-ismap": [ "7.1.2.10" ] @@ -6490,7 +6609,7 @@ "0": "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.", "1": "Human Resources Security (HRS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with HRS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Personnel management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ The Human Resources (HR) department provides guidance on secure HR practices for hiring, retaining and terminating employees, contractors and other personnel that work on behalf of the organization.", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Requests for investigations are handled through a formal, management-approved process.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to sanction personnel failing to comply with established security policies, standards and procedures.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to sanction personnel failing to comply with established security policies, standards and procedures. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6575,7 +6694,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -6649,17 +6769,15 @@ "3.9.2[b]", "3.9.2[c]" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" ], "general-nist-csf-2-0": [ "GV.PO", "GV.PO-01", "GV.PO-02" ], - "general-scf-dpmp-2025": [ - "7.8" - ], "usa-federal-dow-cert-rmm-1-2": [ "HRM:SG3.SP4" ], @@ -6685,11 +6803,11 @@ "PS-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(C)", - "164.530(e)(1)" + "§ 164.308(a)(1)(ii)(C)", + "§ 164.530(e)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(C)" + "§ 164.308(a)(1)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.2", @@ -6721,8 +6839,8 @@ "emea-deu-c5-2020": [ "HR-04" ], - "emea-isr-cmo-1-0": [ - "19.8" + "emea-sau-sama-csf-1-2017": [ + "3.3.1.3.c" ], "apac-jpn-ismap": [ "7.2.3", @@ -6731,7 +6849,7 @@ "7.2.3.3", "7.2.3.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP03", "HHSP72", "HHSP73", @@ -6768,9 +6886,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ Requests for investigations are handled through a formal, management-approved process.", - "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to conduct employee misconduct investigations when there is reasonable assurance that a policy has been violated.", + "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to conduct employee misconduct investigations when there is reasonable assurance that a policy has been violated. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6856,7 +6974,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -6880,8 +6999,9 @@ "03.01.01.f.04", "03.01.01.f.05" ], - "general-nist-800-172": [ - "3.9.2e" + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" ], "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-1g" @@ -6895,7 +7015,7 @@ "emea-eu-nis2-annex-2024": [ "10.4.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP03", "HHSP73", "HML03", @@ -7014,7 +7134,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -7027,8 +7148,8 @@ "control_id": "HRS-07.3", "title": "Preventative Access Restriction", "family": "HRS", - "description": "Mechanisms exist to proactively restrict logical and physical access when an individual with access to sensitive/regulated data is under investigation for personnel sanctions that may lead to employment termination.", - "scf_question": "Does the organization proactively restrict logical and physical access when an individual with access to sensitive/regulated data is under investigation for personnel sanctions that may lead to employment termination?", + "description": "Mechanisms exist to proactively restrict logical and physical access when an individual with access to sensitive and/or regulated data is under investigation for personnel sanctions that may lead to employment termination.", + "scf_question": "Does the organization proactively restrict logical and physical access when an individual with access to sensitive and/or regulated data is under investigation for personnel sanctions that may lead to employment termination?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -7124,13 +7245,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { - "general-nist-800-172": [ - "3.9.2e" - ], "usa-federal-dow-cmmc-2-level-3": [ "PS.L3-3.9.2E" ] @@ -7243,7 +7362,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -7311,7 +7431,8 @@ "general-nist-800-171-r3": [ "03.01.01.g.02", "03.09.02.a", - "03.09.02.b.01" + "03.09.02.b.01", + "03.09.02.b.02" ], "general-nist-800-171a": [ "3.9.2[a]", @@ -7319,7 +7440,9 @@ "3.9.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", + "A.03.09.02.a.01", "A.03.09.02.b.01[01]", "A.03.09.02.b.01[02]", "A.03.09.02.b.02" @@ -7349,10 +7472,10 @@ "PS-05" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.1", @@ -7385,19 +7508,17 @@ "HR-05", "IDM-04" ], - "emea-isr-cmo-1-0": [ - "19.9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-18" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", "03.09.02.A", - "03.09.02.B.01" + "03.09.02.B.01", + "03.09.02.B.02" ] } }, @@ -7509,7 +7630,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -7578,6 +7700,7 @@ "03.01.01.f.03", "03.01.01.g.02", "03.09.02.a", + "03.09.02.a.02", "03.09.02.a.03", "03.09.02.b.01" ], @@ -7587,11 +7710,14 @@ "3.9.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.f.03", + "A.03.01.01.g.02", "A.03.09.02.ODP[01]", "A.03.09.02.a.01", "A.03.09.02.a.02[01]", "A.03.09.02.a.02[02]", - "A.03.09.02.a.03" + "A.03.09.02.a.03", + "A.03.09.02.b.01[01]" ], "general-pci-dss-4-0-1": [ "8.2.5" @@ -7640,10 +7766,10 @@ "PS-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "2.C.4.3", @@ -7683,15 +7809,10 @@ "emea-deu-c5-2020": [ "HR-05" ], - "emea-isr-cmo-1-0": [ - "19.9", - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-18" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "apac-jpn-ismap": [ @@ -7705,6 +7826,7 @@ "03.01.01.F.03", "03.01.01.G.02", "03.09.02.A", + "03.09.02.A.02", "03.09.02.A.03", "03.09.02.B.01" ] @@ -7730,7 +7852,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to retrieve organization-owned assets upon termination of an individual's employment.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7815,7 +7937,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -7835,12 +7958,6 @@ "emea-eu-nis2-annex-2024": [ "12.5" ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-18" - ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.03" ] @@ -7866,7 +7983,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to expedite the process of removing \"high risk\" individual’s access to TAASD upon termination, as determined by management.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7953,7 +8070,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -7992,6 +8110,12 @@ "03.09.02.a.02", "03.09.02.b.01" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]", + "A.03.09.02.b.01[01]" + ], "general-pci-dss-4-0-1": [ "8.2.5" ], @@ -8031,13 +8155,6 @@ "usa-federal-irs-1075-2021": [ "AC-2(CE-13)" ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-6", - "TPC-18" - ], "americas-can-itsp-10-171-2025": [ "03.09.02.A.01", "03.09.02.A.02", @@ -8049,8 +8166,8 @@ "control_id": "HRS-09.3", "title": "Post-Employment Requirements Notification", "family": "HRS", - "description": "Mechanisms exist to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data.", - "scf_question": "Does the organization govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data?", + "description": "Mechanisms exist to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive and/or regulated data.", + "scf_question": "Does the organization govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -8065,7 +8182,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern former employee behavior by formally notifying terminated individuals of their applicable, legally binding post-employment requirements for the protection of sensitive/regulated data.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8147,7 +8264,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -8171,12 +8289,6 @@ ], "general-nist-800-82-r3": [ "PS-04(01)" - ], - "emea-isr-cmo-1-0": [ - "19.10" - ], - "emea-sau-sacs-002-2022": [ - "TPC-18" ] } }, @@ -8198,11 +8310,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to automatically notify Identity and Access Management (IAM) personnel or roles upon termination of an individual employment or contract.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -8267,7 +8379,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -8300,11 +8413,17 @@ "03.09.02.a.01", "03.09.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.g.02", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], "usa-federal-gsa-fedramp-5-high": [ "PS-04(02)" ], "emea-sau-sacs-002-2022": [ - "TPC-6" + "VII.A.TPC-6" ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.02", @@ -8335,7 +8454,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to govern third-party personnel by reviewing and monitoring third-party security, compliance and/or resilience roles and responsibilities.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8426,9 +8545,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -8488,6 +8607,9 @@ "general-nist-800-171-r3": [ "03.16.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.b" + ], "general-swift-cscf-2025": [ "5.3A" ], @@ -8530,11 +8652,8 @@ "emea-eu-nis2-annex-2024": [ "10.2.1" ], - "emea-isr-cmo-1-0": [ - "19.5" - ], - "emea-sau-ecc-1-2018": [ - "1-9-1" + "emea-sau-otcc-1-2022": [ + "1-7-1" ], "apac-jpn-ismap": [ "7.1.1.10" @@ -8651,7 +8770,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -8688,7 +8808,7 @@ "5.3", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -8952,6 +9072,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ], "usa-federal-irs-1075-2021": [ "AC-5" ], @@ -8975,23 +9098,21 @@ ], "emea-deu-c5-2020": [ "OIS-04", - "IDM-01" - ], - "emea-isr-cmo-1-0": [ - "4.11", - "10.4" + "OIS-04-BP1", + "OIS-04-BP2", + "OIS-04-BP3", + "OIS-04-DOAR", + "IDM-01-BP2", + "IDM-01-BP3", + "BEI-12" ], "emea-sau-cgiot-2024": [ "2-2-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.3" - ], - "emea-esp-decree-311-2022": [ - "13.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.3 [OP.ACC.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.3", + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2207" @@ -9017,11 +9138,19 @@ "6.1.2.4" ], "apac-sgp-mas-trm-2021": [ + "6.3.2", + "7.6.1", "9.1.1" ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-osfi-b13-2022": [ "2.5.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.5.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.04.A" ] @@ -9047,7 +9176,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates risk for individuals requiring elevated privileges or access to sensitive/regulated data.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to avoid incompatible development-specific roles through limiting and reviewing developer privileges to change hardware, software and firmware components within a production/operational environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9120,7 +9249,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -9142,11 +9272,11 @@ "general-nist-800-171-r3": [ "03.01.04.a" ], - "emea-deu-c5-2020": [ - "PSS-08" + "general-nist-800-171a-r3": [ + "A.03.01.04.a" ], - "apac-chn-data-security-law-2021": [ - "27" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.3" ], "americas-can-itsp-10-171-2025": [ "03.01.04.A" @@ -9257,7 +9387,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -9276,6 +9407,13 @@ "general-nist-800-160-vol-2-r1": [ "AC-03(02)" ], + "general-nist-800-172-r3": [ + "03.01.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" + ], "general-sparta": [ "CM0054" ], @@ -9298,7 +9436,7 @@ "title": "Identify Critical Skills & Gaps", "family": "HRS", "description": "Mechanisms exist to evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist.", - "scf_question": "Does the organization evaluate the critical security, compliance and resilience skills needed to support the organization's mission and identify gaps that exist?", + "scf_question": "Does the organization evaluate the critical security, compliance and resilience skills needed to support its mission and identify gaps that exist?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -9382,9 +9520,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -9402,6 +9540,9 @@ "usa-federal-doe-c2m2-2-1": [ "WORKFORCE-4b", "WORKFORCE-4c" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" ] } }, @@ -9492,7 +9633,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -9502,6 +9644,9 @@ ], "usa-federal-dow-cert-rmm-1-2": [ "HRM:SG2" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" ] } }, @@ -9592,9 +9737,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-cobit-2019": [ @@ -9605,9 +9750,6 @@ "PM:SG1.SP1", "PM:SG2", "PM:SG2.SP1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } }, @@ -9696,19 +9838,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-cobit-2019": [ "APO07.03" ], + "emea-eu-eba-ict-srm-2025": [ + "3.2.1.3" + ], "emea-eu-nis2-annex-2024": [ "4.2.4(c)" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } }, @@ -9730,7 +9872,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.\n▪ The HR department, in conjunction with IT and/or cybersecurity personnel, evaluates the business-critical cybersecurity and data protection skills needed to support the organization's mission and identify gaps that exist.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to perform succession planning for vital security, compliance and resilience roles.", "4": "Human Resources Security (HRS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9798,9 +9940,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Human Resources Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -9811,9 +9953,6 @@ ], "general-shared-assessments-sig-2025": [ "K.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.5 [MP.PER.5]" ] } }, @@ -9822,7 +9961,7 @@ "title": "Identifying Authorized Work Locations", "family": "HRS", "description": "Mechanisms exist to identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home).", - "scf_question": "Does the organization identity and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home)?", + "scf_question": "Does the organization identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -9835,7 +9974,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to identify and document authorized working locations, including:\n(1) Designated on-premises, organization-controlled work locations; and\n(2) Other off-premises locations not under organization-control (e.g., work from home).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9903,7 +10042,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -9939,7 +10079,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are documented and maintained by process owners.\n▪ 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 HRS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Personnel management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Personnel management is decentralized at a localized/regionalized function, where there are non-standardized methods to govern personnel matters across the organization.\n▪ Localized HR practices are implemented for hiring, managing, training, investigating and terminating employees, contractors and other personnel that work on behalf of the organization.", "3": "Human Resources Security (HRS) 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:\n▪ Policies and standards associated with HRS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with HRS domain capabilities are well-documented and kept current by process owners.\n▪ A Human Resources (HR) team, or similar function, is appropriately staffed and supported to implement and maintain HRS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of human resources security operations (e.g., personnel management software solution, etc.).\n▪ 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 HRS 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).\n▪ An implemented and operational capability exists to communicate authorized work locations to organizational personnel.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10005,7 +10145,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { @@ -10112,7 +10253,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Human Resources Security", "crosswalks": { diff --git a/docs/api/families/IAC.json b/docs/api/families/IAC.json index f8419acc..2c10137f 100644 --- a/docs/api/families/IAC.json +++ b/docs/api/families/IAC.json @@ -1,7 +1,7 @@ { "family_code": "IAC", "family_name": "Identification & Authentication", - "control_count": 114, + "control_count": 116, "controls": [ { "control_id": "IAC-01", @@ -124,7 +124,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -148,9 +149,9 @@ ], "general-cis-csc-8-1": [ "4.7", - "5.0", + "5", "5.6", - "6.0", + "6", "6.6" ], "general-cis-csc-8-1-ig1": [ @@ -302,6 +303,20 @@ "03.05.05.a", "03.05.12.e" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.a[01]", + "A.03.01.01.a[02]", + "A.03.01.18.b", + "A.03.05.01.a[01]", + "A.03.05.05.a", + "A.03.05.12.e" + ], + "general-nist-800-172-r3": [ + "03.05.07E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.07E.ODP[01]" + ], "general-nist-800-207": [ "NIST Tenet 6" ], @@ -361,9 +376,6 @@ "8.5.1", "8.6.1" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-swift-cscf-2025": [ "4.1", "5.2" @@ -454,25 +466,28 @@ "AC-01", "IA-01" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(1)", "314.4(c)(1)(i)", "314.4(c)(1)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)", + "§ 164.530(c)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(4)(i)", - "164.308(a)(4)(ii)(B)", - "164.310(a)(2)(iii)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(4)(i)", + "§ 164.308(a)(4)(ii)(B)", + "§ 164.310(a)(2)(iii)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "AC-1", @@ -527,6 +542,9 @@ "usa-state-vt-act-171-2018": [ "2447(c)(1)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(g)" + ], "emea-eu-dora-2023": [ "Article 9.4(d)" ], @@ -545,73 +563,49 @@ "11.5.2(c)", "11.6.4" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "6.1", "6.2" ], "emea-deu-c5-2020": [ "IDM-01", - "PSS-05", - "PSS-09" + "IDM-03" ], - "emea-isr-cmo-1-0": [ - "4.1", - "4.8", - "4.34", - "4.37", - "12.15", - "12.28", - "12.29" + "emea-isr-cmo-2-0": [ + "Appendix A, 8.2" ], "emea-sau-cscc-1-2019": [ - "2-2", - "2-2-1-5" + "2-2-1" ], "emea-sau-ecc-1-2018": [ "2-2-1", - "2-2-2", - "2-2-4" + "2-2-3" ], "emea-sau-otcc-1-2022": [ - "2-2", - "2-2-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-10" + "2-2-1", + "2-2-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.5" - ], - "emea-zaf-popia-2013": [ - "19", - "20" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" + "3.3.5.1" ], "emea-esp-decree-311-2022": [ - "18" + "Article 12(6)(e)", + "Article 24(3)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.2 [OP.ACC.2]", - "7.2.4 [OP.ACC.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-caf-4-0": [ "B2", "B2.d" ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "4" ], "emea-gbr-def-stan-05-138-2024": [ "2200", @@ -632,9 +626,11 @@ "2208", "2210" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1146", - "ISM-1546" + "ISM-1546", + "ISM-2076", + "ISM-2077" ], "apac-chn-cybersecurity-law-2017": [ "Article 40" @@ -666,33 +662,46 @@ "9.1.1.15", "9.4.1.8.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.53", + "10.54", + "10.56", + "10.57" + ], "apac-nzl-ism-3-9": [ - "16.1.31.C.01" + "16.1.31.C.01", + "16.4.39.C.01", + "20.2.16.C.02" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.1" ], "apac-sgp-mas-trm-2021": [ - "9.1.2", - "9.1.3", - "9.1.8" + "9.1.8", + "9.2.2" + ], + "americas-arg-ppd-2018": [ + "B", + "D.1.2-1" ], "americas-bmu-mba-coc-2020": [ "6.6" ], - "amaericas-can-osfi-self-assessment": [ - "4.22", - "4.24" - ], "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.A", "03.01.18.B", "03.05.01.A", "03.05.05.A", "03.05.12.E" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(b)" ] } }, @@ -714,7 +723,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to retain a record of personnel accountability to ensure there is a record of all access granted to an individual (system and application-wise), who provided the authorization, when the authorization was granted and when the access was last reviewed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -800,7 +809,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -822,8 +832,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1503" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0407" + ], + "apac-sgp-mas-trm-2021": [ + "9.1.3" ] } }, @@ -847,7 +860,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).\n▪ LAC and RBAC enforcements limit the ability of non-administrators from making unauthorized configuration changes to TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to strictly govern the use of Authenticate, Authorize and Audit (AAA) solutions, both on-premises and those hosted by an External Service Provider (ESP).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -926,7 +939,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -1042,6 +1056,8 @@ "IA-4" ], "general-nist-800-171-r3": [ + "03.01.01.d.01", + "03.01.16.b", "03.05.01.a", "03.05.02", "03.05.05.d", @@ -1051,18 +1067,23 @@ "03.05.07.d", "03.05.07.e", "03.05.12.d", - "03.05.12.f", "03.07.05.a" ], "general-nist-800-171a-r3": [ "A.03.01.01.d.01", - "A.03.01.01.d.02", "A.03.01.16.b", "A.03.05.01.a[01]", - "A.03.05.01.a[02]" - ], - "general-nist-800-172": [ - "3.5.2e" + "A.03.05.01.a[02]", + "A.03.05.02[01]", + "A.03.05.02[02]", + "A.03.05.05.d", + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.12.d", + "A.03.07.05.a[01]" ], "general-nist-800-207": [ "NIST Tenet 2", @@ -1076,9 +1097,6 @@ "PR.AA-04", "PR.AA-05" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0031" ], @@ -1154,12 +1172,31 @@ "2447(c)(1)(B)", "2447(c)(2)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(g)" + ], "emea-eu-nis2-annex-2024": [ "11.3.2(a)", "11.4.2(c)", "11.6.1", "11.6.3" ], + "emea-deu-c5-2020": [ + "IDM-02", + "IDM-03-BP2", + "IDM-08-BP2" + ], + "emea-sau-ecc-1-2018": [ + "2-2-3-1" + ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP5", + "4", + "4-BP2" + ], "emea-gbr-def-stan-05-138-2024": [ "2200", "2209", @@ -1182,6 +1219,10 @@ "2210", "2304" ], + "apac-aus-ism-2026-march": [ + "ISM-2013", + "ISM-2014" + ], "apac-jpn-ismap": [ "9.4.2", "9.4.2.1", @@ -1201,14 +1242,28 @@ "9.4.2.15", "9.4.2.16" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP39", "HML39" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP34" ], + "apac-nzl-ism-3-9": [ + "16.1.26.C.01" + ], + "americas-arg-ppd-2018": [ + "B.2.3-1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.D.01", + "03.01.16.B", "03.05.01.A", "03.05.02", "03.05.05.D", @@ -1218,7 +1273,6 @@ "03.05.07.D", "03.05.07.E", "03.05.12.D", - "03.05.12.F", "03.07.05.A" ] } @@ -1344,7 +1398,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -1374,6 +1429,113 @@ ] } }, + { + "control_id": "IAC-01.4", + "title": "Identity Providers (IdP) & Authorization Servers", + "family": "IAC", + "description": "Mechanisms exist to employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms.", + "scf_question": "Does the organization employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to employ identity providers and authorization servers to manage user, device and Non-Person Entity (NPE) identities, attributes and access rights that support authentication and authorization decisions:\n(1) In accordance with organization-defined identification and authentication policy; and\n(2) Using organization-defined mechanisms.", + "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "small": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "medium": "∙ Microsoft Entra ID \n∙ Google Workspace Identity \n∙ Okta", + "large": "∙ Microsoft Entra ID with conditional access\n∙ Okta Workforce Identity\n∙ SailPoint for identity governance", + "enterprise": "∙ Enterprise IdP with federation (SAML/OIDC/OAuth 2.0)\n∙ Microsoft Entra ID with Privileged Identity Management\n∙ Okta or Ping Identity enterprise tier\n∙ SailPoint or Saviynt for identity governance" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Identification & Authentication", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.05.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.07E[01]", + "A.03.05.07E.ODP[02]", + "DS-A.03.05.07E[02]", + "DS-A.03.05.07E[03]" + ] + } + }, { "control_id": "IAC-02", "title": "Identification & Authentication for Organizational Users", @@ -1398,7 +1560,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1485,7 +1647,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -1553,7 +1716,7 @@ "general-iso-27018-2025": [ "5.15" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -1895,10 +2058,10 @@ "IA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "IA-2", @@ -1921,34 +2084,18 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(a)" ], - "emea-deu-c5-2020": [ - "IDM-01", - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.31", - "4.34" - ], - "emea-sau-ecc-1-2018": [ - "2-2-3" + "emea-sau-otcc-1-2022": [ + "2-2-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-32" + "VII.B.TPC-32" ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.3" - ], - "emea-esp-decree-311-2022": [ - "24.3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2" ], "emea-gbr-caf-4-0": [ "B2.a" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" - ], "emea-gbr-def-stan-05-138-2024": [ "2218" ], @@ -1961,7 +2108,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2218" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0414", "ISM-0415", "ISM-1546" @@ -1969,19 +2116,9 @@ "apac-nzl-ism-3-9": [ "16.1.32.C.01" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ - "03.05.01.A" + "03.05.01.A", + "03.05.05.D" ] } }, @@ -2003,9 +2140,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2073,7 +2210,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -2134,19 +2272,12 @@ "usa-federal-gsa-fedramp-5-high": [ "IA-02(05)" ], - "emea-isr-cmo-1-0": [ - "4.34" - ], - "emea-sau-cscc-1-2019": [ - "2-2-1-7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0415", "ISM-1619" ], "apac-nzl-ism-3-9": [ "16.1.33.C.01", - "16.1.33.C.02", "16.1.34.C.01" ] } @@ -2245,7 +2376,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -2295,9 +2427,6 @@ "A.03.05.04[02]", "A.03.07.05.b[02]" ], - "general-nist-800-172": [ - "3.5.1e" - ], "general-nist-csf-2-0": [ "PR.AA-04" ], @@ -2349,9 +2478,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (08)" ], - "emea-isr-cmo-1-0": [ - "4.31" - ], "emea-gbr-def-stan-05-138-2024": [ "2215" ], @@ -2364,7 +2490,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2215" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1055", "ISM-1603" ], @@ -2392,9 +2518,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify organizational Personal Identity Verification (PIV) credentials.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify organizational Personal Identity Verification (PIV) credentials. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2476,7 +2602,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -2554,9 +2681,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Out-of-Band Authentication (OOBA) under specific conditions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Out-of-Band Authentication (OOBA) under specific conditions. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2638,7 +2765,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -2677,7 +2805,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2766,7 +2894,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -2817,7 +2946,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1053", "T1053.007", "T1059", @@ -2880,6 +3009,9 @@ "general-nist-800-171-r3": [ "03.05.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.05.01.a[03]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -2937,43 +3069,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-08" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.21" - ], - "emea-sau-ecc-1-2018": [ - "2-2-3" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.3" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-32" ], - "emea-esp-decree-311-2022": [ - "24.3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "emea-gbr-caf-4-0": [ "B2.a" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1583" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ "03.05.01.A" ] @@ -2997,7 +3104,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3081,7 +3188,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -3150,9 +3258,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3233,7 +3341,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -3292,10 +3401,6 @@ "IA-8(CE-2)", "IA-8(CE-2).a", "IA-8(CE-2).b" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" ] } }, @@ -3317,9 +3422,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to conform systems to Federal Identity, Credential and Access Management (FICAM)-issued profiles. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3385,7 +3490,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -3454,7 +3560,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disassociate user attributes or credential assertion relationships among individuals, credential service providers and relying parties.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3493,7 +3599,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -3526,7 +3633,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3558,7 +3665,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -3591,7 +3699,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3680,7 +3788,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -3732,7 +3841,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1530", "T1537", "T1552", @@ -3799,12 +3908,18 @@ "03.05.02" ], "general-nist-800-171a-r3": [ + "A.03.01.18.b", "A.03.05.02.ODP[01]", "A.03.05.02[01]", "A.03.05.02[02]" ], - "general-nist-800-172": [ - "3.5.1e" + "general-nist-800-172-r3": [ + "03.05.01E", + "03.05.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.01E", + "DS-A.03.05.03E" ], "general-nist-800-207": [ "NIST Tenet 2", @@ -3876,20 +3991,13 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(a)" ], - "emea-us-psd2-2015": [ - "25" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.33" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "emea-gbr-caf-4-0": [ "B2.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1603" ], "americas-can-itsp-10-171-2025": [ @@ -3916,11 +4024,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure device identification and authentication is accurate by centrally-managing the joining of systems to the domain as part of the initial asset configuration management process.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -3984,7 +4092,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -4000,6 +4109,12 @@ "general-nist-800-82-r3": [ "IA-03(04)" ], + "general-nist-800-172-r3": [ + "03.05.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.03E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-low": [ "IA-03(04)" ], @@ -4032,7 +4147,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce cryptographic communications keys to prevent one key from being used to access multiple devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4093,7 +4208,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -4123,7 +4239,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify and authenticate third-party Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4212,7 +4328,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -4246,7 +4363,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1036", "T1036.001", "T1036.005", @@ -4295,6 +4412,11 @@ "03.05.01.a", "03.05.02" ], + "general-nist-800-171a-r3": [ + "A.03.05.01.a[03]", + "A.03.05.02[01]", + "A.03.05.02[02]" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -4316,29 +4438,19 @@ "usa-federal-irs-1075-2021": [ "IA-9" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.2" + "emea-sau-cscc-1-2019": [ + "2-2-1-7" ], - "emea-sau-ecc-1-2018": [ - "2-2-3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP49", "HML49" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP41" ], - "apac-sgp-mas-trm-2021": [ - "9.1.8" - ], "americas-can-itsp-10-171-2025": [ "03.05.01.A", "03.05.02" @@ -4363,11 +4475,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure external service providers provide current and accurate information for any third-party user with access to the organization's data or assets.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -4447,7 +4559,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -4573,7 +4686,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -4598,6 +4712,9 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[01]" + ], "general-nist-800-207": [ "NIST Tenet 4" ], @@ -4613,8 +4730,8 @@ "control_id": "IAC-06", "title": "Multi-Factor Authentication (MFA)", "family": "IAC", - "description": "Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:\n(1) Remote network access; \n(2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n(3) Non-console access to critical TAAS that store, transmit and/or process sensitive/regulated data.", - "scf_question": "Does the organization use automated mechanisms to enforce Multi-Factor Authentication (MFA) for:\n (1) Remote network access; \n (2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n (3) Non-console access to critical TAAS that store, transmit and/or process sensitive/regulated data?", + "description": "Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:\n(1) Remote network access; \n(2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n(3) Non-console access to critical TAAS that store, transmit and/or process sensitive and/or regulated data.", + "scf_question": "Does the organization use automated mechanisms to enforce Multi-Factor Authentication (MFA) for:\n (1) Remote network access; \n (2) Third-party Technology Assets, Applications and/or Services (TAAS); and/ or\n (3) Non-console access to critical TAAS that store, transmit and/or process sensitive and/or regulated data?", "relative_weight": 9, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -4717,7 +4834,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -4866,9 +4984,6 @@ "8.4.3", "8.5.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "4.2" ], @@ -4921,6 +5036,9 @@ "IA-02(01)", "IA-02(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(4)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(5)" ], @@ -4966,12 +5084,9 @@ "11.3.2(a)", "11.7.1" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-isr-cmo-1-0": [ - "4.21", - "4.32" + "emea-deu-c5-2020": [ + "RB-15-DOAR", + "IDM-08-BP3" ], "emea-sau-cscc-1-2019": [ "2-2-1-3", @@ -4983,14 +5098,14 @@ "2-15-3-5" ], "emea-sau-sacs-002-2022": [ - "TPC-4", - "TPC-5", - "TPC-37", - "TPC-44", - "TPC-45" + "VII.A.TPC-4", + "VII.A.TPC-5", + "VII.B.TPC-37", + "VII.B.TPC-44", + "VII.B.TPC-45" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "4-BP4" ], "emea-gbr-def-stan-05-138-2024": [ "2201", @@ -5016,7 +5131,7 @@ "ML2-P3", "ML3-P3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0974", "ISM-1173", "ISM-1401", @@ -5030,20 +5145,39 @@ "ISM-1681", "ISM-1682", "ISM-1683", - "ISM-1685" + "ISM-1685", + "ISM-1872", + "ISM-1873", + "ISM-1874", + "ISM-1892", + "ISM-1893", + "ISM-1894", + "ISM-2011" + ], + "apac-aus-cop-sitc-2020": [ + "1" ], "apac-ind-sebi-2024": [ "PR.AA.S7" ], + "apac-mys-bnm-rmit-2025": [ + "10.55" + ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01", + "16.1.29.C.02", + "16.4.37.C.02", + "16.7.42.C.01", + "16.7.42.C.04", + "16.7.42.C.05", + "16.7.42.C.06", + "16.7.42.C.07", + "16.7.43.C.01", + "16.7.44.C.01", "23.3.19.C.01", "23.3.19.C.02" ], "apac-sgp-cyber-hygiene-practice-2019": [ + "4.6", "4.6(b)" ], "apac-sgp-mas-trm-2021": [ @@ -5052,6 +5186,9 @@ "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.05.03", "03.07.05.B" @@ -5078,7 +5215,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5164,7 +5301,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -5243,6 +5381,9 @@ "3.5.3[a]", "3.5.3[c]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -5324,21 +5465,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" ], - "emea-isr-cmo-1-0": [ - "4.29" - ], "emea-sau-cscc-1-2019": [ "2-2-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-5", - "TPC-37" - ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "16.7.42.C.02", + "16.7.42.C.03" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.6(a)" @@ -5368,7 +5500,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5454,7 +5586,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -5520,6 +5653,9 @@ "general-nist-800-171a": [ "3.5.3[d]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[02]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -5590,19 +5726,15 @@ "emea-sau-cscc-1-2019": [ "2-2-1-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-5", - "TPC-45" - ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML3-P3" ], "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" + "16.7.42.C.03" + ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.6(b)" ], "americas-can-itsp-10-171-2025": [ "03.05.03" @@ -5627,9 +5759,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5715,7 +5847,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -5781,6 +5914,9 @@ "3.5.3[a]", "3.5.3[b]" ], + "general-nist-800-171a-r3": [ + "A.03.05.03[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -5847,28 +5983,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" ], - "emea-isr-cmo-1-0": [ - "4.30" + "emea-deu-c5-2020": [ + "RB-15-DOAR" ], "emea-sau-cscc-1-2019": [ "2-2-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-37" - ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML3-P3" ], - "apac-nzl-ism-3-9": [ - "16.7.34.C.01", - "16.7.34.C.02", - "16.7.35.C.01", - "16.7.36.C.01" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.6(a)" - ], "americas-can-itsp-10-171-2025": [ "03.05.03" ] @@ -5879,7 +6003,7 @@ "title": "Out-of-Band Multi-Factor Authentication", "family": "IAC", "description": "Mechanisms exist to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed.", - "scf_question": "Does the organization implements Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is securely provided by a device separate from the system gaining access?", + "scf_question": "Does the organization implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5892,9 +6016,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement Multi-Factor Authentication (MFA) for access to privileged and non-privileged accounts such that one of the factors is independently provided by a device separate from the system being accessed. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5976,7 +6100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -6038,6 +6163,9 @@ "general-nist-800-160-vol-2-r1": [ "IA-02(06)" ], + "general-nist-800-171-r3": [ + "03.05.03" + ], "general-nist-800-171a-r3": [ "A.03.05.03[01]", "A.03.05.03[02]" @@ -6102,6 +6230,9 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-02 (01)" + ], + "americas-can-itsp-10-171-2025": [ + "03.05.03" ] } }, @@ -6207,7 +6338,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -6240,7 +6372,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize a formal user registration and de-registration process that governs the assignment of access rights.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize a formal user registration and de-registration process that governs the assignment of access rights. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6329,7 +6461,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -6400,6 +6533,7 @@ "IA-12(04)" ], "general-nist-800-171-r3": [ + "03.01.01.b", "03.01.01.g.01", "03.01.01.g.02", "03.01.01.g.03", @@ -6413,7 +6547,13 @@ "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.05.05.a" + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -6476,17 +6616,23 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-12(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(7)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 6.1.1", "CIP-004-7 6.1.2", "CIP-004-7 6.3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(e)" + ], "emea-eu-nis2-annex-2024": [ "11.2.1", "11.2.2(a)", @@ -6499,15 +6645,33 @@ "6.6" ], "emea-deu-c5-2020": [ - "IDM-01", - "IDM-02", - "PSS-09" + "IDM-01-BP1", + "IDM-01-BP5", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-04", + "IDM-05" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" + ], + "emea-sau-ecc-1-2018": [ + "1-9-5" + ], + "emea-sau-otcc-1-2022": [ + "2-2-1-10", + "2-2-1-11" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-6" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.1 [OP.ACC.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1", + "op.acc.4", + "op.acc.5" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "4-BP6" ], "emea-gbr-def-stan-05-138-2024": [ "2702" @@ -6521,7 +6685,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2702" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0430" ], "apac-jpn-ismap": [ @@ -6534,7 +6698,7 @@ "9.2.6", "9.2.6.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -6545,7 +6709,11 @@ "apac-nzl-ism-3-9": [ "23.3.20.C.01" ], + "apac-sgp-mas-trm-2021": [ + "9.1.2" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.B", "03.01.01.G.01", "03.01.01.G.02", "03.01.01.G.03", @@ -6578,7 +6746,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6648,7 +6816,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -6684,6 +6853,14 @@ "03.05.05.a", "03.09.02.b.02" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.g.01", + "A.03.01.01.g.02", + "A.03.01.01.g.03", + "A.03.05.05.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -6728,10 +6905,10 @@ "ACCESS-2h" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "emea-eu-nis2-annex-2024": [ "1.2.6" @@ -6741,20 +6918,20 @@ "6.5", "6.6" ], - "emea-deu-c5-2020": [ - "PS-04", - "PSS-08" + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" ], "emea-sau-otcc-1-2022": [ - "2-2-1-10" + "2-2-1-11" ], - "apac-aus-ism-2024-june": [ - "ISM-0430" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], - "apac-chn-data-security-law-2021": [ - "27" + "apac-aus-ism-2026-march": [ + "ISM-0430" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -6879,7 +7056,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -6959,6 +7137,11 @@ "03.09.02.a.01", "03.09.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.09.02.a.01", + "A.03.09.02.a.02[01]", + "A.03.09.02.a.02[02]" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -7008,10 +7191,10 @@ "AC-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(C)" + "§ 164.308(a)(3)(ii)(C)" ], "usa-federal-irs-1075-2021": [ "AC-2" @@ -7036,14 +7219,20 @@ "6.5", "6.6" ], + "emea-isr-cmo-2-0": [ + "Appendix A, 9.2" + ], "emea-sau-otcc-1-2022": [ - "2-2-1-10", "2-2-1-11" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "apac-aus-ism-2026-march": [ "ISM-0430" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -7081,7 +7270,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Role-Based Access Control (RBAC) for TAASD to restrict access to individuals assigned specific roles with legitimate business needs.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -7152,7 +7341,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -7166,7 +7356,7 @@ ], "general-cis-csc-8-1": [ "3.3", - "6.0", + "6", "6.8" ], "general-cis-csc-8-1-ig1": [ @@ -7269,17 +7459,28 @@ "3.1.3[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.01", "A.03.01.01.c.02", "A.03.01.01.c.03", + "A.03.01.02[01]", + "A.03.01.02[02]", "A.03.01.05.ODP[01]", "A.03.01.05.ODP[02]", "A.03.01.05.b[01]", "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.12.a[02]", + "A.03.03.08.b", "A.03.04.05[04]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.07.06.a" + ], + "general-nist-800-172-r3": [ + "03.01.11E" ], - "general-nist-800-172": [ - "3.1.2e" + "general-nist-800-172a-r3": [ + "DS-A.03.01.11E.a", + "DS-A.03.01.11E.b" ], "general-nist-800-207": [ "NIST Tenet 3", @@ -7336,9 +7537,6 @@ "7.3.2", "7.3.3" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.2", "5.1" @@ -7394,20 +7592,20 @@ "155.260(a)(4)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)", - "164.514(d)(2)(i)(A)", - "164.514(d)(2)(i)(B)", - "164.514(d)(2)(ii)", - "164.530(c)(2)(ii)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)", + "§ 164.514(d)(2)(i)(A)", + "§ 164.514(d)(2)(i)(B)", + "§ 164.514(d)(2)(ii)", + "§ 164.530(c)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.308(a)(3)(ii)(A)", - "164.308(a)(4)(ii)(C)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.308(a)(3)(ii)(A)", + "§ 164.308(a)(4)(ii)(C)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "2.D.6" @@ -7443,7 +7641,7 @@ "2447(c)(2)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.2.(32)" + "3.4.2.32" ], "emea-eu-gdpr-2016": [ "Article 32.4" @@ -7453,43 +7651,31 @@ "11.2.2(d)", "11.4.1" ], - "emea-deu-bsrit-2017": [ - "6.2" + "emea-deu-fdpa-2017": [ + "2.1.2.27(1)", + "3.2.48(2)4" ], "emea-deu-c5-2020": [ - "PSS-08", - "PSS-11" - ], - "emea-isr-cmo-1-0": [ - "4.2", - "4.8", - "4.9", - "4.10", - "4.11", - "4.20", - "12.28", - "12.29" + "RB-15", + "IDM-01", + "IDM-01-BP3", + "BEI-12" ], "emea-sau-cgiot-2024": [ "2-2-1" ], "emea-sau-ecc-1-2018": [ - "2-2-3-3" + "2-2-3-3", + "2-6-3-2" ], "emea-sau-sacs-002-2022": [ - "TPC-39" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 17" + "VII.B.TPC-34" ], "emea-esp-decree-311-2022": [ - "17" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.4 [OP.ACC.4]" + "Article 17" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2" ], "emea-gbr-def-stan-05-138-2024": [ "2200", @@ -7516,11 +7702,11 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-1746" - ], - "apac-chn-data-security-law-2021": [ - "27" + "apac-aus-ism-2026-march": [ + "ISM-1746", + "ISM-1852", + "ISM-2092", + "ISM-2093" ], "apac-ind-sebi-2024": [ "PR.AA.S3" @@ -7537,15 +7723,15 @@ "9.4.1.6", "9.4.1.7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.56" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP40", "HHSP42", "HML40", "HML42" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS07" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP04", "HSUP37" @@ -7557,8 +7743,13 @@ "16.2.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "9.1.7", - "11.1.6" + "9.1.7" + ], + "americas-arg-ppd-2018": [ + "B.1.2-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01", @@ -7666,7 +7857,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -7715,7 +7907,7 @@ "general-iso-27018-2025": [ "5.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.005", "T1003.006", @@ -7814,7 +8006,8 @@ "A.03.05.05.ODP[01]", "A.03.05.05.b[01]", "A.03.05.05.b[02]", - "A.03.05.05.c" + "A.03.05.05.c", + "A.03.05.05.d" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -7864,10 +8057,10 @@ "IA-04" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(i)" + "§ 164.312(a)(2)(i)" ], "usa-federal-irs-1075-2021": [ "IA-4", @@ -7892,11 +8085,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-04" ], - "emea-deu-c5-2020": [ - "IDM-01" - ], - "emea-isr-cmo-1-0": [ - "12.15" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "americas-can-itsp-10-171-2025": [ "03.05.05.B", @@ -7925,7 +8115,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure proper user identification management for non-consumer users and administrators.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure proper user identification management for non-consumer users and administrators. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7995,7 +8185,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -8053,6 +8244,10 @@ "general-nist-800-171-r3": [ "03.05.05.b" ], + "general-nist-800-171a-r3": [ + "A.03.05.05.b[01]", + "A.03.05.05.b[02]" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -8102,11 +8297,8 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(b)" ], - "emea-isr-cmo-1-0": [ - "12.15" - ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], "americas-can-itsp-10-171-2025": [ "03.05.05.B" @@ -8131,9 +8323,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify contractors and other third-party users through unique username characteristics.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify contractors and other third-party users through unique username characteristics. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8203,7 +8395,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -8271,17 +8464,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-04 (04)" ], - "apac-nzl-privacy-act-2020": [ - "Principle 13", - "P13-(1)", - "P13-(2)", - "P13-(2)(a)", - "P13-(2)(b)", - "P13-(3)", - "P13-(4)(a)", - "P13-(4)(b)", - "P13-(5)" - ], "americas-can-itsp-10-171-2025": [ "03.05.05.D" ] @@ -8305,9 +8487,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to dynamically manage usernames and system identifiers.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to dynamically manage usernames and system identifiers. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8375,7 +8557,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -8417,7 +8600,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to coordinate username identifiers with external organizations for cross-organization management of identifiers.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to coordinate username identifiers with external organizations for cross-organization management of identifiers. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8483,7 +8666,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -8513,6 +8697,9 @@ ], "general-nist-800-161-r1-level-3": [ "IA-4(6)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ] } }, @@ -8534,7 +8721,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to uniquely manage privileged accounts to identify the account as a privileged user or service.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8606,7 +8793,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -8640,6 +8828,10 @@ "general-nist-800-171a": [ "3.1.5[a]" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b", + "A.03.05.05.d" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -8655,12 +8847,6 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05(08)" ], - "emea-deu-c5-2020": [ - "IDM-02" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "3" - ], "americas-can-itsp-10-171-2025": [ "03.01.07.B", "03.05.05.D" @@ -8722,7 +8908,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -8742,29 +8929,8 @@ "general-owasp-top-10-2025": [ "A01:2025" ], - "emea-zaf-popia-2013": [ - "6.1.b" - ], - "apac-aus-privacy-principles-2026": [ - "APP 2" - ], - "apac-jpn-ppi-2020": [ - "35-2(1)", - "35-2(2)", - "35-2(3)", - "35-2(4)", - "35-2(5)", - "35-2(6)", - "35-2(7)", - "35-2(8)", - "35-2(9)", - "36(1)", - "36(2)", - "36(3)", - "36(4)", - "37", - "38", - "39" + "apac-jpn-appi-2020": [ + "IV.2.35-2(1)" ] } }, @@ -8790,7 +8956,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to:\n(1) Securely manage authenticators for users and devices; and\n(2) Ensure the strength of authentication is appropriate to the classification of the data being accessed.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -8861,7 +9027,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -8929,7 +9096,7 @@ "5.17", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -9077,6 +9244,12 @@ "3.5.9" ], "general-nist-800-171a-r3": [ + "A.03.05.07.a[01]", + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", "A.03.05.12.ODP[01]", "A.03.05.12.ODP[02]", "A.03.05.12.a", @@ -9249,39 +9422,17 @@ "11.6.2(a)", "11.7.2" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "IDM-08" - ], - "emea-isr-cmo-1-0": [ - "4.35", - "12.15", - "12.16" - ], - "emea-sau-cscc-1-2019": [ - "2-2-1-6" - ], "emea-sau-cgiot-2024": [ "2-2-2" ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-8" - ], "emea-sau-sacs-002-2022": [ - "TPC-3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" + "VII.B.TPC-62" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "2" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1227", "ISM-1593", "ISM-1594", @@ -9304,12 +9455,11 @@ "14.3.13.C.01", "14.3.13.C.02", "14.3.13.C.03", + "16.1.36.C.02", + "16.1.36.C.03", "16.1.40.C.01", - "16.1.40.C.02", "16.1.41.C.01", "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04", "16.1.42.C.01" ], "americas-can-itsp-10-171-2025": [ @@ -9418,7 +9568,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -9523,10 +9674,8 @@ "03.05.07.e", "03.05.07.f", "03.05.12.b", - "03.05.12.c", "03.05.12.d", - "03.05.12.e", - "03.05.12.f" + "03.05.12.e" ], "general-nist-800-171a": [ "3.5.7[a]", @@ -9536,7 +9685,17 @@ ], "general-nist-800-171a-r3": [ "A.03.05.07.ODP[02]", - "A.03.05.07.f" + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.b", + "A.03.05.12.d", + "A.03.05.12.e" + ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.02E.ODP[02]" ], "general-owasp-top-10-2025": [ "A07:2025" @@ -9632,6 +9791,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(3)" + ], "usa-federal-irs-1075-2021": [ "IA-5(CE-1)", "IA-5(CE-1).f", @@ -9682,47 +9844,33 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (01)" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "IDM-09", - "PSS-07" - ], - "emea-isr-cmo-1-0": [ - "4.35", - "12.15", - "12.16" - ], "emea-sau-cscc-1-2019": [ "2-2-1-5" ], "emea-sau-cgiot-2024": [ "2-2-2" ], - "emea-sau-ecc-1-2018": [ - "2-2-3-1" - ], "emea-sau-otcc-1-2022": [ "2-2-1-8" ], "emea-sau-sacs-002-2022": [ - "TPC-2" + "VII.A.TPC-2" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0417", "ISM-0421", "ISM-0422", "ISM-1557", "ISM-1558", "ISM-1596", - "ISM-1795" + "ISM-1795", + "ISM-1980", + "ISM-2079", + "ISM-2080", + "ISM-2081" ], "apac-aus-cop-sitc-2020": [ - "Principle 1" + "1" ], "apac-jpn-ismap": [ "9.3.1.4", @@ -9738,6 +9886,9 @@ "9.4.3.9" ], "apac-nzl-ism-3-9": [ + "16.1.29.C.01", + "16.1.31.C.02", + "16.1.31.C.07", "16.1.35.C.01", "16.1.35.C.02", "16.1.42.C.01", @@ -9746,14 +9897,15 @@ "apac-sgp-mas-trm-2021": [ "9.1.4" ], + "americas-arg-ppd-2018": [ + "B.2.3-7" + ], "americas-can-itsp-10-171-2025": [ "03.05.07.E", "03.05.07.F", "03.05.12.B", - "03.05.12.C", "03.05.12.D", - "03.05.12.E", - "03.05.12.F" + "03.05.12.E" ] } }, @@ -9775,7 +9927,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically validate certificates by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information for PKI-based authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9858,7 +10010,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -9981,13 +10134,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (02)" - ], - "emea-deu-c5-2020": [ - "IDM-09" - ], - "emea-isr-cmo-1-0": [ - "12.15", - "12.16" ] } }, @@ -10096,7 +10242,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -10121,6 +10268,9 @@ "general-nist-800-171-r3": [ "03.05.12.a" ], + "general-nist-800-171a-r3": [ + "A.03.05.12.a" + ], "usa-federal-gsa-fedramp-5-low": [ "IA-12(04)" ], @@ -10161,9 +10311,9 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Password managers are not governed.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -10230,7 +10380,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -10290,6 +10441,12 @@ "A.03.05.07.a[03]", "A.03.05.07.b" ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.02E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -10328,12 +10485,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (01)" ], - "emea-us-psd2-2015": [ - "19" - ], - "emea-deu-c5-2020": [ - "PSS-07" - ], "emea-gbr-def-stan-05-138-2024": [ "2213" ], @@ -10346,11 +10497,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2213" ], + "apac-aus-ism-2026-march": [ + "ISM-2078" + ], "apac-nzl-ism-3-9": [ "16.1.41.C.01", - "16.1.41.C.02", - "16.1.41.C.03", - "16.1.41.C.04" + "16.1.41.C.02" ], "americas-can-itsp-10-171-2025": [ "03.05.07.A", @@ -10378,7 +10530,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.\n▪ Password managers are not governed.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10447,7 +10599,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -10515,6 +10668,12 @@ "A.03.05.12.f[01]", "A.03.05.12.f[02]" ], + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.02E.b" + ], "general-pci-dss-4-0-1": [ "8.3.11" ], @@ -10579,27 +10738,17 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(b)" ], - "emea-us-psd2-2015": [ - "19", - "22" - ], "emea-deu-c5-2020": [ - "IDM-08", - "PSS-07" - ], - "emea-isr-cmo-1-0": [ - "4.37" + "IDM-07", + "IDM-08" ], "emea-sau-cscc-1-2019": [ "2-2-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-3" + "VII.A.TPC-3" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0418", "ISM-1402", "ISM-1590", @@ -10618,6 +10767,7 @@ "9.3.1.7" ], "apac-nzl-ism-3-9": [ + "16.1.34.C.02", "16.1.36.C.01", "16.1.37.C.01", "16.1.38.C.01" @@ -10649,7 +10799,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10719,7 +10869,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -10747,6 +10898,15 @@ "general-nist-800-171-r3": [ "03.05.07.d" ], + "general-nist-800-171a-r3": [ + "A.03.05.07.d" + ], + "general-nist-800-172-r3": [ + "03.05.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.04E" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -10783,8 +10943,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (07)" ], - "emea-sau-sacs-002-2022": [ - "TPC-62" + "apac-aus-cop-sitc-2020": [ + "4" ], "apac-nzl-ism-3-9": [ "16.1.36.C.01" @@ -10879,7 +11039,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -11084,7 +11245,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -11194,6 +11356,10 @@ "03.05.07.e", "03.05.12.d" ], + "general-nist-800-171a-r3": [ + "A.03.05.07.e", + "A.03.05.12.d" + ], "general-owasp-top-10-2025": [ "A07:2025" ], @@ -11256,6 +11422,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IA-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(2)" + ], "usa-federal-irs-1075-2021": [ "IA-5", "IA-5(CE-5)" @@ -11281,12 +11450,18 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05" ], + "emea-sau-cscc-1-2019": [ + "2-3-1-7" + ], "emea-sau-cgiot-2024": [ "2-2-2" ], "emea-sau-otcc-1-2022": [ "2-2-1-3" ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP2" + ], "emea-gbr-def-stan-05-138-2024": [ "2211" ], @@ -11299,12 +11474,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2211" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1304", - "ISM-1806" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 1" + "ISM-1806", + "ISM-2044" ], "americas-can-itsp-10-171-2025": [ "03.05.07.E", @@ -11330,7 +11503,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement security safeguards to manage the risk of compromise due to individuals having accounts on multiple Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11398,7 +11571,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -11516,7 +11690,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -11535,6 +11710,12 @@ "general-nist-800-82-r3": [ "IA-05(13)" ], + "general-nist-800-172-r3": [ + "03.05.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.05.05E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-high": [ "IA-05(13)" ] @@ -11558,7 +11739,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ Password managers are provided, but decentralized and not actively governed.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to protect and store passwords via a password manager tool.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11631,7 +11812,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -11668,10 +11850,16 @@ "A.03.05.07.a[01]", "A.03.05.07.a[02]", "A.03.05.07.a[03]", - "A.03.05.07.b" + "A.03.05.07.b", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.f" ], - "general-nist-800-172": [ - "3.5.2e" + "general-nist-800-172-r3": [ + "03.05.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.02E.a" ], "general-swift-cscf-2025": [ "5.4" @@ -11688,11 +11876,9 @@ "emea-sau-otcc-1-2022": [ "2-2-1-9" ], - "emea-sau-sacs-002-2022": [ - "TPC-3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.5 [OP.ACC.5]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2212" @@ -11706,7 +11892,8 @@ "apac-nzl-ism-3-9": [ "14.3.13.C.01", "14.3.13.C.02", - "14.3.13.C.03" + "14.3.13.C.03", + "16.1.37.C.02" ], "americas-can-itsp-10-171-2025": [ "03.05.07.A", @@ -11819,7 +12006,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -11944,7 +12132,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -12042,7 +12231,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -12071,7 +12261,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to obscure the feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to obscure the feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12141,7 +12331,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -12169,7 +12360,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.10" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1021.005", "T1530", @@ -12245,9 +12436,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-06" ], - "emea-isr-cmo-1-0": [ - "4.36" - ], "emea-gbr-def-stan-05-138-2024": [ "2419", "2420" @@ -12287,7 +12475,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure cryptographic modules adhere to applicable statutory, regulatory and contractual requirements for security strength.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12357,7 +12545,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -12379,7 +12568,7 @@ "general-govramp-high": [ "IA-07" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1495", "T1542", @@ -12457,9 +12646,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "IA-07" - ], - "emea-isr-cmo-1-0": [ - "4.37" ] } }, @@ -12481,9 +12667,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Hardware Security Modules (HSM) to protect authenticators on which the component relies.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Hardware Security Modules (HSM) to protect authenticators on which the component relies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12546,7 +12732,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -12585,7 +12772,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to allow individuals to utilize alternative methods of authentication under specific circumstances or situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12657,7 +12844,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -12687,7 +12875,7 @@ "title": "Single Sign-On (SSO) Transparent Authentication", "family": "IAC", "description": "Mechanisms exist to provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to the organization's Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization provide a Single Sign-On (SSO) capability to its Technology Assets, Applications and/or Services (TAAS)?", + "scf_question": "Does the organization provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to its Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -12700,7 +12888,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a transparent authentication (e.g., Single Sign-On (SSO)) capability to the organization's Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12768,7 +12956,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -12807,7 +12996,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to federate credentials to allow cross-organization authentication of individuals and devices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12875,7 +13064,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -12998,7 +13188,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -13037,7 +13228,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -13107,11 +13298,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1110", "T1110.001", "T1110.002", @@ -13205,8 +13397,8 @@ "control_id": "IAC-15", "title": "Account Management", "family": "IAC", - "description": "Mechanisms exist to proactively govern account management of individual, group, system, service, application, guest and temporary accounts.", - "scf_question": "Does the organization proactively govern account management of individual, group, system, service, application, guest and temporary accounts?", + "description": "Mechanisms exist to:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts.", + "scf_question": "Does the organization:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -13222,9 +13414,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to proactively govern account management of individual, group, system, service, application, guest and temporary accounts.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to:\n(1) Define authorized system account types;\n(2) Define prohibited system account types; and\n(3) Proactively govern individual, group, system, service, application, guest and temporary accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -13237,11 +13429,11 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "micro_small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "small": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "medium": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "large": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)", - "enterprise": "∙ Microsoft Active Directory (https://microsoft.com)\n∙ Microsoft Entra (https://microsoft.com)\n∙ AWS IAM (https://aws.amazon.com)" + "micro_small": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "small": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "medium": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "large": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM", + "enterprise": "∙ Microsoft Active Directory\n∙ Microsoft Entra\n∙ AWS IAM" }, "risks": [ "R-AC-1", @@ -13297,8 +13489,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed", "family_name": "Identification & Authentication", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -13347,7 +13541,7 @@ "5.16", "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -13632,6 +13826,7 @@ "03.01.01.d.02", "03.01.01.e", "03.01.01.f.01", + "03.01.01.f.02", "03.01.01.f.03", "03.01.01.f.04", "03.01.01.f.05", @@ -13641,7 +13836,8 @@ "03.01.02", "03.01.05.b", "03.01.05.c", - "03.01.05.d" + "03.01.05.d", + "03.05.07.e" ], "general-nist-800-171a": [ "3.1.2[a]", @@ -13651,7 +13847,13 @@ "A.03.01.01.ODP[01]", "A.03.01.01.a[01]", "A.03.01.01.a[02]", + "A.03.01.01.b[01]", + "A.03.01.01.b[02]", + "A.03.01.01.b[03]", "A.03.01.01.c.01", + "A.03.01.01.c.02", + "A.03.01.01.d.01", + "A.03.01.01.d.02", "A.03.01.01.e", "A.03.01.01.f.01", "A.03.01.01.f.02", @@ -13661,6 +13863,12 @@ "A.03.01.01.g.01", "A.03.01.01.g.02", "A.03.01.01.g.03", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.05.c", + "A.03.01.05.d", "A.03.05.07.e" ], "general-pci-dss-4-0-1": [ @@ -13721,10 +13929,10 @@ "AC-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "AC-2" @@ -13774,23 +13982,35 @@ "2447(c)(1)(A)(i)", "2447(c)(1)(A)(iv)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(c)" + ], "emea-eu-nis2-annex-2024": [ "11.2.2(c)", "11.5.2(c)" ], - "emea-deu-bsrit-2017": [ - "6.2" + "emea-deu-c5-2020": [ + "IDM-02" ], - "emea-isr-cmo-1-0": [ - "4.3", - "4.4", - "4.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 8.1" ], "emea-sau-cscc-1-2019": [ "2-2-1-7" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-10" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-32" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1", + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1", + "4-BP1", + "4-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2424" @@ -13801,9 +14021,18 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2424" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0441", - "ISM-0443" + "ISM-0443", + "ISM-1832", + "ISM-1834", + "ISM-1845", + "ISM-1940", + "ISM-1941", + "ISM-1942" + ], + "apac-aus-cop-sitc-2020": [ + "1" ], "apac-ind-sebi-2024": [ "PR.AA.S1" @@ -13819,7 +14048,10 @@ "9.2.1.6.PB", "9.2.4.9.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.56" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP38", "HML38" ], @@ -13827,6 +14059,15 @@ "HSUP33", "HSUP35" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.1" + ], + "apac-sgp-mas-trm-2021": [ + "9.1.8" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.A", "03.01.01.B", @@ -13836,6 +14077,7 @@ "03.01.01.D.02", "03.01.01.E", "03.01.01.F.01", + "03.01.01.F.02", "03.01.01.F.03", "03.01.01.F.04", "03.01.01.F.05", @@ -13845,7 +14087,8 @@ "03.01.02", "03.01.05.B", "03.01.05.C", - "03.01.05.D" + "03.01.05.D", + "03.05.07.E" ] } }, @@ -13854,7 +14097,7 @@ "title": "Automated System Account Management (Directory Services)", "family": "IAC", "description": "Automated mechanisms exist to support the management of system accounts (e.g., directory services).", - "scf_question": "Does the organization use automated mechanisms to support the management of system accounts?", + "scf_question": "Does the organization use automated mechanisms to support the management of system accounts (e.g., directory services)?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -13867,9 +14110,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically support the management of system accounts (e.g., directory services).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically support the management of system accounts (e.g., directory services). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -13938,14 +14181,15 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { "general-cis-csc-8-1": [ - "5.0", + "5", "5.6", - "6.0" + "6" ], "general-cis-csc-8-1-ig2": [ "5.6" @@ -14011,6 +14255,7 @@ "3.5.2" ], "general-nist-800-171-r3": [ + "03.01.01.d.01", "03.05.05.b", "03.05.05.c", "03.05.05.d", @@ -14022,6 +14267,33 @@ "03.05.12.e", "03.05.12.f" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.d.01", + "A.03.05.05.b[01]", + "A.03.05.05.b[02]", + "A.03.05.05.c", + "A.03.05.05.d", + "A.03.05.07.c", + "A.03.05.07.d", + "A.03.05.07.e", + "A.03.05.07.f", + "A.03.05.12.d", + "A.03.05.12.e", + "A.03.05.12.f[01]", + "A.03.05.12.f[02]" + ], + "general-nist-800-172-r3": [ + "03.01.07E", + "03.01.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]", + "DS-A.03.01.11E.a" + ], "general-nist-800-207": [ "NIST Tenet 3", "NIST Tenet 4" @@ -14060,6 +14332,20 @@ "AC-2-IS.3", "AC-2(1)" ], + "emea-deu-c5-2020": [ + "IDM-03-BP2", + "IDM-08-BP2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cap-1850-2020": [ + "B2" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP6" + ], "emea-gbr-def-stan-05-138-2024": [ "2209", "2218" @@ -14074,13 +14360,20 @@ "2209", "2218" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1649" ], "apac-jpn-ismap": [ "9.2.2.5" ], + "apac-sgp-mas-trm-2021": [ + "9.2.2" + ], + "americas-arg-ppd-2018": [ + "B.2.3-2" + ], "americas-can-itsp-10-171-2025": [ + "03.01.01.D.01", "03.05.05.B", "03.05.05.C", "03.05.05.D", @@ -14112,9 +14405,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable or remove temporary and emergency accounts after an organization-defined time period for each type of account.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable or remove temporary and emergency accounts after an organization-defined time period for each type of account. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -14181,7 +14474,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -14231,10 +14525,10 @@ "AC-02(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "AC-2(CE-2)" @@ -14242,12 +14536,9 @@ "usa-federal-cms-marse-2-0": [ "AC-2(2)" ], - "emea-deu-c5-2020": [ - "IDM-04", - "PSS-09" - ], - "emea-isr-cmo-1-0": [ - "4.4" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ] } }, @@ -14269,9 +14560,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable inactive accounts after an organization-defined time period.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically disable inactive accounts after an organization-defined time period. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -14340,7 +14631,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -14456,20 +14748,23 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-02 (03)" ], - "emea-deu-c5-2020": [ - "IDM-03" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" ], - "emea-isr-cmo-1-0": [ - "4.5" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP3" ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1404", "ISM-1648" ], + "americas-arg-ppd-2018": [ + "B.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.F.02" ] @@ -14495,9 +14790,9 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically audit account creation, modification, enabling, disabling and removal actions and notify organization-defined personnel or roles.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically audit account creation, modification, enabling, disabling and removal actions and notify organization-defined personnel or roles. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -14560,7 +14855,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -14591,6 +14887,16 @@ "general-nist-800-82-r3-high": [ "AC-02(04)" ], + "general-nist-800-172-r3": [ + "03.01.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.07E[01]", + "DS-A.03.01.07E[02]", + "DS-A.03.01.07E[03]", + "DS-A.03.01.07E[04]", + "DS-A.03.01.07E[05]" + ], "usa-federal-fbi-cjis-6-0": [ "AC-2(4)" ], @@ -14632,7 +14938,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to authorize the use of shared/group accounts only under certain organization-defined conditions.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -14700,7 +15006,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -14734,6 +15041,9 @@ "general-nist-800-171-r3": [ "03.01.01.c.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.c.01" + ], "general-pci-dss-4-0-1": [ "8.2.2" ], @@ -14781,14 +15091,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-02 (09)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(b)" + ], "emea-eu-nis2-annex-2024": [ "11.5.3" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.1" + ], "apac-nzl-ism-3-9": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.28.C.01", "16.1.33.C.01", - "16.1.33.C.02", "16.1.34.C.01" ], + "americas-arg-ppd-2018": [ + "B.2.3-8" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.01" ] @@ -14812,7 +15133,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to disable accounts immediately upon notification for users posing a significant risk to the organization.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -14884,7 +15205,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -14922,6 +15244,10 @@ "03.01.01.f.04", "03.01.01.f.05" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.f.04", + "A.03.01.01.f.05" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -14943,7 +15269,7 @@ "usa-federal-irs-1075-2021": [ "AC-2(CE-13)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1591" ], "americas-can-itsp-10-171-2025": [ @@ -14957,7 +15283,7 @@ "title": "System Account Reviews", "family": "IAC", "description": "Mechanisms exist to review all system accounts and disable any account that cannot be associated with a business process and owner.", - "scf_question": "Does the organization review all system accounts and disables any account that cannot be associated with a business process and owner?", + "scf_question": "Does the organization review all system accounts and disable any account that cannot be associated with a business process and owner?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -14972,11 +15298,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.\n▪ IAM inventories all privileged accounts and validates that each person with elevated privileges is authorized by the appropriate level of organizational management.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to review all system accounts and disable any account that cannot be associated with a business process and owner.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to review all system accounts and disable any account that cannot be associated with a business process and owner. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -15045,7 +15371,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -15054,18 +15381,15 @@ "CC6.2-POF3" ], "general-nist-800-171-r3": [ + "03.01.01.b", "03.01.01.e", "03.01.05.c" ], "general-nist-800-171a-r3": [ - "A.03.01.01.a[01]", - "A.03.01.01.a[02]", - "A.03.01.01.b[01]", - "A.03.01.01.b[02]", - "A.03.01.01.b[03]", "A.03.01.01.b[04]", "A.03.01.01.b[05]", - "A.03.01.01.c.01" + "A.03.01.01.e", + "A.03.01.05.c" ], "general-pci-dss-4-0-1": [ "8.6", @@ -15089,16 +15413,11 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(a)(4)" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-sau-cgiot-2024": [ "1-8-2" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-2" - ], "americas-can-itsp-10-171-2025": [ + "03.01.01.B", "03.01.01.E", "03.01.05.C" ] @@ -15122,11 +15441,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically enforce usage conditions for users and/or roles.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -15207,7 +15526,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -15258,7 +15578,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to establish and control \"emergency access only\" accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15344,7 +15664,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -15355,16 +15676,19 @@ "164.312(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(ii)" + "§ 164.312(a)(2)(ii)" + ], + "emea-deu-c5-2020": [ + "IDM-09" ], "apac-aus-essential-8-2024": [ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1610", "ISM-1611", "ISM-1612", @@ -15374,6 +15698,103 @@ ] } }, + { + "control_id": "IAC-15.10", + "title": "Account Separation Between Infrastructure Environments", + "family": "IAC", + "description": "Mechanisms exist to separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "scf_question": "Does the organization separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to separate non-privileged accounts between infrastructure environments to reduce the risk that a compromise in one infrastructure environment laterally affects another infrastructure environment.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Separate user accounts for production vs development environments\n∙ Role-based access restricting cross-environment access", + "small": "∙ Separate accounts per environment (dev, staging, prod)\n∙ Access restrictions preventing cross-environment access", + "medium": "∙ Separate cloud accounts or tenants per environment\n∙ AWS Organizations or Azure Management Groups for account separation\n∙ Privileged Access Management (PAM)", + "large": "∙ AWS Organizations, Azure Landing Zones, or GCP Organization policies for environment separation\n∙ PAM solution for privileged environment access\n∙ Zero Trust access between environments", + "enterprise": "∙ Enterprise cloud account separation via AWS Organizations or Azure Entra Tenants\n∙ Enterprise PAM (e.g., CyberArk, BeyondTrust)\n∙ Zero Trust architecture for cross-environment access\n∙ Automated account lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - (33 CFR Part 101 Subpart F)", + "family_name": "Identification & Authentication", + "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ] + } + }, { "control_id": "IAC-16", "title": "Privileged Account Management (PAM)", @@ -15398,7 +15819,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).\n▪ LAC and RBAC enforcements limit the ability of non-administrators from making unauthorized configuration changes to TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict and control privileged access rights for users and Technology Assets, Applications and/or Services (TAAS).", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -15486,7 +15907,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -15540,6 +15962,11 @@ "03.01.07.a", "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.01.07.b" + ], "general-pci-dss-4-0-1": [ "7.2.3", "7.2.5" @@ -15560,9 +15987,6 @@ "7.2.3", "7.2.5" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.2" ], @@ -15598,14 +16022,17 @@ "500.7(a)(3)", "500.7(c)(1)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(d)" + ], "emea-eu-nis2-annex-2024": [ "11.6.2(f)" ], "emea-deu-c5-2020": [ "IDM-06" ], - "emea-isr-cmo-1-0": [ - "4.2" + "emea-sau-cscc-1-2019": [ + "2-2-1-7" ], "emea-sau-cgiot-2024": [ "2-2-1" @@ -15613,12 +16040,17 @@ "emea-sau-ecc-1-2018": [ "2-2-3-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-34" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-caf-4-0": [ "B2.c" ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP6" + ], "emea-gbr-def-stan-05-138-2024": [ "2424" ], @@ -15633,7 +16065,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0445", "ISM-0446", "ISM-0447", @@ -15648,13 +16080,16 @@ "ISM-1650", "ISM-1687", "ISM-1688", - "ISM-1689" + "ISM-1689", + "ISM-1835", + "ISM-1939" ], "apac-ind-sebi-2024": [ "PR.AA.S11" ], "apac-jpn-ismap": [ "9.2.3", + "9.2.3.1", "9.2.3.2", "9.2.3.3", "9.2.3.4", @@ -15665,7 +16100,7 @@ "9.2.3.9", "9.2.3.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP41", "HML41" ], @@ -15674,24 +16109,15 @@ ], "apac-nzl-ism-3-9": [ "16.3.5.C.01", - "16.3.5.C.02", "16.3.6.C.01", "16.3.6.C.02", "16.3.7.C.01", - "16.4.30.C.01", - "16.4.30.C.02", - "16.4.30.C.03", - "16.4.31.C.01", - "16.4.31.C.02", - "16.4.32.C.01", - "16.4.32.C.02", - "16.4.33.C.01", - "16.4.34.C.01", - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03", "16.4.36.C.01", - "16.4.37.C.01" + "16.4.36.C.02", + "16.4.36.C.03", + "16.4.37.C.01", + "16.4.37.C.03", + "16.4.38.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.1" @@ -15699,13 +16125,18 @@ "apac-sgp-mas-trm-2021": [ "9.2.1" ], - "amaericas-can-osfi-self-assessment": [ - "4.23", - "4.24" + "americas-arg-ppd-2018": [ + "B.2.1-2", + "B.2.1-3", + "B.2.3-6", + "B.2.5-DS-2" ], "americas-can-osfi-b13-2022": [ "3.2.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.06.A", "03.01.07.A", @@ -15733,11 +16164,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -15806,7 +16237,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -15871,8 +16303,9 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(a)(4)" ], - "emea-sau-sacs-002-2022": [ - "TPC-34" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "2424" @@ -15884,7 +16317,7 @@ "2424" ], "apac-nzl-ism-3-9": [ - "16.4.34.C.01" + "16.4.40.C.01" ] } }, @@ -15975,10 +16408,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(6)" + ], "apac-nzl-ism-3-9": [ "23.3.18.C.01" ] @@ -16002,7 +16439,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure privilege change requests require additional levels of authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16069,7 +16506,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -16100,7 +16538,7 @@ "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to assign dedicated privileged user accounts to be used solely for duties requiring privileged access.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -16163,17 +16601,23 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { + "emea-gbr-cyber-essentials-requirements-3-3": [ + "4-BP5" + ], "apac-aus-essential-8-2024": [ "ML1-P4", "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-0445" + "apac-aus-ism-2026-march": [ + "ISM-0445", + "ISM-1827", + "ISM-1842" ] } }, @@ -16195,7 +16639,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enable a manual override of the current account privileges to enable the timely response to unusual conditions without terminating the current session and establishing a new session as a higher-privileged user.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16225,9 +16669,9 @@ "MT-2", "MT-8", "MT-9", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (IEC 62443-4-2)", "family_name": "Identification & Authentication", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -16335,7 +16779,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -16411,9 +16856,12 @@ "03.10.01.d" ], "general-nist-800-171a-r3": [ + "A.03.01.01.g.03", "A.03.01.05.ODP[03]", "A.03.01.05.c", - "A.03.01.05.d" + "A.03.01.05.d", + "A.03.10.01.c", + "A.03.10.01.d" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -16465,10 +16913,10 @@ "AC-06(07)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(B)" + "§ 164.308(a)(3)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "AC-6(CE-7)", @@ -16487,40 +16935,49 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-06 (07)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(e)", + "3.4.2.31(f)" + ], "emea-eu-nis2-annex-2024": [ "11.2.3", "11.3.3", "11.5.4" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-deu-c5-2020": [ - "IDM-05" + "IDM-01-BP4", + "IDM-05", + "IDM-05-DOAR", + "IDM-09-DOAR" ], - "emea-isr-cmo-1-0": [ - "4.3" + "emea-sau-cscc-1-2019": [ + "2-2-2" ], "emea-sau-cgiot-2024": [ "1-8-2", "2-2-3" ], "emea-sau-ecc-1-2018": [ - "1-9-5", "2-2-3-5" ], "emea-sau-otcc-1-2022": [ "2-2-1-10" ], "emea-sau-sacs-002-2022": [ - "TPC-33", - "TPC-34" + "VII.B.TPC-33" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0405", "ISM-1647", - "ISM-1648", - "ISM-1716" + "ISM-1648" ], "apac-ind-sebi-2024": [ "PR.AA.S5" @@ -16535,14 +16992,6 @@ "9.2.5.5", "9.2.5.6" ], - "apac-nzl-ism-3-9": [ - "16.4.35.C.01", - "16.4.35.C.02", - "16.4.35.C.03" - ], - "apac-sgp-mas-trm-2021": [ - "9.1.6" - ], "americas-can-itsp-10-171-2025": [ "03.01.01.G.03", "03.01.05.C", @@ -16572,7 +17021,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.).", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -16641,7 +17090,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -16709,15 +17159,13 @@ "usa-state-tx-txramp-2-0-level-2": [ "IA-05 (06)" ], - "emea-sau-cscc-1-2019": [ - "2-2-2" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0421", "ISM-0422" ], "apac-nzl-ism-3-9": [ - "16.4.37.C.01" + "16.4.37.C.01", + "16.4.38.C.02" ] } }, @@ -16808,7 +17256,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -16851,6 +17300,15 @@ "III.C.4", "III.C.4.a", "III.C.4.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], + "apac-nzl-ism-3-9": [ + "16.1.27.C.01", + "16.1.27.C.02", + "16.1.27.C.03" ] } }, @@ -16859,7 +17317,7 @@ "title": "Access Enforcement", "family": "IAC", "description": "Mechanisms exist to enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"", - "scf_question": "Does the organization enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege?\"", + "scf_question": "Does the organization enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16872,7 +17330,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Logical Access Control (LAC) permissions that conform to the principle of \"least privilege.\"", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16946,7 +17404,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -16997,7 +17456,7 @@ "general-iso-27018-2025": [ "5.18" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -17358,6 +17817,22 @@ "3.1.1[e]", "3.1.1[f]" ], + "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.09.02.b.01[02]", + "A.03.09.02.b.02" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -17469,18 +17944,19 @@ "AC-03", "AC-06" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "apac-ind-sebi-2024": [ "PR.AA.S15" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP10", "HHSP40", "HML10", "HML40" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS07" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP09" ], @@ -17502,8 +17978,8 @@ "control_id": "IAC-20.1", "title": "Access To Sensitive / Regulated Data", "family": "IAC", - "description": "Mechanisms exist to limit access to sensitive/regulated data to only those individuals whose job requires such access.", - "scf_question": "Does the organization limit access to sensitive/regulated data to only those individuals whose job requires such access?", + "description": "Mechanisms exist to limit access to sensitive and/or regulated data to only those individuals whose job requires such access.", + "scf_question": "Does the organization limit access to sensitive and/or regulated data to only those individuals whose job requires such access?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -17516,11 +17992,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit access to sensitive/regulated data to only those individuals whose job requires such access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit access to sensitive/regulated data to only those individuals whose job requires such access. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -17604,7 +18080,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -17629,13 +18106,26 @@ "03.01.03", "03.01.04.b", "03.01.05.a", + "03.01.05.b", "03.06.05.d", "03.10.01.a" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", + "A.03.01.02[02]", + "A.03.01.03[01]", + "A.03.01.03[02]", + "A.03.01.04.a", + "A.03.01.05.a", "A.03.01.05.b[01]", "A.03.01.05.b[02]", - "A.03.06.05.d" + "A.03.06.05.d", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]" ], "general-nist-800-207": [ "NIST Tenet 3" @@ -17678,6 +18168,10 @@ "7.2.5", "7.2.6" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.C.03", "03.01.01.D.01", @@ -17686,6 +18180,7 @@ "03.01.03", "03.01.04.B", "03.01.05.A", + "03.01.05.B", "03.06.05.D", "03.10.01.A" ] @@ -17695,8 +18190,8 @@ "control_id": "IAC-20.2", "title": "Database Access", "family": "IAC", - "description": "Mechanisms exist to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", - "scf_question": "Does the organization restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access?", + "description": "Mechanisms exist to restrict access to databases containing sensitive and/or regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", + "scf_question": "Does the organization restrict access to databases containing sensitive and/or regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -17709,11 +18204,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict access to databases containing sensitive/regulated data to only necessary Technology Assets, Applications and/or Services (TAAS) or those individuals whose job requires such access. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -17795,7 +18290,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -17819,6 +18315,10 @@ ], "emea-sau-cscc-1-2019": [ "2-2-1-8" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ] } }, @@ -17840,7 +18340,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict and tightly control utility programs that are capable of overriding system and application controls.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -17910,7 +18410,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -17951,7 +18452,11 @@ "500.7(a)(5)" ], "emea-deu-c5-2020": [ - "IDM-06" + "IDM-12" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" ], "apac-jpn-ismap": [ "9.4.4", @@ -17987,7 +18492,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to restrict executing administrative tasks or tasks requiring elevated access to a dedicated machine.", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -18073,7 +18578,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -18103,6 +18609,14 @@ ], "apac-aus-essential-8-2024": [ "ML3-P4" + ], + "apac-aus-ism-2026-march": [ + "ISM-1898" + ], + "americas-can-itsp-10-171-2025": [ + "03.01.06.C", + "03.14.08.A", + "03.14.08.C" ] } }, @@ -18124,7 +18638,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically enforce dual authorization for privileged commands.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18209,7 +18723,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -18235,8 +18750,12 @@ "general-nist-800-160-vol-2-r1": [ "AC-03(02)" ], - "general-nist-800-172": [ - "3.1.1e" + "general-nist-800-172-r3": [ + "03.01.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.01E", + "A.03.01.01E.ODP[01]" ], "usa-federal-gsa-fedramp-5-low": [ "AC-03(02)" @@ -18270,7 +18789,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM revokes user access rights in a timely manner, up on termination of employment or contract.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to revoke logical and physical access authorizations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -18343,7 +18862,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -18490,7 +19010,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": {} @@ -18517,9 +19038,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -18592,7 +19113,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -18658,7 +19180,7 @@ "8.3", "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -18976,6 +19498,7 @@ "03.01.01.c.03", "03.01.01.d.01", "03.01.01.d.02", + "03.01.02", "03.01.04.b", "03.01.05.a", "03.01.05.b", @@ -18991,8 +19514,20 @@ "3.1.5[d]" ], "general-nist-800-171a-r3": [ + "A.03.01.01.c.03", + "A.03.01.01.d.01", + "A.03.01.01.d.02", + "A.03.01.02[01]", "A.03.01.02[02]", - "A.03.01.05.a" + "A.03.01.04.a", + "A.03.01.05.a", + "A.03.01.05.b[01]", + "A.03.01.05.b[02]", + "A.03.01.06.a", + "A.03.01.07.a", + "A.03.03.08.a[02]", + "A.03.03.08.b", + "A.03.04.05[04]" ], "general-nist-800-207": [ "NIST Tenet 3" @@ -19057,9 +19592,6 @@ "7.3.3", "8.6.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0039" ], @@ -19106,16 +19638,19 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(5)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(c)(1)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(i)", - "164.312(a)(1)" + "§ 164.308(a)(3)(i)", + "§ 164.312(a)(1)" ], "usa-federal-irs-1075-2021": [ "AC-6" @@ -19146,8 +19681,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-06" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(a)" ], "emea-eu-dora-2023": [ "Article 9.4(c)" @@ -19159,15 +19694,13 @@ "11.3.2(c)", "11.3.2(d)" ], - "emea-deu-bsrit-2017": [ - "6.2" - ], "emea-deu-c5-2020": [ - "IDM-07" - ], - "emea-isr-cmo-1-0": [ - "4.10", - "12.29" + "IDM-03-BP1", + "IDM-03-BP2", + "IDM-03-BP4", + "IDM-10", + "IDM-12", + "IDM-13" ], "emea-sau-cgiot-2024": [ "2-2-1" @@ -19175,13 +19708,23 @@ "emea-sau-otcc-1-2022": [ "2-3-1-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 17", - "Article 20" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-34" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.5" ], "emea-esp-decree-311-2022": [ - "17", - "20" + "Article 12(6)(h)", + "Article 20" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "2-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "2205", @@ -19204,7 +19747,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0441", "ISM-0611", "ISM-1380", @@ -19212,7 +19755,11 @@ "ISM-1705", "ISM-1706", "ISM-1707", - "ISM-1708" + "ISM-1708", + "ISM-1833" + ], + "apac-aus-cop-sitc-2020": [ + "6" ], "apac-ind-sebi-2024": [ "PR.AA.S3" @@ -19228,14 +19775,15 @@ "9.1.2.7", "9.1.2.8" ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], "apac-nzl-ism-3-9": [ "16.2.4.C.01", - "16.4.31.C.01", - "16.4.31.C.02", "23.4.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "9.1.1" + "9.1.7" ], "americas-can-osfi-b13-2022": [ "3.2.7" @@ -19244,6 +19792,7 @@ "03.01.01.C.03", "03.01.01.D.01", "03.01.01.D.02", + "03.01.02", "03.01.04.B", "03.01.05.A", "03.01.05.B", @@ -19343,7 +19892,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -19435,9 +19985,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prohibit privileged users from using privileged accounts, while performing non-security functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prohibit privileged users from using privileged accounts, while performing non-security functions. \n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -19507,7 +20057,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -19615,8 +20166,9 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ - "ISM-1175" + "apac-aus-ism-2026-march": [ + "ISM-1175", + "ISM-1883" ], "americas-can-itsp-10-171-2025": [ "03.01.06.B" @@ -19715,7 +20267,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -19772,7 +20325,8 @@ ], "general-nist-800-171a-r3": [ "A.03.01.06.ODP[01]", - "A.03.01.06.a" + "A.03.01.06.a", + "A.03.01.07.a" ], "general-owasp-top-10-2025": [ "A01:2025" @@ -19824,11 +20378,18 @@ "emea-eu-nis2-annex-2024": [ "11.3.2(b)" ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.4", + "op.acc.5" + ], "apac-aus-essential-8-2024": [ "ML1-P4", "ML2-P4", "ML3-P4" ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.06.A", "03.01.07.A" @@ -19855,7 +20416,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM revokes user access rights following changes in personnel roles and duties, if no longer necessary or permitted.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to audit the execution of privileged functions.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to audit the execution of privileged functions. ", "4": "Identification & Authentication (IAC) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -19925,7 +20486,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -19965,6 +20527,9 @@ "general-nist-800-171-r3": [ "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b" + ], "general-owasp-top-10-2025": [ "A01:2025" ], @@ -20032,7 +20597,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -20102,7 +20667,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -20190,8 +20756,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2216" ], - "apac-aus-ism-2024-june": [ - "ISM-1592" + "apac-aus-ism-2026-march": [ + "ISM-1592", + "ISM-2048" ], "americas-can-itsp-10-171-2025": [ "03.01.07.A" @@ -20202,8 +20769,8 @@ "control_id": "IAC-21.6", "title": "Network Access to Privileged Commands", "family": "IAC", - "description": "Mechanisms exist to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs.", - "scf_question": "Does the organization authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs?", + "description": "Mechanisms exist to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive and/or regulated data is stored, transmitted and/or processed only for compelling operational needs.", + "scf_question": "Does the organization authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive and/or regulated data is stored, transmitted and/or processed only for compelling operational needs?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -20216,7 +20783,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to authorize remote access to perform privileged commands on critical Technology Assets, Applications and/or Services (TAAS) or where sensitive/regulated data is stored, transmitted and/or processed only for compelling operational needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -20284,7 +20851,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -20334,7 +20902,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically prevent applications from executing at higher privilege levels than the user's privileges.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically prevent applications from executing at higher privilege levels than the user's privileges. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -20399,7 +20967,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -20519,18 +21088,19 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { "general-cis-csc-8-1": [ - "4.1" + "4.10" ], "general-cis-csc-8-1-ig2": [ - "4.1" + "4.10" ], "general-cis-csc-8-1-ig3": [ - "4.1" + "4.10" ], "general-govramp": [ "AC-07" @@ -20567,7 +21137,7 @@ "general-iso-27018-2025": [ "8.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021", "T1021.001", "T1021.004", @@ -20658,6 +21228,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AC-07" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(a)(1)" + ], "usa-federal-irs-1075-2021": [ "AC-7" ], @@ -20690,12 +21263,13 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(d)" ], - "emea-isr-cmo-1-0": [ - "4.14" - ], "emea-sau-cgiot-2024": [ "2-2-2" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" + ], "emea-gbr-def-stan-05-138-2024": [ "2214" ], @@ -20708,13 +21282,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2214" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1403" ], - "apac-nzl-ism-3-9": [ - "16.1.46.C.01", - "16.1.46.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.08.A", "03.01.08.B" @@ -20741,7 +21311,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit the number of concurrent sessions for each system account.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to limit the number of concurrent sessions for each system account. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -20809,7 +21379,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -20831,7 +21402,7 @@ "general-iec-62443-4-2-2019": [ "CR 2.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.002", "T1185", @@ -20852,17 +21423,22 @@ "general-nist-800-82-r3-high": [ "AC-10" ], + "general-nist-800-172-r3": [ + "03.01.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.04E", + "A.03.01.04E.ODP[01]", + "A.03.01.04E.ODP[02]" + ], "usa-federal-gsa-fedramp-5-high": [ "AC-10" ], "usa-federal-cms-marse-2-0": [ "AC-10" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "4.15" + "americas-arg-ppd-2018": [ + "B.2.5-DS-1" ] } }, @@ -20956,7 +21532,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -21001,7 +21578,7 @@ "CR 2.5(a)", "CR 2.5(b)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1563.002" ], @@ -21092,18 +21669,6 @@ "AC-02 (05)", "AC-11" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "4.16" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], "emea-gbr-def-stan-05-138-2024": [ "2408" ], @@ -21116,13 +21681,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2408" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0428" ], - "apac-nzl-ism-3-9": [ - "16.1.45.C.01", - "16.1.45.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.10.A", "03.01.10.B" @@ -21149,7 +21710,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement pattern-hiding displays to conceal information previously visible on the display during the session lock.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement pattern-hiding displays to conceal information previously visible on the display during the session lock. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -21219,7 +21780,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -21283,9 +21845,6 @@ "usa-federal-cms-marse-2-0": [ "AC-11(1)" ], - "emea-sau-sacs-002-2022": [ - "TPC-2" - ], "americas-can-itsp-10-171-2025": [ "03.01.10.C" ] @@ -21311,7 +21870,7 @@ "0": "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.", "1": "Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.\n▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -21380,7 +21939,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -21399,7 +21959,7 @@ "general-iec-62443-3-3-2013": [ "SR 2.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1072", "T1185", @@ -21488,10 +22048,10 @@ "AC-12" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(a)(2)(iii)" + "§ 164.312(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "AC-12" @@ -21509,19 +22069,14 @@ "emea-eu-nis2-annex-2024": [ "11.6.2(e)" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-4" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0853" ], "apac-nzl-ism-3-9": [ "16.1.44.C.01" ], "americas-can-itsp-10-171-2025": [ + "03.01.01.H", "03.01.11", "03.07.05.C" ] @@ -21545,9 +22100,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", - "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a logout capability and display an explicit logout message to users indicating the reliable termination of the session.", + "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to provide a logout capability and display an explicit logout message to users indicating the reliable termination of the session. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -21613,7 +22168,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -21655,7 +22211,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to identify and document the supporting rationale for specific user actions that can be performed on a system without identification or authentication.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -21723,7 +22279,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -21742,7 +22299,7 @@ "general-govramp-high": [ "AC-14" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137.002" ], "general-nist-800-53-r4": [ @@ -21821,7 +22378,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to implement a reference monitor that is tamperproof, always-invoked, small enough to be subject to analysis / testing and the completeness of which can be assured.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -21889,7 +22446,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -21927,7 +22485,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to verify the identity of a user before issuing authenticators or modifying access permissions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22001,11 +22559,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.002", "T1078.003", @@ -22030,8 +22589,20 @@ "IA-12" ], "general-nist-800-171-r3": [ - "03.05.12.a", - "03.05.12.c" + "03.05.12.a" + ], + "general-nist-800-171a-r3": [ + "A.03.05.12.a" + ], + "general-nist-800-172-r3": [ + "03.05.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.05.06E.a", + "DS-A.03.05.06E.b", + "DS-A.03.05.06E.c[01]", + "DS-A.03.05.06E.c[02]", + "DS-A.03.05.06E.c[03]" ], "general-nist-csf-2-0": [ "PR.AA-02" @@ -22070,20 +22641,22 @@ "IA-12" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12" ], + "emea-deu-c5-2020": [ + "IDM-08-BP1" + ], "apac-jpn-ismap": [ "7.1.1.4" ], "americas-can-itsp-10-171-2025": [ - "03.05.12.A", - "03.05.12.C" + "03.05.12.A" ] } }, @@ -22107,7 +22680,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to ensure management approvals are required for new accounts or changes in permissions to existing accounts.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22196,7 +22769,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -22241,8 +22815,9 @@ "03.01.01.b", "03.05.05.a" ], - "general-scf-dpmp-2025": [ - "7.1" + "general-nist-800-171a-r3": [ + "A.03.01.01.b[02]", + "A.03.05.05.a" ], "general-tisax-6-0-3": [ "4.2.1" @@ -22252,10 +22827,10 @@ "ACCESS-2g" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(3)(ii)(A)" + "§ 164.308(a)(3)(ii)(A)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-1)" @@ -22270,15 +22845,26 @@ "11.2.2(c)" ], "emea-deu-c5-2020": [ - "IDM-01", - "IDM-02" + "IDM-01-BP1", + "IDM-01-BP6", + "IDM-03-BP3", + "IDM-03-BP4", + "IDM-06", + "IDM-09", + "BEI-09" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0405" ], "apac-jpn-ismap": [ "9.2.2.1" ], + "americas-arg-ppd-2018": [ + "B.2.3-5" + ], + "americas-bmu-mba-coc-2020": [ + "6.6" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.B", "03.05.05.A" @@ -22303,8 +22889,8 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM proactively governs account management of individual, group, system, application, guest and temporary accounts.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.\n▪ IAM collects, validates and verifies identity evidence of a user.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require evidence of individual identification to be presented to the registration authority.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." @@ -22388,7 +22974,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -22420,10 +23007,10 @@ "IA-12(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-2)" @@ -22448,7 +23035,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that the presented identity evidence be validated and verified through organizational-defined methods of validation and verification.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22533,7 +23120,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -22565,10 +23153,10 @@ "IA-12(03)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(d)" + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "IA-12(CE-3)" @@ -22593,7 +23181,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that the validation and verification of identity evidence be conducted in person before a designated registration authority.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22678,7 +23266,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -22732,7 +23321,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to require that a notice of proofing be delivered through an out-of-band channel to verify the user's address (physical or digital).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22817,7 +23406,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -22868,7 +23458,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Attribute-Based Access Control (ABAC) for policy-driven, dynamic authorizations that supports the secure sharing of information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -22915,7 +23505,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -22925,6 +23516,15 @@ "general-mpa-csbp-5-3-1": [ "TS-1.8" ], + "general-nist-800-172-r3": [ + "03.01.09E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.09E.a[01]", + "DS-A.03.01.09E.a[02]", + "DS-A.03.01.09E.b", + "A.03.01.09E.ODP[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "1.2", "1.2.1", @@ -22943,6 +23543,12 @@ "2.3.3", "2.3.5", "2.4.2" + ], + "apac-mys-bnm-rmit-2025": [ + "10.54" + ], + "apac-nzl-ism-3-9": [ + "16.1.31.C.06" ] } }, @@ -22951,7 +23557,7 @@ "title": "Real-Time Access Decisions", "family": "IAC", "description": "Automated mechanisms exist to utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources.", - "scf_question": "Does the organization utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources?", + "scf_question": "Does the organization use automated mechanisms to utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources?", "relative_weight": 3, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -22964,7 +23570,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.\n▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to automatically utilize Machine Learning (ML) to make real-time access decisions based on advanced network analytics that leverages enterprise-wide data sources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23009,7 +23615,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -23023,8 +23630,8 @@ "control_id": "IAC-29.2", "title": "Access Profile Rules", "family": "IAC", - "description": "Mechanisms exist to develop access profile rules for sensitive/regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes.", - "scf_question": "Does the organization develop access profile rules for sensitive/regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes?", + "description": "Mechanisms exist to develop access profile rules for sensitive and/or regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes.", + "scf_question": "Does the organization develop access profile rules for sensitive and/or regulated Technology Assets, Applications, Services and/or Data (TAASD) access based on User, Data, Network, Environment & Device attributes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -23084,7 +23691,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Identification & Authentication", "crosswalks": { @@ -23113,7 +23721,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", "3": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are well-documented and kept current by process owners.\n▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).\n▪ 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 IAC 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).\n▪ An implemented and operational capability exists to enforce Mutual Authentication (MA) where both sides of a communications channel verify the identity of the other party through certificate exchange.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -23139,9 +23747,9 @@ "MT-2", "MT-8", "MT-9", - "MT-14" + "MT-14", + "MT-28" ], - "errata": "- new control (IEC 62443-2-1)", "family_name": "Identification & Authentication", "crosswalks": { "general-iec-62443-2-1-2024": [ diff --git a/docs/api/families/IAO.json b/docs/api/families/IAO.json index 411658e0..3cab4195 100644 --- a/docs/api/families/IAO.json +++ b/docs/api/families/IAO.json @@ -25,7 +25,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel coordinate IAP activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience assessment and authorization controls.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience assessment and authorization controls. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -121,9 +121,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -247,12 +247,12 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-nist-csf-2-0": [ "ID.RA-01" ], - "general-scf-dpmp-2025": [ - "7.11" - ], "general-sparta": [ "CM0089" ], @@ -331,50 +331,34 @@ "emea-eu-ai-act-2024": [ "Article 9.8" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)" + "3.4.6.42", + "3.4.6.43", + "3.4.6.43(a)", + "3.4.6.43(b)", + "3.4.6.45", + "3.6.2.69", + "3.6.2.70" ], "emea-eu-nis2-annex-2024": [ "6.5.1", "6.5.2(a)", "6.5.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5", - "17.1", - "17.16", - "17.18" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" + "emea-sau-cscc-1-2019": [ + "1-3-1", + "1-3-2", + "2-13-4" ], "emea-sau-cgiot-2024": [ "1-5-2", @@ -382,15 +366,21 @@ "4-1-5", "4-2-3" ], + "emea-sau-ecc-1-2018": [ + "1-6-2" + ], "emea-sau-otcc-1-2022": [ - "1-4-1-2" + "1-5-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-51" + "emea-esp-decree-311-2022": [ + "Article 13(2)(c)", + "Article 21(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" ], - "emea-zaf-popia-2013": [ - "19", - "60" + "emea-gbr-cap-1850-2020": [ + "A2" ], "emea-gbr-def-stan-05-138-2024": [ "1205" @@ -401,7 +391,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1205" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0027", "ISM-0280", "ISM-1525" @@ -410,7 +400,14 @@ "ID.AM.S4", "PR.AA.S16" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.6", + "10.8", + "10.15", + "16.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP68", "HML67" ], @@ -441,19 +438,16 @@ "4.4.12.C.05" ], "apac-sgp-mas-trm-2021": [ - "5.1.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.6.1", + "4.5.1", "5.6.2", - "5.6.3", "5.7.1", - "5.7.2" + "6.1.6", + "6.1.7", + "6.4.6", + "6.5.3" ], "americas-bmu-mba-coc-2020": [ - "5.14" + "6.15" ], "americas-can-osfi-b13-2022": [ "2.4.4" @@ -570,7 +564,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -599,6 +594,9 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-swift-cscf-2025": [ "7.3A" ], @@ -618,25 +616,54 @@ "11.10(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.F.2.b" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-annex-2024": [ "6.5.2(c)" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.3" + ], + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "2-11-3-1" + ], + "emea-gbr-cap-1850-2020": [ + "A2" + ], + "apac-mys-bnm-rmit-2025": [ + "10.8", + "10.9" + ], "apac-nzl-ism-3-9": [ "5.8.61.C.01", "5.8.61.C.02", - "5.8.61.C.03" + "5.8.61.C.03", + "20.1.21.C.02", + "23.5.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2" + "4.5.1", + "5.6.2", + "6.1.6", + "6.4.6" ], "americas-can-osfi-b13-2022": [ "2.4.4" @@ -758,9 +785,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -848,7 +875,7 @@ "general-iso-42001-2023": [ "A.6.2.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1190", "T1195", "T1195.001", @@ -909,6 +936,9 @@ "general-nist-800-171-r3": [ "03.12.01" ], + "general-nist-800-171a-r3": [ + "A.03.12.01" + ], "general-nist-csf-2-0": [ "ID.RA-01", "ID.IM-01", @@ -951,11 +981,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "CA-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)", + "101.650(e)(1)(i)", + "101.650(e)(1)(ii)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(8)" + "§ 164.308(a)(8)" ], "usa-federal-irs-1075-2021": [ "CA-2" @@ -995,19 +1030,15 @@ "emea-eu-ai-act-2024": [ "Article 9.8" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 32(1)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.4.6(41)", - "3.4.6(42)", - "3.4.6(43)", - "3.4.6(43)(a)", - "3.4.6(43)(b)", - "3.4.6(44)", - "3.4.6(45)", - "3.4.6(46)", - "3.4.6(47)", - "3.4.6(48)", - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" ], "emea-eu-nis2-annex-2024": [ "6.5.2(a)", @@ -1016,16 +1047,10 @@ "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5", - "17.2", - "17.16", - "17.18" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2" + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "1-3-1-2", + "2-13-4" ], "emea-sau-cgiot-2024": [ "2-15-2", @@ -1033,6 +1058,20 @@ "4-2-3", "4-2-4" ], + "emea-sau-ecc-1-2018": [ + "1-6-2-1", + "1-6-2-2" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3", + "mp.sw.2" + ], + "emea-gbr-cap-1850-2020": [ + "A2" + ], "emea-gbr-def-stan-05-138-2024": [ "1205" ], @@ -1042,8 +1081,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1205" ], - "apac-aus-ism-2024-june": [ - "ISM-0100" + "apac-aus-ism-2026-march": [ + "ISM-0100", + "ISM-1967", + "ISM-1971", + "ISM-1972" + ], + "apac-aus-ps-cps-234-2019": [ + "22", + "28" ], "apac-chn-cybersecurity-law-2017": [ "Article 35" @@ -1062,7 +1108,14 @@ "14.2.9.3", "14.2.9.4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.6", + "10.8", + "10.9", + "16.4" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP68", "HML67" ], @@ -1074,18 +1127,30 @@ "4.3.20.C.01", "4.3.20.C.02", "4.3.20.C.03", - "6.3.8.C.01" + "6.3.8.C.01", + "11.1.19.C.01", + "16.1.30.C.01", + "16.7.41.C.01", + "20.1.21.C.01", + "20.1.21.C.07", + "20.1.22.C.03", + "20.1.23.C.01", + "23.5.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2" + "4.5.1", + "5.6.2", + "6.1.6" ], "americas-bmu-mba-coc-2020": [ - "5.14" + "6.15-BP2" ], "americas-can-osfi-b13-2022": [ "2.4.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.4" + ], "americas-can-itsp-10-171-2025": [ "03.12.01" ] @@ -1111,7 +1176,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1194,9 +1259,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -1241,6 +1306,12 @@ "general-nist-800-171-r2": [ "NFO - CA-2(1)" ], + "general-nist-800-172-r3": [ + "03.12.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.02E" + ], "usa-federal-fbi-cjis-6-0": [ "CA-2(1)" ], @@ -1263,9 +1334,16 @@ "CA-2(1)", "CA-2(1)-IS" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "apac-mys-bnm-rmit-2025": [ + "10.8" ], "apac-nzl-ism-3-9": [ "4.3.16.C.01" @@ -1276,8 +1354,8 @@ "control_id": "IAO-02.2", "title": "Specialized Assessments", "family": "IAO", - "description": "Mechanisms exist to conduct specialized assessments for: \n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities; \n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management; \n(8) Malicious code; \n(9) Insider threats;\n(10) Performance/load testing; and/or\n(11) Artificial Intelligence and Autonomous Technologies (AAT).", - "scf_question": "Does the organization conduct specialized assessments for: \n (1) Statutory, regulatory and contractual compliance obligations;\n (2) Monitoring capabilities; \n (3) Mobile devices;\n (4) Databases;\n (5) Application security;\n (6) Embedded technologies (e.g., IoT, OT, etc.);\n (7) Vulnerability management; \n (8) Malicious code; \n (9) Insider threats;\n (10) Performance/load testing; and/or\n (11) Artificial Intelligence and Autonomous Technologies (AAT) testing?", + "description": "Mechanisms exist to conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.", + "scf_question": "Does the organization conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements?", "relative_weight": 9, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -1292,7 +1370,7 @@ "0": "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.", "1": "Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct specialized assessments for: \n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities; \n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management; \n(8) Malicious code; \n(9) Insider threats;\n(10) Performance/load testing; and/or\n(11) Artificial Intelligence and Autonomous Technologies (AAT).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct specialized assessments for:\n(1) Statutory, regulatory and contractual compliance obligations;\n(2) Monitoring capabilities;\n(3) Mobile devices;\n(4) Databases;\n(5) Application security;\n(6) Embedded technologies (e.g., IoT, OT, etc.);\n(7) Vulnerability management;\n(8) Malicious code;\n(9) Insider threats;\n(10) Performance/load testing;\n(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or\n(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1376,8 +1454,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -1484,29 +1564,75 @@ "usa-federal-irs-1075-2021": [ "SA-11(CE-5)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 13(3)", + "Article 32(1)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)", + "Annex I, Part II(3)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.4.6.47", + "3.6.2.69", + "3.6.2.70", + "3.6.2.71" ], "emea-deu-bsrit-2017": [ "7.11" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" + "emea-sau-cscc-1-2019": [ + "1-3-1-1", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-2-1", + "1-6-2-2" ], - "apac-aus-ism-2024-june": [ + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3", + "2-10-1-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.b.1", + "3.3.7.4.b.2", + "3.3.7.4.b.3", + "3.3.7.4.b.4" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3", + "mp.sw.2" + ], + "apac-aus-ism-2026-march": [ "ISM-0100", "ISM-1137", - "ISM-1570" + "ISM-1570", + "ISM-2019" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.9", + "10.15" ], "apac-nzl-ism-3-9": [ "4.3.20.C.01", "4.3.20.C.02", - "4.3.20.C.03" + "4.3.20.C.03", + "20.2.13.C.01", + "20.2.13.C.02" ], "apac-sgp-mas-trm-2021": [ - "5.7.4" + "5.3.3", + "5.6.3", + "6.1.6", + "6.4.6" ] } }, @@ -1528,9 +1654,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to accept and respond to the results of external assessments that are performed by impartial, external organizations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to accept and respond to the results of external assessments that are performed by impartial, external organizations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1613,9 +1739,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Information Assurance", "crosswalks": { "general-govramp": [ @@ -1648,11 +1774,7 @@ "usa-federal-gsa-fedramp-5-high": [ "CA-02(03)" ], - "emea-isr-cmo-1-0": [ - "17.2", - "17.16" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0100" ], "apac-nzl-ism-3-9": [ @@ -1686,7 +1808,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1774,7 +1896,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -1797,21 +1920,35 @@ "ID.IM-01", "ID.IM-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)(iii)" + ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-annex-2024": [ "6.5.2(c)" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "apac-aus-ism-2026-march": [ "ISM-1563" ], + "apac-mys-bnm-rmit-2025": [ + "10.8" + ], "apac-nzl-ism-3-9": [ "4.2.11.C.01", "4.2.12.C.01", "4.3.21.C.01", "4.5.17.C.01", "6.3.8.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.6" ] } }, @@ -1835,7 +1972,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ 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).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate authoritative documentation (e.g., System Security Plan (SSP)) that:\n(1) Identifies key architectural and implementation information on in-scope Technology Assets, Applications and/or Services (TAAS);\n(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\n(3) Provides a historical record of applied security controls, including changes.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1908,9 +2045,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -2018,6 +2155,8 @@ "3.12.4" ], "general-nist-800-171-r3": [ + "03.01.16.a", + "03.04.11.a", "03.04.11.b", "03.15.02.a", "03.15.02.a.01", @@ -2041,6 +2180,7 @@ "3.12.4[h]" ], "general-nist-800-171a-r3": [ + "A.03.01.16.a[01]", "A.03.04.11.a[02]", "A.03.04.11.a[03]", "A.03.04.11.b[01]", @@ -2055,14 +2195,50 @@ "A.03.15.02.a.07", "A.03.15.02.a.08", "A.03.15.02.b[01]", - "A.03.15.02.b[02]", - "A.03.15.02.c" - ], - "general-nist-800-172": [ - "3.11.4e" - ], - "general-scf-dpmp-2025": [ - "5.13" + "A.03.15.02.b[02]" + ], + "general-nist-800-172-r3": [ + "03.01.04E", + "03.01.06E", + "03.13.11E", + "03.13.14E", + "03.13.16E", + "03.14.08E", + "03.14.10E", + "03.14.14E", + "03.14.15E", + "03.14.16E", + "03.15.01E", + "03.15.02E", + "03.15.03E", + "03.16.01E", + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.04E.ODP[02]", + "DS-A.03.01.06E", + "A.03.13.11E.ODP[01]", + "A.03.13.14E.ODP[01]", + "A.03.13.16E.ODP[03]", + "A.03.14.08E.ODP[01]", + "A.03.14.08E.ODP[03]", + "A.03.14.08E.ODP[05]", + "A.03.14.08E.ODP[07]", + "A.03.14.08E.ODP[11]", + "A.03.14.10E.ODP[02]", + "A.03.14.14E.ODP[01]", + "A.03.14.15E.ODP[01]", + "A.03.14.16E.ODP[01]", + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.03", + "DS-A.03.15.01E.b", + "DS-A.03.15.01E.c", + "DS-A.03.15.02E.b", + "A.03.15.02E.ODP[01]", + "A.03.15.03E.ODP[01]", + "A.03.15.03E.ODP[02]", + "A.03.16.01E.ODP[02]", + "A.03.17.02E.ODP[01]" ], "usa-federal-fbi-cjis-6-0": [ "PL-2" @@ -2088,6 +2264,27 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PL-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(5)", + "101.630(a)", + "101.630(c)", + "101.630(c)(1)", + "101.630(c)(2)", + "101.630(c)(3)", + "101.630(c)(4)", + "101.630(c)(5)", + "101.630(c)(6)", + "101.630(c)(7)", + "101.630(c)(8)", + "101.630(c)(9)", + "101.630(c)(10)", + "101.630(c)(11)", + "101.630(c)(12)", + "101.630(c)(13)", + "101.630(c)(14)", + "101.650(c)", + "101.650(e)(1)(v)" + ], "usa-federal-irs-1075-2021": [ "2.E.4.3", "2.E.4.3-1.1", @@ -2151,8 +2348,40 @@ "emea-eu-ai-act-2024": [ "Article 11.1" ], - "emea-qat-pdppl-2020": [ - "11.1" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)", + "Article 13(3)", + "Article 13(7)", + "Article 19(2)(b)", + "Article 31(1)", + "Article 31(2)", + "Article 31(3)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], + "emea-deu-bsrit-2017": [ + "3.6" + ], + "emea-deu-c5-2020": [ + "UP-01-BP2", + "UP-01-BP3", + "UP-01-BP5" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "emea-esp-decree-311-2022": [ + "Article 12(1)(e)", + "Article 15(2)" + ], + "emea-gbr-cap-1850-2020": [ + "A2", + "A3", + "B1", + "B4" ], "emea-gbr-def-stan-05-138-2024": [ "2301" @@ -2163,9 +2392,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2301" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0041", - "ISM-0432" + "ISM-0432", + "ISM-0912", + "ISM-1912", + "ISM-2005" ], "apac-jpn-ismap": [ "4.4.4", @@ -2187,7 +2419,16 @@ "5.4.5.C.02", "5.4.5.C.03" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.3(a)" + ], + "americas-arg-ppd-2018": [ + "B.2.1-1", + "E.1.1-3" + ], "americas-can-itsp-10-171-2025": [ + "03.01.16.A", + "03.04.11.A", "03.04.11.B", "03.15.02.A", "03.15.02.A.01", @@ -2220,9 +2461,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to plan and coordinate Information Assurance Program (IAP) activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to plan and coordinate Information Assurance Program (IAP) activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2306,7 +2547,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -2406,8 +2648,8 @@ "control_id": "IAO-03.2", "title": "Adequate Security for Sensitive / Regulated Data In Support of Contracts", "family": "IAO", - "description": "Mechanisms exist to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", - "scf_question": "Does the organization protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract?", + "description": "Mechanisms exist to protect sensitive and/or regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", + "scf_question": "Does the organization protect sensitive and/or regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -2422,9 +2664,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to protect sensitive/regulated data that is collected, developed, received, transmitted, used or stored in support of the performance of a contract. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2508,7 +2750,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -2544,10 +2787,10 @@ "CAL2.-3.12.4" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(3)" + "§ 164.308(b)(3)" ], "usa-state-co-privacy-act-2021": [ "6-1-1305(3)(b)" @@ -2560,21 +2803,26 @@ "SA-04-SID", "SA-09-SID" ], - "emea-deu-c5-2020": [ - "HR-06", - "PI-02" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" ], - "emea-isr-cmo-1-0": [ - "16.5" + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "emea-deu-c5-2020": [ + "BEI-02", + "BEI-02-BP1", + "BEI-02-BP2", + "BEI-02-BP3", + "BEI-02-BP4" ], - "emea-srb-act-9-2018": [ - "5", - "11" + "emea-gbr-cap-1850-2020": [ + "A2", + "B1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0072", "ISM-1451", "ISM-1571", @@ -2583,9 +2831,6 @@ "ISM-1574", "ISM-1575" ], - "apac-jpn-ppi-2020": [ - "22" - ], "apac-jpn-ismap": [ "13.2.2", "13.2.2.2", @@ -2601,20 +2846,8 @@ "apac-nzl-ism-3-9": [ "2.2.5.C.02" ], - "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" - ], - "apac-sgp-mas-trm-2021": [ - "5.4.3" - ], - "amaericas-can-osfi-self-assessment": [ - "4.26", - "4.28" + "americas-bhs-dpa-2003": [ + "V.51(1)(a)" ] } }, @@ -2623,7 +2856,7 @@ "title": "Threat Analysis & Flaw Remediation During Development", "family": "IAO", "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.", - "scf_question": "Does the organization require system developers and integrators to create and execute a Security Testing and Evaluation (ST&E) plan to identify and remediate flaws during development?", + "scf_question": "Does the organization 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?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2636,7 +2869,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2721,7 +2954,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -2875,9 +3109,39 @@ "SA-11(CE-5).a", "SA-11(CE-5).b" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(6)", + "Article 13(21)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(2)", + "Annex I, Part II(3)" + ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], + "emea-sau-cscc-1-2019": [ + "1-3-2-1" + ], + "emea-sau-ecc-1-2018": [ + "1-5-3" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.10" + ], "apac-nzl-ism-3-9": [ "6.2.5.C.01", "6.2.6.C.01" @@ -2885,8 +3149,8 @@ "apac-sgp-mas-trm-2021": [ "5.7.5" ], - "amaericas-can-osfi-self-assessment": [ - "2.7" + "americas-can-osfi-self-assessment-2": [ + "2.4.4" ] } }, @@ -2910,7 +3174,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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:\n(1) Deficiency tracking number;\n(2) Applicable security, compliance and/or resilience control;\n(3) Description of the deficiency(ies);\n(4) Risk associated with the deficiency(ies);\n(5) Source deficiency identification/detection;\n(6) Temporary compensating controls, if applicable;\n(7) Point of Contact (POC) (e.g., asset/process owner);\n(8) Resources required to conduct remediation actions;\n(9) Planned remedial actions to the deficiency(ies);\n(10) Proposed remediation timeline; and\n(11) Disposition statement (e.g., closeout summary).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2982,9 +3246,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -3136,20 +3400,20 @@ "3.12.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.04.11.b[01]", + "A.03.04.11.b[02]", "A.03.12.02.a.01", "A.03.12.02.a.02", "A.03.12.02.b.01", "A.03.12.02.b.02", - "A.03.12.02.b.03" + "A.03.12.02.b.03", + "A.03.14.01.a[01]" ], "general-nist-csf-2-0": [ "ID.RA-01", "ID.IM-01", "ID.IM-02" ], - "general-scf-dpmp-2025": [ - "9.3" - ], "general-tisax-6-0-3": [ "1.5.2" ], @@ -3192,6 +3456,9 @@ "CA-05", "PM-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(1)(iv)" + ], "usa-federal-irs-1075-2021": [ "2.E.5", "2.E.5-1", @@ -3233,8 +3500,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-05" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(d)" + "3.3.1.13(d)", + "3.3.6.27", + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], "emea-eu-nis2-2022": [ "Article 21.4" @@ -3242,13 +3516,25 @@ "emea-eu-nis2-annex-2024": [ "6.5.2(d)" ], + "emea-deu-bsrit-2017": [ + "3.8" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 4" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], "emea-sau-otcc-1-2022": [ - "1-3-1-6" + "1-3-1-7" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.4-2.2" ], "emea-uae-niaf-2023": [ "3.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1564" ], "apac-jpn-ismap": [ @@ -3256,16 +3542,13 @@ "4.7.1.4", "4.7.1.7" ], + "apac-mys-bnm-rmit-2025": [ + "10.8" + ], "apac-nzl-ism-3-9": [ "4.2.12.C.01", "6.3.8.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.5.2" - ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-itsp-10-171-2025": [ "03.04.11.B", "03.12.02.A", @@ -3342,9 +3625,9 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-nist-800-53-r4": [ @@ -3379,7 +3662,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with IAO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.\n▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with IAO domain capabilities are well-documented and kept current by process owners.\n▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software, risk assessment software, etc.).\n▪ 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).\n▪ 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.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3468,9 +3751,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Information Assurance", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -3595,13 +3878,34 @@ "CA-02", "CM-04 (02)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5" + "emea-deu-bsrit-2017": [ + "7.11" + ], + "emea-sau-cscc-1-2019": [ + "1-3-1-2", + "2-13-4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-3-5" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-72", + "VII.B.TPC-73" + ], + "emea-gbr-cap-1850-2020": [ + "A2" ], "emea-gbr-def-stan-05-138-2024": [ "1205" @@ -3611,6 +3915,13 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "1205" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8" + ], + "apac-sgp-mas-trm-2021": [ + "5.7.6" ] } }, @@ -3720,7 +4031,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Information Assurance", "crosswalks": { @@ -3802,9 +4114,6 @@ "general-nist-800-161-r1-level-3": [ "CA-6" ], - "general-scf-dpmp-2025": [ - "7.11" - ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.Q" ], @@ -3860,21 +4169,44 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-06" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(70)", - "3.6.2(71)" + "3.4.6.42", + "3.6.2.69", + "3.6.2.70" ], - "emea-isr-cmo-1-0": [ - "10.6", - "16.5" + "emea-deu-bsrit-2017": [ + "7.11" + ], + "emea-sau-cscc-1-2019": [ + "2-13-4" + ], + "emea-sau-otcc-1-2022": [ + "1-4-1-2", + "1-5-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-51" + "VII.B.TPC-72", + "VII.B.TPC-73" + ], + "emea-esp-decree-311-2022": [ + "Article 21(1)" ], - "apac-aus-ism-2024-june": [ + "emea-gbr-cap-1850-2020": [ + "A2" + ], + "apac-aus-ism-2026-march": [ "ISM-0027", "ISM-0293", - "ISM-1525" + "ISM-1525", + "ISM-1968" + ], + "apac-mys-bnm-rmit-2025": [ + "10.6", + "10.8", + "10.15" ], "apac-nzl-ism-3-9": [ "2.2.5.C.01", @@ -3882,8 +4214,15 @@ "4.5.18.C.01", "4.5.18.C.02", "4.5.18.C.03", + "20.1.21.C.04", + "20.1.22.C.01", + "20.1.22.C.03", + "20.1.22.C.05", "23.2.16.C.03", "23.2.16.C.04" + ], + "apac-sgp-mas-trm-2021": [ + "5.7.6" ] } } diff --git a/docs/api/families/IRO.json b/docs/api/families/IRO.json index fdf661c1..2eb5d1d4 100644 --- a/docs/api/families/IRO.json +++ b/docs/api/families/IRO.json @@ -122,7 +122,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -154,7 +155,7 @@ "4.1.3" ], "general-cis-csc-8-1": [ - "17.0", + "17", "17.5" ], "general-cis-csc-8-1-ig2": [ @@ -287,6 +288,12 @@ "general-nist-800-171a-r3": [ "A.03.06.01[01]" ], + "general-nist-800-172-r3": [ + "03.11.09E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.09E.ODP[02]" + ], "general-nist-csf-2-0": [ "GV.SC-08", "DE.AE", @@ -310,9 +317,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-shared-assessments-sig-2025": [ "J.4" ], @@ -379,14 +383,14 @@ "314.4(h)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(6)(i)", - "164.308(a)(7)(i)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(6)(i)", + "§ 164.308(a)(7)(i)" ], "usa-federal-irs-1075-2021": [ "1.8.4", @@ -440,18 +444,8 @@ "IR-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60" ], "emea-eu-dora-2023": [ "Article 9.4(b)", @@ -478,55 +472,42 @@ "3.5.1", "4.3.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" + "emea-eu-psd2-2015": [ + "95(1)" ], "emea-deu-bsrit-2017": [ "4.7" ], "emea-deu-c5-2020": [ - "SIM-01" + "UP-01-BP4", + "SIM-01", + "SIM-07" ], - "emea-isr-cmo-1-0": [ - "24.1" + "emea-qat-pdppl-2020": [ + "3.11.5" ], "emea-sau-ecc-1-2018": [ "2-13-1", "2-13-2", - "2-13-3", - "2-13-3-2", - "2-13-4" + "2-13-3-1" ], "emea-sau-otcc-1-2022": [ - "2-12", "2-12-1", "2-12-2" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88", - "TPC-89" + "VII.A.TPC-23" ], "emea-sau-sama-csf-1-2017": [ - "3.3.15" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.3", - "22" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1" + "3.3.15.1" ], "emea-esp-decree-311-2022": [ - "25.1" + "Article 8(4)", + "Article 12(6)(m)", + "Article 25(1)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.7 [OP.EXP.7]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7" ], "emea-uae-niaf-2023": [ "3.3", @@ -535,6 +516,9 @@ "emea-gbr-caf-4-0": [ "D1" ], + "emea-gbr-cap-1850-2020": [ + "D1" + ], "emea-gbr-def-stan-05-138-2024": [ "3105", "4104" @@ -550,18 +534,17 @@ "3105", "4104" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0137", "ISM-0576", "ISM-1609", "ISM-1618" ], "apac-aus-ps-cps-230-2023": [ - "32" + "16(d)" ], "apac-aus-ps-cps-234-2019": [ - "23", - "24" + "23" ], "apac-ind-sebi-2024": [ "RS.MA.S1" @@ -580,6 +563,11 @@ "16.1.1.11.P", "16.1.1.12.P" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.2", + "11.12" + ], "apac-nzl-ism-3-9": [ "7.1.7.C.01", "7.1.7.C.02", @@ -588,37 +576,28 @@ ], "apac-sgp-mas-trm-2021": [ "7.7.1", - "7.7.2", - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "7.7.4", - "7.7.5", - "7.7.6", - "7.7.7" + "7.7.2" + ], + "americas-arg-ppd-2018": [ + "E.1.2-11", + "G" ], "americas-bmu-mba-coc-2020": [ - "6.1", + "5.3-BP3", + "6.1-BP4", "6.3", "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], "americas-can-osfi-b13-2022": [ "2.7", "2.7.2", "3.3", "3.4.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.1", + "3.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.01" ] @@ -644,7 +623,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.\n▪ IT and/or cybersecurity personnel operate facilitate basic forensic investigations in the event of a suspected or confirmed security incident.\n▪ The IRP contains eDiscovery processes to support Federal Rules of Civil Procedure (FRCP) requirements for eDiscovery practices.\n▪ IT personnel support incident response operations by provisioning and deprovisioning incident responders with temporary emergency accounts.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to cover:\n(1) Preparation;\n(2) Automated event detection or manual incident report intake;\n(3) Analysis;\n(4) Containment;\n(5) Eradication; and\n(6) Recovery.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -735,7 +714,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -772,7 +752,7 @@ ], "general-cis-csc-8-1": [ "2.3", - "17.0", + "17", "17.1", "17.3", "17.4", @@ -929,7 +909,8 @@ "03.06.02.a", "03.06.02.b", "03.06.02.c", - "03.06.02.d" + "03.06.02.d", + "03.06.05.b" ], "general-nist-800-171a": [ "3.6.1[a]", @@ -947,12 +928,24 @@ "3.6.2[f]" ], "general-nist-800-171a-r3": [ + "A.03.03.04.b", "A.03.06.01[02]", "A.03.06.01[03]", "A.03.06.01[04]", "A.03.06.01[05]", "A.03.06.01[06]", - "A.03.06.02.b" + "A.03.06.02.a[01]", + "A.03.06.02.a[02]", + "A.03.06.02.b", + "A.03.06.02.c", + "A.03.06.02.d", + "A.03.06.05.b[01]" + ], + "general-nist-800-172-r3": [ + "03.17.03E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.03E.ODP[02]" ], "general-nist-csf-2-0": [ "GV.SC-08", @@ -988,10 +981,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.5" ], - "general-scf-dpmp-2025": [ - "8.0", - "8.1" - ], "general-swift-cscf-2025": [ "6.1", "6.2", @@ -1064,6 +1053,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(4)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)", "248.30(a)(3)(i)", @@ -1080,14 +1072,14 @@ "314.4(h)(7)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(6)(ii)", - "164.412", - "164.412(a)", - "164.412(b)", - "164.530(f)" + "§ 164.308(a)(6)(ii)", + "§ 164.412", + "§ 164.412(a)", + "§ 164.412(b)", + "§ 164.530(f)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(6)(ii)" + "§ 164.308(a)(6)(ii)" ], "usa-federal-irs-1075-2021": [ "IR-4" @@ -1139,18 +1131,18 @@ "IR-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60", + "3.5.1.60(a)", + "3.5.1.60(b)", + "3.5.1.60(c)", + "3.5.1.60(d)", + "3.5.1.60(d)(i)", + "3.5.1.60(d)(ii)", + "3.5.1.60(e)", + "3.5.1.60(f)", + "3.5.1.60(f)(i)", + "3.5.1.60(f)(ii)" ], "emea-eu-dora-2023": [ "Article 9.4(b)", @@ -1182,47 +1174,40 @@ "emea-deu-bsrit-2017": [ "4.7" ], - "emea-deu-c5-2020": [ - "SIM-02" - ], - "emea-isr-cmo-1-0": [ - "7.2", - "24.2" + "emea-isr-cmo-2-0": [ + "Appendix A, 12.1" ], "emea-sau-cgiot-2024": [ "2-12-2" ], - "emea-sau-ecc-1-2018": [ - "2-13-3-2" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-1", - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5", - "2-12-2-6", - "2-12-2-7", - "2-12-2-8" + "2-12-1-3", + "2-12-1-4" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88", - "TPC-89" + "VII.B.TPC-89" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1", - "Article 25.2", - "Article 33.4" + "emea-sau-sama-csf-1-2017": [ + "3.3.15.3", + "3.3.15.4", + "3.3.15.4.a", + "3.3.15.4.b", + "3.3.15.4.c", + "3.3.15.4.d", + "3.3.15.4.e", + "3.3.15.4.f", + "3.3.15.4.g", + "3.3.15.4.h", + "3.3.15.4.i", + "3.3.15.4.j" ], "emea-esp-decree-311-2022": [ - "25.1", - "25.2", - "33.4" + "Article 25(2)", + "Article 34(1)(a)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.7 [OP.EXP.7]", - "7.3.9 [OP.EXP.9]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7", + "op.exp.9" ], "emea-uae-niaf-2023": [ "3.3.1", @@ -1231,6 +1216,9 @@ "emea-gbr-caf-4-0": [ "D1.b" ], + "emea-gbr-cap-1850-2020": [ + "D1" + ], "emea-gbr-def-stan-05-138-2024": [ "3105", "4104" @@ -1256,25 +1244,22 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0123", "ISM-0141", "ISM-0917", "ISM-1618", - "ISM-1803" - ], - "apac-aus-ps-cps-230-2023": [ - "32" + "ISM-1803", + "ISM-1819" ], "apac-aus-ps-cps-234-2019": [ - "23", - "24" + "23" + ], + "apac-chn-data-security-law-2021": [ + "Article 29" ], "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "Article 57" ], "apac-ind-sebi-2024": [ "RS.MA.S2" @@ -1302,7 +1287,13 @@ "16.1.3.2", "16.1.5.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.35", + "11.3", + "11.11" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP07", "HML07" ], @@ -1311,20 +1302,30 @@ ], "apac-nzl-ism-3-9": [ "5.7.4.C.01", - "7.2.17.C.01", - "7.2.17.C.02", "7.2.18.C.01", + "7.2.18.C.02", "7.2.19.C.01", "7.3.9.C.01", - "7.3.10.C.01" + "7.3.10.C.01", + "20.1.25.C.02" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(2)" ], "apac-sgp-mas-trm-2021": [ + "7.7.2", + "7.7.3", "7.7.3(a)", "7.7.3(b)", "7.7.3(c)" ], - "americas-bra-lgpd-2018": [ - "48" + "americas-arg-ppd-2018": [ + "E.1.2-10", + "E.1.2-11", + "G.1.1-1" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7", @@ -1336,13 +1337,21 @@ "3.4.3", "3.4.4" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.1", + "2.7.2", + "2.7.3", + "3", + "3.4.1" + ], "americas-can-itsp-10-171-2025": [ "03.03.04.B", "03.06.01", "03.06.02.A", "03.06.02.B", "03.06.02.C", - "03.06.02.D" + "03.06.02.D", + "03.06.05.B" ] } }, @@ -1364,9 +1373,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically support the incident handling process.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically support the incident handling process. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1447,7 +1456,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -1518,9 +1528,6 @@ ], "emea-eu-dora-2023": [ "Article 9.4(b)" - ], - "emea-isr-cmo-1-0": [ - "24.4" ] } }, @@ -1542,9 +1549,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to implement and govern an insider threat program.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to implement and govern an insider threat program. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1624,7 +1631,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -1678,7 +1686,7 @@ "usa-federal-irs-1075-2021": [ "IR-4(CE-6)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ] @@ -1704,7 +1712,7 @@ "0": "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.", "1": "Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically dynamically reconfigure system components as part of the incident response capability.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically dynamically reconfigure system components as part of the incident response capability. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1744,7 +1752,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -1794,7 +1803,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1880,7 +1889,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -1974,6 +1984,11 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "IR-08-SID" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(5)", + "Article 14(5)(a)", + "Article 14(5)(b)" + ], "emea-eu-nis2-2022": [ "Article 23.3", "Article 23.3(a)", @@ -1984,11 +1999,18 @@ "3.4.1", "3.4.2(a)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 33.4" + "emea-deu-bsrit-2017": [ + "4.7" ], - "emea-esp-decree-311-2022": [ - "33.4" + "emea-deu-c5-2020": [ + "SIM-03", + "SIM-07" + ], + "emea-isr-cmo-2-0": [ + "Appendix B" + ], + "emea-sau-ecc-1-2018": [ + "2-13-3-2" ], "apac-ind-sebi-2024": [ "RS.AN.S2" @@ -1998,9 +2020,16 @@ "16.1.4.1", "16.1.4.2" ], + "americas-bmu-mba-coc-2020": [ + "6.4" + ], "americas-can-osfi-b13-2022": [ "2.7", "3.4.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2", + "3.4.2" ] } }, @@ -2024,9 +2053,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate with approved third-parties to achieve a cross-organization perspective on incident awareness and more effective incident responses.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate with approved third-parties to achieve a cross-organization perspective on incident awareness and more effective incident responses. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2110,7 +2139,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -2141,9 +2171,6 @@ "usa-federal-irs-1075-2021": [ "IR-4(CE-8)" ], - "emea-deu-c5-2020": [ - "OPS-21" - ], "apac-ind-sebi-2024": [ "GV.SC.S6", "RS.CO.S3", @@ -2151,9 +2178,6 @@ ], "apac-nzl-ism-3-9": [ "7.3.10.C.01" - ], - "amaericas-can-osfi-self-assessment": [ - "3.6" ] } }, @@ -2218,7 +2242,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -2248,10 +2273,6 @@ ], "emea-eu-dora-2023": [ "Article 9.4(b)" - ], - "amaericas-can-osfi-self-assessment": [ - "4.13", - "4.15" ] } }, @@ -2275,7 +2296,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to define specific Indicators of Compromise (IOC) to identify the signs of potential cybersecurity events.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2340,7 +2361,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -2359,6 +2381,20 @@ "general-nist-800-171-r2": [ "3.14.7" ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.02.01E", + "03.11.02E", + "03.11.09E", + "03.14.17E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.08E.ODP[01]", + "A.03.02.01E.ODP[01]", + "DS-A.03.11.02E.a.01[01]", + "A.03.11.09E.ODP[01]", + "A.03.14.17E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.CM" ], @@ -2395,8 +2431,8 @@ "emea-deu-bsrit-2017": [ "5.4" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-12" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-80" ], "emea-gbr-caf-4-0": [ "C1.f" @@ -2413,13 +2449,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3201" ], - "apac-nzl-ism-3-9": [ - "7.2.17.C.01", - "7.2.17.C.02" + "apac-sgp-mas-trm-2021": [ + "11.3.5" ], "americas-can-osfi-b13-2022": [ "2.7.2", "3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ] } }, @@ -2443,7 +2481,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain and make available a current and viable Incident Response Plan (IRP) to all stakeholders.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2534,7 +2572,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -2708,9 +2747,11 @@ "03.06.05.a.04", "03.06.05.a.05", "03.06.05.a.06", - "03.06.05.b" + "03.06.05.b", + "03.06.05.d" ], "general-nist-800-171a-r3": [ + "A.03.06.01[01]", "A.03.06.02.ODP[01]", "A.03.06.02.ODP[02]", "A.03.06.05.a.01", @@ -2770,9 +2811,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.10.1" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-swift-cscf-2025": [ "7.1" ], @@ -2815,6 +2853,10 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-08" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(6)", + "101.650(g)(2)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)" ], @@ -2896,18 +2938,8 @@ "IR-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.5.1(59)", - "3.5.1(60)", - "3.5.1(60)(a)", - "3.5.1(60)(b)", - "3.5.1(60)(c)", - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)", - "3.5.1(60)(d)(ii)", - "3.5.1(60)(e)", - "3.5.1(60)(f)", - "3.5.1(60)(f)(i)", - "3.5.1(60)(f)(ii)" + "3.5.1.59", + "3.5.1.60" ], "emea-eu-dora-2023": [ "Article 17.1", @@ -2926,38 +2958,28 @@ "3.5.1", "6.10.2(d)" ], - "emea-isr-cmo-1-0": [ - "7.2", - "24.2", - "24.3", - "24.8", - "24.9" + "emea-deu-c5-2020": [ + "SIM-03" ], "emea-sau-cgiot-2024": [ "2-12-1", "2-12-2" ], "emea-sau-ecc-1-2018": [ - "2-13-3-1", - "2-13-3-2" + "2-13-3-1" ], "emea-sau-otcc-1-2022": [ - "2-12-2-2", - "2-12-2-3", - "2-12-2-4", - "2-12-2-5" + "2-12-1-1", + "2-12-1-3", + "2-12-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-88" + "VII.A.TPC-23-BP2", + "VII.B.TPC-88" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.1", - "Article 25.2" - ], - "emea-esp-decree-311-2022": [ - "25.1", - "25.2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7", + "op.exp.9" ], "emea-gbr-caf-4-0": [ "D1.a" @@ -2974,27 +2996,21 @@ "4101", "4102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0043", "ISM-0576", "ISM-0917", "ISM-1784" ], "apac-aus-ps-cps-234-2019": [ - "23", "24", + "25", "25(a)", "25(b)" ], "apac-chn-cybersecurity-law-2017": [ "Article 25" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], "apac-ind-sebi-2024": [ "DE.DP.S2", "GV.RM.S3", @@ -3012,12 +3028,14 @@ "16.1.5.7", "16.1.5.8" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HHSP07", - "HML07" + "apac-mys-bnm-rmit-2025": [ + "10.20", + "11.3", + "11.13" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS20" + "HHSP07", + "HML07" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP07" @@ -3031,32 +3049,22 @@ "7.3.5.C.01", "7.3.9.C.01", "7.3.10.C.01", - "16.1.47.C.01" + "16.4.39.C.02", + "16.4.42.C.01" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(2)", + "6A.26C(4)" ], "apac-sgp-mas-trm-2021": [ - "7.7.3(a)", - "7.7.3(b)", - "7.7.3(c)", - "12.3.1", - "12.3.2", - "12.3.3" + "12.3.1" ], - "apac-kor-pipa-2011": [ - "34" + "americas-arg-ppd-2018": [ + "G.1.1-1" ], "americas-bmu-mba-coc-2020": [ "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" - ], "americas-can-osfi-b13-2022": [ "2.7.1", "2.7.2", @@ -3071,7 +3079,8 @@ "03.06.05.A.04", "03.06.05.A.05", "03.06.05.A.06", - "03.06.05.B" + "03.06.05.B", + "03.06.05.D" ] } }, @@ -3093,9 +3102,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address data breaches, or other incidents involving the unauthorized disclosure of sensitive or regulated data, according to applicable laws, regulations and contractual obligations.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address data breaches, or other incidents involving the unauthorized disclosure of sensitive or regulated data, according to applicable laws, regulations and contractual obligations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3161,7 +3170,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -3209,32 +3219,29 @@ "general-nist-800-82-r3": [ "IR-08(01)" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "usa-federal-fbi-cjis-6-0": [ "IR-8(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.404(a)(1)", - "164.404(a)(2)", - "164.404(c)(1)(A)", - "164.404(c)(1)(B)", - "164.404(c)(1)(C)", - "164.404(c)(1)(D)", - "164.404(c)(1)(E)", - "164.404(c)(2)", - "164.404(d)(1)(i)", - "164.404(d)(1)(ii)", - "164.404(d)(2)", - "164.404(d)(2)(i)", - "164.404(d)(2)(ii)(A)", - "164.404(d)(2)(ii)(B)", - "164.404(d)(3)", - "164.406(a)", - "164.406(b)", - "164.406(c)", - "164.410(c)(1)" + "§ 164.404(a)(1)", + "§ 164.404(a)(2)", + "§ 164.404(c)(1)(A)", + "§ 164.404(c)(1)(B)", + "§ 164.404(c)(1)(C)", + "§ 164.404(c)(1)(D)", + "§ 164.404(c)(1)(E)", + "§ 164.404(c)(2)", + "§ 164.404(d)(1)(i)", + "§ 164.404(d)(1)(ii)", + "§ 164.404(d)(2)", + "§ 164.404(d)(2)(i)", + "§ 164.404(d)(2)(ii)(A)", + "§ 164.404(d)(2)(ii)(B)", + "§ 164.404(d)(3)", + "§ 164.406(a)", + "§ 164.406(b)", + "§ 164.406(c)", + "§ 164.410(c)(1)" ], "usa-federal-irs-1075-2021": [ "IR-8(CE-1)", @@ -3245,78 +3252,25 @@ "emea-eu-gdpr-2016": [ "Article 33.1" ], - "emea-deu-c5-2020": [ - "SIM-02" - ], - "emea-ken-pda-2019": [ - "43(1)(b)", - "43(2)", - "43(3)", - "43(4)", - "43(5)", - "43(5)(a)", - "43(5)(b)", - "43(5)(c)", - "43(5)(d)", - "43(5)(e)", - "43(6)", - "43(7)", - "43(8)(a)", - "43(8)(b)", - "43(8)(c)" - ], - "emea-qat-pdppl-2020": [ - "14" + "emea-deu-fdpa-2017": [ + "3.4.65(1)", + "3.4.65(2)" ], "emea-sau-pdpl-2023": [ "Article 20.1", "Article 20.2" ], - "emea-srb-act-9-2018": [ - "53", - "53.1", - "53.2", - "53.3" - ], - "emea-zaf-popia-2013": [ - "22" - ], - "emea-che-fadp-2025": [ - "12" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" - ], "apac-ind-dpdpa-2023": [ "8(6)" ], - "apac-jpn-ppi-2020": [ - "22-2(1)", - "22-2(2)" - ], - "apac-phl-dpa-2012": [ - "38" - ], "apac-kor-pipa-2011": [ - "34" - ], - "apac-twn-pdpa-2025": [ - "12" - ], - "americas-bra-lgpd-2018": [ - "48" + "IV.34(2)" ], - "americas-mex-fdpa-2010": [ - "20" + "americas-bhs-dpa-2003": [ + "V.48(1)" ] } }, @@ -3340,7 +3294,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ On at least an annual basis, IT and/or cybersecurity personnel update incident response strategies to keep current with business needs, technology changes and regulatory requirements.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to regularly review and modify incident response practices to incorporate lessons learned, business process changes and industry developments, as necessary.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3413,7 +3367,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -3484,7 +3439,6 @@ "NFO - IR-1" ], "general-nist-800-171-r3": [ - "03.06.04.b", "03.06.05.c" ], "general-nist-800-171a-r3": [ @@ -3558,14 +3512,10 @@ "EV.ST.S3", "RS.IM.S2" ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-osfi-b13-2022": [ "2.7.3" ], "americas-can-itsp-10-171-2025": [ - "03.06.04.B", "03.06.05.C" ] } @@ -3575,7 +3525,7 @@ "title": "Continuous Incident Response Improvements", "family": "IRO", "description": "Mechanisms exist to use qualitative and quantitative data from incident response testing to: \n(1) Determine the effectiveness of incident response processes;\n(2) Continuously improve incident response processes; and\n(3) Provide incident response measures and metrics that are accurate, consistent and in a reproducible format.", - "scf_question": "Does the organization use qualitative and quantitative data from incident response testing to: \n (1) Determine the effectiveness of incident response processes;\n (2) Continuously improve incident response processes; and\n (3) Provide incident response measures and metrics that are accurate, consistent, and in a reproducible format?", + "scf_question": "Does the organization use qualitative and quantitative data from incident response testing to: \n(1) Determine the effectiveness of incident response processes;\n(2) Continuously improve incident response processes; and\n(3) Provide incident response measures and metrics that are accurate, consistent and in a reproducible format?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -3659,7 +3609,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -3676,6 +3627,9 @@ "general-nist-800-171-r3": [ "03.06.04.b" ], + "general-nist-800-171a-r3": [ + "A.03.06.04.b[03]" + ], "usa-federal-dhs-cisa-cpg-2-0": [ "2.S" ], @@ -3685,9 +3639,16 @@ "IR-3(CE-3).b", "IR-3(CE-3).c" ], + "emea-gbr-cap-1850-2020": [ + "D2" + ], "apac-jpn-ismap": [ "16.1.1.14" ], + "apac-sgp-mas-trm-2021": [ + "7.8.3", + "12.3.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.04.B" ] @@ -3714,7 +3675,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders are proficient on their specific IRP role(s) and responsibilities through recurring training events (e.g., annual rock drill).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to train personnel in their incident response roles and responsibilities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3786,7 +3747,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -3861,15 +3823,8 @@ "03.06.04.a.03" ], "general-nist-800-171a-r3": [ - "A.03.06.04.ODP[01]", - "A.03.06.04.ODP[02]", - "A.03.06.04.ODP[03]", - "A.03.06.04.ODP[04]", "A.03.06.04.a.01", - "A.03.06.04.b[01]", - "A.03.06.04.b[02]", - "A.03.06.04.b[03]", - "A.03.06.04.b[04]" + "A.03.06.04.a.03" ], "general-pci-dss-4-0-1": [ "12.10.4", @@ -3932,22 +3887,16 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-02" ], - "emea-isr-cmo-1-0": [ - "24.10", - "24.11" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-6" + "2-12-1-6" ], - "emea-sau-sacs-002-2022": [ - "TPC-88" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], "apac-ind-sebi-2024": [ "RS.IM.S2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" - ], "americas-can-itsp-10-171-2025": [ "03.06.04.A", "03.06.04.A.03" @@ -3972,7 +3921,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate simulated events into incident response training to facilitate effective response by personnel in crisis situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4044,7 +3993,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -4080,9 +4030,6 @@ ], "usa-federal-irs-1075-2021": [ "IR-2(CE-1)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.8" ] } }, @@ -4171,7 +4118,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -4221,7 +4169,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders are proficient on their specific IRP role(s) and responsibilities through recurring training events (e.g., annual rock drill).\n▪ On at least an annual basis, IT and/or cybersecurity personnel conduct tabletop exercises to validate disaster recovery and contingency plans, in conjunction with stakeholders and any required vendors.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to formally test incident response capabilities through realistic exercises to determine the operational effectiveness of those capabilities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4293,7 +4241,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -4400,9 +4349,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.2" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "general-swift-cscf-2025": [ "7.1" ], @@ -4427,6 +4373,21 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(a)(1)", + "101.635(b)(1)", + "101.635(b)(2)", + "101.635(b)(3)", + "101.635(c)(1)", + "101.635(c)(2)", + "101.635(c)(2)(i)", + "101.635(c)(2)(ii)", + "101.635(c)(2)(iii)", + "101.635(c)(2)(iv)", + "101.635(c)(3)", + "101.635(c)(4)", + "101.635(c)(5)" + ], "usa-federal-irs-1075-2021": [ "IR-3" ], @@ -4456,13 +4417,11 @@ "emea-eu-nis2-annex-2024": [ "3.5.5" ], - "emea-isr-cmo-1-0": [ - "24.10", - "24.11", - "24.12" - ], "emea-sau-otcc-1-2022": [ - "2-12-2-7" + "2-12-1-7" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-gbr-caf-4-0": [ "D1.c" @@ -4479,19 +4438,42 @@ "4103", "4105" ], + "apac-aus-ism-2026-march": [ + "ISM-2006" + ], + "apac-aus-ps-cps-230-2023": [ + "27(c)" + ], "apac-aus-ps-cps-234-2019": [ - "26" + "26", + "27", + "27(a)", + "27(b)", + "27(c)", + "27(d)", + "27(e)" ], "apac-ind-sebi-2024": [ "DE.DP.S2", "GV.RM.S3" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-mys-bnm-rmit-2025": [ + "11.16" + ], + "apac-sgp-mas-trm-2021": [ + "13.3.1", + "13.3.2", + "13.5.2" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" + ], "americas-can-itsp-10-171-2025": [ "03.06.03" ] @@ -4517,9 +4499,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ On at least an annual basis, IT and/or cybersecurity personnel conduct tabletop exercises to validate disaster recovery and contingency plans, in conjunction with stakeholders and any required vendors.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate incident response testing with organizational elements responsible for related plans.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to coordinate incident response testing with organizational elements responsible for related plans. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4605,7 +4587,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -4657,20 +4640,27 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-03(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(a)(1)" + ], "usa-federal-irs-1075-2021": [ "IR-3(CE-2)" ], "usa-state-tx-txramp-2-0-level-2": [ "IR-03 (02)" ], - "emea-sau-otcc-1-2022": [ - "2-12-2-8" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], - "amaericas-can-osfi-self-assessment": [ - "2.8" + "apac-mys-bnm-rmit-2025": [ + "11.3" ], "americas-can-osfi-b13-2022": [ "3.4.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" ] } }, @@ -4695,7 +4685,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to establish an integrated team of cybersecurity, IT and business function representatives that are capable of addressing cybersecurity and data protection incident response operations.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4784,7 +4774,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -4854,12 +4845,22 @@ "general-nist-800-161-r1-level-3": [ "IR-4(11)" ], + "general-nist-800-171-r3": [ + "03.06.02.b", + "03.06.02.d" + ], "general-nist-800-171a-r3": [ "A.03.06.02.b", "A.03.06.02.d" ], - "general-nist-800-172": [ - "3.6.2e" + "general-nist-800-172-r3": [ + "03.06.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.02E[01]", + "A.03.06.02E.ODP[01]", + "DS-A.03.06.02E[02]", + "DS-A.03.06.02E[03]" ], "general-nist-csf-2-0": [ "DE.AE-06", @@ -4883,9 +4884,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.10.3" ], - "general-scf-dpmp-2025": [ - "8.1" - ], "general-tisax-6-0-3": [ "1.6.3" ], @@ -4907,10 +4905,6 @@ "usa-federal-sec-cybersecurity-rule-2023": [ "Form 8-K Item 1.05(a)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(i)" - ], "emea-eu-dora-2023": [ "Article 14.1", "Article 14.2", @@ -4922,49 +4916,44 @@ "3.5.3(a)", "4.3.3" ], - "emea-isr-cmo-1-0": [ - "24.7", - "24.9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-89" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 33.3" + "emea-sau-otcc-1-2022": [ + "2-12-1-4" ], - "emea-esp-decree-311-2022": [ - "33.3" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0733", "ISM-1618" ], - "apac-aus-ps-cps-234-2019": [ - "23", - "24", - "25(a)", - "25(b)" + "apac-mys-bnm-rmit-2025": [ + "11.13", + "11.14" ], "apac-nzl-ism-3-9": [ "7.2.18.C.01" ], "apac-sgp-mas-trm-2021": [ - "7.7.5" + "7.7.5", + "7.7.6" ], - "amaericas-can-osfi-self-assessment": [ - "5.1", - "5.2", - "5.3", - "5.4", - "5.5", - "5.6", - "5.7", - "5.8" + "americas-arg-ppd-2018": [ + "G.1.1-2" + ], + "americas-bmu-mba-coc-2020": [ + "6.4" ], "americas-can-osfi-b13-2022": [ "2.7.2", "3.3.3", "3.4.4" + ], + "americas-can-osfi-self-assessment-2": [ + "3.4.4" + ], + "americas-can-itsp-10-171-2025": [ + "03.06.02.B", + "03.06.02.D" ] } }, @@ -4989,7 +4978,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to perform digital forensics and maintain the integrity of the chain of custody, in accordance with applicable laws, regulations and industry-recognized secure practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5080,7 +5069,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -5158,10 +5148,10 @@ "CIP-009-6 1.5" ], "emea-deu-c5-2020": [ - "SIM-03" + "SIM-01-DOAR" ], - "emea-sau-sacs-002-2022": [ - "TPC-89" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.9" ], "emea-gbr-def-stan-05-138-2024": [ "3104" @@ -5172,7 +5162,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3104" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0137", "ISM-0138", "ISM-1609", @@ -5198,7 +5188,7 @@ "16.1.7.12", "16.1.7.13.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP74", "HML74" ], @@ -5210,6 +5200,9 @@ ], "americas-can-osfi-b13-2022": [ "3.4.5" + ], + "americas-can-osfi-self-assessment-2": [ + "3.4.5" ] } }, @@ -5268,9 +5261,9 @@ "MT-6", "MT-8", "MT-9", - "MT-11" + "MT-11", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Incident Response", "crosswalks": {} }, @@ -5294,7 +5287,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to document, monitor and report the status of cybersecurity and data protection incidents to internal stakeholders all the way through the resolution of the incident.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5384,7 +5377,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -5491,7 +5485,8 @@ ], "general-nist-800-171a-r3": [ "A.03.06.02.a[01]", - "A.03.06.02.a[02]" + "A.03.06.02.a[02]", + "A.03.06.02.b" ], "general-nist-csf-2-0": [ "DE.AE-06", @@ -5535,10 +5530,10 @@ "314.4(h)(6)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(D)" + "§ 164.308(a)(1)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "IR-5" @@ -5558,10 +5553,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-05" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5.1(60)(d)", - "3.5.1(60)(d)(ii)" - ], "emea-eu-gdpr-2016": [ "Article 33.5" ], @@ -5570,33 +5561,25 @@ "3.5.4", "6.10.2(a)" ], - "emea-isr-cmo-1-0": [ - "24.5" - ], - "emea-sau-sacs-002-2022": [ - "TPC-89", - "TPC-90" + "emea-deu-c5-2020": [ + "SIM-07" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.2" + "emea-isr-cmo-2-0": [ + "Appendix A, 13.1" ], - "emea-esp-decree-311-2022": [ - "25.2" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-90" ], "emea-uae-niaf-2023": [ "3.3.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0125", "ISM-0137", "ISM-0733", "ISM-1609", "ISM-1803" ], - "apac-aus-ps-cps-234-2019": [ - "23", - "24" - ], "apac-ind-dpdpa-2023": [ "8(6)" ], @@ -5608,9 +5591,6 @@ "7.3.6.C.01", "7.3.6.C.02" ], - "apac-sgp-mas-trm-2021": [ - "7.7.5" - ], "americas-can-osfi-b13-2022": [ "2.7" ], @@ -5638,11 +5618,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically assist in the tracking, collection and analysis of information from actual and potential cybersecurity and data protection incidents.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -5722,7 +5702,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -5747,11 +5728,19 @@ "general-nist-800-82-r3-high": [ "IR-05(01)" ], + "general-nist-800-172-r3": [ + "03.06.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.04E[01]", + "A.03.06.04E.ODP[01]", + "DS-A.03.06.04E[02]", + "A.03.06.04E.ODP[02]", + "DS-A.03.06.04E[03]", + "A.03.06.04E.ODP[03]" + ], "usa-federal-gsa-fedramp-5-high": [ "IR-05(01)" - ], - "emea-isr-cmo-1-0": [ - "24.5" ] } }, @@ -5858,7 +5847,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -5888,7 +5878,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain a repository of cybersecurity events and incidents that documents:\n(1) Details of the incident (e.g., category, severity, affected parties, etc.);\n(2) Remediation actions taken through incident closure; and\n(3) A summary from the Root Cause Analysis (RCA), if applicable.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5922,9 +5912,9 @@ "MT-5", "MT-6", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Incident Response", "crosswalks": { "usa-federal-doe-c2m2-2-1": [ @@ -5956,7 +5946,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to analyze historical incidents in aggregate to identify:\n(1) Patterns;\n(2) Trends; and \n(3) Other common root causes in order to address the vulnerability and risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5988,9 +5978,9 @@ "MT-5", "MT-6", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (C2M2)", "family_name": "Incident Response", "crosswalks": { "usa-federal-doe-c2m2-2-1": [ @@ -6020,7 +6010,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to timely-report incidents to applicable:\n(1) Internal stakeholders; \n(2) Affected clients & third-parties; and\n(3) Regulatory authorities.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6100,7 +6090,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -6174,7 +6165,7 @@ "6.8" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-iso-42001-2023": [ "A.8.3", @@ -6225,7 +6216,8 @@ ], "general-nist-800-171-r3": [ "03.06.02.b", - "03.06.02.c" + "03.06.02.c", + "03.06.02.d" ], "general-nist-800-171a-r3": [ "A.03.06.02.ODP[01]", @@ -6277,9 +6269,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.10.1" ], - "general-scf-dpmp-2025": [ - "8.2" - ], "general-tisax-6-0-3": [ "1.6.2" ], @@ -6309,6 +6298,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(10)" + ], "usa-federal-sro-finra": [ "248.30(a)(3)(iii)", "248.30(a)(4)(i)", @@ -6331,10 +6323,10 @@ "314.4(h)(4)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.404(b)", - "164.408(a)", - "164.408(b)", - "164.408(c)" + "§ 164.404(b)", + "§ 164.408(a)", + "§ 164.408(b)", + "§ 164.408(c)" ], "usa-federal-irs-1075-2021": [ "IR-6" @@ -6398,6 +6390,19 @@ "12(e)(C)", "12(e)(D)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.220.1", + "603A.220.2", + "603A.220.3", + "603A.220.4", + "603A.220.4(a)", + "603A.220.4(b)", + "603A.220.4(c)", + "603A.220.4(c)(1)", + "603A.220.4(c)(2)", + "603A.220.4(c)(3)", + "603A.220.6" + ], "usa-state-nv-regulation-5-2024": [ "5.260.4(a)", "5.260.4(c)" @@ -6474,8 +6479,13 @@ "emea-eu-ai-act-2024": [ "Article 17.1(j)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(8)", + "Article 15(1)", + "Article 15(2)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-dora-2023": [ "Article 14.1", @@ -6513,16 +6523,57 @@ "3.1.2(b)", "13.2.2(c)" ], + "emea-eu-psd2-2015": [ + "96(1)" + ], + "emea-aut-dpa-2018": [ + "§ 55(1)", + "§ 55(2)", + "§ 56(1)", + "§ 56(2)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 4, Art. 61(1)", + "Title 2, Chapter IV, Section 4, Art. 61(2)", + "Title 2, Chapter IV, Section 4, Art. 61(3)", + "Title 2, Chapter IV, Section 4, Art. 61(4)", + "Title 2, Chapter IV, Section 4, Art. 61(5)", + "Title 2, Chapter IV, Section 4, Art. 61(6)", + "Title 2, Chapter IV, Section 4, Art. 62(1)", + "Title 2, Chapter IV, Section 4, Art. 62(2)", + "Title 2, Chapter IV, Section 4, Art. 62(3)", + "Title 2, Chapter IV, Section 4, Art. 62(4)", + "Title 2, Chapter IV, Section 4, Art. 62(5)" + ], + "emea-deu-fdpa-2017": [ + "3.4.66(1)", + "3.4.66(2)" + ], "emea-deu-c5-2020": [ - "SIM-03", + "RB-20", "SIM-04" ], - "emea-isr-cmo-1-0": [ - "24.6", - "24.8" + "emea-irl-dpa-2018": [ + "s.85", + "s.86" ], - "emea-qat-pdppl-2020": [ - "14" + "emea-ken-pda-2019": [ + "IV.43(1)(b)", + "IV.43(2)", + "IV.43(3)", + "IV.43(4)", + "IV.43(5)", + "IV.43(5)(a)", + "IV.43(5)(b)", + "IV.43(5)(c)", + "IV.43(5)(d)", + "IV.43(5)(e)", + "IV.43(6)", + "IV.43(7)", + "IV.43(8)", + "IV.43(8)(a)", + "IV.43(8)(b)", + "IV.43(8)(c)" ], "emea-sau-cgiot-2024": [ "2-12-2" @@ -6532,27 +6583,91 @@ "2-13-3-4" ], "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-89" + "VII.A.TPC-23-BP1" ], - "emea-zaf-popia-2013": [ - "22" + "emea-srb-act-9-2018": [ + "IV.2.52", + "IV.2.52(1)", + "IV.2.52(2)", + "IV.2.52(3)", + "IV.2.52(4)", + "IV.2.53" ], - "emea-esp-boe-a-2022-7191": [ - "Article 25.2", - "Article 33.2", - "Article 33.4", - "Article 33.7" + "emea-zaf-popia-2013": [ + "3.A.7.22(1)", + "3.A.7.22(1)(a)", + "3.A.7.22(1)(b)", + "3.A.7.22(2)", + "3.A.7.22(3)", + "3.A.7.22(4)", + "3.A.7.22(4)(a)", + "3.A.7.22(4)(b)", + "3.A.7.22(4)(c)", + "3.A.7.22(4)(d)", + "3.A.7.22(4)(e)", + "3.A.7.22(5)", + "3.A.7.22(5)(a)", + "3.A.7.22(5)(b)", + "3.A.7.22(5)(c)", + "3.A.7.22(5)(d)", + "3.A.7.22(6)" ], - "emea-esp-decree-311-2022": [ - "25.2", - "33.2", - "33.4", - "33.7" + "emea-che-fadp-2025": [ + "3.24.1", + "3.24.2", + "3.24.3", + "3.24.4", + "3.24.5", + "3.24.5.a", + "3.24.5.b", + "3.24.5.c", + "3.24.5bis", + "3.24.6" ], "emea-uae-niaf-2023": [ "3.3.3" ], + "emea-gbr-dpa-2018": [ + "Section 67(1)", + "Section 67(1)(a)", + "Section 67(1)(b)", + "Section 67(2)", + "Section 67(3)", + "Section 67(4)", + "Section 67(4)(a)", + "Section 67(4)(b)", + "Section 67(4)(c)", + "Section 67(4)(d)", + "Section 67(5)", + "Section 67(6)", + "Section 67(6)(a)", + "Section 67(6)(b)", + "Section 67(6)(c)", + "Section 67(7)", + "Section 67(9)", + "Section 68(1)", + "Section 68(2)", + "Section 68(2)(a)", + "Section 68(2)(b)", + "Section 68(2)(c)", + "Section 68(2)(d)", + "Section 68(3)", + "Section 68(3)(a)", + "Section 68(3)(b)", + "Section 68(3)(c)", + "Section 68(4)", + "Section 68(5)", + "Section 68(6)", + "Section 68(6)(a)", + "Section 68(6)(b)", + "Section 68(7)", + "Section 68(7)(a)", + "Section 68(7)(b)", + "Section 68(7)(c)", + "Section 68(7)(e)", + "Section 68(8)", + "Section 68(9)" + ], "apac-aus-essential-8-2024": [ "ML2-P3", "ML2-P4", @@ -6563,17 +6678,25 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0123", "ISM-0137", "ISM-0733", "ISM-1088", - "ISM-1609" + "ISM-1609", + "ISM-1880", + "ISM-1881" ], "apac-aus-ps-cps-230-2023": [ - "33", "42" ], + "apac-aus-ps-cps-234-2019": [ + "35", + "36" + ], + "apac-chn-pipl-2021": [ + "Article 57" + ], "apac-ind-dpdpa-2023": [ "8(6)" ], @@ -6584,10 +6707,17 @@ "RS.CO.S2", "RS.CO.S3" ], + "apac-jpn-appi-2020": [ + "IV.1.22-2(2)" + ], "apac-jpn-ismap": [ "6.1.3.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.35", + "11.19" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP75", "HML75" ], @@ -6596,27 +6726,108 @@ ], "apac-nzl-ism-3-9": [ "7.2.18.C.01", + "7.2.18.C.02", "7.2.20.C.01", + "7.2.20.C.02", + "7.2.20.C.03", "7.2.21.C.01", "7.2.23.C.01" ], + "apac-nzl-privacy-act-2020": [ + "6.1.115(1)", + "6.1.115(2)", + "6.1.115(3)", + "6.1.115(3)(a)", + "6.1.115(3)(b)", + "6.1.115(4)", + "6.1.115(4)(a)", + "6.1.115(4)(b)", + "6.1.117(1)", + "6.1.117(1)(a)", + "6.1.117(1)(a)(i)", + "6.1.117(1)(a)(ii)", + "6.1.117(1)(b)", + "6.1.117(1)(c)", + "6.1.117(1)(d)", + "6.1.117(1)(e)", + "6.1.117(1)(f)", + "6.1.117(2)", + "6.1.117(2)(a)", + "6.1.117(2)(b)", + "6.1.117(2)(c)", + "6.1.117(2)(d)", + "6.1.117(2)(e)", + "6.1.117(2)(f)", + "6.1.117(3)", + "6.1.117(4)", + "6.1.117(5)" + ], + "apac-sgp-pdpa-2012": [ + "6A.26D(1)", + "6A.26D(2)", + "6A.26D(3)", + "6A.26D(4)", + "6A.26D(5)(a)", + "6A.26D(5)(b)", + "6A.26D(6)", + "6A.26D(6)(a)", + "6A.26D(6)(b)", + "6A.26D(9)", + "6A.26E", + "6A.26E(a)", + "6A.26E(b)" + ], "apac-sgp-mas-trm-2021": [ "7.7.5", - "7.7.6", "7.7.7" ], + "apac-kor-pipa-2011": [ + "IV.34(1)", + "IV.34(1)1", + "IV.34(1)2", + "IV.34(1)3", + "IV.34(1)4", + "IV.34(1)5", + "IV.34(3)" + ], + "apac-twn-pdpa-2025": [ + "I.12", + "I.12.1", + "I.12.2" + ], + "americas-arg-ppd-2018": [ + "G.1.2" + ], + "americas-bhs-dpa-2003": [ + "V.48(2)", + "V.48(3)", + "V.48(3)(a)", + "V.48(3)(b)", + "V.48(3)(c)" + ], "americas-bmu-mba-coc-2020": [ - "6.5" + "6.4" ], "americas-bra-lgpd-2018": [ - "48" + "VII.I.48", + "VII.I.48.1", + "VII.I.48.1.I", + "VII.I.48.1.II", + "VII.I.48.1.III", + "VII.I.48.1.IV", + "VII.I.48.1.V", + "VII.I.48.1.VI" ], "americas-can-osfi-b13-2022": [ "3.4.1" ], "americas-can-itsp-10-171-2025": [ "03.06.02.B", - "03.06.02.C" + "03.06.02.C", + "03.06.02.D" + ], + "americas-mex-fdpa-2010": [ + "II.20" ] } }, @@ -6638,7 +6849,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically assist in the reporting of cybersecurity and data protection incidents.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6711,7 +6922,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -6766,8 +6978,8 @@ "control_id": "IRO-10.2", "title": "Cyber Incident Reporting for Sensitive / Regulated Data", "family": "IRO", - "description": "Mechanisms exist to report sensitive/regulated data incidents in a timely manner.", - "scf_question": "Does the organization report sensitive/regulated data incidents in a timely manner?", + "description": "Mechanisms exist to report sensitive and/or regulated data incidents in a timely manner.", + "scf_question": "Does the organization report sensitive and/or regulated data incidents in a timely manner?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -6861,7 +7073,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -6935,7 +7148,8 @@ "03.06.02.c" ], "general-nist-800-171a-r3": [ - "A.03.06.02.ODP[02]" + "A.03.06.02.ODP[02]", + "A.03.06.02.b" ], "general-nist-csf-2-0": [ "RS.CO", @@ -6958,8 +7172,13 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(3)(v)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(7)", + "101.625(d)(10)", + "101.650(g)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.410(a)(1)" + "§ 164.410(a)(1)" ], "usa-federal-nerc-cip-2024": [ "CIP-008-6 4.2" @@ -6974,8 +7193,18 @@ "emea-eu-ai-act-2024": [ "Article 17.1(j)" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(1)", + "Article 14(3)", + "Article 14(4)(a)", + "Article 14(4)(b)", + "Article 14(4)(c)", + "Article 14(4)(i)", + "Article 14(4)(i)(ii)", + "Article 14(4)(i)(iii)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-gdpr-2016": [ "Article 33.1", @@ -6989,40 +7218,50 @@ "emea-eu-nis2-annex-2024": [ "3.1.2(b)" ], + "emea-deu-fdpa-2017": [ + "3.4.65(1)", + "3.4.65(2)", + "3.4.65(3)", + "3.4.65(3)1", + "3.4.65(3)2", + "3.4.65(3)3", + "3.4.65(3)4", + "3.4.65(4)", + "3.4.65(5)", + "3.4.65(6)" + ], + "emea-irl-dpa-2018": [ + "s.87" + ], + "emea-ken-pda-2019": [ + "IV.43(1)(a)" + ], "emea-qat-pdppl-2020": [ - "14" + "3.14" ], "emea-sau-ecc-1-2018": [ "2-13-3-3", "2-13-3-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-23", - "TPC-89" - ], - "emea-srb-act-9-2018": [ - "52", - "52.1", - "52.2", - "52.3", - "52.4" - ], "emea-uae-niaf-2023": [ "3.3.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0733" ], - "apac-chn-pipl-2021": [ - "57", - "57(1)", - "57(2)", - "57(3)" + "apac-aus-ps-cps-230-2023": [ + "33" ], "apac-ind-sebi-2024": [ "DE.DP.S3", "RS.CO.S2" ], + "apac-jpn-appi-2020": [ + "IV.1.22-2(1)" + ], + "apac-mys-bnm-rmit-2025": [ + "11.18" + ], "apac-nzl-ism-3-9": [ "7.2.18.C.01", "7.2.20.C.01", @@ -7030,9 +7269,41 @@ "7.2.23.C.01", "7.3.8.C.03" ], + "apac-phl-dpa-2012": [ + "V.20(f)" + ], + "apac-sgp-pdpa-2012": [ + "6A.26C(3)(a)", + "6A.26C(3)(b)", + "6A.26C(4)" + ], + "americas-arg-ppd-2018": [ + "G.1.3" + ], + "americas-bhs-dpa-2003": [ + "V.47(1)", + "V.47(2)", + "V.47(3)", + "V.47(4)(a)", + "V.47(4)(b)", + "V.47(4)(c)", + "V.47(4)(d)", + "V.47(4)(e)", + "V.47(4)(f)", + "V.47(4)(g)", + "V.47(4)(h)", + "V.47(5)", + "V.47(6)", + "V.47(6)(a)", + "V.47(6)(b)", + "V.47(6)(c)" + ], "americas-can-itsp-10-171-2025": [ "03.06.02.B", "03.06.02.C" + ], + "americas-col-law-1581-2012": [ + "VI.17(n)" ] } }, @@ -7054,7 +7325,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to report system vulnerabilities associated with reported cybersecurity and data protection incidents to organization-defined personnel or roles.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7137,7 +7408,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -7185,9 +7457,6 @@ ], "usa-federal-irs-1075-2021": [ "IR-6(CE-3)" - ], - "emea-deu-c5-2020": [ - "PSS-02" ] } }, @@ -7211,7 +7480,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide cybersecurity and data protection incident information to the provider of the Technology Assets, Applications and/or Services (TAAS) and other organizations involved in the supply chain for TAAS related to the incident.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7300,7 +7569,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -7398,10 +7668,7 @@ "emea-eu-nis2-2022": [ "Article 23.2" ], - "emea-isr-cmo-1-0": [ - "17.11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1569" ], "apac-ind-sebi-2024": [ @@ -7420,7 +7687,7 @@ "title": "Serious Incident Reporting", "family": "IRO", "description": "Mechanisms exist to report any serious incident involving the organization's Technology Assets, Applications, Services and/or Data (TAASD) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines.", - "scf_question": "Does the organization report any serious incident involving the organization's Technology Assets, Applications and/or Services (TAAS) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines?", + "scf_question": "Does the organization report any serious incident involving its Technology Assets, Applications, Services and/or Data (TAASD) to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7433,7 +7700,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to report any serious incident involving the organization's TAASD to relevant authorities in the locality where the incident occurred, in accordance with mandatory reporting:\n(1) Requirements; and\n(2) Timelines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7518,10 +7785,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(10)" + ], "usa-federal-nerc-cip-2024": [ "CIP-008-6 R4", "CIP-008-6 4.1", @@ -7530,9 +7801,33 @@ "CIP-008-6 4.1.3", "CIP-008-6 4.2" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.2", - "Article 11.4" + "emea-eu-psd2-2015": [ + "96(1)" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.15.7", + "3.3.15.7.a", + "3.3.15.7.b", + "3.3.15.7.c", + "3.3.15.7.d", + "3.3.15.7.e", + "3.3.15.7.f", + "3.3.15.7.g", + "3.3.15.7.h", + "3.3.15.7.i", + "3.3.15.7.j", + "3.3.15.7.k" + ], + "emea-esp-decree-311-2022": [ + "Article 33(7)" + ], + "americas-bmu-mba-coc-2020": [ + "6.5", + "6.5(a)", + "6.5(b)", + "6.5(c)", + "6.5(d)", + "6.5(e)" ] } }, @@ -7554,9 +7849,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide incident response advice and assistance to users of Technology Assets, Applications and/or Services (TAAS) for the handling and reporting of actual and potential cybersecurity and data protection incidents.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to provide incident response advice and assistance to users of Technology Assets, Applications and/or Services (TAAS) for the handling and reporting of actual and potential cybersecurity and data protection incidents. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7640,7 +7935,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -7692,9 +7988,6 @@ "general-nist-800-171a-r3": [ "A.03.06.02.d" ], - "general-scf-dpmp-2025": [ - "8.0" - ], "usa-federal-fbi-cjis-6-0": [ "IR-7" ], @@ -7758,7 +8051,7 @@ "0": "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.", "1": "Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically increase the availability of incident response-related information and support.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to automatically increase the availability of incident response-related information and support. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7824,7 +8117,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -7887,7 +8181,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to establish a direct, cooperative relationship between the organization's incident response capability and external service providers.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7971,7 +8265,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -8017,9 +8312,6 @@ "general-nist-800-161-r1-level-3": [ "IR-7(2)" ], - "general-scf-dpmp-2025": [ - "8.2" - ], "usa-federal-doe-c2m2-2-1": [ "RESPONSE-3j", "RESPONSE-3k" @@ -8033,8 +8325,9 @@ "IR-7(CE-2).a", "IR-7(CE-2).b" ], - "emea-zaf-popia-2013": [ - "21.2" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.1", + "op.cont.2" ], "apac-nzl-ism-3-9": [ "7.3.10.C.01", @@ -8047,8 +8340,8 @@ "control_id": "IRO-12", "title": "Sensitive / Regulated Data Spill Response", "family": "IRO", - "description": "Mechanisms exist to respond to sensitive/regulated data spills.", - "scf_question": "Does the organization respond to sensitive/regulated data spills?", + "description": "Mechanisms exist to respond to sensitive and/or regulated data spills.", + "scf_question": "Does the organization respond to sensitive and/or regulated data spills?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [ @@ -8063,7 +8356,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to respond to sensitive/regulated data spills.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8150,7 +8443,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -8194,10 +8488,12 @@ "IR-9" ], "general-nist-800-171-r3": [ + "03.01.22.b", "03.06.01" ], "general-nist-800-171a-r3": [ - "A.03.01.22.b[02]" + "A.03.01.22.b[02]", + "A.03.06.01[01]" ], "general-pci-dss-4-0-1": [ "12.10.7", @@ -8242,7 +8538,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "IR-09" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], "apac-nzl-ism-3-9": [ @@ -8256,7 +8552,15 @@ "7.3.8.C.02", "7.3.8.C.03" ], + "americas-bhs-dpa-2003": [ + "IV.28(3)(a)", + "IV.28(3)(b)", + "IV.28(3)(b)(i)", + "IV.28(3)(b)(ii)", + "IV.28(3)(b)(iii)" + ], "americas-can-itsp-10-171-2025": [ + "03.01.22.B", "03.06.01" ] } @@ -8265,8 +8569,8 @@ "control_id": "IRO-12.1", "title": "Sensitive / Regulated Data Spill Responsible Personnel", "family": "IRO", - "description": "Mechanisms exist to formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills.", - "scf_question": "Does the organization formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills?", + "description": "Mechanisms exist to formally assign personnel or roles with responsibility for responding to sensitive and/or regulated data spills.", + "scf_question": "Does the organization formally assign personnel or roles with responsibility for responding to sensitive and/or regulated data spills?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -8279,7 +8583,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to formally assign personnel or roles with responsibility for responding to sensitive/regulated data spills.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8363,7 +8667,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -8427,8 +8732,8 @@ "control_id": "IRO-12.2", "title": "Sensitive / Regulated Data Spill Training", "family": "IRO", - "description": "Mechanisms exist to ensure incident response training material provides coverage for sensitive/regulated data spillage response.", - "scf_question": "Does the organization ensure incident response training material provides coverage for sensitive/regulated data spillage response?", + "description": "Mechanisms exist to ensure incident response training material provides coverage for sensitive and/or regulated data spillage response.", + "scf_question": "Does the organization ensure incident response training material provides coverage for sensitive and/or regulated data spillage response?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8441,7 +8746,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to ensure incident response training material provides coverage for sensitive/regulated data spillage response.", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8509,7 +8814,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -8543,8 +8849,8 @@ "control_id": "IRO-12.3", "title": "Post-Sensitive / Regulated Data Spill Operations", "family": "IRO", - "description": "Mechanisms exist to ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", - "scf_question": "Does the organization ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions?", + "description": "Mechanisms exist to ensure that organizational personnel impacted by sensitive and/or regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", + "scf_question": "Does the organization ensure that organizational personnel impacted by sensitive and/or regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8557,7 +8863,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to ensure that organizational personnel impacted by sensitive/regulated data spills can continue to carry out assigned tasks while contaminated Technology Assets, Applications and/or Services (TAAS) are undergoing corrective actions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8641,7 +8947,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -8682,10 +8989,7 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-09(03)" ], - "emea-deu-c5-2020": [ - "OPS-21" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ] } @@ -8694,8 +8998,8 @@ "control_id": "IRO-12.4", "title": "Sensitive / Regulated Data Exposure to Unauthorized Personnel", "family": "IRO", - "description": "Mechanisms exist to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations.", - "scf_question": "Does the organization address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations?", + "description": "Mechanisms exist to address security safeguards for personnel exposed to sensitive and/or regulated data that is not within their assigned access authorizations.", + "scf_question": "Does the organization address security safeguards for personnel exposed to sensitive and/or regulated data that is not within their assigned access authorizations?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8708,9 +9012,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to address security safeguards for personnel exposed to sensitive/regulated data that is not within their assigned access authorizations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8793,7 +9097,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -8821,7 +9126,7 @@ "usa-federal-gsa-fedramp-5-high": [ "IR-09(04)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0133" ], "apac-nzl-ism-3-9": [ @@ -8850,9 +9155,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ Incident responders provide After Action Review (AAR) feedback on what worked, what did not work and ways to improve future responses to similar incidents.\n▪ A formal Root Cause Analysis (RCA) is performed that documents the findings in a report for both technical and business leadership management.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8940,7 +9245,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -9057,7 +9363,8 @@ "03.06.04.b" ], "general-nist-800-171a-r3": [ - "A.03.06.04.ODP[04]" + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" ], "general-nist-800-218": [ "RV.3" @@ -9115,6 +9422,9 @@ "IR-04(12)", "IR-06(02)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.635(c)(6)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(h)(7)" ], @@ -9164,14 +9474,20 @@ "3.6.3" ], "emea-deu-c5-2020": [ - "SIM-05" + "SIM-04" ], "emea-sau-cgiot-2024": [ "2-12-2", "2-12-3" ], + "emea-sau-otcc-1-2022": [ + "2-12-1-2" + ], "emea-sau-sacs-002-2022": [ - "TPC-89" + "VII.B.TPC-89" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.7" ], "emea-gbr-caf-4-0": [ "D2", @@ -9193,11 +9509,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4200" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1213" ], - "apac-aus-ps-cps-234-2019": [ - "25(a)" + "apac-aus-ps-cps-230-2023": [ + "32" ], "apac-ind-sebi-2024": [ "EV.ST.S3", @@ -9217,20 +9533,19 @@ "apac-sgp-mas-trm-2021": [ "7.8.1", "7.8.2", - "7.8.3", - "12.3.3" + "12.3.2" ], "americas-bmu-mba-coc-2020": [ "6.4" ], - "amaericas-can-osfi-self-assessment": [ - "5.9" - ], "americas-can-osfi-b13-2022": [ "2.7.3", "3.4", "3.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.3" + ], "americas-can-itsp-10-171-2025": [ "03.06.04.B" ] @@ -9254,9 +9569,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", - "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain incident response contacts with applicable regulatory and law enforcement agencies.", + "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to maintain incident response contacts with applicable regulatory and law enforcement agencies. ", "4": "Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9325,7 +9640,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -9405,6 +9721,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "IR-06" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.620(b)(3)" + ], "usa-federal-irs-1075-2021": [ "IR-6" ], @@ -9424,23 +9743,11 @@ "IR-06" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0140" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "2.1.10.C.01" - ], - "apac-sgp-pdpa-2012": [ - "11" - ], "americas-can-itsp-10-171-2025": [ "03.06.02.C" ] @@ -9464,7 +9771,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.\n▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.", "3": "Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:\n▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.\n▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).\n▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).\n▪ An implemented and operational capability exists to utilize a detonation chamber capability to detect and/or block potentially-malicious files and email attachments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9552,12 +9859,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.6", "9.7" ], @@ -9571,7 +9879,7 @@ "general-iso-21434-2021": [ "RC-05-15" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1137", "T1137.001", "T1137.002", @@ -9607,15 +9915,18 @@ "general-nist-800-160-vol-2-r1": [ "SC-44" ], + "general-nist-800-172-r3": [ + "03.13.14E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.14E" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EM.E3AEP", "3.PEP.EM.MFPRO", "3.PEP.EM.PDPRO", "3.PEP.FI.DCHAM" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" - ], "emea-gbr-def-stan-05-138-2024": [ "2411" ], @@ -9628,16 +9939,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0651", "ISM-0652", - "ISM-1389" + "ISM-1389", + "ISM-1970" ], "apac-jpn-ismap": [ "12.2.1.14" - ], - "apac-nzl-ism-3-9": [ - "15.2.21.C.01" ] } }, @@ -9735,7 +10044,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Incident Response", "crosswalks": { @@ -9755,18 +10065,13 @@ "248.30(a)(4)(i)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.5(91)" + "3.7.5.91" ], "emea-eu-nis2-2022": [ "Article 23.2" ], "apac-ind-sebi-2024": [ "RC.CO.S1" - ], - "apac-sgp-mas-trm-2021": [ - "7.7.5", - "7.7.6", - "7.7.7" ] } } diff --git a/docs/api/families/MDM.json b/docs/api/families/MDM.json index f46de718..d03b59fc 100644 --- a/docs/api/families/MDM.json +++ b/docs/api/families/MDM.json @@ -21,7 +21,7 @@ }, "maturity": { "0": "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.", - "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage.", + "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to implement and govern Mobile Device Management (MDM) controls.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -116,7 +116,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -160,7 +161,8 @@ "03.01.20.d" ], "general-nist-800-171a-r3": [ - "A.03.01.18.a[01]" + "A.03.01.18.a[01]", + "A.03.01.20.d" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -191,47 +193,34 @@ "usa-federal-irs-1075-2021": [ "3.3.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-isr-cmo-1-0": [ - "4.25", - "4.28", - "13.1", - "13.3", - "13.5", - "13.8", - "13.9", - "13.10" + "emea-deu-c5-2020": [ + "MDM-01", + "MDM-01-BP2", + "MDM-01-BP3", + "MDM-01-BP5", + "MDM-01-DOAR" ], "emea-sau-cscc-1-2019": [ - "2-5" + "2-5-1" ], "emea-sau-ecc-1-2018": [ - "2-6-3", - "2-6-3-1", - "2-6-3-2", - "2-6-3-3", - "2-6-3-4", - "2-6-4", - "5-1-3-6" + "2-6-1", + "2-6-2" ], "emea-sau-otcc-1-2022": [ - "2-5", "2-5-1", - "2-5-1-1", - "2-5-1-2", - "2-5-1-3", "2-5-1-4", - "2-5-1-5", "2-5-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.3.3 [MP.EQ.3]" + "emea-sau-sama-csf-1-2017": [ + "3.3.10" + ], + "emea-esp-decree-311-2022": [ + "Article 22(1)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], "emea-gbr-caf-4-0": [ "B3.d" @@ -251,7 +240,7 @@ "2309", "2322" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0682", "ISM-0687", "ISM-0863", @@ -263,33 +252,23 @@ "ISM-1366", "ISM-1533" ], + "apac-mys-bnm-rmit-2025": [ + "12.3" + ], "apac-nzl-ism-3-9": [ "21.1.10.C.01", "21.1.10.C.02", - "21.1.10.C.03", "21.1.11.C.01", - "21.1.11.C.02", "21.1.12.C.01", - "21.1.14.C.01", - "21.1.14.C.02", - "21.1.15.C.01", - "21.1.16.C.01", - "21.1.16.C.02", - "21.1.17.C.01", - "21.1.17.C.02", - "21.1.17.C.03", - "21.1.18.C.01", - "21.1.18.C.02", - "21.1.19.C.01", - "21.1.19.C.02" + "22.1.10.C.01", + "22.1.10.C.03", + "22.1.12.C.01", + "22.1.15.C.01", + "22.1.18.C.02" ], "americas-bmu-mba-coc-2020": [ "6.11" ], - "amaericas-can-osfi-self-assessment": [ - "4.14", - "4.15" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.01.20.D" @@ -314,9 +293,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict the connection of personally-owned, mobile devices to organizational TAASD.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce access control requirements for the connection of mobile devices to organizational Technology Assets, Applications and/or Services (TAAS).", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce access control requirements for the connection of mobile devices to organizational Technology Assets, Applications and/or Services (TAAS). ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -401,7 +380,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -429,7 +409,7 @@ "general-iso-27018-2025": [ "8.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1070.001", @@ -504,6 +484,7 @@ "3.1.18[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.18.a[02]", "A.03.01.18.b" ], "general-nist-800-207": [ @@ -552,23 +533,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-19" ], - "emea-isr-cmo-1-0": [ - "4.27", - "13.2", - "13.3", - "13.5", - "13.7", - "13.9" - ], "emea-sau-cscc-1-2019": [ "2-5-1-1" ], - "emea-sau-ecc-1-2018": [ - "2-6-3-2", - "5-1-3-6" + "emea-sau-otcc-1-2022": [ + "2-5-1-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", @@ -594,7 +567,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of information on mobile devices through full-device or container encryption.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -647,7 +620,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -718,10 +692,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-19 (05)" ], - "emea-isr-cmo-1-0": [ - "4.26", - "8.7", - "13.4" + "emea-deu-c5-2020": [ + "MDM-01-BP1" ], "emea-sau-cscc-1-2019": [ "2-5-1-2" @@ -729,6 +701,9 @@ "emea-sau-ecc-1-2018": [ "2-6-3-1" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-5" + ], "emea-gbr-def-stan-05-138-2024": [ "2309" ], @@ -738,15 +713,13 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2309" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0869" ], "apac-nzl-ism-3-9": [ "21.1.13.C.01", - "21.1.13.C.02", - "21.1.13.C.03", - "21.1.13.C.04", - "21.1.13.C.05" + "22.1.14.C.01", + "22.1.14.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.18.C" @@ -771,7 +744,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel protect mobile devices from tampering through inspecting devices returning from locations that the organization deems to be of significant risk, prior to the device being connected to the organization's network.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to protect mobile devices from tampering through inspecting devices returning from locations that the organization deems to be of significant risk, prior to the device being connected to the organization's network.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -842,7 +815,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -870,14 +844,14 @@ "general-nist-800-171-r3": [ "03.04.12.b" ], + "general-nist-800-171a-r3": [ + "A.03.04.12.b" + ], "general-shared-assessments-sig-2025": [ "M.1.3" ], - "emea-isr-cmo-1-0": [ - "13.9" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" + "emea-deu-c5-2020": [ + "MDM-01-BP4" ], "americas-can-itsp-10-171-2025": [ "03.04.12.B" @@ -902,11 +876,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ MDM software can remotely purge selected information from mobile devices.", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to remotely purge selected information from mobile devices.", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to remotely purge selected information from mobile devices. ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -971,7 +945,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -1020,22 +995,21 @@ "usa-federal-irs-1075-2021": [ "AC-7(CE-2)" ], - "emea-isr-cmo-1-0": [ - "13.8" - ], "emea-sau-ecc-1-2018": [ "2-6-3-3" ], + "emea-sau-otcc-1-2022": [ + "2-6-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-59" + "VII.B.TPC-59" ], - "apac-aus-ism-2024-june": [ - "ISM-0702" + "emea-esp-ccn-stic-825-2026": [ + "mp.eq.3", + "mp.eq.4" ], - "apac-nzl-ism-3-9": [ - "21.1.20.C.01", - "21.1.20.C.02", - "21.1.20.C.03" + "apac-aus-ism-2026-march": [ + "ISM-0702" ] } }, @@ -1057,9 +1031,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict the connection of personally-owned, mobile devices to organizational TAASD.\n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connection of personally-owned, mobile devices to organizational Technology Assets, Applications and/or Services (TAAS).", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connection of personally-owned, mobile devices to organizational Technology Assets, Applications and/or Services (TAAS). ", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1146,7 +1120,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -1160,6 +1135,10 @@ "03.01.18.a", "03.01.18.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.18.b" + ], "general-nist-800-207": [ "NIST Tenet 1" ], @@ -1169,20 +1148,19 @@ "usa-federal-dow-safeguarding-nnpi-2010": [ "9-3.d" ], - "emea-isr-cmo-1-0": [ - "13.3", - "13.5" - ], - "emea-sau-cscc-1-2019": [ - "2-5-1-1" + "emea-deu-c5-2020": [ + "MDM-01-BP6" ], "emea-sau-ecc-1-2018": [ "5-1-3-6" ], + "emea-sau-otcc-1-2022": [ + "2-5-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-84" + "VII.B.TPC-84" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0694", "ISM-1297", "ISM-1400", @@ -1194,9 +1172,6 @@ "apac-nzl-ism-3-9": [ "21.1.12.C.01" ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", "03.01.18.B" @@ -1221,7 +1196,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Mobile devices containing sensitive/regulated data use MDM software to prevent the unauthorized disclosure of information at rest (e.g., container encryption).\n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to prohibit the installation of non-approved applications or approved applications not obtained through the organization-approved application store.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1310,7 +1285,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -1325,24 +1301,23 @@ "03.01.18.b", "03.01.20.d" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.a[01]", + "A.03.01.18.b", + "A.03.01.20.d" + ], "general-nist-800-207": [ "NIST Tenet 1" ], "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.18" ], - "emea-isr-cmo-1-0": [ - "13.3", - "13.5" - ], "emea-sau-ecc-1-2018": [ "5-1-3-6" ], "emea-sau-otcc-1-2022": [ - "2-5-1-4" - ], - "apac-sgp-mas-trm-2021": [ - "14.1.7" + "2-5-1-1", + "2-5-1-3" ], "americas-can-itsp-10-171-2025": [ "03.01.18.A", @@ -1369,7 +1344,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are documented and maintained by process owners.\n▪ 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 MDM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ MDM-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ MDM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to limit data retention on mobile devices to the smallest usable dataset and timeframe.", "4": "Mobile Device Management (MDM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1410,7 +1385,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": {} @@ -1433,7 +1409,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the functionality of mobile devices based on geographic location.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1477,7 +1453,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -1510,9 +1487,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce a separate device workspace on applicable mobile devices to separate work-related and personal-related applications and data.", + "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to enforce a separate device workspace on applicable mobile devices to separate work-related and personal-related applications and data. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1578,7 +1555,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -1610,7 +1588,7 @@ }, "maturity": { "0": "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.", - "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. \n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).\n▪ MDM software is used to prevent the unauthorized disclosure of sensitive/regulated data (e.g., cryptographic containerization).", + "1": "Mobile Device Management (MDM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MDM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ MDM-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ MDM is mostly administrative in nature (e.g., policies & standards) that rely on administrative “acceptable use” restrictions to govern mobile device usage. \n▪ MDM software is used to restrict the data that is stored/processed/transmitted on organization-owned and/or applicable Bring Your Own Device (BYOD) (e.g., personal devices).\n▪ MDM software is used to prevent the unauthorized disclosure of sensitive/regulated data (e.g., cryptographic containerization). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Mobile Device Management (MDM) 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:\n▪ Policies and standards associated with MDM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MDM domain capabilities are well-documented and kept current by process owners.\n▪ An endpoint technology management team, or similar function, is appropriately staffed and supported to implement and maintain MDM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of mobile device security operations (e.g., Mobile Device Management (MDM) solution, etc.).\n▪ 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 MDM 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).\n▪ An implemented and operational capability exists to restrict the connectivity of unauthorized mobile devices from communicating with organizational Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1677,7 +1655,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Mobile Device Management", "crosswalks": { @@ -1689,15 +1668,15 @@ "general-nist-800-171-r3": [ "03.01.18.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.18.b" + ], "general-shared-assessments-sig-2025": [ "M.1.2" ], "emea-sau-cscc-1-2019": [ "2-5-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-84" - ], "americas-can-itsp-10-171-2025": [ "03.01.18.B" ] diff --git a/docs/api/families/MNT.json b/docs/api/families/MNT.json index bc19006d..3eb7b002 100644 --- a/docs/api/families/MNT.json +++ b/docs/api/families/MNT.json @@ -122,7 +122,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -211,6 +212,12 @@ "03.07.04.a", "03.07.06.a" ], + "general-nist-800-171a-r3": [ + "A.03.04.03.c[01]", + "A.03.07.04.a[01]", + "A.03.07.04.a[02]", + "A.03.07.06.a" + ], "general-nist-csf-2-0": [ "PR.PS", "PR.PS-02", @@ -241,12 +248,12 @@ "MA-01" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iv)", - "164.310(d)(1)" + "§ 164.310(a)(2)(iv)", + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MA-1" @@ -269,28 +276,14 @@ "emea-eu-nis2-annex-2024": [ "4.3.2(c)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-78" + "emea-deu-c5-2020": [ + "PS-05" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.4 [OP.EXP.4]" - ], - "apac-aus-ism-2024-june": [ - "ISM-0305", - "ISM-1226" + "apac-aus-ism-2026-march": [ + "ISM-0305" ], "apac-jpn-ismap": [ "11.2.4", @@ -298,7 +291,10 @@ "11.2.4.3", "11.2.4.5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.26" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP15", "HML15" ], @@ -323,7 +319,7 @@ "title": "Controlled Maintenance", "family": "MNT", "description": "Mechanisms exist to conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).", - "scf_question": "Does the organization conduct controlled maintenance activities throughout the lifecycle of theTechnology Asset, Application and/or Service (TAAS)?", + "scf_question": "Does the organization conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -338,7 +334,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset custodians track maintenance activities and component failure rates.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to conduct controlled maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -429,7 +425,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -499,7 +496,9 @@ "3.7.1" ], "general-nist-800-171a-r3": [ - "A.03.04.03.c[01]" + "A.03.04.03.c[01]", + "A.03.07.04.a[02]", + "A.03.07.05.a[01]" ], "general-nist-csf-2-0": [ "PR.PS", @@ -525,10 +524,10 @@ "MA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iv)" + "§ 164.310(a)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "MA-2" @@ -552,8 +551,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-02" ], - "emea-sau-sacs-002-2022": [ - "TPC-78" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" ], "emea-gbr-def-stan-05-138-2024": [ "2511" @@ -567,7 +566,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2511" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1079" ], "apac-ind-sebi-2024": [ @@ -576,7 +575,12 @@ "apac-jpn-ismap": [ "11.2.4.4" ], + "apac-mys-bnm-rmit-2025": [ + "10.26" + ], "apac-nzl-ism-3-9": [ + "11.8.10.C.01", + "11.8.10.C.04", "12.5.3.C.01", "12.5.3.C.02", "12.5.6.C.01", @@ -691,7 +695,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -747,7 +752,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to obtain maintenance support and/or spare parts for Technology Assets, Applications and/or Services (TAAS) within a defined Recovery Time Objective (RTO).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -836,7 +841,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -891,6 +897,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-nist-csf-2-0": [ "PR.PS-02", "PR.PS-03" @@ -917,6 +926,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-06" ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.4" + ], "emea-gbr-def-stan-05-138-2024": [ "2511" ], @@ -954,11 +966,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset custodians track maintenance activities and component failure rates.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to perform preventive maintenance on critical Technology Assets, Applications and/or Services (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -1042,7 +1054,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -1061,6 +1074,9 @@ "general-nist-800-171-r3": [ "03.07.04.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], "general-nist-csf-2-0": [ "PR.PS-02", "PR.PS-03" @@ -1088,11 +1104,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to perform predictive maintenance on critical Technology Assets, Applications and/or Services (TAAS).", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -1162,7 +1178,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -1195,7 +1212,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to automatically transfer predictive maintenance data to a computerized maintenance management system.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1268,7 +1285,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -1304,9 +1322,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to control and monitor the use of system maintenance tools.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to control and monitor the use of system maintenance tools. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1390,7 +1408,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -1466,6 +1485,12 @@ "A.03.07.04.a[02]", "A.03.07.04.a[03]" ], + "general-nist-800-172-r3": [ + "03.07.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.07.01E" + ], "usa-federal-fbi-cjis-6-0": [ "MA-3" ], @@ -1511,9 +1536,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.\n▪ IT and/or cybersecurity personnel inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1596,7 +1621,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -1639,6 +1665,9 @@ "general-nist-800-171-r3": [ "03.07.04.b" ], + "general-nist-800-171a-r3": [ + "A.03.07.04.b" + ], "usa-federal-fbi-cjis-6-0": [ "MA-3(1)" ], @@ -1682,9 +1711,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.\n▪ IT and/or cybersecurity personnel inspect maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to check media containing diagnostic and test programs for malicious code before the media are used.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to check media containing diagnostic and test programs for malicious code before the media are used. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1764,7 +1793,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -1863,7 +1893,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners prevent or control the removal of equipment undergoing maintenance that contains organizational information.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to prevent or control the removal of equipment undergoing maintenance that contains organizational information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1942,7 +1972,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -2001,10 +2032,10 @@ "MA-03(03)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(d)(1)" + "§ 164.310(d)(1)" ], "usa-federal-irs-1075-2021": [ "MA-3(CE-3)", @@ -2030,6 +2061,9 @@ "11.2.5.3", "11.2.5.4" ], + "apac-nzl-ism-3-9": [ + "11.8.10.C.02" + ], "americas-can-itsp-10-171-2025": [ "03.07.04.C" ] @@ -2057,7 +2091,7 @@ "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel control and monitor the use of system maintenance tools.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to automatically restrict the use of maintenance tools to authorized maintenance personnel and/or roles.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -2133,7 +2167,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -2178,11 +2213,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Instances of non-console administrative access use cryptographic mechanisms to protect the confidentiality and integrity of the data being transmitted.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to authorize, monitor and control remote, non-local maintenance and diagnostic activities.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -2266,7 +2301,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -2353,8 +2389,11 @@ "3.7.5[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.12.d[1]", "A.03.07.05.a[01]", - "A.03.07.05.a[02]" + "A.03.07.05.a[02]", + "A.03.07.05.b[01]", + "A.03.07.05.c[01]" ], "general-pci-dss-4-0-1": [ "8.2.7" @@ -2415,16 +2454,6 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(h)" ], - "emea-isr-cmo-1-0": [ - "4.18", - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-2-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" - ], "emea-gbr-def-stan-05-138-2024": [ "2512" ], @@ -2471,9 +2500,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to audit remote, non-local maintenance and diagnostic sessions, as well as review the maintenance action performed during remote maintenance sessions.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to audit remote, non-local maintenance and diagnostic sessions, as well as review the maintenance action performed during remote maintenance sessions. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2543,7 +2572,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -2628,6 +2658,9 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[02]" + ], "general-pci-dss-4-0-1": [ "8.2.7" ], @@ -2692,9 +2725,6 @@ "MA-01", "MA-04" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], "apac-jpn-ismap": [ "11.2.4.7" ], @@ -2721,7 +2751,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners require maintenance personnel to notify entity-defined personnel when non-local maintenance is planned (e.g., date/time).", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require maintenance personnel to notify affected stakeholders when remote, non-local maintenance is planned (e.g., date/time).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2792,7 +2822,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -2912,9 +2943,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-01", "MA-04" - ], - "emea-isr-cmo-1-0": [ - "12.7" ] } }, @@ -2936,9 +2964,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", - "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity and confidentiality of remote, non-local maintenance and diagnostic communications.", + "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational cryptographic capability exists to protect the integrity and confidentiality of remote, non-local maintenance and diagnostic communications. ", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2993,7 +3021,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -3025,7 +3054,7 @@ "03.07.05.b" ], "general-nist-800-171a-r3": [ - "A.03.07.05.b[02]" + "A.03.07.05.b[01]" ], "general-pci-dss-4-0-1": [ "2.2.7" @@ -3054,10 +3083,6 @@ "usa-federal-irs-1075-2021": [ "MA-4(CE-6)" ], - "emea-isr-cmo-1-0": [ - "4.20", - "12.7" - ], "americas-can-itsp-10-171-2025": [ "03.07.05.B" ] @@ -3081,7 +3106,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT and/or cybersecurity personnel provide remote disconnect verification to ensure non-local maintenance and diagnostic sessions are properly terminated.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to provide remote disconnect verification to ensure remote, non-local maintenance and diagnostic sessions are properly terminated.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3149,7 +3174,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -3195,11 +3221,6 @@ "usa-federal-irs-1075-2021": [ "MA-4(CE-7)" ], - "emea-isr-cmo-1-0": [ - "4.18", - "4.20", - "12.7" - ], "apac-jpn-ismap": [ "11.2.4.11" ], @@ -3226,7 +3247,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require maintenance personnel to obtain pre-approval and scheduling for remote, non-local maintenance sessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3295,7 +3316,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -3311,12 +3333,12 @@ "general-nist-800-171-r3": [ "03.07.05.a" ], + "general-nist-800-171a-r3": [ + "A.03.07.05.a[01]" + ], "usa-federal-nerc-cip-2024": [ "CIP-005-7 3.1" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], "apac-ind-sebi-2024": [ "PR.MA.S2" ], @@ -3346,7 +3368,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to require Technology Assets, Applications and/or Services (TAAS) performing remote, non-local maintenance and/or diagnostic services implement a security capability comparable to the capability implemented on the system being serviced.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3413,7 +3435,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -3540,7 +3563,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -3583,7 +3607,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ IT personnel, in conjunction with asset custodians, maintain a current list of authorized maintenance organizations or personnel.\n▪ Asset / process owners require maintenance personnel to obtain pre-approval and scheduling for non-local maintenance sessions.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to maintain a current list of authorized maintenance organizations or personnel.", "4": "Maintenance (MNT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3672,7 +3696,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -3740,8 +3765,7 @@ "A.03.07.06.a", "A.03.07.06.b", "A.03.07.06.c", - "A.03.07.06.d[01]", - "A.03.07.06.d[02]" + "A.03.07.06.d[01]" ], "usa-federal-fbi-cjis-6-0": [ "MA-5" @@ -3779,13 +3803,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "MA-05" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0305", "ISM-0307" ], @@ -3908,7 +3926,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -3961,12 +3980,13 @@ "3.7.6" ], "general-nist-800-171-r3": [ - "03.07.06.a", "03.07.06.c", "03.07.06.d" ], "general-nist-800-171a-r3": [ - "A.03.07.06.c" + "A.03.07.06.c", + "A.03.07.06.d[01]", + "A.03.07.06.d[02]" ], "usa-federal-dow-cmmc-2-level-2": [ "MAL2.-3.7.6" @@ -3977,11 +3997,8 @@ "usa-federal-gsa-fedramp-5-high": [ "MA-05(01)" ], - "emea-isr-cmo-1-0": [ - "12.7" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" ], "emea-gbr-def-stan-05-138-2024": [ "2513" @@ -3995,7 +4012,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2513" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0306" ], "apac-nzl-ism-3-9": [ @@ -4005,7 +4022,6 @@ "12.5.4.C.04" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A", "03.07.06.C", "03.07.06.D" ] @@ -4029,7 +4045,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.\n▪ Asset / process owners require maintenance personnel to obtain pre-approval and scheduling for non-local maintenance sessions.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to ensure that non-escorted personnel performing non-IT maintenance activities in the physical proximity of systems have required access authorizations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4102,7 +4118,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -4119,7 +4136,6 @@ "3.7.6" ], "general-nist-800-171-r3": [ - "03.07.06.a", "03.07.06.c" ], "general-nist-800-171a-r3": [ @@ -4128,11 +4144,13 @@ "usa-federal-dow-cmmc-2-level-2": [ "MAL2.-3.7.6" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" + ], "usa-federal-irs-1075-2021": [ "MA-5(CE-5)" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A", "03.07.06.C" ] } @@ -4155,7 +4173,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to maintain proper physical security and configuration control over technology assets awaiting service or repair.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4241,7 +4259,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -4310,7 +4329,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to securely conduct field maintenance on geographically deployed assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4392,7 +4411,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { @@ -4417,7 +4437,7 @@ "general-nist-800-161-r1-level-3": [ "MA-7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0305" ], "apac-nzl-ism-3-9": [ @@ -4443,7 +4463,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to ensure off-site maintenance activities are conducted securely and the asset(s) undergoing maintenance actions are secured during physical transfer and storage while off-site.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4529,14 +4549,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { "general-nist-800-171-r3": [ "03.07.04.a" ], - "apac-aus-ism-2024-june": [ + "general-nist-800-171a-r3": [ + "A.03.07.04.a[02]" + ], + "apac-aus-ism-2026-march": [ "ISM-0310" ], "apac-jpn-ismap": [ @@ -4574,7 +4598,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities are documented and maintained by process owners.\n▪ 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS).\n▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution.", "3": "Maintenance (MNT) 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:\n▪ Policies and standards associated with MNT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners.\n▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities.\n▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance operations.\n▪ 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 MNT 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).\n▪ An implemented and operational capability exists to validate:\n(1) Maintenance activities were appropriately performed according to the work order; and \n(2) Applicable security, compliance and resilience controls are operational.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4657,12 +4681,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Maintenance", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1598" ], "apac-jpn-ismap": [ @@ -4753,7 +4777,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Maintenance", "crosswalks": { diff --git a/docs/api/families/MON.json b/docs/api/families/MON.json index 79c0a48d..88d37d05 100644 --- a/docs/api/families/MON.json +++ b/docs/api/families/MON.json @@ -104,7 +104,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -116,9 +117,9 @@ "CC7.2-POF1" ], "general-cis-csc-8-1": [ - "8.0", + "8", "8.2", - "13.0", + "13", "13.6" ], "general-cis-csc-8-1-ig1": [ @@ -187,7 +188,7 @@ "8.15", "8.16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -660,16 +661,16 @@ "general-nist-800-171-r3": [ "03.03.01.a", "03.12.03", - "03.14.06.a" + "03.14.06.a", + "03.14.06.a.02" ], "general-nist-800-171a-r3": [ + "A.03.03.01.a", + "A.03.12.03[01]", "A.03.14.06.a.01[01]", "A.03.14.06.a.01[02]", "A.03.14.06.a.02" ], - "general-nist-800-172": [ - "3.14.2e" - ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 6", @@ -714,9 +715,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-sparta": [ "CM0090" ], @@ -808,18 +806,22 @@ "AU-01", "SI-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)", + "101.650(f)(3)" + ], "usa-federal-hhs-45-cfr-155-260-2016": [ "155.260(a)(3)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(i)", - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(i)", + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-1", @@ -873,9 +875,8 @@ "SI-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" + "3.4.5.39", + "3.5.52" ], "emea-eu-dora-2023": [ "Article 10.3" @@ -887,72 +888,46 @@ "3.2.6", "13.1.2(f)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "5.5", - "6.3", - "6.7" - ], "emea-deu-c5-2020": [ - "OPS-10" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" + "RB-10" ], "emea-sau-cscc-1-2019": [ - "2-11" + "2-11-1" ], "emea-sau-cgiot-2024": [ "2-11-1" ], "emea-sau-ecc-1-2018": [ - "2-3-4", "2-12-1", "2-12-2", - "2-12-3", - "2-12-4", "5-1-3-3" ], "emea-sau-otcc-1-2022": [ - "2-11", "2-11-1", + "2-11-1-10", "2-11-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-40", - "TPC-80" - ], "emea-sau-sama-csf-1-2017": [ - "3.3.14" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1", - "Article 21.2", - "Article 24.1" + "3.3.14", + "3.3.14.1", + "3.3.14.3", + "3.3.14.4", + "3.3.14.4.a", + "3.3.14.4.b", + "3.3.14.4.c", + "3.3.14.4.d", + "3.3.14.4.e", + "3.3.14.4.f", + "3.3.14.4.g" ], "emea-esp-decree-311-2022": [ - "10.1", - "21.2", - "24.1" + "Article 8(3)", + "Article 12(6)(l)", + "Article 24(1)", + "Article 24(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1" @@ -987,7 +962,7 @@ "3102", "3106" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-0120", "ISM-0580", @@ -996,6 +971,12 @@ "ISM-1294", "ISM-1586" ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], + "apac-chn-data-security-law-2021": [ + "Article 29" + ], "apac-ind-sebi-2024": [ "DE.CM.S2", "PR.AA.S8" @@ -1005,12 +986,14 @@ "12.4.1", "12.4.1.15.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ - "HHSP70", - "HML70" + "apac-mys-bnm-rmit-2025": [ + "10.57", + "11.9", + "12.3" ], "apac-nzl-hisf-microsmall-2023": [ - "HMS18" + "HHSP70", + "HML70" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP61" @@ -1023,25 +1006,25 @@ "16.6.10.C.02" ], "apac-sgp-mas-trm-2021": [ - "12.2.1", - "12.2.2", - "12.2.3" + "6.4.7", + "12.2.1" ], "americas-bmu-mba-coc-2020": [ "6.21" ], - "amaericas-can-osfi-self-assessment": [ - "3.5" - ], "americas-can-osfi-b13-2022": [ "3.3", "3.3.1", "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" + ], "americas-can-itsp-10-171-2025": [ "03.03.01.A", "03.12.03", - "03.14.06.A" + "03.14.06.A", + "03.14.06.A.02" ] } }, @@ -1067,7 +1050,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement Intrusion Detection / Prevention Systems (IDS / IPS) technologies on critical systems, key network segments and network choke points.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1137,7 +1120,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -1191,8 +1175,8 @@ "general-nist-800-171-r3": [ "03.13.01.a" ], - "general-nist-800-172": [ - "3.14.6e" + "general-nist-800-171a-r3": [ + "A.03.13.01.a[01]" ], "general-nist-csf-2-0": [ "DE.CM-01" @@ -1271,18 +1255,6 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(8)(A)" ], - "emea-isr-cmo-1-0": [ - "7.4", - "11.11", - "12.18", - "23.6" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-6" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", "16.6.10.C.02", @@ -1301,11 +1273,6 @@ "18.4.12.C.01", "18.4.14.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "3.3", - "4.3", - "4.4" - ], "americas-can-osfi-b13-2022": [ "3.3.2" ], @@ -1335,9 +1302,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support near real-time analysis and incident escalation.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support near real-time analysis and incident escalation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1404,7 +1371,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -1543,19 +1511,12 @@ "500.14(b)(2)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)" + "3.4.5.38", + "3.4.5.39" ], "emea-eu-nis2-annex-2024": [ "3.2.2" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "11.11", - "12.31" - ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" @@ -1565,10 +1526,15 @@ ], "emea-sau-ecc-1-2018": [ "2-12-3-3", + "2-12-3-4", "5-1-3-3" ], + "emea-sau-otcc-1-2022": [ + "2-11-1-3" + ], "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "3.3.14.4.j", + "3.3.14.4.k" ], "emea-gbr-def-stan-05-138-2024": [ "3102" @@ -1576,14 +1542,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3102" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS19" + "apac-nzl-ism-3-9": [ + "16.6.15.C.01", + "16.6.15.C.02" ], - "amaericas-can-osfi-self-assessment": [ - "3.4" + "apac-sgp-mas-trm-2021": [ + "6.4.7", + "7.7.4", + "12.2.2" ], "americas-can-osfi-b13-2022": [ "3.3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" ] } }, @@ -1679,7 +1651,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -1752,8 +1725,8 @@ "general-nist-800-171a-r3": [ "A.03.13.01.a[01]", "A.03.13.01.a[03]", - "A.03.14.06.c[01]", - "A.03.14.06.c[02]" + "A.03.14.06.b", + "A.03.14.06.c[01]" ], "general-nist-csf-2-0": [ "DE.CM-01" @@ -1789,6 +1762,10 @@ "usa-federal-gsa-fedramp-5-high": [ "SI-04(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(3)", + "101.650(h)(2)" + ], "usa-federal-irs-1075-2021": [ "SI-4(CE-4)", "SI-4(CE-4).a", @@ -1810,15 +1787,13 @@ "emea-eu-nis2-annex-2024": [ "3.2.3(a)" ], - "emea-isr-cmo-1-0": [ - "9.9", - "9.10", - "10.9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-40" + "apac-aus-ism-2026-march": [ + "ISM-1906", + "ISM-1907", + "ISM-2015" ], "apac-nzl-ism-3-9": [ + "15.2.40.C.02", "16.6.10.C.01", "16.6.10.C.02", "18.4.8.C.01", @@ -1854,9 +1829,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to generate, monitor, correlate and respond to alerts from physical, cybersecurity, data protection and supply chain activities to achieve integrated situational awareness.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to generate, monitor, correlate and respond to alerts from physical, cybersecurity, data protection and supply chain activities to achieve integrated situational awareness. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1926,7 +1901,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -2022,8 +1998,17 @@ "03.14.06.c" ], "general-nist-800-171a-r3": [ - "A.03.03.02.a.01", - "A.03.03.03.a" + "A.03.03.01.a", + "A.03.03.03.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.b" + ], + "general-nist-800-172-r3": [ + "03.14.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.17E" ], "general-nist-800-207": [ "NIST Tenet 7" @@ -2110,11 +2095,15 @@ "usa-federal-gsa-fedramp-5-high": [ "SI-04(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)", + "101.650(h)(2)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "SI-4(CE-5)" @@ -2139,25 +2128,18 @@ "emea-eu-ai-act-2024": [ "Article 12.1" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "21.2", - "21.4" - ], "emea-sau-cscc-1-2019": [ "2-11-1-1" ], "emea-sau-ecc-1-2018": [ - "2-12-3-1" + "2-12-3-1", + "2-12-3-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-80", - "TPC-87" + "emea-sau-otcc-1-2022": [ + "2-11-1-1" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.a", @@ -2172,15 +2154,29 @@ "emea-gbr-def-stan-05-138-l2-2024": [ "3101" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-aus-ism-2026-march": [ + "ISM-1959" + ], + "apac-aus-cop-sitc-2020": [ + "7" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP69", "HML68" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP60" ], - "amaericas-can-osfi-self-assessment": [ - "3.6" + "americas-arg-ppd-2018": [ + "B.2.3-3", + "B.2.3-4", + "B.2.5-DS-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP6" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.7" ], "americas-can-itsp-10-171-2025": [ "03.03.01.A", @@ -2292,9 +2288,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Continuous Monitoring", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -2331,6 +2327,14 @@ "general-nist-800-82-r3-high": [ "SI-04(14)" ], + "general-nist-800-172-r3": [ + "03.14.19E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.19E[01]", + "DS-A.03.14.19E[02]", + "DS-A.03.14.19E[03]" + ], "general-pci-dss-4-0-1": [ "11.2" ], @@ -2343,9 +2347,6 @@ "usa-federal-cms-marse-2-0": [ "SI-4(14)" ], - "emea-isr-cmo-1-0": [ - "7.6" - ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", "16.6.10.C.02", @@ -2437,7 +2438,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -2492,7 +2494,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a File Integrity Monitor (FIM), or similar change-detection technology, on critical Technology Assets, Applications and/or Services (TAAS) to generate alerts for unauthorized modifications.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a File Integrity Monitor (FIM), or similar change-detection technology, on critical Technology Assets, Applications and/or Services (TAAS) to generate alerts for unauthorized modifications. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2560,7 +2562,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -2608,6 +2611,13 @@ "general-nist-800-160-vol-2-r1": [ "SI-04(24)" ], + "general-nist-800-172-r3": [ + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.01E.a[03]", + "A.03.14.01E.ODP[03]" + ], "general-nist-csf-2-0": [ "DE.CM-09" ], @@ -2669,23 +2679,16 @@ "SI-04(24)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "SI-4(CE-24)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(e)" - ], - "emea-isr-cmo-1-0": [ - "6.4", - "12.19" - ], - "emea-sau-otcc-1-2022": [ - "1-5-4" + "3.4.4.36(e)" ], "apac-nzl-ism-3-9": [ "16.6.10.C.01", @@ -2787,7 +2790,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -2904,7 +2908,6 @@ "3.14.3" ], "general-nist-800-171-r3": [ - "03.03.01.b", "03.03.05.a" ], "general-nist-800-171a": [ @@ -2917,10 +2920,24 @@ ], "general-nist-800-171a-r3": [ "A.03.03.01.ODP[02]", - "A.03.03.01.b[01]", "A.03.03.05.ODP[01]", "A.03.03.05.a" ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.11.09E", + "03.14.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.b", + "DS-A.03.11.09E[03]", + "DS-A.03.14.01E.b[01]", + "A.03.14.01E.ODP[04]", + "DS-A.03.14.01E.b[02]", + "A.03.14.01E.ODP[05]", + "DS-A.03.14.01E.b[03]", + "A.03.14.01E.ODP[06]" + ], "general-nist-csf-2-0": [ "DE.CM-01", "DE.AE", @@ -2999,13 +3016,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(1)(ii)(D)", - "164.312(b)" + "§ 164.308(a)(1)(ii)(D)", + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-2" @@ -3060,21 +3080,12 @@ "2447(b)(2)(C)", "2447(c)(4)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)" - ], "emea-eu-nis2-annex-2024": [ "3.2.3", "3.2.4" ], "emea-deu-bsrit-2017": [ - "5.5" - ], - "emea-isr-cmo-1-0": [ - "12.31", - "21.3", - "21.11" + "6.7" ], "emea-sau-cscc-1-2019": [ "2-11-1-2" @@ -3082,19 +3093,12 @@ "emea-sau-cgiot-2024": [ "2-11-1" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-40" + "emea-sau-otcc-1-2022": [ + "2-11-1-4" ], "emea-gbr-caf-4-0": [ "C1.a" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "emea-gbr-def-stan-05-138-2024": [ "3101", "3102" @@ -3108,7 +3112,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3102" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109" ], "apac-ind-sebi-2024": [ @@ -3124,16 +3128,21 @@ "12.4.5.5.P" ], "apac-sgp-mas-trm-2021": [ - "12.2.2" + "12.2.6" + ], + "americas-arg-ppd-2018": [ + "B.2.5-DS-3" ], - "amaericas-can-osfi-self-assessment": [ - "3.5" + "americas-bmu-mba-coc-2020": [ + "6.21-BP5" ], "americas-can-osfi-b13-2022": [ "3.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.3" + ], "americas-can-itsp-10-171-2025": [ - "03.03.01.B", "03.03.05.A" ] } @@ -3158,7 +3167,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.\n▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to log all Internet-bound requests, in order to identify prohibited activities and assist incident handlers with identifying potentially compromised systems.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to log all Internet-bound requests, in order to identify prohibited activities and assist incident handlers with identifying potentially compromised systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3224,15 +3233,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { - "emea-isr-cmo-1-0": [ - "9.14", - "21.20" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0261" ], "apac-nzl-ism-3-9": [ @@ -3260,7 +3266,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor deactivated accounts for attempted usage.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3330,7 +3336,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -3347,7 +3354,7 @@ "title": "Automated Response to Suspicious Events", "family": "MON", "description": "Automated mechanisms exist to implement pre-determined corrective actions in response to detected events that have security incident implications.", - "scf_question": "Does the organization automatically implement pre-determined corrective actions in response to detected events that have security incident implications?", + "scf_question": "Does the organization use automated mechanisms to implement pre-determined corrective actions in response to detected events that have security incident implications?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -3360,11 +3367,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically implement pre-determined corrective actions in response to detected events that have security incident implications.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -3424,7 +3431,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -3488,7 +3496,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically alert incident response personnel to inappropriate or anomalous activities that have potential security incident implications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3557,7 +3565,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -3592,6 +3601,15 @@ "general-nist-800-171a-r3": [ "A.03.03.05.b" ], + "general-nist-800-172-r3": [ + "03.14.17E", + "03.14.18E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.17E", + "DS-A.03.14.18E", + "A.03.14.18E.ODP[02]" + ], "general-nist-csf-2-0": [ "DE.AE", "DE.AE-06" @@ -3617,10 +3635,7 @@ "usa-federal-irs-1075-2021": [ "SI-4(CE-12)" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-1" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP69", "HML68" ], @@ -3651,11 +3666,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to \"tune\" event monitoring technologies through analyzing communications traffic/event patterns and developing profiles representing common traffic patterns and/or events.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -3720,7 +3735,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -3775,11 +3791,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for individuals who have been identified as posing an increased level of risk.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for individuals who have been identified as posing an increased level of risk. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -3844,7 +3860,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -3874,12 +3891,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SI-04(19)" - ], - "emea-deu-bsrit-2017": [ - "6.7" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" ] } }, @@ -3903,11 +3914,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to implement enhanced activity monitoring for privileged users.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -3977,7 +3988,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -4019,26 +4031,23 @@ "general-nist-800-171-r3": [ "03.01.07.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.07.b" + ], "usa-federal-gsa-fedramp-5-high": [ "SI-04(20)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(c)(2)" + "§ 164.312(c)(2)" ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.7(c)" ], - "emea-deu-bsrit-2017": [ - "6.7" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" - ], "emea-sau-sacs-002-2022": [ - "TPC-83" + "VII.B.TPC-83" ], "emea-gbr-def-stan-05-138-2024": [ "2203" @@ -4049,6 +4058,12 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2203" ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" + ], + "americas-arg-ppd-2018": [ + "B.2.1-3" + ], "americas-can-itsp-10-171-2025": [ "03.01.07.B" ] @@ -4059,7 +4074,7 @@ "title": "Analyze and Prioritize Monitoring Requirements", "family": "MON", "description": "Mechanisms exist to assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes.", - "scf_question": "Does the organization assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes?", + "scf_question": "Does the organization assess its needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [ @@ -4074,7 +4089,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to assess the organization's needs for monitoring and prioritize the monitoring of Technology Assets, Applications and/or Services (TAAS), based on TAAS criticality and the sensitivity of the data it stores, transmits and processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4152,9 +4167,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed\n- NIST 800-171A", "family_name": "Continuous Monitoring", "crosswalks": { "general-csa-iot-2": [ @@ -4191,83 +4206,23 @@ "11.10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.3.a", "III.D.3.b" ], - "emea-eu-eba-ict-srm-2025": [ - "3.4.5(39)", - "3.4.5(40)", - "3.5(52)" - ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "5.5", - "6.3", "6.7" ], - "emea-deu-c5-2020": [ - "OPS-10" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "6.8", - "9.10", - "11.11", - "12.31", - "13.9", - "21.1" - ], - "emea-sau-cscc-1-2019": [ - "2-11" - ], - "emea-sau-ecc-1-2018": [ - "2-3-4", - "2-12-1", - "2-12-2", - "2-12-3", - "2-12-4", - "5-1-3-3" - ], "emea-sau-otcc-1-2022": [ - "2-11", - "2-11-1", - "2-11-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-40", - "TPC-80" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" - ], - "emea-zaf-popia-2013": [ - "19.1", - "19.2" - ], - "emea-esp-decree-311-2022": [ - "10.1", - "21.2", - "24.1" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" - ], - "emea-gbr-cap-1850-2020": [ - "C1" + "2-11-1-9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-0120", "ISM-0580", @@ -4282,17 +4237,6 @@ "16.6.8.C.01", "16.6.10.C.01", "16.6.10.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "12.2.1", - "12.2.2", - "12.2.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], - "amaericas-can-osfi-self-assessment": [ - "3.5" ] } }, @@ -4314,7 +4258,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to enable authorized personnel the ability to remotely view and hear content related to an established user session in real time, in accordance with organizational standards, as well as statutory, regulatory and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4380,7 +4324,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -4397,7 +4342,7 @@ "title": "Centralized Collection of Security Event Logs", "family": "MON", "description": "Mechanisms exist to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs.", - "scf_question": "Does the organization utilize a Security Incident Event Manager (SIEM) or similar automated tool, to support the centralized collection of security-related event logs?", + "scf_question": "Does the organization utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -4413,7 +4358,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a Security Incident Event Manager (SIEM), or similar automated tool, to support the centralized collection of security-related event logs.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4498,7 +4443,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -4730,10 +4676,6 @@ "10.4.1", "10.4.1.1" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.13" - ], "general-swift-cscf-2025": [ "6.1", "6.2", @@ -4839,48 +4781,50 @@ "SI-04" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" + "3.4.5.38", + "3.4.5.39", + "3.5.52" ], "emea-eu-nis2-annex-2024": [ "3.2.6" ], "emea-deu-c5-2020": [ - "OPS-14" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.3", - "21.4", - "21.6", - "21.12" + "RB-10", + "RB-13", + "RB-16-DOAR", + "SIM-05" ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" ], "emea-sau-otcc-1-2022": [ - "2-11-1-3", - "2-11-1-9" - ], - "emea-sau-sacs-002-2022": [ - "TPC-81" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "2-11-1-5", + "2-11-1-6", + "2-11-1-7", + "2-11-1-8" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0109", "ISM-1228", "ISM-1405", "ISM-1536", "ISM-1537", "ISM-1566", - "ISM-1650" + "ISM-1650", + "ISM-1911", + "ISM-1960", + "ISM-1963", + "ISM-1976", + "ISM-1977", + "ISM-1978", + "ISM-1979", + "ISM-1983", + "ISM-1986", + "ISM-1987" ], "apac-nzl-ism-3-9": [ "16.6.11.C.01", @@ -4890,18 +4834,13 @@ "16.6.12.C.02", "16.6.12.C.03" ], - "apac-sgp-mas-trm-2021": [ - "9.1.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], - "amaericas-can-osfi-self-assessment": [ - "3.2" - ], "americas-can-osfi-b13-2022": [ "3.3.1" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1", + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.03.05.A", "03.03.05.C" @@ -4929,7 +4868,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of vulnerability scanning activities and associated administrator accounts are reviewed to ensure that those activities are limited to the timeframes of legitimate scans.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate both technical and non-technical information from across the enterprise by a Security Incident Event Manager (SIEM) or similar automated tool, to enhance organization-wide situational awareness.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5014,7 +4953,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -5119,6 +5059,7 @@ "3.14.7[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.05.a", "A.03.03.05.c[02]" ], "general-nist-800-207": [ @@ -5150,9 +5091,6 @@ "10.4.1.1", "12.10.5" ], - "general-scf-dpmp-2025": [ - "7.13" - ], "general-tisax-6-0-3": [ "5.2.4" ], @@ -5207,37 +5145,30 @@ "usa-federal-cms-marse-2-0": [ "AU-6(3)" ], - "emea-deu-c5-2020": [ - "OPS-13" - ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.6", - "21.12", - "21.13", - "21.19" + "emea-eu-eba-ict-srm-2025": [ + "3.4.5.38(a)", + "3.4.5.38(b)", + "3.4.5.38(c)", + "3.4.5.39", + "3.4.5.40" ], "emea-sau-cscc-1-2019": [ "2-11-1-3", "2-11-1-4" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" - ], "emea-sau-sacs-002-2022": [ - "TPC-81" + "VII.B.TPC-81" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.14" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], - "apac-aus-ism-2024-june": [ - "ISM-1228" + "apac-aus-ism-2026-march": [ + "ISM-1228", + "ISM-1961", + "ISM-1964" + ], + "apac-aus-cop-sitc-2020": [ + "10" ], "apac-nzl-ism-3-9": [ "16.6.14.C.01", @@ -5246,9 +5177,6 @@ "apac-sgp-mas-trm-2021": [ "12.2.5" ], - "amaericas-can-osfi-self-assessment": [ - "3.6" - ], "americas-can-osfi-b13-2022": [ "3.3.1" ], @@ -5280,11 +5208,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically centrally collect, review and analyze audit records from multiple sources.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -5364,7 +5292,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -5415,10 +5344,13 @@ "AU-06(04)" ], "general-nist-800-171-r3": [ - "03.03.01.b", "03.03.05.a", "03.03.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.03.05.a", + "A.03.03.05.c[01]" + ], "general-nist-800-207": [ "NIST Tenet 5", "NIST Tenet 7" @@ -5476,30 +5408,17 @@ "7123(c)(7)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" + "3.5.52" ], "emea-deu-c5-2020": [ - "OPS-13" + "RB-10", + "SIM-05" ], "emea-sau-cscc-1-2019": [ "2-11-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-12-3-4" - ], - "emea-sau-otcc-1-2022": [ - "2-11-1-9", - "2-11-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-81" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" - ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "apac-aus-essential-8-2024": [ "ML2-P3", @@ -5511,7 +5430,7 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1228" ], "apac-nzl-ism-3-9": [ @@ -5522,18 +5441,11 @@ "16.6.12.C.02", "16.6.12.C.03" ], - "apac-sgp-mas-trm-2021": [ - "12.2.6" - ], - "americas-bmu-mba-coc-2020": [ - "6.21" - ], "americas-can-osfi-b13-2022": [ "3.3.1", "3.3.2" ], "americas-can-itsp-10-171-2025": [ - "03.03.01.B", "03.03.05.A", "03.03.05.C" ] @@ -5557,11 +5469,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically integrate the analysis of audit records with analysis of vulnerability scanners, network performance, system monitoring and other sources to further enhance the ability to identify inappropriate or unusual activity.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -5641,7 +5553,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -5703,6 +5616,17 @@ "general-nist-800-171-r3": [ "03.03.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.03.05.c[02]" + ], + "general-nist-800-172-r3": [ + "03.03.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.04E", + "A.03.03.04E.ODP[01]", + "A.03.03.04E.ODP[02]" + ], "general-nist-800-207": [ "NIST Tenet 4", "NIST Tenet 5", @@ -5727,18 +5651,6 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-06(05)" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-4", - "2-11-1-5", - "2-11-1-6", - "2-11-1-7", - "2-11-1-8", - "2-11-1-10" - ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "americas-can-itsp-10-171-2025": [ "03.03.05.C" ] @@ -5762,11 +5674,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual or malevolent activity.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual or malevolent activity. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -5844,7 +5756,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -5904,9 +5817,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to specify the permitted actions for both users and Technology Assets, Applications and/or Services (TAAS) associated with the review, analysis and reporting of audit information.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to specify the permitted actions for both users and Technology Assets, Applications and/or Services (TAAS) associated with the review, analysis and reporting of audit information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5969,7 +5882,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -5993,9 +5907,6 @@ ], "usa-federal-irs-1075-2021": [ "AU-6(CE-7)" - ], - "emea-sau-cscc-1-2019": [ - "2-3-1-8" ] } }, @@ -6017,9 +5928,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to adjust the level of audit review, analysis and reporting based on evolving threat information from law enforcement, industry associations or other credible sources of threat intelligence.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to adjust the level of audit review, analysis and reporting based on evolving threat information from law enforcement, industry associations or other credible sources of threat intelligence. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6086,7 +5997,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -6144,6 +6056,12 @@ "general-nist-800-161-r1-level-3": [ "AU-6" ], + "general-nist-800-171-r3": [ + "03.03.01.b" + ], + "general-nist-800-171a-r3": [ + "A.03.03.01.b[01]" + ], "usa-federal-fbi-cjis-6-0": [ "AU-6" ], @@ -6175,12 +6093,15 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-06" ], - "emea-deu-c5-2020": [ - "OIS-05" + "emea-sau-otcc-1-2022": [ + "2-11-1-9" ], "apac-jpn-ismap": [ "6.1.3.5", "6.1.4.7" + ], + "americas-can-itsp-10-171-2025": [ + "03.03.01.B" ] } }, @@ -6202,11 +6123,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically compile audit records into an organization-wide audit trail that is time-correlated.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -6290,7 +6211,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -6333,6 +6255,9 @@ "general-nist-800-171-r3": [ "03.03.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.01.a" + ], "general-pci-dss-4-0-1": [ "10.6", "10.6.1", @@ -6387,12 +6312,10 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "AU-02-SID" ], - "emea-sau-otcc-1-2022": [ - "2-11-1-1", - "2-11-1-2", - "2-11-1-3" + "emea-deu-c5-2020": [ + "RB-14" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0988" ], "apac-nzl-ism-3-9": [ @@ -6424,9 +6347,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide privileged users or roles the capability to change the auditing to be performed on specified system components, based on specific event criteria within specified time thresholds.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide privileged users or roles the capability to change the auditing to be performed on specified system components, based on specific event criteria within specified time thresholds. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6493,7 +6416,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -6520,6 +6444,9 @@ ], "usa-federal-gsa-fedramp-5-high": [ "AU-12(03)" + ], + "emea-deu-c5-2020": [ + "RB-15" ] } }, @@ -6627,7 +6554,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -6660,7 +6588,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.\n▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD).", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action.\n▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum:\n(1) Establish what type of event occurred;\n(2) When (date and time) the event occurred;\n(3) Where the event occurred;\n(4) The source of the event;\n(5) The outcome (success or failure) of the event; and \n(6) The identity of any user/subject associated with the event.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum:\n(1) Establish what type of event occurred;\n(2) When (date and time) the event occurred;\n(3) Where the event occurred;\n(4) The source of the event;\n(5) The outcome (success or failure) of the event; and \n(6) The identity of any user/subject associated with the event. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6734,7 +6662,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -6872,7 +6801,7 @@ "general-nist-800-171a-r3": [ "A.03.03.01.ODP[01]", "A.03.03.01.a", - "A.03.03.01.b[02]", + "A.03.03.02.a.01", "A.03.03.02.a.02", "A.03.03.02.a.03", "A.03.03.02.a.04", @@ -6978,10 +6907,10 @@ "AU-03" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-irs-1075-2021": [ "AU-3" @@ -7024,9 +6953,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-03" ], - "emea-eu-eba-ict-srm-2025": [ - "3.5(52)" - ], "emea-eu-nis2-annex-2024": [ "3.2.3", "3.2.3(c)", @@ -7044,27 +6970,28 @@ "6.3" ], "emea-deu-c5-2020": [ - "OPS-15" + "RB-10" ], - "emea-isr-cmo-1-0": [ - "4.6", - "12.17", - "21.2", - "21.5", - "21.7", - "21.10" + "emea-isr-cmo-2-0": [ + "Appendix A, 12.2" ], "emea-sau-cscc-1-2019": [ "2-11-1-5" ], - "emea-esp-boe-a-2022-7191": [ - "Article 24.1" + "emea-sau-otcc-1-2022": [ + "2-11-1-2" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-87" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.14.3.a" ], "emea-esp-decree-311-2022": [ - "24.1" + "Article 20(b)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.8 [OP.EXP.8]" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.a" @@ -7084,11 +7011,16 @@ "ML3-P3", "ML3-P5" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0582", "ISM-0585", "ISM-1536", - "ISM-1537" + "ISM-1537", + "ISM-1895", + "ISM-2051" + ], + "apac-aus-cop-sitc-2020": [ + "7" ], "apac-ind-sebi-2024": [ "PR.AA.S9" @@ -7111,7 +7043,7 @@ "12.4.1.17", "12.4.1.18" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP70", "HML70" ], @@ -7125,7 +7057,7 @@ "16.6.10.C.02" ], "americas-bmu-mba-coc-2020": [ - "6.21" + "6.21-BP6" ], "americas-can-osfi-b13-2022": [ "3.2.7", @@ -7148,8 +7080,8 @@ "control_id": "MON-03.1", "title": "Sensitive Event Log Information", "family": "MON", - "description": "Mechanisms exist to protect sensitive/regulated data contained in log files.", - "scf_question": "Does the organization protect sensitive/regulated data contained in log files?", + "description": "Mechanisms exist to protect sensitive and/or regulated data contained in log files.", + "scf_question": "Does the organization protect sensitive and/or regulated data contained in log files?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7164,7 +7096,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect sensitive/regulated data contained in log files.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect sensitive/regulated data contained in log files. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7210,9 +7142,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Continuous Monitoring", "crosswalks": { "general-cis-csc-8-1": [ @@ -7289,8 +7221,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-03 (01)" ], - "emea-isr-cmo-1-0": [ - "21.4" + "apac-aus-ism-2026-march": [ + "ISM-2052" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP2" ] } }, @@ -7387,7 +7322,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -7404,6 +7340,9 @@ "3.3.1[c]", "3.3.2[a]" ], + "general-nist-800-171a-r3": [ + "A.03.03.01.a" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -7474,10 +7413,10 @@ "11.10(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)" + "§ 164.312(b)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.3.b" @@ -7488,8 +7427,9 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(b)" ], - "emea-isr-cmo-1-0": [ - "12.17" + "emea-deu-c5-2020": [ + "RB-14", + "RB-16" ], "emea-sau-cscc-1-2019": [ "2-11-1-3" @@ -7506,10 +7446,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3107" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0407" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP70", "HML70" ], @@ -7522,9 +7462,6 @@ "16.6.10.C.01", "16.6.10.C.02" ], - "apac-sgp-mas-trm-2021": [ - "9.2.2" - ], "americas-can-itsp-10-171-2025": [ "03.03.01.A" ] @@ -7621,7 +7558,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -7717,15 +7655,8 @@ "emea-eu-nis2-annex-2024": [ "11.5.2(d)" ], - "emea-deu-c5-2020": [ - "OPS-16" - ], - "emea-isr-cmo-1-0": [ - "21.10", - "21.21" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-2" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-def-stan-05-138-2024": [ "2216" @@ -7741,13 +7672,18 @@ "ML3-P4", "ML3-P7" ], - "apac-aus-ism-2024-june": [ - "ISM-1537" + "apac-aus-ism-2026-march": [ + "ISM-1537", + "ISM-1889" ], "apac-jpn-ismap": [ "12.4.3", "12.4.3.1" ], + "apac-nzl-ism-3-9": [ + "16.4.41.C.01", + "16.4.41.C.02" + ], "americas-can-itsp-10-171-2025": [ "03.01.07.B" ] @@ -7807,16 +7743,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-owasp-top-10-2025": [ "A09:2025" - ], - "emea-isr-cmo-1-0": [ - "21.5", - "21.21" ] } }, @@ -7838,7 +7771,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to limit Personal Data (PD) contained in audit records to the elements identified in the Data Privacy Risk Assessment (DPRA).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7884,7 +7817,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -7926,9 +7860,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to centrally manage and update the criteria to be captured in event logs generated by organization-defined system components.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to centrally manage and update the criteria to be captured in event logs generated by organization-defined system components. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7981,9 +7915,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Continuous Monitoring", "crosswalks": { "general-nist-800-53-r4": [ @@ -8007,6 +7941,13 @@ "general-nist-800-161-r1-level-2": [ "PL-9" ], + "general-nist-800-171-r3": [ + "03.03.01.b" + ], + "general-nist-800-171a-r3": [ + "A.03.03.01.b[01]", + "A.03.03.01.b[02]" + ], "usa-federal-fbi-cjis-6-0": [ "PL-9" ], @@ -8026,8 +7967,8 @@ "AU-2(3)", "AU-2(3)-IS.1" ], - "emea-sau-ecc-1-2018": [ - "2-12-4" + "americas-can-itsp-10-171-2025": [ + "03.03.01.B" ] } }, @@ -8049,7 +7990,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to ensure databases produce audit records that contain sufficient information to monitor database activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8114,7 +8055,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -8130,7 +8072,10 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "7.2.6" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "2-2-1-8" + ], + "apac-aus-ism-2026-march": [ "ISM-1537" ], "apac-nzl-ism-3-9": [ @@ -8161,7 +8106,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to allocate and proactively manage sufficient event log storage capacity to reduce the likelihood of such capacity being exceeded.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to allocate and proactively manage sufficient event log storage capacity to reduce the likelihood of such capacity being exceeded. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8216,24 +8161,25 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-cis-csc-8-1": [ "8.3", - "8.1" + "8.10" ], "general-cis-csc-8-1-ig1": [ "8.3" ], "general-cis-csc-8-1-ig2": [ "8.3", - "8.1" + "8.10" ], "general-cis-csc-8-1-ig3": [ "8.3", - "8.1" + "8.10" ], "general-govramp": [ "AU-04" @@ -8308,12 +8254,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-04" ], - "emea-isr-cmo-1-0": [ - "21.8" - ], - "emea-sau-ecc-1-2018": [ - "2-12-3-5" - ], "apac-nzl-ism-3-9": [ "16.6.13.C.01", "16.6.13.C.02", @@ -8342,7 +8282,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to alert appropriate personnel in the event of a log processing failure and take actions to remedy the disruption.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8403,7 +8343,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -8463,6 +8404,14 @@ "A.03.03.04.a", "A.03.03.04.b" ], + "general-nist-800-172-r3": [ + "03.03.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.02E", + "A.03.03.02E.ODP[03]", + "A.03.03.02E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -8508,15 +8457,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-05" ], - "emea-deu-c5-2020": [ - "OPS-17" - ], - "emea-isr-cmo-1-0": [ - "21.9" - ], - "emea-sau-otcc-1-2022": [ - "2-11-1-2" - ], "americas-can-itsp-10-171-2025": [ "03.03.04.B" ] @@ -8540,9 +8480,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide 24x7x365 near real-time alerting capability when an event log processing failure occurs.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide 24x7x365 near real-time alerting capability when an event log processing failure occurs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8597,7 +8537,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -8632,6 +8573,12 @@ "general-nist-800-82-r3-high": [ "AU-05(02)" ], + "general-nist-800-172-r3": [ + "03.03.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.03.02E.ODP[01]" + ], "usa-federal-gsa-fedramp-5-low": [ "SI-04(12)" ], @@ -8649,10 +8596,7 @@ "SI-4(CE-12)" ], "emea-deu-c5-2020": [ - "OPS-17" - ], - "emea-isr-cmo-1-0": [ - "21.9" + "RB-16-DOAR" ] } }, @@ -8674,7 +8618,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically alert appropriate personnel when the allocated volume reaches an organization-defined percentage of maximum event log storage capacity.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8731,7 +8675,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -8791,9 +8736,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A log aggregator, or similar automated tool, provides an event log report generation capability to aid in detecting and assessing anomalous activities on business-critical TAASD.\n▪ IT and/or cybersecurity personnel configure alerts for critical or sensitive data that is stored, transmitted and processed on assets.\n▪ Logs of privileged functions (e.g., administrator or root actions) are reviewed for evidence of unauthorized activities.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide an event log report generation capability to aid in detecting and assessing anomalous activities.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide an event log report generation capability to aid in detecting and assessing anomalous activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8865,7 +8810,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -9036,11 +8982,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-12" ], - "emea-isr-cmo-1-0": [ - "21.3", - "21.11", - "21.19", - "21.20" + "emea-deu-c5-2020": [ + "RB-16" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-def-stan-05-138-2024": [ "3108" @@ -9054,12 +9000,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "3108" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1660" ], - "apac-sgp-mas-trm-2021": [ - "12.2.6" - ], "americas-can-itsp-10-171-2025": [ "03.03.05.B", "03.03.06.A" @@ -9084,7 +9027,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to provide and implement the capability for auditing the parameters of user query events for data sets containing Personal Data (PD).", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9126,7 +9069,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -9216,7 +9160,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -9274,7 +9219,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use an authoritative time source to generate time stamps for event logs.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use an authoritative time source to generate time stamps for event logs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9326,7 +9271,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -9384,6 +9330,7 @@ "3.3.7[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.02.a.02", "A.03.03.07.ODP[01]", "A.03.03.07.a", "A.03.03.07.b[01]" @@ -9455,12 +9402,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-09" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-4" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.5 [MP.INFO.5]" - ], "americas-can-itsp-10-171-2025": [ "03.03.02.A.02", "03.03.07.A" @@ -9487,7 +9428,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to synchronize internal system clocks with an authoritative time source.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to synchronize internal system clocks with an authoritative time source. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9539,7 +9480,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -9646,9 +9588,6 @@ "emea-eu-nis2-annex-2024": [ "3.2.6" ], - "emea-sau-ecc-1-2018": [ - "2-3-3-4" - ], "emea-gbr-def-stan-05-138-2024": [ "2421" ], @@ -9661,7 +9600,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2421" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP71", "HML71" ], @@ -9691,7 +9630,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel retain security event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and/or contractual retention requirements.\n▪ IT and/or cybersecurity personnel restrict access to the management of event logs for privileged users to protect event logs and audit tools from unauthorized access, modification and deletion.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to protect event logs and audit tools from unauthorized access, modification and deletion.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9764,7 +9703,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -9846,7 +9786,8 @@ "general-nist-800-171-r3": [ "03.03.03.b", "03.03.06.b", - "03.03.08.a" + "03.03.08.a", + "03.03.08.b" ], "general-nist-800-171a": [ "3.3.8[a]", @@ -9918,6 +9859,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-09" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-9" ], @@ -9937,12 +9881,7 @@ "AU-09" ], "emea-deu-c5-2020": [ - "OPS-16" - ], - "emea-isr-cmo-1-0": [ - "21.4", - "21.14", - "21.16" + "RB-16" ], "emea-sau-cscc-1-2019": [ "2-3-1-8", @@ -9950,14 +9889,16 @@ "2-11-2" ], "emea-sau-ecc-1-2018": [ - "2-12-3-5", "2-14-3-3" ], "emea-sau-otcc-1-2022": [ "2-3-1-10" ], - "emea-esp-ccn-stic-825-2023": [ - "7.3.10 [OP.EXP.10]" + "emea-sau-sama-csf-1-2017": [ + "3.3.14.4.h" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.exp.8" ], "emea-gbr-caf-4-0": [ "C1.b" @@ -9981,9 +9922,8 @@ "ML3-P5", "ML3-P7" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991" + "apac-aus-ism-2026-march": [ + "ISM-1815" ], "apac-ind-sebi-2024": [ "PR.AA.S9" @@ -10001,13 +9941,17 @@ "16.6.13.C.03", "16.6.13.C.04" ], + "apac-sgp-mas-trm-2021": [ + "12.2.2" + ], "americas-bmu-mba-coc-2020": [ - "6.21" + "6.21-BP3" ], "americas-can-itsp-10-171-2025": [ "03.03.03.B", "03.03.06.B", - "03.03.08.A" + "03.03.08.A", + "03.03.08.B" ] } }, @@ -10081,7 +10025,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -10129,6 +10074,15 @@ "general-nist-800-171-r3": [ "03.03.08.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]" + ], + "general-nist-800-172-r3": [ + "03.03.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.01E" + ], "general-owasp-top-10-2025": [ "A09:2025" ], @@ -10153,11 +10107,6 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-09(02)" ], - "emea-isr-cmo-1-0": [ - "21.14", - "21.15", - "21.17" - ], "emea-sau-cscc-1-2019": [ "2-11-1-5", "2-11-2" @@ -10191,7 +10140,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel restrict access to the management of event logs for privileged users to protect event logs and audit tools from unauthorized access, modification and deletion.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to restrict access to the management of event logs to privileged users with a specific business need.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10250,7 +10199,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -10306,6 +10256,7 @@ "3.3.9[b]" ], "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]", "A.03.03.08.b" ], "general-owasp-top-10-2025": [ @@ -10347,17 +10298,20 @@ "usa-federal-gsa-fedramp-5-high": [ "AU-09(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-9(CE-4)" ], "usa-federal-cms-marse-2-0": [ "AU-9(4)" ], - "emea-deu-c5-2020": [ - "OPS-16" + "apac-aus-ism-2026-march": [ + "ISM-1985" ], - "emea-isr-cmo-1-0": [ - "21.14" + "apac-nzl-ism-3-9": [ + "16.4.41.C.03" ], "americas-can-itsp-10-171-2025": [ "03.03.08.A", @@ -10383,9 +10337,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational cryptographic capability exists to protect the integrity of event logs and audit tools.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational cryptographic capability exists to protect the integrity of event logs and audit tools. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10441,7 +10395,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -10475,9 +10430,15 @@ "general-nist-800-171-r3": [ "03.03.08.a" ], + "general-nist-800-171a-r3": [ + "A.03.03.08.a[01]" + ], "usa-federal-gsa-fedramp-5-high": [ "AU-09(03)" ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP2" + ], "americas-can-itsp-10-171-2025": [ "03.03.08.A" ] @@ -10571,7 +10532,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -10586,6 +10548,14 @@ ], "general-nist-800-160-vol-2-r1": [ "AU-09(05)" + ], + "general-nist-800-172-r3": [ + "03.03.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.03.03E", + "A.03.03.03E.ODP[01]", + "A.03.03.03E.ODP[02]" ] } }, @@ -10607,9 +10577,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a non-repudiation capability to protect against an individual falsely denying having performed a particular action.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to utilize a non-repudiation capability to protect against an individual falsely denying having performed a particular action. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10650,7 +10620,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -10694,25 +10665,6 @@ ], "usa-federal-cms-marse-2-0": [ "AU-10" - ], - "emea-us-psd2-2015": [ - "26" - ], - "emea-isr-cmo-1-0": [ - "21.14" - ], - "apac-sgp-mas-trm-2021": [ - "14.2.1", - "14.2.2", - "14.2.3", - "14.2.4", - "14.2.5", - "14.2.6", - "14.2.7", - "14.2.8", - "14.2.9", - "14.2.10", - "14.2.11" ] } }, @@ -10766,7 +10718,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -10816,7 +10769,7 @@ "0": "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.", "1": "Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.\n▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10876,7 +10829,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -10884,13 +10838,13 @@ "C1.2" ], "general-cis-csc-8-1": [ - "8.1" + "8.10" ], "general-cis-csc-8-1-ig2": [ - "8.1" + "8.10" ], "general-cis-csc-8-1-ig3": [ - "8.1" + "8.10" ], "general-csa-cmm-4-1-0": [ "LOG-04" @@ -10972,9 +10926,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "10.5.1" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "general-shared-assessments-sig-2025": [ "D.3" ], @@ -11002,6 +10953,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AU-11" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(c)(1)" + ], "usa-federal-irs-1075-2021": [ "AU-11" ], @@ -11039,12 +10993,7 @@ "3.2.5" ], "emea-deu-c5-2020": [ - "OPS-14" - ], - "emea-isr-cmo-1-0": [ - "21.4", - "21.15", - "21.17" + "RB-13" ], "emea-sau-cscc-1-2019": [ "2-11-2" @@ -11057,7 +11006,7 @@ "2-14-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-75" + "VII.B.TPC-75" ], "emea-gbr-caf-4-0": [ "C1.b" @@ -11077,19 +11026,25 @@ "3103", "3107" ], - "apac-aus-ism-2024-june": [ - "ISM-0859", - "ISM-0991", - "ISM-1213" - ], - "apac-chn-pipl-2021": [ - "19" + "apac-aus-ism-2026-march": [ + "ISM-1213", + "ISM-1988", + "ISM-1989" ], "apac-ind-sebi-2024": [ "PR.AA.S9" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS18" + "apac-mys-bnm-rmit-2025": [ + "10.42" + ], + "apac-nzl-ism-3-9": [ + "16.6.13.C.05" + ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP1" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.1" ], "americas-can-itsp-10-171-2025": [ "03.03.03.B" @@ -11114,9 +11069,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of non-public information.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of non-public information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -11186,7 +11141,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -11223,7 +11179,13 @@ "general-nist-800-171-r3": [ "03.01.22.b" ], - "apac-nzl-hisf-mlhsp-2023": [ + "general-nist-800-171a-r3": [ + "A.03.01.22.b[01]" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP63", "HML69" ], @@ -11253,11 +11215,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically analyze network traffic to detect covert data exfiltration.", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -11294,7 +11256,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -11363,11 +11326,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically detect unauthorized network services and alert incident response personnel.", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically detect unauthorized network services and alert incident response personnel. ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -11422,7 +11385,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -11479,11 +11443,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically identify and alert on Indicators of Compromise (IoC).", + "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to automatically identify and alert on Indicators of Compromise (IoC). ", "4": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Continuous Monitoring (MON) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -11567,7 +11531,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -11616,8 +11581,26 @@ "03.14.06.b", "03.14.06.c" ], - "general-nist-800-172": [ - "3.11.2e" + "general-nist-800-171a-r3": [ + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", + "A.03.14.06.b" + ], + "general-nist-800-172-r3": [ + "03.01.08E", + "03.11.02E", + "03.11.09E", + "03.14.17E", + "03.14.18E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.a", + "DS-A.03.11.02E.a.01[01]", + "DS-A.03.11.09E[01]", + "DS-A.03.11.09E[02]", + "DS-A.03.14.17E", + "A.03.14.18E.ODP[03]" ], "general-nist-csf-2-0": [ "DE.CM" @@ -11661,15 +11644,18 @@ "7123(c)(8)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" ], "emea-deu-bsrit-2017": [ "5.4" ], - "apac-aus-ism-2024-june": [ + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-80" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], + "apac-aus-ism-2026-march": [ "ISM-0120", "ISM-1091" ], @@ -11679,6 +11665,9 @@ "americas-can-osfi-b13-2022": [ "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.14.06.A.01", "03.14.06.A.02", @@ -11776,7 +11765,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -11800,10 +11790,6 @@ ], "general-nist-800-161-r1-level-3": [ "AU-14" - ], - "emea-isr-cmo-1-0": [ - "21.10", - "21.18" ] } }, @@ -11875,7 +11861,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -11887,9 +11874,6 @@ ], "general-nist-800-82-r3": [ "AU-05(05)" - ], - "emea-isr-cmo-1-0": [ - "21.15" ] } }, @@ -11911,7 +11895,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to coordinate sanitized event logs among external organizations to identify anomalous events when event logs are shared across organizational boundaries, without giving away sensitive or critical business data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11968,7 +11952,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -12020,7 +12005,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to share event logs with third-party organizations based on specific cross-organizational sharing agreements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12077,7 +12062,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -12171,11 +12157,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -12202,9 +12189,6 @@ ], "general-pci-dss-4-0-1-saq-d-service-provider": [ "11.5.1.1" - ], - "emea-isr-cmo-1-0": [ - "21.10" ] } }, @@ -12321,7 +12305,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -12400,10 +12385,20 @@ "03.14.06.c" ], "general-nist-800-171a-r3": [ + "A.03.01.01.e", + "A.03.03.05.a", + "A.03.14.06.a.01[01]", + "A.03.14.06.a.01[02]", + "A.03.14.06.a.02", "A.03.14.06.b" ], - "general-nist-800-172": [ - "3.14.2e" + "general-nist-800-172-r3": [ + "03.01.08E", + "03.06.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.08E.a", + "DS-A.03.06.03E" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -12475,12 +12470,12 @@ "IR-04(13)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(b)", - "164.312(c)(2)" + "§ 164.312(b)", + "§ 164.312(c)(2)" ], "usa-federal-irs-1075-2021": [ "AC-2(CE-12)", @@ -12498,10 +12493,7 @@ "AC-02 (12)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.5(38)", - "3.4.5(38)(a)", - "3.4.5(38)(b)", - "3.4.5(38)(c)" + "3.4.5.38" ], "emea-eu-dora-2023": [ "Article 10.1" @@ -12512,30 +12504,15 @@ "emea-deu-bsrit-2017": [ "5.5" ], - "emea-isr-cmo-1-0": [ - "4.7", - "21.10", - "21.20" - ], "emea-sau-otcc-1-2022": [ "2-3-1-12" ], "emea-sau-sacs-002-2022": [ - "TPC-80" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 10.1" - ], - "emea-esp-decree-311-2022": [ - "10.1" + "VII.B.TPC-80" ], "emea-gbr-caf-4-0": [ "C1.f" ], - "emea-gbr-cap-1850-2020": [ - "C1", - "C2" - ], "emea-gbr-def-stan-05-138-2024": [ "3200", "3202", @@ -12555,20 +12532,28 @@ "3202", "3203" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1660" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS19" + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.57", + "11.9" ], "apac-sgp-mas-trm-2021": [ - "9.2.2", "11.5.5", + "12.2.3", "12.2.4" ], + "americas-bmu-mba-coc-2020": [ + "6.21-BP4" + ], "americas-can-osfi-b13-2022": [ "3.3.2" ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.01.E", "03.03.05.A", @@ -12690,7 +12675,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -12706,14 +12692,8 @@ "general-sparta": [ "CM0052" ], - "emea-isr-cmo-1-0": [ - "21.10" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625" - ], - "apac-sgp-mas-trm-2021": [ - "3.5.2" ] } }, @@ -12828,7 +12808,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -12840,9 +12821,6 @@ ], "general-shared-assessments-sig-2025": [ "J.5" - ], - "emea-isr-cmo-1-0": [ - "21.10" ] } }, @@ -12867,7 +12845,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to monitor for unauthorized activities, accounts, connections, devices and software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12957,7 +12935,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -12982,13 +12961,6 @@ "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.4" ], - "emea-isr-cmo-1-0": [ - "21.10" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-11", - "2-3-1-12" - ], "emea-gbr-def-stan-05-138-2024": [ "4106" ], @@ -13112,18 +13084,23 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { "general-nist-csf-2-0": [ "DE.CM-06" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.2.31(c)", + "3.4.2.31(d)" + ], "emea-eu-nis2-annex-2024": [ "3.2.3(b)", "11.2.2(f)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1650" ] } @@ -13146,7 +13123,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to ensure event log reviews include analysis and triage practices that integrate with the organization's established incident response processes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13234,7 +13211,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -13296,7 +13274,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to make event log review processes more efficient and effective by developing and maintaining an incident response escalation matrix.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13384,7 +13362,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -13407,8 +13386,8 @@ "control_id": "MON-18", "title": "File Activity Monitoring (FAM)", "family": "MON", - "description": "Automated mechanisms exist to monitor sensitive/regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories.", - "scf_question": "Does the organization use automated tools to monitor sensitive/regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories?", + "description": "Automated mechanisms exist to monitor sensitive and/or regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories.", + "scf_question": "Does the organization use automated mechanisms to monitor sensitive and/or regulated data in Technology Assets, Applications and/or Services (TAAS) and data repositories?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -13507,7 +13486,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Continuous Monitoring", "crosswalks": { @@ -13536,7 +13516,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.\n▪ 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Continuous Monitoring (MON) 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:\n▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.\n▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM), etc.).\n▪ 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 MON 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).\n▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.\n▪ An implemented and operational capability exists to produce event logs on hardware-enforced, write-once media (e.g., Write Once Read Many (WORM) technologies).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13564,9 +13544,9 @@ "NT-7", "MT-2", "MT-8", - "MT-9" + "MT-9", + "MT-28" ], - "errata": "- new control (IEC 62443-4-2)", "family_name": "Continuous Monitoring", "crosswalks": { "general-iec-62443-3-3-2013": [ diff --git a/docs/api/families/NET.json b/docs/api/families/NET.json index 27b9ecb4..9b15b873 100644 --- a/docs/api/families/NET.json +++ b/docs/api/families/NET.json @@ -1,7 +1,7 @@ { "family_code": "NET", "family_name": "Network Security", - "control_count": 98, + "control_count": 100, "controls": [ { "control_id": "NET-01", @@ -122,7 +122,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -139,7 +140,7 @@ "CC6.6-POF4" ], "general-cis-csc-8-1": [ - "12.0", + "12", "12.1", "12.2", "12.3", @@ -276,10 +277,14 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.18.a", "03.13.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[03]", + "A.03.13.01.a[02]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -355,12 +360,12 @@ "SC-01" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.312(e)(1)", - "164.312(e)(2)(i)" + "§ 164.312(e)(1)", + "§ 164.312(e)(2)(i)" ], "usa-federal-irs-1075-2021": [ "3.3.6", @@ -409,23 +414,9 @@ "6.8.3", "6.9.1" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-c5-2020": [ - "PSS-10" - ], - "emea-isr-cmo-1-0": [ - "9.1" - ], "emea-sau-cscc-1-2019": [ "2-3-1-5", - "2-4", - "2-4-1-5" + "2-4-1" ], "emea-sau-cgiot-2024": [ "2-3-1", @@ -434,49 +425,25 @@ "2-4-5" ], "emea-sau-ecc-1-2018": [ - "2-4-4", "2-5-1", - "2-5-2", - "2-5-4" + "2-5-2" ], "emea-sau-otcc-1-2022": [ - "2-3", - "2-3-1", - "2-3-1-1", - "2-4", "2-4-1", - "2-4-2", - "2-5-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15", - "TPC-16", - "TPC-17", - "TPC-78" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 23" + "2-4-2" ], "emea-esp-decree-311-2022": [ - "23" + "Article 12(6)(k)", + "Article 18" ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.1 [MP.COM.1]", - "8.4.2 [MP.COM.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3", + "mp.s.1" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "1" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0521", "ISM-0629", "ISM-1186", @@ -506,7 +473,12 @@ "13.1.1.9", "13.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.37", + "12.3", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP49", "HHSP54", "HML49", @@ -545,28 +517,17 @@ "4.4" ], "apac-sgp-mas-trm-2021": [ - "11.2.1", - "11.2.2", - "11.2.3", - "11.2.4", - "11.2.5", - "11.2.6", - "11.2.7", - "11.2.8" - ], - "americas-bmu-mba-coc-2020": [ - "6.18" + "11.2.1" ], - "amaericas-can-osfi-self-assessment": [ - "4.10", - "4.15" + "americas-can-osfi-self-assessment-2": [ + "3.2.4" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", - "03.01.16.B", "03.01.18.A", - "03.13.01.A" + "03.13.01.A", + "03.14.08.B" ] } }, @@ -590,7 +551,7 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to treat all users and devices as potential threats and prevent access to data and resources until the users can be properly authenticated and their access authorized.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -656,7 +617,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -698,7 +660,7 @@ "usa-federal-dow-zta-reference-architecture-2-0": [ "3.0" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0665" ], "apac-ind-sebi-2024": [ @@ -709,7 +671,9 @@ ], "apac-nzl-ism-3-9": [ "2.3.26.C.01", - "2.3.26.C.02" + "2.3.26.C.02", + "16.1.25.C.01", + "16.5.12.C.02" ] } }, @@ -735,9 +699,9 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes are used to configure boundary devices (e.g., firewalls, routers, etc.) to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity architects maintain a segmented development network to ensure a secure development environment.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security functions as a layered structure that minimizes interactions between layers of the design and avoids any dependence by lower layers on the functionality or correctness of higher layers.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security functions as a layered structure that minimizes interactions between layers of the design and avoids any dependence by lower layers on the functionality or correctness of higher layers. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -815,7 +779,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -857,8 +822,8 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.13.01.b" ], "general-nist-csf-2-0": [ "PR.IR-01" @@ -895,31 +860,31 @@ "7123(c)(10)" ], "emea-deu-c5-2020": [ - "PSS-10" - ], - "emea-isr-cmo-1-0": [ - "9.17" + "KOS-01", + "KOS-03-DOAR" ], "emea-sau-cscc-1-2019": [ "2-4-1-5" ], "emea-sau-ecc-1-2018": [ - "2-5-3-1" + "2-5-3-8" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-1" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.4" + "apac-mys-bnm-rmit-2025": [ + "12.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.11", - "4.12", - "4.15" + "americas-bmu-mba-coc-2020": [ + "6.18" ], "americas-can-osfi-b13-2022": [ "3.2.4" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.13.01.B" ] @@ -943,9 +908,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Boundary protection technologies minimize the effect of Denial of Service (DoS) attacks against business-critical services.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically protect against or limit the effects of denial of service attacks.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically protect against or limit the effects of denial of service attacks. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -984,7 +949,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -1016,7 +982,7 @@ "CR 7.1", "CR 7.1(1)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1496.003" ], "general-nist-800-53-r4": [ @@ -1043,6 +1009,16 @@ "general-nist-800-82-r3-high": [ "SC-05" ], + "general-nist-800-172-r3": [ + "03.13.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.12E.a", + "A.03.13.12E.ODP[01]", + "A.03.13.12E.ODP[02]", + "DS-A.03.13.12E.b", + "A.03.13.12E.ODP[03]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.RE.DDSPR" ], @@ -1077,40 +1053,24 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-05" ], - "emea-isr-cmo-1-0": [ - "9.3" + "emea-deu-c5-2020": [ + "KOS-01" ], "emea-sau-cscc-1-2019": [ "2-4-1-8" ], - "emea-sau-sacs-002-2022": [ - "TPC-92" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.3 [MP.S.3]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1019", "ISM-1431", "ISM-1436", "ISM-1805" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS17" - ], "apac-nzl-ism-3-9": [ "18.3.18.C.01", "18.3.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "11.2.7" - ], "americas-bmu-mba-coc-2020": [ "6.19" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } }, @@ -1132,9 +1092,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel implement and manage a secure guest network.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and manage a secure guest network.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and manage a secure guest network. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1218,7 +1178,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -1287,10 +1248,7 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(x)" ], - "emea-isr-cmo-1-0": [ - "9.18" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0536" ], "apac-nzl-ism-3-9": [ @@ -1405,11 +1363,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.001", "T1021.003", "T1021.006", @@ -1447,9 +1406,6 @@ "general-nist-800-160-vol-2-r1": [ "SC-46" ], - "general-nist-800-172": [ - "3.1.3e" - ], "general-nist-800-207": [ "NIST Tenet 4" ], @@ -1462,10 +1418,13 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.5" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-2" + "emea-deu-c5-2020": [ + "KOS-03" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "2-6-1-5" + ], + "apac-aus-ism-2026-march": [ "ISM-0597", "ISM-0610", "ISM-0626", @@ -1485,7 +1444,13 @@ "19.2.18.C.01", "19.2.19.C.01", "19.2.19.C.02", - "19.2.20.C.01" + "19.2.20.C.01", + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.14.C.04", + "20.3.9.C.02", + "20.3.9.C.04", + "21.1.8.C.01" ] } }, @@ -1510,7 +1475,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network activity monitoring and control communications at the external network boundary and at key internal boundaries within the network.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor and control communications at the external network boundary and at key internal boundaries within the network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1602,7 +1567,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -1670,7 +1636,7 @@ "8.20", "8.21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -1883,6 +1849,7 @@ ], "general-nist-800-171-r3": [ "03.01.12.a", + "03.01.18.a", "03.13.01.a", "03.13.01.b", "03.13.01.c" @@ -1901,8 +1868,17 @@ "A.03.01.18.a[03]", "A.03.13.01.a[02]", "A.03.13.01.a[04]", + "A.03.13.01.b", "A.03.13.01.c" ], + "general-nist-800-172-r3": [ + "03.01.12E", + "03.13.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.12E.ODP[01]", + "DS-A.03.13.04E" + ], "general-pci-dss-4-0-1": [ "1.3.3", "1.4", @@ -2020,27 +1996,31 @@ "SC-07" ], "emea-deu-c5-2020": [ - "COS-04", - "PSS-10" + "KOS-01", + "KOS-02", + "KOS-03" ], - "emea-isr-cmo-1-0": [ - "9.3", - "9.18", - "9.23", - "10.9", - "11.8", - "16.4" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.3" + ], + "emea-sau-cscc-1-2019": [ + "2-4-1-5" ], "emea-sau-cgiot-2024": [ "2-4-5" ], "emea-sau-otcc-1-2022": [ - "2-3-1-1", - "2-4-1-2", - "2-4-1-6" + "2-3-1-13", + "2-4-1-12" ], "emea-sau-sacs-002-2022": [ - "TPC-76" + "VII.B.TPC-76" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.com.2", + "mp.com.3" ], "emea-gbr-cyber-essentials-requirements-3-3": [ "1" @@ -2057,7 +2037,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2427" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0611", "ISM-0612", "ISM-0613", @@ -2159,17 +2139,20 @@ "19.5.28.C.05", "19.5.28.C.06", "19.5.28.C.07", - "19.5.29.C.01" + "19.5.29.C.01", + "21.3.5.C.01", + "21.3.5.C.02", + "21.3.6.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ "4.4" ], "apac-sgp-mas-trm-2021": [ - "11.2.5", - "11.2.6" + "11.2.1" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", + "03.01.18.A", "03.13.01.A", "03.13.01.B", "03.13.01.C" @@ -2196,7 +2179,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to limit the number of concurrent external network connections to its Technology Assets, Applications and/or Services (TAAS).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to limit the number of concurrent external network connections to its Technology Assets, Applications and/or Services (TAAS). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2281,7 +2264,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -2380,15 +2364,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (03)" ], - "emea-deu-c5-2020": [ - "COS-04" - ], - "emea-isr-cmo-1-0": [ - "9.10", - "9.11", - "16.4" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1314" ] } @@ -2481,7 +2460,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -2567,13 +2547,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (04)" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.5" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0546", "ISM-1562" ] @@ -2597,9 +2571,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent the public disclosure of internal network information.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent the public disclosure of internal network information. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2637,7 +2611,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -2647,7 +2622,7 @@ "general-iso-27018-2025": [ "8.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1590.001", "T1590.003", "T1590.004", @@ -2683,9 +2658,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.4.5" ], - "emea-isr-cmo-1-0": [ - "9.19" - ], "apac-jpn-ismap": [ "14.1.1.23" ] @@ -2709,7 +2681,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to apply network-based processing rules to data elements of Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2757,7 +2729,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -2788,8 +2761,8 @@ "control_id": "NET-03.5", "title": "Prevent Unauthorized Exfiltration", "family": "NET", - "description": "Automated mechanisms exist to prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces.", - "scf_question": "Does the organization use automated mechanisms to prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces?", + "description": "Automated mechanisms exist to prevent the unauthorized exfiltration of sensitive and/or regulated data across managed interfaces.", + "scf_question": "Does the organization use automated mechanisms to prevent the unauthorized exfiltration of sensitive and/or regulated data across managed interfaces?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -2802,9 +2775,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically prevent the unauthorized exfiltration of sensitive/regulated data across managed interfaces. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2852,7 +2825,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -2950,9 +2924,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically dynamically isolate (e.g., sandbox) untrusted components during runtime, where the component is isolated in a fault-contained environment but it can still collaborate with the application.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically dynamically isolate (e.g., sandbox) untrusted components during runtime, where the component is isolated in a fault-contained environment but it can still collaborate with the application. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2997,7 +2971,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -3025,11 +3000,8 @@ "usa-federal-gsa-fedramp-5-high": [ "SC-07(20)" ], - "emea-sau-sacs-002-2022": [ - "TPC-38" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "4" + "apac-sgp-mas-trm-2021": [ + "11.5.5" ] } }, @@ -3051,9 +3023,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ boundary protections to isolate Technology Assets, Applications and/or Services (TAAS) that support critical missions and/or business functions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ boundary protections to isolate Technology Assets, Applications and/or Services (TAAS) that support critical missions and/or business functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3122,7 +3094,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -3154,8 +3127,11 @@ "general-nist-800-160-vol-2-r1": [ "SC-07(21)" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-172-r3": [ + "03.13.04E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.04E.ODP[01]" ], "general-pci-dss-4-0-1": [ "1.3.3" @@ -3187,20 +3163,14 @@ "emea-sau-ecc-1-2018": [ "5-1-3-4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP43", "HHSP55", "HML43", "HML55" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS16" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP47" - ], - "apac-sgp-mas-trm-2021": [ - "11.2.6" ] } }, @@ -3294,7 +3264,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -3322,6 +3293,17 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], + "general-nist-800-172-r3": [ + "03.13.10E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.10E", + "DS-A.03.13.15E" + ], "general-pci-dss-4-0-1": [ "1.4", "1.4.1" @@ -3347,12 +3329,8 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-07(29)" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "emea-deu-c5-2020": [ + "KOS-02" ], "apac-nzl-ism-3-9": [ "14.1.11.C.01" @@ -3386,11 +3364,11 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Administrative processes enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement and govern Access Control Lists (ACLs) to provide data flow enforcement that explicitly restrict network traffic to only what is authorized.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -3462,7 +3440,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -3539,7 +3518,7 @@ "8.3", "8.20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1001", "T1001.001", "T1001.002", @@ -3750,10 +3729,9 @@ "3.1.3[e]" ], "general-nist-800-171a-r3": [ - "A.03.01.03[02]" - ], - "general-nist-800-172": [ - "3.1.3e" + "A.03.01.03[02]", + "A.03.13.01.a[02]", + "A.03.13.01.c" ], "general-nist-800-207": [ "NIST Tenet 4" @@ -3848,15 +3826,6 @@ "6.7.2(f)", "6.7.2(g)" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.12", - "9.16", - "10.9", - "12.11" - ], "emea-sau-cscc-1-2019": [ "2-4-1-4", "2-4-1-6", @@ -3868,11 +3837,14 @@ ], "emea-sau-otcc-1-2022": [ "2-4-1-6", - "2-4-1-7", "2-4-1-8", - "2-4-1-10", - "2-4-1-14", - "2-4-1-16" + "2-4-1-9", + "2-4-1-10" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2316", @@ -3890,7 +3862,7 @@ "2316", "2428" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0643", "ISM-0645", "ISM-1157", @@ -3902,6 +3874,9 @@ "18.1.13.C.02", "18.1.14.C.01" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" + ], "americas-can-itsp-10-171-2025": [ "03.01.03", "03.13.01.A", @@ -3932,11 +3907,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure firewall and router configurations to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure firewall and router configurations to deny network traffic by default and allow network traffic by exception (e.g., deny all, permit by exception). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -4006,7 +3981,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -4111,6 +4087,7 @@ "3.13.6[b]" ], "general-nist-800-171a-r3": [ + "A.03.13.01.a[02]", "A.03.13.06[01]", "A.03.13.06[02]" ], @@ -4202,9 +4179,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-07 (05)" ], - "emea-isr-cmo-1-0": [ - "9.12", - "12.9" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.4" ], "emea-sau-cscc-1-2019": [ "2-4-1-4", @@ -4212,13 +4188,10 @@ "2-4-1-7", "2-4-1-9" ], - "emea-sau-otcc-1-2022": [ - "2-4-1-6", - "2-4-1-8", - "2-4-1-14" - ], - "emea-sau-sacs-002-2022": [ - "TPC-36" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1", + "mp.s.1" ], "emea-gbr-def-stan-05-138-2024": [ "2507" @@ -4232,11 +4205,17 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2507" ], + "apac-aus-ism-2026-march": [ + "ISM-2068" + ], "apac-nzl-ism-3-9": [ "18.1.13.C.01", "18.1.13.C.02", "18.1.14.C.01" ], + "apac-sgp-cyber-hygiene-practice-2019": [ + "4.4" + ], "americas-can-itsp-10-171-2025": [ "03.13.01.A", "03.13.06" @@ -4263,7 +4242,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to associate security attributes with information, source and destination objects to enforce defined information flow control configurations as a basis for flow control decisions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to associate security attributes with information, source and destination objects to enforce defined information flow control configurations as a basis for flow control decisions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4308,7 +4287,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -4320,6 +4300,16 @@ ], "general-nist-800-82-r3": [ "AC-04(01)" + ], + "general-nist-800-172-r3": [ + "03.01.10E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.10E", + "A.03.01.10E.ODP[01]", + "A.03.01.10E.ODP[02]", + "A.03.01.10E.ODP[03]", + "A.03.01.10E.ODP[04]" ] } }, @@ -4341,9 +4331,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent encrypted data from bypassing content-checking mechanisms.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent encrypted data from bypassing content-checking mechanisms. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4388,7 +4378,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -4409,9 +4400,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "AC-04(04)" - ], - "emea-isr-cmo-1-0": [ - "9.16" ] } }, @@ -4433,9 +4421,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce limitations on embedding data within other data types.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce limitations on embedding data within other data types. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4480,7 +4468,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -4492,9 +4481,6 @@ ], "general-nist-800-82-r3": [ "AC-04(05)" - ], - "emea-isr-cmo-1-0": [ - "9.16" ] } }, @@ -4518,7 +4504,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce information flow controls based on metadata.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce information flow controls based on metadata. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4563,7 +4549,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -4589,6 +4576,12 @@ "general-nist-800-161-r1-level-3": [ "AC-4(6)" ], + "general-nist-800-172-r3": [ + "03.01.13E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.13E.ODP[01]" + ], "usa-federal-dow-zt-roadmap-1-1": [ "4.4" ], @@ -4617,9 +4610,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enforce the use of human reviews for Access Control Lists (ACLs) and similar rulesets on a routine basis. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4699,7 +4692,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -4727,18 +4721,8 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "1.2.7" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "9.24" - ], "emea-sau-cscc-1-2019": [ - "2-3-1-6", "2-4-1-2" - ], - "apac-sgp-mas-trm-2021": [ - "11.2.5" ] } }, @@ -4747,7 +4731,7 @@ "title": "Policy Decision Point (PDP)", "family": "NET", "description": "Automated mechanisms exist to evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions.", - "scf_question": "Does the organization evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions?", + "scf_question": "Does the organization use automated mechanisms to evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions?", "relative_weight": 5, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -4760,7 +4744,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically evaluate access requests against established criteria to dynamically and uniformly enforce access rights and permissions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4810,7 +4794,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -4832,6 +4817,18 @@ "general-nist-800-160-vol-2-r1": [ "AC-04(08)" ], + "general-nist-800-172-r3": [ + "03.01.10E", + "03.01.13E", + "03.01.14E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.10E.ODP[05]", + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "A.03.01.14E.ODP[01]", + "DS-A.03.01.14E.b" + ], "general-nist-800-207": [ "NIST Tenet 4" ], @@ -4883,7 +4880,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically utilize data type identifiers to validate data essential for information flow decisions when transferring information between different security domains.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4929,7 +4926,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -4944,6 +4942,17 @@ ], "general-nist-800-160-vol-2-r1": [ "AC-04(12)" + ], + "general-nist-800-172-r3": [ + "03.01.13E", + "03.01.14E", + "03.01.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.13E", + "DS-A.03.01.14E.a", + "DS-A.03.01.15E", + "A.03.01.15E.ODP[01]" ] } }, @@ -4965,7 +4974,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms, when transferring information between different security domains.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5009,7 +5018,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -5021,6 +5031,12 @@ ], "general-nist-800-82-r3": [ "AC-04(13)" + ], + "general-nist-800-172-r3": [ + "03.01.16E" + ], + "general-nist-800-172a-r3": [ + "A.03.01.16E.ODP[01]" ] } }, @@ -5042,7 +5058,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically implement security policy filters requiring fully enumerated formats that restrict data structure and content, when transferring information between different security domains.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -5094,7 +5110,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -5106,6 +5123,12 @@ ], "general-nist-800-82-r3": [ "AC-04(15)" + ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.a" ] } }, @@ -5127,11 +5150,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically examine information for the presence of unsanctioned information and prohibits the transfer of such information, when transferring information between different security domains.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -5180,7 +5203,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -5216,7 +5240,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically uniquely identify and authenticate source and destination points for information transfer.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5253,7 +5277,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -5298,7 +5323,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically apply cybersecurity and/or data protection filters on metadata.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5335,7 +5360,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -5361,7 +5387,7 @@ "title": "Application Proxy", "family": "NET", "description": "Mechanisms exist to terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network.", - "scf_question": "Does the organization maintain visibility and control over application traffic, regardless of the user’s location or the security posture of the surrounding network?", + "scf_question": "Does the organization terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5374,7 +5400,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate, inspect, control and reinitiate application traffic, regardless of the user’s location or the security posture of the surrounding network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5425,7 +5451,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": {} @@ -5528,9 +5555,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Network Security", "crosswalks": { "general-govramp": [ @@ -5551,7 +5578,7 @@ "general-iec-62443-2-1-2024": [ "NET 1.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1041", "T1048", @@ -5610,6 +5637,7 @@ ], "general-nist-800-171a-r3": [ "A.03.01.03[02]", + "A.03.01.20.c.02", "A.03.12.05.ODP[01]", "A.03.12.05.ODP[02]", "A.03.12.05.a[01]", @@ -5620,6 +5648,18 @@ "A.03.12.05.c[01]", "A.03.12.05.c[02]" ], + "general-nist-800-172-r3": [ + "03.12.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.04E.a", + "A.03.12.04E.ODP[01]", + "DS-A.03.12.04E.b[01]", + "DS-A.03.12.04E.b[02]", + "DS-A.03.12.04E.b[03]", + "A.03.12.04E.ODP[02]", + "DS-A.03.12.04E.d" + ], "general-swift-cscf-2025": [ "2.4" ], @@ -5665,11 +5705,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-03" ], - "emea-deu-c5-2020": [ - "COS-03" - ], - "emea-isr-cmo-1-0": [ - "16.4" + "emea-esp-decree-311-2022": [ + "Article 23" ], "americas-can-itsp-10-171-2025": [ "03.01.03", @@ -5702,7 +5739,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the direct connection of a sensitive system to an external network without the use of an organization-defined boundary protection device.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the direct connection of a sensitive system to an external network without the use of an organization-defined boundary protection device. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5777,7 +5814,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -5814,19 +5852,8 @@ "usa-federal-cms-marse-2-0": [ "CA-3(5)" ], - "emea-isr-cmo-1-0": [ - "9.11", - "12.8", - "16.4" - ], - "emea-sau-ecc-1-2018": [ - "5-1-3-2" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-13" - ], "emea-sau-sacs-002-2022": [ - "TPC-36" + "VII.B.TPC-36" ], "apac-nzl-ism-3-9": [ "14.1.13.C.01", @@ -5931,7 +5958,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -5980,10 +6008,18 @@ ], "general-nist-800-171-r3": [ "03.01.03", - "03.12.05.a", "03.12.05.b", "03.12.05.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.03[02]" + ], + "general-nist-800-172-r3": [ + "03.12.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.04E.c" + ], "general-shared-assessments-sig-2025": [ "G.3" ], @@ -6022,18 +6058,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-09" ], - "emea-sau-ecc-1-2018": [ - "5-1-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-3-1-13" - ], "apac-jpn-ismap": [ "13.1.1.10" ], "americas-can-itsp-10-171-2025": [ "03.01.03", - "03.12.05.A", "03.12.05.B", "03.12.05.C" ] @@ -6041,10 +6070,10 @@ }, { "control_id": "NET-06", - "title": "Network Segmentation (macrosegementation)", + "title": "Network Segmentation (macrosegmentation)", "family": "NET", - "description": "Mechanisms exist to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.", - "scf_question": "Does the organization ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources?", + "description": "Mechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", + "scf_question": "Does the organization implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -6057,9 +6086,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network segmentation exists to implement separate network addresses (e.g., different subnets) to connect TAASD in different security domains (e.g., sensitive/regulated data environments).\n▪ IT and/or cybersecurity architects maintain a segmented development network to ensure a secure development environment.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure network architecture utilizes network segmentation to isolate Technology Assets, Applications and/or Services (TAAS) to protect from other network resources.\nMechanisms exist to implement network segmentation within network architectures to isolate Technology Assets, Applications and/or Services (TAAS) from other network resources.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6146,8 +6175,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control (typo)\n- wordsmithed control", "family_name": "Network Security", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -6240,8 +6271,12 @@ "general-nist-800-171a-r3": [ "A.03.13.01.b" ], - "general-nist-800-172": [ - "3.14.3e" + "general-nist-800-172-r3": [ + "03.01.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.12E", + "A.03.01.12E.ODP[01]" ], "general-pci-dss-4-0-1": [ "1.2.1", @@ -6385,12 +6420,15 @@ "usa-federal-gsa-fedramp-5-high": [ "AC-04(21)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(h)(1)" + ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)", "7123(c)(10)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.4(36)(c)" + "3.4.4.36(c)" ], "emea-eu-nis2-annex-2024": [ "6.8.1", @@ -6404,16 +6442,8 @@ "6.8.2(h)" ], "emea-deu-c5-2020": [ - "COS-06" - ], - "emea-isr-cmo-1-0": [ - "9.2", - "9.18", - "9.19", - "10.8", - "12.4", - "12.5", - "12.11" + "RB-23-DOAR", + "KOS-05" ], "emea-sau-cscc-1-2019": [ "2-3-1-4", @@ -6423,22 +6453,24 @@ "2-4-4" ], "emea-sau-ecc-1-2018": [ + "2-5-3-1", + "2-5-3-2", "5-1-3-1", "5-1-3-2" ], "emea-sau-otcc-1-2022": [ "2-4-1-1", "2-4-1-2", - "2-4-1-3", - "2-4-1-5", - "2-4-1-10" + "2-4-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "VII.B.TPC-40" ], - "emea-esp-ccn-stic-825-2023": [ - "8.4.4 [MP.COM.4]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "op.mon.1", + "mp.com.1", + "mp.com.4" ], "emea-gbr-def-stan-05-138-2024": [ "2508" @@ -6452,7 +6484,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2508" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1181", "ISM-1269", "ISM-1270", @@ -6479,7 +6511,10 @@ "13.1.3.12.P", "13.1.4.P" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.28" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP55", "HML55" ], @@ -6487,7 +6522,13 @@ "HSUP47" ], "apac-sgp-mas-trm-2021": [ - "11.2.6" + "11.2.2" + ], + "americas-arg-ppd-2018": [ + "E.1.2-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" ], "americas-can-osfi-b13-2022": [ "3.2.5" @@ -6517,7 +6558,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Processing and storage of service location, including a managed security zone to house cybersecurity and data protection tools.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security management subnets to isolate security tools and support components from other internal system components by implementing separate subnetworks with managed interfaces to other components of the system.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement security management subnets to isolate security tools and support components from other internal system components by implementing separate subnetworks with managed interfaces to other components of the system. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6600,7 +6641,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -6661,6 +6703,14 @@ "general-nist-800-161-r1-level-3": [ "SC-7(13)" ], + "general-nist-800-172-r3": [ + "03.13.09E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.09E", + "DS-A.03.13.15E" + ], "general-swift-cscf-2025": [ "1.1" ], @@ -6683,15 +6733,11 @@ "7123(c)(5)(B)", "7123(c)(10)" ], - "emea-deu-c5-2020": [ - "COS-04" - ], - "emea-isr-cmo-1-0": [ - "9.2", - "12.4", - "12.5" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "mp.com.4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385", "ISM-1750" ], @@ -6718,9 +6764,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable Virtual Local Area Networks (VLANs) to limit the ability of devices on a network to directly communicate with other devices on the subnet and limit an attacker's ability to laterally move to compromise neighboring systems. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6789,11 +6835,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "KOS-05-DOAR" + ], + "apac-aus-ism-2026-march": [ "ISM-0529", "ISM-0530", "ISM-0535", @@ -6804,13 +6854,9 @@ "13.1.4.P" ], "apac-nzl-ism-3-9": [ - "22.3.9.C.01", - "22.3.9.C.02", - "22.3.9.C.03", - "22.3.9.C.04", - "22.3.10.C.01", - "22.3.11.C.01", - "22.3.11.C.02" + "20.3.9.C.02", + "20.3.9.C.03", + "20.3.9.C.04" ] } }, @@ -6818,8 +6864,8 @@ "control_id": "NET-06.3", "title": "Sensitive / Regulated Data Enclave (Secure Zone)", "family": "NET", - "description": "Mechanisms exist to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones).", - "scf_question": "Does the organization implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones)?", + "description": "Mechanisms exist to implement segmentation controls to restrict inbound and outbound connectivity for sensitive and/or regulated data enclaves (secure zones).", + "scf_question": "Does the organization implement segmentation controls to restrict inbound and outbound connectivity for sensitive and/or regulated data enclaves (secure zones)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [], @@ -6832,9 +6878,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement segmentation controls to restrict inbound and outbound connectivity for sensitive/regulated data enclaves (secure zones). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6844,7 +6890,7 @@ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], "possible_solutions": { - "medium": "∙ Dedicated network segment for sensitive/regulated data systems", + "medium": "∙ Dedicated network segment for sensitive and/or regulated data systems", "large": "∙ Secure enclave/zone for sensitive data\n∙ Enhanced controls within the zone", "enterprise": "∙ Enterprise secure data enclave with enhanced controls\n∙ Data loss prevention at enclave boundary\n∙ Microsegmentation" }, @@ -6897,7 +6943,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -6911,6 +6958,9 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], "general-swift-cscf-2025": [ "1.1", "1.4", @@ -6921,22 +6971,24 @@ "III.B.1.c" ], "emea-sau-cscc-1-2019": [ + "2-3-1-4", "2-4-1-6", "2-4-1-7" ], + "emea-sau-ecc-1-2018": [ + "5-1-3-1", + "5-1-3-2" + ], "emea-sau-otcc-1-2022": [ - "2-4-1-1" + "2-4-1-2", + "2-4-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-38", - "TPC-40" + "VII.B.TPC-38" ], "apac-jpn-ismap": [ "13.1.4.P" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS15" - ], "americas-can-itsp-10-171-2025": [ "03.13.01.B" ] @@ -6946,8 +6998,8 @@ "control_id": "NET-06.4", "title": "Segregation From Enterprise Services", "family": "NET", - "description": "Mechanisms exist to isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", - "scf_question": "Does the organization isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments?", + "description": "Mechanisms exist to isolate sensitive and/or regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", + "scf_question": "Does the organization isolate sensitive and/or regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments?", "relative_weight": 4, "conformity_cadence": "Annual", "evidence_requests": [], @@ -6960,7 +7012,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to isolate sensitive/regulated data enclaves (secure zones) from corporate-provided IT resources by providing enclave-specific IT services (e.g., directory services, DNS, NTP, ITAM, antimalware, patch management, etc.) to those isolated network segments.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7023,7 +7075,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -7034,9 +7087,6 @@ "general-mpa-csbp-5-3-1": [ "TS-1.0" ], - "general-nist-800-172": [ - "3.14.3e" - ], "general-swift-cscf-2025": [ "1.1" ], @@ -7047,16 +7097,10 @@ "usa-federal-dow-cmmc-2-level-3": [ "SI.L3-3.14.3E" ], - "emea-sau-otcc-1-2022": [ - "2-2-1-1", - "2-4-1-3", - "2-4-1-9", - "2-4-1-10", - "2-4-1-11", - "2-4-1-12", - "2-4-1-13" + "emea-deu-c5-2020": [ + "KOS-05" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1385" ] } @@ -7065,8 +7109,8 @@ "control_id": "NET-06.5", "title": "Direct Internet Access Restrictions", "family": "NET", - "description": "Mechanisms exist to prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones).", - "scf_question": "Does the organization prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones)?", + "description": "Mechanisms exist to prohibit, or strictly-control, Internet access from sensitive and/or regulated data enclaves (secure zones).", + "scf_question": "Does the organization prohibit, or strictly-control, Internet access from sensitive and/or regulated data enclaves (secure zones)?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7079,7 +7123,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit, or strictly-control, Internet access from sensitive/regulated data enclaves (secure zones).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7142,7 +7186,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -7170,51 +7215,280 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "2.X" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(iv)", + "101.650(e)(3)(v)" + ], "emea-sau-cscc-1-2019": [ "2-4-1-3", "2-4-1-6" ], "emea-sau-otcc-1-2022": [ - "2-3-1-13", "2-4-1-7" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" + "apac-aus-ism-2026-march": [ + "ISM-1863" + ] + } + }, + { + "control_id": "NET-06.6", + "title": "Microsegmentation", + "family": "NET", + "description": "Automated mechanisms exist to enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs.", + "scf_question": "Does the organization use automated mechanisms to enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs?", + "relative_weight": 2, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": false, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "CORE ESP Level 2 Critical Infrastructure", + "CORE ESP Level 3 Advanced Threats" + ], + "possible_solutions": { + "medium": "∙ Plan for microsegmentation as network matures", + "large": "∙ Microsegmentation for high-risk workloads (e.g., VMware NSX)\n∙ Segmentation policy", + "enterprise": "∙ Enterprise microsegmentation platform (e.g., Illumio, VMware NSX)\n∙ Application-level micro-perimeters\n∙ Zero-trust workload access" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Network Security", + "crosswalks": { + "usa-federal-dhs-cisa-tic-3-0": [ + "3.PEP.NE.MICRO" + ], + "usa-federal-dow-zt-roadmap-1-1": [ + "3.4.7", + "5.3.1", + "5.4", + "5.4.1", + "5.4.2", + "5.4.3" + ], + "usa-federal-dow-zta-reference-architecture-2-0": [ + "3.2" + ], + "apac-aus-ism-2026-march": [ + "ISM-1269", + "ISM-1270", + "ISM-1271" + ] + } + }, + { + "control_id": "NET-06.7", + "title": "Software Defined Networking (SDN)", + "family": "NET", + "description": "Automated mechanisms exist to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", + "scf_question": "Does the organization use automated mechanisms to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture?", + "relative_weight": 5, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", + "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "large": "∙ Software-defined networking (SDN) evaluation and planning", + "enterprise": "∙ Enterprise SDN platform (e.g., Cisco ACI, VMware NSX)\n∙ Centralized network policy management\n∙ Automated network provisioning" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Network Security", + "crosswalks": { + "usa-federal-dow-zt-roadmap-1-1": [ + "3.4.7", + "5.2.1", + "5.2.2", + "5.4.2" ] } }, { - "control_id": "NET-06.6", - "title": "Microsegmentation", + "control_id": "NET-06.8", + "title": "Network Device Plane Segmentation", "family": "NET", - "description": "Automated mechanisms exist to enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs.", - "scf_question": "Does the organization use automated mechanisms to enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs?", - "relative_weight": 2, - "conformity_cadence": "Quarterly", + "description": "Automated mechanisms exist to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations.", + "scf_question": "Does the organization use automated mechanisms to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations?", + "relative_weight": 7, + "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Technology", "nist_csf_function": "Protect", "scrm_focus": { "strategic": false, - "operational": false, + "operational": true, "tactical": true }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", - "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable microsegmentation, either physically or virtually, to divide the network according to application and data workflows communications needs.", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Automated mechanisms exist to separate network appliance functions (e.g., management, control and data planes) to prevent ordinary traffic from accessing functions that:\n(1) Manage network appliances; and/or\n(2) Affect network operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [ - "CORE ESP Level 2 Critical Infrastructure", - "CORE ESP Level 3 Advanced Threats" + "Community Derived" ], "possible_solutions": { - "medium": "∙ Plan for microsegmentation as network matures", - "large": "∙ Microsegmentation for high-risk workloads (e.g., VMware NSX)\n∙ Segmentation policy", - "enterprise": "∙ Enterprise microsegmentation platform (e.g., Illumio, VMware NSX)\n∙ Application-level micro-perimeters\n∙ Zero-trust workload access" + "micro_small": "∙ Management VLAN for network device administration\n∙ Out-of-band management interface for network devices", + "small": "∙ Management VLAN for network device administration\n∙ Restrict management access to jump server", + "medium": "∙ Dedicated out-of-band management network\n∙ Separate control plane and data plane configuration\n∙ Management VLAN with strict ACLs", + "large": "∙ Dedicated out-of-band management network (OOB)\n∙ Software-defined networking (SDN) with plane separation\n∙ Management plane protection with strict ACLs", + "enterprise": "∙ Dedicated OOB management network infrastructure\n∙ SDN platform with automated plane segmentation\n∙ Management plane micro-segmentation\n∙ Automated configuration enforcement" }, "risks": [ "R-AC-1", @@ -7257,6 +7531,8 @@ "R-SC-6" ], "threats": [ + "NT-7", + "MT-1", "MT-2", "MT-7", "MT-8", @@ -7269,59 +7545,48 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- new control - SCF community", "family_name": "Network Security", "crosswalks": { - "usa-federal-dhs-cisa-tic-3-0": [ - "3.PEP.NE.MICRO" - ], - "usa-federal-dow-zt-roadmap-1-1": [ - "3.4.7", - "5.3.1", - "5.4", - "5.4.1", - "5.4.2", - "5.4.3" - ], - "usa-federal-dow-zta-reference-architecture-2-0": [ - "3.2" - ], - "apac-aus-ism-2024-june": [ - "ISM-1269", - "ISM-1270", - "ISM-1271" + "emea-deu-c5-2020": [ + "KOS-04" ] } }, { - "control_id": "NET-06.7", - "title": "Software Defined Networking (SDN)", + "control_id": "NET-06.9", + "title": "Separate Subnets To Isolate Functions", "family": "NET", - "description": "Automated mechanisms exist to enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", - "scf_question": "Does the organization enable dynamic, policy-driven network segmentation, access controls and traffic management?", - "relative_weight": 5, - "conformity_cadence": "Quarterly", + "description": "Mechanisms exist to implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 7, + "conformity_cadence": "", "evidence_requests": [], "pptdf": "Technology", "nist_csf_function": "Protect", "scrm_focus": { "strategic": false, "operational": true, - "tactical": false + "tactical": true }, "maturity": { "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", - "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enable dynamic, policy-driven network segmentation, access controls and traffic management with a Software Defined Networking (SDN) architecture.", - "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "2": "Identification & Authentication (IAC) 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:\n▪ Policies and standards associated with IAC domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with IAC domain capabilities are documented and maintained by process owners.\n▪ 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).\n▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.\n▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement physically or logically separate subnetworks to isolate organization-defined Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], "possible_solutions": { - "large": "∙ Software-defined networking (SDN) evaluation and planning", - "enterprise": "∙ Enterprise SDN platform (e.g., Cisco ACI, VMware NSX)\n∙ Centralized network policy management\n∙ Automated network provisioning" + "micro_small": "∙ Subnetting for basic functional isolation\n∙ VLAN segmentation", + "small": "∙ VLAN-based subnet isolation\n∙ Separate subnets for servers, workstations and IoT/OT", + "medium": "∙ Subnet-based micro-segmentation\n∙ Firewall rules between functional subnets\n∙ Network ACLs for inter-subnet traffic", + "large": "∙ Network micro-segmentation\n∙ Host-based firewall enforcement between subnets\n∙ Zero Trust Network Architecture (ZTNA) between segments", + "enterprise": "∙ Enterprise micro-segmentation platform (e.g., Illumio, Guardicore)\n∙ Software-Defined Networking (SDN) for subnet isolation\n∙ ZTNA platform for workload-to-workload access control\n∙ Automated subnet policy enforcement" }, "risks": [ "R-AC-1", @@ -7364,25 +7629,9 @@ "R-SC-6" ], "threats": [ - "NT-2", - "NT-3", - "NT-4", - "NT-5", - "NT-6", "NT-7", - "NT-8", - "NT-9", - "NT-10", - "NT-11", - "NT-12", - "NT-13", - "NT-14", "MT-1", "MT-2", - "MT-3", - "MT-4", - "MT-5", - "MT-6", "MT-7", "MT-8", "MT-9", @@ -7394,15 +7643,32 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "usa-federal-dow-zt-roadmap-1-1": [ - "3.4.7", - "5.2.1", - "5.2.2", - "5.4.2" + "general-nist-800-172-r3": [ + "03.13.09E", + "03.13.15E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.09E.ODP[01]", + "DS-A.03.13.15E", + "A.03.13.15E.ODP[01]", + "A.03.13.15E.ODP[02]" + ], + "emea-isr-cmo-2-0": [ + "Appendix A, 7.5" + ], + "emea-sau-otcc-1-2022": [ + "2-4-1-1", + "2-4-1-5", + "2-4-1-6", + "2-4-1-9", + "2-4-1-10", + "2-4-1-12", + "2-4-1-13" ] } }, @@ -7426,9 +7692,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce network connection terminations at the end of a session or after an entity-defined time period of inactivity.\n▪ SBC terminate remote sessions at the end of the session or after an entity-defined time period of inactivity.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate network connections at the end of a session or after an organization-defined time period of inactivity.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to terminate network connections at the end of a session or after an organization-defined time period of inactivity. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -7480,7 +7746,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -7502,7 +7769,7 @@ "general-iec-62443-4-2-2019": [ "CR 2.6" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -7528,6 +7795,7 @@ "3.13.9" ], "general-nist-800-171-r3": [ + "03.07.05.c", "03.13.09" ], "general-nist-800-171a": [ @@ -7578,10 +7846,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-10" ], - "emea-isr-cmo-1-0": [ - "4.16", - "9.4" - ], "emea-gbr-def-stan-05-138-2024": [ "2303", "2411" @@ -7599,6 +7863,7 @@ "2411" ], "americas-can-itsp-10-171-2025": [ + "03.07.05.C", "03.13.09" ] } @@ -7621,9 +7886,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to employ Network Intrusion Detection / Prevention Systems (NIDS/NIPS) to detect and/or prevent intrusions into the network. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7693,7 +7958,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -7733,6 +7999,10 @@ "03.13.01.a", "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.a[02]", + "A.03.14.06.c[01]" + ], "general-pci-dss-4-0-1": [ "1.4.3", "11.5", @@ -7780,20 +8050,23 @@ "emea-eu-dora-2023": [ "Article 10.2" ], - "emea-isr-cmo-1-0": [ - "7.4", - "7.6", - "12.18", - "23.6" + "emea-deu-c5-2020": [ + "KOS-01", + "KOS-01-DOAR" ], "emea-sau-ecc-1-2018": [ "2-5-3-6" ], + "emea-sau-otcc-1-2022": [ + "2-3-1-12", + "2-3-1-13" + ], "emea-sau-sacs-002-2022": [ - "TPC-77" + "VII.B.TPC-77" ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.com.2", + "mp.com.3" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -7807,19 +8080,23 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1028", "ISM-1030", "ISM-1627", "ISM-1628" ], "apac-sgp-mas-trm-2021": [ - "11.2.3", - "11.2.4" + "11.2.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "americas-arg-ppd-2018": [ + "E.1.2-DS-2" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.4" ], "americas-can-itsp-10-171-2025": [ "03.13.01.A", @@ -7918,7 +8195,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -7940,6 +8218,9 @@ "general-nist-800-171-r3": [ "03.13.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.13.01.b" + ], "general-pci-dss-4-0-1": [ "1.2.1", "1.2.3", @@ -8034,10 +8315,11 @@ "emea-eu-nis2-annex-2024": [ "6.8.2(d)" ], - "emea-sau-sacs-002-2022": [ - "TPC-41" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.1", + "mp.com.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0637" ], "apac-nzl-ism-3-9": [ @@ -8067,7 +8349,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel receive feeds from Wireless Intrusion Detection / Protection Systems (WIDS / WIPS) to identify rogue wireless devices and to detect attack attempts via wireless networks.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize Wireless Intrusion Detection / Protection Systems (WIDS / WIPS) on wireless network segments.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8138,9 +8420,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Network Security", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -8177,26 +8459,6 @@ ], "general-shared-assessments-sig-2025": [ "N.7" - ], - "emea-isr-cmo-1-0": [ - "4.24", - "12.18", - "23.6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-77" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.6.1 [OP.MON.1]" - ], - "apac-nzl-ism-3-9": [ - "21.4.12.C.01", - "21.4.12.C.02", - "21.4.12.C.03" - ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" ] } }, @@ -8218,7 +8480,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically enforce host containment protections that revoke or quarantine a host’s access to the network.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8288,7 +8550,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -8401,7 +8664,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -8412,7 +8676,7 @@ "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.NE.RCONT" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1778", "ISM-1779" ] @@ -8436,9 +8700,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the authenticity and integrity of communications sessions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the authenticity and integrity of communications sessions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8496,7 +8760,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -8521,7 +8786,7 @@ "CR 3.8(b)", "CR 3.8(c)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -8609,12 +8874,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-23" ], - "emea-deu-c5-2020": [ - "PSS-06" - ], - "emea-isr-cmo-1-0": [ - "17.25" - ], "emea-gbr-def-stan-05-138-2024": [ "2414" ], @@ -8650,9 +8909,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically invalidate session identifiers upon user logout or other session termination.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically invalidate session identifiers upon user logout or other session termination. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8706,7 +8965,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -8730,9 +8990,6 @@ ], "usa-federal-irs-1075-2021": [ "SC-23(CE-1)" - ], - "emea-deu-c5-2020": [ - "PSS-06" ] } }, @@ -8788,7 +9045,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -8834,7 +9092,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel ensure Domain Name Service (DNS) resolution is designed, implemented and managed to protect the security of name / address resolution.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure Domain Name Service (DNS) resolution is designed, implemented and managed to protect the security of name / address resolution.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8912,7 +9170,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -8940,7 +9199,7 @@ "general-govramp-high": [ "SC-20" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -9023,11 +9282,10 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(l)" ], - "emea-isr-cmo-1-0": [ - "9.6" + "emea-isr-cmo-2-0": [ + "Appendix A, 7.2" ], "emea-sau-ecc-1-2018": [ - "2-4-3-5", "2-5-3-7" ], "emea-gbr-def-stan-05-138-2024": [ @@ -9042,7 +9300,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0574", "ISM-0861", "ISM-1026", @@ -9051,14 +9309,8 @@ "ISM-1183", "ISM-1540", "ISM-1782", - "ISM-1799" - ], - "apac-nzl-ism-3-9": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" + "ISM-1799", + "ISM-2017" ] } }, @@ -9080,9 +9332,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel ensure systems that collectively provide Domain Name Service (DNS) resolution service for are fault-tolerant and implement internal/external role separation.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure systems that collectively provide Domain Name Service (DNS) resolution service are fault-tolerant and implement internal/external role separation.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure systems that collectively provide Domain Name Service (DNS) resolution service are fault-tolerant and implement internal/external role separation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9155,7 +9407,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -9174,7 +9427,7 @@ "general-govramp-high": [ "SC-22" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -9245,12 +9498,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SC-22" - ], - "emea-isr-cmo-1-0": [ - "9.7" - ], - "apac-nzl-ism-3-9": [ - "15.2.22.C.01" ] } }, @@ -9272,9 +9519,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to perform data origin authentication and data integrity verification on the Domain Name Service (DNS) resolution responses received from authoritative sources when requested by client systems.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to perform data origin authentication and data integrity verification on the Domain Name Service (DNS) resolution responses received from authoritative sources when requested by client systems. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9351,7 +9598,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -9373,7 +9621,7 @@ "general-govramp-high": [ "SC-21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -9442,9 +9690,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SC-21" - ], - "emea-isr-cmo-1-0": [ - "9.7" ] } }, @@ -9466,7 +9711,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to validate the legitimacy of email communications through configuring a Domain Naming Service (DNS) Sender Policy Framework (SPF) record to specify the IP addresses and/or hostnames that are authorized to send email from the specified domain.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9543,7 +9788,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -9559,10 +9805,13 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "2.M" ], + "emea-sau-ecc-1-2018": [ + "2-4-3-5" + ], "emea-sau-sacs-002-2022": [ - "TPC-13", - "TPC-14", - "TPC-15" + "VII.A.TPC-13", + "VII.A.TPC-14", + "VII.A.TPC-15" ], "emea-gbr-def-stan-05-138-2024": [ "2315" @@ -9576,18 +9825,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0574", "ISM-1151", "ISM-1183", "ISM-1799" - ], - "apac-nzl-ism-3-9": [ - "15.2.20.C.01", - "15.2.20.C.02", - "15.2.20.C.03", - "15.2.20.C.04", - "15.2.20.C.05" ] } }, @@ -9687,17 +9929,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1596.002" ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.DO.DNMON" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1432" ] } @@ -9722,7 +9965,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize out-of-band channels for the electronic transmission of information and/or the physical shipment of system components or devices to authorized individuals.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize out-of-band channels for the electronic transmission of information and/or the physical shipment of system components or devices to authorized individuals. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9781,14 +10024,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-csa-iot-2": [ "SWS-09" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1071", "T1071.001", "T1071.002", @@ -9826,9 +10070,6 @@ ], "general-nist-800-161-r1-level-3": [ "SC-37(1)" - ], - "emea-us-psd2-2015": [ - "22" ] } }, @@ -9836,8 +10077,8 @@ "control_id": "NET-12", "title": "Safeguarding Data Over Open Networks", "family": "NET", - "description": "Cryptographic mechanisms exist to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks.", - "scf_question": "Are cryptographic mechanisms utilized to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks?", + "description": "Cryptographic mechanisms exist to implement strong cryptography and security protocols to safeguard sensitive and/or regulated data during transmission over open, public networks.", + "scf_question": "Are cryptographic mechanisms utilized to implement strong cryptography and security protocols to safeguard sensitive and/or regulated data during transmission over open, public networks?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -9852,7 +10093,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). \n▪ Wireless access is protected via secure authentication and encryption.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network communications containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to implement strong cryptography and security protocols to safeguard sensitive/regulated data during transmission over open, public networks. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9929,7 +10170,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -10222,11 +10464,8 @@ "SI-07", "SI-10" ], - "emea-isr-cmo-1-0": [ - "8.4", - "8.6", - "9.20", - "13.6" + "emea-deu-c5-2020": [ + "PI-04" ], "emea-gbr-def-stan-05-138-2024": [ "2305" @@ -10258,9 +10497,6 @@ "14.1.2.13", "14.1.2.14", "14.1.2.15" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS17" ] } }, @@ -10357,7 +10593,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -10367,7 +10604,7 @@ "general-csa-iot-2": [ "SWS-07" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1557.004" ], "general-nist-800-53-r4": [ @@ -10472,8 +10709,8 @@ "control_id": "NET-12.2", "title": "End-User Messaging Technologies", "family": "NET", - "description": "Mechanisms exist to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies.", - "scf_question": "Does the organization prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies?", + "description": "Mechanisms exist to prohibit the transmission of unprotected sensitive and/or regulated data by end-user messaging technologies.", + "scf_question": "Does the organization prohibit the transmission of unprotected sensitive and/or regulated data by end-user messaging technologies?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -10486,9 +10723,9 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prohibit the transmission of unprotected sensitive/regulated data by end-user messaging technologies. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -10572,7 +10809,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -10617,7 +10855,7 @@ }, "maturity": { "0": "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.", - "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", + "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Network communications containing sensitive/regulated data are protected using a cryptographic mechanism to prevent unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.). ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to protect the confidentiality, integrity and availability of electronic messaging communications.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -10702,7 +10940,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -10758,10 +10997,10 @@ "2-3-1", "2-3-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.1 [MP.S.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0264", "ISM-0267", "ISM-0269", @@ -10825,25 +11064,6 @@ "15.1.19.C.01", "15.1.19.C.02", "15.1.20.C.01", - "15.2.25.C.01", - "15.2.25.C.02", - "15.2.26.C.01", - "15.2.27.C.01", - "15.2.28.C.01", - "15.2.29.C.01", - "15.2.30.C.01", - "15.2.30.C.02", - "15.2.30.C.03", - "15.2.31.C.01", - "15.2.31.C.02", - "15.2.32.C.01", - "15.2.32.C.02", - "15.2.32.C.03", - "15.2.33.C.01", - "15.2.33.C.02", - "15.2.33.C.03", - "15.2.33.C.04", - "16.7.33.C.01", "17.6.6.C.01", "17.6.7.C.01" ] @@ -10870,7 +11090,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define, control and review organization-approved, secure remote access methods.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -10951,7 +11171,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -11004,7 +11225,7 @@ "general-iso-27018-2025": [ "6.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1021", "T1021.001", @@ -11143,19 +11364,21 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.12.b", - "03.01.12.c", - "03.01.12.d" + "03.01.12.c" ], "general-nist-800-171a-r3": [ "A.03.01.12.a[01]", "A.03.01.12.a[02]", - "A.03.01.12.a[03]", "A.03.01.12.a[04]", "A.03.01.12.b", "A.03.01.12.c[01]", - "A.03.01.12.c[02]", - "A.03.01.12.d[1]", - "A.03.01.12.d[2]" + "A.03.01.12.c[02]" + ], + "general-nist-800-172-r3": [ + "03.01.06E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.06E" ], "general-pci-dss-4-0-1": [ "3.4.2", @@ -11271,21 +11494,13 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(d)" ], - "emea-isr-cmo-1-0": [ - "4.17" - ], "emea-sau-cscc-1-2019": [ "2-2-1-1", "2-2-1-2" ], "emea-sau-otcc-1-2022": [ - "2-2-1-7" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.7 [OP.ACC.7]" + "2-2-1-7", + "2-4-1-10" ], "emea-gbr-def-stan-05-138-2024": [ "2305" @@ -11299,7 +11514,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2305" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0487", "ISM-0488", "ISM-0489" @@ -11307,9 +11522,6 @@ "apac-ind-sebi-2024": [ "PR.AA.S12" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS13" - ], "apac-nzl-ism-3-9": [ "16.5.10.C.01", "16.5.10.C.02", @@ -11333,7 +11545,7 @@ "03.01.12.A", "03.01.12.B", "03.01.12.C", - "03.01.12.D" + "03.14.08.B" ] } }, @@ -11357,9 +11569,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically monitor and control remote access sessions.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically monitor and control remote access sessions. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -11414,7 +11626,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -11469,6 +11682,16 @@ "3.1.12[c]", "3.1.12[d]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.b" + ], + "general-nist-800-172-r3": [ + "03.01.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.05E[01]", + "DS-A.03.01.05E[02]" + ], "general-nist-800-207": [ "NIST Tenet 5" ], @@ -11493,8 +11716,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (01)" ], - "emea-isr-cmo-1-0": [ - "4.18" + "emea-sau-cscc-1-2019": [ + "2-2-1-2" + ], + "emea-sau-otcc-1-2022": [ + "2-2-1-7" ], "americas-can-itsp-10-171-2025": [ "03.01.12.B" @@ -11519,9 +11745,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of remote access sessions (e.g., VPN).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational cryptographic capability exists to protect the confidentiality and integrity of remote access sessions (e.g., VPN). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -11580,7 +11806,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -11636,6 +11863,9 @@ "3.1.13[a]", "3.1.13[b]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.a[04]" + ], "general-nist-800-207": [ "NIST Tenet 2" ], @@ -11663,8 +11893,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (02)" ], - "emea-isr-cmo-1-0": [ - "9.8" + "emea-sau-otcc-1-2022": [ + "2-2-1-7" ], "emea-gbr-def-stan-05-138-2024": [ "2305", @@ -11682,6 +11912,9 @@ "2305", "2306" ], + "apac-aus-cop-sitc-2020": [ + "7" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A" ] @@ -11784,7 +12017,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -11833,13 +12067,16 @@ "3.1.14" ], "general-nist-800-171-r3": [ - "03.01.12.b", "03.01.12.c" ], "general-nist-800-171a": [ "3.1.14[a]", "3.1.14[b]" ], + "general-nist-800-171a-r3": [ + "A.03.01.12.c[01]", + "A.03.01.12.c[02]" + ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EN.VPNET" ], @@ -11868,8 +12105,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (03)" ], - "emea-isr-cmo-1-0": [ - "4.19" + "emea-sau-otcc-1-2022": [ + "2-4-1-7" ], "emea-gbr-def-stan-05-138-2024": [ "2307" @@ -11884,7 +12121,6 @@ "2307" ], "americas-can-itsp-10-171-2025": [ - "03.01.12.B", "03.01.12.C" ] } @@ -11909,7 +12145,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Network communications containing sensitive/regulated data use a cryptographic mechanism to prevent the unauthorized disclosure of information while in transit (e.g., SSH, TLS, VPN, etc.).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to restrict the execution of privileged commands and access to security-relevant information via remote access only for compelling operational needs.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to restrict the execution of privileged commands and access to security-relevant information via remote access only for compelling operational needs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -11967,7 +12203,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -12039,12 +12276,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (04)" ], - "emea-isr-cmo-1-0": [ - "4.17", - "4.20" - ], "emea-sau-sacs-002-2022": [ - "TPC-35" + "VII.B.TPC-35" ], "emea-gbr-def-stan-05-138-2024": [ "2417" @@ -12088,9 +12321,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define secure telecommuting practices and govern remote access to TAASD for remote workers.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to define secure telecommuting practices and govern remote access to TAASD for remote workers. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12182,7 +12415,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -12213,11 +12447,11 @@ ], "general-nist-800-171-r3": [ "03.01.12.a", - "03.01.12.c", "03.10.06.a", "03.10.06.b" ], "general-nist-800-171a-r3": [ + "A.03.01.12.a[01]", "A.03.10.06.ODP[01]", "A.03.10.06.a", "A.03.10.06.b" @@ -12245,10 +12479,6 @@ "2-2-1-1", "2-2-1-2" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.7 [OP.ACC.7]", - "9" - ], "emea-gbr-def-stan-05-138-2024": [ "2305" ], @@ -12286,26 +12516,16 @@ "6.2.2.20", "6.2.2.21" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS13" - ], "apac-nzl-ism-3-9": [ "21.2.4.C.01", - "21.2.4.C.02", "21.2.5.C.01", "21.2.6.C.01", "21.2.7.C.01", - "21.2.7.C.02", - "21.3.5.C.01", - "21.3.6.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "9.3.1", - "9.3.2" + "22.2.4.C.01", + "22.2.4.C.02" ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", - "03.01.12.C", "03.10.06.A", "03.10.06.B" ] @@ -12331,7 +12551,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to proactively control and monitor third-party accounts used to access, support, or maintain system components via remote access.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -12420,7 +12640,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -12450,9 +12671,6 @@ "CIP-005-7 2.5", "CIP-005-7 3.1", "CIP-005-7 3.2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-35" ] } }, @@ -12461,7 +12679,7 @@ "title": "Endpoint Security Validation", "family": "NET", "description": "Automated mechanisms exist to validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS)?", + "scf_question": "Does the organization use automated mechanisms to validate the security posture of the endpoint devices (e.g., software versions, patch levels, etc.) prior to allowing devices to connect to organizational Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 6, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -12545,7 +12763,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -12613,7 +12832,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ IT and/or cybersecurity personnel provide the capability to expeditiously disconnect or disable a user's remote access session.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to provide the capability to expeditiously disconnect or disable a user's remote access session.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -12691,7 +12910,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -12735,7 +12955,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-17 (09)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1591" ] } @@ -12844,7 +13064,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -12882,7 +13103,7 @@ "general-iso-27018-2025": [ "8.21" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011", "T1011.001", "T1020.001", @@ -12965,7 +13186,8 @@ "general-nist-800-171a-r3": [ "A.03.01.16.a[01]", "A.03.01.16.a[02]", - "A.03.01.16.a[04]" + "A.03.01.16.a[04]", + "A.03.01.16.b" ], "general-nist-800-207": [ "NIST Tenet 2" @@ -13029,22 +13251,22 @@ "usa-state-tx-txramp-2-0-level-2": [ "AC-18" ], - "emea-isr-cmo-1-0": [ - "4.24", - "12.12", - "12.14" - ], "emea-sau-cscc-1-2019": [ "2-3-1-5", "2-4-1-4" ], + "emea-sau-ecc-1-2018": [ + "2-5-3-4" + ], "emea-sau-otcc-1-2022": [ - "2-4-1-4", - "2-4-1-5" + "2-4-1-4" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.com.2", + "mp.com.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0225", - "ISM-0248", "ISM-0536", "ISM-1314", "ISM-1315", @@ -13162,7 +13384,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -13209,6 +13432,8 @@ "3.1.17[b]" ], "general-nist-800-171a-r3": [ + "A.03.01.16.a[04]", + "A.03.01.16.b", "A.03.01.16.d[01]", "A.03.01.16.d[02]" ], @@ -13268,8 +13493,11 @@ "emea-eu-nis2-annex-2024": [ "11.4.2(c)" ], - "emea-isr-cmo-1-0": [ - "12.14" + "emea-sau-ecc-1-2018": [ + "2-5-3-4" + ], + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-42" ], "emea-gbr-def-stan-05-138-2024": [ "2304" @@ -13300,6 +13528,8 @@ "18.2.17.C.01", "18.2.18.C.01", "18.2.19.C.01", + "18.2.19.C.02", + "18.2.19.C.03", "18.2.20.C.01", "18.2.20.C.02", "18.2.20.C.03", @@ -13337,7 +13567,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to disable unnecessary wireless networking capabilities that are internally embedded within system components prior to issuance to end users.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to disable unnecessary wireless networking capabilities that are internally embedded within system components prior to issuance to end users. ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -13390,7 +13620,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -13421,6 +13652,9 @@ "general-nist-800-171-r3": [ "03.01.16.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.c" + ], "general-shared-assessments-sig-2025": [ "U.1.2" ], @@ -13436,16 +13670,9 @@ "usa-federal-irs-1075-2021": [ "AC-18(CE-3)" ], - "emea-isr-cmo-1-0": [ - "4.24" - ], "emea-sau-cscc-1-2019": [ "2-4-1-4" ], - "apac-nzl-ism-3-9": [ - "21.1.16.C.01", - "21.1.16.C.02" - ], "americas-can-itsp-10-171-2025": [ "03.01.16.C" ] @@ -13471,7 +13698,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to identify and explicitly authorize users who are allowed to independently configure wireless networking capabilities.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to identify and explicitly authorize users who are allowed to independently configure wireless networking capabilities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -13533,7 +13760,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -13562,12 +13790,13 @@ "03.01.16.a", "03.01.16.c" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[03]", + "A.03.01.16.c" + ], "usa-federal-gsa-fedramp-5-high": [ "AC-18(04)" ], - "emea-isr-cmo-1-0": [ - "12.13" - ], "americas-can-itsp-10-171-2025": [ "03.01.16.A", "03.01.16.C" @@ -13594,7 +13823,7 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to confine wireless communications to organization-controlled boundaries.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to confine wireless communications to organization-controlled boundaries. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -13666,7 +13895,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -13694,10 +13924,7 @@ "usa-federal-gsa-fedramp-5-high": [ "AC-18(05)" ], - "emea-isr-cmo-1-0": [ - "4.23" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1013", "ISM-1338" ], @@ -13728,9 +13955,9 @@ "0": "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.", "1": "Network Security (NET) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with NET domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Network security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to test for the presence of Wireless Access Points (WAPs) and identify all authorized and unauthorized WAPs within the facility(ies).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to test for the presence of Wireless Access Points (WAPs) and identify all authorized and unauthorized WAPs within the facility(ies). ", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -13802,7 +14029,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -13825,8 +14053,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "AC-18-SID.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0829" + ], + "apac-nzl-ism-3-9": [ + "22.4.12.C.02", + "22.4.12.C.03" ] } }, @@ -13835,7 +14067,7 @@ "title": "Intranets", "family": "NET", "description": "Mechanisms exist to establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS.", - "scf_question": "Does the organization establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n (1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n (2) Process, store, and/or transmit organization-controlled information using the external systems?", + "scf_question": "Does the organization establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13848,7 +14080,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to establish trust relationships with other organizations owning, operating, and/or maintaining intranet systems, allowing authorized individuals to: \n(1) Access the intranet from external Technology Assets, Applications and/or Services (TAAS); and\n(2) Process, store, and/or transmit organization-controlled information using the external TAAS.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13933,7 +14165,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": {} @@ -13960,7 +14193,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ Data Loss Prevention (DLP), or similar technologies, prevent unauthorized devices from connecting to endpoint devices to control the distribution of sensitive/regulated data.\n▪ DLP prevents unauthorized devices from connecting to endpoint devices to control the distribution of sensitive/regulated data.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically implement Data Loss Prevention (DLP) to protect sensitive information as it is stored, transmitted and processed.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -13998,7 +14231,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -14050,6 +14284,12 @@ "SC-07(10)", "SI-04(18)" ], + "general-nist-800-172-r3": [ + "03.01.17E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.01.17E.a" + ], "general-pci-dss-4-0-1": [ "A3.2.6" ], @@ -14116,16 +14356,25 @@ "apac-ind-sebi-2024": [ "PR.DS.S4" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP63", "HML69" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP55" ], - "amaericas-can-osfi-self-assessment": [ - "4.1", - "4.2" + "apac-nzl-ism-3-9": [ + "15.2.39.C.01", + "15.2.40.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.1.1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-DS-3" + ], + "americas-bmu-mba-coc-2020": [ + "6.9" ], "americas-can-osfi-b13-2022": [ "3.2.5" @@ -14156,7 +14405,7 @@ "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce Internet-bound network traffic routing through a proxy device for URL content filtering to limit a user's ability to connect to prohibited content.\n▪ Content filtering blocks users from performing ad hoc file transfers through unapproved file transfer services (e.g., Box, Dropbox, Google Drive, etc.).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to force Internet-bound network traffic through a proxy device (e.g., Policy Enforcement Point (PEP)) for URL content filtering and DNS filtering to limit a user's ability to connect to dangerous or prohibited Internet sites.", "4": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Network Security (NET) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -14232,15 +14481,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "9.2", "9.3", - "13.1" + "13.10" ], "general-cis-csc-8-1-ig1": [ "9.2" @@ -14252,7 +14502,7 @@ "general-cis-csc-8-1-ig3": [ "9.2", "9.3", - "13.1" + "13.10" ], "general-govramp": [ "SC-07(08)" @@ -14309,6 +14559,9 @@ "general-nist-800-171-r3": [ "03.14.06.c" ], + "general-nist-800-171a-r3": [ + "A.03.14.06.c[02]" + ], "general-nist-csf-2-0": [ "DE.CM-03" ], @@ -14375,15 +14628,21 @@ "emea-eu-nis2-annex-2024": [ "6.7.2(l)" ], - "emea-isr-cmo-1-0": [ - "9.14" - ], "emea-sau-ecc-1-2018": [ - "2-5-3-3", - "2-5-3-8" + "2-5-3-3" ], "emea-sau-sacs-002-2022": [ - "TPC-57" + "VII.B.TPC-57", + "VII.B.TPC-57-BP1", + "VII.B.TPC-57-BP2", + "VII.B.TPC-57-BP3" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.s.1", + "mp.s.3" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "5-BP1-4" ], "emea-gbr-def-stan-05-138-2024": [ "2411" @@ -14397,7 +14656,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2411" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0267", "ISM-0649", "ISM-0659", @@ -14412,7 +14671,8 @@ "ISM-1287", "ISM-1293", "ISM-1502", - "ISM-1524" + "ISM-1524", + "ISM-1965" ], "apac-nzl-ism-3-9": [ "9.3.6.C.01", @@ -14426,27 +14686,16 @@ "14.3.11.C.01", "14.3.11.C.02", "14.3.12.C.01", - "20.3.4.C.01", - "20.3.4.C.02", - "20.3.5.C.01", - "20.3.5.C.02", - "20.3.6.C.01", - "20.3.7.C.01", - "20.3.7.C.02", - "20.3.8.C.01", "20.3.9.C.01", "20.3.10.C.01", "20.3.11.C.01", "20.3.11.C.02", - "20.3.11.C.03", - "20.3.12.C.01", - "20.3.12.C.02", - "20.3.13.C.01", - "20.3.13.C.02", - "20.3.14.C.01", - "20.3.15.C.01", - "20.3.15.C.02", - "20.3.16.C.01" + "21.3.7.C.01", + "21.3.7.C.02", + "21.3.14.C.01" + ], + "apac-sgp-mas-trm-2021": [ + "11.2.7" ], "americas-can-itsp-10-171-2025": [ "03.14.06.C" @@ -14473,9 +14722,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ SBC enforce Internet-bound network traffic routing through a proxy device for URL content filtering to limit a user's ability to connect to prohibited content.", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to route internal communications traffic to external networks through organization-approved proxy servers at managed interfaces.", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to route internal communications traffic to external networks through organization-approved proxy servers at managed interfaces. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -14548,15 +14797,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { "general-cis-csc-8-1": [ - "13.1" + "13.10" ], "general-cis-csc-8-1-ig3": [ - "13.1" + "13.10" ], "general-govramp": [ "SC-07(08)" @@ -14616,16 +14866,13 @@ "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.1.b" ], - "emea-isr-cmo-1-0": [ - "9.14" - ], "emea-sau-cscc-1-2019": [ "2-4-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-5-3-8" + "emea-sau-otcc-1-2022": [ + "2-4-1-11" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0260", "ISM-0570", "ISM-1237" @@ -14633,7 +14880,8 @@ "apac-nzl-ism-3-9": [ "14.3.6.C.01", "14.3.6.C.02", - "14.3.6.C.03" + "14.3.6.C.03", + "15.2.46.C.02" ] } }, @@ -14655,7 +14903,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to configure the proxy to make encrypted communications traffic visible to monitoring tools and mechanisms.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14731,7 +14979,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -14759,13 +15008,12 @@ "usa-federal-irs-1075-2021": [ "SI-4(CE-10)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0263" ], "apac-nzl-ism-3-9": [ "14.3.8.C.01", - "14.3.9.C.01", - "20.3.14.C.01" + "14.3.9.C.01" ] } }, @@ -14787,7 +15035,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically route networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14843,7 +15091,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -14879,7 +15128,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to automatically ensure network traffic complies with Internet Engineering Task Force (IETF) protocol specifications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14946,7 +15195,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -14974,7 +15224,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to ensure that domain name lookups, whether for internal or external domains, are validated according to Domain Name System Security Extensions (DNSSEC).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15040,7 +15290,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15067,7 +15318,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement Internet address denylisting protections that blocks traffic received from or destined to a denylisted Internet address.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15133,7 +15384,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15160,7 +15412,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement bandwidth control technologies to limit the amount of bandwidth used by categories of domains that are bandwidth-intensive.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15225,7 +15477,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15252,7 +15505,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to force systems and processes to authenticate Internet-bound traffic with a proxy to enable user, group and/or location-aware security controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15317,7 +15570,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15344,7 +15598,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to prevent communication with Technology Assets, Applications and/or Services (TAAS) that use a set of known bad certificates.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15410,7 +15664,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15424,7 +15679,7 @@ "title": "Content Disarm and Reconstruction (CDR)", "family": "NET", "description": "Automated Content Disarm and Reconstruction (CDR) mechanisms exist to detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements.", - "scf_question": "Automated Content Disarm and Reconstruction (CDR) Does the organization detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements?", + "scf_question": "Does the organization use automated Content Disarm and Reconstruction (CDR) mechanisms exist to detect the presence of unapproved active content and facilitate its removal, resulting in content with only known safe elements?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -15437,7 +15692,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational Content Disarm and Reconstruction (CDR) capability detects the presence of unapproved active content and facilitates its removal, resulting in content with only known safe elements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15503,7 +15758,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15530,7 +15786,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement an email filtering security service to detect malicious attachments in emails and prevent users from accessing them.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15596,7 +15852,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15623,7 +15880,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to monitor the organization's email domain’s reputation and protect the email domain’s reputation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15689,7 +15946,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15716,7 +15974,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement sender denylisting protections that prevent the reception of email from denylisted senders, domains and/or email servers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15782,7 +16040,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15809,7 +16068,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize an authenticated received chain that allows for an intermediary to sign its own authentication of the original email, allowing downstream entities to accept the intermediary’s authentication even if the email was changed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15873,7 +16132,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15900,9 +16160,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement domain signature verification protections that authenticate incoming email according to the Domain-based Message Authentication Reporting and Conformance (DMARC).", + "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to implement domain signature verification protections that authenticate incoming email according to the Domain-based Message Authentication Reporting and Conformance (DMARC).\n", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -15966,7 +16226,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -15994,8 +16255,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2315" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1540" + ], + "apac-nzl-ism-3-9": [ + "15.2.36.C.01", + "15.2.36.C.02", + "15.2.36.C.03", + "15.2.36.C.04", + "15.2.36.C.05" ] } }, @@ -16017,7 +16285,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are documented and maintained by process owners.\n▪ 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 NET domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Network security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Network security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT personnel define secure networking practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable users to digitally sign their emails, allowing external parties to authenticate the email’s sender and its contents according to the Domain-based Message Authentication Reporting and Conformance (DMARC) email authentication protocol.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16081,7 +16349,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -16109,7 +16378,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to enable the encryption of outgoing emails using organization-approved cryptographic means.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16175,7 +16444,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -16202,7 +16472,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Network Security (NET) 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:\n▪ Policies and standards associated with NET domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with NET domain capabilities are well-documented and kept current by process owners.\n▪ A network security management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of network security operations (e.g., network management solution, log aggregator, etc.).\n▪ 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 NET 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).\n▪ Secure Baseline Configurations (SBC) enforce the principles of least privileges and least functionality for boundary protection technologies.\n▪ An implemented and operational capability exists to utilize adaptive email protections that involve employing risk-based analysis in the application and enforcement of email protections.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16268,7 +16538,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -16287,7 +16558,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2509" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0567" ] } @@ -16376,7 +16647,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { @@ -16469,7 +16741,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Network Security", "crosswalks": { diff --git a/docs/api/families/OPS.json b/docs/api/families/OPS.json index c8d42743..b6bfecd2 100644 --- a/docs/api/families/OPS.json +++ b/docs/api/families/OPS.json @@ -112,7 +112,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -139,7 +140,7 @@ "7.5.3(a)", "7.5.3(b)" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025" ], @@ -188,6 +189,9 @@ "03.15.01.a", "03.15.01.b" ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[03]" + ], "general-nist-csf-2-0": [ "ID.IM" ], @@ -302,54 +306,14 @@ "Article 9.1", "Article 9.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-c5-2020": [ - "SP-01" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 8.1", - "Article 8.2", - "Article 8.3", - "Article 8.4", - "Article 8.5" - ], - "emea-esp-decree-311-2022": [ - "8.1", - "8.2", - "8.3", - "8.4", - "8.5" - ], - "apac-chn-pipl-2021": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "emea-esp-ccn-stic-825-2026": [ + "org.3" ], "apac-jpn-ismap": [ "12", "12.1", "12.1.3.9.PB" ], - "apac-sgp-mas-trm-2021": [ - "7.1.1" - ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "1.5" - ], "americas-can-osfi-b13-2022": [ "3" ], @@ -379,7 +343,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to identify and document Standardized Operating Procedures (SOP), or similar documentation, to enable the proper execution of day-to-day / assigned tasks.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -450,7 +414,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -534,9 +499,46 @@ ], "general-nist-800-171a-r3": [ "A.03.15.01.a[03]", - "A.03.15.01.a[04]", - "A.03.15.01.b[01]", - "A.03.15.01.b[02]" + "A.03.15.01.a[04]" + ], + "general-nist-800-172-r3": [ + "03.02.01E", + "03.08.03E", + "03.09.03E", + "03.11.02E", + "03.12.01E", + "03.13.05E", + "03.13.07E", + "03.14.08E", + "03.14.15E", + "03.15.01E", + "03.17.02E" + ], + "general-nist-800-172a-r3": [ + "A.03.02.01E.ODP[02]", + "A.03.08.03E.ODP[01]", + "A.03.08.03E.ODP[02]", + "DS-A.03.09.03E.b[01]", + "A.03.09.03E.ODP[01]", + "DS-A.03.09.03E.b[02]", + "DS-A.03.09.03E.c.02", + "A.03.09.03E.ODP[02]", + "A.03.11.02E.ODP[01]", + "A.03.12.01E.ODP[01]", + "A.03.12.04E.ODP[03]", + "A.03.13.05E.ODP[02]", + "A.03.13.05E.ODP[03]", + "A.03.13.07E.ODP[01]", + "A.03.14.05E.ODP[02]", + "A.03.14.05E.ODP[03]", + "A.03.14.05E.ODP[04]", + "A.03.14.08E.ODP[08]", + "A.03.14.08E.ODP[09]", + "A.03.14.08E.ODP[12]", + "A.03.14.15E.ODP[03]", + "A.03.15.01E.ODP[01]", + "A.03.17.02E.ODP[02]", + "A.03.17.02E.ODP[03]" ], "general-nist-800-218": [ "PO.3.2", @@ -746,12 +748,12 @@ "314.4(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-cms-marse-2-0": [ "AC-1.b", @@ -788,16 +790,9 @@ "500.8(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.2.(31)", - "3.4.2(31)(a)", - "3.4.2(31)(b)", - "3.4.2(31)(c)", - "3.4.2(31)(d)", - "3.4.2(31)(e)", - "3.4.2(31)(f)", - "3.4.2(31)(g)", - "3.4.5(38)", - "3.5(50)" + "3.4.2.31", + "3.4.4.36", + "3.5.50" ], "emea-eu-dora-2023": [ "Article 6.2", @@ -808,31 +803,14 @@ "7.1", "9.1" ], - "emea-deu-c5-2020": [ - "SP-01", - "IDM-02" - ], - "emea-isr-cmo-1-0": [ - "12.2", - "12.3", - "18.2", - "22.2" - ], "emea-sau-cgiot-2024": [ "1-2-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2(d)", - "Article 13.4", - "Article 22.2" - ], - "emea-esp-decree-311-2022": [ - "13.2(d)", - "13.4", - "22.2" + "emea-sau-ecc-1-2018": [ + "1-3-4" ], - "emea-esp-ccn-stic-825-2023": [ - "6.3 [ORG.3]" + "emea-esp-ccn-stic-825-2026": [ + "org.3" ], "emea-gbr-def-stan-05-138-2024": [ "1100", @@ -853,15 +831,6 @@ "2100", "2101" ], - "apac-chn-pipl-2021": [ - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" - ], "apac-ind-sebi-2024": [ "PR.AA.S14", "PR.IP.S7", @@ -886,6 +855,9 @@ "12.1.5.P", "12.1.5.1.PB" ], + "apac-mys-bnm-rmit-2025": [ + "10.27" + ], "apac-nzl-hisf-suppliers-2023": [ "HSUP01" ], @@ -897,15 +869,35 @@ "5.5.3.C.01", "5.5.4.C.01", "5.5.5.C.01", - "5.5.6.C.01" + "5.5.6.C.01", + "16.1.24.C.01", + "20.2.15.C.01", + "21.1.7.C.01", + "21.1.7.C.02" + ], + "americas-arg-ppd-2018": [ + "B.1.3-1", + "B.1.3-2", + "B.1.3-3", + "B.2.4-2", + "B.2.5" + ], + "americas-bmu-mba-coc-2020": [ + "5.9-BP4" ], "americas-can-osfi-b13-2022": [ "2.2.1", "2.8", "3" ], + "americas-can-osfi-self-assessment-2": [ + "2.7.2" + ], "americas-can-itsp-10-171-2025": [ "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.2" ] } }, @@ -929,7 +921,7 @@ "0": "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.", "1": "Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cybersecurity operations are primarily viewed as additional duties for IT staff.\n▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage.", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", - "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to develop a security Concept of Operations (CONOPS), or a similarly-defined plan for achieving cybersecurity objectives, that documents management, operational and technical measures implemented to apply defense-in-depth techniques that is communicated to all appropriate stakeholders.", + "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to develop a security Concept of Operations (CONOPS), or a similarly-defined plan for achieving cybersecurity objectives, that documents management, operational and technical measures implemented to apply defense-in-depth techniques that is communicated to all appropriate stakeholders. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -993,7 +985,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -1029,18 +1022,21 @@ "8.1.1" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(6)" + "3.2.2.6" ], "emea-eu-dora-2023": [ "Article 9.1", "Article 9.2" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 1.2" + ], + "emea-sau-cscc-1-2019": [ + "1-1-1" + ], "apac-nzl-ism-3-9": [ "5.1.15.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "4.30" - ], "americas-can-osfi-b13-2022": [ "1.3.2" ] @@ -1066,7 +1062,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to define supporting business processes and implement appropriate governance and service management to ensure appropriate planning, delivery and support of the organization's technology capabilities supporting business functions, workforce, and/or customers based on industry-recognized standards to achieve the specific goals of the process area.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1137,7 +1133,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -1232,7 +1229,10 @@ "164.316(b)" ], "general-nist-800-171-r3": [ - "03.15.01.b" + "03.15.01.a" + ], + "general-nist-800-171a-r3": [ + "A.03.15.01.a[04]" ], "general-nist-800-218": [ "PO.3.2" @@ -1247,14 +1247,14 @@ "11.10" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.312(e)(2)(ii)", - "164.316(b)(2)(ii)" + "§ 164.310(b)", + "§ 164.312(e)(2)(ii)", + "§ 164.316(b)(2)(ii)" ], "usa-federal-cms-marse-2-0": [ "IP-4", @@ -1266,7 +1266,6 @@ ], "emea-deu-bsrit-2017": [ "8.1", - "8.2", "11.1", "11.2", "11.3", @@ -1276,8 +1275,11 @@ "11.7", "11.8" ], - "apac-chn-pipl-2021": [ - "51" + "emea-esp-ccn-stic-825-2026": [ + "org.3" + ], + "apac-aus-ps-cps-230-2023": [ + "12(b)" ], "apac-jpn-ismap": [ "13.1.1.11.P", @@ -1286,19 +1288,24 @@ "14.1.1.19.P", "14.1.1.20.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.31" + ], "apac-sgp-mas-trm-2021": [ "7.1.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "1.5" - ], "americas-can-osfi-b13-2022": [ "2.2.1", "2.8" ], + "americas-can-osfi-self-assessment-2": [ + "2.8.1" + ], "americas-can-itsp-10-171-2025": [ - "03.15.01.B" + "03.15.01.A" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.2" ] } }, @@ -1322,7 +1329,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to establish and maintain a Security Operations Center (SOC) that facilitates a 24x7 response capability.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1396,7 +1403,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -1423,8 +1431,12 @@ "general-nist-800-161-r1-level-3": [ "SC-38" ], - "general-nist-800-172": [ - "3.6.1e" + "general-nist-800-172-r3": [ + "03.06.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.06.01E[01]", + "DS-A.03.06.01E[02]" ], "usa-federal-dow-cmmc-2-level-3": [ "IR.L3-3.6.1E" @@ -1449,11 +1461,8 @@ "apac-ind-sebi-2024": [ "DE.CM.S1" ], - "apac-sgp-mas-trm-2021": [ - "12.2.1" - ], - "amaericas-can-osfi-self-assessment": [ - "1.4" + "apac-mys-bnm-rmit-2025": [ + "11.9" ] } }, @@ -1475,7 +1484,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.", "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to provide guidelines and recommendations for the secure use of Technology Assets, Applications and/or Services (TAAS) to assist in the configuration, installation and use of the product and/or service.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1547,7 +1556,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -1560,13 +1570,6 @@ ], "usa-federal-dow-zt-roadmap-1-1": [ "6.5.3" - ], - "emea-deu-c5-2020": [ - "PSS-01" - ], - "amaericas-can-osfi-self-assessment": [ - "4.29", - "4.30" ] } }, @@ -1639,13 +1642,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { - "general-nist-800-172": [ - "3.11.3e" - ], "usa-federal-dhs-cisa-tic-3-0": [ "3.PEP.EN.SOARE" ], @@ -1659,6 +1660,9 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.D.2.d" + ], + "americas-can-osfi-self-assessment-2": [ + "3.3.2" ] } }, @@ -1682,7 +1686,7 @@ "0": "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.", "1": "Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Cybersecurity operations are primarily viewed as additional duties for IT staff.\n▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage.", "2": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are documented and maintained by process owners.\n▪ 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security operations management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ An implemented and operational capability exists to detect the presence of unauthorized Technology Assets, Applications and/or Services (TAAS) in use.", + "3": "Security Operations (OPS) 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:\n▪ Policies and standards associated with OPS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with OPS domain capabilities are well-documented and kept current by process owners.\n▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).\n▪ 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 OPS 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).\n▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.\n▪ An implemented and operational capability exists to detect the presence of unauthorized Technology Assets, Applications and/or Services (TAAS) in use.", "4": "Security Operations (OPS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1778,7 +1782,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Operations", "crosswalks": { @@ -1787,6 +1792,13 @@ ], "apac-ind-sebi-2024": [ "ID.AM.S3" + ], + "apac-mys-bnm-rmit-2025": [ + "10.16" + ], + "apac-sgp-mas-trm-2021": [ + "6.5.1", + "6.5.2" ] } } diff --git a/docs/api/families/PES.json b/docs/api/families/PES.json index 846d1afc..122323b6 100644 --- a/docs/api/families/PES.json +++ b/docs/api/families/PES.json @@ -26,7 +26,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ The Human Resources (HR) department maintains a current list of personnel with authorized access to organizational facilities and facilitates the implementation of physical access management controls.\n▪ Physical security controls and technologies ensure that only authorized personnel are allowed access to secure areas.\n▪ A facilities maintenance team, or similar function, manages the operation of automated physical and environmental protection controls.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to facilitate the operation of physical and environmental protection controls.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to facilitate the operation of physical and environmental protection controls. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -123,7 +123,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -265,7 +266,8 @@ "03.08.01", "03.08.02", "03.10.01.a", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "general-nist-800-171a": [ "3.10.2[a]", @@ -273,6 +275,15 @@ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.01.a[01]", + "A.03.10.01.a[02]", + "A.03.10.01.a[03]", + "A.03.10.07.a.01" + ], "general-nist-csf-2-0": [ "ID.AM", "PR.AA", @@ -303,9 +314,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-sparta": [ "CM0053" ], @@ -351,14 +359,14 @@ "PE-23" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(1)", - "164.310(a)(2)(ii)", - "164.310(a)(2)(iv)" + "§ 164.310(a)(1)", + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "2.B.2", @@ -396,7 +404,7 @@ "PE-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(33)" + "3.4.3.33" ], "emea-eu-nis2-annex-2024": [ "13.1.1", @@ -407,56 +415,45 @@ "13.3.2(a)", "13.3.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-c5-2020": [ - "PS-01" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "12.27", - "18.1", - "18.2", - "18.10" - ], - "emea-sau-cscc-1-2019": [ - "2-3" + "PS-01", + "PS-02", + "PS-03" ], "emea-sau-ecc-1-2018": [ "2-3-1", "2-3-2", - "2-3-4", "2-14-1", "2-14-2", - "2-14-3", + "2-14-3-1", + "2-14-3-2", + "2-14-3-3", + "2-14-3-5", "2-14-4" ], "emea-sau-otcc-1-2022": [ - "2-13", + "2-3-1", + "2-3-2", "2-13-1", - "2-13-1-8", - "2-13-1-9", "2-13-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-46" - ], "emea-sau-sama-csf-1-2017": [ - "3.3.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 18" + "3.3.2", + "3.3.2.1", + "3.3.2.3" ], "emea-esp-decree-311-2022": [ - "18" + "Article 12(6)(f)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.s.1" ], "emea-uae-niaf-2023": [ "3.2.2" @@ -473,7 +470,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0810" ], "apac-ind-sebi-2024": [ @@ -488,7 +485,7 @@ "11.1.4.1", "11.2.1.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP47", "HML47" ], @@ -498,27 +495,28 @@ ], "apac-nzl-ism-3-9": [ "5.7.4.C.01", - "8.1.10.C.01" + "8.1.10.C.01", + "20.2.16.C.01" ], "apac-sgp-mas-trm-2021": [ - "8.5.1", - "8.5.2", "8.5.5", - "8.5.6(a)", - "8.5.6(b)", - "8.5.6(c)", - "8.5.6(d)", - "8.5.6(e)", - "8.5.6(f)" + "8.5.6" ], "americas-can-osfi-b13-2022": [ "3.2.10" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.02", "03.10.01.A", - "03.10.07.A" + "03.10.07.A", + "03.10.07.A.01" + ], + "americas-can-pipeda-2000": [ + "P7-4.7.3(a)" ] } }, @@ -527,7 +525,7 @@ "title": "Physical Security Plan (PSP)", "family": "PES", "description": "Mechanisms exist to document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats.", - "scf_question": "Does the organization document a Site Security Plan (SitePlan) for each server and communications room to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats?", + "scf_question": "Does the organization document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats?", "relative_weight": 4, "conformity_cadence": "Annual", "evidence_requests": [ @@ -542,7 +540,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to document a Physical Security Plan (PSP), or similar document, to summarize the implemented security controls to protect physical access to technology assets, as well as applicable risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -611,7 +609,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -622,13 +621,14 @@ "CIP-006-6 R1", "CIP-006-6 1.1" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-deu-c5-2020": [ + "PS-02", + "PS-03" ], "apac-ind-sebi-2024": [ "PR.IP.S9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP13", "HML13" ], @@ -637,6 +637,9 @@ ], "apac-nzl-ism-3-9": [ "8.2.7.C.01" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" ] } }, @@ -729,7 +732,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -738,6 +742,10 @@ ], "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.2" + ], + "emea-deu-c5-2020": [ + "PS-01-DOAR", + "PS-03-BP1" ] } }, @@ -837,7 +845,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -932,13 +941,15 @@ "3.10.1" ], "general-nist-800-171-r3": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.a", "03.10.01.b", "03.10.01.c", "03.10.01.d", - "03.10.07.a" + "03.10.07.a", + "03.10.07.a.01" ], "general-nist-800-171a": [ "3.10.1[a]", @@ -948,10 +959,14 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[02]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", "A.03.10.01.a[01]", "A.03.10.01.a[02]", "A.03.10.01.a[03]", + "A.03.10.01.b", "A.03.10.01.c", "A.03.10.01.d", "A.03.10.07.a.01" @@ -988,9 +1003,6 @@ "9.2.1", "9.3.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -1031,13 +1043,16 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PE-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)", - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(i)", + "§ 164.310(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.B.3.2", @@ -1074,24 +1089,23 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-02" ], + "emea-eu-eba-ict-srm-2025": [ + "3.4.3.34" + ], "emea-eu-nis2-annex-2024": [ "13.3.1" ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.3" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" - ], "emea-sau-otcc-1-2022": [ "2-13-1-1" ], "emea-sau-sacs-002-2022": [ - "TPC-86" + "VII.B.TPC-86" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" ], "emea-gbr-def-stan-05-138-2024": [ "1500" @@ -1109,7 +1123,7 @@ "11.1.2.3", "11.1.2.12" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP04", "HML04" ], @@ -1123,14 +1137,19 @@ "apac-sgp-mas-trm-2021": [ "8.5.6(a)" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.A", "03.10.01.B", "03.10.01.C", "03.10.01.D", - "03.10.07.A" + "03.10.07.A", + "03.10.07.A.01" ] } }, @@ -1156,11 +1175,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ The Human Resources (HR) department maintains a current list of personnel with authorized access to organizational facilities and facilitates the implementation of physical access management controls.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to authorize physical access to facilities based on the position or role of the individual.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -1229,7 +1248,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -1281,6 +1301,7 @@ "3.10.1" ], "general-nist-800-171-r3": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.b", @@ -1288,8 +1309,12 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[01]", + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", "A.03.10.01.ODP[01]", - "A.03.10.01.b" + "A.03.10.01.b", + "A.03.10.01.d" ], "general-nist-csf-2-0": [ "PR.AA-06" @@ -1325,9 +1350,6 @@ "9.3.1", "9.3.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -1344,11 +1366,14 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(viii)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(i)" + "§ 164.310(a)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "PE-2(1)" @@ -1360,17 +1385,15 @@ "7123(c)(3)(D)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(34)" - ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.4" + "3.4.3.34" ], "emea-sau-sacs-002-2022": [ - "TPC-86" + "VII.B.TPC-86" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5" ], "emea-gbr-def-stan-05-138-2024": [ "1502", @@ -1388,13 +1411,14 @@ "1502", "2422" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP04" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.10" + ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.08.01", "03.08.02", "03.10.01.B", @@ -1420,7 +1444,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to enforce a \"two-person rule\" for physical access by requiring two authorized individuals with separate access cards, keys or PINs, to access highly-sensitive areas (e.g., safe, high-security cage, etc.).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1486,7 +1510,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -1522,7 +1547,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls and technologies ensure that only authorized personnel are allowed access to secure areas.\n▪ A facilities maintenance team, or similar function, manages the operation of automated physical and environmental protection controls.\n▪ Physical security controls and technologies are configured to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to enforce physical access authorizations for all physical access points (including designated entry/exit points) to facilities (excluding those areas within the facility officially designated as publicly accessible).", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1612,7 +1637,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -1725,6 +1751,7 @@ "3.10.5" ], "general-nist-800-171-r3": [ + "03.04.05", "03.10.02.a", "03.10.07.a", "03.10.07.a.01", @@ -1738,12 +1765,11 @@ ], "general-nist-800-171a-r3": [ "A.03.04.05[03]", + "A.03.10.02.a[01]", + "A.03.10.07.a.01", "A.03.10.07.a.02", "A.03.10.07.d" ], - "general-nist-800-172": [ - "3.1.2e" - ], "general-nist-csf-2-0": [ "PR.AA", "PR.AA-06", @@ -1772,9 +1798,6 @@ "9.1.2", "9.2.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -1823,15 +1846,18 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "PE-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(i)(1)" + ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(ii)", - "164.310(a)(2)(iii)", - "164.310(c)" + "§ 164.310(a)(2)(ii)", + "§ 164.310(a)(2)(iii)", + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ "2.B.3.4", @@ -1885,27 +1911,22 @@ "13.3.2(b)" ], "emea-deu-c5-2020": [ - "PS-03", - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "12.27", - "18.4" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" + "PS-02-DOAR" ], "emea-sau-otcc-1-2022": [ "2-13-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-47", - "TPC-82", - "TPC-86" + "VII.B.TPC-82" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.a" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.1 [MP.IF.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "op.acc.4", + "op.acc.5", + "mp.if.1" ], "emea-uae-niaf-2023": [ "3.2.2" @@ -1922,7 +1943,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1296" ], "apac-ind-sebi-2024": [ @@ -1943,7 +1964,7 @@ "11.1.2.5", "11.1.2.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP48", "HML48" ], @@ -1951,13 +1972,17 @@ "HSUP40" ], "apac-sgp-mas-trm-2021": [ - "8.5.6(c)", - "5.5.6(f)" + "8.5.6(e)" + ], + "americas-arg-ppd-2018": [ + "B.2.4-1", + "B.2.4-2" ], "americas-can-osfi-b13-2022": [ "3.2.10" ], "americas-can-itsp-10-171-2025": [ + "03.04.05", "03.10.02.A", "03.10.07.A", "03.10.07.A.01", @@ -2072,7 +2097,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -2098,8 +2124,14 @@ "general-nist-800-171-r3": [ "03.10.02.a", "03.10.07.a", + "03.10.07.a.01", "03.10.07.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], "general-pci-dss-4-0-1": [ "9.2", "9.2.1", @@ -2129,29 +2161,21 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(b)" ], - "emea-deu-c5-2020": [ - "PS-03" - ], - "emea-isr-cmo-1-0": [ - "12.27", - "18.6", - "18.8" - ], - "emea-sau-ecc-1-2018": [ - "2-14-3-1" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-82" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.1", + "mp.if.2", + "mp.if.7" ], "apac-sgp-mas-trm-2021": [ - "5.5.6(f)" + "8.5.6(c)" + ], + "americas-arg-ppd-2018": [ + "B.2.4-3" ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", "03.10.07.A", + "03.10.07.A.01", "03.10.07.A.02" ] } @@ -2176,7 +2200,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect system components from unauthorized physical access (e.g., lockable physical casings).", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect system components from unauthorized physical access (e.g., lockable physical casings). ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2236,7 +2260,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -2288,21 +2313,11 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SC-07(14)" ], - "emea-isr-cmo-1-0": [ - "18.6", - "18.11" - ], - "emea-sau-otcc-1-2022": [ - "2-13-1-4" - ], "emea-sau-sacs-002-2022": [ - "TPC-46" + "VII.B.TPC-46" ], "apac-nzl-ism-3-9": [ "8.2.5.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(d)" ] } }, @@ -2311,7 +2326,7 @@ "title": "Physical Access Logs", "family": "PES", "description": "Physical access control mechanisms generate a log entry for each access attempt through controlled ingress and egress points.", - "scf_question": "Does the organization generate a log entry for each access attempt through controlled ingress and egress points?", + "scf_question": "Physical access control mechanisms generate a log entry for each access attempt through controlled ingress and egress points?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [ @@ -2326,7 +2341,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Where applicable, physical security controls and technologies are configured to generate a log entry for each access attempt through controlled ingress and egress points.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to generate a log entry for each access attempt through controlled ingress and egress points.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2409,7 +2424,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -2475,12 +2491,15 @@ ], "general-nist-800-171-r3": [ "03.10.02.a", + "03.10.07.a.02", "03.10.07.b" ], "general-nist-800-171a": [ "3.10.4" ], "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.07.a.02", "A.03.10.07.b" ], "general-nist-csf-2-0": [ @@ -2560,12 +2579,13 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "18.5" - ], "emea-sau-ecc-1-2018": [ "2-14-3-3" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -2581,8 +2601,13 @@ "apac-jpn-ismap": [ "11.1.2.7" ], + "americas-arg-ppd-2018": [ + "B.2.4-3", + "B.2.4-4" + ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", + "03.10.07.A.02", "03.10.07.B" ] } @@ -2591,8 +2616,8 @@ "control_id": "PES-03.4", "title": "Access To Critical Systems", "family": "PES", - "description": "Physical access control mechanisms exist to enforce physical access to critical systems or sensitive/regulated data, in addition to the physical access controls for the facility.", - "scf_question": "Does the organization enforce physical access to critical systems or sensitive/regulated data, in addition to the physical access controls for the facility?", + "description": "Physical access control mechanisms exist to enforce physical access to critical systems or sensitive and/or regulated data, in addition to the physical access controls for the facility.", + "scf_question": "Does the organization enforce physical access to critical systems or sensitive and/or regulated data, in addition to the physical access controls for the facility?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2691,7 +2716,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -2748,6 +2774,10 @@ "03.10.07.a.01", "03.10.07.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.a.01", + "A.03.10.07.a.02" + ], "general-tisax-6-0-3": [ "5.3.4" ], @@ -2764,28 +2794,21 @@ "PE-03(01)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-cms-marse-2-0": [ "PE-3-IS.2" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-sau-ecc-1-2018": [ - "2-3-3-2" - ], "emea-sau-otcc-1-2022": [ "2-13-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-46", - "TPC-49" + "VII.B.TPC-46" ], "emea-gbr-def-stan-05-138-2024": [ "1502" @@ -2799,7 +2822,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1502" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0813", "ISM-1053", "ISM-1074", @@ -2808,7 +2831,7 @@ "apac-ind-sebi-2024": [ "PR.AA.S10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP10", "HML10" ], @@ -2850,7 +2873,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls and technologies are primarily designed and implemented for offices, rooms and facilities that focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to identify systems, equipment and respective operating environments that require limited physical access so that appropriate physical access controls are designed and implemented for offices, rooms and facilities.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to identify systems, equipment and respective operating environments that require limited physical access so that appropriate physical access controls are designed and implemented for offices, rooms and facilities. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2935,7 +2958,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -2992,6 +3016,14 @@ "03.10.07.a.02", "03.10.07.d" ], + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" + ], "general-pci-dss-4-0-1": [ "9.3.1.1" ], @@ -3001,9 +3033,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.3.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -3022,14 +3051,15 @@ "52.204-21(b)(1)(viii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(b)", - "164.310(c)" + "§ 164.310(b)", + "§ 164.310(c)" ], "usa-federal-irs-1075-2021": [ + "2.B.3", "2.B.3.3" ], "usa-state-ca-ccpa-cpra-2026": [ @@ -3038,21 +3068,23 @@ "emea-eu-nis2-annex-2024": [ "13.3.2(c)" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "9.15", - "18.6" - ], "emea-sau-ecc-1-2018": [ "2-14-3-5" ], "emea-sau-otcc-1-2022": [ "2-13-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-46" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.c" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "mp.if.1", + "mp.if.3", + "mp.if.5", + "mp.if.6", + "mp.eq.1", + "mp.eq.2" ], "apac-jpn-ismap": [ "11.1.2.6", @@ -3069,7 +3101,7 @@ "11.2.9.5", "11.2.9.6" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP48", "HML48" ], @@ -3080,9 +3112,6 @@ "8.2.6.C.01", "8.2.6.C.02" ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(e)" - ], "americas-can-itsp-10-171-2025": [ "03.08.01", "03.08.02", @@ -3110,9 +3139,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to allow only authorized personnel access to secure areas.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to allow only authorized personnel access to secure areas. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3196,7 +3225,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -3239,8 +3269,13 @@ "03.10.07.a.02", "03.10.07.d" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.08.01[01]", + "A.03.08.01[02]", + "A.03.08.02", + "A.03.10.07.a.01", + "A.03.10.07.a.02", + "A.03.10.07.d" ], "general-pci-dss-4-0-1": [ "9.3.1.1" @@ -3258,10 +3293,13 @@ "SC.L3-3.13.4E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(c)" + "§ 164.310(c)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(c)" + "§ 164.310(c)" + ], + "usa-federal-irs-1075-2021": [ + "2.B.3" ], "usa-federal-dow-safeguarding-nnpi-2010": [ "8-3.a(2)" @@ -3269,19 +3307,18 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(3)(D)" ], - "emea-isr-cmo-1-0": [ - "18.6" - ], "emea-sau-ecc-1-2018": [ "2-14-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-5" - ], "emea-sau-sacs-002-2022": [ - "TPC-49" + "VII.B.TPC-49" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.acc.2", + "mp.if.2", + "mp.if.7" + ], + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ @@ -3294,9 +3331,8 @@ "11.1.5.5", "11.1.5.6" ], - "apac-sgp-mas-trm-2021": [ - "8.5.6(e)", - "5.5.6(f)" + "apac-nzl-ism-3-9": [ + "17.9.36.C.02" ], "americas-can-itsp-10-171-2025": [ "03.08.01", @@ -3325,7 +3361,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to inspect personnel and their personal effects (e.g., personal property ordinarily worn or carried by the individual, including vehicles) to prevent the unauthorized exfiltration of data and technology assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3407,7 +3443,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -3521,7 +3558,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": {} @@ -3635,7 +3673,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -3731,6 +3770,14 @@ "A.03.10.02.b[01]", "A.03.10.02.b[02]" ], + "general-nist-800-172-r3": [ + "03.10.01E", + "03.10.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[02]", + "DS-A.03.10.02E.b" + ], "general-nist-csf-2-0": [ "DE.CM-02" ], @@ -3746,9 +3793,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.2.1.1" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -3807,17 +3851,15 @@ "13.1.2(f)", "13.3.2(d)" ], - "emea-isr-cmo-1-0": [ - "18.8", - "18.10", - "18.11" - ], "emea-sau-cgiot-2024": [ "2-13-1" ], "emea-sau-ecc-1-2018": [ "2-14-3-2" ], + "emea-sau-otcc-1-2022": [ + "2-13-1-2" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -3836,16 +3878,13 @@ "apac-jpn-ismap": [ "11.1.2.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP66", "HML65" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP57" ], - "apac-sgp-mas-trm-2021": [ - "5.5.5" - ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", "03.10.02.B" @@ -3872,9 +3911,9 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Where applicable, physical security controls and technologies are configured to monitor for, detect and respond to physical security incidents.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to monitor physical intrusion alarms and surveillance equipment.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to monitor physical intrusion alarms and surveillance equipment. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -3942,7 +3981,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -3994,13 +4034,21 @@ "NFO - PE-6(1)" ], "general-nist-800-171-r3": [ - "03.10.02.a", - "03.10.02.b" + "03.10.02.a" ], "general-nist-800-171a": [ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]" + ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[02]" + ], "general-pci-dss-4-0-1": [ "9.2.1.1" ], @@ -4041,10 +4089,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-06 (01)" ], - "emea-isr-cmo-1-0": [ - "18.9", - "18.11" - ], "emea-sau-cgiot-2024": [ "2-13-1" ], @@ -4054,6 +4098,9 @@ "emea-sau-otcc-1-2022": [ "2-13-1-2" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.b" + ], "emea-gbr-def-stan-05-138-2024": [ "1500" ], @@ -4066,12 +4113,8 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1500" ], - "apac-chn-pipl-2021": [ - "26" - ], "americas-can-itsp-10-171-2025": [ - "03.10.02.A", - "03.10.02.B" + "03.10.02.A" ] } }, @@ -4079,8 +4122,8 @@ "control_id": "PES-05.2", "title": "Monitoring Physical Access To Critical Systems", "family": "PES", - "description": "Facility security mechanisms exist to monitor physical access to critical systems or sensitive/regulated data, in addition to the physical access monitoring of the facility.", - "scf_question": "Does the organization monitor physical access to critical systems or sensitive/regulated data, in addition to the physical access monitoring of the facility?", + "description": "Facility security mechanisms exist to monitor physical access to critical systems or sensitive and/or regulated data, in addition to the physical access monitoring of the facility.", + "scf_question": "Does the organization monitor physical access to critical systems or sensitive and/or regulated data, in addition to the physical access monitoring of the facility?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -4164,7 +4207,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -4218,6 +4262,17 @@ "3.10.2[c]", "3.10.2[d]" ], + "general-nist-800-171a-r3": [ + "A.03.10.02.a[01]", + "A.03.10.02.b[01]", + "A.03.10.02.b[02]" + ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.01E[01]" + ], "general-pci-dss-4-0-1": [ "9.2.1.1" ], @@ -4236,8 +4291,8 @@ "usa-federal-gsa-fedramp-5-high": [ "PE-06(04)" ], - "apac-sgp-mas-trm-2021": [ - "8.5.5" + "emea-sau-otcc-1-2022": [ + "2-13-1-7" ], "americas-can-itsp-10-171-2025": [ "03.10.02.A", @@ -4267,9 +4322,9 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.\n▪ Users are trained and encouraged to stop and question anyone attempting to install or remove IT assets from facilities.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible).", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to identify, authorize and monitor visitors before allowing access to the facility (other than areas designated as publicly accessible). ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -4355,7 +4410,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -4379,7 +4435,7 @@ "3.10.3" ], "general-nist-800-171-r3": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "general-nist-800-171a": [ @@ -4387,9 +4443,16 @@ "3.10.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.10.01.a[02]", "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], + "general-nist-800-172-r3": [ + "03.10.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.10.01E.ODP[01]" + ], "general-pci-dss-4-0-1": [ "9.3.2", "9.3.3", @@ -4405,9 +4468,6 @@ "9.3.3", "9.3.4" ], - "general-scf-dpmp-2025": [ - "7.3" - ], "general-swift-cscf-2025": [ "3.1" ], @@ -4424,10 +4484,10 @@ "52.204-21(b)(1)(ix)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.310(a)(2)(iii)" + "§ 164.310(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "2.B.3.1", @@ -4456,24 +4516,19 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(3)(D)" ], - "emea-deu-c5-2020": [ - "PS-04" - ], - "emea-isr-cmo-1-0": [ - "18.3", - "18.12" - ], "emea-sau-otcc-1-2022": [ "2-13-1-6" ], "emea-sau-sacs-002-2022": [ - "TPC-47" + "VII.B.TPC-47", + "VII.B.TPC-47-BP2", + "VII.B.TPC-47-BP3" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.2 [MP.IF.2]", - "8.1.7 [MP.IF.7]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ @@ -4491,11 +4546,10 @@ "9.4.10.C.01" ], "apac-sgp-mas-trm-2021": [ - "8.5.6(b)", - "5.5.6(f)" + "8.5.6(b)" ], "americas-can-itsp-10-171-2025": [ - "03.10.02.B", + "03.10.01.A", "03.10.07.C" ] } @@ -4504,8 +4558,8 @@ "control_id": "PES-06.1", "title": "Distinguish Visitors from On-Site Personnel", "family": "PES", - "description": "Physical access control mechanisms exist to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", - "scf_question": "Does the organization easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible?", + "description": "Physical access control mechanisms exist to easily distinguish between onsite personnel and visitors, especially in areas where sensitive and/or regulated data is accessible.", + "scf_question": "Does the organization easily distinguish between onsite personnel and visitors, especially in areas where sensitive and/or regulated data is accessible?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -4520,7 +4574,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to easily distinguish between onsite personnel and visitors, especially in areas where sensitive/regulated data is accessible. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4604,7 +4658,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -4612,7 +4667,7 @@ "3.10.3" ], "general-nist-800-171-r3": [ - "03.10.02.b", + "03.10.01.a", "03.10.07.c" ], "general-nist-800-171a": [ @@ -4620,6 +4675,7 @@ "3.10.3[b]" ], "general-nist-800-171a-r3": [ + "A.03.10.01.a[02]", "A.03.10.07.c[01]", "A.03.10.07.c[02]" ], @@ -4641,9 +4697,6 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(ix)" ], - "emea-sau-sacs-002-2022": [ - "TPC-47" - ], "emea-gbr-def-stan-05-138-2024": [ "1503" ], @@ -4660,7 +4713,7 @@ "11.1.2.8" ], "americas-can-itsp-10-171-2025": [ - "03.10.02.B", + "03.10.01.A", "03.10.07.C" ] } @@ -4670,7 +4723,7 @@ "title": "Identification Requirement", "family": "PES", "description": "Physical access control mechanisms exist to requires at least one(1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility.", - "scf_question": "Does the organization require at least one (1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility?", + "scf_question": "Does the organization requires at least one(1) form of government-issued or organization-issued photo identification to authenticate individuals before they can gain access to the facility?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -4757,7 +4810,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -4776,6 +4830,10 @@ "general-nist-800-171-r3": [ "03.10.07.c" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], "general-pci-dss-4-0-1": [ "9.3.2" ], @@ -4792,10 +4850,7 @@ "CIP-006-6 2.2" ], "emea-sau-sacs-002-2022": [ - "TPC-47" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.2 [MP.IF.2]" + "VII.B.TPC-47-BP1" ], "emea-gbr-def-stan-05-138-2024": [ "1503" @@ -4832,9 +4887,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Users are trained and encouraged to stop and question anyone attempting to install or remove IT assets from facilities.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict unescorted access to facilities to personnel with required security clearances, formal access authorizations and validate the need for access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict unescorted access to facilities to personnel with required security clearances, formal access authorizations and validate the need for access. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4916,7 +4971,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -4967,19 +5023,19 @@ "usa-federal-far-52-204-21": [ "52.204-21(b)(1)(ix)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(3)" + ], "usa-federal-nerc-cip-2024": [ "CIP-004-7 4.1.2", "CIP-006-6 1.2", "CIP-006-6 1.3", "CIP-006-6 2.1" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-7" - ], "emea-sau-sacs-002-2022": [ - "TPC-48" + "VII.B.TPC-48" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0164" ], "apac-jpn-ismap": [ @@ -5013,7 +5069,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to automatically facilitate the maintenance and review of visitor access records.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5055,7 +5111,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -5115,7 +5172,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to minimize the collection of Personal Data (PD) contained in visitor access records.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5195,7 +5252,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -5358,7 +5416,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -5368,6 +5427,10 @@ "general-nist-800-171-r3": [ "03.10.07.c" ], + "general-nist-800-171a-r3": [ + "A.03.10.07.c[01]", + "A.03.10.07.c[02]" + ], "general-pci-dss-4-0-1": [ "9.3.3" ], @@ -5377,9 +5440,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "9.3.3" ], - "emea-sau-sacs-002-2022": [ - "TPC-47" - ], "emea-gbr-def-stan-05-138-2024": [ "1503" ], @@ -5419,7 +5479,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power equipment and power cabling for the system from damage and destruction.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power equipment and power cabling for the system from damage and destruction. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5488,7 +5548,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -5553,6 +5614,9 @@ "general-nist-800-171-r3": [ "03.10.08" ], + "general-nist-800-171a-r3": [ + "A.03.10.08" + ], "general-nist-csf-2-0": [ "PR.IR-02" ], @@ -5573,18 +5637,19 @@ "PE-09" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-eu-nis2-annex-2024": [ "13.1.2(d)" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-06" + "PS-04" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.3 [MP.IF.3]", - "8.1.4 [MP.IF.4]" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.d" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "apac-jpn-ismap": [ "11.2.2", @@ -5600,12 +5665,6 @@ "8.3.4.C.02", "8.3.5.C.01" ], - "apac-sgp-mas-trm-2021": [ - "8.5.2", - "8.5.2(a)", - "8.5.2(b)", - "8.5.2(c)" - ], "americas-can-itsp-10-171-2025": [ "03.10.08" ] @@ -5631,7 +5690,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize automatic voltage controls for critical system components.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize automatic voltage controls for critical system components. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5694,7 +5753,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -5732,10 +5792,10 @@ "PE-09(02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.4 [MP.IF.4]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ] } }, @@ -5824,7 +5884,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -5897,6 +5958,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-10" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" + ], "apac-jpn-ismap": [ "11.2.2.7" ] @@ -5987,7 +6051,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -6081,12 +6146,10 @@ "13.1.2(a)" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-06" + "PS-04" ], - "emea-isr-cmo-1-0": [ - "18.14", - "18.15" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "emea-gbr-def-stan-05-138-2024": [ "2704" @@ -6100,7 +6163,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2704" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1123" ] } @@ -6125,7 +6188,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6190,7 +6253,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -6275,8 +6339,11 @@ "emea-eu-nis2-annex-2024": [ "13.1.2(a)" ], - "emea-isr-cmo-1-0": [ - "18.16" + "emea-isr-cmo-2-0": [ + "Appendix A, 11.1" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.4" ], "apac-jpn-ismap": [ "11.2.2.6" @@ -6303,9 +6370,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect systems from damage resulting from water leakage by providing master shutoff valves that are accessible, working properly and known to key personnel.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect systems from damage resulting from water leakage by providing master shutoff valves that are accessible, working properly and known to key personnel. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6374,7 +6441,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -6463,13 +6531,10 @@ "PE-15" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], - "emea-deu-c5-2020": [ - "PS-01" - ], - "emea-isr-cmo-1-0": [ - "18.19" + "americas-arg-ppd-2018": [ + "D.1.2-DS-1" ] } }, @@ -6491,9 +6556,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to detect the presence of water in the vicinity of critical systems and alert facility maintenance and IT personnel.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to detect the presence of water in the vicinity of critical systems and alert facility maintenance and IT personnel. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6557,7 +6622,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -6587,9 +6653,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "PE-15(01)" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.6 [MP.IF.6]" ] } }, @@ -6665,7 +6728,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -6680,6 +6744,9 @@ ], "general-nist-800-160-vol-2-r1": [ "PE-09(01)" + ], + "emea-deu-c5-2020": [ + "PS-04" ] } }, @@ -6705,7 +6772,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire suppression and detection devices/systems for the system that are supported by an independent energy source.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire suppression and detection devices/systems for the system that are supported by an independent energy source. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6774,7 +6841,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -6857,21 +6925,22 @@ "PE-13" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-deu-c5-2020": [ - "PS-01", - "PS-05" - ], - "emea-isr-cmo-1-0": [ - "18.17" + "PS-03-BP1", + "PS-03-BP2", + "PS-03-BP4", + "PS-03-BP6" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.5 [MP.IF.5]" + "emea-isr-cmo-2-0": [ + "Appendix A, 11.2" ], "apac-sgp-mas-trm-2021": [ - "8.5.3", - "8.5.4" + "8.5.3" + ], + "americas-arg-ppd-2018": [ + "D.1.2-DS-1" ] } }, @@ -6895,7 +6964,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire detection devices/systems that activate automatically and notify organizational personnel and emergency responders in the event of a fire.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize and maintain fire detection devices/systems that activate automatically and notify organizational personnel and emergency responders in the event of a fire. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6961,7 +7030,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -7011,14 +7081,10 @@ "PE-13(1)" ], "emea-deu-c5-2020": [ - "PS-05" - ], - "emea-isr-cmo-1-0": [ - "18.17" + "PS-03-BP5" ], "apac-sgp-mas-trm-2021": [ - "8.5.3", - "8.5.4" + "8.5.3" ] } }, @@ -7040,9 +7106,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize fire suppression devices/systems that provide automatic notification of any activation to organizational personnel and emergency responders.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to utilize fire suppression devices/systems that provide automatic notification of any activation to organizational personnel and emergency responders. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7106,7 +7172,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -7156,10 +7223,7 @@ "PE-13(3)" ], "emea-deu-c5-2020": [ - "PS-05" - ], - "emea-isr-cmo-1-0": [ - "18.17" + "PS-03-BP5" ], "emea-gbr-def-stan-05-138-2024": [ "2704" @@ -7172,6 +7236,9 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2704" + ], + "apac-sgp-mas-trm-2021": [ + "8.5.3" ] } }, @@ -7259,7 +7326,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -7307,9 +7375,6 @@ ], "usa-federal-cms-marse-2-0": [ "PE-13(2)" - ], - "emea-deu-c5-2020": [ - "PS-05" ] } }, @@ -7403,7 +7468,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -7490,17 +7556,14 @@ "PE-14" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.3(35)" + "3.4.3.35" ], "emea-eu-nis2-annex-2024": [ "13.1.2(f)" ], "emea-deu-c5-2020": [ - "PS-06", - "PS-07" - ], - "emea-isr-cmo-1-0": [ - "18.18" + "PS-03-BP3", + "PS-03-DOAR" ], "emea-gbr-def-stan-05-138-2024": [ "2704" @@ -7536,7 +7599,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to trigger an alarm or notification of temperature and humidity changes that be potentially harmful to personnel or equipment.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to trigger an alarm or notification of temperature and humidity changes that be potentially harmful to personnel or equipment. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7601,7 +7664,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -7636,13 +7700,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "PE-14(02)" - ], - "emea-deu-c5-2020": [ - "PS-06", - "PS-07" - ], - "emea-isr-cmo-1-0": [ - "18.18" ] } }, @@ -7666,7 +7723,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7746,7 +7803,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -7813,6 +7871,17 @@ "general-nist-800-171-r2": [ "NFO - PE-16" ], + "general-nist-800-172-r3": [ + "03.10.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.10.02E.a[01]", + "A.03.10.02E.ODP[01]", + "DS-A.03.10.02E.a[02]", + "DS-A.03.10.02E.a[03]", + "A.03.10.02E.ODP[02]", + "DS-A.03.10.02E.a[04]" + ], "general-tisax-6-0-3": [ "3.1.3", "5.3.3" @@ -7848,8 +7917,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-16" ], - "emea-isr-cmo-1-0": [ - "18.20" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.2", + "mp.if.7" ], "apac-jpn-ismap": [ "11.1.6", @@ -7862,7 +7935,7 @@ "11.1.6.7" ], "apac-sgp-mas-trm-2021": [ - "5.5.6(f)" + "8.5.6(f)" ] } }, @@ -7972,7 +8045,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -8065,12 +8139,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-17" ], - "emea-deu-c5-2020": [ - "PS-02" - ], - "emea-isr-cmo-1-0": [ - "18.21" - ], "emea-gbr-def-stan-05-138-2024": [ "2312" ], @@ -8109,7 +8177,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to locate system components within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to locate system components within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8196,7 +8264,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -8216,10 +8285,10 @@ "PE-18" ], "general-iso-27002-2022": [ - "7.12", "7.3", "7.5", - "7.8" + "7.8", + "7.12" ], "general-iso-27017-2015": [ "11.1.4", @@ -8288,8 +8357,9 @@ "03.10.07.e", "03.10.08" ], - "general-nist-800-172": [ - "3.13.4e" + "general-nist-800-171a-r3": [ + "A.03.10.07.e", + "A.03.10.08" ], "general-pci-dss-4-0-1": [ "9.2.2", @@ -8357,15 +8427,15 @@ "usa-federal-nerc-cip-2024": [ "CIP-006-6 1.10" ], - "emea-isr-cmo-1-0": [ - "18.7", - "18.13", - "18.22" + "emea-sau-sama-csf-1-2017": [ + "3.3.2.3.e" ], - "emea-esp-ccn-stic-825-2023": [ - "8.1.3 [MP.IF.3]" + "emea-esp-ccn-stic-825-2026": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1644" ], "apac-jpn-ismap": [ @@ -8412,9 +8482,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power and telecommunications cabling carrying data or supporting information services from interception, interference or damage.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect power and telecommunications cabling carrying data or supporting information services from interception, interference or damage. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8500,7 +8570,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -8626,11 +8697,10 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-04" ], - "emea-isr-cmo-1-0": [ - "9.15", - "18.13" + "emea-deu-c5-2020": [ + "PS-04" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0181", "ISM-0187", "ISM-0194", @@ -8671,7 +8741,10 @@ "ISM-1718", "ISM-1719", "ISM-1720", - "ISM-1721" + "ISM-1721", + "ISM-1820", + "ISM-1821", + "ISM-1822" ], "apac-jpn-ismap": [ "11.2.3", @@ -8798,7 +8871,7 @@ "0": "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.", "1": "Physical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Physical security controls address system component location within the facility to minimize potential damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.\n▪ Physical security controls isolate information processing facilities from points such as delivery and loading areas and other points to avoid unauthorized access.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict access to printers and other system output devices to prevent unauthorized individuals from obtaining the output.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to restrict access to printers and other system output devices to prevent unauthorized individuals from obtaining the output. ", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8862,7 +8935,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -8956,12 +9030,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "PE-05" ], - "emea-isr-cmo-1-0": [ - "18.7" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1036" ], + "apac-nzl-ism-3-9": [ + "11.8.9.C.01" + ], "americas-can-itsp-10-171-2025": [ "03.10.07.E" ] @@ -8985,9 +9059,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", - "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect the system from information leakage due to electromagnetic signals emanations.", + "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to protect the system from information leakage due to electromagnetic signals emanations. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9039,7 +9113,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -9061,7 +9136,7 @@ "general-nist-800-82-r3": [ "PE-19" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0246", "ISM-0249", "ISM-0250" @@ -9094,11 +9169,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to employ asset location technologies that track and monitor the location and movement of organization-defined assets within organization-defined controlled areas.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -9156,7 +9231,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -9234,7 +9310,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -9267,7 +9344,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are documented and maintained by process owners.\n▪ 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 PES domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Physical security / facilities management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Physical security / facilities management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Physical security controls and technologies primarily focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational physical security capability exists to mark system hardware components indicating the impact or classification level of the information permitted to be processed, stored or transmitted by the hardware component.", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9327,7 +9404,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { @@ -9361,7 +9439,7 @@ "emea-sau-cgiot-2024": [ "2-6-1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1107", "ISM-1216", "ISM-1217", @@ -9393,7 +9471,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to automatically monitor physical proximity to robotic or autonomous platforms to reduce applied force or stop the operation when sensors indicate a potentially dangerous scenario.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9444,7 +9522,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": {} @@ -9453,8 +9532,8 @@ "control_id": "PES-18", "title": "On-Site Client Segregation", "family": "PES", - "description": "Mechanisms exist to ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces.", - "scf_question": "Does the organization ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces?", + "description": "Mechanisms exist to ensure client-specific sensitive and/or regulated data is isolated from other data when client-specific sensitive and/or regulated data is processed or stored within multi-client workspaces.", + "scf_question": "Does the organization ensure client-specific sensitive and/or regulated data is isolated from other data when client-specific sensitive and/or regulated data is processed or stored within multi-client workspaces?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -9467,7 +9546,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPhysical & Environmental Security (PES) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PES domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Physical security-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Physical security controls are primarily administrative in nature (e.g., policies & standards), focusing on protecting High Value Assets (HVAs).\n▪ IT and/or cybersecurity personnel implement appropriate physical security practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets and data.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to ensure client-specific sensitive/regulated data is isolated from other data when client-specific sensitive/regulated data is processed or stored within multi-client workspaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9543,13 +9622,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { - "general-nist-800-172": [ - "3.13.4e" - ], "general-tisax-6-0-3": [ "5.3.4", "8.1.8" @@ -9558,7 +9635,8 @@ "SC.L3-3.13.4E" ], "emea-sau-sacs-002-2022": [ - "TPC-38" + "VII.B.TPC-38", + "VII.B.TPC-49" ] } }, @@ -9584,7 +9662,7 @@ "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Physical & Environmental Security (PES) 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:\n▪ Policies and standards associated with PES domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PES domain capabilities are well-documented and kept current by process owners.\n▪ A facilities management team, or similar function, is appropriately staffed and supported to implement and maintain NET domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of physical and environmental security operations (e.g., facility management solution, visitor log management automation, proximity badge access, etc.).\n▪ 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 PES 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).\n▪ An implemented and operational capability exists to maintain an accurate inventory of all physical access devices (e.g., RFID cards, access fobs, door keys, etc.).", "4": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Physical & Environmental Security (PES) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -9656,7 +9734,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Physical & Environmental Security", "crosswalks": { diff --git a/docs/api/families/PRI.json b/docs/api/families/PRI.json index 601adbbb..7eeb8ee1 100644 --- a/docs/api/families/PRI.json +++ b/docs/api/families/PRI.json @@ -1,7 +1,7 @@ { "family_code": "PRI", "family_name": "Data Privacy", - "control_count": 102, + "control_count": 103, "controls": [ { "control_id": "PRI-01", @@ -24,7 +24,7 @@ }, "maturity": { "0": "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.", - "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.\n▪ Data/process owners are expected to take the initiative to work with Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ No formal data privacy principles are identified for the organization.\n▪ Data/process owners perform their own Data Protection Impact Assessment (DPIA).", + "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.\n▪ Data/process owners are expected to take the initiative to work with Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.\n▪ No formal data privacy principles are identified for the organization.\n▪ Data/process owners perform their own Data Protection Impact Assessment (DPIA). ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is formally assigned as the Chief Privacy Officer (CPO), or similar role, to lead the organization's data privacy program. This individual may be assigned to multiple data privacy-related roles.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to facilitate the implementation and operation of data protection controls throughout the data lifecycle to ensure all forms of Personal Data (PD) are processed lawfully, fairly and transparently.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -101,7 +101,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -168,7 +169,7 @@ "7.5.3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-100-1-ai-rmf": [ "MAP 1.6" @@ -232,10 +233,6 @@ "general-oecd-privacy-principles-2010": [ "8" ], - "general-scf-dpmp-2025": [ - "1.0", - "1.1" - ], "general-shared-assessments-sig-2025": [ "P.3" ], @@ -267,14 +264,14 @@ "155.260(a)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)", - "164.530(a)(1)(i)", - "164.530(i)(1)", - "164.530(i)(4)(i)(A)", - "164.530(i)(4)(i)(B)", - "164.530(i)(5)", - "164.530(i)(5)(i)", - "164.530(i)(5)(ii)" + "§ 164.502(a)", + "§ 164.530(a)(1)(i)", + "§ 164.530(i)(1)", + "§ 164.530(i)(4)(i)(A)", + "§ 164.530(i)(4)(i)(B)", + "§ 164.530(i)(5)", + "§ 164.530(i)(5)(i)", + "§ 164.530(i)(5)(ii)" ], "usa-federal-irs-1075-2021": [ "PM-18", @@ -313,221 +310,73 @@ "Article 9.1", "Article 12.2" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "4" - ], "emea-deu-fdpa-2017": [ - "Inferred", - "Expectation" - ], - "emea-grc-pirppd-1997": [ - "Inferred", - "Expectation" - ], - "emea-hun-isdfi-2011": [ - "Inferred", - "Expectation" + "2.1.2.26(5)" ], - "emea-irl-dpa-2003": [ - "Inferred", - "Expectation" + "emea-hun-act-cxii-2011": [ + "II.6.7(1)" ], - "emea-isr-ppl-5741-1981": [ - "Inferred", - "Expectation" - ], - "emea-ita-pdpc-2003": [ - "Inferred", - "Expectation" + "emea-isr-cmo-2-0": [ + "Appendix F" ], "emea-ken-pda-2019": [ - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)" + "IV.25" ], "emea-nga-dpr-2019": [ "4.1(3)" ], - "emea-nor-pda-2018": [ - "Inferred", - "Expectation" - ], - "emea-pol-act-29-1997": [ - "Inferred", - "Expectation" - ], "emea-qat-pdppl-2020": [ - "2", - "3", - "8.1" - ], - "emea-rus-federal-law-27-2006": [ - "Inferred", - "Expectation" + "3.11", + "3.11.5" ], "emea-sau-pdpl-2023": [ "Article 11.2" ], - "emea-srb-act-9-2018": [ - "5.1", - "59", - "59.1", - "59.2", - "59.3", - "59.4", - "59.5", - "59.6", - "59.7", - "59.8", - "59.9", - "59.10", - "59.11" - ], - "emea-zaf-popia-2013": [ - "19", - "20", - "60" - ], - "emea-esp-decree-1720-2007": [ - "Inferred", - "Expectation" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.7.1 [MP.INFO.1]" - ], - "emea-che-fadp-2025": [ - "Inferred", - "Expectation" - ], - "emea-tur-lppd-2016": [ - "Inferred", - "Expectation" - ], - "emea-gbr-dpa-1998": [ - "Inferred", - "Expectation" - ], - "apac-aus-privacy-act-1998": [ - "Inferred", - "Expectation" - ], - "apac-aus-privacy-principles-2026": [ - "APP 1" - ], - "apac-chn-csnip-2012": [ - "Inferred", - "Expectation" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2", + "mp.info.1" ], "apac-chn-pipl-2021": [ - "7", - "16", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)", - "58", - "58(1)", - "58(2)", - "58(3)", - "58(4)", - "59" - ], - "apac-hkg-pdo-2022": [ - "Inferred", - "Expectation" + "Article 51" ], "apac-ind-privacy-rules-2011": [ - "Inferred", - "Expectation" + "8(1)" ], - "apac-jpn-ppi-2020": [ - "24(3)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)", - "36", - "37", - "38", - "39", - "51(1)", - "51(2)", - "52(1)", - "53(2)", - "53(3)", - "53(1)", - "53(4)", - "54", - "55" + "apac-jpn-appi-2020": [ + "IV.5.53(1)" ], "apac-jpn-ismap": [ "5.1.1", "5.1.1.19", "18.1.4" ], - "apac-mys-pdpa-2010": [ - "23" - ], "apac-phl-dpa-2012": [ - "Inferred", - "Expectation" - ], - "apac-sgp-pdpa-2012": [ - "12" - ], - "apac-kor-pipa-2011": [ - "3", - "30" - ], - "apac-twn-pdpa-2025": [ - "Inferred", - "Expectation" + "III.11" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.8", - "6.10", - "50" - ], - "americas-can-pipeda-2000": [ - "Principle 1", - "Principle 8" - ], - "americas-chl-act-19628-1999": [ - "Inferred", - "Expectation" + "V.45(2)(a)", + "V.45(2)(b)", + "V.45(2)(b)(i)", + "V.45(2)(b)(ii)" ], "americas-col-law-1581-2012": [ - "4" + "VI.18(a)", + "VI.18(b)", + "VI.18(c)", + "VI.18(d)", + "VI.18(e)", + "VI.18(f)", + "VI.18(g)", + "VI.18(h)", + "VI.18(i)", + "VI.18(j)", + "VI.18(k)", + "VI.18(l)" ], "americas-mex-fdpa-2010": [ - "6", - "14", - "30" + "II.6", + "II.14" ] } }, @@ -536,7 +385,7 @@ "title": "Chief Privacy Officer (CPO)", "family": "PRI", "description": "Mechanisms exist to appoints a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program.", - "scf_question": "Does the organization have a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program?", + "scf_question": "Does the organization appoints a Chief Privacy Officer (CPO) or similar role, with the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [ @@ -551,7 +400,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A qualified individual is formally assigned as the Chief Privacy Officer (CPO), or similar role, to lead the organization's data privacy program. This individual may be assigned to multiple data privacy-related roles.\n▪ The CPO, or similar role, identifies appropriate data privacy controls that Technology Assets, Applications and/or Services (TAAS) and third-parties must adhere to, in addition to applicable statutory, regulatory and/or contractual obligations.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ A Chief Privacy Officer (CPO) or similar role, has the authority, mission, accountability and resources to coordinate, develop and implement, applicable data privacy requirements and manage data privacy risks through the organization-wide data privacy program.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -599,7 +448,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -622,7 +472,7 @@ "5.3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.PO-P3" @@ -657,14 +507,11 @@ "general-oecd-privacy-principles-2010": [ "8" ], - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-federal-omb-fipps-1973": [ "2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(a)(1)(i)" + "§ 164.530(a)(1)(i)" ], "usa-federal-irs-1075-2021": [ "PM-19" @@ -672,61 +519,36 @@ "usa-federal-cms-marse-2-0": [ "AR-1.a" ], - "emea-deu-fdpa-2017": [ - "Sec 4d", - "Sec 4f", - "Sec 4g" - ], - "emea-hun-isdfi-2011": [ - "24" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "30" - ], - "emea-pol-act-29-1997": [ - "46" - ], - "emea-qat-pdppl-2020": [ - "8.1" - ], - "emea-rus-federal-law-27-2006": [ - "23" - ], - "emea-zaf-popia-2013": [ - "55", - "56" - ], - "apac-chn-pipl-2021": [ - "9", - "52" - ], - "apac-jpn-ppi-2020": [ - "21" + "apac-phl-dpa-2012": [ + "VI.21", + "VI.21(a)", + "VI.21(b)" ], "apac-sgp-pdpa-2012": [ - "11" + "3.11(3)", + "3.11(4)" ], "apac-kor-pipa-2011": [ - "31" + "IV.31(1)", + "IV.31(2)", + "IV.31(2)1", + "IV.31(2)2", + "IV.31(2)3", + "IV.31(2)4", + "IV.31(2)5", + "IV.31(2)6", + "IV.31(2)7", + "IV.31(3)", + "IV.31(4)", + "IV.31(5)" ], - "americas-bra-lgpd-2018": [ - "6.8", - "6.10" + "americas-can-pipeda-2000": [ + "P1-4.1", + "P1-4.1.1", + "P1-4.1.2" ], "americas-chl-act-19628-1999": [ - "7", - "11" - ], - "americas-col-law-1581-2012": [ - "17", - "18" + "I.5" ] } }, @@ -795,7 +617,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -817,15 +640,9 @@ "general-nist-800-82-r3": [ "PT-05(02)" ], - "general-scf-dpmp-2025": [ - "4.0" - ], "usa-federal-cms-marse-2-0": [ "TR-2", "TR-2.c" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 8" ] } }, @@ -834,7 +651,7 @@ "title": "Dissemination of Data Privacy Program Information", "family": "PRI", "description": "Mechanisms exist to: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes.", - "scf_question": "Does the organization: \n (1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n (2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n (3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n (4) Inform data subjects when changes are made to the privacy notice and the nature of such changes?", + "scf_question": "Does the organization: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -847,11 +664,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to: \n(1) Ensure that the public has access to information about organizational data privacy activities and can communicate with its Chief Privacy Officer (CPO) or similar role;\n(2) Ensure that organizational data privacy practices are publicly available through organizational websites or document repositories; \n(3) Utilize publicly facing email addresses and/or phone lines to enable the public to provide feedback and/or direct questions to data privacy office(s) regarding data privacy practices; and\n(4) Inform data subjects when changes are made to the privacy notice and the nature of such changes.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -904,7 +721,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -970,10 +788,6 @@ "general-oecd-privacy-principles-2010": [ "6" ], - "general-scf-dpmp-2025": [ - "1.0", - "11.2" - ], "usa-federal-omb-fipps-1973": [ "8" ], @@ -988,12 +802,12 @@ "usa-state-va-cdpa-2023": [ "59.1-581.A.2" ], - "apac-aus-privacy-principles-2026": [ - "APP 1" + "emea-esp-ccn-stic-825-2026": [ + "org.1", + "org.2" ], - "apac-chn-pipl-2021": [ - "9", - "48" + "apac-jpn-appi-2020": [ + "IV.5.53(3)" ], "apac-jpn-ismap": [ "5.1.1" @@ -1020,7 +834,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Data/process owners work with IT and/or cybersecurity personnel and Data Protection Officers (DPOs) to ensure applicable statutory, regulatory and/or contractual obligations are properly addressed, including the storage, transmission and processing of sensitive/regulated data.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ A Data Protection Officer (DPO) is appointed:\n(1) Based on professional qualifications; and\n(2) To be involved in all issues related to how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1078,23 +892,21 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.PO-P3", "CT.PO-P2", "CM.PO-P2" ], - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.530(a)(1)(ii)" + "§ 164.530(a)(1)(ii)" ], "emea-eu-gdpr-2016": [ "Article 27.1", @@ -1126,69 +938,171 @@ "Article 39.1(e)", "Article 39.2" ], + "emea-aut-dpa-2018": [ + "§ 5(1)", + "§ 57(1)", + "§ 57(2)", + "§ 57(3)", + "§ 57(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 5, Art. 63", + "Title 2, Chapter IV, Section 5, Art. 64", + "Title 2, Chapter IV, Section 5, Art. 65", + "Title 4, Chapter II, Art. 190", + "Title 4, Chapter II, Art. 191", + "Title 4, Chapter II, Art. 192" + ], + "emea-deu-fdpa-2017": [ + "2.1.1.22(2)4", + "2.3.38(1)", + "2.3.38(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.18.24(1)(a)", + "II.18.24(1)(b)", + "II.18.24(1)(c)", + "II.18.24(2)", + "II.18.24(2)(a)", + "II.18.24(2)(b)", + "II.18.24(2)(c)", + "II.18.24(2)(d)", + "II.18.24(2)(e)", + "II.18.24(2)(f)" + ], + "emea-irl-dpa-2018": [ + "s.88" + ], + "emea-isr-ppl-5741-2025": [ + "s.17B1", + "s.17B2" + ], + "emea-ita-pdpc-2018": [ + "Article 2-q(1)" + ], "emea-ken-pda-2019": [ - "24(1)", - "24(1)(a)", - "24(1)(b)", - "24(1)(c)", - "24(2)", - "24(3)", - "24(4)", - "24(5)", - "24(6)", - "24(7)(a)", - "24(7)(b)", - "24(7)(c)", - "24(7)(d)", - "24(7)(e)" + "III.24(1)", + "III.24(1)(a)", + "III.24(1)(b)", + "III.24(1)(c)", + "III.24(2)", + "III.24(3)", + "III.24(4)", + "III.24(5)", + "III.24(6)", + "III.24(7)", + "III.24(7)(a)", + "III.24(7)(b)", + "III.24(7)(c)", + "III.24(7)(d)", + "III.24(7)(e)" ], "emea-nga-dpr-2019": [ - "4.1(2)", - "4.1(3)" + "4.1(2)" ], - "emea-qat-pdppl-2020": [ - "8.2", - "10" + "emea-nor-pda-2018": [ + "18", + "18(a)", + "18(b)", + "18(c)", + "18(d)" + ], + "emea-pol-act-10-2018": [ + "Art. 8", + "Art. 11a" + ], + "emea-rus-152-fz-2025": [ + "Art. 22.1" ], "emea-sau-pdpl-2023": [ "Article 30.2" ], "emea-srb-act-9-2018": [ - "44", - "44.1", - "44.2", - "56", - "56.1", - "56.2", - "56.3", - "57", - "58", - "58.1", - "58.2", - "58.3", - "58.4" + "IV.4.56", + "IV.4.56(1)", + "IV.4.56(2)", + "IV.4.56(3)", + "IV.4.57", + "IV.4.58", + "IV.4.58(1)", + "IV.4.58(2)", + "IV.4.58(3)", + "IV.4.58(4)" ], - "emea-zaf-popia-2013": [ - "17", - "55", - "56" + "emea-che-fadp-2025": [ + "2.1.10.1", + "2.1.10.2", + "2.1.10.2.b" + ], + "emea-gbr-dpa-2018": [ + "Section 69(1)", + "Section 69(2)", + "Section 69(2)(a)", + "Section 69(2)(b)", + "Section 69(3)", + "Section 70(1)", + "Section 70(2)", + "Section 70(2)(a)", + "Section 70(2)(b)", + "Section 70(3)", + "Section 70(3)(a)", + "Section 70(3)(b)", + "Section 70(3)(c)", + "Section 70(4)", + "Section 70(4)(a)", + "Section 70(4)(b)", + "Section 70(5)", + "Section 71(1)", + "Section 71(1)(a)", + "Section 71(1)(b)", + "Section 71(1)(c)", + "Section 71(1)(d)", + "Section 71(1)(e)", + "Section 71(1)(f)", + "Section 71(2)", + "Section 71(2)(a)", + "Section 71(2)(b)", + "Section 71(2)(c)", + "Section 71(2)(d)", + "Section 71(3)" ], "apac-chn-pipl-2021": [ - "9", - "52", - "53" + "Article 52", + "Article 54" ], "apac-ind-dpdpa-2023": [ "10(2)(a)", "10(2)(a)(iv)" ], + "americas-bhs-dpa-2003": [ + "V.45(1)", + "V.45(1)(a)", + "V.45(1)(b)", + "V.45(1)(c)", + "V.45(3)", + "V.45(3)(a)", + "V.45(3)(b)", + "V.45(3)(c)", + "V.45(3)(d)", + "V.45(3)(e)", + "V.45(3)(f)", + "V.45(3)(g)", + "V.45(3)(h)", + "V.45(3)(i)", + "V.45(3)(j)" + ], "americas-bra-lgpd-2018": [ - "6.8", - "6.10", - "41" + "VI.II.41", + "VI.II.41.1", + "VI.II.41.2", + "VI.II.41.2.I", + "VI.II.41.2.II", + "VI.II.41.2.III", + "VI.II.41.2.IV", + "VI.II.41.3" ], - "americas-can-pipeda-2000": [ - "Sec 6" + "americas-mex-fdpa-2010": [ + "IV.30" ] } }, @@ -1212,7 +1126,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to implement and manage Binding Corporate Rules (BCR) (e.g., data sharing agreement) to legally-bind all parties engaged in a joint economic activity that contractually states enforceable rights on data subjects with regard to the processing of their personal data.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1263,7 +1177,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -1298,30 +1213,337 @@ "Article 46.1", "Article 46.2(b)" ], + "emea-aut-dpa-2018": [ + "§ 58(1)", + "§ 58(2)", + "§ 58(3)", + "§ 59(1)", + "§ 59(2)", + "§ 59(3)", + "§ 59(5)", + "§ 59(6)", + "§ 59(7)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter V, Art. 66(1)", + "Title 2, Chapter V, Art. 66(2)", + "Title 2, Chapter V, Art. 67", + "Title 2, Chapter V, Art. 68(1)", + "Title 2, Chapter V, Art. 68(2)", + "Title 2, Chapter V, Art. 68(3)", + "Title 2, Chapter V, Art. 69(1)", + "Title 2, Chapter V, Art. 69(2)", + "Title 2, Chapter V, Art. 69(3)", + "Title 2, Chapter V, Art. 70(1)", + "Title 2, Chapter V, Art. 70(2)", + "Title 2, Chapter V, Art. 70(3)" + ], + "emea-deu-fdpa-2017": [ + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)8", + "3.4.62(5)9", + "3.4.62(6)", + "3.4.62(7)", + "3.4.63", + "3.5.78(1)", + "3.5.78(1)1", + "3.5.78(1)2", + "3.5.78(2)", + "3.5.78(3)", + "3.5.78(4)", + "3.5.79(1)", + "3.5.79(1)1" + ], + "emea-grc-pirppd-1997": [ + "B.9.1.b", + "B.9.2" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" + ], + "emea-irl-dpa-2018": [ + "s.96", + "s.97", + "s.98", + "s.99", + "s.100" + ], + "emea-ken-pda-2019": [ + "IV.25(h)", + "VI.49(1)", + "VI.49(2)", + "VI.49(3)", + "VI.50" + ], + "emea-nga-dpr-2019": [ + "2.11", + "2.11(a)", + "2.11(b)", + "2.11(c)", + "2.11(d)", + "2.11(e)", + "2.12" + ], "emea-qat-pdppl-2020": [ - "15" + "3.15" + ], + "emea-rus-152-fz-2025": [ + "Art. 12" ], "emea-sau-pdpl-2023": [ "Article 29.2.b" ], "emea-srb-act-9-2018": [ - "65", - "65.x", - "66", - "67", - "67.x" + "V.63", + "V.63(1)", + "V.63(2)", + "V.63(3)", + "V.63(4)", + "V.64", + "V.64(1)", + "V.64(2)", + "V.64(3)", + "V.65-1", + "V.65-1(1)", + "V.65-1(2)", + "V.65-1(3)", + "V.65-1(4)", + "V.65-1(5)", + "V.65-2", + "V.65-2(1)", + "V.65-2(2)", + "V.66", + "V.66(1)", + "V.66(2)", + "V.67-1", + "V.67-1(1)", + "V.67-1(2)", + "V.67-1(3)", + "V.67-2", + "V.67-2(1)", + "V.67-2(2)", + "V.67-2(3)", + "V.67-2(4)", + "V.67-2(5)", + "V.67-2(6)", + "V.67-2(7)", + "V.67-2(8)", + "V.67-2(9)", + "V.67-2(10)", + "V.67-2(11)", + "V.67-2(12)", + "V.67-2(13)", + "V.67-2(14)", + "V.68", + "V.69-1", + "V.69-1(1)", + "V.69-1(2)", + "V.69-1(3)", + "V.69-1(4)", + "V.69-1(5)", + "V.69-1(6)", + "V.69-1(7)", + "V.69-2", + "V.69-2(1)", + "V.69-2(2)", + "V.69-2(3)", + "V.69-2(4)", + "V.70", + "V.70(1)", + "V.70(2)", + "V.70(3)", + "V.70(4)", + "V.70(5)", + "V.71", + "V.71(1)", + "V.71(2)", + "V.71(3)", + "V.71(4)", + "V.71(5)", + "V.72", + "V.72(1)", + "V.72(2)", + "V.72(3)", + "V.72(4)" + ], + "emea-zaf-popia-2013": [ + "9.72(1)", + "9.72(1)(a)", + "9.72(1)(a)(i)", + "9.72(1)(a)(ii)", + "9.72(1)(b)", + "9.72(1)(c)", + "9.72(1)(d)", + "9.72(1)(e)", + "9.72(1)(e)(i)", + "9.72(1)(e)(ii)", + "9.72(2)", + "9.72(2)(a)", + "9.72(2)(b)" + ], + "emea-che-fadp-2025": [ + "2.3.16.1", + "2.3.16.2", + "2.3.16.2.a", + "2.3.16.2.b", + "2.3.16.2.c", + "2.3.16.2.d", + "2.3.16.2.e", + "2.3.16.3" + ], + "emea-tur-lppd-2016": [ + "9(1)", + "9(2)", + "9(3)", + "9(3)(a)", + "9(3)(b)", + "9(3)(c)", + "9(3)(ç)", + "9(3)(d)", + "9(3)(e)", + "9(4)", + "9(4)(a)", + "9(4)(b)", + "9(4)(c)", + "9(4)(ç)", + "9(5)", + "9(6)", + "9(6)(a)", + "9(6)(b)", + "9(6)(c)", + "9(6)(ç)", + "9(6)(d)", + "9(6)(e)", + "9(6)(f)", + "9(7)", + "9(8)", + "9(9)", + "9(10)", + "9(11)" + ], + "emea-gbr-dpa-2018": [ + "Section 78", + "Section 78(1)", + "Section 78(1)(a)", + "Section 78(1)(b)", + "Section 78(1)(b)(i)", + "Section 78(1)(b)(ii)", + "Section 78(1A)", + "Section 78(1A)(a)", + "Section 78(1A)(b)", + "Section 78(2)", + "Section 78(3)", + "Section 78(3)(a)", + "Section 78(3)(b)", + "Section 78(3)(c)", + "Section 78(4)", + "Section 78(5)", + "Section 78(5)(a)", + "Section 78(5)(b)", + "Section 78(6)", + "Section 78(7)", + "Section 78(7)(a)", + "Section 78(7)(b)" + ], + "apac-aus-privacy-principles-2026": [ + "3.8.1", + "3.8.1.a", + "3.8.1.b", + "3.8.2", + "3.8.2.a", + "3.8.2.a.i", + "3.8.2.a.ii", + "3.8.2.b", + "3.8.2.b.i", + "3.8.2.b.ii", + "3.8.2.c", + "3.8.2.d", + "3.8.2.e", + "3.8.2.f", + "3.8.2.f.i", + "3.8.2.f.ii" + ], + "apac-chn-pipl-2021": [ + "Article 38" + ], + "apac-ind-privacy-rules-2011": [ + "7" + ], + "apac-jpn-appi-2020": [ + "IV.1.24(1)", + "IV.1.24(2)", + "IV.1.24(3)" + ], + "apac-mys-pdpa-2010": [ + "129(1)", + "129(2)", + "129(2)(a)", + "129(2)(b)", + "129(3)", + "129(3)(a)", + "129(3)(b)", + "129(3)(c)", + "129(3)(c)(i)", + "129(3)(c)(ii)", + "129(3)(d)", + "129(3)(e)", + "129(3)(e)(i)", + "129(3)(e)(ii)", + "129(3)(e)(iii)", + "129(3)(f)", + "129(3)(g)", + "129(3)(h)", + "129(4)", + "129(4)(a)", + "129(4)(b)" ], "apac-nzl-privacy-act-2020": [ - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "3.1.22.12(1)", + "3.1.22.12(1)(a)", + "3.1.22.12(1)(b)", + "3.1.22.12(1)(c)", + "3.1.22.12(1)(d)", + "3.1.22.12(1)(e)", + "3.1.22.12(1)(f)", + "3.1.22.12(2)", + "3.1.22.12(3)" + ], + "apac-sgp-pdpa-2012": [ + "6.26(1)" + ], + "americas-bra-lgpd-2018": [ + "V.33", + "V.33.I", + "V.33.II", + "V.33.II(a)", + "V.33.II(b)", + "V.33.II(c)", + "V.33.II(d)", + "V.33.III", + "V.33.IV", + "V.33.V", + "V.33.VI", + "V.33.VII", + "V.33.VIII", + "V.33.IX", + "V.34", + "V.34.I", + "V.34.II", + "V.34.III", + "V.34.IV", + "V.34.V", + "V.34.VI" ] } }, @@ -1343,7 +1565,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure Personal Data (PD) is protected by logical and physical security safeguards that are sufficient and appropriately scoped to protect the confidentiality and integrity of the PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1392,7 +1614,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -1428,10 +1651,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.9.1" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.1" - ], "general-tisax-6-0-3": [ "7.1.2" ], @@ -1463,6 +1682,9 @@ "usa-state-il-pipa-2006": [ "45(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.1" + ], "usa-state-nv-regulation-5-2024": [ "5.260.1" ], @@ -1503,99 +1725,341 @@ "Article 32.1(a)", "Article 32.1(b)" ], + "emea-aut-dpa-2018": [ + "§ 6(1)", + "§ 13(1)", + "§ 54(1)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 34(2)", + "Title 2, Chapter III, Art. 45(4)", + "Title 2, Chapter IV, Section 1, Art. 50", + "Title 2, Chapter IV, Section 1, Art. 51(1)", + "Title 2, Chapter IV, Section 1, Art. 51(2)", + "Title 2, Chapter IV, Section 4, Art. 60(1)", + "Title 2, Chapter IV, Section 4, Art. 60(2)" + ], + "emea-deu-fdpa-2017": [ + "2.1.1.22(2)5", + "2.1.1.22(2)6", + "2.1.1.22(2)7", + "2.1.2.28(1)", + "3.2.53", + "3.4.62(5)2", + "3.4.64(1)", + "3.4.64(2)1", + "3.4.64(2)2", + "3.4.64(3)", + "3.4.64(3)1", + "3.4.64(3)2", + "3.4.64(3)3", + "3.4.64(3)4", + "3.4.64(3)5", + "3.4.64(3)6", + "3.4.64(3)7", + "3.4.64(3)8", + "3.4.64(3)9", + "3.4.64(3)10", + "3.4.64(3)11", + "3.4.64(3)12", + "3.4.64(3)13", + "3.4.64(3)14", + "3.4.71(2)" + ], + "emea-grc-pirppd-1997": [ + "B.9.2.f", + "B.10.1", + "B.10.2", + "B.10.3" + ], + "emea-hun-act-cxii-2011": [ + "II.6.7(2)", + "II.6.7(3)", + "II.6.7(4)", + "II.6.7(5)(a)", + "II.6.7(5)(b)", + "II.6.7(5)(c)", + "II.6.7(5)(d)", + "II.6.7(5)(e)", + "II.6.7(5)(f)", + "II.6.7(6)" + ], + "emea-irl-dpa-2018": [ + "s.72", + "s.75", + "s.76", + "s.77", + "s.78" + ], + "emea-isr-ppl-5741-2025": [ + "s.17" + ], + "emea-ita-pdpc-2018": [ + "Article 115(1)", + "Article 115(2)" + ], "emea-ken-pda-2019": [ - "29(f)", - "41(1)", - "41(1)(a)", - "41(1)(b)", - "41(2)", - "41(3)(a)", - "41(3)(b)", - "41(3)(c)", - "41(3)(d)", - "41(3)(e)", - "41(4)(a)", - "41(4)(b)", - "41(4)(c)", - "41(4)(d)", - "41(4)(e)", - "41(4)(f)", - "42(1)(a)", - "42(1)(b)", - "42(1)(c)", - "42(1)(d)", - "42(2)(a)", - "42(2)(b)", - "42(3)", - "42(4)" + "IV.41(1)", + "IV.41(1)(a)", + "IV.41(1)(b)", + "IV.41(2)", + "IV.41(3)", + "IV.41(3)(a)", + "IV.41(3)(b)", + "IV.41(3)(c)", + "IV.41(3)(d)", + "IV.41(3)(e)", + "IV.41(4)", + "IV.41(4)(a)", + "IV.41(4)(b)", + "IV.41(4)(c)", + "IV.41(4)(d)", + "IV.41(4)(e)", + "IV.41(4)(f)", + "IV.42(1)", + "IV.42(1)(a)", + "IV.42(1)(b)", + "IV.42(1)(c)", + "IV.42(1)(d)", + "IV.42(2)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], "emea-nga-dpr-2019": [ "2.1(1)(d)", "2.6" ], "emea-qat-pdppl-2020": [ - "8.3", - "13" + "3.13" + ], + "emea-rus-152-fz-2025": [ + "Art. 7", + "Art. 18.1", + "Art. 19" ], "emea-sau-pdpl-2023": [ "Article 19" ], "emea-srb-act-9-2018": [ - "5.6", - "41", - "42", - "42.1", - "42.2", - "50", - "50.1", - "50.2", - "50.3", - "50.4", - "51", - "51.1", - "51.2", - "51.3", - "51.4", - "51.5", - "51.6", - "51.7", - "51.8", - "51.9", - "51.10" + "II.6(5)", + "II.8", + "IV.1.41", + "IV.1.42", + "IV.1.42(1)", + "IV.1.42(2)", + "IV.2.50", + "IV.2.50(2)", + "IV.2.50(3)", + "IV.2.50(4)", + "IV.2.51", + "IV.2.51(1)", + "IV.2.51(2)", + "IV.2.51(3)", + "IV.2.51(4)", + "IV.2.51(5)", + "IV.2.51(6)", + "IV.2.51(7)", + "IV.2.51(8)", + "IV.2.51(9)", + "IV.2.51(10)" + ], + "emea-zaf-popia-2013": [ + "3.A.7.19(1)", + "3.A.7.19(1)(a)", + "3.A.7.19(1)(b)", + "3.A.7.19(2)", + "3.A.7.19(2)(a)", + "3.A.7.19(2)(b)", + "3.A.7.19(2)(c)", + "3.A.7.19(2)(d)", + "3.A.7.19(3)" + ], + "emea-esp-decree-311-2022": [ + "Article 5(a)", + "Article 5(b)", + "Article 5(c)", + "Article 5(d)", + "Article 5(e)", + "Article 5(f)", + "Article 5(g)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" + ], + "emea-che-fadp-2025": [ + "2.1.7.2", + "2.1.8.1", + "2.1.8.2" + ], + "emea-tur-lppd-2016": [ + "12(1)", + "12(1)(a)", + "12(1)(b)", + "12(1)(c)", + "12(2)", + "12(3)", + "12(4)", + "12(5)" + ], + "emea-gbr-dpa-2018": [ + "Section 55(3)", + "Section 55(3)(a)", + "Section 55(3)(b)", + "Section 55(3)(c)", + "Section 55(3)(d)", + "Section 56(1)", + "Section 56(2)", + "Section 56(3)", + "Section 57(1)", + "Section 57(1)(a)", + "Section 57(1)(b)", + "Section 57(2)", + "Section 57(3)", + "Section 57(4)", + "Section 57(4)(a)", + "Section 57(4)(b)", + "Section 57(4)(c)", + "Section 57(4)(d)", + "Section 57(5)", + "Section 66(1)", + "Section 66(2)", + "Section 66(2)(a)", + "Section 66(2)(b)", + "Section 66(2)(c)", + "Section 66(2)(d)", + "Section 66(3)" + ], + "apac-aus-privacy-principles-2026": [ + "4.11.1", + "4.11.1.a", + "4.11.1.b" + ], + "apac-aus-cop-sitc-2020": [ + "5" ], "apac-chn-cybersecurity-law-2017": [ "Article 42" ], + "apac-chn-csnip-2012": [ + "IV" + ], "apac-chn-pipl-2021": [ - "9", - "25", - "28", - "59" + "Article 9" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 4(1)", + "Schedule 1 - 4(1)(a)", + "Schedule 1 - 4(1)(b)", + "Schedule 1 - 4(1)(c)", + "Schedule 1 - 4(1)(d)", + "Schedule 1 - 4(1)(e)" ], "apac-ind-dpdpa-2023": [ "8(4)", "8(5)" ], - "apac-jpn-ppi-2020": [ - "20", - "21" + "apac-ind-privacy-rules-2011": [ + "5(8)", + "8(2)" + ], + "apac-jpn-appi-2020": [ + "IV.1.20" + ], + "apac-mys-pdpa-2010": [ + "9(1)", + "9(1)(a)", + "9(1)(b)", + "9(1)(c)", + "9(1)(d)", + "9(1)(e)", + "9(2)", + "9(2)(a)", + "9(2)(b)" ], "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "3.1.22.5(a)", + "3.1.22.5(a)(i)", + "3.1.22.5(a)(ii)", + "3.1.22.5(a)(iii)" ], - "apac-sgp-mas-trm-2021": [ - "14.1.1", - "14.1.2", - "14.1.3", - "14.1.4", - "14.1.5", - "14.1.6", - "14.1.7" + "apac-phl-dpa-2012": [ + "V.20(a)", + "V.20(b)", + "V.20(c)", + "V.20(c)(1)", + "V.20(c)(2)", + "V.20(c)(3)", + "V.20(c)(4)", + "V.20(d)", + "V.20(e)" + ], + "apac-sgp-pdpa-2012": [ + "6.24", + "6.24(a)", + "6.24(b)" + ], + "apac-twn-pdpa-2025": [ + "III.20-1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-1" + ], + "americas-bhs-dpa-2003": [ + "II.5(1)(f)", + "II.9(2)", + "II.11(1)", + "II.11(1)(a)", + "II.11(1)(b)", + "II.11(2)", + "V.43(4)(d)", + "V.43(4)(e)", + "V.52(1)", + "V.52(2)", + "V.52(2)(a)", + "V.52(2)(b)", + "V.52(2)(c)", + "V.52(2)(d)", + "V.52(4)" + ], + "americas-bra-lgpd-2018": [ + "VII.I.46", + "VII.I.46.1", + "VII.I.47", + "VII.I.49", + "VII.II.50", + "VII.II.50.1", + "VII.II.50.2", + "VII.II.50.2.I", + "VII.II.50.2.I(a)", + "VII.II.50.2.I(b)", + "VII.II.50.2.I(c)", + "VII.II.50.2.I(d)", + "VII.II.50.2.I(e)", + "VII.II.50.2.I(f)", + "VII.II.50.2.I(g)", + "VII.II.50.2.I(h)", + "VII.II.50.2.II" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(a)", + "P7-4.7", + "P7-4.7.1", + "P7-4.7.2", + "P7-4.7.3" + ], + "americas-chl-act-19628-1999": [ + "I.7", + "I.11" + ], + "americas-col-law-1581-2012": [ + "II.4(g)", + "VI.17(d)" + ], + "americas-mex-fdpa-2010": [ + "II.19", + "II.21" ] } }, @@ -1617,7 +2081,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to limit the disclosure of Personal Data (PD) to authorized parties for the sole purpose for which the PD was obtained.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1665,7 +2129,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -1712,49 +2177,16 @@ "10(c)(2)", "10(c)(5)" ], + "emea-grc-pirppd-1997": [ + "C.11.3" + ], "emea-sau-pdpl-2023": [ "Article 23.1", "Article 23.2", "Article 29.2.c" ], - "emea-srb-act-9-2018": [ - "33" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "22", - "25", - "41" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 11", - "P11-(1)", - "P11-(1)(a)", - "P11-(1)(b)", - "P11-(1)(c)", - "P11-(1)(d)", - "P11-(1)(e)(i)", - "P11-(1)(e)(ii)", - "P11-(1)(e)(iii)", - "P11-(1)(e)(iv)", - "P11-(1)(f)(i)", - "P11-(1)(f)(ii)", - "P11-(1)(g)", - "P11-(1)(h)(i)", - "P11-(1)(h)(ii)", - "P11-(1)(i)", - "P11-(2)", - "Principle 12", - "P12-(1)", - "P12-(1)(a)", - "P12-(1)(b)", - "P12-(1)(c)", - "P12-(1)(d)", - "P12-(1)(e)", - "P12-(1)(f)", - "P12-(2)", - "P12-(3)" + "apac-aus-privacy-principles-2026": [ + "3.6.1" ] } }, @@ -1776,7 +2208,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to appoint an individual to determine the following criteria about Personal Data (PD):\n(1) The purpose why PD is necessary; \n(2) Authorized methods to collect, receive, process, store, transmit, share, update and/or dispose PD; and\n(3) Authorized parties PD may be shared with.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1826,7 +2258,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -1850,7 +2283,7 @@ "title": "Personal Data (PD) Process Manager", "family": "PRI", "description": "Mechanisms exist to assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent.", - "scf_question": "Does the organization assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD)is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent?", + "scf_question": "Does the organization assign accountability to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -1863,7 +2296,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ Accountability is assigned to a Personal Data Process Manager, or equivalent role, to ensure Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed of according to data subject consent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1914,12 +2347,16 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "apac-ind-dpdpa-2023": [ "6(8)" + ], + "americas-mex-fdpa-2010": [ + "IV.30" ] } }, @@ -1941,7 +2378,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to strictly govern financial incentives offered to data subjects for Personal Data (PD) to ensure compliance with applicable legal and regulatory requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1977,7 +2414,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -2063,7 +2501,8 @@ "MT-12", "MT-13", "MT-14", - "MT-15" + "MT-15", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -2083,7 +2522,7 @@ "general-iso-29100-2024": [ "6.5", "6.8", - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "TS-1.14" @@ -2099,9 +2538,6 @@ "general-nist-800-37-r2": [ "TASK P-16" ], - "general-scf-dpmp-2025": [ - "1.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(D)" ], @@ -2165,6 +2601,14 @@ "usa-state-il-pipa-2006": [ "45(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.1", + "603A.510.3(b)", + "603A.525.1", + "603A.525.1(a)", + "603A.525.1(b)", + "603A.525.2(c)" + ], "usa-state-ny-shield-act-2019": [ "899-bb.2(a)", "899-bb.2(b)(ii)(A)" @@ -2203,44 +2647,729 @@ "2433(a)(2)(C)", "2447(a)(2)" ], - "apac-jpn-ismap": [ - "7.1.1.12", - "18.1.4", - "18.1.4.1", - "18.1.4.2", - "18.1.4.3", - "18.1.4.4", - "18.1.4.5", - "18.1.4.6" - ] - } - }, - { - "control_id": "PRI-02", - "title": "Data Privacy Notice", - "family": "PRI", - "description": "Mechanisms exist to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.", - "scf_question": "Does the organization:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements?", - "relative_weight": 7, - "conformity_cadence": "Annual", - "evidence_requests": [ - "E-PRI-08" - ], - "pptdf": "Process", - "nist_csf_function": "Identify", - "scrm_focus": { - "strategic": false, - "operational": true, - "tactical": false - }, - "maturity": { - "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", - "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ The CPO, or similar role, develops and ensures data privacy notices are published that include relevant purpose, notice and data privacy program information.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.", - "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." - }, + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(g)" + ], + "emea-eu-psd2-2015": [ + "94(1)", + "94(2)" + ], + "emea-aut-dpa-2018": [ + "§ 1(1)", + "§ 1(2)", + "§ 1(3)", + "§ 1(4)", + "§ 6(2)", + "§ 8(1)", + "§ 8(2)", + "§ 8(3)", + "§ 37(1)", + "§ 37(5)", + "§ 37(8)", + "§ 45(3)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(2)", + "Title 2, Chapter II, Art. 28", + "Title 2, Chapter II, Art. 32(1)", + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter II, Art. 34(1)", + "Title 2, Chapter III, Art. 39(3)", + "Title 2, Chapter III, Art. 45(3)", + "Title 4, Chapter III, Section 2, Art. 194", + "Title 4, Chapter III, Section 2, Art. 195", + "Title 4, Chapter III, Section 2, Art. 196", + "Title 4, Chapter III, Section 2, Art. 197", + "Title 4, Chapter III, Section 3, Art. 202(1)", + "Title 4, Chapter III, Section 3, Art. 202(2)" + ], + "emea-deu-fdpa-2017": [ + "2.2.32(1)1", + "2.2.32(1)2", + "2.2.32(1)3", + "2.2.32(1)4", + "2.2.32(1)5", + "2.2.32(2)", + "2.2.32(3)", + "2.2.33(1)1(a)", + "2.2.33(1)1(b)", + "2.2.33(1)2", + "2.2.33(2)", + "2.2.35(3)", + "2.2.36", + "3.1.47.1", + "3.2.48(2)", + "3.2.48(2)1", + "3.2.48(2)5", + "3.3.57(4)", + "3.3.58(3)", + "3.3.58(3)1", + "3.3.58(3)2", + "3.3.58(3)3", + "3.3.58(4)", + "3.3.59(3)", + "3.4.71(1)", + "3.4.74(1)", + "3.4.74(2)", + "3.5.80(1)", + "3.5.80(1)1", + "3.5.80(1)2", + "3.5.80(1)3", + "3.5.80(1)4", + "3.5.80(1)5", + "3.5.80(2)", + "3.5.80(3)", + "3.7.83(2)", + "3.7.83(3)", + "3.7.83(4)", + "3.7.83(5)" + ], + "emea-grc-pirppd-1997": [ + "B.4.1.a", + "B.4.1.b", + "B.7.2.b", + "B.7.2.c", + "B.7.2.d", + "B.7.2.e", + "B.7.2.f", + "B.7.2.g", + "B.9.2.f", + "C.11.4", + "C.11.5", + "C.12.3" + ], + "emea-hun-act-cxii-2011": [ + "II.5.6(1)(a)", + "II.5.6(5)(b)", + "II.6.7(1)", + "II.8.9(1)(c)", + "II.8.9(1)(d)", + "II.10.11(1)(a)", + "II.13.16(1)", + "II.13.17(3)", + "II.13.17(4)", + "II.13.17(5)", + "II.14.20(4)(e)", + "II.14.20(4)(f)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)", + "II.15.21(3)", + "II.15.21(7)", + "II.18.24(3)" + ], + "emea-irl-dpa-2018": [ + "s.71", + "s.94" + ], + "emea-isr-ppl-5741-2025": [ + "s.1", + "s.2", + "s.2A", + "s.3", + "s.16" + ], + "emea-ita-pdpc-2018": [ + "Article 75(1)", + "Article 102(1)", + "Article 102(2)(a)", + "Article 102(2)(b)", + "Article 102(2)(c)", + "Article 106(1)", + "Article 106(2)(a)", + "Article 106(2)(b)", + "Article 106(2)(c)", + "Article 106(2)(d)", + "Article 106(2)(g)", + "Article 106(2)(h)", + "Article 106(2)(i)", + "Article 126(1)", + "Article 126(2)", + "Article 126(3)", + "Article 126(4)" + ], + "emea-ken-pda-2019": [ + "IV.25(b)", + "IV.25(d)", + "IV.26", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(e)", + "IV.28(2)(f)", + "IV.28(2)(f)(i)", + "IV.28(2)(f)(ii)", + "IV.28(2)(f)(iii)", + "IV.28(3)", + "IV.33(2)", + "IV.33(3)", + "IV.33(3)(a)", + "IV.33(3)(b)", + "IV.33(3)(c)", + "IV.33(3)(d)", + "IV.33(3)(e)", + "IV.34(1)(c)", + "IV.34(1)(d)", + "IV.34(2)(a)", + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.35(2)(c)" + ], + "emea-nga-dpr-2019": [ + "2.4(a)", + "2.4(b)", + "2.6", + "2.8", + "2.9", + "2.12(b)", + "2.12(c)", + "2.12(d)", + "2.12(e)", + "2.12(f)", + "3.1(3)", + "3.1(3)(a)" + ], + "emea-qat-pdppl-2020": [ + "2.4", + "2.6.3", + "3.8.1", + "3.8.2", + "3.8.3", + "3.8.4", + "3.10", + "3.11.1", + "3.11.6", + "3.13", + "4.17.3", + "4.17.4", + "4.17.5" + ], + "emea-rus-152-fz-2025": [ + "Art. 5", + "Art. 6", + "Art. 11", + "Art. 18.1" + ], + "emea-srb-act-9-2018": [ + "II.5", + "II.5(1)", + "II.5(2)", + "II.5(3)", + "II.5(4)", + "II.5(5)", + "II.5(6)", + "II.6", + "II.12", + "III.1.21(1)", + "III.1.22(1)", + "III.2.24-4", + "III.2.24-4(1)", + "III.2.24-4(2)", + "III.2.24-4(3)", + "III.2.24-4(4)", + "III.2.25-1", + "III.2.25-1(1)", + "III.2.25-1(2)", + "III.2.25-1(3)", + "III.2.25-1(4)", + "III.2.25-1(5)", + "III.2.25-2", + "III.2.25-2(1)", + "III.2.25-2(2)", + "III.2.25-2(3)", + "III.2.25-2(4)", + "III.2.25-3", + "III.2.25-3(1)", + "III.2.25-3(2)", + "III.2.25-3(3)", + "III.2.25-3(4)", + "III.2.25-3(5)", + "III.2.28", + "III.2.28(1)", + "III.2.28(2)", + "III.2.28(3)", + "III.2.28(4)", + "III.2.28(5)", + "III.3.31(1)", + "III.3.31(2)", + "III.3.31(3)", + "III.3.31(4)", + "III.3.32(1)", + "III.3.32(2)", + "III.3.34(1)", + "III.3.34(2)", + "III.3.34(3)", + "III.3.34(4)", + "III.3.34(5)", + "III.4.38(1)", + "III.4.38(2)", + "III.4.38(3)" + ], + "emea-zaf-popia-2013": [ + "2.5(1)", + "2.5(1)(a)", + "2.5(1)(a)(i)", + "2.5(1)(a)(ii)", + "2.5(1)(b)", + "2.5(1)(c)", + "2.5(1)(d)", + "2.5(1)(e)", + "2.5(1)(e)(i)", + "2.5(1)(e)(ii)", + "2.5(1)(f)", + "2.5(1)(g)", + "2.5(1)(h)", + "2.5(1)(i)", + "3.A.2.9(1)", + "3.A.2.9(1)(a)", + "3.A.2.9(1)(b)", + "3.A.2.10", + "3.A.2.11(2)(a)", + "3.A.2.12(2)", + "3.A.2.12(2)(a)", + "3.A.2.12(2)(b)", + "3.A.2.12(2)(c)", + "3.A.2.12(2)(d)", + "3.A.2.12(2)(d)(i)", + "3.A.2.12(2)(d)(ii)", + "3.A.2.12(2)(d)(iii)", + "3.A.2.12(2)(d)(iv)", + "3.A.2.12(2)(d)(v)", + "3.A.2.12(2)(e)", + "3.A.2.12(2)(f)", + "3.A.6.17", + "3.A.6.18(1)", + "3.A.6.18(1)(a)", + "3.A.6.18(1)(b)", + "3.A.6.18(1)(c)", + "3.A.6.18(1)(d)", + "3.A.6.18(1)(e)", + "3.A.6.18(1)(f)", + "3.A.6.18(1)(g)", + "3.A.6.18(1)(h)", + "3.A.6.18(1)(h)(i)", + "3.A.6.18(1)(h)(ii)", + "3.A.6.18(1)(h)(iii)", + "3.A.6.18(1)(h)(iv)", + "3.A.6.18(1)(h)(v)", + "3.A.6.18(2)", + "3.A.6.18(2)(a)", + "3.A.6.18(2)(b)", + "3.A.6.18(3)", + "3.A.6.18(4)", + "3.A.6.18(4)(a)", + "3.A.6.18(4)(b)", + "3.A.6.18(4)(c)", + "3.A.6.18(4)(c)(i)", + "3.A.6.18(4)(c)(ii)", + "3.A.6.18(4)(c)(iii)", + "3.A.6.18(4)(c)(iv)", + "3.A.6.18(4)(d)", + "3.A.6.18(4)(e)", + "3.A.6.18(4)(f)", + "3.A.6.18(4)(f)(i)", + "3.A.6.18(4)(f)(ii)", + "3.A.7.20(1)", + "3.A.7.20(1)(a)", + "3.A.7.20(1)(b)" + ], + "emea-che-fadp-2025": [ + "2.1.6.1", + "2.1.6.2", + "2.1.7.1", + "4.25.6" + ], + "emea-gbr-dpa-2018": [ + "Section 45(4)", + "Section 45(4)(a)", + "Section 45(4)(b)", + "Section 45(4)(c)", + "Section 45(4)(e)", + "Section 47(2)" + ], + "apac-aus-privacy-principles-2026": [ + "1.1.2", + "2.3.1", + "2.3.2", + "2.3.5", + "2.3.7", + "2.4.1", + "2.4.1.a", + "2.4.1.b", + "2.4.2", + "2.4.3", + "2.4.3.a", + "2.4.3.b", + "2.4.4", + "3.9.1", + "3.9.1.a", + "3.9.1.b", + "5.12.7", + "5.12.8", + "5.12.8.a", + "5.12.8.b" + ], + "apac-aus-cop-sitc-2020": [ + "5" + ], + "apac-chn-data-security-law-2021": [ + "Article 33" + ], + "apac-chn-csnip-2012": [ + "I", + "II", + "VI" + ], + "apac-chn-pipl-2021": [ + "Article 5", + "Article 7", + "Article 10", + "Article 26", + "Article 27" + ], + "apac-hkg-pdo-2022": [ + "28(1)", + "28(2)", + "28(3)", + "28(4)", + "28(4)(II)", + "28(5)", + "28(6)", + "28(6)(a)", + "28(6)(b)", + "29", + "29(a)", + "29(b)", + "Schedule 1 - 1(1)(a)", + "Schedule 1 - 1(1)(b)", + "Schedule 1 - 1(1)(c)", + "Schedule 1 - 1(2)(a)", + "Schedule 1 - 1(2)(b)" + ], + "apac-ind-privacy-rules-2011": [ + "4(v)", + "8(1)", + "8(4)" + ], + "apac-jpn-appi-2020": [ + "IV.1.17(1)", + "IV.1.26-2(1)", + "IV.2.35-2(7)", + "IV.2.35-2(8)", + "IV.2.35-3(1)", + "IV.3.36(1)", + "IV.3.36(2)", + "IV.3.36(3)", + "IV.3.36(4)", + "IV.3.36(5)", + "IV.3.36(6)", + "IV.3.37", + "IV.3.38", + "IV.3.39", + "IV.5.54" + ], + "apac-jpn-ismap": [ + "7.1.1.12", + "18.1.4", + "18.1.4.1", + "18.1.4.2", + "18.1.4.3", + "18.1.4.4", + "18.1.4.5", + "18.1.4.6" + ], + "apac-mys-pdpa-2010": [ + "5(1)", + "5(1)(a)", + "5(1)(b)", + "5(1)(c)", + "5(1)(d)", + "5(1)(e)", + "5(1)(f)", + "5(1)(g)", + "130(1)", + "130(1)(a)", + "130(1)(b)", + "130(2)", + "130(2)(a)", + "130(2)(a)(i)", + "130(2)(a)(ii)", + "130(2)(b)", + "130(2)(c)", + "130(2)(d)", + "130(3)", + "130(4)", + "130(5)", + "130(5)(a)", + "130(5)(b)", + "130(6)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.4", + "3.1.22.4(a)", + "3.1.22.4(b)", + "3.1.22.4(b)(i)", + "3.1.22.4(b)(ii)", + "3.1.22.5", + "3.1.22.5(b)", + "4.1.47(1)", + "4.1.47(1)(a)", + "4.1.47(1)(b)" + ], + "apac-phl-dpa-2012": [ + "III.11", + "III.11(b)", + "III.11(d)" + ], + "apac-sgp-pdpa-2012": [ + "3.11(1)", + "4.1.14(2)(a)", + "4.1.14(2)(b)", + "4.1.15A(4)(c)", + "4.1.15A(5)(c)", + "9.3.46(2)(a)", + "9.3.46(2)(b)", + "9.3.47(2)" + ], + "apac-kor-pipa-2011": [ + "I.3(1)", + "I.3(2)", + "I.3(3)", + "I.3(4)", + "I.3(5)", + "I.3(6)", + "I.3(7)", + "I.3(8)", + "I.4", + "I.4.1", + "I.4.2", + "I.4.3", + "I.4.4", + "I.4.5", + "III.2.23", + "III.2.24(1)", + "III.2.24(1)1", + "III.2.24(1)2", + "III.2.24(2)", + "III.2.24(3)", + "III.2.24(4)", + "IV.29", + "V.38(3)", + "V.38(4)", + "V.38(5)", + "VIII.60" + ], + "apac-twn-pdpa-2025": [ + "I.5" + ], + "americas-arg-ppd-2018": [ + "A", + "A.1.1", + "A.1.2", + "A.1.3", + "A.2.2-1", + "A.2.2-2" + ], + "americas-bhs-dpa-2003": [ + "II.5(1)(a)", + "II.5(1)(b)", + "II.5(1)(c)", + "II.5(1)(d)", + "II.5(1)(e)", + "II.5(1)(f)", + "II.5(2)", + "II.5(3)", + "II.8(4)", + "V.43(4)(d)", + "V.43(4)(e)" + ], + "americas-bra-lgpd-2018": [ + "II.I.10", + "II.I.10.I", + "II.I.10.II", + "II.I.10.II.1", + "II.I.10.II.2", + "II.II.11.I", + "II.II.11.II", + "II.II.11.II(a)", + "II.II.11.II(b)", + "II.II.11.II(c)", + "II.II.11.II(d)", + "II.II.11.II(e)", + "II.II.11.II(f)", + "II.II.11.II(g)", + "II.II.11.II(g)1", + "II.II.11.II(g)2", + "II.II.11.II(g)3", + "II.II.11.II(g)4", + "III.21" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(a)", + "P3-4.3.3", + "P4-4.4.1", + "P4-4.4.2" + ], + "americas-chl-act-19628-1999": [ + "I.7", + "I.11" + ], + "americas-col-law-1581-2012": [ + "II.4(d)", + "II.4(g)", + "VI.17(a)", + "VI.17(e)" + ], + "americas-mex-fdpa-2010": [ + "II.6", + "II.7", + "II.9", + "II.10", + "II.10.I", + "II.10.II", + "II.10.III", + "II.10.IV", + "II.10.V", + "II.10.VI", + "II.10.VII", + "III.26", + "III.26.I", + "III.26.II", + "III.26.III", + "III.26.IV", + "III.26.V", + "III.26.VI", + "III.26.VII", + "IV.34", + "IV.35" + ] + } + }, + { + "control_id": "PRI-01.12", + "title": "Privacy-Aware Design", + "family": "PRI", + "description": "Mechanisms exist to formally incorporate the organization's data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "scf_question": "Does the organization formally incorporate its data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to formally incorporate the organization's data privacy principles into engineering, product and model design requirements to ensure data privacy is built in by default and by design.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Privacy by design principles (basic data minimization practices)\n∙ NIST Privacy Framework reference", + "small": "∙ Privacy by design checklist for new systems\n∙ NIST Privacy Framework or GDPR Art. 25 alignment", + "medium": "∙ Privacy by design and by default program\n∙ DPIA for new systems\n∙ Privacy engineering practices in SDLC", + "large": "∙ Enterprise privacy engineering program\n∙ Privacy by design requirements in system development lifecycle\n∙ DPIA for new data processing", + "enterprise": "∙ Enterprise privacy engineering framework\n∙ Automated privacy design reviews in SDLC\n∙ DPIA for all new data processing\n∙ Privacy technology stack (e.g., OneTrust)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-4", + "R-AM-2", + "R-AM-3", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-19", + "MT-20", + "MT-21", + "MT-22", + "MT-23", + "MT-24", + "MT-25", + "MT-28" + ], + "errata": "- new control - NIST Privacy Framework", + "family_name": "Data Privacy", + "crosswalks": { + "general-nist-privacy-framework-1-0": [ + "CT.DM-P10" + ] + } + }, + { + "control_id": "PRI-02", + "title": "Data Privacy Notice", + "family": "PRI", + "description": "Mechanisms exist to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.", + "scf_question": "Does the organization:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-PRI-08" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ The CPO, or similar role, develops and ensures data privacy notices are published that include relevant purpose, notice and data privacy program information.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to:\n(1) Make data privacy notice(s) available to individuals upon first interacting with an organization and subsequently as necessary; \n(2) Ensure that data privacy notices are clear and easy-to-understand, expressing relevant information about how Personal Data (PD) is collected, received, processed, stored, transmitted, shared, updated and/or disposed;\n(3) Contain all necessary notice-related criteria required by applicable statutory, regulatory and contractual obligations;\n(4) Define the scope of PD processing activities, including the geographic locations and third-party recipients that process the PD within the scope of the data privacy notice;\n(5) Periodically, review and update the content of the privacy notice, as necessary; and\n(6) Retain prior versions of the privacy notice, in accordance with data retention requirements.\n", + "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, "profiles": [ "SCRMS", "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -2289,7 +3418,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -2362,9 +3492,6 @@ "general-nist-800-82-r3-high": [ "PM-20(01)" ], - "general-scf-dpmp-2025": [ - "4.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(A)(i)" ], @@ -2395,50 +3522,50 @@ "155.260(a)(3)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.520(a)(1)", - "164.520(a)(2)(i)", - "164.520(a)(2)(i)(A)", - "164.520(a)(2)(i)(B)", - "164.520(a)(2)(ii)", - "164.520(a)(2)(ii)(A)", - "164.520(a)(2)(ii)(B)", - "164.520(a)(2)(iii)", - "164.520(b)(1)", - "164.520(b)(1)(i)", - "164.520(b)(1)(ii)", - "164.520(b)(1)(ii)(A)", - "164.520(b)(1)(ii)(B)", - "164.520(b)(1)(ii)(C)", - "164.520(b)(1)(ii)(D)", - "164.520(b)(1)(ii)(E)", - "164.520(b)(1)(iv)", - "164.520(b)(1)(iv)(A)", - "164.520(b)(1)(iv)(B)", - "164.520(b)(1)(iv)(C)", - "164.520(b)(1)(iv)(D)", - "164.520(b)(1)(iv)(E)", - "164.520(b)(1)(iv)(F)", - "164.520(b)(1)(v)", - "164.520(b)(1)(v)(A)", - "164.520(b)(1)(v)(B)", - "164.520(b)(1)(v)(C)", - "164.520(b)(1)(vi)", - "164.520(b)(1)(vii)", - "164.520(b)(1)(viii)", - "164.520(b)(2)(i)", - "164.520(b)(2)(ii)", - "164.520(b)(3)", - "164.520(c)", - "164.520(c)(1)(i)", - "164.520(c)(1)(i)(A)", - "164.520(c)(1)(i)(B)", - "164.520(c)(1)(ii)", - "164.520(c)(1)(iii)", - "164.520(c)(1)(iv)", - "164.520(c)(1)(v)", - "164.520(c)(1)(v)(A)", - "164.520(c)(1)(v)(B)", - "164.530(i)(4)(i)(C)" + "§ 164.520(a)(1)", + "§ 164.520(a)(2)(i)", + "§ 164.520(a)(2)(i)(A)", + "§ 164.520(a)(2)(i)(B)", + "§ 164.520(a)(2)(ii)", + "§ 164.520(a)(2)(ii)(A)", + "§ 164.520(a)(2)(ii)(B)", + "§ 164.520(a)(2)(iii)", + "§ 164.520(b)(1)", + "§ 164.520(b)(1)(i)", + "§ 164.520(b)(1)(ii)", + "§ 164.520(b)(1)(ii)(A)", + "§ 164.520(b)(1)(ii)(B)", + "§ 164.520(b)(1)(ii)(C)", + "§ 164.520(b)(1)(ii)(D)", + "§ 164.520(b)(1)(ii)(E)", + "§ 164.520(b)(1)(iv)", + "§ 164.520(b)(1)(iv)(A)", + "§ 164.520(b)(1)(iv)(B)", + "§ 164.520(b)(1)(iv)(C)", + "§ 164.520(b)(1)(iv)(D)", + "§ 164.520(b)(1)(iv)(E)", + "§ 164.520(b)(1)(iv)(F)", + "§ 164.520(b)(1)(v)", + "§ 164.520(b)(1)(v)(A)", + "§ 164.520(b)(1)(v)(B)", + "§ 164.520(b)(1)(v)(C)", + "§ 164.520(b)(1)(vi)", + "§ 164.520(b)(1)(vii)", + "§ 164.520(b)(1)(viii)", + "§ 164.520(b)(2)(i)", + "§ 164.520(b)(2)(ii)", + "§ 164.520(b)(3)", + "§ 164.520(c)", + "§ 164.520(c)(1)(i)", + "§ 164.520(c)(1)(i)(A)", + "§ 164.520(c)(1)(i)(B)", + "§ 164.520(c)(1)(ii)", + "§ 164.520(c)(1)(iii)", + "§ 164.520(c)(1)(iv)", + "§ 164.520(c)(1)(v)", + "§ 164.520(c)(1)(v)(A)", + "§ 164.520(c)(1)(v)(B)", + "§ 164.530(i)(4)(i)(C)" ], "usa-federal-cms-marse-2-0": [ "TR-1", @@ -2540,6 +3667,28 @@ "35(a)(5)", "37(a)(5)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.340.1", + "603A.340.1(b)", + "603A.340.1(c)", + "603A.340.1(d)", + "603A.340.1(e)", + "603A.345.1", + "603A.346.1", + "603A.495.1", + "603A.495.1(a)", + "603A.495.1(b)", + "603A.495.1(c)", + "603A.495.1(d)", + "603A.495.1(e)", + "603A.495.1(f)", + "603A.495.1(g)", + "603A.495.1(h)", + "603A.495.1(i)", + "603A.495.1(j)", + "603A.495.1(k)", + "603A.495.2" + ], "usa-state-or-ors-646a-2025": [ "646A.578(1)(a)", "646A.578(4)", @@ -2638,31 +3787,84 @@ "Article 14.4", "Article 14.5(a)" ], - "emea-bel-act-8-1992": [ - "9" + "emea-aut-dpa-2018": [ + "§ 43(1)", + "§ 43(2)", + "§ 43(3)", + "§ 43(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 37(1)", + "Title 2, Chapter III, Art. 37(2)", + "Title 4, Chapter III, Section 1, Art. 193" ], "emea-deu-fdpa-2017": [ - "Sec 4", - "Sec 19" + "3.2.51(4)", + "3.3.55", + "3.3.55.1", + "3.3.55.2", + "3.3.55.3", + "3.3.55.4", + "3.3.55.5", + "3.3.56(1)", + "3.3.56(1)1", + "3.3.56(1)2", + "3.3.56(1)3", + "3.3.56(1)4", + "3.3.56(1)5", + "3.3.56(2)1", + "3.3.56(2)2", + "3.3.56(2)3", + "3.3.56(3)" ], - "emea-ita-pdpc-2003": [ - "11", - "13", - "37" + "emea-grc-pirppd-1997": [ + "C.11.1", + "C.11.1.a", + "C.11.1.b", + "C.11.1.c", + "C.11.1.d", + "C.11.2", + "C.11.3" + ], + "emea-hun-act-cxii-2011": [ + "II.5.6(4)", + "II.7.8(1)(a)", + "II.14.20(1)", + "II.14.20(2)", + "II.14.20(4)(a)", + "II.14.20(4)(b)", + "II.14.20(4)(d)" + ], + "emea-irl-dpa-2018": [ + "s.90" + ], + "emea-isr-ppl-5741-2025": [ + "s.11" + ], + "emea-ita-pdpc-2018": [ + "Article 2-d(2)", + "Article 77(1)(a)", + "Article 77(1)(b)", + "Article 78(1)", + "Article 78(2)", + "Article 78(3)", + "Article 132-c(1)" ], "emea-ken-pda-2019": [ - "25(e)", - "26(a)", - "29(a)", - "29(b)", - "29(c)", - "29(d)", - "29(e)", - "29(f)", - "29(g)", - "29(h)" + "IV.25(e)", + "IV.26(a)", + "IV.29", + "IV.29(a)", + "IV.29(b)", + "IV.29(c)", + "IV.29(d)", + "IV.29(e)", + "IV.29(f)", + "IV.29(g)", + "IV.29(h)" ], "emea-nga-dpr-2019": [ + "2.3(1)", "2.5", "2.5(a)", "2.5(b)", @@ -2674,6 +3876,7 @@ "2.5(h)", "2.5(i)", "3.1(1)", + "3.1(7)", "3.1(7)(a)", "3.1(7)(b)", "3.1(7)(c)", @@ -2688,34 +3891,21 @@ "3.1(7)(l)", "3.1(7)(m)", "3.1(7)(n)", - "3.1(9)", - "3.1(9)(a)", - "3.1(9)(b)", - "3.1(9)(c)", - "3.1(9)(d)", - "3.1(9)(e)" + "3.1(8)" ], - "emea-nor-pda-2018": [ - "31" - ], - "emea-pol-act-29-1997": [ - "23" + "emea-pol-act-10-2018": [ + "Art. 11" ], "emea-qat-pdppl-2020": [ - "6.1", - "8.1", - "9.1", - "9.3", - "9.4", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" - ], - "emea-rus-federal-law-27-2006": [ - "22" + "3.9", + "3.9.1", + "3.9.2", + "3.9.3", + "3.9.4", + "4.17.1" + ], + "emea-rus-152-fz-2025": [ + "Art. 18" ], "emea-sau-pdpl-2023": [ "Article 4.1", @@ -2726,22 +3916,77 @@ "Article 13.6" ], "emea-srb-act-9-2018": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" + "III.1.21", + "III.2.23-1", + "III.2.23-1(1)", + "III.2.23-1(2)", + "III.2.23-1(3)", + "III.2.23-1(4)", + "III.2.23-1(5)", + "III.2.23-1(6)", + "III.2.23-2", + "III.2.23-2(1)", + "III.2.23-2(2)", + "III.2.23-2(3)", + "III.2.23-2(4)", + "III.2.23-2(5)", + "III.2.23-2(6)", + "III.2.24-1", + "III.2.24-1(1)", + "III.2.24-1(2)", + "III.2.24-1(3)", + "III.2.24-1(4)", + "III.2.24-1(5)", + "III.2.24-1(6)", + "III.2.24-2", + "III.2.24-2(1)", + "III.2.24-2(2)", + "III.2.24-2(3)", + "III.2.24-2(4)", + "III.2.24-2(5)", + "III.2.24-2(6)", + "III.2.24-2(7)", + "III.2.24-3", + "III.2.24-3(1)", + "III.2.24-3(2)", + "III.2.24-3(3)" ], "emea-zaf-popia-2013": [ - "18" + "3.A.3.13(1)", + "3.A.3.13(2)" ], - "emea-esp-decree-1720-2007": [ - "8" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" + ], + "emea-che-fadp-2025": [ + "2.2.15.3", + "3.19.1", + "3.19.2", + "3.19.2.a", + "3.19.2.b", + "3.19.2.c", + "3.19.3", + "3.19.4", + "3.19.5", + "3.21.1" ], "emea-tur-lppd-2016": [ - "10" + "10(1)", + "10(1)(a)", + "10(1)(b)", + "10(1)(c)", + "10(1)(ç)", + "10(1)(d)", + "11(1)", + "11(1)(a)", + "11(1)(b)", + "11(1)(c)", + "11(1)(ç)", + "11(1)(d)", + "11(1)(e)", + "11(1)(f)", + "11(1)(g)", + "11(1)(ğ)" ], "emea-gbr-def-stan-05-138-2024": [ "2406", @@ -2758,26 +4003,93 @@ "2406", "2407" ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principles 8" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 5" + "emea-gbr-dpa-2018": [ + "Section 44(1)", + "Section 44(1)(a)", + "Section 44(1)(b)", + "Section 44(1)(c)", + "Section 44(1)(d)", + "Section 44(1)(d)(i)", + "Section 44(1)(d)(ii)", + "Section 44(1)(d)(iii)", + "Section 44(1)(e)", + "Section 44(2)", + "Section 44(2)(b)", + "Section 44(2)(c)", + "Section 44(2)(d)", + "Section 44(3)", + "Section 69(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 1", - "APP 5" + "1.1.3", + "1.1.4", + "1.1.4.a", + "1.1.4.b", + "1.1.4.c", + "1.1.4.d", + "1.1.4.e", + "1.1.4.f", + "1.1.4.g", + "1.1.5", + "1.1.5.a", + "1.1.5.b", + "1.1.6", + "2.5.1", + "2.5.1.a", + "2.5.1.b", + "2.5.2", + "2.5.2.a", + "2.5.2.b", + "2.5.2.b.i", + "2.5.2.b.ii", + "2.5.2.c", + "2.5.2.d", + "2.5.2.e", + "2.5.2.f", + "2.5.2.g", + "2.5.2.h", + "2.5.2.i", + "2.5.2.j" ], "apac-chn-pipl-2021": [ - "7", - "17", - "17(1)", - "17(2)", - "17(3)", - "17(4)", - "27", - "39", - "48" + "Article 17", + "Article 18", + "Article 30", + "Article 39" + ], + "apac-hkg-pdo-2022": [ + "35C(2)", + "35C(2)(a)", + "35C(2)(a)(i)", + "35C(2)(a)(ii)", + "35C(2)(b)", + "35C(2)(b)(i)", + "35C(2)(b)(ii)", + "35C(2)(c)", + "35C(3)", + "35C(4)", + "35C(5)", + "35J(2)", + "35J(2)(a)", + "35J(2)(a)(i)", + "35J(2)(a)(ii)", + "35J(2)(b)", + "35J(2)(b)(i)", + "35J(2)(b)(ii)", + "35J(2)(b)(iii)", + "35J(2)(b)(iv)", + "35J(2)(c)", + "35J(3)", + "35J(4)", + "35J(5)", + "35J(5)(a)", + "35J(5)(b)", + "Schedule 1 - 1(3)(a)", + "Schedule 1 - 1(3)(b)(ii)(B)", + "Schedule 1 - 5", + "Schedule 1 - 5(a)", + "Schedule 1 - 5(b)", + "Schedule 1 - 5(c)" ], "apac-ind-dpdpa-2023": [ "5(1)(i)", @@ -2789,71 +4101,214 @@ "6(3)", "6(10)" ], - "apac-jpn-ppi-2020": [ - "15(1)", - "15(2)" + "apac-ind-privacy-rules-2011": [ + "4", + "4(i)", + "4(ii)", + "4(iii)", + "4(iv)", + "4(v)", + "5(3)", + "5(3)(a)", + "5(3)(b)", + "5(3)(c)", + "5(3)(d)", + "5(3)(d)(i)", + "5(3)(d)(ii)" + ], + "apac-jpn-appi-2020": [ + "IV.1.18(1)", + "IV.1.18(2)", + "IV.1.18(3)", + "IV.1.23(2)", + "IV.1.23(2)(i)", + "IV.1.23(2)(ii)", + "IV.1.23(2)(iii)", + "IV.1.23(2)(iv)", + "IV.1.23(2)(v)", + "IV.1.23(2)(vi)", + "IV.1.23(2)(vii)", + "IV.1.23(2)(viii)", + "IV.1.27(1)", + "IV.1.27(1)(i)", + "IV.1.27(1)(ii)", + "IV.1.27(1)(iii)", + "IV.1.27(1)(iv)" ], "apac-mys-pdpa-2010": [ - "7" + "7(1)", + "7(1)(a)", + "7(1)(b)", + "7(1)(c)", + "7(1)(d)", + "7(1)(e)", + "7(1)(f)", + "7(1)(g)", + "7(1)(h)", + "7(2)", + "7(2)(a)", + "7(2)(b)", + "7(2)(c)", + "7(2)(c)(i)", + "7(2)(c)(ii)" + ], + "apac-mys-bnm-rmit-2025": [ + "16.2" ], "apac-nzl-privacy-act-2020": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" + "3.1.22.3(1)", + "3.1.22.3(1)(a)", + "3.1.22.3(1)(b)", + "3.1.22.3(1)(c)", + "3.1.22.3(1)(d)", + "3.1.22.3(1)(d)(i)", + "3.1.22.3(1)(d)(ii)", + "3.1.22.3(1)(e)", + "3.1.22.3(1)(e)(i)", + "3.1.22.3(1)(e)(ii)", + "3.1.22.3(1)(f)", + "3.1.22.3(1)(g)", + "4.1.45(1)", + "4.1.45(1)(a)", + "4.1.45(1)(b)", + "4.1.45(1)(c)", + "4.1.45(2)" ], "apac-sgp-pdpa-2012": [ - "14" + "3.11(5)", + "3.11(5A)", + "4.1.14(1)(a)", + "4.1.15A(4)(b)", + "4.1.15A(4)(b)(i)", + "4.1.15A(4)(b)(ii)", + "4.1.15A(4)(b)(iii)", + "4.2.20(1)(a)", + "4.2.20(1)(b)", + "4.2.20(1)(c)", + "4.2.20(2)" + ], + "apac-sgp-mas-trm-2021": [ + "14.4.1" ], "apac-kor-pipa-2011": [ - "3", - "4" + "III.1.18(3)", + "III.1.18(3)1", + "III.1.18(3)2", + "III.1.18(3)3", + "III.1.18(3)4", + "III.1.18(3)5", + "IV.30(1)", + "IV.30(1)1", + "IV.30(1)2", + "IV.30(1)3", + "IV.30(1)4", + "IV.30(1)5", + "IV.30(1)6", + "IV.30(2)", + "IV.30(3)" ], "apac-twn-pdpa-2025": [ - "5" + "I.8-1", + "I.8.1-1", + "I.8.2-1", + "I.8.3-1", + "I.8.4-1", + "I.8.5-1", + "I.8.6-1", + "I.8-2", + "I.8.1-2", + "I.8.2-2", + "I.8.3-2", + "I.8.4-2", + "I.8.5-2", + "I.8.6-2", + "I.9", + "I.9.1", + "I.9.2", + "I.9.3", + "I.9.4", + "I.9.5" + ], + "americas-bhs-dpa-2003": [ + "II.8(1)", + "II.8(1)(a)", + "II.8(1)(b)", + "II.8(1)(c)", + "II.8(1)(d)", + "II.8(1)(e)", + "II.8(1)(f)", + "II.8(1)(g)", + "II.8(1)(g)(i)", + "II.8(1)(g)(ii)", + "II.8(1)(g)(iii)", + "II.8(1)(h)", + "II.8(1)(i)", + "II.8(2)", + "II.8(2)(a)", + "II.8(2)(b)", + "IV.24(1)(a)", + "IV.24(1)(b)", + "IV.24(1)(b)(i)", + "IV.24(1)(b)(ii)", + "IV.24(1)(b)(iii)", + "IV.24(1)(b)(iv)", + "IV.24(1)(b)(v)", + "IV.24(1)(c)", + "IV.24(1)(c)(i)", + "IV.24(1)(c)(ii)", + "IV.24(1)(c)(iii)", + "IV.24(1)(d)", + "IV.24(1)(e)", + "IV.24(1)(f)", + "IV.24(1)(g)", + "V.45(8)", + "V.52(3)" ], "americas-bra-lgpd-2018": [ - "6.2", - "6.6", - "8" + "II.I.9", + "II.I.9.I", + "II.I.9.II", + "II.I.9.III", + "II.I.9.IV", + "II.I.9.V", + "II.I.9.VI", + "II.I.9.VII", + "II.I.9.VII.1" ], "americas-can-pipeda-2000": [ - "Principle 2" - ], - "americas-chl-act-19628-1999": [ - "5" + "P2-4.2", + "P2-4.2.1", + "P2-4.2.2", + "P2-4.2.3", + "P8-4.8", + "P8-4.8.1", + "P8-4.8.2", + "P8-4.8.2(a)", + "P8-4.8.2(b)", + "P8-4.8.2(c)", + "P8-4.8.2(d)", + "P8-4.8.2(e)", + "P8-4.8.3" ], "americas-col-law-1581-2012": [ - "12" + "VI.17(c)" ], "americas-mex-fdpa-2010": [ - "7", - "16", - "17", - "18" + "II.7", + "II.12", + "II.15", + "II.16", + "II.16.I", + "II.16.II", + "II.16.III", + "II.16.IV", + "II.16.V", + "II.16.VI", + "II.17", + "II.17.I", + "II.17.II", + "II.18", + "V.36" ] } }, @@ -2875,7 +4330,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data privacy notices identify the purpose(s) for which Personal Data (PD) is collected, received, processed, stored, transmitted and/or shared.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2928,7 +4383,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -2975,9 +4431,6 @@ "general-oecd-privacy-principles-2010": [ "3" ], - "general-scf-dpmp-2025": [ - "4.1" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.1.a.iv", "II.5.a" @@ -2999,13 +4452,13 @@ "7" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(3)", - "164.508(c)(1)(i)", - "164.508(c)(1)(ii)", - "164.508(c)(1)(iii)", - "164.508(c)(1)(iv)", - "164.508(c)(2)(i)(A)", - "164.508(c)(2)(i)(B)" + "§ 164.502(a)(3)", + "§ 164.508(c)(1)(i)", + "§ 164.508(c)(1)(ii)", + "§ 164.508(c)(1)(iii)", + "§ 164.508(c)(1)(iv)", + "§ 164.508(c)(2)(i)(A)", + "§ 164.508(c)(2)(i)(B)" ], "usa-federal-cms-marse-2-0": [ "AP-2" @@ -3038,74 +4491,27 @@ "Article 13.1(c)", "Article 14.1(c)" ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "8" - ], - "emea-ita-pdpc-2003": [ - "13" + "emea-deu-fdpa-2017": [ + "3.3.56(1)2" ], - "emea-ken-pda-2019": [ - "29(c)" + "emea-hun-act-cxii-2011": [ + "II.8.9(1)(a)", + "II.14.20(2)", + "II.14.20(4)(c)" ], "emea-nga-dpr-2019": [ "2.3(1)" ], - "emea-nor-pda-2018": [ - "32" - ], - "emea-pol-act-29-1997": [ - "23" - ], - "emea-qat-pdppl-2020": [ - "6.1", - "8.1", - "10" - ], - "emea-rus-federal-law-27-2006": [ - "5" - ], "emea-sau-pdpl-2023": [ "Article 11.1", "Article 13.2", "Article 13.3" ], - "emea-srb-act-9-2018": [ - "5.1", - "6.1", - "12.2", - "12.3", - "12.4", - "12.5", - "12.6" - ], - "emea-zaf-popia-2013": [ - "13", - "18" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 1" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.1" ], "apac-chn-pipl-2021": [ - "6", - "48" - ], - "apac-hkg-pdo-2022": [ - "Principle 1" + "Article 6" ], "apac-ind-dpdpa-2023": [ "4(2)", @@ -3114,83 +4520,20 @@ "7(a)", "8(8)(a)" ], - "apac-jpn-ppi-2020": [ - "15(1)", - "15(2)" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)" + "apac-jpn-appi-2020": [ + "IV.1.15(1)" ], "apac-phl-dpa-2012": [ - "19" - ], - "apac-sgp-pdpa-2012": [ - "14", - "19", - "20" - ], - "apac-kor-pipa-2011": [ - "3", - "4" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "6", - "27.1", - "27.2", - "28.1" + "III.12" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.1", - "6.3" + "II.5(1)(b)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 2" - ], - "americas-chl-act-19628-1999": [ - "5" - ], - "americas-col-law-1581-2012": [ - "4" + "P2-4.2" ], "americas-mex-fdpa-2010": [ - "7", - "16", - "17", - "18" + "II.16.II" ] } }, @@ -3199,7 +4542,7 @@ "title": "Automated Data Management Processes", "family": "PRI", "description": "Automated mechanisms exist to adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s).", - "scf_question": "Does the organization use automated mechanisms to adjust data that is able tobe collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s)?", + "scf_question": "Does the organization use automated mechanisms to adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s)?", "relative_weight": 1, "conformity_cadence": "Quarterly", "evidence_requests": [], @@ -3212,7 +4555,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically adjust data that is able to be collected, received, processed, stored, transmitted, shared, updated and/or disposed, based on updated data subject authorization(s).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3264,7 +4607,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -3291,9 +4635,6 @@ "general-nist-800-82-r3-high": [ "PM-24" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-24", "PT-03(02)" @@ -3311,39 +4652,7 @@ "PT-03(02)" ], "emea-ken-pda-2019": [ - "35(1)", - "35(2)", - "35(2)(a)", - "35(2)(b)", - "35(2)(c)", - "35(3)", - "35(3)(a)", - "35(3)(b)(i)", - "35(3)(b)(ii)", - "35(4)(a)", - "35(4)(b)", - "35(4)(c)(i)", - "35(4)(c)(ii)" - ], - "emea-srb-act-9-2018": [ - "38", - "38.1", - "38.2", - "38.3", - "39" - ], - "emea-zaf-popia-2013": [ - "5", - "71" - ], - "apac-chn-pipl-2021": [ - "24" - ], - "apac-twn-pdpa-2025": [ - "5" - ], - "americas-mex-fdpa-2010": [ - "7" + "IV.35(1)" ] } }, @@ -3365,7 +4674,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish Computer Matching Agreements (CMA) on the organization's public website(s).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3416,7 +4725,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -3444,9 +4754,6 @@ "general-nist-800-82-r3-high": [ "PM-24" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-24" ], @@ -3482,7 +4789,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to draft, publish and keep System of Records Notices (SORN) updated in accordance with regulatory guidance.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3533,7 +4840,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -3549,9 +4857,6 @@ "general-nist-800-82-r3": [ "PT-06" ], - "general-scf-dpmp-2025": [ - "11.6" - ], "usa-federal-cms-marse-2-0": [ "TR-2", "TR-2.a", @@ -3578,7 +4883,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to review all routine uses of data published in the System of Records Notices (SORN) to ensure continued accuracy and to ensure that routine uses continue to be compatible with the purpose for which the information was collected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3629,7 +4934,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -3641,9 +4947,6 @@ ], "general-nist-800-82-r3": [ "PT-06(01)" - ], - "general-scf-dpmp-2025": [ - "11.6" ] } }, @@ -3665,7 +4968,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to review all Privacy Act exemptions claimed for the System of Records Notices (SORN) to ensure they remain appropriate and accurate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3716,7 +5019,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -3728,9 +5032,6 @@ ], "general-nist-800-82-r3": [ "PT-06(02)" - ], - "general-scf-dpmp-2025": [ - "11.6" ] } }, @@ -3752,7 +5053,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide real-time and/or layered notice when Personal Data (PD) is collected that provides data subjects with a summary of key points or more detailed information that is specific to the organization's data privacy notice.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3803,7 +5104,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -3833,7 +5135,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to periodically assess disclosed purposes for which Personal Data (PD) is collected, received, processed, stored, transmitted and/or shared to ensure compatibility with reasonable consumer expectations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3884,7 +5186,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -3896,6 +5199,9 @@ "7002(c)(1)", "7002(c)(2)", "7002(c)(3)" + ], + "americas-bra-lgpd-2018": [ + "II.IV.15.I" ] } }, @@ -3917,7 +5223,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reasonably accommodate data privacy notice formatting for consumers requiring alternative formatting due to accessibility needs through:\n(1) Screen resolution / screen sizes;\n(2) Multilingual support; and/or\n(3) Disability-specific concessions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3968,7 +5274,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -3997,7 +5304,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure symmetry in choice, where options presented to consumers for more protective options are not longer, more difficult, nor more time-consuming than less protective options.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4048,7 +5355,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -4075,7 +5383,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to avoid choice architecture that impairs, interferes with or subverts a consumer’s ability to make well-informed choices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4126,7 +5434,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -4155,9 +5464,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to perform testing of choice architecture to ensure it does not undermine a consumer’s ability to submit choice selections.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to perform testing of choice architecture to ensure it does not undermine a consumer’s ability to submit choice selections. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4206,7 +5515,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -4233,9 +5543,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include within the data privacy notice a notification to data subjects of:\n(1) Their right to limit the use and disclosure of their sensitive Personal Data (sPD); and\n(2) The methods available to exercise that right.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include within the data privacy notice a notification to data subjects of:\n(1) Their right to limit the use and disclosure of their sensitive Personal Data (sPD); and\n(2) The methods available to exercise that right. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4284,7 +5594,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -4294,6 +5605,12 @@ "7014(f)", "7014(f)(1)", "7014(f)(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.14.20(4)(f)" + ], + "apac-aus-privacy-principles-2026": [ + "1.2.1" ] } }, @@ -4315,7 +5632,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with a data privacy notice through alternative means for interactions that do not utilize an interface on a website or application.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4366,7 +5683,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -4380,10 +5698,10 @@ }, { "control_id": "PRI-03", - "title": "Choice & Consent", + "title": "Data Subject Consent", "family": "PRI", - "description": "Mechanisms exist to enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", - "scf_question": "Does the organization enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations?", + "description": "Mechanisms exist to enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", + "scf_question": "Does the organization enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations?", "relative_weight": 7, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -4396,9 +5714,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to enable data subjects to authorize the collection, receiving, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where prior to collection the data subject is provided with:\n(1) Plain language to illustrate the potential data privacy risks of the authorization; \n(2) A means for users to decline the authorization; and\n(3) All necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to Mechanisms exist to enable data subjects to authorize the collection, receipt, processing, storage, transmission, sharing, updating and/or disposal of their Personal Data (PD), where the data subject is provided, prior to collection, with:\n(1) Plain language explaining the potential data privacy risks of the authorization;\n(2) A means to decline the authorization; and\n(3) Necessary choice and consent-related criteria required by applicable statutory, regulatory and contractual obligations.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4450,8 +5768,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -4512,11 +5832,6 @@ "1", "4(a)" ], - "general-scf-dpmp-2025": [ - "2.0", - "2.1", - "2.2" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.2.a", "II.2.c" @@ -4536,17 +5851,17 @@ "155.260(a)(3)(iv)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.506(b)(1)", - "164.508(a)(2)", - "164.508(c)(1)(v)", - "164.508(c)(3)", - "164.510(b)(2)(i)", - "164.510(b)(2)(ii)", - "164.510(b)(2)(iii)", - "164.510(b)(3)", - "164.514(f)(2)(ii)", - "164.514(f)(2)(iv)", - "164.514(f)(2)(v)" + "§ 164.506(b)(1)", + "§ 164.508(a)(2)", + "§ 164.508(c)(1)(v)", + "§ 164.508(c)(3)", + "§ 164.510(b)(2)(i)", + "§ 164.510(b)(2)(ii)", + "§ 164.510(b)(2)(iii)", + "§ 164.510(b)(3)", + "§ 164.514(f)(2)(ii)", + "§ 164.514(f)(2)(iv)", + "§ 164.514(f)(2)(v)" ], "usa-federal-cms-marse-2-0": [ "IP-1", @@ -4581,6 +5896,22 @@ "15(d)(3)", "15(d)(4)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.2(a)", + "603A.500.2(b)", + "603A.500.3", + "603A.500.3(a)", + "603A.500.3(b)", + "603A.500.3(c)", + "603A.500.3(d)", + "603A.535.5", + "603A.535.6", + "603A.535.6(a)", + "603A.535.6(b)", + "603A.535.6(c)", + "603A.535.6(d)", + "603A.535.7" + ], "usa-state-or-ors-646a-2025": [ "646A.578(6)", "646A.583(1)(a)(C)" @@ -4613,53 +5944,66 @@ "Article 21.5", "Article 21.6" ], - "emea-aut-fappd-2000": [ - "Sec 8" - ], - "emea-bel-act-8-1992": [ - "45754" + "emea-aut-dpa-2018": [ + "§ 8(1)", + "§ 12(1)", + "§ 12(2)", + "§ 12(3)", + "§ 12(4)" ], "emea-deu-fdpa-2017": [ - "Sec 4a", - "Sec 11" + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.27(4)", + "3.2.51(1)", + "3.2.51(2)", + "3.2.51(5)" ], "emea-grc-pirppd-1997": [ - "5" - ], - "emea-hun-isdfi-2011": [ - "6" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "23", - "24" + "B.5.1", + "B.7.2.a" + ], + "emea-hun-act-cxii-2011": [ + "II.5.5(1)(a)", + "II.5.5(2)(a)", + "II.5.6(3)", + "II.5.6(4)", + "II.7.8(1)(a)", + "II.8.9(4)", + "II.11.12(3)(a)", + "II.15.21(1)(a)", + "II.15.21(1)(b)", + "II.15.21(1)(c)" + ], + "emea-isr-ppl-5741-2025": [ + "s.1" ], "emea-ken-pda-2019": [ - "32(1)", - "32(4)" + "IV.26(c)", + "IV.28(2)(c)", + "IV.32(4)" ], "emea-nga-dpr-2019": [ - "2.2(a)", "2.3(2)", "2.3(2)(a)", "2.3(2)(b)", "2.3(2)(c)", "2.3(2)(d)", - "2.3(2)(e)" - ], - "emea-pol-act-29-1997": [ - "23" + "2.3(2)(e)", + "2.8(b)", + "2.12(a)", + "3.1(14)(a)", + "3.1(14)(b)", + "3.1(14)(c)" ], "emea-qat-pdppl-2020": [ - "4", - "5.2", - "10" + "2.4", + "2.5.2" ], - "emea-rus-federal-law-27-2006": [ - "6", - "9" + "emea-rus-152-fz-2025": [ + "Art. 6", + "Art. 9", + "Art. 10.1" ], "emea-sau-pdpl-2023": [ "Article 5.1", @@ -4672,41 +6016,55 @@ "Article 26" ], "emea-srb-act-9-2018": [ - "12.1", - "15", - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "II.15", + "III.3.31" ], "emea-zaf-popia-2013": [ - "11" - ], - "emea-esp-decree-1720-2007": [ - "8", - "12" - ], - "emea-tur-lppd-2016": [ - "10" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "6.57(1)", + "6.57(1)(a)", + "6.57(1)(a)(i)", + "6.57(1)(a)(ii)", + "6.57(1)(b)", + "6.57(1)(c)", + "6.57(1)(d)", + "6.57(2)", + "6.57(3)", + "6.57(4)" ], - "apac-aus-privacy-principles-2026": [ - "APP 3" + "emea-che-fadp-2025": [ + "2.1.6.6", + "2.1.6.7", + "2.1.6.7.a", + "2.1.6.7.b", + "2.1.6.7.c" ], "apac-chn-cybersecurity-law-2017": [ "Article 22" ], "apac-chn-pipl-2021": [ - "13(1)", - "14", - "23", - "27", - "29", - "30", - "44" + "Article 14" + ], + "apac-hkg-pdo-2022": [ + "35E(1)", + "35E(1)(a)", + "35E(1)(b)", + "35E(1)(b)(i)", + "35E(1)(b)(ii)", + "35E(1)(b)(iii)", + "35E(1)(c)", + "35E(2)", + "35E(2)(a)", + "35E(2)(b)", + "35E(3)", + "35E(4)", + "Schedule 1 - 1(3)(a)(i)", + "Schedule 1 - 1(3)(a)(ii)", + "Schedule 1 - 1(3)(b)", + "Schedule 1 - 1(3)(b)(i)", + "Schedule 1 - 1(3)(b)(i)(A)", + "Schedule 1 - 1(3)(b)(i)(B)", + "Schedule 1 - 1(3)(b)(ii)", + "Schedule 1 - 1(3)(b)(ii)(A)" ], "apac-ind-dpdpa-2023": [ "4(1)(a)", @@ -4719,56 +6077,107 @@ "8(8)(b)" ], "apac-ind-privacy-rules-2011": [ - "5" + "5(1)", + "5(7)" ], - "apac-jpn-ppi-2020": [ - "16(1)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)", - "24(1)", - "24(2)" + "apac-jpn-appi-2020": [ + "IV.1.26-2(1)(i)", + "IV.1.26-2(1)(ii)" ], "apac-mys-pdpa-2010": [ - "7" + "7(3)" ], "apac-phl-dpa-2012": [ - "19" + "III.12(a)" ], "apac-sgp-pdpa-2012": [ - "13" + "4.1.13", + "4.1.14(1)(b)", + "4.1.14(3)", + "4.1.14(4)", + "4.1.15(1)", + "4.1.15(1)(a)", + "4.1.15(1)(b)", + "4.1.15(2)", + "4.1.15(3)", + "4.1.15(6)", + "4.1.15(6)(a)(i)", + "4.1.15(6)(a)(ii)", + "4.1.15(6)(b)", + "4.1.15(6)(c)", + "4.1.15(7)", + "4.1.15(9)(a)", + "4.1.15(9)(b)", + "9.3.46(1)" ], "apac-kor-pipa-2011": [ - "3", - "4", - "22" + "III.1.15(2)", + "III.1.15(2)1", + "III.1.15(2)2", + "III.1.15(2)3", + "III.1.15(2)4", + "III.1.17(1)", + "III.1.17(1)1", + "III.1.17(1)2", + "III.1.17(2)", + "III.1.17(2)1", + "III.1.17(2)2", + "III.1.17(2)3", + "III.1.17(2)4", + "III.1.17(2)5", + "III.1.17(3)", + "III.1.22(3)" ], "apac-twn-pdpa-2025": [ - "5" + "I.7" ], - "americas-arg-ppd-2018": [ - "5.1", - "5.2" + "americas-bhs-dpa-2003": [ + "II.7(1)", + "IV.32(1)", + "IV.32(2)", + "IV.32(2)(a)", + "IV.32(2)(b)", + "IV.32(2)(c)", + "IV.32(3)", + "IV.32(4)", + "IV.32(5)", + "IV.32(6)", + "IV.36(2)" ], "americas-bra-lgpd-2018": [ - "7.1", - "15" + "II.I.7.I", + "II.I.8", + "II.I.8.1", + "II.I.8.2", + "II.I.8.3", + "II.I.8.4" ], "americas-can-pipeda-2000": [ - "Sec 6", - "Sec 7", - "Principle 3" + "P2-4.2.5", + "P3-4.3", + "P3-4.3.1", + "P3-4.3.2", + "P3-4.3.3", + "P3-4.3.4", + "P3-4.3.5", + "P3-4.3.6", + "P3-4.3.7", + "P3-4.3.7(a)", + "P3-4.3.7(b)", + "P3-4.3.7(c)", + "P3-4.3.7(d)" ], "americas-chl-act-19628-1999": [ - "4" + "I.4", + "I.8" ], "americas-col-law-1581-2012": [ - "4" + "II.4(c)", + "VI.17(b)" ], "americas-mex-fdpa-2010": [ - "8", - "10" + "II.8", + "II.9" ] } }, @@ -4790,7 +6199,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to modify permission to collect, receive, process, store, transmit, share, update and/or dispose selected attributes of their Personal Data (PD).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4843,7 +6252,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -4862,27 +6272,23 @@ "general-nist-800-82-r3": [ "PT-04(01)" ], - "general-scf-dpmp-2025": [ - "2.5" - ], "usa-state-tn-tipa-2025": [ "47-18-3203(a)(2)(E)(i)", "47-18-3203(a)(2)(E)(ii)", "47-18-3203(a)(2)(E)(iii)", "47-18-3203(b)" ], - "emea-srb-act-9-2018": [ - "31", - "31.1", - "31.2", - "31.3", - "31.4" + "apac-chn-pipl-2021": [ + "Article 29" ], - "emea-zaf-popia-2013": [ - "11" + "apac-jpn-appi-2020": [ + "IV.1.30(5)" ], - "apac-twn-pdpa-2025": [ - "5" + "apac-kor-pipa-2011": [ + "III.1.22(2)" + ], + "americas-bra-lgpd-2018": [ + "II.I.9.VII.3" ] } }, @@ -4904,7 +6310,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to present data subjects with a new or updated consent request to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD) in conjunction with the data action, when:\n(1) The original circumstances under which an individual gave consent have changed; or\n(2) A significant amount of time has passed since an individual gave consent.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4957,7 +6363,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -4984,10 +6391,6 @@ "PT-04(02)", "PT-05(01)" ], - "general-scf-dpmp-2025": [ - "2.3", - "5.14" - ], "usa-federal-doc-data-privacy-framework-2023": [ "III.14.b.i", "III.14.b.ii" @@ -5003,48 +6406,28 @@ "7221(i)", "7221(k)" ], - "emea-aut-fappd-2000": [ - "Sec 8" - ], - "emea-ken-pda-2019": [ - "32(2)", - "32(3)" - ], - "emea-zaf-popia-2013": [ - "15" - ], - "apac-aus-privacy-principles-2026": [ - "APP 5" - ], - "apac-chn-pipl-2021": [ - "14", - "22", - "23", - "27" - ], - "apac-jpn-ppi-2020": [ - "16(2)", - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" + "apac-jpn-appi-2020": [ + "IV.1.16(2)" ], "apac-kor-pipa-2011": [ - "22" - ], - "apac-twn-pdpa-2025": [ - "5" + "III.1.20(1)", + "III.1.20(1)1", + "III.1.20(1)2", + "III.1.20(1)3", + "III.1.22(1)" ], - "americas-arg-ppd-2018": [ - "27.3" + "americas-bra-lgpd-2018": [ + "II.I.8.6", + "II.I.9.VII.2" ], "americas-can-pipeda-2000": [ - "Sec 6", - "Sec 7", - "Principle 3" + "P2-4.2.4" + ], + "americas-col-law-1581-2012": [ + "VI.17(m)" ], "americas-mex-fdpa-2010": [ - "7" + "II.16.VI" ] } }, @@ -5066,7 +6449,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Asset / process owners collect, store, processes, transmit share or use PD only for the purposes identified in the data privacy notice.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to prevent the sale, processing and/or sharing of Personal Data (PD) when:\n(1) Instructed by the data subject; or\n(2) The data subject is a minor, where selling and/or sharing PD is legally prohibited.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5119,15 +6502,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.5" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(5)(ii)(A)" + "§ 164.502(a)(5)(ii)(A)" ], "usa-state-co-privacy-act-2021": [ "6-1-1308(1)(b)" @@ -5149,14 +6530,54 @@ "59.1-578.F.1", "59.1-578.F.1.a" ], - "emea-srb-act-9-2018": [ - "37" + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 7" ], - "apac-aus-privacy-principles-2026": [ - "APP 7" + "emea-grc-pirppd-1997": [ + "B.7.1", + "B.9.1", + "B.9.1.a" ], - "apac-chn-pipl-2021": [ - "10" + "emea-hun-act-cxii-2011": [ + "II.5.6(3)" + ], + "emea-ita-pdpc-2018": [ + "Article 2-d(1)" + ], + "emea-ken-pda-2019": [ + "IV.36" + ], + "emea-qat-pdppl-2020": [ + "3.12" + ], + "emea-srb-act-9-2018": [ + "II.16" + ], + "emea-zaf-popia-2013": [ + "3.C.34", + "3.C.35(1)", + "3.C.35(1)(a)", + "3.C.35(1)(b)", + "3.C.35(1)(c)", + "3.C.35(1)(d)", + "3.C.35(1)(d)(i)", + "3.C.35(1)(d)(ii)", + "3.C.35(1)(d)(iii)", + "3.C.35(1)(e)", + "3.C.35(2)", + "3.C.35(3)", + "3.C.35(3)(a)", + "3.C.35(3)(a)(i)", + "3.C.35(3)(a)(ii)", + "3.C.35(3)(b)", + "3.C.35(3)(b)(i)", + "3.C.35(3)(b)(ii)", + "3.C.35(3)(b)(iii)", + "3.C.35(3)(c)", + "3.C.35(3)(d)" + ], + "apac-jpn-appi-2020": [ + "IV.1.23(1)" ] } }, @@ -5178,7 +6599,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to revoke consent to collect, receive, process, store, transmit, share and/or update their Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5231,7 +6652,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -5247,12 +6669,14 @@ "general-nist-800-82-r3": [ "PT-04(03)" ], - "general-scf-dpmp-2025": [ - "2.3" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)(ii)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.500.3(d)", + "603A.505.1(c)", + "603A.535.4" + ], "usa-state-or-ors-646a-2025": [ "646A.576(7)", "646A.578(1)(d)" @@ -5263,28 +6687,53 @@ "emea-eu-gdpr-2016": [ "Article 7.3" ], + "emea-deu-fdpa-2017": [ + "3.2.51(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.15.21(1)(a)", + "II.15.21(1)(b)" + ], "emea-ken-pda-2019": [ - "26(c)", - "32(2)", - "32(3)" + "IV.26(c)", + "IV.32(2)", + "IV.32(3)" ], "emea-nga-dpr-2019": [ - "2.8", "2.8(a)", - "2.8(b)" + "3.1(9)(b)" ], "emea-qat-pdppl-2020": [ - "5.1" + "2.5.1" ], "emea-sau-pdpl-2023": [ "Article 5.2" ], "emea-srb-act-9-2018": [ - "15", - "37" + "III.3.30-1(2)", + "III.4.37" + ], + "emea-zaf-popia-2013": [ + "3.A.2.11(2)(b)", + "3.A.2.11(3)", + "3.A.2.11(3)(a)", + "3.A.2.11(3)(b)", + "3.A.2.11(4)" + ], + "emea-gbr-dpa-2018": [ + "Section 47(4)" ], "apac-chn-pipl-2021": [ - "15" + "Article 15" + ], + "apac-hkg-pdo-2022": [ + "35G(1)", + "35L(1)", + "35L(1)(a)", + "35L(1)(b)", + "35L(2)", + "35L(3)", + "35L(4)" ], "apac-ind-dpdpa-2023": [ "5(2)(b)", @@ -5292,6 +6741,34 @@ "6(7)", "8(7)(a)", "8(8)(b)" + ], + "apac-jpn-appi-2020": [ + "IV.1.30(1)" + ], + "apac-mys-pdpa-2010": [ + "38(1)", + "43(1)" + ], + "apac-sgp-pdpa-2012": [ + "4.1.16(1)", + "9.3.47(1)" + ], + "apac-kor-pipa-2011": [ + "V.37(1)" + ], + "americas-bra-lgpd-2018": [ + "II.I.8.5", + "II.IV.15.III" + ], + "americas-can-pipeda-2000": [ + "P3-4.3.8" + ], + "americas-col-law-1581-2012": [ + "IV.8(e)" + ], + "americas-mex-fdpa-2010": [ + "II.8", + "III.25" ] } }, @@ -5313,7 +6790,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to prevent discrimination against a data subject for exercising their legal rights pertaining to modifying or revoking consent, including prohibiting:\n(1) Refusing products and/or services;\n(2) Charging different rates for goods and/or services; and\n(3) Providing different levels of quality.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5363,7 +6840,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -5371,13 +6849,10 @@ "C3.1-POF2", "C3.1-POF3" ], - "general-scf-dpmp-2025": [ - "2.4" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.508(c)(2)(ii)(A)", - "164.508(c)(2)(ii)(B)", - "164.514(f)(2)(iii)" + "§ 164.508(c)(2)(ii)(A)", + "§ 164.508(c)(2)(ii)(B)", + "§ 164.514(f)(2)(iii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7080(a)", @@ -5388,6 +6863,9 @@ "6-1-1308(1)(c)(I)", "6-1-1308(1)(c)(II)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.535.2" + ], "usa-state-or-cpa-2023": [ "Section 5(2)(d)" ], @@ -5399,14 +6877,21 @@ "59.1-577.1.E", "59.1-578.A.4" ], + "emea-deu-fdpa-2017": [ + "3.3.59(3)" + ], "emea-ken-pda-2019": [ - "32(4)" + "IV.32(4)" ], "emea-sau-pdpl-2023": [ "Article 7" ], "apac-chn-pipl-2021": [ - "16" + "Article 16" + ], + "apac-kor-pipa-2011": [ + "III.1.16(2)", + "III.1.22(4)" ] } }, @@ -5428,7 +6913,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to allow data subjects to authorize another person or entity (e.g., authorized agent, proxy, etc.), acting on the data subject's behalf, to make Personal Data (PD) processing decisions.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5458,14 +6943,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.6" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)", "Sec. 6502.(b)(1)(B)(ii)" @@ -5474,10 +6956,10 @@ "II.2.b" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(g)(1)", - "164.502(g)(2)", - "164.502(g)(3)(i)", - "164.502(g)(3)(i)(A)" + "§ 164.502(g)(1)", + "§ 164.502(g)(2)", + "§ 164.502(g)(3)(i)", + "§ 164.502(g)(3)(i)(A)" ], "usa-state-ca-ccpa-cpra-2026": [ "7026(j)", @@ -5520,28 +7002,32 @@ "Article 8.1", "Article 8.2" ], + "emea-hun-act-cxii-2011": [ + "II.5.6(2)" + ], + "emea-ita-pdpc-2018": [ + "Article 82(2)(a)" + ], "emea-ken-pda-2019": [ - "27(a)", - "27(b)", - "27(c)" + "IV.27(a)", + "IV.27(b)", + "IV.27(c)", + "IV.28(2)(d)" ], - "emea-qat-pdppl-2020": [ - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" + "apac-chn-pipl-2021": [ + "Article 49" ], "apac-ind-dpdpa-2023": [ "6(7)", "9(1)", "14(1)" ], - "apac-jpn-ppi-2020": [ - "16(3)(i)", - "16(3)(ii)", - "16(3)(iii)", - "16(3)(iv)" + "apac-phl-dpa-2012": [ + "IV.17" + ], + "apac-kor-pipa-2011": [ + "V.38(1)", + "V.38(2)" ] } }, @@ -5563,7 +7049,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to compel data subjects to select the level of consent deemed appropriate by the data subject for the relevant business purpose (e.g., opt-in, opt-out, accept all cookies, etc.).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5614,7 +7100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -5624,9 +7111,6 @@ "general-oecd-privacy-principles-2010": [ "1" ], - "general-scf-dpmp-2025": [ - "6.0" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.2.c", "III.12.a", @@ -5658,9 +7142,14 @@ "59.1-577.A", "59.1-577.A.5" ], + "emea-hun-act-cxii-2011": [ + "II.14.20(1)" + ], "emea-ken-pda-2019": [ - "26(a)", - "26(c)" + "IV.28(1)" + ], + "emea-zaf-popia-2013": [ + "3.A.2.12(1)" ] } }, @@ -5682,7 +7171,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically provide data subjects with functionality to exercise pre-selected opt-out preferences (e.g., opt-out signal).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5733,13 +7222,11 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "2.7" - ], "usa-state-ca-ccpa-cpra-2026": [ "7025(a)", "7025(b)", @@ -5797,7 +7284,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to govern the continued use of Personal Data (PD) as it is collected, received, processed, stored, transmitted, shared and/or updated until:\n(1) Disposal of PD occurs when there is no longer a legitimate business purpose;\n(2) Disposal of PD occurs when the data retention timeline for the use case is met; and/or\n(3) Continued use of PD is prohibited upon withdrawal of data subject consent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5835,7 +7322,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -5867,10 +7355,37 @@ "emea-eu-gdpr-2016": [ "Article 18.2" ], + "emea-ita-pdpc-2018": [ + "Article 99(1)" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 2(1)(b)(i)", + "Schedule 1 - 2(1)(b)(ii)" + ], "apac-ind-dpdpa-2023": [ "5(2)(b)", "9(2)", "9(3)" + ], + "apac-jpn-appi-2020": [ + "IV.1.30(2)", + "IV.1.30(4)", + "IV.1.30(6)", + "IV.1.30(7)", + "IV.1.31" + ], + "apac-sgp-pdpa-2012": [ + "4.2.19(a)", + "9.3.47(3)" + ], + "americas-bhs-dpa-2003": [ + "IV.35(1)", + "IV.35(1)(a)", + "IV.35(1)(b)", + "IV.36(1)" + ], + "americas-chl-act-19628-1999": [ + "I.9" ] } }, @@ -5879,7 +7394,7 @@ "title": "Cease Processing, Storing and/or Sharing Personal Data (PD)", "family": "PRI", "description": "Mechanisms exist to ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation.", - "scf_question": "Does the organization ensure it ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation?", + "scf_question": "Does the organization ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -5892,7 +7407,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Asset / process owners collect, store, processes, transmit share or use PD only for the purposes identified in the data privacy notice.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the organization ceases collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) upon receiving a data subject's consent revocation.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5930,7 +7445,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -5946,6 +7462,18 @@ ], "apac-ind-dpdpa-2023": [ "6(6)" + ], + "apac-mys-pdpa-2010": [ + "38(2)", + "42(1)", + "42(1)(a)" + ], + "apac-sgp-pdpa-2012": [ + "4.1.16(4)" + ], + "americas-bra-lgpd-2018": [ + "II.IV.15.II", + "II.IV.15.IV" ] } }, @@ -5967,7 +7495,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of processing changes affecting their Personal Data (PD), including:\n(1) Erasure of PD;\n(2) Remediation of incorrect PD; and/or\n(3) Processing restrictions affecting their PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6003,13 +7531,25 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "emea-eu-gdpr-2016": [ "Article 18.3", "Article 19" + ], + "emea-deu-fdpa-2017": [ + "3.4.75(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.18(1)" + ], + "apac-jpn-appi-2020": [ + "IV.1.23(3)", + "IV.1.23(6)", + "IV.1.30(3)" ] } }, @@ -6031,7 +7571,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to obtain consent from data subjects to opt-in for the following Personal Data (PD) actions:\n(1) Collecting;\n(2) Receiving; \n(3) Processing;\n(4) Storing;\n(5) Transmitting:\n(6) Sharing; and/or\n(7) Updating.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6067,7 +7607,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -6083,6 +7624,9 @@ "usa-state-va-cdpa-2023": [ "59.1-578.F.1", "59.1-578.F.1.b" + ], + "apac-sgp-pdpa-2012": [ + "9.3.46(2)" ] } }, @@ -6104,7 +7648,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to obtain parental or guardian consent for Personal Data (PD) processing actions through reasonable consumer expectations, when the data subject is a minor.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6140,7 +7684,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -6165,15 +7710,51 @@ "usa-state-va-cdpa-2023": [ "59.1-578.F.1", "59.1-578.F.1.b" + ], + "emea-ken-pda-2019": [ + "IV.27(a)", + "IV.28(2)(d)", + "IV.33(2)", + "IV.33(4)" + ], + "emea-qat-pdppl-2020": [ + "4.17.2" + ], + "apac-chn-pipl-2021": [ + "Article 31" + ], + "apac-kor-pipa-2011": [ + "III.1.22(5)" + ], + "americas-bhs-dpa-2003": [ + "IV.33(1)", + "IV.33(2)", + "IV.33(3)", + "IV.33(4)", + "IV.33(4)(a)", + "IV.33(4)(b)", + "IV.33(4)(c)" + ], + "americas-bra-lgpd-2018": [ + "II.III.14", + "II.III.14.1", + "II.III.14.2", + "II.III.14.3", + "II.III.14.4", + "II.III.14.5", + "II.III.14.6" + ], + "americas-col-law-1581-2012": [ + "III.7" ] } }, { "control_id": "PRI-04", - "title": "Restrict Collection To Identified Purpose", + "title": "Restrict Collection, Processing & Sharing To Identified Purpose", "family": "PRI", - "description": "Mechanisms exist to minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", - "scf_question": "Does the organization minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent?", + "description": "Mechanisms exist to minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", + "scf_question": "Does the organization minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -6188,9 +7769,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to minimize the collection of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to minimize the collection, processing and/or sharing of Personal Data (PD) to only what is adequate, relevant and limited to the purposes identified in the data privacy notice, including protections against collecting PD from minors without appropriate parental or legal guardian consent.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6242,8 +7823,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -6287,9 +7870,6 @@ "general-nist-800-82-r3": [ "PT-02" ], - "general-scf-dpmp-2025": [ - "3.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(a)(1)" ], @@ -6320,6 +7900,15 @@ "usa-state-il-ipa-2009": [ "10(b)(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.495.3(a)", + "603A.495.3(c)", + "603A.500.1(a)", + "603A.500.1(b)", + "603A.535.1", + "603A.535.1(a)", + "603A.535.1(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.578(1)(b)" ], @@ -6337,182 +7926,74 @@ ], "usa-state-va-cdpa-2023": [ "59.1-578.A.1", - "59.1-578.F.1", - "59.1-578.F.1.c", - "59.1-578.F.2" - ], - "usa-state-vt-act-171-2018": [ - "2433(a)(1)" - ], - "emea-eu-gdpr-2016": [ - "Article 5.1(b)", - "Article 5.1(c)", - "Article 8.1" - ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" - ], - "emea-deu-fdpa-2017": [ - "Sec 4" - ], - "emea-grc-pirppd-1997": [ - "4" - ], - "emea-hun-isdfi-2011": [ - "4", - "5" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "11" - ], - "emea-ken-pda-2019": [ - "25(c)", - "25(d)", - "27(a)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)" - ], - "emea-pol-act-29-1997": [ - "23" - ], - "emea-qat-pdppl-2020": [ - "9.1", - "10", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5" - ], - "emea-rus-federal-law-27-2006": [ - "5" - ], - "emea-srb-act-9-2018": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "16" - ], - "emea-zaf-popia-2013": [ - "5", - "11", - "69" + "59.1-578.F.1", + "59.1-578.F.1.c", + "59.1-578.F.2" ], - "emea-esp-decree-1720-2007": [ - "8" + "usa-state-vt-act-171-2018": [ + "2433(a)(1)" ], - "emea-che-fadp-2025": [ - "4" + "emea-eu-gdpr-2016": [ + "Article 5.1(b)", + "Article 5.1(c)", + "Article 8.1" ], - "emea-tur-lppd-2016": [ - "10" + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 29(1)", + "Title 2, Chapter II, Art. 29(2)" ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "emea-deu-fdpa-2017": [ + "3.1.47.2", + "3.1.47.3", + "3.1.47.6" ], - "apac-aus-privacy-principles-2026": [ - "APP 3" + "emea-grc-pirppd-1997": [ + "B.4.1.a", + "B.4.1.b" ], - "apac-chn-pipl-2021": [ - "26", - "31" + "emea-hun-act-cxii-2011": [ + "II.4.4(1)", + "II.4.4(2)", + "II.11.12(1)", + "II.12.13(2)" ], - "apac-ind-privacy-rules-2011": [ - "5" + "emea-ken-pda-2019": [ + "IV.25(c)", + "IV.27(a)" ], - "apac-jpn-ppi-2020": [ - "17(1)" + "emea-qat-pdppl-2020": [ + "3.12" ], - "apac-nzl-privacy-act-2020": [ - "Principle 1", - "P1-(1)(a)", - "P1-(1)(b)", - "Principle 3", - "P3-(1)", - "P3-(1)(a)", - "P3-(1)(b)", - "P3-(1)(c)", - "P3-(1)(d)", - "P3-(1)(d)(i)", - "P3-(1)(d)(ii)", - "P3-(1)(e)", - "P3-(1)(e)(i)", - "P3-(1)(e)(ii)", - "P3-(1)(f)", - "P3-(1)(g)", - "P3-(2)", - "P3-(3)", - "P3-(4)", - "P3-(4)(a)", - "P3-(4)(b)", - "P3-(4)(b)(i)", - "P3-(4)(b)(ii)", - "P3-(4)(b)(iii)", - "P3-(4)(b)(iv)", - "P3-(4)(c)", - "P3-(4)(d)", - "P3-(4)(e)", - "P3-(4)(e)(i)", - "P3-(4)(e)(ii)", - "Principle 4", - "P4-(a)", - "P4-(b)", - "P4-(b)(i)", - "P4-(b)(ii)" + "emea-che-fadp-2025": [ + "2.1.6.3" ], - "apac-phl-dpa-2012": [ - "19" + "apac-ind-privacy-rules-2011": [ + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(5)" ], - "apac-sgp-pdpa-2012": [ - "17" + "apac-jpn-appi-2020": [ + "IV.1.15(2)" ], "apac-kor-pipa-2011": [ - "3", - "15", - "22" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "4.1", - "4.2", - "6" + "III.1.15(1)", + "III.1.15(1)1", + "III.1.15(1)2", + "III.1.15(1)3", + "III.1.15(1)4", + "III.1.15(1)5", + "III.1.15(1)6" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.2" + "II.5(1)(c)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 4" - ], - "americas-col-law-1581-2012": [ - "4" + "P4-4.4" ], "americas-mex-fdpa-2010": [ - "7" + "II.7", + "II.12" ] } }, @@ -6536,7 +8017,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to determine and document the legal authority that permits the organization to collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD), either generally or in support of a specific business process.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6589,7 +8070,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -6626,9 +8108,6 @@ "1", "4(b)" ], - "general-scf-dpmp-2025": [ - "3.1" - ], "general-shared-assessments-sig-2025": [ "P.6" ], @@ -6651,11 +8130,11 @@ "3" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(1)(i)", - "164.502(a)(1)(ii)", - "164.502(a)(1)(iii)", - "164.502(a)(5)(i)", - "164.502(i)" + "§ 164.502(a)(1)(i)", + "§ 164.502(a)(1)(ii)", + "§ 164.502(a)(1)(iii)", + "§ 164.502(a)(5)(i)", + "§ 164.502(i)" ], "usa-federal-irs-1075-2021": [ "PT-2" @@ -6707,198 +8186,106 @@ "Article 9.3", "Article 10" ], - "emea-aut-fappd-2000": [ - "Sec 6" - ], - "emea-bel-act-8-1992": [ - "45754" + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(4)", + "Title 2, Chapter II, Art. 33(1)", + "Title 2, Chapter II, Art. 33(2)" ], "emea-deu-fdpa-2017": [ - "Sec 4" + "2.1.2.26(1)", + "2.1.2.26(2)", + "2.1.2.26(3)", + "2.1.2.26(4)", + "3.2.49", + "3.2.50" ], "emea-grc-pirppd-1997": [ - "4" - ], - "emea-hun-isdfi-2011": [ - "4", - "5" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "11" + "B.4.1.a", + "B.4.1.b", + "B.5.2", + "B.5.2.a", + "B.5.2.b", + "B.5.2.c", + "B.5.2.d", + "B.5.2.e", + "B.8.3" + ], + "emea-hun-act-cxii-2011": [ + "II.4.4(1)", + "II.4.4(2)", + "II.4.4(3)", + "II.4.4(5)", + "II.5.5(1)(b)", + "II.5.5(2)(b)", + "II.5.5(2)(c)", + "II.5.5(3)", + "II.5.5(4)", + "II.5.6(1)(b)", + "II.5.6(5)(a)", + "II.10.11(1)(b)", + "II.11.12(1)" ], "emea-ken-pda-2019": [ - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)" + "IV.25(a)", + "IV.28(3)" ], "emea-nga-dpr-2019": [ - "2.1(1)(a)", - "2.1(1)(a)(i)", - "2.1(1)(a)(ii)", - "2.2(a)", - "2.2(b)", - "2.2(c)", - "2.2(d)", - "2.2(e)", - "2.4(a)" + "2.3(1)" ], - "emea-pol-act-29-1997": [ - "23" + "emea-nor-pda-2018": [ + "8" ], "emea-qat-pdppl-2020": [ - "9.2", - "18.1", - "18.2", - "18.3", - "18.4" - ], - "emea-rus-federal-law-27-2006": [ - "5" + "2.4", + "3.11.1" ], "emea-sau-pdpl-2023": [ "Article 13.1" ], "emea-srb-act-9-2018": [ - "5.1", - "5.2", - "6.1", - "6.2", - "6.3", - "6.4", - "6.5", - "7", - "7.1", - "7.2", - "14", - "20" + "II.14" ], "emea-zaf-popia-2013": [ - "2", - "3", - "4" - ], - "emea-esp-decree-1720-2007": [ - "8" - ], - "emea-che-fadp-2025": [ - "4" - ], - "emea-tur-lppd-2016": [ - "10" + "3.A.2.11(1)", + "3.A.2.11(1)(a)", + "3.A.2.11(1)(b)", + "3.A.2.11(1)(c)", + "3.A.2.11(1)(d)", + "3.A.2.11(1)(e)", + "3.A.2.11(1)(f)" ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "emea-gbr-dpa-2018": [ + "Section 44(2)(a)" ], "apac-aus-privacy-principles-2026": [ - "APP 3", - "APP 7" - ], - "apac-chn-pipl-2021": [ - "5", - "10", - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "26", - "29", - "30", - "47" + "2.3.1", + "2.3.2" ], "apac-ind-dpdpa-2023": [ "4(1)(b)" ], - "apac-ind-privacy-rules-2011": [ - "5" - ], - "apac-jpn-ppi-2020": [ - "17(1)", - "17(2)", - "17(2)(i)", - "17(2)(ii)", - "17(2)(iii)", - "17(2)(iv)", - "17(2)(v)", - "17(2)(vi)" - ], - "apac-phl-dpa-2012": [ - "19" - ], "apac-sgp-pdpa-2012": [ - "17" - ], - "apac-kor-pipa-2011": [ - "3", - "15" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "5.2", - "7.1", - "7.2", - "7.4", - "8" + "4.1.17(1)(a)" ], "americas-bhs-dpa-2003": [ - "6" - ], - "americas-bra-lgpd-2018": [ - "6.1", - "10", - "11" + "IV.35(2)", + "IV.35(2)(a)", + "IV.35(2)(b)", + "IV.36(3)", + "IV.36(3)(a)", + "IV.36(3)(b)", + "IV.36(3)(c)", + "IV.36(3)(c)(i)", + "IV.36(3)(c)(ii)" ], "americas-can-pipeda-2000": [ - "Sec 5", - "Principle 4" + "P4-4.4" ], - "americas-col-law-1581-2012": [ - "4" + "americas-chl-act-19628-1999": [ + "I.4" ], "americas-mex-fdpa-2010": [ - "7" + "II.7" ] } }, @@ -6920,7 +8307,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure information is directly collected from the data subject, whenever possible.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6966,7 +8353,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -6977,39 +8365,19 @@ "P.5.3" ], "emea-ken-pda-2019": [ - "28(1)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)" + "IV.28(1)" ], "emea-sau-pdpl-2023": [ "Article 10" ], - "apac-chn-pipl-2021": [ - "10" + "apac-aus-privacy-principles-2026": [ + "2.3.6", + "2.3.6.a", + "2.3.6.a.ii", + "2.3.6.b" ], "apac-nzl-privacy-act-2020": [ - "Principle 2", - "P2-(1)", - "P2-(2)", - "P2-(2)(a)", - "P2-(2)(b)", - "P2-(2)(c)", - "P2-(2)(d)", - "P2-(2)(e)(i)", - "P2-(2)(e)(ii)", - "P2-(2)(e)(iii)", - "P2-(2)(e)(iv)", - "P2-(2)(e)(v)", - "P2-(2)(f)", - "P2-(2)(g)(i)", - "P2-(2)(g)(ii)" + "3.1.22.2(1)" ] } }, @@ -7031,7 +8399,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting and/or sharing of photographic and/or video surveillance image collection that can identify individuals to legitimate business needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7079,14 +8447,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": { - "apac-chn-pipl-2021": [ - "26" - ] - } + "crosswalks": {} }, { "control_id": "PRI-04.4", @@ -7106,7 +8471,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to promptly inform data subjects of the utilization purpose when their Personal Data (PD) is acquired and not received directly from the data subject, except where that utilization purpose was disclosed in advance to the data subject.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7136,7 +8501,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -7144,17 +8510,6 @@ "Article 10", "Article 14", "Article 15.2" - ], - "emea-srb-act-9-2018": [ - "20" - ], - "apac-jpn-ppi-2020": [ - "18(1)", - "18(2)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)" ] } }, @@ -7176,7 +8531,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, validate Personal Data (PD) during the collection process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7227,7 +8582,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -7263,7 +8619,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure that the data subject, or authorized representative, re-validate that Personal Data (PD) acquired during the collection process is still accurate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7314,7 +8670,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -7380,7 +8737,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -7390,6 +8748,9 @@ "general-iso-29100-2024": [ "6.7" ], + "emea-deu-fdpa-2017": [ + "3.3.56(2)" + ], "emea-sau-pdpl-2023": [ "Article 11.2" ] @@ -7400,7 +8761,7 @@ "title": "Personal Data (PD) Retention & Disposal", "family": "PRI", "description": "Mechanisms exist to: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records).", - "scf_question": "Does the organization: \n (1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n (2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n (3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records)?", + "scf_question": "Does the organization: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -7416,11 +8777,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to: \n(1) Retain Personal Data (PD), including metadata, for an organization-defined time period to fulfill the purpose(s) identified in the notice or as required by law;\n(2) Dispose of, destroys, erases, and/or anonymizes the PD, regardless of the method of storage; and\n(3) Use organization-defined techniques or methods to ensure secure deletion or destruction of PD (including originals, copies and archived records).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE AI Model Deployment", @@ -7503,7 +8864,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -7653,9 +9015,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "9.4.6" ], - "general-scf-dpmp-2025": [ - "5.0" - ], "usa-federal-fbi-cjis-6-0": [ "4.2.2", "4.2.3.1", @@ -7731,73 +9090,52 @@ "emea-eu-gdpr-2016": [ "Article 5.1(e)" ], - "emea-us-psd2-2015": [ - "24" - ], - "emea-aut-fappd-2000": [ - "Sec 7" + "emea-aut-dpa-2018": [ + "§ 13(3)", + "§ 37(2)" ], - "emea-bel-act-8-1992": [ - "4-7", - "21" + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 30" ], "emea-deu-fdpa-2017": [ - "Sec 3a", - "Sec 5", - "Sec 13", - "Sec 14", - "Sec 20" - ], - "emea-deu-c5-2020": [ - "OPS-11", - "OPS-12", - "PI-03" + "3.1.47.5", + "3.2.48(2)2", + "3.3.58(2)", + "3.4.62(5)4", + "3.4.75(2)", + "3.4.75(4)" ], "emea-grc-pirppd-1997": [ - "4", - "7" - ], - "emea-hun-isdfi-2011": [ - "5" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "15.4" - ], - "emea-isr-ppl-5741-1981": [ - "8" - ], - "emea-ita-pdpc-2003": [ - "11" + "B.4.1.d", + "B.4.2" + ], + "emea-hun-act-cxii-2011": [ + "II.8.9(1)(b)", + "II.13.15(3)", + "II.13.17(2)(a)", + "II.13.17(2)(b)", + "II.13.17(2)(c)", + "II.13.17(2)(d)", + "II.13.17(2)(e)", + "II.14.20(4)(d)", + "II.15.21(7)" + ], + "emea-ita-pdpc-2018": [ + "Article 99(3)" ], "emea-ken-pda-2019": [ - "25(g)", - "34(3)", - "39(1)", - "39(1)(a)", - "39(1)(b)", - "39(1)(c)", - "39(1)(d)", - "39(2)" + "IV.25(g)", + "IV.34(1)(b)", + "IV.34(3)", + "IV.39(1)", + "IV.39(1)(a)", + "IV.39(1)(b)", + "IV.39(1)(c)", + "IV.39(1)(d)", + "IV.39(2)" ], "emea-nga-dpr-2019": [ - "2.1(1)(c)" - ], - "emea-nor-pda-2018": [ - "8", - "11", - "15", - "27", - "28" - ], - "emea-pol-act-29-1997": [ - "23", - "26" - ], - "emea-rus-federal-law-27-2006": [ - "5" + "3.1(9)(a)" ], "emea-sau-pdpl-2023": [ "Article 11.4", @@ -7805,127 +9143,103 @@ "Article 18.2.a", "Article 18.2.b" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.11" - ], "emea-srb-act-9-2018": [ - "5.5", - "8" + "II.8", + "III.3.30-1(1)" ], "emea-zaf-popia-2013": [ - "4", - "14", - "16" - ], - "emea-esp-decree-1720-2007": [ - "8", - "22" + "3.A.3.14(1)", + "3.A.3.14(1)(a)", + "3.A.3.14(1)(b)", + "3.A.3.14(1)(c)", + "3.A.3.14(1)(d)", + "3.A.3.14(2)", + "3.A.3.14(3)", + "3.A.3.14(3)(a)", + "3.A.3.14(3)(b)", + "3.A.3.14(4)", + "3.A.3.14(5)", + "3.A.3.14(6)", + "3.A.3.14(6)(a)", + "3.A.3.14(6)(b)", + "3.A.3.14(6)(c)", + "3.A.3.14(6)(d)", + "3.A.3.14(7)" ], "emea-che-fadp-2025": [ - "4" - ], - "emea-tur-lppd-2016": [ - "5", - "7" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3", - "APP Part 6" + "2.1.6.4" ], "apac-aus-privacy-principles-2026": [ - "APP 4", - "APP 6" + "4.11.2", + "4.11.2.a", + "4.11.2.b", + "4.11.2.c", + "4.11.2.d" ], "apac-chn-pipl-2021": [ - "10", - "19", - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)" + "Article 19", + "Article 47" ], "apac-hkg-pdo-2022": [ - "Principle 2", - "Sec 26", - "Principle 3", - "Sec 4" + "26(1)", + "26(1)(a)", + "26(1)(b)", + "26(2)", + "26(2)(a)", + "26(2)(b)", + "Schedule 1 - 2(2)", + "Schedule 1 - 2(3)" ], "apac-ind-privacy-rules-2011": [ - "5" + "5(4)" ], - "apac-jpn-ppi-2020": [ - "19" + "apac-jpn-appi-2020": [ + "IV.2.35-2(5)" ], "apac-mys-pdpa-2010": [ - "5", - "6", - "10" + "10(1)", + "10(2)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.9" ], "apac-phl-dpa-2012": [ - "19", - "21" + "III.11(e)", + "III.11(f)" ], "apac-sgp-pdpa-2012": [ - "23", - "25" - ], - "apac-sgp-mas-trm-2021": [ - "11.1.7" + "5.22A(1)", + "5.22A(2)" ], "apac-kor-pipa-2011": [ - "3", - "4", - "15", - "19", - "21", - "37" - ], - "apac-twn-pdpa-2025": [ - "5", - "19" - ], - "americas-arg-ppd-2018": [ - "5.1", - "4.3", - "9.2" + "III.1.21(1)", + "III.1.21(2)", + "III.1.21(3)", + "III.1.21(4)" ], "americas-bhs-dpa-2003": [ - "6", - "12" + "II.5(1)(e)", + "II.9(1)", + "II.9(1)(a)", + "II.9(1)(b)", + "II.9(1)(c)" ], "americas-bra-lgpd-2018": [ - "6.2", - "6.9", - "13", - "14", - "15", - "21" + "II.IV.16", + "II.IV.16.I", + "II.IV.16.II", + "II.IV.16.III", + "II.IV.16.IV" ], "americas-can-pipeda-2000": [ - "Sec 7", - "Sec 8", - "Principle 5", - "Principle 6" + "P5-4.5.3", + "P7-4.7.5" ], "americas-chl-act-19628-1999": [ - "9" - ], - "americas-col-law-1581-2012": [ - "4" + "I.6" ], "americas-mex-fdpa-2010": [ - "7", - "8", - "9", - "11", - "12", - "13", - "14" + "II.11" ] } }, @@ -7949,7 +9263,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to address the use of Personal Data (PD) for internal testing, training and research that:\n(1) Takes measures to limit or minimize the amount of PD used for internal testing, training and research purposes; and\n(2) Authorizes the use of PD when such information is required for internal testing, training and research.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8016,7 +9330,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -8087,9 +9402,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.5.5" ], - "general-scf-dpmp-2025": [ - "3.3" - ], "usa-federal-fbi-cjis-6-0": [ "4.2.2", "4.2.3.1", @@ -8127,7 +9439,7 @@ "SI-12(02)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.508(a)(2)(i)(B)" + "§ 164.508(a)(2)(i)(B)" ], "usa-federal-irs-1075-2021": [ "PT-2", @@ -8158,158 +9470,33 @@ "47-18-3207(b)(3)(B)", "47-18-3207(b)(3)(C)" ], - "emea-aut-fappd-2000": [ - "Sec 12" + "emea-aut-dpa-2018": [ + "§ 7(2)" ], - "emea-bel-act-8-1992": [ - "4-7", - "21" - ], - "emea-hun-isdfi-2011": [ - "9" + "emea-deu-fdpa-2017": [ + "2.1.2.27(3)" ], - "emea-isr-ppl-5741-1981": [ - "8" + "emea-grc-pirppd-1997": [ + "B.7.2.f" ], - "emea-ita-pdpc-2003": [ - "13", - "20" + "emea-ita-pdpc-2018": [ + "Article 99(3)", + "Article 105(1)", + "Article 105(2)", + "Article 105(3)", + "Article 105(4)" ], "emea-ken-pda-2019": [ - "25(a)", - "25(b)", - "25(c)", - "28(2)(a)", - "28(2)(b)", - "28(2)(c)", - "28(2)(d)", - "28(2)(e)", - "28(2)(f)", - "28(2)(f)(i)", - "28(2)(f)(ii)", - "28(2)(f)(iii)", - "28(3)", - "30(1)(a)", - "30(1)(b)(i)", - "30(1)(b)(ii)", - "30(1)(b)(iii)", - "30(1)(b)(iv)", - "30(1)(b)(v)", - "30(1)(b)(vi)", - "30(1)(b)(vii)", - "30(1)(b)(viii)", - "30(2)", - "30(3)", - "33(1)(a)", - "33(1)(b)", - "33(2)", - "33(3)(a)", - "33(3)(b)", - "33(3)(c)", - "33(3)(d)", - "33(3)(e)", - "33(4)", - "34(1)(a)", - "34(1)(b)", - "34(1)(c)", - "34(1)(d)", - "34(2)(a)", - "34(2)(b)", - "34(3)", - "36", - "37(1)(a)", - "37(1)(b)", - "37(2)", - "53(1)", - "53(2)", - "53(3)(a)", - "53(3)(b)", - "53(4)" - ], - "emea-nga-dpr-2019": [ - "2.1(1)(b)", - "3.1(12)" - ], - "emea-nor-pda-2018": [ - "11", - "27" - ], - "emea-pol-act-29-1997": [ - "26" - ], - "emea-qat-pdppl-2020": [ - "8.2", - "9.4" - ], - "emea-srb-act-9-2018": [ - "5.1", - "5.3", - "7", - "7.1", - "7.2", - "20" - ], - "emea-zaf-popia-2013": [ - "10" - ], - "emea-esp-decree-1720-2007": [ - "8" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" - ], - "apac-aus-privacy-principles-2026": [ - "APP 6" - ], - "apac-chn-pipl-2021": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "28", - "47" - ], - "apac-jpn-ppi-2020": [ - "16-2" - ], - "apac-nzl-privacy-act-2020": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "IV.30(1)(b)(viii)" ], "apac-phl-dpa-2012": [ - "19" - ], - "apac-kor-pipa-2011": [ - "3" - ], - "americas-arg-ppd-2018": [ - "7.3", - "9.2" + "IV.19" ], "americas-bhs-dpa-2003": [ - "6" + "II.5(2)" ], - "americas-col-law-1581-2012": [ - "4" + "americas-bra-lgpd-2018": [ + "II.I.7.IV" ] } }, @@ -8331,7 +9518,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure the accuracy and relevance of Personal Data (PD) throughout the information lifecycle by:\n(1) Keeping PD up-to-date; and \n(2) Remediating identified inaccuracies, as necessary.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8377,7 +9564,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -8413,9 +9601,6 @@ "general-nist-800-82-r3-high": [ "PM-24" ], - "general-scf-dpmp-2025": [ - "5.9" - ], "general-shared-assessments-sig-2025": [ "P.5.1" ], @@ -8445,77 +9630,125 @@ "emea-eu-gdpr-2016": [ "Article 5.1(d)" ], - "emea-ken-pda-2019": [ - "25(f)" + "emea-aut-dpa-2018": [ + "§ 37(6)", + "§ 37(7)" ], - "emea-nor-pda-2018": [ - "11" + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 32(2)" + ], + "emea-deu-fdpa-2017": [ + "3.1.47.4", + "3.4.74(1)" + ], + "emea-hun-act-cxii-2011": [ + "II.4.4(4)", + "II.13.17(1)" + ], + "emea-irl-dpa-2018": [ + "s.74" + ], + "emea-ken-pda-2019": [ + "IV.25(f)" ], "emea-sau-pdpl-2023": [ "Article 14" ], "emea-srb-act-9-2018": [ - "5.4" + "II.11" ], "emea-zaf-popia-2013": [ - "14", - "16" + "3.A.5.16(1)", + "3.A.5.16(2)" ], - "emea-esp-decree-1720-2007": [ - "8" + "emea-che-fadp-2025": [ + "2.1.6.5" ], - "apac-aus-privacy-act-1998": [ - "APP Part 10" + "emea-gbr-dpa-2018": [ + "Section 46(1)", + "Section 47(3)" ], "apac-aus-privacy-principles-2026": [ - "APP 10" + "4.10.1", + "4.10.2" ], "apac-chn-pipl-2021": [ - "8" + "Article 8" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 2(1)(a)", + "Schedule 1 - 2(1)(b)", + "Schedule 1 - 2(1)(c)(i)", + "Schedule 1 - 2(1)(c)(ii)", + "Schedule 1 - 2(1)(c)(ii)(A)", + "Schedule 1 - 2(1)(c)(ii)(B)" ], "apac-ind-dpdpa-2023": [ "8(3)", "8(3)(a)", "8(3)(b)" ], - "apac-jpn-ppi-2020": [ - "19" + "apac-ind-privacy-rules-2011": [ + "5(6)" + ], + "apac-jpn-appi-2020": [ + "IV.1.19" ], "apac-mys-pdpa-2010": [ "11" ], "apac-nzl-privacy-act-2020": [ - "Principle 9" + "3.1.22.8" + ], + "apac-phl-dpa-2012": [ + "III.11(c)" ], "apac-sgp-pdpa-2012": [ - "23" + "6.23", + "6.23(a)", + "6.23(b)", + "6.25", + "6.25(a)", + "6.25(b)" ], - "apac-kor-pipa-2011": [ - "3" + "apac-twn-pdpa-2025": [ + "I.11" ], "americas-arg-ppd-2018": [ - "4.5" + "A.1.3" ], "americas-bhs-dpa-2003": [ - "6" + "II.5(1)(d)", + "II.5(3)", + "II.10(1)", + "II.10(2)", + "II.10(2)(a)", + "II.10(2)(b)" ], "americas-can-pipeda-2000": [ - "Principle 6" + "P6-4.6", + "P6-4.6.1", + "P6-4.6.2", + "P6-4.6.3" + ], + "americas-chl-act-19628-1999": [ + "I.9" ], "americas-col-law-1581-2012": [ - "4" + "VI.17(f)", + "VI.17(g)" ], "americas-mex-fdpa-2010": [ - "9" + "II.11" ] } }, { "control_id": "PRI-05.3", - "title": "Data Masking", + "title": "Data Anonymization", "family": "PRI", - "description": "Mechanisms exist to mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification.", - "scf_question": "Does the organization mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification?", + "description": "Mechanisms exist to mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification.", + "scf_question": "Does the organization mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8528,9 +9761,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to mask sensitive/regulated data through data anonymization, pseudonymization, redaction or de-identification.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to mask sensitive and/or regulated data through data anonymization, pseudonymization, redaction and/or de-identification.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8574,8 +9807,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-iso-27002-2022": [ @@ -8617,9 +9852,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "3.4.1" ], - "general-scf-dpmp-2025": [ - "5.1" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-19(04)" ], @@ -8638,14 +9870,25 @@ "usa-state-va-cdpa-2023": [ "59.1-581.A.1" ], - "apac-aus-privacy-act-1998": [ - "APP Part 2" + "emea-deu-fdpa-2017": [ + "3.2.48(2)6", + "3.2.50" ], - "apac-kor-pipa-2011": [ - "3" + "emea-rus-152-fz-2025": [ + "Art. 13.1" ], - "americas-arg-ppd-2018": [ - "4.4" + "emea-sau-cscc-1-2019": [ + "2-6-1-1" + ], + "apac-jpn-appi-2020": [ + "IV.2.35-2(1)" + ], + "americas-bra-lgpd-2018": [ + "II.II.13", + "II.II.13.1", + "II.II.13.2", + "II.II.13.3", + "II.II.13.4" ] } }, @@ -8667,7 +9910,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to restrict collecting, receiving, processing, storing, transmitting, sharing and/or updating Personal Data (PD) to:\n(1) The purpose(s) originally collected, consistent with the data privacy notice(s);\n(2) What is authorized by the data subject, or authorized agent; and\n(3) What is consistent with applicable laws, regulations and contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8724,7 +9967,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -8822,9 +10066,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.5.5" ], - "general-scf-dpmp-2025": [ - "3.3" - ], "general-shared-assessments-sig-2025": [ "P.2.3" ], @@ -8868,64 +10109,64 @@ "155.260(a)(3)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(c)", - "164.502(d)(1)", - "164.504(g)(2)", - "164.506(a)", - "164.506(c)(1)", - "164.506(c)(5)", - "164.508(a)(1)", - "164.508(a)(2)(i)(C)", - "164.510(a)(1)(i)(A)", - "164.510(a)(1)(i)(B)", - "164.510(a)(1)(i)(C)", - "164.510(a)(1)(i)(D)", - "164.510(a)(1)(ii)(A)", - "164.510(a)(1)(ii)(B)", - "164.510(b)(4)", - "164.512", - "164.512(i)(1)", - "164.512(j)(1)", - "164.512(j)(1)(i)(A)", - "164.512(j)(1)(i)(B)", - "164.512(j)(1)(ii)", - "164.512(j)(1)(ii)(A)", - "164.512(j)(1)(ii)(B)", - "164.512(j)(2)(i)", - "164.512(j)(2)(ii)", - "164.512(j)(3)", - "164.512(j)(4)", - "164.512(k)(1)(i)", - "164.512(k)(1)(i)(A)", - "164.512(k)(1)(i)(B)", - "164.512(k)(1)(ii)", - "164.512(k)(1)(iii)", - "164.512(k)(1)(iv)", - "164.512(k)(2)", - "164.512(k)(3)", - "164.512(k)(4)", - "164.512(k)(4)(i)", - "164.512(k)(4)(ii)", - "164.512(k)(4)(iii)", - "164.512(k)(5)(i)", - "164.512(k)(5)(i)(A)", - "164.512(k)(5)(i)(B)", - "164.512(k)(5)(i)(C)", - "164.512(k)(5)(i)(D)", - "164.512(k)(5)(i)(E)", - "164.512(k)(5)(i)(F)", - "164.512(k)(5)(ii)", - "164.512(k)(5)(iii)", - "164.512(k)(6)(i)", - "164.512(k)(6)(ii)", - "164.512(k)(6)(ii)(1)", - "164.514(f)(2)(i)", - "164.514(g)", - "164.530(i)(4)(ii)", - "164.530(i)(4)(ii)(B)", - "164.532(a)", - "164.532(b)", - "164.532(c)" + "§ 164.502(c)", + "§ 164.502(d)(1)", + "§ 164.504(g)(2)", + "§ 164.506(a)", + "§ 164.506(c)(1)", + "§ 164.506(c)(5)", + "§ 164.508(a)(1)", + "§ 164.508(a)(2)(i)(C)", + "§ 164.510(a)(1)(i)(A)", + "§ 164.510(a)(1)(i)(B)", + "§ 164.510(a)(1)(i)(C)", + "§ 164.510(a)(1)(i)(D)", + "§ 164.510(a)(1)(ii)(A)", + "§ 164.510(a)(1)(ii)(B)", + "§ 164.510(b)(4)", + "§ 164.512", + "§ 164.512(i)(1)", + "§ 164.512(j)(1)", + "§ 164.512(j)(1)(i)(A)", + "§ 164.512(j)(1)(i)(B)", + "§ 164.512(j)(1)(ii)", + "§ 164.512(j)(1)(ii)(A)", + "§ 164.512(j)(1)(ii)(B)", + "§ 164.512(j)(2)(i)", + "§ 164.512(j)(2)(ii)", + "§ 164.512(j)(3)", + "§ 164.512(j)(4)", + "§ 164.512(k)(1)(i)", + "§ 164.512(k)(1)(i)(A)", + "§ 164.512(k)(1)(i)(B)", + "§ 164.512(k)(1)(ii)", + "§ 164.512(k)(1)(iii)", + "§ 164.512(k)(1)(iv)", + "§ 164.512(k)(2)", + "§ 164.512(k)(3)", + "§ 164.512(k)(4)", + "§ 164.512(k)(4)(i)", + "§ 164.512(k)(4)(ii)", + "§ 164.512(k)(4)(iii)", + "§ 164.512(k)(5)(i)", + "§ 164.512(k)(5)(i)(A)", + "§ 164.512(k)(5)(i)(B)", + "§ 164.512(k)(5)(i)(C)", + "§ 164.512(k)(5)(i)(D)", + "§ 164.512(k)(5)(i)(E)", + "§ 164.512(k)(5)(i)(F)", + "§ 164.512(k)(5)(ii)", + "§ 164.512(k)(5)(iii)", + "§ 164.512(k)(6)(i)", + "§ 164.512(k)(6)(ii)", + "§ 164.512(k)(6)(ii)(1)", + "§ 164.514(f)(2)(i)", + "§ 164.514(g)", + "§ 164.530(i)(4)(ii)", + "§ 164.530(i)(4)(ii)(B)", + "§ 164.532(a)", + "§ 164.532(b)", + "§ 164.532(c)" ], "usa-federal-irs-1075-2021": [ "PT-2" @@ -8974,125 +10215,349 @@ "Article 10.5(c)", "Article 10.5(d)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(e)" + "emea-aut-dpa-2018": [ + "§ 7(1)", + "§ 7(6)", + "§ 38", + "§ 39", + "§ 40(1)", + "§ 40(2)", + "§ 40(3)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 8(3)", + "Title 1, Chapter II, Art. 9", + "Title 1, Chapter II, Art. 10(1)", + "Title 2, Chapter III, Art. 45(2)" ], - "emea-aut-fappd-2000": [ - "Sec 12" - ], - "emea-bel-act-8-1992": [ - "4-7", - "21" - ], - "emea-hun-isdfi-2011": [ - "9" - ], - "emea-isr-ppl-5741-1981": [ - "8" + "emea-deu-fdpa-2017": [ + "2.1.1.22(1)", + "2.1.1.22(1)1", + "2.1.1.22(1)1(a)", + "2.1.1.22(1)1(b)", + "2.1.1.22(1)1(c)", + "2.1.1.22(1)1(d)", + "2.1.1.22(1)2(a)", + "2.1.1.22(1)2(b)", + "2.1.1.22(2)", + "2.1.1.22(2)1", + "2.1.1.22(2)2", + "2.1.1.22(2)3", + "2.1.1.22(2)8", + "2.1.1.22(2)9", + "2.1.1.22(2)10", + "2.1.1.24(1)", + "2.1.1.24(1)1", + "2.1.1.24(1)2", + "2.1.1.24(2)", + "2.2.33(1)2(a)", + "2.2.33(1)3(b)", + "3.2.52" ], - "emea-ita-pdpc-2003": [ - "13", - "20" + "emea-grc-pirppd-1997": [ + "B.7.1", + "B.7.2", + "B.8.3" + ], + "emea-hun-act-cxii-2011": [ + "II.11.12(3)(a)", + "II.11.12(3)(b)", + "II.12.13(2)" + ], + "emea-irl-dpa-2018": [ + "s.45", + "s.46", + "s.47", + "s.48", + "s.49", + "s.50", + "s.51", + "s.52", + "s.53", + "s.54", + "s.55", + "s.73" + ], + "emea-ita-pdpc-2018": [ + "Article 2-f(1)", + "Article 2-g(1)", + "Article 101(1)", + "Article 101(2)", + "Article 101(3)", + "Article 122(1)" ], "emea-ken-pda-2019": [ - "44", - "45(a)", - "45(a)(i)", - "45(a)(ii)", - "45(b)", - "45(c)(i)", - "45(c)(ii)", - "45(c)(iii)", - "46(1)(a)", - "46(1)(b)", - "46(2)(a)", - "46(2)(b)", - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" + "IV.25(a)", + "IV.25(b)", + "IV.28(3)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(1)(b)(i)", + "IV.30(1)(b)(ii)", + "IV.30(1)(b)(iii)", + "IV.30(1)(b)(iv)", + "IV.30(1)(b)(v)", + "IV.30(1)(b)(vi)", + "IV.30(1)(b)(vii)", + "IV.30(2)", + "IV.33(1)", + "IV.33(1)(a)", + "IV.33(1)(b)", + "IV.36", + "V.45", + "V.45(a)", + "V.45(a)(i)", + "V.45(a)(ii)", + "V.45(b)", + "V.45(c)", + "V.45(c)(i)", + "V.45(c)(ii)", + "V.45(c)(iii)", + "V.46(1)", + "V.46(1)(a)", + "V.46(1)(b)", + "V.46(2)(a)", + "V.46(2)(b)" ], "emea-nga-dpr-2019": [ + "2.1(1)(a)", + "2.1(1)(a)(i)", + "2.1(1)(a)(ii)", + "2.1(1)(b)", + "2.1(1)(c)", + "2.2(a)", + "2.2(c)", + "2.2(d)", + "2.2(e)", "3.1(12)" ], "emea-nor-pda-2018": [ - "9" - ], - "emea-pol-act-29-1997": [ - "27" + "9", + "12" ], "emea-qat-pdppl-2020": [ - "8.2", - "9.4", - "10", - "16", - "22" + "3.10", + "4.16", + "4.17", + "4.17.4" ], - "emea-rus-federal-law-27-2006": [ - "6", - "10" + "emea-rus-152-fz-2025": [ + "Art. 10", + "Art. 11", + "Art. 13" ], "emea-sau-pdpl-2023": [ "Article 11.3" ], "emea-srb-act-9-2018": [ - "5.1", - "5.3", - "17", - "17.1", - "17.2", - "17.3", - "17.4", - "17.5", - "17.6", - "17.7", - "17.8", - "17.9", - "17.10", - "18.1", - "18.2", - "18.3", - "19" + "II.6(1)", + "II.6(2)", + "II.6(3)", + "II.6(4)", + "II.6(5)", + "II.7", + "II.7(1)", + "II.7(2)", + "II.12", + "II.12(1)", + "II.12(2)", + "II.12(3)", + "II.12(4)", + "II.12(5)", + "II.12(6)", + "II.13", + "II.17", + "II.17(1)", + "II.17(2)", + "II.17(3)", + "II.17(4)", + "II.17(5)", + "II.17(6)", + "II.17(7)", + "II.17(8)", + "II.17(9)", + "II.17(10)", + "II.18", + "II.18(1)", + "II.18(2)", + "II.18(3)", + "II.19", + "II.20", + "IV.1.46", + "IV.1.47-1", + "IV.1.47-1(1)", + "IV.1.47-1(2)", + "IV.1.47-1(3)", + "IV.1.47-1(4)", + "IV.1.47-1(5)", + "IV.1.47-1(6)", + "IV.1.47-1(7)" ], "emea-zaf-popia-2013": [ - "15", - "26" + "3.A.4.15(1)", + "3.A.4.15(2)", + "3.A.4.15(2)(a)", + "3.A.4.15(2)(b)", + "3.A.4.15(2)(c)", + "3.A.4.15(2)(d)", + "3.A.4.15(2)(e)", + "3.A.4.15(3)", + "3.A.4.15(3)(a)", + "3.A.4.15(3)(b)", + "3.A.4.15(3)(c)", + "3.A.4.15(3)(c)(i)", + "3.A.4.15(3)(c)(ii)", + "3.A.4.15(3)(c)(iii)", + "3.A.4.15(3)(c)(iv)", + "3.A.4.15(3)(d)", + "3.A.4.15(3)(d)(i)", + "3.A.4.15(3)(d)(ii)", + "3.A.4.15(3)(e)", + "3.A.4.15(3)(f)", + "3.B.26(1)", + "3.B.26(1)(a)", + "3.B.26(1)(b)", + "3.B.26(1)(b)(i)", + "3.B.26(1)(b)(ii)", + "3.B.27(1)", + "3.B.27(1)(a)", + "3.B.27(1)(b)", + "3.B.27(1)(c)", + "3.B.27(1)(d)", + "3.B.27(1)(d)(i)", + "3.B.27(1)(d)(ii)", + "3.B.27(1)(e)", + "3.B.27(1)(f)", + "3.B.27(2)", + "3.B.27(3)" ], "emea-tur-lppd-2016": [ - "6" - ], - "emea-gbr-dpa-1998": [ - "Chapter29-Schedule1-Part1-Principle 3" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 3" + "4(1)", + "4(2)", + "4(2)(a)", + "4(2)(b)", + "4(2)(c)", + "4(2)(ç)", + "4(2)(d)", + "5(1)", + "5(2)", + "5(2)(a)", + "5(2)(b)", + "5(2)(c)", + "5(2)(ç)", + "5(2)(d)", + "5(2)(e)", + "5(2)(f)", + "6(1)", + "6(2)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "6(3)(ç)", + "6(3)(d)", + "6(3)(e)", + "6(3)(f)", + "6(3)(g)", + "6(4)", + "7(1)", + "7(2)", + "7(3)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(4)", + "Section 44(4)(a)", + "Section 44(4)(b)", + "Section 44(4)(c)", + "Section 44(4)(e)", + "Section 47(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 6", - "APP 7", - "APP 9" + "2.3.3", + "2.3.3.a", + "2.3.3.a.i", + "2.3.3.a.ii", + "2.3.3.b", + "2.3.4", + "2.3.4.a", + "2.3.4.b", + "2.3.4.c", + "2.3.4.d", + "2.3.4.d.i", + "2.3.4.d.ii", + "2.3.4.e", + "2.3.4.e.i", + "2.3.4.e.ii", + "3.6.1", + "3.6.1.a", + "3.6.1.b", + "3.6.2", + "3.6.2.a", + "3.6.2.a.i", + "3.6.2.a.ii", + "3.6.2.b", + "3.6.2.c", + "3.6.2.d", + "3.6.2.e", + "3.6.3", + "3.6.4", + "3.6.4.a", + "3.6.4.b", + "3.7.1", + "3.7.2", + "3.7.2.a", + "3.7.2.b", + "3.7.2.c", + "3.7.2.d", + "3.7.3", + "3.7.3.a", + "3.7.3.a.i", + "3.7.3.a.ii", + "3.7.3.b", + "3.7.3.b.i", + "3.7.3.b.ii", + "3.7.3.c", + "3.7.3.d", + "3.7.3.d.i", + "3.7.3.d.ii", + "3.7.3.e", + "3.7.4", + "3.7.5", + "3.7.5.a", + "3.7.5.b", + "3.7.5.c" ], "apac-chn-cybersecurity-law-2017": [ "Article 41", "Article 44" ], + "apac-chn-csnip-2012": [ + "V" + ], "apac-chn-pipl-2021": [ - "13", - "13(1)", - "13(2)", - "13(3)", - "13(4)", - "13(5)", - "13(6)", - "13(7)", - "18", - "28", - "29", - "30", - "31", - "32" + "Article 13", + "Article 28" + ], + "apac-hkg-pdo-2022": [ + "35K(1)", + "35K(1)(a)", + "35K(1)(b)", + "35K(1)(c)", + "35K(2)", + "35K(2)(a)", + "35K(2)(b)", + "35K(2)(c)", + "35K(3)", + "Schedule 1 - 3(1)", + "Schedule 1 - 3(2)", + "Schedule 1 - 3(2)(a)", + "Schedule 1 - 3(2)(a)(i)", + "Schedule 1 - 3(2)(a)(ii)", + "Schedule 1 - 3(2)(a)(iii)", + "Schedule 1 - 3(2)(b)", + "Schedule 1 - 3(2)(c)", + "Schedule 1 - 3(3)" ], "apac-ind-dpdpa-2023": [ "7(f)", @@ -9101,62 +10566,273 @@ "7(i)", "8(1)" ], - "apac-jpn-ppi-2020": [ - "16-2" + "apac-jpn-appi-2020": [ + "IV.1.16(1)", + "IV.1.17(2)", + "IV.1.17(2)(i)", + "IV.1.17(2)(ii)", + "IV.1.17(2)(iii)", + "IV.1.17(2)(iv)", + "IV.1.17(2)(v)", + "IV.1.17(2)(vi)", + "IV.1.23(1)(i)", + "IV.1.23(1)(ii)", + "IV.1.23(1)(iii)", + "IV.1.23(1)(iv)" ], "apac-mys-pdpa-2010": [ - "34" + "6(1)(a)", + "6(2)", + "6(2)(a)", + "6(2)(b)", + "6(2)(c)", + "6(2)(d)", + "6(2)(e)", + "6(2)(f)", + "6(3)", + "6(3)(a)", + "6(3)(b)", + "6(3)(c)", + "8", + "8(a)", + "8(a)(i)", + "8(a)(ii)", + "8(b)", + "39", + "39(a)", + "39(b)", + "39(b)(i)", + "39(b)(ii)", + "39(c)", + "39(d)", + "39(e)", + "40(1)", + "40(1)(a)", + "40(1)(b)", + "40(1)(b)(i)", + "40(1)(b)(ii)", + "40(1)(b)(ii)(A)", + "40(1)(b)(ii)(B)", + "40(1)(b)(iii)", + "40(1)(b)(iv)", + "40(1)(b)(iv)(A)", + "40(1)(b)(iv)(B)", + "40(1)(b)(v)", + "40(1)(b)(vi)", + "40(1)(b)(vii)", + "40(1)(b)(viii)", + "40(1)(b)(ix)", + "40(1)(b)(x)", + "40(1)(c)", + "42(1)(b)", + "42(1)(b)(A)", + "42(1)(b)(B)", + "42(2)", + "42(2)(a)", + "42(2)(b)", + "42(2)(b)(i)", + "42(2)(b)(ii)", + "42(2)(b)(iii)", + "42(2)(b)(iv)", + "42(2)(c)", + "42(3)", + "42(3)(a)", + "42(3)(b)", + "42(4)", + "42(5)" ], "apac-nzl-privacy-act-2020": [ - "Principle 10", - "P10-(1)", - "P10-(1)(a)", - "P10-(1)(b)(i)", - "P10-(1)(b)(ii)", - "P10-(1)(c)", - "P10-(1)(d)", - "P10-(1)(e)(i)", - "P10-(1)(e)(ii)", - "P10-(1)(e)(iii)", - "P10-(1)(e)(iv)", - "P10-(1)(f)(i)", - "P10-(1)(f)(ii)", - "P10-(2)" + "3.1.22.1(1)", + "3.1.22.1(1)(a)", + "3.1.22.1(1)(b)", + "3.1.22.10(1)", + "3.1.22.10(1)(a)", + "3.1.22.10(1)(b)", + "3.1.22.10(1)(b)(i)", + "3.1.22.10(1)(b)(ii)", + "3.1.22.10(1)(c)", + "3.1.22.10(1)(d)", + "3.1.22.10(1)(e)", + "3.1.22.10(1)(e)(i)", + "3.1.22.10(1)(e)(ii)", + "3.1.22.10(1)(e)(iii)", + "3.1.22.10(1)(e)(iv)", + "3.1.22.10(1)(f)", + "3.1.22.10(1)(f)(i)", + "3.1.22.10(1)(f)(ii)" ], "apac-phl-dpa-2012": [ - "19", - "22", - "34" + "III.11(a)", + "III.11(c)", + "III.12(b)", + "III.12(c)", + "III.12(d)", + "III.12(e)", + "III.12(f)", + "III.13", + "III.13(a)", + "III.13(b)", + "III.13(c)", + "III.13(d)", + "III.13(e)", + "III.13(f)" ], "apac-sgp-pdpa-2012": [ - "14" + "4.1.13", + "4.1.13(a)", + "4.1.13(b)", + "4.1.15(3)(a)", + "4.1.15(3)(b)", + "4.1.15(3)(c)", + "4.1.17(1)(b)", + "4.1.17(2)(a)" ], "apac-kor-pipa-2011": [ - "16", - "18", - "23" + "III.1.18(1)", + "III.1.18(2)", + "III.1.18(2)1", + "III.1.18(2)2", + "III.1.18(2)3", + "III.1.18(2)4", + "III.1.18(2)5", + "III.1.18(2)6", + "III.1.18(2)7", + "III.1.18(2)8", + "III.1.18(2)9", + "III.1.19", + "III.1.19.1", + "III.1.19.2", + "III.2.23.1", + "III.2.23.2" ], "apac-twn-pdpa-2025": [ - "5" - ], - "americas-arg-ppd-2018": [ - "4.3" + "I.6", + "I.6.1", + "I.6.2", + "I.6.3", + "I.6.4", + "I.6.5", + "I.6.6", + "III.19", + "III.19.1", + "III.19.2", + "III.19.3", + "III.19.4", + "III.19.5", + "III.19.6", + "III.19.7", + "III.19.8", + "III.20", + "III.20.1", + "III.20.2", + "III.20.3", + "III.20.4", + "III.20.5", + "III.20.6", + "III.20.7" ], "americas-bhs-dpa-2003": [ - "12" + "IV.29(2)", + "IV.29(2)(a)", + "IV.29(2)(b)", + "IV.29(2)(c)", + "IV.29(2)(d)", + "IV.34(1)", + "IV.34(2)", + "IV.34(2)(a)", + "IV.34(2)(b)", + "IV.34(2)(c)", + "IV.34(2)(d)", + "IV.34(2)(e)", + "IV.34(2)(e)(i)", + "IV.34(2)(e)(ii)", + "IV.34(2)(f)", + "IV.34(2)(g)", + "IV.34(2)(h)", + "IV.34(2)(i)", + "IV.34(2)(j)", + "IV.34(2)(k)", + "IV.34(2)(l)", + "IV.34(2)(m)", + "IV.34(2)(n)", + "IV.34(2)(n)(i)", + "IV.34(2)(n)(ii)", + "IV.34(2)(n)(iii)", + "IV.34(2)(n)(iv)", + "IV.34(2)(o)", + "IV.34(2)(o)(a)", + "IV.34(2)(o)(b)", + "IV.34(2)(p)", + "IV.34(2)(p)(i)", + "IV.34(2)(p)(ii)", + "IV.34(2)(p)(ii)(aa)", + "IV.34(2)(p)(ii)(bb)", + "IV.34(2)(p)(ii)(cc)", + "IV.34(2)(p)(ii)(dd)", + "IV.34(2)(p)(ii)(ee)", + "IV.34(2)(p)(iii)", + "IV.34(2)(q)", + "IV.34(2)(q)(i)", + "IV.34(2)(q)(ii)", + "IV.34(2)(q)(iii)", + "IV.34(2)(r)", + "IV.34(2)(s)", + "IV.34(4)", + "IV.34(4)(a)", + "IV.34(4)(b)", + "IV.34(5)", + "IV.34(5)(a)", + "IV.34(5)(b)", + "IV.34(5)(c)", + "IV.34(5)(d)", + "IV.34(6)" + ], + "americas-bra-lgpd-2018": [ + "II.I.7.II", + "II.I.7.III", + "II.I.7.V", + "II.I.7.VI", + "II.I.7.VII", + "II.I.7.VIII", + "II.I.7.IX", + "II.I.7.X", + "II.I.7.X.1", + "II.I.7.X.2", + "II.I.7.X.3", + "II.I.7.X.4", + "II.I.7.X.5", + "II.I.7.X.6" + ], + "americas-can-pipeda-2000": [ + "P5-4.5", + "P5-4.5.3" ], "americas-chl-act-19628-1999": [ - "10" + "I.6", + "I.10", + "II.15" ], "americas-col-law-1581-2012": [ - "4", - "5", - "6", - "7" + "II.4(f)", + "III.6", + "III.6(a)", + "III.6(b)", + "III.6(c)", + "III.6(d)", + "III.6(e)", + "III.7" ], "americas-mex-fdpa-2010": [ - "7", - "9" + "II.7", + "II.13", + "V.37", + "V.37.I", + "V.37.II", + "V.37.III", + "V.37.IV", + "V.37.V", + "V.37.VI", + "V.37.VII" ] } }, @@ -9165,7 +10841,7 @@ "title": "Inventory of Personal Data (PD)", "family": "PRI", "description": "Mechanisms exist to establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD).", - "scf_question": "Does the organization establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS)that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD)?", + "scf_question": "Does the organization establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD)?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -9180,7 +10856,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to establish and maintain a current inventory of all Technology Assets, Applications and/or Services (TAAS) that collect, receive, process, store, transmit, share, update and/or dispose Personal Data (PD).", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9246,7 +10922,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -9293,9 +10970,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.5.1" ], - "general-scf-dpmp-2025": [ - "1.5" - ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:SG2.SP1" ], @@ -9325,8 +10999,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-05(1)" ], - "apac-kor-pipa-2011": [ - "33" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.exp.1" + ], + "apac-sgp-pdpa-2012": [ + "4.1.13" ] } }, @@ -9348,7 +11026,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically determine if Personal Data (PD) is maintained in electronic form.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9399,7 +11077,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -9416,9 +11095,6 @@ "general-nist-800-82-r3": [ "PM-05(01)" ], - "general-scf-dpmp-2025": [ - "1.5" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-05(01)" ], @@ -9436,9 +11112,6 @@ ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-05(1)" - ], - "emea-rus-federal-law-27-2006": [ - "16" ] } }, @@ -9462,7 +11135,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to define and implement data handling and protection requirements for specific categories of sensitive Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9509,7 +11182,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -9536,10 +11210,6 @@ "PT-07(01)", "PT-07(02)" ], - "general-scf-dpmp-2025": [ - "1.2", - "1.7" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)(i)" ], @@ -9562,6 +11232,9 @@ "usa-state-co-privacy-act-2021": [ "6-1-1308(1)(a)(I)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.340.1(a)" + ], "usa-state-or-cpa-2023": [ "Section 5(4)(a)", "Section 5(4)(e)" @@ -9579,29 +11252,37 @@ "Article 13.1(e)", "Article 14.1(d)" ], - "emea-ken-pda-2019": [ - "47(1)", - "47(2)(a)", - "47(2)(b)", - "47(2)(c)", - "47(2)(d)", - "47(3)" + "emea-aut-dpa-2018": [ + "§ 37(4)" ], - "emea-srb-act-9-2018": [ - "9", - "9.1", - "9.2", - "9.3", - "9.4", - "9.5", - "10", - "13" + "emea-bel-act-30-2018": [ + "Title 1, Chapter II, Art. 8(2)", + "Title 1, Chapter II, Art. 10(2)", + "Title 2, Chapter II, Art. 31" ], - "apac-aus-privacy-principles-2026": [ - "APP 9" + "emea-deu-fdpa-2017": [ + "2.1.2.26(3)", + "2.1.2.26(4)", + "2.1.2.26(7)", + "3.2.48(1)", + "3.2.51(5)", + "3.4.70(2)", + "3.4.72", + "3.4.72.1", + "3.4.72.2", + "3.4.72.3", + "3.4.72.4", + "3.4.72.5", + "3.4.73" + ], + "emea-rus-152-fz-2025": [ + "Art. 10" ], - "apac-chn-pipl-2021": [ - "51(2)" + "apac-kor-pipa-2011": [ + "III.2.23" + ], + "americas-bhs-dpa-2003": [ + "V.43(4)(b)" ] } }, @@ -9623,7 +11304,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to retain Personal Data (PD) in a format permitting data subject identification for no longer than is necessary for legitimate business purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9659,7 +11340,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -9688,7 +11370,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide authenticated data subjects the ability to:\n(1) Access their Personal Data (PD) that is being processed, stored and shared, except where the burden, risk or expense of providing access would be disproportionate to the benefit offered to the data subject through granting access;\n(2) Obtain answers on the specifics of how their PD is collected, received, processed, stored, transmitted, shared, updated and/or disposed; \n(3) Obtain the source(s) of their PD; \n(4) Obtain the categories of their PD being collected, received, processed, stored and shared; \n(5) Request correction to their PD due to inaccuracies;\n(6) Request erasure of their PD; and\n(7) Restrict the further collecting, receiving, processing, storing, transmitting, updated and/or sharing of their PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9749,7 +11431,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -9775,7 +11458,7 @@ ], "general-iso-29100-2024": [ "6.9", - "6.1" + "6.10" ], "general-nist-800-53-r4": [ "IP-2" @@ -9795,9 +11478,6 @@ "general-oecd-privacy-principles-2010": [ "7(a)" ], - "general-scf-dpmp-2025": [ - "6.0" - ], "usa-federal-law-coppa-2024": [ "Sec. 6502.(b)(1)(B)", "Sec. 6502.(b)(1)(B)(iii)" @@ -9842,46 +11522,46 @@ "155.260(a)(3)(i)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.502(a)(2)(i)", - "164.502(a)(2)(ii)", - "164.514(h)(1)(i)", - "164.514(h)(1)(ii)", - "164.524(a)(1)", - "164.524(a)(1)(i)", - "164.524(a)(1)(ii)", - "164.524(a)(1)(iii)", - "164.524(a)(1)(iii)(A)", - "164.524(a)(1)(iii)(B)", - "164.524(a)(2)", - "164.524(a)(2)(i)", - "164.524(a)(2)(ii)", - "164.524(a)(2)(iii)", - "164.524(a)(2)(iv)", - "164.524(a)(2)(v)", - "164.524(a)(3)", - "164.524(a)(3)(i)", - "164.524(a)(3)(ii)", - "164.524(a)(3)(iii)", - "164.524(a)(4)", - "164.524(b)(1)", - "164.524(b)(2)(i)", - "164.524(b)(2)(i)(A)", - "164.524(b)(2)(i)(B)", - "164.524(b)(2)(ii)", - "164.524(b)(2)(ii)(A)", - "164.524(b)(2)(ii)(B)", - "164.524(c)", - "164.524(c)(1)", - "164.524(c)(3)(i)", - "164.524(c)(3)(ii)", - "164.524(c)(4)", - "164.524(c)(4)(i)", - "164.524(c)(4)(ii)", - "164.524(c)(4)(iii)", - "164.524(c)(4)(iv)", - "164.524(d)", - "164.524(d)(1)", - "164.524(d)(2)" + "§ 164.502(a)(2)(i)", + "§ 164.502(a)(2)(ii)", + "§ 164.514(h)(1)(i)", + "§ 164.514(h)(1)(ii)", + "§ 164.524(a)(1)", + "§ 164.524(a)(1)(i)", + "§ 164.524(a)(1)(ii)", + "§ 164.524(a)(1)(iii)", + "§ 164.524(a)(1)(iii)(A)", + "§ 164.524(a)(1)(iii)(B)", + "§ 164.524(a)(2)", + "§ 164.524(a)(2)(i)", + "§ 164.524(a)(2)(ii)", + "§ 164.524(a)(2)(iii)", + "§ 164.524(a)(2)(iv)", + "§ 164.524(a)(2)(v)", + "§ 164.524(a)(3)", + "§ 164.524(a)(3)(i)", + "§ 164.524(a)(3)(ii)", + "§ 164.524(a)(3)(iii)", + "§ 164.524(a)(4)", + "§ 164.524(b)(1)", + "§ 164.524(b)(2)(i)", + "§ 164.524(b)(2)(i)(A)", + "§ 164.524(b)(2)(i)(B)", + "§ 164.524(b)(2)(ii)", + "§ 164.524(b)(2)(ii)(A)", + "§ 164.524(b)(2)(ii)(B)", + "§ 164.524(c)", + "§ 164.524(c)(1)", + "§ 164.524(c)(3)(i)", + "§ 164.524(c)(3)(ii)", + "§ 164.524(c)(4)", + "§ 164.524(c)(4)(i)", + "§ 164.524(c)(4)(ii)", + "§ 164.524(c)(4)(iii)", + "§ 164.524(c)(4)(iv)", + "§ 164.524(d)", + "§ 164.524(d)(1)", + "§ 164.524(d)(2)" ], "usa-federal-cms-marse-2-0": [ "IP-2", @@ -9914,6 +11594,16 @@ "6-1-1306(1)(b)", "6-1-1306(2)(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.345.2", + "603A.346.2", + "603A.505.1(a)", + "603A.505.1(b)", + "603A.505.2", + "603A.505.2(a)", + "603A.510.3(a)(1)", + "603A.510.3(a)(2)" + ], "usa-state-nv-sb220-2019": [ "2.1", "2.2" @@ -9972,59 +11662,104 @@ "Article 18.1(c)", "Article 18.1(d)" ], - "emea-aut-fappd-2000": [ - "Sec 26" + "emea-aut-dpa-2018": [ + "§ 42(1)", + "§ 42(2)", + "§ 44(1)", + "§ 44(5)" ], - "emea-bel-act-8-1992": [ - "10", - "12" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(2)", + "Title 2, Chapter III, Art. 38(1)", + "Title 2, Chapter III, Art. 38(2)", + "Title 2, Chapter III, Art. 39(1)" ], "emea-deu-fdpa-2017": [ - "Sec 19" + "3.3.57(1)", + "3.3.57(1)2", + "3.3.57(1)3", + "3.3.57(1)4", + "3.3.57(1)5", + "3.3.57(1)6", + "3.3.57(1)7", + "3.3.57(1)8", + "3.3.58(1)", + "3.3.58(2)" ], "emea-grc-pirppd-1997": [ - "11", - "12" - ], - "emea-hun-isdfi-2011": [ - "14", - "15" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "13" - ], - "emea-ita-pdpc-2003": [ - "7" + "C.12.1", + "C.12.2", + "C.12.2.a", + "C.12.2.b", + "C.12.2.c", + "C.12.2.d", + "C.12.2.e", + "C.12.2.f" + ], + "emea-hun-act-cxii-2011": [ + "II.13.14(a)", + "II.13.14(b)", + "II.13.14(c)", + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)" + ], + "emea-irl-dpa-2018": [ + "s.56", + "s.57", + "s.58", + "s.59", + "s.60", + "s.61", + "s.91", + "s.92" + ], + "emea-isr-ppl-5741-2025": [ + "s.13", + "s.14" ], "emea-ken-pda-2019": [ - "26(a)", - "26(b)", - "26(c)", - "26(d)", - "26(e)" + "IV.26(b)", + "IV.27", + "IV.34(1)", + "IV.35(3)(b)(i)", + "IV.35(3)(b)(ii)", + "IV.38(1)", + "IV.38(2)", + "IV.38(3)", + "IV.40(1)", + "IV.40(1)(a)", + "IV.40(1)(b)" ], "emea-nga-dpr-2019": [ - "3.1(1)", - "3.1(3)", - "3.1(3)(a)", - "3.1(3)(b)" - ], - "emea-nor-pda-2018": [ - "18" - ], - "emea-pol-act-29-1997": [ - "32" + "2.8(a)", + "3.1(9)", + "3.1(9)(a)", + "3.1(9)(b)", + "3.1(9)(c)", + "3.1(9)(d)", + "3.1(9)(e)", + "3.1(11)", + "3.1(11)(a)", + "3.1(11)(b)", + "3.1(11)(c)", + "3.1(11)(d)", + "3.1(15)" ], "emea-qat-pdppl-2020": [ - "6", - "21.1", - "21.2" - ], - "emea-rus-federal-law-27-2006": [ - "14" + "2.5.1", + "2.5.2", + "2.5.3", + "2.5.4", + "2.6", + "2.6.1", + "2.6.2", + "3.11.6" + ], + "emea-rus-152-fz-2025": [ + "Art. 14", + "Art. 15", + "Art. 20" ], "emea-sau-pdpl-2023": [ "Article 4.2", @@ -10034,131 +11769,258 @@ "Article 21" ], "emea-srb-act-9-2018": [ - "21", - "23", - "24", - "25", - "26", - "28.1", - "28.2", - "28.3", - "28.4", - "28.5" + "III.2.26", + "III.2.26(1)", + "III.2.26(2)", + "III.2.26(3)", + "III.2.26(4)", + "III.2.26(5)", + "III.2.26(6)", + "III.2.26(7)", + "III.2.26(8)", + "III.2.27", + "III.2.27(1)", + "III.2.27(2)", + "III.2.27(3)", + "III.2.27(4)", + "III.2.27(5)", + "III.2.27(6)", + "III.2.27(7)" ], "emea-zaf-popia-2013": [ - "23" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "27", - "28", - "29" + "3.A.8.23(1)", + "3.A.8.23(1)(a)", + "3.A.8.23(1)(b)", + "3.A.8.23(1)(b)(i)", + "3.A.8.23(1)(b)(ii)", + "3.A.8.23(1)(b)(iii)", + "3.A.8.23(1)(b)(iv)", + "3.A.8.23(2)", + "3.A.8.23(3)", + "3.A.8.23(3)(a)", + "3.A.8.23(3)(b)" ], "emea-che-fadp-2025": [ - "8" + "3.21.2", + "4.25.1", + "4.25.2", + "4.25.2.a", + "4.25.2.b", + "4.25.2.c", + "4.25.2.d", + "4.25.2.e", + "4.25.2.f", + "4.25.2.g", + "4.25.3", + "4.25.4", + "4.25.5", + "4.28.1", + "4.28.1.a", + "4.28.1.b", + "4.28.2" ], "emea-tur-lppd-2016": [ - "11" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 12" + "13(1)", + "13(2)", + "13(3)" + ], + "emea-gbr-dpa-2018": [ + "Section 45(1)", + "Section 45(1)(a)", + "Section 45(1)(b)", + "Section 45(2)", + "Section 45(2)(a)", + "Section 45(2)(b)", + "Section 45(2)(c)", + "Section 45(2)(d)", + "Section 45(2)(e)", + "Section 45(2)(e)(i)", + "Section 45(2)(e)(ii)", + "Section 45(2)(f)", + "Section 45(2)(g)", + "Section 45(2A)" ], "apac-aus-privacy-principles-2026": [ - "APP 12" + "3.7.6", + "3.7.6.a", + "3.7.6.b", + "3.7.6.c", + "3.7.6.d", + "3.7.6.e", + "3.7.7", + "3.7.7.a", + "3.7.7.b", + "5.12.1" + ], + "apac-chn-csnip-2012": [ + "VIII" ], "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "Article 44", + "Article 48" ], "apac-hkg-pdo-2022": [ - "Principle 6", - "Sec 17A", - "Sec 18" + "18(1)", + "18(1)(a)", + "18(1)(b)", + "18(2)", + "18(3)", + "18(4)", + "18(4)(a)", + "18(4)(b)", + "35G(3)", + "Schedule 1 - 6", + "Schedule 1 - 6(a)", + "Schedule 1 - 6(b)", + "Schedule 1 - 6(b)(i)", + "Schedule 1 - 6(b)(ii)", + "Schedule 1 - 6(b)(iii)", + "Schedule 1 - 6(b)(iv)", + "Schedule 1 - 6(c)", + "Schedule 1 - 6(d)", + "Schedule 1 - 6(e)", + "Schedule 1 - 6(f)", + "Schedule 1 - 6(g)" ], "apac-ind-dpdpa-2023": [ "11(1)(c)", "11(2)" ], - "apac-jpn-ppi-2020": [ - "27(1)", - "27(1)(i)", - "27(1)(ii)", - "27(1)(iii)", - "27(1)(iv)", - "27(2)(i)", - "27(2)(ii)", - "27(3)", - "28(1)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)" + "apac-jpn-appi-2020": [ + "IV.1.28(1)" ], "apac-mys-pdpa-2010": [ "12", - "30" + "30(1)", + "30(2)(a)", + "30(2)(b)", + "34(1)(a)", + "34(1)(b)", + "34(2)" ], "apac-nzl-privacy-act-2020": [ - "Principle 6", - "P6-(1)", - "P6-(1)(a)", - "P6-(1)(b)", - "P6-(2)", - "P6-(3)" + "3.1.22.6(1)", + "3.1.22.6(1)(a)", + "3.1.22.6(1)(b)", + "3.1.22.6(2)", + "3.1.22.7(1)", + "3.1.22.7(3)", + "3.1.22.7(3)(a)", + "4.2.59" ], "apac-phl-dpa-2012": [ - "34" + "IV.16", + "IV.16(a)", + "IV.16(b)", + "IV.16(b)(1)", + "IV.16(b)(2)", + "IV.16(b)(3)", + "IV.16(b)(4)", + "IV.16(b)(5)", + "IV.16(b)(6)", + "IV.16(b)(7)", + "IV.16(b)(8)", + "IV.16(c)", + "IV.16(c)(1)", + "IV.16(c)(2)", + "IV.16(c)(3)", + "IV.16(c)(4)", + "IV.16(c)(5)", + "IV.16(c)(6)", + "IV.16(c)(7)", + "IV.16(c)(8)", + "IV.16(d)", + "IV.16(e)", + "IV.16(f)" ], "apac-sgp-pdpa-2012": [ - "21" + "4.1.16(3)", + "5.21(1)", + "5.21(1)(a)", + "5.21(1)(b)", + "5.21(2)", + "5.21(5)" ], "apac-kor-pipa-2011": [ - "4", - "35" + "V.35(1)", + "V.35(2)", + "V.35(3)", + "V.36(1)" ], "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "4.6", - "13", - "14.1", - "14.2", - "14.3", - "14.4" + "I.3", + "I.3.1", + "I.3.2", + "I.3.3", + "I.3.4", + "I.3.5" ], "americas-bhs-dpa-2003": [ - "8" + "IV.27(1)", + "IV.29(1)", + "IV.29(1)(a)", + "IV.29(1)(b)", + "IV.29(1)(c)", + "IV.29(1)(d)", + "IV.29(1)(e)", + "IV.29(1)(f)", + "IV.30(1)", + "IV.30(1)(a)", + "IV.30(1)(b)", + "IV.30(2)", + "IV.30(2)(a)", + "IV.30(2)(b)", + "IV.30(3)" ], "americas-bra-lgpd-2018": [ - "6.4", - "9", - "17", - "18.1", - "18.2", - "20" + "III.18", + "III.18.I", + "III.18.II", + "III.18.III", + "III.18.IV", + "III.18.V", + "III.18.VI", + "III.18.VII", + "III.18.VIII", + "III.18.IX", + "III.18.IX.1", + "III.18.IX.2", + "III.18.IX.3", + "III.18.IX.4" ], "americas-can-pipeda-2000": [ - "Principle 8", - "Principle 9" + "P9-4.9", + "P10-4.10" ], "americas-chl-act-19628-1999": [ - "12" + "II.12", + "II.13", + "II.14" ], "americas-col-law-1581-2012": [ - "8", - "11" + "II.4(e)", + "IV.8(a)", + "IV.8(b)", + "IV.8(c)", + "IV.8(f)", + "IV.11", + "V.14", + "V.15", + "V.15.1" ], "americas-mex-fdpa-2010": [ - "15", - "22", - "23", - "25" + "II.16.III", + "III.22", + "III.23", + "III.25", + "III.27", + "IV.28", + "IV.29", + "IV.29.I", + "IV.29.II", + "IV.29.III", + "IV.29.IV", + "IV.31" ] } }, @@ -10180,7 +12042,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process for:\n(1) Data subjects to have inaccurate Personal Data (PD) maintained by the organization corrected or amended; and\n(2) Disseminating corrections or amendments of PD to other authorized users of the PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -10252,7 +12114,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -10285,9 +12148,6 @@ "SI-18(04)", "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "6.3" - ], "usa-federal-doc-data-privacy-framework-2023": [ "II.6.a" ], @@ -10311,13 +12171,13 @@ "1" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(a)(2)", - "164.526(a)(2)(i)", - "164.526(a)(2)(ii)", - "164.526(a)(2)(iii)", - "164.526(a)(2)(iv)", - "164.526(b)(1)" + "§ 164.526(a)(1)", + "§ 164.526(a)(2)", + "§ 164.526(a)(2)(i)", + "§ 164.526(a)(2)(ii)", + "§ 164.526(a)(2)(iii)", + "§ 164.526(a)(2)(iv)", + "§ 164.526(b)(1)" ], "usa-federal-cms-marse-2-0": [ "IP-3", @@ -10347,152 +12207,123 @@ "usa-state-va-cdpa-2023": [ "59.1-577.A.2" ], - "emea-aut-fappd-2000": [ - "Sec 27" - ], - "emea-bel-act-8-1992": [ - "10", - "12" + "emea-aut-dpa-2018": [ + "§ 45(1)" ], "emea-deu-fdpa-2017": [ - "Sec 20" + "3.3.57(1)6", + "3.3.58(1)", + "3.4.75(1)" ], "emea-grc-pirppd-1997": [ - "13" - ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" - ], - "emea-irl-dpa-2003": [ - "2" + "B.4.1.c", + "C.12.2.e" ], - "emea-isr-ppl-5741-1981": [ - "14" + "emea-hun-act-cxii-2011": [ + "II.13.17(1)" ], - "emea-ita-pdpc-2003": [ - "7" + "emea-isr-ppl-5741-2025": [ + "s.14" ], "emea-ken-pda-2019": [ - "25(f)", - "26(d)", - "40(1)(a)", - "40(2)(a)" - ], - "emea-nor-pda-2018": [ - "27" - ], - "emea-pol-act-29-1997": [ - "32" + "IV.25(f)", + "IV.26(d)", + "IV.34(1)(a)", + "IV.40(1)(a)" ], "emea-qat-pdppl-2020": [ - "5.4", - "6.2" - ], - "emea-rus-federal-law-27-2006": [ - "17" + "2.5.4" ], "emea-srb-act-9-2018": [ - "5.4", - "11", - "29" + "III.3.29" ], "emea-zaf-popia-2013": [ - "24" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" - ], - "emea-che-fadp-2025": [ - "5" + "3.A.8.24(1)", + "3.A.8.24(1)(a)", + "3.A.8.24(1)(b)" ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "emea-gbr-dpa-2018": [ + "Section 46(1)", + "Section 46(2)", + "Section 46(3)", + "Section 46(4)" ], "apac-aus-privacy-principles-2026": [ - "APP 13" + "5.13.1", + "5.13.1.a", + "5.13.1.b", + "5.13.1.b.i" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], - "apac-chn-csnip-2012": [ - "8" - ], "apac-chn-pipl-2021": [ - "46", - "49" + "Article 46" ], "apac-hkg-pdo-2022": [ - "Sec 22" + "22(1)(a)", + "22(1)(b)", + "22(1A)", + "22(2)", + "22(2)(a)", + "22(2)(b)", + "22(3)", + "22(4)", + "23(1)", + "23(1)(a)", + "23(1)(c)(i)", + "23(1)(c)(ii)", + "23(2)", + "23(2)(a)", + "23(2)(a)(i)", + "23(2)(a)(ii)", + "23(2)(b)", + "23(3)", + "23(3)(a)", + "23(3)(b)" ], "apac-ind-dpdpa-2023": [ "12(1)", "12(2)(a)", "12(2)(b)" ], - "apac-jpn-ppi-2020": [ - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "29(1)", - "29(2)", - "29(3)" + "apac-jpn-appi-2020": [ + "IV.1.29(1)", + "IV.1.29(2)" ], "apac-mys-pdpa-2010": [ - "34" - ], - "apac-nzl-privacy-act-2020": [ - "P6-(2)", - "Principle 7", - "P7-(1)", - "P7-(2)", - "P7-(3)(a)", - "P7-(3)(b)", - "P7-(4)", - "P7-(5)", - "P7-(6)" - ], - "apac-phl-dpa-2012": [ - "34" + "35(1)", + "35(1)(a)", + "35(1)(b)", + "35(1)(c)", + "35(1)(c)(i)", + "35(1)(c)(ii)", + "35(2)", + "35(2)(a)", + "35(2)(b)", + "35(3)", + "35(4)", + "35(4)(a)", + "35(4)(b)", + "35(5)", + "35(5)(a)", + "35(5)(b)" ], "apac-sgp-pdpa-2012": [ - "22" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "apac-twn-pdpa-2025": [ - "3" - ], - "americas-arg-ppd-2018": [ - "16.1", - "16.3" + "5.22(1)", + "5.22(2)(a)", + "5.22(4)" ], "americas-bhs-dpa-2003": [ - "10" - ], - "americas-bra-lgpd-2018": [ - "18.3" + "IV.26(1)", + "IV.26(2)" ], "americas-can-pipeda-2000": [ - "Principle 10" - ], - "americas-chl-act-19628-1999": [ - "13" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "P9-4.9.5" ], "americas-mex-fdpa-2010": [ - "24", - "28", - "29" + "III.24", + "IV.28" ] } }, @@ -10514,7 +12345,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify affected data subjects if their Personal Data (PD) has been corrected, amended or deleted.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -10573,7 +12404,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -10596,9 +12428,6 @@ "general-nist-800-82-r3": [ "SI-18(05)" ], - "general-scf-dpmp-2025": [ - "6.4" - ], "usa-federal-gsa-fedramp-5-low": [ "SI-18(05)" ], @@ -10612,12 +12441,12 @@ "SI-18(05)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(c)", - "164.526(c)(1)", - "164.526(c)(2)", - "164.526(c)(3)", - "164.526(c)(3)(i)", - "164.526(c)(3)(ii)" + "§ 164.526(c)", + "§ 164.526(c)(1)", + "§ 164.526(c)(2)", + "§ 164.526(c)(3)", + "§ 164.526(c)(3)(i)", + "§ 164.526(c)(3)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7022(e)", @@ -10626,93 +12455,89 @@ "usa-state-tn-tipa-2025": [ "47-18-3203(b)(1)" ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17", - "18" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-ita-pdpc-2003": [ - "10" - ], - "emea-nga-dpr-2019": [ - "3.1(13)" - ], - "emea-pol-act-29-1997": [ - "32" + "emea-aut-dpa-2018": [ + "§ 45(5)" ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 39(5)", + "Title 2, Chapter III, Art. 39(6)" ], - "emea-rus-federal-law-27-2006": [ - "18" - ], - "emea-srb-act-9-2018": [ - "34", - "34.1", - "34.2", - "34.3", - "34.4", - "34.5" + "emea-deu-fdpa-2017": [ + "3.3.58(1)", + "3.3.58(5)", + "3.4.75(3)" ], "emea-zaf-popia-2013": [ - "24" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24", - "31", - "32" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "3.A.8.24(3)", + "3.A.8.24(4)" + ], + "emea-gbr-dpa-2018": [ + "Section 48(1)", + "Section 48(1)(a)", + "Section 48(1)(b)", + "Section 48(1)(b)(i)", + "Section 48(1)(b)(ii)", + "Section 48(1)(b)(iii)", + "Section 48(1)(b)(iv)", + "Section 48(2)", + "Section 48(2)(a)", + "Section 48(2)(b)", + "Section 48(3)", + "Section 48(3)(a)", + "Section 48(3)(b)", + "Section 48(3)(c)", + "Section 48(3)(e)", + "Section 48(4)", + "Section 48(4)(a)", + "Section 48(4)(b)", + "Section 48(4)(c)", + "Section 48(4)(d)", + "Section 48(5)", + "Section 48(6)", + "Section 48(6)(a)", + "Section 48(6)(b)", + "Section 48(7)", + "Section 48(9)", + "Section 48(9)(a)", + "Section 48(9)(b)", + "Section 48(10)" ], "apac-aus-privacy-principles-2026": [ - "APP 13" + "5.13.2", + "5.13.2.a", + "5.13.2.b", + "5.13.3", + "5.13.3.a", + "5.13.3.b", + "5.13.3.c" ], - "apac-chn-pipl-2021": [ - "22", - "46", - "49" + "apac-hkg-pdo-2022": [ + "19(3)(b)", + "19(3)(c)", + "19(3)(c)(i)", + "19(3)(c)(i)(A)", + "19(3)(c)(i)(B)", + "19(3)(c)(ii)", + "19(3)(c)(iii)", + "19(3)(c)(iii)(A)", + "19(3)(c)(iii)(B)", + "19(3)(c)(I)", + "19(3)(c)(II)", + "19(3)(c)(iv)", + "19(3)(c)(v)", + "23(1)(b)" ], - "apac-jpn-ppi-2020": [ - "18(3)", - "18(4)(i)", - "18(4)(ii)", - "18(4)(iii)", - "18(4)(iv)", - "29(1)", - "29(2)", - "29(3)" + "apac-mys-pdpa-2010": [ + "37(1)", + "37(1)(a)", + "37(1)(b)" ], "apac-nzl-privacy-act-2020": [ - "P6-(2)" - ], - "apac-phl-dpa-2012": [ - "34" - ], - "apac-sgp-pdpa-2012": [ - "23" - ], - "apac-kor-pipa-2011": [ - "4", - "36" - ], - "americas-arg-ppd-2018": [ - "16.2" + "3.1.22.7(3)(b)" ], "americas-bhs-dpa-2003": [ - "11" - ], - "americas-bra-lgpd-2018": [ - "18.9" - ], - "americas-col-law-1581-2012": [ - "8", - "11" + "IV.26(3)(a)", + "IV.26(3)(b)" ] } }, @@ -10734,7 +12559,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process for data subjects to appeal an adverse decision.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -10796,7 +12621,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -10830,9 +12656,6 @@ "general-nist-800-161-r1-level-3": [ "PM-26" ], - "general-scf-dpmp-2025": [ - "6.5" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-26" ], @@ -10849,7 +12672,7 @@ "155.260(a)(3)(ii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(d)(4)" + "§ 164.524(d)(4)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(d)(1)", @@ -10858,6 +12681,15 @@ "usa-state-co-privacy-act-2021": [ "6-1-1306(3)(a)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.520.1", + "603A.520.1(a)", + "603A.520.1(b)", + "603A.520.2", + "603A.520.2(a)", + "603A.520.2(b)", + "603A.520.2(c)" + ], "usa-state-or-ors-646a-2025": [ "646A.576(6)", "646A.576(6)(a)", @@ -10877,58 +12709,17 @@ "usa-state-va-cdpa-2023": [ "59.1-577.C" ], - "emea-aut-fappd-2000": [ - "Sec 28" - ], - "emea-grc-pirppd-1997": [ - "13" - ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17", - "18" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-rus-federal-law-27-2006": [ - "17" - ], - "emea-zaf-popia-2013": [ - "63", - "74" - ], - "emea-esp-decree-1720-2007": [ - "23", - "24" - ], - "apac-jpn-ppi-2020": [ - "31" - ], - "apac-phl-dpa-2012": [ - "34" - ], - "apac-kor-pipa-2011": [ - "38" - ], - "americas-bra-lgpd-2018": [ - "18.9" - ], - "americas-can-pipeda-2000": [ - "Sec 11" - ], - "americas-col-law-1581-2012": [ - "15" + "emea-rus-152-fz-2025": [ + "Art. 17" ] } }, { "control_id": "PRI-06.4", - "title": "User Feedback Management", + "title": "Data Subject Feedback Management", "family": "PRI", - "description": "Mechanisms exist to maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", - "scf_question": "Does the organization maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes?", + "description": "Mechanisms exist to maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", + "scf_question": "Does the organization maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes?", "relative_weight": 5, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -10941,9 +12732,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to efficiently and effectively respond to requests, complaints, concerns or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to efficiently and effectively respond to requests, complaints, concerns and/or questions from authenticated data subjects about Personal Data (PD) the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -11000,8 +12791,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -11028,7 +12821,7 @@ "P8.1-POF3" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "GV.MT-P7", @@ -11073,9 +12866,6 @@ "7(c)", "7(d)" ], - "general-scf-dpmp-2025": [ - "6.1" - ], "general-tisax-6-0-3": [ "9.6.1" ], @@ -11100,28 +12890,28 @@ "6" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(b)(2)(i)", - "164.526(b)(2)(i)(A)", - "164.526(b)(2)(i)(B)", - "164.526(b)(2)(ii)", - "164.526(b)(2)(ii)(A)", - "164.526(b)(2)(ii)(B)", - "164.526(d)", - "164.526(d)(1)", - "164.526(d)(1)(i)", - "164.526(d)(1)(ii)", - "164.526(d)(1)(iii)", - "164.526(d)(1)(iv)", - "164.526(d)(2)", - "164.526(d)(3)", - "164.526(d)(4)", - "164.526(d)(5)(i)", - "164.526(d)(5)(ii)", - "164.526(d)(5)(iii)", - "164.526(e)", - "164.526(f)", - "164.530(d)(1)", - "164.530(d)(2)" + "§ 164.526(b)(2)(i)", + "§ 164.526(b)(2)(i)(A)", + "§ 164.526(b)(2)(i)(B)", + "§ 164.526(b)(2)(ii)", + "§ 164.526(b)(2)(ii)(A)", + "§ 164.526(b)(2)(ii)(B)", + "§ 164.526(d)", + "§ 164.526(d)(1)", + "§ 164.526(d)(1)(i)", + "§ 164.526(d)(1)(ii)", + "§ 164.526(d)(1)(iii)", + "§ 164.526(d)(1)(iv)", + "§ 164.526(d)(2)", + "§ 164.526(d)(3)", + "§ 164.526(d)(4)", + "§ 164.526(d)(5)(i)", + "§ 164.526(d)(5)(ii)", + "§ 164.526(d)(5)(iii)", + "§ 164.526(e)", + "§ 164.526(f)", + "§ 164.530(d)(1)", + "§ 164.530(d)(2)" ], "usa-federal-cms-marse-2-0": [ "IP-4", @@ -11173,6 +12963,16 @@ "6-1-1306(3)(b)", "6-1-1306(3)(c)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.345.3", + "603A.345.4", + "603A.346.3", + "603A.346.4", + "603A.510.1", + "603A.510.2", + "603A.510.2(a)", + "603A.510.2(b)" + ], "usa-state-nv-sb220-2019": [ "2.4" ], @@ -11237,119 +13037,299 @@ "emea-eu-gdpr-2016": [ "Article 12.4" ], - "emea-hun-isdfi-2011": [ - "14", - "15", - "17" + "emea-aut-dpa-2018": [ + "§ 42(3)", + "§ 42(4)", + "§ 42(5)", + "§ 42(6)", + "§ 45(8)", + "§ 45(9)", + "§ 44(3)", + "§ 44(4)", + "§ 45(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(3)", + "Title 2, Chapter III, Art. 38(3)", + "Title 2, Chapter III, Art. 39(4)", + "Title 2, Chapter III, Art. 40" ], - "emea-ita-pdpc-2003": [ - "9" + "emea-deu-fdpa-2017": [ + "2.2.34(2)", + "2.2.35(2)", + "3.3.57(6)", + "3.3.59(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.15(1)", + "II.13.15(2)", + "II.13.15(4)", + "II.13.16(2)", + "II.13.18(2)", + "II.15.21(2)", + "II.15.21(3)" + ], + "emea-irl-dpa-2018": [ + "s.93" ], "emea-ken-pda-2019": [ - "40(1)(b)" + "IV.35(4)(a)", + "IV.35(4)(b)", + "IV.35(4)(c)", + "IV.35(4)(c)(i)", + "IV.35(4)(c)(ii)", + "IV.38(4)" ], "emea-nga-dpr-2019": [ - "2.8", - "2.8(a)", - "2.8(b)", "3.1(2)", - "3.1(4)", + "3.1(3)(b)", "3.1(5)", - "3.1(11)(a)", - "3.1(11)(b)", - "3.1(11)(c)", - "3.1(11)(d)", "3.1(13)" ], "emea-qat-pdppl-2020": [ - "5.3", - "5.4", - "6.3" + "3.11.4" + ], + "emea-rus-152-fz-2025": [ + "Art. 21" ], "emea-srb-act-9-2018": [ - "21", - "21.1", - "21.2", - "22", - "22.1", - "22.2", - "23", - "23.x", - "24", - "24.x", - "25", - "25.x", - "26", - "26.1", - "26.2", - "26.3", - "26.4", - "26.5", - "26.6", - "26.7", - "26.8", - "27.1", - "27.2", - "27.3", - "27.4", - "27.5", - "27.6", - "27.7" - ], - "emea-esp-decree-1720-2007": [ - "26" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 13" + "III.1.22", + "III.3.34" + ], + "emea-zaf-popia-2013": [ + "3.A.8.23(4)(a)", + "3.A.8.23(4)(b)", + "3.A.8.23(5)", + "3.A.8.24(2)", + "3.A.8.24(2)(a)", + "3.A.8.24(2)(b)", + "3.A.8.24(2)(c)", + "3.A.8.24(2)(d)" + ], + "emea-che-fadp-2025": [ + "4.25.7", + "4.28.3" + ], + "emea-gbr-dpa-2018": [ + "Section 45(3)", + "Section 45(3)(a)", + "Section 45(3)(b)", + "Section 45(5)", + "Section 45(5)(a)", + "Section 45(5)(b)", + "Section 45(5)(c)", + "Section 45(5)(d)", + "Section 45(5)(e)", + "Section 52(6)", + "Section 53(6)", + "Section 53(6)(a)", + "Section 53(6)(b)", + "Section 53(7)", + "Section 53(7)(a)", + "Section 53(7)(b)" ], "apac-aus-privacy-principles-2026": [ - "APP 12", - "APP 13" + "5.12.3", + "5.12.3.a", + "5.12.3.b", + "5.12.3.c", + "5.12.3.d", + "5.12.3.e", + "5.12.3.f", + "5.12.3.g", + "5.12.3.h", + "5.12.3.h.ii", + "5.12.3.i", + "5.12.3.j", + "5.12.4", + "5.12.4.a", + "5.12.4.a.i", + "5.12.4.a.ii", + "5.12.4.b", + "5.12.5", + "5.12.5.a", + "5.12.5.b", + "5.12.6", + "5.13.4", + "5.13.4.a", + "5.13.5", + "5.13.5.a", + "5.13.5.a.i", + "5.13.5.a.ii", + "5.13.5.b" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], "apac-chn-pipl-2021": [ - "45", - "46", - "50" + "Article 50" ], - "apac-jpn-ppi-2020": [ - "27(3)", - "28(2)", - "28(2)(i)", - "28(2)(ii)", - "28(2)(iii)", - "28(3)", - "28(4)", - "28(5)", - "31", + "apac-hkg-pdo-2022": [ + "18(5)", + "18(5)(a)", + "18(5)(b)", + "19(1)", + "19(1)(a)", + "19(1)(a)(i)", + "19(1)(a)(ii)", + "19(1)(b)", + "19(3)", + "19(3)(a)", + "19(3)(a)(i)", + "19(3)(a)(i)(A)", + "19(3)(a)(i)(B)", + "19(3)(a)(ii)", + "19(4)", + "19(4)(a)", + "19(4)(b)", + "19(4)(b)(i)", + "19(4)(b)(ii)", + "19(4)(b)(ii)(A)", + "19(4)(b)(I)", + "19(4)(b)(II)", + "19(4)(b)(III)", + "19(4)(b)(III)(B)", + "21(1)", + "21(1)(a)", + "21(1)(b)", + "21(1)(c)", + "25(1)", + "25(1)(b)" + ], + "apac-ind-privacy-rules-2011": [ + "5(9)" + ], + "apac-jpn-appi-2020": [ + "IV.1.27(2)", + "IV.1.27(2)(i)", + "IV.1.27(2)(ii)", + "IV.1.27(3)", + "IV.1.28(2)", + "IV.1.28(3)", + "IV.1.35(1)", + "IV.1.35(2)" + ], + "apac-mys-pdpa-2010": [ + "30(3)", + "30(4)", + "30(5)", + "31(1)", + "31(2)", + "31(2)(a)", + "31(2)(b)", + "31(3)", "32(1)", + "32(1)(a)", + "32(1)(b)", + "32(1)(c)", "32(2)", + "32(2)(a)", + "32(2)(b)", + "32(2)(c)", + "32(2)(d)", "32(3)", - "32(4)" + "33", + "33(a)", + "33(b)" + ], + "apac-nzl-privacy-act-2020": [ + "3.1.22.7(2)", + "4.1.44(1)", + "4.1.44(2)", + "4.1.44(2)(b)", + "4.1.44(2)(c)", + "4.1.44(2)(c)(i)", + "4.1.44(2)(c)(ii)", + "4.1.44(2)(d)", + "4.2.63(1)", + "4.2.63(1)(a)", + "4.2.63(1)(b)", + "4.2.63(1)(b)(i)", + "4.2.63(1)(b)(ii)", + "4.2.63(2)", + "4.2.63(3)", + "4.2.63(3)(a)", + "4.2.63(3)(b)", + "4.2.63(3)(c)", + "4.2.64(1)", + "4.2.64(1)(a)", + "4.2.64(1)(b)", + "4.2.64(1)(b)(i)", + "4.2.64(1)(b)(ii)", + "4.2.64(2)", + "4.2.64(3)" + ], + "apac-sgp-pdpa-2012": [ + "3.12(b)", + "4.1.16(2)", + "5.21(6)", + "5.21(6)(b)", + "5.21(7)", + "5.21(7)(b)" ], "apac-kor-pipa-2011": [ - "37" + "V.36(2)", + "V.36(3)", + "V.36(4)", + "V.36(5)", + "V.37(2)", + "V.37(2)1", + "V.37(2)2", + "V.37(2)3", + "V.37(2)4", + "V.37(3)", + "V.37(4)" ], - "americas-arg-ppd-2018": [ - "16.2", - "16.6" + "apac-twn-pdpa-2025": [ + "I.10", + "I.10.1", + "I.10.2", + "I.10.3" ], "americas-bhs-dpa-2003": [ - "11" + "IV.24(4)", + "IV.24(4)(a)", + "IV.24(4)(b)", + "IV.24(5)", + "IV.24(5)(a)", + "IV.24(5)(b)", + "IV.24(10)", + "IV.24(10)(a)", + "IV.24(10)(b)", + "IV.24(10)(c)", + "IV.24(10)(d)", + "IV.24(13)(f)", + "IV.27(3)", + "IV.28(5)(a)", + "IV.28(5)(b)", + "IV.29(3)(a)", + "IV.29(3)(b)" ], "americas-bra-lgpd-2018": [ - "18", - "19", - "21" + "III.18.IX.4.I", + "III.18.IX.4.II", + "III.18.IX.5" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(b)", + "P9-4.9.1", + "P9-4.9.4", + "P10-4.10.2", + "P10-4.10.3", + "P10-4.10.4" ], "americas-col-law-1581-2012": [ - "12", - "15" + "IV.12(a)", + "IV.12(b)", + "IV.12(c)", + "IV.12(d)", + "V.15.2", + "V.15.3", + "VI.17(j)" ], "americas-mex-fdpa-2010": [ - "30" + "IV.32", + "IV.33" ] } }, @@ -11371,7 +13351,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to erase a data subject's Personal Data (PD), in accordance with applicable laws, regulations and contractual obligations pertaining to the retention of their PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -11430,16 +13410,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ "P4.3-POF1" ], - "general-scf-dpmp-2025": [ - "6.6" - ], "usa-state-ca-ccpa-cpra-2026": [ "7022(b)(1)", "7022(f)(2)" @@ -11447,6 +13425,14 @@ "usa-state-co-privacy-act-2021": [ "6-1-1306(1)(d)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.505.1(d)", + "603A.515.1", + "603A.515.1(a)", + "603A.515.1(b)", + "603A.515.2", + "603A.515.3" + ], "usa-state-or-ors-646a-2025": [ "646A.574(1)(c)" ], @@ -11480,66 +13466,64 @@ "Article 17.3(d)", "Article 17.3(e)" ], + "emea-aut-dpa-2018": [ + "§ 45(2)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 39(2)" + ], + "emea-deu-fdpa-2017": [ + "2.2.35(1)", + "3.3.58(2)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.e" + ], "emea-ken-pda-2019": [ - "26(e)", - "40(1)(b)", - "40(2)(b)", - "40(3)" + "IV.26(e)", + "IV.40(1)(b)", + "IV.40(3)" ], "emea-nga-dpr-2019": [ - "3.1(13)" + "3.1(9)(e)" ], "emea-qat-pdppl-2020": [ - "5.3" + "2.5.3" ], "emea-srb-act-9-2018": [ - "30", - "30.x", - "32", - "32.1", - "32.2" + "III.3.30-1", + "III.3.32" + ], + "emea-gbr-dpa-2018": [ + "Section 47(1)", + "Section 47(1)(a)", + "Section 47(1)(b)" ], "apac-chn-cybersecurity-law-2017": [ "Article 43" ], - "apac-chn-pipl-2021": [ - "47", - "47(1)", - "47(2)", - "47(3)", - "47(4)", - "47(5)", - "49" + "apac-chn-csnip-2012": [ + "VIII" ], "apac-ind-dpdpa-2023": [ "8(7)(a)", "12(1)", "12(3)" ], - "apac-jpn-ppi-2020": [ - "30(1)", - "30(2)", - "30(3)", - "30(4)", - "30(5)", - "30(6)", - "30(7)", - "33(1)", - "33(2)", - "34", - "34(1)", - "34(2)", - "34(3)", - "35(1)", - "35(2)" - ], - "americas-arg-ppd-2018": [ - "16.5", - "16.7" - ], - "americas-bra-lgpd-2018": [ - "18.4", - "18.6" + "americas-bhs-dpa-2003": [ + "IV.28(1)", + "IV.28(2)", + "IV.28(2)(a)", + "IV.28(2)(b)", + "IV.28(2)(c)", + "IV.28(2)(d)", + "IV.28(2)(e)", + "IV.28(4)", + "IV.28(4)(a)", + "IV.28(4)(b)", + "IV.28(4)(c)", + "IV.28(4)(d)", + "IV.28(4)(e)" ] } }, @@ -11561,7 +13545,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to format exports of Personal Data (PD) in a structured, machine-readable format that allows data subjects to transfer their PD to another controller without hindrance.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11604,7 +13588,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -11615,12 +13600,9 @@ "ID.DE-P4", "CT.DM-P6" ], - "general-scf-dpmp-2025": [ - "5.7" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(c)(2)(i)", - "164.524(c)(2)(ii)" + "§ 164.524(c)(2)(i)", + "§ 164.524(c)(2)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7024(g)" @@ -11644,44 +13626,32 @@ "Article 20.1" ], "emea-ken-pda-2019": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IV.38(1)", + "IV.38(2)", + "IV.38(3)" ], "emea-nga-dpr-2019": [ - "3.1(6)", "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)", "3.1(15)" ], - "emea-qat-pdppl-2020": [ - "6.3" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], "emea-srb-act-9-2018": [ - "21", - "22", - "36", - "36.1", - "36.2" + "III.3.36" ], - "americas-arg-ppd-2018": [ - "15.1", - "15.2", - "15.3" + "apac-chn-pipl-2021": [ + "Article 45" + ], + "apac-phl-dpa-2012": [ + "IV.18" ], "americas-bra-lgpd-2018": [ - "18.5", - "40" + "III.18.IX.7", + "III.19", + "III.19.II", + "III.19.II.1", + "III.19.II.2", + "III.19.II.2.I", + "III.19.II.2.II", + "III.19.II.3" ] } }, @@ -11690,7 +13660,7 @@ "title": "Personal Data (PD) Exports", "family": "PRI", "description": "Mechanisms exist to export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request.", - "scf_question": "Does the organization process an export of a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request?", + "scf_question": "Does the organization export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -11703,7 +13673,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to export a data subject's available Personal Data (PD) in a readily usable format, upon an authenticated request.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11744,7 +13714,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -11770,9 +13741,6 @@ "7(b)", "7(b)(iv)" ], - "general-scf-dpmp-2025": [ - "5.7" - ], "usa-state-ca-ccpa-cpra-2026": [ "7024(g)" ], @@ -11800,34 +13768,32 @@ "Article 20.1(b)" ], "emea-ken-pda-2019": [ - "38(1)", - "38(2)", - "38(3)", - "38(4)", - "38(5)(a)", - "38(5)(b)", - "38(6)", - "38(7)" + "IV.38(1)", + "IV.38(2)" ], "emea-nga-dpr-2019": [ - "3.1(6)", - "3.1(14)", - "3.1(14)(a)", - "3.1(14)(b)", - "3.1(14)(c)" - ], - "emea-qat-pdppl-2020": [ - "6.3" - ], - "emea-srb-act-9-2018": [ - "21", - "22" + "3.1(14)" ], - "apac-chn-pipl-2021": [ - "45" + "emea-gbr-dpa-2018": [ + "Section 52(1)", + "Section 52(2)", + "Section 52(3)", + "Section 52(5)" ], "apac-ind-dpdpa-2023": [ "11(1)(a)" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.58(1)", + "4.1.58(1)(a)", + "4.1.58(1)(b)", + "4.1.58(1)(c)", + "4.1.58(1)(d)", + "4.1.58(1)(e)", + "4.1.58(1)(f)" + ], + "americas-bra-lgpd-2018": [ + "III.19.I" ] } }, @@ -11849,7 +13815,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to utilize reasonable consumer expectations to verify a data subject's identity, prior to taking action to disclose, share, correct, amend and/or delete Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -11890,16 +13856,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-pmf-2020": [ "A5.1-POF1" ], - "general-scf-dpmp-2025": [ - "6.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7060(a)", "7060(b)", @@ -11931,8 +13895,43 @@ "6-1-1306(1)", "6-1-1306(2)(d)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.505.2(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.576(2)" + ], + "emea-deu-fdpa-2017": [ + "3.3.57(3)", + "3.3.59(4)" + ], + "emea-nga-dpr-2019": [ + "3.1(5)" + ], + "emea-qat-pdppl-2020": [ + "4.17.3" + ], + "emea-gbr-dpa-2018": [ + "Section 52(4)", + "Section 52(4)(a)", + "Section 52(4)(b)" + ], + "apac-aus-privacy-principles-2026": [ + "1.2.2.a", + "1.2.2.b" + ], + "apac-mys-pdpa-2010": [ + "32(1)(a)(i)", + "32(1)(a)(ii)", + "32(1)(a)(ii)(A)", + "32(1)(a)(ii)(B)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.2" + ], + "americas-col-law-1581-2012": [ + "IV.9", + "IV.12" ] } }, @@ -11957,9 +13956,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to disclose Personal Data (PD) to third-parties only for the purposes identified in the data privacy notice and with the implicit or explicit consent of the data subject.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to disclose Personal Data (PD) to third-parties only for the purposes identified in the data privacy notice and with the implicit or explicit consent of the data subject. ", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12016,7 +14015,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -12052,7 +14052,7 @@ "5.33" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "CT.PO-P2" @@ -12087,9 +14087,6 @@ "general-nist-800-161-r1-level-2": [ "AC-21" ], - "general-scf-dpmp-2025": [ - "10.2" - ], "general-tisax-6-0-3": [ "9.5.2" ], @@ -12112,12 +14109,12 @@ "155.260(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.506(c)(1)", - "164.506(c)(2)", - "164.506(c)(3)", - "164.506(c)(4)", - "164.508(a)(1)", - "164.508(a)(4)(i)" + "§ 164.506(c)(1)", + "§ 164.506(c)(2)", + "§ 164.506(c)(3)", + "§ 164.506(c)(4)", + "§ 164.508(a)(1)", + "§ 164.508(a)(4)(i)" ], "usa-federal-irs-1075-2021": [ "AC-21" @@ -12134,138 +14131,97 @@ "Section 6(1)(a)", "Section 6(1)(c)" ], - "emea-aut-fappd-2000": [ - "Sec 10" + "emea-deu-fdpa-2017": [ + "3.5.79(1)2", + "3.5.81(1)", + "3.5.81(1)1", + "3.5.81(1)2", + "3.5.81(1)3", + "3.5.81(2)", + "3.5.81(3)", + "3.5.81(4)" ], - "emea-isr-cmo-1-0": [ - "10.5" + "emea-grc-pirppd-1997": [ + "B.9.1", + "B.9.2.a", + "B.9.2.b", + "B.9.2.b.i", + "B.9.2.b.ii", + "B.9.2.b.iii", + "B.9.2.c", + "B.9.2.d", + "B.9.2.e" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(3)", + "II.8.9(5)" ], "emea-ken-pda-2019": [ - "25(h)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "IV.25(h)" ], "emea-nga-dpr-2019": [ - "2.4(b)" + "2.12(a)" + ], + "emea-qat-pdppl-2020": [ + "3.12" ], "emea-sau-pdpl-2023": [ "Article 8" ], - "emea-srb-act-9-2018": [ - "5" - ], - "emea-zaf-popia-2013": [ - "18", - "28", - "30", - "31" - ], - "apac-aus-privacy-principles-2026": [ - "APP 7", - "APP 8" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "22", - "27", - "38(3)", - "41", - "42", - "49" + "emea-tur-lppd-2016": [ + "8(1)", + "8(2)", + "8(2)(a)", + "8(2)(b)", + "8(3)" ], "apac-ind-dpdpa-2023": [ "8(2)" ], - "apac-jpn-ppi-2020": [ - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "20.1.6.C.01", - "20.1.6.C.02", - "20.1.7.C.01", - "20.1.7.C.02", - "20.1.8.C.01", - "20.1.9.C.01", - "20.1.10.C.01", - "20.1.10.C.02", - "20.1.11.C.01", - "20.1.12.C.01", - "20.1.13.C.01", - "20.2.3.C.01", - "20.2.4.C.01", - "20.2.5.C.01", - "20.2.6.C.01", - "20.2.6.C.02", - "20.2.6.C.03", - "20.2.7.C.01", - "20.2.8.C.01", - "20.2.9.C.01", - "20.2.9.C.02", - "20.2.9.C.03", - "20.2.9.C.04", - "20.2.10.C.01", - "20.2.10.C.02", - "20.2.11.C.01", - "20.2.11.C.02", - "20.2.11.C.03" + "apac-nzl-privacy-act-2020": [ + "3.1.22.11(1)", + "3.1.22.11(1)(a)", + "3.1.22.11(1)(b)", + "3.1.22.11(1)(c)", + "3.1.22.11(1)(d)", + "3.1.22.11(1)(e)", + "3.1.22.11(1)(e)(i)", + "3.1.22.11(1)(e)(ii)", + "3.1.22.11(1)(e)(iii)", + "3.1.22.11(1)(e)(iv)", + "3.1.22.11(1)(f)", + "3.1.22.11(1)(f)(i)", + "3.1.22.11(1)(f)(ii)", + "3.1.22.11(1)(g)", + "3.1.22.11(1)(h)", + "3.1.22.11(1)(h)(i)", + "3.1.22.11(1)(h)(ii)", + "3.1.22.11(1)(i)" ], "apac-sgp-pdpa-2012": [ - "26" + "4.1.17(1)(c)", + "5.22(2)(b)", + "5.22(3)" ], - "apac-kor-pipa-2011": [ - "17", - "26", - "27" - ], - "americas-arg-ppd-2018": [ - "11.1", - "11.2", - "11.3", - "11.4", - "12.1", - "16.4" + "americas-bhs-dpa-2003": [ + "VI.53(1)", + "VI.54", + "VI.54(a)", + "VI.54(b)", + "VI.54(b)(i)", + "VI.54(b)(ii)", + "VI.54(b)(iii)", + "VI.54(b)(iv)", + "VI.54(b)(v)", + "VI.54(b)(vi)", + "VI.54(c)" ], - "americas-can-pipeda-2000": [ - "Sec 20", - "Sec 23" + "americas-bra-lgpd-2018": [ + "V.33" ], "americas-col-law-1581-2012": [ - "26" + "VI.17(h)" ] } }, @@ -12290,9 +14246,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include data privacy requirements in contracts and other acquisition-related documents that establish data privacy roles and responsibilities for contractors and service providers.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include data privacy requirements in contracts and other acquisition-related documents that establish data privacy roles and responsibilities for contractors and service providers. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12356,7 +14312,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -12397,7 +14354,7 @@ "5.33" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-nist-privacy-framework-1-0": [ "ID.DE-P3" @@ -12419,22 +14376,19 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-tisax-6-0-3": [ "9.5.2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.504(e)(2)(i)", - "164.504(e)(2)(ii)(A)", - "164.504(e)(2)(ii)(B)", - "164.504(e)(2)(ii)(C)", - "164.504(e)(4)(i)", - "164.504(e)(4)(i)(A)", - "164.504(e)(4)(i)(B)", - "164.504(e)(4)(i)(B)(ii)", - "164.504(e)(4)(i)(B)(ii)(A)" + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(ii)(A)", + "§ 164.504(e)(2)(ii)(B)", + "§ 164.504(e)(2)(ii)(C)", + "§ 164.504(e)(4)(i)", + "§ 164.504(e)(4)(i)(A)", + "§ 164.504(e)(4)(i)(B)", + "§ 164.504(e)(4)(i)(B)(ii)", + "§ 164.504(e)(4)(i)(B)(ii)(A)" ], "usa-federal-cms-marse-2-0": [ "AR-3", @@ -12483,6 +14437,15 @@ "usa-state-il-pipa-2006": [ "45(b)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.210.3", + "603A.495.3(d)", + "603A.530.1", + "603A.530.2", + "603A.530.3", + "603A.530.3(a)", + "603A.530.3(b)" + ], "usa-state-or-ors-646a-2025": [ "646A.581(2)" ], @@ -12558,124 +14521,167 @@ "Article 29", "Article 46.3(a)" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-deu-c5-2020": [ - "HR-06", - "PI-02" + "emea-aut-dpa-2018": [ + "§ 48(1)", + "§ 48(2)", + "§ 48(3)", + "§ 48(4)", + "§ 48(5)", + "§ 48(6)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 3, Art. 53(1)", + "Title 2, Chapter IV, Section 3, Art. 53(2)", + "Title 2, Chapter IV, Section 3, Art. 53(3)", + "Title 2, Chapter IV, Section 3, Art. 53(4)", + "Title 2, Chapter IV, Section 3, Art. 53(5)", + "Title 2, Chapter IV, Section 3, Art. 54" ], - "emea-isr-cmo-1-0": [ - "11.1" + "emea-grc-pirppd-1997": [ + "B.10.4" + ], + "emea-hun-act-cxii-2011": [ + "II.7.8(1)(b)", + "II.8.9(1)", + "II.8.9(1)(c)", + "II.8.9(1)(e)", + "II.8.9(2)", + "II.8.9(3)", + "II.8.9(5)", + "II.9.10(1)", + "II.9.10(2)", + "II.9.10(3)", + "II.9.10(4)", + "II.10.11(1)(a)" + ], + "emea-irl-dpa-2018": [ + "s.80" + ], + "emea-isr-ppl-5741-2025": [ + "s.13A" ], "emea-ken-pda-2019": [ - "25(h)", - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)", - "42(2)(a)", - "42(2)(b)", - "42(3)" + "IV.25(h)", + "IV.40(2)(a)", + "IV.40(2)(b)", + "IV.40(3)", + "IV.42(2)(a)", + "IV.42(2)(b)", + "IV.42(3)", + "IV.42(4)" ], "emea-nga-dpr-2019": [ - "2.4(b)", "2.7" ], - "emea-qat-pdppl-2020": [ - "12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-25" - ], "emea-srb-act-9-2018": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "45", - "45.x", - "46" + "IV.1.45-1", + "IV.1.45-1(1)", + "IV.1.45-1(2)", + "IV.1.45-1(3)", + "IV.1.45-1(4)", + "IV.1.45-1(5)", + "IV.1.45-1(6)", + "IV.1.45-1(7)", + "IV.1.45-1(8)", + "IV.1.45-2", + "IV.1.45-2(1)", + "IV.1.45-2(2)", + "IV.1.45-2(3)", + "IV.1.45-2(4)", + "IV.1.45-2(5)", + "IV.1.45-2(6)" ], "emea-zaf-popia-2013": [ - "11", - "20", - "21" - ], - "apac-aus-privacy-principles-2026": [ - "APP 7" + "3.A.7.21(1)", + "3.A.7.21(2)" + ], + "emea-gbr-dpa-2018": [ + "Section 59(1)", + "Section 59(2)", + "Section 59(2)(a)", + "Section 59(2)(b)", + "Section 59(3)", + "Section 59(4)", + "Section 59(5)", + "Section 59(5)(a)", + "Section 59(5)(b)", + "Section 59(5)(c)", + "Section 59(5)(d)", + "Section 59(6)", + "Section 59(6)(a)", + "Section 59(6)(b)", + "Section 59(6)(c)", + "Section 59(6)(d)", + "Section 59(6)(d)(i)", + "Section 59(6)(d)(ii)", + "Section 59(6)(e)", + "Section 59(6)(f)", + "Section 59(7)", + "Section 59(7A)", + "Section 59(8)", + "Section 60", + "Section 60(a)", + "Section 60(b)", + "Section 63" + ], + "apac-aus-cop-sitc-2020": [ + "5" ], "apac-chn-pipl-2021": [ - "20", - "21", - "27", - "38(3)", - "42" + "Article 21" + ], + "apac-hkg-pdo-2022": [ + "Schedule 1 - 4(2)" ], "apac-ind-dpdpa-2023": [ "8(2)", "8(7)(b)" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" + "apac-ind-privacy-rules-2011": [ + "6(4)" ], - "apac-nzl-privacy-act-2020": [ - "Principle 5", - "P5-(a)", - "P5-(a)(i)", - "P5-(a)(ii)", - "P5-(a)(iii)", - "P5-(b)" + "apac-phl-dpa-2012": [ + "III.14", + "V.20(d)" ], "apac-kor-pipa-2011": [ - "26", - "27" + "III.1.18(5)" ], - "americas-arg-ppd-2018": [ - "11.4" + "americas-bhs-dpa-2003": [ + "V.51(1)(a)", + "V.51(1)(b)", + "V.51(1)(b)(i)", + "V.51(1)(b)(ii)", + "V.51(1)(b)(iii)", + "V.51(1)(b)(iv)", + "V.51(2)(a)", + "V.51(2)(b)", + "V.51(2)(c)", + "V.51(2)(d)", + "V.51(2)(e)", + "V.51(2)(f)", + "V.51(2)(g)", + "V.51(2)(h)", + "V.51(3)", + "V.51(4)", + "V.51(5)", + "V.51(5)(a)", + "V.51(5)(b)", + "V.51(6)", + "V.51(7)", + "V.51(8)" ], "americas-bra-lgpd-2018": [ - "35", - "39" + "VI.I.39" ], "americas-can-pipeda-2000": [ - "Sec 20", - "Sec 23" + "P1-4.1.3" + ], + "americas-col-law-1581-2012": [ + "VI.17(i)" + ], + "americas-mex-fdpa-2010": [ + "II.21" ] } }, @@ -12700,9 +14706,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to clearly define and communicate the organization's role in processing Personal Data (PD) in the data processing ecosystem.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to clearly define and communicate the organization's role in processing Personal Data (PD) in the data processing ecosystem. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12761,7 +14767,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -12771,70 +14778,50 @@ "general-nist-privacy-framework-1-0": [ "ID.BE-P1" ], - "general-scf-dpmp-2025": [ - "11.1" - ], "usa-state-or-cpa-2023": [ "Section 6(1)(a)" ], "usa-state-tn-tipa-2025": [ "47-18-3205(d)" ], - "emea-ken-pda-2019": [ - "42(2)(a)", - "42(2)(b)", - "42(3)" + "emea-aut-dpa-2018": [ + "§ 47" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter IV, Section 2, Art. 52" + ], + "emea-deu-fdpa-2017": [ + "3.4.62(1)", + "3.4.62(2)", + "3.4.62(3)", + "3.4.62(4)", + "3.4.62(5)", + "3.4.62(5)1", + "3.4.62(5)2", + "3.4.62(5)3", + "3.4.62(5)4", + "3.4.62(5)5", + "3.4.62(5)6", + "3.4.62(5)7", + "3.4.62(5)9", + "3.4.63" + ], + "emea-grc-pirppd-1997": [ + "B.8.1" + ], + "emea-irl-dpa-2018": [ + "s.79" ], "emea-srb-act-9-2018": [ - "5", - "11", - "30", - "30.x", - "32", - "32.1", - "32.2", - "33", - "43" + "IV.1.43" + ], + "emea-gbr-dpa-2018": [ + "Section 58(1)", + "Section 58(2)", + "Section 58(3)" ], "apac-chn-pipl-2021": [ - "20", - "21", - "27", - "38(3)" - ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "26(1)", - "26(1)(i)", - "26(1)(ii)", - "26(2)", - "26(3)", - "26(4)", - "26-2(1)", - "26-2(1)(i)", - "26-2(1)(ii)", - "26-2(2)", - "26-2(3)" + "Article 20" ] } }, @@ -12856,7 +14843,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to inform applicable third-parties of any modification, deletion or other change that affects shared Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12914,7 +14901,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -12924,9 +14912,6 @@ "general-nist-privacy-framework-1-0": [ "CM.AW-P5" ], - "general-scf-dpmp-2025": [ - "6.4" - ], "usa-state-ca-ccpa-cpra-2026": [ "7022(b)(2)", "7022(b)(3)", @@ -12939,57 +14924,45 @@ "usa-state-va-cdpa-2023": [ "59.1-579.B.2" ], + "emea-deu-fdpa-2017": [ + "3.3.58(5)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.f" + ], + "emea-hun-act-cxii-2011": [ + "II.13.18(1)" + ], "emea-ken-pda-2019": [ - "40(2)", - "40(2)(a)", - "40(2)(b)", - "40(3)" + "IV.40(2)", + "IV.40(3)" ], "emea-nga-dpr-2019": [ "3.1(10)" ], "emea-srb-act-9-2018": [ - "30", - "30.x", - "32", - "32.1", - "32.2", - "33" + "II.11" ], - "apac-chn-pipl-2021": [ - "46" - ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" + "apac-nzl-privacy-act-2020": [ + "3.1.22.7(5)" + ], + "americas-bra-lgpd-2018": [ + "III.18.IX.6" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.6" + ], + "americas-col-law-1581-2012": [ + "VI.17(l)" ] } }, { "control_id": "PRI-07.4", - "title": "Reject Unauthenticated or Untrustworthy Disclosure Requests", + "title": "Disclosure Request Rejections", "family": "PRI", - "description": "Mechanisms exist to reject unauthenticated, or untrustworthy, disclosure requests.", - "scf_question": "Does the organization reject unauthenticated, or untrustworthy, disclosure requests?", + "description": "Mechanisms exist to reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful.", + "scf_question": "Does the organization reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13002,9 +14975,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject unauthenticated, or untrustworthy, disclosure requests.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject disclosure requests that are:\n(1) Unjustified;\n(2) Unauthenticated or untrustworthy; and/or\n(3) Unlawful.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -13047,8 +15020,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -13059,15 +15034,11 @@ "general-csa-cmm-4-1-0": [ "DSP-18" ], - "general-scf-dpmp-2025": [ - "6.0", - "6.1" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.524(d)(2)(i)", - "164.524(d)(2)(ii)", - "164.524(d)(2)(iii)", - "164.524(d)(3)" + "§ 164.524(d)(2)(i)", + "§ 164.524(d)(2)(ii)", + "§ 164.524(d)(2)(iii)", + "§ 164.524(d)(3)" ], "usa-state-ca-ccpa-cpra-2026": [ "7022(a)", @@ -13082,17 +15053,74 @@ "usa-state-tn-tipa-2025": [ "47-18-3203(b)(4)" ], - "usa-state-tx-cdpa-2025": [ - "541.052(e)" + "usa-state-tx-cdpa-2025": [ + "541.052(e)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(4)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(1)" + ], + "emea-gbr-dpa-2018": [ + "Section 53(1)", + "Section 53(1)(a)", + "Section 53(1)(b)", + "Section 53(2)", + "Section 53(3)", + "Section 53(4)", + "Section 53(4A)", + "Section 53(4A)(a)", + "Section 53(4A)(b)", + "Section 53(5)" + ], + "apac-aus-privacy-principles-2026": [ + "5.12.3.h.i" + ], + "apac-chn-pipl-2021": [ + "Article 50" + ], + "apac-hkg-pdo-2022": [ + "24(1)", + "24(1)(a)", + "24(1)(b)", + "24(1)(b)(i)", + "24(1)(b)(ii)", + "24(2)", + "24(3)", + "24(3)(a)", + "24(3)(b)", + "24(3)(c)", + "24(3)(d)", + "24(3)(e)", + "24(4)" + ], + "apac-mys-pdpa-2010": [ + "36(1)", + "36(1)(a)", + "36(1)(a)(i)", + "36(1)(a)(ii)", + "36(1)(a)(ii)(A)", + "36(1)(a)(ii)(B)", + "36(1)(b)", + "36(1)(c)", + "36(1)(d)", + "36(1)(e)", + "36(2)" ], - "emea-srb-act-9-2018": [ - "21.2", - "22.2" + "apac-nzl-privacy-act-2020": [ + "4.1.46(1)" ], - "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "apac-kor-pipa-2011": [ + "V.35(4)", + "V.35(4)1", + "V.35(4)2", + "V.35(4)3", + "V.35(4)3.a", + "V.35(4)3.b", + "V.35(4)3.c", + "V.35(4)3.d", + "V.35(4)3.e" ] } }, @@ -13100,8 +15128,8 @@ "control_id": "PRI-07.5", "title": "Justification To Reject Disclosure Requests", "family": "PRI", - "description": "Mechanisms exist to reject data subject access requests that are categorized as:\n(1) Harassing; \n(2) Repetitive; or\n(3) Fraudulent.", - "scf_question": "Does the organization reject data subject access requests that are categorized as:\n (1) Harassing; \n (2) Repetitive; or\n (3) Fraudulent?", + "description": "Mechanisms exist to document justifiable reasons for rejecting a data subject's access request for disclosure when the request is:\n(1) Harassing;\n(2) Repetitive;\n(3) Fraudulent;\n(4) Unjustified; and/or\n(5) Unlawful.", + "scf_question": "Does the organization document justifiable reasons for rejecting a data subject's access request for disclosure when the request is:\n(1) Harassing;\n(2) Repetitive;\n(3) Fraudulent;\n(4) Unjustified; and/or\n(5) Unlawful?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13114,7 +15142,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to reject data subject access requests that are categorized as:\n(1) Harassing; \n(2) Repetitive; or\n(3) Fraudulent.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13159,8 +15187,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Data Privacy", "crosswalks": { "general-csa-cmm-4-1-0": [ @@ -13176,14 +15206,77 @@ "7027(f)", "7027(j)" ], + "emea-aut-dpa-2018": [ + "§ 44(4)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 36(5)" + ], + "emea-deu-fdpa-2017": [ + "2.2.34(2)", + "3.3.59(4)" + ], + "emea-nga-dpr-2019": [ + "3.1(4)" + ], + "emea-nor-pda-2018": [ + "16" + ], "emea-srb-act-9-2018": [ - "21.2", - "22.2" + "III.1.21(2)", + "III.1.22(2)" ], "apac-chn-pipl-2021": [ - "45", - "46", - "49" + "Article 50" + ], + "apac-hkg-pdo-2022": [ + "20(1)", + "20(1)(a)", + "20(1)(a)(i)", + "20(1)(a)(ii)", + "20(1)(a)(ii)(A)", + "20(1)(a)(ii)(B)", + "20(1)(b)", + "20(1)(c)", + "20(2)(a)", + "20(2)(b)", + "20(3)", + "20(3)(a)", + "20(3)(b)", + "20(3)(c)", + "20(3)(c)(i)", + "20(3)(c)(ii)", + "20(3)(c)(iii)", + "20(3)(d)", + "20(3)(e)", + "20(3)(f)", + "25(1)(a)" + ], + "apac-jpn-appi-2020": [ + "IV.1.28(2)(i)", + "IV.1.28(2)(ii)", + "IV.1.28(2)(iii)" + ], + "apac-mys-pdpa-2010": [ + "32(1)(d)", + "32(1)(d)(i)", + "32(1)(d)(ii)", + "32(1)(e)", + "32(1)(f)", + "32(1)(g)", + "32(1)(h)" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.46(2)", + "4.1.46(3)" + ], + "americas-mex-fdpa-2010": [ + "IV.34", + "IV.34.I", + "IV.34.II", + "IV.34.III", + "IV.34.IV", + "IV.34.V" ] } }, @@ -13205,9 +15298,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to conduct testing, training and monitoring activities for Personal Data (PD) controls.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to conduct testing, training and monitoring activities for Personal Data (PD) controls.\n", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -13272,9 +15365,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -13325,9 +15418,6 @@ "general-pci-dss-4-0-1": [ "A3.1.4" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-14" ], @@ -13355,9 +15445,6 @@ ], "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-14" - ], - "emea-zaf-popia-2013": [ - "19" ] } }, @@ -13366,7 +15453,7 @@ "title": "Personal Data (PD) Lineage", "family": "PRI", "description": "Mechanisms exist to maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD.", - "scf_question": "Does the organization document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD?", + "scf_question": "Does the organization maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13379,7 +15466,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain a process to document the lineage of Personal Data (PD) by recording how the organization collects, receives, processes, stores, transmits, shares, updates and/or disposes PD.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13422,7 +15509,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -13448,10 +15536,6 @@ "general-nist-800-82-r3-high": [ "SA-04(12)" ], - "general-scf-dpmp-2025": [ - "5.1", - "5.13" - ], "usa-federal-gsa-fedramp-5-low": [ "SA-04(12)" ], @@ -13466,9 +15550,6 @@ ], "usa-federal-irs-1075-2021": [ "SA-4(CE-12)" - ], - "emea-zaf-popia-2013": [ - "17" ] } }, @@ -13476,8 +15557,8 @@ "control_id": "PRI-10", "title": "Data Quality Management", "family": "PRI", - "description": "Mechanisms exist to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle.", - "scf_question": "Does the organization manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle?", + "description": "Mechanisms exist to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive and/or regulated data across the information lifecycle.", + "scf_question": "Does the organization manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive and/or regulated data across the information lifecycle?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13490,7 +15571,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to manage the quality, utility, objectivity, integrity and impact determination and de-identification of sensitive/regulated data across the information lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13552,7 +15633,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -13609,9 +15691,6 @@ "general-oecd-privacy-principles-2010": [ "2" ], - "general-scf-dpmp-2025": [ - "5.11" - ], "usa-federal-gsa-fedramp-5-low": [ "PM-22", "PM-23", @@ -13636,10 +15715,10 @@ "5" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.512(i)(1)(i)(B)", - "164.512(i)(1)(i)(B)(1)", - "164.512(i)(1)(i)(B)(2)", - "164.512(i)(1)(i)(B)(3)" + "§ 164.512(i)(1)(i)(B)", + "§ 164.512(i)(1)(i)(B)(1)", + "§ 164.512(i)(1)(i)(B)(2)", + "§ 164.512(i)(1)(i)(B)(3)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(c)" @@ -13647,18 +15726,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-22" ], - "emea-srb-act-9-2018": [ - "5.4", - "11" - ], - "emea-zaf-popia-2013": [ - "4" - ], - "apac-chn-pipl-2021": [ - "8" - ], - "americas-bra-lgpd-2018": [ - "6.5" + "emea-grc-pirppd-1997": [ + "B.4.1.c" ] } }, @@ -13680,7 +15749,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to automatically support the evaluation of data quality across the information lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13725,7 +15794,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -13738,9 +15808,6 @@ "general-nist-800-82-r3": [ "PT-03(02)" ], - "general-scf-dpmp-2025": [ - "5.11" - ], "usa-federal-gsa-fedramp-5-low": [ "PT-03(02)" ], @@ -13773,7 +15840,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to evaluate its analytical processes for potential bias.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13817,21 +15884,18 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": { - "general-scf-dpmp-2025": [ - "5.16" - ] - } + "crosswalks": {} }, { "control_id": "PRI-11", "title": "Data Tagging", "family": "PRI", - "description": "Mechanisms exist to issue data modeling guidelines to support tagging of sensitive/regulated data.", - "scf_question": "Does the organization issue data modeling guidelines to support tagging of sensitive/regulated data?", + "description": "Mechanisms exist to issue data modeling guidelines to support tagging of sensitive and/or regulated data.", + "scf_question": "Does the organization issue data modeling guidelines to support tagging of sensitive and/or regulated data?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -13844,7 +15908,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to issue data modeling guidelines to support tagging of sensitive/regulated data.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -13888,7 +15952,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -13901,10 +15966,6 @@ "general-nist-800-82-r3": [ "PT-03(01)" ], - "general-scf-dpmp-2025": [ - "5.0", - "5.2" - ], "usa-federal-dow-zt-roadmap-1-1": [ "4.2", "4.3", @@ -13989,7 +16050,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -13997,14 +16059,11 @@ "P5.2", "P5.2-POF2" ], - "general-scf-dpmp-2025": [ - "6.2" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.526(a)(1)", - "164.526(b)(1)", - "164.526(e)", - "164.526(f)" + "§ 164.526(a)(1)", + "§ 164.526(b)(1)", + "§ 164.526(e)", + "§ 164.526(f)" ], "usa-state-ca-ccpa-cpra-2026": [ "7023(b)", @@ -14016,9 +16075,6 @@ ], "emea-sau-pdpl-2023": [ "Article 17.1" - ], - "emea-zaf-popia-2013": [ - "16" ] } }, @@ -14040,7 +16096,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to enable data subjects to update their Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14078,7 +16134,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -14086,6 +16143,9 @@ "7023(a)", "7023(b)" ], + "apac-aus-privacy-principles-2026": [ + "5.13.1.b.ii" + ], "apac-ind-dpdpa-2023": [ "12(2)(c)" ] @@ -14109,7 +16169,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to establish a written charter for a Data Management Board (DMB) and assigned organization-defined roles to the DMB.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14171,7 +16231,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -14205,9 +16266,6 @@ "general-nist-800-161-r1-level-1": [ "PM-23" ], - "general-scf-dpmp-2025": [ - "11.4" - ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -14247,7 +16305,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to document Personal Data (PD) processing activities that covers collection, receiving, processing, storage, transmission, sharing, updating and/or disposal actions with sufficient detail to demonstrate conformity with applicable statutory, regulatory and contractual requirements.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -14332,7 +16390,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -14382,10 +16441,6 @@ "general-nist-800-161-r1-level-3": [ "PM-27" ], - "general-scf-dpmp-2025": [ - "5.8", - "11.5" - ], "general-shared-assessments-sig-2025": [ "L.1" ], @@ -14393,6 +16448,19 @@ "AR-6", "DM-2(1)" ], + "usa-state-nv-privacy-law-2023": [ + "603A.535.3", + "603A.535.3(a)", + "603A.535.3(b)", + "603A.535.3(c)", + "603A.535.3(d)", + "603A.535.3(e)", + "603A.535.3(f)", + "603A.535.3(g)", + "603A.535.3(h)", + "603A.535.3(i)", + "603A.535.8" + ], "usa-state-tx-cdpa-2025": [ "541.052(f)(1)" ], @@ -14415,8 +16483,67 @@ "Article 30.2(d)", "Article 30.3" ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-aut-dpa-2018": [ + "§ 13(2)", + "§ 49(1)", + "§ 49(2)", + "§ 49(3)", + "§ 50(1)", + "§ 50(2)", + "§ 50(3)", + "§ 50(5)" + ], + "emea-bel-act-30-2018": [ + "Title 1, Section III, Art. 14(3)", + "Title 2, Chapter III, Art. 45(5)", + "Title 2, Chapter IV, Section 4, Art. 55(1)", + "Title 2, Chapter IV, Section 4, Art. 55(2)", + "Title 2, Chapter IV, Section 4, Art. 55(3)", + "Title 2, Chapter IV, Section 4, Art. 56(1)", + "Title 2, Chapter IV, Section 4, Art. 56(2)", + "Title 2, Chapter IV, Section 4, Art. 56(3)", + "Title 2, Chapter IV, Section 4, Art. 57", + "Title 2, Chapter IV, Section 4, Art. 58" + ], + "emea-deu-fdpa-2017": [ + "3.4.70(1)", + "3.4.70(1)1", + "3.4.70(1)2", + "3.4.70(1)3", + "3.4.70(1)4", + "3.4.70(1)5", + "3.4.70(1)6", + "3.4.70(1)7", + "3.4.70(1)8", + "3.4.70(1)9", + "3.4.70(2)1", + "3.4.70(2)2", + "3.4.70(2)3", + "3.4.70(4)", + "3.4.76(1)", + "3.4.76(1)1", + "3.4.76(1)2", + "3.4.76(1)3", + "3.4.76(1)4", + "3.4.76(1)5", + "3.4.76(1)6", + "3.4.76(2)", + "3.4.76(3)", + "3.4.76(4)", + "3.5.79(2)" + ], + "emea-hun-act-cxii-2011": [ + "II.13.15(2)" + ], + "emea-irl-dpa-2018": [ + "s.81", + "s.82" + ], + "emea-ita-pdpc-2018": [ + "Article 110(2)" + ], + "emea-nga-dpr-2019": [ + "3.1(8)" ], "emea-sau-pdpl-2023": [ "Article 31", @@ -14428,17 +16555,136 @@ "Article 31.6" ], "emea-srb-act-9-2018": [ - "47", - "47.x", - "48", - "52", - "52.1", - "52.2", - "52.3", - "52.4" + "II.15", + "IV.1.47-2", + "IV.1.47-2(1)", + "IV.1.47-2(2)", + "IV.1.47-2(3)", + "IV.1.47-2(4)", + "IV.1.47-2(5)", + "IV.1.47-2(6)", + "IV.1.47-2(7)", + "IV.1.47-2(8)", + "IV.1.47-2(9)", + "IV.1.47-3", + "IV.1.47-3(1)", + "IV.1.47-3(2)", + "IV.1.47-3(3)", + "IV.1.47-3(4)", + "IV.1.47-4", + "IV.1.47-4(1)", + "IV.1.47-4(2)", + "IV.1.47-4(3)", + "IV.1.47-4(4)" + ], + "emea-che-fadp-2025": [ + "2.1.12.1", + "2.1.12.2", + "2.1.12.2.a", + "2.1.12.2.b", + "2.1.12.2.c", + "2.1.12.2.d", + "2.1.12.2.e", + "2.1.12.2.f", + "2.1.12.2.g", + "2.1.12.3", + "2.2.15.1" + ], + "emea-gbr-dpa-2018": [ + "Section 61(1)", + "Section 61(2)", + "Section 61(2)(a)", + "Section 61(2)(b)", + "Section 61(2)(c)", + "Section 61(2)(d)", + "Section 61(2)(e)", + "Section 61(2)(f)", + "Section 61(2)(f)(i)", + "Section 61(2)(f)(ii)", + "Section 61(2)(g)", + "Section 61(2)(h)", + "Section 61(2)(h)(i)", + "Section 61(2)(j)", + "Section 61(2)(k)", + "Section 61(3)", + "Section 61(4)", + "Section 61(4)(a)", + "Section 61(4)(b)", + "Section 61(4)(c)", + "Section 61(4)(d)", + "Section 61(4)(e)", + "Section 61(4)(f)", + "Section 61(5)", + "Section 62(1)", + "Section 62(1)(a)", + "Section 62(1)(b)", + "Section 62(1)(c)", + "Section 62(1)(d)", + "Section 62(1)(e)", + "Section 62(1)(f)", + "Section 62(2)", + "Section 62(2)(a)", + "Section 62(2)(b)", + "Section 62(3)", + "Section 62(3)(a)", + "Section 62(3)(b)", + "Section 62(3)(b)(i)", + "Section 62(3)(b)(ii)", + "Section 62(4)", + "Section 62(4)(a)", + "Section 62(4)(b)", + "Section 62(4)(c)", + "Section 62(4)(d)", + "Section 62(5)" + ], + "apac-hkg-pdo-2022": [ + "27(1)", + "27(1)(a)", + "27(1)(b)", + "27(1)(c)", + "27(1)(c)(i)", + "27(1)(c)(ii)", + "27(2)", + "27(2)(a)", + "27(2)(b)", + "27(2)(c)", + "27(2)(d)", + "27(3)", + "27(3)(a)", + "27(3)(b)", + "27(3)(c)", + "27(3)(d)", + "27(4)", + "27(4)(a)", + "27(4)(b)" + ], + "apac-mys-pdpa-2010": [ + "44(1)" + ], + "americas-bhs-dpa-2003": [ + "V.43(1)", + "V.43(2)", + "V.43(2)(a)", + "V.43(2)(b)", + "V.43(2)(c)", + "V.43(2)(d)", + "V.43(2)(e)", + "V.43(2)(f)", + "V.43(2)(g)", + "V.43(2)(h)", + "V.43(2)(i)", + "V.43(2)(j)", + "V.43(3)", + "V.43(4)", + "V.43(4)(a)", + "V.43(4)(b)", + "V.43(4)(c)" ], "americas-bra-lgpd-2018": [ - "38" + "VI.I.37" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.1" ] } }, @@ -14462,7 +16708,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with an accounting of disclosures of their Personal Data (PD) controlled by:\n(1) The organization; and/or\n(2) Relevant third-parties that their PD was shared with.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -14524,7 +16770,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -14576,49 +16823,46 @@ "general-nist-800-161-r1-level-2": [ "PM-21" ], - "general-scf-dpmp-2025": [ - "5.8" - ], "usa-federal-law-hipaa-simplification-2013": [ - "164.528(a)(1)", - "164.528(a)(1)(i)", - "164.528(a)(1)(ii)", - "164.528(a)(1)(iii)", - "164.528(a)(1)(iv)", - "164.528(a)(1)(v)", - "164.528(a)(1)(vi)", - "164.528(a)(1)(vii)", - "164.528(a)(1)(viii)", - "164.528(a)(1)(ix)", - "164.528(b)", - "164.528(b)(1)", - "164.528(b)(2)", - "164.528(b)(2)(i)", - "164.528(b)(2)(ii)", - "164.528(b)(2)(iii)", - "164.528(b)(2)(iv)", - "164.528(b)(3)", - "164.528(b)(3)(i)", - "164.528(b)(3)(ii)", - "164.528(b)(3)(iii)", - "164.528(b)(4)(i)", - "164.528(b)(4)(i)(A)", - "164.528(b)(4)(i)(B)", - "164.528(b)(4)(i)(C)", - "164.528(b)(4)(i)(D)", - "164.528(b)(4)(i)(E)", - "164.528(b)(4)(i)(F)", - "164.528(b)(4)(ii)", - "164.528(c)(1)", - "164.528(c)(1)(i)", - "164.528(c)(1)(ii)", - "164.528(c)(1)(ii)(A)", - "164.528(c)(1)(ii)(B)", - "164.528(c)(2)", - "164.528(d)", - "164.528(d)(1)", - "164.528(d)(2)", - "164.528(d)(3)" + "§ 164.528(a)(1)", + "§ 164.528(a)(1)(i)", + "§ 164.528(a)(1)(ii)", + "§ 164.528(a)(1)(iii)", + "§ 164.528(a)(1)(iv)", + "§ 164.528(a)(1)(v)", + "§ 164.528(a)(1)(vi)", + "§ 164.528(a)(1)(vii)", + "§ 164.528(a)(1)(viii)", + "§ 164.528(a)(1)(ix)", + "§ 164.528(b)", + "§ 164.528(b)(1)", + "§ 164.528(b)(2)", + "§ 164.528(b)(2)(i)", + "§ 164.528(b)(2)(ii)", + "§ 164.528(b)(2)(iii)", + "§ 164.528(b)(2)(iv)", + "§ 164.528(b)(3)", + "§ 164.528(b)(3)(i)", + "§ 164.528(b)(3)(ii)", + "§ 164.528(b)(3)(iii)", + "§ 164.528(b)(4)(i)", + "§ 164.528(b)(4)(i)(A)", + "§ 164.528(b)(4)(i)(B)", + "§ 164.528(b)(4)(i)(C)", + "§ 164.528(b)(4)(i)(D)", + "§ 164.528(b)(4)(i)(E)", + "§ 164.528(b)(4)(i)(F)", + "§ 164.528(b)(4)(ii)", + "§ 164.528(c)(1)", + "§ 164.528(c)(1)(i)", + "§ 164.528(c)(1)(ii)", + "§ 164.528(c)(1)(ii)(A)", + "§ 164.528(c)(1)(ii)(B)", + "§ 164.528(c)(2)", + "§ 164.528(d)", + "§ 164.528(d)(1)", + "§ 164.528(d)(2)", + "§ 164.528(d)(3)" ], "usa-federal-irs-1075-2021": [ "PM-21" @@ -14636,28 +16880,34 @@ "Section 3(1)(a)(B)(i)", "Section 3(1)(a)(B)(ii)" ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-deu-fdpa-2017": [ + "3.3.57(1)4", + "3.5.79(2)" ], - "emea-srb-act-9-2018": [ - "33" + "emea-hun-act-cxii-2011": [ + "II.13.15(2)" ], - "emea-zaf-popia-2013": [ - "17" + "emea-nga-dpr-2019": [ + "3.1(8)" + ], + "apac-chn-pipl-2021": [ + "Article 22", + "Article 23" ], "apac-ind-dpdpa-2023": [ "11(1)(b)" ], - "apac-jpn-ppi-2020": [ - "25(1)", - "25(2)" + "apac-jpn-appi-2020": [ + "IV.1.25(1)", + "IV.1.25(2)", + "IV.1.26(3)", + "IV.1.26(4)" ], - "apac-phl-dpa-2012": [ - "20" + "americas-bhs-dpa-2003": [ + "V.43(4)(c)" ], - "americas-bra-lgpd-2018": [ - "18.7", - "37" + "americas-can-pipeda-2000": [ + "P9-4.9.3" ] } }, @@ -14679,7 +16929,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of applicable legal requests to disclose Personal Data (PD).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14723,26 +16973,32 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-csa-cmm-4-1-0": [ "DSP-18" ], - "general-scf-dpmp-2025": [ - "4.0", - "4.1" - ], - "emea-qat-pdppl-2020": [ - "6.2" + "emea-nga-dpr-2019": [ + "3.1(8)" ], "emea-sau-pdpl-2023": [ "Article 24.2" ], "emea-srb-act-9-2018": [ - "33", - "35" + "III.3.33" + ], + "apac-aus-privacy-principles-2026": [ + "3.6.5" + ], + "americas-bhs-dpa-2003": [ + "V.46(3)", + "V.46(3)(a)", + "V.46(3)(b)", + "V.46(3)(c)", + "V.46(3)(d)" ] } }, @@ -14766,7 +17022,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to register as a data controller and/or data processor, including registering databases containing Personal Data (PD) with the appropriate Data Authority, when necessary.", "4": "Privacy (PRI) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -14812,115 +17068,74 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.3" - ], "general-tisax-6-0-3": [ "9.3.1" ], "usa-state-vt-act-171-2018": [ "2446(a)(1)" ], - "emea-aut-fappd-2000": [ - "Sec 16", - "Sec 17" - ], - "emea-bel-act-8-1992": [ - "17" - ], - "emea-deu-fdpa-2017": [ - "Sec 4d", - "Sec 4e" - ], "emea-grc-pirppd-1997": [ - "6" - ], - "emea-hun-isdfi-2011": [ - "65", - "66" - ], - "emea-irl-dpa-2003": [ - "17" - ], - "emea-isr-ppl-5741-1981": [ - "8", - "9" - ], - "emea-ita-pdpc-2003": [ - "26", - "37" - ], - "emea-ken-pda-2019": [ - "18(1)", - "18(2)", - "18(2)(a)", - "18(2)(b)", - "18(2)(c)", - "18(2)(d)", - "19(1)", - "19(2)", - "19(2)(a)", - "19(2)(b)", - "19(2)(c)", - "19(2)(d)", - "19(2)(e)", - "19(2)(f)", - "19(2)(g)", - "19(3)", - "19(4)", - "19(5)", - "19(6)", - "19(7)", - "20" - ], - "emea-nor-pda-2018": [ - "33" - ], - "emea-pol-act-29-1997": [ - "40" + "B.6.1", + "B.6.2", + "B.6.2.a", + "B.6.2.b", + "B.6.2.c", + "B.6.2.d", + "B.6.2.e", + "B.6.2.f", + "B.6.2.g", + "B.6.2.h", + "B.6.3", + "B.6.4" + ], + "emea-isr-ppl-5741-2025": [ + "s.8", + "s.8A", + "s.9", + "s.10" ], - "emea-rus-federal-law-27-2006": [ - "23" - ], - "emea-esp-decree-1720-2007": [ - "60" + "emea-nga-dpr-2019": [ + "4.1(4)" ], - "emea-che-fadp-2025": [ - "11" + "emea-rus-152-fz-2025": [ + "Art. 22" ], "emea-tur-lppd-2016": [ - "16" - ], - "apac-hkg-pdo-2022": [ - "Sec 15" - ], - "apac-mys-pdpa-2010": [ - "14", - "15" - ], - "apac-phl-dpa-2012": [ - "46", - "47", - "48" - ], - "apac-sgp-pdpa-2012": [ - "39" - ], - "apac-kor-pipa-2011": [ - "32" + "16(1)", + "16(2)", + "16(3)", + "16(3)(a)", + "16(3)(b)", + "16(3)(c)", + "16(3)(ç)", + "16(3)(d)", + "16(3)(e)", + "16(3)(f)", + "16(4)", + "16(5)" ], - "americas-arg-ppd-2018": [ - "21.1", - "21.2", - "21.3", - "24" + "americas-bhs-dpa-2003": [ + "V.41(1)", + "V.41(1)(a)", + "V.41(1)(b)", + "V.41(1)(c)", + "V.41(1)(d)", + "V.41(1)(e)", + "V.41(1)(f)", + "V.41(1)(g)", + "V.41(2)", + "V.41(3)" ], - "americas-col-law-1581-2012": [ - "25" + "americas-chl-act-19628-1999": [ + "I.5", + "I.5(a)", + "I.5(b)", + "I.5(c)" ] } }, @@ -14942,7 +17157,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to constrain the supply of physical and/or digital activity logs to the host government that can directly lead to contravention of the Universal Declaration of Human Rights (UDHR), as well as other applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -14987,7 +17202,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -14998,34 +17214,14 @@ "Article 24" ], "apac-chn-data-security-law-2021": [ - "7", - "8", - "9", - "11", - "14", - "15", - "16", - "18", - "19", - "20", - "28", - "31", - "32", - "33", - "36", - "37", - "38", - "48", - "53" + "Article 27", + "Article 33" + ], + "apac-chn-csnip-2012": [ + "VI" ], "apac-chn-pipl-2021": [ - "11", - "12", - "18", - "26", - "38(4)", - "40", - "47(5)" + "Article 38" ] } }, @@ -15047,7 +17243,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.\n▪ Communications with data subjects is designed to be readily accessible and written in a manner that is concise, unambiguous and understandable by a reasonable person.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to craft disclosures and communications to data subjects in a manner that is concise, unambiguous and understandable by a reasonable person.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15091,16 +17287,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "general-aicpa-tsc-2017": [ "P6.7-POF3" ], - "general-scf-dpmp-2025": [ - "1.8" - ], "usa-state-ca-ccpa-cpra-2026": [ "7003(a)", "7004(a)(3)", @@ -15131,6 +17325,86 @@ ], "usa-state-va-cdpa-2023": [ "59.1-577.B.2" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 32(3)", + "Title 2, Chapter III, Art. 36(1)" + ], + "emea-deu-fdpa-2017": [ + "2.2.33(2)", + "2.2.34(2)", + "3.3.57(6)", + "3.3.57(8)", + "3.3.58(6)", + "3.3.59(1)", + "3.3.59(2)", + "3.4.74(2)" + ], + "emea-grc-pirppd-1997": [ + "C.11.3" + ], + "emea-hun-act-cxii-2011": [ + "II.13.16(2)", + "II.13.18(2)" + ], + "emea-ken-pda-2019": [ + "IV.34(2)(b)", + "IV.35(3)(a)" + ], + "emea-nga-dpr-2019": [ + "3.1(2)", + "3.1(6)" + ], + "emea-qat-pdppl-2020": [ + "2.6.2", + "3.11.4" + ], + "emea-srb-act-9-2018": [ + "III.3.34" + ], + "emea-zaf-popia-2013": [ + "3.A.3.14(8)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(5)", + "Section 44(5)(a)", + "Section 44(5)(b)", + "Section 44(5)(c)", + "Section 44(5)(d)", + "Section 44(5)(e)", + "Section 44(6)" + ], + "apac-aus-privacy-principles-2026": [ + "5.12.9", + "5.12.9.a", + "5.12.9.b", + "5.12.9.c", + "5.12.10" + ], + "apac-nzl-privacy-act-2020": [ + "4.1.46(2)(a)", + "4.1.46(2)(b)", + "4.1.46(3)(a)", + "4.1.46(3)(b)" + ], + "apac-kor-pipa-2011": [ + "III.2.27(1)", + "III.2.27(1)1", + "III.2.27(1)2", + "III.2.27(1)3", + "III.2.27(2)", + "III.2.27(3)" + ], + "americas-bhs-dpa-2003": [ + "IV.24(2)", + "IV.24(2)(a)", + "IV.24(2)(b)", + "IV.36(4)", + "IV.36(4)(a)", + "IV.36(4)(b)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.4" ] } }, @@ -15152,7 +17426,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a conspicuous link to the organization's data privacy notice on all consumer-facing websites and mobile applications.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15209,13 +17483,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.9" - ], "usa-state-ca-ccpa-cpra-2026": [ "7003(c)", "7003(d)" @@ -15240,7 +17512,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with a Notice of Financial Incentive that explains the material terms of a financial incentive, price or service difference so the data subject can make an informed decision about whether to participate.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15297,13 +17569,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { - "general-scf-dpmp-2025": [ - "1.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7010(g)", "7080(e)" @@ -15328,7 +17598,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to maintain records of data subject requests and responses in accordance with an established documentation retention schedule that adheres to applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15385,7 +17655,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -15398,6 +17669,23 @@ ], "usa-state-va-cdpa-2023": [ "59.1-577.B.5" + ], + "emea-deu-fdpa-2017": [ + "3.3.57(8)" + ], + "emea-gbr-dpa-2018": [ + "Section 44(7)(a)", + "Section 44(7)(b)", + "Section 45(7)(a)", + "Section 45(7)(b)" + ], + "apac-mys-pdpa-2010": [ + "37(2)", + "37(2)(a)", + "37(2)(a)(i)", + "37(2)(a)(ii)", + "37(2)(b)", + "37(3)" ] } }, @@ -15419,7 +17707,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to collect metrics associated with data subject requests and responses.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15476,7 +17764,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -15511,7 +17800,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publicly disclose applicable data subject communications metrics, as required by statutory and/or regulatory obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15570,7 +17859,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -15598,7 +17888,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to receive and process data controller communications pertaining to:\n(1) Receiving and responding to data subject requests;\n(2) Updating/correcting Personal Data (PD); \n(3) Accounting for disclosures of PD; and\n(4) Accounting for PD that is stored, processed and/or transmitted on behalf of the data controller.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15670,7 +17960,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -15680,6 +17971,25 @@ "usa-state-tx-cdpa-2025": [ "541.053(a)", "541.055(a)(1)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter III, Art. 38(4)" + ], + "emea-zaf-popia-2013": [ + "3.A.3.14(8)" + ], + "apac-jpn-appi-2020": [ + "IV.1.32(1)", + "IV.1.32(2)", + "IV.1.32(3)", + "IV.1.32(4)" + ], + "apac-sgp-pdpa-2012": [ + "5.22(5)", + "5.22(6)" + ], + "americas-can-pipeda-2000": [ + "P9-4.9.6" ] } }, @@ -15701,7 +18011,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data subject actions utilizing Automated Decision-Making Technology (ADMT) where computation replaces, or substantially replaces, human decisionmaking, conforms with all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15761,10 +18071,100 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", - "crosswalks": {} + "crosswalks": { + "emea-aut-dpa-2018": [ + "§ 41(1)", + "§ 41(2)", + "§ 41(3)" + ], + "emea-bel-act-30-2018": [ + "Title 2, Chapter II, Art. 35" + ], + "emea-deu-fdpa-2017": [ + "2.2.37(1)1", + "2.2.37(1)2", + "2.2.37(2)", + "3.2.54(1)", + "3.2.54(2)", + "3.2.54(3)" + ], + "emea-hun-act-cxii-2011": [ + "II.10.11(2)" + ], + "emea-irl-dpa-2018": [ + "s.89" + ], + "emea-ken-pda-2019": [ + "IV.35(1)" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-srb-act-9-2018": [ + "III.4.39" + ], + "emea-zaf-popia-2013": [ + "8.71(1)", + "8.71(2)", + "8.71(2)(a)", + "8.71(2)(a)(i)", + "8.71(2)(a)(ii)", + "8.71(2)(b)", + "8.71(3)" + ], + "emea-che-fadp-2025": [ + "3.21.3.a" + ], + "emea-gbr-dpa-2018": [ + "Section 50(1)", + "Section 50(1)(a)", + "Section 50(1)(b)", + "Section 50(1)(b)(i)", + "Section 50(1)(b)(ii)", + "Section 50(2)", + "Section 50C(1)", + "Section 50C(1)(a)", + "Section 50C(1)(b)", + "Section 50C(2)", + "Section 50C(2)(a)", + "Section 50C(2)(b)", + "Section 50C(2)(c)", + "Section 50C(2)(d)", + "Section 50C(3)", + "Section 50C(3)(a)", + "Section 50C(3)(b)", + "Section 50C(3)(c)", + "Section 50C(4)", + "Section 50C(4)(a)", + "Section 50C(4)(b)", + "Section 50C(4)(c)", + "Section 50C(4)(d)", + "Section 50C(4)(e)", + "Section 50C(5)" + ], + "apac-chn-pipl-2021": [ + "Article 24" + ], + "americas-bhs-dpa-2003": [ + "IV.24(3)", + "V.49(1)", + "V.49(2)", + "V.49(2)(a)", + "V.49(2)(b)", + "V.49(2)(c)", + "V.49(3)", + "V.49(4)", + "V.49(4)(a)", + "V.49(4)(b)" + ], + "americas-bra-lgpd-2018": [ + "III.20" + ] + } }, { "control_id": "PRI-19.1", @@ -15784,7 +18184,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to notify data subjects of their rights through a pre-use notice when their Personal Data (PD) will be processed by an Automated Decision-Making Technology (ADMT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15844,7 +18244,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -15871,6 +18272,12 @@ "7220(e)(2)", "7220(e)(3)", "7220(e)(4)" + ], + "emea-ken-pda-2019": [ + "IV.35(3)(a)" + ], + "emea-zaf-popia-2013": [ + "8.71(3)(b)" ] } }, @@ -15892,7 +18299,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide concise, unambiguous and understandable instructions on how data subjects can opt-out of Automated Decision-Making Technology (ADMT).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -15952,7 +18359,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -15979,6 +18387,21 @@ "7221(n)", "7221(n)(1)", "7221(n)(2)" + ], + "emea-ken-pda-2019": [ + "IV.35(1)" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-srb-act-9-2018": [ + "III.4.38" + ], + "emea-zaf-popia-2013": [ + "8.71(3)(a)" + ], + "emea-che-fadp-2025": [ + "3.21.3.b" ] } }, @@ -16000,7 +18423,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to provide data subjects with sufficient details of the logic and parameters used by Automated Decision-Making Technology (ADMT) to process the Personal Data (PD) to generate an output with respect to the data subject.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16060,12 +18483,35 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ "7222(a)" + ], + "emea-grc-pirppd-1997": [ + "C.12.2.d" + ], + "emea-rus-152-fz-2025": [ + "Art. 16" + ], + "emea-che-fadp-2025": [ + "3.21.3.a" + ], + "apac-chn-pipl-2021": [ + "Article 24" + ], + "americas-bhs-dpa-2003": [ + "IV.24(3)(a)", + "IV.24(3)(b)", + "IV.24(3)(c)", + "IV.24(3)(d)" + ], + "americas-bra-lgpd-2018": [ + "III.20", + "III.20.1" ] } }, @@ -16087,7 +18533,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to ensure data brokers that collect Personal Data (PD) from a source other than directly from the data subject adhere to all applicable statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16146,7 +18592,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -16173,9 +18620,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a notification to data subjects within the data privacy notice of:\n(1) Their right to direct an organization that sells or shares their Personal Data (PD) to stop selling or sharing their PD; and\n(2) The methods available to exercise that right.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to include a notification to data subjects within the data privacy notice of:\n(1) Their right to direct an organization that sells or shares their Personal Data (PD) to stop selling or sharing their PD; and\n(2) The methods available to exercise that right. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -16232,7 +18679,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -16287,7 +18735,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nPrivacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish conspicuous links for data subjects to exercise their rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -16346,7 +18794,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Data Privacy", "crosswalks": { @@ -16367,10 +18816,10 @@ }, { "control_id": "PRI-21.2", - "title": "Alternative Out-Out Link", + "title": "Alternative Opt-Out Link", "family": "PRI", - "description": "Mechanisms exist to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", - "scf_question": "Does the organization publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD?", + "description": "Mechanisms exist to publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD.", + "scf_question": "Does the organization publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -16385,7 +18834,7 @@ "0": "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.", "1": "Privacy (PRI) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRI domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Data privacy-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No formal data privacy team exists. Privacy roles are assigned to existing IT / cybersecurity.", "2": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are documented and maintained by process owners.\n▪ 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 PRI domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Data privacy management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Data privacy management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The data privacy program is developed to work with IT and cybersecurity staff to ensure that applicable statutory, regulatory and/or contractual data privacy obligations for Personal Data (PD) are properly identified and implemented.", - "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.", + "3": "Privacy (PRI) 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:\n▪ Policies and standards associated with PRI domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with PRI domain capabilities are well-documented and kept current by process owners.\n▪ A data privacy team, or similar function, is appropriately staffed and supported to implement and maintain PRI domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of data privacy operations (e.g., privacy notice management software, customer management solution, etc.).\n▪ 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 PRI 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).\n▪ An implemented and operational capability exists to publish a single, clearly-labeled link that allows data subjects to efficiently exercise their opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Not sell or share PD.\nMechanisms exist to publish a single, clearly labeled link that allows data subjects to efficiently exercise opt-out rights to:\n(1) Limit the collection and/or use of Personal Data (PD); and\n(2) Opt out of the sale or sharing of PD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -16442,8 +18891,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control\n- renamed control", "family_name": "Data Privacy", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ diff --git a/docs/api/families/PRM.json b/docs/api/families/PRM.json index b3da5e27..ace6c4b3 100644 --- a/docs/api/families/PRM.json +++ b/docs/api/families/PRM.json @@ -104,9 +104,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -232,12 +232,15 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-csf-2-0": [ "GV.RM", "GV.RR-03" ], - "general-scf-dpmp-2025": [ - "1.4" + "general-nist-cswp-39": [ + "6.1" ], "usa-federal-dow-cert-rmm-1-2": [ "EF:SG1.SP3", @@ -308,12 +311,10 @@ "PL-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(6)", - "3.6.1(61)", - "3.6.1(62)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -321,45 +322,39 @@ "Article 7(c)", "Article 7(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "2.3", "7.4", "7.5", "8.3" ], - "emea-isr-cmo-1-0": [ - "17.5" + "emea-isr-cmo-2-0": [ + "4.1, Stage 4" ], "emea-sau-cscc-1-2019": [ - "1-1" + "1-3-1", + "2-13-1" ], "emea-sau-ecc-1-2018": [ "1-1-3", "1-2-3" ], - "emea-zaf-popia-2013": [ - "19" + "emea-sau-otcc-1-2022": [ + "1-4-2" ], - "emea-esp-ccn-stic-825-2023": [ - "9" + "emea-sau-sama-csf-1-2017": [ + "3.1.5.1" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0720", "ISM-0732" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "25", + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -367,22 +362,24 @@ "apac-jpn-ismap": [ "4.5.1.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], "apac-nzl-ism-3-9": [ "3.2.15.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.22" + "5.2.1", + "5.2.2" ], "americas-can-osfi-b13-2022": [ "1.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.3.1" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -408,7 +405,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to establish a:\n(1) Strategic security, compliance and resilience-specific business plan; and \n(2) Set of objectives to achieve that plan.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -472,9 +469,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-bsi-200-1-1-0": [ @@ -537,10 +534,12 @@ "7102(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(4)", - "3.2.1(5)(a)", - "3.2.1(5)(b)", - "3.2.1(5)(c)" + "3.2.1.4", + "3.2.2.5", + "3.2.2.5(a)", + "3.2.2.5(b)", + "3.2.2.5(c)", + "3.2.2.6" ], "emea-eu-dora-2023": [ "Article 6.8", @@ -563,24 +562,40 @@ "1.2(e)", "1.2(f)" ], + "emea-deu-c5-2020": [ + "SA-02-DOAR" + ], + "emea-isr-cmo-2-0": [ + "2.A", + "4.1, Stage 4", + "4.2, Stage 1.2" + ], "emea-sau-cscc-1-2019": [ - "1-1", "1-1-1" ], "emea-sau-ecc-1-2018": [ "1-1-1", - "1-1-2" + "1-1-2", + "1-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.1.2" - ], - "apac-aus-ism-2024-june": [ + "3.1.2", + "3.1.2.1", + "3.1.2.2", + "3.1.2.2.a", + "3.1.2.2.b", + "3.1.2.2.c", + "3.1.2.3", + "3.1.2.3.a", + "3.1.2.3.b", + "3.1.2.3.c" + ], + "apac-aus-ism-2026-march": [ "ISM-0039", "ISM-0720" ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "apac-aus-ps-cps-230-2023": [ + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -588,21 +603,21 @@ "apac-jpn-ismap": [ "5.1.1.2" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], "apac-nzl-ism-3-9": [ "2.3.25.C.01", "2.3.25.C.02", "2.3.29.C.01" ], - "apac-sgp-mas-trm-2021": [ - "3.1.4", - "3.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.7" - ], "americas-can-osfi-b13-2022": [ "1.2.1" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } }, @@ -687,7 +702,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -704,14 +720,20 @@ "general-iso-31000-2018": [ "5.4.4" ], - "apac-aus-ps-cps-234-2019": [ - "15" + "general-nist-cswp-39": [ + "6.5" + ], + "emea-isr-cmo-2-0": [ + "4.1, Stages 2-3" + ], + "apac-aus-ps-cps-230-2023": [ + "27(b)" ], "apac-jpn-ismap": [ "4.4.5.2" ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "apac-mys-bnm-rmit-2025": [ + "8.1" ], "americas-can-osfi-b13-2022": [ "1.2.1" @@ -740,7 +762,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.\n▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to address all capital planning and investment requests, including the resources needed to implement the Security, Compliance & Resilience Program (SCRP) and document all exceptions to this requirement.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to address all capital planning and investment requests, including the resources needed to implement the Security, Compliance & Resilience Program (SCRP) and document all exceptions to this requirement. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -802,9 +824,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -904,8 +926,8 @@ "general-nist-csf-2-0": [ "GV.RR-03" ], - "general-scf-dpmp-2025": [ - "11.0" + "general-nist-cswp-39": [ + "6.1" ], "usa-federal-dow-cert-rmm-1-2": [ "ADM:GG2.GP3", @@ -957,8 +979,9 @@ "PM-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.1(61)", - "3.6.1(62)" + "3.6.1.61", + "3.6.1.62", + "3.6.1.66" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -969,31 +992,18 @@ "emea-deu-bsrit-2017": [ "2.3" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.8", - "17.9" - ], - "emea-sau-cscc-1-2019": [ - "1-1" - ], "emea-sau-ecc-1-2018": [ "1-1-3" ], "emea-sau-otcc-1-2022": [ - "1-4", - "1-4-1", - "1-4-1-1" + "1-4-2" ], - "apac-aus-ism-2024-june": [ - "ISM-0732" + "apac-aus-ism-2026-march": [ + "ISM-0732", + "ISM-2004" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "13", - "15" + "27(b)" ], "apac-jpn-ismap": [ "4.5.1.1", @@ -1003,18 +1013,7 @@ "3.2.15.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.5.1", - "5.5.2" - ], - "amaericas-can-osfi-self-assessment": [ - "1.1", - "6.22" + "5.1.4" ], "americas-can-osfi-b13-2022": [ "1.2.1" @@ -1026,7 +1025,7 @@ "title": "Prioritization To Address Evolving Risks & Threats", "family": "PRM", "description": "Mechanisms exist to integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize the organization's exposure to evolving risks and threats.", - "scf_question": "Does the organization integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize the organization's exposure to evolving risks and threats?", + "scf_question": "Does the organization integrate foundational cybersecurity practices with advanced technologies to maintain situation awareness of and minimize its exposure to evolving risks and threats?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -1098,7 +1097,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -1121,11 +1121,46 @@ "4.3.2", "6.3" ], + "general-nist-cswp-39": [ + "6.1" + ], "usa-federal-dow-zt-roadmap-1-1": [ "2.3" ], + "emea-eu-eba-ict-srm-2025": [ + "3.6.1.62", + "3.6.1.66" + ], + "emea-deu-c5-2020": [ + "SA-02-BP3" + ], + "emea-isr-cmo-2-0": [ + "2.D", + "4.1, Stage 4" + ], + "emea-sau-ecc-1-2018": [ + "1-6-4" + ], + "emea-sau-otcc-1-2022": [ + "1-4-2" + ], + "apac-aus-ism-2026-march": [ + "ISM-2020" + ], + "apac-aus-ps-cps-230-2023": [ + "25", + "27(b)" + ], "apac-jpn-ismap": [ "4.5.5.3" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "8.2", + "8.4" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2" ] } }, @@ -1216,7 +1251,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -1352,10 +1388,10 @@ "SA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iii)" + "§ 164.306(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-2" @@ -1377,7 +1413,7 @@ "Article 17.1(l)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)" + "3.2.1.3" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -1388,23 +1424,21 @@ "emea-deu-bsrit-2017": [ "2.3" ], - "emea-isr-cmo-1-0": [ - "17.5" + "emea-isr-cmo-2-0": [ + "4.1, Stage 4" ], - "emea-sau-cscc-1-2019": [ - "1-1" + "emea-sau-otcc-1-2022": [ + "1-4-2" ], - "emea-sau-ecc-1-2018": [ - "1-6-4" + "emea-sau-sama-csf-1-2017": [ + "3.1.1.10" ], - "apac-aus-ism-2024-june": [ - "ISM-0732" + "apac-aus-ism-2026-march": [ + "ISM-0732", + "ISM-2020" ], "apac-aus-ps-cps-230-2023": [ - "25" - ], - "apac-aus-ps-cps-234-2019": [ - "15" + "27(b)" ], "apac-ind-sebi-2024": [ "GV.RR.S4" @@ -1414,11 +1448,7 @@ "4.5.5.3" ], "apac-sgp-mas-trm-2021": [ - "5.2.1", - "5.2.2" - ], - "amaericas-can-osfi-self-assessment": [ - "6.22" + "5.1.4" ], "americas-can-osfi-b13-2022": [ "1.2.1" @@ -1429,8 +1459,8 @@ "control_id": "PRM-04", "title": "Security, Compliance & Resilience In Project Management", "family": "PRM", - "description": "Mechanisms exist 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.", - "scf_question": "Does the organization 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?", + "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.", + "scf_question": "Does the organization 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?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1539,9 +1569,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", + "errata": "- wordsmithed control", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -1664,15 +1695,18 @@ "general-nist-800-161-r1-level-3": [ "CA-2" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A06:2025" ], "general-pci-dss-4-0-1": [ "1.1" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-tisax-6-0-3": [ "1.2.3", "5.3.1" @@ -1716,20 +1750,25 @@ "usa-state-tx-txramp-2-0-level-2": [ "CA-02" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(14)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(f)", - "3.6.1(62)", - "3.6.1(61)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.1(66)" + "3.3.1.10", + "3.3.1.13(f)", + "3.6.1.61", + "3.6.1.62", + "3.6.1.63", + "3.6.1.63(a)", + "3.6.1.63(b)", + "3.6.1.63(c)", + "3.6.1.63(d)", + "3.6.1.63(e)", + "3.6.1.63(f)", + "3.6.1.64", + "3.6.1.65", + "3.6.1.66", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -1745,42 +1784,53 @@ "7.2", "7.3" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.8", - "17.9" - ], "emea-sau-cscc-1-2019": [ - "1-3", - "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-ecc-1-2018": [ - "1-6-1", - "1-6-4" + "1-5-2", + "1-6-1" ], "emea-sau-otcc-1-2022": [ - "1-4-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-74" + "1-4-1-1", + "1-4-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.1.5" + "3.1.5", + "3.1.5.1", + "3.1.5.2", + "3.1.5.2.a", + "3.1.5.2.b", + "3.1.5.2.c", + "3.1.5.2.d", + "3.1.5.2.e", + "3.1.5.2.f" + ], + "emea-esp-decree-311-2022": [ + "Article 16(1)" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1739" ], + "apac-aus-ps-cps-230-2023": [ + "25", + "27(b)" + ], "apac-jpn-ismap": [ "4.5.1.1", "6.1.5", "6.1.5.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.3", + "10.2", + "10.3", + "10.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP28", "HHSP31", @@ -1793,29 +1843,19 @@ ], "apac-sgp-mas-trm-2021": [ "5.1.1", - "5.1.2", - "5.1.3", - "5.1.4", - "5.2.1", - "5.2.2", - "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4", - "5.8.1", - "5.8.2" + "5.1.3" ], - "americas-bra-lgpd-2018": [ - "6.8" - ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "americas-bmu-mba-coc-2020": [ + "5.14" ], "americas-can-osfi-b13-2022": [ "1.2.1", "2.3", "2.3.1", "2.4.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.3.1" ] } }, @@ -1823,8 +1863,8 @@ "control_id": "PRM-05", "title": "Security, Compliance & Resilience Requirements Definition", "family": "PRM", - "description": "Mechanisms exist to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC).", - "scf_question": "Does the organization identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC)?", + "description": "Mechanisms exist to proactively govern Technology Assets, Applications and/or Services (TAAS) by:\n(1) Defining technical security, compliance and resilience requirements; and\n(2) Performing a criticality analysis at predefined decision points in the Secure Development Life Cycle (SDLC).", + "scf_question": "Does the organization proactively govern Technology Assets, Applications and/or Services (TAAS) by:\n(1) Defining technical security, compliance and resilience requirements; and\n(2) Performing a criticality analysis at predefined decision points in the Secure Development Life Cycle (SDLC)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1842,7 +1882,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to identify critical system components and functions by performing a criticality analysis for critical Technology Assets, Applications and/or Services (TAAS) at pre-defined decision points in the Secure Development Life Cycle (SDLC). ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1916,9 +1956,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", + "errata": "- wordsmithed control", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -2053,6 +2094,21 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], + "general-nist-800-172-r3": [ + "03.11.10E", + "03.13.01E", + "03.13.02E", + "03.13.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.10E", + "A.03.13.01E.ODP[01]", + "A.03.13.02E.ODP[01]", + "A.03.13.03E.ODP[01]" + ], "general-nist-800-218": [ "PO.1", "PO.1.1" @@ -2063,9 +2119,6 @@ "general-pci-dss-4-0-1": [ "1.1" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-swift-cscf-2025": [ "2.8", "2.11A" @@ -2103,10 +2156,10 @@ "RA-09" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(ii)" + "§ 164.306(b)(2)(ii)" ], "usa-state-ca-ccpa-cpra-2026": [ "7100(b)" @@ -2115,10 +2168,8 @@ "Article 14.3(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.6.1.64", + "3.6.2.68" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -2132,47 +2183,38 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(a)" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.6" - ], - "emea-qat-pdppl-2020": [ - "11.1", - "11.2", - "11.3", - "11.4", - "11.5", - "11.6", - "11.7", - "11.8" + "emea-deu-bsrit-2017": [ + "7.6" ], "emea-sau-cscc-1-2019": [ - "1-3-1-2", "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-ecc-1-2018": [ - "1-6-1" + "1-6-1", + "2-9-1" ], "emea-sau-otcc-1-2022": [ - "1-4-1", - "1-4-1-1", - "1-4-2" + "1-4-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-43" + "emea-esp-decree-311-2022": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.3 [OP.PL.3]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.2", + "op.pl.3", + "op.exp.1", + "mp.info.4", + "mp.s.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0720", "ISM-1739" ], + "apac-aus-ps-cps-230-2023": [ + "25" + ], "apac-jpn-ismap": [ "4.4.3.1", "4.4.5.2", @@ -2180,7 +2222,11 @@ "6.1.5.2", "14.1.1.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.3", + "10.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP11", "HHSP28", "HHSP31", @@ -2198,22 +2244,13 @@ "12.1.32.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.1.1", "5.1.2", - "5.1.3", - "5.1.4", - "5.3.3", - "5.5.1", - "5.5.2", - "5.6.1", - "5.6.2", - "5.6.3" - ], - "apac-twn-pdpa-2025": [ - "27" + "5.4.2", + "5.4.3", + "5.5.1" ], - "amaericas-can-osfi-self-assessment": [ - "6.7" + "americas-bmu-mba-coc-2020": [ + "5.14" ], "americas-can-osfi-b13-2022": [ "1.2.1", @@ -2223,6 +2260,9 @@ "2.4.3", "2.8" ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -2310,9 +2350,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -2451,12 +2491,15 @@ "general-nist-800-161-r1-level-3": [ "PM-11" ], + "general-nist-800-172-r3": [ + "03.13.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.13.01E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-swift-cscf-2025": [ "2.8", "2.11A" @@ -2505,10 +2548,10 @@ "609.935(e)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(i)" + "§ 164.306(b)(2)(i)" ], "usa-federal-cms-marse-2-0": [ "PM-11", @@ -2519,10 +2562,9 @@ "PM-11" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(51)", - "3.6.1(64)", - "3.6.1(65)", - "3.6.2(68)" + "3.3.2.15", + "3.6.1.64", + "3.6.2.68" ], "emea-eu-dora-2023": [ "Article 8.1" @@ -2530,14 +2572,15 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(a)" ], - "emea-isr-cmo-1-0": [ - "17.5", - "17.6" + "emea-deu-bsrit-2017": [ + "7.6" + ], + "emea-sau-ecc-1-2018": [ + "2-9-1" ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" + "emea-esp-decree-311-2022": [ + "Article 13(2)(a)", + "Article 13(2)(b)" ], "apac-jpn-ismap": [ "4.4.3.1", @@ -2547,6 +2590,9 @@ "13.1.2", "14.1.1.2" ], + "apac-mys-bnm-rmit-2025": [ + "10.2" + ], "apac-nzl-hisf-suppliers-2023": [ "HSUP27" ], @@ -2556,8 +2602,11 @@ "12.1.32.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.5.1", - "5.5.2" + "5.1.2", + "5.5.1" + ], + "americas-bmu-mba-coc-2020": [ + "6.9" ], "americas-can-osfi-b13-2022": [ "1.2.1", @@ -2566,6 +2615,9 @@ "2.4.1", "2.4.3", "2.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.2.1" ] } }, @@ -2589,9 +2641,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2686,7 +2738,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Project & Resource Management", "crosswalks": { @@ -2774,7 +2827,7 @@ "A.6.2.7", "A.6.2.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -2855,9 +2908,6 @@ "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "general-tisax-6-0-3": [ "5.3.1" ], @@ -2930,15 +2980,12 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-03" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(14)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(f)", - "3.5(55)", - "3.6.1(63)(a)", - "3.6.1(63)(b)", - "3.6.1(63)(c)", - "3.6.1(63)(d)", - "3.6.1(63)(e)", - "3.6.1(63)(f)" + "3.3.1.13(f)", + "3.5.55" ], "emea-eu-dora-2023": [ "Article 7(a)", @@ -2954,39 +3001,35 @@ "7.2", "7.3" ], - "emea-isr-cmo-1-0": [ - "17.4", - "17.5", - "17.8" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" - ], "emea-sau-cscc-1-2019": [ - "2-13-4" + "2-13-1" ], "emea-sau-cgiot-2024": [ "1-5-2" ], - "emea-sau-sacs-002-2022": [ - "TPC-74" + "emea-sau-ecc-1-2018": [ + "1-5-3-1", + "1-5-3-2", + "1-5-3-3", + "1-5-3-4" ], - "emea-esp-boe-a-2022-7191": [ - "Article 8 (end)", - "Article 36" + "emea-sau-otcc-1-2022": [ + "1-4-1-1" ], - "emea-esp-decree-311-2022": [ - "36", - "8 (end)" + "emea-sau-sama-csf-1-2017": [ + "3.1.5" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "op.exp.5", + "mp.sw.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1526", "ISM-1739" ], - "apac-aus-ps-cps-234-2019": [ - "21(c)" + "apac-aus-ps-cps-230-2023": [ + "25" ], "apac-ind-sebi-2024": [ "PR.IP.S2" @@ -2995,19 +3038,26 @@ "6.1.5.4", "14.1" ], + "apac-mys-bnm-rmit-2025": [ + "10.5" + ], "apac-sgp-mas-trm-2021": [ "5.1.2", - "5.1.3", - "5.1.4", "5.4.1", - "5.4.2", - "5.4.3", - "5.4.4" + "5.4.4", + "5.5.2", + "5.8.1" + ], + "americas-bmu-mba-coc-2020": [ + "6.20" ], "americas-can-osfi-b13-2022": [ "2.4", "2.4.1", "2.4.3" + ], + "americas-can-osfi-self-assessment-2": [ + "2.4.1" ] } }, @@ -3031,7 +3081,7 @@ "0": "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.", "1": "Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with PRM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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.\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to manage the organizational knowledge of the security, compliance and resilience staff.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with PRM domain capabilities are well-documented and kept current by process owners.\n▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution, etc.).\n▪ 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).\n▪ 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.\n▪ An implemented and operational capability exists to manage the organizational knowledge of the security, compliance and resilience staff.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3105,17 +3155,14 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Project & Resource Management", "crosswalks": { "general-cobit-2019": [ "APO01.08" ], - "general-scf-dpmp-2025": [ - "5.12" - ], "usa-federal-dhs-cisa-cpg-2-0": [ "1.D" ], diff --git a/docs/api/families/QTS.json b/docs/api/families/QTS.json new file mode 100644 index 00000000..23468272 --- /dev/null +++ b/docs/api/families/QTS.json @@ -0,0 +1,3317 @@ +{ + "family_code": "QTS", + "family_name": "Quantum Security", + "control_count": 34, + "controls": [ + { + "control_id": "QTS-01", + "title": "Quantum Risk Governance", + "family": "QTS", + "description": "Mechanisms exist to establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "scf_question": "Does the organization establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-01", + "E-QTS-02" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish an executive-sponsored quantum risk governance structure that institutionalizes quantum risk in the same manner as other enterprise risks by:\n(1) Assigning a named migration lead with defined authority; and\n(2) Treating quantum risk as a standing agenda item in Board of Directors and/or executive leadership meetings.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Awareness of NIST PQC standards (https://csrc.nist.gov/pqc)\n∙ Note: Formal quantum risk governance may not be cost-effective at this size; monitor NIST guidance", + "small": "∙ Designate a named lead responsible for tracking PQC developments\n∙ NIST Post-Quantum Cryptography standards awareness (https://csrc.nist.gov/pqc)", + "medium": "∙ Designated quantum migration lead within CISO function\n∙ NIST PQC standards alignment\n∙ Include quantum risk in enterprise risk register", + "large": "∙ Executive-sponsored quantum risk governance structure\n∙ Named migration lead with defined authority\n∙ NIST PQC and NSA CNSA 2.0 alignment\n∙ Quantum risk as standing agenda item in executive meetings", + "enterprise": "∙ Board-level quantum risk governance structure\n∙ NIST PQC standards and NSA CNSA 2.0 alignment\n∙ Dedicated PQC migration program team\n∙ Quantum risk integrated into enterprise risk management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-01.1", + "title": "Quantum Security Policy", + "family": "QTS", + "description": "Mechanisms exist to establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "scf_question": "Does the organization establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-GOV-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish a formal, documented quantum security policy that:\n(1) Conveys executive management's intent;\n(2) Provides organizational direction and expected behaviors;\n(3) Is reviewed at least annually; and\n(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Reference NIST PQC standards in cryptography policy\n∙ Note: Standalone quantum security policy may not be required at this size", + "small": "∙ Addendum to existing cryptography policy covering quantum risks\n∙ NIST PQC reference (https://csrc.nist.gov/pqc)", + "medium": "∙ Formal quantum security policy\n∙ Annual review cycle aligned to NIST PQC updates\n∙ Integration with cryptography standard", + "large": "∙ Standalone quantum security policy with executive approval\n∙ Annual review and update cycle\n∙ Alignment to NIST PQC, NSA CNSA 2.0 and CISA PQC guidance", + "enterprise": "∙ Enterprise quantum security policy with board endorsement\n∙ Alignment to NIST, NSA, CISA, and applicable regulatory guidance\n∙ Integration with security policy framework" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-01.2", + "title": "Data Shelf-Life Classification for Post-Quantum Cryptography (PQC) Prioritization", + "family": "QTS", + "description": "Mechanisms exist to classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "scf_question": "Does the organization classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-03" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to classify Technology Assets, Applications, Services and Data (TAASD) by confidentiality shelf-life and use that classification as a direct input to Post-Quantum Cryptography (PQC) migration prioritization, including prioritizing data with a shelf-life exceeding the expected PQC arrival horizon.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Identify data with long-term confidentiality requirements (e.g., legal, financial, health records)\n∙ Flag for priority PQC protection", + "medium": "∙ Data classification extended to include confidentiality shelf-life dimension\n∙ Prioritize PQC migration for long-lived sensitive data", + "large": "∙ Formal data shelf-life classification taxonomy\n∙ Integration with data catalog and PQC migration prioritization\n∙ Policy-driven PQC protection for long-lived data", + "enterprise": "∙ Automated data shelf-life classification\n∙ Integration with enterprise data catalog and PQC migration roadmap\n∙ Continuous monitoring of long-lived data for PQC readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-01.3", + "title": "Long-Lived Data Identification", + "family": "QTS", + "description": "Mechanisms exist to identify data with long-lived confidentiality protection requirements.", + "scf_question": "Does the organization identify data with long-lived confidentiality protection requirements?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-03" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to identify data with long-lived confidentiality protection requirements.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Review data retention schedules to identify long-lived sensitive records", + "medium": "∙ Data discovery tools to identify long-lived sensitive data\n∙ Data retention policy integration\n∙ Tag long-lived data in data catalog", + "large": "∙ Automated long-lived data identification via data discovery tools\n∙ Integration with DLP and data catalog\n∙ PQC priority mapping for identified data", + "enterprise": "∙ Enterprise data discovery and classification platform\n∙ Automated long-lived data tagging and PQC risk mapping\n∙ Continuous monitoring of data with long confidentiality requirements" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-01.4", + "title": "Harvest Now, Decrypt Later (HNDL) Mitigation", + "family": "QTS", + "description": "Mechanisms exist to mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control.", + "scf_question": "Does the organization mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-09" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to mitigate Harvest Now, Decrypt Later (HNDL) risk by minimizing an adversary's ability to collect long-lived data through Zero Trust Network Architecture (ZTNA) that enforces:\n(1) Continuous authentication;\n(2) Data microsegmentation;\n(3) Least privilege; and\n(4) Identity-based access control.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Ensure TLS 1.3 is enforced for sensitive data in transit\n∙ Note: Full HNDL mitigation via ZTNA is typically not feasible at this size", + "small": "∙ Enforce TLS 1.3 for all sensitive communications\n∙ Minimize external exposure of long-lived sensitive data", + "medium": "∙ TLS 1.3 enforcement across all external-facing services\n∙ Data access minimization practices\n∙ Zero Trust Network Architecture (ZTNA) planning", + "large": "∙ Zero Trust Network Architecture (ZTNA) implementation\n∙ TLS 1.3 enforcement with forward secrecy\n∙ Identity-based access controls for sensitive data\n∙ Data microsegmentation", + "enterprise": "∙ Enterprise ZTNA platform (e.g., Zscaler, Netskope, Palo Alto Prisma Access)\n∙ Continuous authentication enforcement\n∙ Data microsegmentation with identity-aware access\n∙ HNDL risk monitoring and response program" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-02", + "title": "Cryptographic Agility Risk Assessment (CARA)", + "family": "QTS", + "description": "Mechanisms exist to perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact.", + "scf_question": "Does the organization perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-06" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to perform a Cryptographic Agility Risk Assessment (CARA) that analyzes Technology Assets, Applications, Services and Data (TAASD) to:\n(1) Identify TAASD most vulnerable to quantum-enabled cryptanalytic threats; and\n(2) Prioritize TAASD based on potential business impact.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Inventory of cryptographic algorithms in use\n∙ Identification of quantum-vulnerable algorithms (RSA, ECDSA, DH)", + "medium": "∙ Structured CARA aligned to NIST guidance\n∙ Asset-level mapping of cryptographic algorithm use\n∙ Prioritization by business impact", + "large": "∙ Formal CARA process aligned to NIST IR 8547 or equivalent methodology\n∙ Integration with risk register and PQC migration planning", + "enterprise": "∙ Enterprise CARA program with automated cryptographic discovery\n∙ NIST IR 8547 methodology implementation\n∙ Integration with GRC platform and PQC migration roadmap" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "5" + ] + } + }, + { + "control_id": "QTS-02.1", + "title": "Cryptographic Exception Register", + "family": "QTS", + "description": "Mechanisms exist to govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date.", + "scf_question": "Does the organization govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-07" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Inventories are manual (e.g., spreadsheets).\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ Quantum security risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to govern each Post-Quantum Cryptography (PQC) deviation in a formal cryptographic exception register that contains, at a minimum:\n(1) Asset and/or process owner(s);\n(2) Compensating control(s);\n(3) Planned remediation date; and\n(4) Re-evaluation date.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Simple exception register for known quantum-vulnerable algorithm uses", + "medium": "∙ Cryptographic exception register with owner, compensating controls, and remediation dates\n∙ Integration with risk register", + "large": "∙ Formal cryptographic exception register\n∙ GRC platform integration\n∙ Regular review and escalation process for aged exceptions", + "enterprise": "∙ Enterprise cryptographic exception register within GRC platform\n∙ Automated exception tracking and escalation\n∙ Integration with PQC migration roadmap and compliance reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-02.2", + "title": "Compensating Controls for Quantum-Vulnerable Systems", + "family": "QTS", + "description": "Mechanisms exist to implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "scf_question": "Does the organization implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with QTS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on quantum security-related risk.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to implement short-term compensating measures for Technology Assets, Applications and Services (TAAS) that cannot be migrated to Post-Quantum Cryptography (PQC) on the planned schedule, (e.g., network segmentation, additional pre-shared-key layers, reduced key lifetimes, out-of-band key transport and data minimization).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Network isolation of legacy systems using quantum-vulnerable algorithms\n∙ Shorten certificate validity periods", + "small": "∙ Network segmentation of quantum-vulnerable systems\n∙ Reduce key lifetimes for quantum-vulnerable certificates", + "medium": "∙ Network segmentation and additional authentication for quantum-vulnerable systems\n∙ Shortened key validity periods\n∙ Out-of-band key transport where applicable", + "large": "∙ Network micro-segmentation of quantum-vulnerable systems\n∙ Shortened key lifetimes and certificate validity periods\n∙ Pre-shared key (PSK) layers on quantum-vulnerable links\n∙ Data minimization on quantum-vulnerable paths", + "enterprise": "∙ Automated micro-segmentation of quantum-vulnerable systems\n∙ Enterprise PSK and data minimization controls\n∙ Continuous monitoring of quantum-vulnerable system exposure\n∙ Integration with PQC migration prioritization" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-02.3", + "title": "Crypto Agility Maturity Assessment", + "family": "QTS", + "description": "Mechanisms exist to measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "scf_question": "Does the organization measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to measure progress in adopting cryptographic agility using defined maturity criteria to support resilience against evolving Post-Quantum Cryptography (PQC) requirements and threats.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Self-assessment against basic cryptographic agility criteria\n∙ NIST PQC readiness checklist", + "medium": "∙ Crypto agility maturity assessment against defined criteria\n∙ NIST or CISA PQC maturity model\n∙ Integration with annual security assessments", + "large": "∙ Formal crypto agility maturity assessment using NIST or CISA PQC maturity framework\n∙ Annual assessment with improvement roadmap", + "enterprise": "∙ Enterprise crypto agility maturity program\n∙ Third-party validated maturity assessments\n∙ Continuous maturity monitoring via GRC platform\n∙ Board-level reporting on crypto agility progress" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "6.5" + ] + } + }, + { + "control_id": "QTS-03", + "title": "Post-Quantum Cryptography Agility Plan (PSCAP)", + "family": "QTS", + "description": "Mechanisms exist to develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms.", + "scf_question": "Does the organization develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to develop a risk-prioritized Post-Quantum Cryptography Agility Plan (PQCAP) that:\n(1) Enables cryptographic agility;\n(2) Aligns with evolving security standards; and\n(3) Defines the approach for selecting and implementing PQC algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Basic PQC transition roadmap aligned to NIST PQC standards\n∙ NIST PQCAP guidance (https://csrc.nist.gov/pqc)", + "medium": "∙ Documented PQCAP aligned to NIST standards\n∙ Risk-prioritized migration roadmap\n∙ Integration with enterprise risk management", + "large": "∙ Formal PQCAP with executive sponsorship\n∙ Risk-prioritized migration with milestones\n∙ NIST PQC and NSA CNSA 2.0 alignment\n∙ Annual plan refresh", + "enterprise": "∙ Enterprise PQCAP with board visibility\n∙ Dedicated PQC program office\n∙ NIST, NSA CNSA 2.0, and CISA PQC guidance alignment\n∙ Integration with enterprise architecture and GRC" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "3", + "5", + "5.3", + "6" + ], + "apac-aus-ism-2026-march": [ + "ISM-1917", + "ISM-2073" + ] + } + }, + { + "control_id": "QTS-03.1", + "title": "Post-Quantum Cryptography (PQC) Transition Planning & Hybrid Mode Support", + "family": "QTS", + "description": "Mechanisms exist to allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period.", + "scf_question": "Does the organization allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-11", + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to allocate resources to:\n(1) Transition legacy Technology Assets, Applications and/or Services (TAAS) to Post-Quantum Cryptography (PQC) algorithms; and\n(2) Support hybrid cryptography during a defined transition period.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor TLS library vendor support for PQC/hybrid modes\n∙ Plan transition for highest-risk systems first", + "medium": "∙ PQC algorithm support assessment for key systems\n∙ Hybrid cryptography pilot for critical services\n∙ Vendor roadmap review for PQC support", + "large": "∙ Hybrid cryptography deployment for critical services\n∙ TLS 1.3 with hybrid PQC key exchange pilot\n∙ Legacy system migration planning and resource allocation", + "enterprise": "∙ Enterprise hybrid cryptography deployment program\n∙ FIPS 140-3 validated PQC module adoption\n∙ Hybrid mode support across all external-facing services\n∙ Automated legacy system discovery and migration tracking" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-03.2", + "title": "Post-Quantum Cryptography (PQC) Migration Progress Oversight", + "family": "QTS", + "description": "Mechanisms exist to establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership.", + "scf_question": "Does the organization establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish reportable metrics that:\n(1) Measure migration progress against the Post-Quantum Cryptography Agility Plan (PQCAP); and\n(2) Report progress periodically to executive leadership.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Note: Typically not required at this size; document any PQC migration progress informally", + "medium": "∙ PQC migration progress metrics\n∙ Inclusion in security program status reports", + "large": "∙ Executive dashboard for PQC migration progress\n∙ Milestone-based reporting aligned to PQCAP\n∙ Regular reporting to security leadership", + "enterprise": "∙ Board-level PQC migration progress reporting\n∙ Automated migration tracking in GRC platform\n∙ KPIs aligned to PQCAP milestones\n∙ Regulatory compliance reporting on PQC readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-03.3", + "title": "Post-Quantum Cryptography (PQC) Supply Chain Visibility", + "family": "QTS", + "description": "Mechanisms exist to require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "scf_question": "Does the organization require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04", + "E-QTS-13" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to require vendors to disclose Post-Quantum Cryptography (PQC) support roadmaps that include:\n(1) Identification of PQC-related limitations; and\n(2) Supported upgrade paths to ensure long-lived devices (e.g., OT, IoT and embedded systems) can support PQC capabilities.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Request PQC support roadmaps from key technology vendors\n∙ Include PQC readiness in vendor RFPs", + "medium": "∙ Vendor PQC readiness assessments as part of TPRM\n∙ Contractual requirements for PQC roadmap disclosure\n∙ Vendor questionnaires on quantum readiness", + "large": "∙ Formal vendor PQC disclosure requirements\n∙ PQC readiness as part of third-party risk assessments\n∙ Vendor roadmap tracking for critical suppliers", + "enterprise": "∙ Enterprise vendor PQC supply chain program\n∙ Automated vendor PQC tracking in TPRM platform\n∙ Contractual PQC disclosure requirements for all critical vendors\n∙ Regular supply chain quantum risk reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-03.4", + "title": "Post-Quantum Cryptography (PQC) Supply Chain Flow-Down Requirements", + "family": "QTS", + "description": "Mechanisms exist to require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "scf_question": "Does the organization require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-CPL-01" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to require vendors to support Post-Quantum Cryptography (PQC) migration, including flow-down requirements to subcontractors, suppliers and third-party components.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "medium": "∙ Include PQC flow-down requirements in new vendor contracts\n∙ Reference NIST PQC standards in contract language", + "large": "∙ Formal PQC flow-down contract requirements\n∙ Supplier compliance verification\n∙ Integration with third-party risk management", + "enterprise": "∙ Enterprise PQC flow-down program\n∙ Automated contract requirement tracking\n∙ Subcontractor PQC compliance monitoring\n∙ Integration with supply chain risk management platform" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-04", + "title": "Post-Quantum Cryptography (PQC) Discovery & Visibility", + "family": "QTS", + "description": "Mechanisms exist to gain situational awareness into the organization’s current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques.", + "scf_question": "Does the organization gain situational awareness into its current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to gain situational awareness into the organization’s current cryptographic landscape through a formal discovery process that uses a combination of:\n(1) Automated tools; and\n(2) Manual techniques.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Manual cryptographic algorithm inventory\n∙ Free scanning tools for common quantum-vulnerable implementations", + "medium": "∙ Automated cryptographic discovery tools\n∙ Cryptographic inventory as part of vulnerability management\n∙ NIST guidance on cryptographic discovery (https://csrc.nist.gov/pqc)", + "large": "∙ Automated cryptographic discovery and inventory platform\n∙ Integration with asset management and vulnerability scanning\n∙ Regular cryptographic posture reporting", + "enterprise": "∙ Enterprise cryptographic discovery platform\n∙ Continuous cryptographic inventory maintenance\n∙ Integration with GRC, asset management, and SIEM\n∙ Automated quantum exposure reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "5" + ] + } + }, + { + "control_id": "QTS-04.1", + "title": "Post-Quantum Cryptography (PQC) Asset Inventory", + "family": "QTS", + "description": "Mechanisms exist to maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "scf_question": "Does the organization maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-04" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain a current inventory of cryptographic assets that includes:\n(1) Algorithms (asymmetric and symmetric);\n(2) Key lengths;\n(3) Libraries;\n(4) Protocols;\n(5) Associated Technology Assets, Applications and/or Services (TAAS) utilizing the cryptography; and\n(6) Federal Information Processing Standards (FIPS) validation status from the Cryptographic Module Validation Program (CMVP), including certificate number, if applicable.", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Spreadsheet-based cryptographic asset inventory\n∙ Document algorithms, key lengths, and associated systems", + "medium": "∙ Structured cryptographic asset inventory\n∙ FIPS validation status tracking\n∙ Integration with overall asset inventory", + "large": "∙ Formal cryptographic asset inventory with automated updates\n∙ FIPS 140-3 validation tracking\n∙ Integration with vulnerability management and asset management", + "enterprise": "∙ Enterprise cryptographic asset inventory platform\n∙ Automated discovery and inventory maintenance\n∙ FIPS 140-3 validation status integration\n∙ Continuous inventory accuracy monitoring" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-04.2", + "title": "Cryptographic Bill of Materials (CBOM)", + "family": "QTS", + "description": "Mechanisms exist to develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing the organization's cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols.", + "scf_question": "Does the organization develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing its cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-05" + ], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to develop and maintain a Cryptographic Bill of Materials (CBOM) by analyzing the organization's cryptographic architecture, including:\n(1) Hardware;\n(2) Firmware;\n(3) Software modules; and\n(4) Communication protocols.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "medium": "∙ Software Composition Analysis (SCA) tools to identify cryptographic library usage\n∙ Manual CBOM for critical applications", + "large": "∙ SCA platform with cryptographic library identification\n∙ CBOM generation for critical systems\n∙ Integration with SBOM processes", + "enterprise": "∙ Enterprise CBOM generation platform\n∙ Integration with SCA and SBOM tooling\n∙ Automated cryptographic dependency tracking\n∙ CBOM as input to PQC migration prioritization" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2082", + "ISM-2083" + ] + } + }, + { + "control_id": "QTS-04.3", + "title": "Post-Quantum Cryptography Exposure", + "family": "QTS", + "description": "Mechanisms exist to maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "scf_question": "Does the organization maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-10" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ The IT department establishes, maintains and updates an inventory that contains a listing of all organizational-owned TAASD, at a minimum covering common devices (e.g., laptops, workstations and servers). Encryption inventories are limited.\n▪ Inventories may be manual (e.g., spreadsheets) or automated.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain a current inventory of Technology Assets, Applications and/or Services (TAAS) with Post-Quantum Cryptography (PQC) exposure, including:\n(1) Public key algorithms vulnerable to Cryptographically Relevant Quantum Computers (CRQCs);\n(2) Long-lived keys and certificates (e.g., CA roots, firmware signing keys, etc.); and\n(3) TAAS that cannot easily adopt PQC upgrades (e.g., embedded, RTOS, etc.).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Identify systems using quantum-vulnerable public key algorithms (RSA, ECDSA, DH)\n∙ Prioritize based on data sensitivity", + "medium": "∙ Inventory of systems with PQC exposure\n∙ Risk-based prioritization of exposed systems\n∙ Integration with vulnerability management", + "large": "∙ Formal PQC exposure inventory\n∙ Automated scanning for quantum-vulnerable algorithm use\n∙ Risk-prioritized remediation planning", + "enterprise": "∙ Continuous PQC exposure monitoring\n∙ Enterprise scanning for quantum-vulnerable implementations\n∙ Automated risk prioritization and remediation tracking\n∙ Board-level PQC exposure reporting" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-05", + "title": "Quantum Security Awareness", + "family": "QTS", + "description": "Mechanisms exist to deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles.", + "scf_question": "Does the organization deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-SAT-05" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ 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 QTS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to deliver differentiated quantum security awareness and training content to:\n(1) General workforce;\n(2) Technical roles; and\n(3) Leadership roles.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Include quantum threat awareness in annual security training\n∙ NIST PQC awareness resources (https://csrc.nist.gov/pqc)", + "medium": "∙ Differentiated quantum security awareness content by role\n∙ General workforce awareness module\n∙ Technical team PQC training", + "large": "∙ Role-specific quantum security awareness program (workforce, technical, leadership)\n∙ Integration with annual security awareness platform", + "enterprise": "∙ Enterprise quantum security awareness program\n∙ Differentiated content for workforce, technical, and leadership roles\n∙ Annual training refresh aligned to NIST and regulatory updates\n∙ Integration with Learning Management System (LMS)" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-05.1", + "title": "Quantum Threat Intelligence Monitoring", + "family": "QTS", + "description": "Mechanisms exist to maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists.", + "scf_question": "Does the organization maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-10", + "E-THR-03" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to maintain an ongoing quantum threat intelligence function that monitors:\n(1) Cryptanalytic threat developments;\n(2) Quantum computing capability advances; and\n(3) NIST and/or regulatory updates to approved algorithm lists.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subscribe to NIST and CISA PQC update notifications (https://csrc.nist.gov/pqc)", + "small": "∙ NIST and CISA PQC update subscriptions\n∙ Relevant industry group newsletters or alerts", + "medium": "∙ Dedicated quantum threat intelligence monitoring\n∙ NIST, CISA, and NSA PQC guidance tracking\n∙ Industry-specific quantum security working groups", + "large": "∙ Quantum threat intelligence function within threat intelligence program\n∙ Monitoring of cryptanalytic advances and quantum computing milestones\n∙ NIST algorithm update tracking", + "enterprise": "∙ Dedicated quantum threat intelligence capability\n∙ Monitoring of academic, regulatory, and vendor quantum developments\n∙ Integration with enterprise threat intelligence platform\n∙ Regular quantum threat briefings to leadership" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-05.2", + "title": "Collaboration & Information Sharing", + "family": "QTS", + "description": "Mechanisms exist to ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk.", + "scf_question": "Does the organization ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to ensure stakeholder participation in sector-appropriate quantum security forums to:\n(1) Detect emerging threats earlier; and\n(2) Reduce systemic ecosystem risk.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor outputs from sector-specific quantum security working groups\n∙ CISA and NIST information-sharing resources", + "medium": "∙ Participation in sector-appropriate quantum security working groups\n∙ ISAC membership where relevant\n∙ CISA PQC working group engagement", + "large": "∙ Active participation in quantum security forums and ISACs\n∙ NIST PQC working group engagement\n∙ Cross-sector information sharing on quantum threats", + "enterprise": "∙ Enterprise participation in quantum security forums\n∙ ISAC and government information sharing partnerships\n∙ Active contribution to quantum security standards development\n∙ Public-private partnership engagement on quantum readiness" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06", + "title": "Crypto-Agility Architecture", + "family": "QTS", + "description": "Mechanisms exist to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "scf_question": "Does the organization validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Use cloud-native cryptographic services with configurable algorithm support\n∙ Avoid hardcoded cryptographic algorithm dependencies", + "medium": "∙ Design systems for cryptographic algorithm replaceability\n∙ Crypto-agility requirements in architecture reviews\n∙ Abstraction of cryptographic operations from application logic", + "large": "∙ Crypto-agility architecture validation in design reviews\n∙ Cryptographic abstraction layer requirements\n∙ Support for PQC key and signature sizes in protocols and libraries", + "enterprise": "∙ Enterprise crypto-agility architecture program\n∙ Formal agility validation across protocols, libraries and hardware\n∙ Cryptographic abstraction APIs enforced organization-wide\n∙ Automated architecture compliance checking" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "4", + "5.4", + "6.2", + "6.3", + "6.4" + ] + } + }, + { + "control_id": "QTS-06.1", + "title": "Entropy Source & Random Bit Generation", + "family": "QTS", + "description": "Mechanisms exist to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation.", + "scf_question": "Does the organization use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):\n(1) Key generation;\n(2) Nonce generation;\n(3) Probabilistic algorithm inputs; and\n(4) Key validation.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use OS and cloud provider cryptographically secure random number generators\n∙ Avoid custom entropy implementations", + "small": "∙ Cryptographically secure PRNG from OS or validated cryptographic libraries\n∙ NIST SP 800-90B guidance (https://csrc.nist.gov)", + "medium": "∙ FIPS 140-3 validated entropy sources\n∙ Hardware Security Module (HSM) with validated RNG\n∙ NIST SP 800-90B compliance", + "large": "∙ FIPS 140-3 validated HSMs for key generation\n∙ Validated entropy sources aligned to NIST SP 800-90B\n∙ Enterprise key management platform", + "enterprise": "∙ Enterprise HSM infrastructure with FIPS 140-3 validated entropy\n∙ Quantum random number generators (QRNG) for enhanced entropy\n∙ Centralized key management platform\n∙ Continuous entropy source validation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.2", + "title": "Stateful Hash-Based Signatures for Firmware & Code Signing", + "family": "QTS", + "description": "Mechanisms exist to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases.", + "scf_question": "Does the organization enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:\n(1) Firmware signing;\n(2) Secure boot signing; and\n(3) Other long-lifetime code-signing use cases.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use vendor-managed firmware signing", + "small": "∙ Use vendor-managed firmware signing", + "medium": "∙ Review code signing infrastructure for quantum vulnerability\n∙ Plan migration to hash-based signatures for critical firmware\n∙ NIST SP 800-208 guidance (https://csrc.nist.gov)", + "large": "∙ Hash-based signature scheme deployment for firmware signing\n∙ NIST SP 800-208 compliance for firmware and code signing\n∙ State-management controls to prevent key reuse", + "enterprise": "∙ Enterprise hash-based signature infrastructure for firmware and code signing\n∙ NIST SP 800-208 compliant implementation\n∙ Automated state management to prevent one-time key reuse\n∙ HSM-backed hash-based key management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.3", + "title": "Approved Post-Quantum Cryptography (PQC) Algorithm Use", + "family": "QTS", + "description": "Mechanisms exist to define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).", + "scf_question": "Does the organization define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to define:\n(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and\n(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).", + "4": "Quantum Security (QTS) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Monitor NIST PQC algorithm approvals (https://csrc.nist.gov/pqc)\n∙ Adopt approved PQC algorithms as available in consumed services", + "small": "∙ Reference NIST PQC approved algorithms in cryptography policy\n∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)", + "medium": "∙ Define approved PQC algorithm list\n∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) adoption\n∙ FIPS 140-3 validated module requirements", + "large": "∙ Formal approved PQC algorithm standard\n∙ NIST FIPS 203/204/205 compliant implementations\n∙ Required validation levels in cryptography policy\n∙ Algorithm approval workflow for exceptions", + "enterprise": "∙ Enterprise approved PQC algorithm governance\n∙ NIST FIPS 203/204/205 and CNSA 2.0 alignment\n∙ Automated algorithm compliance enforcement\n∙ Integration with cryptographic exception register" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1990", + "ISM-1991", + "ISM-1992", + "ISM-1993", + "ISM-1994", + "ISM-1995" + ] + } + }, + { + "control_id": "QTS-06.4", + "title": "Post-Quantum Cryptography (PQC) Validation Requirements", + "family": "QTS", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use cloud provider services with FIPS 140-3 validated cryptographic modules\n∙ Prefer managed services over self-hosted cryptography", + "small": "∙ Use FIPS 140-3 validated cryptographic libraries and services\n∙ NIST CMVP validation list (https://csrc.nist.gov/projects/cryptographic-module-validation-program)", + "medium": "∙ FIPS 140-3 validated module requirements for cryptographic operations\n∙ Track NIST CMVP PQC validation certificates\n∙ Policy mandate for validated modules where applicable", + "large": "∙ Enterprise policy requiring FIPS 140-3 validated modules\n∙ Validation tracking in cryptographic asset inventory\n∙ HSM with FIPS 140-3 validation for key management", + "enterprise": "∙ Enterprise FIPS 140-3 validation requirement enforcement\n∙ Automated validation status tracking in cryptographic inventory\n∙ HSM infrastructure with FIPS 140-3 Level 3 validation\n∙ Continuous compliance monitoring for cryptographic module validation" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.5", + "title": "Deprecated Cryptographic Algorithms", + "family": "QTS", + "description": "Mechanisms exist to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.", + "scf_question": "Does the organization identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-08" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Disable RC4, DES, 3DES and MD5 in systems and services\n∙ Enforce TLS 1.2 minimum (disable TLS 1.0/1.1)\n∙ Reference NIST SP 800-131A for deprecated algorithm guidance", + "small": "∙ Deprecated algorithm disablement per NIST SP 800-131A\n∙ TLS 1.2 minimum enforcement\n∙ Retire RSA-1024 and similar weak key sizes", + "medium": "∙ Deprecated algorithm disablement across all systems\n∙ NIST SP 800-131A and SP 800-57 compliance\n∙ Vulnerability scanning for deprecated algorithm detection", + "large": "∙ Formal deprecated algorithm disablement program\n∙ Automated scanning for deprecated cryptographic use\n∙ NIST SP 800-131A compliance tracking", + "enterprise": "∙ Enterprise deprecated algorithm removal program\n∙ Automated detection and alerting for deprecated algorithm use\n∙ NIST SP 800-131A and CNSA 2.0 compliance enforcement\n∙ Continuous monitoring for deprecated algorithm introduction" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "general-nist-cswp-39": [ + "5.2" + ] + } + }, + { + "control_id": "QTS-06.6", + "title": "Post-Quantum Cryptography (PQC) Key Management", + "family": "QTS", + "description": "Mechanisms exist to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources.", + "scf_question": "Does the organization manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:\n(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;\n(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and\n(3) Ensuring key generation uses quantum-safe entropy sources.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Shorten TLS certificate validity periods (e.g., 90-day certificates)\n∙ Let's Encrypt for automated short-lived certificate management (https://letsencrypt.org)", + "small": "∙ 90-day certificate validity enforcement\n∙ Automated certificate lifecycle management\n∙ Let's Encrypt or ACME protocol (https://letsencrypt.org)", + "medium": "∙ Shortened certificate validity periods per PQC guidance\n∙ Certificate lifecycle management platform\n∙ PKI preparation for PQC roots of trust", + "large": "∙ Enterprise certificate lifecycle management with shortened validity periods\n∙ PKI infrastructure preparation for PQC transition\n∙ HSM-backed key generation with quantum-safe entropy", + "enterprise": "∙ Enterprise PKI with PQC-ready architecture\n∙ Automated certificate lifecycle management (e.g., Venafi, Keyfactor)\n∙ HSM infrastructure with quantum-safe entropy sources\n∙ Dual-root hybrid trust model support" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.7", + "title": "Quantum-Safe Public Key Infrastructure (PKI) Transition", + "family": "QTS", + "description": "Mechanisms exist to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.", + "scf_question": "Does the organization transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Rely on cloud provider and CA/Browser Forum quantum-safe transitions", + "small": "∙ Monitor CA/Browser Forum and browser vendor PQC adoption timelines\n∙ Plan reliance on public CA quantum-safe transition", + "medium": "∙ Assess internal PKI for PQC transition readiness\n∙ Evaluate hybrid certificate support in PKI platforms\n∙ Certificate authority PQC roadmap review", + "large": "∙ Internal PKI PQC transition plan\n∙ Hybrid certificate deployment for critical services\n∙ Trust anchor migration planning to quantum-safe algorithms", + "enterprise": "∙ Enterprise quantum-safe PKI transition program\n∙ Hybrid certificate infrastructure deployment\n∙ Trust anchor migration to NIST FIPS 203/204/205 algorithms\n∙ Integration with enterprise certificate lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.8", + "title": "Algorithm Negotiation Integrity", + "family": "QTS", + "description": "Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts.", + "scf_question": "Does the organization configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:\n(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);\n(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and\n(3) Monitoring for downgrade attempts.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Enforce TLS 1.3 (includes transcript integrity protection)\n∙ Disable TLS 1.0/1.1 and weak cipher suites", + "small": "∙ TLS 1.3 enforcement\n∙ Disable deprecated cipher suites\n∙ Monitor for TLS downgrade attempts via web application firewall", + "medium": "∙ TLS 1.3 with strong cipher suite enforcement\n∙ Monitoring for algorithm downgrade attempts\n∙ Disallow classical-only cipher suite negotiation where PQC is deployed", + "large": "∙ TLS 1.3 enforcement with integrity-protected handshake\n∙ Algorithm downgrade monitoring and alerting\n∙ Cipher suite allowlisting across enterprise TLS infrastructure", + "enterprise": "∙ Enterprise TLS cipher suite governance with automated enforcement\n∙ Algorithm negotiation integrity monitoring at scale\n∙ Automated detection of downgrade attempts\n∙ Integration with network security monitoring and SIEM" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-06.9", + "title": "Hybrid / Composite Cryptography", + "family": "QTS", + "description": "Mechanisms exist to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.", + "scf_question": "Does the organization leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:\n(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);\n(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and\n(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Monitor TLS library and browser vendor hybrid PQC support\n∙ Plan adoption of hybrid modes when widely available", + "medium": "∙ Pilot hybrid cryptography for highest-risk external-facing services\n∙ IETF hybrid draft standards monitoring\n∙ Vendor hybrid mode support assessment", + "large": "∙ Hybrid cryptography deployment for critical services\n∙ ECDH + ML-KEM hybrid KEM support\n∙ Hybrid certificate testing and deployment", + "enterprise": "∙ Enterprise hybrid cryptography deployment program\n∙ Hybrid KEM (ECDH + ML-KEM) and hybrid signatures (ECDSA + ML-DSA)\n∙ PKI infrastructure supporting dual-key/dual-certificate models\n∙ Plan for classical algorithm sunset post-PQC confidence" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-1996" + ] + } + }, + { + "control_id": "QTS-06.10", + "title": "Cryptographic Application Programming Interface (API) Abstraction", + "family": "QTS", + "description": "Mechanisms exist to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "scf_question": "Does the organization use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Use established cryptographic libraries with abstraction (e.g., OpenSSL, BouncyCastle)\n∙ Avoid direct algorithm calls; use library-level interfaces", + "medium": "∙ Cryptographic abstraction requirements in development standards\n∙ Use of crypto-agility compatible libraries\n∙ Abstract cryptographic operations from application code", + "large": "∙ Enterprise cryptographic API abstraction standard\n∙ Use of PKCS#11 or equivalent for hardware abstraction\n∙ Crypto abstraction layer in enterprise development frameworks", + "enterprise": "∙ Enterprise cryptographic API abstraction framework\n∙ Universal cryptographic interface standard across all applications\n∙ PKCS#11 and provider-based abstraction architecture\n∙ Automated compliance checking for cryptographic abstraction" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-07", + "title": "Cryptographic Incident Response (Emergency Algorithm Transition)", + "family": "QTS", + "description": "Mechanisms exist to establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios.", + "scf_question": "Does the organization establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [ + "E-QTS-12" + ], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to establish the capability to respond to the compromise or disallowance of a Post-Quantum Cryptography (PQC) or classical algorithm on a compressed timeline, including:\n(1) Pre-identified algorithm alternates;\n(2) Tested rollback and roll-forward procedures;\n(3) Customer and/or counterparty communication templates; and\n(4) Incident response rehearsals against defined scenarios.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Maintain vendor and CA contacts for certificate revocation emergencies\n∙ Basic plan for replacing compromised certificates", + "medium": "∙ Emergency certificate replacement procedures\n∙ Pre-identified algorithm alternates in security runbook\n∙ Integration with incident response plan", + "large": "∙ Formal cryptographic incident response plan\n∙ Pre-identified algorithm alternates with tested rollback procedures\n∙ Customer/counterparty communication templates\n∙ Integration with enterprise incident response", + "enterprise": "∙ Enterprise cryptographic incident response program\n∙ Tested emergency algorithm transition procedures\n∙ 24/7 incident response capability for cryptographic emergencies\n∙ Regular cryptographic incident response exercises" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + }, + { + "control_id": "QTS-08", + "title": "PQC Implementation Validation & Interoperability Testing", + "family": "QTS", + "description": "Mechanisms exist to validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions.", + "scf_question": "Does the organization validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Quantum Security (QTS) 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:\n▪ Policies and standards associated with QTS domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 QTS 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).\n▪ An implemented and operational capability exists to validate that each Post-Quantum Cryptography (PQC) implementation:\n(1) Meets functional and cryptographic requirements;\n(2) Is interoperable with counterparties and successors;\n(3) Meets performance criteria for its use case; and\n(4) Documents test results and exceptions.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "small": "∙ Verify PQC implementations using NIST test vectors (https://csrc.nist.gov/pqc)\n∙ Use FIPS 140-3 validated modules where available", + "medium": "∙ PQC implementation testing using NIST test vectors\n∙ Interoperability testing with key counterparties\n∙ FIPS 140-3 validated module requirement", + "large": "∙ Formal PQC implementation validation program\n∙ Interoperability testing with counterparties and successors\n∙ Performance testing for PQC use cases\n∙ Test result documentation", + "enterprise": "∙ Enterprise PQC implementation validation framework\n∙ Automated test vector validation\n∙ Continuous interoperability testing with ecosystem partners\n∙ Third-party validation for critical implementations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-16", + "MT-17", + "MT-18", + "MT-28" + ], + "errata": "- new control - QTS domain", + "family_name": "Quantum Security", + "crosswalks": {} + } + ] +} \ No newline at end of file diff --git a/docs/api/families/RSK.json b/docs/api/families/RSK.json index e89a1612..613a939c 100644 --- a/docs/api/families/RSK.json +++ b/docs/api/families/RSK.json @@ -1,14 +1,14 @@ { "family_code": "RSK", "family_name": "Risk Management", - "control_count": 32, + "control_count": 33, "controls": [ { "control_id": "RSK-01", "title": "Risk Management Program", "family": "RSK", - "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls.", - "scf_question": "Does the organization facilitate the implementation of strategic, operational and tactical risk management controls?", + "description": "Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) The organization's Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices.", + "scf_question": "Does the organization facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:\n(1) its Enterprise Risk Management (ERM); and\n(2) Industry-recognized cybersecurity risk management practices?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -123,8 +123,10 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Risk Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -371,9 +373,12 @@ ], "general-nist-800-171-r3": [ "03.11.01.a", - "03.17.01.a" + "03.17.01.a", + "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", "A.03.17.03.b" ], "general-nist-csf-2-0": [ @@ -400,9 +405,6 @@ "general-pci-dss-4-0-1": [ "12.3" ], - "general-scf-dpmp-2025": [ - "9.0" - ], "general-tisax-6-0-3": [ "1.4.1" ], @@ -465,12 +467,12 @@ "314.4(b)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(a)(3)", - "164.306(b)(2)(iv)" + "§ 164.306(a)(3)", + "§ 164.306(b)(2)(iv)" ], "usa-federal-irs-1075-2021": [ "PM-9", @@ -526,15 +528,14 @@ "Article 17.1(g)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(7)", - "3.3.1(10)", - "3.3.1(13)(a)", - "3.3.1(13)(b)", - "3.3.1(13)(c)", - "3.3.1(13)(d)", - "3.3.1(13)(e)", - "3.3.1(13)(f)", - "3.3.1(14)" + "3.2.3.7", + "3.3.1.10", + "3.3.1.13", + "3.3.1.13(d)", + "3.3.1.13(e)", + "3.3.1.13(f)", + "3.3.1.14", + "3.3.4.23" ], "emea-eu-dora-2023": [ "Article 6.1", @@ -578,37 +579,20 @@ "7.1", "7.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "3.1", "3.2", - "3.3", - "3.4", - "3.5", - "3.6", - "3.7", - "3.8", - "3.9", - "3.10", - "3.11", - "12.3" + "3.5" ], "emea-deu-c5-2020": [ - "OIS-06" + "OIS-06", + "OIS-07" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.1", - "2.2" + "emea-isr-cmo-2-0": [ + "3" ], "emea-sau-cscc-1-2019": [ - "1-2" + "1-2-1" ], "emea-sau-cgiot-2024": [ "1-4-1" @@ -619,26 +603,38 @@ "1-5-4" ], "emea-sau-otcc-1-2022": [ - "1-3", - "1-3-1", - "1-3-1-1" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "1-3-1" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 7.1", - "Article 7.2" + "3.2.1", + "3.2.1.1-1", + "3.2.1.2-1", + "3.2.1.3-1", + "3.2.1.4-1", + "3.2.1.5", + "3.2.1.5.a", + "3.2.1.5.b", + "3.2.1.5.c", + "3.2.1.6", + "3.2.1.6.a", + "3.2.1.6.b", + "3.2.1.6.c", + "3.2.1.6.d", + "3.2.1.7", + "3.2.1.8", + "3.2.1.8.a", + "3.2.1.8.b", + "3.2.1.8.c", + "3.2.1.8.d" ], "emea-esp-decree-311-2022": [ - "7.1", - "7.2" + "Article 7(2)", + "Article 12(6)(b)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.if.3", + "mp.if.5", + "mp.if.6" ], "emea-gbr-caf-4-0": [ "A2", @@ -664,26 +660,12 @@ "1201", "1204" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0726" ], "apac-aus-ps-cps-230-2023": [ - "12(a)", - "12(c)", - "13", - "16(a)", - "16(b)", - "16(c)", - "16(d)", - "16(e)", - "16(f)", - "17", - "18", - "19(a)", - "19(b)", - "19(c)", - "19(d)", - "19(e)" + "16", + "16(d)" ], "apac-ind-sebi-2024": [ "GV.RM.S1" @@ -693,7 +675,14 @@ "4.5.5.2", "4.8.1.1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.2", + "9.1", + "9.2", + "9.3", + "11.3" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP30", "HML30" ], @@ -708,20 +697,16 @@ "5.3.9.C.01" ], "apac-sgp-mas-trm-2021": [ + "3.1.4", + "3.1.7(a)", "4.1.1", - "4.1.2", + "4.1.4", + "4.1.4(d)", "4.1.5" ], "americas-bmu-mba-coc-2020": [ "5.3", - "5.8" - ], - "amaericas-can-osfi-self-assessment": [ - "1.3", - "6.4", - "6.8", - "6.16", - "6.24" + "5.11-BP1" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -729,9 +714,15 @@ "1.3.2", "3.1.1" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.1", + "1.3.2", + "3.1.8" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", - "03.17.01.A" + "03.17.01.A", + "03.17.03.B" ] } }, @@ -758,7 +749,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify:\n(1) Assumptions affecting risk assessments, risk response and risk monitoring;\n(2) Constraints affecting risk assessments, risk response and risk monitoring;\n(3) The organizational risk tolerance; and\n(4) Priorities, benefits and trade-offs considered by the organization for managing risk.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -833,7 +824,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -1022,10 +1014,10 @@ "609.930(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(a)", @@ -1039,9 +1031,7 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.6.1(66)", - "3.7.2(82)" + "3.3.1.10" ], "emea-eu-dora-2023": [ "Article 8.2" @@ -1049,12 +1039,18 @@ "emea-eu-nis2-annex-2024": [ "2.1.2(c)" ], - "emea-isr-cmo-1-0": [ - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.1" ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" + "emea-esp-decree-311-2022": [ + "Article 14(2)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" + ], + "apac-aus-ps-cps-230-2023": [ + "16(b)", + "27" ], "apac-jpn-ismap": [ "4.4.6.1", @@ -1066,20 +1062,16 @@ "23.2.17.C.01" ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.3.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.15", - "6.24" + "4.2.1" ], "americas-can-osfi-b13-2022": [ "1.3", "3.1.8" ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" ] @@ -1103,7 +1095,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to reduce the magnitude or likelihood of potential impacts by resourcing the capability required to manage technology-related risks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1187,7 +1179,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -1235,7 +1228,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk tolerance, the specified range of acceptable results.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1325,7 +1318,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -1382,13 +1376,19 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "2.1.2(b)" ], + "emea-deu-c5-2020": [ + "OIS-07-DOAR" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.11" + ], "apac-aus-ps-cps-230-2023": [ - "26" + "16(b)" ], "apac-ind-sebi-2024": [ "GV.RM.S4" @@ -1396,8 +1396,20 @@ "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1", + "11.2" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.7(d)", + "4.4.2" + ], "americas-can-osfi-b13-2022": [ "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } }, @@ -1421,7 +1433,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define organizational risk threshold, the level of risk exposure above which risks are addressed and below which risks may be accepted.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1511,7 +1523,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -1551,19 +1564,23 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "13.2.2(b)" ], - "apac-aus-ps-cps-230-2023": [ - "26" - ], "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-sgp-mas-trm-2021": [ + "4.4.2" + ], "americas-can-osfi-b13-2022": [ "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } }, @@ -1677,7 +1694,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -1726,17 +1744,23 @@ "500.9(b)(1)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(a)" + "3.3.1.10", + "3.3.1.13(a)" ], "emea-eu-nis2-annex-2024": [ "2.1.2(b)" ], + "emea-deu-c5-2020": [ + "OIS-07-DOAR" + ], "emea-sau-cgiot-2024": [ "1-4-5" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.11" + ], "apac-aus-ps-cps-230-2023": [ - "26" + "16(b)" ], "apac-ind-sebi-2024": [ "GV.RM.S4" @@ -1744,9 +1768,20 @@ "apac-jpn-ismap": [ "4.4.7.1" ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "apac-sgp-mas-trm-2021": [ + "3.1.5", + "3.1.7(d)" + ], "americas-can-osfi-b13-2022": [ "1.3", "3.1.8" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.8" ] } }, @@ -1773,7 +1808,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to categorize TAASD in accordance with applicable laws, regulations and contractual obligations that:\n(1) Document the security categorization results (including supporting rationale) in the security plan for systems; and\n(2) Ensure the security categorization decision is reviewed and approved by the asset owner.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1847,7 +1882,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -1936,6 +1972,9 @@ "general-nist-800-171-r3": [ "03.11.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a" + ], "general-nist-csf-2-0": [ "ID.AM" ], @@ -1997,10 +2036,10 @@ "RA-02" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-cms-marse-2-0": [ "RA-2", @@ -2027,18 +2066,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "RA-02" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" - ], - "apac-sgp-mas-trm-2021": [ - "4.2.1" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" @@ -2140,7 +2169,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -2185,6 +2215,10 @@ "03.11.01.a", "03.14.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.14.03.a" + ], "general-nist-csf-2-0": [ "ID.RA-05", "ID.RA-06" @@ -2206,25 +2240,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.9(b)(3)" ], - "emea-sau-otcc-1-2022": [ - "1-3-1-4", - "1-3-1-5" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "apac-nzl-ism-3-9": [ "23.2.16.C.01", "23.2.17.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.3.1", - "4.3.2" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.14.03.B" @@ -2253,7 +2275,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and document risks, both internal and external.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and document risks, both internal and external. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2328,7 +2350,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -2466,10 +2489,10 @@ "314.4(c)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(b)(1)" @@ -2485,9 +2508,9 @@ "Article 9.2(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "emea-eu-dora-2023": [ "Article 8.2" @@ -2497,31 +2520,25 @@ "2.1.2(d)" ], "emea-deu-c5-2020": [ - "SP-03" + "OIS-03-DOAR", + "OIS-07" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.1" ], "emea-sau-cgiot-2024": [ "1-1-2", "1-4-1", "1-4-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.1" + "3.2.1.4-1.a", + "3.2.1.1-2", + "3.2.1.1-2.1", + "3.2.1.1-2.3" ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.2" - ], - "emea-esp-decree-311-2022": [ - "3.2" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], "emea-gbr-cap-1850-2020": [ "A2" @@ -2538,13 +2555,20 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1200" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1526" ], + "apac-aus-ps-cps-230-2023": [ + "13", + "16(d)" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], "apac-nzl-ism-3-9": [ "2.4.13.C.01", "2.4.13.C.02", @@ -2555,14 +2579,12 @@ "2.4.13.C.07" ], "apac-sgp-mas-trm-2021": [ - "4.1.3", - "4.1.4(a)" + "4.1.4(a)", + "4.2.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "5.3-BP1", + "5.5-BP1" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -2648,7 +2670,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -2670,14 +2693,12 @@ "TASK 2-1" ], "general-nist-800-171-r3": [ + "03.11.01.a", "03.15.02.a.03" ], "general-nist-800-171a-r3": [ "A.03.11.01.a" ], - "general-nist-800-172": [ - "3.11.5e" - ], "general-nist-csf-2-0": [ "ID" ], @@ -2704,10 +2725,10 @@ "609.930(a)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.105(a)", @@ -2725,21 +2746,138 @@ "emea-deu-bsrit-2017": [ "3.3" ], + "emea-deu-c5-2020": [ + "OIS-03-DOAR" + ], "emea-sau-cgiot-2024": [ "1-4-2", "1-4-4" ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.1-2.2" + ], "apac-jpn-ismap": [ "4.4.7.2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-mas-trm-2021": [ + "4.2.1" + ], "americas-can-osfi-b13-2022": [ "3.1.1" ], "americas-can-itsp-10-171-2025": [ + "03.11.01.A", "03.15.02.A.03" ] } }, + { + "control_id": "RSK-03.2", + "title": "Risk Owner", + "family": "RSK", + "description": "Mechanisms exist to identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks.", + "scf_question": "Does the organization identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks?", + "relative_weight": 9, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify a risk owner for each item in the risk register to ensure clear accountability for unremediated risks.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Risk register with assigned owner column\n∙ Designated security lead responsible for risk follow-up", + "small": "∙ Risk register with mandatory owner assignment\n∙ Regular risk owner check-ins on remediation progress", + "medium": "∙ Formal risk ownership assignment in risk register\n∙ GRC platform with risk owner workflow\n∙ Management accountability for open risk items", + "large": "∙ GRC platform with risk ownership and accountability workflow\n∙ Executive reporting on risk owner compliance\n∙ Risk owner training and awareness", + "enterprise": "∙ Enterprise GRC platform with risk ownership management\n∙ Automated risk owner escalation and reminders\n∙ Board-level reporting on material risk accountability\n∙ Risk ownership integrated into performance management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-17", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - RMiT", + "family_name": "Risk Management", + "crosswalks": { + "emea-deu-bsrit-2017": [ + "3.4" + ], + "apac-mys-bnm-rmit-2025": [ + "8.1" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.3" + ] + } + }, { "control_id": "RSK-04", "title": "Risk Assessment", @@ -2837,7 +2975,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -3028,12 +3167,7 @@ "3.11.1[b]" ], "general-nist-800-171a-r3": [ - "A.03.11.01.a", - "A.03.11.01.b" - ], - "general-nist-800-172": [ - "3.11.1e", - "3.11.5e" + "A.03.11.01.a" ], "general-nist-csf-2-0": [ "GV.RM-06", @@ -3059,9 +3193,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.1" - ], "general-swift-cscf-2025": [ "7.4A" ], @@ -3111,6 +3242,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "RA-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(1)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(b)", "314.4(b)(1)", @@ -3119,12 +3253,12 @@ "314.4(b)(1)(iii)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)", - "164.308(a)(1)(ii)(A)" + "§ 164.306(b)(2)(iv)", + "§ 164.308(a)(1)(ii)(A)" ], "usa-federal-irs-1075-2021": [ "RA-3" @@ -3181,10 +3315,9 @@ "Article 9.2(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(b)", - "3.3.3(20)", - "3.7.2(82)" + "3.3.1.10", + "3.3.1.13(b)", + "3.3.1.13(f)" ], "emea-eu-dora-2023": [ "Article 8.3", @@ -3201,16 +3334,19 @@ "2.1.3", "6.1.1" ], + "emea-eu-psd2-2015": [ + "95(2)" + ], "emea-deu-bsrit-2017": [ - "3.10" + "3.9" ], "emea-deu-c5-2020": [ "OIS-07", - "SP-03" + "BEI-06" ], - "emea-isr-cmo-1-0": [ - "1.2", - "2.2" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.2", + "4.2, Stage 2.3" ], "emea-sau-cscc-1-2019": [ "1-2-1-1" @@ -3223,29 +3359,27 @@ "1-5-3" ], "emea-sau-otcc-1-2022": [ - "1-3-1-2" + "1-3-1-2", + "1-3-1-4", + "1-3-1-5" ], "emea-sau-sacs-002-2022": [ - "TPC-31" + "VII.B.TPC-31" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 3.2", - "Article 14.1", - "Article 14.2" + "3.2.1.4-1.b", + "3.2.1.2-2", + "3.2.1.2-2.1", + "3.2.1.2-2.2" ], "emea-esp-decree-311-2022": [ - "14.1", - "14.2", - "3.2" + "Article 14(2)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.1 [OP.PL.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "mp.if.3", + "mp.if.5", + "mp.if.6" ], "emea-gbr-cap-1850-2020": [ "A2" @@ -3268,12 +3402,17 @@ "1202", "1204" ], + "apac-aus-ism-2026-march": [ + "ISM-1203" + ], "apac-aus-ps-cps-230-2023": [ - "27(a)", - "27(b)", - "27(c)", + "13", + "16(d)", "28" ], + "apac-chn-data-security-law-2021": [ + "Article 30" + ], "apac-ind-sebi-2024": [ "ID.RA.S1", "ID.RA.S2" @@ -3287,7 +3426,11 @@ "4.6.1.1", "6.1.5.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "8.1", + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP32", "HML32" ], @@ -3298,18 +3441,23 @@ "2.3.27.C.01", "2.3.27.C.02", "5.9.23.C.01", + "22.4.7.C.01", "23.2.16.C.02" ], "apac-sgp-mas-trm-2021": [ "4.1.4(b)", - "4.3.2" + "4.3.1", + "8.5.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "2.1", - "6.8" + "5.3-BP1", + "5.5", + "5.5-BP2", + "5.11", + "6.19", + "6.19-BP1", + "6.19-BP2", + "6.19-BP3" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -3340,11 +3488,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to maintain a risk register that facilitates monitoring and reporting of risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -3416,7 +3564,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -3454,6 +3603,10 @@ "03.12.02.a.01", "03.12.02.a.02" ], + "general-nist-800-171a-r3": [ + "A.03.12.02.a.01", + "A.03.12.02.a.02" + ], "general-nist-csf-2-0": [ "GV.RM-06", "ID", @@ -3476,9 +3629,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.3" - ], "general-tisax-6-0-3": [ "1.4.1" ], @@ -3507,15 +3657,14 @@ "500.9(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)", - "3.3.1(13)(d)" + "3.3.1.10", + "3.3.1.13(d)" ], "emea-deu-c5-2020": [ - "SP-03" + "OIS-03-DOAR" ], - "emea-isr-cmo-1-0": [ - "2.2", - "6.8" + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.2" ], "emea-sau-cscc-1-2019": [ "1-2-1-2" @@ -3524,17 +3673,11 @@ "1-4-3" ], "emea-sau-otcc-1-2022": [ - "1-3-1-3", - "1-3-1-6" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "1-3-1-3" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.4" - ], - "emea-zaf-popia-2013": [ - "19" + "3.2.1.4-1.c", + "3.2.1.1-2.2" ], "emea-gbr-def-stan-05-138-2024": [ "4201" @@ -3545,27 +3688,28 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4201" ], + "apac-aus-ps-cps-230-2023": [ + "13", + "32" + ], "apac-ind-sebi-2024": [ "GV.RM.S4" ], "apac-jpn-ismap": [ "4.4.7.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP65", "HML64" ], "apac-sgp-mas-trm-2021": [ - "4.1.3", - "4.1.4(d)", - "4.5.2", - "4.5.3" + "4.5.2" ], "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "5.5-BP4" ], "americas-can-osfi-b13-2022": [ "1.3", @@ -3595,7 +3739,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to implement a risk assessment methodology to ensure coverage for organizational components relevant for secure, compliant and resilient operations.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3668,7 +3812,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -3687,9 +3832,6 @@ "6.2", "6.7" ], - "general-nist-800-172": [ - "3.11.1e" - ], "general-swift-cscf-2025": [ "7.4A" ], @@ -3735,10 +3877,33 @@ "7.2(e)", "7.2(f)" ], + "emea-deu-c5-2020": [ + "OIS-07" + ], + "emea-sau-cscc-1-2019": [ + "1-2-1" + ], + "emea-sau-ecc-1-2018": [ + "1-5-1", + "1-5-2" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-1" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.1", "4.4.7.4" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.4(d)" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.1.3" ] } }, @@ -3762,7 +3927,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to define instances that require a risk assessment to be performed.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3830,16 +3995,14 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { "general-mpa-csbp-5-3-1": [ "OR-2.0" ], - "general-scf-dpmp-2025": [ - "9.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7150(a)", "7150(b)", @@ -3858,6 +4021,9 @@ "apac-jpn-ismap": [ "4.4.7.3", "4.5.5.1" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.4(d)" ] } }, @@ -3947,16 +4113,17 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { - "general-scf-dpmp-2025": [ - "9.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7151(a)", "7151(b)" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.9" ] } }, @@ -3982,7 +4149,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4055,7 +4222,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -4092,6 +4260,9 @@ "general-nist-800-171-r3": [ "03.11.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a" + ], "general-nist-csf-2-0": [ "ID", "ID.RA-05", @@ -4129,32 +4300,11 @@ "500.9(b)(3)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(10)" + "3.3.1.10" ], "emea-eu-nis2-annex-2024": [ "2.1.2(e)" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-sau-sama-csf-1-2017": [ - "3.2.1.2" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-sgp-mas-trm-2021": [ - "4.2.1" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "2.2" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A" ] @@ -4182,7 +4332,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to remediate risks to an acceptable level.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to remediate risks to an acceptable level. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4274,7 +4424,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -4387,8 +4538,9 @@ "03.11.02.b", "03.12.02.a.02" ], - "general-nist-800-172": [ - "3.11.7e" + "general-nist-800-171a-r3": [ + "A.03.11.02.b", + "A.03.12.02.a.02" ], "general-nist-csf-2-0": [ "GV.RM-04", @@ -4470,7 +4622,8 @@ "Article 9.2(d)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "emea-eu-nis2-2022": [ "Article 21.4" @@ -4481,24 +4634,26 @@ "2.1.2(g)", "2.1.2(j)" ], + "emea-deu-bsrit-2017": [ + "11.1" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 2.3" + ], "emea-sau-cgiot-2024": [ "1-1-2", "1-4-1", "1-4-5" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 14.2", - "Article 14.3" + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2", + "3.2.1.3-2.1" ], "emea-esp-decree-311-2022": [ - "14.2", - "14.3" + "Article 3(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], "emea-gbr-def-stan-05-138-2024": [ "1200" @@ -4513,6 +4668,7 @@ "1200" ], "apac-aus-ps-cps-230-2023": [ + "13", "31" ], "apac-ind-sebi-2024": [ @@ -4522,24 +4678,24 @@ "4.6.1.1", "4.7.1.1" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-sgp-pdpa-2012": [ + "4.1.15A(5)(b)(i)", + "4.1.15A(5)(b)(ii)", + "4.1.15A(5)(b)(iii)" + ], "apac-sgp-mas-trm-2021": [ - "4.1.3", "4.1.4(c)", - "4.4.1", - "4.4.2", - "4.4.3", - "13.6.1", - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" + "4.4.1" ], "americas-bmu-mba-coc-2020": [ - "5.5" + "5.3-BP1", + "5.5-BP3" ], - "amaericas-can-osfi-self-assessment": [ - "2.2", - "2.7", - "6.8" + "americas-can-osfi-self-assessment-2": [ + "3.2.3" ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", @@ -4567,7 +4723,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure proper risk response actions were performed to remediate findings from security, compliance and/or resilience-related:\n(1) Assessments;\n(2) Audits; and/or\n(3) Incidents.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4660,9 +4816,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -4768,13 +4924,11 @@ "03.11.04" ], "general-nist-800-171a-r3": [ + "A.03.11.02.b", "A.03.11.04[01]", "A.03.11.04[02]", "A.03.11.04[03]" ], - "general-nist-800-172": [ - "3.11.6e" - ], "general-nist-csf-2-0": [ "GV.RM-04", "ID.RA-05", @@ -4795,9 +4949,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "9.4" - ], "general-un-155-2021": [ "7.2.2.3" ], @@ -4856,24 +5007,16 @@ "Article 9.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "3.3.1.13(c)" ], "emea-sau-sama-csf-1-2017": [ - "3.2.1.3" - ], - "emea-zaf-popia-2013": [ - "19" + "3.2.1.4-1.d" ], - "emea-esp-boe-a-2022-7191": [ - "Article 14.2", - "Article 14.3" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3" ], - "emea-esp-decree-311-2022": [ - "14.2", - "14.3" + "apac-aus-ps-cps-230-2023": [ + "16(d)" ], "apac-jpn-ismap": [ "4.4.7.4", @@ -4883,15 +5026,8 @@ "4.7.1.3", "4.7.1.6" ], - "apac-sgp-mas-trm-2021": [ - "4.1.5", - "4.5.3" - ], - "americas-bmu-mba-coc-2020": [ - "5.5" - ], - "amaericas-can-osfi-self-assessment": [ - "6.24" + "apac-mys-bnm-rmit-2025": [ + "9.2" ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", @@ -4920,7 +5056,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to identify and implement compensating countermeasures to reduce risk and exposure to threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5013,7 +5149,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -5071,6 +5208,9 @@ "general-nist-800-171-r3": [ "03.11.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.b" + ], "general-nist-csf-2-0": [ "GV.RM-04", "ID.RA-06" @@ -5107,9 +5247,6 @@ "2.2.4", "12.3.1" ], - "general-scf-dpmp-2025": [ - "9.0" - ], "general-un-155-2021": [ "7.2.2.3" ], @@ -5133,10 +5270,10 @@ "314.4(c)(2)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(d)(3)(ii)(B)(2)" + "§ 164.306(d)(3)(ii)(B)(2)" ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.C.1.b", @@ -5158,22 +5295,35 @@ "Article 9.5(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(c)" + "3.3.1.13(c)", + "3.3.4.23" ], "emea-eu-nis2-annex-2024": [ "6.6.1(d)" ], + "emea-deu-c5-2020": [ + "OIS-04-DOAR", + "SA-03-DOAR" + ], "emea-sau-otcc-1-2022": [ "1-3-1-6", "1-3-1-7" ], - "emea-sau-sacs-002-2022": [ - "TPC-31" + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2.6", + "3.2.1.3-2.6.a", + "3.2.1.3-2.6.b", + "3.2.1.3-2.6.b.1", + "3.2.1.3-2.6.b.2", + "3.2.1.3-2.6.b.3", + "3.2.1.3-2.6.c", + "3.2.1.3-2.6.d" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-decree-311-2022": [ + "Article 28(3)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ + "ISM-0009", "ISM-1809" ], "apac-ind-sebi-2024": [ @@ -5184,7 +5334,10 @@ "4.4.8.1", "4.4.8.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP26", "HHSP43", "HHSP65", @@ -5193,6 +5346,7 @@ "HML64" ], "apac-nzl-ism-3-9": [ + "11.1.18.C.03", "12.4.5.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ @@ -5200,20 +5354,18 @@ "4.3(c)" ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "4.4.2", - "4.4.3" + "4.4.1" ], "americas-bmu-mba-coc-2020": [ - "5.8" - ], - "amaericas-can-osfi-self-assessment": [ - "6.16", - "6.24" + "5.11-BP4" ], "americas-can-osfi-b13-2022": [ "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.3", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B" ] @@ -5223,8 +5375,8 @@ "control_id": "RSK-06.3", "title": "Risk Treatment Options", "family": "RSK", - "description": "Mechanisms exist to select appropriate risk treatment options, based on applicable risk assessment findings.", - "scf_question": "Does the organization select appropriate risk treatment options, based on applicable risk assessment findings?", + "description": "Mechanisms exist to select appropriate risk treatment options, based on applicable risk assessment findings, including:\n(1) Mitigating the risk to an acceptable level;\n(2) Avoiding the risk (e.g., terminating the project);\n(3) Transferring the risk to a third party (e.g., insurance, service provider, etc.); or\n(4) Accepting the risk.", + "scf_question": "Does the organization select appropriate risk treatment options, based on applicable risk assessment findings, including:\n(1) Mitigating the risk to an acceptable level;\n(2) Avoiding the risk (e.g., terminating the project);\n(3) Transferring the risk to a third party (e.g., insurance, service provider, etc.); or\n(4) Accepting the risk?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -5239,7 +5391,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to select appropriate risk treatment options, based on applicable risk assessment findings.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5324,8 +5476,10 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Risk Management", "crosswalks": { "general-iso-21434-2021": [ @@ -5360,10 +5514,44 @@ "RISK-4a", "RISK-4b" ], + "emea-deu-bsrit-2017": [ + "3.9" + ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 3.1" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-6" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.10", + "3.2.1.3-2.3", + "3.2.1.3-2.3.a", + "3.2.1.3-2.3.b", + "3.2.1.3-2.3.b.1", + "3.2.1.3-2.3.b.2", + "3.2.1.3-2.4", + "3.2.1.3-2.5", + "3.2.1.3-2.5.a", + "3.2.1.3-2.5.b", + "3.2.1.3-2.5.c" + ], "apac-jpn-ismap": [ "4.4.7.1", "4.4.8.1", "4.4.8.2" + ], + "apac-mys-bnm-rmit-2025": [ + "11.17" + ], + "apac-sgp-mas-trm-2021": [ + "4.1.3", + "4.1.4(c)", + "4.4.2", + "4.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "5.8" ] } }, @@ -5387,7 +5575,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to formalize a Risk Treatment Plan (RTP) that applicable stakeholders will utilize to remediate identified risks according to a defined timeline.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5474,9 +5662,9 @@ "MT-15", "MT-17", "MT-24", - "MT-25" + "MT-25", + "MT-28" ], - "errata": "- renamed", "family_name": "Risk Management", "crosswalks": { "general-cobit-2019": [ @@ -5530,6 +5718,27 @@ "RISK:SG5.SP2", "TM:SG3.SP2" ], + "emea-isr-cmo-2-0": [ + "4.2, Stage 4" + ], + "emea-sau-otcc-1-2022": [ + "1-3-1-6" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.3-2.2", + "3.2.1.3-2.7", + "3.2.1.4-2", + "3.2.1.4-2.1", + "3.2.1.4-2.1.a", + "3.2.1.4-2.1.b", + "3.2.1.4-2.2" + ], + "emea-esp-decree-311-2022": [ + "Article 14(3)" + ], + "apac-aus-ps-cps-230-2023": [ + "31" + ], "apac-jpn-ismap": [ "4.4.6.1", "4.4.7.1", @@ -5542,6 +5751,13 @@ "4.7.1.1", "4.7.1.4", "4.9" + ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], + "americas-can-osfi-self-assessment-2": [ + "1.3.2", + "3.2.3" ] } }, @@ -5565,7 +5781,7 @@ "0": "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.", "1": "Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information. ", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5653,7 +5869,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -5707,30 +5924,11 @@ "500.9(a)" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.1(13)(f)" + "3.3.1.13(f)" ], "emea-eu-nis2-annex-2024": [ "2.1.4" ], - "emea-isr-cmo-1-0": [ - "2.2" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-4" - ], - "emea-sau-sacs-002-2022": [ - "TPC-31" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS05" - ], - "apac-sgp-mas-trm-2021": [ - "4.1.5" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.B" ] @@ -5756,7 +5954,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to conduct a Business Impact Analysis (BIA) to identify and assess security, compliance and resilience risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -5844,9 +6042,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -5907,11 +6105,9 @@ "general-pci-dss-4-0-1": [ "A3.2.2" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(78)" + "3.3.3.20", + "3.7.1.78" ], "emea-eu-dora-2023": [ "Article 11.5" @@ -5920,21 +6116,12 @@ "2.1.3", "4.1.3" ], - "emea-bel-act-8-1992": [ - "21" - ], "emea-deu-c5-2020": [ - "BCM-02" + "BCM-02-BP5", + "BCM-04" ], - "emea-isr-cmo-1-0": [ - "6.8", - "16.6" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-4" - ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-ccn-stic-825-2026": [ + "op.cont.3" ], "emea-uae-niaf-2023": [ "3.1.2" @@ -5948,18 +6135,21 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "4201" ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "apac-aus-ps-cps-230-2023": [ + "26" ], "apac-jpn-ismap": [ "4.4.7.3" ], - "apac-sgp-mas-trm-2021": [ - "5.1.3", - "5.3.3" + "apac-mys-bnm-rmit-2025": [ + "10.44" + ], + "apac-nzl-ism-3-9": [ + "16.1.30.C.01" ], - "apac-kor-pipa-2011": [ - "33" + "americas-bmu-mba-coc-2020": [ + "5.14", + "7.1-BP1" ] } }, @@ -6084,7 +6274,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -6245,16 +6436,11 @@ "A.03.17.01.a[10]", "A.03.17.01.b[01]", "A.03.17.01.b[02]", - "A.03.17.01.c", "A.03.17.03.ODP[01]", "A.03.17.03.a[01]", "A.03.17.03.a[02]", "A.03.17.03.b" ], - "general-nist-800-172": [ - "3.11.6e", - "3.11.7e" - ], "general-nist-csf-2-0": [ "GV.SC", "GV.SC-01", @@ -6270,9 +6456,6 @@ "general-owasp-top-10-2025": [ "A03:2025" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "general-sparta": [ "CM0026" ], @@ -6372,23 +6555,16 @@ "5.1.6" ], "emea-deu-c5-2020": [ - "OIS-07" + "OIS-07", + "PS-04-DOAR" ], - "emea-isr-cmo-1-0": [ - "16.3", - "17.3", - "17.11" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-3" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" ], "emea-gbr-caf-4-0": [ "A4", "A4.a" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -6401,11 +6577,14 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0731", "ISM-1567", "ISM-1785" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-nzl-ism-3-9": [ "2.2.7.C.01", "12.7.14.C.01", @@ -6428,13 +6607,6 @@ "12.7.20.C.05", "12.7.21.C.01" ], - "apac-sgp-mas-trm-2021": [ - "5.3.1" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.17.01.A", @@ -6464,7 +6636,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to periodically assess supply chain risks associated with Technology Assets, Applications and/or Services (TAAS).", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6563,7 +6735,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -6646,8 +6819,10 @@ "03.11.01.b", "03.17.03.a" ], - "general-nist-800-172": [ - "3.11.6e" + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.11.01.b", + "A.03.17.03.a[01]" ], "general-nist-csf-2-0": [ "GV.SC", @@ -6656,9 +6831,6 @@ "general-owasp-top-10-2025": [ "A03:2025" ], - "general-scf-dpmp-2025": [ - "9.2" - ], "general-un-155-2021": [ "7.2.2.5" ], @@ -6701,17 +6873,6 @@ "emea-eu-nis2-annex-2024": [ "5.1.3" ], - "emea-isr-cmo-1-0": [ - "16.6", - "17.3", - "17.11" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-3" - ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -6724,13 +6885,16 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1452", "ISM-1567" ], "apac-ind-sebi-2024": [ "GV.SC.S7" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.11.01.B", @@ -6843,7 +7007,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -6874,7 +7039,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to conduct a Data Protection Impact Assessment (DPIA) on Technology Assets, Applications and/or Services (TAAS) that store, process and/or transmit Personal Data (PD) to identify and remediate reasonably-expected risks.", "4": "Risk Management (RSK) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6928,7 +7093,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -7024,9 +7190,6 @@ "general-pci-dss-4-0-1": [ "A3.2.2" ], - "general-scf-dpmp-2025": [ - "9.5" - ], "general-shared-assessments-sig-2025": [ "P.5" ], @@ -7171,64 +7334,126 @@ "Article 35.11", "Article 36.1" ], - "emea-deu-c5-2020": [ - "BCM-02" + "emea-deu-fdpa-2017": [ + "3.4.67(1)", + "3.4.67(2)", + "3.4.67(3)", + "3.4.67(4)", + "3.4.67(4)1", + "3.4.67(4)2", + "3.4.67(4)3", + "3.4.67(4)4", + "3.4.67(5)" ], - "emea-isr-cmo-1-0": [ - "16.6", - "17.3" + "emea-irl-dpa-2018": [ + "s.84" ], "emea-ken-pda-2019": [ - "31(1)", - "31(2)(a)", - "31(2)(b)", - "31(2)(c)", - "31(2)(d)", - "31(3)", - "31(4)", - "31(5)", - "31(6)" + "IV.31(1)", + "IV.31(2)", + "IV.31(2)(a)", + "IV.31(2)(b)", + "IV.31(2)(c)", + "IV.31(2)(d)", + "IV.31(3)" ], "emea-qat-pdppl-2020": [ - "8.2" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-4" + "3.11.1" ], "emea-sau-pdpl-2023": [ "Article 22" ], "emea-srb-act-9-2018": [ - "54", - "54.x" + "IV.3.54-1", + "IV.3.54-1(1)", + "IV.3.54-1(2)", + "IV.3.54-1(3)", + "IV.3.54-2", + "IV.3.54-2(1)", + "IV.3.54-2(2)", + "IV.3.54-2(3)", + "IV.3.54-2(4)", + "IV.3.55-1", + "IV.3.55-1(1)", + "IV.3.55-1(2)", + "IV.3.55-2", + "IV.3.55-2(1)", + "IV.3.55-2(2)", + "IV.3.55-2(3)", + "IV.3.55-2(4)", + "IV.3.55-2(5)", + "IV.3.55-2(6)" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-decree-311-2022": [ + "Article 3(2)", + "Article 12(1)(f)" + ], + "emea-che-fadp-2025": [ + "3.22.1", + "3.22.2", + "3.22.2.a", + "3.22.2.b", + "3.22.3", + "3.22.4", + "3.22.5", + "3.22.5.a", + "3.22.5.b", + "3.22.5.c" + ], + "emea-gbr-dpa-2018": [ + "Section 64(1)", + "Section 64(2)", + "Section 64(3)", + "Section 64(3)(a)", + "Section 64(3)(b)", + "Section 64(3)(c)", + "Section 64(3)(d)", + "Section 64(4)" ], - "apac-aus-ps-cps-234-2019": [ - "21(d)" + "apac-aus-ps-cps-230-2023": [ + "26" ], "apac-chn-pipl-2021": [ - "55", - "55(1)", - "55(2)", - "55(3)", - "55(4)", - "55(5)", - "56", - "56(1)", - "56(2)", - "56(3)" + "Article 55", + "Article 56" ], "apac-ind-dpdpa-2023": [ "10(2)(c)(i)" ], - "apac-sgp-mas-trm-2021": [ - "5.1.3", - "5.3.3" - ], - "apac-kor-pipa-2011": [ - "33" + "apac-sgp-pdpa-2012": [ + "4.1.15A(4)(a)", + "4.1.15A(5)(a)" + ], + "americas-bhs-dpa-2003": [ + "V.50(1)", + "V.50(1)(a)", + "V.50(1)(b)", + "V.50(2)", + "V.50(2)(a)", + "V.50(2)(b)", + "V.50(2)(c)", + "V.50(3)", + "V.50(3)(a)", + "V.50(3)(b)", + "V.50(3)(c)", + "V.50(3)(d)", + "V.50(4)", + "V.50(5)", + "V.50(6)", + "V.50(7)", + "V.50(8)", + "V.50(8)(a)", + "V.50(8)(b)", + "V.50(8)(c)", + "V.50(8)(d)", + "V.50(8)(e)", + "V.50(8)(f)" + ], + "americas-bra-lgpd-2018": [ + "II.I.10.II.3" + ], + "americas-can-pipeda-2000": [ + "P5-4.5.1" ] } }, @@ -7250,7 +7475,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are documented and maintained by process owners.\n▪ 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.\n▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.\n▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure risk monitoring as an integral part of the continuous monitoring strategy that includes monitoring the effectiveness of security, compliance and resilience controls, compliance and change management.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7336,9 +7561,9 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Risk Management", "crosswalks": { "general-nist-800-53-r5-2": [ @@ -7362,10 +7587,11 @@ "general-nist-800-82-r3-high": [ "CA-07(04)" ], - "general-scf-dpmp-2025": [ - "7.11", - "9.0", - "9.3" + "general-nist-800-172-r3": [ + "03.12.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.03E[01]" ], "usa-federal-fbi-cjis-6-0": [ "CA-7(4)" @@ -7400,8 +7626,11 @@ "emea-eu-nis2-annex-2024": [ "2.1.2(h)" ], - "emea-zaf-popia-2013": [ - "4" + "emea-sau-sama-csf-1-2017": [ + "3.2.1.4-1.d" + ], + "emea-esp-decree-311-2022": [ + "Article 14(1)" ] } }, @@ -7425,7 +7654,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to ensure teams are committed to a culture that considers and communicates technology-related risk.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7492,7 +7721,8 @@ "MT-17", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Risk Management", "crosswalks": { @@ -7534,9 +7764,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to obtain executive leadership approval for risk management decisions involving material risk.", + "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to obtain executive leadership approval for risk management decisions involving material risk. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7563,10 +7793,18 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", - "crosswalks": {} + "crosswalks": { + "emea-deu-bsrit-2017": [ + "3.4" + ], + "emea-sau-sama-csf-1-2017": [ + "3.2.1.10" + ] + } }, { "control_id": "RSK-13.1", @@ -7588,7 +7826,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nRisk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.\n▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.\n▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Risk Management (RSK) 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:\n▪ Policies and standards associated with RSK domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with RSK domain capabilities are well-documented and kept current by process owners.\n▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform, TPRM tool, etc.).\n▪ 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 RSK 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).\n▪ An implemented and operational capability exists to document alternative courses of action to ensure executive leadership is reasonably informed of options to manage material risks, including potential:\n(1) Benefits;\n(2) Drawbacks (including technical limitations);\n(3) Costs; and\n(4) Timelines.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7617,7 +7855,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", "crosswalks": {} @@ -7673,7 +7912,8 @@ "MT-9", "MT-14", "MT-15", - "MT-17" + "MT-17", + "MT-28" ], "family_name": "Risk Management", "crosswalks": {} diff --git a/docs/api/families/SAT.json b/docs/api/families/SAT.json index 9f5259bc..da2e83f6 100644 --- a/docs/api/families/SAT.json +++ b/docs/api/families/SAT.json @@ -1,7 +1,7 @@ { "family_code": "SAT", "family_name": "Security Awareness & Training", - "control_count": 17, + "control_count": 18, "controls": [ { "control_id": "SAT-01", @@ -27,7 +27,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security workforce development and awareness controls.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to facilitate the implementation of security workforce development and awareness controls. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -125,9 +125,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -140,7 +140,7 @@ "6" ], "general-cis-csc-8-1": [ - "14.0", + "14", "14.1" ], "general-cis-csc-8-1-ig1": [ @@ -271,8 +271,7 @@ "general-nist-800-171a-r3": [ "A.03.02.01.ODP[01]", "A.03.02.01.ODP[02]", - "A.03.02.01.a.01[01]", - "A.03.02.01.a.01[02]" + "A.03.02.01.a.01[01]" ], "general-nist-csf-2-0": [ "PR.AT" @@ -331,10 +330,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6", - "7.6" - ], "general-swift-cscf-2025": [ "7.2" ], @@ -399,14 +394,18 @@ "AT-01", "PM-13" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)", + "101.650(d)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-irs-1075-2021": [ "2.D.2", @@ -439,8 +438,7 @@ "AT-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -452,65 +450,48 @@ "8.1.3", "8.2.5" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "4.9" ], "emea-deu-c5-2020": [ - "HR-03", - "DEV-04" - ], - "emea-isr-cmo-1-0": [ - "20.1" - ], - "emea-qat-pdppl-2020": [ - "11.3" + "HR-03" ], "emea-sau-cgiot-2024": [ "1-9-1" ], "emea-sau-ecc-1-2018": [ "1-10-1", - "1-10-5" + "1-10-2" ], "emea-sau-otcc-1-2022": [ - "1-8" - ], - "emea-sau-sacs-002-2022": [ - "TPC-7" + "1-8-1" ], "emea-sau-sama-csf-1-2017": [ - "3.1.6" - ], - "emea-zaf-popia-2013": [ - "4.1.e" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 6.2" - ], - "emea-esp-decree-311-2022": [ - "6.2" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "3.1.6", + "3.1.6.1", + "3.1.6.2", + "3.1.6.2.a", + "3.1.6.2.b", + "3.1.6.2.c", + "3.1.6.3", + "3.1.6.4", + "3.1.6.5", + "3.1.6.5.a", + "3.1.6.5.b", + "3.1.6.5.c" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" ], "emea-gbr-caf-4-0": [ "B6.a" ], - "emea-gbr-cap-1850-2020": [ - "B6" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0252", "ISM-0720", - "ISM-0735" + "ISM-0735", + "ISM-2022" ], "apac-chn-cybersecurity-law-2017": [ "Article 34(2)" @@ -529,7 +510,7 @@ "7.2.2.17", "7.2.2.18" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP22", "HML22" ], @@ -540,21 +521,17 @@ "9.1.4.C.01" ], "apac-sgp-mas-trm-2021": [ - "3.6.1", - "3.6.4", - "6.1.5" - ], - "americas-bmu-mba-coc-2020": [ - "6.7" + "3.1.6" ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "apac-kor-pipa-2011": [ + "III.2.28(2)" ], "americas-can-osfi-b13-2022": [ "3.1.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], "americas-can-itsp-10-171-2025": [ "03.02.01.A" ] @@ -674,7 +651,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -687,6 +665,32 @@ "general-nist-600-1-gen-ai-profile": [ "MP-3.4-002" ], + "general-nist-800-171-r3": [ + "03.02.01.b", + "03.02.02.a.02", + "03.02.02.b", + "03.06.04.b" + ], + "general-nist-800-171a-r3": [ + "A.03.02.01.b[01]", + "A.03.02.01.b[02]", + "A.03.02.02.b[01]", + "A.03.02.02.b[02]", + "A.03.06.04.ODP[03]", + "A.03.06.04.ODP[04]", + "A.03.06.04.b[01]", + "A.03.06.04.b[02]", + "A.03.06.04.b[03]", + "A.03.06.04.b[04]" + ], + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.b[01]", + "DS-A.03.02.01E.b[02]", + "A.03.02.01E.ODP[03]" + ], "general-swift-cscf-2025": [ "7.2" ], @@ -694,12 +698,35 @@ "WORKFORCE-2g", "WORKFORCE-4e" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "emea-eu-nis2-annex-2024": [ "8.1.2(a)" ], + "emea-deu-bsrit-2017": [ + "4.9" + ], + "emea-sau-sama-csf-1-2017": [ + "3.1.6.6", + "3.1.6.6.a", + "3.1.6.6.b" + ], "apac-jpn-ismap": [ "4.5.2.4", "4.5.2.5" + ], + "apac-sgp-mas-trm-2021": [ + "3.6.4" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], + "americas-can-itsp-10-171-2025": [ + "03.02.01.B", + "03.02.02.A.02", + "03.02.02.B", + "03.06.04.B" ] } }, @@ -725,7 +752,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -815,9 +842,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -944,7 +971,6 @@ "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.06.04.a.03" ], "general-nist-800-171a": [ @@ -954,12 +980,13 @@ "3.2.1[d]" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", "A.03.02.01.ODP[03]", "A.03.02.01.ODP[04]", + "A.03.02.01.a.01[01]", "A.03.02.01.a.03[03]", "A.03.02.01.a.03[04]", - "A.03.02.01.a.03[05]", - "A.03.02.01.a.03[06]" + "A.03.06.04.a.03" ], "general-nist-csf-2-0": [ "PR.AT", @@ -1021,9 +1048,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-swift-cscf-2025": [ "7.2" ], @@ -1065,19 +1089,27 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-02" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(9)", + "101.650(d)(1)", + "101.650(d)(1)(i)", + "101.650(d)(1)(ii)", + "101.650(d)(1)(iii)", + "101.650(d)(1)(iv)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(i)", - "164.530(b)(2)(i)", - "164.530(b)(2)(i)(A)", - "164.530(b)(2)(i)(B)", - "164.530(b)(2)(i)(C)", - "164.530(b)(2)(ii)" + "§ 164.308(a)(5)(i)", + "§ 164.530(b)(2)(i)", + "§ 164.530(b)(2)(i)(A)", + "§ 164.530(b)(2)(i)(B)", + "§ 164.530(b)(2)(i)(C)", + "§ 164.530(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(i)" + "§ 164.308(a)(5)(i)" ], "usa-federal-irs-1075-2021": [ "2.D.2.1", @@ -1139,7 +1171,7 @@ "2447(b)(2)(A)" ], "emea-eu-eba-ict-srm-2025": [ - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -1148,34 +1180,40 @@ "8.1.1", "8.1.2" ], - "emea-deu-c5-2020": [ - "HR-03", - "DEV-04" + "emea-deu-fdpa-2017": [ + "3.2.48(2)3" ], - "emea-isr-cmo-1-0": [ - "20.2" + "emea-deu-c5-2020": [ + "HR-03" ], "emea-sau-cgiot-2024": [ "1-9-1", "1-9-2" ], "emea-sau-ecc-1-2018": [ - "1-10-2", - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4" + "1-10-1", + "2-6-3-4" ], "emea-sau-otcc-1-2022": [ - "1-8" + "1-8-2" ], "emea-sau-sacs-002-2022": [ - "TPC-7" + "VII.A.TPC-7", + "VII.A.TPC-7.1", + "VII.A.TPC-7.2", + "VII.A.TPC-7.4", + "VII.A.TPC-7.5", + "VII.A.TPC-8", + "VII.A.TPC-9" ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "emea-sau-sama-csf-1-2017": [ + "3.1.6.7", + "3.1.7", + "3.3.1.3.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" ], "emea-gbr-caf-4-0": [ "B6" @@ -1202,7 +1240,7 @@ "2602", "2603" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0252", "ISM-0824", "ISM-1146", @@ -1221,29 +1259,42 @@ "7.2.2.15", "7.2.2.25" ], + "apac-mys-bnm-rmit-2025": [ + "15.1" + ], "apac-nzl-ism-3-9": [ "9.1.5.C.01", "9.1.5.C.02", "9.1.6.C.01", - "9.1.6.C.02" + "9.1.6.C.02", + "16.4.43.C.01", + "20.1.27.C.01" + ], + "apac-sgp-pdpa-2012": [ + "3.12(c)" ], "apac-sgp-mas-trm-2021": [ "3.6.1" ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" + "americas-bmu-mba-coc-2020": [ + "6.7" ], "americas-can-osfi-b13-2022": [ "3.1.7" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", "03.02.01.A.01", "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", "03.06.04.A.03" + ], + "americas-can-pipeda-2000": [ + "P1-4.1.4(c)", + "P7-4.7.4" ] } }, @@ -1354,7 +1405,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -1381,8 +1433,11 @@ "general-nist-800-161-r1-level-2": [ "AT-2(1)" ], - "general-scf-dpmp-2025": [ - "1.6" + "general-nist-800-172-r3": [ + "03.02.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.02E" ], "usa-federal-irs-1075-2021": [ "AT-2(CE-1)", @@ -1396,6 +1451,9 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2605" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.7" ] } }, @@ -1475,12 +1533,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { "general-cis-csc-8-1": [ - "9.0", + "9", "14.2" ], "general-cis-csc-8-1-ig1": [ @@ -1522,8 +1581,10 @@ "general-nist-800-171-r3": [ "03.02.01.a.03" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-171a-r3": [ + "A.03.02.01.a.03[03]", + "A.03.02.01.a.03[05]", + "A.03.02.01.a.03[06]" ], "general-pci-dss-4-0-1": [ "12.6.3.1" @@ -1561,11 +1622,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "AT-02 (03)" ], - "emea-isr-cmo-1-0": [ - "20.4" - ], "emea-sau-ecc-1-2018": [ - "1-10-3" + "1-10-3-1" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-7.3" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -1576,12 +1637,9 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ - "ISM-0817" - ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" + "apac-aus-ism-2026-march": [ + "ISM-0817", + "ISM-2071" ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.03" @@ -1593,7 +1651,7 @@ "title": "Role-Based Security, Compliance & Resilience Training", "family": "SAT", "description": "Mechanisms exist to provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter.", - "scf_question": "Does the organization provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafterystem changes; and \n (3) Annually thereafter?", + "scf_question": "Does the organization provide role-based security, compliance and resilience-related training: \n(1) Before authorizing access to the system or performing assigned duties; \n(2) When required by system changes; and \n(3) Annually thereafter?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1683,9 +1741,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -1773,7 +1831,7 @@ "7.2" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "OR-3.1", @@ -1846,11 +1904,10 @@ "03.02.02.a", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a", "03.06.04.a.01", "03.06.04.a.02", - "03.06.04.b" + "03.06.04.a.03" ], "general-nist-800-171a": [ "3.2.2[a]", @@ -1858,6 +1915,10 @@ "3.2.2[c]" ], "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.01.a.01[02]", + "A.03.02.01.a.02", "A.03.02.02.ODP[01]", "A.03.02.02.ODP[02]", "A.03.02.02.ODP[03]", @@ -1866,14 +1927,19 @@ "A.03.02.02.a.01[02]", "A.03.02.02.a.01[03]", "A.03.02.02.a.02", - "A.03.02.02.b[01]", - "A.03.02.02.b[02]", + "A.03.06.04.ODP[01]", + "A.03.06.04.ODP[02]", "A.03.06.04.a.01", "A.03.06.04.a.02", "A.03.06.04.a.03" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-172-r3": [ + "03.02.01E", + "03.02.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.02", + "A.03.02.04E.ODP[01]" ], "general-nist-800-218": [ "PO.2.2" @@ -1950,9 +2016,6 @@ "9.5.1.3", "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -2031,6 +2094,14 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(9)", + "101.650(d)(1)(v)", + "101.650(d)(2)", + "101.650(d)(2)(i)", + "101.650(d)(2)(ii)", + "101.650(d)(4)" + ], "usa-federal-sro-finra": [ "248.201(e)(3)" ], @@ -2041,13 +2112,13 @@ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)", - "164.530(b)(1)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)", + "§ 164.530(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(C)", - "164.308(a)(5)(ii)(D)" + "§ 164.308(a)(5)(ii)(C)", + "§ 164.308(a)(5)(ii)(D)" ], "usa-federal-irs-1075-2021": [ "2.D.2.1", @@ -2090,8 +2161,7 @@ "Article 9.5(c)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.1(3)", - "3.4.7(49)" + "3.4.7.49" ], "emea-eu-dora-2023": [ "Article 13.6" @@ -2105,48 +2175,53 @@ "8.2.4" ], "emea-deu-c5-2020": [ - "DEV-04" - ], - "emea-isr-cmo-1-0": [ - "20.2", - "25.3" + "HR-03", + "HR-03-BP1", + "HR-03-BP4", + "HR-03-DOAR" ], "emea-qat-pdppl-2020": [ - "11.3" + "3.11.3" ], "emea-sau-cgiot-2024": [ "1-9-1" ], "emea-sau-ecc-1-2018": [ - "1-10-3", - "1-10-3-1", - "1-10-3-2", - "1-10-3-3", - "1-10-3-4", - "1-10-4", "1-10-4-1", "1-10-4-2", - "1-10-4-3" + "1-10-4-3", + "1-10-5" ], "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-7" + "1-8-2-1", + "2-13-1-8" ], "emea-sau-sama-csf-1-2017": [ - "3.1.6", - "3.1.7" + "3.1.7.1", + "3.1.7.1.a", + "3.1.7.1.b", + "3.1.7.1.c", + "3.1.7.1.d", + "3.1.7.2" + ], + "emea-esp-decree-311-2022": [ + "Article 6(2)", + "Article 15(1)", + "Article 16(3)" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.per.3", + "mp.per.4" ], - "emea-esp-ccn-stic-825-2023": [ - "8.2.3 [MP.PER.3]", - "8.2.4 [MP.PER.4]" + "emea-che-fadp-2025": [ + "2.1.10.2.a" ], "emea-gbr-caf-4-0": [ "B6.b" ], + "emea-gbr-cap-1850-2020": [ + "B6" + ], "emea-gbr-def-stan-05-138-2024": [ "2321", "2602" @@ -2162,14 +2237,11 @@ "2321", "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1146", "ISM-1565", "ISM-1740" ], - "apac-chn-data-security-law-2021": [ - "27" - ], "apac-ind-sebi-2024": [ "PR.AT.S2" ], @@ -2180,20 +2252,20 @@ "7.2.2.14", "7.2.2.19.PB" ], + "apac-mys-bnm-rmit-2025": [ + "15.2", + "15.3" + ], "apac-nzl-ism-3-9": [ + "2.1.47.C.01", "9.1.6.C.01", "9.1.6.C.02", "9.1.6.C.03" ], "apac-sgp-mas-trm-2021": [ + "3.6.1", "3.6.2", - "3.6.3", - "6.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "3.6.3" ], "americas-can-osfi-b13-2022": [ "3.1.7" @@ -2205,17 +2277,16 @@ "03.02.02.A", "03.02.02.A.01", "03.02.02.A.02", - "03.02.02.B", "03.06.04.A", "03.06.04.A.01", "03.06.04.A.02", - "03.06.04.B" + "03.06.04.A.03" ] } }, { "control_id": "SAT-03.1", - "title": "Practical Exercises", + "title": "Practical Security Training Exercises", "family": "SAT", "description": "Mechanisms exist to include practical exercises in security, compliance and resilience training that reinforce training objectives.", "scf_question": "Does the organization include practical exercises in security, compliance and resilience training that reinforce training objectives?", @@ -2235,7 +2306,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to include practical exercises in security, compliance and resilience training that reinforce training objectives.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to include practical exercises in security, compliance and resilience training that reinforce training objectives.\nMechanisms exist to include practical exercises in security, compliance and resilience training that reinforce training objectives.", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2289,9 +2360,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", + "errata": "- renamed control", "family_name": "Security Awareness & Training", "crosswalks": { "general-cis-csc-8-1": [ @@ -2324,12 +2396,6 @@ "general-nist-800-160-vol-2-r1": [ "AT-03(03)" ], - "general-nist-800-172": [ - "3.2.2e" - ], - "general-scf-dpmp-2025": [ - "1.6" - ], "usa-federal-dow-cmmc-2-level-3": [ "AT.L3-3.2.2E" ], @@ -2425,8 +2491,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "update mappings to NIST 800-53", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -2482,8 +2550,11 @@ "AT-2(4)", "AT-2(5)" ], - "general-nist-800-172": [ - "3.2.1e" + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.02" ], "general-pci-dss-4-0-1": [ "11.5", @@ -2500,9 +2571,6 @@ "11.5.1", "11.5.1.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -2517,10 +2585,10 @@ "AT.L3-3.2.1E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(B)" + "§ 164.308(a)(5)(ii)(B)" ], "usa-federal-irs-1075-2021": [ "AT-2(CE-4)" @@ -2532,11 +2600,8 @@ "3.3.1", "3.3.2" ], - "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3", - "2-3-1-12" + "emea-sau-ecc-1-2018": [ + "1-10-3-1" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -2547,20 +2612,11 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0817", "ISM-0824", "ISM-1740" ], - "apac-sgp-mas-trm-2021": [ - "9.2.2", - "11.5.5", - "12.2.4" - ], - "amaericas-can-osfi-self-assessment": [ - "1.8", - "1.9" - ], "americas-can-osfi-b13-2022": [ "3.1.7" ] @@ -2570,8 +2626,8 @@ "control_id": "SAT-03.3", "title": "Sensitive / Regulated Data Storage, Handling & Processing", "family": "SAT", - "description": "Mechanisms exist to ensure that every user accessing a system processing, storing or transmitting sensitive/regulated data is formally trained in data handling requirements.", - "scf_question": "Does the organization ensure that every user accessing a system processing, storing or transmitting sensitive/regulated data is formally trained in data handling requirements?", + "description": "Mechanisms exist to ensure that every user accessing a system processing, storing or transmitting sensitive and/or regulated data is formally trained in data handling requirements.", + "scf_question": "Does the organization ensure that every user accessing a system processing, storing or transmitting sensitive and/or regulated data is formally trained in data handling requirements?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -2672,7 +2728,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -2704,7 +2761,7 @@ "6.3(a)" ], "general-iso-29100-2024": [ - "6.1" + "6.10" ], "general-mpa-csbp-5-3-1": [ "OR-3.3" @@ -2726,6 +2783,11 @@ "03.02.01.a.01", "03.02.02.a.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a", + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], "general-nist-800-218": [ "PO.2.2" ], @@ -2770,9 +2832,6 @@ "9.5.1", "9.5.1.3" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-sparta": [ "CM0041" ], @@ -2849,17 +2908,17 @@ "usa-state-vt-act-171-2018": [ "2447(c)(8)" ], - "emea-isr-cmo-1-0": [ - "20.3" + "emea-aut-dpa-2018": [ + "§ 6(3)" + ], + "emea-deu-c5-2020": [ + "HR-03-BP2" ], "emea-qat-pdppl-2020": [ - "11.3" + "3.11.3" ], "emea-sau-ecc-1-2018": [ - "1-10-4-2" - ], - "emea-sau-sama-csf-1-2017": [ - "3.1.7" + "1-10-3-2" ], "emea-gbr-def-stan-05-138-2024": [ "2602" @@ -2870,7 +2929,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2602" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0831", "ISM-1059" ], @@ -2878,13 +2937,12 @@ "7.2.2.16", "7.2.2.19.PB" ], - "apac-sgp-mas-trm-2021": [ - "3.6.2", - "3.6.3", - "6.1.5" + "apac-nzl-ism-3-9": [ + "21.1.6.C.01", + "22.1.11.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "1.7" + "apac-sgp-mas-trm-2021": [ + "3.6.1" ], "americas-can-itsp-10-171-2025": [ "03.01.22.A", @@ -2916,7 +2974,7 @@ "0": "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.", "1": "Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ Security awareness and training methods are often generic, without organization-specific content.", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to incorporate vendor-specific security, compliance and resilience training in support of new technology initiatives.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to incorporate vendor-specific security, compliance and resilience training in support of new technology initiatives. ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2982,16 +3040,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "usa-federal-dhs-cisa-cpg-2-0": [ "2.J" - ], - "emea-deu-c5-2020": [ - "DEV-04" ] } }, @@ -3000,7 +3055,7 @@ "title": "Privileged Users", "family": "SAT", "description": "Mechanisms exist to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", - "scf_question": "Does the organization provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", + "scf_question": "Does the organization provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -3015,9 +3070,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.\n▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data).", - "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide specific training for privileged users to ensure privileged users understand their unique roles and responsibilities ", "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3105,7 +3160,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -3122,6 +3178,10 @@ "03.02.01.a.01", "03.02.02.a.01" ], + "general-nist-800-171a-r3": [ + "A.03.02.01.a.01[01]", + "A.03.02.02.a.01[01]" + ], "general-nist-800-218": [ "PO.2.2" ], @@ -3152,26 +3212,12 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.10(a)(2)" ], - "emea-sau-ecc-1-2018": [ - "1-10-4-1" - ], - "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1565" ], "apac-ind-sebi-2024": [ "PR.AT.S2" ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" - ], - "amaericas-can-osfi-self-assessment": [ - "1.7" - ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.01", "03.02.02.A.01" @@ -3198,7 +3244,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision.\n▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations.\n▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities.\n▪ The responsibility for training users and enforcing policies may be assigned to user’s immediate supervisor(s)/manager(s), including the definition and enforcement of the user’s specific role(s) and responsibilities.\n▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data).\n▪ Business process owners are required to incorporate vendor-specific security training in support of new technology initiatives.\n▪ Security awareness training covers recommended practices for securing laptops and mobile devices while traveling.\n▪ Security awareness training covers reporting of unauthorized alterations and evidence of tampering of equipment", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to provide role-based security, compliance and resilience awareness training that is current and relevant to the cyber threats that users might encounter in day-to-day business operations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3271,9 +3317,10 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", + "errata": "update mappings to NIST 800-53", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -3318,20 +3365,24 @@ "03.02.01.a.01", "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", "03.02.02.a.01", "03.02.02.a.02", - "03.02.02.b", "03.06.04.a.02" ], "general-nist-800-171a-r3": [ + "A.03.02.01.a.01[01]", "A.03.02.01.a.02", - "A.03.02.01.b[01]", - "A.03.02.01.b[02]" + "A.03.02.01.b[02]", + "A.03.02.02.a.01[01]", + "A.03.02.02.a.02", + "A.03.06.04.a.02" ], - "general-nist-800-172": [ - "3.2.1e", - "3.2.2e" + "general-nist-800-172-r3": [ + "03.02.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.01E.a.01", + "DS-A.03.02.01E.a.03" ], "general-nist-800-218": [ "PO.2.2" @@ -3384,9 +3435,6 @@ "9.5.1", "9.5.1.3" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-shared-assessments-sig-2025": [ "P.4" ], @@ -3412,14 +3460,17 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(4)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(e)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(5)(ii)(A)" + "§ 164.308(a)(5)(ii)(A)" ], "usa-federal-nispom-2020": [ "§117.12(e)(1)", @@ -3440,13 +3491,19 @@ "8.1.2(c)", "8.2.3(b)" ], + "emea-deu-c5-2020": [ + "HR-03-BP3" + ], "emea-sau-cgiot-2024": [ "1-9-2" ], + "emea-sau-ecc-1-2018": [ + "1-10-3-3", + "1-10-3-4" + ], "emea-sau-otcc-1-2022": [ - "1-8-1", - "1-8-2", - "1-8-3" + "1-8-2-2", + "2-13-1-8" ], "emea-gbr-def-stan-05-138-2024": [ "2601", @@ -3469,19 +3526,15 @@ "2603", "3106" ], - "amaericas-can-osfi-self-assessment": [ - "1.7", - "1.8", - "1.9" + "apac-sgp-mas-trm-2021": [ + "12.1.3" ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.01", "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", "03.02.02.A.01", "03.02.02.A.02", - "03.02.02.B", "03.06.04.A.02" ] } @@ -3507,7 +3560,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience personnel receive Continuing Professional Education (CPE) training to maintain currency and proficiency with industry-recognized secure practices that are pertinent to their assigned roles and responsibilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3556,9 +3609,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -3578,9 +3631,6 @@ "general-iso-27701-2025": [ "7.2" ], - "general-nist-800-171-r3": [ - "03.06.04.b" - ], "general-nist-csf-2-0": [ "PR.AT-02" ], @@ -3590,11 +3640,14 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.10(a)(3)" ], + "emea-sau-otcc-1-2022": [ + "1-8-2-1" + ], "apac-jpn-ismap": [ "4.5.2.4" ], - "americas-can-itsp-10-171-2025": [ - "03.06.04.B" + "apac-mys-bnm-rmit-2025": [ + "15.2" ] } }, @@ -3616,7 +3669,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to ensure application development and operations (DevOps) personnel receive Continuing Professional Education (CPE) training on Secure Software Development Practices (SSDP) to appropriately address evolving threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3661,7 +3714,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": { @@ -3692,8 +3746,11 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1780" + ], + "apac-sgp-mas-trm-2021": [ + "6.1.5" ] } }, @@ -3783,7 +3840,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Security Awareness & Training", "crosswalks": {} @@ -3880,9 +3938,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "general-govramp": [ @@ -3970,9 +4028,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.6.1" ], - "general-scf-dpmp-2025": [ - "1.6" - ], "general-tisax-6-0-3": [ "8.2.3" ], @@ -3991,6 +4046,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "AT-04" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(d)(4)" + ], "usa-federal-irs-1075-2021": [ "AT-4" ], @@ -4022,6 +4080,84 @@ ] } }, + { + "control_id": "SAT-04.1", + "title": "Training Feedback", + "family": "SAT", + "description": "Mechanisms exist to:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders.", + "scf_question": "Does the organization:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Identify", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are documented and maintained by process owners.\n▪ 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Security Awareness & Training (SAT) 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:\n▪ Policies and standards associated with SAT domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SAT domain capabilities are well-documented and kept current by process owners.\n▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions, etc.).\n▪ 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 SAT 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).\n▪ An implemented and operational capability exists to:\n(1) Monitor individual training results; and\n(2) Report findings to stakeholders.", + "4": "Security Awareness & Training (SAT) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Track training completion rates\n∙ Simple feedback survey after training", + "small": "∙ Training completion tracking\n∙ Post-training feedback forms\n∙ Report findings to management", + "medium": "∙ Learning Management System (LMS) with completion and assessment tracking\n∙ Training effectiveness metrics\n∙ Regular reporting to management on training outcomes", + "large": "∙ LMS with detailed completion and assessment analytics\n∙ Training effectiveness measurement\n∙ Reporting to security leadership and HR", + "enterprise": "∙ Enterprise LMS with advanced analytics\n∙ Training effectiveness measurement and outcome reporting\n∙ Behavioral change metrics linked to awareness program\n∙ Board-level workforce security readiness reporting" + }, + "risks": [ + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-GV-1", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Security Awareness & Training", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.02.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.03E" + ] + } + }, { "control_id": "SAT-05", "title": "Security, Compliance & Resilience Knowledge Sharing", @@ -4047,7 +4183,13 @@ "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, "profiles": [], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Informal security knowledge sharing (e.g., team meetings, email updates)\n∙ Subscribe to CISA and NIST security alerts", + "small": "∙ Regular security briefings or newsletter\n∙ CISA and NIST alert subscriptions for the security team", + "medium": "∙ Internal security knowledge sharing program\n∙ Cross-functional security briefings\n∙ Lessons learned from incidents and assessments", + "large": "∙ Formal knowledge sharing program (security communities of practice)\n∙ Internal security portal or wiki\n∙ Cross-functional security training and briefings", + "enterprise": "∙ Enterprise security knowledge management platform\n∙ Communities of practice for security specializations\n∙ Cross-organizational knowledge sharing and lessons learned\n∙ Integration with LMS and professional development programs" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -4118,9 +4260,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Security Awareness & Training", "crosswalks": { "usa-federal-dhs-cisa-cpg-2-0": [ diff --git a/docs/api/families/SEA.json b/docs/api/families/SEA.json index a583d911..e6da9b53 100644 --- a/docs/api/families/SEA.json +++ b/docs/api/families/SEA.json @@ -1,7 +1,7 @@ { "family_code": "SEA", "family_name": "Secure Engineering & Architecture", - "control_count": 44, + "control_count": 47, "controls": [ { "control_id": "SEA-01", @@ -27,7 +27,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).\n▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of TAAS.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -109,9 +109,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -126,18 +126,18 @@ "general-cis-csc-8-1": [ "12.2", "12.6", - "16.0", - "16.1" + "16", + "16.10" ], "general-cis-csc-8-1-ig2": [ "12.2", "12.6", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ "12.2", "12.6", - "16.1" + "16.10" ], "general-cobit-2019": [ "APO03.01", @@ -213,7 +213,7 @@ "8.26", "8.27" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1005", "T1025", "T1041", @@ -351,7 +351,6 @@ "general-nist-800-171-r3": [ "03.01.12.a", "03.01.16.a", - "03.01.16.b", "03.01.16.c", "03.01.18.a", "03.13.01.c", @@ -364,7 +363,13 @@ "3.13.2[f]" ], "general-nist-800-171a-r3": [ - "A.03.16.01.ODP[01]" + "A.03.01.12.a[04]", + "A.03.01.16.a[02]", + "A.03.01.16.c", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01.ODP[01]", + "A.03.16.01" ], "general-nist-csf-2-0": [ "PR.IR", @@ -399,10 +404,6 @@ "6.2.1", "8.5.1" ], - "general-scf-dpmp-2025": [ - "5.12", - "7.1" - ], "general-swift-cscf-2025": [ "1.3" ], @@ -490,10 +491,10 @@ "314.4(c)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "PT-1", @@ -533,7 +534,7 @@ "SI-01" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -551,107 +552,28 @@ "6.2.2(b)", "6.2.2(c)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-bsrit-2017": [ - "12.1" + "1.2(d)" ], "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "UP-01-BP2", + "DLL-01-BP1" ], "emea-sau-cgiot-2024": [ "1-5-1", "2-5-1" ], "emea-sau-ecc-1-2018": [ + "1-6-3-1", "1-6-3-4", - "2-4-3", "2-15-3-3" ], "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" + "1-4-1-3" ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 29" - ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" - ], - "emea-che-fadp-2025": [ - "6", - "7" - ], - "emea-tur-lppd-2016": [ - "8", - "12" + "emea-esp-ccn-stic-825-2026": [ + "mp.info.4", + "mp.s.2" ], "emea-uae-niaf-2023": [ "3.2.1" @@ -660,10 +582,6 @@ "B4.a", "B5.b" ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" - ], "emea-gbr-def-stan-05-138-2024": [ "2400" ], @@ -676,41 +594,15 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2400" ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", - "ISM-1743" - ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" + "ISM-1743", + "ISM-1926", + "ISM-1927" ], "apac-ind-sebi-2024": [ "PR.IP.S17" ], - "apac-jpn-ppi-2020": [ - "20" - ], "apac-jpn-ismap": [ "14.2.5", "14.2.5.1", @@ -721,10 +613,19 @@ "14.2.5.6", "14.2.5.7" ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.5", + "10.22", + "10.26", + "10.36", + "10.37", + "10.38", + "10.40", + "10.43", + "10.52" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP16", "HML16" ], @@ -732,42 +633,16 @@ "HSUP14" ], "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" + "2.3.28.C.01", + "20.2.14.C.01", + "20.2.14.C.03" ], "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" + "14.1.1", + "14.2.10" ], "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" + "5.3-BP3" ], "americas-can-osfi-b13-2022": [ "1.3.1", @@ -777,29 +652,18 @@ "3.2", "3.2.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.1.1", + "2.1.2", + "3.2.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", - "03.01.16.B", "03.01.16.C", "03.01.18.A", "03.13.01.C", "03.16.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } }, @@ -824,7 +688,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to centrally-manage the organization-wide management and implementation of security, compliance and resilience controls and related processes.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -914,22 +778,22 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ "CC5.1" ], "general-cis-csc-8-1": [ - "16.1" + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.10" ], "general-cobit-2019": [ "APO03.01", @@ -999,9 +863,6 @@ "10.7.2", "10.7.3" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "general-tisax-6-0-3": [ "5.3.1" ], @@ -1030,21 +891,12 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(5)(B)" ], - "emea-zaf-popia-2013": [ - "8" - ], - "apac-aus-ps-cps-234-2019": [ - "18" + "emea-isr-cmo-2-0": [ + "Appendix C" ], "apac-nzl-ism-3-9": [ "4.3.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "4.5.1" - ], - "americas-arg-ppd-2018": [ - "9.1" - ], "americas-can-osfi-b13-2022": [ "1.3.1" ] @@ -1072,7 +924,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to achieve resilience requirements in normal and adverse situations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1127,7 +979,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -1166,6 +1019,12 @@ "emea-eu-nis2-annex-2024": [ "4.2.4" ], + "emea-sau-otcc-1-2022": [ + "3-1-1-1" + ], + "emea-gbr-cap-1850-2020": [ + "B5" + ], "emea-gbr-def-stan-05-138-2024": [ "2500", "2501" @@ -1185,6 +1044,13 @@ "2500", "2501" ], + "apac-mys-bnm-rmit-2025": [ + "10.24", + "10.31", + "10.32", + "10.40", + "11.2" + ], "americas-can-osfi-b13-2022": [ "2", "2.1.2", @@ -1210,7 +1076,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience are designed and implemented to provide resistance to:\n(1) Unintentional errors (by users or software); and \n(2) Intentional attack or circumvention.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1261,9 +1127,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-csa-cmm-4-1-0": [ @@ -1304,6 +1170,253 @@ "emea-gbr-caf-4-0": [ "B5", "B5.b" + ], + "emea-gbr-cap-1850-2020": [ + "B5" + ], + "apac-mys-bnm-rmit-2025": [ + "10.31", + "10.32", + "10.40", + "11.2" + ] + } + }, + { + "control_id": "SEA-01.4", + "title": "Secure Architecture Principles", + "family": "SEA", + "description": "Mechanisms exist to ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture.", + "scf_question": "Does the organization ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure security, compliance and resilience capabilities are designed and maintained in alignment with security architecture principles from:\n(1) The Open Group Architecture Framework (TOGAF);\n(2) Sherwood Applied Business Security Architecture (SABSA); and/or\n(3) An organization-defined reference architecture.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Reference NIST CSF for architecture guidance\n∙ Apply basic secure design principles (least privilege, defense-in-depth)", + "small": "∙ NIST CSF and OWASP design principles\n∙ Documented secure design checklist", + "medium": "∙ TOGAF or SABSA-aligned secure architecture principles\n∙ Documented architecture principles standard\n∙ Security architecture review in project lifecycle", + "large": "∙ Enterprise secure architecture principles aligned to TOGAF or SABSA\n∙ Security Architecture Review Board (SARB)\n∙ Architecture principles enforced in project governance", + "enterprise": "∙ Enterprise architecture framework with embedded security principles (TOGAF or SABSA)\n∙ Dedicated security architecture function\n∙ Automated architecture compliance checking\n∙ Board-approved enterprise architecture standards" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "emea-deu-bsrit-2017": [ + "1.2(d)" + ], + "emea-deu-c5-2020": [ + "UP-01-BP2", + "SA-01-BP5" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.4", + "3.3.4.1", + "3.3.4.3", + "3.3.4.3.a", + "3.3.4.3.b", + "3.3.4.3.c", + "3.3.4.3.d", + "3.3.4.3.e" + ], + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.5", + "10.36", + "10.37", + "10.38", + "10.40" + ], + "apac-nzl-ism-3-9": [ + "1.2.15.C.01", + "2.3.28.C.01" + ] + } + }, + { + "control_id": "SEA-01.5", + "title": "Security-Aware Design", + "family": "SEA", + "description": "Mechanisms exist to formally incorporate the organization's secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "scf_question": "Does the organization formally incorporate its secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to formally incorporate the organization's secure architecture principles into engineering, product and model design requirements to ensure security, compliance and resilience are built in by default and by design.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Security design checklist for new systems or applications\n∙ OWASP Top 10 design guidance", + "small": "∙ OWASP secure design principles\n∙ Security requirements in development projects", + "medium": "∙ Security-by-design requirements integrated into SDLC\n∙ Threat modeling for new systems\n∙ OWASP Threat Dragon or similar", + "large": "∙ Enterprise secure-by-design program\n∙ Threat modeling requirements in SDLC\n∙ Security architecture approval for new projects\n∙ Privacy and security design reviews", + "enterprise": "∙ Enterprise security-aware design program\n∙ Automated threat modeling integration in SDLC\n∙ Security and privacy design reviews for all new systems\n∙ Board-approved security-by-design policy" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.01", + "DS-A.03.15.01E.a.02" + ], + "apac-nzl-ism-3-9": [ + "2.3.28.C.01" ] } }, @@ -1328,9 +1441,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1401,9 +1514,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -1414,15 +1527,15 @@ ], "general-cis-csc-8-1": [ "12.2", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig2": [ "12.2", - "16.1" + "16.10" ], "general-cis-csc-8-1-ig3": [ "12.2", - "16.1" + "16.10" ], "general-cobit-2019": [ "APO02.01", @@ -1530,6 +1643,18 @@ "03.13.01.c", "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.01.16.a[02]", + "A.03.01.18.a[01]", + "A.03.13.01.c", + "A.03.16.01" + ], + "general-nist-800-172-r3": [ + "03.15.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.01E.a.02" + ], "general-nist-csf-2-0": [ "PR.IR", "PR.IR-01", @@ -1538,9 +1663,6 @@ "general-pci-dss-4-0-1": [ "1.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-swift-cscf-2025": [ "1.3" ], @@ -1580,12 +1702,12 @@ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)", - "164.306(b)(2)(ii)" + "§ 164.306(b)(1)", + "§ 164.306(b)(2)(ii)" ], "usa-federal-irs-1075-2021": [ "PL-8", @@ -1615,7 +1737,7 @@ "PL-08" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -1623,207 +1745,44 @@ "Article 9.3(c)", "Article 9.3(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], "emea-deu-bsrit-2017": [ - "12.1" - ], - "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" + "1.2(d)" ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "emea-sau-cscc-1-2019": [ + "2-12-2" ], "emea-sau-ecc-1-2018": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" - ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 29" - ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" - ], - "emea-che-fadp-2025": [ - "6", - "7" + "1-6-3-4" ], - "emea-tur-lppd-2016": [ - "8", - "12" + "emea-esp-ccn-stic-825-2026": [ + "op.pl.3", + "mp.info.4", + "mp.s.2" ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", "ISM-1743" ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" - ], - "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" + "apac-mys-bnm-rmit-2025": [ + "10.4", + "10.36", + "10.40" ], "americas-can-osfi-b13-2022": [ "2", "2.1", "2.1.2" ], + "americas-can-osfi-self-assessment-2": [ + "2.1.1", + "2.1.2" + ], "americas-can-itsp-10-171-2025": [ "03.01.12.A", "03.01.16.A", "03.01.18.A", "03.13.01.C", "03.16.01" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } }, @@ -1845,9 +1804,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1884,7 +1843,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -1929,15 +1889,18 @@ "usa-federal-far-52-204-21": [ "52.204-21(a)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.615" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.2" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.103", - "164.304", - "164.402", - "164.501", - "164.504(a)" + "§ 164.103", + "§ 164.304", + "§ 164.402", + "§ 164.501", + "§ 164.504(a)" ], "usa-state-ca-ccpa-cpra-2026": [ "7001" @@ -1965,30 +1928,9 @@ "emea-eu-ai-act-2024": [ "Article 3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 3" - ], "emea-eu-gdpr-2016": [ "Article 4" ], - "emea-ken-pda-2019": [ - "2" - ], - "emea-nga-dpr-2019": [ - "1.3" - ], - "emea-qat-pdppl-2020": [ - "1" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 4" - ], - "emea-esp-decree-311-2022": [ - "4" - ], - "amaericas-can-osfi-self-assessment": [ - "6.4" - ], "americas-can-osfi-b13-2022": [ "A.1" ] @@ -2012,7 +1954,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to identify non-essential functions or services that are capable of being outsourced to external service providers and align with the organization's enterprise architecture and security standards.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2079,7 +2021,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -2095,6 +2038,12 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.2(d)" ], + "emea-esp-decree-311-2022": [ + "Article 14(1)" + ], + "apac-aus-ps-cps-230-2023": [ + "15" + ], "apac-jpn-ismap": [ "4.5.4.5" ] @@ -2118,7 +2067,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to conduct ongoing “technical debt” reviews of hardware and software technologies to remediate outdated and/or unsupported technologies.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2196,7 +2145,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -2242,9 +2192,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).\n▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2315,7 +2265,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -2351,6 +2302,14 @@ "general-nist-800-171-r2": [ "3.13.2" ], + "general-nist-800-172-r3": [ + "03.15.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.02E.a", + "A.03.15.02E.ODP[02]", + "DS-A.03.15.02E.c" + ], "general-owasp-top-10-2025": [ "A01:2025", "A05:2025" @@ -2386,14 +2345,17 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(iv)" + ], "usa-federal-law-ftc-act": [ "45(a)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(1)" + "§ 164.306(b)(1)" ], "usa-federal-irs-1075-2021": [ "PL-8(CE-1)", @@ -2404,7 +2366,7 @@ "500.2(b)(2)" ], "emea-eu-eba-ict-srm-2025": [ - "3.7.1(79)" + "3.7.1.79" ], "emea-eu-dora-2023": [ "Article 9.3(a)", @@ -2412,202 +2374,19 @@ "Article 9.3(c)", "Article 9.3(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-fdpa-2017": [ - "Sec 4b", - "Sec 9", - "Sec 9a", - "Sec 16", - "Annex" - ], - "emea-deu-bsrit-2017": [ - "12.1" - ], - "emea-deu-c5-2020": [ - "COS-01" - ], - "emea-grc-pirppd-1997": [ - "9" - ], - "emea-hun-isdfi-2011": [ - "7", - "8" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "2.1", - "15.6", - "17.7" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31", - "33", - "34", - "35", - "42" - ], - "emea-nor-pda-2018": [ - "13", - "14", - "29" - ], - "emea-pol-act-29-1997": [ - "1", - "36", - "47" - ], - "emea-rus-federal-law-27-2006": [ - "7", - "12", - "19" + "emea-isr-cmo-2-0": [ + "2.E" ], "emea-sau-ecc-1-2018": [ - "1-6-3-4", - "2-4-3", - "2-15-3-3" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-43" + "2-15-3-2" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.4", - "3.3.8", - "3.3.13" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 9.1", - "Article 9.1(a)", - "Article 9.1(b)", - "Article 9.2" - ], - "emea-esp-decree-311-2022": [ - "29" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.2 [OP.PL.2]" - ], - "emea-che-fadp-2025": [ - "6", - "7" - ], - "emea-tur-lppd-2016": [ - "8", - "12" - ], - "emea-gbr-cap-1850-2020": [ - "B4", - "B5" - ], - "apac-aus-privacy-act-1998": [ - "APP Part 8", - "APP Part 11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1739", "ISM-1743" ], - "apac-aus-cop-sitc-2020": [ - "Principle 4", - "Principle 5", - "Principle 6", - "Principle 7" - ], - "apac-aus-ps-cps-234-2019": [ - "15", - "18" - ], - "apac-chn-csnip-2012": [ - "4" - ], - "apac-hkg-pdo-2022": [ - "Principle 4", - "Sec 33" - ], - "apac-ind-privacy-rules-2011": [ - "7", - "8" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-nzl-ism-3-9": [ - "1.2.13.C.01", - "1.2.13.C.02" - ], - "apac-phl-dpa-2012": [ - "25", - "29" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-sgp-mas-trm-2021": [ - "5.6.1", - "5.6.2", - "5.6.3", - "11.2.8" - ], - "apac-kor-pipa-2011": [ - "3", - "29" - ], - "apac-twn-pdpa-2025": [ - "21" - ], - "americas-bhs-dpa-2003": [ - "6", - "12" - ], - "americas-bmu-mba-coc-2020": [ - "4" - ], - "americas-bra-lgpd-2018": [ - "6.7", - "46", - "37", - "49" - ], "americas-can-osfi-b13-2022": [ "3.2", "3.2.4" - ], - "americas-can-pipeda-2000": [ - "Principle 7" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "4", - "26" - ], - "americas-mex-fdpa-2010": [ - "19", - "36", - "37" ] } }, @@ -2629,9 +2408,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to partition systems so that partitions reside in separate physical domains or environments.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to partition systems so that partitions reside in separate physical domains or environments. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2678,7 +2457,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -2691,7 +2471,7 @@ "general-cis-csc-8-1-ig3": [ "3.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1590.002" ], "general-nist-800-53-r4": [ @@ -2706,6 +2486,14 @@ "general-nist-800-160-vol-2-r1": [ "SC-32" ], + "general-nist-800-172-r3": [ + "03.13.16E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.16E", + "A.03.13.16E.ODP[01]", + "A.03.13.16E.ODP[02]" + ], "usa-federal-cms-marse-2-0": [ "SC-32", "SC-32-iS" @@ -2730,9 +2518,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to separate user functionality from system management functionality.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to separate user functionality from system management functionality. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2779,7 +2567,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -2801,7 +2590,7 @@ "general-iec-62443-3-3-2013": [ "SR 5.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1189", "T1190", @@ -2890,9 +2679,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement a separate execution domain for each executing process.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement a separate execution domain for each executing process. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2938,7 +2727,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -2960,7 +2750,7 @@ "general-iec-tr-60601-4-5-2021": [ "5.2 - CR 2.1" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1003.002", @@ -3065,9 +2855,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate security functions from non-security functions.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate security functions from non-security functions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3133,7 +2923,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -3143,7 +2934,7 @@ "general-govramp-high": [ "SC-03" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003.001", "T1021.003", "T1047", @@ -3247,9 +3038,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement underlying hardware separation mechanisms to facilitate process separation.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement underlying hardware separation mechanisms to facilitate process separation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3293,7 +3084,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -3333,9 +3125,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to maintain a separate execution domain for each thread in multi-threaded processing.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to maintain a separate execution domain for each thread in multi-threaded processing. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3379,7 +3171,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -3419,7 +3212,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to isolate, or logically separate, any application, service and/or process running with system privileges.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3482,7 +3275,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -3509,9 +3303,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent unauthorized and unintended information transfer via shared system resources.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent unauthorized and unintended information transfer via shared system resources. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3582,7 +3376,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -3601,7 +3396,7 @@ "general-govramp-high": [ "SC-04" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1020.001", "T1040", "T1070", @@ -3705,17 +3500,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SC-04" ], - "emea-deu-c5-2020": [ - "OPS-24", - "COS-06" - ], - "emea-isr-cmo-1-0": [ - "10.5", - "10.8" - ], - "emea-sau-ecc-1-2018": [ - "4-2-3-1" - ], "emea-gbr-def-stan-05-138-2024": [ "2416" ], @@ -3751,9 +3535,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically prevent the execution of unauthorized software programs.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically prevent the execution of unauthorized software programs. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3802,7 +3586,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -3886,7 +3671,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to determine the Mean Time to Failure (MTTF) for system components in specific environments of operation.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3939,7 +3724,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -3970,6 +3756,9 @@ "general-nist-800-171-r3": [ "03.16.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.02.b" + ], "general-nist-csf-2-0": [ "ID.AM-08" ], @@ -4010,9 +3799,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4074,7 +3863,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -4158,6 +3948,10 @@ "03.16.02.a", "03.16.02.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.02.a", + "A.03.16.02.b" + ], "general-nist-csf-2-0": [ "GV.SC-09", "ID.AM-08", @@ -4225,7 +4019,7 @@ "SA-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(55)" + "3.5.55" ], "emea-eu-nis2-annex-2024": [ "6.7.2(j)", @@ -4238,11 +4032,8 @@ "emea-sau-cgiot-2024": [ "2-15-3" ], - "emea-esp-boe-a-2022-7191": [ - "Article 36" - ], - "emea-esp-decree-311-2022": [ - "36" + "emea-sau-otcc-1-2022": [ + "2-2-1-1" ], "emea-gbr-caf-4-0": [ "A3.a (point 5)" @@ -4250,16 +4041,20 @@ "apac-aus-essential-8-2024": [ "ML3-P2" ], + "apac-aus-ps-cps-230-2023": [ + "25" + ], "apac-sgp-mas-trm-2021": [ - "7.3.1", - "7.3.2", - "7.3.3" + "7.3.2" ], "americas-can-osfi-b13-2022": [ "1.3.1", "2.2", "2.2.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.02.A", "03.16.02.B" @@ -4284,11 +4079,11 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -4352,7 +4147,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -4408,9 +4204,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SC-24" - ], - "emea-isr-cmo-1-0": [ - "9.17" ] } }, @@ -4432,11 +4225,11 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement fail-safe procedures when failure conditions occur.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement fail-safe procedures when failure conditions occur. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -4498,7 +4291,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -4549,9 +4343,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement non-persistent system components and services that are initiated in a known state and terminated upon the end of the session of use or periodically at an organization-defined frequency. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4600,7 +4394,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -4611,7 +4406,7 @@ "general-iec-62443-4-2-2019": [ "CR 4.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1505", "T1505.001", "T1505.002", @@ -4632,6 +4427,15 @@ "general-nist-800-160-vol-2-r1": [ "SI-14" ], + "general-nist-800-172-r3": [ + "03.14.15E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.15E.a", + "DS-A.03.14.15E.b", + "DS-A.03.14.15E.c", + "A.03.14.15E.ODP[02]" + ], "general-owasp-top-10-2025": [ "A01:2025", "A05:2025" @@ -4656,7 +4460,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to ensure that software and data needed for system component and service refreshes are obtained from trusted sources.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4722,7 +4526,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -4751,8 +4556,12 @@ "general-nist-800-160-vol-2-r1": [ "SI-14(01)" ], - "general-nist-800-172": [ - "3.14.4e" + "general-nist-800-172-r3": [ + "03.14.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.04E", + "A.03.14.04E.ODP[01]" ], "general-shared-assessments-sig-2025": [ "T.3" @@ -4768,9 +4577,89 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "SA-03(03)" + ] + } + }, + { + "control_id": "SEA-08.2", + "title": "Non-Persistent Information", + "family": "SEA", + "description": "Mechanisms exist to:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed.", + "scf_question": "Does the organization:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to:\n(1) Generate or refresh information per an organization-defined frequency; and\n(2) Delete information when no longer needed.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Session timeout configurations\n∙ Ephemeral file deletion after use", + "small": "∙ Session termination and ephemeral data deletion\n∙ Temporary file cleanup policies", + "medium": "∙ Automated ephemeral data lifecycle management\n∙ Session management with defined timeout and cleanup\n∙ Secure deletion of temporary data stores", + "large": "∙ Automated non-persistent information management\n∙ Defined data refresh cycles for non-persistent stores\n∙ Secure deletion enforcement", + "enterprise": "∙ Enterprise non-persistent information governance\n∙ Automated data lifecycle enforcement for ephemeral data\n∙ Integration with data classification and DLP\n∙ Continuous monitoring for data persistence policy compliance" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-BC-5", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-IR-1", + "R-IR-4" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-10", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Secure Engineering & Architecture", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.14.05E" ], - "emea-sau-ecc-1-2018": [ - "1-6-3-2" + "general-nist-800-172a-r3": [ + "DS-A.03.14.05E.a", + "A.03.14.05E.ODP[01]", + "DS-A.03.14.05E.b" ] } }, @@ -4792,9 +4681,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to validate information output from software programs and/or applications to ensure that the information is consistent with the expected content. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4841,11 +4730,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.002", "T1021.005", "T1048", @@ -4924,7 +4814,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to limit the dissemination of Personal Data (PD) to organization-defined elements identified in the Data Protection Impact Assessment (DPIA) and consistent with authorized purposes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4981,7 +4871,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -5008,9 +4899,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security safeguards to protect system memory from unauthorized code execution.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to implement security safeguards to protect system memory from unauthorized code execution. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5057,7 +4948,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -5076,7 +4968,7 @@ "general-govramp-high": [ "SI-16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003.001", "T1047", "T1055.009", @@ -5138,6 +5030,12 @@ "general-nist-800-171-r2": [ "NFO - SI-16" ], + "general-nist-800-172-r3": [ + "03.14.14E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.14E" + ], "usa-federal-fbi-cjis-6-0": [ "SI-16" ], @@ -5176,9 +5074,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeypots that are specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting and analyzing such attacks.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeypots that are specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting and analyzing such attacks. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5221,11 +5119,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1210", "T1211", "T1212" @@ -5248,6 +5147,14 @@ "IR-04(13)", "SC-26" ], + "general-nist-800-172-r3": [ + "03.13.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.08E[01]", + "DS-A.03.13.08E[02]", + "DS-A.03.13.08E[03]" + ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -5265,9 +5172,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "IR-04(13)" - ], - "emea-isr-cmo-1-0": [ - "23.5" ] } }, @@ -5289,9 +5193,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeyclients that proactively seek to identify malicious websites and/or web-based malicious code.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize honeyclients that proactively seek to identify malicious websites and/or web-based malicious code. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5331,11 +5235,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1210", "T1211", "T1212" @@ -5372,9 +5277,6 @@ ], "usa-federal-irs-1075-2021": [ "SC-35" - ], - "emea-isr-cmo-1-0": [ - "23.5" ] } }, @@ -5396,9 +5298,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a diverse set of technologies for system components to reduce the impact of technical vulnerabilities from the same Original Equipment Manufacturer (OEM).", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a diverse set of technologies for system components to reduce the impact of technical vulnerabilities from the same Original Equipment Manufacturer (OEM). ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5444,11 +5346,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1189", "T1190", "T1203", @@ -5476,8 +5379,11 @@ "general-nist-800-161-r1-level-3": [ "SC-29" ], - "general-nist-800-172": [ - "3.13.1e" + "general-nist-800-172-r3": [ + "03.13.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.01E" ], "apac-ind-sebi-2024": [ "EV.ST.S2" @@ -5502,7 +5408,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize virtualization techniques to support the employment of a diversity of operating systems and applications.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -5548,7 +5454,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -5567,6 +5474,12 @@ "general-nist-800-160-vol-2-r1": [ "SC-29(01)" ], + "general-nist-800-172-r3": [ + "03.13.07E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.07E" + ], "general-swift-cscf-2025": [ "1.3" ], @@ -5576,10 +5489,7 @@ "usa-federal-irs-1075-2021": [ "3.3.7" ], - "emea-deu-c5-2020": [ - "PSS-11" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1460", "ISM-1461", "ISM-1604", @@ -5588,29 +5498,17 @@ "ISM-1607" ], "apac-nzl-ism-3-9": [ - "22.2.12.C.01", - "22.2.12.C.02", - "22.2.12.C.03", - "22.2.12.C.04", - "22.2.13.C.01", - "22.2.13.C.02", - "22.2.14.C.01", - "22.2.14.C.02", - "22.2.14.C.03", - "22.2.14.C.04", - "22.2.14.C.05", - "22.2.14.C.06", - "22.2.14.C.07", - "22.2.15.C.01", - "22.2.15.C.02", - "22.2.15.C.03", - "22.2.15.C.04", - "22.2.15.C.05", - "22.2.15.C.06", - "22.2.15.C.07", - "22.2.16.C.01", - "22.2.16.C.02", - "22.2.16.C.03" + "20.2.12.C.01", + "20.2.12.C.02", + "20.2.12.C.03", + "20.2.12.C.04", + "20.2.14.C.01", + "20.2.14.C.03", + "20.2.14.C.04", + "20.2.14.C.07" + ], + "apac-sgp-mas-trm-2021": [ + "11.4.1" ] } }, @@ -5632,9 +5530,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize concealment and misdirection techniques for TAAS to confuse and mislead adversaries.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize concealment and misdirection techniques for TAAS to confuse and mislead adversaries. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5666,14 +5564,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-cr-cmm-2026": [ "CR4.1.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1189", "T1190", @@ -5715,8 +5614,11 @@ "SC-30(4)", "SC-30(5)" ], - "general-nist-800-172": [ - "3.13.3e" + "general-nist-800-172-r3": [ + "03.13.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.03E" ] } }, @@ -5738,7 +5640,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically introduce randomness into organizational operations and assets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5786,7 +5688,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -5810,6 +5713,12 @@ ], "general-nist-800-161-r1-level-3": [ "SC-30(2)" + ], + "general-nist-800-172-r3": [ + "03.13.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.02E" ] } }, @@ -5831,7 +5740,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to automatically change the location of processing and/or storage at random time intervals.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5879,7 +5788,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -5906,6 +5816,13 @@ ], "general-nist-800-161-r1-level-3": [ "SC-30(3)" + ], + "general-nist-800-172-r3": [ + "03.13.05E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.13.05E", + "A.03.13.05E.ODP[01]" ] } }, @@ -5927,9 +5844,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to distribute processing and storage across multiple physical locations.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to distribute processing and storage across multiple physical locations. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5991,11 +5908,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1070", "T1070.001", "T1070.002", @@ -6037,12 +5955,6 @@ "PE-23", "SC-36" ], - "general-nist-800-172": [ - "3.13.5e" - ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-sparta": [ "CM0074" ], @@ -6057,66 +5969,6 @@ ], "usa-federal-gsa-fedramp-5-li-saas": [ "PE-23" - ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } }, @@ -6138,7 +5990,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize non-modifiable executable programs that load and execute the operating environment and applications from hardware-enforced, read-only media.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6170,11 +6022,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1218.015", "T1542", @@ -6226,7 +6079,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a trusted communications path between the user and the security functions of the system.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6277,7 +6130,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -6290,8 +6144,8 @@ "general-iso-27018-2025": [ "8.5" ], - "emea-esp-ccn-stic-825-2023": [ - "7.2.6 [OP.ACC.6]" + "emea-esp-ccn-stic-825-2026": [ + "op.acc.6" ] } }, @@ -6315,7 +6169,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize system use notification / logon banners that display an approved system use notification message or banner before granting access to Technology Assets, Applications and/or Services (TAAS).", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6367,9 +6221,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-govramp": [ @@ -6393,7 +6247,7 @@ "general-iec-62443-4-2-2019": [ "CR 1.12" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1199" ], "general-nist-800-53-r4": [ @@ -6481,13 +6335,12 @@ "2406", "2407" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" + "16.1.44.C.02", + "16.1.44.C.03" ], "americas-can-itsp-10-171-2025": [ "03.01.09" @@ -6514,7 +6367,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to configure Microsoft Windows-based systems to display an approved logon banner before granting access to the system.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6566,9 +6419,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -6593,14 +6446,9 @@ "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], - "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.09" ] @@ -6626,7 +6474,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize a truncated system use notification / logon banner on systems not capable of displaying a logon banner from a centralized directory services technology (e.g., Active Directory, Entra ID, etc.).", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6678,9 +6526,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Secure Engineering & Architecture", "crosswalks": { "general-iec-62443-3-3-2013": [ @@ -6705,14 +6553,9 @@ "usa-federal-dow-cmmc-2-level-2": [ "ACL2.-3.1.9" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0408" ], - "apac-nzl-ism-3-9": [ - "16.1.48.C.01", - "16.1.48.C.02", - "16.1.48.C.03" - ], "americas-can-itsp-10-171-2025": [ "03.01.09" ] @@ -6722,8 +6565,8 @@ "control_id": "SEA-19", "title": "Previous Logon Notification", "family": "SEA", - "description": "Mechanisms exist to configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", - "scf_question": "Does the organization configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon?", + "description": "Mechanisms exist to configure systems that process, store or transmit sensitive and/or regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", + "scf_question": "Does the organization configure systems that process, store or transmit sensitive and/or regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon?", "relative_weight": 3, "conformity_cadence": "Annual", "evidence_requests": [], @@ -6736,7 +6579,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to configure systems that process, store or transmit sensitive/regulated data to notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6770,7 +6613,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -6785,11 +6629,6 @@ ], "general-nist-800-82-r3": [ "AC-09" - ], - "apac-nzl-ism-3-9": [ - "16.1.49.C.01", - "16.1.50.C.01", - "16.1.50.C.02" ] } }, @@ -6811,9 +6650,9 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", - "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize time-synchronization technology to synchronize all critical system clocks.", + "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize time-synchronization technology to synchronize all critical system clocks. ", "4": "Secure Engineering & Architecture (SEA) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6865,7 +6704,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -7000,6 +6840,9 @@ "usa-state-tx-txramp-2-0-level-2": [ "AU-08" ], + "emea-sau-ecc-1-2018": [ + "2-3-3-4" + ], "emea-gbr-def-stan-05-138-2024": [ "2421" ], @@ -7012,7 +6855,7 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2421" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0988" ], "apac-jpn-ismap": [ @@ -7021,6 +6864,9 @@ "12.4.4.2", "12.4.4.3", "12.4.4.4.PB" + ], + "americas-arg-ppd-2018": [ + "E.1.2-9" ] } }, @@ -7042,7 +6888,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to utilize an application container (virtualization approach) to isolate to a known set of dependencies, access methods and interfaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7073,7 +6919,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -7087,7 +6934,7 @@ "title": "Privileged Environments", "family": "SEA", "description": "Mechanisms exist to prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS).", - "scf_question": "Does the organization prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS).", + "scf_question": "Does the organization prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of Technology Assets, Applications and/or Services (TAAS)?", "relative_weight": 5, "conformity_cadence": "Annual", "evidence_requests": [], @@ -7100,7 +6947,7 @@ }, "maturity": { "0": "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.", - "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.", + "1": "Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions. ", "2": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.\n▪ 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.\n▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.\n▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).", "3": "Secure Engineering & Architecture (SEA) 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:\n▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.\n▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).\n▪ 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 SEA 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).\n▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).\n▪ An implemented and operational capability exists to prevent privileged operating environments from existing within unprivileged operating environments, including physical or virtual deployments of TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7175,7 +7022,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Secure Engineering & Architecture", "crosswalks": { @@ -7183,7 +7031,7 @@ "ML2-P4", "ML3-P4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1687" ] } diff --git a/docs/api/families/TDA.json b/docs/api/families/TDA.json index 63241e5c..2da12a8f 100644 --- a/docs/api/families/TDA.json +++ b/docs/api/families/TDA.json @@ -1,7 +1,7 @@ { "family_code": "TDA", "family_name": "Technology Development & Acquisition", - "control_count": 70, + "control_count": 74, "controls": [ { "control_id": "TDA-01", @@ -26,7 +26,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -128,7 +128,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -141,7 +142,7 @@ ], "general-cis-csc-8-1": [ "15.7", - "16.0" + "16" ], "general-cis-csc-8-1-ig3": [ "15.7" @@ -211,7 +212,7 @@ "A.6.1.3", "A.6.2.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -308,11 +309,21 @@ "03.17.02" ], "general-nist-800-171a-r3": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", "A.03.16.01.ODP[01]", + "A.03.16.01", "A.03.17.02[04]", "A.03.17.02[05]", "A.03.17.02[06]" ], + "general-nist-800-172-r3": [ + "03.16.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.16.01E" + ], "general-nist-800-218": [ "PO.1", "PO.3", @@ -351,9 +362,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.1" ], - "general-scf-dpmp-2025": [ - "7.0" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "1.d", "4.b" @@ -460,8 +468,8 @@ "Article 14.4" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(67)", - "3.6.2(74)" + "3.6.2.67", + "3.6.2.74" ], "emea-eu-dora-2023": [ "Article 13.7" @@ -476,73 +484,28 @@ "6.2.2(c)", "6.2.4" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ + "1.2(f)", "7.7", "7.8", "7.9", - "7.10", - "7.11", - "7.12", - "7.13", - "7.14" + "7.10" ], "emea-deu-c5-2020": [ - "DEV-01" - ], - "emea-isr-cmo-1-0": [ - "17.1", - "17.9" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" + "BEI-01" ], "emea-sau-cscc-1-2019": [ - "2-13", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3", - "2-5-4" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" + "1-3-2", + "2-13-1" ], - "emea-sau-sama-csf-1-2017": [ - "3.3.6" + "emea-esp-decree-311-2022": [ + "Article 12(6)(g)", + "Article 19(1)" ], - "emea-esp-boe-a-2022-7191": [ - "Article 19.1", - "Article 19.2", - "Article 19.2(a)", - "Article 19.2(b)", - "Article 19.2(c)", - "Article 19.3" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], - "emea-esp-decree-311-2022": [ - "19.1", - "19.2", - "19.2(a)", - "19.2(b)", - "19.2(c)", - "19.3" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.1.3 [OP.PL.3]", - "8.6.1 [MP.SW.1]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0938", "ISM-1780" ], @@ -553,7 +516,13 @@ "14.2.1.13.PB", "14.2.7" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -561,38 +530,21 @@ "HSUP42" ], "apac-sgp-mas-trm-2021": [ - "5.3.1", - "5.3.2", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" - ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" + "5.3.2" + ], + "americas-arg-ppd-2018": [ + "H" + ], + "americas-bmu-mba-coc-2020": [ + "6.1-BP3" ], "americas-can-osfi-b13-2022": [ "2.4.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3", + "2.4.4" + ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03", @@ -711,7 +663,8 @@ "MT-24", "MT-25", "MT-26", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -837,6 +790,16 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], + "general-nist-800-172-r3": [ + "03.16.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.16.01E", + "A.03.16.01E.ODP[01]" + ], "general-nist-800-218": [ "PO.1", "PO.1.1", @@ -870,9 +833,6 @@ "A09:2025", "A10:2025" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-ul-2900-1-2017": [ "7.1", "7.1.1", @@ -1065,61 +1025,53 @@ "emea-eu-ai-act-2024": [ "Article 14.3(b)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 5", - "Article 5.1", - "Article 5.2", - "Article 10.1", - "Article 10.5", - "Article 10.6", - "Article 10.9", - "Article 10.10", - "Article 10.11", - "Article 13.1", - "Article 13.2", - "Article 13.2(a)", - "Article 13.2(b)", - "Article 13.2(c)", - "Article 13.3", - "Article 13.4", - "Article 13.5", - "Article 13.6", - "Article 14.1", - "Article 14.2", - "Article 14.2(a)", - "Article 14.2(b)", - "Article 14.3", - "Article 14.4" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(j)", - "Annex 1.2(2)", - "Annex 2.1", - "Annex 2.2", - "Annex 2.3", - "Annex 2.4", - "Annex 2.5", - "Annex 2.6", - "Annex 2.7", - "Annex 2.8", - "Annex 2.9", - "Annex 2.9(a)", - "Annex 2.9(b)", - "Annex 2.9(c)", - "Annex 2.9(d)", - "Annex 6 Module A.3", - "Annex 6 Module A.4.1", - "Annex 6 Module C.2.1", - "Annex 6 Module C.3.1", - "Annex 6 Module H.2", - "Annex 6 Module H.3.2", - "Annex 6 Module H.3.4", - "Annex 6 Module H.5.1", - "Annex 6 Module H.5.2", - "Annex 6 Module H.6" - ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(1)", + "Article 13(5)", + "Article 13(8)", + "Article 13(10)", + "Article 13(11)", + "Article 13(13)", + "Article 13(14)", + "Article 13(15)", + "Article 13(16)", + "Article 13(17)", + "Article 13(18)", + "Article 13(19)", + "Article 13(20)", + "Article 13(21)", + "Article 13(22)", + "Article 13(23)", + "Article 19(1)", + "Article 19(2)", + "Article 19(2)(c)", + "Article 19(2)(d)", + "Article 19(3)", + "Article 19(4)", + "Article 19(5)", + "Article 19(6)", + "Article 20(1)", + "Article 20(2)", + "Article 20(2)(a)", + "Article 20(2)(b)", + "Article 20(3)", + "Article 20(4)", + "Article 24(1)", + "Article 30(1)", + "Article 30(2)", + "Article 30(3)", + "Article 30(4)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(1)", + "Annex I, Part I(2)(g)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)", + "Annex I, Part I(2)(m)", + "Annex I, Part II(1)", + "Annex I, Part II(2)" ], "emea-eu-dora-2023": [ "Article 13.7" @@ -1129,36 +1081,25 @@ "7.8", "7.9", "7.10", - "7.11", "7.12", "7.13", "7.14" ], - "emea-isr-cmo-1-0": [ - "17.9" - ], - "emea-qat-pdppl-2020": [ - "11.4", - "11.5", - "11.6" - ], "emea-sau-cscc-1-2019": [ "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], - "emea-sau-otcc-1-2022": [ - "1-1-2", - "4-1-1-1" + "emea-sau-ecc-1-2018": [ + "1-6-3-4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1796", "ISM-1797", "ISM-1798" ], + "apac-aus-cop-sitc-2020": [ + "11" + ], "apac-chn-cybersecurity-law-2017": [ "Article 22", "Article 46", @@ -1168,7 +1109,13 @@ "14.1.1", "14.2.7.11" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.2", + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -1198,17 +1145,16 @@ "12.4.7.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.8.1", - "5.8.2", - "7.6.1", - "7.6.2", - "14.4.1", - "14.4.2", - "14.4.3" + "5.5.2", + "14.1.5", + "14.1.7" ], "americas-can-osfi-b13-2022": [ "2.4.3" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] @@ -1234,11 +1180,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize integrity validation mechanisms for security updates.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -1292,14 +1238,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-nist-800-172": [ - "3.14.1e", - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -1316,7 +1259,7 @@ "title": "Malware Testing Prior to Release", "family": "TDA", "description": "Mechanisms exist to utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update.", - "scf_question": "Does the organization utilize at least one (1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update?", + "scf_question": "Does the organization utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -1329,11 +1272,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize at least one(1) malware detection tool to identify if any known malware exists in the final binaries of the product or security update.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -1384,7 +1327,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -1397,6 +1341,9 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)" ] } }, @@ -1506,9 +1453,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "usa-federal-dow-zt-roadmap-1-1": [ @@ -1517,6 +1464,12 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-sgp-mas-trm-2021": [ + "6.3.1" + ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3" ] } }, @@ -1540,7 +1493,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to design, develop and produce Technology Assets, Applications and/or Services (TAAS) in such a way that risk-based technical and functional specifications ensure Minimum Viable Product (MVP) criteria establish an appropriate level of security and resiliency based on applicable risks and threats.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1631,7 +1584,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -1742,6 +1696,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PO.1", "PO.1.1", @@ -1818,33 +1775,33 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-04" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(1)", - "Annex 1.1(3)(b)", - "Annex 1.1(3)(c)", - "Annex 1.1(3)(d)", - "Annex 1.1(3)(f)", - "Annex 1.1(3)(g)", - "Annex 1.1(3)(i)", - "Annex 6 Module A.3" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" ], "emea-deu-bsrit-2017": [ "7.7" ], - "emea-deu-c5-2020": [ - "DEV-02" - ], "emea-sau-cscc-1-2019": [ "2-13-1", "2-13-2", + "2-13-3", "2-13-3-1", "2-13-3-2", "2-13-3-3", "2-13-3-4" ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" + ], + "apac-aus-cop-sitc-2020": [ + "4" + ], "apac-jpn-ismap": [ "14.1.1.2", "14.1.1.3", @@ -1859,12 +1816,18 @@ "14.1.1.16", "14.2.1.3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "12.1", + "12.5" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP31", "HML31" ], "apac-sgp-mas-trm-2021": [ - "5.3.3" + "5.4.3", + "5.5.2" ], "americas-can-itsp-10-171-2025": [ "03.16.01" @@ -1892,9 +1855,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to identify early in the Secure Development Life Cycle (SDLC), the functions, ports, protocols and services intended for use.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to identify early in the Secure Development Life Cycle (SDLC), the functions, ports, protocols and services intended for use. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1962,7 +1925,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -2044,14 +2008,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-04 (09)" ], - "emea-isr-cmo-1-0": [ - "12.9", - "12.29" - ], - "emea-sau-ecc-1-2018": [ - "2-5-3-5", - "2-15-3-3" - ], "apac-nzl-ism-3-9": [ "18.1.15.C.01", "18.1.15.C.02", @@ -2078,7 +2034,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit the use of commercially-provided Information Assurance (IA) and IA-enabled IT products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile or the cryptographic module is FIPS-validated or NSA-approved.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2114,7 +2070,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -2258,7 +2215,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2331,7 +2288,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -2438,9 +2396,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.1" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "2" ], @@ -2469,23 +2424,25 @@ "emea-eu-ai-act-2024": [ "Article 14.1" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(74)" + "emea-sau-ecc-1-2018": [ + "1-6-3-2" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.1 [MP.SW.1]" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" ], - "apac-sgp-mas-trm-2021": [ - "6.1.4", - "6.1.5", - "6.1.6", - "6.1.7" + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.14" ], "americas-can-osfi-b13-2022": [ "2.4.3", "2.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.3", + "2.4.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -2509,7 +2466,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure vendors / manufacturers:\n(1) Deliver the Technology Asset, Application and/or Service (TAAS) with a pre-established, secure configuration implemented; and\n(2) Use the pre-established, secure configuration as the default for any subsequent TAAS reinstallation or upgrade.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2581,7 +2538,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -2606,15 +2564,15 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4", "PW.5.1", "PW.9.1", "PW.9.2" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-dhs-cisa-ssdaf-2024": [ "1.e" ], @@ -2630,15 +2588,17 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(a)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(b)", + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -2665,9 +2625,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require process owners to identify, document and justify the business need for the ports, protocols and other services necessary to operate their technology solutions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require process owners to identify, document and justify the business need for the ports, protocols and other services necessary to operate their technology solutions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2727,7 +2687,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -2782,9 +2743,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to mitigate the risk associated with the use of insecure ports, protocols and services necessary to operate technology solutions.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to mitigate the risk associated with the use of insecure ports, protocols and services necessary to operate technology solutions. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2846,7 +2807,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -2891,9 +2853,6 @@ "1.2.6", "2.2.5" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ] @@ -2917,7 +2876,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to include appropriate security, compliance and resilience representatives in the product feature and/or functionality change control review process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3004,9 +2963,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-iec-62443-4-1-2018": [ @@ -3027,17 +2986,14 @@ "RV.1", "RV.3.4" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-irs-1075-2021": [ "SA-10(CE-7)" ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } }, @@ -3059,7 +3015,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to minimize the attack surface of Technology Assets, Applications and/or Services (TAAS) by reasonably mitigating known exploitable vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3146,19 +3102,17 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(2)", - "Annex 1.1(3)(h)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(a)", + "Annex I, Part I(2)(d)" ] } }, @@ -3180,7 +3134,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to deliver security updates to Technology Assets, Applications and/or Services (TAAS), where applicable, through:\n(1) Automatic updates; and\n(2) Notification of available updates to affected users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3266,7 +3220,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -3285,20 +3240,27 @@ "SUM-5(d)", "SUM-5(e)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.6" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(8)", + "Article 13(9)", + "Article 13(11)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(c)", + "Annex I, Part I(2)(l)", + "Annex I, Part II(2)", + "Annex I, Part II(3)", + "Annex I, Part II(4)", + "Annex I, Part II(5)", + "Annex I, Part II(6)", + "Annex I, Part II(7)", + "Annex I, Part II(8)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.1(3)(k)", - "Annex 1.2(2)", - "Annex 1.2(7)", - "Annex 1.2(8)" + "emea-deu-bsrit-2017": [ + "7.12" ] } }, @@ -3320,7 +3282,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to regularly review Technology Assets, Applications and/or Services (TAAS) for an appropriate level of security and resiliency based on applicable risks and threats.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3407,7 +3369,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -3428,14 +3391,15 @@ "SUM-1(2)(b)", "SUM-1(2)(c)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(3)" + "apac-sgp-mas-trm-2021": [ + "5.6.1", + "5.7.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.12" ] } }, @@ -3457,7 +3421,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to disclose information about vulnerabilities to relevant stakeholders, including:\n(1) A description of the vulnerability(ies);\n(2) Affected product(s) and/or service(s);\n(3) Potential impact of the vulnerability(ies);\n(4) Severity of the vulnerability(ies); and\n(5) Guidance to remediate the vulnerability(ies).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3543,7 +3507,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -3552,9 +3517,6 @@ "DM-5(a)", "DM-5(b)" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-federal-nerc-cip-2024": [ "CIP-013-2 1.2.4" ], @@ -3562,15 +3524,26 @@ "7123(c)(6)", "7123(c)(14)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.7" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(4)", - "Annex 1.2(6)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 14(1)", + "Article 14(2)(a)", + "Article 14(2)(b)", + "Article 14(2)(c)", + "Article 14(2)(i)", + "Article 14(2)(i)(ii)", + "Article 14(2)(i)(iii)", + "Article 20(3)", + "Article 20(4)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(5)", + "Annex I, Part II(6)" ], "emea-eu-nis2-annex-2024": [ "6.10.2(e)" + ], + "emea-deu-c5-2020": [ + "RB-21-DOAR" ] } }, @@ -3592,7 +3565,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to categorize applicable security and resiliency requirements for products and/or services with digital elements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3675,49 +3648,16 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 3 Class 1.1", - "Annex 3 Class 1.2", - "Annex 3 Class 1.3", - "Annex 3 Class 1.4", - "Annex 3 Class 1.5", - "Annex 3 Class 1.6", - "Annex 3 Class 1.7", - "Annex 3 Class 1.8", - "Annex 3 Class 1.9", - "Annex 3 Class 1.10", - "Annex 3 Class 1.11", - "Annex 3 Class 1.12", - "Annex 3 Class 1.13", - "Annex 3 Class 1.14", - "Annex 3 Class 1.15", - "Annex 3 Class 1.16", - "Annex 3 Class 1.17", - "Annex 3 Class 1.18", - "Annex 3 Class 1.19", - "Annex 3 Class 1.20", - "Annex 3 Class 1.21", - "Annex 3 Class 1.22", - "Annex 3 Class 1.23", - "Annex 3 Class 2.1", - "Annex 3 Class 2.2", - "Annex 3 Class 2.3", - "Annex 3 Class 2.4", - "Annex 3 Class 2.5", - "Annex 3 Class 2.6", - "Annex 3 Class 2.7", - "Annex 3 Class 2.8", - "Annex 3 Class 2.9", - "Annex 3 Class 2.10", - "Annex 3 Class 2.11", - "Annex 3 Class 2.12", - "Annex 3 Class 2.13", - "Annex 3 Class 2.14", - "Annex 3 Class 2.15" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(1)" + ], + "apac-mys-bnm-rmit-2025": [ + "12.1" ] } }, @@ -3739,7 +3679,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to notify applicable stakeholders about potentially exploitable vulnerabilities in organization-developed Technology Assets, Applications and/or Services (TAAS), as required by statutory, regulatory and/or contractual obligations.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3822,16 +3762,14 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)", "7123(c)(14)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.1" ] } }, @@ -3853,7 +3791,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers to use an industry-defined secure logging format to generate event logs for specified event types at organization-defined level of detail.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -3916,7 +3854,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -3946,9 +3885,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, custom-develops business-critical TAAS, when Commercial Off The Shelf (COTS) solutions are unavailable.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize only Commercial Off-the-Shelf (COTS) security products.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize only Commercial Off-the-Shelf (COTS) security products. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3985,7 +3924,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -4006,6 +3946,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4", "PW.4.1" @@ -4013,10 +3956,6 @@ "general-sparta": [ "CM0007" ], - "apac-sgp-mas-trm-2021": [ - "5.3.3", - "6.1.3" - ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -4040,7 +3979,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to obtain security, compliance and resilience technologies from different suppliers to minimize supply chain risk.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4102,9 +4041,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-nist-800-53-r4": [ @@ -4137,6 +4076,12 @@ "PL-8(2)", "SR-3(1)" ], + "general-nist-800-172-r3": [ + "03.15.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.15.03E" + ], "usa-federal-gsa-fedramp-5-low": [ "SR-03(01)" ], @@ -4173,7 +4118,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to obtain, protect and distribute administrator documentation for Technology Assets, Applications and/or Services (TAAS) that describe:\n(1) Secure configuration, installation and operation of the TAAS;\n(2) Effective use and maintenance of security features/functions; and\n(3) Known vulnerabilities regarding configuration and use of administrative (e.g., privileged) functions.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4221,7 +4166,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -4421,22 +4367,25 @@ "emea-eu-ai-act-2024": [ "Article 11.1" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(4)", + "Article 13(7)", + "Article 31(1)" + ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(73)" + "3.6.2.73" ], "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6", - "17.10" - ], - "emea-sau-otcc-1-2022": [ - "1-1-2" + "UP-01", + "KOS-07" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ], + "apac-aus-cop-sitc-2020": [ + "11", + "12" + ], "apac-jpn-ismap": [ "14.1.1.15", "14.2.7.10" @@ -4444,9 +4393,6 @@ "apac-nzl-ism-3-9": [ "3.4.10.C.01", "3.4.10.C.02" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.4" ] } }, @@ -4473,9 +4419,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ 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. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4530,9 +4476,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-govramp": [ @@ -4648,17 +4594,11 @@ "SA-04 (01)", "SA-04 (02)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6", - "17.10" + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(7)", + "Article 31(1)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1798" ] } @@ -4683,7 +4623,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate, or obtain, a Software Bill of Materials (SBOM) for Technology Assets, Applications and/or Services (TAAS) that lists software packages in use, including versions and applicable licenses.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -4733,7 +4673,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -4810,22 +4751,23 @@ "4e(iii)", "4e(vii)" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 11.7" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(1)", - "Annex 1.2(6)" + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(1)" ], "emea-sau-cgiot-2024": [ "4-1-3" ], - "apac-aus-ism-2024-june": [ - "ISM-1730" + "apac-aus-ism-2026-march": [ + "ISM-1730", + "ISM-2054", + "ISM-2056" ], "apac-ind-sebi-2024": [ "GV.SC.S5", "PR.IP.S5" + ], + "apac-mys-bnm-rmit-2025": [ + "10.15" ] } }, @@ -4834,7 +4776,7 @@ "title": "Developer Architecture & Design", "family": "TDA", "description": "Mechanisms exist to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", - "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection?", + "scf_question": "Does the organization require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of its security architecture which is established within and is an integrated part of its enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection?", "relative_weight": 8, "conformity_cadence": "Annual", "evidence_requests": [ @@ -4849,7 +4791,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a design specification and security architecture that: \n(1) Is consistent with and supportive of the organization's security architecture which is established within and is an integrated part of the organization's enterprise architecture;\n(2) Accurately and completely describes the required security functionality and the allocation of security, compliance and resilience controls among physical and logical components; and\n(3) Expresses how individual security functions, mechanisms and services work together to provide required security capabilities and a unified approach to protection.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4948,19 +4890,22 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.1", + "16.10" ], "general-govramp": [ "SA-17" @@ -4992,7 +4937,7 @@ "8.27", "8.30" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -5033,6 +4978,9 @@ "general-nist-800-171-r3": [ "03.16.01" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PW.4.2", "RV.1.1" @@ -5071,35 +5019,9 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.6" - ], - "emea-sau-ecc-1-2018": [ - "1-6-3-4" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "apac-aus-ism-2026-march": [ + "ISM-2033", + "ISM-2043" ], "americas-can-itsp-10-171-2025": [ "03.16.01" @@ -5124,7 +5046,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to secure physical diagnostic and test interfaces to prevent misuse.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5178,7 +5100,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -5225,7 +5148,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to enable endpoint devices to log events and generate alerts for attempts to access diagnostic and test interfaces.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5279,7 +5202,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -5314,11 +5238,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to develop applications based on Secure Software Development Practices (SSDP).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -5388,7 +5312,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -5416,19 +5341,22 @@ "PI1.5-POF4" ], "general-cis-csc-8-1": [ - "16.0", + "16", "16.1", "16.5", + "16.10", "16.11" ], "general-cis-csc-8-1-ig2": [ "16.1", "16.5", + "16.10", "16.11" ], "general-cis-csc-8-1-ig3": [ "16.1", "16.5", + "16.10", "16.11" ], "general-cobit-2019": [ @@ -5503,7 +5431,7 @@ "A.6.1.3", "A.6.2.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -5592,6 +5520,9 @@ "3.13.2[b]", "3.13.2[e]" ], + "general-nist-800-171a-r3": [ + "A.03.16.01" + ], "general-nist-800-218": [ "PO.1", "PW.1", @@ -5639,10 +5570,6 @@ "6.2.1", "6.2.4" ], - "general-scf-dpmp-2025": [ - "5.12", - "7.1" - ], "general-sparta": [ "CM0017", "CM0043" @@ -5726,8 +5653,16 @@ "SA-03", "SA-15" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" + "emea-eu-cyber-resilience-act-2024": [ + "Article 24(1)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part I(2)(e)", + "Annex I, Part I(2)(f)", + "Annex I, Part I(2)(h)", + "Annex I, Part I(2)(i)", + "Annex I, Part I(2)(j)", + "Annex I, Part I(2)(k)" ], "emea-eu-nis2-2022": [ "Article 21.3" @@ -5740,25 +5675,16 @@ "7.10" ], "emea-deu-c5-2020": [ - "DEV-02", - "DEV-07", - "DEV-08" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.6", - "17.9", - "17.20", - "17.25" + "UP-01-BP2", + "BEI-01-BP1", + "BEI-01-BP4", + "BEI-01-DOAR", + "BEI-02" ], "emea-sau-cscc-1-2019": [ "1-3-2-3", "2-13-1", - "2-13-2", - "2-13-3-1", - "2-13-3-2", - "2-13-3-3", - "2-13-3-4" + "2-13-2" ], "emea-sau-cgiot-2024": [ "2-14-3" @@ -5767,17 +5693,47 @@ "1-6-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-60", - "TPC-62" + "VII.B.TPC-74" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.6.4", + "3.3.6.5", + "3.3.6.5.a", + "3.3.6.5.b", + "3.3.6.5.c", + "3.3.6.5.d", + "3.3.6.5.e", + "3.3.6.5.f", + "3.3.6.5.g" + ], + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.info.4", + "mp.s.2" ], "emea-gbr-caf-4-0": [ "A4.b" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0401", "ISM-1239", "ISM-1419", - "ISM-1552" + "ISM-1552", + "ISM-1849", + "ISM-1922", + "ISM-2032", + "ISM-2035", + "ISM-2041", + "ISM-2045", + "ISM-2063", + "ISM-2064", + "ISM-2065", + "ISM-2066", + "ISM-2067" + ], + "apac-aus-cop-sitc-2020": [ + "4", + "6" ], "apac-jpn-ismap": [ "14.1.1.1", @@ -5785,7 +5741,7 @@ "14.2.1.9", "14.2.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP50", "HML50" ], @@ -5796,35 +5752,21 @@ "14.4.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "5.3.2", "6.1.1", "6.1.2", "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3" + "6.2.2" ], "americas-bmu-mba-coc-2020": [ "6.20" ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" - ], "americas-can-osfi-b13-2022": [ "2.4.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.4.2", + "2.4.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.01" ] @@ -5852,7 +5794,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developer of the Technology Asset, Application and/or Service (TAAS) to perform a criticality analysis at organization-defined decision points in the Secure Development Life Cycle (SDLC).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -5904,9 +5846,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -5921,7 +5863,7 @@ "general-iso-27018-2025": [ "8.29" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1195.003", "T1495", "T1542", @@ -5989,15 +5931,18 @@ "RA-9", "SA-15(3)" ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[01]" + ], "general-nist-800-218": [ "PW.1" ], "general-nist-csf-2-0": [ "PR.PS-06" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-sparta": [ "CM0022" ], @@ -6042,11 +5987,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.2" ], "apac-nzl-ism-3-9": [ "14.4.6.C.01", @@ -6080,7 +6022,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform threat modelling and other secure design techniques, to ensure that threats to software and solutions are identified and accounted for.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6132,7 +6074,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -6282,18 +6225,22 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], "emea-sau-cgiot-2024": [ "2-12-1" ], - "apac-aus-ism-2024-june": [ - "ISM-1238" + "apac-aus-ism-2026-march": [ + "ISM-1238", + "ISM-2039" + ], + "apac-aus-ps-cps-230-2023": [ + "27(c)" ], "apac-jpn-ismap": [ "14.2.7.3" ], + "apac-mys-bnm-rmit-2025": [ + "9.2" + ], "apac-nzl-ism-3-9": [ "14.4.6.C.01", "14.4.6.C.02", @@ -6302,6 +6249,9 @@ "americas-can-osfi-b13-2022": [ "2.4.4", "3.1.6" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.6" ] } }, @@ -6326,7 +6276,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a Software Assurance Maturity Model (SAMM) to govern a secure development lifecycle for the development of Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6375,7 +6325,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -6448,29 +6399,10 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.1 [MP.SW.1]" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.1", - "6.1.2", - "6.2.1", - "6.2.2", - "6.3.1", - "6.3.2", - "6.4.1", - "6.4.2", - "6.4.3", - "6.4.4", - "6.4.5", - "6.4.6", - "6.4.7", - "6.4.8", - "6.5.1", - "6.5.2", - "6.5.3", - "7.6.1", - "7.6.2" + "apac-aus-ism-2026-march": [ + "ISM-2025", + "ISM-2034", + "ISM-2102" ] } }, @@ -6492,7 +6424,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically improve the accuracy, consistency and comprehensiveness of secure practices throughout the asset's lifecycle.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6533,7 +6465,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -6552,6 +6485,9 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-aus-ism-2026-march": [ + "ISM-2031" ] } }, @@ -6575,7 +6511,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to have an independent review of the software design to validate:\n(1) Applicable security, compliance and resilience requirements are met; and\n(2) Identified risks are remediated.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6620,9 +6556,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ @@ -6658,9 +6594,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.2.3" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "general-sparta": [ "CM0043" ], @@ -6673,24 +6606,9 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.8(a)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)" - ], "emea-sau-cgiot-2024": [ "2-14-3" ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.2 [MP.SW.2]" - ], - "apac-sgp-mas-trm-2021": [ - "5.7.4", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", - "6.1.6", - "6.1.7" - ], "americas-can-osfi-b13-2022": [ "2.4.1", "2.4.2" @@ -6715,7 +6633,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to assess software design processes that includes: \n(1) Conducting Root Cause Analysis (RCA) to identify the underlying causes of issues or failures;\n(2) Developing actions to address the root cause of the issue or failure; and\n(3) Implementing the actions and monitoring the implementation for effectiveness.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6756,7 +6674,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -6784,43 +6703,43 @@ ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" + ], + "apac-aus-ism-2026-march": [ + "ISM-1909" ] } }, { - "control_id": "TDA-07", - "title": "Secure Development Environments", + "control_id": "TDA-06.7", + "title": "Programming Language Selection", "family": "TDA", - "description": "Mechanisms exist to maintain a segmented development network to ensure a secure development environment.", - "scf_question": "Does the organization maintain a segmented development network to ensure a secure development environment?", - "relative_weight": 9, + "description": "Mechanisms exist to:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions.", + "scf_question": "Does the organization:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions?", + "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "Process", - "nist_csf_function": "Protect", + "nist_csf_function": "Identify", "scrm_focus": { - "strategic": true, + "strategic": false, "operational": true, - "tactical": true + "tactical": false }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a segmented development network to ensure a secure development environment.", - "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to:\n(1) Define organization-approved programming language(s) for software development; and\n(2) Document the justification for selection decisions.", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, - "profiles": [ - "SCRMS", - "CORE Mergers, Acquisitions & Divestitures (MA&D)" - ], + "profiles": [], "possible_solutions": { - "micro_small": "∙ Keep software development tools secure and updated", - "small": "∙ Secure development environment policy\n∙ Control access to dev tools", - "medium": "∙ Formal secure development environment standards\n∙ Dev tool security controls", - "large": "∙ Enterprise secure development environment program\n∙ Dev tool access controls and monitoring", - "enterprise": "∙ Enterprise secure development environment platform\n∙ DevSecOps toolchain security\n∙ Dev tool lifecycle management" + "micro_small": "∙ Document approved programming languages for internal development\n∙ Prefer memory-safe languages for security-sensitive code (e.g., Rust, Go, Python)", + "small": "∙ Approved programming language list\n∙ Memory-safe language preference for new development\n∙ Documented justification for language choices", + "medium": "∙ Formal programming language governance standard\n∙ Memory-safe language requirements for security-critical code\n∙ Language selection approval process", + "large": "∙ Enterprise programming language governance program\n∙ Enforcement of approved languages in CI/CD\n∙ Security-focused language selection criteria (e.g., CISA memory safety guidance)", + "enterprise": "∙ Enterprise programming language governance with automated enforcement\n∙ CISA Memory Safe Roadmap alignment\n∙ Automated language compliance checking in CI/CD pipeline\n∙ Developer training on approved languages" }, "risks": [ "R-AC-1", @@ -6849,7 +6768,6 @@ "R-GV-5", "R-GV-6", "R-GV-7", - "R-GV-8", "R-IR-1", "R-IR-2", "R-IR-3", @@ -6877,11 +6795,117 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- new control - ISM 2040", "family_name": "Technology Development & Acquisition", "crosswalks": { - "general-cis-csc-8-1": [ + "emea-deu-c5-2020": [ + "BEI-01-BP3" + ], + "apac-aus-ism-2026-march": [ + "ISM-2040", + "ISM-2041" + ] + } + }, + { + "control_id": "TDA-07", + "title": "Secure Development Environments", + "family": "TDA", + "description": "Mechanisms exist to maintain a segmented development network to ensure a secure development environment.", + "scf_question": "Does the organization maintain a segmented development network to ensure a secure development environment?", + "relative_weight": 9, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": true, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a segmented development network to ensure a secure development environment. ", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [ + "SCRMS", + "CORE Mergers, Acquisitions & Divestitures (MA&D)" + ], + "possible_solutions": { + "micro_small": "∙ Keep software development tools secure and updated", + "small": "∙ Secure development environment policy\n∙ Control access to dev tools", + "medium": "∙ Formal secure development environment standards\n∙ Dev tool security controls", + "large": "∙ Enterprise secure development environment program\n∙ Dev tool access controls and monitoring", + "enterprise": "∙ Enterprise secure development environment platform\n∙ DevSecOps toolchain security\n∙ Dev tool lifecycle management" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "general-cis-csc-8-1": [ "16.8" ], "general-cis-csc-8-1-ig2": [ @@ -6977,30 +7001,22 @@ "7123(c)(14)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(72)" + "3.6.2.72" ], "emea-eu-nis2-annex-2024": [ "6.2.2(c)", "6.8.2(h)" ], - "emea-deu-c5-2020": [ - "DEV-02", - "DEV-10" - ], - "emea-isr-cmo-1-0": [ - "10.1" - ], "emea-sau-cscc-1-2019": [ "1-3-2-4" ], "emea-sau-otcc-1-2022": [ "1-4-1-4" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0400", "ISM-1419" ], @@ -7020,6 +7036,9 @@ "14.2.6.11", "14.2.6.12" ], + "apac-mys-bnm-rmit-2025": [ + "10.7" + ], "apac-nzl-ism-3-9": [ "14.4.4.C.01" ], @@ -7046,7 +7065,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7142,7 +7161,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -7252,14 +7272,11 @@ "7123(c)(14)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(72)" + "3.6.2.72" ], "emea-deu-c5-2020": [ - "DEV-10" - ], - "emea-isr-cmo-1-0": [ - "10.1" + "BEI-01-BP2", + "BEI-11" ], "emea-sau-cscc-1-2019": [ "1-3-2-4" @@ -7267,13 +7284,13 @@ "emea-sau-ecc-1-2018": [ "2-5-3-2" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-4" + "emea-sau-sama-csf-1-2017": [ + "3.3.7.4.g" ], - "emea-sau-sacs-002-2022": [ - "TPC-73" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0400", "ISM-1273", "ISM-1274" @@ -7293,15 +7310,30 @@ "12.1.4.8", "12.1.4.9" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.7", + "10.26", + "10.28" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP58", "HML58" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP50" ], + "apac-nzl-ism-3-9": [ + "20.2.14.C.06" + ], "apac-sgp-mas-trm-2021": [ "5.7.3" + ], + "americas-arg-ppd-2018": [ + "E.1.2-4" + ], + "americas-bmu-mba-coc-2020": [ + "6.20-BP2", + "6.20-BP3" ] } }, @@ -7323,7 +7355,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure secure migration practices purge Technology Assets, Applications and/or Services (TAAS) of test/development/staging data and accounts before it is migrated into a production environment.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -7386,7 +7418,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -7447,7 +7480,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers/integrators consult with security, compliance and/or resilience personnel to: \n(1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability;\n(2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the control testing and evaluation process; and\n(3) Document the results.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7524,9 +7557,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- renamed\n- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -7639,7 +7672,7 @@ "8.29", "8.30" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078", "T1078.001", "T1078.003", @@ -7734,6 +7767,12 @@ "03.12.03", "03.14.01.a" ], + "general-nist-800-171a-r3": [ + "A.03.12.01", + "A.03.12.03[01]", + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], "general-nist-800-218": [ "PO.4", "PO.4.1", @@ -7794,11 +7833,6 @@ "6.2.4", "6.5.6" ], - "general-scf-dpmp-2025": [ - "7.0", - "7.11", - "7.12" - ], "general-ul-2900-1-2017": [ "12.3", "12.3(a)", @@ -7902,11 +7936,6 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-11" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(69)", - "3.6.2(70)", - "3.6.2(71)" - ], "emea-eu-nis2-annex-2024": [ "6.2.2(d)", "6.5.1" @@ -7916,42 +7945,27 @@ "7.8", "7.9", "7.10", - "7.11", - "7.12", - "7.13", - "7.14" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.3", - "17.4", - "17.12", - "17.15" + "7.12" ], "emea-sau-cscc-1-2019": [ - "1-3-1-1", "1-3-2-1" ], "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-3-4", "1-6-3-3" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-2" + "emea-esp-ccn-stic-825-2026": [ + "mp.sw.1", + "mp.sw.2" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "emea-esp-ccn-stic-825-2023": [ - "8.6.2 [MP.SW.2]" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402", - "ISM-1754" + "ISM-1754", + "ISM-1850", + "ISM-1851", + "ISM-2057", + "ISM-2060", + "ISM-2061", + "ISM-2062" ], "apac-ind-sebi-2024": [ "PR.IP.S6" @@ -7966,27 +7980,24 @@ "14.2.8.2", "14.2.8.3" ], + "apac-mys-bnm-rmit-2025": [ + "10.10" + ], "apac-sgp-mas-trm-2021": [ - "5.7.1", - "5.7.2", - "5.7.3", "5.7.4", "5.7.5", - "5.7.6", - "6.1.1", - "6.1.2", - "6.1.3", - "6.1.4", "6.1.6", "6.1.7" ], - "amaericas-can-osfi-self-assessment": [ - "4.8", - "4.9" + "americas-bmu-mba-coc-2020": [ + "6.20-BP1" ], "americas-can-osfi-b13-2022": [ "3.2.9" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.9" + ], "americas-can-itsp-10-171-2025": [ "03.12.01", "03.12.03", @@ -8014,9 +8025,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a plan for the continuous monitoring of security, compliance and/or resilience control effectiveness.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to produce a plan for the continuous monitoring of security, compliance and/or resilience control effectiveness. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8098,9 +8109,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "general-cis-csc-8-1": [ @@ -8142,6 +8153,9 @@ "general-nist-800-171-r3": [ "03.12.03" ], + "general-nist-800-171a-r3": [ + "A.03.12.03[01]" + ], "general-nist-800-218": [ "RV.1" ], @@ -8164,14 +8178,6 @@ "usa-federal-irs-1075-2021": [ "SA-4(CE-8)" ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.4", - "17.12" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.4" - ], "americas-can-itsp-10-171-2025": [ "03.12.03" ] @@ -8197,9 +8203,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Developers of TAAS are required to employ static code analysis tools to identify and remediate common flaws, documenting the results of the analysis before the application is cleared for production usage.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ static code analysis tools to identify and remediate common flaws and document the results of the analysis.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ static code analysis tools to identify and remediate common flaws and document the results of the analysis. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8255,7 +8261,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -8366,24 +8373,15 @@ "SA-11(1)-IS.1", "SA-11(1)-IS.2" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.14" - ], "emea-sau-cscc-1-2019": [ "1-3-2-1" ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2028" ], "apac-sgp-mas-trm-2021": [ "6.1.6" @@ -8413,9 +8411,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ Developers of TAAS are to employ dynamic code analysis tools to identify and remediate common flaws, documenting the results of the analysis before the application is cleared for production usage.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ dynamic code analysis tools to identify and remediate common flaws and document the results of the analysis.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ dynamic code analysis tools to identify and remediate common flaws and document the results of the analysis. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8470,7 +8468,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -8553,30 +8552,27 @@ "usa-federal-eo-14028": [ "4e(iv)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.19" - ], "emea-sau-cscc-1-2019": [ "1-3-2-1" ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2028" ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-mys-bnm-rmit-2025": [ + "10.14" ], "apac-sgp-mas-trm-2021": [ "6.1.6" ], "americas-can-osfi-b13-2022": [ "3.2.9" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.9" ] } }, @@ -8600,7 +8596,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, implements a process to check the validity of information inputs.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize testing methods to ensure Technology Assets, Applications and/or Services (TAAS) continue to operate as intended when subject to invalid or unexpected inputs on its interfaces.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8657,7 +8653,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -8723,21 +8720,12 @@ "usa-federal-fda-21-cfr-part-11-2025": [ "11.10" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.3", - "17.24" - ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ - "ISM-0402" + "apac-aus-ism-2026-march": [ + "ISM-0402", + "ISM-2057" ], "apac-nzl-ism-3-9": [ "14.5.6.C.01" @@ -8767,7 +8755,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform application-level penetration testing of custom-made Technology Assets, Applications and/or Services (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -8826,7 +8814,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -8934,29 +8923,14 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "11.9", - "17.3", - "17.15", - "17.17" - ], "emea-sau-ecc-1-2018": [ "1-6-3-3" ], - "emea-sau-sacs-002-2022": [ - "TPC-72" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402" ], "apac-nzl-ism-3-9": [ "14.5.6.C.01" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.6" ] } }, @@ -8980,7 +8954,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement secure configuration settings by default to reduce the likelihood of Technology Assets, Applications and/or Services (TAAS) being deployed with weak security settings that would put the TAAS at a greater risk of compromise.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9043,7 +9017,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -9086,11 +9061,13 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.8(a)" ], - "emea-sau-otcc-1-2022": [ - "1-4-1-3" + "apac-aus-ism-2026-march": [ + "ISM-0383", + "ISM-2042", + "ISM-2044" ], - "apac-aus-ism-2024-june": [ - "ISM-0383" + "apac-aus-cop-sitc-2020": [ + "4" ] } }, @@ -9112,7 +9089,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to employ a manual code review process to identify and remediate unique flaws that require knowledge of the application’s requirements and design.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -9166,7 +9143,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -9202,7 +9180,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to approve, document and control the use of live data in development and test environments.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9255,7 +9233,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -9303,10 +9282,7 @@ "emea-eu-nis2-annex-2024": [ "6.2.2(f)" ], - "emea-isr-cmo-1-0": [ - "10.3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1420" ], "apac-jpn-ismap": [ @@ -9318,9 +9294,6 @@ "14.3.1.4", "14.3.1.5", "14.3.1.6" - ], - "apac-sgp-mas-trm-2021": [ - "11.1.6" ] } }, @@ -9342,11 +9315,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure the integrity of test data through existing security, compliance and resilience controls.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -9392,15 +9365,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Technology Development & Acquisition", "crosswalks": { "emea-eu-nis2-annex-2024": [ "6.2.2(e)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0402" ] } @@ -9423,7 +9396,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain awareness of component authenticity by developing and implementing Product Tampering and Counterfeiting (PTC) practices that include the means to detect and prevent counterfeit components.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9495,7 +9468,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -9508,7 +9482,7 @@ "general-cis-csc-8-1-ig3": [ "16.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1059.002", "T1195", "T1195.001", @@ -9594,6 +9568,19 @@ "SR-11", "SR-11(3)" ], + "general-nist-800-172-r3": [ + "03.17.02E", + "03.17.03E", + "03.17.05E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.02E.ODP[04]", + "DS-A.03.17.03E.b", + "A.03.17.03E.ODP[01]", + "DS-A.03.17.05E[01]", + "A.03.17.05E.ODP[01]", + "DS-A.03.17.05E[02]" + ], "general-sparta": [ "CM0024", "CM0028" @@ -9621,10 +9608,7 @@ "SR-10", "SR-11" ], - "emea-isr-cmo-1-0": [ - "17.21" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1790", "ISM-1791", "ISM-1792" @@ -9649,9 +9633,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to train personnel to detect counterfeit system components, including hardware, software and firmware.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to train personnel to detect counterfeit system components, including hardware, software and firmware. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -9719,7 +9703,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -9756,6 +9741,12 @@ "general-nist-800-161-r1-level-3": [ "SR-11(1)" ], + "general-nist-800-172-r3": [ + "03.02.04E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.02.04E" + ], "general-sparta": [ "CM0024" ], @@ -9773,9 +9764,6 @@ ], "usa-federal-irs-1075-2021": [ "SR-11(CE-1)" - ], - "emea-isr-cmo-1-0": [ - "17.21" ] } }, @@ -9789,7 +9777,7 @@ "conformity_cadence": "Annual", "evidence_requests": [], "pptdf": "N/A", - "nist_csf_function": "Protect", + "nist_csf_function": "N/A", "scrm_focus": { "strategic": false, "operational": false, @@ -9799,7 +9787,7 @@ "0": "N/A", "1": "N/A", "2": "N/A", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ [deprecated - incorporated into AST-09]\nAn implemented and operational capability exists to dispose of system components using organization-defined techniques and methods to prevent such components from entering the gray market.", + "3": "N/A", "4": "N/A", "5": "N/A" }, @@ -9844,7 +9832,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to custom-develop critical system components, when Commercial Off The Shelf (COTS) solutions are unavailable.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -9911,7 +9899,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -10007,7 +9996,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that the developers of Technology Assets, Applications and/or Services (TAAS) have the requisite skillset and appropriate access authorizations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -10074,7 +10063,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -10128,9 +10118,198 @@ ], "emea-eu-nis2-annex-2024": [ "10.2.1" - ], - "emea-deu-c5-2020": [ - "DEV-02" + ] + } + }, + { + "control_id": "TDA-13.1", + "title": "Developer Knowledge & Skills Register", + "family": "TDA", + "description": "Mechanisms exist to maintain a cybersecurity knowledge and skills register for developers.", + "scf_question": "Does the organization maintain a cybersecurity knowledge and skills register for developers?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to maintain a cybersecurity knowledge and skills register for developers.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Note: Formal developer skills register typically not required at this size\n∙ Track relevant security certifications for development staff", + "small": "∙ Simple skills inventory for development team security knowledge\n∙ Track SSDP training completion", + "medium": "∙ Developer cybersecurity skills register\n∙ Skills gap analysis against SSDP requirements\n∙ Integration with HR and training records", + "large": "∙ Formal developer security knowledge and skills register\n∙ Annual skills assessment and gap analysis\n∙ Integration with training and professional development program", + "enterprise": "∙ Enterprise developer security skills management program\n∙ Automated skills tracking in HR platform\n∙ Skills gap analysis tied to learning pathways\n∙ Integration with workforce planning" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2039", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2038" + ] + } + }, + { + "control_id": "TDA-13.2", + "title": "Developer Training", + "family": "TDA", + "description": "Mechanisms exist to ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP).", + "scf_question": "Does the organization ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP)?", + "relative_weight": 7, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "People", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure developers of Technology Assets, Applications and/or Services (TAAS) who lack the requisite skillset receive suitable training on Secure Software Development Practices (SSDP).", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Free OWASP and SANS resources for developer security training.\n∙ Online SSDP training (e.g., Secure Code Warrior free tier)", + "small": "∙ OWASP resources and Secure Code Warrior free tier (https://securecodewarrior.com)\n∙ Annual developer security training requirement", + "medium": "∙ Secure coding training platform (e.g., Secure Code Warrior, Snyk Learn)\n∙ Role-based training for developers on SSDP\n∙ Annual required training completion", + "large": "∙ Enterprise secure coding training platform (e.g., Secure Code Warrior)\n∙ Mandatory annual training tied to developer roles\n∙ Training effectiveness measurement", + "enterprise": "∙ Enterprise developer security training program\n∙ Role-based SSDP training with LMS integration\n∙ Secure Code Warrior or equivalent at scale\n∙ Skills-gap based personalized learning paths" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - ISM 2038", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "apac-aus-ism-2026-march": [ + "ISM-2037" ] } }, @@ -10157,7 +10336,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to perform configuration management during system design, development, implementation and operation.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -10234,7 +10413,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -10268,7 +10448,7 @@ "8.30", "8.32" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1072", "T1078", "T1078.001", @@ -10359,11 +10539,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-10" ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" + "emea-esp-ccn-stic-825-2026": [ + "op.exp.5" ] } }, @@ -10390,11 +10567,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of software and firmware components.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of software and firmware components. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -10457,7 +10634,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -10494,9 +10672,6 @@ "general-nist-800-82-r3": [ "SA-10(01)" ], - "general-nist-800-172": [ - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -10517,9 +10692,6 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.1(c)" - ], - "emea-isr-cmo-1-0": [ - "17.20" ] } }, @@ -10546,7 +10718,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -10613,7 +10785,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -10626,9 +10799,6 @@ "general-nist-800-82-r3": [ "SA-10(03)" ], - "general-nist-800-172": [ - "3.14.7e" - ], "general-nist-csf-2-0": [ "ID.RA-09" ], @@ -10642,7 +10812,7 @@ "title": "Developer Threat Analysis & Flaw Remediation", "family": "TDA", "description": "Mechanisms exist to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", - "scf_question": "Does the organization require system developers and integrators to create a Security Testing and Evaluation (ST&E) plan and implement the plan under the witness of an independent party?", + "scf_question": "Does the organization require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -10655,7 +10825,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -10722,7 +10892,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -10893,32 +11064,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(68)", - "3.6.2(69)", - "3.6.2(70)" - ], "emea-eu-nis2-2022": [ "Article 21.4" - ], - "emea-deu-c5-2020": [ - "DEV-02" - ], - "emea-isr-cmo-1-0": [ - "17.13" - ], - "emea-sau-cscc-1-2019": [ - "1-3-2-1" - ], - "emea-sau-ecc-1-2018": [ - "1-5-3-2", - "1-5-3-4" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.6" - ], - "amaericas-can-osfi-self-assessment": [ - "2.7" ] } }, @@ -10940,7 +11087,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to require the developers of Technology Assets, Applications and/or Services (TAAS) to provide training on the correct use and operation of the Technology Asset, Application and/or Service (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -11004,7 +11151,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -11023,7 +11171,7 @@ "general-govramp-high": [ "SA-16" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1078.001", "T1078.003", "T1574.002" @@ -11054,9 +11202,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "SA-16" - ], - "apac-sgp-mas-trm-2021": [ - "6.1.5" ] } }, @@ -11080,7 +11225,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, provides in-house support or contract external providers for support with unsupported system components.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prevent unsupported Technology Assets, Applications and/or Services (TAAS) by:\n(1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and\n(2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -11160,7 +11305,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -11176,7 +11322,7 @@ "general-cis-csc-8-1-ig3": [ "2.2" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1189", "T1195", "T1195.001", @@ -11239,9 +11385,6 @@ "general-owasp-top-10-2025": [ "A06:2025" ], - "general-scf-dpmp-2025": [ - "7.5" - ], "usa-federal-fbi-cjis-6-0": [ "SA-22" ], @@ -11277,8 +11420,11 @@ "usa-state-tx-txramp-2-0-level-2": [ "SA-22" ], - "emea-isr-cmo-1-0": [ - "12.23" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-51" + ], + "emea-gbr-cyber-essentials-requirements-3-3": [ + "3-BP2" ], "apac-aus-essential-8-2024": [ "ML1-P1", @@ -11288,13 +11434,22 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0304", "ISM-1501", "ISM-1704", - "ISM-1753" + "ISM-1753", + "ISM-1848", + "ISM-1981", + "ISM-1982" + ], + "apac-aus-cop-sitc-2020": [ + "3" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP43", "HML43" ], @@ -11303,16 +11458,17 @@ ], "apac-sgp-mas-trm-2021": [ "7.3.1", - "7.3.2", "7.3.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.6", - "4.9" + "americas-bmu-mba-coc-2020": [ + "6.16" ], "americas-can-osfi-b13-2022": [ "2.2.5" ], + "americas-can-osfi-self-assessment-2": [ + "2.2.5" + ], "americas-can-itsp-10-171-2025": [ "03.16.02.A" ] @@ -11336,9 +11492,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to provide in-house support or contract external providers for support with unsupported Technology Assets, Applications and/or Services (TAAS). ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -11415,7 +11571,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -11500,9 +11657,6 @@ "emea-eu-dora-2023": [ "Article 28.8 (end)" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.3 [OP.EXT.3]" - ], "americas-can-itsp-10-171-2025": [ "03.16.02.B" ] @@ -11526,11 +11680,11 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to check the validity of information inputs.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to check the validity of information inputs. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -11585,7 +11739,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -11653,7 +11808,7 @@ "general-iec-62443-4-2-2019": [ "CR 3.5" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1021.002", "T1021.005", "T1027.010", @@ -11879,6 +12034,13 @@ "SI-5", "SI-7" ], + "general-nist-800-172-r3": [ + "03.14.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.12E", + "A.03.14.12E.ODP[01]" + ], "general-owasp-top-10-2025": [ "A08:2025" ], @@ -11980,11 +12142,11 @@ "SI-07", "SI-10" ], - "emea-isr-cmo-1-0": [ - "17.22" - ], "emea-sau-sacs-002-2022": [ - "TPC-60" + "VII.B.TPC-60" + ], + "apac-aus-ism-2026-march": [ + "ISM-2059" ], "apac-jpn-ismap": [ "14.2.5.9" @@ -12009,7 +12171,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to handle error conditions by: \n(1) Identifying potentially security-relevant error conditions;\n(2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and\n(3) Revealing error messages only to authorized personnel.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -12063,7 +12225,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -12106,6 +12269,13 @@ "general-nist-800-82-r3-high": [ "SI-11" ], + "general-nist-800-172-r3": [ + "03.14.13E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.13E.a", + "DS-A.03.14.13E.b" + ], "general-owasp-top-10-2025": [ "A08:2025", "A10:2025" @@ -12130,14 +12300,98 @@ "usa-state-tx-txramp-2-0-level-2": [ "SI-11" ], - "emea-deu-c5-2020": [ - "PSS-04" - ], - "emea-isr-cmo-1-0": [ - "17.23" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-61" + ] + } + }, + { + "control_id": "TDA-19.1", + "title": "Designated Roles To View Error Messages", + "family": "TDA", + "description": "Mechanisms exist to:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s).", + "scf_question": "Does the organization:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s)?", + "relative_weight": 6, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to:\n(1) Define personnel and/or role(s) authorized to receive security-relevant error messages; and\n(2) Restrict access to error messages to authorized personnel and/or role(s).", + "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", + "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Configure error messages to suppress technical details from end users\n∙ Role-based access to application error logs", + "small": "∙ Application configuration to display generic errors to end users\n∙ Technical error details restricted to authorized administrators", + "medium": "∙ Error message configuration standards\n∙ Role-based access to error logs and detailed messages\n∙ Centralized log management with access controls", + "large": "∙ Enterprise error message governance standard\n∙ Role-based log access controls\n∙ Automated testing for information disclosure via error messages", + "enterprise": "∙ Enterprise error handling standard with automated enforcement\n∙ Centralized SIEM with role-based log access\n∙ Automated security testing for error message information disclosure\n∙ Integration with code review and CI/CD security gates" + }, + "risks": [ + "R-AC-3", + "R-AC-4", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-4", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Technology Development & Acquisition", + "crosswalks": { + "general-nist-800-172a-r3": [ + "A.03.14.13E.ODP[01]" ], "emea-sau-sacs-002-2022": [ - "TPC-61" + "VII.B.TPC-61" ] } }, @@ -12159,9 +12413,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.\n▪ An application development team, or similar function, uses a Source Code Manager (SCM) solution to govern modifying, copying, deleting, moving and renaming items in the software library.\n▪ SCM supports integrity checking on the source code repository.\n▪ SCM uses Role-Based Access Controls (RBAC) to limit the logical access and permissions for users in the software library.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit privileges to change software resident within software libraries.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to limit privileges to change software resident within software libraries. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12226,7 +12480,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -12314,15 +12569,18 @@ "SA-04 (02)" ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(73)" + "3.6.2.73" ], "emea-deu-bsrit-2017": [ "7.9" ], "emea-deu-c5-2020": [ - "DEV-07" + "IDM-13" ], - "apac-aus-ism-2024-june": [ + "emea-sau-cscc-1-2019": [ + "1-3-2-2" + ], + "apac-aus-ism-2026-march": [ "ISM-1422" ], "apac-jpn-ismap": [ @@ -12338,12 +12596,18 @@ "9.4.5.9", "14.2.1.5" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP42", "HML42" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP37" + ], + "apac-sgp-mas-trm-2021": [ + "7.6.2" ] } }, @@ -12365,7 +12629,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to publish integrity verification information for software releases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12419,7 +12683,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -12459,7 +12724,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to archive software releases and all of their components (e.g., code, package files, third-party libraries, documentation) to maintain integrity verification information.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12513,7 +12778,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -12523,6 +12789,9 @@ "general-nist-800-218": [ "PS.3", "PS.3.1" + ], + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } }, @@ -12546,9 +12815,9 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to escrow source code and supporting documentation to ensure software availability in the event the software provider goes out of business or is unable to provide support.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to escrow source code and supporting documentation to ensure software availability in the event the software provider goes out of business or is unable to provide support. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -12586,7 +12855,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -12605,6 +12875,9 @@ "apac-jpn-ismap": [ "14.2.7.8" ], + "apac-mys-bnm-rmit-2025": [ + "10.12" + ], "apac-sgp-mas-trm-2021": [ "5.3.4" ] @@ -12628,7 +12901,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to govern the approval of binaries and code for production use.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12689,7 +12962,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -12725,7 +12999,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure developed Technology Assets, Applications and/or Services (TAAS) conform to applicable statutory and regulatory requirements, based on the product's and/or service's:\n(1) Use case(s); and\n(2) Geographic markets.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12791,7 +13065,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -12832,8 +13107,8 @@ "Article 53.1(c)", "Article 111.3" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.12" + "apac-mys-bnm-rmit-2025": [ + "10.12" ] } }, @@ -12855,7 +13130,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to generate appropriate technical documentation artifacts for Technology Assets, Applications and/or Services (TAAS) in sufficient detail to demonstrate conformity with applicable statutory, regulatory and contractual compliance requirements.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -12921,7 +13196,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { @@ -12930,9 +13206,6 @@ "MP-4.1-010", "MS-2.9-001" ], - "general-scf-dpmp-2025": [ - "7.1" - ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(14)" ], @@ -12942,32 +13215,6 @@ "Article 17.1(k)", "Article 23.1(b)", "Article 53.1(a)" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.7", - "Article 13.2(b)", - "Article 23.1", - "Article 23.2", - "Article 23.3", - "Article 23.4" - ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 5", - "Annex 5.1", - "Annex 5.1(a)", - "Annex 5.1(b)", - "Annex 5.1(c)", - "Annex 5.1(d)", - "Annex 5.2", - "Annex 5.2(a)", - "Annex 5.2(b)", - "Annex 5.2(c)", - "Annex 5.3", - "Annex 5.4", - "Annex 5.5", - "Annex 5.6", - "Annex 5.7", - "Annex 6 Module A.2" ] } }, @@ -12989,7 +13236,7 @@ }, "maturity": { "0": "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.", - "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).", + "1": "Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.). ", "2": "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:\n▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ 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, NIST SP 800-160, etc.).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.\n▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution, software testing tools, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to include a detailed cybersecurity risk assessment in the technical documentation for Technology Assets, Applications and/or Services (TAAS) to demonstrate applicable risks in approved use cases.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -13052,15 +13299,13 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Technology Development & Acquisition", "crosswalks": { "general-shared-assessments-sig-2025": [ "C.4" - ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.3" ] } } diff --git a/docs/api/families/THR.json b/docs/api/families/THR.json index 27e1208c..0d4401bd 100644 --- a/docs/api/families/THR.json +++ b/docs/api/families/THR.json @@ -1,7 +1,7 @@ { "family_code": "THR", "family_name": "Threat Management", - "control_count": 13, + "control_count": 15, "controls": [ { "control_id": "THR-01", @@ -122,7 +122,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -207,8 +208,20 @@ ], "general-nist-800-171-r3": [ "03.11.02.a", + "03.14.01.a", "03.14.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.a[01]", + "A.03.14.01.a[01]", + "A.03.14.03.a" + ], + "general-nist-800-172-r3": [ + "03.11.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.01E" + ], "general-nist-800-207": [ "NIST Tenet 7" ], @@ -285,33 +298,37 @@ "Article 45.2", "Article 45.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "3.10", "5.3" ], - "emea-isr-cmo-1-0": [ - "23.1", - "23.4" + "emea-deu-c5-2020": [ + "OIS-05-DOAR" + ], + "emea-isr-cmo-2-0": [ + "2.B" ], "emea-sau-cgiot-2024": [ "2-12-4" ], "emea-sau-ecc-1-2018": [ - "2-10-4", "2-13-1", "2-13-2", - "2-13-3", - "2-13-4" + "2-13-3-5" + ], + "emea-sau-otcc-1-2022": [ + "2-12-1-8" ], "emea-sau-sama-csf-1-2017": [ - "3.3.16" + "3.3.16.1", + "3.3.16.3", + "3.3.16.3.a", + "3.3.16.3.c", + "3.3.16.3.d", + "3.3.16.3.e" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "emea-gbr-caf-4-0": [ "A2.b" @@ -331,19 +348,11 @@ "apac-jpn-ismap": [ "5.1.1.4" ], - "apac-sgp-mas-trm-2021": [ - "4.2.1", - "13.5.1", - "13.5.2", - "14.3.1", - "14.3.2", - "14.3.3" - ], - "americas-bmu-mba-coc-2020": [ - "6.2" + "apac-mys-bnm-rmit-2025": [ + "11.10" ], - "amaericas-can-osfi-self-assessment": [ - "1.3" + "apac-sgp-mas-trm-2021": [ + "14.1.6" ], "americas-can-osfi-b13-2022": [ "3.0", @@ -351,12 +360,231 @@ "3.1.1", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.A", + "03.14.01.A", "03.14.03.A" ] } }, + { + "control_id": "THR-01.1", + "title": "Dynamic Threat Awareness", + "family": "THR", + "description": "Mechanisms exist to determine and maintain ongoing awareness of the current cyber threat environment.", + "scf_question": "Does the organization determine and maintain ongoing awareness of the current cyber threat environment?", + "relative_weight": 3, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to determine and maintain ongoing awareness of the current cyber threat environment.", + "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Subscribe to CISA alerts\n∙ MS-ISAC free membership", + "small": "∙ CISA and MS-ISAC alerts\n∙ Industry-specific threat intelligence feeds\n∙ Basic threat awareness program", + "medium": "∙ Threat intelligence feeds (CISA, industry ISACs)\n∙ Regular threat landscape reviews\n∙ Integration with security awareness program", + "large": "∙ Threat intelligence program with dedicated analyst\n∙ ISAC membership and information sharing\n∙ Regular executive threat briefings", + "enterprise": "∙ Enterprise threat intelligence program\n∙ Automated threat intelligence feeds and analysis\n∙ ISAC and government information sharing partnerships\n∙ Threat intelligence integrated with SIEM and SOC operations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Threat Management", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.11.08E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.08E", + "A.03.11.08E.ODP[01]" + ], + "apac-sgp-mas-trm-2021": [ + "14.1.6" + ] + } + }, + { + "control_id": "THR-01.2", + "title": "Predictive Cyber Analytics", + "family": "THR", + "description": "Mechanisms exist to employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "scf_question": "Does the organization employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD)?", + "relative_weight": 3, + "conformity_cadence": "Annual", + "evidence_requests": [], + "pptdf": "Process", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": false + }, + "maturity": { + "0": "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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", + "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to employ advanced automation and analytics capabilities to predict and identify risks to Technology Assets, Applications, Services and/or Data (TAASD).", + "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [], + "possible_solutions": { + "micro_small": "∙ Use free threat indicators from CISA and MS-ISAC", + "small": "∙ Use free threat indicators from CISA and MS-ISAC\n∙ Basic anomaly detection via endpoint protection tools", + "medium": "∙ SIEM with anomaly detection capabilities\n∙ User and Entity Behavior Analytics (UEBA) basic functionality", + "large": "∙ SIEM/UEBA platform with predictive analytics\n∙ Machine learning-based anomaly detection\n∙ Threat hunting based on behavioral analytics", + "enterprise": "∙ Enterprise SIEM/SOAR with advanced predictive analytics\n∙ AI/ML-based threat detection (e.g., Darktrace, Vectra AI, Microsoft Sentinel ML)\n∙ Dedicated threat analytics team\n∙ Predictive analytics integrated with SOC operations" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SA-2", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-7", + "MT-1", + "MT-2", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - NIST 800-172 R3", + "family_name": "Threat Management", + "crosswalks": { + "general-nist-800-172-r3": [ + "03.11.03E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.03E[01]", + "A.03.11.03E.ODP[01]", + "A.03.11.03E.ODP[02]", + "DS-A.03.11.03E[02]", + "A.03.11.03E.ODP[03]" + ] + } + }, { "control_id": "THR-02", "title": "Indicators of Exposure (IOE)", @@ -379,9 +607,9 @@ "0": "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.", "1": "Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Threat management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop Indicators of Exposure (IOE) to understand the potential attack vectors that attackers could use to attack the organization.", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop Indicators of Exposure (IOE) to understand the potential attack vectors that attackers could use to attack the organization. ", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 1 Foundational", @@ -440,7 +668,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -475,16 +704,8 @@ "usa-federal-dhs-cisa-cpg-2-0": [ "3.A" ], - "emea-isr-cmo-1-0": [ - "23.3" - ], - "emea-sau-otcc-1-2022": [ - "2-12-2-8" - ], - "apac-sgp-mas-trm-2021": [ - "14.3.1", - "14.3.2", - "14.3.3" + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "americas-can-osfi-b13-2022": [ "3.1" @@ -581,7 +802,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -630,7 +852,7 @@ "general-iso-27018-2025": [ "5.7" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1210", "T1211", @@ -701,17 +923,20 @@ "general-nist-800-171-r3": [ "03.02.01.a.02", "03.02.01.a.03", - "03.02.01.b", - "03.02.02.b", "03.11.02.a", "03.14.03.a" ], "general-nist-800-171a-r3": [ + "A.03.02.01.a.02", + "A.03.02.01.b[02]", + "A.03.11.02.a[01]", "A.03.14.03.a" ], - "general-nist-800-172": [ - "3.11.1e", - "3.14.6e" + "general-nist-800-172-r3": [ + "03.11.12E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.12E" ], "general-nist-800-207": [ "NIST Tenet 7" @@ -806,6 +1031,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SI-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(ii)" + ], "usa-federal-irs-1075-2021": [ "SI-5" ], @@ -832,7 +1060,7 @@ "SI-05" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(21)" + "3.3.3.21" ], "emea-eu-dora-2023": [ "Article 13.1" @@ -841,21 +1069,26 @@ "6.10.2(a)" ], "emea-deu-bsrit-2017": [ + "3.10", "5.3" ], - "emea-isr-cmo-1-0": [ - "23.2" + "emea-deu-c5-2020": [ + "OIS-05" ], "emea-sau-cgiot-2024": [ "2-12-4" ], "emea-sau-ecc-1-2018": [ - "2-10-3-5", "2-13-3-5" ], "emea-sau-otcc-1-2022": [ - "1-8-3", - "2-12-2-8" + "2-12-1-8" + ], + "emea-sau-sama-csf-1-2017": [ + "3.3.16.3.b" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" ], "emea-gbr-def-stan-05-138-2024": [ "1204", @@ -868,6 +1101,9 @@ "1204", "3110" ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], "apac-ind-sebi-2024": [ "EV.ST.S1", "EV.ST.S4", @@ -881,13 +1117,19 @@ "12.2.1.12", "12.2.1.13" ], + "apac-mys-bnm-rmit-2025": [ + "11.3", + "11.10", + "12.3", + "12.4" + ], "apac-sgp-mas-trm-2021": [ + "4.2.1", "12.1.1", - "12.1.2", - "12.1.3" + "12.1.2" ], - "amaericas-can-osfi-self-assessment": [ - "3.7" + "americas-bmu-mba-coc-2020": [ + "6.2" ], "americas-can-osfi-b13-2022": [ "3.0", @@ -895,11 +1137,13 @@ "3.1.1", "3.1.5" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.02.01.A.02", "03.02.01.A.03", - "03.02.01.B", - "03.02.02.B", "03.11.02.A", "03.14.03.A" ] @@ -991,7 +1235,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -1008,6 +1253,7 @@ "03.14.03.b" ], "general-nist-800-171a-r3": [ + "A.03.14.03.a", "A.03.14.03.b[01]", "A.03.14.03.b[02]" ], @@ -1022,9 +1268,23 @@ "7.5.1", "7.5.2" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(8)", + "101.625(d)(14)", + "101.650(e)(3)(iii)" + ], + "emea-deu-c5-2020": [ + "OIS-05-DOAR" + ], "emea-sau-cgiot-2024": [ "2-12-4" ], + "emea-sau-sama-csf-1-2017": [ + "3.3.16.3.f" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.mon.3" + ], "emea-gbr-def-stan-05-138-2024": [ "1204", "3110" @@ -1045,6 +1305,16 @@ "4.9.2.1", "4.9.2.2" ], + "apac-mys-bnm-rmit-2025": [ + "11.10" + ], + "apac-sgp-mas-trm-2021": [ + "12.1.3" + ], + "americas-can-osfi-self-assessment-2": [ + "3.1.1", + "3.1.5" + ], "americas-can-itsp-10-171-2025": [ "03.14.03.B" ] @@ -1072,7 +1342,7 @@ "0": "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.", "1": "Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Threat management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to implement an insider threat program that includes a cross-discipline insider threat incident handling team.", + "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to implement an insider threat program that includes a cross-discipline insider threat incident handling team. ", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1145,7 +1415,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -1209,7 +1480,7 @@ "§117.18(b)(4)(iii)", "§117.18(b)(4)(iv)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ], @@ -1240,7 +1511,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to utilize security awareness training on recognizing and reporting potential indicators of insider threat.", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1315,7 +1586,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -1427,7 +1699,7 @@ "usa-state-tx-txramp-2-0-level-2": [ "AT-02 (02)" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1625", "ISM-1626" ], @@ -1456,7 +1728,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to establish a Vulnerability Disclosure Program (VDP) to assist with the secure development and maintenance of Technology Assets, Applications and/or Services (TAAS) that receives unsolicited input from the public about vulnerabilities in organizational TAAS.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1503,7 +1775,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -1538,6 +1811,13 @@ "general-nist-800-82-r3-high": [ "RA-05(11)" ], + "general-nist-800-171-r3": [ + "03.14.01.a" + ], + "general-nist-800-171a-r3": [ + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" + ], "general-nist-800-218": [ "RV.1.3" ], @@ -1565,9 +1845,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "T.2" ], @@ -1605,17 +1882,17 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "RA-05(11)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 1.2(5)" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1616", "ISM-1717", "ISM-1755", "ISM-1756" ], "apac-aus-cop-sitc-2020": [ - "Principle 2" + "2" + ], + "apac-mys-bnm-rmit-2025": [ + "11.7" ], "apac-nzl-ism-3-9": [ "5.9.23.C.01", @@ -1628,6 +1905,9 @@ ], "apac-sgp-mas-trm-2021": [ "13.2.2" + ], + "americas-can-itsp-10-171-2025": [ + "03.14.01.A" ] } }, @@ -1649,7 +1929,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to enable public submissions of discovered or potential security vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1694,7 +1974,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -1705,8 +1986,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(6)" ], - "emea-eu-cyber-resilience-act-annexes-2022": [ - "Annex 2.2" + "apac-aus-cop-sitc-2020": [ + "2" ] } }, @@ -1730,7 +2011,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to perform cyber threat hunting that uses Indicators of Compromise (IoC) to detect, track and disrupt threats that evade existing security controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1805,14 +2086,15 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { "general-cr-cmm-2026": [ "CR2.2.4" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1068", "T1190", "T1195", @@ -1849,10 +2131,14 @@ "general-nist-800-161-r1-level-3": [ "RA-10" ], - "general-nist-800-172": [ - "3.11.1e", - "3.11.2e", - "3.14.6e" + "general-nist-800-172-r3": [ + "03.11.02E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.02E.a.01[02]", + "DS-A.03.11.02E.a.02[01]", + "DS-A.03.11.02E.a.02[02]", + "DS-A.03.11.02E.b" ], "general-nist-csf-2-0": [ "ID.RA-03", @@ -1886,6 +2172,9 @@ "C2.a (point 7)", "C2.a (point 8)" ], + "apac-aus-ism-2026-march": [ + "ISM-1921" + ], "apac-ind-sebi-2024": [ "DE.DP.S5" ], @@ -1912,7 +2201,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to embed false data or steganographic data in files to enable the organization to determine if data has been exfiltrated and provide a means to identify the individual(s) involved.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1955,7 +2244,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -1979,6 +2269,12 @@ ], "general-nist-800-161-r1-level-3": [ "SI-20" + ], + "general-nist-800-172-r3": [ + "03.14.16E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.14.16E" ] } }, @@ -2002,7 +2298,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to develop and keep current a catalog of applicable internal and external threats to the organization, both natural and manmade.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -2056,7 +2352,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -2090,9 +2387,6 @@ "general-nist-800-171-r3": [ "03.15.02.a.03" ], - "general-nist-800-172": [ - "3.11.5e" - ], "general-nist-csf-2-0": [ "ID.RA-03", "ID.RA-04", @@ -2122,10 +2416,10 @@ "RA.L3-3.11.5E" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-state-ma-201-cmr-17-2008": [ "17.03(2)(b)" @@ -2138,6 +2432,7 @@ ], "emea-deu-bsrit-2017": [ "3.3", + "3.10", "5.3" ], "emea-sau-cgiot-2024": [ @@ -2147,10 +2442,24 @@ "A2.b", "C1.f" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "11.3" + ], + "apac-sgp-mas-trm-2021": [ + "4.2.1" + ], + "americas-arg-ppd-2018": [ + "E.1.1-1" + ], "americas-can-osfi-b13-2022": [ "3.0", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.2", + "3.1.6" + ], "americas-can-itsp-10-171-2025": [ "03.15.02.A.03" ] @@ -2230,7 +2539,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -2266,6 +2576,9 @@ "general-nist-800-171-r3": [ "03.14.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.14.03.a" + ], "general-nist-csf-2-0": [ "ID.RA-04", "ID.RA-05", @@ -2293,10 +2606,10 @@ "THREAT-2i" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.306(b)(2)(iv)" + "§ 164.306(b)(2)(iv)" ], "usa-federal-sec-cybersecurity-rule-2023": [ "17 CFR 229.106(a)" @@ -2311,18 +2624,42 @@ "3.10", "5.3" ], + "emea-isr-cmo-2-0": [ + "Appendix B" + ], "emea-sau-cgiot-2024": [ "1-4-4" ], + "apac-aus-ism-2026-march": [ + "ISM-1203" + ], + "apac-aus-ps-cps-230-2023": [ + "16(d)" + ], "apac-ind-sebi-2024": [ "ID.RA.S4" ], + "apac-mys-bnm-rmit-2025": [ + "11.3", + "12.4" + ], + "apac-sgp-mas-trm-2021": [ + "4.3.2", + "8.5.1" + ], + "americas-arg-ppd-2018": [ + "E.1.1-1" + ], "americas-can-osfi-b13-2022": [ "3.1", "3.1.1", "3.1.2", "3.1.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.2", + "3.1.6" + ], "americas-can-itsp-10-171-2025": [ "03.14.03.B" ] @@ -2352,7 +2689,7 @@ "2": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are documented and maintained by process owners.\n▪ 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Threat Management (THR) 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:\n▪ Policies and standards associated with THR domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with THR domain capabilities are well-documented and kept current by process owners.\n▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution, bug bounty solution, etc.).\n▪ 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 THR 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).\n▪ An implemented and operational capability exists to automatically establish behavioral baselines that capture information about user and entity behavior to enable dynamic threat discovery.", "4": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Threat Management (THR) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -2420,7 +2757,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Threat Management", "crosswalks": { @@ -2444,6 +2782,9 @@ ], "usa-federal-dow-zta-reference-architecture-2-0": [ "1.2" + ], + "apac-sgp-mas-trm-2021": [ + "12.2.3" ] } } diff --git a/docs/api/families/TPM.json b/docs/api/families/TPM.json index 743bdf79..2b72b326 100644 --- a/docs/api/families/TPM.json +++ b/docs/api/families/TPM.json @@ -124,7 +124,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -153,7 +154,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0", + "15", "15.2" ], "general-cis-csc-8-1-ig2": [ @@ -305,9 +306,19 @@ "03.01.20.c.01", "03.07.06.a", "03.16.01", - "03.16.03.a" + "03.16.03.a", + "03.17.02" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.07.06.a", + "A.03.16.01", + "A.03.16.03.a", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.02[06]", "A.03.17.03.ODP[01]" ], "general-nist-csf-2-0": [ @@ -363,10 +374,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "10.0", - "11.0" - ], "general-sparta": [ "CM0025" ], @@ -440,12 +447,12 @@ "314.4(f)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.312(d)" + "§ 164.308(b)(1)", + "§ 164.312(d)" ], "usa-federal-irs-1075-2021": [ "1.9.3", @@ -489,8 +496,7 @@ "2447(b)(6)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(7)", - "3.6.2(74)" + "3.2.3.7" ], "emea-eu-dora-2023": [ "Article 30.3 (end)", @@ -504,62 +510,43 @@ "emea-eu-nis2-annex-2024": [ "6.2.3" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-deu-bsrit-2017": [ "9.1" ], "emea-deu-c5-2020": [ - "SSO-01", - "SSO-03" + "UP-01", + "DLL-01", + "DLL-02" ], - "emea-isr-cmo-1-0": [ - "11.3", - "11.10", - "16.1", - "17.3" + "emea-isr-cmo-2-0": [ + "Appendix A, 10.1" ], "emea-sau-cscc-1-2019": [ - "4-1" + "4-1-1" ], "emea-sau-ecc-1-2018": [ - "1-5-3-3", "4-1-1", - "4-1-2", - "4-1-3", - "4-1-4" + "4-1-3-2" ], "emea-sau-otcc-1-2022": [ - "4-1", "4-1-1", - "4-1-1-1", - "4-1-1-2", - "4-1-1-3", - "4-1-1-4", "4-1-2" ], "emea-sau-sama-csf-1-2017": [ "3.4.1", - "3.4.2" - ], - "emea-zaf-popia-2013": [ - "20", - "21" + "3.4.1.1", + "3.4.1.4", + "3.4.1.4.a", + "3.4.1.6", + "3.4.1.6.a", + "3.4.2.1" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-caf-4-0": [ "A4" ], - "emea-gbr-cap-1850-2020": [ - "A4" - ], "emea-gbr-def-stan-05-138-2024": [ "1400" ], @@ -572,66 +559,24 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1073", "ISM-1785" ], "apac-aus-ps-cps-230-2023": [ - "15", + "12(c)", + "16(f)", "47", + "48", "48(a)", "48(b)", - "48(c)", - "57" - ], - "apac-aus-ps-cps-234-2019": [ - "16", - "20", - "22", - "28" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)", - "42", - "51", - "51(1)", - "51(2)", - "51(3)", - "51(4)", - "51(5)", - "51(6)" + "48(c)" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1", "PR.IP.S15" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)", - "24(3)" - ], "apac-jpn-ismap": [ "4.5.3.1", "5.1.1.20", @@ -654,7 +599,13 @@ "15.1.1.13", "15.1.1.14.B" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.24", + "10.25", + "10.46" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HML25" ], @@ -668,24 +619,19 @@ ], "apac-sgp-mas-trm-2021": [ "3.4.1", - "3.4.2", - "3.4.3", - "9.1.8" + "8.3.4" ], "americas-bmu-mba-coc-2020": [ "5.10" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.01.20.A", "03.01.20.B", "03.01.20.C.01", "03.07.06.A", "03.16.01", - "03.16.03.A" + "03.16.03.A", + "03.17.02" ] } }, @@ -710,7 +656,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ A procurement function maintains a list of all active External Service Providers (ESPs), including pertinent contract information that will assist in a risk assessment.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to maintain a current, accurate and complete list of External Service Providers (ESPs) that can potentially impact the Confidentiality, Integrity, Availability and/or Safety (CIAS) of the organization's TAASD.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -780,7 +726,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -830,7 +777,11 @@ "SR-13" ], "general-nist-800-171-r3": [ - "03.07.06.a" + "03.07.06.a", + "03.07.06.b" + ], + "general-nist-800-171a-r3": [ + "A.03.07.06.b" ], "general-nist-800-207": [ "NIST Tenet 1" @@ -936,7 +887,10 @@ "5.2", "5.2(a)" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" + ], + "apac-aus-ism-2026-march": [ "ISM-1631", "ISM-1637", "ISM-1638", @@ -945,7 +899,8 @@ "ISM-1786" ], "apac-aus-ps-cps-230-2023": [ - "49" + "49", + "51" ], "apac-ind-sebi-2024": [ "GV.OC.S3", @@ -953,7 +908,8 @@ "GV.SC.S2" ], "americas-can-itsp-10-171-2025": [ - "03.07.06.A" + "03.07.06.A", + "03.07.06.B" ] } }, @@ -977,7 +933,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to identify, prioritize and assess suppliers and partners of critical Technology Assets, Applications and/or Services (TAAS) using a supply chain risk assessment process relative to their importance in supporting the delivery of high-value services.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1075,7 +1031,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -1172,6 +1129,16 @@ "03.11.01.a", "03.17.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.03.a[01]" + ], + "general-nist-800-172-r3": [ + "03.11.10E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.10E.ODP[01]" + ], "general-nist-csf-2-0": [ "GV.OC-04", "GV.OC-05", @@ -1182,9 +1149,6 @@ "ID.AM-05", "ID.RA-10" ], - "general-scf-dpmp-2025": [ - "11.7" - ], "general-sparta": [ "CM0022" ], @@ -1235,10 +1199,10 @@ "314.4(f)(1)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(a)(7)(ii)(E)" + "§ 164.308(a)(7)(ii)(E)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -1253,53 +1217,51 @@ "500.11(a)(1)", "500.11(a)(4)" ], + "emea-eu-eba-ict-srm-2025": [ + "3.3.2.16" + ], "emea-eu-dora-2023": [ "Article 8.4" ], "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-deu-c5-2020": [ - "SSO-02", - "SSO-03" - ], - "emea-isr-cmo-1-0": [ - "16.1", - "16.6" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1" ], - "emea-sau-otcc-1-2022": [ - "4-1-1-2" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1452" ], "apac-aus-ps-cps-230-2023": [ + "15", + "49", + "50", "50(a)", "50(b)", "50(c)", "50(d)", - "52" - ], - "apac-aus-ps-cps-234-2019": [ - "21(b)" + "51" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1", "GV.SC.S2" ], + "apac-mys-bnm-rmit-2025": [ + "9.2", + "10.46" + ], "apac-nzl-ism-3-9": [ "12.7.17.C.01" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.27" + "apac-sgp-mas-trm-2021": [ + "5.3.1" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", @@ -1312,7 +1274,7 @@ "title": "Supply Chain Risk Management (SCRM)", "family": "TPM", "description": "Mechanisms exist to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", - "scf_question": "Does the organization:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary?", + "scf_question": "Does the organization:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize its exposure to those risks and threats, as necessary?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1327,11 +1289,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to:\n(1) Evaluate security risks and threats associated with Technology Assets, Applications and/or Services (TAAS) supply chains; and\n(2) Take appropriate remediation actions to minimize the organization's exposure to those risks and threats, as necessary.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -1427,7 +1389,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -1535,6 +1498,12 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.11.01.a", + "A.03.17.01.a[01]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC", "GV.SC-06", @@ -1545,9 +1514,6 @@ "A03:2025", "A05:2025" ], - "general-scf-dpmp-2025": [ - "10.1" - ], "general-sparta": [ "CM0026", "CM0027" @@ -1614,11 +1580,8 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-02" ], - "emea-eu-cyber-resilience-act-2022": [ - "Article 10.4" - ], "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" + "3.7.3.86" ], "emea-eu-dora-2023": [ "Article 30.3(f)" @@ -1631,37 +1594,22 @@ "5.1.6" ], "emea-deu-c5-2020": [ - "SSO-02", - "SSO-03" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.1", - "16.3", - "16.5", - "17.3", - "17.11" - ], - "emea-pol-act-29-1997": [ - "31" + "PS-04-DOAR" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "emea-sau-sama-csf-1-2017": [ - "3.4.2" - ], - "emea-zaf-popia-2013": [ - "20" + "emea-sau-ecc-1-2018": [ + "4-1-3-1" ], - "emea-esp-decree-1720-2007": [ - "20", - "21" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2", + "op.ext.3" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]", - "7.4.3 [OP.EXT.3]" + "emea-gbr-cap-1850-2020": [ + "A4" ], "emea-gbr-def-stan-05-138-2024": [ "1400" @@ -1675,20 +1623,22 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "1400" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0731", "ISM-1452", "ISM-1632", "ISM-1789" ], - "apac-aus-ps-cps-234-2019": [ - "22", - "28" + "apac-aus-ps-cps-230-2023": [ + "15" ], "apac-ind-sebi-2024": [ "GV.OC.S3", "GV.SC.S1" ], + "apac-mys-bnm-rmit-2025": [ + "10.15" + ], "apac-nzl-ism-3-9": [ "12.7.14.C.01", "12.7.14.C.02", @@ -1710,26 +1660,11 @@ "12.7.20.C.05", "12.7.21.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "43" - ], - "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" - ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", "03.17.01.A", "03.17.03.A", "03.17.03.B" - ], - "americas-mex-fdpa-2010": [ - "21" ] } }, @@ -1751,7 +1686,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize tailored acquisition strategies, contract tools and procurement methods for the purchase of unique Technology Assets, Applications and/or Services (TAAS).", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -1820,7 +1755,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -1842,7 +1778,7 @@ "5.21", "5.22" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1059.002", "T1195", "T1195.001", @@ -1914,9 +1850,14 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.17.01.a[01]", "A.03.17.02[01]", "A.03.17.02[02]", - "A.03.17.02[03]" + "A.03.17.02[03]", + "A.03.17.02[04]", + "A.03.17.02[05]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], "general-owasp-top-10-2025": [ "A03:2025" @@ -1967,9 +1908,6 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-05" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" - ], "emea-eu-dora-2023": [ "Article 29.1 (end)" ], @@ -1979,17 +1917,15 @@ "emea-deu-bsrit-2017": [ "9.3" ], - "emea-deu-c5-2020": [ - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "16.1" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "apac-aus-ism-2024-june": [ + "emea-esp-ccn-stic-825-2026": [ + "op.ext.2", + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1567", "ISM-1568", "ISM-1632", @@ -1997,6 +1933,9 @@ "ISM-1788", "ISM-1789" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "americas-can-itsp-10-171-2025": [ "03.17.01.A", "03.17.02", @@ -2028,9 +1967,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize security safeguards to limit harm from potential adversaries who identify and target the organization's supply chain.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to utilize security safeguards to limit harm from potential adversaries who identify and target the organization's supply chain. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2126,7 +2065,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -2151,7 +2091,7 @@ ], "general-iso-27002-2022": [ "5.19", - "5.2" + "5.20" ], "general-iso-27018-2025": [ "5.19", @@ -2173,6 +2113,10 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -2205,38 +2149,17 @@ "Article 21.3" ], "emea-deu-c5-2020": [ - "SSO-02" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.2" + "UP-01-BP1" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "apac-aus-ism-2024-june": [ - "ISM-1567" - ], - "apac-aus-ps-cps-230-2023": [ - "56(a)", - "56(b)", - "56(c)", - "56(d)" - ], - "apac-aus-ps-cps-234-2019": [ - "22" - ], - "apac-chn-pipl-2021": [ - "20" - ], - "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" + "apac-aus-ism-2026-march": [ + "ISM-1567" ], "americas-can-itsp-10-171-2025": [ "03.17.03.A", @@ -2249,7 +2172,7 @@ "title": "Processes To Address Weaknesses or Deficiencies", "family": "TPM", "description": "Mechanisms exist to address identified weaknesses or deficiencies in the security of the supply chain", - "scf_question": "Does the organization address identified weaknesses or deficiencies in the security of the supply chain", + "scf_question": "Does the organization address identified weaknesses or deficiencies in the security of the supply chain?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [ @@ -2269,7 +2192,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.\n▪ No centralized inventory of External Service Providers (ESP) is maintained.\n▪ ESP are not formally managed according to criticality.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address identified weaknesses or deficiencies in the security of the supply chain", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address identified weaknesses or deficiencies in the security of the supply chain ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2365,7 +2288,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -2423,6 +2347,10 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -2463,8 +2391,9 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-deu-c5-2020": [ - "SSO-02" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2" ], "americas-can-itsp-10-171-2025": [ "03.17.03.A", @@ -2490,11 +2419,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to develop and implement a spare parts strategy to ensure that an adequate supply of critical components is available to meet operational needs.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to develop and implement a spare parts strategy to ensure that an adequate supply of critical components is available to meet operational needs. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -2571,7 +2500,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -2612,7 +2542,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel proactively control and monitor third-party accounts used to access, support, or maintain system components via remote access.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to mitigate the risks associated with third-party access to the organization's TAASD.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2710,7 +2640,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -2770,7 +2701,7 @@ "A.10.2", "A.10.3" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1041", "T1048", "T1048.002", @@ -2821,6 +2752,16 @@ "03.17.03.a", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.a", + "A.03.16.03.c", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07" @@ -2867,11 +2808,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.2" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.1", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -2915,10 +2851,10 @@ "314.4(f)(3)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-irs-1075-2021": [ "2.C.9", @@ -2974,74 +2910,24 @@ "9.2" ], "emea-deu-c5-2020": [ - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "11.3", - "16.1", - "22.4" + "PS-04-DOAR" ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], - "emea-sau-otcc-1-2022": [ - "4-1-1-3" - ], - "emea-zaf-popia-2013": [ - "19" - ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.5" - ], - "emea-esp-decree-311-2022": [ - "13.5" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-36" ], - "emea-gbr-cap-1850-2020": [ - "A4" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1569" ], - "apac-aus-ps-cps-234-2019": [ - "16", - "22", - "28" - ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)" - ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], - "americas-arg-ppd-2018": [ - "25.1" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25" + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.50" ], "americas-can-itsp-10-171-2025": [ "03.16.03.A", @@ -3074,7 +2960,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to conduct a risk assessment prior to the acquisition or outsourcing of technology-related Technology Assets, Applications and/or Services (TAAS).", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3173,7 +3059,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -3262,7 +3149,13 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.17.03.a[01]" + "A.03.11.01.a", + "A.03.17.02[02]", + "A.03.17.02[03]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[01]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.SC-06", @@ -3370,9 +3263,6 @@ "usa-state-vt-act-171-2018": [ "2447(b)(6)(A)" ], - "emea-eu-eba-ict-srm-2025": [ - "3.6.2(74)" - ], "emea-eu-dora-2023": [ "Article 28.4(a)", "Article 28.4(b)", @@ -3392,66 +3282,62 @@ "9.2", "9.5" ], - "emea-deu-c5-2020": [ - "SSO-02", - "SSO-04" - ], - "emea-isr-cmo-1-0": [ - "16.3", - "16.5", - "17.3" - ], "emea-sau-cscc-1-2019": [ "4-1-1-1", "4-1-1-2" ], "emea-sau-ecc-1-2018": [ - "1-5-3-4", "4-1-3-1" ], "emea-sau-otcc-1-2022": [ - "4-1-1-2", - "4-1-1-4" - ], - "emea-sau-sama-csf-1-2017": [ - "3.4.1", - "3.4.2" + "4-1-1-2" ], - "emea-zaf-popia-2013": [ - "19" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "emea-gbr-cap-1850-2020": [ "A4" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1568", "ISM-1573", - "ISM-1787" + "ISM-1787", + "ISM-1882" ], "apac-aus-ps-cps-230-2023": [ "15", + "53", "53(a)", "53(b)" ], "apac-aus-ps-cps-234-2019": [ - "22", - "28" + "16" ], "apac-jpn-ismap": [ "14.1.1.14", "15.1.1.16.B" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.46", + "10.47", + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HML25" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP67" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.25", - "4.27" + "apac-sgp-mas-trm-2021": [ + "3.4.2", + "5.3.1", + "5.3.2", + "6.4.2", + "6.4.3" + ], + "americas-bmu-mba-coc-2020": [ + "5.10" ], "americas-can-itsp-10-171-2025": [ "03.11.01.A", @@ -3552,7 +3438,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -3635,9 +3522,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "SA-09 (02)" - ], - "emea-isr-cmo-1-0": [ - "16.3" ] } }, @@ -3661,7 +3545,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure that the interests of external service providers are consistent with and reflect organizational interests.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -3741,7 +3625,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -3796,12 +3681,8 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" ], - "emea-isr-cmo-1-0": [ - "16.3" - ], - "emea-zaf-popia-2013": [ - "20", - "21" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ] } }, @@ -3827,7 +3708,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to restrict the location of information processing/storage based on business requirements.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to restrict the location of information processing/storage based on business requirements. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3923,7 +3804,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -3981,6 +3863,9 @@ "general-nist-800-171-r3": [ "03.16.03.a" ], + "general-nist-800-171a-r3": [ + "A.03.16.03.a" + ], "general-nist-csf-2-0": [ "GV.SC-06" ], @@ -4010,9 +3895,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "3.2.1" ], - "general-scf-dpmp-2025": [ - "5.6" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -4050,84 +3932,17 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "emea-aut-fappd-2000": [ - "Sec 10" - ], - "emea-bel-act-8-1992": [ - "Chapter 4 - 16" - ], - "emea-deu-c5-2020": [ - "PI-02", - "PSS-12" - ], - "emea-hun-isdfi-2011": [ - "7" - ], - "emea-irl-dpa-2003": [ - "2" - ], - "emea-isr-cmo-1-0": [ - "16.3" - ], - "emea-isr-ppl-5741-1981": [ - "16", - "17" - ], - "emea-ita-pdpc-2003": [ - "31" - ], - "emea-nor-pda-2018": [ - "13", - "14" - ], - "emea-pol-act-29-1997": [ - "1", - "36" - ], - "emea-rus-federal-law-27-2006": [ - "7" - ], - "emea-zaf-popia-2013": [ - "19", - "21" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1572" ], - "apac-chn-pipl-2021": [ - "21", - "38", - "38(3)", - "40" - ], - "apac-jpn-ppi-2020": [ - "20" - ], - "apac-mys-pdpa-2010": [ - "9" - ], - "apac-phl-dpa-2012": [ - "25" - ], - "apac-sgp-pdpa-2012": [ - "24", - "26" - ], - "apac-kor-pipa-2011": [ - "17", - "27" + "apac-mys-bnm-rmit-2025": [ + "10.50" ], "americas-can-itsp-10-171-2025": [ "03.16.03.A" - ], - "americas-can-pipeda-2000": [ - "Sec 20" - ], - "americas-chl-act-19628-1999": [ - "7" - ], - "americas-col-law-1581-2012": [ - "26" ] } }, @@ -4136,7 +3951,7 @@ "title": "Third-Party Contract Requirements", "family": "TPM", "description": "Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).", - "scf_question": "Does the organization require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD)?", + "scf_question": "Does the organization require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting its needs to protect its Technology Assets, Applications, Services and/or Data (TAASD)?", "relative_weight": 10, "conformity_cadence": "Annual", "evidence_requests": [ @@ -4155,7 +3970,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.\n▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its TAASD.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -4254,9 +4069,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -4423,8 +4238,22 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.01.20.c.02", + "A.03.07.06.a", "A.03.16.03.ODP[01]", - "A.03.16.03.a" + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" + ], + "general-nist-800-172-r3": [ + "03.17.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.17.01E.ODP[02]" ], "general-nist-800-218": [ "PO.1" @@ -4490,9 +4319,6 @@ "12.8.2", "12.8.5" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -4566,6 +4392,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SR-03(03)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(f)(2)" + ], "usa-federal-sro-finra": [ "248.30(a)(5)(ii)" ], @@ -4583,54 +4412,54 @@ "155.260(b)(2)(iv)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)", - "164.502(a)(4)(i)", - "164.502(a)(4)(ii)", - "164.502(e)(1)(i)", - "164.502(e)(2)", - "164.504(e)(2)(i)", - "164.504(e)(2)(i)(A)", - "164.504(e)(2)(i)(B)", - "164.504(e)(2)(ii)(J)", - "164.504(e)(4)(i)(B)(ii)(B)(1)", - "164.504(e)(4)(i)(B)(ii)(B)(2)", - "164.504(f)(1)(i)", - "164.504(f)(2)(i)", - "164.504(f)(2)(ii)", - "164.504(f)(2)(ii)(A)", - "164.504(f)(2)(ii)(B)", - "164.504(f)(2)(ii)(C)", - "164.504(f)(2)(ii)(D)", - "164.504(f)(2)(ii)(E)", - "164.504(f)(2)(ii)(F)", - "164.504(f)(2)(ii)(G)", - "164.504(f)(2)(ii)(H)", - "164.504(f)(2)(ii)(I)", - "164.504(f)(2)(ii)(J)", - "164.504(f)(2)(iii)(A)", - "164.504(f)(2)(iii)(B)", - "164.504(f)(2)(iii)(C)", - "164.504(f)(3)(i)", - "164.504(f)(3)(ii)", - "164.504(f)(3)(iii)", - "164.504(f)(3)(iv)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)", + "§ 164.502(a)(4)(i)", + "§ 164.502(a)(4)(ii)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(2)", + "§ 164.504(e)(2)(i)", + "§ 164.504(e)(2)(i)(A)", + "§ 164.504(e)(2)(i)(B)", + "§ 164.504(e)(2)(ii)(J)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(1)", + "§ 164.504(e)(4)(i)(B)(ii)(B)(2)", + "§ 164.504(f)(1)(i)", + "§ 164.504(f)(2)(i)", + "§ 164.504(f)(2)(ii)", + "§ 164.504(f)(2)(ii)(A)", + "§ 164.504(f)(2)(ii)(B)", + "§ 164.504(f)(2)(ii)(C)", + "§ 164.504(f)(2)(ii)(D)", + "§ 164.504(f)(2)(ii)(E)", + "§ 164.504(f)(2)(ii)(F)", + "§ 164.504(f)(2)(ii)(G)", + "§ 164.504(f)(2)(ii)(H)", + "§ 164.504(f)(2)(ii)(I)", + "§ 164.504(f)(2)(ii)(J)", + "§ 164.504(f)(2)(iii)(A)", + "§ 164.504(f)(2)(iii)(B)", + "§ 164.504(f)(2)(iii)(C)", + "§ 164.504(f)(3)(i)", + "§ 164.504(f)(3)(ii)", + "§ 164.504(f)(3)(iii)", + "§ 164.504(f)(3)(iv)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.308(b)(3)", - "164.314(a)(2)(iii)", - "164.314(b)(1)", - "164.314(b)(2)(i)", - "164.314(b)(2)(ii)", - "164.314(b)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.308(b)(3)", + "§ 164.314(a)(2)(iii)", + "§ 164.314(b)(1)", + "§ 164.314(b)(2)(i)", + "§ 164.314(b)(2)(ii)", + "§ 164.314(b)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "3.3.1.g", @@ -4717,9 +4546,9 @@ "2447(b)(6)(B)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8", + "3.2.3.8(a)", + "3.2.3.8(b)" ], "emea-eu-dora-2023": [ "Article 28.1(a)", @@ -4777,28 +4606,21 @@ "9.4" ], "emea-deu-c5-2020": [ - "HR-06", - "PI-02", - "SSO-02", - "SSO-05" - ], - "emea-isr-cmo-1-0": [ - "11.1", - "11.3", - "11.10", - "16.2", - "19.5", - "22.4", - "25.17" - ], - "emea-pol-act-29-1997": [ - "31" + "UP-01-BP1", + "UP-01-BP6", + "UP-03", + "OIS-03", + "DLL-01", + "DLL-01-BP1", + "DLL-01-BP2", + "DLL-01-BP3", + "DLL-01-BP4", + "BCM-05" ], "emea-qat-pdppl-2020": [ - "12" + "3.11.8" ], "emea-sau-cscc-1-2019": [ - "4-1-1", "4-1-1-1", "4-1-1-2" ], @@ -4807,7 +4629,6 @@ "4-2-5" ], "emea-sau-ecc-1-2018": [ - "4-1-2", "4-1-2-1", "4-1-2-2", "4-1-2-3" @@ -4820,21 +4641,26 @@ "Article 8" ], "emea-sau-sacs-002-2022": [ - "TPC-25" - ], - "emea-srb-act-9-2018": [ - "5", - "11" + "VII.A.TPC-17", + "VII.A.TPC-23-BP2" ], - "emea-zaf-popia-2013": [ - "20" - ], - "emea-esp-decree-1720-2007": [ - "20", - "21" - ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.1 [OP.EXT.1]" + "emea-sau-sama-csf-1-2017": [ + "3.4.1.4.b", + "3.4.1.4.c", + "3.4.1.5", + "3.4.1.5.a", + "3.4.1.5.b", + "3.4.1.5.c", + "3.4.1.5.d", + "3.4.1.5.e", + "3.4.1.5.f", + "3.4.1.5.g" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.3", + "mp.com.2", + "mp.com.3" ], "emea-gbr-def-stan-05-138-2024": [ "1401", @@ -4852,7 +4678,7 @@ "1401", "2323" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0072", "ISM-1395", "ISM-1451", @@ -4866,31 +4692,27 @@ ], "apac-aus-ps-cps-230-2023": [ "15", + "16(f)", + "54", "54(a)", "54(b)", "54(c)", "54(d)", "54(e)", "54(f)", - "54(g)", + "55", "55(a)", "55(b)", - "55(c)" - ], - "apac-aus-ps-cps-234-2019": [ - "16", - "20", - "28" + "55(c)", + "56", + "56(a)", + "56(b)", + "56(c)", + "56(d)" ], "apac-chn-cybersecurity-law-2017": [ "Article 36" ], - "apac-chn-pipl-2021": [ - "20", - "21", - "38(3)", - "42" - ], "apac-ind-dpdpa-2023": [ "8(7)(b)" ], @@ -4900,29 +4722,6 @@ "GV.SC.S8", "PR.AT.S3" ], - "apac-jpn-ppi-2020": [ - "22", - "23(1)(i)", - "23(1)(ii)", - "23(1)(iii)", - "23(1)(iv)", - "23(2)", - "23(2)(i)", - "23(2)(ii)", - "23(2)(iii)", - "23(2)(iv)", - "23(2)(v)", - "23(2)(vi)", - "23(2)(vii)", - "23(2)(viii)", - "23(3)", - "23(4)", - "23(5)(i)", - "23(5)(ii)", - "23(5)(iii)", - "23(6)", - "23(1)" - ], "apac-jpn-ismap": [ "6.3.P", "7.1.1.11", @@ -4967,7 +4766,15 @@ "15.1.3.11.P", "15.2" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.12", + "10.24", + "10.25", + "10.46", + "10.48", + "10.50" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP09", "HHSP36", "HHSP72", @@ -4975,30 +4782,28 @@ "HML36", "HML72" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS06" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP63", "HSUP68" ], "apac-nzl-ism-3-9": [ "2.3.30.C.01", + "20.1.20.C.05", + "20.1.23.C.02", + "20.1.23.C.03", + "20.1.24.C.01", + "20.1.25.C.01", "23.2.19.C.01" ], - "apac-phl-dpa-2012": [ - "25", - "43" - ], "apac-sgp-mas-trm-2021": [ - "3.4.1", - "3.4.2", - "3.4.3" + "3.4.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.10", + "5.11-BP2" ], - "amaericas-can-osfi-self-assessment": [ - "2.3", - "4.26", - "4.28" + "americas-can-osfi-self-assessment-2": [ + "2.8.1" ], "americas-can-itsp-10-171-2025": [ "03.01.20.B", @@ -5010,9 +4815,6 @@ "03.16.03.C", "03.17.02", "03.17.03.B" - ], - "americas-mex-fdpa-2010": [ - "21" ] } }, @@ -5034,7 +4836,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to compel External Service Providers (ESPs) to provide notification of actual or potential compromises in the supply chain that can potentially affect or have adversely affected Technology Assets, Applications and/or Services (TAAS) that the organization utilizes.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5131,7 +4933,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -5185,6 +4988,16 @@ "general-nist-800-171-r3": [ "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.17.02[05]" + ], + "general-nist-800-172-r3": [ + "03.17.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.17.01E", + "A.03.17.01E.ODP[01]" + ], "general-shared-assessments-sig-2025": [ "P.8" ], @@ -5210,16 +5023,16 @@ "SR-08" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)", - "164.410(a)(1)", - "164.410(a)(2)", - "164.410(b)", - "164.410(c)(2)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)", + "§ 164.410(a)(1)", + "§ 164.410(a)(2)", + "§ 164.410(b)", + "§ 164.410(c)(2)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.314(a)(2)(i)(C)", - "164.314(b)(2)(iv)" + "§ 164.314(a)(2)(i)(C)", + "§ 164.314(b)(2)(iv)" ], "usa-federal-nerc-cip-2024": [ "CIP-013-2 1.2.1" @@ -5236,9 +5049,18 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "SR-08" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "RB-20" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.3" + ], + "apac-aus-ism-2026-march": [ "ISM-1576" ], + "apac-mys-bnm-rmit-2025": [ + "10.49" + ], "apac-nzl-ism-3-9": [ "7.2.22.C.01", "7.2.23.C.01" @@ -5268,7 +5090,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.\n▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure applicable security, compliance and resilience requirements are included in contracts that flow-down to applicable sub-contractors and suppliers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5344,9 +5166,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -5401,7 +5223,12 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.16.03.ODP[01]" + "A.03.16.03.ODP[01]", + "A.03.16.03.a", + "A.03.16.03.b", + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.OC-03", @@ -5410,9 +5237,6 @@ "GV.SC-06", "GV.SC-10" ], - "general-scf-dpmp-2025": [ - "10.3" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -5464,18 +5288,18 @@ "155.260(b)(2)(v)" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)", - "164.502(e)(1)(ii)", - "164.504(e)(2)(ii)(D)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)", + "§ 164.502(e)(1)(ii)", + "§ 164.504(e)(2)(ii)(D)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)", - "164.308(b)(2)", - "164.314(a)(2)(i)(B)", - "164.314(a)(2)(iii)" + "§ 164.308(b)(1)", + "§ 164.308(b)(2)", + "§ 164.314(a)(2)(i)(B)", + "§ 164.314(a)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SR-3(CE-3)" @@ -5505,9 +5329,7 @@ "59.1-579.B.5" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)" + "3.2.3.8" ], "emea-eu-dora-2023": [ "Article 29.2" @@ -5518,15 +5340,17 @@ "emea-eu-nis2-annex-2024": [ "5.1.4(g)" ], - "emea-qat-pdppl-2020": [ - "12" + "emea-deu-bsrit-2017": [ + "9.4" ], - "emea-sau-sacs-002-2022": [ - "TPC-25" + "emea-deu-c5-2020": [ + "UP-01-BP6", + "DLL-01-BP2", + "DLL-01-BP4", + "DLL-01-DOAR" ], - "emea-srb-act-9-2018": [ - "5", - "11" + "emea-sau-ecc-1-2018": [ + "4-1-2-3" ], "emea-gbr-def-stan-05-138-2024": [ "1401" @@ -5547,6 +5371,9 @@ "GV.SC.S3", "GV.SC.S8" ], + "apac-mys-bnm-rmit-2025": [ + "10.48" + ], "americas-can-itsp-10-171-2025": [ "03.16.03.A", "03.16.03.B", @@ -5576,7 +5403,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure External Service Providers (ESPs) use unique authentication factors for each of its customers.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5642,7 +5469,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -5681,9 +5509,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ IT and/or cybersecurity personnel govern third-party cybersecurity and data protection roles and responsibilities through a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar shared responsibilities tracking tool.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to document and maintain a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to delineate assignment for security, compliance and resilience controls between internal stakeholders and External Service Providers (ESPs).", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to document and maintain a Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to delineate assignment for security, compliance and resilience controls between internal stakeholders and External Service Providers (ESPs). ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5759,9 +5587,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -5778,7 +5606,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0" + "15" ], "general-coso-2013": [ "12" @@ -5853,9 +5681,11 @@ ], "general-nist-800-171-r3": [ "03.07.06.a", + "03.07.06.b", "03.16.03.b" ], "general-nist-800-171a-r3": [ + "A.03.07.06.b", "A.03.16.03.b" ], "general-nist-csf-2-0": [ @@ -5915,9 +5745,6 @@ "12.8.2", "12.8.5" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -5936,10 +5763,10 @@ "THIRD-PARTIES-1a" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(1)" + "§ 164.308(b)(1)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -5961,11 +5788,8 @@ "500.10(b)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)", - "3.2.3(8)(a)", - "3.2.3(8)(b)", - "3.3.2(16)", - "3.5(55)" + "3.2.3.8", + "3.5.55" ], "emea-eu-nis2-2022": [ "Article 21.3" @@ -5975,19 +5799,25 @@ "8.1.1", "10.1.2(a)" ], + "emea-deu-c5-2020": [ + "UP-01-BP5", + "UP-01-BP6", + "OIS-03", + "SIM-06" + ], + "emea-sau-ecc-1-2018": [ + "4-1-2-2" + ], "emea-sau-otcc-1-2022": [ "1-2-1-1" ], - "emea-esp-boe-a-2022-7191": [ - "Article 13.2", - "Article 13.5" - ], "emea-esp-decree-311-2022": [ - "13.2", - "13.5" + "Article 11(2)", + "Article 13(3)", + "Article 13(5)" ], - "emea-gbr-cap-1850-2020": [ - "A4" + "emea-esp-ccn-stic-825-2026": [ + "org.4" ], "apac-ind-sebi-2024": [ "GV.OC.S3", @@ -6003,8 +5833,19 @@ "6.1.5.6", "6.3.1.P" ], + "apac-mys-bnm-rmit-2025": [ + "10.46", + "10.48" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.2" + ], + "americas-bmu-mba-coc-2020": [ + "5.10" + ], "americas-can-itsp-10-171-2025": [ "03.07.06.A", + "03.07.06.B", "03.16.03.B" ] } @@ -6029,7 +5870,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to perform recurring validation of the Responsible, Accountable, Supportive, Consulted & Informed (RASCI) matrix, or similar documentation, to ensure security, compliance and resilience control assignments accurately reflect current:\n(1) Contractual obligations for the External Service Provider (ESP);\n(2) Business practices;\n(3) Applicable stakeholders; and\n(4) Deployed Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6091,9 +5932,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -6103,7 +5944,7 @@ "CC9.2-POF12" ], "general-cis-csc-8-1": [ - "15.0" + "15" ], "general-iso-42001-2023": [ "4.3" @@ -6115,7 +5956,11 @@ "03.17.03.b" ], "general-nist-800-171a-r3": [ - "A.03.16.03.c" + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.a[02]", + "A.03.17.03.b" ], "general-nist-csf-2-0": [ "GV.SC-06" @@ -6157,9 +6002,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.1" ], - "general-scf-dpmp-2025": [ - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -6174,14 +6016,23 @@ "500.11(a)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.5(55)" + "3.5.55" ], "emea-eu-nis2-2022": [ "Article 21.3" ], - "apac-aus-ism-2024-june": [ + "emea-deu-c5-2020": [ + "UP-01-BP1" + ], + "apac-aus-ism-2026-march": [ "ISM-1793" ], + "apac-mys-bnm-rmit-2025": [ + "10.46" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.3" + ], "americas-can-itsp-10-171-2025": [ "03.16.03.C", "03.17.02", @@ -6210,9 +6061,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to obtain a First-Party Declaration(1PD) from applicable External Service Providers (ESPs) that provides assurance of compliance with specified statutory, regulatory and contractual obligations for security, compliance and resilience controls, including any flow-down requirements to subcontractors.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to obtain a First-Party Declaration(1PD) from applicable External Service Providers (ESPs) that provides assurance of compliance with specified statutory, regulatory and contractual obligations for security, compliance and resilience controls, including any flow-down requirements to subcontractors. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6285,9 +6136,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -6309,6 +6160,7 @@ "03.16.03.c" ], "general-nist-800-171a-r3": [ + "A.03.01.20.c.01", "A.03.16.03.c" ], "general-nist-csf-2-0": [ @@ -6327,12 +6179,12 @@ "7.2.2.5" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.308(b)(2)", - "164.502(e)(1)(i)", - "164.502(e)(1)(ii)" + "§ 164.308(b)(2)", + "§ 164.502(e)(1)(i)", + "§ 164.502(e)(1)(ii)" ], "usa-federal-law-hipaa-security-rule-2013": [ - "164.308(b)(2)" + "§ 164.308(b)(2)" ], "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" @@ -6347,11 +6199,14 @@ "500.11(b)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(9)" + "3.2.3.9" ], "emea-eu-nis2-2022": [ "Article 21.3" ], + "emea-qat-pdppl-2020": [ + "3.11.8" + ], "emea-sau-cgiot-2024": [ "4-1-2" ], @@ -6384,7 +6239,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.\n▪ Contracts with ESP contain break clauses to enable penalty-free, early termination of a contract for cause, based on ESP cybersecurity and/or data protection practices deficiency(ies).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to include \"break clauses\" within contracts for failure to meet contract criteria for security, compliance and/or resilience controls.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -6457,9 +6312,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-pmf-2020": [ @@ -6497,6 +6352,12 @@ "03.17.02", "03.17.03.b" ], + "general-nist-800-171a-r3": [ + "A.03.17.01.a[01]", + "A.03.17.02[05]", + "A.03.17.02[06]", + "A.03.17.03.b" + ], "general-nist-csf-2-0": [ "GV.SC-06" ], @@ -6513,7 +6374,7 @@ "1.H" ], "usa-federal-law-hipaa-simplification-2013": [ - "164.504(e)(2)(iii)" + "§ 164.504(e)(2)(iii)" ], "usa-federal-irs-1075-2021": [ "SA-9(CE-3)" @@ -6536,15 +6397,18 @@ "emea-eu-nis2-2022": [ "Article 21.3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1804" ], "apac-aus-ps-cps-230-2023": [ - "50(g)" + "54(g)" ], "apac-ind-sebi-2024": [ "GV.SC.S3" ], + "apac-mys-bnm-rmit-2025": [ + "10.50" + ], "americas-can-itsp-10-171-2025": [ "03.17.01.A", "03.17.02", @@ -6644,9 +6508,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-iso-21434-2021": [ @@ -6664,6 +6528,10 @@ "03.16.03.c" ], "general-nist-800-171a-r3": [ + "A.03.01.20.a", + "A.03.01.20.b", + "A.03.01.20.c.01", + "A.03.16.03.a", "A.03.16.03.c" ], "general-tisax-6-0-3": [ @@ -6672,6 +6540,16 @@ "usa-state-nv-regulation-5-2024": [ "5.260.5(c)" ], + "emea-deu-c5-2020": [ + "UP-04" + ], + "emea-qat-pdppl-2020": [ + "3.11.8" + ], + "emea-sau-sacs-002-2022": [ + "VII.A.TPC-20", + "VII.A.TPC-21" + ], "apac-ind-sebi-2024": [ "PR.IP.S15", "PR.IP.S16" @@ -6705,7 +6583,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to control personnel security requirements including security roles and responsibilities for third-party providers.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6802,7 +6680,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -6864,23 +6743,18 @@ "5.1.4(c)", "10.2.1" ], - "emea-isr-cmo-1-0": [ - "11.1", - "11.3", - "18.10", - "19.5" + "emea-esp-decree-311-2022": [ + "Article 13(5)" ], - "apac-aus-ism-2024-june": [ - "ISM-1569" + "emea-esp-ccn-stic-825-2026": [ + "org.4", + "op.ext.1" ], - "apac-chn-pipl-2021": [ - "52" + "apac-aus-ism-2026-march": [ + "ISM-1569" ], "apac-ind-sebi-2024": [ "PR.AT.S3" - ], - "amaericas-can-osfi-self-assessment": [ - "2.3" ] } }, @@ -6902,9 +6776,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of organizational information.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor for evidence of unauthorized exfiltration or disclosure of organizational information. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6963,7 +6837,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -6977,22 +6852,15 @@ "usa-state-ca-ccpa-cpra-2026": [ "7123(c)(15)" ], - "emea-deu-c5-2020": [ - "SSO-04" - ], - "emea-isr-cmo-1-0": [ - "11.5", - "11.11" + "apac-mys-bnm-rmit-2025": [ + "10.49" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP73", "HML73" ], "apac-nzl-hisf-suppliers-2023": [ "HSUP64" - ], - "amaericas-can-osfi-self-assessment": [ - "4.27" ] } }, @@ -7016,9 +6884,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to monitor, regularly review and assess External Service Providers (ESPs) for compliance with established contractual requirements for security, compliance and resilience controls. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7098,9 +6966,9 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Third-Party Management", "crosswalks": { "general-aicpa-tsc-2017": [ @@ -7116,7 +6984,7 @@ "CC9.2-POF13" ], "general-cis-csc-8-1": [ - "15.0", + "15", "15.6" ], "general-cis-csc-8-1-ig3": [ @@ -7207,7 +7075,9 @@ "03.17.02" ], "general-nist-800-171a-r3": [ - "A.03.16.03.c" + "A.03.16.03.c", + "A.03.17.02[05]", + "A.03.17.02[06]" ], "general-nist-csf-2-0": [ "GV.SC-07", @@ -7252,10 +7122,6 @@ "general-pci-dss-4-0-1-saq-p2pe": [ "12.8.4" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -7313,7 +7179,7 @@ "500.11(a)(4)" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(9)" + "3.2.3.9" ], "emea-eu-dora-2023": [ "Article 28.6", @@ -7327,13 +7193,17 @@ "5.1.7(b)", "5.1.7(c)" ], + "emea-deu-bsrit-2017": [ + "9.3" + ], "emea-deu-c5-2020": [ - "SSO-04", - "SSO-05" + "DLL-02", + "DLL-02-BP1", + "DLL-02-BP2", + "DLL-02-BP3" ], - "emea-isr-cmo-1-0": [ - "11.4", - "11.5" + "emea-qat-pdppl-2020": [ + "3.11.8" ], "emea-sau-cgiot-2024": [ "4-1-6" @@ -7344,23 +7214,21 @@ "emea-sau-pdpl-2023": [ "Article 8" ], - "apac-aus-ism-2024-june": [ - "ISM-1793" + "emea-sau-sama-csf-1-2017": [ + "3.3.11.6" ], - "apac-aus-ps-cps-230-2023": [ - "58(a)", - "58(b)", - "58(c)" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1", + "op.ext.2", + "mp.com.2", + "mp.com.3" ], - "apac-aus-ps-cps-234-2019": [ - "28" + "apac-aus-ism-2026-march": [ + "ISM-1793" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "apac-jpn-ppi-2020": [ - "24(3)" - ], "apac-jpn-ismap": [ "13.1.2.1", "15.2.1", @@ -7378,15 +7246,15 @@ "15.2.1.12", "15.2.1.13" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.49" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP25", "HHSP73", "HML25", "HML73" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS04" - ], "apac-nzl-hisf-suppliers-2023": [ "HSUP64", "HSUP67" @@ -7394,9 +7262,6 @@ "apac-sgp-mas-trm-2021": [ "3.4.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.27" - ], "americas-can-itsp-10-171-2025": [ "03.16.03.C", "03.17.02" @@ -7423,9 +7288,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -7520,7 +7385,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -7555,6 +7421,9 @@ "general-nist-800-171-r3": [ "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.17.02[06]" + ], "general-nist-csf-2-0": [ "GV.SC-06", "GV.SC-07", @@ -7567,10 +7436,6 @@ "general-pci-dss-4-0-1": [ "A3.3.1.2" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-swift-cscf-2025": [ "2.8" ], @@ -7594,21 +7459,20 @@ "Article 21.3", "Article 21.4" ], - "emea-deu-c5-2020": [ - "SSO-04" - ], "emea-sau-cgiot-2024": [ "4-1-6" ], - "emea-sau-ecc-1-2018": [ - "4-1-2-3" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "amaericas-can-osfi-self-assessment": [ - "2.7", - "4.27" + "apac-jpn-appi-2020": [ + "IV.5.53(4)" + ], + "apac-sgp-mas-trm-2021": [ + "3.4.3" ], "americas-can-itsp-10-171-2025": [ "03.17.02" @@ -7635,7 +7499,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to control changes to services by suppliers, taking into account the criticality of business TAASD that are in scope by the third-party.", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -7733,7 +7597,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -7821,13 +7686,13 @@ "03.16.01", "03.17.02" ], + "general-nist-800-171a-r3": [ + "A.03.16.01", + "A.03.17.02[06]" + ], "general-nist-csf-2-0": [ "GV.SC-08" ], - "general-scf-dpmp-2025": [ - "10.0", - "10.4" - ], "general-shared-assessments-sig-2025": [ "K.6" ], @@ -7877,21 +7742,17 @@ "5.1.7(d)" ], "emea-deu-c5-2020": [ - "SSO-04", - "SSO-05" + "OIS-03" ], - "emea-esp-ccn-stic-825-2023": [ - "7.4.2 [OP.EXT.2]" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1794" ], "apac-ind-sebi-2024": [ "GV.SC.S4" ], - "apac-jpn-ppi-2020": [ - "24(3)" - ], "apac-jpn-ismap": [ "15.2.1.14", "15.2.1.15", @@ -7900,9 +7761,6 @@ "15.2.2.2", "15.2.2.3" ], - "amaericas-can-osfi-self-assessment": [ - "4.27" - ], "americas-can-itsp-10-171-2025": [ "03.16.01", "03.17.02" @@ -7931,7 +7789,7 @@ "0": "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.", "1": "Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are documented and maintained by process owners.\n▪ 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Third-party management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Asset management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure response/recovery planning and testing are conducted with critical suppliers/providers.", + "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to ensure response/recovery planning and testing are conducted with critical suppliers/providers. ", "4": "Third-Party Management (TPM) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -8026,7 +7884,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Third-Party Management", "crosswalks": { @@ -8108,16 +7967,13 @@ "CIP-013-2 1.2.2" ], "emea-eu-eba-ict-srm-2025": [ - "3.2.3(8)(b)" - ], - "emea-isr-cmo-1-0": [ - "25.17" + "3.2.3.8(b)" ], "emea-sau-ecc-1-2018": [ "4-1-2-2" ], - "amaericas-can-osfi-self-assessment": [ - "4.28" + "emea-esp-ccn-stic-825-2026": [ + "op.ext.1" ] } }, @@ -8126,7 +7982,7 @@ "title": "Foreign Ownership, Control or Influence (FOCI)", "family": "TPM", "description": "Mechanisms exist to minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices.", - "scf_question": "Does the organization minimize risk associate with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices?", + "scf_question": "Does the organization minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices?", "relative_weight": 6, "conformity_cadence": "Annual", "evidence_requests": [], @@ -8139,7 +7995,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to minimize risk associated with Foreign Ownership, Control or Influence (FOCI) through Supply Chain Risk Management (SCRM) practices.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8180,9 +8036,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} }, @@ -8204,7 +8060,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to periodically review External Service Providers (ESP) for changes that affect Foreign Ownership, Control or Influence (FOCI).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8243,9 +8099,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} }, @@ -8267,7 +8123,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Third-Party Management (TPM) 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:\n▪ Policies and standards associated with TPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with TPM domain capabilities are well-documented and kept current by process owners.\n▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution, vendor management solution, etc.).\n▪ 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 TPM 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).\n▪ An implemented and operational capability exists to contractually impose safeguards (e.g., additional controls, access modification, contract termination, etc.) from Foreign Ownership, Control or Influence (FOCI) concerns to ensure that:\n(1) Unauthorized access to sensitive and/or regulated data is prevented; and \n(2) Performance of contracts is not adversely affected.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -8312,9 +8168,9 @@ "MT-22", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- new control (SCF)", "family_name": "Third-Party Management", "crosswalks": {} } diff --git a/docs/api/families/VPM.json b/docs/api/families/VPM.json index c7a4c3be..5e0e8ee7 100644 --- a/docs/api/families/VPM.json +++ b/docs/api/families/VPM.json @@ -1,7 +1,7 @@ { "family_code": "VPM", "family_name": "Vulnerability & Patch Management", - "control_count": 33, + "control_count": 34, "controls": [ { "control_id": "VPM-01", @@ -124,7 +124,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -137,9 +138,9 @@ "CC9.2-POF13" ], "general-cis-csc-8-1": [ - "7.0", + "7", "7.1", - "18.0" + "18" ], "general-cis-csc-8-1-ig1": [ "7.1" @@ -274,7 +275,9 @@ "3.14.1[f]" ], "general-nist-800-171a-r3": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" ], "general-nist-csf-2-0": [ "ID.RA-01", @@ -318,9 +321,6 @@ "6.3.1", "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "T.2" ], @@ -460,8 +460,8 @@ "SI-03" ], "emea-eu-eba-ict-srm-2025": [ - "3.3.3(21)", - "3.4.4(36)(a)" + "3.3.3.21", + "3.4.4.36(a)" ], "emea-eu-dora-2023": [ "Article 9.4(f)", @@ -478,64 +478,46 @@ "6.10.2(a)", "6.10.2(d)" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.1", - "22.2" + "RB-17", + "RB-17-BP2" ], "emea-sau-cscc-1-2019": [ "2-3-1-3", - "2-9", + "2-9-1", "2-9-2" ], "emea-sau-cgiot-2024": [ "2-9-1" ], "emea-sau-ecc-1-2018": [ - "2-3-4", "2-10-1", "2-10-2", - "2-10-3", - "2-10-4", - "2-11-1", - "2-11-2", - "2-11-3", - "2-11-4", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ - "2-9", "2-9-1", - "2-9-2" - ], - "emea-sau-sacs-002-2022": [ - "TPC-11" + "2-9-2", + "2-10-1", + "2-10-2" ], "emea-sau-sama-csf-1-2017": [ - "3.3.17" - ], - "emea-zaf-popia-2013": [ - "19" + "3.3.17", + "3.3.17.1", + "3.3.17.3", + "3.3.17.3.a", + "3.3.17.3.b", + "3.3.17.3.c", + "3.3.17.3.d", + "3.3.17.3.e", + "3.3.17.3.f" + ], + "emea-esp-decree-311-2022": [ + "Article 12(6)(i)" ], "emea-gbr-caf-4-0": [ "B4.d" ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" - ], "emea-gbr-def-stan-05-138-2024": [ "2402", "2405" @@ -552,7 +534,7 @@ "2402", "2405" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1143", "ISM-1163", "ISM-1460", @@ -585,7 +567,13 @@ "12.6.1.17", "12.6.1.18.PB" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17", + "10.18", + "10.19", + "10.31" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HHSP26", "HML19", @@ -597,22 +585,20 @@ "apac-nzl-ism-3-9": [ "6.2.4.C.01" ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" - ], "apac-sgp-mas-trm-2021": [ - "4.2.1", - "7.4.1", - "7.4.2" + "6.1.4" ], - "americas-bmu-mba-coc-2020": [ - "6.16" + "americas-arg-ppd-2018": [ + "E" ], "americas-can-osfi-b13-2022": [ "2.6", "3.1" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.A", "03.14.01.A" @@ -639,7 +625,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to define and manage the scope for its attack surface management activities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -729,7 +715,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -779,7 +766,14 @@ "03.14.01.a" ], "general-nist-800-171a-r3": [ - "A.03.11.02.a[01]" + "A.03.11.02.a[01]", + "A.03.14.01.a[01]" + ], + "general-nist-800-172-r3": [ + "03.12.01E" + ], + "general-nist-800-172a-r3": [ + "A.03.12.01E.ODP[02]" ], "general-nist-csf-2-0": [ "PR.PS-02" @@ -839,9 +833,6 @@ "11.3.2", "11.3.2.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -875,6 +866,9 @@ "SA-11(06)", "SA-11(07)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-irs-1075-2021": [ "SA-11(CE-6)" ], @@ -884,28 +878,24 @@ "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.5(a)(1)" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], "emea-sau-cscc-1-2019": [ "2-10-1-1" ], "emea-sau-ecc-1-2018": [ - "2-11-3-1", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ - "2-9-1-1" + "2-9-1-1", + "2-10-1-1" ], - "emea-sau-sacs-002-2022": [ - "TPC-27", - "TPC-28", - "TPC-29" + "apac-mys-bnm-rmit-2025": [ + "10.18" ], "apac-nzl-ism-3-9": [ "6.2.4.C.01" ], "apac-sgp-mas-trm-2021": [ + "6.1.4", "13.1.2" ], "americas-can-itsp-10-171-2025": [ @@ -937,11 +927,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to ensure that vulnerabilities are properly identified, tracked and remediated.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -1029,7 +1019,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -1138,7 +1129,16 @@ "3.11.3[b]" ], "general-nist-800-171a-r3": [ - "A.03.11.02.ODP[03]" + "A.03.11.02.ODP[03]", + "A.03.11.02.b", + "A.03.12.02.a.02" + ], + "general-nist-800-172-r3": [ + "03.11.11E" + ], + "general-nist-800-172a-r3": [ + "A.03.11.11E.ODP[01]", + "DS-A.03.11.11E[02]" ], "general-nist-800-218": [ "RV.2.2" @@ -1193,9 +1193,6 @@ "11.3.2", "11.3.2.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -1239,6 +1236,9 @@ "PM-04", "SC-18(01)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-irs-1075-2021": [ "PM-4", "SC-18(CE-1)" @@ -1265,6 +1265,12 @@ "usa-state-tx-dir-security-control-standards-catalog-2-2": [ "PM-04" ], + "emea-eu-cyber-resilience-act-2024": [ + "Article 13(6)" + ], + "emea-eu-cyber-resilience-act-annex-i-2024": [ + "Annex I, Part II(2)" + ], "emea-eu-nis2-2022": [ "Article 21.4" ], @@ -1273,15 +1279,6 @@ "6.10.2(c)", "6.10.3" ], - "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.8", - "22.11", - "22.13" - ], "emea-sau-cscc-1-2019": [ "2-9-1-2" ], @@ -1289,18 +1286,16 @@ "2-9-1" ], "emea-sau-ecc-1-2018": [ - "2-10-3-3", "5-1-3-8" ], "emea-sau-otcc-1-2022": [ "2-9-1-2" ], "emea-sau-sacs-002-2022": [ - "TPC-11", - "TPC-91" - ], - "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" + "VII.B.TPC-91", + "VII.B.TPC-91-BP1", + "VII.B.TPC-91-BP2", + "VII.B.TPC-91-BP3" ], "emea-gbr-def-stan-05-138-2024": [ "2402" @@ -1314,8 +1309,10 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2402" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-aus-ism-2026-march": [ + "ISM-1902", + "ISM-1903", + "ISM-1904" ], "apac-ind-sebi-2024": [ "PR.MA.S3" @@ -1323,7 +1320,10 @@ "apac-jpn-ismap": [ "12.6.1.14" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HHSP59", "HML19", @@ -1338,20 +1338,21 @@ "23.2.19.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" + "4.2(a)" ], "apac-sgp-mas-trm-2021": [ + "6.1.4", + "13.6.1", "13.6.1(a)", "13.6.1(b)", "13.6.1(c)" ], - "amaericas-can-osfi-self-assessment": [ - "2.7" - ], "americas-can-osfi-b13-2022": [ "2.6" ], + "americas-can-osfi-self-assessment-2": [ + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", "03.12.02.A.02", @@ -1359,6 +1360,117 @@ ] } }, + { + "control_id": "VPM-02.1", + "title": "Known Exploited Vulnerabilities (KEV) Mitigations", + "family": "VPM", + "description": "Mechanisms exist to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions.", + "scf_question": "Does the organization prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions?", + "relative_weight": 7, + "conformity_cadence": "Quarterly", + "evidence_requests": [], + "pptdf": "Technology", + "nist_csf_function": "Protect", + "scrm_focus": { + "strategic": false, + "operational": true, + "tactical": true + }, + "maturity": { + "0": "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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.\n▪ IT and/or cybersecurity personnel apply software patches through an informal process.", + "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.\n▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:\n(1) Reducing or removing public exposure to exploitation; and\n(2) Expediting patch deployment actions.", + "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." + }, + "profiles": [ + "Community Derived" + ], + "possible_solutions": { + "micro_small": "∙ Subscribe to CISA KEV catalog alerts (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)\n∙ Prioritize patching KEV-listed vulnerabilities within CISA timeframes", + "small": "∙ CISA KEV catalog subscription and monitoring\n∙ Priority patching for KEV-listed vulnerabilities within CISA-defined windows", + "medium": "∙ KEV-integrated vulnerability management program\n∙ CISA KEV catalog integration with vulnerability scanner\n∙ Accelerated remediation SLAs for KEV items", + "large": "∙ Enterprise vulnerability management with KEV prioritization\n∙ Automated KEV alerting and remediation tracking\n∙ Defined KEV remediation SLAs", + "enterprise": "∙ Enterprise KEV management program\n∙ Automated CISA KEV catalog integration\n∙ Real-time KEV exposure tracking and alerting\n∙ Risk-based KEV remediation with board-level visibility for material exposures" + }, + "risks": [ + "R-AC-1", + "R-AC-2", + "R-AC-3", + "R-AC-4", + "R-AM-1", + "R-AM-2", + "R-AM-3", + "R-BC-1", + "R-BC-2", + "R-BC-3", + "R-BC-4", + "R-BC-5", + "R-EX-1", + "R-EX-2", + "R-EX-3", + "R-EX-4", + "R-EX-5", + "R-EX-6", + "R-EX-7", + "R-GV-1", + "R-GV-2", + "R-GV-3", + "R-GV-4", + "R-GV-5", + "R-GV-6", + "R-GV-7", + "R-GV-8", + "R-IR-1", + "R-IR-2", + "R-IR-3", + "R-IR-4", + "R-SA-1", + "R-SC-1", + "R-SC-2", + "R-SC-3", + "R-SC-4", + "R-SC-5", + "R-SC-6" + ], + "threats": [ + "NT-2", + "NT-3", + "NT-4", + "NT-5", + "NT-6", + "NT-7", + "NT-8", + "NT-9", + "NT-10", + "NT-11", + "NT-12", + "NT-13", + "NT-14", + "MT-1", + "MT-2", + "MT-3", + "MT-4", + "MT-5", + "MT-6", + "MT-7", + "MT-8", + "MT-9", + "MT-11", + "MT-12", + "MT-13", + "MT-14", + "MT-15", + "MT-24", + "MT-25", + "MT-27", + "MT-28" + ], + "errata": "- new control - SCF community", + "family_name": "Vulnerability & Patch Management", + "crosswalks": {} + }, { "control_id": "VPM-03", "title": "Vulnerability Ranking", @@ -1382,9 +1494,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and assign a risk ranking to newly discovered security vulnerabilities using reputable outside sources for security vulnerability information. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1456,7 +1568,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -1482,6 +1595,9 @@ "general-nist-800-171-r3": [ "03.11.02.a" ], + "general-nist-800-171a-r3": [ + "A.03.11.02.a[01]" + ], "general-nist-csf-2-0": [ "ID.RA-08" ], @@ -1513,9 +1629,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.1" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-sparta": [ "CM0016" ], @@ -1535,6 +1648,9 @@ "usa-federal-sro-fca-crm-2023": [ "609.930(c)(2)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)" + ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.E.2.b" ], @@ -1545,29 +1661,25 @@ "500.5(c)" ], "emea-deu-c5-2020": [ - "OPS-18", - "OPS-22", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.8" + "RB-17-BP1", + "RB-19" ], "emea-sau-cscc-1-2019": [ "2-9-1-2" ], "emea-sau-ecc-1-2018": [ - "2-10-3-2" - ], - "emea-sau-otcc-1-2022": [ - "2-9-1-2", - "2-9-1-3" + "2-10-3-2", + "2-10-3-3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163" ], "apac-ind-sebi-2024": [ "PR.MA.S3" ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], "americas-can-osfi-b13-2022": [ "3.1.3" ], @@ -1594,7 +1706,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify, assess, prioritize and document the potential impact(s) and likelihood(s) of applicable internal and external threats exploiting known vulnerabilities.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1642,7 +1754,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -1668,6 +1781,10 @@ ], "usa-state-ny-dfs-23-nycrr500-2023-amd2": [ "500.5(c)" + ], + "emea-deu-c5-2020": [ + "RB-17-BP1", + "RB-19" ] } }, @@ -1692,11 +1809,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -1781,7 +1898,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -1789,7 +1907,7 @@ "CC4.2" ], "general-cis-csc-8-1": [ - "7.0", + "7", "7.7", "12.1", "18.3" @@ -1844,11 +1962,11 @@ ], "general-nist-800-171-r3": [ "03.11.02.b", - "03.14.01.a", - "03.14.01.b" + "03.14.01.a" ], "general-nist-800-171a-r3": [ - "A.03.11.02.b" + "A.03.11.02.b", + "A.03.14.01.a[03]" ], "general-owasp-top-10-2025": [ "A05:2025" @@ -1878,9 +1996,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-swift-cscf-2025": [ "2.2", "2.7" @@ -1933,48 +2048,32 @@ "Article 21.4" ], "emea-deu-c5-2020": [ - "OPS-18", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.6", - "22.11" + "RB-17-BP2", + "RB-19", + "RB-21" ], "emea-sau-cscc-1-2019": [ "2-9-1-3" ], - "emea-sau-ecc-1-2018": [ - "2-10-3-3" - ], - "emea-sau-otcc-1-2022": [ - "2-9-1-2", - "2-9-1-3" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1801" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-mys-bnm-rmit-2025": [ + "10.18" ], "apac-nzl-ism-3-9": [ "6.2.6.C.01", "23.2.19.C.01" ], - "apac-sgp-mas-trm-2021": [ - "13.6.1(a)", - "13.6.1(b)", - "13.6.1(c)" - ], - "amaericas-can-osfi-self-assessment": [ - "2.7" - ], "americas-can-osfi-b13-2022": [ "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", - "03.14.01.A", - "03.14.01.B" + "03.14.01.A" ] } }, @@ -1996,7 +2095,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to install the latest stable version of any software and/or security-related updates on all applicable systems.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -2066,7 +2165,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -2097,23 +2197,16 @@ "usa-state-vt-act-171-2018": [ "2447(c)(6)" ], - "emea-isr-cmo-1-0": [ - "12.22" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1467", "ISM-1483" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-nzl-hisf-microsmall-2023": [ "HHSP44", "HML44" ], - "apac-nzl-hisf-microsmall-2023": [ - "HMS08" - ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "americas-can-osfi-self-assessment-2": [ + "2.6.1" ] } }, @@ -2135,11 +2228,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify and correct flaws related to the collection, usage, processing or dissemination of Personal Data (PD).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -2193,17 +2286,11 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", - "crosswalks": { - "general-scf-dpmp-2025": [ - "5.15" - ], - "emea-zaf-popia-2013": [ - "4" - ] - } + "crosswalks": {} }, { "control_id": "VPM-04.3", @@ -2232,7 +2319,13 @@ "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" ], - "possible_solutions": {}, + "possible_solutions": { + "micro_small": "∙ Documented deferred patch register (spreadsheet)\n∙ Management sign-off for deferred patches with interim mitigations documented", + "small": "∙ Formal deferred patch register\n∙ Risk-based justification and management approval\n∙ Compensating control documentation", + "medium": "∙ Deferred patching exception process within vulnerability management program\n∙ Compensating control requirements for deferred patches\n∙ GRC platform for exception tracking", + "large": "∙ Enterprise deferred patch management process\n∙ Formal exception approval with compensating controls\n∙ GRC platform for tracking and reporting\n∙ Regular review of aged deferred patches", + "enterprise": "∙ Enterprise patch exception management program\n∙ Automated deferred patch tracking and escalation\n∙ Compensating control validation for all exceptions\n∙ Board-level reporting on material deferred patches" + }, "risks": [ "R-AC-1", "R-AC-2", @@ -2287,7 +2380,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -2302,6 +2396,9 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.2" + ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1" ] } }, @@ -2310,7 +2407,7 @@ "title": "Software & Firmware Patching", "family": "VPM", "description": "Mechanisms exist to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", - "scf_question": "Does the organization conduct software patching for all deployed systems, applications and firmware?", + "scf_question": "Does the organization conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware?", "relative_weight": 10, "conformity_cadence": "Quarterly", "evidence_requests": [ @@ -2326,11 +2423,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -2417,7 +2514,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -2486,7 +2584,7 @@ "general-iso-27018-2025": [ "8.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1003", "T1003.001", "T1027", @@ -2642,10 +2740,9 @@ ], "general-nist-800-171a-r3": [ "A.03.11.02.b", + "A.03.12.02.a.02", "A.03.14.01.ODP[01]", "A.03.14.01.ODP[02]", - "A.03.14.01.a[01]", - "A.03.14.01.a[02]", "A.03.14.01.a[03]", "A.03.14.01.b[01]", "A.03.14.01.b[02]" @@ -2677,9 +2774,6 @@ "general-pci-dss-4-0-1-saq-d-service-provider": [ "6.3.3" ], - "general-scf-dpmp-2025": [ - "5.15" - ], "general-shared-assessments-sig-2025": [ "N.4" ], @@ -2733,6 +2827,10 @@ "SI-02(04)", "SI-03" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.625(d)(15)", + "101.650(e)(3)(i)" + ], "usa-federal-irs-1075-2021": [ "SI-2", "SI-2(CE-4)", @@ -2776,10 +2874,7 @@ "6.6.1(a)" ], "emea-deu-c5-2020": [ - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "12.21" + "RB-17-BP2" ], "emea-sau-cscc-1-2019": [ "2-3-1-3" @@ -2798,11 +2893,14 @@ "2-4-1-15" ], "emea-sau-sacs-002-2022": [ - "TPC-11", - "TPC-78" + "VII.A.TPC-11" ], "emea-gbr-cyber-essentials-requirements-3-3": [ - "5" + "3", + "3-BP4", + "3-BP4-1", + "3-BP4-2", + "3-BP4-3" ], "emea-gbr-def-stan-05-138-2024": [ "2402", @@ -2828,7 +2926,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1143", "ISM-1493", "ISM-1690", @@ -2839,10 +2937,15 @@ "ISM-1695", "ISM-1696", "ISM-1697", - "ISM-1751" + "ISM-1751", + "ISM-1876", + "ISM-1877", + "ISM-1878", + "ISM-1879", + "ISM-1901" ], - "apac-aus-ps-cps-234-2019": [ - "21" + "apac-aus-cop-sitc-2020": [ + "3" ], "apac-ind-sebi-2024": [ "PR.MA.S3" @@ -2850,7 +2953,11 @@ "apac-jpn-ismap": [ "12.6.1.10" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "10.17", + "10.18" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP19", "HML19" ], @@ -2858,29 +2965,30 @@ "HSUP17" ], "apac-nzl-ism-3-9": [ + "22.1.18.C.01", "23.2.19.C.01" ], "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)", - "4.2(b)" + "4.2(a)" ], "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "7.4.1" + ], + "americas-arg-ppd-2018": [ + "E.1.2-7" ], "americas-bmu-mba-coc-2020": [ "6.16" ], - "amaericas-can-osfi-self-assessment": [ - "4.5", - "4.7", - "4.9" - ], "americas-can-osfi-b13-2022": [ "2.6", "2.6.1", "3.2.6" ], + "americas-can-osfi-self-assessment-2": [ + "2.6.1", + "3.2.6" + ], "americas-can-itsp-10-171-2025": [ "03.11.02.B", "03.12.02.A.02", @@ -2907,9 +3015,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to centrally-manage the flaw remediation process.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to centrally-manage the flaw remediation process. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -2994,7 +3102,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -3143,23 +3252,17 @@ "Article 21.4" ], "emea-deu-c5-2020": [ - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "12.21", - "22.11", - "22.12" - ], - "emea-sau-sacs-002-2022": [ - "TPC-91" + "RB-17-BP2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0298", "ISM-0300" ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" + "apac-mys-bnm-rmit-2025": [ + "10.19" + ], + "americas-can-osfi-self-assessment-2": [ + "3.2.6" ] } }, @@ -3181,9 +3284,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically determine the state of system components with regard to flaw remediation.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically determine the state of system components with regard to flaw remediation. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -3229,7 +3332,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -3306,10 +3410,6 @@ ], "usa-federal-cms-marse-2-0": [ "SI-2(2)" - ], - "emea-isr-cmo-1-0": [ - "22.11", - "22.12" ] } }, @@ -3331,11 +3431,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to track the effectiveness of remediation operations through metrics reporting.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -3385,7 +3485,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -3427,18 +3528,6 @@ ], "usa-federal-tsa-security-directive-1580-82-2022-01": [ "III.E.2.a" - ], - "emea-deu-c5-2020": [ - "OPS-19" - ], - "emea-isr-cmo-1-0": [ - "12.22" - ], - "emea-sau-sacs-002-2022": [ - "TPC-91" - ], - "apac-sgp-mas-trm-2021": [ - "13.6.1(b)" ] } }, @@ -3528,7 +3617,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -3581,6 +3671,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "SI-02(04)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(ii)" + ], "usa-federal-irs-1075-2021": [ "SI-2(CE-4)", "SI-2(CE-5)" @@ -3591,21 +3684,11 @@ "emea-sau-ecc-1-2018": [ "2-10-3-5" ], - "emea-sau-otcc-1-2022": [ - "2-3-1-3" - ], - "emea-sau-sacs-002-2022": [ - "TPC-78" + "emea-gbr-cyber-essentials-requirements-3-3": [ + "3-BP3" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1467" - ], - "apac-sgp-cyber-hygiene-practice-2019": [ - "4.2(a)" - ], - "apac-sgp-mas-trm-2021": [ - "7.4.1", - "7.4.2" ] } }, @@ -3629,9 +3712,9 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -3674,7 +3757,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -3714,7 +3798,7 @@ "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform due diligence on software and/or firmware update stability by conducting pre-production testing in a non-production environment.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -3778,7 +3862,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -3803,6 +3888,12 @@ ], "emea-gbr-def-stan-05-138-l3-2024": [ "2405" + ], + "apac-mys-bnm-rmit-2025": [ + "10.18" + ], + "apac-sgp-mas-trm-2021": [ + "7.4.2" ] } }, @@ -3824,11 +3915,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to perform out-of-cycle software and/or firmware updates to address time-sensitive remediations.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [], "possible_solutions": { @@ -3892,7 +3983,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -3996,7 +4088,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -4011,6 +4104,12 @@ ], "emea-eu-nis2-annex-2024": [ "6.6.1(c)" + ], + "emea-sau-otcc-1-2022": [ + "2-4-1-15" + ], + "apac-aus-cop-sitc-2020": [ + "3" ] } }, @@ -4039,7 +4138,7 @@ "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel configure technologies to update vulnerability scanning tools.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to detect vulnerabilities and configuration errors by routine vulnerability scanning of systems and applications.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "SCRMS", @@ -4105,7 +4204,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -4164,7 +4264,7 @@ "general-iso-27018-2025": [ "8.8" ], - "general-mitre-att&ck-16-1": [ + "general-mitre-att_ck-16-1": [ "T1011.001", "T1021.001", "T1021.003", @@ -4322,7 +4422,8 @@ "3.11.2" ], "general-nist-800-171-r3": [ - "03.11.02.a" + "03.11.02.a", + "03.14.01.a" ], "general-nist-800-171a": [ "3.11.2[a]", @@ -4339,8 +4440,8 @@ "A.03.11.02.a[02]", "A.03.11.02.a[03]", "A.03.11.02.a[04]", - "A.03.11.02.c[01]", - "A.03.11.02.c[02]" + "A.03.14.01.a[01]", + "A.03.14.01.a[02]" ], "general-nist-csf-2-0": [ "ID.RA-01" @@ -4427,6 +4528,9 @@ "usa-federal-gsa-fedramp-5-li-saas": [ "RA-05" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(3)(vi)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(2)", "314.4(d)(2)(ii)" @@ -4480,20 +4584,9 @@ "emea-eu-nis2-annex-2024": [ "6.10.2(b)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-22", - "PSS-02", - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "3.4", - "9.25", - "12.30", - "22.3", - "22.6" + "RB-17-BP1", + "RB-21" ], "emea-sau-cscc-1-2019": [ "2-9-1-1", @@ -4505,8 +4598,11 @@ "emea-sau-ecc-1-2018": [ "2-10-3-1" ], + "emea-sau-otcc-1-2022": [ + "2-9-1-3" + ], "emea-sau-sacs-002-2022": [ - "TPC-85" + "VII.B.TPC-85" ], "emea-uae-niaf-2023": [ "3.1.3" @@ -4531,7 +4627,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163", "ISM-1698", "ISM-1699", @@ -4539,12 +4635,17 @@ "ISM-1701", "ISM-1702", "ISM-1703", - "ISM-1752" + "ISM-1752", + "ISM-1875", + "ISM-1900" ], "apac-ind-sebi-2024": [ "ID.RA.S1" ], - "apac-nzl-hisf-mlhsp-2023": [ + "apac-mys-bnm-rmit-2025": [ + "11.9" + ], + "apac-nzl-hisf-microsmall-2023": [ "HHSP26", "HHSP59", "HML26", @@ -4557,21 +4658,18 @@ "6.2.5.C.01" ], "apac-sgp-mas-trm-2021": [ - "13.1.1", - "13.1.2" - ], - "americas-bmu-mba-coc-2020": [ - "6.15" - ], - "amaericas-can-osfi-self-assessment": [ - "2.5" + "13.1.1" ], "americas-can-osfi-b13-2022": [ "3.1.2", "3.1.3" ], + "americas-can-osfi-self-assessment-2": [ + "3.1.3" + ], "americas-can-itsp-10-171-2025": [ - "03.11.02.A" + "03.11.02.A", + "03.14.01.A" ] } }, @@ -4660,7 +4758,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -4811,11 +4910,8 @@ "emea-eu-nis2-annex-2024": [ "6.10.4" ], - "emea-deu-c5-2020": [ - "PSS-03" - ], - "emea-isr-cmo-1-0": [ - "22.7" + "emea-sau-sacs-002-2022": [ + "VII.B.TPC-78" ], "apac-aus-essential-8-2024": [ "ML1-P1", @@ -4825,7 +4921,7 @@ "ML3-P1", "ML3-P2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1808" ], "americas-can-itsp-10-171-2025": [ @@ -4853,7 +4949,7 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify the breadth and depth of coverage for vulnerability scanning that define the system components scanned and types of vulnerabilities that are checked for.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to identify the breadth and depth of coverage for vulnerability scanning that define the system components scanned and types of vulnerabilities that are checked for. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -4916,7 +5012,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -4990,14 +5087,8 @@ "usa-state-tx-txramp-2-0-level-2": [ "RA-05 (03)" ], - "emea-isr-cmo-1-0": [ - "22.6" - ], "emea-sau-cscc-1-2019": [ - "2-9-2-1" - ], - "emea-sau-ecc-1-2018": [ - "2-11-3-1" + "2-9-2" ] } }, @@ -5019,9 +5110,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement privileged access authorization for selected vulnerability scanning activities.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to implement privileged access authorization for selected vulnerability scanning activities. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5084,7 +5175,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -5150,9 +5242,6 @@ ], "usa-state-tx-txramp-2-0-level-2": [ "RA-05 (05)" - ], - "emea-isr-cmo-1-0": [ - "22.9" ] } }, @@ -5174,9 +5263,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically compare the results of vulnerability scans over time to determine trends in system vulnerabilities.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to automatically compare the results of vulnerability scans over time to determine trends in system vulnerabilities. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -5238,7 +5327,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -5274,12 +5364,6 @@ ], "general-swift-cscf-2025": [ "2.7" - ], - "emea-deu-c5-2020": [ - "OPS-20" - ], - "emea-isr-cmo-1-0": [ - "22.10" ] } }, @@ -5303,9 +5387,9 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to review historical event logs to determine if identified vulnerabilities have been previously exploited.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to review historical event logs to determine if identified vulnerabilities have been previously exploited. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -5366,7 +5450,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -5393,12 +5478,6 @@ ], "usa-federal-gsa-fedramp-5-high": [ "RA-05(08)" - ], - "emea-deu-c5-2020": [ - "OPS-20" - ], - "emea-isr-cmo-1-0": [ - "22.10" ] } }, @@ -5502,7 +5581,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -5546,11 +5626,8 @@ "11.3.2", "11.3.2.1" ], - "emea-deu-c5-2020": [ - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "22.3" + "emea-sau-cscc-1-2019": [ + "2-9-1-1" ] } }, @@ -5654,7 +5731,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -5686,11 +5764,11 @@ "11.3.1.2", "11.3.1.3" ], - "emea-deu-c5-2020": [ - "PSS-02" + "emea-sau-cscc-1-2019": [ + "2-9-1-1" ], - "emea-isr-cmo-1-0": [ - "22.3" + "americas-bmu-mba-coc-2020": [ + "6.15-BP3" ] } }, @@ -5712,7 +5790,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to define what information is allowed to be discoverable by adversaries and take corrective actions to remediate non-compliant Technology Assets, Applications and/or Services (TAAS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -5750,7 +5828,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -5778,6 +5857,12 @@ "general-nist-800-160-vol-2-r1": [ "RA-05(04)" ], + "general-nist-800-172-r3": [ + "03.11.11E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.11.11E[01]" + ], "general-pci-dss-4-0-1": [ "1.4.5" ], @@ -5798,6 +5883,9 @@ ], "apac-nzl-ism-3-9": [ "14.1.14.C.01" + ], + "americas-bmu-mba-coc-2020": [ + "6.15-BP4" ] } }, @@ -5854,7 +5942,8 @@ "MT-14", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -5899,7 +5988,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, conduct annual penetration testing on network segments hosting High Value Assets (HVAs).", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to conduct penetration testing on Technology Assets, Applications and/or Services (TAAS).", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -5983,12 +6072,13 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { "general-cis-csc-8-1": [ - "18.0", + "18", "18.1", "18.2", "18.5" @@ -6051,8 +6141,11 @@ "CA-08", "SA-11(05)" ], - "general-nist-800-172": [ - "3.12.1e" + "general-nist-800-172-r3": [ + "03.12.01E" + ], + "general-nist-800-172a-r3": [ + "DS-A.03.12.01E" ], "general-pci-dss-4-0-1": [ "11.4", @@ -6127,6 +6220,9 @@ "CA-08", "SA-11(05)" ], + "usa-federal-law-33-cfr-part-101-subpart-f": [ + "101.650(e)(2)" + ], "usa-federal-law-glba-cfr-314-2023": [ "314.4(d)(2)", "314.4(d)(2)(i)" @@ -6161,22 +6257,12 @@ "Article 26.8(b)", "Article 26.8(c)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-deu-c5-2020": [ - "OPS-19", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "3.4", - "12.30", - "17.17", - "22.4", - "22.5" + "RB-18", + "RB-18-DOAR" ], "emea-sau-cscc-1-2019": [ - "2-10", + "2-10-1", "2-10-1-1", "2-10-1-2", "2-10-2" @@ -6185,21 +6271,19 @@ "2-10-1" ], "emea-sau-ecc-1-2018": [ - "2-11-3-1" + "2-11-1", + "2-11-2", + "2-11-3-1", + "2-11-3-2" ], "emea-sau-otcc-1-2022": [ - "2-10", - "2-10-1", - "2-10-1-1", "2-10-1-2", - "2-10-1-3", - "2-10-1-4", - "2-10-2" + "2-10-1-3" ], "emea-sau-sacs-002-2022": [ - "TPC-27", - "TPC-28", - "TPC-29" + "VII.B.TPC-27", + "VII.B.TPC-28", + "VII.B.TPC-29" ], "emea-gbr-def-stan-05-138-2024": [ "2403" @@ -6213,19 +6297,19 @@ "emea-gbr-def-stan-05-138-l3-2024": [ "2403" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1163" ], + "apac-mys-bnm-rmit-2025": [ + "11.9" + ], "apac-sgp-mas-trm-2021": [ "13.2.1", "13.2.3", "13.2.4" ], "americas-bmu-mba-coc-2020": [ - "6.15" - ], - "amaericas-can-osfi-self-assessment": [ - "2.6" + "6.15-BP1" ], "americas-can-osfi-b13-2022": [ "3.1.2" @@ -6252,7 +6336,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, use red team exercises to simulate attempts by adversaries to compromise TAASD in accordance with entity-defined rules of engagement.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize an independent assessor or penetration team to perform penetration testing.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6330,7 +6414,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -6416,16 +6501,6 @@ "Article 27.2(c)", "Article 27.3" ], - "emea-deu-c5-2020": [ - "OPS-19", - "PSS-02" - ], - "emea-isr-cmo-1-0": [ - "17.16", - "17.17", - "22.4", - "22.5" - ], "emea-sau-cscc-1-2019": [ "2-10-1-2" ] @@ -6449,7 +6524,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize a technical surveillance countermeasures survey.", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -6501,7 +6576,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -6541,11 +6617,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nVulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", + "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to monitor logs associated with scanning activities and associated administrator accounts to ensure that those activities are limited to the timeframes of legitimate scans.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to monitor logs associated with scanning activities and associated administrator accounts to ensure that those activities are limited to the timeframes of legitimate scans. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies." }, "profiles": [ "CORE Mergers, Acquisitions & Divestitures (MA&D)" @@ -6588,7 +6664,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": {} @@ -6613,7 +6690,7 @@ "0": "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.", "1": "Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ 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.", "2": "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:\n▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.\n▪ 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).\n▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ 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.\n▪ IT and/or cybersecurity personnel, or contracted professionals, use red team exercises to simulate attempts by adversaries to compromise TAASD in accordance with entity-defined rules of engagement.", - "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize \"red team\" exercises to simulate attempts by adversaries to compromise Technology Assets, Applications and/or Services (TAAS) in accordance with organization-defined rules of engagement.", + "3": "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:\n▪ 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.\n▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.\n▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).\n▪ 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).\n▪ An implemented and operational capability exists to utilize \"red team\" exercises to simulate attempts by adversaries to compromise Technology Assets, Applications and/or Services (TAAS) in accordance with organization-defined rules of engagement. ", "4": "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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -6701,7 +6778,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Vulnerability & Patch Management", "crosswalks": { @@ -6740,21 +6818,17 @@ "usa-federal-gsa-fedramp-5-high": [ "CA-08(02)" ], - "emea-deu-bsrit-2017": [ - "5.6" - ], "emea-sau-cgiot-2024": [ "2-10-2" ], - "emea-sau-otcc-1-2022": [ - "2-13-1-9" - ], "apac-ind-sebi-2024": [ "DE.DP.S4" ], + "apac-mys-bnm-rmit-2025": [ + "11.6" + ], "apac-sgp-mas-trm-2021": [ - "13.3.1", - "13.3.2", + "8.5.1", "13.4.1", "13.4.2" ] diff --git a/docs/api/families/WEB.json b/docs/api/families/WEB.json index 9694c411..800bab24 100644 --- a/docs/api/families/WEB.json +++ b/docs/api/families/WEB.json @@ -102,7 +102,8 @@ "MT-23", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -116,6 +117,9 @@ "general-nist-800-171-r3": [ "03.01.22.a" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.a" + ], "general-pci-dss-4-0-1": [ "6.4", "6.4.1", @@ -146,15 +150,8 @@ "3.3.8", "3.3.8.c" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-sau-cscc-1-2019": [ - "2-12", + "2-12-1", "2-12-1-1", "2-12-1-2" ], @@ -162,16 +159,19 @@ "2-15-1", "2-15-2", "2-15-3", + "2-15-3-2", + "2-15-3-4", + "2-15-3-5", "2-15-4" ], - "emea-esp-ccn-stic-825-2023": [ - "8.8.2 [MP.S.2]" - ], "apac-nzl-ism-3-9": [ "14.5.6.C.01", "14.5.7.C.01", "14.5.8.C.01" ], + "apac-sgp-mas-trm-2021": [ + "14.1.1" + ], "americas-can-itsp-10-171-2025": [ "03.01.22.A" ] @@ -195,7 +195,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to prevent unauthorized code from being present in a secure page as it is rendered in a client’s browser.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -257,7 +257,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -296,7 +297,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to utilize a Demilitarized Zone (DMZ) to restrict inbound traffic to authorized Technology Assets, Applications and/or Services (TAAS) on certain services, protocols and ports.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -361,7 +362,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -407,19 +409,18 @@ "usa-federal-irs-1075-2021": [ "3.3.8.a" ], - "emea-aut-fappd-2000": [ - "Sec 14", - "Sec 15" - ], - "emea-bel-act-8-1992": [ - "16" - ], "emea-sau-otcc-1-2022": [ - "2-4-1-10", "2-4-1-13" ], "emea-sau-sacs-002-2022": [ - "TPC-41" + "VII.B.TPC-41" + ], + "emea-esp-ccn-stic-825-2026": [ + "op.ext.4", + "mp.com.4" + ], + "americas-bmu-mba-coc-2020": [ + "6.18" ] } }, @@ -441,9 +442,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", - "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy Web Application Firewalls (WAFs) to provide defense-in-depth protection for application-specific threats.", + "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy Web Application Firewalls (WAFs) to provide defense-in-depth protection for application-specific threats. ", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -487,13 +488,14 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ "4.4", - "13.1" + "13.10" ], "general-cis-csc-8-1-ig1": [ "4.4" @@ -503,7 +505,7 @@ ], "general-cis-csc-8-1-ig3": [ "4.4", - "13.1" + "13.10" ], "general-nist-800-53-r4": [ "SC-7(17)" @@ -538,11 +540,10 @@ "2-15-3-1" ], "emea-sau-sacs-002-2022": [ - "TPC-79" + "VII.B.TPC-79" ], - "amaericas-can-osfi-self-assessment": [ - "4.3", - "4.4" + "apac-aus-ism-2026-march": [ + "ISM-1862" ] } }, @@ -564,7 +565,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "Web Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to deploy reasonably-expected security, compliance and resilience controls to protect the confidentiality and availability of client data that is stored, transmitted or processed by the Internet-based service.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -621,9 +622,9 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], - "errata": "- wordsmithed", "family_name": "Web Security", "crosswalks": { "general-nist-800-171-r2": [ @@ -646,12 +647,17 @@ "52.204-21(b)(1)(iv)" ], "emea-sau-cscc-1-2019": [ - "2-12", - "2-12-1-1", - "2-12-1-2" + "2-12-1-1" ], - "emea-zaf-popia-2013": [ - "19" + "apac-sgp-mas-trm-2021": [ + "14.1.1", + "14.1.2", + "14.1.3", + "14.1.4", + "14.2.1", + "14.2.3", + "14.2.4", + "14.2.11" ] } }, @@ -673,7 +679,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to provide individuals with clear and precise information about cookies, in accordance with applicable legal requirements for cookie management.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", @@ -721,7 +727,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": {} @@ -744,11 +751,11 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.\n▪ 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 WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).\n▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).\n▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to implement Strong Customer Authentication (SCA) for consumers to reasonably prove their identity.", "4": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).\n▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).\n▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.\n▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).\n▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.\n▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.", - "5": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. \n▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions." + "5": "Web Security (WEB) 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:\n▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.\n▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. " }, "profiles": [ "CORE ESP Level 2 Critical Infrastructure", @@ -803,7 +810,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -828,14 +836,23 @@ "usa-state-tx-cdpa-2025": [ "541.055(a)(3)" ], - "emea-us-psd2-2015": [ - "4" - ], - "emea-deu-c5-2020": [ - "PSS-05" + "emea-eu-psd2-2015": [ + "97(1)", + "97(1)(a)", + "97(1)(b)", + "97(1)(c)", + "97(2)" ], "emea-sau-cscc-1-2019": [ "2-12-1-1" + ], + "apac-sgp-mas-trm-2021": [ + "14.2.1", + "14.2.5", + "14.2.6", + "14.2.7", + "14.2.8", + "14.2.9" ] } }, @@ -857,7 +874,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure the Open Web Application Security Project (OWASP) Application Security Verification Standard is incorporated into the organization's Secure Systems Development Lifecycle (SSDLC) process.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -912,27 +929,32 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ - "16.0", + "16", "16.1", - "16.7" + "16.7", + "16.10" ], "general-cis-csc-8-1-ig2": [ "16.1", - "16.7" + "16.7", + "16.10" ], "general-cis-csc-8-1-ig3": [ "16.1", - "16.7" + "16.7", + "16.10" ], "emea-sau-cscc-1-2019": [ - "2-12-1-2" + "2-12-1-2", + "2-12-2" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-0971", "ISM-1239" ], @@ -946,8 +968,8 @@ "control_id": "WEB-08", "title": "Web Application Framework", "family": "WEB", - "description": "Mechanisms exist to ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs.", - "scf_question": "Does the organization ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs?", + "description": "Mechanisms exist to use a robust Web Application Framework to support the development of secure web applications, including web services, web resources and web Application Programming Interfaces (APIs).", + "scf_question": "Does the organization use a robust Web Application Framework to support the development of secure web applications, including web services, web resources and web Application Programming Interfaces (APIs)?", "relative_weight": 9, "conformity_cadence": "Annual", "evidence_requests": [], @@ -960,7 +982,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure a robust Web Application Framework is used to aid in the development of secure web applications, including web services, web resources and web APIs.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -968,7 +990,6 @@ }, "profiles": [], "possible_solutions": { - "micro_small": "∙ Use a security-tested web framework", "small": "∙ Approved secure web framework policy\n∙ Use maintained frameworks only", "medium": "∙ Formal web application framework security requirements\n∙ Approved framework list", "large": "∙ Enterprise web framework governance program\n∙ Security-approved frameworks\n∙ Framework lifecycle management", @@ -1015,24 +1036,29 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], + "errata": "- wordsmithed control", "family_name": "Web Security", "crosswalks": { "general-cis-csc-8-1": [ - "16.0", - "16.1" + "16", + "16.1", + "16.10" ], "general-cis-csc-8-1-ig2": [ - "16.1" + "16.1", + "16.10" ], "general-cis-csc-8-1-ig3": [ - "16.1" + "16.1", + "16.10" ], "emea-sau-cscc-1-2019": [ "2-12-1-1" ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1239" ], "apac-nzl-ism-3-9": [ @@ -1059,7 +1085,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure all input handled by a web application is validated and/or sanitized.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1114,11 +1140,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1240" ] } @@ -1141,7 +1168,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure all web application content is delivered using cryptographic mechanisms (e.g., TLS).", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1198,7 +1225,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -1223,8 +1251,14 @@ "emea-sau-cscc-1-2019": [ "2-12-1-1" ], - "apac-aus-ism-2024-june": [ + "emea-sau-ecc-1-2018": [ + "2-15-3-3" + ], + "apac-aus-ism-2026-march": [ "ISM-1552" + ], + "apac-sgp-mas-trm-2021": [ + "14.2.2" ] } }, @@ -1246,7 +1280,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure output encoding is performed on all content produced by a web application to reduce the likelihood of cross-site scripting and other injection attacks.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1301,11 +1335,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1241" ] } @@ -1328,7 +1363,7 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to ensure web applications implement Content-Security-Policy, HSTS and X-Frame-Options response headers to protect both the web application and its users.", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", @@ -1383,14 +1418,12 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { - "emea-sau-cscc-1-2019": [ - "2-12-1-1" - ], - "apac-aus-ism-2024-june": [ + "apac-aus-ism-2026-march": [ "ISM-1424" ] } @@ -1399,8 +1432,8 @@ "control_id": "WEB-13", "title": "Website Change Detection", "family": "WEB", - "description": "Mechanisms exist to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data.", - "scf_question": "Does the organization detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data?", + "description": "Mechanisms exist to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive and/or regulated data.", + "scf_question": "Does the organization detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive and/or regulated data?", "relative_weight": 8, "conformity_cadence": "Semi-Annual", "evidence_requests": [], @@ -1413,9 +1446,9 @@ }, "maturity": { "0": "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.", - "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. \nWeb Security (WEB) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:\n▪ Policies, standards & procedures associated with WEB domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.\n▪ Web management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.", + "1": "SCR-CMM Level 1 criteria definitions are not available for this control:\n▪ A reasonable person would conclude this control requires a structured process.\n▪ 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. ", "2": "SCR-CMM Level 2 criteria definitions are not available for this control:\n▪ A reasonable person would conclude a well-defined and standardized process is required.\n▪ 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.\n▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).", - "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data.", + "3": "Web Security (WEB) 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:\n▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.\n▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.\n▪ A web management team, or simiE210:E1635main capabilities.\n▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway, Content Management System (CMS) solution, etc.).\n▪ 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 WEB 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).\n▪ An implemented and operational capability exists to detect and respond to Indicators of Compromise (IoC) for unauthorized alterations, additions, deletions or changes on websites that store, process and/or transmit sensitive/regulated data. ", "4": "Utilize SCR-CMM Level 3 criteria definitions:\n▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. \n▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.", "5": "Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:\n▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. \n▪ 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.\n▪ 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." }, @@ -1475,7 +1508,8 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { @@ -1501,8 +1535,8 @@ "control_id": "WEB-14", "title": "Publicly Accessible Content Reviews", "family": "WEB", - "description": "Mechanisms exist to routinely review the content on publicly accessible systems for sensitive/regulated data and remove such information, if discovered.", - "scf_question": "Does the organization routinely review the content on publicly accessible systems for sensitive/regulated data and remove such information, if discovered?", + "description": "Mechanisms exist to routinely review the content on publicly accessible systems for sensitive and/or regulated data and remove such information, if discovered.", + "scf_question": "Does the organization routinely review the content on publicly accessible systems for sensitive and/or regulated data and remove such information, if discovered?", "relative_weight": 7, "conformity_cadence": "Annual", "evidence_requests": [ @@ -1565,13 +1599,17 @@ "MT-15", "MT-24", "MT-25", - "MT-27" + "MT-27", + "MT-28" ], "family_name": "Web Security", "crosswalks": { "general-nist-800-171-r3": [ "03.01.22.b" ], + "general-nist-800-171a-r3": [ + "A.03.01.22.b[02]" + ], "emea-gbr-def-stan-05-138-2024": [ "2321" ], diff --git a/docs/api/summary.json b/docs/api/summary.json index 7449466c..67579788 100644 --- a/docs/api/summary.json +++ b/docs/api/summary.json @@ -1,17 +1,17 @@ { - "scf_version": "2026.1.1", - "total_controls": 1468, - "total_families": 33, + "scf_version": "2026.2", + "total_controls": 1534, + "total_families": 34, "families": [ { "family_code": "AAT", "family_name": "Artificial Intelligence & Autonomous Technologies", - "control_count": 156 + "control_count": 161 }, { "family_code": "AST", "family_name": "Asset Management", - "control_count": 63 + "control_count": 64 }, { "family_code": "BCD", @@ -26,7 +26,7 @@ { "family_code": "CFG", "family_name": "Configuration Management", - "control_count": 28 + "control_count": 32 }, { "family_code": "CHG", @@ -41,7 +41,7 @@ { "family_code": "CPL", "family_name": "Compliance", - "control_count": 40 + "control_count": 41 }, { "family_code": "CRY", @@ -65,8 +65,8 @@ }, { "family_code": "GOV", - "family_name": "Cybersecurity & Data Protection Governance", - "control_count": 38 + "family_name": "Security, Compliance & Resilience Governance", + "control_count": 42 }, { "family_code": "HRS", @@ -76,7 +76,7 @@ { "family_code": "IAC", "family_name": "Identification & Authentication", - "control_count": 114 + "control_count": 116 }, { "family_code": "IAO", @@ -106,7 +106,7 @@ { "family_code": "NET", "family_name": "Network Security", - "control_count": 98 + "control_count": 100 }, { "family_code": "OPS", @@ -121,37 +121,42 @@ { "family_code": "PRI", "family_name": "Data Privacy", - "control_count": 102 + "control_count": 103 }, { "family_code": "PRM", "family_name": "Project & Resource Management", "control_count": 11 }, + { + "family_code": "QTS", + "family_name": "Quantum Security", + "control_count": 34 + }, { "family_code": "RSK", "family_name": "Risk Management", - "control_count": 32 + "control_count": 33 }, { "family_code": "SAT", "family_name": "Security Awareness & Training", - "control_count": 17 + "control_count": 18 }, { "family_code": "SEA", "family_name": "Secure Engineering & Architecture", - "control_count": 44 + "control_count": 47 }, { "family_code": "TDA", "family_name": "Technology Development & Acquisition", - "control_count": 70 + "control_count": 74 }, { "family_code": "THR", "family_name": "Threat Management", - "control_count": 13 + "control_count": 15 }, { "family_code": "TPM", @@ -161,7 +166,7 @@ { "family_code": "VPM", "family_name": "Vulnerability & Patch Management", - "control_count": 33 + "control_count": 34 }, { "family_code": "WEB", @@ -170,503 +175,503 @@ } ], "crosswalk_frameworks": [ - { - "framework_id": "amaericas-can-osfi-self-assessment", - "display_name": "Canada - OSFI Cyber Security Self-Assessment Guidance", - "scf_controls_mapped": 141, - "framework_controls_mapped": 88 - }, { "framework_id": "americas-arg-ppd-2018", "display_name": "Argentina - Protection of Personal Data (2018)", - "scf_controls_mapped": 25, - "framework_controls_mapped": 50 + "scf_controls_mapped": 78, + "framework_controls_mapped": 89 }, { "framework_id": "americas-bhs-dpa-2003", - "display_name": "Bahamas - DPA (2003)", - "scf_controls_mapped": 18, - "framework_controls_mapped": 5 + "display_name": "Bahamas - Data Protection Act (DPA) (2003)", + "scf_controls_mapped": 40, + "framework_controls_mapped": 370 }, { "framework_id": "americas-bmu-mba-coc-2020", - "display_name": "Bermuda - Bermuda Monetary Authority Code of Conduct (2020)", - "scf_controls_mapped": 61, - "framework_controls_mapped": 37 + "display_name": "Bermuda - Bermuda Monetary Authority (BMA) Insurance Sector Operational Cyber Risk Management Code of Conduct (2020)", + "scf_controls_mapped": 97, + "framework_controls_mapped": 84 }, { "framework_id": "americas-bra-lgpd-2018", "display_name": "Brazil - General Data Protection Law (LGPD) (2018)", - "scf_controls_mapped": 33, - "framework_controls_mapped": 55 + "scf_controls_mapped": 29, + "framework_controls_mapped": 161 }, { "framework_id": "americas-can-itsp-10-171-2025", - "display_name": "Canada - ITSP.10.171 (2025)", - "scf_controls_mapped": 407, - "framework_controls_mapped": 275 + "display_name": "Canada - Protecting controlled information in non - Government of Canada systems and organizations (ITSP.10.171) (2025)", + "scf_controls_mapped": 415, + "framework_controls_mapped": 279 }, { "framework_id": "americas-can-osfi-b13-2022", - "display_name": "Canada - OSFI B-13 (2022)", + "display_name": "Canada - OSFI B - 13 (2022)", "scf_controls_mapped": 150, "framework_controls_mapped": 77 }, + { + "framework_id": "americas-can-osfi-self-assessment", + "display_name": "Canada - Office of the Superintendent of Financial Institutions Canada (OSFI) - Cyber Security Self - Assessment Guidance", + "scf_controls_mapped": 0, + "framework_controls_mapped": 0 + }, + { + "framework_id": "americas-can-osfi-self-assessment-2", + "display_name": "Canada - OSFI Cyber Security Self - Assessment Guidance", + "scf_controls_mapped": 125, + "framework_controls_mapped": 57 + }, { "framework_id": "americas-can-pipeda-2000", "display_name": "Canada - Personal Information Protection and Electronic Documents Act (PIPEDA) (2000)", - "scf_controls_mapped": 28, - "framework_controls_mapped": 17 + "scf_controls_mapped": 35, + "framework_controls_mapped": 68 }, { "framework_id": "americas-chl-act-19628-1999", - "display_name": "Chile - Act 19628 (1999)", - "scf_controls_mapped": 22, - "framework_controls_mapped": 10 + "display_name": "Chile - Act 19628 - Protection of Personal Data (1999)", + "scf_controls_mapped": 12, + "framework_controls_mapped": 15 }, { "framework_id": "americas-col-law-1581-2012", "display_name": "Colombia - Law 1581 (2012)", - "scf_controls_mapped": 29, - "framework_controls_mapped": 12 + "scf_controls_mapped": 21, + "framework_controls_mapped": 60 }, { "framework_id": "americas-mex-fdpa-2010", "display_name": "Mexico - Federal Law on Protection of Personal Data held by Private Parties (2010)", "scf_controls_mapped": 23, - "framework_controls_mapped": 25 + "framework_controls_mapped": 70 }, { "framework_id": "apac-aus-cop-sitc-2020", "display_name": "Australia - Code of Practice - Securing the Internet of Things for Consumers (2020)", - "scf_controls_mapped": 15, + "scf_controls_mapped": 35, "framework_controls_mapped": 13 }, { "framework_id": "apac-aus-essential-8-2024", - "display_name": "Australia - Essential Eight (2024)", + "display_name": "Australia - Essential Eight maturity model and ISM mapping (2024)", "scf_controls_mapped": 37, "framework_controls_mapped": 24 }, { - "framework_id": "apac-aus-ism-2024-june", - "display_name": "Australia - Information Security Manual (ISM) (June 2024)", - "scf_controls_mapped": 336, - "framework_controls_mapped": 802 - }, - { - "framework_id": "apac-aus-privacy-act-1998", - "display_name": "Australia - Privacy Act of 1998", - "scf_controls_mapped": 23, - "framework_controls_mapped": 12 + "framework_id": "apac-aus-ism-2026-march", + "display_name": "Australia - Information Security Manual (ISM) (March 2026)", + "scf_controls_mapped": 389, + "framework_controls_mapped": 1054 }, { "framework_id": "apac-aus-privacy-principles-2026", "display_name": "Australia - Privacy Principles (2026)", - "scf_controls_mapped": 26, - "framework_controls_mapped": 13 + "scf_controls_mapped": 24, + "framework_controls_mapped": 205 }, { "framework_id": "apac-aus-ps-cps-230-2023", - "display_name": "Australia - Prudential Standard CPS 230 (2023)", - "scf_controls_mapped": 41, - "framework_controls_mapped": 98 + "display_name": "Australia - Prudential Standard CPS 230 - Operational Risk Management (2023)", + "scf_controls_mapped": 69, + "framework_controls_mapped": 97 }, { "framework_id": "apac-aus-ps-cps-234-2019", - "display_name": "Australia - Prudential Standard CPS 234 (2019)", - "scf_controls_mapped": 52, - "framework_controls_mapped": 38 + "display_name": "Australia - Prudential Standard CPS 234 Information Security (2019)", + "scf_controls_mapped": 23, + "framework_controls_mapped": 37 }, { "framework_id": "apac-chn-csnip-2012", "display_name": "China - Decision on Strengthening Network Information Protection (2012)", - "scf_controls_mapped": 10, - "framework_controls_mapped": 4 + "scf_controls_mapped": 7, + "framework_controls_mapped": 7 }, { "framework_id": "apac-chn-cybersecurity-law-2017", - "display_name": "China - Cybersecurity Law (2017)", + "display_name": "China - Cybersecurity Law of the People's Republic of China (2017)", "scf_controls_mapped": 27, "framework_controls_mapped": 34 }, { "framework_id": "apac-chn-data-security-law-2021", - "display_name": "China - Data Security Law (2021)", - "scf_controls_mapped": 15, - "framework_controls_mapped": 24 + "display_name": "China - Data Security Law of the People's Republic of China (2021)", + "scf_controls_mapped": 10, + "framework_controls_mapped": 7 }, { "framework_id": "apac-chn-pipl-2021", - "display_name": "China - Personal Information Protection Law (2021)", - "scf_controls_mapped": 79, - "framework_controls_mapped": 100 + "display_name": "China - Personal Information Protection Law of the People's Republic of China (2021)", + "scf_controls_mapped": 37, + "framework_controls_mapped": 43 }, { "framework_id": "apac-hkg-pdo-2022", "display_name": "Hong Kong - Personal Data Ordinance (2022)", - "scf_controls_mapped": 14, - "framework_controls_mapped": 14 + "scf_controls_mapped": 18, + "framework_controls_mapped": 256 }, { "framework_id": "apac-ind-dpdpa-2023", - "display_name": "India - DPDPA (2023)", + "display_name": "India Digital Personal Data Protection Act (2023)", "scf_controls_mapped": 41, "framework_controls_mapped": 96 }, { "framework_id": "apac-ind-privacy-rules-2011", - "display_name": "India - Privacy Rules (2011)", - "scf_controls_mapped": 12, - "framework_controls_mapped": 5 + "display_name": "India - Information Technology Rules (Privacy Rules) (2011)", + "scf_controls_mapped": 13, + "framework_controls_mapped": 31 }, { "framework_id": "apac-ind-sebi-2024", - "display_name": "India - SEBI CSCRF (2024)", + "display_name": "India - SEBI Cybersecurity and Cyber Resilience Framework (2024)", "scf_controls_mapped": 170, "framework_controls_mapped": 129 }, + { + "framework_id": "apac-jpn-appi-2020", + "display_name": "Japan - Act on the Protection of Personal Information (2020)", + "scf_controls_mapped": 34, + "framework_controls_mapped": 106 + }, { "framework_id": "apac-jpn-ismap", "display_name": "Japan - Information System Security Management and Assessment Program (ISMAP)", "scf_controls_mapped": 249, - "framework_controls_mapped": 1312 - }, - { - "framework_id": "apac-jpn-ppi-2020", - "display_name": "Japan - Act on the Protection of Personal Information (2020)", - "scf_controls_mapped": 58, - "framework_controls_mapped": 134 + "framework_controls_mapped": 1313 }, { "framework_id": "apac-kor-pipa-2011", "display_name": "South Korea - Personal Information Protection Act (PIPA) (2011)", - "scf_controls_mapped": 37, - "framework_controls_mapped": 22 + "scf_controls_mapped": 24, + "framework_controls_mapped": 150 + }, + { + "framework_id": "apac-mys-bnm-rmit-2025", + "display_name": "Malaysia - Risk Management in Technology (RMiT) (2025)", + "scf_controls_mapped": 197, + "framework_controls_mapped": 107 }, { "framework_id": "apac-mys-pdpa-2010", "display_name": "Malaysia - Personal Data Protection Act (PDPA) (2010)", - "scf_controls_mapped": 25, - "framework_controls_mapped": 12 + "scf_controls_mapped": 19, + "framework_controls_mapped": 213 }, { "framework_id": "apac-nzl-hisf-microsmall-2023", "display_name": "New Zealand - HISF MicroSmall (2023)", - "scf_controls_mapped": 32, - "framework_controls_mapped": 21 + "scf_controls_mapped": 102, + "framework_controls_mapped": 150 }, { "framework_id": "apac-nzl-hisf-mlhsp-2023", "display_name": "New Zealand - HISF MLHSP (2023)", - "scf_controls_mapped": 102, - "framework_controls_mapped": 150 + "scf_controls_mapped": 0, + "framework_controls_mapped": 0 }, { "framework_id": "apac-nzl-hisf-suppliers-2023", - "display_name": "New Zealand - HISF Guidance for Suppliers (2023)", + "display_name": "New Zealand - HISO 10029:2024 NZ Health Information Security Framework Guidance for Suppliers", "scf_controls_mapped": 101, "framework_controls_mapped": 68 }, { "framework_id": "apac-nzl-ism-3-9", - "display_name": "New Zealand - Information Security Manual (ISM) (v3.9)", - "scf_controls_mapped": 291, - "framework_controls_mapped": 1392 + "display_name": "New Zealand - Information Security Manual (ISM) v3.9", + "scf_controls_mapped": 289, + "framework_controls_mapped": 1383 }, { "framework_id": "apac-nzl-privacy-act-2020", "display_name": "New Zealand - Privacy Act (2020)", "scf_controls_mapped": 20, - "framework_controls_mapped": 121 + "framework_controls_mapped": 160 }, { "framework_id": "apac-phl-dpa-2012", "display_name": "Philippines - Data Privacy Act (DPA) (2012)", - "scf_controls_mapped": 30, - "framework_controls_mapped": 16 + "scf_controls_mapped": 16, + "framework_controls_mapped": 61 }, { "framework_id": "apac-sgp-cyber-hygiene-practice-2019", "display_name": "Singapore - Cyber Hygiene Practice (2019)", - "scf_controls_mapped": 21, - "framework_controls_mapped": 13 + "scf_controls_mapped": 17, + "framework_controls_mapped": 11 }, { "framework_id": "apac-sgp-mas-trm-2021", "display_name": "Singapore - Monitory Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines (2021)", - "scf_controls_mapped": 214, - "framework_controls_mapped": 280 + "scf_controls_mapped": 219, + "framework_controls_mapped": 279 }, { "framework_id": "apac-sgp-pdpa-2012", "display_name": "Singapore - Personal Data Protection Ac (PDPA) (2012)", - "scf_controls_mapped": 30, - "framework_controls_mapped": 14 + "scf_controls_mapped": 33, + "framework_controls_mapped": 115 }, { "framework_id": "apac-twn-pdpa-2025", "display_name": "Taiwan - Personal Data Protection Act (PDPA) (2025)", - "scf_controls_mapped": 23, - "framework_controls_mapped": 8 + "scf_controls_mapped": 9, + "framework_controls_mapped": 61 }, { - "framework_id": "emea-aut-fappd-2000", - "display_name": "Austria - Federal Act concerning the Protection of Personal Data (2000)", - "scf_controls_mapped": 63, - "framework_controls_mapped": 12 + "framework_id": "emea-aut-dpa-2018", + "display_name": "Austria - Data Protection Act (2018)", + "scf_controls_mapped": 28, + "framework_controls_mapped": 93 }, { - "framework_id": "emea-bel-act-8-1992", - "display_name": "Belgium - Act of 8 December 1992", - "scf_controls_mapped": 59, - "framework_controls_mapped": 10 + "framework_id": "emea-bel-act-30-2018", + "display_name": "Belgium - Act of 30 July 2018", + "scf_controls_mapped": 27, + "framework_controls_mapped": 105 }, { "framework_id": "emea-che-fadp-2025", - "display_name": "Switzerland - FADP", - "scf_controls_mapped": 16, - "framework_controls_mapped": 9 + "display_name": "Switzerland - Federal Act on Data Protection (FADP) (2025)", + "scf_controls_mapped": 25, + "framework_controls_mapped": 104 }, { "framework_id": "emea-deu-bsrit-2017", "display_name": "Germany - Banking Supervisory Requirements for IT (2017)", "scf_controls_mapped": 91, - "framework_controls_mapped": 93 + "framework_controls_mapped": 88 }, { "framework_id": "emea-deu-c5-2020", "display_name": "Germany - Cloud Computing Compliance Controls Catalogue (C5) (2020)", - "scf_controls_mapped": 239, - "framework_controls_mapped": 121 + "scf_controls_mapped": 207, + "framework_controls_mapped": 282 }, { "framework_id": "emea-deu-fdpa-2017", "display_name": "Germany - Federal Data Protection Act (2017)", - "scf_controls_mapped": 18, - "framework_controls_mapped": 20 - }, - { - "framework_id": "emea-esp-boe-a-2022-7191", - "display_name": "Spain - BOE-A-2022-7191", - "scf_controls_mapped": 72, - "framework_controls_mapped": 132 - }, - { - "framework_id": "emea-esp-ccn-stic-825-2023", - "display_name": "Spain - ICT Security Guide CCN-STIC 825 (2023)", - "scf_controls_mapped": 99, - "framework_controls_mapped": 75 + "scf_controls_mapped": 46, + "framework_controls_mapped": 255 }, { - "framework_id": "emea-esp-decree-1720-2007", - "display_name": "Spain - Royal Decree 1720/2007", - "scf_controls_mapped": 17, - "framework_controls_mapped": 16 + "framework_id": "emea-esp-ccn-stic-825-2026", + "display_name": "Spain - ICT Security Guide CCN - STIC 825 (2026)", + "scf_controls_mapped": 234, + "framework_controls_mapped": 70 }, { "framework_id": "emea-esp-decree-311-2022", "display_name": "Spain - Royal Decree 311/2022", - "scf_controls_mapped": 73, - "framework_controls_mapped": 128 + "scf_controls_mapped": 72, + "framework_controls_mapped": 104 }, { "framework_id": "emea-eu-ai-act-2024", - "display_name": "EU Artificial Intelligence Act (AI Act) (2024)", + "display_name": "EU - European Union Artificial Intelligence Act (Regulation (EU) 2024/1689)", "scf_controls_mapped": 119, "framework_controls_mapped": 279 }, { - "framework_id": "emea-eu-cyber-resilience-act-2022", - "display_name": "EU Cyber Resilience Act (CRA) (2022)", - "scf_controls_mapped": 18, - "framework_controls_mapped": 52 + "framework_id": "emea-eu-cyber-resilience-act-2024", + "display_name": "EU - European Union Cyber Resilience Act (2024)", + "scf_controls_mapped": 35, + "framework_controls_mapped": 96 }, { - "framework_id": "emea-eu-cyber-resilience-act-annexes-2022", - "display_name": "EU Cyber Resilience Act Annexes (CRA Annexes) (2022)", - "scf_controls_mapped": 23, - "framework_controls_mapped": 117 + "framework_id": "emea-eu-cyber-resilience-act-annex-i-2024", + "display_name": "EU - European Union Cyber Resilience Act - Annex I (2024)", + "scf_controls_mapped": 16, + "framework_controls_mapped": 24 }, { "framework_id": "emea-eu-dora-2023", - "display_name": "EU Digital Operational Resilience Act (DORA) (2023)", + "display_name": "EU - Digital Operational Resilience Act (2023)", "scf_controls_mapped": 102, "framework_controls_mapped": 241 }, { "framework_id": "emea-eu-eba-ict-srm-2025", - "display_name": "EU EBA Guidelines on ICT and Security Risk Management (2025)", - "scf_controls_mapped": 148, - "framework_controls_mapped": 150 + "display_name": "EU - European Banking Authority Guidelines on ICT and Security Risk Management (2025)", + "scf_controls_mapped": 153, + "framework_controls_mapped": 156 }, { "framework_id": "emea-eu-gdpr-2016", - "display_name": "EU General Data Protection Regulation (GDPR) (2016)", + "display_name": "EU - European Union General Data Protection Regulation (2016)", "scf_controls_mapped": 42, "framework_controls_mapped": 227 }, { "framework_id": "emea-eu-nis2-2022", - "display_name": "EU NIS2 Directive (2022)", + "display_name": "EU - European Union Agency for Cybersecurity NIS2 Directive (EU) 2022/2555)", "scf_controls_mapped": 68, "framework_controls_mapped": 30 }, { "framework_id": "emea-eu-nis2-annex-2024", - "display_name": "EU NIS2 Annex (2024)", + "display_name": "EU - European Union Agency for Cybersecurity NIS2 Annex (2024)", "scf_controls_mapped": 223, "framework_controls_mapped": 351 }, + { + "framework_id": "emea-eu-psd2-2015", + "display_name": "EU - Second Payment Services Directive (PSD2) (2015)", + "scf_controls_mapped": 11, + "framework_controls_mapped": 22 + }, { "framework_id": "emea-gbr-caf-4-0", - "display_name": "UK - Cyber Assessment Framework (CAF) (v4.0)", + "display_name": "UK - Cyber Assessment Framework (CAF) v4.0", "scf_controls_mapped": 66, "framework_controls_mapped": 66 }, { "framework_id": "emea-gbr-cap-1850-2020", "display_name": "UK - Cyber Assessment Framework for Aviation Guidance (CAP1850) (2020)", - "scf_controls_mapped": 43, + "scf_controls_mapped": 36, "framework_controls_mapped": 14 }, { "framework_id": "emea-gbr-cyber-essentials-requirements-3-3", - "display_name": "UK - Cyber Essentials (v3.3)", - "scf_controls_mapped": 26, - "framework_controls_mapped": 5 + "display_name": "UK - Cyber Essentials: Requirements for IT Infrastructure v3.3", + "scf_controls_mapped": 27, + "framework_controls_mapped": 32 }, { "framework_id": "emea-gbr-def-stan-05-138-2024", - "display_name": "UK - Defstan 05-138 (2024)", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024)", "scf_controls_mapped": 213, "framework_controls_mapped": 147 }, { "framework_id": "emea-gbr-def-stan-05-138-l0-2024", - "display_name": "UK - Defstan 05-138 (2024) - L0", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L0", "scf_controls_mapped": 2, "framework_controls_mapped": 3 }, { "framework_id": "emea-gbr-def-stan-05-138-l1-2024", - "display_name": "UK - Defstan 05-138 (2024) - L1", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L1", "scf_controls_mapped": 159, "framework_controls_mapped": 100 }, { "framework_id": "emea-gbr-def-stan-05-138-l2-2024", - "display_name": "UK - Defstan 05-138 (2024) - L2", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L2", "scf_controls_mapped": 206, "framework_controls_mapped": 138 }, { "framework_id": "emea-gbr-def-stan-05-138-l3-2024", - "display_name": "UK - Defstan 05-138 (2024) - L3", + "display_name": "UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L3", "scf_controls_mapped": 212, "framework_controls_mapped": 143 }, { - "framework_id": "emea-gbr-dpa-1998", - "display_name": "UK - Data Protection Act (DPA) (1998)", - "scf_controls_mapped": 10, - "framework_controls_mapped": 8 + "framework_id": "emea-gbr-dpa-2018", + "display_name": "UK - Data Protection Act (DPA) (2018)", + "scf_controls_mapped": 25, + "framework_controls_mapped": 348 }, { "framework_id": "emea-grc-pirppd-1997", - "display_name": "Greece - Protection of Individuals with Regard to the Processing of Personal Data (1997)", - "scf_controls_mapped": 17, - "framework_controls_mapped": 11 + "display_name": "Greece - Protection of Individuals with Regard to the Processing of Personal Data (2472/1997)", + "scf_controls_mapped": 26, + "framework_controls_mapped": 73 }, { - "framework_id": "emea-hun-isdfi-2011", - "display_name": "Hungary - Informational Self-Determination and Freedom of Information (2011)", - "scf_controls_mapped": 27, - "framework_controls_mapped": 15 + "framework_id": "emea-hun-act-cxii-2011", + "display_name": "Hungary - Act CXII of 2011", + "scf_controls_mapped": 35, + "framework_controls_mapped": 100 }, { - "framework_id": "emea-irl-dpa-2003", - "display_name": "Ireland - Data Protection Act (DPA) (2003)", - "scf_controls_mapped": 25, - "framework_controls_mapped": 4 + "framework_id": "emea-irl-dpa-2018", + "display_name": "Ireland - Data Protection Act (DPA) (2018)", + "scf_controls_mapped": 17, + "framework_controls_mapped": 46 }, { - "framework_id": "emea-isr-cmo-1-0", - "display_name": "Israel - Cybersecurity Methodology for an Organization v1.0", - "scf_controls_mapped": 393, - "framework_controls_mapped": 323 + "framework_id": "emea-isr-cmo-2-0", + "display_name": "Ireland - Cybersecurity Methodology for an Organization (CMO) v2.0", + "scf_controls_mapped": 67, + "framework_controls_mapped": 48 }, { - "framework_id": "emea-isr-ppl-5741-1981", - "display_name": "Israel - Protection of Privacy Law, 5741 (1981)", - "scf_controls_mapped": 22, - "framework_controls_mapped": 8 + "framework_id": "emea-isr-ppl-5741-2025", + "display_name": "Israel - Protection of Privacy Law, 5741 (2025)", + "scf_controls_mapped": 13, + "framework_controls_mapped": 18 }, { - "framework_id": "emea-ita-pdpc-2003", - "display_name": "Italy - Personal Data Protection Code (2003)", - "scf_controls_mapped": 28, - "framework_controls_mapped": 18 + "framework_id": "emea-ita-pdpc-2018", + "display_name": "Italy - Personal Data Protection Code (2018)", + "scf_controls_mapped": 13, + "framework_controls_mapped": 45 }, { "framework_id": "emea-ken-pda-2019", "display_name": "Kenya - Data Protection Act (DPA) (2019)", - "scf_controls_mapped": 41, - "framework_controls_mapped": 237 + "scf_controls_mapped": 42, + "framework_controls_mapped": 196 }, { "framework_id": "emea-nga-dpr-2019", "display_name": "Nigeria - Data Protection Regulation (DPR) (2019)", - "scf_controls_mapped": 25, - "framework_controls_mapped": 107 + "scf_controls_mapped": 32, + "framework_controls_mapped": 111 }, { "framework_id": "emea-nor-pda-2018", "display_name": "Norway - Personal Data Act (PDA) (2018)", - "scf_controls_mapped": 23, - "framework_controls_mapped": 15 + "scf_controls_mapped": 4, + "framework_controls_mapped": 9 }, { - "framework_id": "emea-pol-act-29-1997", - "display_name": "Poland - Act of 29 August 1997 on the Protection of Personal Data", - "scf_controls_mapped": 29, - "framework_controls_mapped": 12 + "framework_id": "emea-pol-act-10-2018", + "display_name": "Poland - Act of 10 May 2018 on the Protection of Personal Data", + "scf_controls_mapped": 2, + "framework_controls_mapped": 3 }, { "framework_id": "emea-qat-pdppl-2020", "display_name": "Qatar - Personal Data Privacy Protection Law (PDPPL) (2020)", - "scf_controls_mapped": 56, - "framework_controls_mapped": 46 + "scf_controls_mapped": 33, + "framework_controls_mapped": 40 }, { - "framework_id": "emea-rus-federal-law-27-2006", - "display_name": "Russia - Federal Law of 27 (2006)", - "scf_controls_mapped": 28, - "framework_controls_mapped": 15 + "framework_id": "emea-rus-152-fz-2025", + "display_name": "Russia - Federal Law No. 152 - FZ (2025)", + "scf_controls_mapped": 17, + "framework_controls_mapped": 21 }, { "framework_id": "emea-sau-cgiot-2024", - "display_name": "Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT-1:2024)", + "display_name": "Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT - 1:2024)", "scf_controls_mapped": 118, "framework_controls_mapped": 81 }, { "framework_id": "emea-sau-cscc-1-2019", "display_name": "Saudi Arabia - Critical Systems Cybersecurity Controls (CSCC – 1: 2019)", - "scf_controls_mapped": 152, - "framework_controls_mapped": 107 + "scf_controls_mapped": 172, + "framework_controls_mapped": 104 }, { "framework_id": "emea-sau-ecc-1-2018", "display_name": "Saudi Arabia - Essential Cybersecurity Controls (ECC – 1 : 2018)", - "scf_controls_mapped": 190, - "framework_controls_mapped": 215 + "scf_controls_mapped": 169, + "framework_controls_mapped": 199 }, { "framework_id": "emea-sau-otcc-1-2022", - "display_name": "Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC -1: 2022)", - "scf_controls_mapped": 198, - "framework_controls_mapped": 189 + "display_name": "Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC - 1: 2022)", + "scf_controls_mapped": 160, + "framework_controls_mapped": 168 }, { "framework_id": "emea-sau-pdpl-2023", @@ -676,27 +681,27 @@ }, { "framework_id": "emea-sau-sacs-002-2022", - "display_name": "Saudi Arabia - SACS-002 Third Party Cybersecurity Standard (2022)", - "scf_controls_mapped": 185, - "framework_controls_mapped": 92 + "display_name": "Saudi Arabia - SACS - 002 Third Party Cybersecurity Standard (2022)", + "scf_controls_mapped": 101, + "framework_controls_mapped": 124 }, { "framework_id": "emea-sau-sama-csf-1-2017", - "display_name": "Saudi Arabia - SAMA CSF Version 1.0 (2017)", - "scf_controls_mapped": 50, - "framework_controls_mapped": 36 + "display_name": "Saudi Arabia - Saudi Arabian Monetary Authority (SAMA) Cyber Security Framework Version 1.0 (2017)", + "scf_controls_mapped": 91, + "framework_controls_mapped": 482 }, { "framework_id": "emea-srb-act-9-2018", - "display_name": "Serbia - Act of 9 November 2018 on Personal Data Protection", - "scf_controls_mapped": 56, - "framework_controls_mapped": 205 + "display_name": "Serbia - Act of 9 November 2018 on Personal Data Protection (Official Gazette No. 87/18)", + "scf_controls_mapped": 31, + "framework_controls_mapped": 330 }, { "framework_id": "emea-tur-lppd-2016", "display_name": "Turkey - Law on the Protection of Personal Data (LPPD) (2016)", - "scf_controls_mapped": 17, - "framework_controls_mapped": 10 + "scf_controls_mapped": 7, + "framework_controls_mapped": 103 }, { "framework_id": "emea-uae-niaf-2023", @@ -704,65 +709,59 @@ "scf_controls_mapped": 20, "framework_controls_mapped": 15 }, - { - "framework_id": "emea-us-psd2-2015", - "display_name": "EU Second Payment Services Directive (PSD2) (2015)", - "scf_controls_mapped": 30, - "framework_controls_mapped": 10 - }, { "framework_id": "emea-zaf-popia-2013", "display_name": "South Africa - Protection of Personal Information Act (POPIA) (2013)", - "scf_controls_mapped": 101, - "framework_controls_mapped": 41 + "scf_controls_mapped": 23, + "framework_controls_mapped": 242 }, { "framework_id": "general-aicpa-pmf-2020", - "display_name": "AICPA Privacy Management Framework (PMF) (2020)", + "display_name": "American Institute of Certified Public Accountants (AICPA) Privacy Management Framework (PMF) (2020)", "scf_controls_mapped": 109, "framework_controls_mapped": 123 }, { "framework_id": "general-aicpa-tsc-2017", - "display_name": "Trust Services Criteria (TSC) (2017)", + "display_name": "American Institute of Certified Public Accountants (AICPA) Trust Services Criteria (2017)", "scf_controls_mapped": 412, "framework_controls_mapped": 399 }, { "framework_id": "general-apec-privacy-framework-2015", - "display_name": "APEC Privacy Framework (2015)", + "display_name": "Asia - Pacific Economic Cooperation (APEC) Privacy Framework (2015)", "scf_controls_mapped": 14, "framework_controls_mapped": 25 }, { "framework_id": "general-bsi-200-1-1-0", - "display_name": "Standard 200-1 (v1.0)", + "display_name": "Bundesamt für Sicherheit in der Informationstechnik (BSI) - Standard 200 - 1 (v1.0)", "scf_controls_mapped": 35, "framework_controls_mapped": 22 }, { "framework_id": "general-cis-csc-8-1", - "display_name": "Critical Security Controls (CSC) (v8.1)", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1", "scf_controls_mapped": 234, - "framework_controls_mapped": 166 + "framework_controls_mapped": 171 }, { "framework_id": "general-cis-csc-8-1-ig1", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG1", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG1", "scf_controls_mapped": 104, "framework_controls_mapped": 56 }, { "framework_id": "general-cis-csc-8-1-ig2", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG2", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG2", "scf_controls_mapped": 208, - "framework_controls_mapped": 126 + "framework_controls_mapped": 130 }, { "framework_id": "general-cis-csc-8-1-ig3", - "display_name": "Critical Security Controls (CSC) (v8.1) - IG3", + "display_name": "Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG3", "scf_controls_mapped": 230, - "framework_controls_mapped": 148 + "framework_controls_mapped": 153 }, { "framework_id": "general-cobit-2019", @@ -778,85 +777,85 @@ }, { "framework_id": "general-cr-cmm-2026", - "display_name": "Cyber Resilience Capability Maturity Model (CR-CMM) (2026)", + "display_name": "Cyber Resilience Capability Maturity Model (CR - CMM) (2026)", "scf_controls_mapped": 46, "framework_controls_mapped": 40 }, { "framework_id": "general-csa-cmm-4-1-0", - "display_name": "Cloud Controls Matrix (CCM) (v4.1.0)", + "display_name": "Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) v4.1.0", "scf_controls_mapped": 291, "framework_controls_mapped": 207 }, { "framework_id": "general-csa-iot-2", - "display_name": "IoT Security Controls Framework (v2)", + "display_name": "Cloud Security Alliance (CSA) Internet of Things Security Controls Framework v2", "scf_controls_mapped": 253, "framework_controls_mapped": 155 }, { "framework_id": "general-govramp", - "display_name": "GovRAMP", + "display_name": "Government Risk and Authorization Management Program (GovRAMP)", "scf_controls_mapped": 441, "framework_controls_mapped": 383 }, { "framework_id": "general-govramp-core", - "display_name": "GovRAMP Core", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Core Controls", "scf_controls_mapped": 86, "framework_controls_mapped": 60 }, { "framework_id": "general-govramp-high", - "display_name": "GovRAMP High", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - High", "scf_controls_mapped": 441, "framework_controls_mapped": 383 }, { "framework_id": "general-govramp-low", - "display_name": "GovRAMP Low", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Low", "scf_controls_mapped": 166, "framework_controls_mapped": 114 }, { "framework_id": "general-govramp-low-plus", - "display_name": "GovRAMP Low+", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Low+", "scf_controls_mapped": 230, "framework_controls_mapped": 173 }, { "framework_id": "general-govramp-mod", - "display_name": "GovRAMP Moderate", + "display_name": "Government Risk and Authorization Management Program (GovRAMP) - Moderate", "scf_controls_mapped": 347, "framework_controls_mapped": 290 }, { "framework_id": "general-iec-62443-2-1-2024", - "display_name": "IEC 62443-2-1 (2024)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 2 - 1:2024 - Security for industrial automation and control systems - Part 2 - 1: Security program requirements for IACS asset owners", "scf_controls_mapped": 112, "framework_controls_mapped": 119 }, { "framework_id": "general-iec-62443-3-3-2013", - "display_name": "IEC 62443-3-3 (2013)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 3 - 3:2013 - Industrial communication networks - Network and system security - Part 3 - 3: System security requirements and security levels", "scf_controls_mapped": 80, "framework_controls_mapped": 111 }, { "framework_id": "general-iec-62443-4-1-2018", - "display_name": "IEC 62443-4-1 (2018)", + "display_name": "International Electrotechnical Commission (IEC) 62443 - 4 - 1:2018 - Security for industrial automation and control systems - Part 4 - 1: Secure product development lifecycle requirements", "scf_controls_mapped": 25, "framework_controls_mapped": 186 }, { "framework_id": "general-iec-62443-4-2-2019", - "display_name": "IEC 62443-4-2 (2019)", + "display_name": "International Electrotechnical Commission 62443 - 4 - 2 Ed. 1.0 b:2019 - Security for industrial automation and control systems - Part 4 - 2: Technical security requirements for IACS components", "scf_controls_mapped": 89, "framework_controls_mapped": 169 }, { "framework_id": "general-iec-tr-60601-4-5-2021", - "display_name": "IEC TR 60601-4-5 (2021)", + "display_name": "International Electrotechnical Commission (IEC) Technical Report 60601 - 4 - 5:2021 - Medical electrical equipment - Part 4 - 5: Guidance and interpretation - Safety - related technical security specifications", "scf_controls_mapped": 26, "framework_controls_mapped": 37 }, @@ -868,820 +867,844 @@ }, { "framework_id": "general-iso-21434-2021", - "display_name": "ISO 21434 (2021)", + "display_name": "ISO/SAE 21434:2021 - Road vehicles — Cybersecurity engineering", "scf_controls_mapped": 51, "framework_controls_mapped": 232 }, { "framework_id": "general-iso-22301-2019", - "display_name": "ISO 22301 (2019)", + "display_name": "ISO/IEC 22301:2019 - Security and resilience - Business continuity management systems - Requirements", "scf_controls_mapped": 36, "framework_controls_mapped": 259 }, { "framework_id": "general-iso-27001-2022", - "display_name": "ISO 27001 (2022)", + "display_name": "ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements", "scf_controls_mapped": 51, "framework_controls_mapped": 148 }, { "framework_id": "general-iso-27002-2022", - "display_name": "ISO 27002 (2022)", + "display_name": "ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls", "scf_controls_mapped": 316, "framework_controls_mapped": 96 }, { "framework_id": "general-iso-27017-2015", - "display_name": "ISO 27017 (2015)", + "display_name": "ISO/IEC 27017:2015 - Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services", "scf_controls_mapped": 224, "framework_controls_mapped": 118 }, { "framework_id": "general-iso-27018-2025", - "display_name": "ISO 27018 (2025)", + "display_name": "ISO/IEC 27018:2025 - Information security, cybersecurity and privacy protection - Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors", "scf_controls_mapped": 322, "framework_controls_mapped": 108 }, { "framework_id": "general-iso-27701-2025", - "display_name": "ISO 27701 (2025)", + "display_name": "ISO/IEC 27701:2025 - Information security, cybersecurity and privacy protection - Privacy information management systems - Requirements and guidance", "scf_controls_mapped": 59, "framework_controls_mapped": 90 }, { "framework_id": "general-iso-29100-2024", - "display_name": "ISO 29100 (2024)", + "display_name": "ISO/IEC 29100:2024 - Information technology - Security techniques - Privacy framework", "scf_controls_mapped": 43, "framework_controls_mapped": 11 }, { "framework_id": "general-iso-31000-2018", - "display_name": "ISO 31000 (2018)", + "display_name": "ISO/IEC 31000:2018 - Risk management - Guidelines", "scf_controls_mapped": 53, "framework_controls_mapped": 27 }, { "framework_id": "general-iso-31010-2009", - "display_name": "ISO 31010 (2009)", + "display_name": "ISO/IEC 31010:2019 - Risk management - Risk assessment techniques", "scf_controls_mapped": 31, "framework_controls_mapped": 32 }, { "framework_id": "general-iso-42001-2023", - "display_name": "ISO 42001 (2023)", + "display_name": "ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system", "scf_controls_mapped": 149, "framework_controls_mapped": 140 }, { - "framework_id": "general-mitre-att&ck-16-1", - "display_name": "MITRE ATT&CK (v16.1)", + "framework_id": "general-mitre-att_ck-16-1", + "display_name": "MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) - NIST 800 - 53 mappings", "scf_controls_mapped": 108, "framework_controls_mapped": 511 }, { "framework_id": "general-mpa-csbp-5-3-1", - "display_name": "Content Security Best Practices Common Guidelines (v5.3.1)", + "display_name": "Motion Picture Association (MPA) Content Security Best Practices Common Guidelines v5.3.1", "scf_controls_mapped": 232, "framework_controls_mapped": 81 }, { "framework_id": "general-naic-insurance-data-security-model-law-668-2017", - "display_name": "Insurance Data Security Model Law 668 (2017)", + "display_name": "National Association of Insurance Commissioners (NAIC) Insurance Data Security Model Law (MDL - 668) (2017)", "scf_controls_mapped": 58, "framework_controls_mapped": 85 }, { "framework_id": "general-nist-100-1-ai-rmf", - "display_name": "NIST AI 100-1 (AI RMF 1.0)", + "display_name": "NIST AI 100 - 1 - Artificial Intelligence Risk Management Framework (AI RMF 1.0)", "scf_controls_mapped": 158, "framework_controls_mapped": 91 }, { "framework_id": "general-nist-600-1-gen-ai-profile", - "display_name": "NIST AI 600-1", + "display_name": "NIST AI 600 - 1 - Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", "scf_controls_mapped": 139, "framework_controls_mapped": 250 }, { "framework_id": "general-nist-800-160-vol-2-r1", - "display_name": "NIST SP 800-160 (Vol 2, Rev 1)", + "display_name": "NIST SP 800 - 160 Volume 2, Revision 1 - Developing Cyber - Resilient Systems: A Systems Security Engineering Approach", "scf_controls_mapped": 204, "framework_controls_mapped": 196 }, { "framework_id": "general-nist-800-161-r1", - "display_name": "NIST SP 800-161 R1 UDP1", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations", "scf_controls_mapped": 341, "framework_controls_mapped": 308 }, { "framework_id": "general-nist-800-161-r1-cscrm", - "display_name": "NIST SP 800-161 R1 UDP1 - C-SCRM Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - C - SCRM Baseline", "scf_controls_mapped": 132, "framework_controls_mapped": 95 }, { "framework_id": "general-nist-800-161-r1-flowdown", - "display_name": "NIST SP 800-161 R1 UDP1 - Flow Down Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Flow Down Baseline", "scf_controls_mapped": 107, "framework_controls_mapped": 69 }, { "framework_id": "general-nist-800-161-r1-level-1", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 1 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 1 Baseline", "scf_controls_mapped": 95, "framework_controls_mapped": 76 }, { "framework_id": "general-nist-800-161-r1-level-2", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 2 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 2 Baseline", "scf_controls_mapped": 273, "framework_controls_mapped": 236 }, { "framework_id": "general-nist-800-161-r1-level-3", - "display_name": "NIST SP 800-161 R1 UDP1 - Level 3 Baseline", + "display_name": "NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 3 Baseline", "scf_controls_mapped": 284, "framework_controls_mapped": 251 }, { "framework_id": "general-nist-800-171-r2", - "display_name": "NIST SP 800-171 R2", + "display_name": "NIST SP 800 - 171 R2 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", "scf_controls_mapped": 251, "framework_controls_mapped": 172 }, { "framework_id": "general-nist-800-171-r3", - "display_name": "NIST SP 800-171 R3", - "scf_controls_mapped": 407, + "display_name": "NIST SP 800 - 171 R3 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", + "scf_controls_mapped": 414, "framework_controls_mapped": 275 }, { "framework_id": "general-nist-800-171a", - "display_name": "NIST SP 800-171A", + "display_name": "NIST SP 800 - 171A - Assessing Security Requirements for Controlled Unclassified Information", "scf_controls_mapped": 134, "framework_controls_mapped": 320 }, { "framework_id": "general-nist-800-171a-r3", - "display_name": "NIST SP 800-171A R3", - "scf_controls_mapped": 215, - "framework_controls_mapped": 508 + "display_name": "NIST SP 800 - 171A R3 - Assessing Security Requirements for Controlled Unclassified Information", + "scf_controls_mapped": 414, + "framework_controls_mapped": 509 }, { - "framework_id": "general-nist-800-172", - "display_name": "NIST SP 800-172", - "scf_controls_mapped": 74, - "framework_controls_mapped": 35 + "framework_id": "general-nist-800-172-r3", + "display_name": "NIST SP 800 - 172 R3 - Enhanced Security Requirements for Protecting Controlled Unclassified Information", + "scf_controls_mapped": 162, + "framework_controls_mapped": 103 + }, + { + "framework_id": "general-nist-800-172a-r3", + "display_name": "NIST SP 800 - 172A R3 - Assessing Enhanced Security Requirements for Controlled Unclassified Information", + "scf_controls_mapped": 163, + "framework_controls_mapped": 364 }, { "framework_id": "general-nist-800-207", - "display_name": "NIST SP 800-207", + "display_name": "NIST SP 800 - 207 - Zero Trust Architecture", "scf_controls_mapped": 93, "framework_controls_mapped": 7 }, { "framework_id": "general-nist-800-218", - "display_name": "NIST SP 800-218", + "display_name": "NIST SP 800 - 218 - Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities", "scf_controls_mapped": 59, "framework_controls_mapped": 60 }, { "framework_id": "general-nist-800-37-r2", - "display_name": "NIST SP 800-37 R2", + "display_name": "NIST SP 800 - 37 R2 - Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy", "scf_controls_mapped": 45, "framework_controls_mapped": 47 }, { "framework_id": "general-nist-800-39", - "display_name": "NIST SP 800-39", + "display_name": "NIST SP 800 - 39 - Managing Information Security Risk: Organization, Mission, and Information System View", "scf_controls_mapped": 17, "framework_controls_mapped": 16 }, { "framework_id": "general-nist-800-53-r4", - "display_name": "NIST SP 800-53 R4", + "display_name": "NIST SP 800 - 53 R4 - Security and Privacy Controls for Federal Information Systems and Organizations", "scf_controls_mapped": 653, "framework_controls_mapped": 682 }, { "framework_id": "general-nist-800-53-r5-2", - "display_name": "NIST SP 800-53 R5", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations", "scf_controls_mapped": 777, "framework_controls_mapped": 810 }, { "framework_id": "general-nist-800-53-r5-2-high", - "display_name": "NIST SP 800-53 R5 - High Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - High Baseline", "scf_controls_mapped": 89, "framework_controls_mapped": 83 }, { "framework_id": "general-nist-800-53-r5-2-low", - "display_name": "NIST SP 800-53 R5 - Low Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Low Baseline", "scf_controls_mapped": 202, "framework_controls_mapped": 149 }, { "framework_id": "general-nist-800-53-r5-2-mod", - "display_name": "NIST SP 800-53 R5 - Moderate Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Moderate Baseline", "scf_controls_mapped": 157, "framework_controls_mapped": 138 }, { "framework_id": "general-nist-800-53-r5-2-privacy", - "display_name": "NIST SP 800-53 R5 - Privacy Baseline", + "display_name": "NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Privacy Baseline", "scf_controls_mapped": 346, "framework_controls_mapped": 236 }, { "framework_id": "general-nist-800-66-r2", - "display_name": "NIST SP 800-66 R2", + "display_name": "NIST SP 800 - 66 R2 - Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide", "scf_controls_mapped": 112, "framework_controls_mapped": 22 }, { "framework_id": "general-nist-800-82-r3", - "display_name": "NIST SP 800-82 R3", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay", "scf_controls_mapped": 777, "framework_controls_mapped": 810 }, { "framework_id": "general-nist-800-82-r3-high", - "display_name": "NIST SP 800-82 R3 - High OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - High OT Overlay", "scf_controls_mapped": 467, "framework_controls_mapped": 418 }, { "framework_id": "general-nist-800-82-r3-low", - "display_name": "NIST SP 800-82 R3 - Low OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay", "scf_controls_mapped": 251, "framework_controls_mapped": 194 }, { "framework_id": "general-nist-800-82-r3-mod", - "display_name": "NIST SP 800-82 R3 - Moderate OT Overlay", + "display_name": "NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Moderate OT Overlay", "scf_controls_mapped": 390, "framework_controls_mapped": 337 }, { "framework_id": "general-nist-csf-2-0", - "display_name": "NIST Cybersecurity Framework (v2.0)", + "display_name": "NIST Cybersecurity Framework v2.0", "scf_controls_mapped": 250, "framework_controls_mapped": 134 }, + { + "framework_id": "general-nist-cswp-39", + "display_name": "NIST CSWP 39 - Considerations for Achieving Crypto Agility", + "scf_controls_mapped": 15, + "framework_controls_mapped": 18 + }, { "framework_id": "general-nist-privacy-framework-1-0", - "display_name": "NIST Privacy Framework (v1.0)", - "scf_controls_mapped": 152, - "framework_controls_mapped": 122 + "display_name": "NIST Privacy Framework v1.0", + "scf_controls_mapped": 153, + "framework_controls_mapped": 123 }, { "framework_id": "general-oecd-privacy-principles-2010", - "display_name": "OECD Privacy Principles (2010)", + "display_name": "Organisation for Economic Co - operation and Development (EOCD) Privacy Principles", "scf_controls_mapped": 14, "framework_controls_mapped": 17 }, { "framework_id": "general-owasp-top-10-2025", - "display_name": "OWASP Top 10 (2025)", + "display_name": "Open Worldwide Application Security Project (OWASP) Top 10 (2025)", "scf_controls_mapped": 139, "framework_controls_mapped": 10 }, { "framework_id": "general-pci-dss-4-0-1", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) (v4.01)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.01", "scf_controls_mapped": 371, "framework_controls_mapped": 351 }, { "framework_id": "general-pci-dss-4-0-1-saq-a", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ A (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A", "scf_controls_mapped": 71, "framework_controls_mapped": 29 }, { "framework_id": "general-pci-dss-4-0-1-saq-a-ep", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ A-EP (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A - EP", "scf_controls_mapped": 239, "framework_controls_mapped": 139 }, { "framework_id": "general-pci-dss-4-0-1-saq-b", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ B (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B", "scf_controls_mapped": 58, "framework_controls_mapped": 27 }, { "framework_id": "general-pci-dss-4-0-1-saq-b-ip", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ B-IP (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B - IP", "scf_controls_mapped": 121, "framework_controls_mapped": 50 }, { "framework_id": "general-pci-dss-4-0-1-saq-c", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ C (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C", "scf_controls_mapped": 227, "framework_controls_mapped": 124 }, { "framework_id": "general-pci-dss-4-0-1-saq-c-vt", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ C-VT (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C - VT", "scf_controls_mapped": 115, "framework_controls_mapped": 54 }, { "framework_id": "general-pci-dss-4-0-1-saq-d-merchant", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Merchant (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Merchant", "scf_controls_mapped": 322, "framework_controls_mapped": 233 }, { "framework_id": "general-pci-dss-4-0-1-saq-d-service-provider", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Service Provider (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Service Provider", "scf_controls_mapped": 339, "framework_controls_mapped": 257 }, { "framework_id": "general-pci-dss-4-0-1-saq-p2pe", - "display_name": "Payment Card Industry Data Security Standard (PCI DSS) - SAQ P2PE (v4.0.1)", + "display_name": "Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) P2PE", "scf_controls_mapped": 47, "framework_controls_mapped": 21 }, { "framework_id": "general-scf-dpmp-2025", - "display_name": "Data Privacy Management Principle (DPMP) (2025)", - "scf_controls_mapped": 218, - "framework_controls_mapped": 83 + "display_name": "Secure Controls Framework (SCF) Data Privacy Management Principles (2025)", + "scf_controls_mapped": 0, + "framework_controls_mapped": 0 }, { "framework_id": "general-shared-assessments-sig-2025", - "display_name": "SIG (2025)", + "display_name": "Shared Assessments Standard Information Gathering (SIG) Questionnaire 2025", "scf_controls_mapped": 128, "framework_controls_mapped": 65 }, { "framework_id": "general-sparta", - "display_name": "SPARTA Countermeasures", + "display_name": "Space Attack Research & Tactic Analysis (SPARTA) Countermeasures", "scf_controls_mapped": 79, "framework_controls_mapped": 53 }, { "framework_id": "general-swift-cscf-2025", - "display_name": "SWIFT Customer Security Controls Framework (2025)", + "display_name": "Society for Worldwide Interbank Financial Telecommunication Customer Security Controls Framework 2025", "scf_controls_mapped": 164, "framework_controls_mapped": 32 }, { "framework_id": "general-tisax-6-0-3", - "display_name": "TISAX ISA (6.0.3)", + "display_name": "Trusted Information Security Assessment Exchange (TISAX) 6.0.3", "scf_controls_mapped": 154, "framework_controls_mapped": 73 }, { "framework_id": "general-ul-2900-1-2017", - "display_name": "UL 2900-1 (2017)", + "display_name": "UL 2900 - 1 - Software Cybersecurity for Network - Connectable Products, Part 1: General Requirements (2017)", "scf_controls_mapped": 23, "framework_controls_mapped": 143 }, { "framework_id": "general-ul-2900-2-2-2016", - "display_name": "UL 2900-2-2 (2016)", + "display_name": "UL 2900 - 2 - 2 Ed. 1 - 2016 - Outline of Investigation for Software Cybersecurity for Network - Connectable Products, Part 2 - 2: Particular Requirements for Industrial Control Systems", "scf_controls_mapped": 20, "framework_controls_mapped": 57 }, { "framework_id": "general-un-155-2021", - "display_name": "UN Regulation No. 155 (2021)", + "display_name": "United Nations - Regulation No. 155 - Cyber security and cyber security management system (2021)", "scf_controls_mapped": 57, "framework_controls_mapped": 55 }, { "framework_id": "general-un-ece-wp-29-2020", - "display_name": "UNECE WP.29 (2020)", + "display_name": "United Nations - United Nations Economic Commission for Europe (UNECE) Working Party 29 (2020)", "scf_controls_mapped": 57, "framework_controls_mapped": 54 }, { "framework_id": "usa-federal-cms-marse-2-0", - "display_name": "MARS-E Document Suite (2.0)", - "scf_controls_mapped": 391, - "framework_controls_mapped": 1286 + "display_name": "US - Centers for Medicare & Medicaid Services MARS - E Document Suite, Version 2.0", + "scf_controls_mapped": 392, + "framework_controls_mapped": 1287 }, { "framework_id": "usa-federal-dhs-cisa-cpg-2-0", - "display_name": "CISA Cross-Sector Cybersecurity Performance Goals (CPG) (2.0)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Cross - Sector Cybersecurity Performance Goals 2.0", "scf_controls_mapped": 126, "framework_controls_mapped": 38 }, { "framework_id": "usa-federal-dhs-cisa-ssdaf-2024", - "display_name": "CISA Secure Software Development Attestation Form (SSDAF) (2024)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Secure Software Development Attestation Form (SSDAF) (2024)", "scf_controls_mapped": 41, "framework_controls_mapped": 15 }, { "framework_id": "usa-federal-dhs-cisa-tic-3-0", - "display_name": "CISA Trusted Internet Connections 3.0 Security Capabilities Catalog (TIC 3.0)", + "display_name": "US - Cybersecurity & Infrastructure Security Agency (CISA) Trusted Internet Connections 3.0 Security Capabilities Catalog", "scf_controls_mapped": 148, "framework_controls_mapped": 117 }, { "framework_id": "usa-federal-doc-data-privacy-framework-2023", - "display_name": "Data Privacy Framework (2023)", + "display_name": "US - Data Privacy Framework (2023)", "scf_controls_mapped": 31, "framework_controls_mapped": 74 }, { "framework_id": "usa-federal-doe-c2m2-2-1", - "display_name": "Cybersecurity Capability Maturity Model (C2M2) (v2.1)", + "display_name": "US - Department of Energy (DOE) - Cybersecurity Capability Maturity Model version 2.1", "scf_controls_mapped": 224, "framework_controls_mapped": 356 }, { "framework_id": "usa-federal-dow-cert-rmm-1-2", - "display_name": "CERT-RMM (v1.2)", + "display_name": "US - Department of War (DoW) - Computer Emergency Response Team (CERT) Resilience Management Model (RMM) Version 1.2", "scf_controls_mapped": 85, "framework_controls_mapped": 753 }, { "framework_id": "usa-federal-dow-cmmc-2-level-1", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1", + "display_name": "US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1", "scf_controls_mapped": 52, "framework_controls_mapped": 15 }, { "framework_id": "usa-federal-dow-cmmc-2-level-1-aos", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1 Assessment Objectives", + "display_name": "US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1 Assessment Objectives", "scf_controls_mapped": 16, "framework_controls_mapped": 59 }, { "framework_id": "usa-federal-dow-cmmc-2-level-2", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 2", + "display_name": "US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 2", "scf_controls_mapped": 198, "framework_controls_mapped": 110 }, { "framework_id": "usa-federal-dow-cmmc-2-level-3", - "display_name": "Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 3", + "display_name": "US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 3", "scf_controls_mapped": 55, "framework_controls_mapped": 24 }, { "framework_id": "usa-federal-dow-dfars-252-204-7012", - "display_name": "DFARS 252.204-7012", + "display_name": "US - Defense Federal Acquisition Regulation Supplement (DFARS) 252.204 - 7012", "scf_controls_mapped": 19, "framework_controls_mapped": 20 }, { "framework_id": "usa-federal-dow-safeguarding-nnpi-2010", - "display_name": "Safeguarding of NNPI (2010)", + "display_name": "US - Safeguarding of Naval Nuclear Propulsion Information (NNPI) (2010)", "scf_controls_mapped": 32, "framework_controls_mapped": 68 }, { "framework_id": "usa-federal-dow-zt-roadmap-1-1", - "display_name": "Department of War (DoW) - Zero Trust Execution Roadmap (v1.1)", + "display_name": "US - Department of War (DoW) - Zero Trust Execution Roadmap v1.1", "scf_controls_mapped": 117, - "framework_controls_mapped": 190 + "framework_controls_mapped": 191 }, { "framework_id": "usa-federal-dow-zta-reference-architecture-2-0", - "display_name": "Department of War (DoW) - Zero Trust Reference Architecture (v2)", + "display_name": "US - Department of War (DoW) - Zero Trust Reference Architecture v2", "scf_controls_mapped": 39, "framework_controls_mapped": 28 }, { "framework_id": "usa-federal-eo-14028", - "display_name": "Executive Order 14028 - Improving the Nation's Cybersecurity", + "display_name": "US - Executive Order (EO) 14028 - Improving the Nation's Cybersecurity", "scf_controls_mapped": 43, "framework_controls_mapped": 16 }, { "framework_id": "usa-federal-far-52-204-21", - "display_name": "FAR 52.204-21", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 21 - Basic Safeguarding of Covered Contractor Information Systems", "scf_controls_mapped": 59, "framework_controls_mapped": 17 }, { "framework_id": "usa-federal-far-52-204-25", - "display_name": "FAR 52.204-25 (NDAA Section 889)", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 25 (NDAA Section 889) - Prohibition on Contracting With Entities Using Certain Telecommunications and Video Surveillance Services or Equipment", "scf_controls_mapped": 2, "framework_controls_mapped": 5 }, { "framework_id": "usa-federal-far-52-204-27", - "display_name": "FAR 52.204-27", + "display_name": "US - Federal Acquisition Regulation (FAR) 52.204 - 27 - Prohibition on a ByteDance Covered Application", "scf_controls_mapped": 3, "framework_controls_mapped": 2 }, { "framework_id": "usa-federal-fbi-cjis-6-0", - "display_name": "Criminal Justice Information Services (CJIS) Security Policy (v6.0)", + "display_name": "US - Department of Justice - Criminal Justice Information Services (CJIS) Security Policy v6.0", "scf_controls_mapped": 365, "framework_controls_mapped": 319 }, { "framework_id": "usa-federal-fda-21-cfr-part-11-2025", - "display_name": "Food & Drug Administration (FDA) 21 CFR Part 11 (2025)", + "display_name": "US - Food & Drug Administration (FDA) 21 CFR Part 11 (2025)", "scf_controls_mapped": 62, "framework_controls_mapped": 28 }, { "framework_id": "usa-federal-gsa-fedramp-5-high", - "display_name": "FedRAMP R5 - High Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - High Baseline", "scf_controls_mapped": 561, "framework_controls_mapped": 490 }, { "framework_id": "usa-federal-gsa-fedramp-5-li-saas", - "display_name": "FedRAMP R5 - Li-SAAS Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Li - SAAS Baseline", "scf_controls_mapped": 383, "framework_controls_mapped": 269 }, { "framework_id": "usa-federal-gsa-fedramp-5-low", - "display_name": "FedRAMP R5 - Low Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Low Baseline", "scf_controls_mapped": 383, "framework_controls_mapped": 269 }, { "framework_id": "usa-federal-gsa-fedramp-5-mod", - "display_name": "FedRAMP R5 - Moderate Baseline", + "display_name": "US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Moderate Baseline", "scf_controls_mapped": 491, "framework_controls_mapped": 410 }, { "framework_id": "usa-federal-hhs-45-cfr-155-260-2016", - "display_name": "HHS § 155.260 (2016)", + "display_name": "US - Health and Human Services (HHS) § 155.260 - Privacy and Security of Personally Identifiable Information (2016)", "scf_controls_mapped": 36, "framework_controls_mapped": 44 }, { "framework_id": "usa-federal-irs-1075-2021", - "display_name": "IRS 1075 (2021)", - "scf_controls_mapped": 442, - "framework_controls_mapped": 743 + "display_name": "US - Internal Revenue Service (IRS) 1075 (2021)", + "scf_controls_mapped": 443, + "framework_controls_mapped": 744 + }, + { + "framework_id": "usa-federal-law-33-cfr-part-101-subpart-f", + "display_name": "US - 33 CFR Part 101 Subpart F (up to date as of 4 - 17 - 2026)", + "scf_controls_mapped": 104, + "framework_controls_mapped": 148 }, { "framework_id": "usa-federal-law-coppa-2024", - "display_name": "Children's Online Privacy Protection Act (COPPA) (2024)", + "display_name": "US - Children's Online Privacy Protection Act (COPPA) (2024)", "scf_controls_mapped": 10, "framework_controls_mapped": 8 }, { "framework_id": "usa-federal-law-facta-fcra-2023", - "display_name": "Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023)", + "display_name": "US - Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023)", "scf_controls_mapped": 3, "framework_controls_mapped": 6 }, { "framework_id": "usa-federal-law-ferpa-2010", - "display_name": "Family Educational Rights and Privacy Act (FERPA) (2010)", + "display_name": "US - Family Educational Rights and Privacy Act (FERPA) (2010)", "scf_controls_mapped": 5, "framework_controls_mapped": 27 }, { "framework_id": "usa-federal-law-ftc-act", - "display_name": "Federal Trade Commission (FTC) Act", + "display_name": "US - Federal Trade Commission (FTC) Act", "scf_controls_mapped": 16, "framework_controls_mapped": 1 }, { "framework_id": "usa-federal-law-glba-cfr-314-2023", - "display_name": "Gramm Leach Bliley Act (GLBA) (2023)", + "display_name": "US - Gramm Leach Bliley Act (GLBA) - CFR 314 (Dec 2023)", "scf_controls_mapped": 70, "framework_controls_mapped": 52 }, { "framework_id": "usa-federal-law-hipaa-security-rule-2013", - "display_name": "HIPAA Security Rule (2013)", + "display_name": "US - Health Insurance Portability and Accountability Act (HIPAA) Security Rule (2013)", "scf_controls_mapped": 136, "framework_controls_mapped": 87 }, { "framework_id": "usa-federal-law-hipaa-simplification-2013", - "display_name": "HIPAA Administrative Simplification (2013)", + "display_name": "US - Health Insurance Portability and Accountability Act (HIPAA) Administrative Simplification (2013)", "scf_controls_mapped": 170, "framework_controls_mapped": 576 }, { "framework_id": "usa-federal-law-sox-2002", - "display_name": "SOX (2002)", + "display_name": "US - Sarbanes Oxley Act (SOX) (2002)", "scf_controls_mapped": 4, "framework_controls_mapped": 17 }, { "framework_id": "usa-federal-nerc-cip-2024", - "display_name": "NERC Critical Infrastructure Protection (CIP) (2024)", + "display_name": "US - North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) (2024)", "scf_controls_mapped": 122, "framework_controls_mapped": 204 }, { "framework_id": "usa-federal-nispom-2020", - "display_name": "National Industrial Security Program Operating Manual (NISPOM) (2020)", + "display_name": "US - National Industrial Security Program Operating Manual (NISPOM) (2020)", "scf_controls_mapped": 35, "framework_controls_mapped": 226 }, { "framework_id": "usa-federal-omb-fipps-1973", - "display_name": "US Fair Information Practice Principles (FIPPs) (1973)", + "display_name": "US - Fair Information Practice Principles (FIPPs) (1973)", "scf_controls_mapped": 30, "framework_controls_mapped": 8 }, { "framework_id": "usa-federal-sec-cybersecurity-rule-2023", - "display_name": "SEC Cybersecurity Rule (2023)", + "display_name": "US - Securities and Exchange Commission (SEC) Cybersecurity Rule (2023)", "scf_controls_mapped": 40, "framework_controls_mapped": 15 }, { "framework_id": "usa-federal-sro-fca-crm-2023", - "display_name": "Farm Credit Administration (FCA) Cyber Risk Management (2023)", + "display_name": "US - Farm Credit Administration (FCA) Cyber Risk Management (2023)", "scf_controls_mapped": 81, "framework_controls_mapped": 34 }, { "framework_id": "usa-federal-sro-finra", - "display_name": "FINRA Cybersecurity Rules", + "display_name": "US - Financial Industry Regulatory Authority (FINRA) Cybersecurity Rules", "scf_controls_mapped": 17, "framework_controls_mapped": 39 }, { "framework_id": "usa-federal-tsa-security-directive-1580-82-2022-01", - "display_name": "TSA Security Directive 1580/82-2022-01", + "display_name": "US - Transportation Security Administration (TSA) Security Directive 1580/82 - 2022 - 01 - Rail Cybersecurity Mitigation Actions and Testing", "scf_controls_mapped": 60, "framework_controls_mapped": 68 }, { "framework_id": "usa-state-ak-pipa-2009", - "display_name": "Alaska Personal Information Protection Act (PIPA) (2009)", + "display_name": "US - Alaska Personal Information Protection Act (PIPA) (2009)", "scf_controls_mapped": 5, "framework_controls_mapped": 25 }, { "framework_id": "usa-state-ca-ccpa-cpra-2026", - "display_name": "California Consumer Privacy Act (CCPA) (2026)", + "display_name": "US - California Consumer Privacy Act (CCPA) (January 2026) - amended California Privacy Rights Act (CPRA)", "scf_controls_mapped": 258, "framework_controls_mapped": 623 }, { "framework_id": "usa-state-ca-sb1386-2002", - "display_name": "California SB1386 (2002)", + "display_name": "US - California SB1386 (2002)", "scf_controls_mapped": 4, "framework_controls_mapped": 6 }, { "framework_id": "usa-state-ca-sb327-2018", - "display_name": "California SB327 (2018)", + "display_name": "US - California SB327 (2018)", "scf_controls_mapped": 3, "framework_controls_mapped": 7 }, { "framework_id": "usa-state-co-privacy-act-2021", - "display_name": "Colorado Privacy Act (2021)", + "display_name": "US - Colorado Privacy Act (2021)", "scf_controls_mapped": 23, "framework_controls_mapped": 52 }, { "framework_id": "usa-state-il-bipa-2008", - "display_name": "Illinois Biometric Information Privacy Act (BIPA) (2008)", + "display_name": "US - Illinois Biometric Information Privacy Act (BIPA) (2008)", "scf_controls_mapped": 6, "framework_controls_mapped": 12 }, { "framework_id": "usa-state-il-ipa-2009", - "display_name": "Illinois Identity Protection Act (IPA) (2009)", + "display_name": "US - Illinois Identity Protection Act (IPA) (2009)", "scf_controls_mapped": 12, "framework_controls_mapped": 33 }, { "framework_id": "usa-state-il-pipa-2006", - "display_name": "Illinois Personal Information Protection Act (PIPA) (2006)", + "display_name": "US - Illinois Personal Information Protection Act (PIPA) (2006)", "scf_controls_mapped": 10, "framework_controls_mapped": 53 }, { "framework_id": "usa-state-ma-201-cmr-17-2008", - "display_name": "Massachusetts 201 CMR 17.00 (2008)", + "display_name": "US - Massachusetts 201 CMR 17.00 (2008)", "scf_controls_mapped": 53, "framework_controls_mapped": 37 }, + { + "framework_id": "usa-state-nv-privacy-law-2023", + "display_name": "US - Nevada Privacy Law (2023) - CHAPTER 603A - SECURITY AND PRIVACY OF PERSONAL INFORMATION", + "scf_controls_mapped": 29, + "framework_controls_mapped": 121 + }, { "framework_id": "usa-state-nv-regulation-5-2024", - "display_name": "Nevada Operation of Gaming Establishment (NOGE) Regulation 5.260 (2024)", + "display_name": "US - Nevada Operation of Gaming Establishments - Regulation 5.260 (Cybersecurity)", "scf_controls_mapped": 20, "framework_controls_mapped": 11 }, { "framework_id": "usa-state-nv-sb220-2019", - "display_name": "Nevada SB220 (2019)", + "display_name": "US - Nevada SB220 (2019)", "scf_controls_mapped": 3, "framework_controls_mapped": 4 }, { "framework_id": "usa-state-ny-dfs-23-nycrr500-2023-amd2", - "display_name": "New York Department of Financial Services 23NYCRR Part 500 (2023 Amendment 2)", + "display_name": "US - New York Department of Financial Services (NY DFS) 23NYCRR Part 500 (2023 Amendment 2)", "scf_controls_mapped": 156, "framework_controls_mapped": 145 }, { "framework_id": "usa-state-ny-shield-act-2019", - "display_name": "New York SHIELD Act (SB S5575B) (2019)", + "display_name": "US - New York SHIELD Act (SB S5575B) (2019)", "scf_controls_mapped": 28, "framework_controls_mapped": 45 }, { "framework_id": "usa-state-or-cpa-2023", - "display_name": "Oregon Consumer Privacy Act (SB 619) (2023)", + "display_name": "US - Oregon Consumer Privacy Act (SB 619) (2023)", "scf_controls_mapped": 34, "framework_controls_mapped": 75 }, { "framework_id": "usa-state-or-ors-646a-2025", - "display_name": "Oregon Consumer Information Protection Act (ORS 646A) (2025)", + "display_name": "US - Oregon Consumer Information Protection Act (ORS 646A) (2025)", "scf_controls_mapped": 24, "framework_controls_mapped": 97 }, { "framework_id": "usa-state-tn-tipa-2025", - "display_name": "Tennessee Information Protection Act (TIPA) (2025)", + "display_name": "US - Tennessee Information Protection Act (TIPA) (2025)", "scf_controls_mapped": 29, "framework_controls_mapped": 76 }, { "framework_id": "usa-state-tx-bc521-2009", - "display_name": "Texas Identity Theft Enforcement and Protection Act (BC521) (2009)", + "display_name": "US - Texas Identity Theft Enforcement and Protection Act (BC521) (2009)", "scf_controls_mapped": 5, "framework_controls_mapped": 27 }, { "framework_id": "usa-state-tx-cdpa-2025", - "display_name": "Texas Consumer Data Protection Act (2025)", + "display_name": "US - Texas Consumer Data Protection Act (2025)", "scf_controls_mapped": 28, "framework_controls_mapped": 89 }, { "framework_id": "usa-state-tx-dir-security-control-standards-catalog-2-2", - "display_name": "Texas DIR Security Control Standards Catalog (v2.2)", + "display_name": "US - Texas DIR Security Control Standards Catalog v2.2", "scf_controls_mapped": 238, "framework_controls_mapped": 228 }, { "framework_id": "usa-state-tx-sb2610-2025", - "display_name": "Texas Safe Harbor Law (SB2610) (2025)", + "display_name": "US - Texas Safe Harbor Law (SB2610) (2025)", "scf_controls_mapped": 6, "framework_controls_mapped": 33 }, { "framework_id": "usa-state-tx-sb820-2019", - "display_name": "Texas SB820 (2019)", + "display_name": "US - Texas SB820 (2019)", "scf_controls_mapped": 4, "framework_controls_mapped": 7 }, { "framework_id": "usa-state-tx-txramp-2-0-level-1", - "display_name": "TX-RAMP 2.0 - Level 1", + "display_name": "US - Texas Risk & Authorization Management Program 2.0 - Level 1", "scf_controls_mapped": 173, "framework_controls_mapped": 117 }, { "framework_id": "usa-state-tx-txramp-2-0-level-2", - "display_name": "TX-RAMP 2.0 - Level 2", + "display_name": "US - Texas Risk & Authorization Management Program 2.0 - Level 2", "scf_controls_mapped": 285, "framework_controls_mapped": 223 }, { "framework_id": "usa-state-va-cdpa-2023", - "display_name": "Virginia Consumer Data Protection Act (2023)", + "display_name": "US - Virginia Consumer Data Protection Act (2023)", "scf_controls_mapped": 44, "framework_controls_mapped": 64 }, { "framework_id": "usa-state-vt-act-171-2018", - "display_name": "Vermont Data Broker Registration Act (Act 171 of 2018)", + "display_name": "US - Vermont Data Broker Registration Act (Act 171 of 2018)", "scf_controls_mapped": 35, "framework_controls_mapped": 61 } ], - "total_threats": 41, + "total_threats": 42, "total_risks": 39, - "total_assessment_objectives": 5776, - "total_evidence_requests": 303, - "total_compensating_controls": 1305, + "total_assessment_objectives": 5956, + "total_evidence_requests": 316, + "total_compensating_controls": 1371, "total_privacy_principles": 258, "weight_distribution": { "0": 1, "1": 42, "2": 43, - "3": 65, + "3": 67, "4": 41, - "5": 309, - "6": 79, - "7": 134, - "8": 267, - "9": 324, + "5": 311, + "6": 80, + "7": 192, + "8": 269, + "9": 325, "10": 163 } } \ No newline at end of file diff --git a/docs/api/threats.json b/docs/api/threats.json index 3947797c..abd5c23a 100644 --- a/docs/api/threats.json +++ b/docs/api/threats.json @@ -1,5 +1,5 @@ { - "total": 41, + "total": 42, "threats": [ { "threat_id": "NT-1", @@ -155,7 +155,7 @@ "threat_id": "MT-12", "grouping": "Man-Made Threat", "name": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) Data", - "description": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data is information an organization utilizes for business processes even though the data is untrustworthy, due to the data's currency, accuracy, integrity and/or applicability." + "description": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data is information an organization utilizes for business processes even though the data is untrustworthy, due to the data's currency, accuracy, integrity and/or applicability. This includes \"poisoned\", or otherwise compromised, Artificial Intelligence (AI) training data." }, { "threat_id": "MT-13", @@ -246,6 +246,12 @@ "grouping": "Man-Made Threat", "name": "Infrastructure", "description": "Infrastructure is a threat category that pertains to the availability and functioning of fundamental facilities and systems necessary to support an industry and its supply chains within a country. This includes buildings, transportation networks, utilities and equipment. Additionally, this includes how well those facilities and systems are protected from both natural and man-made threats." + }, + { + "threat_id": "MT-28", + "grouping": "Man-Made Threat", + "name": "Harvest Now / Decrypt Later (HNDL)", + "description": "Harvest Now / Decrypt Later (HNDL) is a threat category associated with Post-Quantum Cryptography (PQC) that is focused on nation-state threat actors harvesting data streams using legacy encryption protocols, so when a quantum computer exists it can decrypt harvested data for long-living sensitive / regulated data (e.g., secrets, intellectual property, etc.)." } ] } \ No newline at end of file diff --git a/docs/api/threats/MT-12.json b/docs/api/threats/MT-12.json index 9bdcaef9..ec151970 100644 --- a/docs/api/threats/MT-12.json +++ b/docs/api/threats/MT-12.json @@ -2,5 +2,5 @@ "threat_id": "MT-12", "grouping": "Man-Made Threat", "name": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) Data", - "description": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data is information an organization utilizes for business processes even though the data is untrustworthy, due to the data's currency, accuracy, integrity and/or applicability." + "description": "Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data is information an organization utilizes for business processes even though the data is untrustworthy, due to the data's currency, accuracy, integrity and/or applicability. This includes \"poisoned\", or otherwise compromised, Artificial Intelligence (AI) training data." } \ No newline at end of file diff --git a/docs/api/threats/MT-28.json b/docs/api/threats/MT-28.json new file mode 100644 index 00000000..d3ff5fb8 --- /dev/null +++ b/docs/api/threats/MT-28.json @@ -0,0 +1,6 @@ +{ + "threat_id": "MT-28", + "grouping": "Man-Made Threat", + "name": "Harvest Now / Decrypt Later (HNDL)", + "description": "Harvest Now / Decrypt Later (HNDL) is a threat category associated with Post-Quantum Cryptography (PQC) that is focused on nation-state threat actors harvesting data streams using legacy encryption protocols, so when a quantum computer exists it can decrypt harvested data for long-living sensitive / regulated data (e.g., secrets, intellectual property, etc.)." +} \ No newline at end of file diff --git a/docs/index.html b/docs/index.html index 0c5ee8f0..86b19298 100644 --- a/docs/index.html +++ b/docs/index.html @@ -4,7 +4,7 @@ SCF API — SC2 - + -

SCF APIv2026.1.1

+

SCF APIv2026.2

The Secure Controls Framework as a validated, versioned, static JSON API — parsed from the official SCF workbook, gated on cross-sheet referential integrity, and rebuilt automatically on every upstream release. No auth, no rate limits, plain files.

-
1,468controls
-
33families
-
249crosswalks
-
5,776assessment objectives
-
303evidence requests
-
1,305compensating controls
+
1,534controls
+
34families
+
252crosswalks
+
5,956assessment objectives
+
316evidence requests
+
1,371compensating controls

Try it

@@ -101,7 +101,7 @@

Agents

llms.txt · llms-full.txt · api/docs.md

-

SCF v2026.1.1, format-shifted verbatim from the official workbook — +

SCF v2026.2, format-shifted verbatim from the official workbook — content © Secure Controls Framework Council, CC BY-ND 4.0. Pipeline: sc2in/scf (AGPL-3.0), maintained by SC2. Every release ships its validation report.

diff --git a/docs/llms-full.txt b/docs/llms-full.txt index 2a325816..a238162b 100644 --- a/docs/llms-full.txt +++ b/docs/llms-full.txt @@ -1,6 +1,6 @@ # SCF API (sc2in/scf) -> Source-faithful static JSON API for the Secure Controls Framework (SCF) v2026.1.1. 1468 controls, 33 families, 249 framework crosswalks, 41 threats, 39 risks, 5776 assessment objectives, and 303 evidence requests. All static JSON, no auth required. +> Source-faithful static JSON API for the Secure Controls Framework (SCF) v2026.2. 1534 controls, 34 families, 252 framework crosswalks, 42 threats, 39 risks, 5956 assessment objectives, and 316 evidence requests. All static JSON, no auth required. All data is static JSON. Append paths to the base URL. @@ -37,14 +37,14 @@ Data: Control identifiers, titles, and crosswalk references from the Secure Cont # SCF API Reference -Static JSON API for the [Secure Controls Framework](https://securecontrolsframework.com) (SCF) v2026.1.1, +Static JSON API for the [Secure Controls Framework](https://securecontrolsframework.com) (SCF) v2026.2, maintained by SC2 (sc2in/scf). -- **1468** controls across **33** families -- **249** framework crosswalks -- **41** threats, **39** risks -- **5776** assessment objectives, **303** evidence requests -- **1305** compensating controls, **258** privacy principles +- **1534** controls across **34** families +- **252** framework crosswalks +- **42** threats, **39** risks +- **5956** assessment objectives, **316** evidence requests +- **1371** compensating controls, **258** privacy principles - All static JSON, no auth, CC BY-ND. ## Endpoints @@ -104,38 +104,39 @@ maintained by SC2 (sc2in/scf). | code | family | controls | |---|---|---| -| AAT | Artificial Intelligence & Autonomous Technologies | 156 | -| AST | Asset Management | 63 | +| AAT | Artificial Intelligence & Autonomous Technologies | 161 | +| AST | Asset Management | 64 | | BCD | Business Continuity & Disaster Recovery | 59 | | CAP | Capacity & Performance Planning | 6 | -| CFG | Configuration Management | 28 | +| CFG | Configuration Management | 32 | | CHG | Change Management | 20 | | CLD | Cloud Security | 24 | -| CPL | Compliance | 40 | +| CPL | Compliance | 41 | | CRY | Cryptographic Protections | 29 | | DCH | Data Classification & Handling | 85 | | EMB | Embedded Technology | 19 | | END | Endpoint Security | 47 | -| GOV | Cybersecurity & Data Protection Governance | 38 | +| GOV | Security, Compliance & Resilience Governance | 42 | | HRS | Human Resources Security | 46 | -| IAC | Identification & Authentication | 114 | +| IAC | Identification & Authentication | 116 | | IAO | Information Assurance | 15 | | IRO | Incident Response | 44 | | MDM | Mobile Device Management | 11 | | MNT | Maintenance | 28 | | MON | Continuous Monitoring | 71 | -| NET | Network Security | 98 | +| NET | Network Security | 100 | | OPS | Security Operations | 8 | | PES | Physical & Environmental Security | 51 | -| PRI | Data Privacy | 102 | +| PRI | Data Privacy | 103 | | PRM | Project & Resource Management | 11 | -| RSK | Risk Management | 32 | -| SAT | Security Awareness & Training | 17 | -| SEA | Secure Engineering & Architecture | 44 | -| TDA | Technology Development & Acquisition | 70 | -| THR | Threat Management | 13 | +| QTS | Quantum Security | 34 | +| RSK | Risk Management | 33 | +| SAT | Security Awareness & Training | 18 | +| SEA | Secure Engineering & Architecture | 47 | +| TDA | Technology Development & Acquisition | 74 | +| THR | Threat Management | 15 | | TPM | Third-Party Management | 31 | -| VPM | Vulnerability & Patch Management | 33 | +| VPM | Vulnerability & Patch Management | 34 | | WEB | Web Security | 15 | Data: Control identifiers, titles, and crosswalk references from the Secure Controls Framework (SCF), https://securecontrolsframework.com, licensed CC BY-ND 4.0. @@ -144,252 +145,255 @@ Data: Control identifiers, titles, and crosswalk references from the Secure Cont ## Frameworks -- `amaericas-can-osfi-self-assessment` — Canada - OSFI Cyber Security Self-Assessment Guidance (141 SCF controls, 88 framework controls) -- `americas-arg-ppd-2018` — Argentina - Protection of Personal Data (2018) (25 SCF controls, 50 framework controls) -- `americas-bhs-dpa-2003` — Bahamas - DPA (2003) (18 SCF controls, 5 framework controls) -- `americas-bmu-mba-coc-2020` — Bermuda - Bermuda Monetary Authority Code of Conduct (2020) (61 SCF controls, 37 framework controls) -- `americas-bra-lgpd-2018` — Brazil - General Data Protection Law (LGPD) (2018) (33 SCF controls, 55 framework controls) -- `americas-can-itsp-10-171-2025` — Canada - ITSP.10.171 (2025) (407 SCF controls, 275 framework controls) -- `americas-can-osfi-b13-2022` — Canada - OSFI B-13 (2022) (150 SCF controls, 77 framework controls) -- `americas-can-pipeda-2000` — Canada - Personal Information Protection and Electronic Documents Act (PIPEDA) (2000) (28 SCF controls, 17 framework controls) -- `americas-chl-act-19628-1999` — Chile - Act 19628 (1999) (22 SCF controls, 10 framework controls) -- `americas-col-law-1581-2012` — Colombia - Law 1581 (2012) (29 SCF controls, 12 framework controls) -- `americas-mex-fdpa-2010` — Mexico - Federal Law on Protection of Personal Data held by Private Parties (2010) (23 SCF controls, 25 framework controls) -- `apac-aus-cop-sitc-2020` — Australia - Code of Practice - Securing the Internet of Things for Consumers (2020) (15 SCF controls, 13 framework controls) -- `apac-aus-essential-8-2024` — Australia - Essential Eight (2024) (37 SCF controls, 24 framework controls) -- `apac-aus-ism-2024-june` — Australia - Information Security Manual (ISM) (June 2024) (336 SCF controls, 802 framework controls) -- `apac-aus-privacy-act-1998` — Australia - Privacy Act of 1998 (23 SCF controls, 12 framework controls) -- `apac-aus-privacy-principles-2026` — Australia - Privacy Principles (2026) (26 SCF controls, 13 framework controls) -- `apac-aus-ps-cps-230-2023` — Australia - Prudential Standard CPS 230 (2023) (41 SCF controls, 98 framework controls) -- `apac-aus-ps-cps-234-2019` — Australia - Prudential Standard CPS 234 (2019) (52 SCF controls, 38 framework controls) -- `apac-chn-csnip-2012` — China - Decision on Strengthening Network Information Protection (2012) (10 SCF controls, 4 framework controls) -- `apac-chn-cybersecurity-law-2017` — China - Cybersecurity Law (2017) (27 SCF controls, 34 framework controls) -- `apac-chn-data-security-law-2021` — China - Data Security Law (2021) (15 SCF controls, 24 framework controls) -- `apac-chn-pipl-2021` — China - Personal Information Protection Law (2021) (79 SCF controls, 100 framework controls) -- `apac-hkg-pdo-2022` — Hong Kong - Personal Data Ordinance (2022) (14 SCF controls, 14 framework controls) -- `apac-ind-dpdpa-2023` — India - DPDPA (2023) (41 SCF controls, 96 framework controls) -- `apac-ind-privacy-rules-2011` — India - Privacy Rules (2011) (12 SCF controls, 5 framework controls) -- `apac-ind-sebi-2024` — India - SEBI CSCRF (2024) (170 SCF controls, 129 framework controls) -- `apac-jpn-ismap` — Japan - Information System Security Management and Assessment Program (ISMAP) (249 SCF controls, 1312 framework controls) -- `apac-jpn-ppi-2020` — Japan - Act on the Protection of Personal Information (2020) (58 SCF controls, 134 framework controls) -- `apac-kor-pipa-2011` — South Korea - Personal Information Protection Act (PIPA) (2011) (37 SCF controls, 22 framework controls) -- `apac-mys-pdpa-2010` — Malaysia - Personal Data Protection Act (PDPA) (2010) (25 SCF controls, 12 framework controls) -- `apac-nzl-hisf-microsmall-2023` — New Zealand - HISF MicroSmall (2023) (32 SCF controls, 21 framework controls) -- `apac-nzl-hisf-mlhsp-2023` — New Zealand - HISF MLHSP (2023) (102 SCF controls, 150 framework controls) -- `apac-nzl-hisf-suppliers-2023` — New Zealand - HISF Guidance for Suppliers (2023) (101 SCF controls, 68 framework controls) -- `apac-nzl-ism-3-9` — New Zealand - Information Security Manual (ISM) (v3.9) (291 SCF controls, 1392 framework controls) -- `apac-nzl-privacy-act-2020` — New Zealand - Privacy Act (2020) (20 SCF controls, 121 framework controls) -- `apac-phl-dpa-2012` — Philippines - Data Privacy Act (DPA) (2012) (30 SCF controls, 16 framework controls) -- `apac-sgp-cyber-hygiene-practice-2019` — Singapore - Cyber Hygiene Practice (2019) (21 SCF controls, 13 framework controls) -- `apac-sgp-mas-trm-2021` — Singapore - Monitory Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines (2021) (214 SCF controls, 280 framework controls) -- `apac-sgp-pdpa-2012` — Singapore - Personal Data Protection Ac (PDPA) (2012) (30 SCF controls, 14 framework controls) -- `apac-twn-pdpa-2025` — Taiwan - Personal Data Protection Act (PDPA) (2025) (23 SCF controls, 8 framework controls) -- `emea-aut-fappd-2000` — Austria - Federal Act concerning the Protection of Personal Data (2000) (63 SCF controls, 12 framework controls) -- `emea-bel-act-8-1992` — Belgium - Act of 8 December 1992 (59 SCF controls, 10 framework controls) -- `emea-che-fadp-2025` — Switzerland - FADP (16 SCF controls, 9 framework controls) -- `emea-deu-bsrit-2017` — Germany - Banking Supervisory Requirements for IT (2017) (91 SCF controls, 93 framework controls) -- `emea-deu-c5-2020` — Germany - Cloud Computing Compliance Controls Catalogue (C5) (2020) (239 SCF controls, 121 framework controls) -- `emea-deu-fdpa-2017` — Germany - Federal Data Protection Act (2017) (18 SCF controls, 20 framework controls) -- `emea-esp-boe-a-2022-7191` — Spain - BOE-A-2022-7191 (72 SCF controls, 132 framework controls) -- `emea-esp-ccn-stic-825-2023` — Spain - ICT Security Guide CCN-STIC 825 (2023) (99 SCF controls, 75 framework controls) -- `emea-esp-decree-1720-2007` — Spain - Royal Decree 1720/2007 (17 SCF controls, 16 framework controls) -- `emea-esp-decree-311-2022` — Spain - Royal Decree 311/2022 (73 SCF controls, 128 framework controls) -- `emea-eu-ai-act-2024` — EU Artificial Intelligence Act (AI Act) (2024) (119 SCF controls, 279 framework controls) -- `emea-eu-cyber-resilience-act-2022` — EU Cyber Resilience Act (CRA) (2022) (18 SCF controls, 52 framework controls) -- `emea-eu-cyber-resilience-act-annexes-2022` — EU Cyber Resilience Act Annexes (CRA Annexes) (2022) (23 SCF controls, 117 framework controls) -- `emea-eu-dora-2023` — EU Digital Operational Resilience Act (DORA) (2023) (102 SCF controls, 241 framework controls) -- `emea-eu-eba-ict-srm-2025` — EU EBA Guidelines on ICT and Security Risk Management (2025) (148 SCF controls, 150 framework controls) -- `emea-eu-gdpr-2016` — EU General Data Protection Regulation (GDPR) (2016) (42 SCF controls, 227 framework controls) -- `emea-eu-nis2-2022` — EU NIS2 Directive (2022) (68 SCF controls, 30 framework controls) -- `emea-eu-nis2-annex-2024` — EU NIS2 Annex (2024) (223 SCF controls, 351 framework controls) -- `emea-gbr-caf-4-0` — UK - Cyber Assessment Framework (CAF) (v4.0) (66 SCF controls, 66 framework controls) -- `emea-gbr-cap-1850-2020` — UK - Cyber Assessment Framework for Aviation Guidance (CAP1850) (2020) (43 SCF controls, 14 framework controls) -- `emea-gbr-cyber-essentials-requirements-3-3` — UK - Cyber Essentials (v3.3) (26 SCF controls, 5 framework controls) -- `emea-gbr-def-stan-05-138-2024` — UK - Defstan 05-138 (2024) (213 SCF controls, 147 framework controls) -- `emea-gbr-def-stan-05-138-l0-2024` — UK - Defstan 05-138 (2024) - L0 (2 SCF controls, 3 framework controls) -- `emea-gbr-def-stan-05-138-l1-2024` — UK - Defstan 05-138 (2024) - L1 (159 SCF controls, 100 framework controls) -- `emea-gbr-def-stan-05-138-l2-2024` — UK - Defstan 05-138 (2024) - L2 (206 SCF controls, 138 framework controls) -- `emea-gbr-def-stan-05-138-l3-2024` — UK - Defstan 05-138 (2024) - L3 (212 SCF controls, 143 framework controls) -- `emea-gbr-dpa-1998` — UK - Data Protection Act (DPA) (1998) (10 SCF controls, 8 framework controls) -- `emea-grc-pirppd-1997` — Greece - Protection of Individuals with Regard to the Processing of Personal Data (1997) (17 SCF controls, 11 framework controls) -- `emea-hun-isdfi-2011` — Hungary - Informational Self-Determination and Freedom of Information (2011) (27 SCF controls, 15 framework controls) -- `emea-irl-dpa-2003` — Ireland - Data Protection Act (DPA) (2003) (25 SCF controls, 4 framework controls) -- `emea-isr-cmo-1-0` — Israel - Cybersecurity Methodology for an Organization v1.0 (393 SCF controls, 323 framework controls) -- `emea-isr-ppl-5741-1981` — Israel - Protection of Privacy Law, 5741 (1981) (22 SCF controls, 8 framework controls) -- `emea-ita-pdpc-2003` — Italy - Personal Data Protection Code (2003) (28 SCF controls, 18 framework controls) -- `emea-ken-pda-2019` — Kenya - Data Protection Act (DPA) (2019) (41 SCF controls, 237 framework controls) -- `emea-nga-dpr-2019` — Nigeria - Data Protection Regulation (DPR) (2019) (25 SCF controls, 107 framework controls) -- `emea-nor-pda-2018` — Norway - Personal Data Act (PDA) (2018) (23 SCF controls, 15 framework controls) -- `emea-pol-act-29-1997` — Poland - Act of 29 August 1997 on the Protection of Personal Data (29 SCF controls, 12 framework controls) -- `emea-qat-pdppl-2020` — Qatar - Personal Data Privacy Protection Law (PDPPL) (2020) (56 SCF controls, 46 framework controls) -- `emea-rus-federal-law-27-2006` — Russia - Federal Law of 27 (2006) (28 SCF controls, 15 framework controls) -- `emea-sau-cgiot-2024` — Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT-1:2024) (118 SCF controls, 81 framework controls) -- `emea-sau-cscc-1-2019` — Saudi Arabia - Critical Systems Cybersecurity Controls (CSCC – 1: 2019) (152 SCF controls, 107 framework controls) -- `emea-sau-ecc-1-2018` — Saudi Arabia - Essential Cybersecurity Controls (ECC – 1 : 2018) (190 SCF controls, 215 framework controls) -- `emea-sau-otcc-1-2022` — Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC -1: 2022) (198 SCF controls, 189 framework controls) +- `americas-arg-ppd-2018` — Argentina - Protection of Personal Data (2018) (78 SCF controls, 89 framework controls) +- `americas-bhs-dpa-2003` — Bahamas - Data Protection Act (DPA) (2003) (40 SCF controls, 370 framework controls) +- `americas-bmu-mba-coc-2020` — Bermuda - Bermuda Monetary Authority (BMA) Insurance Sector Operational Cyber Risk Management Code of Conduct (2020) (97 SCF controls, 84 framework controls) +- `americas-bra-lgpd-2018` — Brazil - General Data Protection Law (LGPD) (2018) (29 SCF controls, 161 framework controls) +- `americas-can-itsp-10-171-2025` — Canada - Protecting controlled information in non - Government of Canada systems and organizations (ITSP.10.171) (2025) (415 SCF controls, 279 framework controls) +- `americas-can-osfi-b13-2022` — Canada - OSFI B - 13 (2022) (150 SCF controls, 77 framework controls) +- `americas-can-osfi-self-assessment` — Canada - Office of the Superintendent of Financial Institutions Canada (OSFI) - Cyber Security Self - Assessment Guidance (0 SCF controls, 0 framework controls) +- `americas-can-osfi-self-assessment-2` — Canada - OSFI Cyber Security Self - Assessment Guidance (125 SCF controls, 57 framework controls) +- `americas-can-pipeda-2000` — Canada - Personal Information Protection and Electronic Documents Act (PIPEDA) (2000) (35 SCF controls, 68 framework controls) +- `americas-chl-act-19628-1999` — Chile - Act 19628 - Protection of Personal Data (1999) (12 SCF controls, 15 framework controls) +- `americas-col-law-1581-2012` — Colombia - Law 1581 (2012) (21 SCF controls, 60 framework controls) +- `americas-mex-fdpa-2010` — Mexico - Federal Law on Protection of Personal Data held by Private Parties (2010) (23 SCF controls, 70 framework controls) +- `apac-aus-cop-sitc-2020` — Australia - Code of Practice - Securing the Internet of Things for Consumers (2020) (35 SCF controls, 13 framework controls) +- `apac-aus-essential-8-2024` — Australia - Essential Eight maturity model and ISM mapping (2024) (37 SCF controls, 24 framework controls) +- `apac-aus-ism-2026-march` — Australia - Information Security Manual (ISM) (March 2026) (389 SCF controls, 1054 framework controls) +- `apac-aus-privacy-principles-2026` — Australia - Privacy Principles (2026) (24 SCF controls, 205 framework controls) +- `apac-aus-ps-cps-230-2023` — Australia - Prudential Standard CPS 230 - Operational Risk Management (2023) (69 SCF controls, 97 framework controls) +- `apac-aus-ps-cps-234-2019` — Australia - Prudential Standard CPS 234 Information Security (2019) (23 SCF controls, 37 framework controls) +- `apac-chn-csnip-2012` — China - Decision on Strengthening Network Information Protection (2012) (7 SCF controls, 7 framework controls) +- `apac-chn-cybersecurity-law-2017` — China - Cybersecurity Law of the People's Republic of China (2017) (27 SCF controls, 34 framework controls) +- `apac-chn-data-security-law-2021` — China - Data Security Law of the People's Republic of China (2021) (10 SCF controls, 7 framework controls) +- `apac-chn-pipl-2021` — China - Personal Information Protection Law of the People's Republic of China (2021) (37 SCF controls, 43 framework controls) +- `apac-hkg-pdo-2022` — Hong Kong - Personal Data Ordinance (2022) (18 SCF controls, 256 framework controls) +- `apac-ind-dpdpa-2023` — India Digital Personal Data Protection Act (2023) (41 SCF controls, 96 framework controls) +- `apac-ind-privacy-rules-2011` — India - Information Technology Rules (Privacy Rules) (2011) (13 SCF controls, 31 framework controls) +- `apac-ind-sebi-2024` — India - SEBI Cybersecurity and Cyber Resilience Framework (2024) (170 SCF controls, 129 framework controls) +- `apac-jpn-appi-2020` — Japan - Act on the Protection of Personal Information (2020) (34 SCF controls, 106 framework controls) +- `apac-jpn-ismap` — Japan - Information System Security Management and Assessment Program (ISMAP) (249 SCF controls, 1313 framework controls) +- `apac-kor-pipa-2011` — South Korea - Personal Information Protection Act (PIPA) (2011) (24 SCF controls, 150 framework controls) +- `apac-mys-bnm-rmit-2025` — Malaysia - Risk Management in Technology (RMiT) (2025) (197 SCF controls, 107 framework controls) +- `apac-mys-pdpa-2010` — Malaysia - Personal Data Protection Act (PDPA) (2010) (19 SCF controls, 213 framework controls) +- `apac-nzl-hisf-microsmall-2023` — New Zealand - HISF MicroSmall (2023) (102 SCF controls, 150 framework controls) +- `apac-nzl-hisf-mlhsp-2023` — New Zealand - HISF MLHSP (2023) (0 SCF controls, 0 framework controls) +- `apac-nzl-hisf-suppliers-2023` — New Zealand - HISO 10029:2024 NZ Health Information Security Framework Guidance for Suppliers (101 SCF controls, 68 framework controls) +- `apac-nzl-ism-3-9` — New Zealand - Information Security Manual (ISM) v3.9 (289 SCF controls, 1383 framework controls) +- `apac-nzl-privacy-act-2020` — New Zealand - Privacy Act (2020) (20 SCF controls, 160 framework controls) +- `apac-phl-dpa-2012` — Philippines - Data Privacy Act (DPA) (2012) (16 SCF controls, 61 framework controls) +- `apac-sgp-cyber-hygiene-practice-2019` — Singapore - Cyber Hygiene Practice (2019) (17 SCF controls, 11 framework controls) +- `apac-sgp-mas-trm-2021` — Singapore - Monitory Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines (2021) (219 SCF controls, 279 framework controls) +- `apac-sgp-pdpa-2012` — Singapore - Personal Data Protection Ac (PDPA) (2012) (33 SCF controls, 115 framework controls) +- `apac-twn-pdpa-2025` — Taiwan - Personal Data Protection Act (PDPA) (2025) (9 SCF controls, 61 framework controls) +- `emea-aut-dpa-2018` — Austria - Data Protection Act (2018) (28 SCF controls, 93 framework controls) +- `emea-bel-act-30-2018` — Belgium - Act of 30 July 2018 (27 SCF controls, 105 framework controls) +- `emea-che-fadp-2025` — Switzerland - Federal Act on Data Protection (FADP) (2025) (25 SCF controls, 104 framework controls) +- `emea-deu-bsrit-2017` — Germany - Banking Supervisory Requirements for IT (2017) (91 SCF controls, 88 framework controls) +- `emea-deu-c5-2020` — Germany - Cloud Computing Compliance Controls Catalogue (C5) (2020) (207 SCF controls, 282 framework controls) +- `emea-deu-fdpa-2017` — Germany - Federal Data Protection Act (2017) (46 SCF controls, 255 framework controls) +- `emea-esp-ccn-stic-825-2026` — Spain - ICT Security Guide CCN - STIC 825 (2026) (234 SCF controls, 70 framework controls) +- `emea-esp-decree-311-2022` — Spain - Royal Decree 311/2022 (72 SCF controls, 104 framework controls) +- `emea-eu-ai-act-2024` — EU - European Union Artificial Intelligence Act (Regulation (EU) 2024/1689) (119 SCF controls, 279 framework controls) +- `emea-eu-cyber-resilience-act-2024` — EU - European Union Cyber Resilience Act (2024) (35 SCF controls, 96 framework controls) +- `emea-eu-cyber-resilience-act-annex-i-2024` — EU - European Union Cyber Resilience Act - Annex I (2024) (16 SCF controls, 24 framework controls) +- `emea-eu-dora-2023` — EU - Digital Operational Resilience Act (2023) (102 SCF controls, 241 framework controls) +- `emea-eu-eba-ict-srm-2025` — EU - European Banking Authority Guidelines on ICT and Security Risk Management (2025) (153 SCF controls, 156 framework controls) +- `emea-eu-gdpr-2016` — EU - European Union General Data Protection Regulation (2016) (42 SCF controls, 227 framework controls) +- `emea-eu-nis2-2022` — EU - European Union Agency for Cybersecurity NIS2 Directive (EU) 2022/2555) (68 SCF controls, 30 framework controls) +- `emea-eu-nis2-annex-2024` — EU - European Union Agency for Cybersecurity NIS2 Annex (2024) (223 SCF controls, 351 framework controls) +- `emea-eu-psd2-2015` — EU - Second Payment Services Directive (PSD2) (2015) (11 SCF controls, 22 framework controls) +- `emea-gbr-caf-4-0` — UK - Cyber Assessment Framework (CAF) v4.0 (66 SCF controls, 66 framework controls) +- `emea-gbr-cap-1850-2020` — UK - Cyber Assessment Framework for Aviation Guidance (CAP1850) (2020) (36 SCF controls, 14 framework controls) +- `emea-gbr-cyber-essentials-requirements-3-3` — UK - Cyber Essentials: Requirements for IT Infrastructure v3.3 (27 SCF controls, 32 framework controls) +- `emea-gbr-def-stan-05-138-2024` — UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) (213 SCF controls, 147 framework controls) +- `emea-gbr-def-stan-05-138-l0-2024` — UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L0 (2 SCF controls, 3 framework controls) +- `emea-gbr-def-stan-05-138-l1-2024` — UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L1 (159 SCF controls, 100 framework controls) +- `emea-gbr-def-stan-05-138-l2-2024` — UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L2 (206 SCF controls, 138 framework controls) +- `emea-gbr-def-stan-05-138-l3-2024` — UK - Ministry of Defence Standard (DEFSTAN) 05 - 138 (2024) - L3 (212 SCF controls, 143 framework controls) +- `emea-gbr-dpa-2018` — UK - Data Protection Act (DPA) (2018) (25 SCF controls, 348 framework controls) +- `emea-grc-pirppd-1997` — Greece - Protection of Individuals with Regard to the Processing of Personal Data (2472/1997) (26 SCF controls, 73 framework controls) +- `emea-hun-act-cxii-2011` — Hungary - Act CXII of 2011 (35 SCF controls, 100 framework controls) +- `emea-irl-dpa-2018` — Ireland - Data Protection Act (DPA) (2018) (17 SCF controls, 46 framework controls) +- `emea-isr-cmo-2-0` — Ireland - Cybersecurity Methodology for an Organization (CMO) v2.0 (67 SCF controls, 48 framework controls) +- `emea-isr-ppl-5741-2025` — Israel - Protection of Privacy Law, 5741 (2025) (13 SCF controls, 18 framework controls) +- `emea-ita-pdpc-2018` — Italy - Personal Data Protection Code (2018) (13 SCF controls, 45 framework controls) +- `emea-ken-pda-2019` — Kenya - Data Protection Act (DPA) (2019) (42 SCF controls, 196 framework controls) +- `emea-nga-dpr-2019` — Nigeria - Data Protection Regulation (DPR) (2019) (32 SCF controls, 111 framework controls) +- `emea-nor-pda-2018` — Norway - Personal Data Act (PDA) (2018) (4 SCF controls, 9 framework controls) +- `emea-pol-act-10-2018` — Poland - Act of 10 May 2018 on the Protection of Personal Data (2 SCF controls, 3 framework controls) +- `emea-qat-pdppl-2020` — Qatar - Personal Data Privacy Protection Law (PDPPL) (2020) (33 SCF controls, 40 framework controls) +- `emea-rus-152-fz-2025` — Russia - Federal Law No. 152 - FZ (2025) (17 SCF controls, 21 framework controls) +- `emea-sau-cgiot-2024` — Saudi Arabia - Cybersecurity Guidelines for Internet of Things (CGIoT - 1:2024) (118 SCF controls, 81 framework controls) +- `emea-sau-cscc-1-2019` — Saudi Arabia - Critical Systems Cybersecurity Controls (CSCC – 1: 2019) (172 SCF controls, 104 framework controls) +- `emea-sau-ecc-1-2018` — Saudi Arabia - Essential Cybersecurity Controls (ECC – 1 : 2018) (169 SCF controls, 199 framework controls) +- `emea-sau-otcc-1-2022` — Saudi Arabia - Operational Technology Cybersecurity Controls (OTCC - 1: 2022) (160 SCF controls, 168 framework controls) - `emea-sau-pdpl-2023` — Saudi Arabia - Personal Data Protection Law (PDPL) (2023) (36 SCF controls, 70 framework controls) -- `emea-sau-sacs-002-2022` — Saudi Arabia - SACS-002 Third Party Cybersecurity Standard (2022) (185 SCF controls, 92 framework controls) -- `emea-sau-sama-csf-1-2017` — Saudi Arabia - SAMA CSF Version 1.0 (2017) (50 SCF controls, 36 framework controls) -- `emea-srb-act-9-2018` — Serbia - Act of 9 November 2018 on Personal Data Protection (56 SCF controls, 205 framework controls) -- `emea-tur-lppd-2016` — Turkey - Law on the Protection of Personal Data (LPPD) (2016) (17 SCF controls, 10 framework controls) +- `emea-sau-sacs-002-2022` — Saudi Arabia - SACS - 002 Third Party Cybersecurity Standard (2022) (101 SCF controls, 124 framework controls) +- `emea-sau-sama-csf-1-2017` — Saudi Arabia - Saudi Arabian Monetary Authority (SAMA) Cyber Security Framework Version 1.0 (2017) (91 SCF controls, 482 framework controls) +- `emea-srb-act-9-2018` — Serbia - Act of 9 November 2018 on Personal Data Protection (Official Gazette No. 87/18) (31 SCF controls, 330 framework controls) +- `emea-tur-lppd-2016` — Turkey - Law on the Protection of Personal Data (LPPD) (2016) (7 SCF controls, 103 framework controls) - `emea-uae-niaf-2023` — UAE - National Information Assurance Framework (NIAF) (2023) (20 SCF controls, 15 framework controls) -- `emea-us-psd2-2015` — EU Second Payment Services Directive (PSD2) (2015) (30 SCF controls, 10 framework controls) -- `emea-zaf-popia-2013` — South Africa - Protection of Personal Information Act (POPIA) (2013) (101 SCF controls, 41 framework controls) -- `general-aicpa-pmf-2020` — AICPA Privacy Management Framework (PMF) (2020) (109 SCF controls, 123 framework controls) -- `general-aicpa-tsc-2017` — Trust Services Criteria (TSC) (2017) (412 SCF controls, 399 framework controls) -- `general-apec-privacy-framework-2015` — APEC Privacy Framework (2015) (14 SCF controls, 25 framework controls) -- `general-bsi-200-1-1-0` — Standard 200-1 (v1.0) (35 SCF controls, 22 framework controls) -- `general-cis-csc-8-1` — Critical Security Controls (CSC) (v8.1) (234 SCF controls, 166 framework controls) -- `general-cis-csc-8-1-ig1` — Critical Security Controls (CSC) (v8.1) - IG1 (104 SCF controls, 56 framework controls) -- `general-cis-csc-8-1-ig2` — Critical Security Controls (CSC) (v8.1) - IG2 (208 SCF controls, 126 framework controls) -- `general-cis-csc-8-1-ig3` — Critical Security Controls (CSC) (v8.1) - IG3 (230 SCF controls, 148 framework controls) +- `emea-zaf-popia-2013` — South Africa - Protection of Personal Information Act (POPIA) (2013) (23 SCF controls, 242 framework controls) +- `general-aicpa-pmf-2020` — American Institute of Certified Public Accountants (AICPA) Privacy Management Framework (PMF) (2020) (109 SCF controls, 123 framework controls) +- `general-aicpa-tsc-2017` — American Institute of Certified Public Accountants (AICPA) Trust Services Criteria (2017) (412 SCF controls, 399 framework controls) +- `general-apec-privacy-framework-2015` — Asia - Pacific Economic Cooperation (APEC) Privacy Framework (2015) (14 SCF controls, 25 framework controls) +- `general-bsi-200-1-1-0` — Bundesamt für Sicherheit in der Informationstechnik (BSI) - Standard 200 - 1 (v1.0) (35 SCF controls, 22 framework controls) +- `general-cis-csc-8-1` — Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 (234 SCF controls, 171 framework controls) +- `general-cis-csc-8-1-ig1` — Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG1 (104 SCF controls, 56 framework controls) +- `general-cis-csc-8-1-ig2` — Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG2 (208 SCF controls, 130 framework controls) +- `general-cis-csc-8-1-ig3` — Center for Internet Security (CIS) Critical Security Controls (CSC) version 8.1 - IG3 (230 SCF controls, 153 framework controls) - `general-cobit-2019` — Control Objectives for Information and Related Technologies (COBIT) (2019) (190 SCF controls, 230 framework controls) - `general-coso-2013` — Committee of Sponsoring Organizations (COSO) (2013) (104 SCF controls, 17 framework controls) -- `general-cr-cmm-2026` — Cyber Resilience Capability Maturity Model (CR-CMM) (2026) (46 SCF controls, 40 framework controls) -- `general-csa-cmm-4-1-0` — Cloud Controls Matrix (CCM) (v4.1.0) (291 SCF controls, 207 framework controls) -- `general-csa-iot-2` — IoT Security Controls Framework (v2) (253 SCF controls, 155 framework controls) -- `general-govramp` — GovRAMP (441 SCF controls, 383 framework controls) -- `general-govramp-core` — GovRAMP Core (86 SCF controls, 60 framework controls) -- `general-govramp-high` — GovRAMP High (441 SCF controls, 383 framework controls) -- `general-govramp-low` — GovRAMP Low (166 SCF controls, 114 framework controls) -- `general-govramp-low-plus` — GovRAMP Low+ (230 SCF controls, 173 framework controls) -- `general-govramp-mod` — GovRAMP Moderate (347 SCF controls, 290 framework controls) -- `general-iec-62443-2-1-2024` — IEC 62443-2-1 (2024) (112 SCF controls, 119 framework controls) -- `general-iec-62443-3-3-2013` — IEC 62443-3-3 (2013) (80 SCF controls, 111 framework controls) -- `general-iec-62443-4-1-2018` — IEC 62443-4-1 (2018) (25 SCF controls, 186 framework controls) -- `general-iec-62443-4-2-2019` — IEC 62443-4-2 (2019) (89 SCF controls, 169 framework controls) -- `general-iec-tr-60601-4-5-2021` — IEC TR 60601-4-5 (2021) (26 SCF controls, 37 framework controls) +- `general-cr-cmm-2026` — Cyber Resilience Capability Maturity Model (CR - CMM) (2026) (46 SCF controls, 40 framework controls) +- `general-csa-cmm-4-1-0` — Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) v4.1.0 (291 SCF controls, 207 framework controls) +- `general-csa-iot-2` — Cloud Security Alliance (CSA) Internet of Things Security Controls Framework v2 (253 SCF controls, 155 framework controls) +- `general-govramp` — Government Risk and Authorization Management Program (GovRAMP) (441 SCF controls, 383 framework controls) +- `general-govramp-core` — Government Risk and Authorization Management Program (GovRAMP) - Core Controls (86 SCF controls, 60 framework controls) +- `general-govramp-high` — Government Risk and Authorization Management Program (GovRAMP) - High (441 SCF controls, 383 framework controls) +- `general-govramp-low` — Government Risk and Authorization Management Program (GovRAMP) - Low (166 SCF controls, 114 framework controls) +- `general-govramp-low-plus` — Government Risk and Authorization Management Program (GovRAMP) - Low+ (230 SCF controls, 173 framework controls) +- `general-govramp-mod` — Government Risk and Authorization Management Program (GovRAMP) - Moderate (347 SCF controls, 290 framework controls) +- `general-iec-62443-2-1-2024` — International Electrotechnical Commission (IEC) 62443 - 2 - 1:2024 - Security for industrial automation and control systems - Part 2 - 1: Security program requirements for IACS asset owners (112 SCF controls, 119 framework controls) +- `general-iec-62443-3-3-2013` — International Electrotechnical Commission (IEC) 62443 - 3 - 3:2013 - Industrial communication networks - Network and system security - Part 3 - 3: System security requirements and security levels (80 SCF controls, 111 framework controls) +- `general-iec-62443-4-1-2018` — International Electrotechnical Commission (IEC) 62443 - 4 - 1:2018 - Security for industrial automation and control systems - Part 4 - 1: Secure product development lifecycle requirements (25 SCF controls, 186 framework controls) +- `general-iec-62443-4-2-2019` — International Electrotechnical Commission 62443 - 4 - 2 Ed. 1.0 b:2019 - Security for industrial automation and control systems - Part 4 - 2: Technical security requirements for IACS components (89 SCF controls, 169 framework controls) +- `general-iec-tr-60601-4-5-2021` — International Electrotechnical Commission (IEC) Technical Report 60601 - 4 - 5:2021 - Medical electrical equipment - Part 4 - 5: Guidance and interpretation - Safety - related technical security specifications (26 SCF controls, 37 framework controls) - `general-imo-maritime-cyber-risk-management-2025` — International Maritime Organization (IMO) Guidelines on Maritime Cyber Risk Management (2025) (75 SCF controls, 35 framework controls) -- `general-iso-21434-2021` — ISO 21434 (2021) (51 SCF controls, 232 framework controls) -- `general-iso-22301-2019` — ISO 22301 (2019) (36 SCF controls, 259 framework controls) -- `general-iso-27001-2022` — ISO 27001 (2022) (51 SCF controls, 148 framework controls) -- `general-iso-27002-2022` — ISO 27002 (2022) (316 SCF controls, 96 framework controls) -- `general-iso-27017-2015` — ISO 27017 (2015) (224 SCF controls, 118 framework controls) -- `general-iso-27018-2025` — ISO 27018 (2025) (322 SCF controls, 108 framework controls) -- `general-iso-27701-2025` — ISO 27701 (2025) (59 SCF controls, 90 framework controls) -- `general-iso-29100-2024` — ISO 29100 (2024) (43 SCF controls, 11 framework controls) -- `general-iso-31000-2018` — ISO 31000 (2018) (53 SCF controls, 27 framework controls) -- `general-iso-31010-2009` — ISO 31010 (2009) (31 SCF controls, 32 framework controls) -- `general-iso-42001-2023` — ISO 42001 (2023) (149 SCF controls, 140 framework controls) -- `general-mitre-att&ck-16-1` — MITRE ATT&CK (v16.1) (108 SCF controls, 511 framework controls) -- `general-mpa-csbp-5-3-1` — Content Security Best Practices Common Guidelines (v5.3.1) (232 SCF controls, 81 framework controls) -- `general-naic-insurance-data-security-model-law-668-2017` — Insurance Data Security Model Law 668 (2017) (58 SCF controls, 85 framework controls) -- `general-nist-100-1-ai-rmf` — NIST AI 100-1 (AI RMF 1.0) (158 SCF controls, 91 framework controls) -- `general-nist-600-1-gen-ai-profile` — NIST AI 600-1 (139 SCF controls, 250 framework controls) -- `general-nist-800-160-vol-2-r1` — NIST SP 800-160 (Vol 2, Rev 1) (204 SCF controls, 196 framework controls) -- `general-nist-800-161-r1` — NIST SP 800-161 R1 UDP1 (341 SCF controls, 308 framework controls) -- `general-nist-800-161-r1-cscrm` — NIST SP 800-161 R1 UDP1 - C-SCRM Baseline (132 SCF controls, 95 framework controls) -- `general-nist-800-161-r1-flowdown` — NIST SP 800-161 R1 UDP1 - Flow Down Baseline (107 SCF controls, 69 framework controls) -- `general-nist-800-161-r1-level-1` — NIST SP 800-161 R1 UDP1 - Level 1 Baseline (95 SCF controls, 76 framework controls) -- `general-nist-800-161-r1-level-2` — NIST SP 800-161 R1 UDP1 - Level 2 Baseline (273 SCF controls, 236 framework controls) -- `general-nist-800-161-r1-level-3` — NIST SP 800-161 R1 UDP1 - Level 3 Baseline (284 SCF controls, 251 framework controls) -- `general-nist-800-171-r2` — NIST SP 800-171 R2 (251 SCF controls, 172 framework controls) -- `general-nist-800-171-r3` — NIST SP 800-171 R3 (407 SCF controls, 275 framework controls) -- `general-nist-800-171a` — NIST SP 800-171A (134 SCF controls, 320 framework controls) -- `general-nist-800-171a-r3` — NIST SP 800-171A R3 (215 SCF controls, 508 framework controls) -- `general-nist-800-172` — NIST SP 800-172 (74 SCF controls, 35 framework controls) -- `general-nist-800-207` — NIST SP 800-207 (93 SCF controls, 7 framework controls) -- `general-nist-800-218` — NIST SP 800-218 (59 SCF controls, 60 framework controls) -- `general-nist-800-37-r2` — NIST SP 800-37 R2 (45 SCF controls, 47 framework controls) -- `general-nist-800-39` — NIST SP 800-39 (17 SCF controls, 16 framework controls) -- `general-nist-800-53-r4` — NIST SP 800-53 R4 (653 SCF controls, 682 framework controls) -- `general-nist-800-53-r5-2` — NIST SP 800-53 R5 (777 SCF controls, 810 framework controls) -- `general-nist-800-53-r5-2-high` — NIST SP 800-53 R5 - High Baseline (89 SCF controls, 83 framework controls) -- `general-nist-800-53-r5-2-low` — NIST SP 800-53 R5 - Low Baseline (202 SCF controls, 149 framework controls) -- `general-nist-800-53-r5-2-mod` — NIST SP 800-53 R5 - Moderate Baseline (157 SCF controls, 138 framework controls) -- `general-nist-800-53-r5-2-privacy` — NIST SP 800-53 R5 - Privacy Baseline (346 SCF controls, 236 framework controls) -- `general-nist-800-66-r2` — NIST SP 800-66 R2 (112 SCF controls, 22 framework controls) -- `general-nist-800-82-r3` — NIST SP 800-82 R3 (777 SCF controls, 810 framework controls) -- `general-nist-800-82-r3-high` — NIST SP 800-82 R3 - High OT Overlay (467 SCF controls, 418 framework controls) -- `general-nist-800-82-r3-low` — NIST SP 800-82 R3 - Low OT Overlay (251 SCF controls, 194 framework controls) -- `general-nist-800-82-r3-mod` — NIST SP 800-82 R3 - Moderate OT Overlay (390 SCF controls, 337 framework controls) -- `general-nist-csf-2-0` — NIST Cybersecurity Framework (v2.0) (250 SCF controls, 134 framework controls) -- `general-nist-privacy-framework-1-0` — NIST Privacy Framework (v1.0) (152 SCF controls, 122 framework controls) -- `general-oecd-privacy-principles-2010` — OECD Privacy Principles (2010) (14 SCF controls, 17 framework controls) -- `general-owasp-top-10-2025` — OWASP Top 10 (2025) (139 SCF controls, 10 framework controls) -- `general-pci-dss-4-0-1` — Payment Card Industry Data Security Standard (PCI DSS) (v4.01) (371 SCF controls, 351 framework controls) -- `general-pci-dss-4-0-1-saq-a` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ A (v4.0.1) (71 SCF controls, 29 framework controls) -- `general-pci-dss-4-0-1-saq-a-ep` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ A-EP (v4.0.1) (239 SCF controls, 139 framework controls) -- `general-pci-dss-4-0-1-saq-b` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ B (v4.0.1) (58 SCF controls, 27 framework controls) -- `general-pci-dss-4-0-1-saq-b-ip` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ B-IP (v4.0.1) (121 SCF controls, 50 framework controls) -- `general-pci-dss-4-0-1-saq-c` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ C (v4.0.1) (227 SCF controls, 124 framework controls) -- `general-pci-dss-4-0-1-saq-c-vt` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ C-VT (v4.0.1) (115 SCF controls, 54 framework controls) -- `general-pci-dss-4-0-1-saq-d-merchant` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Merchant (v4.0.1) (322 SCF controls, 233 framework controls) -- `general-pci-dss-4-0-1-saq-d-service-provider` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ D Service Provider (v4.0.1) (339 SCF controls, 257 framework controls) -- `general-pci-dss-4-0-1-saq-p2pe` — Payment Card Industry Data Security Standard (PCI DSS) - SAQ P2PE (v4.0.1) (47 SCF controls, 21 framework controls) -- `general-scf-dpmp-2025` — Data Privacy Management Principle (DPMP) (2025) (218 SCF controls, 83 framework controls) -- `general-shared-assessments-sig-2025` — SIG (2025) (128 SCF controls, 65 framework controls) -- `general-sparta` — SPARTA Countermeasures (79 SCF controls, 53 framework controls) -- `general-swift-cscf-2025` — SWIFT Customer Security Controls Framework (2025) (164 SCF controls, 32 framework controls) -- `general-tisax-6-0-3` — TISAX ISA (6.0.3) (154 SCF controls, 73 framework controls) -- `general-ul-2900-1-2017` — UL 2900-1 (2017) (23 SCF controls, 143 framework controls) -- `general-ul-2900-2-2-2016` — UL 2900-2-2 (2016) (20 SCF controls, 57 framework controls) -- `general-un-155-2021` — UN Regulation No. 155 (2021) (57 SCF controls, 55 framework controls) -- `general-un-ece-wp-29-2020` — UNECE WP.29 (2020) (57 SCF controls, 54 framework controls) -- `usa-federal-cms-marse-2-0` — MARS-E Document Suite (2.0) (391 SCF controls, 1286 framework controls) -- `usa-federal-dhs-cisa-cpg-2-0` — CISA Cross-Sector Cybersecurity Performance Goals (CPG) (2.0) (126 SCF controls, 38 framework controls) -- `usa-federal-dhs-cisa-ssdaf-2024` — CISA Secure Software Development Attestation Form (SSDAF) (2024) (41 SCF controls, 15 framework controls) -- `usa-federal-dhs-cisa-tic-3-0` — CISA Trusted Internet Connections 3.0 Security Capabilities Catalog (TIC 3.0) (148 SCF controls, 117 framework controls) -- `usa-federal-doc-data-privacy-framework-2023` — Data Privacy Framework (2023) (31 SCF controls, 74 framework controls) -- `usa-federal-doe-c2m2-2-1` — Cybersecurity Capability Maturity Model (C2M2) (v2.1) (224 SCF controls, 356 framework controls) -- `usa-federal-dow-cert-rmm-1-2` — CERT-RMM (v1.2) (85 SCF controls, 753 framework controls) -- `usa-federal-dow-cmmc-2-level-1` — Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1 (52 SCF controls, 15 framework controls) -- `usa-federal-dow-cmmc-2-level-1-aos` — Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 1 Assessment Objectives (16 SCF controls, 59 framework controls) -- `usa-federal-dow-cmmc-2-level-2` — Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 2 (198 SCF controls, 110 framework controls) -- `usa-federal-dow-cmmc-2-level-3` — Cybersecurity Maturity Model Certification (CMMC) 2.0 - Level 3 (55 SCF controls, 24 framework controls) -- `usa-federal-dow-dfars-252-204-7012` — DFARS 252.204-7012 (19 SCF controls, 20 framework controls) -- `usa-federal-dow-safeguarding-nnpi-2010` — Safeguarding of NNPI (2010) (32 SCF controls, 68 framework controls) -- `usa-federal-dow-zt-roadmap-1-1` — Department of War (DoW) - Zero Trust Execution Roadmap (v1.1) (117 SCF controls, 190 framework controls) -- `usa-federal-dow-zta-reference-architecture-2-0` — Department of War (DoW) - Zero Trust Reference Architecture (v2) (39 SCF controls, 28 framework controls) -- `usa-federal-eo-14028` — Executive Order 14028 - Improving the Nation's Cybersecurity (43 SCF controls, 16 framework controls) -- `usa-federal-far-52-204-21` — FAR 52.204-21 (59 SCF controls, 17 framework controls) -- `usa-federal-far-52-204-25` — FAR 52.204-25 (NDAA Section 889) (2 SCF controls, 5 framework controls) -- `usa-federal-far-52-204-27` — FAR 52.204-27 (3 SCF controls, 2 framework controls) -- `usa-federal-fbi-cjis-6-0` — Criminal Justice Information Services (CJIS) Security Policy (v6.0) (365 SCF controls, 319 framework controls) -- `usa-federal-fda-21-cfr-part-11-2025` — Food & Drug Administration (FDA) 21 CFR Part 11 (2025) (62 SCF controls, 28 framework controls) -- `usa-federal-gsa-fedramp-5-high` — FedRAMP R5 - High Baseline (561 SCF controls, 490 framework controls) -- `usa-federal-gsa-fedramp-5-li-saas` — FedRAMP R5 - Li-SAAS Baseline (383 SCF controls, 269 framework controls) -- `usa-federal-gsa-fedramp-5-low` — FedRAMP R5 - Low Baseline (383 SCF controls, 269 framework controls) -- `usa-federal-gsa-fedramp-5-mod` — FedRAMP R5 - Moderate Baseline (491 SCF controls, 410 framework controls) -- `usa-federal-hhs-45-cfr-155-260-2016` — HHS § 155.260 (2016) (36 SCF controls, 44 framework controls) -- `usa-federal-irs-1075-2021` — IRS 1075 (2021) (442 SCF controls, 743 framework controls) -- `usa-federal-law-coppa-2024` — Children's Online Privacy Protection Act (COPPA) (2024) (10 SCF controls, 8 framework controls) -- `usa-federal-law-facta-fcra-2023` — Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023) (3 SCF controls, 6 framework controls) -- `usa-federal-law-ferpa-2010` — Family Educational Rights and Privacy Act (FERPA) (2010) (5 SCF controls, 27 framework controls) -- `usa-federal-law-ftc-act` — Federal Trade Commission (FTC) Act (16 SCF controls, 1 framework controls) -- `usa-federal-law-glba-cfr-314-2023` — Gramm Leach Bliley Act (GLBA) (2023) (70 SCF controls, 52 framework controls) -- `usa-federal-law-hipaa-security-rule-2013` — HIPAA Security Rule (2013) (136 SCF controls, 87 framework controls) -- `usa-federal-law-hipaa-simplification-2013` — HIPAA Administrative Simplification (2013) (170 SCF controls, 576 framework controls) -- `usa-federal-law-sox-2002` — SOX (2002) (4 SCF controls, 17 framework controls) -- `usa-federal-nerc-cip-2024` — NERC Critical Infrastructure Protection (CIP) (2024) (122 SCF controls, 204 framework controls) -- `usa-federal-nispom-2020` — National Industrial Security Program Operating Manual (NISPOM) (2020) (35 SCF controls, 226 framework controls) -- `usa-federal-omb-fipps-1973` — US Fair Information Practice Principles (FIPPs) (1973) (30 SCF controls, 8 framework controls) -- `usa-federal-sec-cybersecurity-rule-2023` — SEC Cybersecurity Rule (2023) (40 SCF controls, 15 framework controls) -- `usa-federal-sro-fca-crm-2023` — Farm Credit Administration (FCA) Cyber Risk Management (2023) (81 SCF controls, 34 framework controls) -- `usa-federal-sro-finra` — FINRA Cybersecurity Rules (17 SCF controls, 39 framework controls) -- `usa-federal-tsa-security-directive-1580-82-2022-01` — TSA Security Directive 1580/82-2022-01 (60 SCF controls, 68 framework controls) -- `usa-state-ak-pipa-2009` — Alaska Personal Information Protection Act (PIPA) (2009) (5 SCF controls, 25 framework controls) -- `usa-state-ca-ccpa-cpra-2026` — California Consumer Privacy Act (CCPA) (2026) (258 SCF controls, 623 framework controls) -- `usa-state-ca-sb1386-2002` — California SB1386 (2002) (4 SCF controls, 6 framework controls) -- `usa-state-ca-sb327-2018` — California SB327 (2018) (3 SCF controls, 7 framework controls) -- `usa-state-co-privacy-act-2021` — Colorado Privacy Act (2021) (23 SCF controls, 52 framework controls) -- `usa-state-il-bipa-2008` — Illinois Biometric Information Privacy Act (BIPA) (2008) (6 SCF controls, 12 framework controls) -- `usa-state-il-ipa-2009` — Illinois Identity Protection Act (IPA) (2009) (12 SCF controls, 33 framework controls) -- `usa-state-il-pipa-2006` — Illinois Personal Information Protection Act (PIPA) (2006) (10 SCF controls, 53 framework controls) -- `usa-state-ma-201-cmr-17-2008` — Massachusetts 201 CMR 17.00 (2008) (53 SCF controls, 37 framework controls) -- `usa-state-nv-regulation-5-2024` — Nevada Operation of Gaming Establishment (NOGE) Regulation 5.260 (2024) (20 SCF controls, 11 framework controls) -- `usa-state-nv-sb220-2019` — Nevada SB220 (2019) (3 SCF controls, 4 framework controls) -- `usa-state-ny-dfs-23-nycrr500-2023-amd2` — New York Department of Financial Services 23NYCRR Part 500 (2023 Amendment 2) (156 SCF controls, 145 framework controls) -- `usa-state-ny-shield-act-2019` — New York SHIELD Act (SB S5575B) (2019) (28 SCF controls, 45 framework controls) -- `usa-state-or-cpa-2023` — Oregon Consumer Privacy Act (SB 619) (2023) (34 SCF controls, 75 framework controls) -- `usa-state-or-ors-646a-2025` — Oregon Consumer Information Protection Act (ORS 646A) (2025) (24 SCF controls, 97 framework controls) -- `usa-state-tn-tipa-2025` — Tennessee Information Protection Act (TIPA) (2025) (29 SCF controls, 76 framework controls) -- `usa-state-tx-bc521-2009` — Texas Identity Theft Enforcement and Protection Act (BC521) (2009) (5 SCF controls, 27 framework controls) -- `usa-state-tx-cdpa-2025` — Texas Consumer Data Protection Act (2025) (28 SCF controls, 89 framework controls) -- `usa-state-tx-dir-security-control-standards-catalog-2-2` — Texas DIR Security Control Standards Catalog (v2.2) (238 SCF controls, 228 framework controls) -- `usa-state-tx-sb2610-2025` — Texas Safe Harbor Law (SB2610) (2025) (6 SCF controls, 33 framework controls) -- `usa-state-tx-sb820-2019` — Texas SB820 (2019) (4 SCF controls, 7 framework controls) -- `usa-state-tx-txramp-2-0-level-1` — TX-RAMP 2.0 - Level 1 (173 SCF controls, 117 framework controls) -- `usa-state-tx-txramp-2-0-level-2` — TX-RAMP 2.0 - Level 2 (285 SCF controls, 223 framework controls) -- `usa-state-va-cdpa-2023` — Virginia Consumer Data Protection Act (2023) (44 SCF controls, 64 framework controls) -- `usa-state-vt-act-171-2018` — Vermont Data Broker Registration Act (Act 171 of 2018) (35 SCF controls, 61 framework controls) +- `general-iso-21434-2021` — ISO/SAE 21434:2021 - Road vehicles — Cybersecurity engineering (51 SCF controls, 232 framework controls) +- `general-iso-22301-2019` — ISO/IEC 22301:2019 - Security and resilience - Business continuity management systems - Requirements (36 SCF controls, 259 framework controls) +- `general-iso-27001-2022` — ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements (51 SCF controls, 148 framework controls) +- `general-iso-27002-2022` — ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls (316 SCF controls, 96 framework controls) +- `general-iso-27017-2015` — ISO/IEC 27017:2015 - Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services (224 SCF controls, 118 framework controls) +- `general-iso-27018-2025` — ISO/IEC 27018:2025 - Information security, cybersecurity and privacy protection - Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors (322 SCF controls, 108 framework controls) +- `general-iso-27701-2025` — ISO/IEC 27701:2025 - Information security, cybersecurity and privacy protection - Privacy information management systems - Requirements and guidance (59 SCF controls, 90 framework controls) +- `general-iso-29100-2024` — ISO/IEC 29100:2024 - Information technology - Security techniques - Privacy framework (43 SCF controls, 11 framework controls) +- `general-iso-31000-2018` — ISO/IEC 31000:2018 - Risk management - Guidelines (53 SCF controls, 27 framework controls) +- `general-iso-31010-2009` — ISO/IEC 31010:2019 - Risk management - Risk assessment techniques (31 SCF controls, 32 framework controls) +- `general-iso-42001-2023` — ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system (149 SCF controls, 140 framework controls) +- `general-mitre-att_ck-16-1` — MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) - NIST 800 - 53 mappings (108 SCF controls, 511 framework controls) +- `general-mpa-csbp-5-3-1` — Motion Picture Association (MPA) Content Security Best Practices Common Guidelines v5.3.1 (232 SCF controls, 81 framework controls) +- `general-naic-insurance-data-security-model-law-668-2017` — National Association of Insurance Commissioners (NAIC) Insurance Data Security Model Law (MDL - 668) (2017) (58 SCF controls, 85 framework controls) +- `general-nist-100-1-ai-rmf` — NIST AI 100 - 1 - Artificial Intelligence Risk Management Framework (AI RMF 1.0) (158 SCF controls, 91 framework controls) +- `general-nist-600-1-gen-ai-profile` — NIST AI 600 - 1 - Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (139 SCF controls, 250 framework controls) +- `general-nist-800-160-vol-2-r1` — NIST SP 800 - 160 Volume 2, Revision 1 - Developing Cyber - Resilient Systems: A Systems Security Engineering Approach (204 SCF controls, 196 framework controls) +- `general-nist-800-161-r1` — NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (341 SCF controls, 308 framework controls) +- `general-nist-800-161-r1-cscrm` — NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - C - SCRM Baseline (132 SCF controls, 95 framework controls) +- `general-nist-800-161-r1-flowdown` — NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Flow Down Baseline (107 SCF controls, 69 framework controls) +- `general-nist-800-161-r1-level-1` — NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 1 Baseline (95 SCF controls, 76 framework controls) +- `general-nist-800-161-r1-level-2` — NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 2 Baseline (273 SCF controls, 236 framework controls) +- `general-nist-800-161-r1-level-3` — NIST SP 800 - 161 R1 UDP1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - Level 3 Baseline (284 SCF controls, 251 framework controls) +- `general-nist-800-171-r2` — NIST SP 800 - 171 R2 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (251 SCF controls, 172 framework controls) +- `general-nist-800-171-r3` — NIST SP 800 - 171 R3 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (414 SCF controls, 275 framework controls) +- `general-nist-800-171a` — NIST SP 800 - 171A - Assessing Security Requirements for Controlled Unclassified Information (134 SCF controls, 320 framework controls) +- `general-nist-800-171a-r3` — NIST SP 800 - 171A R3 - Assessing Security Requirements for Controlled Unclassified Information (414 SCF controls, 509 framework controls) +- `general-nist-800-172-r3` — NIST SP 800 - 172 R3 - Enhanced Security Requirements for Protecting Controlled Unclassified Information (162 SCF controls, 103 framework controls) +- `general-nist-800-172a-r3` — NIST SP 800 - 172A R3 - Assessing Enhanced Security Requirements for Controlled Unclassified Information (163 SCF controls, 364 framework controls) +- `general-nist-800-207` — NIST SP 800 - 207 - Zero Trust Architecture (93 SCF controls, 7 framework controls) +- `general-nist-800-218` — NIST SP 800 - 218 - Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (59 SCF controls, 60 framework controls) +- `general-nist-800-37-r2` — NIST SP 800 - 37 R2 - Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy (45 SCF controls, 47 framework controls) +- `general-nist-800-39` — NIST SP 800 - 39 - Managing Information Security Risk: Organization, Mission, and Information System View (17 SCF controls, 16 framework controls) +- `general-nist-800-53-r4` — NIST SP 800 - 53 R4 - Security and Privacy Controls for Federal Information Systems and Organizations (653 SCF controls, 682 framework controls) +- `general-nist-800-53-r5-2` — NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations (777 SCF controls, 810 framework controls) +- `general-nist-800-53-r5-2-high` — NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - High Baseline (89 SCF controls, 83 framework controls) +- `general-nist-800-53-r5-2-low` — NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Low Baseline (202 SCF controls, 149 framework controls) +- `general-nist-800-53-r5-2-mod` — NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Moderate Baseline (157 SCF controls, 138 framework controls) +- `general-nist-800-53-r5-2-privacy` — NIST SP 800 - 53 R5 - Security and Privacy Controls for Information Systems and Organizations - Privacy Baseline (346 SCF controls, 236 framework controls) +- `general-nist-800-66-r2` — NIST SP 800 - 66 R2 - Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide (112 SCF controls, 22 framework controls) +- `general-nist-800-82-r3` — NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay (777 SCF controls, 810 framework controls) +- `general-nist-800-82-r3-high` — NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - High OT Overlay (467 SCF controls, 418 framework controls) +- `general-nist-800-82-r3-low` — NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Low OT Overlay (251 SCF controls, 194 framework controls) +- `general-nist-800-82-r3-mod` — NIST SP 800 - 82 R3 - Guide to Operational Technology (OT) Security - Moderate OT Overlay (390 SCF controls, 337 framework controls) +- `general-nist-csf-2-0` — NIST Cybersecurity Framework v2.0 (250 SCF controls, 134 framework controls) +- `general-nist-cswp-39` — NIST CSWP 39 - Considerations for Achieving Crypto Agility (15 SCF controls, 18 framework controls) +- `general-nist-privacy-framework-1-0` — NIST Privacy Framework v1.0 (153 SCF controls, 123 framework controls) +- `general-oecd-privacy-principles-2010` — Organisation for Economic Co - operation and Development (EOCD) Privacy Principles (14 SCF controls, 17 framework controls) +- `general-owasp-top-10-2025` — Open Worldwide Application Security Project (OWASP) Top 10 (2025) (139 SCF controls, 10 framework controls) +- `general-pci-dss-4-0-1` — Payment Card Industry Data Security Standard (PCI DSS) v4.01 (371 SCF controls, 351 framework controls) +- `general-pci-dss-4-0-1-saq-a` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A (71 SCF controls, 29 framework controls) +- `general-pci-dss-4-0-1-saq-a-ep` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) A - EP (239 SCF controls, 139 framework controls) +- `general-pci-dss-4-0-1-saq-b` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B (58 SCF controls, 27 framework controls) +- `general-pci-dss-4-0-1-saq-b-ip` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) B - IP (121 SCF controls, 50 framework controls) +- `general-pci-dss-4-0-1-saq-c` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C (227 SCF controls, 124 framework controls) +- `general-pci-dss-4-0-1-saq-c-vt` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) C - VT (115 SCF controls, 54 framework controls) +- `general-pci-dss-4-0-1-saq-d-merchant` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Merchant (322 SCF controls, 233 framework controls) +- `general-pci-dss-4-0-1-saq-d-service-provider` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) D Service Provider (339 SCF controls, 257 framework controls) +- `general-pci-dss-4-0-1-saq-p2pe` — Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 - Self - Assessment Questionnaire (SAQ) P2PE (47 SCF controls, 21 framework controls) +- `general-scf-dpmp-2025` — Secure Controls Framework (SCF) Data Privacy Management Principles (2025) (0 SCF controls, 0 framework controls) +- `general-shared-assessments-sig-2025` — Shared Assessments Standard Information Gathering (SIG) Questionnaire 2025 (128 SCF controls, 65 framework controls) +- `general-sparta` — Space Attack Research & Tactic Analysis (SPARTA) Countermeasures (79 SCF controls, 53 framework controls) +- `general-swift-cscf-2025` — Society for Worldwide Interbank Financial Telecommunication Customer Security Controls Framework 2025 (164 SCF controls, 32 framework controls) +- `general-tisax-6-0-3` — Trusted Information Security Assessment Exchange (TISAX) 6.0.3 (154 SCF controls, 73 framework controls) +- `general-ul-2900-1-2017` — UL 2900 - 1 - Software Cybersecurity for Network - Connectable Products, Part 1: General Requirements (2017) (23 SCF controls, 143 framework controls) +- `general-ul-2900-2-2-2016` — UL 2900 - 2 - 2 Ed. 1 - 2016 - Outline of Investigation for Software Cybersecurity for Network - Connectable Products, Part 2 - 2: Particular Requirements for Industrial Control Systems (20 SCF controls, 57 framework controls) +- `general-un-155-2021` — United Nations - Regulation No. 155 - Cyber security and cyber security management system (2021) (57 SCF controls, 55 framework controls) +- `general-un-ece-wp-29-2020` — United Nations - United Nations Economic Commission for Europe (UNECE) Working Party 29 (2020) (57 SCF controls, 54 framework controls) +- `usa-federal-cms-marse-2-0` — US - Centers for Medicare & Medicaid Services MARS - E Document Suite, Version 2.0 (392 SCF controls, 1287 framework controls) +- `usa-federal-dhs-cisa-cpg-2-0` — US - Cybersecurity & Infrastructure Security Agency (CISA) Cross - Sector Cybersecurity Performance Goals 2.0 (126 SCF controls, 38 framework controls) +- `usa-federal-dhs-cisa-ssdaf-2024` — US - Cybersecurity & Infrastructure Security Agency (CISA) Secure Software Development Attestation Form (SSDAF) (2024) (41 SCF controls, 15 framework controls) +- `usa-federal-dhs-cisa-tic-3-0` — US - Cybersecurity & Infrastructure Security Agency (CISA) Trusted Internet Connections 3.0 Security Capabilities Catalog (148 SCF controls, 117 framework controls) +- `usa-federal-doc-data-privacy-framework-2023` — US - Data Privacy Framework (2023) (31 SCF controls, 74 framework controls) +- `usa-federal-doe-c2m2-2-1` — US - Department of Energy (DOE) - Cybersecurity Capability Maturity Model version 2.1 (224 SCF controls, 356 framework controls) +- `usa-federal-dow-cert-rmm-1-2` — US - Department of War (DoW) - Computer Emergency Response Team (CERT) Resilience Management Model (RMM) Version 1.2 (85 SCF controls, 753 framework controls) +- `usa-federal-dow-cmmc-2-level-1` — US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1 (52 SCF controls, 15 framework controls) +- `usa-federal-dow-cmmc-2-level-1-aos` — US - Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 1 Assessment Objectives (16 SCF controls, 59 framework controls) +- `usa-federal-dow-cmmc-2-level-2` — US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 2 (198 SCF controls, 110 framework controls) +- `usa-federal-dow-cmmc-2-level-3` — US Department of War (DoW) - Cybersecurity Maturity Model Certification (CMMC) v2.0 - Level 3 (55 SCF controls, 24 framework controls) +- `usa-federal-dow-dfars-252-204-7012` — US - Defense Federal Acquisition Regulation Supplement (DFARS) 252.204 - 7012 (19 SCF controls, 20 framework controls) +- `usa-federal-dow-safeguarding-nnpi-2010` — US - Safeguarding of Naval Nuclear Propulsion Information (NNPI) (2010) (32 SCF controls, 68 framework controls) +- `usa-federal-dow-zt-roadmap-1-1` — US - Department of War (DoW) - Zero Trust Execution Roadmap v1.1 (117 SCF controls, 191 framework controls) +- `usa-federal-dow-zta-reference-architecture-2-0` — US - Department of War (DoW) - Zero Trust Reference Architecture v2 (39 SCF controls, 28 framework controls) +- `usa-federal-eo-14028` — US - Executive Order (EO) 14028 - Improving the Nation's Cybersecurity (43 SCF controls, 16 framework controls) +- `usa-federal-far-52-204-21` — US - Federal Acquisition Regulation (FAR) 52.204 - 21 - Basic Safeguarding of Covered Contractor Information Systems (59 SCF controls, 17 framework controls) +- `usa-federal-far-52-204-25` — US - Federal Acquisition Regulation (FAR) 52.204 - 25 (NDAA Section 889) - Prohibition on Contracting With Entities Using Certain Telecommunications and Video Surveillance Services or Equipment (2 SCF controls, 5 framework controls) +- `usa-federal-far-52-204-27` — US - Federal Acquisition Regulation (FAR) 52.204 - 27 - Prohibition on a ByteDance Covered Application (3 SCF controls, 2 framework controls) +- `usa-federal-fbi-cjis-6-0` — US - Department of Justice - Criminal Justice Information Services (CJIS) Security Policy v6.0 (365 SCF controls, 319 framework controls) +- `usa-federal-fda-21-cfr-part-11-2025` — US - Food & Drug Administration (FDA) 21 CFR Part 11 (2025) (62 SCF controls, 28 framework controls) +- `usa-federal-gsa-fedramp-5-high` — US - Federal Risk and Authorization Management Program (FedRAMP) R5 - High Baseline (561 SCF controls, 490 framework controls) +- `usa-federal-gsa-fedramp-5-li-saas` — US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Li - SAAS Baseline (383 SCF controls, 269 framework controls) +- `usa-federal-gsa-fedramp-5-low` — US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Low Baseline (383 SCF controls, 269 framework controls) +- `usa-federal-gsa-fedramp-5-mod` — US - Federal Risk and Authorization Management Program (FedRAMP) R5 - Moderate Baseline (491 SCF controls, 410 framework controls) +- `usa-federal-hhs-45-cfr-155-260-2016` — US - Health and Human Services (HHS) § 155.260 - Privacy and Security of Personally Identifiable Information (2016) (36 SCF controls, 44 framework controls) +- `usa-federal-irs-1075-2021` — US - Internal Revenue Service (IRS) 1075 (2021) (443 SCF controls, 744 framework controls) +- `usa-federal-law-33-cfr-part-101-subpart-f` — US - 33 CFR Part 101 Subpart F (up to date as of 4 - 17 - 2026) (104 SCF controls, 148 framework controls) +- `usa-federal-law-coppa-2024` — US - Children's Online Privacy Protection Act (COPPA) (2024) (10 SCF controls, 8 framework controls) +- `usa-federal-law-facta-fcra-2023` — US - Fair & Accurate Credit Transactions Act (FACTA) & Fair Credit Reporting Act (FCRA) (2023) (3 SCF controls, 6 framework controls) +- `usa-federal-law-ferpa-2010` — US - Family Educational Rights and Privacy Act (FERPA) (2010) (5 SCF controls, 27 framework controls) +- `usa-federal-law-ftc-act` — US - Federal Trade Commission (FTC) Act (16 SCF controls, 1 framework controls) +- `usa-federal-law-glba-cfr-314-2023` — US - Gramm Leach Bliley Act (GLBA) - CFR 314 (Dec 2023) (70 SCF controls, 52 framework controls) +- `usa-federal-law-hipaa-security-rule-2013` — US - Health Insurance Portability and Accountability Act (HIPAA) Security Rule (2013) (136 SCF controls, 87 framework controls) +- `usa-federal-law-hipaa-simplification-2013` — US - Health Insurance Portability and Accountability Act (HIPAA) Administrative Simplification (2013) (170 SCF controls, 576 framework controls) +- `usa-federal-law-sox-2002` — US - Sarbanes Oxley Act (SOX) (2002) (4 SCF controls, 17 framework controls) +- `usa-federal-nerc-cip-2024` — US - North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) (2024) (122 SCF controls, 204 framework controls) +- `usa-federal-nispom-2020` — US - National Industrial Security Program Operating Manual (NISPOM) (2020) (35 SCF controls, 226 framework controls) +- `usa-federal-omb-fipps-1973` — US - Fair Information Practice Principles (FIPPs) (1973) (30 SCF controls, 8 framework controls) +- `usa-federal-sec-cybersecurity-rule-2023` — US - Securities and Exchange Commission (SEC) Cybersecurity Rule (2023) (40 SCF controls, 15 framework controls) +- `usa-federal-sro-fca-crm-2023` — US - Farm Credit Administration (FCA) Cyber Risk Management (2023) (81 SCF controls, 34 framework controls) +- `usa-federal-sro-finra` — US - Financial Industry Regulatory Authority (FINRA) Cybersecurity Rules (17 SCF controls, 39 framework controls) +- `usa-federal-tsa-security-directive-1580-82-2022-01` — US - Transportation Security Administration (TSA) Security Directive 1580/82 - 2022 - 01 - Rail Cybersecurity Mitigation Actions and Testing (60 SCF controls, 68 framework controls) +- `usa-state-ak-pipa-2009` — US - Alaska Personal Information Protection Act (PIPA) (2009) (5 SCF controls, 25 framework controls) +- `usa-state-ca-ccpa-cpra-2026` — US - California Consumer Privacy Act (CCPA) (January 2026) - amended California Privacy Rights Act (CPRA) (258 SCF controls, 623 framework controls) +- `usa-state-ca-sb1386-2002` — US - California SB1386 (2002) (4 SCF controls, 6 framework controls) +- `usa-state-ca-sb327-2018` — US - California SB327 (2018) (3 SCF controls, 7 framework controls) +- `usa-state-co-privacy-act-2021` — US - Colorado Privacy Act (2021) (23 SCF controls, 52 framework controls) +- `usa-state-il-bipa-2008` — US - Illinois Biometric Information Privacy Act (BIPA) (2008) (6 SCF controls, 12 framework controls) +- `usa-state-il-ipa-2009` — US - Illinois Identity Protection Act (IPA) (2009) (12 SCF controls, 33 framework controls) +- `usa-state-il-pipa-2006` — US - Illinois Personal Information Protection Act (PIPA) (2006) (10 SCF controls, 53 framework controls) +- `usa-state-ma-201-cmr-17-2008` — US - Massachusetts 201 CMR 17.00 (2008) (53 SCF controls, 37 framework controls) +- `usa-state-nv-privacy-law-2023` — US - Nevada Privacy Law (2023) - CHAPTER 603A - SECURITY AND PRIVACY OF PERSONAL INFORMATION (29 SCF controls, 121 framework controls) +- `usa-state-nv-regulation-5-2024` — US - Nevada Operation of Gaming Establishments - Regulation 5.260 (Cybersecurity) (20 SCF controls, 11 framework controls) +- `usa-state-nv-sb220-2019` — US - Nevada SB220 (2019) (3 SCF controls, 4 framework controls) +- `usa-state-ny-dfs-23-nycrr500-2023-amd2` — US - New York Department of Financial Services (NY DFS) 23NYCRR Part 500 (2023 Amendment 2) (156 SCF controls, 145 framework controls) +- `usa-state-ny-shield-act-2019` — US - New York SHIELD Act (SB S5575B) (2019) (28 SCF controls, 45 framework controls) +- `usa-state-or-cpa-2023` — US - Oregon Consumer Privacy Act (SB 619) (2023) (34 SCF controls, 75 framework controls) +- `usa-state-or-ors-646a-2025` — US - Oregon Consumer Information Protection Act (ORS 646A) (2025) (24 SCF controls, 97 framework controls) +- `usa-state-tn-tipa-2025` — US - Tennessee Information Protection Act (TIPA) (2025) (29 SCF controls, 76 framework controls) +- `usa-state-tx-bc521-2009` — US - Texas Identity Theft Enforcement and Protection Act (BC521) (2009) (5 SCF controls, 27 framework controls) +- `usa-state-tx-cdpa-2025` — US - Texas Consumer Data Protection Act (2025) (28 SCF controls, 89 framework controls) +- `usa-state-tx-dir-security-control-standards-catalog-2-2` — US - Texas DIR Security Control Standards Catalog v2.2 (238 SCF controls, 228 framework controls) +- `usa-state-tx-sb2610-2025` — US - Texas Safe Harbor Law (SB2610) (2025) (6 SCF controls, 33 framework controls) +- `usa-state-tx-sb820-2019` — US - Texas SB820 (2019) (4 SCF controls, 7 framework controls) +- `usa-state-tx-txramp-2-0-level-1` — US - Texas Risk & Authorization Management Program 2.0 - Level 1 (173 SCF controls, 117 framework controls) +- `usa-state-tx-txramp-2-0-level-2` — US - Texas Risk & Authorization Management Program 2.0 - Level 2 (285 SCF controls, 223 framework controls) +- `usa-state-va-cdpa-2023` — US - Virginia Consumer Data Protection Act (2023) (44 SCF controls, 64 framework controls) +- `usa-state-vt-act-171-2018` — US - Vermont Data Broker Registration Act (Act 171 of 2018) (35 SCF controls, 61 framework controls) diff --git a/docs/llms.txt b/docs/llms.txt index 534c7e03..cd752852 100644 --- a/docs/llms.txt +++ b/docs/llms.txt @@ -1,6 +1,6 @@ # SCF API (sc2in/scf) -> Source-faithful static JSON API for the Secure Controls Framework (SCF) v2026.1.1. 1468 controls, 33 families, 249 framework crosswalks, 41 threats, 39 risks, 5776 assessment objectives, and 303 evidence requests. All static JSON, no auth required. +> Source-faithful static JSON API for the Secure Controls Framework (SCF) v2026.2. 1534 controls, 34 families, 252 framework crosswalks, 42 threats, 39 risks, 5956 assessment objectives, and 316 evidence requests. All static JSON, no auth required. All data is static JSON. Append paths to the base URL. diff --git a/overrides/overrides.json b/overrides/overrides.json index 669192a4..4bd9f419 100644 --- a/overrides/overrides.json +++ b/overrides/overrides.json @@ -1,15 +1,17 @@ { + "resolution": { + "sheets": [], + "columns": [] + }, "overrides": [ { - "id": "mon-03.3-erl-typo-2026.1.1", + "id": "mon-03.3-erl-typo", "check": "control-erl", - "sheet": "SCF 2026.1", "control": "MON-03.3", "match": "MON-03.2", "action": "drop", - "reason": "Workbook typo: the Evidence Request List column of MON-03.3 lists the control id MON-03.2 instead of an E-* artifact id. No plausible intended ERL id exists, so the reference is dropped. praxis independently filters non-E-* values; the archived hackIDLE dataset shipped the raw typo (tree-proof allowlist entry).", - "reported_upstream": null, - "applies_to": ["2026.1.1"] + "reason": "Workbook typo: the Evidence Request List column of MON-03.3 lists the control id MON-03.2 instead of an E-* artifact id. No plausible intended ERL id exists, so the reference is dropped. praxis independently filters non-E-* values; the archived hackIDLE dataset shipped the raw typo (tree-proof allowlist entry). Confirmed still present at 2026.2, so this entry is deliberately NOT version-scoped: autopilot must stay hands-off across releases until upstream corrects it, at which point the override-unused WARN surfaces it for removal.", + "reported_upstream": null } ] } diff --git a/src/scf_api/cli.py b/src/scf_api/cli.py index 91c39537..8d506c11 100644 --- a/src/scf_api/cli.py +++ b/src/scf_api/cli.py @@ -21,10 +21,10 @@ from . import jsonio from .build import build_docs, find_catalog from .changelog import generate_changelog -from .overrides import load_overrides +from .overrides import load_overrides, load_resolution_aliases from .parse import parse_workbook from .report import build_report, human_summary, write_report -from .schemas import validate_schemas +from .schemas import CATALOG_RE, validate_overrides_file, validate_schemas from .validate import validate_data_dir, validate_result from .verify_tree import compare_trees, load_allowlist from .workbook import ColumnResolveError, SheetResolveError @@ -65,19 +65,23 @@ def _run_parse( report_path: Path | None, ) -> int: overrides = load_overrides(overrides_path) + aliases = load_resolution_aliases(overrides_path, version) try: - result = parse_workbook(workbook, version) + result = parse_workbook(workbook, version, aliases=aliases) except (SheetResolveError, ColumnResolveError) as exc: + # Both subclass KeyError, whose str() is the *repr* of the message — + # args[0] keeps the issue body readable. + message = exc.args[0] if exc.args else str(exc) report = build_report( version, - "", - _structural_failure(str(exc)), + _sha256(workbook), + _structural_failure(message, exc), {}, str(workbook), ) if report_path: write_report(report, report_path) - print(f"FATAL structure error: {exc}", file=sys.stderr) + print(f"FATAL structure error: {message}", file=sys.stderr) return 1 outcome = validate_result(result, overrides) @@ -95,15 +99,46 @@ def _run_parse( out_dir.mkdir(parents=True, exist_ok=True) for name, obj in result.files.items(): jsonio.write(out_dir / name, obj) + stale = _prune_stale_catalogs(out_dir, result.catalog_name) + for name in stale: + print(f"removed stale catalog {name}", file=sys.stderr) print(f"wrote {len(result.files)} data files to {out_dir}", file=sys.stderr) return 0 -def _structural_failure(message: str): +def _prune_stale_catalogs(data_dir: Path, keep: str) -> list[str]: + """Delete catalogs from previous versions. + + The catalog filename carries the SCF version, so a version bump leaves the + old file behind. `find_catalog` takes the first sorted match, so a stale + scf-2026-1-1.json would shadow scf-2026-2.json and the build would publish + the previous release's data. + """ + removed = [] + for path in sorted(data_dir.glob("scf-*.json")): + if path.name != keep and CATALOG_RE.match(path.name): + path.unlink() + removed.append(path.name) + return removed + + +def _sha256(path: Path) -> str: + import hashlib + + digest = hashlib.sha256() + with open(path, "rb") as fh: + for chunk in iter(lambda: fh.read(1 << 20), b""): + digest.update(chunk) + return digest.hexdigest() + + +def _structural_failure(message: str, exc: Exception | None = None): from .validate import FAIL, Finding, ValidationOutcome outcome = ValidationOutcome() - check = "sheet-resolve" if "sheet" in message.lower() else "col-resolve" + # Branch on the exception type: every ColumnResolveError message also + # contains the word "sheet", so substring sniffing mislabels them. + check = "col-resolve" if isinstance(exc, ColumnResolveError) else "sheet-resolve" outcome.findings.append( Finding(check=check, severity=FAIL, message=message, owner="", value="") ) @@ -130,10 +165,13 @@ def _cmd_validate(args: argparse.Namespace) -> int: if not version: _, version = find_catalog(data_dir) schema_errors = validate_schemas(data_dir) + overrides_path = Path(args.overrides) if args.overrides else None + if overrides_path and overrides_path.exists(): + schema_errors += [f"overrides.json: {e}" for e in validate_overrides_file(overrides_path)] for err in schema_errors: print(f"schema: {err}", file=sys.stderr) - overrides = load_overrides(Path(args.overrides) if args.overrides else None) + overrides = load_overrides(overrides_path) outcome = validate_data_dir(data_dir, overrides, version) report = build_report(version, "", outcome, {}, None) if args.report: diff --git a/src/scf_api/overrides.py b/src/scf_api/overrides.py index 885c7e80..2b86c820 100644 --- a/src/scf_api/overrides.py +++ b/src/scf_api/overrides.py @@ -10,6 +10,14 @@ An entry that matched nothing this run is itself a warning — stale overrides must not accumulate silently. + +The same file also carries a `resolution` section: operator-supplied fallback +patterns for sheet tabs and column headers the upstream workbook has renamed. +That section exists so a rename discovered by autopilot in production can be +fixed by editing JSON — no code change, no release — which is exactly what the +summon-a-human issue body tells the reader to do. Aliases are tried only after +the parser's built-in patterns miss, and a hit raises a WARN rather than +passing silently, so the alias gets folded into the parser later. """ from __future__ import annotations @@ -18,6 +26,8 @@ from dataclasses import dataclass from pathlib import Path +from .workbook import ResolutionAliases + ACTIONS = ("drop", "replace", "accept") @@ -66,3 +76,38 @@ def load_overrides(path: Path | None) -> list[Override]: ) ) return out + + +def load_resolution_aliases(path: Path | None, version: str | None = None) -> ResolutionAliases: + """Load the `resolution` section: operator fallbacks for renamed tabs/columns. + + Entries scoped with `applies_to` are filtered against `version` (when one + is given), matching the semantics of the override map above. + """ + aliases = ResolutionAliases() + if path is None or not Path(path).exists(): + return aliases + raw = json.loads(Path(path).read_text(encoding="utf-8")) + if not isinstance(raw, dict): + return aliases + section = raw.get("resolution") or {} + + def scoped(entry: dict) -> bool: + applies_to = entry.get("applies_to") + return not (applies_to and version is not None and version not in applies_to) + + for e in section.get("sheets", []): + if not e.get("reason"): + raise ValueError(f"resolution alias {e.get('id')!r} is missing its mandatory reason") + if not scoped(e): + continue + aliases.sheets.setdefault(e["kind"], []).append((e["pattern"], e["id"])) + + for e in section.get("columns", []): + if not e.get("reason"): + raise ValueError(f"resolution alias {e.get('id')!r} is missing its mandatory reason") + if not scoped(e): + continue + aliases.columns.setdefault(e["kind"], []).append((e["pattern"], e["alias"], e["id"])) + + return aliases diff --git a/src/scf_api/parse.py b/src/scf_api/parse.py index faf0c8b1..bbfc8b9f 100644 --- a/src/scf_api/parse.py +++ b/src/scf_api/parse.py @@ -22,7 +22,13 @@ assign_api_ids, reconcile, ) -from .workbook import ColumnResolveError, SCFWorkbook, Sheet, cell_text +from .workbook import ( + ColumnResolveError, + ResolutionAliases, + SCFWorkbook, + Sheet, + cell_text, +) SOURCE_URL = "https://securecontrolsframework.com" LICENSE_TEXT = "CC BY-ND (Attribution, No Derivatives)" @@ -78,12 +84,16 @@ def _text(value: object) -> str: return cell_text(value) or "" -def parse_workbook(path: str | Path, version: str) -> ParseResult: +def parse_workbook( + path: str | Path, + version: str, + aliases: ResolutionAliases | None = None, +) -> ParseResult: path = Path(path) result = ParseResult(version=version, files={}) result.workbook_sha256 = hashlib.sha256(path.read_bytes()).hexdigest() - with SCFWorkbook(str(path)) as wb: + with SCFWorkbook(str(path), aliases=aliases) as wb: families = _parse_domains(wb, result) controls, xwalk = _parse_controls(wb, result) result.files[result.catalog_name] = { @@ -102,6 +112,8 @@ def parse_workbook(path: str | Path, version: str) -> ParseResult: result.files["scf-privacy-principles.json"] = _parse_privacy(wb, result) result.files["scf-risks.json"] = _parse_risks(wb, result) result.files["scf-threats.json"] = _parse_threats(wb, result) + # Operator aliases that had to be used — surfaced as WARN findings. + result.findings.extend(wb.resolution_notes) return result @@ -411,7 +423,9 @@ def _parse_aos(wb: SCFWorkbook, result: ParseResult) -> dict: def _parse_compensating(wb: SCFWorkbook, result: ParseResult) -> dict: sheet = wb.sheet("compensating") - id_col = sheet.col("scf control #") + # 2026.2 shortened "SCF Control #" to "SCF #". Neither pattern is a + # substring of the other's header, so both releases resolve unambiguously. + id_col = sheet.col("scf #", alts=("scf control #",)) risk_col = sheet.col("risk if") cc1_col = sheet.col("possible compensating control #1") cc2_col = sheet.col("possible compensating control #2") diff --git a/src/scf_api/schemas/overrides.schema.json b/src/scf_api/schemas/overrides.schema.json index 8c82efea..90c824de 100644 --- a/src/scf_api/schemas/overrides.schema.json +++ b/src/scf_api/schemas/overrides.schema.json @@ -4,6 +4,46 @@ "type": "object", "required": ["overrides"], "properties": { + "resolution": { + "type": "object", + "description": "Operator fallbacks for tabs/columns the upstream workbook renamed. Tried only after the parser's built-in patterns miss; a hit raises a resolution-alias WARN.", + "additionalProperties": false, + "properties": { + "sheets": { + "type": "array", + "items": { + "type": "object", + "required": ["id", "kind", "pattern", "reason"], + "additionalProperties": false, + "properties": { + "id": {"type": "string", "minLength": 1}, + "kind": {"type": "string", "minLength": 1}, + "pattern": {"type": "string", "minLength": 1}, + "reason": {"type": "string", "minLength": 1}, + "reported_upstream": {"type": ["string", "null"]}, + "applies_to": {"type": "array", "items": {"type": "string"}} + } + } + }, + "columns": { + "type": "array", + "items": { + "type": "object", + "required": ["id", "kind", "pattern", "alias", "reason"], + "additionalProperties": false, + "properties": { + "id": {"type": "string", "minLength": 1}, + "kind": {"type": "string", "minLength": 1}, + "pattern": {"type": "string", "minLength": 1}, + "alias": {"type": "string", "minLength": 1}, + "reason": {"type": "string", "minLength": 1}, + "reported_upstream": {"type": ["string", "null"]}, + "applies_to": {"type": "array", "items": {"type": "string"}} + } + } + } + } + }, "overrides": { "type": "array", "items": { diff --git a/src/scf_api/workbook.py b/src/scf_api/workbook.py index 6c401291..6d716550 100644 --- a/src/scf_api/workbook.py +++ b/src/scf_api/workbook.py @@ -1,15 +1,26 @@ """Workbook access: pattern-based sheet resolution and cell flattening. -Sheets are found by case-insensitive substring pattern, never by index — -sheet order and exact names change between SCF releases. Cells are read -with openpyxl in read_only+data_only mode, so formula cells yield their -cached values (the TEXTJOIN risk/threat summaries) and rich text arrives -as plain strings. +Sheets are found by normalized substring pattern, never by index — sheet +order and exact names change between SCF releases (2026.2 renamed +"Authoritative Sources" to "Focal Documents"). Each logical kind therefore +carries an ORDERED tuple of accepted patterns: the current name first, +historical names after it, so one parser reads every release we support. + +Patterns are matched with `norm_key`, the same normalization column headers +get, so a tab that gains an NBSP, an en-dash or a double space still +resolves instead of hard-failing the autopilot. + +When neither the built-in patterns nor an operator-supplied alias resolves a +sheet, that is a `SheetResolveError` and the validation gate summons a human. + +Cells are read with openpyxl in read_only+data_only mode, so formula cells +yield their cached values (the TEXTJOIN risk/threat summaries) and rich text +arrives as plain strings. """ from __future__ import annotations -from dataclasses import dataclass +from dataclasses import dataclass, field from openpyxl import load_workbook @@ -24,23 +35,59 @@ class ColumnResolveError(KeyError): """A required column could not be found in a sheet header.""" -# pattern, exclude-patterns — all case-insensitive substrings. -SHEET_PATTERNS: dict[str, tuple[str, tuple[str, ...]]] = { - "domains": ("domain", ()), - "sources": ("authoritative sources", ()), +# kind -> (accepted patterns, newest first), exclude-patterns. +# All matched with norm_key (NFKC, dash-folded, casefolded, space-collapsed). +SHEET_PATTERNS: dict[str, tuple[tuple[str, ...], tuple[str, ...]]] = { + "domains": (("domain",), ()), + # 2026.2 renamed "Authoritative Sources" -> "Focal Documents". + "sources": (("focal document", "authoritative sources"), ()), "controls": ( - "scf", - ("domain", "authoritative", "privacy", "objective", "list", "compensating", "catalog"), + ("scf",), + ( + "domain", + "authoritative", + "focal", + "privacy", + "objective", + "list", + "compensating", + "catalog", + ), ), - "compensating": ("compensating", ()), - "evidence": ("evidence request", ()), - "aos": ("assessment objectives", ("evidence",)), - "privacy": ("privacy", ("evidence",)), - "risks": ("risk catalog", ()), - "threats": ("threat catalog", ()), + "compensating": (("compensating",), ()), + "evidence": (("evidence request",), ()), + "aos": (("assessment objectives",), ("evidence",)), + "privacy": (("privacy",), ("evidence",)), + "risks": (("risk catalog",), ()), + "threats": (("threat catalog",), ()), } +@dataclass +class ResolutionAliases: + """Operator-supplied fallback patterns from overrides/overrides.json. + + Tried only after every built-in pattern has missed, so an alias can never + steal a sheet from the shipped manifest. A hit is recorded as a WARN + finding: the dataset still builds unattended, but the drift stays visible + so the alias can be folded into SHEET_PATTERNS in a later release. + """ + + sheets: dict[str, list[tuple[str, str]]] = field(default_factory=dict) + columns: dict[str, list[tuple[str, str, str]]] = field(default_factory=dict) + + def sheet_aliases(self, kind: str) -> list[tuple[str, str]]: + """[(pattern, override-id)] for a logical sheet kind.""" + return self.sheets.get(kind, []) + + def column_aliases(self, kind: str, pattern: str) -> list[tuple[str, str]]: + """[(alias, override-id)] for a (sheet kind, primary pattern) pair.""" + want = norm_key(pattern) + return [ + (alias, oid) for pat, alias, oid in self.columns.get(kind, []) if norm_key(pat) == want + ] + + def cell_text(value: object) -> str | None: """Flatten a cell value to text. Numbers keep their shortest repr.""" if value is None: @@ -62,18 +109,57 @@ class Sheet: header: list[str | None] rows: list[tuple] header_row: int # 1-based row number of the header (provenance) + kind: str = "" # logical kind it was resolved as (alias lookup key) + aliases: "ResolutionAliases | None" = None + notes: list[dict] | None = None # shared sink for resolution WARN findings - def col(self, pattern: str, exclude: tuple[str, ...] = ()) -> int: - """First column whose header contains pattern (normalized, case-insensitive).""" - idx = self.find_col(pattern, exclude) + def col( + self, + pattern: str, + exclude: tuple[str, ...] = (), + alts: tuple[str, ...] = (), + ) -> int: + """Resolve a column, trying `pattern` then each of `alts` in order.""" + idx = self.find_col(pattern, exclude, alts) if idx is None: + tried = ", ".join(repr(p) for p in (pattern, *alts)) raise ColumnResolveError( - f"no column matching {pattern!r} in sheet {self.title!r} " + f"no column matching {tried} in sheet {self.title!r} " f"(headers: {[h for h in self.header if h][:12]}...)" ) return idx - def find_col(self, pattern: str, exclude: tuple[str, ...] = ()) -> int | None: + def find_col( + self, + pattern: str, + exclude: tuple[str, ...] = (), + alts: tuple[str, ...] = (), + ) -> int | None: + """First matching column index, or None. + + Built-in patterns (`pattern`, then `alts`) resolve silently — they are + the shipped, tested manifest. Operator aliases from overrides.json are + tried last and record a WARN so the drift is visible in the report. + """ + for pat in (pattern, *alts): + idx = self._scan(pat, exclude) + if idx is not None: + return idx + if self.aliases is not None: + for alias, oid in self.aliases.column_aliases(self.kind, pattern): + idx = self._scan(alias, exclude) + if idx is not None: + self._note( + "column", + f"column {pattern!r} in sheet {self.title!r} resolved via " + f"operator alias {alias!r} (override {oid!r}) — fold it into " + f"the parser's built-in patterns", + oid, + ) + return idx + return None + + def _scan(self, pattern: str, exclude: tuple[str, ...]) -> int | None: want = norm_key(pattern) for i, h in enumerate(self.header): if h is None: @@ -83,14 +169,31 @@ def find_col(self, pattern: str, exclude: tuple[str, ...] = ()) -> int | None: return i return None + def _note(self, scope: str, message: str, oid: str) -> None: + if self.notes is None: + return + self.notes.append( + { + "check": "resolution-alias", + "severity": "warn", + "message": message, + "owner": f"{scope}:{self.kind}", + "value": oid, + "sheet": self.title, + } + ) + class SCFWorkbook: """The SCF master workbook, resolved sheet by pattern.""" - def __init__(self, path: str): + def __init__(self, path: str, aliases: ResolutionAliases | None = None): self.path = path self._wb = load_workbook(path, read_only=True, data_only=True) self.sheet_names: list[str] = list(self._wb.sheetnames) + self.aliases = aliases + # Resolution WARNs (operator aliases used); drained into ParseResult. + self.resolution_notes: list[dict] = [] def close(self) -> None: self._wb.close() @@ -102,15 +205,52 @@ def __exit__(self, *exc: object) -> None: self.close() def resolve_sheet_name(self, kind: str) -> str: - pattern, excludes = SHEET_PATTERNS[kind] - for name in self.sheet_names: - low = name.casefold() - if pattern in low and not any(x in low for x in excludes): + """Resolve a logical kind to a tab name. + + Built-in patterns are tried in order (current name first, historical + names after) and resolve silently. Operator aliases from + overrides.json are tried only after all of them miss, and record a + WARN so a rename patched in production stays visible. + """ + patterns, excludes = SHEET_PATTERNS[kind] + for pattern in patterns: + name = self._scan_sheets(pattern, excludes) + if name is not None: return name + + if self.aliases is not None: + for alias, oid in self.aliases.sheet_aliases(kind): + name = self._scan_sheets(alias, excludes) + if name is not None: + self.resolution_notes.append( + { + "check": "resolution-alias", + "severity": "warn", + "message": ( + f"sheet {kind!r} resolved to {name!r} via operator alias " + f"{alias!r} (override {oid!r}) — fold it into " + f"SHEET_PATTERNS in the parser" + ), + "owner": f"sheet:{kind}", + "value": oid, + "sheet": name, + } + ) + return name + + tried = ", ".join(repr(p) for p in patterns) raise SheetResolveError( - f"no sheet matching {pattern!r} (exclude={excludes!r}) in {self.sheet_names}" + f"no sheet matching {tried} (exclude={excludes!r}) in {self.sheet_names}" ) + def _scan_sheets(self, pattern: str, excludes: tuple[str, ...]) -> str | None: + want = norm_key(pattern) + for name in self.sheet_names: + key = norm_key(name) + if want in key and not any(norm_key(x) in key for x in excludes): + return name + return None + def sheet(self, kind: str, header_row: int = 1) -> Sheet: """Materialize a sheet. header_row is 1-based; rows are what follows it.""" name = self.resolve_sheet_name(kind) @@ -124,6 +264,9 @@ def sheet(self, kind: str, header_row: int = 1) -> Sheet: header=header, rows=all_rows[header_row:], header_row=header_row, + kind=kind, + aliases=self.aliases, + notes=self.resolution_notes, ) def catalog_sheet(self, kind: str, id_header: str) -> Sheet: @@ -143,5 +286,8 @@ def catalog_sheet(self, kind: str, id_header: str) -> Sheet: header=[cell_text(c) for c in row], rows=all_rows[i + 1 :], header_row=i + 1, + kind=kind, + aliases=self.aliases, + notes=self.resolution_notes, ) raise ColumnResolveError(f"no header row containing {id_header!r} in sheet {name!r}") diff --git a/tests/conftest.py b/tests/conftest.py index 89e9fee4..34114189 100644 --- a/tests/conftest.py +++ b/tests/conftest.py @@ -11,6 +11,13 @@ - erl-control-id control id in the ERL column (the MON-03.3 workbook typo) - dup-control-id duplicated control id row - renamed-source-header Sources header drifts from the column header (fuzzy match) + +Upstream rename defects (the SCF 2026.2 shape, which broke autopilot): + +- renamed-tab "Authoritative Sources" tab renamed to "Focal Documents" +- renamed-cc-header compensating "SCF Control #" header shortened to "SCF #" +- drifted-tab same tab, NBSP + doubled space + zero-width space +- unknown-tab a tab name no built-in pattern knows (operator-alias path) """ from __future__ import annotations @@ -30,6 +37,11 @@ "erl-control-id", "dup-control-id", "renamed-source-header", + # Upstream tab/header renames (SCF 2026.2 shape). + "renamed-tab", # "Authoritative Sources" -> "Focal Documents" + "renamed-cc-header", # "SCF Control #" -> "SCF #" + "drifted-tab", # same tab, NBSP + doubled space + zero-width space + "unknown-tab", # a name no built-in pattern knows (operator-alias path) } ) @@ -58,8 +70,18 @@ def build_workbook(path: Path, defects: frozenset[str] = frozenset()) -> Path: ws.append([3, "Testing", "TST", "Test things.", "Because.", 1, 0.17]) ws.append([None, None, None, None, "Total Control Count", 6, None]) - # --- Authoritative Sources --- - ws = wb.create_sheet("Authoritative Sources") + # --- Authoritative Sources (2026.2 renamed this tab to "Focal Documents") --- + if "unknown-tab" in defects: + sources_tab = "Reference Register" # no built-in pattern matches this + elif "drifted-tab" in defects: + # NBSP + a doubled space + a zero-width space: invisible drift that + # norm_key absorbs for column headers and now for tab names too. + sources_tab = "Authoritative\xa0 \u200bSources" + elif "renamed-tab" in defects: + sources_tab = "Focal Documents" + else: + sources_tab = "Authoritative Sources" + ws = wb.create_sheet(sources_tab) ws.append( [ "Geography", @@ -293,7 +315,7 @@ def control_row( ws.append( [ "SCF Control Name", - "SCF Control #", + "SCF #" if "renamed-cc-header" in defects else "SCF Control #", "SCF Control Description", "PPTDF\nApplicability", "Risk if Primary Control\nNot Implemented", diff --git a/tests/test_cli.py b/tests/test_cli.py index d33dfca9..955bea4b 100644 --- a/tests/test_cli.py +++ b/tests/test_cli.py @@ -75,6 +75,31 @@ def test_parse_gate_blocks_bad_workbook(workbook_factory, tmp_path): assert fails and fails[0]["check"] == "ao-control" +def test_version_bump_removes_the_previous_catalog(clean_workbook, tmp_path): + """A version bump must not leave the old catalog behind. + + find_catalog() takes the first sorted scf-*.json, so a leftover + scf-2099-1-1.json would shadow scf-2099-2.json and the build would + silently publish the previous release. + """ + from scf_api.build import find_catalog + + data = tmp_path / "data" + args = ["parse", "--workbook", str(clean_workbook), "--out", str(data), "--overrides", "/none"] + + assert main([*args, "--scf-version", "2099.1.1"]) == 0 + assert (data / "scf-2099-1-1.json").exists() + + assert main([*args, "--scf-version", "2099.2"]) == 0 + assert (data / "scf-2099-2.json").exists() + assert not (data / "scf-2099-1-1.json").exists() + assert find_catalog(data)[1] == "2099.2" + + # Non-catalog scf-*.json satellites must survive the prune. + assert (data / "scf-crosswalks.json").exists() + assert (data / "scf-risks.json").exists() + + def test_changelog_between_versions(clean_workbook, workbook_factory, tmp_path): from scf_api import jsonio from scf_api.parse import parse_workbook diff --git a/tests/test_integration_real.py b/tests/test_integration_real.py index 147e926f..982f9a9e 100644 --- a/tests/test_integration_real.py +++ b/tests/test_integration_real.py @@ -1,8 +1,8 @@ """Integration against the real SCF workbook — gated on $SCF_WORKBOOK. -Verified ground truth at 2026.1.1: 1,468 controls, 33 families, 249 -crosswalk frameworks, 5,776 AOs, 303 ERLs, 1,305 compensating controls, -258 privacy principles, 41 threats, 39 risks. +Ground truth is recorded per release, so one parser is proven against every +workbook vintage we support. Set $SCF_WORKBOOK (and optionally $SCF_VERSION +when the filename does not carry it) to run these. """ import os @@ -15,6 +15,16 @@ not WORKBOOK, reason="set $SCF_WORKBOOK to run real-workbook integration tests" ) +# version -> (controls, families, frameworks, aos, erls, compensating, +# privacy, threats, risks) +GROUND_TRUTH = { + "2026.1.1": (1468, 33, 249, 5776, 303, 1305, 258, 41, 39), + # 2026.2 renamed the "Authoritative Sources" tab to "Focal Documents" and + # shortened the compensating "SCF Control #" header to "SCF #"; it also + # added the QTS family and threat MT-28. + "2026.2": (1534, 34, 252, 5956, 316, 1371, 258, 42, 39), +} + @pytest.fixture(scope="module") def real_result(): @@ -26,25 +36,50 @@ def real_result(): def test_counts(real_result): + expected = GROUND_TRUTH.get(real_result.version) + if expected is None: + pytest.skip(f"no recorded ground truth for SCF {real_result.version}") + controls, families, frameworks, aos, erls, compensating, privacy, threats, risks = expected + catalog = real_result.catalog - assert len(catalog["controls"]) == 1468 - assert len(catalog["families"]) == 33 - xwalk = real_result.files["scf-crosswalks.json"] - assert xwalk["metadata"]["total_frameworks"] == 249 - assert real_result.files["scf-assessment-objectives.json"]["total"] == 5776 - assert real_result.files["scf-evidence-requests.json"]["total"] == 303 - assert real_result.files["scf-compensating-controls.json"]["total"] == 1305 - assert real_result.files["scf-privacy-principles.json"]["total"] == 258 - assert real_result.files["scf-threats.json"]["total"] == 41 - assert real_result.files["scf-risks.json"]["total"] == 39 + assert len(catalog["controls"]) == controls + assert len(catalog["families"]) == families + assert real_result.files["scf-crosswalks.json"]["metadata"]["total_frameworks"] == frameworks + assert real_result.files["scf-assessment-objectives.json"]["total"] == aos + assert real_result.files["scf-evidence-requests.json"]["total"] == erls + assert real_result.files["scf-compensating-controls.json"]["total"] == compensating + assert real_result.files["scf-privacy-principles.json"]["total"] == privacy + assert real_result.files["scf-threats.json"]["total"] == threats + assert real_result.files["scf-risks.json"]["total"] == risks + + +def test_no_operator_aliases_needed(real_result): + """Every supported release resolves on built-in patterns alone. + + A resolution-alias finding here means a rename is being carried by + overrides.json that should be folded into the parser. + """ + assert real_result.findings == [] + + +def test_sources_reconcile_without_guessing(real_result): + """No crosswalk column may be matched by a low-confidence fuzzy guess.""" + weak = [ + s for s in real_result.manifest["sources"] if s["method"] == "fuzzy" and s["score"] < 90 + ] + assert not weak, f"low-confidence source matches: {weak}" def test_known_workbook_typo_is_caught(real_result): - """MON-03.3 lists control id MON-03.2 in its ERL column at 2026.1.1.""" + """MON-03.3 lists control id MON-03.2 in its ERL column. + + Present at 2026.1.1 and still present at 2026.2 — the reason the + mon-03.3-erl-typo override is deliberately not version-scoped. + """ from scf_api.validate import validate_result - if real_result.version != "2026.1.1": - pytest.skip("typo is specific to 2026.1.1") + if real_result.version not in ("2026.1.1", "2026.2"): + pytest.skip(f"typo not characterized for SCF {real_result.version}") outcome = validate_result(real_result, []) fails = [f for f in outcome.findings if f.unresolved_fail] assert any( diff --git a/tests/test_parse.py b/tests/test_parse.py index ab1b187e..b793b22f 100644 --- a/tests/test_parse.py +++ b/tests/test_parse.py @@ -169,3 +169,41 @@ def test_parse_deterministic(clean_workbook): assert {n: jsonio.dumps(o) for n, o in a.files.items()} == { n: jsonio.dumps(o) for n, o in b.files.items() } + + +def test_renamed_tabs_and_headers_parse_identically(workbook_factory): + """The 2026.2 rename shape yields byte-identical data to the old names. + + This is the regression that broke autopilot: a pure rename must change + nothing about the emitted dataset. + """ + from scf_api import jsonio + + old = parse_workbook(workbook_factory(), VERSION) + renamed = parse_workbook(workbook_factory("renamed-tab", "renamed-cc-header"), VERSION) + + assert {n: jsonio.dumps(o) for n, o in old.files.items()} == { + n: jsonio.dumps(o) for n, o in renamed.files.items() + } + # Built-in patterns handled it, so no operator alias was needed. + assert renamed.findings == [] + + +def test_operator_alias_surfaces_as_a_warn_finding(workbook_factory): + """An overrides.json alias parses the workbook but flags the drift.""" + from scf_api.overrides import load_overrides + from scf_api.validate import validate_result + from scf_api.workbook import ResolutionAliases + + aliases = ResolutionAliases(sheets={"sources": [("reference register", "ref-register-2099")]}) + result = parse_workbook(workbook_factory("unknown-tab"), VERSION, aliases=aliases) + + (note,) = result.findings + assert note["check"] == "resolution-alias" + + outcome = validate_result(result, load_overrides(None)) + alias_findings = [f for f in outcome.findings if f.check == "resolution-alias"] + assert len(alias_findings) == 1 + assert alias_findings[0].severity == "warn" + # A WARN must not block the gate. + assert outcome.ok diff --git a/tests/test_workbook.py b/tests/test_workbook.py index df899f7c..2de9a03e 100644 --- a/tests/test_workbook.py +++ b/tests/test_workbook.py @@ -1,6 +1,11 @@ import pytest -from scf_api.workbook import SCFWorkbook, SheetResolveError +from scf_api.workbook import ( + ColumnResolveError, + ResolutionAliases, + SCFWorkbook, + SheetResolveError, +) def test_sheet_resolution(clean_workbook): @@ -28,3 +33,89 @@ def test_catalog_sheet_floating_header(clean_workbook): sheet = wb.catalog_sheet("risks", "Risk #") assert sheet.header_row == 6 assert sheet.find_col("risk #") is not None + + +# --- rename resilience ----------------------------------------------------- + + +def test_renamed_tab_resolves_via_builtin_alias(workbook_factory): + """SCF 2026.2's "Focal Documents" resolves with no operator intervention.""" + wb_path = workbook_factory("renamed-tab") + with SCFWorkbook(str(wb_path)) as wb: + assert wb.resolve_sheet_name("sources") == "Focal Documents" + # A built-in alias is the shipped manifest, so it must stay silent. + assert wb.resolution_notes == [] + + +def test_renamed_tab_does_not_steal_the_controls_sheet(workbook_factory): + """ "Focal Documents" must not satisfy the `controls` pattern.""" + wb_path = workbook_factory("renamed-tab") + with SCFWorkbook(str(wb_path)) as wb: + assert wb.resolve_sheet_name("controls") == "SCF 2099.1" + + +def test_drifted_tab_name_is_normalized(workbook_factory): + """Invisible whitespace drift resolves like column headers already do.""" + wb_path = workbook_factory("drifted-tab") + with SCFWorkbook(str(wb_path)) as wb: + assert wb.resolve_sheet_name("sources") == "Authoritative\xa0 \u200bSources" + assert wb.resolution_notes == [] + + +def test_unknown_tab_raises_without_an_alias(workbook_factory): + wb_path = workbook_factory("unknown-tab") + with SCFWorkbook(str(wb_path)) as wb: + with pytest.raises(SheetResolveError): + wb.resolve_sheet_name("sources") + + +def test_operator_sheet_alias_resolves_and_warns(workbook_factory): + """An overrides.json alias rescues an unknown tab, loudly.""" + wb_path = workbook_factory("unknown-tab") + aliases = ResolutionAliases(sheets={"sources": [("reference register", "ref-register-2099")]}) + with SCFWorkbook(str(wb_path), aliases=aliases) as wb: + assert wb.resolve_sheet_name("sources") == "Reference Register" + (note,) = wb.resolution_notes + assert note["check"] == "resolution-alias" + assert note["severity"] == "warn" + assert note["value"] == "ref-register-2099" + assert note["owner"] == "sheet:sources" + + +def test_builtin_patterns_win_over_operator_aliases(clean_workbook): + """An alias can never steal a sheet the shipped manifest already resolves.""" + aliases = ResolutionAliases(sheets={"sources": [("lists", "bogus-alias")]}) + with SCFWorkbook(str(clean_workbook), aliases=aliases) as wb: + assert wb.resolve_sheet_name("sources") == "Authoritative Sources" + assert wb.resolution_notes == [] + + +def test_renamed_column_resolves_via_builtin_alt(workbook_factory): + """2026.2's "SCF #" and 2026.1.1's "SCF Control #" both resolve.""" + for defects, header in ((("renamed-cc-header",), "SCF #"), ((), "SCF Control #")): + wb_path = workbook_factory(*defects) + with SCFWorkbook(str(wb_path)) as wb: + sheet = wb.sheet("compensating") + assert sheet.header[sheet.col("scf #", alts=("scf control #",))] == header + assert wb.resolution_notes == [] + + +def test_operator_column_alias_resolves_and_warns(clean_workbook): + aliases = ResolutionAliases( + columns={"compensating": [("nonexistent col", "scf control #", "cc-alias-2099")]} + ) + with SCFWorkbook(str(clean_workbook), aliases=aliases) as wb: + sheet = wb.sheet("compensating") + assert sheet.col("nonexistent col") == sheet.col("scf control #") + (note,) = wb.resolution_notes + assert note["check"] == "resolution-alias" + assert note["value"] == "cc-alias-2099" + assert note["owner"] == "column:compensating" + + +def test_unresolvable_column_lists_every_pattern_tried(clean_workbook): + with SCFWorkbook(str(clean_workbook)) as wb: + sheet = wb.sheet("compensating") + with pytest.raises(ColumnResolveError) as exc: + sheet.col("no such col", alts=("nor this one",)) + assert "'no such col', 'nor this one'" in exc.value.args[0] diff --git a/validation/validation-report.json b/validation/validation-report.json index b830ab52..323ea3e6 100644 --- a/validation/validation-report.json +++ b/validation/validation-report.json @@ -1,11 +1,11 @@ { - "scf_version": "2026.1.1", - "workbook_sha256": "ef13a69f58e3290168b0d582330b87d22d4ee39e846ec64c3d4e98e7886c312e", - "workbook": "/home/tsunami/Downloads/Secure.Controls.Framework.SCF.-.2026.1.1.xlsx", - "generated_at": "2026-07-20T01:59:56+00:00", + "scf_version": "2026.2", + "workbook_sha256": "9e0a4df4993726c95e636f04b3028d8b5edeba2bda45d16ed6722b13540e6835", + "workbook": "/tmp/claude-1001/-home-tsunami-code-sc2-scf-api-sc2in/ed86f800-bd58-4ecf-a036-698937f8a3e0/scratchpad/wb/secure-controls-framework-scf-2026-2.xlsx", + "generated_at": "2026-08-04T16:40:58+00:00", "summary": { "fail": 0, - "warn": 5, + "warn": 3, "resolved": 1, "ok": true }, @@ -16,29 +16,9 @@ "message": "'MON-03.3' references unknown erl id 'MON-03.2'", "owner": "MON-03.3", "value": "MON-03.2", - "sheet": "SCF 2026.1", - "cell": "F467", - "resolution": "override:mon-03.3-erl-typo-2026.1.1" - }, - { - "check": "xwalk-source", - "severity": "warn", - "message": "Authoritative Sources row 144 (usa-state-nv-privacy-law-2023) matched no crosswalk column", - "owner": "usa-state-nv-privacy-law-2023", - "value": "US - NV\nSB220", - "sheet": null, - "cell": null, - "resolution": null - }, - { - "check": "xwalk-source", - "severity": "warn", - "message": "crosswalk column 'US - NV\\nPrivacy Law 2023' matched no Authoritative Sources row", - "owner": "", - "value": "US - NV\nPrivacy Law 2023", - "sheet": null, - "cell": null, - "resolution": null + "sheet": "SCF 2026.2", + "cell": "F482", + "resolution": "override:mon-03.3-erl-typo" }, { "check": "xwalk-source", @@ -73,7 +53,7 @@ ], "overrides": { "used": [ - "mon-03.3-erl-typo-2026.1.1" + "mon-03.3-erl-typo" ], "unused": [] }, @@ -354,8 +334,8 @@ "api_id": "general-iso-27018-2025", "sheet_row": 32, "header": "ISO \n27018\n2025", - "matched_column": "ISO\n27018 \n2025", - "method": "normalized", + "matched_column": "ISO \n27018\n2025", + "method": "exact", "score": 100 }, { @@ -404,8 +384,8 @@ "score": 100 }, { - "fdi": "general-mitre-att&ck-16-1", - "api_id": "general-mitre-att&ck-16-1", + "fdi": "general-mitre-att_ck-16-1", + "api_id": "general-mitre-att_ck-16-1", "sheet_row": 38, "header": "MITRE\nATT&CK\n16", "matched_column": "MITRE\nATT&CK\n16", @@ -674,18 +654,27 @@ "score": 100 }, { - "fdi": "general-nist-800-172", - "api_id": "general-nist-800-172", + "fdi": "general-nist-800-172-r3", + "api_id": "general-nist-800-172-r3", "sheet_row": 68, - "header": "NIST\n800-172", - "matched_column": "NIST\n800-172", + "header": "NIST\n800-172 R3", + "matched_column": "NIST\n800-172 R3", + "method": "exact", + "score": 100 + }, + { + "fdi": "general-nist-800-172a-r3", + "api_id": "general-nist-800-172a-r3", + "sheet_row": 69, + "header": "NIST\n800-172A R3", + "matched_column": "NIST\n800-172A R3", "method": "exact", "score": 100 }, { "fdi": "general-nist-800-207", "api_id": "general-nist-800-207", - "sheet_row": 69, + "sheet_row": 70, "header": "NIST\n800-207", "matched_column": "NIST\n800-207", "method": "exact", @@ -694,7 +683,7 @@ { "fdi": "general-nist-800-218", "api_id": "general-nist-800-218", - "sheet_row": 70, + "sheet_row": 71, "header": "NIST\n800-218", "matched_column": "NIST\n800-218", "method": "exact", @@ -703,16 +692,25 @@ { "fdi": "general-nist-csf-2-0", "api_id": "general-nist-csf-2-0", - "sheet_row": 71, + "sheet_row": 72, "header": "NIST\nCSF\n2.0", "matched_column": "NIST\nCSF\n2.0", "method": "exact", "score": 100 }, + { + "fdi": "general-nist-cswp-39", + "api_id": "general-nist-cswp-39", + "sheet_row": 73, + "header": "NIST\nCSWP 39", + "matched_column": "NIST\nCSWP 39", + "method": "exact", + "score": 100 + }, { "fdi": "general-oecd-privacy-principles-2010", "api_id": "general-oecd-privacy-principles-2010", - "sheet_row": 72, + "sheet_row": 74, "header": "OECD\nPrivacy Principles", "matched_column": "OECD\nPrivacy Principles", "method": "exact", @@ -721,7 +719,7 @@ { "fdi": "general-owasp-top-10-2025", "api_id": "general-owasp-top-10-2025", - "sheet_row": 73, + "sheet_row": 75, "header": "OWASP\nTop 10\n2025", "matched_column": "OWASP\nTop 10\n2025", "method": "exact", @@ -730,7 +728,7 @@ { "fdi": "general-pci-dss-4-0-1", "api_id": "general-pci-dss-4-0-1", - "sheet_row": 74, + "sheet_row": 76, "header": "PCI DSS\n4.0.1", "matched_column": "PCI DSS\n4.0.1", "method": "exact", @@ -739,7 +737,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-a", "api_id": "general-pci-dss-4-0-1-saq-a", - "sheet_row": 75, + "sheet_row": 77, "header": "PCI DSS\n4.0.1\nSAQ A", "matched_column": "PCI DSS\n4.0.1\nSAQ A", "method": "exact", @@ -748,7 +746,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-a-ep", "api_id": "general-pci-dss-4-0-1-saq-a-ep", - "sheet_row": 76, + "sheet_row": 78, "header": "PCI DSS\n4.0.1\nSAQ A-EP", "matched_column": "PCI DSS\n4.0.1\nSAQ A-EP", "method": "exact", @@ -757,7 +755,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-b", "api_id": "general-pci-dss-4-0-1-saq-b", - "sheet_row": 77, + "sheet_row": 79, "header": "PCI DSS\n4.0.1\nSAQ B", "matched_column": "PCI DSS\n4.0.1\nSAQ B", "method": "exact", @@ -766,7 +764,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-b-ip", "api_id": "general-pci-dss-4-0-1-saq-b-ip", - "sheet_row": 78, + "sheet_row": 80, "header": "PCI DSS\n4.0.1\nSAQ B-IP", "matched_column": "PCI DSS\n4.0.1\nSAQ B-IP", "method": "exact", @@ -775,7 +773,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-c", "api_id": "general-pci-dss-4-0-1-saq-c", - "sheet_row": 79, + "sheet_row": 81, "header": "PCI DSS\n4.0.1\nSAQ C", "matched_column": "PCI DSS\n4.0.1\nSAQ C", "method": "exact", @@ -784,7 +782,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-c-vt", "api_id": "general-pci-dss-4-0-1-saq-c-vt", - "sheet_row": 80, + "sheet_row": 82, "header": "PCI DSS\n4.0.1\nSAQ C-VT", "matched_column": "PCI DSS\n4.0.1\nSAQ C-VT", "method": "exact", @@ -793,7 +791,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-d-merchant", "api_id": "general-pci-dss-4-0-1-saq-d-merchant", - "sheet_row": 81, + "sheet_row": 83, "header": "PCI DSS\n4.0.1\nSAQ D Merchant", "matched_column": "PCI DSS\n4.0.1\nSAQ D Merchant", "method": "exact", @@ -802,7 +800,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-d-service-provider", "api_id": "general-pci-dss-4-0-1-saq-d-service-provider", - "sheet_row": 82, + "sheet_row": 84, "header": "PCI DSS\n4.0.1\nSAQ D Service Provider", "matched_column": "PCI DSS\n4.0.1\nSAQ D Service Provider", "method": "exact", @@ -811,7 +809,7 @@ { "fdi": "general-pci-dss-4-0-1-saq-p2pe", "api_id": "general-pci-dss-4-0-1-saq-p2pe", - "sheet_row": 83, + "sheet_row": 85, "header": "PCI DSS\n4.0.1\nSAQ P2PE", "matched_column": "PCI DSS\n4.0.1\nSAQ P2PE", "method": "exact", @@ -820,7 +818,7 @@ { "fdi": "general-scf-dpmp-2025", "api_id": "general-scf-dpmp-2025", - "sheet_row": 84, + "sheet_row": 86, "header": "SCF\nDPMP\n2025", "matched_column": "SCF\nDPMP\n2025", "method": "exact", @@ -829,7 +827,7 @@ { "fdi": "general-shared-assessments-sig-2025", "api_id": "general-shared-assessments-sig-2025", - "sheet_row": 85, + "sheet_row": 87, "header": "Shared Assessments SIG \n2025", "matched_column": "Shared Assessments SIG \n2025", "method": "exact", @@ -838,7 +836,7 @@ { "fdi": "general-sparta", "api_id": "general-sparta", - "sheet_row": 86, + "sheet_row": 88, "header": "SPARTA", "matched_column": "SPARTA", "method": "exact", @@ -847,7 +845,7 @@ { "fdi": "general-swift-cscf-2025", "api_id": "general-swift-cscf-2025", - "sheet_row": 87, + "sheet_row": 89, "header": "SWIFT\nCSF\n2025", "matched_column": "SWIFT\nCSF\n2025", "method": "exact", @@ -856,7 +854,7 @@ { "fdi": "general-tisax-6-0-3", "api_id": "general-tisax-6-0-3", - "sheet_row": 88, + "sheet_row": 90, "header": "TISAX\nISA\n6.0.3", "matched_column": "TISAX\nISA\n6.0.3", "method": "exact", @@ -865,7 +863,7 @@ { "fdi": "general-ul-2900-1-2017", "api_id": "general-ul-2900-1-2017", - "sheet_row": 89, + "sheet_row": 91, "header": "UL\n2900-1\n2017", "matched_column": "UL\n2900-1\n2017", "method": "exact", @@ -874,7 +872,7 @@ { "fdi": "general-ul-2900-2-2-2016", "api_id": "general-ul-2900-2-2-2016", - "sheet_row": 90, + "sheet_row": 92, "header": "UL\n2900-2-2\n2016", "matched_column": "UL\n2900-2-2\n2016", "method": "exact", @@ -883,7 +881,7 @@ { "fdi": "general-un-155-2021", "api_id": "general-un-155-2021", - "sheet_row": 91, + "sheet_row": 93, "header": "UN\nR155", "matched_column": "UN\nR155", "method": "exact", @@ -892,7 +890,7 @@ { "fdi": "general-un-ece-wp-29-2020", "api_id": "general-un-ece-wp-29-2020", - "sheet_row": 92, + "sheet_row": 94, "header": "UN\nECE WP.29", "matched_column": "UN\nECE WP.29", "method": "exact", @@ -901,7 +899,7 @@ { "fdi": "usa-federal-dow-cert-rmm-1-2", "api_id": "usa-federal-dow-cert-rmm-1-2", - "sheet_row": 93, + "sheet_row": 95, "header": "US\nCERT RMM\n1.2", "matched_column": "US\nCERT RMM\n1.2", "method": "exact", @@ -910,7 +908,7 @@ { "fdi": "usa-federal-law-coppa-2024", "api_id": "usa-federal-law-coppa-2024", - "sheet_row": 94, + "sheet_row": 96, "header": "US\nCOPPA", "matched_column": "US\nCOPPA", "method": "exact", @@ -919,7 +917,7 @@ { "fdi": "usa-federal-dhs-cisa-ssdaf-2024", "api_id": "usa-federal-dhs-cisa-ssdaf-2024", - "sheet_row": 95, + "sheet_row": 97, "header": "US\nDHS CISA\nSSDAF", "matched_column": "US\nDHS CISA\nSSDAF", "method": "exact", @@ -928,7 +926,7 @@ { "fdi": "usa-federal-dhs-cisa-tic-3-0", "api_id": "usa-federal-dhs-cisa-tic-3-0", - "sheet_row": 96, + "sheet_row": 98, "header": "US\nDHS CISA\nTIC 3.0", "matched_column": "US\nDHS CISA\nTIC 3.0", "method": "exact", @@ -937,7 +935,7 @@ { "fdi": "usa-federal-dhs-cisa-cpg-2-0", "api_id": "usa-federal-dhs-cisa-cpg-2-0", - "sheet_row": 97, + "sheet_row": 99, "header": "US\nCISA\nCPG\n2022", "matched_column": "US\nCISA\nCPG\n2022", "method": "exact", @@ -946,7 +944,7 @@ { "fdi": "usa-federal-fbi-cjis-6-0", "api_id": "usa-federal-fbi-cjis-6-0", - "sheet_row": 98, + "sheet_row": 100, "header": "US\nCJIS Security Policy\n6.0", "matched_column": "US\nCJIS Security Policy\n6.0", "method": "exact", @@ -955,7 +953,7 @@ { "fdi": "usa-federal-doe-c2m2-2-1", "api_id": "usa-federal-doe-c2m2-2-1", - "sheet_row": 99, + "sheet_row": 101, "header": "US\nC2M2\n2.1", "matched_column": "US\nC2M2\n2.1", "method": "exact", @@ -964,7 +962,7 @@ { "fdi": "usa-federal-dow-cmmc-2-level-1", "api_id": "usa-federal-dow-cmmc-2-level-1", - "sheet_row": 100, + "sheet_row": 102, "header": "US\nCMMC 2.0\nLevel 1", "matched_column": "US\nCMMC 2.0\nLevel 1", "method": "exact", @@ -973,7 +971,7 @@ { "fdi": "usa-federal-dow-cmmc-2-level-1-aos", "api_id": "usa-federal-dow-cmmc-2-level-1-aos", - "sheet_row": 101, + "sheet_row": 103, "header": "US\nCMMC 2.0\nLevel 1 AOs", "matched_column": "US\nCMMC 2.0\nLevel 1 AOs", "method": "exact", @@ -982,7 +980,7 @@ { "fdi": "usa-federal-dow-cmmc-2-level-2", "api_id": "usa-federal-dow-cmmc-2-level-2", - "sheet_row": 102, + "sheet_row": 104, "header": "US\nCMMC 2.0\nLevel 2", "matched_column": "US\nCMMC 2.0\nLevel 2", "method": "exact", @@ -991,7 +989,7 @@ { "fdi": "usa-federal-dow-cmmc-2-level-3", "api_id": "usa-federal-dow-cmmc-2-level-3", - "sheet_row": 103, + "sheet_row": 105, "header": "US\nCMMC 2.0\nLevel 3", "matched_column": "US\nCMMC 2.0\nLevel 3", "method": "exact", @@ -1000,7 +998,7 @@ { "fdi": "usa-federal-doc-data-privacy-framework-2023", "api_id": "usa-federal-doc-data-privacy-framework-2023", - "sheet_row": 104, + "sheet_row": 106, "header": "US\nData Privacy Framework (DPF)", "matched_column": "US\nData Privacy Framework (DPF)", "method": "exact", @@ -1009,7 +1007,7 @@ { "fdi": "usa-federal-dow-zt-roadmap-1-1", "api_id": "usa-federal-dow-zt-roadmap-1-1", - "sheet_row": 105, + "sheet_row": 107, "header": "US\nDoD\nZero Trust Execution Roadmap", "matched_column": "US\nDoD\nZero Trust Execution Roadmap", "method": "exact", @@ -1018,7 +1016,7 @@ { "fdi": "usa-federal-dow-zta-reference-architecture-2-0", "api_id": "usa-federal-dow-zta-reference-architecture-2-0", - "sheet_row": 106, + "sheet_row": 108, "header": "US\nDoD\nZero Trust Reference Architecture 2.0", "matched_column": "US\nDoD\nZero Trust Reference Architecture 2.0", "method": "exact", @@ -1027,7 +1025,7 @@ { "fdi": "usa-federal-dow-dfars-252-204-7012", "api_id": "usa-federal-dow-dfars-252-204-7012", - "sheet_row": 107, + "sheet_row": 109, "header": "US\nDFARS\nCybersecurity\n252.204-7012", "matched_column": "US\nDFARS\nCybersecurity\n252.204-7012", "method": "exact", @@ -1036,7 +1034,7 @@ { "fdi": "usa-federal-eo-14028", "api_id": "usa-federal-eo-14028", - "sheet_row": 108, + "sheet_row": 110, "header": "US\nEO 14028", "matched_column": "US\nEO 14028", "method": "exact", @@ -1045,7 +1043,7 @@ { "fdi": "usa-federal-law-facta-fcra-2023", "api_id": "usa-federal-law-facta-fcra-2023", - "sheet_row": 109, + "sheet_row": 111, "header": "US\nFACTA & FCRA", "matched_column": "US\nFACTA & FCRA", "method": "exact", @@ -1054,7 +1052,7 @@ { "fdi": "usa-federal-far-52-204-21", "api_id": "usa-federal-far-52-204-21", - "sheet_row": 110, + "sheet_row": 112, "header": "US\nFAR\n52.204-21", "matched_column": "US\nFAR\n52.204-21", "method": "exact", @@ -1063,7 +1061,7 @@ { "fdi": "usa-federal-far-52-204-25", "api_id": "usa-federal-far-52-204-25", - "sheet_row": 111, + "sheet_row": 113, "header": "US\nFAR\n52.204-25\n(NDAA Section 889)", "matched_column": "US\nFAR\n52.204-25\n(NDAA Section 889)", "method": "exact", @@ -1072,7 +1070,7 @@ { "fdi": "usa-federal-far-52-204-27", "api_id": "usa-federal-far-52-204-27", - "sheet_row": 112, + "sheet_row": 114, "header": "US\nFAR\n52.204-27", "matched_column": "US\nFAR\n52.204-27", "method": "exact", @@ -1081,7 +1079,7 @@ { "fdi": "usa-federal-sro-fca-crm-2023", "api_id": "usa-federal-sro-fca-crm-2023", - "sheet_row": 113, + "sheet_row": 115, "header": "US\nFCA CRM", "matched_column": "US\nFCA CRM", "method": "exact", @@ -1090,7 +1088,7 @@ { "fdi": "usa-federal-fda-21-cfr-part-11-2025", "api_id": "usa-federal-fda-21-cfr-part-11-2025", - "sheet_row": 114, + "sheet_row": 116, "header": "US\nFDA\n21 CFR Part 11", "matched_column": "US\nFDA\n21 CFR Part 11", "method": "exact", @@ -1099,7 +1097,7 @@ { "fdi": "usa-federal-gsa-fedramp-5-low", "api_id": "usa-federal-gsa-fedramp-5-low", - "sheet_row": 115, + "sheet_row": 117, "header": "US\nFedRAMP R5\n(low)", "matched_column": "US\nFedRAMP R5\n(low)", "method": "exact", @@ -1108,7 +1106,7 @@ { "fdi": "usa-federal-gsa-fedramp-5-mod", "api_id": "usa-federal-gsa-fedramp-5-mod", - "sheet_row": 116, + "sheet_row": 118, "header": "US\nFedRAMP R5\n(moderate)", "matched_column": "US\nFedRAMP R5\n(moderate)", "method": "exact", @@ -1117,7 +1115,7 @@ { "fdi": "usa-federal-gsa-fedramp-5-high", "api_id": "usa-federal-gsa-fedramp-5-high", - "sheet_row": 117, + "sheet_row": 119, "header": "US\nFedRAMP R5\n(high)", "matched_column": "US\nFedRAMP R5\n(high)", "method": "exact", @@ -1126,16 +1124,25 @@ { "fdi": "usa-federal-gsa-fedramp-5-li-saas", "api_id": "usa-federal-gsa-fedramp-5-li-saas", - "sheet_row": 118, + "sheet_row": 120, "header": "US\nFedRAMP R5\n(LI-SaaS)", "matched_column": "US\nFedRAMP R5\n(LI-SaaS)", "method": "exact", "score": 100 }, + { + "fdi": "usa-federal-law-33-cfr-part-101-subpart-f", + "api_id": "usa-federal-law-33-cfr-part-101-subpart-f", + "sheet_row": 121, + "header": "US\n33 CFR\nPart 101 Subpart F", + "matched_column": "US\n33 CFR\nPart 101 Subpart F", + "method": "exact", + "score": 100 + }, { "fdi": "usa-federal-law-ferpa-2010", "api_id": "usa-federal-law-ferpa-2010", - "sheet_row": 119, + "sheet_row": 122, "header": "US\nFERPA", "matched_column": "US\nFERPA", "method": "exact", @@ -1144,7 +1151,7 @@ { "fdi": "usa-federal-sro-finra", "api_id": "usa-federal-sro-finra", - "sheet_row": 120, + "sheet_row": 123, "header": "US\nFINRA", "matched_column": "US\nFINRA", "method": "exact", @@ -1153,7 +1160,7 @@ { "fdi": "usa-federal-omb-fipps-1973", "api_id": "usa-federal-omb-fipps-1973", - "sheet_row": 121, + "sheet_row": 124, "header": "US\nFIPPS", "matched_column": "US\nFIPPS", "method": "exact", @@ -1162,7 +1169,7 @@ { "fdi": "usa-federal-law-ftc-act", "api_id": "usa-federal-law-ftc-act", - "sheet_row": 122, + "sheet_row": 125, "header": "US\nFTC Act", "matched_column": "US\nFTC Act", "method": "exact", @@ -1171,7 +1178,7 @@ { "fdi": "usa-federal-law-glba-cfr-314-2023", "api_id": "usa-federal-law-glba-cfr-314-2023", - "sheet_row": 123, + "sheet_row": 126, "header": "US\nGLBA\nCFR 314\n2023", "matched_column": "US\nGLBA\nCFR 314\n2023", "method": "exact", @@ -1180,7 +1187,7 @@ { "fdi": "usa-federal-hhs-45-cfr-155-260-2016", "api_id": "usa-federal-hhs-45-cfr-155-260-2016", - "sheet_row": 124, + "sheet_row": 127, "header": "US\nHHS\n45 CFR 155.260", "matched_column": "US\nHHS\n45 CFR 155.260", "method": "exact", @@ -1189,7 +1196,7 @@ { "fdi": "usa-federal-law-hipaa-simplification-2013", "api_id": "usa-federal-law-hipaa-simplification-2013", - "sheet_row": 125, + "sheet_row": 128, "header": "US\nHIPAA Administrative Simplification\n2013", "matched_column": "US\nHIPAA Administrative Simplification\n2013", "method": "exact", @@ -1198,7 +1205,7 @@ { "fdi": "usa-federal-law-hipaa-security-rule-2013", "api_id": "usa-federal-law-hipaa-security-rule-2013", - "sheet_row": 126, + "sheet_row": 129, "header": "US\nHIPAA\nSecurity Rule / NIST SP 800-66 R2", "matched_column": "US\nHIPAA\nSecurity Rule / NIST SP 800-66 R2", "method": "exact", @@ -1207,7 +1214,7 @@ { "fdi": "usa-federal-irs-1075-2021", "api_id": "usa-federal-irs-1075-2021", - "sheet_row": 127, + "sheet_row": 130, "header": "US\nIRS 1075", "matched_column": "US\nIRS 1075", "method": "exact", @@ -1216,7 +1223,7 @@ { "fdi": "usa-federal-cms-marse-2-0", "api_id": "usa-federal-cms-marse-2-0", - "sheet_row": 128, + "sheet_row": 131, "header": "US\nCMS MARS-E\n2.0", "matched_column": "US\nCMS MARS-E\n2.0", "method": "exact", @@ -1225,7 +1232,7 @@ { "fdi": "usa-federal-nerc-cip-2024", "api_id": "usa-federal-nerc-cip-2024", - "sheet_row": 129, + "sheet_row": 132, "header": "US\nNERC CIP\n2024", "matched_column": "US\nNERC CIP\n2024", "method": "exact", @@ -1234,7 +1241,7 @@ { "fdi": "usa-federal-nispom-2020", "api_id": "usa-federal-nispom-2020", - "sheet_row": 130, + "sheet_row": 133, "header": "US\nNISPOM\n2020", "matched_column": "US\nNISPOM\n2020", "method": "exact", @@ -1243,7 +1250,7 @@ { "fdi": "usa-federal-dow-safeguarding-nnpi-2010", "api_id": "usa-federal-dow-safeguarding-nnpi-2010", - "sheet_row": 131, + "sheet_row": 134, "header": "US\nNNPI (unclass)", "matched_column": "US\nNNPI (unclass)", "method": "exact", @@ -1252,7 +1259,7 @@ { "fdi": "usa-federal-sec-cybersecurity-rule-2023", "api_id": "usa-federal-sec-cybersecurity-rule-2023", - "sheet_row": 132, + "sheet_row": 135, "header": "US\nSEC\nCybersecurity Rule", "matched_column": "US\nSEC\nCybersecurity Rule", "method": "exact", @@ -1261,7 +1268,7 @@ { "fdi": "usa-federal-law-sox-2002", "api_id": "usa-federal-law-sox-2002", - "sheet_row": 133, + "sheet_row": 136, "header": "US\nSOX", "matched_column": "US\nSOX", "method": "exact", @@ -1270,7 +1277,7 @@ { "fdi": "usa-federal-tsa-security-directive-1580-82-2022-01", "api_id": "usa-federal-tsa-security-directive-1580-82-2022-01", - "sheet_row": 134, + "sheet_row": 137, "header": "US\nTSA / DHS\n1580/82-2022-01", "matched_column": "US\nTSA / DHS\n1580/82-2022-01", "method": "exact", @@ -1279,7 +1286,7 @@ { "fdi": "usa-state-ak-pipa-2009", "api_id": "usa-state-ak-pipa-2009", - "sheet_row": 135, + "sheet_row": 138, "header": "US - AK\nPIPA", "matched_column": "US - AK\nPIPA", "method": "exact", @@ -1288,7 +1295,7 @@ { "fdi": "usa-state-ca-sb327-2018", "api_id": "usa-state-ca-sb327-2018", - "sheet_row": 136, + "sheet_row": 139, "header": "US - CA\nSB327", "matched_column": "US - CA\nSB327", "method": "exact", @@ -1297,7 +1304,7 @@ { "fdi": "usa-state-ca-ccpa-cpra-2026", "api_id": "usa-state-ca-ccpa-cpra-2026", - "sheet_row": 137, + "sheet_row": 140, "header": "US - CA\nCCPA\n2025", "matched_column": "US - CA\nCCPA\n2025", "method": "exact", @@ -1306,7 +1313,7 @@ { "fdi": "usa-state-ca-sb1386-2002", "api_id": "usa-state-ca-sb1386-2002", - "sheet_row": 138, + "sheet_row": 141, "header": "US - CA\nSB1386", "matched_column": "US - CA\nSB1386", "method": "exact", @@ -1315,7 +1322,7 @@ { "fdi": "usa-state-co-privacy-act-2021", "api_id": "usa-state-co-privacy-act-2021", - "sheet_row": 139, + "sheet_row": 142, "header": "US - CO\nColorado Privacy Act", "matched_column": "US - CO\nColorado Privacy Act", "method": "exact", @@ -1324,7 +1331,7 @@ { "fdi": "usa-state-il-bipa-2008", "api_id": "usa-state-il-bipa-2008", - "sheet_row": 140, + "sheet_row": 143, "header": "US - IL\nBIPA", "matched_column": "US - IL\nBIPA", "method": "exact", @@ -1333,7 +1340,7 @@ { "fdi": "usa-state-il-ipa-2009", "api_id": "usa-state-il-ipa-2009", - "sheet_row": 141, + "sheet_row": 144, "header": "US - IL\nIPA", "matched_column": "US - IL\nIPA", "method": "exact", @@ -1342,7 +1349,7 @@ { "fdi": "usa-state-il-pipa-2006", "api_id": "usa-state-il-pipa-2006", - "sheet_row": 142, + "sheet_row": 145, "header": "US - IL\nPIPA", "matched_column": "US - IL\nPIPA", "method": "exact", @@ -1351,7 +1358,7 @@ { "fdi": "usa-state-ma-201-cmr-17-2008", "api_id": "usa-state-ma-201-cmr-17-2008", - "sheet_row": 143, + "sheet_row": 146, "header": "US - MA\n201 CMR 17.00", "matched_column": "US - MA\n201 CMR 17.00", "method": "exact", @@ -1360,16 +1367,16 @@ { "fdi": "usa-state-nv-privacy-law-2023", "api_id": "usa-state-nv-privacy-law-2023", - "sheet_row": 144, - "header": "US - NV\nSB220", - "matched_column": null, - "method": "unmatched", - "score": 0 + "sheet_row": 147, + "header": "US - NV\nPrivacy Law\n2023", + "matched_column": "US - NV\nPrivacy Law\n2023", + "method": "exact", + "score": 100 }, { "fdi": "usa-state-nv-regulation-5-2024", "api_id": "usa-state-nv-regulation-5-2024", - "sheet_row": 145, + "sheet_row": 148, "header": "US - NV\nNOGE Reg 5", "matched_column": "US - NV\nNOGE Reg 5", "method": "exact", @@ -1378,7 +1385,7 @@ { "fdi": "usa-state-nv-sb220-2019", "api_id": "usa-state-nv-sb220-2019", - "sheet_row": 146, + "sheet_row": 149, "header": "US - NV\nSB220", "matched_column": "US - NV\nSB220", "method": "exact", @@ -1387,7 +1394,7 @@ { "fdi": "usa-state-ny-dfs-23-nycrr500-2023-amd2", "api_id": "usa-state-ny-dfs-23-nycrr500-2023-amd2", - "sheet_row": 147, + "sheet_row": 150, "header": "US - NY\nDFS\n23 NYCRR500\n2023 Amd 2", "matched_column": "US - NY\nDFS\n23 NYCRR500\n2023 Amd 2", "method": "exact", @@ -1396,7 +1403,7 @@ { "fdi": "usa-state-ny-shield-act-2019", "api_id": "usa-state-ny-shield-act-2019", - "sheet_row": 148, + "sheet_row": 151, "header": "US - NY\nSHIELD Act\nS5575B", "matched_column": "US - NY\nSHIELD Act\nS5575B", "method": "exact", @@ -1405,7 +1412,7 @@ { "fdi": "usa-state-or-ors-646a-2025", "api_id": "usa-state-or-ors-646a-2025", - "sheet_row": 149, + "sheet_row": 152, "header": "US - OR\n646A", "matched_column": "US - OR\n646A", "method": "exact", @@ -1414,7 +1421,7 @@ { "fdi": "usa-state-or-cpa-2023", "api_id": "usa-state-or-cpa-2023", - "sheet_row": 150, + "sheet_row": 153, "header": "US - OR\nCPA", "matched_column": "US - OR\nCPA", "method": "exact", @@ -1423,7 +1430,7 @@ { "fdi": "usa-state-tn-tipa-2025", "api_id": "usa-state-tn-tipa-2025", - "sheet_row": 151, + "sheet_row": 154, "header": "US - TN\nTIPA", "matched_column": "US - TN\nTIPA", "method": "exact", @@ -1432,7 +1439,7 @@ { "fdi": "usa-state-tx-bc521-2009", "api_id": "usa-state-tx-bc521-2009", - "sheet_row": 152, + "sheet_row": 155, "header": "US - TX\nBC521", "matched_column": "US - TX\nBC521", "method": "exact", @@ -1441,7 +1448,7 @@ { "fdi": "usa-state-tx-cdpa-2025", "api_id": "usa-state-tx-cdpa-2025", - "sheet_row": 153, + "sheet_row": 156, "header": "US - TX\nCDPA", "matched_column": "US - TX\nCDPA", "method": "exact", @@ -1450,7 +1457,7 @@ { "fdi": "usa-state-tx-dir-security-control-standards-catalog-2-2", "api_id": "usa-state-tx-dir-security-control-standards-catalog-2-2", - "sheet_row": 154, + "sheet_row": 157, "header": "US - TX\nDIR Control Standards\n2.2", "matched_column": "US - TX\nDIR Control Standards\n2.2", "method": "exact", @@ -1459,7 +1466,7 @@ { "fdi": "usa-state-tx-sb820-2019", "api_id": "usa-state-tx-sb820-2019", - "sheet_row": 155, + "sheet_row": 158, "header": "US - TX\nSB 820", "matched_column": "US - TX\nSB 820", "method": "exact", @@ -1468,7 +1475,7 @@ { "fdi": "usa-state-tx-sb2610-2025", "api_id": "usa-state-tx-sb2610-2025", - "sheet_row": 156, + "sheet_row": 159, "header": "US - TX\nSB 2610", "matched_column": "US - TX\nSB 2610", "method": "exact", @@ -1477,7 +1484,7 @@ { "fdi": "usa-state-tx-txramp-2-0-level-1", "api_id": "usa-state-tx-txramp-2-0-level-1", - "sheet_row": 157, + "sheet_row": 160, "header": "US - TX\nTX-RAMP\nLevel 1", "matched_column": "US - TX\nTX-RAMP\nLevel 1", "method": "exact", @@ -1486,7 +1493,7 @@ { "fdi": "usa-state-tx-txramp-2-0-level-2", "api_id": "usa-state-tx-txramp-2-0-level-2", - "sheet_row": 158, + "sheet_row": 161, "header": "US - TX\nTX-RAMP\nLevel 2", "matched_column": "US - TX\nTX-RAMP\nLevel 2", "method": "exact", @@ -1495,7 +1502,7 @@ { "fdi": "usa-state-va-cdpa-2023", "api_id": "usa-state-va-cdpa-2023", - "sheet_row": 159, + "sheet_row": 162, "header": "US - VA\nCDPA\n2023", "matched_column": "US - VA\nCDPA\n2023", "method": "exact", @@ -1504,7 +1511,7 @@ { "fdi": "usa-state-vt-act-171-2018", "api_id": "usa-state-vt-act-171-2018", - "sheet_row": 160, + "sheet_row": 163, "header": "US - VT\nAct 171 of 2018", "matched_column": "US - VT\nAct 171 of 2018", "method": "exact", @@ -1513,34 +1520,34 @@ { "fdi": "emea-eu-ai-act-2024", "api_id": "emea-eu-ai-act-2024", - "sheet_row": 161, + "sheet_row": 164, "header": "EMEA\nEU\nAI Act", "matched_column": "EMEA\nEU\nAI Act", "method": "exact", "score": 100 }, { - "fdi": "emea-eu-cyber-resilience-act-2022", - "api_id": "emea-eu-cyber-resilience-act-2022", - "sheet_row": 162, - "header": "EMEA\nEU\nCyber Resiliency Act", - "matched_column": "EMEA\nEU\nCyber Resiliency Act", + "fdi": "emea-eu-cyber-resilience-act-2024", + "api_id": "emea-eu-cyber-resilience-act-2024", + "sheet_row": 165, + "header": "EMEA\nEU\nCyber Resiliency Act\n2024", + "matched_column": "EMEA\nEU\nCyber Resiliency Act\n2024", "method": "exact", "score": 100 }, { - "fdi": "emea-eu-cyber-resilience-act-annexes-2022", - "api_id": "emea-eu-cyber-resilience-act-annexes-2022", - "sheet_row": 163, - "header": "EMEA\nEU\nCyber Resiliency Act Annexes", - "matched_column": "EMEA\nEU\nCyber Resiliency Act Annexes", + "fdi": "emea-eu-cyber-resilience-act-annex-i-2024", + "api_id": "emea-eu-cyber-resilience-act-annex-i-2024", + "sheet_row": 166, + "header": "EMEA\nEU\nCyber Resiliency Act Annex I\n2024", + "matched_column": "EMEA\nEU\nCyber Resiliency Act Annex I\n2024", "method": "exact", "score": 100 }, { "fdi": "emea-eu-eba-ict-srm-2025", "api_id": "emea-eu-eba-ict-srm-2025", - "sheet_row": 164, + "sheet_row": 167, "header": "EMEA\nEU\nEBA\nGL/2019/04", "matched_column": "EMEA\nEU\nEBA\nGL/2019/04", "method": "exact", @@ -1549,88 +1556,88 @@ { "fdi": "emea-eu-dora-2023", "api_id": "emea-eu-dora-2023", - "sheet_row": 165, - "header": "EMEA\nEU\nDORA", - "matched_column": "EMEA\nEU\nDORA", + "sheet_row": 168, + "header": "EMEA\nEU\nDORA\n2023", + "matched_column": "EMEA\nEU\nDORA\n2023", "method": "exact", "score": 100 }, { "fdi": "emea-eu-gdpr-2016", "api_id": "emea-eu-gdpr-2016", - "sheet_row": 166, - "header": "EMEA\nEU\nGDPR", - "matched_column": "EMEA\nEU\nGDPR", + "sheet_row": 169, + "header": "EMEA\nEU\nGDPR\n2016", + "matched_column": "EMEA\nEU\nGDPR\n2016", "method": "exact", "score": 100 }, { "fdi": "emea-eu-nis2-2022", "api_id": "emea-eu-nis2-2022", - "sheet_row": 167, - "header": "EMEA\nEU\nNIS2", - "matched_column": "EMEA\nEU\nNIS2", + "sheet_row": 170, + "header": "EMEA\nEU\nNIS2\n2022", + "matched_column": "EMEA\nEU\nNIS2\n2022", "method": "exact", "score": 100 }, { "fdi": "emea-eu-nis2-annex-2024", "api_id": "emea-eu-nis2-annex-2024", - "sheet_row": 168, - "header": "EMEA\nEU\nNIS2 Annex", - "matched_column": "EMEA\nEU\nNIS2 Annex", + "sheet_row": 171, + "header": "EMEA\nEU\nNIS2 Annex\n2024", + "matched_column": "EMEA\nEU\nNIS2 Annex\n2024", "method": "exact", "score": 100 }, { - "fdi": "emea-us-psd2-2015", - "api_id": "emea-us-psd2-2015", - "sheet_row": 169, - "header": "EMEA\nEU\nPSD2", - "matched_column": "EMEA\nEU\nPSD2", + "fdi": "emea-eu-psd2-2015", + "api_id": "emea-eu-psd2-2015", + "sheet_row": 172, + "header": "EMEA\nEU\nPSD2\n2015", + "matched_column": "EMEA\nEU\nPSD2\n2015", "method": "exact", "score": 100 }, { - "fdi": "emea-aut-fappd-2000", - "api_id": "emea-aut-fappd-2000", - "sheet_row": 170, - "header": "EMEA\nAustria", - "matched_column": "EMEA\nAustria", + "fdi": "emea-aut-dpa-2018", + "api_id": "emea-aut-dpa-2018", + "sheet_row": 173, + "header": "EMEA\nAustria\nFAPPD\n2000", + "matched_column": "EMEA\nAustria\nFAPPD\n2000", "method": "exact", "score": 100 }, { - "fdi": "emea-bel-act-8-1992", - "api_id": "emea-bel-act-8-1992", - "sheet_row": 171, - "header": "EMEA\nBelgium", - "matched_column": "EMEA\nBelgium", + "fdi": "emea-bel-act-30-2018", + "api_id": "emea-bel-act-30-2018", + "sheet_row": 174, + "header": "EMEA\nBelgium\nAct 8\n1992", + "matched_column": "EMEA\nBelgium\nAct 8\n1992", "method": "exact", "score": 100 }, { "fdi": "emea-deu-fdpa-2017", "api_id": "emea-deu-fdpa-2017", - "sheet_row": 172, - "header": "EMEA\nGermany", - "matched_column": "EMEA\nGermany", + "sheet_row": 175, + "header": "EMEA\nGermany\nFDPA\n2017", + "matched_column": "EMEA\nGermany\nFDPA\n2017", "method": "exact", "score": 100 }, { "fdi": "emea-deu-bsrit-2017", "api_id": "emea-deu-bsrit-2017", - "sheet_row": 173, - "header": "EMEA\nGermany\nBanking Supervisory Requirements for IT (BAIT)", - "matched_column": "EMEA\nGermany\nBanking Supervisory Requirements for IT (BAIT)", + "sheet_row": 176, + "header": "EMEA\nGermany\nBAIT\n2017", + "matched_column": "EMEA\nGermany\nBAIT\n2017", "method": "exact", "score": 100 }, { "fdi": "emea-deu-c5-2020", "api_id": "emea-deu-c5-2020", - "sheet_row": 174, + "sheet_row": 177, "header": "EMEA\nGermany\nC5\n2020", "matched_column": "EMEA\nGermany\nC5\n2020", "method": "exact", @@ -1639,61 +1646,61 @@ { "fdi": "emea-grc-pirppd-1997", "api_id": "emea-grc-pirppd-1997", - "sheet_row": 175, - "header": "EMEA\nGreece", - "matched_column": "EMEA\nGreece", + "sheet_row": 178, + "header": "EMEA\nGreece\nPIRPPD\n1997", + "matched_column": "EMEA\nGreece\nPIRPPD\n1997", "method": "exact", "score": 100 }, { - "fdi": "emea-hun-isdfi-2011", - "api_id": "emea-hun-isdfi-2011", - "sheet_row": 176, - "header": "EMEA\nHungary", - "matched_column": "EMEA\nHungary", + "fdi": "emea-hun-act-cxii-2011", + "api_id": "emea-hun-act-cxii-2011", + "sheet_row": 179, + "header": "EMEA\nHungary\nAct CXII\n2011", + "matched_column": "EMEA\nHungary\nAct CXII\n2011", "method": "exact", "score": 100 }, { - "fdi": "emea-irl-dpa-2003", - "api_id": "emea-irl-dpa-2003", - "sheet_row": 177, - "header": "EMEA\nIreland", - "matched_column": "EMEA\nIreland", + "fdi": "emea-irl-dpa-2018", + "api_id": "emea-irl-dpa-2018", + "sheet_row": 180, + "header": "EMEA\nIreland\nDPA\n2018", + "matched_column": "EMEA\nIreland\nDPA\n2018", "method": "exact", "score": 100 }, { - "fdi": "emea-isr-cmo-1-0", - "api_id": "emea-isr-cmo-1-0", - "sheet_row": 178, - "header": "EMEA\nIsrael\nCDMO\n1.0", - "matched_column": "EMEA\nIsrael\nCDMO\n1.0", + "fdi": "emea-isr-cmo-2-0", + "api_id": "emea-isr-cmo-2-0", + "sheet_row": 181, + "header": "EMEA\nIsrael\nCDMO\n2.0", + "matched_column": "EMEA\nIsrael\nCDMO\n2.0", "method": "exact", "score": 100 }, { - "fdi": "emea-isr-ppl-5741-1981", - "api_id": "emea-isr-ppl-5741-1981", - "sheet_row": 179, - "header": "EMEA\nIsrael", - "matched_column": "EMEA\nIsrael", + "fdi": "emea-isr-ppl-5741-2025", + "api_id": "emea-isr-ppl-5741-2025", + "sheet_row": 182, + "header": "EMEA\nIsrael\nPPL\n2025", + "matched_column": "EMEA\nIsrael\nPPL\n2025", "method": "exact", "score": 100 }, { - "fdi": "emea-ita-pdpc-2003", - "api_id": "emea-ita-pdpc-2003", - "sheet_row": 180, - "header": "EMEA\nItaly", - "matched_column": "EMEA\nItaly", + "fdi": "emea-ita-pdpc-2018", + "api_id": "emea-ita-pdpc-2018", + "sheet_row": 183, + "header": "EMEA\nItaly\nPDPC\n2018", + "matched_column": "EMEA\nItaly\nPDPC\n2018", "method": "exact", "score": 100 }, { "fdi": "emea-ken-pda-2019", "api_id": "emea-ken-pda-2019", - "sheet_row": 181, + "sheet_row": 184, "header": "EMEA\nKenya\nDPA\n2019", "matched_column": "EMEA\nKenya\nDPA\n2019", "method": "exact", @@ -1702,7 +1709,7 @@ { "fdi": "emea-nga-dpr-2019", "api_id": "emea-nga-dpr-2019", - "sheet_row": 182, + "sheet_row": 185, "header": "EMEA\nNigeria\nDPR\n2019", "matched_column": "EMEA\nNigeria\nDPR\n2019", "method": "exact", @@ -1711,43 +1718,43 @@ { "fdi": "emea-nor-pda-2018", "api_id": "emea-nor-pda-2018", - "sheet_row": 183, - "header": "EMEA\nNorway", - "matched_column": "EMEA\nNorway", + "sheet_row": 186, + "header": "EMEA\nNorway\nDPA\n2018", + "matched_column": "EMEA\nNorway\nDPA\n2018", "method": "exact", "score": 100 }, { - "fdi": "emea-pol-act-29-1997", - "api_id": "emea-pol-act-29-1997", - "sheet_row": 184, - "header": "EMEA\nPoland", - "matched_column": "EMEA\nPoland", + "fdi": "emea-pol-act-10-2018", + "api_id": "emea-pol-act-10-2018", + "sheet_row": 187, + "header": "EMEA\nPoland\nAct 10\n2018", + "matched_column": "EMEA\nPoland\nAct 10\n2018", "method": "exact", "score": 100 }, { "fdi": "emea-qat-pdppl-2020", "api_id": "emea-qat-pdppl-2020", - "sheet_row": 185, - "header": "EMEA\nQatar\nPDPPL", - "matched_column": "EMEA\nQatar\nPDPPL", + "sheet_row": 188, + "header": "EMEA\nQatar\nPDPPL\n2020", + "matched_column": "EMEA\nQatar\nPDPPL\n2020", "method": "exact", "score": 100 }, { - "fdi": "emea-rus-federal-law-27-2006", - "api_id": "emea-rus-federal-law-27-2006", - "sheet_row": 186, - "header": "EMEA\nRussia", - "matched_column": "EMEA\nRussia", + "fdi": "emea-rus-152-fz-2025", + "api_id": "emea-rus-152-fz-2025", + "sheet_row": 189, + "header": "EMEA\nRussia\n152-FZ\n2025", + "matched_column": "EMEA\nRussia\n152-FZ\n2025", "method": "exact", "score": 100 }, { "fdi": "emea-sau-cscc-1-2019", "api_id": "emea-sau-cscc-1-2019", - "sheet_row": 187, + "sheet_row": 190, "header": "EMEA\nSaudi Arabia\nCSCC-1\n2019", "matched_column": "EMEA\nSaudi Arabia\nCSCC-1\n2019", "method": "exact", @@ -1756,7 +1763,7 @@ { "fdi": "emea-sau-cgiot-2024", "api_id": "emea-sau-cgiot-2024", - "sheet_row": 188, + "sheet_row": 191, "header": "EMEA\nSaudi Arabia\nIoT CGIoT-1\n2024", "matched_column": "EMEA\nSaudi Arabia\nIoT CGIoT-1\n2024", "method": "exact", @@ -1765,7 +1772,7 @@ { "fdi": "emea-sau-ecc-1-2018", "api_id": "emea-sau-ecc-1-2018", - "sheet_row": 189, + "sheet_row": 192, "header": "EMEA\nSaudi Arabia\nECC-1\n2018", "matched_column": "EMEA\nSaudi Arabia\nECC-1\n2018", "method": "exact", @@ -1774,7 +1781,7 @@ { "fdi": "emea-sau-otcc-1-2022", "api_id": "emea-sau-otcc-1-2022", - "sheet_row": 190, + "sheet_row": 193, "header": "EMEA\nSaudi Arabia\nOTCC-1\n2022", "matched_column": "EMEA\nSaudi Arabia\nOTCC-1\n2022", "method": "exact", @@ -1783,7 +1790,7 @@ { "fdi": "emea-sau-pdpl-2023", "api_id": "emea-sau-pdpl-2023", - "sheet_row": 191, + "sheet_row": 194, "header": "EMEA\nSaudi Arabia\nPDPL", "matched_column": "EMEA\nSaudi Arabia\nPDPL", "method": "exact", @@ -1792,25 +1799,25 @@ { "fdi": "emea-sau-sacs-002-2022", "api_id": "emea-sau-sacs-002-2022", - "sheet_row": 192, - "header": "EMEA\nSaudi Arabia\nSACS-002", - "matched_column": "EMEA\nSaudi Arabia\nSACS-002", + "sheet_row": 195, + "header": "EMEA\nSaudi Arabia\nSACS-002\n2022", + "matched_column": "EMEA\nSaudi Arabia\nSACS-002\n2022", "method": "exact", "score": 100 }, { "fdi": "emea-sau-sama-csf-1-2017", "api_id": "emea-sau-sama-csf-1-2017", - "sheet_row": 193, - "header": "EMEA\nSaudi Arabia\nSAMA CSF\n1.0", - "matched_column": "EMEA\nSaudi Arabia\nSAMA CSF\n1.0", + "sheet_row": 196, + "header": "EMEA\nSaudi Arabia\nSAMA CSF 1.0\n2017", + "matched_column": "EMEA\nSaudi Arabia\nSAMA CSF 1.0\n2017", "method": "exact", "score": 100 }, { "fdi": "emea-srb-act-9-2018", "api_id": "emea-srb-act-9-2018", - "sheet_row": 194, + "sheet_row": 197, "header": "EMEA\nSerbia\n87/2018", "matched_column": "EMEA\nSerbia\n87/2018", "method": "exact", @@ -1819,43 +1826,25 @@ { "fdi": "emea-zaf-popia-2013", "api_id": "emea-zaf-popia-2013", - "sheet_row": 195, - "header": "EMEA\nSouth Africa", - "matched_column": "EMEA\nSouth Africa", - "method": "exact", - "score": 100 - }, - { - "fdi": "emea-esp-boe-a-2022-7191", - "api_id": "emea-esp-boe-a-2022-7191", - "sheet_row": 196, - "header": "EMEA\nSpain\nBOE-A-2022-7191", - "matched_column": "EMEA\nSpain\nBOE-A-2022-7191", - "method": "exact", - "score": 100 - }, - { - "fdi": "emea-esp-decree-1720-2007", - "api_id": "emea-esp-decree-1720-2007", - "sheet_row": 197, - "header": "EMEA\nSpain\n1720/2007", - "matched_column": "EMEA\nSpain\n1720/2007", + "sheet_row": 198, + "header": "EMEA\nSouth Africa\nPOPIA\n2013", + "matched_column": "EMEA\nSouth Africa\nPOPIA\n2013", "method": "exact", "score": 100 }, { "fdi": "emea-esp-decree-311-2022", "api_id": "emea-esp-decree-311-2022", - "sheet_row": 198, - "header": "EMEA\nSpain\n311/2022", - "matched_column": "EMEA\nSpain\n311/2022", + "sheet_row": 199, + "header": "EMEA\nSpain\nRoyal Decree 311\n2022", + "matched_column": "EMEA\nSpain\nRoyal Decree 311\n2022", "method": "exact", "score": 100 }, { - "fdi": "emea-esp-ccn-stic-825-2023", - "api_id": "emea-esp-ccn-stic-825-2023", - "sheet_row": 199, + "fdi": "emea-esp-ccn-stic-825-2026", + "api_id": "emea-esp-ccn-stic-825-2026", + "sheet_row": 200, "header": "EMEA\nSpain\nCCN-STIC 825", "matched_column": "EMEA\nSpain\nCCN-STIC 825", "method": "exact", @@ -1864,34 +1853,34 @@ { "fdi": "emea-che-fadp-2025", "api_id": "emea-che-fadp-2025", - "sheet_row": 200, - "header": "EMEA\nSwitzerland", - "matched_column": "EMEA\nSwitzerland", + "sheet_row": 201, + "header": "EMEA\nSwitzerland\nFADP\n2025", + "matched_column": "EMEA\nSwitzerland\nFADP\n2025", "method": "exact", "score": 100 }, { "fdi": "emea-tur-lppd-2016", "api_id": "emea-tur-lppd-2016", - "sheet_row": 201, - "header": "EMEA\nTurkey", - "matched_column": "EMEA\nTurkey", + "sheet_row": 202, + "header": "EMEA\nTurkey\nLDDP\n2016", + "matched_column": "EMEA\nTurkey\nLDDP\n2016", "method": "exact", "score": 100 }, { "fdi": "emea-uae-niaf-2023", "api_id": "emea-uae-niaf-2023", - "sheet_row": 202, - "header": "EMEA\nUAE\nNIAF", - "matched_column": "EMEA\nUAE\nNIAF", + "sheet_row": 203, + "header": "EMEA\nUAE\nNIAF\n2023", + "matched_column": "EMEA\nUAE\nNIAF\n2023", "method": "exact", "score": 100 }, { "fdi": "emea-gbr-caf-4-0", "api_id": "emea-gbr-caf-4-0", - "sheet_row": 203, + "sheet_row": 204, "header": "EMEA\nUK\nCAF 4.0", "matched_column": "EMEA\nUK\nCAF 4.0", "method": "exact", @@ -1900,90 +1889,81 @@ { "fdi": "emea-gbr-cap-1850-2020", "api_id": "emea-gbr-cap-1850-2020", - "sheet_row": 204, - "header": "EMEA\nUK\nCAP 1850", - "matched_column": "EMEA\nUK\nCAP 1850", + "sheet_row": 205, + "header": "EMEA\nUK\nCAP 1850\n2020", + "matched_column": "EMEA\nUK\nCAP 1850\n2020", "method": "exact", "score": 100 }, { "fdi": "emea-gbr-cyber-essentials-requirements-3-3", "api_id": "emea-gbr-cyber-essentials-requirements-3-3", - "sheet_row": 205, - "header": "EMEA\nUK\nCyber Essentials", - "matched_column": "EMEA\nUK\nCyber Essentials", + "sheet_row": 206, + "header": "EMEA\nUK\nCyber Essentials 3.3", + "matched_column": "EMEA\nUK\nCyber Essentials 3.3", "method": "exact", "score": 100 }, { "fdi": "emea-gbr-def-stan-05-138-2024", "api_id": "emea-gbr-def-stan-05-138-2024", - "sheet_row": 206, - "header": "EMEA\nUK\nDEFSTAN 05-138", - "matched_column": "EMEA\nUK\nDEFSTAN 05-138", + "sheet_row": 207, + "header": "EMEA\nUK\nDEFSTAN 05-138\n2024", + "matched_column": "EMEA\nUK\nDEFSTAN 05-138\n2024", "method": "exact", "score": 100 }, { "fdi": "emea-gbr-def-stan-05-138-l0-2024", "api_id": "emea-gbr-def-stan-05-138-l0-2024", - "sheet_row": 207, - "header": "EMEA\nUK\nDEFSTAN 05-138 - L0", - "matched_column": "EMEA\nUK\nDEFSTAN 05-138 - L0", + "sheet_row": 208, + "header": "EMEA\nUK\nDEFSTAN 05-138 - L0\n2024", + "matched_column": "EMEA\nUK\nDEFSTAN 05-138 - L0\n2024", "method": "exact", "score": 100 }, { "fdi": "emea-gbr-def-stan-05-138-l1-2024", "api_id": "emea-gbr-def-stan-05-138-l1-2024", - "sheet_row": 208, - "header": "EMEA\nUK\nDEFSTAN 05-138 - L1", - "matched_column": "EMEA\nUK\nDEFSTAN 05-138 - L1", + "sheet_row": 209, + "header": "EMEA\nUK\nDEFSTAN 05-138 - L1\n2024", + "matched_column": "EMEA\nUK\nDEFSTAN 05-138 - L1\n2024", "method": "exact", "score": 100 }, { "fdi": "emea-gbr-def-stan-05-138-l2-2024", "api_id": "emea-gbr-def-stan-05-138-l2-2024", - "sheet_row": 209, - "header": "EMEA\nUK\nDEFSTAN 05-138 - L2", - "matched_column": "EMEA\nUK\nDEFSTAN 05-138 - L2", + "sheet_row": 210, + "header": "EMEA\nUK\nDEFSTAN 05-138 - L2\n2024", + "matched_column": "EMEA\nUK\nDEFSTAN 05-138 - L2\n2024", "method": "exact", "score": 100 }, { "fdi": "emea-gbr-def-stan-05-138-l3-2024", "api_id": "emea-gbr-def-stan-05-138-l3-2024", - "sheet_row": 210, - "header": "EMEA\nUK\nDEFSTAN 05-138 - L3", - "matched_column": "EMEA\nUK\nDEFSTAN 05-138 - L3", - "method": "exact", - "score": 100 - }, - { - "fdi": "emea-gbr-dpa-1998", - "api_id": "emea-gbr-dpa-1998", "sheet_row": 211, - "header": "EMEA\nUK\nDPA", - "matched_column": "EMEA\nUK\nDPA", + "header": "EMEA\nUK\nDEFSTAN 05-138 - L3\n2024", + "matched_column": "EMEA\nUK\nDEFSTAN 05-138 - L3\n2024", "method": "exact", "score": 100 }, { - "fdi": "apac-aus-essential-8-2024", - "api_id": "apac-aus-essential-8-2024", + "fdi": "emea-gbr-dpa-2018", + "api_id": "emea-gbr-dpa-2018", "sheet_row": 212, - "header": "APAC\nAustralia\nEssential 8", - "matched_column": "APAC\nAustralia\nEssential 8", + "header": "EMEA\nUK\nDPA\n2018", + "matched_column": "EMEA\nUK\nDPA\n2018", "method": "exact", "score": 100 }, { - "fdi": "apac-aus-privacy-act-1998", - "api_id": "apac-aus-privacy-act-1998", + "fdi": "apac-aus-essential-8-2024", + "api_id": "apac-aus-essential-8-2024", "sheet_row": 213, - "header": "APAC\nAustralia\nPrivacy Act", - "matched_column": "APAC\nAustralia\nPrivacy Act", + "header": "APAC\nAustralia\nEssential 8\n2024", + "matched_column": "APAC\nAustralia\nEssential 8\n2024", "method": "exact", "score": 100 }, @@ -1991,17 +1971,17 @@ "fdi": "apac-aus-privacy-principles-2026", "api_id": "apac-aus-privacy-principles-2026", "sheet_row": 214, - "header": "APAC\nAustralian Privacy Principles", - "matched_column": "APAC\nAustralian Privacy Principles", + "header": "APAC\nAustralian Privacy Principles\n2026", + "matched_column": "APAC\nAustralian Privacy Principles\n2026", "method": "exact", "score": 100 }, { - "fdi": "apac-aus-ism-2024-june", - "api_id": "apac-aus-ism-2024-june", + "fdi": "apac-aus-ism-2026-march", + "api_id": "apac-aus-ism-2026-march", "sheet_row": 215, - "header": "APAC\nAustralia\nISM\nJune 2024", - "matched_column": "APAC\nAustralia\nISM\nJune 2024", + "header": "APAC\nAustralia\nISM\nMarch 2026", + "matched_column": "APAC\nAustralia\nISM\nMarch 2026", "method": "exact", "score": 100 }, @@ -2009,8 +1989,8 @@ "fdi": "apac-aus-cop-sitc-2020", "api_id": "apac-aus-cop-sitc-2020", "sheet_row": 216, - "header": "APAC\nAustralia\nIoT Code of Practice", - "matched_column": "APAC\nAustralia\nIoT Code of Practice", + "header": "APAC\nAustralia\nIoT Code of Practice\n2024", + "matched_column": "APAC\nAustralia\nIoT Code of Practice\n2024", "method": "exact", "score": 100 }, @@ -2018,8 +1998,8 @@ "fdi": "apac-aus-ps-cps-230-2023", "api_id": "apac-aus-ps-cps-230-2023", "sheet_row": 217, - "header": "APAC\nAustralia\nPrudential Standard CPS230", - "matched_column": "APAC\nAustralia\nPrudential Standard CPS230", + "header": "APAC\nAustralia\nPrudential Standard CPS230\n2023", + "matched_column": "APAC\nAustralia\nPrudential Standard CPS230\n2023", "method": "exact", "score": 100 }, @@ -2027,8 +2007,8 @@ "fdi": "apac-aus-ps-cps-234-2019", "api_id": "apac-aus-ps-cps-234-2019", "sheet_row": 218, - "header": "APAC\nAustralia\nPrudential Standard CPS234", - "matched_column": "APAC\nAustralia\nPrudential Standard CPS234", + "header": "APAC\nAustralia\nPrudential Standard CPS234\n2019", + "matched_column": "APAC\nAustralia\nPrudential Standard CPS234\n2019", "method": "exact", "score": 100 }, @@ -2036,8 +2016,8 @@ "fdi": "apac-chn-cybersecurity-law-2017", "api_id": "apac-chn-cybersecurity-law-2017", "sheet_row": 219, - "header": "APAC\nChina\nCybersecurity Law", - "matched_column": "APAC\nChina\nCybersecurity Law", + "header": "APAC\nChina\nCybersecurity Law\n2017", + "matched_column": "APAC\nChina\nCybersecurity Law\n2017", "method": "exact", "score": 100 }, @@ -2045,8 +2025,8 @@ "fdi": "apac-chn-data-security-law-2021", "api_id": "apac-chn-data-security-law-2021", "sheet_row": 220, - "header": "APAC\nChina\nData Security Law", - "matched_column": "APAC\nChina\nData Security Law", + "header": "APAC\nChina\nData Security Law\n2021", + "matched_column": "APAC\nChina\nData Security Law\n2021", "method": "exact", "score": 100 }, @@ -2054,8 +2034,8 @@ "fdi": "apac-chn-csnip-2012", "api_id": "apac-chn-csnip-2012", "sheet_row": 221, - "header": "APAC\nChina\nDNSIP", - "matched_column": "APAC\nChina\nDNSIP", + "header": "APAC\nChina\nDNSIP\n2012", + "matched_column": "APAC\nChina\nDNSIP\n2012", "method": "exact", "score": 100 }, @@ -2063,8 +2043,8 @@ "fdi": "apac-chn-pipl-2021", "api_id": "apac-chn-pipl-2021", "sheet_row": 222, - "header": "APAC\nChina\nPrivacy Law", - "matched_column": "APAC\nChina\nPrivacy Law", + "header": "APAC\nChina\nPrivacy Law\n2021", + "matched_column": "APAC\nChina\nPrivacy Law\n2021", "method": "exact", "score": 100 }, @@ -2072,8 +2052,8 @@ "fdi": "apac-hkg-pdo-2022", "api_id": "apac-hkg-pdo-2022", "sheet_row": 223, - "header": "APAC\nHong Kong", - "matched_column": "APAC\nHong Kong", + "header": "APAC\nHong Kong\nPDO\n2022", + "matched_column": "APAC\nHong Kong\nPDO\n2022", "method": "exact", "score": 100 }, @@ -2090,8 +2070,8 @@ "fdi": "apac-ind-privacy-rules-2011", "api_id": "apac-ind-privacy-rules-2011", "sheet_row": 225, - "header": "APAC\nIndia\nITR", - "matched_column": "APAC\nIndia\nITR", + "header": "APAC\nIndia\nITR\n2011", + "matched_column": "APAC\nIndia\nITR\n2011", "method": "exact", "score": 100 }, @@ -2099,17 +2079,17 @@ "fdi": "apac-ind-sebi-2024", "api_id": "apac-ind-sebi-2024", "sheet_row": 226, - "header": "APAC\nIndia\nSEBI CSCRF", - "matched_column": "APAC\nIndia\nSEBI CSCRF", + "header": "APAC\nIndia\nSEBI CSCRF\n2024", + "matched_column": "APAC\nIndia\nSEBI CSCRF\n2024", "method": "exact", "score": 100 }, { - "fdi": "apac-jpn-ppi-2020", - "api_id": "apac-jpn-ppi-2020", + "fdi": "apac-jpn-appi-2020", + "api_id": "apac-jpn-appi-2020", "sheet_row": 227, - "header": "APAC\nJapan\nAPPI", - "matched_column": "APAC\nJapan\nAPPI", + "header": "APAC\nJapan\nAPPI\n2020", + "matched_column": "APAC\nJapan\nAPPI\n2020", "method": "exact", "score": 100 }, @@ -2126,15 +2106,24 @@ "fdi": "apac-mys-pdpa-2010", "api_id": "apac-mys-pdpa-2010", "sheet_row": 229, - "header": "APAC\nMalaysia", - "matched_column": "APAC\nMalaysia", + "header": "APAC\nMalaysia\nPDPA\n2010", + "matched_column": "APAC\nMalaysia\nPDPA\n2010", + "method": "exact", + "score": 100 + }, + { + "fdi": "apac-mys-bnm-rmit-2025", + "api_id": "apac-mys-bnm-rmit-2025", + "sheet_row": 230, + "header": "APAC\nMalaysia\nRMiT\n2025", + "matched_column": "APAC\nMalaysia\nRMiT\n2025", "method": "exact", "score": 100 }, { "fdi": "apac-nzl-hisf-mlhsp-2023", "api_id": "apac-nzl-hisf-mlhsp-2023", - "sheet_row": 230, + "sheet_row": 231, "header": "APAC\nNew Zealand\nHISF MLHSP\n2023", "matched_column": "APAC\nNew Zealand\nHISF MLHSP\n2023", "method": "exact", @@ -2143,7 +2132,7 @@ { "fdi": "apac-nzl-hisf-microsmall-2023", "api_id": "apac-nzl-hisf-microsmall-2023", - "sheet_row": 231, + "sheet_row": 232, "header": "APAC\nNew Zealand\nHISF Microsmall\n2023", "matched_column": "APAC\nNew Zealand\nHISF Microsmall\n2023", "method": "exact", @@ -2152,7 +2141,7 @@ { "fdi": "apac-nzl-hisf-suppliers-2023", "api_id": "apac-nzl-hisf-suppliers-2023", - "sheet_row": 232, + "sheet_row": 233, "header": "APAC\nNew Zealand\nHISF Suppliers\n2023", "matched_column": "APAC\nNew Zealand\nHISF Suppliers\n2023", "method": "exact", @@ -2161,16 +2150,16 @@ { "fdi": "apac-nzl-ism-3-9", "api_id": "apac-nzl-ism-3-9", - "sheet_row": 233, - "header": "APAC\nNew Zealand\nNZISM 3.6", - "matched_column": "APAC\nNew Zealand\nNZISM 3.6", + "sheet_row": 234, + "header": "APAC\nNew Zealand\nNZISM 3.9", + "matched_column": "APAC\nNew Zealand\nNZISM 3.9", "method": "exact", "score": 100 }, { "fdi": "apac-nzl-privacy-act-2020", "api_id": "apac-nzl-privacy-act-2020", - "sheet_row": 234, + "sheet_row": 235, "header": "APAC\nNew Zealand\nPrivacy Act of 2020", "matched_column": "APAC\nNew Zealand\nPrivacy Act of 2020", "method": "exact", @@ -2179,97 +2168,97 @@ { "fdi": "apac-phl-dpa-2012", "api_id": "apac-phl-dpa-2012", - "sheet_row": 235, - "header": "APAC\nPhilippines", - "matched_column": "APAC\nPhilippines", + "sheet_row": 236, + "header": "APAC\nPhilippines\nDPA\n2012", + "matched_column": "APAC\nPhilippines\nDPA\n2012", "method": "exact", "score": 100 }, { "fdi": "apac-sgp-pdpa-2012", "api_id": "apac-sgp-pdpa-2012", - "sheet_row": 236, - "header": "APAC\nSingapore", - "matched_column": "APAC\nSingapore", + "sheet_row": 237, + "header": "APAC\nSingapore\nPDPA\n2012", + "matched_column": "APAC\nSingapore\nPDPA\n2012", "method": "exact", "score": 100 }, { "fdi": "apac-sgp-cyber-hygiene-practice-2019", "api_id": "apac-sgp-cyber-hygiene-practice-2019", - "sheet_row": 237, - "header": "APAC\nSingapore \nCyber Hygiene Practice", - "matched_column": "APAC\nSingapore \nCyber Hygiene Practice", + "sheet_row": 238, + "header": "APAC\nSingapore \nCyber Hygiene Practice\n2019", + "matched_column": "APAC\nSingapore \nCyber Hygiene Practice\n2019", "method": "exact", "score": 100 }, { "fdi": "apac-sgp-mas-trm-2021", "api_id": "apac-sgp-mas-trm-2021", - "sheet_row": 238, - "header": "APAC\nSingapore MAS\nTRM 2021", - "matched_column": "APAC\nSingapore MAS\nTRM 2021", + "sheet_row": 239, + "header": "APAC\nSingapore\nMAS TRM\n2021", + "matched_column": "APAC\nSingapore\nMAS TRM\n2021", "method": "exact", "score": 100 }, { "fdi": "apac-kor-pipa-2011", "api_id": "apac-kor-pipa-2011", - "sheet_row": 239, - "header": "APAC\nSouth Korea", - "matched_column": "APAC\nSouth Korea", + "sheet_row": 240, + "header": "APAC\nSouth Korea\nPIPA\n2011", + "matched_column": "APAC\nSouth Korea\nPIPA\n2011", "method": "exact", "score": 100 }, { "fdi": "apac-twn-pdpa-2025", "api_id": "apac-twn-pdpa-2025", - "sheet_row": 240, - "header": "APAC\nTaiwan", - "matched_column": "APAC\nTaiwan", + "sheet_row": 241, + "header": "APAC\nTaiwan\nPDPA\n2025", + "matched_column": "APAC\nTaiwan\nPDPA\n2025", "method": "exact", "score": 100 }, { "fdi": "americas-arg-ppd-2018", "api_id": "americas-arg-ppd-2018", - "sheet_row": 241, - "header": "Americas\nArgentina\nReg 132-2018", - "matched_column": "Americas\nArgentina\nReg 132-2018", + "sheet_row": 242, + "header": "Americas\nArgentina\nReg 132\n2018", + "matched_column": "Americas\nArgentina\nReg 132\n2018", "method": "exact", "score": 100 }, { "fdi": "americas-bhs-dpa-2003", "api_id": "americas-bhs-dpa-2003", - "sheet_row": 242, - "header": "Americas\nBahamas", - "matched_column": "Americas\nBahamas", + "sheet_row": 243, + "header": "Americas\nBahamas\nDPA\n2003", + "matched_column": "Americas\nBahamas\nDPA\n2003", "method": "exact", "score": 100 }, { "fdi": "americas-bmu-mba-coc-2020", "api_id": "americas-bmu-mba-coc-2020", - "sheet_row": 243, - "header": "Americas\nBermuda\nBMACCC", - "matched_column": "Americas\nBermuda\nBMACCC", + "sheet_row": 244, + "header": "Americas\nBermuda\nBMACCC\n2020", + "matched_column": "Americas\nBermuda\nBMACCC\n2020", "method": "exact", "score": 100 }, { "fdi": "americas-bra-lgpd-2018", "api_id": "americas-bra-lgpd-2018", - "sheet_row": 244, - "header": "Americas\nBrazil\nLGPD", - "matched_column": "Americas\nBrazil\nLGPD", + "sheet_row": 245, + "header": "Americas\nBrazil\nLGPD\n2018", + "matched_column": "Americas\nBrazil\nLGPD\n2018", "method": "exact", "score": 100 }, { - "fdi": "amaericas-can-osfi-self-assessment", - "api_id": "amaericas-can-osfi-self-assessment", - "sheet_row": 245, + "fdi": "americas-can-osfi-self-assessment", + "api_id": "americas-can-osfi-self-assessment", + "sheet_row": 246, "header": "Americas\nCanada\nCSAG", "matched_column": "Americas\nCanada\nCSAG", "method": "exact", @@ -2278,60 +2267,68 @@ { "fdi": "americas-can-osfi-b13-2022", "api_id": "americas-can-osfi-b13-2022", - "sheet_row": 246, - "header": "Americas\nCanada\nOSFI B-13", - "matched_column": "Americas\nCanada\nOSFI B-13", + "sheet_row": 247, + "header": "Americas\nCanada\nOSFI B-13\n2022", + "matched_column": "Americas\nCanada\nOSFI B-13\n2022", + "method": "exact", + "score": 100 + }, + { + "fdi": "americas-can-osfi-self-assessment", + "api_id": "americas-can-osfi-self-assessment-2", + "sheet_row": 248, + "header": "Americas\nCanada\nOSFI Self-Assessment Guidance", + "matched_column": "Americas\nCanada\nOSFI Self-Assessment Guidance", "method": "exact", "score": 100 }, { "fdi": "americas-can-itsp-10-171-2025", "api_id": "americas-can-itsp-10-171-2025", - "sheet_row": 247, - "header": "Americas\nCanada\nITSP-10-171", - "matched_column": "Americas\nCanada\nITSP-10-171", + "sheet_row": 249, + "header": "Americas\nCanada\nITSP-10-171\n2025", + "matched_column": "Americas\nCanada\nITSP-10-171\n2025", "method": "exact", "score": 100 }, { "fdi": "americas-can-pipeda-2000", "api_id": "americas-can-pipeda-2000", - "sheet_row": 248, - "header": "Americas\nCanada\nPIPEDA", - "matched_column": "Americas\nCanada\nPIPEDA", + "sheet_row": 250, + "header": "Americas\nCanada\nPIPEDA\n2000", + "matched_column": "Americas\nCanada\nPIPEDA\n2000", "method": "exact", "score": 100 }, { "fdi": "americas-chl-act-19628-1999", "api_id": "americas-chl-act-19628-1999", - "sheet_row": 249, - "header": "Americas\nChile", - "matched_column": "Americas\nChile", + "sheet_row": 251, + "header": "Americas\nChile\nAct 19628\n1999", + "matched_column": "Americas\nChile\nAct 19628\n1999", "method": "exact", "score": 100 }, { "fdi": "americas-col-law-1581-2012", "api_id": "americas-col-law-1581-2012", - "sheet_row": 250, - "header": "Americas\nColombia", - "matched_column": "Americas\nColombia", + "sheet_row": 252, + "header": "Americas\nColombia\nLaw 1581\n2012", + "matched_column": "Americas\nColombia\nLaw 1581\n2012", "method": "exact", "score": 100 }, { "fdi": "americas-mex-fdpa-2010", "api_id": "americas-mex-fdpa-2010", - "sheet_row": 251, - "header": "Americas\nMexico", - "matched_column": "Americas\nMexico", + "sheet_row": 253, + "header": "Americas\nMexico\nFDPA\n2010", + "matched_column": "Americas\nMexico\nFDPA\n2010", "method": "exact", "score": 100 } ], "unmatched_columns": [ - "US - NV\nPrivacy Law 2023", "Minimum Security Requirements \nMCR + DSR", "Identify\nMinimum Compliance Requirements (MCR)", "Identify\nDiscretionary Security Requirements (DSR)" From db8ff37d7f63774b2307d9fece0962c908a74651 Mon Sep 17 00:00:00 2001 From: TsunamiNoAi Date: Tue, 4 Aug 2026 12:50:42 -0400 Subject: [PATCH 2/2] Keep the version-bump test hermetic; record the CI workbook path MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The new catalog-prune test called `parse` without --report, whose default is the repo's validation/validation-report.json — so running the suite overwrote the committed release report with fixture output. Also regenerate the 2026.2 report with the workbook at the relative path autopilot uses, instead of a local absolute path. Same sha256, and data/ is byte-identical. --- tests/test_cli.py | 13 ++++++++++++- validation/validation-report.json | 4 ++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/tests/test_cli.py b/tests/test_cli.py index 955bea4b..38f24052 100644 --- a/tests/test_cli.py +++ b/tests/test_cli.py @@ -85,7 +85,18 @@ def test_version_bump_removes_the_previous_catalog(clean_workbook, tmp_path): from scf_api.build import find_catalog data = tmp_path / "data" - args = ["parse", "--workbook", str(clean_workbook), "--out", str(data), "--overrides", "/none"] + # --report defaults to the repo's validation/ path; keep the test hermetic. + args = [ + "parse", + "--workbook", + str(clean_workbook), + "--out", + str(data), + "--overrides", + "/none", + "--report", + str(tmp_path / "report.json"), + ] assert main([*args, "--scf-version", "2099.1.1"]) == 0 assert (data / "scf-2099-1-1.json").exists() diff --git a/validation/validation-report.json b/validation/validation-report.json index 323ea3e6..ff889acd 100644 --- a/validation/validation-report.json +++ b/validation/validation-report.json @@ -1,8 +1,8 @@ { "scf_version": "2026.2", "workbook_sha256": "9e0a4df4993726c95e636f04b3028d8b5edeba2bda45d16ed6722b13540e6835", - "workbook": "/tmp/claude-1001/-home-tsunami-code-sc2-scf-api-sc2in/ed86f800-bd58-4ecf-a036-698937f8a3e0/scratchpad/wb/secure-controls-framework-scf-2026-2.xlsx", - "generated_at": "2026-08-04T16:40:58+00:00", + "workbook": "workbooks/secure-controls-framework-scf-2026-2.xlsx", + "generated_at": "2026-08-04T16:50:03+00:00", "summary": { "fail": 0, "warn": 3,